Dosti bylo na našem portálu koncertů. Dejme tomu, že toto téma máme již uspokojivě vyřešeno, a pojďme se věnovat dalším věcem. Bude to ztvárnění diskografie.
Alba a písně
Připomeňme, že portál by měl být schopen následujících věcí:
- Názvy alb a písní by se měly zadat do databáze
- Půjdou zobrazit buď jen alba, nebo alba a písně
- Vyhledávání - podle názvu písně najít album nebo alba, na nichž
byla uvedena
- Jedna píseň bude moci být na více albech
To nás vede k závěru, že budeme muset přidat další tabulky do
databáze (zatím tam máme jen tabulku pro uživatele a tabulku pro
koncerty). Kromě toho, že budeme muset přidat tabulky, musíme si
rozmyslet jaké a jak na sebe budou navazovat. Tabulka uživatelů a
tabulka koncertů totiž byly na svém okolí relativně nezávislé, zatímco
tabulky s alby, písněmi a také s texty písní budou vzájemně záviset.
Již jsme o tom mluvili v díle o uložení dat
v databázi. Na
takovou situaci platí staré české přísloví:
Dvakrát měř, jednou řež
Uvědomme si, že špatně navržená databáze obyčejně aplikaci pohřbí.
Začátečník by mohl například uvažvat takto: Máme alba, na každém albu
budou nějaké písně. Založíme tedy tabulku alb a tabulku písní, a u
každé písně bude odkaz na album, na němž je uvedena. Dalo by se to
graficky znázornit takto:
A zhruba tomu odpovídající definice tabulek by mohla být:
CREATE TABLE alba (
id int NOT NULL auto_increment,
nazev varchar(50) NOT NULL default '',
PRIMARY KEY (id)
);
CREATE TABLE pisne (
id int NOT NULL auto_increment,
album int NOT NULL default 0,
nazev varchar(50) NOT NULL default '',
PRIMARY KEY (id)
);
Na první pohled to vypadá dobře. Co se však stane, jestliže bude
jedna píseň na více albech? V tom případě naše koncepce selže, protože
nebudeme vědět, co napsat do sloupce album. Jistě, dalo by se pro
stejnou píseň přidat více řádků, ale to má několik nevýhod - duplikují
se data v tabulce a nastane problém s přidáváním textů písní.
Musíme tedy na celou věc jinak. Jelikož může být více písní na
jednom albu a zároveň jedna píseň na více albech, bude potřeba
sestrojit třetí tabulku, která tuto situaci postihne. Můžeme ji nazvat
třeba "obsahyalb" a schéma pak bude následující:
A tomu odpovídající definice tabulek bude tato:
CREATE TABLE alba (
id int NOT NULL auto_increment,
nazev varchar(50) NOT NULL default '',
PRIMARY KEY (id)
);
CREATE TABLE obsahyalb (
id int NOT NULL auto_increment,
album int NOT NULL default 0,
pisen int NOT NULL default 0,
PRIMARY KEY (id)
);
CREATE TABLE pisne (
id int NOT NULL auto_increment,
nazev varchar(50) NOT NULL default '',
PRIMARY KEY (id)
);
Něco názvosloví
Kdybyste se chtěli zabývat světem databází trochu do hloubky, možná
se Vám bude následujících pár řádků. To, co jsme demonstrovali na
albech a písních se vznešeně nazývá "návrh
struktury databáze". Vztahům mezi alby a písněmi se odborně říká
relace (odtud relační
databáze). V našem prvním příkladu se jednalo o tzv. relaci 1:N, neboli "jeden k mnoha".
Popisuje to situaci, kdy jednomu "rodičovskému" záznamu odpovídá
teoreticky neomezený počet "dceřinných" záznamů. Tato situace je celkem
běžná - jedna faktura může více položek, jeden tým může sehrát více
zápasů, v jednom bytě může bydlet více lidí.
Ve druhém případě se jednalo o tzv. relaci N:N (mnoho k mnoha). Tato
relace se obvykle vyjadřuje vloženou tabulkou, tak jak jsme to udělali
v našem případě. I ta je v reálném svěce celkem běžná: Více písní na
více albech, můžete montovat různá auta ze stejných součástek (tedy
jedna součástka ve více autech a zároveň více součástek v jednom autě)
a tak dále.
Někomu by se mohlo zdát, že vložení té "prostřední" tabulky celou
databázi zpomalí. Většinou to tak není, protože databázový software
bývá na podobné zpracování (které nazýváme tvorba spojení) vysoce
optimalizován. Rovněž odstraňování záznamů je v takovém případě výrazně
zjednodušeno.
Pozn.: U alb a písní to není moc
dobrý příklad, ale třeba u těch aut a součástek ano. Pokud byste totiž
z nějakých důvodů přestali do daného auta montovat danou součástku
(protože byla dejme tomu zbytečná), stačí odstranit záznam z té
"prostřední" tabulky a je to!
V dalším díle se zaměříme zpátky na náš portál a uplatníme relace v praxi