Skema Snowflake vs. Skema Bintang

Ketika memilih skema database untuk data warehouse, kepingan salju dan skema bintang cenderung menjadi pilihan populer. Perbandingan ini membahas kesesuaian skema bintang vs kepingan salju dalam berbagai skenario dan karakteristiknya.

Grafik perbandingan

Skema perbandingan Snowflake versus bagan Skema Bintang
Skema Snowflake Skema Bintang
Kemudahan perawatan / perubahanTidak ada redundansi, sehingga skema kepingan salju lebih mudah dipelihara dan diubah.Memiliki data yang berlebihan dan karenanya kurang mudah untuk dipelihara / diubah
Kemudahan penggunaanPertanyaan yang lebih kompleks dan karenanya kurang mudah dipahamiKompleksitas kueri yang lebih rendah dan mudah dimengerti
Performa PermintaanLebih banyak kunci asing dan karenanya waktu eksekusi permintaan lebih lama (lebih lambat)Jumlah kunci asing lebih sedikit dan karenanya waktu eksekusi kueri lebih pendek (lebih cepat)
Jenis DatawarehouseBaik digunakan untuk inti datawarehouse untuk menyederhanakan hubungan yang kompleks (banyak: banyak)Baik untuk data dengan hubungan sederhana (1: 1 atau 1: banyak)
BergabungJumlah Bergabung yang lebih tinggiLebih sedikit Bergabung
Tabel dimensiSkema kepingan salju mungkin memiliki lebih dari satu tabel dimensi untuk setiap dimensi.Skema bintang hanya berisi tabel dimensi tunggal untuk setiap dimensi.
Kapan harus digunakanKetika tabel dimensi ukurannya relatif besar, kepingan salju lebih baik karena mengurangi ruang.Ketika tabel dimensi mengandung lebih sedikit jumlah baris, kita dapat memilih skema Bintang.
Normalisasi / De-NormalisasiTabel Dimensi dalam bentuk Normalisasi tetapi Tabel Fakta dalam bentuk De-NormalisasiTabel Dimensi dan Fakta keduanya dalam bentuk De-Normalisasi
Model dataPendekatan dari bawah ke atasPendekatan atas ke bawah

Contohnya

Pertimbangkan database untuk pengecer yang memiliki banyak toko, dengan masing-masing toko menjual banyak produk dalam banyak kategori produk dan berbagai merek. Gudang data atau data mart untuk pengecer seperti itu perlu memberikan kemampuan kepada analis untuk menjalankan laporan penjualan yang dikelompokkan berdasarkan toko, tanggal (atau bulan, kuartal atau tahun), atau kategori produk atau merek.

Contoh Skema Bintang

Jika data mart ini menggunakan skema bintang, itu akan terlihat sebagai berikut:

Contoh skema Bintang

Tabel fakta akan menjadi catatan transaksi penjualan, sementara ada tabel dimensi untuk tanggal, toko dan produk. Tabel dimensi masing-masing terhubung ke tabel fakta melalui kunci utama mereka, yang merupakan kunci asing untuk tabel fakta. Misalnya, alih-alih menyimpan tanggal transaksi aktual dalam baris tabel fakta, date_id disimpan. Date_id ini sesuai dengan baris unik di tabel Dim_Date, dan baris itu juga menyimpan atribut lain dari tanggal yang diperlukan untuk pengelompokan dalam laporan. mis. hari dalam seminggu, bulan, kuartal tahun dan seterusnya. Data didenormalisasi untuk pelaporan yang lebih mudah.

Berikut adalah bagaimana orang akan mendapatkan laporan jumlah televisi yang dijual berdasarkan merek dan negara dengan bantuan gabungan batin.

Contoh Skema Snowflake

Skenario yang sama juga dapat menggunakan skema kepingan salju, dalam hal ini akan disusun sebagai berikut:

Contoh skema kepingan salju (klik untuk memperbesar)

Perbedaan utama, jika dibandingkan dengan skema bintang, adalah bahwa data dalam tabel dimensi lebih normal. Misalnya, alih-alih menyimpan bulan, kuartal, dan hari dalam seminggu di setiap baris tabel Dim_Date, ini lebih lanjut dibagi menjadi tabel dimensi mereka sendiri. Demikian pula untuk tabel Dim_Store, negara bagian dan negara adalah atribut geografis yang satu langkah dihapus - alih-alih disimpan dalam tabel Dim_Store, mereka sekarang disimpan dalam tabel Dim_Geography yang terpisah.

Laporan yang sama - jumlah televisi yang dijual oleh negara dan merek - sekarang sedikit lebih rumit daripada dalam skema bintang:

Permintaan SQL untuk mendapatkan jumlah produk yang dijual oleh negara dan merek, ketika database menggunakan skema kepingan salju.

Artikel Terkait