Saat memilih skema basis data untuk gudang data, kepingan salju dan skema bintang cenderung menjadi pilihan populer. Perbandingan ini membahas kesesuaian skema bintang vs kepingan salju dalam berbagai skenario dan karakteristiknya.
Skema Snowflake | Skema Bintang | |
---|---|---|
Kemudahan perawatan / perubahan | Tidak ada redundansi, sehingga skema kepingan salju lebih mudah dipelihara dan diubah. | Memiliki data yang berlebihan dan karenanya kurang mudah untuk dipelihara / diubah |
Kemudahan penggunaan | Pertanyaan yang lebih kompleks dan karenanya kurang mudah dipahami | Kompleksitas kueri yang lebih rendah dan mudah dimengerti |
Performa Permintaan | Lebih 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 Datawarehouse | Baik digunakan untuk inti datawarehouse untuk menyederhanakan hubungan yang kompleks (banyak: banyak) | Baik untuk data dengan hubungan sederhana (1: 1 atau 1: banyak) |
Bergabung | Jumlah Bergabung yang lebih tinggi | Lebih sedikit Bergabung |
Tabel dimensi | Skema kepingan salju mungkin memiliki lebih dari satu tabel dimensi untuk setiap dimensi. | Skema bintang hanya berisi tabel dimensi tunggal untuk setiap dimensi. |
Kapan harus digunakan | Ketika tabel dimensi ukurannya relatif besar, snowflaking lebih baik karena mengurangi ruang. | Ketika tabel dimensi mengandung lebih sedikit jumlah baris, kita dapat memilih skema Bintang. |
Normalisasi / De-Normalisasi | Tabel Dimensi dalam bentuk Normalisasi tetapi Tabel Fakta dalam bentuk De-Normalisasi | Tabel Dimensi dan Fakta keduanya dalam bentuk De-Normalisasi |
Model data | Pendekatan dari bawah ke atas | Pendekatan atas ke bawah |
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 analis kemampuan untuk menjalankan laporan penjualan yang dikelompokkan berdasarkan toko, tanggal (atau bulan, kuartal atau tahun), atau kategori produk atau merek.
Jika data mart ini menggunakan skema bintang, itu akan terlihat sebagai berikut:
Contoh skema BintangTabel 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.
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 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.