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

Článek navazuje na Řízení změn záznamů v relační databázi.

Historie záznamů

Jakákoliv změna v reálném životě se děje v čase. A čas, jako významný faktor, musí být v databázi zohledněn. Určitý stav, určité hodnoty, platily do té doby, než došlo k jejich změně. Od data změny hodnot došlo i ke změně stavu. Situace se změnila. Je zcela jiná než před změnou. Na tyto změny musí reagovat i údaje v databázi. A to nejen při vkládání nových záznamů. Čas musí být zohledněn i při úpravě záznamů, ale zejména při čtení (výběru) záznamů. Pouze v závislosti na čase, pro který data získáváme, získáváme platné hodnoty. Tak, jak v uvedený okamžik platily.

K vysvětlení problematiky nejlépe poslouží schématické obrázky. Ty jsou rozděleny na sekce (A) a (B). Sekce (A) představují současná obvyklá řešení. Tak, jak jsme se je naučili používat a jak s nimi denně pracujeme. Netvrdím, že konkrétní implementace čtenářů nemůže být více sofistikovaná. Ale pro náš výklad a pochopení souvislostí a rozdílů to bude stačit.

Sekce (B) pak prezentují řešení, která implementuje Digital Data Cube Framework (dále jen DDCF). Jde o celý soubor logiky chování, který byl vyvinut za účelem řízení změn záznamů (historie dat) v čase. Dnes se budeme zabývat pouze databázovou částí, a to způsoby ukládání, modifikací a rekonstrukcí záznamů v proměnlivém čase.

Ukládání a změny záznamů

Obrázek 1. ukazuje ideální případ klasického založení záznamu v tabulce v čase (t_n) na časové ose (t). Ideální proto, že v tuto chvíli ignorujeme aspekty, popsané v kapitole „1.4. Kontrola integrity“. Je vidět, že oba způsoby pracují stejně a očekávaně. V tabulce byl v čase (t_n) založen nový záznam.

Obrázek 2. ukazuje provedení dotazu do databáze v čase (t_n+1) příkazem SELECT. Vidíme, že se obě řešení (A) i (B) opět chovají očekávaně. Návratová hodnota je v obou případech totožná. Dostáváme hodnotu („Value 1“).

Obrázek 3. je již mnohem zajímavější. V čase (t_n+1) jsme provedli změnu záznamu (UPDATE). Jak můžeme vidět, v tomto případě se již obě řešení rozcházejí. V případě řešení (A) došlo k okamžitému přepsání původní hodnoty na hodnotu novou („Value 2“). Tím jsme nenávratně ztratili původní hodnotu („Value 1“). Co se stalo v případě použití řešení (B), lépe pochopíme na Obrázku 4.

Provedeme dotaz (SELECT) v čase (t_n+2), kde (t_n+1) < (t_n+2). Vidíme, že v případě řešení (B) dostáváme novou aktuální hodnotu („Value 2“). Původní hodnota („Value 1“) je ovšem zachována! Řešení (A) o tu svou přišlo.

Obrázek 5. ukazuje další provedení změny záznamu (UPDATE) v čase (t_n+2). U řešení (A) došlo opět k okamžité změně z hodnoty („Value 2“) na novou hodnotu („Value 3“). Původní hodnota („Value 2“) byla opět nenávratně ztracena. Otázkou je, jaká byla původní hodnota?

Řešení (B) ponechává původní hodnotu („Value 2“) uchovánu. Nová hodnota („Value 3“) je platná až od data (t_n+2).

Opakovaný dotaz do databáze (SELECT) v čase (t_n+3) nám vrátí očekávané hodnoty. Řešení (A) stále vrací („Value 3“), řešení (B) vrací také („Value 3“).

Obrázek 7. ukazuje, že při použití standardního řešení (A) přicházíme o řadu možností. Nemůžeme řešit historii provedených změn ani případnou rekonstrukci hodnot záznamů do původní podoby. Nemůžeme vyhodnotit záznamy k určitému datumu. Žádné předchozí hodnoty neznáme. Vůbec netušíme, že nějaké předchozí hodnoty byly. Na základě čeho se rozhodujeme? To je velmi nebezpečné a z mého pohledu nepoužitelné. Návratové hodnoty neodpovídají realitě!

Použití řešení (B) naopak umožňuje tzv. „cestování v čase“. Můžeme se dotazovat do databáze na jakékoliv datum v minulosti. Vždy dostáváme aktuální hodnoty pro zvolené datum. Platné záznamy jsou vybírány z intervalu <(t_n), (t_n+1)). Tzn., že:

((t_n) <= zadané datum < (t_n+1)) = návratová hodnota

Na Obrázku 7. vidíme, že pro interval <(t_n), (t_n+1)) dostáváme hodnotu („Value 1“), pro interval<(t_n+1), (t_n+2)) hodnotu („Value 2“) a pro interval <(t_n+2), (t_n+3)) pak hodnotu („Value 3“). Vždy obdržíme platné hodnoty pro zadaný čas. Tak, jak v reálném světě skutečně existovaly.

V případě řešení (A) dostáváme vždy poslední pseudo hodnotu („Value 3“). Z tohoto pohledu nemají příkazy (SELECT) do databáze v proměnném čase žádný smysl.

Důležité je, že se dá pro každého uživatele nastavit, zda a jak hluboko do historie může jít. Ne každému uživateli budeme chtít takové informace z historie zpřístupnit.

Obrázek 8. ukazuje, že se změny nemusí provádět přesně v daný čas. Dnes, v čase (t_actual) zjistíme, že záznam (B_A) nebyl ještě opraven. Můžeme jej změnit zpětně, jak ukazuje (B_B). Nebo víme, že záznam (B_A) bude muset být změněn již za několik dnů. Můžeme si jej připravit a opravit s budoucím datem, jak ukazuje (B_C). Změny můžeme provádět pouze na záznamu v tzv. „schváleném stavu“. Platnost nové změny nemůže nastat dříve, než byla změna předchozí. Tzn., že:

(t_n) < (t_n+1)

Vyřazení a obnovení záznamů

Fyzicky lze odstranit pouze záznamy, na které se neodkazují jiné záznamy. To bývá v relační databázi zřídka. Je-li mazaný záznam referencován jiným záznamem, příkaz DELETE vyhodí výjimku. Smazání se neprovede. Jiná situace nastane, pokud nejsou zapnuty cizí klíče nebo zapnuty jsou a je nastaveno kaskádovité mazání. Výsledkem můžeme být překvapeni. Odstraněním nesprávných záznamů dojde k narušení integrity.

Obrázek 9. ukazuje situaci pro řešení (B), kdy byl záznam (B_A) v čase (t_n+2) vyřazen. Dotaz do databáze (SELECT) v časovém intervalu <(t_n+2), (t_actual)) nám pro (B_A) vždy vrátí „NULL“. Standardní nastavení vyřazené záznamy ignoruje. Systém se chová tak, jako by vyřazené záznamy již neexistovaly.

Někdy je ale potřebujeme vidět. Zobrazení můžeme explicitně zapnout pro všechny tabulky. Zapnutí zobrazení vyřazených záznamů vidíme u verze (B_B) v čase (t_n+2). V tomto případě dotaz (SELECT) v intervalu <(t_n+2), (t_n+3)) vrací i vyřazené záznamy. Ty se pouze zobrazují. Nelze je modifikovat. Lze je pouze obnovit. Po vypnutí zobrazování v čase (t_n+3) se dotazy (SELECT) chovají stejně, jak je popsáno v předchzím odstavci.

Vyřazené záznamy je možné opětovně obnovit. To je vidět u verze (B_C) v čase (t_n+3). Po obnovení nabývá záznam původních hodnot. Dotaz do databáze (SELECT) v intervalu <(t_n+3), (t_actual)) nám pro (B_C) již vrací plnohodnotný obnovený záznam se všemi jeho referencemi.

Samozřejmě, že existuje i možnost použití příkazu DELETE. Musí být možnost záznam fyzicky odstranit. Jde ale o nenávratnou změnu. Je to možné pouze za splnění určitých specifických podmínek. A takové oprávnění není přiděleno každému uživateli.

Rekonstrukce záznamu

Někdy nastává situace, kdy provedené změny záznamu nejsou korektní. Z různých důvodů. V takovém případě nám systém DDCF umožňuje tyto změny stornovat a vrátit se k předcházejícímu stavu.

Obrázek 10. ukazuje řešení (B), kdy změna záznamu na pozici (B_A) v čase (t_n+3) nebyla korektní. Ke změně nemělo vůbec dojít. To jsme odhalili dotazem (SELECT) v čase (t_actual). Musíme se vrátit k předchozímu stavu. Změnu, provedenou v čase (t_n+3) můžeme zrušit. Záznam nabude předchozí hodnoty z času (t_n+2), jak ukazuje pozice (B_B).

Stornovat lze všechny provedené změny na záznamu. Postupuje se vždy od nejmladší změny ke změně nejstarší (B_C). Tak se můžeme dostat až do výchozí pozice (B_D) a záznam zrekonstruovat na původní hodnoty. Rekonstrukce záznamu se nedotkne jiných referencovaných záznamů.

Kontrola integrity

Každé vložení záznamu (INSERT) a každá změna záznamu (UPDATE), případně (DELETE), prochází kontrolou integrity cizích klíčů. Kontroluje se stav záznamu, na který se cizí klíč vkládaného záznamu odkazuje. Tzn., že pokud je referencovaný záznam ve schvalovacím procesu, jeho vypovídající hodnota je téměř nulová. Změna stavu totiž může nebo nemusí projít. Pokud projde, nabude záznam nového stavu. Pokud neprojde, zůstane záznam v původním stavu. To v okamžiku vkládání nového záznamu ještě nevíme. Systémově můžeme nastavit, jaké stavy referencovaného záznamu jsou pro vložení a úpravy akceptovatelné a jaké nikoliv.

Obrázek 11. ukazuje řešení (B), kde existují záznamy (R₁ – R₉) v různých tabulkách. Každý záznam byl ve své tabulce vytvořen v jiném čase. Barvy označují provedené změny záznamu a dobu platnosti. Červená barva označuje vyřazený záznam. Čas (t_m) ukazuje, kdy byl záznam (R₉) vytvořen. (NR₁) a (NR₂) jsou nově vkládané záznamy do tabulky („Table BA“) v čase (t_n) a (t_n+1). Celé zpracování probíhá právě dnes, v čase (t_actual).

Předpokládejme, že oba nově vkládané záznamy (NR₁) a (NR₂) mají cizí klíče (FK₁ – FK₉), které se odkazují na záznamy (R₁ – R₉). Cizí klíče jsou povinné. Musí obsahovat Id referencovaného záznamu.

Vidíme, že záznam (R₆) je v čase (t_n) vyřazen. Pro záznam (NR₁) a jeho cizí klíč (FK₆) je v čase (t_n) nedostupný. Stejně jako záznam (R₉) pro cizí klíč (FK₉). (R₉) v čase (t_n) ještě v databázi neexistoval. Byl vytvořen až v čase (t_m). To odporuje podmínkám zmíněným výše.

Implementované kontrolní mechanismy takovou situaci rozpoznají a zakážou vložení nového záznamu (NR₁) v čase (t_n) pro zadané cizí klíče (FK₆) a (FK₉). To proto, že se odkazují na nekorektní záznamy (R₆) a (R₉). Protože se cizí klíč (FK₉) záznamu (NR₁) odkazuje na záznam (R₉), který v čase (t_n) neexistoval, nebude možné záznam (NR₁) v čase (t_n) nikdy uložit.

U druhého nově vkládaného záznamu (NR₂) v čase (t_n+1) problémy nebudou. Záznam je ukládán v jiném čase. Proto se korektně uloží.

Uvedený pokus o vložení záznamu (NR₁) odpovídá následující situaci. Představme si, že vkládaný záznam (NR₁) je nějaké zařízení. Jeho cizí klíč (FK₉) představuje odkaz na odpovědnou osobu (R₉) v tabulce zaměstnanců. Jinak řečeno. Snažíme se zaměstnanci (R₉) přiřadit zodpovědnost za zařízení (NR₁) v čase (t_n). V čase (t_n) zaměstnanec ve firmě ještě vůbec nepracoval! Logicky jde o nesmysl.

Zde je popsána pouze modelová situace pro základní vysvětlení problematiky. V reálné aplikaci situace se záznamem (NR₁) a cizím klíčem (FK₉) na záznam (R₉) nenastane. A to proto, že jsou uživateli nabídnuty pouze záznamy, které v čase (t_n) již existují. Jiná bude situace s cizím klíčem (FK₆) na záznam (R₆) – vyřazený záznam. Tato situace nastat může (zobrazení vyřazených záznamů). Kontrolní mechanismy tuto situaci ale spolehlivě zachytí a konflikt ošetří.

Obrázek 12. nám pro porovnání ukazuje předchozí situaci za použití standardního řešení (A). V tomto případě se kolize neřeší. Záznam (NR₁) bude v čase (t_n) normálně uložen. A to i přes to, že záznam (R₉) byl založen později, v čase (t_m). Čili jakákoliv integrita dat a časový sled byly bezostyšně ignorovány. A je-li výše uvedený příklad se zaměstnancem logický a pochopitelný, tak proč takové řešení používáme? Jakou vypovídající hodnotu taková data mají?

Závěr

Dnes jsem představil základní principy chování historie dat. Věřím, že názorný výklad za použití obrázků je pro čtenáře lépe pochopitelný. V příští úvaze se chci vrátit k tématu a představit další integrované prvky chování.