Power BI’da Hangi Veri Modeli: Yıldız Şeması (Star Schema) Vs Kar tanesi Şeması (Snowflake Schema)

Yıldız şeması (Star Schema) ve Kartanesi Şemsası (Snowflake Schema) veri ambarı dizaynında kullanılan iki farklı yaklaşımdır. Power BI’da rapor performansını etkileyen en önemli faktörler arasında yer alır. Power BI en iyi pratiklerinde her zaman yıldız şema kullanımı öneriliyor olsa da gerçek dünya senaryoları için her iki modeli de anlamak oldukça önemli.

Fact Table (Olgu Tablosu) ve Dimension Table (Boyut Tablosu)

Fact Table, bir veri modelinde gerçekleşen olaylarla ilgili sayısal verileri (satış miktarı, maliyet gibi) tutan bir tabloyu ifade eder. Bu tablo, genellikle yıldız veya kar tanesi şemalarında merkezde yer alır ve boyut tabloları ile ilişkilidir.

Boyut tablosu, bir veri modelinde olgu tablosundaki verileri kategorize eden ve daha detaylı analiz yapmayı sağlayan tablodur. Genellikle metinsel veriler içerir ve olgu tablosundaki sayısal verileri anlamlı bir bağlama oturtur. Ürünler, müşteriler, ülkeler, tarih tabloları boyut tablosuna örnektir.

Boyut tablosu, olgu tablosundaki ölçümlere (satış miktarı, maliyet gibi) farklı boyutlardan bakmak için kullanılan niteliksel bilgileri barındırır. Örneğin, bir satış olgusu için müşteri, ürün, tarih ve mağaza gibi boyutlar tanımlanabilir. Bu boyutlar sayesinde, hangi ürünün hangi müşteri tarafından hangi tarihte ve hangi mağazada satıldığı gibi sorulara cevap bulunabilir.

Yıldız Şema (Star Schema) nedir? 

İlişkisel veri ambarı yapılarında geniş kullanım alanı olan bu dizaynda, veri modelleyenler tabloları boyut (dimension) ve fact (olgu) tabloları olarak tasarlarlar. Modelde, boyut tabloları genelde tek katmanlıdır ve ortada yer alan tek olgu tablosuna bağlanırlar. Boyut tablolarındaki anahtar sütunlar (key columns), olgu tablosunun granül (detay) seviyesini belirler. 

Power BI’da veri modeli oluşturma aşamalarında boyut veya olgu tabloları seçimi yoktur. Bu kararı ilişkileri oluştururken ifade edip, tablolar arasında filtreleme davranışının oluşumuna da bu şekilde yön veririz. İyi tasarlanmış bir yıldız şemasında bir tablo, ya bir boyut ya da bir olgu tablosudur. Tek tabloda ikisi beraber kullanılmaz. Bazı tablolarda bu durum gözlendiğinde Power Query kullanarak hızlı bir şekilde tablolar ayrılabilir.

Star Schema dizaynında veri modelinde ilişkiler birden çoka (one-to-many) ya da tersi çoktan bire (many-to-one) olacak şekilde kurgulanır. İlişkinin 1 tarafı her zaman boyut tablosu iken çok (many) tarafı hep olgu tablosudur.

Kar Tanesi Şeması (Snowflake Schema) nedir?

Yıldız şemasında olduğu gibi, kar tanesi şemasında da olgu tablosu ve boyut tabloları bulunur. Ancak kar tanesi şemasında, boyut tabloları daha fazla ayrıntıya sahip olmak üzere alt boyutlara bölünebilir. Bu durum, daha karmaşık analizler yapmaya olanak tanır.

Örnek veri modelinde ürün kategorisi, ürün alt kategorisi ve ürün tabloları ayrı tablolar olarak many-to-one ilişki ağı ile satış tablosuna bağlanıyor. Basit raporlarda bu tür bir dizayn yerine boyut tablolarını birleştirerek tek hiyerarşik boyut haline getirmek ve yıldız şemasına dönüştürmek daha anlamlı olabilir. 

Yıldız Şema ve Kar Tanesi Şema Karşılaştırması:

 

Star Schema mı yoksa Snowflake Shema mı? Hangisini kullanmalı?

Bu sorunun cevabı gereksinimlere bağlı olarak değişiklik gösterir. Her firmaya, firmadaki departmana, kullanan pozisyona, ilgili kişiye, firma veri kültürüne ve daha birçok değişkene göre değerlendirmek gerekir.

Yıldız Şeması, basit yapısı, yüksek performansı ve kolay yönetimi sayesinde raporlama süreçlerinde sıklıkla tercih edilir. Özellikle satış gibi tek bir konuya odaklanan raporlar için ideal bir seçimdir.

Ancak işletmelerin karmaşıklığı arttıkça, tek bir şema ile tüm ihtiyaçları karşılamak zorlaşabilir. Farklı departmanların verilerini bir araya getirip analiz etmek isteyen şirketler için Yıldız Şeması her zaman yeterli olmayabilir. Bu gibi durumlarda, her iki şemanın avantaj ve dezavantajlarını değerlendirerek hibrit modeller oluşturmak daha uygun olacaktır.

Örneğin kontrol raporları için bir veri analisti ya da business analist satış, üretim gibi farklı departmanların kullandığı farklı kaynaklardan gelen bilgileri birleştirerek SQL veri modeline ekleyebilir, birden çok fact table kullanarak bu bilgilerin finans ekibinin verileriyle örtüşmesini denetleyebilir ve nakit akış projeksiyonu oluşturarak olası darboğazları önceden tespit edebilir. Böylelikle birbiriyle ilintili tüm bilgileri tek raporda otomatize edebilir, denetleyebilir ve analiz edebilir. Başka bir örnek de veri kültürüyle ilgili. Veri kültürü gelişmiş şirketlerde, çalışanların kendi analizlerini yapabilmeleri için daha esnek ve geniş veri modellerine ihtiyaç duyulur. Bu tür durumlarda, ad-hoc raporlamaya olanak tanıyan hibrit modeller tercih edilebilir.  

Sonuç olarak yıldız ve kar tanesi şemaları arasında doğru seçim yapmak, gereksinimler doğrultusunda optimum tercihi yapmakla ilgili. Veri hacmi, analiz derinliği, performans gereksinimleri ve gelecekteki büyüme planları vb. faktörler, en uygun şemanın belirlenmesinde önemli rol oynar. Hibrit modeller gibi daha karmaşık yapılar da, işletmelerin değişen ihtiyaçlarına daha iyi cevap verebilir.