Microsoft Fabric Warehouse'da boyut modelleme: Boyut tabloları

Şunlar için geçerlidir: Microsoft Fabric'te SQL analiz uç noktası ve Ambarı

Not

Bu makale, Boyutsal modelleme makale serisinin bir bölümünü oluşturur. Bu seri, Microsoft Fabric Warehouse'da boyutsal modellemeyle ilgili rehberlik ve tasarım en iyi yöntemlerine odaklanır.

Bu makalede boyut tablolarını boyut modelinde tasarlamaya yönelik yönergeler ve en iyi yöntemler sağlanır. Tablo oluşturma ve tablolardaki verileri yönetme gibi birçok T-SQL özelliklerini destekleyen bir deneyim olan Microsoft Fabric'teki Warehouse için pratik rehberlik sağlar. Bu nedenle, boyutsal model tablolarınızı oluşturma ve bunları verilerle yükleme konusunda tam denetime sahip olursunuz.

Not

Bu makalede, veri ambarı terimi kuruluş genelinde kritik verilerin kapsamlı tümleştirmesini sağlayan kurumsal veri ambarını ifade eder. Buna karşılık, tek başına terim ambarı, veri ambarı uygulamak için kullanabileceğiniz bir hizmet olarak yazılım (SaaS) ilişkisel veritabanı teklifi olan Doku Ambarı'nı ifade eder. Netlik için, bu makalede ikincisinde Doku Ambarı olarak bahsedilmektedir.

İpucu

Boyutsal modelleme konusunda deneyimli değilseniz ilk adımınız olan bu makale serisini göz önünde bulundurun. Boyutsal modelleme 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.

Boyutsal modelde boyut tablosu, iş ve analiz gereksinimlerinizle ilgili bir varlığı açıklar. Boyut tabloları, modellediğiniz öğeleri geniş bir şekilde temsil eden tablolardır . Ürünler, kişiler, yerler veya tarih ve saat de dahil olmak üzere başka bir kavram olabilir. Boyut tablolarını kolayca tanımlamak için, genellikle adlarına d_ veya Dim_ön ekini eklersiniz.

Boyut tablosu yapısı

Boyut tablosunun yapısını açıklamak için adlı d_Salespersonsatış temsilcisi boyut tablosunun aşağıdaki örneğini göz önünde bulundurun. Bu örnek iyi tasarım uygulamaları uygular. Sütun gruplarının her biri aşağıdaki bölümlerde açıklanmıştır.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Vekil anahtar

Örnek boyut tablosunda adlı Salesperson_SKbir vekil anahtar vardır. Vekil anahtar, boyut tablosunda oluşturulan ve depolanan tek sütunlu benzersiz bir tanımlayıcıdır. Boyutsal modeldeki diğer tablolarla ilişkilendirmek için kullanılan birincil anahtar sütunu.

Vekil anahtarlar, veri ambarını kaynak verilerdeki değişikliklerden yalıtmaya çalışır. Ayrıca, şunları yapmanızı sağlayan başka birçok avantaj da sunar:

• Birden çok veri kaynağını birleştirin (yinelenen tanımlayıcıların çakışmasını önleyerek).
• Çok sütunlu doğal anahtarları daha verimli, tek sütunlu bir anahtarda birleştirin.
• Yavaş değişen boyut (SCD) türü 2 ile boyut geçmişini izleyin.
• Depolama iyileştirmesi için olgu tablosu genişliğini sınırlayın (mümkün olan en küçük tamsayı veri türünü seçerek).

Vekil anahtar sütunu, doğal anahtar (bundan sonra açıklanmıştır) kabul edilebilir bir aday gibi görünse bile önerilen bir uygulamadır. Anahtar değerlerine anlam vermekten de kaçınmanız gerekir (daha sonra açıklandığı gibi tarih ve saat boyut anahtarları hariç).

Doğal anahtarlar

Örnek boyut tablosunda da adlı EmployeeIDbir doğal anahtar vardır. Doğal anahtar, kaynak sistemde depolanan anahtardır. Boyut verilerini kaynak sistemiyle ilişkilendirerek boyut tablosunu yüklemek için genellikle Ayıklama, Yükleme ve Dönüştürme (ETL) işlemi tarafından yapılır. Bazen doğal anahtara iş anahtarı adı verilir ve değerleri iş kullanıcıları için anlamlı olabilir.

Bazen boyutların doğal bir anahtarı olmaz. Tarih boyutunuz veya arama boyutlarınız için veya düz bir dosyayı normalleştirerek boyut verileri oluşturduğunuzda bu durum söz konusu olabilir.

Boyut öznitelikleri

Örnek boyut tablosunda sütun gibi FirstName boyut öznitelikleri de vardır. Boyut öznitelikleri, ilgili olgu tablolarında depolanan sayısal verilerin bağlamını sağlar. Bunlar genellikle analiz sorgularında filtrelemek ve gruplandırmak (dilim ve zar) için kullanılan, ancak kendilerinin toplanmadığı metin sütunlarıdır. Bazı boyut tabloları birkaç öznitelik içerirken, diğerleri birçok öznitelik içerir (boyutsal modelin sorgu gereksinimlerini desteklemek için gereken kadar).

İpucu

İhtiyacınız olan boyutları ve öznitelikleri belirlemenin iyi bir yolu, doğru kişileri bulmak ve doğru soruları sormaktır. Özellikle, sözcüğün bahsetmesi için uyarıda kalın. Örneğin, birisi satış temsilcisine göre, aya ve ürün kategorisine göre satışları analiz etmek gerektiğini söylediğinde, size bu özniteliklere sahip boyutlara ihtiyacı olduğunu söyler.

Direct Lake semantik modeli oluşturmayı planlıyorsanız, boyut öznitelikleri olarak filtreleme ve gruplandırma için gereken tüm olası sütunları eklemeniz gerekir. Bunun nedeni Direct Lake semantik modellerinin hesaplanmış sütunları desteklemediğidir.

Yabancı anahtarlar

Örnek boyut tablosunda da adlı SalesRegion_FKbir yabancı anahtar vardır. Diğer boyut tabloları yabancı bir anahtara başvurabilir ve bunların boyut tablosundaki varlığı özel bir durumdur. Tablonun başka bir boyut tablosuyla ilişkili olduğunu gösterir; başka bir deyişle kar tanesi boyutunun bir parçasını oluşturabilir veya bir outrigger boyutuyla ilişkili olabilir.

Doku Ambarı yabancı anahtar kısıtlamalarını destekler, ancak uygulanamaz. Bu nedenle, veriler yüklendiğinde ETL işleminizin ilgili tablolar arasında bütünlük testi gerçekleştirmesi önemlidir.

Yabancı anahtarlar oluşturmak yine de iyi bir fikirdir. Zorunlu olmayan yabancı anahtarlar oluşturmanın iyi bir nedeni, Power BI Desktop gibi modelleme araçlarının anlamsal modeldeki tablolar arasındaki ilişkileri otomatik olarak algılamasına ve oluşturmasına izin vermektir.

Geçmiş izleme öznitelikleri

Örnek boyut tablosunun çeşitli geçmiş izleme öznitelikleri de vardır. Geçmiş izleme öznitelikleri, kaynak sistemde gerçekleşen belirli değişiklikleri izleme gereksiniminize bağlı olarak isteğe bağlıdır. Veri ambarının birincil rolünü desteklemek için değerlerin depolanmasına olanak sağlar. Bu, geçmişi doğru bir şekilde açıklamaktır. Özellikle, ETL işlemi boyuta yeni veya değiştirilmiş veriler yükledikçe bu öznitelikler geçmiş bağlamı depolar.

Daha fazla bilgi için bu makalenin devamında geçmiş değişikliği yönetme bölümüne bakın.

Öznitelikleri denetleme

Örnek boyut tablosunun çeşitli denetim öznitelikleri de vardır. Denetim öznitelikleri isteğe bağlıdır ancak önerilir. Boyut kayıtlarının ne zaman ve nasıl oluşturulduğunu veya değiştirildiğini izlemenize olanak sağlar ve ETL işlemleri sırasında oluşturulan tanılama veya sorun giderme bilgilerini içerebilirler. Örneğin, bir satırı kimin (veya hangi işlemin) ne zaman güncelleştirmiş olduğunu izlemek istersiniz. Denetim öznitelikleri, etl işleminin beklenmedik bir şekilde durması gibi zorlu bir sorunu tanılamaya da yardımcı olabilir. Ayrıca boyut üyelerini hata veya çıkarsanan üye olarak işaretleyebilirler.

Boyut tablosu boyutu

Genellikle, boyutsal modeldeki en kullanışlı ve çok yönlü boyutlar büyük, geniş boyutlardır. Bunlar satırlar açısından büyük (milyondan fazla) ve boyut özniteliklerinin sayısı (potansiyel olarak yüzlerce) açısından geniştir. Boyut o kadar önemli değildir (ancak mümkün olan en küçük boyut için tasarlamanız ve iyileştirmeniz gerekir). Önemli olan boyutun olgu verilerinin gerekli filtreleme, gruplandırma ve doğru geçmiş analizini desteklemesidir.

Büyük boyutlar birden çok kaynak sistemden kaynaklanabilir. Bu durumda boyut işlemenin verileri birleştirmesi, birleştirmesi, yinelenenleri kaldırması ve standartlaştırması gerekir; ve vekil anahtarlar atayın.

Karşılaştırmak gerekirse, bazı boyutlar çok küçüktür. Bunlar, yalnızca birkaç kayıt ve öznitelik içeren arama tablolarını temsil edebilir. Bu küçük boyutlar genellikle olgu tablolarındaki işlemlerle ilgili kategori değerlerini depolar ve olgu kayıtlarıyla ilişkili vekil anahtarlara sahip boyutlar olarak uygulanır.

İpucu

Çok sayıda küçük boyutunuz olduğunda, bunları gereksiz bir boyutta birleştirmeyi göz önünde bulundurun.

Boyut tasarımı kavramları

Bu bölümde çeşitli boyut tasarımı kavramları açıklanmaktadır.

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

Neredeyse her zaman boyut tablolarının normal dışı olması gerekir. Normalleştirme, yinelenen verileri azaltacak şekilde depolanan verileri açıklamak için kullanılan terim olsa da, normalleştirme, önceden derlenmiş yedekli verilerin nerede bulunduğunu tanımlamak için kullanılan terimdir. Yedekli veriler genellikle hiyerarşilerin depolanmasından kaynaklanır (daha sonra ele alınmalıdır), yani hiyerarşiler düzleştirilmiştir. Örneğin, bir ürün boyutu alt kategoriyi (ve ilgili özniteliklerini) ve kategoriyi (ve ilgili özniteliklerini) depolayabilir.

Boyutlar genellikle küçük olduğundan (olgu tablolarıyla karşılaştırıldığında), yedekli verileri depolama maliyeti, geliştirilmiş sorgu performansı ve kullanılabilirliği nedeniyle neredeyse her zaman ağır basıyor.

Kar tanesi boyutları

Normalden çıkarmanın bir istisnası, bir kar tanesi boyutu tasarlamaktır. Kar tanesi boyutu normalleştirilir ve boyut verilerini çeşitli ilgili tablolarda depolar.

Aşağıdaki diyagramda, ilgili üç boyut tablosunu içeren bir kar tanesi boyutu gösterilmiştir: Product, Subcategoryve Category.

Aşağıdaki durumlarda bir kar tanesi boyutu uygulamayı göz önünde bulundurun:

• Boyut son derece büyük ve depolama maliyetleri yüksek sorgu performansı gereksiniminden daha ağır basıyor. (Ancak, bunun hala geçerli olduğunu düzenli aralıklarla yeniden değerlendirir.)
• Boyutu daha ayrıntılı olgulara ilişkilendirmek için anahtarlara ihtiyacınız vardır. Örneğin, satış olgu tablosu satırları ürün düzeyinde depolar, ancak satış hedefi olgu tablosu satırları alt kategori düzeyinde depolar.
• Geçmiş değişiklikleri daha yüksek ayrıntı düzeyinde izlemeniz gerekir.

Not

Power BI anlam modelindeki bir hiyerarşinin yalnızca tek bir anlam modeli tablosundaki sütunları temel alabileceğini unutmayın. Bu nedenle kar tanesi boyutu, kar tanesi tablolarını birleştiren bir görünüm kullanarak normal olmayan bir sonuç vermelidir.

Hiyerarşiler

Genellikle boyut sütunları hiyerarşiler oluşturur. Hiyerarşiler, verileri ayrı özetleme düzeylerinde keşfetmeye olanak tanır. Örneğin, matris görselinin ilk görünümü yıllık satışları gösterebilir ve rapor tüketicisi üç aylık ve aylık satışları ortaya çıkarmak için detaya gitmeyi seçebilir.

Hiyerarşiyi bir boyutta depolamanın üç yolu vardır. Şunları kullanabilirsiniz:

• Tek bir normalleştirilmiş boyuttan sütunlar.
• Birden çok ilişkili tabloyu içeren bir kar tanesi boyutu.
• Bir boyutta üst-alt (kendine başvuran) ilişki.

Hiyerarşiler dengelenebilir veya dengelenemez. Bazı hiyerarşilerin düzensiz olduğunu anlamak da önemlidir.

Dengeli hiyerarşiler

Dengeli hiyerarşiler en yaygın hiyerarşi türüdür. Dengeli hiyerarşi aynı sayıda düzeye sahiptir. Dengeli hiyerarşinin yaygın bir örneği, yıl, üç aylık dönem, ay ve tarih düzeylerini içeren tarih boyutunda bir takvim hiyerarşisidir.

Aşağıdaki diyagramda satış bölgelerinin dengeli hiyerarşisi gösterilmiştir. Satış bölgesi grubu ve satış bölgesi olan iki düzeyden oluşur.

Dengeli hiyerarşi düzeyleri, tek bir normalleştirilmiş boyuttaki veya kar tanesi boyutu oluşturan tablolardaki sütunları temel alır. Tek ve normal dışı bir boyut temel alındığında, yüksek düzeyleri temsil eden sütunlar yedekli veriler içerir.

Dengeli hiyerarşiler için olgular her zaman hiyerarşinin tek bir düzeyiyle ilgilidir ve bu genellikle en düşük düzeydir. Bu şekilde, olgular hiyerarşinin en yüksek düzeyine toplanabilir (toplanabilir). Olgular, olgu tablosunun dilimi tarafından belirlenen herhangi bir düzeyle ilişkilendirilebilir. Örneğin, satış olgu tablosu tarih düzeyinde, satış hedefi olgu tablosu ise çeyrek düzeyinde depolanabilir.

Dengesiz hiyerarşiler

Dengesiz hiyerarşiler daha az yaygın bir hiyerarşi türüdür. Dengesiz bir hiyerarşi, üst-alt ilişkiyi temel alan düzeylere sahiptir. Bu nedenle, dengelenmemiş bir hiyerarşideki düzeylerin sayısı belirli boyut tablosu sütunları tarafından değil boyut satırları tarafından belirlenir.

Bir çalışan boyutundaki her satırın aynı tablodaki bir raporlama yöneticisi satırıyla ilişkilendirildiği bir çalışan hiyerarşisi, dengesiz bir hiyerarşinin yaygın bir örneğidir. Bu durumda, herhangi bir çalışan, çalışan raporlaması olan bir yönetici olabilir. Doğal olarak, hiyerarşinin bazı dalları diğerlerinden daha fazla düzeye sahip olur.

Aşağıdaki diyagramda dengesiz bir hiyerarşi gösterilmiştir. Dört düzeyden oluşur ve hiyerarşideki her üye bir satış temsilcisidir. Satış temsilcilerinin hiyerarşide rapor verdikleri kişilere göre farklı sayıda ataları olduğuna dikkat edin.

Dengesiz hiyerarşilerin diğer yaygın örnekleri arasında ürün reçetesi, şirket sahipliği modelleri ve genel muhasebe sayılabilir.

Dengesiz hiyerarşiler için olgular her zaman boyut dilimiyle ilgilidir. Örneğin, satış bilgileri farklı raporlama yapılarına sahip farklı satış temsilcileriyle ilgilidir. Boyut tablosunda bir vekil anahtar (adlı Salesperson_SK) ve birincil anahtar sütununa başvuran bir ReportsTo_Salesperson_FK yabancı anahtar sütunu olacaktır. Yönetecek kimsesi olmayan her satış temsilcisi, hiyerarşinin herhangi bir dalının en düşük düzeyinde olmayabilir. En düşük düzeyde olmayan bir satış temsilcisi ürünleri satabilir ve aynı zamanda ürün satan raporlama satış temsilcilerine sahip olabilir. Bu nedenle olgu verilerinin toplaması tek tek satışçıyı ve tüm alt öğeleri dikkate almalıdır.

Üst-alt hiyerarşileri sorgulamak, özellikle büyük boyutlar için karmaşık ve yavaş olabilir. Kaynak sistem ilişkileri üst-alt öğe olarak depolayabilir ancak hiyerarşiyi doğallaştırmanızı öneririz. Bu örnekte hiyerarşi düzeylerini dönüştürüp boyuta sütun olarak depolamak için araçları doğallaştırın.

İpucu

Hiyerarşiyi doğallaştırmamayı seçerseniz, Power BI anlam modelinde üst-alt ilişkiyi temel alan bir hiyerarşi oluşturabilirsiniz. Ancak bu yaklaşım büyük boyutlar için önerilmez. Daha fazla bilgi için bkz . DAX'ta üst-alt hiyerarşileri için işlevleri anlama.

Düzensiz hiyerarşiler

Bazen hiyerarşideki bir üyenin üst öğesi hemen üzerinde olmayan bir düzeyde bulunduğundan hiyerarşi düzensiz olur. Bu gibi durumlarda, eksik düzey değerleri üst öğesinin değerini yineler.

Dengeli bir coğrafya hiyerarşisi örneği düşünün. Bir ülkenin/bölgenin hiçbir eyaleti veya ili olmadığında düzensiz bir hiyerarşi vardır. Örneğin, Yeni Zelanda'nın ne eyaletleri ne de illeri vardır. Bu nedenle, Yeni Zelanda satırını eklediğinizde, ülke/bölge değerini de sütunda StateProvince depolamanız gerekir.

Aşağıdaki diyagramda coğrafi bölgelerin düzensiz hiyerarşisi gösterilmiştir.

Geçmiş değişikliği yönetme

Gerektiğinde, yavaş değişen bir boyut (SCD) uygulanarak geçmiş değişikliği yönetilebilir. SCD, geçmiş bağlamı içine yeni veya değiştirilmiş veriler yüklendikçe korur.

En yaygın SCD türleri aşağıdadır.

• Tür 1: Varolan boyut üyesinin üzerine yazın.
• Tür 2: Zamana dayalı yeni bir sürüme sahip boyut üyesi ekleyin.
• Tür 3: Özniteliklerle sınırlı geçmişi izleyin.

Bir boyut hem SCD tür 1 hem de SCD tür 2 değişikliklerini destekleyebilecektir.

SCD tür 3, kısmen anlamsal modelde kullanılmasının zor olması nedeniyle yaygın olarak kullanılmaz. SCD tür 2 yaklaşımının daha uygun olup olmadığını dikkatlice düşünün.

İpucu

Sık sık değişen bir özniteliği olan bir boyut olan hızla değişen bir boyut bekliyorsanız, bunun yerine bu özniteliği olgu tablosuna eklemeyi göz önünde bulundurun. Öznitelik, ürün fiyatı gibi sayısalsa olgu tablosuna ölçü olarak ekleyebilirsiniz. Öznitelik bir metin değeriyse, tüm metin değerlerini temel alan bir boyut oluşturabilir ve boyut anahtarını olgu tablosuna ekleyebilirsiniz.

SCD türü 1

SCD tür 1 değişiklikleri var olan boyut satırının üzerine yazar çünkü değişiklikleri izlemeye gerek yoktur. Bu SCD türü, hataları düzeltmek için de kullanılabilir. Bu yaygın bir SCD türüdür ve müşteri adı, e-posta adresi ve diğerleri gibi çoğu değişen öznitelik için kullanılmalıdır.

Aşağıdaki diyagramda, telefon numarasının değiştirildiği satış temsilcisi boyut üyesinin önceki ve sonraki durumu gösterilmiştir.

Varolan satır güncelleştirildiğinden bu SCD türü geçmiş perspektifi korumaz. Bu, SCD tür 1 değişikliklerinin farklı üst düzey toplamalara neden olabileceği anlamına gelir. Örneğin, bir satış temsilcisi farklı bir satış bölgesine atanmışsa, SCD tür 1 değişikliği boyut satırının üzerine yazar. Satış temsilcilerinin bölgeye geçmiş satış sonuçlarının toplaması, şimdi yeni geçerli satış bölgesini kullandığından farklı bir sonuç elde eder. Sanki bu satış temsilcisi her zaman yeni satış bölgesine atanmış gibi.

SCD türü 2

SCD tür 2 değişiklikleri, boyut üyesinin zamana dayalı bir sürümünü temsil eden yeni satırlara neden olur. Her zaman geçerli bir sürüm satırı vardır ve kaynak sistemdeki boyut üyesinin durumunu yansıtır. Boyut tablosundaki geçmiş izleme öznitelikleri , geçerli sürümü (geçerli bayrak) TRUEve geçerlilik süresini tanımlamaya olanak sağlayan değerleri depolar. Birden çok sürüm depolandığında yinelenen doğal anahtarlar olacağı için vekil anahtar gereklidir.

Bu yaygın bir SCD türüdür, ancak geçmiş perspektifi koruması gereken öznitelikler için ayrılmalıdır.

Örneğin, bir satış temsilcisi farklı bir satış bölgesine atanmışsa, SCD tür 2 değişikliği bir güncelleştirme işlemi ve ekleme işlemi içerir.

1. Güncelleştirme işlemi, geçmiş izleme özniteliklerini ayarlamak için geçerli sürümün üzerine yazar. Özellikle, bitiş geçerlilik sütunu ETL işleme tarihine (veya kaynak sistemde uygun bir zaman damgasına) ve geçerli bayrak olarak FALSEayarlanır.
2. Ekleme işlemi yeni, geçerli bir sürüm ekler ve başlangıç geçerlilik sütununu bitiş geçerlilik sütunu değerine (önceki sürümü güncelleştirmek için kullanılır) ve geçerli bayrağı olarak TRUEayarlar.

İlgili olgu tablolarının ayrıntı düzeyinin satış temsilcisi düzeyinde değil, satış temsilcisi sürüm düzeyinde olduğunu anlamak önemlidir. Geçmiş satış sonuçlarının bölgeye toplaması doğru sonuçlar üretecektir ancak analiz edilecek iki (veya daha fazla) satış temsilcisi üyesi sürümü olacaktır.

Aşağıdaki diyagramda, satış bölgelerinin değiştiği satış temsilcisi boyut üyesinin önceki ve sonraki durumu gösterilmiştir. Kuruluş, satış temsilcilerinin çalışmalarını atandıkları bölgeye göre analiz etmek istediğinden SCD tür 2 değişikliği tetikler.

İpucu

Boyut tablosu SCD tür 2 değişikliklerini desteklediğinde, üyeyi ve sürümü açıklayan bir etiket özniteliği eklemeniz gerekir. Adventure Works satış temsilcisi Lynn Tsoflias'ın Avustralya satış bölgesinden Birleşik Krallık satış bölgesine atamayı değiştirmesine ilişkin bir örnek düşünün. İlk sürümün etiket özniteliği "Lynn Tsoflias (Avustralya)" ve yeni, geçerli sürümün etiket özniteliği "Lynn Tsoflias (Birleşik Krallık) " olarak okunabilir. Yararlı olursa, geçerlilik tarihlerini etikete de ekleyebilirsiniz.

Tarihi doğruluk ve kullanılabilirlik ve verimlilik gereksinimini dengelemeniz gerekir. Bir boyut tablosunda çok fazla SCD tür 2 değişikliği olmasını önlemeye çalışın çünkü analistlerin anlamayı zorlaştırabilecek aşırı sayıda sürüme neden olabilir.

Ayrıca, çok fazla sürüm değişen bir özniteliğin olgu tablosunda daha iyi depolanabileceğini gösterebilir. Önceki örneği genişleterek, satış bölgesi değişiklikleri sık yapıldıysa, satış bölgesi scd türü 2 uygulamak yerine olgu tablosunda boyut anahtarı olarak depolanabilirdi.

Aşağıdaki SCD tür 2 geçmiş izleme özniteliklerini göz önünde bulundurun.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Geçmiş izleme özniteliklerinin amaçları aşağıdadır.

• Sütun, RecChangeDate_FK değişikliğin yürürlüğe girdiği tarihi depolar. Değişiklikler gerçekleştiğinde sorgulamanıza olanak tanır.
• RecValidFromKey ve RecValidToKey sütunları, satır için geçerlilik tarihlerini depolar. İlk sürümü temsil etmek için RecValidFromKey için için tarih boyutunda bulunan en erken tarihi depolamayı ve geçerli sürümlerin depolanmasını 01/01/9999 RecValidToKey göz önünde bulundurun.
• Sütun RecReason isteğe bağlıdır. Sürümün eklenmesinin nedeninin belgelenmesine olanak tanır. Hangi özniteliklerin değiştiğini kodlayabilir veya kaynak sistemden belirli bir iş nedenini belirten bir kod olabilir.
• RecIsCurrent sütunu yalnızca geçerli sürümleri almayı mümkün kılar. ETL işlemi olgu tablolarını yüklerken boyut anahtarlarını ararken kullanılır.

Not

Bazı kaynak sistemler geçmiş değişiklikleri depolamaz, bu nedenle boyutun değişiklikleri algılamak ve yeni sürümleri uygulamak için düzenli olarak işlenmesi önemlidir. Bu şekilde, değişiklikleri oluştuktan kısa süre sonra algılayabilirsiniz ve geçerlilik tarihleri doğru olur.

SCD türü 3

SCD tür 3 değişiklikleri özniteliklerle sınırlı geçmişi izler. Bu yaklaşım, son değişikliği veya en son değişiklikleri kaydetmeye ihtiyaç duyulduğunda yararlı olabilir.

Bu SCD türü sınırlı geçmiş perspektifi korur. Yalnızca ilk ve geçerli değerlerin depolanması gerektiğinde yararlı olabilir. Bu örnekte, ara değişiklikler gerekli olmayacaktır.

Örneğin, bir satış temsilcisi farklı bir satış bölgesine atanmışsa, SCD tür 3 değişikliği boyut satırının üzerine yazar. Önceki satış bölgesini özel olarak depolayan bir sütun önceki satış bölgesi olarak, yeni satış bölgesi ise geçerli satış bölgesi olarak ayarlanır.

Aşağıdaki diyagramda, satış bölgelerinin değiştiği satış temsilcisi boyut üyesinin önceki ve sonraki durumu gösterilmiştir. Kuruluş önceki satış bölgesi atamalarını belirlemek istediğinden SCD tür 3 değişikliği tetikler.

Özel boyut üyeleri

Eksik, bilinmeyen, YOK veya hata durumlarını temsil eden bir boyuta satır ekleyebilirsiniz. Örneğin, aşağıdaki vekil anahtar değerlerini kullanabilirsiniz.

Anahtar değeri	Amaç
0	Eksik (kaynak sistemde kullanılamaz)
-1	Bilinmiyor (olgu tablosu yükü sırasında arama hatası)
-2	Yok (uygulanamaz)
-3	Hata

Takvim ve saat

Neredeyse istisnasız olarak olgu tabloları, ölçüleri belirli noktalarda depolar. Tarihe (ve muhtemelen saate) göre analizi desteklemek için takvim (tarih ve saat) boyutları olmalıdır.

Kaynak sistemin takvim boyutu verilerine sahip olması nadirdir, bu nedenle veri ambarında oluşturulması gerekir. Genellikle bir kez oluşturulur ve takvim boyutuysa gerektiğinde gelecekteki tarihlerle uzatılmış olur.

Tarih boyutu

Tarih (veya takvim) boyutu, analiz için kullanılan en yaygın boyutdur. Tarih başına bir satır depolar ve yıl, üç aylık dönem veya ay gibi belirli tarih dönemlerine göre filtrelemek veya gruplandırmak için ortak gereksinimi destekler.

Önemli

Tarih boyutu, günün saatine kadar uzanan bir tane içermemelidir. Günün saati analizi gerekiyorsa, hem tarih boyutuna hem de saat boyutuna sahip olmanız gerekir (bundan sonra açıklanmıştır). Günün olgularını depolayan olgu tablolarında bu boyutların her biri için birer tane olmak üzere iki yabancı anahtar olmalıdır.

Tarih boyutunun doğal anahtarı tarih veri türünü kullanmalıdır. Vekil anahtar, biçimi ve int veri türünü kullanarak YYYYMMDD tarihi depolamalıdır. Bu kabul edilen uygulama, vekil anahtar değerinin anlamı olduğunda ve okunabilir olduğunda tek özel durum (zaman boyutuyla birlikte) olmalıdır. Int veri türü olarak depolamak YYYYMMDD yalnızca sayısal olarak verimli ve sıralı olmakla kalmaz, aynı zamanda kesin olmayan Uluslararası Standartlar Kuruluşu (ISO) 8601 tarih biçimine de uygundur.

Tarih boyutuna dahil etmek için bazı yaygın öznitelikler aşağıdadır.

• Year, Quarter, Month, Day
• QuarterNumberInYear, MonthNumberInYear – metin etiketlerini sıralamak için gerekli olabilir.
• FiscalYear, FiscalQuarter – bazı kurumsal muhasebe zamanlamaları yılın ortasında başlar, böylece takvim yılının başlangıcı/sonu ve mali yıl farklıdır.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – metin etiketlerini sıralamak için gerekli olabilir.
• WeekOfYear – 52 veya 53 haftalık ISO standardı dahil olmak üzere yılın haftasını etiketlemenin birden çok yolu vardır.
• IsHoliday, HolidayText – Kuruluşunuz birden çok coğrafyada faaliyet gösteriyorsa, her coğrafyanın ayrı bir boyut olarak gözlemlediği veya tarih boyutunda birden çok öznitelikte doğallaştırıldığı birden çok tatil listesi oluşturmanız gerekir. HolidayText Öznitelik eklemek, raporlama için tatilleri belirlemenize yardımcı olabilir.
• IsWeekday – Benzer şekilde bazı coğrafyalarda standart çalışma haftası pazartesiden cumaya değildir. Örneğin, birçok Orta Doğu bölgesinde çalışma haftası Pazar ile Perşembe arasında, diğer bölgelerde ise dört günlük veya altı günlük bir çalışma haftası kullanılır.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset – göreli tarih filtrelemeyi desteklemek için gerekli olabilir (örneğin, önceki ay). Geçerli dönemlerde sıfır uzaklığı kullanılır (0); önceki dönemler -1, -2, -3...; gelecek dönemler 1, 2, 3... konumlarını depolar.

Her boyutta olduğu gibi önemli olan, bilinen filtreleme, gruplandırma ve hiyerarşi gereksinimlerini destekleyen öznitelikler içermesidir. Etiketlerin çevirilerini başka dillere depolayan öznitelikler de olabilir.

Boyut daha ayrıntılı olgular ile ilişkilendirmek için kullanıldığında olgu tablosu tarih döneminin ilk tarihini kullanabilir. Örneğin, üç aylık satış temsilcileri hedeflerini depolayan bir satış hedefi olgu tablosu, üç aylık dönemin ilk tarihini tarih boyutunda depolar. Alternatif bir yaklaşım, tarih tablosunda anahtar sütunlar oluşturmaktır. Örneğin, çeyrek anahtar biçim ve smallint veri türünü kullanarak YYYYQ çeyrek anahtarı depolayabilir.

Boyut, tüm olgu tabloları tarafından kullanılan bilinen tarih aralığıyla doldurulmalıdır. Ayrıca, veri ambarı hedefler, bütçeler veya tahminler hakkındaki olguları depoladığında gelecekteki tarihleri de içermelidir. Diğer boyutlarda olduğu gibi eksik, bilinmeyen, YOK veya hata durumlarını temsil eden satırlar da ekleyebilirsiniz.

İpucu

Tarih verileri oluşturan betikleri ve elektronik tabloları bulmak için internette "tarih boyutu oluşturucu" araması yapın.

Genellikle, gelecek yılın başında ETL işlemi tarih boyutu satırlarını belirli bir yıl ileriye kadar genişletmelidir. Boyut göreli uzaklık öznitelikleri içerdiğinde, geçerli tarihe (bugün) göre uzaklık öznitelik değerlerini güncelleştirmek için ETL işleminin günlük olarak çalıştırılması gerekir.

Zaman boyutu

Bazen olguların belirli bir noktada (günün saatinde olduğu gibi) depolanması gerekir. Bu durumda, bir saat (veya saat) boyutu oluşturun. Dakika (24 x 60 = 1.440 satır) ve hatta saniye (24 x 60 x 60 = 86.400 satır) olabilir. Diğer olası tahıllar yarım saat veya saat içerir.

Bir zaman boyutunun doğal anahtarı, zaman veri türünü kullanmalıdır. Vekil anahtar uygun bir biçim kullanabilir ve anlamları olan ve insan tarafından okunabilen değerleri depolayabilir( örneğin, veya HHMMSS biçimini kullanarakHHMM).

Zaman boyutuna dahil etmek için bazı yaygın öznitelikler aşağıdadır.

• Hour, HalfHour, QuarterHour, Minute
• Zaman aralığı etiketleri (sabah, öğleden sonra, akşam, gece)
• Çalışma vardiyası adları
• Tepe veya tepe noktası dışında bayrakları

Uyumlu boyutlar

Bazı boyutlar uygun boyutlar olabilir. Uyumlu boyutlar birçok olgu tablosuyla ilgilidir ve bu nedenle boyutsal modelde birden çok yıldız tarafından paylaşılır. Tutarlılık sağlar ve devam eden geliştirme ve bakımı azaltmanıza yardımcı olabilir.

Örneğin, olgu tablolarının en az bir tarih boyut anahtarı depolaması normaldir (çünkü etkinlik neredeyse her zaman tarih ve/veya saate göre kaydedilir). Bu nedenle, tarih boyutu ortak bir uyumlu boyutdur. Bu nedenle tarih boyutunuzun tüm olgu tablolarının analiziyle ilgili öznitelikler içerdiğinden emin olmalısınız.

Aşağıdaki diyagramda Sales olgu tablosu ve olgu tablosu gösterilmektedir Inventory . Her olgu tablosu, uygun boyutlar olan boyut ve Product boyutla ilgilidirDate.

Başka bir örnek olarak, çalışanınız ve kullanıcılarınız aynı kişi kümesi olabilir. Bu durumda, uygun bir boyut oluşturmak için her varlığın özniteliklerini birleştirmek mantıklı olabilir.

Rol yapan boyutlar

Olgu tablosunda bir boyuta birden çok kez başvurulduğunda, rol yapma boyutu olarak bilinir.

Örneğin, bir satış olgu tablosunda sipariş tarihi, sevk tarihi ve teslim tarihi boyut anahtarları olduğunda, tarih boyutu üç şekilde ilişkilendirilmiştir. Her yol ayrı bir rolü temsil eder, ancak yalnızca bir fiziksel tarih boyutu vardır.

Aşağıdaki diyagramda olgu Flight tablosu gösterilmiştir. BoyutAirport, olgu tablosuyla boyut ve Arrival Airport boyut olarak Departure Airport iki kez ilişkili olduğundan rol yapma boyutudur.

Gereksiz boyutlar

Gereksiz boyut, özellikle birkaç öznitelik (belki de bir tane) oluşturduğunda ve bu özniteliklerin kardinalitesi düşük olduğunda (birkaç değer) çok sayıda bağımsız boyut olduğunda kullanışlıdır. Gereksiz bir boyutun amacı, birçok küçük boyutu tek bir boyutta birleştirmektir. Bu tasarım yaklaşımı boyut sayısını azaltabilir, olgu tablosu anahtarlarının sayısını ve dolayısıyla olgu tablosu depolama boyutunu azaltabilir. Kullanıcılara daha az tablo sunduğundan Veri bölmesi dağınıklığı azaltmaya da yardımcı olur.

Gereksiz boyut tablosu genellikle tüm boyut öznitelik değerlerinin Kartezyen çarpımını vekil anahtar özniteliğiyle depolar.

İyi adaylar arasında bayraklar ve göstergeler, sipariş durumu ve müşteri demografik durumları (cinsiyet, yaş grubu ve diğerleri) bulunur.

Aşağıdaki diyagramda, sipariş durumu değerleriyle teslim durumu değerlerini birleştiren adlı Sales Status gereksiz bir boyut gösterilmiştir.

Bozuk boyutlar

Boyut ilgili olgular ile aynı düzeyde olduğunda, dejenere bir boyut oluşabilir. Dejenere bir boyuta yaygın bir örnek, satış olgu tablosuyla ilişkili bir satış siparişi numarası boyutudur. Genellikle, fatura numarası olgu tablosundaki tek, hiyerarşik olmayan bir özniteliktir. Bu nedenle, ayrı bir boyut tablosu oluşturmak için bu verileri kopyalamamak kabul edilen bir uygulamadır.

Aşağıdaki diyagramda, satış olgu tablosundaki SalesOrderNumber sütuna göre bozuk bir boyut olan bir boyut gösterilmiştirSales Order. Bu boyut, ayrı satış siparişi numarası değerlerini alan bir görünüm olarak uygulanır.

İpucu

Doku Ambarı'nda, bozuk boyutu sorgulama amacıyla boyut olarak sunan bir görünüm oluşturmak mümkündür.

Power BI anlamsal modelleme perspektifinden bakıldığında, power query kullanılarak ayrı bir tablo olarak dejenere bir boyut oluşturulabilir. Bu şekilde, anlam modeli filtrelemek veya gruplandırmak için kullanılan alanların boyut tablolarından, olguları özetlemek için kullanılan alanların ise olgu tablolarından kaynaklandığını gösteren en iyi yönteme uygundur.

Outrigger boyutları

Bir boyut tablosu diğer boyut tablolarıyla ilişkilendirildiğinde, bu bir ayrımcı boyut olarak bilinir. Bir outrigger boyutu, boyutsal modeldeki tanımların uyumlu ve yeniden kullanılmasına yardımcı olabilir.

Örneğin, her posta kodu için coğrafi konumları depolayan bir coğrafya boyutu oluşturabilirsiniz. Daha sonra bu boyuta, coğrafya boyutunun vekil anahtarını depolayan müşteri boyutunuz ve satış temsilcisi boyutunuz tarafından başvurulabilir. Böylece müşteriler ve satış temsilcileri tutarlı coğrafi konumlar kullanılarak analiz edilebilir.

Aşağıdaki diyagramda Geography , bir outrigger boyutu olan bir boyut gösterilmiştir. Doğrudan olgu tablosuyla Sales ilgili değildir. Bunun yerine, boyut ve boyut aracılığıyla Customer dolaylı olarak ilişkilidir Salesperson .

Diğer boyut tablosu öznitelikleri tarihleri depoladığında tarih boyutunun bir outrigger boyutu olarak kullanılabileceğini düşünün. Örneğin, müşteri boyutunda doğum tarihi, tarih boyutu tablosunun vekil anahtarı kullanılarak depolanabilir.

Birden çok değerli boyutlar

Boyut özniteliğinin birden çok değer depolaması gerektiğinde, çok değerli bir boyut tasarlamanız gerekir. Bir köprü tablosu (bazen birleştirme tablosu olarak da adlandırılır) oluşturarak çok değerli bir boyut uygularsınız. Köprü tablosu varlıklar arasında çoka çok ilişki depolar.

Örneğin, bir satış temsilcisi boyutu olduğunu ve her satış temsilcisinin bir veya daha fazla satış bölgesine atandığını düşünün. Bu durumda, bir satış bölgesi boyutu oluşturmak mantıklıdır. Bu boyut, her satış bölgesini yalnızca bir kez depolar. Köprü tablosu olarak bilinen ayrı bir tablo, her satış temsilcisi ve satış bölgesi ilişkisi için bir satır depolar. Fiziksel olarak, satış temsilcisi boyutundan köprü tablosuna bire çok ilişkisi ve satış bölgesi boyutundan köprü tablosuna bire çok ilişkisi vardır. Mantıksal olarak, satış temsilcileriyle satış bölgeleri arasında çoka çok ilişki vardır.

Aşağıdaki diyagramda Account boyut tablosu olgu tablosuyla Transaction ilgilidir. Müşterilerin birden çok hesabı olabileceği ve hesapların birden çok müşterisi olabileceğinden Customer , boyut tablosu köprü tablosu aracılığıyla Customer Account ilişkilidir.

İlgili içerik

Bu serinin sonraki makalesinde olgu tabloları için rehberlik ve tasarım en iyi yöntemleri hakkında bilgi edinin.