Kar Tanesi Şeması ile Yıldız Şeması: Boyutları Düzleştirmek mi, Normalleştirmek mi?

Ortak zemin: olgu tablosu ve onu çevreleyen boyutlar

Her iki şema da boyutsal modellemenin ürünüdür. Ortada olayları ve ölçüleri tutan bir olgu tablosu bulunur: satış satırları, sipariş kalemleri, stok hareketleri. Çevresinde ise bu olayları anlamlandıran boyut tabloları yer alır: ürün, müşteri, mağaza, tarih. Raporlar boyutlardan filtreler, olgu tablosundan toplar.

İki şema arasındaki fark, boyutların nasıl saklandığıdır. Yıldız şemada her iş varlığı tek bir boyut tablosudur; ürünün adı, alt kategorisi ve kategorisi aynı satırda durur. Kar tanesi şemada ise bu hiyerarşi normalleştirilir: ürün tablosu alt kategori tablosuna, alt kategori tablosu da kategori tablosuna anahtarla bağlanır. Diyagramda tablolar olgu tablosundan dışarı doğru dallandığı için kar tanesine benzeyen bir şekil oluşur.

Kimball Group'un tanımına göre düzleştirilmiş bir boyut tablosu, kar tanesi biçimindeki boyutla tam olarak aynı bilgiyi içerir. Yani seçim bilgi kaybıyla ilgili değildir; sorgu yolu, kullanılabilirlik ve bakım yükü arasındaki dengeyle ilgilidir.

Ölçüt ölçüt farklar

• Ölçüt: Boyutun yapısı. Yıldız şema: her varlık tek, düzleştirilmiş bir tablo. / Kar tanesi şema: hiyerarşi düzeyleri ayrı tablolarda.
• Ölçüt: Veri tekrarı. Yıldız şema: kategori adı gibi değerler her ürün satırında tekrarlanır. / Kar tanesi şema: her değer bir kez saklanır.
• Ölçüt: Sorgu yolu. Yıldız şema: filtre boyuttan olgu tablosuna tek adımda ulaşır. / Kar tanesi şema: filtre birden fazla ilişki üzerinden yürür.
• Ölçüt: Rapor yazarının deneyimi. Yıldız şema: alan listesinde az ve anlamlı tablo. / Kar tanesi şema: çoğu yalnızca bir iki sütun taşıyan çok sayıda küçük tablo.
• Ölçüt: Hiyerarşi tanımı. Yıldız şema: kategori, alt kategori ve ürün aynı tabloda olduğu için tek hiyerarşide toplanabilir. / Kar tanesi şema: Power BI'da birden fazla tablodaki sütunlardan hiyerarşi kurulamaz.
• Ölçüt: Güncelleme. Yıldız şema: bir kategori adı değişince çok sayıda satır güncellenir, ama bunu yükleme süreci üstlenir. / Kar tanesi şema: değişiklik tek satırda yapılır.

Kimball Group kar tanesi biçimini iki gerekçeyle önermez: iş kullanıcılarının bu yapıyı anlaması ve içinde gezinmesi zordur, ayrıca sorgu performansını olumsuz etkileyebilir. Microsoft'un Power BI rehberi de benzer bir sonuca varır: genel olarak tek bir model tablosunun yararları, birden fazla tablonun yararlarından ağır basar.

Power BI gibi araçlarda farkın somut karşılığı

Microsoft'un yıldız şema rehberi, kar tanesi tasarımını modele taşımanın sonuçlarını açıkça sıralar. Model daha fazla tablo yükler; bu tablolar ilişkiler için ek anahtar sütunları taşımak zorundadır ve model boyutu büyüyebilir. Filtrelerin daha uzun ilişki zincirlerinden geçmesi gerekir; bu, tek tabloya uygulanan filtreden daha az verimli olabilir. Alan listesinde rapor yazarına daha çok tablo görünür ve yalnız bir iki sütundan oluşan tablolar kafa karıştırır. Son olarak birden fazla tablodaki sütunlardan tek bir hiyerarşi kurulamaz.

Tek tabloya birleştirmenin bedeli de aynı rehberde yazar: tekrarlanan veri nedeniyle özellikle büyük boyut tablolarında depolama boyutu artabilir. Bu yüzden karar her model için yeniden tartılır; varsayılan ise tek tablodur.

Pratikte iş akışı şöyledir: kaynak sistem ürün, alt kategori ve kategori tablolarını ayrı tutuyorsa, Power Query ya da veri ambarının yükleme süreci bu tabloları birleştirip tek bir ürün boyutu üretir. Rapor yazarı kategori, alt kategori ve ürün sütunlarını aynı tabloda görür ve bunlarla bir hiyerarşi kurar.

Örnek senaryo: perakende satış modeli

Bir perakende şirketinin kaynak sisteminde ürün bilgisi normalleştirilmiş durumdadır: ürünler alt kategorilere, alt kategoriler kategorilere, kategoriler de departmanlara bağlıdır. Mağaza bilgisi de benzer biçimde mağaza, ilçe, il ve bölge tablolarına bölünmüştür.

Modeli kaynakla aynı biçimde kurmak, satış olgu tablosunun çevresinde çok sayıda küçük tablo demektir. Bölge yöneticisi kategori bazında satış görmek istediğinde filtre önce bölgeden ile, ilden mağazaya, mağazadan satışa; diğer yanda departmandan kategoriye, kategoriden ürüne, üründen satışa yürür. Alan listesinde de iki boyut yerine çok sayıda tablo görünür.

Yıldız şemada ise yükleme sırasında ürün hiyerarşisi tek bir ürün boyutuna, mağaza hiyerarşisi de tek bir mağaza boyutuna düzleştirilir. Bölge yöneticisi aynı soruyu iki boyut ve bir olgu tablosuyla yanıtlar; departmandan ürüne inen hiyerarşi tek tabloda tanımlanır. Kategori adı değiştiğinde güncellemeyi yükleme süreci yapar; rapor tarafı bundan etkilenmez.

Hangi durumda hangisi?

Yıldız şema şu durumlarda doğal tercihtir: • Model, iş kullanıcılarının kendi raporlarını hazırlayacağı bir anlamsal katmandır. • Boyut tabloları olgu tablolarına göre küçüktür ve tekrar eden değerlerin maliyeti düşüktür. • Hiyerarşide yukarıdan aşağı inme (kategori, alt kategori, ürün) raporların temel ihtiyacıdır.

Kar tanesi biçimine şu durumlarda gerekçeyle başvurulabilir: • Büyük bir boyut içinde ayrı sahibi olan ve sık değişen bir alt yapı vardır ve bu yapının ayrı tabloda yönetilmesi yükleme sürecini belirgin biçimde sadeleştirir. • Aynı alt boyut birden fazla boyut tarafından paylaşılır. Kimball yaklaşımı bunu outrigger boyut olarak adlandırır ve idareli kullanılmasını, çoğu durumda ise boyutlar arası ilişkinin olgu tablosuna taşınmasını önerir. • Fiziksel veri ambarında depolama ve bütünlük kaygısıyla normalleştirilmiş bir katman tutulur; ancak raporlama katmanı bunun üstüne düzleştirilmiş görünümlerle kurulur.

Kısacası soru 'hangisi daha doğru' değil, 'normalleştirme hangi katmanda yapılmalı' sorusudur. Normalleştirme kaynakta ve hazırlık katmanında kalabilir; kullanıcının dokunduğu katman yıldız şema olarak tasarlanır.

Sık yapılan hatalar

• Kaynak sistemin yapısını modele aynen taşımak. İşlemsel sistemler normalleştirilmiştir, çünkü amaçları kayıt eklemek ve güncellemektir. Analitik modelin amacı ise filtrelemek ve toplamaktır; yapının da buna göre kurulması gerekir.
• Depolama tasarrufunu tek ölçüt yapmak. Boyut tabloları genellikle olgu tablolarından çok daha küçüktür; tekrarlanan kategori adlarının maliyeti, kullanıcının yaşadığı karmaşanın yanında küçük kalır.
• Bir iki sütunluk tabloları modelde bırakmak. Yalnız kategori adını tutan bir tablo, alan listesinde ayrı bir öğe olarak görünür ve rapor yazarına hangi tablodan filtre alacağını düşündürür.
• Boyutlar arasındaki ilişkiyi boyut tablolarında zincirlemek. Müşteri ile satış temsilcisi gibi iki varlığın ilişkisi, çoğu durumda olgu tablosunda iki ayrı anahtar olarak tutulmalıdır.
• Snowflake veri platformuyla karıştırmak. Kar tanesi şeması bir modelleme biçimidir; aynı adı taşıyan bulut veri ambarı ürünüyle bir ilgisi yoktur; o platformda da her iki şema kurulabilir ve aynı seçim kararı geçerlidir.

Mindset programlarında bu karar nerede çalışılır?

Bu kıyas, Power BI ile rapor geliştiren analistler ve veri ambarı tasarlayan veri mühendisleri için gündelik bir karardır. Star Schema ve Snowflake Schema Tasarımı eğitimi şema yapılarını, performans karşılaştırmasını, bakım ve depolama ölçütlerini ve sunum katmanını doğrudan ele alır. Power BI Veri Modelleme eğitimi yıldız şema ve boyut modellemesini Power Query mimarisiyle birlikte işler; Boyutsal Modelleme ve Kimball Metodolojisi ise olgu ve boyut tablolarının tasarımını ve tarihsel takibi derinleştirir.