Přednášky

Databázové systémy 2 Kapitola 1
Základy datové analýzy – ER model Konceptuální modelování konceptuální model
snaha umožnit popis dat v DB nezávisle na fyzické a logické implementaci
má co nejvěrněji vystihnout lidský konceptuální pohled na danou oblast
datová analýza (ne funkční analýza)
modelování datové reality
jaká budeme mít v informačním systému data
pohled uživatele vs. pohled analytika
* E-R model množina pojmů, umožňujících popis struktury DB na uživatelsky srozumitelné úrovni
nejlépe se vyjadřuje graficky
entita (entity)
objekt reálného světa, který je schopen nezávislé existence a je jednoznačně identifikovatelný
např. mostní objekt číslo 221-0608
je obvykle odpovědí na otázku „co“, je vystižena podstatným jménem MOST * E-R model vztah (relationship)
vazba mezi dvěma či více entitami
např. mostní objekt č. 221-0608 leží na silnici třetí třídy č. 221, tj. obecně entita „most“ je ve vztahu „leží na“ s entitou „silnice“
často je vystižen slovesem MOST SILNICE leží na * E-R model hodnota popisného typu (value)
jednoduchý datový typ (tj. dvojice {množina hodnot, množina operací}), např. „celé číslo“ apod.
atribut (attribute)
funkce přiřazující entitě či vztahu popisnou hodnotu, např. entita „SILNICE“ má atribut „číslo“ SILNICE číslo * Identifikační klíč každá entita musí být jednoznačně identifikovatelná
atribut nebo skupina atributů, jejichž hodnota slouží k identifikaci konkrétní entity se nazývá identifikační klíč (v E-R schematu podtrženě)
např. atribut „rodné číslo“ entity ZAMĚSTNANEC
entitní typ může mít několik kandidátů na klíč
ZAMĚSTNANEC může být identifikován
rodným číslem
číslem zaměstnance
jménem, příjmením a datem narození
volba klíče podle efektivity apod. * Kardinalita (poměr) vztahu integritní omezení pro vztahový typ
entitní typy KINO a FILM a vztahový typ HRAJE
tři druhy kardinality
poměr 1:1
dané kino dává maximálně jeden film
daný film je na programu maximálně v jednom kině
může zahrnovat vztahy 0:1 a 1:0, tj. kino nic nedává nebo film se nikde nehraje – povinnost členství KINO FILM HRAJE 1 1 * Kardinalita (poměr) vztahu poměr 1:N
dané kino může hrát více než jeden film
daný film se dává maximálně v jednom kině
může zahrnovat vztahy 0:1, 1:0, 1:1
důležitý směr („jedno kino – víc filmů“ vs. „jeden film – víc kin“) KINO FILM HRAJE 1 N * Kardinalita (poměr) vztahu poměr M:N
dané kino může hrát více než jeden film
daný film se může dávat ve více než v jednom kině
může zahrnovat vztahy 0:1, 1:0, 1:1, 1:N, N:1 – některé z nich mohou být vyloučeny přísnějšími pravidly KINO FILM HRAJE M N * Kardinalita (poměr) vztahu kardinalita také odpovídá tvrzení, že jedna entita jednoznačně určuje druhou entitu, resp. je determinantem entity druhého typu
pro vztah 1:1 lze např. říct, že název kina determinuje název filmu a také název filmu determinuje název kina
pro vztah 1:N lze např. říct, že název filmu determinuje název kina, ale název kina nedeterminuje název filmu
u vztahu M:N není determinující ani jedna entita
* Parcialita (členství) vztahu účastní-li se entita vztahu, říkáme, že je členem vztahu
někdy má entita předepsanou účast ve vztahu, tj. členství je povinné
např. zaměstnanec musí být zaměstnán na nějakém oddělení
jindy se entita do vztahu zapojovat nemusí, členství je nepovinné
např. oddělení může existovat i bez zaměstnanců
důležité: vyjadřuje, že entita nemůže existovat bez zapojení do vztahu s instancí druhého typu
* Parcialita (členství) vztahu v grafickém konceptuálním modelu se parcialita značí různě, například
v kině se může dávat víc filmů anebo žádný
film se musí dávat právě v jednom kině
KINO FILM HRAJE 1 N * Slabé entitní typy součástí klíče některých entit nemusí být pouze jejich vlastní atributy
entita není jednoznačně identifikovatelná pouze pomocí svých atributů, mohou existovat instance, které mají stejné hodnoty atributů
např. identifikace kinosálu je možná pouze ve spojení s identifikací multikina, v němž se nalézá
kino – identifikační vlastník
kinosál – slabý entitní typ
vztah kino-kinosál – identifikační vztah
slabý entitní typ má vždy povinné členství v identifikačním vztahu
* Slabé entitní typy v databázi může existovat více sálů s týmž číslem, které se však nalézají v různých kinech
identifikační klíč je dvojice (jméno_kina, číslo_sálu)
vlastní atribut „číslo_sálu“ je jen částečný klíč
KINO SÁL má jméno_kina SÁL číslo_sálu * Dekompozice M:N vztahu návrh konceptuálního schematu je sice nezávislý na logickém modelu, nicméně některé SŘBD neumějí reprezentovat vztahy M:N přímo
vztahy M:N je určitě vhodné používat při konceptuálním modelování, avšak musíme být schopni je následně rozdělit do dvou vztahů typu 1:N – dekompozice * Dekompozice M:N vztahu chybná dekompozice KINO FILM HRAJE (0,N) (0,N) KINO FILM DÁVÁ (0,1) (0,N) DÁVÁN (0,1) (0,N) * Dekompozice M:N vztahu správná dekompozice KINO FILM HRAJE (0,N) (0,N) KINO FILM DÁVÁ (0,1) (0,N) DÁVÁN (0,1) (0,N) PROGRAM * Dekompozice M:N vztahu lze též využít identifikační závislosti
entita PROGRAM má identifikační klíč (jméno_kina,jméno_filmu)
pokud není atribut „datum“ klíčový, kino nemůže promítat jeden film v různých dnech KINO FILM DÁVÁ (0,N) DÁVÁN (0,N) PROGRAM PROGRAM jméno_kina jméno_filmu datum * Rekurzivní typ vztahu typ entity vstupuje do vztahu sám se sebou
vzniká stromová hierarchie – osoba může vést několik osob, ale je vedena pouze jednou osobou
je vhodné zavést tzv. role (vede, je_veden)
OSOBA VEDE (0,N) jméno adresa telefon (0,1) * ISA hierarchie analogie dědičnosti v OOP
např. OSOBA může být buď STUDENT nebo UČITEL – entitní podtyp
STUDENT IS A OSOBA, UČITEL IS A OSOBA
společné atributy: jméno, RČ, adresa
atributy vázané pouze na podtyp
STUDENT: počet kreditů, ...
UČITEL: platová třída, ...
OSOBA STUDENT UČITEL * Speciální typy atributů konceptuální model se nemusí omezovat pouze na atomické atributy (logický model se na ně obvykle již omezuje)
skupinový atribut
např. adresa (ulice, číslo, město, PSČ)
heterogenní strukturovaný datový typ
může tvořit hierarchie
užitečný, přistupujeme-li někdy ke složkám a někdy k celku
vícehodnotový atribut
např. atribut telefon ent. typu ZAMĚSTNANEC
když předem nevíme, kolik prvků bude mít
* Výlučný typ vztahu entitní typ vstupuje právě do jednoho z N vztahů POLOŽKA PŘÍJMOVÁ FAKTURA PATŘÍ N 1 VÝDEJOVÁ FAKTURA PATŘÍ N 1 * Častá chyba častá chyba
entitě přiřadíme atribut, který slouží k reprezentaci vztahu v relačním modelu
například schema
bude tranformováno do dvou relací:
KINO(jméno_kina, adresa)
SÁL(číslo_sálu, jméno_kina, kapacita) KINO SÁL má jméno_kina SÁL číslo_sálu adresa kapacita * Častá chyba to ovšem neznamená, že by ER diagram měl vypadat takto
atribut „jméno_kina“ v entitě SÁL je na konceptuální úrovni nesmyslný
to, že daný sál patří do daného kina je jednoznačně řečeno vztahem má KINO SÁL má jméno_kina SÁL číslo_sálu adresa kapacita jméno_kina *
Databázové systémy 2 Kapitola 2
Metodologie logického návrhu DB v relačním prostředí Logický návrh datová část informačního systému
tři fáze STADIUM 2 * Logický návrh, 1. fáze požadavky na IS
formulace a shromažďování uživ. požadavků
identifikace dat organizace
objevujeme entity
ER modelování
první krok (iterativně)
definice nezávislých entitních typů
definice typů vztahů
definice typů závislých entit
druhý krok
nalezení atributů
určení identifikačních klíčů
* Logický návrh, 2. fáze převod ER modelu do RMD
částečně algoritmizovatelná
nutná kontrola normálních forem
návrh tabulek
hrubý návrh
tabulky s atributy, primárními a cizími klíči * Logický návrh, 3. fáze detailní návrh tabulek
datové typy
integritní omezení (IO)
některá IO nejsou přímo podporovaná daným SŘBD, je třeba je ošetřit na úrovni aplikace, popř. jako uložené procedury a triggery * ER model entity a atributy
nejprve nalezneme entitní typy, popř. jejich kandidátní klíče
atributy
kvalifikace, identifikace, klasifikace, vyjádření stavu entity
eliminovat vícehodnotové atributy
vyjasnit rozdíly mezi entitami+vztahy a atributy
sémantický relativismus
jeden jev lze modelovat více způsoby
pojmenovávat tak, aby bylo pokud možno jasné, k jaké entitě náleží
tj. nikoli „číslo“, ale např. „číslo_zaměstnance“
* ER model entity a atributy
atributy
samostatnou entitu pravděpodobně zavedeme, pokud u ní identifikujeme více atributů než jeden
říká se, že pokud má entita víc než 8 atributů, je to známka toho, že nám v modelu chybí entity či vztahy
už zde je možné provádět prvotní kontrolu normálních forem, např. testovat, zda nově identifikovaný atribut závisí pouze na celém klíči apod.
* ER model vztahy
určit název, kardinalitu, parcialitu, popř. atributy
je vhodné (a často CASE-podporováno) testovat návrh na chybějící či redundantní vztahy
pokud entita není zapojena do vztahu, něco je divně
redundantní vztah vznikne například tranzitivitou (ISA hierarchie) * ER model doporučená pravidla pro kreslení
vztahy vodorovně, číst zleva doprava
u vztahů 1:N dávat N nalevo
minimalizovat šikmé čáry a křížení
nekreslit čáry těsně u sebe
používat podmnožiny ER diagramů
označit každý diagram jménem a datem * ER model kontrola
entity
je jméno entity smysluplné a je v jednotném čísle?
jak je to s výlučností?
jsou dány alespoň dva atributy?
není zvláštní, že existuje více než 8 atributů?
co homonyma a synonyma v názvech typů entit?
je definice typu entity úplná?
jsou známy skutečné četnosti entit daného typu?
je dán klíč entity?
existuje alespoň jeden typ vztahu, ve kterém je typ entity členem?
existuje alespoň jeden proces, používá danou entitu? * ER model kontrola
mění se entita v čase?
vyhovuje definice atributů normalizaci?
není typ entity příliš generický?
je typ entity generický postačujícím způsobem?
entitní podtypy
jsou podtypy typu entity výlučné?
mají atributy a/nebo participují ve vztazích?
mají vlastní identifikátor nebo přijímají identifikátor nadřazeného typu entity?
je množina podtypů úplná?
známe atributy a/nebo vztahy a podmínky, které odlišují podtyp entity od jiného typu? * ER model kontrola
atributy
má atribut jméno v jednotném čísle?
nezahrnuje jméno atributu jméno typu entity?
je atribut jednoduchý?
je dána definice formátu, délky, domény, atd.?
nejde ve skutečnosti o chybějící typ entity či vztahu?
není atribut replikován odjinud (např. z nadtypu)?
není důležité znát jeho hodnoty v čase?
závisí hodnota atributu pouze na entitě?
je-li hodnota atributu povinná, je vždy známá?
je hodnota atributu funkčně závislá na části klíče nebo na atributech, které nejsou částí klíče? * ER model kontrola
vztahy
je každý konec spojnice vztahu pojmenovaný?
má typ vztahu právě dva konce (spojnice)?
řekneme-li větu popisující vztah "inverzně", je vztah stále korektní?
má každý člen typu vztahu kardinalitu a typ členství?
je konstrukce platná?
nejde o zřídka se vyskytující konstrukce?
není typ vztahu redundantní?
vycházejí konce výlučných vztahů ze stejné entity?
má tento typ entity ve výlučných typech vztahů vždy stejný typ členství?
je vztah jen v jedné skupině výlučných vztahů? * Přístupy ke konceptuálnímu návrhu při konstrukci větších celků
mentálně obtížně zvládnutelný problém
příliš mnoho entit a ještě více vztahů
týmová práce
neexistuje nikdo, kdo by měl v hlavě celý model
strategie
shora dolů
zdola nahoru
zevnitř ven
smíšená * Přístupy ke konceptuálnímu návrhu strategie shora dolů
nejprve globální pohled na doménu aplikace
postupné zjemňování pojmů
tvorba stále podrobnějších ER diagramů
každý ER diagram popisuje celou doménu, ale v různém detailu
mentálně velmi náročná
vysoká schopnost abstrakce
na nic nezapomenout
složité zvlášť u rozsáhlých systémů
chyba v počátku se obtížně odstraňuje * Přístupy ke konceptuálnímu návrhu strategie zdola nahoru
vyjdeme z jednotlivých atributů
objekty na nejnižší úrovni
seskupujeme je a vytváříme z nich entitní typy
integrace dílčích částí do vyšších celků
generalizace
zapojení do vztahů
ISA hierarchie
tento postup je jednoduchý, ale může vyžadovat častou restrukturalizaci
na začátku může být množina dat nepřehledná
řada pojmů se objeví až na konci
* Přístupy ke konceptuálnímu návrhu strategie zevnitř ven
nejprve jeden jasný a dobře definovaný objekt
pak hledáme, do jakých vztahů a s jakými dalšími objekty tento prvotní objekt vstupuje
od jakéhosi „krystalizačního jádra“ postupujeme sítí vztahů až nejvzdálenějším entitám
speciální případ strategie zdola nahoru
nevýhoda
pohybujeme se stále na jedné úrovni abstrakce
tuto úroveň je nutno dobře odhadnout * Přístupy ke konceptuálnímu návrhu strategie smíšená
kombinace strategií zdola nahoru a shora dolů
nejprve se problém základně rozdělí na podproblémy (skeletální schema), které se následně řeší separátně
libovolná strategie řešení podproblémů
nutnost integrovat dílčí schemata
* Přístupy ke konceptuálnímu návrhu strategie návrhu
obecně nevedou k témuž výsledku
dokonce ani aplikace té samé strategie různými týmy nemusí vést ke stejnému výsledku
záleží na abstrakci, na schopnostech, na úhlu pohledu
* Integrace pohledů cíl
vytvořit z více dílčích schemat jedno
některé části se ve schematech opakují
unifikovat reprezentaci těchto částí
konflikty
strukturální
ve jménech
* Integrace pohledů strukturální konflikt
odlišná úroveň abstrakce
* Integrace pohledů strukturální konflikt
sémantický relativismus, záměna atributu za vztah
* Integrace pohledů strukturální konflikt
sémantický relativismus, hierarchie
* Integrace pohledů strukturální konflikt
nekompatibilní specifikace vztahů
rozdílné kardinality
rozdílné parciality
* Integrace pohledů strukturální konflikt
řešení
obvykle se dává přednost obecnější variantě
pokud se dva analytici koukají na tentýž problém různě, značí to určitou nejednoznačnost zadání, vybereme to řešení, které je bližší skutečné realitě
konflikt jmen
synonyma
dva analytici pojmenují stejnou věc různě
dá se odhalit
homonyma
dva analytici pojmenují různé věci stejně
to je horší, na to přichází obtížněji
* Integrace pohledů metoda
pohledy integrujeme obvykle po dvojicích a tvoříme větší celek
nebo k celku přidáváme další a další dílčí schemata
záleží na použité strategii návrhu
u smíšené strategie se začíná skeletálním schematem
při integraci nestačí ER diagram, je nutný verbální popis všech použitých pojmů
* Integrace pohledů příklad – konflikt jmen entit
nejjednodušší řešení
* Integrace pohledů lepší řešení
*
Databázové systémy 2 Kapitola 3
Transformace ER schematu do RMD Silný entitní typ přímočaré – silnému ent. typu odpovídá schema relace
stejná množina atributů
primární klíč odpovídá identifikačnímu klíči entit. typu
popisným typům atributů se přiřadí domény * Silný entitní typ vícehodnotové atributy
některé SŘBD je přímo umožňují
jestliže víme max. počet výskytů atributu, pak pro ně „rezervujeme“ místo v relaci, nevyužité budou mít například hodnotu NULL
zabírá místo
zavedeme další relaci, odpovídající vícehodnotovému atributu * Silný entitní typ skupinové atributy
nutno oželet hierarchickou strukturu atributu, uložíme pouze atomické složky
opět využijeme nové relace * Vztahový typ vztah 1:1
služební vozidla v podniku
žádný vůz není využíván více zaměstnanci
žádný zaměstnanec nevyužívá víc než jeden vůz
OSOBA
(č_osoby, ...) AUTO
(SPZ, ...) UZIVA 1 1 * Vztahový typ vztah 1:1
reprezentace závisí na tom, zda je členství ve vztahu povinné či nikoli (parcialita)
povinné členství pro oba ent. typy
každý zaměstnec má právě jedno auto
každé auto je přiděleno právě jednomu zaměstnanci
atributy obou entitních typů zařadíme do jediné relace – slévání, přilepení atributů
vztah reprezentován implicitně
klíčem bude buď č_osoby nebo SPZ
OSOBA(č_osoby, ... , SPZ, ...) * Vztahový typ vztah 1:1
povinné členství pouze pro jeden ent. typ
každé auto je přiděleno právě jednomu zaměstnanci
každý zaměstnec má žádné nebo jedno auto
dvě relace (VŮZ a OSOBA), do relace VŮZ přidáme atribut č_osoby
klíčem by mohlo být i č_osoby
OSOBA(č_osoby, ... )
VŮZ(SPZ, ..., č_osoby)
* Vztahový typ vztah 1:1
nepovinné členství pro oba ent. typy
každé auto přiděleno žádné nebo jedné osobě
každý zaměstnec má žádné nebo jedno auto
nelze přilepit atributy ani k vozu, ani k osobě
museli bychom jedině připustit prázdné hodnoty (v SQL lze)
vytvoříme třetí (vztahovou) relaci UŽÍVÁ
atributy odpovídající identifikačním klíčům obou e. typů
klíčem nové relace může být č_osoby nebo SPZ
OSOBA(č_osoby, ... )
VŮZ(SPZ, ...)
UŽÍVÁ(č_osoby, SPZ)
* Vztahový typ vztah 1:1
co když má vztah atributy?
v prvních dvou případech se přilepí tam, kde jsou klíče obou relací (č_osoby i SPZ)
ve třetím případě se přidají do nové vztahové relace
optimální reprezentace by měla také respektovat funkcionalitu
například když se agenda autoparku příliš nevyužívá, můžeme si dovolit více menších relací (pružnější odezva např. při dotazech na zaměstnance), dotaz na autopark bude pomalejší (náročná operace spojení) * Vztahový typ vztah 1:N
ent. typ PACIENT je determinantem ent. typu POKOJ, opačně to neplatí
hraje roli pouze parcialita determinantu (PACIENT)
PACIENT
(rč, ...) POKOJ
(č_pokoje, ...) UMÍSTĚN N 1 * Vztahový typ vztah 1:N
povinné členství determinantu vztahu
evidujeme pouze hospitalizované pacienty
přilepíme atribut č_pokoje k relaci PACIENT (tj. k determinantu)
PACIENT(rč, ..., č_pokoje)
POKOJ(č_pokoje, ...)
* Vztahový typ vztah 1:N
nepovinné členství determinantu vztahu
evidujeme i ambulantní pacienty
přilepíme-li atribut č_pokoje k relaci PACIENT jako v předchozím případě, musíme připustit prázdnou hodnotu (v SQL možné)
zavedení třetí (vztahové) relace UMÍSTĚN
atributy odpovídající identifikačním klíčům obou e. typů
klíčem nové relace je klíč determinantu
PACIENT(rč, ...)
POKOJ(č_pokoje, ...)
UMÍSTĚN(rč, č_pokoje)
* Vztahový typ vztah M:N
v každém případě budou tři relace (dvě pro entity, jedna pro vztah)
primárním klíčem vztahové relace bude dvojice příslušných cizích klíčů
např. vůz může náležet více zaměstnancům, jeden zaměstnanec může mít přiděleno víc vozů
OSOBA(č_osoby, ...)
VŮZ(č_vozu, ...)
POUŽÍVÁ(č_osoby, č_vozu)
* Slabý entitní typ identifikační závislost na id. vlastníkovi
identifikační vztah je speciálním případem vztahu 1:N, kde slabý entitní typ má povinné členství
tedy máme vyřešeno
slabý ent. typ má pouze parciální identifikační klíč
k relaci slabého ent. typu přilepíme atributy odpovídající identifikačním klíčům id. vlastníků
cizí klíče * Entitní podtyp (ISA hierarchie) narozdíl od slabého typu nemá žádný parciální klíč
je identifikován zdrojem ISA hierarchie
tři způsoby transformace
jediná relace se všemi atributy nadtypu i všech podtypů + další rozlišující atribut, jakého typu entita je
přímočaré, avšak mnoho prázdných hodnot
relace pro entitní podtypy
v každé relaci se opakují atributy nadtypu
relace pro každý typ (nadtyp i podtypy)
odkazy z podtypů do nadtypu
nutno dbát na disjunktnost * Výlučné vztahy
první způsob
mají-li klíče K2 a K3 stejnou doménu, lze provést
R1(K1, id, K, A)
K je cizí klíč odkazující buď na R2 nebo na R3
id je atribut, rozlišující, který vztah to je
R2(K2, B)
R3(K3, C)
* Výlučné vztahy
druhý způsob
nemají-li klíče K2 a K3 stejnou doménu
R1(K1, K2, K3, A)
nesmí být K2 i K3 současně neprázdné!
R2(K2, B)
R3(K3, C)
* Normální forma výsledných relací cíl je, aby relace byly normalizované, aspoň 3NF
závisí na citu a zkušenosti analytika
mělo by platit, že jediné závislosti, odvoditelné z ER diagramu, jsou závislosti atributů na klíči
odhalení dalších závislostí může indikovat další entitní typ
např.
PRACOVNÍK(rč, ..., č_místnosti, č_telefonu)
platí-li: č_telefonu  č_místnosti, není ve 3NF
z hlediska uživatele nemá ale dekompozice smysl, lze v SQL částečně řešit pomocí pohledů *
Databázové systémy 2 Kapitola 4
Modelování funkcí Modelování funkcí nedílnou součástí analýzy a návrhu IS je funkční analýza
modelování činností týkajících se dané aplikace
funkční analýza
jaké informace vstupují do funkcí
jak informace putují mezi funkcemi
první krok ve specifikaci aplikačních programů, jež budou nad databází operovat
komplement k datové analýze