Power BI Veri Modelleme: İş Zekası için Yıldız Şeması Tasarımı

Veri modeli her Power BI raporunun temelidir. İyi tasarlanmış bir model, DAX'ın ölçümlerini basitleştirir, sorgu performansını hızlı hale getirir ve rapor geliştirmeyi sezgisel hale getirir. Kötü tasarlanmış bir model her şeyi zorlaştırır; önlemler karmaşık geçici çözümler gerektirir, sorgular yavaş çalışır ve geliştiriciler, içgörü oluşturmaktan çok modelle mücadele etmek için daha fazla zaman harcar.

Yıldız şeması analitik veri modelleri için altın standarttır ve onlarca yıldır bu böyledir. ERP ve CRM sistemlerinize güç veren ilişkisel veritabanları, düzinelerce birbirine bağlı tablo içeren normalleştirilmiş şemalar kullanılarak işlem verimliliği için tasarlanmıştır. Bu tasarım, bireysel işlemlerin kaydedilmesi için idealdir ancak toplama, karşılaştırma ve trend analizi açısından berbattır. Yıldız şeması, analitik performans için aynı verileri olgu tablolarına (ne oldu) ve boyut tablolarına (olanların etrafındaki bağlam) ayırarak yeniden yapılandırır.

Bu kılavuz, olgu ve boyut tablolarının nasıl oluşturulacağı, ilişkilerin nasıl yapılandırılacağı, verimli DAX ölçümlerinin nasıl yazılacağı, hesaplama gruplarından nasıl yararlanılacağı, zaman zekasının nasıl uygulanacağı ve birden fazla veri kaynağına bağlanmak için bileşik modellerin nasıl kullanılacağı dahil olmak üzere Power BI'ya özel yıldız şeması tasarım ilkelerini kapsar.

Önemli Çıkarımlar

• Yıldız şeması, verileri olgu tablolarına (sayısal ölçüler, yabancı anahtarlar) ve boyut tablolarına (açıklayıcı nitelikler) ayırır; bu yapı, Power BI'ın VertiPaq motoru için optimize edilmiştir
• Power BI modelindeki her ilişki, yalnızca tek yönde çapraz filtrelemeyle, boyuttan gerçeğe (birden çoğa) doğru akmalıdır
• VertiPaq boyut sütunlarını verimli bir şekilde sıkıştırabildiğinden ve gerçekleri ilişkiler aracılığıyla filtreleyebildiğinden, DAX ölçümleri yıldız şemalarında çok daha iyi performans gösteriyor
• Hesaplama grupları düzinelerce gereksiz ölçümü (YTD, QTD, MTD, Önceki Yıl) tüm temel ölçümlere uygulanan tek bir modelle değiştirir
• Zaman zekası, özel bir tarih boyutu tablosu gerektirir --- hiçbir zaman otomatik tarih/saat kullanmayın veya bilgi tablolarındaki tarih sütunlarına güvenmeyin
• Bileşik modeller, içe aktarılan verileri DirectQuery bağlantılarıyla birleştirmenize olanak tanıyarak size canlı sorguların tazeliğiyle birlikte bellek içi performans sunar
• Rol yapma boyutları (birden fazla ilişki rolünde kullanılan bir tablo), DAX'ın USERELATIONSHIP işlevini gerektirir

---

Yıldız Şemasının Temelleri

Neden Power BI için Yıldız Şeması

Power BI'ın bellek içi motoru VertiPaq, verileri depolamak için sütunlu sıkıştırmayı kullanır. Her sütunu bağımsız olarak sıkıştırır ve düşük kardinaliteye sahip sütunlar (birkaç benzersiz değer) önemli ölçüde sıkıştırılır; 10 milyon satırda 40 benzersiz değere sahip bir "Ülke" sütunu neredeyse hiçbir şeye sıkıştırılmaz. İşlem kimlikleri veya zaman damgaları gibi yüksek kardinaliteye (birçok benzersiz değer) sahip sütunlar yeterince sıkıştırılmıyor.

Yıldız şeması, yüksek kardinaliteli işlem verilerini (tarihler, miktarlar, miktarlar) dar olgu tablolarında izole ederek ve düşük kardinaliteli tanımlayıcı verileri (adlar, kategoriler, bölgeler) ayrı boyut tablolarına yerleştirerek bundan yararlanır. Sonuç, hem hafızası daha küçük hem de sorgulanması daha hızlı olan bir veri modelidir.

Farkı düşünün. Bir perakende satış işletmesi için normalleştirilmemiş bir düz tablo 50 sütuna sahip olabilir: OrderDate, CustomerName, CustomerEmail, CustomerCity, CustomerCountry, CustomerSegment, ProductName, ProductCategory, ProductSubcategory, Marka, Tedarikçi, TedarikçiÜlkesi, Miktar, BirimFiyat, İndirim, ToplamTutar vb. Her satırda "Amerika Birleşik Devletleri" binlerce kez, "Elektronik" yüzlerce kez tekrarlanıyor ve müşterinin verdiği her sipariş için tam müşteri adı geçiyor.

Yıldız şeması eşdeğeri bunu şu şekilde ayırır:

FactSales (dar, sipariş satırı başına bir satır): OrderDateKey, CustomerKey, ProductKey, Quantity, UnitPrice, İndirim, TotalAmount.

DimCustomer: MüşteriAnahtarı, MüşteriAdı, E-posta, Şehir, Ülke, Segment.

DimProduct: ÜrünAnahtarı, ÜrünAdı, Kategori, Alt Kategori, Marka.

DimDate: DateKey, Date, Year, Quarter, Month, MonthName, DayOfWeek.

Olgu tablosunda 50 yerine yalnızca 7 sütun bulunur. Her boyut tablosu, her benzersiz değeri tam olarak bir kez saklar. VertiPaq bu yapıyı düz tabloya göre 3-5 kat daha iyi sıkıştırır ve motor küçük boyutlu tabloları filtreleyip ardından yalnızca olgu tablosundaki eşleşen satırları çözdüğü için sorgular 2-10 kat daha hızlı çalışır.

Bilgi Tabloları: Tasarım İlkeleri

Bilgi tabloları iş olaylarını kaydeder; satışlar, siparişler, sevkiyatlar, destek biletleri, web ziyaretleri, üretim çalışmaları. Her satır bir olayı veya bir olayın bir satır öğesini temsil eder.

Tahıl tanımı. Tahıl, olgu tablosundaki ayrıntı düzeyidir. Bunu kesin olarak tanımlayın ve tutarlı bir şekilde uygulayın. Bir satış bilgisi tablosu "sipariş satır öğesi başına bir satır" veya "günlük ürün satış özeti başına bir satır" şeklinde olabilir. Tahılları tek bir olgu tablosunda karıştırmak (bazı satırlar bireysel işlemlerdir, bazıları günlük toplamlardır), hata ayıklaması son derece zor olan hesaplama hataları oluşturur.

Yalnızca yabancı anahtarlar. Gerçek tablosu, tanımlayıcı nitelikleri değil, boyut tablolarına yönelik yabancı anahtarları içerir. Bir olgu tablosu "MüşteriAdı" veya "ÜrünKategorisi" içermemelidir; bunlar boyut tablolarına aittir. Bilgi tablosunda, açıklayıcı ayrıntıların bulunduğu boyutlara bağlantı sağlayan Müşteri Anahtarı ve Ürün Anahtarı bulunur.

Toplam önlemler. Bir olgu tablosundaki sayısal sütunlar, herhangi bir boyutta anlamlı bir şekilde toplanabilecek değerler olan toplam değerler olmalıdır. Gelir, miktar, maliyet ve indirim eklenir. Yüzdeler, oranlar ve birim fiyatlar toplamsal değildir (ürünler genelinde birim fiyatları toplayamazsınız). Bileşenleri (pay ve payda) olgu tablosunda saklayın ve oranı bir DAX ölçüsünde hesaplayın.

Olgularda hesaplanan sütunlardan kaçının. Bir olgu tablosuna hesaplanan sütunların eklenmesi, tablonun bellek alanını artırır ve yenileme sırasında işlem süresini artırır. Bunun yerine, sorgu zamanında işlem yapan ve depolama alanı tüketmeyen DAX ölçülerinde türetilmiş değerleri hesaplayın.

Boyut Tabloları: Tasarım İlkeleri

Boyut tabloları iş olaylarının "kim, ne, nerede, ne zaman, neden" sorularını açıklar. Kullanıcıların filtrelediği, gruplandırdığı ve dilimlediği nitelikleri içerirler.

Yedek anahtarlar. Boyut tablolarında birincil anahtar olarak doğal anahtarlar (müşteri e-postası, ürün SKU'su) yerine tamsayı yedek anahtarları (MüşteriAnahtarı, ÜrünKey) kullanın. Yedek anahtarlar daha küçüktür, daha iyi sıkıştırılır ve modeli kaynak sistem anahtarlarındaki değişikliklerden yalıtır.

Boyutları normalleştirmeyin. Yıldız şemasında, boyut tabloları kasıtlı olarak normalleştirilmemiştir. DimProduct tablosu Kategori, Alt Kategori ve Markayı kendi anahtarları olan ayrı normalleştirilmiş tablolar olarak değil, aynı tablodaki sütunlar olarak içerir. Bu, işlemsel veritabanı tasarımının tam tersidir ve kasıtlıdır. VertiPaq motoru birden çok tabloyu birleştirmek yerine tek bir tabloyu taradığından, normalleştirilmemiş boyutlar daha hızlı sorgular ve daha basit DAX üretir.

Açıklayıcı hiyerarşileri ekleyin. Kullanıcılar Kategori'den Alt Kategori'ye, oradan da Ürün'e gidecekse, üç düzeyin tümü DimProduct'ta sütunlar olmalıdır. Power BI modelinde bu detay yolunu tanımlayan bir hiyerarşi nesnesi oluşturun.

Boyutlar yavaş yavaş değişiyor. Boyut özellikleri zaman içinde değiştiğinde (müşteri şehir değiştirdiğinde, ürün kategori değiştirdiğinde) bir stratejiye ihtiyacınız olur. Tip 1 (üzerine yazma) en basittir; boyut satırını yeni değerle güncelleyin. Tür 2 (yeni satır ekle) geçmişi korur --- geçerlilik tarihi aralığına sahip yeni bir satır ekleyin, böylece geçmiş işlemler o sırada geçerli olan özellik değerleriyle ilişkilendirilir. Tip 2 daha karmaşıktır ancak tarihsel doğruluğun önemli olduğu durumlarda gereklidir (mali denetimler, düzenleyici raporlama).

---

İlişkileri Yapılandırma

Power BI için İlişki Kuralları

Power BI ilişkileri, tabloların nasıl bağlanacağını ve filtrelerin nasıl yayılacağını tanımlar. İlişkileri doğru kurmak kritik öneme sahiptir; yanlış ilişkiler sessizce yanlış sayılar üretir, bu da hata üretmekten daha kötüdür.

Yalnızca bire çok. Yıldız şemasındaki her ilişki, bir boyut tablosunu (bir taraf) bir olgu tablosuna (çok taraf) bağlar. Boyut tablosunun anahtar sütununda benzersiz değerler vardır. Gerçek tablosu tekrarlanan değerlere sahiptir. Power BI bunu doğrular ve ihlalleri işaretler. Power BI çoktan çoğa bir ilişki algılarsa düzeltmeniz gereken bir modelleme sorununuz var demektir.

Tek yönlü çapraz filtreleme. Tüm ilişkilerde çapraz filtre yönünü "Tek" olarak ayarlayın. Bu, filtrelerin boyuttan gerçeğe doğru aktığı (dilimleyicide bir müşteri seçtiğinizde, olgu tablosu görsellerinde yalnızca o müşterinin satırlarının göründüğü) ancak olgudan boyuta doğru akmadığı anlamına gelir. Çift yönlü filtreleme, birden fazla olgu tablosu içeren modellerde belirsiz filtre yolları oluşturur ve çok özel senaryolar dışında bundan kaçınılmalıdır.

Etkin ve etkin olmayan ilişkiler. Power BI, herhangi iki tablo arasında yalnızca bir etkin ilişkiye izin verir. Bir olgu tablosunda birden fazla tarih sütunu (OrderDate, ShipDate, DeliveryDate) varsa, bir etkin ilişki (genellikle OrderDate ile DimDate arasında) ve diğerleri için etkin olmayan ilişkiler oluşturun. Gerektiğinde etkin olmayan ilişkiyi etkinleştirmek için DAX ölçümlerinde USERELATIONSHIP işlevini kullanın:

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

Rol Oynama Boyutları

Rol yapma boyutu, modelde birden fazla role hizmet eden tek boyut tablosudur. Tarih boyutu en yaygın örnektir; olgu tablosundaki OrderDate, ShipDate ve DeliveryDate'e bağlanarak her ilişkide farklı bir "rol" oynar.

Power BI'da rol yapma boyutlarını iki şekilde ele alabilirsiniz:

Etkin olmayan ilişkiler + USERELATIONSHIP (önerilen). Bir etkin ilişki (OrderDate ile) ve diğer tarih sütunlarıyla etkin olmayan ilişkiler içeren tek bir DimDate tablosu tutun. Alternatif tarih perspektifleri için USERELATIONSHIP'i kullanan hesaplamalar oluşturun. Bu, modeli kompakt tutar ve veri tekrarını önler.

Boyut tablolarını çoğaltın. DimDate'in (DimOrderDate, DimShipDate, DimDeliveryDate) ayrı kopyalarını oluşturun; her birinin ilgili bilgi sütunuyla etkin ilişkisi vardır. Bu yaklaşım DAX açısından daha basittir (KULLANIM İLİŞKİSİ gerekmez), ancak model boyutunu ve bakım yükünü artırır.

Çoğu uygulamada etkin olmayan ilişki yaklaşımı tercih edilir. Biraz daha ayrıntılı DAX pahasına daha temiz bir model ve daha küçük bellek alanı üretir.

Çoktan Çoğa İlişkiler

Bazı iş senaryoları gerçekten çoktan çoğa ilişkiler gerektirir. Bir müşteri birden fazla segmente ait olabilir, bir ürün birden fazla promosyon kampanyasında yer alabilir, bir satış elemanı birden fazla bölgeyi kapsayabilir. Yıldız şeması bunları köprü tabloları aracılığıyla halleder.

Bir köprü tablosu, çoktan çoğa ilişki içinde iki tablo arasında yer alır ve her kombinasyon için bir satır içerir:

KöprüMüşteriSegmenti: MüşteriAnahtarı, SegmentAnahtarı

DimCustomer, BridgeCustomerSegment'e (CustomerKey'de birden çoğa) bağlanır. DimSegment, BridgeCustomerSegment'e (SegmentKey'de birden çoğa) bağlanır. Köprü tablosu, FactSales'in segmentlere göre filtrelenmesine olanak tanırken birden fazla segmentteki müşterilerle doğru şekilde ilgilenir.

Köprü tabloları konusunda dikkatli olun; çoktan çoğa ayırma işlemini gerçekleştiren uygun DAX önlemleriyle eşleştirilmezlerse çift sayım üretebilirler. Toplamların doğru olduğunu doğrulamak için bilinen verilerle kapsamlı testler yapın.

---

DAX Ölçüleri: Kalıplar ve Performans

Temel Ölçüler

Her analitik model, olgu tablosu sütunlarında basit toplamalar gerçekleştiren bir dizi temel ölçüme ihtiyaç duyar. Öncelikle bunları tanımlayın; bunlar daha karmaşık hesaplamalar için yapı taşları görevi görür.

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

Ortalama Sipariş Değeri ve Brüt Marjın, toplama mantığını tekrarlamak yerine diğer ölçümlere referans verdiğine dikkat edin. Bu kasıtlıdır; eğer Toplam Gelir tanımı değişirse (örneğin getirileri hariç tutmak için), alt ölçümler bu değişikliği otomatik olarak yansıtır.

HESAPLAMA: DAX'ın Temeli

HESAPLAMA en önemli DAX işlevidir. Bir ifadeyi değiştirilmiş bir filtre bağlamında değerlendirir. CALCULATE'i anlamak DAX'ı anlamaktır.

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Bu ölçü, Toplam Gelir ölçüsünü alır ve bunu, tarih aralığının bir yıl geriye kaydırıldığı bir filtre bağlamında değerlendirir. Geçerli filtre bağlamı "Ocak 2026" ise CALCULATE, bunu "Ocak 2025" olarak değiştirir ve Toplam Geliri bu değiştirilen bağlamda değerlendirir.

HESAPLAMA birden fazla filtre argümanını kabul eder ve türlerine bağlı olarak farklı şekilde etkileşime girerler:

Tablo filtreleri (SAMEPERIODLASTYEAR gibi), söz konusu tablonun sütunlarındaki mevcut filtrenin yerini alır. Görselde zaten bir ay filtresi varsa SAMEPERIODLASTYEAR bunu önceki yılın karşılık gelen ayıyla geçersiz kılar.

Boolean filtreleri (DimProduct[Category] = "Electronics" gibi) mevcut bağlama eklenir. Görsel 2026'ya göre filtrelenirse HESAPLA sonucu 2026 Elektronik gelirini gösterir.

REMOVEFILTERS mevcut filtreleri temizler. CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])), hangi kategori filtrelerinin etkin olduğuna bakılmaksızın tüm kategorilerdeki toplam geliri döndürür.

Okunabilirlik ve Performans Değişkenleri

Değişkenler (VAR), bir değeri bir kez hesaplar ve ona birden çok kez referans verir. Karmaşık ölçümleri okunabilir hale getirirler ve gereksiz hesaplamaları ortadan kaldırırlar:

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

Değişkenler olmadan bu ölçüm, [Toplam Gelir] ve [Geçen Yıl Geliri] birden çok kez (bir kez çıkarma için, bir kez bölme için) hesaplayarak hesaplama maliyetini iki katına çıkarır. Değişkenler her birinin tam olarak bir kez hesaplanmasını sağlar.

Yineleyici İşlevler: Ne Zaman Kullanılmalı

Yineleyici işlevler (SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX), bir tablodaki ifadeyi satır satır değerlendirir. Güçlüdürler ancak pahalıdırlar; belirtilen tablodaki her satırı tararlar.

Toplamadan önce satır düzeyinde hesaplamalara ihtiyaç duyduğunuzda yineleyicileri kullanın:

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

Bu basit SUM ile elde edilemez çünkü toplamadan önce her satırda Miktarı BirimFiyat ile çarpmanız gerekir. Yineleyici SUMX bu satır satır çarpma işlemini gerçekleştirir.

Basit bir toplama yeterli olduğunda yineleyicilerden kaçının. SUMX(FactSales, FactSales[TotalAmount]) işlevsel olarak SUM(FactSales[TotalAmount]) ile eşdeğerdir ancak daha yavaştır çünkü yineleyici satır satır tararken SUM sütunlu sıkıştırmayı kullanır.

---

Hesaplama Grupları

Hesaplama Grupları Neyi Çözüyor?

Hesaplama gruplarından önce, 10 temel ölçü (Gelir, Miktar, Maliyet, Marj vb.) ve 5 zaman istihbarat varyasyonu (YTD, QTD, MTD, Önceki Yıl, Önceki Yıl YTD) içeren bir veri modeli, 50 ayrı ölçüm gerektiriyordu. Yeni bir temel ölçü eklemek, 5 tane daha zaman istihbaratı varyantı oluşturmak anlamına geliyordu. Yeni bir zaman zekası modeli eklemek, 10 ölçüm daha oluşturmak anlamına geliyordu. Bu kombinatoryal patlama modellerin bakımını zorlaştırdı.

Hesaplama grupları bunu, zaman zekası modellerini bir kez tanımlayıp bunları herhangi bir ölçüme dinamik olarak uygulayarak çözer.

Zaman Zekası Hesaplama Grubu Oluşturma

Power BI Desktop'ta Model görünümü aracılığıyla veya Tablo Düzenleyici gibi harici araçları (daha fazla denetim sağlar) kullanarak bir hesaplama grubu oluşturun.

Her zaman istihbarat modeli için hesaplama öğelerini tanımlayın:

Geçerli: Değişiklik yok --- hesaplamayı olduğu gibi döndürür.

SELECTEDMEASURE()

YTD (Yıl Başından Bugüne):

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

Önceki Yıl:

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Önceki Yıl YTD:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

Yıllık Değişim:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

Yıllık Yüzde Değişim:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

Kullanıcılar tanımlandıktan sonra hesaplama grubunu bir görselin sütun veya satır eksenine yerleştirir ve Power BI, her hesaplama öğesini değerler kuyusunda bulunan ölçüme uygular. 6 öğeli bir hesaplama grubu, 60 ayrı ölçümün yerine geçer (10 temel ölçüm için).

Dize İfadelerini Biçimlendir

Her hesaplama öğesi, hesaplamaya dayalı olarak sayı biçimini dinamik olarak değiştiren bir biçim dizesi ifadesine sahip olabilir:

Mutlak ölçüler için (Mevcut, YTD, Önceki Yıl): temel ölçünün formatını kullanın. Yüzde ölçüleri için (Yıllık % Değişim): yüzde olarak biçimlendirin.

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

Bu, bir kullanıcı "Geçerli" (1.234.567 ABD dolarını gösterir) ve "Yıllık Yüzde Değişim" (%12,5'i gösterir) arasında geçiş yaptığında, biçimlendirmenin manuel müdahale olmadan doğru olmasını sağlar.

---

Zaman Zekası

Tarih Boyutu Tablosu

Power BI'daki zaman zekası, özel bir tarih boyutu tablosu gerektirir. Otomatik tarih/saat özelliğine güvenmeyin (Dosya → Seçenekler → Veri Yükleme bölümünden devre dışı bırakın) --- her tarih sütunu için gizli tarih tabloları oluşturur, modelinizi şişirir ve kontrolünüzü sınırlandırır.

Verilerinizin tüm aralığını ve her iki tarafta en az bir yılı kapsayan bir tarih boyutu tablosu oluşturun. En erken işleminiz Ocak 2020 ise tarih tablosuna Ocak 2019'dan başlayın. Analiziniz 2027 tahminlerini içerecekse Aralık 2027'de sonlandırın.

Tarih boyutu tablosu için temel sütunlar:

Tarih tablosunu Power Query'de veya DAX hesaplanmış tablosu olarak oluşturun:

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

Tabloyu Power BI'da Tarih Tablosu olarak işaretleyin (Tablo Araçları → Tarih Tablosu Olarak İşaretle → Tarih sütununu seçin). Bu, yerleşik zaman zekası işlevlerini etkinleştirir.

Ortak Zaman Zeka Kalıpları

Power BI'ın zaman zekası işlevleri, uygun bir tarih boyutuyla en yaygın zamansal hesaplamaları gerçekleştirir:

Yıl Başından Bugüne: DATESYTD(DimDate[Date]) Çeyrek Başından Bugüne: DATESQTD(DimDate[Date]) Ay Başından Bugüne: DATESMTD(DimDate[Date]) Geçen Yılın Aynı Dönemi: SAMEPERIODLASTYEAR(DimDate[Date]) Geçici 12 Ay: DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) Paralel Dönem: PARALLELPERIOD(DimDate[Date], -1, QUARTER) (aynı boyutlu pencere geriye kaydırılmıştır)

Bu işlevler, CALCULATE içinde kullanıldığında tarih filtresi bağlamını değiştirir. Yalnızca tarih sütunu, bitişik ve tam bir tarih aralığına sahip Tarih Tablosu olarak işaretlenmiş bir tablodan geldiğinde doğru şekilde çalışırlar.

Mali Takvim Desteği

Kuruluşunuzun mali yılı takvim yılıyla uyumlu değilse zaman bilgisi hesaplamalarını mali takvimi kullanacak şekilde değiştirin:

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

DATESYTD'nin ikinci argümanı mali yıl sonu tarihini belirtir. Tüm YTD hesaplamalarında 31 Aralık yerine mali yıl sınırı kullanılır.

---

Kompozit Modeller

Kompozit Modeller Ne Zaman Kullanılmalı

Bileşik modeller, içe aktarılan verileri (VertiPaq'ta depolanan) DirectQuery verileriyle (kaynaktan canlı olarak sorgulanan) tek bir modelde birleştirir. Bu hibrit yaklaşım, geçmiş analiz için içe aktarılan verilerin performansına ve operasyonel ölçümler için canlı verilerin güncelliğine ihtiyaç duyduğunuzda değerlidir.

Yaygın senaryolar:

Geçmiş + gerçek zamanlı. Trend analizi için 3 yıllık geçmiş satış verilerini içe aktarın (hızlı sorgular, kaynak veritabanı üzerinde hiçbir etkisi yoktur). En güncel operasyonel görünümler için DirectQuery aracılığıyla mevcut ayın verilerine bağlanın.

Merkezi model + yerel zenginleştirme. DirectQuery aracılığıyla merkezi olarak yönetilen bir veri kümesine bağlanın (kuruluşun yönetilen tanımlarını kullanmanızı sağlar). Merkezi modelde bulunmayan departmana özel veriler (bütçe hedefleri, özel sınıflandırmalar) için yerel olarak içe aktarılan tablolar ekleyin.

Birden çok kaynak sistemi. Verileri bir bulut veri ambarından (Snowflake, Azure Synapse) içe aktarın ve bunları birleştirmek için ayrı bir ETL işlem hattı oluşturmanıza gerek kalmadan DirectQuery aracılığıyla tek bir raporda operasyonel bir veritabanına (PostgreSQL, SQL Server) bağlanın.

Kompozit Model Mimarisi

Bileşik modelde her tablonun bir depolama modu vardır:

İçe Aktarma: Veriler VertiPaq belleğine yüklenir. En hızlı sorgu performansı ancak güncellenmesi için zamanlanmış yenileme gerekir.

DirectQuery: Veriler kaynaktan canlı olarak sorgulanır. Her zaman günceldir ancak kaynak veritabanı performansına bağlıdır.

İkili: Tablo hem içe aktarılmıştır hem de DirectQuery için kullanılabilir. Hem İçe Aktarma hem de DirectQuery olgu tablolarıyla ilişkili olması gereken boyut tabloları için kullanılır.

İçe Aktarma ve DirectQuery olgularını "İkili" moda bağlayan boyut tablolarını ayarlayın. Bu, VertiPaq motorunun, İçe aktarma gerçeklerini filtrelerken bellek içi kopyayı kullanmasına ve DirectQuery gerçeklerini filtrelerken SQL sorguları oluşturmasına olanak tanır.

Performansla İlgili Hususlar

Bileşik modeller karmaşıklığı beraberinde getirir. İçe Aktarma ve DirectQuery tablolarını kapsayan sorgular, Power BI'ın iki farklı motordan gelen sonuçları birleştirmesini gerektirir; DirectQuery kaynağı iyileştirilmemişse bu yavaş olabilir.

Modelinizi, çoğu analitik sorgunun tabloları içe aktaracak şekilde yapılandırarak çapraz kaynak birleştirmelerini en aza indirin. DirectQuery'yi yalnızca gerçek zamanlı güncellik gerektiren belirli tablolar için kullanın. İlişkilerde ve filtrelerde kullanılan sütunlarda DirectQuery kaynak tablolarını dizine ekleyin.

ECOSIRE'ın veri modelleme hizmetleri, karmaşık Power BI veri modelleri oluşturan kuruluşlar için yıldız şeması tasarımı, DAX optimizasyonu ve özel veri ortamınıza ve performans gereksinimlerinize göre uyarlanmış bileşik model mimarisi konusunda uzman rehberliği sağlar.

---

Model Optimizasyonu

Model Boyutunu Küçültme

Büyük modeller daha fazla bellek tüketir, daha yavaş yenilenir ve daha az yanıt verir. Bu tekniklerle model boyutunu optimize edin:

Kullanılmayan sütunları kaldırın. Bir sütun herhangi bir görselde, ölçümde, ilişkide veya RLS kuralında kullanılmıyorsa kaldırın. Her sütun, hiçbir görsel referans vermese bile belleği tüketir. Yaygın olarak görülen suçlular arasında otomatik olarak oluşturulan sütunlar, denetim sütunları (CreatedBy, ModifiedDate) ve hiçbir analitik amaca hizmet etmeyen teknik tanımlayıcılar yer alır.

Önemliliği azaltın. Milyonlarca benzersiz değere (zaman damgaları, GUID'ler, serbest metin alanları) sahip sütunlar zayıf şekilde sıkıştırılır. Zaman damgalarını uygun ayrıntı düzeyine (günlük, saatlik) yuvarlayın. GUID'leri tamsayı yedek anahtarlarla değiştirin. Serbest metin alanlarını yalnızca detaylandırma sırasında sorgulanan ayrı bir ayrıntı tablosuna taşıyın.

Uygun veri türlerini kullanın. Power BI, "Tam Sayı"yı "Ondalık Sayı"ya göre daha verimli bir şekilde depolar. Bir sütun yalnızca tam sayılar (miktarlar, sayılar) içeriyorsa türünü Tam Sayı olarak ayarlayın. Metin sütunları, aynı önem derecesine sahip sayısal sütunlardan daha fazla bellek tüketir; mümkün olduğunda metin kategorilerini arama boyutuna sahip tamsayılar olarak kodlayın.

Otomatik tarih/saati devre dışı bırakın. Otomatik tarih/saat özelliği, modeldeki her tarih sütunu için gizli bir tarih tablosu oluşturur. 10 tarih sütunlu bir model için bu, hafızayı tüketen 10 gizli tarih tablosu anlamına gelir. Bu özelliği devre dışı bırakın ve bunun yerine tek bir açık tarih boyutu kullanın.

Sorgu Performansı Tanılaması

Power BI'ın yerleşik Performans Analizcisi'nin gösterdiğinin ötesinde sorgu performansını analiz etmek için DAX Studio'yu kullanın. DAX Studio şunları ortaya koyuyor:

Depolama motoru sorguları. VertiPaq motoruna kaç sorgu gönderildiği ve ne kadar veri taradığı. Daha az veriyi tarayan daha az sorgu, daha iyi performans anlamına gelir.

Formül motoru etkinliği. Formül motorunun ne kadar iş yaptığı (satır satır hesaplamalar, karmaşık ifadeler). Yüksek formül motoru süresi, depolama motoruna daha fazla iş göndermek için yeniden yazılması gereken önlemleri belirtir.

Sorgu planı. Power BI'ın bir ölçüyü depolama motoru sorgularına ve formül motoru işlemlerine nasıl ayrıştırdığını gösteren, bir DAX sorgusunun mantıksal ve fiziksel yürütme planı.

Etkileşimli görseller için sorgu sürelerini 500 ms'nin altında hedefleyin. 2 saniyeden uzun süren sorgular yavaşlıyor ve kontrol paneli kullanımını caydırıyor. Belirli bir görsel sürekli olarak 2 saniyeyi aşıyorsa DAX'ı basitleştirin, işlediği veri hacmini azaltın veya kullanıcıların kısa bir beklemeyi kabul edeceği bir detaylandırma sayfasına taşıyın.

---

SSS

Power BI'da yıldız şemasını mı yoksa kar tanesi şemasını mı kullanmalıyım?

Yıldız şeması neredeyse her zaman Power BI için daha iyi bir seçimdir. Snowflake şeması, boyut tablolarını alt tablolar (Kategori → Alt Kategori → Ürün) halinde normalleştirir; bu, ilişkisel veritabanlarında iyi çalışır ancak Power BI'ın VertiPaq motorunda gereksiz birleştirmeler oluşturur. VertiPaq, denormalize edilmiş boyut sütunlarını son derece verimli bir şekilde sıkıştırır, böylece kar taneciklerinden kaynaklanan alan tasarrufu göz ardı edilebilirken, ek ilişkilerin performans maliyeti gerçektir. Belirli bir teknik nedeniniz olmadığı sürece (örneğin, izole etmek istediğiniz, nadiren kullanılan yüksek kardinaliteli bir sütuna sahip çok büyük bir boyut tablosu gibi) boyutlarınızı yıldız şemasına göre düzleştirin.

Power BI'da maksimum veri kümesi boyutu nedir?

Power BI Pro, sıkıştırılmış boyutu 1 GB'a kadar olan veri kümelerini destekler. Kullanıcı Başına Premium, 100 GB'a kadar destekler. Premium kapasite (P1 ve üzeri), geniş veri kümesi depolama etkinken 400 GB'a kadar destekler. Bu sınırlar kaynak veri boyutunu değil, sıkıştırılmış bellek içi boyutu ifade eder. VertiPaq verileri genellikle 10:1 oranında sıkıştırır; dolayısıyla 1 GB sıkıştırılmış veri kümesi, 10 GB kaynak veriyi temsil edebilir. Bu sınırlara yaklaşan veri kümeleri için toplamaları, artımlı yenilemeyi veya ayrıntı düzeyindeki veriler için DirectQuery ile bileşik modelleri göz önünde bulundurun.

Yıldız şemasında çoktan çoğa ilişkileri nasıl hallederim?

Bir köprü tablosu kullanın (gerçeğe dayanmayan olgu tablosu veya bağlantı tablosu da denir). Köprü tablosunda çoktan çoğa ilişkisindeki her kombinasyon için bir satır bulunur; örneğin, her müşteri segmenti ataması için bir satır. Her boyuttan köprü tablosuna bire çok ilişkiler oluşturun. Köprü tablolarının çift sayıma neden olabileceğini unutmayın; bunları DISTINCTCOUNT ölçümleriyle eşleştirin veya filtre yayılımını kontrol etmek için DAX'ta CROSSFILTER'ı kullanın. Toplamların doğru olduğundan emin olmak için bilinen verilerle kapsamlı testler yapın.

Hesaplanan sütunlar mı yoksa DAX ölçümleri mi oluşturmalıyım?

Neredeyse tüm durumlarda hesaplanan sütunlar yerine hesaplamaları tercih edin. Ölçüler sorgu zamanında hesaplanır ve depolama alanı tüketmez. Hesaplanan sütunlar yenileme sırasında hesaplanır ve bellekte depolanır, böylece model boyutu artar. Hesaplanan sütunları yalnızca filtreleme, sıralama veya ilişkiler için kullanılabilir değere ihtiyacınız olduğunda kullanın (dilimleyicideki bir hesaplamaya göre filtreleyemezsiniz ancak hesaplanmış bir sütuna göre filtreleyebilirsiniz). Yaygın bir istisna, kullanıcıların dilimleyicilerde veya tablo görsellerinde ihtiyaç duyduğu satır düzeyindeki etiketler (FullName = FirstName + " " + LastName) için birleştirilmiş bir sütundur.

Hesaplama grupları mevcut ölçümlerle nasıl etkileşime giriyor?

Hesaplama grupları, hesaplama öğesinin ifadesine hesaplamayı sararak ölçüm değerlendirmesini keser. Bir görsel bir hesaplama ve hesaplama grubu içerdiğinde Power BI, SELECTEDMEASURE() işlevi aracılığıyla hesaplama öğesini hesaplamaya uygular. Bu, temel ölçümlerinizin değiştirilmesine gerek olmadığı anlamına gelir. Bununla birlikte, halihazırda zaman zekası içeren ölçümler (sabit kodlanmış bir YTD ölçümü gibi), hesaplama grubunun en üstte uygulanmasına neden olacak ve potansiyel olarak çift uygulama üretecektir. Bunu önlemek için yalnızca temel ölçümleri (basit toplamalar) tanımlayın ve tüm zamanların istihbaratı ve karşılaştırma mantığı için özel olarak hesaplama gruplarını kullanın.