9. blok Fáze návrhu databáze, konceptuální modelování
|
|
- Milada Dostálová
- před 8 lety
- Počet zobrazení:
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 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íceModely 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íceAnalý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íceStř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íceInovace 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íceKonceptuá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íceDatabá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íceModelová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íceObsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel
Obsah přednášky Databázové systémy Konceptuální model databáze Codd a návrh relační databáze fáze návrhu pojem konceptuální model základní pojmy entity, relace, atributy, IO kardinalita, 2 historie: RDBMS
VíceObsah. Zpracoval:
Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč
Více11. 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íce13. 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íceDatabázové systémy. Přednáška 1
Databázové systémy Přednáška 1 Vyučující Ing. Martin Šrotýř, Ph.D. K614 Místnost: K311 E-mail: srotyr@fd.cvut.cz Telefon: 2 2435 9532 Konzultační hodiny: Dle domluvy Databázové systémy 14DATS 3. semestr
VíceKapitola 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íceDatabá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íce2. 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íce10 Metody a metodologie strukturované analýzy
10 Metody a metodologie strukturované analýzy 10.1 Strukturovaná analýza DeMarco (1978) Nástroje: DFD, datový slovník, strukturovaná angličtina, rozhodovací tabulky a stromy Postup: 1. Analýza stávajícího
VíceDatabázové systémy. Vztahy a relace. 3.přednáška
Databázové systémy Vztahy a relace 3.přednáška Terminologie - vztahy Účastníci vztahu Stupeň vztahu počet relací účastnících se na vztahu Unární Binární Ternární Terminologie - vztahy Kardinalita vztahu
VíceDatabá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íceInovace 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íceDBS 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íceS 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Ú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íceDatabáze. Logický model DB. David Hoksza
Databáze Logický model DB David Hoksza http://siret.cz/hoksza Osnova Relační model dat Převod konceptuálního schématu do logického Funkční závislosti Normalizace schématu Cvičení převod do relačního modelu
VíceÚ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íceNávrh databázového modelu
Návrh databázového modelu Informační a znalostní systémy 1 2 Konflikty 3 návrh musí pokrývat požadavky zadavatele návrhbyměl reflektovat i možné budoucí poslání návrh od shora dolů zdola nahoru Vývoj modelu
VíceInformač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íce4. 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íce2. 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íceObsah 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íceTÉ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íceMODELOVÁ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íceObjekty, třídy, vazby 2006 UOMO 30
Objekty, třídy, vazby 2006 UOMO 30 Osnova Vymezení pojmu objekt Objekt a základní objektové koncepty Třídy, třída vs. objekt Vztahy mezi objekty, vazby mezi třídami Polymorfismus 2006 UOMO 31 Vymezení
VícePrimá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ícePrimární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace
Téma 2.2 Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace Obecný postup: Každá tabulka databáze by měla obsahovat pole (případně sadu polí), které jednoznačně identifikuje každý
VíceHierarchický 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íceInformač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íceSQL - 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íceJaký 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íceMateriá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Ú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íceVÝ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íceDatabá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íceDATOVÉ 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íce1. 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íceDatabá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ícePracovní 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íce12. 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íceRELAČ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íceObjektově 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íceEXTRAKT 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íce6. 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íceRelač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íce2. 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íceMINISTERSTVO PRO MÍSTNÍ ROZVOJ Č.j. 7022/ R O Z H O D N U T Í č. 19/2016. ministryně pro místní rozvoj. ze dne
MINISTERSTVO PRO MÍSTNÍ ROZVOJ Č.j. 7022/2016-56 R O Z H O D N U T Í č. 19/2016 ministryně pro místní rozvoj ze dne 18. 2. 2016 o Pravidlech správy otevřených dat Ministerstva pro místní rozvoj S účinností
VíceEXTRAKT 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íceDatabázové systémy. Cvičení 3
Databázové systémy Cvičení 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
VícePří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íceMarketingová 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ícePŘÍ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ícePRODUKTY. 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íceRelač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íce12 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íceTÉ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íce12. 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íceDatabá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íce6. blok část C Množinové operátory
6. blok část C Množinové operátory Studijní cíl Tento blok je věnován problematice množinových operátorů a práce s množinovými operátory v jazyce SQL. Čtenáři se seznámí s operátory, UNION, a INTERSECT.
VíceTEORIE 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íceMetodika 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ícePOUŽ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íceMarketingová 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íceEXTRAKT 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íceZá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íceGeografické 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ícePopisné 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íce24 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Úvod do databázových systémů
Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 8 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014 Opakování Entita Entitní typ
VíceUŽ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íceRelač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íceOOT 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íceProblé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íceManuá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íce8.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Úvod do modelování a simulace. Ing. Michal Dorda, Ph.D.
Úvod do modelování a simulace systémů Ing. Michal Dorda, Ph.D. 1 Základní pojmy Systém systémem rozumíme množinu prvků (příznaků) a vazeb (relací) mezi nimi, která jako celek má určité vlastnosti. Množinu
VíceDatabá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íceKritéria hodnocení praktické maturitní zkoušky z databázových systémů
Kritéria hodnocení praktické maturitní zkoušky z databázových systémů Otázka č. 1 Datový model 1. Správně navržený ERD model dle zadání max. 40 bodů teoretické znalosti konceptuálního modelování správné
VíceRegistr 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íceNá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íceObjektově 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íceDatabá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íceSoftwarové 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íceU Ú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íceObsah. 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íce4IT218 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ícePRODUKTY. 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íce10 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íceArchitektura 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