Správně navržená databáze poskytuje 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í, dává smysl investovat čas potřebný k seznámení se s principy správného návrhu. Nakonec je mnohem pravděpodobnější, že skončíte s databází, která vyhovuje 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 je rozdělit do příslušných tabulek a sloupců a jak spolu tyto tabulky vzájemně souvisejí. Před vytvořením první desktopové databáze byste si měli přečíst tento článek.
V tomto článku
Některé termíny databáze, které je potřeba znát
Access uspořádá informace do tabulek: seznamy řádků a sloupců, které připomínají panel účetního nebo tabulku. V jednoduché databázi můžete mít jenom jednu tabulku. U většiny databází budete potřebovat více databází. Můžete mít například tabulku, která ukládá informace o produktech, jinou tabulku s informacemi o objednávkách a jinou tabulku s informacemi o zákaznících.
Každý řádek se správně nazývá záznam a každý sloupec je pole. Záznam je smysluplný a konzistentní způsob, jak o něčem zkombinovat informace. Pole je jedna položka informací – typ položky, která se zobrazuje v každém záznamu. V tabulce Products by například každý řádek nebo záznam obsahovat informace o jednom produktu. Každý sloupec nebo pole obsahuje určitý typ informací o daném produktu, například jeho název nebo cenu.
Co je dobrý návrh databáze?
Proces návrhu databáze řídí určité principy. Prvním principem je, že duplicitní informace (označované také jako redundantní data) jsou špatné, protože plýtví místem a zvyšuje pravděpodobnost chyb a nekonzistence. Druhým principem je, že správnost a úplnost informací je důležitá. Pokud databáze obsahuje nesprávné informace, všechny sestavy, které z databáze přebují informace, budou také obsahovat nesprávné informace. V důsledku toho budou veškerá rozhodnutí, která na těchto sestavách uděláte, chybně informovaná.
Dobrý návrh databáze je proto takový, který:
-
Rozdělí informace do tabulek založených na předmětech a omezí tak redundantní data.
-
Poskytuje Accessu informace, které potřebuje ke spojení informací v tabulkách podle potřeby.
-
Pomáhá podporovat a zajišťovat přesnost a integritu vašich informací.
-
Vyhovuje vašim požadavkům na 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 připravit se na zbývající kroky.
-
Vyhledání a uspořádání požadovaných informací:
Shromážděte všechny typy informací, které můžete chtít v databázi zaznamenat, například název produktu a číslo objednávky.
-
Rozdělení informací do tabulek
Rozdělte 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řevod informačních položek na sloupce
Rozhodněte se, jaké informace chcete do jednotlivých tabulek uložit. Každá položka se stane polem a zobrazí se jako sloupec v tabulce. Tabulka Zaměstnanci může například obsahovat pole Příjmení a Datum přijetí.
-
Zadání primárních klíčů
Zvolte primární klíč každé tabulky. Primární klíč je sloupec, který slouží k jedineč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 jednotlivé tabulky a rozhodněte, jak data v jedné tabulce souvisí s daty v jiných tabulkách. Přidejte pole do tabulek nebo vytvořte nové tabulky, abyste podle potřeby zpřehlednili relace.
-
Upřesnění návrhu
Analyzujte v návrhu chyby. Vytvořte tabulky a přidejte několik záznamů ukázkových dat. Podívejte se, jestli můžete z tabulek získat požadované výsledky. Podle potřeby upravte návrh.
-
Použití pravidel normalizace
Pomocí pravidel normalizace dat zjistěte, jestli jsou tabulky správně strukturované. Podle potřeby upravte tabulky.
Určení účelu databáze
Účel databáze je vhodné si napsat na papír – její účel, jak ji očekáváte používat a kdo ji bude používat. Například pro malou databázi pro domácí firmu můžete napsat něco jednoduchého jako "Databáze zákazníka uchovává seznam informací o zákaznících za účelem vytváření adresátů 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é lze odkazovat v průběhu 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 svými stávajícími informacemi. Můžete například zaznamenávat nákupní objednávky do registru nebo uchovávat informace o zákaznící na papírových formulářích v kartotéce. Shromážděte tyto dokumenty a zobrazte seznam jednotlivých typů zobrazených informací (například každé pole, které vyplníte ve formuláři). Pokud nemáte žádné existující formuláře, představte si, že místo toho musíte navrhnout formulář pro záznam informací o zákazníkovi. Jaké informace byste do formuláře dali? Jaká pole byste vytvořili? Identifikujte a vypište každou z těchto položek. Předpokládejme například, že aktuálně udržujete seznam zákazníků na indexových kartách. Při zkoumání těchto karet se může ukázat, že každá karta obsahuje jméno, adresu, město, stát, PSČ a telefonní číslo zákazníka. Každá z těchto položek představuje potenciální sloupec v tabulce.
Při přípravě tohoto seznamu se nemusíte zpočátku starat o to, aby byl dokonalý. Místo toho uveďte seznam všech položek, které vám přijdou na mysl. Pokud bude databázi používat někdo jiný, zeptejte se také na jeho nápady. Seznam můžete vyladit později.
Dále zvažte typy sestav nebo korespondencí, které byste mohli chtít z databáze vytvořit. Můžete například chtít, aby sestava prodeje produktů zobrazovala prodej podle oblastí nebo sestavu souhrnu zásob, která zobrazuje úrovně skladových zásob produktů. Můžete také chtít generovat formulářové dopisy, které budou posílat zákazníkům, kteří oznamují prodejní událost nebo nabízejí premium. Navrhněte si sestavu podle svých představ a představte si, jak by vypadala. Jaké informace byste do sestavy umístili? Vypsat jednotlivé položky. To samé udělejte pro formulářový dopis a pro jakoukoli jinou sestavu, kterou očekáváte vytvořit.
Když si promyslíte sestavy a korespondence, 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 dáváte zákazníkům možnost přihlásit se k pravidelným e-mailovým aktualizacím (nebo se z nich odhlásit) a chcete vytisknout výpis těch, kteří se k odběru přihlásili. Pokud chcete tuto informaci zaznamenat, přidejte do tabulky zákazníka sloupec Odeslat e-mail. U každého zákazníka můžete pole nastavit na Ano nebo Ne.
Požadavek na odesílání e-mailových zpráv zákazníkům navrhuje jinou položku k záznamu. 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 ho chcete poslat. Proto musíte 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 prozkoumáte formulářový dopis, může vás napadnout pár věcí. Pokud chcete zahrnout správné oslovení – například řetězec "Pan", "Paní." nebo "Paní", který začíná pozdravem, budete muset vytvořit položku pozdravu. Můžete také obvykle začínat dopis "Vážený pane Smithe", nikoli "Drahý. Pan Sylvester Smith" To naznačuje, že byste obvykle chtěli uložit příjmení odděleně od jména.
Klíčovým bodem, který je třeba si zapamatovat, je, že byste měli rozdělit jednotlivé informace na jejich nejmenší užitečné části. V případě jména rozdělíte příjmení na dvě části : Jméno a Příjmení. Pokud například chcete sestavu seřadit podle příjmení, je užitečné mít příjmení zákazníka uložené odděleně. Obecně platí, že pokud chcete řadit, prohledávat, počítat nebo sestavy založené na položce informací, měli byste tuto položku umístit do jejího vlastního pole.
Zamyslete se nad tím, na které otázky by mohla databáze odpovídat. Například kolik prodejů vašeho doporučeného produktu jste minulý měsíc uzavřeli? Kde bydlí 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 spoléhat se na další položky, které chcete 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 nebo témata. Například po vyhledání a uspořádání informací pro databázi prodeje produktů může předběžný seznam vypadat takto:
Hlavními entitami, které se zde zobrazují, 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 druhá pro fakta o objednávkách. I když se tím seznam nedokončí, je to dobrý výchozí bod. Tento seznam můžete dál upřesňovat, dokud nebudete mít návrh, který bude fungovat dobře.
Když si poprvé projdete předběžný seznam položek, můžete být v pokušení umístit je všechny do jedné tabulky místo čtyř zobrazených na předchozím obrázku. Tady se dozvíte, proč je to špatný nápad. Zvažte na chvíli tabulku, která je tady zobrazená:
V tomto případě každý řádek obsahuje informace o produktu i jeho dodavateli. Vzhledem k tomu, že můžete mít mnoho produktů od stejného dodavatele, musí se jméno a adresa dodavatele mnohokrát opakovat. To plýtvá místem na disku. Mnohem lepším řešením je zaznamenání informací o dodavateli pouze jednou do samostatné tabulky Dodavatelé a následné propojení této tabulky s tabulkou Produkty.
Druhý problém s tímto návrhem nastává, když potřebujete upravit informace o dodavateli. Předpokládejme například, že potřebujete změnit adresu dodavatele. Vzhledem k tomu, že se zobrazuje na mnoha místech, můžete omylem změnit adresu na jednom místě, ale zapomněli jste ji změnit na ostatních místech. Záznam adresy dodavatele pouze na jednom místě vyřeší problém.
Při návrhu databáze se vždy pokuste zaznamenat každou skutečnost jen jednou. Pokud zjistíte, že stejné informace opakujete na více než jednom místě, například na adrese konkrétního dodavatele, umístěte tyto informace do samostatné tabulky.
Nakonec předpokládejme, že existuje pouze jeden produkt dodávaný společností Coho Winery a chcete produkt odstranit, ale zachovat jméno a adresu dodavatele. Jak byste odstranili záznam o produktu bez ztráty informací o dodavateli? Nemůžeš. Vzhledem k tomu, že každý záznam obsahuje fakta o produktu i fakta o dodavateli, nemůžete jeden z nich odstranit bez odstranění druhého. Pokud chcete tyto skutečnosti oddělit, musíte jednu tabulku rozdělit na dvě: jednu tabulku pro informace o produktech a druhou tabulku pro informace o dodavateli. Odstraněním záznamu o produktu by se měly odstranit pouze fakta o produktu, nikoli fakta o dodavateli.
Jakmile zvolíte předmět, který je reprezentován tabulkou, měly by sloupce v této tabulce obsahovat pouze fakta o předmětu. Například tabulka produktů by měla obsahovat pouze fakta o produktech. Vzhledem k tomu, že adresa dodavatele je fakt o dodavateli, a ne fakt o produktu, patří do tabulky dodavatelů.
Převádění položek informací 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 Customers (Zákazníci) se dobrým počátečním seznamem sloupců tvoří název, adresa, město-stát-zip, odeslat e-mail, oslovení a e-mailová adresa. Každý záznam v tabulce obsahuje stejnou sadu sloupců, takže pro každý záznam můžete uložit informace o jménu, adrese, městu a státu zip, odeslání e-mailu, oslovení a e-mailové adrese. Sloupec adresa například obsahuje adresy zákazníků. Každý záznam obsahuje data o jednom zákazníkovi a pole adresa obsahuje adresu daného zákazníka.
Jakmile určíte počáteční sadu sloupců pro každou tabulku, můžete sloupce dále upřesnit. Například má smysl uložit jméno zákazníka jako dva samostatné sloupce: jméno a příjmení, abyste mohli řadit, hledat a indexovat jenom v těchto sloupcích. Podobně se adresa ve skutečnosti skládá z pěti samostatných složek: adresy, města, státu, PSČ a země/oblasti a dává také smysl je ukládat do samostatných sloupců. Pokud chcete například provést operaci vyhledávání, filtrování nebo řazení podle stavu, potřebujete informace o stavu uložené v samostatném sloupci.
Měli byste také zvážit, jestli databáze bude obsahovat informace, které jsou pouze domácího původu, nebo mezinárodní. Pokud například plánujete ukládat mezinárodní adresy, je lepší mít místo sloupce Stát sloupec Oblast, protože takový sloupec může obsahovat jak domácí státy, tak oblasti jiných zemí nebo oblastí. Podobně, PSČ 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ů, jak určit sloupce.
-
Nezahrnovat počítaná data
Ve většině případů byste neměli ukládat výsledky výpočtů do tabulek. Místo toho můžete, aby Access provedl výpočty, když chcete zobrazit výsledek. Předpokládejme například, že existuje sestava Produkty v objednávce, která zobrazuje mezisoučet jednotek v objednávce pro každou kategorii produktu v databázi. V žádné tabulce ale není žádný sloupec mezisoučtu Jednotek v pořadí. Místo toho tabulka Products (Produkty) obsahuje sloupec Units On Order (Jednotky v objednávce), ve kterém jsou uložené jednotky v objednávce pro každý produkt. Na základě těchto dat Access vypočítá mezisoučet při každém tisku sestavy. Samotný souhrn by neměl být uložen v tabulce.
-
Ukládání informací v nejmenších logických částech
Můžete být v pokušení mít jedno pole pro celá jména nebo pro názvy produktů spolu s popisy produktů. Pokud v poli zkombinujete více než jeden druh informací, bude obtížné později načíst jednotlivá fakta. Pokuste se rozdělit informace do logických částí; Můžete například vytvořit samostatná pole pro jméno a příjmení nebo pro název produktu, kategorii a popis.
Po upřesnění datových sloupců v každé tabulce můžete 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é jednoznačně 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 tyto informace označují jako 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 spojování za vás.
Pokud už máte jedinečný identifikátor tabulky, například číslo produktu, které jednoznačně identifikuje jednotlivé produkty v katalogu, můžete tento identifikátor použít jako primární klíč tabulky – ale jenom v případě, že hodnoty v tomto sloupci budou pro každý záznam vždy jiné. V primárním klíči nelze mít duplicitní hodnoty. Nepoužívejte například jména lidí jako primární klíč, protože jména nejsou jedinečná. Ve stejné tabulce můžete snadno mít dva lidi se stejným jménem.
Primární klíč musí mít vždy hodnotu. Pokud se hodnota sloupce může v určitém okamžiku stát nepřiřazenou nebo neznámou (chybějící hodnotou), nedá se použít jako součást primárního klíče.
Vždy byste měli zvolit primární klíč, jehož hodnota se nezmění. V databázi, která používá více než jednu tabulku, lze primární klíč tabulky použít jako odkaz v jiných tabulkách. Pokud se primární klíč změní, musí se tato změna použít také všude, kde se na klíč odkazuje. Použití primárního klíče, který se nezmění, snižuje pravděpodobnost, že se primární klíč nemusí synchronizovat s jinými tabulkami, které na něj odkazují.
Často se jako primární klíč 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 identifikace objednávky. Po přiřazení se nikdy nezmění.
Pokud nemáte na mysli sloupec nebo sadu sloupců, které by mohly být dobrým primárním klíčem, zvažte použití sloupce s datovým typem Automatické číslo. Když použijete datový typ Automatické číslo, Access vám automaticky přiřadí hodnotu. Takový identifikátor je bez faktu; neobsahuje žádné faktické informace popisující řádek, který představuje. Identifikátory bez faktů jsou ideální pro použití jako primární klíč, protože se nemění. Primární klíč, který obsahuje fakta o řádku – například telefonní číslo nebo jméno zákazníka – se s větší pravděpodobností změní, protože samotné faktické informace se můžou změnit.
1. Sloupec nastavený na datový typ Automatické číslo často představuje dobrý primární klíč. Žádná dvě ID produktů nejsou stejná.
V některých případech můžete chtít použít dvě nebo více polí, která společně poskytují primární klíč tabulky. Například tabulka Podrobnosti objednávky, která ukládá řádkové položky pro objednávky, by ve svém primárním klíči používala dva sloupce: ID objednávky a ID produktu. Pokud primární klíč využívá více než jeden sloupec, označuje se také jako složený klíč.
Pro databázi prodeje produktů můžete pro každou z tabulek vytvořit sloupec Automatické číslo, který bude sloužit jako primární klíč: IDproduktu pro tabulku Produkty, IDobjednávky pro tabulku Objednávky, ID zákazníka pro tabulku Zákazníci a ID dodavatele pro tabulku Dodavatelé.
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. ... the Products table...
5. ... a tabulku Podrobnosti objednávky.
Access je systém pro správu relačních databází. V relační databázi rozdělíte informace do samostatných tabulek založených na předmětech. Pomocí relací mezi tabulkami pak podle potřeby spojíte informace dohromady.
Vytvoření relace 1:N
Podívejme se na tento příklad: tabulky Dodavatelé a Produkty v databázi objednávek produktů. Dodavatel může dodat libovolný počet produktů. Z toho vyplývá, že pro každého dodavatele zastoupeného v tabulce Dodavatelé může být v tabulce Výrobky zastoupeno mnoho produktů. Relace mezi tabulkou Suppliers (Dodavatelé) a tabulkou Products (Produkty) je proto relace 1:N.
Pokud chcete v návrhu databáze reprezentovat relaci 1:N, vezměte primární klíč na straně "1" relace a přidejte ho 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 pak může použít číslo ID dodavatele v tabulce Produkty k vyhledání správného dodavatele pro každý produkt.
Sloupec ID dodavatele v tabulce Products se nazývá cizí klíč. Cizí klíč je primárním klíčem jiné tabulky. Sloupec ID dodavatele v tabulce Products (Produkty) je cizí klíč, protože je také primárním klíčem v tabulce Dodavatelé.
Základem pro spojování souvisejících tabulek je vytvoření párování primárních a cizích klíčů. Pokud si nejste jistí, které tabulky by měly sdílet společný sloupec, identifikace relace 1:N zajistí, že obě tabulky budou skutečně vyžadovat sdílený sloupec.
Vytvoření relace M:N
Vezměte v úvahu relaci mezi tabulkou Products (Produkty) a tabulkami Orders (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 Produkty může být mnoho záznamů v tabulce Objednávky. Tento typ relace se nazývá relace M:N, protože pro každý produkt může existovat mnoho objednávek; a pro každou objednávku, tam může být mnoho produktů. Mějte na paměti, že pokud chcete mezi tabulkami rozpoznat relace M:N, je důležité zvážit obě strany relace.
Předměty těchto dvou tabulek – objednávky a produkty – mají relaci M:N. To představuje problém. Abyste pochopili problém, představte si, co by se stalo, kdybyste se pokusili vytvořit relaci mezi těmito dvěma tabulkami přidáním pole Id produktu do tabulky Objednávky. Pokud chcete mít na objednávku více než jeden produkt, potřebujete v tabulce Objednávky pro každou objednávku více než jeden záznam. Opakujte informace o objednávce pro každý řádek, který souvisí s jedním pořadím, což vede k neefektivnímu návrhu, který by mohl vést k nepřesným datům. Ke stejnému problému dojde, pokud do tabulky Produkty vložíte pole Id objednávky – v tabulce Produkty byste měli pro každý produkt více než jeden záznam. Jak tento problém vyřešíte?
Odpovědí je vytvořit třetí tabulku, která se často označuje 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 důsledku toho třetí tabulka zaznamenává každý výskyt nebo instanci relace.
Každý záznam v tabulce Podrobnosti objednávky představuje jednu řádkovou položku v objednávce. Primární klíč tabulky Podrobnosti objednávky se skládá ze dvou polí – cizích klíčů z tabulek Objednávky a Produkty. Použití samotného pole ID objednávky nefunguje jako primární klíč pro tuto tabulku, protože jedna objednávka může obsahovat mnoho řádkových položek. ID objednávky se opakuje pro každou položku řádku objednávky, takže pole neobsahuje jedinečné hodnoty. Použití samotného pole Id produktu také nefunguje, protože jeden produkt se může zobrazovat v mnoha různých objednávkách. Obě pole ale společně vždy vytvoří jedinečnou hodnotu pro každý záznam.
V prodejní databázi produktů spolu tabulka Objednávky a Produkty přímo nesouvisí. Místo toho jsou propojeny nepřímo prostřednictvím tabulky Podrobnosti objednávky. Relace M:N mezi objednávkami a produkty je v databázi reprezentována pomocí dvou relací 1:N:
-
Tabulka Objednávky a Podrobnosti objednávky mají relaci 1:N. Každá objednávka může obsahovat více než jednu položku řádku, ale každá položka řádku je připojená pouze k jedné objednávce.
-
Tabulka Products (Produkty) a Order Details (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 Podrobnosti objednávky můžete určit všechny produkty na konkrétní objednávce. Můžete také určit všechny objednávky konkrétního produktu.
Po zahrnutí tabulky Podrobnosti objednávky 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ěkteré zvláštní doplňující informace o produktech, které budete potřebovat jen zřídka nebo které se týkají pouze několika produktů. Vzhledem k tomu, že tyto informace často nepotřebujete a uložení informací v tabulce Produkty by vedlo k prázdnému místu pro každý produkt, na který se nevztahují, umístíte je do samostatné tabulky. Podobně jako v tabulce Products (Produkty) použijete jako primární klíč Idproduktu. Relace mezi touto doplňkovou tabulkou a tabulkou Product je relace 1:1. Pro každý záznam v tabulce Product 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.
Když v databázi zjistíte potřebu relace 1:1, zvažte, jestli můžete informace z těchto dvou tabulek dát dohromady 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 v návrhu reprezentovali relaci:
-
Pokud mají obě tabulky stejný předmět, můžete pravděpodobně nastavit relaci pomocí stejného primárního klíče v obou tabulkách.
-
Pokud mají obě tabulky různé předměty s různými primárními klíči, zvolte jednu z tabulek (jednu 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 správné tabulky a sloupce. Pokud existuje relace 1:1 nebo 1:N, musí dané tabulky sdílet společný sloupec nebo sloupce. Pokud existuje relace M:N, k reprezentaci relace je potřeba třetí tabulka.
Upřesnění návrhu
Jakmile budete mít potřebné tabulky, pole a relace, měli byste tabulky vytvořit a naplnit ukázkovými daty a zkusit s nimi pracovat: vytváření dotazů, přidávání nových záznamů atd. To pomůže zvýraznit potenciální problémy – například budete muset 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 do dvou tabulek, aby se odstranila duplicita.
Podívejte se, jestli můžete použít databázi k získání požadovaných odpovědí. Vytvářejte hrubé koncepty formulářů a sestav a zjistěte, jestli zobrazují očekávaná data. Hledejte zbytečné duplikování dat, a když nějaké najdete, upravte návrh tak, abyste je odstranili.
Při vyzkoušení počáteční databáze pravděpodobně zjistíte prostor pro zlepšení. Tady je pár věcí, které můžete zkontrolovat:
-
Zapomněli jste nějaké sloupce? Pokud ano, patří informace do existujících tabulek? Pokud se jedná o informace o něčem jiném, možná budete muset vytvořit jinou tabulku. Vytvořte sloupec pro každou položku informací, kterou potřebujete sledovat. Pokud se informace nedají vypočítat z jiných sloupců, je pravděpodobné, že pro ni budete potřebovat nový sloupec.
-
Nejsou některé sloupce zbytečné, protože je možné je vypočítat z existujících polí? Pokud je možné položku informací vypočítat z jiných existujících sloupců – například ze zvýhodněné ceny vypočítané z maloobchodní ceny – je obvykle lepší udělat právě to a vyhnout se vytváření nového sloupce.
-
Zadáváte do některé z tabulek opakovaně duplicitní informace? Pokud ano, budete pravděpodobně muset tabulku rozdělit do dvou tabulek, které mají relaci 1:N.
-
Máte tabulky s mnoha poli, omezeným počtem záznamů a mnoha prázdnými poli v jednotlivých záznamech? Pokud ano, zamyslete se nad tím, jak tabulku přepracovat tak, aby v ní bylo méně polí a více záznamů.
-
Byla každá informační položka rozdělena na své nejmenší užitečné části? Pokud potřebujete vytvořit sestavu, seřadit, hledat nebo počítat s položkou informací, vložte tuto položku do jejího vlastní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 reprezentované 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 Products
Předpokládejme, že každý produkt v databázi prodeje produktů spadá do obecné kategorie, jako jsou nápoje, koření nebo mořské plody. Tabulka Products (Produkty) může obsahovat pole, které zobrazuje kategorii jednotlivých produktů.
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 do tabulky Produkty přidáte pole Popis kategorie, budete muset opakovat popis každé kategorie pro každý produkt, který spadá do dané kategorie – to není dobré řešení.
Lepším řešením je nastavit kategorie jako nový předmět, který bude databáze sledovat, s vlastní tabulkou a vlastním primárním klíčem. Pak můžete přidat primární klíč z tabulky Kategorie do tabulky Products jako cizí klíč.
Tabulky Kategorie a Produkty mají relaci 1:N: Kategorie může obsahovat více než jeden produkt, ale produkt může patřit jenom do jedné kategorie.
Při kontrole struktur tabulek hledejte opakující se skupiny. 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
Tady je každý produkt opakující se skupinou sloupců, která se liší od ostatních pouze přidáním čísla na konec názvu sloupce. Když uvidíte sloupce očíslované tímto způsobem, měli byste se k návrhu vrátit znovu.
Takový návrh má několik chyb. Pro začátek vás nutí, abyste u počtu produktů událi horní limit. 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ýttváním místem, protože další sloupce budou prázdné. Nejzávažnější chybou takového návrhu je to, že znesnadňuje provádění mnoha úloh, jako je řazení nebo indexování tabulky podle ID produktu nebo názvu.
Kdykoli uvidíte opakující se skupiny, pečlivě si prohlédněte návrh a podívejte se na rozdělení tabulky na dvě části. Ve výše uvedeném příkladu je lepší použít dvě tabulky, jednu pro dodavatele a druhou pro produkty propojené id dodavatele.
Použití pravidel normalizace
Pravidla normalizace dat (někdy označovaná jako pravidla normalizace) můžete použít jako další krok v návrhu. Pomocí těchto pravidel můžete zjistit, jestli jsou tabulky správně strukturované. Proces použití pravidel v návrhu databáze se nazývá normalizace databáze nebo jen normalizace.
Normalizace je nejužitečnější poté, co jste reprezentovali všechny položky informací a dospěli k předběžnému návrhu. Cílem je pomoct zajistit, že jste informační položky rozdělili do příslušných tabulek. Normalizace nemůže zajistit, abyste měli všechny správné datové položky.
Pravidla použijete postupně a v každém kroku zajistíte, že návrh dospěje k některé z těch, které se označují jako "normální formy". Pět normálních forem je široce přijímáno – první normální forma až po pátou normální formu. Tento článek se rozšiřuje o první tři, protože jsou všechny potřebné pro většinu návrhů databází.
První normální forma
První normální formulář uvádí, že při každém průniku řádků a sloupců v tabulce existuje jedna hodnota a nikdy seznam hodnot. Například nemůžete mít pole s názvem Cena, do kterého umístíte více než jednu cenu. Pokud si každý průnik řádků a sloupců myslí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ý sloupec, který není klíčem, byl plně závislý na celém primárním klíči, nikoli pouze na části klíče. Toto pravidlo platí, pokud máte primární klíč, který se skládá z více než jednoho sloupce. 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 produktu musíte z tabulky odebrat. Patří do jiné tabulky (Products).
Třetí normální forma
Třetí normální forma vyžaduje, aby každý sloupec, který není klíčem, byl závislý na celém primárním klíči, ale aby sloupce, které nejsou klíčem, byly nezávislé na sobě navzájem.
Dalším způsobem, jak to říct, je, že každý sloupec, který není klíčem, musí být závislý na primárním klíči a nic kromě primárního klíče. Předpokládejme například, že máte tabulku obsahující následující sloupce:
-
ProductID (primární klíč)
-
Name (Název)
-
SRP
-
Diskont_sazba:
Předpokládejme, že sleva závisí na navrhované maloobchodní ceně (SRP). Tato tabulka porušuje třetí normální formu, protože sloupec, který není klíč, Discount, závisí na jiném sloupci, který není klíčem, SRP. Nezávislost sloupce znamená, že byste měli být schopni změnit libovolný sloupec, který není klíčem, aniž by to mělo vliv na jiný sloupec. Pokud změníte hodnotu v poli SRP, sleva se odpovídajícím způsobem změní, čímž dojde k porušení tohoto pravidla. V tomto případě by se sleva měla přesunout do jiné tabulky, která má klíč v SRP.
