Strukturované metodologie

Transkript

1 Strukturované metodologie

2 Strukturovaný přístup aplikace má podobu hierarchie funkcí, která je realizována strukturovanými programy styl práce: AKCE OBJEKT

3 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

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

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

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

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

8 KNIHA AUTOR mohou být: dvě entity, entita atribut (autor jako atribut knihy), nebo atribut entita (kniha jako atribut autora) Příklad 1a [1]

9 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ÁŘ) Příklad 1b [1]

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

11 Nejčastější způsoby vyjádření ERA b) grafické vyjádření [1] modelu 2

12 Nejčastější způsoby vyjádření ERA b) grafické vyjádření [1] modelu 3

13 Nejčastější způsoby vyjádření ERA b) grafické vyjádření [1] modelu 4

14 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

15 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

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

17 Vlastnosti entit 2 Znázornění hierarchie v PowerDesigneru [1]

18 Vlastnosti entit 3 [1]

19 Vlastnosti entit 3 [1] Příklad: Funkční závislost atributů entity STUDENT

20 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).

21 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

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

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

24 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í.

25 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ý)

26 Unární (rekurzívní) vztah [1]

27 Binární vztah [1]

28 Ternární vztah [1]

29 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) písmena a číslice b) číslice a symboly c) šipky d) vraní stopa (crow s foot)

30 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

31 Vlastnosti vztahů 4 Kombinované vyjádření kardinality a členství ve vztahu (min, max notace)

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

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

34 Řešení multizávislostí v entitách, které vícehodnotový atribut nejsou v 1NF 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]

35 Řešení multizávislostí v entitách, které skupinový atribut nejsou v 1NF 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ů).

36 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

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

38 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

39 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

40 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

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

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

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

44 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

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

46 Strukturovaná čeština pro slovní ENTITY popis ERA diagramů 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ů].

47 ATRIBUTY Strukturovaná čeština pro slovní popis ERA diagramů 2 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ů.

48 ATRIBUTY Strukturovaná čeština pro slovní popis ERA diagramů 3 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í).

49 KLÍČE Strukturovaná čeština pro slovní popis ERA diagramů 4 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.

50 KLÍČE Strukturovaná čeština pro slovní popis ERA diagramů 5 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.

51 KLÍČE Strukturovaná čeština pro slovní popis ERA diagramů 6 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.

52 VZTAHY Strukturovaná čeština pro slovní popis ERA diagramů 7 [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

53 VZTAHY Strukturovaná čeština pro slovní popis ERA diagramů 8 kardinalita:

54 Slovní vyjádření kardinality a členství vztah jedna jedna ve vztahu Č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.

55 Slovní vyjádření kardinality a členství vztah jedna jedna ve vztahu 2 Č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.

56 Slovní vyjádření kardinality a členství vztah jedna více ve vztahu 3

57 Slovní vyjádření kardinality a členství vztah jedna více ve vztahu 4

58 Slovní vyjádření kardinality a členství vztah jedna více ve vztahu 5

59 Slovní vyjádření kardinality a členství vztah jedna více ve vztahu 6

60 Slovní vyjádření kardinality a členství vztah více více ve vztahu 7

61 Slovní vyjádření kardinality a členství vztah více více ve vztahu 8

62 Slovní vyjádření kardinality a členství vztah více více ve vztahu 9

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

64 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

65 jedna událost jedna reakce (proces) jedna událost různé reakce (procesy) více událostí stejná reakce (proces) Typy reakcí na událost

66 Základní prvky a symboly (notace) diagramů datových toků [1]

67 Základní prvky a symboly (notace) diagramů datových toků 2

68 Hierarchický princip tvorby DFD (top-down) [1]

69 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

70 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

71 Příklad DFD [1]

72 Příklad DFD 2 [1]

73 Software Enterprise Architect PowerDesigner Oracle Designer Microsoft Visio Visual Paradigm for UML... ArgoUML...

74 Literatura [1] Kučerová, H. Projektování informačních systémů (Sylaby ke kurzu). Praha: VOŠIS, [on-line] [cit ]. Dostupné na URL: [2] BAGUI, Sigha a EARP, Richard. Database design using entity-relationship diagrams. Boca Raton : Auerbach Publications, s. ISBN [3] Velbloud. Teorie relačních databází: Normalizace. [on-line] [cit ]. Dostupné na URL: