Relační databáze je databáze založená na relačním modelu. Často se tímto pojmem označuje nejen databáze samotná, ale i její konkrétní softwarové řešení.

Relační databáze je založena na tabulkách, jejichž řádky obvykle chápeme jako záznamy a eventuálně některé sloupce v nich (tzv. cizí klíče) chápeme tak, že uchovávají informace o relacích mezi jednotlivými záznamy v matematickém slova smyslu.

Termín relační databáze definoval Edgar Frank v roce 1970.

Historie

V roce 1890 vznikl na objednávku státních úřadů v USA první automat na bázi děrných štítků. U jeho zrodu stál Herman Hollerith, jehož firma při fúzi několika firem dala vzniknout IBM. Ta stála v popředí i v roce 1951, kdy vznikl první digitální počítač pro komerční využití UNIVAC I. V roce 1960 vznikl předchůdce dnešních databázových jazyků COBOL. V 60. letech založil Charles Bachman spolu s dalšími výzkumníky seskupení Codasyl, které publikovalo základní specifikaci pro programovací jazyky, především pro COBOL. Většina Codasyl kompatibilních databází byla postavena na síťovém modelu, zatímco firma IBM se vydala cestou hierarchického modelu. V roce 1970 přišel Ted Codd s novým návrhem datového modelu, relačním modelem. Dle relační teorie lze pomocí základních operací (sjednocení, kartézský součin, rozdíl, selekce, projekce a spojení) uskutečnit veškeré operace s daty a ostatní operace jsou již jen kombinacemi těchto šesti. Zavádí se použití relačního kalkulu a algebry. Databáze mají být nezávislé na fyzickém uložení dat i na použitém jazyce. Pod tlakem událostí se do projektu vkládá i IBM, která přichází s jazykem SQL. První SQL databází se v roce 1980 stal Oracle pro počítače VAX-11. Druhá v řadě přichází i firma IBM s produktem IBM DB2.

Terminologie

Základním konstruktorem relačních databází jsou relace (databázové tabulky), což jsou dvourozměrné struktury tvořené záhlavím a tělem. Jejich sloupce se nazývají atributy, řádky tabulky jsou pak záznamy. Atributy mají určen svůj konkrétní datový typ a doménu, což je množina přípustných hodnot daného atributu. Řádek je řezem přes sloupce tabulky a slouží k vlastnímu uložení dat.

Pojem „relační databáze“ souvisí s teorií množin. Každá konkrétní tabulka totiž realizuje podmnožinu kartézského součinu množin přípustných hodnot všech sloupců – relaci.

Kandidátní klíč

Kandidátní klíč je atribut nebo skupina atributů, které jednoznačně identifikují záznam v relační tabulce. Kandidátní klíč se může stát primárním klíčem; ty, které se primárním klíčem nestanou, jsou označovány jako alternativní klíče. Např. v relaci Zaměstnanec, která má atributy číslo_zaměstnance, rodné_číslo, jméno a příjmení, jsou kandidátními klíči atributy číslo_zaměstnance a rodné_číslo. Pokud primárním klíčem zvolíme číslo_zaměstnance, alternativním klíčem bude rodné_číslo a naopak.

Primární klíč

Primární klíč je jednoznačný identifikátor záznamu, řádku tabulky. Primárním klíčem může být jediný sloupec či kombinace více sloupců tak, aby byla zaručena jeho jednoznačnost. Pole klíče musejí obsahovat hodnotu, tzn. nesmí se zde vyskytovat nedefinovaná prázdná hodnota NULL. V praxi se dnes často používají umělé klíče, což jsou číselné či písmenné identifikátory – každý nový záznam dostává identifikátor odlišný od identifikátorů všech předchozích záznamů (požadavek na unikátnost klíče), obvykle se jedná o celočíselné řady a každý novější záznam dostává číslo vždy o jednotku vyšší (zpravidla zcela automatizovaně) než je číslo u posledního vloženého záznamu (číselné označení záznamů s časem stoupá).

Cizí klíč

Dalším důležitým pojmem jsou nevlastní/cizí klíče. Slouží pro vyjádření vztahů, relací, mezi databázovými tabulkami. Jedná se o pole či skupinu polí, která nám umožní identifikovat, které záznamy z různých tabulek spolu navzájem souvisí.

Integrita databáze

Integrita databáze znamená, že data v ní uložená jsou konzistentní vůči definovaným pravidlům. Lze zadávat pouze data, která vyhovují předem definovaným kritériím (např. musí respektovat datový typ nastavený pro daný sloupec tabulky, či další omezení hodnot přípustných pro daný sloupec). K zajištění integrity slouží integritní omezení. Jedná se o nástroje, které zabrání vložení nesprávných dat či ztrátě nebo poškození stávajících záznamů v průběhu práce s databází. Typicky je možné zajistit mazání dat, která již ztratila svůj význam (kupř. smažeme-li uživatele z tabulky uživatelů, odstraní se i na něj navázané záznamy v ostatních databázových tabulkách).

Druhy integritních omezení

• Entitní integritní omezení – někdy je mylně považováno za pouhé omezení primárního klíče tabulky (jež má zamezit uložení dat, která neobsahují všechna pole sdružená do klíče, nebo data, jež by v těchto polích byla stejná jako v nějakém jiném, již zapsaném, řádku tabulky). Ve skutečnosti jde o to, aby o jedné entitě nebylo možno do databáze vložit duplicitní záznamy; jedná se tedy o zajištění unikátnosti skutečných identifikátorů reálných objektů (což například umělé automaticky generované ID nezajistí).
• Doménová integritní omezení – zajišťují dodržování datových typů/domén definovaných sloupcům databázové tabulky.
• Aktivní referenční integrita – definují činnosti, které databázový systém provede, pokud jsou porušena některá pravidla.
• Referenční integritní omezení – zabývají se vztahy dvou tabulek, kde jejich relace je určena vazbou primárního a cizího klíče.

Dodržování integritních omezení

V zásadě existují tři způsoby, jak zajistit dodržování integritních omezení.

1. umístění jednoduchých mechanismů pro dodržování integritních omezení na straně databázového serveru. Jedná se o nejlepší způsob z hlediska ochrany dat. Uživateli však obvykle přináší delší odezvu systému a nelze vždy zajistit jejich přenositelnost na jiný databázový systém.
2. umístění ochranných mechanismů na straně klienta. Pro komfort a nezávislost na databázovém systému je nejlepší volbou. Nutnost kontrolních mechanismů pro každou operaci může způsobit chyby u aplikací a v případě většího počtu aplikací je potřeba je opravit na více místech.
3. samostatné programové moduly na straně serveru. V moderních databázových systémech jsou pro tento účel implementovány tzv. triggery. Jedná se o samostatné procedury, které lze spouštět automatizovaně před a po operacích manipulujících s daty. Tento způsob umožňuje implementaci i složitých integritních omezení. Nevýhody opět přináší provádění na serveru, i velmi omezená možnost přenesení na jiný databázový systém.

Možná je i kombinace předchozích variant v závislosti na konkrétních podmínkách.

Kontroly integritních omezení se zpravidla provádějí po každé provedené operaci, což snižuje nároky na server. Není nutno nijak zaznamenávat, které kontroly mají být provedeny později. Složitější integritní omezení však vždy nelze takto ověřit, proto je možné kontrolovat dodržení pravidel až po dokončení celé transakce.

Vztahy mezi tabulkami

Vztahy (angl. relationships) slouží ke svázání dat, která spolu souvisejí a jsou umístěny v různých databázových tabulkách. Každý vztah je charakterizován třemi základními vlastnostmi:

• stupněm,
• kardinalitou,
• parcialitou.

Stupeň vztahu

1. Unární vztah – relace je spojena sama se sebou. Typickým příkladem je vztah zaměstnance a jeho nadřízeného, kdy nadřízený je také jedním ze zaměstnanců, pročež také může mít nadřízeného. Vztah se realizuje vložením primárního klíče relace zaměstnanec ve formě cizího klíče opět do relace zaměstnanec.
2. Binární vztah – vztah mezi dvěma relacemi.
3. Ternární vztah – vztah mezi třemi relacemi najednou.
4. N-ární vztah – vztah mezi n-relacemi zároveň.

Ternární a n-ární vztahy se nesnadno modelují a v praxi se objevují velice zřídka.

Kardinalita vztahu

Kardinalita vztahu je maximální počet vztahů instancí, kterých se může entita účastnit.

1. Mezi daty v tabulkách není žádná spojitost, proto nedefinujeme žádný vztah.
2. 1:1 používáme, pokud záznamu odpovídá právě jeden záznam v jiné databázové tabulce a naopak. Takovýto vztah je používán pouze ojediněle, protože většinou není pádný důvod, proč takovéto záznamy neumístit do jedné databázové tabulky. Jedno z mála využití je zpřehlednění rozsáhlých tabulek. Jako ilustraci je možné použít vztah řidiče a automobilu – v jednu chvíli (diskrétní časový okamžik) jeden řidič řídí právě jeden automobil a zároveň jeden automobil je řízen právě jedním řidičem.
3. 1:N přiřazuje jednomu záznamu více záznamů z jiné tabulky. Jedná se o nejpoužívanější typ relace, jelikož odpovídá mnoha situacím v reálném životě. Jako reálný příklad může posloužit vztah autobusu a jím cestujícího pasažéra – v jednu chvíli pasažér jede právě jedním autobusem a v jednom autobuse může zároveň cestovat více pasažérů.
4. M:N umožňuje každému záznamu z jedné tabulky přiřadit libovolný počet záznamů z druhé tabulky, přičemž záznam v druhé tabulce přiřazením k záznamu k první tabulce svou možnost přiřazení „nespotřebuje“, takže jej lze přiřadit k libovolnému počtu záznamů první tabulky. V databázové praxi bývá tento vztah z praktických důvodů nejčastěji realizován kombinací dvou vztahů, a sice 1:N a 1:M, které ukazují do pomocné tabulky, složené z kombinace obou použitých klíčů (jde o třetí, resp. tzv. vazební tabulku). Příkladem z reálného života by mohl být vztah výrobku a jeho vlastnosti – výrobek může mít více vlastností a jednu vlastnost může mít více výrobků. Dalším příkladem je vztah herce a filmu – jeden herec může hrát ve více filmech a v jednom filmu může hrát více herců. M:N je v reálném životě obecně méně častým vztahem, při poněkud odlišném pohledu však existuje velké množství vztahů M:N; to mj. také proto, že často existuje praktická potřeba zachovávat i údaje o historii relačních vztahů (každý jeden řidič za minulost a přítomnost mohl řídit více rozličných automobilů a za volantem každého jednoho automobilu se mohlo vystřídat více řidičů).

Parcialita vztahu

Parcialita vyjadřuje, zda je účast entity ve vztahu povinná nebo volitelná. Jinými slovy, parcialita určuje minimální počet vztahů (0 nebo 1). Povinnost se realizuje pomocí integritního omezení NOT NULL. Při převodu z E-R modelu se ale některé informace o parcialitě ztrácí.

Normální formy

Pod pojmem normalizace rozumíme proces zjednodušování a optimalizace navržených struktur databázových tabulek. Hlavním cílem je navrhnout databázové tabulky tak, aby vykazovaly minimum redundance (opakování stejné informace na více místech). Správnost navržení struktur v tomto smyslu lze ohodnotit některou z následujících normálních forem:

• Nultá normální forma (0NF) – tabulka obsahuje alespoň jeden sloupec (atribut); tento může obsahovat více druhů hodnot.
• První normální forma (1NF) – žádný sloupec (atribut) tabulky nelze dále dělit na části nesoucí nějakou informaci, jinými slovy prvky musí být atomické (žádný sloupec neobsahuje složené hodnoty).
• Druhá normální forma (2NF) – tabulka obsahuje pouze atributy (sloupce), které jsou závislé na celém klíči.
• Třetí normální forma (3NF) – mezi neklíčovými atributy (sloupci) tabulky neexistují žádné závislosti (vztahy).
• Čtvrtá normální forma (4NF) – každý sloupec (atribut) tabulky popisuje pouze jeden fakt nebo jednu souvislost.
• Pátá normální forma (5NF) – tabulka je ve stavu, že přidáním libovolného nového sloupce (atributu) by se rozpadla na více tabulek.

Nultou normální formu (0NF) splňuje každá tabulka.

Příklady (relačních) databází

• Microsoft Access
• MySQL
• MariaDB
• PostgreSQL
• Oracle
• Microsoft SQL Server
• SQLite
• Firebird

Odkazy

Související články

• Edgar Frank Codd

Externí odkazy

• Relační databáze v České terminologické databázi knihovnictví a informační vědy (TDKIV)
• Článek na Root.cz - historie databází
• Článek na Programujte.com - Úvod do relačních databází
• Jiří Kosek: Co je to databáze
• Online kurz zdarma na Distančně.cz - Relační databáze a dotazovací jazyk SQL