Kısaca: Power BI yıldız şema, rapor verisini olayları tutan olgu (fact) tabloları ile bu olayları anlatan boyut (dimension) tablolarına ayıran veri modelidir. ERP’den gelen tek ve geniş satış tablosunu bu yapıya böldüğünüzde toplamlar tutarlı olur, filtreler doğru çalışır ve rapor hazırlayanlar alanları kolayca bulur. Microsoft da Power BI anlam modelleri için bu yaklaşımı önerir.
Birçok KOBİ’de Power BI’ın ilk sürümü şöyle doğar: ERP’den kırk sütunlu bir satış raporu Excel’e alınır, Power BI’a bağlanır ve üzerine grafikler eklenir. Satış hedefleri ya da stok bakiyeleri ikinci bir dosya olarak eklendiğinde sorunlar başlar: ürün filtresi bir grafiği süzer, diğerini süzmez, toplamlar tutmaz. Power BI dashboard yazımızda hangi göstergeleri izleyeceğinizi anlattık; bu yazı o göstergelerin altındaki veri modelini doğru kurmanız için.
İçindekiler
- Power BI yıldız şema nedir?
- Tek ve geniş bir ERP tablosu neden yetmez?
- ERP verisinden yıldız şemaya: 7 adım
- Kar tanesi şema mı, tek boyut tablosu mu?
- Sık yapılan 5 model hatası
- Kontrol listesi
- Özet
Power BI yıldız şema nedir?
Yıldız şema, ortada olayları kaydeden bir olgu tablosunun, çevresinde de bu olayı tarif eden boyut tablolarının bulunduğu ve tabloların bire çok ilişkilerle bağlandığı modelleme yaklaşımıdır.
Microsoft’un yıldız şema ve Power BI rehberine göre boyut tabloları ürün, kişi, yer ve zaman gibi iş varlıklarını tarif eder; olgu tabloları ise satış siparişi, stok bakiyesi veya döviz kuru gibi olayları ve gözlemleri saklar. ERP diliyle karşılaştırma şöyle:
| Özellik | Olgu tablosu | Boyut tablosu |
|---|---|---|
| Ne saklar? | Olaylar ve sayısal değerler (miktar, tutar) | Olayı tarif eden bilgiler (ad, grup, bölge) |
| ERP’den örnek | Fatura satırları, stok hareketleri, satış hedefleri | Stok kartı, cari kart, satış temsilcisi, depo, tarih |
| Satır sayısı | Çok satırlı, zamanla büyür | Görece az satırlı |
| Raporda görevi | Özetlenir (toplam, ortalama) | Filtreler ve gruplar |
| İlişkideki yeri | “Çok” tarafı | “Bir” tarafı |
Olgu tablosunun tanesi (grain), bir satırın neyi temsil ettiğidir: “fatura satırı başına bir satır” ya da “ay ve ürün başına bir hedef” gibi.
Tek ve geniş bir ERP tablosu neden yetmez?
ERP’den alınan rapor çıktıları genellikle denormalize olur: her satırda ürün adı, ürün grubu, müşteri adı, şehir ve temsilci tekrar eder. Microsoft bu tür dışa aktarımları Power Query ile ayrı olgu ve boyut tablolarına bölmeyi önerir.
Bunun nedeni, her rapor görselinin modele bir sorgu göndermesidir. Bu sorgular veriyi filtreler, gruplar ve özetler. Boyut tabloları filtreleme ve gruplamayı, olgu tabloları özetlemeyi üstlendiğinde aynı ürün tablosu hem satışı hem hedefi hem de stoğu birlikte süzer. Tek geniş tabloda ise her yeni veri kaynağı kendi ürün sütunlarıyla gelir ve filtreler birbirinden kopar.
ERP verisinden yıldız şemaya: 7 adım
- Soruları ve taneyi belirleyin. Raporun cevaplayacağı soruları yazın ve her olgu tablosu için bir satırın neyi temsil ettiğine karar verin. Bir tabloda tane tutarlı olmalıdır.
- Olgu tablolarını seçin. Satış fatura satırları, satın alma satırları, stok hareketleri ve satış hedefleri ayrı olgu tablolarıdır. Aylık hedefleri günlük satışlarla aynı tabloya koymayın.
- Boyut tablolarını çıkarın. Ürün, müşteri, satış temsilcisi ve depo için ERP kartlarından ayrı tablolar oluşturun. Rapor kullanıcısının filtreleyeceği alanlar (grup, marka, şehir, bölge) burada durur.
- Ayrı bir tarih tablosu kurun. Microsoft’a göre yıldız şemada en tutarlı bulunan tablo tarih boyutudur. Fatura, sipariş ve hedef tarihleri aynı takvim tablosuna bağlanır; yıl, ay ve çeyrek gibi alanlar buradan gelir.
- Anahtarları düzenleyin. Power BI ilişkileri, bir tablodaki tek bir benzersiz sütun üzerinden kurulur. Boyut tablosunda böyle bir sütun yoksa Power Query’de dizin sütunu (index column) ekleyin.
- İlişkileri bire çok kurun. Filtre boyut tablosundan olgu tablosuna doğru aksın. İki olgu tablosunu doğrudan birbirine bağlamayın; ortak boyutlar üzerinden buluşsunlar. Satır düzeyi güvenlik kuracaksanız rol filtrelerini de boyut tablolarına koymak bu yapıyla kolaylaşır; ayrıntısı Power BI satır düzeyi güvenlik yazımızda.
- Ölçüleri DAX ile açıkça yazın. Ciro, miktar ve kâr için açık ölçüler (explicit measures) oluşturun. Birim fiyat gibi toplanmaması gereken sütunları gizleyin. Kullanıcılar modele Excel’de Analiz Et (Analyze in Excel) ile bağlanacaksa açık ölçüler zorunludur.
Dönüşümü nerede yapmalı? Küçük ve orta hacimde Power Query yeterli olabilir. Veri hacmi büyükse veya müşteri ve temsilci geçmişini saklamanız gerekiyorsa Microsoft önce bir veri ambarı ve ETL süreci kurmayı önerir. Raporların canlı ERP veritabanına ağır sorgular göndermesi ERP ekranlarını da yavaşlatabilir; bu durumda Logo veritabanı yavaşladı kontrol listemize de bakın.
Kar tanesi şema mı, tek boyut tablosu mu?
Kar tanesi boyutu (snowflake), tek bir iş varlığının birbirine bağlı birkaç tabloya bölünmesidir: ürün, alt grup ve ana grup ayrı tablolarda durur. ERP’lerde bu yapı sık görülür.
Microsoft, Power BI’da bu tabloları tek bir boyut tablosunda birleştirmenin genellikle daha avantajlı olduğunu belirtir. Kar tanesi yapısını modele aynen taşırsanız:
- Daha fazla tablo yüklenir; depolama ve performans açısından daha az verimlidir.
- Filtreler daha uzun ilişki zincirlerinden geçer.
- Veri bölmesinde kullanıcıya daha çok tablo görünür ve model karmaşık hale gelir.
- Farklı tablolardaki sütunlardan tek bir hiyerarşi kuramazsınız.
Tek tabloda ise “ana grup, alt grup, ürün” hiyerarşisini kurup raporlarda detaya inebilirsiniz. Çok büyük boyut tablolarında tekrar eden veri model boyutunu artırabilir; kararı veri hacmine göre verin.
Sık yapılan 5 model hatası
- Her şeyi tek tabloda bırakmak: İkinci veri kaynağı geldiğinde filtreler tutarsızlaşır.
- Farklı taneleri karıştırmak: Aylık hedef ile fatura satırını aynı tabloya koymak toplamları bozar.
- Bir tabloyu hem olgu hem boyut yapmak: Microsoft iki türü tek tabloda karıştırmamayı önerir.
- Toplanmaması gereken sütunu toplamak: Birim fiyatın toplamı anlamsızdır; ortalama, en düşük veya en yüksek için ölçü yazın.
- Geçmişi Power Query ile korumaya çalışmak: Temsilcinin bölgesi değiştiğinde eski satışların eski bölgede kalması için sürümlü boyut (SCD Tip 2) gerekir. Microsoft’a göre bunu Power Query üretemez; değişiklikleri bir veri ambarı izlemelidir.
Kontrol listesi
- Her olgu tablosunun tanesi tek cümleyle yazılı mı?
- Ürün, müşteri, temsilci, depo ve tarih ayrı boyut tabloları mı?
- Her boyutta tek ve benzersiz bir anahtar sütun var mı?
- Tüm ilişkiler bire çok ve filtre boyuttan olguya mı akıyor?
- Tüm tarih alanları tek bir tarih tablosuna bağlı mı?
- Temel göstergeler açık DAX ölçüleri olarak yazıldı mı, birim fiyat gibi sütunlar gizlendi mi?
- Veri hacmi ve geçmiş ihtiyacı için veri ambarı gerekip gerekmediği değerlendirildi mi?
Özet
Power BI yıldız şema, ERP verisini olgu ve boyut tablolarına ayırarak raporların doğru filtrelenmesini ve tutarlı toplamlar üretmesini sağlar. Taneyi belirleyin, olguları ve boyutları ayırın, ortak bir tarih tablosu kurun, ilişkileri bire çok tutun ve göstergeleri açık ölçülerle yazın. Bu temel hazır olduğunda iş kullanıcılarının kendi raporlarını güvenle hazırlaması da kolaylaşır; bunu self servis BI yazımızda anlattık. ÇAP Teknoloji olarak ERP verinizden Power BI modelinizi iş zekası (BI) danışmanlığı kapsamında sizinle birlikte kurabiliriz; iletişim sayfamızdan bize yazın.
Sıkça Sorulan Sorular
Yıldız şema ile kar tanesi şema arasındaki fark nedir?
Yıldız şemada her iş varlığı (ürün, müşteri, tarih) tek bir boyut tablosundadır ve doğrudan olgu tablosuna bağlanır. Kar tanesi şemada aynı varlık ürün, alt grup ve ana grup gibi birbirine bağlı birkaç tabloya bölünür. Microsoft, Power BI’da bu tabloları tek boyut tablosunda birleştirmenin genellikle daha avantajlı olduğunu belirtir.
Yıldız şemayı Power BI içinde mi, SQL Server’da mı kurmalıyım?
Küçük ve orta veri hacminde dönüşümleri Power Query ile Power BI içinde yapabilirsiniz. Veri hacmi büyükse veya müşteri ve temsilci geçmişini sürümlü saklamanız gerekiyorsa Microsoft önce bir veri ambarı ve ETL süreci kurmayı, Power BI modelini de bu ambara bağlamayı önerir.
Bir modelde birden fazla olgu tablosu olabilir mi?
Evet. Satış, satın alma, stok hareketleri ve hedefler ayrı olgu tabloları olabilir. Önemli olan, bu tabloların doğrudan birbirine değil; ürün, müşteri ve tarih gibi ortak boyut tabloları üzerinden bağlanması ve her birinin kendi tanesinin tutarlı olmasıdır.
Satış temsilcisinin bölgesi değişince geçmiş raporlar nasıl korunur?
Bunun için sürümlü bir boyut tablosu (SCD Tip 2) gerekir: temsilcinin her bölge dönemi başlangıç ve bitiş tarihli ayrı bir satırdır. Microsoft’a göre Power Query bu yapıyı üretemez; değişiklikleri bir veri ambarının yükleme süreci izlemeli, Power BI hazır tabloyu okumalıdır.
