Domov › Telefon › Navrhování er modelu. Metodika pro konstrukci er-diagramů pro databázi

Navrhování er modelu. Metodika pro konstrukci er-diagramů pro databázi

(Přednáška 8)

Vývoj koncepční úrovně databáze

Cílem této etapy je důsledný vývoj koncepčního informačně-logického modelu předmětné oblasti, odrážejícího logiku podnikových informací a datově logický model databáze.

Infoologický doménový model

Výchozími daty pro konstrukci ILM předmětné oblasti jsou výsledky analýzy předmětné oblasti, prezentované ve formě popisu tříd objektů a vazeb mezi nimi. Nejčastěji je ILM předmětné oblasti prezentováno z hlediska sémantického datového modelu ve formě ER diagramu předmětné oblasti.

Je třeba poznamenat, že identifikace tříd objektů, vazeb v předmětné oblasti, jejich popis a zobrazení ve schématu probíhá paralelně.

Metodiky pro konstrukci ER diagramů

V současné době existují různé metodiky (zápisy) pro konstrukci ER modelu.

1 Metodika Petera Chena. V roce 1976 navrhl Peter Chen sémantický model entita-vztah – model ER, který se nyní stal nejrozšířenějším.

Konvence používané při zobrazování diagramu:

Třídy objektů jsou zobrazeny jako obdélníky, vlastnosti jako elipsy, spojení jako kosočtverce;

Jedinečný identifikátor (primární klíč) je zobrazen jako elipsa obklopená dvojitou čarou;

Síla spojení „jeden“ je označena čárou, „mnoho“ - čárou se šipkou.

Vlastnosti této metodiky:

Metoda umožňuje ukázat vztah mezi dvěma, třemi nebo více třídami objektů (entit);

Vztah může mít své vlastní atributy;

Chybí možnost zobrazení vzájemně se vylučujících spojení a netolerance spojení;

Vzájemně se vylučující vztahy jsou implicitně implementovány jako supertypy a podtypy;

Nelze vyjádřit volitelnost atributů a vztahů.

Obrázek 6 ukazuje příklad fragmentu ER diagramu s použitím metodologie Petera Chena.

Obrázek 6 - Příklad fragmentu ER diagramu pomocí metodologie Petera Chena

Diagram zobrazuje následující obchodní pravidla podniku: „Každá objednávka, která má takové vlastnosti jako číslo a datum, musí odpovídat jedné nebo více položkám objednávky, které mají vlastnosti jako počet, cena za jednotku zboží, množství zboží“; na druhé straně - "Každá položka produktu se musí vztahovat k jedné a pouze jedné objednávce."

Je třeba poznamenat, že příklad ukazuje fragment popisu předmětné oblasti. Měl by také obsahovat třídy objektů, jako je „Produkt“, „Měrná jednotka“ a další.

2 Metodika IDEF1. Používá se v CASE nástrojích ERwin, Design/IDEF. Metodika používá následující konvence:

Každá třída objektů má přiřazen jedinečný název a číslo;

Povinné připojení je zobrazeno jako plná čára, volitelné připojení jako tečkovaná čára;

Komunikační výkon „jeden“ je zobrazen čárou, „mnoho“ tečkou;

Spojení může být dále specifikováno specifikací síly (typu) spoje. Výkon může nabývat následujících hodnot: N - nula, jedna nebo více (standardně akceptováno); Z - nula nebo jedna, P - jedna nebo více.

Vlastnosti třídy prvků se zobrazují jako seznam názvů v bloku, který zobrazuje třídu prvků;

Atributy primárního klíče jsou zobrazeny nahoře a odděleny od ostatních.

Příklad ER diagramu v metodice IDEF1 je na obrázku 7.

Obrázek 7 - Příklad znázornění ER diagramu v metodologii IDEF1.

Obrázek 7 ukazuje stejnou situaci v předmětné oblasti jako na obrázku 6.

3 Metodika Richarda Barkera. Prvky používané v metodice: třída objektů, vlastnost třídy objektů, jedinečné identifikátory, volitelnost vlastností, spojení, síla (typ), volitelnost a přenositelnost spojení, jednoznačnost objektu ze spojení, nadtypy, podtypy, oblouky.

Používají se následující konvence:

Třída prvku se zobrazí jako obdélník se zaoblenými rohy. Název třídy objektu je uveden uvnitř čtyřúhelníku, jde o podstatné jméno v jednotném čísle, zobrazené velkými písmeny;

Vlastnosti se zapisují do čtyřúhelníku reprezentujícího třídu objektů malými písmeny, jedná se o podstatné jméno v jednotném čísle;

Čtyřúhelník představující třídu objektů lze zvětšit na libovolnou velikost;

Volitelnost vlastností je označena: požadovaná vlastnost - hvězdičkou (*), volitelná - kroužkem (o);

Jedinečný identifikátor je označen #, pokud existuje několik jedinečných identifikátorů, pak je každý označen číslem uvedeným v závorce, například # (1), #(2);

Povinné připojení je označeno plnou čarou, nepovinné pak tečkovanou čarou;

Typ (výkon) připojení „jeden“ je označen čárou, „mnoho“ - „vrána noha“.

Složitější prvky použité v ER diagramu sestaveném podle metodiky Richarda Barkera budou dále zvažovány v příkladech.

Modelovací šablony

Každá zvažovaná oblast má své vlastní charakteristiky. Ale zároveň má také prvky společné pro všechny obory. Převážná část problémů automatizace, které je třeba vyřešit, tedy nutně zahrnuje takové třídy objektů, jako je podnik (organizace), strukturální jednotka podniku (dílna, katedra, fakulta, katedra atd.), lidé nebo jednotlivci a různé druhy hmotné předměty. Veškeré procesy probíhající v předmětné oblasti, které je třeba zohlednit v databázi, jsou prováděny na základě dokumentů, které zase zaznamenávají sběr, pohyb a spotřebu jakýchkoli dat. Mnoho situací lze tedy simulovat pomocí existujících šablon. Podíváme se na modelování vzorů na příkladu konstrukce fragmentů ER diagramů pomocí metodologie Richarda Barkera.

1 Modelování rodinného stavu. Například doménová situace popsaná následujícími větami: „každý JEDNOTLIVC (muž) může být manželem jiného JEDNOTLIVCE (žena)“ a naopak „každý JEDNOTLIVC (žena) může být partnerem jiného JEDNOTLIVCE (muž“ může být být modelován pomocí rekurzivního spojení Jedná se o spojení mezi objekty stejné třídy objektů. Takové spojení může mít všechny vlastnosti vlastní libovolnému jinému spojení. Obrázek 8 ukazuje rekurzivní spojení, které má stejný typ na obou stranách („jeden“) a volitelnost „nepovinné“ V metodice Richarda Barkera lze názvy spojů zobrazit i na ER diagramu.

Obrázek – Příklad rekurzivního vztahu – „volitelné prasečí ucho“

2 Modelování datové hierarchie. Hierarchie dat je dodržena, pokud model domény obsahuje:

Libovolný počet hierarchií tříd objektů;

Třídy objektů zahrnuté v hierarchii mají stejné vlastnosti;

Spojení mezi takovými třídami objektů jsou stejná.

Obrázek 9 ukazuje fragment ER diagramu vytvořeného podle metodologie Richarda Barkera a zobrazující příklad hierarchie dat.

Obrázek - Příklad datové hierarchie

V každém podniku je organizační struktura obvykle hierarchická. V tomto příkladu je tedy představena organizační struktura vysoké školy. Objektové třídy odrážejí strukturální jednotky univerzity, umístěné na různých úrovních hierarchické struktury podřízenosti. Třídy objektů mají stejné vlastnosti a mezi třídami objektů umístěnými na různých úrovních hierarchie existují identická spojení. Po přečtení fragmentu takové tematické oblasti se můžete přesvědčit o její adekvátnosti. Tato reprezentace má však určitou nevýhodu - při přidávání další úrovně hierarchie, například přidání strukturální jednotky „Laboratoř“ pod podřízenost libovolného oddělení, bude vyžadovat přidání další třídy objektů do modelu, to znamená jakoukoli změnu v organizaci. struktura podniku bude vyžadovat úpravu modelu.

K modelování takovéto datové hierarchie můžete použít šablonu modelu – rekurzivní vztah. V tomto případě musí být rekurzivní spojení typu 1:M a musí být volitelné v obou směrech. Strana „jedna“ zobrazuje pravidlo „podřízené“, strana „mnoho“ zobrazuje pravidlo „podřízené“. Nejvyšší prvek hierarchie se „nikomu nepodřizuje“, nejspodnější prvek „nemá nikoho ve své podřízenosti“. Použití šablony vám umožňuje přidávat a odebírat úrovně hierarchie podle požadavků vaší domény, aniž byste měnili základní model.

Nahrazení datové hierarchie rekurzivním připojením se provádí pomocí následujícího algoritmu:

Je vytvořena jedna třída objektů obsahující vlastnosti vlastní každé třídě objektů v datové hierarchii;

Třídě objektů je přiřazen společný název (v hierarchii podřízenosti divizí podniku to může být např. třída objektů s názvem „STRUKTURNÍ JEDNOTKA PODNIKU“;

Je vytvořena další třída objektů, která bude zobrazovat název pro rozlišení jednotlivých uzlů datové hierarchie, například třída objektů „ENTERPRISE STRUCTURAL UNIT TYPE“.

Na závěr je třeba učinit následující poznámky:

Vzor má jednu nevýhodu: třídy objektů umístěné na všech úrovních hierarchie musí mít stejné vlastnosti;

Hierarchie modelovaná jako rekurzivní vztah musí být volitelná v obou směrech. Povinné větvení nahoru nebo dolů vytváří nekonečnou hierarchii, která nemá žádné uplatnění v reálném světě;

Pokud se při transformaci doménového modelu sloučí části diagramu do jednoho, pak je nutné v předmětné doméně najít třídu objektů „TYPE“, která vám umožní zobrazit jedinečnost každé části

Příklad použití šablony, která modeluje datovou hierarchii, je znázorněn na obrázku.

Obrázek - Příklad použití šablony pro modelování datové hierarchie.

3 Přerušení vazeb M:M. Přítomnost M:M spojení v ER diagramu je přijatelná, ale je třeba mít na paměti, že to není adekvátní reprezentace předmětné oblasti, která nebyla důkladně prozkoumána. Je potřeba najít třídu objektů (entitu), která takové spojení přeruší. Zpravidla se jedná o dokument nebo pozici dokumentu. Například vztah mnoho k mnoha mezi třídami objektů DODAVATEL a PRODUKT („každý DODAVATEL může dodat mnoho PRODUKTŮ“ a „každý PRODUKT může dodat různí DODAVATELÉ“) lze přerušit použitím tříd objektů, jako je POLOŽKA INVOICE “. , "CENÍKOVÁ POZICE", "SMLUVNÍ POZICE" a další. Obrázek 11 ukazuje příklad přerušeného spojení M:M. Dodavatelem v příkladu je právnická osoba.

Obrázek - Přerušení spojení M:M

Je třeba poznamenat, že třídy objektů, které porušují vztah M:M, zpravidla obsahují vlastnosti, jejichž hodnoty se dynamicky mění. Jsou to vlastnosti jako „množství“, „cena“.

Přerušení rekurzivního spojení M:M. (Modelování struktury sítě)

Tato struktura je velmi běžná v předmětné oblasti v prvních fázích návrhu. Příklad 1

Každá KOMPONENTA se může skládat z několika KOMPONENTŮ Každá KOMPONENTA může být zahrnuta do jedné nebo více KOMPONENT

Pro modelování byl použit volitelný rekurzivní vztah typu M:M.

Každá PRÁVNICKÁ OSOBA může k provádění přepravy využít mnoho PRÁVNICKÝCH OSOB

Každá PRÁVNICKÁ OSOBA může poskytnout PRÁVNICKÝM OSOBÁM mnoho služeb v oblasti přepravy.

Rekurzivní vztah „many_to_many“ musí být přerušen, protože není kam umístit např. takové vlastnosti jako „počet komponentů jednoho druhu pro sestavení komponentu vyšší úrovně“, „datum přepravy“, „počet přepravovaných věcí“ atd., tzn. s důkladnější analýzou předmětné oblasti můžete vidět takové třídy objektů, jako je „pravidlo montáže“ a „přeprava“.

Každé MONTÁŽNÍ PRAVIDLO platí pro jedno

KOMPONENT pro montáž

Každé MONTÁŽNÍ PRAVIDLO platí pro jednu KOMPONENTU zahrnutou v sestavě jiné

KOMPONENT.

Každá KOMPONENTA může obsahovat mnoho PRAVIDEL MONTÁŽE pro její součásti.

Každá Komponenta může být zahrnuta do mnoha

MONTÁŽNÍ PRAVIDLO.

Příklad 2

Každou PŘEPRAVU musí provádět PRÁVNICKÁ OSOBA

Každá PŘEPRAVA musí být provedena pro PRÁVNICKOU OSOBU Každá PRÁVNICKÁ OSOBA se může jako klient zúčastnit mnoha PŘEPRAV.

Paralelní spojení m.b. různých variant a typů.

Poznámka: pomocí rekurzivních spojení jsou modelovány síťové struktury a jejich speciální případy

Hierarchie.

4 Modelování rolí. Role osoby nebo organizace v předmětné oblasti jsou chápány jako pozice, odpovědnosti a přezdívky. V různých třídách objektů reprezentujících role se mohou objekty vzájemně překrývat a duplikovat. Například třída objektů „DOKTOR“ a třída objektů „PACIENT“ odrážejí různé role člověka – jeden léčí, druhý léčí. Pokud se však lékař stane pacientem ve stejné předmětové oblasti, pak by se informace o něm měly zobrazit ve třídě objektů „PATIENT“ dva objekty ve dvou třídách objektů budou duplikovat informace a vzájemně se překrývat. Role musí být modelovány pomocí vztahů, je nutné, aby objekt stejné třídy objektů mohl působit v několika rolích.

Příklad nesprávného a správného modelování rolí je znázorněn na obrázcích.

Obrázek – Nesprávné modelování rolí

Obrázek - Správné modelování rolí

Na obrázku s nesprávným modelováním rolí jsou třídy objektů „DODAVATEL“ a „SPOTŘEBITEL“ zvýrazněny samostatně. Pokud nastane situace, že právnická osoba bude vystupovat jako dodavatel i jako spotřebitel, bude model neadekvátně odrážet předmětnou oblast – informace budou duplicitní. Správným modelováním situace by bylo vyčlenit jednu třídu objektů „PRÁVNICKÁ OSOBA“ a zobrazit role „dodavatel“ a „spotřebitel“ ve formě odpovídajících spojení (figura se správným modelováním rolí).

Příklady oblastí, ve kterých je třeba modelovat role, jsou uvedeny v tabulce 9.

Tabulka 9 - Příklady modelování rolí.

Předmětná oblast	Nesprávné modelování	Správné modelování
Nákup a prodej, dodání zboží	Třídy objektů: KUPUJÍCÍ, PRODÁVAJÍCÍ, DODAVATEL	Třídy objektů: PRÁVNICKÁ OSOBA nebo JEDNOTLIVCI. Vztahy (role): nakupuje, prodává, dodává
Vzdělávací instituce, školení	Objektové třídy: UCHAZEČ, ŽÁK, UČITEL, ABSOLVENT	Třídy objektů: JEDNOTLIVCI, PRÁCE JEDNOTLIVCŮ, VÝCVIK JEDNOTLIVCŮ, TYP VÝCVIKU JEDNOTLIVCŮ, TYP POHYBU JEDNOTLIVCŮ. Konexe (role): předkládá dokumenty, práce, studie.
Tok dokumentů	Třídy objektů: PŘÍCHOZÍ DOKUMENT, ODchozí DOKUMENT, OBJEDNÁVKA, DISTRIBUCE	Třídy objektů: DOKUMENT, POZICE DOKUMENTU, TYP DOKUMENTU, TYP POHYBU DOKUMENTU. Vztahy (role): odkazuje (na typ)

Obrázek ukazuje fragment ER diagramu zobrazující oblast „Enterprise Personnel“. Třída objektu „POZICE POHYBU“ zobrazuje informace o pohybu zaměstnanců (jednotlivců) v podniku, třída objektu „TYP POHYBU“ - typy pohybu personálu - přijímání, překládání, propouštění atd. Mezi třídami objektů „POŘAD POHYBU“ a „POZICE POHYBU POHYBU“ existují tři spojení, dvě z nich modelují role:

- „každý POHYBOVÝ PŘÍKAZ musí být podepsán jedním zaměstnancem, který je vedoucím personálního oddělení, o čemž jsou relevantní informace v objektové třídě POZICE POHYBOVÉHO OBJEDNÁVKY“, vedoucí personálního oddělení může podepsat mnoho zakázek“;

Obrázek - Příklad modelování rolí

- „každý POHYBOVÝ PŘÍKAZ musí být podepsán jedním zaměstnancem, který je vedoucím podniku, o čemž jsou relevantní informace v objektové třídě „POZICE POHYBU“, vedoucí podniku může podepsat mnoho příkazů.“

Fragment popisu předmětné oblasti prezentovaný na obrázku lze nazvat šablonou, pomocí které lze zobrazit situaci, kdy jsou jakékoli dokumenty podepisovány úředníky a je nutné v databázi sledovat historii - kdo a kdy jednotlivců a když v určité pozici podporoval ten či onen dokument. To je důležité, protože doklady v předmětné oblasti zpravidla odrážejí pohyb (příchod, výdej) hmotných a nehmotných předmětů (příchod, spotřeba zboží do skladu, pohyb personálu, pohyb pacientů, účtování vysílané programy atd.).

Stáhnout přednášku: Nemáte přístup ke stahování souborů z našeho serveru.

Komunikace „One-to-one“ One-to-one. Tento typ spojení znamená, že každý objekt prvního typu odpovídá maximálně jednomu objektu druhého typu a naopak. Například: zaměstnanec může řídit pouze jedno oddělení a každé oddělení má pouze jednoho vedoucího.

Vztah „Jeden – k mnoha“ Jeden – k mnoha (nebo v opačném směru Mnoho – k jednomu). Tento typ vztahu znamená, že každý objekt prvního typu může odpovídat více než jednomu objektu druhého typu, ale každý objekt druhého typu odpovídá nejvýše jednomu objektu prvního typu. Například: Každé oddělení může mít mnoho zaměstnanců, ale každý zaměstnanec pracuje pouze v jednom oddělení.

Mnoho-k-mnoho vztah Mnoho-k-mnoho. Tento typ vztahu znamená, že každý objekt prvního typu může odpovídat více než jednomu objektu druhého typu a naopak. Tento typ připojení má někdy své vlastní atributy. Například: Každá faktura může obsahovat více položek a každá položka může být zahrnuta v různých fakturách.

Slabá entita je entita, kterou nelze jednoznačně identifikovat pomocí vlastních atributů, ale pouze prostřednictvím vztahu s jinou entitou. Nechť je například číslo zaměstnance jedinečné pouze v rámci oddělení, to znamená, že v různých odděleních mohou být zaměstnanci se stejnými čísly. Kombinace atributů „Číslo zaměstnance, Číslo oddělení“ bude v tomto případě jedinečná. Entita Zaměstnanec je slabá.

Binární, ternární spojení Pokud spojení spojuje dvě entity, nazývá se binární. Vztah může spojovat více než dvě entity, například vztah spojující tři entity se nazývá ternární: Vztah s aritou větší než 2 je obvykle typu many - to many s ohledem na všechny související entity.

Příklad modelu ER: Kancelář "Rohy a kopyta" Popis úkolu Kancelář "Rohy a kopyta" se zabývá obchodní činností prodejem výrobků z rohoviny a kopyt a poskytováním magických služeb. Zaměstnanec organizace má celé jméno, personální číslo a funkci. Zaměstnanci jsou rozděleni do několika oddělení. Každé oddělení má číslo, název a vedoucího. Zaměstnanec nemůže řídit více než jedno oddělení. Organizace spolupracuje s klientskými podniky. Každá firma má jméno a adresu. S podnikem lze uzavřít několik smluv. Smlouva je charakterizována jedinečným číslem, datem a typem. Na každou smlouvu dohlíží určitý zaměstnanec. Vzhledem k tomu, že zboží a služby podle smlouvy jsou prodávány klientovi, jsou v určitých intervalech vystavovány faktury. Faktura je charakterizována jedinečným číslem, datem vystavení, platebním termínem a částkou a také seznamem prodaného zboží a služeb s uvedením jejich množství. Na nezaplacené faktury se vyměřují penále. Fakturu je možné uhradit v několika splátkách, přičemž každá platba je charakterizována číslem, datem a částkou. Číslo platby je v rámci jeho účtu jedinečné. Ceny zboží a služeb se mohou v průběhu času měnit.
Příklad modelu ER: „Muzikanti“ Popis úlohy Je nutné vytvořit databázi pro ukládání informací o hudebnících, skladbách a koncertech. Hudebník je charakterizován svým jménem, datem narození a zemí narození. Práce obsahuje informace o názvu, skladateli a datu prvního uvedení. Hudebník může hrát na různé nástroje s různou mírou dovednosti. Soubory jsou tvořeny z účinkujících hudebníků. Každý soubor kromě svých členů obsahuje údaje o jménu, zemi a vedoucím. Nakonec jsou představení děl charakterizována datem, zemí, městem provedení, jakož i souborem, dirigentem a skutečně provedeným dílem.
17 Další příklady V učebnici „Databáze“ na webu

1.5 ER modelování

Datové modelování je prvním krokem k návrhu databáze, jde o přechod od objektů reálného světa k počítačovému modelu databáze.

Model ER slouží k integraci různých pohledů na data na koncepční úrovni. Na základě ER modelu jsou sestaveny ER diagramy, které zobrazují tři hlavní součásti ER modelu: entity, atributy, vztahy.

1.5.1 Subjekty

Vzhledem k tomu, že entita je objektem reálného světa, slova „entita“ a „objekt“ často znamenají totéž.

Na úrovni modelování ER entita ve skutečnosti znamená sadu entit, nikoli jednu entitu. Jinými slovy, entita v ER modelování odpovídá tabulce, a nikoli řádku v relačním prostředí, samostatný řádek v ER modelu se nazývá instance entity (výskyt entity). Entitu představuje obdélník, ve kterém je napsán název entity.

1.5.2 Atributy

Atributy popisují vlastnosti entity. Například entita STUDENT obsahuje atributy NSTBIL (ID studenta), FIO (jméno studenta), KURS (kurz) atd.

Rýže. 1.24. Atributy entity STUDENT v modelu ER.

Atributy mají domény. Doména je sada možných hodnot pro atribut. Například doménu pro číselnou hodnotu průměrného prospěchu studenta lze zapsat jako interval.

Primární klíče v modelu ER jsou podtržené. Pokud existuje více primárních klíčů, všechny jsou podtržené.

Atributy mohou být jednoduché nebo složené. Složený atribut je atribut, který lze dále rozdělit na několik atributů. Například atribut ADRESS lze rozdělit na STREET, CITY atd.

Atributy mohou být jednohodnotové nebo vícehodnotové. Atribut s jednou hodnotou je atribut, který může nabývat pouze jedné hodnoty. Například daňové identifikační číslo může mít pro každou osobu jeden význam. Jedinečné atributy nemusí být nutně jednoduché. Například sériové číslo 78-03-06-137846 je atribut s jednou hodnotou, ale zároveň je to atribut složený, protože lze jej rozdělit na region, ve kterém byl výrobek vyroben (78), kód města (03), výrobní směna (06), číslo výrobku (137846).

Atribut s více hodnotami je atribut, který může nabývat více hodnot. Osoba může například vystudovat několik univerzit a mít několik telefonních čísel.

V relačním DBMS nelze použít vícehodnotové atributy. Pokud existují atributy s více hodnotami, musíte v rámci této entity vytvořit několik nových atributů nebo vytvořit novou entitu sestávající z komponent vícehodnotového atributu.

Odvozený atribut je atribut, který není třeba ukládat do databáze, získává se pomocí nějakého algoritmu. Například věk zaměstnance lze získat jako celočíselnou hodnotu rozdílu mezi aktuálním datem a datem narození.

1.5.3. Spojení

Vztah je asociace. Subjekty účastnící se komunikace se nazývají účastníci. K pojmenování spojení lze použít sloveso nebo dokument. Například oddělení je řízeno zaměstnancem, zboží je přijímáno na základě uzavřené smlouvy atp.

Vztahy mezi entitami v kvantitativním vztahu mohou být „jeden k jednomu“, „jeden k mnoha“. Pojem „konektivita“ se používá k označení typů připojení.

Mohutnost vyjadřuje určitý počet instancí entity spojených s jednou instancí související entity. ER diagram neudává sílu komunikace, ale při programování aplikací mohou být užitečné informace o maximálním a minimálním počtu instancí entity. Například skupina nemůže zahájit výuku, pokud má méně než 10 studentů.

Vznikají vztahy mezi subjekty. Pokud entita závisí na existenci jedné nebo více jiných entit, pak je závislá na existenci. Pokud například zaměstnanci mají závislé osoby, pak pro výpočet daní můžete vytvořit vztah „zaměstnanec má závislé osoby“. V tomto případě závisí závislý subjekt na zaměstnaneckém subjektu.

Pokud entita může existovat mimo jiné entity, pak je nezávislá na existenci (existence –nezávislá). Například entita "část" může existovat nezávisle na entitě "dodavatel".

Pokud je jedna entita nezávislá na existenci jiné entity, vztah mezi nimi se nazývá slabý vztah nebo neidentifikující vztah. Slabé vazby nastanou, pokud primární klíč související entity neobsahuje primární součásti nadřazené entity. Například existují dvě entity COURSE a CLASS, popsané jako

KURZ ( CRS-KÓD, DEPT_CODE,…)

TŘÍDA ( KÓD TŘÍDY, CRS_CODE,…)

Mezi těmito entitami je slabé spojení, protože atribut CLASS_CODE je primární klíč entity CLASS, zatímco atribut CRS_CODE entity CLASS je cizí klíč. Primární klíč entity CLASS nedědí komponentu primárního klíče od entity COURSE. Slabá vazba je na ER diagramu znázorněna přerušovanou čarou.

Silný vztah, nazývaný také identifikační vztah, nastává, když jsou související entity existenčně závislé. K silnému vztahu mezi dvěma entitami dochází, když primární klíč související entity obsahuje komponentu primárního klíče nadřazené entity. Například entity

KURZ ( CRS-KÓD, DEPT_CODE,…)

TŘÍDA ( CRS_CODE, CLASS-SECTION,…)

Mají silné spojení, protože složený klíč entity CLASS zahrnuje primární klíč entity COURSE. V ER diagramu jsou silné vztahy znázorněny plnou čarou.

Je důležité mít na paměti, že důležité je pořadí, ve kterém jsou tabulky vytvářeny a načítány. Pro data je například nemožné, aby cizí klíč tabulky CLASS odkazoval na tabulku COURSE, která ještě neexistuje. Problém po sekvenci vytvoření tabulky v některých DBMS nenastane, dokud se data nenačtou. Aby se zabránilo narušení integrity na úrovni propojení, musí vztah 1:M načíst stranu "1" bez ohledu na to, zda je silný nebo slabý.

Účast účetní jednotky ve vztahu může, ale nemusí být vyžadována. Účast entity je volitelná, pokud jedna instance entity nevyžaduje, aby byla odpovídající instance entity přítomna v samostatném vztahu. Například v souvislosti s kurzem (COURSE) se vytvářejí skupiny (CLASS), alespoň v některých kurzech skupiny nemusí být vytvořeny. Tito. instance entity (řádek) v tabulce COURSE nutně nevyžaduje odpovídající instanci entity v tabulce CLASS. Proto je entita CLASS považována za volitelnou vzhledem k entitě COURSE. Volitelný vztah na ER diagramu je znázorněn malým kroužkem na straně volitelné entity. Existence volitelnosti znamená, že volitelná entita min má hodnotu komunikačního výkonu 0.

Účast entity ve vztahu je povinná, pokud jedna instance entity nutně vyžaduje odpovídající instanci entity v samostatném vztahu. Pokud není vedle entity zobrazen žádný další symbol, znamená to, že je tato entita zapojena do povinného spojení se související entitou. Minimální mohutnost pro požadovaný subjekt je 1.

a) Entita CLASS je pro entitu KURZ volitelná

b) Subjekty COURE a CLASS v kogentním vztahu.

Obr.1.25. Reprezentace povinných a volitelných spojení v modelu ER.

Z hlediska návrhu databáze je existence silného vztahu mezi nadřazenou entitou a její přidruženou entitou nebo entitami spojena se slabými entitami.

Slabá entita je entita, která splňuje dvě podmínky:

podmínka závislosti na existenci, tzn. nemůže existovat bez entity, se kterou je spojen;

jeho primární klíč je částečně nebo zcela odvozen od nadřazené entity vztahu.

V modelu ER jsou slabé entity znázorněny jako malé segmenty v každém ze čtyř rohů obdélníku entity.

Rýže. 1.26. Slabá entita v ER diagramech.

Slabá entita zdědí všechny části primárního klíče svého silného partnera. Je to návrhář databáze, kdo rozhoduje, zda má být entita prohlášena za slabou.

Stupeň vztahu udává počet přidružených entit. Unární vztah existuje, když je přidružení udržováno v rámci jediné entity. Binární vztah existuje, když jsou spojeny dvě entity. K ternárnímu vztahu dochází, když jsou spojeny tři entity. Ačkoli existují vyšší stupně spojení, jsou poměrně vzácné a nemají zvláštní jména.

Pokud má entita spojení sama se sebou, pak se takové spojení nazývá rekurzivní.

Rýže. 1.27. ER reprezentace rekurzivního spojení

Hierarchie zobecnění zobrazuje vztahy předek-potomek. V kontextu relačních databází zobrazuje hierarchie obecných pohledů vztahy mezi supertypy entity nejvyšší úrovně a podtypy entity nižší úrovně. Tito. nadtyp obsahuje sdílené atributy, zatímco podtyp obsahuje jedinečné atributy.

Rýže. 1.28. Hierarchie zobecněných reprezentací.

Vztahy se dědí, tzn. Subtyp entity dědí atributy a vztahy z nadtypu entity. Například všichni piloti, mechanici a účetní mají osobní čísla, celá jména, domácí adresy atd., ale mohou mít atributy jedinečné pro jejich specializaci. Jinými slovy, supertyp sady entit je obvykle spojen s několika jedinečnými a nepřekrývajícími se podtypy sady entit. Takové nepřekrývající se dluhopisy jsou označeny písmenem „G“.

Nadtyp a podtyp(y) udržují vztah 1:1. Například struktura tabulky ZAMĚSTNAN může být nahrazena dvěma tabulkami, z nichž jedna představuje nadtyp ZAMĚSTNANEC a druhá představuje podtyp PILOT.

Některé supertypy obsahují překrývající se podtypy. Zaměstnanec může být například učitel, ale zároveň administrátor.

Křížící se vazby jsou reprezentovány symboly 'Gs'.

Rýže. 1.29. Hierarchie zobecněných reprezentací s protínajícími se podtypy.

Model navrhl Peter Ping-Shen Chen v roce 1976. Většina moderních přístupů k návrhu databází (hlavně relačních) je založena na použití variací modelu ER. Doménové modelování je založeno na použití grafických diagramů, které zahrnují malý počet heterogenních komponent. Vzhledem k přehlednosti prezentace konceptuálních databázových diagramů jsou modely ER široce používány v systémech CASE, které podporují automatizovaný návrh relačních databází.

Základními pojmy modelu ER jsou entita, vztah a atribut.

Esence– je skutečný nebo imaginární objekt, informace o něm jsou zajímavé. V modelových diagramech ER je entita reprezentována jako obdélník obsahující název entity. V tomto případě je názvem entity název typu, nikoli konkrétní objekt – instance tohoto typu. Každá instance entity musí být odlišitelná od každé jiné instance stejné entity.

Spojení je graficky znázorněná asociace vytvořená mezi dvěma entitami. Tato asociace je vždy binární a může existovat mezi dvěma různými entitami nebo mezi entitou a jí samotnou (rekurzivní vztah). V každém spojení jsou identifikovány dva konce (v souladu s párem spojených entit), z nichž každý označuje název konce spojení, stupeň konce spojení (kolik instancí této entity je připojeno) , povinný charakter připojení (tj. zda se na tomto připojení musí podílet nějaká instance tohoto subjektu).

Spojení je reprezentováno jako čára spojující dvě entity nebo vedoucí od entity k sobě. V tomto případě se v místě, kde se spojení s entitou „spojuje“, použije tříbodový vstup do obdélníku entity. Pokud tato entita může mít mnoho instancí entity zapojené do vztahu, a jednobodový vstup, pokud se vztahu může účastnit pouze jedna instance entity. Požadovaný konec připojení je znázorněn plnou čarou a volitelný konec přerušovanou čarou.

Stejně jako entita je vztah obecným pojmem všechny instance obou párů souvisejících entit podléhají pravidlům asociace.

Rýže. 12. Příklad vztahu mezi entitami

Tento diagram lze interpretovat následovně: Každý STUDENT studuje pouze v jedné SKUPINĚ; Jakákoli SKUPINA se skládá z jednoho nebo více STUDENTŮ. Následující obrázek znázorňuje entitu MAN s rekurzivním spojením, které ji k sobě připojuje.

Rýže. 13. Příklad rekurzivního odkazu

Lakonický ústní výklad zobrazeného diagramu je následující:

Každý ČLOVĚK je synem jedné a jediné OSOBY;

Každá OSOBA může být otcem jednoho nebo více LIDÍ (dále jen „LIDI“).

Atribut entity je jakýkoli detail, který slouží k objasnění, identifikaci, klasifikaci, kvantifikaci nebo vyjádření stavu entity. Názvy atributů se zadávají do obdélníku představujícího entitu pod názvem entity a jsou zobrazeny malými písmeny. Například:

Rýže. 14. Obrázek entity s jejími atributy

Jedinečný identifikátor entity je atribut, kombinace atributů, kombinace vztahů nebo kombinace vztahů a atributů, která jednoznačně odlišuje jakoukoli instanci entity od jiných instancí stejného typu entity.

Stejně jako ve schématech relačních databází, schémata ER zavádějí koncept normálních forem a jejich význam úzce odpovídá významu relačních normálních forem. Všimněte si, že formulace normálních forem schémat ER objasňují význam normalizačních relačních schémat. Budeme uvažovat pouze velmi stručné a neformální definice prvních tří normálních forem.

V první normální formě Schémata ER odstraňují duplicitní atributy nebo skupiny atributů, tj. jsou identifikovány implicitní entity „skryté“ jako atributy.

Ve druhé normální formě atributy, které závisí pouze na části jedinečného identifikátoru, jsou eliminovány. Tato část jedinečného identifikátoru identifikuje jednu entitu.

Ve třetí normální formě atributy, které závisí na atributech, které nejsou součástí jedinečného identifikátoru, jsou eliminovány. Tyto atributy jsou základem jediné entity.

Zaměřili jsme se pouze na nejdůležitější koncepty datového modelu ER. Mezi složitější prvky modelu patří:

Podtypy a nadtypy entity. Model ER umožňuje určit vztah IS-A mezi typy. Navíc, pokud T, IS-A T 2 (kde T 1 a T 2 jsou typy entit), pak se T nazývá podtyp T 2 a T 2 je nadtyp T. Existuje tedy možnost zdědit typ entity založený na jednom nebo více supertypech.

Vztahy mnoho k mnoha. Někdy je nutné propojit entity tak, že na obou koncích vazby může být více instancí entity (např. všichni členové družstva společně vlastní majetek družstva). K tomu je zaveden typ vztahu „mnoho k mnoha“.

Specifikovatelné stupně připojení. Někdy je užitečné definovat možný počet instancí entit účastnících se daného vztahu (např. zaměstnanec se smí zúčastnit maximálně tří projektů najednou). Pro vyjádření tohoto sémantického omezení je dovoleno uvést na konci spojení jeho maximální nebo povinný stupeň.

Kaskádové mazání instancí entit. Některé vztahy jsou tak silné (samozřejmě v případě vztahu jedna k mnoha), že když odstraníte instanci referenční entity (odpovídající jednomu konci vztahu), musíte také odstranit všechny instance entity odpovídající mnoho konec vztahu. Odpovídající požadavek na „kaskádové odstranění“ lze formulovat při definování entity.

domény. Stejně jako u relačního datového modelu je užitečné mít možnost definovat potenciálně platnou sadu hodnot pro atribut entity (domény).

Tyto a další, složitější prvky datového modelu Entity-Relationship ho činí výkonnějším, ale zároveň poněkud znesnadňují jeho použití. Samozřejmě, když skutečně používáte ER diagramy pro návrh databáze, musíte se seznámit se všemi možnostmi.

Účel práce

Seznámení s metodami a algoritmem pro vytvoření modelu „Entity-Relationship“.

Základní pojmy modelu Entity-Relationship. ER modely.

Informační model se používá ve druhé fázi návrhu databáze, po slovním popisu předmětné oblasti. Měl by obsahovat formalizovaný popis předmětné oblasti, který mohou snadno „číst“ jak databázoví specialisté, tak všichni uživatelé. Tento popis by měl být natolik obsáhlý, aby bylo možné posoudit hloubku a správnost vývoje databázového projektu a samozřejmě by neměl být vázán na konkrétní DBMS. Výběr DBMS je samostatný úkol, pro jeho správné řešení je potřeba mít projekt, který není vázán na žádný konkrétní DBMS.

Infologický design je primárně spojen se snahou reprezentovat sémantiku předmětné oblasti v databázovém modelu, což se špatně odráží v síťových, hierarchických datových modelech.

Bylo navrženo několik datových modelů, nazývaných sémantické modely. Všechny tyto modely měly své pozitivní i negativní stránky, ale pouze model „entity-relationship“ neboli Entity Relationships se stal de facto standardem v modelování infologických databází. Všeobecně se vžil zkrácený název ER model a většina moderních CASE nástrojů obsahuje nástroje pro popis dat ve formalismu tohoto modelu. Kromě toho byly vyvinuty metody pro automatický převod databázového projektu z modelu ER na relační databázi při současném převodu na konkrétní model DBMS. Všechny systémy CASE mají vyvinuté nástroje pro dokumentaci procesu vývoje automatické generátory sestav umožňují připravit zprávu o aktuálním stavu projektu s podrobným popisem databázových objektů a jejich vztahů, což značně usnadňuje řízení projektu.

Jako každý model má i model vztahu mezi entitou několik základních konceptů, z nichž se podle předem stanovených pravidel staví složitější objekty. Tento model nejvíce odpovídá konceptu objektově orientovaného designu, který je základem pro vývoj komplexních softwarových systémů.

Podívejme se na základní koncepty, na kterých je založen model ER.

1. Esence, s jehož pomocí se modeluje třída objektů stejného typu. Entita má název, který je v rámci modelovaného systému jedinečný. Protože entita odpovídá určité třídě objektů stejného typu, předpokládá se, že v systému existuje mnoho instancí této entity. Objekt, kterému odpovídá pojem entity, má svou vlastní množinu atributy - charakteristiky, které určují vlastnosti daného zástupce třídy. V tomto případě musí být sada atributů taková, aby bylo možné rozlišit konkrétní instance entity. Například entita Zaměstnanec může existovat tato sada atributů: Osobní číslo, Příjmení, Jméno, Patronymie, Datum narození, Počet dětí, Přítomnost příbuzných v zahraničí. Je volána sada atributů, která jednoznačně identifikuje konkrétní instanci entity klíč. Pro entitu Zaměstnanec bude klíčovým atributem Osobní číslo, protože osobní čísla jsou u všech zaměstnanců daného podniku různá. Instance entity Zaměstnanec bude uveden popis konkrétního zaměstnance podniku. Jedním z běžných grafických znázornění entity je obdélník s názvem entity napsaným nahoře a atributy uvedenými níže, s klíčovými atributy označenými například podtržením nebo speciálním písmem, jak je uvedeno níže:

2. Mezi subjekty mohou být založeny komunikace - binární asociace , ukazující, jak spolu entity souvisí nebo jak spolu interagují. Vztah může existovat mezi dvěma různými entitami nebo mezi entitou a samotnou entitou (rekurzivní spojení). Ukazuje, jak spolu instance entit souvisí. Pokud je vytvořen vztah mezi dvěma entitami, pak definuje vztah mezi instancemi jedné a druhé entity. Pokud například existuje spojení mezi entitou „Student“ a entitou „Učitel“ a tímto spojením je vedení diplomových projektů, pak má každý student pouze jednoho vedoucího, ale stejný učitel může dohlížet na mnoho postgraduálních studentů. Bude se tedy jednat o vztah jeden k mnoha (1:M), jeden na straně „Učitel“ a mnoho na straně „Student“ (obr. 10.1.).

3. V různých notacích je komunikační síla znázorněna odlišně. Ve výše uvedeném příkladu je multiplicita znázorněna vydělením odkazu 3. Odkaz má společný název "Diploma Design" a má názvy rolí na obou stranách entit. Ze strany studenta se tato role nazývá „Provádí projekt pod vedením“; ze strany učitele se toto spojení nazývá „Vede“. Grafická interpretace vztahu umožňuje okamžitě přečíst význam vztahu mezi entitami, je vizuální a snadno interpretovatelná. Spojení jsou rozdělena do tří typů podle jejich početnosti: jedna ku jedné (1:1), jeden k mnoha(1:M), mnoho-k-mnoho(MM). Vztah one-to-one znamená, že instance jedné entity souvisí pouze s jednou instancí jiné entity. Vztah 1: M znamená, že jedna instance entity umístěné na levé straně vztahu může být spojena s několika instancemi entity umístěné na pravé straně vztahu. Vztah mnoho k mnoha (M:M) znamená, že jedna instance první entity může být spojena s více instancemi druhé entity a naopak jedna instance druhé entity může být spojena s více instancemi první entity. . Například vztah typu „Studium“ mezi entitami „Student“ a „Disciplína“ je vztah typu „many-to-many“ (M:M), protože každý student může studovat několik oborů a každý obor je studovalo mnoho studentů. Toto zapojení je znázorněno na Obr. 10.2.

4. Mezi dvěma entitami lze zadat libovolný počet spojení s různým sémantickým zatížením. Například mezi dvěma entitami „Student“ a „Učitel“ lze vytvořit dvě sémantická spojení, jedním je dříve diskutovaný „Diploma Design“ a druhý může být podmíněně nazýván „Přednášky“ a určuje, které přednášky učitelů budou student poslouchá a které Tento učitel studentům přednáší. Je jasné, že jde o spojení jako mnoho-k-mnoho.

5. Komunikace jakéhokoli z těchto typů může být povinné, pokud se na daném vztahu musí podílet každá instance entity, a volitelný- pokud se daného vztahu nemusí účastnit každá instance entity. V tomto případě může být spojení na jedné straně povinné A na druhé straně volitelný. Závaznost spojení se také v různých zápisech označuje odlišně. Nepovinnost spojení může být označena prázdným kroužkem na konci spojení a povinným charakterem kolmé čáry protínající spojení. A tento zápis má jednoduchý výklad. Kruh znamená, že se tohoto spojení nemůže zúčastnit žádná instance. A kolmice je interpretována tak, že v tomto spojení je zapojena alespoň jedna instance entity.

V dříve uvedeném příkladu připojení „Diploma Design“ je toto připojení interpretováno jako oboustranně volitelné. Ve skutečnosti každý student, který dělá diplomovou práci, musí mít svého vedoucího projektu diplomové práce, ale na druhou stranu ne každý učitel projekt diplomové práce vede. Proto se v této sémantické formulaci obraz tohoto spojení změní a bude vypadat stejně jako na Obr. 10.3.

V důsledku konstrukce doménového modelu ve formě množiny entit a vztahů získáme souvislý graf. Ve výsledném grafu je nutné se vyvarovat cyklických souvislostí – odhalují nesprávnost modelu.

Příklad vytvoření modelu ER

Pojďme navrhnout informační model systému určeného k ukládání informací o knihách a oblastech znalostí prezentovaných v knihovně. Začněme vývoj modelu identifikací hlavních entit.

Především je tu podstata „Knihy“; Každá kniha má jedinečnou šifru, která je jejím klíčem, a řadu atributů, které jsou převzaty z popisu předmětné oblasti. Sada instancí entit definuje sadu knih, které jsou uloženy v knihovně. Každý výskyt entity „Kniha“ neodpovídá konkrétní knize na poličce, ale popisu určité knihy, který je obvykle uveden v předmětovém katalogu knihovny. Každá kniha může být přítomna v několika kopiích, a to jsou právě ty konkrétní knihy, které jsou na policích knihovny. Aby se to projevilo, měli byste zavést entitu Instance, která by měla obsahovat popisy všech kopií knih, které jsou uloženy v knihovně. Každá instance entity Instance odpovídá konkrétní knize na poličce. Každá kopie má jedinečné přístupové číslo, které jednoznačně identifikuje konkrétní knihu. Každý výtisk knihy může být navíc buď v knihovně, nebo v rukou určitého čtenáře, a v druhém případě u daného výtisku datum, kdy si čtenář knihu převzal, a datum předpokládaného vrácení knihy. knihy jsou navíc označeny.

Mezi entitami „Knihy“ a „Instance“ existuje vztah (1:M), který je povinný na obou stranách. Co určuje tento typ připojení? Každá kniha může být v knihovně přítomna v několika kopiích, proto - vztah 1:M. Navíc, pokud knihovna nemá jedinou kopii dané knihy, neuložíme její popis, takže pokud je kniha popsána v entitě „Kniha“, pak se v knihovně nachází alespoň jedna kopie této knihy. To znamená, že ze strany knihy je připojení povinné. Co se týče entity „Kopie“, v knihovně nemůže existovat ani jedna kopie, která by se nevztahovala ke konkrétní knize, proto je povinné i připojení ze strany „Kopie“.

Nyní musíte určit, jak bude čtenář zastoupen v systému. Je přirozené navrhnout pro tento účel zavedení entity „Čtenáři“, jejíž každý výskyt bude odpovídat konkrétnímu čtenáři. V knihovně má každý čtenář přiděleno unikátní číslo čtenářského průkazu, které čtenáře jednoznačně identifikuje. Číslo čtenářského průkazu bude klíčovým atributem entity Čtenáři. Entita „Čtenáři“ musí navíc obsahovat další atributy, které jsou nutné k řešení zadaných úkolů; tyto atributy budou: „Příjmení Jméno Patronymic“, „Adresa čtenáře“, „Telefon domů“ a „Telefon do práce“. Navíc v entitě „Čtenáři“ byste měli zadat atribut „Datum narození“, který vám umožní kontrolovat věk čtenářů.

Každý čtenář může držet v ruce několik výtisků knih. Aby se tato situace odrážela, mělo by být vytvořeno spojení mezi entitami „Čtenáři“ a „Kopie“, protože čtenář si z knihovny vezme konkrétní kopii konkrétní knihy, nikoli pouze knihu. A jakou knihu daný čtenář má, zjistíte dodatečným spojením mezi entitami „Instance“ a „Knihy“ a toto spojení přiřadí každé instanci jednu knihu, takže můžete vždy jednoznačně určit, které knihy jsou v rukou čtenář, i když se spojujeme se čtenářem dostává pouze inventární čísla odebraných knih. Mezi entitami „Čtenáři“ a „Instance“ je vytvořen vztah 1:M a zároveň je na obou stranách volitelný. Čtenář v tuto chvíli nemusí držet v rukou ani jednu knihu a na druhou stranu tento výtisk knihy nemusí mít žádný čtenář, ale prostě stojí na poličce v knihovně.

Nyní byste měli odrážet poslední entitu spojenou se systémovým katalogem, který obsahuje seznam všech oblastí znalostí, o nichž jsou informace obsaženy v knihách knihovny. Název znalostní oblasti může být dlouhý a skládat se z několika slov, proto pro modelování systémového katalogu zavádíme entitu „System Catalog“ se dvěma atributy: „Knowledge Area Code“ a „Knowledge Area Name“. Atribut Kód oblasti znalostí bude klíčovým atributem entity.

Z popisu předmětové oblasti je známo, že každá kniha může obsahovat informace z více oblastí vědění a na druhou stranu knihovna může obsahovat mnoho knih souvisejících se stejnou oblastí vědění, proto je nutné stanovit mezi entitami „Systémový katalog“ a „Knihy“ propojení M:M, povinné na obou stranách. Systémový katalog by ve skutečnosti neměl obsahovat takovou oblast znalostí, informace o kterých nejsou uvedeny v žádné knize knihovny. A naopak, každá kniha by měla být přiřazena k jedné nebo více oblastem vědění, aby ji čtenář rychleji našel.

ER model předmětové oblasti „Knihovna“ je znázorněn na Obr. 10.4.

Informační model „Knihovna“ byl vyvinut pro úkoly uvedené výše. Neexistuje žádné ustanovení o ukládání historie četby knihy, například za účelem nalezení někoho, kdo knihu dříve držel a mohl jí ublížit. Pokud by byl stanoven úkol ukládat tyto informace, pak by byl infoologický model jiný.

Normalizace ER diagramů

Informační model se používá v raných fázích vývoje projektu. Pokud rozumíte jazyku konvencí, které odpovídají kategoriím modelu ER, lze jej snadno „číst“, proto je k dispozici pro analýzu vývojářům programátorů, kteří budou vyvíjet jednotlivé aplikace. Má na rozdíl od některých vět přirozeného jazyka jednoznačný výklad, a proto nemůže dojít k nedorozumění ze strany vývojářů.

Odborníci vždy raději vyjadřují své myšlenky nějakým formálním jazykem, který zajišťuje jejich jednoznačnou interpretaci. Takový jazyk pro programátory je jazykem algoritmů. Každý algoritmus má jednoznačnou interpretaci. Je implementován v různých programovacích jazycích, ale samotný algoritmus zůstává nezměněn. K popisu algoritmů se používají různé formalismy.

Modelový jazyk ER se stal běžně přijímaným jazykem pro popis databáze. Pro ER model existuje algoritmus pro jeho jednoznačnou konverzi na relační datový model, což umožnilo následně vyvinout mnoho instrumentálních systémů podporujících proces vývoje informačních systémů založených na databázové technologii. A ve všech těchto systémech existují prostředky pro popis infologického modelu vyvíjené databáze s možností automatického generování datalogického modelu, na kterém bude projekt v budoucnu realizován.

Pravidla pro převod ER modelu na relační databázi

Podívejme se na pravidla pro převod ER modelu na relační databázi.

1. Každá entita je spojena s relací v relačním datovém modelu. V tomto případě se názvy entity a vztahu mohou lišit, protože jména entit nemusí podléhat dalším syntaktickým omezením jiným než jedinečnost jména v rámci modelu. Názvy vztahů mohou být omezeny požadavky konkrétní DBMS, nejčastěji jsou tato jména identifikátory v nějakém základním jazyce, jsou omezena délkou a nesmí obsahovat mezery a některé speciální znaky. Entita může být například pojmenována « Katalog knih“ a je vhodné pojmenovat odpovídající vztah, například KNIHY (bez mezer a latinkou).

2. Každý atribut entity se stává atributem odpovídajícího vztahu. K přejmenování atributů musí dojít v souladu se stejnými pravidly jako vztahy pro přejmenování v odstavci 1. Pro každý atribut je specifikován specifický datový typ povolený v DBMS a zda je tento atribut povinný nebo volitelný.

3. Primární klíč entity se stává PRIMÁRNÍM KLÍČEM odpovídajícího vztahu. Atributy zahrnuté v primárním klíči vztahu jsou vyžadovány automaticky.

4. Ke každému vztahu odpovídajícímu podřízené entitě je přidána sada atributů hlavní entity, která je primárním klíčem hlavní entity. Ve vztahu odpovídajícím subentitě se tato sada atributů stává cizím klíčem.

5. Pro modelování volitelného typu vztahu na fyzické úrovni jsou atributy odpovídající cizímu klíči nastaveny tak, aby umožňovaly hodnoty null. U povinného typu připojení mají atributy vlastnost, že nemají žádné hodnoty null.

Je možné vytvořit pouze jeden vztah pro všechny podtypy jednoho nadtypu. Zahrnuje všechny atributy všech podtypů, ale pak pro řadu instancí nebude mít řada atributů smysl. A i když mají nedefinovaný význam, budou k rozlišení jednoho podtypu od druhého vyžadována další pravidla. Výhodou této reprezentace je, že se vytvoří pouze jeden vztah.

Ve druhé metodě se pro každý podtyp a nadtyp vytvoří samostatné vztahy. Nevýhodou tohoto způsobu zobrazení je, že vytváří mnoho vztahů, ale tento způsob má více výhod, protože pracujete pouze s významnými atributy podtypu. Pro umožnění přechodů na podtypy z nadtypu je navíc nutné zahrnout do nadtypu identifikátor připojení.

7. Při popisu vztahu mezi typem a podtypy je navíc nutné uvést typ diskriminátoru. Diskriminátor se může, ale nemusí, vzájemně vylučovat. Pokud je nastaven tento typ diskriminátoru, znamená to, že jedna instance entity nadtypu je spojena pouze s jednou instancí entity podtypu a pro každou instanci entity nadtypu existuje potomek. Kromě toho musíte u druhé metody určit, zda se do podtypů dědí pouze identifikátor nadtypu, nebo zda se dědí všechny atributy nadtypu.

8. Pokud v ER diagramu existuje vztah M:M (vztahy), který relační model nepodporuje, je zaveden speciální spojovací vztah, který je s každým původním vztahem spojen vztahem 1:M. Atributy tohoto vztahu jsou primární klíče souvisejících vztahů.

Algoritmus pro přenesení sémantického modelu do 3NF

Algoritmus pro redukci sémantického modelu na 3. normální formu může být následující:

1. Analyzujte diagram na přítomnost entit, které skrytě modelují několik různých vzájemně propojených tříd objektů v reálném světě (to odpovídá nenormalizovaným vztahům). Pokud je toto zjištěno, rozdělte každou z těchto entit na několik nových entit a vytvořte mezi nimi vhodná spojení; výsledný obvod bude v první normální formě.

2. Analyzujte všechny entity, které mají složené primární klíče, na přítomnost neúplných funkčních závislostí neprimárních atributů na atributech kandidátského klíče. Pokud jsou takové závislosti nalezeny, rozdělte tyto entity na 2, určete primární klíče pro každou entitu a vytvořte mezi nimi vhodné vztahy. Výsledný obvod bude ve druhé normální formě.

3. Analyzujte neklíčové atributy všech entit na přítomnost tranzitivních funkčních závislostí. Pokud nějaké najdete, rozdělte každou entitu na několik tak, abyste odstranili tranzitivní závislosti. Obvod je ve třetí normální formě.

Pomocí uvažovaných ustanovení normalizujeme schéma ER. Výsledek normalizace je na Obr. 5. Při normalizaci schématu byl do schématu zaveden vztah „Knihy-Katalogové vztahy“, obsahující atributy „ISBN“ a „Kód znalostní oblasti“, které slouží k implementaci spojení M:M „Knihy – systematický katalog“, a do vztahu „Kopie“ pro jeho V souvislosti se vztahy „Knihy“ a „Čtenáři“ byly zavedeny atributy „Číslo čtenářského průkazu“ a „ISBN“. Šipky ukazují směr připojení.

Lze ukázat, že schéma na Obr. 10.5 splňuje požadavky 3. normálního formuláře.