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 anlam modellerini geliştirmeye olan ilgisini açıklar.

Önemli

Power BI anlam modelleri, verileri içeri aktarmak veya verilere bağlanmak için Power Query'ye bağlıdır. Bu, kaynak verileri dönüştürmek ve hazırlamak için Power Query'yi kullanmanız gerektiği anlamına gelir. Bu, büyük veri hacimleriniz olduğunda veya yavaş değişen boyutlar gibi gelişmiş kavramlar uygulamanız gerektiğinde (bu makalenin ilerleyen bölümlerinde açıklanmaktadır) zor olabilir.

Bu zorluklarla karşılaştığınızda, veri ambarını düzenli aralıklarla yüklemek için önce bir veri ambarı ve Ayıklama, Dönüştürme ve Yükleme (ETL) işlemleri geliştirmenizi öneririz. Semantik modeliniz daha sonra veri ambarına bağlanabilir. Daha fazla bilgi için bkz . Microsoft Fabric Warehouse'da boyutsal modelleme.

İpucu

Bu makale, yıldız şeması tasarımı hakkında eksiksiz bir tartışma sağlamak için tasarlanmamıştır. Daha fazla bilgi için, Ralph Kimball ve diğer kişilerin The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) gibi yaygın olarak benimsenen yayımlanmış içeriklere 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ütunu (veya sütunları) ve diğer sütunları içerir. Diğer sütunlar verilerinizi filtrelemeyi ve gruplandırmanızı destekler.
• Olgu tabloları gözlemleri veya olayları depolar ve satış siparişleri, hisse senetleri, döviz kurları, sıcaklıklar ve daha fazlası 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, iki boyut anahtarı sütunu Date ve ProductKeyiçeren 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, sütunda depolanan değerlerin Date her ayın ilk günü olduğunu düşünün. 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 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 diğer 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 sütunun ProductKey ü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 ve ürünle ilgili diğer sütunların ProductKey ü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 anlam modelleri geliştirmeye çalışmanız gerekir. Ancak, tek bir model tablosu oluşturmak için kar tanesi boyutunun normal dışı hale getirilebileceği bir özel durum vardır.

Power BI anlam modellerine yıldız şeması 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 anlam modeline gönderilen bir sorgu oluşturduğunu düşünün. Sorgular genellikle model verilerini filtreler, gruplandırıp özetler. İ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 özelliğini etkinleştirir.
• Olgu tabloları özetlemeyi etkinleştirir.

Modelleyicilerin tablo türünü boyut veya olgu olarak ayarlamak 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 bir boyut tablosu, "çok" tarafı ise her zaman bir olgu tablosudur.

İyi yapılandırılmış model tasarımı, boyut tabloları veya olgu tabloları olan tabloları içerir. 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 etmeye çalışmanızı öneririz. Olgu tablolarını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 anlam modeline uygulanabilen yıldız şeması tasarımıyla ilgili birçok 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 anlam modelinde ölçünün tanımı farklıdır ancak benzerdir. Model hem açık hem de örtük ölçüleri destekler.

• Açık ölçüler açıkça oluşturulur ve özetleme elde eden Veri Çözümleme İfadeleri'nde (DAX) yazılmış bir formülü temel alır. Ölçü ifadeleri sorgu zamanında skaler değer sonucu üretmek için genellikle , MINMAX, , AVERAGEve diğerleri gibi SUMDAX toplama işlevlerini kullanır (değerler asla modelde 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 TemelLeri hakkında bilgi edinin.
• Örtük ölçüler , rapor görseli veya Soru-Cevap tarafından özetlenebilir sütunlardır. Birçok örnekte (açık) ölçüler oluşturmanız gerekmeyen model geliştiricisi olarak size kolaylık sağlar. Örneğin Adventure Works kurumsal bayi satış Sales Amount sütunu, her olası toplama türü için bir ölçü oluşturmaya gerek kalmadan çeşitli yollarla (toplam, sayı, ortalama, ortanca, min, max ve diğerleri) özetlenebilir.

Veri bölmesinde açık ölçüler hesap makinesi simgesiyle gösterilirken örtük ölçüler sigma simgesi (∑) ile gösterilir.

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

• Rapor yazarlarınızın Çok Boyutlu İfadeler (MDX) kullanarak semantik modeli sorgulayacaklarını biliyorsanız, modelin açık ölçüler içermesi gerekir. Bunun nedeni MDX'in sütun değerlerini özetleyememedir. Özellikle, PivotTable'lar MDX sorguları sağladığından Excel'de Çözümle işlemi yapılırken 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, anlam modeli açık ölçüler içermelidir. 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ı belirli yollarla nasıl özetlemesini denetlemek istediğinizde. Örneğin, bayi satış Unit Price sütunu (birim fiyatına göre bir değeri temsil eder) özetlenebilir, ancak yalnızca belirli toplama işlevleri kullanılarak özetlenebilir. Hiçbir zaman toplanmamalıdır, ancak min, max veya average gibi diğer toplama işlevlerini kullanarak özetlemek uygundur. Bu örnekte, modelleyici sütunu gizleyebilir Unit Price 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 Veri bölmesinde gizli alanları göstermesine olanak sağlar ve bu da bu tasarım yaklaşımının atlanması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 anlam modeli ilişkileri, filtreleri farklı bir tablodaki tek bir sütuna yayan tek bir tablodaki tek bir benzersiz sütunu temel alır. Anlam modelinizdeki bir boyut tablosu 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 ekleyerek bu gereksinimi karşılayabilirsiniz.

Dizin sütununu da ekleyebilmek için bu sorguyu "çok" tarafındaki sorguyla birleştirmeniz gerekir. Bu sorguları anlamsal 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, DimProductSubcategoryve 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ı birleştirerek tek ve normal dışı bir model tablosu oluşturmayı 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.
• Tek bir tabloya uygulanan filtrelerden daha az verimli olabilecek daha uzun ilişki filtresi yayma zincirlerinin geçişi gerekir.
• Veri 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.
• Birden fazla tablodan sütun oluşturan 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 büyük boyutlu tablolar için model depolama boyutunun artmasına neden olabilir.

Yavaşça değişen boyutlar

Yavaş değişen boyut (veya SCD), zaman içinde boyut üyelerinin değişimini uygun şekilde yöneten boyutdur. İş varlığı değerleri zaman içinde plansız bir şekilde yavaş değiştiğinde geçerlidir. E-posta adresi ve telefon numarası gibi iletişim ayrıntısı sütunları seyrek değiştiğinden, SCD'ye iyi bir örnek müşteri boyutudur. Buna karşılık, hisse senedinin 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 tablosu 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 1 SCD 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 tablosunun 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 2 SCD, 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 ve StartDate EndDate) ve büyük olasılıkla bir bayrak sütunu (örneğin, IsCurrent) içerir.

Örneğin, Adventure Works her 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 tabloda da vekil anahtar bulunmalıdır.

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. Bu değişiklikleri, değeri güncelleştirerek EndDate ve değeri önceki EndDate değerden başlayarak yeni bir sürüm StartDate ekleyerek kaydeder. Ayrıca, olgu tarihiyle ilgili boyut anahtarı değerini almak için ilgili olguların zamana dayalı bir arama kullanması gerekir. Power BI anlam modeli Power Query'yi kullandığı için bu sonucu oluşturamaz. Ancak, önceden yüklenmiş bir SCD Tür 2 boyut tablosundan veri yükleyebilir.

İpucu

Doku ambarında Type 2 SCD boyut tablosu uygulamayı öğrenmek için bkz . Geçmiş değişikliği yönetme.

Power BI anlam 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 gereksinimi elde etmek için Power BI anlam modeli boyut tablosu, 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 veya David Campbell (06/27/2019-Current)gibi David Campbell (12/15/2008-06/26/2019) 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 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 anlam 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 anlam modeli tablosu arasında yalnızca bir etkin ilişki olabilir. 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 fazlalığı olan karmaşık bir Veri bölmesi de 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 bir ö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 oynayan örnek için bir boyut tablosu oluşturmaktır. Her boyut tablosunu Power Query kullanarak başvuru sorgusu olarak veya DAX kullanarak hesaplanan tablo olarak oluşturabilirsiniz. Model, Ship Date her biri kendi bayi satış tablosu sütunlarıyla tek ve etkin ilişkisi olan bir Delivery Date tablo, tablo ve tablo içerebilirDate.

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 tabloları genellikle olgu tablolarına göre daha az satır depoladığından, bu nadiren sorun olur.

Her rol için model boyutu tabloları oluştururken iyi tasarım uygulamalarını izlemenizi öneririz:

• Sütun adlarının kendi kendine açıklayıcı olduğundan emin olun. Tüm tarih tablolarında bir Year sütun olması mümkün olsa da (sütun adları tablolarında benzersizdir), varsayılan görsel başlıklar tarafından kendi kendine açıklanmaz. Her boyut rolü tablosundaki sütunları yeniden adlandırarak tablonun adlı Ship Yearbir yıl sütununa sahip olması Ship Date vb. göz önünde bulundurun.
• İlgili olduğunda, tablo açıklamalarının rapor yazarlarına (Veri bölmesi araç ipuçları aracılığıyla) filtre yayma işleminin nasıl ayarlandığı hakkında geri bildirim sağladığından emin olun. Bu netlik, model birçok olgu tablosunu filtrelemek için kullanılan gibi Dategenel olarak adlandırılmış bir tablo içerdiğinde önemlidir. Bu tabloda bayi satış siparişi tarihi sütunuyla etkin bir ilişki olması durumunda, gibi Filters reseller sales by order datebir 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 cinsiyet veya yaş grubu gibi müşteri demografik sütunlarını içerir.

Gereksiz boyutun tasarım amacı, model depolama boyutunu küçültmek için birçok küçük boyutu tek bir boyutta birleştirmek ve daha az model tablosu oluşturarak Veri bölmesi dağınıklığı azaltmaktır.

Gereksiz boyut tablosu genellikle tüm boyut özniteliği üyelerinin Kartezyen ürünüdür ve her satırı benzersiz olarak tanımlamak için vekil anahtar sütunu bulunur. 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 tablosu olarak yüklersiniz. "Bire çok" model ilişkisinin oluşturulmasını desteklemek için dizin sütununun modele yüklenmesi için bu sorguyu olgu sorgusuyla da birleştirmeniz gerekir.

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 örnekte yalnızca bu sütundan oluşan bağımsız bir tablo oluşturmak mantıklı değildir çünkü model depolama boyutunu artırır ve Veri bölmesi dağınıklığıyla sonuçlanır.

Power BI anlam modelinde, satış siparişi numarası sütununu olgu tablosuna ekleyerek satış siparişi numarasına göre filtrelemeye veya gruplandırmaya izin vermek uygun olabilir. Daha önce tanıtılan ve tablo türlerini karıştırmamanız gereken bir özel durumdur (genellikle model tabloları boyut veya olgu 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 oluşturmak 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 bu, çoka çok boyut ilişkilerini tanımlamak için önerdiğimiz bir Power BI anlam 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 anlam modeli tasarımı hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Boyutlu modelleme Vikipedi makalesi
• Power BI Desktop'ta model ilişkileri
• 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
• Microsoft Fabric Warehouse'da boyutsal modelleme
• Sorularınız var mı? Doku Topluluğu'na sormayı deneyin
• Öneri? Fabric'i geliştirmek için fikirlere katkıda bulunma