Správne navrhnutá databáza poskytuje prístup k aktuálnym a presným informáciám. Keďže správny návrh databázy je nevyhnutný na dosiahnutie cieľov, ktoré si pre prácu s databázou vytýčite, je užitočné investovať čas do štúdia princípov správneho návrhu. Zvýši sa tým pravdepodobnosť, že databáza bude spĺňať vaše požiadavky a ľahko sa prispôsobí zmenám.
Tento článok poskytuje pokyny na plánovanie databázy. Naučíte sa rozhodnúť, ktoré informácie sú potrebné, ako tieto informácie rozdeliť do príslušných tabuliek a stĺpcov a ako tieto tabuľky navzájom spojiť. Tento článok si prečítajte predtým, ako vytvoríte svoju prvú počítačovú databázu.
Obsah článku
Niekoľko databázových výrazov, ktoré treba poznať
Access usporadúva informácie do tabuliek: zoznamov riadkov a stĺpcov pripomínajúcich účtovnícky blok alebo tabuľkový hárok. V jednoduchej databáze možno budete mať len jednu tabuľku. Vo väčšine databáz ich však budete potrebovať viacero. Môžete mať napríklad tabuľku, v ktorej sú uložené informácie o produktoch, ďalšiu tabuľku, v ktorej sú uložené informácie o objednávkach, a ďalšiu tabuľku s informáciami o zákazníkoch.
Každý riadok sa správnejšie nazýva záznam a každý stĺpec sa nazýva pole. Záznam je zmysluplný a konzistentný spôsob kombinovania informácií o určitej skutočnosti. Pole je jednotlivá položka informácie – typ položky, ktorý sa nachádza v každom zázname. V tabuľke Produkty napríklad každý riadok alebo záznam obsahuje informácie o jednom produkte. Každý stĺpec alebo pole obsahuje nejaký druh informácií o danom produkte, napríklad jeho názov alebo cenu.
Čo je dobrý návrh databázy?
Proces navrhovania databázy sa riadi určitými princípmi. Prvý princíp je, že duplicitné informácie (nazývané aj nadbytočné údaje) sú nežiaduce, pretože zaberajú priestor a zvyšujú pravdepodobnosť chýb a nekonzistentných položiek. Druhý princíp je, že je dôležitá správnosť a úplnosť informácií. Ak databáza obsahuje nesprávne informácie, nesprávne informácie budú zahŕňať aj zostavy, ktoré vyberú informácie z databázy. Výsledkom je, že rozhodnutia, ktoré urobíte na základe týchto zostáv, budú vychádzať z nesprávnych informácií.
Dobrý návrh databázy je preto taký, ktorý:
-
rozdeľuje informácie do tematických tabuliek, čím znižuje množstvo nadbytočných údajov,
-
poskytuje Accessu informácie, ktoré sú potrebné na spájanie informácií v tabuľkách podľa potreby,
-
pomáha podporiť a zabezpečiť presnosť a integritu informácií,
-
prispôsobuje sa vašim potrebám týkajúcim sa spracovania údajov a tvorby zostáv.
Proces navrhovania
Proces navrhovania sa skladá z týchto krokov:
-
Stanovenie účelu databázy
Tento krok vám pomôže pripraviť sa na ostatné kroky.
-
Vyhľadanie a usporiadanie požadovaných informácií
Zhromaždite všetky informácie, ktoré chcete zaznamenať do databázy, napríklad názov produktu a číslo objednávky.
-
Rozdelenie informácií do tabuliek
Informačné položky rozdeľte do hlavných celkov alebo predmetov, ako sú napríklad Produkty alebo Objednávky. Každý predmet sa stane tabuľkou.
-
Premena informačných položiek na stĺpce
Rozhodnite sa, ktoré informácie chcete uložiť do jednotlivých tabuliek. Každá položka sa stane poľom a zobrazí sa ako stĺpec v tabuľke. Napríklad tabuľka Zamestnanci môže obsahovať polia ako Priezvisko a Dátum nástupu.
-
Stanovenie primárnych kľúčov
Vyberte primárny kľúč každej tabuľky. Primárny kľúč je stĺpec, ktorý sa používa na jednoznačnú identifikáciu každého riadka. Môže to byť napríklad ID produktu alebo ID objednávky.
-
Nastavenie vzťahov medzi tabuľkami
Pozrite sa na každú tabuľku a rozhodnite, ako údaje v jednej tabuľke súvisia s údajmi v ďalších tabuľkách. Podľa potreby do tabuliek pridajte polia alebo vytvorte nové tabuľky na objasnenie vzťahov.
-
Optimalizácia návrhu
Analyzovaním návrhu v ňom vyhľadajte prípadné chyby. Vytvorte tabuľky a pridajte do nich niekoľko záznamov vzorových údajov. Zistite, či sa z tabuliek dajú získať požadované údaje. Upravte návrh podľa potreby.
-
Použitie pravidiel normalizácie
S použitím pravidiel normalizácie údajov zistite, či sú tabuľky správne štruktúrované. Upravte tabuľky podľa potreby.
Stanovenie účelu databázy
Odporúča sa zapísať účel databázy na papier – jej účel, ako ju budete očakávať a kto ju bude používať. V prípade malej databázy pre domácu firmu môžete napríklad napísať niečo jednoduché, napríklad "Databáza zákazníkov uchováva zoznam informácií o zákazníkoch na účely vytvárania poštových správ a zostáv." Ak je databáza zložitejšia alebo ju používajú mnohí ľudia, ako sa to často stáva v podnikovom nastavení, účelom môže byť jednoducho odsek alebo viac a mal by obsahovať, kedy a ako bude každá osoba databázu používať. Cieľom je mať dobre vyvinuté poslanie, na ktoré možno odkazovať počas celého procesu navrhovania. Takéto vyhlásenie vám pomôže sústrediť sa na ciele pri rozhodovaní.
Vyhľadanie a usporiadanie požadovaných informácií
Pri vyhľadávaní a usporadúvaní požadovaných informácií začnite s existujúcimi informáciami. Je napríklad možné, že si vediete záznamy o nákupných objednávkach v účtovnej knihe alebo informácie o zákazníkoch v papierových formulároch v kartotékach. Zhromaždite tieto dokumenty a vytvorte zoznam všetkých typov zobrazených informácií (napríklad každé políčko, ktoré vypĺňate vo formulári). Ak nemáte existujúce formuláre, predstavte si, že musíte vytvoriť formulár na zaznamenanie informácií o zákazníkoch. Aké informácie by ste dali do formulára? Aké polia na vyplnenie by ste vytvorili? Identifikujte všetky tieto položky a vytvorte ich zoznam. Predpokladajme napríklad, že v súčasnosti máte zoznam zákazníkov na kartotékových lístkoch. Preskúmaním týchto lístkov môžete zistiť, že každý lístok obsahuje meno zákazníka, adresu, mesto, štát, PSČ a telefónne číslo. Každá z týchto položiek predstavuje potenciálny stĺpec v tabuľke.
Pri príprave tohto zoznamu si nerobte starosti z toho, či bude hneď na prvýkrát bezchybný. Naopak, uveďte do neho každú položku, ktorá vám napadne. Ak budú databázu používať aj iní, požiadajte o svoje nápady aj ich. Zoznam budete môcť doladiť neskôr.
Zvážte typy zostáv alebo korešpondencie, ktoré budete vytvárať z databázy. Je napríklad možné, že budete chcieť vytvoriť zostavu predaja produktov zobrazujúcu predaj podľa oblasti alebo súhrnnú skladovú zostavu zobrazujúcu úrovne zásob produktov. Možno tiež budete chcieť vytvoriť formulárové listy zasielané zákazníkom, ktoré oznamujú predajné akcie alebo ponúkajú prémiu. Vytvorte si v mysli návrh zostavy a predstavte si, ako by mala vyzerať. Aké informácie by ste dali do zostavy? Zapíšte do zoznamu každú položku. Urobte to isté s formulárovým listom alebo každou ďalšou zostavou, ktorú plánujete vytvoriť.
Uvažovanie o zostavách a korešpondencii, ktoré možno budete chcieť vytvoriť, vám pomáha identifikovať položky, ktoré budete potrebovať v databáze. Predpokladajme napríklad, že poskytnete zákazníkom možnosť prihlásiť sa na odber pravidelných e-mailových aktualizácií (alebo tento odber zrušiť) a chcete vytlačiť zoznam tých, ktorí sa rozhodli prihlásiť. Ak chcete zaznamenať túto informáciu, do tabuľky zákazníkov pridáte stĺpec Odoslať e-mail. Pole pre každého zákazníka môžete nastaviť na možnosť Áno alebo Nie.
Požiadavka na odosielanie e-mailových správ zákazníkom je podnetom na zaznamenanie ďalšej položky. Keď už viete, že zákazník chce dostávať e-mailové správy, budete tiež potrebovať poznať e-mailovú adresu, na ktorú ich odosielať. Preto budete potrebovať zaznamenať e-mailovú adresu každého zákazníka.
Je vhodné vytvoriť prototyp každej zostavy alebo zoznamu výstupov a zvážiť, ktoré položky budete potrebovať na vytvorenie zostavy. Keď napríklad preskúmate formulárový list, môže nastať niekoľko vecí. Ak chcete zahrnúť správne oslovenie, napríklad reťazec "Pán", "Pani" alebo "Pani", ktorý začína pozdravom, budete musieť vytvoriť položku oslovenia. Okrem toho môžete zvyčajne začať list s textom Vážený pán Kováč, a nie s textom Vážený. Pán Sylvester Smith". To naznačuje, že by ste zvyčajne chceli uložiť priezvisko oddelene od krstného mena.
Kľúčové je pamätať na to, že každú informáciu je vhodné rozdeliť na čo najmenšie užitočné časti. Ak ide napríklad o meno a chcete, aby bolo priezvisko okamžite dostupné, rozdeľte meno do dvoch častí – na krstné meno a priezvisko. Mať uložené priezvisko zákazníka osobitne je užitočné napríklad vtedy, keď chcete zoradiť zostavu podľa priezviska. Vo všeobecnosti platí, že ak chcete zoraďovať, hľadať, vykonávať výpočty alebo vytvárať zostavy na základe určitej informačnej položky, je potrebné túto položku umiestniť do vlastného poľa.
Zamyslite sa nad otázkami, na ktoré má databáza poskytovať odpovede. Napríklad: aký bol predaj vášho hlavného produktu v minulom mesiaci? Kde žijú vaši najlepší zákazníci ? Kto je dodávateľom vášho najpredávanejšieho produktu? Predvídanie týchto otázok pomôže určiť, ktoré ďalšie položky je potrebné zaznamenať.
Po zhromaždení týchto informácií ste pripravení na ďalší krok.
Rozdelenie informácií do tabuliek
Ak chcete rozdeliť informácie do tabuliek, vyberte hlavné celky alebo predmety. Napríklad po vyhľadaní a usporiadaní informácií pre databázu predaja produktov môže predbežný zoznam vyzerať takto:
Hlavnými celkami zobrazenými v tomto príklade sú produkty, dodávatelia, zákazníci a objednávky. Preto je vhodné začať s týmito štyrmi tabuľkami: jedna pre údaje o produktoch, jedna pre údaje o dodávateľoch, jedna pre údaje o zákazníkoch a jedna pre údaje o objednávkach. Aj keď nejde o úplný zoznam, je to vhodný východiskový bod. Môžete pokračovať v optimalizovaní tohto zoznamu dovtedy, kým nebudete mať dobre fungujúci návrh.
Pri prvom prezeraní predbežného zoznamu položiek vás možno bude lákať umiestniť ich všetky do jednej tabuľky namiesto štyroch, ktoré sú zobrazené na predchádzajúcom obrázku. Tu si vysvetlíme, prečo to nie je dobrý nápad. Pouvažujte chvíľu nad touto tabuľkou:
V tomto prípade každý riadok obsahuje informácie o produkte a jeho dodávateľovi. Keďže môžete mať veľa produktov od toho istého dodávateľa, informácie o mene a adrese dodávateľa sa musia veľakrát opakovať. To zbytočne zaberá miesto na disku. Omnoho lepším riešením je zaznamenať informácie o dodávateľovi iba raz do samostatnej tabuľky Dodávatelia a potom prepojiť túto tabuľku s tabuľkou Produkty.
Druhý problém s týmto návrhom vzniká, keď potrebujete upraviť informácie o dodávateľovi. Predpokladajme napríklad, že potrebujete zmeniť adresu dodávateľa. Keďže sa objavuje na mnohých miestach, môže sa stať, že omylom adresu zmeníte na jednom mieste, no zabudnete ju zmeniť na iných miestach. Zaznamenaním adresy dodávateľa len na jednom mieste sa tento problém vyrieši.
Pri navrhovaní databázy sa vždy snažte zaznamenať každú skutočnosť len raz. Ak zistíte, že opakujete rovnakú informáciu na viacerých miestach, ako napríklad adresu určitého dodávateľa, umiestnite informáciu do samostatnej tabuľky.
Nakoniec predpokladajme, že spoločnosť Coho Winery dodáva iba jeden produkt a vy chcete produkt odstrániť, ale zachovať meno dodávateľa a informácie o adrese. Ako odstránite záznam o produkte bez toho, aby ste súčasne stratili aj informácie o dodávateľovi? Nedá sa to. Keďže každý záznam obsahuje údaje o produkte, ako aj údaje o dodávateľovi, nemožno odstrániť jedno bez odstránenia druhého. Ak chcete tieto údaje oddeliť, treba rozdeliť jednu tabuľku na dve: jednu tabuľku pre informácie o produkte a druhú tabuľku pre informácie o dodávateľovi. Odstránením záznamu o produkte sa odstránia iba údaje o produkte, nie údaje o dodávateľovi.
Po výbere predmetu, ktorý predstavuje tabuľka, by v stĺpcoch tejto tabuľky mali byť uložené iba údaje o danom predmete. Napríklad v tabuľke produktov by mali byť uložené len údaje o produktoch. Keďže adresa dodávateľa je údaj o dodávateľovi a nie údaj o produkte, patrí do tabuľky dodávateľov.
Premena informačných položiek na stĺpce
Ak chcete stanoviť stĺpce v tabuľke, rozhodnite sa, ktoré informácie o predmete zaznamenanom v tabuľke potrebujete sledovať. Vhodný východiskový zoznam stĺpcov pre tabuľku Zákazníci tvoria napríklad stĺpce Meno, Adresa, PSČ – mesto – štát, Odoslať e-mail, Oslovenie a E-mailová adresa. Každý záznam v tabuľke obsahuje rovnakú množinu stĺpcov, takže môžete uložiť údaj Meno, Adresa, PSČ – mesto – štát, Odoslať e-mail, Oslovenie a E-mailová adresa pre každý záznam. Stĺpec s adresou napríklad obsahuje adresy zákazníkov. Každý záznam obsahuje údaje o jednom zákazníkovi a pole s adresou obsahuje adresu tohto zákazníka.
Po určení počiatočnej množiny stĺpcov pre každú tabuľku môžete stĺpce ďalej spresniť. Má napríklad zmysel uložiť meno zákazníka ako dva samostatné stĺpce: krstné meno a priezvisko, aby ste mohli zoraďovať, vyhľadávať a indexovať len v týchto stĺpcoch. Podobne sa adresa v skutočnosti skladá z piatich samostatných súčastí, adresy, mesta, štátu, PSČ a krajiny/oblasti a má tiež zmysel ich uložiť do samostatných stĺpcov. Ak chcete napríklad vyhľadávať, filtrovať alebo zoraďovať podľa štátu, potrebujete informácie o stave uložené v samostatnom stĺpci.
Treba tiež zvážiť, či bude databáza obsahovať len informácie domáceho pôvodu, alebo aj informácie medzinárodného pôvodu. Ak napríklad plánujete ukladať medzinárodné adresy, je lepšie namiesto stĺpca Štát použiť stĺpec Oblasť, pretože tento stĺpec môže obsahovať ako domáce štáty, tak aj regióny iných krajín alebo oblastí. Podobne Poštové smerovacie číslo je vhodnejšie ako PSČ, ak plánujete ukladať medzinárodné adresy.
Nasledujúci zoznam obsahuje niekoľko tipov na stanovenie stĺpcov.
-
Nezahŕňajte vypočítané údaje.
Vo väčšine prípadov nie je vhodné uložiť do tabuliek výsledok výpočtov. Namiesto toho použite Access na vykonanie výpočtov vtedy, keď chcete vidieť nejaký výsledok. Predpokladajme napríklad, že existuje zostava Objednané produkty, ktorá zobrazuje medzisúčet objednaných jednotiek pre každú kategóriu produktov v databáze. V žiadnej tabuľke však neexistuje medzisúčtový stĺpec Objednané jednotky. Namiesto toho je v tabuľke Produkty zahrnutý stĺpec Objednané jednotky, v ktorom sú uložené objednané jednotky pre každý produkt. Access s použitím týchto údajov vypočíta medzisúčet vždy pri tlači zostavy. Samotný medzisúčet by nemal byť uložený v tabuľke.
-
Ukladajte informácie v najmenších logických častiach.
Možno vás bude lákať mať jedno pole pre celé mená alebo názvy produktov spolu s ich popisom. Ak v jednom poli skombinujete viaceré druhy informácií, je ťažké neskôr získať jednotlivé údaje. Snažte sa rozdeliť informácie na logické časti – vytvorte samostatné polia napríklad pre krstné meno a priezvisko alebo pre názov, kategóriu a popis produktu.
Po optimalizovaní stĺpcov s údajmi v jednotlivých tabuľkách ste pripravení vybrať primárny kľúč pre každú tabuľku.
Stanovenie primárnych kľúčov
Každá tabuľka by mala obsahovať stĺpec alebo množinu stĺpcov, ktoré jednoznačne identifikujú každý riadok uložený v tabuľke. Často je to jedinečné identifikačné číslo, ako napríklad identifikačné číslo zamestnanca alebo sériové číslo. V databázovej terminológii sa tento údaj nazýva primárny kľúč tabuľky. Access používa polia primárneho kľúča na rýchle priradenie údajov z viacerých tabuliek a spojenie týchto údajov.
Ak už máte jedinečný identifikátor tabuľky, napríklad číslo produktu, ktoré jednoznačne identifikuje každý produkt v katalógu, môžete použiť tento identifikátor ako primárny kľúč tabuľky — ale iba v prípade, že hodnoty v stĺpci budú vždy pre každý záznam odlišné. Primárny kľúč nesmie obsahovať duplicitné hodnoty. Ako primárny kľúč nepoužívajte napríklad mená ľudí, pretože mená nie sú jedinečné. Je celkom pravdepodobné, že môžete mať dvoch ľudí s rovnakým menom v rovnakej tabuľke.
Primárny kľúč musí mať vždy hodnotu. Ak hodnota stĺpca môže byť v určitom momente nepriradená alebo neznáma (chýbajúca hodnota), nemôže sa použiť ako komponent v primárnom kľúči.
Vždy je potrebné vybrať primárny kľúč, ktorého hodnota sa nemení. V databáze používajúcej viaceré tabuľky sa primárny kľúč tabuľky môže použiť ako odkaz v ďalších tabuľkách. V prípade zmeny tohto primárneho kľúča sa daná zmena musí použiť aj vo všetkých miestach, kde sa na kľúč odkazuje. Použitie nemenného primárneho kľúča znižuje riziko, že primárny kľúč nebude synchronizovaný s ostatnými tabuľkami, v ktorých sa naň odkazuje.
Často sa ako primárny kľúč používa ľubovoľné jedinečné číslo. Môžete napríklad priradiť každej objednávke jedinečné číslo objednávky. Jediným účelom čísla objednávky je identifikovať objednávku. Po priradení sa nikdy nezmení.
Ak vám nenapadá stĺpec alebo množina stĺpcov, ktoré by mohli predstavovať vhodný primárny kľúč, zvážte použitie stĺpca, ktorý obsahuje typ údajov AutoNumber. Keď použijete typ údajov AutoNumber, Access automaticky priradí hodnotu za vás. Takýto identifikátor nemá údajovú hodnotu a neobsahuje žiadne faktické informácie popisujúce riadok, ktorý tento identifikátor predstavuje. Identifikátory bez údajovej hodnoty sú ideálne na použitie ako primárny kľúč, pretože sa nemenia. Primárny kľúč, ktorý obsahuje informácie o riadku – napríklad telefónne číslo alebo meno zákazníka – má väčšiu pravdepodobnosť meniť sa, pretože sa môžu meniť samotné faktické informácie.
1. Stĺpec nastavený na typ údajov AutoNumber je často vhodný ako primárny kľúč. Žiadne dve ID produktu nie sú rovnaké.
V niektorých prípadoch je vhodné použiť viacero polí, ktoré spoločne tvoria primárny kľúč tabuľky. Tabuľka Podrobnosti objednávok, v ktorej sú uložené riadkové položky objednávok, môže napríklad používať ako primárny kľúč dva stĺpce: ID objednávky a ID produktu. Ak primárny kľúč pozostáva z viacerých stĺpcov, nazýva sa aj zložený kľúč.
V databáze predaja produktov môžete pre každú tabuľku vytvoriť stĺpec typu AutoNumber, ktorý bude slúžiť ako primárny kľúč: stĺpec ID produktu pre tabuľku Produkty, stĺpec ID objednávky pre tabuľku Objednávky, stĺpec ID zákazníka pre tabuľku Zákazníci a stĺpec ID dodávateľa pre tabuľku Dodávatelia.
Vytvorenie vzťahov medzi tabuľkami
Po rozdelení informácií do tabuliek potrebujete spôsob, ako tieto informácie opäť zmysluplne spojiť. Nasledujúci formulár napríklad obsahuje informácie z viacerých tabuliek.
1. Informácie v tomto formulári pochádzajú z tabuľky Zákazníci...
2. ...tabuľky Zamestnanci...
3. ...tabuľky Objednávky...
4. ...tabuľky Produkty...
5. ...a tabuľky Podrobnosti objednávok.
Access je systém správy relačných databáz. V relačnej databáze rozdelíte informácie do samostatných tematických tabuliek. Potom použijete vzťah medzi tabuľkami na spojenie informácií podľa potreby.
Vytvorenie vzťahu „one-to-many“
Zamyslite sa nad týmto príkladom: tabuľka Dodávatelia a tabuľka Produkty v databáze objednávok produktov. Dodávateľ môže dodávať ľubovoľný počet produktov. Z toho vyplýva, že každý dodávateľ uvedený v tabuľke Dodávatelia môže mať veľa produktov uvedených v tabuľke Produkty. Vzťah medzi tabuľkou Dodávatelia a tabuľkou Produkty je preto „one-to-many“.
Ak chcete v návrhu databázy vyjadriť vzťah „one-to-many“, použite primárny kľúč na strane „one“ tohto vzťahu a pridajte ho v danom vzťahu ako ďalší stĺpec alebo stĺpce do tabuľky na strane „many“. V tomto prípade napríklad pridáte nový stĺpec ID dodávateľa z tabuľky Dodávatelia do tabuľky Produkty. Access potom môže použiť na vyhľadanie správneho dodávateľa pre každý produkt číslo v stĺpci ID dodávateľa v tabuľke Produkty.
Stĺpec ID dodávateľa v tabuľke Produkty sa nazýva cudzí kľúč. Cudzí kľúč je primárny kľúč inej tabuľky. Stĺpec ID dodávateľa v tabuľke Produkty je cudzí kľúč, pretože je tiež primárnym kľúčom v tabuľke Dodávatelia.
Vytvorením párov primárnych kľúčov a cudzích kľúčov poskytujete základ pre spojenie súvisiacich tabuliek. Ak si nie ste istí, ktoré tabuľky by mali zdieľať spoločný stĺpec, zistenie vzťahu „one-to-many“ je potvrdením, že dané dve tabuľky budú skutočne vyžadovať zdieľaný stĺpec.
Vytvorenie vzťahu „many-to-many“
Posúďte vzťah medzi tabuľkou Produkty a tabuľku Objednávky.
Jedna objednávka môže obsahovať viac ako jeden produkt. Na druhej strane, jeden produkt sa môže objaviť v mnohých objednávkach. Preto pre každý záznam v tabuľke Objednávky môže existovať veľa záznamov v tabuľke Produkty. Zároveň pre každý záznam v tabuľke Produkty môže existovať veľa záznamov v tabuľke Objednávky. Tento typ vzťahu sa nazýva „many-to-many“, pretože na každý produkt môže existovať veľa objednávok a v každej objednávke môže byť veľa produktov. Nezabúdajte, že ak chcete zistiť medzi tabuľkami vzťah „many-to many“, je dôležité vziať do úvahy obidve strany vzťahu.
Medzi predmetmi týchto dvoch tabuliek – objednávok a produktov – je vzťah „many-to-many“. To predstavuje problém. Pre pochopenie problému si predstavte, čo by sa stalo, keby ste sa pokúsili vytvoriť vzťah medzi dvoma tabuľkami pridaním poľa ID produktu do tabuľky Objednávky. Ak chcete mať viacero produktov na každú objednávku, potrebujete na každú objednávku v tabuľke Objednávky viacero záznamov. Opakovali by ste informáciu o objednávke v každom riadku, ktorý sa vzťahuje na jednotlivú objednávku, a preto ide o neefektívny návrh, ktorý môže viesť k nepresným údajom. Na rovnaký problém narazíte, keď umiestnite pole ID objednávky do tabuľky Produkty– mali by ste viaceré záznamy v tabuľke Produkty pre každý produkt. Ako sa dá tento problém vyriešiť?
Odpoveďou je vytvoriť tretiu tabuľku, často označovanú ako spojovaciu tabuľku, ktorá rozdelí vzťah „many-to-many“ do dvoch vzťahov „one-to-many“. Do tejto tretej tabuľky vložíte primárny kľúč z oboch daných tabuliek. Výsledkom je, že tretia tabuľka zaznamenáva každý výskyt alebo inštanciu tohto vzťahu.
Každý záznam v tabuľke Podrobnosti objednávok predstavuje jednu riadkovú položku v objednávke. Primárny kľúč tabuľky Podrobnosti objednávok sa skladá z dvoch polí – cudzích kľúčov z tabuľky Objednávky a tabuľky Produkty. Ako primárny kľúč pre túto tabuľku nemožno použiť samotné pole ID objednávky, pretože jedna objednávka môže mať veľa riadkových položiek. Keďže ID objednávky sa opakuje pre každú riadkovú položku objednávky, toto pole neobsahuje jedinečné hodnoty. Použiť nemožno ani samotné pole ID produktu, pretože jeden produkt sa môže objaviť v mnohých rôznych objednávkach. Spolu však tieto dve polia vždy tvoria jedinečnú hodnotu pre každý záznam.
V databáze predaja produktov nie sú tabuľky Objednávky a Produkty v priamej vzájomnej súvislosti. Namiesto toho súvisia nepriamo prostredníctvom tabuľky Podrobnosti objednávok. Vzťah „many-to-many“ medzi objednávkami a produktmi je vyjadrený v databáze s použitím dvoch vzťahov „one-to-many“:
-
Medzi tabuľkou Objednávky a tabuľkou Podrobnosti objednávok je vzťah „one-to-many“. Každá objednávka môže mať viacero riadkových položiek, no každá riadková položka je spojená len s jednou objednávkou.
-
Medzi tabuľkou Produkty a tabuľkou Podrobnosti objednávok je vzťah „one-to-many“. Ku každému produktu môže byť priradených veľa riadkových položiek, no každá riadková položka odkazuje len na jeden produkt.
Z tabuľky Podrobnosti objednávok môžete určiť všetky produkty v určitej objednávke. Môžete tiež určiť všetky objednávky určitého produktu.
Po zavedení tabuľky Podrobnosti objednávok môže zoznam tabuliek a polí vyzerať asi takto:
Vytvorenie vzťahu „one-to-one“
Ďalším typom vzťahu je vzťah „one-to-one“. Predpokladajme napríklad, že potrebujete zaznamenať nejaké špeciálne doplňujúce informácie o produkte, ktoré budete potrebovať len zriedkavo alebo ktoré sa vzťahujú len na niekoľko produktov. Keďže tieto informácie nepotrebujete často a ich uloženie do tabuľky Produkty by malo za následok prázdne miesta v tabuľke pri všetkých produktoch, na ktoré sa nevzťahujú, umiestnite ich do samostatnej tabuľky. Rovnako ako v tabuľke Produkty použijete ako primárny kľúč ID produktu. Medzi touto doplňujúcou tabuľkou a tabuľkou Produkty je vzťah „one-to-one“. Pre každý záznam v tabuľke Produkty existuje jeden zodpovedajúci záznam v doplňujúcej tabuľke. Keď určíte takýto vzťah, obidve tabuľky musia zdieľať spoločné pole.
Ak zistíte, že v databáze potrebujete vzťah „one-to-one“, zvážte, či možno zlúčiť informácie z daných dvoch tabuliek do jednej tabuľky. Ak to z nejakého dôvodu nechcete urobiť, povedzme preto, že by to malo za následok veľa prázdneho miesta, v nasledujúcom zozname je uvedené, ako by ste tento vzťah vyjadrili v návrhu:
-
Ak majú dve tabuľky rovnaký predmet, môžete pravdepodobne nastaviť vzťah s použitím rovnakého primárneho kľúča v oboch tabuľkách.
-
Ak majú dve tabuľky rozdielne predmety a rozdielne primárne kľúče, vyberte ľubovoľnú z týchto dvoch tabuliek a vložte jej primárny kľúč do druhej tabuľky ako cudzí kľúč.
Určenie vzťahov medzi tabuľkami vám pomôže ubezpečiť sa, že máte správne tabuľky a stĺpce. Ak existuje vzťah „one-to-one“ alebo „one-to-many“, príslušné tabuľky musia zdieľať aspoň jeden spoločný stĺpec. Ak existuje vzťah „many-to-many“, na vyjadrenie vzťahu je potrebná tretia tabuľka.
Optimalizácia návrhu
Keď máte potrebné tabuľky, polia a vzťahy, mali by ste vytvoriť tabuľky, vyplniť ich vzorovými údajmi a skúsiť pracovať s informáciami: vytvárať dotazy, pridávať nové záznamy a podobne. Pomôže vám to zistiť potenciálne problémy – možno napríklad budete potrebovať pridať stĺpec, ktorý ste zabudli vložiť vo fáze návrhu, alebo zistíte, že niektorú tabuľku treba rozdeliť do dvoch tabuliek, aby sa odstránili duplicity.
Zistite, či je možné databázu používať na získanie požadovaných odpovedí. Vytvorte hrubé koncepty formulárov a zostáv a skontrolujte, či sa v nich zobrazujú očakávané údaje. Vyhľadajte zbytočné duplicity údajov a ak nejaké nájdete, odstráňte ich úpravou návrhu.
Pri skúšaní prvotnej databázy pravdepodobne objavíte priestor na zlepšenie. Tu je niekoľko vecí, ktoré treba skontrolovať:
-
Zabudli ste na nejaké stĺpce? Ak áno, patria tieto informácie do existujúcich tabuliek? Ak sú tieto informácie o niečom inom, možno bude potrebné vytvoriť ďalšiu tabuľku. Vytvorte stĺpec pre každú informačnú položku, ktorú potrebujete sledovať. Ak sa daná informácia nedá vypočítať z ostatných stĺpcov, pravdepodobne budete pre ňu potrebovať nový stĺpec.
-
Sú niektoré stĺpce zbytočné, pretože ich možno vypočítať z existujúcich polí? Ak sa informačná položka dá vypočítať z iných existujúcich stĺpcov, napríklad zľavnená cena vypočítaná z maloobchodnej ceny, zvyčajne je lepšie použiť takýto výpočet, a tým sa vyhnúť vytvoreniu nového stĺpca.
-
Zadávate opakovane duplicitné informácie do niektorej tabuľky? Ak áno, pravdepodobne je potrebné túto tabuľku rozdeliť do dvoch tabuliek, medzi ktorými je vzťah „one-to-many“.
-
Máte tabuľky s mnohými poľami, obmedzeným počtom záznamov a mnohými prázdnymi poľami v jednotlivých záznamoch? Ak áno, pokúste sa zmeniť návrh tabuľky tak, aby obsahovala menej polí a viac záznamov.
-
Je každá informačná položka rozdelená na najmenšie užitočné časti? Ak potrebujete vytvárať zostavy, zoraďovať, hľadať alebo vykonávať výpočty na základe určitej informačnej položky, umiestnite túto položku do vlastného stĺpca.
-
Obsahuje každý stĺpec údaj týkajúci sa predmetu tabuľky? Ak stĺpec neobsahuje informácie o predmete tabuľky, patrí do inej tabuľky.
-
Sú všetky vzťahy medzi tabuľkami vyjadrené buď spoločnými poľami, alebo treťou tabuľkou? Vzťahy „one-to-ne“ a „one-to-many“ vyžadujú spoločné stĺpce. Vzťahy „many-to-many“ vyžadujú tretiu tabuľku.
Optimalizácia tabuľky Produkty
Predpokladajme, že každý produkt v databáze predaja produktov spadá do určitej všeobecnej kategórie, ako napríklad nápoje, koreniny alebo plody mora. Tabuľka Produkty môže obsahovať pole, ktoré udáva kategóriu jednotlivých produktov.
Predpokladajme, že po preskúmaní a optimalizovaní návrhu databázy sa rozhodnete uložiť spolu s názvom kategórie aj jej popis. Ak pridáte pole Popis kategórie do tabuľky Produkty, budete musieť opakovať popis kategórie pre každý produkt, ktorý spadá do tejto kategórie, čo nie je vhodné riešenie.
Lepším riešením je urobiť z kategórií nový predmet sledovaný v databáze, s vlastnou tabuľkou a vlastným primárnym kľúčom. Potom môžete pridať primárny kľúč z tabuľky Kategórie do tabuľky Produkty ako cudzí kľúč.
Medzi tabuľkami Kategórie a Produkty je vzťah „one-to-many“: kategória môže obsahovať viaceré produkty, ale produkt môže patriť len do jednej kategórie.
Pri kontrole tabuľkových štruktúr hľadajte opakujúce sa skupiny. Predstavte si napríklad tabuľku, ktorá obsahuje tieto stĺpce:
-
ID produktu
-
Názov
-
ID produktu 1
-
Názov1
-
ID produktu 2
-
Názov2
-
ID produktu 3
-
Názov3
V tomto prípade je každý produkt opakujúcou sa skupinou stĺpcov, ktorá sa od ostatných odlišuje len číslom pridaným na konci názvu stĺpca. Ak máte takto očíslované stĺpce, mali by ste návrh prehodnotiť.
Takýto návrh má viacero chýb. V prvom rade vás núti stanoviť horný limit počtu produktov. Po prekročení tohto limitu musíte do tabuľkovej štruktúry pridať novú skupinu stĺpcov, čo je zložitá administratívna úloha.
Ďalší problém spočíva v tom, že pri dodávateľoch s menším ako maximálnym počtom produktov sa bude plytvať miestom, keďže dodatočné stĺpce budú prázdne. Najzávažnejšou chybou takéhoto návrhu je, že sťažuje vykonávanie mnohých úloh, ako je napríklad zoradenie alebo indexovanie tabuľky podľa ID produktu alebo názvu.
Vždy, keď zbadáte opakujúce sa skupiny, podrobne skontrolujte návrh a zamerajte sa na rozdelenie tabuľky na dve. Vo vyššie uvedenom príklade je lepšie použiť dve tabuľky, jednu pre dodávateľov a jednu pre produkty, a prepojiť ich pomocou ID dodávateľa.
Použitie pravidiel normalizácie
Ako ďalší krok návrhu môžete uplatniť pravidlá normalizácie údajov (niekedy sa nazývajú len pravidlá normalizácie). Pomocou týchto pravidiel zistíte, či sú tabuľky správne štruktúrované. Proces uplatnenia pravidiel na návrh databázy sa nazýva normalizácia databázy alebo jednoducho normalizácia.
Normalizácia je najužitočnejšia vtedy, keď ste už vyjadrili všetky informačné položky a dospeli k predbežnému návrhu. Jej cieľom je pomôcť vám ubezpečiť sa, že ste informačné položky rozdelili do náležitých tabuliek. Normalizácia však nedokáže zabezpečiť, aby ste mali k dispozícii všetky správne údajové položky.
Pravidlá sa použijú postupne, pričom v každom kroku zabezpečíte, že váš návrh príde na jeden z nich, známy ako "normálna forma". Bežne prijímame päť normálnych foriem – prvú normálnu formu až po piatu normálnu formu. Tento článok sa rozbalí na prvé tri, pretože sú všetko, čo je potrebné pre väčšinu návrhov databáz.
Prvá normálna forma
Prvá normálna forma stanovuje, že v každom prieniku riadka a stĺpca v tabuľke existuje jedna hodnota a nikdy nie zoznam hodnôt. Nemožno mať napríklad pole s názvom Cena, v ktorom sú umiestnené viaceré ceny. Ak si všetky jednotlivé prieniky riadkov a stĺpcov predstavíme ako bunky, každá bunka smie obsahovať len jednu hodnotu.
Druhá normálna forma
Druhá normálna forma vyžaduje, aby bol každý nekľúčový stĺpec plne závislý od celého primárneho kľúča a nie len od jeho časti. Toto pravidlo platí pre primárny kľúč pozostávajúci minimálne z dvoch stĺpcov. Predpokladajme napríklad, že máte tabuľku obsahujúcu nasledujúce stĺpce, pričom ID objednávky a ID produktu tvoria primárny kľúč:
-
ID objednávky (primárny kľúč)
-
ID produktu (primárny kľúč)
-
Názov produktu
Tento návrh porušuje druhú normálnu formu, pretože stĺpec Názov produktu závisí od ID produktu, ale nie od ID objednávky, čo znamená, že nie je závislý od celého primárneho kľúča. Stĺpec Názov produktu je nutné odstrániť z tabuľky. Patrí do inej tabuľky (Produkty).
Tretia normálna forma
Tretia normálna forma vyžaduje nielen to, aby bol každý nekľúčový stĺpec závislý od celého primárneho kľúča, ale aj to, aby boli nekľúčové stĺpce od seba nezávislé.
Inak povedané, každý nekľúčový stĺpec musí byť závislý, a to výhradne od primárneho kľúča. Predpokladajme napríklad, že máte tabuľku obsahujúcu tieto stĺpce:
-
ID produktu (primárny kľúč)
-
Názov
-
MOC
-
Zľava
Predpokladajme, že zľava závisí od navrhovanej maloobchodnej ceny (MOC). Táto tabuľka porušuje tretiu normálnu formu, pretože nekľúčový stĺpec Zľava závisí od ďalšieho nekľúčového stĺpca MOC. Nezávislosť stĺpca znamená, že každý nekľúčový stĺpec sa musí dať zmeniť bez toho, aby to ovplyvnilo akýkoľvek iný stĺpec. Ak zmeníte hodnotu v poli MOC, príslušným spôsobom sa zmení aj hodnota v poli Zľava, čo je porušením tohto pravidla. V tomto prípade je stĺpec Zľava potrebné premiestniť do inej tabuľky, v ktorej sa ako kľúč používa MOC.
