10. blok Logický návrh databáze

10. blok

Logický návrh databáze

Studijní cíl Tento blok je věnován převodu konceptuálního návrhu databáze na návrh logický. Blok se věnuje tvorbě tabulek na základě entit z konceptuálního modelu a dále se věnuje správné interpretací relací mezi entitami a jejich správnému převodu do logického návrhu. Dále je blok zaměřen na kontrolu integritních omezení v logickém návrhu databáze. Doba nutná k nastudování

2 - 3 hodiny

Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen s pojmy konceptuálního modelování. Tzn., že je obeznámen s pojmy entita, relace, multiplicita, participace, ER modelování a ER diagram. 1. Logický návrh databáze Tento blok se zabývá druhým krokem metodologie návrhu databáze, tedy logickým návrhem databáze. Základním zdrojem informaci pro logický návrh je ER model vytvořený během fáze konceptuálního modelování. V tomto bloku tedy dojde k popisu převodu konceptuálního modelu na model logický, který je založen na relačním modelu dat. Základem této fáze je tedy mapování ER konceptuálního modelu do tabulek. Strukturu každé takto vzniklé tabulky je třeba pak zkontrolovat za pomocí normalizace, zejména kvůli potenciální duplicitě sloupců. Zároveň musí být otestováno, zda převedené tabulky stále podporují všechny uživatelské transakce. Konečnou fází logického návrh je kontrola integritních omezení. Logický návrh se tedy dělí na následující kroky:   

Krok 1 – Tvorba tabulek. Krok 2 – Kontrola podpora uživatelských transakcí. Krok 3 – Kontrola integritních omezení.

David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/10 – Logický návrh databáze

1

1.1. Krok 1 – Tvorba tabulek. V tomto kroku dojde k vytvoření tabulek podle ER modelu, který byl vytvořen ve fázi konceptuálního modelování. Tabulky budou v podstatě reprezentací nalezených entit, relací, atributů a integritních omezení. Základním zdrojem informací pro tento krok je tedy ER model, ovšem stále není vyloučeno použití jiné podpůrné dokumentace, vytvořené před fází konceptuálního modelování. Tzn., že logický model nemusí striktně obsahovat jen elementy obsažené v ER diagramu. Pro popis obsahu tabulek se využívá jazyk DBDL (database definition language) – jazyk pro definici databáze, určený pro relační databáze. Při využívání DBDL se nejprve uvede jméno tabulky, poté výčet jejich jednoduchých atributů. Následně určí primární a alternativní klíče. Terminologie Pokud se v rámci ER modelu hovoří o entitě, většinou se její název píše v jednotném čísle. Například entita Student. Po převodu entity na tabulku většinou dojde k převodu názvu entity do množného čísla. To znamená, že z entity Student vznikne tabulka Studenti. Pro každou entitu z ER modelu vytvoříme tabulku, která bude obsahovat všechny jednoduché atributy. Složené atributy rozdělíme na atributy jednoduché. Typicky dojde k rozložení složeného atributu adresa na jednoduché atributy ulice, mesto a psc. Ve všech tabulkách, kde je to možné, se identifikuje sloupec (sloupce), který tvoří primární klíč tabulky. U některých tabulek dojde k identifikaci jen neúplné množiny sloupců, jelikož nebudou ještě reprezentovány relace, které mezi entitami ER modelu existují. Dále se v modelu zřejmě objeví tabulky, u kterých nebude možné určit primární klíč. Typicky půjde o tabulky, které vznikly ze slabých entit. V těchto tabulkách bude možno definovat primární klíč až po zahrnutí sloupců reprezentujících relace. Příklady tabulek, které mohou vzniknout po počátečním převodu entit na tabulky: Studenti (cisloStudenta, stJmeno, stPrijmeni, stDatumNarozeni, stRodneCislo, stUlice, stCp, stMěsto, stPsc, stEmail, stTelefon, stPohlavi, stStuduje) Primární klíč cisloStudenta Alternativní klič stRodneCislo Zkoušky (cisloZkousky, zkDatumZkousky, zkMaxStudentu) Primární klíč cisloZkousky

Předměty (kodPredmetu, prNazevPredmetu, prPocetKreditu) Primární klíč kodPredmetu

Hodnoceni (hodnoceni) Primární klíč neurčen

1 - Příklad definice tabulek


2

Na konci tohoto kroku se budeme zabývat identifikací primárních klíčů pro slabé entity. Příkladem je např. tabulka Hodnoceni. Nyní se je nutné reprezentovat relace. Relace jsou reprezentovány mechanismem primární/cizí klíč. Nejprve, než je rozhodnuto, do které tabulky bude atribut cizího klíče umístěn, musí dojít k identifikaci rodičovské a dceřiné tabulky. Rodičovská entita pak umisťuje kopii svého primárního klíče do dceřiné tabulky, kde tato kopie pak funguje jako cizí klíč. Identifikací rodičovských a dceřiných tabulek dojde k vytvoření jednoho z následujících typů relací:       

binární relace jedna k více (1:*, 1:N), rekurzivní relace jedna k více (1:*, 1:N), binární relace jedna k jedné (1:1), rekurzivní relace jedna k jedné (1:1), binární relace více k více (*:*), komplexní relace, atributy s více hodnotami.

Binární relace jedna k více (1:*, 1:N) Při každé binární relaci jedna k více stojí na jedné straně rodičovská tabulka a na druhé straně relace je tabulka dceřiná. Dceřiná stojí v tomto případě na straně k více. Příklad této relace je na obrázku.

Rodičovská entita

Dceřiná entita

<<Entity>>

Fakulta

<<Entity>>

<>

1..1

Zaměstnává >

0..N

Zamestnanec cisloZamestnance

idFakulta

Obrázek 1 - Relace jedna k více s vyznačením rodičovské a dceřiné tabulky

Atribut idFakulta se stane cizím klíčem v tabulce Zamestnaneci. Výsledný logický model může mít následující podobu:

Obrázek 2 - Logický model relace jedné k více


3

Rekurzivní relace jedna k více (1:*, 1:N) Tato relace je velice podobná binární relaci jedna k více. Základním rozdílem ale je, že této relace se účastní jen jedna entita. Tudíž entita je zároveň rodičovskou i dceřinou entitou. Tzn., že kopie primárního klíče je umístěna do téže tabulky. <>

Vede

Podřízený <<Entity>>

0..N

Zamestnanec

1..1

cisloZamestnance

Vedoucí

Obrázek 3 - Rekurzivní relace

Definice této tabulky by mohla vypadat následovně (se začleněním i předchozí relace 1:*): (cisloZamestnance, zaJmeno, zaPrijmeni, zaPozice, zaEmail, idFakulta, vedouciCisloZamestnance) Primární klíč cisloZamestnance Cizí klíč idFakulta Cizí klíč vedouciCisloZamestnance Zamestnanec

Rekurzivní relace se dá v rámci logického modelování reprezentovat následujícím způsobem:

Obrázek 4 - Logický model rekurzivní relace


4

Binární relace jedna k jedné (1:1) Reprezentovat tento typ relace je o něco komplikovanější než předcházející případy. Hlavním problémem je identifikace rodičovské a dceřiné tabulky (entity). V tomto případě již není možné k identifikaci tabulek využít kardinalitu.

Slovníček Kardinalita Participace (Parcialita)

Popisuje počet možných relací pro každou zúčastněnou entitu. Popisuje, zda se relace účastní všechny výskyty entity nebo jen některé.

V případě relace 1:1 se využívá participace k určení, zda je výhodnější relaci reprezentovat spojením zúčastněných tabulek do tabulky jedné, anebo vytvořit dvě tabulky a umístit kopii primárního klíče jedné tabulky do druhé. Aby to nebylo tak jednoduché, při binární relace 1:1 můžou nastat tři případy participace obou zúčastněných entit:   

(a) Povinná participace na obou stranách relace 1:1. (b) Povinná participace na jedné straně relace 1:1. (c) Nepovinná participace na obou stranách relace 1:1.

Ad a) V tomto případě zpravidla dochází ke spojení obou zúčastěných entit do jediné tabulky, přičemž se vybere jeden z primárních klíčů jako primární klíč nové tabulky, zatímco druhý primární klíč se stane klíčem alternativním. Příklad bude demonstrován na entitách Student a Rodné číslo.

<<Entity>>

<<Entity>> <>

Student cisloStudenta

Má

1..1

Rodne_cislo

1..1 rodneCislo

Obrázek 5 - Relace 1:1 s povinnou participací na obou stranách relace

Z obrázku je zřejmé, že entita Student se neobejde bez entity Rodne_cislo a naopak. Navíc jsou ve vztahu 1:1, což znamená, že zadní dva studenti nemohou sdílet stejné rodné číslo a naopak se dá daná vazba číst, že student musí mít právě jedno rodné číslo. Zároveň tato povinná participace sděluje, že entity v systému David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/10 – Logický návrh databáze

5

nemohou existovat odděleně. Proto jsou obě entity vhodné pro spojení do jedné tabulky. Výsledkem může být tabulka Studenti, jejímž primárním klíčem se stane atribut cisloStudenta a atribut rodneCislo se stane klíčem alternativním. Ostatní atributy obou entit splynou v jedné tabulce.

Obrázek 6 - Logický model po úpravě relace 1:1 s povinou participací na obou stranách relace

Ad b) V tomto případě je identifikace rodičovské a dceřiné tabulky v celku jednoduchá. Entita s nepovinnou participací v relaci bude označena jako rodičovská entita, zatímco entita s povinnou participací se stane entitou dceřinou. Pak už je postup totožný, jako u relace 1:* (1:N) a to sice, že kopii primárního klíče rodičovské entity umístíme do dceřiné entity jako klíč cizí. Viz příklad: Nepovinná participace entity Zamestnanec

Povinná participace entity Notebook

<<Entity>>

Zamestnanec

1..1

cisloZamestnance Rodičovská entita

<>

Má

<<Entity>>

0..1

Notebook idNotebook Dceřinná entita

Obrázek 7 - Relace 1:1 s povinou participací na jedné straně relace

V případě tohoto modelu požadujeme, aby každý notebook byl přiřazen právě k jednomu zaměstnanci. Naopak zaměstnanec k notebooku může být přiřazen, ale nemusí. Jelikož tedy byla entita Zamestnanec identifikovaná jako rodičovská, umístíme tedy kopii primárního klíče tabulky Zamestnanci (cisloZamestance) do tabulky Notebook. Cizí klíč se umisťuje do tabulky s povinnou participací z jednoho prostého důvodu. Takový sloupec pak bude muset být vždy vyplněn (tzn., že cisloZamestnance v tabulce Notebooky bude muset být vždy vyplněno). Zabrání se tím vkládání hodnot null do cizího klíče. Pokud bychom tedy cizí klíč umístili do tabulky reprezentující entitu s nepovinnou participací, pak by sloupec mohl obsahovat hodnoty null.


6

Obrázek 8 - Logický model relace 1:1 s povinou participací jen na jedné straně relace

Ad c) V tomto případě je označení rodičovské a dceřiné tabulky volitelné, pokud tedy nejsou k dispozici nějaké dodatečné informace o obou entitách, které by rozhodování usnadnily. Pokud budeme uvažovat předchozí příklad (za předpokladu že se tentokrát bude jednat o participaci nepovinnou), může být do rozhodování zahrnuta následující úvaha. Může byt zjištěno, že většina notebooků je přiřazována zaměstnancům, ale jen zlomek zaměstnanců vlastní nějaký notebook. V toto chvíli můžeme entitu Zamestnanec označit jako rodičovskou, jelikož entita Notebook má přece jen blíže k povinné participaci. Proto se umístí kopie primárního klíče tabulky Zamestnanci do tabulky Notebooky. Tzn., že logický model bude naprosto shodný s modelem na obrázku 8. Rekurzivní relace jedna k jedné (1:1) U tohoto typu relace se postupuje velmi podobným způsobem jako u binární relace jedna k jedné. Jediný rozdíl je v tom, že entity na obou stranách relace jsou totožné. Binární relace více k více (*:*, M:N) Pro každou binární relaci více k více vznikne v modelu nová tabulka, jenž se stane reprezentací relace a bude obsahovat všechny atributy, které jsou součástí relace. Do této nové tabulky pak umístíme kopie primárních klíčů obou zúčastněných tabulek reprezentující entity. Kopie primárních klíčů se v nové tabulce stanou jako obvykle cizími klíči. Primární klíč nově vzniklé tabulky pak obvykle vzniká kombinací cizích klíčů, případně kombinací cizích klíčů a atributů relace. Uvažujme vztah entit Student a Předmět. Každý student si může zapsat více předmětů a zároveň jeden předmět může navštěvovat více studentů. Jedná se tedy o typický příklad binární relace více k více. Pro vyjádření této relace tedy musí vzniknout nová tabulka, např. StudentiPredmety, do které přidáme kopie primárních klíčů tabulek Student a Předmět. Do nové tabulky můžou být samozřejmě přidány i různé atributy relace, např. datumZapisu (vyjadřuje, kdy si daný student daný předmět zapsal). Zároveň oba cizí klíče spolu vytvoří primární klíč nově vzniklé tabulky.


7

datumZapisu <<Entity>>

Student cisloStudenta

<<Entity>>

0..N

0..N Zapisuje <>

Predmet kodPredmetu

Obrázek 9 - Relace více k více

Nová tabulka, vzniklá díky této relaci více k více, bude mít následující definici: StudentPredmet(cisloStudenta, kodPredmetu, datumZapisu) Primární klíč cisloStudenta, kodPredmetu Cizí klíč cisloStudenta Cizí klíč kodPredmetu

Obrázek 10 - Logický model relace M:N (více k více)

Komplexní relace Za komplexní relaci je považována taková relace, které se účastní více než dvě entity. Taková relace vždy vede na vytvoření nové tabulky pro reprezentaci relace. Kopie všech primárních klíčů zúčastněných entit jsou umístěny do nově vzniklé tabulky, kde se stanou cizími klíči. Samozřejmě nesmí být opomenuto na atributy relace. Z jednoho nebo více klíčů se potom stane primární klíč nově vzniklé tabulky.


8

Dobrým příkladem komplexní relace může být hodnocení výuky. Identifikovali jsme entity Ucitel, Predmet a Student a požadavkem je, aby studenti mohli ohodnotit konkrétní předmět vyučovaný konkrétním učitelem.

<<Entity>>

<>

Predmet

0..N

Hodnocení

<<Entity>> 0..N

kodPredmetu

Ucitel idUcitel

0..N <<Entity>>

Student cisloStudenta Obrázek 11 - Komplexní relace

V tomto případě považujeme entity Predmet, Ucitel a Student za rodičovské entity a proto se kopie jejich primárních klíčů objeví v nově vzniklé tabulce Hodnoceni. Kromě cizích klíčů nesmí být opomenuto na atribut relace samotné. V tomto případě by se jednalo o atribut hodnoceni, jenž by reprezentoval konkrétní hodnocení studenta. Výsledná tabulka Hodnoceni by tedy mohla být definovaná následovně. Hodnoceni (kodPredmetu, idUcitel, cisloStudenta, hodnoceni, pripominky) Primární klíč kodPredmetu, idUcitel, cisloStudenta Cizí klíč kodPredmetu Cizí klíč idUcitel

Obrázek 12 - Logický model komplexní relace


9

Atributy s více hodnotami. Pokud se v modelu vyskytnou entity obsahující atributy s více hodnotami, je třeba na tyto atributy aplikovat pravidla pro relaci typu jedna k více (1:*, 1:N). Tzn., že entitu obsahující tento typ atributu označíme jako entitu rodičovskou. Naopak atribut s více hodnotami přiřadíme na stranu více a vytvoří tak dceřinou entitu. Vždy tak vznikne nová tabulka, která bude sloužit pro uložení atributu s více hodnotami, a rodičovská entita do tabulky umístí kopii svého primárního klíče. Pokud není atribut s více hodnotami sám o sobě alternativním klíčem rodičovské entity, musí se primární klíč nově vzniklé tabulky skládat z atributu s více hodnotami a z původního primárního klíče entity rodičovské.

<<Entity>>

<<Entity>>

Student

Student <>

cisloStudenta jmeno telefon[1..*] adresa

cisloStudenta jmeno adresa

<<Entity>>

1..1 MaTelCisla 1..N Telefon telCislo

Obrázek 13 - Převod atributu s více hodnotami na relaci jedna k více

Ve výše uvedeném příkladu byl vícehodnotový atribut telefon (z tabulky Studenti) vyčleněn do samostatné tabulky Telefony. Nově vzniklá tabulka by tedy měla mít následující definici: Telefony (telCislo,cisloStudenta) Primární klíč telCislo, cisloStudenta Cizí klíč cisloStudenta Cizí klíč cisloStudenta zde v tomto případě posloužil zároveň i jako část primárního klíče.

Obrázek 14 - Logický model po rozložení atributu s více hodnotami


10

1.2. Krok 2 - Kontrola podpory uživatelských transakcí Tento krok je analogický ke kroku posouzení uživatelských transakcí z fáze konceptuálního modelování. Tentokrát už nejsou kontrolovány entity, ale pozornost se zaměřuje na tabulky a na relace mezi nimi. Tento krok by měl zkontrolovat, že tabulky vytvořené v předchozích krocích podporují uživatelské transakce, které jsou uvedeny ve specifikacích uživatelských požadavků. Jedním možným postupem při kontrole uživatelských transakcí je zaměřit se na datové požadavky jednotlivých transakcí. Kontrola by měla prověřit, zda je v daném modelu možné všechna požadovaná data vyhledat či uložit. Pokud jsou data ve více tabulkách, je zároveň nutné zkontrolovat, zda je lze všechny propojit pomocí mechanismu primárních a cizích klíčů. Tento typ kontrol je velmi časově náročný. Často se stává, že je tomuto kroku věnováno pramálo času či je záměrně ignorován. Je proto nezbytné si uvědomit, že vynechání kontrolního mechanismu ve fázi logického návrhu může způsobit značné komplikace. V lepším případě se komplikace projeví při fyzickém návrhu, v tom horším, při samotné implementaci systému. Je zřejmé, že čím později se na problém přijde, tím je vyřešení daného problému náročnější. S tím je samozřejmě spojena značná ztráta času a velmi často se to neobejde i bez finanční ztráty. Proto je důležité neodkládat nepříjemné, ale důležité kroky návrhu na pozdější dobu. 1.3. Krok 3 – Kontrola integritních omezení V této fázi přichází na řadu kontrola toho, zda model obsahuje integritní omezení. Integritní omezení se do databází zavadí jako mechanismus, který zabraňuje tomu, aby se databáze stala neúplnou, nepřesnou či nekonzistentní. Ačkoliv se může stát, že cílový databázový systém neumožní implementovat námi navržená integritní omezení, ve fázi logického návrhu se tento fakt zanedbává. Logický návrh se nezabývá tím, jak omezení budou implementována, ale tím, která integritní omezení mají být implementována. Identifikace integritních omezení je klíčová pro úplnost a celistvost logického návrhu. Mezi základní integritní omezení patří:      

požadovaná data, omezení domén sloupců, integrita entit, multiplicita, referenční integrita, ostatní integritní omezení.


11

Požadovaná data. Toto omezení se vztahuje na sloupce, které musí vždy obsahovat hodnotu, tzn., že se v nich nikdy nesmí objevit hodnota NULL. Například každý zaměstnanec musí mít vyplněné jméno a příjmení. Tento druh bývá obvykle identifikován již ve fázi konceptuálního modelování, konkrétně v kroku identifikace atributů. Omezení domén sloupců. Každý nalezený sloupec má svou doménu, tzn., že je ke sloupci definována konkrétní množina přípustných hodnot. Někdy je definice domény volnější, například když je sloupec definován jen pomocí datového typu. Někdy je naopak definice domény velmi striktní a obsahuje jen velmi omezený výčet přípustných hodnot pro daný sloupec (například výčet možných pracovních pozic pro zaměstnance). Integrita entit. Primární klíč nesmí obsahovat hodnotu NULL. Například všichni zaměstnanci musí být jednoznačně identifikovatelní na základě svého primárního klíče (například cisloZamestnance). Multiplicita. Multiplicita je ten typ integritního omezení, který se primárně soustřeďuje na relace vzniklé mezi daty v databázi. Referenční integrita Úkolem cizího klíče je spojit záznam v dceřiné tabulce se záznamem v rodičovské tabulce. Referenční integrita vynucuje shodu cizího klíče, pokud cizí klíč hodnotu obsahuje, s existujícím primárním klíčem rodičovské tabulky. V souvislosti s cizími klíči je třeba zabývat se dvěma otázkami.


12

První otázka se zabývá tím, zda je u cizího klíče přípustná hodnota NULL? Obecně platí, že pokud je participace dceřiného prvku povinná, nejsou hodnoty NULL v hodnotě cizího klíče přípustné. Naopak, pokud je participace dceřiné entity nepovinná, pak hodnota cizího klíče může obsahovat hodnotu NULL. Druhá otázka se týká zajištění referenční integrity. V této otázce se pozornost zaměřuje na vložení, aktualizaci a smazaní hodnoty primárního či cizího klíče. V této souvislosti může tedy nastat šest následujících případů. 1) Vložení záznamu do dceřiné tabulky. Při vložení nového záznamu se kontroluje, zda se hodnota vložená do sloupce cizího klíče vyskytuje v primárním klíči rodičovské tabulky, nebo se rovná hodnotě NULL (pokud to definice daného sloupce umožňuje). 2) Vymazání záznamu z dceřiné tabulky nemůže mít na referenční integritu vliv. 3) Aktualizace záznamu v dceřiné tabulce. Tento případ se velice podobá případu 1. Opět je nutné zkontrolovat, zda cizí klíč obsahuje některou z hodnot primárního klíče rodičovské tabulky. Alternativně může obsahovat NULL hodnotu. 4) Vložení záznamu do rodičovské tabulky. Vložení nového záznamu do rodičovské tabulky nemůže mít vliv na referenční integritu. Pouze vznikne záznam bez odkazu do dceřiné tabulky. 5) Vymazání záznamu z rodičovské tabulky. Při vymazání záznamu z rodičovské tabulky dojde ke ztrátě referenční integrity, jestliže v dceřiné tabulce existuje záznam s odkazem na právě smazaný záznam v rodičovské tabulce. V tomto případě existuje široká škála řešení, jak ztrátě referenční integrity vymazáním rodičovského záznamu předejít: 





SMAZÁNÍ SE NEPROVEDE. V tomto případě bude zabráněno smazání záznamu rodičovské tabulky, neboť se na něj odkazují záznamy dceřiné tabulky. V tomto případě bude rodičovský záznam možné smazat až ve chvíli, kdy se na něj žádaný ze záznamů dceřiné tabulky nebude odkazovat. KASKÁDNÍ SMAZANÍ. Pokud dojde ke smazání rodičovského záznamu, budou zároveň smazány i záznamy dceřiné tabulky, které se na daný záznam rodičovské tabulky odkazovali. Pokud by dceřiný záznam byl zároveň rodičovským záznamem pro jinou tabulku, mazání by se rozšířilo do této tabulky. Jinak řečeno, došlo by ke kaskádnímu šíření mazání. NASTAVENÍ HODNOTY NULL. Pokud je vymazán záznam rodičovské tabulky, cizí klíč dceřiného záznamu se nastaví na hodnotu NULL. Toho lze využít jen v případě, kdy jsou hodnoty NULL ve sloupci cizího klíče povoleny.


13





NASTAVENÍ IMPLICITNÍ HODNOTY. Pokud dojde k vymazání rodičovského záznamu, nastaví se cizí klíč dceřiného záznamu na předem definovanou implicitní hodnotu. Samozřejmě, že tato hodnota se musí rovnat některé z existujících hodnot primárního klíče rodičovské tabulky. BEZ KONTROLY. V tomto případě nedochází ke kontrole referenční integrity. V tomto případě hrozí, že v dceřiné tabulce vzniknou tzv. sirotci, tedy záznamy dceřiné tabulky odkazující se na záznamy rodičovské tabulky, které již neexistují. Obecně velmi nevhodná strategie kontroly referenční integrity.

6) Aktualizace primárního klíče v rodičovské tabulce. Pokud v rodičovské tabulce dojde ke změně primárního klíče, hrozí, že v dceřiné tabulce zůstane záznam s cizím klíčem odkazujícím se starou (a již neplatnou) hodnotu primárního klíče rodičovské tabulky. Aby zůstala referenční integrita zachována, můžeme využit strategie kaskádní aktualizace. Tato kaskádní aktualizace se provede na všechny cizí klíče odkazující se na právě aktualizovanou hodnotu primárního klíče a totéž se zopakuje kaskádovitě i pro další dceřiné tabulky, pokud existují.

Jiné integritní omezení. Na konec návrhu integritních omezení se rozebírají omezení, která mají být implementována, ale nelze je zařadit do některé z předcházejících kategorií. Taková omezení se nazývají jako ostatní (jiná) integritní omezení. Těmito omezeními můžeme například stanovit, že hodnota primárního klíče se v cizím klíči v dceřiné tabulce může vyskytnout maximálně deset krát (technicky to znamená, že z relace typu 1:* (1:N) se stane relace 1:10)

Pojmy k zapamatování Pojmy: Logický model databáze, tabulka, relace jedna ku jedné, relace jedna ku více, relace více k více, kardinalita, participace (parcialiata), povinná participace, nepovinná participace, multiplicita, integritní omezení, referenční integrita. Problém: Převedení konceptuálního modelu dat na logický návrh databáze, převod entit na tabulky spolu s reprezentací relací, řešení relací typu 1:1, problémy spojené s vícehodnotovými atributy, návrh integritních omezení, různé strategie aktualizace rodičovských a dceřiných tabulek. David Žák, Jiří Zechmeister, Tomáš Váňa IDAS1/10 – Logický návrh databáze

14

Shrnutí  

 



Cílem kapitoly bylo shrnout fázi logického návrhu databáze. Logický návrh databáze se zaměřuje na vznik množiny tabulek na základě transformace ER modelu vytvořeného ve fázi konceptuálního návrhu databáze. Jedním z důležitých kroků logického návrhu je nalezení správných relací mezi jednotlivými tabulkami. Důležitou fází logického návrh je i kontrola struktury tabulek z pohledu uživatelských transakcí. Je nutné, aby bylo možné stále provést všechny uživatelské transakce vyjmenované při analýze. Integritní omezení zabraňují vzniku nekonzistencí a nekompletnosti databáze. Do skupiny těchto omezení se řadí požadavky na data, omezení domén sloupců, entitní integrita, referenční integrita a jiné integritní omezení.

Otázky na procvičení 1. 2. 3. 4. 5. 6. 7. 8.

Jaký je hlavní cíl logického modelování? Co jsou to silné a slabé entity? Co vyjadřuje pojem rekurzivní relace? Uveďte příklady. Jak je možné postupovat při kontrole uživatelských transakcí? K čemu se využívá integritních omezení? Jak lze definovat komplexní relaci? Co jsou to atributy s více hodnotami? Jaké strategie je možné použít v případě, že dceřiný záznam odkazuje na rodičovský záznam, který má být smazán.

Odkazy a další studijní prameny

Odkazy a další studijní prameny CONOLLY, Thomas, Carolyn BEGG a Richard HOLOWCZAK. Mistrovství databáze: profesionální průvodce tvorbou efektivních databází. Brno: Computer Press, 2009. ISBN 978-802-5123-287.


15

10. blok Logický návrh databáze

Recommend Documents