Databáze 2011/2012. Logický model DB. RNDr.David Hoksza, Ph.D.

Podobné dokumenty
Databáze. Logický model DB. David Hoksza

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

Databáze 2011/2012 SQL SELECT II. RNDr.David Hoksza, Ph.D.

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

4 Datový typ, proměnné, literály, konstanty, výrazy, operátory, příkazy

Databáze 2011/2012 T-SQL - kurzory, funkce. RNDr.David Hoksza, Ph.D.

ZŠ ÚnO, Bratří Čapků 1332

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D.

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

Helios Orange Plugin Zadávání vlastností

GLOBÁLNÍ ARCHITEKTURA ROB

Databáze 2011/2012. Optimalizace, základní konstrukty T-SQL RNDr.David Hoksza, Ph.D.

Databázové systémy. Tomáš Skopal. - úvod do relačního modelu. - převod konceptuálního schématu do relačního

Design databáze. MI-DSP 2013/14 RNDr. Ondřej Zýka,

Práce s WKT řetězci v MarushkaDesignu

Databázové patterny Profinit. All rights reserved.

Sledování provedených změn v programu SAS

Databázové systémy Tomáš Skopal

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

Databáze. Optimalizace, základní konstrukty T-SQL David Hoksza

1. Databázové systémy, definice, struktura

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

Podklady k práci s Intranetem - administrátor

Konceptuální modelování. Pavel Tyl

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

Vykreslení obrázku z databázového sloupce na referenční bod geometrie

Integrace dat Profinit. All rights reserved.

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

Simulátor krizových procesů na úrovni krizového štábu. Systémová dokumentace

Design databáze. NDBI /14 RNDr. Ondřej Zýka,

ZŠ ÚnO, Bratří Čapků 1332

Dotaz typu Common Info v MarushkaDesignu

Základní mechanizmy UML

DBS Normální formy, normalizace

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

Základní škola Valašské Meziříčí, Vyhlídka 380, okres Vsetín, příspěvková organizace

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

Informační ikony v MarushkaDesignu

NORMALIZACE Část 2 1

Metadata Profinit. All rights reserved.

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

Tile systém v Marushka Designu

MS Word pro administrátory projektů Základy

Vizualizace TIN (trojúhelníková nepravidelná síť) v Marushka Designu

Databázové systémy BIK-DBS

30. výzva Ministerstva životního prostředí

Případy užití RSSystems

5. Formalizace návrhu databáze

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

Jak zavést systém managementu kvality

Relace x vztah (relationship)

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

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

- Aplikace je napsána v C#.NET, je instalována na webovém serveru - Data jsou ukládána v databázi MS-SQL 2005 a vyšší

VIS ČAK - Uživatelský manuál - OnLine semináře

Plánování směn verze 2.1, revize 03

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

Databázové systémy I. - II. 2009/2010

Organizační řád Občanského sdružení NHfree.net

3.5.1 Shodná zobrazení

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

Generování Homepage ze serveru AReality.sk

5. Formalizace návrhu databáze

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

Datové typy. $PROG 1 Str. 1/5

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

Provozní řád služby zálohování CIT

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

Spisová služba/elisa - Dodatek k manuálu - subverze 1.28

Návod k vyplňování formulářů - vyúčtování

Uživatelská příručka aplikace Partner24 modul Zaměstnavatelský portál Česká spořitelna penzijní společnost, a.s.

Teplota a její měření

1.3. Požárně bezpečnostní řešení

HTML šablona v MarushkaDesignu

Datová kvalita Profinit. All rights reserved.

IPS1 zápočtový test na fei-learnu

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM Č. III ZE DNE

DBS Transformace konceptuálního schématu na

Zpráva z testování 7.ročníků ZŠ v rámci projektu Rozvoj a podpora kvality ve vzdělávání

Transakce Profinit. All rights reserved.

SPARTAN DAIRY 3.0. Uživatelský manuál. Vytvořeno s podporou Interní vzdělávací agentury projekt č. 2017FVHE/2220/47 VFU BRNO

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

Vkládání dat do databázové aplikace

F O R M Á L N Í P O Ž AD AV K Y N A B AK AL ÁŘSKÉ PRÁCE

RELAČNÍ DATABÁZOVÉ SYSTÉMY

Eda. Evidence obchodních aktivit. Proces nákupu

DBS Konceptuální modelování

se sídlem Purkyňova 125, Brno , IČ: , DIČ: CZ , tel.: , Znalecký posudek

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

Teorie elektronických obvodů (MTEO)

C8 Relační databáze. 1. Datový model

Portál veřejné správy

UNIVERZITA PALACKÉHO V OLOMOUCI

Legenda v MarushkaDesignu

Zpráva pro uživatele

Mimořádná účetní uzávěrka

Instalace a technické informace

Veřejná zakázka SUSEN generální dodávka staveb v areálu Řež. Dodatečná informace č. 1 k zadávacím podmínkám

NET Genium. Příručka administrátora

INFORMACE O NOVÉ VERZI POSKI REAL

Transkript:

Databáze 2011/2012 Lgický mdel DB RNDr.David Hksza, Ph.D. http://siret.cz/hksza

Osnva Relační mdel dat Převd knceptuálníh schématu d lgickéh Funkční závislsti Nrmalizace schématu Cvičení převd d relačníh mdelu

Relační lgický mdel (nefrmálně) 1974 - E. F. Cdd reprezentace bjektů knceptuálníh schématu pmcí tabulek (relací) entitní (vztahvý) typ tabulka atribut slupec entita (vztah) řádek tabulky schéma tabulky T(S 1 :T 1,, S n :T n ) T = tabulka, S i = slupec i, T i = datvý typ slupce i schéma DB schémata všech tabulek v DB + případná integritní mezení

Relační mdel (nefrmálně) Neexistují 2 stejné řádky, tj. každá tabulka má jednznačný identifikátr Relační mdel nezná pjem NULL hdnty lze zavést metadhntu NULL Mnžina slupců jednznačně identifikující řádky tabulky se nazývá nadklíč Nadklíč s nejmenším pčtem slupců se nazývá klíč klíčů může být více Mnžinu slupců, které jsu klíčem v jiné tabulce nazýváme cizí klíč realizace vatahů mezi entitami

Relační mdel (frmálně) relace v algebře R D 1 x D 2 x x D n databázvé rzšíření pjmu relace R(A 1 :D 1,, A n :D n ) zjedndušeně R(A 1,, A n ) frmální vs. nefrmální schéma relace schéma tabulky relace tabulka (data) dména datvý typ slupce prvek relace řádek tabulky dále budeme pužívat zjedndušený relační mdel k ppisu principů převdu knceptuálníh schématu d relačníh

Cizí klíč - princip autmbil(spz:string, majitel:string, rk_vyrby:integer, znacka:string) spz majitel rk_vyrby znacka 1A3 3040 Petr Nvák 1980 Frd ANE 0689 Aleš Vmáčka 2005 Hnda 1T8 1230 Jsef Nvtný 2000 Hnda 2B1 3491 Karel Vdrážka 2005 Škda znacka Frd Hnda Škda zeme USA JP CZ vyrbce(znacka:string, zeme:string) klíč cizí klíč

Převd kardinalita 1:1 V 1:1 kardinalitě může libvlný z klíčů účastnících se entit být klíčem výslednéh relačníh schématu linkaridic(cisl, start, cil,, id, jmen, rk_narzeni, ) linka(cisl, start, cil,, id), Při nepvinné účasti je třeba zvláštní relaci pr řidiče, který ve vztahu být nemusí ridic(id, jmen, rk_narzeni, )

Převd kardinalita 1:1 linka(cisl, start, cil, ) linkaridic(cisl, id) ridic(id, jmen, rk_narzeni, ) Při nepvinné účasti bu entit je třeba vytvřit nvu relaci, prtže každý bjekt v jedné entitě může existvat nezávisle na bjektu v entitě druhé Prtže jsu kardinality na bu stranách 1, tvří každý z cizích klíčů ve spjvací relaci klíč v tét relaci

Převd kardinalita 1:N linka(cisl, start, cil, ) Kardinalitu N zajišťuje cizí klíč cisl v relaci ridic, kde nehraje rli klíče (atribut není pdtržen), na rzdíl d (0,1):(1,1) situace ridic(id, jmen, rk_narzeni, cisl) Parcialitu na N straně nejsme schpni v základním relačním mdelu zajistit, prt ke 2 ER schématům máme 1 relační schéma

Převd kardinalita 1:N linka(cisl, start, cil, ) linkaridic(cisl, id) ridic(id, jmen, rk_narzeni) Parcialitu na 1 straně zajistíme vlžením spjvací relace, která bude mít id jak klíč. Výsledek je pdbný jak (0:1):(0:1) až na nejednznačnst atributu cisl ve spjvací relaci Parcialitu na N straně nejsme schpni v základním relačním mdelu zajistit, prt ke 2 ER schématům máme 1 relační schéma

Převd kardinalita M:N linka(cisl, start, cil, ) linkaridic(cisl, id) ridic(id, jmen, rk_narzeni) Ve vztahu M:N nejsme schpni v relačním mdelu zajistit parcialitu, nebť každý bjekt jedné entity muže být ve vztahu s více bjekty druhé entity nutnst spjvací relace Klíčem ve spjvací relaci nemůže být ani jeden z cizích klíčů, nýbrž klíč musí tvřit ba cizí klíče najednu

Funkční závislst př. funkční závislst určuje sémantické vztahy mezi atributy značení čtení RC JMENO Rdné čísl funkčně určuje jmén RČ JMENO 870226/5385 Karel Vmáčka 890610/1182 David Mikeš 880906/5595 Jan Nvák 870226/5385 Patrik Nvý význam Ke každému RČ existuje nejvýše jedn jmén = Neexistují 2 záznamy v tabulce řidič se stejným RČ, ale různým jménem

Funkční závislst př. značení {START, CIL} CISLO čtení Start a cíl funkčně určuje čísl CISLO START CIL 106 Kavkazská Nádraží Braník 203 Kačerv Vavřenva 308 Kavkazská Nádraží Braník 205 Zemanka Kmřany význam Ke každému startu a cíli existuje nejvýše jedn čísl = Neexistují 2 záznamy v tabulce linka se stejným startem a cílem, ale různým číslem

Funkční závislst frmálně Funkční závislst (FZ) je funkce mezi dménami atributů FZ je typem integritníh mezení, tj. vymezuje jaká data mhu být v DB ulžena, případně vymezuje vztahy mezi nimi Definice: Funkční závislst (FZ) X Y nad schématem R(A) je parciální zbrazení f i : X i Y i, kde X i,y i A (kde i = 1..pčet závislstí pr R(A)). Říkáme že n- tice z X i funkčně určuje m-tici z Y i a že m-tice z Y i funkčně závisí na n-tici z X i

Funkční závislst a relační mdel relační mdel lze rzšířit tak, aby byl mžné v něm uchvávat infrmace závislstech, tj. u relace nebudeme uchvávat puze seznam atributů, ale i funkční závislsti mezi nimi R(A, F), kde F = i {f i } nadklíč relace NK NK A klíč relace K K A K 1 : K 1 K klíčvý atribut atribut z A, který je sučástí nějakéh klíče (klíčů může být více) neklíčvý atribut atribut z A, který není sučástí žádnéh klíče

Návrh funkčních závislstí mdelvání funkčních závislstí spadá d prcesu funkční analýzy, tj. je třeba jej učinit ještě před vkládáním dat. T plyne i z faktu, že se jedná IO, tedy mezuje mžné vstupy není mžné FZ dvzvat ze stávajících dat, nýbrž z přirzených vztahů mezi atributy ID JMENO 1 Petr Malý 2 Jan Vstrý 3 Aleš Nvý 4 Petr Berka NAJETE_K M_ZA_ME SIC ODPRAC OVANO_ LET PLAT 412 20 18000 48 654 10 19000 35 412 20 18000 44 128 15 17000 50 VEK ID ALL JMENO ALL NJKZM OL OL NJKZM {NJKZM, OL} PLAT VEK VSE ne vše, c vidíme v datech becně platí

Aktualizační anmálie mějme relaci AUTOBUS(SPZ, NAJETO,, SOUCASTKA, VYROBCE_SOUCASTKY, ) sučástky uchváváme v relaci s autbusy, tj. má-li autbus 20 sučástek, máme 20 prvků relace v tabulce autbus pr jeden autbus příklady aktualizačních anmálií změna infrmace knkrétním autbusu vyžaduje vícenásbné prvedení tét změny chceme-li dstranit jeden autbus z DB, je třeba t učinit na více místech není-li sučástka pužita v žádném autbusu, infrmaci ní ztrácíme nelze přidat sučástku d DB, aniž by nebyla pužita v nějakém autbuse

Nrmalizace schématu Nrmalizaci lze zajisti dekmpzicí tak, aby výsledné schéma splňval pžadavky dané nrmální frmy 1NF zajišťuje nestrukturvanst dat 2NF a 3NF mezují redundanci dat, tj. nutí uživatele dekmpnvat schéma Další NF, které nejsu v praxi čast využívány BCNF 4NF 5NF Výhdy Snížení redundance dat menší prstrvé nárky Jedndušší aktualizace dat Zabránění aktualizačním anmáliím Nevýhdy Zpmalení kmplexních dtazů

1NF 1. tabulka musí reprezentvat relaci v algebraickém smyslu atributy vnitřně nestrukturvané (žádné vnřené tabulky, neb slžené datvé typy, tj. jak dmény je třeba užít základní datvé typy) 2. neexistence pakujících se skupin sba(id:integer, jmen:string, datum_narzeni:date, pdrizeni:sba[]) sba(id:integer, jmen:string, datum_narzeni:date) sbasba(id_pd:integer, id_nad:integer) sba(id:integer, jmen:string, datum_narzeni:date, tel1:string, tel2:string, tel3:string) sba(id:integer, jmen:string, datum_narzeni:date) sbatelefn(cisl:string, id_sba:integer) 1NF dpruje i situace, kdy je pr telefn pužit jeden slupec typu string, kde jsu telefny dděleny delimitrem

2NF v DB se nesmí vyskytvat závislst neklíčvéh atributu NK na vlastní pdmnžině některéh klíče K KK K: KK NK JMENO C_ZIDLE BUDOVA ADRESA PLAT Jan Vdnář 58 A Technická 5, Praha 24000 Petr Nvtný 58 B Technická 3, Praha 20000 Karel Klář 2 A Technická 5, Praha 18000 Patrik Nvý 23 C Studentská 1, Praha 35000 Aleš Výmla 45 B Technická 3, Praha 28000 {C_ZIDLE,BUDOVA} ALL, BUDOVA ADRESA redundance adresy není v 2NF

2NF - dekmpzice JMENO C_ZIDLE BUDOVA PLAT Jan Vdnář 58 A 24000 Petr Nvtný 58 B 20000 Karel Klář 2 A 18000 Patrik Nvý 23 C 35000 Aleš Výmla 45 B 28000 {C_ZIDLE,BUDOVA} ALL 2NF BUDOVA ADRESA A Technická 5, Praha B Technická 3, Praha C Studentská 1, Praha BUDOVA ADRESA 2NF

3NF v DB se nesmí vystkytnut tranzitivní závislst na klíči K A, B: K A B JMENO PSC MESTO PLAT Jan Vdnář 14200 Praha 24000 Petr Nvtný 10100 Praha 20000 Karel Klář 60200 Brn 18000 Patrik Nvý 66434 Kuřim 35000 Aleš Výmla 63900 Brn 28000 JMENO VSE, PSC MESTO JMENO PSC MESTO reundance města není v 3NF může být prblematické, když k se rzhdneme uchvávat další infrmace městě, např. pčet byvatel

3NF dekmpzice JMENO PSC PLAT Jan Vdnář 14200 24000 Petr Nvtný 10100 20000 Karel Klář 60200 18000 Patrik Nvý 66434 35000 Aleš Výmla 63900 28000 JMENO ALL 3NF PSC MESTO 14200 Praha 10100 Praha 60200 Brn 66434 Kuřim 63900 Brn PSC MESTO 3NF