Yıldız şemasını ve Power BI açısından önemini anlamaUnderstand star schema and the importance for Power BI

Bu makale Power BI Desktop veri modelleyicilerine yöneliktir.This article targets Power BI Desktop data modelers. Yıldız şeması tasarımı ve bunun performans ve kullanılabilirlik için iyileştirilmiş Power BI veri modellerinin geliştirilmesine neden uygun olduğu açıklanır.It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

Bu makalede yıldız şeması tasarımıyla ilgili eksiksiz bir açıklama sağlamak amaçlanmamıştır.This article isn't intended to provide a complete discussion on star schema design. Diğer ayrıntılar için doğrudan Ralph Kimball'un Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. Baskı, 2013) kitabı yayımlanmış içeriğe başvurun.For more details, refer directly to published content, like The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) by Ralph Kimball et al.

Yıldız şemasına genel bakışStar schema overview

Yıldız şeması ilişkisel veri ambarları tarafından yaygın olarak benimsenmiş olgun bir modelleme yaklaşımıdır.Star schema is a mature modeling approach widely adopted by relational data warehouses. Modelleyicilerin model tablolarını boyut veya olgu olarak sınıflandırmasını gerektirir.It requires modelers to classify their model tables as either dimension or fact.

Boyut tabloları iş varlıklarını, modellediğiniz şeyleri açıklar.Dimension tables describe business entities—the things you model. Varlıklar ürünlerden, kişilerden, yerlerden ve kavramlardan, ayrıca zamanın kendisinden oluşabilir.Entities can include products, people, places, and concepts including time itself. Yıldız şemasında bulabileceğiniz en tutarlı tablo tarih boyutu tablosudur.The most consistent table you'll find in a star schema is a date dimension table. Boyut tablosu benzersiz tanımlayıcı işlevi gören bir anahtar sütunu (veya sütunları) ile açıklayıcı sütunlar içerir.A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

Gözlemleri ve olayları depolayan olgu tabloları satış siparişleri, envanter bakiyeleri, döviz kurları, sıcaklıklar vb. olabilir. Olgu tablosu boyut tablolarıyla ilgili boyut anahtar sütunları ve sayısal ölçü sütunları içerir.Fact tables store observations or events, and can be sales orders, stock balances, exchange rates, temperatures, etc. A fact table contains dimension key columns that relate to dimension tables, and numeric measure columns. Boyut anahtar sütunları olgu tablosunun boyut özelliklerini belirlerken boyut anahtar değerleri de olgu tablosunun ayrıntı düzeyini belirler.The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. Örneğin satış hedeflerinin depolandığı, iki boyut anahtar sütunu (Date ve ProductKey) olan bir olgu tablosu tasarlandığını düşünün.For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. Tablonun iki boyutu olduğu kolayca anlaşılabilir.It's easy to understand that the table has two dimensions. Öte yandan ayrıntı düzeyi boyut anahtar değerleri dikkate alınmadan belirlenemez.The granularity, however, can't be determined without considering the dimension key values. Bu örnekte Date sütununda depolanan değerlerin her ayın ilk günü olduğunu düşünün.In this example, consider that the values stored in the Date column are the first day of each month. Bu örnekte ayrıntı düzeyi aylık ürün düzeyidir.In this case, the granularity is at month-product level.

Genel olarak boyut tabloları görece az sayıda satır içerir.Generally, dimension tables contain a relatively small number of rows. Öte yandan olgu tabloları çok fazla sayıda satır içerebilir ve zamanla bu sayı büyümeye devam eder.Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

Yıldız şemasının çizimi

Yıldız şemasının Power BI modellerine uygunluğuStar schema relevance to Power BI models

Bu makalede tanıtılan yıldız şeması tasarımı ve bununla ilgili birçok kavram, performans ve kullanılabilirlik için iyileştirilmiş Power BI modelleri geliştirmeyle son derece ilgilidir.Star schema design and many related concepts introduced in this article are highly relevant to developing Power BI models that are optimized for performance and usability.

Her Power BI raporu görselinin Power BI modeline gönderilen bir sorgu oluşturduğunu düşünün (Power BI hizmeti bir veri kümesi çağırır).Consider that each Power BI report visual generates a query that is sent to the Power BI model (which the Power BI service calls a dataset). Bu sorgular model verilerini filtrelemek, gruplandırmak ve özetlemek için kullanılır.These queries are used to filter, group, and summarize model data. İyi tasarlanmış bir model filtreleme ve gruplandırma için tablolar ve özetleme için tablolar sağlayan modeldir.A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. Bu tasarım, yıldız şemasının ilkelerine çok iyi uyar:This design fits well with star schema principles:

  • Boyut tabloları filtrelemeyi ve gruplandırmayı desteklerDimension tables support filtering and grouping
  • Olgu tabloları özetlemeyi desteklerFact tables support summarization

Modelleriyicilerin tablo türünü boyut veya olgu olarak yapılandırmak için ayarlayabilecekleri bir tablo özelliği yoktur.There's no table property that modelers set to configure the table type as dimension or fact. Aslında bu, model ilişkileri tarafından belirlenir.It's in fact determined by the model relationships. Model ilişkisi iki tablo arasında bir filtre yayma yolu oluşturur ve tablo türü ilişkinin Kardinalite özelliğiyle belirlenir.A model relationship establishes a filter propagation path between two tables, and it's the Cardinality property of the relationship that determines the table type. Yaygın bir ilişki kardinalitesi bire çok veya bunun tersi olan çoka bir ilişkidir.A common relationship cardinality is one-to-many or its inverse many-to-one. İlişkinin "bir" tarafı her zaman boyut türündeki tabloyken "çok" tarafı da her zaman olgu türünde tablodur.The "one" side is always a dimension-type table while the "many" side is always a fact-type table. İlişkiler hakkında daha fazla bilgi için bkz. Power BI Desktop’ta model ilişkileri.For more information about relationships, see Model relationships in Power BI Desktop.

Kavramsal yıldız şeması

İyi yapılandırılmış bir model tasarımı boyut türünde veya olgu türünde olan tablolar içermelidir.A well-structured model design should include tables that are either dimension-type tables or fact-type tables. Aynı tabloda bu iki türü karıştırmaktan kaçının.Avoid mixing the two types together for a single table. Ayrıca doğru ilişkileri olan doğru sayıda tablo sağlamak için çaba harcamanızı da öneririz.We also recommend that you should strive to deliver the right number of tables with the right relationships in place. Olgu türündeki tabloların her zaman tutarlı bir dilime sahip veriler yüklemesi de önemlidir.It's also important that fact-type tables always load data at a consistent grain.

Son olarak, en uygun model tasarımını yapmanın kısmen bilim kısmen de sanat olduğunu anlamalısınız.Lastly, it's important to understand that optimal model design is part science and part art. Bazen size mantıklı geldiğinde uygun yönergelerden uzaklaşabilirsiniz.Sometimes you can break with good guidance when it makes sense to do so.

Yıldız şeması tasarımında Power BI modeline uygulanabilecek birçok başka kavram da vardır.There are many additional concepts related to star schema design that can be applied to a Power BI model. Bu kavramlar şunlardır:These concepts include:

ÖlçülerMeasures

Yıldız şeması tasarımında ölçü özetlenecek değerlerin depolandığı bir olgu tablosu sütunudur.In star schema design, a measure is a fact table column that stores values to be summarized.

Power BI modelinde ölçünün farklı ama benzer bir tanımı vardır.In a Power BI model, a measure has a different—but similar—definition. Özetleme yapabilen Veri Çözümleme İfadeleri (DAX) dilinde yazılmış bir formüldür.It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. Ölçü ifadeleri çoğunlukla sorgu süresinde skaler bir değer sonucu üretmek için SUM, MIN, MAX ve AVERAGE gibi DAX toplama işlevlerinden yararlanır (değerler hiçbir zaman modelde depolanmaz).Measure expressions often leverage DAX aggregation functions like SUM, MIN, MAX, AVERAGE, etc. to produce a scalar value result at query time (values are never stored in the model). Ölçü ifadesi basit sütun toplamalarından filtre bağlamını ve/veya ilişki yayma işlemini geçersiz kılan daha gelişmiş formüllere kadar değişebilir.Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. Daha fazla bilgi için Power BI Desktop'ta DAX ile İlgili Temel Bilgiler makalesini okuyun.For more information, read the DAX Basics in Power BI Desktop article.

Power BI modellerinin özetlemeyi başarmak için ikinci bir yöntemi daha desteklediğini anlamanız önemlidir.It's important to understand that Power BI models support a second method for achieving summarization. Herhangi bir sütun ve genellikle de sayısal sütunlar rapor görseli veya Soru-Cevap kullanılarak özetlenebilir.Any column—and typically numeric columns—can be summarized by a report visual or Q&A. Bu sütunlara örtülü ölçüler denir.These columns are referred to as implicit measures. Birçok durumda ölçüler oluşturmanız gerekmediğinden bir model geliştiricisi olarak bu size kolaylık sağlar.They offer a convenience for you as a model developer, as in many instances you do not need to create measures. Örneğin Adventure Works bayi satışlarının Sales Amount (Satış Tutarı) sütunu, olası her toplama türü için bir ölçü oluşturmaya gerek kalmadan çok sayıda yolla (sum, count, average, median, min, max vb.) özetlenebilir.For example, the Adventure Works reseller sales Sales Amount column could be summarized in numerous ways (sum, count, average, median, min, max, etc.), without the need to create a measure for each possible aggregation type.

Alan listesinde simge örneği

Öte yandan basit sütun düzeyi özetlemelerinde bile ölçüler oluşturmanız için üç cazip neden vardır:However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • Rapor yazarlarınızın modeli Çok Boyutlu İfadeler (MDX) kullanarak sorgulayacağını biliyorsanız, modelin açık ölçüler içermesi gerekir.When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. Açık ölçüler DAX kullanılarak tanımlanır.Explicit measures are defined by using DAX. Power BI veri kümesi MDX kullanılarak sorgulandığında bu tasarım yaklaşımı son derece uygundur çünkü MDX sütun değerlerinin özetlemesini yapamaz.This design approach is highly relevant when a Power BI dataset is queried by using MDX, because MDX can't achieve summarization of column values. Özellikle, Excel'de Analiz yapılırken MDX kullanılır çünkü PivotTable’lar MDX sorguları gönderir.Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • Rapor yazarlarınızın MDX sorgu tasarımcısını kullanarak Power BI sayfalandırılmış raporları oluşturacağını biliyorsanız, modelin açık ölçüler içermesi gerekir.When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. Sunucu toplamalarını yalnızca MDX sorgu tasarımcısı destekler.Only the MDX query designer supports server aggregates. Bu nedenle rapor yazarlarının ölçülerin Power BI tarafından değerlendirilmesine (sayfalandırılmış rapor altyapısı yerine) ihtiyaç duyması halinde MDX sorgu tasarımcısını kullanmaları gerekir.So, if report authors need to have measures evaluated by Power BI (instead of by the paginated report engine), they must use the MDX query designer.
  • Rapor yazarlarınızın sütunları yalnızca belirli yollarla özetleyebildiğinden emin olmanız gerektiğinde.When you need to ensure that your report authors can only summarize columns in specific ways. Örneğin bayi satışlarının Unit Price (Birim Fiyatı) sütunu (birim başına ücreti temsil eder) özetlenebilir ama bu yalnızca belirli toplama işlevleri kullanılarak yapılabilir.For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. Hiçbir zaman toplanmamalıdır ama başka toplama işlevleriyle (min, max, average vb.) özetlemeye uygundur. Bu örnekte modelleyici Unit Price sütununu gizleyebilir ve tüm uygun toplama işlevleri için ölçüler oluşturabilir.It should never be summed, but it's appropriate to summarize by using other aggregation functions like min, max, average, etc. In this instance, the modeler can hide the Unit Price column, and create measures for all appropriate aggregation functions.

Bu tasarım yaklaşımı Power BI hizmetinde yazılan raporlarda ve Soru-Cevap için iyi sonuç verir.This design approach works well for reports authored in the Power BI service and for Q&A. Öte yandan Power BI Desktop canlı bağlantıları rapor yazarlarının Alanlar bölmesinde gizli alanları göstermesine izin verir ve sonuç olarak bu tasarım yaklaşımı aşılabilir.However, Power BI Desktop live connections allow report authors to show hidden fields in the Fields pane, which can result in circumventing this design approach.

Vekil anahtarlarSurrogate keys

Vekil anahtar yıldız şeması modellemesini desteklemek için tabloya eklediğiniz benzersiz bir tanımlayıcıdır.A surrogate key is a unique identifier that you add to a table to support star schema modeling. Tanımı gereği kaynak verilerde tanımlanmaz veya depolanmaz.By definition, it's not defined or stored in the source data. Yaygın olarak vekil anahtarlar ilişkisel veri ambarı boyut tablolarına eklenerek boyut tablosu satırlarının her biri için benzersiz tanımlayıcı sağlanır.Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

Power BI modeli ilişkilerinde bir tablodaki tek bir benzersiz sütun temel alınır ve bu sütun farklı bir tablodaki tek sütuna filtreleri yayar.Power BI model relationships are based on a single unique column in one table, which propagates filters to a single column in a different table. Modelinizde boyut türündeki bir tablo tek bir benzersiz sütun içermiyorsa, ilişkinin "bir" tarafına dönüşmesi için benzersiz tanımlayıcı eklemelisiniz.When a dimension-type table in your model doesn't include a single unique column, you must add a unique identifier to become the "one" side of a relationship. Power BI Desktop'ta Power Query dizin sütunu oluşturarak bu gereksinimi kolayca karşılayabilirsiniz.In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Power Query araç çubuğunda dizin sütunu oluşturma

Bu sorguyu "çok" tarafı sorgusuyla birleştirmeniz gerekir çünkü bu sayede ona da dizin sütunu ekleyebilirsiniz.You must merge this query with the "many"-side query so that you can add the index column to it also. Bu sorguları modele yüklediğinizde, model tabloları arasında bire çok ilişkisi oluşturabilirsiniz.When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

Kar tanesi boyutlarıSnowflake dimensions

Kar tanesi boyutu tek bir iş varlığı için bir dizi normalleştirilmiş tablodur.A snowflake dimension is a set of normalized tables for a single business entity. Örneğin Adventure Works ürünleri kategoriye ve alt kategoriye göre sınıflandırır.For example, Adventure Works classifies products by category and subcategory. Kategoriler alt kategorilere atanır ve ardından ürünler de alt kategorilere atanır.Categories are assigned to subcategories, and products are in turn assigned to subcategories. Adventure Works ilişkisel ve ambarında ürün boyutu normalleştirilir ve üç ilişkili tabloda depolanır: DimProductCategory, DimProductSubcategory ve DimProduct.In the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

Hayal gücünüzü kullanırsanız normalleştirilmemiş tabloların olgu tablosundan dışarı doğru konumlandırıldığını ve bunun bir kar tanesi tasarımı oluşturduğunu gözünüzde canlandırabilirsiniz.If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

Kar tanesi diyagramı örneği

Power BI Desktop'ta kar tanesi boyut tasarımını taklit etmeyi (belge kaynak verileriniz taklit ettiği için) veya kaynak tabloları tek model tablosuna tümleştirmeyi (normalleştirilmişlikten çıkarma) seçebilirsiniz.In Power BI Desktop, you can choose to mimic a snowflake dimension design (perhaps because your source data does) or integrate (denormalize) the source tables into a single model table. Genel olarak tek modelli tablonun avantajları çok modelli tabloların avantajlarına ağır basar.Generally, the benefits of a single model table outweigh the benefits of multiple model tables. En uygun karar veri hacimlerine ve modelin kullanılabilirlik gereksinimlerine bağlı olabilir.The most optimal decision can depend on the volumes of data and the usability requirements for the model.

Kar tanesi boyut tasarımını taklit etmeyi seçtiğinizde:When you choose to mimic a snowflake dimension design:

  • Power BI daha fazla tablo yükler, bu da depolama ve performans açılarından daha az verimlidir.Power BI loads more tables, which is less efficient from storage and performance perspectives. Bu tabloların model ilişkilerini destekleyen sütunlar içermesi gerekir ve bu da daha büyük model boyuta yol açabilir.These tables must include columns to support model relationships, and it can result in a larger model size.
  • Daha uzun ilişki yayma zincirlerinin geçirilmesi gerekir ve bu da büyük olasılıkla tek tabloya uygulanan filtrelerden daha az verimli olur.Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • Alanlar bölmesi rapor yazarlarına daha fazla model tablosu sunar ve bu da özellikle kar tanesi boyut tabloları yalnızca bir veya iki sütun içerdiğinde daha az sezgisel bir deneyime yol açabilir.The Fields pane presents more model tables to report authors, which can result in a less intuitive experience, especially when snowflake dimension tables contain just one or two columns.
  • Tablolara yayılmış bir hiyerarşi oluşturmak mümkün değildir.It's not possible to create a hierarchy that spans the tables.

Tek modelli tabloya tümleştirmeyi seçtiğinizde boyutun en yüksek ve en düşük dilimini kapsayan bir hiyerarşi de tanımlayabilirsiniz.When you choose to integrate into a single model table, you can also define a hierarchy that encompasses the highest and lowest grain of the dimension. Bir olasılıkla yedekli normalleştirilmişlikten çıkarılmış verilerin depolanması, özellikle de çok büyük boyut tabloları için model depolama boyutunun artmasına yol açabilir.Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

Boyut içindeki hiyerarşi

Yavaş değişen boyutlarSlowly changing dimensions

Yavaş değişen boyut (SCD) boyut üyelerinin zaman içindeki değişimini uygun bir şekilde yöneten boyuttur.A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. İş varlığı değerlerinin zaman içinde ve geçici olarak değiştiği durumlarda geçerli olur.It applies when business entity values change over time, and in an ad hoc manner. Müşteri boyutu, özellikle de bunun e-posta adresi ve telefon numarası gibi iletişim ayrıntıları sütunları yavaş değişen boyuta iyi bir örnektir.A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. Buna karşılık borsa fiyatı gibi boyut özniteliği sık sık değişen bazı boyutlar hızlı değişen boyut olarak kabul edilir.In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. Bu örneklerde yaygın tasarım yaklaşımı, hızlı değişen öznitelik değerlerini bir olgu tablosu ölçüsünde depolamaktır.The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

Yıldız şeması tasarım teorisi iki yaygın SCD türüne başvurur: Tür 1 ve Tür 2.Star schema design theory refers to two common SCD types: Type 1 and Type 2. Boyut türündeki tablo Tür 1 veya Tür 2 olabileceği gibi, farklı sütunlarda aynı anda her iki türü de destekleyebilir.A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

Tür 1 SCDType 1 SCD

Tür 1 SCD her zaman en son değerleri yansıtır ve kaynak verilerde değişiklikler algılandığında boyut tablosu verilerinin üzerine yazılır.A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. Bu tasarım yaklaşımı müşterinin e-posta adresi veya telefon numarası gibi tamamlayıcı değerlerin depolandığı sütunlarda yaygın olarak kullanılır.This design approach is common for columns that store supplementary values, like the email address or phone number of a customer. Müşterinin e-posta adresi veya telefon numarası değiştiğinde boyut tablosu müşteri satırını yeni değerlerle güncelleştirir.When a customer email address or phone number changes, the dimension table updates the customer row with the new values. Müşterinin iletişim bilgileri hep böyleymiş gibi olur.It's as if the customer always had this contact information.

Tür 1 SCD'nin sonucu, Power BI modeli boyut türündeki tablonun artımlı olmayan yenilemesiyle elde edilir.A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. En son verilerin yüklendiğinden emin olmak için tablo verilerini yeniler.It refreshes the table data to ensure the latest values are loaded.

Tür 2 SCDType 2 SCD

Tür 2 SCD boyut üyelerinin sürümlerini oluşturmayı destekler.A Type 2 SCD supports versioning of dimension members. Kaynak sistem sürümleri depolamıyorsa, değişiklikleri algılayan ve boyut tablosunda bu değişiklikleri uygun şekilde yöneten genellikle veri ambarı yükleme işlemi olur.If the source system doesn't store versions, then it's usually the data warehouse load process that detects changes, and appropriately manages the change in a dimension table. Bu durumda boyut tablosunun, boyut üyesinin sürümüne yönelik benzersiz bir başvuru sağlamak üzere vekil anahtar kullanması gerekir.In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. Ayrıca geçerli boyut üyelerine göre kolayca filtreleme yapabilmek için sürümün tarih aralığı geçerliliğini tanımlayan sütunlar (örneğin StartDate ve EndDate) ve olasılıkla bir bayrak sütunu da (örneğin IsCurrent) içerir.It also includes columns that define the date range validity of the version (for example, StartDate and EndDate) and possibly a flag column (for example, IsCurrent) to easily filter by current dimension members.

Örneğin Adventure Works satış bölgelerine satış elemanları atar.For example, Adventure Works assigns salespeople to a sales region. Bir satış elemanının bölgesi değiştiğinde, geçmiş olgularının eski bölgeyle ilişkili kalmasını sağlamak için satış elemanına yeni bir sürüm oluşturmak gerekir.When a salesperson relocates region, a new version of the salesperson must be created to ensure that historical facts remain associated with the former region. Satış elemanına göre satışlarla ilgili doğru geçmiş analizini desteklemek için, boyut tablosu satış elemanlarının ve ilişkili bölgelerinin sürümlerini depolamalıdır.To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). Tablo ayrıca zaman geçerliliğini tanımlamak üzere başlangıç ve bitiş tarihi değerlerini de içermelidir.The table should also include start and end date values to define the time validity. Satırın geçerli sürüm olduğunu göstermek üzere geçerli sürümlerde Current boş bir bitiş tarihi (veya 31/12/9999) tanımlanabilir.Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. Tablo aynı zamanda bir de vekil anahtar tanımlamalıdır çünkü iş anahtarı (bu örnekte çalışan kimliği) benzersiz olmayacaktır.The table must also define a surrogate key because the business key (in this instance, employee ID) won't be unique.

Kaynak verilerde sürüm depolanmadığında, değişiklikleri algılamak ve depolamak için bir ara sistem (veri ambarı gibi) kullanmanız gerektiğini anlamanız önemlidir.It's important to understand that when the source data doesn't store versions, you must use an intermediate system (like a data warehouse) to detect and store changes. Tablo yükleme işlemi mevcut verileri korumalı ve değişiklikleri algılamalıdır.The table load process must preserve existing data and detect changes. Değişiklik algılandığında tablo yükleme işleminin geçerli sürümün süresini sona erdirmesi gerekir.When a change is detected, the table load process must expire the current version. EndDate değerini güncelleştirerek ve StartDate değeri önceki EndDate değerinden başlayan yeni bir sürüm ekleyerek bu değişiklikleri kaydeder.It records these changes by updating the EndDate value and inserting a new version with the StartDate value commencing from the previous EndDate value. Ayrıca, ilgili olgular olgu tarihine uygun boyut anahtarı değerini almak için zamana dayalı bir arama kullanmalıdır.Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. Power Query kullanan bir Power BI modeli bu sonucu üretemez.A Power BI model using Power Query can't produce this result. Bununla birlikte önceden yüklenmiş bir SCD Type 2 boyut tablosundan verileri yükleyebilir.It can, however, load data from a pre-loaded SCD Type 2 dimension table.

Power BI modeli değişikliğe bakılmaksızın üyenin ve üye sürümünün (üyenin zaman içindeki belirli bir durumunu temsil eder) geçmiş verilerini sorgulamayı desteklemelidir.The Power BI model should support querying historical data for a member, regardless of change, and for a version of the member, which represents a particular state of the member in time. Adventure Works bağlamında baktığımızda bu tasarım, hangi satış bölgesine atanmış olursa olsun satış elemanını veya satış elemanının belirli bir sürümünü sorgulamanıza olanak tanır.In the context of Adventure Works, this design enables you to query the salesperson regardless of assigned sales region, or for a particular version of the salesperson.

Bu gereksinimi karşılamak için Power BI modeli boyut türündeki tablosunda satış elemanını filtreleme sütunu ve bir de satış elemanının belirli bir sürümünü filtreleme sütunu bulunmalıdır.To achieve this requirement, the Power BI model dimension-type table must include a column for filtering the salesperson, and a different column for filtering a specific version of the salesperson. Sürüm sütununun "Michael Blythe (12/15/2008-06/26/2019)" veya "Michael Blythe (güncel)" gibi belirgin bir açıklama sağlaması önemlidir.It's important that the version column provides a non-ambiguous description, like "Michael Blythe (12/15/2008-06/26/2019)" or "Michael Blythe (current)". Ayrıca rapor yazarlarıyla tüketicilerine SCD Tür 2 ile ilgili eğitim vermek ve doğru filtreleri uygulayarak uygun rapor tasarımları elde etmeyi öğretmek de önemlidir.It's also important to educate report authors and consumers about the basics of SCD Type 2, and how to achieve appropriate report designs by applying correct filters.

Görsellerin sürüm düzeyinde detaya gitmesine izin veren bir hiyerarşi eklemek de iyi bir yöntem olabilir.It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

Alan listesinde hiyerarşi örneği

Hiyerarşi örneği çıkışı

Rol yapan boyutlarRole-playing dimensions

Rol yapan boyut, ilgili olguları farklı filtreleyebilen bir boyuttur.A role-playing dimension is a dimension that can filter related facts differently. Örneğin Adventure Works'te tarih boyut tablosunun bayi satış olgularıyla üç ilişkisi vardır.For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. Aynı boyut tablosu olguları sipariş tarihine, sevk tarihine veya teslim tarihine göre filtrelemek için kullanılabilir.The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

Veri ambarında kabul edilen tasarım yaklaşımı tek tarihli boyut tablosu tanımlamaktır.In a data warehouse, the accepted design approach is to define a single date dimension table. Sorgu zamanında tarih boyutunun "rolü", tabloları birleştirmek için kullandığınız olgu sütunu tarafından belirlenir.At query time, the "role" of the date dimension is established by which fact column you use to join the tables. Örneğin sipariş tarihine göre satışları analiz ederken tablo birleştirmesi bayi satış siparişi tarihi sütunuyla ilgilidir.For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

Power BI modelinde bu tasarım iki tablo arasında birden çok ilişki oluşturularak taklit edilebilir.In a Power BI model, this design can be imitated by creating multiple relationships between two tables. Adventure Works örneğinde tarih ile bayi satış tabloları arasında üç ilişki olabilir.In the Adventure Works example, the date and reseller sales tables would have three relationships. Bu tasarım mümkün olsa da, iki Power BI modeli tablosu arasında tek bir etkin ilişki olabileceğini anlamanız önemlidir.While this design is possible, it's important to understand that there can only be one active relationship between two Power BI model tables. Kalan tüm ilişkiler etkin değil olarak ayarlanmalıdır.All remaining relationships must be set to inactive. Tek etkin ilişki olması tarihten bayi satışlarına varsayılan bir filtre yayılması olduğu anlamına gelir.Having a single active relationship means there is a default filter propagation from date to reseller sales. Bu örnekte etkin ilişki raporlar tarafından kullanılan en yaygın filtreye, Adventure Works'te sipariş tarih ilişkisine ayarlanmıştır.In this instance, the active relationship is set to the most common filter that is used by reports, which at Adventure Works is the order date relationship.

Tek rol yapan boyut ve ilişkiler örneği

Etkin olmayan ilişki kullanmanın tek yolu USERELATIONSHIP işlevini kullanan bir DAX ifadesi tanımlamaktır.The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. Bizim örneğimizde model geliştiricisinin sevk tarihine ve teslim tarihine göre bayi satışlarını analiz etmeye olanak tanımak için ölçüler oluşturması gerekir.In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. Özellikle de bayi tablosunun çok sayıda ölçü tanımladığı durumlarda bu bıktırıcı bir çalışma olabilir.This work can be tedious, especially when the reseller table defines many measures. Ayrıca ölçülerin aşırı bolluğu nedeniyle Alanlar bölmesinde dağınıklığa da yol açar.It also creates Fields pane clutter, with an overabundance of measures. Başka sınırlamaları da vardır:There are other limitations, too:

  • Rapor yazarları ölçüleri tanımlamak yerine sütunları özetlemeye dayandığında, rapor düzeyi bir ölçü yazmadan etkin olmayan ilişkileri özetlemeyi başaramaz.When report authors rely on summarizing columns, rather than defining measures, they can't achieve summarization for the inactive relationships without writing a report-level measure. Rapor düzeyi ölçüleri ancak raporlar Power BI Desktop'ta yazılırken tanımlanabilir.Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • Tarih ile bayi satışları arasında tek bir etkin ilişki yolu olduğunda bayi satışlarını farklı tarih türlerine göre eş zamanlı olarak filtrelemek mümkün olmaz.With only one active relationship path between date and reseller sales, it's not possible to simultaneously filter reseller sales by different types of dates. Örneğin sevk edilen satışlara göre sipariş tarihi satışlarının çizildiği bir görsel oluşturamazsınız.For example, you can't produce a visual that plots order date sales by shipped sales.

Bu sınırlamaları aşmak için yaygın kullanılan bir Power BI modelleme tekniği her rol yapan örnek için boyut türünde bir tablo oluşturmaktır.To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. Normalde DAX kullanarak ek boyut tablolarını hesaplanan tablolar olarak oluşturursunuz.You typically create the additional dimension tables as calculated tables, using DAX. Hesaplanan tablolar kullanıldığında model bir Date (Tarih) tablosu, bir Ship Date (Sevk Tarihi) tablosu ve bir de Delivery Date (Teslim Tarihi) tablosu içerebilir. Her birinin kendi ilgili bayi satış tablosu sütunlarıyla tek ve etkin bir ilişkisi olur.Using calculated tables, the model can contain a Date table, a Ship Date table and a Delivery Date table, each with a single and active relationship to their respective reseller sales table columns.

Rol yapan boyutlar ve ilişkiler örneği

Bu tasarım yaklaşımında farklı tarih rolleri için birden çok ölçü tanımlamanız gerekmez ve aynı anda farklı tarih rollerine göre filtrelemeye olanak tanınır.This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. Bu tasarım yaklaşımında ödenecek küçük bir bedel vardır: Tarih boyutu tablosunun çoğaltılması model depolama boyutunun artmasına yol açar.A minor price to pay, however, with this design approach is that there will be duplication of the date dimension table resulting in an increased model storage size. Boyut türündeki tablolar normalde olgu türündeki tablolara göre daha az satır depoladığından bu durum pek sorun yaratmaz.As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

Her rol için model boyut türünde tablolar oluştururken aşağıdaki iyi tasarım yöntemlerine dikkat edin:Observe the following good design practices when you create model dimension-type tables for each role:

  • Sütun adlarının açıklayıcı olduğundan emin olun.Ensure that the column names are self-describing. Tüm tarih tablolarında bir Year (Yıl) sütunu olabilir (sütun adları kendi tabloları içinde benzersizdir) ama bu ad varsayılan olarak görsel başlıklarında pek açıklayıcı değildir.While it's possible to have a Year column in all date tables (column names are unique within their table), it's not self-describing by default visual titles. Boyut rol tablolarının her birinde sütunları yeniden adlandırmayı göz önünde bulundurun; böylelikle örneğin Ship Date (Sevk Tarihi) tablosunda Ship Year (Sevk Yılı) adlı bir yıl sütunu bulunabilir.Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • Uygun olduğunda tablo açıklamalarının rapor yazarlarına (Alanlar bölmesi araç ipuçları yoluyla) filtre yayılımının nasıl yapılandırıldığına ilişkin geri bildirim sağladığından emin olun.When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. Modelde olgu türünde birçok tabloyu filtrelemek için kullanılan Date (Tarih) gibi genel adlı bir tablo olduğunda, bu netliği sağlamak önemlidir.This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. Örneğin bu tablonun bayi satış siparişi sütunuyla etkin bir ilişkisi olması gibi durumlarda "Bayi satışlarını sipariş tarihine göre filtreler" gibi bir tablo açıklaması sağlamayı dikkate alın.In the case that this table has, for example, an active relationship to the reseller sales order date column, consider providing a table description like "Filters reseller sales by order date".

Daha fazla bilgi için bkz. Etkin ve etkin olmayan ilişki karşılaştırması kılavuzu.For more information, see Active vs inactive relationship guidance.

Gereksiz boyutlarJunk dimensions

Gereksiz boyutlar, özellikle az sayıda (belki de bir) öznitelikten oluşan çok fazla boyut olduğunda ve bu özniteliklerin de çok az değeri olduğunda yararlıdır.A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. İyi adaylar arasında sipariş durumu sütunları veya müşteri demografisi sütunları (cinsiyet, yaş grubu vb.) sayılabilir.Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

Gereksiz boyutun tasarım amacı, hem model depolama boyutunu küçültmek hem de daha az model tablosu ortaya koyarak Alanlar bölmesindeki dağınıklığı azaltmak için birçok "küçük" boyutu tek bir boyutta birleştirmektir.The design objective of a junk dimension is to consolidate many "small" dimensions into a single dimension to both reduce the model storage size and also reduce Fields pane clutter by surfacing fewer model tables.

Gereksiz boyut tablosu normalde tüm boyut öznitelik üyelerinin bir vekil anahtar sütunuyla Kartezyen çarpımıdır.A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. Vekil anahtar tablodaki her satıra benzersiz bir başvuru sağlar.The surrogate key provides a unique reference to each row in the table. Boyutu bir veri ambarında oluşturabileceğiniz gibi, Power Query kullanıp tam dış sorgu birleştirmeleri gerçekleştiren bir sorgu oluşturarak ve ardından vekil anahtar (dizin sütunu) ekleyerek de oluşturabilirsiniz.You can build the dimension in a data warehouse, or by using Power Query to create a query that performs full outer query joins, then adds a surrogate key (index column).

Gereksiz boyut örneği

Bu sorguyu bir boyut türünde tablo olarak modele yüklersiniz.You load this query to the model as a dimension-type table. Ayrıca bu sorguyu olgu sorgusuyla birleştirmeniz gerekir, dolayısıyla dizin sütunu bir "bire çok" model ilişkisi oluşturmayı desteklemek için modele yüklenir.You also need to merge this query with the fact query, so the index column is loaded to the model to support the creation of a "one-to-many" model relationship.

Bozuk boyutlarDegenerate dimensions

Bozuk boyutlar, olgu tablosunun filtreleme için gereken bir özniteliğine karşılık gelir.A degenerate dimension refers to an attribute of the fact table that is required for filtering. Adventure Works'te bayi satışları sipariş numarası iyi bir örnektir.At Adventure Works, the reseller sales order number is a good example. Bu örnekte, yalnızca bu tek sütundan oluşan bağımsız bir tablo oluşturmak anlamlı bir model tasarımı değildir çünkü modelin depolama boyutunu artırabilir ve Alanlar bölmesinde dağınıklığa yol açabilir.In this case, it doesn't make good model design sense to create an independent table consisting of just this one column, because it would increase the model storage size and result in Fields pane clutter.

Power BI modelinde satış sipariş numarası sütununu olgu türündeki tabloya ekleyip satış sipariş numarasına göre filtrelemeye olanak tanımak uygun olabilir.In the Power BI model, it can be appropriate to add the sales order number column to the fact-type table to allow filtering or grouping by sales order number. Bu daha önce belirtilen tablo türlerini karıştırmama kuralına (örneğin, model tabloları ya boyut türünde ya da olgu türünde olmalıdır) karşı özel bir durumudur.It is an exception to the formerly introduced rule that you should not mix table types (generally, model tables should be either dimension-type or fact-type).

Bozuk boyut örneği

Ancak Adventure Work kurumsal bayiler satış masasında sipariş numarası ve sipariş sıra numarası sütunları varsa ve bunlara filtreleme için ihtiyaç duyuluyorsa bozuk boyut tablosu iyi bir tasarım olabilir.However, if the Adventure Works resellers sales table has order number and order line number columns, and they're required for filtering, a degenerate dimension table would be a good design. Daha fazla bilgi için bkz. Birebir ilişki kılavuzu (Bozuk boyutlar).For more information, see One-to-one relationship guidance (Degenerate dimensions).

Olgu içermeyen olgu tablolarıFactless fact tables

Olgu içermeyen olgu tablosu hiçbir ölçü sütunu içermez.A factless fact table doesn't include any measure columns. Yalnızca boyut anahtarlarını içerir.It contains only dimension keys.

Olgu içermeyen olgu tablosu boyut anahtarları tarafından tanımlanan gözlemleri depolayabilir.A factless fact table could store observations defined by dimension keys. Örneğin belirli bir tarih ve saatte belirli bir müşteri web sitenizde oturum açmıştır.For example, at a particular date and time, a particular customer logged into your web site. Kaç müşterinin ne zaman oturum açtığıyla ilgili bir analiz yapmak için olgu içermeyen olgu tablosunun satırlarını sayan bir ölçü tanımlayabilirsiniz.You could define a measure to count the rows of the factless fact table to perform analysis of when and how many customers have logged in.

Olgu içermeyen olgu tablosunun daha cazip bir kullanımı, boyutlar arasındaki ilişkileri depolamaktır ve bu da çoklu boyut ilişkilerini tanımlamayı önerdiğimiz Power BI modeli tasarım yaklaşımıdır.A more compelling use of a factless fact table is to store relationships between dimensions, and it's the Power BI model design approach we recommend defining many-to-many dimension relationships. Çoklu boyut ilişkisi tasarımında olgu içermeyen olgu tablosuna bir köprü oluşturma tablosu denir.In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

Örneğin, satış elemanlarının bir veya birden çok satış bölgesine atanabildiğini düşünün.For example, consider that salespeople can be assigned to one or more sales regions. Köprü oluşturma tablosu, iki sütundan oluşan bir olgu içermeyen olgu tablosu olarak tasarlanabilir: satış elemanı anahtarı ve bölge anahtarı.The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. Yinelenen değerler her iki sütunda da depolanabilir.Duplicate values can be stored in both columns.

Olgu içermeyen olgu tablosu örneği

Bu çoklu tasarım yaklaşımı iyi belgelenmiştir ve köprü oluşturma tablosu olmadan da başarılabilir.This many-to-many design approach is well documented, and it can be achieved without a bridging table. Öte yandan, iki boyut ilişkilendirilirken köprü oluşturma tablosunun en iyi yöntem olduğu düşünülür.However, the bridging table approach is considered the best practice when relating two dimensions. Daha fazla bilgi için bkz. Çoka çok ilişki kılavuzu (Boyut türündeki iki tabloyu ilişkilendirme).For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

Sonraki adımlarNext steps

Yıldız şeması tasarımı ve Power BI modeli tasarımı hakkında daha fazla bilgi için aşağıdaki makalelere bakın:For more information about star schema design or Power BI model design, see the following articles: