Datový model vztahu entit

Datový model entita-vztah byl představen v roce 1976 P. P. Chenem. Má mnoho společného s hierarchickými a síťové modely dat a vzhledem k jejich orientaci na proces navrhování lze považovat za zobecnění a rozvoj dříve diskutovaných modelů. Popsaný model umožňuje přímou reprezentaci spojů typu M: N.

Základní pojmy. Model entity-spojení" vychází z myšlenky, že skutečný svět se skládá z různých entit spojených určitými vztahy. Kategorie „esence“ a „vztah“ jsou prohlášeny za základní a jejich rozdělení se provádí ve fázi vytváření konkrétních reprezentací určité předmětné oblasti.

Každá entita patří do určité třídy nebo má odpovídající typ. Mezi entitami existují spojení, kterým uživatel přiřadí nějakou třídu (typ). Tím pádem, třída entity A třída dluhopisů definovat množiny konkrétních objektů a spojení mezi nimi. Všimněte si, že účetní jednotka může patřit do více než jedné třídy (například dodavatel může být také spotřebitel). V každém okamžiku je stav komunikace S mezi třídami entit E 1, E 2 ..., E n definovaný vztahem mezi sadami DOM E 1, DOM E2,..., DOM E n, kde DOM E i, i= - množina objektů typu E i.

Množinu vazeb v modelu „entity-relationship“ lze reprezentovat jako matematický vztah P třídy objektů:

Kde e i- entita patřící do množiny entit E i, kolona<e 1 e 2 ... e n >- spojení z mnoha spojení R. Není nutné, aby všichni E i, na kterém se určuje R, byly různé. Kolekce formulářů entit a tříd vztahů nejvyšší úroveň modelu.

Entity a vztahy jsou popsány jejich charakteristickými atributy. Mezi atributy entity nebo vztahu se rozlišuje podseznam, jehož hodnoty atributů jedinečně identifikují entitu nebo vztah v rámci typu. Forma entit, vztahů a atributů nižší úroveň modelu.

Graficky je model „entity-relationship“ prezentován ve formě diagramu, ve kterém každé třídě objektů odpovídá obdélník a třída spojení - šestiúhelník (obr. 2.7). Pod obdélníkem a šestiúhelníkem jsou uvedeny názvy atributů entit a vztahů.

Rýže. 2.7. Grafické znázornění Modely „vztahu entit“:

a) třída entity; b) třída spojů;

Při zobrazování třídy entit se budeme držet následující notace: klíčové atributy jsou podtržené, dvě různé třídy entit nemohou mít stejný název.

Pro komunikaci platí následující omezení:

typy spojení mezi třídami jsou specifikovány v párech (1:1, 1: N, N: 1, M: N). Když hodnoty M a N objasněno, převzato maximální hodnota;

jeden vztah se může týkat mnoha entit a jedna entita může mít mnoho vztahů. V případě připojení typu 1:1, 1: N, N: 1 není vždy nutné uvádět název připojení.

Uvažujme příklad znázornění konceptuálního databázového diagramu pomocí modelu „entity-relationship“ (obr. 2.8). Nech to být následující aplikace: řízení dodávek, skladu, výroby a zakázek. Tyto aplikace mohou využívat následující třídy subjektů: DODAVATEL (dodavatelé), BAZ-DET (základní díly), IZD-UNIT (výrobky a sestavy), KONTRAKT (smlouvy), ZAMĚSTNANEC (zaměstnanci), ODDĚLENÍ (oddělení).

Rýže. 2.8. Příklad diagramu modelu entita-vztah

Pro splnění požadavků výše uvedených aplikací se používají následující vztahy mezi entitami:

SELECT - umožňuje vybrat dodavatele základního produktu v závislosti na podmínkách prodeje a dodání (tyto podmínky jsou uvedeny ve schématu);

MONTÁŽ-DB - označuje základní díly (materiály), které se přímo používají k výrobě výrobku nebo sestavy, a také jejich počet;

MONTÁŽ-JEDNOTKA - označuje jednotky přímo zahrnuté v jiných jednotkách nebo produktech a také jejich počet;

POST-BAZ - spojuje dodavatele se základními detaily ve smlouvě;

DESIGNATE - charakterizuje produkty a komponenty ve smlouvě;

ODPOVĚDNÁ - označuje osobu odpovědnou za smlouvu;

ÚČASTNÍ SE - zavazuje dohodu a lidi, kteří se podílejí na její realizaci;

WORKS - spojuje oddělení a lidi, kteří v něm pracují;

ŘÍDÍ - označuje vedoucí tohoto oddělení.

Diagram modelu entita-vztah lze popsat tak, jak je znázorněno na Obr. 2.8.

Třídy entit:

E1/DODAVATEL [NOM-POST, FAM POST, ADRESA];

E2/BAZ-DET [NOM-BDZ-DET, NAIM-BASE-DET, MNOŽSTVÍ-SKLADEM, MINIMÁLNÍ-MNOŽSTVÍ];

E3/DOHODA [NOM-PES, DATUM];

Odkaz na třídy:

L 1/POST-BAZ L2/VYBRAT L3/MONTÁŽ-DB

[DODAVATEL, BAZ-DET, SMLOUVA];

[DODAVATEL, BASE-DET: CENA, TERMÍN];

[BASE-DET, ED-NODE: QUANTITY-DB];

Názvy atributů vztahů jsou od názvů tříd entit odděleny dvojtečkou.

Model entita-vztah zahrnuje různé doménové charakteristiky.

1. Vztah se může týkat několika tříd entit, například vztah POST-BAZ spojuje třídy entit DODAVATEL, BAZ-DET, KONTRAKT.

2. Vztah může odkazovat vícekrát na stejnou třídu entity, například vztah ASSEMBLY-NODE.

3. Mnoho vztahů může patřit do stejné třídy entit, například vztahy WORKS a MANAGES mezi entitami EMPLOYEE a DEPARTMENT.

4. Model zobrazuje různá zapojení, například 1:1, 1: N, M: N.

5. Přítomnost dvou tříd entit pro díly BAZ-DET a IZD-UZEL umožňuje řídit: dodávky dílů a vyhledávat dodavatele na základě třídy BAZ-DET; proces výroby výrobků pomocí třídy IZD-UZEL.

6. Dvě třídy entit BAZ-DET a IZD-NODE mají společné a specifické atributy. Přítomnost společných atributů vede k určité redundanci dat. Specifické atributy jsou vyžadovány rozsahem objektů.

V diagramu (obr. 2.8) bylo možné uvažovat pouze o funkci prodeje produktů. V tomto případě by externí diagram zahrnoval pouze entity: základní části, jednotky, produkty, které je třeba extrahovat spolu se spojeními mezi nimi z konceptuálního diagramu. v vnější obvod Je třeba rozlišovat mezi výrobky a sestavami, protože některé informace požadované pro prodej se týkají pouze výrobků.

Pro řešení problematiky řízení skladu a výroby výrobků je nutné popsat sortiment výrobků a sestav s uvedením: složení výrobků ze sestav a základních dílů, složení sestav z podsestav a základních dílů.

Pro označení konkrétnějších vztahů mezi entitami existují Přímo A zpětná vazba. Každé takové spojení má jméno a dvojici čísel.

Rýže. 2.9. Schéma přímých a zpětných vazeb

Například ve vztahu mezi entitami ZAMĚSTNANEC a ODDĚLENÍ (obrázek 2.9) přímý vztah PRÁCE udává, že zaměstnanec pracuje pouze v jednom oddělení; Zpětná vazba OBSAHUJE uvádí, že oddělení obsahuje alespoň jednoho zaměstnance (obvykle mnoho zaměstnanců). Jinými slovy, spojení L mezi dvěma třídami entit A A V označuje, že entita A spojené minimálně s M a maximálně s N entity V. Někdy N nemusí být určeno.

Model entita-vztah vznikl v souvislosti s potřebami návrhu databáze. Splňuje dvě důležitá kritéria: za prvé, síla jeho nástrojů mu umožňuje reprezentovat struktury a omezení vlastní reálnému světu, a za druhé, propast mezi schopnostmi modelu a průmyslovými DBMS není příliš velká. Tyto modely pomáhají návrhářům komunikovat s uživateli během procesu analýzy a návrhu databáze.

Relační model

Základní pojmy

V relačním datovém modelu jsou informace uloženy v jedné nebo více souvisejících tabulkách. Jedna tabulka obvykle představuje kolekci (skupinu) buď skutečných objektů, nebo nějakých abstraktních pojmů nebo událostí stejného typu. Každá položka v tabulce identifikuje jeden objekt skupiny. Tabulka se skládá z řádků a sloupců, které se nazývají záznamy a pole. Tabulky mají následující vlastnosti:

1. Každý prvek tabulky představuje jeden datový prvek, tzn. skupina hodnot v jednom sloupci jednoho řádku není povolena;

2. Všechny sloupce v tabulce jsou homogenní. To znamená, že prvky sloupce jsou stejné povahy. Sloupce jsou pojmenovány;

3. V tabulce nejsou dva stejné řádky;

4. Pořadí řádků a sloupců v tabulce může být libovolné. Při operacích s takovou tabulkou lze její řádky a sloupce prohlížet v libovolném pořadí, bez ohledu na jejich informační obsah nebo význam.

Tabulky s takovými vlastnostmi jsou přesným prototypem matematické dvourozměrné množiny – vztahu. Ale tyto dva pojmy nejsou ekvivalentní. Relace je abstraktní matematický objekt a tabulka je konkrétní reprezentace tohoto abstraktního objektu. Rozdíl se projevuje v jejich vlastnostech. V relaci mohou být řádky a sloupce neuspořádané, ale v tabulce jsou řádky seřazeny shora dolů a sloupce zleva doprava. Řádky v tabulce mohou být opakované řádky, ale ne ve vztahu.

V relačním modelu je každý řádek v tabulce jedinečný. Toho je dosaženo použitím klíčů, které obsahují jedno nebo více polí tabulky. Klíče jsou uloženy organizovaným způsobem, který umožňuje přímý přístup k záznamům tabulky během vyhledávání. Spojení mezi tabulkami se provádí prostřednictvím hodnot jednoho nebo více odpovídajících polí (většinou klíčových).

Zde je několik termínů používaných v relačním modelu:

· přístup (relation) je dvourozměrná sestava - stůl, který splňuje výše uvedené požadavky;

· Atribut je vlastnost, která charakterizuje objekt. Ve struktuře tabulky má každý atribut název a odpovídající záhlaví sloupce tabulky. Je volán počet atributů stupeň vztahu ;

· Kolonou motorek (n-tice) je řádek tabulky. V obecný případ n-tice jsou množinou párů<атрибут>, <значение>. Každá hodnota musí být atomická, tzn. nemůže být vícehodnotový nebo složený. V relačním modelu proto nejsou podporovány vícehodnotové a složené atributy. Je volán počet n-tic základní číslovka ;

· Doména představuje množinu všech možných hodnot specifický atribut vztah.

· Primární klíč je atribut relace, který jednoznačně identifikuje každou z jeho n-tic. Klíč může být složený (komplexní), tj. může se skládat z několika atributů.

· Potenciální klíč je podmnožina atributů vztahu, která má následující vlastnosti:

Vlastnost jedinečnosti. Neexistují žádné identické n-tice se stejnými hodnotami kandidátského klíče;

Vlastnost nadbytečnosti. Žádná podmnožina potenciálního klíče není jedinečná.

Každý vztah má nutně kombinaci atributů, které mohou sloužit jako klíč. Jeho existence je zaručena tím, že relace je matematická množina, která nemůže obsahovat shodné n-tice, tzn. Podle alespoň celá sada atributů má vlastnost jednoznačně identifikovat n-tice vztahu. Mohou nastat případy, kdy má relace několik kombinací atributů, z nichž každá jednoznačně identifikuje všechny n-tice vztahu. Všechny tyto kombinace atributů jsou potenciální resp možné klíče vztah. Jeden kandidátský klíč je vybrán jako primární klíč, zbytek se bude nazývat sekundární (alternativní). Mohou dokonce nastat situace, kdy by mohl být jako primární klíč vybrán jakýkoli z kandidátských klíčů. Příkladem je periodická tabulka obsahující pole název, Symbol A Protonové číslo. Potenciální klíče jsou v teorii vztahů velmi důležité. Používají se k adresování n-tic. Zadáním hodnoty potenciálního klíče je zaručeno, že neobdržíme více než jednu n-tici. Pro vztahy, které souvisejí s jinými „základními“ vztahy, existují také cizí klíče, které se používají k navázání vztahu.

· Externí klíč - Toto je atribut podřízeného vztahu, který se používá k navázání spojení se základním vztahem. Obsahuje hodnoty, které vždy odpovídají některým z kandidátských klíčových hodnot základního vztahu.

Na základě výše uvedených pojmů lze matematicky vztah popsat následovně. Ať jsou dány n sady Dl, D2, D3,..., Dn. Pak postoj R existuje mnoho uspořádaných n-tic<d1, d2, d3 ,..., dn>, Kde nevím Î Dk, nevím - atribut , A Dk – doména vztahu R.

V polovině 70. let navrhl inženýr IBM Codd datový model založený na matematických operacích počtu a relační algebry. Hlavní konstrukční jednotkou tohoto modelu byla relace. Proto se tento datový model nazývá relační. Codd také vyvinul jazyk pro manipulaci s daty reprezentovanými jako vztahy. Navrhl dvě verze jazyka pro manipulaci s daty, které jsou ekvivalentní ve svých vyjadřovacích schopnostech:

5. Relační algebra. Je to procedurální jazyk, protože relace vyplývající z dotazu na relační databázi je vyhodnocena provedením sekvence relačních operátorů aplikovaných na vztahy. Operátory se skládají z operandů, což jsou vztahy, a relačních operací. Výsledkem relační operace je vztah. Operace relační algebry lze rozdělit do dvou skupin. První skupinu tvoří operace na množinách, které zahrnují operace sjednocení, průnik, rozdíl, dělení a kartézský součin. Druhou skupinu tvoří speciální operace se vztahy: projekce, výběr a spojení.

6. Relační kalkul. Jde o neprocedurální jazyk popisného nebo deklarativního charakteru, obsahující pouze informaci o požadovaném výsledku. Proces získání tohoto výsledku je před uživatelem skrytý. Mezi jazyky tohoto typu patří SQL a QBE. První je založen na n-ticovém relačním kalkulu, druhý na doménovém relačním kalkulu.

Pomocí těchto jazyků můžete načíst podmnožinu sloupců a řádků tabulky, vytvářet menší tabulky a kombinovat související data z více tabulek a vytvářet tak větší tabulky. V důsledku toho mohou různí uživatelé v relační databázi vybrat různé sady dat a vztahy mezi nimi. Tento způsob prezentace dat je pro koncového uživatele nejpřirozenější a nejsrozumitelnější. Relační datový model je velmi flexibilní, protože jakoukoli reprezentaci dat s určitou redundancí lze redukovat na dvourozměrné tabulky.

Vztah

Teoretickým základem relačního přístupu k databázím je matematická teorie relací. V relačních databázích se používají základní pojmy a operace s vztahy.

Základní pojmy a způsoby reprezentace vztahů. Jakýkoli systém (matematický, informační) přímo souvisí s množstvím některých objektů nebo Prvky. V matematice se tedy používají množiny čísel: přirozené, kladné, reálné atd. V algebře se uvažují prvky, které lze sčítat, odečítat, násobit atd. a v geometrii - množiny bodů: přímky, úsečky, letadla atd.. Informační systém zařízení, např. vzdělávací instituce, obsahuje informace o učitelích, studentech, katedrách, fakultách, laboratořích, rozvrhech tříd atd.

Kromě prvků systém zahrnuje vazby a vztahy mezi nimi. Ano, čísla A A b může být stejný ( A = b), nerovná se ( A ≠ b), A více nebo stejné b (A ≥ b); postavy A A V může být kongruentní ( A = V), A může obsahovat V (A B); dvě rovné A A V může být paralelní ( A || V), kolmice (). Student A patří do sady A(studenti katedry).

Všechny výše uvedené vztahy se týkají dvou objektů a jsou proto tzv binární vztahy nebo jednoduše vztahy. Vztah mezi třemi objekty se nazývá trojice a mezi n předměty - n-ární. Vztah mezi objekty ZÁKAZNÍK, DODAVATEL, PRODUKT je tedy ternární.

Binární relace R mezi sadami A A V(označeno R(A, V)) je jakákoliv sada uspořádaných párů ( A, b), kde A A, b V. Pokud ( A,b) R, pak to říkají A je ve vztahu R Na b a zapište aRb, Od sady objednaných párů ( A, b), kde A A, b V, je kartézský produkt A× V, pak jakákoli podmnožina tohoto součinu bude binární relací.

Příklad 2.1. Zvažte mnoho dodavatelů a mnoho nabízených produktů. Jakákoli podmnožina vztahů DODAVATEL – PRODUKT je binární vztah.

Příklad 2.2. Nechte dané sady A= (1, 2, 3) a V= (2, 3, 4, 5, 6). kartézský součin A× V- toto je sada dvojic:

(1, 2), (1, 3), …, (1, 6),

(2, 2), (2, 3), …, (2, 6),

(3, 2), (3, 3), …, (3, 6).

Vytvořme binární vztah R, jehož první prvek je dělitelem druhého. Dostaneme následující binární vztah: R={(1, 2), (1, 3), (1, 4), (1, 5), (1, 6), (2, 2), (2, 4), (2, 6), (3, 3), (3,6)}.

Příklad 2.3. Nechť jsou jména dětí v rodině Olga (O), Pavel (P), Ivan (I). přístup A- Bratr b vůle:

R= ((P, O), (I, O), (P, I), (I, P)).

Ve vztahu R(A, V) spoustu A, tj. volá se množina všech prvních souřadnic doména definice vztahu R a sadu B, tj. množina všech druhých souřadnic, - rozsahu jeho hodnot. Takže například 3.3 je doménou definice množina (P, I) a doména hodnoty - nastavit(O, P, I).

Doplněk binární relace R budeme nazývat vztah, který definuje podmnožinu

= (A× B)\R,

těch. a b tehdy a jen tehdy ( A, b) R. Takže například 2.2

= {(2, 3), (2, 5), (3, 2), (3, 4), (3, 5)}.

Binární vztahy lze specifikovat různými způsoby: maticemi, grafy, tabulkami (sekcemi). přístup R(A, V), kde A = {A 1, A 2 , ..., a m}; B = {b 1, b 2 , ..., b n), může být reprezentována maticí sousednosti, jejíž řádky odpovídají prvkům A, a sloupce - k prvkům V; na křižovatce a jářádek a b j tý sloupec je zapsán 1 if a i Rb j, a 0 pokud a i Rb j. Matice sousedství pro vztahy R a například 2.2 vypadají

Binární relace R(A, V) lze zobrazit jako orientovaný graf. Prvky sady A A V- vrcholy grafu a ty a jen ty prvky jsou spojeny hranou A A, b V, pro který ( A, b) R. Takže ve formě grafu na obr. 2.10 poskytuje příklad vztahu:

Rýže. 2.10. Znázornění vztahu R jako graf

Nechť jsou uvedeny tři sady A, V, S a dva vztahy R(A, V) A S(B, S). Složení nebo násobení, vztahy R A S nazývá se binární relace R.S.(nebo R*S) mezi prvky množin A A S takové, že aRSc právě tehdy, pokud existuje alespoň jeden prvek b V, což je pravda aRb A bSc.

Příklad 2.4. Podívejme se na sady

A = {A 1, A 2 , A 3 }, V = {b 1 , b 2 , b 3 }, S = {S 1 , C 2 , C 3 , C 4 }

a vztahy

R (A, B) = {(A 1 , b 2), (A 2 , b 1), (A 2 , b 3), (A 3 , b 4)},

S(B, C) = {(b 1 , C 2), (b 2 , C 1)}.

Násobící poměry R.S. lze znázornit ve formě grafu (obr. 2.11.).

Násobení binárních relací je asociativní, tj. R.S.)T= R(SVATÝ). Vztah nechť je dán R(A, V), S(B, S) A T (S, D). Pak A(R.S.)Td= aR(SVATÝ)d, tj. živel A A pokud a pouze tehdy je v každém ze vztahů ( R.S.)T A R(SVATÝ) k prvku d D když takové prvky existují b V A C S, Co aRb, bSc, cTd. Násobení vztahů však není v obecném případě komutativní (komutativní), tzn. R.S.≠S.R.. Tato operace se provádí pouze ve zvláštních případech (v tomto případě se říká, že R A S zaměnitelné).

Příklad 2.5. Nechte dané sady

A = (a, b), B = (a, b, c), C = (b, c)

a vztahy R (A, V) = {(A, b), (b, S)}, S (B, C) = {(b, S), (A, b)). Pak aRSc = aSRc pro jakékoli A A A C S.

Násobení k vztahy R na sadě H, tj. k-tý stupeň R, označené Rk, je rekurzivně definován takto:

1) aR l b pravda, když pravda aRb;

2) aR i b Pro i>0 je pravda, pokud taková existuje S A,
Co oblouk A cR i-l b jsou pravdivé.

Nechte nás aR 3 b. Pak je tu takový S 1, co oblouk 1 a C 1 R 2 b. Pro C 1 R 2 b existuje něco takového S 2 co C 1 Rc 2 a C 2 Rb, tedy pro аR 3 b existuje taková věc S 1, S 2 A, Co аRс 1 , C 1 Rc 2 a S 2 Rb.

Nechť jsou vztahy dány v jedné nebo více množinách R i (i prochází mnoha indexy já) A S. Pak

, (2.1)

Podle A[(U R i)S]S existuje takový prvek b, Co A(Ri)b A bSc. A to se zase rovná existenci takového indexu i 0 co R b A bSc, tj.

Rýže. 2.11.Znázornění fungování násobných vztahů RS ve formě grafu

a(R S) c a proto A(R i S)C. Všimněte si, že v rovnosti (3.1) nelze sjednocení nahradit průnikem. Z (3.1) vyplývá, že pokud jsou dané vztahy R, R" A S, a R R", Že

RS R"S, SR SR". (2.2)

Opravdu, od té doby R R' Že R R" = R“, což vede k rovnosti ( R R’) S = RS R’S = R’S, což je ekvivalentní včetně RS R"S.a, pokud pro funkční vztah R funkční je i jeho symetrický vztah.

Každý postoj R(A, V) lze přiřadit k funkci F(X), pokud jeho průřez pro každého X A buď prázdný, nebo prvek množiny V. Li F(X) je definován všude, tj. definiční obor funkce se shoduje s A, pak říkají, že poměr R(A, V) je mapa sady A PROTI V. Funkční vztah R(A, V) je nazýván displej A PROTI V, pokud pro každého A A existuje jeden a pouze jeden prvek

Rýže. 2.12. Znázornění funkčního vztahu R(A, B) ve formě grafu

b B, uspokojující vztah aRb. Živel b volal cestaživel A a je určeno aR a prvek A- prototyp prvku b při zobrazení R. Sada všech prototypů prvku b PROTI A při zobrazení R volal kompletní prototyp tento prvek v A.

Zobrazení může být specifikováno tabulkou sestávající ze dvou řádků. Prvky jsou napsány na horním řádku A A a pod nimi jsou prototypy ze sady odpovídající jmenovaným prvkům V. Například tabulka

definuje mapování z množiny (1, 2, 3, 4) do množiny (2, 5, 1, 4). Zároveň 1 R = 2, 2R = 5, 3R=1, 4R = 4.

Nechat R- Zobrazit A PROTI V, Q- Zobrazit V PROTI S. Mapování násobení PQ bude mapování A PROTI S a pro kohokoli X?A veletrh X(PQ) = (xP)Q. Opravdu, nech X(PQ)=C. Pak pro některé na V my máme xRu A yQc, kde xP = na a proto S = (xP)Q. Zpět z ( xP)Q by měl X(PQ).

Násobení mapování specifikovaných tabulkami si ukážeme na příkladu:

Zobrazit R volal subjektivní (dohadování) nebo zobrazení sady A pro mnoho V, kdy každý prvek b?V má alespoň jeden prototyp A.

Příklad 2.6. Nechat A A V- sady reálná čísla. mapování (surjektivní) A na V může být funkce definovaná vzorcem X→ Z X+ 5, tzn. X jde do y = 3X + 5.

Funkce X→na=X 2 definuje nastavené zobrazení A PROTI B, což není surjektivní, protože záporná čísla z V nejsou obrázky prvků z A.

Zobrazit R sady A do množství V se nazývá jedna ku jedné, pokud je inverzní vztah R- Jsem mapování V PROTI A. Pro mapování jedna ku jedné definované pomocí sekcí je nutné a postačující, aby každý prvek V se objevil ve spodním řádku tabulky jednou a pouze jednou. Tři tabulky uvedené dříve jako příklad násobení zobrazení tedy odpovídají zobrazení jedna ku jedné.

Mapování typu one-to-one pro které R všude definovaná, tzv injekční (injekce).

Příklad 2.7. Nechat A- sada reálných čísel, V- množina kladných reálných čísel. Zobrazit X→na = e x je jedna ku jedné, protože každá na odpovídá X= log y. Máme tedy injektivní zobrazení, jehož inverzní je zobrazení na→X=ln y.

Mapování jedna ku jedné R mezi prvky jedné množiny, pro které R A R- Jsem všude definován, volán sebereferenční nebo bijektivní mapování. Bijektivní mapování je jak surjektivní, tak injektivní.

Při mapování určité množiny do sebe říkáme, že mapování aRb překládá bod A přesně b. Když je volán bod aRa pevný bod Zobrazit R. Pokud všechny body sady A jsou během mapování nehybné, pak je zavoláno mapování identické a označují E A. To je zřejmé E -1 =E a pro jakýkoli displej R RE=ER = R. Při zadávání mapování na sebe pomocí sekcí bude mít spodní řádek tabulky stejné prvky jako horní řádek (možná v jiném pořadí) a každý z nich se objeví jednou a pouze jednou:

Matice sousedství odpovídající mapování do sebe je čtvercová:

R

Grafická reprezentace zobrazení na sebe sama se skládá z cyklů (konečných nebo nekonečných).

Účel modelu.

Hašování.

Tato metoda se používá, když je předem známa celá sada klíčů a lze ji umístit paměť s náhodným přístupem. V tomto případě je postaven speciální funkce, který jedinečně mapuje sadu klíčů na sadu ukazatelů, nazývaných hashovací funkce (z anglického slova „to hash“ - řezat, sekat). S takovou funkcí můžete vypočítat adresu záznamu v souboru pomocí daného vyhledávacího klíče. Obecně platí, že klíčová data používaná k určení adresy záznamu jsou organizována v tabulce zvané hashovací tabulka.

Pokud je sada klíčů předem neznámá nebo je velmi velká, pak se upouští od myšlenky jedinečného výpočtu adresy záznamu z jeho klíče a hashovací funkce je považována jednoduše za funkci, která rozptyluje sadu klíčů do sadu adres.

2.1.Reprezentace dat pomocí modelu "entity-relationship".

Než začne vývojář vytvářet automatizovaný systém zpracování informací, musí si vytvořit představy o objektech, faktech a událostech, se kterými bude pracovat. tento systém. Aby bylo možné tyto pojmy přenést do jednoho nebo druhého datového modelu, je nutné je nahradit informačními reprezentacemi. Jeden z nejvíce pohodlné nástroje jednotná reprezentace dat, nezávislá na implementátorovi software, je entitně-vztahový model (ER - model).

Model entita-vztah je založen na některých důležitých sémantických informacích o reálném světě a je určen logický prezentace dat. Definuje význam dat v kontextu jejich vztahů s jinými daty. Důležitá je pro nás skutečnost, že od modely vztahů mezi entitou všechny existující lze vygenerovat datové modely(hierarchický, síťový, relační, objektový), proto je nejobecnější.

Všimněte si, že model vztahu entita není datovým modelem ve smyslu definovaném v odstavci 1.1.2, protože nedefinuje operace s daty a je omezen pouze na popis jejich logické struktury.

Model vztahu mezi entitou navrhl v roce 1976 Peter Ping-Sheng Chen.

Jakýkoli fragment předmětné oblasti může být reprezentován jako množina entit, mezi nimiž je nějaká mnoho spojení. Uveďme definice:

Podstata Entita je objekt, který lze identifikovat nějakým způsobem, který jej odlišuje od jiných objektů. Příklady: speciální osoba, podnik, událost atd.

Sada entit(množina entit) - množina entit stejného typu (mající identické vlastnosti). Příklady: všichni lidé, firmy, svátky atd. Množiny entit nemusí být disjunktní. Například entita, která patří do množiny ČLOVĚK, patří také do množiny LIDÉ.

Ve skutečnosti se zdá, že podstatou je mnohost atributy, které popisují vlastnosti všech členů tato sada entity.

V budoucnu budeme k definování entity a jejích atributů používat zápis formuláře

ZAMĚSTNANEC (ČÍSLO_PERSONÁLU, JMÉNO, VĚK).

Například oddělení, do kterých je podnik rozdělen a ve kterých pracují zaměstnanci, lze popsat jako ODDĚLENÍ (ODDĚLENÍ_ČÍSLO, JMÉNO).

Zavolá se sada hodnot (doména) atributu doména. Například pro atribut AGE je doména (říkejme jí NUMBER_YEARS) určena intervalem celých čísel větším než nula, protože neexistují žádní lidé se záporným věkem.

Ve zmíněném článku P. Chena je atribut definován jako funkce, která mapuje množinu entit na množinu hodnot nebo na kartézský součin množin hodnot. Atribut AGE se tedy mapuje na množinu hodnot (doména) NUMBER_YEARS. Atribut NAME mapuje sady hodnot FIRST NAME, LAST NAME a PATRONIC do kartézského součinu.

Odtud se to určuje klíč entity- skupina atributů taková, že mapování ze sady entit na odpovídající skupinu sad hodnot je mapování jedna ku jedné. Jinými slovy: klíč entity je jeden nebo více atributů, které danou entitu jednoznačně identifikují. V našem příkladu je klíčem entity EMPLOYEE atribut PERSONNEL_NUMBER (samozřejmě pouze v případě, že všechna personální čísla v podniku jsou jedinečná).

Spojení(vztah) je sdružení založené mezi více subjekty. Příklady:

protože každý zaměstnanec pracuje v nějakém oddělení, existuje mezi subjekty ZAMĚSTNANCE a ODDĚLENÍ vztah „pracuje v“ neboli ODDĚLENÍ-ZAMĚSTNANEC;
protože jeden ze zaměstnanců oddělení je jeho vedoucím, pak mezi subjekty ZAMĚSTNANEC a ODDĚLENÍ existuje spojení „vedoucí“ nebo ODBOR-VEDOUCÍ;
Mohou také existovat spojení mezi entitami stejného typu, například spojení PARENT - DESCENDANT mezi dvěma entitami PERSON;

Bohužel neexistuje hlavní pravidla určení, co je považováno za entitu a co je spojení. Ve výše uvedeném příkladu jsme předpokládali, že „vedení“ je spojení. Můžeme však uvažovat entitu „vedoucí“, která má spojení „řídí“ s entitou „útvar“ a „je“ s entitou „zaměstnanec“.

Vztah může mít také atributy. Například pro vztah ODDĚLENÍ-ZAMĚSTNANEC můžete nastavit atribut WORK_TERRENCE_IN_DEPARTMENT.

Role entity ve vztahu- funkce, kterou entita vykonává v daném spojení. Například ve vztahu PARENT-CHILD mohou mít entity PERSON role "rodič" a "dítě". Zadání rolí v modelu vztahu entita je volitelné a slouží k objasnění sémantiky vztahu.

Sada připojení(vztahová množina) je vztah mezi n(a n ne méně než 2) entity, z nichž každá patří do určité množiny entit.

Když n=2, tj. když vztah kombinuje dvě entity, nazývá se binární. Bylo prokázáno, že n-ary sada připojení ( n>2) lze vždy nahradit mnoha binárními, ale ty první lépe odrážejí sémantiku předmětné oblasti.

Nazývá se počet entit, které mohou být spojeny prostřednictvím sady připojení s jinou entitou stupeň připojení. Zvažování stupňů je zvláště užitečné pro binární vztahy. Mohou existovat následující stupně binárních vazeb:

jedna ku jedné (označeno 1: 1 ). To znamená, že v takovém vztahu entity s jednou rolí vždy odpovídají nejvýše jedné entitě s jinou rolí. V příkladu, na který jsme se podívali, se jedná o vztah „vedoucích“, protože každé oddělení může mít pouze jednoho nadřízeného a zaměstnanec může řídit pouze jedno oddělení. Tento fakt je znázorněno na následujícím obrázku, kde obdélníky představují entity a kosočtverec představuje vztah. Protože stupeň spojení pro každou entitu je 1, jsou spojeny jednou čárou.

Další důležitou vlastností spojení kromě jeho stupně je členská třída subjekty v něm zahrnuté popř mohutnost komunikace. Vzhledem k tomu, že každé oddělení musí mít manažera, musí mít každý subjekt „ODDĚLENÍ“ nutně odpovídající subjekt „ZAMĚSTNANEC“. Ne každý zaměstnanec je však vedoucím oddělení, proto v tomto ohledu ne každý subjekt „ZAMĚSTNANEC“ má přidružený subjekt „ODDĚLENÍ“.

Tedy entita „ZAMĚSTNANEC“ prý má povinná členská třída(tato skutečnost je indikována i uvedením intervalu počtu možných výskytů entity ve vztahu, v tomto případě je to 1,1), a entita "ODDĚLENÍ" má volitelná členská třída(0,1). Nyní toto spojení můžeme to popsat jako 0,1:1,1 . V následujícím budeme označovat mohutnost binárních spojení stupně 1 takto:

jeden k mnoha ( 1:n). V tomto případě může entitě s jednou rolí odpovídat libovolný počet entit s jinou rolí. Jedná se o vztah ODDĚLENÍ – ZAMĚSTNANCE. Každé oddělení může mít libovolný počet zaměstnanců, ale zaměstnanec může pracovat pouze v jednom oddělení. Graficky stupeň spojení n se zobrazí jako „stromová“ čára, jak je znázorněno na následujícím obrázku.

Tento obrázek dále ilustruje skutečnost, že mezi dvěma entitami lze definovat více sad vztahů.

Zde je také nutné vzít v úvahu členskou třídu subjektů. Každý zaměstnanec musí pracovat v nějakém oddělení, ale ne každé oddělení (například nově vzniklé) musí zahrnovat alespoň jednoho zaměstnance. Proto má entita „ODDĚLENÍ“ povinnou třídu a entita „ZAMĚSTNANEC“ má volitelnou třídu členství. Mohutnost vztahů binárních stupňů n budeme to označovat takto:

mnoho k jednomu ( n: 1). Tento vztah je podobný mapování 1:n. Předpokládejme, že podnik, o kterém uvažujeme, zakládá svou činnost na základě smluv uzavřených se zákazníky. Tato skutečnost se odráží v modelu entita-vztah využívající spojení SMLOUVA-ZÁKAZNÍK, které kombinuje entity SMLOUVA(ČÍSLO, DATUM_SPLATNOSTI, ČÁSTKA) a ZÁKAZNÍK(JMÉNO, ADRESA). Vzhledem k tomu, že s jedním zákazníkem lze uzavřít více smluv, bude mít vztah SMLOUVA – ZÁKAZNÍK mezi těmito subjekty stupeň n: 1.

V tomto případě má ze zcela zřejmých důvodů (každá smlouva je uzavřena s konkrétním zákazníkem a každý zákazník má alespoň jednu smlouvu, jinak by tomu tak nebylo) každý subjekt třídu povinného členství.

mnoho pro mnoho ( n: n). V tomto případě může být každá z přidružených entit reprezentována libovolným počtem instancí. Necháme podnik, o kterém uvažujeme, vytvořit a pracovní skupina, která zahrnuje zaměstnance z různých oddělení. Vzhledem k tomu, že každý zaměstnanec může být členem několika (včetně žádné) pracovních skupin a každá skupina musí zahrnovat alespoň jednoho zaměstnance, má vztah mezi subjekty EMPLOYEE a WORK_GROUP určitou míru n: n.

Je-li existence entity X závisí na existenci entity y, Že X volal závislá entita(někdy entita X nazývané "slabé" a "esence" y - silný). Jako příklad zvažte vztah mezi dříve popsanými entitami WORKING_GROUP a CONTRACT. Pracovní skupina vzniká až po podpisu smlouvy se zákazníkem a zaniká dokončením smlouvy. Entita WORKING_GROUP je tedy závislá na entitě CONTRACT. Závislou entitu označíme dvojitým obdélníkem a její spojení se silnou entitou čárou se šipkou:

Všimněte si, že mohutnost spojení pro silnou entitu bude vždy (1,1). Třída členství a stupeň vztahu pro závislou entitu může být cokoliv. Předpokládejme například, že podnik, o kterém uvažujeme, využívá několik bankovních úvěrů, které jsou reprezentovány množinou entit KREDIT(ČÍSLO_SMLOUVY, ČÁSTKA, SPLATNOST_TERM, BANKA). Za každou půjčku je třeba zaplatit úroky a splátky. Tuto skutečnost představuje množina entit PLATBA(DATUM, ČÁSTKA) a množina vztahů „provádí“. V případě, že dojde ke zrušení plánované výpůjčky, musí být informace o ní vymazána z databáze. V souladu s tím musí být vymazány všechny informace o plánovaných platbách této půjčky. Subjekt PLATBY tedy závisí na subjektu KREDIT.

2.2.Diagram vztahů entit.

Velmi důležitou vlastností modelu entita-vztah je, že jej lze znázornit jako grafický diagram. To značně usnadňuje analýzu předmětné oblasti. Existuje několik možností pro pojmenování prvků diagramu vztahů mezi entitami, z nichž každá má své vlastní pozitivní vlastnosti. Krátká recenze Některé z těchto zápisů budou provedeny v části 2.4. Zde použijeme jakýsi hybrid zápisů Chena (označení entit, spojení a atributů) a Martina (označení stupňů a mohutností spojení). Tabulka 2.1 uvádí zde použitý zápis.

Tabulka 2.1

Atributy s entitami a entity se vztahy jsou spojeny přímkami. V tomto případě se k označení mohutnosti spojení používají zápisy uvedené v předchozím odstavci.

V procesu vytváření diagramu existuje několik zřejmých fází:

Identifikace zájmových entit a vztahů.
Identifikace sémantických informací v sadách odkazů (například zda je určitá sada odkazů mapováním 1:n).
Stanovení mohutnosti spojů.
Definice atributů a množin jejich hodnot (domény).
Uspořádání dat ve formě vztahů entita-vztah.

Jako příklad sestavme schéma ukazující datové připojení pro subsystém personálního účetnictví podniku.

Zdůrazněme entity a souvislosti, které nás zajímají:

Podnik se v prvé řadě skládá z oddělení, ve kterých pracují zaměstnanci. Mzda každého zaměstnance závisí na zastávané pozici: inženýr, vedoucí inženýr, účetní, uklízeč atd. Předpokládejme dále, že naše společnost umožňuje více pozic, tzn. Každý zaměstnanec může mít více než jednu pozici (a pracovat ve více než jednom oddělení) a může být na částečný úvazek. Současně může stejnou pozici zastávat několik zaměstnanců současně. V důsledku této úvahy musíme zavést množiny entit

DEPARTMENT(DEPARTMENT_NAME),
ZAMĚSTNANCE (PERSONNEL_NUMBER, JMÉNO),
POSITION(POSITION_NAME, SALARY),

a sadu připojení WORKS_B s atributem nabídka mezi nimi. Atribut nabídka může nabývat hodnot z intervalu ]0,1] (větší než nula, ale menší nebo rovný jedné), určuje, jakou část služebního platu daný zaměstnanec pobírá.

Jak je uvedeno výše, každý n-ary sada spojení může být nahrazena několika binárními sadami. Nyní je vhodná chvíle zhodnotit výhody každého z těchto způsobů reprezentace vztahů.

Zde zobrazené tréninkové spojení s sebou nese jistě více úplné informace o předmětné oblasti. Ve skutečnosti to jasně odráží skutečnost, že plat zaměstnance závisí na jeho pozici, oddělení, kde pracuje, a sazbě. V tomto případě však existují určité problémy s určením stupně připojení. I když, jak bylo řečeno, každý zaměstnanec může zastávat více pozic a v personálu každého oddělení jsou volná místa s různými pozicemi, přesto je členská třída entity POZICE na výše uvedeném obrázku nastavena na (1,1). To se vysvětluje skutečností, že POZICE ve skutečnosti není spojena s entitami ZAMĚSTNANEC a ODDĚLENÍ, ale se vztahem mezi nimi. Navrhujeme tuto skutečnost označit tak, jak je znázorněno na následujícím schématu:

Zde jsou entity vztahů ZAMĚSTNAN, ODDĚLENÍ a PRÁCE_B agregovány do nové abstraktní entity, která je spojena s entitou POSITION pomocí vztahu stupně n:1.

Zkusme zobrazit asociace zaměstnanců, oddělení a pozic pomocí binárních spojení.

V tomto případě je pro adekvátní popis sémantiky předmětové oblasti nutné zavést další entitu STAFF_UNIT, která vlastně nahrazuje vztah WORK_B v abstraktní entitě a má tedy atribut nabídka.

Přenést z n-ární spojení prostřednictvím agregace entit do množiny binárních vztahů lze považovat za po sobě jdoucí fáze jednoho procesu, což vede k jednoznačnému generování relačního datového modelu. Při vytváření diagramu" entita-vztah„K prezentaci dat můžete použít kterýkoli z těchto tří způsobů.

Uveďte několik objektů popsaných v předchozím odstavci, které budou užitečné při modelování dat daného podniku. Odpovídají jim následující entity:

CUSTOMER(CUSTOMER_NAME,ADDRESS)
CONTRACT(NUMBER, START_DATE, END_DATE, AMOUNT)
PRACOVNÍ SKUPINA (PERCENTAGE_REWARD)

Atribut "procento odměny" odráží část hodnoty zakázky, která je určena k vyplacení členům příslušné pracovní skupiny. Význam zbývajících atributů je jasný bez dalšího vysvětlení. Vztahy mezi uvedenými subjekty jsou rovněž popsány v předchozím odstavci.
Jeden z členů pracovní skupiny je zpravidla vedoucím ve vztahu k ostatním zaměstnancům zařazeným do jejího složení. Abychom tuto skutečnost reflektovali, musíme zavést spojení „průvodci“ s mohutností 1,1:0, n mezi entitami EMPLOYEE a WORK_GROUP (zaměstnanec může vést libovolný počet pracovních skupin, ale každá pracovní skupina má jednoho a pouze jednoho vedoucího).

Podívejme se nyní blíže na informační objekt „zákazník“. V praxi se velmi často stává nutností rozlišovat státní příslušnost právnických osob, se kterými podnik vstupuje do smluvních vztahů. Je to dáno tím, že u zahraničních společností je nutné uchovávat např. informace o měně, ve které jsou platby prováděny, v jakém jazyce byla smlouva podepsána atp. Na druhé straně, pro domácí firmy je nutné mít informace o jejich formě vlastnictví (soukromé nebo veřejné), protože na tom může záviset postup zdanění prostředků přijatých za provedení práce na základě smlouvy.
Dostáváme se tedy k závěru, že je nutné uvést v úvahu ještě dvě disjunktní množiny ZAHRANIČNÍ_PODNIK(MĚNA, JAZYK) a DOMÁCÍ_PODNIK (FORMA VLASTNICTVÍ), jejichž spojení tvoří kompletní množinu ZÁKAZNÍK. Asociace mezi těmito objekty se nazývá dědický vztah nebo hierarchické spojení, protože entity FOREIGN_ENTERPRISE a DOMESTIC_ENTERPRISE dědí atributy entity CUSTOMER(CUSTOMER_NAME, ADDRESS). Abyste mohli určit, do které podmnožiny patří konkrétní entita ze sady ZÁKAZNÍK (a podle toho, do které sady atributů má), musíte zadat atribut tzv. „národnost“. diskriminační. Tento typ připojení se navrhuje zobrazit na schématu následovně:

Shrneme-li všechny výše uvedené úvahy, dostaneme diagram „vztahu entit“ znázorněný na následujícím obrázku.

Na konci této části je čtenáři nabídnuto několik otázek k samostatnému studiu:

Jak se změní diagram entita-vztah, pokud bude procento odměny pro všechny smlouvy stejné?
Co se v diagramu změní, pokud bude zakázáno více pozic, tzn. bude mít každý zaměstnanec právo obsadit pouze jednu pozici s sazbou 1?

Logický model Data (entity) jsou nezávislou logickou reprezentací dat.

Fyzikální model(Tabulární) data obsahují definice všech implementovaných objektů v konkrétní databázi pro konkrétní DBMS.

Modely jsou základní kámen design. Inženýři musí před uvedením do výroby postavit model vozu a vypracovat všechny detaily. Stejným způsobem systémoví inženýři nejprve vyvinou modely ke studiu obchodní logiky a prohloubí pochopení struktury databáze.

V minulé přednášce jsme se seznámili s metodikami IDEF0 a DFD, které nám umožňují popsat podnikové procesy probíhající v informačním systému. V modelu DFD jsme uvažovali prvek – datové úložiště, které zobrazuje typy informací, se kterými systém pracuje. Tato metodika však není určena k popisu struktury uložených informací. Vhodnější jsou k tomu různé Entity Relationship diagramy (entitní diagramy), jejichž účelem je popsat strukturu uložených dat a vztahy mezi nimi. Byly vyvinuty metody, které umožňují převést taková data do sady příkazů, které vytvoří potřebné úložiště (tabulky) uvnitř databáze informačního systému.

ER modelování

V informačních systémech jsou data rozdělena do samostatných kategorií nebo entit. Koneckonců si pamatujeme, že databáze je soubor strukturovaných dat. Různé typy dat jsou uloženy odděleně. Úkolem ER modelu je ukázat, jaké typy informací jsou v systému uloženy, jaká je jejich struktura a jak jsou vzájemně propojeny. ER model je postaven na základě podnikové analýzy (konstruovaný DF diagram). V tomto případě se zpočátku každý obchod v diagramu DF stane entitou na diagramu ER. Při další analýze je lze rozdělit na jednotlivé části. Stojí za zmínku, že modely ER jsou odolnější vůči změnám v obchodní struktuře než DF diagramy. Obchodní procesy se mohou změnit, ale informace potřebné k jejich implementaci často zůstávají nezměněny.

Hlavní výhody modelů ER:

Přesný a srozumitelný formát pro dokumentaci struktury informací.
Umožňuje zadat požadavky na data a vztahy mezi nimi.
Umožňuje jasně ukázat strukturu úložiště pro usnadnění návrhu databáze.
Existují metody mapování ER modelů na databázové tabulky a naopak.
Pokládá základy pro integraci s jinými aplikacemi.

Hlavní typy objektů v ER diagramu:

Entita je typ objektů, informace o kterých budou uloženy v databázi. Například: oddělení, zaměstnanci, zboží, faktury.
Atribut – prvky, které tvoří entity. Například u entity „produkty“ mohou být atributy „název“, „popis“, „množství“, „cena“ a další v závislosti na potřebách informačního systému. V závislosti na zápisu ER diagramu u atributu kromě jeho názvu uveďte typ a povinné vyplnění. Snímek ukazuje ER diagram v notaci „Information Engineering“, podle kterého se u atributu uvádí název, typ a zda se jedná o externí a/nebo primární volání.
Vztahy ukazují spojení mezi entitami. Například zaměstnanec pracuje v oddělení, kde „oddělení“ a „oddělení“ jsou entity.

Entita – množina objektů reálný svět, z nichž každá má následující vlastnosti:

Unikátní (lze nějakým způsobem oddělit od všech ostatních)
Hraje roli v modelovaném systému
Může být popsána jednou nebo více informacemi (atribut)

Příklad: lidé, zaměstnanci, události, objednávky, prodej, zákazníci, dodavatelé

Atribut popisuje některé vlastnosti entity. Entita může mít mnoho atributů, ale vybírají se pouze ty, které jsou důležité pro systém. Atributy se dělí na klíčové (Entity Keys) a popisné (Entity Descriptors). Klíčové atributy musí jednoznačně identifikovat instance entity. Pro každý atribut musí být uvedena doména (typ, předmětová oblast).

Snímek ukazuje, jak se entity a atributy zapisují v různých zápisech modelu ER. Ve všech zápisech je entita objekt obdélníkového tvaru, v jehož horní části je uveden název entity. Atributy jsou uvedeny pod názvem entity.

Podívejme se blíže na to, jaké jsou klíčové atributy. To je důležité pro pochopení typů vztahů mezi entitami.

Základní pojmy

Relační model lze v případě potřeby popsat matematickým jazykem, tedy tím nejpřesnějším, který člověk vymyslel. Níže jsou volné definice některých konceptů relačního modelu.

"Datový typ" (typ, doména - doména) - sada přípustných hodnot ("doména") a operací. Všechny typy mají operace porovnání a přiřazení. Množství není zakázáno mít strukturu například předmětu.
"Relace" (relace) - množina atributů: jedinečná jména s upřesněním datového typu; plus sada „sad hodnot“ („série“) odpovídajících atributům. Hodnoty v sadách mohou být reprezentovány pouze jednotlivými hodnotami typů odpovídajících atributům, to znamená, že mohou být skaláry („1. normální forma“).
„Klíč“ (klíč) je skupina atributů, jejichž hodnoty ve všech množinách jsou ve vztahu různé, ale žádná podskupina těchto atributů již takovou vlastnost nemá (vlastnost klíče „minimalita“). Skupina se může skládat zejména z jediného atributu. Klíč ve vztahu musí být vždy přítomen, a pokud jich je několik, jeden z nich musí být označen jako „primární“.
„Cizí klíč“ je skupina atributů, jejichž hodnoty v každé sadě hodnot vztahu se musí shodovat s hodnotami klíče případně jiného vztahu. Cizí klíče v relaci jsou volitelné a jsou deklarovány podle potřeb modelování.
"Operace" (operace) - nastaveno obecné akce nad vztahy, které opět vyúsťují ve vztahy („uzavřenost operací“). Slouží k získání nových vztahů pro potřeby následného modelování nebo při extrakci potřebných dat z databáze. Seznam operací lze definovat různými způsoby; v prvních návrzích modelu bylo dáno osm operací (projekce, připojení, výběr atd.), již ne minimální sada, jako kompromis mezi nedostatkem redundance a snadností použití.
" Relační databáze" (relační databáze) - množina vztahů.

„Datový typ“ se někdy nazývá „doména“, ale někdy „doména“ odkazuje pouze na „definiční doménu“ hodnot. „Soubor množství“ (n-tice) se v ruštině jinak nazývá „n-tice“ nebo „n-coy“.

Pro usnadnění jsou vztahy často znázorněny ve formě tabulek, i když taková reprezentace je nelegitimní (na rozdíl od tabulky není ve vztahu definováno ani pořadí atributů, ani pořadí sad hodnot). V SQL, na kterém je Oracle DBMS postaven, je pojem „vztah“ jako modelovací nástroj nahrazen „tabulkou“. Jinou reprezentací relačních dat může být hyperkrychle a někdy je také vhodné se k ní uchýlit při uvažování o existující databázi.

Pokud opustíme definující sledovací slovo „relační“, pak výraz „relační databáze“ lze přeložit jako „databáze vztahů“ (přesněji „databáze postavená přes vztahy"; vztahy jako nástroj, nikoli jako objekt modelování: jinak by původní termín byla relační databáze). Stejně tak lze pojem „relační model" přeložit jako „model vztahu", tedy „a systém pojmů pro konstrukci modelu předmětné oblasti ve formě množinových vztahů." Z řady důvodů, včetně historických a lingvistických, k tomu v té době nedošlo.

Všechny datové vztahy jsou popsány očividně A pouze hodnoty v množinách (to se může u jiných přístupů modelování lišit). Neexistují žádné „implicitní“ závislosti (včetně na úrovni programové logiky), kromě vztahů formulovaných proměnnými. Relační přístup rozlišuje mezi popisem dat a programovou logikou doprovázející aplikaci (na rozdíl např. od objektového přístupu).

Výše uvedený pohled na relační databázi (soubor vztahů a operací) je typický pro relační algebra. To není jediný úhel pohledu. Každou množinu hodnot v relační proměnné lze chápat jako pravdivé tvrzení („predikát“): existuje takový a takový zaměstnanec s takovými a takovými vlastnostmi; takové a takové oddělení a tak dále. Relační databáze tedy v každém okamžiku představuje soubor pravdivých tvrzení o předmětné oblasti, formulovaných prostřednictvím vztahů. V podstatě sada prohlášení v vztahové proměnné a tvoří doménový model reprezentovaný databází. Tento pohled na relační databázi je typický pro vztahový kalkul. Oba pohledy na relační model byly dobře prostudovány a byla prokázána jejich výrazová ekvivalence.

Pro výrazy uvedené na předchozím snímku existují neformální ekvivalenty, které usnadňují pochopení a zapamatování jejich významu:

Vztah → Tabulka
N-tice → Řetězec, záznam
Mohutnost → Počet řádků
Atribut → Sloupec, pole
Stupeň → Počet sloupců
Primární klíč → Identifikátor
Doména → Rozsah přijatelných hodnot

Klíčová pole

Některé atributy vztahu jsou klíče nebo klíče. Existuje několik typů klíčů:

Jednoduchý klíč se skládá z jednoho atributu, složený klíč se skládá z několika.
Potenciální klíč- atribut nebo sada atributů, které mohou identifikovat každou z n-tic vztahu. Například ve vztahu k pasovému úřadu („Číslo pasu“) a („Celé jméno“ a „Datum narození“) jsou potenciální klíče, které vám umožňují jednoznačně identifikovat každou osobu.
Každý vztah může mít pouze jeden primární klíč – atribut nebo sadu hodnot atributů, jejichž hodnoty jednoznačně identifikují každý záznam. Pokud má několik sad atributů takové vlastnosti, pak je jedna z nich vybrána jako primární a všechny ostatní jsou vybrány jako alternativní.
Cizí klíč - obchody význam primární klíč jiného vztahu. Ke komunikaci mezi vztahy se používají cizí klíče.

Primární klíč

Každý relační vztah má pouze 1 primární klíč, všechny ostatní jsou alternativní klíče.
Hodnota všech atributů primárního klíče Ne Možná nedefinováno. Například vztah ukládá informace o obyvatelích města. Primární klíč je složený (JMÉNO, PŘÍJMENÍ, datum narození). Informační systém byl nainstalován na Islandu, kde nepoužívají příjmení, což znamená, že atribut „last name“ bude pro většinu n-tic prázdný. Navzdory tomu bude složený primární klíč nadále jednoznačně identifikovat každou z n-tic. Je však nepřijatelné, aby hodnoty všech atributů primárního klíče byly prázdné současně.
Hodnota primárního klíče neovlivňuje umístění n-tic v tabulkovém zobrazení vztahu. I když je hodnotou primárního klíče číslo (například 1,2,3...), obecně to nezaručuje, že n-tice v databázi budou uloženy ve stejném pořadí a že budou na výstupu ve stejném pořadí. V „obecném případě“ to znamená, že někdy lze vzhledem ke specifikům konkrétní DBMS ukládat řádky v pořadí podle primárního klíče, ale to je spíše výjimka. Při výstupu výsledků dotazu musíme explicitně určit pořadí, ve kterém by měly být řádky na výstupu, pokud je toto pořadí důležité. Výsledky dotazu „dej mi prvních 5 lidí“ jsou nepředvídatelné, pokud nespecifikujeme, podle jakého kritéria by měli být „první“.
Primární klíč neovlivňuje přístup k atributům n-tice. Například ve vztahu k „pasovému úřadu“ je registrační adresa osoby uložena spolu s celým jménem a datem narození. Můžeme požádat databázi, aby extrahovala všechny adresy, aniž bychom znali celé jméno a datum narození.

Externí klíč

Cizí klíč se používá k navázání spojení mezi vztahy. Vezměme si například dva vztahy „Vlastníci“ (primární klíč „číslo pasu“) a „Nemovitost“. Abychom zjistili, kdo vlastní jednotlivé nemovitosti, spojíme tyto vztahy hodnotou atributu „číslo pasu“. Na rozdíl od primárního klíče lze hodnotu cizího klíče nedefinovat (4. řádek na snímku) – pokud neznáme vlastníka nemovitosti, neuvádíme jej. Na rozdíl od primárního klíče se hodnota cizího klíče může opakovat (zásoby 1.3 na snímku) - jeden vlastník může mít více nemovitostí. Skutečnost, že atribut „číslo pasu“ ve vztahu „Nemovitost“ je cizím klíčem k primárnímu klíči vztahu „Vlastník“, však zaručuje, že hodnotou atributu „číslo pastora“ mohou být pouze hodnoty od primární klíč. Nemůžeme zadat číslo fary osoby jako hodnotu atributu, která ještě neexistuje ve vztahu Owner (řádek 5).

Nastavením cizího klíče můžete explicitně nastavit chování DBMS, pokud změníte hodnotu primárního klíče nebo odstraníte n-tici. Platí však pravidlo „cizí klíč ukládá pouze hodnoty, které jsou v primárním klíči resp nedefinovaná hodnota(NULA)".

Cizí klíč mezi vztahy se obvykle zadává při návrhu databáze. Lze jej však kdykoli odebrat nebo znovu nainstalovat, pokud přidání tohoto omezení není v konfliktu s vlastnostmi cizího klíče. Odebrání/instalace cizích klíčů se obvykle provádí při vkládání velmi velkého množství dat, aby se tento proces urychlil - DBMS nemůže ukládat nekonzistentní (nesprávná, chybná) data, takže při vkládání každého řádku kontroluje každé omezení.

Modely ER: připojení

V modelech ER jsou cizí klíče zobrazeny jako vztahy.

Každé spojení je charakterizováno 4 vlastnostmi – silou, silou, stupněm a účastí entity na spojení.

Podívejme se na tyto vlastnosti.

Účast entity ve vztahu

Označeno na spoji příčnou čarou nebo kroužkem.

Příčná čára znamená povinné (povinné) účast subjektu ve spojení a kruh - volitelný (volitelný).

V případě povinné účasti subjektu ve spojení se sloveso „ musí". Pokud se entita nezbytně nezúčastňuje spojení, sloveso " Možná".

V oddělení Možná zaměstnávají několik zaměstnanců. Zaměstnanec musí pracovat v jednom z oddělení.

Stupeň připojení ( vztah stupeň) udává počet přidružených entit. Binární komunikace ( binární vztah) popisuje spojení dvou entit. Ternární spojení (trojice vztah) nastane, když jsou spojeny tři entity. Unární komunikace (unární vztah) popisuje asociace v rámci jedné entity.

Nejběžnější jsou binární spojení – spojují dvě různé entity („Oddělení“ – „Zaměstnanec“, „Zakázka“ – „Zboží“, „Kurz“ – „Přednášky“, „Skupina“ – „Studenti“). Méně častá, ale přesto často používaná jsou unární spojení. S jejich pomocí obvykle nastaví vnořovací vztah na objekty stejného typu (relace „Parts“ - můžeme označit, které části je tato konkrétní část součástí, vztah „Employees“ - můžeme označit, který zaměstnanec je šéf pro tento).

Síla propojení ukazuje, kolik instancí jedné entity je připojeno k instancím jiné entity.

Výkon může být:

jedna ku jedné(1:1) - ve skupině studentů je jeden ředitel;
jeden k mnoha(1:N) - mnoho zaměstnanců pracuje v jednom oddělení;
mnoho-k-mnoho(M:N) - jeden kupující koupil mnoho zboží, mnoho kupujících kupovalo zboží.

Síla spojení: silné spojení (Identifying Relationship)

Podřízená entita nemůže existovat bez nadřazené entity. (Bez otázky neexistuje odpověď; v košíku uživatele není žádný produkt, pokud košík samotný neexistuje)

V tomto případě primární klíč migruje z nadřazené entity do podřízené entity, kde se stane součástí primárního klíče.

V diagramu je silný vztah reprezentován nepřerušovanou čarou mezi entitami.

Síla vztahu: Neidentifikující vztah

Nadřazené a podřízené entity spolu souvisí, ale podřízenou entitu lze vytvořit jako první. (Náklad patří k objednávce, ale náklad může být ve skladu před vytvořením objednávky).

Primární klíč migruje z nadřazené entity do podřízené entity a není součástí primárního klíče (prostě se stává cizím klíčem).

V diagramu je silný vztah znázorněn tečkovanou čarou mezi entitami.

Rekurzivní vazba (unární vazba)

Nejčastěji se používá k vytváření hierarchií.

Dodavatel MŮŽE spolupracovat s NULOU nebo VÍCE zákazníky (id_Customer).

Zákazník MUSÍ spolupracovat s jedním dodavatelem (id_Sup).

Ale dodavatel a zákazník – ať už jde o společnost nebo organizaci – jsou objekty stejného typu, a proto jsou uloženy ve stejném vztahu.

Komunikace mnoho s mnoha.

Příklad: Dodavatelé mohou dodávat mnoho typů produktů. Různí dodavatelé mohou dodávat stejné druhy zboží.

Vztahy many-to-many jsou platné z hlediska ER modelu, ale nemohou být přímo reflektovány z hlediska relační algebry.

Nejednoznačnost vztahu je vyřešena zavedením přechodných entit, jak je znázorněno na snímku.

ER modely a realita

Při bližším prozkoumání vztahu jedna ku jedné se téměř vždy ukáže, že A a B jsou vlastně různé podmnožiny téže věci nebo různé pohledy na ni, jen mají různá jména a různě popsané vztahy a atributy.

Představme si, že A je dodavatel, B je produkt.

Povinné-povinné. Pro příklad zobrazený na snímku tento vztah znamená, že každý dodavatel musí dodávat pouze jeden unikátní sada zboží (faktura). Z teoretického hlediska je zde vše v pořádku. V praxi je to nepřijatelné: nikdo nebude hledat nového dodavatele, pokud vámi ověřený dodavatel může poskytnout několik produktových řad. A nyní o emocích, které operátor zažije při pokusu o zadání údajů o novém dodavateli. Nebude moci zadávat data do žádné z tabulek. Takže všechna ta zavazadla neslušného jazyka bude namířena na vás.

Nepovinné-povinné. Příklad zapojení je na snímku. Jak vidíme, s operátorem je nyní vše v pořádku: může zadávat data. Podnik má opět problém: musí hledat nového dodavatele, i když vámi ověřený dodavatel může poskytnout několik produktových řad. Potřebuje podnikání problémy? Ne. Musí fungovat. Jak uspokojit podnikání? Odpověď je jednoduchá. Při návrhu databáze je třeba myslet na normalizaci. Pokud je Dodavatel entita, použijte vztahy volitelné-povinné (povinné-nepovinné) nebo nepovinně-volitelné. I když nejčastěji jsou osobní vztahy chybou.

Volitelné-volitelné. Jak vidíme, operátorovi se opět daří, ale byznys má opět problém. Pojďme si to shrnout pro osobní komunikaci. Pokud se subjekty účastní připojení jako: - povinné-povinné, pak takové připojení nemá právo na život; - volitelné-povinné (povinné-nepovinné) nebo nepovinné-nepovinné, pak je podpora podnikání problematická.

Vztah povinného a povinného jedna k mnoha je poměrně silný konstrukt, který implikuje, že výskyt entity B nelze vytvořit, aniž by současně nebyl vytvořen alespoň jeden výskyt entity A, která je s ní spojena. Nejčastěji se jedná o nesprávný vztah.

Povinně volitelný vztah typu one-to-man je nejběžnější formou vztahu. Předpokládá, že každý výskyt entity A může existovat pouze v kontextu jednoho (a pouze jednoho) výskytu entity B. Výskyty B mohou naopak existovat buď s výskyty A, nebo bez nich.

Vztah one-to-many optional-optional – A i B mohou existovat bez vztahu mezi nimi.

Pokud jde o předchozí snímek, lze tato schémata ilustrovat pomocí následujících příkladů.

Vztahy jeden k mnoha. Tyto vztahy znamenají, že jeden záznam v jedné tabulce může logicky souviset s více záznamy v jiné tabulce.

Povinné-povinné. Pro příklad zobrazený na snímku tento vztah znamená, že každý dodavatel (A) musí dodat jednu nebo více sad zboží (B). Z teoretického hlediska je zde vše v pořádku. V praxi však operátor nebude moci zadávat údaje do žádné z tabulek, protože záznamy musí být zároveň zadejte do obou tabulek.

Nepovinné-povinné. V tomto případě je pro operátora vše v pořádku: může zadávat data, ale byznys může mít problémy. Jde o to, že volitelný-povinný vztah předpokládá, že dodavatel (A) musí dodat jednu nebo více sad zboží (B), zatímco B Možná patří dodavateli. Jinými slovy, zboží může existovat bez dodavatele, zatímco dodavatel má zboží. Tito. je možné nekontrolované obchodní jednání: kdo dodal zboží? Koho se mám zeptat? Potřebuje podnikání problémy? Ne. Musí to mít zisk. V tomto případě je lepší použít povinné-volitelné: dodavatel může dodat jednu nebo více sad zboží, přičemž zboží musí patřit dodavateli. Jinými slovy, produkt má dodavatele a data o dodavatelích, kteří produkt jednou dodali, budou uložena. A ovce jsou v bezpečí a vlci jsou krmení - operátor může zadat data a obchodník to má vědět.

Volitelné-volitelné. Jak vidíme, s operátorem je opět vše v pořádku, ale obchod má problém – nedostatek kontroly: Produkt může existovat bez dodavatele a dodavatel bez produktu.
Pojďme si to shrnout pro komunikaci typu one-to-many. Pokud se subjekty účastní vztahu jako: - povinný-povinný, pak takový vztah nemá právo na život, protože není možné zadávat záznamy současně do obou tabulek; - volitelné-volitelné, pak je podpora podnikání problematická.

Vztahy many-to-many jsou v ER diagramech povoleny, ale při převodu na tabulkové zobrazení je vztah nahrazen prostřední entitou.

Mnoho k mnoha povinné-povinné – tato konstrukce se často vyskytuje na začátku fáze analýzy a znamená vztah – buď není plně pochopen a vyžaduje další řešení, nebo odráží jednoduchý kolektivní vztah – obousměrný seznam.

Many-to-many povinné-volitelné – zřídka používané. Taková spojení jsou vždy předmětem dalších podrobností.

Rekurzivní spojení. Tyto vztahy naznačují, že položky tabulky spolu mohou logicky souviset.

Volitelně-volitelné one-to-one. Pro příklad zobrazený na snímku tento vztah znamená, že kterýkoli muž (žena) může být ženatý s jednou ženou (mužem). Toto spojení je vhodné pro sledování historie těch, kteří se vdávají: poprvé, znovu, ... Jinými slovy, alternativní typ vztahu.

Volitelně-volitelné one-to-many. Příklad zapojení je na snímku. Jedná se o klasickou hierarchii (stromovou strukturu). Vztah zobrazený na snímku lze interpretovat například takto: každý zaměstnanec se může hlásit pouze jednomu vedoucímu, zatímco manažer může řídit jednoho nebo více zaměstnanců.

Volitelně-volitelné M:M Příklad komunikace je uveden na snímku 3. Jedná se o síťovou strukturu.

Kontrolní seznam otázek entit

Odráží název entity podstatu? tohoto objektu?
Existuje nějaké překrývání s jinými subjekty?
Existují alespoň dva atributy?
Celkem neexistuje více než osm atributů?
Existují nějaká synonyma/homonyma pro tuto entitu?
Je entita plně definována?
Existuje jedinečný identifikátor?
Existuje alespoň jedno spojení?
Existuje alespoň jedna funkce pro vytváření, vyhledávání, úpravy, mazání, archivování a používání hodnoty entity?
Existuje historie změn?
Jsou dodrženy zásady normalizace dat?
Existuje stejná entita v jiném aplikačním systému, možná pod jiným názvem?
Nemá také podstata obecný význam?
Je míra zobecnění v něm obsažená dostatečná?

Kontrolní seznam atributů:

Je název atributu podstatné jméno v jednotném čísle, které odráží podstatu vlastnosti označené atributem?
Nezahrnuje název atributu název entity (neměl by)?
Má atribut vždy pouze jednu hodnotu?
Existují nějaké duplicitní hodnoty (nebo skupiny)?
Jsou popsány formát, délka, přijatelné hodnoty, algoritmus získávání atd.?
Mohl by tento atribut být chybějící entitou, která by byla užitečná pro jiný aplikační systém (existující nebo navrhovaný)?
Může to být zmeškané spojení?
Existuje někde odkaz na atribut jako „funkci návrhu“, která by měla zmizet při přechodu na úroveň aplikace?
Je potřeba historie změn?
Závisí její význam pouze na této entitě?
Je-li hodnota atributu povinná, je vždy známa?
Je potřeba pro tento a podobné atributy vytvořit doménu?
Závisí jeho hodnota pouze na nějaké části jedinečného identifikátoru?
Závisí jeho hodnota na hodnotách některých atributů, které nejsou zahrnuty v jedinečném identifikátoru?

Chcete-li vytvořit databázi, jejíž struktura nezávisí na konkrétních informačních potřebách a umožňuje splnit jakékoli požadavky uživatelů, použijte diagram infologické modely"entita-vztah" (ER - diagram).

Nejčastěji se formalizace představ o předmětné oblasti provádí v rámci modelu „entity-relationship“ („objekty-vztahy“). V této fázi návrhu se používá metoda „esence-relationship“, která se také nazývá metoda „ER-diagram“ („Essence“ - entita, „Relation“ - spojení). Tato metoda je založena na použití diagramů nazývaných diagramy ER-instance a diagramy typu ER.

ER – diagram „entity-relationship“ je soubor mnoha objektů a jejich charakteristik a také vztahů mezi nimi, nezbytných k identifikaci dat, která jsou následně využívána funkcemi navrhovaného systému.

Hlavní koncepty metody entitních vztahů jsou následující:

Podstata;

Atribut entity;

Klíč entity;

Vztah mezi subjekty;

Stupeň připojení;

Třída členství instancí entity;

diagramy instancí ER;

Diagramy typu ER.

Pod informační objekt rozumí se určitá entita fragmentu reality např.: organizace, dokument, zaměstnanec, místo, událost apod. Entita je objekt, o kterém jsou informace uloženy v databázi. Instance entit se od sebe liší a jsou jednoznačně identifikovány. Názvy entit jsou podstatná jména. Každý typ objektu je identifikován svou vlastní sadou atributů. V tomto kurzu jsou subjekty: zaměstnanec, pozice, vzdělání, formy pracovní participace, fakulty, katedry a témata.

Atribut (z lat. attribuo - atribut - vlastnost nebo věc neoddělitelná od předmětu) je logicky nedělitelný prvek informační struktury, vyznačující se množstvím atomárních hodnot. Tento koncept je podobný konceptu „atributu“ ve vztahu. Instance objektu je charakterizována kolekcí konkrétní hodnoty atributy daného typu objektu. Jeden nebo některá skupina atributů objektu tohoto typu může hrát roli klíčového atributu (klíč entity). V tomto projektu kurzu jsou výše uvedené entity charakterizovány atributy, jako jsou: kód_oddělení, název_oddělení, kód_oddělení, jméno_zaměstnance atd.

Klíč entity je atribut nebo sada atributů, které identifikují instanci entity (například kód_úlohy).

Vztah mezi dvěma nebo více entitami je závislost mezi atributy těchto entit. Označuje se slovesem. Kromě toho existují dva typy připojení:

Hierarchický;

Jednoúrovňové.

Pro zvýšení přehlednosti a snadnosti návrhu se používají grafické prostředky reprezentující entitu, instance entity a vztahy mezi nimi. ER diagram je uveden v příloze A.

Klasifikace spojení

V reálných databázích jsou informace umístěny v několika tabulkách. Tabulky jsou propojeny informační sémantikou. V relační DBMS K označení vztahů mezi tabulkami se provádí operace jejich propojení. To zvyšuje spolehlivost informací uložených v databázi, protože DBMS kontroluje integritu dat vložených do databáze v souladu se zavedenými spojeními.

Navázání spojení usnadňuje přístup k datům při provádění operací: vyhledávání, prohlížení, úpravy, načítání a příprava sestavy, protože je poskytován přístup do všech polí souvisejících tabulek.

Mezi stoly lze nainstalovat následující:

Binární spojení;

Ternární spojení;

N-ární vazby.

Při propojení dvou tabulek se rozlišuje primární a podřízená tabulka (nadřazená a podřízená). Logické propojení tabulek se provádí pomocí spojovacího klíče. Pole hlavní tabulky mohou být jednoduchá nebo klíčová. Nejčastěji klíčová jsou odkazová pole doplňkové tabulky. V závislosti na tom, jak jsou definována pole připojení v hlavní a doplňkové tabulce (jak klíčová pole souvisí s poli připojení), se vytvoří typy připojení:

1:1 (jeden ku jednomu);

1:M (jeden k mnoha);

M:1 (mnoho ku jedné);

M:M (mnoho k mnoha).

Vztah 1:1 se vytvoří, pokud jsou klíčová všechna pole vztahu mezi nadřazenou a podřízenou tabulkou. Vzhledem k tomu, že hodnoty v klíčová pole dvě tabulky se neopakují, je zajištěna vzájemná korespondence záznamů z těchto tabulek. Samotné tabulky se zde ve skutečnosti stávají rovnocennými.

Vztah 1:M nastane, když jeden záznam v nadřazené tabulce odpovídá několika záznamům v podřízené tabulce.

Vztah M:1 nastane, když se jeden nebo několik záznamů hlavní tabulky shoduje s jedním záznamem další tabulky.

Vztah M:M nastává v případech, kdy několik záznamů hlavní tabulky odpovídá několika záznamům doplňkové tabulky.

Podobně jako u vztahu 1:1 nezakládá vztah M:M podřízenost tabulek. V praxi vztah obvykle zahrnuje několik tabulek. V tomto případě může mít jeden stůl různé druhy spojení s několika tabulkami, které tvoří hierarchii nebo „strom vztahů“.

V tomto projektu kurzu jsou tabulky propojeny vztahy 1:M (one-to-many). Například tabulka "fakulty" je nadřazenou tabulkou podřízené tabulky "oddělení". Tyto tabulky spolu souvisí ve vztahu 1:M pomocí klíče „faculty_code“

Jako každý model má i model vztahu mezi entitou několik základní pojmy, které tvoří výchozí cihly, ze kterých se staví složitější objekty podle předem stanovených pravidel.

Tento model je nejvíce v souladu s konceptem objektově orientovaného designu, který v současné době je nepochybně základem pro rozvoj komplexu softwarových systémů, tolik pojmů se vám může zdát povědomých, a pokud je to pravda, pak pro vás bude snazší zvládnout technologii návrhu databáze založenou na modelu ER.

Model ER je založen na následujících základních konceptech:

Esence, s s jehož pomocí se modeluje třída podobných objektů. 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. Entita Zaměstnanec může mít například následující sadu 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íč. U entity Zaměstnanec bude klíčovým atributem Osobní číslo, protože pro všechny zaměstnance tohoto podniku personální čísla se budou lišit. Instancí entity Zaměstnanec bude popis konkrétního zaměstnance podniku. Jeden z obecně uznávaných grafické symboly entity - obdélník, ve kterém je nahoře napsán název entity a níže jsou uvedeny atributy s klíčovými atributy označenými např. podtržítkem popř. speciální písmo(obr. 7.1):

Rýže. 7.1.Příklad definice entity v ER modelu

Mezi entitami lze nastavit komunikace- binární asociace ukazující, jak entity spolu souvisí nebo jak se vzájemně ovlivňují. 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 máme například 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 to tedy vztah jeden k mnoha (1:M), jeden na straně učitele a mnoho na straně studenta (viz obrázek 7.2).

Rýže. 7.2.Příklad vztahu jeden k mnoha při propojení entit „Student“ a „Učitel“

Různé zápisy vyjadřují komunikační sílu různě. V našem příkladu používáme CASE notaci systému POWER DESIGNER, zde je násobnost znázorněna vydělením odkazu 3. Odkaz má společný název „Discipline Design“ a má názvy rolí na straně obou entit. Ze strany studenta se tato role nazývá „Píše diplomovou práci pod vedením“, ze strany učitele se toto spojení nazývá „Vůdcovství“. 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), od a i-to-many(1 milion), 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 one-to-one (1:1) znamená, že jedna instance jedné entity je spojena pouze s jednou instancí jiné entity, zatímco vztah many-to-many (M:M) znamená, že jedna instance první entity entita 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. Uvažujeme-li například vztah typu „Studium“ mezi entitami „Student“ a „Disciplína“, pak se jedná o vztah typu „mnoho k mnoha“ (M:M), protože každý student může studovat několik oborů, ale každý obor studuje mnoho studentů.Takové spojení ukazuje Obr. 7.3.

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. Příklad těchto zapojení je na Obr. 7.3.

Rýže. 7.3.Příklad modelování vztahu many-to-many

Jakýkoli z těchto typů komunikace může být povinné, pokud se na daném vztahu musí podílet každá instance entity, 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ě. Opět používáme notaci POWER DESIGNER. Zde je volitelnost spojení označena prázdným kroužkem na konci spojení a závazek je označen kolmou čarou, která spojení přeškrtne. 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.

Chcete-li to provést, zvažte dříve uvedený příklad připojení „Diploma Design“. Na našem obrázku je toto spojení interpretováno jako oboustranně volitelné. Ve skutečnosti ale každý student, který píše diplomovou práci, musí mít svého vedoucího projektu diplomové práce, ale na druhou stranu ne každý učitel by měl projekt diplomové práce vést. Proto se v této sémantické formulaci obraz tohoto spojení změní a bude vypadat stejně jako na Obr. 7.4.

Rýže. 7.4.Příklad povinného a nepovinného vztahu mezi entitami

Model ER navíc umožňuje princip kategorizace entit. To znamená, že stejně jako v objektově orientovaných programovacích jazycích je zaveden koncept podtypu entity, to znamená, že entita může být reprezentována jako dva nebo více jejích podtypů - entity, z nichž každý může mít společné atributy a vztahy a/nebo atributy a vztahy, které jsou jednou definovány na nejvyšší úrovni a zděděny na nižší úrovni. Všechny podtypy jedné entity jsou považovány za vzájemně se vylučující a při rozdělení entity na podtypy musí být reprezentována jako úplná sada vzájemně se vylučujících podtypů. Pokud na úrovni analýzy není možné identifikovat úplný seznam podtypů, pak se zavádí speciální podtyp, podmíněně nazývaný JINÉ, který lze dále objasnit. V skutečné systémy Někdy stačí zavést podtypování na dvou nebo třech úrovních.

Zavolá se entita, na jejímž základě jsou podtypy stavěny supertyp. Každá instance nadtypu musí patřit do konkrétního podtypu. Pro grafické znázornění principu kategorizace nebo typizace entity je zaveden speciální grafický prvek, tzv. diskriminační uzel, v notaci POWER DESIGNER je zobrazen jako půlkruh s konvexní stranou obrácenou k superentitě. Tato strana je spojena nasměrovanou šipkou s nadentitou a podtypy této entity jsou spojeny s průměrem této kružnice šipkami (viz obr. 7.5).

Rýže. 7.5.TEST diagram subtypu entity

Tento diagram lze dešifrovat následovně. Každý test v testovacím systému je buď testem znalosti jazyka SQL, nebo nějakým analytickým úkolem, který se provádí pomocí předem napsaných Java appletů, nebo testem v nějaké oblasti znalostí, který se skládá ze sady otázek. a sadu odpovědí navržených pro každou otázku.

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.

Jako příklad navrhneme mytologický model systému určeného k ukládání informací o knihách a oblastech znalostí prezentovaných v knihovně. Popis předmětné oblasti byl uveden dříve. Začněme vývoj modelu identifikací hlavních entit.

V první řadě je to entita „Kniha“, 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á instance 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.

Abychom to odráželi, musíme zavést entitu Instance, která bude obsahovat popisy všech kopií knih uložených 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 jedna k mnoha (1:M), který je vyžadován na obou stranách. Co určuje tento typ připojení? Můžeme předpokládat, že každá kniha může být v knihovně přítomna v několika exemplářích, tedy vztah one-to-many. Navíc, pokud knihovna nemá jedinou kopii dané knihy, pak její popis neuložíme, takže pokud je kniha popsána v podstatě „Kniha“, pak se v knihovně nachází alespoň jedna kopie této knihy. . To znamená, že na straně knihy je připojení povinné. Pokud jde o entitu „Kopie“, v knihovně nemůže existovat ani jeden výtisk, který se nevztahuje ke konkrétní knize, proto je povinné i připojení ze strany „Kopie“.

Nyní musíme určit, jak bude čtenář zastoupen v našem 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ě je každému čtenáři přiděleno unikátní číslo čtenářského průkazu, které našeho čtenáře jednoznačně identifikuje. Číslo čtenářského průkazu bude klíčový atribut entity "čtenáři".

Navíc v entitě „Čtenáři“ musí být další atributy, které jsou nutné pro řešení zadaných úkolů, budou to tyto atributy: „Příjmení Jméno Patronymika“, „Adresa čtenáře“, „Telefon domů“ a „Telefon do práce“. . Proč jsme zavedli dva samostatné atributy pro telefony? Protože na tato čísla je potřeba volat v různou dobu, abyste zastihli čtenáře, bude proto důležité, aby správa knihovny věděla, o jaký typ se jedná. tento telefon. V popisu naší tematické oblasti je omezení věku našich čtenářů, takže v podstatě musí být zadáno „Čtenáři“ povinný atribut„Datum narození“, které nám umožní kontrolovat věk našich čtenářů.

Z popisu tematické oblasti víme, že každý čtenář může držet v ruce několik výtisků knih. Abychom tuto situaci odráželi, musíme vytvořit spojení mezi entitami „Čtenáři“ a „Instance“. Proč ne mezi entitami „Čtenáři“ a „Knihy“? Protože čtenář si z knihovny vezme konkrétní výtisk konkrétní knihy, a nejen knihu. Jak zjistíte, jakou knihu daný čtenář má? A to lze zjistit dodatečným spojením mezi entitami „Instance“ a „Books“ a toto spojení přiřadí každé instanci jednu knihu, takže můžeme kdykoli jednoznačně určit, které knihy jsou v rukou čtenáře, i když se čtenářem spojujeme pouze inventární čísla odebraných knih. Mezi entitami „Čtenáři“ a „Instance“ je vytvořen vztah one-to-many a zároveň je na obou stranách volitelný. Čtenář v tento moment nesmí držet v rukou jedinou knihu a na druhou stranu tento výtisk knihy nemusí mít žádný čtenář, ale prostě stojí na poličce v knihovně.

Nyní musíme odrážet poslední entitu, která je přidružena k systémovému adresáři. Katalog systému obsahuje seznam všech oblastí znalostí, informace o nich jsou obsaženy v knihách knihovny. Můžeme si vyvolat systémový katalog v knihovně, ze kterého obvykle začneme hledat knihy, které potřebujeme, pokud neznáme jejich autory a názvy. Název znalostní oblasti může být dlouhý a může se skládat z několika slov, takže pro modelování systémového katalogu uvedeme entitu „Systémový katalog“ se dvěma atributy: „Knowledge Area Code“ a „Knowledge Area Name“. Atribut Kód oblasti znalostí bude klíčovým atributem entity.

Z popisu oborové oblasti víme, že každá kniha může obsahovat informace z více oblastí vědění a na druhou stranu z praxe víme, že knihovna může obsahovat mnoho knih souvisejících se stejnou oblastí vědění, takže musíme vytvořit mezi entitami „Systémový katalog“ a „Knihy“ jsou vztahem mnoho k mnoha, povinným na obou stranách. Systémový katalog by skutečně neměl obsahovat takovou oblast znalostí, o které nejsou uvedeny žádné knihy v naší knihovně, naopak by to postrádalo smysl. 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.

Mytologický model tematické oblasti „Knihovna“ je uveden na Obr. 7.6.

Rýže. 7.6.Mytologický model "Knihovna"

Vyvinuli jsme mytologický model „Knihovna“ pro úkoly, které byly uvedeny dříve. V těchto úkolech jsme si nekladli podmínku pro uložení historie četby knihy, např. s cílem najít někoho, kdo knihu dříve držel a mohl jí ublížit nebo v ní omylem zapomenout větší obnos peněz. Pokud bychom si dali za úkol tyto informace ukládat, pak by náš informačně-logický model byl jiný. Tento úkol nechám na vaší samostatné kreativitě.