Aracılığıyla paylaş

Microsoft Fabric Warehouse'da boyutsal modelleme: Tabloları yükleme

  • Makale

Ş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 makale size boyut ve olgu tablolarını boyutsal modelde yüklemeye yönelik rehberlik ve en iyi yöntemleri sağlar. 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 model yükleme

Boyutsal modelin yüklenmesi, belirli aralıklarla Ayıklama, Dönüştürme ve Yükleme (ETL) işleminin çalıştırılmasını içerir. ETL işlemi genellikle kaynak verileri hazırlama, boyut verilerini eşitleme, olgu tablolarına satır ekleme ve denetim verilerini ve hatalarını kaydetme ile ilgilenen diğer işlemlerin çalışmasını düzenler.

Doku Ambarı çözümünde, ETL işleminizi geliştirmek ve çalıştırmak için Data Factory'yi kullanabilirsiniz. İşlem, kaynak verileri boyutlu model tablolarınıza hazırlayabilir, dönüştürebilir ve yükleyebilir.

Özellikle:

  • ETL işlemini düzenlemeye yönelik iş akışları oluşturmak için veri işlem hatlarını kullanın. Veri işlem hatları SQL betiklerini, saklı yordamları ve daha fazlasını yürütebilir.
  • Yüzlerce veri kaynağından veri almak için düşük kod mantığı geliştirmek için veri akışlarını kullanın. Veri akışları, birden çok kaynaktan verileri birleştirmeyi, verileri dönüştürmeyi ve ardından boyutsal model tablosu gibi bir hedefe yüklemeyi destekler. Veri akışları, bugün Microsoft Excel ve Power BI Desktop dahil olmak üzere birçok Microsoft ürününde kullanılabilen tanıdık Power Query deneyimi kullanılarak oluşturulur.

Not

ETL geliştirme karmaşık olabilir ve geliştirme zor olabilir. Veri ambarı geliştirme çalışmalarının yüzde 60-80'inin ETL sürecine ayrılmış olduğu tahmin edilmektedir.

Düzenleme

ETL işleminin genel iş akışı şu şekildedir:

  1. İsteğe bağlı olarak hazırlama tablolarını yükleyin.
  2. İşlem boyutu tabloları.
  3. Olgu tablolarını işleme.
  4. İsteğe bağlı olarak, bağımlı Doku içeriğinin (semantik model gibi) yenilenmesini tetikleme gibi işlem sonrası görevleri gerçekleştirin.

Diyagram, önceki paragrafta açıklandığı gibi ETL işleminin dört adımını gösterir.

Boyut tabloları, son ETL işleminden bu yana kaynak sistemlere eklenenler de dahil olmak üzere tüm boyut üyelerini depolamak için önce işlenmelidir. Boyutlar arasında bağımlılıklar olduğunda, farklı boyutlar söz konusu olduğunda, boyut tabloları bağımlılık sırasına göre işlenmelidir. Örneğin, müşteri boyutu ve satıcı boyutu tarafından kullanılan bir coğrafya boyutu, diğer iki boyuttan önce işlenmelidir.

Olgu tabloları, tüm boyut tabloları işlendikten sonra işlenebilir.

Tüm boyutlu model tabloları işlendiğinde, bağımlı anlam modellerinin yenilenmesini tetikleyebilirsiniz. EtL sürecinin sonucunu bildirmek için ilgili personele bildirim göndermek de iyi bir fikirdir.

Verileri hazırlama

Hazırlama kaynak verileri, veri yükleme ve dönüştürme gereksinimlerini desteklemeye yardımcı olabilir. Kaynak sistem verilerini ayıklamayı ve ETL işlemini desteklemek için oluşturduğunuz hazırlama tablolarına yüklemeyi içerir. Aşağıdakiler yapılabildiğinden kaynak verileri hazırlamanızı öneririz:

  • İşletim sistemleri üzerindeki etkiyi en aza indirin.
  • ETL işleme konusunda yardımcı olmak ve iyileştirmek için kullanılabilir.
  • Kaynak sistemlerden verileri yeniden yüklemeye gerek kalmadan ETL işlemini yeniden başlatma olanağı sağlayın.

Hazırlama tablolarındaki veriler hiçbir zaman iş kullanıcılarının kullanımına sunulmamalıdır. Yalnızca ETL işlemiyle ilgilidir.

Not

Verileriniz bir Fabric Lakehouse'da depolandığında, verilerini veri ambarında hazırlamanız gerekmeyebilir. Bir madalyon mimarisi uygularsa, verilerini bronz, gümüş veya altın katmandan kaynaklayabilirsiniz.

Ambarda büyük olasılıkla adlı stagingbir şema oluşturmanızı öneririz. Hazırlama tabloları, sütun adları ve veri türleri açısından kaynak tablolara olabildiğince yakın olmalıdır. EtL işleminin başlangıcında her tablonun içeriği kaldırılmalıdır. Ancak, Doku Ambarı tablolarının kesilebileceğini unutmayın. Bunun yerine, her hazırlama tablosunu verilerle yüklemeden önce bırakabilir ve yeniden oluşturabilirsiniz.

Hazırlama stratejinizin bir parçası olarak veri sanallaştırma alternatiflerini de göz önünde bulundurabilirsiniz. Şunları kullanabilirsiniz:

Verileri dönüştürme

Kaynak verilerinizin yapısı, boyutsal model tablolarınızın hedef yapılarına benzemeyebilir. Bu nedenle ETL işleminizin, boyutsal model tablolarının yapısıyla uyumlu olması için kaynak verileri yeniden şekillendirmesi gerekir.

Ayrıca, veri ambarı temizlenmiş ve uyumlu veriler sağlamalıdır, bu nedenle kalite ve tutarlılık sağlamak için kaynak verilerin dönüştürülmesi gerekebilir.

Not

çöp girme , çöp çıkarma kavramı kesinlikle veri ambarı için geçerlidir; bu nedenle, atık (düşük kaliteli) verileri boyutsal model tablolarınıza yüklemekten kaçının.

ETL işleminizin gerçekleştirebileceği bazı dönüşümler aşağıdadır.

  • Verileri birleştirme: Farklı kaynaklardan gelen veriler, eşleşen anahtarlara göre tümleştirilebilir (birleştirilebilir). Örneğin, ürün verileri farklı sistemlerde (üretim ve pazarlama gibi) depolanır, ancak hepsi ortak bir stok tutma birimi (SKU) kullanır. Veriler ortak bir yapıyı paylaştığında da eklenebilir. Örneğin, satış verileri birden çok sistemde depolanır. Her sistemdeki satışların birleşimi, tüm satış verilerinin üst kümesini oluşturabilir.
  • Veri türlerini dönüştürme: Veri türleri, boyutsal model tablolarında tanımlananlara dönüştürülebilir.
  • Hesaplamalar: Hesaplamalar, boyutsal model tablolarının değerlerini üretmek için yapılabilir. Örneğin, bir çalışan boyut tablosu için, tam adı oluşturmak için ad ve soyadlarını birleştirirsiniz. Başka bir örnek olarak, satış olgu tablonuz için birim fiyatın ve miktarın ürünü olan brüt satış gelirini hesaplayabilirsiniz.
  • Geçmiş değişikliği algılama ve yönetme: Değişiklik algılanabilir ve boyut tablolarında uygun şekilde depolanabilir. Daha fazla bilgi için bu makalenin devamında geçmiş değişikliği yönetme bölümüne bakın.
  • Toplama verileri: Toplama, olgu tablosunun boyutsallığını azaltmak ve/veya olguların ayrıntı düzeyini artırmak için kullanılabilir. Örneğin, satış olgu tablosunun satış siparişi numaralarını depolaması gerekmez. Bu nedenle, olgu tablosu verilerini depolamak için tüm boyut anahtarlarına göre gruplanan toplu bir sonuç kullanılabilir.

Verileri yükleme

Aşağıdaki veri alımı seçeneklerini kullanarak bir Yapı Ambarı'na tablo yükleyebilirsiniz.

  • COPY INTO (T-SQL): Bu seçenek, kaynak veriler ADLS 2. Nesil veya Azure Blob Depolama gibi bir dış Azure depolama hesabında depolanan Parquet veya CSV dosyalarını oluşturduğunda kullanışlıdır.
  • Veri işlem hatları: ETL işlemini düzenlemeye ek olarak, veri işlem hatları T-SQL deyimlerini çalıştıran, arama yapan veya veri kaynağından hedefe veri kopyalayan etkinlikler içerebilir.
  • Veri akışları: Veri işlem hatlarına alternatif olarak, veri akışları verileri dönüştürmek ve temizlemek için kodsuz bir deneyim sağlar.
  • Ambarlar arası alım: Veriler aynı çalışma alanında depolandığında, ambarlar arası alım farklı ambar veya göl evi tablolarının birleştirilmesini sağlar. , SELECT INTOve CREATE TABLE AS SELECT (CTAS)gibi INSERT…SELECTT-SQL komutlarını destekler. Bu komutlar özellikle aynı çalışma alanı içindeki hazırlama tablolarındaki verileri dönüştürmek ve yüklemek istediğinizde kullanışlıdır. Bunlar ayrıca, boyutsal model tablolarını yüklemenin en verimli ve en hızlı yolu olabilecek, ayarlanmış tabanlı işlemlerdir.

İpucu

En iyi yöntemler de dahil olmak üzere bu veri alımı seçeneklerinin tam açıklaması için bkz . Verileri Ambar'a alma.

Günlük Kaydı

ETL işlemleri genellikle özel izleme ve bakım gerektirir. Bu nedenlerden dolayı, ETL işleminin sonuçlarını ambarınızdaki boyutsal olmayan model tablolarında günlüğe kaydetmenizi öneririz. Her ETL işlemi için benzersiz bir kimlik oluşturmanız ve bunu kullanarak her işlemle ilgili ayrıntıları günlüğe kaydetmeniz gerekir.

Günlüğe kaydetmeyi göz önünde bulundurun:

  • ETL işlemi:
    • Her ETL yürütmesi için benzersiz bir kimlik
    • Başlangıç saati ve bitiş saati
    • Durum (başarı veya başarısızlık)
    • Karşılaşılan hatalar
  • Her hazırlama ve boyutlu model tablosu:
    • Başlangıç saati ve bitiş saati
    • Durum (başarı veya başarısızlık)
    • Eklenen, güncelleştirilen ve silinen satırlar
    • Son tablo satırı sayısı
    • Karşılaşılan hatalar
  • Diğer işlemler:
    • Anlam modeli yenileme işlemlerinin başlangıç saati ve bitiş saati

İpucu

ETL süreçlerinizi izlemeye ve analiz etmeye ayrılmış bir anlam modeli oluşturabilirsiniz. İşlem süreleri, gözden geçirme ve iyileştirmeden yararlanabilecek performans sorunlarını belirlemenize yardımcı olabilir. Satır sayıları, ETL her çalıştığında artımlı yükün boyutunu anlamanıza ve ayrıca veri ambarının gelecekteki boyutunu tahmin etmenize (ve uygunsa Doku kapasitesinin ne zaman ölçeklendirileceğini) tahmin etmenize yardımcı olabilir.

İşlem boyutu tabloları

Boyut tablosunun işlenmesi, veri ambarı verilerinin kaynak sistemlerle eşitlenmesini içerir. Kaynak veriler önce dönüştürülür ve boyut tablosuna yüklenmek üzere hazırlanır. Bu veriler daha sonra iş anahtarlarına katılarak mevcut boyut tablosu verileriyle eşleştirilir. Daha sonra kaynak verilerin yeni veya değiştirilmiş verileri temsil edip etmediğini belirlemek mümkündür. Boyut tablosu yavaş değişen boyut (SCD) tür 1 uyguladığında, varolan boyut tablosu satırları güncelleştirilerek değişiklikler yapılır. Tablo SCD tür 2 değiştiğinde, mevcut sürümün süresi dolar ve yeni bir sürüm eklenir.

Aşağıdaki diyagramda bir boyut tablosunu işlemek için kullanılan mantık gösterilmiştir.

Diyagram, aşağıdaki paragrafta açıklandığı gibi yeni ve değiştirilmiş kaynak satırların bir boyut tablosuna nasıl yüklendiğini açıklayan bir akışı gösterir.

Boyut tablosunun Product işlemini göz önünde bulundurun.

  • Kaynak sisteme yeni ürünler eklendiğinde, satırlar boyut tablosuna Product eklenir.
  • Ürünler değiştirildiğinde, boyut tablosundaki mevcut satırlar güncelleştirilir veya eklenir.
    • SCD türü 1 uygulandığında, mevcut satırlarda güncelleştirmeler yapılır.
    • SCD türü 2 uygulandığında, geçerli satır sürümlerinin süresinin dolmasına yönelik güncelleştirmeler yapılır ve geçerli sürümü temsil eden yeni satırlar eklenir.
    • SCD türü 3 uygulandığında, SCD türü 1'e benzer bir işlem gerçekleşir ve mevcut satırlar yeni satır eklemeden güncelleştirilir.

Vekil anahtarlar

Her boyut tablosunun, mümkün olan en küçük tamsayı veri türünü kullanması gereken bir vekil anahtarı olması önerilir. Genellikle bir kimlik sütunu oluşturularak yapılan SQL Server tabanlı ortamlarda bu özellik Doku Ambarı'nda desteklenmez. Bunun yerine, benzersiz tanımlayıcılar oluşturan bir geçici çözüm tekniği kullanmanız gerekir.

Önemli

Bir boyut tablosu otomatik olarak oluşturulan vekil anahtarlar içerdiğinde, hiçbir zaman kesme ve tam yeniden yükleme işlemi gerçekleştirmemelisiniz. Bunun nedeni, boyutu kullanan olgu tablolarına yüklenen verileri geçersiz kılmasıdır. Ayrıca, boyut tablosu SCD tür 2 değişikliklerini destekliyorsa, geçmiş sürümleri yeniden oluşturmak mümkün olmayabilir.

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

Bir boyut tablosunun geçmiş değişikliği depolaması gerektiğinde, yavaş değişen bir boyut (SCD) uygulamanız gerekir.

Not

Boyut tablosu satırı çıkarılmış bir üyeyse (olgu yükleme işlemi tarafından eklenir), tüm değişiklikleri SCD değişikliği yerine geç gelen boyut ayrıntıları olarak işlemeniz gerekir. Bu durumda, değiştirilen öznitelikler güncelleştirilmeli ve çıkarsanan üye bayrağı sütunu olarak FALSEayarlanmalıdır.

Bir boyut SCD türü 1 ve/veya SCD tür 2 değişikliklerini destekleyebilecektir.

SCD türü 1

SCD tür 1 değişiklikleri algılandığında aşağıdaki mantığı kullanın.

  1. Değiştirilen öznitelikleri güncelleştirin.
  2. Tabloda son değiştirme tarihi ve sütunlar tarafından son değiştirme tarihi varsa, değişiklikleri yapan geçerli tarihi ve işlemi ayarlayın.

SCD türü 2

SCD tür 2 değişiklikleri algılandığında aşağıdaki mantığı kullanın.

  1. Bitiş tarihi geçerlilik sütununu ETL işleme tarihine (veya kaynak sistemde uygun bir zaman damgasına) ve geçerli bayrağı olarak ayarlayarak geçerli sürümün süresinin dolmasına neden olur FALSE.
  2. Tabloda son değiştirme tarihi ve sütunlar tarafından son değiştirme tarihi varsa, değişiklikleri yapan geçerli tarihi ve işlemi ayarlayın.
  3. Başlangıç tarihi geçerlilik sütunu bitiş tarihi geçerlilik sütunu değerine ayarlanmış (önceki sürümü güncelleştirmek için kullanılır) ve geçerli sürüm bayrağı olarak TRUEayarlanmış yeni üyeler ekleyin.
  4. Tablo oluşturma tarihi içeriyorsa ve sütunlar tarafından oluşturulduysa, eklemeleri yapan geçerli tarihi ve işlemi ayarlayın.

SCD türü 3

SCD tür 3 değişiklikleri algılandığında, SCD türü 1'i işlemeye benzer bir mantık kullanarak öznitelikleri güncelleştirin.

Boyut üyesi silme işlemleri

Kaynak verilerin boyut üyelerinin silindiğini (kaynak sistemden alınmadıkları veya silinmiş olarak işaretlendiği için) gösterilip gösterilmediğine dikkat edin. Boyut üyeleri hatayla oluşturulmadığı ve bunlarla ilgili olgu kaydı olmadığı sürece silmeleri boyut tablosuyla eşitlememelisiniz.

Kaynak silme işlemlerini işlemenin uygun yolu, bunları geçici silme olarak kaydetmektir. Geçici silme, boyut üyesini artık etkin veya geçerli değil olarak işaretler. Bu durumu desteklemek için boyut tablonuz gibi IsDeletedbit veri türüne sahip bir Boole özniteliği içermelidir. Silinen boyut üyeleri için bu sütunu (1) olarak TRUE güncelleştirin. Bir boyut üyesinin geçerli, en son sürümü benzer şekilde veya IsActive sütunlarında IsCurrent boole (bit) değeriyle işaretlenebilir. Tüm raporlama sorguları ve Power BI anlam modelleri geçici silme olan kayıtları filtrelemelidir.

Tarih boyutu

Genellikle kaynak verileri olmadığından takvim ve zaman boyutları özel durumlardır. Bunun yerine, bunlar sabit mantık kullanılarak oluşturulur.

Satırlarını belirli bir yıl öncesine genişletmek için her yeni yılın başında tarih boyutu tablosunu yüklemeniz gerekir. Düzenli olarak güncelleştirilecek mali yıl verileri, tatiller, hafta numaraları gibi başka iş verileri de olabilir.

Tarih boyutu tablosu 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.

Tarih boyutu tablosunu genişletme veya güncelleştirme mantığının T-SQL'de yazılmasını ve saklı yordamda kapsüllenmiş olmasını öneririz.

Olgu tablolarını işleme

Olgu tablosunun işlenmesi, veri ambarı verilerinin kaynak sistem olgularıyla eşitlenmesini içerir. Kaynak veriler önce dönüştürülür ve olgu tablosuna yüklenmek üzere hazırlanır. Ardından, her boyut anahtarı için bir arama, olgu satırında depo kullanılacak vekil anahtar değerini belirler. Boyut SCD tür 2'yi desteklediğinde, boyut üyesinin geçerli sürümünün vekil anahtarı alınmalıdır.

Not

Genellikle vekil anahtar, kullanmaları YYYYMMDD veya HHMM biçimlendirmeleri gerektiğinden tarih ve saat boyutları için hesaplanabilir. Daha fazla bilgi için bkz . Takvim ve saat.

Boyut anahtarı araması başarısız olursa, kaynak sistemle ilgili bir bütünlük sorununa işaret edebilir. Bu durumda olgu satırı yine de olgu tablosuna eklenmelidir. Geçerli bir boyut anahtarı yine de depolanmalıdır. Yaklaşımlardan biri, özel bir boyut üyesini (Bilinmiyor gibi ) depolamaktır. Bu yaklaşım, bilindiğinde doğru gerçek boyut anahtarı değerini atamak için daha sonraki bir güncelleştirme gerektirir.

Önemli

Doku Ambarı yabancı anahtarları zorunlu kılmadığından, ETL işleminin olgu tablolarına veri yüklerken bütünlüğü denetlemesi kritik önem taşır.

Doğal anahtarın geçerli olduğuna güvenildiğinde ilgili olan bir diğer yaklaşım da yeni bir boyut üyesi eklemek ve ardından vekil anahtar değerini depolamaktır. Daha fazla bilgi için bu bölümün devamında yer alan Çıkarımlı boyut üyeleri bölümüne bakın.

Aşağıdaki diyagramda olgu tablosunu işlemek için kullanılan mantık gösterilmiştir.

Diyagram, önceki paragraflarda açıklandığı gibi yeni kaynak satırların olgu tablosuna nasıl yüklendiğini açıklayan bir akışı gösterir.

Mümkün olduğunda, bir olgu tablosu artımlı olarak yüklenmelidir, yani yeni olgular algılanır ve eklenir. Artımlı yük stratejisi daha ölçeklenebilirdir ve hem kaynak sistemler hem de hedef sistemler için iş yükünü azaltır.

Önemli

Özellikle büyük bir olgu tablosu için, olgu tablosunun kesilmesi ve yeniden yüklenmesi için son çare olmalıdır. Bu yaklaşım işlem süresi, işlem kaynakları ve kaynak sistemlerde olası kesintiler açısından pahalıdır. Olgu tablosu boyutları SCD türü 2'yi uyguladığında karmaşıklık da içerir. Bunun nedeni, boyut anahtarı aramalarının boyut üyesi sürümlerinin geçerlilik süresi içinde yapılması gerekeceğidir.

Umarım kaynak sistem tanımlayıcılarına veya zaman damgalarına güvenerek yeni olguları etkili bir şekilde algılayabilirsiniz. Örneğin, bir kaynak sistem sıralı satış siparişlerini güvenilir bir şekilde kaydettiğinde, alınan en son satış siparişi numarasını (yüksek filigran olarak bilinir) depolayabilirsiniz. Sonraki işlem, yeni oluşturulan satış siparişlerini almak için bu satış siparişi numarasını kullanabilir ve bir sonraki işlem tarafından kullanılmak üzere alınan en son satış siparişi numarasını depolayabilir. Yeni siparişleri güvenilir bir şekilde algılamak için bir oluşturma tarihi sütunu da kullanılabilir.

Yeni olguları verimli bir şekilde algılamak için kaynak sistem verilerine güvenemiyorsanız, artımlı yük gerçekleştirmek için kaynak sistemin bir özelliğine güvenebilirsiniz. Örneğin, SQL Server ve Azure SQL Yönetilen Örneği, tablodaki her satırda yapılan değişiklikleri izleyebilen değişiklik veri yakalama (CDC) adlı bir özelliğe sahiptir. Ayrıca SQL Server, Azure SQL Yönetilen Örneği ve Azure SQL Veritabanı, değiştirilen satırları belirleyebilen değişiklik izleme adlı bir özelliğe sahiptir. Etkinleştirildiğinde, herhangi bir veritabanı tablosundaki yeni veya değiştirilmiş verileri verimli bir şekilde algılamanıza yardımcı olabilir. Eklenen, güncelleştirilen veya silinen tablo kayıtlarının anahtarlarını depolayan ilişkisel tablolara tetikleyiciler de ekleyebilirsiniz.

Son olarak, öznitelikleri kullanarak kaynak verileri olgu tablosuyla ilişkilendirebilirsiniz. Örneğin, satış siparişi numarası ve satış siparişi satır numarası. Ancak, büyük olgu tablolarında yeni, değiştirilmiş veya silinmiş olguları algılamak çok pahalı bir işlem olabilir. Kaynak sistem işletimsel verileri arşivlediğinde de sorun olabilir.

Çıkarsanan boyut üyeleri

Olgu yükleme işlemi yeni bir boyut üyesi eklediğinde, çıkarsanan üye olarak bilinir. Örneğin, bir otel konuğu giriş yaparken, otel zincirine sadakat üyesi olarak katılması istenir. Üyelik numarası hemen verilir, ancak evraklar konuk tarafından gönderilene kadar (varsa) konuğun ayrıntıları takip edilmeyebilir.

Boyut üyesi hakkında bilinen tek şey doğal anahtarıdır. Olgu yükleme işleminin Bilinmeyen öznitelik değerlerini kullanarak yeni bir boyut üyesi oluşturması gerekir. Daha da önemlisi, denetim özniteliğini IsInferredMember olarak TRUEayarlaması gerekir. Bu şekilde, geç gelen ayrıntılar kaynaklandığında boyut yükleme işlemi boyut satırında gerekli güncelleştirmeleri yapabilir. Daha fazla bilgi için bu makaledeki Geçmiş değişikliği yönetme bölümüne bakın.

Olgu güncelleştirmeleri veya silmeleri

Olgu verilerini güncelleştirmeniz veya silmeniz gerekebilir. Örneğin, bir satış siparişi iptal edildiğinde veya sipariş miktarı değiştirildiğinde. Olgu tablolarını yüklemek için daha önce açıklandığı gibi, değişiklikleri etkili bir şekilde algılamanız ve olgu verilerinde uygun değişiklikleri gerçekleştirmeniz gerekir. İptal edilen sipariş için bu örnekte, satış siparişi durumu büyük olasılıkla Aç olan İptal Edildi olarak değişir. Bu değişiklik, bir satırın silinmesini değil olgu verilerinin güncelleştirilmesini gerektirir. Miktar değişikliği için olgu satırı miktar ölçüsünün güncelleştirilmesi gerekir. Geçici silmeleri kullanma stratejisi geçmişi korur. Geçici silme, bir satırı artık etkin veya geçerli değil olarak işaretler ve tüm raporlama sorguları ve Power BI anlam modelleri geçici silme olan kayıtları filtrelemelidir.

Olgu güncelleştirmelerini veya silmelerini tahmin ettiğinizde, değiştireceğiniz olgu satırlarını tanımlamaya yardımcı olmak için olgu tablosuna öznitelikleri (satış siparişi numarası ve satış siparişi satır numarası gibi) eklemeniz gerekir. Verimli değişiklik işlemlerini desteklemek için bu sütunların dizinini oluşturmayı unutmayın.

Son olarak, olgu verileri özel bir boyut üyesi (Bilinmiyor gibi) kullanılarak eklendiyse, bu tür olgu satırları için geçerli kaynak verileri alan düzenli bir işlem çalıştırmanız ve boyut anahtarlarını geçerli değerlerle güncelleştirmeniz gerekir.

İlgili içerik

Doku Ambarı'na veri yükleme hakkında daha fazla bilgi için bkz: