![]() |
![]() | ||||||||||
Relace vs. tabulka
Víme již, že základním pojmem a současně i konstrukčním nástrojem (konstruktem) relačního modelu dat je relace. Relace je matematický pojem, i když se používá v běžném jazyku i v jiných souvislostech, jako např. relace v rozhlase, něco je s něčím v relaci apod. Ten druhý význam napovídá, že jde o nějaké vztahy. Např. (Novák, 480423/016, 23.04.1948) reprezentuje vztah mezi údaji Novák, 480423/016 a 23.04.1948. Daná trojice (možná) reprezentuje vztah vyjádřitelný větou “Novák má rodné číslo 480423/016 a narodil se 23.04.1948. Ano, relace obsahuje prvky, které reprezentují vztahy mezi nějakými objekty. Teď trochu matematicky. Relace je v matematice významnou, dokonce fundamentální strukturou. Formální definice říká: jsou-li D1,...,Dn, kde n³ 2, množiny, pak relace nad množinami D1,...,Dn je libovolná podmnožina kartézského součinu D1´ ...´ Dn. Neformálněji řečeno, relace je množina prvků (d1,...,dn), kde di je z Di, pro každé i od 1 do n. Důležité jsou dva důsledky této definice:
Geniální myšlenkou otce relačního databázového modelu E.F. Codda bylo použít formální pojem relace na soubory dat. Je-li D1 množina jmen, D2 množina rodných čísel a D3 množina dat, pak v kartézském součinu D1 ´ D2 ´ D3 jsou všechny možné trojice reprezentující vztahy mezi daty z uvedených množin. V daném čase pouze některé z nich odpovídají skutečnosti (např. v podniku). A přesně ty tvoří onu podmnožinu kartézského součinu. Aby se s relacemi dalo jednoduše zacházet zavedl Codd pojem atributu. Atribut relace není nic jiného než pojmenovaná množina (v databázové terminologii doména) použitá v kartézském součinu. Jde-li např. o DATUM, pak v kontextu našeho příkladu je atributem DATUM_NAROZENÍ:DATUM. Jméno atributu umožňuje rozlišit dvě stejné množiny v kartézském součinu. Důležité ovšem je, aby v rámci jednoho typu relace byla jména atributů různá. Najednou jsme se z matematiky přenesli do informatiky. Použili jsme slovo typ relace. V databázovém žargonu se však zarazíme o pojem schéma relace. Jak to spolu všechno souvisí? Připomeňme si schéma relace PRACOVNÍK(JMÉNO, RODNÉ_ČÍSLO, DATUM_N) z minulé databázové abecedy. Jak je vidět domény byly zamlčeny. Domysleme si je ke jménům atributů. Uvedená trojice atributů dává typ relace pracovník. Technicky je ovšem PRACOVNÍK spíše relační proměnná, jejíž hodnota se mění, tak jak to požaduje uživatelské aplikace. Všimněte si, že téhož typu můžeme použít pro schéma relace DŮCHODCE, ZÁKAZNÍK apod. Přibereme nyní ještě trochu terminologie. Prvkům množin - relací se říká n-tice. Je to náhrada z anglický termín tuple, který marně hledáme v anglických slovnících, a který zřejmě lépe vystihuje situaci. Neobsahuje totiž žádné n. Nejlepší je dívat se na pojem n-tice jako na jedno slovo a nechápat n jako nějaký parametr. Trojice, dvojice, dvacetice - všechno jsou n-tice. Někteří puristé navrhovali všelijaká náhradní řešení, jako vektory, jiní píší entice (to by asi nebylo tak nejhorší), někdo dokonce navrhoval tice. Bohužel, slyšet je občas i tuple. Že jsem zapomněl na řádek? Hned na něj dojde. Dodejme ještě dvě poznámky. Jedna je se týká maličkosti. Užitečné jsou i relace, kde n = 1. To trochu naráží na naivní představu o vztazích, nicméně proč ne. Zajímavější a podstatnější je ovšem něco jiného. Komponenty jednotlivých n-tic jsou nedělitelné. Jde o významné omezení, které je na druhé straně vyváženo jednoduchostí nazírání na relace. Jde vlastně o ty nejjednodušší soubory dat. V relačním modelu dat však tento fakt hraje ještě významnější roli. Umožnil Coddovi takřka zadarmo využít aparát matematické logiky, který s pojmem relace úzce souvisí. Právě v tomto momentě je třeba zdůraznit, proč se vlastně “relační” pojmy zavádí (vždyť bychom jinak mohli vystačit s pojmem soubor!). Logiku lze totiž použít pro vybudování relačních dotazovacích jazyků. Co však plyne negativního z omezení na atomičnost komponent relace? Např. to, že, do komponenty n-tice, např. rodné číslo 480423/016 je z hlediska relačního nazírání chápáno jako jeden řetězec znaků. Nelze z něj “vytáhnout” rok, měsíc apod. Někdy by se třeba hodilo mít jako komponentu n-tice množinu. Představme si schéma relace PRACOVNÍK_S_DĚTMI(JMÉNO, DÍTĚ). Doménou DÍTĚ jsou křestní jména. K vyjádření faktu, že Novák má děti Jarmilu, Frantu, Honzu potřebujeme tři n-tice. Jméno Novák se tam bude opakovat, ale s tím už se musíme smířit. Můžete namítnout, že bychom mohli zavést atributy DÍTĚ2, DÍTĚ2, DÍTĚ3. Toto řešení je řešením jen zdánlivě. Problém by nastal v případě, že někdo má více dětí než 3, ale i méně dětí než 3. Co by se totiž dosadilo do n-tice za hodnoty? Možná prázdná hodnota (speciální symbol), ale v tom smyslu nám zatím relační databázový model žádné “oficiální” řešení nenabízí. Atomičnost (nedělitelnost) hodnot tvořících komponenty n-tic se tradičně nazývá 1. normální forma relace. Jde vlastně o důležitý předpoklad celého relačního přístupu. Už jsme konečně u tabulek. Tabulka a relace není totéž. Intuitivní pojem tabulky překládá jistou podobu - reprezentaci relace např. na obrazovce na papíře apod. Předkládá uživateli jisté pořadí řádků, narozdíl od relace, kde se o uspořádání n-tic nic neříká. V běžném životě může také tabulka obsahovat stejné řádky, což je v rozporu s relací, kde dvě stejné n-tice nejsou dovoleny. Proč tedy tabulka? Jde o pojem, který do relačního databázového modelu vnesli v počátcích 70. let tvůrci jazyka SEQUEL (později SQL). Tabulka je bližší uživateli, zakrývá mu matematickou podstatu věci. V SQL může mít tabulka dokonce duplicitní řádky, tyto řádky mohou obsahovat i tzv. prázdnou hodnotu (NULL). Nejde o špatný nápad, protože v praxi je neúplná informace běžná, i duplicity řádků jsou občas potřebné. Ovšem pozor! SQL tak používá poněkud odlišný aparát než je relační. Asi by bylo lepší říkat tabulkový databázový model. Slovem tabulka se překládá anglické tabel. Když se zamyslíme nad tím, že máme tabulky o 100000 řádků, je to trochu směšné. Slyšel jsem i říkat místo tabulka tabule. Připravíme řediteli na ranní poradu potřebné tabule. Co k tomu dodat. Shrneme nyní pojmy tabulkového a relačního databázového modelu.
Atribut relace není přesně totéž co sloupec tabulky. Atribut zahrnuje celou doménu, kdežto sloupec jen hodnoty dané v tabulce. Popis tabulky či relace dosud obsahoval to nejnutnější, co bylo pro modelování reálných objektů potřeba. Jeden problém však zůstává. Jak zařídit, aby se do databáze dostaly jen takové n-tice, které odpovídají vztahům v reálném světě. Člověk je totiž omylný a spolehnout na něho se zcela nedá. Databázisté proto vymysleli pojem integritní omezení (IO). Ke schématu relace se přidají jistá tvrzení, která omezují široké možnosti vstupu n-tic do relací. Např. “hodnoty atributu PLAT je z intervalu hodnot < 5600, 10800> ”, nebo “každý vedoucí je pracovník” jsou taková omezení. Mohou poskytovat podmínky na hodnoty n-tic, na vztahy mezi n-ticemi v jedné relaci, ale i složitá tvrzení popisující vztahy mezi n-ticemi více relací. Není těžké si představit, že lze zařídit, aby za IO stály programy kontrolující vstupující data. Jazyky jako SQL dnes v tomto směru nabízejí dost silné možnosti. Čím více IO, tím lepší databáze. Všechno ale něco stojí. Zavedením složitých kontrol dat se můžeme dostat do situace, že kontroly budou trvat neúnosně dlouho. Takže schéma relace neobsahuje pouze popis atributů, ale také IO. Relace, které vyhovují IO budou přípustné relace. Je ovšem třeba si uvědomit, že dokonalé přesnosti nelze nikdy dosáhnout. Jestliže se mi úředník na magistrátě splete při vstupu údaje rok absolvování základní školy o jedničku, žádná systémová podpora mi takovou chybu neodhalí. Co z toho vyplývá? Nevěřte všemu, co se z databází dozvíte. Nejde však jen o neúmyslné chyby. Databáze obsahují data a my je modifikujeme v informace. A nejde jen o informace k řízení podniku. Hezkou relaci uvádí pan Date v jedné své práci: PTÁK(JMÉNO,POPIS,OBRÁZEK,POHYB,ZPĚV,MAPA STĚHOVÁNÍ) Jde o vskutku multimediální relaci, kterou bychom si mohly představit široce přístupnou v síti. A co když se někdo (úmyslně) splete a vloží do relace obrázek, kde kos je červený? <seznam dílů seriálu> <COMPUTERWORLD> |