Návrh datového modelu

Podobné dokumenty
Databázové systémy I. 3. přednáška

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

Návrh datového modelu

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. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal

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

DBS Konceptuální modelování

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

Transformace konceptuálního modelu na relační

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

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

Databáze. Logický model DB. David Hoksza

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ázové systémy Cvičení 5.2

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

Konceptuální modelování. Pavel Tyl

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í

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

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS

DBS Transformace konceptuálního schématu na

Databázové systémy trocha teorie

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

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

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

A5M33IZS Informační a znalostní systémy. Relační databázová technologie

DUM 12 téma: Příkazy pro tvorbu databáze

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

Návrh databázového modelu

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

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

Relace x vztah (relationship)

Konceptuální modelování a SQL

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

Mendelova univerzita v Brně Provozně ekonomická fakulta. Síť hotelů. Databázové systémy I

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL

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

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

RELAČNÍ DATABÁZOVÉ SYSTÉMY

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:

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

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

Konceptuální datové modely používané při analýze

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

Funkční schéma Datové schéma Integrita modelu s realitou

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

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

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

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.

Terminologie v relačním modelu

Relační DB struktury sloužící k optimalizaci dotazů - indexy, clustery, indexem organizované tabulky

5. POČÍTAČOVÉ CVIČENÍ

Relační databázová technologie

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

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

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

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

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

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

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Úvod do databázových systémů 2012/2013 IS MHD

Databázové systémy. Cvičení 6: SQL

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

4IT218 Databáze. 4IT218 Databáze

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

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

7. Integrita a bezpečnost dat v DBS

7. Integrita a bezpečnost dat v DBS

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc.

Transformace ER SQL. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, P edn. 9

Databázové systémy I

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

5. Formalizace návrhu databáze

5. Formalizace návrhu databáze

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

Návrh a tvorba WWW stránek 1/14. PHP a databáze

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) 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

Pokročilé typové úlohy a scénáře 2006 UOMO 71

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

DBS Konceptuální modelování

Úvod do databázových systémů. Ing. Jan Šudřich

Otázka č. 1 (bodů za otázku: 4)

Modelový příklad Knihovna Vypracovaný příklad ze cvičení včetně komentářů k řešení

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

DATOVÉ MODELOVÁNÍ ER MODEL

Databázové systémy a SQL

Databázové systémy BIK-DBS

Kapitola 6: Omezení integrity. Omezení domény

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

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

Integritní omezení (IO)

Hierarchický databázový model

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM

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

10. blok Logický návrh databáze

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

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

Administrace Oracle. Práva a role, audit

Diagram výskytů a vztahů

2 Konceptuální modelování a návrh databáze

Konceptuální modelování

Transkript:

Návrh datového modelu

Co nás dnes čeká Pohledy na data Konceptuální datové modelování Entitně-relační schéma Prvky E-R schématu, konvence Maticové diagramy a ERDish věty Pokročilé prostředky E-R diagramů Převod do fyzického modelu DDL operace

Schéma databáze Výsledkem databázového modelování není model, ale schéma databáze V obecné rovině lze uvádět 3 pohledy na data Vnější pohled aplikační úroveň Konceptuální schéma logika modelu Fyzické schéma vlastní uložení dat Pro datové modelování je nutné pochopit a rozpoznat informace, to jak věci fungují

Konceptuální model To, jak by to mohlo fungovat, lze nazvat konceptuálním modelem Vlastní implementace je pak fyzický model Co je konceptuální model přesněji: Orientovaný na objekty (entity a vztahy mezi nimi) Neřeší vlastní implementaci Pokrývá současné potřeby s možností dalšího rozvoje Výsledkem aplikace konceptuálního modelu je konceptuální schéma

Konceptuální modelování Přesně popisuje potřeby uchování dat Podporuje diskusi komunikaci, předchází chybám a nedorozuměním Definuje výchozí dokumentaci ideálního systému de facto standardem pro jeho použití jsou Entitně Relační Diagramy (ERD)

Fyzický model databáze Vlastní návrh implementace v konkrétním databázovém systému Obsahuje Tabulky, Struktury objektů a Integritní omezení Studuje (Kód_studenta: Int, Kód_Předmětu: Int)

Integritní omezení Jsou definována na konceptuální i fyzické úrovni Vymezují korektní databázi Umožňují vkládat pouze data, která vyhovují předem definovaným kritériím Např. Kód_studenta jednoznačně identifikuje jednotlivé záznamy tabulky Student, Kód_Předmětu určuje jednotlivé záznamy tabulky Předmět

Entity Představují objekty/osoby/věci, o kterých je třeba uchovávat informace zaznamenávané podle skutečnosti Pojmenování souboru několika podobných objektů Lze přirovnat ke třídám objektů stejného typu FILM, ZÁKAZNÍK, ZAMĚSTNANEC, ZVÍŘE Instance je jeden případ výskytu entity

Entity Instance OSOBA VÝROBEK TYP VÝROBKU ZAMĚSTNÁNÍ KONCERT AUTO Larry Ellison Pilsner Urquell Pivo Popelář Umakart v Roxy Porsche

Atributy Blíže popisují vlastnosti entit i vztahů Kvantifikují příslušnou entitu Kvalifikují příslušnou entity Zařazují a zpřesňují příslušnou entitu Nabývají hodnot z dané domény Je jím právě jedna hodnota, číslo, řetězec znaků, datum, obrázek, zvuk,... příslušného datového typu Integritní omezení jsou pak přídavná pravidla pro zajištění souladu modelu s modelovanou realitou

Atributy příklad OSOBA jméno příjmení datum narození pohlaví e-mail řetězec obsahující písmena řetězec obsahující písmena datum muž nebo žena řetězec v určitém formátu

Identifikátory Co je to UID Atribut nebo kombinace atributů jednoznačně odlišující jednu instanci od ostatních Jedinečný identifikátor právě jedné instance Složený identifikátor Kombinace více atributů, když jeden atribut k identifikaci nestačí Např. název ulice jednoznačně neidentifikuje konkrétní ulici, protože ulice se stejným názvem může být ve dvou různých městech. Ulice + Město už jednoznačná informace je. Lístek na koncert, jízdenka na SC vlak,...

Umělý a druhotný identifikátor Umělý identifikátor V situacích, kde není možné použít žádný z atributů, ani jejich kombinaci Vhodné pro identifikaci osob, RČ nemusí být vždy ideální. Můžeme identifikovat studenta jménem a příjmením? Z důvodu efektivity to bývá zpravidla celé číslo Druhotný identifikátor V situacích, kdy máme víc možností UID Např. nakupujete přes ebay? Identifikace přes e-mail, ale i uživatelské číslo Další kandidáti na UID jsou druhotné identifikátory OBUV * barva * velikost * materiál * styl ZÁKAZNÍK # ID (#) e-mail * jméno * příjmení

Vztahy Představují propojení jednotlivých entit Vždy existují mezi dvěma entitami (entita může mít i vztah sama se sebou) Vztahy jsou vždy pojmenovány na obou svých stranách STUDENT (entita) STUDUJE (vztah) PŘEDMĚT (entita) a PŘEDMĚT (entita) JE STUDOVÁN (vztah) STUDENTEM (entita)

Povinnost, neboli členství Povinnost je determinována na základě instancí příslušných entit Povinné členství = všechny výskyty členské entity musí být zapojeny do nějakého výskytu vztahu Nepovinné členství = jednotlivé výskyty členské entity mohou být zapojeny do nějakého výskytu vztahu Stanovuje se na základě vhodných otázek, např. Musí mít každý zaměstnanec práci/funkci? Musí být úkol splněn nějakým zaměstnancem?

Příklad členství Každý zaměstnanec MUSÍ pracovat v oddělení. Každé oddělení MUSÍ zaměstnávat zaměstnance. Každý sudí MŮŽE rozhodovat utkání. Každému utkání MUSÍ být přiřazen sudí. oddělení

Kardinalita Popisuje, kolikrát se každá instance dané entity může účastnit daného typu vazby Např. jeden konkrétní student může studovat několik předmětů a jeden předmět může být studován několika studenty Rozlišujeme 3 druhy násobností: 1:1, 1:N M:N Vazby M:N jsou později dekomponovány na tzv. průnikový typ entity, neboli asociační entitu, protože je nelze realizovat v relační databázi

Entity a členství Entity zapisujme jako obdélníky se jménem v jednotném čísle psaným velkými písmeny Povinné atributy značíme * Volitelné Unikátní identifikátory označujeme #

Vztahy Vztahy kreslíme jako linie spojující entity Linie mohou být čárkované (nepovinnost) nebo plné (povinnost) Tzv. vidlice ( ) představuje násobnost

Maticové diagramy Způsob pro identifikaci vztahů mezi entitami Jsou velmi vhodné zejména pro rozsáhlejší schémata Nepokrývají povinnosti ani násobnosti vazeb

Maticové diagramy - příklad Mějme následující entity zákazník, země, památka a následující zadání: "Pracuji pro cestovní kanceláře. Uchovávám záznam ze zemí, které naši zákazníci navštívili a památek, které zákaznici viděli v každé zemi. Pomáhá nám přizpůsobit nabízené výlety." zákazník země památka zákazník země památka

zákazník země památka zákazník navštívil viděl země památka byla navštívena byla shlédnuta se nachází v má Maticové diagramy

ERDish Popis vztahů mezi entitami ve slovním vyjádření Pomáhá pro správné pochopení modelované úlohy i lidem mimo oblast IT Preventivní zamezení chyb

Jak na ERDish? Části ERDish vět: 1. Každý 2. Entita A 3. Členství (může/musí) 4. Jméno vazby 5. Kardinalita 6. Entita B a také opačným směrem

Jak na ERDish? ZAMĚSTNANEC pracuje v zaměstnává ODDĚLENÍ Každý zaměstnanec (entita) musí (plná čára) pracovat v (jméno vazby) v právě jednom (jednoduchá čára) oddělení (název entity).

Jak na ERDish? ZAMĚSTNANEC pracuje v zaměstnává ODDĚLENÍ Každé oddělení (entita) může (přerušovaná čára) zaměstnávat (jméno vazby) jednoho nebo více (vidlice) zaměstnanců (název entity).

ERDish Po přepsání: Každý ZAMĚSTNANEC (entita A) musí pracovat v právě jednom ODDĚLENÍ (entita B). Každé ODDĚLENÍ (entita B) může zaměstnávat jednoho nebo více ZAMĚSTNANCŮ (entita A).

Postup E-R modelování Seznam entit Určení atributů (* povinné/ o volitelné/ # unikátní) Matice vazeb ERDish Konceptuální model (ER Diagram) Doplnění integritních omezení

Vytvořte ERD pro následující problém Firma má své zázemí v několika budovách. Budovy jsou vždy organizovány do vyšších celků nazývaných areály. Budovy mohou mít jedna nebo více podlaží s určitým označením. Celé podlaží patří vždy k určitému oddělení. Oddělení se může nacházet na více podlažích Na každém patře může být několik místností, každá místnost je určitého typu (dílna, sklad, učebna, kancelář, laboratoř, šatna). Každá místnost má přidělenu osobu, která je za ni zodpovědná. Každá osoba může pracovat v několika místnostech, ale pouze jedna z nich je primární. Každý člověk je zaměstnán alespoň v jednom oddělení na určité pracovní pozici.

Supertyp a subtyp Jde reakci na reálné situace: způsob platby (hotovost, kartou, převodem,...), časový údaj (okamžik, den, týden, měsíc, rok), zvířata (obratlovci, bezobratlí), uživatel systému (zaměstnanec, zákazník) Instance supertypu se mohou lišit svými atributy a/nebo vztahy. Příklad platba, stejné jsou datum platby, částku, apod. Jiný typ platby => jiné atributy

Supertyp a subtyp Logické rozdělení entity na podcelky. Například když dílčí instance mají specifické vlastnosti (viz jednotlivé platby). Entitu označujeme jako supertyp, každý podcelek je pak subtyp. Platba Hotově Kartou PayPal

Subtyp Přebírá všechny atributy Přebírá všechny vztahy Může mít vlastní atributy i vazby Je znázorněn uvnitř supertypu Nikdy nevzniká samostatně Zvířata Obratlovci Bezobratlí

Zanoření (vhnízdění) subtypů V některých případech je pro lepší názornost možné používat více úrovní zanoření. Je důležité, aby to bylo smysluplné!!! Zvířata Obratlovci Ptáci Savci Plazi Ostatní Bezobratlí

Jak si to představit

Co s tím Subtyp je možné najít u každé entity Ne vždy je nutné jej použít Kdy jej použít vyplývá z reality, kterou modelujeme Identifikace subtypu Je subtyp součástí supertypu? Vyčerpali jsme opravdu všechny možnosti? Náleží příklad instance do právě jednoho subtypu?

Přenositelnost u vztahů Povinnost styl bez písně? Kardinalita kolik písní je stejného stylu? A kolik stylů může mít jedna píseň? Můžeme změnit styl písně?

Tzv. silné a slabé vazby Nepřenositelné vztahy

Obloukové vazby (Arcs) Pro vyjádření možnosti volby u vazeb Oblouk vždy náleží ke konkrétní entitě Zahrnují dvě a více vazeb Entita může využívat i více obloukových vazeb Oblouková vazba má vždy stejnou násobnost Supertyp i subtyp mohou být znázorněny pomocí obloukových vazeb (arc)

Použití obloukových vazeb

Hierarchické vztahy Nastává v případě, kdy je instance dané entity ve vztahu sama k sobě Příkladem je následující zadání Potřebujeme sledovat informace o našich zaměstnancích. Každý zaměstnanec má právě jednoho nařízeného, kromě prezidenta. Každý manažer může řídit několik zaměstnanců.

Hierarchické struktury Typicky organizační schéma společnosti Pokrytí budov včetně místností

Rekursivní struktury jiný způsob zaznamenání hierarchií jak? Máme za úkol namodelovat zaměstnaneckou strukturu Zkuste se zamyslet, který přístup je lepší a kdy?

Normální formy Vychází z návrhu relačního schématu Při návrhu relačního schématu hledáme funkční závislosti mezi atributy Funkční závislost lze definovat formálně X Y t 1,t 2 r: t 1 X = t 2 X t 1 Y = t 2 Y Intuitivně však pojem závislosti chápeme (např. PSČ město) Normální formy se snaží zjednodušit návrh

1. normální forma (NF) Všem atributům jsou jako jejich domény přiřazeny pouze atomické typy Např. adresa nebo celé jméno uživatele nebo e- mailové adresy nejsou atributy s atomickým typem, tedy celý návrh nesplňuje 1. normální formu Předpoklad 1. normální formy lze při návrhu obvykle snadno dodržet

První normální forma vyžaduje, aby neexistovaly vícehodnotové atributy. Proč není tato tabulka v 1. NF? Jak docílit, aby byla? ID_ZAKAZNIKA JMENO PRIJMENI ZBOZI 101 Marta Nováková stůl, lampa 102 Josef Koudelka postel, skříň, stůl 103 Johan Gregor Mendel židle Nevhodné řešení ID_ZAKAZNIKA JMENO PRIJMENI ZBOZI1 ZBOZI2 ZBOZI3 101 Marta Nováková stůl lampa 102 Josef Koudelka postel skříň stůl 103 Johan Gregor Mendel židle Tabulky splňují 1.NF ID_ZAKAZNIKA ZBOZI ID_ZAKAZNIKA JMENO PRIJMENI 101 Marta Nováková 102 Josef Koudelka 103 Johan Gregor Mendel 101 stůl 101 lampa 102 postel 102 skříň 102 stůl 103 židle

2. normální forma Pro splnění 2. NF musí být schéma v 1. NF Schéma nesmí obsahovat žádné částečné závislosti neklíčových atributů na klíči Zavedením jednoduchých klíčů a splněním 1. NF lze jednoduše dosáhnout 2. NF

Příklad Program Název_D Jméno_H Adresa Datum Městské Pastorkyňa Lidická 16 23.02.11 Městské Tři mušketýři Lidická 16 28.04.11 Národní Tři mušketýři Roosvelltova 3 04.04.11 Národní Pastorkyňa Roosvelltova 3 28.03.11 Národní Mary Poppins Roosvelltova 3 23.02.11 Redundance

Příklad - řešení Program Název_D Jméno_H Datum Městské Pastorkyňa 23.02.11 Adresář Název_D Adresa Městské Lidická 16 Národní Roosvelltova 3 Městské Tři mušketýři 28.04.11 Národní Tři mušketýři 04.04.11 Národní Pastorkyňa 28.03.11 Národní Mary Poppins 23.02.11 Intuitivně dekompozicí, dojde k odstranění závislosti neklíčového atributu (Adresa) na podklíči (Název_D)

3. normální forma Pro splnění 3. NF musí být schéma v 2. NF Dále nesmí být žádný neklíčový atribut tranzitivně závislý na žádném klíči schématu Tedy např. existence atributů PSČ a města uvnitř relace uživatel s klíčem rodné číslo odporuje 3. NF, protože město funkčně závisí na PSČ Pro zavedení 3. NF je třeba vyrobit číselníky

Podniková pravidla Co je cílem konceptuálního modelování? Uchování a poskytování informací Ve schématech uchováváme také integritní omezení (IO) Pro správné schéma databáze je nutné pokrýt i podniková pravidla Procedurální, často spojené s časem Strukturální, jaká informace má být uložena

Podniková pravidla Strukturované uvádějí typy informací, jež je možno pro daný atribut uchovávat (jen čísla, časové údaje od 2. 1. 2012, primární klíč z jiné tabulky,...) Procedurální jedná se o pracovní postupy související s provozem systému (sumační údaje z prodeje se ukládají vždy prvního v každém měsíci) Strukturální podniková pravidla je možné téměř vždy možné zanést do ERD. Některá z procedurálních podnikových pravidel nelze do diagramu zaznamenat, ale i tak musí být zdokumentována.

Modelování historických dat Kdy musíme počítat s historií? Budou data auditována? Podléhají data času? Musíme udržovat vývoj v čase a jak dlouho? Co když budeme chtít sledovat výplaty zaměstnanců?

Půjčovna Jak namodelujme půjčovnu šperků?

Půjčovna Jak namodelujme půjčovnu šperků?

Modelování času Kdy použijeme datový typ DATE a den jako entitu? co je nové entitě špatně? Nápověda 3NF

Omezení související s časem

Modelování vývoje ceny Nejen cen, ale také vývojových ukazatelů Zavedeme si tzv. historickou entitu Co si uvědomit Z Bc. na Ing., co je dobré vědět? Sleva u obchodních aplikacích jako e-shop Kam sledování ceny zařadíme? A co když zákazník vrací zboží?

Přenesená závislost Jaké atributy sledovat? Čas u prodeje Čas platné ceny

Žurnálování Opomíjené při návrhu schématu databáze Používáme vždy, když uživatelé mají umožněno zásadně měnit data aplikace. Vytváření logu/žurnálu Uchováváme předchozí hodnotu, ale také kdo změnu provedl

Na společné procvičení Jsme taneční studio a nabízíme taneční kurzy pro dospělé. Kurzy jsou rozděleny podle náročnosti do několika kategorií. Pro jednotlivé kategorie jsou určeny tance, které jsou vyučovány. Jeden tanec se může vyskytnout ve více kategoriích (pouze v jiné náročnosti). Za jednotlivé kurzy jsou zodpovědní lektoři, kteří řídí výuku. Vždy je jeden hlavní a jeden pomocný. Hlavní a pomocný lektor musejí být opačného pohlaví. U jednotlivých kurzů evidujeme, který den v týdnu probíhají a v kolik hodin, kolik je lekcí a datum, kdy kurz začíná a kdy končí. Dále evidujeme naše tanečníky. O nich známe jméno, příjmení a u některých i e- mail. Chceme vědět, do kterých kurzů chodí.

Převod ERD do fyzického modelu Konceptuální model (ER diagram) je převeden do fyzického modelu. Fyzický model bude implementován relační databází.

Změna terminologie Převod z konceptuálního modelu na fyzický s sebou přináší i změnu terminologie: Konceptuální entita instance atribut primární identifikátor sekundární identifikátor vztah Fyzický tabulka řádek sloupec primární klíč unikátní klíč cizí klíč

Notace zápisu tabulek První řádek obsahuje jméno tabulky Samotná tabulka popisující tabulku obsahuje tři sloupce: typ klíče (pk, uk, fk), povinnost (*, o) a název sloupce. Pro jména tabulek se užívají množná čísla. Jména sloupců zůstávají zachována kromě speciálních znaků (diakritiky). Mezery jsou nahrazeny podtržítkem.

Mapování vazeb Vztah vytváří cizí klíč, který musí být zanesen do jednoho nebo i více sloupců tabulky. V závislosti na povinnosti vztahu je pak dáno, může-li odpovídající sloupec nabývat hodnotu NULL.

Problémy při převodu Povinnost vazby se v rámci relační databáze dá vynutit pouze na jedné straně vazby (té, která se promítne jako nový sloupec). Nepřevoditelnou vazbu v relační databázi také nelze zachytit. Je potřeba použít nadstavbu v podobě dodatečného programování. Tyto skutečnosti je vždy vhodné zanést do dokumentace.

Mapování vazeb N:M

Mapování oblouků Při tomto mapování je nezbytné ohlídat, aby byl cizí klíč právě v jednom z odpovídajících sloupců. CHECK (pse_id IS NOT NULL AND phe_id IS NULL) OR (pse_id IS NULL AND phe_id IS NOT NULL)

Mapování supertypů a subtypů jedna tabulka Vytváří se vždy pouze jedna tabulka nezávisle na počtu subtypů. Tabulka bude obsahovat všechny sloupce odpovídající atributům supertypu s deklarovanými povinnostmi. Do tabulky budou zahrnuty také sloupce patřící jednotlivým subtypům. Tyto sloupce budou nepovinné. K těmto sloupcům se pak přidá ještě jeden, který bude povinný a bude specifikovat, o jaký subtyp se jedná.

Jedna tabulka pokračování Je potřeba se ujistit, aby docházelo ke vkládání odpovídajících hodnot daným subtypům pomoci omezení CHECK.

Kdy použít jednu tabulku? Použití jedné tabulky je běžná a flexibilní implementace. Je vhodné ji použít především když: Většina atributů je společných (nachází se v supertypu) Většina vazeb je na úrovni supertypu Podniková pravidla jsou globálně aplikovatelná na subtypy

Mapování supertypů a subtypů dvě tabulky Vytváří se tabulka pro každý subtyp. Ve skutečnosti tak může vzniknout tabulek více. Všechny tabulky budou obsahovat sloupce odpovídající atributům supertypu a k tomu sloupce odpovídající atributům daného subtypu. Povinnost zůstane zachována podle ERD. Stejným způsobem se pak mapují i vztahy mezi entitami do cizích klíčů

Dvě tabulky pokračování

Kdy použít dvě tabulky? Subtypy mají pouze málo společného. Vyskytuje se málo atributů v supertypu a více v subtypech Většina vztahů je na úrovni subtypů Podniková pravidla se mezi subtypy výrazněji liší

Mapování supertypů a subtypů oblouk Muže dojít k úpravě ERD a následně se postupuje jako by se jednalo o obloukovou vazbu.

Data definition language Datový slovník Vytváření, úprava a rušení nových objektů v datovém slovníku Objekty v datovém slovníku: tabulky, indexy, omezení, pohledy, sekvence, synonyma Obvykle se provádí rozdělení databáze na jednotlivá schémata (sessions), přičemž každé má svůj datový slovník RDBMS mají datový slovník přístupný jako zvláštní datového schéma

Tabulky (tables) představují relace vertikálně se dělí na řádky horizontálně se dělí na sloupce (tj. atributy) platí zde všechna pravidla o relacích a normálních formách zmíněná dříve (zejména definice domény, integritní omezení, klíče, atomičnost atd.) jedná se o jednorozměrný Excel

Jak na tabulku v SQL CREATE TABLE jméno (relace) Relace je představována popisem atributů a integritních omezení navzájem oddělených čárkou Popis atributu: jméno typ [impl. hod.] [omezení] Implicitní hodnota je definovatelná pomocí fráze DEFAULT hodnota

Jak pojmenovat tabulky Základní pravidla pro pojmenovaní tabulek lze shrnout na: Začínají písmenem Název musí mít mezi 1 a 30 znaky Obsahují pouze znaky A-Z, a-z, 0-9, _, $ a # Nesmí mít stejný název jako jiný objekt vlastněný stejným uživatelem Nesmí být tvořeno vyhrazenými klíčovými slovy Názvy nejsou Case-Sensitive Volte popisná jména

Základní datové typy V jednotlivých DB systémech mohou být rozdíly v názvech. Zde uvedené platí pro dbs Oracle. Znakové typy: CHAR(n), VARCHAR2(n) Číselné typy: NUMBER(prec, scale), INT, DECIMAL, FLOAT, REAL, SMALLINT Typ datum a čas: DATE Velké objekty: LONG, LONG RAW, RAW(n) Rozsáhlé objekty: BLOB, CLOB, BFILE Vlastní definované typy Tabulkové a objektové typy

Definice integritního omezení Základní omezení označuje možnost existence nedefinovaného stavu atributu (NULL, NOT NULL), implicitně je NULL Další omezení lze zavést jako doplňující podmínku k doméně CHECK (podmínka) Každému atributu lze definovat klíč (primární PRIMARY KEY, unikátní UNIQUE nebo cizí klíč REFERENCES) Pojmenované omez. CONSTRAINT jméno

Vícesloupcová integrita Představuje integritní omezení definované jako atribut relace Může být definována jako primární klíč PRIMARY KEY(sloupce), unikátní klíč UNIQUE(sloupce), podmínku CHECK(podmínka) nebo jako cizí klíč FOREIGN KEY(sloupce) REFERENCES Zápis cizího klíče je REFERENCES tabulka(sloupce) [ON DELETE CASCADE SET NULL]

Příklad

Další příkazy DDL Rušení objektů: DROP objekt název Modifikace struktury tabulky: ALTER TABLE jméno operace Podporované operace: přejmenování, RENAME TO jméno přidání sloupců, ADD (definice relace) zrušení sloupců, DROP (sloupce) změna omezení sloupce, MODIFY (relace) přejmenování sloupce RENAME COLUMN jméno TO jméno

Přihlašovací údaje

Přihlašovací údaje Username: c##jmeno Password: pwjmeno Hostname: trust.mendelu.cz Port: 1521 SID: trust

https://akela.mendelu.cz/~xturcin0/naostro/