Kayıt Ol

Giriş

Şifremi Kaybettim

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

soru ekleme

Soru sormak için giriş yapmalısınız.

Giriş

Kayıt Ol

.........

Designing Dimension Tables

Designing Dimension Tables

Veri ambarı için boyutsal modeller tasarladıktan sonra, tasarımı veritabanının mantıksal bir şemasına çevirebilirsiniz. Bununla birlikte, Dimension tablolarını tasarlamadan önce, bazı ortak tasarım desenlerini dikkate almanız ve bunları tablo özelliklerine uygulamanız önemlidir. Bu ders, Dimension tablolarını tasarlarken göz önüne alınması gereken bazı hususları açıklayacağız.

Dimension Key’leri için Dikkat Edilmesi Gerekenler

1

Bir dimension tablosundaki her bir satır, fact tablosundaki measure’lerin toplanabileceği bir iş varlığının bir örneğini gösterir. Bir veritabanındaki diğer tablolar gibi, bir anahtar sütunu da dimension tablosundaki her satırı benzersiz şekilde tanımlar.Birçok senaryoda, Dimension’ın verileri, bir key’in zaten atandığı bir kaynak sistemden elde edilir.Ancak bir veri ambarını tasarlarken, her satırı tanımlamak için bir tamsayı değeri kullanan yeni bir “surrogate” key tanımlamak standart bir uygulamadır.Bir Surrogate key aşağıdaki nedenlerden dolayı önerilir:

  • Veri ambarı, çoklu kaynak sistemlerinden gelen dimension verilerini kullanabilir, bu nedenle business keyleri benzersiz olmayabilir.
  • Bazı kaynak sistemler, veri varlıklarını benzersiz şekilde tanımlamak için, genel benzersiz tanımlayıcı (GUID) gibi sayısal olmayan key’leri veya bir e-posta adresi gibi natural key’leri kullanır. Tamsayı keyleri daha küçük ve fact tablolardan join’ler  yapılarak daha verimli kullanılır.
  • Bir dimension Tablodaki her satır bir işletme  örneğinin belirli bir modelini temsil eder.Dimension tablosu “Tür 2” yi  Slowly changing dimension’ları destekliyorsa, tablonun aynı öğenin farklı modellerini temsil eden birden çok satır içermesi gerekebilir. Bu satırların business key’leri aynı olacak ve surrogate key’i olmadan benzersiz olarak tanımlanamayacaktır.

Genellikle, business key’i dimension tablosunda bir “alternatif” key olarak kalır. Natural key’lere dayalı business key’leri, verileri analiz eden kullanıcılar tarafından bilinmelidir. Örneğin, kullanıcıların tanıyacağı bir ProductCode business key’i, Ürün boyutu tablosunda alternatif key olarak kullanılabilir. Bununla birlikte, bir business key’i kullanmanın temel nedeni, dimension tablosuna yeni veri yüklerken Slowly changing dimension’ları yönetmeyi kolaylaştırmaktır. ETL işlemi, bir iş varlığının bir örneğinin dimension tablosunda zaten olup olmadığını belirlemek için alternatif key’i bir arama sütunu olarak kullanabilir.

Dimension Attribute’lar ve Hiyerarşiler

2

Surrogate ve alternatif anahtar sütunlarına ek olarak, bir dimension tablosu raporlamayı ve analitik gereksinimleri desteklemek için gereken iş varlığının her bir özelliği için bir sütun içerir.Bir dimension tablosu tasarlarken, raporlarda ve analizlerde kullanılacak nitelikleri tanımlamanız ve eklemeniz gerekir. Tipik olarak, dimension öznitelikleri aşağıdaki üç yoldan biriyle kullanılır:

  • Hiyerarşiler:Çoğu durumda dimensionlar daha büyük bir yapının üyesi durumundadırlar. Bu yapıya hiyerarşi adı verilir.Hiyerarşiler iki ya da daha fazla ilişkili dimension’dan meydana gelen yapılardır. Üst seviyede bulunan bir dimenison, bir sonraki seviyeye ait bir daha fazla dimension’ı içerir. Kullanıcıların daha derin ayrıntı seviyelerine kadar detaylandırmasına olanak tanıyan hiyerarşileri oluşturmak için birden fazla Attribute birleştirilebilir. Örneğin, Müşteri tablosunun olduğunu düşünelim, doğal bir coğrafi hiyerarşi oluşturmak üzere birleştirilebilecek Ülke, Eyalet ve Şehir Attribute’larını içersin. iş kullanıcıları, satış siparişinin gelirini ülkelere göre görmek gibi, toplu gerçek verileri her seviyede görüntüleyebilir. Ardından belirli bir ülkeye girip devlete göre dökümünü görebilir, satış gelirlerini şehire göre görmek için belirli bir ülkeye daha fazla şube açabilirler.
  • Slicer’lar: Attribute’ların, analiz ve raporlamada kullanışlı olması için hiyerarşiler oluşturulması gerekmez. İş kullanıcıları, verilerin analitik alt gruplarını oluşturmak için verileri tek düzeyli hiyerarşilere dayalı olarak gruplayabilir veya filtreleyebilir. Örneğin, Müşteri tablosundaki Cinsiyet özelliği, erkek ve kadın müşterilerin satış gelirlerini karşılaştırmak için kullanılabilir.
  • Drill-through ayrıntısı: Bazı Attribute’ların Slicer’lar veya hiyerarşi üyeleri olarak çok az değeri vardır. Örneğin, bir iş kullanıcısının satış gelirini müşteri telefon numarasına göre analiz etmesi gerekmeyebilir. Bununla birlikte, raporlara veya analitik uygulamalara Drill-through işlevselliğini kolaylaştırmak için varlığa özel attribute’lar eklemek yararlı olabilir. Örneğin, kullanıcıların tek tek sipariş seviyelerine kadar ayrıntılı bilgi bulmalarını sağlayan bir satış sipariş raporunda, kullanıcılar bir siparişi çift tıklatıp, onu ısmarlayan müşterinin adını ve telefon numarasını görmek isteyebilir.

Unknown ve None

3

Genel bir kural olarak, veri ambarınızı, özellikle de dimension tablolarını referans alan fact tablolarının anahtar sütunlarındaki NULL değerlerini ortadan kaldırın veya en azından en aza indirecek şekilde tasarlamayı deneyin. NULL değerleri yanlışlıkla raporların satırlarını ortadan kaldırıp ,yanıltıcı toplamlar üretmeyi kolaylaştırır.

NULL eşitliği

Bir SQL Server veritabanındaki ayarlara bağlı olarak, eşitlik için NULL değerlerini karşılaştırabilmeniz mümkün olmayabilir.En mutlak tanımlamasında, NULL bilinmiyen demektir; bu nedenle, bir “NULL = NULL” karşılaştırması aslında bilinmeyen bir değerin diğeriyle aynı olup olmadığını karşılaştırıyor ve her iki değer bilinmediği için cevap da bilinmiyor(Ve dolayısıyla NULL). ETL yükleme işlemi sırasında arama sorguları, bu anahtarı, bir dimension satırının zaten mevcut olup olmadığını belirlemek için yüklenen veriyle karşılaştırması gerektiği için, “Bilinmeyen” dimension satırının alternatif key’i olarak NULL kullanmamalısınız. Bunun yerine, varolan bir business key’i ile aynı olması muhtemel olmayan uygun bir key değeri kullanın, ve aşağıdaki kod örneğinde gösterildiği gibi kaynak satırlarını dimension satırlarıyla karşılaştırmak için Transact-SQL ISNULL işlevini kullanın:

Designing Slowly Changing Dimensions

4

Slowly changing dimensions (SCDs), Dimension tablolarının tasarımında önemli bir husustur.

SCD’lerde attribute değerinin değişikliklerini işlemek için kullanılan üç yaygın teknik vardır:

  • Tip 1. Bu değişiklikleri uygulamak için en basit SCD türüdür. Attribute değerleri doğrudan mevcut dimension tablosunun satırında güncellenir ve geçmiş tutulmaz.
  • Tip 2. Bu değişiklikler, dimension varlığının yeni bir sürümünün yeni bir satır şeklinde oluşturulmasını içerir.Genellikle, boyut tablosundaki bir bit sütun, boyut satırının hangi sürümünün geçerli olduğunu göstermek için bayrak olarak kullanılır.Ayrıca, tarih saat sütunları, genellikle satırın bir sürümünün geçerli olduğu dönemin başlangıç ve bitişini belirtmek için kullanılır.
  • Tip 3. Bu değişiklikler nadiren kullanılır. Bir Tip 3 değişikliğinde, önceki değer, dimension tablosunun satırında saklanır. Bu, izlenen her attribute için yeni değerler barındıracak dimension tablosu şemasını değiştirmeyi gerektirir ve yönetilmesi zor olan karmaşık bir dimension tablosuna neden olabilir.

Time Dimension Tables

5

Analiz ve raporlama gereksinimlerinin çoğu, zaman aralıklarında değer toplama gereksinimini içerir; bu nedenle hemen hemen her veri ambarı bir time dimension tablosu içerir. Bir time dimension tablosu tasarlarken, dikkate alınması gereken noktalar şunlardır:

  •  Surrogate key. Dimension tablolarındaki surrogate key’ler için en iyi uygulama normal olarak anlamsal anlamı olmayan basit bir tamsayı değerini kullanmak olsa da, time dimension tabloları, satırın temsil ettiği tarih veya saatin bir tamsayı gösteriminden yararlanabilir.İdeal olarak, değerler temsil ettikleri tarihlere göre artan sırada olmalıdır, bu nedenle en iyi yaklaşım her tarih bölümü için tam sayı değerlerini kapsamın azalan sırasına göre birleştirmektir.Örneğin, tarihleri temsil etmek için YYYYMMDD modelini kullanarak, 31 Ocak 2013 değeri 20130131 olur. Bu, 1 Şubat 2013’ün bir sonraki ardışık tarihi için kullanılan değerin 20130201’den daha yüksek bir değer olmasını sağlar. Artan değerler ,veri ambarı sorguları genellikle bir dizi tarih veya saat değerinde filtre uygulayacağından önerilir. Artan sayısal anahtarı, olgu verilerini kronolojik sırayla depolayan dizinleri ve bölümleri kullanmanıza ve sorgu iyileştiricisinin verileri okumak için ardışık taramaları etkinleştirmesine olanak tanır. Ayrıca, satıra ait gerçek tarih / saat değeri, genellikle datetime işlevlerini veya datetime özgü mantığı uygulayabilecek istemci uygulamalarını desteklemek için diğer anahtar olarak kullanılır.
  • Granularity. Bir time dimension tablosu için kullanılan ayrıntı düzeyi, iş gereksinimlerine bağlıdır.Satış siparişleriyle ilgili ayrıntıları görüntüleme gibi birçok raporlama ve analiz senaryosunda, gerekli olması muhtemel en düşük düzey düzeyi bir gündür. Bununla birlikte, bazı senaryolarda, kullanıcıların gerçekleri saat, dakika veya saniye ile hatta daha küçük artışlarla toplaması gerekebilir. Kullanılan ayrıntı düzeyi ne kadar düşükse, dimension tabloda daha fazla satır bulunur ve bir satırı bir günden daha kısa sürelerle saklamak, son derece büyük tablolara neden olabilir. Alternatif bir yaklaşım, her gün için bir satır içeren bir “tarih” dimension tablosu ve 24 saatlik bir periyotta her gerekli zaman artışı için bir satır depolayan bir “zaman” dimension tablosu oluşturmaktır. Ölçülerin gün düzeyi veya daha yüksek bir seviyesinde analiz edilmesinde kullanılan fact tablolar yalnızca tarih dimension tablosuyla ilişkilendirilebilir. Daha küçük zaman artışlarıyla ölçülen Fact’ler hem tarih hem de zaman dimension tablolarıyla ilişkilendirilebilir.
  • Range. Tipik olarak, bir time dimension tablosu, aralık bırakmadan bir başlangıç noktası ile bitiş noktası arasındaki her artım için bir satır saklar. Örneğin, satış siparişlerini analiz etmek için kullanılan bir veri ambarı time dimension, araya giren günlerde sipariş verilmemiş olsa bile, her gün için ilk ve son siparişler arasında bir sıraya sahip olabilir. Gerçekte başlangıç ve bitiş tarihleri genellikle önemli takvim tarihlerine dayanır. Örneğin, başlangıç tarihi, şirketin ticarete başladığı yılın 1 Ocak tarihi veya ilk mali yılının başladığı tarih olabilir. Bitiş tarihi genellikle cari yılın sonu gibi gelecekteki bazı noktalardır. Gelecekteki tarihlerin arabelleğini korumak için, bitiş tarihi yaklaştıkça otomatik olarak daha fazla satır eklenir. Veri ambarı gelecekteki operasyonlar için projeksiyonlar veya bütçe rakamları yaratmak ve depolamak için kullanılacaksa, gelecekte yeterince uzanan bir bitiş tarihi seçmeniz gerekecektir.
  • Attribute’lar ve Hiyerarşiler. Verilerin toplatılacağı her dönem için, örneğin yıl, çeyrek, ay, hafta ve gün gibi nitelikler eklemelisiniz.Bu nitelikler doğal hiyerarşileri oluşturmaya eğilimlidir. Ayrıca, “hafta içi” gibi slicer olarak kullanılacak öznitelikler de ekleyebilirsiniz; bu, örneğin, kullanıcıların haftanın her günü için tipik satış hacimlerini karşılaştırabilmelerini sağlar.Sayısal değerlere ek olarak, tarih elemanı adlarına, örneğin “ay” ve “gün” gibi nitelikler eklemek isteyebilirsiniz.Bu, Mesela kullanıcıların aylar 3 ve 4 yerine Mart ve Nisan aylarında satışları karşılaştırabildiği daha erişilebilir raporlar sağlar. İstemci uygulamaları bunları, verileri doğru kronolojik sıraya göre sıralamak için kullanabilmeleri için sayısal eşdeğerleri de dahil etmelidir. Ay adıyla değil, ay sayılarına göre sıralama.
  • Multiple calendars. Birçok organizasyon, birden fazla takvimi, örneğin Ocak – Aralık aylarında çalışan normal bir yılı ve Nisan’dan Mart’a kadar sürebilecek bir mali takvimi desteklemelidir. Veri ambarı bu durumda ise, her bir takvim için ayrı bir time dimension tablosu oluşturabilir veya daha tercihen tek bir time dimension tablosundaki tüm alternatif takvim değerlerine ilişkin özellikleri ekleyebilirsiniz. Örneğin, bir time dimension tablosunda Takvim Yılı ve Mali Yıl nitelikleri olabilir.
  • Unknown values. Diğer dimension tablolarıyla ortak olarak, tarih veya saat değerinin bilinmediği fact’leri desteklemeniz gerekebilir.Fact tablosunda bir Null değer gerektirmek yerine, zaman boyutu tablosunda bilinmeyen değerler için bir satır oluşturmayı düşünün. Bu satır için belirgin bir surrogate key değerini (00000000 gibi) kullanabilirsiniz. Bununla birlikte, alternatif anahtarın geçerli bir tarih olması gerektiği için, 1 Ocak 1753 veya 31 Aralık 9999 gibi  iş operasyonlarının normal aralığı dışındaki alanı seçmemeniz gerekir. Bunlar, tarih / saat veri türünün desteklediği minimum ve maksimum değerlerdir .

Populating a Time Dimension Table

Bir veri ambarındaki diğer tabloların çoğunun aksine, time dimension tabloları genellikle bir kaynak sistemden ayıklanan verilerle doldurulmaz. Genellikle, veri ambarı geliştirici time dimension tablosunu uygun ayrıntı cinsinden satırlarla doldurur. Bu satırlar genellikle temporal değerden (örneğin 1 Ocak 2011 için 20110101) türetilen sayısal birincil anahtardan ve her dimension özniteliği için bir sütun (örneğin, tarih, günün günü, gün adı, yılın ayı, Ayın adı, yılı ve benzeri). Time dimension tablosunun satırlarını oluşturmak için aşağıdaki tekniklerden birini kullanabilirsiniz:

  • Create a Transact-SQL script.  Transact-SQL, zaman aralıkları dizisi için gerekli öznitelik değerlerini oluşturmak için bir döngü yapısında kullanabileceğiniz birçok tarih ve saat işlevleri içerir. Aşağıdaki Transact-SQL işlevleri, tarih ve saat değerlerini hesaplamak için yaygın olarak kullanılır:
    • DATEPART (datepart, date), bir tarihin, hafta içi gün sayısı, ayın günü, yılın ayı gibi sayısal bölümlerini döndürür.
    • DATENAME (datepart, date), tarihin bir bölümünün, örneğin, hafta içi adı veya ayın adı gibi dize adını döndürür.
    • MONTH (date), belirli bir tarih için yılın ay sayısını döndürür.
    • YEAR (date), belirli bir tarihe karşılık yılı döndürür.
  • Use Microsoft® Excel®. Excel, tarih ve saat değerlerine formüller oluşturmak için kullanabileceğiniz birkaç işlev içerir. Ardından, zaman aralıkları dizisine geniş bir değer tablosu oluşturmak için Excel’deki otomatik doldurma işlevini kullanabilirsiniz.
  • Use a BI tool to autogenerate a time dimension table. Bazı BI araçları time dimension tablosu oluşturmak için kullanabileceğiniz time dimension oluşturma işlevselliğini içerir.

Self-Referencing Dimension Tables

Bir veri ambarında ortak bir gereklilik, ebeveyn-çocuk hiyerarşileri ile dimension’ları desteklemektir. Örneğin, bir çalışan dimension’ı, her biri kendisine rapor veren çalışanlara sahip yöneticilerden oluşabilir ve bu yöneticilerin kendi raporları olabilir.

Genellikle, ebeveyn çocuk hiyerarşileri, her bir satırdaki bir sütunun, aynı tablodaki birincil anahtar değerine yapılan bir yabancı anahtar referansı olarak kullanıldığı self-referencing tablolar olarak uygulanır.SQL Server Analysis Services de dahil olmak üzere bazı istemci uygulamaları self-join’lerden haberdardır ve bir dimension’daki üst-alt hiyerarşileri otomatik olarak işleyebilir. Diğer uygulamalar için, bu hiyerarşilerin analizini ve raporlamasını etkinleştirmek için bazı özel, yinelenen mantık uygulamanız gerekebilir.

Veri ambarında self-referencing dimension tablosu uyguladığınızda, aşağıdaki hususlar önemlidir:

  • Tüm dimension load operasyonları gibi, dimension tablosuna kayıtlar eklendiğinde, ETL işlemi varlık için bir kayıt’ın olup olmadığını belirlemek için alternatif anahtarı aramak zorundadır. Bununla birlikte, yabancı anahtar sütununda kullanılacak doğru surrogate key’i belirlemek için üst kaydın alternatif anahtarı aranmalıdır.
  • Üst kaydın henüz load edilmediği bir kayıt eklemeniz gereken durumla baş etmeniz gerekebilir.
  • self-referencing dimension tablosunda Tip 2 SCD’leri desteklemek karmaşık olabilir. En kötü senaryoda, yeni bir satırla sonuçlanan ve bu nedenle yeni bir yedek anahtara neden olan bir Tür 2 değişikliği gerçekleştirebilirsiniz. Değişiklik ebeveyn-çocuk ilişkilerini değiştirmediyse, varlığın tüm alt üyelerinin yeni satırlar oluşturmak için bu Tür 2 değişikliğini basamaklandırmanız gerekebilir.

6

Junk Dimensions

Bazı raporlama ve analitik gerekliliklerde, boyutsal modelde tanımlanan dimension’lardan herhangi birine ait olmayan fact’leri gruplamak veya filtrelemek için yararlı nitelikler vardır. Bu özniteliklerin önemlilikleri düşükse, yalnızca birkaç ayrık değer olduğunda, bunları çeşitli analitik değerler içeren tek bir boyut tablosuna gruplayabilirsiniz. Bu tür boyut tablosu genellikle “Junk Dimension” olarak adlandırılır ve çoklu, çok küçük dimension tablolarının oluşturulmasını önlemek için kullanılır.

Örneğin, bir satış sipariş dimension modeli, malların stokta kalmadığı veya ücretsiz gönderimin yapıldığı siparişler için “doğru veya yanlış” göstergeler içerebilir. Ödeme yöntemini belirtmek için “kredi” veya “borç” yazan bir sütun olabilir. Bu özniteliklerin her biri için bir dimension tablosu oluşturmak yerine, bunları Junk Dimension tablosunda olası tüm kombinasyonlarla birleştirebilirsiniz.

7

https://youtu.be/olv-TqLAyG4

Hakkında Hilal Saim

Namık Kemal Üniversitesi/Bilgisayar Mühendisliği

Beni Takip Et

Leave a reply

*