Skema Bintang vs. Skema Kepingan Salju

Dalam dua artikel sebelumnya, kami mempertimbangkan dua model gudang data yang paling umum:skema bintang dan skema kepingan salju. Hari ini, kami akan memeriksa perbedaan antara kedua skema ini dan kami akan menjelaskan kapan sebaiknya menggunakan satu atau yang lain.

Skema bintang dan skema kepingan salju adalah cara untuk mengatur data mart atau seluruh gudang data menggunakan database relasional. Keduanya menggunakan tabel dimensi untuk mendeskripsikan data yang dikumpulkan dalam tabel fakta .

Setiap orang menjual sesuatu, baik itu pengetahuan, produk, atau layanan. Menyimpan informasi ini, baik dalam sistem operasional maupun dalam sistem pelaporan, juga merupakan kebutuhan. Jadi kita bisa berharap untuk menemukan beberapa jenis model penjualan di dalam gudang data hampir setiap perusahaan.

Mari kita lihat sekali lagi model penjualan dalam skema bintang dan kepingan salju.

Skema Bintang

Karakteristik yang paling jelas dari skema bintang adalah bahwa tabel dimensi tidak dinormalisasi. Pada model di atas, fact_sales tabel menyimpan data agregat yang dibuat dari basis data operasional kami. Tabel biru muda adalah tabel dimensi. Kami memutuskan untuk menggunakan lima dimensi ini karena kami perlu membuat laporan menggunakan mereka sebagai parameter. Granulasi di dalam setiap dimensi juga ditentukan oleh kebutuhan pelaporan kami.

Dari model ini, kita dapat dengan mudah melihat mengapa skema ini disebut 'skema bintang':terlihat seperti bintang, dengan tabel dimensi mengelilingi tabel fakta pusat.

Skema Kepingan Salju

Skema kepingan salju ini menyimpan data yang sama persis dengan skema bintang. Tabel fakta memiliki dimensi yang sama seperti pada contoh skema bintang. Perbedaan yang paling penting adalah bahwa tabel dimensi dalam skema kepingan salju dinormalisasi. Menariknya, proses normalisasi tabel dimensi disebut snowflaking.

Sekali lagi, secara visual skema kepingan salju mengingatkan kita pada namanya, dengan beberapa lapisan tabel dimensi menciptakan bentuk seperti kepingan salju yang tidak beraturan.

Perbedaan Pertama:Normalisasi

Seperti disebutkan, normalisasi adalah perbedaan utama antara skema bintang dan kepingan salju. Mengenai hal ini, ada beberapa hal yang perlu diketahui:

Skema kepingan salju akan menggunakan lebih sedikit ruang untuk menyimpan tabel dimensi. Ini karena sebagai aturan, basis data yang dinormalisasi menghasilkan jauh lebih sedikit catatan redundan.
Model data yang didenormalisasi meningkatkan kemungkinan masalah integritas data. Masalah ini juga akan memperumit modifikasi dan pemeliharaan di masa mendatang.
Untuk pemodel data berpengalaman, skema kepingan salju tampaknya lebih terorganisir secara logis daripada skema bintang. (Ini adalah pendapat pribadi saya, bukan fakta yang sulit. :) )

Mari beralih ke perbedaan utama kedua antara kedua skema ini.

Perbedaan Kedua:Kompleksitas Kueri

Dalam dua artikel pertama kami, kami mendemonstrasikan kueri yang dapat digunakan pada model penjualan untuk mendapatkan jumlah semua produk tipe telepon yang dijual di toko Berlin pada tahun 2016.

Kueri skema bintang terlihat seperti ini:

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

Untuk mendapatkan hasil yang sama dari skema kepingan salju, kita harus menggunakan kueri ini:

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_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Jelas, kueri skema kepingan salju lebih kompleks. Karena tabel dimensi dinormalisasi, kita perlu menggali lebih dalam untuk mendapatkan nama jenis produk dan kotanya. Kita harus menambahkan GABUNG lain untuk setiap level baru di dalam dimensi yang sama.

Dalam skema bintang, kita hanya menggabungkan tabel fakta dengan tabel dimensi yang kita butuhkan. Paling-paling, kita hanya akan memiliki satu GABUNG per tabel dimensi. Dan jika kita tidak menggunakan tabel dimensi, kita bahkan tidak perlu repot dengannya. Dalam kueri skema kepingan salju, kami tidak tahu seberapa dalam yang harus kami tempuh untuk mendapatkan tingkat dimensi yang tepat, sehingga memperumit proses penulisan kueri.

Menggabungkan dua tabel membutuhkan waktu karena DMBS membutuhkan waktu lebih lama untuk memproses permintaan. dim_store dan dim_city tabel ditempatkan berdekatan dalam model kami, tetapi mereka mungkin tidak ditempatkan di dekat satu sama lain pada disk. Ada kemungkinan yang lebih baik bahwa data akan lebih dekat secara fisik pada disk jika berada di dalam tabel yang sama.

Pada dasarnya, kueri yang dijalankan terhadap data mart skema kepingan salju akan dieksekusi lebih lambat. Namun dalam kebanyakan kasus, ini tidak akan menimbulkan masalah:tidak masalah jika kita mendapatkan hasilnya dalam satu milidetik atau satu detik.

Mempercepat Segalanya

Untuk mempercepat pelaporan, kami dapat:

Gabungkan data ke tingkat yang kami butuhkan dalam laporan. Ini akan memampatkan data secara signifikan. Kita perlu membuat prosedur yang akan mengubah data langsung kita agar sesuai dengan struktur skema pelaporan (proses ETL).
Bangun area penyimpanan pusat untuk semua data agregat perusahaan, bukan hanya data penjualan.
Hanya berikan data yang dibutuhkan pengguna untuk analisis dan laporan.

Skema Kepingan Salju vs. Bintang:Mana yang Harus Anda Gunakan?

Sekarang setelah kita melihat teori dan kecepatan kueri, mari kita langsung ke inti masalahnya:bagaimana Anda tahu skema mana yang akan digunakan pada proyek tertentu?

Pertimbangkan untuk menggunakan skema kepingan salju :

Di gudang data. Karena gudang adalah Pusat Data bagi perusahaan, kami dapat menghemat banyak ruang dengan cara ini.
Saat tabel dimensi membutuhkan ruang penyimpanan yang signifikan. Dalam kebanyakan kasus, tabel fakta akan menjadi tabel yang mengambil sebagian besar ruang. Mereka mungkin juga akan tumbuh lebih cepat daripada tabel dimensi. Tetapi ada situasi tertentu di mana itu tidak berlaku. Misalnya, tabel dimensi dapat berisi banyak atribut yang berlebihan tetapi dibutuhkan. Dalam contoh kami, kami menggunakan kota atribut untuk menggambarkan kota tempat toko berada. Bagaimana jika kita menginginkan gambaran kota yang lebih detail, termasuk jumlah penduduk, kode pos, data demografi, dll? Menjelaskan subdimensi lain – misalnya, toko , wilayah , negara bagian dan negara – dengan lebih banyak atribut akan mengubah dim_store tabel dimensi menjadi satu tabel besar dengan banyak redundansi.
Jika Anda menggunakan alat yang memerlukan skema kepingan salju di latar belakang. (Untungnya, sebagian besar alat modern mendukung skema dan bahkan skema galaksi.)

Pertimbangkan untuk menggunakan skema bintang :

Di data mart. Data mart adalah bagian dari data yang diambil dari gudang data pusat. Mereka biasanya dibuat untuk departemen yang berbeda dan bahkan tidak berisi semua data riwayat. Dalam pengaturan ini, menghemat ruang penyimpanan bukanlah prioritas.

Di sisi lain, skema bintang memang menyederhanakan analisis. Ini bukan hanya tentang efisiensi kueri tetapi juga tentang menyederhanakan tindakan di masa mendatang untuk pengguna bisnis. Mereka mungkin memahami basis data dan tahu cara menulis kueri, tetapi mengapa memperumit masalah dan menyertakan lebih banyak gabungan jika kita dapat menghindarinya? Pengguna bisnis dapat memiliki kueri template yang menggabungkan tabel fakta dengan semua tabel dimensi. Kemudian mereka hanya perlu menambahkan pilihan dan pengelompokan yang sesuai. (Pendekatan ini mirip dengan tabel pivot Excel.)
Jika Anda menggunakan alat yang memerlukan skema bintang di latar belakang. (Sekali lagi, ini biasanya tidak menjadi masalah.)

Baik skema bintang dan skema kepingan salju adalah model relasional yang digunakan untuk mengatur gudang data dan/atau data mart. Tidak peduli seberapa mirip mereka, mereka menunjukkan dua pendekatan yang berbeda dan memiliki kelebihan dan kekurangannya sendiri. Secara pribadi, saya akan menggunakan skema kepingan salju saat menerapkan gudang data (untuk menghemat ruang penyimpanan) dan dengan skema bintang untuk data mart (untuk membuat hidup lebih mudah bagi pengguna bisnis).