Aplikační a programové vybavení Vytvoření databáze

E-R modelování Obecná metoda modelování datových struktur Popis dat pomocí entit a vztahů (E-R): entita (entity) – jednoznačně identifikovatelný objekt reálného světa (záznam v tabulce) typ entity (entity types) – třídy reálných objektů stejného typu vztah (relationship) – vazba mezi entitami atribut (attribute) – vlastnost entity nebo vztahu hodnota (value) – konkrétní hodnota (instance) atributu doména atributu (attribute domain) – množina hodnot, kterých může atribut nabývat klíč (key) – množina atributů, jejichž hodnoty jednoznačně identifikují entitu Příklad: entita: Jiří Paroubek typ entity: populista vlastnost: věk hodnota: 15? doména: 1-200 klíč: jméno, přijmení

E-R model Entity-Relationship model Relationship není relace znázorňuje se ER diagramy (ERD) klasická varianta: typy entit (třídy objektů) atributy (vlastnosti) vztahy mezi entitami

E-R model – příklad Zadání příkladu ze cvičení: Vytvořte webovou aplikaci pro evidenci přítelkyň, přítelů, adres, vztahů a schůzek. Hlavním prvkem aplikace je evidence osob a schůzek mezi nimi, tedy jakýsi adresář. U každé osoby se zaznamenává jméno, příjmení, věk, bydliště a kontaktní údaje. Každá osoba může mít libovolný počet kontaktních údajů (mobil, Jabber, Skype, …). Každá osoba může mít vztah s libovolnými jinými osobami v databázi. U každého vztahu se zaznamenává délka trvání a typ (známý, přítel, přítelkyně, manžel, …). Dále se také zaznamenávají schůzky mezi jednotlivými osobami. Schůzky se může účastnit libovolný počet osob. U schůzky se dále zaznamenává datum a místo. Osoba může mít více kontaktů stejného typu (např. dva emaily). Typy kontaktů jsou definované dynamicky v databázi a uživatel je může měnit. Aplikace musí umožňovat přidání, změnu a odstranění vložených údajů. Aplikace by měla umožňovat snadné přidávání a změnu osob a schůzek. Využijte navržené schéma databáze a vytvořte databázi a implementujte aplikaci.

E-R model – příklad Klasický E-R model se dá prakticky vytvářet přímo ze zadání a výborně se na něm určuje násobnost vztahu.

Násobnost vztahu násobnost vztahu (kardinalita vztahu, cardinality ratio, relationship degree) parcialita vztahu (úplné/částečné členství) R (Entity1:(min, max), Entity2:(min, max)) 1:1 – ŘÍDÍ(OSOBA:(0,1), AUTO:(0,1)) 1:N – VLASTNÍ(OSOBA:(0,N), AUTO:(1,1)) N:M – POUŽÍVÁ(OSOBA:(0,M), AUTO:(0,N)) Parcialita vztahu se v klasickém ER diagramu nezobrazuje protože vlastně není vůbec důležitá. Naproti tomu násobnost vztahu je velmi důležitá, vztah 1:1 není problém, vztah 1:N většinou také není problém, často se dá reprezentovat jen jedním odkazujícím se polem. Naproti tomu vztah M:N je problém protože může vyžadovat vytvoření další propojující tabulky.

Převod E-R modelu na RDB E-R konceptuální model je velice blízký relačnímu datovému modelu typ entity – tabulka entita – záznam v tabulce atribut – sloupec tabulky hodnota atributu – buňka tabulky vztah – ? Jak převést vztah mezi entitami je otázka, protože záleží na násobnosti vztahu a dalších okolnostech.

Převod vztahu Vztahy mohou být reprezentovány: samostatnými tabulkami skrytě uvnitř jiných tabulek Obecně je vztah reprezentován tabulkou pokud: se jedná o vztah M:N pokud má vztah atributy VZTAH(ID, OSOBA1, OSOBA2, DATUM_VZNIKU) má vztah nepovinné členství a není přípustná prázdná hodnota atributu Vztah je možné reprezentovat tabulkou vždy, jelikož se však jedná o dost práce navíc a je vhodné se tomu vyhnout vždy pokud je to jen trochu možné. Reprezentování všech vztahů tabulkami je pokus o vytváření univerzálního systému, který zpravidla končí neúspěchem. Obecně velmi častým případem atributu (vlastnost) vztahu M:N je datum vzniku, viz. další slajd.

Převod vztahu Příklad (osoba – adresa): Pokud má osoba maximálně jednu adresu, může být uvedena v tabulce osob: OSOBA(ID_OS, JMÉNO, PŘÍJMENÍ, MĚSTO, ULICE) Pokud má osoba více adres je nutné zavést tabulku adres a v ní odkaz na osobu: OSOBA(ID_OS, JMÉNO, PŘÍJMENÍ) ADRESA(ID_AD, MĚSTO, ULICE, ID_OS) Pokud na jedné adrese bydlí více osob je nutné zavést další tabulku přiřazení: ADRESA(ID_AD, MĚSTO, ULICE) BYDLIŠTĚ(ID_BY, ID_OS, ID_AD, OD_KDY)

Normalizace návrhu Normalizace – převod do normální formy (NF) Normálních forem je více, ale prakticky se používají první 3. 1. NF – hodnoty atributů jsou atomické 2. NF – relace neobsahuje částečné funkční závislosti neklíčových atributů na klíči 3. NF – žádný neklíčový atribut není tranzitivně závislý na klíči Další normální formy nejsou příliš praktické NF jsou pouze doporučení (ale nedodržení musí být opodstatněné)

Normální formy NF jsou vnořené – tj. relace je ve 3. NF pokud je v 1. i v 2. i ve 3. NF. Pokud je DB v 3NF je zajištěno, že bude mít určité kladné vlastnosti. Pokud databáze ve 3NF není, tak si autor musí sám pohlídat, aby databáze měla správné vlastnosti.

První normální forma Tato definice relace VZTAHY není v 1. NF Jméno 1. osoby Jméno 2. osoby Adresa 1. osoby Adresa 2. osoby Datum vzniku vztahu Chlastislav Peruňka Sosna Orbnicová Olomoucká 23, Brno Brněnská 32, Olomouc 1.1.2004 Růžeslav Mekota Pražská 12, Brno 12.3.2006 Květoslav Blekota Brněnská 56, Praha 5.1.2007 Tato definice relace VZTAHY není v 1. NF není jasné pořadí jméno-příjmení nelze řadit podle jména, příjmení, města, ulice nelze vypsat nebo hledat jen příjmení atomičnost se vyžaduje z hlediska aplikace Pro převod relace do první stačí jen přidat vhodné sloupce.

Druhá normální forma Jméno 1. osoby Příjmení 1. osoby RČ 1. osoby RČ 2. osoby Jméno 2. osoby Příjmení 2. osoby Datum vzniku vztahu Chlastislav Peruňka 123456 213456 Sosna Orbnicová 1.1.2004 Růžeslav Mekota 543256 12.3.2006 Květoslav Blekota 456456 5.1.2007 Tato definice relace VZTAHY je v 1.NF a není v 2.NF klíčem jsou atributy RČ1 a RČ2, protože datum vzniku vztahu závisí na jejich kombinaci jméno a příjmení 1. osoby závisí na RČ 1. osoby – tedy závisí na klíči pouze částečně redundance dat anomálie vložení, anomálie zrušení nelze vložit osobu, která nemá žádný vztah Částečná závislost znamená, že atribut (sloupec) závisí pouze na části klíče (v přikladu jméno 1. osoby závisí pouze na rodném čísle první osoby, což je pouze část klíče (celý klíč je tvořen kombinací rodné číslo 1. osoby a rodné číslo 2. osoby)). Pokud budeme předpokládat, že jednoznačnou identifikací osoby je rodné číslo, tak můžeme jako klíč použít kombinaci rodné číslo první osoby a rodné číslo druhé osoby. Pak však vznikají anomálie vložení (nelze vytvořit záznam o osobě, která nemá žádný vztah (rodné číslo druhé osoby není známé a klíč by byl neúplný)) a anomálie zrušení (při smazání všech vztahů osoby zmizí i záznam o osobě). Současně je v tabulce velká redundance dat, a s tím spojené nebezpečí neúplných aktualizací a následných nekonzistencí. Pro převod do druhé normální formy je nutné tabulku rozdělit. Pokud tabulka neobsahuje složený klíč, tak je vždy automaticky ve druhé normální formě (protože neobsahuje složený klíč, tak nemůže existovat částečná závislost nějakého atributu).

Druhá normální forma VZTAHY: OSOBY: RČ 1. osoby RČ 2. osoby Datum vzniku 123456 213456 1.1.2004 543256 12.3.2006 456456 5.1.2007 RČ Jméno Příjmení 213456 Sosna Orbnicová 123456 Chlastislav Peruňka 456456 Květoslav Blekota 543256 Růžeslav Mekota Tato definice relací VZTAHY a OSOBY je v 2. NF (a tedy i v 1. NF) žádná data nejsou redundantní vložení vztahu neznamená vložení osoby zrušení vztahu nezruší osobu rozklad schématu musí být bezztrátový tak, aby bylo možné rekonstruovat původní schéma Tabulka ve druhé normální formě je úspornější a spolehlivější způsob uložení dat, nicméně zpravidla již neodpovídá tomu, jakým způsobem chceme data zobrazovat. Došlo tedy k rozkladu původního schématu databáze, které je před zobrazením nutné rekonstruovat do původní podoby. Toho se dá docílit např. použitím příkazu JOIN jazyka SQL.

Třetí normální forma Tato definice relace ADRESY není v 3. NF ID Město Ulice ČO PSČ 1 Brno Pražská 3 643 00 Olomoucká 54 656 00 4 Brněnská 22 653 00 Tato definice relace ADRESY není v 3. NF atribut PSČ závisí na atributu Město změna hodnoty města zcela jistě vyvolá změnu PSČ každý neklíčový atribut plně závisí na klíči (definice klíče) pokud neklíčový atribut závisí na jiném neklíčovém atributu, pak závisí na klíči také tranzitivně (nepřímo) Jedná se opět o určitou redundanci dat v tabulce (město je jednoznačně určeno hodnotou PSČ), není však tak dramatická jako v případě pokud tabulka není ve 2NF.

Třetí normální forma Rozložením relace ADRESY je nová relace v 3NF: MĚSTSKÉ ČÁSTI: ADRESY: ID Ulice ČO PSČ 1 Pražská 3 643 00 Olomoucká 54 656 00 4 Brněnská 22 653 00 Město PSČ Brno-město 643 00 Brno-kr.pole 656 00 Brno-č.pole 653 00 Rozložením relace ADRESY je nová relace v 3NF: klíčem tabulky městských částí je PSČ hypotetické přečíslování PSČ by ale mohlo způsobit problémy Pro převod do 3NF je opět potřeba tabulku rozdělit.

E-R model – příklad Klasická variante E-R diagramu vychází spíše z reality, je blízká slovnímu popisu zadání. Neodpovídá však skutečnému schématu databáze a před implementací je tedy potřeba ji dále zanalyzovat a identifikovat skutečné tabulky, které vzniknou jednak z existujících entit, jednak převodem vztahů a konečně také normalizací návrhu.

E-R Diagram „klasický“ diagram obsahuje entity a vztahy některé vztahy se nemusí projevit tabulkami „crow’s foot“ diagram obsahuje spíše definice jednotlivých tabulek Crow’s foot diagram je velmi blízký schématu databáze a je možné ho rovnou využít pro vytvoření struktury databáze (lepší modelovací nástroje umožňují export diagramu do SQL pro vytvoření struktury databáze). Není však možné jej vytvořit přímo ze zadání, jeho vytvoření vyžaduje analýzu vztahů mezi entitami a dále normalizaci návrhu.

E-R model – příklad