Úvod do databázových systémů Databáze je dnes velmi často skloňovaným slovem. Co se pod tímto termínem skrývá si vysvětlíme na několika následujících stranách a cvičeních. Databáze se využívají k ukládání dat, většinou textové povahy, slouží k rychlému vyhledávání informací podle zadaných kritérií. Využívají se v širokém spektru různých aplikací, od samostatně běžících programů (například účetní programy) po velmi rozsáhlé webové projekty, které rovněž houfně využívají databáze. Databáze je rovněž realizována nějakou aplikací je sama programem, a abychom jí mohli využívat, musí být nainstalována a spuštěna. Těmto aplikacím, které jsou sami databázemi říkejme databázové stroje. Nejznámější z nich jsou: MySQL MS SQL (Microsoft SQL) Oracle DBMS Postgre SQL IBM DB2 Data v databázi se ukládají do tabulek. Tabulka je ve světě databází velmi důležitý objekt, protože skrze něj se popisuje nějaký reálný prvek světa (jeho vlastnosti). Tomuto prvku budeme od této chvíle říkat entita. Vlastnostem těchto prvků (entit) pak říkejme atributy. Příklad: reálným prvkem světa je město. Město má své vlastnosti jako je název, počet obyvatel, PSČ, telefonní předvolba. To jsou právě jeho atributy. Mohli bychom tedy vytvořit tabulku města, její sloupce by tvořily zmíněné atributy a v řádcích by byla zapsána jednotlivá města. Příklad obecné databáze je na obrázku níže. Jednalo by se patrně o databázi objednávek.
Výše uvedený příklad databáze ale není nejlepší. Popravdě je zcela špatně a porušuje několik pravidel pro vytváření databází. Těmto pravidlům budeme říkat NORMÁLNÍ FORMY, těch je několik a postupně si projdeme první tři z nich. 1. Normální forma Aby databáze splňovala první normální formu je nutné, aby atributy databáze byly atomické tedy dále nedělitelné, čímž je umožněno snadné filtrování a vyhledávání dat. Příklad je uveden na obrázku: Na chvíli odbočme od normálních forem a uvažujme. Na obrázku je znázorněna databáze osob, které bydlí v určitých městech. Není zbytečné u každého obyvatele evidovat název města a PSČ? Tato data se budou velmi často opakovat a zabírat naprosto zbytečně místo. Navíc je to potenciální zdroj chyb (plzeň Plzeň plzen jsou přece různé údaje). Tuto tabulku by bylo vhodné rozdělit na dvě tedy dejme tomu: osoby a města a vzájemně je propojit s pomocí identifikátorů. Označme proto Jana Nováka nějakým Identifikátorem 1, Petra Nového identifikátorem 2 a tak dále. Město Prahu rovněž identifikátorem 1, Brno identifikátorem 2 atd. Nyní přichází ono zjednodušení. Osoba s ID 1 bydlí ve městě s ID 1, osoba s ID 2 bydlí ve městě s ID 2, osoba s ID 3 bydlí ve městě s ID 3. V tabulce může být uložen další člověk žijící v Praze, třeba Jana Dvořáková tedy osoba s ID 4 bydlí ve městě s ID 1. Je vidět, že mezi entitami jsou určité vztahy a než přistoupíme k dalším normálním formám, vysvětleme si napřed různé typy těchto vztahů.
Vazby mezi entitami Mezi entitami se s rozdělením do jednotlivých tabulek vytvoří určité vazby. V odborné terminologii se těmto vazbám říká kardinality. Mohou to být celkem 3 typy: Jedné položce v tabulce1 odpovídá PRÁVĚ JEDNA položka z tabulky2 kardinalita 1:1 Jedné položce v tabulce1 odpovídá libovolné množství položek z tabulky2 kardinalita 1:N Libovolnému množství položek v tabulce1 odpovídá libovolné množství položek z tabulky2 kardinalita M:N Identifikátory Již zmíněné identifikátory jsou ve většině případů uměle vytvořené vlastnosti (atributy) nějakého objektu (entity), které slouží k jeho jednoznačné identifikaci. S jejich pomocí tedy není možné zaměnit jedno město za druhé, jednu osobu za jinou. Identifikátor je pro danou věc naprosto jedinečný a tvoří tzv. primární klíč. Pokud nechceme vytvářet identifikátory uměle, musíme vybrat vhodný atribut, který by mohl jednoznačně popsat položku databáze. Například rodné číslo může být dobrý primární klíč pro osoby. Číslo faktury může být dobrý primární klíč pro databázi (tabulku) faktur a tak podobně. Primární klíč může být i n-tice položek. Dejme tomu, že Jméno + Příjmení + Ulice + + Město může identifikovat jednoznačně nějakou osobu. Tedy pouze za předpokladu, že v daném městě a ulici nebydlí dvě osoby stejného jména a příjmení (což se ale běžně stává ) 2. Normální forma Druhá normální forma říká, že každý atribut, který není primárním klíčem, je na primárním klíči úplně závislý. Tento požadavek je u většiny tabulek splněn triviálně a týká se pouze tabulek se složeným primárním klíčem.
3. Normální forma Třetí normální forma databáze je nejpodstatnější. Díky ní nedochází k nežádoucímu opakování dat. Říká, že databáze splňuje 3.NF právě tehdy, když splňuje 2.NF a žádný atribut, který není primárním klíčem není tranzitivně závislý. Pojem tranzitivní závislost vám může znít jako zaklínadlo, ale zkusme ho vysvětlit. Pokud, pak platí, že. Říkáme, že C je tranzitivně závislé na A (skrze B). Zde bude opět nejlepší příklad: Na obrázku vidíme tabulku, kde ID osoby určuje funkci a plat. V reálném světě je ale plat závislý na funkci a jedná se právě o případ tranzitivní závislosti. Plat je skrze funkci závislý na čísle osoby. Tato tabulka tedy nesplňuje třetí normální formu, data se v ní zbytečně opakují a je nutné databázi opravit a převést ji do správného tvaru. Správný tvar bude vypadat tak, že vytvoříme novou další tabulku, která bude obsahovat dvě položky: funkce a plat. Mezi tabulkami zaměstnanců a funkcí bude existovat nějaká vazba. Tomuto úkonu se říká dekompozice do více tabulek. Nesplnění normálních forem obvykle doprovází redundance dat!
Datové typy atributů Při vytváření reálných databází musíme dopředu přemýšlet, jaká data budou obsažena v jakých atributech. Zda budou obsahovat text, datum, čas, logickou hodnotu. Toto určení bude zamezovat možným chybám v databázi a ulehčovat vkládání a vyhledávání dat. Datové typy budou závislé na použitém databázovém stroji a velmi připomínají datové typy proměnných využívaných při programování. Jmenujme některé: Char(x) Text určité délky Varchar(x) Text určité délky Date/Time/Datetime Integer/Smallint/Bigint Double/Real Boolean Binary/Varbinary AutoIncrement U atributů také bývá zvykem uvést, zda musí být povinně vyplněn, nebo ne tedy zda je tzv. null nebo not null.