Yıldız şemasını ve Power BI'ın önemini anlama

Bu makale Power BI Desktop veri modelleyicilerini hedefler. Yıldız şeması tasarımını ve performans ve kullanılabilirlik için en iyi duruma getirilmiş Power BI veri modellerini geliştirmeye olan ilgisini açıklar.

Bu makale, yıldız şeması tasarımı hakkında eksiksiz bir tartışma sağlamak için tasarlanmamıştır. Daha fazla ayrıntı için, Ralph Kimball ve diğerleri tarafından yayınlanan The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) gibi yayımlanmış içeriğe doğrudan bakın.

Yıldız şemasına genel bakış

Yıldız şeması , ilişkisel veri ambarları tarafından yaygın olarak benimsenen olgun bir modelleme yaklaşımıdır. Modelleyicilerin model tablolarını boyut veya olgu olarak sınıflandırması gerekir.

Boyut tabloları, iş varlıklarını (modellediğiniz öğeleri) açıklar. Varlıklar ürünler, kişiler, yerler ve zamanın kendisi de dahil olmak üzere kavramlar içerebilir. Yıldız şemasında bulabileceğiniz en tutarlı tablo tarih boyutu tablosudur. Boyut tablosu, benzersiz tanımlayıcı işlevi gören bir anahtar sütun (veya sütunlar) ve açıklayıcı sütunlar içerir.

Olgu tabloları gözlemleri veya olayları depolar ve satış siparişleri, hisse senetleri, döviz kurları, sıcaklıklar vb. olabilir. Olgu tablosu, boyut tablolarına ve sayısal ölçü sütunlarına ilişkin boyut anahtarı sütunları içerir. Boyut anahtarı sütunları olgu tablosunun boyutsallığını belirlerken, boyut anahtarı değerleri olgu tablosunun ayrıntı düzeyini belirler. Örneğin, Date ve ProductKey olmak üzere iki boyut anahtarı sütununa sahip satış hedeflerini depolamak için tasarlanmış bir olgu tablosu düşünün. Tablonun iki boyutu olduğunu anlamak kolaydır. Ancak boyut anahtarı değerleri dikkate alınmadan ayrıntı düzeyi belirlenemez. Bu örnekte Date sütununda depolanan değerlerin her ayın ilk günü olduğunu göz önünde bulundurun. Bu durumda ayrıntı düzeyi ay ürün düzeyindedir.

Genellikle boyut tabloları görece az sayıda satır içerir. Öte yandan olgu tabloları çok fazla sayıda satır içerebilir ve zamanla büyümeye devam edebilir.

Normalleştirme ve normalleştirme karşılaştırması

Bu makalede açıklanan bazı yıldız şeması kavramlarını anlamak için iki terim bilmek önemlidir: normalleştirme ve normalden çıkarma.

Normalleştirme , yinelenen verileri azaltacak şekilde depolanan verileri açıklamak için kullanılan terimdir. Ürün anahtarı gibi benzersiz bir anahtar değeri sütununa ve ürün adı, kategori, renk ve boyut gibi ürün özelliklerini açıklayan ek sütunlara sahip bir ürün tablosu düşünün. Satış tablosu, ürün anahtarı gibi yalnızca anahtarları depoladığında normalleştirilmiş olarak kabul edilir. Aşağıdaki görüntüde yalnızca ProductKey sütununun ürünü kaydettiğine dikkat edin.

Ancak satış tablosu ürün ayrıntılarını anahtarın ötesinde depolarsa, normalleştirilmiş olarak kabul edilir. Aşağıdaki görüntüde ProductKey ve ürünle ilgili diğer sütunların ürünü kaydettiğine dikkat edin.

Dışarı aktarma dosyasından veya veri ayıklamadan veri kaynağı yaptığınızda, büyük olasılıkla normalleştirilmiş bir veri kümesini temsil eder. Bu durumda, kaynak verileri birden çok normalleştirilmiş tabloya dönüştürmek ve şekillendirmek için Power Query'yi kullanın.

Bu makalede açıklandığı gibi, normalleştirilmiş olgu ve boyut verilerini temsil eden tablolarla iyileştirilmiş Power BI veri modelleri geliştirmeye çalışmanız gerekir. Ancak tek bir model tablosu oluşturmak için kar tanesi boyutunun normal dışı olması gereken bir özel durum vardır.

Power BI modellerinin yıldız şemasıyla ilgisi

Yıldız şeması tasarımı ve bu makalede kullanıma sunulan birçok ilgili kavram, performans ve kullanılabilirlik için iyileştirilmiş Power BI modelleri geliştirmekle son derece ilgilidir.

Her Power BI rapor görselinin Power BI modeline (Power BI hizmeti daha önce veri kümesi olarak bilinen anlamsal modeli çağırdığı) gönderilen bir sorgu oluşturduğunu düşünün. Bu sorgular model verilerini filtrelemek, gruplandırmak ve özetlemek için kullanılır. İyi tasarlanmış bir model, filtreleme ve gruplandırma için tablolar ve özetleme tabloları sağlayan modeldir. Bu tasarım, yıldız şeması ilkelerine çok uygundur:

• Boyut tabloları filtrelemeyi ve gruplandırma işlemini destekler
• Olgu tabloları özetlemeyi destekler

Modelleyicilerin tablo türünü boyut veya olgu olarak yapılandırmak için ayarlandığı bir tablo özelliği yoktur. Aslında model ilişkileri tarafından belirlenir. Model ilişkisi iki tablo arasında bir filtre yayma yolu oluşturur ve tablo türünü belirleyen ilişkinin Kardinalite özelliğidir. Ortak ilişki kardinalitesi bire çok veya ters çoka birdir. "Bir" tarafı her zaman boyut türündeki bir tabloyken "çok" tarafı her zaman olgu türünde bir tablodur. İlişkiler hakkında daha fazla bilgi için bkz . Power BI Desktop'ta model ilişkileri.

İyi yapılandırılmış bir model tasarımı, boyut türü tablolar veya olgu türündeki tablolar olan tabloları içermelidir. Tek bir tablo için iki türü birlikte kullanmaktan kaçının. Ayrıca, doğru ilişkilere sahip doğru sayıda tabloyu teslim etmek için çaba göstermenizi öneririz. Olgu türündeki tabloların her zaman tutarlı bir dilimde veri yüklemesi de önemlidir.

Son olarak, en uygun model tasarımının kısmen bilim ve parça sanatı olduğunu anlamak önemlidir. Bazen bunu yapmak mantıklı olduğunda iyi bir rehberliğe sahip olabilirsiniz.

Power BI modeline uygulanabilen yıldız şeması tasarımıyla ilgili birçok ek kavram vardır. Bu kavramlar şunlardır:

• Önlem -ler
• Vekil anahtarlar
• Kar tanesi boyutları
• Rol yapma boyutları
• Yavaşça değişen boyutlar
• Gereksiz boyutlar
• Bozuk boyutlar
• Olgu içermeyen olgu tabloları

Ölçümler

Yıldız şeması tasarımında ölçü, özetlenecek değerleri depolayan olgu tablosu sütunudur.

Power BI modelinde ölçünün tanımı farklıdır ancak benzerdir. Özetlemeyi başaran, Veri Çözümleme İfadeleri'nde (DAX) yazılmış bir formül. Ölçü ifadeleri sorgu zamanında skaler değer sonucu üretmek için genellikle TOPLA, MIN, MAX, ORTALAMA gibi DAX toplama işlevlerinden yararlanmaktadır (değerler modelde hiçbir zaman depolanmaz). Ölçü ifadesi, basit sütun toplamalarından filtre bağlamı ve/veya ilişki yaymalarını geçersiz kılan daha karmaşık formüllere kadar değişebilir. Daha fazla bilgi için Power BI Desktop'ta DAX Temel Bilgileri makalesini okuyun.

Power BI modellerinin özetleme için ikinci bir yöntemi desteklediğini anlamak önemlidir. Herhangi bir sütun (ve genellikle sayısal sütunlar) bir rapor görseli veya Soru-Cevap tarafından özetlenebilir. Bu sütunlar örtük ölçüler olarak adlandırılır. Birçok durumda ölçü oluşturmanız gerekmediğinden model geliştirici olarak size kolaylık sağlar. Örneğin Adventure Works kurumsal bayi satışları Satış Tutarı sütunu, her olası toplama türü için bir ölçü oluşturmaya gerek kalmadan çeşitli yollarla (toplam, sayı, ortalama, ortanca, minimum, maksimum vb.) özetlenebilir.

Ancak, basit sütun düzeyinde özetlemeler için bile ölçüler oluşturmanız için üç cazip neden vardır:

• Rapor yazarlarınızın Modeli Çok Boyutlu İfadeler (MDX) kullanarak sorgulayacaklarını bildiğinizde, modelin açık ölçüler içermesi gerekir. Açık ölçüler DAX kullanılarak tanımlanır. Bir Power BI veri kümesi MDX kullanılarak sorgulandığında bu tasarım yaklaşımı son derece önemlidir çünkü MDX sütun değerlerinin özetlenmesine ulaşamaz. Özellikle, PivotTable'lar MDX sorguları sağladığından, Excel'de Çözümle işlemi gerçekleştirilirken MDX kullanılır.
• Rapor yazarlarınızın MDX sorgu tasarımcısını kullanarak Power BI sayfalandırılmış raporları oluşturacağını bildiğinizde modelin açık ölçüler içermesi gerekir. Yalnızca MDX sorgu tasarımcısı sunucu toplamalarını destekler. Bu nedenle rapor yazarlarının ölçülerin Power BI tarafından değerlendirilmesi gerekiyorsa (sayfalandırılmış rapor altyapısı tarafından değil), MDX sorgu tasarımcısını kullanmaları gerekir.
• Rapor yazarlarınızın sütunları yalnızca belirli yollarla özetleyeceklerine emin olmanız gerektiğinde. Örneğin, bayi satış birim fiyatı sütunu (birim fiyatına göre bir değeri temsil eder) özetlenebilir, ancak yalnızca belirli toplama işlevleri kullanılarak. Hiçbir zaman toplanmamalıdır, ancak min, max, average gibi diğer toplama işlevlerini kullanarak özetlemek uygundur. Bu örnekte, modelleyici Birim Fiyat sütununu gizleyebilir ve tüm uygun toplama işlevleri için ölçüler oluşturabilir.

Bu tasarım yaklaşımı, Power BI hizmeti ve Soru-Cevap'ta yazılan raporlar için iyi çalışır. Ancak Power BI Desktop canlı bağlantıları, rapor yazarlarının Alanlar bölmesinde gizli alanları göstermesine olanak sağlar ve bu da bu tasarım yaklaşımının aşılmasıyla sonuçlanabilir.

Vekil anahtarlar

Vekil anahtar, yıldız şeması modellemesini desteklemek için tabloya eklediğiniz benzersiz bir tanımlayıcıdır. Tanım gereği kaynak verilerde tanımlanmaz veya depolanmaz. Genellikle, her boyut tablosu satırı için benzersiz bir tanımlayıcı sağlamak üzere ilişkisel veri ambarı boyut tablolarına vekil anahtarlar eklenir.

Power BI model ilişkileri, tek bir tablodaki tek bir benzersiz sütunu temel alır ve bu da filtreleri farklı bir tablodaki tek bir sütuna yarmaktadır. Modelinizdeki boyut türündeki bir tablo tek bir benzersiz sütun içermiyorsa, ilişkinin "bir" tarafı olmak için benzersiz bir tanımlayıcı eklemeniz gerekir. Power BI Desktop'ta bir Power Query dizin sütunu oluşturarak bu gereksinimi kolayca elde edebilirsiniz.

Dizin sütununu da ekleyebilmek için bu sorguyu "çok" tarafındaki sorguyla birleştirmeniz gerekir. Bu sorguları modele yüklediğinizde, model tabloları arasında bire çok ilişkisi oluşturabilirsiniz.

Kar tanesi boyutları

Kar tanesi boyutu, tek bir iş varlığı için normalleştirilmiş bir tablo kümesidir. Örneğin, Adventure Works ürünleri kategoriye ve alt kategoriye göre sınıflandırır. Ürünler alt kategorilere atanır ve alt kategoriler de kategorilere atanır. Adventure Works ilişkisel veri ambarında ürün boyutu normalleştirilir ve üç ilişkili tabloda depolanır: DimProductCategory, DimProductSubcategory ve DimProduct.

Hayal gücünüzü kullanıyorsanız, olgu tablosundan dışarı doğru konumlandırılmış normalleştirilmiş tabloların kar tanesi tasarımını oluşturarak hayal gücünüzü hayal edebilirsiniz.

Power BI Desktop'ta kar tanesi boyut tasarımını taklit etmeyi (kaynak verilerinizin taklit etme nedeni olabilir) veya kaynak tabloları tek modelli bir tabloyla tümleştirmeyi (normalleştirmeyi kaldırma) seçebilirsiniz. Genel olarak, tek bir model tablosunun avantajları birden çok model tablosunun avantajlarından daha fazladır. En uygun karar, veri hacimlerine ve modelin kullanılabilirlik gereksinimlerine bağlı olabilir.

Kar tanesi boyut tasarımını taklit etmeyi seçtiğinizde:

• Power BI, depolama ve performans açısından daha az verimli olan daha fazla tablo yükler. Bu tablolar, model ilişkilerini desteklemek için sütunlar içermelidir ve daha büyük bir model boyutuna neden olabilir.
• Daha uzun ilişki filtresi yayma zincirlerinin geçirilmesi gerekir ve bu da büyük olasılıkla tek bir tabloya uygulanan filtrelerden daha az verimli olacaktır.
• Alanlar bölmesi rapor yazarlarına daha fazla model tablosu sunar ve bu da özellikle kar tanesi boyut tablolarında yalnızca bir veya iki sütun bulunduğunda daha az sezgisel bir deneyime neden olabilir.
• Tablolara yayılan bir hiyerarşi oluşturmak mümkün değildir.

Tek bir model tablosuyla tümleştirmeyi seçtiğinizde, boyutun en yüksek ve en düşük dilimini kapsayan bir hiyerarşi de tanımlayabilirsiniz. Büyük olasılıkla, yedekli normalleştirilmiş verilerin depolanması, özellikle çok büyük boyut tabloları için model depolama boyutunun artmasına neden olabilir.

Yavaşça değişen boyutlar

Yavaş değişen boyut (SCD), zaman içinde boyut üyelerinin değişimini uygun şekilde yöneten boyutdur. İş varlığı değerleri zaman içinde ve geçici bir şekilde değiştiğinde geçerlidir. Yavaş değişen boyuta iyi bir örnek olarak müşteri boyutu, özellikle de e-posta adresi ve telefon numarası gibi iletişim ayrıntıları sütunları gösteriliyor. Buna karşılık, hisse senedi piyasa fiyatı gibi bir boyut özniteliği sık sık değiştiğinde bazı boyutların hızla değiştiği kabul edilir. Bu örneklerde yaygın tasarım yaklaşımı, hızla değişen öznitelik değerlerini olgu tablosu ölçüsünde depolamaktır.

Yıldız şeması tasarım teorisi iki yaygın SCD türünü ifade eder: Tür 1 ve Tür 2. Boyut türündeki bir tablo Tür 1 veya Tür 2 olabilir ya da farklı sütunlar için her iki türü de aynı anda destekler.

Tür 1 SCD

Tür 1SCD her zaman en son değerleri yansıtır ve kaynak verilerdeki değişiklikler algılandığında boyut tablosu verilerinin üzerine yazılır. Bu tasarım yaklaşımı, müşterinin e-posta adresi veya telefon numarası gibi ek değerleri depolayan sütunlarda yaygındır. Bir müşteri e-posta adresi veya telefon numarası değiştiğinde, boyut tablosu müşteri satırını yeni değerlerle güncelleştirir. Sanki müşteri her zaman bu iletişim bilgilerine sahipmiş gibi.

Power BI modeli boyut türündeki bir tablonun artımlı olmayan yenilemesi, Tür 1 SCD'nin sonucuna ulaşır. En son değerlerin yüklendiğinden emin olmak için tablo verilerini yeniler.

Tür 2 SCD

Tür 2SCD, boyut üyelerinin sürüm oluşturmasını destekler. Kaynak sistem sürümleri depolamıyorsa, genellikle değişiklikleri algılayan ve boyut tablosundaki değişikliği uygun şekilde yöneten veri ambarı yükleme işlemidir. Bu durumda, boyut tablosunun boyut üyesinin bir sürümüne benzersiz bir başvuru sağlamak için vekil anahtar kullanması gerekir. Ayrıca, geçerli boyut üyelerine göre kolayca filtre uygulamak için sürümün tarih aralığı geçerliliğini tanımlayan sütunlar (örneğin, StartDate ve EndDate) ve muhtemelen bir bayrak sütunu (örneğin, IsCurrent) içerir.

Örneğin, Adventure Works satış temsilcisini bir satış bölgesine atar. Bir satış temsilcisi bölgeyi yeniden yer değiştirdiğinde, geçmiş olguların eski bölgeyle ilişkilendirildiğinden emin olmak için satış temsilcisinin yeni bir sürümü oluşturulmalıdır. Satış temsilcisi tarafından yapılan satışların doğru geçmiş analizini desteklemek için boyut tablosunun satış temsilcilerinin ve ilişkili bölgelerinin sürümlerini depolaması gerekir. Tablo, saat geçerliliğini tanımlamak için başlangıç ve bitiş tarihi değerlerini de içermelidir. Geçerli sürümler, satırın geçerli sürüm olduğunu gösteren boş bir bitiş tarihi (veya 31/12/9999) tanımlayabilir. İş anahtarı (bu örnekte çalışan kimliği) benzersiz olmayacağından, tablonun bir vekil anahtar tanımlaması da gerekir.

Kaynak veriler sürümleri depolamadığında, değişiklikleri algılamak ve depolamak için bir ara sistem (veri ambarı gibi) kullanmanız gerektiğini anlamak önemlidir. Tablo yükleme işleminin mevcut verileri koruması ve değişiklikleri algılaması gerekir. Bir değişiklik algılandığında, tablo yükleme işleminin geçerli sürümün süresinin dolması gerekir. EndDate değerini güncelleştirerek ve startDate değeri önceki EndDate değerinden başlayarak yeni bir sürüm ekleyerek bu değişiklikleri kaydeder. Ayrıca, olgu tarihiyle ilgili boyut anahtarı değerini almak için ilgili olguların zamana dayalı bir arama kullanması gerekir. Power Query kullanan bir Power BI modeli bu sonucu üretemez. Ancak, önceden yüklenmiş bir SCD Tür 2 boyut tablosundan veri yükleyebilir.

Power BI modeli, değişiklik fark etmeksizin üyenin geçmiş verilerini ve üyenin belirli bir durumunu zaman içinde temsil eden bir sürümünü sorgulamayı desteklemelidir. Adventure Works bağlamında bu tasarım, atanan satış bölgesine veya satış temsilcisinin belirli bir sürümüne bakılmaksızın satış temsilcisini sorgulamanızı sağlar.

Bu gereksinimin karşılanması için Power BI modeli boyut türündeki tablo, satış temsilcisini filtrelemek için bir sütun ve satış temsilcisinin belirli bir sürümünü filtrelemek için farklı bir sütun içermelidir. Sürüm sütununun "Michael Blythe (15/12/2008-06/26/2019)" veya "Michael Blythe (güncel)" gibi belirsiz olmayan bir açıklama sağlaması önemlidir. Ayrıca rapor yazarlarını ve tüketicilerini SCD Tür 2'nin temelleri ve doğru filtreler uygulayarak uygun rapor tasarımlarını elde etme konusunda eğitmek de önemlidir.

Görsellerin sürüm düzeyinde detaya gitmelerine olanak tanıyan bir hiyerarşi eklemek de iyi bir tasarım uygulamasıdır.

Rol yapan boyutlar

Rol yapma boyutu, ilgili olguları farklı şekilde filtreleyebilecek bir boyuttur. Örneğin Adventure Works'te tarih boyutu tablosunun bayi satış bilgileriyle üç ilişkisi vardır. Olguları sipariş tarihine, sevk tarihine veya teslim tarihine göre filtrelemek için aynı boyut tablosu kullanılabilir.

Bir veri ambarında kabul edilen tasarım yaklaşımı tek bir tarih boyutu tablosu tanımlamaktır. Sorgu zamanında, tarih boyutunun "rolü", tabloları birleştirmek için kullandığınız olgu sütunu tarafından oluşturulur. Örneğin, satışları sipariş tarihine göre analiz ettiğinizde, tablo birleştirmesi bayi satış siparişi tarihi sütunuyla ilgilidir.

Power BI modelinde bu tasarım, iki tablo arasında birden çok ilişki oluşturularak taklit edilebilir. Adventure Works örneğinde tarih ve bayi satış tablolarının üç ilişkisi olabilir. Bu tasarım mümkün olsa da, iki Power BI model tablosu arasında yalnızca bir etkin ilişki olabileceğini anlamak önemlidir. Kalan tüm ilişkiler devre dışı olarak ayarlanmalıdır. Tek bir etkin ilişkiye sahip olmak, tarihten kurumsal bayi satışlarına varsayılan bir filtre yayılması olduğu anlamına gelir. Bu örnekte, etkin ilişki raporlar tarafından kullanılan en yaygın filtreye ayarlanır ve Adventure Works'te sipariş tarihi ilişkisi kullanılır.

Etkin olmayan ilişki kullanmanın tek yolu USERELATIONSHIP işlevini kullanan bir DAX ifadesi tanımlamaktır. Örneğimizde, model geliştiricisinin kurumsal bayi satışlarının sevkiyat tarihine ve teslim tarihine göre analiz edilmesine olanak tanımak için ölçüler oluşturması gerekir. Bu çalışma, özellikle bayi tablosu birçok ölçü tanımladığında yorucu olabilir. Ayrıca, ölçülerin fazlasıyla Alanlar bölmesi dağınıklığı da oluşturur. Başka sınırlamalar da vardır:

• Rapor yazarları ölçüleri tanımlamak yerine sütunları özetlemeyi kullandıklarında, rapor düzeyinde ölçü yazmadan etkin olmayan ilişkiler için özetleme yapamazlar. Rapor düzeyinde ölçüler yalnızca Power BI Desktop'ta rapor yazarken tanımlanabilir.
• Tarih ve bayi satışları arasında yalnızca bir etkin ilişki yolu olduğundan, kurumsal bayi satışlarını farklı tarih türlerine göre aynı anda filtrelemek mümkün değildir. Örneğin, sevk edilen satışlara göre sipariş tarihi satışlarını çizen bir görsel oluşturamazsınız.

Bu sınırlamaları aşmak için yaygın bir Power BI modelleme tekniği, her rol yapma örneği için boyut türü bir tablo oluşturmaktır. DaX kullanarak genellikle ek boyut tablolarını hesaplanan tablolar olarak oluşturursunuz. Hesaplanmış tabloları kullanarak model, her biri ilgili bayi satış tablosu sütunlarıyla tek ve etkin ilişkisi olan bir Tarih tablosu, Bir Sevk Tarihi tablosu ve Teslim Tarihi tablosu içerebilir.

Bu tasarım yaklaşımı, farklı tarih rolleri için birden çok ölçü tanımlamanızı gerektirmez ve farklı tarih rollerine göre eşzamanlı filtrelemeye izin verir. Bununla birlikte, bu tasarım yaklaşımıyla ödenecek küçük bir fiyat, tarih boyutu tablosunun çoğaltılması ve model depolama boyutunun artmasıdır. Boyut türündeki tablolar genellikle olgu türündeki tablolara göre daha az satır depoladıkça, nadiren sorun olur.

Her rol için model boyut türü tabloları oluştururken aşağıdaki iyi tasarım uygulamalarını inceleyin:

• Sütun adlarının kendi kendine açıklayıcı olduğundan emin olun. Tüm tarih tablolarında bir Year sütunu olması mümkün olsa da (sütun adları tablolarında benzersizdir), varsayılan görsel başlıklar tarafından kendi kendini açıklamaz. Her boyut rol tablosundaki sütunları yeniden adlandırarak Ship Date tablosunun Ship Year adlı bir yıl sütununa sahip olması vb. göz önünde bulundurun.
• İlgili olduğunda, tablo açıklamalarının rapor yazarlarına (Alanlar bölmesi araç ipuçları aracılığıyla) filtre yayma yapılandırması hakkında geri bildirim sağladığından emin olun. Bu netlik, model birçok olgu türü tabloyu filtrelemek için kullanılan Date gibi genel olarak adlandırılmış bir tablo içerdiğinde önemlidir. Örneğin, bu tabloda bayi satış siparişi tarihi sütunuyla etkin bir ilişki olması durumunda, "Bayi satışlarını sipariş tarihine göre filtreler" gibi bir tablo açıklaması sağlamayı göz önünde bulundurun.

Daha fazla bilgi için bkz . Etkin ve etkin olmayan ilişki kılavuzu.

Gereksiz boyutlar

Gereksiz boyut, özellikle birkaç öznitelik (belki de bir tane) içeren birçok boyut olduğunda ve bu özniteliklerin birkaç değeri olduğunda kullanışlıdır. İyi adaylar sipariş durumu sütunlarını veya müşteri demografik sütunlarını (cinsiyet, yaş grubu vb.) içerir.

Gereksiz boyutun tasarım amacı, hem model depolama boyutunu küçültmek hem de daha az model tablosu oluşturarak Alanlar bölmesi dağınıklığı azaltmak için birçok "küçük" boyutu tek bir boyutta birleştirmektir.

Gereksiz boyut tablosu genellikle vekil anahtar sütunuyla tüm boyut özniteliği üyelerinin Kartezyen ürünüdür. Vekil anahtar, tablodaki her satıra benzersiz bir başvuru sağlar. Boyutu bir veri ambarında oluşturabilir veya Power Query kullanarak tam dış sorgu birleştirmeleri gerçekleştiren ve ardından vekil anahtar (dizin sütunu) ekleyen bir sorgu oluşturabilirsiniz.

Bu sorguyu modele boyut türündeki bir tablo olarak yüklersiniz. Ayrıca bu sorguyu olgu sorgusuyla birleştirmeniz gerekir, böylece "bire çok" model ilişkisinin oluşturulmasını desteklemek için dizin sütunu modele yüklenir.

Bozuk boyutlar

Bozuk boyut, olgu tablosunun filtreleme için gereken özniteliğine başvurur. Adventure Works'te bayi satış siparişi numarası iyi bir örnektir. Bu durumda, model depolama boyutunu artıracağı ve Alanlar bölmesi dağınıklığıyla sonuçlanması nedeniyle yalnızca bu sütundan oluşan bağımsız bir tablo oluşturmak iyi bir model tasarımı mantıklı değildir.

Power BI modelinde, satış siparişi numarası sütununu olgu türündeki tabloya ekleyerek satış siparişi numarasına göre filtrelemeye veya gruplandırmaya izin vermek uygun olabilir. Daha önce tanıtılan tablo türlerini karıştırmamanızı gerektiren bir özel durumdur (genellikle model tabloları boyut türünde veya olgu türünde olmalıdır).

Ancak Adventure Works kurumsal bayileri satış tablosunda sipariş numarası ve sipariş satırı numarası sütunları varsa ve bunlar filtreleme için gerekliyse, bozuk bir boyut tablosu iyi bir tasarım olacaktır. Daha fazla bilgi için bkz . Bire bir ilişki kılavuzu (Bozuk boyutlar).

Olgu içermeyen olgu tabloları

Olgu içermeyen olgu tablosu hiçbir ölçü sütunu içermez. Yalnızca boyut anahtarlarını içerir.

Olgu içermeyen bir olgu tablosu, boyut anahtarları tarafından tanımlanan gözlemleri depolayabilir. Örneğin, belirli bir tarih ve saatte, belirli bir müşteri web sitenizde oturum açtı. Ne zaman ve kaç müşterinin oturum açtığını analiz etmek için olgu içermeyen olgu tablosunun satırlarını saymak için bir ölçü tanımlayabilirsiniz.

Olgu içermeyen olgu tablosunun daha cazip bir kullanımı, boyutlar arasındaki ilişkileri depolamaktır ve çoka çok boyut ilişkilerini tanımlamanızı önerdiğimiz Power BI modeli tasarım yaklaşımıdır. Çoka çok boyut ilişkisi tasarımında, olgusuz olgu tablosu köprü oluşturma tablosu olarak adlandırılır.

Örneğin, satış temsilcilerinin bir veya daha fazla satış bölgesine atanabileceğini düşünün. Köprü oluşturma tablosu, iki sütundan oluşan olgu içermeyen bir olgu tablosu olarak tasarlanır: satış temsilcisi anahtarı ve bölge anahtarı. Yinelenen değerler her iki sütunda da depolanabilir.

Bu çoka çok tasarım yaklaşımı iyi belgelenmiştir ve köprü oluşturma tablosu olmadan gerçekleştirilebilir. Ancak köprü oluşturma tablosu yaklaşımı, iki boyutu ilişkilendirirken en iyi uygulama olarak kabul edilir. Daha fazla bilgi için bkz . Çoka çok ilişki kılavuzu (İki boyut türü tablosunu ilişkilendirme).

İlgili içerik

Yıldız şeması tasarımı veya Power BI modeli tasarımı hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Boyutlu modelleme Vikipedi makalesi
• Power BI Desktop'ta ilişkileri oluşturma ve yönetme
• Bire bir ilişki kılavuzu
• Çoka çok ilişki kılavuzu
• çift yönlü ilişki kılavuzu
• Etkin ve etkin olmayan ilişki kılavuzu
• Sorularınız var mı? Power BI Topluluğu sormayı deneyin
• Öneri? Power BI'ı geliştirmek için fikirlere katkıda bulunma