Fakulta elektrotechniky a informatiky

Fakulta elektrotechniky a informatiky jiri.zechmeister@upce.cz
Databázové systémy I Přednáška č. 2 Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky

Databázové systémy 1 - př. 1
Obsah Fáze návrhu databáze Konceptuální model Barkerova notace Unikátní identifikátory Databázové systémy 1 - př. 1

Návrhové fáze vývoje dtb. systému
Databázové systémy 1 - př. 1

Fáze plánování databáze
Fáze plánování databáze je počátečním bodem databázového projektu. V této fázi jsou stanoveny: základní cíle a priority celého projektu hlavní cíl databázového systému milníky, kterých je nutné postupně dosahovat odhad rozsahu potřebné práce, rozdělení práce mezi členy vývojového týmu odhad finanční náročnosti celého projektu často se definují i standardy vývoje Databázové systémy 1 - př. 1

Fáze definice systému Při definici systému dochází k identifikaci rozsahu a hranic systému, který zkoumáme, identifikuje se rozhraní vůči jiným informačním systémům, při definici systému se nesledují pouze aktuální uživatelské pohledy, nýbrž musí být počítáno se všemi předpokládanými budoucími pohledy. Přesto jsou uživatelské pohledy velmi důležitou částí definice systému. Uživatelský pohled definuje to, co se od databázového systému požaduje z hlediska konkrétního pracovního postavení (může to být pohled vysokého manažera společnosti stejně jako pohled běžného pracovníka), či se může jednat o pohled určité provozní oblasti (marketing, lidské zdroje, CRM, …). Databázové systémy 1 - př. 1

Fáze sběru požadavků Závěrečnou přípravnou fází před zahájením samotného modelovaní je fáze sběru požadavků a jejich následná analýza. V této fázi proběhne sběr a analýza informací o organizaci či objektu zájmu, kterému bude databáze sloužit. Sběr informací se provádí pro každý významný uživatelský pohled a jeho součástí bývá: popis používaných nebo vytvářených dat, podrobnosti o tom, jak jsou data vytvářena a používána, všechny další požadavky na databázový systém. Databázové systémy 1 - př. 1

Fáze sběru požadavků Tyto informace se následně analyzují, aby se určily požadavky, které je nutné implementovat do návrhu nového databázového systému. Tyto požadavky se dále archivují jako součást specifikace požadavků. Určení těch správných požadavků je kritická činnost, neboť systém s neúplnou implementací uživatelských požadavků může být z pohledu uživatele těžko použivatelný a může to vést až k odmítnutí systému jako celku. Databázové systémy 1 - př. 1

Konceptuální návrh databáze
V první fázi se prostřednictvím konzultací s uživateli a zadavateli systému formulují a shromažďují přesné požadavky na to, co vše má být v databázi uloženo. Z takto získaných informací se vytvoří konceptuální model, který je výsledkem první fáze návrhu databáze. Konceptuální datový model popisuje data na abstraktní úrovni nezávisle na jejich fyzickém uložení. Proces tvorby konceptuálního modelu se nazývá konceptuální modelování. Jeho výsledkem je konceptuální model znázorněný jako konceptuální schéma nebo diagram, který má co nejvýstižněji zachycovat pohled člověka na danou část reálného světa. Mezi nejznámější konceptuální datové modely patří E-R model. Databázové systémy 1 - př. 1

Business pravidla (business rules)
Business pravidla nám definují vše co se týká chování aplikace Tato pravidla dělíme do dvou kategorií Procedurální pravidla (procedural business rules) Tato pravidla vyžadují dodatečné programování a není možné je podchytit pomocí struktury databáze „Nové záznamy může provádět pouze uživatel s rolí administrátor“ Strukturální pravidla (structural business rules) Tato pravidla je možné podchytit již ve struktuře databázového modelu (pomocí klíčů, omezení, atd..) „Objednávku je možné vystavit pouze registrovaným uživatelům“ Databázové systémy 1 - př. 1

Business pravidla Všechna business pravidla, která není možné zahrnout do konceptuálního modelu, je třeba dokumentovat Pokud bychom pravidla nedokumentovali, mohlo by se na ně v průběhu vývoje zapomenout „Žádný zaměstnanec jehož přesčas přesáhne 10 hodin týdně, bude vyplácen 1.5 násobkem hodinové mzdy.“ „Zákazníci, kteří budou opožděni se splatností o více než 90 dnů, nebudou moci vytvořit novou objednávku.“ Databázové systémy 1 - př. 1

Konceptuální návrh databáze
Pro konceptuální návrh jsou podstatné tyto úkoly: Krok 1 – Identifikace entit (entity). Krok 2 – Identifikace relací (relation). Krok 3 – Identifikace atributů (attribute) a spojení atributů s entitami a relacemi. Krok 4 – Nalezení domén atributů (attribute domain). Krok 5 – Vyhledání unikátních identifikátorů (unique identifier). Krok 6 – Kontrola redundance (redundancy check) v modelu. Krok 7 – Posouzení zda model podporuje uživatelské transakce. Databázové systémy 1 - př. 1

Entita, Instance entity
1. Krok Entita se dá definovat jako věc schopná samostatné existence a je jednoznačně identifikovatelná. Entita může být fyzicky existující objekt (tangible entity), jako například dům nebo automobil, nebo událost (event entity) jako je prodej domu nebo servis automobilu nebo může jít o pojem(intagible entity) jako je například zákaznická transakce nebo objednávka. Entity obsahují instance (instance). Pod pojmem instance potom rozumíme jeden výskyt entity. Budeme-li mít například entitu zvíře, potom instance této entity může být pes, kočka atd. V literatuře můžeme najít také místo pojmu entita pojem entitní typ a místo pojmu instance se potom používá pojem entita. Entity jsou označovány podstatnými jmény jednotného čísla. Příklad: počítač, zaměstnanec, píseň, matematická teorie. Entity se zobrazují jako obdélníky s kulatými rohy. Databázové systémy 1 - př. 1

Identifikace entit 1. Krok Počáteční krokem při tvorbě ER modelu by měla být identifikace hlavních objektů modelovaného systému. Tyto objekty pak představují entity pro model. Standardně považujeme za entitu rozlišitelný a identifikovatelný objekt reality. Nebo též se dá entita definovat jako objekt reálného světa, který je předmětem zájmu a má smysl o něm uchovávat informace. Z pohledu modelu se entitami mohou stát osoby, hmotné i nehmotné objekty, události (rezervace, objednávka, reklamace, …) či pojmy důležité z pohledu modelovaného systému. Při hledání entit na základě slovníku dat se postupuje tak, že se v dokumentu vyhledávají hlavní objekty zájmu (například osoby, pojmy či zájmy) a dochází k vyloučení položek, které jen označují vlastnosti jiných objektů. Jinou cestou při hledání entit je nalezení objektů se samostatnou existencí. Například položka Student může být entitou, neboť student existuje i bez toho, abychom znali jeho jméno, adresu či jiné osobní informace. Databázové systémy 1 - př. 1

Super entity & Odvozené entity (Supertypes & Subtypes)
1. Krok Mohou nastat případy, kdy některé entity mají společné atributy a/nebo relace. Uvažujme následující příklad. Potřebujeme sledovat jednotlivé platby zákazníků. Zákazníci mohou platit hotově, převodem nebo kreditní kartou. Všechny typy plateb mají společné atributy, kterými jsou datum platby, částka atd. Pouze platba kreditní kartou u sebou nese ještě atribut číslo kreditní karty. U platby kreditní kartou a převod také potřebujeme vědět, kdo platbu provedl, což u platby hotově vědět nepotřebujeme. Bude lepší vytvořit jedno entitu PLATBA, nebo jednotlivé entity HOTOVE, PREVODEM a KREDITNI_KARTOU? Co se stane, když v budoucnosti přidáme další platební metodu? Databázové systémy 1 - př. 1

Odvozené entity 1. Krok Pokud entitu rozdělíme na části, vznikne nám jedna skupinová entita (supertyp) a několik pod-entit (podtyp). Pro jednotlivé podtypy potom platí: Dědí všechny atributy ze supertypu Dědí všechny relace ze supertypu Může mít vlastní atributy a relace Kreslí se do supertypu Nikdy neexistuje samostatně Může mít vlastní podtypy Databázové systémy 1 - př. 1

Vztah (relationship) 2. Krok Vztah (relationship) zachycuje, jakým způsobem jsou dvě nebo více entit vztažené mezi sebou. Vztahy se označují slovesy, spojujícími dvě nebo více podstatných jmen. Příklad: vztah vlastní je mezi společností a počítačem, vztah dohlíží je mezi zaměstnancem a oddělením, vztah hraje je mezi umělcem a písní, a vztah dokázal je mezi matematikem a matematickou teorií. Vztah je také označován jako relace. Nepleťte si pojem relace z relačního modelu s pojmem relace z konceptuálního modelu! Databázové systémy 1 - př. 1

Kardinalita vztahu 2. Krok nám říká, kolik instancí jedné entity je možné spojit s kolika instancemi druhé entity Mohou nastat situace: 1:1 (billboard – reklama) 1:M (zákazník – objednávka) M:M (studenti – učebny) Databázové systémy 1 - př. 1

Parcialita vztahu 2. Krok nám říká, jestli může instance jedné entity existovat bez instance druhé entity Rozšiřuje kardinalitu o možnosti: 0..1 0..M Příklad: 1:0..M (zákazník – objednávky) zákazník může existovat i bez objednávky, objednávka bez zákazníka nikoliv Databázové systémy 1 - př. 1

Přenositelnost (Transferability)
2. Krok Přenositelnost nám definuje, zda je možné danou relaci převést na jiné entity. Uveďme si na příkladech: Máme entitu pes a majitel. Pokud majitel může prodat, tedy mezi relaci je možné přenést na jinou instanci entity majitele. Pokud budeme mít entitu objednávka a zákazník, potom jakmile jednou zákazník provede objednávku, již ji není možné přesunout na jiného zákazníka. Relace mezi entitami je tedy nepřenositelná (Non-trasferable). Zubní kartáček – člověk ? Nepřenositelnost patří mezi procedurální pravidla! Databázové systémy 1 - př. 1

Výlučné relace (Arc) 2. Krok Každá entita může být v relaci s libovolným množstvím jiných entit. Mohou ale nastat případy, kdy existence relace je vzájemně výlučná, tedy že pokud je entita v relaci s jinou entitou, již není možné aby současně byla v relaci s jinou entitou. Výlučné relace se modelují pomocí oblouků (Arc) Databázové systémy 1 - př. 1

Atribut (atribute) 3. Krok Atribut je část informace, která: Popisuje entitu Kvantifikuje entitu Kvalifikuje entitu Klasifikuje entitu Specifikuje entitu Příklad: entita zaměstnanec může obsahovat atribut rodné číslo (RČ); Atribut obsahuje vždy jednu hodnotu (single valued) Atributy mohou být přiřazeny také vztahům Databázové systémy 1 - př. 1

Atribut (atribute) 3. Krok Každý atribut má datový typ (data type) Řetězec, datum, obrázek, zvuk, číslo, znak atd. Každý atribut má daném okamžiku vždy jednu hodnotu Každá instance entity má vlastní hodnotu atributu Atributy dále dělíme na Povinné (mandatory) – atribut musí mít hodnotu ( vycházíme z business požadavků) Nepovinné (optional) – atribut hodnotu mít nemusí (mohou nabývat hodnoty NULL) Databázové systémy 1 - př. 1

Identifikace domén atributů
4. Krok Doména je přípustná množina hodnot, z níž mohou čerpat své hodnoty jeden nebo i více atributů. Příkladem může být například osobní číslo studenta. Jeho doménou může být sedmimístný znakový řetězec s pevnou délkou, jehož první dva znaky jsou „ST“ a zbývající znaky tvoří čísla, tedy čísla – Dalším příkladem může byt doména atributu „studuje“ u entity Student. Zde můžeme určit doménu jako jeden znak, jenž může nabývat pouze hodnot „A“ a „N“ Základními informacemi o doméně jsou tedy: Přípustná množina hodnot atributu. Velikost a formát atributu. Databázové systémy 1 - př. 1

Unikátní identifikátor
5. Krok Je velice důležitý v oblasti relačních databází Jedná se o atribut nebo skupinu atributů, která jednoznačně identifikuje instanci entity mezi ostatními Typy: Jednoduché (simple UID) Složené (compose UID) Umělé (artifical UID) Kandidátní (cadidate UID) Databázové systémy 1 - př. 1

Jednoduché UID 5. Krok Jsou takové identifikátory, které se skládají pouze z jednoho atributu Jednoduchý přirozený Je tvořen atributem, který entitu přirozeně identifikuje (výrobní číslo produktu, „rodné číslo“, registrační značka vozidla) Jednoduchý umělý Jelikož neexistuje atribut, který by entitu identifikoval přirozeně, vytvoříme umělý identifikátor Většinou označován jako ID Databázové systémy 1 - př. 1

Složené UID 5. Krok Jsou takové identifikátory, které se skládají z více atributů Většinou se využívá u průnikových tabulek (intersection table), které slouží pro řešení vazeb M:M Entita objednavka, atributy cislo_zakaznika a datum_objednavky Databázové systémy 1 - př. 1

Kandidátní UID 5. Krok U některých entit existuje možnost více unikátních identifikátorů Příklad: číslo zákazníka, zákazníka Všechny tyto možnosti jsou nazývány jako kandidátní identifikátory Pouze jeden vybraný kandidátní identifikátor se stane unikátním identifikátorem (primární unikátní identifikátor). Ostatní kandidátní identifikátory zůstanou jako sekundární unikátní identifikátory. Databázové systémy 1 - př. 1

Kontrola redundance v modelu
6. Krok Redundance (nadbytečnost) se v modelu vyskytne ve chvíli, kdy nalezneme dvě entity, které ve skutečnosti vyjadřují jeden a tentýž objekt v rámci modelované problematiky. Může se stát, že v modelu systému pro VŠ vzniknou entity Vyučující a Školitel. Mezi oběma entitami bude navíc vazba 1:1. To je totiž typický případ, kdy redundance vznikají. V tomto případě je vhodné obě entity spojit do jedné. Pokud mají obě entity své UID, vybere se jeden z nich a druhý se ponechá jako alternativní. Proto je při kontrole vhodné nejprve projít všechny vazby 1:1 a prověřit entity na obou stranách relace, zda náhodou nevyjadřují tutéž skutečnost. Druhý typ redundance, méně nápadný než první, který při modelování vzniká, je redundance relací. V tomto případě se v modelu vyskytne relace, která vyjadřuje informaci, kterou lze získat prostřednictvím jiné relace (relací). Databázové systémy 1 - př. 1

Posouzení zda model podporuje uživatelské transakce
7. Krok Pokud byly provedeny předchozí kroky pečlivě a svědomitě, měl by být k dispozici ER model plně popisující modelovaný objekt. Nyní je nutné zkontrolovat, zda daný model podporuje požadované transakce (činnosti). V podstatě se jedná o manuální provedení požadovaných operací nad modelem. Pokud je nad modelem možné provést všechny požadované transakce (operace), může být model považován za kompletní. V opačném případě je pravděpodobné, že ve výsledném modelu chybí nějaká entita, relace nebo atribut. V zásadě lze pro kontrolu uživatelských transakcí použít dvě metody: Metoda popisu transakcí. Metoda sledovaní cest transakcí. Databázové systémy 1 - př. 1

Posouzení zda model podporuje uživatelské transakce
7. Krok Při metodě popisu transakce se kontroluje, zda všechny informace (entity, relace, a jejich atributy) potřebné pro realizaci jedné konkrétní transakce jsou k dispozici. Například v modelu VŠ můžeme položit otázku: „Které předměty vyučuje daný vyučující“. Údaje o vyučujících jsou uloženy v entitě Vyučující, informace o konkrétních předmětech jsou uloženy v entitě Předmět. A k určení jednotlivých předmětů daného vyučujícího využijeme relace „Učí“. Tuto transakci je tedy možno s v rámci tohoto modelu vykonat. Při druhé metodě se požadované transakce reprezentují pomocí cest přímo v ER diagramu. Doslova jde o spojení všech zainteresovaných entit a relací a zjištění, zda je daná cesta průchodná. Databázové systémy 1 - př. 1

Nástroje pro tvorbu ER diagramů
Na trhu je mnoho nástrojů pro vytváření databázových modelů, například: Avolution, ConceptDraw, ER/Studio, ERwin, DeZign for Databases, MEGA International, OmniGraffle, Oracle Designer, PowerDesigner, Rational Rose, RISE Editor, SmartDraw, Sparx Enterprise Architect, SQLyog, Toad Data Modeler, Microsoft Visio, Visual Paradigm Oracle SQL Developer Data Modeler MySQL Workbench, StarUML Toto budeme Používat  Databázové systémy 1 - př. 1

ERD notace Ukázka notací ERD A Barkerova notace, kterou se budeme zabývat podrobněji Databázové systémy 1 - př. 1

ERD - Entita (Barkerova notace)
Definována jako obdélník s kulatými rohy (softbox) Databázové systémy 1 - př. 1

ERD Modelování supertypů a podtypů Databázové systémy 1 - př. 1

ERD Modelování supertypů (supertypes) a odvozených typů (subtypes) Databázové systémy 1 - př. 1

ERD - Atribut Atributy Seznam atributů je uveden pod názvem entity UID – označeno # Povinný (mandatory) atribut – označeno * Nepovinný (optional) atribut – označeno o Databázové systémy 1 - př. 1

ERD - Relace Relace Jsou čáry spojující jednotlivé entity Relace jsou zakončeny jednoduchou čarou (single toe) nebo kohoutí stopou (crow‘s foot) Na obou koncích relace jsou uvedeny popisky, které specifikují relaci Databázové systémy 1 - př. 1

ERD Význam relací Entita CELEK obsahuje nula, jednu nebo více entit CAST Entita CELEK obsahuje jednu nebo více entit CAST Entita CELEK obsahuje přesně jednu entitu CAST Entita CELEK obsahuje nula nebo jednu entitu CAST Databázové systémy 1 - př. 1

ERD Význam relací - příklad Entita JADRO obsahuje jednu nebo více entit PROTON a nula, jednu nebo více entit NEUTRON Entita ATOM obsahuje přesně jednu entitu JÁDRO a nula, jednu nebo více entit ELEKTRON Databázové systémy 1 - př. 1

ERD Identifikující relace Definuje, že unikátní identifikátor z jedné entity se stane částí unikátního identifikátoru z entity druhé. V ERD se tento atribut (nebo množina atributů) v entitě nezobrazuje, musíme s jeho existencí počítat. Zobrazujeme jako svislou čáru na straně podřízené entity. Databázové systémy 1 - př. 1

ERD Kardinalita U Bakerovi notace, je kardinalita definována tvarem zakončení relace mezi entitami Obecně známe kardinality 1:1, 1:M a M:M Barkrova notace je modeluje následovně: 1:1 1:M M:M Databázové systémy 1 - př. 1

ERD Parcialita Parcialita je definována v notaci typem čáry. Přerušovaná čára značí volitelnou (optional) část relace. Plná čára definuje, že část relace je povinná (mandatory) Parcialita nám rozšiřuje kardinalitu na možnosti 0..1:0..1, 0..1:0..M a 0..M:0..M 0..M:0..M 0..1:0..1 0..1:0..M Databázové systémy 1 - př. 1

ERD Rekurzivní relace (recursive relation) Rekurzivní relace je taková, kdy je entita ve vztahu se sebou samou. Budeme-li mít entitu CLOVEK, potom rekurzivní relace nám může definovat předky daného člověka. Databázové systémy 1 - př. 1

ERD Výlučné relace V ERD jsou výlučné relace modelovány pomocí oblouků (Arcs) Databázové systémy 1 - př. 1

ERD Přenositelnost (transferabilita) Možnost přenositelnosti je v ERD modelován symbolem diamantu Pokud je diamant zobrazen, je možné provést update relace (transferable) Pokud není diamant zobrazen, relace je pevná, nepřenositelná (non-transferable) Databázové systémy 1 - př. 1

Prostor pro dotazy Děkuji za pozornost Databázové systémy 1 - př. 1

Fakulta elektrotechniky a informatiky

Podobné prezentace

Prezentace na téma: "Fakulta elektrotechniky a informatiky"— Transkript prezentace:

Podobné prezentace

O projektu

Kontaktní formulář

Přihlásit se

Přihlásit se přes sociální síť:

Fakulta elektrotechniky a informatiky

Podobné prezentace

Prezentace na téma: "Fakulta elektrotechniky a informatiky"— Transkript prezentace:

Podobné prezentace

O projektu

Kontaktní formulář