COMPUTERWORLD
pod kapotou
Referenční integrita

V zájmu každého uživatele databáze je, aby odpovídala zadaným specifikacím. Jistě, víme dobře, že ne všechny specifikace uživatel zadal, řadu z nich totiž navrhl analytik či návrhář databáze, nicméně uživatel s nimi při schvalování návrhu databáze souhlasil a očekává, že výsledný IS bude specifikace podporovat.

Dnes nám nepůjde o uživatelské aplikace, ale spíše o to, zdali je zajištěno, že databáze je v průběhu svého života konzistentní. Konzistence databáze znamená v širším smyslu, že databáze odpovídá skutečnosti, v užším pojetí, že odpovídá alespoň zadaným integritním omezením (IO). Mimochodem, je jasné, že z prvního významu plyne druhý, ale ne naopak.

Zaměříme se pouze na jeden typ IO - referenční integritu. Je to IO popisující vztah mezi daty obsaženými ve dvou relacích. Motivací pro jeho použití je sám E-R model. Popíšeme-li realitu jako na obr. 1. Každý film může být hrán ve více kinech, každé kino může dávat i více filmů. Kina i filmy existují nezávisle na sobě, tj. existují kina, která nehrají nic, jsou filmy, které se nikde nepromítají.

hraje JMÉNO_F

KINO FILM

je hrán v REŽISÉR

JMÉNO_V

NÁZEV ADRESA

Obr. 1 Typ vztahu M:N mezi kiny a filmy

Převedeme-li dané konceptuální schéma do schémat relací, obdržíme zřejmě:

KINO(NÁZEV, ADRESA, JMÉNO_V)

FILM(JMÉNO_F, REŽISÉR)

PŘEDSTAVENÍ(NÁZEV, JMÉNO_F)

Kdo nahlíží do obrázku, je mu jasné, že entity typu KINO vztažené k entitám typu FILM typem vztahu “hraje” (“je hrán”) jsou prvky z entitní množiny KINO, resp. FILM. U relací odpovídajících konceptuálnímu schématu však může nastat i něco, co nechceme. Do relace PŘEDSTAVENÍ lze totiž bez problémů vložit řádek např. (Vesna, Zahrada), přestože kino Vesna již dávno neexistuje a nevyskytuje se v relaci KINO. Databázové relace jsou totiž obecně zcela nezávislé. Požadavkem tedy je, aby hodnoty sloupce NÁZEV v relaci PŘEDSTAVENÍ byly zároveň hodnotami sloupce NÁZEV v relaci KINO. Podobně lze postupovat i pro vztah hodnot sloupce JMÉNO_F z PŘEDSTAVENÍ k hodnotám sloupce JMÉNO_F v relaci FILM.

Schematicky lze požadavek na logickou vazbu mezi našimi relacemi zobrazit diagramem na obr. 2.

KINO NÁZEV ADRESA JMÉNO_V FILM JMÉNO_F REŽISÉR

PŘEDSTAVENÍ NÁZEV JMÉNO_F

Obr. 2 Diagram referenční integrity

Zajímavé je, že řada lidí se mylně domnívá, že dané vazby jsou skutečně fyzicky implementovány. To skutečně bývalo, ale u síťového či hierarchického databázového modelu. Databázové relace fyzicky propojeny nejsou, nejvýše přes indexy, ale to je jiná kapitola.

Pro snadnější vysvětlování se zavádí, že jedna tabulka je u referenční integrity vždy hlavní a jedna vedlejší. Dokonce může jít o jednu a tutéž tabulku. Zhruba řečeno, hlavní většinou odpovídá typu entity, vedlejší typu vztahu. Potom, atribut, kterého se referenční integrita týká ve vedlejší tabulce se nazývá cizí klíč (foreign key). Jde o atribut (často i skupinu atributů), jehož hodnota v n-tici relace je buď prázdná nebo musí být obsažena jako hodnota primárního klíče hlavní relace.

Poslední větu bychom mohli chápat jako definici referenční integrity. Vyskytuje v ní ale něco, co není obsaženo v původní definici relačního databázového modelu. Jde o tzv. prázdné hodnoty (v SQL se nazývají NULL) označující nedefinované či neznámé hodnoty. Existence prázdných hodnot vychází z praktických potřeb. Ne vždy jsou data v n-ticích relací známá, ne vždy jsou definovaná.

Prázdné hodnoty někdy souvisí s nepovinným členstvím v E-R modelu a kardinalitou 1:N. Uvažujme relaci FILM rozšířenou o atribut HVĚZDA, její schéma je FILM (JMÉNO_F, REŽISÉR,HVĚZDA). Hvězda ve filmu se předpokládá nejvýše jedna. Tabulka vlastně reprezentuje vztah mezi filmy a herci, pro které je k dispozici samostatná tabulka HEREC. Daný typ vztahu v E-R modelu můžeme definovat tak, že v něm herci mají nepovinné členství, tj. existují ale nemusí být hvězdou v žádném filmu, tj. mohou existovat i filmy bez hvězd (např. dokumentární, nebo jenom s vedlejšími rolemi). Odpovídající tabulka FILM tedy může obsahovat prázdné hodnoty atributu HVĚZDA, nicméně, jestliže hodnota existuje, musí být z obsažena v tabulce HEREC. Takže uvedená koncepce referenční integrity je smysluplná.

Nejnovější verze standardního přístupu k referenční integritě je obsažena ve standardu SQL92. Řeší nejen podstatu, ale i možnosti reakce SŘBD, které mají následovat při narušení referenční integrity aktualizační operací. V předchozím standardu SQL SŘBD pouze poskytoval upozornění. Ukážeme reakce podrobněji pro varianty příkazů INSERT a DELETE, které lze přímo specifikovat v definicích tabulek. (Pro UPDATE je styl možností podobný.) budeme předpoklát, že primární klíč hlavní relace je množina atributů K a tatáž množina atributů tvoří cizí klíč vedlejší relace.

INSERT:

  • omezené vložení n-tice u do závislé relace

Operace není dovolena, neexistuje-li pro hodnotu K n-tice u odpovídající n-tice v hlavní relaci s toutéž hodnotou K.

DELETE:

  • omezené odstranění n-tice u z hlavní relace

Operace není dovolena, existuje-li pro hodnotu K n-tice u v závislé relaci n-tice s toutéž hodnotou K.

  • kaskádové odstranění n-tic

Operace odstranění n-tice u z hlavní relace je propagována do závislé relace, kde se odstraní všechny ty n-tice, které mají stejnou hodnotu K jako n-tice u.

  • nahrazení cizího klíče prázdnou hodnotou

Operace odstranění n-tice u z hlavní relace je propagována do závislé relace, kde se všechny hodnoty K stejné jako hodnota K n-tice u, nahradí prázdnou hodnotou.

  • nahrazení cizího klíče implicitní hodnotou

Operace odstranění n-tice u z hlavní relace je propagována do závislé relace, kde se všechny hodnoty K stejné jako hodnota K n-tice u, nahradí implicitní hodnotou.

  • odstranění n-tice u z hlavní relace s upozorněním

Operace je dovolena s upozorněním, že pro hodnotu K n-tice u existují v závislé relaci n-tice s toutéž hodnotou K.

Snadno lze najít příklady podobné referenční integritě, které nejdou deklarovat ani v SQL92. Prvky referenční integrity byly s oblibou ohlašovány výrobci SŘBD jako nový rys další verze. Zdůrazněme však, že referenční integrita, ať je jakkoli atraktivní, pokrývá pouze nepatrnou částí potřeb, které pro vybudování solidní databáze vyžadujeme. Složitější, i když ne zcela obecná, IO umožňuje formulovat a pojmenovat SQL92 klauzulí ASSERTION. Většina současných implementací SQL však zatím neumožňují realizovat neprocedurálně složitá IO. Je to do jisté míry dáno i dávno zjištěným faktem, že provoz komplikovanějších IO je časově náročný, že by měl být optimalizován, podobně jako se optimalizuje vyhodnocení dotazů. V běžné praxi se IO stále “doprogramovávají” do aplikace, v lepším případě jsou formou uložených procedur uloženy v blízkostí definice databáze na serveru. Jejich formulace ovšem vyžaduje speciální jazyk, který je zatím u různých SŘBD různý.

Jaká je perspektiva ? Příznivá. Připravovaný standard SQL přináší nové jazykové prvky, které ho budou činit zcela soběstačným. Jinými slovy řečeno, definice databáze i aplikace budou moci být vybudovány jedním (výpočetně úplným) jazykem. Zní to lákavě, ale něco mi říká, že než se implementace takového jazyka objeví na trhu, tak si pár let ještě počkáme.



<seznam dílů seriálu>   <COMPUTERWORLD>