Aplikační a programové vybavení

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

2. 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 (entitytypes) – 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 (attributedomain) – množina hodnot, kterých může atribut nabývat • klíč (key) – množina atributů, jejichž hodnoty jednoznačně identifikují entitu

3. 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

4. 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.

5. E-R model – příklad

6. 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))

7. 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 – ?

8. 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 vztahM:N • pokud má vztah atributy • VZTAH(ID, OSOBA1, OSOBA2, DATUM_VZNIKU) • má vztah nepovinné členství a není přípustná prázdná hodnota atributu

9. 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í: • OSOBA(ID_OS, JMÉNO, PŘÍJMENÍ) • ADRESA(ID_AD, MĚSTO, ULICE) • BYDLIŠTĚ(ID_BY, ID_OS, ID_AD, OD_KDY)

10. 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é)

11. 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.

12. První normální forma • 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

13. Druhá normální forma • 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

14. Druhá normální forma VZTAHY: OSOBY: • 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

15. Třetí normální forma ADRESY: • 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)

16. Třetí normální forma MĚSTSKÉ ČÁSTI: ADRESY: • 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

17. E-R model – příklad

18. 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

19. E-R model – příklad