Saat ini, laporan dan analitik hampir sama pentingnya dengan bisnis inti. Laporan dapat dibuat dari data langsung Anda; seringkali pendekatan ini akan berhasil untuk perusahaan kecil dan menengah tanpa banyak data. Tetapi ketika segalanya menjadi lebih besar – atau jumlah data mulai meningkat secara dramatis – inilah saatnya untuk berpikir tentang memisahkan sistem operasional dan pelaporan Anda.
Sebelum kita menangani pemodelan data dasar, kita memerlukan beberapa latar belakang tentang sistem yang terlibat. Kami secara kasar dapat membagi sistem dalam dua kategori:sistem operasional dan pelaporan. Sistem operasional sering disebut Online Transaction Processing (OLTP). Sistem pelaporan dan analitik disebut sebagai Online Analytical Processing (OLAP). Sistem OLTP mendukung proses bisnis. Mereka bekerja dengan data operasional "langsung", sangat dinormalisasi, dan bereaksi sangat cepat terhadap tindakan pengguna. Di sisi lain, tujuan utama sistem OLAP adalah analitik. Sistem ini menggunakan data yang diringkas, yang biasanya ditempatkan dalam struktur pergudangan data yang didenormalisasi seperti skema bintang. (Apa itu denormalisasi? Sederhananya, ia memiliki catatan data yang berlebihan demi kinerja yang lebih baik. Baca selengkapnya.)
Sekarang setelah kita mengetahui sedikit tentang sistem, mari kita mulai memeriksa gudang data beserta bagian dan prosesnya.
Data Warehouse vs. Data Mart
gudang data (DWH) adalah sistem yang digunakan untuk menyimpan informasi untuk digunakan dalam analisis dan pelaporan data. Data mart adalah area gudang data yang digunakan untuk menyimpan informasi yang dibutuhkan oleh satu departemen atau bahkan oleh pengguna individu. (Bayangkan DWH sebagai gedung, dan data mart sebagai kantor di dalam gedung.)
Mengapa data mart dibutuhkan? Semua data yang relevan disimpan di dalam DWH perusahaan. Namun, sebagian besar pengguna hanya perlu mengakses subset data tertentu, seperti yang berkaitan dengan penjualan, produksi, logistik, atau pemasaran. Data mart penting dari sudut pandang keamanan (membatasi akses yang tidak perlu) dan dari sudut pandang pengguna (kami tidak ingin membingungkan mereka atau memaksa mereka untuk mengarungi data asing).
Ada dua pendekatan berbeda untuk hubungan data warehouse-data mart:
- Top-Down :Data mart dibuat dari gudang data. (Ini adalah sesuatu yang Bill Inmon, “bapak gudang data”, akan setuju, bersama dengan gagasan bahwa gudang harus dalam 3NF.)
- Bottom-Up :Data mart dibuat terlebih dahulu, kemudian digabungkan menjadi data warehouse. (Pendekatan ini lebih dekat dengan apa yang didukung oleh Ralph Kimball, seorang ahli data warehouse dan pemodelan dimensi.)
Proses ETL digunakan untuk menambahkan data "baru" ke sistem OLAP secara teratur. ETL adalah kependekan dari Extract, Transform, dan Load. Seperti namanya, kami akan mengekstrak data dari satu atau beberapa database operasional, mengubahnya agar sesuai dengan struktur gudang kami, dan memuat data ke dalam DWH.
Pemodelan dimensi , yang merupakan bagian dari desain gudang data, menghasilkan pembuatan model dimensi. Ada dua jenis tabel yang terlibat:
-
Tabel dimensi digunakan untuk menggambarkan data yang ingin kita simpan. Misalnya:pengecer mungkin ingin menyimpan tanggal, toko, dan karyawan yang terlibat dalam pembelian tertentu. Setiap tabel dimensi adalah kategorinya sendiri (tanggal, karyawan, toko) dan dapat memiliki satu atau lebih atribut . Untuk setiap toko, kami dapat menyimpan lokasinya di tingkat kota, wilayah, negara bagian, dan negara. Untuk setiap tanggal, kita dapat menyimpan tahun, bulan, hari dalam sebulan, hari dalam seminggu, dll. Ini terkait dengan hierarki atribut dalam tabel dimensi.
Dalam skema bintang, kita biasanya akan menemukan bahwa beberapa atribut adalah subset dari atribut lain dalam catatan yang sama. Redundansi ini disengaja dan dilakukan atas nama kinerja yang lebih baik. Kita dapat menggunakan dimensi tanggal, lokasi, dan agen penjualan untuk menggabungkan (bagian transformasi dari proses ETL) dan menyimpan data di dalam DWH. Dalam pemodelan dimensi, sangat penting untuk menentukan dimensi yang tepat dan memilih granulasi yang tepat.
- Tabel fakta berisi data yang ingin kami sertakan dalam laporan, dikumpulkan berdasarkan nilai dalam tabel dimensi terkait. Tabel fakta hanya memiliki kolom yang menyimpan nilai dan kunci asing yang merujuk ke tabel dimensi. Menggabungkan semua kunci asing membentuk kunci utama dari tabel fakta. Misalnya, tabel fakta dapat menyimpan sejumlah kontak dan jumlah penjualan yang dihasilkan dari kontak tersebut.
Dengan info ini, kita sekarang dapat menggali model data skema bintang.
Skema Bintang
Skema bintang adalah model paling sederhana yang digunakan dalam DWH. Karena tabel fakta berada di tengah skema dengan tabel dimensi di sekitarnya, tampilannya kira-kira seperti bintang. Hal ini terutama terlihat ketika tabel fakta dikelilingi oleh tabel lima dimensi. Varian dari skema bintang skema lipan , di mana tabel fakta dikelilingi oleh sejumlah besar tabel dimensi kecil.
Skema bintang sangat umum digunakan di data mart. Kita dapat menghubungkannya dengan pendekatan model data top-down. Kami akan menganalisis dua skema bintang (data mart) dan kemudian menggabungkannya untuk membuat satu model.
Contoh Skema Bintang:Penjualan
Laporan penjualan adalah salah satu laporan paling umum saat ini. Seperti yang kami sebutkan sebelumnya, dalam banyak kasus kami dapat menghasilkan laporan penjualan dari sistem langsung. Tetapi ketika data atau ukuran bisnis membuatnya terlalu rumit, kita harus membangun gudang data atau data mart untuk merampingkan prosesnya. Setelah merancang skema bintang kami, sebuah ETL proses akan mendapatkan data dari database operasional, mengubah data ke dalam format yang tepat untuk DWH, dan memuat data ke dalam gudang.
Model yang disajikan di atas terdiri dari satu tabel fakta (berwarna merah muda) dan tabel lima dimensi (berwarna biru muda). Tabel dalam model adalah:
fact_sales– Tabel ini berisi referensi ke tabel dimensi ditambah dua fakta (harga dan kuantitas yang terjual). Perhatikan bahwa kelima kunci asing bersama-sama membentuk kunci utama tabel.dim_sales_type– Ini adalah tabel dimensi tipe penjualan dengan hanya satu atribut, “type_name”.dim_employee– Ini adalah tabel dimensi karyawan yang menyimpan atribut dasar karyawan:nama lengkap dan tahun lahir.dim_product– Ini adalah tabel dimensi produk dengan hanya dua atribut (selain kunci utama):nama produk dan jenis produk.dim_time– Tabel ini menangani dimensi waktu. Ini berisi lima atribut selain kunci utama. Data tingkat terendah adalah penjualan menurut tanggal (action_date).action_weekatribut adalah jumlah minggu di tahun itu (yaitu minggu pertama di bulan Januari akan diberi nomor 1; minggu terakhir di bulan Desember akan mendapatkan nomor 52, dll.)actual_monthdanactual_yearatribut menyimpan kalender bulan dan tahun saat penjualan terjadi. Ini dapat diekstraksi dariaction_dateatribut.action_weekdayatribut menyimpan nama hari saat penjualan berlangsung.dim_store– Ini adalah dimensi toko. Untuk setiap toko, kami akan menyimpan kota, wilayah, negara bagian, dan negara tempat toko itu berada. Di sini kita dapat dengan jelas melihat bahwa skema bintang didenormalisasi.
Contoh Skema Bintang:Pesanan Pasokan
Ada banyak kesamaan antara model ini, yang ditunjukkan di bawah, dan model penjualan.
Model ini dimaksudkan untuk menyimpan riwayat pesanan yang ditempatkan. Kami memiliki satu tabel fakta dan tabel empat dimensi. Tabel dimensi dim_employee , dim_product dan dim_time persis sama dengan model penjualan. Namun, tabel berikut ini berbeda:
fact_supply_order– berisi data agregat tentang pesanan yang dilakukan.dim_supplier– adalah tabel dimensi yang menyimpan data pemasok dengan cara yang sama sepertidim_storemenyimpan data toko dalam model penjualan.
Keuntungan dan Kerugian Skema Bintang
Ada banyak keuntungan menggunakan skema bintang. Tabel fakta terkait dengan setiap tabel dimensi dengan tepat satu relasi, dan kita tidak memerlukan kamus tambahan untuk mendeskripsikan tabel dimensi. Itu menyederhanakan kueri dan mengurangi waktu eksekusi kueri. Kami dapat menghasilkan laporan yang sama langsung dari sistem OLTP kami, tetapi kuerinya akan jauh lebih kompleks dan dapat memengaruhi kinerja sistem secara keseluruhan. Kueri sampel berikut untuk model penjualan akan menampilkan jumlah semua jenis produk jenis telepon yang dijual di toko Berlin pada tahun 2016:
SELECT dim_store.store_address, SUM(fact_sales.quantity) AS quantity_sold FROM fact_sales INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id WHERE dim_time.action_year = 2016 AND dim_store.city = 'Berlin' AND dim_product.product_type = 'phone' GROUP BY dim_store.store_id, dim_store.store_address
Kerugian terbesar dari skema bintang adalah redundansi. Setiap dimensi disimpan dalam tabel dimensi terpisah, dan ini menyebabkan denormalisasi. Dalam contoh kita, kota adalah milik suatu wilayah atau negara bagian, yang merupakan milik suatu negara; kami tidak menyimpan hubungan itu sebagai aturan di database kami, tetapi kami terus mengulanginya. Ini berarti kita akan menghabiskan lebih banyak ruang disk dan memiliki risiko integritas data.
Skema Galaksi
Kita dapat melihat dua model sebelumnya sebagai dua data mart, satu untuk departemen penjualan dan yang lainnya untuk departemen persediaan. Masing-masing hanya terdiri dari satu tabel fakta dan beberapa tabel dimensi. Jika kita mau, kita bisa menggabungkan dua data mart ini menjadi satu model. Jenis skema ini, yang berisi beberapa tabel fakta dan berbagi beberapa tabel dimensi, disebut skema galaksi . Berbagi tabel dimensi dapat mengurangi ukuran database, terutama jika dimensi bersama memiliki banyak kemungkinan nilai. Idealnya, di kedua data mart, dimensi didefinisikan dengan cara yang sama. Jika bukan itu masalahnya, kita harus menyesuaikan dimensi agar sesuai dengan kedua kebutuhan.
Skema galaksi, dibangun dari dua contoh data mart kami, ditunjukkan di bawah ini:
Skema bintang adalah salah satu pendekatan untuk mengatur gudang data. Ini sangat mudah dan paling sering digunakan di data mart. Jika kita tidak perlu khawatir tentang ruang disk dan kita menjaga integritas data dengan baik, maka skema bintang adalah pilihan pertama dan terbaik yang layak. Jika tidak, kita harus memikirkan pendekatan lain. Salah satunya adalah skema kepingan salju, yang akan kita bahas di artikel mendatang.
