POWER BI VERİ MODELİ YILDIZ ŞEMA

Power BI'da veri modeli, tabloların üst üste yığıldığı bir depo sanılır — içeri ne attıysanız oradadır, gerisini görseller halleder. Yanılgı tam burada başlar: modelin biçimi, raporun kaderidir. Tablolar rastgele bağlandığında filtreler beklenmedik yönlere akar, ölçüler yanlış toplamlar üretir ve "rakam neden böyle çıktı" sorusu ekibin gündelik sorusu hâline gelir. Düzgün modelin adı bellidir: yıldız şema.
Bu yazı yıldız şemayı gerçek bir model üzerinden anlatıyor: 72 satış kaydının ortada, ürün ve şube tablolarının etrafında durduğu bir .pbix. Ekran görüntüleri modelin kendisinden; dosya yazının sonunda indirilebilir.
Model dosyasını indir (.pbix) — yıldız şema + ilişkiler gömülü1. Yıldız Şema Nedir: Olgu ve Boyut
Yıldız şemanın iki yapı taşı vardır. Olgu tablosu (fact) olayları kaydeder: kim, neyi, ne zaman, kaç adet — örneğimizde Satislar. Uzundur, sürekli büyür ve ad, fiyat gibi tanım bilgisi taşımaz; yalnızca sayılar ve kimlik numaraları. Boyut tabloları (dimension) ise tanımları tutar: Urunler (ad, kategori, fiyat), Subeler (şube, şehir, bölge). Kısadır ve yavaş değişir.
Şemaya adını veren görüntü, olgunun merkezde, boyutların çevresinde ışınlar gibi dizilmesidir. Desen Power BI'a özgü değildir; modelleme kılavuzlarının tamamı — resmî dokümantasyon dahil — rapor modellerinde bu düzeni varsayılan kabul eder. Düzen estetik değil işlevseldir: her filtre boyuttan olguya tek yönde, tek adımda akar — raporun her sayısı, izlenebilir tek bir yoldan hesaplanır.
2. Model Görünümünü Okumak
Power BI'ın sol kenarındaki üçüncü simge model görünümünü açar — raporun makine dairesi:

Diyagramda üç şey okunur. Kutular tabloları ve alanlarını gösterir; Satislar'daki Tarih alanının takvim simgesi taşıması, otomatik tarih hiyerarşisinin kurulduğuna işarettir. Çizgiler ilişkilerdir. Uçlardaki 1 ve * işaretleri yönü söyler: bir ürün (1) çok satışta (*) geçer. Modeli ilk kez açan biri bu tek ekrandan iş modelinin tamamını çıkarabilmelidir — çıkaramıyorsa model, yıldızdan uzaklaşmış demektir.
3. İlişkiler: Otomatik Kurulum ve Kontrol
Bu modeldeki ilişkilerin ilginç bir özelliği var: hiçbirini elle kurmadık. Excel'den içe aktarma sırasında Power BI, ŞubeID ve ÜrünID kolonlarının iki tabloda da bulunduğunu görüp bağları kendisi kurdu. Otomatik algılama çoğu düzenli veri setinde isabetlidir — ama denetimsiz bırakılmaz. Kontrol noktası, şeritteki İlişkileri yönet ekranıdır:

Listede her bağın kaynağı, hedefi, kardinalitesi ve durumu görünür; Yeni ilişki ve Otomatik Algıla düğmeleri elle müdahale içindir. Kurumsal alışkanlık önerisi: içe aktarmadan sonra bu ekranı açıp her ilişkiyi tek tek okumak. Otomatik algılamanın yanlış eşleştirdiği bir kolon (örneğin iki tablodaki alakasız "Ad" kolonları), fark edilmezse bütün raporu sessizce zehirler.
4. Kardinalite ve Filtre Yönü
İlişkinin iki ayarı, modelin davranışını belirler. Kardinalite bire-çok (1-*) olmalıdır: boyut tarafı tekil (her ürün bir kez), olgu tarafı çoğul. Gezgin'de tabloları ayrı ayrı aktarmanın ödülü budur — tekrarsız boyut tabloları, temiz 1-* bağlar. Filtre yönü ise varsayılanda tek yönlüdür: boyuttan olguya. Bölge filtresi satışları süzer; satışlar bölge listesini süzmez.
İki ayarı da değiştirmek mümkündür (çoka-çok kardinalite, çift yön) ama bunlar istisna araçlarıdır. Yeni başlayanın "filtre çalışmıyor" diye çift yöne geçmesi, sorunun kendisini değil belirtisini tedavi eder ve büyüyen modelde belirsiz filtre döngüleri üretir. Doğru refleks, yön sorunlarında önce şemaya bakmaktır: tablolar gerçekten olgu-boyut düzeninde mi?
5. Yıldızdan Sapmalar: Neye Mal Olur
Sahada en sık görülen üç sapma ve bedelleri:
- Tek dev tablo: her şey DÜŞEYARA ile tek tabloya dikilmiş. Çalışır — ta ki dosya şişene, aynı ürün adının iki yazımı iki ayrı satır üretene kadar. Model sıkıştırması da kötüleşir; aynı verinin tek-tablo hâli, yıldız hâlinden büyük yer kaplar.
- Kar tanesi (snowflake): boyutun boyutu — Urunler'in Kategoriler tablosuna bağlanması gibi. Power BI'da çoğu zaman gereksizdir; kategori, ürün tablosunun kolonu olarak kalmalıdır. Her ek zincir halkası, filtre yolunu uzatır.
- Olgular arası doğrudan bağ: Satislar ile Hedefler'i birbirine bağlamaya çalışmak. Olgular birbirine değil, ortak boyutlara bağlanır — ikisinin buluşma yeri tarih/ay boyutudur.
Örnek modeldeki Hedefler tablosu üçüncü durumun canlı dersi: kasıtlı olarak ilişkisiz duruyor. Ay bazlı hedef-gerçekleşme kıyası, bağ değil ortak boyut (takvim) ister — bu kurulumun ölçü tarafı DAX ölçü kültürü yazısının konusudur.
6. Dosyayı İndirin
Model dosyasını indir (.pbix) — yıldız şema + ilişkiler gömülüDosyayı ücretsiz Power BI Desktop ile açın (veri gömülüdür, indiği anda çalışır) ve model görünümüne geçin. Üç alıştırma önerisi: bir ilişki çizgisine çift tıklayıp kardinalite ekranını inceleyin; İlişkileri yönet'ten bağları listeleyin; rapor görünümünde Bölge ile Adet'i aynı görsele koyup iki ayrı tablonun ilişki sayesinde buluşmasını izleyin.
Yıldız şema, Power BI'ın bütün üst katmanlarının (DAX, RLS, performans) üzerinde durduğu zemindir; zemin eğriyse üst katlar düzelmez. Modellemeyi gerçek kurumsal veri setleriyle çalışmak isteyenler için Power BI eğitimi şema tasarımını geçiş senaryolarıyla birlikte işliyor.
Sıkça Sorulan Sorular
Mevcut raporumuz tek dev tabloyla çalışıyor; yıldız şemaya geçiş neyi gerektirir?
Kaynağı üçe-dörde bölmek: tekrar eden tanım kolonları (ürün adı, bölge gibi) kendi tablolarına çıkar, olgu tablosunda yalnız kimlik numaraları kalır. Bu ayrıştırma Power Query'de sorgu çoğaltma ve yinelenenleri kaldırma ile kaynağa dokunmadan yapılabilir. Rapor görselleri alan adları değişmediği sürece büyük ölçüde aynı kalır.
Otomatik ilişki algılamaya güvenilir mi, kurumsal modellerde kapatılmalı mı?
Düzenli adlandırılmış küçük modellerde isabetlidir; çok kaynaklı kurumsal modellerde yanlış eşleşme riski büyür. Pratik orta yol: açık bırakıp her içe aktarmadan sonra İlişkileri yönet ekranında bağları denetlemek. Kritik modellerde ekipler genelde otomatik algılamayı kapatıp ilişkileri bilinçli elle kurar — hangisini seçerseniz seçin, denetim adımı atlanmamalıdır.
Ayrı bir takvim (tarih) tablosu şart mı? Otomatik tarih hiyerarşisi yetmez mi?
Küçük raporlarda otomatik hiyerarşi (Yıl/Çeyrek/Ay/Gün) yeterlidir. Birden çok olgu tablosunu aynı zaman ekseninde kıyaslayacaksanız — satış ve hedef gibi — ortak bir takvim boyutu şart olur; iki olgu da ona bağlanır. Mali yıl, hafta numarası gibi kurumsal takvim ihtiyaçları da ancak özel tarih tablosuyla karşılanır.
Yıldız şemayı öğrenmek için veri ambarı geçmişi gerekir mi?
Hayır — kavram iki cümledir: olaylar olgu tablosuna, tanımlar boyut tablolarına; boyutlar olguya bire-çok bağlanır. Örnek dosyadaki dört tablo bu mantığı görmek için yeterlidir. Veri ambarı literatürü aynı deseni büyük ölçekte uygular; Power BI kullanıcısı için önemli olan ölçek değil, deseni küçükken doğru kurmaktır.


