Umíme to s Delphi: 98. díl – konzistence databáze, integrita dat a transakce

Při práci s kteroukoliv databází dbáme na to, aby data v databázi vyjadřovala nějakou možnou, reálnou informaci o vnějším světě. Pokud databáze obsahuje nesmyslná data (například záporný věk zaměstnance), je nám k ničemu. Tento požadavek a jeho zajištění souvisí se třemi základními pojmy – konzistencí, integritou a transakcemi. V článku se dočtete vše, co o těchto pojmech dosud nevíte.
Předchozí část tohoto seriálu se zabývala problematikou znakových sad v databázích Interbase. Dnešní článek bude zaměřen na další zajímavé databázové téma – na tzv. integritu dat a konzistence databáze a na její zajištění prostřednictvím tzv. transakcí a transakčního zpracování. Nejprve si řekneme, co to integrita dat vlastně je a jak souvisí s transakcemi. V dalších článcích si ukážeme, jak využívat transakce při práci s platformou Interbase.

Konzistence databáze

Pracujeme-li s daty v jakékoliv databázi, máme jeden základní požadavek: data v databázi musí v kterýkoliv okamžik vyjadřovat nějakou (možnou) informaci o reálném světě. V žádném časovém okamžiku by se nemělo stát, že při data při přístupu do databáze jsou nekonzistentní, tj. vyjadřují nějakou nesmyslnou informaci, informaci, která nemůže v reálném světě nikdy nastat. Nekonzistentním stavem myslíme například záporný věk apod.

A jak souvisí pojem „konzistence databáze“ s pojmem „integrita dat“? Souvislost je velmi úzká: platí totiž, že podmínky, které musí databáze splňovat, aby byla v konzistentním stavu, se nazývají integritní omezení. Integritním omezením tedy může být požadavek „plat nesmí být záporný“, „rodné číslo musí mít devět nebo deset cifer a musí být dělitelné *****“, ale třeba také „plat zaměstnance oddělení X nesmí být vyšší než plat vedoucího tohoto oddělení“, „nesmí existovat knihovní výpůjčka vedená na neexistujícího čtenáře“, „všechny předměty vyučované učitelem A musí být vyučovány jen ve středu nebo v pátek“ apod. Integritní omezení stanovuje „tvůrce dat“, tedy nikoliv programátor (nebo dokonce tvůrce databázového systému): jediným člověkem, který o nich může erudovaně rozhodnout, je zodpovědný pracovník dotčené organizace (tj. zákazník nebo zadavatel projektu).

Konzistenci databáze lze zajišťovat řadou prostředků. Než si však tyto prostředky přiblížíme, uvedeme si několik základních příčin, které typicky způsobují nekonzistenci, tedy nepěkný stav, v němž databáze obsahuje nesmyslná nebo nesprávná data:

  • Jedním z možných příčin nekonzistence je selhání technického zařízení. Typickým příkladem může být havárie (nebo jiná závada) pevného disku apod. V dnešní době je patrná snaha zajistit odstranění této příčiny již na systémové úrovni (například častým a efektivním zálohováním, použitím diskových polí RAID apod.).
  • Selháním operačního systému. Typickým případem je pád systému, který může nastat v nevhodném okamžiku a způsobit tak nekonzistenci – případně který následně způsobí předchozí bod (selhání technického zařízení). Řešením tohoto problému je instalace takového systému, který slibuje vyšší spolehlivost. Trend výrobců operačních systémů v poslední době lze hezky vyjádřit známým výrokem „raději bezpečnost než funkci“ a nové verze systémů bývají obvykle stabilnější než ty předchozí.
  • Další příčina nekonzistence spočívá v chybě aplikačního programu. Pokud si databázový systém nedokáže konzistenci nejen ohlídat, ale také „vynutit“, může nesprávně napsaná aplikace snadno data úplně rozházet. Aplikací přitom můžeme mít na mysli nejen klienty napsané např. v Delphi (a spolupracující s databází pomocí speciálních komponent nebo rozhraní, např. ODBC), ale i webovou stránku připojující se k databázi třeba prostředky PHP. Pojmeme-li pojem „aplikace“ v nejobecnějším slova smyslu, může jí být i nebezpečný nebo nesprávný SQL skript spuštěný s příslušnými právy v klientské konzoli databázového systému.
  • Poslední dvě možné příčiny uvedeme v jednom bodu, neboť úzce souvisejí s dobře známými „chybami mezi klávesnicí a židlí“ – jedná se o chybnou obsluhu a chybná data. Je jen málo systémů (prakticky žádné), které mohou zajistit stoprocentní odolnost vůči zvůli nebo neodbornosti uživatele, v případě administrátorů pak žádná obrana ani nepřichází v úvahu. Ostatně výzkumy týkající se bezpečnostních selhání (mezi něž nekonzistenci dat můžeme zařadit) ukazují, že jednou z hlavních a nejčastějších příčin bezpečnostních chyb jsou právě neodborní nebo nespokojení uživatelé, zejména pak administrátoři.

Tím jsme velmi podrobně rozebrali možné příčiny nekonzistence dat. Jak jsme již naznačili, k zajištění konzistence (a k zabránění nekonzistence) existuje mnoho prostředků. Tyto prostředky můžeme rozdělit do dvou základních skupin podle toho, kdo je poskytuje:

  • prostředky poskytované operačním systémem
  • prostředky poskytované systémem řízení báze dat (SŘBD, tedy databázovým systémem).

Je nutné podotknout, že prostředky z první kategorie patří spíše minulosti a dnes se již prakticky nepoužívají. Pro případné zájemce jen stručně shrnu, že spočívaly v tzv. kontrolních bodech, v nichž systém vytvořil kopii všech souborů dané agendy. Mezi kontrolními body se pak ukládaly pouze změny (mohlo se například využít mechanismu ukládání jen těch – fyzických – bloků, v nichž došlo ke změně apod.). Tento přístup mě ale tu zásadní nevýhodu, že zajištění konzistence trvalo dlouho a v inkriminovanou dobu nesmě s databází nikdo pracovat.

Druhý způsob je používaný vlastně všemi moderními relačními databázovými systémy a spočívá v podpoře a práci s tzv. transakcemi. Protože se jedná o zajímavé a užitečné téma, pokusím se vyslyšet vaše žádosti a popsat jej podrobněji, přestože s Delphi přímo nesouvisí.

Transakce – co to je?

Celá řada moderních databázových systémů – prakticky všechny – nesou přízvisko transakční. Co to znamená?

Pojem „transakce“ lze přirovnat k běžné události z reálného světa. Zásadním požadavkem na transakci bývá atomičnost, tj. transakce musí být provedena celá a nebo nesmí být provedena vůbec. Ukážeme si to na příkladu. Dejme tomu, že spravujeme databázi z bankovního sektoru: transakcí může být například:

  • vložení peněz na bankovní účet číslo X,
  • výběr peněz z účtu číslo X,
  • převod peněz z účtu X na druhý účet Y,
  • ...apod.

Zaměřme se na třetí zmíněnou událost (tj. transakci) – převod peněz z jednoho účtu na druhý. Tato transakce se skládá ze dvou (nedělitelných) kroků:

  • odečtení peněz z bankovního účtu číslo X,
  • přičtení peněz na bankovní účet číslo Y.

Událost „převod peněz z účtu X na účet Y“ je typickou transakcí, protože k tomu, abychom ji mohli prohlásit za „úspěšně dokončenou“, musí být provedeny oba její kroky. Nesmí se stát, aby z účtu X došlo k odečtení částky, ale třeba z důvodu následné poruchy systému se příslušná suma nepřičetla na účet Y. Po provedení kroku 1 se tedy musíme přesvědčit, že se úspěšně provede/provedl i krok číslo 2. Neprovede-li se, musíme krok 1 zrušit, vzít zpět.

Můžeme si uvést ještě jeden příklad typické transakce. Dejme tomu, že se zabýváme knihovnictvím a máme databázi knih, čtenářů a jejich výpůjček. Každý čtenář je v systému reprezentován (kromě dalších údajů) svým jedinečným číselným označením – identifikátorem. Pokud se některému čtenáři změní tento identifikátor (ponechme nyní stranou úvahy o tom, proč by se mu mělo měnit), musí se tento identifikátor změnit i u všech jeho výpůjček. Také tato operace je transakcí – nesmí dojít k selhání někde uprostřed, protože pak bychom měli „ve vzduchu“ některé výpůjčky s neexistujícím čtenářským číslem. Buď se musí změnit čísla u čtenáře i u všech jeho výpůjček, nebo se nesmí změnit zhola nic.

Toto je základní koncepce transakcí v reálném světě a totéž platí i o transakcích v databázových systémech. Pokud se pustíme do nějaké činnosti, která se skládá z řady dílčích kroků, ale splňuje požadavky na transakci (tj. učinit buď všechny kroky nebo nic), postupujeme v databázovém systému obecně takto:

  • vytvoříme/spustíme novou transakci,
  • provedeme všechny kroky, které se v dané transakci nacházejí,
  • pokud vznikne v průběhu některého kroku chyba a krok nemůže být dokončen, celou transakci zrušíme, tj. odvoláme všechny dosud provedené kroky,
  • provedou-li se všechny kroky úspěšně, transakci potvrdíme. Teprve potom obsahuje databáze související data: teprve potom lze transakci prohlásit za provedenou.

Výše jsme si transakci popsali a vágně definovali. Nyní uvedeme přesnější definici: transakce je posloupnost operací nad objekty databáze, která realizuje jednu ucelenou operaci z pohledu uživatele. Transakce je základní logickou jednotkou práce a je také jednotkou zotavení z chyb. Vyznáte-li se v teorii operačních systémů, můžete si databázovou transakci přirovnat k pojmu „proces“ z oblasti operačních systémů.

Na tomto místě je nutné uvést jednu důležitou poznámku, která teď možná napadá některé akurátní čtenáře. Transakce je sice základní logickou operací, avšak typicky se skládá z řady dílčích kroků. Tyto kroky musí postupně provést jednotlivé dílčí úkony (např. změnit číslo čtenáře, následně změnit číslo jeho první výpůjčky, následně změnit číslo jeho druhé výpůjčky apod.). Z toho plyne důležitý důsledek – v průběhu provádění transakce není databáze v konzistentním stavu. To však nevadí, pro nás je důležité, aby byla konzistentní po skončení transakce. Konzistentní stav přitom nemusí znamenat „aktuální stav“: pokud je transakce dokončena úspěšně, bude databáze v aktuálním konzistentním stavu a pokud skončila s chybou, je v neaktuálním (ale stále konzistentním) stavu. Konzistence pouze říká, že takové hodnoty mohou reálně nastat: neříká nic o tom, že jsou tyto hodnoty momentálně platné.

Stavy transakce

Abychom si mohli vysvětlit způsob, jakým databázové systémy zacházejí s transakcemi a jakým zajišťují konzistentní stav, je nutné zmínit stavy, v nichž transakce mohou být. Ještě předtím však musíme uvést tři základní činnosti, které s transakcí lze provést:

  • vytvoření transakce. Poté, co se rozhodneme, že některá událost reálného světa splňuje vlastnosti transakce (časem zjistíme, že to platí prakticky o všech událostech, které nelze „vyřídit“ jedním SQL příkazem), musíme vytvořit novou transakci. Poté, co transakci A vytvoříme, začne ihned běžet a my následně musíme jen říkat cosi ve smyslu „následující příkaz patří do transakce A“, tedy že následující příkaz má být proveden v rámci transakce A.
  • potvrzení transakce. Jakmile dokončíme poslední krok transakce a máme jistotu, že všechny provedené kroky skončily bez chyb a učinily to, co jsme od nich očekávali, můžeme transakci potvrdit. Tím řekneme cosi ve smyslu „milý databázový systéme, všechny předchozí kroky provedené v rámci transakce A tímto potvrzujeme“. Pak je již na databázovém systému, jak s touto informací naloží. Jak poznáme později, některé databázové systémy nezapisují do databáze (fyzicky) žádné změny před tímto potvrzením a po něm zapíší vše najednou. Jiné systémy naopak ukládají vše ihned po provedení, ale teprve potvrzení je pro ně signálem, že „zapsané změny už nebude nutné brát zpět“ apod.
  • zrušení transakce. Zjistíme-li, že některý z kroků transakce se neprovedl nebo že nějaká jiná událost (třeba i způsobená uživatele, okolním světem nebo získanými daty) brání úspěšnému dokončení transakce, transakci zrušíme. Tím prohlásíme „milý databázový systéme, všechny kroky provedené v rámci transakce A chceme vzít zpět a databázi chceme uvést do stavu před začátkem transakce A“. Nyní opět záleží na tom, jak databázový systém vnitřně pracuje s transakcemi: pokud všechny změny ihned ukládá, musí nyní projít obtížným procesem jejich zrušení a „vzetí zpět“ (musí tedy odkudsi přečíst původní hodnoty. Naopak neukládá-li fyzicky žádné změny před potvrzením, nemusí nyní učinit zhola nic. Těmito všemi otázkami se budeme později podrobněji zabývat.

Na tomto místě bych jen podotkl, že předchozí popis vypadal poměrně jednoduše („databázový systém zruší všechny změny a uvede databázi do stavu před startem transakce“). Je však nutné vidět, že tento úkol může být (a v reálných databázích také bývá) velmi obtížný, a to především proto, že databázové systémy umožňují (v současnosti prostě musí umožňovat) současný běh více transakcí. Jistě si dovedete představit zmatek, který vznikne při požadavku na zrušení transakce, po jejímž startu bylo spuštěno třeba dalších 100 (nebo 100 000) transakcí. Pro nás je však podstatné, že moderní transakční databázové systémy si s tímto úkolem dokáží poradit, a dokáží tedy konzistenci zajistit a udržet.

Nyní se konečně dostáváme ke slíbeným stavům, v nichž transakce za svého „života“ může být. Základní stavy transakcí vidíte na následujícím obrázku:

Klepněte pro větší obrázek

Zkratky uvedené v tomto obrázku mají následující význam:

  • A – Active. Transakce je aktivní a probíhá. V okamžiku, kdy transakce vznikne (kdy je vytvořena), je okamžitě ve stavu A a tedy okamžitě začne provádět svou činnost.
  • PC – Partially Commited. Transakce je částečně potvrzena, to znamená, že je již dokončila poslední dílčí operace, ale ještě nedošlo k explicitnímu potvrzení transakce (ještě jsme neřekli, že transakci potvrzujeme).
  • C – Commited. Transakce je potvrzena. Po potvrzení již máme zaručeno, že všechny změny provedené transakcí jsou v databázi fyzicky zapsány.
  • F – Fault. Jedná se o chybový stav, do něhož transakce „spadne“ v případě, že nemůže z nějakých důvodů pokračovat ve své činnosti.
  • AB – Aborted. Zrušení transakce, tedy požadavek na navrácení dat v databázi do stavu před spuštěním trensakce.

Protože z obrázku nejsou patrné přípustné přechody mezi stavy, vyjmenujeme je v následujícím přehledu:

  • A -> PC. Transakce provede všechny kroky a přejde do stavu „částečně potvrzeno“. Následně čeká, dokud transakci nepotvrdíme.
  • A -> F. Transakce provádí dílčí činnosti, avšak nastane chyba, která znemožní další pokračování transakce.
  • PC -> F. I ve stavu částečného potvrzení může nastat chyba (případně se můžeme rozhodnout, že transakci prostě nepotvrdíme).
  • PC -> C. Částečně potvrzenou transakci konečně potvrdíme, tím se provedou všechny změny (neprovedly-li se již dříve) a transakce skončí svou existenci.
  • F -> AB. Transakci, která z nějakého důvodu – ať již na straně systému nebo z rozhodnutí uživatele – nemůže pokračovat, zrušíme. Transakce následně odvolá všechny provedené změny v datech (pokud je předtím ukládala) a skončí její existence.

Na závěr

Dnešní článek byl zaměřen na úvod do problematiky konzistence databáze, integrity dat a databázových transakcí. Vysvětlili jsme si, co výše uvedené pojmy znamenají a jaký mají význam při práci s databázemi. V závěru článku jsme se hlouběji ponořili do databázových transakcí a ukázali jsme si, co s nimi můžeme provádět (vytvořit, potvrdit, zrušit) a v jakém mohou být stavu (aktivní, částečně potvrzená, potvrzená, chyba a zrušená). Za týden budeme v databázových transakcích pokračovat a vysvětlíme si něco ze zákulisí práce databázových systémů: poznáme, jak databázový systém využívá transakce k zajištění konzistence a integrity spravovaných dat.

    Váš názor Další článek: Recenze HOOP Dandy 230: malý a funkcemi našlapaný MP3 přehrávač

    Témata článku: Software, Programování, Nekonzistence, Poslední číslo, Transakce, Důležitý krok, Zajímavé data, Díl, Jedinečný identifikátor, Základní koncepce, Konzistence, Kontrolní systém, Zrušení, Slíbená podpora, Častá operace, Krok, Moderní svět, Důležitá událost, Databáze, Technické zařízení, Speciální komponent, Plat, Apod, Nebezpečná událost, Typický příklad


    Určitě si přečtěte

    Na Zemi je nejtepleji za posledních více než 100 tisíc let. Co nám hrozí?

    Na Zemi je nejtepleji za posledních více než 100 tisíc let. Co nám hrozí?

    ** Letošní červenec byl třetím nejteplejším měsícem od roku 1880 ** Teplota naší planety roste raketovým tempem ** Co lidstvu hrozí v období, které v minulosti nemá obdoby?

    Karel Kilián | 70

    Roboruka se 100 let učila otočit kostičku. Skutečné A.I. se možná nikdy nedočkáme

    Roboruka se 100 let učila otočit kostičku. Skutečné A.I. se možná nikdy nedočkáme

    ** Strojové učení v posledních deseti letech dokázalo divy ** Používáme ho dnes každý den nejen ve vyhledávači ** A přesto se člověku nepřibližuje ani náznakem

    Jakub Čížek | 59

    Vyzkoušeli jsme eObčanku a přihlásili se s ní na weby úřadů. Vážně to funguje!

    Vyzkoušeli jsme eObčanku a přihlásili se s ní na weby úřadů. Vážně to funguje!

    ** Máme eObčanku, máme čtečku, vyzkoušeli jsme přihlášení na weby úřadů. ** Objevily se drobné problémy, podařilo se nám je vyřešit. ** Používání eObčanky pro online identifikaci je velmi pohodlné.

    Marek Lutonský | 35

    Praktické vychytávky, které si chcete doinstalovat do Windows

    Praktické vychytávky, které si chcete doinstalovat do Windows

    ** Pokud vás nudí vzhled nabídky Start, snadno jej můžete změnit. ** Stejně tak existují programy na přidání záložek do programů. ** Spokojit se ani nemusíte se základním ovládáním hlasitosti.

    Vladislav Kluska | 46

    Tohle tak jednou zažít: Nová vzducholoď Airlander 10 s prosklenou podlahou

    Tohle tak jednou zažít: Nová vzducholoď Airlander 10 s prosklenou podlahou

    ** Airlander 10 nabídne plavby vzduchem v interiéru s prosklenou podlahou ** Luxusní vzducholoď byla původně vyvíjena pro vojenské účely ** Počítá se s třídenními „kochacími“ výlety za poznáním

    Karel Kilián | 7


    Aktuální číslo časopisu Computer

    Jak vytvořit a spravovat vlastní web

    Velký test herních klávesnic a DVB-T2 tunerů

    Vše o formátu RAW

    Vybíráme nejlepší základní desku