Oracle APEX - Aplikace pro oceňování nemovitostí

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Oracle APEX - Aplikace pro oceňování nemovitostí Diplomová práce

Autor:

Bc. Michaela Třeštíková Informační technologie a management

Vedoucí práce:

Praha

Ing. Jiří Rezler

Duben, 2009

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracovala samostatně a s použitím uvedené literatury.

V Praze dne 5.dubna 2009

Michaela Třeštíková

Poděkování: Ráda bych touto cestou poděkovala vedoucímu této diplomové práce Ing. Jiřímu Rezlerovi za jeho podněty, nápady a čas, který mi věnoval během tvorby této práce. Jeho cenné rady a připomínky mi byly velkou oporou a pomocí.

Anotace práce Ve své diplomové práci si kladu za cíl na příkladu z praxe ověřit použitelnost a funkčnost nástroje pro vývoj a provoz webových aplikací, dodávaného na trh přední softwarovou firmou na databáze, firmou Oracle. Jedná se o nástroj, který je na trhu znám pod zkratkou Oracle APEX a je poskytován zcela zdarma. Oracle APEX, celým názvem Oracle Application Express, tak jak je firmou Oracle prezentován, má být nástroj pro „expresní“, jinými slovy, rychlou a snadnou tvorbu webových aplikací. Mým základním cílem v diplomové práci není ověřit použitelnost nástroje Oracle APEX pro rychlou tvorbu webových aplikací, ale zejména a hlavně ověřit obecně propagované firemní tvrzení, které prohlašuje, že webovou aplikaci pomocí Oracle APEX, která bude využívat vlastností jedné z celosvětově uznávaných databází, jakou Oracle databáze je, může vytvořit běžný uživatel PC, který zvládá základy práce s tabulkovým editorem a umí pracovat s internetem. Tedy uživatel, který nemá znalosti jak s vývojem aplikací, tak s jejich programováním.

Annotation In my graduation thesis I am focused to examine and test a development tool for design and running a web application. The tool that I have chosen for my thesis is a product of Oracle company and on the market the tool is known as Oracle APEX. Oracle APEX with its long name Oracle Application Express is a tool for rapid application development, it means a tool for quick and easy development. Oracle APEX for web applications uses features of one of the best databases on the current market as Oracle database is. My main goal is to prove Oracle marketing claims that to develop a web application using Oracle APEX is possible without programming experiences only with basic knowledge of PC using. The claims say that a common user who can work with excel editor is able to develop a web application.

Obsah ÚVOD ................................................................................................................................................................ 7 1

PROBLEMATIKA OCEŇOVÁNÍ NEMOVITOSTÍ .......................................................................... 8 1.1 ÚVOD DO OCEŇOVÁNÍ NEMOVITOSTÍ..................................................................................................... 8 1.1.1 Základní pojmy z oblasti oceňování ........................................................................................... 9 1.1.2 Historie oceňování.................................................................................................................... 10 1.2 ZÁKLADNÍ KATEGORIE CEN DLE ÚČELU A ZPŮSOBU OCENĚNÍ .............................................................. 11 1.2.1 Ceny podle cenového předpisu tzv. administrativní ceny ......................................................... 11 1.2.2 Ceny používané v účetnictví ..................................................................................................... 12 1.2.3 Ceny používané v pojišťovnictví ............................................................................................... 12 1.2.4 Obvyklá cena ............................................................................................................................ 12 1.3 METODY STANOVENÍ OBVYKLÉ CENY ................................................................................................. 14 1.3.1 Metoda nákladová .................................................................................................................... 14 1.3.2 Metoda výnosová ...................................................................................................................... 14 1.3.3 Metoda srovnávací ................................................................................................................... 15 1.4 APLIKACE PRO STANOVENÍ OBVYKLÉ CENY ........................................................................................ 15 1.4.1 Existující aplikace..................................................................................................................... 16 1.4.2 Vlastní excel aplikace ............................................................................................................... 16 1.4.3 Obecné požadavky na www aplikaci ........................................................................................ 17

2

ORACLE APEX.................................................................................................................................... 18 2.1 ORACLE APEX – DATOVÁ VRSTVA ..................................................................................................... 20 2.2 ORACLE APEX – APLIKAČNÍ VRSTVA ................................................................................................. 21 2.2.1 Vývojové prostředí .................................................................................................................... 21 2.2.2 Provozní prostředí .................................................................................................................... 23

3

REALIZACE APLIKACE ................................................................................................................... 24 3.1 ODBORNÝ ČLÁNEK.............................................................................................................................. 25 3.1.1 Popis technické použití ............................................................................................................. 25 3.1.2 Aplikační typy uživatelů ............................................................................................................ 26 3.1.3 Úvod a přihlášení ..................................................................................................................... 26 3.1.4 Vyhledávání záznamů ............................................................................................................... 28 3.1.5 Vkládání záznamů ..................................................................................................................... 28 3.1.6 Registrace uživatelů .................................................................................................................. 29 3.1.7 Kontrola bez aplikačního rozhraní ........................................................................................... 29 3.2 SEZNAM POŽADAVKŮ .......................................................................................................................... 30 3.2.1 Požadavky nepřihlášeného uživatele ........................................................................................ 30 3.2.2 Požadavky přihlášeného uživatele ............................................................................................ 31 3.2.3 Požadavky aplikačního administrátora .................................................................................... 33 3.3 USE CASE SCÉNÁŘE A DIAGRAM .......................................................................................................... 33 3.3.1 Základní diagram spolupráce ................................................................................................... 34 3.3.2 Use Case scénáře...................................................................................................................... 34 3.4 DIAGRAM AKTIVIT............................................................................................................................... 38 3.4.1 Aktivity nepřihlášeného uživatele ............................................................................................. 39 3.4.2 Aktivity přihlášeného uživatele ................................................................................................. 42 3.4.3 Aktivity aplikačního administrátora ......................................................................................... 46 3.5 RAD IMPLEMENTACE .......................................................................................................................... 48 3.5.1 Implementační nástroje ............................................................................................................ 48 3.5.2 Databázové objekty .................................................................................................................. 51 3.5.3 Vývoj aplikace .......................................................................................................................... 53

5

4

POUŽÍVÁNÍ APLIKACE .................................................................................................................... 59 4.1 4.2 4.3

NEPŘIHLÁŠENÝ UŽIVATEL ................................................................................................................... 59 PŘIHLÁŠENÝ UŽIVATEL ....................................................................................................................... 62 APLIKAČNÍ ADMINISTRÁTOR ............................................................................................................... 66

VÝSLEDKY .................................................................................................................................................... 68 ZÁVĚRY A DOPORUČENÍ ......................................................................................................................... 69 SEZNAM POUŽITÉ LITERATURY .............................................................................................................. I SEZNAM DIAGRAMŮ ................................................................................................................................. III SEZNAM TABULEK..................................................................................................................................... III SEZNAM OBRÁZKŮ .................................................................................................................................... IV PŘÍLOHY .........................................................................................................................................................A

6

Úvod Ověřit možnost tvorby webové aplikace bez programátorských znalostí je hlavním cílem mé diplomové práce. Na tuto myšlenku mě přivedl reklamní materiál k produktu APEX firmy Oracle, vydaný pod názvem „Když už tabulkové editory nestačí“. A jak je v něm uvedeno, dokument je určen „běžným uživatelům PC, kteří zvládají základy práce s tabulkovými editory a umějí pracovat s Internetem1“. Úvodní kapitoly diplomové práce věnuji problematice oceňování nemovitostí a seznámím s důvody, které vedou odhadce nemovitostí nebo jiné subjekty zajímající se o tržní ceny nemovitostí, k tvorbě vlastních databází, kde si uchovávají informace o realizovaných prodejích. Toto zasvěcení do problematiky daného oboru je nutné z důvodu pochopení potřeby realizace webové aplikace a zejména z důvodu vydefinování požadavků na vyvíjenou aplikaci. Dále v kapitolách představím vybraný nástroj Oracle APEX a to jak z pohledu uživatelského, tak z pohledu požadavků na provoz a seznámím s jeho architekturou. Nedílnou součástí nástroje Oracle APEX je i Oracle databáze, která slouží jak k ukládání a správě dat, tak také jako úložiště vytvořené aplikace a jako neoddělitelná část prostředí provozního. Ve stručnosti se zaměřím i na základní architekturu a základní vlastnosti Oracle databáze a provedu vlastní zhodnocení těch databázových vlastností, které pro tento typ aplikace považuji za stěžejní. V navazujících kapitolách provedu seznámení s vývojovým prostředím Oracle APEX a to z pohledu uživatele PC, který nemá programátorské znalosti. Po seznámení s vývojovým prostředím přejdu k vlastní realizaci aplikace. Základ pro realizaci mi budou tvořit datové soubory s přehledem uskutečněných prodejů, které mám vytvořené a k jejichž správě používám tabulkový editor MS Excel. Do požadavků na aplikaci zahrnu i takové požadavky, které jsou v tabulkovém editoru náročné na realizaci. Po vytvoření aplikace představím vytvořené uživatelské prostředí a způsob používání. Závěr diplomové práce budu věnovat výsledkům mého ověření, zda je možné vytvořit provozu schopnou webovou aplikaci bez programátorských znalostí pomocí nástroje Oracle APEX.

1

část věty citována z dokumentu ORACLE Corporation, Když už tabulkové editory nestačí, r. 2007, strana 3

7

1 Problematika oceňování nemovitostí Pochopení problematiky oceňování nemovitostí je základním stavebním prvkem uvažované aplikace. Bez pochopení a základního uvedení do této problematiky není možné vydefinovat potřebné požadavky na aplikaci a bez stanovení jasně daných požadavků je realizace jakékoliv aplikace nemožná. Vzhledem k uvedeným základním předpokladům k úspěšné realizaci aplikace je nyní nutné se s problematikou oceňování nemovitostí seznámit blíže.

1.1 Úvod do oceňování nemovitostí Oceňování je činností, kdy je určitému předmětu, souboru předmětů, práv apod. přiřazován peněžní ekvivalent. Je základním nástrojem řízení hodnoty. Je přitom třeba rozlišovat pojmy cena a hodnota.2 Cenu vytváří trh, je to vztah mezi nabídkou a poptávkou v daném místě a čase, vyjadřuje se v peněžních jednotkách. Nemůže ji stanovit odhadce, ale určuje ji prodávající a kupující. Oproti tomu hodnota se stanovuje výpočtem nebo odhadem. Je nutno rozlišovat jakým způsobem byla hodnota stanovena, protože dle předpisů a zákonů se velmi liší od cen na trhu. Přesnou hranici mezi cenou a hodnotou nelze prakticky oddělit, protože hodnota, stanovená např. odhadem, je vlastně součástí ceny, neboli jádrem ceny, stanovené trhem. Důležité je odpovědět si na otázky co lze ocenit, jak a proč je nutné oceňovat. Ocenit lze vlastně všechno. Pod pojmem ocenění chápeme stanovení hodnoty libovolného hmotného i nehmotného statku. Tento informační systém se bude zabývat oceňováním pouze nemovitostí. Na otázku jak ocenit, je důležité uvědomit si, že neoceňujeme holou věc, například prostory v nemovitosti, ale oceňujeme využitelnost daných prostor. Podstatou je porozumění užitečnosti, činnosti oceňovaného majetku.3. Oceňovat je nutné proto, že bez ocenění bychom neznali hodnotu majetku. Důležitou roli proto hraje, pro jaké účely je nutné oceňovat, tím vyplývající způsoby ocenění, které nyní v praxi používají. Tyto účely jsou detailněji popsány v kapitole 1.2 Základní kategorie cen dle účelu a způsobu ocenění.

2

Kovandová, Marie, server LAMA, dostupné z URL: http://www.la-ma.cz/ocenem/on.php?co=1 8

1.1.1 Základní pojmy z oblasti oceňování Prvním pojmem v oblasti oceňování nemovitostí je, co je to Nemovitost. Nemovitost je Specifikována Zákonem č. 40/1964 Sb., Občanský zákoník, § 1194 dělí se na věci movité a nemovité. Nemovité věci jsou pozemky a stavby spojené se zemí pevným základem. Pozemkem se rozumí část zemského povrchu oddělená od sousedních částí hranicí územní jednotky nebo hranicí katastrálního území, hranicí vlastnickou, hranicí držby, hranicí druhů pozemků, popř. rozhraním způsobu využití těchto pozemků. Parcela je název pro pozemek, který je geometricky a polohově určen, zobrazen v katastrální mapě s parcelním číslem. Definice stavby není přímo v občanském zákoníku, ale lze aplikovat výklad stavebního zákona

5

50/1976 Sb. O územním plánování a stavebním řádu tavbou se rozumí veškerá

stavební díla, která vznikají stavební nebo montážní technologií, bez zřetele na jejich stavebně technické provedení, použité stavební výrobky, materiály a konstrukce, na účel využití a dobu trvání. Na příkladu například velkého cirkusového stanu lze vidět, že stan je stavbou, ale není nemovitostí, protože není spojen se zemí pevným základem. Stavbou se rozumí i stavba nepovolená, tzn. nezkolaudovaná. Vznik stavby se u budov bere ten okamžik, kdy začnou být zřetelné obrysy a dispozice prvního nadzemního podlaží, obvykle se požaduje alespoň jeden metr výšky stěn prvního nadzemního podlaží. U bytových domů musí být hrubá stavba včetně střechy. Pokud se pod tuto úroveň stěny sníží, lze tento okamžik obvykle brát jako čas zániku stavby. 6 Bytová jednotka není vlastně nemovitostí, pouze celý dům, ale díky Zákonu č. 72/1994 Sb., kterým se upravují některé spoluvlastnické vztahy (zákon o vlastnictví bytů)7, díky tomuto zákonu je možné s byty nakládat stejně jako s nemovitostmi, například je oceňovat a zastavovat.

3

ORT, Petr, Moderní metody oceňování nemovitostí na tržních principech Zákon č. 40/1964 Sb., Občanský zákoník, § 119 http://business.center.cz/business/pravo/zakony/obcanzak/ 5 Zákon č. 50/1976 Sb o územním plánování a stavebním řádu (Stavební zákon) http://business.center.cz/business/pravo/zakony/stavebni/cast1.aspx 6 Kovandová, Marie, server LAMA, dostupné z URL: http://www.la-ma.cz/ocenem/on.php?co=1#1zp 7 Zákon o vlastnictví bytů, dostupný na http://business.center.cz/business/pravo/zakony/byty/ 4

9

Dalším důležitým pojmem je příslušenství k nemovitosti, což je samostatná nemovitost a vlastník rozhoduje, zda je užíváno s hlavní nemovitostí, typickým příkladem je sklep v bytovém domě. Oproti tomu součást nemovitosti je vše, co k nemovitosti podle povahy náleží a nemůže být odděleno, aniž by se tím nemovitost poškodila či podstatně znehodnotila.

1.1.2 Historie oceňování První informace o oceňování je již v Bibli ve Starém zákoně. Další výraznější informace přinesly tereziánské a josefínské reformy. Odhadní řády a nařízení začaly vznikat ve druhé polovině 19. století.8 Prvním důležitým předpisem v historii bylo nařízení č. 175 z roku 1939 O zákazu zvýšení cen, tzv. Stopceny, díky kterému stát zamrazil ceny nemovitostí, aby nedocházelo k hospodářskému kolapsu, díky velkému růstu cen, jak tomu bylo v předchozích krizích. Nařízení platilo až do roku 1964, v některých případech dokonce do roku 1984. Poté Občanským zákoníkem Zákonem č. 40/1964 bylo rozděleno vlastnictví na osobní a soukromé, kdy osobní byly věci pro osobní potřebu občana, rodinný domek, automobil a do vlastnictví soukromého spadaly ostatní tehdy nadstandardní věci jako další automobil, další domek v rodině a hlavně výrobní prostředky, továrny a statky. Tyto soukromé věci se nesměly obchodovat s občany, pouze se státem. Vyhláška č. 73/1964 Sb.9 Stanovila u staveb v osobním vlastnictví cenu za metr čtvereční obytné plochy podle zatřídění dle určitých bodů. Tato vyhláška byla nahrazena vyhláškou č. 43/1969 o cenách staveb v osobním vlastnictví a o náhradách při vyvlastnění nemovitostí 10 Tato vyhláška je založena na stejném principu zatřídění dle specifických bodů, ale byly zvýšeny ceny za některé měrné jednotky. Tato vyhláška také používala pojem „cena obecná

11

“ kdy na konci

znaleckého posudku znalci prohlašovali, že se jedná o cenu obecnou, tím vznikla

8

ORT, Petr, Oceňování nemovitostí na tržních principech, str. 53 Vyhláška č. 73/1964 Sb o cenách staveb v osobním vlastnictví a o náhradách při vyvlastnění nemovitostí http://abonent.lexdata.cz/lexdata/sb_free.nsf/c12571cc00341df10000000000000000/c12571cc00341df1c1256 6d40071ffed?OpenDocument 10 Vyhláška č. 43/1969 o cenách staveb v osobním vlastnictvía o náhradách při vyvlastnění nemovitostí http://www.mujweb.cz/www/lubomir/predpisy/43_1969.txt 11 Cena obecná je ve své podstatě cena reálná, tržní, dnes se používá termín „obvyklá cena“ 9

10

deformace tohoto pojmu, protože před rokem 1989 u nás neexistovalo tržní prostředí. Pojem obecná cena proto byl postupně nahrazen pojmem obvyklá cena. Tento typ ocenění na základě vyhlášky státu a zatřídění nemovitosti dle určitých bodů u nás stále přetrvává hlavně pro státní účely, např. pro daň z převodu nemovitosti. Pro tržní ocenění mezi občany již má málo vypovídací schopnost a užitek.

1.2 Základní kategorie cen dle účelu a způsobu ocenění Jak již bylo uvedeno v kapitole 1.1 Úvod do oceňování nemovitostí, je důležitý účel pro který danou věc oceňujeme, protože z toho se odvíjí i způsob ocenění. Základní dělení způsobů a účelů ocenění jsou již zmiňované ceny dle cenového předpisu, Ceny používané v účetnictví, ceny v pojišťovnictví a nakonec odhady tržních cen.

1.2.1 Ceny podle cenového předpisu tzv. administrativní ceny Hodnota nemovitosti stanovená cenovým předpisem se řídí zákonem č. 151/1997 Sb. O oceňování majetku, ve znění následných vyhlášek, kdy nejvýraznější vyhláškou je vyhláška č. 540/2002 Sb. A vyhláška 640/2004 Sb. Nejčastěji se takto oceňuje pro účely daní, například pro daň z převodu nemovitosti. Profese znalce, je v tomto případě odlišná od ostatních účelů a tím i způsobů oceňování. Řídí se zákonem 36/1967 o znalcích a tlumočnících. Shodné jsou pouze objekty zkoumání, tedy např. pozemky, stavby, nehmotným majetkem. Odhadci a znalci ale používají ale odlišný způsob zkoumání daného objektu zkoumání. Odhadce stanovuje obvyklou cenu, tedy částku, za kterou může být objekt zkoumání prodán za obvyklých tržních podmínek, znalec stanovuje cenu, která je předem dána v právním předpise pro daný účel. Každý znalecký posudek obsahuje nález, což jsou skutečnosti, které zjistil znalec při místním šetření, jako je např. zastavěné plochy, opotřebení, a samotné ocenění, kdy daný objekt zkoumání a jeho dílčí části znalec správně zatřídí do kategorií a tím stanoví i administrativní cenu. Nejedná se tedy o tržní hodnotu, ale o cenu stanovenou vyhláškou, která nezahrnuje tržní principy dané doby. Znalci již většinou nepoužívají tištěné předpisy, ale používají specializovaný software. Nejčastěji NEM 3000

11

1.2.2 Ceny používané v účetnictví Ceny používané v účetnictví se řídí zákonem č. 563/1991 Sb. O účetnictví12 ve znění pozdějších předpisů a další účetní standardy. Tento zákon v § 25 stanovuje, jak se oceňují jednotlivé složky majetku. A to například tak, že: •

Hmotný majetek kromě zásob, s výjimkou hmotného majetku vytvořeného vlastní činností se oceňují pořizovacími náklady, což jsou náklady, za které byl majetek pořízen včetně nákladů s pořízením souvisejících. Někdy se pro pořizovací cenu používá pojem cena historická, protože odpovídá ceně v době pořízení,

•

hmotný majetek kromě zásob vytvořený vlastní činností se oceňuje vlastními náklady, což jsou náklady vynaložené u hmotného majetku na výrobu a nepřímé náklady, které se vztahují k výrobě nebo jiné činnosti s výrobou daného hmotného majetku souvisejících,

•

Majetek v případě bezúplatného nabytí, nebo majetek v případech, kdy vlastní náklady na jeho vytvoření vlastní činností nelze zjistit se oceňuje reprodukční pořizovací cenou, což je cena, za kterou by byl majetek pořízen v době, kdy se o něm účtuje. Jedná se tedy o stanovení tržní hodnoty, tedy obvyklé ceny.

1.2.3 Ceny používané v pojišťovnictví Pro účely pojišťovnictví je třeba oceňovat budovy a stavby, pozemky se nepojišťují, podle zákona 37/2004 Sb. O pojistné smlouvě. Dle tohoto zákona se budovy a stavby pojišťují na časovou cenu a novou cenu. Časová cena je cena, kterou by měla bezprostředně před pojistnou událostí. Stanoví se z nové věci a odečte se opotřebení či jiné znehodnocení a přičte se hodnota opravy a modernizace. Nová cena je cena, za kterou lze v daném čase stejnou věc znovu pořídit. Tento zákon přímo odkazuje na obvyklou cenu dle Zákona č. 151/1997 Sb., §2, odst. 1, o oceňování majetku, kterou blíže popisuji v následující kapitole.

1.2.4 Obvyklá cena Obvyklou cenu definuje Zákon č. 151/1997 Sb., §2, odst. 1, o oceňování majetku13 takto:

12

Zákon č. 563/1991 Sb. O účetnictví http://business.center.cz/business/pravo/zakony/ucto/cast4.aspx 12

„Obvyklou cenou se pro účely tohoto zákona rozumí cena, která by byla dosažena při prodejích stejného, popřípadě obdobného majetku nebo při poskytování stejné nebo obdobné služby v obvyklém obchodním styku v tuzemsku ke dni ocenění. Přitom se zvažují všechny okolnosti, které mají na cenu vliv, avšak do její výše se nepromítají vlivy mimořádných okolností trhu, osobních poměrů prodávajícího nebo kupujícího ani vliv zvláštní obliby. Mimořádnými okolnostmi trhu se rozumějí například stav tísně prodávajícího nebo kupujícího, důsledky přírodních či jiných kalamit. Osobními poměry se rozumějí zejména vztahy majetkové, rodinné nebo jiné osobní vztahy mezi prodávajícím a kupujícím. Zvláštní oblibou se rozumí zvláštní hodnota přikládaná majetku nebo službě vyplývající z osobního vztahu k nim.“ Odhad obvyklé ceny dle této definice je vyžadován pro účely hlavně bankovní zástavy, pro občansko-právní spory, pro ocenění majetku vkládaného do obchodního majetku společnosti a další účely, kdy chce objednatel získat reálnou představu o hodnotě svého majetku. Pro metody stanovení této ceny se vychází z naší předválečné praxe, ale hlavně z praxe a zkušenosti ze zahraničí, protože v České republice nebylo delší dobu do roku 1989 standardní tržní prostředí. Cena obvyklá se obvykle velmi liší od administrativní ceny stanovené znalcem. Administrativní cena je tabulková dle předpisu, obvyklá cena zohledňuje tržní principy, tedy poptávku po daném oceňovaném majetku, nabídku podobných a hlavně jde o porozumění využitelnosti daného majetku, ne jen o velikost a stav oceňovaného majetku, jak je tomu při stanovení administrativní ceny V případě ocenění nemovitostí, na což se bude tato aplikace vyvíjet, má na obvyklou cenu nejčastěji vliv lokalita, vzdálenost od centra, okolní zástavba, dispozice nemovitosti, užitná plocha, velikost okolního pozemku, stáří stavby, stav stavby, materiál, ze kterého byla nemovitost postavena. Je nutné také sledovat i závažné vlivy na obvyklou cenu, což je hlavně územní plán obce při oceňování pozemku, soulad fyzický s právním vedením věci a věcná břemena.14 Jednotlivá 13

Zákon č. 151/1997 Sb., §2, odst. 1, o oceňování majetku http://www.mfcr.cz/cps/rde/xchg/mfcr/hs.xsl/zakony_1092.html 14 věcné břemeno = omezení vlastníka nemovitosti ve prospěch jiného tak, že je povinen něco trpět, konat nebo se něčeho zdržet. 13

věcná břemena se oceňují stejně jako nemovitosti. Vyvíjená aplikace se nebude zaměřovat na ocenění věcných břemen. Odhad obvyklé ceny nemovitosti s věcnými břemeny je vždy odhadnuta jako celek včetně těchto věcných břemen. Naproti tomu v případě zástavního práva 15, to výši obvyklé ceny neovlivňuje, je nutné jej ale uvést v odhadu jako omezení.

1.3 Metody stanovení obvyklé ceny Základní metody pro stanovení obvyklé ceny se používají: metoda nákladová, výnosová a srovnávací. Každá vypovídá o nemovitosti hodnotu a je na odhadci určit, do jaké výše se podílově na obvyklé ceně podílí právě daná metoda. V následující části popíšu blíže dané metody, avšak nebude se jednat o detailní popis prvních dvou zmíněných metod, protože vyvíjená aplikace se bude vyvíjet právě pro metodu srovnávací.

1.3.1 Metoda nákladová Tato metoda je nazývána také jako metoda věcná či technická. V podstatě se jedná o metodu, která stanoví náklady na vybudování nové nemovitosti v současných cenách a odečte se opotřebení dle stáří a skutečného stavu oceňované nemovitosti. Výsledkem je nákladová hodnota, která vystihuje technický stav nemovitosti v čase hodnocení. Ke stanovení hodnoty nákladovou metodu není nutné mít databázi uskutečněných prodejů, ale jedná se o stanovení hodnoty dle stavebních ukazatelů stavebních nákladů a stanovení vzorců pro opotřebení. Vyvíjená aplikace se nákladovou metodou nebude zabývat.

1.3.2 Metoda výnosová Metoda výnosová, někdy také nazývána příjmová, vyjadřuje schopnost nemovitosti vytvářet výnos. Je určena ekonomickým využitím za předpokladu stávajícího způsobu užití nemovitosti nebo za předpokladu nejlepšího možného způsobu využití.

16

Tuto hodnotu si

lze představit jako jistinu, kterou musíme uložit do banky, aby byly úroky z této vložené jistiny ročně stejné, jako je výnos z oceňované nemovitosti za rok.

15

Zástavní právo = slouží k zajištění pohledávky pro případ, že dluh, který ji odpovídá, nebude splněn včas s tím, že pak lze dosáhnout uspokojení z výtěžku zpeněžením zástavy 16 Ing. Milada Najvárková, studijní materiál Úvod do oceňování – ceny a hodnoty 14

Tato metoda je velmi vypovídací u provozních objektů, administrativních budov a dalších nemovitostí, které vytváří výnos. Ke stanovení ceny výnosovou hodnotou je třeba znát ceny pronajímaných nemovitostí v podobných typech nemovitostí v podobné lokalitě, takže většinou je třeba použít částečně srovnávací metodu. Vyvíjená aplikace bude mít možnost zadat u vkládané nemovitosti cenu za m2/rok, za kterou se prokazatelně nemovitost pronajímá. Aplikace tedy bude pomáhat ke stanovení výnosové hodnoty, ale není to jejím primárním záměrem.

1.3.3 Metoda srovnávací Metoda srovnávací, někdy nazývána také porovnávací, vyhodnocuje ceny nedávno prodaných srovnatelných nemovitostí. Odhadce tak vždy většinou ze své vlastní databáze, případně z veřejně dostupných databází či jiných veřejných portálů, vyhledá co nejpodobnější objekty z hlediska lokality, využití a dalších parametrů a stanoví tak jednotkovou cenu za m2. Předpokladem je ale dostatečný počet kvalitních informací, které jsou úplné a hlavně pravdivé. Porovnáním s dostatečným výběrem podobných zobchodovaných nemovitostí, stanoví odhadce lépe a přesněji odhadní hodnotu pro oceňovanou nemovitost. Tato metoda srovnávací se v dnešní době dostává do popředí, hlavně při odhadech bytů a nemovitostí, které se často obchodují a jsou porovnatelné. Pro banky má metoda velký význam, protože vypovídá o potencionálním rychlém zobchodování za tržně přijatelnou hodnotu, v případě neplnění podmínek při splácení úvěrů.

1.4 Aplikace pro stanovení obvyklé ceny Existence aplikace uskutečněných prodejů s dostatečným počtem přesných dat by měla velký význam pro vývoj tohoto oboru oceňování. Konečná kupní cena reaguje vždy na základě dané poptávky a nabídky, ale je to velmi cenný pomocný nástroj pro stanovení obvyklé ceny. V současnosti se nejčastěji používají vlastní databáze uskutečněných odhadů s kupními cenami oceňovaných nemovitostí každého odhadce, nebo placené databáze uskutečněných prodejů. Z tohoto důvodu vznikl nápad na vývoj této aplikace, která bude splňovat oba 15

požadavky, jak jednoduchost pro přístup odhadce, tak i nenákladovost této aplikace. Aplikace, která zajistí tyto základní požadavky, si tak zajistí i větší počet uživatelů, tím také větší počet cenných dat o uskutečněných prodejích.

1.4.1 Existující aplikace Na trhu již existují důležité aplikace, které splňují jednoduchost v přístupu pro odhadce, ale nejsou zdarma. Jsou to placené přístupy do informačního systému např. MOISES, dostupný na http://www.reaia.cz, která je momentálně základní a nejvíce používanou aplikací po vlastních databázích každého odhadce a veřejných portálech. Cena za tuto aplikaci MOISES se pohybuje kolem 4.000 Kč/rok a uživatel je povinen poslat min. 12 záznamů o rodinném domě za jeden rok. Systém je navržen tak, že po zaplacení licence je nutné si stáhnout instalační software na domácí počítač uživatele a na CD-ROM či disketě zasílat poštou na centrálu společnosti záznamy o uskutečněných prodejích včetně fotografie. Na centrále jsou data zpracovány do potřebného tvaru a na disketách jsou zasílány opět poštou všem licencovaných uživatelům. Tato aplikace obsahuje již 11tis. Záznamů, dle společnosti REAIA. Oproti navrhované aplikaci je tato aplikace placená a je nutné instalovat soubor na domácím počítači. Z hlediska aktualizací a vkládání nových záznamů je velmi nepraktická.

1.4.2 Vlastní excel aplikace Každý odhadce si vede svou vlastní aplikaci uskutečněných odhadů, kde je vedena i skutečná kupní cena dané nemovitosti. Náhled mé vlastní evidence v aplikaci Excel o uskutečněných prodejích je v příloze č.1 této práce. Při stanovení obvyklé hodnoty obdobného majetku tak má reálné a úplné informace o obdobné nemovitosti. Většinou je vedena v aplikaci Excel nebo Word od společnosti Microsoft. Tyto základní evidence jsou omezené hlavně sdílením v počtu uživatelů a ve vyhledávání. Sdílení informací z takovýchto databází je ale stěžejní věc pro vyhledávání obdobných uskutečněných prodejů obdobných nemovitostí, protože čím více odhadců by spojilo své soukromé databáze na svých počítačích, tím větší databáze by vznikla a tím by měla i větší využitelnost pro další

16

odhadce. Čím větší a úplnější databáze porovnatelných nemovitostí, tím kvalifikovanější odhady.

1.4.3 Obecné požadavky na www aplikaci Aplikace bude sloužit jako pomocný nástroj ke stanovení obvyklé ceny nemovitosti na trhu. Bude umožňovat zejména odhadcům, ale i jiným osobám a institucím, vyhledávat pro obdobný typ nemovitosti uskutečněné prodeje a tím získat kvalitní informaci o reálných cenách na trhu. Proto, aby aplikace poskytovala sofistikované podklady pro určení obvyklé ceny, je důležité databázi uskutečněných prodejů plnit reálnými informacemi o uskutečněných prodejích. Jedna ze základních vlastností aplikace je proto zadávání vstupních údajů o realizovaných prodejích. Druhou klíčovou vlastností aplikace musí být možnost vyhledávání v databázi obdobné nemovitosti jako právě oceňovaná nemovitost. Zde pro vyhledávání bude rozhodujícím kriteriem lokalita, ve které se nachází oceňovaná nemovitost, dále pak její charakteristické rysy, jako je např. velikost, dispozice, typ materiálu, ze kterého je nemovitost postavena. Další důležitou vlastností aplikace je uchovávat data o realizovaných prodejích. Aplikace by měla umožňovat data archivovat. Při rozhodování, jaký nástroj použít pro vývoj a provozování, je důležité pro daný nástroj zohlednit jeho cenovou dostupnost. Nutnou podmínkou je volné šíření a používání nástrojové licence. Jak nástroj pro vývoj, tak samotné používání následně vyvinuté aplikace musí být dostupné z webového prohlížeče, který nebude pro správné fungování aplikace vyžadovat doinstalování žádných speciálních Plug-inů, ani jiných programů. Vývoj, používání a správa aplikace bude tedy možná vzdáleně standardními prostředky Internetu.

17

2 Oracle APEX Oracle Application Expres (Oracle APEX) se řadí mezi nástroje určené pro rychlou tvorbu webových aplikací. Oracle APEX patří mezi nástroje skupiny RAD (Rapid Application Development), které jsou určeny právě pro snadnou a rychlou tvorbu aplikací. Dnes se jedná již z převážné většiny o aplikace provozované pomocí webového prohlížeče, tedy o webové aplikace. Tak jak společnost Oracle nástroj Oracle APEX presentuje na svých webových stránkách17, jedná se o nástroj, který je určený pro vývoj, nasazení a samotný provoz jednoduchých webových aplikací. Oracle APEX je úzce integrován s databází Oracle a od verze Oracle database 10g je dodáván zcela zdarma a to ve všech na trhu dostupných variantách Oracle databáze. Společnost Oracle nabízí zcela zdarma k používání a provozování licenci databáze, která se nazývá Oracle database 10g Express Edition (dále jen Oracel XE). Tato databáze má v sobě již nainstalován produkt Oracle APEX a je dodávána i HTTP serverem pro příjem http požadavků. Oracle XE je určena právě pro vývoj a provozování informačních systémů založených na Oracle APEX. Je tedy možné v terminologii používat pro Oracle APEX označení Oracle XE a obráceně. Díky integraci Oracle APEX do Oracle databáze je možné rychle vytvořit bezpečnou, z pohledu správy uložených dat a přístupu k nim, tak také snadno rozšiřitelnou aplikaci, kterou je možné dále rozvíjet, a to pouze za využitím webového prohlížeče. Pokud v bodech shrnu uváděné základní vlastnosti nástroje Oracle APEX, bude se jednat o: •

Snadné a rychlé vytváření webových aplikací přímo ve webovém prohlížeči

•

Jednoduchý přenos dat z tabulkových a textových editorů do databázových tabulek

•

Samozřejmostí, která je dána vlastností databáze, je sdílení dat mezi uživateli

•

Vytvoření aplikace bez nutnosti programování, k tomu slouží sada průvodců

•

Data a definice aplikací jsou uložena v bezpečné a spolehlivé Oracle databázi

•

Vedle možnosti tvorby aplikace bez programování, lze aplikace rozšířit i o naprogramovanou logiku

•

17

Oracle APEX je zdarma a je součástí všech variant Oracle databáze

http://www.oracle.com/global/cz/database/express_edition.html 18

Architektura Oracle APEX je založena na již zmíněné úzké integraci s databází Oracle a dále na Oracle HTTP serveru, který zprostředkovává směrem k webovému prohlížeči aplikační výstupy zpracované v samotné databázi. Aplikační výstupy z Oracle databáze v podobě html kódu zajišťuje APEX programový modul, který s předdefinovanou databázovou strukturou pro ukládání definic aplikací tvoří jádro nástroje Oracle APEX. Jednoduchým shrnutím dostáváme, že Oracle APEX je tvořen předpřipravenými strukturami v databázi, které slouží pro ukládání definic aplikací, vytvořených pomocí průvodců a dále programovým modulem, který uložené definice transformuje do html kódu. Html kód je zpracován webovým prohlížečem a umožňuje vykreslení a zpracování webových stránek a jejich obsahu. Z popisu architektury je zřejmé, že veškeré zpracování aplikace probíhá na databázovém serveru. Oracle HTTP server s knihovnou mod_plsql, který přijímá požadavky od koncových uživatelů z webových prohlížečů, provádí pouze napojení na databázi a předání http požadavku APEX programovému modulu. APEX programový modul dle typu požadavku provede sestavení vzhledu html stránky a naplnění příslušnými daty. APEX programový modul je vytvořen pomocí programovacího jazyka PL/SQL a umožňuje zpracování aplikace v reálném čase z definic aplikace uložených v předdefinovaných strukturách. Vytváření nové aplikace nebo rozšiřování funkcionality stávající aplikace nezpůsobuje generování žádného kódu, ale další uložení aplikační definice do databáze. Programový modul vedle zajišťování vykreslování a zpracování stránek zajišťuje důležitou správu uživatelských sezení (user session) a je vybaven funkcionalitou pro správu autentizace (identifikace uživatele při přihlášení) a správu autorizace (správa uživatelských oprávnění přístupu ke komponentám aplikace). Důležitou vlastností je také kontrola správnosti zadaných a zpracovávaných dat. Oracle APEX je speciálním případem provozování aplikace na tzv. tří-vrstvé architektuře. Obecně je tří-vrstvá architektura webových aplikací presentována jako systém složený ze tří fyzicky navzájem oddělených částí, které mezi sebou komunikují a předávají si požadované informace. Na začátku této architektury je klientská stanice, označována také jako vrstva tenkého klienta. Druhá vrstva se nazývá vrstvou aplikační a je tvořena webovým serverem,

19

který zpracovává aplikaci a aplikační data. Třetí a poslední vrstvou, je vrstva datová, kde jsou uložena data a je převážně tvořena databázovým serverem. Oracle APEX je speciálním řešením z toho důvodu, že značná část aplikační vrstvy je uložena rovněž v databázovém serveru a samotný webový server slouží, jak již bylo napsáno, pouze k předávání požadavků od tenkého klienta. V následujících kapitolách se podíváme na jednotlivé vrstvy tří-vrstvé architektury Oracle APEX detailněji.

2.1 Oracle APEX – datová vrstva Jak z úvodu kapitoly o produktu Oracle APEX vyplývá, základ celého řešení je postaven na vlastnostech databáze Oracle. Proto se v této podkapitole zaměřím na základní seznámení s databázovým serverem Oracle. Databázový server Oracle je tvořen instancí databáze, která se vytváří v paměti počítače po spuštění základního databázového programu (na systémech MS WIN se jedná o program oracle.exe), a fyzickou databází, jinými slovy databázovými soubory uloženými na pevném disku počítače. Instance databáze obsahuje sadu programových procesů, které spolu s vyhrazeným paměťovým prostorem zajišťují správnou funkcionalitu databáze. Není-li spuštěn základní databázový program, který vytvoří instanci databáze, nejsou přístupná žádna data z databázových souborů. Každý z programových procesů v instanci databáze má přesně definovanou funkcionalitu. Zjednodušeně lze říci, že existují programové procesy, které zajišťují operace jako je čtení a zápis z a do databázových souborů, programové procesy, které monitorují stav instance a jiné například spravují požadavky na data od koncových uživatelů.

20

Samotná data jsou uložena v databázových souborech, které tvoří soubory operačního systému. Hlavním úkolem databázových souborů je bezpečné a trvalé uložení dat.

Databázový server Oracle Instance databáze

Databázové soubory

Obrázek 1 : Databázový server Oracle – Základní architektura

Vzhledem k obsahu mé diplomové práce není cílem detailní seznámení s databázovým serverem Oracle a pro základní pochopení jeho funkcionality s ohledem na Oracle APEX je uvedený popis dostačující.

2.2 Oracle APEX – aplikační vrstva Ať již budeme používat označení Oracle APEX nebo Oracle Database XE, jedná se o nástroj, který na aplikační vrstvě nabízí prostředky jak pro vývoj aplikace, tak pro její provozování.

2.2.1 Vývojové prostředí Vývojové prostředí je navrženo takovým způsobem, aby bez nutnosti instalace speciálních programů a vývojových nástrojů na klientském počítači, pouze ve webovém prohlížeči, bylo možné efektivním a rychlým způsobem vytvářet aplikace nad datovou vrstvou. Pro jednoduchou a rychlou tvorbu aplikací vývojové prostředí obsahuje komponenty a vlastnosti, které jsou navrženy právě s ohledem na rychlý způsob tvorby vyvíjených

21

systémů.

Nyní se podíváme na některé důležité komponenty a vlastnosti, které tvoří

vývojové prostředí. Pro webové aplikace je charakteristické udržování informací patřících k jednomu uživatelskému spojení v paměťovém prostředí nazývaných jako uživatelská session. Vybudování aparátu pro správu uživatelské session je programátorsky náročné. Oracle APEX v sobě již zahrnuje vestavěnou funkcionalitu, která správu uživatelské session automaticky řeší. Tím je tvůrci aplikace usnadněna právě ta část týkající se náročné správy uživatelské session. Uživatelská session je v Oracle APEX uložena přímo v databázi a pro práci s ní a informacemi uloženými v ní, již existuje celá řada předpřipravených funkcí. Další funkcionalitou, která usnadňuje vývoj aplikací je vestavěná komponenta pro rychlou tvorbu webových formulářů nad daty uloženými v databázi. Formuláře je možné vytvářet pomocí tzv. průvodců, kde ne výstupu z průvodce je hotový a použitelný webový formulář a to nejen pro zobrazení dat, ale i pro vkládání, jejich změnu a mazání. Každá webová aplikace se vyznačuje vlastním grafickým uživatelským rozhraním, které se každý vývojář snaží navrhnout tak, aby bylo uživatelsky příjemné. Samotný návrh vzhledu aplikace je náročný proces nejen na čas, ale i na znalosti návrháře. Tato skutečnost je v Oracle APEX zohledněna sadou předpřipravených šablon, které umožňují snadným způsobem vytvořit sofistikovaný vzhled aplikace. Tento vzhled je možno dále měnit přiřazením jiné šablony. Vedle průvodců pro tvorbu webových formulářů aplikační vývojové prostředí obsahuje i průvodce pro tvorbu reportů, které jsou založeny na SQL dotazech nad daty uloženými v databázi. Vestavěný průvodce pro tvorbu reportů umožňuje návrh reportů založených na jednoduchých SQL dotazech, tak také nad složitými vnořenými SQL dotazy. Vygenerovaný report obsahuje sadu vlastností, které může využít uživatel, kterému je report ve webovém prohlížeči zobrazen. Jedná se například o vlastnost třídění záznamů podle vybraného sloupce, možnost propojení na jiné reporty nebo grafy. Oblíbenou vlastností, kterou vygenerovaný report nabízí a která je hodně využívána, je možnost přenesení zobrazených dat z reportu do aplikace MS Excel.

22

Přestože aplikace by mohla být navržena bez programování, vývojové prostředí umožňuje do vytvářených webových stránek zakomponovat programové kódy a to jak programové kódy PL/SQL, tak skriptovacího jazyka JavaScripts. Ve výčtu vlastností vývojového prostředí bych mohla pokračovat, jen zmíním možnost rychlé tvorby grafů pomocí vestavěného průvodce nebo možnosti snadného ukládání dokumentů do databáze, zasílání emailů z databáze a tvorby přihlašovacích dialogů. Závěrem nelze opomenout připravenost vývojového prostředí pro správu přístupu, autorizaci k jednotlivým částem vytvářené webové aplikace. Autorizace je navržena takovým způsobem, že je možné řídit přístupová oprávnění na úrovni celé stránky nebo dílčích komponent, které jsou na stránce použity.

2.2.2 Provozní prostředí Provozní prostředí nástroje Oracle APEX je úzce svázáno s prostředím vývojovým a pro provoz aplikací jsou automaticky využívány i vlastnosti spadající do prostředí vývojového. Provozní prostředí využívá metadata aplikace, která jsou prostřednictvím vývojového prostředí uložena do metadata repository. Metadata repository je předdefinovaná databázová oblast obsahující sadu databázových objektů, které jsou využívány pro ukládání informací, ze kterých je aplikace tvořena. Provozní prostředí informace uložené v metadata repository využívá k výslednému sestavení obsahu webové stránky a k jejímu zobrazení. Provozní prostředí vedle vykreslování a zpracování stránek obsahuje vlastnosti a funkcionalitu jako je správa uživatelské session, služby pro autentizaci, dále služby pro autorizaci a kontrolu správnosti zadaných a zpracovávaných dat. Provozní prostředí se vyznačuje tím, že aplikace jsou zpracovávány v reálném čase z informací a dat uložených v metadata repository. Pro účely diplomové práce je popis vývojového a provozního prostředí produktu Oracle APEX nebo chceme-li Oracle database XE dostačující. Dále se budu již věnovat samotné realizaci zvolené aplikace pro oceňování nemovitosti.

23

3 Realizace aplikace Dle teorií o vývoji a realizaci informačních systémů a aplikací, má-li být projekt ukončen úspěšným zavedením a nasazením aplikace do rutinního provozu, je nutné při vývoji a implementaci postupovat dle metodiky vhodné pro daný typ projektu. Metodika se skládá z metod, kde metoda například podle doc. Aleny Buchalcevové určuje, co je třeba dělat v určité fázi činnosti vývoje či provozu IS. Metoda je vždy spojena s určitým přístupem, jako je funkční, datový, procesní, nebo například objektový přístup. S přihlédnutím k této charakteristice řeší každá metoda postup činností v určité části procesu vývoje systému, nebo pouze z některého úhlu pohledu na systém (data, funkce, SW, HW, atd.)18. Dále doc. Buchalcevová na svých výukových slidech pro výuku systémové metodologie uvádí příklady následujících metod: •

ISAC (informační analýza),

•

YSM (Yourdon Structured Method),

•

Jackson System Development,

•

BSP (Business System Planning),

•

OMT (Rumbaugh a kol),

•

UP a RUP (OMG, Rational), Perspective, Catalysis, Room...

•

OOSE (Jacobson),

•

OOAD (Booch),

•

SSM (Soft Systems Methodology)

•

RAD (Rapid Application Development), „Agilní metodiky“

V úvodu diplomové práce jsem zmínila, že Oracle APEX patří mezi RAD nástroje pro vývoj aplikací. Z výše uvedeného seznamu příkladu metodik vyplývá, že pro vývoj pomocí RAD nástrojů jsou vhodné agilní metodiky. Tento fakt potvrzují i doporučení, která lze najít na veřejně dostupných webových stránkách Oracle APEX komunity a přidružených diskusních fórech týkajících se problematiky spojených s návrhem a vývojem informačních systému právě pomocí RAD nástroje Oracle APEX. Studiem nesčetného množství 18

BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 24

diskusních příspěvků, týkajících se vhodného způsobu a metod pro vývoj aplikace pomocí Oracle APEX, jsem na základě v komunitě uvedených znalostí a doporučení sestavila metodiku, kterou lze obecně nazvat návrh aplikace pomocí Oracle APEX na základě bestpractices. Best-practices metodika obsahuje následující části, které je vhodné v uvedeném pořadí dodržet a zpracovávat pro úspěšnou realizaci aplikace. Best-practices obsahují tyto části: • Odborný článek • Seznam požadavků • Use case scénáře a diagram • Diagram aktivit • RAD implementace Následující kapitoly odpovídají jednotlivým částem sestavené best-practices metodiky.

3.1 Odborný článek Úlohou odborného článku je nadefinovat základní požadavky na provozování a používání aplikace. Odborný článek by dle obecných pravidel měl být obecně zaměřen. Obecným zaměřením je myšleno, že by se odborný článek neměl zaměřovat na technologie, které budou použity pro vývoj a provoz aplikace, ale měl by obecně popisovat požadavky, které by aplikace měla nutně plnit. Může se jednat jak o požadavky na provoz, tak zejména o funkční požadavky na používání a obsluhu aplikace. Vzhledem k zaměření diplomové práce, se v odborném článku vyskytne povolená výjimka a budou zmíněny i požadavky, které se týkají konkrétní použité technologie pro realizaci a provozování aplikace. S přihlédnutím ke skutečnosti, že na odborný článek navazují další části analýzy a následné implementace, je zpracování odborného článku v potřebné míře detailu kritické pro celý navrhovaný systém.

3.1.1 Popis technické použití Aplikace bude navržena tak, aby mohla být provozována u webového poskytovatele, který umožní využití diskového prostoru o velikosti 2GB. Tento prostor bude odpovídající pro instalaci Oracle databáze XE, která využije cca 1,5GB a zbývajících 500MB bude

25

dostatečný prostor pro aplikační data. Vzhledem k architektuře provozování aplikace realizované v Oracle APEX. Bude potřeba na straně poskytovatele nastavit předávání http požadavků z jeho primárního http serveru na server, který je součástí instalace Oracle databáze XE (Oracle APEX). Tímto předávání http požadavku („redirectem“) se vyhneme náročné konfiguraci http serveru poskytovatele a případným nekompatibilitám. Aplikaci bude možné prostředky řešení zálohovat a distribuovat i na jiné webové servery, které budou mít nainstalované prostředí Oracle APEX. Zálohování a distribuce musí být proveditelná bez hlubších administrátorských znalostí a to jak databáze, tak aplikace.

3.1.2 Aplikační typy uživatelů Vlastní používání aplikace musí být platformově nezávislé a bude provozovaná pouze ve webovém prohlížeči. Tento požadavek se týká i administrace a to i na úrovni správy databázových objektů. Aplikace musí umět rozlišovat čtyři typy uživatelů. Prvním typem je systémový administrátor, kterému bude umožněno spravovat databázi z pohledu systémového a zakládat další typ uživatele, tzv. aplikační designer. Aplikační designer bude aplikaci vytvářet, spravovat a k tomu všechny potřebné aplikační databázové objekty. Pak budou následovat dva typy uživatelů, kteří budou aplikaci jen používat, jedná se o aplikační uživatele, kde uživatel, který bude spravovat a zajišťovat přístup do aplikace pro ostatní uživatele se bude nazývat aplikační administrátor. Poslední skupinu budou tvořit aplikační uživatelé, ti budou aplikaci používat a využívat informace, které bude poskytovat. Společným rysem pro uvedené typy uživatelů je přístup k potřebné funkcionalitě, dle typu uživatele, přes webové rozhraní. Systémový administrátor a aplikační designer budou mít jinou URL adresu pro přístup k potřebným nástrojům pro správu a vývoj než aplikační uživatel a aplikační administrátor. Tato adresa bude dána samotnou instalací a nebude možné ji měnit. Z pohledu potřebné aplikační funkčnosti je důležité splnit požadavky dané zejména potřebami uživatele a administrátora aplikace.

3.1.3 Úvod a přihlášení Po zadání URL adresy aplikace do webového prohlížeče se zobrazí veřejně přístupná úvodní stránka, ta bude obsahovat odkazy na další veřejně dostupné stránky a to formou 26

záložek a ULR linků ve veřejně dostupném menu. Aplikace tedy musí rozlišovat dva základní typy přístupů. Veřejný přístup, tzv. public access, a přístup přihlášeného uživatele, tzv. autentizovaný přístup. Další veřejné stránky, které budou přístupné pro nepřihlášené uživatele, budou stránka registrace, přihlášení a kontakt. Úvodní stránka na záložce „Úvod“ bude obsahovat obecný popis aplikace, proč aplikace vznikla, komu je určena, kdo je autorem aplikace a informace jak se zaregistrovat. Další veřejně dostupná stránka bude uložena na záložce „Registrace“. Záložka registrace nabídne potencionálním zájemcům o používání aplikace možnost zadat žádost o registraci. Žádost o registraci si uživatel podá vyplněním registračního formuláře, kde uživatel zapíše o sobě informace jako jméno, příjmení, titul, telefon, IČO, název firmy, pozici, adresu a navolí si heslo. Po zadání potřebných údajů bude moci uživatel žádost odeslat ke zpracování. Žádost mu bude vyřízena souhlasně nebo bude zamítnuta. O této skutečnosti rozhodne administrátor aplikace, o funkčních požadavcích na aplikaci pro administrátora aplikace bude pojednáno dále v odborném článku.

Na záložce „Přihlášení“ se zobrazí stránka s přihlašovacím

dialogem. Dialog umožní zadání uživatelského osobního čísla, které mu bude přiděleno při kladném vyřízení žádosti o registraci a zadáním hesla, které zadal do registračního formuláře. Poslední veřejně dostupná stránka bude na záložce „Kontakt“, zde bude uveden kontakt na provozovatele a administrátory aplikace. Po přihlášení do aplikace bude mít uživatel rozšířenou volbu záložek o stránky s funkcionalitou dostupnou pouze pro autentizované uživatele. Tedy pro uživatele, kterým byla administrátorem aplikace kladně vyřízena žádost o registraci a bylo jim přiděleno jejich osobní číslo. Ověřeným přihlášením do aplikace se nejen zobrazí záložky pro autentizovaný přístup, ale zároveň již nebudou zobrazovány záložky „Přihlášení“ a „Registrace“. Změna přístupných stránek se projeví nejen v seznamu záložek, ale i v korespondujícím seznamu URL odkazů v menu. Mezi stránky, které budou zobrazeny po úspěšném přihlášení, přibudou stránky na záložkách s funkcionalitou potřebnou pro vkládání záznamů, pro jejich vyhledávání, pro kontrolu osobních údajů a pro editaci záznamů, které aktuálně přihlášený uživatel do aplikace vložil.

27

3.1.4 Vyhledávání záznamů Stránka s funkcionalitou pro vyhledávání záznamů bude umožňovat vyhledávat záznamy podle typu nemovitostí, podle zadaného kraje, okresu a čísla katastrálního území. Vyhledávané záznamy bude možno filtrovat podle typu nemovitosti a podle dalších kriterií, které se budou vztahovat k vybranému typu nemovitosti. Bude se jednat o kriteria datum převodu, dispoziční řešení nemovitosti, provedení bytového jádra, typ materiálu použitý pro stavbu daného objektu. Při vyhledávání typu administrativní budova, bude možné záznamy filtrovat podle kriteria typ komerčního objektu, speciální filtr se nabídne u nemovitostí typu pozemek, rovněž jiný typ filtru bude umožněn pro typ nemovitostí nebytové prostory. Pro nemovitosti zahrnuty do kategorie ostatní, bude umožněno vyhledávat a filtrovat podle základních vyhledávacích parametrů jako jsou kraj, okres, číslo katastrálního území a datum převodu. Po vyhledání záznamů dle vyhledávacích kriterií se vyhledané záznamy zobrazí na stránce pro vyhledávání pod vyhledávacími parametry. Zobrazené záznamy budou obsahovat základní informace o vyhledané nemovitosti. Dle vybraných údajů bude možné nad reportem záznamu provádět třídění. Pro každý vyhledaný záznam bude možné zobrazit detailní informace a to kliknutím na uvedený záznam. Detailní informace se zobrazí na nové stránce opět pod záložkou pro vyhledávání.

3.1.5 Vkládání záznamů Důležitou funkcionalitou aplikace pro oceňování nemovitostí je samotné vkládání údajů do databáze. Údaje se budou vkládat na stránce příslušející záložce pro vkládání a vkládané údaje budou ovlivněny typem nemovitosti, pro které budou informace vkládané do databáze. Při vkládání je tedy velmi důležité, jakému typu nemovitosti vkládané informace náleží. Při vkládání se nesmí zapomenout na automatické vložení uživatele, který daný záznam pořídil, rovněž na datum pořízení záznamu. Vkládaná informace o uživateli, který záznam pořídil, bude využita pro funkcionalitu, která bude dostupná na samostatné stránce pod záložkou určenou k prohlížení a editaci záznamu, které pořídil přihlášený uživatel.

28

Aplikace každému přihlášenému uživateli na stránce pod záložkou určenou pro zobrazení a editaci údajů přihlášeného uživatele nabídne funkcionalitu pro změnu jeho osobních údajů a změnu hesla.

3.1.6 Registrace uživatelů Funkcionalita určená výhradně pro uživatele typu administrátor aplikace se bude nabízet na stránce pod záložkou administrace. Základním úkolem administrátora aplikace je vyřizování žádostí nových zájemců o registraci a tuto žádost vyřídit kladně nebo ji zamítnout. Proto na stránce pro administraci se bude nabízet report se seznamem žádostí, kde každá žádost bude obsahovat základní osobní údaje žadatele. Administrátor provede osobní kontakt s žadatelem a to formou telefonického pohovoru na telefonním čísle uvedených v žádosti. Tímto procesem je nutné ověřit existenci žadatele a oprávněnost jeho žádosti. Pokud administrátor aplikace shledá žádost odůvodněnou, pro vybraného žadatele provede schválení žádosti. Po schválení žádosti je uživateli přiděleno unikátní osobní číslo a žadatel se stává ověřeným uživatelem aplikace. Administrátor na emailovou adresu uvedenou v osobních údajích nově schváleného uživatele zašle jeho osobní číslo, které je nutné pro přihlášení do aplikace. Dále se na stránce určené pro administrátora budou zobrazovat již schválení uživatelé.

3.1.7 Kontrola bez aplikačního rozhraní Vedle schvalování žádostí o přístup do aplikace další úlohou administrátora bude sledování, zda registrovaný uživatel využívá aplikaci podle podmínek pro její používání. Důležitou podmínkou pro užívání aplikace uživatelem je přispívání k obsahu databáze, tzn. Každý registrovaný uživatel, pokud chce aplikaci užívat v souladu s nastaveným pravidly, by měl během 3 měsíců zadat alespoň jeden záznam o uskutečněném prodeji. Sledování, zda uživatel plní tuto podmínku je úloha administrátora aplikace. Ten pomocí standardních SQL dotazů bude provádět kontrolu uživatelů. Uvedený požadavek na kontrolu není součástí webové aplikace a je možné ho považovat za požadavek pro případné rozšíření komfortu pro administraci, kdy namísto používání standardních nástrojů pro spouštění SQL dotazů, by mohla být vytvořena další webová stránka do aplikace, která by zobrazovala report s potřebným výstupem.

29

3.2 Seznam požadavků Na základě odborného článku jsou v této kapitole popsány požadavky, které budou řešeny v rámci navrhované aplikace. Požadavky jsou definované unikátním číslem, názvem a popisem. Požadavky jsou rozděleny do třech kapitol podle typu aplikačního uživatele, od kterého je daný požadavek nejvíce očekáván.

3.2.1 Požadavky nepřihlášeného uživatele PZ01: Zobrazení úvodu – uživateli se zobrazí úvodní stránka o aplikaci, kde nalezne informace typu proč aplikace vznikla, kdo ji vytvořil, jaké jsou podmínky pro její užívání a jak funguje. PZ02: Zobrazení kontaktních údajů – uživateli je zobrazena stránka se základními kontaktními informacemi o provozovateli aplikace a kontakt na aplikačního administrátora. PZ03: Přihlášení - nepřihlášeného uživateli je zobrazen přihlašovací dialog pro zadání osobního čísla a hesla. Po zadání uživatel stiskne tlačítko přihlásit, zadané údaje jsou předány autentizační funkci, která ověří, zda pro daného uživatele existuje uživatelský účet. Pokud účet existuje a zadané údaje souhlasí, uživatel je přihlášen. V opačném případě se mu zobrazí chybová hláška pro zadání správných přihlašovacích údajů. Pro přihlášeného uživatele je vytvořena uživatelská session (paměťový prostor, který je unikátní pro daného uživatele a po úspěšném přihlášení obsahuje jeho uživatelské číslo). PZ04: Žádost o registraci – nepřihlášenému uživateli se zobrazí registrační formulář, který mu umožní zadání osobních údajů a přihlašovacího hesla. Po zadání osobních údajů a stisknutí tlačítka registrovat se údaje z formuláře zapíší do databáze a uživateli je zobrazena informativní hláška o provedeném zápisu. Zobrazené údaje v registračním formuláři: jméno, příjmení, titul, IČO, telefon, email, ulice, město, PSČ, firma, pozice, heslo

30

3.2.2 Požadavky přihlášeného uživatele PZ05: Odhlášení – Přihlášenému uživateli je v aplikaci nabízena možnost odhlášení. Pokud uživatel zvolí odhlášení z aplikace, provede se funkce, která uživatele odhlásí, což způsobí zrušení jeho uživatelského session) a po úspěšném odhlášení zobrazí úvodní stranu aplikace. PZ06: Vložení záznamu – Přihlášený uživatel má možnost ve webovém formuláři zadat nový záznam o uskutečněném prodeji. Rozhodujícím kriteriem pro zadání údajů o uskutečněném prodeji je typ nemovitosti. Podle typu nemovitosti se nabízejí údaje pro zadání údajů o uskutečněném prodeji. Společným rysem všech typů nemovitostí jsou údaje: kraj, okres, číslo katastru, obec, ulice, číslo popisné, číslo parcelní, kupní cena, obvyklá cena současná, datum prodeje, pronajato, roční příjem a popis. Pro další údaje je rozhodující typ nemovitosti, který bude nabízen z číselníku obsahující uvedené hodnoty: bytová jednotka, rodinný dům, komerční objekt, pozemek, nebytový prostor a ostatní. Pro typ nemovitosti bytová jednotka se dále budou nabízet údaje k vyplnění: dispozice, obytná plocha, jádro, materiál. Údaje pro rodinný dům: dispozice, užitná plocha, plocha pozemku, materiál. Komerční objekt: užitná plocha,

plocha pozemku, materiál, typ komerčního

objektu. Nebytový prostor: užitná plocha, materiál. Pozemek: plocha pozemku, typ pozemku. Aby se u vybraných údajů předešlo chybám při vkládání údajů, budou hodnoty pro vybrané údaje vybírány z číselníků a uživateli nabízeny při vkládání. Jedná se o následující číselníky. Typ nemovitosti: bytová jednotka, rodinný dům, komerční objekt, pozemek, nebytový prostor a ostatní. Kraj: dle záznamu z databáze. Okres: dle záznamů v databázi. Dispozice : Garsoniera, 1+kk, 1+1, 2+kk, 2+1, 3+kk, 3+1, 4+kk, 4+1, 5+kk, 5+1, 6 a více pokojů, dvougenerační. Jádro: umakart, zděné. Materiál: dřevostavba, panel, zděné, plech, ostatní. Typ komerčního objektu: nákupní středisko, obchodní, průmyslový areál, sklad, výrobní budova. Typ pozemku: stavební, zemědělský, ostatní. Pronajato: ano, ne. Uživatel po vyplnění záznamu o uskutečněném prodeji stiskem tlačítka uložit, předá vkládané údaje k dalšímu zpracování. Nejprve proběhne kontrola správnosti údajů a

31

následně dojde k uložení záznamu do databáze a vypsání informace, že záznam byl uložen. Uživatel může stiskem tlačítka reset nastavit stránku pro vkládání do inicializační podoby. PZ07: Vyhledání záznamu – přihlášený uživatel má možnost v záložce vyhledávání vyhledávat informace o uskutečněném prodeji podle jím zadaných parametrů. Základním vyhledávacím parametrem je typ nemovitosti. Dalšími společnými vyhledávacími parametry jsou kraj, obec, číslo katastru a datum prodeje. Specifickým vyhledávacím parametrem u typu nemovitosti bytová jednotka a rodinný dům jsou: dispozice a materiál. U komerčních objektů bude dále možnost vyhledávat dle typu komerčního objektu a materiálu. U pozemku to budou vyhledávací kriteria společná rozšířena o typ pozemku. U typu nemovitosti nebytový prostor navíc vyhledávací kriterium materiál. Při zadání typu nemovitosti ostatní budou nabídnuty společné vyhledávací parametry. U údajů jejíž hodnoty jsou při vkládání vybírány z číselníků, budou i při vyhledávání nabízeny hodnoty ze stejných číselníků. Seznam a obsah číselníků viz požadavek PZ06. Po vyplnění požadovaných vyhledávacích parametrů stiskem tlačítka vyhledat dojde k odeslání požadavku na vyhledání do databáze, kde se spustí příkaz SQL SELECT a výsledek SELECTu bude uživateli zobrazen formou reportu, který bude obsahovat sloupce podle typu nemovitosti. Vedle spuštění vyhledávací funkce, bude uživateli umožněno zavolat funkci pro reset vyhledávacích parametrů. Report vyhledaných záznamů dle typu nemovitosti bude obsahovat sloupce uvedené dále. Shodné sloupce pro všechny typy vyhledaných nemovitostí jsou: kupní cena, datum prodeje, kraj, okres, katastrální území, obec, ulice, datum vložení. Bytová jednotka navíc obsahuje sloupec dispozice, materiál, jádro. U typu nemovitosti rodinný dům budou zobrazeny stejné údaje v reportu jako u typu nemovitosti bytová jednotka vyjma jádra. U komerčních objektů se navíc zobrazí sloupce materiál a typ objektu. U pozemku typ pozemku. Při vyhledání typu nebytový prostor bude zobrazen sloupec materiál a společné sloupce pro všechny typy nemovitosti. Pro každý vyhledaný záznam bude možné zobrazit detailní informace, které budou odpovídat danému typu nemovitosti a jsou shodné s údaji, které jsou nabízeny při vkládání, viz požadavek PZ06.

32

PZ08: Aktualizace vlastních záznamů – U každého záznamu o uskutečněném prodeji bude uložena informace o uživateli, který záznam pořídil a jemu bude nabízena možnost jim pořízené záznamy prohlížet a editovat. Report na stránce s vlastními záznamy bude obsahovat sloupce dle požadavků na report na vyhledávání, viz požadavek PZ07. uživatel si ze seznamu vybere záznam pro aktualizaci a na nové stránce se mu po výběru záznamu nabídne možnost editovat záznamy podle typu nemovitosti, obdobně jako při vkládání záznamu, viz požadavek PZ06. Provedené změny bude moci uživatel stiskem tlačítka pro uložení potvrdit a spustit proces pro uložení změn. PZ09: Aktualizace profilu - je požadováno aby přihlášený uživatel mohl provádět změnu svých osobních údajů a hesla, které zadával do registračního formuláře, viz požadavek PZ04. Po provedení změn uživatel stiskem tlačítka uložit změny spustí proces pro uložení změn do databáze.

3.2.3 Požadavky aplikačního administrátora PZ10: Administrace žádostí – Aplikačnímu administrátorovi musí být umožněno spravovat žádosti o registraci. Správa žádostí bude prováděna na základě zobrazeného reportu, který bude obsahovat základní údaje o žadatelích. Vývěrem konkrétního záznamu se zobrazí detailní informace o žadateli a administrátor provede, stisknutím tlačítka registruj, spuštění procesu, který žadatele ze seznamu žadatelů přenese mezi registrované uživatele a přidělí mu unikátní osobní číslo. Zároveň je uživatel ze seznamu žadatelů vymazán. Vedle možnosti žadatele registrovat bude aplikační administrátor mít možnost registraci zamítnout. Touto volbou se spustí proces, který uživatele vymaže ze seznamu žádostí o registraci.

3.3 Use case scénáře a diagram Kapitola use case scénáře a diagram popisuje jednotlivé užití systému. Zabývá se způsobem komunikace mezi systémem a nepřihlášeným uživatelem, přihlášeným uživatelem a aplikačním administrátorem. Jak z požadavků z předchozí kapitoly vyplývá, aplikační administrátor je specializací přihlášeného uživatele, a proto v základním Use Case

33

diagramu je aplikační administrátor zobrazen jako generalizace vztahu k přihlášenému uživateli.

3.3.1 Základní diagram spolupráce Následující diagram zobrazuje způsob spolupráce mezi jednotlivými typ aplikačních uživatelů a aplikací pro oceňování nemovitostí. Detailnější rozpad jednotlivých případů užití a potažmo návrh dalších use case diagramů nemá pro realizaci aplikace opodstatnění.

Diagram 1 : Use Case diagram

Diagram na jedné straně zobrazuje nepřihlášeného uživatele a jemu dostupné funkcionality aplikace, a na druhé straně aktéry, kteří reprezentují uživatele přihlášeného a z něho vyplývajícího aplikačního administrátora, který oproti přihlášenému uživateli má navíc možnost jednoho případu užití.

3.3.2 Use Case scénáře Kapitola popisuje jednotlivé způsoby užití tak, jak vyplývá z výše uvedeného diagramu. Pro popis jednotlivých scénářů je použita forma pomocí tabulek.

34

UC01: Přihlášení Use Case:

Přihlášení

Aktér (role):

Nepřihlášený uživatel

Popis:

Nepřihlášenému uživateli je aplikací nabídnuta možnost zobrazení přihlašovacího dialogu a přihlášení do aplikace

Vstup:

Osobní číslo uživatele a heslo

Výstup:

Uživatel je přihlášen

Předpoklad:

Uživatel má účet v aplikaci – jedná se o registrovaného uživatele Tabulka 1 : Use Case scénář - Přihlášení

UC02: Odhlášení Use Case:

Odhlášení

Aktér (role):

Přihlášený uživatel/aplikační administrátor

Popis:

Přihlášenému uživateli a aplikačnímu administrátorovi je nabízena možnost se odhlásit z aplikace

Vstup:

Požadavek na funkci odhlášení

Výstup:

Uživatel je odhlášen

Předpoklad:

Uživatel musí být přihlášený Tabulka 2 : Use Case scénář - Odhlášení

UC03: Zobrazení úvodu Use Case:

Zobrazení úvodu

Aktér (role):

Nepřihlášený uživatel/přihlášený uživatel/aplikační administrátor

Popis:

Uvedeným aktérům je zobrazena stránka s úvodními informacemi o aplikaci

Vstup:

Požadavek na úvodní stránku

Výstup:

Zobrazení úvodní stránky

Předpoklad:

Není Tabulka 3 : Use Case scénář - Zobrazení úvodu

35

UC04: Zobrazení kontaktních údajů Use Case:

Zobrazení kontaktních údajů

Aktér (role):

Nepřihlášený uživatel/přihlášený uživatel/aplikační administrátor

Popis:

Uvedeným aktérům je zobrazena stránka s kontaktními informacemi

Vstup:

Požadavek na stránku s kontakty

Výstup:

Zobrazení stránky s kontakty

Předpoklad:

Není Tabulka 4 : Use Case scénář - Zobrazení kontaktních údajů

UC05: Žádost o registraci Use Case:

Žádost o registraci

Aktér (role):

Nepřihlášený uživatel

Popis:

Nepřihlášený uživatel má možnost na stránce o registraci vyplnit své osobní údaje a submitem této stránky zažádat o registraci

Vstup:

Vyplnění registračního formuláře

Výstup:

Informace o uložení žádosti do databáze

Předpoklad:

Není Tabulka 5 : Use Case scénář - Žádost o registraci

UC06: Vložení záznamu Use Case:

Vložení záznamu

Aktér (role):

Přihlášený uživatel/aplikační administrátor

Popis:

Uživatel vyplní údaje o záznamu do webového formuláře a potvrdí jejich uložení do databáze

Vstup:

Vyplnění potřebných údajů do formuláře

Výstup:

Informace o uložení záznamu do databáze

Předpoklad:

Uživatel je přihlášen, vyplnění všech povinných údajů Tabulka 6 : Use Case scénář – Vložení záznamu

36

UC07: Vyhledání záznamu Use Case:

Vyhledání záznamu

Aktér (role):

Přihlášený uživatel/aplikační administrátor

Popis:

Uživatel zadá vyhledávací kriteria a dá příkaz vyhledat

Vstup:

Zadání vyhledávacích kriterií

Výstup:

Zobrazení vyhledaných záznamů

Předpoklad:

Uživatel je přihlášen, pro zadaná kriteria existují v databázi záznamy Tabulka 7 : Use Case scénář – Vyhledání záznamu

UC08: Aktualizace profilu Use Case:

Aktualizace profilu

Aktér (role):

Přihlášený uživatel/aplikační administrátor

Popis:

Uživatel si může editovat své osobní údaje včetně změny hesla

Vstup:

Změna osobních údajů nebo hesla

Výstup:

Změna osobních údajů nebo hesla v databázi a informace o změně

Předpoklad:

Uživatel je přihlášen Tabulka 8 : Use Case scénář – Aktualizace profilu

UC09: Aktualizace vlastních záznamů Use Case:

Aktualizace vlastních záznamů

Aktér (role):

Přihlášený uživatel/aplikační administrátor

Popis:

Uživateli dle jeho osobního čísla jsou zobrazeny jím zadané záznamy a je mu nabídnuta možnost jejich editace.

Vstup:

Osobní číslo

Výstup:

Seznam záznamů k danému osobnímu číslu

Předpoklad:

Uživatel je přihlášen, pro dané osobní číslo existují v databázi záznamy

Tabulka 9 : Use Case scénář – Aktualizace vlastních záznamů

37

UC10: Administrace žádostí Use Case:

Administrace žádostí

Aktér (role):

Aplikační administrátor

Popis:

Zobrazení žádostí o registraci, vybrání ze seznamu jedné žádosti a její odsouhlasení nebo zamítnutí

Vstup:

Požadavek na zobrazení žádostí a následně požadavek na zobrazení jedné vybrané žádosti, souhlas nebo odmítnutí žadatele

Výstup:

Souhlas = žadatel se stává uživatelem s přiděleným osobním číslem, nesouhlas = smazání žádosti

Předpoklad:

Existence žádosti v seznamu Tabulka 10 : Use Case scénář – Administrace žádosti

3.4 Diagram aktivit Diagramy aktivit grafickou formou popisují realizaci a plnění požadavků. U každého diagramu je tabulka se seznamem aktivit, ve které je vyspecifikováno, zda se jedná o automatickou aktivitu nebo aktivitu prováděnou uživatelem a zda je pro danou aktivitu potřeba uživatelský interface. Diagramy aktivit jsou rozděleny do třech skupin podle typu uživatele, od kterého se provádění dané aktivity očekává nejvíce. Ačkoli jsou diagram aktivit samopopisující a není třeba u nich psát zvláštní textový popis, u každého diagramu stručně uvedu činnosti, které provádí.

38

3.4.1 Aktivity nepřihlášeného uživatele Diagram aktivit výběr obsahu zobrazení popisuje činnosti, které jsou povoleny neautentifikovanému uživateli. Uživatel po připojení na úvodní stránku aplikace má možnost výběru zobrazit stránku s kontaktními informacemi nebo zpět úvodní stránku se základním popisem aplikace. Dle zvolené akce je mu zobrazen úvod nebo kontakt.

Diagram 2 : Výběr obsahu zobrazení

Aktivita

Typ

Uživatelský interface

Výběr obsahu

Manuální

ANO

Zobrazen úvod

Automatická

ANO

Zobrazen kontakt

Automatická

ANO

Tabulka 11 : Aktivity pro výběr obsahu zobrazení

39

Diagram aktivit žádost o registraci popisuje činnosti, které budou uživateli nabízeny při registrování do aplikace. Bude mu zobrazen webový formulář, kde vyplní své osobní údaje a zvolené heslo pro přihlášení do systému. Na stránce s registračním formulářem bude mít možnost zavolat akci stisknutím tlačítka reset, která vymaže údaje ve vyplněném formuláři nebo tlačítko registrovat, které vyplněná data uloží do databáze a bude mu zobrazena hláška o uložení dat.

Diagram 3 : Žádost o registraci

Aktivita

Typ

Uživatelský interface

Zobrazení formuláře pro registraci

Automatická

ANO

Vyplnění osobních údajů

Manuální

ANO

Zobrazení informace o uložení

Automatická

ANO

Uložení do DB - ZADATEL

Automatická

NE

Tabulka 12 : Aktivity pro žádost o registraci

40

Akce přihlášení uživatele je zobrazena v diagramu aktivit přihlášení. Uživatel zadá přihlašovací údaje do dialogového okna pro přihlášení. Po stisknutí tlačítka přihlásit je uživatel ověřen a při úspěšném ověření se uživateli zakládá uživatelská session a žadateli jsou zpřístupněny funkce aplikace pro přihlášené uživatele. V opačném případě je mu zobrazena chybová hláška.

Diagram 4 : přihlášení

Aktivita

Typ

Uživatelský interface

Zadání přihlašovacích údajů

Manuální

ANO

Odeslání údajů k ověření

Automatická

NE

Zobrazení chybové hlášky

Automatická

ANO

Přihlášení – založení user session

Automatická

NE

Tabulka 13 : Aktivity pro přihlášení

41

3.4.2 Aktivity přihlášeného uživatele Diagram aktivit vložení popisuje činnosti, které budou uživateli nabízeny při vkládání nového záznamu o uskutečněném prodeji ceny do aplikace. Bude mu zobrazen formulář pro vložen. Po vyplnění formuláře bude mít možnost údaje ve vyplněném formuláři smazat nebo uložit. V případě ukládání záznamu projde formulář kontrolou, zda jsou zadávané údaje validní a v kladném případě je záznam uložen do databáze a uživatel je informován hláškou o úspěšném uložení. V opačném případě je mu zobrazena chybová hláška.

Diagram 5 : Vložení

Aktivita

Typ

Uživatelský interface

Zobrazení formuláře

Manuální

ANO

Vyplnění formuláře

Manuální

ANO

Zobrazit chybovou hlášku

Automatická

ANO

Záznam – uložení do DB

Automatická

NE

Info o vložení

Automatická

ANO

Tabulka 14 : Aktivity pro vložení

42

Akce vyhledání je zobrazena v diagramu aktivit vyhledání. Uživatel zadá vyhledávací parametry a po stisknutí tlačítka vyhledat proběhne výběr záznamů v databázi dle vyhledávacích kriterií a tyto záznamy mu budou zobrazeny. Jednotlivé vyhledané záznamy si může uživatel zobrazit detailně při zvolené akci zobrazit detail u daného záznamu. Pokud dle vyhledávacích kriterií nebude nalezen žádný záznam, zobrazí se uživateli hláška záznamy nenalezeny. Tlačítkem smazat může vyhledávací zadaná kriteria ve formuláři pro vyhledávání smazat.

Diagram 6 : Vyhledání Aktivita

Typ

Uživatelský interface

Zadání vyhledávacích parametrů

Manuální

ANO

Výběr záznamů v databázi

Automatická

NE

Zobrazení hlášky – záznamy nenalezeny

Automatická

ANO

Zobrazení nalezených záznamů

Automatická

ANO

Zobrazení detailu

Manuální

ANO

Tabulka 15 : Aktivity pro vyhledání

43

Diagram aktivit aktualizace profilu zobrazuj činnosti prováděné při změně osobních údajů, které jsou uložené v databázi pro právě přihlášeného uživatele. Vedle změn osobních údajů uživatel může měnit i heslo.

Diagram 7 : Aktualizace profilu

Aktivita

Typ

Uživatelský interface

Zobrazení formuláře pro změnu pro přihlášeného uživatele

Manuální

ANO

Editace údajů

Manuální

ANO

Změna záznamu - UZIVATEL

Automatická

NE

Tabulka 16 : Aktivity pro aktualizaci profilu

44

Přihlášený uživatel může na stránce, která zobrazuje jím zadané uskutečněné prodej provádět jejich editaci. Detailní popis prováděné editace a způsob ukládání do databáze popisuje následující diagram aktivit.

Diagram 8 : Aktualizace vlastních záznamů Aktivita

Typ

Uživatelský interface

Zobrazení záznamu dle osobního čísla přihlášeného uživatele

Automatická

ANO

Zobrazení detailu o záznamu v editovacím formuláři

Manuální

ANO

Chybová hláška

Automatická

ANO

Uložení změn - ZAZNAM

Automatická

NE

Informace o uložení

Automatická

ANO

Tabulka 17 : Aktivity pro aktualizaci vlastních záznamů

45

Po volbě akce odhlášení je přihlášený uživatel odhlášen a je zrušena user session, dále je přesměrován na úvodní stránku aplikace jako nepřihlášený uživatel.

Diagram 9 : Odhlášení

Aktivita

Typ

Uživatelský interface

Odhlásit

Manuální

ANO

Zrušení user session

Automatická

NE

Zobrazení úvodní stránky

Automatická

ANO

Tabulka 18 : Aktivity pro odhlášení

3.4.3 Aktivity aplikačního administrátora Aplikační administrátor má možnost žadatelé o registraci schvalovat a tím registrovat do databáze nebo žádost o registraci zamítnout a tohoto žadatele smazat ze seznamu žadatelů.

46

Uvedený diagram aktivit nepopisuje manuální způsob ověřování pravosti zadaných údajů uživatele, kterou provádí administrátor formou telefonního pohovoru na telefonní číslo uvedené v žádosti.

Diagram 10 : Administrace žadatelů

Aktivita

Typ

Uživatelský interface

Zobrazení seznamu žádostí

Automatická

ANO

Zobrazit detail o uživateli

Manuální

ANO

Aktualizace v DB – UZIVATEL/ZADATEL

Automatická

NE

Smazání z DB

Automatická

NE

Informace o provedené akci

Automatická

ANO

Tabulka 19 : Aktivity pro administraci žadatelů 47

3.5 RAD implementace Vývoj aplikace pomocí nástroje RAD se vyznačuje sloučením fáze návrhu a implementace. RAD nástroje umožňují vývojářům v reálném čase při tvorbě aplikace přímo ověřit reálné použití navrhovaného a reagovat tak na jednotlivé výsledky řešení. RAD implementace je založena na provedené fázi analýza a to zejména s důkladným zaměřením na podrobné zmapování požadavků. Požadavky jsou využívány jako základní zdroj informací pro sloučenou fázi návrhu s implementací. Z toho vyplývá, že požadavek je bez rozpadu do detailní úrovně návrhu programových modulů přímo implementován prostředky RAD nástroje. Jak již bylo zmíněno, RAD nástroj umožňuje okamžitou kontrolu správnosti řešení, jinými slovy plnění konkrétního požadavku. Aby bylo možné tímto agilním způsobem realizovat implementaci aplikace, musí RAD vývojové prostředí obsahovat sadu podpůrných implementačních nástrojů, které takový způsob implementace přímo podporují.

3.5.1 Implementační nástroje Oracle

APEX,

potažmo

Database

Express

Edition,

obsahuje

následující

sadu

implementačních nástrojů pro podporu RAD vývoje. Přístup k jednotlivým nástrojům je v Oracle APEX realizován pomocí webového prohlížeče, kde si vývojář aplikace prostřednictvím ikony pro příslušný nástroj zpřístupní potřebnou funkcionalitu. Následující obrázek zobrazuje základní sadu dostupných implementačních nástrojů.

Obrázek 2 : Implementační nástroje Oracle APEX

48

Funkcionalita dostupná volbou ikony Administration umožňuje základní administraci databáze, zejména vytváření nových databázových uživatelů, jinými slovy schémat pro ukládání databázových objektů, které budou využívány v rámci následně vyvíjené aplikace. Nástroj Object Browser umožňuje rychlým způsobem spravovat databázové objekty, zejména se jedná o činnosti vytváření objektů, jejich modifikaci a případné mazání. Object browser nabízí vytváření databázových objektů bez nutné znalosti SQL DDL příkazů prostřednictvím objektových průvodců. Více o object browseru v kapitole o databázových objektech. Další nabízené a užitečné nástroje jsou dostupné na SQL stránce. Jak následující obrázek ukazuje, SQL stránka obsahuje SQL příkazovou řádku pro spouštění SQL příkazů a anonymních PL/SQL bloků. Pokud je potřeba v rámci vývoje nebo provozu aplikace opakovaně spouštět určité SQL příkazy, je možné využít nástroje, který se nazývá SQL Scripts a umožňuje opakovaně spouštěné SQL příkazy uložit do scriptů a ten pod jednoznačným identifikátorem uložit pro opakované použití do script repozitory. Pro uživatele, kteří nemají zkušenosti s používáním SQL příkazů je navržen nástroj Query Builder, který jednoduchou a grafickou formou umožňuje sestavování dotazů nad databázovými objekty.

Obrázek 3 : Stránka s SQL nástroji

Nástroje na stránce Utilities, zobrazené v následujícím obrázku, jsou navrženy zejména s ohledem na možnost zálohování databázových objektů. Nástroj Data Load/Unload se používá pro zálohování dat. Generate DDL umožňuje vygenerovat DDL příkazy pro tvorbu databázových

objektů.

Dojde-li

k odstranění

databázového

objektu

z databáze

prostřednictvím některého z nástrojů Oracle APEX, je možné jej pomocí nástroje Recycle Bin obnovit. Object Reports, jak z jeho názvu vyplývá, slouží k vytváření reportů nad 49

databázovými objekty. Jedná se o reporty administrátorského typu, kde je možné nalézt informace například o množství uložených dat, velikosti zabíraného prostoru, o počtu databázových objektů a jiné.

Obrázek 4 : Stránka s Utilities

Vedle nástrojů uvedených na stránce Utilities a určených pro zálohování dat a databázových objektů, nabízí Oracle APEX nástroj pro zálohování vytvořených aplikací a to formou exportu a případného importu metadat aplikace z aplikační metadata repository. Způsob exportu a importu zobrazuje následující obrázek.

Obrázek 5 : Export/Import aplikačních metadat

Výše popsané nástroje tvoří základní skupinu pro vývoj a správu aplikací a s nimi souvisejících databázových objektů. Další nástroje, například pro správu uživatelských oprávnění nad databázovými objekty, již popisovat blíže v této práci nebudu. Pro tvorbu aplikace pro oceňování nemovitostí další nástroje nepovažuji za nezbytné.

50

3.5.2 Databázové objekty Jak již bylo řečeno v úvodu kapitoly RAD implementace, nástroje pro rychlý vývoj aplikací se vyznačují sloučení fáze návrh a implementace a ani v případě návrhu databázových objektů, které budou využívány aplikací, tomu není jinak. V případě aplikace pro oceňování nemovitostí, požadavky na databázové objekty jsou jednak dány požadavky, které vyplývají z odborného článku a jednak z excelovských tabulek, ve kterých se uchovávají v současné formě informace o uskutečněných prodejích. Tabulky jsou uvedeny v příloze č.1 této práce. Na základě požadavků a uvedených excelovských tabulek se v prostředí Oracle APEX, podotýkám bez nutné znalosti DDL příkazů, vytvářejí pomocí průvodců potřebné databázové objekty a to zejména tabulky, sequence a databázové trigery. RAD přístup umožňuje nad vytvořeným databázovým objektem rychle zrealizovat potřebnou funkcionalitu vyplývající z požadavků a v reálném čase ověřit zda právě vytvořený databázový objekt splňuje potřebná očekávání. Zároveň RAD přístup, v případech kdy navržený databázový objekt nesplňuje potřebná kriteria, umožňuje rychlou modifikaci příslušného databázového objektu vzhledem k požadované funkcionalitě. Příklad průvodce tvorby databázového objektu je zobrazen na následujícím obrázku, ze kterého lze vyčíst jednotlivé kroky při vytváření databázového objektu.

Obrázek 6 : Průvodce tvorby databázového objektu

51

V prvním kroku se definují sloupce tabulky, v druhém kroku se definuje primární klíč, dále případné cizí klíče, omezení. Po posledním kroku se automaticky generuje SQL DDL příkaz, který je možné před jeho spuštěním zkontrolovat, popř. se vrátit k některému z předchozích kroků k dopřesnění definice. Následující snímek obrazovky zobrazuje poskytnuté informace a možnosti o databázových objektech, konkrétně o databázové tabulce. Již vytvořený objekt je možné na uvedené obrazovce revidovat, popř. modifikovat jeho vlastnosti

Obrázek 7 : Informace poskytované o databázové tabulce

Velmi užitečnou vlastností, která je pro správu databázových objektů nabízena, je možnost zobrazení a úprav vygenerovaného DDL kódu na základě údajů zadaných v průvodci pro tvorbu daného objektu. DDL kód je možné upravovat a následně kompilovat. Příklad DDL kódu pro tabulku uchovávající záznamy možných dispozic řešení nemovitostí je uveden na následujícím obrázku.

Obrázek 8 : Vygenerovaný DDL kód

52

Správa databázových objektů pomocí Oracle APEX je propracovaná a umožňuje tvorbu a správu objektů i těm uživatelům, kteří nejsou programátorsky zaměřeni a s příkazy SQL DDL neumějí pracovat.

3.5.3 Vývoj aplikace Implementační prostředí zahrnuje nástroje pro správu databázových objektů, se kterými jsme se seznámili v předchozí kapitole. Důležitým nástrojem pro implementaci je nástroj pro vývoj samotné aplikace, která vedle databázových objektů zahrnuje funkcionalitu pro podporu business logiky a uživatelský interface pro ovládání aplikace. Tvorba aplikace v RAD nástroji Oracle APEX vždy začíná definicí aplikace. Definice aplikace zahrnuje pojmenování aplikace jednoznačným názvem a nadefinování parametrů, které jsou k dané aplikaci vztaženy. Jedná se o tzv. aplikační parametry, mezi které patří zejména způsob přihlašování do vytvářené aplikace a nadefinování aplikačních proměnných, které jsou sdílené a dostupné pro všechny komponenty, ze kterých bude aplikace tvořena. Obdobně jako u databázových objektů i pro tvorbu aplikace existuje sada průvodců, které mu umožní rychlou a přehlednou tvorbu aplikace.

Obrázek 9 : Správa aplikací

Množství vytvářených aplikací není v Oracle APEX omezeno. Je limitováno pouze kapacitou dostupných systémových prostředků. Vzhledem k tomu, že se jedná pouze o webové aplikace, které je možné produktem Oracle APEX vytvářet, základní komponentou, která je součástí každé webové aplikace, je webová stránka. Aplikace je tedy tvořena jednou nebo více stránkami. Webová stránka je nositelem aplikační logiky a funkcionality. Tím je dána její jedinečnost a důležitost pro samotnou aplikaci. Proto tvůrci produktu Oracle APEX věnovali způsobu tvorby stránek velkou pozornost a výsledkem je důmyslný

53

systém, který na základě aplikačních metadat uložených v repozitory, efektivním způsobem dokáže vygenerovat výslednou html stránku, ověřit zadané údaje ve formulářích na stránce a zavolat potřebné procedury a funkce pro správu dat v databázi.

Obrázek 10 : Realizace webových stránek

Při tvorbě nové stránky ve vybrané aplikaci se nejprve prostřednictvím jednoduchého průvodce zadá jméno stránky a vybere příslušná šablona, podle které bude stránka zobrazena. Takto vytvořena samotná stránka je prázdná a je nabídnuta k doplnění o aplikační logiku. Přidání funkcionality do stránky je realizováno prostřednictvím webového uživatelského rozhraní s předdefinovanou funkcionalitou. Realizační interface se rozdělen do třech sloupců, kde každý sloupec má nadefinován pevně daný počet regionů s vymezenou funkcionalitou. První sloupec, který se nazývá Page Rendering, český překlad pro tento termíny je vykreslování stránky, je zaměřen na vlastnosti, které se bezprostředně týkají funkcionality související s vykreslováním stránky. Do tohoto sloupce se přidávají zejména webové položky, jako jsou textová pole, seznamy hodnot, tlačítka, radiobutony a další, které se zobrazují koncovému uživateli. Druhý sloupec Page Processing – zpracování, je zaměřen na vkládání funkcionality pro kontrolu vložených hodnot, na vkládání databázových volání nebo spouštění SQL příkazů. Sloupec Processing umožňuje vytvářené stránce dodávat dynamičnost, jinými slovy, změnu obsahu stránky na základě předem definovaných kriterií. Poslední sloupec je navržen pro zadávání tzv. sdílených komponent,

54

které jsou používány i na jiných stránkách aplikace. Například se jedná o komponentu šablona, která sdílením dodává jednotný vzhled všem stránkám, tedy výsledné aplikace.

Obrázek 11 : Správa aplikace a přístup k aplikačním stránkám

V diplomové práci si nekladu za cíl detailním způsobem popisovat jednotlivé kroky tvorby databázových objektů, stránek a zapracování aplikační logiky do nich, proto považuji základní seznámení se způsobem vývoje aplikace Oracle APEX za dostatečné. Detailní popis práce s produktem Oracle APEX je popsán v celé řadě programátorských příruček dostupných na veřejných stránkách společnosti Oracle. Implementovaná funkcionalita navíc jednoznačně vyplývá z popisu vytvořené aplikace, který je v následujících kapitolách. Za nutné však považuji předložit seznam databázových objektů, které byly vytvořeny pro danou aplikaci. Seznam uvádím formou tabulky, kde pro každý typ použitého databázového objektu je vytvořena samostatná tabulka s přehledem názvu a popisem pro použití objektu.

55

Detailní definice jednotlivých databázových objektů jsou uvedeny v příloze č. 2, a to formou DDL příkazů, které byly automaticky vygenerovány z průvodců pro tvorbu objektů.

Objekt

Popis

C_DISPOZICE

Číselník dispozičního řešení pro vybraný typ nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_JADRA

Číselník typu jádra pro vybraný typ nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_OKRESU

Číselník okresu pro vybraný typ nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_KATASTRALNI_UZEMI

Číselník katastrálního území pro vybraný typ nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_KOMERCNICH_OBJEKTŮ

Číselník typu komerčního objektu. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_KRAJU

Číselník krajů pro vybraný typ nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_MATERIALU

Číselník typu materiálu pro vybraný typ nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_NEMOVITOSTI

Číselník typu nemovitosti. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

C_POZEMKU

Číselník typu pozemku. Hodnoty číselníku vycházejí z excelovské tabulky, viz příloha č. 1

UZIVATELE

Tabulka se záznamy registrovaných uživatelů

ZADATELE

Tabulka se záznamy žadatelů o registraci

ZAZNAM

Tabulka se záznamy uskutečněných prodejů Tabulka 20 : Databázové tabulky

Ve výše uvedené tabulce je seznam databázových tabulek a jejich popis, které vycházejí z excelovské aplikace a aplikačních potřeb, které nebylo nutné řešit při uchovávání dat formou excelovské tabulky.

56

Objekt

Popis

OVERENI_UZIVATELE

Funkce pro ověření uživatele

Tabulka 21 : Databázová funkce

Tato funkce, jejíž DDL kód je uveden v příloze č. 2, má na vstupu osobní číslo a heslo uživatele, v těle se provádí vyhledání záznamu, který odpovídá vstupním osobnímu číslu a heslu. Funkce vrací hodnotu TRUE nebo FALSE podle výsledku vyhledání.

Objekt

Popis

C_DISPOZICE_SEQ C_JADRA_SEQ C_OKRESU_SEQ C_KATASTRALNI_UZEMI_SEQ

Sekvence pro získání pořadového C_KOMERCNICH_OBJEKTŮ_SEQ

čísla, které slouží jako unikátní identifikátor záznamu v tabulce, jejíž

C_KRAJU_SEQ

název vyplývá z názvu sekvence. Zde

C_MATERIALU_SEQ

uvádím pouze seznam sekvencí. C_NEMOVITOSTI_SEQ

Detailní popis v příloze

C_POZEMKU_SEQ UZIVATELE_SEQ ZADATELE_SEQ ZAZNAM_SEQ

Tabulka 22 : Databázové sequence

Vytvořené sekvence, jejichž seznam je ve výše uvedené tabulce, plní funkci pro získání unikátní identifikační hodnoty, která se používá pro jednoznačné rozlišení záznamů ve většině použitých tabulce. Pro každou tabulku je vytvořena sequence a při vkládání nového záznamu do tabulky je sequence zavolána prostřednictvím databázového trigeru, který se provede před vložením záznamu do tabulky a ze sequence získává pořadové číslo záznamu, které nebylo ještě použito. Přehled databázových trigerů je uveden v následující tabulce. Detailní DDL příkaz, ze kterého lze vyčíst způsob práce se sekvencí je uveden v příloze.

57

Objekt

Popis

BI_C_DISPOZIC BI_C_JADRA BI_C_OKRESU BI_C_KATASTRALNI_UZEMI BI_C_KOMERCNICH_OBJEKTŮ

Příslušnost databázového BI_C_KRAJU

trigeru k tabulce vyplývá BI_C_MATERIALU

z názvu samotného objektu

BI_C_NEMOVITOSTI BI_C_POZEMKU BI_UZIVATELE BI_ZADATELE BI_ZAZNAM

Tabulka 23 : Databázové trigery

U každé tabulky byl vytvořen další databázový objekt typu primární klíč a typu index, pro které již tabulku s popisem v této práci neuvádím, neboť jejich detailní popis je uveden v DDL příkazu pro vytvoření tabulky a je součástí přílohy.

58

4 Používání aplikace Popis používání aplikace je členěn stejným způsobem jako popis požadavků a následné analýzy. Aplikace je popsána z pohledu nepřihlášeného uživatele, přihlášeného uživatele a aplikačního administrátora. Součástí popisu používání aplikace je nejen popis uživatelského rozhraní, ale i skryté aplikační funkcionality, která tvoří jádro samotné aplikace a vychází z analýzy a návrhu založených na best-practices pro tento typ úlohy a produktu. Všechny stránky, které jsou součástí aplikace, jsou založeny na společné komponentě typu šablona, která aplikaci propůjčuje jednotný vzhled. Použitá šablona je tvořena záhlavím, ve kterém je umístěno logo aplikace, v našem případě bitmapový obrázek s názvem aplikace. Dále se v záhlaví nachází linky pro přihlášení a odhlášení uživatele. Doplněnou komponentou do jinak předdefinované šablony je zobrazení příjmení přihlášeného uživatele. Příjmení přihlášeného uživatele je do šablony vloženo jako globální aplikační proměnná, která se naplní při přihlášení uživatele, kdy na základě zadaného osobního čísla, v tabulce uživatelé vyhledá příslušné příjmení a dosadí se do dané proměnné. Součástí záhlaví jsou i aplikační záložky, kde po kliknutí na záložku se zobrazuje tělo šablony. Tělo šablony může obsahovat jeden nebo více regionů pro zobrazení webového formuláře, diagramu, reportu nebo prostého html textu. Další sdílenou komponentou, která vedle šablony propůjčuje aplikaci jednotný vzhled, je kontextové menu, tvořené html linky s odkazem na příslušnou aplikační stránku. Uživatel pro přístup k aplikačním stránkám může volit buď ze seznamu linků aplikačního menu, nebo z jemu dostupných záložek. Vedle sdílených vizuálních komponent aplikace obsahuje i skrytou funkcionalitu, která zajišťuje autorizaci pro přístup k jednotlivým stránkám. Autorizace je členěna do třech skupin a to pro nepřihlášeného a přihlášeného uživatele a dále aplikačního administrátora.

4.1 Nepřihlášený uživatel Po přístupu na aplikační stránky má podle nastavené autorizační politiky nepřihlášený uživatel přistup ke stránkám úvod, registrace, kontakt a přihlášení. Tak jak je uvedeno na následujícím obrázku, kde je zobrazena úvodní stránka, která poskytuje základní informace

59

o aplikaci, o jejím využití, o tom, komu je určena, jak aplikace funguje a co má udělat zájemce o plnohodnotné užití aplikace..

Obrázek 12 : Úvodní stránka aplikace

Pokud chce uživatel plnohodnotně využívat aplikaci, musí nejprve zažádat o registraci a to prostřednictvím stránky registrace, kde je nabídnut registrační formulář. Informace potřebné k registraci a vzhled formuláře je patrný z následujícího obrázku.

Obrázek 13 : Žádost o registraci

60

Skrytá funkcionalita, která není z obrázku patrná, zajišťuje, po stisknutí tlačítka registruj, zavolání SQL DML příkazu INSERT pro uložení údajů do tabulky ZADATELE. Narozdíl od stránky pro žádost o registraci stránka s kontaktními informacemi, která je uvedena na následujícím obrázku, neobsahuje žádnou skrytou funkcionalitu a zobrazuje pouze jeden html region.

Obrázek 14 : Kontaktní informace

Pro nepřihlášeného uživatele zásadní stránkou, která mění jeho status z pohledu aplikace, jinými slovy z nepřihlášeného uživatele dělá uživatele přihlášeného, je stránka pro přihlášení. Po vyplnění přihlašovacích údajů a stisknutí tlačítka přihlášení se údaje předají funkci OVERENI_UZIVATELE a na základě výstupu z uvedené funkce, je uživatel přihlášen nebo mu je zobrazena chybová hláška o neplatných přihlašovacích údajích. Další funkcí, která je zavolána po úspěšném ověření uživatele pomocí zmíněné funkce, je zavolání vestavěné funkcionality, která je na stránku přidána v její definici. Vestavěné funkce obecně tvoří důležitou část RAD nástroje Oracle APEX a zajišťují bez nutnosti programovat vlastní funkcionalitu využívat funkce, které jsou předpřipravené, vestavěné. Volaná vestavěná funkce z definice stránky se nazývá LOGIN a zajišťuje uložení osobního

61

čísla přihlášeného uživatele do jemu přiděleného paměťového prostoru, který nazýváme uživatelská session. Vzhled přihlašovací stránky je zobrazen v následném obrázku.

Obrázek 15 : Přihlašovací dialog

Jiná funkcionalita než ta, která je uvedena v této kapitole, není nepřihlášenému uživateli přístupná. Přístupy zajišťuje vestavěná funkcionalita, která se jednoduchým způsobem navolí v definici dané stránky v podmínkách určených pro způsob zobrazení stránky.

4.2 Přihlášený uživatel Hlavní funkcionalita aplikace, která spočívá ve vyhledávání uskutečněných prodejů, které mají usnadnit porovnávání cen a tím stanovení obvyklé ceny u dané nemovitosti, je přístupná pouze přihlášenému uživateli. Přihlášenému uživateli jsou krom stránky přihlášení a registrace dostupné zbývající stránky pro nepřihlášeného uživatele. Zjišťování uskutečněných prodejů je přístupné na stránce vyhledávání, kde uživateli po zadání typu vyhledávané nemovitosti, jsou dynamicky nabídnuty relevantní kriteria pro vyhledávání odpovídající požadavku PZ07 z analýzy projektu.

62

Vyhledané záznamy jsou zobrazeny v reportu, vzhled je patrný z obrázku níže a na následném obrázku je zobrazení detailních informací k vybranému záznamu.

. Obrázek 16 : Stránka pro vyhledávání

Obrázek 17 : Detail uskutečněného prodeje

63

Vkládání záznamů do databáze je uskutečňováno přes webový formulář, který dynamicky mění obsah údajů pro zadávání dle typu nemovitosti, tak jak vyplývá z požadavků definovaných při analýze.

Obrázek 18 : Vložení záznamu o uskutečněném prodeji

Po stisknutí tlačítka vložit se před zavoláním SQL DML příkazu INSERT provádí validace vybraných údajů formuláře a případné zobrazení chybové hlášky u konkrétní chybné položky formuláře. Po úspěšném vložení záznamu do databáze je uživateli zobrazena informativní hláška o provedené akci.

Údaje, které uživatel zadává při žádosti o registraci a na základě kterých byl do aplikace zaregistrován, mu jsou přístupné na stránce profil. S uživatelské session je před zobrazení údajů ve formuláři pro úpravu profilu získáno osobní číslo uživatele a pro dané osobní číslo je proveden SQL SELECT v databázi nad tabulkou uživatele a údaje ze získaného záznamu jsou ve formuláři profil nabídnuty k úpravám.

64

Po stisknutí tlačítka uložit změny je zavolána funkce UPDATE, která provede změnu záznamu v databázi. Následující obrázek zobrazuje formulář pro úpravu uživatelského profilu.

Obrázek 19 : Profil uživatele

Každý záznam o uskutečněném prodeji, který je uložen do databáze sebou nese i informaci o uživateli, který záznam pořídil a to formou uložení jemu přiděleného osobního čísla do záznamu. Identifikace záznamu podle osobního čísla vkladatele je využita na stránce pro zobrazení a případnou modifikaci jím vložených záznamů.

Tato funkcionalita je dostupná na stránce moje záznamy, která je zobrazena na následujícím obrázku. Na uvedené stránce může uživatel pro zvolený záznam upravit jim vložené údaje. Při úpravě údajů však nemůže již měnit typ nemovitosti, který je zásadní pro počet a typ zobrazených údajů pro vyplnění a následnou kontrolu vložených hodnot. Uživateli není povoleno měnit typ nemovitosti, je mu však povoleno záznam smazat a tal v případech, kdy při vkládání záznamu vybral chybný typ nemovitosti, může smazáním záznamu tuto chybu napravit. Report se záznamy, které pořídil právě přihlášený uživatel je možné třídit vybranými sloupci jako je nemovitost, kraj, typ pozemku, komerční objekt, kupní cena,

65

datum vložení. Třídění podle vybraných sloupců je užitečnou vlastností, kterou poskytuje Oracle APEX a je možné ji jednoduchým způsobem zakomponovat do vytvářeného reportu.

Obrázek 20 : Záznamy přihlášeného uživatele

Funkcionalita, která nemá vlastní stránku a nemůže být formou obrázku znázorněna, je funkce pro odhlášení uživatele z aplikace. Odhlášení uživatele z aplikace je realizováno zavoláním vestavěné funkcionality. Zavolání funkce pro odhlášení se provede prostřednictvím html linku v záhlaví aplikace. Po odhlášení a zrušení user session, je uživatel přesměrován na úvodní stránku aplikace jako nepřihlášený uživatel.

4.3 Aplikační administrátor Přihlášený uživatel, u kterého je v záznamu v tabulce UZIVATELE ve sloupci skupina uvedena textová hodnota „admin“, je zpřístupněna navíc záložka pro administraci uživatelů. Obsah záložky pro administraci je zobrazen na obrázku níže. Administrace uživatelů spočívá ve výběru žadatele o registraci ze zobrazeného reportu se seznamem žadatelů o registraci. Administrátor u každého konkrétního žadatele, konkrétního záznamu v databázi v tabulce ZADATELE, provádí kontrolu vložených údajů 66

a to jak kontrolu vizuální, zda jsou zadány údaje smysluplné a dále provádí ověření zadaných údajů formou kontaktování žadatele na jim uvedené kontaktní údaje. Zpracování registrace vychází z požadavku PZ10 a je také podle něj realizováno.

Obrázek 21 : Administrace uživatelů

Vedle reportu žadatelů o registraci je administrátorovi nabídnut i seznam již registrovaných uživatelů a to formou reportu, který může třídit podle vybraných sloupců, jak je znázorněno na obrázku výše. Veškerá použita funkcionalita je založena na SQL nebo PL/SQL příkazech. Záleží jen na způsobu spuštění příkazu a na jeho načasování. To se realizuje podle toho, zda zobrazena stránka má obsahovat report nebo formulář. V případě zobrazování reportu se příkaz spouští před generováním obsahu stránky a výsledek reportu přímo ovlivňuje zobrazené informace. Na druhé straně údaje pro vkládání jsou do databáze uloženy až ve fázi přechodu z jedné stránky na druhou. Uvedený způsob realizace byl použit v rámci celé aplikace.

67

Výsledky Aplikace pro oceňování nemovitostí, která slouží jako pomocný nástroj pro stanovení obvyklé ceny nemovitosti na základě v ní uložených uskutečněných prodejů je vyvinuta a provozována na Oracle APEX za využití best-practices načerpaných z veřejně dostupných zdrojů zaměřených na realizaci pomocí zvoleného RAD nástroje. Při použitém postupu se osvědčilo věnovat důkladnou přípravu odbornému článku a z něj vydefinování požadavků na aplikaci. Jako správné se ukázala kontrola správnosti vydefinovaných požadavků a jejich ujasnění si formou use-case diagramu a jednotlivých use-case scénářů. Velmi užitečné a vycházející ze zmiňovaných best-practices, je v rámci analýzy použití diagramů aktivit. Diagramy aktivit byly velmi užitečným pomocníkem při vlastní realizaci aplikace. Ujasnění si aktivit a stavů grafickým způsobem zrychlilo následný samotný vývoj. Při takto provedené analýze vlastní implementace aplikace RAD nástrojem Oracle APEX nevyžadovala zpětné změny do analýzy a realizace byla uskutečňována bez zásadních problémů s implementací požadované funkcionality. Dodržením uvedeného postupu je vytvoření a zprovoznění webové aplikace s funkcionalitou tak, jak bylo vyspecifikováno. Aplikace v provozním prostředí Oracle APEX je stabilní. Stránky jsou zobrazovány v přijatelném časovém intervalu, max. v jednotkách vteřin, a přestože aplikace nebyla zatěžována velkým množstvím dat a připojením uživatelů, lze na základě vlastních zkušeností se stabilitou prostředí při vývoji a testování aplikace a ze zkušeností z různých internetových zdrojů předpokládat, stejnou stabilitu a odezvu i při větší datové a uživatelské zátěži. Zkoumáním výkonnostní problematiky Oracle APEX však nebylo předmětem diplomové práce a jedná se jen o přidružený výsledek vyplívající z realizace a provozování. Na základě vlastních zkušeností mohu tvrdit, že jednoduchou aplikaci bez složitější aplikační logiky zvládne vytvořit i uživatel bez programátorských znalostí

68

Závěry a doporučení V úvodu mé diplomové práce si kladu za cíl ověřit tvrzení společnosti Oracle, že pomocí produktu APEX je možné vytvořit funkční aplikaci i bez programátorských znalostí. Po provedené realizaci mohu tvrdit, že uváděné tvrzení je platné pouze v případech, kdy vyvíjená aplikace bude založena čistě na výsledcích aplikačních průvodců. Ale v případech, kde nabízená vestavěná funkcionalita nestačí, se bez základních programátorských znalostí není možné obejít. Jen na příkladu uvádím, že například zobrazení příjmení přihlášeného uživatele v případě, kdy uživatel se přihlašuje osobním číslem, nelze realizovat pomocí aplikačního průvodce a je nutné vytvořit jednoduchý dotaz do databáze založený na SQL příkazu. Samotný vývoj aplikace bez dobře zvolené metodologie pro realizaci by byl zmatečný a nevedl by k požadovanému výsledku. Velmi oceňuji dostupnost relevantních informací, které se týkají samotného vývoje pomocí Oracle APEX. Zde použitý projektový postup vycházející z best-practices mohu jen doporučit a to i přesto, že část týkající se usecase diagramů a scénářů se mi při prvním seznámení zdála nadbytečná, ale při dokončení uvedené části oceňuji úlohu use-case scénářů zejména z pohledu zpětné kontroly na plnění požadavků. Použití diagramu aktivit považuji pro implementace pomocí RAD produktů za nezbytné. K samotné vyvinuté aplikaci musím dodat, že cílem bylo vytvoření provozuschopné aplikace a na základě požadavků vyplívajících z pseudoaplikace vytvořené v excelu. Je zřejmé, že aplikace by se dala dále vylepšovat a to jak z pohledu uživatelského komfortu, tak z pohledu implementované aplikační logiky. Závěrem musím konstatovat, že produkt Oracle APEX je vhodný pro realizaci webových aplikací a to od jednoduchých aplikací až po aplikace složité, je však mít na paměti, že složitější aplikace se bez programátorských znalostí nedají realizovat.

69

Seznam použité literatury 1.

BAKER Drue, ROMANO Anne, WINTERS Terri: Oracle Application Express Advanced Tutorials, Release 3.2 (online), © 2003, 2009, Oracle and/or its affiliates. E13363-01. 300 s. Dostupné z URL dne 1.12.2008 : http://download.oracle.com/docs/cd/E14373_01/appdev.32/e13363.pdf

2.

BENEŠ, Vladimír. Technická infrastruktura a síťové technologie. První vydání. Praha : Bankovní institut, a.s., leden 2005. ISBN 80-7265-063-7

3.

BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vyd. Praha : Grada, 2005. Management v informační společnosti. ISBN 80-247-1075-7.

4.

JENNINNGS Terri: Oracle Application Express Administration Guide, Release 3.2 (online), © 2003, 2009, Oracle and/or its affiliates. E13371-01. 106 s., dostupné dne 18.2.2009 z URL: http://download.oracle.com/docs/cd/E14373_01/admin.32/e13371.pdf

5.

KOVANDOVÁ, Marie, server LAMA, dostupný dne 7.4.2009 na URL: http://www.lama.cz/ocenem/on.php?co=1

6.

KOVANDOVÁ, Marie, server LAMA, odstavec 2, dostupné dne 7.4.2009 na URL: http://www.la-ma.cz/ocenem/on.php?co=1#1zp

7.

McCULLOUGH-DIETER, Carol. Mistrovství v Oracle8. Praha : Computer Press, 1999. ISBN 80-7226-204-1

8.

NAJVÁRKOVÁ, Milada, studijní materiál Úvod do oceňování – ceny a hodnoty, při studiu Odhadce nemovitostí na Bankovním institutu vysoké škole, v letech 2007-2008

9.

ORACLE Corporation. Oracle Database Administrator’s Guide 10g Release 1. Oracle, 2004. B10739-01. Dostupný dne 14.2.2009, z http://downloadwest.oracle.com/docs/cd/B14117_01/server.101/b10739/toc.htm

10. ORACLE CZECH, informace o produktu Oracle Database 10g Express Edition dostupné dne 6.4.2009 na URL http://www.oracle.com/global/cz/database/express_edition.html

I

11. Oracle Database Express Edition Installation Guide, 10g Release 2 (10.2) for Microsoft Windows (online), © 2005, 2007, Oracle. B25143-03. 34 s. Dostupné (dne 1.2.2009) z URL: http://download.oracle.com/docs/cd/B25329_01/doc/install.102/b25143.pdf 12. ORACLE Corporation, Když už tabulkové editory nestačí, r. 2007 dostupný dne 2.4.2009 na URL http://www.oracle.com/global/cz/database/2007_09_25_apex_01.pdf 13. ORT, Petr, Moderní metody oceňování nemovitostí na tržních principech, 1. Vydání. Praha : Bankovní institut vysoká škola, a.s. 2007, ISBN : 978-80-7265-113-9 14. ORT, Petr, Oceňování nemovitostí na tržních principech, str. 53, 1. Vydání. Praha : Bankovní institut vysoká škola, a.s. 2007, ISBN : 978-80-7265-101 15. Vyhláška č. 73/1964 Sb o cenách staveb v osobním vlastnictví a o náhradách při vyvlastnění nemovitostí, dostupná dne 7.2.2009 z URL http://abonent.lexdata.cz/lexdata/sb_free.nsf/c12571cc00341df10000000000000000/c1 2571cc00341df1c12566d40071ffed?OpenDocument 1 16. Vyhláška č. 43/1969 o cenách staveb v osobním vlastnictví a o náhradách při vyvlastnění nemovitostí, dostupná dne 7.2.2008 u URL http://www.mujweb.cz/www/lubomir/predpisy/43_1969.txt 17. Zákon č. 50/1976 Sb o územním plánování a stavebním řádu (Stavební zákon), dostupný dne 6.2.2009 na URL http://business.center.cz/business/pravo/zakony/stavebni/cast1.aspx 18. Zákon o vlastnictví bytů, dostupný dne 7.2.2009 na URL http://business.center.cz/business/pravo/zakony/byty/ 19. Zákon č. 563/1991 Sb. o účetnictví, § 25, odst. 1 dostupný dne 8.2.2009 z URL http://business.center.cz/business/pravo/zakony/ucto/cast4.aspx 20. Zákon č. 40/1964 Sb., Občanský zákoník, § 119, dostupný dne 6.2.2009 na URL http://business.center.cz/business/pravo/zakony/obcanzak/ 21. Zákon č. 151/1997 Sb., §2, odst. 1, o oceňování majetku, dostupný dne 8.2.2009 na URL http://www.mfcr.cz/cps/rde/xchg/mfcr/hs.xsl/zakony_1092.html

II

Seznam diagramů DIAGRAM 1 : USE CASE DIAGRAM ..................................................................................................................... 34 DIAGRAM 2 : VÝBĚR OBSAHU ZOBRAZENÍ ......................................................................................................... 39 DIAGRAM 3 : ŽÁDOST O REGISTRACI.................................................................................................................. 40 DIAGRAM 4 : PŘIHLÁŠENÍ................................................................................................................................... 41 DIAGRAM 5 : VLOŽENÍ....................................................................................................................................... 42 DIAGRAM 6 : VYHLEDÁNÍ.................................................................................................................................. 43 DIAGRAM 7 : AKTUALIZACE PROFILU ................................................................................................................ 44 DIAGRAM 8 : AKTUALIZACE VLASTNÍCH ZÁZNAMŮ ........................................................................................... 45 DIAGRAM 9 : ODHLÁŠENÍ .................................................................................................................................. 46 DIAGRAM 10 : ADMINISTRACE ŽADATELŮ ......................................................................................................... 47

Seznam tabulek TABULKA 1 : USE CASE SCÉNÁŘ - PŘIHLÁŠENÍ .................................................................................................. 35 TABULKA 2 : USE CASE SCÉNÁŘ - ODHLÁŠENÍ .................................................................................................. 35 TABULKA 3 : USE CASE SCÉNÁŘ - ZOBRAZENÍ ÚVODU ...................................................................................... 35 TABULKA 4 : USE CASE SCÉNÁŘ - ZOBRAZENÍ KONTAKTNÍCH ÚDAJŮ................................................................ 36 TABULKA 5 : USE CASE SCÉNÁŘ - ŽÁDOST O REGISTRACI ................................................................................. 36 TABULKA 6 : USE CASE SCÉNÁŘ – VLOŽENÍ ZÁZNAMU ..................................................................................... 36 TABULKA 7 : USE CASE SCÉNÁŘ – VYHLEDÁNÍ ZÁZNAMU ................................................................................ 37 TABULKA 8 : USE CASE SCÉNÁŘ – AKTUALIZACE PROFILU................................................................................ 37 TABULKA 9 : USE CASE SCÉNÁŘ – AKTUALIZACE VLASTNÍCH ZÁZNAMŮ .......................................................... 37 TABULKA 10 : USE CASE SCÉNÁŘ – ADMINISTRACE ŽÁDOSTI ........................................................................... 38 TABULKA 11 : AKTIVITY PRO VÝBĚR OBSAHU ZOBRAZENÍ ................................................................................ 39 TABULKA 12 : AKTIVITY PRO ŽÁDOST O REGISTRACI ......................................................................................... 40 TABULKA 13 : AKTIVITY PRO PŘIHLÁŠENÍ ......................................................................................................... 41 TABULKA 14 : AKTIVITY PRO VLOŽENÍ .............................................................................................................. 42 TABULKA 15 : AKTIVITY PRO VYHLEDÁNÍ ......................................................................................................... 43 TABULKA 16 : AKTIVITY PRO AKTUALIZACI PROFILU ......................................................................................... 44 TABULKA 17 : AKTIVITY PRO AKTUALIZACI VLASTNÍCH ZÁZNAMŮ.................................................................... 45 TABULKA 18 : AKTIVITY PRO ODHLÁŠENÍ.......................................................................................................... 46 TABULKA 19 : AKTIVITY PRO ADMINISTRACI ŽADATELŮ ................................................................................... 47 TABULKA 20 : DATABÁZOVÉ TABULKY ............................................................................................................. 56 TABULKA 21 : DATABÁZOVÁ FUNKCE ............................................................................................................... 57 TABULKA 22 : DATABÁZOVÉ SEQUENCE ........................................................................................................... 57 TABULKA 23 : DATABÁZOVÉ TRIGERY .............................................................................................................. 58

III

Seznam obrázků OBRÁZEK 1 : IMPLEMENTAČNÍ NÁSTROJE ORACLE APEX ................................................................................ 48 OBRÁZEK 2 : STRÁNKA S SQL NÁSTROJI ........................................................................................................... 49 OBRÁZEK 3 : STRÁNKA S UTILITIES ................................................................................................................... 50 OBRÁZEK 4 : EXPORT/IMPORT APLIKAČNÍCH METADAT .................................................................................... 50 OBRÁZEK 5 : PRŮVODCE TVORBY DATABÁZOVÉHO OBJEKTU ........................................................................... 51 OBRÁZEK 6 : INFORMACE POSKYTOVANÉ O DATABÁZOVÉ TABULCE ................................................................. 52 OBRÁZEK 7 : VYGENEROVANÝ DDL KÓD ......................................................................................................... 52 OBRÁZEK 8 : SPRÁVA APLIKACÍ......................................................................................................................... 53 OBRÁZEK 9 : REALIZACE WEBOVÝCH STRÁNEK ................................................................................................ 54 OBRÁZEK 10 : SPRÁVA APLIKACE A PŘÍSTUP K APLIKAČNÍM STRÁNKÁM ........................................................... 55 OBRÁZEK 11 : ÚVODNÍ STRÁNKA APLIKACE ...................................................................................................... 60 OBRÁZEK 12 : ŽÁDOST O REGISTRACI................................................................................................................ 60 OBRÁZEK 13 : KONTAKTNÍ INFORMACE ............................................................................................................ 61 OBRÁZEK 14 : PŘIHLAŠOVACÍ DIALOG ............................................................................................................... 62 OBRÁZEK 15 : STRÁNKA PRO VYHLEDÁVÁNÍ ..................................................................................................... 63 OBRÁZEK 16 : DETAIL USKUTEČNĚNÉHO PRODEJE ............................................................................................ 63 OBRÁZEK 17 : VLOŽENÍ ZÁZNAMU O USKUTEČNĚNÉM PRODEJI ......................................................................... 64 OBRÁZEK 18 : PROFIL UŽIVATELE ..................................................................................................................... 65 OBRÁZEK 19 : ZÁZNAMY PŘIHLÁŠENÉHO UŽIVATELE ........................................................................................ 66 OBRÁZEK 20 : ADMINISTRACE UŽIVATELŮ ........................................................................................................ 67

IV

Příloha č. 1 : Excelovská tabulka, původní aplikace

Přílohy

a

Příloha č. 1

b

Příloha č. 1

Příloha č. 2 : SQL DDL příkazy

Příloha č. 2

CREATE TABLE "APLIKACNI_SKUPINY" ( "CISLO_SKUPINY" NUMBER(6,0) NOT NULL ENABLE, "NAZEV_SKUPINY" VARCHAR2(100) NOT NULL ENABLE, "POPIS" VARCHAR2(4000), CONSTRAINT "APLIKACNI_SKUPINY_PK" PRIMARY KEY ("CISLO_SKUPINY") ENABLE ) / CREATE TABLE "C_DISPOZICE" ( "ID" NUMBER(2,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(4), "POPIS" VARCHAR2(100), CONSTRAINT "C_DISPOZICE_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_JADRA" ( "ID" NUMBER(1,0), "NAZEV" VARCHAR2(10), "POPIS" VARCHAR2(100), CONSTRAINT "C_JADRA_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_OKRESU" ( "ID" NUMBER(4,0) NOT NULL ENABLE, "ID_KRAJE" NUMBER(3,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(100), CONSTRAINT "C_OKRESU_PK" PRIMARY KEY ("ID") ENABLE, CONSTRAINT "C_OKRESU_FK" FOREIGN KEY ("ID_KRAJE") REFERENCES "C_KRAJU" ("ID") ON DELETE CASCADE ENABLE ) / CREATE TABLE "C_KATASTRALNI_UZEMI" ( "CISLO_KU" NUMBER(6,0) NOT NULL ENABLE, "ID_OKRESU" NUMBER(2,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(100) NOT NULL ENABLE, CONSTRAINT "C_KATASTRALNI_UZEMI_PK" PRIMARY KEY ("CISLO_KU") ENABLE, CONSTRAINT "C_KATASTRALNI_UZEMI_FK" FOREIGN KEY ("ID_OKRESU") REFERENCES "C_OKRESU" ("ID") ON DELETE CASCADE ENABLE ) /

-1-

Příloha č. 2 CREATE TABLE "C_KOMERCNICH_OBJEKTU" ( "ID" NUMBER(2,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(20), "POPIS" VARCHAR2(100), CONSTRAINT "C_KOMERCNICH_OBJEKTU_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_KRAJU" ( "ID" NUMBER(3,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(100), CONSTRAINT "C_KRAJU_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_MATERIALU" ( "ID" NUMBER(2,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(15), "POPIS" VARCHAR2(100), CONSTRAINT "C_MATERIALU_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_NEMOVITOSTI" ( "ID" NUMBER(2,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(30), "POPIS" VARCHAR2(100), CONSTRAINT "C_NEMOVITOSTI_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_POZEMKU" ( "ID" NUMBER(2,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(20), "POPIS" VARCHAR2(100), CONSTRAINT "C_POZEMKU_PK" PRIMARY KEY ("ID") ENABLE ) / CREATE TABLE "C_TYPU_ZAZNAMU" ( "ID" NUMBER(1,0) NOT NULL ENABLE, "NAZEV" VARCHAR2(10) NOT NULL ENABLE, "POPIS" VARCHAR2(100), CONSTRAINT "C_TYPU_ZAZNAMU_PK" PRIMARY KEY ("ID") ENABLE ) /

-2-

Příloha č. 2 CREATE TABLE "UZIVATELE" ( "OSOBNI_CISLO" NUMBER(6,0) NOT NULL ENABLE, "JMENO" VARCHAR2(100), "PRIJMENI" VARCHAR2(100), "TITUL" VARCHAR2(10), "E_MAIL" VARCHAR2(100), "TELEFON" VARCHAR2(20), "ULICE" VARCHAR2(100), "MESTO" VARCHAR2(100), "PSC" VARCHAR2(10), "HESLO" VARCHAR2(100), "FIRMA" VARCHAR2(100), "ICO" NUMBER(8,0), "POZICE" VARCHAR2(100), "DATUM_REGISTRACE" DATE, "DATUM_SCHVALENI" DATE, "SKUPINA" VARCHAR2(10), CONSTRAINT "UZIVATELE_PK" PRIMARY KEY ("OSOBNI_CISLO") ENABLE ) / CREATE TABLE "UZIVATEL_SKUPINA" ( "OSOBNI_CISLO" NUMBER(6,0) NOT NULL ENABLE, "CISLO_SKUPINY" NUMBER(6,0) NOT NULL ENABLE, CONSTRAINT "UZIVATEL_SKUPINA_FK" FOREIGN KEY ("OSOBNI_CISLO") REFERENCES "UZIVATELE" ("OSOBNI_CISLO") ON DELETE CASCADE ENABLE, CONSTRAINT "UZIVATEL_SKUPINA_FK2" FOREIGN KEY ("CISLO_SKUPINY") REFERENCES "APLIKACNI_SKUPINY" ("CISLO_SKUPINY") ON DELETE CASCADE ENABLE ) / CREATE TABLE "ZADATELE" ( "OSOBNI_CISLO" NUMBER(6,0) NOT NULL ENABLE, "JMENO" VARCHAR2(100), "PRIJMENI" VARCHAR2(100), "TITUL" VARCHAR2(10), "E_MAIL" VARCHAR2(100), "TELEFON" VARCHAR2(20), "ULICE" VARCHAR2(100), "MESTO" VARCHAR2(100), "PSC" VARCHAR2(10), "HESLO" VARCHAR2(100),

-3-

"FIRMA" VARCHAR2(100), "POZICE" VARCHAR2(100), "ICO" NUMBER(8,0), "DATUM_REGISTRACE" DATE DEFAULT SYSDATE ) / CREATE TABLE "ZAZNAM" ( "ID" NUMBER NOT NULL ENABLE, "ID_TYP_ZAZNAMU" NUMBER, "ID_TYP_NEMOVITOSTI" NUMBER, "ID_KRAJE" NUMBER, "ID_OKRESU" NUMBER, "OBEC" VARCHAR2(4000), "KAT_UZEMI" VARCHAR2(4000), "CISLO_JEDNACI" VARCHAR2(4000), "DATUM_PREVODU" DATE, "ULICE" VARCHAR2(4000), "CISLO_POPISNE" VARCHAR2(4000), "PARCELNI_CISLA" VARCHAR2(4000), "CISLA_LV" VARCHAR2(4000), "ID_TYP_DISPOZICE" NUMBER, "M2_UZITNE_PLOCHY" NUMBER, "M2_OBYTNE_PLOCHY" NUMBER, "ID_TYP_POZEMKU" NUMBER, "M2_POZEMKU" NUMBER, "KUPNI_CENA" NUMBER, "ID_TYP_JADRA" NUMBER, "ID_TYP_MATERIALU" NUMBER, "ID_TYP_KOMERCNIHO_OBJEKTU" NUMBER, "CENA_M2_POZEMKU" NUMBER, "CENA_ZA_POZEMEK" NUMBER, "CENA_M2_BEZ_POZEMKU" NUMBER, "CENA_M2_VC_POZEMKU" NUMBER, "ROZESTAVENOST_PROCENT" NUMBER, "PRONAJATO" VARCHAR2(4000), "ROCNI_PRIJEM" NUMBER, "ROCNI_PRIJEM_M2" NUMBER, "CENA_OBVYKLA_SOUCASNA" NUMBER, "CENA_OBVYKLA_BUDOUCI" NUMBER, "POZNAMKA" VARCHAR2(4000), "CISLO_ZADAVATELE" NUMBER, "DATUM_VLOZENI" DATE, "DATUM_AKTUALIZACE" DATE, CONSTRAINT "ZAZNAM_PK" PRIMARY KEY ("ID") ENABLE )

-4-

Příloha č. 2

/ Příloha č. 2 CREATE OR REPLACE FUNCTION "OVERENI_UZIVATELE" (p_username IN VARCHAR2, p_password IN VARCHAR2) return BOOLEAN as v_pocet_nalezenych number; begin select count (*) into v_pocet_nalezenych from UZIVATELE where OSOBNI_CISLO = p_username and HESLO = p_password; return v_pocet_nalezenych > 0; EXCEPTION WHEN OTHERS THEN RETURN FALSE; end; / CREATE UNIQUE INDEX "APLIKACNI_SKUPINY_PK" ON "APLIKACNI_SKUPINY" ("CISLO_SKUPINY") / CREATE UNIQUE INDEX "C_DISPOZICE_PK" ON "C_DISPOZICE" ("ID") / CREATE UNIQUE INDEX "C_JADRA_PK" ON "C_JADRA" ("ID") / CREATE UNIQUE INDEX "C_KATASTRALNI_UZEMI_PK" ON "C_KATASTRALNI_UZEMI" ("CISLO_KU") / CREATE UNIQUE INDEX "C_KOMERCNICH_OBJEKTU_PK" ON "C_KOMERCNICH_OBJEKTU" ("ID") / CREATE UNIQUE INDEX "C_KRAJU_PK" ON "C_KRAJU" ("ID") / CREATE UNIQUE INDEX "C_MATERIALU_PK" ON "C_MATERIALU" ("ID") / CREATE UNIQUE INDEX "C_NEMOVITOSTI_PK" ON "C_NEMOVITOSTI" ("ID") / CREATE UNIQUE INDEX "C_OKRESU_PK" ON "C_OKRESU" ("ID") / CREATE UNIQUE INDEX "C_POZEMKU_PK" ON "C_POZEMKU" ("ID") / CREATE UNIQUE INDEX "C_TYPU_ZAZNAMU_PK" ON "C_TYPU_ZAZNAMU" ("ID") /

-5-

CREATE UNIQUE INDEX "UZIVATELE_PK" ON "UZIVATELE" ("OSOBNI_CISLO") / Příloha č. 2 CREATE UNIQUE INDEX "ZAZNAM_PK" ON "ZAZNAM" ("ID") / CREATE SEQUENCE "APLIKACNI_SKUPINY_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 41 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_DISPOZICE_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 26 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_JADRA_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 21 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_KOMERCNICH_OBJEKTU_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 22 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_KRAJU_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 3 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_MATERIALU_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 22 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_NEMOVITOSTI_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 7 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_OKRESU_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 5 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_POZEMKU_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 22 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "C_TYPU_ZAZNAMU_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 4 CACHE 20 NOORDER NOCYCLE /

-6-

Příloha č. 2 CREATE SEQUENCE "UZIVATELE_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 41 CACHE 20 NOORDER NOCYCLE / CREATE SEQUENCE "ZADATEL_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 7 NOCACHE NOORDER NOCYCLE / CREATE SEQUENCE "ZAZNAM_SEQ" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 63 CACHE 20 NOORDER NOCYCLE / CREATE OR REPLACE TRIGGER "BI_APLIKACNI_SKUPINY" before insert on "APLIKACNI_SKUPINY" for each row begin select "APLIKACNI_SKUPINY_SEQ".nextval into :NEW.CISLO_SKUPINY from dual; end; / ALTER TRIGGER "BI_APLIKACNI_SKUPINY" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_DISPOZICE" before insert on "C_DISPOZICE" for each row begin select "C_DISPOZICE_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_DISPOZICE" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_JADRA" before insert on "C_JADRA" for each row begin select "C_JADRA_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_JADRA" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_KOMERCNICH_OBJEKTU"

-7-

before insert on "C_KOMERCNICH_OBJEKTU" Příloha č. 2 for each row begin select "C_KOMERCNICH_OBJEKTU_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_KOMERCNICH_OBJEKTU" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_KRAJU" before insert on "C_KRAJU" for each row begin select "C_KRAJU_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_KRAJU" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_MATERIALU" before insert on "C_MATERIALU" for each row begin select "C_MATERIALU_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_MATERIALU" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_NEMOVITOSTI" before insert on "C_NEMOVITOSTI" for each row begin select "C_NEMOVITOSTI_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_NEMOVITOSTI" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_OKRESU" before insert on "C_OKRESU" for each row begin select "C_OKRESU_SEQ".nextval into :NEW.ID from dual;

-8-

end; Příloha č. 2 / ALTER TRIGGER "BI_C_OKRESU" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_POZEMKU" before insert on "C_POZEMKU" for each row begin select "C_POZEMKU_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_POZEMKU" ENABLE / CREATE OR REPLACE TRIGGER "BI_C_TYPU_ZAZNAMU" before insert on "C_TYPU_ZAZNAMU" for each row begin select "C_TYPU_ZAZNAMU_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_C_TYPU_ZAZNAMU" ENABLE / CREATE OR REPLACE TRIGGER "BI_UZIVATELE" before insert on "UZIVATELE" for each row begin select "UZIVATELE_SEQ".nextval into :NEW.OSOBNI_CISLO from dual; end; / ALTER TRIGGER "BI_UZIVATELE" ENABLE / CREATE OR REPLACE TRIGGER "BI_ZAZNAM" before insert on "ZAZNAM" for each row begin select "ZAZNAM_SEQ".nextval into :NEW.ID from dual; end; / ALTER TRIGGER "BI_ZAZNAM" ENABLE /

-9-