Modelový příklad Knihovna Vypracovaný příklad ze cvičení včetně komentářů k řešení 2014-02-28



Podobné dokumenty
Zadání. Seznam typů entit včetně jejich atributů, vyznačte klíče a cizí klíče Seznam typů vztahu určený svým názvem a entitami do něj vstupujícími

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Konceptuální modelování. Pavel Tyl

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Hromadná korespondence

Metodika návrhu databáze

Úvod do databázových systémů 6. cvičení

Úvod do databázových systémů

Databáze. Logický model DB. David Hoksza

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

DBS Konceptuální modelování

Úvod do databázových systémů

Inovace a zkvalitnění výuky prostřednictvím ICT Databázové systémy MS Access propojení relací s formuláři a sestavami Ing.

Obsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel

Databázové systémy. Cvičení 2

Střední průmyslová škola Zlín

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou:

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

IMPORT DAT DO DATABÁZE

Obsah přednášky. Databázové systémy. Normalizace relací. Normalizace relací. Normalizace relací. Normalizace relací

Otázka č. 1 (bodů za otázku: 4)

Terminologie v relačním modelu

HROMADNÉ ÚPRAVY NAJÍT A NAHRADIT

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi.

Databáze I. Přednáška 2

Návod k použití webového katalogu CKIS

Funkční schéma Datové schéma Integrita modelu s realitou

CVIČENÍ 4 G:\KU\DAS\PDOXWIN\KNIHOVNA

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Návrh databázového modelu

Databázové systémy. Vztahy a relace. 3.přednáška

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

Úvod do databázových systémů 10. cvičení

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS

Diagram výskytů a vztahů

Úvod do databázových systémů. Lekce 1

Strukturované metodologie

Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Úvod do databázových systémů 2012/2013 IS MHD

Microsoft. Access. Nová databáze, návrh tabulky. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie

Databázové a informační systémy Informační systém prodejny nábytku. Jakub Kamrla, KAM087

Databázové systémy Cvičení 5.2

C8 Relační databáze. 1. Datový model

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií

Microsoft Office. Word hromadná korespondence

Databáze 2013/2014. Konceptuální model DB. RNDr. David Hoksza, Ph.D.

2HCS Fakturace 3 - modul Banka -

Databázové systémy Cvičení 5.3

Databázové modelování. Analýza Návrh konceptuálního schématu

Úvod do databázových systémů

DATABÁZE MS ACCESS 2010

5. POČÍTAČOVÉ CVIČENÍ

Relační datový model. Integritní omezení. Normální formy Návrh IS. funkční závislosti multizávislosti inkluzní závislosti

Postupy práce se šablonami IS MPP

Popis modulu Základní popisy odpadu v programu SKLAD Odpadů 8

Informační systém pro nemocnici

8.2 Používání a tvorba databází

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy

VYTVÁŘENÍ DATABÁZÍ, VKLÁDÁNÍ ÚDAJŮ

Obsah. 1.1 Práce se záznamy Stránka Dnes Kontakt se zákazníkem... 5

Databázové systémy. Ing. Radek Holý

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

DUM 12 téma: Příkazy pro tvorbu databáze

Návod na základní používání Helpdesku AGEL

Hierarchický databázový model

DBS Konceptuální modelování

DATOVÉ MODELOVÁNÍ ER MODEL

Microsoft. Access. Výběrové dotazy. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie

Návod na používání Digitálního povodňového plánu povodňové komise

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška

DATABÁZE A SYSTÉMY PRO UCHOVÁNÍ DAT 61 DATABÁZE - ACCESS. (příprava k vykonání testu ECDL Modul 5 Databáze a systémy pro zpracování dat)

Používání IS Carsystem

JRV.CZ s.r.o. Bulharská Brno RosaData TM DEVELOPERSKÝ PROJEKT

Administrace webu Postup při práci

Analýza dat a modelování. Přednáška 1

Vykazování dat o poskytovaných sociálních službách

Formulář NÚV v programu PPP4

soubor dat uspořádaných do řádků a sloupců

5. Formalizace návrhu databáze

Databázové patterny. RNDr. Ondřej Zýka

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

Základy relačních databází, jejich využití v programování webu

Semestrální práce 2 znakový strom

Základy informatiky. 06 Databázové systémy. Kačmařík/Szturcová/Děrgel/Rapant

Konceptuální modelování

1. Základní pojmy, používané v tomto manuálu. 2. Stránky

6. blok část C Množinové operátory

4. blok část A Logické operátory

Revize majetku. Dovývoj je vytvořen jako součást DELPHI Pluginu a může být přidán do jakékoliv existující knihovny. (pokud existují zdrojové kódy)

Databáze I. 4. přednáška. Helena Palovská

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Manuál SQL Ekonom funkce pro zajištění souladu s ochranu osobních údajů podle GDPR

Hromadná korespondence

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal

Vykazování dat o poskytovaných sociálních službách

Návod na půjčování e-knih

A5M33IZS Informační a znalostní systémy. Relační databázová technologie

Transkript:

Modelový příklad Knihovna Vypracovaný příklad ze cvičení včetně komentářů k řešení 2014-02-28 v.1.0 Mějme evidenci klasické knihovny, našim cílem je evidovat informace o výpůjčkách a s tím související agendy, pro účely rychlého zatřídění a vyhledání potřebné knihy. Obsah 1. Definice typů entit (objektů)... 2 2. Definice typů vztahů mezi entitami (objekty)... 3 Kniha má exempláře (Kniha, Exemplář)... 3 Exemplář je vypůjčen (Výpůjčka, Exemplář)... 4 Čtenář si vypůjčil (Výpůjčka, Čtenář)... 4 Autor napsal knihu (Autor, Kniha)... 5 Kniha je psána v nějakém žánru (Žánr, Kniha)... 5 3. Výsledné schéma... 6 4. Odstranění vazeb M:N... 6 5. Finální úprava schématu a lineárního zápisu... 7 6. Datový slovník... 8 7. Schémata generovaná nástroji pro vizuální tvorbu datových struktur... 10 Logické (konceptuální) schéma... 10 Relační (databázové) schéma... 10 8. Další řešené pojmy a problémy... 11 Vazby s informací... 11 Vícenásobné vazby... 11 Vícenásobná vazba... 11 Vícenásobná vazba nahrazená vazební tabulkou... 11 Vazby typu povinnost : povinnost pro kardinalitu 1:N... 12 Vazby typu povinnost : povinnost pro kardinalitu 1:1... 12 Vazby 1:1 vliv povinnosti na cizí klíč... 12 Unární vazby vazba sama na sebe... 13

1. Definice typů entit (objektů) Prvním krokem je definice typů entit, které chceme v systému evidovat Kniha (ISBN, název, počet stran, nakladatel, rok vydání, ) Autor (číslo autora, příjmení, jméno, anotace, ) Žánr (číslo žánru, název žánru, anotace, ) Čtenář (číslo čtenáře, jméno, příjmení, ulice, město, PSČ, email, telefon) Výpůjčka (ISBN, číslo čtenáře, datum čas půjčení, datum čas vrácení, datum čas skutečného vrácení) Podtržení značí klíč, který jednoznačně rozlišuje každý řádek (objekt, prvek) v tabulce. Kroužkem značíme cizí klíč, který je převzat z jiné tabulky. Tato vlastnost se využívá při tvoření vazeb kdy například u vazby 1:N bereme klíč z tabulky, kde je kardinalita 1 a ukládáme jej do tabulky kde je kardinalita N. Atributy musí být atomické, dále nedělitelné, proto jsme rozepsali na dílčí části jméno, a adresu (ctíme pravidlo, že jednotlivé komponenty, jde vždy sloučit, ale obráceně to nemusí platit), mohou nastat i struktury typu pole (více autorů pro jednu knihu), toto ale řešíme dodatečnou tabulkou (číselníkem) Jelikož u Výpůjčky sledujeme navíc data a časy půjčení a vrácení, sledujeme celou historii, ne pouze aktuální stav výpůjček. Tato organizace je vhodná pro vedení účetní agendy, kdy potřebujeme sledovat, kolik výpůjček se provedlo v daném období. Diskutovali jsme problém, více exemplářů jedné knihy: Řešení, kdy do tabulky kniha přidáme číslo exempláře, zavádí redundanci. Všechny informace o knize budou stejné, lišící se pouze číslem exempláře. Kniha (číslo exempláře, ISBN, název, počet, stran, nakladatel, rok vydání, ) Vhodné je přidat novou tabulku exemplář, v niž bude číslo exempláře a ISBN, navíc zde lze ukládat i další informace, jako třeba datum pořízení daného exempláře, datum vyřazení z nabídky atd. Následně je nutné změnit i tabulku Výpůjčka, jelikož se nepůjčuje kniha s ISBN, ale konkrétní exemplář s číslem exempláře. (To má výhodu v tom, že sledujeme, kdo si půjčil který konkrétní kus, jak často byl půjčen, kdo jej poškodil atd.) Upravené schéma vypadá takto: Kniha (ISBN, název, počet stran, nakladatel, rok vydání, ) Autor (číslo autora, příjmení, jméno, anotace, ) Žánr (číslo žánru, název žánru, anotace, ) Čtenář (číslo čtenáře, jméno, příjmení, ulice, město, PSČ, email, telefon) Exemplář (číslo exempláře, ISBN, datum pořízení, datum vyřazení) Výpůjčka (číslo exempláře, číslo čtenáře, datum čas půjčení, datum čas vrácení, datum čas skutečného vrácení)

2. Definice typů vztahů mezi entitami (objekty) Druhým krokem je definice typů vztahů, ty musíme pojmenovat a určit jejich kardinalitu (mohutnost) a povinnost členství Čtenář Výpůjčka Exemplář Kniha Autor Žánr V našem případě jsme identifikovali 5 vztahů, které pojmenujeme a určíme jejich kardinalitu a povinnost členství. U vztahu uvádíme smysluplný název a typy entit (objektů), které do vztahu vstupují. Kniha má exempláře (Kniha, Exemplář) N : 1 Exemplář N : 1 Kniha 1 : 1 Je třeba říci dvě nebo čtyři tvrzení, která rozhodnou o výsledné kardinalitě (mohutnosti) vztahu. Začneme zjednodušenou variantou čtyř tvrzení: Jedna kniha může mít více exemplářů = vztah z pohledu knihy na exemplář 1:N Jeden exemplář je pouze pro jedinou knihu = vztah z pohledu exemplář kniha 1:1 Celkově je tedy vztah 1:N (obecnější z obou identifikovaných vztahů) Nyní k povinnosti členství: o Každý exemplář musí být pro nějakou knihu (každý exemplář vstupuje do vztahu s nějakou knihou) plný puntík o Každá kniha nemusí mít exemplář (každá kniha nemusí vstupovat do vztahu s nějakým exemplářem) prázdný puntík Varianta řešena dvěma větami, kombinuje povinnost a kardinalitu v jednom tvrzení: Kniha může (slovo může rovná se nepovinnost členství) mít více (= N) exemplářů. Exemplář musí být (slovo musí = znamená povinnost) právě pro jednu (= 1) knihu. Je nutné si uvědomit, že tyto složená tvrzení určují povinnost na jedné straně, ale kardinalitu na straně protější. Viz předchozí obrázek. (Jedna kniha může mít více exemplářů N na straně exempláře, ale nepovinnost (může) na straně knihy.

Exemplář je vypůjčen (Výpůjčka, Exemplář) N : 1 Výpůjčka N : 1 Exemplář 1 : 1 Tvrzení určující kardinalitu a povinnost členství: Jeden exemplář může být vícekrát půjčen Jedná výpůjčka je pouze pro jediný exemplář Celkově je tedy vztah 1:N (z pohledu jeden exemplář více výpůjček) Nyní k povinnosti členství: o Každý exemplář nemusí mít výpůjčku nepovinné členství prázdný puntík o Každá výpůjčka je pro nějaký exemplář povinné členství plný puntík Čtenář si vypůjčil (Výpůjčka, Čtenář) N : 1 Výpůjčka N : 1 Čtenáč 1 : 1 Tvrzení určující kardinalitu a povinnost členství: Jeden čtenář může mít více výpůjček Jedná výpůjčka je pouze pro jednoho čtenář Celkově je tedy vztah 1:N (z pohledu jeden čtenář více výpůjček) Nyní k povinnosti členství: o Každý čtenář nemusí mít výpůjčku nepovinné členství prázdný puntík o Každá výpůjčka je pro nějakého čtenáře povinné členství plný puntík

Autor napsal knihu (Autor, Kniha) N : 1 Autor M : N Kniha 1 : N Tvrzení určující kardinalitu a povinnost členství: Jedna kniha může mít více autorů Jeden autor mohl napsat více knih Celkově je tedy vztah M:N (sloučení obou mnohočetností) Nyní k povinnosti členství: o Každý autor nemusel napsat knihu nepovinné členství prázdný puntík o Každý kniha nemusí mít autora nepovinné členství prázdný puntík Povinnost členství můžeme také formulovat jako důkaz sporem o Může existovat autor, který nic nenapsal o Může existovat kniha, které nemá žádné autory Kniha je psána v nějakém žánru (Žánr, Kniha) N : 1 Žánr M : N Kniha 1 : N Tvrzení určující kardinalitu a povinnost členství: Jedna kniha může být zařazena do více žánrů V jednom žánru může být napsáno více knih Celkově je tedy vztah M:N (sloučení obou mnohočetností) Nyní k povinnosti členství: o Každý žánr nemusí evidovat knihu nepovinné členství prázdný puntík o Každý kniha nemusí mít přiřazen žánr nepovinné členství prázdný puntík

3. Výsledné schéma Výsledné schéma po doplnění kardinalit a povinností členství Čtenář Výpůjčka Exemplář Kniha Autor Žánr Ve schématu jsou vidět vztahy s kardinalitou M:N, které nejsme schopni v relačním datovém modelu přímo zaznamenat, a proto je musíme nahradit vazební tabulkou. 4. Odstranění vazeb M:N Nahrazení vazeb M:N vazební tabulkou Vazba M:N nelze v relační databázi uložit, a proto se musí nahradit vazební tabulkou, které bude obsahovat klíče obou typů entit, které do vztahu vstupují. Případně pak další dodatečné informace, hovoříme pak o vazbě s informací. Pokud se zamyslíme nad naším již hotovým schématem, vidíme, že v podstatě tabulka výpůjčka, je také vazební tabulkou, které rozkládá vztah typu M:N mezi Exemplářem a Čtenářem (Jeden exemplář mohl být vícekrát půjčen, jeden čtenář si mohl půjčit více exemplářů). Navíc se zde jedná o vazbu s (dodatečnou) informací, jelikož zde ukládáme i data půjčení a vrácení. Kniha Napsal Autor Uvědomme si: Krajní typy entit mají nepovinnost členství = jejich klíče už musí existovat (samostatně), když je přidáváme do vazební tabulky U vazební tabulky je vždy povinnost na obou stranách = vždy musí existovat klíče z obou stran, které propojují a tím realizují vazbu (do Napsal se vždy uloží ISBN knihy a číslo autora) Nezapomeňte na to, že i vazební tabulka musí mít svůj vlastní klíč, který jednoznačně rozliší každý řádek, obvykle jsou to cizí klíče, případně přidané další atributy nebo nový umělý klíč Kniha Žánr Knihy Žánr

5. Finální úprava schématu a lineárního zápisu Nahrazení vazeb M:N vazební tabulkou Jak jsme si mohli všimnou, v dřívějším lineárním zápisu, měli jsme sice typy entit Kniha, Autor a Žánr, ale tyto spolu nebyly nijak propojeny (pomocí cizího klíče) = vzájemná vazba nebyla zaznamenána. Nahrazením vazeb M:N jsme získali vazební tabulky a dvěma novými vztahy, které právě toto propojení zajišťují. Čtenář Výpůjčka Exemplář Kniha Napsal Žánr Knihy Autor Žánr Zde platí obecné pravidlo, že klíč bereme z typu entity, kde je hodnota kardinality 1, a ukládáme do typu entity kde je hodnota kardinality N (hodnota klíče se může v tomto typu entity víckrát zopakovat). Lineární zápis typů entit: Kniha (ISBN, název, počet stran, nakladatel, rok vydání, ) Autor (číslo autora, příjmení, jméno, anotace, ) Žánr (číslo žánru, název žánru, anotace, ) Čtenář (číslo čtenáře, jméno, příjmení, ulice, město, PSČ, email, telefon) Exemplář (číslo exempláře, ISBN, datum pořízení, datum vyřazení) Výpůjčka (číslo exempláře, číslo čtenáře, datum čas půjčení, datum čas vrácení, datum čas skutečného vrácení) Napsal (ISBN, číslo autora) Žánr Knihy (ISBN, číslo žánru) Lineární zápis typů vztahů: Kniha má exempláře (Kniha, Exemplář) Exemplář je vypůjčen (Výpůjčka, Exemplář) Čtenář si vypůjčil (Výpůjčka, Čtenář) Autor napsal knihu (Autor, Kniha) - tento typ vztahu M:N byl nahrazen dvěma vztahy Autor Napsal (Autor, Napsal) Kniha je napsána (Napsal, Kniha) Kniha je psána v nějakém žánru (Žánr, Kniha) - tento typ vztahu M:N byl nahrazen dvěma vztahy Kniha je v žánru (Kniha, Žánr Knihy) Použitý žánr (Žánr, Žánr knihy)

6. Datový slovník Datový slovník slouží k podrobnému popisu jednotlivých atributů Datový slovník vytváříme pro každou tabulku zvlášť. Datový slovník obsahuje tyto hodnoty: Název Atributu popisující výstižně (přesně a bezesporně) jeho obsahový význam Datový typ text, číslo, datum atd. Velikost maximální počet znaků, počet číslic Klíč zda je daný atribut klíčem (nebo součástí klíče pro danou tabulku), Pozor na cizí klíč, toto je vlastnost integritního omezení, ale i cizí klíč může být klíčem pro danou tabulku, například u vazebních tabulek po M:N rozkladu NULL zda daná hodnota nemusí být vyplněna Index zda podle daného atributu bude často třídit nebo vyhledávat (v databázích můžeme třídit a vyhledávat podle libovolného atributu, ale pokud jej indexujeme, celý proces se zrychlí) Integritní omezení upřesňují formát vstupních dat, cizí klíče a další vlastnosti, které chceme pro dané atributy kontrolovat Uvědomme si: pokud je atribut někde klíčem a v jiné tabulce je použit jako cizí klíč, musí mít stejný datový typ a velikost Akceptuje-li hodnoty NULL u cizího klíče jedná se o nepovinný vztah Neakceptuje-li hodnoty NULL u cizího klíče jedná se o povinný vztah = vždy musí být vyplněno například ISBN u Exempláře Datový slovník pro typ entity Kniha: ISBN číslo 10 ano ne ano Formát ISBN název text 200 ne ne ano počet stran číslo 4 ne ne ne nakladatel text 100 ne ne ano rok vydání číslo 4 ne ne ne Datový slovník pro typ entity Autor: číslo autora číslo 6 ano ne ano Od 0 inkrementálně nahoru příjmení text 50 ne ne ano jméno text 30 ne ne ne anotace text 1000 ne ano ne Datový slovník pro typ entity Žánr: číslo žánru číslo 3 ano ne ano Od 0 inkrementálně nahoru název žánru text 150 ne ne ano anotace text 1000 ne ne ne

Datový slovník pro typ entity Čtenář: číslo čtenáře číslo 8 ano ne ano Od 0 inkrementálně nahoru jméno text 30 ne ne ne příjmení text 50 ne ne ano ulice text 50 ne ne ne město text 50 ne ne ne PSČ číslo 5 ne ne ne email text 100 ne ano ne Kontrola formátu emailu *) telefon text 10 ne ano ne Kontrola formátu tel. čísla *) *) Dodatečné integritní omezení = musí být vyplněn minimálně jeden údaj (telefon, email) Datový slovník pro typ entity Exemplář: číslo exempláře číslo 9 ano ne ano Od 0 inkrementálně nahoru ISBN číslo 10 ne ne ano Cizí klíč z tabulky Kniha datum pořízení datum 10 ne ne ne RRRR-MM-DD datum vyřazení datum 10 ne ano ne RRRR-MM-DD Datový slovník pro typ entity Výpůjčka: číslo exempláře číslo 9 ano ne ano Cizí klíč z tabulky Exemplář číslo čtenáře číslo 8 ano ne ano Cizí klíč z tabulky Čtenář datum čas Časové 19 ano ne ano RRRR-MM-DD HH:MM:SS půjčení razítko datum čas Časové 19 ne ne ne RRRR-MM-DD HH:MM:SS vrácení datum čas skutečného vrácení razítko Časové razítko 19 ne ano ne RRRR-MM-DD HH:MM:SS Datový slovník pro typ entity Napsal: ISBN číslo 10 ano ne ano Cizí klíč z tabulky Kniha číslo autora číslo 6 ano ne ano Cizí klíč z tabulky Autor Datový slovník pro typ entity Žánr knihy: ISBN číslo 10 ano ne ano Cizí klíč z tabulky Kniha číslo žánru číslo 3 ano ne ano Cizí klíč z tabulky Žánr

7. Schémata generovaná nástroji pro vizuální tvorbu datových struktur Použitý nástroj Oracle Developer Data Modeler, dostupný na adrese www.oracle.com Logické (konceptuální) schéma Všimněte si, že toto schéma obsahuje vazby typu M:N a nejsou v tabulkách přeneseny cizí klíče. Relační (databázové) schéma Zde jsou již vazby M:N nahrazeny vazební tabulkou, a navíc jsou pro ostatní vazby (1:1 a 1:N), přeneseny cizí klíče (příznak F).

8. Další řešené pojmy a problémy Nahrazení vazeb M:N vazební tabulkou Vazby s informací Vazba, která krom propojení entit navíc dodává další informaci Obvykle se tato další informace ukládá do nového typu entity (tabulky), nebo pokud je to možné, přidává se k již existujícím typům entit. Příklad takovéto vazby s informací můžeme vidět v typu entity Výpůjčka v logickém schématu předchozí kapitoly. Kdybychom chtěli sledovat, pouze kdo si co půjčil, byla by to vazba M:N, následně nahrazená vazební tabulkou V tomto případě jsou zde dodatečné informace (data) a proto je nutné je někam uložit, nelze je však přidat ani k Exempláři ani ke Čtenáři Vícenásobné vazby Vícenásobné vazby, mezí více než dvěma typy entit Krom nejčastěji užívaných vazeb binárních existuji i vazby vícenásobné, tedy mezi více než dvěma typy entit. V tomto případě pak, většinou pro realizaci této vazby používáme vazební tabulku. Vícenásobná vazba Učitel Rozvrh Předmět Místnost Na cvičení jsme si uváděli příklad Rozvrh vyučovacích hodin: Což je ternární vztah mezi Učitelem, Místností a Předmětem Navíc se zjevně bude jednat o vazbu s informací, jelikož nám nestačí vědět, který učitel učí, který předmět, v jaké místnosti, ale navíc chceme doplnit i datum (den v týdnu) a čas Vícenásobná vazba nahrazená vazební tabulkou Učitel Rozvrh Předmět Místnost

Vazby typu povinnost : povinnost pro kardinalitu 1:N Tento typ povinnosti přináší problémy v implementaci Odebrání povinnosti Majitel Auto Majitel Auto u Majitele Představíme-li si situaci: Máme Auto a Majitele, definujeme vztah povinnost:povinnost a kardinalitu 1:N = jeden Majitel může mít více Aut Uvědomme si, že vkládat můžeme vždy pouze do jediné tabulky, nelze vkládat do dvou tabulek současně (proto, je třeba vložit záznam nejprve do tabulky jedné a potom druhé) Pokud budou tabulky prázdné Při vložení nového Majitele bude systém vyžadovat přidání auta (které zatím neexistuje) takže majitele nepřidáme Při pokusu vložit nové Auto dojde k požadavku na přidání Majitele (stejná situace) záznam opět nejde přidat Řešením je prohlásit jednu povinnost za nepovinnou a to obvykle tu, která je na straně (kardinality) 1 v našem případě Majitel Tedy nejdříve do systému přidáme Majitele bez aut a následně pak při přidávání Aut již budeme vybírat z existujících (vložených) Majitelů Vazby typu povinnost : povinnost pro kardinalitu 1:1 Vazba povinnost : povinnost V tomto případě, pokud tomu nebrání jiné okolnosti (třeba zabezpečení = omezíme přístup různým uživatelům k různým tabulkám, lze to řešit i v rámci jediné tabulky, kdy omezíme uživatelům přístup na určité sloupce) spojujeme tabulky do jediné. Sloučení Ridič 0 Řidičský průkaz Řidič + Řidičský průkaz do jediné tabulky Je nutné si uvědomit: Máme kardinalitu 1:1, tedy každý prvek má právě jeden obraz v protější množině Navíc je-li povinnost na obou stranách, vzniká problém při vkládání prvních hodnot Dále, každý prvek bude mít vždy právě jednu vazbu a počet prvků v obou množinách je stejný Tím pádem můžeme informace sloučit do jediné tabulky, která bude obsahovat vše Vazby 1:1 vliv povinnosti na cizí klíč Vliv cizího klíče na vazbu 1:1, obě varianty přenesení klíče fungují, některé jsou lepší Zákazník Členská karta Pokud máme vztah 1:1:

povinnost členství pouze na jedné straně je vhodné brát klíč z nepovinné části vztahu a ukládat jej do povinné, tak máme jistotu, že cizí klíč bude mít vždy vyplněnu nějakou hodnotu Naproti tomu ani druhá varianta není špatně, pouze u některých prvků, kde nebude existovat vazba bude hodnota cizího klíče NULL (neznámá - nevyplněná) Třetím faktorem, který ovlivní naše rozhodnutí, který klíč přenést je složitost klíče o Například máme-li přenášet rodné číslo (složité) nebo číslo zaměstnance (jednoduché), volíme jednoduchou variantu, která zabere méně místa o Případně, opět můžeme řešit otázku zabezpečení = který klíč v sobě nese kritická data (rodné číslo, číslo pasu, číslo bankovního účtu), ten nemusíme chtít přenášet jinam Unární vazby vazba sama na sebe Vazbu unární si představíme jako vazbu binární nad dvěma stejnými tabulkami Vztah unární, je situace, kdy existuje vazba nad jedinou tabulkou. Zaměstnanec Rozložíme na dvě stejné tabulky Zaměstnanec (Nadřízený) Zaměstnanec (Podřízený) Uvědomme si: Vztah nad jedinou tabulkou můžeme řešit jako vztah binární, tedy nad dvěma tabulkami, které mají identický obsah Určíme vztah, a pokud se bude jednat o vazbu 1:1, 1:N přidáme do stejné tabulky cizí klíč, který bude vazbu realizovat o Například: každý zaměstnanec má svoje identifikační číslo, a přidáme do tabulky identifikační číslo mého nadřízeného o Kdo má nadřízeného, ten bude mít tuto hodnotu vyplněnou, kdo nemá nadřízeného, bude mít hodnotu NULL Pokud by se jednalo o vazbu M:N o Například: Zaměstnanec má více oblíbených spolupracovníků o Musíme situaci řešit (M:N rozkladem) vazební tabulkou o Uvědomme si, ale že vazební tabulka nám ukládá pouze jednosměrnou informací Tedy mým oblíbeným spolupracovníkem je třeba Karel Pokud jsem i já Karlovým oblíbencem, měla by v tabulce existovat druhá (protisměrná) vazba Oblíbenci Zaměstnanec Doufám, že vám tento materiál bude alespoň trochu k užitku Radoslav Fasuga