Na tomto místě bude oficiální zadání vaší práce

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

Download "Na tomto místě bude oficiální zadání vaší práce"

Transkript

1 Na tomto místě bude oficiální zadání vaší práce Toto zadání je podepsané děkanem a vedoucím katedry, musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí, v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě). i

2 ii

3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce Bakalářská práce Implementační rozdíly ve vývoji IS při použití bezschémové a relační databáze Antonín Daněk Vedoucí práce: Ing. Martin Kákona Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia 25. května 2011

4 iv

5 v Poděkování Chtěl bych poděkovat především rodičům, za umožnění studia a tedy i napsání této práce. Dále také sestře za konzultace gramatické stránky práce a přátelům, kteří tolerovali značné omezení mého volného času. Děkuji také vedoucímu mé bakalářské práce Ing. Martinu Kákonovi, za jeho konzultace a benevolentní přístup.

6 vi

7 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

8 viii

9 Abstract This thesis addresses comparison of a typical relational database with non-relational one while it focuses on non-relational database MongoDB. The practical result of the work is an information system based on Google Maps. Realization of the system is also described in the work. This system is used to demonstrate how the implementation for individual databases vary, and it is also shown how to minimize these differences. Abstrakt Tato bakalářská práce se zabývá srovnáním typické relační databáze s databází bezschémovou, detailněji se při tom zaměřuje na bezschémovou databázi MongoDB. Praktickým výsledkem práce je informační systém založený na Google Maps, jehož realizace je v práci též popsána. Na tomto systému je demonstrováno, jak se implementace pro jednotlivé databáze liší a též je ukázána cesta, jak tyto odlišnosti minimalizovat. ix

10 x

11 Obsah 1 Úvod Struktura bakalářské práce Popis problému, specifikace cíle Požadavky Funkční požadavky Požadavky týkající se uživatele Požadavky týkající se pozorovacích míst a událostí Ostatní funkční požadavky Nefunkční požadavky Srovnání existujících řešení Řešení v českém jazyce astro.cz astro-forum.cz astronomie.cz vesmir.info Řešení v anglickém jazyce xi

12 xii OBSAH astronomy.com ostatní Analýza technologií pro implementaci Diskuse relačních a bezschémových databází Úvod do bezschémových databází MongoDB Vlastnosti MongoDB Denormalizovaná databáze Rychlost Škálovatelnost Základní příkazy Vkládání dat Čtení dat Upravování dat Mazání dat Srovnání relačních a bezschémových databází Množství dat Rychlost a horizontální škálování Křivka učení, rozšířenost a dospělost Dostupnost a cena Flexibilní schéma a interakce s daty Transakce Normalizace dat a konzistence Výběr technologií pro implementaci

13 OBSAH xiii Výběr hlavní databáze Výběr ostatních technologií Realizace Model-View-Controller Model Zaměnitelnost datové vrstvy Připojení k MySQL Připojení k MongoDB Business objekty View Controller Implementace Data Access Objektů Implementace DAO pro MySQL Metoda getspotscreatedby Metoda createnewuser Metoda addattendingusertoevent Implementace DAO pro MongoDB Metoda getspotscreatedby Metoda createnewuser Metoda addattendingusertoevent Některé další prvky implementace Formuláře Životní cyklus formulářů

14 xiv OBSAH Dynamicky generovaný JavaScript Dynamicky generované XML Práce s Google Maps zobrazení značek na mapě Vložení značky na mapu Práce s GPS souřadnicemi Načítání nejbližších pozorovacích míst AJAX Komponenty jquery Tvorba multimediálních záznamů z pozorování Obrázky YouTube videa Profilové fotografie popup okna a cache Ukládání hesel Model nasazení Testování Akceptační test Test validity HTML Test kognitivním průchodem Založení nového místa Založení nové události na určitém místě Přidání místa mezi oblíbené Přidání komentáře k pozorovacímu místu Přidání záznamu z pozorování k události

15 OBSAH xv Přihlášení se k účasti u události Uložení výchozí pozice mapy Výsledky kognitivních průchodů Závěr Shrnutí výsledků a zhodnocení splnění cílů Srovnání relačních a bezschémových databází Implementace informačního systému pro JihoČAS Rozdíly v implementaci při použití bezschémové databáze Otestování implementovaného systému Zhodnocení přínosu práce Zamyšlení se nad použitelností bezschémových databází Další možné pokračování práce A Seznam použitých zkratek 45 B UML diagramy 47 C Ukázky zdrojových kódů 49 D Výsledky akceptačního testu 57 E Instalační a uživatelská příručka 61 E.1 Instalační příručka E.1.1 PHP + MySQL E.1.2 MongoDB E.1.3 Nahrání souborů na server

16 xvi OBSAH E.1.4 Konfigurace aplikace E.2 Uživatelská příručka E.2.1 Administrace F Obsah přiloženého CD 65

17 Seznam obrázků 2.1 Ukázka obsahu a UI webu astro-forum.cz kategorie Astronomická setkání Přibližné zobrazení závislosti výkonu na funkcionalitě čtyř systémů - zdroj: [21] Znázornění, jak jednotlivé SQL funkce odpovídají nástroji MapReduce zdroj: [19] UML diagram pro DaoFactory a jím vracené DAO objekty (z úsporných důvodů je zobrazeno pouze několik DAO tříd a pouze některé metody) UML diagram systému controllerů (z úsporných důvodů jsou zobrazeny pouze některé) UML diagram modelu nasazení B.1 Grafické znázornění adresářové struktury aplikace E.1 Ukázka úvodní stránky aplikace E.2 Ukázka profilové stránky uživatele E.3 Ukázka stránky pozorovacího místa E.4 Ukázka stránky události xvii

18 xviii SEZNAM OBRÁZKŮ

19 Seznam tabulek 3.1 Různé typy bezschémových databází. Tabulka čerpá především z článku [23] Výsledky testu rychlosti vložení milionu záznamů (každý záznam měl tři hodnoty včetně generovaného ID) na stolním počítači. [3] Základní komponenty databází MySQL a MongoDB, které sobě přibližně odpovídají D.1 Akceptační test požadavků týkajících se uživatele D.2 Akceptační test požadavků týkajících se pozorovacích míst a událostí D.3 Akceptační test ostatních požadavků xix

20 xx SEZNAM TABULEK

21 Kapitola 1 Úvod Lidé, zabývající se astronomií (ať už amatérsky či profesionálně), jsou poměrně decentralizovaní. Často se tak stává, že ten samý objekt pozorují jednotliví astronomové odděleně, připravujíce se tak o sociální prvky takových událostí a možnost sdílet vybavení či znalosti. V horším případě právě z důvodu absence vybavení nepozorují vůbec. Především výše zmíněné bylo motivací k vytvoření informačního systému (sociální sítě), který bude astronomům pomáhat organizovat pozorování. Současně se práce zabývá srovnáním bezschémových databází s relačními, a to především z pohledu implementace aplikace. V současnosti zaznamenává velký rozvoj tzv. cloud computing 1 a distribuované služby. Pokud chceme cloud využít, obvykle se nevyhneme také bezschémovým databázím. Mnoho programátorů má však z opuštění ověřených relačních databází obavy. Jedním z cílů této práce je zjistit, zda jsou tyto obavy oprávněné. Práce popisuje všechny fáze tvorby systému od specifikace cíle, přes technologickou analýzu a samotnou implementaci, až po otestování a zhodnocení výsledků. 1 Cloud computing je definovaný především poskytováním zdrojů (jako je výpočetní výkon či datový prostor) na požádání. Jednou z výhod tohoto přístupu je, že provozovatel aplikace platí pouze za výkon, jaký jeho aplikace opravdu využívá a navíc růst počtu uživatelů a s ním požadavek na více výkonu nepředstavuje problém. 1

22 2 KAPITOLA 1. ÚVOD 1.1 Struktura bakalářské práce V kapitole Popis problému, specifikace cíle (2) je popsán řešený problém a především jsou zde specifikovány funkční i nefunkční požadavky na výsledný systém. Dále se zde nachází analýza současných řešení stejného problému. V následující kapitole Analýza technologií pro implementaci (3) je čtenář nejdříve uveden do základů relačních a bezschémových databází. Základní informace jsou následovány srovnáním obou databází a výběrem hlavní databáze pro implementaci. Kromě databáze je proveden i výběr dalších technologií. Navazuje kapitola Realizace (4), která tvoří spolu s analýzou nejdůležitější část práce. Kromě ostatních důležitých částí zdrojového kódu, ukazuje rozdílnost implementace systému pro relační a pro bezschémovou databázi. Testování aplikace je zdokumentováno v kapitole Testování (5). Především je zde akceptačním testem ověřeno splnění všech požadavků. Navazuje ověření validnosti výstupu systému a několik testů provedených kognitivním průchodem. Zhodnocení práce spolu s možnostmi dalšího rozšíření systému je možno nalézt v poslední kapitole Závěr (6).

23 Kapitola 2 Popis problému, specifikace cíle Cílem projektu je vytvořit webovou aplikaci pro Jihočeskou pobočku České astronomické společnosti s využitím Google Maps (http://code.google.com/apis/maps/index.html). Aplikace bude sloužit jako mezičlánek pro amatérské a profesionální astronomy. Lidé se budou moci scházet na vytvořených pozorovacích místech a mimo jiné tak sdílet své vybavení. V aplikaci pak bude možné monitorovat, kdo se pozorovací události bude účastnit (účastní se) a na závěr podat z pozorování hlášení, které může být obohacené multimedii. Podrobněji viz Funkční požadavky (2.1.1). Současně je cílem zhodnotit výhody a nevýhody relačních a bezschémových databází pro implementaci tohoto systému a zjistit, jak složité je přizpůsobení systému pro jeden či druhý databázový stroj. 2.1 Požadavky Dále jsou uvedeny funkční a nefunkční požadavky na systém Funkční požadavky Požadavky týkající se uživatele 1. Systém bude umožňovat registraci nového uživatele. O úspěšné registraci bude systém uživatele informovat em. 2. Systém bude umožňovat přihlášení a odhlášení uživatele. 3. Neregistrovaný uživatel bude mít omezená práva. Bude si moci pouze pasivně prohlížet veřejný obsah. 4. Profil uživatele bude obsahovat fotografii, historii navštívených událostí, seznam oblíbených pozorovacích míst, seznam založených pozorovacích míst, seznam privátních pozorovacích míst a nastavení odebíraných informací o místech. 5. Registrovaný uživatel si bude moci přidat pozorovací místo mezi svá oblíbená místa. 3

24 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 6. Registrovaný uživatel si bude moci nastavit preferovanou úroveň přiblížení a výchozí pozici mapy (domácí souřadnice). 7. Registrovaný uživatel bude moci vytvářet pozorovací místa. 8. Registrovaný uživatel bude moci vytvářet události (i na místech, které sám nezaložil, pokud je toto místo veřejné nebo pokud je místo privátní, ale uživatel je v seznamu privátních pozorovatelů tohoto místa). 9. Registrovaný uživatel se bude moci přihlásit k odběru informací o událostech na pozorovacích místech (např. založení nové události). 10. Registrovaný uživatel dostane za každých 10 návštěv pozorovacích míst (jiných, než těch, které sám vytvořil) jeden volný bod hodnocení. Tento bod hodnocení může registrovaný uživatel použít ke zlepšení hodnocení pozorovacího místa. 11. Každá navštívená událost registrovaného uživatele bude zaznamenávána. Součet těchto návštěv bude odpovídat uživatelovo osobnímu hodnocení (karma). 12. Registrovaný uživatel se bude moci přihlásit k události se stavy: Možná se zúčastním, zúčastním se, jsem na místě, ale nepozoruji, jsem na místě a pozoruji Požadavky týkající se pozorovacích míst a událostí 1. Pozorovací místo bude obsahovat popis, zeměpisné souřadnice, datum založení, zakladatele, komentáře registrovaných uživatelů a seznam událostí na tomto místě. 2. Událost bude obsahovat popis, pozorovací místo, datum založení, zakladatele, seznam účastníků a hlášení z pozorování. 3. Pozorovací místa budou privátní a veřejná. Privátní pozorovací místa budou viditelná pouze pro vyjmenované pozorovatele. Veřejná místa budou viditelná pro všechny. 4. Vyjmenovat pozorovatele privátního místa bude moci pouze jeho zakladatel. 5. K pozorovacímu místu bude moci registrovaný uživatel přidat komentář. 6. Všichni účastníci události budou moci k této události přidat multimediální hlášení, do kterého bude možné přidávat videa z YouTube (http://youtube.com/) a obrázky Ostatní funkční požadavky 1. V systému budou pozorovací místa a události. Události lze vytvořit pouze na pozorovacích místech. 2. Google Mapa bude zobrazovat pozorovací místa. 3. Na Google Mapě budou odlišena (zvýrazněna) ta pozorovací místa, kde právě někdo pozoruje.

25 2.2. SROVNÁNÍ EXISTUJÍCÍCH ŘEŠENÍ 5 4. Otevřený detail (bublina v Google maps) pozorovacího místa na mapě bude obsahovat aktuální pozorování. 5. Úvodní stránka bude obsahovat seznam pozorovacích míst, setříděných podle vzdálenosti od aktuálního středu zobrazené mapy. 6. Vedle mapy bude tlačítko pro přechod na domácí souřadnice. 7. Systém bude nabízet sérii ikon pro různé druhy objektů na mapě. 8. Systém bude obsahovat tři role: neregistrovaný uživatel, registrovaný uživatel a administrátor. 9. Administrátor bude moci archivovat pozorovací místa. 10. Administrátor bude mít práva pro přístup do všech pozorovacích míst, včetně těch privátních Nefunkční požadavky 1. K systému se bude přistupovat přes webové rozhraní. 2. Systém bude implementovaný v jazyce PHP. 3. Systém bude pro klienty nezávislý na platformě. 4. Systém bude možné co nejjednodušeji rozšiřovat. 5. Systém bude jednoduchý na používání. 2.2 Srovnání existujících řešení Pokusil jsem se na internetu nalézt co nejvíce podobných řešení, nicméně aplikace, která by pomáhala lidem jednoduše organizovat menší i větší pozorovací události, zřejmě neexistuje (nenalezl jsem takovou) Řešení v českém jazyce astro.cz Na webu ČAS (http://www.astro.cz/) (pro jejíž Jihočeskou pobočku systém vyvíjím) se objevují aktuální informace nejen o tom, co je možné na obloze pozorovat. Není zde však pro uživatele žádná možnost, jak se navzájem kontaktovat a už vůbec ne nástroj pro organizaci takovýchto akcí. V sekci akce jsou některé události vypisovány, takže setkání možné je, nicméně jedná se pouze o události významné, kterých bývá jen několik do roka. Navíc zde není pro uživatele žádný prvek interakce, jde pouze o pasivní příjem informace od správců webu.

26 6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE astro-forum.cz Astronomické fórum (http://www.astro-forum.cz/) nabízí uživatelům interakci mezi sebou formou odpovědí na své příspěvky (a zakládáním nových témat). Navíc má pro pozorování a podobné akce vyhrazenou kategorii Astronomická setkání. Fórum je hostováno na serveru ČAS, ale není jeho přímou součástí. Diskusní fórum nabízí určitou možnost zorganizovat společné pozorování, není však pro tento typ úkolu dostatečně přehledné a názorné. Nový potenciální pozorovatel např. nemůže snadno zjistit (bez přečtení celého vlákna), kdo se bude události účastnit, kde konkrétně bude apod. Obrázek 2.1: Ukázka obsahu a UI webu astro-forum.cz kategorie Astronomická setkání astronomie.cz Virtuální trpaslík (http://www.astronomie.cz/) s podtitulem Amatérská prohlídka oblohy stejně jako astro.cz poskytuje aktuální informace z prostředí Astronomie (některé zprávy přebírá z RSS kanálu ČAS, ale i dalších webů). U lokálních článků se dá komunikovat formou komentářů, nicméně toto není vhodné místo pro organizaci pozorovacích událostí. Virtuální trpaslík svým uživatelům nabízí kromě informací i několik komunikačních kanálů Facebook stránku (http://www.facebook.com/astronomiecz), uživatelské blogy a Twitter (http://twitter.com/astronomiecz). K organizaci událostí by se dalo využít diskusní fórum Facebook stránky, ale se stejnými nevýhodami (o něco zesílenými z důvodu ne příliš vhodné integrace na Facebooku), jako v případě Astronomického fóra.

27 2.2. SROVNÁNÍ EXISTUJÍCÍCH ŘEŠENÍ vesmir.info Poslední aktualita webu vesmir.info (http://www.vesmir.info/) je téměř dva roky stará, web již tedy pravděpodobně přerušil svou činnost. Nicméně v době, kdy aktivní byl, se v sekci Obloha pozorování objevovaly tipy na pozorování a pod těmito tipy bylo možné diskutovat Řešení v anglickém jazyce astronomy.com Web astronomy.com (http://www.astronomy.com/) stojí za oblíbeným magazínem Astronomy a nabízí organizátorům akcí na svém webu (a zřejmě i v magazínu samotném) vypisovat události, které pořádají. Jedná se většinou o větší akce, jako jsou např. konference, exhibice, kempování či přednášky. Web nabízí i diskusní fórum, ale žádný nástroj určený k organizování setkání pozorovatelů oblohy zde není ostatní Existuje mnoho zdrojů, které nabízí informace o aktuálním dění ve viditelném vesmíru kolem nás. Mezi takovými je např.: NASA Space Calendar (http://www2.jpl.nasa.gov/calendar/) The Calendar-Sky (http://www.calsky.com/cs.cgi/calendar) AAS Calendar (http://aas.org/calendar) Sea and Sky Astronomy Calendar (http://www.seasky.org/astronomy/astronomy-calendar-current.html) Žádný z nich však nenabízí možnost pro uživatele, jak se mezi sebou dohodnout na společném pozorování ze stejného místa. Kromě pasivních poskytovatelů informací pak existují diskusní fóra. Mimo výše uvedeného astronomy.com, je dobrým příkladem např. Jak již však bylo řečeno, diskusní fóra nejsou ideálním nástrojem pro organizaci pozorovacích událostí.

28 8 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

29 Kapitola 3 Analýza technologií pro implementaci V této kapitole jsou diskutovány výhody a nevýhody dvou významných zástupců z řady bezschémových a relačních databází. V první řadě je uveden princip fungování NoSQL databáze. Následuje srovnání obou databází a je proveden výběr jedné z nich pro finální implementaci aplikace. 3.1 Diskuse relačních a bezschémových databází Jako zástupce bezschémové databáze jsem vybral MongoDB, jejíž autorem je firma 10gen (http://www.10gen.com/). Zástupcem relačních databází v této práci bude MySQL Úvod do bezschémových databází MongoDB Tato část bakalářské práce obsahuje vlastnosti konkrétní databáze MongoDB, ale mnoho zmiňovaného platí obecně pro většinu NoSQL databází. Tuto podkapitolu píši především proto, aby si čtenář mohl udělat základní obrázek o bezschémových databázích. Vycházím z faktu, že bezschémové databáze jsou pro mnoho lidí novou věcí, kterou neznají. Naopak základy relačních SQL databází jsou pro případné čtenáře této poměrně specificky zaměřené bakalářské práce známé. Z toho důvodu sekci uvádějící základy relačních databází záměrně vynechávám. MongoDB je škálovatelná databáze s vysokým výkonem a je považována za spojnici mezi klíč/hodnota databázemi a klasickými RDBMS systémy. Je tomu tak především proto, že MongoDB je robustní jako jednoduchá klíč/hodnota databáze, ale rychlá jako Memcached 1, při zachování funkcí srovnatelných s RDBMS systémy, což je symbolicky zobrazeno na obrázku 3.1. [21] Existuje několik druhů bezschémových databází, z nichž nejvíce zastoupené jsou zmíněny v tabulce Memcached je obecný systém pro cachování dat do paměti. Často používaný právě v oblasti databází jako mezivrstva za účelem zvýšení rychlosti. [16] 9

30 10 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI Typ databáze Poznámka úložiště typu klíč/hodnota Příkladem takového úložiště je např. Azure Table Storage od společnosti Microsoft (http://www.microsoft.com/) nebo SimpleDB od společnosti Amazon (http://www.amazon.com/). tabulkové úložiště Tyto úložiště mají pevně definované struktury tabulek, ne však relace mezi nimi. Příkladem je Cassandra (http://cassandra.apache.org/) (úložiště bylo vyvinuto a uvolněno pod licencí Open Source ve společnosti Facebook) nebo Hypertable (http://www.hypertable.org/). úložiště dokumentů Příkladem je MongoDB CouchDB (http://couchdb.apache.org/) nebo Riak (http://wiki.basho.com/). úložiště objektů Velmi podobné úložišti dokumentů. Rozdíl je především v tom, že schéma je zde pevně určeno, je definována hierarchie dědičností a místo vkládání dokumentů do sebe se zde používají pointery mezi objekty. Příkladem je databáze db4objects (http://www.db4o.com/). Tabulka 3.1: Různé typy bezschémových databází. Tabulka čerpá především z článku [23].

31 3.1. DISKUSE RELAČNÍCH A BEZSCHÉMOVÝCH DATABÁZÍ 11 Obrázek 3.1: Přibližné zobrazení závislosti výkonu na funkcionalitě čtyř systémů - zdroj: [21]. Bezschémové databáze (často také nazývané jako strukturovaná úložiště) nemají pevně dané schéma dat, jako je tomu u relačních SQL databází. Díky tomu je možné bez nutnosti složitých změn struktury dat u jednotlivých záznamů přidávat či ubírat klíče a změny ošetřit na úrovni aplikace Vlastnosti MongoDB MongoDB a ani žádné jiné databáze nelze považovat za univerzální řešení všech problémů. Má však vlastnosti a funkce potřebné u většiny projektů. Ke komunikaci s MongoDB je používán bohatý a široce známý jazyk JavaScript, formát pro ukládání dokumentů je obecný JSON. MongoDB nabízí širokou škálu základních datových typů, blíže je možné se s nimi seznámit v knize [12] na stranách Databáze je velmi rychlá detailněji viz

32 12 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI Díky podpory shardingu 2 umožňuje horizontální škálování. Protože se jedná o dokumentově orientovanou bezschémovou databázi, má flexibilní datový model. Databázi je možné snadno replikovat a díky tomu mít záložní databáze např. pro případy výpadku hlavní databáze (failover). Data je možné indexovat. MongoDB je ve srovnání s MySQL velmi lightweight (jednoduchý systém). Klíč/hodnota páry databáze MongoDB jsou citlivé na datové typy, velikost písmen a jsou také seřazené. Použijeme-li tedy v názvu či hodnotě jinou velikost písma, jiný datový typ hodnoty či změníme pořadí klíčů, bude se jednat o jiné dokumenty. Dokument také nesmí obsahovat duplicitní klíče Denormalizovaná databáze Častým argumentem proti bezschémovým databázím, je denormalizace dat 3, ke které zde (nikoliv však nezbytně) obvykle dochází. Karel Minařík ve své přednášce na WebExpo 2010 [11] (http://webexpo.cz/) upozorňuje, že mnoho aspektů reálného světa neodpovídá normalizovanému obrazu. Myšlenku opírá o příklad fakturačního systému, kde při změně adresy dojde vlivem normalizace dat ke změně adres na všech fakturách a tím dojde ke znehodnocení starých faktur (adresa musí zůstat stejná, jaká byla v době vystavení). Také v článku [23] jsou uvedeny protiargumenty na téma normalizace dat: 1. Argument: Ušetření datového prostoru Protiargument: Žijeme v době, kdy datový prostor je velmi levný a představuje až ten poslední problém. 2. Argument: Normalizovaná data je možné upravovat na jednom místě Protiargument: Pravdou je, že většinu dat nepotřebujeme měnit, anebo jen velmi zřídka. Na druhou stranu pokud použijeme normalizovaný model, operaci spojování dat musíme provádět pokaždé, kdy o ně někdo požádá. 3. Argument: Potřebujeme many-to-many relace Protiargument: Je uveden příklad knihovny. Máme knihu, kterou si může půjčit více lidí a osobu, která si může půjčit několik knih. Problém se dá vyřešit snadno, za cenu denormalizace dat k osobě si uložíme všechny knihy, které si půjčila a ke knize všechny osoby. Za předpokladu, že ke změně informací jako je název knihy či jméno osoby dochází zřídka, denormalizace nepředstavuje problém a přináší nezanedbatelné výhody v podobě ušetření místa na vztahových tabulkách a především ušetření výkonu, díky nepoužití operací spojení (JOIN). 2 Sharding je metoda horizontálního dělení databáze, která umožňuje rozdělení dat mezi jednotlivé stroje po řádcích (dokumentech, záznamech,... ). 3 Opakem je normalizace dat, která se snaží odstranit nadbytečné informace, sémanticky oddělit data a vytvořit mezi těmito daty dobře definované relace.

33 3.1. DISKUSE RELAČNÍCH A BEZSCHÉMOVÝCH DATABÁZÍ 13 Databáze Čas MongoDB unsafe 76,911s MyISAM 231,695s MongoDB safe 232,042s InnoDB 533,430s Tabulka 3.2: Výsledky testu rychlosti vložení milionu záznamů (každý záznam měl tři hodnoty včetně generovaného ID) na stolním počítači. [3] Nabízí se otázka, proč vůbec dělit data do více kolekcí, máme-li databázi bez pevného schématu. Důvodů je několik, ale především bychom neměli zneužívat flexibility, jaká je nám bezschémovými databázemi nabízena, k vytvoření chaosu. Hlavní důvod je tedy udržení určitého pořádku a čitelnosti pro programátory. Ze stejného důvodu je vhodné používat pro pojmenování kolekcí tečkovou konvenci (např. blog.posts či blog.posts.comments), ačkoliv tím fyzicky není vyjádřena žádná spojitost. Dalším důvodem je rychlost. Pokud bychom si typy různých dat (řekněme např. komentáře a články) oddělovali hodnotou určitého atributu, rychlost výběru dat z takové jedné univerzální kolekce by byla menší, než při rozdělení do více kolekcí. V neposlední řadě pak oddělením do kolekcí získáváme lepší indexovatelnost dat Rychlost Je všeobecně známo, že bezschémové databáze jsou výrazně rychlejší, než ty relační. Tato skutečnost je však způsobená z velké části tím, že bezschémové databáze často nezajišťují durability 4. Jinak řečeno data zapisují pouze do paměti a bezpečně uchovávají na disk až po určitém čase (např. jednou za minutu). [24] Test rychlosti (ačkoliv neprofesionální) vkládání dat provedl např. Artur Ejsmont. Své výsledky, jejichž část je možné vidět v tabulce 3.2, prezentoval ve svém článku [3] Škálovatelnost Škálovatelnost je vlastnost umožňující zvyšování (ale i snižování) výkonu stroje, především za účelem poskytnutí služeb více klientům a možnost pracovat s větším množstvím dat (v případě databází). Existují dva základní způsoby, jakými lze databáze škálovat - horizontální a vertikální. Vertikální škálování probíhá v rámci jednoho fyzického stroje. V praxi může vypadat např. tak, že se současný server rozšíří o další paměťový modul. Problém tohoto přístupu je především cena (velmi výkonný stroj je mnohem dražší, než více méně výkonných), ale také fakt, že tento způsob má určitý limit (jeden stroj nelze donekonečna rozšiřovat). Horizontální škálování neboli rozšiřování do šířky naopak uvažuje rozšíření systému o více strojů a rozdělení práce mezi ně. 4 Durability je jedna z vlastností ACID systémů, která garantuje, že jednou odeslaná transakce bude zachována, i kdyby následovala závažná chyba typu výpadek proudu.

34 14 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI MongoDB nativně nabízí podporu pro horizontální škálování. Pokud je potřeba větší výkon, lze do stávajícího systému zapojit další MongoDB server Základní příkazy show dbs vypíše seznam všech databází use foobar přepne do databáze s názvem foobar db vypíše název aktuální databáze show collections vypíše seznam všech kolekcí v aktuální databázi db.runcommand({getlasterror:1}) vypíše chybu (spíše status) posledního příkazu Vkládání dat Dokument bezschémové databáze, na rozdíl od záznamu v relační databázi, může reprezentovat složitější datové struktury, což je bližší reprezentaci dat na úrovni aplikace implementované v objektově orientovaném jazyku. Ukázku vložení dokumentu do databáze MongoDB je možné vidět ve zdrojovém kódu 3.1. Pokud dokumentu ručně nedefinujeme jeho _id, dojde k jeho automatickému vygenerování, jak je možné vidět v kódu 3.3. Tento vygenerovaný ObjectId garantuje unikátnost napříč všemi servery. Podrobnější informace o ObjectId lze nalézt např. v knize [12] na stranách Listing 3.1: Příklad vložení nového dokumentu do MongoDB 1 post = { 2 " title " : " Article headline ", 3 " articlecontent " : " Here is the content 4 of the article with headline 5 Article headline.", 6 " date " : new Date (), 7 " author " : { 8 " name ":" Tonda ", 9 " ":" 10 } 11 } db. test. insert ( post ) Pro vkládání velkého množství záznamů najednou (stovky, tisíce,... ) je vhodné použít funkci batch_insert(), které se předává pole dokumentů a je možné je takto vložit najednou. Dojde tak k ušetření času při otevírání TCP spojení a dekódování hlaviček. Nejde však o funkci určenou např. pro migraci záznamů z jiné databáze. K tomu účelu existují nástroje, jako je např. mongoimport.

35 3.1. DISKUSE RELAČNÍCH A BEZSCHÉMOVÝCH DATABÁZÍ 15 Omezení velikosti jednoho dokumentu je nastavena na 4MB a velikost jednoho dávkového vložení dokumentů na 16MB. Jde především o ochranu před špatnými návrhy. Vkládání záznamů je nativně odolné proti SQL injection Čtení dat Pro čtení dat z databáze je možné použít jednu ze dvou základních funkcí: find() nebo findone(). Do obou vyhledávacích funkcí je možné jako parametr předat dotazovací dokument. Výsledky hledání pak obsahují pouze ty dokumenty, které odpovídají dotazu. Funkce se volají nad kolekcemi, konkrétní použití je možné vidět ve zdrojovém kódu 3.2. Výsledek každého volání v tomto příkladu je stejný a je vidět v ukázce 3.3. Listing 3.2: Příklad jednoduchého načtení dokumentu z databáze (3x) 1 db. test. find ( 2 { " _id ": ObjectId ("4 d72450e4e2f b38 ") } ) 3 4 db. test. find ( {" title ": " Article headline "} ) 5 6 db. test. find ( 7 {" _id ": ObjectId ("4 d72450e4e2f b38 "), 8 " title ": " Article headline "} ) Listing 3.3: Příklad dokumentu s automaticky generovaným ObjectId 1 { 2 " _id " : ObjectId ("4 d72450e4e2f b38 "), 3 " title " : " Article headline ", 4 " articlecontent " : " Here is the content 5 of the article with headline 6 Article headline.", 7 " date " : " Sat Mar :13:07 GMT ( Central Europe Standard Time )", 9 " author " : { 10 " name " : " Tonda ", 11 " " : " cz" 12 } 13 } Pokud je potřeba agregace (seskupující operace, ke kterým se ve světě SQL používají funkce GROUP BY, HAVING, MAX apod.), je zde funkce mapreduce(). Problematika a možnosti mapreduce jsou poměrně široké a existuje na toto téma mnoho názorných příkladů. 5 SQL injection je technika napadení databázové vrstvy programu vsunutím (odtud injection ) kódu přes neošetřený vstup a vykonáním vlastního SQL dotazu. [17]

36 16 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI Některými z nich jsou např. [18], [10] či na oficiálních stránkách MongoDB [7]. Pomocí mapreduce se dá vyjádřit vše, co pomocí agregačních funkcí v SQL a existují dokonce úspěšné pokusy o automatické převody. [20] Rick Osborne na toto téma vytvořil názornou infografiku 3.2. SELECT Dim1, Dim2, SUM(Measure1) AS MSum, COUNT(*) AS RecordCount, AVG(Measure2) AS MAvg, MIN(Measure1) AS MMin MAX(CASE WHEN Measure2 < 100 THEN Measure2 END) AS MMax FROM DenormAggTable WHERE (Filter1 IN ( A, B )) AND (Filter2 = C ) AND (Filter3 > 123) GROUP BY Dim1, Dim2 HAVING (MMin > 0) ORDER BY RecordCount DESC LIMIT 4, 8 1 mysql Grouped dimension columns are pulled out as keys in the map function, reducing the size of the working set. 2 Measures must be manually aggregated. 3 Aggregates depending on record counts must wait until finalization. 4 Measures can use procedural logic. 5 Filters have an ORM/ActiveRecordlooking style. 6 Aggregate filtering must be applied to the result set, not in the map/reduce. 7 Ascending: 1; Descending: MongoDB db.runcommand({ mapreduce: "DenormAggCollection", query: { filter1: { '$in': [ 'A', 'B' ] }, filter2: 'C', filter3: { '$gt': 123 } }, map: function() { emit( { d1: this.dim1, d2: this.dim2 }, { msum: this.measure1, recs: 1, mmin: this.measure1, mmax: this.measure2 < 100? this.measure2 : 0 } );}, reduce: function(key, vals) { var ret = { msum: 0, recs: 0, mmin: 0, mmax: 0 }; for(var i = 0; i < vals.length; i++) { ret.msum += vals[i].msum; ret.recs += vals[i].recs; if(vals[i].mmin < ret.mmin) ret.mmin = vals[i].mmin; if((vals[i].mmax < 100) && (vals[i].mmax > ret.mmax)) ret.mmax = vals[i].mmax; } return ret; }, finalize: function(key, val) { val.mavg = val.msum / val.recs; return val; }, out: 'result1', verbose: true }); db.result1. find({ mmin: { '$gt': 0 } }). sort({ recs: -1 }). skip(4). limit(8); Revision 4, Created Rick Osborne, rickosborne.org Obrázek 3.2: Znázornění, jak jednotlivé SQL funkce odpovídají nástroji MapReduce zdroj: [19] Upravování dat Updaty jsou atomické 6 a provádí se postupně tak, jak přicházejí na server. Provádí se pomocí funkce update( vyhledavaci_dokument, novy_dokument ), která funguje tak, že nahradí dokument nalezený podle prvního parametru dokumentem v druhém parametru. V příkladu 3.4 je vidět ukázka úpravy dat (je upravován dokument 3.3). 6 Atomicita nebo-li nedělitelnost je důležitou vlastností v programování. Vyjadřuje, že daná činnost (operace) se provede najednou, nemůže být přerušena něčím jiným a dokončena později. [15]

37 3.1. DISKUSE RELAČNÍCH A BEZSCHÉMOVÝCH DATABÁZÍ 17 Listing 3.4: Příklad nahrazení dokumentu jiným dokumentem 1 db. test. update ( 2 { " title " : " Article headline " }, 3 { " foo " : " novy dokument " }) 4 5 db. test. find ( 6 {" _id ": ObjectId ("4 d72450e4e2f b38 " )}) 7 8 // nalezeny dokument 9 { " _id " : ObjectId ("4 d72450e4e2f b38 "), 10 " foo " : " novy dokument " } Pokud bychom chtěli odstranit z dokumentu nějaký klíč, mohli bychom to udělat tak, jak je ukázáno v ukázce 3.5. Listing 3.5: Příklad odstranění klíče z dokumentu 1 var article = db. test. findone ( 2 { " title " : " Article headline " } ); 3 delete article. date 4 db. test. update ( 5 { " title " : " Article headline " }, article ) Mnohdy však potřebujeme se záznamy provádět pouze částečné změny a v takovém případě je zbytečné nahrazovat celý dokument. Pro změnu pouze některých klíčů se používají modifikátory. Jelikož si tato bakalářská práce neklade za cíl být referenční příručkou ani k MongoDB, ani k jiné bezschémové databázi, uvedu pouze stručný příklad a krátký výčet dalších možných modifikátorů. V příkladu 3.6 je použit modifikátor $inc, který slouží k přičtení číselné hodnoty. Klíč, ke kterému je hodnota přičítána, nemusí předem existovat v takovém případě bude vytvořen. Listing 3.6: Příklad použití modifikátorů 1 db. test. update ( 2 { " title " : " Article headline " }, 3 {" $inc " : {" pageviews ": 1}}) Některé další modifikátory $set Slouží pro přidání nového klíče nebo upravení obsahu již existujícího. Je možné takto změnit i datový typ. $unset Odstranění klíče.

38 18 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI MySQL databáze tabulka řádka sloupec MongoDB databáze kolekce dokument klíč Tabulka 3.3: Základní komponenty databází MySQL a MongoDB, které sobě přibližně odpovídají. $push Vloží další element na konec pole, případně vytvoří pole, pokud neexistovalo. $addtoset Vloží další element na konec pole, ale pouze v případě, že element v poli ještě neexistuje. $pop Odebere prvek ze začátku či konce pole. $pull Odebere prvek z pole dle kritérií. Konkrétní příklady použití modifikátorů a další možnosti upravování dat, včetně jejich výhod a nevýhod, je možné dohledat v knize [12] na stranách Mazání dat Pro mazání lze použít funkci remove(), která bez parametrů smaže všechny dokumenty v kolekci, nad kterou byla zavolána. Stejně jako u předchozích příkladů je možné funkci předat v parametru dokument, podle něhož budou vymazány pouze specifické dokumenty. Je třeba si uvědomit, že zde neexistuje žádná funkce zpět. Funkce remove nesmaže samotnou kolekci ani indexy. Pokud bychom chtěli smazat celou kolekci, je vhodnější použít funkci pro zrušení kolekce db.drop_collection("test"), která je o mnoho rychlejší Srovnání relačních a bezschémových databází V této sekci provedu srovnání bezschémových a relačních databází tak, abych na jeho základě mohl rozhodnout, která z databází bude vhodnější pro finální implementaci aplikace. Jak již bylo výše zmíněno, žádné řešení se nedá považovat za univerzálně nejlepší a vždy je třeba vlastnosti jednotlivých systémů porovnat s požadavky na konkrétní systém. Mnohé systémy dokonce používají obě databáze. Relační databáze je pak použita v části, kde je klíčová konzistence či komplexní transakce a na vše ostatní databáze bezschémová. [23] V následujících podsekcích provádím diskuzi důležitých aspektů obou databází Množství dat Pokud potřebujeme ukládat velké množství dat, bezschémová databáze je lepší volba. [22] Velkým množstvím dat je však míněno opravdu velmi velké množství dat. Pro představu, bezschémovou databázi začal používat server digg.com (http://digg.com/), který umožňuje

39 3.1. DISKUSE RELAČNÍCH A BEZSCHÉMOVÝCH DATABÁZÍ 19 návštěvníkům přidávat odkazy na zajímavé webové stránky a následně pro ně hlasovat. Tento oblíbený server čítá desetitisíce nově přidaných odkazů denně, přibližně stejné množství komentářů a statisíce hlasů pro tyto odkazy. [13] Dalším příkladem je server Twitter (http://twitter.com/), který přijímá na 7TB dat denně je tedy třeba rychlost více než 80MB/s, aby se takové množství dat vůbec zapsalo. V těchto případech není myslitelné použití SQL databáze. [22] Bezschémové databáze však mohou pojmout velké množství dat především díky škálování datovým prostorem nijak nešetří. Pokud vyvíjíme např. pro mobilní zařízení, kde stále ještě máme poměrně omezený datový prostor, je vhodnější použít relační databázi Rychlost a horizontální škálování Z hlediska rychlosti vyhrávají bezschémové databáze, ale mnoho logiky, která je u relačních databází zahrnuta, si musí programátor dopsat sám nebo ji musí obsahovat ovladač databáze. [22] [4] Opět nabízím příklad serveru digg.com, který obsluhuje 40 milionů uživatelů a 500 milionů zobrazení stránek měsíčně. [13] S bezschémovými databázemi se díky horizontálnímu škálování také zprošťujeme možného problému nárazu na nepřekonatelnou bariéru, kdy bychom mohli zjistit, že náš rostoucí projekt už nejsme schopni technicky zvládnout. [23] Horizontální škálování lze u bezschémových databazí snadno provádět především proto, že API pro přístup k datům je dostatečně jednoduché a přesně definované. [4] Relační databáze také nabízejí určité možnosti rozložení zátěže na více strojů, ale nevyhneme se dotazům, které se budou muset odeslat na všechny databáze a výsledek zkombinovat z těchto dílčích výsledků. Takové dotazy se pak stanou velmi drahými a úzkým hrdlem celé aplikace. [8] Relační databáze horizontálně škálujeme pomocí vytvoření struktury master-slave, kde master slouží pro zapisovací operace a slaves pro čtecí. U bezschémové databáze jsou všechny stroje ekvivalentní a škáluje se jednoduše přidáním dalšího stroje. [8] Křivka učení, rozšířenost a dospělost Křivka učení představuje závislost času stráveného programátorem učením se určité technologie na jeho schopnostech s touto technologií pracovat. Ta v případě NoSQL bude mít u většiny lidí pomalejší růst, než u SQL databází. [9] [13] Na druhou stranu to jiní lidé [21] vyvracejí, jako mýtus. Relační databáze tu jsou už velmi dlouho a těžko bychom hledali programátora, který nezná alespoň základy dotazovacího jazyka SQL. Díky tomu je pro firmu snazší najmout SQL programátora a navíc existuje více lidí, s kterými je možné případné problémy konzultovat. NoSQL naopak zatím není tak rozšířené. [6] Relační databáze se nesčetněkrát ověřily v praxi a lidé v ně mají důvěru. Také vědí, co se s nimi dá dělat a co ne. Navíc existuje o mnoho více SQL nástrojů, které při vývoji pomohou. [22]

40 20 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI Dostupnost a cena Vzhledem k hromadnému rozšíření MySQL i dalších SQL databází je mnohem snazší nalézt hostera, který poskytuje relační databázi. Pokud však vyvíjíme pro cloud, je třeba porovnat ceny datového prostoru pro jednotlivé databáze. Cena prostoru pro bezschémové databáze bývá nižší, může však dojít k jejímu navýšení např. v podobě zpoplatnění transakcí. [23] Flexibilní schéma a interakce s daty Už z podstaty bezschémových databází je jasné, že pokud očekáváme časté změny datového modelu, měli bychom se vydat cestou NoSQL. Na druhou stranu s flexibilitou ztrácíme jistý pevný základ aplikace. U aplikací používajících relační databáze se dá datový model považovat za jakýsi souhrn pevných informací, které přetrvávají přes všechny změny, které se v aplikaci dějí. [22] Díky standardizaci komunikace s relačními databázemi v podobě jazyka SQL získáváme jednotný přístup k datům ačkoliv implementace SQL se u jednotlivých databází často liší. U bezschémových databází se zatím přístup k datům standardizovat nepodařilo a změna jedné NoSQL databáze za jinou tak může představovat velké změny. [5] Transakce Komplexní víceřádkové transakce bezschémové databáze nemají (jednoduché transakce ano) a je třeba je řešit na úrovni aplikace. Je tomu tak z toho důvodu, že tyto operace je složité poskytnout na distribuovaném systému. Relační databáze transakce většinou mají sami o sobě. [22] [8] Existují i bezschémové databáze, jako je např. GT.M, které komplexní transakce podporují (http://fisglobal.com/products/technologyplatforms/gtm/index.htm) Normalizace dat a konzistence Díky denormalizaci dat je možné dosahovat vysokých výkonů, ale programátor pak musí být velmi obezřetný (především při upravování či mazání dat), aby došlo ke změnám na všech potřebných místech. [9] Denormalizaci dat lze provést jak u bezschémových, tak u relačních databází. Systém je tím vystaven možné nekonzistenci, ale SQL databáze s podporou ACID nabízí lepší prostředí pro udržování konzistence. [23] Relační databáze nabízejí okamžitou (blokující) konzistenci, zatímco bezschémové pouze částečnou (čtecí operace nečekají na zapisovací a poslední zápis vyhrává). [8] 3.2 Výběr technologií pro implementaci Výběr hlavní databáze Výběr proběhl mezi bezschémovou databází MongoDB a relační databází MySQL.

41 3.2. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI 21 Množství dat Informační systém (dále jen IS) nebude obsahovat gigantické množství dat. Velká multimediální data a mapové podklady budou uloženy v jiných databázích a v aplikaci na ně budou umístěny pouze odkazy. Z tohoto pohledu je možné použít obě databáze. Rychlost a horizontální škálování IS by vzhledem k cílení na omezenou skupinu lidí v ČR neměl přesáhnout kapacit jednoho serveru. Z tohoto pohledu je možné použít obě databáze. Křivka učení, rozšířenost a dospělost Vzhledem k možnosti, že systém budou spravovat a případně i rozšiřovat další lidé, bude lepší použít technologii, která je všeobecně známá. Z tohoto pohledu je lepší použít MySQL. Dostupnost a cena Zadavatel má již k dispozici server s MySQL databází. Z tohoto pohledu je lepší použít MySQL. Flexibilní schéma a interakce s daty Je pravděpodobné, že při vývoji a dalším rozšiřování systému (které je v plánu) se objeví požadavek na změny datového modelu. Z tohoto pohledu je lepší použít MongoDB. Transakce Ačkoliv je jistě lepší transakce mít, než-li ne, systém nebude nakládat z finančními či jinak choulostivými daty, a proto vyloženě nutné nejsou. Z tohoto pohledu je možné použít obě databáze. Normalizace dat a konzistence Systém by mělo být možné úspěšně denormalizovat při zachování konzistence (např. z důvodu zvýšení výkonu). Z tohoto pohledu je možné použít obě databáze. Výsledek: Ačkoliv bude pravděpodobně v budoucnu nutné upravovat datový model databáze, všeobecné rozšíření a znalost SQL databází posouvá MySQL na místo lepší volby. Navíc je nepravděpodobné, že by bylo nutné systém v budoucnu horizontálně škálovat Výběr ostatních technologií Výběr jazyka byl dán nefunkčními požadavky 2.1.2, kde je specifikován jazyk PHP. Další otázkou bylo, zda použít pro PHP některý z frameworků. Z důvodu jednoduchosti a pochopitelnosti jsem se rozhodl systém vyvíjet bez frameworku. Také z důvodu, že budu systém vyvíjet jak pro MySQL, tak částečně pro MongoDB, rozhodl jsem se nepoužívat ORM. Pro oddělení aplikační logiky od uživatelského rozhraní jsem se rozhodl použít šablonovací systém Smarty (http://www.smarty.net/). Pro komunikaci s Google Maps je možné v PHP použít neoficiální knihovnu php-google-mapapi (http://code.google.com/p/php-google-map-api/), ale rozhodl jsem se použít oficiální Google Maps JavaScript API V3 (http://code.google.com/apis/maps/documentation/javascript/).

42 22 KAPITOLA 3. ANALÝZA TECHNOLOGIÍ PRO IMPLEMENTACI

43 Kapitola 4 Realizace V projektu je použit architektonický vzor Model-View-Controller, konkrétně jeho pasivní verze, kde modul View není okamžitě informován Modelem o změnách, nýbrž aktuální data jsou načtena až při dalším HTTP požadavku vyvolaném uživatelem. [2] Pro základní obsluhu požadavků je použit návrhový vzor Front Controller, který předává řízení příslušnému MVC Controlleru. Jak je možné vidět na obrázku B.1, který znázorňuje hlavní adresáře (a jejich podadresáře) aplikace, soubory realizující jednotlivé moduly MVC se nacházejí ve složkách s odpovídajícími názvy (model, view a controller). Zajímavým obsahem těchto i ostatních adresářů se budu blíže zabývat v následujících podkapitolách. 4.1 Model-View-Controller Model Zaměnitelnost datové vrstvy Poněkud nestandardní částí projektu je jeho Model, což je způsobené tím, že je možné v konfiguraci aplikace zaměnit relační databázi za bezschémovou. Aby toto bylo možné (bez nutnosti provádět další změny ve zbytku aplikace), bylo nutné v první řadě odstínit datovou vrstvu od aplikační logiky a view, což zajistila implementace MVC. Kromě toho však bylo nutné vytvořit ještě rozhraní mezi Controllerem a Modelem, aby bylo možné ovlivňovat, jaký model bude použit. Tato funkčnost byla realizována implementací jednoduché továrny (nejde však o návrhový vzor Factory method). Jak je vidět na diagramu 4.1, třída DaoFactory vrací příslušný Data Access Object implementující požadované rozhraní. V aplikaci je pak pouze třeba dodržovat pravidlo, že s databází se komunikuje pouze skrze DAO, které získáváme od DaoFactory. Tímto způsobem by bylo možné systém rozšířit o další datovou vrstvu. Museli bychom pouze rozšířit DaoFactory a samozřejmě naimplementovat příslušné DAO. 23

44 24 KAPITOLA 4. REALIZACE Obrázek 4.1: UML diagram pro DaoFactory a jím vracené DAO objekty (z úsporných důvodů je zobrazeno pouze několik DAO tříd a pouze některé metody) Připojení k MySQL Připojení k MySQL databázi probíhá ve třídě MyDb, která se nachází v adresáři model/datalayer/sql/database. Tato třída implementuje návrhový vzor Singleton, který napomáhá ušetření vytváření připojení k databázi, jež je časové náročné. V rámci jednoho zpracování HTTP požadavku tak díky tomuto vzoru dochází k vytvoření pouze jediného připojení k databázi. K připojení samotnému je použito PDO (http://php.net/manual/en/book.pdo.php). Třída MyDb poskytuje statickou metodu getinstance(), častěji je však používána spíše druhá statická metoda query, které je možné přímo předat SQL dotaz, který bude nad databází proveden. Na této úrovni již nejsou prováděny žádné kontroly a je očekáváno, že přijatý SQL dotaz je korektní Připojení k MongoDB Připojení k MongoDB databázi probíhá též ve třídě MyDb, která se nachází v adresáři model/- datalayer/nosql/database. Na rozdíl od připojení k MySQL, zde není na úrovni aplikace

45 4.1. MODEL-VIEW-CONTROLLER 25 implementována logika pro zajištění pouze jediného připojení k databázi. Místo toho je použita nativní podpora pro vytvoření tzv. persistentního připojení, která tuto problematiku řeší. K připojení samotnému je použita třída Mongo (http://cz.php.net/manual/en/book.mongo.php) Business objekty Business objekty jsou součástí rozhraní se zbytkem systému, protože jsou používány jak v controllerech, tak v samotných view tyto komponenty tedy mají znalost jejich struktury. Business objekty jsou poměrně primitivní a tvoří pouze obálku pro různé typy dat, reprezentujíce tak určitý složitější typ. Typický business objekt pak obsahuje pouze privátní atributy, které je možné namapovat na atributy záznamů v databázi, a veřejné metody pro přístup k nim. K atributům nepřistupujeme přímo z důvodu zlepšení zapouzdření a možnosti provádět s daty určité korekce, jako je např. transformace znaků nových řádků na příslušné HTML tagy, což je možné vidět např. ve třídě Event, konkrétně v metodě getdescription(). Tyto třídy však mohou obsahovat i metody vracející určitou informaci, kterou bychom za jistých okolností (např. pokud je výpočet příliš náročný) mohli také ukládat do databáze, ale z důvodu možnosti dopočítání z jiných informací a omezení redundance, to neděláme. Příkladem takové metody je metoda getstate(), kterou je možné vidět opět ve třídě Event. Tato metoda porovnává data události s datem aktuálním a vrací informaci o tom, zda událost např. ještě probíhá, či zda se teprve bude konat View View aplikace je realizováno pomocí šablonovacího systému Smarty (http://www.smarty.net/). Opakující se části, jako je např. hlavička stránky, drobečková navigace, patička či formulář pro přechod na domovské souřadnice, se nacházejí v oddělených souborech (v adresářích view/includes a view/templates). Tyto části jsou pak do ostatních šablon vkládány příkazem include Controller Základem každého controlleru aplikace je abstrakční předek BaseController, který provádí určité přípravné operace prvků, které jsou později třeba ve všech controllerech. Těmito operacemi jsou např. inicializace Smarty, nastavení výchozích hodnot pro titulek stránky či zvolení defaultní šablony. Dále definuje abstraktní metody setup() a render(). Jak je vidět na diagramu 4.2, většina controllerů nedědí přímo z této třídy, ale z konkrétnější (avšak stále abstraktní) třídy BaseSessionController, která navíc připravuje session pro uložení přihlášeného uživatele. Každý finální controller pak implementuje již zmíněné metody setup() a render(), které jsou nad příslušnými controllery volány instancí FrontController v souboru index.php5 (či admin.php5 ). Obsah obou metod by mohl být přesunut do konstruktoru a být tak proveden automaticky při vytváření jednotlivých instancí, ale takto zůstává otevřena možnost pro případné operace např. ještě před vykreslením uživatelského rozhraní. V metodě setup() dochází k vyhodnocení aplikační logiky v závislosti na požadavku, získání potřebných dat a jejich předání do příslušných Smarty proměnných voláním metody assign.

46 26 KAPITOLA 4. REALIZACE Obrázek 4.2: UML diagram systému controllerů (z úsporných důvodů jsou zobrazeny pouze některé) Zajímavou Smarty proměnnou je invokejavascript, ve které je možné definovat, které JavaScript funkce z přiložených souborů budou explicitně zavolány po načtení stránky. Podobně lze do proměnné customjavascript dynamicky generovat funkce nové, čehož je využíváno např. u jednotlivých pozorovacích míst a událostí, kde je třeba zacílit a přiblížit mapu na příslušné místo, dle definované polohy při zakládání těchto objektů. V setup() metodě může také dojít k předání řízení controlleru ErrorController, který je určen k obsluhování chyb (to může nastat, pokud se snažíme přistupovat k privátnímu nebo neexistujícímu obsahu), či případně k přesměrování na jinou adresu. Metoda render() pak už pouze pošle Smarty zprávu s informací, jaká šablona má být zobrazena. 4.2 Implementace Data Access Objektů V této sekci se nachází příklady tří metod (další je možné nalézt přímo ve zdrojovém kódu aplikace) pro práci s databází. Na těchto je demonstrován odlišný přístup k operacím čtení, upravování a vkládání.

47 4.2. IMPLEMENTACE DATA ACCESS OBJEKTŮ Implementace DAO pro MySQL Metoda getspotscreatedby Na ukázce C.1 je vidět, jakým způsobem dochází k získávání dat z databáze při použití MySQL. Důležitou částí je místo plnění proměnné $sql, kde se nachází konkrétní SQL dotaz. Je zde také možné vidět ochranu proti SQL injection, jež je realizována metodou gpcaddslashes, která v závislosti na nastavení PHP přidá před speciální znaky escape sekvence (pokud to PHP nedělá automaticky). Další důležitou částí je volání mapovací metody mapspot, která přijme řádek získaný z databáze jako pole hodnot a z těchto hodnot vytvoří business objekt ( ), který je vrácen zpět Metoda createnewuser Na další ukázce (C.2) je možné vidět metodu createnewuser, která je volána při registraci nového uživatele. Opět je možné si povšimnout ochrany proti SQL injection. Metoda po vložení záznamu do databáze tohoto právě vytvořeného uživatele vrátí, aby mohl být automaticky po registraci přihlášen Metoda addattendingusertoevent V poslední ukázce (C.3) této podsekce je metoda vkládající záznam do joinovací (spojovací) tabulky. Ukázka je zde pro účely porovnání této operace s bezschémovou databází (viz ), kde joinovací tabulky nejsou Implementace DAO pro MongoDB Metoda getspotscreatedby Jak je vidět na ukázce C.4, nejsou zde žádné SQL dotazy, místo nich je vytvářen dotazovací dokument, a proto není třeba už z principu řešit SQL injection. Za povšimnutí stojí nutnost volby kolekce (ekvivalent tabulky) před odesláním samotného dotazu, nad kterou bude dotaz proveden. U relační databáze je tato volba součástí dotazu. Je třeba si také uvědomit, že není používán stejný Mapper, jako byl použit u relační databáze. Ve většině případů je třeba mapování lehce upravit, protože data nejsou z databáze přijata ve stejném formátu, jako u databáze relační Metoda createnewuser Ukázka postupu uložení nového uživatele do MongoDB je vidět ve zdrojovém kódu C.5. Zdrojový kód je sám o sobě snadno pochopitelný.

48 28 KAPITOLA 4. REALIZACE Metoda addattendingusertoevent V ukázce C.6 lze pozorovat (při srovnání s ukázkou C.3) odlišný přístup k ukládání dat mezi jednotlivými databázemi. V tomto případě není využíváno spojovacích tabulek, ale navštívené události příslušným uživatelem jsou uloženy přímo u uživatele. Na to je třeba myslet, pokud bychom implementovali možnost události editovat, což by mohlo způsobit vznik aktualizační anomálie 1 (aplikace to však momentálně neumožňuje a tak tento problém neexistuje). Editace se provádí voláním metody update, které se kromě vyhledávacího dokumentu předává také dokument upravovací. V tomto dokumentu je použit modifikátor $addtoset, který zajišťuje přidání dokumentu do pole attendedevents pouze v případě, že se v poli již nenachází. 4.3 Některé další prvky implementace Formuláře Každý formulář je na straně serveru reprezentován příslušnou třídou (k nalezení v adresáři model/forms) s abstraktním předkem Form, který vyžaduje implementaci metod isvalid() a geterrormessages(). Navíc obsahuje některé již implementované metody, jako je např. check_ ($ ) (jejímž autorem je Jakub Vrána které jsou potřeba u více formulářů. Konkrétní potomci tohoto předka jsou inicializováni předáním příslušných $_POST dat jejich konstruktoru, který do atributů třídy uloží jednotlivé položky formuláře zadané uživatelem. Stejně jako u business objektů (viz ), i zde jsou atributy privátní a je k nim přistupováno pouze skrze veřejné metody. Díky tomu bylo možné do setterů zakomponovat zabezpečení proti XSS Životní cyklus formulářů 1. Při první návštěvě stránky s formulářem controller detekuje nepřítomnost formulářových dat a je pouze zobrazena šablona obsahující formulář. 2. Uživatel vyplní (správně či špatně) formulář a data odešle stisknutím tlačítka na server. 3. Controller detekuje přítomnost formulářových dat a vytvoří objekt formuláře. Voláním metody isvalid() (tato metoda zároveň plní pole chyb, pokud nějaké nastaly) nad formulářem ověří jeho korektnost. 1 Aktualizační anomálie je problém, který se může vyskytnout v případě, kdy data v databázi nejsou v normalizované podobě. Tedy aktualizace určité hodnoty nelze provést na jediném místě, ale je třeba ji obnovit na všech místech, kam byla hodnota zkopírována. 2 Cross-site scripting je druh bezpečnostní díry, který umožňuje útočníkům vložit do stránky svůj clientside skript.

49 4.3. NĚKTERÉ DALŠÍ PRVKY IMPLEMENTACE Jestliže byl formulář nesprávně vyplněn (vynechání povinné položky, nesprávný formát položky,... ) nebo došlo k jiné chybě (datum konce události je před začátkem, uživatelské jméno již bylo registrováno,... ), controller předá view chybové hlášky, které jím jsou zobrazeny u příslušných polí. Spolu s chybovými hláškami controller předává i samotný objekt formuláře, odkud view uživateli předvyplní jeho původní (i když špatná) data, aby nedošlo ke ztrátě informací a uživatel nebyl nucen vyplňovat celý formulář od začátku. 5. Jestliže byla data korektní, provede se cílová operace (uložení dat, přihlášení uživatele,... ) a obvykle je také uživatel přesměrován na cílovou stránku operace (stránka nově vytvořené události, profilová stránka uživatele,... ) Dynamicky generovaný JavaScript Protože aplikace pracuje s Google Maps prostřednictvím jeho klientského (JavaScript) API a pro některé operace nad mapou je potřeba dat uložených na straně serveru (např. uživatelem uložené preference či umístění událostí), je nutné generovat mapu ovládající funkce dynamicky. V aplikaci lze přistupovat ke generování JavaScriptu dvěma možnými způsoby. V první řadě v souboru scripts/dynamic/custommapoptions.js.php5 probíhá generování JS funkce setusersmapattributes(). PHP skript pouze načte přihlášeného uživatele ze session (pokud je přihlášen a pokud má nastavené preference) a vygeneruje příslušné volání GMaps API pro nastavení mapy. V této části implementace jsem se setkal se zajímavou chybu PHP_Incomplete_Class. Ta byla způsobena použitím objektu User ze session, aniž by předtím byla tato třída načtena. Tuto chybu jsem vyřešil inicializací prázdného uživatele před použitím uživatele načteného ze session. Druhá možnost, jak v aplikaci generovat JavaScript, již byla zmíněna v části Controller (4.1.3), kdy je možné prostřednictvím proměnné customjavascript generovat JS kód přímo v controlleru Dynamicky generované XML Protože data aplikace jsou ukládána do databáze na straně serveru, ale současně je potřeba s nimi pracovat i na straně klienta pomocí JavaScriptu, bylo nutné vytvořit určitou formu databáze i právě na straně klienta. Nejlepší možností se jevilo XML, pro které existuje mnoho ověřených nástrojů a knihoven. Generování XML probíhá v souboru helpers/spotsmarkers.xml.php5 a to pokaždé, kdy je o tento soubor požádáno. Tímto způsobem bude pravděpodobně docházet k redundantním dotazům na databázi, kdy se bude znovu generovat to samé XML, ačkoliv v databázi nejsou od generování předchozího žádná nová místa či události. Z důvodu zamezení předčasné optimalizace toto zatím není řešeno, avšak zapojení určité cache je předmětem dalšího rozvoje aplikace.

50 30 KAPITOLA 4. REALIZACE K vytvoření XML dokumentu byly použity třídy DOMDocument a DOMElement, které pokrývají celou problematiku generování XML. Navíc bylo třeba pouze zajistit odeslání hlavičky Content-type: text/xml, pro informování prohlížeče, o jaký typ souboru se jedná. Ke každému místu jsou do informační bubliny na mapě přidány tři události a to tak, že pokud možno ty probíhající, jinak ty nadcházející a až nakonec uplynulé. Pro ušetření dotazů na databázi jsou načteny všechny události na příslušném pozorovacím místě a následně jsou filtrovány ve třídě EventService Práce s Google Maps zobrazení značek na mapě Značky jsou na mapě zobrazovány pomocí funkce loadmarkersfromxml(), která se nachází v souboru scripts/gmapsskript.js. Část obsahu této funkce je možné vidět v ukázce C.7. Na začátku je jquery metodou get asynchronně načten obsah XML souboru do proměnné data a následně je její obsah prohledán taktéž jquery metodou find. Pro všechna nalezená pozorovací místa jsou vytvořeny jednak značky samotné, ale také informační bubliny, které jsou naplněny kromě základních informací o místě i již zmíněnými událostmi, které se zde konají, budou konat či konaly (tato část v ukázce C.7 z důvodu přehlednosti popisu funkcí kódu chybí, zpracování značek event je však velmi podobné zpracování značek spot). V závěru je nově vytvořené značce přiřazen listener pro zachytávání kliků na značku. Jako reakce na tyto kliky pak dochází k zobrazování (či skrývání) informační bubliny Vložení značky na mapu Vkládání značky na mapu je použito při zakládání nového místa, což uživatelům poskytuje možnost definovat pozici místa na mapě bez nutnosti znalosti jeho GPS souřadnic. Tato funkce je realizována voláním placemarker (také v souboru scripts/gmapsskript.js), kterému je předána pozice kliknutí na mapu z listeneru. Při prvním volání metody dojde k vytvoření značky a jejímu uložení do globální proměnné marker. Při dalších voláních je pak už pouze měněna pozice této značky metodou setposition. Zároveň jsou do příslušných polí formuláře vloženy GPS souřadnice právě umístěné značky, které tu jsou pro pokročilé uživatele Práce s GPS souřadnicemi Pro výpočet vzdálenosti mezi dvěma souřadnicemi byla použita třída GeoCalc, která byla původně napsána Andy McGovernem v C++ [1] a následně přepsána Stevenem Brendtroem (http://trac.guifi.net/trac/browser/guifi/drupal6x/modules/guifi/geocalc.class.php?rev=234) do PHP. Pro převod GPS souřadnic reprezentovaných jako desetinné číslo na stupně, minuty a vteřiny, což je pro člověka mnohem čitelnější podoba, je použita funkce Jakuba Vrány float2gps.

51 4.3. NĚKTERÉ DALŠÍ PRVKY IMPLEMENTACE Načítání nejbližších pozorovacích míst AJAX Na úvodní stránce projektu se nachází seznam nejbližších pozorovacích míst (vzhledem ke středu mapy), který se při posunu mapy aktualizuje. JavaScript realizující asynchronní volání PHP skriptu byl napsán opět pomocí jquery (funkce se nachází v souboru scripts/ajax.js), kde pouze stačilo zavolat funkci get s příslušnými parametry. Nesporná výhoda řešení touto knihovnou je kompatibilita s různými prohlížeči. Serverovou část reprezentuje PHP skript, který se nachází v souboru helpers/ajax/getspotsbydistance.php5. Ten vrací HTML kód, který je klientskou stranou vložen do příslušného elementu DIV. Tento soubor by mohl být považován za potenciální bezpečností díru, protože je volán přímo z klientské části prostřednictvím své URL a nemůže tak být chráněn pomocí.htaccess, jako je tomu u většiny serverových souborů v tomto systému. Skript se však proveden pouze tehdy, jsou-li správně definovány vstupní parametry, a navíc provádí nad databází pouze čtecí operace. Jediné bezpečnostní riziko tak hrozí v podobě DoS 3 útoku. Ten však hrozí i u ostatních skriptů a prevence takového útoku je nad rámec aplikační logiky tohoto systému Komponenty jquery Jak již bylo zmíněno, v aplikaci je upotřeben JavaScriptový framework jquery (http://jquery.com/) a to včetně jquery UI (http://jqueryui.com/). Ten je použit např. pro odesílání asynchronních požadavků, zpracování XML, ale i jednoduché animace na uživatelském rozhraní (např. při zobrazování informačních zpráv nebo při obnovení dat na titulní stránce). Z UI komponent byl použit kalendář pro volbu data (při zakládání nové události). Pro volbu času s posuvníky bylo nutné použít jquery addon od Trenta Richardsona (http://trentrichardson.com/examples/timepicker/) Tvorba multimediálních záznamů z pozorování U událostí je pozorovatelům umožněno vytvářen záznamy, do kterých lze přidávat fotografie a videa z YouTube. Před uložením záznamu je navíc možné si nejdříve prohlédnout výsledek, jak bude po uložení záznam vypadat. Obrázky ani videa nejsou do databáze ukládány ve formě HTML, ale pouze jako interní značky (v případě obrázku) či pouhého odkazu (v případě YouTube videa), což ponechává do budoucna otevřenu možnost s těmito daty dále strojově pracovat Obrázky Vložení obrázku se provádí skrze stejný formulář, jaký slouží pro přidání hlášení samotného. Při požadavku na odeslání formuláře s obrázkem dojde ještě před odesláním dat na server 3 Útok typu Denial-of-service obvykle spočívá v umělém vytvoření dotazů na systém v takovém množství, že dojde k jeho zahlcení a neschopnosti poskytovat služby svým skutečným uživatelům. Takový útok je však v efektivní podobě poměrně nákladný a lze ho předpokládat spíše u honosnějších aplikací, jako jsou např. internetová bankovnictví. [14]

52 32 KAPITOLA 4. REALIZACE k vložení značky do textového pole s hlášením a to konkrétně na místo, kde se aktuálně nachází kurzor. Toto vložení značky na správně místo zajišťuje JavaScriptová funkce insertatcursor. Na serveru je pak nahraný obrázek zpracován, a pokud se skutečně jedná o obrázek (a je v podporovaném formátu), dojde k jeho uložení do adresáře graphics/upload/reports (unikátnost názvu obrázku je zajištěna jeho složením z jedinečného identifikátoru události a aktuálního času). Značky, které byly do formuláře vloženy JS funkcí, jsou poté obohaceny o název nově nahraného obrázku. Tento přístup není ideální, a to proto, že nad jednou nahranými obrázky ztrácíme kontrolu. Pokud se tedy uživatel rozhodne vložený obrázek nepoužít, přesto již zůstane uložený na serveru. Toto by bylo možné vyřešit např. ukládáním názvů přiložených obrázků do databáze, přičemž nepoužité obrázky by byly při ukládání záznamu smazány. Jiným řešením by mohl být Cron 4 job, který by jednou za určitý čas kontroloval, zda se všechny obrázky v příslušném adresáři nacházejí alespoň v jednom záznamu z pozorování YouTube videa Při vložení YouTube videa do záznamu neprobíhají při ukládání žádné operace navíc, protože převod YouTube odkazu na přehrávač probíhá až při čtení záznamu. Pro detekci videí je použit regulární výraz, jemuž odpovídající odkazy jsou převedeny pomocí PHP funkce preg_replace na HTML, které prohlížeč interpretuje jako YouTube přehrávač Profilové fotografie popup okna a cache Nahrání nové profilové fotografie se provádí v popup okně, které je po úspěšném nahrání fotografie automaticky zavřeno funkcí window.close(), ještě předtím je však obnoven obsah otevírající stránky popup okna, aby došlo k načtení nového obrázku. To je provedeno nastavením adresy do proměnné window.opener.location.href a zavoláním funkce window.opener.focus(). Při nahrávání nových obrázků a jejich ukládání pod stejným názvem však nastává problém s cache pamětí prohlížeče, který pro ušetření zbytečných přenosů po síti a urychlení zobrazení stránky jednou načtené obrázky již znovu nenačítá. Uživatel by z tohoto důvodu nově nahraný obrázek bez tzv. tvrdého obnovení stránky neviděl. Tento problém jsem vyřešil přidáním prefixu iterator před název obrázku, přičemž při vytváření prvního obrázku je hodnota proměnné iterator nastavena na číslo 1. Při nahrávání nové profilové fotografie pak dochází před smazáním fotografie staré k zjištění současné hodnoty iterátoru, která je pro název nového obrázku navýšena o číslo 1. Tímto je zajištěno, že nově nahraná fotografie bude mít nové jméno a prohlížeč je nucen její obsah stáhnout ze serveru. Na druhou stranu funkčnost cache pro fotografie, které už není třeba stahovat, zůstává zachována (problém by se dal vyřešit dynamickým načítáním obrázků a odesíláním hlavičky s informací, že je obrázek starý, ale pak by došlo k úplnému zamezení cachování obrázků v prohlížeči). 4 Unixový program umožňující automatické spouštění jiných programů či skriptů v určitý čas a s danou periodicitou.

53 4.4. MODEL NASAZENÍ Ukládání hesel Při registraci nového uživatele je vyžadováno heslo, pomocí kterého se uživatel později může do aplikace přihlašovat. Tato hesla nejsou v databázi uložena v čiré (plain text) podobě, nýbrž jsou osolena a následně zahashována. Díky tomu jsou uživatelská hesla v bezpečí i v případě, že by došlo např. k úniku surových dat z databáze. Implementační detaily zde z bezpečnostních důvodů nebudou zmíněny. 4.4 Model nasazení Aplikace momentálně zkušebně běží na adrese a provoz odpovídá modelu nasazení na obrázku 4.3. V ostrém provozu se předpokládá model podobný či dokonce stejný. Obrázek 4.3: UML diagram modelu nasazení

54 34 KAPITOLA 4. REALIZACE

55 Kapitola 5 Testování 5.1 Akceptační test Akceptační test lze vykonat v rámci standardního prostředí a s výchozím nastavením souboru config.php (kromě nastavení přístupu k databázi, které je třeba upravit dle lokální konfigurace). V databázi musí být vytvořena struktura tabulek skriptem DDL.sql (který se nachází v adresáři model/datalayer/sql/database) a vložena výchozí data skriptem demo_data.sql. Akceptační test proběhnul s úspěšností 100%, přičemž jednotlivé testované položky je možné vidět v tabulkách D.1, D.2 a D Test validity HTML5 Validita stránek dle zvoleného doctype je důležitá z důvodu správného zobrazení obsahu v různých prohlížečích. Je však třeba myslet na to, že se jedná o podmínku nutnou, nikoliv však postačující a neméně důležitou roli hraje korektnost kaskákodých stylů CSS. V případě, kdy nejsou stránky napsané dle standardu, dochází k interpretaci (X)HTML v tzv. quirk módu, ve kterém se každý prohlížeč chová jinak, v závislosti na tom, jak se programátoři jednotlivých prohlížečů rozhodli k chybným stránkám zachovat. DTD jednotlivých typů dokumentů lze nalézt na webových stránkách konsorcia W3C (http://www.w3.org/), kde je možné validitu stránek také otestovat. Vzhledem k tomu, že se v systému nachází poměrně nízký počet stránek, provedl jsem jejich validaci ručně. Při testování jsem objevil některé menší chyby, které jsem ihned opravil a systém je proto nyní plně validní. 5.3 Test kognitivním průchodem Při provádění kognitivního průchodu se snažíme simulovat, jak by asi postupoval uživatel aplikace. Zjišťujeme, zda aplikace uživatele vede ke splnění požadovaného úkolu. Pro všechny úkoly pak odpovídáme na následující otázky: 35

56 36 KAPITOLA 5. TESTOVÁNÍ 1. Bude uživateli zřejmé, jakou akci použít? 2. Spojí si uživatel popisek u požadované akce s tím, co chce udělat? 3. Dostane uživatel dostatečnou zpětnou vazbu o provedení akce? Založení nového místa 1. Ano 2. Ano 3. Ano Problém může nastat v případě, kdy se uživatel nenachází na své profilové stránce a není si vědom toho, že právě ze své profilové stránky může místa zakládat. Uživatel je však na svou profilovou stránku přesměrován ihned po registraci a pravděpodobně si zapamatuje, že na jeho profilové stránce nějaké akce jsou Založení nové události na určitém místě 1. Ano 2. Ano 3. Ano Problém může nastat, pokud uživatel neví, že nové události lze zakládat ze stránky pozorovacího místa Přidání místa mezi oblíbené 1. Ano 2. Ano 3. Ano Přidání komentáře k pozorovacímu místu 1. Ano 2. Ano 3. Ano

57 5.3. TEST KOGNITIVNÍM PRŮCHODEM Přidání záznamu z pozorování k události 1. Ano 2. Ano 3. Ano Přihlášení se k účasti u události 1. Ano 2. Ano 3. Ano Uložení výchozí pozice mapy 1. Ano 2. Ano 3. Ano Problém může nastat, pokud uživatel neví, že změnit výchozí pozici mapy lze z jeho profilové stránky Výsledky kognitivních průchodů Kognitivní průchody zvolených úkolů proběhly dobře. Problém může nastat pouze u operací, které různí lidé (s různými mentálními modely) mohou očekávat na různých místech. Pokud se při dalších testech s uživateli zjistí, že toto skutečně je problém, řešením by mohlo být vytvoření menu v hlavičce s problematickými operacemi či vytvoření FAQ stránky.

58 38 KAPITOLA 5. TESTOVÁNÍ

59 Kapitola 6 Závěr 6.1 Shrnutí výsledků a zhodnocení splnění cílů Srovnání relačních a bezschémových databází V sekci byl nastíněn úvod do bezschémových databází a především bylo provedeno srovnání s databázemi relačními (v sekci 3.1.2). Při srovnání bylo zjištěno, že bezschémové databáze jsou ideální pro projekty, kde je klíčová rychlost, prostor pro enormní množství dat, škálovatelnost a flexibilita datového modelu. Pokud však vyžadujeme komplexní transakce, je pro nás důležité, abychom používali ověřené a široce rozšířené řešení se strmou křivkou učení a nejsme ochotni přistoupit k denormalizaci dat (při zachování dobré rychlosti a prostoru pro přiměřené množství dat), měli bychom zvolit spíše databázi relační Implementace informačního systému pro JihoČAS Informační systém byl plně implementován s použitím relační databáze a částečně i s použitím databáze bezschémové (pro účely demonstrace odlišnosti). Výsledná aplikace splňuje všechny definované požadavky (viz sekce 2.1). Subjektivně ji považuji za zdařilou a reakce na beta verzi byly též velmi pozitivní. Objektivně budeme moci úspěšnost aplikace posoudit až po jejím dokončení a oficiálním spuštění Rozdíly v implementaci při použití bezschémové databáze Z teoretického hlediska je důležitým výsledkem této práce zjištění, že implementace systému pro bezschémovou databázi nepředstavuje velký problém. Jak je demonstrováno v sekcích a 4.2, pokud je zajištěno dobré oddělení datové vrstvy od zbytku systému, implementace pro bezschémovou databázi se kromě komunikace s databází nijak neliší od implementace pro databázi relační. 39

60 40 KAPITOLA 6. ZÁVĚR Otestování implementovaného systému Implementovaný systém byl otestován (viz kapitola 5). Dále proběhl beta-test s šesti uživateli, z nichž dva jsou členové ČAS. Nebyl proveden pouze test zátěže. 6.2 Zhodnocení přínosu práce Jelikož je tato práce z části teoretická, a z části praktická, je vhodné ji posuzovat ze dvou pohledů. Přínos práce z teoretického hlediska vidím především v podání konkrétního příkladu o jednoduchosti implementace aplikace nad bezschémovou databází. Mnoho programátorů se NoSQL databázím vyhýbá pouze z neochoty učit se novou technologii, proto podávám touto formou důkaz, že křivka učení je u obou databází přinejmenším srovnatelně strmá. Nezanedbatelným přínosem je také poskytnuté srovnání obou databází, na základě kterého je možno učinit informované rozhodnutí, zda použít pro různé projekty databázi bezschémovou či relační. Přínos praktického výsledku této práce implementovaný systém pro organizaci pozorování bude možné posoudit až po nasazení aplikace do produkce a bude jistě záležet také na jejím patřičném uvedení mezi současné členy JihoČASu. Subjektivně má systém reálnou šanci stát se mezi astronomy oblíbeným. Ohlasy z testování velmi omezenou skupinou uživatelů jsou velmi pozitivní. 6.3 Zamyšlení se nad použitelností bezschémových databází Bezschémové databáze mají své místo v budoucnosti zajištěné díky tzv. cloud computingu, se kterým jsou neoddělitelně spjaty. Věřím však (a spolu se mnou mnozí další), že bezschémové databáze mohou být uplatněny i u menších systémů, které nevyužijí jejich možnosti takřka neomezeného škálování. Data jsou na straně databáze uložena v podobě velmi blízké jejich reprezentaci na straně aplikace a převod mezi jednotlivými podobami je tak podstatně jednodušší. Překážku rozšíření bezschémových databází v řadách odborné veřejnosti představuje především velká popularita SQL databází, kdy znalost jedné technologie představuje bariéru v podobě neochoty učit se podstatu technologie jiné. Tato překážka bude pravděpodobně (s ohledem na oblíbenost ORM 1 frameworků) o něco snížena po vydání dobrého ODM 2 frameworku, což bude v případě PHP nejspíš MongoDB Object Document Mapper (http://www.doctrine-project.org/projects/mongodb_odm) z dílny týmu Doctrine (pro většinu ostatních programovacích jazyků probíhá vývoj ODM též). 1 Objektově relační mapování slouží k transformaci záznamů databáze na objekty aplikace a též k interpretaci prvků objektově orientovaného jazyka do relačního světa. 2 Objektově dokumentové mapování slouží k transformaci dokumentů bezschémové databáze na objekty aplikace a též k interpretaci prvků objektově orientovaného jazyka do světa dokumentů.

61 6.4. DALŠÍ MOŽNÉ POKRAČOVÁNÍ PRÁCE Další možné pokračování práce Implementovaný systém není v aktuální podobě zcela dokončený a před jeho spuštěním je v plánu vytvoření několika prvků, které vyplynuly při implementaci funkcí naplánovaných pro tuto práci. Uvádím zde pouze některé: Pozorovací místa (jejich názvy nebo i další atributy) bude možné editovat jejich zakladateli. Pozorovací místo bude obsahovat seznam lidí, kteří se na něm právě nachází. Pro přidávání pozorovatelů k privátnímu místu bude vytvořen našeptávač. Na stránkách pozorovacích míst bude chat (týkající se pouze tohoto místa). Na titulní stránce se budou zobrazovat zprávy ze všech míst. Registrace bude chráněna proti spamu (CAPTCHA). Generované XML s pozorovacími místy bude obsahovat vyrovnávací paměť (cache). Při archivaci místa v administraci bude administrátor upozorněn, pokud archivuje místo, na kterém jsou probíhající nebo naplánované události. Uživatel bude moci právě pozorovat pouze na jednom místě. Pozorovací místa, která se nacházejí blízko sebe, budou při oddálení mapy sdružována pomocí utility MarkerClusterer (http://code.google.com/p/gmaps-utility-librarydev/). Pokud bude systém úspěšný na úrovni Jihočeského kraje, je v plánu jeho prosazení u poboček ČAS po celé České republice.

62 42 KAPITOLA 6. ZÁVĚR

63 Literatura [1] Andy McGovern. Geographic Distance and Azimuth Calculations [online] [cit ]. Dostupné z: <http://www.codeguru.com/cpp/cpp/algorithms/ article.php/c5115/>. [2] Antonín Daněk, Jakub Stejskal. Model-View-Controller vs. Presentation-Abstraction- Control [online] [cit ]. Dostupné z: <http://data.antonindanek.cz/ MVCvsPAC.pdf>. [3] Artur Ejsmont. Insert performance comparison of NoSQL vs SQL servers [online] [cit ]. Dostupné z: <http://artur.ejsmont.org/blog/content/ insert-performance-comparison-of-nosql-vs-sql-servers>. [4] Avi Kapuya. NoSQL - the SQL [online] [cit ]. Dostupné z: <http: //www.theserverside.com/discussions/thread.tss?thread_id=61425>. [5] Bill Nigh. NoSQL DB vs SQL Performance Monitoring [online] [cit ]. Dostupné z: <http://www.evidentsoftware.com/ nosql-vs-sql-performance-monitoring/>. [6] claus. NoSQL vs. SQL [online] [cit ]. Dostupné z: <http://www. catify.com/2010/10/19/nosql-vs-sql/>. [7] Eliot Horowitz. MapReduce [online] [cit ]. Dostupné z: <http://www. mongodb.org/display/docs/mapreduce>. [8] Ian Rogers. Compare sql vs. nosql [online] [cit ]. Dostupné z: <http: //www.sirgroane.net/2010/09/compare-sql-vs-nosql/>. [9] Ilya Grigorik. Schema-Free MySQL vs NoSQL [online] [cit ]. Dostupné z: <http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/>. [10] ishaan. Yet another MongoDB Map Reduce tutorial [online] [cit ]. Dostupné z: <http://www.mongovue.com/2010/11/03/ yet-another-mongodb-map-reduce-tutorial/>. [11] Karel Minařík. CouchDB Databáze pro web [online] [cit ]. Dostupné z: <http://webexpo.cz/prednaska/couchdb-databaze-pro-web/>. [12] KRISTINA CHODOROW, M. D. MongoDB: The Definitive Guide. : O Reilly Media Inc, California, 1st edition, In English. 43

64 44 LITERATURA [13] Loraine Lawson. The Business Pros and Cons of NoSQL [online] [cit ]. Dostupné z: <http://www.itbusinessedge.com/cm/blogs/lawson/ the-business-pros-and-cons-of-nosql/?cs=40089>. [14] Přispěvatelé Wikipedie. Denial-of-service attack [online] [cit ]. Dostupné z: <http://en.wikipedia.org/wiki/denial-of-service_attack>. [15] Přispěvatelé Wikipedie. Linearizability [online] [cit ]. Dostupné z: <http://en.wikipedia.org/wiki/atomicity_(programming)>. [16] Přispěvatelé Wikipedie. Memcached [online] [cit ]. Dostupné z: <http: //en.wikipedia.org/wiki/memcached>. [17] Přispěvatelé Wikipedie. SQL injection [online] [cit ]. Dostupné z: <http://en.wikipedia.org/wiki/sql_injection>. [18] Rick Osborne. Playing around with MongoDB and MapReduce functions [online] [cit ]. Dostupné z: <http://rickosborne.org/blog/2010/02/ playing-around-with-mongodb-and-mapreduce-functions/>. [19] Rick Osborne. InfoGraphic: Migrating from SQL to MapReduce with MongoDB [online] [cit ]. Dostupné z: <http://rickosborne.org/blog/2010/02/ infographic-migrating-from-sql-to-mapreduce-with-mongodb/>. [20] Rick Osborne. Yes, Virginia, that s automated SQL to MongoDB MapReduce [online] [cit ]. Dostupné z: <http://rickosborne.org/blog/2010/02/ yes-virginia-thats-automated-sql-to-mongodb-mapreduce/>. [21] NoSQL Technology [online] [cit ]. Dostupné z: <http://www.slideshare.net/fachrybafadal/nosql-technology>. [22] Todd Hoff. What the heck are you actually using NoSQL for? [online] [cit ]. Dostupné z: <http://highscalability.com/blog/2010/12/6/ what-the-heck-are-you-actually-using-nosql-for.html>. [23] unknown. RDBMS vs NoSQL [online] [cit ]. Dostupné z: <http://www.dotnetsolutions.co.uk/blogs/markrendle/archive/2010/03/11/ rdbms-vs-nosql/>. [24] unknown. Why MongoDB Writes are Faster than MySQL? [online] [cit ]. Dostupné z: <http://nosql.mypopescu.com/post/ / why-mongodb-writes-are-faster-than-mysql>.

65 Příloha A Seznam použitých zkratek AAS American Astronomical Society ACID Atomicity, Consistency, Isolation, Durability AJAX Asynchronous JavaScript and XML API Application programming interface ČAS Česká astronomická společnost ČVUT České vysoké učení technické DAO Data Access Object DoS Denial-of-service DTD Document Type Definition FAQ Frequently Asked Questions GPS Global Positioning System HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IS Informační systém JSON JavaScript Object Notation MVC Model-View-Controller NASA National Aeronautics and Space Administration NoSQL Not Only SQL ODM Object-Document Mapping ORM Object-Relational Mapping 45

66 46 PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK PDO PHP Data Objects PHP PHP: Hypertext Preprocessor (rekurzivní akronym) RDBMS Relational database management system SQL Structured Query Language CSS Cascading Style Sheets UML Unified Modeling Language W3C World Wide Web Consortium XML Extensible Markup Language XAMPP X(cross-platform) Apache MySQL PHP Perl XSS Cross-site scripting

67 Příloha B UML diagramy Obrázek B.1: Grafické znázornění adresářové struktury aplikace 47

68 48 PŘÍLOHA B. UML DIAGRAMY

69 Příloha C Ukázky zdrojových kódů Listing C.1: Ukázka čtecí operace nad relační databází 1 public function getspotscreatedby ( $userid ) { 2 3 if(! isset ( $userid ) ) return null ; 4 5 $spots = array (); 6 7 $sql = " SELECT spots.* 8 FROM spots 9 WHERE spots. creator = ". 10 Utils :: gpcaddslashes ( ( int ) $userid )." "; $query = MyDb :: query ( $sql ); 13 if( $query - > rowcount () == 0) return null ; $rows = $query - > fetchall (); 16 foreach ( $rows as $row ) { $spot = Mapper :: mapspot ( $row ); 19 $spots [] = $spot ; } return $spots ; } 49

70 50 PŘÍLOHA C. UKÁZKY ZDROJOVÝCH KÓDŮ Listing C.2: Ukázka vkládací operace nad relační databází 1 public function createnewuser ( RegistrationForm 2 $data ){ 3 4 $sql = " INSERT INTO users ( id, name, 5 surname, login, password ) 6 VALUES (0, ". Utils :: gpcaddslashes ( $data 7 -> getname ()). 8 ", ". Utils :: gpcaddslashes ($data -> getsurname ()). 9 ", ". Utils :: gpcaddslashes ($data -> get ()). 10 ", ". Utils :: gpcaddslashes ( /* hashovani hesla */ ) 11." );"; MyDb :: query ( $sql ); return $this - > getuserby ( $data - > get ()); }

71 51 Listing C.3: Ukázka vkládací operace do joinovací tabulky nad relační databází 1 public function add AttendingUs ertoevent ( $userid, 2 $eventid, $attendtypeid, 3 $addpoints, $addkarma ){ 4 5 if (! isset ( $userid ) 6! isset ( $eventid )) return null ; 7 8 if( $addpoints ) { 9 DaoFactory :: getuserdao () 10 -> increaseusersclassificationpoints ( $userid ); 11 } 12 if( $addkarma ){ 13 DaoFactory :: getuserdao () 14 -> increaseuserskarma ( $userid ); 15 } $sql = " INSERT INTO eventsattendees ( event, 18 user, attendtype ) 19 VALUES ( ". Utils :: gpcaddslashes ( ( int ) $eventid ). 20 ", ". Utils :: gpcaddslashes ( ( int ) $userid ). 21 ", ". Utils :: gpcaddslashes ( 22 ( int ) $attendtypeid )." );"; 23 MyDb :: query ( $sql ); }

72 52 PŘÍLOHA C. UKÁZKY ZDROJOVÝCH KÓDŮ Listing C.4: Ukázka čtecí operace nad bezschémovou databází 1 public function getspotscreatedby ( $userid ) { 2 3 if(! isset ( $userid ) ) return null ; 4 5 $spots = array (); 6 7 $searchdocument = array ( 8 creator. _id => new MongoId ( $userid ) 9 ); $db = new MyDb (); 12 $db -> setcollection (" spots "); 13 $rows = $db - > get ( $searchdocument, null ); if( count ( $rows ) == 0) return null ; foreach ( $rows as $row ) { 19 $spot = Mapper :: mapspot ( $row ); 20 $spots [] = $spot ; } return $spots ; }

73 53 Listing C.5: Ukázka vkládací operace nad bezschémovou databází 1 public function createnewuser ( RegistrationForm 2 $data ) { 3 4 $newuser = array ( 5 " name " => $data -> getname (), 6 " surname " => $data -> getsurname (), 7 " login " => $data -> get (), 8 " password " = > /* hashovani hesla */, 9 " longitude " => null, 10 " latitude " => null, 11 " zoom " => null, 12 " karma " => 0, 13 " profilepicture " = > null, 14 " classificationpoints " = > 0 15 ); $db = new MyDb (); 18 $db -> setcollection (" users "); 19 $db -> insert ( $newuser ); return $this - > getuserby ( 22 $data -> get ()); }

74 54 PŘÍLOHA C. UKÁZKY ZDROJOVÝCH KÓDŮ Listing C.6: Ukázka upravovací operace nad bezschémovou databází 1 public function add AttendingUs ertoevent ( $userid, 2 $eventid, $attendtypeid, $addpoints, 3 $addkarma ) { 4 5 if (! isset ( $userid ) 6! isset ( $eventid )) return null ; 7 8 if( $addpoints ) { 9 DaoFactory :: getuserdao () 10 -> increaseusersclassificationpoints ( $userid ); 11 } 12 if( $addkarma ){ 13 DaoFactory :: getuserdao () 14 -> increaseuserskarma ( $userid ); 15 } $eventtoadd = DaoFactory :: geteventdao () 18 -> geteventbyid ( $eventid ); $searchdocument = array ( 21 _id => new MongoId ( $userid ) 22 ); $updatedocument = array ( $addtoset = > array ( 25 attendedevents = > array ( 26 " _id " => $eventtoadd -> getid (), 27 " eventname " = > $eventtoadd - > geteventname (), 28 " eventurl " = > $eventtoadd - > geteventurl (), 29 " attendtype " = > $attendtypeid, 30 " fromdate " = > $eventtoadd - > getfromdate (), 31 " todate " = > $eventtoadd - > gettodate () 32 ) 33 )); $db = new MyDb (); 36 $db -> setcollection (" users "); 37 $rows = $db - > update ( $searchdocument, 38 $updatedocument ); }

75 55 Listing C.7: Ukázka načtení značek mapy z XML 1 jquery. get (" helpers / SpotsMarkers. xml. php5 ", {}, 2 function ( data ) { 3 4 jquery ( data ). find (" spot "). each ( function () { 5 6 var marker = jquery ( this ); 7 var latlng = new google. maps. LatLng ( 8 parsefloat ( marker. attr (" lat ")), 9 parsefloat ( marker. attr (" lng ")) 10 ); var newmarker = new google. maps. Marker ({ 16 position : latlng, 17 map : map, 18 icon : image, 19 shadow : shadow, 20 title : marker. attr (" name ") 21 }); var markersbubble = new google. maps. InfoWindow ( ); google. maps. event. addlistener ( newmarker, click, 28 function () { markersbubble. open ( map, newmarker ); 31 }); }); });

76 56 PŘÍLOHA C. UKÁZKY ZDROJOVÝCH KÓDŮ

77 Příloha D Výsledky akceptačního testu 57

78 58 PŘÍLOHA D. VÝSLEDKY AKCEPTAČNÍHO TESTU Požadavek Systém bude umožňovat registraci nového uživatele. O úspěšné registraci bude systém uživatele informovat em. Systém bude umožňovat přihlášení a odhlášení uživatele. Neregistrovaný uživatel bude mít omezená práva. Bude si moci pouze pasivně prohlížet veřejný obsah. Profil uživatele bude obsahovat fotografii, historii navštívených událostí, seznam oblíbených pozorovacích míst, seznam založených pozorovacích míst, seznam privátních pozorovacích míst a nastavení odebíraných informací o místech. Registrovaný uživatel si bude moci přidat pozorovací místo mezi svá oblíbená místa. Registrovaný uživatel si bude moci nastavit preferovanou úroveň přiblížení a výchozí pozici mapy (domácí souřadnice). Registrovaný uživatel bude moci vytvářet pozorovací místa. Registrovaný uživatel bude moci vytvářet události (i na místech, které sám nezaložil, pokud je toto místo veřejné nebo pokud je místo privátní, ale uživatel je v seznamu privátních pozorovatelů tohoto místa). Registrovaný uživatel se bude moci přihlásit k odběru informací o událostech na pozorovacích místech (např. založení nové události). Registrovaný uživatel dostane za každých 10 návštěv pozorovacích míst (jiných, než těch, které sám vytvořil) jeden volný bod hodnocení. Tento bod hodnocení může registrovaný uživatel použít k zlepšení hodnocení pozorovacího místa. Každá navštívená událost registrovaného uživatele bude zaznamenávána. Součet těchto návštěv bude odpovídat uživatelovo osobnímu hodnocení (karma). Registrovaný uživatel se bude moci přihlásit k události se stavy: Možná se zúčastním, zúčastním se, jsem na místě, ale nepozoruji, jsem na místě a pozoruji. Splněno ano ano ano ano ano ano ano ano ano ano ano ano Tabulka D.1: Akceptační test požadavků týkajících se uživatele

79 59 Požadavek Pozorovací místo bude obsahovat popis, zeměpisné souřadnice, datum založení, zakladatele, komentáře registrovaných uživatelů a seznam událostí na tomto místě. Událost bude obsahovat popis, pozorovací místo, datum založení, zakladatele, seznam účastníků a hlášení z pozorování. Pozorovací místa budou privátní a veřejná. Privátní pozorovací místa budou viditelná pouze pro vyjmenované pozorovatele. Veřejná místa budou viditelná pro všechny. Vyjmenovat pozorovatele privátního místa bude moci pouze jeho zakladatel. K pozorovacímu místu bude moci registrovaný uživatel přidat komentář. Všichni účastníci události budou moci k této události přidat multimediální hlášení, do kterého bude možné přidávat videa z YouTube a obrázky. Splněno ano ano ano ano ano ano Tabulka D.2: Akceptační test požadavků týkajících se pozorovacích míst a událostí Požadavek V systému budou pozorovací místa a události. Události lze vytvořit pouze na pozorovacích místech. Google Mapa bude zobrazovat pozorovací místa. Na Google Mapě budou odlišena (zvýrazněna) ta pozorovací místa, kde právě někdo pozoruje. Otevřený detail (bublina v Google maps) pozorovacího místa na mapě bude obsahovat aktuální pozorování. Úvodní stránka bude obsahovat seznam pozorovacích míst, setříděných podle vzdálenosti od aktuálního středu zobrazené mapy. Vedle mapy bude tlačítko pro přechod na domácí souřadnice. Systém bude nabízet sérii ikon pro různé druhy objektů na mapě. Systém bude obsahovat tři role: neregistrovaný uživatel, registrovaný uživatel a administrátor. Administrátor bude moci archivovat pozorovací místa. Administrátor bude mít práva pro přístup do všech pozorovacích míst, včetně těch privátních. Splněno ano ano ano ano ano ano ano ano ano ano Tabulka D.3: Akceptační test ostatních požadavků

80 60 PŘÍLOHA D. VÝSLEDKY AKCEPTAČNÍHO TESTU

81 Příloha E Instalační a uživatelská příručka E.1 Instalační příručka E.1.1 PHP + MySQL Aplikace byla vyvíjena na PHP verze 5.3.1, serveru Apache verze a MySQL verze Vše zmíněné lze jednoduše nainstalovat pomocí balíčku XAMPP (verze 1.7.3) (http://www.apachefriends.org/en/xampp.html). Již v době psaní této dokumentace však byla vydána novější verze (s novější verzí PHP apod.). Použití novější verze by nemělo představovat problém, dokud všechny systémy zajišťují zpětnou kompatibilitu, což však nemusí vždy platit (zejména u PHP). V takovém případě je možné stáhnout starší verzi XAMPPu (http://sourceforge.net/projects/xampp/files/). XAMPP (pro Windows) lze nalézt také na přiloženém CD v adresáři execution-environments. Samozřejmě je také možné provést instalaci každé komponenty zvlášť. Výhodou balíčku XAMPP je kromě kompaktnosti všech tří důležitých systémů pro vývoj v PHP i instalace nejčastěji používaných ovladačů. Pro připojení se z PHP k MySQL (ale i MongoDB) už tedy není třeba instalovat další komponenty. E.1.2 MongoDB Pro testování běhu aplikace nad bezschémovou databází je nutné nainstalovat MongoDB server (http://www.mongodb.org/). Při implementaci byl použit server verze E.1.3 Nahrání souborů na server Po instalaci serverů je nutné do veřejně dostupného adresáře aplikačního serveru nahrát soubory aplikace (viz přiložené CD). Kromě toho je také nutné nastavit práva pro zápis adresářům graphics/upload/profiles a graphics/upload/reports. 61

82 62 PŘÍLOHA E. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA E.1.4 Konfigurace aplikace Konfigurace aplikace probíhá pouze v souboru config.php5. Celý soubor je komentovaný, nicméně pro spuštění aplikace postačuje upravit hodnoty těchto konstant: ADR URL adresa aplikace, bez konečného lomítka. DB_NAME Název databáze. HOST URL adresa databázového serveru. USER Uživatelské jméno pro přístup do databáze. PASSWORD Heslo pro přístup do databáze. Přidání administrátorského účtu lze provést ve třídě Administrators, která se též nachází v souboru config.php5 (tento uživatel však musí být v aplikaci registrován klasickým způsobem, nedojde k jeho automatickému vytvoření na pořadí těchto operací nezáleží). E.2 Uživatelská příručka Systém neobsahuje složité uživatelské rozhraní a lze se v něm orientovat i bez uživatelské příručky. Uvádím pouze popis některých stránek systému. Po spuštění aplikace (pokud není v Apache nastaven soubor index.php5 jako možný automatický vstupní soubor, je třeba za adresu serveru vložit index.php5 ) se zobrazí úvodní obrazovka E.1. Zde je možné se přihlásit nebo registrovat (vpravo nahoře). Na profilové stránce uživatele, kterou je možné vidět na obrázku E.2, lze uložit výchozí souřadnice mapy, založit nové pozorovací místo či nahrát profilovou fotografii. Na stránce pozorovacího místa (E.3) je možné vedle názvu místa vidět až tři druhy ikon (pokud máme místo přidané mezi oblíbenými, odebíráme z něj novinky nebo se jedná o místo soukromé). Nachází se zde také ovládací prvky pro přidání právě prohlíženého místa mezi oblíbené, přihlášení se k odběru novinek či založení nové události. Také zde lze k místu přidat komentář. Pokud je zobrazené místo privátní a právě přihlášený uživatel je jeho zakladatel, lze zde také přidávat privátní pozorovatele. Na stránce události (E.4) lze nastavit účást na této události a v případě, že je aktuální uživatel k události již přihlášen, je zde také tlačítko pro přidání nového záznamu z pozorování. E.2.1 Administrace Administrace aplikace se nachází na adrese aplikace v souboru admin.php5 a je přístupná pouze administrátorům. Přihlášený administrátor má k dispozici odkaz mířící do administrace přímo v aplikaci a to vpravo nahoře (za svým jménem).

83 E.2. UŽIVATELSKÁ PŘÍRUČKA Obrázek E.1: Ukázka úvodní stránky aplikace Obrázek E.2: Ukázka profilové stránky uživatele 63

84 64 PŘÍLOHA E. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA Obrázek E.3: Ukázka stránky pozorovacího místa Obrázek E.4: Ukázka stránky události

Použití databází na Webu

Použití databází na Webu 4IZ228 tvorba webových stránek a aplikací Jirka Kosek Poslední modifikace: $Date: 2010/11/18 11:33:52 $ Obsah Co nás čeká... 3 Architektura webových databázových aplikací... 4 K čemu se používají databázové

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK Systém WorkWatch je určen pro malé a střední firmy, které se zabývají službami nebo zakázkovou výrobou. Zajistí dokonalý přehled o všech zakázkách a jejich rozpracovanosti.

Více

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

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

Více

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE WEBOWÉ STRÁNKY TŘÍD KAMIL POPELKA ZÁVĚREČNÁ MATURITNÍ PRÁCE BRNO 2011 Prohlášení Prohlašuji, že maturitní práce je mým původním autorským dílem, které

Více

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Příručka uživatele HELPDESK GEOVAP

Příručka uživatele HELPDESK GEOVAP HELPDESK GEOVAP verze 1.2 11.11.2008 OBSAH 1 REGISTRACE DO HELPDESK...1 2 PŘIHLÁŠENÍ A ODHLÁŠENÍ...1 3 ZÁKLADNÍ OBRAZOVKA HELPDESK...2 4 PŘEHLED HLÁŠENÍ...2 5 ZALOŽENÍ NOVÉHO HLÁŠENÍ...3 6 ZOBRAZENÍ/EDITACE

Více

Maturitní projekt do IVT Pavel Doleček

Maturitní projekt do IVT Pavel Doleček Maturitní projekt do IVT Pavel Doleček CO FILMBOOK JE Filmbook je uzavřená webová aplikace pro celkovou správu informací a dat souvisejících se sledováním filmů. Primárně je zaměřen na uchovávání a spravování

Více

Individuální projekt z předmětu webových stránek 2012/2013 - Anketa

Individuální projekt z předmětu webových stránek 2012/2013 - Anketa Individuální projekt z předmětu webových stránek 2012/2013 - Anketa Daniel Beznoskov, 2 IT A Skupina 1 Úvod Prohlášení o autorství Prohlašuji, že jsem individuální projekt z předmětu webových stránek na

Více

Využití OOP v praxi -- Knihovna PHP -- Interval.cz

Využití OOP v praxi -- Knihovna PHP -- Interval.cz Page 1 of 6 Knihovna PHP Využití OOP v praxi Po dlouhé teorii přichází na řadu praxe. V následujícím textu si vysvětlíme možnosti přístupu k databázi pomocí různých vzorů objektově orientovaného programování

Více

BALISTICKÝ MĚŘICÍ SYSTÉM

BALISTICKÝ MĚŘICÍ SYSTÉM BALISTICKÝ MĚŘICÍ SYSTÉM UŽIVATELSKÁ PŘÍRUČKA Verze 2.3 2007 OBSAH 1. ÚVOD... 5 2. HLAVNÍ OKNO... 6 3. MENU... 7 3.1 Soubor... 7 3.2 Měření...11 3.3 Zařízení...16 3.4 Graf...17 3.5 Pohled...17 1. ÚVOD

Více

Operátory ROLLUP a CUBE

Operátory ROLLUP a CUBE Operátory ROLLUP a CUBE Dotazovací jazyky, 2009 Marek Polák Martin Chytil Osnova přednášky o Analýza dat o Agregační funkce o GROUP BY a jeho problémy o Speciální hodnotový typ ALL o Operátor CUBE o Operátor

Více

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz Databáze II 1. přednáška Helena Palovská palovska@vse.cz Program přednášky Úvod Třívrstvá architektura a O-R mapování Zabezpečení dat Role a přístupová práva Úvod Co je databáze Mnoho dat Organizovaných

Více

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19 3 Obsah Novinky v tomto vydání 10 Význam základních principů 11 Výuka principů nezávisle na databázových produktech 12 Klíčové pojmy, kontrolní otázky, cvičení, případové studie a projekty 12 Software,

Více

Obsah. Úvod 11 O autorovi 11 Koncept knihy 11 Zpětná vazba od čtenářů 12 Zdrojové kódy ke knize 12 Errata 12 ČÁST I VÝVOJ MOBILNÍ APLIKACE

Obsah. Úvod 11 O autorovi 11 Koncept knihy 11 Zpětná vazba od čtenářů 12 Zdrojové kódy ke knize 12 Errata 12 ČÁST I VÝVOJ MOBILNÍ APLIKACE Úvod 11 O autorovi 11 Koncept knihy 11 Zpětná vazba od čtenářů 12 Zdrojové kódy ke knize 12 Errata 12 ČÁST I VÝVOJ MOBILNÍ APLIKACE KAPITOLA 1 Vývojové prostředí a výběr frameworku 15 PhoneGap 15 jquery

Více

Dolování v objektových datech. Ivana Rudolfová

Dolování v objektových datech. Ivana Rudolfová Dolování v objektových datech Ivana Rudolfová Relační databáze - nevýhody První normální forma neumožňuje vyjádřit vztahy A je podtypem B nebo vytvořit struktury typu pole nebo množiny SQL omezení omezený

Více

Ukládání a vyhledávání XML dat

Ukládání a vyhledávání XML dat XML teorie a praxe značkovacích jazyků (4IZ238) Jirka Kosek Poslední modifikace: $Date: 2014/12/04 19:41:24 $ Obsah Ukládání XML dokumentů... 3 Ukládání XML do souborů... 4 Nativní XML databáze... 5 Ukládání

Více

M4 PDF rozšíření. Modul pro PrestaShop. http://www.presta-addons.com

M4 PDF rozšíření. Modul pro PrestaShop. http://www.presta-addons.com M4 PDF rozšíření Modul pro PrestaShop http://www.presta-addons.com Obsah Úvod... 2 Vlastnosti... 2 Jak modul funguje... 2 Zdroje dat... 3 Šablony... 4 A. Označení šablon... 4 B. Funkce Smarty... 5 C. Definice

Více

27 Evidence kasiček. Popis modulu. Záložka Organizované sbírky

27 Evidence kasiček. Popis modulu. Záložka Organizované sbírky 27 Evidence kasiček Uživatelský modul Evidence kasiček realizuje evidenci všech pořádaných sbírek, jednotlivých kasiček sbírky, dále pak evidenci výběrů kasiček s návazností na pokladnu (příjem výběru

Více

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná. Průběžná klasifikace Nová verze modulu Klasifikace žáků přináší novinky především v práci s průběžnou klasifikací. Pro zadání průběžné klasifikace ve třídě doposud existovaly 3 funkce Průběžná klasifikace,

Více

Postup. Úvodem. Hlavní myšlenka frameworku. application. system. assets. uploads

Postup. Úvodem. Hlavní myšlenka frameworku. application. system. assets. uploads Postup Úvodem Můj úkol při tomto projektu byl vytvořit model pro data, dle návrhového vzoru MVC. Jelikož v poslední době pracuji spíše s návrhovým vzorem HMVC (http://en.wikipedia.org/wiki/hmvc) ve frameworku

Více

1 Vytvoření oboustranné informační platformy MČ občan (mobilní aplikace + rozhraní API pro přenos informací do webových stránek městské části)

1 Vytvoření oboustranné informační platformy MČ občan (mobilní aplikace + rozhraní API pro přenos informací do webových stránek městské části) PŘÍLOHA Č. 1 ZADÁVACÍ DOKUMENTACE TECHNICKÁ SPECIFIKACE ZÁKAZNÍKA 1 Vytvoření oboustranné informační platformy MČ občan (mobilní aplikace + rozhraní API pro přenos informací do webových stránek městské

Více

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Webové aplikace Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Harmonogram Dopolední blok 9:00 12:30 Ing. Dostal Úvod, XHTML + CSS Ing. Brada,

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

Maturitní otázky z předmětu PROGRAMOVÁNÍ

Maturitní otázky z předmětu PROGRAMOVÁNÍ Wichterlovo gymnázium, Ostrava-Poruba, příspěvková organizace Maturitní otázky z předmětu PROGRAMOVÁNÍ 1. Algoritmus a jeho vlastnosti algoritmus a jeho vlastnosti, formy zápisu algoritmu ověřování správnosti

Více

Bridge. Známý jako. Účel. Použitelnost. Handle/Body

Bridge. Známý jako. Účel. Použitelnost. Handle/Body Bridge Bridge Známý jako Handle/Body Účel odděluje abstrakci (rozhraní a jeho sémantiku) od její konkrétní implementace předchází zbytečnému nárůstu počtu tříd při přidávání implementací používá se v době

Více

PŘÍLOHA C Požadavky na Dokumentaci

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

Více

Postupy práce se šablonami IS MPP

Postupy práce se šablonami IS MPP Postupy práce se šablonami IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Postupy práce se šablonami IS MPP Modul

Více

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav Střední průmyslová škola a Vyšší odborná škola technická Brno, Sokolská 1 Šablona: Název: Téma: Autor: Číslo: Anotace: Inovace a zkvalitnění výuky prostřednictvím ICT Databáze Základní seznámení s MySQL

Více

Nástrojová lišta v editačním poli

Nástrojová lišta v editačním poli Nástrojová lišta v editačním poli Název projektu PŘEJÍT NA konkrétní sekci webu ZOBRAZIT zobrazí a) pracovní verzi webu (tj. nepublikovanou) b) publikovanou verzi webu a) Odstranit odstraní zobrazenou

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Semestrální práce 2 znakový strom

Semestrální práce 2 znakový strom Semestrální práce 2 znakový strom Ondřej Petržilka Datový model BlockFileRecord Bázová abstraktní třída pro záznam ukládaný do blokového souboru RhymeRecord Konkrétní třída záznamu ukládaného do blokového

Více

Vhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging

Vhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging Vhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging 1. Vhodnost nasazení jednotlivých webových architektur - toto je podle Klímy

Více

Informační systém pro e-learning manuál

Informační systém pro e-learning manuál Informační systém pro e-learning manuál Verze 1.00 Úvod Tento dokument popisuje způsob práce s informačním systémem pro elektronické vzdělávání. Systém je určený pro vytvoření elektronického kurzu a jeho

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

Akceptační test. Úvod

Akceptační test. Úvod Verze 1.5 Akceptační test Úvod Tento dokument popisuje postup ověření softwaru, ohledně pokrytí požadavků. Obsahuje vstupní a výstupní parametry pro každý test. Testy Aplikace je napsána pro více uživatelských

Více

WNC::WebNucleatCreator

WNC::WebNucleatCreator Tomáš Dlouhý WNC::WebNucleatCreator Verze: 5.1 1 Obsah Obsah...2 Úvod...3 Novinky...3 Požadavky...4 Instalace...4 Přihlášení se do WNC...6 Moduly...7 Modul Blog...7 Modul Categories...8 Modul News...8

Více

Návrh uživatelských rozhraní NOV-WEB. Jakub Bartoš, Pavel Dvořák, Jakub Motyčka, Kamil Procházka

Návrh uživatelských rozhraní NOV-WEB. Jakub Bartoš, Pavel Dvořák, Jakub Motyčka, Kamil Procházka Návrh uživatelských rozhraní D3 NOV-WEB Web pro stránky předmětů Jakub Bartoš, Pavel Dvořák, Jakub Motyčka, Kamil Procházka Prototyp - Prototyp je vytvořen formou webové stránky. Výchozí stránka prototypu

Více

ANOTACE vytvořených/inovovaných materiálů

ANOTACE vytvořených/inovovaných materiálů ANOTACE vytvořených/inovovaných materiálů Číslo projektu Číslo a název šablony klíčové aktivity Tematická oblast Formát Druh učebního materiálu Druh interaktivity CZ.1.07/1.5.00/34.0722 III/2 Inovace a

Více

1. Dědičnost a polymorfismus

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

Více

Roční periodická zpráva projektu

Roční periodická zpráva projektu WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových

Více

Návrh a tvorba WWW stránek 1/14. PHP a databáze

Návrh a tvorba WWW stránek 1/14. PHP a databáze Návrh a tvorba WWW stránek 1/14 PHP a databáze nejčastěji MySQL součástí balíčků PHP navíc podporuje standard ODBC PHP nemá žádné šablony pro práci s databází princip práce s databází je stále stejný opakované

Více

ZADÁVACÍ DOKUMENTACE Comenis 2.0

ZADÁVACÍ DOKUMENTACE Comenis 2.0 ZADÁVACÍ DOKUMENTACE Comenis 2.0 jako příloha Výzvy k podání nabídek v rámci projektu Distanční jazykové vzdělávání pomocí M-learningu CZ.1.07/3.2.10/04.0011 Akademie Jana Amose Komenského Jičín Název

Více

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13 Obsah Úvodem 9 1. Úvod do Ajaxu 11 Jak Ajax funguje? 13 Popis 13 Ukázky 13 Jaké jsou možnosti tvorby interaktivních webových aplikací? 15 Co je třeba znát? 16 Jak fungují technologie Ajaxu 16 Jak funguje

Více

Reranking založený na metadatech

Reranking založený na metadatech České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Reranking založený na metadatech MI-VMW Projekt IV - 1 Pavel Homolka Ladislav Kubeš 6. 12. 2011 1

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

DELTA - STŘEDNÍ ŠKOLA INFORMATIKY A EKONOMIE, s.r.o. Obor informační technologie AJAX ESHOP. Maturitní projekt. Třída:

DELTA - STŘEDNÍ ŠKOLA INFORMATIKY A EKONOMIE, s.r.o. Obor informační technologie AJAX ESHOP. Maturitní projekt. Třída: DELTA - STŘEDNÍ ŠKOLA INFORMATIKY A EKONOMIE, s.r.o. Obor informační technologie AJAX ESHOP Maturitní projekt Vypracoval: Denis Ptáček Třída: 4B Rok: 2014/2015 Obsah 1. Použité nástroje... 3 1.1 NetBeans

Více

Vstupní požadavky, doporučení a metodické pokyny

Vstupní požadavky, doporučení a metodické pokyny Název modulu: Základy PHP Označení: C9 Stručná charakteristika modulu Modul je orientován na tvorbu dynamických stánek aktualizovaných podle kontextu volání. Jazyk PHP umožňuje velmi jednoduchým způsobem

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

Elektronická podpora výuky předmětu Komprese dat

Elektronická podpora výuky předmětu Komprese dat Elektronická podpora výuky předmětu Komprese dat Vojtěch Ouška ouskav1@fel.cvut.cz 19. června 2006 Vojtěch Ouška Elektronická podpora výuky předmětu Komprese dat - 1 /15 Co je to SyVyKod? SyVyKod = Systém

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

Maturitní témata Školní rok: 2015/2016

Maturitní témata Školní rok: 2015/2016 Maturitní témata Školní rok: 2015/2016 Ředitel školy: Předmětová komise: Předseda předmětové komise: Předmět: PhDr. Karel Goš Informatika a výpočetní technika Mgr. Ivan Studnička Informatika a výpočetní

Více

O Apache Derby detailněji. Hynek Mlnařík

O Apache Derby detailněji. Hynek Mlnařík O Apache Derby detailněji Hynek Mlnařík Agenda Historie Vlastnosti Architektura Budoucnost Historie 1997 Cloudscape Inc. - JBMS 1999 Informix Software, Inc. odkoupila Cloudscape, Inc. 2001 IBM odkoupila

Více

Modul Konfigurace. 2006... MTJ Service, s.r.o.

Modul Konfigurace. 2006... MTJ Service, s.r.o. Modul Konfigurace Modul Konfigurace Představení Menu konfigurace sdružuje všechny konfigurační příkazy k celému systému Soft-4-Sale. Dále konfigurace kopíruje jednotlivé moduly systému tzn. že existuje

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

E-NABÍDKA PARTNER.REDA.CZ

E-NABÍDKA PARTNER.REDA.CZ E-NABÍDKA PARTNER.REDA.CZ Reda e-nabídka představuje mocný nástroj, díky kterému mohou naši registrovaní klienti přímo z prostředí e-shopu partner.reda.cz vytvářet vlastní produktové nabídky pro své zákazníky.

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

Uživatelská příručka pro ředitele škol

Uživatelská příručka pro ředitele škol Národní šetření výsledků žáků v počátečním vzdělávání Uživatelská příručka pro ředitele škol Název souboru: Modul IDM - Uživatelská příručka pro ředitele škol V2.doc Strana 1 Obsah 1 Úvod... 3 2 Přihlášení

Více

Databázové aplikace pro internetové prostředí. 01 - PHP úvod, základní princip, vkládání skriptu, komentáře, výpis na obrazovku

Databázové aplikace pro internetové prostředí. 01 - PHP úvod, základní princip, vkládání skriptu, komentáře, výpis na obrazovku Databázové aplikace pro internetové prostředí 01 - PHP úvod, základní princip, vkládání skriptu, komentáře, výpis na obrazovku Projekt: Inovace výuky prostřednictvím ICT Registrační číslo: CZ.1.07/1.5.00/34.250

Více

Webové stránky fotbalového klubu

Webové stránky fotbalového klubu Semestrální práce pro X36WWW Webové stránky fotbalového klubu DOKUMENTACE autor: David Komárek 1. Zadání Naprogramujte informační web fotbalového klubu. V klubu jsou registrována dvě mužstva, A mužstvo

Více

Geis Point Plugin Map

Geis Point Plugin Map Str. 1/5 Geis Point Plugin Map Rozhraní pro vložení výdejního místa do objednávky na e-shopu Str. 2/5 Obsah 1. Co je Geis Point Plugin Map?... 3 2. Jak to funguje?... 3 3. Obecný postup nasazení... 3 4.

Více

Obecní webové stránky. www.benetice.net

Obecní webové stránky. www.benetice.net Obecní webové stránky www.benetice.net Obsah Registrace uživatele Panel uživatele Uživatelský profil Tvorba článků Skupiny Profily odběr informací Reakce na informaci TinyMCE Správa skupin Registrace uživatele

Více

Technologické postupy práce s aktovkou IS MPP

Technologické postupy práce s aktovkou IS MPP Technologické postupy práce s aktovkou IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Technologické postupy práce

Více

emanuál Rozvoj ICT kompetencí žáků a pedagogů v oblasti zpracování grafiky a předtiskové přípravy pro studenty kurzu v LMS systému Moodle

emanuál Rozvoj ICT kompetencí žáků a pedagogů v oblasti zpracování grafiky a předtiskové přípravy pro studenty kurzu v LMS systému Moodle emanuál pro studenty kurzu Rozvoj ICT kompetencí žáků a pedagogů v oblasti zpracování grafiky a předtiskové přípravy v LMS systému Moodle CZ.1.07/1.1.22/02.0053 Obsah CO JE E-LEARNINGOVÝ E KURZ?.........

Více

1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4

1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4 CRM SYSTÉM KORMORÁN PŘÍRUČKA ADMINISTRÁTORA Obsah 1 Administrace systému 3 1.1 Uživatelské účty.................................. 3 1.2 Přístupová práva................................. 3 1.3 Moduly.......................................

Více

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

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

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

Databáze v MS ACCESS

Databáze v MS ACCESS 1 z 14 19.1.2014 18:43 Databáze v MS ACCESS Úvod do databází, návrh databáze, formuláře, dotazy, relace 1. Pojem databáze Informací se data a vztahy mezi nimi stávají vhodnou interpretací pro uživatele,

Více

PROFI TDi s.r.o. 696 37, Želetice 40 www.profi-tdi.cz info@profi-tdi.cz. Návod k používání systému OTDI.CZ

PROFI TDi s.r.o. 696 37, Želetice 40 www.profi-tdi.cz info@profi-tdi.cz. Návod k používání systému OTDI.CZ Návod k používání systému OTDI.CZ Vážený kliente. Děkujeme za projevený zájem o náš on-line systém evidence kontrol, určený speciálně pro účely dozorů staveb. Systém OTDI.CZ nabízí svým uživatelům zejména:

Více

Dokumentace pro správu zlínských DUM

Dokumentace pro správu zlínských DUM Dokumentace pro správu zlínských DUM Obsah 1 Správa administrátorů... 3 1.1 Přidávání administrátorů... 3 1.2 Nastavování práv administrátorů... 3 1.3 Upravení detailů administrátora... 5 1.4 Aktivování,

Více

APS mini.ed programová nadstavba pro základní vyhodnocení docházky. Příručka uživatele verze 2.2.0.6

APS mini.ed programová nadstavba pro základní vyhodnocení docházky. Příručka uživatele verze 2.2.0.6 APS mini.ed programová nadstavba pro základní vyhodnocení docházky Příručka uživatele verze 2.2.0.6 APS mini.ed Příručka uživatele Obsah Obsah... 2 Instalace a konfigurace programu... 3 Popis programu...

Více

Uživatelská příručka administrativního rozhraní Vědecké knihovny v Olomouci

Uživatelská příručka administrativního rozhraní Vědecké knihovny v Olomouci Držitel certifikátu jakosti ISO 9001:2001 Uživatelská příručka administrativního rozhraní Vědecké knihovny v Olomouci Stránka 1/44 Obsah 1.Redakční systém...4 1.1. Povolené jazykové mutace...4 5.2.1 Překlad

Více

Obsah. Rozdíly mezi systémy Joomla 1.0 a 1.5...15 Systém Joomla coby jednička online komunity...16 Shrnutí...16

Obsah. Rozdíly mezi systémy Joomla 1.0 a 1.5...15 Systém Joomla coby jednička online komunity...16 Shrnutí...16 Obsah Kapitola 1 Seznámení se systémem Joomla!................................. 9 Přehled systémů pro správu obsahu....................................................10 Použití systému pro správu obsahu.....................................................11

Více

Evidence požadavků uživatelů bytů a nebytových prostor

Evidence požadavků uživatelů bytů a nebytových prostor Evidence požadavků uživatelů bytů a nebytových prostor Úvod Pro zjednodušení a zprůhlednění Vaší komunikace se správní firmou (dále jen SF ), která má na starost objekt, v němž se nachází bytový či nebytový

Více

Obsah Úvod 4. TF Wmake 1.5

Obsah Úvod 4. TF Wmake 1.5 Obsah Úvod 4 Struktura systému 5 Uživatelské role 6 Přihlášení do systému 7 Úvodní stránka 8 enu redaktora 9 enu autora 9 azyky 0 Odhlášení ze systému 0 Nastavení Bloky Editace bloku Přidání nového bloku

Více

POKYNY K REGISTRACI PROFILU ZADAVATELE

POKYNY K REGISTRACI PROFILU ZADAVATELE POKYNY K REGISTRACI PROFILU ZADAVATELE Stav ke dni 4. 12. 2012 Obsah: 1 Úvod... 3 1.1 Podmínky provozu... 3 1.2 Pokyny k užívání dokumentu... 3 2 Registrace profilu zadavatele... 4 2.1 Přihlášení uživatele...

Více

NewLink Moravia. CSP aplikace: RedHorse Content management ISM Issue management

NewLink Moravia. CSP aplikace: RedHorse Content management ISM Issue management NewLink Moravia CSP aplikace: RedHorse Content management ISM Issue management Činnost společnosti NewLink NewLink se zabývá webovými aplikacemi a informačními systémy pro průmyslové podniky a obchodní

Více

UAI/612 - Cloudová Řešení. Technologie

UAI/612 - Cloudová Řešení. Technologie UAI/612 - Cloudová Řešení Technologie Rekapitulace Multitenance Bezestavovost Škálovatelnost Cachování Bezpečnost Způsoby nasazení Datová úložiště SQL databáze NoSQL databáze Cloudová datová úložiště (API)

Více

Uživatelská příručka k systému Jídelna inet

Uživatelská příručka k systému Jídelna inet Uživatelská příručka k systému Jídelna inet Internetová část Microdata s.r.o. Verze 2.5 Srpen 2010 Přihlášení do systému... 3 Prohlížení jídelníčku... 4 Objednávání jídel... 4 Přehled Objednávek... 6 Změna

Více

43 HTML šablony. Záložka Šablony v systému

43 HTML šablony. Záložka Šablony v systému 43 HTML šablony Modul HTML šablony slouží ke správě šablon pro výstupy z informačního systému modularis ve formátu HTML. Modul umožňuje k šablonám doplňovat patičku, dokumentaci a vázat šablony na konkrétní

Více

K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/.

K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/. 2. Seznámení K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/. 2.1. Uživatel (učitel) Uživatelem (učitelem) se myslí osoba, která

Více

Integrační modul REX. pro napojení elektronické spisové služby e-spis LITE k informačnímu systému základních registrů. Uživatelská příručka

Integrační modul REX. pro napojení elektronické spisové služby e-spis LITE k informačnímu systému základních registrů. Uživatelská příručka REX a e-spis LITE 2.5.4 - uživatelská příručka Integrační modul REX pro napojení elektronické spisové služby e-spis LITE k informačnímu systému základních registrů Uživatelská příručka www.i.cz Czech Republic

Více

www.dpd.cz/dobirky Uživatelský manuál

www.dpd.cz/dobirky Uživatelský manuál www.dpd.cz/dobirky Uživatelský manuál DPD CZ Obsah 1. Úvod... 3 2. Přihlášení... 3 Přihlášení... 3 Nový uživatel, zapomenuté heslo... 5 3. Nastavení... 6 Nastavení uživatele... 6 Nastavení bankovních účtů...

Více

Uživatelský manuál aplikace. Dental MAXweb

Uživatelský manuál aplikace. Dental MAXweb Uživatelský manuál aplikace Dental MAXweb Obsah Obsah... 2 1. Základní operace... 3 1.1. Přihlášení do aplikace... 3 1.2. Odhlášení z aplikace... 3 1.3. Náhled aplikace v jiné úrovni... 3 1.4. Změna barevné

Více

Logika formulářů úlohy

Logika formulářů úlohy Logika formulářů úlohy Uživatelský/administrační manuál CleverApp s.r.o. 2007/11/03 verze 1.0 CleverApp s.r.o. 2007 1/1 Obsah 1 Úvod... 3 2 Důležité faktory úspěchu řešení ze strany uživatelů... 3 3 Nářadí

Více

11.5.2012. Obsah přednášky 9. Skrývání informací. Skrývání informací. Zapouzdření. Skrývání informací. Základy programování (IZAPR, IZKPR) Přednáška 9

11.5.2012. Obsah přednášky 9. Skrývání informací. Skrývání informací. Zapouzdření. Skrývání informací. Základy programování (IZAPR, IZKPR) Přednáška 9 Obsah přednášky 9 Základy programování (IZAPR, IZKPR) Přednáška 9 Základy dědičnosti, přístupová práva Ing. Michael Bažant, Ph.D. Katedra softwarových technologií Kancelář č. 03 022, Náměstí Čs. legií

Více

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

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

Více

Uživatelský manuál. Aplikace GraphViewer. Vytvořil: Viktor Dlouhý

Uživatelský manuál. Aplikace GraphViewer. Vytvořil: Viktor Dlouhý Uživatelský manuál Aplikace GraphViewer Vytvořil: Viktor Dlouhý Obsah 1. Obecně... 3 2. Co aplikace umí... 3 3. Struktura aplikace... 4 4. Mobilní verze aplikace... 5 5. Vytvoření projektu... 6 6. Části

Více

Reliance 3 design OBSAH

Reliance 3 design OBSAH Reliance 3 design Obsah OBSAH 1. První kroky... 3 1.1 Úvod... 3 1.2 Založení nového projektu... 4 1.3 Tvorba projektu... 6 1.3.1 Správce stanic definice stanic, proměnných, stavových hlášení a komunikačních

Více

Programování v jazyku C# II. 5.kapitola

Programování v jazyku C# II. 5.kapitola Programování v jazyku C# II. 5.kapitola Obsah O ADO.NET Spojení s DB Příkazy Jednoduché čtení DataSet 2/28 ADO.NET ADO - ActiveX Data Object Orientováno na webové aplikace neexistence stavu v HTTP Obecný

Více

ArcGIS Online Subscription

ArcGIS Online Subscription ArcGIS Online Subscription GIS pro organizace ArcGIS Online je GIS v cloudu. Poskytuje služby GIS v prostředí internetu, ať už se jedná o úložné místo, publikaci mapových a geoprocessingových služeb, nebo

Více

SRSW4IT Inventarizační SW. Prezentace aplikace. Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek

SRSW4IT Inventarizační SW. Prezentace aplikace. Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek Prezentace aplikace Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek Osnova Úvod Programovací jazyk - PHP Etapy vývoje Funkce aplikace Co SW umí Na čem se pracuje Vize do budoucna Úvod Úvod Inspirováno

Více

Pryč jsou ty doby, kdy bylo nutné kvůli každé malé úpravě webových stránek shánět odborníka, který

Pryč jsou ty doby, kdy bylo nutné kvůli každé malé úpravě webových stránek shánět odborníka, který Redakční systém JSR Systém pro správu obsahu webových stránek Pryč jsou ty doby, kdy bylo nutné kvůli každé malé úpravě webových stránek shánět odborníka, který měl potřebné znalosti jazyka HTML a jiných

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Olga Rudikova 2. ročník APIN

Olga Rudikova 2. ročník APIN Olga Rudikova 2. ročník APIN Redakční (publikační) systém neboli CMS - content management system (systém pro správu obsahu) je software zajišťující správu dokumentů, nejčastěji webového obsahu. (webová

Více