|
1. Formulace úkolů a cílů
| Formulací úkolu se rozumí formulace účelu databáze. Měla by být stručná a věcná. Cíle úkolu jsou tvrzením, které
reprezentuje obecné úkoly podporované daty uloženými v databázi. V první fázi se tak shromažďují data potřebná k následnému
návrhu a je zde třeba hlavně analýza požadavků a rozhovory se zadavatelem (v případě možnosti i budoucími uživateli). |
2. Analýza existující databáze
| Následuje analýza současné databáze. Nemusí se jednat o databázi digitální, často se jedná i o formu papírovou. Analýza
napomůže k odhalení případných vad struktur a zjištění, zdali databáze podporuje současné požadavky. Výstupem této fáze je
seznam polí (atributů) uchovávaných v databázi. |
3. Vytváření datových struktur
-
Zřízení struktur a tabulek – Vytváření seznamu tabulek a přiřazení atributů. Důležité je dbát na správná
pojmenování - jednoznačné a pro všechny srozumitelné názvy, využívající co nejmenšího počtu slov a nepoužívání
akronymů či zkratek.
-
Primární Klíče – pomáhají jasně identifikovat záznam v tabulce a zajištují integritu na úrovni tabulky.
-
Specifikace polí – zahrnuje mimo jiné název, popis, datový typ, délku, povolené znaky, formát a možnost ukládání
prázdných hodnot.
|
4. Vztahy mezi tabulkami
V tomto kroku dochází k vytváření logických spojení mezi tabulkami. To napomáhá k minimalizaci redundantních dat a je
díky tomu možné v aplikaci načítat data najednou z více tabulek.
Existují tři typy vztahů: 1:1, 1:N a M:N. Jsou rozlišeny jednak funkčností, ale i implementací. Nejčastější typ vztahu
je 1:N „Z pohledu integrity se jedná o nejdůležitější druh vztahu, protože umožňuje eliminovat duplicitní data a udržet
redundantní data na absolutním minimu“ (Hernandez, 2006, s. 229). Při implementaci vztahu 1:1 a 1:N se využívá
propojení tabulek pomocí primárního a cizího klíče. V případě vtahu M:N se pak využívá vazební tabulky, která vztah
rozdělí na dva typu 1:N.
U definovaných vztahů je dále třeba určit jejich charakteristiku. Jedná se o určení typu a stupně účasti (povinnost
existence záznamu v protilehlé tabulce). Také se definují pravidla v případě smazání záznamu z rodičovské tabulky.
Existuje několik možností, jak se s mazáním vypořádat – nejpoužívanější volbou je buď nemožnost smazání záznamu, pokud
existuje související v dceřiné tabulce, či volba tzv. kaskády, kde jsou automaticky smazány záznamy v dceřiných
tabulkách. Další možnosti je pak nastavení hodnoty null, implicitní hodnoty, nebo žádnou akci ani kontrolu neprovádět.
|
5. Určení a definování business pravidel
| Business pravidla jsou omezení vyplývající z analýzy pro atributy či vtahy. Některá pravidla lze implementovat na úrovni
databáze – např. seznamy přípustných hodnot pro jednotlivá pole (obvykle řešeno pomocí číselníků). Jiná se musí zpracovávat
až na úrovni aplikace – např. kontrola, aby zadávaná hodnota do jednoho sloupce byla vždy vyšší než ve sloupci druhém. |
6. Určení a definování pohledů
| Pohled je virtuální tabulka, která se skládá z polí jedné, či několika tabulek databáze. Je vhodné ho využít, pokud
aplikace často zobrazuje data z více tabulek, nebo je v aplikaci více uživatelů, kterým se mají data zobrazit jinak. Dále
je možné v pohledu definovat tzv. vypočítaná pole, která slučují data z existujících tabulek podle zadaného vzorce. Tuto
funkčnost je samozřejmě možné implementovat až na úrovni aplikace, obvykle je však implementace na úrovni databáze
rychlejší. |
7. Kontrola integrity dat
| Poslední fáze návrhu databáze, ve které je doporučeno přezkoumat ještě jednou celou integritu databáze. Je doporučen
modulární přístup – postupně projít všechny části celkové integrity: integritu na úrovni tabulek, polí, vztahů a business
pravidel. |
|
