Správně navržená databáze umožňuje přístup k aktuálním a přesným informacím. Vzhledem k tomu, že správný návrh je nezbytný pro dosažení vašich cílů při práci s databází, má smysl investovat čas potřebný k seznámení se s principy dobrého návrhu. Je mnohem pravděpodobnější, že nakonec budete mít databázi, která odpovídá vašim potřebám a snadno se přizpůsobí změnám.
Tento článek obsahuje pokyny pro plánování desktopové databáze. Dozvíte se, jak se rozhodnout, jaké informace potřebujete, jak tyto informace rozdělit do příslušných tabulek a sloupců a jak spolu tyto tabulky vzájemně souvisí. Tento článek byste si měli přečíst před vytvořením první desktopové databáze.
V tomto článku
- Některé databázové pojmy, které je dobré znát
- Co znamená dobrý návrh databáze?
- Proces návrhu
- Určení účelu databáze:
- Vyhledání a uspořádání požadovaných informací
- Rozdělení informací do tabulek
- Převedení informačních položek na sloupce
- Zadání primárních klíčů
- Vytvoření relací mezi tabulkami
- Upřesnění návrhu
- Použití normalizačních pravidel
Některé databázové pojmy, které je dobré znát
Access uspořádá informace do tabulek, což jsou seznamy řádků a sloupců, které připomínají účetní blok nebo tabulku. V jednoduché databázi můžete mít pouze jednu tabulku. Pro většinu databází jich budete potřebovat více. Můžete třeba mít tabulku, ve které jsou uložené informace o produktech, další tabulku s informacemi o objednávkách a další tabulku s informacemi o zákaznících.
Každý řádek se přesněji nazývá záznam a každý sloupec pole. Záznam je smysluplný a konzistentní způsob, jak sloučit informace o nějaké věci. Pole je jedna položka informací – typ položky, která se vyskytuje v každém záznamu. Například v tabulce Produkty by každý řádek nebo záznam obsahoval informace o jednom produktu. Každý sloupec nebo pole obsahuje nějaký typ informací o daném produktu, například jeho název nebo cenu.
Co znamená dobrý návrh databáze?
Proces návrhu databáze se řídí určitými principy. První zásadou je, že duplicitní informace (nazývané také redundantní data) jsou špatné, protože plýtvají místem a zvyšují pravděpodobnost chyb a nekonzistencí. Druhou zásadou je, že důležitá je správnost a úplnost informací. Pokud databáze obsahuje nesprávné informace, budou nesprávné informace obsahovat i sestavy, které z databáze informace načítají. V důsledku toho budou všechna rozhodnutí, která jsou na základě těchto zpráv mylná.
Dobrý návrh databáze je tedy takový, který:
- Rozdělí informace do tabulek s příslušnými předměty, aby omezil nadbytečná data.
- Poskytuje Accessu informace, které potřebuje, aby mohl podle potřeby spojit informace v tabulkách.
- Pomáhá podporovat a zajišťovat přesnost a integritu vašich informací.
- Vyhovuje vašim potřebám zpracování dat a vytváření sestav.
Proces návrhu
Proces návrhu se skládá z následujících kroků:
-
Určení účelu databáze:
To vám pomůže se připravit na zbývající kroky. -
Vyhledání a uspořádání požadovaných informací:
Shromážděte všechny typy informací, které byste mohli chtít zaznamenat do databáze, například název produktu a číslo objednávky. -
Rozdělení informací do tabulek
Rozdělte své položky informací do hlavních entit nebo předmětů, jako jsou Produkty nebo Objednávky. Z každého předmětu se pak stane tabulka. -
Převedení informačních položek na sloupce
Rozhodněte, jaké informace chcete v každé tabulce ukládat. Každá položka se stane polem a zobrazí se v tabulce jako sloupec. Tabulka Zaměstnanci může například obsahovat pole, jako je Příjmení a Datum nástupu. -
Zadání primárních klíčů
Zvolte primární klíč každé tabulky. Primární klíč je sloupec, který slouží k jednoznačné identifikaci každého řádku. Příkladem může být ID produktu nebo ID objednávky. -
Nastavení relací mezi tabulkami
Podívejte se na každou tabulku a rozhodněte se, jak data v jedné tabulce souvisí s daty v jiných tabulkách. Přidejte pole do tabulek nebo podle potřeby vytvořte nové tabulky, abyste vyjasnili relace. -
Vylepšení návrhu
Analýza chyb v návrhu. Vytvořte tabulky a přidejte několik záznamů ukázkových dat. Zjistěte, jestli můžete z tabulek získat požadované výsledky. Podle potřeby proveďte úpravy návrhu. -
Použití normalizačních pravidel
Pomocí pravidel normalizace dat můžete zjistit, jestli jsou tabulky správně strukturované. Podle potřeby upravte tabulky.
Určení účelu databáze:
Je vhodné si na papír zapsat účel databáze – její účel, jak ji podle vás budete používat a kdo ji bude používat. Pokud potřebujete třeba malou databázi pro domácí firmu, můžete napsat něco jednoduchého, jako třeba, že "Databáze zákazníků uchovává seznam informací o zákaznících za účelem vytváření korespondence a sestav". Pokud je databáze složitější nebo ji používá mnoho lidí, jak se často stává v podnikovém prostředí, může být účelem snadno odstavec nebo více a měl by zahrnovat, kdy a jak budou jednotlivé osoby databázi používat. Cílem je mít dobře propracované prohlášení o poslání, na které se lze odkazovat v průběhu celého procesu návrhu. Takové prohlášení vám pomůže soustředit se při rozhodování na své cíle.
Vyhledání a uspořádání požadovaných informací
Pokud chcete najít a uspořádat požadované informace, začněte s existujícími informacemi. Můžete například zaznamenávat nákupní objednávky v hlavní knize nebo uchovávat informace o zákaznících na papírových formulářích v archivu. Shromážděte tyto dokumenty a uveďte všechny typy zobrazených informací (například všechna pole, která ve formuláři vyplníte). Pokud nemáte žádné existující formuláře, představte si, že musíte navrhnout formulář pro zaznamenání informací o zákazníkovi. Jaké informace byste uvedli ve formuláři? Jaká pole pro vyplnění byste vytvořili? Každou z těchto položek identifikujte a uveďte v jejím seznamu. Předpokládejme například, že v současné době vedete seznam zákazníků na kartotéčních kartách. Při zkoumání těchto karet můžete zjistit, že každá z nich obsahuje jméno zákazníka, adresu, město, stát, PSČ a telefonní číslo. Každá z těchto položek představuje potenciální sloupec v tabulce.
Při přípravě tohoto seznamu si nedělejte starosti s tím, aby byl hned napoprvé dokonalý. Místo toho si vypište seznam všech položek, které vás napadnou. Pokud bude databázi používat někdo jiný, zeptejte se také na jejich nápady. Později můžete seznam doladit.
Dále zvažte typy sestav nebo korespondence, které byste mohli chtít z databáze vytvářet. Můžete třeba chtít sestavu prodeje produktů, která zobrazuje prodeje podle oblastí, nebo souhrnnou sestavu skladových zásob, která zobrazuje stav zásob produktů. Můžete taky vygenerovat formulářové dopisy, které se budou posílat zákazníkům a v nichž zákazníci oznámí prodejní akci nebo prémii. Navrhněte si sestavu ve své mysli a představte si, jak by vypadala. Jaké informace byste do sestavy umístili? Vypsat jednotlivé položky. To samé udělejte u formulářového dopisu a u všech dalších sestav, které se chystáte vytvořit.
Když se zamyslíte nad sestavami a korespondencemi, které byste mohli chtít vytvořit, pomůže vám to identifikovat položky, které budete v databázi potřebovat. Předpokládejme například, že zákazníkům dáte možnost přihlásit se k pravidelným e-mailovým aktualizacím (nebo je odmítnout) a chcete vytisknout jejich seznam. Chcete-li tyto informace zaznamenat, přidejte do tabulky zákazníků sloupec "Odeslat e-mail". U každého zákazníka můžete v poli nastavit hodnotu Ano nebo Ne.
Požadavek na odesílání e-mailových zpráv zákazníkům navrhne další položku k zaznamenání. Jakmile víte, že zákazník chce dostávat e-mailové zprávy, budete také potřebovat znát e-mailovou adresu, na kterou je má odeslat. Proto je potřeba zaznamenat e-mailovou adresu každého zákazníka.
Je vhodné vytvořit prototyp každé sestavy nebo výpisu výstupu a zvážit, jaké položky budete k vytvoření sestavy potřebovat. Když například zkoumáte formulářový dopis, může vás napadnout několik věcí. Pokud chcete zahrnout správné oslovení – například řetězec "pan", "paní" nebo "paní", kterým se začíná pozdrav, musíte vytvořit položku pozdravu. Také můžete obvykle začínat dopis slovy "Vážený pane Nováke" místo "Vážený. Pan Sylvester Smith". Z toho vyplývá, že příjmení je obvykle vhodné uložit odděleně od křestního jména.
Klíčovým bodem, který je třeba si zapamatovat, je, že každou informaci byste měli rozdělit na co nejmenší užitečné části. Aby bylo příjmení vždy po ruce, rozdělíte ho na dvě části – křestní jméno a příjmení. Pokud chcete sestavu seřadit například podle příjmení, pomůže, když příjmení zákazníka uložíte samostatně. Obecně platí, že pokud chcete řadit, vyhledávat, počítat nebo vykazovat na základě položky informací, měli byste tuto položku umístit do vlastního pole.
Zamyslete se nad otázkami, na které by mohla databáze odpovědět. Kolik prodejů doporučeného produktu jste například minulý měsíc uzavřeli? Kde žijí vaši nejlepší zákazníci ? Kdo je dodavatelem vašeho nejprodávanějšího produktu? Předvídání těchto otázek vám pomůže zaměřit se na další položky, které je třeba zaznamenat.
Po shromáždění těchto informací jste připraveni na další krok.
Rozdělení informací do tabulek
Pokud chcete informace rozdělit do tabulek, zvolte hlavní entity neboli předměty. Když třeba vyhledáte a uspořádáte informace pro databázi prodeje produktů, může předběžný seznam vypadat takto:
Hlavními entitami, které jsou zde uvedeny, jsou produkty, dodavatelé, zákazníci a objednávky. Proto má smysl začít s těmito čtyřmi tabulkami: jedna pro fakta o produktech, jedna pro fakta o dodavatelích, jedna pro fakta o zákaznících a jedna pro fakta o objednávkách. I když to není úplný seznam, je to dobrý výchozí bod. Tento seznam můžete dále upřesňovat, dokud nezískáte návrh, který bude dobře fungovat.
Při prvním prohlížení předběžného seznamu položek můžete být v pokušení umístit je všechny do jediné tabulky namísto čtyř položek zobrazených na předchozím obrázku. Zde se dozvíte, proč je to špatný nápad. Zamyslete se na chvíli nad tabulkou tady:
V tomto případě obsahuje každý řádek informace o produktu i jeho dodavateli. Vzhledem k tomu, že můžete mít více produktů od stejného dodavatele, je nutné mnohokrát opakovat informace o názvu a adrese dodavatele. Plýtvá se tím místem na disku. Mnohem lepším řešením je zaznamenat informace o dodavateli do samostatné tabulky Dodavatelé jen jednou a potom tuto tabulku propojit s tabulkou Výrobky.
Druhý problém s tímto designem nastává, když potřebujete upravit informace o dodavateli. Předpokládejme například, že potřebujete změnit adresu dodavatele. Protože se vyskytuje na mnoha místech, můžete adresu omylem změnit na jednom místě, ale zapomenete ji změnit na ostatních. Zaznamenávání adresy dodavatele pouze na jednom místě problém řeší.
Při navrhování databáze se vždy snažte zaznamenat všechna fakta jenom jednou. Pokud zjistíte, že opakujete stejné informace na více místech, například na adrese určitého dodavatele, umístěte tyto informace do samostatné tabulky.
A konečně, předpokládejme, že společnost Coho Winery dodává pouze jeden produkt a chcete tento produkt odstranit, ale zachovat informace o názvu a adrese dodavatele. Jak byste odstranili záznam o produktu, aniž byste zároveň přišli o informace o dodavateli? Nemůžete. Každý záznam obsahuje fakta o produktu i o dodavateli, takže nemůžete odstranit jeden z nich bez odstranění druhého. Chcete-li tyto údaje oddělit, je třeba jednu tabulku rozdělit na dvě: jednu tabulku s informacemi o produktu a druhou na informace o dodavateli. Při odstranění záznamu o produktu by se měla odstranit jenom fakta o produktu, ne fakta o dodavateli.
Jakmile zvolíte předmět, který je zastoupen tabulkou, sloupce v této tabulce by měly obsahovat fakta pouze o tomto předmětu. Tabulka produktů by například měla obsahovat fakta pouze o produktech. Protože adresa dodavatele je fakt o dodavateli, ne fakt o produktu, patří do tabulky dodavatelů.
Převedení informačních položek na sloupce
Pokud chcete určit sloupce v tabulce, rozhodněte se, jaké informace potřebujete sledovat o předmětu zaznamenaném v tabulce. Například pro tabulku Zákazníci tvoří vhodný výchozí seznam sloupců Jméno, Adresa, Město-Stát-PSČ, Odeslat e-mail, Oslovení a E-mailová adresa. Každý záznam v tabulce obsahuje stejnou sadu sloupců, abyste pro každý záznam mohli uložit informace o názvu, adrese, městě-státu, PSČ, odeslání e-mailu, oslovení a e-mailové adrese. Například sloupec s adresou obsahuje adresy zákazníků. Každý záznam obsahuje data o jednom zákazníkovi, přičemž pole adresy obsahuje adresu tohoto zákazníka.
Jakmile určíte počáteční sadu sloupců pro každou tabulku, můžete sloupce dále upřesnit. Má například smysl uložit jméno zákazníka jako dva samostatné sloupce: jméno a příjmení, abyste mohli řadit, vyhledávat a indexovat jenom podle těchto sloupců. Podobně se adresa ve skutečnosti skládá z pěti samostatných částí: adresa, město, stát, PSČ a země/oblast, a má také smysl je ukládat do samostatných sloupců. Pokud chcete provést operaci hledání, filtrování nebo řazení například podle státu, potřebujete informace o stavu uložené v samostatném sloupci.
Měli byste také zvážit, zda databáze bude obsahovat pouze informace domácího nebo také mezinárodního. Pokud třeba plánujete ukládat mezinárodní adresy, je lepší mít sloupec Oblast místo Stát, protože takový sloupec pojme jak domácí státy, tak oblasti jiných zemí nebo oblastí. Podobně poštovní směrovací číslo dává větší smysl než PSČ, pokud se chystáte ukládat mezinárodní adresy.
V následujícím seznamu najdete několik tipů pro určení sloupců.
-
Nezahrnovat počítaná data
Ve většině případů byste neměli výsledky výpočtů ukládat do tabulek. Místo toho můžete nechat Access výpočty provést, až budete chtít vidět výsledek. Předpokládejme například, že existuje sestava Výrobky na objednávku, která zobrazuje mezisoučet jednotek na objednávku pro každou kategorii výrobků v databázi. V žádné tabulce však neexistuje žádný sloupec mezisoučtu jednotek objednávky. Místo toho obsahuje tabulka Produkty sloupec Jednotky na objednávku, který ukládá jednotky na objednávku jednotlivých produktů. Na základě těchto dat Access vypočítá mezisoučet pokaždé, když sestavu vytisknete. Samotný souhrn by neměl být uložený v tabulce. -
Ukládejte informace v nejmenších logických částech
Možná budete navádět možnost mít jedno pole pro celá jména nebo názvy produktů spolu s popisy produktů. Pokud v poli zkombinujete víc než jeden druh informací, je později obtížné zjistit jednotlivé údaje. Snažte se rozdělit informace do logických částí; Vytvořte například samostatná pole pro jméno a příjmení nebo pro název produktu, kategorii a popis.
Po upřesnění sloupců dat v každé tabulce jste připraveni zvolit primární klíč každé tabulky.
Zadání primárních klíčů
Každá tabulka by měla obsahovat sloupec nebo sadu sloupců, které jedinečným způsobem identifikují každý řádek uložený v tabulce. Často se jedná o jedinečné identifikační číslo, například identifikační číslo zaměstnance nebo sériové číslo. V terminologii databáze se tato informace nazývá primární klíč tabulky. Access používá pole primárního klíče k rychlému přidružení dat z více tabulek a jejich sloučení dohromady.
Pokud už máte pro tabulku jedinečný identifikátor, například číslo výrobku, které jedinečným způsobem identifikuje jednotlivé produkty v katalogu, můžete tento identifikátor použít jako primární klíč tabulky – ale jenom v případě, že se hodnoty v tomto sloupci budou v jednotlivých záznamech lišit. Primární klíč nesmí obsahovat duplicitní hodnoty. Nepoužívejte například jména lidí jako primární klíč, protože jména nejsou jedinečná. Snadno můžete mít v jedné tabulce dva lidi se stejným jménem.
Primární klíč musí vždy obsahovat hodnotu. Pokud se hodnota sloupce může v určitém okamžiku stát nepřiřazenou nebo neznámou (chybějící hodnota), nemůžete ji použít jako součást primárního klíče.
Vždy byste měli zvolit primární klíč, jehož hodnota se nebude měnit. V databázi, která používá více než jednu tabulku, může být primární klíč tabulky použit jako odkaz v jiných tabulkách. Pokud se změní primární klíč, musí být změna použita také všude, kde je na klíč odkazováno. Použití primárního klíče, který se nemění, snižuje riziko nesynchronizace primárního klíče s jinými tabulkami, které na něj odkazují.
Jako primární klíč se často používá libovolné jedinečné číslo. Každé objednávce můžete například přiřadit jedinečné číslo objednávky. Jediným účelem čísla objednávky je identifikovat objednávku. Jakmile je přiřadíte, už se nikdy nezmění.
Pokud nemáte na mysli sloupec nebo sadu sloupců, které by mohly být vhodným primárním klíčem, zvažte použití sloupce s datovým typem Automatické číslo. Když použijete datový typ Automatické číslo, přiřadí vám Access automaticky hodnotu. Takový identifikátor je bez faktů; Neobsahuje žádné faktické informace popisující řádek, který představuje. Identifikátory bez údajů jsou ideální pro použití jako primární klíč, protože se nemění. Primární klíč, který obsahuje fakta o řádku, třeba telefonní číslo nebo jméno zákazníka, se s větší pravděpodobností změní, protože se může změnit samotná faktická informace.
1. Sloupec nastavený na datový typ Automatické číslo je často vhodným primárním klíčem. Žádné dvě ID produktů nejsou stejné.
Někdy můžete chtít použít dvě nebo více polí, která společně tvoří primární klíč tabulky. Například tabulka Podrobnosti objednávky, která obsahuje položky řádku pro objednávky, by jako svůj primární klíč použila dva sloupce: ID objednávky a ID produktu. Pokud primární klíč využívá více než jeden sloupec, nazývá se taky složený klíč.
Pro databázi prodeje produktů můžete pro každou tabulku vytvořit sloupec Automatické číslo, který bude sloužit jako primární klíč: ProductID pro tabulku Produkty, OrderID pro tabulku Orders, CustomerID (ID zákazníka) pro tabulku Customers (Zákazníci) a SupplierID (ID dodavatele) pro tabulku Suppliers (Dodavatele).
Vytvoření relací mezi tabulkami
Teď, když jste informace rozdělili do tabulek, potřebujete způsob, jak je znovu smysluplně spojit. Následující formulář například obsahuje informace z několika tabulek.
1. Informace v tomto formuláři pocházejí z tabulky Zákazníci...
2. ... tabulka Zaměstnanci...
3. ... tabulka Objednávky...
4. ... Tabulka Produkty...
5. ... a tabulky Rozpis objednávek.
Access je systém pro správu relačních databází. V relační databázi rozdělujete informace do samostatných tabulek s různými předměty. Podle potřeby pak můžete pomocí relací mezi tabulkami tyto informace seskupit.
Vytvoření relace 1:N
Představte si tento příklad: tabulky Dodavatelé a Produkty v databázi Objednávky výrobků. Dodavatel může dodat libovolný počet produktů. Z toho vyplývá, že pro každého dodavatele uvedeného v tabulce Dodavatelé může existovat mnoho výrobků zastoupených v tabulce Výrobky. Relace mezi tabulkami Dodavatelé a Výrobky je tedy relace 1:N.
Chcete-li znázornit relaci 1:N v návrhu databáze, vezměte primární klíč na straně 1 relace a přidejte jej jako další sloupec nebo sloupce do tabulky na straně N relace. V tomto případě například přidáte sloupec ID dodavatele z tabulky Dodavatelé do tabulky Produkty. Access potom může použít identifikační číslo dodavatele v tabulce Produkty k vyhledání správného dodavatele pro každý produkt.
Sloupec ID dodavatele v tabulce Produkty se nazývá cizí klíč. Cizí klíč je primárním klíčem jiné tabulky. Sloupec ID dodavatele v tabulce Produkty je cizí klíč, protože je také primárním klíčem v tabulce Dodavatelé.
Poskytnete základ pro spojení souvisejících tabulek vytvořením párování primárních a cizích klíčů. Pokud si nejste jisti, které tabulky by měly sdílet společný sloupec, určením relace 1:N zajistíte, že tyto dvě zahrnuté tabulky budou skutečně vyžadovat sdílený sloupec.
Vytvoření relace M:N
Podívejte se na relaci mezi tabulkami Výrobky a Objednávky.
Jedna objednávka může obsahovat více výrobků. Na druhou stranu se jeden výrobek může objevit v mnoha objednávkách. Z tohoto důvodu může pro každý záznam v tabulce Objednávky existovat mnoho záznamů v tabulce Výrobky. A pro každý záznam v tabulce Výrobky může existovat celá řada záznamů v tabulce Objednávky. Tento typ relace se nazývá relace M:N, protože pro libovolný produkt může existovat mnoho objednávek. A pro každou objednávku může existovat mnoho produktů. Všimněte si, že ke zjištění relací M:N mezi tabulkami je důležité vzít v úvahu obě strany relace.
Předměty těchto dvou tabulek – objednávky a produkty – mají relaci M:N. To představuje problém. Abyste problému porozuměli, představte si, co by se stalo, kdybyste se pokusili vytvořit relaci mezi těmito dvěma tabulkami přidáním pole Kód výrobku do tabulky Objednávky. Pokud chcete mít v jedné objednávce víc než jeden produkt, potřebujete víc než jeden záznam v tabulce Objednávky na jednu objednávku. Informace o objednávce by se opakovaly pro každý řádek, který se vztahuje k jedné objednávce, což by vedlo k neefektivnímu návrhu, který by mohl vést k nepřesným datům. Na stejný problém narazíte, pokud vložíte pole ID objednávky do tabulky Produkty – pro každý produkt byste měli v tabulce Výrobky více než jeden záznam. Jak tento problém vyřešíte?
Řešením je vytvořit třetí tabulku, často označovanou jako spojovací tabulka, která rozdělí relaci M:N na dvě relace 1:N. Primární klíč z těchto dvou tabulek vložíte do třetí tabulky. Výsledkem je, že třetí tabulka zaznamená každý výskyt nebo instanci relace.
Každý záznam v tabulce Rozpis objednávek představuje jednu řádkovou položku v objednávce. Primární klíč tabulky Rozpis objednávek se skládá ze dvou polí – cizích klíčů z tabulek Objednávky a Produkty. Samotné pole Číslo objednávky nefunguje jako primární klíč této tabulky, protože jedna objednávka může obsahovat mnoho položek řádku. ID objednávky se opakuje pro každou položku řádku objednávky, takže pole neobsahuje jedinečné hodnoty. Nefunguje ani samotné pole Kód výrobku, protože jeden výrobek se může objevit v mnoha různých objednávkách. Společně však tato dvě pole vždy poskytují jedinečnou hodnotu pro každý záznam.
V databázi prodeje produktů nejsou tabulky Objednávky a Produkty přímo propojené. Souvisejí nepřímo prostřednictvím tabulky Rozpis objednávek. Relace M:N mezi objednávkami a produkty je v databázi znázorněna pomocí dvou relací 1:N:
- Tabulky Objednávky a Podrobnosti objednávek mají relaci 1:N. Každá objednávka může mít více než jednu položku řádku, ale každá položka řádku je připojená jenom k jedné objednávce.
- Tabulky Produkty a Podrobnosti objednávky mají relaci 1:N. Ke každému produktu může být přidruženo mnoho řádkových položek, ale každá řádková položka odkazuje pouze na jeden produkt.
V tabulce Rozpis objednávek můžete určit všechny produkty v určité objednávce. Můžete také určit všechny objednávky určitého produktu.
Po zahrnutí tabulky Rozpis objednávek může seznam tabulek a polí vypadat nějak takto:
Creating a one-to-one relationship
Dalším typem relace je relace 1:1. Předpokládejme například, že potřebujete zaznamenat nějaké speciální doplňkové informace o produktu, které budete potřebovat zřídka nebo které se týkají pouze několika produktů. Protože tyto informace nepotřebujete často a protože při ukládání informací do tabulky Produkty by vzniklo prázdné místo pro všechny produkty, pro které tyto informace neplatí, umístíte je do samostatné tabulky. Podobně jako tabulku Produkty použijete IDProduktu jako primární klíč. Mezi touto doplňkovou tabulkou a tabulkou Produkt je relace 1:1. Pro každý záznam v tabulce Produkt existuje jeden odpovídající záznam v doplňkové tabulce. Při určování relace musí obě tabulky sdílet společné pole.
Pokud zjistíte, že v databázi potřebujete relaci 1:1, zvažte, zda je možné spojit informace z obou tabulek do jedné tabulky. Pokud to z nějakého důvodu nechcete udělat, třeba proto, že by to vedlo k velkému množství prázdného místa, následující seznam ukazuje, jak byste relaci vyjádřili ve svém návrhu:
- Pokud mají tyto dvě tabulky stejný předmět, pravděpodobně můžete relaci vytvořit tak, že v obou tabulkách použijete stejný primární klíč.
- Pokud mají tyto dvě tabulky různé předměty s různými primárními klíči, zvolte jednu z tabulek (v jedné z nich) a vložte její primární klíč do druhé tabulky jako cizí klíč.
Určení relací mezi tabulkami vám pomůže zajistit, abyste měli k dispozici správné tabulky a sloupce. Pokud existuje relace 1:1 nebo 1:N, musí příslušné tabulky sdílet společný sloupec nebo sloupce. Pokud existuje relace M:N, je potřebná třetí tabulka, která tuto relaci představuje.
Upřesnění návrhu
Až budete mít tabulky, pole a relace, které potřebujete, měli byste vytvořit a naplnit tabulky ukázkovými daty a zkusit pracovat s informacemi – vytvořením dotazů, přidáním nových záznamů atd. Tímto způsobem můžete upozornit na potenciální problémy – můžete třeba přidat sloupec, který jste zapomněli vložit během fáze návrhu, nebo můžete mít tabulku, kterou byste měli rozdělit na dvě tabulky, abyste odebrali duplicitu.
Podívejte se, jestli můžete databázi použít k získání požadovaných odpovědí. Vytvořte hrubé koncepty formulářů a sestav a zjistěte, jestli obsahují očekávaná data. Hledejte zbytečné duplicity dat, a když nějakou najdete, upravte návrh tak, abyste ji odstranili.
Při vyzkoušení počáteční databáze pravděpodobně objevíte prostor pro zlepšení. Tady je pár věcí, které byste měli zkontrolovat:
- Zapomněli jste na nějaké sloupce? Pokud ano, patří tyto informace do existujících tabulek? Pokud se jedná o informace o něčem jiném, bude pravděpodobně nutné vytvořit další tabulku. Vytvořte sloupec pro každou položku informací, kterou potřebujete sledovat. Pokud nejdou informace vypočítat z jiných sloupců, budete k nim pravděpodobně potřebovat nový sloupec.
- Jsou některé sloupce zbytečné, protože je možné je vypočítat z existujících polí? Pokud jde položku informací vypočítat z jiných existujících sloupců (například pomocí snížené ceny vypočítané z maloobchodní ceny), je obvykle lepší použít právě tento způsob a vyhnout se vytváření nového sloupce.
- Nezadáváte do některé z tabulek opakovaně duplicitní informace? V takovém případě budete pravděpodobně muset tabulku rozdělit na dvě tabulky s relací 1:N.
- Máte tabulky s mnoha poli, omezeným počtem záznamů a velkým množstvím prázdných polí v jednotlivých záznamech? Pokud ano, uvažujte o tom, že byste přepracovali tabulku, aby obsahovala méně polí a více záznamů.
- Byla každá informační položka rozdělena na nejmenší užitečné části? Pokud potřebujete vytvářet sestavy, řadit, vyhledávat nebo provádět výpočty s některou položkou informací, uveďte tuto položku do samostatného sloupce.
- Obsahuje každý sloupec fakt o předmětu tabulky? Pokud sloupec neobsahuje informace o předmětu tabulky, patří do jiné tabulky.
- Jsou všechny relace mezi tabulkami zastoupeny buď společnými poli, nebo třetí tabulkou? Relace 1:1 a 1:N vyžadují společné sloupce. Relace M:N vyžadují třetí tabulku.
Upřesnění tabulky Výrobky
Předpokládejme, že každý produkt v databázi prodeje produktů spadá do obecné kategorie, například nápoje, koření nebo mořské plody. Tabulka Produkty by mohla obsahovat pole, které zobrazuje kategorii každého produktu.
Předpokládejme, že po prozkoumání a upřesnění návrhu databáze se rozhodnete uložit popis kategorie spolu s jejím názvem. Pokud přidáte pole Popis kategorie do tabulky Produkty, je nutné zopakovat každý popis kategorie pro každý produkt, který do této kategorie spadá – to není dobré řešení.
Lepším řešením je udělat z kategorií nový předmět databáze, který bude sledovat, s vlastní tabulkou a vlastním primárním klíčem. Primární klíč z tabulky Kategorie pak můžete přidat do tabulky Produkty jako cizí klíč.
Tabulky Categories a Products jsou v relaci 1:N: kategorie může obsahovat více produktů, ale produkt může patřit pouze do jedné kategorie.
Při prohlížení struktury tabulky si všímejte opakujících se skupin. Představte si například tabulku obsahující následující sloupce:
- Product ID
- Name (Název)
- ID produktu 1
- Název1
- ID produktu 2
- Název2
- ID produktu 3
- Název3
Každý součin představuje opakující se skupinu sloupců, která se od ostatních liší pouze tím, že na konec názvu sloupce přidá číslo. Když uvidíte takto očíslované sloupce, měli byste svůj návrh přehodnotit.
Takový design má několik nedostatků. Pro začátek vás to nutí stanovit horní limit počtu produktů. Jakmile tento limit překročíte, musíte do struktury tabulky přidat novou skupinu sloupců, což je hlavní administrativní úkol.
Dalším problémem je, že dodavatelé, kteří mají méně než maximální počet produktů, budou plýtvat místem, protože další sloupce budou prázdné. Nejzávažnější chybou takového designu je, že ztěžuje provádění mnoha úloh, například řazení nebo indexování tabulky podle ID nebo názvu produktu.
Pokaždé, když uvidíte opakující se skupiny, pečlivě si prohlédněte návrh s ohledem na rozdělení tabulky na dvě části. V předchozím příkladu je lepší použít dvě tabulky, jednu pro dodavatele a druhou pro produkty, propojené pomocí ID dodavatele.
Použití normalizačních pravidel
Pravidla normalizace dat (někdy nazývaná pravidla normalizace) můžete použít jako další krok návrhu. Pomocí těchto pravidel můžete zkontrolovat, jestli jsou tabulky správně strukturované. Proces použití těchto pravidel v návrhu databáze se nazývá normalizace databáze, nebo jenom normalizace.
Normalizace je nejužitečnější, když jste reprezentovali všechny položky informací a dospěli k předběžnému návrhu. Cílem je pomoci vám zajistit, abyste měli informace rozdělené do příslušných tabulek. Normalizace nemůže zajistit, abyste měli všechny správné datové položky pro začátek.
Pravidla aplikujete postupně, v každém kroku zajišťujete, že váš návrh dospěje k jedné z takzvaných "normálních forem". Je široce přijímáno pět normálních forem – od první normální až po pátou normální formu. Tento článek rozšiřuje první tři, protože jsou vše, co je potřeba pro většinu návrhů databází.
První normální forma
První normální forma udává, že v každém průsečíku řádků a sloupců v tabulce existuje jedna hodnota, nikdy seznam hodnot. Například nemůžete mít pole s názvem Cena, do kterého zadáte více než jednu Cenu. Pokud si každý průsečík řádků a sloupců představíte jako buňku, může každá buňka obsahovat jenom jednu hodnotu.
Druhá normální forma
Druhá normální forma vyžaduje, aby každý neklíčový sloupec byl plně závislý na celém primárním klíči, nikoli pouze na jeho části. Toto pravidlo platí, pokud máte primární klíč, který se skládá z více sloupců. Předpokládejme například, že máte tabulku obsahující následující sloupce, kde primární klíč tvoří ID objednávky a ID produktu:
- ID objednávky (primární klíč)
- ID produktu (primární klíč)
- Název produktu
Tento návrh porušuje druhou normální formu, protože Název produktu závisí na ID produktu, ale ne na ID objednávky, takže není závislý na celém primárním klíči. Název výrobku musíte z tabulky odebrat. Patří do jiné tabulky (Produkty).
Třetí normální forma
Třetí normální forma vyžaduje, aby nejen všechny neklíčové sloupce byly závislé na celém primárním klíči, ale aby neklíčové sloupce byly na sobě nezávislé.
Jiný způsob, jak to říci, je, že každý neklíčový sloupec musí být závislý pouze na primárním klíči, a to pouze na primárním klíči. Předpokládejme například, že máte tabulku obsahující následující sloupce:
- IDProduktu (primární klíč)
- Name (Název)
- SRP
- Diskont_sazba:
Předpokládejme, že sleva závisí na doporučené maloobchodní ceně. Tato tabulka porušuje třetí normální formu, protože sloupec Discount, který není klíčový, závisí na jiném neklíčovém sloupci (SRP). Nezávislost sloupce znamená, že byste měli mít možnost změnit kterýkoli sloupec, který není klíčový, aniž by to ovlivnilo kterýkoli jiný sloupec. Pokud změníte hodnotu v poli SRP, změní se odpovídajícím způsobem sleva, čímž se toto pravidlo poruší. V takovém případě by měla být možnost Sleva přesunuta do jiné tabulky, která má klíč SRP.