Data Quality CZ - portál věnující se tématu kvalitních dat

Role validace při řízení datové kvality

[20.5.2013] D. Pejčoch

Úvod

Tento článek vznikl na základě potřeby syntézy různých přístupů v oblasti validace do jediného materiálu sloužícího jako studijní podpora pro kurz 4IZ562 Řízení datové kvality. Shrnuje nejobvyklejší používané typy validací a jejich použití demonstruje na konkrétních příkladech.

Článků na téma příčin vzniku nekvalitních dat byla již publikována celá řada. Není proto až tak moc nutné na tomto místě znovu opakovat různé mechanismy vzniku chybných záznamů. Lze snad jen zmínit, že mnoho z těchto chyb vzniká díky absenci nebo slabinám vstupních validačních kontrol i tam, kde by bylo tyto kontroly možné úspěšně naimplementovat. Použití níže uvedených technik však není nutně omezeno pouze na vstupní kontroly a lze je aplikovat i pro ex-post monitoring datové kvality a kontinuální zlepšování kontrolních mechanismů, nicméně vzhledem k pochopitelnému trendu spíše proaktivního předcházení vzniku nekvalitních dat oproti zpětnému „záplatování“ již vzniklých defektů jejich role spočívá především ve zmíněných vstupních kontrolách.

Typické formy validace

Povolený rozsah hodnot

Nejjednodušší způsob validace numerických hodnot představuje povolený rozsah. Slouží k validaci sémantické správnosti. Validace může být realizována pouhým porovnáním hodnoty atributu s definovaným rozsahem, anebo může mít podobu komplikovanějších pravidel. Typickým příkladem může být např. validace věku klienta. Ten může být validován proti intervalu, jehož dolní mez představuje 0 let a horní mez je odvozena od aktuálních statistik o maximálním uvažovaném věku úmrtí , publikovaných např. formou úmrtnostních tabulek. Komplikovanější avšak praxi bližší je v tomto případě rozlišení rolí, v nichž se příslušný klient nachází. V případě pojišťovny můžeme rozlišovat role: pojištěný, pojistník (uzavírá pojistnou smlouvu a platí pojistné), oprávněná / obmyšlená osoba (je jí vyplaceno pojistné plnění v případě smrti pojištěné osoby na základě smlouvy o životním pojištění), držitel / vlastník vozidla, poškozený. Pro každou z těchto rolí je nutné uvažovat povolený rozsah věku separátně. V některých z uvedených případů je totiž nutné uvažovat jako dolní mez přípustného věku počátek způsobilosti k právním úkonům, případně nejnižší přípustnou věkovou hranici pro vydání řidičského oprávnění.

Lookup / join do referenční báze

V případě kategoriálních atributů, pro něž existuje nějaký referenční zdroj, optimálně kontinuálně spravovaný nezávislou autoritou, je možné provést validaci lookupem do tohoto zdroje. V souvislosti s lookupem se zpravidla hovoří o vyhledání jedné konkrétní hodnoty, zatímco join se zpravidla chápe ve smyslu doplnění více hodnot. Při realizaci lookupu / joinu lze použít jak přesný join (v případě existence unikátního klíče), anebo technik pro přibližné porovnání (s využitím měr podobnosti nebo generování porovnávacích kódů). V případě, že neexistuje pro zřetězení záznamů jediný atribut mající funkci klíče a kompozitní klíč je možné vytvořit v různých případech pomocí rozdílných atributů (typicky v případě validace adres proti územnímu registru UIR-ADR), je vhodně vytvořit několik pomocných atributů obsahujících vygenerované různé porovnávací kódy a aplikovat je postupně.

Ověření referenční integrity

Referenční integrita je chápána jako vztah mezi primárním a cizím klíčem. V této souvislosti je tedy nutné ověřit, zda pro všechny cizí klíče z jedné tabulky existuje primární klíč v referenční tabulce. Příkladem může být ověření, že ke všem kontraktům existuje osoba, která je na nich uvedena nebo že ke všem adresám existuje navázaná osoba / firma. Pro tyto účely je možné použít např. SQL dotaz. Řada nástrojů pro řízení datové kvality (např. DataFlux) také poskytuje funkcionalitu pro grafické znázornění průniku hodnot dvou tabulek. V souvislosti s referenční integritou je kontrolována vlastnost konzistentnost.

Validace syntaxe pomocí regulárních výrazů

Regulárních výrazů lze úspěšně použít pro validaci syntaktické správnosti. Mnoho nástrojů pro podporu řízení datové kvality (např. Talend Open Studio, Melissa Data) také tuto funkcionalitu poskytuje. Jako příklady zjednodušených validačních pravidel lze uvést:

Při validaci syntaxe lze použít dodatečné znalosti o struktuře podmíněné hodnotami ostatních atributů. Např. u kreditních karet lze podle typu karty uvažovat různou délku identifikačního čísla (Visa: 13, 16; Visa Electron: 16; Maestro: 12-19; MasterCard: 16; ...) a jeho počátek číselné řady (Visa: 4, MasterCard: 51-55, American Express: 15; ...). Kompletní přehled o logice přidělování číselných řad poskytuje ISO/IEC 7812-1:2006.

V případě rodného čísla lze využít pro kontrolu struktury dodatečné znalosti o pohlaví či data narození. U žen se k měsíci narození (3.-4. znak) připočítává číslice 50, případně 70. U mužů se k měsíci narození připočítává 0, případně 20. Validace pomocí kontrolních součtů

Mnoho jedinečných klíčů má v sobě uchovanou vnitřní kontrolu pomocí kontrolních součtů, kdy kontrolní číslice (typicky zbytek po celočíselném dělení) je součástí klíče. Jako příklady lze uvést algorirmy pro validaci rodného čísla, IČO, ABO (Automatizované bankovní operace) čísla či ISBN.

Při validaci rodného čísla se lze dopustit typického omylu, že doplnění o zbytek po dělení číslem 11 automaticky znamená dělitelnost celého rodného čísla číslem 11. K tomu pochopitelně neochází v případě, kdy zbytkem po celočísleném dělení je číslo 10 a řetězec je doplněn nulou. Tuto skutečnost si můžeme ukázat na příkladu. Uvažujme datum narození: 12.10.1977 a pořadí novorozence 21. Výsledné rodné číslo bez kontrolní číslice je 771012021. Modulo 11 je 10. Celé doplněné rodné číslo je 7710120210. Ale pozor: 7710120210 ÷ 11 = 700920019,1. Přidělování rodných čísel, která nejsou dělitelná 11, bylo roku 1985 podle interního předpisu FSÚ Č. Vk. 2898/1985 ukončeno. S toho důvodu se např. na webu MSSZ setkáme pouze s kontrolou na dělitelnost 11. Validovat lze tímto způsobem pouze rodná čísla vydaná po 31.12.1953 (do té doby se rodná čísla skládala pouze z 9 znaků).

Validaci IČO si ukážeme na příkladu Raiffeisenbank (IČO = 49240901). Algoritmus spočívá v postupném vážení 1. až 7. číslice sestupnou řadou 8 až 2. Kontrolní číslice se spočte jako modulo 10 z rozdílu 11 – modulo z váženého součtu řady. Součet řady je v tomto případě 4*8 + 9*7 +2*6 +4*5 + 0*4 + 9*3 + 0*2 = 154. Modulo 11 je 0. Modulo 10 z 11 – 0 je 1. Kontrolní součet odpovídá osmé číslici, IČO je tedy validní.

Syntaxe ABO čísla účtu je UUUUUK-MMMMMOK-PPB, kde U = čísla předčíslí, M = pozice základního čísla účtu, O = identifikátor druhu organizace, K = kontrolní pozice na modulo 11, P = číslo pobočky banky, B = číslo banky. ISBN-10 může mít např. tvar 80-7234-184-7. Jako první krok je pochopitelně nejprve nutné odstranit z řetězce mezery a pomlčky. Výpočet kontrolní číslice je realizován pomocí následujícího algoritmu 8*1 + 0*2 + 7*3 + 2*4 + 3*5 + 4*6 + 1*7 + 8*8 + 4*9 = 183, kdy jsou jednotlivá čísla vážena svým pořadím. Následně je proveden výpočet 183 mod 11 = 7. Zbytek po dělení 11 se shoduje s kontrolní číslicí, ISBN je tedy validní.

Existuje celá řada kódů, u nichž je realizována kontrola na nižší číslo než 11. Např. celá řada čísel platebních / kreditních karet je validována pomocí tzv. Luhnova algoritmu (modulo 10). Ten je založen na jednoduchém postupu: 1) vynásob dvěmi všechna čísla karty kromě posledního (je kontrolní číslice), 2) sečti čísla jednotlivých řádů v případě, že vyjdou víceciferné, 3) sečti takto získanou řadu, 4) vynásob výsledek devíti, 5) poslední číslice výsledku je kontrolní číslo. Kontroly na kratší modulo než 11 mají však své slabiny. Např. modulo 10 používané pro validaci čísla karty nedetekuje přehození 09/90, 22/55, 33/66 a 44/77. Kontrolu na modulo využívá např. také Universal Product Code (UPC), NPI (National Provider Identifier), IMEI (International Mobile Station Equipment Identity), kontrolu na modulo 9 identifikace poštovních zásilek v USA a identifikace bankovek EUR, modulo 7 čísla letenek nebo zásilek UPS a FedEx. Validace pomocí byznys pravidel

Pomocí byznys pravidel lze realizovat validaci konzistentnosti, nebo podmíněnou validaci syntaktické / sémantické správnosti na základě dodatečných znalostí o hodnotách ostatních atributů, často s využitím některého jiného mechanismu popsaného výše. Pravidla mohou být jak „ostrého“ charakteru, tak mohou obsahovat určitou míru volatility (fuzzifikace jednotlivých částí pravidel nebo míra senzitivity / priority v rámci soustavy pravidel). Příkladem byznys pravidla pro ověření konzistentnosti může být křížová validace rodného čísla, pohlaví a data narození. Při tomto typu validace se je nutné zvážit, jaký atribut považovat při nekonzistentnosti za referenční. Jako best practice je možné uvažovat atribut, který je v dané vertikále nejvíce používán a je tedy menší pravděpodobnost, že bude chybný. V případě pojišťovny bude nejspíš více než rodné číslo používán atribut datum narození, např. pro výpočet pojistného v životním pojištění nebo segmentaci povinného ručení.

Závěr

V rámci tohoto stručného článku byly nastíněny základní přístupy k validci dat. Nejedná se samozřejmě o vyčerpávající seznam všech možných validačních pravidel. Na každé dílčí téma by bylo možné napsat celou knihu. Zájemce o rozšíření tématu kontrolních součtů bych odkázal na publikaci (Kirtland, 2001). Kompilace metod přesného i přibližného porovnávání je zpracována např. v (Pejčoch, 2001). Oblasti disponibilních externích datových zdrojů pro účely validace kategoriálních atirubutů se budu věnovat v některém z dalších článků. Konkrétní použití dostupních validačních pravidel pomocí kontrolního součtu je k dispozici v rámci kanonických modelů vertikál vytvořených projektem TheHive a postupně doplňováno do znalostní báze pro kurz 4IZ562 dostupné pro registrované uživatele.

Doporučená literatura

Relevantní zdroje

Komentáře ke článku

Stránka byla naposledy aktualizována dne 4.5.2015
Powered by HOLOPAGE
©2011 - 2015 D. Pejčoch