Databázové systémy. Normálové formy + kandidátní klíče. 2.přednáška

Podobné dokumenty
Databáze I. Přednáška 3

Databázové systémy. Cvičení 3

Obsah přednášky. Databázové systémy. Normalizace relací. Normalizace relací. Normalizace relací. Normalizace relací

5. Formalizace návrhu databáze

Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola

5. Formalizace návrhu databáze

Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace

Úvod do databázových systémů 10. cvičení

Kapitola 7: Návrh relačních databází. Nástrahy relačního návrhu. Příklad. Rozklad (dekompozice)

Databáze. Logický model DB. David Hoksza

Relační datový model. Integritní omezení. Normální formy Návrh IS. funkční závislosti multizávislosti inkluzní závislosti

Úvod do databázových systémů. Cvičení 12 Ing. Martin Zwierzyna

Databázové systémy. Přednáška 1

Databázové systémy Tomáš Skopal

Úvod do databázových systémů

Střední průmyslová škola Zlín

Databázové systémy. Ing. Radek Holý

Databáze I. 4. přednáška. Helena Palovská

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška

NORMALIZACE Část 2 1

Normální formy. Zdeněk Kouba

4. Základy relačních databází, logická úroveň návrhu

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy

Úvod do databázových systémů

MATICE. a 11 a 12 a 1n a 21 a 22 a 2n A = = [a ij]

4IT218 Databáze. 4IT218 Databáze

Jiří Mašek BIVŠ V Pra r ha

Návrh databázového modelu

11. blok Normalizace. Studijní cíl

UDBS Cvičení 10 Funkční závislosti

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou:

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů

Mortalita chronických nemocí dolní části dýchacího ústrojí (J40 J47)

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Konceptuální modelování. Pavel Tyl

Databázové systémy. Cvičení 2

Hierarchický databázový model

Mortalita zhoubný novotvar hrtanu, průdušnice a průdušky (C32-C34)

Mortalita - ostatní příčiny

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

8.2 Používání a tvorba databází

Úvod do databázových systémů 6. cvičení

Mortalita zhoubný novotvar žaludku (C16) kraj Vysočina

Databázové systémy. Vztahy a relace. 3.přednáška

Databáze I. Přednáška 2

Databázové systémy. Úvod do teorie normalizace. Vilém Vychodil

Regionální zpravodajství NZIS Celková mortalita kraj Vysočina Regionální zpravodajství NZIS

Kurz Databáze. Obsah. Návrh databáze E-R model. Datová analýza, tabulky a vazby. Doc. Ing. Radim Farana, CSc.

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR):

Obsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel

Mortalita dopravní nehody (V01 V99)

Mortalita zhoubný novotvar žaludku (C16)

CENOVÉ MAPY ČESKÉ REPUBLIKY

Mortalita Alzheimerovy nemoci, demence a senility (G30, F00 F07)

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

Mortalita dopravní nehody (V01 V99)

Mortalita onemocnění ledvin (N00 N29) kraj Vysočina

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Přehled o počtu OSVČ

Mortalita - nehody (V01 X59)

Relace x vztah (relationship)

Praha - bytové prostory

Mortalita - nehody (V01 X59)

Věková struktura obyvatelstva

Mortalita onemocnění jater (K70 K77)

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi.

Vysoká škola báňská Technická univerzita Ostrava Fakulta stavební Katedra městského inženýrství. aktivita A0705 Příprava faktografických údajů

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Databáze 2013/2014. Konceptuální model DB. RNDr. David Hoksza, Ph.D.

NEZAMĚSTNANOST V PLZEŇSKÉM KRAJI PODLE MPSV K

1 Báze a dimenze vektorového prostoru 1

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Provozní dokumentace. Seznam datových schránek. Datové soubory. Vytvořeno dne: Aktualizováno: Verze: 1.

ZADÁVACÍ DOKUMENTACE Příloha č. 2 Specifikace částí veřejné zakázky. Poskytování služeb v oblasti praní a čištění prádla

6. Vektorový počet Studijní text. 6. Vektorový počet

Úřad práce v Plzni. Zpráva o situaci na trhu práce Plzeňský kraj. Únor 2010

KMA/PDB. Karel Janečka. Tvorba materiálů byla podpořena z prostředků projektu FRVŠ č. F0584/2011/F1d

Liga mladších žáků skupina C

HIV / AIDS, Česká rep.,

Krajská pobočka Úřadu práce ČR v Královéhradeckém kraji. Měsíční statistická zpráva

Úvod do databázových systémů

Základy relačních databází, jejich využití v programování webu

KIV/ZIS cvičení 2. Martin Kryl

Mortalita Alzheimerovy nemoci, demence a senility (G30, F00 F07)

Liga mladších žáků 2000 skupina C

4. Napjatost v bodě tělesa

QA Pokrytí gynekologickou preventivní prohlídkou

Úvod do databázových systémů

Strukturované metodologie

Transkript:

Databázové systémy Normálové formy + kandidátní klíče 2.přednáška

Struktura databází = struktura samotných relací První aspekt návrhu relační databáze 2 cíle: 1. Obsahový (odpovědi na otázky) 2. Minimalizace redundancí

Co je a co není redundance? Č. obj. Jméno prodejce Zaměstnán od Linka Firma Výrobek Ks 1 Nová A. 1.1.2008 12 Kobe CX-13 20 2 Nová A. 1.1.2008 12 Alexo MD-50 40 3 Nová A. 1.1.2008 12 Tulo DS-13 10 4 Míval P. 3.3.2006 44 Kobe RC.45 30 5 Míval P. 3.3.2006 44 Juko FG-78 10 6 Lubo V. 1.1.1990 22 Hasa CV-12 10 7 Bílá F. 8.8.2008 55 Juko FG-78 20

Relace Výrobky na skladě Číslo výrobku Název výrobku Jednotková cena FX12 Zubní pasta Signal 25 DX34 Mýdlo Protex 15 FG22 Šampon HB Bříza 39 DX89 Lak na vlasy T. 79 Relace Objednávky Č.obj. Název výrobku Jednotková cena Množství Datum obj. 1 Mýdlo Protex 15 100 1.2.2009 2 Lak na vlasy T. 79 20 3.2.2009

Schopnosti databáze Závisí na úplnosti systému Závisí na struktuře systému

Základní princip Principy normalizace = nástroje, které řídí strukturu dat Tzn. specifikují pravidla pro strukturu dat

Bezztrátová dekompozice Relace propojujeme prostřednictvím propojení atributů při tvorbě normalizovaného datového modelu odstraňujeme redundance, přičemž rozdělujeme původní relace tak, aby je opětovně bylo možno spojit bez ztráty informace = bezztrátová dekompozice

Č.obj. Datum Dodat dne Firma Adresa Telefon 1 1.1.2009 5.1.2009 AB Dolní 15 444444 2 2.2.2009 6.2.2009 AB Dolní 15 444444 Nenormalizovaná relace Řešení : Kod zak. Firma Adresa Telefon Relace Zákazník + Č.obj. Datum Dodat dne Kod zak. Relace Objednávky

Kandidátní (identifikační) klíče Z definice relace víme, že každý její člen (řádek) musí být jedinečný. Pro splnění této podmínky musí platit: U každé relace existuje určitá kombinace atributů, která jednoznačně identifikuje každý jednotlivý vektor souřadnic

Kandidátní klíč - pokračování Daná relace může mít víc než jeden kandidátní klíč KK (pak se jeden stanoví jako primární KK a ostatní jako náhradní KK) Jestliže mají dva vektory souřadnic stejnou hodnotu KK, pak reprezentují stejnou entitu Každá relace musí mít alespoň jeden KK Triviálním KK je množina všech atributů

Kandidátní klíč - pokračování Jednoduchý KK - skládá se z jediného atributu Složený KK - více atributů KK musí být neredukovatelný (jakákoliv podmnožina z KK již nezabezpečí jednoznačnou identifikaci)

Kandidátní klíč - pokračování Pokud je jediný KK příliš rozsáhlý, můžeme zvolit umělý KK s hodnotami vygenerovanými systémem Pozor: umělému KK nelze přikládat žádný jiný význam např. číslování atd.

Cíl normalizace Odstranění redundance v relaci Existuje 6 normálních forem: 1.NF 2.NF 3.NF Boyce/Coddova NF 4.NF 5.NF

První normální forma Relace je v 1.NF, pokud všechny její atributy jsou definovány nad skalárními obory hodnot. (každý atribut je dále nedělitelný)

První normální forma Jméno Obec Okres Kraj Petr Poupa Klatovy Klatovy Plzeňský Josef Pokorný Železná Ruda Klatovy Plzeňský Antonín Mokrý Zdice Beroun Středočeský Ladislav Lejbl Broumy Beroun Středočeský Jan Novák Beroun Beroun Středočeský Miroslav Růžička Hradec Králové Hradec Králové Hradec Králové Lucie Hesslerová Doksy Kladno Středočeský Jan Malý Doksy Česká Lípa Liberecký

První normální forma Jméno Příjmení Obec Okres Kraj Petr Poupa Klatovy Klatovy Plzeňský Josef Pokorný Železná Ruda Klatovy Plzeňský Antonín Mokrý Zdice Beroun Středočeský Ladislav Lejbl Broumy Beroun Středočeský Jan Novák Beroun Beroun Středočeský Miroslav Růžička Hradec Králové Hradec Králové Hradec Králové Lucie Hesslerová Doksy Kladno Středočeský Jan Malý Doksy Česká Lípa Liberecký

První normální forma ID zam. Příjmení Jméno Adresa 1 Novák Petr Luční 534, 460 01, Liberec 2 Vodičková Eva Nad lesem 78, 110 00, Praha 3 Vítek Vlastimil Potoční 15, 602 00, Brno 4 Lukeš Jaroslav Kubánská 235, 460 01 Liberec ID zam. Příjmení Jméno Ulice Č.p. PSČ Město 1 Novák Petr Luční 534 460 01 Liberec 2 Vodičková Eva Nad lesem 78 110 00 Praha 3 Vítek Vlastimil Potoční 15 602 00 Brno 4 Lukeš Jaroslav Kubánská 235 460 01 Liberec

Opakovaná skupina hodnot Opakovaná skupina hodnot je typ neskalární hodnoty Tato relace není v 1.NF!!! Č. obj. Kód zákazníka Polož ka 1 Množst ví 1 Položk a 2 Množs tví 2 Položk a 3 Množs tví 3 Polož ka 4 Množs tví 4 1 2

Opakovaná skupina hodnot Č. obj. Kód zákazníka Polož ka 1 Množst ví 1 Položk a 2 Množs tví 2 Položk a 3 Množs tví 3 Polož ka 4 Množs tví 4 1 2 Č. obj. Položka Množství Č. obj. kód zákazníka 1 +

2. normální forma Relace je v 2.NF, pokud je v 1.NF a navíc v relaci existuje atribut A k takový, že hodnoty všech ostatních atributů A i pro i k jsou funkčně závislé na hodnotách atributu A i. Hodnota atributu A i jednoznačně identifikuje popisovaný objekt Atribut A i nazýváme primární klíč Pokud primární klíč v tabulce přirozené neexistuje, můžeme ho do tabulky uměle doplnit (ID)

2. normální forma Relace je v 2.NF, pokud je v 1.NF a navíc všechny její atributy jsou závislé na celém kandidátním klíči Tato relace není v 2.NF!!! Název výrobku NV Jméno dodavatele JD Název kategorie NK Telefon dodavatele TD

2.NF pokračování Č. výrobku Název výrobku Kategorie Č. dodavatele Jméno dodavatele Telefon

2. normální forma Je relace v 2.NF? Jméno Příjmení Obec Okres Kraj Petr Poupa Klatovy Klatovy Plzeňský Josef Pokorný Železná Ruda Klatovy Plzeňský Antonín Mokrý Zdice Beroun Středočeský Ladislav Lejbl Broumy Beroun Středočeský Jan Novák Beroun Beroun Středočeský Miroslav Růžička Hradec Králové Hradec Králové Hradec Králové Lucie Hesslerová Doksy Kladno Středočeský Jan Malý Doksy Česká Lípa Liberecký

2. normální forma Není je třeba doplnit ID ID Jméno Příjmení Obec Okres Kraj 1 Petr Poupa Klatovy Klatovy Plzeňský 2 Josef Pokorný Železná Ruda Klatovy Plzeňský 3 Antonín Mokrý Zdice Beroun Středočeský 4 Ladislav Lejbl Broumy Beroun Středočeský 5 Jan Novák Beroun Beroun Středočeský 6 Miroslav Růžička Hradec Králové Hradec Králové Hradec Králové 7 Lucie Hesslerová Doksy Kladno Středočeský 8 Jan Malý Doksy Česká Lípa Liberecký

2.NF - pokračování Z předchozího příkladu vidíme, že je lépe nesnažit se vyjádřit více entit v jedné relaci. (menší redundance, možnost zavést nového dodavatele, aniž bychom museli objednat výrobek)

3. normální forma Relace je v 3.NF pokud je v 2.NF a navíc v databázi (soustavě tabulek) neexistuje atribut A k, jehož hodnoty by se daly funkčně odvodit z hodnot ostatních atributů. V databázi neexistují redundantní data.

3. normální forma Relace je v 3.NF pokud je v 2.NF a navíc všechny její neklíčové atributy jsou vzájemně nezávislé. Př.: Firma, kde z každý region má jednoho obchodního zástupce / prodejce Tato relace není v 3.NF!!! Č.obj. Firma Region příjemce Prodejce

3. normální forma Č.obj. Firma Region příjemce Prodejce Č. obj. Firma Region příjemce Region příjemce Prodejce +

3. normální forma Je relace v 3.NF? ID Jméno Příjmení Obec Okres Kraj 1 Petr Poupa Klatovy Klatovy Plzeňský 2 Josef Pokorný Železná Ruda Klatovy Plzeňský 3 Antonín Mokrý Zdice Beroun Středočeský 4 Ladislav Lejbl Broumy Beroun Středočeský 5 Jan Novák Beroun Beroun Středočeský 6 Miroslav Růžička Hradec Králové Hradec Králové Hradec Králové 7 Lucie Hesslerová Doksy Kladno Středočeský 8 Jan Malý Doksy Česká Lípa Liberecký

3. normální forma Nové tabulky + rozdělit ID Jméno Příjmení Obec 1 Petr Poupa 1 2 Josef Pokorný 2 3 Antonín Mokrý 3 4 Ladislav Lejbl 4 5 Jan Novák 5 6 Miroslav Růžička 6 7 Lucie Hesslerová 7 8 Jan Malý 8 ID_OBCE Jméno Okres 1 Klatovy KT 2 Železná Ruda KT 3 Antonín BE 4 Ladislav BE 5 Jan BE 6 Miroslav HK 7 Lucie KD 8 Jan CL ID_OKR Název Kraj KT Klatovy Plzeňský BE Beroun Středočeský HK Hradec Králové Královéhradecký KD Kladno Středočeský CL Česká Lípa Liberecký

Boyce/Coddova NF Jedná se o variaci 3.NF v případě, že relace obsahuje více kandidátních klíčů B/C NF lze aplikovat pouze při splnění následujících podmínek: Relace musí mít 2 nebo více KK Nejméně 2 z KK musí být složené KK se v některých atributech musí překrývat

B/C NF - pokračování B/C NF říká, že mezi KK nesmí být žádná funkční závislost Tato relace není v B/C NF!!! Č. dodavatele CD Jméno dodavatele JD Č. výrobku CV Množství M Jednotková cena JC

Př.B/C NF - pokračování Mezi CD a JD je funkční závislost, což je porušením pravidel B/C NF. Správný dat. model: Č. dodavatele CD Jméno dodavatele JD ČD Č. výrobku Množství Jedn. cena

4. normální forma 4.NF říká, že v jedné relaci se nesmí spojovat nezávislé opakované skupiny Vícehodnotové závislosti (tj. vzájemně nezávislé množiny atributů) musíme vyčlenit do samostatné relace Definice 4 NF: Relace je v 4NF, pokud je v B/C NF a navíc všechny vícehodnotové závislosti jsou zároveň funkčními závislostmi z KK

4 NF - příklad Název výrobku Jméno dodavatele Množství v jednotce Siesta ORION 8ks,16ks,32ks Nenormalizovaná relace!! Název výrobku Jméno dodavatele Množství v jednotce Siesta ORION 8ks Siesta ORION 16ks Siesta ORION 32ks Relace v B/C NF. Dvojici vícehodnotové závislosti představují: Název výrobku množství / jméno dodavatele

4.NF řešení příkladu Název výrobku SIESTA SIESTA SIESTA Název výrobku SIESTA STUD. PEČEŤ Množství v jednotce 8ks 16ks 32ks Jméno dodavatele ORION ORION Pozn.:4NF má smysl pouze v případě, když atributy mají více hodnot.

5. normální forma Týká se poměrně vzácného případu spojené závislosti: Spojená závislost vyjadřuje cyklické omezení: Pokud je Entita 1 spojena s Entitou 2, Entita 2 je spojena s Entitou 3 a Entita 3 je spojena zpětně s Entitou 1, pak všechny 3 entity musí být nutně součástí stejného vektoru hodnot.

5 NF - pokračování Př.: Dodavatel dodá Výrobek, Zákazník si objedná Výrobek a Dodavatel dodá něco Zákazníkovi, pak Dodavatel dodává Výrobek Zákazníkovi Dodavatel Výrobek Zákazník Tato relace není v 5 NF!!

5 NF - pokračování Řešením příkladu je rozložení spojené závislosti do tří samostatných relací: DODAVATEL, VÝROBEK VÝROBEK, ZÁKAZNÍK DODAVATEL, ZÁKAZNÍK

Shrnutí - NF Jedná se o strukturu databází z pohledu normalizace procesů Základní princip je odstranění redundance mechanismem bezztrátové dekompozice tzn. dělením relací bez jakékoli ztráty informací

Shrnutí - NF

Procvičení Klíč: (město, podnik) Město Podnik Artikl Písek Jitex Textil Písek Elektropřístroj Elektrické ovl. prvky Mladá Boleslav Škoda Automobily Mladá Boleslav Akuma Akumulátory

Procvičení Není ve 2.NF, neklíčový atribut musí být závislý na celém klíči Město Podnik Podnik Artikl Písek Písek Mladá Boleslav Mladá Boleslav Jitex Elektropřístroj Škoda Akuma Jitex Textil Elektropřístroj Elektrické ovl. prvky Škoda Automobily Akuma Akumulátory

Procvičení Klíč (Os.č.) Os. č. Jmén o Příjme ní Ulice Č.P. Město PSČ Funkce Plat 1 Petr Poupa Krátká 52 Jihlava 58601 CEO 150000 2 Josef Cejnar Slepá 1 Praha 10 11000 Senior Consultant 3 Jiří Mokrý Nová 48 Kladno 27201 Database Designer 4 Pavel Lejbl Stará 88 Pardubice 53001 Junior Developer 5 Petr Malý Uhelná 5 Beroun 26601 Junior Developer 6 Aleš Lex Hlavní 99 Beroun 26601 Senior Consultant 80000 70000 30000 30000 80000

Procvičení Město PSČ Není v 3.NF všechny její neklíčové atributy jsou vzájemně nezávislé Os.č. Jmé no Příjme ní Ulice Č. P. PSČ Funkce Id. f. Jihlava 58601 Praha 10 11000 Kladno 27201 Pardubice 53001 Beroun 26601 Funkce Plat 1 Petr Poupa Krátká 52 58601 1 2 Josef Cejnar Slepá 1 11000 2 3 Jiří Mokrý Nová 48 27201 3 4 Pavel Lejbl Stará 88 53001 4 5 Petr Malý Uheln á 5 26601 4 6 Aleš Lex Hlavní 99 26601 2 1 CEO 150000 2 Senior Consultant 3 Database Designer 4 Junior Developer 80000 70000 30000

Procvičení Klíče: (hodina, učitel), (hodina, místnost) Přednáška Učitel Místnost Hodina DATS Šrotýř K305 8:00 DATS Šrotýř K305 9:45 UITS Derbek K501 13:15

Procvičení Není v 3.BC formě, opakuje se jméno učitele Přednáška Učitel Přednáška Místnost Hodina DATS UITS Šrotýř Derbek DATS K305 8:00 DATS K305 9:45 UITS K501 13:15

Konec