Veri kalitesi yönetimi (DQM) yıllar içinde önemli ölçüde gelişmiştir. Sorunun tam boyutu ilk olarak 1980’lerdeki veri ambarı hareketi sırasında fark edildi. Bunun dışında, veri kalitesi gereksinimlerini ifade etmek ve ISO 8000 Bölüm 61: Veri kalitesi yönetimi: Süreç referans modeli gibi DQM modellerinin geliştirilmesi için boyutlu çerçeveler geliştirildi. Önceki makalelerde genel DQM sürecini tartışmış olsam da, bu makalede biraz daha ayrıntılara inmek istiyorum.
Çoğu kişiye, hatta veri insanlarına veri kalitesinin (DQ) anlamını soracak olursanız, tipik yanıt “doğru veriler istiyoruz!” Bununla birlikte, deneyimlerime göre, kuruluşlardaki açık ara en yaygın DQ sorunlarının eksiklik ve tutarsız temsil olduğunu görüyorum. Anahtar veri değerleri eksik olduğunda, müdahalesi kayıp değerleri elde etmenin veya belki de onları kaybetmemek için bir yol bulmak olan akut bir sorundur. Ancak tutarlı temsil sorunu, her gün tedavi edilmesi gereken kronik bir sorundur.
Genel olarak, tutarlı temsil basitçe, bir özelliğin değerleri aynı olduğunda aynı anlama geldiği ve bir özelliğin değerleri farklı olduğunda farklı anlamlara geldiği anlamına gelir. Başka bir deyişle, tutarlı temsil, bir kavramın (veri öğesinin) sözdiziminin (ifadesinin), kavramın anlambilimiyle (anlamı) uyum içinde (bire bir yazışma) olduğu anlamına gelir. Bu kuralın iki tarafı vardır. Bir yönü, aynı kavramın birden fazla değerle temsil edilmesine izin vermesidir. Diğer taraf ise aynı değerin birden fazla kavramı temsil etmesine izin vermektir.
Basit bir örnek olarak, 7 Mayıs 2023 takvim tarihini 5/7/23 (ABD öncesi Y2K sözleşmesi), 5/7/2023 (ABD Y2K sonrası sözleşmesi), 7/5/2023 (Avrupa sözleşmesi) olarak ifade etmek veya 2023-05-07 (ISO standardı). Bir diğeri, Arkansas eyaletimin “AR” (USPS kodu), “Ark” (geleneksel kısaltma), “Arkansaw” (alternatif yazım) ve “Arknsas” (yazım hatası) dahil olmak üzere çeşitli şekillerde nasıl temsil edilebileceği olabilir. Bu örnekler, iki farklı yanlış beyan türünü temsil eder: biçim ve değer. Tarihler söz konusu olduğunda, sorun farklı biçimlerde ifade edilen aynı değere sahip olmaktır. Durum adları söz konusu olduğunda, sorun aynı anlama sahip farklı ancak eşanlamlı dize değerlerine sahip olmaktır.
Tutarlı biçimlendirme, genellikle kuruluştaki tüm sistemlerde kullanılacak tek biçimli bir biçim öngören bir veri standardı aracılığıyla ele alınır. Öte yandan, eşanlamlı değer sorunu genellikle referans veri yönetimi (RDM) aracılığıyla ele alınır. RDM’de, bir eşanlamlılar koleksiyonundan belirli bir değer, USPS posta kodlarının ISO coğrafi kodlarının kullanımı gibi bir kuruluştaki sistemlerde her zaman kullanılacak değer olarak belirlenir. Belirlenen değerler listelerinin bakımını kolaylaştırmak için birçok satıcı RDM yazılım sistemleri geliştirmiştir. Bu standart biçimlerin ve değerlerin tutarlı bir şekilde kullanılmasını sağlamak için, veri kalitesi için veri yönetişimi (DG) standartları tarafından zorunlu kılınmalıdır.
Hem veri standartları hem de RDM sistemleri, öncelikle durum adları gibi tek değerli temsillerle ifade edilen kavramlarla ilgilenir. Yönetilmesi daha zor bir durum, tek bir kavramı ifade etmek için birden çok değerin gerekli olduğu durumdur. Burada tutarsız gösterim sorununun diğer tarafıyla yani aynı değerin farklı anlamlara gelmesiyle karşılaşıyoruz. Örneğin, bireysel bir müşteriyi temsil etme sorunu. Bir köşe mahalle mağazasıysanız, müşterilerinizi yalnızca adlarıyla tanımlayabilirsiniz.
Ancak büyük bir şirket için, birkaç farklı müşteri aynı ada sahip olabileceğinden bu yeterli olmayacaktır. Bunu çözmek için adres öğelerini ekleyebiliriz. Bu, farklı adreslere sahip olmaları durumunda aynı ada sahip müşterilerin ayırt edilmesine yardımcı olacaktır. Ancak, her bir müşteriyi tanımlamak için ek özellikler eklediğimizde, bu bizi diğer taraftaki tutarsız temsile geri götürür. Ad, soyad, sokak numarası, sokak adı, şehir adı vb. için yazımlar gibi korunması gereken pek çok farklı değer olduğu için aynı müşteri için aynı değerleri korumak giderek daha zor hale geliyor. Bunlardan herhangi biri üzerinde anlaşmaya varılan sabit bir değerden farklıysa, müşterinin temsili tutarsız hale gelir.
Bu durumlar için semantik kodlama tekniği kullanılır. Semantik kodlamada, tüm kavramı temsil etmek için üzerinde anlaşmaya varılan tek bir değer (tanımlayıcı) oluşturulur. Müşteri örneğinde, benzersiz, tek tanımlayıcı, her bir müşteriyi temsil etmek için oluşturulmuş bir müşteri numarasıdır. Müşteri numarası gibi bir kavram tanımlayıcısı ile müşteri adı ve adresi gibi kavramı tanımlayan veriler arasındaki bu katı uyumu sürdürmek için gereken yazılım, tek değerleri işleyen RDM sistemlerinden çok daha karmaşık ve karmaşıktır. Bu nedenle semantik kodlama tekniği genellikle sadece müşteriler, tedarikçiler ve ürünler gibi organizasyonun en kritik kavramlarına ayrılmıştır. Bu temel kavramları açıklayan verilere ana veri adı verildiğinden, bunlar için anlamsal kodlamayı koruyan yazılıma ana veri yönetimi (MDM) sistemi denir.
Temel olarak MDM, kuruluştaki tüm sistemlerde temel kavramların tutarlı temsilini sürdürmek için bir veri kalitesi sürecidir. Bununla birlikte, bir MDM sistemi, kavramların teknik açıdan tutarlı temsilini ne kadar iyi sürdürürse sürdürsün, kuruluşun bölümleri MDM sistemini kullanmazsa veya farklı bir MDM sistemi kullanmakta ısrar ederse, MDM amaçlanan amacına ulaşamaz. tutarlı temsili sürdürmek. Tıpkı veri standartları ve RDM’de olduğu gibi, MDM’nin başarılı olabilmesi için MDM standartlarının DG’ye dahil edilmesi gerekir. MDM için DG standartları, tipik olarak, her bir ana veri türü için yalnızca bir MDM sistemine sahip olmayı zorunlu kılar, kuruluşun tüm bölümlerinin bu sistemler tarafından sağlanan tanımlayıcıları kullanmasını ve MDM tanımlayıcılarının kaynak verilere olabildiğince erken eklenmesini gerektirir.
Ancak durup kendimize şu soruyu sormalıyız: “Kuruluşlar veri standartları, RDM ve MDM sistemleri aracılığıyla tutarlı temsili sürdürmek için neden bu kadar ileri gidiyor?” Bunun nedeni, yazılım geliştirmedeki mevcut en son teknolojidir. Uygulama sistemleri şu anda, girdi verilerinin bir dizi veri girdi gereksinimiyle tutarlı olacak şekilde önceden işlenmiş olduğu beklentisiyle tasarlanmaktadır. Mevcut yazılım geliştirme dillerimiz ve programlama yöntemlerimiz göz önüne alındığında, uygulama işleminde tutarsız verileri işlemek için uygulama yazılımı oluşturmak çok karmaşıktır. Bu nedenle, önce tutarsızlıkları analiz etmek ve düzeltmek, ardından tutarlı veriler üzerinde uygulama işlemeyi gerçekleştirmek için bir endişeler ayrımı vardır.
Ancak bu yaklaşım ne kadar yerleşik hale gelse de, bunun yakında değişeceğine inanıyorum. Üretilmekte olan yeni yapay zeka modellerinin, özellikle de ChatGPT ve BARD gibi büyük dil modlarının ilk etkilerinden biri, verilerdeki tutarsızlıkların ve diğer veri kalitesi sorunlarının üstesinden bizim yaptığımız gibi gelmek olacaktır. Siz ya da ben “James Doe, 123 Oak, Anytown, AR” ve “Jim Doe, 123 Oak St, Anytown, Ark” gibi kayıtları gördüğümüzde, tutarsızlıklara rağmen aynı müşteriyi tarif ettiklerini zaten anlıyoruz. Ancak faturalandırma gibi uygulama sistemlerimizin bunları aynı olarak tanıyabileceğini bildiğimiz için, bunları bir MDM sürecinden geçirerek müşteri numarasını ekleyerek faturalandırma işlevinin doğru şekilde çalışmasını sağlıyoruz.
Ancak yakında, yapay zeka destekli yeni yazılımın da aynı şeyi yapabileceğine inanıyorum. Ve bir müşteri numarası eklemek için otomatik olarak otomatikleştirilmiş bir MDM işlemi gerçekleştirmeyi kastetmiyorum. Demek istediğim, kayıtları doğrudan alacak ve verileri bir MDM veya diğer veri temizleme ön işlemleri olmadan “olduğu gibi” kullanacaktır. Ne de olsa yapay zekanın amacı, insan performansına eşit veya bu performansı aşan sistemler oluşturmak değil mi?
Veri ve veri işleme dünyasında çok yakında köklü bir değişimin olacağına inanıyorum ve bu harika olacak! Veri kalitesinin bir sonraki aşaması kapımızda, veri sorunlarına değil veri fırsatlarına odaklanacak bir aşama. Artık kaynak verileri analiz etmek ve ETL akışları oluşturmak zorunda kalmayacağız. Yakında, tüm formatlardaki verileri alabilen büyük ölçekli sistemler göreceğiz. Her biri özel olarak önceden işlenmiş veriler gerektiren faturalandırma, maaş bordrosu ve iş raporları gibi özel uygulamalar için önceden programlanmak yerine bu sistemler, Bay Spock’ın Star Trek Enterprise’da yaptığı gibi, sorularımızı yanıtlayacak ve komutlarımıza itaat edecek. Ve sadece “Bana son 60 gün için brüt ve net gelirimizin bir raporunu verin” gibi operasyonel şeyler değil, aynı zamanda “Önümüzdeki tatil sezonu için ürün envanterimizi nasıl optimize etmeliyiz?”
Belki de bu, GIGO’nun yeni bir yorumuna yol açacaktır. Çöp Gir, Çöp Dışarı yerine, Çöp Gir, İyi Çıkış olabilir. Geleceğe hazır mısın!
