Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

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

Podobné prezentace


Prezentace na téma: "Databázové systémy I Přednáška č. 2 Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky"— Transkript prezentace:

1 Databázové systémy I Přednáška č. 2 Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky

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

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

4 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 4

5 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 5

6 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 6

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

8 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 8

9 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 9

10 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 10

11 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 11

12 Entita, Instance entity Entita se dá definovat jako věc schopná samostatné existence a je jednoznačně identifikovatelná. Entita 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.podstatnými jmény Entity se zobrazují jako obdélníky s kulatými rohy. Databázové systémy 1 - př Krok

13 Identifikace entit 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ř Krok

14 Super entity & Odvozené entity (Supertypes & Subtypes) 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ř Krok

15 Odvozené entity 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ř Krok

16 Vztah (relationship) 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í.slovesy 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ř Krok

17 Kardinalita vztahu – 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ř Krok

18 Parcialita vztahu – nám říká, jestli může instance jedné entity existovat bez instance druhé entity – Rozšiřuje kardinalitu o možnosti: 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ř Krok

19 Přenositelnost (Transferability) 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ř Krok

20 Výlučné relace (Arc) 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ř Krok

21 Atribut (atribute) 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ř Krok

22 Atribut (atribute) 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ř Krok

23 Identifikace domén atributů 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ř Krok

24 Unikátní identifikátor 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ř Krok

25 Jednoduché UID 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ř Krok

26 Složené UID 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ř Krok

27 Kandidátní UID 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ř Krok

28 Kontrola redundance v modelu 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ř Krok

29 Posouzení zda model podporuje uživatelské transakce 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ř Krok

30 Posouzení zda model podporuje uživatelské transakce 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ř Krok

31 Nástroje pro tvorbu ER diagramů Na trhu je mnoho nástrojů pro vytváření databázových modelů, například: AvolutionAvolution, ConceptDraw,ConceptDraw ER/StudioER/Studio, ERwin,ERwin DeZign for DatabasesDeZign for Databases, MEGA International,MEGA International OmniGraffleOmniGraffle, Oracle Designer,Oracle Designer PowerDesignerPowerDesigner, Rational Rose,Rational Rose RISE EditorRISE Editor, SmartDraw,SmartDraw Sparx Enterprise ArchitectSparx Enterprise Architect, SQLyog,SQLyog Toad Data ModelerToad Data Modeler, Microsoft Visio,Microsoft Visio Visual ParadigmVisual ParadigmOracle SQL Developer Data Modeler MySQL WorkbenchMySQL Workbench, StarUMLStarUML Databázové systémy 1 - př Toto budeme Používat

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

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

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

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

36 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 36

37 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 37

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

39 ERD Význam relací - příklad Databázové systémy 1 - př 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

40 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 40

41 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ě: Databázové systémy 1 - př M:M 1:M 1:1

42 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 Databázové systémy 1 - př : :0..M 0..M:0..M

43 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 43

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

45 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 45

46 DĚKUJI ZA POZORNOST Prostor pro dotazy Databázové systémy 1 - př. 1 46


Stáhnout ppt "Databázové systémy I Přednáška č. 2 Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky"

Podobné prezentace


Reklamy Google