Deployment Diagram

Deployment diagram, nebo-li diagram nasazení, je poslední z nezbytných diagramů pro tvorbu databázového informačního systému. Hlavním přínosem deployment diagramu je, že popisuje fyzické rozmístění elementů systému. Zobrazuje skutečné vztahy mezi částmi systému po jeho spuštění (fyzická architektura systému).

Jednotlivé SW komponenty se zobrazují na HW zdrojích (výpočetní uzly) a pomocí hran (většinou síťové spojení) se naznačuje jejich vzájemná spolupráce. Dále se dá vymodelovat topologie sítě nebo použitý protokol pro komunikaci.

Hlavní prvky tohoto diagramu jsou uzly. Mohou být dvojího druhu:

• zařízení – fyzické zařízení pro zpracování dat, jako jsou mobilní telefony, PC, servery..

• EEN – SW jednotka, která běží na fyzickém zařízení (uzlu), poskytuje služby dalším SW elementům, na jednom fyzickém uzlu může být spuštěno více EEN, příkladem EEN jsou:

¾ Virtual Machine

¾ Operační systém (windows, linux, unix..)

¾ Web browser

¾ DB stroj

¾ Servlet container

¾ Workflow engine

Příklad jednoduchého deployment diagramu je obrázek 3.24.

Obr. 3.24 Deployment diagram 3.3.4. XML

V oblasti zpracování textu bylo potřeba označit význam jednotlivých částí. Proto v 80. letech byl standardizován jazyk GML. Pravděpodobně první značkovací jazyk vůbec, který vytvořili pánové Goldfarb, Mosher, Lorie. V roce 1986 se z GML vytvořil nový značkovací jazyk SGML. Umožňoval definici vlastních značkovacích jazyků (sad značek) pomocí DTD. Asi nejznámější aplikací SGML je jazyk používaný pro tvorbu webových stránek HTML. Nevýhodou SGML je přílišná komplexnost a tudíž obtížná implementace. Proto se vzala nejdůležitější a nejvíce používaná podmožina SGML a vytvořil se nový jazyk XML.

XML je značkovací jazyk vyvinutý konsorciem W3C. Na rozdíl od SGML jsou délka názvů značek, použité oddělovače a speciální znaky předem definované a nelze je měnit. Lepší označení pro XML je metajazyk, neboť pomocí DTD lze vytvářet vlastní jazyk s vlastními značkami. Takto vznikl například XHTML – kombinace HTML a XML.

XML se dnes používá pro snadnou výměnu informací. Obecně se dá říci, že slouží pro popis dat. Tudíž ho lze využít i pro strukturovaný popis dat uvnitř databáze.

Komunikace je nezávislá na platformě a aplikaci. Další výhodou je podpora všech světových jazyků, malá velikost dokumentu a jednoduchý převod na jiné formáty.

Každý XML dokument se skládá z elementů a těm zase náleží atributy. Element má své jméno a je uvozen mezi počáteční značku (start tag) a koncovou značku (end tag). Mezi počátečním a koncovým tagem je obsah elementu. Příklad je na obrázku 3.25.

Obr. 3.25 XML dokument

Příklad na obrázku 3.25 se skládá z jednoho elementu books a dvou podelementů book. Element book obsahuje dva dětské elementy title, author a atribut id.

Na rozdíl od relačního datového modelu se v XML rozlišuje pořadí elementů.

Obsah tabulky z relační databáze popsaný pomocí XML je na obrázku 3.26.

Obr. 3.26 Zobrazení databázových dat pomocí XML

3.3.4.1. DOM

Rozhraní DOM slouží pro schématické zobrazení XML dat. Dokument je zobrazen v hierarchicky stromové struktuře. Každému elementu, podelementu i atributu ve schématu odpovídá jeden uzel. Vztah mezi nimi zobrazujeme hranou, viz obrázek 3.27.

Obr. 3.27 Stromové schéma XML dokumentu z obrázku 3.25 3.4. SQL

Prvopočátky jazyka SQL spadají do roku 1974. V tomto roce uveřejnil své revoluční myšlenky o relačním databázovém modelu Dr. Codd. První prototypová implementace se jmenoval SEQUEL a vznikla v laboratoři IBM v San Jose v Kalifornii.

Postupně si většina firem, zabývajících se databázovými informačními systémy (Oracle, SyBase, Informix..), uvědomila obrovský přínos standardizovaného jazyka pro správu databáze a přidaly se k vývoji. Tak vznikl „nepsaný standard“ databázového jazyka SQL. V roce 1986 přijímá SQL jako standard organizace ANSI a o rok později ISO.

Tato verze se nazývá podle roku přijetí SQL86. Rozšířená verze o možnost definovat integritní omezení se nazývá SQL89. V roce 1992 přišla verze SQL2/SQL92, která nabízela například lepší podporu transakcí. Jeden z posledních standardů je SQL3, který je objektově orientovaný (1996). Jazyk SQL je implementován v řadě komerčních SŘBD (obvykle na úrovní SQL92).

SQL je více než dotazovací jazyk. Umožňuje definovat data a uživatelská práva přístupu k relacím. Dále nabízí možnost tvorby pohledů (virtuální relace). Pro rychlejší přístup k prvkům relací při zpracování uživatelského požadavku nabízí možnost tvorby

indexů. Od verze SQL89 definovat integritní omezení. Dále je to řízení transakcí (příkazy pro začátek a konec transakce) od verze SQL2/SQL92.

SQL se v relačních SŘBD vyskytuje obvykle ve dvou verzích současně – interakční a hostitelská. V interakční verzi se dají používat příkazy samostatně v režimu online - pomocí příkazového řádku (psaní SQL dotazů) nebo grafického nástroje, který umožní vytvářet dotazy pomocí grafických ovládacích prvků. V hostitelské verzi se příkazy SQL stávají součástí hostitelského jazyka, jako například Java, Delphi, C++

apod. To znamená naprogramovat GUI pro předem definované úkony. Cílovému uživateli neumožním vytvářet dotazy do databáze, ale umožním mu používat před-programované funkce, které ke své práci bude potřebovat. V hostitelské verzi je nutné vhodně realizovat vazby mezi proměnnými programovacího jazyka a výsledky dotazů v SQL. Dotazy jsou součástí zdrojového kódu programu, proto je nutné je oddělit od ostatních příkazů daného jazyka.

Jazyk SQL můžeme rozdělit na dvě základní podmnožiny DDL, DML [9]. DDL umožňuje vytvářet, rušit nebo měnit struktury objektů (tabulky, indexy, pohledy..) v databázi. Příklady příkazů spadajících do skupiny DDL jsou CREATE TABLE, CREATE DATABASE, DROP TABLE, CREATE VIEW...

Pro manipulace s daty je důležitá podmnožina DML, která obsahuje 4 základní příkazy:

• Select

• Insert

• Update

• Delete

Kromě těchto dvou hlavních podmnožin můžeme některé příkazy jazyka SQL zařadit do podmnožiny řídících příkazů DCL [9]. Podmnožina DCL obsahuje speciální příkazy pro řízení provozu a údržbu databáze, jako je např. CREATE USER, GRANT, REVOKE...

Podmnožina příkazů pro řízení transakcí TCC [9].TCC je určená pro řízení

transakcí např. SET TRANSACTION, COMMIT, SAVEPOINT...

Standardní SQL podporuje koncepci transakce v rámci hostitelského jazyka.

Transakce je definována jako posloupnost příkazů SQL formující jednotku zotavení z chyb a souběžného zpracování. Transakce jsou implicitní v tom smyslu, že první příkaz SQL znamená počátek transakce. Každá transakce končí vyvoláním bud' příkazu COMMIT WORK (potvrzuje platnost transakce) nebo ROLLBACK WORK (zruší všechny změny, které dosud v průběhu transakce proběhly). Příkladem transakce je převod finanční částky z jednoho účtu na druhý.

Hlavním omezením jazyka SQL je fakt, že se jedná o neprocedurální jazyk.

Příkazy jsou zpracovány sekvenčně bez použití klasických programátorských konstrukcí jako jsou cykly, podmínky, funkce a procedury. Proto každý moderní SŘBD obsahuje implementaci procedurálního rozšíření jazyka SQL. Příkladem je platforma Oracle, která implementuje procedurální jazyk PL/SQL nebo Microsoft SQL Server 2000 nabízí Transact SQL (T-SQL).

4. Vlastní návrh IS

Zadáním naší práce bylo vytvořit databázový informační systém pro podporu procesu neustálého zlepšování. Tento úkol se skládal z několika částí. V první řadě to bylo vytvořit datový a funkční model. Dále vytvořit databázi a naprogramovat grafické uživatelské rozhraní. Tyto vyjmenované kroky budou postupně, jak zde byly uvedeny, popsány v následujících kapitolách.

Pro vymodelování naší databáze jsme vybrali nástroj CASE Studio 2.23.1 Tento SW nabízí nejenom tvorbu datového modelu ERD, ale také funkčního modelu DFD.

Pro tvorbu databáze jsme si vybrali databázový systém Oracle 10g Express Edition. A pro tvorbu uživatelského rozhraní Java 2 Platform Standard Edition Development Kit 6.0 a NetBeans IDE 5.5 vývojové prostředí.

Před vlastní tvorbou modelů bylo nutné absolvovat několik pohovorů, které nám pomohly určit předběžný seznam atributů a typů entit. Dále určit operace, které se budou provádět s daty a kdo s nimi bude pracovat. Návod na korektní vedení takovýchto pohovorů je popsán v kapitole 3.2.

4.1. ERD

Tvorba ER modelu byla podrobně popsána v kapitole 3.3.1.1. Proto se nebudeme více věnovat teoretickému popisu ERD a raději popíšeme námi navržené schéma.

V prvé řadě jsme museli zvolit metodologii logického návrhu databáze.

Nejvhodnější se nám zdála metodologie uvedená v kapitole 3.3.1 strana 24 obrázek 3.2.

Pro tvorbu konceptuálního schématu jsme zvolili strategii zdola nahoru.

Pomocí této strategie jsme získali 21 entitních typů. Konkrétně to jsou: ZAVOD, PROVOZ, HALA, LINKA, USEK, TAKT, PRACOVISTE, OPERACE, VSTUP, WS, SCHUZKA, CLEN_WS, CLEN, SEF, POVERENI, PROBLEM, OPATRENI, PREDP_USPORA, NASAZENI, ZAMESTNANEC, USPORA.

Mezi nově vzniklými entitními typy jsme museli najít typy vztahů, určit jejich IO a zvolit identifikační klíče. Pro větší přehlednost jsme celkové schéma rozdělili na 3 části. Hlavní část našeho schématu je vidět na obrázku 4.1. Ukazuje nejdůležitější aspekty pro proces neustálého zlepšování. Na každou operaci bude udělán minimálně jeden workshop. Členové týmu budou odhalovat problémy, které jsou potřeba odstranit z průběhu operace, na pracovních schůzkách.

Obr. 4.1 Hlavní část KVP schématu

Mezi jednotlivými entitními typy jsme nalezli typy vztahů. Například u dvojice OPERACE a WS to je typ vztahu ZLEPSUJE, kardinalita vztahu 1:N, povinný typ účasti na obou stranách. Dále je patrné, že oba entitní typy jsou regulární (silné). Další typ vztahu je NALEZA mezi entitními typy WS a PROBLEM. Je zde opět kardinalita 1:N. Členství ve vztahu entitního typu WS je volitelné a entitního typu PROBLEM je povinné. Důvod je prostý, mohou se objevovat operace, které nebudou potřebovat vylepšovat (nemají žádný problém), ale k takovému závěru lze dojít až na základě workshopu (WS). Opět jsou oba entitní typy regulární. V další části našeho výseku jsou dva vztahové typy (JE, MA) a tři entitní typy (WS, CLEN_WS, CLEN). Ve skutečnosti to jsou pouze dva entitní typy s kardinalitou M:N. V konceptuálním schématu se kardinality M:N dvou entitních typů dekomponují pomocí vazební entity (CLEN_WS) na dva vztahy typu 1:N. Entitní typ SEF je svázán s entitním typem CLEN s kardinalitou 1:N. V našem případě nelze použít self-relaci, neboť u členů týmu musíme uchovávat více informací (role, důležitost) než u jeho nadřízeného. V entitním typu SEF jsou uloženy pouze základní informace o nadřízeném člena workshopu, a to z důvodu, že nadřízený by měl uvolnit člena týmu v termínech, kdy probíhá workshop.

Do entitního typu POVERENI může jakýkoliv člen týmu zadat informace o člověku, který převezme jeho roli. Entitní typ POVERENY je svázán s vazební entitou CLEN_WS, aby bylo možné pověřovat lidi dle výběru člena týmu bez jakýchkoli omezení. Na hlavním výseku KVP schématu je typ vztahu VSTUPUJE mezi entitními typy OPERACE a VSTUP s kardinalitou 1:1. Zde se ukládají informace o materiálu, nářadí, normě obsluhy.. , které vstupují do operace.

Druhou část schématu lze nazvat identifikační, protože přesně určuje a popisuje konkrétní operaci, viz obrázek 4.2.

Obr. 4.2 Identifikační část KVP schématu

V této části schématu je uložena hierarchie fabriky. V jednotlivých entitách jsou uloženy informace potřebné pro průběh workshopu. Například na jakém pracovišti je prováděna operace, kdo ji provádí, kde je pracoviště umístěno a kdo je zde mistrem..

Zajímavostí je entitní typ PROVOZ, který je oproti ostatním slabý. Mezi entitním typem ZÁVOD a PROVOZ je identifikační typ vztahu. Identifikační klíč entitního typu ZÁVOD se stává částí identifikačního klíče entitního typu PROVOZ.

Poslední část schématu lze nazvat zlepšování. Zde jsou uloženy poznatky, které pomohou zdokonalit operaci. Tato část schématu je na obrázku 4.3.

Obr. 4.3 Část zlepšování ze schématu KVP

Na obrázku 4.3 je vidět průběh workshopu. Nejprve jsou určovány problémy a poté je navrženo opatření. Mezi entitním typem PROBLEM a OPATRENI je kardinalita 1:N, jelikož může existovat více řešení, která mohou vést k odstranění problému. U každého opatření je nezbytné definovat předpokládanou úsporu. Opatření má pouze jednu předpokládanou úsporu, proto kardinalita 1:1. Je nezbytné tuto předpokládanou úsporu vyčíslit, proto je účast ve vztahu povinná. Následně se vybere to nejlepší opatření (většinou největší předpokládaná úspora) a to je nasazeno. Tím je pověřen odpovědný zaměstnanec nebo více zaměstnanců, v závislosti na složitosti nasazení. Po jisté době, kdy je opatření využíváno, je vyhodnocena reálná úspora. Vyhodnocením úspory končí workshop a tým se již nadále neschází.

4.2. DFD

Stejně jako ERD i teorie DFD byla podrobně vysvětlena v kapitole 3.3.2.2.

Tudíž se jí nebudeme více věnovat.

Pro tvorbu DFD jsme zvolili strategii shora dolů. Na nejvyšší úrovni našeho modelu je hlavní proces KVP. Jelikož jsme zvolili strategii shora dolů, budeme tento proces dále zjemňovat. Postupnou dekompozicí rozložíme náš hlavní proces na pod-procesy. Procesy jsou značeny oválem s názvem uvnitř. Jednotlivé procesy se propojují datovými toky (šipky) v pořadí v jakém se reálně vykonávají. Dále musíme propojovat procesy s data story (dvě plné čáry s názvem uprostřed), abychom vymodelovali ukládání a načítání dat. Pokud šipka datového toku směřuje k data store, jedná se o ukládání dat. Pokud směřuje od data store k procesu, jedná se o načítání dat. Poslední prvek v našem modelu je vstupně/výstupní rozhraní (obdélníky s názvem uvnitř).

Obr. 4.4 Kontextový diagram

Diagramu na nejvyšší úrovni se říká kontextový. Na obrázku 4.4 je zobrazen náš kontextový diagram. Zde je vidět hlavní proces s názvem KVP. Tento proces ovlivňuje (zadává a načítá data) několik vstupně/výstupních rozhraní. Hlavní úlohu zaujímá klíčový uživatel s názvem ADMIN_KVP, který nezasahuje přímo do průběhu procesu neustálého zlepšování. Spravuje jednotlivé uživatele a přiděluje jim požadovaně role.

Také může upravovat všechny tabulky ve schématu KVP. Ostatní vstupně/výstupní rozhraní budou popsány v následujících odstavcích.

Dekompozicí procesu KVP nám vzniklo 8 procesů: OVERENI HESLA A ID, SPUSTENI APLIKACE A PRIPOJENI SE K DATABAZI, SPRAVA UZIVATELU, SPRAVA SCHEMATU, ZALOZENI WS, EDITACE WS (PROCES ZLEPSOVANI), POSKYTNUTI PRAV, PROHLIZENI WS.

Do prvního procesu OVERENI HESLA A ID nám vstupuje rozhraní s názvem ZAMESTNANEC FIRMY SKODA a data store s názvem USER_SYS. USER_SYS je systémová tabulka, v které jsou uchovávána data o uživatelích (heslo a uživatelské jméno). Heslo a uživatelské jméno je porovnáno s daty načtenými ze systémové tabulky USER_SYS. Na obrázku 4.5 je vidět průběh ověření.

Pokud je heslo a uživatelské jméno zadáno správně, je spuštěna aplikace a naváže se spojení s databází. Každý uživatel kromě ADMINA_KVP (ten má veškerá objektová oprávnění na celé schéma KVP) má přidělenou jistou roli, podle toho jaká má objektová oprávnění. Konkrétně to jsou MODERATOR, CO-MODERATOR, CLEN_WS, UZIVATEL. Na následujícím obrázku budou zobrazeny jako rozhraní. Na obrázku 4.5 je vidět, že nejvíce objektových oprávnění má klíčový uživatel ADMIN_KVP a role MODERATOR a CO-MODERATOR.

Jak bylo uvedeno výše ADMIN_KVP nezasahuje přímo do procesu neustálého zlepšování. Pouze vytváří nové účty uživatelům systému, ruší uživatele, přiděluje, odebírá role a mění hesla. Tuto činnost reprezentuje proces s názvem SPRAVA UZIVATELU na obrázku 4.5. Veškerá objektová oprávnění na celé schéma KVP má z důvodu řešení možných chyb způsobených uživateli. Nápravu těchto chyb symbolizuje proces s názvem SPRAVA SCHEMATU viz obrázek 4.5.

Obr. 4.5 Průběh KVP

Pouze uživatelé s rolí MODERATOR nebo CO-MODERATOR mají právo založit workshop. Proces ZALOZENI WS se dále dělí na dílčí pod-procesy (IDENTIFIKACE WS, URCENI TYMU A SCHUZEK). Po založení workshopu následuje fáze zlepšování. Reprezentuje ji proces EDITACE WS (PROCES ZLEPSOVANI). Tento proces se opět dále dělí na dílčí pod-procesy např.

STANOVENI OPATRENI, STANOVENI NASAZENI, VYHODNOCENI WS… Do této fáze zasahují i uživatelé s rolí CLEN_WS. Proces POSKYTNUTI PRAV slouží pro uložení informací o uživateli, který převezme plnění úkolů po členovi workshopu. Data jsou uložena v data storu s názvem POVERENI. Poslední část je reprezentována procesem PROHLIZENI WS. Zde dochází k získávání a porovnávání dat ze všech data storů (entit) v našem schématu KVP. Prohlížet vytvořené workshopy mohou všechny tři dříve popsané role i role UZIVATEL.

4.3. Vytvoření databáze

Jako každý DBS se i Oracle 10g XE skládá ze dvou základních prvků – DB a SŘBD. Každý SŘBD odděluje datovou část od programové. Umožňuje definovat různé

datové struktury, obsahuje soubor instrukcí pro operace s daty a zaznamenává vztahy mezi objekty. Dále poskytuje víceuživatelský přístup a zabezpečuje ochranu dat.

Oracle 10g XE je volně stažitelný SW poskytovaný na stránkách http://www.oracle.com. Tato volně stažitelná verze je konkrétně 10g release 2 (10.2.0.1.0), která má oproti plné verzi následující omezení:

• Využívá maximálně jeden CPU nebo jeden dual core

• Využívá maximálně 1GB operační paměti

• Je omezen pouze na jednu instanci na jednom počítači (jedna databáze)

• Maximum uložených dat jsou 4GB

Omezení zde uvedená nejsou problémem pro naši nově vznikající databázi.

Oracle 10g nabízí nový Oracle Enterprise Manager – nástroj s množstvím návrhových dialogů pro kompletní správu databáze s plně webovým rozhraním. A stejně jako předešlé verze nabízí SQL Command line (SQL*plus) pro psaní sql dotazů. Dále umožňuje přistupovat k datům v databázi pomocí standardních rozhraní, jako jsou JDBC, ODBC, OLE DB, SQL…

Oracle 10g XE je koncipován na principu schémat. To znamená, že tento software je pouze jedna databáze a SŘBD. V rámci této jedné databáze lze vytvářet schémata (na úrovni databáze). Pokud chceme vytvořit nové schéma, vytvoříme nového uživatele (vlastník schématu). Podle názvu uživatele bude pojmenované i schéma.

4.3.1. Vlastník schématu a klíčový uživatel

V našem případě je to uživatel a tudíž i schéma s názvem KVP. Tento uživatel je vlastníkem schématu a má přidělena veškerá systémová oprávnění. Pro vytvoření schématu jsme použili skript vygenerovaný CASE Studiem. Tento skript jsme si načetli a spustili pomocí Oracle Enterprise Manageru a vytvořili strukturu schématu (tabulky, vztahy, klíče..). Jako vlastník schématu má veškerá objektová oprávnění nad celým schématem. Jelikož do průběhu zlepšování nebude nijak zasahovat, musí vytvořit klíčového uživatele a předat mu svá objektová oprávnění. Zvolili jsme klíčového uživatele s názvem ADMIN_KVP.

Uživatel ADMIN_KVP bude mít přidělené oprávnění dané rolí connect a systémová oprávnění create role, create profile, create user, drop user, alter user. Bude mít objektové oprávnění select na všechny sekvence. Klíčový uživatel ADMIN_KVP bude mít veškerá objektová oprávnění (select, update, insert, delete) na tabulky týkající se schématu KVP. Tyto oprávnění bude moci dále poskytovat (grantable). Dále bude mít veškerá objektová oprávnění nad tabulkou TRIGG, do které se budou ukládat data pomocí triggeru, kdo, kdy a co změnil, vymazal nebo vložil do tabulek WS, PROBLEM, OPATRENI, PREDP_USPORA, NASAZENI, USPORA, ZAMESTNANEC, VSTUP. ADMIN_KVP vytvoří role MODERATOR , Co-MODERATOR , UZIVATEL a CLEN_WS. Jelikož je vlastníkem rolí, bude oprávněn je poskytovat dalším uživatelům.

4.3.2. Role

Jisté skupiny uživatelů budou mít stejná přístupová oprávnění, proto se vyplatí vytvořit role. Umožňují nám sdružovat uživatele do skupin a ulehčí práci při jejich tvorbě.

Role MODERATOR bude mít oprávnění dané rolí connect. Stejně jako ADMIN_KVP bude mít tato role oprávnění select na všechny sekvence. Jelikož moderátor bude zakládat workshop, musí mít oprávnění insert a select nad tabulkami ZAVOD, PROVOZ, HALA, LINKA, USEK, TAKT, PRACOVISTE, OPERACE, SCHUZKA, CLEN_WS, CLEN, SEF, POVERENI. Dále musí mít veškerá objektová oprávnění nad tabulkami PROBLEM, WS, VSTUP, OPATRENI, PREDP_USPORA, NASAZENI, ZAMESTNANEC, USPORA. Posledním oprávněním je select nad tabulkou TRIGG.

Druhá role Co-MODERATOR bude mít přiděleny privilegia daná rolí connect.

Opět bude mít tato role oprávnění select na všechny sekvence. Dále bude mít možnost založení workshopu, tudíž stejná objektová oprávnění jako moderátor. Na rozdíl od role moderátor nebude mít oprávnění select nad tabulkou TRIGG.

Opět bude mít tato role oprávnění select na všechny sekvence. Dále bude mít možnost založení workshopu, tudíž stejná objektová oprávnění jako moderátor. Na rozdíl od role moderátor nebude mít oprávnění select nad tabulkou TRIGG.