9. blok Fáze návrhu databáze, konceptuální modelování

Save this PDF as:
 WORD  PNG  TXT  JPG

Rozměr: px
Začít zobrazení ze stránky:

Download "9. blok Fáze návrhu databáze, konceptuální modelování"

Transkript

1 9. blok Fáze návrhu databáze, konceptuální modelování Studijní cíl Tento blok je věnován základům databázového modelování. V základu budou probrány jednotlivé fáze návrhu databáze. Dále bude student tohoto bloku seznámen s relačním modelem dat, jenž je podstatný pro pochopení databázového modelování. Dále se bude tento blok detailněji zabývat fází konceptuálního modelování. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen se základními pojmy z oboru databázových systémů, jako jsou relační datový model, databázový systém, tabulka, relace. 1. Fáze návrhu databáze V této části bloku budou popsány jednotlivé části životního cyklu vývoje databázového systému. Při definování životního cyklu je důležité si uvědomit, že jeho jednotlivé fáze nemusí striktně následovat za sebou. Někdy se mohou jednotlivé fáze po sobě opakovat, jako součást kontrolního mechanismu vývoje aplikace pro databázový systém. Díky těmto opakováním se mohou identifikovat a eliminovat chyby učiněné v předcházejících fázích návrhu. Základním kamenem každého databázového projektu je stanovení si cíle spolu se stanovením jednotlivých dílčích cílů. Pod stanovením cíle se můžeme představit stanovení hlavního poslání databázového systému. Pod dílčími cíly si naopak můžeme představit jednotlivé kroky na cestě k finální podobě aplikace využívající databázový systém. S pojmem návrhu databáze úzce souvisí pojem metodologie návrhu. Metodologie návrhu je strukturovaný přístup používající procedury, techniky, nástroje a dokumentaci s cílem podpořit a usnadnit proces návrhu. Metodologie návrhu se 1

2 tedy skládá ze stádií a stádia lze dále dělit na jednotlivé kroky. Stádia jsou vhodná pro plánování, kontrolu a zhodnocení vývojového projektu. Proces tvorby návrhu databázového systému je určen k definici všech prostředků, které budou podporovat celkové poslání, ale i dílčí cíle pro výsledný databázový systém. Proces návrhu databázového systému můžeme rozčlenit na tři základní fáze. Konceptuální, logický a fyzický návrh. Fáze konceptuálního návrhu se snaží o identifikaci podstatných objektů (entit), které budou v rámci databázového systému implementovány. Zároveň se v této fázi hledají i vazby mezi nalezenými objekty. Tato fáze návrhu by měla být absolutně nezávislá na úvahách o pozdějším fyzickém provedení systému. Ve fázi logického návrhu dochází k převodu nalezených objektů a pojmenovaných relací mezi nimi na množinu tabulek. V této části přichází na řadu popis modelu pomoci specifického modelu dat. Typicky se využívá relačního modelu dat, který je ovšem zbaven úvah o fyzické realizaci modelu. Ve fázi fyzického návrhu databáze dochází k rozhodnutím o implementaci v prostředí cílového databázového systému. V této fázi je nutná velmi dobrá znalost cílového databázového systému, ve kterém bude výsledná aplikace implementována. 2

3 Plánování databáze Definice systému Sběr a analýza požadavků Návrh databáze Konceptuální návrh Logický návrh Fyzický návrh Implemetace Obrázek 1 - Fáze návrhu databáze 3

4 2. Před návrhové fáze vývoje databázového systému. Výše popsané fáze návrhu (konceptuální, logický a fyzické) budou probrány v rámci bloků e-learningu velmi detailně. Tato kapitola se věnuje fázím, které probíhají ještě před samotnou fází návrhu databáze. Ačkoliv se tyto fáze neřadí přímo do databázového návrhu, jsou pro jednotlivé fáze databázového návrhu velmi důležité. Mezi tyto fáze se řadí: Plánování databáze. Definice systému. Sběr a analýza požadavků. Fáze plánování databáze je počátečním bodem databázového projektu. V této fázi jsou stanoveny základní cíle a priority celého projektu. Je stanoven hlavní cíl databázového systému. Zároveň se stanovují i milníky, kterých je nutné postupně dosahovat. Jako u jiných softwarových projektů by měl být stanoven odhad rozsahu potřebné práce, rozdělení práce mezi členy vývojového týmu a v neposlední řadě se odhaduje i finanční náročnost celého projektu. Často se ve fázi plánování databáze, především u větších projektů, definují standardy vývoje. Tzn., jsou stanoveny standardy sběru dat, způsoby specifikace formátů, formát dokumentace či postup návrhu a implementace. Při definici systému dochází k identifikaci rozsahu a hranic systému, který zkoumáme, identifikuje se rozhraní vůči jiným informačním systémům. Při definici systému se nesledují pouze aktuální uživatelské pohledy, nýbrž musí být počítáno se všemi předpokládanými budoucími pohledy. Přesto jsou uživatelské pohledy velmi důležitou částí definice systému. Uživatelský pohled definuje to, co se od databázového systému požaduje z hlediska konkrétního pracovního postavení (může to být pohled vysokého manažera společnosti stejně jako pohled běžného pracovníka), či se může jednat o pohled určité provozní oblasti (marketing, lidské zdroje, CRM, ). Databázový systém má tak většinou více uživatelských pohledů. Uživatelské pohledy jsou velmi důležité, pomáhají totiž zajistit, že žádný významný uživatelský aspekt není opomenut. Jejich užitečnost navíc stoupá spolu se složitostí modelovaného systému, protože umožňují rozčlenit modelovaný systém na menší, lépe zvladatelné celky. Jiná definice hovoří o uživatelských pohledech jako o požadavcích na to, jaká data budou do databáze ukládaná a jaké transakce se s daty budou provádět. Závěrečnou přípravnou fází před zahájením samotného modelovaní je fáze sběru požadavků a jejich následná analýza. V této fázi proběhne sběr a analýza informací 4

5 o organizaci či objektu zájmu, kterému bude databáze sloužit. Sběr informací se provádí pro každý významný uživatelský pohled a jeho součástí bývá: popis používaných nebo vytvářených dat, podrobnosti o tom, jak jsou data vytvářena a používána, všechny další požadavky na databázový systém. Tyto informace se následně analyzují, aby se určily požadavky, které je nutné implementovat do návrhu nového databázového systému. Tyto požadavky se dále archivují jako součást specifikace požadavků. Určení těch správných požadavků je kritická činnost, neboť systém s neúplnou implementací uživatelských požadavků může být z pohledu uživatele těžko použivatelný a může to vést až k odmítnutí systému jako celku. 5

6 3. Konceptuální návrh databáze Ve fázi konceptuálního návrhu databáze je vytvořen tzv. konceptuální model dat, jenž je založen na datech získaných z analýzy objektu, který se snažíme převést do cílového databázového systému. Obvyklým výstupem konceptuálního návrhu databáze je ER diagram. Ovšem v tomto případě se jedná o ER diagram vysoké úrovně obsahující úplnou reprezentaci datových požadavků objektu, který má databáze podporovat. Konceptuální fáze návrhu identifikuje podstatné entity a relace 1, které bude nutné v databázi reprezentovat. Konceptuální návrh je základní zdroj informací pro fázi logického návrhu. Pro konceptuální návrh jsou podstatné tyto úkoly: Krok 1 Identifikace entit. Krok 2 Identifikace relací. Krok 3 Identifikace atributů a spojení atributů s entitami a relacemi. Krok 4 Nalezení domén atributů. Krok 5 Vyhledání kandidátních, primárních a alternativních klíčů. Krok 6 Kontrola redundance v modelu. Krok 7 Posouzení zda model podporuje uživatelské transakce. Jelikož standardním výstupem této fáze bývá ER diagram, je dobré připomenout základní prvky, které by měl výsledný ER diagram obsahovat: entity, relace, atributy a domény atributů, primární klíče a alternativní klíče, integritní omezení Krok 1 Identifikace entit Počáteční krokem při tvorbě ER modelu by měla být identifikace hlavních objektů modelovaného systému. Tyto objekty pak představují entity pro model. Standardně považujeme za entitu rozlišitelný a identifikovatelný objekt reality. Nebo též se dá entita definovat jako objekt reálného světa, který je předmětem zájmu a má smysl o něm uchovávat informace. Z pohledu modelu se entitami mohou stát osoby, hmotné i nehmotné objekty, události (rezervace, objednávka, reklamace, ) či pojmy důležité z pohledu modelovaného systému. 1 V rámci e-learningových lekcí je pojem relace chápán jako vztah mezi dvěma entitami (tabulkami) a nikoliv ve smyslu relační algebry, kdy pojem relace označuje tabulku. 6

7 Vymezit samotný pojem entita je relativně složité. Samotný pojem entita je dosti volně definován, jelikož neexistuje jednoznačné pravidlo, které by říkalo, která data klasifikovat jako entity a která data zase jako relace. Velmi přitom závisí na osobním úhlu pohledu dané osoby, která model vytváří. Jednou z možných metod identifikace entit je zkoumání uživatelských požadavků, především pak slovníku dat. V tomto slovníku se pak můžeme zaměřit především na podstatná jména, která mohou posloužit jako kandidátní entity. Naopak slovesa ze slovníku můžou být označena jako kandidáty na relace. Při hledání entit na základě slovníku dat se postupuje tak, že se v dokumentu vyhledávají hlavní objekty zájmu (například osoby, pojmy či zájmy) a dochází k vyloučení položek, které jen označují vlastnosti jiných objektů. Jinou cestou při hledání entit je nalezení objektů se samostatnou existencí. Například položka Student může být entitou, neboť student existuje i bez toho, abychom znali jeho jméno, adresu či jiné osobní informace. Jednou z největších komplikací při zjišťování entit z datového slovníku může být to, že entity v datovém slovníku nemusí vyskytnout přímo. Můžou se tam objevit jejich příklady či jejich analogie. Například místo klíčového slova student se mohou ve slovníku dat vyskytnout konkrétní studenti či různé typy studentů (prezenční student, student kombinovaného oboru, student magisterského programu, absolvent, ). Celý problém je navíc komplikovaný tím, že uživatelé často uvádějí ve slovníku dat synonyma a homonyma. Při používaní synonym se často ve slovníku dat objevují pojmy, které mají ve své podstatě stejný význam (přeprava - transport). V případě homonyma dochází k používání slov, jejž mají význam v závislosti na použitém kontextu (program program kina, plán práce, studijní program nebo program jako software). Při výběru těch správných entit by nám měly pomoci postupné iterace. Aplikací iterací na fázi identifikace entit pomůže odfiltrovat nalezená synonyma a zároveň pomůže ujasnit význam nejednoznačně pojmenovaných entit. Výstupem fáze identifikace entit by měl být seznam entit. Uvažujeme li například informační systém pro VŠ, mohl by tento seznam obsahovat následující položky: Student Vyučující Program Obor Studijní materiál Zkouška Předmět Fakulta Test Práce Hodnocení výuky 3.2. Krok 2 Identifikace relací Po identifikaci entit přichází na řadu fáze identifikace relací (vztahů), které mezi entitami existují. Zde nám opět mohou pomoci specifikace uživatelských 7

8 požadavků, ve kterých budeme předně vyhledávat slovesné výrazy. Typicky se může jednat o výrazy typu: Student si zapisuje Předměty. Student se přihlašuje na Zkoušku. Vyučující vyučuje Předmět. Důležité při hledání relací mezi entitami je zaměřit se na relace, které jsou uživatelskými požadavky požadované. Mezi entitami může být totiž mnoho relací, ale jen některé mohou být skutečně požadované. Nepožadované relace, i když jsou myslitelné, se pak do výsledného modelu nemodelují. Navíc některé relace mohou být modelovány jinou relací (relacemi) a jejich zahrnutí do modelu by vedlo k tzv. redundantní (nadbytečné) relaci. Velkou pozornost je tedy nutné věnovat všem relacím (explicitním i implicitním) zaznamenaným ve specifikaci uživatelských požadavků. V principu by tedy mělo dojít ke kontrole všech dvojic nalezených entit. Důležité je uvědomit si, že entita nemusí mít žádný vztah k jiným entitám, ale může být pro námi modelovaný systém podstatná z pohledu plnění uživatelských požadavků. Proto by neměla být přijata myšlenka, že entita bez vazby na okolní entity je pro systém bezvýznamná a proto může být z modelu odstraněna. Dále je dobré uvědomit si, že ve valné většině případů budou nalezené relace binární, tedy že se budou týkat přesně dvou entit. To ovšem neznamená, že by mělo být z procesu identifikace relací vyřazeno hledání relací unárních (relace týkající se jedné entity), či relací obsahující více entit. Pro přehledné zobrazení relací, můžeme využít následující tabulku: Entita Relace Entita Student Zapisuje Předmět Student Přihlašuje Zkouška Vyučující Učí Předmět Vyučující Vytváří Zkouška Program Má Obor Fakulta Nabízí Program Student Studuje Fakulta Tabulka 1 - Tabulka nalezených relací Často je lepší místo velké tabulky relací uvést relace v grafické podobě. Viz zjednodušený obrázek: 8

9 Student Zapisuje > Předmět < Učí Vyučující Přihlašuje > Vytváří Studuje > Zkouška Fakulta Nabízí > Má > Program Obor Obrázek 2 - Grafická reprezentace relací 2 Po identifikaci všech relací, které jsou z pohledu výsledného modelu podstatné, přichází na řadu určení multiplicity každé z relací. Multiplicita vyjadřuje počet výskytů jedné entity, které se mohou vztahovat k jedinému výskytu související entity. Multiplicita se považuje za jedno z integritních omezení. Pokud budeme uvažovat o binární relaci, multiplicita může mít podobu jedna k jedné (1:1), jedna k více (1:*, 1:N) a více k více (*:*, M:N). Pokud se na místě jedničky objeví nula (0:1,0:N), znamená to, že daná entita se vztahu účastnit nemusí. Za příklad multiplicity 1:1 můžeme považovat např. takový vztah Zaměstnance a Fakulty, kdy můžeme říct, že jeden Zaměstnanec může řídit maximálně jednu fakultu a zároveň jedna fakulta může být řízena jedním zaměstnancem. Vztah 1:* (1:N) se dá reprezentovat vztahem mezi Fakultou a Programem. Jedna Fakulta může nabízet n studijních programů, avšak jeden studijní program může být nabízen nejvýše jednou fakultou. A nakonec vztah *:* (M:N) může být reprezentován vztahem mezi Studentem a Předmětem, kdy jeden Student může studovat více Předmětů a zároveň jeden Předmět může být studován více Studenty. Po určení jednotlivých multiplicit můžeme rozšířit naší původní tabulku: Entita Multiplicita Relace Multiplicita Entita Student 1..* Zapisuje 0..* Předmět Student 1..* Přihlašuje 0..* Zkouška Vyučující 1..* Učí 0..* Předmět Vyučující 1..1 Vytváří 0..* Zkouška Program 1..1 Má 1..* Obor Fakulta 1..1 Nabízí 1..* Program Student 0..* Studuje 1..1 Fakulta Tabulka 2 - Tabulka nalezených relací spolu s údajem o multiplicitě 2 V tomto případě se jedná o ER digram vytvořený pomocí notace UML. Existují i jiné notace. Tyto notace jsou uvedený na závěr tohoto bloku v kapitole o ER diagramech. 9

10 Dle údajů v tabulce můžeme aktualizovat zjednodušený model: Student 0..N Zapisuje > Předmět 1..N 0..N 0..N 1..N < Učí Vyučující 1..1 Studuje > Přihlašuje > 0..N Zkouška 0..N < Vytváří 1..1 Fakulta Nabízí > 1..* Má > 1..* Program Obor Obrázek 3 - Grafická reprezentace relací doplněná o multiplicity 3.3. Krok 3 - Identifikace atributů a spojení atributů s entitami a relacemi. Dalším krokem při tvorbě ER diagramu při konceptuálním modelovaní je identifikace faktů (vlastností), které budeme o entitách a relacích zpracovávat. Z těchto faktů se následně stanou atributy databázového modelu. Jedním ze způsobů, jak tyto atributy identifikovat, je opět prozkoumat uživatelské požadavky, především pak slovník dat. Při identifikaci entit se ve slovníku hledají zejména podstatná jména, při identifikaci relací se pozornost zaměřuje na slovesa. Při identifikaci atributů dochází k hledání jmenných frází (číslo studenta, název předmětu, jméno, titul, ). Atributy ve většině případů vyjadřují nějakou vlastnost či stav dříve identifikované entity nebo relace. Jednou z dalších cest jak nalézat atributy je u každé entity a relace si položit prostou otázku: Jaké informace o dané entitě/relaci bude nutné uchovávat?. Atributy můžeme rozdělit do následujících skupin: Jednoduché/složené atributy. Odvozené atributy. Atributy relací. Jednoduchý atribut je takový atribut, který už je dále nedělitelný. Příkladem takového atributu může být například křestní jméno. Naopak složeným atributem se rozumí takový atribut, který je možné dále rozložit na jednoduché/složené atributy. Příkladem může být adresa, kterou lze dále dekomponovat na ulici, číslo popisné, město atd. Příklad složeného atributu: 10

11 Adresa Ulice Město PSČ Název Číslo Popisné Evidenční Orientační Obrázek 4 - Složený atribut Kromě rozdělení atributů na jednoduché a složené, existuje jejich rozdělení na atributy s jedinou hodnotou a na atributy s více hodnotami. Za atribut s jedinou hodnotou můžeme považovat například atribut jméno u entity Člověk. Taková entita bude mít vždy jedno charakteristické jméno. Typickým představitelem atributu s více hodnotami je telefonní číslo. Každá osoba totiž může potenciálně mít více telefonních čísel (číslo domů, mobilní telefon, pracovní telefon, ). Pro zobrazení vícehodnotového atributu jsou prakticky dvě možnosti. Buďto atribut znázorníme spolu s danou entitou a označíme ho jako vícehodnotový, nebo se z daného atributu vytvoří samostatná entita (např. Telefonní číslo), která by se vztahovala k původní entitě přes relaci jedna k více (1:*). Atribut, který je odvoditelný (vypočitatelný) z jiných atributů, se označuje jako odvozený atribut. Ačkoliv se ve výsledném modelu tyto atributy neobjeví, je třeba je v modelu uchovávat, aby nedošlo ke ztrátě informací při modifikaci nebo odstranění atributů, ze kterých by atribut byl odvozen. Je důležité vědět, že ačkoliv entity jsou tvořeny atributy, tak ne vždy platí, že daný atribut je pevně svázán s danou entitou. V určitých případech se takový atribut může pojit k určité relaci. Takový atribut pak nazýváme atributem relace. Příkladem může být atribut datum_nastupu (vyjadřuje, kdy daný student na fakultu nastoupil), který má smysl až ve chvíli, kdy je realizována relace mezi studentem a fakultou. Velmi často se stává, že se po připojení atributů k relacím a entitám objeví entity nové, které byly v předchozích krocích opomenuty. V tomto případě je nutné vrátit se k prvnímu kroku, zaevidovat nové entity a provést revizi souvisejících relací. Může se stát, že po přiřazení atributů entitám bude více entit sdílet stejné (nebo velmi podobné) sady atributů. V tu chvíli se dá uvažovat o reprezentování těchto entit pouze entitou jedinou. 11

12 Výstupem tohoto kroku může být jednoduchá tabulka, která vyjadřuje vztah jednotlivých entit s vybranými atributy. Složené atributy se uvádí v závorce. Entita Student Předmět Zkouška Atributy cislostudenta, jmenostudenta (složený: stjmeno, stprijmeni), stdatumnarozeni, strodnecislo, adresa (složený: stulice, stcp, stměsto, stpsc), st , sttelefon, stpohlavi, ststuduje kodpredmetu, prnazevpredmetu, prpocetkreditu cislozkousky, zkdatumzkousky, zkmaxstudentu 3.4. Krok 4 Nalezení domén atributů. Výstupem tohoto kroku je určení domén jednotlivých atributů, nalezených v předchozím kroku. Doména je přípustná množina hodnot, z níž mohou čerpat své hodnoty jeden nebo i více atributů. Příkladem může být například osobní číslo studenta. Jeho doménou může být sedmi místný znakový řetězec s pevnou délkou, jehož první dva znaky jsou ST a zbývající znaky tvoří čísla, tedy čísla Dalším příkladem může byt doména atributu studuje u entity Student. Zde můžeme určit doménu jako jeden znak, jenž může nabývat pouze hodnot A a N Základními informacemi o doméně jsou tedy: Přípustná množina hodnot atributu. Velikost a formát atributu Krok 5 - Vyhledání kandidátních, primárních a alternativních klíčů. Cílem tohoto kroku je identifikace tzv. kandidátních klíčů, a pokud jich pro danou entitu existuje více než jeden, vybrat mezi nimi primární klíč a ostatní určit jako klíče alternativní. Důležité při určování kandidátních klíčů je vynechání těch atributů, jenž mohou nabývat hodnoty null. Pokud by byl kandidátní klíč tvořen více atributy, tak ani jeden z těchto atributů nesmí nabývat hodnoty null. Pokud bude pro danou entitu zvoleno více kandidátních klíčů, musí být jeden z nich zvolen jako klíč primární. Za primární klíč by měl být zvolen kandidátní klíč, jenž: obsahuje minimální množství atributů, u něhož je malá pravděpodobnost změny hodnot, má velice nízkou pravděpodobnost, že v budoucnu ztratí jedinečnost, obsahuje nejmenší počet znaků (pokud se jedná o textový atribut), nebo obsahuje nejmenší maximální hodnotu (číselný atribut) 12

13 3.6. Krok 6 - Kontrola redundance v modelu. Redundance (nadbytečnost) se v modelu vyskytne ve chvíli, kdy nalezneme dvě entity, které ve skutečnosti vyjadřují jeden a tentýž objekt v rámci modelované problematiky. Může se stát, že v modelu systému pro VŠ vzniknou entity Vyučující a Školitel. Mezi oběma entitami bude navíc vazba 1:1. To je totiž typický případ, kdy redundance vznikají. V tomto případě je vhodné obě entity spojit do jedné. Pokud mají obě entity své primární klíče, vybere se jeden z nich a druhý se ponechá jako alternativní. Proto je při kontrole vhodné nejprve projít všechny vazby 1:1 a prověřit entity na obou stranách relace, zda náhodou nevyjadřují tutéž skutečnost. Druhý typ redundance, méně nápadný než první, který při modelování vzniká, je redundance relací. V tomto případě se v modelu vyskytne relace, která vyjadřuje informaci, kterou lze získat prostřednictvím jiné relace (relací). Na zjednodušeném modelu je vidět příklad redundantní relace: < Vyučuje 0..N Student Zapisuje > Předmět 0..N 0..N 0..N < Učí 1..N 0..N Vyučující Obrázek 5 - Redundantní relace V uvedeném případě je vazba mezi entitami Student a Vyučující nadbytečná. Stejnou informaci lze totiž získat z vazby mezi Studentem a Vyučujícím přes entitu Předmět. Proto můžeme přímou vazbu mezi Vyučujícím a Studentem odstranit. S odstraňováním redundantních vazeb se pojí jedno upozornění. Ne vždycky platí, že pokud mezi dvěma stejnými entitami relace, že jedna z nich redundantní. Někdy může druhá relace vyjadřovat něco jiného než relace první. Zde je důležité pochopit kontext obou dvou relací. Příkladem může být následující obrázek: Zaměstnává > Fakulta N 0..1 < Vede 0..1 Zaměstnanec Obrázek 6 - Neredundantní relace 13

14 Na obrázku jsou dvě entity a mezi nimi dvě relace. Na první pohled by se mohlo jednat o redundantní relaci, ale při bližším pohledu na jednotlivé relace je zřejmé, že každá z relací vyjadřuje jinou informaci. Relace Zaměstnává nese i informaci o tom, kteří zaměstnanci spadají pod danou fakultu, kdežto relace Vede udává, který ze zaměstnanců je vedoucím dané fakulty. A proto než bude daná relace prohlášena za redundantní, musí být nejprve posouzen kontext, do kterého je daná relace zasazena Krok 7 - Posouzení zda model podporuje uživatelské transakce. Pokud byly provedeny předchozí kroky pečlivě a svědomitě, měl by být k dispozici ER model plně popisující modelovaný objekt. Nyní je nutné zkontrolovat, zda daný model podporuje požadované transakce (činnosti). V podstatě se jedná o manuální provedení požadovaných operací nad modelem. Pokud je nad modelem možné provést všechny požadované transakce (operace), může být model považován za kompletní. V opačném případě je pravděpodobné, že ve výsledném modelu chybí nějaká entita, relace nebo atribut. V zásadě lze pro kontrolu uživatelských transakcí použít dvě metody: Metoda popisu transakcí. Metoda sledovaní cest transakcí. Při metodě popisu transakce se kontroluje, zda všechny informace (entity, relace, a jejich atributy) potřebné pro realizaci jedné konkrétní transakce jsou k dispozici. Například v modelu VŠ můžeme položit otázku: Které předměty vyučuje daný vyučující. Údaje o vyučujících jsou uloženy v entitě Vyučující, informace o konkrétních předmětech jsou uloženy v entitě Předmět. A k určení jednotlivých předmětů daného vyučujícího využijeme relace Učí. Tuto transakci je tedy možno s v rámci tohoto modelu vykonat. Při druhé metodě se požadované transakce reprezentují pomocí cest přímo v ER diagramu. Doslova jde o spojení všech zainteresovaných entit a relací a zjištění, zda je daná cesta průchodná. 4 Entitě-relační modelovaní a ER-diagramy Entitě relační (ER) modelování se snaží překlenout problémy spojené s tím, že každý člověk (ať už programátor, návrhář či běžný uživatel) má na data jiný pohled. Výsledkem ER modelovaní je model, který je jednotný, srozumitelný a neobsahuje víceznačnosti. Typickým výstup ER modelování je tzv. ER-diagram (zkráceně ERD). ER modelování je typickým příkladem návrhu databáze shora dolů. Tzn., že nejprve jsou nalezeny ty nejdůležitější entity spolu s relacemi mezi těmito entitami. Až 14

15 následně se přidávají podrobnější informace. Například méně podstatné entity či atributy jednotlivých entit a relací. Ačkoliv panuje všeobecné shoda o jednotlivých výstupech ER modelování, tak už neexistuje všeobecná shoda o tom, jak tyto jednotlivé elementy ER modelovaní graficky znázornit. Následující obrázek zobrazuje některé z používaných notací pro zápis ER diagramů. Obrázek 7- Možné notace pro zápis ER diagramů. Zdroj: [1] 15

16 Ať už grafická reprezentace modelu jakákoliv, v každém modelu vždy nalezneme dvě základní komponenty. Entity a relace. Entity a relace navíc můžou mít vlastnosti, které je nutné do modelu zahrnout. Entita je základním objektem každého ER diagramu. Na entitu lze pohlížet jako na množinu objektů reálného světa, jejž se vyznačují shodnými vlastnostmi. Každý objekt nacházející se v dané množině se nazývá výskyt entity. Každá entita je nezávislá a může reprezentovat jak objekty se skutečnou existencí, tak i objekty, jejž mají jen existenci pojmovou (abstraktní). V rámci ER diagramu má každá entita jedinečný název. Často entita obsahuje i seznam vlastností, které se v rámci ER modelovaní nazývají atributy. Typicky tedy můžeme při modelovaní narazit na entity Student, Předmět, Fakulta nebo HodnoceníVýuky. S pojmem entita se pojí pojem výskyt entity. Na entitu lze pohlížet jako na množinu výskytů entit. Entitou je tedy například Student a konkrétním výskytem dané entity může být student Jan Novák. Relace je množina spojení mezi entitami. Stejně jako entita, by každá relace měla mít svůj jedinečný název, který by měl korespondovat s jejím významem. Typicky se relace reprezentuje jako spojnice zúčastněných entity. Spolu se spojnicí se uvádí i jméno dané relace. U některých notací se bavíc uvádí i směr dané relace. To má zdůraznit, že této relace má smysl jen v jednom směru. Často se u relací (ať už graficky či textově) udává i tzv. multiplicita. Multiplicita říká, kolik výskytů jedné entity se může vztahovat k jedinému výskytu související entity. Dále se u relací uvádí (opět existují grafické i textové varianty) tzv. omezení participace, které říká, zda se relace účastní všechny výskyty entity nebo jen některé. Na obrázku 7 jsou dvě entity (Person,Location) a relace Born in/birthplace of. Všechny modely na obrázku zachycují skutečnost, že v každá osoba (entita Person) musí mít uvedeno místo narození (entita Location). Dále uvedené zápisy ER diagramů říkají, že jeden výskyt entity Location může vstoupit do vztahu s více výskyty entity Person. Navíc se výskyt entity Location vždy nemusí účastnit vztahu s entitou Person. Tzn., že v systému se mohou vyskytnout osamocené výskyty entity Location, ale entita Person vždy musí vstoupit do vztahu s entitou Location. Při tvorbě ER modelu v té či oné notaci, je nutné vždy dobře nastudovat danou notaci, protože velmi často se stává, že označení multiplicit a participací bývají mezi notacemi velmi odlišná (někdy i naprosto opačná). 16

17 Pojmy k zapamatování Pojmy: Metodologie návrhu, konceptuální modelování, plánování databáze, definice systému, sběr a analýza požadavků, entita, relace, atribut, složený atribut, atribut relace, odvozený atribut, doména atributu, kandidátní klíč, redundance dat, ER modelování, ER diagram. Problém: Návrh konceptuálního modelu dat, nalezení entit, relací a atributů, definice domén, nalezení kandidátních klíčů a následné stanovení primárních a alternativních klíčů, kontrola redundancí v modelu, kontrola modelu z pohledu uživatelských transakcí, využití různých notací ER diagramů při ER modelování. Shrnutí Metodologie návrhu databáze lze rozdělit na tři hlavní fáze: konceptuální, logický a fyzický návrh databáze. Výstupem konceptuálního modelování je vytvoření ER modelu datových požadavků na výsledný systém, v němž je opuštěno od jakékoliv fyzické implementace. Klíčovým prvkem konceptuální modelovaní je nalezení podstatných entit a relací. ER model popisuje entity, relace, atributy, domény atributů, kandidátní klíče apod. Výsledkem logického modelování je specifický model dat nezávislý na cílovém databázovém systému. Fyzický návrh se zabývá převodem logického modelu na model, jenž je implementovatelný v rámci cílového databázového systému. Otázky na procvičení 1. Jaké jsou hlavní fáze návrhu databáze? 2. Jaké je hlavní význam jednotlivých kroků v rámci návrhu databáze? 3. Jakým způsobem se jednotlivé entity v modelu identifikují? 4. Jakým způsobem jsou nalézány jednotlivé atributy? 5. Jakými způsoby je možné zkontrolovat, zda navržený model umožňuje všechny uživatelské transakce. Odkazy a další studijní prameny 0/2785/2785_uml.pdf (Entity Relationship Modeling with UML) 17

18 Odkazy a další studijní prameny Zdroje CONOLLY, Thomas, Carolyn BEGG a Richard HOLOWCZAK. Mistrovství - databáze: profesionální průvodce tvorbou efektivních databází. Brno: Computer Press, ISBN Entity-relationship model. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, [cit ]. Dostupné z: 18

10. blok Logický návrh databáze

10. blok Logický návrh databáze 10. blok Logický návrh databáze Studijní cíl Tento blok je věnován převodu konceptuálního návrhu databáze na návrh logický. Blok se věnuje tvorbě tabulek na základě entit z konceptuálního modelu a dále

Více

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

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

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

Střední průmyslová škola Zlín VY_32_INOVACE_33_01 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

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

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Projekt ESF OP VK reg.č. CZ.1.07/2.2.00/28.0209 Elektronické opory a e-learning pro obory výpočtového

Více

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

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

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

Databázové systémy. Ing. Radek Holý Databázové systémy Ing. Radek Holý holy@cvut.cz Literatura: Skripta: Jeřábek, Kaliková, Krčál, Krčálová, Kalika: Databázové systémy pro dopravní aplikace Vydavatelství ČVUT, 09/2010 Co je relační databáze?

Více

Konceptuální modelování. Pavel Tyl 21. 3. 2013

Konceptuální modelování. Pavel Tyl 21. 3. 2013 Konceptuální modelování Pavel Tyl 21. 3. 2013 Vytváření IS Vytváření IS Analýza Návrh Implementace Testování Předání Jednotlivé fáze mezi sebou iterují Proč modelovat a analyzovat? Standardizované pracovní

Více

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

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

13. blok Databázové modelování v praxi

13. blok Databázové modelování v praxi 13. blok Databázové modelování v praxi Studijní cíl Rekapitulace všech kroků při tvorbě databázového modelu. Demonstrace všech fází databázového návrhu na praktickém příkladu. Ukázky z modelování v konkrétním

Více

11. blok Normalizace. Studijní cíl

11. blok Normalizace. Studijní cíl 11. blok Normalizace Studijní cíl Využití normalizace při návrhu databáze. Vliv nenormalizovaných tabulek na vznik anomálií a nekonzistence v databázi. Pravidla spojená s nejužívanějšími normálními formami

Více

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

Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit (entitní množiny) Atributy - 2.1 - Kapitola 2: Entitně-vztahový model (Entity-Relationship model) Množiny entit Množiny vztahů Otázky návrhu Plánování mezí Klíče E-R diagram Rozšířené E-R rysy Návrh E-R databázového schématu Redukce

Více

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

Úvod do softwarového inženýrství IUS 2009/2010 p.1/30 Úvod do softwarového inženýrství IUS 2009/2010 5. přednáška Ing. Radek Kočí, Ph.D. Ing. Bohuslav Křena, Ph.D. Vytvořeno na základě přednášky doc. Ing. Jaroslava Zendulky, CSc. Úvod do softwarového inženýrství

Více

Databázové systémy I

Databázové systémy I Databázové systémy I Přednáška č. 2 Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky jiri.zechmeister@upce.cz Obsah Fáze návrhu databáze Konceptuální model Barkerova notace Unikátní identifikátory

Více

2. přednáška z předmětu GIS1 Data a datové modely

2. přednáška z předmětu GIS1 Data a datové modely 2. přednáška z předmětu GIS1 Data a datové modely Vyučující: Ing. Jan Pacina, Ph.D. e-mail: jan.pacina@ujep.cz Pro přednášku byly použity texty a obrázky z www.gis.zcu.cz Předmět KMA/UGI, autor Ing. K.

Více

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

Databázové modelování. Analýza Návrh konceptuálního schématu Databázové modelování Analýza Návrh konceptuálního schématu 1 Vytváření IS Analýza Návrh Implementace Testování Předání SW Jednotlivé fáze mezi sebou iterují 2 Proč modelovat/analyzovat? Standardizované

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_33_02 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu: Úvod do databází Základní pojmy Databáze je množina záznamů, kterou shromažďujeme za nějakým konkrétním účelem. Databáze používáme zejména pro ukládání obsáhlých informací. Databázové systémy jsou k dispozici

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

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

Úvod do databázových systémů 6. cvičení Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů 6. cvičení Ing. Petr Lukáš petr.lukas@nativa.cz Ostrava, 2012 Modelování databází [1]

Více

4. blok část A Logické operátory

4. blok část A Logické operátory 4. blok část A Logické operátory Studijní cíl Tento blok je věnován představení logických operátorů AND, OR, NOT v jazyce SQL a práce s nimi. Doba nutná k nastudování 1-2 hodiny Průvodce studiem Při studiu

Více

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

Obsah přednášky. Databázové systémy. Normalizace relací. Normalizace relací. Normalizace relací. Normalizace relací Obsah přednášky Databázové systémy Logický model databáze normalizace relací normální formy tabulek 0NF, 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DNF denormalizace zápis tabulek relační algebra klasické operace

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH Jindřich Kaluža Ludmila Kalužová Recenzenti: prof. Ing. Milan Turčáni, CSc. prof. Ing. Ivan Vrana, DrSc. Tato kniha vznikla za finanční podpory Studentské grantové

Více

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů

Více

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

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče. Primární a cizí klíč Kandidát primárního klíče (KPK) Je taková množina atributů, která splňuje podmínky: Unikátnosti Minimálnosti (neredukovatelnosti) Primární klíč (Primary Key - PK) Je právě jedna množina

Více

2. Konceptuální model dat, E-R konceptuální model

2. Konceptuální model dat, E-R konceptuální model 2. Konceptuální model dat, E-R konceptuální model Úvod Databázový model souhrn prostředků, pojmů a metod, jak na logické úrovni popsat data a jejich strukturu výsledkem je databázové schéma. Databázové

Více

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í

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í 1 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Požadavky kreditového systému. Relační datový model, relace, atributy,

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Logická struktura systému Objektový diagram Pavel Děrgel, Daniela Szturcová Osnova Modelování objektů objektový diagram Struktura a vazby mezi objekty Dobré zvyky při

Více

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

SQL - trigger, Databázové modelování 6. přednáška z předmětu Datové struktury a databáze (DSD) Ústav nových technologií a aplikované informatiky Fakulta mechatroniky, informatiky a mezioborových studií Technická univerzita v Liberci jan.lisal@tul.cz

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

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

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR): Mezi příkazy pro manipulaci s daty (DML) patří : 1. SELECT 2. ALTER 3. DELETE 4. REVOKE Jaké vlastnosti má identifikující relace: 1. Je relace, která se využívá pouze v případě modelovaní odvozených entit

Více

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

Úvod do databázových systémů Úvod do databázových systémů Databáze je dnes velmi často skloňovaným slovem. Co se pod tímto termínem skrývá si vysvětlíme na několika následujících stranách a cvičeních. Databáze se využívají k ukládání

Více

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

Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola Tento projekt je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky Co je to databáze? Jaké

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

DATOVÉ MODELOVÁNÍ ER MODEL

DATOVÉ MODELOVÁNÍ ER MODEL DATOVÉ MODELOVÁNÍ ER MODEL Základní pojmy Entita věc reálného světa (objekt) rozlišitelný od jiných objektů. Př) banky s identifikačním číslem 999, účet s č. účtu 100. Entitní množina - množina entit téhož

Více

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška Databázové systémy Datová integrita + základy relační algebry 4.přednáška Datová integrita Datová integrita = popisuje pravidla, pomocí nichž hotový db. systém zajistí, že skutečná fyzická data v něm uložená

Více

Hierarchický databázový model

Hierarchický databázový model 12. Základy relačních databází Když před desítkami let doktor E. F. Codd zavedl pojem relační databáze, pohlíželo se na tabulky jako na relace, se kterými se daly provádět různé operace. Z matematického

Více

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

Databáze I. Přednáška 3 Databáze I Přednáška 3 Normální formy relací normální formy relací definují určité vlastnosti relací, aby výsledná databáze měla dobré vlastnosti, např. omezena redundance dat snažíme se převést navržené

Více

12 Metody snižování barevného prostoru

12 Metody snižování barevného prostoru 12 Metody snižování barevného prostoru Studijní cíl Tento blok je věnován základním metodám pro snižování barevného rozsahu pro rastrové obrázky. Postupně zde jsou vysvětleny důvody k použití těchto algoritmů

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 03.220.01, 35.240.70 materiálem o normě. Inteligentní dopravní systémy Geografické datové soubory (GDF)

Více

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

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS Relační databázový model Databázové (datové) modely základní dělení klasické databázové modely relační databázový model relační databázový model Základní konstrukt - relace relace, schéma relace atribut,

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

6. blok část B Vnořené dotazy

6. blok část B Vnořené dotazy 6. blok část B Vnořené dotazy Studijní cíl Tento blok je věnován práci s vnořenými dotazy. Popisuje rozdíl mezi korelovanými a nekorelovanými vnořenými dotazy a zobrazuje jejich použití. Doba nutná k nastudování

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 22. Otázka : Úvodní fáze rozpracování softwarového projektu. Postupy při specifikaci byznys modelů. Specifikace požadavků a jejich rozpracování pomocí

Více

TEORIE ZPRACOVÁNÍ DAT

TEORIE ZPRACOVÁNÍ DAT Vysoká škola báňská - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky TEORIE ZPRACOVÁNÍ DAT pro kombinované a distanční studium Jana Šarmanová Ostrava 2003 Jana Šarmanová, 2003 Fakulta

Více

Manuál k programu RIZIKA

Manuál k programu RIZIKA Manuál k programu RIZIKA nástroj k efektivnímu vyhledávání a řízení pracovních rizik Program RIZIKA Program RIZIKA jsou víceuživatelskou aplikací s možností nastavení uživatelských práv pro jednotlivé

Více

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou:

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou: Relační databáze Pojem databáze, druhy databází Databází se myslí uložiště dat. V době začátků využívání databází byly tyto členěny hlavně hierarchicky, případně síťově (rozšíření hierarchického modelu).

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS 03.220.01;35.240.60 Inteligentní dopravní systémy (ITS) Rozšíření specifikací mapové

Více

12. blok Fyzický návrh databáze

12. blok Fyzický návrh databáze 12. blok Fyzický návrh databáze Studijní cíl Tento studijní blok se zabývá metodologií fyzického návrhu databáze. Především se zabývá fází převodu logického modelu na model fyzický. Bude vysvětlen účel

Více

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

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

PRODUKTY. Tovek Tools

PRODUKTY. Tovek Tools jsou desktopovou aplikací určenou k vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci i s velkým objemem textových dat z různorodých informačních zdrojů.

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

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

UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0 UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0 OBSAH 1 ÚVOD... 3 1.1 HOME STRÁNKA... 3 1.2 INFORMACE O GENEROVANÉ STRÁNCE... 4 2 VYHLEDÁVÁNÍ V ÚZEMÍ...

Více

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

Relační datový model. Integritní omezení. Normální formy Návrh IS. funkční závislosti multizávislosti inkluzní závislosti Relační datový model Integritní omezení funkční závislosti multizávislosti inkluzní závislosti Normální formy Návrh IS Funkční závislosti funkční závislost elementární redundantní redukovaná částečná pokrytí

Více

Metodika návrhu databáze

Metodika návrhu databáze Metodika návrhu databáze Metodika tvorby konceptuálního datového modelu (ERA diagramu) 1 1. Zvolte jednu primární entitu ze specifikace požadavků. 2. Určete atributy, jejichž hodnoty se mají pro tuto entitu

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

POUŽITÍ DATABÁZÍ. Po ukončení tohoto kurzu budete schopni

POUŽITÍ DATABÁZÍ. Po ukončení tohoto kurzu budete schopni POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni chápat základní principy databáze, vytvořit novou databázi, vytvořit a upravit tabulky, řadit a filtrovat data v tabulkách,

Více

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á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 Základní pojmy Pojem databáze označuje obecně souhrn informací, údajů, dat o nějakých objektech. Úkolem databáze je hlídat dodržení všech omezení a dále poskytovat data při operacích. Objekty

Více

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

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

Geografické informační systémy p. 1

Geografické informační systémy p. 1 Geografické informační systémy Slajdy pro předmět GIS Martin Hrubý hrubym @ fit.vutbr.cz Vysoké učení technické v Brně Fakulta informačních technologií, Božetěchova 2, 61266 Brno akademický rok 2004/05

Více

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

Základní informace. Modelování. Notace Základní informace BPMS = business process management systems - systémy pro modelování a optimalizace business procesů uvnitř organizace BPMN = business process modeling notation - součást BPMS, notace

Více

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

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) Marketingová komunikace Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) 2. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Minulé soustředění úvod

Více

Popisné systémy a databáze

Popisné systémy a databáze Popisné systémy a databáze Databáze v archeologii přístup k použití databází - dva způsoby aplikace databáze - databázové programy (jejich přednosti a omezení) databáze v archeologii - databáze jako výstup

Více

Registr práv a povinností. Metodika pro definici údajů vedených v agendě

Registr práv a povinností. Metodika pro definici údajů vedených v agendě Registr práv a povinností Metodika pro definici údajů vedených v agendě OBSAH 1 Úvod... 3 2 Základní principy... 4 3 Základní pojmy... 5 3.1 Objekt vedený v agendě... 5 3.2 Subjekt vedený v agendě... 5

Více

24 Uživatelské výběry

24 Uživatelské výběry 24 Uživatelské výběry Uživatelský modul Uživatelské výběry slouží k vytváření, správě a následnému používání tématicky seskupených osob a organizací včetně jejich kontaktních údajů. Modul umožňuje hromadnou

Více

Procesní audit VIKMA

Procesní audit VIKMA Procesní audit VIKMA07-2. 5. 2014 Cíl auditu Procesní audit je zaměřen na relevantní firemní procesy marketing, vývoj, nákup, servis apod. a jeho cílem je průběžně kontrolovat jejich úroveň, aby bylo možné

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Logická struktura systému (Diagram tříd) Daniela Szturcová Institut geoinformatiky, HGF Osnova Třídy Statický pohled na systém Atributy a operace, řízení přístupu

Více

Softwarové inženýrství

Softwarové inženýrství Page 1 of 8 Softwarové inženýrství Inf. systém pro cestovní kancelář PRINTER FRIENDLY VERSION Home Team info autor: Výlupková Irena Datová analýza Popis: Datový model je navržen tak, aby vhodně popsal

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Databázové patterny MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace Databázové patterny o Odzkoušené a doporučené

Více

U Úvod do modelování a simulace systémů

U Úvod do modelování a simulace systémů U Úvod do modelování a simulace systémů Vyšetřování rozsáhlých soustav mnohdy nelze provádět analytickým výpočtem.často je nutné zkoumat chování zařízení v mezních situacích, do kterých se skutečné zařízení

Více

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura Dílčí architektury Informační systémy - dílčí architektury - EIS MIS TPS strategické řízení taktické řízení operativní řízení a provozu 1 Globální Funkční Procesní Datová SW Technologická HW Aplikační

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

7. Rozdělení pravděpodobnosti ve statistice

7. Rozdělení pravděpodobnosti ve statistice 7. Rozdělení pravděpodobnosti ve statistice Statistika nuda je, má však cenné údaje, neklesejte na mysli, ona nám to vyčíslí Jednou z úloh statistiky je odhad (výpočet) hodnot statistického znaku x i,

Více

Objektově orientované databáze. Miroslav Beneš

Objektově orientované databáze. Miroslav Beneš Objektově orientované databáze Miroslav Beneš Obsah přednášky Motivace Vlastnosti databázových systémů Logické datové modely Nevýhody modelů založených na záznamech Co potřebujeme modelovat? Identifikace

Více

Návrh databázového systému pro Galerii S

Návrh databázového systému pro Galerii S Projekt ročníkové práce Návrh databázového systému pro Galerii S Autor: Radka Živnová Vedoucí práce: PhDr. Helena Kučerová Termín odevzdání: 30.5.2008 1. Obecný popis 1.1. Téma práce Návrh databázového

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

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

Databáze I. 4. přednáška. Helena Palovská Databáze I 4. přednáška Helena Palovská palovska@vse.cz Mapování ER modelu do relačního DB schématu Od 80. let 20. stol. znám algoritmus, implementován v CASE nástrojích Rutinní postup s volbami rozhodnutí

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_31_20 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

PRODUKTY. Tovek Tools

PRODUKTY. Tovek Tools Analyst Pack je desktopovou aplikací určenou k vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci i s velkým objemem textových dat z různorodých informačních

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

Více

4IT218 Databáze. 4IT218 Databáze

4IT218 Databáze. 4IT218 Databáze 4IT218 Databáze Osmá přednáška Dušan Chlapek (katedra informačních technologií, VŠE Praha) 4IT218 Databáze Osmá přednáška Normalizace dat - dokončení Transakce v databázovém zpracování Program přednášek

Více

T V POD NIKU. Ostrava 2011

T V POD NIKU. Ostrava 2011 PRŮVODCE STUDIEM PRO KOMBINOVANOU FORMU STUDIA MODULU IT P T V POD NIKU DÍLČÍ ČÁST PODNIKÁNÍ NA INTERNETU Pavlína Hronová Ostrava 2011 Název: Autoři: Vydání: Počet stran: Tisk: Vydala: Průvodce studiem

Více

10 Balíčky, grafické znázornění tříd, základy zapozdření

10 Balíčky, grafické znázornění tříd, základy zapozdření 10 Balíčky, grafické znázornění tříd, základy zapozdření Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost příkazům balíčkům, grafickému

Více

Pokročilé typové úlohy a scénáře 2006 UOMO 71

Pokročilé typové úlohy a scénáře 2006 UOMO 71 Pokročilé typové úlohy a scénáře 2006 UOMO 71 Osnova Interní model typové úlohy Vazby include a extend Provázanost typových úloh na firemní procesy a objekty Nejčastější chyby 2006 UOMO 72 Interní model

Více

11 Diagram tříd, asociace, dědičnost, abstraktní třídy

11 Diagram tříd, asociace, dědičnost, abstraktní třídy 11 Diagram tříd, asociace, dědičnost, abstraktní třídy Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost diagramům tříd, asociaci,

Více

Novela vyhlášky č. 259/ 2012 Sb., o podrobnostech výkonu spisové služby. Metodické setkání uživatelů spisové služby GORDIC

Novela vyhlášky č. 259/ 2012 Sb., o podrobnostech výkonu spisové služby. Metodické setkání uživatelů spisové služby GORDIC Novela vyhlášky č. 259/ 2012 Sb., o podrobnostech výkonu spisové služby Metodické setkání uživatelů spisové služby GORDIC Úvod Aktuální stav novely v legislativním procesu Prezentované znění ještě není

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

Autor. Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech

Autor. Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech Adresářová služba X.500 a LDAP Autor Martin Lasoň Abstrakt Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech vedla ke vzniku specializovaných databází adresářů.

Více

Kurz je rozdělen do čtyř bloků, které je možné absolvovat i samostatně. Podmínkou pro vstup do kurzu je znalost problematiky kurzů předešlých.

Kurz je rozdělen do čtyř bloků, které je možné absolvovat i samostatně. Podmínkou pro vstup do kurzu je znalost problematiky kurzů předešlých. Soubor kurzů XHTML, CSS, PHP a MySQL Kurz je rozdělen do čtyř bloků, které je možné absolvovat i samostatně. Podmínkou pro vstup do kurzu je znalost problematiky kurzů předešlých. Jeden blok se skládá

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1 Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 Vznik a historie projektového řízení Akad. rok 2015/2016, LS Projektové řízení a marketing

Více

S M Ě R N I C E č. 6/2014 ministra financí ------------------------------------------------------------------------

S M Ě R N I C E č. 6/2014 ministra financí ------------------------------------------------------------------------ MINISTERSTVO FINANCÍ Praha 1, Letenská 15 V Praze dne 12. prosince 2014 Č.j.: MF 69 949/2014/4703-2 S M Ě R N I C E č. 6/2014 ministra financí ------------------------------------------------------------------------

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

Více