Hlavní navigace

Řízení změn záznamů v relační databázi

7. 12. 2016
Doba čtení: 7 minut

Sdílet

V dnešní úvaze bych rád podrobněji probral změnu záznamů (Update) v relační databázi (RDB), rekonstrukci nežádoucích změn a historii již provedených změn.

Poznámka na úvod: Pokud zmíním něco jako zásadní, vstupní, minimální požadavky a pod., je třeba toto chápat jako požadavky nebo postoje důležité z mého pohledu na věc. Což bylo také zmíněno v minulém článku. Požadavky stran čtenářů se mohou diametrálně lišit nebo být i v rozporu s požadavky mými, jak se také ukázalo. 

Výraz historie změn (jako teminus technicus) jsem zvolil možná ne příliš šťastně, nebo jsem jej nedokázal v první úvaze srozumitelně vysvětlit. To v jisté skupině diskutujících vyvolalo očekávané nezřízené veselí. Je to škoda, neboť řízení historie změn je nejdůležitější vlastností, která se dotýká vlastně všech aplikací a každého, kdo se na vývoji podílí. Jedná se o problematiku velmi zajímavou, složitou a rozsáhlou.

Měníme data

Představme si, že jsme majiteli DB, s níž denně pracují jednotky, desítky a možná více uživatelů. Ti ukládají a opravují (zpracovávají) data. Na datech je firma závislá. My, jako majitelé firmy, prakticky vůbec nemáme pod kontrolou, co se s údaji v DB děje. Můžeme se vůbec spoléhat na to, že se naše rozhodnutí opírají o relevantní údaje? Jestli ano nebo ne, to závisí právě na tom, jak pracujeme se změnami uložených dat (z pohledu dnešní úvahy). Správnost vkládaných nových záznamů teď pomineme.

Otázkou je, proč se data musí měnit (opravovat). Opravují se ze tří důvodů. Jde o změny vyžádané, úmyslné a vynucené. Vyžádané změny definuji jako opravy vložených dat (překlepy, hrubky, diakritika, nesprávné zařazení a pod.). Vznikají při vkládání nových záznamů a možným chybám se asi nikdy nevyhneme. Můžeme se snažit je pouze eliminovat. Úmyslné změny jsou změny provedené se záměrem škodit. Ty může snadno provést frustrovaný zaměstnanec z různých osobních důvodů. Provede-li to šikovně, pak na to nedojdeme buď vůbec, obtížně nebo až po dlouhé době. A může to mít docela fatální následky. A opravit to? Držím palce. Ne, že by to nešlo. A půjde to vždy? Za jaké námahy? Utopie? Realita. Vynucené změny jsou pak vynuceny vnějšími okolnostmi, na které nemáme vliv, ale reagovat na ně musíme. Uvedené možnosti, přinejmenším já, plně akceptuji.

Jsem přesvědčen, že řízení změn je dnes, na konci roku 2016, zcela nezbytnou vlastností moderních IS. Podívejme se tedy na reálný příklad, spadající do kategorie změn vynucených vnějšími vlivy. Takových příkladů lze vyjmenovat desítky u každého z vás.

Reálný příklad

Ordinace dětského lékaře je typickým příkladem. Nevěřili byste, jak často dochází u dětí ke změně rodného čísla i příjmení. Případně obou údajů naráz. Proč tomu tak je, není předmětem úvahy. Ze současného pohledu na vývoj mám vlastně dvě možnosti, jak provést opravu. Jako nejvhodnější je přepsat původní hodnoty hodnotou novou. Druhým způsobem je vytvořit úplně nový záznam s novými údaji. Otázkou je, jsou-li oba způsoby přijatelné. Podívejme se na použití prvního způsobu.

Nahradit staré údaje údaji novými je velmi přímočaré a jednoduché. Zůstaly všechny údaje související jako provedené preventivní prohlídky, očkování, medikace a pod. To je v pořádku do chvíle, než jsem nucen provádět nějaké výkazy na požádání různých orgánů zpětně. Třeba zdravotní pojišťovny dělají kontroly až tři roky dozadu. Pak vám dojde zpráva, že máte např. neoprávněně vykázaný výkon u pacienta s daným rodným číslem, který jste provedli před 30 měsíci.

Váš systém ale pacienta se starým rodným číslem už nezná. Že jste jej před 14 měsíci přepsali, si už nepamatujete. Začnete hledat podle příjmení a situace se opakuje. Záznam nebyl nalezen. Původní hodnoty neznám. Rodné číslo je nesmírně důležité. Např. cizinci žijící na území ČR mohou čerpat pouze omezenou hrazenou péči. Pokud rodné číslo následně změníte z cizineckého RČ na řádné RČ, pak jste překvapeni, proč nemá pacient za uplynulé období vykázány standardní a povinné výkony (preventivky, očkování a pod., které se u cizinců nevykazovaly). Neříkám, že se nedoberete výsledku. Ale za jaké námahy? Proč? To přece nedává smysl.

Použití druhého způsobu, vytvoření nového záznamu, pak také není ideální. Jeden pacient má dvě různá ID a zároveň ztrácíte odkazy na provedené výkony, zmíněné výše. A jak najdete původního pacienta s jiným ID z předchozího příkladu? A od kdy bude taková změna platit? Od změny těchto údajů? Dobrá, dejme tomu. Ale zase uplyne nějaká doba a vy zjistíte, že máte pacienta, který nemá vykázáno očkování, preventivní prohlídky, důležitá vyšetření a pod. A u jakého lékaře byl těch prvních 9 let registrován? Dáte datum změny od data narození? Dobrá, ty související údaje tam stejně nemáte. Ale za celé období (od data narození pacienta) budete mít ve stavu o jednoho člověka navíc. Jak budete vykazovat statistiky, spotřeby očkovacích látek a pod., když vám nesouhlasí počet evidovaných lidí s počtem spotřebovaných vakcín za dané období? Asi nic jednoduchého.

A pomíjím zde další možnost, tj. vykázání výkonu zpětně. Po několik měsíců. Ten mohu pojišťovně vykázat na původní RČ, původní příjmení a původní datum provedení. Z různých důvodů. Jak to mám udělat, když jsem před měsícem údaje přepsal? Pak je přepsání původních hodnot záznamu nepřípustné!

Konkrétní řešení

Jde o reálnou situaci? V mém světě jsou takové situace nedílnou součástí každodenního řešení. A vyžadují i řízenou změnu hodnot záznamů. Možná existuje řešení, které neznám, a pak se omlouvám. Naše řešení vychází z předpokladu, že celý systém pracuje s dnešním (aktuálním) datem. K tomuto datu vrací aktuální záznamy. Pak šlo pouze o to, jak systém přesvědčit, že jakýkoliv dodaný datum je právě tím datem aktuálním. A to se nám povedlo. Systém důvěřuje uživateli a jakékoliv zadané datum akceptuje jako datum aktuální. Zadáte-li včerejší datum, dostanete výsledky tak, jak se zobrazovaly včera. Dnešní hodnoty systém nezná, ignoruje je. To je pouze partiální řešení.

Druhou částí bylo implementovat schvalovací a odmítací procesy nad prováděnými změnami záznamů. Čili mít plnou kontrolu nad tím, co se v DB děje. Získat plnou historii jednotlivých změn. Jaká byla původní hodnota, jaká je nová hodnota, kdo a kdy ji udělal, kdo a kdy ji schválil. Rozdělit zodpovědnost za vykonanou práci. Tak dostáváme jednoduché a rychlé řešení případné rekonstrukce. Tedy uvedení záznamu do původního stavu. Tak jsme eliminovali i úmyslné změny.

Dále jsme požadovali, aby tato schopnost nebo vlastnost, chcete-li, byla aplikovatelná na všechny tabulky v RDB. V rámci celé aplikace. Nechtěli jsme se zabývat pouze dílčím řešením nad jednou tabulkou, ale řešení zobecnit. Pak to celé zpracovat tak, aby to programátor mohl používat přímo a nemusel to stále a stále složitě vymýšlet a nestandardně implementovat. A požadovali jsme, aby se tyto hodnoty jednoduše zobrazovaly ve formuláři. Aby byly uživatelsky přívětivé. Uživatel nebude prohlížet žádné logy a logovací či změnové tabulky, volat specialistu a pod. Uživatel chce vidět data tak, jak je na ně zvyklý. Ihned.

Naším systémem (řešením) jsme dosáhli toho, že se nám výrazným způsobem zjednodušil vývoj. Z kódu se nám podařilo vytěsnit vše, co se odkazovalo na konkrétní RDB. Dosáhli jsme snadné změny jedné RDB za jinou, aniž bychom byli nuceni zasahovat do odladěného kódu. Zpracováním schvalovacích procesů a historií změn jsme sjednotili přístup a zjednodušili implementaci stran programátora. Kód se stal čitelnější, určitým způsobem standardizovaný. To vedlo k podstatné eliminaci chyb v důsledku individuálního řešení toho kterého programátora. Stran analýzy odpadlo složité vymýšlení uvedených činností. Došlo vlastně k podstatnému zvýšení produktivity a významné časové úspoře. Prakticky se podařilo zavést určitou formu pásové výroby. Výhodou pak je, že se uvolnil prostor pro kvalitní analýzu, časově očištěnou od řešení uvedené problematiky.

Postačující řešení

To vše, samozřejmě, není samospasitelné. I když uvedená oblast zasahuje prakticky do všech obdobných projektů (z mého pohledu), neznamená to, že bychom se dále nepotýkali s řešením jiných dílčích problémů. Na ně nám zůstává o to více času. Účelem bylo zjednodušit opakující se procesy a umožnit jejich standardní implementaci standardním způsobem do všech projektů. To, samozřejmě, zvyšuje užitnou hodnotu dodaného díla. Na to, že šlo o vývoj proprietárního šišatého kola, spíchnutého za páteční odpoledne, to není vůbec špatné.

root_podpora

Je-li naše řešení dobré, špatné, lepší než jiné, to nevím. Vím jen, že řešení, která se před lety nabízela, byla, z mého pohledu, nepoužitelná. Vím jen, že dnes už bez těchto nástrojů nedokážu pracovat. Proto by mne zajímalo, jak se s obdobnými problémy vypořádávají kolegové z oboru jinde. Jestli se takovou problematikou zabývají a jakých výsledků dosáhli.

Příště bych rád představil další možnosti systému DDCF při nasazení ve vícejazyčném prostředí. Společná databáze, společná data, různí uživatelé, hovořící různými jazyky.

Byl pro vás článek přínosný?

Autor článku

Autor se zabývá vývojem software a databázových aplikací více než 25 let. Pracuje s technologiemi Microsoft (C#, .Net Framework, MS SQL).