Veri ambarında çoktan çoğa ilişki kurmanın bazı yolları nelerdir?

Veri Ambarı modellemesinin (Star, Snowflake) baskın topolojileri akılda bir-çok ilişkilerle tasarlanmıştır. Sorgu okunabilirliği, performansı ve yapısı, bu modelleme şemalarında çoktan çoğa ilişkiyle karşılaştığında ciddi şekilde düşer.

Bir veri ambarındaki boyutlar arasında veya olgu tablosu ile bir boyut deposu arasında bir çoktan çoğa ilişki kurmanın bazı yolları nelerdir ve gerekli ayrıntı düzeyi ve sorgulama performansıyla ilgili olarak hangi tavizleri verir?

Tecrübelerime göre, özyinelemeli bir hiyerarşi, bununla mücadele etmenin en pratik yoludur. Aşağıdaki avantajları sunar:

1. Sınırsız derinlik
2. Sıkılık.
3. Esneklik.
4. Hız.

Buna karşılık, "birçok kişiye" birleşme düzeylerinin her biri için ekstra bir tablo gerekir. Bu kodlanmış ve şema güncellemelerine karşı bakımı zordur.

Filtrelenmiş dizinleri kullanarak, büyük bir hiyerarşik birleştirme tablosu atanan tablolara göre daha yüksek hızda performans gösterebilir. Bunun nedeni, her bir birleşme işleminin "veri tablosuna birleştirmek" ile karşılaştırıldığında yalnızca "ebeveyn-çocuk" olmasıdır. İkincisi işlemek ve depolamak için daha fazla dizin var.

Bu sorunu yıllardır çözmeye çalışıyorum. Son zamanlarda, işte bunu buldum.

M için bazı senaryolar: Bir veri ambarı modelinde M ilişkileri

Çoğu OLAP sunucusu ve ROLAP sistemi şu anda M: M veri yapılarıyla ilgilenmek için bir araca sahiptir, ancak bununla ilgili dikkat etmeniz gereken bazı uyarılar vardır. M: M ilişkilerini uygularsanız, raporlama katmanınızı ve hangi araçları desteklemek istediğinizi göz önünde bulundurmanız gerekir.

Senaryo 1: M: M, olgu tablosuna boyut

Buna bir örnek, bir motor politikasındaki birden fazla sürücü olabilir. Bir sürücü ekler veya kaldırırsanız, ilke ayarlama işleminde değişiklikle değişen sürücülerin listesiyle bir ilişki olabilir.

Seçenek 1 - M: M sürücü-gerçek köprü tablosu Bu, belirli bir politika için x işlem satırına sahip olduğundan, oldukça büyük bir veri hacmine sahip olacaktır. SSAS bu veri yapısını doğrudan tüketebilir, ancak bir ROLAP aracıyla sorgulamak daha yavaştır.

M: M ilişkiniz, olgu sırasına özgü varlıklara (örneğin arabadaki sürücüler) dayanıyorsa, ROLAP aracınızın M: M ilişkilerini desteklemesini sağlayarak (örneğin, İşletmelerde bağlamlar kullanarak), ROLAP aracı için de uygun olabilir. ) Nesneleri.

Seçenek 2 - Sahte 'kombinasyonlar' boyut tablosu Genel kodların bir listesini bir olgu tablosuna eşliyorsanız (yani, bağlı varlıklar olgu satırına özgü değildir), o zaman veri hacmini azaltacak başka bir yaklaşım benimseyebilirsiniz. Bu tip bir senaryonun bir örneği, yatan hasta ziyaretindeki ICD kodlarıdır. Her yatan hasta ziyaretinde, kendisine karşı listelenen bir veya daha fazla ICD teşhisi ve / veya prosedürü olacaktır. ICD kodları geneldir.

Bu durumda, her bir durum için kod kombinasyonlarının ayrı bir listesini oluşturabilirsiniz. Her farklı kombinasyon için bir sıra içeren bir boyut tablosu yapın ve kombinasyonlar ile ICD kodlarının referans tabloları arasında bir bağlantı tablosuna sahip olun.

Bilgi tablosunda 'kombinasyonlar' boyutunun bir boyut anahtarı olabilir ve boyut satırının gerçek ICD kodlarına bir referans listesi vardır. Çoğu ROLAP aracı bu veri yapısını tüketebilir. Aletiniz sadece gerçek bir M: M ilişkisi ile çalışacaksa, gerçek ile kodlama referans tablosu arasındaki M: M ilişkisini taklit eden bir görünüm oluşturabilirsiniz. SSAS ile tercih edilen yaklaşım bu olacaktır.

Seçenek 1'in avantajları: - Uygun bir şekilde dizine alınmış, M: M tablosu üzerinden belirli bir ilişki içeren olgu tablosu satırlarının seçilmesine dayanan sorgular makul derecede etkili olabilir.

• Biraz daha basit kavramsal model

Seçenek 2'nin avantajları: - Veri depolama daha kompakt

• 'Kombinasyonlar' boyutunda bir kod olarak insan okunabilir bir formatta kombinasyonları sunarak düz 1: M ilişkisini taklit edebilirsiniz. Bu, M: M ilişkilerini desteklemeyen açık raporlama araçları için daha yararlı olabilir.

Senaryo 2: M: M boyutlar arasındaki ilişki:

Bir kullanım durumu düşünmek daha zor, ancak bir kez daha ICD kodları ile sağlık dışında bir şey öngörülüyor olabilir. Bir maliyet analiz sisteminde, yatarak ziyaret, bir boyut haline gelebilir ve ziyaret (ya da NHS-konuşmasında danışman-bölüm) ile kodlamalar arasında M: M ilişkileri olacaktır.

Bu durumda, M: M ilişkilerini kurabilir ve muhtemelen bunların insan tarafından okunabilir bir şekilde oluşturulmasını temel boyutta kodlayabilirsiniz. İlişkiler, düz M: M bağlantı tabloları veya daha önce olduğu gibi köprüleme 'kombinasyonları' tablosu aracılığıyla yapılabilir. Bu veri yapısı Business Objects veya daha iyi kalitede ROLAP araçları ile doğru bir şekilde sorgulanabilir.

Başımın üstünden, SSAS'ın bunu doğrudan olgu tablosuna götürmeden bunu kullanabildiğini göremiyorum, bu nedenle kodlama ile olgu tablosu arasındaki M: M ilişkisinin bir görünümünü sunmanız gerekir. Bu veri ile SSAS kullanmak için satır.

İşlem modelinizde ya da şu an içinde bulunduğu veri modelinde olduğu gibi, modelinizde aklınızdaki ilişkilerin ne tür olduğunu tam olarak bilmek isterim.

Tipik olarak, boyutlar arasındaki çoktan çoğa ilişkiler, boyutlarla ilgili gerçeklerdir. Bir müşterinin birçok müşteriye hizmet veren birkaç şubeden sipariş vermesi veya bunun gibi bir şey olması. Bunların her biri bir gerçek. Etkili bir tarihi veya bunun gibi bir şey olurdu, ancak ilişki "gerçek-az" olabilirdi. İlişki, müşteri ve şube dışında başka boyutlarda olabilir. Bu yüzden merkezinde (potansiyel olarak gerçeği olmayan) bir durum tablosunun bulunduğu tipik bir yıldız şemasıdır. Bu yıldızın depodaki diğer boyutlu yıldızlarla nasıl bir bağlantısı olacağı açıkça belli olacaktır. Farklı yıldızları ne zaman bir araya getirirseniz, iş tuşlarında bunu yapar ve yanlışlıkla çapraz birleşmeler yapmamanızı sağlarsınız.

Tipik olarak, bu boyut ilişkisi tabloları, daha büyük olgu tabloları ile aynı derecede rapor edilmez ve bunu yaparken, her zaman olduğu kadar veri değildir, bu yüzden performansı etkileme eğiliminde değildir. Yukarıdaki durumda, zaman içinde müşteri / şube kullanımına bakabilirsiniz, ancak gerçek sipariş miktarları ile ilgili daha iyi veriler, sipariş verisi tablonuzda mevcut olacaktır, ki bu muhtemelen müşteri, şube vb. İçin de boyutları olacaktır. çoğu insan çoktan çoğa sayılır (bir sipariş müşteriden şubeye çoktan çoğa ilişki tanımlamak için düşünülebilir olsa da), bu nedenle veri ambarı ortamlarında daha tipiktir. Bu ilişki düzeyine - eğer müşteri, şube, ay gibi - özet bilgileri topladıysanız, yalnızca bir çok modelde sayısal toplamalar yapıyor olacaktınız.

Burada, bir çoktan çoka önerilen ilişkinin modellenmesinde geçerli olabilecek Kimball ve diğer ilgili makaleler yer almaktadır. Çoktan çoğa ilişkinin yalnızca sorunlu alan / mantıksal modeldeki bir kavram olduğunu unutmayın. Normalize edilmiş bir OLTP modelinde, elbette, her biri bir çok yol olan bir bağlantı masasıyla idare edilirdi. Normalleştirilmemiş bir Kimball veri ambarı modelinde, bunu yapmanın birkaç yolu vardır; bunlardan biri temelde bu bağlantı tablosunu bir yıldızın merkezinde olduğu gibi ele alır. Bir diğeri bayrak sütunları dizisi gibidir.

Sonuçta, seçim tam olarak neyi modellediğinize, nasıl değiştiğine ve nasıl rapor etmek istediğinize bağlı olacaktır. Bu, boyutsal modelleme ve genel olarak veri depolamasının normalleştirilmiş modelden keskin bir şekilde ayrıldığı yerdir. Normalize edilmiş model, veri ambarlamasının her zaman gerçekçi kullanım durumlarını göz önünde bulundurarak ve bunları gerçekleştirmek için denormalize ettiği verilerdeki mantıksal ve teorik ilişkilere odaklanır.

Bir köprü tablosu kullanarak alternatif hiyerarşileri modelleme:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Çoktan çoğa ilişki için üç seçenek (sayısal paylaşım tahsislerine bağlı - bazı ilginç ileri ve geri bildirimlerin yorumlarına bakın)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

Ne yazık ki, Kimball'ın Enformasyon Haftası / DBMS mag makalelerinin çoğunun artık iyi bağlantıları yok ...

Bunu çözebilmemizin bir yolu, 2'den fazla ya da çok sayıda ilişki gemisine sahip olan 2 boyuttan yabancı anahtar olan sadece 2 sütuna sahip bir Fact tablosuna sahip olmaktır.