Ralph Kimball-ın 1996-cı ildə yazdığı "The Data Warehouse Toolkit" kitabından bəri star schema analitik data modelinin qızıl standartı olub. Lakin müasir bulud platformalarının inkişafı ilə snowflake schema və hətta daha ekstremal modellər yenidən gündəmdədir. Qərar nəyə əsaslanmalıdır?
Star Schema
Mərkəzdə fact cədvəli (sales_fact), ətrafında denormalize dimension cədvəlləri (dim_customer, dim_product, dim_date). Hər ölçü bir cədvəldə toplanır; JOIN sayı minimuma enir. Üstünlüklər: sadəlik, performans, BI alətinin təbii formada sevdiyi quruluş.
sales_fact ←→ dim_customer ←→ dim_product ←→ dim_date ←→ dim_store
Snowflake Schema
Dimension-lar normalize edilir — dim_product → dim_category → dim_department kimi alt əlaqələr yaranır. Üstünlük: daha az saxlama yeri, asan baxım. Mənfi cəhət: JOIN sayı artır, sorğular mürəkkəbləşir, BI semantic modelləşdirmə daha ağır olur.
Müasir bulud perspektivi
Kolumnar saxlama (Snowflake, BigQuery, Synapse) əsrində denormalize cədvəl ölçüsü artıq əvvəlki qədər kritik deyil. 1 TB-lıq dim_customer kolumnar kompressiya ilə 50 GB-a düşə bilər. Deməli, "snowflake schema ilə yer qazanırıq" arqumenti zəifləyib.
Digər tərəfdən, GCP BigQuery və AWS Athena kimi platformalarda JOIN xərci hələ də vacibdir; bu platformalarda star schema daha qənaətli işləyir.
Praktiki bələdçi
- BI yönlü DWH (Power BI, Tableau, Qlik): star schema — təbii inteqrasiya, sabit performans.
- Data science + analitik hibrid: star, amma dimension daxilindəki iyerarxiyalar üçün kiçik bağlı cədvəllər (yüngül snowflake).
- Çox dinamik məhsul kataloqu (pərakəndə, e-ticarət): denormalize
dim_productgündəlik yenidən qurulmada performans cəzası yaradır; ya incremental rebuild, ya da snowflake. - Tənzimləyici hesabatları: snapshot fact + tarixli SCD Type 2 dimension (hər iki modelin üstündə).
Denormalize edilməli sahələr
- Tarix iyerarxiyaları (il/rüb/ay/gün): həmişə
dim_date-də denormalize. - Müştəri demoqrafiyası: çox zaman
dim_customer-ə daşınır. - Məhsul kateqoriya yolu: əgər 4+ səviyyə varsa, snowflake üstünlük qazana bilər.
One Big Table (OBT) yanaşması
Müasir ML pipeline-ları və bəzi self-service BI ssenariləri dimensional model əvəzinə tək geniş cədvəl seçir. JOIN yox, bütün kontekst tək sətirdə. Mənfi cəhət: baxım xərci çox yüksəkdir; dəyişikliklər bütün cədvələ yayılır. Tövsiyəmiz: OBT yalnız ML feature store üçündür; ümumi BI üçün dimensional model hələ də qalibdir.
