Model tasarımı II: kar tanesi şema, bileşik anahtar, ayrıntı düzeyi ve görünürlük

“Veri modelleme: yıldız şema ve ilişkiler” dersinde olgu ve boyut tablolarını, “Hedef ve gerçekleşen” dersinde iki farklı ayrıntı düzeyindeki olguyu gördük. Bu ders modeli bir kullanıcının gözünden düzenliyor: hangi tablo nereye bağlanmalı, hangi sütun görünmeli, hangi sayı toplanmamalı.

Kar tanesi mi, yıldız mı?

Yıldız şemada her boyut tablosu doğrudan olgu tablosuna bağlanır. Kar tanesi (snowflake) şemada bir boyut, başka bir boyuta bağlanarak dallanır. Bizim modelimizde böyle bir dal var:

Satislar[UrunNo]   *-1  Urunler[UrunNo]
Urunler[Kategori]  *-1  Kategoriler[Kategori]
Hedefler[Kategori] *-1  Kategoriler[Kategori]

Satış satırı, kategorisine iki adımda ulaşır. Satır bağlamında RELATED bu zinciri izler:

Elektronik Satışı (Zincir) =
SUMX(
    FILTER(Satislar, RELATED(Kategoriler[Kategori]) = "Elektronik" && Satislar[Durum] <> "İptal"),
    Satislar[Tutar]
)

Sonuç 339.303,65 ₺; CALCULATE([Net Satış], Urunler[Kategori] = "Elektronik") ile aynıdır.

Ne zaman düzleştirmeli? Dallanan tablo yalnızca bir boyuta hizmet ediyorsa onu Power Query’de üst boyuta birleştir (birleştir + genişlet), dalı sil. Kazancın: daha az ilişki, daha kısa filtre yolu, daha sade bir Veri bölmesi ve tek tabloda kurulabilen hiyerarşiler. Dalı tutmanın haklı nedeni, aynı boyutu farklı ayrıntı düzeyinde başka bir olgunun da kullanmasıdır. Kategoriler tablosu tam olarak bu yüzden var: Hedefler ürün düzeyinde değil kategori düzeyinde tutuluyor ve iki olgu ortak bir kategori listesinde buluşuyor.

Ayrıntı düzeyi: olgu tablosunun cümlesi

Bir olgu tablosu tasarlarken önce tek bir cümle yaz: “Bir satır, … demektir.” Bu cümle ayrıntı düzeyini (grain) belirler; hangi boyutlara bağlanabileceğini ve hangi sorulara cevap verebileceğini sınırlar.

Cümle netse hatalar erken görünür. Hedefler ay düzeyinde olduğu için gün düzeyinde bir hedef sorusu anlamsızdır; StokGorunum bir fotoğraf olduğu için aylar boyunca toplanamaz, son değeri alınır. Aynı tabloya iki farklı tanecikte satır karıştırmak (ör. ürün satırları ile sipariş başlığındaki kargo ücreti) toplamları sessizce bozar: kargo ücretini ayrı bir sipariş düzeyi tabloya ya da satırlara paylaştırarak ekle.

Bileşik anahtar

Power BI’da bir ilişki her iki tarafta tek bir sütun kullanır. StokGorunum’daki bir satırı benzersiz kılan şey ise iki sütunun birlikteliğidir: Tarih + UrunNo. Çoğu zaman bu bir sorun değildir: yıldız şemada her parça kendi boyutuna bağlanır (Tarih’e ve Urunler’e). Bileşik anahtar ancak iki sütunla tanımlanan bir boyuta bağlanman gerektiğinde gerekir; örneğin bayi kodlarının yalnızca bölge içinde benzersiz olduğu bir bayi listesi.

Çözüm, iki sütunu tek bir anahtar sütununda birleştirmektir. En iyi yer Power Query’dir: iki tarafta da aynı ayraçla Sütunları birleştir.

Table.AddColumn(Kaynak, "BayiAnahtar",
    each Text.Combine({[BolgeKodu], Text.From([BayiKodu])}, "|"), type text)

DAX’ta hesaplanmış sütunla da yapılabilir; COMBINEVALUES bu iş için tasarlanmıştır:

BayiAnahtar = COMBINEVALUES("|", Bayiler[BolgeKodu], Bayiler[BayiKodu])

Anahtarın gerçekten benzersiz olduğunu bir sorguyla kontrol et. StokGorunum’da birleşik anahtarın farklı değer sayısı satır sayısına (1.440) eşitse anahtar sağlamdır:

EVALUATE
ROW(
    "Satır", COUNTROWS(StokGorunum),
    "Farklı anahtar", COUNTROWS(DISTINCT(SELECTCOLUMNS(StokGorunum, "K", COMBINEVALUES("|", StokGorunum[Tarih], StokGorunum[UrunNo]))))
)

Ayraç önemlidir: ayraçsız “1” + “12” ile “11” + “2” aynı “112” anahtarını üretir.

Hiyerarşi

Hiyerarşi, kullanıcının matriste ve grafikte detaya inmesini (drill down) sağlayan sıralı bir alan grubudur: Yıl → Çeyrek → Ay ya da Kategori → Ürün. Veri bölmesinde en üst düzey alana sağ tıklayıp Hiyerarşi oluştur dersin, diğer alanları üzerine sürüklersin. Kısıt: bir hiyerarşinin bütün düzeyleri aynı tabloda olmalı. Kategoriler[Kategori] ile Urunler[Urun] farklı tablolarda olduğu için ikisiyle tek bir hiyerarşi kuramazsın; düzleştirmenin bir başka nedeni budur. Hiyerarşi içinde pay hesaplamak sık bir istektir: ürünün kendi kategorisi içindeki payı.

Kategori İçi Pay % =
DIVIDE(
    [Net Satış],
    CALCULATE([Net Satış], REMOVEFILTERS(Urunler[Urun]), VALUES(Urunler[Kategori]))
)

REMOVEFILTERS ürün filtresini kaldırır; VALUES(Urunler[Kategori]) ise o ürünün kategorisini filtre olarak geri koyar. 27" Monitör Elektronik satışlarının yaklaşık %30’unu oluşturur.

Görünürlük, klasörler ve açıklamalar

• Rapor görünümünde gizle: ilişki anahtarları (Satislar[UrunNo], Satislar[MusteriNo]), yardımcı sütunlar ve ham sayı sütunları. Kullanıcı ham Tutar’ı değil [Net Satış] ölçüsünü kullanmalı.
• Görüntüleme klasörü (Display folder): Model görünümünde Özellikler bölmesinden ölçüleri “Satış”, “Müşteri”, “Zaman” gibi klasörlere ayır; ters eğik çizgiyle alt klasör olur (Satış\Oranlar).
• Açıklama (Description): Veri bölmesinde alanın üzerine gelince görünür. “Net Satış: iptal edilen siparişler hariç, indirim sonrası tutar.” Copilot da bu açıklamaları okur; “Yapay zekâ için verileri hazırla” (Prep data for AI) çalışmasının bir parçasıdır.
• Veri kategorisi (Data category): Sütun araçları sekmesinde. Musteriler[Sehir]’i “Şehir” yaparsan harita görseli değeri doğru konumlar; “Web URL’si” bağlantıyı tıklanabilir, “Görüntü URL’si” resmi tabloda gösterir. Veri türüne uymayan kategoriler devre dışıdır.
• Varsayılan özetleme (Summarization): Power BI sayısal sütunları görsele koyunca toplar. UrunNo, Musteriler[DogumYili] ya da Tarih[Yil] toplanınca anlamsız sayılar çıkar; bu sütunlarda özetlemeyi Özetleme (Don’t summarize) yap. Fiyat gibi birim değerler için toplam yerine ortalama daha doğru bir varsayılandır; asıl hesap yine ölçüyle yapılmalı.

Sütunu nerede hesaplamalı?

Örneğin Satislar’a RELATED(Kategoriler[Kategori]) ile bir kategori sütunu eklemek gereksizdir: ilişki zaten filtreyi taşır. Hesaplanmış sütun, Power Query’de kolayca yapılamayan ve model bilgisi gerektiren durumlar için kalsın; örneğin bir müşterinin ömür boyu satışına göre segment, sabit bir değer olarak gerekiyorsa.