Teorie relačních databází: Integritní omezení
10.9. 2006Co je to konzistence dat. Proč se jí zabývat a jak jí udržovat. Co jsou to integritní omezení, čím jsou mi užitečné a proč se jimi zabývat?
Tento článek bude čistě teoretický, neboť každý DBMS má v tomtu ohledu jinou syntaxi a jiné metody, není možné psát zároveň teoretický a praktický článek při zachování nezávislosti platformy. Pro upřesnění pojmů, serverem se myslí databázový server a klientem je aplikaci přistupující k datům v databázi.
Co je to integrita databáze? Je to jenom jinak řečeno konzistence. Realční model dat specifikuje strukturu dat v databázi, ale k tomu, abychom mohli používat databázi jako zdroj dat, je nutné zajistit, aby se do ní dostali jen data, která tam patří a neztratila se data, která nemají. Také je potřeba k tomu mít určité mechanizmi. Těmito mechanizmy jsou integritní omezení (IO). A databáze, respektive data jsou konzistentní, pokud jsou ve stavu, vyhovující IO. To znamená, že se žádnou úpravou dat (úpravou, smazáním) neztratila nebo nepoškodila data, nebo že v DB nejsou data, která tam nemají co dělat, například seznam kontatů smazaného uživatele apd. Proto existují integritní omezení, která mají podobným nehodám zabránit. Vzhledem k tomu, že k porušení integrity databáze může dojít několika způsoby, rozeznáváme několik druhů integritních omezení. A to:
Entitní
Toto IO všichni používáme, protože je v relačním modelu povinné, jde o specifikaci primárního klíče tabulky. Primární klíč je atribut, či minimální seznam atributů, které jednoznačně určují ntici (řádek) relace. Minimální ve smyslu, že z ní nelze odebrat žádný atribut, aniž by se ztratila jedinečnost. Toto omezení implementuje každá relační databáze a při pokusu o vložení nevyhovujích tomuto omezení dojde k chybě.
Doménové
Doménová integrita znamená, že na úrovni sloupců definujeme omezení na určitý datový typ, případně omezení rozsahu hodnot. V databázové hantýrce se tomu celému říká doména atributu. Více viz vaše oblíbená SQL a například CHECK(…) v definici sloupců. Pokud budete hledat funkci check(…) v MySQL, narazíte po dlouhém hledání na jednu nenápadnou větičku ve stránce s referencí příkazu CREATE TABLE: „The CHECK clause is parsed but ignored by all storage engines.“ Což znamená, že na tuto funkci si můžete nechat v MySQL zajít chuť a složitější doménovou integritu řešit trigery.
Referenční
Referenční integrita (RI) je již mezitabulkovou záležitostí. Definuje vztah dvou tabulek, a to pomocí cizích klíčů (FOREIGN KEY). Tabulky, kterých se tento vztah týká, bývají anglicky označovány jako master,detail nebo parent,dependent. Cizí klíč v relaci určuje atribut (skupinu atributů), které mají buďto hodnotu NULL, nebo hodnotu primárního klíče některého řádku nadřazené tabulky. Například v relaci kniha bude sloupec atribut autor, který podle tohoto IO musí mít hodnotu NULL, nebo ID nějákého autora z relace autor.
Aktivní referenční integrita
Definuje co ma databázový stroj udělat, pokud by mělo dojít k porušení referenční integrity. Například při smazání (updatu) nadřazeného záznamu lze u většiny moderní databázových systémů definovat akce, která se má provést. Například RESTRICT pro zákaz, CASCADE, pro kaskádové smazání (změnu), SET DEFAULT pro nastavení defaultní hodnoty sloupce s cizím klíčem, či SET NULL, které snad není nutné vysvětlovat.
Ošetření IO
Jsou tři způsoby jak zajistit integritu databáze:
Deklarativní na serveru
Databázové shcéma se do databázového stroje ukládá včetně definice IO. Z hlediska ochrany dat je tento způsob ideální. M však i své nevýhody při použití IO na straně databáze je uživatel aplikace upozorněn na chybu s určitým zpožděním, což nepřispívá konfortu uživatele. A například při vývoji podnikových aplikací, kde pořadavkem každého zákazníka je jiný databázový systém je poněkud nešikovné a ve výsledku drahé definovat IO v každém databázovém stroji zvlášť.
Procedurální na straně klienta
Kontrolní procedury a ochrany jsou na straně klienta. Toto je z hlediska uživatele aplikace nejkomfortnější, neboť aplikace bezprostředně reauguje na vstupy uživatele. Také pro vývojáře aplikací, kteří požadují nezávislost aplikace na databázovém stroji, je tento způsob vhodný. Bohužel i tato metoda má své nevýhody. Nutnost mít kontrolní proceduru pro každou operaci s daty, může být zdrojem chyb. A pokud má nad konstruovanou DB běžet více aplikací je tato metoda nevhodná, neboť musíme kontrolní procedury definovat v každé aplikaci a případné změny ve schématu DB nám pořádně skomplikují život, protože dohledávat a měnit kontrolní procedury v každé aplikaci bude pravděpodobně velmi nákladné.
Procedurální na straně serveru
Kontrolní procedury tvoří samostatné programové moduly uložené a prováděné na serveru. Speciálně pro kontrolu IO jsou v moderních DBMS implementovány TRIGGRY (od verze 5 i v MySQL), což jsou procedury, které by se dali přirovnat k událostem z objektového programování. Jsou to události spouštěné před/po událostech INSERT,UPDATE nebo DELETE. Pomocí těchto procedur se dají v DBMS definovat podstatně složitější IO. Jsou to omezení vyplívající ze složitějších podmínek. Většinou bývají dány přímo logikou dat nebo jsou to podmínky dané zákazníkem. Například, že v oddělení firmy nesmí být méně než 3 zaměstnanci apd.
Všechny metody mají své výhody i nevýhody. Nejlepším řešením se jeví požití procedurální kontroly na straně klienta jako doplněk deklarativní a v případě složitějších i procedurální definice IO na straně serveru. Zajímavou metodou omezení výskytu chyb v kontrolních procedůrách na straně klienta jsou vývojová prostředí, která nahlížejí do katalogu databáze a ze zjištěných údajů automaticky generují kontrolní procedury aplikace.
Kdy se kontroluje dodržení integritních omezení?
Entitní a doménová integrita se kontroluje okamžitě. Referenční integrita a složitější procedurální definice IO se mohou kontrolovat buď po dokončení příkazu, nebo až po dokončení celé transakce. Okamžitá kontrola je méně náročná, neboť si server nemusí pamatovat všechny odložené kontroly. Kontrola odložená na konec transakce je nutná v případě, kdy prvně integritu porušíme a následně ji obnovíme. Pozornější čtenář si jistě všiml, že v příkladu složitějšího integritního omezení, kde jsme uvedli podmínku existence oddělení minimálně tři zaměstnance v oddělení, by nebylo při kontrole IO po každém příkazu možné oddělení ani založit ani odstranit. Naopak při kontrole až po dokončení transakce můžeme vytvořit oddělení bez zaměstnanců a odložit kontrolu, následně do oddělení převést dostatečné množství zaměstnanců a dokončit transakci a spustit kontroly, které tentokráte projdou.
Integritní omezení jsou nutná pro udržiní konzistence dat. Spousta začátečníků často nemá potuchy, že se jimi musí zabývat a pak se často diví co se jim to děje s daty. Entitní a základní doménovou integritu nás nutí dodržovat snad všechny DBMS. Na refernční a složitější integrita už musíme dbát sami. Vzhledem k tomu, že spousta začínajících programátorů a to hlavně na MySQL nemá potuchy o tom, že mohou referenční IO definovat přímo v databázi a ušetřit si tím spoustu práce. Bude příští článek o zajištění referenční integrity v MySQL.