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]



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

Strukturované metodologie

Recommend Documents