Skema Snowflake vs. Skema bintang

Semasa memilih skema pangkalan data untuk gudang data, Snowflake dan Skema bintang cenderung menjadi pilihan yang popular. Perbandingan ini membincangkan kesesuaian bintang vs. Skema Snowflake dalam senario yang berbeza dan ciri -ciri mereka.

Carta Perbandingan

Skema Snowflake berbanding Carta Perbandingan Skema Bintang

	Skema Snowflake	Skema bintang
Kemudahan penyelenggaraan / perubahan	Tidak ada kelebihan, jadi skema salji lebih mudah untuk mengekalkan dan berubah.	Mempunyai data yang berlebihan dan oleh itu kurang mudah untuk mengekalkan/menukar
Kemudahan penggunaan	Pertanyaan yang lebih kompleks dan oleh itu kurang mudah difahami	Kerumitan pertanyaan yang lebih rendah dan senang difahami
Prestasi pertanyaan	Lebih banyak kunci asing dan oleh itu masa pelaksanaan pertanyaan yang lebih lama (lebih perlahan)	Kurang bilangan kunci asing dan oleh itu masa pelaksanaan pertanyaan yang lebih pendek (lebih cepat)
Jenis DataWarehouse	Baik untuk digunakan untuk DataWarehouse Core untuk memudahkan hubungan kompleks (banyak: banyak)	Bagus untuk Datamarts dengan hubungan mudah (1: 1 atau 1: banyak)
Bergabung	Jumlah gabungan yang lebih tinggi	Lebih kurang menyertai
Jadual dimensi	Skema Snowflake mungkin mempunyai lebih daripada satu jadual dimensi untuk setiap dimensi.	Skema bintang hanya mengandungi jadual dimensi tunggal untuk setiap dimensi.
Bila hendak digunakan	Apabila jadual dimensi agak besar saiznya, snowflaking lebih baik kerana ia mengurangkan ruang.	Apabila jadual dimensi mengandungi bilangan baris yang kurang, kita boleh memilih skema bintang.
Normalisasi/ de-normalisasi	Jadual dimensi dalam bentuk normal tetapi jadual fakta dalam bentuk yang tidak normal	Kedua-dua dimensi dan jadual fakta berada dalam bentuk yang tidak normal
Model data	Pendekatan bawah	Pendekatan atas

Contoh

Pertimbangkan pangkalan data untuk peruncit yang mempunyai banyak kedai, dengan setiap kedai menjual banyak produk dalam banyak kategori produk dan pelbagai jenama. Gudang Data atau Data Mart untuk peruncit sedemikian perlu menyediakan penganalisis keupayaan untuk menjalankan laporan jualan yang dikumpulkan oleh kedai, tarikh (atau bulan, suku atau tahun), atau kategori produk atau jenama.

Contoh skema bintang

Sekiranya data ini menggunakan skema bintang, ia akan kelihatan seperti berikut:

Contoh skema bintang

Jadual Fakta akan menjadi rekod urus niaga jualan, sementara terdapat jadual dimensi untuk tarikh, kedai dan produk. Jadual dimensi masing -masing disambungkan ke jadual fakta melalui kunci utama mereka, yang merupakan kunci asing untuk jadual fakta. Contohnya, bukannya menyimpan tarikh urus niaga sebenar berturut -turut jadual fakta, date_id disimpan. Date_id ini sepadan dengan baris unik dalam jadual DIM_DATE, dan baris itu juga menyimpan atribut lain dari tarikh yang diperlukan untuk mengelompokkan dalam laporan. e.g., hari dalam seminggu, bulan, suku tahun dan sebagainya. Data disenarai untuk pelaporan yang lebih mudah.

Inilah bagaimana seseorang akan mendapat laporan bilangan televisyen yang dijual oleh jenama dan negara dengan bantuan gabungan dalaman.

Contoh skema salji

Senario yang sama juga boleh menggunakan skema salji salji, di mana ia akan disusun seperti berikut:

Contoh Skema Snowflake (klik untuk membesarkan)

Perbezaan utama, berbanding dengan skema bintang, ialah data dalam jadual dimensi lebih normal. Contohnya, bukannya menyimpan bulan, suku dan hari dalam setiap baris meja dim_date, ini akan dipecah lagi ke dalam jadual dimensi mereka sendiri. Begitu juga untuk jadual dim_store, keadaan dan negara adalah atribut geografi yang satu langkah dikeluarkan - bukannya disimpan dalam jadual dim_store, mereka kini disimpan dalam jadual dim_geografi berasingan yang berasingan.

Laporan yang sama - bilangan televisyen yang dijual oleh negara dan oleh jenama - kini sedikit lebih rumit daripada skema bintang:

Pertanyaan SQL untuk mendapatkan bilangan produk yang dijual mengikut negara dan jenama, apabila pangkalan data menggunakan skema salji salji.