Yıldız Şema Diyagramı: Olgu ve Boyut Tabloları, Satış Örneğiyle

Bir ürün yöneticisi, geçen çeyreğin kategori ve bölge bazında gelirini bir önceki yılın aynı çeyreğiyle karşılaştırmanızı istiyor. Sipariş veritabanında bu, beş tabloyu birleştirmek, takvimi anında üretmek ve müşterilerin bölgeler arasında taşındığını hatırlamak demek. Her yeni soru yeni birleştirmeler gerektirir ve iki analist iki farklı sayı bulur.

Yıldız şema bunu, veriyi tek bir iş süreci etrafında yeniden biçimlendirerek çözer: ortada ölçümlerden oluşan bir olgu tablosu, çevresinde onları tanımlayan boyut tabloları. Bu yazı, tanecikten SQL'e kadar bir satış yıldız şemasını adım adım tasarlıyor; yavaş değişen boyutları, yıldız ve kar tanesi şema karşılaştırmasını ve sütun tabanlı veri ambarlarını da kapsıyor.

Yıldız şema nedir

Yıldız şemada iki tür tablo vardır:

• Olgu tabloları bir iş olayının ölçümlerini kaydeder, örneğin bir sipariş satırını: boyutlara giden yabancı anahtarlar ve sayısal ölçüler. Dar ve uzundurlar.
• Boyut tabloları bağlamı tutar: kim, ne, nerede ve ne zaman. Kategori veya bölge gibi metin niteliklerinden oluşan geniş, düz ve kısa tablolardır.

Bu tekniklerin çoğunu adlandıran Kimball Group, yıldız şemayı birincil ve yabancı anahtarlarla boyut tablolarına bağlanan olgu tabloları olarak tanımlar. Microsoft'un Power BI rehberi cazibesini basitçe özetler: boyut tabloları filtrelemeyi ve gruplamayı, olgu tabloları özetlemeyi sağlar.

Dört adımda tasarlayın

Kimball'ın dört adımlı boyutsal tasarım süreci sırayla verilen dört karardır:

1. İş sürecini seçin: mağazalarda ve web mağazasında perakende satış.
2. Taneciği belirleyin: sipariş satırı başına bir satır, yani bir siparişteki bir ürün. Kimball taneciği bağlayıcı bir sözleşme olarak adlandırır ve herhangi bir boyut ya da olgudan önce belirlenmesini ister.
3. Boyutları belirleyin: tarih, ürün, mağaza, müşteri ve promosyon; her biri sipariş satırı başına tek bir değere sahiptir.
4. Olguları belirleyin: adet, birim fiyat, indirim, net tutar ve maliyet; hepsi bu tanecikte doğrudur.

Atomik taneciğle, yani kaynağın yakaladığı en düşük düzeyle başlayın; özetler atomik satırlardan üretilir, asla tersi olmaz. Taneciklileri asla karıştırmayın: sipariş başına alınan ama her satırda saklanan bir kargo ücreti satır sayısı kadar sayılır. Kimball'ın önerdiği gibi onu bir iş kuralıyla satırlara dağıtın ya da ona ayrı bir olgu tablosu verin.

Örnek tablolar

Boyutlar bilerek düz tutulmuştur: dim_product marka, alt kategori ve kategoriyi tek satırda taşır, dim_store ise web mağazasını channel = 'online' olan bir mağaza daha olarak ele alır. order_number dejenere bir boyuttur: sipariş başlığının bağlamı diğer boyutlarda yaşar, geriye yalnızca numara kalır ve sepetleri gruplamak için yine de işe yarar.

Birim fiyat klasik tuzaktır: satırlar arasında toplandığında anlamsızdır, bunun yerine toplanabilir parçaları bölün, örneğin SUM(net_amount) / SUM(quantity) gibi.

Vekil anahtarlar ve tarih boyutu

Her boyuta bir vekil anahtar verilir: 1'den başlayarak sırayla atanan, anlamsız bir tamsayı. Çünkü geçmişi izleyen bir boyutta doğal anahtar başına birden fazla satır bulunur ve kaynaklar anahtarlar konusunda sıklıkla anlaşamaz. Doğal anahtarı (sku, store_code, customer_id) satırları kaynağa kadar izlemek için nitelik olarak saklayın.

Tarih boyutu istisnadır: kararlı ve öngörülebilirdir, bu yüzden anahtarı anlamlı olabilir, örneğin 20261120; bu bölümlemeye de yardımcı olur. Anahtar üzerinde aritmetik yapmak yerine nitelikleri (year, quarter, is_holiday) üzerinden filtreleyin ve gruplayın. Yirmi yıl yalnızca yaklaşık 7.305 satırdır (20 × 365,25).

Olgu yabancı anahtarları asla null olmamalıdır: null bir anahtar satırı iç birleştirmelerden düşürür ve toplamlar sessizce küçülür. Bilinmeyen veya uygulanamayan değerler için varsayılan boyut satırları kullanın; burada promotion_key 0 «Promosyon yok» anlamına gelir.

Yavaş değişen boyutlar

Yavaş değişen boyut (SCD) tipi, bir nitelik değiştikten sonra raporların ne göstereceğini belirler:

Kimball'ın 4 ile 7 arasındaki tipleri mini boyutlar ve bunların melezlerini ekler.

Tip 2 işin yükünü taşıyan yöntemdir. C-1042 numaralı müşteri 20 Kasım 2026'da Austin'den Denver'a taşınıyor:

Önceki satışlar 1001 anahtarını korur ve Austin'de kalır; sonraki satışlar 2417'yi alır. Olgu yüklemesi, aralığı sipariş tarihini içeren satırı seçer (valid_from <= order_date < valid_to). Kimball'ın tip 2 tanımı en azından bir geçerlilik tarihi, bir bitiş tarihi ve bir geçerli satır göstergesi ister; null yerine çok ileri bir valid_to kullanmak aralık filtrelerini basit tutar. dbt snapshot'ları tip 2'yi sizin yerinize uygular.

Tüm geçmişi güncel şehre göre raporlamak için aynı customer_id ile güncel satıra birleştirin. Değişiklik verisi yakalama (CDC) tip 2'yi iyi besler, çünkü her güncelleme bir olay olarak gelir; bkz. change data capture diyagramı.

Yıldız şema, kar tanesi şema ve tek büyük tablo

Kimball kar tanesi boyutlara karşı önerir: iş kullanıcılarının gezinmesi daha zordur, sorgu performansına zarar verebilir ve düzleştirilmiş bir boyut tamamen aynı bilgiyi tutar. Power BI rehberi de aynı fikirdedir.

Tek büyük tablo birleştirme gerektirmez ve sütunlu sıkıştırma tekrar eden değerleri ucuz tutar. Bedeli bakımdır: düzeltmeler yeniden yazmaya, yeni nitelikler yeniden oluşturmaya dönüşür, bu yüzden onu yıldızdan üretin.

Modelin kolaylaştırdığı bir sorgu

SELECT d.year_month,
       p.category,
       SUM(f.net_amount)                                AS revenue,
       SUM(f.net_amount - f.cost_amount)                AS gross_margin,
       SUM(f.net_amount) / NULLIF(SUM(f.quantity), 0)   AS avg_selling_price
FROM fact_sales AS f
JOIN dim_date    AS d ON d.date_key    = f.date_key
JOIN dim_product AS p ON p.product_key = f.product_key
JOIN dim_store   AS s ON s.store_key   = f.store_key
WHERE d.year = 2026
  AND s.channel = 'online'
GROUP BY d.year_month, p.category
ORDER BY d.year_month, revenue DESC;

Her birleştirme olgudan bir boyuta tek bir tamsayı anahtar üzerinden gider; filtreler boyut niteliklerinde, toplamlar olgu sütunlarındadır. Yeni bir soru WHERE ve GROUP BY kısmını değiştirir, birleştirmeleri değil; BI araçlarının bu tür sorguları güvenilir biçimde üretmesinin nedeni budur.

Sütun tabanlı veri ambarlarında performans

Sütun tabanlı ambarlar yalnızca sorgunun kullandığı sütunları okur, bu da dar bir olgu tablosuna uyar; küçük boyutlar da ucuza birleşir: broadcast birleştirmede BigQuery küçük tabloyu her çalışana gönderir. INT64 anahtarlar ve adetler 8, NUMERIC tutarlar 16 mantıksal bayt olduğunda, yukarıdaki sorgu olgudan sipariş satırı başına 64 bayt okur; tablo ne kadar geniş olursa olsun 500 milyon satır için yaklaşık 32 GB eder.

• Tarihe göre budayın. Olguyu date_key üzerinde bölümleyin, kümeleyin veya sıralayın. BigQuery, yalnızca bölümleme sütununun kendisinde sabit bir filtre olduğunda bölümleri budar; bu yüzden büyük taramalar yalnızca dim_date.year üzerinde değil, date_key üzerinde de sabitlerle filtrelemelidir.
• Anahtarları, zorunlu kılınmasa bile bildirin. BigQuery, NOT ENFORCED olarak bildirilen birincil ve yabancı anahtarları birleştirmeleri ortadan kaldırmak ve yeniden sıralamak için kullanır; Snowflake ise RELY işaretli kısıtlar için birleştirmeleri ortadan kaldırır. İkisi de veriyi denetlemez ve ihlal edilen kısıtlar yanlış sonuç döndürebilir, bu yüzden anahtarları pipeline'da test edin.
• Redshift'te birlikte konumlandırın. Redshift'in rehberi, olguyu ve bir boyutu ortak anahtarları üzerinde dağıtmayı, diğer bazı boyutlar için ALL dağıtımını kullanmayı ya da seçimi AUTO'ya bırakmayı önerir.

Yıldız şemalar genellikle bir medallion mimarisinin gold katmanında yaşar; veri pipeline mimarisi diyagramı verinin oraya nasıl ulaştığını, ETL ve ELT ise dönüşümlerin nerede çalıştığını gösterir.

Satış yıldız şeması diyagramı

Nasıl okunur:

• Ortadaki fact_sales beş yabancı anahtarı, dejenere order_number'ı, line_number'ı ve beş ölçüyü tutar.
• Her çizgide karga ayağı: bir uçta sıfır veya çok olgu satırı, diğer uçta tam olarak bir boyut satırı. Etiketler birleştirme anahtarlarını adlandırır.
• Camgöbeği kartlar boyutlardır; dim_date üstte, diğerleri solda ve sağda.
• Kehribar kart, dim_customer, geçmişi SCD tip 2 olarak tutar.
• Markdown bloğu taneciği ve hangi ölçüleri toplayabileceğinizi belirtir.

Yıldız şema diyagramlarını net çizmek

• Taneciği diyagrama yazın. İnceleyenler önce bunu sorar ve yanlış okunan tanecik çift saymaya yol açar.
• Olguyu ortaya, her boyutu bir adım uzağa koyun. İki boyut arasındaki bir çizgi kar tanesidir; bunu bilerek çizin ya da düzleştirin.
• Anahtar rollerini işaretleyin: PK, FK, doğal anahtarlar için NK ve dejenere boyutlar için DD.
• SCD tipini gösterin: geçmiş tutan boyutlarda.
• Dışarıda bırakın: yükleme işlerini, staging tablolarını ve kimsenin filtrelemediği sütunları.
• Diyagram başına bir iş süreci çizin. Olgu tabloları uyumlu boyutları paylaştığında bir bus matrisi ekleyin: satırlarda süreçler, sütunlarda boyutlar.

Karga ayağı gösterimi için ER diyagramı örneğine bakın.

Archboard'da oluşturun

1. Google veya GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Tablolar varsa, ilk taslak için CREATE TABLE ifadelerini SQL'den ER diyagramına aracına, DBML'i ise DBML'den ER diyagramına aracına yapıştırın.
3. Varlık-İlişki pack'inden fact_sales adlı bir Varlık ekleyin, her satıra bir nitelik: FK işaretli beş anahtar, DD işaretli order_number, line_number, ardından ölçüler. Mavi vurgu verin.
4. Beş Varlık node'u daha ekleyin: olgunun üstüne dim_date, sola dim_customer ve dim_promotion, sağa dim_product ve dim_store. Vekil anahtarları PK, doğal anahtarları NK olarak işaretleyin; camgöbeği vurgular kullanın, dim_customer için kehribar.
5. fact_sales'i her boyuta karga ayağıyla bağlayın: olguda sıfır veya çok, boyutta tam olarak bir; her çizgiyi anahtarıyla etiketleyin.
6. Temel pack'inden Metin notları ekleyin: anahtar açıklaması, SCD tip 2 kuralı, akıllı tarih anahtarı, varsayılan promosyon satırı ve web mağazası.
7. Olgunun altına Temel pack'inden, taneciği ve toplanabilirlik kurallarını içeren bir Markdown bloğu ekleyin.

Örnek 7 diagram node kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Basitçe yıldız şema nedir? Satış tutarları gibi ölçümlerden oluşan merkezî bir olgu tablosu ve onu tanımlayan tarih, ürün ve müşteri gibi boyut tabloları. Çizildiğinde yıldıza benzer.

Olgu tablosu ile boyut tablosu arasındaki fark nedir? Olgu tablosu, belirlenmiş bir tanecikteki olayların ölçümlerini ve yabancı anahtarları saklar. Boyut tablosu, kategori veya bölge gibi filtrelediğiniz ve gruplayıp topladığınız nitelikleri saklar.

Yıldız şema ile kar tanesi şema arasındaki fark nedir? Yıldız her boyutu tek bir düz tabloda tutar; kar tanesi onu ürün, alt kategori ve kategori gibi zincirlere normalleştirir. Yıldızlar daha az birleştirme gerektirir ve kullanımı daha kolaydır.

Yıldız şema normalleştirilmiş midir? Tam olarak değil. Boyut tabloları bilerek denormalize edilir; kategori adları gibi değerler her ürün satırında tekrarlanır, olgu tablosu ise dar kalır.

Sütun tabanlı veri ambarlarında yıldız şemalar hâlâ önemli mi? Evet. Geniş tablolar sütunlu motorlarda ucuz taranır, ancak yıldız yine de bir niteliği düzeltmek için tek bir yer, yavaş değişen boyutlarla geçmiş ve raporlar arasında tutarlı yanıtlar sağlar.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.