Power BI Desktop'ta bileşik model kılavuzu

Makale
11/10/2023

Bu makale, Power BI bileşik modelleri geliştiren veri modelleyicilerini hedefler. Bileşik model kullanım örneklerini açıklar ve size tasarım yönergeleri sağlar. Bu kılavuz özellikle bileşik modelin çözümünüze uygun olup olmadığını belirlemenize yardımcı olabilir. Öyleyse, bu makale en uygun bileşik modelleri ve raporları tasarlamanıza da yardımcı olur.

Not

Bileşik modellere giriş bu makalede ele alınmıyor. Bileşik modelleri tam olarak bilmiyorsanız, önce Power BI Desktop'ta bileşik modelleri kullanma makalesini okumanızı öneririz.

Bileşik modeller en az bir DirectQuery kaynağından oluştuğundan model ilişkileri, DirectQuery modelleri ve DirectQuery modeli tasarım kılavuzu hakkında kapsamlı bir anlayışa sahip olmanız da önemlidir.

Bileşik model kullanım örnekleri

Tanım gereği bileşik model birden çok kaynak grubunu birleştirir. Kaynak grubu, içeri aktarılan verileri veya DirectQuery kaynağına bağlantıyı temsil edebilir. DirectQuery kaynağı bir ilişkisel veritabanı veya başka bir tablosal model olabilir; bu bir Power BI anlam modeli veya Analysis Services tablosal modeli olabilir. Tablosal model başka bir tablosal modele bağlandığında zincirleme olarak bilinir. Daha fazla bilgi için bkz . Power BI anlam modelleri ve Analysis Services için DirectQuery kullanma.

Not

Model tablosal bir modele bağlandığında ancak bunu ek verilerle genişletmediğinde, bileşik model değildir. Bu durumda, uzak bir modele bağlanan bir DirectQuery modelidir; bu nedenle yalnızca bir kaynak grubu içerir. Tablo adı, sütun sıralama düzeni veya biçim dizesi gibi kaynak model nesne özelliklerini değiştirmek için bu model türünü oluşturabilirsiniz.

Tablosal modellere bağlanmak, kurumsal bir anlam modelini genişletirken (Power BI anlam modeli veya Analysis Services modeli olduğunda) özellikle önemlidir. Kurumsal anlam modeli, bir veri ambarının geliştirilmesi ve çalıştırılması için temeldir. İş tanımlarını ve terminolojisini sunmak için veri ambarında verilerin üzerinde bir soyutlama katmanı sağlar. Power BI gibi fiziksel veri modelleri ve raporlama araçları arasında bağlantı olarak yaygın olarak kullanılır. Çoğu kuruluşta merkezi bir ekip tarafından yönetilir ve bu nedenle kuruluş olarak tanımlanır. Daha fazla bilgi için bkz . kurumsal BI kullanım senaryosu.

Aşağıdaki durumlarda bileşik model geliştirmeyi düşünebilirsiniz.

Modeliniz bir DirectQuery modeli olabilir ve performansı artırmak istiyorsunuz. Bileşik modelde, her tablo için uygun depolama alanını ayarlayarak performansı geliştirebilirsiniz. Kullanıcı tanımlı toplamalar da ekleyebilirsiniz. Bu iyileştirmelerin her ikisi de bu makalenin devamında açıklanmıştır.
DirectQuery modelini modele aktarılması gereken daha fazla veriyle birleştirmek istiyorsunuz. İçeri aktarılan verileri farklı bir veri kaynağından veya hesaplanan tablolardan yükleyebilirsiniz.
İki veya daha fazla DirectQuery veri kaynağını tek bir modelde birleştirmek istiyorsunuz. Bu kaynaklar ilişkisel veritabanları veya diğer tablosal modeller olabilir.

Not

Bileşik modeller belirli dış analiz veritabanlarına bağlantılar içeremez. Bu veritabanları SAP HANA'yı çok boyutlu bir kaynak olarak ele alırken SAP Business Warehouse ve SAP HANA'yı içerir.

Diğer model tasarım seçeneklerini değerlendirme

Power BI bileşik modelleri belirli tasarım zorluklarını çözebilir ancak yavaş performansa katkıda bulunabilir. Ayrıca, bazı durumlarda beklenmeyen hesaplama sonuçları oluşabilir (bu makalenin ilerleyen bölümlerinde açıklanmaktadır). Bu nedenlerden dolayı, mevcut olduklarında diğer model tasarım seçeneklerini değerlendirin.

Mümkün olduğunda, içeri aktarma modunda bir model geliştirmek en iyisidir. Bu mod, en yüksek tasarım esnekliğini ve en iyi performansı sağlar.

Ancak, büyük veri hacimleriyle veya neredeyse gerçek zamanlı veriler üzerinde raporlamayla ilgili zorluklar, içeri aktarma modelleri tarafından her zaman çözülemez. Bu iki durumda da, verilerinizin DirectQuery modu tarafından desteklenen tek bir veri kaynağında depolanmasını sağlayan bir DirectQuery modeli düşünebilirsiniz. Daha fazla bilgi için bkz . Power BI Desktop'ta DirectQuery modelleri.

İpucu

Amacınız yalnızca mevcut tablosal modeli daha fazla veriyle genişletmekse, mümkün olduğunca bu verileri mevcut veri kaynağına ekleyin.

Tablo depolama modu

Bileşik modelde, her tablo için depolama modunu ayarlayabilirsiniz (hesaplanan tablolar hariç).

DirectQuery: Büyük veri hacimlerini temsil eden veya gerçek zamanlıya yakın sonuçlar sağlaması gereken tablolar için bu modu ayarlamanızı öneririz. Veriler hiçbir zaman bu tablolara aktarılmayacaktır. Genellikle, bu tablolar özetlenmiş tablolar olan olgu türündeki tablolar olacaktır.
İçeri aktarma: DirectQuery veya Karma modunda olgu tablolarını filtrelemek ve gruplandırma amacıyla kullanılmayan tablolar için bu modu ayarlamanızı öneririz. Ayrıca, DirectQuery modu tarafından desteklenmeyen kaynaklara göre tablolar için tek seçenektir. Hesaplanan tablolar her zaman içeri aktarma tablolarıdır.
İkili: Aynı kaynaktan DirectQuery olgu türündeki tablolarla birlikte sorgulanma olasılığı olduğunda boyut türündeki tablolar için bu modu ayarlamanızı öneririz.
Karma: En son veri değişikliklerini gerçek zamanlı olarak eklemek istediğinizde veya içeri aktarma bölümleri aracılığıyla en sık kullanılan verilere hızlı erişim sağlamak istediğinizde ve veri ambarında daha seyrek kullanılan verilerin büyük bir kısmını bırakırken bu modu bir olgu tablosuna içeri aktarma bölümleri ve bir DirectQuery bölümü ekleyerek ayarlamanızı öneririz.

Power BI bileşik modeli sorguladığında birkaç olası senaryo vardır.

Yalnızca içeri aktaran veya çift tablo içeren sorgular: Power BI tüm verileri model önbelleğinden alır. Mümkün olan en hızlı performansı sunar. Bu senaryo, filtreler veya dilimleyici görselleri tarafından sorgulanan boyut türündeki tablolarda yaygındır.
Aynı kaynaktan çift tablo veya DirectQuery tablolarını sorgular: Power BI, DirectQuery kaynağına bir veya daha fazla yerel sorgu göndererek tüm verileri alır. Özellikle kaynak tablolarda uygun dizinler mevcut olduğunda iyi bir performans sunar. Bu senaryo, çift boyut türündeki tabloları ve DirectQuery olgu türündeki tabloları ilişkilendiren sorgular için yaygındır. Bu sorgular kaynak grubu içidir ve bu nedenle tüm bire bir veya bire çok ilişkileri normal ilişkiler olarak değerlendirilir.
Aynı kaynaktan çift tablo veya karma tablo sorgular: Bu senaryo, önceki iki senaryonun birleşimidir. Power BI, içeri aktarma bölümlerinde kullanılabilir olduğunda model önbelleğinden veri alır, aksi takdirde DirectQuery kaynağına bir veya daha fazla yerel sorgu gönderir. Özellikle kaynak tablolarda uygun dizinler mevcut olduğunda veri ambarında yalnızca bir veri dilimi sorgulandığından mümkün olan en hızlı performansı sunar. Çift boyut türündeki tablolara ve DirectQuery olgu türündeki tablolara gelince, bu sorgular kaynak grubu içidir ve bu nedenle tüm bire bir veya bire çok ilişkileri normal ilişkiler olarak değerlendirilir.
Diğer tüm sorgular: Bu sorgular kaynak grupları arası ilişkileri içerir. Bunun nedeni içeri aktarma tablosunun bir DirectQuery tablosuyla ilişkili olması veya çift tablonun farklı bir kaynaktan directQuery tablosuyla ilişkili olmasıdır; bu durumda içeri aktarma tablosu olarak davranır. Tüm ilişkiler sınırlı ilişkiler olarak değerlendirilir. Ayrıca DirectQuery olmayan tablolara uygulanan gruplandırmaların, gerçekleştirilmiş alt sorgular (sanal tablolar) olarak DirectQuery kaynağına gönderilmesi gerektiği anlamına gelir. Bu durumda, özellikle büyük gruplandırma kümeleri için yerel sorgu verimsiz olabilir.

Özetle şunları yapmanızı öneririz:

Bileşik modelin doğru çözüm olduğunu dikkatle göz önünde bulundurun; farklı veri kaynaklarının model düzeyinde tümleştirilmesine izin verirken, olası sonuçları olan tasarım karmaşıklıklarını da getirir (bu makalenin ilerleyen bölümlerinde açıklanmaktadır).
Bir tablo büyük veri hacimlerini depolayarak olgu türündeki bir tablo olduğunda veya gerçek zamanlıya yakın sonuçlar sağlaması gerektiğinde depolama modunu DirectQuery olarak ayarlayın.
Artımlı yenileme ilkesi ve gerçek zamanlı veriler tanımlayarak veya TOM, TMSL veya üçüncü taraf bir araç kullanarak olgu tablosunu bölümleyerek karma modu kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Anlam modelleri için artımlı yenileme ve gerçek zamanlı veriler ve Gelişmiş veri modeli yönetimi kullanım senaryosu.
Bir tablo boyut türündeki bir tablo olduğunda depolama modunu İkili olarak ayarlayın ve aynı kaynak grupta yer alan DirectQuery veya karma olgu türündeki tablolarla birlikte sorgulanır.
çift ve karma tablolar (ve bağımlı hesaplanan tablolar) için model önbelleğini kaynak veritabanlarıyla eşitlenmiş durumda tutmak için uygun yenileme sıklıklarını ayarlayın.
İlişkili sütun değerleri eşleşmediğinde sınırlı ilişkiler sorgu sonuçlarındaki satırları ortadan kaldıracağından, kaynak gruplar arasında veri bütünlüğünü sağlamaya çalışın (model önbelleği dahil).
Mümkün olduğunda, verimli birleşimler, filtreleme ve gruplandırma için uygun dizinlerle DirectQuery veri kaynaklarını iyileştirin.

Kullanıcı tanımlı toplamalar

DirectQuery tablolarına kullanıcı tanımlı toplamalar ekleyebilirsiniz. Amaçları, daha yüksek ayrıntılı sorgular için performansı geliştirmektir.

Toplamalar modelde önbelleğe alınırken, içeri aktarma tabloları gibi davranır (model tablosu gibi kullanılamazlar). DirectQuery modeline içeri aktarma toplamaları eklemek bileşik modele neden olur.

Not

Bazı bölümler içeri aktarma modunda çalıştığından karma tablolar toplamaları desteklemez. Tek bir DirectQuery bölümü düzeyinde toplamalar eklemek mümkün değildir.

Toplamanın temel bir kurala uygun olmasını öneririz: Satır sayısı, temel alınan tablodan en az 10 daha küçük bir faktör olmalıdır. Örneğin, temel alınan tabloda 1 milyar satır depolanırsa toplama tablosu 100 milyon satırı aşmamalıdır. Bu kural, toplamayı oluşturma ve sürdürme maliyetine göre yeterli performans kazancı elde edilmesini sağlar.

Kaynaklar arası grup ilişkileri

Model ilişkisi kaynak gruplara yayıldığında, çapraz kaynak grubu ilişkisi olarak bilinir. Kaynak grupları arası ilişkiler de sınırlı ilişkilerdir çünkü garantili "bir" taraf yoktur. Daha fazla bilgi için bkz . İlişki değerlendirmesi.

Not

Bazı durumlarda, kaynaklar arası grup ilişkisi oluşturmaktan kaçınabilirsiniz. Bu makalenin devamında Eşitleme dilimleyicilerini kullanma konusuna bakın.

Kaynaklar arası grup ilişkilerini tanımlarken aşağıdaki önerileri göz önünde bulundurun.

Düşük kardinaliteli ilişki sütunlarını kullanma: En iyi performans için ilişki sütunlarının düşük kardinaliteye sahip olmasını öneririz; bu da 50.000'den az benzersiz değer depolamaları gerektiği anlamına gelir. Bu öneri özellikle tablosal modeller birleştirildiğinde ve metin olmayan sütunlar için geçerlidir.
Büyük metin ilişkisi sütunları kullanmaktan kaçının: bir ilişkide metin sütunları kullanmanız gerekiyorsa, kardinaliteyi metin sütununun ortalama uzunluğuyla çarparak filtre için beklenen metin uzunluğunu hesaplayın. Olası metin uzunluğu 1.000.000 karakteri aşmamalıdır.
İlişki ayrıntı düzeyini yükseltme: Mümkünse, daha yüksek ayrıntı düzeyinde ilişkiler oluşturun. Örneğin, bir tarih tablosunu tarih anahtarına eklemek yerine ay anahtarını kullanın. Bu tasarım yaklaşımı, ilgili tablonun bir ay anahtarı sütunu içermesini gerektirir ve raporlar günlük olguları gösteremez.
Basit bir ilişki tasarımı elde etmeye çalışın: Yalnızca gerektiğinde çapraz kaynak grubu ilişkisi oluşturun ve ilişki yolundaki tablo sayısını sınırlamaya çalışın. Bu tasarım yaklaşımı, performansı iyileştirmeye ve belirsiz ilişki yollarından kaçınmaya yardımcı olur.

Uyarı

Power BI Desktop kaynaklar arası grup ilişkilerini kapsamlı bir şekilde doğrulamadığından, belirsiz ilişkiler oluşturmak mümkündür.

Kaynaklar arası grup ilişkisi senaryosu 1

Karmaşık bir ilişki tasarımı senaryosu ve sonuçların nasıl farklı ancak geçerli olabileceğine ilişkin bir senaryo düşünün.

Bu senaryoda, A kaynak grubundaki Region tablosunun, B kaynak grubundaki Date tablosu ve Sales tablosuyla ilişkisi vardır. Region tablosu ve Date tablosu arasındaki ilişki etkinken Region tablosu ile Sales tablosu arasındaki ilişki etkin değildir. Ayrıca Region tablosu ile Sales tablosu arasında etkin bir ilişki vardır ve her ikisi de B kaynak grubunda yer alır. Sales tablosu TotalSales adlı bir ölçü, Region tablosu ise RegionalSales ve RegionalSalesDirect adlı iki ölçü içerir.

Diyagram, önceki paragrafta açıklandığı gibi senaryo 1 modeli tasarımını gösterir.

Ölçü tanımları aşağıdadır.

TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID]))

RegionalSalesDirect ölçüsü değilken RegionalSales ölçüsünün TotalSales ölçüsüne nasıl başvurduğuna dikkat edin. Bunun yerine RegionalSalesDirect ölçüsü, TotalSales ölçüsünün ifadesi olan ifadesini kullanırSUM(Sales[Sales]).

Sonuçtaki fark hafiftir. Power BI RegionalSales ölçüsünü değerlendirdiğinde, Region tablosundaki filtreyi hem Sales tablosuna hem de Date tablosuna uygular. Bu nedenle, filtre Date tablosundan Sales tablosuna da yayılır. Buna karşılık, Power BI RegionalSalesDirect ölçüsünü değerlendirdiğinde, filtreyi yalnızca Region tablosundan Sales tablosuna yayılır. RegionalSales ölçüsü ve RegionalSalesDirect ölçüsü tarafından döndürülen sonuçlar, ifadeler eş değerde olsa bile farklı olabilir.

Önemli

işlevini uzak kaynak grubunda ölçü olan bir ifadeyle kullandığınızda CALCULATE hesaplama sonuçlarını kapsamlı bir şekilde test edin.

Kaynak grupları arası ilişki senaryosu 2

Kaynaklar arası grup ilişkisinin yüksek kardinalite ilişkisi sütunlarına sahip olduğu bir senaryo düşünün.

Bu senaryoda, Date tablosu DateKey sütunlarındaki Sales tablosuyla ilişkilidir. DateKey sütunlarının veri türü tamsayıdır ve yymmdd biçimini kullanan tamsayıları depolar. Tablolar farklı kaynak gruplarına aittir. Ayrıca, Tarih tablosundaki en erken tarih 1 Ocak 1900 ve en son tarih 31 Aralık 2100 olduğundan, tabloda toplam 73.414 satır vardır (1900-2100 zaman aralığındaki her tarih için bir satır).

Diyagram, önceki paragrafta açıklandığı gibi senaryo 2 modeli tasarımını gösterir.

Endişeye neden olan iki durum vardır.

İlk olarak, Tarih tablosu sütunlarını filtre olarak kullandığınızda, filtre yayma ölçüleri değerlendirmek için Sales tablosunun DateKey sütununu filtreler. 2022 gibi tek bir yıla göre filtreleme yaparken DAX sorgusu gibi Sales[DateKey] IN { 20220101, 20220102, …20221231 }bir filtre ifadesi içerir. Filtre ifadesindeki değerlerin sayısı büyük olduğunda veya filtre değerleri uzun dizeler olduğunda sorgunun metin boyutu son derece büyüyebilir. Power BI'ın uzun sorguyu oluşturması ve veri kaynağının sorguyu çalıştırması pahalıdır.

İkincisi, Yıl, Çeyrek veya Ay gibi Tarih tablosu sütunlarını gruplandırma sütunları olarak kullandığınızda, yıl, üç aylık dönem veya ay ile DateKey sütun değerlerinin tüm benzersiz birleşimlerini içeren filtreler elde eder. Gruplandırma sütunlarında ve ilişki sütununda filtreler içeren sorgunun dize boyutu son derece büyük olabilir. Bu, özellikle gruplandırma sütunlarının sayısı ve/veya birleştirme sütununun kardinalitesi ( DateKey sütunu) büyük olduğunda geçerlidir.

Performans sorunlarını gidermek için şunları yapabilirsiniz:

Veri kaynağına Date tablosunu ekleyerek tek bir kaynak grubu modeli elde edin (yani artık bileşik model değildir).
İlişkinin ayrıntı düzeyini yükseltir. Örneğin, her iki tabloya bir MonthKey sütunu ekleyebilir ve bu sütunlarda ilişki oluşturabilirsiniz. Ancak, ilişkinin ayrıntı düzeyini artırarak günlük satış etkinliğini raporlama becerisini kaybedersiniz (Sales tablosundaki DateKey sütununu kullanmadığınız sürece).

Kaynak grupları arası ilişki senaryosu 3

Kaynaklar arası grup ilişkisindeki tablolar arasında eşleşen değerler olmadığında bir senaryo düşünün.

Bu senaryoda, B kaynak grubundaki Date tablosunun bu kaynak gruptaki Sales tablosuyla ve ayrıca A kaynak grubundaki Hedef tabloyla ilişkisi vardır. Tüm ilişkiler, Yıl sütunlarıyla ilgili Tarih tablosundan bire çok'dır. Sales tablosu, satış tutarlarını depolayan bir SalesAmount sütunu, Target tablosunda ise hedef tutarları depolayan bir TargetAmount sütunu bulunur.

Diyagram, önceki paragrafta açıklandığı gibi senaryo 3 modeli tasarımını gösterir.

Date tablosu 2021 ve 2022 yıllarını depolar. Sales tablosunda 2021 (100) ve 2022 (200) yıllarına ilişkin satış tutarları, Hedef tablosunda ise gelecek yıl olan 2021 (100), 2022 (200) ve 2023 (300) için hedef tutarlar depolanmaktadır.

Diyagram, önceki paragrafta açıklandığı gibi senaryo 3 tablo verilerini gösterir.

Power BI tablo görseli, Date tablosundaki Year sütununda gruplandırma yaparak ve SalesAmount ve TargetAmount sütunlarını toplayarak bileşik modeli sorguladığında, 2023 için hedef tutar gösterilmez. Bunun nedeni, çapraz kaynak grubu ilişkisinin sınırlı bir ilişki olması ve dolayısıyla her iki tarafta da eşleşen değerin olmadığı satırları ortadan kaldıran semantiği kullanmasıdır INNER JOIN . Ancak, tarih tablosu filtresi değerlendirme için geçerli olmadığından doğru bir hedef tutar toplamı (600) oluşturur.

Diyagramda 2023 hedef miktarını göstermeyen bir tablo görseli gösterilir. Ayrıca toplam 600 olan hedef tutar, 2021 ve 2022 (100 ve 200) için gösterilen iki değere eşit değildir.

Date tablosu ile Hedef tablo arasındaki ilişki kaynak grubu içi ilişkiyse (Hedef tablonun B kaynak grubuna ait olduğu varsayılarak), görselde 2023 (ve diğer eşleşmeyen yılların) hedef tutarını göstermek için bir (Boş) yıl yer alır.

Önemli

Yanlış raporlanmayı önlemek için, boyut ve olgu tabloları farklı kaynak gruplarında bulunduğunda ilişki sütunlarında eşleşen değerler olduğundan emin olun.

Sınırlı ilişkiler hakkında daha fazla bilgi için bkz . İlişki değerlendirmesi.

Hesaplamalar

Bileşik modele hesaplanmış sütunlar ve hesaplama grupları eklerken belirli sınırlamaları dikkate almanız gerekir.

Hesaplanmış sütunlar

DirectQuery tablosuna eklenen ve verilerini Microsoft SQL Server gibi ilişkisel bir veritabanından alan hesaplanmış sütunlar, tek seferde tek bir satırda çalışan ifadelerle sınırlıdır. Bu ifadeler gibi SUMXDAX yineleyici işlevlerini veya gibi CALCULATEfiltre bağlamı değişiklik işlevlerini kullanamaz.

Not

Zincirlenmiş tablosal modellere bağlı hesaplanmış sütunlar veya hesaplanan tablolar eklemek mümkün değildir.

Uzak DirectQuery tablosundaki hesaplanmış sütun ifadesi yalnızca satır içi değerlendirmeyle sınırlıdır. Ancak, böyle bir ifade yazabilirsiniz, ancak bir görselde kullanıldığında hataya neden olur. Örneğin, ifadesini [Product Sales] / SUM (DimProduct[ProductSales])kullanarak DimProduct adlı uzak bir DirectQuery tablosuna hesaplanmış sütun eklerseniz, ifadeyi modele başarıyla kaydedebilirsiniz. Ancak, satır içi değerlendirme kısıtlamasını ihlal ettiği için görselde kullanıldığında hataya neden olur.

Buna karşılık, Power BI anlam modeli veya Analysis Services modeli olan tablosal model olan uzak directquery tablosuna eklenen hesaplanmış sütunlar daha esnektir. Bu durumda, ifade kaynak tablosal modelde değerlendirileceği için tüm DAX işlevlerine izin verilir.

Birçok ifade, Power BI'ın hesaplanmış sütunu grup veya filtre olarak kullanmadan veya toplamadan önce gerçekleştirmesini gerektirir. Hesaplanmış sütun büyük bir tablo üzerinde oluşturulduğunda, hesaplanmış sütunun bağımlı olduğu sütunların kardinalitesine bağlı olarak CPU ve bellek açısından pahalıya mal olabilir. Bu durumda, bu hesaplanmış sütunları kaynak modele eklemenizi öneririz.

Not

Bileşik modele hesaplanmış sütunlar eklediğinizde, tüm model hesaplamalarını test ettiğinizden emin olun. Yukarı akış hesaplamaları, filtre bağlamı üzerindeki etkilerini dikkate almadığından düzgün çalışmayabilir.

Hesaplama grupları

Hesaplama grupları Power BI anlam modeline veya Analysis Services modeline bağlanan bir kaynak grubunda varsa, Power BI beklenmeyen sonuçlar döndürebilir. Daha fazla bilgi için bkz . Hesaplama grupları, sorgu ve ölçü değerlendirmesi.

Model tasarımı

Yıldız şeması tasarımını benimseyerek bir Power BI modelini her zaman iyileştirmeniz gerekir.

İpucu

Daha fazla bilgi için bkz . Yıldız şemasını ve Power BI'ın önemini anlama.

Power BI'ın birleştirmeleri doğru yorumlayabilmesi ve verimli sorgu planları oluşturabilmesi için olgu tablolarından ayrı boyut tabloları oluşturduğunuzdan emin olun. Bu kılavuz herhangi bir Power BI modeli için geçerli olsa da, bileşik modelin kaynak grubu olacağını fark ettiğiniz modeller için özellikle geçerlidir. Aşağı akış modellerindeki diğer tabloların daha basit ve daha verimli tümleştirilmesine olanak tanır.

Mümkün olduğunda, boyut tablolarının farklı bir kaynak grubundaki olgu tablosuyla ilişkili bir kaynak grubunda yer almaktan kaçının. Bunun nedeni, özellikle yüksek kardinaliteli ilişki sütunları için kaynak grubu içi ilişkilerin, kaynak grup içi ilişkilere sahip olmaktan daha iyi olmasıdır. Daha önce açıklandığı gibi, kaynak grupları arası ilişkiler ilişki sütunlarında eşleşen değerlere sahip olmayı temel alır, aksi takdirde rapor görsellerinde beklenmeyen sonuçlar gösterilebilir.

Satır düzeyi güvenlik

Modeliniz kullanıcı tanımlı toplamalar, içeri aktarma tablolarındaki hesaplanmış sütunlar veya hesaplanan tablolar içeriyorsa, satır düzeyi güvenliğin (RLS) doğru ayarlandığından ve test edildiklerinden emin olun.

Bileşik model diğer tablosal modellere bağlanıyorsa, RLS kuralları yalnızca tanımlandığı kaynak gruba (yerel model) uygulanır. Diğer kaynak gruplarına (uzak modeller) uygulanmaz. Ayrıca, başka bir kaynak grubundan bir tabloda RLS kuralları tanımlayamazsınız veya başka bir kaynak grubuyla ilişkisi olan yerel bir tabloda RLS kuralları tanımlayabilirsiniz.

Rapor tasarımı

Bazı durumlarda, iyileştirilmiş bir rapor düzeni tasarlayarak bileşik modelin performansını geliştirebilirsiniz.

Tek kaynak grubu görselleri

Mümkün olduğunda, tek bir kaynak grubundaki alanları kullanan görseller oluşturun. Bunun nedeni, sonuç tek bir kaynak grubundan alındığında görseller tarafından oluşturulan sorguların daha iyi performans göstermesinden kaynaklanır. İki farklı kaynak grubundan veri alan yan yana konumlandırılmış iki görsel oluşturmayı göz önünde bulundurun.

Eşitleme dilimleyicilerini kullanma

Bazı durumlarda, modelinizde çapraz kaynak grubu ilişkisi oluşturmamak için eşitleme dilimleyicileri ayarlayabilirsiniz. Daha iyi performans gösterebilecek kaynak gruplarını görsel olarak birleştirmenizi sağlayabilir.

Modelinizde iki kaynak grubu olduğunda bir senaryo düşünün. Her kaynak grubu, kurumsal bayi ve internet satışlarını filtrelemek için kullanılan bir ürün boyutu tablosuna sahiptir.

Bu senaryoda, A kaynak grubu ResellerSales tablosuyla ilgili Product tablosunu içerir. B kaynak grubu, InternetSales tablosuyla ilişkili Product2 tablosunu içerir. Kaynak grupları arası ilişki yoktur.

Diyagram, önceki paragrafta açıklandığı gibi model tasarımını gösterir.

Raporda, Product tablosunun Color sütununu kullanarak sayfayı filtreleyen bir dilimleyici eklersiniz. Dilimleyici varsayılan olarak ResellerSales tablosunu filtreler ancak InternetSales tablosunu filtrelemez. Ardından, Product2 tablosunun Color sütununu kullanarak gizli bir dilimleyici eklersiniz. Aynı grup adını ayarlayarak (eşitleme dilimleyicileri Gelişmiş seçeneklerinde bulunur), görünür dilimleyiciye uygulanan filtreler otomatik olarak gizli dilimleyiciye yayılır.

Not

Eşitleme dilimleyicilerini kullanmak kaynak grupları arası ilişki oluşturma gereksinimini ortadan kaldırabilir ancak model tasarımının karmaşıklığını artırır. Modeli neden yinelenen boyut tablolarıyla tasarladığınız konusunda diğer kullanıcıları eğitmeye özen gösterin. Diğer kullanıcıların kullanmasını istemediğiniz boyut tablolarını gizleyerek karışıklığı önleyebilirsiniz. Ayrıca gizli tablolara açıklama metni ekleyerek bunların amacını belgeleyebilirsiniz.

Daha fazla bilgi için bkz . Ayrı dilimleyicileri eşitleme.

Diğer yönergeler

Bileşik modelleri tasarlamanıza ve korumanıza yardımcı olacak diğer bazı yönergeler aşağıda verilmiştir.

Performans ve ölçek: Raporlarınız daha önce bir Power BI anlam modeline veya Analysis Services modeline bağlıysa, Power BI hizmeti raporlar arasında görsel önbellekleri yeniden kullanabilir. Canlı bağlantıyı yerel bir DirectQuery modeli oluşturmak için dönüştürdükten sonra raporlar artık bu önbelleklerden yararlanamayacaktır. Sonuç olarak, daha yavaş performansla, hatta yenileme hatalarıyla karşılaşabilirsiniz. Ayrıca, Power BI hizmeti iş yükü artar ve bu da kapasitenizin ölçeğini artırmanızı veya iş yükünü diğer kapasitelere dağıtmanızı gerektirebilir. Veri yenileme ve önbelleğe alma hakkında daha fazla bilgi için bkz . Power BI'da veri yenileme.
Yeniden adlandırma: Bileşik modeller tarafından kullanılan anlamsal modelleri yeniden adlandırmanızı veya çalışma alanlarını yeniden adlandırmanızı önermeyiz. Bunun nedeni, bileşik modellerin çalışma alanı ve anlam modeli adlarını (iç benzersiz tanımlayıcılarını değil) kullanarak Power BI anlam modellerine bağlanmasıdır. Anlamsal modeli veya çalışma alanını yeniden adlandırmak, bileşik modeliniz tarafından kullanılan bağlantıları kesebilir.
İdare: Doğruluk modelinin tek sürümünün bileşik bir model olması önerilmez. Bunun nedeni, diğer veri kaynaklarına veya modellere bağımlı olması ve güncelleştirilirse bileşik modelin bozulmasına neden olmasıdır. Bunun yerine, bir kurumsal anlam modelini tek gerçeklik sürümü olarak yayımlamanızı öneririz. Bu modeli güvenilir bir temel olarak düşünün. Daha sonra diğer veri modelleyicileri, özel modeller oluşturmak için temel modeli genişleten bileşik modeller oluşturabilir.
Veri kökeni: Bileşik model değişikliklerini yayımlamadan önce veri kökeni ve anlamsal model etki analizi özelliklerini kullanın. Bu özellikler Power BI hizmeti kullanılabilir ve anlamsal modellerin nasıl ilişkili olduğunu ve kullanıldığını anlamanıza yardımcı olabilir. Köken görünümünde görüntülenen ancak aslında başka bir çalışma alanında bulunan dış anlam modelleri üzerinde etki analizi gerçekleştiremezseniz, bunu anlamanız önemlidir. Dış anlam modeli üzerinde etki analizi gerçekleştirmek için kaynak çalışma alanına gitmeniz gerekir.
Şema güncelleştirmeleri: Yukarı akış veri kaynaklarında şema değişiklikleri yapıldığında Power BI Desktop'ta bileşik modelinizi yenilemeniz gerekir. Ardından modeli Power BI hizmeti yeniden yayımlamanız gerekir. Hesaplamaları ve bağımlı raporları kapsamlı bir şekilde test etmeye özen gösterin.