Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Vytvoření databáze. Obecná metoda modelování datových struktur Popis dat pomocí entit a vztahů (E-R): entita (entity) – jednoznačně identifikovatelný.

Podobné prezentace


Prezentace na téma: "Vytvoření databáze. Obecná metoda modelování datových struktur Popis dat pomocí entit a vztahů (E-R): entita (entity) – jednoznačně identifikovatelný."— Transkript prezentace:

1 Vytvoření databáze

2 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

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

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

9 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 – převod do normální formy (NF) Normálních forem je více, ale prakticky se používají první 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 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 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 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 Růžeslav Mekota Chlastislav Peruňka Pražská 12, Brno Olomoucká 23, Brno Květoslav Blekota Sosna Orbnicová Brněnská 56, Praha Brněnská 32, Olomouc

13 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 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 ChlastislavPeruňka SosnaOrbnicová RůžeslavMekota ChlastislavPeruňka KvětoslavBlekota SosnaOrbnicová

14 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 RČ 1. osoby RČ 2. osoby Datum vzniku RČJménoPříjmení SosnaOrbnicová ChlastislavPeruňka KvětoslavBlekota RůžeslavMekota VZTAHY:OSOBY:

15 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) IDMěstoUliceČOPSČ 1BrnoPražská BrnoOlomoucká BrnoBrněnská ADRESY:

16 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 IDUliceČOPSČ 1Pražská Olomoucká Brněnská ADRESY: MěstoPSČ Brno-město Brno-kr.pole Brno-č.pole MĚSTSKÉ ČÁSTI:

17

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

20 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?


Stáhnout ppt "Vytvoření databáze. Obecná metoda modelování datových struktur Popis dat pomocí entit a vztahů (E-R): entita (entity) – jednoznačně identifikovatelný."

Podobné prezentace


Reklamy Google