Depodaki verilerin kalitesi, değerli bilgilerin elde edilmesi için önemli bir ön koşuldur. Düşük kalite, uzun vadede olumsuz bir zincirleme reaksiyona yol açar.
Öncelikle sağlanan bilgiye olan güven kaybolur. İnsanlar İş Zekası uygulamalarını daha az kullanmaya başlıyor; uygulamaların potansiyeli henüz keşfedilmemiş durumda.
Sonuç olarak, analitik projeye daha fazla yatırım yapılması sorgulanıyor.
Veri kalitesi sorumluluğu
BI projelerinde veri kalitesinin iyileştirilmesiyle ilgili husus çok önemlidir. Ancak bu sadece teknik uzmanların ayrıcalığı değildir.
Veri kalitesi ayrıca aşağıdaki gibi yönlerden de etkilenir:
Şirket kültürü
- İşçilerin kendisi kaliteli üretimle ilgileniyor mu?
- Değilse neden olmasın? Bir çıkar çatışması olabilir.
- Belki kaliteden kimin sorumlu olduğunu belirleyen kurumsal kurallar vardır?
süreçler
- Bu zincirlerin sonunda hangi veriler oluşuyor?
- Belki de işletim sistemleri, gerçekte şu veya bu durumu yansıtmak için "bükülmeniz" gerekecek şekilde yapılandırılmıştır.
- İşletim sistemleri veri doğrulama ve mutabakat işlemlerini kendileri mi gerçekleştiriyor?
Raporlama sistemlerindeki verilerin kalitesinden kuruluştaki herkes sorumludur.
Tanımı ve anlamı
Kalite, müşteri beklentilerinin kanıtlanmış memnuniyetidir.
Ancak veri kalitesinin bir tanımı yoktur. Her zaman kullanım bağlamını yansıtır. Veri ambarı ve BI sistemi, verilerin geldiği işletim sisteminden farklı amaçlara hizmet eder.
Örneğin bir işletim sisteminde müşteri özelliği isteğe bağlı bir alan olabilir. Depoda bu özellik boyut olarak kullanılabilir ve doldurulması gerekir. Bu da varsayılan değerleri doldurma ihtiyacını ortaya çıkarır.
Veri depolama gereksinimleri sürekli değişmektedir ve genellikle işletim sistemlerine göre daha yüksektir. Ancak işletim sistemindeki ayrıntılı bilgilerin depolama alanında saklanmasına gerek olmadığında bunun tersi de olabilir.
Veri kalitesini ölçülebilir kılmak için standartlarının tanımlanması gerekir. Açıklama sürecine bilgi ve rakamları kullanan kişilerin dahil olması gerekir. Bu katılımın sonucu, tabloya bir bakışta bir hata olup olmadığının anlaşılabileceği bir kural olabilir. Bu kuralın daha sonraki doğrulama için bir komut dosyası/kod olarak biçimlendirilmesi gerekir.
Veri kalitesini iyileştirme
Verilerin depoya yüklenmesi sürecinde tüm varsayımsal hataların temizlenmesi ve düzeltilmesi imkansızdır. İyi veri kalitesine ancak tüm katılımcılar arasındaki yakın işbirliği yoluyla ulaşılabilir. İşletim sistemlerine veri giren kişilerin hangi eylemlerin hataya yol açtığını öğrenmeleri gerekir.
Veri kalitesi bir süreçtir. Ne yazık ki çoğu kuruluşun sürekli iyileştirme stratejisi yoktur. Birçoğu kendilerini yalnızca veri depolamakla sınırlandırıyor ve analitik sistemlerin tam potansiyelini kullanmıyor. Genellikle veri ambarları geliştirilirken bütçenin %70-80'i veri entegrasyonunun uygulanmasına harcanır. İzleme ve iyileştirme süreci eksik kalıyor.
Araçlar
Yazılım araçlarının kullanılması, veri kalitesinin iyileştirilmesi ve izlenmesinin otomatikleştirilmesi sürecine yardımcı olabilir. Örneğin, depolama yapılarının teknik doğrulamasını tamamen otomatik hale getirebilirler: alan formatı, varsayılan değerlerin varlığı, tablo alan adlarıyla uyumluluk.
İçeriği kontrol etmek daha zor olabilir. Depolama gereksinimleri değiştikçe verilerin yorumlanması da değişebilir. Aracın kendisi destek gerektiren büyük bir projeye dönüşebilir.
konsey
Mağazaların tipik olarak tasarlandığı ilişkisel veritabanları, görünüm oluşturma konusunda dikkate değer bir yeteneğe sahiptir. İçeriğin ayrıntılarını biliyorsanız verileri hızlı bir şekilde kontrol etmek için kullanılabilirler. Verilerde bir hata veya sorun bulunması durumunda her durum veritabanı sorgusu şeklinde kaydedilebilir.
Bu sayede içeriğe ilişkin bir bilgi tabanı oluşturulacaktır. Elbette bu tür isteklerin hızlı olması gerekiyor. Görünümlerin bakımı genellikle tablo tabanlı araçlara göre daha az insan zamanı gerektirir. Görünüm her zaman testin sonucunu göstermeye hazırdır.
Önemli raporlar söz konusu olduğunda görünüm, alıcının bulunduğu bir sütun içerebilir. Depodaki veri kalitesinin durumunu raporlamak için aynı BI araçlarını kullanmak mantıklıdır.
Örnek
Sorgu Oracle veritabanı için yazılmıştır. Bu örnekte testler istenildiği gibi yorumlanabilecek sayısal bir değer döndürmektedir. T_MIN ve T_MAX değerleri alarm seviyesini ayarlamak için kullanılabilir. RAPOR alanı bir zamanlar e-postaların nasıl düzgün bir şekilde gönderileceğini bilmeyen ticari bir ETL ürününde mesaj olarak kullanılıyordu, bu nedenle rpad bir "koltuk değneğidir".
Büyük bir tablo durumunda, örneğin AND ROWNUM <= 10 ekleyebilirsiniz; 10 hata varsa bu alarma neden olmak için yeterlidir.
CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
THEN 'OK' ELSE 'ERROR' END AS RESULT,
DESCRIPTION,
TABLE_NAME,
OUTPUT,
T_MIN,
T_MAX,
rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Count of blanks' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- not default value
AND ATTRIBUTE IS NULL ); -- count blanks
Yayın kitaptaki materyalleri kullanıyor
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg kablosu
Kaynak: habr.com