Databáze

Tato kapitola si klade za cíl vám nejenom představit možnosti provozování databázových serverů na Linuxu, ale i nezasvěceným lidem trochu přiblížit některé aspekty databázových technologií. Pokud patříte k obeznámenější skupině čtenářů a zajímá vás jen to, co v oblasti databází nabízí Linux, přeskočte až na kapitolu Databáze v Linuxu.

Počítače zpracovávají údaje (data) už od doby, kdy první kvanta elektrické energie svlažila elektronky starobylého předchůdce všech dnešních „pí-síček“. Není proto divu, že celá problematika kolem schraňování, získávání a všelikého zpracovávání dat je velmi dobře propracovaná nejen na teoretické (nechutně matematikou zavánějící) úrovni. Od všech různých pojetí přístupu k datům se svět nejvíce přiklonil k tzv. relačnímu modelu a přes všechny další pokusy s objektovým paradigmatem je tento model stále nejpoužívanějším.

Po prvních pokusech o práci s informacemi programátoři velice záhy zjistili, že vymýšlení proprietárních řešení ukládání dat není ten nejrozumnější způsob mrhání časem a tak brzy začaly vznikat speciální systémy zabývající se výhradně problematikou spravování dat. V české kotlině se takovým softwarovým prostředkům začalo říkat SŘBD- Systém Řízení Báze Dat (v anglicky mluvících zemích DBMS – DataBase Management System).

Moderní SŘBD jsou aplikacemi typu klient/server, což v podstatě znamená, že jeden proces – server – pracuje jako služba běžící na pozadí (v Unixové terminologii jako démon) a k němu se připojují další aplikace – klienti. Server je hlavním výkonným jádrem databázového systému – stará se o všechny jeho základní funkce, tj. ukládá data a na požádání klientů je vyhledává a vrací. Klienty mohou být různé administrativní aplikace, programátorské knihovny nebo jiné rozhraní či klientské programy (kvůli kterým se vlastně celý ten cirkus provozuje) a podobně.

Relační databáze

Relační databáze ukládají data místo do jednoho velkého uložiště spíše do oddělených tabulek. Zajišťuje to rychlost a flexibilitu. Tabulky vždy popisují nějakou část reálného světa a stejně jako ve skutečném životě, i předměty zachycované tabulkami mohou být spolu v nějakém vztahu. (Např. učitelé učí třídy studentů. Učitelé jsou tedy v určitém vztahu ke třídám…) Jak na tabulky, tak na vztahy mezi nimi (mimochodem implementované opět jako tabulky) se dá pohlížet jako na matematický pojem relace.

Uvedený příklad s učiteli a třídami, které učí, by se dal v relační databázi zachytit třeba takto:

Do tabulky učitel bychom ukládali třeba jméno a příjmení učitele, jeho odborné schopnosti, věk a podobně. Kromě popisných dat bychom ale do tabulky vložili speciální sloupec s jednoznačným číselným identifikátorem učitele, který by sloužil jako klíč. Pomocí tohoto klíčového atributu bychom se vždy mohli na konkrétního učitele odkazovat. Kdykoliv bychom například řekli, že mluvíme o učiteli 1, bylo by ihned z databáze jasné, o kterém pracovníkovi školy je řeč.

Tabulka UČITEL:

 +----+-------+----------+-----+

 | ID | Jméno | Příjmení | … |

 +----+-------+----------+-----+

 | 1  | Jan   | Novák    |     |

 | …                         |

 +----+-------+----------+-----+

V tabulce třída by se uchovával třeba stupeň třídy a její název (třeba „A“). Nějakým způsobem by tam mohly být zakódovány jména studentů, ale to teď nebudeme řešit. Důležité je, že i ke každé třídě bychom přiřadili její jednoznačný identifikátor – klíč.

Tabulka TŘÍDA:

 +----+--------+-------+-----+

 | ID | Stupeň | Název | … |

 +----+--------+-------+-----+

 | 1  | 1      | A     |     |

 | …                       |

 +----+--------+-------+-----+

Jak tedy zachytíme vztah učí? Vytvoříme si novou tabulku stejného jména a vložíme do ní dva sloupce: klíč učitele a klíč třídy. Záznam (1, 10) bude tedy znamenat, že učitel 1 učí třídu 10 atd.

Tabulka UČÍ:

 +------------+----------+

 | ID_učitele | ID_třídy |

 +------------+----------+

 | 1          | 1        |

 | 1          | 2        |

 | 3          | 1        |

 | …                   |

 +------------+----------+

Relační databáze prorazily hlavně svou jednoduchostí – všechno je uloženo v tabulkách, tabulky mají sloupce, v každém sloupci jsou data určitého typu. Bohužel, jak to už v životě bývá, jednoduchost relací si ve složitých aplikacích vybírá svou daň: některé komplikované úlohy se pod relačními databázemi implementují velice těžko (připomíná to škrábání se levou rukou za pravým uchem).

Objektově orientované databáze

Objektově orientované databáze jsou výsledkem módy, které přineslo objektově orientované programování (OOP), a pokusu o odstranění typických achillových pat relačních systémů. V takových databázích jsou všechna data sdružována do objektů, které korespondují s věcmi (objekty) reálného světa. Podobně jako v OOP má každý objekt svou identitu (tj. je přímo systémově jednoznačně identifikovatelný – ne pomocí primárních klíčů jako v relačních databázích), definice dat se mohou dědit, objekty všelijak propojovat a podobně. Přestože jde o velmi hezkou metodu (možná intuitivnější než relace), stále ještě se jí nedostalo tolik úsilí co relačním databázím, takže ještě nejsou tak do detailu vypiplány a optimalizovány.

Jazyk SQL

Velmi dobrým počinem se stala i standardizace speciálního jazyka pro komunikaci s databázovými systémy, SQL (Structured Query Language – strukturovaný dotazovací jazyk). Základem SQL je dotaz. Odpovědí databázového systému je množina dat, které dotazu odpovídají. Velice příjemná je skutečnost, že dotazy v jazyce SQL mají syntaxi podobnou přirozenému lidskému jazyku. Posuďte sami:

SELECT jmeno, prijmeni FROM pracovnici

 WHERE vek < 50 AND plat > 10000

Tímto SQL dotazem SŘBD žádáme, aby nám zjistil ( SELECT) jména a příjmení všech lidí z ( FROM) tabulky pracovníků, kteří ( WHERE) jsou mladší padesáti let ( vek < 50) a dostávají plat vyšší než deset tisíc ( AND plat > 10000).

Síla jazyka SQL roste s faktem, že jej všechny významné softwarové firmy jako standard skutečně přijaly a všechny bez rozdílu ve svých implementacích používají. (Jistě, každý konkrétní SŘBD si k SQL přidává různé okrasy a odlišnosti, ale na určité jádro jazyka se můžeme spolehnout, že bude všude stejné.)

Další pojmy

Zmiňme se ještě v krátkosti o dalších pojmech z databázového světa. Tzv. uložené procedury (stored procedures) jsou SQL dotazy nebo nějaké části uživatelského kódu zapamatované databázovým systémem. Není to nic jiného, než analogie k obyčejným procedurám a funkcím klasických programovacích jazyků. Často používané konstrukce se systémem předzpracují a takto uloží. V případě, že je uživatel chce opět použít, nemusí se jejich zdrojový kód znovu číst, kontrolovat na chyby a předzpracovávat, ale rovnou se použije.

Podobné uloženým procedurám jsou triggery. Liší se však způsobem použití. Zatímco uložené procedury se vykonávají na žádost uživatele, triggery se spouštějí samočinně při vzniku nějaké události – například u přidání, modifikace či smazání záznamu. Díky triggerům můžete zajistit například to, aby se při změně nějaké hodnoty automaticky přepočítaly jiné údaje v databázi nebo aby se při odstranění jakéhosi hlavního záznamu vymazaly i všechny jemu podřízené položky a podobně.

Důležitým pojmem jsou také transakce. Transakcí se rozumí posloupnost příkazů, které musí být provedeny postupně buď všechny nebo žádný – jinak dojde k porušení konzistence dat. Dříve zmiňované SQL dotazy jsou vhodné pro atomické operace typu „najdi data“, „ulož nový záznam“ nebo „modifikuj položku“. Někdy je ovšem potřeba vykonat složitější operaci sestávající z opravování hodnot v několika tabulkách a podobně. Takový příkaz nelze provést jedním SQL dotazem, ale musí se realizovat postupně celou sérií příkazů. Co když ale stihneme vykonat pouze polovinu potřebných příkazů a dojde k výpadku proudu? Některá data budou mít už nové hodnoty, jiná ještě staré. V databázi dojde k porušení konzistence dat a ztrátě informace o vztazích mezi jednotlivými záznamy. Právě této nepříjemnosti se snaží transakce předcházet. V podstatě stačí, aby uživatel databázovému systému vždycky řekl, kdy transakce začíná a kdy končí. SŘBD pak může v klidu příkazy provádět a poznamenávat si, co všechno mění. V případě havárie pak lze podle těchto záznamů zrekonstruovat původní stav databáze a sérii příkazů (transakci) provést znovu.