Veri Kalitesinin Sağlanması

Veri Kalitesinin Sağlanması

Veri kalitesi açısından bakılacak bu dört kategoriden çok daha fazlası var, ancak bu dördünün 80/20 kuralını karşıladığını buldum. Yani, veri kalitesini doğrulama çabasının yüzde 20’si için, veri kalitesi hatalarının en az yüzde 80’ini kapatabilirsiniz.

Bu dört kategorinin yakalanması nispeten minimum bir süre alır ve yine de meta verilerin en az yüzde 80’ini veri kalitesi sorunlarına göre saptayabilir. Hatta bir adım daha ileri giderek bu dört kategorinin, geliştirmeniz sırasında karşılaşacağınız veri kalitesi sorunlarına kadar meta verilerin %95’ini tespit edeceğini söyleyeceğim.

Veri Kalitesi Yakalama Şablonunun çeşitli avantajları vardır:

Verileri meta verilerle karşılaştırır. Bu aracın birincil amacı budur, yani bu noktaya kadar yaptığınız iyi işlerin aslında gerçekte eşleştiğinden emin olmaktır. Aşağıdakileri birçok kez gördüm: Sonunda bir veri öğesinin tanımı üzerinde tam bir anlaşmaya varıldı; ancak verilere gerçekten baktığımızda, değerler ve tanım arasındaki tutarsızlıkları kolayca tespit ederiz.

Bu şablon, bu tutarsızlıkları tespit etmek için tasarlanmıştır. Örneğin, bir Şirket Adı veri öğesinin adı ve tanımı üzerinde bir kez anlaşmıştık. Meta verileri bu veri öğesinin verileriyle karşılaştırdığımızda çok endişe verici bir şey fark ettik.

Değerlerin çoğu şirket adları değil de gerçekten e-posta adresleriymiş gibi görünüyordu. Bu, bu veri öğesi hakkında daha fazla soru sormamıza neden oldu. Çoğu durumda, veri girişi yapan kişinin bu veri öğesine şirket adı yerine şirketin e-posta adresini yazdığını öğrendik.

Bunun nedeni, kaynak uygulamada e-posta adreslerini yakalamanın bir yolu olmaması ve e-posta adresinin şirket adından daha önemli olarak belirlenmiş olmasıdır.

Veri kalitesi sorunları için erken uyarı sağlar. Veri Kalitesi Yakalama Şablonu, herhangi bir veri uygulamanıza fiilen getirilmeden önce tamamlanır. Henüz mantıksal veri modellemeye başlamadığımızı ve hala verileri görmekle ilgilendiğimizi unutmayın.

Herhangi bir gerçek veri getirilmeden önce tespit edildiğinde veri kalitesi sorunlarının çok daha küçük sorunlar olduğunu buldum. Henüz kod yazmadığımız veya herhangi bir tablo tasarlamadığımız için, bu noktadaki düzeltmelerin küçük bir etkisi var.

Ayrıca, veriler uygulamanıza fiilen getirilmeden önce veri kalitesi sorunlarını tespit etmenin, sorunu çözme sorumluluğunu ekibinizden çok kaynak uygulamaya yüklediğini de bulduk.

Örneğin, kaynak uygulamanızdaki öğe tanımlayıcıları, mevcut öğe referans verilerinizdeki öğe tanımlayıcısıyla doğru şekilde eşleşmezse, kaynak sistem uzmanları bu sorunu çözme sorumluluğunu hızla üstlenmelidir. Bazı durumlarda, düşük kaliteli veriler uygulamanıza girer girmez, verileri tespit etme ve düzeltme sorumluluğunun yalnızca kaynak uygulamanın sorumluluğu yerine sizin sorumluluğunuz haline geldiğini gördüm. Bu proaktif yaklaşımı benimsemek bu durumu önleyecektir.

Koleksiyonu doğrulamadan ayırır. Çoğu zaman veri kalitesi kontrolü yaparken, gerekli verileri ve meta verileri toplayıp ardından bu verileri doğrulamak için uzmanlarla birlikte çalışmaktan bunalmış halde buluyoruz. Bu araç yalnızca toplama noktasına odaklanır.

Tartışacağımız bir sonraki araç olan Veri Kalitesi Doğrulama Şablonu, alandaki bir uzman tarafından örnek verilerle meta verilerin senkronize olup olmadığı hakkında bir yargıya varmak için kullanılır.

Veri kalitesinin özellikleri
Veri kalitesini belirleyen özellikler
AHIMA veri kalitesini belirleyen özellikler
AHIMA veri kalitesi modeli
Ahıma veri kalitesi nedir
AHIMA Veri Kalitesi modeline göre
Veri kalitesi modeli nedir
Veri hikayesi anlatımının temel unsurları

Veri Kalitesi Yakalama Şablonunu Kullanma

Veri Kalitesi Yakalama Şablonu, verileri ve meta verileri bir iş uzmanı tarafından doğrulamayı kolaylaştıracak şekilde biçimlendirmek için kullanılır. Bu şablonu kendi ihtiyaçlarınıza göre uyarlayabilirsiniz. Örneğin, aşağıda listelemediğim bazı meta verileri veri kontrollerine eklemek isteyebilirsiniz. Yalnızca gördüğüm veri kalitesi sorunlarının çoğunu açıkladığını düşündüğüm kontrolleri listeledim.

Bu şablonun iki ana bölümü vardır: meta veriler ve veri sonuçları. Meta veriler, doğrudan bu bölümde daha önce bahsedilen Veri Öğesi Aile Ağacından gelir.

Aile Ağacındaki meta veri sütunları, doğrudan bu şablondaki uygun sütunlara kopyalanabilir. Sonuçlar sütunları, gerçek verilere erişim gerektirir. Veriler için, bize sağlanan tüm örnek veri setini incelemek ve basit sorgular çalıştırmak için 10 ila 25 satıra ihtiyacımız var. Bu araçta bu sütunların her birine daha yakından bakalım.

İsim

Ad sütunu, veri öğesinin adını içerir. Bu şablonda olması iki nedenden dolayı yararlıdır: Diğer araçlara bir işaretçi sağlar; ve tanımla bağlantılı olarak, örnek değerlerin doğrulanmasına yardımcı olabilir. Veri Öğesi Aile Ağacına veya Veri Öğesi Tahıl Matrisine geri dönmek istersem, veri öğesinin adını bilmek son derece önemli olacaktır.

İsteğe bağlı olarak, araçlar arasında tutarlı tuttuğum bir tür çapraz referans numarası ekleyebilirim. Örneğin, Brüt Satış Tutarı, Veri Kalitesi Yakalama Şablonunda, Veri Kalitesi Doğrulama Şablonunda ve Aile Ağacı ve Tane Matrisinde referans numarası 35 olabilir.

Ad ve tanım, gerçek verilerle karşılaştırmamızı yapmak için kullandığımız şeylerdir. Veri öğesinin adı Brüt Satış Tutarı ise ve örnek veriler müşteri adlarını gösteriyorsa, kolayca bir sorun belirledik. Tanım, gerçek verilere karşı doğrulamamız gereken birincil meta veri bilgi parçasıdır.

Biçim

Biçim, veri öğesinin uzunluğu ve türüdür. Biçim örnekleri aşağıdakileri içerir:

■■ Ondalık
■■ Tamsayı
■■ Karakter
■■ Tarih

Bu örneklerin her biri, bu veri öğesinde bulduğumuz gerçek değerlerle doğru şekilde eşleşmelidir. İşte aranacak bazı tuzaklar:

■■ Alanın çok küçük bir yüzdesinin kullanıldığı çok uzun karakterli veri öğeleri, örneğin yalnızca ilk 50 karakteri kullandığımız bir Varchar(2000) veri öğesi.
■■ Son derece uzun olan kod veri öğeleri, örneğin, Durum Kodunun Karakter(2) yerine Varchar(10) olması.
■■ Metin değerleri içeren Toplam Satış Miktarı gibi karakter değerlerine sahip, kulağa sayısal gelen bir ada sahip bir veri öğesi.
■■ Tarih dışında değerler içeren bir tarih veri öğesi.

Bu sütunda bu veri öğesinin boş, Y veya evet olarak tanımlanıp tanımlanmadığı, bu veri öğesinin boş olabileceğini gösterir. Yani boş olabilir. Bir N veya hayır, bu veri öğesinin her zaman doldurulması gerektiğini, yani boş olmadığını gösterir.

Bunu iki duruma bakmak amacıyla gerçek verilerle eşleştireceğiz:

■■ Boş olmaması gerektiğine inandığımız veri öğeleri, ancak boş değerler buluyoruz.
■■ Tamamen boş olan veri öğeleri, yani bu veri öğesinde hiçbir şey doldurulmaz. Bu veri öğeleri ya gelecekteki yer tutuculardır ya da büyük bir hatadır.

akademi222 takımı

Biyografinin Tamamını Gör