12 pravidel E. F. Codda

Edgar Frank Codd byl původem britský matematik a informatik ve firmě IBM, který stojí mimo jiné za vynálezem počítačového přístupu k multitaskingu. V roce 1970 vymyslel relační model dat. Později si všiml, že mnoho firem začalo svým produktům říkat „relační databáze“, i když nesplňovaly základní požadavky. Proto sepsal tato pravidla jako „test“, který určí, zda je databáze skutečně relační.

Není bez zajímavosti, že kvůli požadovanému výpočetnímu výkonu se relační model dat poprvé podařilo produktivně realizovat až o téměř 10 let později, tehdy malou a neznámou firmou Oracle (dnes 4. největší softwarová společnost na světě).

1. Pravidlo SŘBD

Všechna data musejí být spravována databázovým systémem pouze prostřednictvím relačních operací.

Toto je základní pravidlo, které říká, že databáze se musí vždy chovat jako databáze a nikoliv jako sada textových souborů. Říká, že systém musí k řízení dat používat výhradně relační principy. Nikdy by neměl vyžadovat, aby programátor musel obcházet databázi a manipuloval se soubory na disku ručně.

2. Pravidlo informační

Všechna data musejí být na logické úrovni reprezentována pouze jako hodnoty v relacích.

Všechno v databázi je uloženo v relacích. Data uživatelů jsou uložena v relacích (databázových tabulkách), ale také metadata (informace o tom, jak se relace jmenují, jak se jmenují jednotlivé atributy, jakých jsou atributy datových typů, atp.) jsou uložena v relacích. Neexistují žádné skryté ukazatele nebo složité struktury, které by nebyly vidět jako záznamy a atributy v relacích.

3. Pravidlo zajišťující přístup

Každý údaj v databázi musí být logicky dosažitelný pomocí kombinace: Název tabulky + Název sloupce + Hodnota primárního klíče.

V databázi se nesmí nic ztratit – musíme být schopni pomocí kombinace třech jednoduchých údajů ukázat na jakoukoliv konkrétní buňku v celé databázi. Příklad – chci znát datum narození konkrétního žáka. Nejprve tedy musím vědět, že data žáků jsou uložena v relaci Students. Datum narození je uložen v atributu BirthDate. Pro identifikaci konkrétního žáka mi stačí znát jeho studentské ID, například best.ad.2022. Jestliže znám tyto tři údaje, jednoznačně se dostanu ke kýženému datu narození.

4. Pravidlo zpracování neznámých hodnot

SŘBD musí podporovat práci s NULL hodnotami systematicky, odlišně od prázdných řetězců nebo čísel.

Toto pravidlo říká, že databáze musí umět říci „Nevím“. Hodnota NULL znamená, že údaj chybí (nebo že není relevantní). Není to stejné jako nula nebo jako prázdný řetězec.

Je-li hodnota atributu Salary = 0 [Kč], pak to znamená, že zaměstnanec pracuje zadarmo. Je-li hodnota Salary = NULL, pak nevíme, kolik zaměstnanec bere (nebo plat nebyl ještě zadán). SŘBD se k hodnotě NULL musí chovat speciálně (např. 5 + NULL = NULL, nikoliv 5).

5. Pravidlo relačního katalogu

Popis celé databáze musí být na logické úrovni reprezentován také jako relace.

Uživatelům jsou k dispozici informace o struktuře databáze (metadatech) za použití stejného jazyka, jakým se běžně ptají na data (SQL). Například příkazem

SELECT * FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = "db22vasina" AND TABLE_NAME = "01Autor";

zjistíme strukturu relace 01Autor stejně jako příkazem

SELECT * FROM db22vasina.01Autor;

zjistíme obsah této relace.

6. Pravidlo pro jazyk

Musí existovat alespoň jeden jazyk, který umožňuje definici dat, manipulaci, výběr, transakce a oprávnění.

SŘBD musí s uživatelem a aplikacemi komunikovat počítačovým jazykem (v praxi většinou jazyky na bázi SQL), kterým je možné udělat všechno. Od vytvoření databáze, vytvoření struktury relací, přes vložení dat, výběr dat až po nastavení práv uživatelům. Není přípustné, aby se pro něco z toho musela použít jiná (externí) aplikace).

Takový jazyk musí umožňovat komunikovat příkazy v následujících skupinách:

7. Pravidlo pohledů

SŘBD musí poskytovat možnost práce s pohledy do databáze včetně aktualizace dat.

Pohled (view) je vlastně virtuální tabulka – můžeme si ji z technického pohledu představit jako uložený dotaz. Pohledy se používají především pro uložení složitějších dotazů nebo takových dotazů, kdy omezujeme viditelnost jednotlivých atributů či záznamů. Pravidlo říká, že pokud to logicky dává smysl, bude možné skrze tento pohled data také měnit (a SŘBD změnu musí promítnout do skutečných podkladových relací). V praxi to dobře funguje pokud je view nad jednou relací, pokud je view složeno pomocí JOINů z několika relací, už můžeme narazit.

Například si představme relaci Students, kde máme uložené všechny žáky. Ne vždy ale budeme chtít pracovat se všemi záznamy této relace, a tak si vytvoříme view (virtuální tabulku) CurrentStudents, kde budou uloženi pouze žáci se statutem „A“ (aktivní). Jakmile toto view máme již vytvořené, pracujeme s ním jako s klasickou relací, tj. například příkaz

SELECT * FROM CurrentStudents;

nám vrátí všechny žáky z tohoto view (tj. všechny žáky se statutem „A“ z relace Students).

8. Pravidlo operací

Všechny operace vybírající a vkládající data musejí pracovat s relacemi jako s celky.

Měli bychom být schopni pracovat s celou množinou dat v relaci najednou, nikoliv pouze záznam po záznamu. Tak například příkaz

UPDATE Employees SET Salary = Salary * 1.05;

přidá všem zaměstnancům najednou 5 % platu. Nemusím psát žádný program, žádnou smyčku, která bude postupně načítat jednoho zaměstnance po druhém, načítat jeho plat, přidávat mu 5 %, ukládat atd. SŘBD to pomocí podobného příkazu udělá vše hromadně.

9. Pravidlo fyzické a logické nezávislosti dat

Výsledky operací nesmějí být ovlivněny změnami struktury relací a konkrétní implementací.

Toto pravidlo spojuje dvě myšlenky:

  1. fyzická nezávislost – když databázový administrátor přesune data z pomalého disku na rychlé SSD nebo když změní způsob indexování, SQL dotazy musejí stále fungovat beze změny.
  2. logická nezávislost – když do relace přidám nový atribut BirthDate, nesmí to nijak rozbít (ovlivnit) existující aplikace, které tento atribut nepoužívají – a nesmí to mít ani žádný dopad na data, která v relaci již jsou.

V praxi se s tímto pravidlem můžeme setkat, jestliže chceme změnit strukturu již naplněné relace – například v relaci Customers již máme uloženého zákazníka s hodnotou atributu Surname Schottenbauer (13 znaků). Databázový vývojář se nyní rozhodne, že atribut Surname(50) je zbytečně dlouhý a pošle příkaz na zkrácení na 10 znaků. SŘBD ale zareaguje (podle pravidla 9) chybou 🛑 String truncation error. Data totiž mají „právo veta“ – změna struktury dat nesmí poškodit data samotná.

10. Pravidlo nezávislosti dat na integritních omezeních

Výsledky operací nesmějí být ovlivněny změnami v integritních omezeních, pokud nedošlo ke změně dat.

Toto pravidlo nám opět říká, že data mají „právo veta“. Integritní omezení je tudíž nejlépe definovat ještě před naplněním dat do jednotlivých relací. Není možné zpětně implementovat integritní omezení taková, která by již uložená data zneplatnila.

Například:

11. Pravidlo nezávislosti dat na distribuci

Výsledky operací nesmějí být ovlivněny konkrétním rozmístěním dat v distribuované databázi.

Zde je nutné si nejprve připomenout, co to vlastně je distribuovaná databáze – jedná se o databázi, která data (z provozních či bezpečnostních důvodů) má umístěná na více fyzických strojích (serverech). Distribuovaná databáze se uživatelům stále jeví jako jedna databáze (i když je fyzicky uložena na více počítačích).

Říká nám, že i když data fyzicky přesuneme na jiný server, nedojde k žádné změně dat. Uživateli musí být jedno, jestli jsou data uložena na jednom nebo druhém serveru, či kde se jednotlivé servery nacházejí. Ať si SŘBD na pozadí sám vyřeší, odkud si data stáhne.

12. Pravidlo nenarušitelnosti SŘBD

Žádný uživatel, aplikace ani nízkoúrovňový přístup nesmí obcházet ani narušovat pravidla SŘBD.

Toto pravidlo nám říká, že neexistují žádná „zadní vrátka“, kterými by šlo zapsat špatná data a obejít kontrolu.