Generátor dat pro testování databázových aplikací

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Generátor dat pro testování databázových aplikací Diplomová práce

Autor:

Bc. Jan Pňakovič Ekonomika a management, Informační technologie a management

Vedoucí práce:

Praha

Ing. Michal Valenta Ph.D.

Duben 2011

Generátor dat pro testování databázových aplikací

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 29. dubna 2011

Bc. Jan Pňakovič


Poděkování Rád bych poděkoval vedoucímu diplomové práce panu Ing. Michalu Valentovi Ph.D. za odbornou konzultaci, pomoc a vedení mých myšlenek při hlubším poznávání oblasti vývoje databázových aplikací. Dále bych chtěl také poděkovat Bc. Kryštofu Zetkovi za množství rad při analýze a návrhu aplikace, Mgr. Karlu Attlovi a Ondřeji Svobodovi za konzultace při realizaci klíčové části vývoje prototypové implementace a také všem, kteří mi poskytli velmi cenné rady a připomínky v průběhu psaní této práce. V neposlední řadě patří velké díky rodině, přátelům a kolegům za trpělivost a podporu.


Anotace Diplomová práce popisuje analýzu a návrh Generátoru dat pro testování databázových aplikací sloužící pro přípravu SQL výstupu. Ten je možné naimportovat do stávající databáze za účelem testování logických vazeb. Součástí diplomové práce je také návrh databázové struktury aplikace společně s přípravou obrazovek grafického rozhraní. Závěrem je připravena prototypová implementace navrhovaného řešení.

Annotation Thesis describes the design and analysis of data generators for testing database applications used to prepare the SQL output. It is possible to import an existing database in order to test logical links. The thesis proposal is a database application architecture, together with the preparation of graphical interface screens. Finally, a prototype is ready to implement the proposed solution.


Obsah Úvod..........................................................................................................................................7 1 Specifikace zadání.................................................................................................................9 2 Existující řešení...................................................................................................................11 2.1 DTM Data Generator......................................................................................................11 2.2 GenerateData.com..........................................................................................................13 2.3 Srovnávací tabulka.........................................................................................................16 3 Analýza a návrh...................................................................................................................17 3.1 Analýza...........................................................................................................................17 3.1.1 Požadavky................................................................................................................18 3.1.1.1 Funkční požadavky...........................................................................................18 3.1.1.1.1 Uživatel......................................................................................................18 3.1.1.1.2 Administrátor.............................................................................................21 3.1.1.1.3 Systém........................................................................................................24 3.1.1.2 Nefunkční požadavky.......................................................................................25 3.1.2 Případy užití.............................................................................................................26 3.1.2.1 Uživatel.............................................................................................................27 3.1.2.2 Administrátor....................................................................................................30 3.1.3 Diagram aktivit........................................................................................................31 3.1.3.1 Správa kompletního schématu..........................................................................31 3.1.3.2 Uložit schéma...................................................................................................35 3.1.4 Diagram tříd.............................................................................................................37 3.1.4.1 Třída User.........................................................................................................37 3.1.4.2 Třída Folder......................................................................................................39 3.1.4.3 Třída Config......................................................................................................40 3.1.4.4 Třída Revision...................................................................................................41 3.1.4.5 Třída Table........................................................................................................42 3.1.5 Sekvenční diagram..................................................................................................43 3.2 Návrh..............................................................................................................................44 3.2.1 Databázová vrstva...................................................................................................45 3.2.2 Business vrstva........................................................................................................52 3.2.2.1 Uložení schématu..............................................................................................52 3.2.2.2 Lokalizace databázových slovníků...................................................................54 3.2.2.3 Správa jazykových mutací aplikace..................................................................54 3.2.3 Prezentační vrstva....................................................................................................55 3.2.3.1 Náhledy obrazovek...........................................................................................56 –5–


3.2.3.1.1 Hlavní obrazovka.......................................................................................56 3.2.3.1.2 Nastavení tabulky.......................................................................................57 3.2.3.1.3 Nápověda...................................................................................................58 3.2.3.1.4 Více tabulek...............................................................................................59 3.2.3.1.5 Náhled výstupu..........................................................................................60 3.2.3.2 Grafický design.................................................................................................60 3.2.3.2.1 Obrázky a ilustrace....................................................................................60 3.2.3.2.2 Rozlišení obrazovky a šířka stránky..........................................................62 4 Prototypová implementace.................................................................................................65 4.1 Realizace prototypu........................................................................................................65 4.2 Systémové požadavky prototypu...................................................................................66 4.3 Postup instalace..............................................................................................................67 4.4 Ukázka výstupu..............................................................................................................68 5 Zhodnocení realizace..........................................................................................................70 Závěr......................................................................................................................................71 Slovník pojmů........................................................................................................................73 Seznam literatury..................................................................................................................74 Seznam obrázků....................................................................................................................75 Seznam diagramů..................................................................................................................76 Seznam tabulek.....................................................................................................................77 Seznam příloh........................................................................................................................78

–6–


Úvod

Úvod Databáze – slovo tak abstraktní, že si pod jeho významem dokáže kdokoliv představit cokoliv. Databázová aplikace však abstrakci rozšiřuje na velmi konkrétní pojem definující aplikace, nebo chceme-li software, využívající k ukládání dat a informací databázový stroj pracující s uspořádanou množinou dat, uložených v logických celcích – tabulky, sloupce a řádky. Právě přípravě databáze pro aplikace je v dnešním IT odvětví věnováno velké úsilí při jejím návrhu, realizaci a testování. Pokud je schéma navrhované databáze velmi rozsáhlé a pomocí vazeb na úrovni sloupců jednotlivých tabulek provázané, stává se poměrně těžko otestovatelnou z pohledu zachování integrity dat. Databázoví vývojáři tak plní tabulky náhodně vygenerovanými daty, které jen vzdáleně korespondují s tím, jaká data budou aplikací fyzicky využívána. Osobně jsem se problémem plnění dat do databáze několikrát zabýval. Z důvodu zefektivnění vývoje a částečně i z ryzí pohodlnosti jsem porovnával dostupný software, který by dokázal tato testovací data připravit. Po velmi dlouhém srovnávání jsem dospěl k názoru, že bude efektivnější si takto specifickou aplikaci připravit sám. Žádná totiž nesplňovala dokonale mé požadavky a výsledná testovací data bych ještě musel ručně dodatečně upravovat. Mnou navrhované řešení pokrývající nedostatky konkurenčních aplikací je předmětem diplomové práce s názvem Generátor dat pro testování databázových aplikací (dále již jen GDPTDA). Ačkoliv se téma může zdát jako velmi těžce srozumitelné spojení odborných výrazů, ve svém obsahu skrývá analýzu, návrh a prototypovou implementaci generátoru dat. Práce je tak rozdělena do několika celků, z nichž se každý věnuje určité části při vývoji této aplikace. V první fázi bylo velmi důležité zjistit jak obsáhle a detailně dokáže konkurenční software databázová data generovat pro následné použití. Ze zjištěných nedostatků byly nastaveny konkurenční výhody popsané v analýze požadavků na výsledný produkt. Na základě těchto cenných informací byly definovány uživatelské role a jejich možnosti při práci s generátorem databázových dat. –7–


Úvod

Při návrhu aplikace byla velká pozornost věnována na databázové schéma jež bude stěžejní kostrou celého generátoru dat. Na databázi tak navazuje business vrstva zpracovávající databázová data a následné požadavky uživatelů. To, co je v poslední fázi zpracování požadavku zobrazeno uživateli je takzvaný frontend. Ten je spolu s použitými technologiemi a doporučeními na jeho realizaci popsán v poslední části kapitoly s návrhem aplikace. Důkazem, že zanalyzované požadavky a návrh realizace aplikace jsou dostatečně zdokumentovány, byl na jejich základě vytvořen jednoduchý avšak funkční prototyp, jehož jednotlivé kroky vývoje jsou spolu s uživatelskou příručkou a návodem na instalaci popsány závěrem této práce Každého při čtení této práce jistě napadne velké množství detailů a prvků, které by dokázaly vylepšit GDPTDA ještě o něco více. Je tak potřeba říci, že při návrhu jsem na mnohé z nich narazil, avšak nezařadil jsem je do seznamu požadavků na aplikaci z důvodu jejich rozsáhlosti a náročnosti.

–8–


Specifikace zadání

1 Specifikace zadání Generátor dat pro testování databázových aplikací bude sloužit pro zjednodušení a ulehčení vývoje aplikací, jejichž nosná data jsou uložena v databázových systémech. GDPTDA bude podporovat práci s databázovými systémy MySQL, Oracle, PostgreSQL, MSSQL, Firebird a SQLite. GDPTDA bude realizován jako webová aplikace pracující na straně serveru, kde bude docházet k příjmu, validaci, zpracování a následnému odeslání požadavku klientovi. Zobrazení zpracovaného požadavku klienta bude probíhat ve webovém prohlížeči uživatele. Systém nabídne uživateli v grafickém rozhraní aplikace možnost vytvořit si vazbu databázových objektů a na základě datového typu nabídne číselníky s rozšířeným výběrem číselných dat, či slovníkových záznamů. Databázové slovníky budou tvořit místopisné pojmy, vlastní jména a příjmení jak v originálním znění, tak následně lokalizované do dalších jazykových mutací. Generátor číselných dat bude umožňovat zpracování triviálních matematických a statistických operací typu MIN, MAX, AVERAGE či RANDOM.

Následujících body představují 8 kroků k úspěšnému vygenerování výstupu: 1. Registrace uživatele 2. Přihlášení uživatele 3. Příprava databáze a) Import SQL syntaxe (CREATE TABLE) b) Ruční sestavení pro jednotlivé tabulky/sloupce 4. Definice číselníků/generátorů 5. Náhled na předvolená data 6. Volba výstupu SQL/ZIP/GZIP/XML 7. Vygenerování výstupu 8. Uložení schématu/stažení schématu v XML Uživatelé aplikace budou mít možnost si své připravené schéma uložit a v případě pozdějšího použití jej znovu otevřít a navázat na předchozí činnost. Při tvorbě schématu a nastavování datových typů sloupců tabulek bude povolena možnost automatického ukládání s verzováním –9–


Specifikace zadání

tak, aby v případě několika kroků, které vedly špatným směrem, bylo možné schéma obnovit zpět do funkční podoby. Projekt bude primárně cílit na database developery, ať už na úrovni junior nebo senior, ale také na drobné vývojáře webových či desktopových aplikací, kteří potřebují svůj software otestovat na datech co možná nejpodobnějších reálnému použití aplikace. V rámci konceptu této práce bude vytvářena bezplatná (free) varianta. Placená varianta aplikace by přinesla nové podmínky a funkcionality, jejichž popis by překročil plánovaný rámec rozsahu diplomové práce.

– 10 –


Existující řešení

2 Existující řešení Při vyhledávání podobné software na základě zadání projektu GDPTDA byly vyhodnoceny jako konkurenceschopné následující 2 aplikace. Jednou z nich je standalone software – DTM Data Generator, a druhá je web-base – GenerateData.com. Není od věci podotknout, že aplikací, které dokáží připravit data pro potřeby testování databázových aplikací je mnohem více než dva adepti z výběru výše. Avšak jejich funkcionality přesahují rozsah, který bude pokrývat GDPDA. Je tak potřeba zmínit aplikaci Datanamic Data Generator MultiDB od společnosti Datanamic pracující výhradně s již vytvořenými databázemi, a GS DataGenerator od Global Software Applications umožňující připravit generovaná data nejen pro databáze.

2.1 DTM Data Generator Aplikace DTM Data Generator pochází od společnosti DTM soft z amerického Seattlu. Software se primárně zaměřuje na komplexní přípravu a generování dat pro testování databázových aplikací. Velkou devizou je možnost připravit a propojit data z jednotlivých tabulek pomocí primárních a cizích klíčů nad jednotlivými sloupci v tabulkách. To umožňuje efektivní tvorbu rozsáhlých schémat a dochází tak k úspoře času při přípravě výstupních dat. Jednou z přidaných hodnot aplikace je také schéma analyzér, s jehož pomocí dokáže uživatel velmi intuitivně propojovat zdánlivě nespojitelné tabulky a vytvořit mezi nimi logické vazby. Tato funkcionalita je ocenitelná při generování hierarchicky rozsáhlých schémat, kde dochází k přebírání dat z jedné tabulky do druhé, v praxi označované jako databázové číselníky. Samozřejmostí je u DTM Data Generator náhled výstupu před jeho samotným vygenerováním a aplikováním nad již stávajícím databázovým schématem. Proces sestavení generovaných dat je možné zkontrolovat v reportech, kde jsou mimo jiné uvedeny informace o počtu záznamů, době generování nebo způsobu jakým byly jednotlivé tabulky a sloupce naplněny. Souhrn základních skupin slovníků, které lze využít pro plnění výstupu: – 11 –


•


General (obecné)

•

Names (jména)

◦ Měsíce

◦ Příjmení

◦ Barvy

◦ Křestní jméno (ženské)

◦ Business (byznys)

◦ Křestní jméno (mužské)

◦ Průmysl

◦ Celé jméno (jméno/příjmení)

◦ Oddělení ◦ Společnosti

Geographic Data (geografické umístění)

◦ Činnost

◦ Země

•

◦ Město ◦ Region ◦ Ulice Jako další vstupní data pro jednotlivé sloupce lze použít číselné či textové generátory.

Obrázek 1: Nastavení výstupu z aplikace DTM Data Generator – 12 –



Proces přípravy testovacích dat je podpořen pomocí intuitivního průvodce (wizard). Ve čtyřech krocích lze strukturu databáze vytvořit ručně, nebo využít připojení na již fungující databázi. K většině databází, vyjma MSSQL, je zapotřebí stáhnout a doinstalovat potřebný ODBC driver (tyto ovladače je možné získat na oficiálních webových stránkách vývojářů databázového systému). Klady

Zápory

Rozsáhlé databázové slovníky

Není národní lokalizace

Schéma designer

Nedostatečná dokumentace

Napojení na stávající databázi Tabulka 1: Klady a zápory aplikace DTM Data Generator

Verze

Enterprise 1.3.17

Licence

EULA1

Cena (USD)

349

Výrobce

DTM soft

Webová adresa

http://www.sqledit.com/dg/

Podporované databáze

Interbase, Firebird, DB2, MS SQL, MySQL, Oracle, PostgreSQL, Sybase

Formát výstupu

XLS, XML, CSV, SQL

Požadavky

Microsoft Windows 2000, XP, 2003/2008 Server, Vista, Windows 7 Tabulka 2: Obecné vlastnosti aplikace DTM Data Generator

2.2 GenerateData.com GenerateData.com je web-base aplikace, jejíž koncept je do určité míry shodný s GDPTDS. Jedná se svobodný software distribuovaný pod GNU-GPL 2 licencí od Benjamina Keena. Jedná se o jedinou aplikaci, která v on-line prostředí dokáže vygenerovat data pro základní testování databázových aplikací. Aplikace ve svém rozhraní umožňuje nadefinovat pouze jednu tabulku s neomezeně sloupci. Data jednotlivých řádků je možné plnit z následujících 3 skupin: Human Data, Text a Custom. 1 EULA (End-User-License-Agreement) je licence pro koncového uživatele softwaru určující, co uživatel smí a nesmí dělat.[1] 2 GNU General Public License, GNU GPL (česky „všeobecná veřejná licence GNU“) je licence pro svobodný software.[2]

– 13 –


•


Human data (lidská data)

•

Text

◦ Jméno/příjmení

◦ Pevný počet slov

◦ Telefon/Fax

◦ Náhodný počet slov

◦ Email

•

Custom (vlastní)

◦ Poštovní adresa

◦ Auto-increment

◦ Město

◦ Rozsah čísel

◦ PSČ

◦ Alfa-numerická data

◦ Stát/provincie/region

◦ Vlastní

◦ Země ◦ Datum Takzvaná „lidská data” jsou vázána k vybrané zeměpisné lokalitě: Kanada, Nizozemsko, Velká Británie a Spojené Státy Americké. Tato volba velmi ovlivňuje celkový výstup, jelikož každá země má vlastní specifika pro zobrazení data či času, spravuje jinou databázi vlastních jmen, zápis zeměpisných informací je v jiném formátu a mnoho dalších národnostních detailů.

Obrázek 2: Nastavení výstupu z aplikace GenerateData.com

– 14 –



Výstup z aplikace je možné uložit do SQL ale také pro snadnější úpravu do CSV nebo XLS. Opomenut není ani formát HTML a XML. Při generování výstupu je možné zvolit databázový systém, pro který je výstup určen. V tomto případě MySQL a Oracle. Každý z těchto systémů má možnost volby vygenerovat jak CREATE TABLE příkaz, či jen INSERT INTO sekvenci pro testovací data. V případě systému MySQL je zde navíc volba pro uzavření názvů tabulky a polí do jednoduchých uvozovek – takzvané escapování textových řetězců. Maximální počet řádků výstupu je omezen na 5 000. Klady

Zápory

Možnost instalace na vlastním prostředí

Není národní lokalizace

Častý update

Malá podpora databázových systémů

Zdarma

Chybí logické vazby mezi tabulkami

Dostupný on-line

Maximálně 5000 řádků výstupu Žádná dokumentace Tabulka 3: Klady a zápory aplikace GenerateData.com

Verze

2.3.2009

Licence

GNU-GPL

Cena (USD)

zdarma

Výrobce

Benjamin Keen

Webová adresa

http://www.generatedata.com

Podporované databáze

MySQL, Oracle

Formát výstupu

HTML, XLS, XML, CSV, SQL

Požadavky

webový prohlížeč se zapnutým JavaScriptem, MySQL 4+, PHP 4+ (pro webový přístup není podmínkou) Tabulka 4: Obecné vlastnosti aplikace GenerateData.com

– 15 –



2.3 Srovnávací tabulka Licence Cena (USD) Výrobce

DTM Data Generator

GenerateData.com

EULA

GNU–GPL

349

zdarma

DTM Soft

Benjamin Keen

Databázové systémy Firebird

ANO

NE

Interbase

ANO

NE

MS Access

NE

NE

MS SQL Server

ANO

NE

MySQL

ANO

ANO

Oracle

ANO

ANO

PostgreSQL

ANO

NE

DB2

ANO

NE

Sybase

ANO

NE

Formát výstupu HTML

NE

ANO

XML

ANO

ANO

SQL

ANO

ANO

CSV

ANO

ANO

XLS

ANO

ANO

TXT

ANO

NE

Vlastnosti aplikace Maximální délka výstupu (řádků)

4 200 000

5 000

Validace schématu

ANO

NE

Vložení hotového schématu

ANO

NE

Schema designer

ANO

NE

Tabulka 5: Detailní srovnání vlastností aplikací DTM Data Generator a GenerateData.com

– 16 –


Analýza a návrh

3 Analýza a návrh Obě kapitoly budou úzce provázány s case nástrojem Enterprise Architect. Enterprise Architect (EA) od společnosti Sparx Systems je kompletní nástroj pro systémovou analýzu a návrh, který pokrývá celý životní cyklus vývoje systému, tzn. od zadání požadavků přes analýzu stavů, návrh modelů, testování a údržbu, vše s využitím diagramů v UML. EA poskytuje podporu pro týmový vývoj a pro jednotlivé role (analytik, tester, projektový manažer, kontrola kvality, vývojový tým).[3] Pro část analýzy tak EA poskytne své možnosti pro modelování požadavků či diagramu tříd, zatím co v kapitole zabývající se návrhem bude nástroj využit k realizaci databázových schémat s kompletním DDL (Data Definition Language) výstupem.

3.1 Analýza Cílem kapitoly je provést analýzu řešení pro GDPTDA. Ta pomůže s definováním slabých či kritických míst a umožní tak včas eliminovat chyby v návrhu a implementaci. V rámci analýzy budou využity následující diagramy: •

Případy užití (uživatel, administrátor)

•

Diagram aktivit

•

Diagram tříd

•

Sekvenční diagram

Tyto grafické diagramy vychází z jazyka UML[4], který lze definovat následujícími slovy: UML, Unified Modeling Language je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy. – 17 –


Analýza a návrh

Standard UML definuje standardizační skupina Object Management Group (OMG).[5]

3.1.1 Požadavky Primárním předpokladem pro analýzu realizované aplikace je správa požadavků, při které je vyžadována velmi úzká spolupráce mezi zadavatelem a realizátorem aplikace. Požadavky dělíme do dvou tématických skupin na funkční a nefunkční. Za funkční požadavky je možné označit vše, co může uživatel, systém nebo sama aplikace vykonávat – popisují požadované funkce systému (například jakým způsobem bude probíhat registrace uživatele do systému). Protikladem funkčních požadavků jsou požadavky nefunkční. Jedná se o popsané omezující podmínky na systém (například maximální počet tabulek v databázi). Vzhledem k množství získaných, popsaných a definovaných požadavků je bylo potřeba logicky rozdělit do skupin, a přiřadit jim unikátní identifikátor. Ten slouží pro snazší odkazování v rámci dalších modelů, diagramů a doplňujících textů. Identifikátor použitý v následujících požadavcích má následující logiku: [první písmeno role – A/U/S]_[první písmeno typu požadavku – f/n]_[číslo požadavku – 1–N]

3.1.1.1 Funkční požadavky 3.1.1.1.1 Uživatel •

U_fREQ_1: Registrování nového uživatele: Uživatel provede registraci do aplikace, při vyplňování registračního formuláře musí povinně uvést přihlašovací jméno (login), heslo, heslo pro ověření shody a emailovou adresu. Při požadavku registrace bude prováděna kontrola na dostupnost volného přihlašovacího jména, shoda hesel a zda–li již emailová adresa pro registraci nebyla využita. V případě splnění všech 3 hlavních podmínek dojde k úspěšné registraci. V opačném případě bude uživatel vyzván k úpravě již vyplněných vstupních dat.

•

U_fREQ_2: Přihlášení zaregistrovaného uživatele: Pro přihlášení uživatele bude vyžadováno přihlašovací jméno a heslo. Následně dojde k porovnání s hodnotami uloženými v databázi. Po úspěšném přihlášení dojde k přesměrování na hlavní stránku aplikace. – 18 –


•

Analýza a návrh

U_fREQ_3: Editování stávajícího uživatelského účtu: Zaregistrovaný uživatel bude mít možnost upravit svá uživatelská data (jméno, příjmení) ale také provést změnu hesla nebo emailové adresy.

•

U_fREQ_3: Odhlášení uživatele: Pro bezpečné opuštění aplikace bude mít uživatel možnost se odhlásit. Po odhlášení se zobrazí úvodní stránka aplikace.

•

U_fREQ_4: Správa složek: Každý uživatel má možnost vytvářet a spravovat své složky a vytvářet tak jejich stromovou strukturu. Složky budou sloužit pro snadnější orientaci a organizaci mezi schématy. ◦ U_fREQ_4.1: Vytvoření složky: Vytvoření složek bude neomezené. Musí být ovšem zachována stromová struktura, která jednoznačně identifikuje nadřazenou složku. ◦ U_fREQ_4.2: Editování složky: Editace složky umožní přejmenování názvu složky. ◦ U_fREQ_4.3: Smazání složky: Po smazání složky, která není prázdná, dojde k přesunutí dat do nejvýše umístěné složky uživatele (do /root).

•

U_fREQ_5: Správa databázových schémat ◦ U_fREQ_5.1: Vytvoření schématu ▪ U_fREQ_5.1.1: Importování hotového schématu z SQL formátu: Schéma bude možné vytvořit na základě importu připraveného SQL souboru, který bude obsahovat všechny důležité parametry pro sestavení modelu databáze (minimálně CREATE TABLE). ▪ U_fREQ_5.1.2: Ruční vytvoření schématu: Vytvoření schématu bude možná na základě ruční definice jednotlivých tabulek, sloupců a vazeb mezi nimi. ◦ U_fREQ_5.2: Uložení schématu: Aktuální verzi schématu bude možné uložit ručně kliknutím na ikonu ULOŽIT. Pro uložení schématu databáze bude využíváno XML, který přesně definuje jednotlivé prvky celého schématu a při následném

otevření dokumentu jej bude schopen snadno sestavit do funkční podoby. – 19 –


Analýza a návrh

◦ U_fREQ_5.3: Editování schématu: Schéma bude možné opětovně otevřít, upravovat a následně uložit. ◦ U_fREQ_5.4: Smazání schématu: Při smazání schématu dojde k vymazání všech revizí. ◦ U_fREQ_5.5: Verzování schématu ▪ U_fREQ_5.5.1: Automatické ukládání při verzování: K automatickému ukládání bude docházet automaticky v časovém intervalu 5 minut nebo při více jak pěti změnách během 1 minuty. Vyžaduje zapnutí cookies ve webovém prohlížeči. ▪ U_fREQ_5.5.2: Obnovení ze starší verze: V případě špatného směru úprav schématu bude možné obnovit starší verzi. •

U_fREQ_6: Zobrazování nápovědy v aplikaci: Při postupném procházení aplikace bude uživatele doprovázet možnost zobrazení nápovědy. Nápovědu bude představovat ikona „otazníku”.

•

U_fREQ_7: Zobrazení náhledu výstupu: V průběhu přípravy vstupních dat a nastavování slovníků pro generování bude mít uživatel možnost si zobrazit náhled výstupu ještě dříve, než dojde k samotnému a komplexnímu generování celého schématu. Tento výstup bude omezen na 10 řádků pro tabulku.

•

U_fREQ_8: Zvolení výstupního formátu souboru a vygenerování výstupu: Po definici dat potřebných pro výstup bude uživatel vyzván, aby zvolil formát souboru, do kterého chce výstup uložit. Následně začne probíhat generování výstupu.

•

U_fREQ_9: Stažení výstupního souboru a uložení schématu do revize: Po vygenerování výstupu bude uživatel vyzván, aby si připravený soubor uložit do svého počítače. Po jeho úspěšném stažení se uloží záznam do databáze informující o definitivním sestavení schématu a bude označen jako „stable”.

– 20 –


Analýza a návrh

Diagram 1: Vazby funkčních požadavků pro uživatele

3.1.1.1.2 Administrátor •

A_fREQ_1: Správa uživatelů: Administrátor bude mít možnost spravovat uživatele. ◦ A_fREQ_1.1: Editování uživatele: Administrátor bude moci upravit uživatelská data, změnit heslo nebo emailovou adresu. ◦ A_fREQ_1.2: Nastavení oprávnění uživatele: Bude možné definovat typ uživatele na základě jeho oprávnění: registrovaný uživatel nebo administrátor. ◦ A_fREQ_1.3: Smazání uživatele: Smazání uživatele dojde ke kompletnímu odstranění účtu uživatele včetně schémat, složek a revizí. Tato akce je nevratná. – 21 –


Analýza a návrh

◦ A_fREQ_1.4: Zobrazení seznam uživatelů: Pro snadnější přehled o uživatelích bude k dispozici seznam s jejich základními informacemi. •

A_fREQ_2: Správa složek: Administrátor bude mít možnost spravovat složky uživatele(ů) ◦ A_fREQ_2.1: Editování složky uživatele: Při editaci bude možné změnit název složky a nadřazenou složku. ◦ A_fREQ_2.2: Smazání složky uživatele ◦ A_fREQ_2.3: Zobrazení seznamu složek uživatele

•

A_fREQ_3: Zobrazení statistiky výstupů: Administrátor bude mít možnost v administračním rozhraní aplikace zobrazit množství a časové intervaly o procesu generování dat.

•

A_fREQ_4: Správa databázových slovníků: Administrátor bude mít možnost spravovat databázové slovníky, ty budou vázány na datové typy. ◦ A_fREQ_4.1: Vytvoření nového záznamu slovníku ◦ A_fREQ_4.2: Editování záznamu slovníku ◦ A_fREQ_4.3: Smazání záznamu slovníku ◦ A_fREQ_4.4: Zobrazení seznamu záznamů slovníků

•

A_fREQ_5: Správa datových typů: Datové typy budou představovat logické prvky pro vazbu slovníků. ◦ A_fREQ_5.1: Vytvoření datového typu ◦ A_fREQ_5.2: Editování datového typu ◦ A_fREQ_5.3: Smazání datového typu ◦ A_fREQ_5.4: Zobrazení seznamu datových typů

– 22 –


•

Analýza a návrh

A_fREQ_6: Správa nápovědy aplikace: Pro plně funkční a lokalizovanou nápovědu bude připraveno rozhraní, ve kterém administrátor bude moci upravovat popisky k jednotlivým funkcionalitám aplikace. ◦ A_fREQ_6.1: Vytvoření nápovědy ◦ A_fREQ_6.2: Editování nápovědy ◦ A_fREQ_6.3: Smazání nápovědy ◦ A_fREQ_6.4: Zobrazení seznamu nápověd

•

A_fREQ_7: Správa jazykových mutací aplikace: Překlad aplikace GDPTDA bude zajištěn přes jazykové soubory v PHP. ◦ A_fREQ_7.1: Vytvoření jazykové mutace ◦ A_fREQ_7.2: Editování jazykové mutace ◦ A_fREQ_7.3: Smazání jazykové mutace ◦ A_fREQ_7.4: Zobrazení seznamu jazykových mutací: Seznam bude odkazovat na lokalizovaný soubor daného jazyka. Souborů bude více, z nichž každý bude představovat souhrnnou část aplikace sloužící pro jednodušší překlad a editaci.

•

A_fREQ_8: Správa statických textů: Administrátorovi bude umožněno vkládat na webové stránky aplikace krátké příspěvky o změnách či novinkách. ◦ A_fREQ_8.1: Vytvoření nového statického textu ◦ A_fREQ_8.2: Editování statického textu ◦ A_fREQ_8.3: Smazání statického textu ◦ A_fREQ_8.4: Zobrazení seznamu statických textů

– 23 –


Analýza a návrh

Diagram 2: Vazby funkčních požadavků pro administrátora

3.1.1.1.3 Systém •

S_fREQ_1: Generování pouze jednoho výstupu: Proces generování výstupu je poměrně složitý a tak bude využívána fronta pro další požadavky na generování. Tímto krokem dojde ke snížení nároků na výpočetní výkon hardwarové konfigurace serveru.

– 24 –


•

Analýza a návrh

S_fREQ_2: Omezení počtu tabulek databáze: Jedno databázové schéma bude obsahovat maximálně 50 tabulek.

•

S_fREQ_3: Omezení počtu řádků vygenerovaných do tabulky: Jedna databázová tabulka bude obsahovat maximálně 3 000 řádků. Maximálně 150 000 řádků ve výstupu.

•

S_fREQ_4: Omezení počtu sloupců v tabulce: Jedna databázová tabulka bude obsahovat maximálně 20 sloupců. Maximálně 1 000 sloupců ve výstupu.

•

S_fREQ_5: Omezení počtu revizí schématu: Jedno databázové schéma bude mít uloženo maximálně 50 revizí.

•

S_fREQ_6: Validování vstupních hodnot: Validace hodnot bude probíhat na základě zvoleného datového typu.

•

S_fREQ_7: Lokalizování databázových slovníků: Geografické slovníky budou dodatečně lokalizovány přes jazykové soubory v PHP.

Funkční požadavky na systém byly vloženy do diagramu (číslo diagramů)

3.1.1.2 Nefunkční požadavky •

nREQ_1: Kompatibilita s webovými prohlížeči: Aplikace poběží ve webovém rozhraní – zaručena tam musí být kompatibilita prohlížečů Internet Explorer 7, 8, 9; Mozilla Firefox 3, 4; Opera 10; Google Chrome.

•

nREQ_2: Plnění standardů W3C: Výstup stránek bude plně validní XHML kód doplněn o validní CSS.

•

nREQ_3: Databázová logika v MySQL: Data aplikace budou uložena v databázovém systému MySQL verze 5.

•

nREQ_4: Business vrstva v PHP: Aplikace bude naprogramována v jazyce PHP z důvodu maximální kompatibility pro nasazení na většině dostupných webhostingových programech.

– 25 –


•

Analýza a návrh

nREQ_5: Záložkový grafický layout aplikace: GDPTDA bude využívat záložkového designu – záložkový design lze popsat jako využití záložek (tabů) z webových prohlížečů.

•

nREQ_6: Omezení na základní 4 barvy aplikace: Pro snadnější orientaci a vnímání aplikace uživatelem bude využito celkem 4 barev: modrá, šedá, bílá a černá. Barva modrá, šedá a bílá budou sloužit jako dominantní barvy grafického layoutu zatímco černá bude výhradně pro textové prvky.

•

nREQ_7: Použití grafických informačních ikon: V aplikaci bude každý funkční odkaz nebo tlačítko doprovázeno unikátní grafickou ikonou informující o charakteru funkce.

•

nREQ_8: Maximální doba sestavení stránky: Maximální doba sestavení stránky v debug (ladícím) režimu bude 1s. Tento čas představuje jak příprava dat na úrovni databázové vrstvy, business vrstvy a prezentační vrstvy.

3.1.2 Případy užití Use casy jsou jednoduché nástroje na popsání chování softwaru nebo systému. Obsahují textový popis všech možných způsobů, jak uživatel může pracovat se softwarem nebo systémem. Nepopisují žádné interní procesy systému, nebo jak bude systém implementován. Jednoduše ukazují kroky jak má uživatel provést úkol/aktivitu. Všechny způsoby, kterými uživatelé komunikují se systémem, lze popsat tímto způsobem.[6]

– 26 –


Analýza a návrh

3.1.2.1 Uživatel

Diagram 3: Případ užití – Registrovat uživatele

Případ užití: Registrovat uživatele ID: 1 Stručný popis: Uživatel provede registraci do aplikace, při vyplňování registračního formuláře musí povinně uvést přihlašovací jméno (login), heslo, heslo pro ověření shody a emailovou adresu. Hlavní aktéři: Uživatel Vedlejší aktéři: Žádní Vstupní podmínky: Uživatel se nachází na hlavní obrazovce aplikace a není registrován v aplikaci. Hlavní scénář: 1. Uživatel přejde na registrační formulář. 2. Vyplní požadovaná registrační data: přihlašovací jméno, heslo, ověření hesla a emailovou adresu. 3. Jsou-li registrační data v pořádku, pak a) Proběhne registrace Uživatele. 4. Nebo: a) Uživatel bude vyzván k úpravě již vyplněných vstupních dat. Výstupní podmínky: Uživatel byl úspěšně zaregistrován. Alternativní scénář: Žádný. Tabulka 6: Popis případu užití – Registrovat uživatele – 27 –


Analýza a návrh

Diagram 4: Případ užití – Generovat výstup

– 28 –


Analýza a návrh

Případ užití: Generovat výstup ID: 15 Stručný popis: Uživatel chce vygenerovat výstupní soubor z připraveného schématu. Hlavní aktéři: Uživatel Vedlejší aktéři: Žádní Vstupní podmínky: Uživatel má připraveny data pro výstup ze schématu. Hlavní scénář: 1. Uživatel Zvolí formát výstupu (ID: 16). 2. Po vygenerování bude Uživateli nabídnuta možnost Stahovat výstupní soubor (ID: 17). Výstupní podmínky: Stažení výstupního souboru bylo úspěšné. Alternativní scénář: Žádný. Tabulka 7: Popis případu užití – Generovat výstup

– 29 –


Analýza a návrh

3.1.2.2 Administrátor

Diagram 5: Případ užití – Spravovat uživatele

– 30 –


Analýza a návrh

Případ užití: Spravovat uživatele ID: 26 Stručný popis: Administrátor chce změnit heslo Uživatele pro přístup do systému. Hlavní aktéři: Administrátor Vedlejší aktéři: Žádní Vstupní podmínky: Administrátor se nachází na obrazovce editace vybraného uživatele. Hlavní scénář: 1. Administrátor vyplní požadovaná pole pro změnu hesla a kontrolu hesla. 2. Je-li shoda mezi hesly, pak a) Proběhne uložení změny hesla. 3. Nebo: a) Uživatel bude vyzván k úpravě již vyplněných vstupních dat. Výstupní podmínky: Úspěšné uložení změny hesla do aplikace. Alternativní scénář: Žádný. Tabulka 8: Popis případu užití – Spravovat uživatele

3.1.3 Diagram aktivit Diagram aktivit je jedním z UML diagramů, které popisují chování. Tento diagram se používá pro modelování procedurální logiky, procesů a zachycení workflow. Každý proces v diagramu aktivit je reprezentován sekvencí jednotlivých kroků, které jsou v modelu zakresleny jako akce, (vnořené) aktivity, počáteční uzly, koncové uzly aktivit, uzly rozhodnutí, spojení uzlů.[7]

3.1.3.1 Správa kompletního schématu Pro nejnázornější popis jednotlivých aktivit aplikace byl zvolen diagram aktivit „Správa kompletního schématu”, který definuje jeho založení schématu, správu tabulek a sloupců, přes vygenerování náhledu až po stažení výstupu. Opomenuto není ani uložení schématu – bude popsáno v následující kapitole.

– 31 –


Analýza a návrh

Toto schéma je však natolik komplexní a rozsáhlé, že bez využití vnořených aktivit by byl rozsah diagramu pro možnosti této práce nepopsatelný. Jednotlivé vnořené aktivity jsou tak dostupné v příloze 1 až 6. Je možné však diagram seskupit do třech logických oddílů. Tyto oddíly lze pojmenovat na základě výstupů jedné z primárních logických podmínek „Volba akce pro schéma” jako: •

Upravit schéma

•

Vygenerovat schéma

•

Zobrazit schéma

Mezi nimi dochází k provázání akcí: •

oddíl Vygenerovat schéma + oddíl Zobrazit schéma = akce „Validovat schéma”

•

oddíl Upravit schéma + oddíl Vygenerovat schéma = vnořená aktivita „Uložit schéma” (tato aktivita je popsána v další části práce).

Těmto oddílům předchází počáteční uzel „Začátek správy kompletního schématu”. Následuje logický rozhodovací uzel „VYTVOŘIT nebo EDITOVAT schéma?”. Po jeho vyhodnocení je v případě vytvoření schématu následných krokem vnořená aktivita „Vytvořit schéma”, v opačném případě je zde akce „Vybrat stávající schéma”. Tuto akci a vnořenou aktivitu pro další workflow schématu slučuje uzel spojení. Oddíl definující úpravu schématu je definován souslednými vnořenými aktivitami „Spravovat tabulky”, “Spravovat sloupce”, „Nastavit sloupce” a sdílenou „Uložit schéma”. Mezi správou sloupců a nastavením sloupce, a také mezi nastavením sloupce a uložením schématu je možné se rozhodnou, zda pokračovat v následném kroku nebo se vrátit zpět na začátek správy tabulek. Po úspěšném uložení schématu dojde dle uzlu „Pokračovat SPRÁVOU SCHÉMATU nebo UKONČIT ÚPRAVY?” k rozhodnutí, zda-li přejít zpět na možnost uzlu „Volby akce pro schéma?” nebo ke koncovému uzlu aktivit „Konec správy kompletního schématu”. Zbylé dva logické oddíly mají do jisté míry společně vypadající průběh. Oddíl popisující vygenerování schématu obsahuje akci „Zvolit nastavení výstupu”, „Vygenerovat výstup”, sdílenou „Validovat schéma”, rozhodovacím uzlem „VYGENEROVAT NÁHLED nebo VYGENEROVAT VÝSTUP?”, vnořenou aktivitou „Uložit schéma”, důležitým rozhodovacím uzlem „ÚPRAVA SCHÉMATU nebo VYGENEROVÁNÍ VÝSTUPU?” a finální akci „Stáhnout vý-

– 32 –


Analýza a návrh

stup”. Po stažení výstupu dojde k rozhodnutí, zda pokračovat v úpravách schématu nebo ukončení správy. Třetí a zároveň poslední oddíl představuje flow akcí „Nastavit rozsah náhledu”, „Vygenerovat náhled”, sdílenou „Validovat schéma”, stejným rozhodovacím uzlem definujícím další postup k akci „Zobrazit náhled výstupu”. Po této akci je směr procesu zobrazení schématu směrován na poslední uzel popisovaný v předchozích dvou oddílech. Velmi nezbytný rozhodovací uzel se nachází po sdílené akci, validující schéma. Jedná se o logickou otázku „Je logika schématu validní?”. Pokud je na otázku zodpovězeno kladně, přejde se na rozhodnutí, jedná-li se o generování výstupu nebo náhledu. V případě, že bude odpověď záporná, provede se akce „Zobrazit informaci o selhání validace” a proces bude pokračovat úpravou schématu. Tato linie zaručí, že uživatel provede potřebné změny ve schématu tak, aby jej při opětovném pokusu získat výstup nebo náhled mohl úspěšně dokončit.

– 33 –


Analýza a návrh

Diagram 6: Diagram aktivit – Správa kompletního schématu

– 34 –


Analýza a návrh

3.1.3.2 Uložit schéma Vnořená aktivita „Uložit schéma” zobrazuje proces uložení vytvořeného schématu. Podmínkou pro vykonání jakékoliv akce v diagramu je přímý vstup z akce, na kterou dokáže logicky navázat počáteční uzel „Začátek uložení schématu”. Této podmínce vyhovuje přístup procesu z rozhodovacího uzlu „Pokračovat ULOŽENÍM SCHÉMATU nebo ZMĚNIT TABULKU” z oddílu pro správu schématu, a uzlu „VYGENEROVAT NÁHLED nebo VYGENEROVAT VÝSTUP?”, který je společný pro zbývající dva oddíly. Z požadavků na aplikaci vyplývá, že počet revizí jednoho schématu nemůže být více než 50. O tomto požadavku rozhoduje logická podmínka „Je počet revizí menší než 50?”. Lze-li vyhodnotit podmínku hodnotou „NE”, uzel rozhodnutí přesměruje proces na akci „Smazat nejstarší revizi schématu” a následně přesune zpět na rozhodovací uzel. Pokud však uzel vyhodnotí, že počet revizí je menší než 50, umožní provést akci „Uložit novou revizi schématu”. Následně po jejím uložení opět navazuje rozhodovací uzel s podmínkou „Je uložená revize schématu „stable”?“. Z poznámky k tomuto uzlu je zřejmé, že revize ve stavu stable může být uložena pouze na základě úspěšného vygenerování schématu do výstupního formátu. Revize vyhodnocená jako „ANO” bude označena jako stable. Po této akci dojde celý proces na koncový uzel „Konec uložení schématu”. Nejedná-li se však o stabilní verzi revize, uzel vyhodnocen jako „NE”, bude na koncový uzel umožněn přechod bez další akcí.

– 35 –


Analýza a návrh

Diagram 7: Diagram aktivit – Uložit schéma

– 36 –


Analýza a návrh

3.1.4 Diagram tříd Diagram tříd popisuje statickou strukturu systému, znázorňuje datové struktury a operace u objektů a souvislosti mezi objekty. Znázorňuje také datový model systému od konceptuální úrovně až po implementaci. Datové struktury zařazuje do tříd a zobrazuje vztahy těchto tříd. [8]

Diagram 8: Diagram tříd – Vytvořit tabulku

3.1.4.1 Třída User Třída User spravuje záznamy jednotlivých uživatelů zaregistrovaných do systému. Umožňuje jejich přihlášení a odhlášení z aplikace na základě jejích atributů.

– 37 –


Analýza a návrh

Obrázek 3: Třída User

Atributy •

password – atribut uchovávající přihlašovací heslo uživatele

•

userUid – unikátní identifikátor uživatele sestaven: U[country_shortcut] [0+user_id] Například: USK005689 (uživatel ze Slovenské republiky s ID 5689)

•

userConfigs – hodnota rovnající se počtu konfigurací/schémat uživatele

•

userDateFormat – formát datumu/času

•

userDst – atribut definující použití letního času

•

userEmail – registrační e-mail uživatele

•

userFolders – hodnota rovnající se počtu složek uživatele

•

userId – jednoznačný identifikátor třídy User

•

userLang – atribut obsahující definici jazykových preferencí uživatele

•

userLastIp – atribut obsahující IP adresu posledního přihlášení uživatele

•

userLastVisit – atribut obsahující datum/čas posledního přihlášení uživatele

•

username – uživatelské jméno – login

•

userRealName – skutečné jméno uživatele

•

userRegDate – atribut obsahující datum/čas registrace uživatele – 38 –


Analýza a návrh

•

userRegIp – atribut obsahující IP adresu registrace uživatele

•

userTimezone – definice geo zóny uživatele pro nastavení správného času

•

userType – identifikátor typu uživatele (administrátor/uživatel)

Metody •

add – metoda, která provede vytvoření uživatele

•

logIn – metoda přihlásí uživatele

•

logOut – metoda odhlásí uživatele

•

validatePassword – metoda kontrolující shodnost hesla při jeho změně

3.1.4.2 Třída Folder Třída Folder slouží ke správě a uchování záznamů o složkách pro ukládání schémat. S pomocí instancí třídy je možné vytvořit novou, upravit, uložit a smazat stávající, a navíc zobrazit jejich seznam.

Obrázek 4: Třída Folder

Atributy •

folderFolders – hodnota rovnající se počtu vnořených složek ve složce

•

folderConfigs – hodnota rovnající se počtu konfigurací/schémat ve složce

•

folderCreateDate – atribut obsahující datum/čas vytvoření složky

•

folderId – jednoznačný identifikátor třídy Folder

•

folderLastEdit – atribut obsahující datum/čas poslední editaci složky

– 39 –


Analýza a návrh

•

folderName – název složky

•

parentId – identifikátor nadřazené složky

•

userId – identifikátor vlastníka složky

Metody •

add – metoda, která vytvoří složku

•

delete – metoda, která smaže složku

•

save – metoda, která uloží složku

•

find – metoda, která vyhledá složku

3.1.4.3 Třída Config Třída Config slouží také ke správě a uchovávání informací o schématu/konfiguraci. Pomocí této třídy bude možné vytvářet nové schéma, upravovat, uložit či smazat stávající.

Obrázek 5: Třída Config

Atributy •

configCreateDate – atribut obsahující datum/čas vytvoření schématu

•

configId – jednoznačný identifikátor třídy Config

•

configLastEdit – atribut obsahující datum/čas poslední úpravu schématu

•

configName – název schématu

•

configNote – atribut obsahující textovou poznámku ke schématu

•

configRevisions – hodnota rovnající se počtu revizí schématu – 40 –


Analýza a návrh

•

stableRevisionsId – hodnota definující stable revizi schématu

•

userId – identifikátor vlastníka schématu

•

folderId – identifikátor složky ve které se schéma nachází

Metody •

add – metoda, která vytvoří konfiguraci/schéma

•

delete – metoda, která smaže konfiguraci/schéma

•

save – metoda, která uloží konfiguraci/schéma

•

find – metoda, která vyhledá konfiguraci/schéma

3.1.4.4 Třída Revision Třída Revision obsahuje informace o jednotlivých uložených revizích daného schématu. Pomocí instancí této třídy bude možné zobrazit seznam revizí, uložit upravenou revizi nebo získat informaci o stabilní revizi vybraného schématu.

Obrázek 6: Třída Revision

Atributy •

configId – identifikátor schématu kterému je revize přiřazena

•

dbId – atribut definující databázový systém revize

•

revisionCreateDate – atribut obsahující datum/čas vytvoření revize

•

revisionId – jednoznačný identifikátor třídy Revision

•

revisionXml – atribut obsahující XML specifikaci revize

•

revisionStable – logická hodnota definující stable revizi – 41 –


Analýza a návrh

Metody •

find – metoda, která vyhledá revizi

•

updateXml – metoda, která uloží upravené XML

•

parseXml – metoda, která rozparsuje uložené XML

•

save – metoda, která uloží revizi

•

getStableRevision – metoda, která umožní získat stabilní revizi

3.1.4.5 Třída Table Třída Table slouží k nastavení základních atributů databázových tabulek. Pomocí této třídy však bude možné nastavit auto-increment či název tabulky.

Obrázek 7: Třída Table

Atributy •

tableAI – nastavení auto-increment tabulky

•

tableName – atribut pro definici názvu tabulky

•

tableEngine – atribut definující název tabulky

Metody •

add – metoda, která vytvoří tabulku

•

delete – metoda, která smaže tabulku

•

save – metoda, která uloží tabulku

•

getCount – metoda, která zjistí počet tabulek ve schématu

•

getTables – metoda vrací pole instancí třídy Table

– 42 –


Analýza a návrh

3.1.5 Sekvenční diagram Sekvenční diagram patří do skupiny diagramů interakce. Identifikuje základní vnitřní dynamiku aplikace a potřebné metody jednotlivých tříd. Diagramy interakce popisují spolupráci skupiny objektů za účelem specifického chování. Sekvenční diagramy patří mezi nejčastěji používané diagramy interakcí. Tento typ diagramu popisuje chování objektů v rámci jednoho scénáře.[9] Sekvenční diagram představuje sousledné metody aplikované na třídy popsané v kapitole 3.1.4.

Diagram 9: Sekvenční diagram – Vytvořit tabulku

Metoda najítSložku(jméno) vyhledá instanci třídy Folder dle parametru jméno, kterou uživateli vrátí. V následujícím kroku pomocí metody najítSchéma(jméno) na třídě Config dojde k vyhledání schématu ve zvolené složce, pokud je schéma nalezeno pokračuje metoda získatStableRevizi(Config) na třídě Revision. Aktuální stable revizi tak vypíše uživa-

– 43 –


Analýza a návrh

teli. S pomocí metody najítStableRevizi(jméno) aplikovanou na třídě Revision vybere konkrétní stable revizi, kterou díky metodě rozparsovatXmlRevize(XML) převede do upravitelné formy a vytvoří pole pro následující úpravy. Metoda získatTabulky() vrátí seznam všech tabulek použitých ve stable revizi. Po jejich získání metoda přidejTabulku(jméno) na třídě Table postoupí na další volání metody zjistiPočetTabulek(revize). V případě, že je počet tabulek menší nebo roven hodnotě 49, vytvoří novou instanci. V opačném případě upozorní uživatele pomocí metody upozornitNaPřekročenýLimit(). Poté metoda smazatTabulku(jméno) provede smazá-

ní vybrané tabulky. Následující metodou uložitRevizi(jméno) na třídě Revision zavolá v rámci své logiky další metodu uložitZměnyTabulky() na třídě Table. Zde dojde vytvoření požadavku na výsledné uložení revize avšak metoda upravitXml(XML) musí rozparsovanou a upravenou revizi uložit.

3.2 Návrh GDPTDA je od základu zamýšlen jako třívrstvá aplikace postavena na následujících vrstvách: •

Databázová vrstva

•

Business vrstva

•

Prezentační vrstva

Seznam vrstev aplikace je seřazen dle důležitosti využívání celého navrženého systému. Průchod dat aplikací systému popisuje obrázek 8.

Obrázek 8: Schéma vazeb třívrstvé aplikace

Uživatel na svém koncovém zařízení (stolní počítač či notebook) zobrazí stránku aplikace. O toto zobrazení se postará prezentační vrstva jejíž cílem je sestavit stránku jak ze zdroje předávaného z business vrstvy tak využít statická data jako jsou obrázky, ikony či tlačítka. Uživatel pak stránce může využít funkčního prvku pro provedení příkazu. Příkaz, ze kterého – 44 –


Analýza a návrh

se stává požadavek, na úrovni business vrstvy provede požadovanou operaci, kterou buď vyřídí sám (validace vstupních dat) nebo předá požadavek příkazu na poslední, databázovou vrstvu. Ta následně vrátí požadovanou odpověď zpět přes business a prezentační vrstvu až dojde k její interpretaci na počítači uživatele. Všechny tři výše zmíněné aplikační vrstvy jsou podrobně popsány v následujících kapitolách.

3.2.1 Databázová vrstva Databáze aplikace je nosnou konstrukcí pro správu dat. Hierarchie databáze bude dělena do základních logických celků, které jsou definovány unikátními prefixy: usr, sys a voc. Každý další zanořený celek má vlastní a unikátní prefix. Prefixy tabulek tak slouží pro snadnější a intuitivnější manipulaci s daty na úrovni business vrstvy.[10] Sestavení prefixů je následující: [primární úroveň]_[sekundární úroveň]_[název tabulky]

Příkladem skladby prefixu může být tabulka nesoucí informace o uživatelích: usr_use_user

Následující stromová struktura detailně popisuje jednotlivé tabulky databáze včetně jejich logických vazeb na další objekty v databázi. •

usr – uživatelské informace (users)

◦ use – definice uživatele (user) ▪ user_types – typ uživatele – role uživatele (administrátor, uživatel) ▪ users – informace o uživatelích (vazba na tabulky: sys_langs + user_types) – tabulka users je základním stavebním prvkem pro definici uživatele, jeho přístupu do aplikace a také jako mateřská tabulka pro další vazby •

cnf – konfigurace (configuration)

◦ configs – nastavení revize (vazba na tabulky: revisions + folders + usr_use_users) – slouží pro uložení stabilní revize ◦ folders – uživatelská složka (vazba na tabulky: usr_use_users + folders) – složky vytvářejí hierarchii pro ukládání jednotlivých revizí či dalších vnořených složek

– 45 –


Analýza a návrh

◦ revisions – revize (vazba na tabulku: sys_dbs) – obsahuje data pro jednotlivé revize (automatická záloha)

Diagram 10: Databázové tabulky use_usr

•

sys – systémové nastavení (system)

◦ dbs – databázový systém (database) – tabulka definující podporované typy databází v rámci využití GDPTDA ◦ langs – definice jazykové mutace – nastavení jazykové mutace uživatele ◦ txt – textové informace pro aplikaci ▪ help – nápověda – definice prvku, u kterého je nápovědný text zobrazen ▪ helps_values – hodnoty nápovědy (vazba na tabulky: help a langs) – definice jazykové mutace a text pro nápovědu – 46 –


Analýza a návrh

▪ news – novinky (vazba na tabulku: usr_use_users) – obsahuje informace a novinky uveřejněné na hlavní stránce aplikace

Diagram 11: Databázové tabulky sys_txt

◦ sta – statistky generování dat (statistics)

– 47 –


Analýza a návrh

Diagram 12: Databázová tabulka sys_sta

•

voc – slovníky (vocabuleries)

◦ bra – značky (brands) ▪ brands – značka (vazba na tabulky: voc_geo_countries + industries) – obsahuje názvy společností a firem ▪ industries – průmysl – odvětví průmyslu

– 48 –


Analýza a návrh

Diagram 13: Databázové tabulky voc_bra

◦ geo – geografické informace (geography) ▪ continents – kontinenty ▪ countries – země (vazba na tabulky: continents + predials) ▪ countries_unions – slučovací tabulka (unions + countries) ▪ currencies – měny (vazba na tabulku: countries) – 49 –


Analýza a návrh

▪ districts – městské části (vazba na tabulky: zipcodes + towns) ▪ predials – telefonní předvolby ▪ regions – regiony/kraje (vazba na tabulky: countries + predials) ▪ towns – města (vazba na tabulky: regions + countries + predials + zipcodes) ▪ streets – ulice (vazba na tabulku: countries) ▪ unions – společenství států/účastníků – EU, OSN, NATO, G8, WHO, FIFA, FIA, IIHF, IAAF, ... ▪ zipcodes – poštovní směrovací čísla

Diagram 14: Databázové tabulky voc_geo

◦ nam – jmenné názvy (names) ▪ genders – pohlaví – mužské, ženské, unisex ▪ middle_names – prostřední jména (vazba na tabulky: voc_geo_countries + genders) ▪ surnames – příjmení (vazba na tabulky: voc_geo_countries + genders) ▪ names – jména (vazba na tabulky: voc_geo_countries + genders) – 50 –


Analýza a návrh

Diagram 15: Databázové tabulky voc_nam

Data aplikace jsou uložena v databázovém systému MySQL s využitím pokročilé PL/SQL logiky. Zde dochází k velkému využití triggerů[11] nad několika tabulkami, s jejichž pomocí je možné velkou část business logiky přesunout na úroveň databázové vrstvy. Jedním příkladem za všechny je trigger, který spočítá počet revizí daného schématu a v případě, že jejich počet bude větší než 50, smaže záznam na pozici 51 pro dané schéma. Tím zaručí prostor pro

– 51 –


Analýza a návrh

následné uložení revize do databáze. Tento proces uložení velmi dobře popisuje vnořená aktivita „Uložit diagram” v diagramu 10. Kompletní struktura tabulek a jejich vazeb byla z Enterprise Architect vygenerována do souboru SQL umožňující okamžitý import do připravené databáze. Tabulku usr definuje příloha 7, tabulku sys definuje příloha 8 a tabulku voc příloha 9.

3.2.2 Business vrstva Celé jádro aplikace zpracovává velké množství složitých operací. Jednou z nejsložitějších je ukládání a otevření stávajícího databázového schématu. Mezi další náročné prvky na běh systému aplikace patří také lokalizace rozhraní aplikace a samotných slovníků pro generování dat. Právě slovníky mají svá specifická kritéria pro správu a zobrazení jejich hodnot. Důležitou součástí zpracovávanou na úrovni business vrstvy je také validace neboli kontrola dat při vstupu či výstupu z aplikace. Je důležitá z důvodu zachování konzistence dat ve schématu a také pro další operace nad schématem jakým je ukládání nebo verzování jednotlivých schémat.

3.2.2.1 Uložení schématu Na základě požadavku U_fREQ_5.2 probíhá ukládání schématu v jazyce XML. Pro tuto potřebu je navržena specifická struktura zápisu, která pokrývá všechny nabízené možnosti nastavení jak na úrovni schématu, tabulky či jednotlivých sloupců. <schema name="icq"> icqcountryuser_id

townuser_id – 52 –


Analýza a návrh

Obecné parametry •

name – název schématu, tabulky (hodnota: text)

Parametry pro sloupec •

fk – sloupec je definován jako cizí klíč tabulky (hodnota: 1 – zapnuto; 0 – vypnuto)

•

fkid – identifikátor sloupce cizího klíče (hodnota: číslo)

•

id – unikátní identifikátor sloupce v celém schématu (hodnota: číslo)

•

idx – povolení indexace dat ve sloupci (hodnota: 1 – zapnuto; 0 – vypnuto)

•

dsi – zdroj pro logický číselník (definice, odkud aplikace čerpá zdrojová data pro

plnění daty – například: města z určitého státu) (hodnota: číslo) •

dit – způsob plnění daty (výběr slovníku) (hodnota: číslo)

•

ditv – vybraná hodnota nebo vstup (konkrétní hodnota pro definici výstupu) (hodno-

ta: text) •

dt – datový typ sloupce (char, int) (hodnota: číslo)

•

null – řádky nemohou být prázdné (hodnota: 1 – zapnuto; 0 – vypnuto)

•

pk – sloupec je definován jako primární klíč tabulky (hodnota: 1 – zapnuto; 0 – vy-

pnuto) •

pos – pořadí sloupce v tabulce (hodnota: číslo)

•

uiq – unikátní záznam dat ve sloupci (hodnota: 1 – zapnuto; 0 – vypnuto)

Parametry pro tabulku •

ai – povolení auto-increment pro sloupec s primárním klíčem (hodnota: 1 – zapnuto;

0 – vypnuto) •

eng – formát tabulek (hodnota: text)

Pro úsporu dat při ukládání schématu prochází parser nastavení tabulek a parametry jejichž hodnota je nastavena na 0 nebo jsou prázdné, nezahrne je do výsledného zápisu schématu. Reverzním způsobem tak parser rozpozná, že v elementu chybí jakýkoliv parametr a jeho hodnotu tak automaticky nastaví na 0. Tímto způsobem nemůže dojít ke kolizím při ukládání schématu.

– 53 –


Analýza a návrh

3.2.2.2 Lokalizace databázových slovníků Vzhledem k rozsáhlým možnostem nastavení aplikace je také možné dále lokalizovat slovníky pomocí dat uložených v souboru PHP pro možnost generování dat dle definice požadavku S_fREQ_7. Názorný příklad využití takového slovníku je možné naleznout na tabulce voc_geo_countries, která obsahuje informace o sloupcích definující jednotlivé záznamy

zemí/států. Názvy sloupců

Hodnoty sloupců

country_id

1

country_english_name

Czech Republic

country_string

COU_CZ

country_shortcut

CZ

continent_id

1

predial_id

5678

street_setting

{street}_{number}

Tabulka 9: Výpis záznamu databázové tabulky voc_geo_countries

Lokalizovaný soubor států se nachází na následujícím relativně odkazovatelném umístění lang/cs/voc/geo/countries.php. Jazykový identifikátor složky pro daný překlad je na-

stavován dle preferencí uživatele a jeho nastavení překladu aplikace. Párování záznamů je realizováno na základě hodnot ze sloupce country_string a unikátním klíčem záznamu. Dle klíče je na požadovaném místě v aplikaci (seznam států při výběru slovníkových záznamů) zobrazena hodnota prvku pole pro zvolený klíč. 'Česká republika', 'COU_SK' => 'Slovenská republika'; ); ?>

3.2.2.3 Správa jazykových mutací aplikace Požadavek A_fREQ_7 definuje možnost nastavit a spravovat kompletní překlady aplikace. Jeho charakteristika je do velké míry totožná z požadavkem S_fREQ_7 z předchozí kapitoly. Zde také dochází k odkazování na soubory PHP, ve kterých jsou informace o překladu ulože-

– 54 –


Analýza a návrh

ny. Lokalizačních souborů je však v tomto případě mnohem více z důvodu rozsáhlosti možností a funkcionalit aplikace. Samotný jazykový soubor je tak uložen ve složce, které bude tématicky náležet. Systém nastavení a uložení dle jazykové mutace je stejný jako v předchozím případě. Při zobrazení zdrojového kódu pro soubor /lang/cs/app/user.php nalezneme informace o uživateli – v tomto případě výňatek o jeho úspěšné registraci. 'Váš účet je nyní aktivní. Děkujeme za registraci.', 'ACCOUNT_ACTIVE_ADMIN' => 'Váš účet je nyní aktivní.', 'ACCOUNT_ACTIVE_PROFILE' => 'Váš účet byl reaktivován.'; ); ?>

Základním předpokladem pro správnou a kompletní realizace všech překladů aplikace, ať již rozhraní či slovníků, je držet a spravovat lokalizaci v anglickém jazyce. Tyto soubory pak lze jednoduše nabídnout potenciálním překladatelům k lokalizaci do jejich národního jazyka. Samozřejmostí je také fakt, že pro kódování souborů bude využito UTF-8 z důvodu snadné použitelnosti v systému ale hlavně pro kompletní mezinárodní znakovou sadu.

3.2.3 Prezentační vrstva Návrh grafického rozhraní aplikace GDPTDA je realizován v aplikaci Axure RP 5.6 od společnosti Axure Software Solutions, Inc. Prioritní výhodou a také důvodem pro využití právě tohoto nástroje je možnost vytvářet interaktivní klikací rozhraní s pomocí wireframe objektů, které následně umožní snazší představu pro vývoj finálního rozvržení aplikace. Výsledek návrhu grafického rozhraní lze jednoduše vyexportovat jako proklikatelnou webovou stránku nebo jako soubor dokumentů popisující jednotlivé funkční prvky návrhu. Základním kritériem pro tvorbu uživatelského rozhraní bude minimalistický vzhled s doprovodnými ikonkami doplňujícími popisy akcí pro lepší přehlednost. Právě přehlednost je stavebním prvkem celého grafického návrhu. Díky množství informací, které bude mít uživatel na svém monitoru zobrazeny, je potřeba účelově a efektivně nastavit pozici informace tak,

– 55 –


Analýza a návrh

aby jeho zrak automaticky mířil na místo, kde bude požadovanou informaci, tlačítko či ikonu očekávat. Dominantním prvkem grafického rozhraní aplikace je v průběhu vytváření a editace schématu lišta panelů (anglicky: tab panel). Pro snadnější představu jak taková lišta panelů vypadá, můžeme nahlédnout do moderních webových prohlížečů jako je Mozilla Firefox, Opera či Google Chrome.

Obrázek 9: Lišta panelů ve webovém prohlížeči Mozilla Firefox 4

Hlavní myšlenkou používání panelů je možnost snadné orientace mezi otevřenými webovými stránkami, v případě GDPTDA se jedná o jednotlivé tabulky databázového schématu.

3.2.3.1 Náhledy obrazovek V rámci návrhu obrazovek s pomocí wireframes je popsáno základní flow vytváření a nastavení jednotlivých tabulek pro potřeby výstupu z aplikace. Jedná se tak o stěžejní obrazovky, se kterými bude uživatel pracovat pokaždé, bude-li chtít připravit data pro výsledné vygenerování souborů. Samotné obrazovky nebudou obsahovat další funkční prvky jako je hlavní menu, přihlašovací formulář aplikace či zápatí s informacemi o aplikaci. 3.2.3.1.1 Hlavní obrazovka Na úvodní obrazovce, první obrazovka, kterou uživatel uvidí při návštěvě aplikace, je zobrazeno logo aplikace/projektu (1). Vpravo od něj se nachází přihlašovací formulář (2) s odkazem na možnost registrace (3). Dominantní panel záložek (4) webu slouží jako rozcestník mezi další důležité stránky jako jsou kontakty, nápověda, novinky v aplikaci či samotný popis aplikace. V bloku uprostřed (5) stránky se nachází prostor, který bude dynamicky plněn na základě vybrané záložky. Při tvorbě schématu nebo jeho editaci se zde budou zobrazovat wireframy z obrázků 11, 12, 13 a 14. Pod těmito vloženými prvky bude zobrazeno tlačítko pro generování výstupu schématu (6). V zápatí úvodní stránky (7) je možné uvést libovolný text obsahující například autora aplikace, rok vzniku či licenční ujednání. – 56 –


Analýza a návrh

2

1 3 4

5

6

7 Obrázek 10: Wireframe – Hlavní obrazovka

1. Logo webové stránky

5. Prostor pro další vnořené stránky

2. Přihlašovací formulář

6. Generovat výstup

3. Nová registrace

7. Zápatí webu

4. Panel stránek webu 3.2.3.1.2 Nastavení tabulky Přidání nové tabulky (1) bude provedeno po stisknutí tlačítka +. Takto vytvořenou tabulku je možné následně smazat tlačítkem X (3). Editaci názvu nové tabulky umožňuje vstupní pole (2) v panelu. Celý seznam tabulek (4) je rozdělen do dalších funkčních celků. Pro označení sloupce (5) je zde připraven checkbox (5) pro každý sloupce. Název sloupce je vyplněn do vstupního pole (6). Datový typ sloupce lze vybrat pomocí dostupného seznamu (7). Na základě výběru datového typu je možná nastavit způsob generování dat (8) spolu s volitelným seznam možností konkrétních voleb. Pro detailní parametry daného sloupce jsou tlačítka představující auto-increment (9), primární klíč (10) a unikátní klíč (11). Nápovědný text pro konkrétní datový typ bude vyvolána po kliknutí na tlačítko ? (12). Označeným sloupcům (5) je možné hromadně nastavovat další parametry jako je primární klíč (14), unikátní klíč (15), nebo je smazat (16). Vstupní pole s názvem Generate [x] rows (17) nastaví počet řádků generovaných pro nastavovanou tabulku.

– 57 –


Analýza a návrh

Aby byla manipulace se sloupci kompletní, je umožněno vložit vetší množství sloupců po zadání tohoto počtu do vstupního pole (18). Následně je potřeba vybrat, zda bude vložení provedeno na začátek tabulky (19), na konec (20) či po konkrétním sloupci vybraným ze seznamu (21). Konečné nastavení přidání sloupců je třeba potvrdit tlačítkem Execute (22). Po kliknutí na tlačítko náhledu (23) se zobrazí desetiřádková ukázka výstupu. 1

3

2

4 9

5 6

8

16

14

a

11 10

13 12

17

b

15 18

7

c

19

20

Obrázek 11: Wireframe – Nastavení tabulky

1. Přidat novou tabulku

13. Smazat sloupec

2. Název tabulky

14. Primární klíč pro označené sloupce

3. Smazat tabulku

15. Unikátní klíč pro označené sloupce

4. Seznam tabulek

16. Smazat označené sloupce

5. Označení sloupce

17. Počet generovaných řádků

6. Název sloupce

18. Přidat X sloupců

7. Datový typ

a) Na začátek

8. Generovaná data

b) Na konec

9. Auto-increment

c) Po sloupci [název_sloupce]

10. Primární klíč

19. Provést příkaz

11. Unikátní klíč

20. Vygenerovat náhled výstupu

12. Nápověda 3.2.3.1.3 Nápověda Každý funkční prvek je doplněn o ikonu ? pro lepší informovanost uživatele. Tento systém nápovědy je velmi praktický pro nastavování jednotlivých datových typů a jejich možností plnění daty (1). Hesla nápověd pro již zmiňované datové typy jsou doplněna o názorné příklady specifických možností nastavení.

– 58 –


Analýza a návrh

1

Obrázek 12: Wireframe – Nápověda

1. Pole s nápovědným textem Další možnost nápovědy bude možné vyvolat pomocí zastavení kurzoru na konkrétním tlačítku, poli či seznamu ve fázi nastavení tabulky. Poté dojde k vyvolání hintu s krátkým avšak obsahově přesně definovaných textem popisující daný prvek. 3.2.3.1.4 Více tabulek Pohyb nad více tabulkami je umožněn pomocí lišty s panely, které představují jednotlivé tabulky. Posun lišty vlevo (1) a vpravo (3) dovolují tlačítka < a > umístěná na začátku a konci lišty s panely. Přehled dalších tabulek (2) je zobrazen pomocí panelů v záhlaví. 1

2

Obrázek 13: Wireframe – Více tabulek

1. Posunout lištu tabulek vlevo

3. Posunout lištu tabulek vpravo

2. Přehled dalších tabulek

– 59 –

3


Analýza a návrh

3.2.3.1.5 Náhled výstupu Přehled tabulek (1) v záhlaví obrazovky dovoluje snadnou orientaci a přechod na další tabulky. Vygenerovaný náhled (2) je realizován pomocí vloženého rámce s horizontálním posuvníkem (3) pro snazší procházení tabulkou. Názvy jednotlivých sloupců jsou uvedené v záhlaví. Pro ukončení náhledu je zde tlačítko Edit (4). Po jeho stisknutí bude opět zobrazena možnost nastavení tabulky. 1

2

3 4 Obrázek 14: Wireframe – Náhled výstupu

1. Přehled tabulek

3. Posuvník

2. Vygenerovaný náhled výstupu

4. Editace výstupu

3.2.3.2 Grafický design Po odladění návrhu grafického rozhraní následuje samotná realizace. Ta probíhá s pomocí grafického software Photoshop od americké společnosti Adobe. Ten je primárně vybrán díky širokým možnostem exportu designu, jeho rozřezání na jednotlivé grafické části a v neposlední řadě možnosti pracovat s vrstvami. Ty umožní efektivnější ladění designu, posouvání prvků či řazení do logických celků. Výsledný grafický výstup z aplikace Photoshop je využit pro nakódování všech stránek a obrazovek dle standardů W3C3 jak pro kaskádové styly CSS, tak zápis XHTML dle specifikace. 3.2.3.2.1 Obrázky a ilustrace V rámci snížení objemu datového toku dochází například k seskupení informačních ikon do jednoho obrazu a jeho pozicování zajistí vlastnosti CSS position a widht/height. Tímto 3 World Wide Web Consortium (W3C) je mezinárodní konsorcium, jehož členové společně s veřejností vyvíjejí webové standardy pro World Wide Web.

– 60 –


Analýza a návrh

jednoduchým krokem dojde k načtení stránky mnohem rychleji a efektivně, avšak hlavní výhoda bude spočívat při zobrazení dalších stránek či panelů. Zde již není potřeba znovu načítat grafický obraz souboru ikon, ale využije se jen potřebný výřez pro jejich zobrazení. Na stejném principu fungují pokročilé grafické layouty například u sociální služby Facebook nebo video portálu YouTube.

Obrázek 15: Sloučení více obrázků a ikon v jeden na serveru YouTube.com

Všechny použité ikony4 budou mít velikost nejběžnějšího rozměru 16x16 pixelů. Právě tento rozměr je ideální pro zobrazení funkčních obrázků nad tlačítky nebo prvky. Obrázek 16: Sloučené základní ikony aplikace GDPTDA

Seznam ikon z obrázku 10 popsaný zleva doprava: 1. Nápověda

5. Smazat

2. Přidat sloupec na začátek tabulky

6. Primární klíč

3. Přidat sloupec na konec tabulky

7. Cizí klíč

4. Přidat sloupec po sloupci Jak je popsáno výše, sloučení ikon nejen zaručí rychlejší načítání webové stránky, ale také sníží velikost objemu stahovaných dat. Například samostatná ikona nápovědy má velikost souboru 786 B. Pokud bychom počet sloučených ikon vynásobili přibližnou velikostí 800 B na ikonu, byl by výsledek 5 600 B = 5,46 KB. Po sloučení má však výsledný obrázek velikost 2,54 kB což je 2,14x méně než 7 ikon v samostatných souborech. Technicky vzato, snížením velikosti grafických prvků dojde ke snížení potřebného množství dat pro sestavení webové stránky na straně uživatele a ke snížení datového přenosu mezi serverem a uživateli používající aplikaci. 4 Autorem ikon je Mark James (http://www.famfamfam.com/lab/icons/silk/)

– 61 –


Analýza a návrh

Představíme-li si situaci, kdy dojde k 1 000 zobrazení stránky denně při využití obou způsobů vykreslení grafických ikon, získáme přehledné srovnání popsané v tabulce 10. 1 000 zobrazení denně

7 souborů ikon (5,46 kB)

jeden soubor ikon (2,54 kB)

den

5,33 MB

2,48 MB

týden

37,32 MB

17,36 MB

měsíc

165,29 MB

76,89 MB

1,9 GB

905,37 MB

rok

Tabulka 10: Porovnání datové náročnosti při změně způsobu zobrazení ikon

Z výsledků tabulky je tedy zřejmé, že díky jednoduché úpravě ikon lze dosáhnout velmi efektivního snížení datové náročnosti. Úvahy a výpočty o maximální úspoře dat je možné dále rozvíjet s rostoucím počtem grafických prvků, které budou na stránce zobrazeny. 3.2.3.2.2 Rozlišení obrazovky a šířka stránky Celý design aplikace bude navržen jako dynamická, relativně a horizontálně pozicovaná webová stránka. Tento přístup zaručuje optimální zobrazení na nejpoužívanějších rozlišeních dnešních monitorů. Pro zjištění optimální výchozí šíře stránky jsem využil statistik návštěvnosti Google Analytics studentského portálu VSMIE.com (http://www.vsmie.com) za období 1. ledna – 31. března 2011. Výsledek měření je zobrazen v tabulce 11 a představuje 10 rozlišení, které využili návštěvníci nejčastěji. Z tohoto měření je zřejmé, že při počtu 19 237 návštěv bylo nepoužívanějším rozlišením obrazovky 1280x800 px. Pokud však dojde k pronásobení všech šířek/výšek rozlišení s počtem návštěv daného rozlišení, a tento výsledek je dále vydělen celkovým počtem návštěv získáme absolutní průměr ideálního rozlišení 1465x920 px, které lze na 86,87 % bez sebemenších problémů využívat.

– 62 –


Analýza a návrh

Rozlišení (px)

Počet návštěv

Návštěvy

Šířka x počet návštěv (px)

Výška x počet návštěv (px)

1

1280x800

3 677

16,79 %

4 706 560

2 941 600

2

1680x1050

3 186

14,55 %

5 352 480

3 345 300

3

1366x768

3 041

13,89 %

4 154 006

2 335 488

4

1280x1024

2 511

11,47 %

3 214 080

2 571 264

5

1920x1080

2 472

11,29 %

4 746 240

2 669 760

6

1440x900

1 339

6,11 %

1 928 160

1 205 100

7

1024x768

1 142

5,22 %

1 169 408

877 056

8

1920x1200

908

4,15 %

1 743 360

1 089 600

9

1024x600

627

2,86 %

642 048

376 200

10

1600x900

334

1,53 %

534 400

300 600

19 237

87,86 %

28 190 742

17 711 968

1 465

920

Celkem

Průměr (zaokrouhleno na celá čísla)

Tabulka 11: Přehled 10 používaných rozlišení na portálu VSMIE.com

Obrázek 17: Překryvné schéma 10 používaných rozlišení na portálu VSMIE.com

Dle překryvného schématu v obrázku 17 je zřejmé, že do optimálního rozlišení se vměstná pouze pět menších zobrazení než je absolutní průměr. To znamená, že je zapotřebí pro tato

– 63 –


Analýza a návrh

menší rozlišení uzpůsobit CSS soubor tak, aby se data a informace zobrazené na webové stránce bez problému vykreslila i na monitorech s menší uhlopříčkou a rozlišením.

– 64 –


Prototypová implementace

4 Prototypová implementace Účelem prototypu není demonstrovat dnes téměř samozřejmý proces registrace a přihlášení uživatele do aplikace či zobrazování nápovědy k jednotlivým funkčním prvkům, nýbrž dokázat jak efektivní může být příprava testovacích dat pro databázové systémy v několika jednoduchých krocích. Pro názornou ukázku fungování analyzované a navrhované aplikace GDPTDA byla vytvořena funkční verze představující základní funkcionality výsledné aplikace – vytvoření a nastavení databázové tabulky, hodnoty pro výstup a provedení vygenerování výstupu. Z rozsáhlého databázového schématu je použito celkem 11 tabulek obsahující slovníkové geografické záznamy. Z tohoto počtu bylo pouze 6 tabulek naplněno testovacími daty pro ukázku závislosti tabulek v procesu generování výstupu. Prázdné tabulky je však potřeba vytvořit z důvodu zachování integrity dat v databázi. Tučně označené tabulky v následujícím seznamu představují ty, jejichž obsah je naplněn slovníkovými daty. •

voc_geo_continents

•

voc_geo_regions

•

voc_geo_countries

•

voc_geo_streets

•

voc_geo_countries_unions

•

voc_geo_towns

•

voc_geo_currencies

•

voc_geo_unions

•

voc_geo_districts

•

voc_geo_zipcodes

•

voc_geo_predials

4.1 Realizace prototypu Prototypová realizace začínala definicí, která data budou generovány. Základní logika celé aplikace leží na jednom komplexním SQL dotazu: SELECT con.continent_string, cou.country_string, reg.region_name, tow.town_local_name, zip.zipcode_text FROM voc_geo_continents con, voc_geo_countries cou, voc_geo_regions reg, voc_geo_towns tow, voc_geo_zipcodes zip WHERE con.continent_id = cou.continent_id AND cou.country_id = reg.country_id AND reg.region_id = tow.region_id AND zip.zipcode_id = tow.zipcode_id AND ...

– 65 –



Poslední podmínka AND ... v dotazu představuje variabilitu pro definici základního sloupce tabulky, od kterého se následně bude hierarchicky odvíjet generování dalších sloupců. Pokud tedy zvolíme cou.continent_id = 5, získáme seznam všech států, jejich krajů, měst a poštovních směrovacích čísel daných měst z kontinentu Evropa. Naopak zadáním zip.zipcode_id = 5 získáme seznam všech měst, krajů, států a kontinentů, v nichž se místo s tímto

směrovacím číslem nachází – výsledkem je Brno-venkov. Pro náhodný výběr všech měst ze země byla využita funkce ORDER BY RAND() jež umožňuje vytvořit seznam náhodně setříděných řádků tabulky. Datový typ sloupce bude definován na základě způsobu plnění sloupce tabulky. Pro pořadí je nastaven typ INT, pro textové hodnoty je VARCHAR() s proměnnou délkou vstupu sloupce. Tyto datové typy budou nastaveny na základě výběru číselníků: •

Pořadí (auto-increment) – INT

•

Kraj – VARCHAR(15)

•

Kontinent – VARCHAR(15)

•

Město – VARCHAR(25)

•

Stát – VARCHAR(25)

•

PSČ – INT

Pokud dojde k vybrání jednoho typu dat, nebude možné ho již v tabulce využít. Tím nebudou zobrazovány duplicitní hodnoty ve sloupcích. Omezením testovacího výstupu na 50 importních řádků bylo docíleno pomocí LIMIT 50 v primárním SQL dotazu. Díky tomu lze napevno nastavit hodnotu auto-incrementu tabulky na číslo 51. Primární klíč je nastaven automaticky na první sloupec tabulky. Název takto definovaného sloupce je přenesen do příkazu PRIMARY KEY `nazev_sloupce`. Pro potřebu názorné ukázky není potřeba odchytávat nelogické možnosti či chyby jakou může být například prázdný název sloupce či tabulky nebo samotného primárního klíče tabulky. Výsledný zdrojový kód prototypu se nachází v příloze 11.

4.2 Systémové požadavky prototypu •

Webhosting nebo lokální prostředí s podporou: ◦ MySQL databáze verze 5.x a vyšší s podporou InnoDB (http://www.mysql.com/) ◦ PHP verze 5.x a vyšší (http://www.php.net/) ◦ phpMyAdmin verze 3.x a vyšší (http://www.phpmyadmin.net/) – 66 –



◦ HTTP Server Apache verze 2.2 a vyšší (http://httpd.apache.org/) •

Jeden z webových prohlížečů: ◦ Mozilla Firefox 3, 4 ◦ Opera 9, 10 ◦ Internet Explorer 7, 8, 9

•

Osobní počítač vybavený optickou mechanikou CD/DVD

4.3 Postup instalace 1. V aplikaci phpMyAdmin (či jiném databázovém editoru) vytvořte databázi s názvem gdptda se znakovou sadou UTF-8 2. Nad vytvořenou databází spusťte obsah skriptu gdptda_all.sql v příloze 7 (k nalezení také ve složce /prototyp/install na přiloženém CD) a) V případě potřeby nebo problému lze zvlášť vytvořit strukturu databáze gdptda_structure.sql či naimportovat data do tabulek z gdptda_data.sql. Tyto soubory jsou dostupné pouze na CD 3. Nakopírujte data ze složky /prototyp z CD do umístění, ze kterého chcete aplikaci spustit 4. Editujte soubor config.php ve složce do které jste data nakopírovali a) Do řádků číslo 5 až 7 vložte umístění databázového serveru, název databáze, přihlašovací jméno a heslo 4| 5| 6| 7|

'host' 'user' 'pass' 'name'

=> => => =>

'localhost', // umístění databázového serveru 'username', // přístupové jméno do databáze 'password', // přihlašovací jméno do databáze 'dbname' // název databáze

b) Soubor uložte 5. Do webového prohlížeče vložte adresu, na které bude aplikace dostupná. Odvíjí se od umístění, do kterého byly nakopírovány soubory v bodě 3. a) Místní umístění (localhost): http://localhost/gdptda/ b) Webové umístění: http://www.example.com/gdptda/ 6. Pokud byla instalace úspěšně provedena, zobrazí se úvodní obrazovka prototypu

– 67 –



Obrázek 18: Úvodní obrazovka prototypu GDPTDA

Poznámka: Funkční verze prototypu se nachází na webové adrese http://gdptda.pnaky.com/, kde bude k dispozici do 31. června 2011.

4.4 Ukázka výstupu Při definici výstupních dat má uživatel velmi široké možnosti jak sestavit sloupce tabulky dle vlastních požadavků. Užitečnou vlastností je funkce Zamíchat, která náhodně (random) rozhází seznam generovaných dat.

Obrázek 19: Nastavení výstupu z prototypu GPDTDA

Dle nastavení hodnot v obrázku 19 dojde po stisknutí tlačítka GENEROVAT k vypsání SQL výstupu: CREATE TABLE `geography` ( ìd` INT, `continent` VARCHAR(15), `country` VARCHAR(25), `town` VARCHAR(25), PRIMARY KEY (ìd`),

– 68 –



) AUTO_INCREMENT=51; INSERT INTO `geography` (ìd`, `continent`, `country`, (1, "Evropa", "Česká republika", "Praha-východ"); INSERT INTO `geography` (ìd`, `continent`, `country`, (2, "Evropa", "Česká republika", "Klatovy"); INSERT INTO `geography` (ìd`, `continent`, `country`, (3, "Evropa", "Česká republika", "Brno-město"); INSERT INTO `geography` (ìd`, `continent`, `country`, (4, "Evropa", "Česká republika", "Liberec"); INSERT INTO `geography` (ìd`, `continent`, `country`, (5, "Evropa", "Česká republika", "Náchod");

`town`) VALUES `town`) VALUES `town`) VALUES `town`) VALUES `town`) VALUES

Tento výstup je zkrácenou verzí plnohodnotného výstupu s počtem 50 řádků. Výstup je možné importovat do databáze a vytvořit tak novou tabulku geography se sloupci id, continent, country a town, kde sloupec id je definován jako primární klíčem celé tabulky.

– 69 –


Zhodnocení realizace

5 Zhodnocení realizace Prototypovou realizaci lze zhodnotit kladně, ačkoliv logika aplikace se odklonila od požadavků a návrhů v rámci analýzy. Hlavním důvodem této odchylky je programátorská náročnost, jež byla nad mé možnosti a také rozsah této práce. Primárním cílem prototypu tak bylo vytvořit funkční generátor dat reflektující logické vazby mezi jednotlivými geografickými objekty uloženými v databázi aplikace. Tento cíl byl úspěšně splněn. V rámci programátorské úspory času tak byla vyjmuta možnost volit nejprve datový typ sloupce – ten je volen automaticky na základě databázového slovníku. Výstupní SQL formát byl v průběhu vývoje prototypu několikrát bez problémů spuštěn nad databázovým systémem MySQL verze 5. Zkušebně došlo i na spuštění výstupu nad MySQL 4 a ani zde nedošlo k žádnému chybovému hlášení či selhání při vykonání příkazů. Závěrem zhodnocení realizace lze prototyp označit za experimentální cestu při implementaci řešení generátoru testovacích dat.

– 70 –


Závěr

Závěr Při psaní této práce jsem se několikrát zabýval tím, zda-li zvolené téma nebylo moc náročné a komplikované. S přibývajícím množstvím textu, stran a ilustrací jsem se ujistil, že navrhovaná aplikace má smysl nejen pro mé interní potřeby ale jistě by našla ocenění i z řad vývojářů. Pokud by na vývoji GDPTDA začal pracovat jednotlivec, v lepším případě tým několika lidí, jejichž znalosti jsou v oblasti programování širší než mé, mohl by se tento projekt profilovat mezi komerční aplikace zmiňované v prvních kapitolách této práce. Webové rozhraní by zaručovalo dostupnost 24 hodin denně z jakéhokoliv místa pokryté sítí Internet. Vzhledem k čistému využívání programovacího jazyku PHP není třeba instalovat žádné podpůrné nástroje na straně klienta/uživatele. Tím nebude docházet k omezení uživatele z minoritních platforem. Jednou z nejdůležitějších a nejpodstatnějších věcí při pokusu o masivnější využívání by bylo nastavení ekonomického modelu celé aplikace tak, aby dokázala v prvních měsících svého provozu pokrýt náklady na sebe samou a následně na tým lidí, kteří by ji vytvářeli a spravovali. Důkazem, že generátor testovacích dat pro databázové systémy není jen účelovou myšlenkou pro potřeby diplomové práce, je fakt, že moji kolegové sami průběžně přicházeli s dotazy zdali aplikace bude umět tu či onu funkcionalitu. Velmi často zmiňovaným tématem bylo vytvoření API pro využívání logiky generátoru přímo z vývojářského prostředí jednotlivých programovacích jazyků a jejich frameworků. Tím by došlo k přímému propojení s databázovým generátorem a databázovým serverem – tato jednoduchá vazba by umožnila data plnit přímo z generátoru a tím tak ušetřit mezikroky jako je definice, generování a stažení výstupu SQL na úrovni GDPTDA a na opačné straně data do databázového stroje nahrát. Takto ušetřený čas lze využít při vývoji software mnohem efektivněji. To nejcennější co však analýza, návrh a prototypová implementace přinesla lze shrnout do následujících dvou vět. Generování dat pro potřeby testování aplikací využívajících k ukládání dat databázové systémy lze specifikovat natolik, že nebude docházet k bezduchému plnění da– 71 –


Závěr

tabázových tabulek daty, která nemají žádné logické vazby a neumožní tak jejich plnohodnotné otestování. Všechny tyto problémy dokáže eliminovat kombinace všech klíčových vlastností Generátoru dat pro testování databázových aplikací.

– 72 –


Slovník pojmů

Slovník pojmů •

standalone software – aplikace, která pro svůj běh nepotřebuje síťové připojení

•

wireframe – „drátěný model” grafického rozhraní aplikace

•

web-based – aplikace postavena na webových službách

•

stable – stabilní – využíváno v kontextu „stable version” (stabilní verze)

•

flow – tok; představuje sled určitých operací či objektů (cash flow)

•

workflow – schéma procesního toku, například zobrazení obrazovek, zpracování dokumentů

•

parser – aplikace umožňující převedení textového souboru na logické celky pro snazší zpracování

•

hint – nápovědný text při zastavení kurzoru myši nad grafickým prvkem v aplikaci

•

API – rozhraní pro programování aplikací (například GoogleMaps API)

•

framework – softwarová struktura pro podporu programování a vývoje

– 73 –


Seznam literatury

Seznam literatury [1] End User License Agreement. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 16.12.2006, poslední změna 27.9.2009 [cit. 2011-04-23]. Dostupné z WWW: [2] GNU General Public License. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 20.12.2004, poslední změna 13.4.2011 [cit. 2011-04-23]. Dostupné z WWW: [3] Enterprise Architect. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 8.5.2010, poslední změna 6.4.2011 [cit. 2011-04-23]. Dostupné z WWW: [4] ARLOW Jim; NEUSTADT Ila. UML 2 a unifikovaný proces vývoje aplikací. 2. akt. a dopl. vydání.Brno : Computer Press, 2007. 567 s. ISBN 978-80-851-1503-9 [5] Unified Modeling Language. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 14.2.2005, poslední změna 8.9.2010 [cit. 2011-04-22]. Dostupné z WWW: [6] Analýza požadavků. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 26.12.2008, poslední změna 8.4.2011 [cit. 2011-04-23]. Dostupné z WWW: [7] Diagram aktivit. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2.12.2006, poslední změna 27.2.2011 [cit. 2011-04-23]. Dostupné z WWW: [8] Diagram tříd. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 16.12.2010, poslední změna 23.3.2011 [cit. 2011-04-25]. Dostupné z WWW: [9] PASTORČÁK, Petr. Sequence Diagrams [online]. 13.11.2010 [cit. 2011-04-23]. Dostupné z WWW: . [10] CONNOLLY Thomas; BEGG Carolyn; HOLOWCZAK Richard. Mistrovství - databáze: Profesionální průvodce tvorbou efektivních databází. 1. vydání.Brno : Computer Press, 2009. 584 s. ISBN 978-80-251-2328-7 [11] GROFF James R.; WEINBERG Paul N.. SQL Kompletní průvodce. 1. vydání.Brno : Computer Press, 2005. 963 s. ISBN 80-251-0369-2

– 74 –


Seznam obrázků

Seznam obrázků Obrázek 1: Nastavení výstupu z aplikace DTM Data Generator..............................................12 Obrázek 2: Nastavení výstupu z aplikace GenerateData.com..................................................14 Obrázek 3: Třída User...............................................................................................................38 Obrázek 4: Třída Folder............................................................................................................39 Obrázek 5: Třída Config...........................................................................................................40 Obrázek 6: Třída Revision........................................................................................................41 Obrázek 7: Třída Table..............................................................................................................42 Obrázek 8: Schéma vazeb třívrstvé aplikace............................................................................44 Obrázek 9: Lišta panelů ve webovém prohlížeči Mozilla Firefox 4.........................................56 Obrázek 10: Wireframe – Hlavní obrazovka............................................................................57 Obrázek 11: Wireframe – Nastavení tabulky............................................................................58 Obrázek 12: Wireframe – Nápověda.........................................................................................59 Obrázek 13: Wireframe – Více tabulek.....................................................................................59 Obrázek 14: Wireframe – Náhled výstupu................................................................................60 Obrázek 15: Sloučení více obrázků a ikon v jeden na serveru YouTube.com..........................61 Obrázek 16: Sloučené základní ikony aplikace GDPTDA.......................................................61 Obrázek 17: Překryvné schéma 10 používaných rozlišení na portálu VSMIE.com.................63 Obrázek 18: Úvodní obrazovka prototypu GDPTDA...............................................................68 Obrázek 19: Nastavení výstupu z prototypu GPDTDA............................................................68

Poznámka: Obrázky 1-19 jsou jako kopie v elektronické podobě uloženy ve složce /obrazky na přiloženém CD.

– 75 –


Seznam diagramů

Seznam diagramů Diagram 1: Vazby funkčních požadavků pro uživatele.............................................................21 Diagram 2: Vazby funkčních požadavků pro administrátora....................................................24 Diagram 3: Případ užití – Registrovat uživatele.......................................................................27 Diagram 4: Případ užití – Generovat výstup.............................................................................28 Diagram 5: Případ užití – Spravovat uživatele.........................................................................30 Diagram 6: Diagram aktivit – Správa kompletního schématu..................................................34 Diagram 7: Diagram aktivit – Uložit schéma...........................................................................36 Diagram 8: Diagram tříd – Vytvořit tabulku.............................................................................37 Diagram 9: Sekvenční diagram – Vytvořit tabulku...................................................................43 Diagram 10: Databázové tabulky use_usr................................................................................46 Diagram 11: Databázové tabulky sys_txt..................................................................................47 Diagram 12: Databázová tabulka sys_sta.................................................................................48 Diagram 13: Databázové tabulky voc_bra................................................................................49 Diagram 14: Databázové tabulky voc_geo...............................................................................50 Diagram 15: Databázové tabulky voc_nam..............................................................................51

Poznámka: Diagramy 1-15 jsou jako kopie v elektronické podobě uloženy ve složce /diagramy na přiloženém CD.

– 76 –


Seznam tabulek

Seznam tabulek Tabulka 1: Klady a zápory aplikace DTM Data Generator.......................................................13 Tabulka 2: Obecné vlastnosti aplikace DTM Data Generator..................................................13 Tabulka 3: Klady a zápory aplikace GenerateData.com...........................................................15 Tabulka 4: Obecné vlastnosti aplikace GenerateData.com.......................................................15 Tabulka 5: Detailní srovnání vlastností aplikací DTM Data Generator a GenerateData.com. .16 Tabulka 6: Popis případu užití – Registrovat uživatele.............................................................27 Tabulka 7: Popis případu užití – Generovat výstup..................................................................29 Tabulka 8: Popis případu užití – Spravovat uživatele...............................................................31 Tabulka 9: Výpis záznamu databázové tabulky voc_geo_countries.........................................54 Tabulka 10: Porovnání datové náročnosti při změně způsobu zobrazení ikon.........................62 Tabulka 11: Přehled 10 používaných rozlišení na portálu VSMIE.com...................................63

– 77 –


Seznam příloh

Seznam příloh Diagram aktivit – Založit nové schéma......................................................................................1 Diagram aktivit – Spravovat tabulky..........................................................................................2 Diagram aktivit – Vytvořit tabulku.............................................................................................3 Diagram aktivit – Spravovat sloupce..........................................................................................4 Diagram aktivit – Vytvořit sloupec.............................................................................................5 Diagram aktivit – Nastavit sloupce.............................................................................................6 Databázové schéma – Importní SQL tabulky usr........................................................................7 Databázové schéma – Importní SQL tabulky sys.....................................................................11 Databázové schéma – Importní SQL tabulky voc.....................................................................14 Zdrojový kód – Importní soubor SQL prototypu......................................................................22 Zdrojový kód prototypu – index.php .......................................................................................31

Poznámka: Přílohy 1-11 jsou jako kopie v elektronické podobě uloženy ve složce /prilohy na přiloženém CD.

– 78 –


Příloha 1

Příloha 1

Diagram aktivit – Založit nové schéma

–1–


Příloha 2

Příloha 2

Diagram aktivit – Spravovat tabulky

–2–


Příloha 3

Příloha 3

Diagram aktivit – Vytvořit tabulku

–3–


Příloha 4

Příloha 4

Diagram aktivit – Spravovat sloupce

–4–


Příloha 5

Příloha 5

Diagram aktivit – Vytvořit sloupec

–5–


Příloha 6

Příloha 6

Diagram aktivit – Nastavit sloupce

–6–


Příloha 7

Příloha 7

Databázové schéma – Importní SQL tabulky usr SET FOREIGN_KEY_CHECKS=0; CREATE TABLE usr_cnf_configs ( config_id BIGINT NOT NULL AUTO_INCREMENT, config_name VARCHAR(255) NOT NULL, config_note TEXT, config_createdate TIMESTAMP NOT NULL, config_lastedit TIMESTAMP, config_revisions INTEGER NOT NULL, stable_revision_id BIGINT, user_id INTEGER NOT NULL, folder_id BIGINT NOT NULL, PRIMARY KEY (config_id), UNIQUE UQ_usr_cnf_configs_config_id(config_id), UNIQUE UQ_usr_cnf_configs_stable_revision_id(stable_revision_id), INDEX IDX_usr_cnf_revisions (stable_revision_id ASC), INDEX IDX_usr_use_users (user_id ASC), INDEX IDX_cnf_folders (folder_id ASC) ) ENGINE=InnoDB ; CREATE TABLE usr_cnf_folders ( folder_id BIGINT NOT NULL AUTO_INCREMENT, folder_name VARCHAR(255) NOT NULL, folder_configs BIGINT NOT NULL, folder_folders BIGINT NOT NULL, folder_createdate TIMESTAMP NOT NULL, folder_lastedit TIMESTAMP, parent_id BIGINT, user_id INTEGER NOT NULL, PRIMARY KEY (folder_id), UNIQUE UQ_usr_cnf_folders_folder_id(folder_id), KEY (parent_id), INDEX IDX_usr_cnf_folders (folder_id ASC), INDEX IDX_usr_use_users (user_id ASC) ) ENGINE=InnoDB ;

–7–


Příloha 7

CREATE TABLE usr_cnf_revisions ( revision_id BIGINT NOT NULL AUTO_INCREMENT, revision_createdate TIMESTAMP NOT NULL, revision_xml TEXT NOT NULL, config_id BIGINT NOT NULL, db_id INTEGER NOT NULL, revision_stable BOOL NOT NULL, PRIMARY KEY (revision_id), UNIQUE UQ_usr_cnf_revisions_revision_id(revision_id), INDEX IDX_usr_cnf_configs (config_id ASC), INDEX IDX_sys_dbs (db_id ASC) ) ENGINE=InnoDB ; CREATE TABLE usr_use_user_types ( user_type_id TINYINT NOT NULL AUTO_INCREMENT, user_type_string VARCHAR(10), PRIMARY KEY (user_type_id), UNIQUE UQ_usr_use_user_types_user_type_id(user_type_id) ) ENGINE=InnoDB ; CREATE TABLE usr_use_users ( user_id INTEGER NOT NULL AUTO_INCREMENT, user_uid VARCHAR(10) NOT NULL, username VARCHAR(255) NOT NULL, password VARCHAR(30) NOT NULL, user_email VARCHAR(100) NOT NULL, user_lang TINYINT NOT NULL, user_realname VARCHAR(255), user_regip VARCHAR(40) NOT NULL, user_lastip VARCHAR(40), user_regdate TIMESTAMP NOT NULL, user_lastvisit TIMESTAMP, user_dst TINYINT, user_dateformat VARCHAR(30), user_timezone DECIMAL(5,2), user_configs INTEGER NOT NULL, user_folders INTEGER NOT NULL, user_type TINYINT NOT NULL, –8–


Příloha 7

PRIMARY KEY (user_id), UNIQUE UQ_usr_use_users_user_id(user_id), UNIQUE UQ_usr_use_users_user_uid(user_uid), INDEX IDX_sys_langs (user_lang ASC), INDEX IDX_user_types (user_type ASC) ) ENGINE=InnoDB ; SET FOREIGN_KEY_CHECKS=1; ALTER TABLE usr_cnf_configs ADD CONSTRAINT FK_usr_cnf_configs_usr_cnf_folders FOREIGN KEY (folder_id) REFERENCES usr_cnf_folders (folder_id) ; ALTER TABLE usr_cnf_configs ADD CONSTRAINT FK_usr_cnf_configs_usr_cnf_revisions FOREIGN KEY (stable_revision_id) REFERENCES usr_cnf_revisions (revision_id) ; ALTER TABLE usr_cnf_configs ADD CONSTRAINT FK_usr_cnf_configs_usr_use_users FOREIGN KEY (user_id) REFERENCES usr_use_users (user_id) ; ALTER TABLE usr_cnf_folders ADD CONSTRAINT FK_usr_cnf_folders_usr_cnf_folders FOREIGN KEY (parent_id) REFERENCES usr_cnf_folders (folder_id) ; ALTER TABLE usr_cnf_folders ADD CONSTRAINT FK_usr_cnf_folders_usr_use_users FOREIGN KEY (user_id) REFERENCES usr_use_users (user_id) ; ALTER TABLE usr_cnf_revisions ADD CONSTRAINT FK_usr_cnf_revisions_sys_dbs FOREIGN KEY (db_id) REFERENCES sys_dbs (db_id) ; ALTER TABLE usr_cnf_revisions ADD CONSTRAINT FK_usr_cnf_revisions_usr_cnf_configs FOREIGN KEY (config_id) REFERENCES usr_cnf_configs (config_id)

–9–


Příloha 7

; ALTER TABLE usr_use_users ADD CONSTRAINT FK_usr_use_users_sys_langs FOREIGN KEY (user_lang) REFERENCES sys_langs (lang_id) ; ALTER TABLE usr_use_users ADD CONSTRAINT FK_usr_use_users_usr_use_user_types FOREIGN KEY (user_type) REFERENCES usr_use_user_types (user_type_id) ;

– 10 –


Příloha 8

Příloha 8

Databázové schéma – Importní SQL tabulky sys SET FOREIGN_KEY_CHECKS=0; CREATE TABLE sys_dbs ( db_id INTEGER NOT NULL AUTO_INCREMENT, db_name VARCHAR(255) NOT NULL, db_version VARCHAR(50) NOT NULL, PRIMARY KEY (db_id), UNIQUE UQ_sys_dbs_db_id(db_id) ) ENGINE=InnoDB ; CREATE TABLE sys_langs ( lang_id TINYINT NOT NULL AUTO_INCREMENT, lang_iso VARCHAR(30) NOT NULL, lang_dir VARCHAR(30) NOT NULL, lang_english_name VARCHAR(100) NOT NULL, lang_local_name VARCHAR(255) NOT NULL, PRIMARY KEY (lang_id), UNIQUE UQ_sys_langs_lang_id(lang_id) ) ENGINE=InnoDB ; CREATE TABLE sys_sta_configs ( sta_id BIGINT NOT NULL AUTO_INCREMENT, config_id BIGINT, start_time TIMESTAMP, end_time TIMESTAMP, tables INTEGER, columns INTEGER, rows INTEGER, file_type CHAR(10), PRIMARY KEY (sta_id), UNIQUE UQ_sys_sta_configs_sta_id(sta_id), KEY (config_id) ) ENGINE=InnoDB ;

– 11 –


Příloha 8

CREATE TABLE sys_txt_help ( help_id INTEGER NOT NULL AUTO_INCREMENT, help_value CHAR(255) NOT NULL, help_createdate DATETIME NOT NULL, help_lastedit TIMESTAMP, PRIMARY KEY (help_id), UNIQUE UQ_sys_txt_help_help_id(help_id) ) ENGINE=InnoDB ; CREATE TABLE sys_txt_helps_values ( value_id INTEGER NOT NULL AUTO_INCREMENT, value_text TEXT, lang_id TINYINT NOT NULL, help_id INTEGER NOT NULL, PRIMARY KEY (value_id), UNIQUE UQ_sys_txt_helps_values_value_id(value_id), INDEX IDX_sys_langs (lang_id ASC), INDEX IDX_sys_txt_help (help_id ASC) ) ; CREATE TABLE sys_txt_news ( news_id INTEGER NOT NULL AUTO_INCREMENT, author_id INTEGER NOT NULL, news_text TEXT NOT NULL, news_createdate TIMESTAMP NOT NULL, news_lastedit INTEGER, news_released BOOL NOT NULL, PRIMARY KEY (news_id), UNIQUE UQ_sys_txt_news_news_id(news_id), INDEX IDX_use_users (author_id ASC) ) ; SET FOREIGN_KEY_CHECKS=1; ALTER TABLE sys_sta_configs ADD CONSTRAINT FK_sys_sta_configs_usr_cnf_configs FOREIGN KEY (config_id) REFERENCES usr_cnf_configs (config_id) – 12 –


Příloha 8

; ALTER TABLE sys_txt_helps_values ADD CONSTRAINT FK_sys_txt_helps_values_sys_langs FOREIGN KEY (lang_id) REFERENCES sys_langs (lang_id) ; ALTER TABLE sys_txt_helps_values ADD CONSTRAINT FK_sys_txt_helps_values_sys_txt_help FOREIGN KEY (help_id) REFERENCES sys_txt_help (help_id) ; ALTER TABLE sys_txt_news ADD CONSTRAINT FK_sys_txt_news_usr_use_users FOREIGN KEY (author_id) REFERENCES usr_use_users (user_id) ;

– 13 –


Příloha 9

Příloha 9

Databázové schéma – Importní SQL tabulky voc SET FOREIGN_KEY_CHECKS=0; CREATE TABLE voc_bra_brands ( brand_id INTEGER NOT NULL AUTO_INCREMENT, brand_name VARCHAR(255) NOT NULL, brand_shortcut VARCHAR(10), industry_id INTEGER NOT NULL, country_id INTEGER NOT NULL, PRIMARY KEY (brand_id), UNIQUE UQ_voc_bra_brands_brand_id(brand_id), INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_bra_industries (industry_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_bra_industries ( industry_id INTEGER NOT NULL AUTO_INCREMENT, industry_string VARCHAR(10) NOT NULL, PRIMARY KEY (industry_id), UNIQUE UQ_voc_bra_industries_industry_id(industry_id) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_continents ( continent_id INTEGER NOT NULL AUTO_INCREMENT, continent_english_name VARCHAR(255), continent_string VARCHAR(255), PRIMARY KEY (continent_id), UNIQUE UQ_voc_geo_continents_continent_id(continent_id) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_countries ( country_id INTEGER NOT NULL AUTO_INCREMENT, country_english_name VARCHAR(255), country_string VARCHAR(255) NOT NULL, – 14 –


Příloha 9

country_shortcut VARCHAR(255) NOT NULL, continent_id INTEGER NOT NULL, predial_id INTEGER NOT NULL, street_setting INTEGER NOT NULL, PRIMARY KEY (country_id), UNIQUE UQ_voc_geo_countries_country_id(country_id), INDEX IDX_voc_geo_continents (continent_id ASC), INDEX IDX_voc_geo_predials (predial_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_countries_unions ( country_union_id INTEGER, country_id INTEGER, INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_geo_unions (country_union_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_currencies ( currency_id INTEGER NOT NULL AUTO_INCREMENT, currency_english_name VARCHAR(255), currency_string VARCHAR(255), currency_symbol_left VARCHAR(12), currency_symbol_right VARCHAR(12), currency_decimal_place CHAR(1), currency_code VARCHAR(3), country_id INTEGER, PRIMARY KEY (currency_id), UNIQUE UQ_voc_geo_currencies_currency_id(currency_id), INDEX IDX_voc_geo_countries (country_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_districts ( district_id INTEGER NOT NULL AUTO_INCREMENT, district_name VARCHAR(255), town_id INTEGER NOT NULL, zipcode_id INTEGER NOT NULL, PRIMARY KEY (district_id), – 15 –


Příloha 9

UNIQUE UQ_voc_geo_districts_district_id(district_id), INDEX IDX_voc_geo_towns (town_id ASC), INDEX IDX_voc_geo_zipcodes (zipcode_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_predials ( predial_id INTEGER NOT NULL AUTO_INCREMENT, predial_value_long VARCHAR(10), predial_value_short VARCHAR(10), predial_type VARCHAR(1), PRIMARY KEY (predial_id), UNIQUE UQ_voc_geo_predials_predial_id(predial_id) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_regions ( region_id INTEGER NOT NULL AUTO_INCREMENT, region_name VARCHAR(255), region_shortcut VARCHAR(30) NOT NULL, country_id INTEGER NOT NULL, predial_id INTEGER NOT NULL, PRIMARY KEY (region_id), UNIQUE UQ_voc_geo_regions_region_id(region_id), INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_geo_predials (predial_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_streets ( street_id INTEGER NOT NULL AUTO_INCREMENT, street_name VARCHAR(255), country_id INTEGER, PRIMARY KEY (street_id), UNIQUE UQ_voc_geo_streets_street_id(street_id), INDEX IDX_voc_geo_countries (country_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_towns – 16 –


Příloha 9

( town_id INTEGER NOT NULL AUTO_INCREMENT, town_english_name VARCHAR(255), town_local_name VARCHAR(255) NOT NULL, region_id INTEGER NOT NULL, country_id INTEGER NOT NULL, predial_id INTEGER NOT NULL, zipcode_id INTEGER NOT NULL, PRIMARY KEY (town_id), UNIQUE UQ_voc_geo_towns_town_id(town_id), INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_geo_predials (predial_id ASC), INDEX IDX_voc_geo_regions (region_id ASC), INDEX IDX_voc_geo_zipcodes (zipcode_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_unions ( country_union_id INTEGER NOT NULL AUTO_INCREMENT, country_union_english_name VARCHAR(255), country_union_string VARCHAR(255), PRIMARY KEY (country_union_id), UNIQUE UQ_voc_geo_unions_country_union_id(country_union_id) ) ENGINE=InnoDB ; CREATE TABLE voc_geo_zipcodes ( zipcode_id INTEGER NOT NULL AUTO_INCREMENT, zipcode_text VARCHAR(255) NOT NULL, PRIMARY KEY (zipcode_id), UNIQUE UQ_voc_geo_zipcodes_zipcode_id(zipcode_id) ) ENGINE=InnoDB ; CREATE TABLE voc_nam_genders ( gender_id SMALLINT NOT NULL AUTO_INCREMENT, gender_string VARCHAR(50), PRIMARY KEY (gender_id), UNIQUE UQ_voc_nam_genders_gender_id(gender_id) ) ENGINE=InnoDB – 17 –


Příloha 9

; CREATE TABLE voc_nam_middle_names ( middle_name INTEGER NOT NULL AUTO_INCREMENT, middle_name_text VARCHAR(50), gender_id SMALLINT, country_id INTEGER, PRIMARY KEY (middle_name), UNIQUE UQ_voc_nam_middle_names_middle_name(middle_name), INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_nam_genders (gender_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_nam_names ( name_id INTEGER NOT NULL AUTO_INCREMENT, name_text VARCHAR(50), gender_id SMALLINT, country_id INTEGER, PRIMARY KEY (name_id), UNIQUE UQ_voc_nam_names_name_id(name_id), INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_nam_genders (gender_id ASC) ) ENGINE=InnoDB ; CREATE TABLE voc_nam_surnames ( surname_id INTEGER NOT NULL AUTO_INCREMENT, surname_text VARCHAR(50), gender_id SMALLINT, country_id INTEGER, PRIMARY KEY (surname_id), UNIQUE UQ_voc_nam_surnames_surname_id(surname_id), INDEX IDX_voc_geo_countries (country_id ASC), INDEX IDX_voc_nam_genders (gender_id ASC) ) ENGINE=InnoDB ; SET FOREIGN_KEY_CHECKS=1;

– 18 –


Příloha 9

ALTER TABLE voc_bra_brands ADD CONSTRAINT FK_voc_bra_brands_voc_bra_industries FOREIGN KEY (industry_id) REFERENCES voc_bra_industries (industry_id) ; ALTER TABLE voc_bra_brands ADD CONSTRAINT FK_voc_bra_brands_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_geo_countries ADD CONSTRAINT FK_voc_geo_countries_voc_geo_continents FOREIGN KEY (continent_id) REFERENCES voc_geo_continents (continent_id) ; ALTER TABLE voc_geo_countries ADD CONSTRAINT FK_voc_geo_countries_voc_geo_predials FOREIGN KEY (predial_id) REFERENCES voc_geo_predials (predial_id) ; ALTER TABLE voc_geo_countries_unions ADD CONSTRAINT FK_voc_geo_countries_unions_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_geo_countries_unions ADD CONSTRAINT FK_voc_geo_countries_unions_voc_geo_unions FOREIGN KEY (country_union_id) REFERENCES voc_geo_unions (country_union_id) ; ALTER TABLE voc_geo_currencies ADD CONSTRAINT FK_voc_geo_currencies_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_geo_districts ADD CONSTRAINT FK_voc_geo_districts_voc_geo_towns FOREIGN KEY (town_id) REFERENCES voc_geo_towns (town_id) ;

– 19 –


Příloha 9

ALTER TABLE voc_geo_districts ADD CONSTRAINT FK_voc_geo_districts_voc_geo_zipcodes FOREIGN KEY (zipcode_id) REFERENCES voc_geo_zipcodes (zipcode_id) ; ALTER TABLE voc_geo_regions ADD CONSTRAINT FK_voc_geo_regions_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_geo_regions ADD CONSTRAINT FK_voc_geo_regions_voc_geo_predials FOREIGN KEY (predial_id) REFERENCES voc_geo_predials (predial_id) ; ALTER TABLE voc_geo_streets ADD CONSTRAINT FK_voc_geo_streets_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_geo_towns ADD CONSTRAINT FK_voc_geo_towns_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_geo_towns ADD CONSTRAINT FK_voc_geo_towns_voc_geo_predials FOREIGN KEY (predial_id) REFERENCES voc_geo_predials (predial_id) ; ALTER TABLE voc_geo_towns ADD CONSTRAINT FK_voc_geo_towns_voc_geo_regions FOREIGN KEY (region_id) REFERENCES voc_geo_regions (region_id) ; ALTER TABLE voc_geo_towns ADD CONSTRAINT FK_voc_geo_towns_voc_geo_zipcodes FOREIGN KEY (zipcode_id) REFERENCES voc_geo_zipcodes (zipcode_id) ; ALTER TABLE voc_nam_middle_names ADD CONSTRAINT – 20 –


Příloha 9

FK_voc_nam_middle_names_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_nam_middle_names ADD CONSTRAINT FK_voc_nam_middle_names_voc_nam_genders FOREIGN KEY (gender_id) REFERENCES voc_nam_genders (gender_id) ; ALTER TABLE voc_nam_names ADD CONSTRAINT FK_voc_nam_names_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_nam_names ADD CONSTRAINT FK_voc_nam_names_voc_nam_genders FOREIGN KEY (gender_id) REFERENCES voc_nam_genders (gender_id) ; ALTER TABLE voc_nam_surnames ADD CONSTRAINT FK_voc_nam_surnames_voc_geo_countries FOREIGN KEY (country_id) REFERENCES voc_geo_countries (country_id) ; ALTER TABLE voc_nam_surnames ADD CONSTRAINT FK_voc_nam_surnames_voc_nam_genders FOREIGN KEY (gender_id) REFERENCES voc_nam_genders (gender_id) ;

– 21 –


Příloha 10

Příloha 10

Zdrojový kód – Importní soubor SQL prototypu /*Disable Foreing key checks */ SET FOREIGN_KEY_CHECKS=0; /*Table structure for table `voc_geo_continents` */ DROP TABLE IF EXISTS `voc_geo_continents`; CREATE TABLE `voc_geo_continents` ( `continent_id` int(11) NOT NULL AUTO_INCREMENT, `continent_english_name` varchar(255) DEFAULT NULL, `continent_string` varchar(255) DEFAULT NULL, PRIMARY KEY (`continent_id`), UNIQUE KEY ÙQ_voc_geo_continents_continent_id` (`continent_id`) ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8; /*Data for the table `voc_geo_continents` */ insert into `voc_geo_continents`(`continent_id`,`continent_english_name`,`continen t_string`) values ('1','Africa','CON_AF'),('2','Antarctica','CON_AN'), ('3','Asia','CON_AS'),('4','Australia','CON_AU'), ('5','Europe','CON_EU'),('6','North America','CON_NA'),('7','South America','CON_SA'); /*Table structure for table `voc_geo_countries` */ DROP TABLE IF EXISTS `voc_geo_countries`; CREATE TABLE `voc_geo_countries` ( `country_id` int(11) NOT NULL AUTO_INCREMENT, `country_english_name` varchar(255) DEFAULT NULL, `country_string` varchar(255) NOT NULL, `country_shortcut` varchar(255) NOT NULL, `continent_id` int(11) NOT NULL, `predial_id` int(11) NOT NULL, `street_setting` int(11) NOT NULL, PRIMARY KEY (`country_id`), UNIQUE KEY ÙQ_voc_geo_countries_country_id` (`country_id`), KEY ÌDX_voc_geo_continents` (`continent_id`), KEY ÌDX_voc_geo_predials` (`predial_id`), – 22 –


Příloha 10

CONSTRAINT `FK_voc_geo_countries_voc_geo_predials` FOREIGN KEY (`predial_id`) REFERENCES `voc_geo_predials` (`predial_id`), CONSTRAINT `FK_voc_geo_countries_voc_geo_continents` FOREIGN KEY (`continent_id`) REFERENCES `voc_geo_continents` (`continent_id`) ) ENGINE=InnoDB AUTO_INCREMENT=46 DEFAULT CHARSET=utf8; /*Data for the table `voc_geo_countries` */ insert into `voc_geo_countries`(`country_id`,`country_english_name`,`country_strin g`,`country_shortcut`,`continent_id`,`predial_id`,`street_setting`) values ('1','Albania','COU_AL','AL','5','1','0'), ('2','Andorre','COU_AND','AND','5','2','0'), ('3','Austria','COU_A','A','5','3','0'), ('4','Belgium','COU_B','B','5','4','0'), ('5','Belorussia','COU_BY','BY','5','5','0'),('6','BosniaHerzegovina','COU_BiH','BiH','5','6','0'), ('7','Bulgaria','COU_BG','BG','5','7','0'), ('8','Croatia','COU_HR','HR','5','8','0'), ('9','Cyprus','COU_CY','CY','5','9','0'),('10','Czech republic','COU_CZ','CZ','5','10','0'), ('11','Denmark','COU_DK','DK','5','11','0'), ('12','Estonia','COU_EW','EW','5','12','0'), ('13','Finland','COU_FIN','FIN','5','13','0'), ('14','France','COU_F','F','5','14','0'), ('15','FYROM','COU_MK','MK','5','15','0'), ('16','Germany','COU_D','D','5','16','0'),('17','Great Britain','COU_GB','GB','5','17','0'), ('18','Greece','COU_GR','GR','5','18','0'), ('19','Hungary','COU_H','H','5','19','0'), ('20','Iceland','COU_IS','IS','5','20','0'), ('21','Ireland','COU_IRL','IRL','5','21','0'), ('22','Italy','COU_I','I','5','22','0'), ('23','Latvia','COU_LV','LV','5','23','0'), ('24','Liechtenstein','COU_FL','FL','5','24','0'), ('25','Lithuania','COU_LT','LT','5','25','0'), ('26','Luxembourg','COU_L','L','5','26','0'), ('27','Malte','COU_M','M','5','27','0'), ('28','Moldavia','COU_MD','MD','5','28','0'), ('29','Monaco','COU_MC','MC','5','29','0'), ('30','Netherlands','COU_NL','NL','5','30','0'), ('31','Norway','COU_N','N','5','31','0'), ('32','Poland','COU_PL','PL','5','32','0'), ('33','Portugal','COU_P','P','5','33','0'), ('34','Romania','COU_RO','RO','5','34','0'), ('35','Russia','COU_RUS','RUS','5','35','0'),('36','SaintMarin','COU_RSM','RSM','5','36','0'),('37','Slovak republic','COU_SK','SK','5','37','0'), ('38','Slovenia','COU_SLO','SLO','5','38','0'), ('39','Spain','COU_E','E','5','39','0'), ('40','Sweden','COU_S','S','5','40','0'),

– 23 –


Příloha 10

('41','Switzerland','COU_CH','CH','5','41','0'), ('42','Turkey','COU_TR','TR','5','42','0'), ('43','Ukraine','COU_UK','UK','5','43','0'), ('44','Vatican','COU_V','V','5','44','0'), ('45','Yugoslavia','COU_YU','YU','5','45','0'); /*Table structure for table `voc_geo_countries_unions` */ DROP TABLE IF EXISTS `voc_geo_countries_unions`; CREATE TABLE `voc_geo_countries_unions` ( `country_union_id` int(11) DEFAULT NULL, `country_id` int(11) DEFAULT NULL, KEY ÌDX_voc_geo_countries` (`country_id`), KEY ÌDX_voc_geo_unions` (`country_union_id`), CONSTRAINT `FK_voc_geo_countries_unions_voc_geo_unions` FOREIGN KEY (`country_union_id`) REFERENCES `voc_geo_unions` (`country_union_id`), CONSTRAINT `FK_voc_geo_countries_unions_voc_geo_countries` FOREIGN KEY (`country_id`) REFERENCES `voc_geo_countries` (`country_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Table structure for table `voc_geo_currencies` */ DROP TABLE IF EXISTS `voc_geo_currencies`; CREATE TABLE `voc_geo_currencies` ( `currency_id` int(11) NOT NULL AUTO_INCREMENT, `currency_english_name` varchar(255) DEFAULT NULL, `currency_string` varchar(255) DEFAULT NULL, `currency_symbol_left` varchar(12) DEFAULT NULL, `currency_symbol_right` varchar(12) DEFAULT NULL, `currency_decimal_place` char(1) DEFAULT NULL, `currency_code` varchar(3) DEFAULT NULL, `country_id` int(11) DEFAULT NULL, PRIMARY KEY (`currency_id`), UNIQUE KEY ÙQ_voc_geo_currencies_currency_id` (`currency_id`), KEY ÌDX_voc_geo_countries` (`country_id`), CONSTRAINT `FK_voc_geo_currencies_voc_geo_countries` FOREIGN KEY (`country_id`) REFERENCES `voc_geo_countries` (`country_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Table structure for table `voc_geo_districts` */

– 24 –


Příloha 10

DROP TABLE IF EXISTS `voc_geo_districts`; CREATE TABLE `voc_geo_districts` ( `district_id` int(11) NOT NULL AUTO_INCREMENT, `district_name` varchar(255) DEFAULT NULL, `town_id` int(11) NOT NULL, `zipcode_id` int(11) NOT NULL, PRIMARY KEY (`district_id`), UNIQUE KEY ÙQ_voc_geo_districts_district_id` (`district_id`), KEY ÌDX_voc_geo_towns` (`town_id`), KEY ÌDX_voc_geo_zipcodes` (`zipcode_id`), CONSTRAINT `FK_voc_geo_districts_voc_geo_zipcodes` FOREIGN KEY (`zipcode_id`) REFERENCES `voc_geo_zipcodes` (`zipcode_id`), CONSTRAINT `FK_voc_geo_districts_voc_geo_towns` FOREIGN KEY (`town_id`) REFERENCES `voc_geo_towns` (`town_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Table structure for table `voc_geo_predials` */ DROP TABLE IF EXISTS `voc_geo_predials`; CREATE TABLE `voc_geo_predials` ( `predial_id` int(11) NOT NULL AUTO_INCREMENT, `predial_value_long` varchar(10) DEFAULT NULL, `predial_value_short` varchar(10) DEFAULT NULL, `predial_type` varchar(1) DEFAULT NULL, PRIMARY KEY (`predial_id`), UNIQUE KEY ÙQ_voc_geo_predials_predial_id` (`predial_id`) ) ENGINE=InnoDB AUTO_INCREMENT=87 DEFAULT CHARSET=utf8; /*Data for the table `voc_geo_predials` */ insert into `voc_geo_predials`(`predial_id`,`predial_value_long`,`predial_value_sh ort`,`predial_type`) values ('1','00355','+355','1'), ('2','00376','+376','1'),('3','0043','+43','1'), ('4','0032','+32','1'),('5','00357','+357','1'), ('6','00387','+387','1'),('7','00359','+359','1'), ('8','00385','+385','1'),('9','00357','+357','1'), ('10','00420','+420','1'),('11','0045','+45','1'), ('12','00372','+372','1'),('13','00358','+358','1'), ('14','0033','+33','1'),('15','00389','+389','1'), ('16','0049','+49','1'),('17','0044','+44','1'), ('18','0030','+30','1'),('19','0036','+36','1'),

– 25 –


Příloha 10

('20','00354','+354','1'),('21','00353','+353','1'), ('22','0039','+39','1'),('23','00371','+371','1'), ('24','004175','+4175','1'),('25','00370','+370','1'), ('26','00352','+352','1'),('27','00356','+356','1'), ('28','00373','+373','1'),('29','00377','+377','1'), ('30','0031','+31','1'),('31','0047','+47','1'), ('32','0048','+48','1'),('33','00351','+351','1'), ('34','0040','+40','1'),('35','007','+7','1'), ('36','00378','+378','1'),('37','00421','+421','1'), ('38','00386','+386','1'),('39','0034','+34','1'), ('40','0046','+46','1'),('41','0041','+41','1'), ('42','0090','+90','1'),('43','00380','+380','1'), ('44','0039','+39','1'),('45','00381','+381','1'),('46','','2','1'), ('47','','31','1'),('48','','41','1'),('49','','48','1'), ('50','','35','1'),('51','','49','1'),('52','','46','1'), ('53','','37','1'),('54','','38','1'),('55','','56','1'), ('56','','51','1'),('57','','58','1'),('58','','55','1'), ('59','','57','1'),('60','','601','2'),('61','','602','2'), ('62','','606','2'),('63','','607','2'),('64','','720','2'), ('65','','721','2'),('66','','722','2'),('67','','723','2'), ('68','','724','2'),('69','','725','2'),('70','','726','2'), ('71','','727','2'),('72','','728','2'),('73','','729','2'), ('74','','603','2'),('75','','604','2'),('76','','605','2'), ('77','','731','2'),('78','','732','2'),('79','','736','2'), ('80','','737','2'),('81','','739','2'),('82','','608','2'), ('83','','774','2'),('84','','775','2'),('85','','776','2'), ('86','','777','2'); /*Table structure for table `voc_geo_regions` */ DROP TABLE IF EXISTS `voc_geo_regions`; CREATE TABLE `voc_geo_regions` ( `region_id` int(11) NOT NULL AUTO_INCREMENT, `region_name` varchar(255) DEFAULT NULL, `region_shortcut` varchar(30) NOT NULL, `country_id` int(11) NOT NULL, `predial_id` int(11) NOT NULL, PRIMARY KEY (`region_id`), UNIQUE KEY ÙQ_voc_geo_regions_region_id` (`region_id`), KEY ÌDX_voc_geo_countries` (`country_id`), KEY ÌDX_voc_geo_predials` (`predial_id`), CONSTRAINT `FK_voc_geo_regions_voc_geo_predials` FOREIGN KEY (`predial_id`) REFERENCES `voc_geo_predials` (`predial_id`), CONSTRAINT `FK_voc_geo_regions_voc_geo_countries` FOREIGN KEY (`country_id`) REFERENCES `voc_geo_countries` (`country_id`) ) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;

– 26 –


Příloha 10

/*Data for the table `voc_geo_regions` */ insert into `voc_geo_regions`(`region_id`,`region_name`,`region_shortcut`,`country _id`,`predial_id`) values ('1','Hlavní město Praha','A','10','46'), ('2','Středočeský','S','10','47'),('3','Ústecký','U','10','48'), ('4','Liberecký','L','10','49'),('5','Karlovarský','K','10','50'), ('6','Královéhradecký','H','10','51'), ('7','Pardubický','E','10','52'),('8','Plzeňský','P','10','53'), ('9','Jihočeský','C','10','54'),('10','Vysočina','J','10','55'), ('11','Jihomoravský','B','10','56'),('12','Olomoucký','M','10','57'), ('13','Moravskoslezský','T','10','58'),('14','Zlínský','Z','10','59'); /*Table structure for table `voc_geo_streets` */ DROP TABLE IF EXISTS `voc_geo_streets`; CREATE TABLE `voc_geo_streets` ( `street_id` int(11) NOT NULL AUTO_INCREMENT, `street_name` varchar(255) DEFAULT NULL, `country_id` int(11) DEFAULT NULL, PRIMARY KEY (`street_id`), UNIQUE KEY ÙQ_voc_geo_streets_street_id` (`street_id`), KEY ÌDX_voc_geo_countries` (`country_id`), CONSTRAINT `FK_voc_geo_streets_voc_geo_countries` FOREIGN KEY (`country_id`) REFERENCES `voc_geo_countries` (`country_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Table structure for table `voc_geo_towns` */ DROP TABLE IF EXISTS `voc_geo_towns`; CREATE TABLE `voc_geo_towns` ( `town_id` int(11) NOT NULL AUTO_INCREMENT, `town_english_name` varchar(255) DEFAULT NULL, `town_local_name` varchar(255) NOT NULL, `region_id` int(11) NOT NULL, `country_id` int(11) NOT NULL, `predial_id` int(11) NOT NULL, `zipcode_id` int(11) NOT NULL, PRIMARY KEY (`town_id`), UNIQUE KEY ÙQ_voc_geo_towns_town_id` (`town_id`), KEY ÌDX_voc_geo_countries` (`country_id`), KEY ÌDX_voc_geo_predials` (`predial_id`), KEY ÌDX_voc_geo_regions` (`region_id`), – 27 –


Příloha 10

KEY ÌDX_voc_geo_zipcodes` (`zipcode_id`), CONSTRAINT `FK_voc_geo_towns_voc_geo_zipcodes` FOREIGN KEY (`zipcode_id`) REFERENCES `voc_geo_zipcodes` (`zipcode_id`), CONSTRAINT `FK_voc_geo_towns_voc_geo_countries` FOREIGN KEY (`country_id`) REFERENCES `voc_geo_countries` (`country_id`), CONSTRAINT `FK_voc_geo_towns_voc_geo_predials` FOREIGN KEY (`predial_id`) REFERENCES `voc_geo_predials` (`predial_id`), CONSTRAINT `FK_voc_geo_towns_voc_geo_regions` FOREIGN KEY (`region_id`) REFERENCES `voc_geo_regions` (`region_id`) ) ENGINE=InnoDB AUTO_INCREMENT=78 DEFAULT CHARSET=utf8; /*Data for the table `voc_geo_towns` */ insert into `voc_geo_towns`(`town_id`,`town_english_name`,`town_local_name`,`regio n_id`,`country_id`,`predial_id`,`zipcode_id`) values ('1',NULL,'Benešov','2','10','0','1'), ('2',NULL,'Beroun','2','10','0','2'), ('3',NULL,'Blansko','11','10','0','3'),('4',NULL,'Brnoměsto','11','10','0','4'),('5',NULL,'Brno-venkov','11','10','0','5'), ('6',NULL,'Bruntál','13','10','0','6'), ('7',NULL,'Břeclav','11','10','0','7'),('8',NULL,'Česká Lípa','4','10','0','8'),('9',NULL,'České Budějovice','9','10','0','9'),('10',NULL,'Český Krumlov','9','10','0','10'),('11',NULL,'Děčín','3','10','0','11'), ('12',NULL,'Domažlice','8','10','0','12'),('13',NULL,'FrýdekMístek','13','10','0','13'),('14',NULL,'Havlíčkův Brod','10','10','0','14'),('15',NULL,'Hlavní město Praha','1','10','0','15'),('16',NULL,'Hodonín','11','10','0','16'), ('17',NULL,'Hradec Králové','6','10','0','17'), ('18',NULL,'Cheb','5','10','0','18'), ('19',NULL,'Chomutov','3','10','0','19'), ('20',NULL,'Chrudim','7','10','0','20'),('21',NULL,'Jablonec nad Nisou','4','10','0','21'),('22',NULL,'Jeseník','12','10','0','22'), ('23',NULL,'Jičín','6','10','0','23'), ('24',NULL,'Jihlava','10','10','0','24'),('25',NULL,'Jindřichův Hradec','9','10','0','25'),('26',NULL,'Karlovy Vary','5','10','0','26'),('27',NULL,'Karviná','13','10','0','27'), ('28',NULL,'Kladno','2','10','0','28'), ('29',NULL,'Klatovy','8','10','0','29'), ('30',NULL,'Kolín','2','10','0','30'), ('31',NULL,'Kroměříž','14','10','0','31'),('32',NULL,'Kutná Hora','2','10','0','32'),('33',NULL,'Liberec','4','10','0','33'), ('34',NULL,'Litoměřice','3','10','0','34'), ('35',NULL,'Louny','3','10','0','35'), ('36',NULL,'Mělník','2','10','0','36'),('37',NULL,'Mladá Boleslav','2','10','0','37'),('38',NULL,'Most','3','10','0','38'), ('39',NULL,'Náchod','6','10','0','39'),('40',NULL,'Nový Jičín','13','10','0','40'),('41',NULL,'Nymburk','2','10','0','41'), ('42',NULL,'Olomouc','12','10','0','42'), ('43',NULL,'Opava','13','10','0','43'),('44',NULL,'Ostrava– 28 –


Příloha 10

město','13','10','0','44'),('45',NULL,'Pardubice','7','10','0','45'), ('46',NULL,'Pelhřimov','10','10','0','46'), ('47',NULL,'Písek','9','10','0','47'),('48',NULL,'Plzeňjih','8','10','0','48'),('49',NULL,'Plzeň-město','8','10','0','49'), ('50',NULL,'Plzeň-sever','8','10','0','50'),('51',NULL,'Prahavýchod','2','10','0','51'),('52',NULL,'Prahazápad','2','10','0','52'),('53',NULL,'Prachatice','9','10','0','53'), ('54',NULL,'Prostějov','12','10','0','54'), ('55',NULL,'Přerov','12','10','0','55'), ('56',NULL,'Příbram','2','10','0','56'), ('57',NULL,'Rakovník','2','10','0','57'), ('58',NULL,'Rokycany','8','10','0','58'),('59',NULL,'Rychnov nad Kněžnou','6','10','0','59'),('60',NULL,'Semily','4','10','0','60'), ('61',NULL,'Sokolov','5','10','0','61'), ('62',NULL,'Strakonice','9','10','0','62'), ('63',NULL,'Svitavy','7','10','0','63'), ('64',NULL,'Šumperk','12','10','0','64'), ('65',NULL,'Tábor','9','10','0','65'), ('66',NULL,'Tachov','8','10','0','66'), ('67',NULL,'Teplice','3','10','0','67'), ('68',NULL,'Trutnov','6','10','0','68'), ('69',NULL,'Třebíč','10','10','0','69'),('70',NULL,'Uherské Hradiště','14','10','0','70'),('71',NULL,'Ústí nad Labem','3','10','0','71'),('72',NULL,'Ústí nad Orlicí','7','10','0','72'),('73',NULL,'Vsetín','14','10','0','73'), ('74',NULL,'Vyškov','11','10','0','74'), ('75',NULL,'Zlín','14','10','0','75'), ('76',NULL,'Znojmo','11','10','0','76'),('77',NULL,'Žďár nad Sázavou','10','10','0','77'); /*Table structure for table `voc_geo_unions` */ DROP TABLE IF EXISTS `voc_geo_unions`; CREATE TABLE `voc_geo_unions` ( `country_union_id` int(11) NOT NULL AUTO_INCREMENT, `country_union_english_name` varchar(255) DEFAULT NULL, `country_union_string` varchar(255) DEFAULT NULL, PRIMARY KEY (`country_union_id`), UNIQUE KEY ÙQ_voc_geo_unions_country_union_id` (`country_union_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Table structure for table `voc_geo_zipcodes` */ DROP TABLE IF EXISTS `voc_geo_zipcodes`; CREATE TABLE `voc_geo_zipcodes` (

– 29 –


Příloha 10

`zipcode_id` int(11) NOT NULL AUTO_INCREMENT, `zipcode_text` varchar(255) NOT NULL, PRIMARY KEY (`zipcode_id`), UNIQUE KEY ÙQ_voc_geo_zipcodes_zipcode_id` (`zipcode_id`) ) ENGINE=InnoDB AUTO_INCREMENT=78 DEFAULT CHARSET=utf8; /*Data for the table `voc_geo_zipcodes` */ insert into `voc_geo_zipcodes`(`zipcode_id`,`zipcode_text`) values ('1','25765'),('2','26751'),('3','67904'),('4','61900'),('5','66491'), ('6','79351'),('7','69201'),('8','47301'),('9','37371'), ('10','38241'),('11','40502'),('12','34525'),('13','73901'), ('14','58001'),('15','19011'),('16','69633'),('17','50315'), ('18','35002'),('19','43001'),('20','53854'),('21','46843'), ('22','79001'),('23','50782'),('24','58601'),('25','37833'), ('26','36235'),('27','36471'),('28','73543'),('29','27371'), ('30','34201'),('31','28163'),('32','76701'),('33','28601'), ('34','46345'),('35','41186'),('36','44001'),('37','27724'), ('38','29401'),('39','43526'),('40','54701'),('41','74255'), ('42','28923'),('43','79351'),('44','74723'),('45','71100'), ('46','53002'),('47','39470'),('48','39811'),('49','34012'), ('50','30100'),('51','33101'),('52','25101'),('53','25401'), ('54','38301'),('55','79804'),('56','75101'),('57','26301'), ('58','27054'),('59','33824'),('60','51722'),('61','51101'), ('62','35709'),('63','38901'),('64','56802'),('65','78963'), ('66','39133'),('67','34901'),('68','41701'),('69','54232'), ('70','67544'),('71','68703'),('72','40002'),('73','56301'), ('74','75643'),('75','68501'),('76','76821'),('77','67161'); /*Enable Foreing key checks */ SET FOREIGN_KEY_CHECKS=1;

– 30 –


Příloha 11

Příloha 11

Zdrojový kód prototypu – index.php conn = mysql_connect($config['host'], $config['user'], $config['pass']); mysql_select_db($config['name']); } function query($query) { return mysql_query($query); } function fetch_array($res) { return mysql_fetch_array($res); } function fetch_row($res) { return mysql_fetch_row($res); } function fetch_all($res) { if ($res === false) return array(); if (mysql_num_rows($res) == 0) return array();

– 31 –


Příloha 11

while ($arr = mysql_fetch_array($res)) $ret[] = $arr; return $ret; } function __destruct() { mysql_close(); } } $db = new db_mysql($db_config); function compareContinent($a, $b) { return (strcoll($a['continent_czech_name'], $b['continent_czech_name'])); } function getContinents() { global $db, $lang; $res = $db->query('SELECT continent_id, continent_english_name, continent_string FROM voc_geo_continents'); $rows = $db->fetch_all($res); foreach ($rows as &$row) { $row['continent_czech_name'] = $lang['cs']['continents'] [$row['continent_string']]; } usort($rows, 'compareContinent'); return $rows; } function compareCountry($a, $b) { return (strcoll($a['country_czech_name'], $b['country_czech_name'])); }

– 32 –


Příloha 11

function getCountries() { global $db, $constraint, $lang; $query = 'SELECT country_id, country_english_name, country_string, country_shortcut, continent_id, predial_id, street_setting FROM voc_geo_countries'; if (isset($constraint['continent'])) $constraints[] = 'continent_id = "' . $constraint['continent'] . '"'; if (isset($constraints) && count($constraints)) $query .= ' WHERE ' . join(' AND ', $constraints); $res = $db->query($query); $rows = $db->fetch_all($res); foreach ($rows as &$row) { $row['country_czech_name'] = $lang['cs']['countries'] [$row['country_string']]; } usort($rows, 'compareCountry'); return $rows; } function getRegions() { global $db, $constraint; $query = 'SELECT region_id, region_name, region_shortcut, country_id, predial_id FROM voc_geo_regions'; if (isset($constraint['country'])) $constraints[] = 'country_id = "' . $constraint['country'] . '"'; if (isset($constraints) && count($constraints)) $query .= ' WHERE ' . join(' AND ', $constraints); $res = $db->query($query); return $db->fetch_all($res); }

– 33 –


Příloha 11

function getTowns() { global $db, $constraint; $query = 'SELECT town_id, town_english_name, town_local_name, region_id, country_id, predial_id, zipcode_id FROM voc_geo_towns'; if (isset($constraint['country'])) $constraints[] = 'country_id = "' . $constraint['country'] . '"'; if (isset($constraint['region'])) $constraints[] = 'region_id = "' . $constraint['region'] . '"'; if (isset($constraints) && count($constraints)) $query .= ' WHERE ' . join(' AND ', $constraints); $res = $db->query($query); return $db->fetch_all($res); } function addColumn() { $_POST['col'][] = array( 'name' => '', 'type' => '', 'continent' => '', 'country' => '', 'region' => '', 'town' => '' ); } function loadData() { global $continents, $countries, $regions, $towns; $continents = getContinents(); array_unshift($continents, array('continent_id' => '', 'continent_czech_name' => '')); $countries = getCountries(); if (count($countries) == 0) return; array_unshift($countries, array('country_id' => '', 'country_czech_name' => '')); $regions = getRegions(); – 34 –


Příloha 11

if (count($regions) == 0) return; array_unshift($regions, array('region_id' => '', 'region_name' => '')); $towns = getTowns(); array_unshift($towns, array('town_id' => '', 'town_local_name' => '')); } $colTypes = array( 'serial' => array('Pořadí', 'INT'), 'continent' => array('Kontinent', 'VARCHAR(15)', 'table' => 'voc_geo_continents', 'continent_id', 'col' => 'continent_string', 'alias' => 'con'), 'country' => array('Stát', 'VARCHAR(25)', 'table' => 'voc_geo_countries', 'country_id', 'col' => 'country_string', 'alias' => 'cou'), 'region' => array('Kraj', 'VARCHAR(15)', 'table' => 'voc_geo_regions', 'region_id', 'col' => 'region_name', 'alias' => 'reg'), 'town' => array('Město', 'VARCHAR(25)', 'table' => 'voc_geo_towns', 'town_id', 'col' => 'town_local_name', 'alias' => 'tow'), 'zipCode' => array('PSČ', 'INT', 'table' => 'voc_geo_zipcodes', 'zipcode_id', 'col' => 'zipcode_text', 'alias' => 'zip') ); function deleteColumn($colId) { array_splice($_POST['col'], $colId, 1); } function createInserts() { global $colTypes, $constraint, $db, $lang; foreach ($_POST['col'] as $colId => $col) { $colNames[] = $col['name']; switch ($col['type']) { case 'serial': $serial = true; continue 2; case 'continent': $colContinent = $colId; break; case 'country': – 35 –


Příloha 11

$colCountry = $colId; break; } $cols[] = $colTypes[$col['type']]['alias'] . '.' . $colTypes[$col['type']]['col']; } if (!isset($cols)) return; $query = 'SELECT DISTINCT ' . join(', ', $cols) . "\nFROM voc_geo_continents con, voc_geo_countries cou, voc_geo_regions reg, voc_geo_towns tow, voc_geo_zipcodes zip"; if (isset($constraint['continent'])) $constraints[] = 'con.continent_id = ' . $constraint['continent']; if (isset($constraint['country'])) $constraints[] = 'cou.country_id = ' . $constraint['country']; if (isset($constraint['region'])) $constraints[] = 'reg.region_id = ' . $constraint['region']; if (isset($constraint['town'])) $constraints[] = 'tow.town_id = ' . $constraint['town']; $constraints[] = 'con.continent_id = cou.continent_id'; $constraints[] = 'cou.country_id = reg.country_id'; $constraints[] = 'reg.region_id = tow.region_id'; $constraints[] = 'tow.zipcode_id = zip.zipcode_id'; $constraints[] = 'cou.country_id = reg.country_id AND reg.region_id = tow.region_id'; $query .= "\nWHERE " . join(' AND ', $constraints); if (isset($_POST['randomize'])) $query .= "\nORDER BY RAND() ASC"; $query .= "\nLIMIT " . LIMIT . ";\n\n"; $res = $db->query($query);

– 36 –


Příloha 11

$ret = array(); while ($arr = $db->fetch_row($res)) { if (isset($colContinent)) $arr[$colContinent - isset($serial)] = $lang['cs'] ['continents'][$arr[$colContinent - isset($serial)]]; if (isset($colCountry)) $arr[$colCountry - isset($serial)] = $lang['cs'] ['countries'][$arr[$colCountry - isset($serial)]]; $ret[] = $arr; } $cols = join('`, `', $colNames); foreach ($ret as $i => $row) print 'INSERT INTO `' . $_POST['tableName'] . '` (`' . $cols . '`) VALUES (' . (isset($serial) ? ($i + 1) . ', ' : '') . '"' . join('", "', $row) . "\");\n"; } function scanCols() { global $constraint; // determine constraints and remove duplicated cols or those scheduled for removal foreach ($_POST['col'] as $colId => $col) { $duplicated = isset($usedColTypes[$col['type']]); $chosenToRemove = $_POST['mode'] == 'removeColumn' && $_POST['colId'] == $colId; if ($duplicated || (!$duplicated && $chosenToRemove)) deleteColumn($colId); switch ($col['type']) { case 'continent': if ($col['continent'] != '') $constraint['continent'] = $col['continent']; break; case 'country': if ($col['country'] != '') $constraint['country'] = $col['country']; break; case 'region':

– 37 –


Příloha 11

if ($col['region'] != '') $constraint['region'] = $col['region']; break; case 'town': if ($col['town'] != '') $constraint['town'] = $col['town']; break; case 'serial': if ($colId <> 0) $serialCol = $colId; } $usedColTypes[$col['type']] = true; } if (isset($serialCol)) { $tmp = $_POST['col'][0]; $_POST['col'][0] = $_POST['col'][$serialCol]; $_POST['col'][$serialCol] = $tmp; } } function createTable() { global $colTypes; print 'CREATE TABLE `' . $_POST['tableName'] . "` (\n"; foreach ($_POST['col'] as $colId => $col) { if ($col['type'] == '') continue; print "\t`" . $col['name'] . '` ' . $colTypes[$col['type']] [1] . ",\n"; } if ($_POST['col'][0]['type'] == 'serial') { print "\tPRIMARY KEY (`" . $_POST['col'][0]['name'] . "`),\n"; $autoIncrement = ' AUTO_INCREMENT=' . (LIMIT + 1); } print ")" . (isset($autoIncrement) ? $autoIncrement : '') . ";\n\n"; }

– 38 –


Příloha 11

if (isset($_POST['col'])) scanCols(); if (!isset($_POST['col'])) { addColumn(); } else if (($_POST['mode'] == 'addColumn' && count($_POST['col']) < 6) || count($_POST['col']) == 0) { addColumn(); } loadData(); ?> Prototyp: Generátor dat pro testování databázových aplikací <meta name="author" content="Bc. Jan Pňakovič"/> <meta http-equiv="content-type" content="text/html; charset=UTF-8"/> <script type="text/javascript"> function choose_column_type(id) { continent = document.getElementById("colContinent" + id); country = document.getElementById("colCountry" + id); region = document.getElementById("colRegion" + id); town = document.getElementById("colTown" + id); continent.style.display = "none"; country.style.display = "none"; region.style.display = "none"; town.style.display = "none"; switch (document.getElementById("colType" + id).value) { case "continent": continent.style.display = "inline"; break; case "country": country.style.display = "inline"; break; case "region": region.style.display = "inline";

– 39 –


Příloha 11

break; case "town": town.style.display = "inline"; break; } } function choose_constraint() { document.getElementById("mode").value = "constraint"; document.getElementById("columnCreator").submit(); } function add_column() { document.getElementById("mode").value = "addColumn"; document.getElementById("columnCreator").submit(); } function delete_column(colId) { document.getElementById("mode").value = "removeColumn"; document.getElementById("colId").value = colId; document.getElementById("columnCreator").submit(); } function generate() { document.getElementById("mode").value = "generate"; document.getElementById("columnCreator").submit(); }
Prototyp generátoru dat


Příloha 11

foreach ($_POST['col'] as $colId => $col) { ?>

Název sloupce Druh dat Volby

<select name="col[][type]" id="colType" onchange="choose_column_type()"> $colType) { if (isset($usedColTypes[$id])) continue; print "\t\t\t\n"; if ($col['type'] == $id) $usedColTypes[$id] = true; } ?> <select name="col[][continent]" id="colContinent" style="display: " onchange="choose_constraint()"> <select name="col[][country]" id="colCountry" style="display: " onchange="choose_constraint()"> <select name="col[][region]" id="colRegion" style="display:
– 41 –


Příloha 11

isset($col['type']) && $col['type'] == 'region' ? 'inline' : 'none'; ? >" onchange="choose_constraint()"> <select name="col[][town]" id="colTown" style="display: " onchange="choose_constraint()">

Název tabulky:
id="createTable"/>Vypsat CREATE TABLE id="randomize"/>Zamíchat

<pre>

– 42 –


Příloha 11

– 43 –

Generátor dat pro testování databázových aplikací

Recommend Documents

Prototyp generátoru dat