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

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

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

10. blok Logický návrh databáze

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

Databázové systémy 1. Cvičení č. 9. Fakulta elektrotechniky a informatiky Univerzita Pardubice

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

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

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

Konceptuální modelování. Pavel Tyl

4IT218 Databáze. 4IT218 Databáze

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

Databázové systémy trocha teorie

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

Třída. Atributy. Operace

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

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

INFORMAČNÍ SYSTÉM PŮJČOVNY JÍZDNÍCH KOL

Jak začít pracovat s programem BetOptim.exe?

Informační systémy ve zdravotnictví. 8. cvičení

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

2. Konceptuální model dat, E-R konceptuální model

Informační systémy ve zdravotnictví. 6. cvičení

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

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

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

Etapy tvorby lidského díla

Pokročilé schopnosti OOP

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émy. Ing. Radek Holý

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

Zadání úlohy do projektu z předmětu IPP 2013/2014

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

Databázové modelování. Analýza Návrh konceptuálního schématu

Modul EPNO. Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů


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

Západočeská univerzita v Plzni Katedra informatiky a výpočetní techniky. 9. června krovacek@students.zcu.cz

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

Elektronická dokumentace - LATEX. Maticové operace

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

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

Informační systémy ve zdravotnictví. 10. cvičení

KIV/PIA Semestrální práce

NÁVRH A REALIZACE WWW PREZENTACE ČKR

Informační systém pro nemocnici

DATOVÉ MODELOVÁNÍ ER MODEL

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

Potenciál datových schránek pro rozvoj e-governmentu v České republice

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

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

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

Univerzita Pardubice. Fakulta elektrotechniky a informatiky SEMESTRÁLNÍ PRÁCE PRO PŘEDMĚT IDAS2

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

TouchGuard Online pochůzkový systém

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

Uživatelem řízená navigace v univerzitním informačním systému

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

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

Prohlášení ú astníka výb rového ízení k výb rovému ízení ís. SBN/020/2015

Objektově relační databáze a ORACLE 8

Databázové a informační systémy Informační systém prodejny nábytku. Jakub Kamrla, KAM087

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

DBS Konceptuální modelování

Úvod do databázových systémů 2012/2013 IS MHD. Jiří Znoj zno

PV167 Projekt z obj. návrhu IS. 26. března 2008

Úvod do PHP s přihlédnutím k MySQL

Úvod do softwarového inženýrství IUS 2009/2010 p.1/30

DATABÁZOVÉ SYSTÉMY MYSQL. Sestavil Mgr. Jan Kubrický. Distanční opora Poslední úprava:

VII. DOHODY O PRACÍCH KONANÝCH MIMO PRACOVNÍ POMĚR

Validační pravidla NRKN

RELAČNÍ DATABÁZOVÉ SYSTÉMY

KIV/ZIS cvičení 1. Martin Kryl

Zadání. Seznam typů entit včetně jejich atributů, vyznačte klíče a cizí klíče Seznam typů vztahu určený svým názvem a entitami do něj vstupujícími

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky

Oborové číslo Hodnocení - část A Hodnocení - část B Hodnocení - část A+B

Příklady a návody. Databázová vrstva

IS Autopůjčovna VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA INFORMAČNÍ SYSTÉMY A DATOVÉ SKLADY. (semestrální projekt) ZS

30. března Je možné dle analýzy implementovat systém tak, aby splňoval požadavky zadavatele?

Kolaborativní aplikace

Aukční síň VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA INFORMAČNÍ SYSTÉMY A DATOVÉ SKLADY. (semestrální projekt) ZS

ISPOP 2016 MANUÁL K VYPLNĚNÍ FORMULÁŘŮ PRO OHLAŠOVÁNÍ ÚDAJŮ PRO VODNÍ BILANCI

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Návrh a tvorba databáze v prostředí vybrané firmy

Relační databáze a povaha dat

A5M33IZS Informační a znalostní systémy. O čem předmět bude? Úvod do problematiky databázových systémů

7.3 Diagramy tříd - základy

Uživatelská příručka + základní informace o IS o ISVS

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

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Relace x vztah (relationship)

Diagram výskytů a vztahů

Dokumentace k 5. iteraci

Projekt z předmětu Teorie zpracování dat

Příloha č. 1 Smlouvy o spolupráci B2B rozhraní VZP ČR

Analýza a modelování dat. Přednáška 4

Vícetabulková databáze. Vztahy mezi tabulkami

E-ZAK, verze M-2 jednoduchý elektronický nástroj pro veřejné zakázky

MANUÁL MOBILNÍ APLIKACE GOLEM PRO OPERAČNÍ SYSTÉM ANDROID 4.X A VYŠŠÍ

KAPITOLA 3. Architektura aplikací na frameworku Rails. V této kapitole: modely, pohledy, řadiče.

Minebot manuál (v 1.2)

Digitální mapa veřejné správy (DMVS) Ústeckého kraje část Nástroje pro tvorbu a údržbu Územně analytických podkladů

Transkript:

Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 7 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014

Modelování databází

Modelování databází Zadání Konceptuální model Datový model Vytvoření databáze Konceptuální model v této fázi zatím nemusíme uvažovat o implementaci nějaké databáze. Zkrátka snažíme se zachytit statický pohled na reálnou situaci. Datový model modelujeme databázi a máme jasno, zda budeme používat tabulky, XML, objekty nebo jinou organizaci dat. Relační datový model nejběžnější, používáme tabulky XML v určitých případech lépe modeluje reálnou situaci Objektový datový model využívá výhody OOP jako např. dědičnost

Konceptuální datový model Konceptuální datový model

Entita, entitní typ Relační datový model Konceptuální model Záznam popisuje konkrétní výskyt objektu Entita konkrétní objekt reálného světa např. Jan Novák narozen 1.1.1990 Schéma relace popisuje množinu záznamů se stejnými atributy Entitní typ popis množiny entit se stejnými atributy. Používáme lineární zápis. např. Osoba (rc, jmeno, prijmeni, datum_narozeni)

Klíč Relační datový model Konceptuální model Primární klíč atribut nebo více atributů, jejichž hodnota nebo kombinace hodnot je pro každý záznam jedinečná Klíč jeden nebo více atributů, které jednoznačně identifikují entitu v množině entit Cizí klíč atribut odkazující se na primární klíč Na úrovni konceptuálního modelu nepoužíváme cizí klíč, vše zaznamenávají vztahy samy o sobě (viz dále)

Cizí klíč a konceptuální model V konceptuální modelu neuvádíme cizí klíče! Proč? Představme si na chvíli, že bychom místo relačního datového modelu použili XML. <osoba> <id>1</id> <jmeno>karel</jmeno> <email>karel@gmail.com</email> <email>karel@seznam.cz</email> <email>karel@vsb.cz</email> </osoba> Mezi osobou a emailem je vztah 1:N. Musíme u mailu dodatečně psát, že se vztahuje k osobě s určitým id?

Konceptuální model Pro znázornění konceptuálního modelu používáme nejčastěji E-R diagramy a lineární zápisy. E-R diagramy tedy můžeme používat jak pro konceptuální, tak pro relační datový model. Proto se často setkáme s požadvkem 2 úrovní E-R diagramu.

Vztahy Vztah vyjadřuje fyzickou nebo konceptuální vazbu mezi entitami, resp. entitními typy. Každý vztah by měl být pojmenovaný Nejčastěji se setkáváme s binárními vztahy Vztahy zaznačujeme E-R diagramem nebo lineárním zápisem Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddělení id_oddeleni nazev popis PRACUJE_V (Osoba, Firma)

Vztahy Oddělení Zaměstnanec Objednávka Výrobek Kategorie výrobku Položka objednávky

Vztahy Oddělení Zaměstnanec Objednávka Výrobek Kategorie výrobku Položka objednávky Např: PRACUJE_V (Zaměstnanec, Oddělení) OBSAHUJE (Objednávka, Položka objednávky) ZALOZIL (Zaměstnanec, Objednávka) JE_V_KATEGORII (Výrobek, Kategorie výrobku) JE_NADRIZENYM (Zaměstnanec, Zaměstnanec) JE_NA_POLOZCE (Výrobek, Položka objednávky)

Kardinalita vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni Oddeleni id_oddeleni nazev popis

Kardinalita vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni Oddeleni id_oddeleni nazev popis Jde jednoduše o určení, zda se jedná o vztah 1:1, 1:N nebo M:N. Jaká bude kardinalita vztahu na obrázku?

Kardinalita vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni Oddeleni id_oddeleni nazev popis 1:1 1:N M:N

Kardinalita vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni JE_VEDOUCIM Oddeleni id_oddeleni nazev popis 1:1 Zaměstnanec může být vedoucím jednoho oddělení, oddělení má jednoho vedoucího. 1:N M:N

Kardinalita vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis 1:1 Zaměstnanec může být vedoucím jednoho oddělení, oddělení má jednoho vedoucího. 1:N Jedno oddělení má více zaměstnanců. Každý zaměstnanec pracuje v jednom oddělení. M:N

Kardinalita vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis 1:1 Zaměstnanec může být vedoucím jednoho oddělení, oddělení má jednoho vedoucího. 1:N Jedno oddělení má více zaměstnanců. Každý zaměstnanec pracuje v jednom oddělení. M:N Jedno oddělení má více zaměstnanců, jeden zaměstnanec může pracovat ve více odděleních.

Povinnost ve vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis Musí každý zaměstnanec pracovat v nějakém oddělení? Musí mít každé oddělení nějakého zaměstnance?

Povinnost ve vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis Zaměstnanec nemusí být v oddělení a oddělení nemusí mít zaměstnance. Zaměstnanec musí pracovat v oddělení, ale oddělení nemusí mít zaměstnance. Zaměstnanec nemusí být v oddělení, ale oddělení musí mít zaměstnance. Zaměstnanec musí být v oddělení a oddělení musí mít zaměstnance.

Povinnost ve vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis Zaměstnanec nemusí být v oddělení a oddělení nemusí mít zaměstnance. Zaměstnanec musí pracovat v oddělení, ale oddělení nemusí mít zaměstnance. Zaměstnanec nemusí být v oddělení, ale oddělení musí mít zaměstnance. Zaměstnanec musí být v oddělení a oddělení musí mít zaměstnance.

Povinnost ve vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis Zaměstnanec nemusí být v oddělení a oddělení nemusí mít zaměstnance. Zaměstnanec musí pracovat v oddělení, ale oddělení nemusí mít zaměstnance. Zaměstnanec nemusí být v oddělení, ale oddělení musí mít zaměstnance. Zaměstnanec musí být v oddělení a oddělení musí mít zaměstnance.

Povinnost ve vztahu Zamestnanec id_zamestnance jmeno prijmeni datum_narozeni PRACUJE_V Oddeleni id_oddeleni nazev popis Zaměstnanec nemusí být v oddělení a oddělení nemusí mít zaměstnance. Zaměstnanec musí pracovat v oddělení, ale oddělení nemusí mít zaměstnance. Zaměstnanec nemusí být v oddělení, ale oddělení musí mít zaměstnance. Zaměstnanec musí být v oddělení a oddělení musí mít zaměstnance.

Slabý entitní typ a identifikující vztah Silné entitní typy se vyznačují tím, že mají svůj vlastní klíčový atribut (popř. více atributů), který je identifikuje. Slabé entitní typy naopak nemají vlastní atribut, který by je identifikoval. Obvykle vyjadřují objekty reálného světa, které nemohou existovat bez jiného nadřízeného objektu jejich samostatná existence nedává smysl.

Slabý entitní typ a identifikující vztah Objednavka idobj cislo_obj datum_vytvoreni PolozkaObjednavky poradi produkt mnozstvi

Slabý entitní typ a identifikující vztah Objednavka idobj cislo_obj datum_vytvoreni PolozkaObjednavky poradi produkt mnozstvi Položka objednávky nemá vlastní klíčový atribut. Je identifikována klíčem z objednávky a pořadovým číslem. Jedná se tedy o slabý entitní typ. Klíč položky objednávky je složený z odobj a poradi. Cizí klíče nezakreslujeme do konceptuálního modelu, takže poradi idobj nemůže být součástí položky objednávky. Proto používáme tzv. identifikující vztah, který zajistí, že součástí klíče položky objednávky bude kromě pořadí také id objednávky, přestože id objednávky není součástí položky.

Shrnutí Entita Entitní typ Klíč Vztah Kardinalita vztahu Povinnost ve vztahu Slabý entitní typ Identifikující vztah

Shrnutí Entita Objekt reálného světa Entitní typ Označení celé třídy objektů reálného světa Klíč Atribut nebo více atributů, které jednoznačně identifikují entitu Vztah Fyzická nebo konceptuální vazba mezi entitami Kardinalita vztahu 1:1, 1:N, M:N Povinnost ve vztahu Pro každý (binární) vztah máme celkem 4 možnosti Slabý entitní typ Klíč je složen z atributů, které nejsou jeho součástí Identifikující vztah Zajistí, aby se klíč z nadřazeného entitního typu stal součástí klíče slabého entitního typu

Cvičení www.dbedu.cs.vsb.cz Přihlášení přes jednotný login a heslo Vpravo sloupec -> České kurzy -> UDBS