Aplikační a programové vybavení Přednáška se zabývá postupem návrhu a vytvoření struktury relační databáze. 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říjmení Pokud vám tyto pojmy připomínají objektové programování (modelování), tak je to dobře. Objektové modelování a ER modelování a relační modelování jsou tři velmi podobné nástroje, pro řešení stejného problému. Pro jistotu: doména atributu je přesnější určení než datový typ. Neboli datový typ je např. integer, ale doména může být: „integer (1-200)“, tj. přesněji určená množina možných hodnot.

E-R model Entity-Relationship model Relationship není relace znázorňuje se ER diagramy (ERD) klasická varianta: typy entit (třídy objektů) Zde nastává zmatek v tom, že v angličtině se relace řekne relation. Vztah se řekne relationship, což se bohužel velmi často hovorově zkracuje na relation. Jedná se však o dvě velmi různé věci (relace je množina něčeho – osob, schůzek apod.). Vztah je vazba mezi těmito entitami (osoba může a nemusí mít schůzku). Pro ERD existuje více zápisů (notací); tzv. klasická notace obsahuje je dobrá v počáteční fázi návrhu. Ke konci slajdů je uvedena i pokročilejší notace crow’s foot. atributy (vlastnosti) vztahy mezi entitami

E-R model – příklad Zadání projektu: 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. Základním krokem při návrhu databáze je analýza zadání. V následujících slajdech je popsán nejjednodušší způsob zadání analýzy, který vyžaduje použití selského informatického rozumu. Je to způsob vhodný pro malé databáze (malá databáze = databáze, kterou si celou pamatujete – orientačně do 100 tabulek). Pro složitější systémy je nutné použít sofistikovanější metodiky pro návrh systému. Selským informatickým rozumem si přečtěte zadání. Vyberte z něj podstatná jména. Podstatná jména jsou entity (nebo typy entit), které (pravděpodobně) bude nutné uložit do databáze. Rozdíl mezi typem entity a entitou je stejný jako rozdíl mezi třídou a objektem, tj. entita (objekt) je konkrétní instance něčeho obecného – typu entity (třídy). Pokud máte v textu identifikované entity, můžete načrtnout ERD podle symbolů na předchozím slajdu.

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. Pokud se vám podařilo načrtnout jiný model, neznamená to, že je špatně. Model databáze je problém, který nemá jednoznačné řešení, tedy jedno zadání lze namodelovat 1000 různými způsoby. Na násobnost vztahů se vždy ptejte otázkou, která začíná jedničkou. Tj. Jedna osoba bydlí na 1 adrese. Na jedné adrese bydlí N osob.

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í pro návrh vůbec důležitá (pro implementaci už ano). 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 sloupcem. Naproti tomu vztah M:N je problém, protože vyžaduje vytvoření další propojující tabulky. Obecně platí, že všechny vztahy, které na světě existují jsou vztahy M:N – snažíme se tedy najít co nejnižší násobnost vztahu, která ještě dostačuje aplikaci. Toto odpovídá definici, že „Software pro informační systém je model informačního systému podniku – model procesů, které probíhají v podniku“. Model je zjednodušený a platí tedy, že software je vždy zjednodušením reality a nemůže postihovat všechny podivnosti, které na světě vznikají. Příkladem mohou být siamská dvojčata, která řídí auto (http://www.youtube.com/watch?v=a9h6JpXZ5N8) a informační systém pro evidenci dopravních přestupků. Při určování násobnosti se tedy snažíme postihnout co nejvíce případů, ale ne nutně všechny. Viz také Parettovo pravidlo (http://en.wikipedia.org/wiki/Pareto_principle).

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 – ? Proč se používá ER model pro návrh relační databáze? Protože se snadno převádí do konkrétní podoby relační databáze (snadněji než objektový model). 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 uvnitř jiných tabulek pomocí přidaných sloupců Obecně je vztah reprezentován tabulkou pokud: se jedná o vztah M:N pokud má vztah atributy VZTAH(ID, OSOBA1, OSOBA2, DATUM_VZNIKU) 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) První případ může vypadat divně, protože město a ulice nejsou na první pohled vlastnosti osoby. Při druhém pohledu ale zjistíte, že jimi docela klidně mohou být – je to jen konzervativní myšlení, které člověku nutí rozlišit mezi osobou a adresou. Druhou variantu lze použít pouze pokud je jedna adresa přiřazena právě jedné osobě. Pokud má být jedna adresa přiřazena více osobám, ale současně jedna osoba má přiřazenou pouze jednu adresu, je možné použít opět druhou variantu – pouze se přidá sloupec id_adresy k osobám, přesně tak, jak je to ve vzorové databázi pro projekt do APV. Třetí variantu je nutné použít typicky v případě tabulek, která evidují historická data. Je relativně snadné dát do systému omezení, že uživatel smí mít pouze jednu (korespondenční) adresu. Pokud zákazník požaduje, aby systém uchovával i změny adres, je nutné zavést relaci bydliště. Protože uživatel smí mít pouze jednu aktuální adresu. Historicky však mohl mít adres víc.

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é) Definice jsou vysvětleny na následujících slajdech. Funkční závislost atributu A na atributu B znamená, že pokud změníme hodnotu atributu B, změní se zcela jistě i hodnota atributu A. Např. sloupec jméno závisí na sloupci id_osoby, protože změna hodnoty id_osoby vede ke změně osoby jako takové (entity) a tedy i nutně ke změně jména (to, že mohou mít dvě osoby stejné jméno je nepodstatné, jedná se o jinou instanci osoby a tedy i o jinou instanci jména). Z definice klíče vyplývá, že všechny vždy atributy závisí na klíči. U normálních forem jsou však podstatné částečné a tranzitivní závislosti na klíči.

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é (viz dále) vlastnosti. Normalizace je proces, který při návrhu databáze pomáhá navržené schéma databáze zkontrolovat. Normální formy jsou pouze doporučení, které má databáze splňovat. Pro OLTP systémy se zpravidla používají databáze, které jsou dobře normalizované. Použití databází, které porušují normální formy musí mít velmi dobrý důvod. Jeden z mála obhajitelných důvodů je výkon aplikace, typickým případem může být například zapisování operací v systému (návštěvy webových stránek, operace v IS). Jedná se o akci, kterou je nutné provést velmi rychle a současně produkuje velké množství dat v krátkém čase (u zatížených systémů to mohou být miliony řádků během sekund/minut). Na druhou stranu i zde se může normalizace hodit ke zmenšení velikosti tabulky, ale je nutné ji pečlivě zvážit. S tabulkami, které porušují normální formy se velmi často setkáte v analytických systémech (OLAP). Zde se pracuje s denormalizovanými tabulkami. Jak název napovídá, jedná se o tabulky, které vznikly zrušením normálních forem u již existujících normalizovaných tabulek – což stručně znamená, že tyto tabulky vznikly spojením (SQL JOIN) nějakých normalizovaných tabulek. Pokud se vám zdá divné, že nějakou zdrojovou tabulku nejprve rozsekáme (normalizujeme) na schéma databáze a vzápětí ji zase denormalizujeme do zobrazitelné podoby, věřte, že právě toto je obrovská výhoda relačních databází. Tj. je to možnost vzít nějaká data, rozbít je a pak je slepit jiným způsobem dohromady. Je to možnost vzít data, která vnikají nějakým pevně daným způsobem a zobrazit je tisíci různými způsoby podle toho, co kdo zrovna chce vidět.

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í NF stačí jen přidat vhodné sloupce. To, že se atomičnost vyžaduje z hlediska aplikace znamená, že není možné bezhlavě atomizovat cokoliv (např. datum). Zajímavým příkladem je například atomizace adresy, která se zejména ve Spojených státech nebo ve Velké Británii vůbec nedělá (což je způsobeno míň formálním systémem adres, v ČR používáme velmi formální německý systém). V takovém případě je adresa jen jedno pole, anebo je rozdělená do: address_line_1, address_line_2, address_line_3 Takový přístup je možný v případě, že se s adresou dále nijak nepracuje – tj. používá se pouze a jen k natištění na obálky. V tom případě se z ní stává atomický údaj, protože ho aplikace nezpracovává, nerozděluje, jen ho ukládá a zobrazuje.

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). Pokud se v aplikaci objeví anomálie vložení (musíte vložit něco, aby se vložilo něco jiného), nebo anomálie zrušení, pak jednoznačně víte, že máte špatný návrh databáze.

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 (viz předchozí přednášky).

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ě, že tabulka není ve 2NF. V databázi k projektu je tabulka adres ponechána s porušením 3NF a je to proto, aby se s databází jednodušeji pracovalo. Vzhledem k tomu, že způsob normalizace adres je sám o sobě lehce diskutabilní, tak jsem si toto dovolil, abyste měli s projektem o něco méně práce.

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 a vytvořit další tabulku.

E-R model – příklad Klasická varianta 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 anebo hodně zkušenosti, které vám umožní toto všechno udělat současně v jednom kroku.

E-R model – příklad Finální schéma databáze. Platí stále, že se jedná pouze o návrh a návrh je od toho, aby se měnil. Relační databáze jsou navrženy tak, že se v průběhu používání snadno a poměrně často mění (zejména rozšiřují). Nikdy tedy nepovažujte schéma databáze za finální, v průběhu implementace aplikace se vždy objeví další požadavky, které je nutné do schématu zakomponovat. Čím pečlivěji je však udělaná prvotní analýza, tím budou změny menší a méně drastické.

Otázky? Jaký je rozdíl mezi vztahem a relací? Lze použít objektové modelování místo ER modelování? Pokud není databáze v 3NF, smí se použít v aplikaci? Jaké násobnosti vztahu se rozlišují? Kdy má smysl v databázi ukládat datum jako sloupce den, měsíc a rok? Co je parcialita vztahu a kdy je důležitá? Je možné jednoznačně určit násobnost vztahu? Kdy je nutné pro reprezentaci vztahu vytvářet tabulku? Proč je redundance dat v databázi škodlivá? Je nutné nějak rozdělovat datum, aby byla dodržena atomičnost?