Yavaş yavaş değişen boyut - Slowly changing dimension

Bu makale için ek alıntılara ihtiyaç var doğrulama. Lütfen yardım et bu makaleyi geliştir tarafından güvenilir kaynaklara alıntılar eklemek. Kaynaksız materyale itiraz edilebilir ve kaldırılabilir. Kaynakları bulun: "Yavaş değişen boyut"  – Haberler  · gazeteler  · kitabın  · akademisyen  · JSTOR (Mart 2015) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin)

Boyutlar içinde veri yönetimi ve veri depolama nispeten statik içerir veri coğrafi konumlar, müşteriler veya ürünler gibi varlıklar hakkında. Tarafından toplanan veriler Yavaşça Değişen Boyutlar (SCD'ler) Düzenli bir programa göre değil, yavaş ama öngörülemeyen bir şekilde değiştirin.^[1]

Bazı senaryolar neden olabilir bilgi tutarlılığı sorunlar.

Örneğin, bir veri tabanı içerebilir olgu tablosu satış kayıtlarını saklayan. Bu bilgi tablosu boyutlara şu şekilde bağlanacaktır: Yabancı anahtarlar. Bu boyutlardan biri, şirketin satış görevlileri hakkında veriler içerebilir: örneğin, çalıştıkları bölge ofisleri. Bununla birlikte, satış görevlileri bazen bir bölge ofisinden diğerine aktarılır. Geçmiş satış raporlaması amaçları için, belirli bir satış görevlisinin daha önceki bir tarihte belirli bir bölge ofisine atanmış olmasına karşın, bu satış görevlisinin artık farklı bir bölge ofisine atanmış olduğu gerçeğinin bir kaydını tutmak gerekli olabilir.^{[açıklama gerekli ]}

Bu sorunların ele alınması, Tip 0 ila 6 olarak adlandırılan SCD yönetim metodolojilerini içerir. Tip 6 SCD'lere bazen Hibrit SCD'ler de denir.

Tip 0: orijinali koru

Tip 0 boyut öznitelikleri hiçbir zaman değişmez ve kalıcı değerlere sahip olan veya "Orijinal" olarak tanımlanan özniteliklere atanır. Örnekler: Doğum tarihi, Orijinal Kredi Puanı. Tür 0, çoğu Tarih Boyutu özelliği için geçerlidir.^[2]

Tip 1: üzerine yaz

Bu yöntem eskinin üzerine yeni veriler yazar ve bu nedenle geçmiş verileri izlemez.

Tedarikçi tablosu örneği:

Yukarıdaki örnekte, Supplier_Code, doğal anahtar ve Supplier_Key bir Vekil anahtarı. Teknik olarak, yedek anahtar gerekli değildir, çünkü sıra doğal anahtar (Tedarikçi_Kodu) ile benzersiz olacaktır.

Tedarikçi, merkezi Illinois'e taşırsa, kaydın üzerine yazılır:

Tip 1 yönteminin dezavantajı, veri ambarında geçmiş bulunmamasıdır. Avantajı vardır, ancak bakımı kolaydır.

Durumlara göre gerçekleri özetleyen bir toplu tablo hesaplandıysa, Tedarikçi_Durum değiştiğinde bunun yeniden hesaplanması gerekecektir.^[1]

Tip 2: yeni satır ekle

Bu yöntem, belirli bir veri için birden çok kayıt oluşturarak geçmiş verileri izler. doğal anahtar ayrı boyutlu tablolarda vekil anahtarlar ve / veya farklı sürüm numaraları. Her bir ek için sınırsız geçmiş korunur.

Örneğin, tedarikçi Illinois'e taşınırsa, sürüm numaraları sırayla artırılacaktır:

Diğer bir yöntem de 'geçerlilik tarihi' sütunları eklemektir.

İkinci satırın Başlangıç ​​tarihi / saati, önceki satırın Bitiş tarihi / saatine eşittir. İkinci satırdaki boş End_Date, geçerli kayıt sürümünü gösterir. Standartlaştırılmış bir vekil yüksek tarih (örneğin 9999-12-31) bunun yerine bitiş tarihi olarak kullanılabilir, böylece alan bir dizine dahil edilebilir ve böylece sorgulama sırasında boş değer ikamesi gerekmez.

Ve üçüncü bir yöntem, bir geçerlilik tarihi ve geçerli bir bayrak kullanır.

'Y'nin Current_Flag değeri, mevcut demet versiyonunu gösterir.

Belirli bir atıfta bulunan işlemler Vekil anahtarı (Tedarikçi_Anahtar) daha sonra, yavaşça değişen boyut tablosunun bu satırı tarafından tanımlanan zaman dilimlerine kalıcı olarak bağlanır. Gerçekleri eyalete göre özetleyen toplu bir tablo, tarihsel durumu, yani tedarikçinin işlem sırasında bulunduğu durumu yansıtmaya devam etmektedir; güncelleme gerekmez. Varlığa doğal anahtar aracılığıyla başvurmak için benzersiz kısıtlama yapmanın kaldırılması gerekir. Bilgi tutarlılığı DBMS tarafından imkansız.

Boyutun içeriğinde geriye dönük değişiklikler yapılmışsa veya boyuta önceden tanımlanmış olanlardan farklı geçerlilik tarihlerine sahip yeni öznitelikler (örneğin bir Satış_Rep sütunu) eklenmişse, bu durum mevcut işlemlerin yapılması gerekmesine neden olabilir. yeni durumu yansıtacak şekilde güncellendi. Bu pahalı bir veritabanı işlemi olabilir, bu nedenle, boyutsal model sık sık değişime maruz kalıyorsa Tip 2 SCD'ler iyi bir seçim değildir.^[1]

Tür 3: yeni öznitelik ekleyin

Bu yöntem, değişiklikleri ayrı sütunlar kullanarak izler ve sınırlı geçmişi korur. Tip 3, geçmiş verileri depolamak için belirlenmiş sütun sayısıyla sınırlı olduğundan sınırlı geçmişi korur. Tip 1 ve Tip 2'deki orijinal tablo yapısı aynıdır ancak Tip 3 ek sütunlar ekler. Aşağıdaki örnekte, tedarikçinin orijinal durumunu kaydetmek için tabloya ek bir sütun eklenmiştir - yalnızca önceki geçmiş saklanır.

Bu kayıt, orijinal durum ve mevcut durum için bir sütun içerir — tedarikçi ikinci kez yer değiştirirse değişiklikleri izleyemez.

Bunun bir varyasyonu, yalnızca en son tarihsel değişikliği takip edecek olan Original_Supplier_State yerine Previous_Supplier_State alanını oluşturmaktır.^[1]

Tip 4: geçmiş tablosu ekle

Tip 4 yöntem genellikle "geçmiş tabloları" olarak adlandırılır, burada bir tablo mevcut verileri tutar ve ek bir tablo, değişikliklerin bir kısmının veya tümünün kaydını tutmak için kullanılır. Her iki vekil anahtar, sorgu performansını artırmak için Fact tablosunda belirtilir.

Yukarıdaki örnek için, orijinal tablo adı şöyledir: Tedarikçi ve geçmiş tablosu Supplier_History.

Bu yöntem, veritabanı denetim tablolarının ve veri yakalamayı değiştir teknikler işlevi.

Tür 5

Tip 5 tekniği, tip 1 özniteliği olarak üzerine yazılan temel boyuta bir "geçerli profil" mini boyut anahtarı yerleştirerek tip 4 mini boyutuna dayanır. 4 + 1, 5'e eşit olduğu için tip 5 olarak adlandırılan bu yaklaşım, şu anda atanmış olan mini boyut özellik değerlerine, bir olgu tablosu aracılığıyla bağlantı kurmadan temel boyutun diğerleriyle birlikte erişilmesine olanak tanır. Mantıksal olarak, tipik olarak temel boyutu ve mevcut mini boyutlu profil payandasını sunum katmanında tek bir tablo olarak temsil ederiz. Destekleyici nitelikleri, bunları olgu tablosuna bağlı mini boyuttaki özelliklerden ayırmak için "Mevcut Gelir Düzeyi" gibi farklı sütun adlarına sahip olmalıdır. ETL ekibi, mevcut mini boyut zaman içinde her değiştiğinde tip 1 mini boyut referansını güncellemeli / üzerine yazmalıdır. Destek ayağı yaklaşımı tatmin edici bir sorgu performansı sağlamazsa, mini boyut öznitelikleri temel boyuta fiziksel olarak gömülebilir (ve güncellenebilir).^[3]

Tip 6: kombine yaklaşım

Tür 6 yöntem, tip 1, 2 ve 3 (1 + 2 + 3 = 6) yaklaşımlarını birleştirir. Terimin kökeninin olası bir açıklaması, terimin icat edilmiş olmasıdır. Ralph Kimball Kalido'dan Stephen Pace ile bir konuşma sırasında^{[kaynak belirtilmeli ]}. Ralph Kimball bu yöntemi "Tek Sürümlü Yer Paylaşımlı Öngörülemeyen Değişiklikler" olarak adlandırır. Veri Ambarı Araç Seti.^[1]

Tedarikçi tablosu, örnek tedarikçimiz için bir kayıtla başlar:

Current_State ve Historical_State aynıdır. İsteğe bağlı Current_Flag niteliği, bunun bu tedarikçi için mevcut veya en son kayıt olduğunu belirtir.

Acme Supply Company Illinois'e taşındığında, Tip 2 işlemede olduğu gibi yeni bir kayıt ekleriz, ancak her satır için benzersiz bir anahtara sahip olduğumuzdan emin olmak için bir satır anahtarı dahil edilir:

Birinci kayıttaki (Row_Key = 1) Current_State bilgisinin üzerine Type 1 işlemede olduğu gibi yeni bilgiler yazıyoruz. Tip 2 işlemede olduğu gibi değişiklikleri takip etmek için yeni bir kayıt oluşturuyoruz. Ve geçmişi, Tip 3 işlemeyi içeren ikinci bir Durum sütununda (Historical_State) saklarız.

Örneğin, tedarikçi yeniden yer değiştirecek olsaydı, Tedarikçi boyutuna başka bir kayıt eklerdik ve Current_State sütununun içeriğinin üzerine yazardık:

Tip 2 / tip 6 olgu uygulaması

Tip 3 özniteliğine sahip 2 vekil anahtar yazın

Birçok Tip 2 ve Tip 6 SCD uygulamasında, Vekil anahtarı boyuttan bilgi tablosunun yerine doğal anahtar olgu verileri veri havuzuna yüklendiğinde.^[1] Vekil anahtar, belirli bir olgu kaydı için geçerli tarihine ve boyut tablosundan Başlangıç_Tarihi ve Bitiş_Tarihine göre seçilir. Bu, olgu verilerinin karşılık gelen geçerlilik tarihi için doğru boyut verilerine kolayca birleştirilmesine olanak tanır.

Type 6 Hybrid metodolojisini kullanarak yukarıda oluşturduğumuz Tedarikçi tablosu:

Teslimat tablosu doğru Supplier_Key'i içerdiğinde, bu anahtar kullanılarak Tedarikçi tablosuna kolayca birleştirilebilir. Aşağıdaki SQL, her olgu kaydı için mevcut tedarikçi durumunu ve teslimat sırasında tedarikçinin bulunduğu durumu alır:

SEÇ  teslimat.Teslimat maliyeti,  Tedarikçi.sağlayıcı adı,  Tedarikçi.history_state,  Tedarikçi.şu anki durumFROM teslimatİÇ KATILMAK Tedarikçi  AÇIK teslimat.tedarikçi_anahtar = Tedarikçi.tedarikçi_anahtar;

Saf tip 6 uygulaması

Her bir zaman dilimi için bir Tip 2 vekil anahtarına sahip olmak, boyut değişecekse sorunlara neden olabilir.^[1]

Saf bir Tip 6 uygulaması bunu kullanmaz, ancak her ana veri öğesi için bir Vekil Anahtar kullanır (örneğin, her benzersiz tedarikçinin tek bir vekil anahtarı vardır).

Bu, ana verilerdeki mevcut işlem verileri üzerinde bir etkiye sahip herhangi bir değişikliği önler.

İşlemleri sorgularken daha fazla seçeneğe de izin verir.

Saf Tip 6 metodolojisini kullanan Tedarikçi tablosu:

Aşağıdaki örnek, her işlem için tek bir tedarikçi kaydının alınmasını sağlamak için sorgunun nasıl genişletilmesi gerektiğini gösterir.

SEÇ  Tedarikçi.tedarikçi_kodu,  Tedarikçi.Supplier_stateFROM TedarikçiİÇ KATILMAK teslimat  AÇIK Tedarikçi.tedarikçi_anahtar = teslimat.tedarikçi_anahtar VE teslimat.teslim tarihi >= Tedarikçi.Başlangıç ​​tarihi VE teslimat.teslim tarihi < Tedarikçi.bitiş tarihi;

Yürürlük tarihi 9 Ağustos 2001 olan bir olgu kaydı (Teslimat_tarihi) ABC'nin Supplier_Code'una 'CA' Supplier_State ile bağlanacaktır. Yürürlük tarihi 11 Ekim 2007 olan bir olgu kaydı da aynı Supplier_Code ABC'ye, ancak "IL" Tedarikçi_ Durumu'na bağlanacaktır.

Daha karmaşık olsa da, bu yaklaşımın aşağıdakiler dahil birçok avantajı vardır:

1. Bilgi tutarlılığı DBMS ile artık mümkündür, ancak Tedarikçi_Code'u şu şekilde kullanılamaz: yabancı anahtar Ürün tablosunda ve Tedarikçi_Anahtarını yabancı anahtar olarak kullanarak her ürün belirli bir zaman dilimine bağlıdır.
2. Gerçekte birden fazla tarih varsa (örneğin, Sipariş Tarihi, Teslimat Tarihi, Fatura Ödeme Tarihi) bir sorgu için hangi tarihin kullanılacağını seçebilir.
3. Tarih filtresi mantığını değiştirerek "şu anda olduğu gibi", "işlem zamanında olduğu gibi" veya "bir anda olduğu gibi" sorguları yapabilirsiniz.
4. Boyut tablosunda bir değişiklik varsa (örneğin geriye dönük olarak zaman dilimlerini değiştiren ek alanlar eklemek veya boyut tablosundaki tarihlerde hata yaparsanız, bunları kolayca düzeltmek için) Fact tablosunu yeniden işlemeniz gerekmez. .
5. Tanıtabilirsin iki zamansal boyut tablosundaki tarihler.
6. Aynı bilgilerin farklı geçerlilik tarihleriyle aynı sorguda raporlanmasına izin vermek için gerçeği boyut tablosunun birden çok sürümüne birleştirebilirsiniz.

Aşağıdaki örnek, '2012-01-01T00: 00: 00' (mevcut tarih saat olabilir) gibi belirli bir tarihin nasıl kullanılabileceğini gösterir.

SEÇ  Tedarikçi.tedarikçi_kodu,  Tedarikçi.Supplier_stateFROM TedarikçiİÇ KATILMAK teslimat  AÇIK Tedarikçi.tedarikçi_anahtar = teslimat.tedarikçi_anahtar VE Tedarikçi.Başlangıç ​​tarihi <= '2012-01-01T00: 00: 00' VE Tedarikçi.bitiş tarihi > '2012-01-01T00: 00: 00';

Hem vekil hem de doğal anahtar

Alternatif bir uygulama yerleştirmektir her ikisi de Vekil anahtarı ve doğal anahtar olgu tablosuna.^[4] Bu, kullanıcının aşağıdakilere dayalı olarak uygun boyut kayıtlarını seçmesine olanak tanır:

• olgu kaydındaki birincil geçerlilik tarihi (yukarıda),
• en son veya güncel bilgiler,
• olgu kaydıyla ilişkili diğer herhangi bir tarih.

Bu yöntem, Tip 6 yerine Tip 2 yaklaşımı kullanılsa bile boyuta daha esnek bağlantılar sağlar.

Tip 2 metodolojisini kullanarak oluşturmuş olabileceğimiz Tedarikçi tablosu şu şekildedir:

Aşağıdaki SQL, her olgu kaydı için en güncel Supplier_Name ve Supplier_State'i alır:

SEÇ  teslimat.Teslimat maliyeti,  Tedarikçi.sağlayıcı adı,  Tedarikçi.Supplier_stateFROM teslimatİÇ KATILMAK Tedarikçi  AÇIK teslimat.tedarikçi_kodu = Tedarikçi.tedarikçi_koduNEREDE Tedarikçi.current_flag = 'Y';

Olgu kaydında birden fazla tarih varsa olgu, birincil geçerlilik tarihi yerine başka bir tarih kullanılarak boyuta birleştirilebilir. Örneğin, Teslimat tablosunun birincil bir geçerlilik tarihi Teslimat_tarihi olabilir, ancak aynı zamanda her kayıtla ilişkili bir Sipariş_Tarihi de olabilir.

Aşağıdaki SQL, Order_Date temelinde her olgu kaydı için doğru Supplier_Name ve Supplier_State'i alır:

SEÇ  teslimat.Teslimat maliyeti,  Tedarikçi.sağlayıcı adı,  Tedarikçi.Supplier_stateFROM teslimatİÇ KATILMAK Tedarikçi  AÇIK teslimat.tedarikçi_kodu = Tedarikçi.tedarikçi_kodu VE teslimat.sipariş tarihi >= Tedarikçi.Başlangıç ​​tarihi VE teslimat.sipariş tarihi < Tedarikçi.bitiş tarihi;

Bazı uyarılar:

• Bilgi tutarlılığı İlişkiyi oluşturmak için benzersiz bir anahtar olmadığından DBMS ile mümkün değildir.
• Yukarıdaki problemi çözmek için vekil ile ilişki kurulursa, o zaman belirli bir zaman dilimine bağlı varlık ile biter.
• Birleştirme sorgusu doğru yazılmazsa, yinelenen satırlar döndürebilir ve / veya yanlış yanıtlar verebilir.
• Tarih karşılaştırması iyi sonuç vermeyebilir.
• Biraz İş zekası araçlar karmaşık birleşimler oluşturmayı iyi karşılamaz.
• ETL Boyut tablosunu oluşturmak için gereken süreçlerin, her bir farklı referans verisi öğesi için zaman periyotlarında hiçbir örtüşme olmamasını sağlamak için dikkatlice tasarlanması gerekir.

Türleri birleştirmek

Scd modeli örneği

Bir tablonun farklı sütunlarına farklı SCD Türleri uygulanabilir. Örneğin, Type 1'i aynı tablonun Supplier_Name sütununa ve Type 2'yi Supplier_State sütununa uygulayabiliriz.

Ayrıca bakınız

• Veri yakalamayı değiştir
• Zamansal veritabanı
• Günlük tetikleyici
• Varlık-öznitelik-değer modeli - Dikey
• Çok kiracılık

Notlar

Referanslar