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:

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:

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