Strukturované metodologie

Strukturované metodologie
Strukturovaný přístup
• aplikace má podobu hierarchie funkcí, která je
realizována strukturovanými programy
• styl práce: AKCE  OBJEKT
Entitně–relační model (ERA)
• alternativní názvy: ERA, ERD, E–R, ER model
(schéma, diagram)
• množina pojmů sloužící k statickému popisu
aplikace na konceptuální úrovni
• model popisující objekty, které nás zajímají,
jejich vlastnosti a jejich vzájemné vztahy
• ERA diagram: grafický prostředek pro analýzu
a zobrazení datového modelu systému
Základní prvky a symboly (notace)
entitně–relačního modelu
1. typy entit (entitní typy, entity types)
• množiny objektů stejného typu (např. ČTENÁŘ,
KNIHA)
• entita: rozlišitelný a identifikovatelný objekt světa
objektů – existuje nezávisle a může být uvažován
sám o sobě
a) popsatelný objekt (odlišitelný od okolí)
b) jednoznačně identifikovatelný objekt (objekty
stejného typu musí být odlišitelné navzájem)
• znázornění: obdélník, název (podstatné jméno v
jednotném čísle)
Základní prvky a symboly (notace)
entitně–relačního modelu 2
2. typy vztahů (relationship types)
• vztahy, do kterých mohou entity vstupovat
(např. JSOU PŮJČENÉ)
• vztah: vazba mezi dvěma nebo více entitami
• znázornění: kosočtverec, čáry spojující
související entity a vztahy, název (sloveso)
Základní prvky a symboly (notace)
entitně–relačního modelu 3
3. atributy (attributes)
• funkce přiřazující entitám či vztahům hodnotu,
určující některou podstatnou vlastnost entity
nebo vztahu (např. DATUM VÝPŮJČKY)
• atribut: vlastnost entity (taková vlastnost z
množiny všech možných vlastností, která je
společná co do výskytu každému výskytu entity
nebo vztahu)
• doména: množina možných hodnot atributu
• znázornění: kružnice (ovál), název (podstatné
jméno)
Základní prvky a symboly (notace)
entitně–relačního modelu 4
4. integritní omezení
• definování vlastností entit, vztahů a atributů,
např. identifikační klíč (klíčová položka), datový
typ, kardinalita vztahu
Identifikátor (klíč) entity – podtržení názvu atributu
Pojmy atribut, entita a vztah jsou relativní – jejich
užití závisí na účelu, pro který ERA model tvoříme.
Příklad 1a [1]
KNIHA –
AUTOR
mohou být:
• dvě entity,
• entita –
atribut
(autor jako
atribut
knihy), nebo
• atribut –
entita (kniha
jako atribut
autora)
Příklad 1b [1]
KNIHA – VÝPŮJČKA
mohou být:
• dvě entity,
• entita – atribut
(výpůjčka jako
atribut knihy),
• atribut – entita
(kniha jako atribut
výpůjčky),
• entita – vztah
(výpůjčka jako
vztah mezi knihou
a nějakou další
entitou – např.
ČTENÁŘ)
Nejčastější způsoby vyjádření ERA
modelu
Příklad: Vladimír Koutecký z Prahy 4 si 2. října
2007 půjčil na tři týdny „Tajný deník Laury
Palmerové“ (signatura A1586)
a) lineární textový zápis
• E: ČTENÁŘ (Jméno, Adresa)
KNIHA (Signatura, Název)
• R: VÝPŮJČKA (Datum, Lhůta)
Nejčastější způsoby vyjádření ERA
modelu 2
b) grafické vyjádření [1]
Nejčastější způsoby vyjádření ERA
modelu 3
b) grafické vyjádření [1]
Nejčastější způsoby vyjádření ERA
modelu 4
b) grafické vyjádření [1]
Integritní omezení v ERA modelu
Vlastnosti entit:
identifikační (klíčové) atributy
ISA hierarchie
funkční závislost
Vlastnosti atributů: jméno
datový typ
identifikátor (klíčový)
povinný (NOT NULL)
unikátní (UNIQUE)
vícehodnotový
skupinový
odvozený
Vlastnosti vztahů: rozměr (stupeň)
kardinalita (mohutnost)
členství ve vztahu
Vlastnosti entit
Každou entitu jednoznačně definujeme v prostoru (tj. rozsahem
– které objekty do entity patří a které už ne?) a v čase (tj.
obdobím či událostí, po které je pro nás objekt součástí
entity).
Příklad: Entita ZÁKAZNÍK zahrnuje všechny osoby, které si od
firmy koupily její výrobek v běžném a v uplynulém
kalendářním roce a dále osoby, které mají výrobky firmy
objednané (i když je ještě nekoupily).
Identifikátor (klíčový atribut)
• atribut nebo množina atributů, jejichž hodnoty umožňují
jednoznačně rozlišit jednotlivé entity navzájem
Vlastnosti entit 2
ISA hierarchie (alternativní názvy: nadtyp/podtyp, generalizace/specializace):
entity nižší úrovně dědí atributy a sdílí identifikátor z entity nadřízené
úrovně
Příklad: Každý závodník má uvedeno jméno a stát, z nějž pochází. U motoristů
se navíc uvádí kubatura motocyklu, u fotbalistů jejich úloha v týmu, u
zápasníků hmotnost a u tenistů umístění na žebříčku ATP nebo WTA. [1]
Vlastnosti entit 2
Znázornění hierarchie v PowerDesigneru [1]
Vlastnosti entit 3 [1]
Vlastnosti entit 3 [1]
• Příklad: Funkční závislost atributů entity STUDENT
Vlastnosti entit 4
slabá (popisná) entita:
• entita existenčně nebo identifikačně závislá na jiné entitě (entitách)
silná (regulární, kmenová, základní) entita:
• entita existující nezávisle na jiných entitách
Příklad:
• ZBOŽÍ: silná entita
• OBJEDNÁVKA: slabá entita
Zboží může existovat bez objednávky, objednávka bez zboží nikoli.
Odstraníme-li nějaký výskyt (instanci) entity ZBOŽÍ (např. lednice
CALEX 3500), je nutné odstranit i výskyty (instance) entity
OBJEDNÁVKY, jež jsou na dané instanci existenčně závislé (tj.
všechny objednávky lednice CALEX 3500).
Vlastnosti entit 5
Typy funkční závislosti entit:
a) existenční závislost
• Prvky slabé entity závisí existenčně na prvcích jiné entity, tj. zrušíme-li
výskyt entity, na níž je slabá entita závislá, zrušíme i existenci závislé entity.
• Existenční závislost vždy obsahuje povinné členství ve vztahu (entita, která
je existenčně nezávislá, se povinně účastní v daném vztahu).
b) identifikační závislost (též externí identifikace)
• Prvky slabé entity závisejí identifikačně na prvcích jiné entity – tj. klíč slabé
entity definujeme pomocí klíče jiné entity (přebíráme identifikátor/y z
jiných entit). Vždy se jedná současně i o existenční závislost (entita, která je
identifikačně nezávislá, má vždy povinné členství ve vztahu).
• Identifikační závislost je zesílením existenční závislosti.
Vazební (asociativní) entita
• realizuje vazbu mezi entitami - využití: při dekompozici vztahů N:M na 1:N
Vlastnosti atributů
Vícehodnotový atribut
• Příklad: Jedna kniha může být zařazena do více žánrových
kategorií. KNIHA (Signatura, Název, Autor1, Autor2, Cena,
Místo vydání, Vydavatel, Rok vydání, Žánr:Multi, ISBN) [1]
Vlastnosti atributů 2
Skupinový atribut
• Příklad: Údaje o knize tvoří skupina evidenčních informací,
skupina vydavatelských informací a skupina obsahových
informací. KNIHA (EVIDENČNÍ INFORMACE (Signatura, Autor,
Cena), VYDAVATELSKÉ INFORMACE (Místo vydání, Vydavatel),
OBSAHOVÉ INFORMACE (Název, Žánr)) [1]
Vlastnosti atributů 3
Odvozený (derived) atribut
• Příklad: Délku výpůjčky zjistíme odečtením data
půjčení od data vrácení.
Vlastnosti vztahů
• vztahy určujeme mezi identifikátory (klíčovými
atributy) entit
• kombinace rozměru, kardinality a typu členství ve
vztahu (navzájem nezávislé)
Rozměr (stupeň) vztahu (relationship degree)
• počet výskytů entit v jednotlivém výskytu vztahu
• unární (rekurzívní), binární (dvojčlenný, dvojkový,
dvourozměrný), ternární (trojčlenný, trojkový,
třírozměrný) ... n-ární (n-rozměrný)
Unární (rekurzívní) vztah [1]
Binární vztah [1]
Ternární vztah [1]
Vlastnosti vztahů 2
Kardinalita (mohutnost, funkčnost) vztahu
• Určení počtu prvků nějakého vztahu – kolik
výskytů (instancí) jedné entity má vztah k
výskytu druhé entity?
a)
b)
c)
d)
písmena a číslice
číslice a symboly
šipky
„vraní stopa“ (crow´s foot)
Vlastnosti vztahů 3
Členství ve vztahu
• Možnost (ne)existence výskytu partnerské entity (vyžaduje
výskyt jedné entity výskyt druhé entity?)
• Členství (účast) ve vztahu (existenční závislost, úplnost) –
slovní vyjádření:
–
–
–
–
povinné (obligatorní) X nepovinné
totální (totalita) X parciální (parcialita)
úplné X částečné
mandatory X optional
Vlastnosti vztahů 4
Kombinované vyjádření kardinality a členství ve
vztahu (min, max notace)
Normalizace
Úprava modelu s cílem omezit redundanci a složitost
Postup: rozdělení složitých entit, atributů a vztahů na
jednodušší celky
Omezení redundance:
• každý atribut se má v modelu vyskytovat jen jednou
Omezení složitosti:
• každý atribut má být atomický (dále nedělitelný)
• každý atribut má být skalární (má obsahovat pouze
jednu hodnotu)
• v každé entitě mají být jen atributy, které spolu těsně
souvisejí
1. normální forma (1NF)
Řešený problém: multizávislost
• každý atribut entity musí obsahovat pouze
jeden údaj (hodnotu)
• jedna entita nesmí obsahovat násobná data
(data ve vztahu 1 : N)
Řešení multizávislostí v entitách, které
nejsou v 1NF
vícehodnotový atribut
• Příklad: Entita ZÁPIS obsahuje údaje o studentech a
předmětech, které si zapsali. Jeden student si může zapsat více
předmětů. [1]
Řešení multizávislostí v entitách, které
nejsou v 1NF
skupinový atribut
Příklad: Údaj o předmětu se skládá z jeho zkratky a z názvu v
češtině a v angličtině. [1]
Řešení: Přidání atributů (sloupců).
2. normální forma (2NF)
Řešený problém: funkční závislost
• entity obsahují pouze takové atributy, které
jsou funkčně (významově) závislé na celém
identifikátoru (primárním klíči) entity
Řešení funkčních závislostí v entitách,
které nejsou v 2NF
• Příklad: Evidence předmětů zapsaných jednotlivými studenty.
Název ani zkratka předmětu nejsou funkčně závislé na ID
studenta. [1]
• Řešení: Rozdělení dat do více entit.
3. normální forma (3NF)
Řešený problém: tranzitivní závislost
• žádný neklíčový atribut entity nesmí být
závislý na jiném neklíčovém atributu
Boyce Coddova normální forma (BCNF)
Byla původní definicí 3NF
• je to vlastně variace 3NF
• podmínka pro 3NF (nezávislost atributů) musí
platit i pro hodnoty uvnitř složeného klíče
4. normální forma (4NF)
Řešený problém: vztahy uvnitř složeného
primárního klíče
• pokud je v tabulce složený primární klíč, může
se stát, že některé hodnoty tohoto klíče jsou
na sobě nezávislé, ale tím, že spolu tvoří klíč,
vzniká falešná souvislost mezi těmito
hodnotami a nemohou existovat nezávisle na
sobě, což není v souladu s modelovanou
realitou
5. normální forma (5NF)
Řešený problém: týká se primárních klíčů, které
jsou tvořeny nejméně třemi atributy
• v případě, že mezi atributy v klíči existují
párové cyklické závislosti, je třeba tyto
závislosti extrahovat do samostatných tabulek,
ale původní tabulku je v některých případech
třeba zachovat
Podrobněji k normalizaci např. viz [3]
Metodika tvorby ERA diagramu [1, 2]
1. Zvolte jednu primární entitu ze specifikace požadavků.
2. Určete atributy, jejichž hodnoty se mají pro tuto entitu zaznamenávat.
Označte případné klíče (identifikátory) a vytvořte ukázková data.
3. Popište slovně navrženou entitu, její atributy a klíče.
4a. Prověřte funkční vztahy (závislosti) atributů a v případě potřeby entitu
normalizujte.
4b. Prověřte atributy navržené entity (pokud možno ve spolupráci s
uživatelem) a zjistěte, zda je třeba zaznamenávat informace o jednom či
více atributech v nové samostatné entitě.
5. Je-li vhodné vytvořit další entitu, zakreslete ji do diagramu a vraťte se na
krok 2.
6. Spojte entity vztahy, pokud tyto existují. Popište slovně vztahy mezi
entitami z obou stran.
7a. Prověřte seznam atributů a určete, zda některé z nich potřebují být
identifikovány prostřednictvím dvou (či více) entit. Pokud ano, umístěte
atribut na příslušný vztah, který spojuje dané entity.
7b. Prověřte, zda v diagramu nemáte „smyčky“ (kružnice), které mohou
indikovat nadbytečné (odvozené) vztahy. Pokud je vztah skutečně
redundantní, odstraňte ho.
8. Vytvořte ukázková data.
9. Předveďte navržený model (diagram i slovní popis) uživateli. Pokud je to
třeba, upřesněte diagram.
Možné přístupy k tvorbě ERA diagramu
• 1. zdola nahoru (bottom-up)
– nejprve sestavíme seznam atributů, pak je
seskupíme do entit
• 2. shora dolů (top-down)
– nejprve definujeme entity, pak je naplníme
atributy
Ukázky např. na:
http://web.sks.cz/users/ku/DAS/era.htm
Pravidla návrhu správných ERA
diagramů
• Zobrazujeme pouze data a jejich vztahy, žádné procesy
• Každý atribut zobrazujeme pouze jednou – cílem je
strukturovat seznam atributů, nikoli např. znázorňovat
propojení v relační databázi
• Zobrazujeme seskupení dat pro účely databáze, nikoli
pro účely výstupů (kombinaci atributů z různých entit a
případné duplicity realizují až pohledy – formuláře
nebo sestavy)
• Zobrazujeme pouze perzistentní (trvalé) datové objekty
– data, jež hodláme vygenerovat výpočty a agregacemi,
nemodelujeme
Pravidla návrhu správných ERA
diagramů 2
• Zobrazujeme pouze nezbytně nutné vztahy, tj. ty, které k něčemu
využijeme (např. k propojení v dotazu) – nezobrazujeme:
– odvozené vztahy
– kruhové závislosti (smyčky)
– redundantní vztahy
Příklad: Redundantní vztah STUDENT–UČITEL:
• Entity mají být normalizované (např. atributy, mezi kterými je vztah 1 : N,
nepatří do stejné entity)
• Pozor na tyto entity:
–
–
–
–
entita bez atributů
entita, která má pouze identifikátor a žádné další atributy
entita, u níž nastane pouze jeden výskyt
entita, která obsahuje atributy patřící jiným entitám (tzv. cizí atributy)
„Strukturovaná čeština“ pro slovní
popis ERA diagramů
ENTITY
• Informační systém zaznamenává údaje o [název
entity]. Pro každou [název entity] zaznamenáváme v
informačním systému [názvy atributů].
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 2
ATRIBUTY
a) Atomické atributy
Pro každou [název entity] bude existovat vždy jeden a pouze jeden [název atributu].
Hodnota [název atributu] se nebude dále členit (na dílčí údaje).
Pro každou knihu bude vždy jeden a pouze jeden název. Hodnota názvu se nebude dále
členit.
b) Složené (skupinové) atributy
Pro každou [název entity] budeme zaznamenávat [název atributu], který se skládá z
x, y, z…, (x, y, z) jsou součástmi [název atributu].
Pro každou knihu budeme zaznamenávat vydavatelské údaje, jež se skládají z názvu
vydavatele, místa vydání a roku vydání. Název vydavatele, místo vydání a rok vydání
jsou součástí vydavatelských údajů.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 3
ATRIBUTY
c) Vícehodnotové atributy
Pro každou [název entity] budeme zaznamenávat [název atributu]. Může být
zaznamenán více než jeden [název atributu] pro každou [název entity].
Pro každou knihu zaznamenáváme autory. Může být zaznamenán více než jeden autor
pro každou knihu.
d) Odvozené atributy
Pro každou [název entity] může existovat [název atributu], který bude odvozen
z databáze.
Pro každou knihu může existovat lhůta (počet dnů zapůjčení), která bude odvozena z
databáze (odečet data výpůjčky od data vrácení).
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 4
KLÍČE
a) Jeden kandidát klíče (silná entita)
Pro každou [název entity] budeme mít následující primární klíč:
[název atributu].
Pro každou knihu budeme mít následující primární klíč: přírůstkové číslo.
b) Více než jeden kandidátní klíč (silná entita)
Pro každou [název entity] budeme mít následující kandidátní klíče:
[názvy atributů].
Pro každou knihu budeme mít následující kandidátní klíče: přírůstkové číslo,
signatura, ISBN.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 5
KLÍČE
c) Žádní kandidáti klíče (slabá entita)
Pro žádnou [název entity1] nepředpokládáme, že by kterýkoli z atributů byl
dostatečně unikátní, aby identifikoval individuální [název entity1] bez
doplňujícího odkazu na [název entity2], vlastnickou silnou entitu.
Pro žádnou rezervaci nepředpokládáme, že by kterýkoli z atributů byl natolik
unikátní, aby identifikoval individuální rezervaci bez doplňujícího odkazu na
knihu, vlastnickou entitu.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 6
KLÍČE
d) Žádní kandidáti klíče (vazební entita)
Pro žádnou [název vztahové entity] nepředpokládáme, že by kterýkoli z
atributů byl dostatečně unikátní, aby identifikoval individuální [název
vztahové entity] bez doplňujícího odkazu na [název entity2], vlastnickou
entitu.
Pro žádnou výpůjčku nepředpokládáme, že by kterýkoli z atributů byl natolik
unikátní, aby identifikoval individuální výpůjčku bez doplňujícího odkazu na
knihu a čtenáře, vlastnické entity.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 7
VZTAHY
[název entity1] [název vztahu – aktivum] [název entity2]
a
[název entity2] [název vztahu – pasivum] [název entity1]
Čtenáři si půjčují knihy a knihy jsou půjčovány čtenáři.
nebo
Čtenář si půjčuje knihy a kniha se půjčuje čtenářům
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 8
VZTAHY
• kardinalita:
Slovní vyjádření kardinality a členství
ve vztahu
vztah jedna – jedna
Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha
může být půjčena pouze jednomu čtenáři, nemusí být půjčena žádnému
čtenáři.
Čtenář si musí půjčit jednu a právě jednu knihu. Kniha může být půjčena pouze
jednomu čtenáři, nemusí být půjčena žádnému čtenáři.
Slovní vyjádření kardinality a členství
ve vztahu 2
vztah jedna – jedna
Čtenář si musí půjčit jednu a právě jednu knihu. Kniha musí být půjčena
jednomu a právě jednomu čtenáři.
Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha
musí být půjčena jednomu a právě jednomu čtenáři.
Slovní vyjádření kardinality a členství
ve vztahu 3
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 4
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 5
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 6
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 7
vztah více – více
Slovní vyjádření kardinality a členství
ve vztahu 8
vztah více – více
Slovní vyjádření kardinality a členství
ve vztahu 9
vztah více – více
Diagram datových toků (DFD)
DFD – data flow diagram
• grafický prostředek návrhu a zobrazení funkčního
modelu systému
funkční model:
• pohled na realitu jako na souhrn neustále
vznikajících různých událostí
• popis procesů a jejich návazností
• popis procesů transformace informace a jejich
vzájemných vztahů
Událost – stimul – reakce
událost: to, co nastane a systém na to musí reagovat – stimul,
který spouští zpracování uvnitř systému
typy událostí:
– příchod dat do systému z okolí (např. zápis nového studenta)
– událost spojená s časem (např. týdenní kontrola prošlých
výpůjčních lhůt)
– řídící událost (vyžádání reakce řídícím prvkem vně systému –
např. výkaz práce na daném úkolu)
stimul: datový tok – sděluje systému, že událost nastala
reakce:
· výstupní datový tok do okolí
· uložení dat v systému
Typy reakcí na událost
• jedna událost –
jedna reakce
(proces)
• jedna událost –
různé reakce
(procesy)
• více událostí –
stejná reakce
(proces)
Základní prvky a symboly (notace)
diagramů datových toků [1]
Základní prvky a symboly (notace)
diagramů datových toků 2
Hierarchický princip tvorby DFD
(top-down) [1]
Kontextový diagram
• lidé, organizace, systémy, které s
modelovaným systémem komunikují
• data, která systém dostává z okolí a která musí
zpracovat
• data, která systém produkuje
• datastory sdílené systémem a terminátory
(zdroj nebo místo určení dat mimo systém)
• seznam událostí, na které musí systém
reagovat
Doporučený postup tvorby DFD
1. vytvořit kontextový diagram
2. sestavit seznam událostí
3. pro každou událost vytvořit proces (proces = reakce
na událost)
4. každý proces pojmenovat podle reakce na událost
5. ke každému procesu doplnit vstupy, výstupy, příp.
datastory
–
–
jaká data proces potřebuje?
co je jeho výstupem?
6. kontrola konzistence – všechny vstupy a výstupy z
kontextového diagramu se musíobjevit v DFD
Příklad DFD [1]
Příklad DFD 2 [1]
Software
•
•
•
•
•
•
•
•
Enterprise Architect
PowerDesigner
Oracle Designer
Microsoft Visio
Visual Paradigm for UML
...
ArgoUML
...
Literatura
• [1] Kučerová, H. Projektování informačních systémů (Sylaby ke
kurzu). Praha: VOŠIS, 2007. [on-line] [cit. 6.12.2011].
Dostupné na URL:
http://web.sks.cz/users/ku/DOKUMENTY/pri_syl.pdf
• [2] BAGUI, Sigha a EARP, Richard. Database design using
entity-relationship diagrams. Boca Raton : Auerbach
Publications, 2003. 264 s. ISBN 0849315484.
• [3] Velbloud. Teorie relačních databází: Normalizace. [on-line]
[cit. 6.12.2011]. Dostupné na URL:
http://www.manualy.net/article.php?articleID=13