Základy návrhu databáze

Základy návrhu databáze

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 pro dosažení vašich cílů při práci s databází velmi důležitý, vy investicem času nezbytného k se získejte principy vhodného návrhu. Na konci je mnohem pravděpodobnější, že nakonec budete mít k dispozici databázi, která bude splňovat vaše potřeby a snadno se přizpůsobí změně.

Tento článek obsahuje pokyny pro plánování desktopové databáze. Naučí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ě souvisí. Tento článek byste si měli přečíst před vytvořením první desktopové databáze.

Důležité informace: Access poskytuje možnosti návrhu, které vám umožňují vytvářet databázové aplikace pro web. Při návrhu pro web je jiná řada věcí, které je třeba vzít v úvahu. Tento článek se nezabývá návrhem aplikace webové databáze. Další informace najdete v článku Vytvoření databáze pro sdílení na webu.

V tomto článku


Některé databázové termíny, které je dobré vědět

Access informace uspořádá dotabulek: seznamy řádků a sloupců si připomínají panel účetního nebo tabulku. V jednoduché databázi může být jenom jedna tabulka. U většiny databází budete potřebovat více než jednu databázi. Můžete mít třeba tabulku, ve které jsou informace o produktech, další tabulka, která uchovává informace o objednávkách, a další tabulku s informacemi o zákaznících.

Obrázek znázorňující tři tabulky v datových listech

Každý řádek se správněji nazývá záznama každý sloupec – pole. Záznam je smysluplný a konzistentní způsob kombinování informací o něčem. Pole je jedna položka informací – typ položky, který se zobrazuje ve všech záznamech. V tabulce Výrobky by například každý řádek nebo záznam uchová informace o jednom produktu. Každý sloupec nebo pole obsahuje typ informací o produktu, například jeho název nebo cenu.

Začátek stránky

Co je dobrý návrh databáze?

Určitým principům se proces návrhu databáze řídit. Nejdřív je důležité, aby duplicitní informace (nazývané taky redundantní data) byly špatné, protože plýtvá prostorem a zvyšuje se pravděpodobnost chyb a nekoziferencí. Druhým hlavní je to, že je důležitá správnost a úplnost informací. Pokud databáze obsahuje nesprávné informace, budou v sestavách, které natahovat informace z databáze, také nesprávné informace. Všechna vaše rozhodnutí založená na těchto sestavách se tak budou mít mylně dezformátovaná.

Dobrý návrh databáze je tedy ten, který:

  • Rozdělí informace do tabulek s předměty, aby se snížila redundantní data.

  • Poskytuje Accessu informace potřebné ke spojení informací v tabulkách podle potřeby.

  • Pomáhá podporovat a zajistit přesnost a integritu informací.

  • Přizpůsobí se vašim potřebám na zpracování dat a vytváření sestav.

Začátek stránky

Proces návrhu

Proces návrhu se skládá z následujících kroků:

  • Určení účelu databáze:    

    Pomůže vám to 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 do databáze zaznamenávat, 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 například Produkty nebo Objednávky. Každý předmět se pak změní na tabulku.

  • Proměna informačních položek na sloupce    

    Rozhodněte se, jaké informace chcete v jednotlivých tabulkách ukládat. Každá položka se stane polem a zobrazí se jako sloupec v tabulce. Tabulka Zaměstnanci může například obsahovat pole jako Příjmení a Datum platnosti zaměstnance.

  • Zadání primárních klíčů    

    Vyberte primární klíč každé tabulky. Primární klíč je sloupec, který slouží k jedinečné identifikaci jednotlivých řádků. Příkladem může být ID výrobku nebo ID objednávky.

  • Nastavení relací mezi tabulkami    

    Prohlédněte si jednotlivé tabulky a rozhodněte se, jak data v jedné tabulce souvisí s daty v jiných tabulkách. Přidejte do tabulek pole nebo vytvořte nové tabulky, aby relace podle potřeby zpřesnily.

  • Upřesnění návrhu    

    Analyzujte chyby v návrhu. Vytvořte tabulky a přidejte několik záznamů ukázkových dat. Podívejte se, jestli můžete z tabulek získat výsledky, které potřebujete. Podle potřeby proveďte úpravy návrhu.

  • Použití pravidel normalizace    

    Použijte pravidla pro normalizaci dat a podívejte se, jestli jsou tabulky správně strukturované. Podle potřeby tabulky proveďte úpravy.

Začátek stránky

Určení účelu databáze

Je vhodné si účel databáze zapsat na papíře – její účel, jak ji očekáváte používat a kdo ji bude používat. U malé databáze pro domácí firmu můžete například napsat něco jednoduchého, třeba "Databáze zákazníků uchovává seznam informací o zákaznících pro účely vytvoření korespondence a sestav". Pokud je databáze složitější nebo ji používá mnoho lidí, tak často se vyskytuje v podnikovém nastavení, může být účelem odstavec či více a měl by zahrnovat kdy a jak bude každý z nich databázi používat. Cílem je mít dobře vyvinutý prohlášení o poslání, na které se může v průběhu procesu návrhu odkazovat. Když takový prohlášení použijete, budete se při rozhodování soustředit na své cíle.

Začátek stránky

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 zaznamenat nákupní objednávky v hlavní knihy nebo ponechat informace o zákazníkách na papírových formulářích v souborové sféře. Shromážděte tyto dokumenty a vypište seznam všech typů zobrazených informací (například každé pole, které vyplníte do formuláře). Pokud nemáte žádné existující formuláře, představte si, že byste měli navrhnout formulář, abyste se do něj veškoli informace o zákazníkovi. Jaké informace byste do formuláře dali? Která pole s vyplňováním byste vytvořili? Každou z těchto položek určete a vyděste. Předpokládejme například, že momentálně máte seznam zákazníků na indexových kartách. Na těchto kartách se může zobrazit, ž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 bát, že byste ho ze nejdřív měli dobře nachycené. Místo toho vysílte každou položku, která vám přijde vhod. Pokud databázi bude používat někdo jiný, požádejte také o jejich nápady. Seznam můžete později doladit.

Potom zvažte typy sestav nebo korespondence, které chcete z databáze vytvořit. Můžete například chtít, aby sestava prodeje produktu znázorňuje prodeje podle oblastí nebo souhrnná sestava zásob zobrazující úrovně skladových zásob produktů. Můžete také chtít vygenerovat formulářové dopisy, které pošlete zákazníkům, kteří oznámí prodejní událost nebo nabízejí prémiovou verzi. Představte si sestavu a představte si, jak by vypadala. Jaké informace byste měli do sestavy umístit? Zobrazí každou položku v seznamu. Totéž proveďte pro formulářové dopisy i pro jakoukoli jinou sestavu, kterou očekáváte vytvořením.

Osoba představující si sestavu skladových zásob produktu

Když si promyslíte sestavy a korespondence, které byste si 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 příležitost přihlásit se k pravidelným aktualizacím e-mailu (nebo se z něj odhlásit) a chcete vytisknout seznam těch, kteří se k této možnosti rozhodli. Pokud chcete tyto informace zaznamenat, přidejte do tabulky zákazníků sloupec Odeslat e-mail. U každého zákazníka můžete toto pole nastavit na Ano nebo Ne.

Požadavek na odeslání e-mailových zpráv zákazníkům navrhuje další položku k zaznamenání. Až budete vědět, že zákazník chce dostávat e-mailové zprávy, budete taky potřebovat znát e-mailovou adresu, na kterou je chcete poslat. Proto je potřeba nahrát e-mailovou adresu každého zákazníka.

Má smysl vytvořit prototyp každé sestavy nebo zápisu výstupu a zvážit, které položky budete potřebovat k vytvoření sestavy. Třeba když budete formulářové dopis zkoumat, může vás přimět pár věcí. Pokud chcete přidat oslovení pan, např. pan, "pan", "m." nebo "m.", který načte pozdrav, je třeba vytvořit oslovení. Můžete také obvykle napsat dopis vážený pane Nováku, nikoli "Vážený pane Novák". Pan Sy užír Šmídová Novák". To navrhne, že byste obvykle chtěli uložit příjmení oddělené od jména.

Důležité je pamatovat na to, že byste měli každou informaci rozdělit na co nejmenší užitečné části. Pokud chcete u jména zajistit, aby bylo příjmení snadno dostupné, můžete ho rozdělit na dvě části – jméno a příjmení. Pokud například chcete seřadit sestavu podle příjmení, je dobré mít příjmení zákazníka uložené samostatně. Pokud chcete obecně řadit, vyhledávat, počítat nebo sestavovat na základě 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. Například kolik prodejů vybraného produktu jste minulý měsíc zamkl(a)? Kde žijí vaši nejlepší zákazníci? Kdo je dodavatelem vašeho nejprodávanějšího produktu? S těmito otázkami se můžete snáz najít další položky, které je dobré zaznamenat.

Po shromáždění těchto informací jste připraveni na další krok.

Začátek stránky

Rozdělení informací do tabulek

Pokud chcete informace rozdělit na tabulky, zvolte hlavní entity nebo předměty. Třeba po vyhledání a uspořádání informací pro databázi prodeje produktů může předběžný seznam vypadat takhle:

Rukou psané údaje seskupené do předmětů

Zobrazené hlavní entity jsou výrobky, dodavatelé, zákazníci a objednávky. Má proto smysl začít 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ž se tím seznam nevyplní, je to dobrý výchozí bod. Tento seznam můžete dál upřesníte, dokud nebude návrh, který bude dobře fungovat.

Při prvním zobrazení předběžného seznamu položek může být lákavé umístit je všechny do jedné tabulky místo čtyř, které jsou uvedené na předchozím obrázku. Dozvíte se tady, proč je to špatný nápad. Zvažte na chvíli tabulku, která je tady:

Obrázek tabulky obsahující produkty a dodavatele

V tomto případě obsahuje každý řádek informace o výrobku i jeho dodavateli. Protože můžete mít více výrobků od stejného dodavatele, musí se jméno a adresa dodavatele opakovat několikrát. Plýtvá se tím místo na disku. Záznam informací o dodavatelích jenom jednou v samostatné tabulce Dodavatele a jeho propojení s tabulkou Výrobky je mnohem lepší řešení.

Druhý problém s tímto návrhem spočívá v tom, že potřebujete upravit informace o dodavateli. Předpokládejme například, že potřebujete změnit adresu dodavatele. Protože se zobrazuje na různých místech, můžete adresu omylem změnit na jednom místě, ale zapomenete ji změnit na ostatních. Problém se řeší tak, že na jednom místě po zápisu adresy dodavatele.

Při navrhování databáze se vždy pokuste zaznamenat každý fakt jenom jednou. Pokud zjistíte, že stejné informace opakujete na více než jednom místě, například na adrese konkrétního dodavatele, dejte tyto informace do samostatné tabulky.

Nakonec předpokládejme, že existuje jenom jeden výrobek dodávaný společností Coho Winery, který chcete odstranit, ale zachovat název dodavatele a informace o adrese. Jak byste odstranili záznam o výrobku, aniž byste zároveň ztratili informace o dodavateli? Nemůžete. Vzhledem k tomu, že každý záznam obsahuje fakta o produktu a také údaje o dodavateli, nemůžete je odstranit bez odstranění druhého. Aby byly tyto údaje oddělené, je nutné rozdělit jednu tabulku do dvou: jednu tabulku pro informace o výrobku a druhou tabulku pro informace o dodavateli. Odstranění záznamu produktu by mělo odstraňovat pouze údaje o produktu, nikoli údaje o dodavateli.

Po zvolení předmětu, který představuje tabulka, by sloupce v této tabulce měly ukládat údaje pouze o předmětu. Například tabulka produktů by měla uchovávat informace o produktech. Protože adresou dodavatele je fakt, a ne informace o výrobku, patří do tabulky dodavatelů.

Začátek stránky

Soustružení položek informací na sloupce

Pokud chcete určit sloupce v tabulce, rozhodněte se, jaké informace o předmětu zaznamenaného v tabulce potřebujete sledovat. Například pro tabulku Zákazníci: Jméno, Adresa, Město-Stát-PSČ, Poslat e-mail, Oslovení a E-mailová adresa tvoří dobrý výchozí seznam sloupců. Každý záznam v tabulce obsahuje stejnou sadu sloupců, takže je možné uložit jméno, adresu, město-stát-PSČ, odeslat e-mail, oslovení a e-mailovou adresu pro každý záznam. Například sloupec Adresa obsahuje adresy zákazníků. Každý záznam obsahuje data o jednom zákazníkovi a pole Adresa obsahuje adresu tohoto zákazníka.

Po tom, co pro každou tabulku určíte počáteční sadu sloupců, 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 pouze podle těchto sloupců. Adresa vlastně obsahuje pět samostatných součástí, adresu, město, stát, PSČ a zemi/oblast a má také smysl je uložit do samostatných sloupců. Pokud například chcete 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 také informace vnitrostátního původu, nebo také mezinárodní. Pokud například plánujete ukládat mezinárodní adresy, je lepší mít místo sloupce Oblast sloupec Oblast, protože takový sloupec může pojmout jak vnitrostátní státy, tak oblasti jiných zemí nebo oblastí. PSČ podobně dává větší smysl než PSČ, pokud budete ukládat mezinárodní adresy.

Následující seznam obsahuje několik tipů, jak určit sloupce.

  • Nezahrnujte počítaná data    

    Ve většině případů byste výsledky výpočtů v tabulkách neměli ukládat. Místo toho můžete accessové výpočty nastavit tak, aby výsledek viděl. Předpokládejme například, že existuje sestava Products On Order (Výrobky podle objednávky), ve které se zobrazuje mezisoučet jednotek na objednávce pro jednotlivé kategorie výrobků v databázi. V žádné tabulce ale není žádný sloupec Jednotky mezisoučtu Objednávky. Místo toho obsahuje tabulka Výrobky sloupec Jednotky podle objednávky, ve které jsou uloženy jednotky podle objednávky pro jednotlivé výrobky. Access vypočítá souhrn při každém tisku sestavy pomocí těchto dat. Samotný souhrn by neměl být v tabulce uložen.

  • Informace ukládejte do nejmenších logických částí.    

    Může být lákavé mít jediné pole pro celé názvy nebo názvy produktů spolu s popisy produktů. Pokud v poli zkombinujete víc než jeden druh informací, je později obtížné načíst jednotlivé údaje. Snažte se informace rozdělit 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.

Obrázek znázorňující položky informací během procesu návrhu

Jakmile v každé tabulce zpřesníte sloupce dat, můžete vybrat primární klíč každé tabulky.

Začátek stránky

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 nazývají 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 k jejich spojení.

Pokud už máte jedinečný identifikátor tabulky, například číslo výrobku, které jedinečně identifikuje každý produkt 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 pro každý záznam vždy lišit. V primárním klíči nemůžete mít duplicitní hodnoty. Nepoužívejte například jména lidí jako primární klíč, protože jména nejsou jedinečná. V jedné tabulce můžete mít snadno dva lidi se stejným názvem.

Primární klíč musí mít vždy hodnotu. Pokud se hodnota sloupce může někdy stát nepřiřazená nebo neznámá (chybějící hodnota), nelze ji v primárním klíči použít jako součást.

Měli byste vždy zvolit primární klíč, jehož hodnota se nezmění. 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í se tato změna použít všude, kde se na klíč odkazuje. Použitím primárního klíče, který se nezmění, snížíte riziko, že se primární klíč nesynchronní s jinými tabulkami, na které odkazuje.

Jako primární klíč se často používá libovolné jedinečné číslo. Například každé objednávce můžete přiřadit jedinečné číslo objednávky. Jediným účelem čísla objednávky je identifikovat objednávku. 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 automaticky přiřadí hodnotu za vás. Takový identifikátor je skutečně neobsahuje žádné informace popisující řádek, který představuje. Ve skutečnosti jsou identifikátory ideální k použití jako primárního klíče, protože se nemění. Primární klíč obsahující fakta o řádku – například telefonní číslo nebo jméno zákazníka – se může nejspíš změnit, protože samotné informace o zákazníky se můžou změnit.

Obrázek tabulky Výrobky s polem primárního klíče

1. Ze sloupce nastaveného na datový typ Automatické číslo se často stává dobrý primární klíč. Žádná dvě ID produktu 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á obsahuje položky řádku pro objednávky, by v primárním klíči používejte dva sloupce: ID objednávky a ID výrobku. Když primární klíč využívá víc než jeden sloupec, nazývá se také složený klíč.

Pro databázi prodejů produktů můžete vytvořit sloupec Automatické číslo pro každou z tabulek, který bude sloužit jako primární klíč: IDDárku pro tabulku Výrobky, ID Objednávky pro tabulku Objednávky, ID Zákazníka pro tabulku Zákazníci a IDDdárce pro tabulku Dodavatele.

Obrázek znázorňující položky informací během procesu návrhu


Začátek stránky

Vytváření relací mezi tabulkami

Teď, když jste informace rozdělili na tabulky, je potřeba je znova spojit srozumitelným způsobem. Následující formulář například obsahuje informace z několika tabulek.

Formulář Objednávky

1. Informace v tomto formuláři pocházejí z tabulky Zákazníci...

2. ... Tabulka Zaměstnanci...

3. ... Tabulka Objednávky...

4. ... Tabulka Výrobky...

5. ... a tabulku Podrobnosti objednávky.

Access je relační systém pro správu databází. V relační databázi rozdělíte informace do samostatných tabulek založených na předmětu. Potom pomocí relací mezi tabulkami můžete informace podle potřeby spojit.

Začátek stránky

Creating a one-to-many relationship

Vezměte v úvahu tento příklad: Tabulky Dodavatele a Výrobky v databázi objednávek produktů. Dodavatel může dodat libovolný počet výrobků. To znamená, že u libovolného dodavatele znázorněného v tabulce Dodavatelé může být v tabulce Výrobky uvedené mnoho výrobků. Relace mezi tabulkami Dodavatelé a Výrobky je tedy relace 1:N.

Koncepční fáze jedna ku mnoha

Chcete-li představující 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 sloupec do tabulky na straně N relace. V tomto případě například přidáte sloupec ID dodavatele z tabulky Dodavatele do tabulky Výrobky. Access pak pomocí identifikačního čísla dodavatele v tabulce Výrobky najde správného dodavatele každého výrobku.

Sloupec ID dodavatele v tabulce Výrobky se nazývá cizí klíč. Cizí klíč je primární klíč jiné tabulky. Sloupec ID dodavatele v tabulce Výrobky je cizím klíčem, protože je to také primární klíč v tabulce Dodavatelé.

Obrázek znázorňující položky informací během procesu návrhu

Jako základ pro připojování k souvisejícím tabulkám vytváříte párování primárních klíčů a cizích klíčů. Pokud si nejste jistí, které tabulky by měly sdílet společný sloupec, identifikace relace 1:N zajistí, že tyto dvě tabulky budou skutečně vyžadovat sdílený sloupec.

Začátek stránky

Creating a many-to-many relationship

Vezměte v úvahu relaci mezi tabulkou Výrobky a tabulkou 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 být v tabulce Objednávky mnoho záznamů. Tento typ relace se nazývá relace M:N, protože pro jakýkoli produkt existuje mnoho objednávek. a v každé objednávce může být množství produktů. Nezapomeňte, že ke zjištění relací M:N mezi tabulkami je důležité vzít v úvahu obě strany relace.

Předměty obou tabulek, objednávky a produkty, mají relaci M:N. Jedná se o problém. Představte si, co by se stalo, kdybyste se pokusili vytvořit relaci mezi oběma tabulkami přidáním pole Kód výrobku do tabulky Objednávky. Pokud chcete mít pro každou objednávku více než jeden produkt, potřebujete v tabulce Objednávky pro každou objednávku více než jeden záznam. U každého řádku, který souvisí s jedním řádkem, byste měli opakující se informace o objednávce – výsledkem může být neefektivní návrh, který by mohl vést k nepřesnám datům. Na stejný problém nastane, když dáte pole Id objednávky do tabulky Výrobky – v tabulce Výrobky byste pro každý produkt měli v tabulce Výrobky více záznamů. Jak tento problém vyřešíte?

Odpovědí je vytvoření třetí tabulky, často nazývané 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.

Relace typu N:N

Každý záznam v tabulce Podrobnosti objednávky představuje jednu položku řádku objednávky. Primární klíč tabulky Podrobnosti objednávky se skládá ze dvou polí: cizích klíčů z tabulek Objednávky a Produkty. Samostatné pole Id objednávky nefunguje jako primární klíč pro tuto tabulku, protože jedna objednávka může mít mnoho položek řádku. 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 Kód výrobku nefunguje, protože jeden výrobek se může zobrazit v mnoha různých objednávkách. Společně ale tato dvě pole vždy pro každý záznam vytvoří jedinečnou hodnotu.

V databázi prodeje produktů nejsou tabulky Objednávky a Výrobky vzájemně přímo spojené. Místo toho nepřímo souvisí prostřednictvím tabulky Podrobnosti objednávky. Relace M:N mezi objednávkami a produkty je v databázi znázorněna pomocí dvou relací 1:N:

  • Tabulka Objednávky a tabulka Podrobnosti objednávky mají relaci 1:N. Každá objednávka může mít víc než jednu položku na řádku, ale každá položka řádku je připojená jenom k jedné objednávce.

  • Tabulka Výrobky a tabulka Podrobnosti objednávky mají relaci 1:N. Ke každému výrobku může být přiřazeno mnoho položek řádku, ale každá položka řádku odkazuje jenom na jeden produkt.

Z tabulky Podrobnosti objednávky můžete určit všechny produkty na určité objednávce. Můžete také určit všechny objednávky konkrétního produktu.

Po začlenění tabulky Roz podrobnosti objednávky může seznam tabulek a polí vypadat nějak takhle:

Obrázek znázorňující položky informací během procesu návrhu


Začátek stránky

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é speciální doplňující informace o produktu, které budete potřebovat zřídka nebo které se týkají jen několika produktů. Vzhledem k tomu, že tyto informace nepotřebujete často, a protože by při ukládání informací do tabulky Výrobky byly prázdné místo pro každý produkt, na který se nevztahují, umístěte je do samostatné tabulky. Stejně jako tabulka Výrobky i v tabulce ProductID použijete jako primární klíč. Relace mezi touto doplňkovou tabulkou a tabulkou Produkt je relace 1:1. Pro každý záznam v tabulce Produkt existuje v doplňkové tabulce jediný odpovídající záznam. 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é informace z těchto dvou tabulek umístit do jedné tabulky. Pokud byste to z nějakého důvodu nechtěli udělat, třeba proto, že by v důsledku toho bylo hodně volného místa, v následujícím seznamu je vidět, jak byste představovali vztah v návrhu:

  • 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 (v obou) a vložte primární klíč do druhé tabulky jako cizí klíč.

Určením relací mezi tabulkami zajistíte, že máte správné tabulky a sloupce. Pokud existuje relace 1:1 nebo 1:N, je potřeba sdílet společný sloupec nebo sloupce tabulek, které jsou potřeba. Pokud existuje relace M:N, je zapotřebí třetí tabulka představující relaci.

Začátek stránky

Upřesnění návrhu

Až budete mít tabulky, pole a relace, které potřebujete, měli byste tabulky vytvořit a naplnit ukázkovými daty a zkusit s těmito informacemi pracovat: vytvořením dotazů, přidáním nových záznamů atd. Pomůže vám to zvýraznit možné 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 duplikování odstranilo.

Podívejte se, jestli databázi můžete použít k získání odpovědí, které potřebujete. Vytvářejte hrubé koncepty formulářů a sestav a podívejte se, jestli ukazují data, která očekáváte. Hledejte zbytečné duplikování dat, a pokud nějaká najdete, změňte návrh tak, abyste ho odstranili.

Při pokusu o počáteční databázi pravděpodobně objevíte místo pro vylepšení. Tady je pár věcí, které je dobré zkontrolovat:

  • Zapomněli jste nějaké sloupce? Pokud ano, patří informace do stávajících tabulek? Pokud se jedná o informace o něčem jiném, budete možná muset vytvořit další tabulku. Vytvořte sloupec pro každou položku informací, kterou potřebujete sledovat. Pokud informace nelze vypočítat z jiných sloupců, je pravděpodobné, že pro něj budete potřebovat nový sloupec.

  • Jsou nějaké sloupce nepotřebné, protože je lze vypočítat z existujících polí? Pokud lze položku informace vypočítat z jiných existujících sloupců, například z diskontní ceny vypočtené z maloobchodní ceny, je obvykle lepší tento postup provést a vyhnout se vytváření nového sloupce.

  • Zadáváte opakovaně duplicitní informace do jedné z tabulek? Pokud ano, budete nejspíš muset tabulku rozdělit do dvou tabulek, které mají relaci 1:N.

  • Máte tabulky s mnoha poli, omezený počet záznamů a mnoho prázdných polí v jednotlivých záznamech? Pokud ano, představte si o přepracovaní tabulky tak, aby v ní bylo méně polí a víc záznamů.

  • Jsou jednotlivé položky informací rozdělené do svých nejmenších užitečných částí? Pokud potřebujete vytvořit sestavu, řadit, vyhledávat nebo počítat s nějakou položkou informací, umístěte ji do vlastního sloupce.

  • Obsahuje každý sloupec fakt týkající se předmětu tabulky? Pokud sloupec neobsahuje informace o předmětu tabulky, patří do jiné tabulky.

  • Jsou všechny relace mezi tabulkami znázorněné 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.

Refining the Products table

Předpokládejme, že každý produkt v databázi prodeje produktů spadá do obecné kategorie, jako jsou nápoje, doplňky nebo moře. Tabulka Výrobky může obsahovat pole zobrazující kategorii jednotlivých produktů.

Předpokládejme, že po zpřesnění návrhu databáze se rozhodnete uložit spolu s jejím názvem popis kategorie. Pokud do tabulky Výrobky přidáte pole Popis kategorie, musíte zopakovat popis každé kategorie pro každý produkt, který spadá do kategorie – to není dobré řešení.

Lepším řešením je změnit kategorie na nový předmět, který bude databáze sledovat, a to pomocí vlastní tabulky a vlastního primárního klíče. Primární klíč z tabulky Kategorie pak můžete přidat jako cizí klíč do tabulky Výrobky.

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 zkontrolujte strukturu tabulky hledejte opakující se skupiny. Vezměte například v úvahu 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 skupina 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 znovu podívat na svůj návrh.

Takový design má několik užínků. Pro začátek vás nutí umístit horní limit počtu produktů. Jakmile tento limit překročíte, musíte do struktury tabulky, což je hlavní administrativní úkol, přidat novou skupinu sloupců.

Dalším problémem je, že tito dodavatelé, kteří mají méně než maximální počet produktů, budou ztrácet určité místo, protože další sloupce budou prázdné. Závažnější z těchto návrhů je, že provádění mnoha úkolů je obtížné, například řazení nebo indexování tabulky podle ID výrobku nebo názvu.

Pokaždé, když se zobrazí opakující se skupiny, bude návrh pečlivě zkontrolujte s pohledem na rozdělení tabulky do dvou skupin. V tomto příkladu je lepší používat dvě tabulky, jednu pro dodavatele a jednu pro výrobky, propojené ID dodavatele.

Začátek stránky

Použití pravidel normalizace

Jako další krok v návrhu můžete použít pravidla normalizace dat (někdy se jim také říká pravidla normalizace). Tato pravidla použijte k zobrazení správné struktury tabulek. Proces použití pravidel pro návrh databáze se nazývá normalizace databáze nebo jenom normalizace.

Normalizace je nejužitečnější, pokud jste zastupovali všechny informační položky a přidali předběžný návrh. Cílem je zajistit, abyste informace rozdělili do příslušných tabulek. Normalizace nemůže zajistit, že máte všechny správné datové položky, se kterou je třeba začít.

Pravidla aplikujete na sebe a v každém kroku zajistíte, aby návrh dorazil v jednom z "normálních formulářů". Obecně je přijímáno pět normálních formulářů – první normální formulář až po pátý normální formulář. Tento článek se rozšiřuje o první tři části, protože jsou všechny potřebné pro většinu návrhů databází.

První normální formulář

První normální formulář uvádí, že při každém průsečíku řádku a sloupce v tabulce existuje jedna hodnota, nikdy seznam hodnot. Nemůžete mít třeba pole s názvem Cena, do kterého můžete umístit více než jednu cenu. Pokud si myslíte, že každý průsečík řádků a sloupců představuje buňku, může v každé buňce být jenom jedna hodnota.

Druhý normální formulář

Druhý normální formulář vyžaduje, aby každý sloupec, který není klíčem, plně závislý na celém primárním klíči, nikoli pouze na části klíče. Toto pravidlo platí v případě, že 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, ve kterých kód objednávky a ID výrobku tvoří primární klíč:

  • ID objednávky (primární klíč)

  • ID produktu (primární klíč)

  • Název produktu

Tento návrh porušuje druhý normální formulář, protože název produktu je závislý na ID výrobku, nikoli však 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 (Produkty).

Třetí normální formulář

Třetí normální formulář vyžaduje, aby každý sloupec, který není klíčem, závisel na celém primárním klíči, ale aby sloupce, které nejsou klíčové, byly na sobě nezávislé.

Dalším způsobem, jak říci, je, že každý sloupec, který není klíčem, musí být závislý na primárním klíči a na jednom primárním klíči. Předpokládejme například, že máte tabulku obsahující následující sloupce:

  • ID Produktu (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í formulář, protože jiný než klíčový sloupec Discount závisí na jiném sloupci, který není klíčem – SRP. Nezávislost ve sloupci znamená, že byste měli mít možnost změnit jakýkoliv sloupec, který není klíčovým, aniž byste ovlivnili jakýkoliv jiný sloupec. Pokud změníte hodnotu v poli SRP, diskontace se odpovídajícím způsobem změní, a tím toto pravidlo porušuje. V tomto případě byste měli slevu přesunout do jiné tabulky s klíčem SRP.

Začátek stránky

Potřebujete další pomoc?

Rozšiřte své dovednosti s Office
Projít školení
Získejte nové funkce jako první
Připojte se k účastníkům programu Office Insiders

Byly tyto informace užitečné?

Děkujeme vám za zpětnou vazbu.

Děkujeme vám za váš názor! Pravděpodobně bude užitečné, když vás spojíme s některým z našich agentů podpory Office.

×