13 Ağustos 2024

Conformed Dimension Nedir?

 

CONFORMED DIMENSION VS CONSOLIDATED FACT TABLES

Merhaba arkadaşlar bu yazımda size DWH’ın en kritik konularından biri olan conformed dimensionlardan bahsetmek istiyorum.Hemen hemen tüm görüşmelerde karşınıza çıkmış veya çıkabilecek bir konudur.Aynı zamanda tekrar tekrar fact’ler oluşturmaktan sizi kurtaracak inanılmaz önemli bir konudur.

Hemen hemen her zaman şöyle bir soru karşınıza gelmiştir:biz iki datamartı birleştirmek istiyoruz nasıl yapabiliriz.

Burada örnek olarak E- ticaret sektörünü ve 3 data mart alalım.Getir gibi düşünelim firmaya dair bir bilgim yok farazidir daha rahat anlaşılması için 😊

Bir tanesi Siparişler olsun,bir tanesi Stoklar olsun bir tanesi de Teslimatlar olsun örneğin.

Şimdi bu Datamartları biraz açalım.

Siparişler fact’inde neler vardır?

·       Sipariş ID

·       Müşteri ID

·       Ürün ID

·       Sipariş Tarihi

·       Sipariş Kaynak ID(Web,Mobil vb)

·       Depo ID

·       ...benzeri FK’lar ve aşağıdaki gibi factler

·       Adet

·       Tutar

Ve elbette bu transactional bir facttir.

Stoklar fact’ini düşünelim.

·       Stok ID

·       Stok Tarihi

·       Ürün ID

·       Depo ID

·       Tedarikçi ID

·       ...benzeri FK’lar ve aşağıdaki gibi factler

·        Mevcut Adet

·       Yolda Gelen Adet

·       Yolda Giden Adet

·       Geliş Tutarı

Bu tablo snapshotta tutulabilir son günde tutulabilir ihtiyaç nasılsa.

 

Teslimat fact’ini düşünelim şimdide

·       Teslimat Tarihi

·       Müşteri ID

·       Teslimat Yapan Kurye ID

·       Sipariş ID

·       ...benzeri FK’lar ve aşağıdaki gibi factler

·       Teslimat süresi

·       Adet

 

Bu tablo transactional bir facttir.

Ve dimensionlarımız nelerdir?

Tüm tarihler için Dim Date,Dim Personel,Dim Sipariş,Dim Ürün,Dim Tedarikçi,Dim Depo,Dim Müşteri vb.

Biz her datamartımızı oluşturup ister Analysis service cube’leri istersek Power BI gibi toollarda dataset olarak joinleyip paylaşmıştık zaten.

 

Ama kullanıcı ben Sipariş Datamartındaki Adet ile Stok datamartındaki Adedi yanyana görmek istiyorum dedi.

Bu durumda iki seçeneğiniz vardır ya Consolidated Fact Table dediğimiz iki fact’i birleştirip tek bir fact yaptığınız bir senaryo ya da Conformed Dimension yapısı.

İki yöntemde aslında aynı mantığa sahiptir.Çünkü ikisini de yapabilmek için aynı grain seviyeleri üzerinden gidilmesi gerekir.

Consoliadated fact’i konuşalım önce.

Grain: Detay seviyesi demektir.Aynı detay seviyesi demek ise minimum birleştirme seviyesi aynı olan FK’lar kadardır demektir.

Yani örneğimizde olan Sipariş ve Stok için en dip seviyede Depo Id,Ürün ID,Tarih(Biri için sipariş diğeri için stok tarihi ama bu bizim için önemli değil şuan)’dir.Çünkü her ikisinde aynı olan FK’lar sadece bunlardır.

Peki Sipariş ve Teslimat eşleştirilmek istenseydi ne olurdu?

Müşteri ID,Sipariş ID,Tarih olurdu çünkü her ikisinde ortak olan FK’lar bunlardır.

Peki bunların ortaklığı bize ne sağlar?

Bu 3 FK’ya sahip bir fact oluşturup her iki tablodan measure’ları artık getirebilirsiniz demek.Fakat unutulmaması gereken bir konu var.

Örneğin Sipariş ve Stok için konuşursak Measure’larınızı Depo Id,Ürün ID ve Tarih bazında toplamanız gerekir.Çünkü sizin gerçek fact’inizde olan dip seviyede bir adettir.

Ve elbette bu işlem yapılırken FULL JOIN olarak yapılmalıdır!!Çünkü bir factte olan Depo ID,Ürün Id ve Tarih öbüründe olmayabilir.

Yeni bir fact yarattınız ve bunu datamart olarak çıktınız ve herşey çok güzel ve çalışıyor sorunsuz ama ya kullanıcı bir de Teslimattaki measure’larıda getirmek isterse rapora 😊

Bu durumda 3’lü bir kombinasyonda ortak FK’lar üzerinden measure’lar getirilmeli ve tekrar yeni bir fact yaratılmalıdır.Hak verirsiniz ki bu hem storage hem ETL hem BI tarafında inanılmaz bir yük demektir ve ipin ucu bir noktada muhakkak kaçacaktır.

 

Peki Conformed Dimension ile yapsaydık ne olacaktı?

3 datamartı tek bir olap cube veya power bi dataset’inde oluşturup kullanıcı ile paylaşılmalıdır.

Yani sizin 3 datamartta kullanıdığınız her bir dimension ve fact tek bir yerde olmalı ve en en en önemli nokta dimension tablolar kesinlikle çoklanmamalı tek bir tane olmalı!!!

Şöyle  düşünün Power BI’da filtre(slicer) oluşturmuşsunuz ve Ürün Adı filtresi Dim Ürün’den geliyor Sipariş factindeki measure değişir ama Stokdaki measure değişmez çünkü siz Stok factini Dim_Ürün_Stok tablosu ile eşleştirmişsiniz.Slicerdaki Dim Ürünle ilişki kopmuş!!

 

Bu yapıda hem kullanıcı hem siz 3 datamartı + istenilen kadar consolidated bir yapıyı hemen oluşturabilirsiniz.

Mesela 3 factten measure istenirse sadece Tarih ve Depo bazında olmak şartı ile verebilirsiniz çünkü ortak olan tek FK’lar bunlardır.

Burada çok çok çok önemli bir konu daha,Tüm rapor ve filtrelerinizde factten hiç bir FK kullanmayın.Sadece ve sadece measure için Factlerden veri alın yoksa ilişki koptuğundan dolayı hangi factten tarihi aldıysanız o değişir diğerleri değişmez ve çoklar.

Bunu tek bir datamart ile çalışıyorsanız da böyle yapın.

 

Hemen örnek bir şema oluşturup anlaşılmasını arttıralım.



https://media.licdn.com/dms/image/v2/D4D12AQG_C4m9EP6JYQ/article-inline_image-shrink_1500_2232/article-inline_image-shrink_1500_2232/0/1721198225666?e=1729123200&v=beta&t=kuZd4BHll2_rcOtTRqIWgSPDYt9GhKzH7L3jx-7kNa4


Burada görüldüğü üzere Tedarikçi bazında sadece Stokdan veri verebilirsiniz veya Personel bazında sadece Teslimattan veri verebilirsiniz.

Peki bu yapıda nelere dikkat etmemiz lazım?

Raporlar paylaşırken sadece ortak dimensionları paylaşın çünkü son kullanıcı genelde sizin kadar teknik değildir.

Örneğin Sipariş ve Stok birleştirip bir rapor hazırladınız ve paylaştınız bu durumda Conformed Dimensionlar yani dim_date,dim_ürün,dim_depo ve fact_sipariş ve fact_stok harici tablolarınızı gizleyin görmesinler.

Full paylaşacaksınız muhakkak mantığı anlatın ama bence paylaşmayın 😊

 

 

Hiç yorum yok:

Yorum Gönder