Seznamte se s diagramem ER (Entity Relationship), jeho částmi a tím, co se při jeho vytváření často pokazí.
Vytvořili jste někdy model relační databáze? Nebo se možná pokoušíte vytvořit svůj první? Víte (nebo to brzy zjistíte), že převedení skutečných problémů do databázové logiky může být někdy docela obtížné.
Jedním z nástrojů, který vám může pomoci, je ER diagram. Běžná moudrost při návrhu databází tvrdí, že čím lepší je váš ER diagram, tím snazší bude vytvoření databázového modelu. Tato důležitá položka udává tón všem budoucím frustracím nebo úspěchům. S dobrým ER diagramem je vytvoření modelu relační databáze docela jednoduché. V jakékoli fázi databázového modelování lze samozřejmě udělat chyby. Dobrý ER diagram vám však může pomoci vyhnout se některým z těchto chyb.
Pojďme se tedy podívat, co je ER diagram a jak se můžeme vyhnout jeho běžným chybám.
Co je to ER diagram?
„ER Diagram“ nebo ERD je zkratka pro Entity Relationship Diagram. Mapuje problém, který má být modelován, ale strukturovaným způsobem, který ukazuje vztahy mezi entitami.
Stavební bloky diagramu ER
ER diagramy se skládají z následujících prvků:
- Entita
- Vztahy
- Atributy entity nebo vztahu
Prvním prvkem ER diagramu je entita . Entita je objekt nebo výskyt, o kterém chceme ukládat informace. V podstatě je to cokoliv, o čem můžeme sbírat data. Můžeme například ukládat údaje o zaměstnancích, studentech, učitelích, kupujících, produktech, odděleních, platbách, místech atd.
Jakmile máme entity, je nutné vytvořit vztahy . Vztah ukazuje, jak je jedna entita propojena a přidružena k jedné nebo více dalším entitám.
Posledním prvkem ER diagramu je atribut entity nebo vztahu . Atribut je popis vlastnosti patřící k entitě nebo vztahu. Atributy mají hodnoty. Některé atributy pro entity uvedené výše mohou být:
- Zaměstnanec, student, učitel, kupující – IČO, jméno, příjmení, datum narození, adresa atd.
- Produkt – ID, kategorie, popis, barva, sériové číslo atd.
- Oddělení – IČO, název oddělení, vedoucí oddělení, počet zaměstnanců atd.
- Platby – ID, datum a čas, částka.
- Umístění – Město, PSČ, region, země, kontinent.
Typy vztahů
Než se dostaneme k obvyklým chybám v ER diagramech, je důležité porozumět možným typům vztahů. Většina chyb ERD jsou v podstatě chybně definované vztahy mezi entitami.
Existují tři typy vztahů mezi entitami:
- Jedna ku jedné (1:1)
- Jedna k mnoha (1:N)
- Mnoho k mnoha (M:N)
Vztahy jedna ku jedné (1:1)
První typ vztahu je jeden k jednomu nebo 1:1 . V tomto vztahu může být jedna instance jedné entity spojena pouze s jednou instancí jiné entity (a samozřejmě naopak).
Řekněme, že máme entitu student s atributy name a příjmení . Máme také entitu id s jediným atributem id . Vztah 1:1 by znamenal, že jeden student může mít pouze jedno IČO. To také znamená, že jedno ID číslo může patřit pouze jednomu studentovi.
Tento vztah je v databázích k vidění velmi zřídka. Pokud lze pouze jedno ID propojit pouze s jedním studentem, není nutné je rozdělovat do dvou různých entit.
Zde je příklad tohoto vztahu:
Vztahy jedna k mnoha (1:N)
Nejběžnějším typem databázového vztahu je one-to-many nebo 1:N . Vztah One-to-many znamená, že každá jednotlivá instance jedné entity může být propojena s více instancemi jiné entity. To také znamená, že každá instance druhé entity může být spojena pouze s jednou instancí první entity.
Existuje například entita kupující s atributy id , jméno a příjmení . Chceme navázat vztah s entitou platba který má atributy id , datum a hodnota . Toto je vztah 1:N, protože jeden kupující může provést jednu nebo více plateb. Jednu platbu však nemůže provést více kupujících; může být zhotoven pouze jedním kupujícím.
Zde je příklad:
Tento vztah lze vidět i opačně. V této situaci se nazývá many-to-one nebo N:1 . Samozřejmě se nejedná o nový typ vztahu. Je to stejné jako 1:N, ale dívá se na to z opačného směru.
Předpokládejme například, že máme entitu zaměstnanec s atributy id , jméno a příjmení . Chceme založit zaměstnance vztah s entitou oddělením který má atributy id a jméno . Vztah mezi těmito dvěma entitami je N:1. To znamená, že každý zaměstnanec může pracovat pouze v jednom oddělení, ale ve stejném oddělení může pracovat více zaměstnanců.
Vztahy mnoho k mnoha (M:N)
A Mnoho-mnoho nebo M:N vztah znamená, že každá instance první entity může být spojena s více než jednou instancí druhé entity. Znamená to také, že každá instance druhé entity může být spojena s více instancemi první entity.
Podívejme se, jak to funguje mezi entitami student a přednáška . Řekněme, že student má atributy id , jméno a příjmení . Entita přednáška má atributy id a jméno . Vztah many-to-many lze interpretovat následujícím způsobem:jeden student může navštívit jednu nebo více přednášek, zatímco jednu přednášku může navštívit jeden nebo více studentů.
Zde je diagram pro tento příklad:
V databázovém modelování jsou takové vztahy obvykle rozděleny do dvou nebo více vztahů 1:N nebo N:1 zavedením nových entit.
Typické chyby při vytváření diagramu ER
Mnoho chyb v ER diagramu spadá do jedné z těchto čtyř kategorií:
- Nesprávné vztahy mezi entitami
- Použití instance entity místo entity
- Záměna atributu s entitou
- Složité atributy
Podívejme se na každou zvlášť.
Nesprávné vztahy mezi entitami
K nejčastějším chybám dochází při definování vztahu mezi entitami . Ve vztahu 1:1 většinou žádné chyby nebývají. Je však velmi snadné zaměnit vztah 1:N za vztah M:N. To obvykle pramení z nepochopení požadavků koncového uživatele. Je životně důležité mít velmi jasně definované požadavky a hluboce rozumět tomu, proč je databáze potřebná a jak bude využívána. Pokud vytvoříme ER diagram s nedostatečnými daty a neúplným porozuměním, s největší pravděpodobností to povede k nesprávné definici vztahů mezi entitami.
Podívejme se na příklad. Pokud vytváříte databázi pro banku, s největší pravděpodobností vytvoříte ER diagram s entitou klient s atributy id , jméno a příjmení . Budete mít také entitu s názvem účet s atributy id a typ . Pokud vám chybí zkušenosti v bankovním odvětví, pravděpodobně si budete myslet, že mezi klientem je vždy vztah 1:N a účet entity, jak je uvedeno níže.
Jeden klient může mít v jedné bance více účtů. Účet však může vlastnit pouze jeden zákazník. Je to skutečně pravda? Možná je, možná není. Poměrně hodně bank nabízí společné účty, které může využívat více klientů. Vytváříte ER diagram pro banku, která takovou službu nabízí? Pokud banka nenabízí společné účty, pak máte pravdu:vztah mezi klientem a účet je 1:N. Pokud však banka společné účty nabízí, pak je vztah M:N.
Použití instance entity místo entity
Další častou chybou je použití instance entity místo entity. Instance entity je jeden výskyt určité entity – tj. entity, která by ve skutečnosti mohla být atributem větší kategorie.
Řekněme, že pracujeme ve firmě, která přiděluje mobilní telefony a notebooky určitým zaměstnancům. V naší databázi bychom tedy měli entitu s názvem laptop s atributy id a model a entita s názvem zaměstnanec s atributy id , jméno a příjmení , že jo?
Zde je problém:notebook ve skutečnosti není entita – jsou zde také mobilní telefony, které je třeba zohlednit. Řešením je nahradit entitu laptop s obecnější entitou, jako je zařízení . Tato entita může mít atributy ID , typ a model , Jak je ukázáno níže. Typ může obsahovat hodnoty jako telefon , PC , tablet a notebook . Tímto způsobem není nutné vytvářet samostatnou entitu pro každý typ zařízení.
Příklad najdete zde:
Záměna atributu s entitou
Další častou chybou je záměna atributu s entitou. Řekněme, že jsme se rozhodli vytvořit entitu s názvem zaměstnanec který se bude skládat z atributů id , jméno , příjmení , datum_narození , id_department , jméno_oddělení a head_department . Tato entita nás při vytváření databázového modelu dostane do problémů, protože sestává z příliš mnoha atributů, které tuto konkrétní entitu jednoznačně nedefinují .
Pamatujte, že jsme definovali entity jako cokoli, o čem můžeme shromažďovat data. S ohledem na to můžeme vidět, že současný zaměstnanec entitu lze rozdělit na dvě entity:zaměstnanec a oddělení , Jak je ukázáno níže.
Složité atributy
Poslední běžnou chybou, o které budeme mluvit, je zahrnutí složitého atributu do entity. Jinými slovy, máme atribut, který by ve skutečnosti měl být jeho vlastní entitou .
Řekněme, že máme entitu nazvanou studenti který je definován následujícími atributy:id , jméno , příjmení , datum_narození , adresa a zkouška_složila . Zde zkouška_absolvována je komplexní atribut, který se skládá z více než jedné informace, tj. ID a data zkoušky a skóre studenta. Nechat to tak by byla chyba. Místo toho bychom měli vytvořit novou entitu mimo tento komplexní atribut . Nová entita by se mohla jmenovat zkoušky a skládají se z následujících atributů:id , datum , id_studentů a skóre .
Příklad najdete zde:
Získali jste nějaké užitečné tipy na ER diagram?
Tyto čtyři typy chyb jsou nejběžnější v procesu vytváření ER diagramu. Samozřejmě neexistuje úplný seznam typických chyb nebo typů chyb. V reálném životě se pravděpodobně stane mnoho druhů chyb. Nedostatek plánování, nedostatečná technická podpora a uspěchaný proces návrhu databáze, to vše přispívá k vlastním problémům. Pokud jste někdy vytvářeli databáze nebo se na nich podíleli z obchodního hlediska, pravděpodobně jste některé z nich zažili! Všechny tyto okolnosti vedou k různým chybám, z nichž některé jsou zcela unikátní.
Máte svůj vlastní příklad nepříliš dobrého ER diagramu? Nebo možná existují nějaké další chyby, které často nacházíte? Dejte mi prosím vědět v sekci komentářů.