Jak na databáze 7.NF ? : Update anomálie

Určitě potkávate lidi, kterých sebevědomí prevyšuje jejich znalosti. Já bohužel taky. Jeden takový člověk mně inspiroval k tomu, že jsem vymyslel 7. NF. Po insert a delete anomáliím je logické upozornit i na update anomálií a jak ji předcházet.

Ono k této anomálí když používate zdravý selský rozum nemůže dojít, ale … už došlo :). Logicky referenční integrita (cizí klíče) směrují od zdroje k cíly, od nadřízených k podřízeným, od rodičům k dětem, od obecného ke konkrétnímu, od pána k otroku (master-slave), od číselníku k master tabulce, od prvního k následníku, …

Co se ovšem stane, když to otočíte ? Rozeberme si situaci :

Máme tabulku zákazníků. Každý zákazník po registraci dostane aktivační email.  Tak se vytvořila tabulka aktivačních emailů. Aby se vědělo, který email dostal zákazník udělal se cizí klíč v tabulce zákazník na aktivační email. To ale umožňuje aby jeden email byl přirazený více lidem, ačkoliv každý má mít svůj vlastní. Takže není dodržena sémantika zadání.  Jak je tomu na obrázku.

Znalý člověk databází, řekne. Je to jednoduché, stačí když uděláme nad tabulkou zákazník jedinečný index nad sloupcem email_id a je to.  To ano. Je to možné. Ale každý databázista by z toho datového modelu četl, že nedjříve se odešle aktivační email a až pak se zaregistruje zákazník na základě tohoto emailu. Teda opak toho co bylo zadání.

Správný datový model je tento :

Zákazník je primarní zdroj dat. Na něj je přidělený aktivační email pomocí cizího klíče nad tabulkou aktivační email. Namísto vazby 1:n , je zde vazba 1:1. Pozorný čtenář, opět upozorní, že i v tomto případě, musí být zabespečena referenční integrita pomocí jedinečného indexu nad sloupcem zakaznik_id nad tabulkou aktivacni_email. Ano má pravdu, ale čtení tohoto modelu je lehčí.

Navíc u předchozího případu, kdy tabulka zákazník obsahuje email_id musíme tento sloupec nastavit na null. Nemáme zde mimo jiné zajištěno, že každý zákazník bude mít odeslaný aktivační email a že v systému nebudou existovat aktivační emaily bez toho aniž by jsme vědeli komu jsou určeny.

Update anomálie tomu říkám proto, že v případě že se aktualizuje tabulka zákazník, tak se může aktualizovat pro více zákazníku jeden email, nebo když se pokusíme přes tuto vazbu realizovat update, tak je možnost aktualizovat více záznamů v tabulce zákazník.

Rozdíl mezi správným a nesprávným datovým modelováním je ukryt v detailech. Na to bychom mněli pamatovat při tvorbě datového modelu.

A ještě dodatek. Dotyčný si chybu později uvědomil, a udělal to vazbu správně. Myslím si, že chybu udělal v prvotním přístupu k datovému modelu. Přistupoval k tomu objektově. Máme tyhle samostné objekty. Pak jakou vazbu mají tyto objekty na jiné objekty (hlava, nehlava)? Existuje i jiný přístup, který sestavuje model na základě funkčnosti. Máme tyto objekty. Tady data vstupují jako primární, pak pokračují tam …

Závěrem :

Udělal jsem přehled databázové normalizace tak, jak ji vidím já a i jak je posáná v literatúře. Snad to bylo k něčemu. V budoucnu by se chtěl pokračovat v popularizaci datového modelování. Věnuji se mu profesionálně už 20 let a někdy jsem se musel učit io na vlastních chybách, tak aby Jste se nemuseli na tom učit i vy. Tak příště … :)