Prohlášení
Byl(a) jsem seznámen(a) s tím, že na mou diplomovou práci se plně vztahuje zákon č. 121/2000 o právu autorském, zejména § 60 (školní dílo).
Beru na vědomí, že TUL má právo na uzavření licenční smlouvy o užití mé diplomové práce a prohlašuji, že s o u h l a s í m s případným užitím mé diplomové práce (prodej, zapůjčení apod.).
Jsem si vědom(a) toho, že užít své diplomové práce či poskytnout licenci k jejímu využití mohu jen se souhlasem TUL, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených univerzitou na vytvoření díla (až do jejich skutečné výše).
Diplomovou práci jsem vypracoval(a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím diplomové práce a konzultantem.
Datum
Podpis
Resumé
Tato diplomová práce se zabývá informačním systémem pro podporu procesu neustálého zlepšování v automobilovém koncernu Volkswagen (VW). Ten vznikl z důvodu zlepšení produktivity práce na všech pracovištích a nyní se zavádí v celém koncernu VW včetně Škoda Auto. V úvodu vysvětlíme princip procesu neustálého zlepšování a jeho uplatnění v praxi. Před vlastní realizací informačního systému představíme a popíšeme dostupné prostředky pro návrh a tvorbu databázového informačního systému. Dále se budeme věnovat vlastní realizaci. Navrhneme ERD model a funkční model DFD. Ve vybraném vývojovém prostředí vytvoříme databázi podle navrženého modelu. V předposlední části využijeme jeden z objektově orientovaných programovacích jazyků pro tvorbu uživatelského rozhraní pro přístup a správu dat v databázi. Na závěr uvedeme předpokládané zlepšení v důsledku zavedení.
Abstract
This graduation thesis deals with an information system supporting the continuous development within Volkswagen (VW). The thesis is created to increase productivity of work in all workplaces and it is now being integrated into the entire VW, including Škoda Auto. In the introduction we will explain the principle of the process of continuous development and its use in the field. Before the actual realization of the information system, we will introduce and describe the available means for the design and creation of the database information system. We will than give over to the actual realization. We will design an ERD model and a functional DFD model. In the select development medium we will create a database based on the designed model.
Near the conclusion we will use the object oriented programming languages for the creation of the user interface for access and maintenance of the data in the database. In the end we will introduce the expected improvements due to the establishment of the IS.
Klíčová slova
Proces neustálého zlepšování, databázový informační systém, GUI, ERD, DFD Key words
Continuous development, database information system, GUI, ERD, DFD
Použité zkratky ... 7
Úvod ... 9
1. Škoda Auto ... 11
2. KVP – proces neustálého zlepšování ... 12
2.1. Popis procesu KVP-WS ... 12
3. Prostředky pro vývoj databázového IS ... 13
3.1. Relační model dat ... 14
3.1.1. Normální formy ... 15
3.1.2. Metoda dekompozice a syntézy ... 18
3.2. Vedení rozhovorů ... 19
3.3. Modelování databáze ... 22
3.3.1. Datová analýza ... 23
3.3.1.1. ER – model ... 24
3.3.1.2. Transformace ER schématu do relačního schématu databáze ... 32
3.3.2. Funkční analýza ... 34
3.3.2.1. Hierarchie funkcí ... 35
3.3.2.2. Diagram toku dat – DFD ... 36
3.3.3. UML ... 38
3.3.3.1. Use Case Diagram ... 40
3.3.3.2. Class Diagram ... 42
3.3.3.3. Deployment Diagram ... 45
3.3.4. XML ... 46
3.3.4.1. DOM ... 48
3.4. SQL ... 48
4. Vlastní návrh IS ... 50
4.1. ERD ... 51
4.2. DFD ... 53
4.3. Vytvoření databáze ... 56
4.3.1. Vlastník schématu a klíčový uživatel ... 57
4.3.2. Role ... 58
4.3.3. Profil ... 59
4.3.4. Sekvence ... 59
4.3.5. Triggery ... 60
4.3.6. Pohled - view ... 61
4.4. Popis GUI ... 61
5. Závěr ... 66
Použitá literatura ... 67
Seznam obrázků ... 68
Použité zkratky
ANSI American National Standards Institute BCNF Boyce-Coddova normální forma CASE Computer Aided Software Engineering CLI Call Level Interface
DB databáze
DBS databázový systém
DCL Data control language (jazyk pro řídící příkazy) DDL Data definition language (jazyk pro definici dat) DFD Data Flow Diagram
DML Data manipulation language (jazyk pro manipulaci dat) DOM Document Object Model
DTD Data Type Definition (definice typu dokumentu) EEN Execution environment node
ERD Entity Relationship Diagram ER-Model Entity Relationship model FK foreign key (cizí klíč) FSD diagram funkční struktury GML Generalized Markup language
GUI Graphical User Interface (grafické uživatelské rozhraní) HTML Hypertext Markup Language
HW Hardware
IO integritní omezení IS Informační systém
ISO International Organization for Standardization IT Informační technologie
JDBC Java Database Connectivity JDK Java Development Kit
KVP Kontinuerlicher Verbesserung Prozess (proces neustálého zlepšování)
MS Microsoft
OCL Object constraint leanguage
ODBMS Object database management systém ODBC Open Database Connectivity
OLAP online analytical processing (online analytické zpracování) OLTP online transaction processing (online zpracování transakcí) OMG Object management group
ORDBMS Object relational database management system PC osobní počítač (z angličtiny Personal Computer) PK primary key (primární klíč)
RDBMS Relational database management system RMD relační model dat
SGML Standard Generalized Markup Language
SQL strukturovaný dotazovací jazyk (z anglického Structured Query Language)
SŘBD systém řízení bází dat
SW Software
TCC Transaction control commands (příkazy pro řízení transakcí) UML unified modeling language
VW Volkswagen
WS Work shop (pracovní setkání v multidisciplinárním týmu) XHTML eXtensible Hypertext Markup Language
XML eXtensible Markup Language (rozšiřitelný značkovací jazyk) YSM Yourdon Structured method
1NF První normální forma 2NF Druhá normální forma 3NF Třetí normální forma 4NF Čtvrtá normální forma 5NF Pátá normální forma
Úvod
Neustále se zvyšující konkurenční tlak ze strany japonských, korejských, ale dnes již i čínských a ruských výrobců automobilů, nutí evropské, ale i americké výrobce obecně ke snižování nákladů – snižování materiálních nákladů a zvyšování produktivity práce.
Produktivita práce - slova dnes skloňována ve všech pádech. Země jako Japonsko, Korea mají vyšší produktivitu práce při stejných nákladech oproti evropským a americkým automobilkám. O technologické vyspělosti firem jako je Toyota, Hyundai a Nisan dnes již nikdo nepochybuje. Nicméně v poslední době se na celosvětový trh dostávají firmy, které v oblasti produktivity práce nedosahují ani úrovně evropských koncernů. I přes tuto zřejmou nevýhodu jsou více než rovnocenným soupeřem v prodejnosti.
A jak je to možné? Země jako je Čína, Rusko mají obrovský lidský potenciál a snahu dohnat ekonomicky vyspělé země v oblasti průmyslu a výroby. Pokud srovnáme platové podmínky v Číně a Německu zjistíme, že německý občan má přibližně 20 krát vyšší plat než zaměstnanec na stejném postu v Číně. Jak tedy mohou konkurovat západní firmy? Je to kvalitou práce, zlepšením procesů a hlavně vyšší produktivitou práce.
Produktivita práce je obvykle definována jako poměr výnos/počet pracovníků.
Tento jednoduchý vzorec nám ukazuje, že každá úspěšná firma musí zaměstnávat minimum pracovníků a vydělávat maximum peněz. Je tomu opravdu tak? Ve vyspělých zemích tomu opravdu tak je, protože každý zaměstnanec navíc znamená nemalé ztráty na zisku (výnosu), a nebo zvýšení ceny finálního produktu. Tím se buď stává nerentabilním, nebo konkurence neschopným. Ale pokud se podíváme do rozvojových zemí tak zjistíme, že úroveň platů je tak nízká, že se to téměř neprojeví na konečné ceně produktu. Jedinou možností firem s vysokou platovou úrovní je maximální zlepšení kvality a růstu produktivity práce.
Růst produktivity práce je především založen na využití dokonalejší techniky, zdokonalení organizace práce, zavedení dokonalejší technologie, šikovnosti výrobce (pracovníka) a v neposlední řadě na odstranění veškerého plýtvání.
Pokud se budeme věnovat jednotlivým bodům, zjistíme, že kromě omezení plýtvání všechno vyžaduje nové investice. Podaří-li se firmě omezit plýtvání na minimum, její produktivita automaticky poroste.
Jediným řešením je zlepšení celého procesu výroby a plánování. Pro tento účel vznikl v Japonsku v roce 1993 životní princip Kaizen. Japonské slovo kaizen se dá přeložit jako nepřetržitý proces malých pokroků. Vychází z jednoduché myšlenky, 365 malých zlepšení znamená za rok obrovský pokrok. Na podobné ideji je založen princip KVP.
Myšlenka je to vskutku jednoduchá a jak se říká „v jednoduchosti je síla“.
Otázkou ale zůstává, jak zajistit, aby na všech pracovištích docházelo alespoň k malým zlepšením. Tento široký proces, kdy se zkoumá stovky pracovišť a tisíce zaměstnanců v několika vlnách se dá jen velmi těžko v papírové formě zvládnout. V dnešní době se používají informační systémy (IS) pro podporu procesu neustálého zlepšování.
1. Škoda Auto
Tato diplomová práce se zabývá aktuálním problémem, který se řeší v rámci automobilky Škoda Auto. Proto jsme se rozhodli napsat pár slov o této firmě.
Historie Škoda Auto začíná v roce 1895, kdy Václav Laurin a Václav Klement založili malou firmu na výrobu jízdních kol s názvem Laurin & Klement. Důvod, který je vedl k založení dnes jedné z největších automobilek v Evropě, je velmi komický.
Nespokojenost s reklamací bicyklu německou firmou. V roce 1899 začínají vyrábět motocykly. Několik jejich typů se účastní závodů.
Obrovský úspěch v oblasti výroby jízdních kol a motocyklů způsobí, že od roku 1905 firma začíná novou éru – výroby osobních automobilů. První model Voiturette A se okamžitě stal trhákem. Komerční úspěch zapříčinil, že firma Laurin & Klement se stává v roce 1907 akciovou společností. Za první světové války se stává součástí válečně výroby. Po válce se firma dále rozvíjí a rozšiřuje svůj sortiment. Začíná vyrábět nákladní automobily a dokonce letecké motory.
V roce 1924 postihne firmu velký požár, který způsobí o rok později spojení se strojírenskou firmou Škoda. To znamená konec firmy Laurin & Klement. Postupně se přechází na jméno a znak Škoda. Po velké hospodářské krizi pokračuje úspěšná éra až do německé okupace za druhé světové války. Škodovka se stává součástí koncernu Hermann-Goering-Werke a vyrábí se zde zbraňové součásti a terénní vozidla.
Po druhé světové válce se odděluje od plzeňské části firmy Škoda a stává se monopolním výrobcem osobních aut v tehdejším Československu. Z politických důvodů se firma uzavírá moderním technologiím, které se vyvíjejí v demokratických zemích. Automobily Škoda nejsou konkurenceschopnými na západních trzích a prodávají se pouze do východního bloku.
Z tohoto důvodu v roce 1991 odkupuje akcie velká německá automobilka Volkswagen. Škoda Auto se stává čtvrtou značkou v koncernu VW (vedle značek VW, Audi, Seat).
Technologický skluz se podařilo velmi rychle dohnat a dnes jsou automobily Škoda (Octavia, Superb, Fabia, Roomster) prodávány úspěšně po celém světě. Dne 13.
července 2006 vyrobila Škoda Auto a.s. desetimilióntý vůz v historii značky.
2. KVP – proces neustálého zlepšování
Tento proces zasahuje do všech činností od vývoje počínaje až po prodej finálního produktu. Hlavní myšlenky KVP jsou převzaté z japonského Kaizen. Základní tři pravidla, která vymyslel Taiichi Ohno zní takto:
•
Vyrábí se jen to, co je skutečně potřeba a když se to poté používá. To platí pro díly, pro organizaci a vlastnosti produktu. Vše ostatní je plýtvání.•
U vzniklých chyb bude okamžitě nalezena příčina a řešení. Cílem je nulová chybovost.•
Všichni spolupracovníci a externí dodavatelé jsou vyzváni zlepšit produkt a současný stav.Cíle jsou eliminace plýtvání, snížení výrobního času, zvýšení kvality a produktivity.
2.1. Popis procesu KVP-WS
Pokud vytváříme IS pro podporu nějakého procesu, musíme znát jeho přesný průběh. Při tvorbě IS získáme tyto informace konzultacemi s uživateli a vedením dané organizace.
KVP-WS je koncipován, jak vyplývá z názvu, na pracovních schůzkách (workshop). V první řadě musíme umožnit uživateli s daným právem (moderátor, co- moderátor), aby založil WS. Pro tohoto člověka to znamená určit pracoviště a úkon, který bude WS zlepšovat. Dále je to složení týmu, stanovení termínů a míst, kde se budou schůzky konat. Moderátor je zodpovědný za přidělení jednotlivých rolí členům týmu a stanovení jejich důležitosti.
Poté přichází část, kdy ostatní členové týmu včetně moderátora a co-moderátora budou na základě schůzek stanovovat jednotlivé problémy, které na konkrétním pracovišti jsou a musejí se řešit. Navrhují opatření pro zlepšení nebo odstranění problému a určují zodpovědného člověka za jeho nasazení. Na závěr dochází k ekonomickému vyhodnocení a shrnutí účinnosti daného opatření.
Jako doplňkové funkce jsou delegování práv a informování nadřízeného členů týmu o účasti na jednáních, kontrola termínů, plnění úkolů. Tyto funkce nepřímo napomáhají bezproblémovému průběhu procesu.
3. Prostředky pro vývoj databázového IS
Jednou ze základních informačních technologií je databáze. Databáze, jak napovídá název, je soubor dat. Pokud shromažďujeme data organizovaným způsobem, máme databázi. Vyskytují se dva základní typy databází – operační a analytická [10].
Operační databáze jsou základním prvkem firem, organizací a institucí po celém světě. Jejich předností je online zpracování transakcí (OLTP). Tento typ databáze se hodí pro podniky, které potřebují data aktualizovat každý den. Data jsou dynamická, to znamená, že se neustále mění a zaznamenávají aktuální stav. Jejich využití je především v obchodní sféře, průmyslových podnicích, nemocnicích a v investičních podnicích.
Analytické databáze jsou primárně používány pro ukládání, správu a dohledávání starších dat. Používá se pro online analytické zpracování (OLAP). Hodí se v případě, že potřebujeme sledovat vývojové trendy, zaznamenávat statistická data v dlouhodobém časovém horizontu. Data jsou statická, to znamená, že se téměř nemění.
Využívají se v laboratořích, marketingových společnostech a ve společnostech zabývajících se statistickým vyhodnocováním. Analytické databáze často získávají data z operačních databází.
Pro účely naší práce se hodí první typ databáze a to je operační. Ten se dělí na čtyři základní datové modely:
• Hierarchický
• Síťový
• Relační
• Objektový
Hierarchický model obtížně znázorňuje vztah M:N a dále je problémové vkládání a rušení záznamů. Síťový model je nepružný a obtížně se mění jeho struktura.
Jelikož se dnes téměř nepoužívají, nebudeme se jim více věnovat.
Objevují se nové technologie pro konstrukci databází, jako například objektově orientované a objektově-relační. Poskytují základní vlastnosti objektů jako dědičnost, polymorfismus a zapouzdření. Uplatnění nacházejí v databázích, které pracují se složitějšími typy dat, jako jsou audio záznamy, video záznamy, 3D simulace a výstupy z CAD systémů. V dnešní době se nezdá, že by mohly úplně nahradit klasickou relační technologii. Existují ovšem úlohy, pro které je relační technologie nevhodná a zde nacházejí uplatnění objektové technologie.
3.1. Relační model dat
V dnešní době je nejpoužívanější relační model dat (RMD). Myšlenka RMD byla poprvé představena v roce 1970 Dr. Edgarem F. Coddem. Důvodem pro vytvoření nového modelu byla skutečnost, že ostatní databázové modely měly celou řadu závažných nedostatků, jako třeba velká redundance dat, nízká integrita dat. Jelikož byl F. Codd matematik, svůj nový model založil na dvou matematických disciplínách – teorie množin a predikátové logice prvního řádu.
Relačním modelem se nazývá, protože hlavním stavebním prvkem jsou relace a dále pak vztahy mezi nimi. Datové struktury se modelují pomocí schématu relace R(A1:D1,…,An:Dn). Index u A a D se nazývá arita R. Schéma relace nám udává jméno relace a množinu A atributů relace A = {A1:D1,…,An:Dn}. Každá relace je složena z uspořádaných n-tic = záznamů a ty se skládají z atributů. Každý atribut relace je tvořen dvojicí jméno atributu Ai a jeho doménou Di (množina hodnot). Záznam je identifikován v relaci pomocí unikátního atributu (primárního klíče) nebo kombinací atributů [3].
Důležitou definicí je definice schéma relační databáze. Schéma relační databáze je dvojice <R,IO>, kde R je množina schémat a IO je množina integritní omezení.
Relační databáze pro dané schéma je množina relací se schématem daným v R, které vyhovují všem integritním omezením z množiny IO [3].
Jedním z hlavních integritních omezení v relačním modelu dat je již zmiňovaný primární klíč. Další z důležitých IO se nazývá referenční integrita. Atribut, kterého se referenční integrita týká, se nazývá cizí klíč. Jde o atribut, který pomáhá realizovat vazbu dvou relací. Jeho hodnota musí být obsažena v primárním klíči svázané relace.
Na začátku této kapitoly bylo řečeno, že RMD je založen na matematických základech. Dr. Codd nahlížel na relace jako na množiny. Proto lze využít pro práci s relacemi množinové operace. Relační model nám poskytuje dva jazykové prostředky - relační kalkul a relační algebru. Relační algebra je množina operací, jejichž použití na relace vrací opět relaci. Minimální množinu operací tvoří:
• Sjednocení
• Kartézský součin
• Rozdíl
• Selekce
• Projekce
• Přejmenování
Jako dotazovací jazyk lze vhodně využít jazyk logiky. V RMD je definován n- ticový relační kalkul (NRK) srovnatelný s relační algebrou. NRK nahlíží na relace jako na n-tice (řádek tabulky). Tento jazyk využívá pro tvorbu dotazu predikátové symboly – jména relací ze schématu databáze a binární porovnávací predikáty (<, >, =, ≤, ≥, ≠).
Dále využívá logické spojky jako and, or, ┐, a také kvantifikátory . Později se objevil doménový relační kalkul DRK. DRK pracuje s hodnotami jednotlivých n-tic.
Oba jazyky jsou založeny na predikátové logice 1. řádu.
Výhody tohoto modelu jsou oproti hierarchickému a síťovému:
¾ obsahuje víceúrovňovou integritu (relace, atributy, vztahy)
¾ logická a fyzická nezávislost dat databázové aplikace
¾ konzistence a přesnost dat
¾ snadné získávání dat 3.1.1. Normální formy
Pro stanovení relací a vztahů je nutné podrobit naši vznikající databázi
normalizaci. Normalizace je sada pravidel sloužící pro transformaci modelu do fyzického uspořádání tabulek a relací v databázi. Po správném provedení procesu normalizace odstraníme redundantní data, omezíme složitosti (rozložíme složité relace) a zabráníme tzv. aktualizačním anomáliím (např. při smazání všech knih autora nesmíme přijít o data o autorovi). Z toho důvodu uvedeme v této podkapitole základní normální formy. Prostředky normalizace do požadované NF jsou algoritmy dekompozice a syntézy, o kterých budeme hovořit v další kapitole.
Před vlastním uvedením normálních forem je nezbytné definovat několik důležitých pojmů.
Klíč K schématu R(A) je minimální podmnožina atributů z A jejichž hodnoty budou jednoznačně určovat k-tice relace R*. R* se označuje konkrétní relace.[5]
Jednoznačná identifikace - každá n-tice relace je hodnotami atributů tvořících K jednoznačně identifikovatelná.
Množina K je minimální pokud z ní nelze odebrat žádný atribut, aniž by to narušilo identifikační vlastnost. Říkáme, že K je minimální množina. Přidáme-li atribut k množině K její identifikační vlastnost se zachová, ale nelze ji považovat za minimální množinu.
Nechť X, Y jsou atributy relace R. Pak atribut Y je funkčně závislý na atributu X, pokud v čase existuje ke každé hodnotě atributu Y nejvýše jedna hodnota atributu X.
Funkční závislost atributu Y na atributu X budeme zapisovat X Y.
Z funkční závislosti lze odvodit několik pravidel. Říká se jim Armstrongova pravidla [5]. Nechť X, Y, Z jsou podmnožinou A. Potom platí:
1. Y je podmnožinou X, pak X Y – triviální funkční závislost 2. jestliže X Y a Y Z, pak X Z – tranzitivní závislost 3. jestliže X Y a X Z, pak X YZ – kompozice 4. jestliže X YZ pak X Y a X Z – dekompozice
Atribut B je silně funkčně závislý na atributu X, když je na něm funkčně závislý a zároveň neexistuje žádná podmnožina X´ složeného atributu X taková, že Y funkčně závisí na X´ (podmnožina X).
Nechť X, Y, Z jsou atributy relace R. Pokud Y je funkčně závislý na X a Z je funkčně závislý na Y a zároveň platí, že X funkčně nezávisí na Y, pak Z je tranzitivně závislý na X.
Pro schéma relace R(A), kde A={C,D,X}, X=A-C-D, C->>D je multizávislost nad A, jestliže pro každou přípustnou relaci R* platí R*=R*[C,D]*R*[C,X]. Je-li X prázdná množina, nazývá se multizávislost C->>D triviální. Říkáme, že D multizávisí na C.[5]
1NF - každá komponenta (atribut) je atomická = dále nedělitelná. Prakticky to znamená odstranit vícesložkové a vícehodnotové atributy. Vícesložkový atribut obsahuje dvě, nebo více součástí – řeší se rozdělením atributu na více samostatných atributů. Vícehodnotový atribut je složený z několika hodnot toho samého typu – řeší se rozdělením jedné relace na dvě.
2NF - relace R je ve 2NF, když je v 1NF a když každý atribut, který nepatří k žádnému klíči relace R, silně funkčně závisí na každém klíči relace R. V řádku relace se nesmí objevit atribut, který by byl závislý pouze na části primárního klíče. Z toho vyplývá, že pokud má relace jako primární klíč jenom jeden atribut, je automaticky splněna 2NF. Splněním 3NF se automaticky relace dostává do 2NF, proto se většinou 2NF neuvádí.
3NF - každý neklíčový atribut schématu R není tranzitivně funkčně závislý na žádném klíči schématu. To znamená, že neklíčový atribut je závislý na primárním klíči přes jiný neklíčový atribut (neklíčové atributy jsou vzájemně nezávislé).[5].
BCNF - relace se nachází v BCNF, jestliže pro každou netriviální závislost X Y platí, že X obsahuje klíč schématu R. Tato definice nám v podstatě říká, že mezi kandidátními klíči nesmí být žádná funkční závislost. Pokud je schéma v BCNF je automaticky ve 3NF.[5]
4NF - schéma relace R(A) je ve 4NF, jestliže je v BCNF a multizávislost nad A je triviální. Tato definice se dá formulovat také takto: relace je ve 4NF pokud je v BCNF a všechny vícehodnotové závislosti jsou zároveň funkčními závislostmi z kandidátních klíčů.[5]
5NF - relace je v 5NF pokud je ve 4NF a není možné do ní přidat další atribut
nebo skupinu atributů aniž by se vlivem skrytých závislostí rozpadla na několik dílčích relací.
3.1.2. Metoda dekompozice a syntézy
Dekompozice je jedna z metod jak celkové relační schéma rozdělit na schémata, která jsou všechna v BCNF. Pro dekompozice relačních schémat databáze se využívá strategie shora-dolů. Algoritmus dekompozice je velmi jednoduchý, nahrazuje jedno relační schéma dvěma [5].
Dekompozice schématu relace R(A) znamená, rozložit je ve dvě schémata R1(X) a R2(Y), tak, že X Y = A. Odpovídající dekompozice instance schématu R* znamená provést R*[X] a R*[Y]. Pak R1=R*[X] a R2=R*[Y].[3]
Řekneme, že schéma relace je R(A) má bezeztrátovou dekompozici vzhledem k množinám atributů X a Y, jestliže R(A)=R1(X)*R2(Y), tj. každá relace R* dekomponovaná do projekcí R1* a R2* může být rekonstruovaná z těchto projekcí pomocí operace přirozené spojení. Bezztrátová dekompozice se obdrží na základě následující věty. [3]
Mějme schéma relace R(A, B, C), kde A, B, C jsou navzájem disjunktní množiny atributů, a platí funkční závislost B C. Rozložíme-li R na schémata R1(B, C) a R2 (A, B), je takto provedená dekompozice bezeztrátová. [3]
Algoritmus syntézy byl představen v roce 1976 doktorem Bernsteninem. Na syntézu lze nahlížet jako na jistý případ dekompozice, rozdíl je pouze ve strategii.
Syntéza využívá strategii zdola-nahoru. Schéma vytváříme syntézou přímo z funkčních závislostí. [5]
Před popsáním algoritmu syntézy je potřeb definovat několik pojmů.
Množina všech funkčních závislostí odvoditelných z F se nazývá uzávěr F a označuje se F+. Uzávěr F+ získáme použitím Armstrongových pravidel. Závislost, která má na pravé straně jeden atribut se nazývá elementární funkční závislost.[5]
Pokrytí množiny funkčních závislostí F je množina funkčních závislostí G, taková, že F+=G+. Je-li F´množina elementárních závislostí, která vznikne z F
dekompozicí jejích neelementárních závislostí, platí F´+ =F+. Vznikne tak pokrytí, které se nazývá kanonické.[5]
Nechť F je množina funkčních závislostí nad množinou atributů A schématu relace R(A). Potom postupujeme v následujících krocích:
1. Vytvoříme minimální pokrytí G
2. Závislosti z G se roztřídí do skupin tak, že v každé skupině jsou závislosti se stejnou levou stranou. Atributy závislostí každé skupiny tvoří schéma jedné relace, vzniklé syntézou (syntézované schéma). Atributy levé strany tvoří klíč syntézovaného schématu.
3. Pokud jsou atributy, které se nevyskytují v žádné funkční závislosti F musíme je umístit do schématu samostatné relace. Ovšem tak, aby byly součástí klíče původního schématu R. Matematicky se to vyjádří takto: Nechť X je množina atributů, které se nevyskytují v G. Pak k nim připojíme atributy Y takové, aby XY tvořily klíč schématu R. Výsledné schéma připojíme k celkovému schématu R.
4. Jsou-li v takto vzniklých schématech schémata s funkčně ekvivalentními klíči, je vhodné je sloučit v jedno. Vychází se z úvahy, že obě schémata zřejmě popisují jeden objekt. Sloučení ovšem může vést k eventuálním tranzitivitám, které je nutné odstranit.[5]
Absolvováním těchto kroků dostaneme výsledné schéma R={Ri(Ai, Fi) 1≤i≤n, pro n≥1}
3.2. Vedení rozhovorů
Při vývoji databázového informačního systému je nezbytný správný návrh vlastní databáze. V některých případech mu není věnována dostatečná pozornost a poté dochází v implementační části k velkým problémům. Mnoho nezkušených vývojářů tvrdí, že na podrobný návrh není čas. V tomto případě ale platí přísloví „Nikdy není dostatek času na správný návrh databáze, ale vždy se najde dostatek času na její předělání.“
Správný návrh databáze se skládá z několika základních kroků
• Formulace cílů a požadavků
• Vytváření datových struktur
• Určení a zřízení vztahů mezi tabulkami
• Určení a definování vnitřních pravidel firmy/organizace
• Určení a definování pohledů
• Kontrola integrity
Základním prostředkem pro návrh IS jsou rozhovory s klíčovými uživateli a vedením ve firmě. Bez komunikace s uživateli není vývojář schopen vytvořit IS, který bude používán a hlavně bude usnadňovat práci. V každé organizaci existují omezení, která nezasvěcený pozorovatel nemůže odhalit. Jako vývojář musíte podstoupit několik pohovorů. Jejich počet je závislý na ochotě spolupracovat a odborné znalosti problému zúčastněných pracovníků firmy. V různých etapách vývoje IS jsou jiná pravidla pro vedení pohovorů. Někdy je dobré mít při jednáních nadřízeného zúčastněných a naopak v jistých situacích to nenapomáhá zdárnému vyřešení problému. Vedení rozhovorů má mnoho úskalí, které je dobré před schůzkou nastudovat, jinak může počet absolvovaných pohovorů narůstat. Jelikož je to nezbytnou součástí procesu návrhu IS rozhodl jsem se tomuto tématu věnovat celou kapitolu.
Každá pracovní schůzka by měla přinést maximum relevantních informací.
Proto zde uvedu několik zásad pro korektní vedení rozhovorů.
• Na každý rozhovor pozveme maximálně deset účastníků
• Pokud provádíme pohovory se skupinami, vždy určíme vedoucí jednotlivých skupin
• Otázky si připravujeme před rozhovorem
• Zaznamenáváme si na papír nebo diktafon průběh rozhovoru
• Každému účastníkovi věnujeme stejnou a plnou pozornost
• Udržujeme tempo rozhovoru
• Udržujeme kontrolu nad rozhovorem
V první části pracovních schůzek musíme stanovit problémy, které má IS pomáhat řešit. Základní informace je, pro jaký účel je IS tvořen a kdo s ním bude pracovat. Dalším krokem je zformulovat cíle úkolů. To znamená přesně určit operace, které se budou provádět s daty. Tyto informace by nám měli poskytnout představu o vznikající aplikaci. V této fázi hlavně nasloucháme a děláme si poznámky. Do hovoru zasahujeme co možná nejméně.
V následujícím rozhovoru musíme stanovit předběžný seznam typů entit a atributů. Typ entity je abstrakce popisující objekt reálného světa. Tuto práci si můžeme poměrně usnadnit, pokud ve firmě používají nějakou formu databáze. Pro tento typ rozhovorů jsou přesně stanoveny metody. Jedna z účinných metod je zeptat se účastníka pohovoru na jeho každodenní práci. V jeho odpovědi nalezneme množství podstatných jmen, která mohou reprezentovat typy entit. Dále se zeptáme, s jakými daty pracuje, a která data jsou nezbytná pro jeho každodenní činnost. Tím bychom si měli udělat předběžný seznam atributů. Do hovoru zasahujeme pouze, pokud spěje do fáze, která nám nepřináší relevantní informace. Jinak pouze klademe předem připravené otázky a děláme si poznámky.
Pokud dochází ve firmě k zavádění nového procesu, který nebyl předtím používán, forma otázek se mění. Namísto otázek co děláte a s jakými daty pracujete, se používají otázky: „jaká data budete potřebovat a jaké operace se s nimi budou provádět“. Zde je složitější identifikace předběžných seznamů atributů a typů entit.
Další z rozhovorů se zaměstnanci, které musíme absolvovat je ten, který nám pomůže stanovit vnitřní pravidla. Jsou to interní pravidla firmy, které chtějí mít ošetřeny databází. Týká se to stupně účasti, specifikace atributů nebo charakteristiky některého ze vztahů.
Následující fáze bude probíhat bez rozhovorů. Připravíme si modely nově vznikajícího IS. Je nezbytné připravit jak funkční tak datový model. Kapitola 3.3. je věnována této problematice.
Pokud máme připravené modely IS musíme konzultovat jejich správnost s klíčovými uživateli a vedením. V této fázi už neprobíhá rozhovor běžným způsobem, ale má spíše informativní ráz. Do modelů jsou zapracovány pouze věcné připomínky.
Dostáváme se do poslední fáze rozhovorů. Nyní stanovíme pohledy. Vytvoříme virtuální pohledy na fyzické tabulky. Umožníme uživatelům prohlížet data uložená v databázi i z několika tabulek najednou. Dělí se na datový, agregační, validační.
Datový pohled nám zobrazí některé pole z tabulky nebo více tabulek najednou.
Agregační použijeme pro zobrazení vypočítaných polí. To znamená pro získání statistických informací. Poslední typ nahrazuje validační tabulku. Rozdíl je pouze ve fázi vzniku. Validační tabulka data uchovává a je součástí základních tabulek. Validační pohled je získává ze základních tabulek obsažených v databázi.
Jak již bylo řečeno v úvodu této kapitoly počet pohovorů je závislý na ochotě účastníků spolupracovat a na jejich odborné znalosti problému. Oba faktory můžeme do jisté míry ovlivnit, dodržením pravidel uvedených na začátku kapitoly nebo obměnou týmu. Ovšem nelze v žádném případě říci, že zde uvedený postup bude v jednotlivých případech dostačující.
3.3. Modelování databáze
Pro tvorbu databázového schématu slouží modelování. Na schéma lze nahlížet jako na deklaraci typu dat. A na hotovou databázi jako na množinu instancí daného typu. Modelování nám umožňuje tvořit schémata v požadované NF a významným způsobem ulehčuje implementační část.
Mezi nejznámější a nejpoužívanější metodologie vývoje systému patří YSM.
Podstatou je modelování reality pomocí objektů (atributů, entit, vztahů, toků dat...).
Hlavní součásti metodologie vytvořené panem Yourdonem jsou datový model, funkční model, model řízení systému a model struktury programového systému [14].
Pro grafickou reprezentaci se používají schémata, která nazýváme diagramy.
První z diagramů reprezentuje konceptuální model neboli datový model. Tento model může být reprezentován ERD někdy také označovaný ERA. Další součástí celkového schématu je funkční model. Může být reprezentován DFD, popisující toky dat uvnitř databáze. Pro tvorbu modelů existují další nástroje, jako např. UML nebo pro popis struktury XML. Těmto nástrojům se budu věnovat v následujících kapitolách.
Pro každou funkční a v praxi použitelnou databázi je nezbytné nepodcenit její návrh. V současné době je na trhu pro vývoj databázového informačního systému
mnoho sofistikovaných nástrojů. Konkrétně pro návrh, analýzu, integraci a čištění dat to jsou nástroje CASE.
Pro tvorbu modelu slouží velké množství SW založeného na ER. Z těch hlavních bych uvedl CASE Studio od firmy Charonware, Oracle Designer od firmy Oracle, Power Designer od firmy Sybase, Select Enterprise, Rational Rose, XTG Data Modeler, Visio od firmy MS…
Pro svoji práci budeme používat CASE studio 2.23. Výhodou tohoto nástroje je možnost tvorby datového i funkčního modelu.
3.3.1. Datová analýza
Datový model je vyjádřením statického pohledu na realitu. Jako objekty pro simulování reality využívá atributy, entity a vztahy (relace) mezi nimi. Datovou analýzu, jinak také nazývanou konceptuální modelování, lze reprezentovat ER- modelem. Konceptuální modelování je proces vývoje sémantického popisu nějakého systému, který je uplatněn při analýze databázové aplikace. Důležitou vlastností konceptuálního modelu je jeho nezávislost na použitém SŘBD. Základy ER-modelu zformuloval P. Chen v r. 1979.
V dnešní době je velká rozmanitost v ER-modelech. Samozřejmě existuje více datových modelů, které nejsou založeny na ER. Jako příklad lze uvést český HIT viz obr. 3.1. Avšak žádný z nich nedosáhl takové popularity jako právě ER.
Obr. 3.1 Atribut v HIT-modelu
Pro přesný návrh a pozdější orientaci v jednotlivých entitách a atributech je nutné věnovat pozornost datové analýze. Logický návrh databáze se skládá z několika částí. Na obrázku 3.2 je zobrazena metodologie návrhu databáze. Metodologie je přístup obsahující metody a postupy pro tvorbu konečného schématu.
Obr. 3.2 Metodologie logického návrhu databáze [3]
V následujících kapitolách budeme postupovat dle metodologie zobrazené na obrázku 3.2. Konkrétně v kapitole 3.3.1.1. bude popsána tvorba ER modelu a v kapitole 3.3.1.2. bude transformace ER schématu do relačního schématu databáze.
3.3.1.1. ER – model
Konceptuální model reprezentovaný ERD nám umožňuje identifikovat entitní typy, vztahy mezi nimi. Přiřazuje typům entit a vztahům atributy (vlastnosti entit a vztahů) a formuluje různá IO. Pod pojmem entita rozumíme objekt z reálného světa, jehož vlastnosti (hodnoty atributů) chceme evidovat. Entitní typ je popsán jménem a množinou atributů. Entita je instance (konkrétní objekt) entitního typu s konkrétními hodnotami atributů. Jednotlivé entity v rámci entitního typu odlišují identifikační klíče.
Klíč je podmnožina množiny atributů. Vztah modeluje vazbu mezi dvěma nebo více entitami. Vztah je definován názvem a množinou entitních typů.
Pro tvorbu ER-modelu se nabízejí dvě varianty zpracování. Lineárně textový a diagramy. Pro lineárně textové modelování je stanovena jednoduchá konvence. Názvy entitních typů začínají velkým písmenem, názvy atributů malým písmem a klíč je podtržen. Název vazby je psán velkými písmeny. Příklad lineárně textového modelu může vypadat takto:
ENTITA:Zákazník (id_zákazníka, telefon, adresa, e-mail, jméno, příjmení, datum narození, firma) Objednávka (id_objednávky, id_zákazníka, datum objednávky, cena)
RELACE: MÁ-OBJEDNÁNO (zákazník, objednávka)
Lineárně textový je ovšem velmi nepřehledný, proto se téměř nepoužívá a přechází se na ER-diagramy.
Metodologie ER modelování lze rozdělit na dva základní kroky.
1. první krok - iterativní
• definice referenčních entit
• definice typů vztahů
• definice závislých entit 2. druhý krok
• formulují se atributy
• určují se identifikační klíče entit
V první části je důležité definovat typy entit. Typy entit definujeme ze svých poznámek, které jsme si pořizovali při rozhovorech. Již v této části návrhu není od věci najít alespoň kandidáty na klíče entit a přiřadit několik atributů, které jednotlivým entitám odpovídají. V této fázi návrhu nemusíme přiřazovat veškeré atributy jednotlivým entitám. Identifikační klíč je atribut (skupina atributů), který nám jednoznačně identifikuje entitu. Atribut se udává v jednotném čísle stejně jako název entity a popisuje nějakou vlastnost dané entity viz. obr. 3.3. V případě, že atribut považujeme za budoucí klíč, podtrhneme jej. Tento způsob označení klíčů je naznačen na obrázcích 3.3 a 3.4.
Obr. 3.3 Model typu entity s klíčovými atributy
V další části se zaměříme na definování vztahů. Mezi jednotlivými entitními typy existují vztahy, které nám pomohou omezit redundantní data a zajistit integritu na úrovni vztahů. Mezi dvojicí entitních typů, kde objevíme vztah, musíme tento vztah pojmenovat a určit jeho IO. Entitní typy jsou reprezentovány obdélníkem a vztahové typy kosočtvercem. Na obrázku 3.4 je zobrazen tento postup.
Obr. 3.4 Model vztahu dvou entitních typů
Jedním z důležitých IO, které musíme stanovit u vztahu, je kardinalita (poměr).
Toto IO se jinak také označuje typ vztahu. Známe 3 základní poměry – 1:1, 1:N, M:N.
1:1 – dvojice entitních typů je svázána vztahem 1:1, pokud je každá entita z entitního typu A (např. Kino) svázána s maximálně jednou entitou z entitního typu B (např Film), viz obrázek 3.5. Může zahrnovat případy 1:0 a 0:1 - záleží na konkrétních pravidlech. Z obrázku lze vyčíst, že typ entity Kino jednoznačně určuje entitní typ Film
(je jeho determinantem). A naopak Film je determinantem Kina. To znamená, že existuje funkční závislost Kina na Filmu a naopak.
Obr. 3.5 Kardinalita 1:1
1:N – dvojice entitních typů je svázána vztahem 1:N, pokud jedna entita z entitního typu A je svázána s jednou nebo více entitami z entitního typu B, viz obrázek 3.6. Entita z B může být svázána s maximálně jednou entitou z A. Opět záleží na pravidlech, ale většinou může zahrnovat i případy 1:0, 0:1, 1:1. Toto je nejčastější typ vztahu mezi entitními typy. Kino není determinantem, Film je determinantem.
Obr. 3.6 Kardinalita 1:N
M:N – dvojice entiních typů je svázána vztahem M:N, pokud jedna entita z entitního typu A je svázána s jednou nebo více entitami z entitního typu B a jedna entita z B je svázána s jednou nebo více entitami z A, viz obrázek 3.6. Obecně zahrnuje i případy 1:0, 0:1, 1:1, 1:N, N:1. Zde není ani Kino ani Film determinantem. M:N je druhý nejčastější typ vztahu.
Obr. 3.7 Kardinalita M:N
Pokud máme vyřešenou kardinalitu vztahu můžeme se věnovat dalšímu z IO a to konkrétně existenční závislosti. Jinak označované způsob účasti. Toto IO nám říká,
zda-li je účast povinná nebo volitelná. Povinná znamená, že pokud chci do jednoho entitního typu vložit entitu, tak v rodičovském entitním typu už musí existovat aspoň jedna entita, s kterou bychom ji mohli svázat. A naopak, u volitelné nemusí být v druhém entitním typu žádná entita (existuje bez vztahu). Použití se nabízí v případě Zaměstnance a Oddělení. Nabízí se několik variant. Např. způsob účasti u entitního typu Zaměstnanec ve vztahu je povinné (každý zaměstnanec musí být přiřazen do některého oddělení). A Oddělení má volitelné (může existovat oddělení, které nemá žádné zaměstnance) viz obr. 3.7. V ER se toto modeluje následujícím způsobem. Povinné členství má uvnitř modelu entitního typu proužek s kolečkem. A volitelné má vně obdélníku (model entitního typu) kolečko viz obr 3.7.
Obr. 3.8 Existenční závislost
Další z IO se označuje min/max nebo také stupeň účasti. Udává minimální počet entit, se kterými musí být spojena jedna entita v navázaném entitním typu. Dále udává maximální možný počet entit, se kterými může být svázána. Modeluje se následujícím způsobem. Nad vztah k entitnímu typu do závorky napíšeme minimální a maximální počet svázaných entit, příklad (1,2). Tohoto integritního omezení se často využívá pro stanovení vnitřních pravidel uvnitř organizace nebo firmy. Příkladem muže být, jeden zaměstnanec může obsluhovat maximálně dva zákazníky a minimálně jednoho. A zákazník musí mít právě jednoho obsluhujícího zaměstnance.
Nyní se dostáváme do fáze, kdy se budou podrobně definovat identifikační klíče.
Jak bylo řečeno dříve, každý entitní typ musí mít atribut nebo kombinaci atributů, který identifikuje každou instanci (entitu) daného entiního typu. Existují ovšem entitní typy, které nemají natolik jedinečný atribut nebo kombinace atributů, abychom mohli každou jejich instanci identifikovat. Nazývají se slabé entitní typy. Entitní typy, které nejsou slabé se nazývají silné nebo regulární. Slabý entitní typ musíme přiřadit do povinného vztahu k jinému entinímu typu. Ten nazýváme identifikační vlastník a vztah, který je spojuje se nazývá identifikační typ vztahu. U slabého entitního typu jeho vlastní klíčové atributy tvoří jen část identifikačního klíče. Druhou část identifikačního klíče tvoří klíč
vlastníka. Příkladem může být vztah dvou entitních typů Film a Kopie. Každý film má své identifikační číslo a každá jeho kopie je identifikovatelná pomocí identifikačního čísla kopie. Ale pokud uvažujeme, že na světě je nepřeberné množství filmů může se stát, že dvě kopie od různých filmů budou mít stejné identifikační číslo (v rámci entitního typu Kopie). Proto každou kopii doplníme o identifikátor filmu a tím se stává jedinečnou. Model slabého entitního typu je na obrázku 3.9. Název slabého entitního typu se zapisuje do druhého obdélníku a od typu vztahu na něj míří šipka.
Obr. 3.9 Slabý entitní typ
Nyní se naše konceptuální modelování dostává do poslední fáze. Máme stanoveny entitní typy, vyřešeny identifikační klíče a vztahy mezi jednotlivými entitními typy. Musíme se ještě zaměřit na atributy. Na počátku při definování entitních typů jsme každému přidělili několik atributů a nyní musíme doplnit ty zbývající.
Atributy musí vystihovat vlastnosti entitního typu.
Před zavedením IO na úrovní atributů je většinou potřeba odstranit vícesložkové a vícehodnotové atributy. Tuto činnost můžeme odložit až na transformaci do RMD.
Vícesložkový atribut se skládá z více součástí. Příkladem vícesložkového atributu je adresa. Skládá se z údajů jako stát, kraj, město, ulice, ČP, PSČ.. Řešením je rozdělit vícesložkový atribut na jednotlivé atributy. Vícehodnotový atribut obsahuje více hodnot stejného typu. Zbavíme se ho rozdělením entitního typu na dva entitní typy. Příklad vícehodnotového atributu je předmět u entitního typu Student. Každý studen může mít více zapsaných předmětů. Proto zavedeme nový entitní typ Předmět, kde budou zapsány všechny předměty studenta a provážeme jej s entitním typem Student odpovídající vazbou. Nyní lze říci, že naše atributy jsou atomické a můžeme definovat IO atributů.
Pro zavedení integrity na úrovni atributů a zvýšení celkové integrity dat je nutné specifikovat jednotlivé atributy – stanovit jejich IO. Tato specifikace se skládá ze tří
kategorií:
¾ Obecné vlastnosti – jméno atributu, rodičovská entita, popisek, aliasy, sdílenost
¾ Fyzické vlastnosti – datový typ, délka, desetinná místa, povolené znaky, formát
¾ Logické vlastnosti – typ klíče, struktura klíče, jedinečnost, implicitní hodnota, podpora null, původ hodnot, rozsah hodnot, řízená editace, povolené porovnávání, povolené operace
Absolvováním všech těchto bodů se dostáváme do úplně poslední fáze návrhu.
Nyní nás čeká přezkoumání integrity dat. Pokud máme v pořádku integrity:
9 Entitních typů 9 atributů 9 vztahů
9 vnitřních pravidel
můžeme s klidným svědomím říci, že náš ER model je správně a poctivě navržen.
Pro správné kreslení ER diagramů existuje několik zásad:
¾ minimalizovat křížení čar a snažit se, aby byly rovné
¾ nekreslit paralelní čáry těsně u sebe
¾ snažit se tvořit strukturu schématu zleva doprava
¾ u kardinalit 1:N umísťovat entitu s účastí N nalevo
¾ označovat jednotlivé diagramy datem, jménem a jménem autora
¾ používat podmnožiny ER diagramů
Pří tvorbě složitějších IS je třeba zvolit strategii, jak budeme přistupovat ke konstrukci celkového schématu. Nabízejí se 4 základní strategie:
¾ shora dolů
¾ zdola nahoru
¾ smíšená
¾ zevnitř ven
První strategie je založena na postupném konkretizování problému. Vychází z globálního pohledu na aplikaci a postupně vytváří podrobnější ER-diagram. Technika shora dolů nepatří mezi nejsnadnější. Chyba v počátcích našeho modelování technikou shora dolů může znamenat rozsáhlé opravy schématu. To je pro většinu vývojářů dostatečný argument pro to, aby pro rozsáhlé databáze používali další z technik.
Strategie zdola nahoru je přesným opakem. Vycházíme z jednotlivých typů objektů na nejnižší úrovni (atributů) a ty seskupujeme tak, aby vznikaly typy entit.
Tento přístup má řadu výhod. Poskytuje nám značný přehled o datových strukturách.
Lze využít paralelní přístup několika vývojových týmů a nesporným plusem je její jednoduchost. Osobně preferujeme tuto strategii, protože umožňuje rychlý a jednoduchý nástroj pro určení entit a vztahů.
Třetí technika je kombinací dvou předešlých. Smíšená strategie je založena na vytvoření skeletárního schématu. Poté vznikají oddělená schémata, která se nakonec integrují v jedno ucelené. K problémům dochází v závěrečné části, kdy má dojít k integraci jednotlivých konceptuálních schémat. Pro rozsáhlé systémy je výhodná, protože umožňuje nezávislou spolupráci více týmů najednou.
Poslední je strategie zevnitř ven. Jde o speciální případ strategie zdola nahoru.
Začínáme od entitních typů, které postupně doplňujeme a konkretizujeme. Podobně jako u předešlé techniky postupujeme pomocí mezi-schémat, která se nám postupně slučují. A právě nezbytné slučování může způsobovat problémy.
Jakákoliv z těchto technik vede ke správnému modelu databáze, pokud je použita korektním způsobem. Samozřejmě nelze očekávat stejný výsledek při použití různých technik. Závěrečná schémata se mohou výrazně lišit a přesto být správně.
3.3.1.2. Transformace ER schématu do relačního schématu databáze Metodologie, kterou jsme zvolili na začátku, je koncipována na strategii shora- dolů. Nejprve se navrhne konceptuální model a poté se pomocí následně uvedených pravidel transformuje do RMD. Existuje i druhý způsob datové analýzy. Je založený na normalizační teorii, která byla uvedena v kapitole 3.1.1. a 3.1.2. Předpokladem je schéma universální relace a jednoznačných vztahů mezi jednotlivými atributy.
Transformace ER schématu probíhá následujícím způsobem. RMD nerozlišuje entitní typ a vztahový typ. Relační model zobrazuje oba typy pomocí relací (tabulek).
Dá se říci, že entitnímu typu odpovídá schéma relace. A konkrétním entitám odpovídá relace.
Silný entitní typ je velice jednoduše reprezentovatelný v RMD. Atributy silného entitního typu přidělíme příslušnému schématu relace. Primární klíč bude tvořen stejnými atributy jako byl tvořen identifikační klíč u entitního typu. Jménům atributů se přiřadí domény relace. Jelikož jsme odstranili vícehodnotové a vícesložkové atributy již ve fázi konceptuálního modelování můžeme přejít na transformaci vztahů.
V ER schématu jsme použili několik druhů vazeb – 1:1, 1:N, M:N.
Transformace binárních vztahů z ER se provádí většinou pomocí připojování primárního klíče jednoho schématu relace (vzniklého transformací entitního typu) do druhého.
Pro kardinalitu 1:1 existují 3 možnosti transformace. Pokud mají oba entitní typy povinné členství ve vztahu můžeme atributy obou entitních typů zařadit do jednoho schématu relace. Pokud má jeden povinné členství a druhý volitelné definujeme dvě schémata relace. Vazbu realizujeme tak, že připojíme primární klíč (PK) ze schématu s volitelným členstvím do schématu s povinným členstvím viz obr.
3.10. Zde se stává cizím klíčem (FK). Pokud mají oba volitelné členství definujeme opět dvě schémata relace. Do jednoho schématu přidáme primární klíč druhého, ale ten bude mocí nabývat hodnoty NULL.
Obr. 3.10 Kardinalita 1:1
Kardinalitu 1:N lze také reprezentovat více způsoby. Opět záleží na existenční závislost entitních typů. Entitní typy účastnící se vazby nám budou opět reprezentovat dvě relační schémata. Postupuje se obdobně jako u kardinalita 1:1 pouze zde není možnost zařadit oba entitní typy do jednoho relačního schématu viz obr 3.11. Pokud je u jednoho entitního typu povinná účast je možno použít tři relační schémata. Dvě reprezentují entitní typ a jedno vztahový typ.
Obr. 3.11 Kardinalita 1:N
Poslední možností je kardinalita M:N. Zde nezáleží na existenční závislosti. Dva entitní typy transformujeme pomocí tří relačních schémat. Třetí relační schéma je vztahové a bude obsahovat primární klíče obou schémat účastnících se vazby viz obr.
3.12.
Obr. 3.12 Kardinalita M:N
Na začátku jsme si ukázali jak reprezentovat silný entitní typ. Nyní je potřeba transformovat slabé entitní typy. Ve všech předešlých obrázcích byla použita neidentifikující vazba. Rozdíl je v tom, že rodičovská tabulka určuje dceřinou tabulku pomocí svého primárního klíče. Primární klíč rodiče se stává primárním klíčem (PFK) potomka nebo částí primárního klíče potomka (PFK). Na obrázku 3.13 je zobrazen způsob transformace.
Obr. 3.13 Identifikující vazba – slabý entitní typ
Podle použité metodologie by nyní měla být datová analýza hotová. Je ovšem pravdou, že se nelze spoléhat na to, že náš ER model byl natolik dokonale navržený, že nepotřebuje další analýzu. Po transformaci do RMD máme silný nástroj pro jeho vylepšení. Tím nástrojem je normalizace.[3] [5]
Cílem je, aby tabulky byly v normální formě, která vyhovuje danému problému.
Pokud objevíme v našem relačním modelu jisté funkční závislosti, může to indikovat nový entitní typ, který není zařazen do našeho ER modelu. Proto musíme upravit náš ER model. Takto postupujeme, dokud naše relace nejsou v požadované NF. Poté můžeme říci, že i náš ER model je kvalitně navržen.
3.3.2. Funkční analýza
Nedílnou součástí analýzy IS je modelování činností, které v daném systému probíhají. Funkční model (FSD) nám poskytne představu o budoucí podobě uživatelského rozhraní. A dále nám umožní ověřit si správnost a úplnost datového modelu.
Pro funkční modelování se používají dvě základní skupiny techniky. První skupina je spíše zaměřena na data a jejich toky. Hodí se pro klasické IS, které se používají ve firmách a organizacích pro ukládání a zpracování dat. Ta druhá je výhodná pro aktivní databáze, kde dochází ke zpracování dat v reálném čase.
Ukázka rozdělení:
1.
• Hierarchie funkcí
• Toky dat
• Modelování událostí
2.
• Petriho sítě
• Stavové diagramy
Pro naše účely se hodí první skupina. Modelování hierarchie funkcí je nejjednodušší prostředek a proto se využívá pro modelování rozsáhlých databází. Na každou hierarchickou úroveň stavíme funkce, které pracují s objekty stejné složitosti.
Využívá se strategie shora dolů – začínáme s nejobecnější funkcí a dále ji rozkládáme na konkrétnější funkce. Pro modelování shora dolů se nejvíce hodí stromová struktura.
Tato metoda bude popsána podrobněji v další kapitole.
3.3.2.1. Hierarchie funkcí
Funkcí označujeme činnosti, které organizace nebo firma provádí. Při modelování postupujeme následujícím způsobem. Každou funkci pojmenujeme slovesem v rozkazovacím způsobu. V grafické vyjádření budeme funkce kreslit jako obdélník se zakulacenými rohy, s vepsaným názvem funkce a označením v hierarchii viz obrázek 3.14.
Obr. 3.14 Model funkce
Pro modelování hierarchie funkcí se využívá strategie shora dolů. To znamená, že dochází k určení funkcí a pomocí dekompozice se vytváří hierarchie, která má podobu stromu. Kořen stromu (nejvyšší funkce) je nahoře a dekompozice se provádí shora dolů pro horizontálně nakreslené funkce a zleva doprava pro vertikálně nakreslené funkce. Funkce vzniklé dekompozicí se nazývají dílčí funkce.[3]
Pro tvorbu správného modelu je důležitých několik zásad. Dílčí funkce musejí zcela pokrývat v hierarchii nadřazenou funkci. Nesmějí se navzájem překrývat a musejí se vyloučit funkce, které jsou nepodstatné pro nadřazenou funkci.[3]
Do hierarchie funkcí se mohou integrovat externí rozhraní – události, které fungují jako spouštěč (trigger). Tyto události zakreslujeme do schématu v podobě šipek s vepsaným jménem události. Příklad dekompozice funkce a triggru je na obrázku 3.15.
Obr. 3.15 Příklad dekompozice a triggeru
Jak již bylo řečeno dříve, základní stavební jednotkou hierarchického modelu jsou funkce. Rozlišujeme několik základních druhů funkcí. Pokud nelze funkci podrobit další dekompozice nazýváme ji atomickou. Dále to jsou funkce elementární – mají podobné vlastnosti jako databázové transakce. Elementární funkce se dají rozdělit na dílčí funkce (dekomponovat), ale pokud se neprovede jedna z dílčích funkcí, musejí se zrušit i ostatní již provedené. Elementární funkce se provede buď celá, nebo se neprovede vůbec. Pokud by se tato podmínka nedodržela, aplikace by se dostala do nekonzistentního stavu. Posledním druhem funkcí jsou společné. Vyskytují se na více místech v hierarchii.
3.3.2.2. Diagram toku dat – DFD
Někdy se používá název De Marcovy diagramy. Místo funkcí se používají procesy, které mohou reprezentovat více funkcí. Stejně jako se ER model skládal ze základních stavebních prvků (entita, atribut, vztah), tak i DFD se skládá ze 4 základních prvků. Jsou to proces, datový tok, zásobárna dat (datastore), externí rozhraní
(terminátor). Všechny 4 jsou zachyceny na obrázku 3.16. Výsledný diagram je orientovaný graf. Uzly jsou reprezentovány zásobárnami dat, procesy a externími rozhraními. Hrany představují toky dat a dělí se na vstupní a výstupní.
Obr. 3.16 Stavební prvky DFD
1) Proces - reprezentuje činnost uvnitř IS – mazání, manipulace, tvorba dat 2) Tok dat – reprezentuje výměnu dat mezi procesy
3) Data store – místo, kde jsou uložena data
4) Externí rozhraní – představuje vstup/výstup (zdroj nebo cíl datových toků)
Jako u ER modelování se nabízejí 4 základní strategie tvorby celkového schématu:
¾ Shora dolů
¾ Zdola nahoru
¾ Zevnitř ven
¾ Smíšená
Stejně jako u ER modelování je strategie shora dolů založena na postupném konkretizování problému. Začínáme nejobecnějším procesem, který poté rozdělíme (dekompozice) na specializovanější, detailnější procesy. Osobně preferujeme tuto strategii.
Přesně opačný přístup zastává strategie zdola nahoru. Na začátku definujeme všechny elementární procesy, rozhraní a zásobárny dat. Poté je spojujeme pomocí toků dat. Největší uplatnění nachází tato strategie v procesně orientovaných IS.
Strategie zevnitř ven postupuje od zásobáren dat. Při modelování začínáme s objekty, které ovlivňují IS zevnitř. Tato metoda je poněkud nepřehledná pro větší množství objektů.
Poslední je strategie smíšená. Základem je opět skeletární schéma a subschémata, která se nakonec slučují.
Při tvorbě DFD klademe hlavní důraz na úplnost, funkční nezávislost, korektnost, čitelnost, a minimalitu. Pokud dodržíme tyto zásady, máme model toku dat hotový.
3.3.3. UML
Jazyk UML je jazyk pro specifikaci, vizualizaci, konstrukci a dokumentaci softwarových produktů. Hlavními tvůrci jsou pánové Grady Booche, James Rumbaugh a Ivara Jacobson. V 80. letech, kdy začali vyvíjet jazyk UML, existovalo mnoho metodologií pro objektově orientovanou analýzu návrhu. V mnoha případech symboly v jednom zápisu znamenaly úplně odlišnou věc v jiném. Tím pádem vznikaly problémy při spolupráci firem, které používaly odlišný zápis modelů. Proto v roce 1996 vznikla první verze unifikovaného modelovacího jazyka – UML 1.0. V roce 1997 ho převzala sdružení OMG pod označením 1.1. Jazyk UML se začal stávat standardem pro moderní softwarové inženýrství. V roce 2007 je aktuální verze 2.0.
Definice UML obsahuje 4 základní části:
• Definice notace UML (syntaxe)
• Meta-model UML (sémantika)
• Jazyk OCL (popis dalších vlastností modelu)
• Specifikace převodu do výměnných formátů (XML, DTD, COBRA IDL) Softwarové systémy lze simulovat pomocí různých typů modelů. Lze použít klasický textový nebo založený na dvourozměrných obrazcích. Pro větší přehlednost se používají diagramy složené ze základních dvourozměrných elementů propojených pomocí spojnic. Diagram je graficky znázorněný pohled na model.
Vytvořený model nám musí poskytnout ucelené informace o systému. Většinou nestačí pouze jeden diagram pro zachycení celého systému, proto se používá v UML celá sada unifikovaných dvourozměrných diagramů. Konkrétně to jsou:
• Use Case Diagram
• Class Diagram
• Object Diagram
• Sequence Diagram
• Collaboration Diagram
• StateChart Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram
Každý z těchto osmi diagramů popisuje jinou část systému. Statickou strukturu vyjadřují Class, Object, Collaboration, Component diagram a Deployment diagram.
Dynamickou stránku prezentují StateChart, Sequence, Collaboration diagram a Activity diagram.
Pro každou fázi vývoje se používají jiné druhy diagramů. V analytické části
vývoje systému se používají Class Diagram, Use Case Diagram, Activity Diagram, Sequence Diagram, Component Diagram a StateChart Diagram. V návrhové části se využívají Class Diagram, Deployment Diagram, Activity Diagram, Component Diagram a Collaboration Diagram. V závěrečné části, která se nazývá implementační, se používají Class Diagram, Component Diagram a Deployment Diagram.
Pro účely vymodelování databázového informačního systému budou stačit tři základní diagramy. Konkrétně to jsou Use Case Diagram, Class Diagram a Deployment Diagram.
3.3.3.1. Use Case Diagram
Use case diagram se používá pro identifikování prvků a procesů, které formují systém. Primární prvky nazýváme:
• Use case – případ užití (funkce systému)
• Actors – účastníci (pracují se systémem)
• Relationship – vztahy (vazby mezi jednotlivými use case)
• Associations – asociace (vazby mezi actors a use case)
Diagram ukazuje, kteří actors (postavičky v diagramu) spolupracují s definovanými use case (ovály v diagramu) viz obr 3.17.
Obr. 3.17 Actor, association, use case
Dále nám vymezují hranice mezi systémem a okolím a jeho použití z pohledu uživatele.
Hranice systému jsou reprezentovány obdélníkem, do kterého se vkládají případy užití.
Případy užití související s daným systémem mohou být propojeny s účastníky, kteří systém ovlivňují zvenku (vkládají data, získávají data) viz obrázek 3.18. V Use case
diagramu lze nalézt jistou analogii s DFD nejvyšší úrovně.
Obr. 3.18 Use case diagram pro restaurace
Mezi případy použití mohou existovat vztahy (relationship):
• Include
• Extend
• Generalization
V první formě interakce zahrnuje (include) jeden případ použití druhý. Tato forma se reprezentuje pomocí čerchované šipky se stereotypem include. Ta směřuje k zahrnovanému případu použití.
Extend znamená v překladu rozšiřuje. Jeden případ použití rozšiřuje druhý.
Příklad může být následující. Pokud si student registruje předmět a zjistí, že je plně obsazen je nezbytné mu umožnit nahlédnout na jiné předměty. Use case Poskytnutí informací o předmětu rozšiřuje Use case Registrace. V modelu je to zobrazeno pomocí čerchované čáry se stereotypem extend.
Generalization je zevšeobecnění. Užívá se pro vztahy, kdy jeden případ použití je specializovanějším případem druhého. Kreslí se plnou čarou zakončenou nevyplněným trojúhelníkem (šipkou). Šipka směřuje od specializovaného k obecnějšímu případu použití.
Jednotlivé vztahy mezi use case jsou vymodelovány na obrázku 3.19.
Obr. 3.19 Relationships 3.3.3.2. Class Diagram
Pro konceptuální modelování databáze je důležitý Class Diagram. Modeluje entitní typy jako třídy, vazby jako asociace a vlastnosti objektů jako atributy. Třídy kreslíme jako obdélník rozdělený na tři části. V první části obdélníku deklarujeme název třídy a stereotyp. Stereotyp nám umožňuje lépe popsat význam třídy. Pokud se jedná o třídu, která bude uložena v SŘBD, používá se stereotyp table. Do druhé části obdélníku zaznamenáváme atributy třídy a do poslední metody (funkce), které je možné vykonávat nad třídou.
Každý atribut je specifikován pomocí pěti obecných vlastností:
• stereotype – význam atributu
• visibility – (používá + pro public, # pro protected, - pro private)
• atribute name – jméno atributu
• multiplicity – označuje vícehodnotový atribut
• / – označuje odvozený atribut
Každá metoda je specifikována pomocí pěti obecných vlastností:
• stereotype – význam metody
• visibility – stejné jako u atributu
• parameters – seznam parametrů oddělený tečkami
• methodName – název metody
• returnType – návratová hodnota metody
UML neobsahuje označení pro klíčový atribut, proto se tento nedostatek řeší pomocí poznámek. Poznámky se dají využívat pro přesnější a výstižnější popsání.
Příklad vymodelované třídy je na obrázku 3.20.
Obr. 3.20 Model třídy v UML
Vazby v UML nazýváme asociace a značíme je hranou mezi třídami. Asociace je definována názvem rolí a násobností. Násobnost nám udává, kolik instancí jedné třídy je ve vztahu s instancí druhé třídy. Příklad asociace dvou tříd je na obrázku 3.21.
Obr. 3.21 Asociace dvou tříd
V UML se dají použít tři jedinečné asociace – agregace, kompozice a generalizace. Generalizace je typ vztahu, kdy jedna třída je zobecněním vlastností jiné třídy. Kompozice je silnější druh agregace. Část zaniká zároveň s celkem a je závislá pouze na jednom celku.
Pro modelování databází je nejdůležitější asociace agregace. Agregaci se někdy říká skládá se z. Jedna třída má funkci celku a její instance se skládá z více instancí druhé třídy. Agregace se označuje vyplněným kosodélníkem na straně celku, viz obrázek 3.22.
Obr. 3.22 Agregace
Pro speciální případy asociace v databázích se používá typicky objektová vlastnost a tou je dědičnost. Jelikož je konceptuální model nezávislý na SŘBD, lze tuto čistě objektovou vlastnost použít i v relačním modelu. Podtřída dědí atributy i metody.
Příklad je na obrázku 3.23.
