Bu yazının başlığını ne koymam gerektiği konusunda bir miktar kararsız kaldım, çünkü veri modeli konseptinin birden fazla önemli noktasına değineceğim. Basitten başlayalım: Granülarite Nedir?
Yazı İçeriği
Granülarite Nedir?
Granülarite, fact tablolarındaki kayıtların detay seviyesidir. Örneğin aşağıdaki fact (hareket, transaction, hepsi aynı anlamda) tablosu satış kayıtlarını içeriyor.
Granülaritesi, ürün ve gün seviyesinde.
Bu yazıdaki örnek modelde kullanacağım bütçe tablosundaki detay seviyesi ise farklı!
Ürün ve gün seviyesinde değil, ürün kategorisi ve ay seviyesinde!
Eğer modelinizdeki tüm fact tabloları aynı detay seviyesindeyse, yani aynı granülaritedeyse hayat kolaydır! İlgili master (boyut) tablolardaki anahtar sütunlarla fact tablolarını one-to-many birleştirir geçeriz.
Ama farklı granülarite seviyesindeki tablolarla çalışıyorsak -ki genelde öyledir- kullanabileceğimiz birden fazla yöntem var. Hatta bir de asla ve kata yapmamamız gereken hareket var.
Tüm tabloları modele alalım:
Satışlar tablosunu Ürünler ve Tarih tablosuyla one-to-many birleştirmek kolay. Hepsi aynı seviyede: Ürün ve Gün (Tarih).
Soru şu: Bütçe tablosunu bu modele nasıl gömeceğiz? Kategori ve Ay seviyesinde. Kategori dolaylı olarak ürünün bir özelliği. Ürünler master tablosunda her bir ürünün kategorisi var. Ay, -benzer şekilde- dolaylı olarak tarih tablosunun bir özelliği. Tarih tablosundaki her günün bir ay karşılığı var.
Kullanabileceğimiz yöntemlere bakalım:
Referans Entity Kullanma
Zaman zaman tercih ettiğim, hatta bütçe tablosundaki seviyelerin durumuna göre bazen ilk tercih ettiğim yöntem: Tüm fact tablolarını referans entity kullanarak aynı detay seviyesine getirmek.
Neyi kastediyorum?
Bütçe tablosundaki her bir kategori için, bir referans ürün atıyorum.
Böyle bir tabloyu Home tabındaki “Enter Data” ‘dan manuel oluşturabiliriz.
Ve bütçe tablosuna bu referans Ürün ID’lerini getiriyorum. Power Query tarafında merge ile bunu kolaylıkla yapabiliriz.
Benzer mantıkla, her bir ay için de referans tarih verebiliriz. Bu bir bütçe tablosu olduğu için her ayın ilk gününü referans vermek mantıklı olacaktr. Bunu da Power Query’nin süper özelliklerinden biri olan Column From Examples ile yapabiliriz.
** 2009 bütçe verisi olduğunu varsayarak her ayın 1. günü 2009 şekline sokuyorum.
Bütçe tablosu da artık Ürün-Gün seviyesinde!
Fact Tabloları Asla ve Asla Birbirine Doğrudan Bağlanmaz!
Olması gereken model yapısına geçmeden önce, zaman zaman karşıma çıkan, -çünkü- teknik olarak yapılabilirliği olan ama asla ve kata yapılmaması gereken bir hareketi görelim.
Hem Satışlar hem de Bütçe tablolarında Ürün ID var diye, bu iki tabloyu many-to-many ilişkiyle birbirine bağlamak, teknik olarak mümkün olan, ama asla yapılmaması gereken bir hareket.
Fact tabloları hiçbir zaman için birbirine doğrudan bağlanmaz!
Many-to-many ilişki kurmaya çalıştığınızda size uyarı verir, “ne yaptığını biliyorsundur umarım” kabilinden ama böyle bir ilişkiyi yaratmanıza da müsade eder!
Bu tür bir ilişki, teknik olarak mümkün, ama tamamen yanlış ve çalışıyor gibi gözükse de yanlış sonuçlar üretecektir!
Doğru olan model, ilgili sütunları, ilgili master tablolardaki anahtar sütunlar üzerinden one-to-many ilişkiyle bağlamaktır.
Fact tablolarını bu şekilde aynı granülarite seviyesine getirmek kullanabileceğimiz yöntemlerden biri.
** İlişki tipleriyle ilgili bu ve bu yazıya göz atmak isteyebilirsiniz.
Boyut Tablosunu Fact Tablosuyla Many-to-Many Bağlamak
Bir başka yöntem, fact tablosuyla boyut tablosunu many-to-many ilişkiyle bağlamak.
Bütçe tablosunun orijinal halindeki Kategori sütunu ile Ürünler tablosundaki Kategori sütunlarını many-to-many bağlayabiliriz. Ancak, aradaki ilişkinin yönünü “Both” değil, tek yönlü yapmalıyız. Single (Ürünler filters Bütçe) opsiyonunu seçiyorum. Çünkü amacımız bütçeyi ürünlere/kategorilere göre filtrelemek.
Çift yönlü bıraksak çalışır mı? Çalışır! Ama verinizin yapısına göre, yazacağınız metriklerin detayına göre farklı davranışlar gösterebilir!
Bu tip many-to-many ilişkilerle ilgili bu -olası- farklı davranışları sonraki birkaç yazıda ele alacağım. Çünkü önerilen ve tercih edilen daha iyi bir yöntem var: Köprü tablosu kullanmak!
Köprü Tablosu Nedir?
Köprü tablosu, many-to-many ilişkilerden kurtulup, yerine one-to-many ilişkiler kurabilmemizi sağlayan bir nevi yardımcı ara bağlantı tablosu. İngilizce kaynakları da takip ediyorsanız bridge table diye adlandırılıyor.
Daha önce Dynamics Business Central için bir örnek paylaşmıştım.
Burada da bize lazım olan şey, kategorilerin tekil listesini içeren bir kategori -köprü- tablosu. Bunun için DAX’ı tercih edecek olursak, Ürünler tablosundaki kategori sütununun tekil değer listesini, ALL, VALUES, DISTINCT gibi fonksiyonlarla bulabiliriz.
Create New Table deyip formülü yazalım: Bütçesi olmayan kategoriler olabileceğinden, Ürünler tablosundaki kategori sütununu referans almak daha doğru olur.
Artık bu tabloyu Ürünler ve Bütçe arasına koyup, her iki tabloyla da one-to-many ilişki kurabiliriz.
Many-to-many’den kurtulduk!
Yalnız dikkat etmemiz gereken birkaç nokta var:
Modelde 3 tane kategori sütunu oldu! Ürünler, Bütçe, Kategori Köprü Tablosu, üçünde de var. Görselleri oluştururken hangisini kullanacağız?
Genel kural, ilgili boyuta ait master tablo hangisiyse onu kullanmaktır.
Misal kazara Ürünler tablosundaki Kategori sütununu kullanırsak aşağıdaki gibi bir matris karşımıza çıkabilir!
Her kategorinin karşısında aynı bütçe rakamı var! Çünkü ürünler tablosundan bütçe tablosuna doğru ok yönünde gidemiyoruz, dolayısıyla filtreleri taşıyamıyoruz.
Kullanmamız gereken “Kategori” sütunu, köprü tablosundaki Kategori sütunu.
Eğer ayrı bir köprü tablosunu bu şekilde kullanmak istiyorsak -kullanıcı tecrübesi açısından- iki farklı yöntem seçebiliriz:
- Kategori Köprü tablosu görünür kalsın, Ürünler ve Bütçe tablolarındaki kategori sütunlarını gizle! Yukarıda örneğini yaptık.
- Kategori Köprü tablosunu gizle, Bütçe tablosundaki Kategoriyi de gizle, Ürünler ve Kategori Köprü Tablosu arasındaki ilişkiyi çift yönlü yap!
Hangisini tercih edeceğiniz size kalmış, eğer bir entity-bir master tablo kuralını seviyorsanız ikinci yöntem daha doğru olur.
Çünkü Ürünler entity’sini Ürünler-Kategoriler şeklinde iki master tabloya dağıtmaktansa tek bir tabloda gösteriyorsunuz.
Daha temiz bir tasarım desek yanlış olmaz!
Yazıda kullanılan veri setini ve modelleri -siteye üyeyseniz- indirebilirsiniz.
Sadece üyeler görebilir. Hızlı üyelik için sosyal medya hesabınızla giriş yapabilirsiniz!