Veri Ambarına Kaynak Sistemlerden Veri Aktarımlarında Karşılaşılan Temel Veri Kalitesi Problemleri
Kaynak sistem tablolarındaki update, delete veya insert işlemlerinde bir uyarıcı eklenmediyse hatalı kayıtlar oluşmaktadır. Kurumlarda veri kalitesi odaklı yaklaşımlar olmadığında, süreç içerisinde hatalı kayıtların akmaya devam etmesi sonucunda önü alınamaz bir durum oluşmaktadır.
Burada yaşanılan temel veri kalitesi problemlerine ve çözümlerine değineceğiz.
1.Primary Key Kontrolü Olmaması
Kaynak sistem tablolarına kayıt atılırken tekillik kontrolü yapılmaması sonucunda bir veri birden fazla gelebilmektedir. Aşağıda görsel 1.1 de oluşturulan [Egitim].[dbo].[Person] tablosuna baktığımızda, PersonId bazlı tekil gözükmekte.
görsel 1.2 ye baktığımızda tablo PersonId bazlı tekil olarak gözükse de PersonId = 2 ve PersonId = 3 olan kayıtlar iş mantığı olarak aynıdır. Tablo tekilliğini sağlayan PersonId üzerinden bir tekillik kontrolü yapmak doğru bir yöntem olmayacaktır. Sadece PersonId üzerinden bir tekillik kontrolü yapıldığında tablo büyüdükçe çoklayan kayıtlar fark edilmeyecektir. Veri ambarı aktarımında tablo id’si üzerinden yapılan kontroller hatanın bulunmasına engel olacak ve veri ambarı tablosu üzerinden yapılan modeller ve raporlar hatalı olacaktır.
Bu durumda çözümümüz ne olmalı sorusu önemli olmaktadır. Öncelikle veri ambarı aktarımı olmadan ilgili tablonun yapısı anlaşılmalı ve tablo tekil id’si (PersonId) üzerinden değil, iş kuralına göre diğer kolonlardan tekillik kontrolü yapılmalıdır. Örneğin; görsel 1.2 üzerinden bakarsak , iş kuralına göre Tckn üzerinden tekillik olmalı. Veri ambarı aktarımından önce tabloda çoklayan kayıtlar sorumlu ekiple görüşülerek düzelttirilmelidir. İlgili tablonun veri ambarındaki karşılığında ise primary key olarak Tckn kolonu atanmalıdır. Bunun sonucunda kaynak sistem veri aktarımlarında oluşabilecek çoklamanın da önüne geçilmiş olacaktır. Ayrıca kaynak sistemde hatalı verilerin manuel olarak değil kalıcı bir çözüm noktasında ilgili geliştirmelerin yapılması gerekmektedir, veri ambarı analistinin bu tablolarla alakalı geliştirmeleri takip etmesi ve aktarımlarda kesinti olmamasını sağlaması gerekmektedir.
2.Parametresi Eksik Olan Kolonlar
Veri ambarına tablo aktarımları yapılırken, ilgili tablolarda yer alan kolonların parametreleri üzerinden, parametre tanım tablosu da oluşturulmaktadır. Örneğin; görsel 1.2 de yer alan CityId kolonun tanımı/parametresi bulunmalıdır. Parametre tablosu görsel 2.1 deki gibi [Egitim].[dbo].[City] olsun. Burada görüleceği üzere CityId = 6 için, [Egitim].[dbo].[City] parametre tablosunda tanımlama bulunmamaktadır.
İş birimlerinin veri ambarından istedikleri raporlarda, şube adı kolonu talep edildiğinde, parametre tablosunda CityId = 6 tanımlı olmadığından görsel 2.2 deki gibi NULL gelecektir.
Bu noktada çözüm ne olmalı ona değinelim. İlk çözüm ilgili parametre sahibi ekiple görüşülüp parametrede eksik olan CityId = 6 için tanımlama yaptırılmalı. Örnek görsel 2.3
Bu durumda aynı rapor sorgusunu tekrar çalıştırdığımızda sorun çözülecektir. Görsel 2.4’de de görüleceği üzere istenilen sorguda CityId = 6 için CityName = ’Ankara’ gelecektir.
Önceki durumda Ankara’da kaç müşteri/kişi var sorusunun cevabı alınamazken parametre tanımlandığı için bu yeni durumda, bu durum sağlıklı bir şekilde raporlanabilecektir.
Diğer çözüm ise, parametre tanımı eskik veya hatalı olan alanların veri ambarı aktarımlarını id üzerinden yaparak tanım tablosu tanımlamadan ilerlemektir. Yukarıdaki örnek sorguda parametre tablosu olmadığı için, raporlamada CityId = 6 için kaç kişi vardır üzerinden ilerlenmelidir. Bu durumda raporlamada bir eksiklik olmayacaktır.
3.Data Tekilleştirmede Doğru Row_Number Kullanımı
Görsel 3.1’deki gibi, bir fatura ödeme tablosu olsun ve iş birimi bizden her müşterinin son ödediği faturanın bilgisini istemiş olsun. Görselde görüleceği üzere son ödeme tarihinde birden fazla ödeme yapan 222 ve 223 nolu müşterileri görüyoruz. TranDate kolonunda time tutulmadığı için hangi datayı getirmeliyiz sorusuna net cevap verememekteyiz.
Normal şartlarda yapılması gereken görsel 3.2 deki gibi müşteri bazlı “Partition By” yapılıp, TranDate göre sıralanarak RowId atamaktır. Ancak tekrar çalıştırılması , örnek görsel 3.3 , durumunda TranDate aynı olduğu için, farklı bir RowId ataması olabilir. Ayrıca iş kuralı olarak da bir netlik olmadığı için raporlarda tutarsızlık olacaktır.
Şimdi sorunun çözümüne değinelim. Öncelikle hem talep sahibi hem de tablo sahibi ile görüşülmeli. Son kaydı getirmek için tablo yapısı öğrenilerek Row_Number yapısı değiştirilmelidir. Rapor sorgusu her çalıştığında aynı sonucu döndürecek şekilde Row_Number oluşturulmalıdır.
Örnek olarak görsel 3.4 e bakarsak ; tablo sahibi ekip ile görüşülerek teyit edildikten sonra, (son işlem için ıd’si büyük olan kayıt üzerinden ilerlemek doğru bir yöntem mi teyit edilmeli) TranDate yerine PaymentId kolonu “Order By” da kullanılmalıdır. Aynı ödeme tarihli iki kayıttan paymentId’si büyük olan kayda RowId = 1 atanmış ve son kaydı çekmek için RowId = 1 filtresi ile son kayıt getirilmiştir. PaymentId kolonu tekil olduğu için bu yöntem ile son kaydı bulmak raporların tutarlılığı için daha sağlıklı olacaktır.
Bu örnekte dikkat edilmesi gereken nokta “row_number” uygulanacak alanları belirlemeden önce, tabloyu bilmek ve tablo sahibi ile görüşerek alanları ve kuralları teyit etmektir. Bu kurallar rapor analiz dokümanlarına örnekleriyle detaylı eklenmeli ve kapsam net olmalıdır.
Bu yazıda temel olarak veri ambarı tablo aktarımları/geliştirmelerinde karşılaşılan 3 temel probleme ve çözüm yöntemlerine değindik. Bu 3 temel problemin çözümünde de ortak nokta tablonun anlaşılması , hatalı alanların bulunması ve düzeltilmesidir. Tabloya ve iş bilgisine hakim olmak hatalı veri aktarımının önüne geçtiği gibi tutarsız raporlamaların da önüne geçmektedir. Bu temel hatalara dikkat etmeden yapılan veri ambarı tasarımları raporlara olan güveni sarstığı gibi başarısız projelere de sebep olmaktadır.
