Strukturované metodologie



Podobné dokumenty
Metodika návrhu databáze

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

DBS Konceptuální modelování

Databázové modelování. Analýza Návrh konceptuálního schématu

Databáze I. 4. přednáška. Helena Palovská

Konceptuální modelování. Pavel Tyl

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy

Funkční schéma Datové schéma Integrita modelu s realitou

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Databáze 2013/2014. Konceptuální model DB. RNDr. David Hoksza, Ph.D.

Analýza a modelování dat. Helena Palovská

DATOVÉ MODELOVÁNÍ ER MODEL

2 Konceptuální modelování a návrh databáze

2 Konceptuální modelování a návrh databáze

Úvod do softwarového inženýrství IUS 2009/2010 p.1/30

Databáze. Logický model DB. David Hoksza

Modelový příklad Knihovna Vypracovaný příklad ze cvičení včetně komentářů k řešení

Databázové systémy. Vztahy a relace. 3.přednáška

Obsah přednášky. Databázové systémy. Normalizace relací. Normalizace relací. Normalizace relací. Normalizace relací

Database engine (databázový stroj, databázový motor, databázové jádro) Systém řízení báze dat SŘBD. Typy SŘBD podle způsobu práce s daty

Databázové systémy I

Databázové systémy. Cvičení 2

Obsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel

Diagram výskytů a vztahů

5. Formalizace návrhu databáze

4IT218 Databáze. 4IT218 Databáze

Modelování procesů s využitím MS Visio.

5. Formalizace návrhu databáze

RELAČNÍ DATABÁZOVÉ SYSTÉMY

Hierarchický databázový model

Konceptuální datové modely používané při analýze

Strukturované metody Jan Smolík

Úvod do databázových systémů 6. cvičení

Databáze I. Přednáška 3

Databázové systémy. Cvičení 3

DBS Konceptuální modelování

4. Základy relačních databází, logická úroveň návrhu

Konceptuální modelování

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

Otázka č. 1 (bodů za otázku: 4)

4IT218 Databáze. 4IT218 Databáze

Návrh databázového modelu

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS

Relační datový model. Integritní omezení. Normální formy Návrh IS. funkční závislosti multizávislosti inkluzní závislosti

Vývoj IS - strukturované paradigma II

Kapitola 7: Návrh relačních databází. Nástrahy relačního návrhu. Příklad. Rozklad (dekompozice)

2. Modelovací jazyk UML 2.1 Struktura UML Diagram tříd Asociace OCL. 3. Smalltalk 3.1 Jazyk Pojmenování

Analýza dat a modelování. Přednáška 1

C8 Relační databáze. 1. Datový model

Databázové systémy. Přednáška 1

Databázové systémy Tomáš Skopal

Analýza a modelování dat 3. přednáška. Helena Palovská

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

Terminologie v relačním modelu

DBS Transformace konceptuálního schématu na

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

A5M33IZS Informační a znalostní systémy. O čem předmět bude? Úvod do problematiky databázových systémů

Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace

9 Strukturovaná analýza

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

10 Metody a metodologie strukturované analýzy

Jiří Mašek BIVŠ V Pra r ha

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola

CVIČENÍ 4 G:\KU\DAS\PDOXWIN\KNIHOVNA

Relace x vztah (relationship)

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

Databázové systémy. Tomáš Skopal. - úvod do relačního modelu. - převod konceptuálního schématu do relačního

Databázové systémy. Ing. Radek Holý

Databázové systémy. Cvičení 1

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19

Entitno - relačný model. Jaroslav Porubän, Miroslav Biňas, Milan Nosáľ (c)

UNIVERZITA PARDUBICE FAKULTA EKONOMICKO-SPRÁVNÍ

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

9 Strukturovaná analýza

Úvod do databázových systémů. Lekce 1

SQL - trigger, Databázové modelování

Střední průmyslová škola Zlín

Úvod do databázových systémů 10. cvičení

UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0

Databáze I. Přednáška 2

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi.

DATABÁZE A INFORMAČNÍ SYSTÉMY

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR):

Úvod do databázových systémů. Ing. Jan Šudřich

Základní informace. Modelování. Notace

Metody popisu systému, základy UML

A Metodologie návrhu ERD (Batini, Ceri, Navathe)

Okruhy z odborných předmětů

Úvod do databázových systémů

Databázové systémy. modelování. Tomáš Skopal. - úvod. - konceptuální datové

Databázové systémy. Normálové formy + kandidátní klíče. 2.přednáška

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Úvod do databázových systémů 2012/2013 IS MHD

Transformace konceptuálního modelu na relační

A Metodologie návrhu ERD (Batini, Ceri, Navathe)

Úloha 1. Úloha 2. Úloha 3. Text úlohy. Text úlohy. Text úlohy

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Analýza problémové domény

Transkript:

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.

KNIHA AUTOR mohou být: dvě entity, entita atribut (autor jako atribut knihy), nebo atribut entita (kniha jako atribut autora) Příklad 1a [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ÁŘ) Příklad 1b [1]

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 b) grafické vyjádření [1] modelu 2

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

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

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) písmena a číslice b) číslice a symboly c) šipky d) 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é 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]

Ř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ů).

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í 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ů].

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

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

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.

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.

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.

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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