Podnikový informační systém pro odpadové hospodářství

Podnikový informační systém pro odpadové hospodářství Diplomová práce

Bc. Marek Rychlý

Podnikový informační systém pro odpadové hospodářství: Diplomová práce Bc. Marek Rychlý Vydáno jaro 2005

Podnikový informační systém pro odpadové hospodářství, Bc. Marek Rychlý.

Diplomová práce pojednává o analýze, návrhu a implementaci původního informačního systému pro podporu odpadového hospodářství podniku. První část práce je věnována stručnému úvodu do problematiky zpracování environmentálních informací pomocí environmentálního informačního systému. Dále autor popisuje legislativu odpadového hospodářství v České republice a Evropské unii, přičemž zvláštní pozornost je věnována legislativním povinnostem organizace podnikající na území České republiky. Ve třetí kapitole jsou upřesněny požadavky získané předchozí analýzou legislativy. Požadavky jsou formálně vyjádřeny pomocí případů užití a je navržen ideální a logický datový model informačního systému. V následující části práce se autor podrobně věnuje návrhu dynamické části informačního systému a volbě konkrétní architektury a technologií. Závěr práce upřesňuje návrh pro použité technologie a stručně popisuje implementaci a testování vzniklého informačního systému. V přílohách práce je mimo jiné uvedena specifikace aplikačního rozhraní serveru informačního systému a popis instalace, provozní údržby a bezpečnosti systému.

Obsah

1. Úvod ..............................................................................................................................................................1 Podnikový informační systém pro odpadové hospodářství..................................................................1 Environmentální informace ....................................................................................................................1 Environmentální informační systém ......................................................................................................2

2. Legislativa ....................................................................................................................................................4

Environmentální informace v České republice .....................................................................................4 Odpadové hospodářství v České republice............................................................................................5 Zákon o odpadech .........................................................................................................................5 Zákon o obalech ............................................................................................................................8 Environmentální informace a odpadové hospodářství v Evropské unii ............................................10 Odpadové hospodářství z pohledu podniku v České republice..........................................................12 Povinnosti dle zákona o odpadech .............................................................................................12 Povinnosti dle zákona o statistické službě.................................................................................14

3. Analýza požadavků a předběžný návrh informačního systému........................................................16

Požadavky..............................................................................................................................................16 Případy užití...........................................................................................................................................18 Aktér Uživatel .............................................................................................................................18 Aktér Administrátor ....................................................................................................................19 Aktér Správce subjektů ...............................................................................................................19 Aktér Operátor evidence odpadů................................................................................................20 Aktér Správce povolení odpadů .................................................................................................21 Aktér Operátor zpětného odběru ................................................................................................21 Aktér Operátor přepravy nebezpečných odpadů.......................................................................21 Aktér Správce zařízení k nakládání s odpady............................................................................22 Aktér Správce identifikačních listů nebezpečných odpadů......................................................22 Aktér Odběratel výkazů ..............................................................................................................22 Ideální datový model.............................................................................................................................23 Objekty ideálního datového modelu ..........................................................................................23 Vazby ideálního datového modelu.............................................................................................25

4. Návrh informačního systému ..................................................................................................................30 Logický datový model ..........................................................................................................................30 Datové typy..................................................................................................................................31 Číselníky ......................................................................................................................................32 Atributy objektů logického datového modelu ...........................................................................35 Diagram datových toků.........................................................................................................................36 Procesy správy uživatelů ............................................................................................................36 Procesy údržby systému..............................................................................................................38 Procesy správy subjektů, osob a jejich zodpovědností .............................................................38 Procesy evidence odpadů a povolení odpadů............................................................................38 Procesy evidence zpětného odběru ............................................................................................42 Procesy evidence zařízení, přepravy a id. listů nebezpečných odpadů ...................................43 Procesy zpracování výkazů ........................................................................................................43

iii

5. Architektura a podrobný návrh systému..............................................................................................47

Architektura systému ............................................................................................................................47 Fyzický datový model...........................................................................................................................48

6. Implementace a testování informačního systému ................................................................................51

Technologie a nástroje ..........................................................................................................................51 Aplikační rozhraní serveru ...................................................................................................................52 Správa uživatelů a údržba systému ............................................................................................52 Nastavení prostředí......................................................................................................................52 Obecná evidence .........................................................................................................................54 Evidence odpadů a povolení odpadů .........................................................................................55 Evidence zpětného odběru..........................................................................................................55 Zpracování výkazů ......................................................................................................................56 Ostatní ..........................................................................................................................................56 Implementace a testování serveru ........................................................................................................57 Implementace a testování klienta .........................................................................................................57 Rozšíření ................................................................................................................................................58

7. Závěr ...........................................................................................................................................................60 Bibliografie.....................................................................................................................................................61 A. Atributy objektů logického datového modelu .....................................................................................62

B. Specifikace aplikačního rozhraní serveru ............................................................................................70 Uživatelské pohledy ..............................................................................................................................70 Uložené procedury ................................................................................................................................73

C. Instalace.....................................................................................................................................................78 Instalace serveru a databáze .................................................................................................................78 Instalace klienta.....................................................................................................................................79 Migrace ..................................................................................................................................................80

D. Provoz ........................................................................................................................................................82 Řízení přístupu ......................................................................................................................................82 Záloha a obnova dat ..............................................................................................................................82 E. Bezpečnost .................................................................................................................................................84 Hrozby a rizika ......................................................................................................................................84 Opatření vedoucí ke snížení rizik a způsobených škod ......................................................................84 Prosazování bezpečnostních opatření v informačním systému ..........................................................85 F. Obsah přiloženého CD.............................................................................................................................87 Rejstřík ...........................................................................................................................................................88

iv

Seznam tabulek

A-1. atributy objektu (#dopravcePrepravyNO).............................................................................................62 A-2. atributy objektu (#idListNO) .................................................................................................................62 A-3. atributy objektu (#obcanBezIC).............................................................................................................63 A-4. atributy objektu (#odpad).......................................................................................................................64 A-5. atributy objektu (#odpadPrepravyNO)..................................................................................................64 A-6. atributy objektu (#osoba) .......................................................................................................................64 A-7. atributy objektu (#povoleni)...................................................................................................................65 A-8. atributy objektu (#povolenyOdpad) ......................................................................................................65 A-9. atributy objektu (#prepravaNO).............................................................................................................65 A-10. atributy objektu (#provozovna) ...........................................................................................................66 A-11. atributy objektu (#sidloFirmy).............................................................................................................66 A-12. atributy objektu (#sidloObce) ..............................................................................................................66 A-13. atributy objektu (#skupSkladky) .........................................................................................................66 A-14. atributy objektu (#subjekt) ...................................................................................................................67 A-15. atributy objektu (#zarizeni)..................................................................................................................67 A-16. atributy objektu (#zarizeniSklad) ........................................................................................................68 A-17. atributy objektu (#zarizeniSkladka) ....................................................................................................68 A-18. atributy objektu (#zarizeniZarizeni) ....................................................................................................68 A-19. atributy objektu (#zodpOsoby) ............................................................................................................68 A-20. atributy objektu (#zpetnyOdberPrijem) ..............................................................................................69 A-21. atributy objektu (#zpetnyOdberVydej) ...............................................................................................69

v

Kapitola 1. Úvod

Podnikový informační systém pro odpadové hospodářství

S rozvojem informačních technologií roste jejich vliv na životní prostředí. Můžeme konstatovat, že průmysl informačních technologií jistě ohrožuje životní prostředí, neboť spotřebovává přírodní zdroje (zejména energii a suroviny). Informační technologie také pomáhají člověku v jeho boji „proti“ přírodě. Bez informačních technologií bychom neměli letadla znečišťující ovzduší, vrtné věže ničící mořské dno nebo rybářské lodě lovící jen v místech, kde je podle mapování větší hustota mořských živočichů. Na druhou stranu právě nasazení informačních technologií v oblastech ochrany životního prostředí a omezení jeho znečišťování má významný vliv na udržení přírodního bohatství. Informační systémy umožňují efektivně sledovat stav životního prostředí a jeho ovlivňování činnostmi člověka, ať už v lokálním, či globálním měřítku.

Cílem této práce je návrh a implementace informačního systému, který umožní sběr, evidenci a zhodnocení informací v oblasti nakládání s odpady v rámci podniku. Takto získané informace mohou vést k lepšímu pochopení a uvědomění si významu odpadového hospodářství pro ochranu životního prostředí, a zejména ke kritickému pohledu na technologie použité ve výrobě a při nakládání s odpady. Důsledkem může být snaha podniku o zkvalitnění výrobních technologií a redukci záporného vlivu na životní prostředí. Informace poskytované systémem mohou být důležité také na vyšších úrovních, např. pro rozhodování o celkové politice odpadového hospodářství oblasti či státu.

Environmentální informace

Existuje mnoho definic pojmu „informace“. Podle teorie informace je to kvantitativní jednotka vyjadřující snížení nejistoty a je přesně definována pomocí entropie. Toto vyjádření uvedeného pojmu však není vhodné pro pochopení obecného významu informace v informačních systémech. Mnohem více nám pomůže definice1, podle níž je pojem informace vyjádřen jako znalost získaná zkoumáním a zkušenostmi nebo převzata pomocí učení, či definice informace jako získaných dat, kterým bylo porozuměno.

Z výše uvedeného plyne, že je třeba rozlišovat mezi pojmy „data“ a „informace“. Pojmem data rozumíme nezpracovanou formu informací v původním stavu, tj. bez přisouzeného významu. Informace pak přiřazuje datům význam a interpretuje je do srozumitelné podoby. Tento vztah mezi daty a informacemi také odpovídá definici v teorii informace, neboť samotná data nejistotu nesnižují.

Pojem informace je standardizován normou ISO/IEC 2382-1:1993, kterou vyvinula komise ISO/IEC JTC1 (Informační technologie) mezinárodní organizace pro normalizaci ISO (International Organisation for Standardisation). V dubnu 1998 byla uvedená norma přejata Českým normalizačním ústavem jako česká norma ČSN ISO/IEC 2382-1 (Informační technologie – Slovník – Část 1: Základní termíny) s účinností od 1. května 1998. Norma rozlišuje pojmy data a informace, přičemž informace je znalost týkající se objektů a data jsou opakovaně interpretovatelná formalizovaná podoba této informace. Norma též striktně rozlišuje mezi pojmy zpracování dat a zpracování informací. Zpracováním dat je rozuměno aplikování funkcí na data (např. třídění, nesémantické vyhledávání, kompilace, přenos atd.),

1

Kapitola 1. Úvod narozdíl od zpracování informací, což je systematické provádění operací s informacemi, zahrnující zpracování dat, datovou komunikaci a automatizaci kancelářských prací (např. přeměna informací aplikací důsledku).

V oblasti životního prostředí musíme opět rozlišit pojmy data a informace. Environmentální data jsou data týkající se objektů a procesů z oblasti životního prostředí. Pojem „environmentální informace“, jako informace o životním prostředí, lze podle Mezinárodního fóra o informacích v životním prostředí charakterizovat takto: „data, statistiky a jiné kvantitativní a kvalitativní údaje, které rozhodovací orgány vyžadují k hodnocení stavu a trendů změn prostředí, k formulaci a upřesňování ekologické politiky a k účelnému využívání prostředků“, jak uvádí [Hrebicek99]. Velký důraz je kladen na správnou a odbornou interpretaci environmentálních dat, protože se jedná o data statistického charakteru, která v čisté formě nemají pro běžného uživatele smysl. Významným rysem environmentálních dat je také silná časoprostorová závislost (data se bezprostředně týkají pouze části životního prostředí ve vymezeném časovém intervalu). Dle [Hrebicek99] mají environmentální data z hlediska možné reprezentace a srovnání dvě podoby: kvantitativní (v podobě číselného vyjádření určité veličiny) a kvalitativní (v podobě nečíselného ohodnocení významu). Podle úrovně abstrakce je lze dále rozlišit na:

1. primární data – to jsou data získaná sledováním objektů a procesů se vztahem k životnímu prostředí prostřednictvím monitoringu a následného zpracování dat. Jejich získávání od subjektů může být vynuceno legislativou (např. hlášení o nakládání s odpady). Primární data nejsou určena pro veřejnost z důvodu obtížného výkladu (jedná se o prostá data v specifických formátech), ale také z důvodu ochrany osobních dat či obchodních tajemství.

2. agregovaná data – jsou data získaná zpracováním primárních dat, především použitím agregačních (statistických) funkcí (souhrn, průměr, apod.). Jedná se o první stupeň interpretace environmentálních dat. Agregovaná data jsou použitelná pro odbornou veřejnost, umožňují sledovat stav životního prostředí v určitém prostorovém a časovém ohraničení. Tato data nejsou vhodná pro srovnávání v globálním měřítku. 3. environmentální indikátory – jedná se o vysoce abstrahovaná environmentální data získaná násobnou aplikací agregačních funkcí. Hodnoty environmentálních indikátorů jsou normalizované (často standardy na národní či mezinárodní úrovni), a proto umožňují srovnání. Zejména kvantitativní podoba indikátorů je lehce srozumitelná široké veřejnosti, a přitom vhodná pro srovnání (zjištění trendu) a kvalifikované rozhodnutí.

Kvalita environmentální informace, tj. vhodně reprezentovaná informace získaná z environmentálních dat vhodným způsobem, má zásadní vliv na kvalitní rozhodnutí, která vedou k dosažení trvale udržitelného rozvoje společnosti. Kvalita provedených rozhodnutí je pak díky zpětné vazbě2 opět měřitelná pomocí environmentálních dat.

Environmentální informační systém

Obecný význam pojmu „informační systém“ bývá definován jako souhrn prostředků, procesů, osob a zodpovědností, sloužící k získávání, zpracování a uchovávání dat a prezentaci informací uživatelům systému vhodným způsobem (podrobněji viz [Kral]). Informační systém tedy nejen zpracovává data, ale též informace (ve smyslu předchozí části kapitoly). Jako environmentální informační systém pak bude označen informační systém zpracovávající environmentální data a informace.

2

Kapitola 1. Úvod Vzhledem k tomu, že životní prostředí je úzce svázáno s mnoha obory lidské činnosti, zpracování environmentální informace můžeme nalézt i v informačních systémech, které nejsou navrhovány primárně jako environmentální informační systémy. Zde je nutno brát v úvahu specifické vlastnosti zpracování environmentální informace, a to zejména: •

•

•

•

velké množství environmentálních dat vstupujících do systému – Je obtížné vybrat environmentální data relevantní pro požadovanou informaci (zejména při návrhu systému) a omezit zpracování informací pouze na tato data3.

komplexnost a dynamika procesů v životním prostředí – Procesy nemusí být stejné v době návrhu systému a v době jeho používání. Životní prostředí je měkký systém, kde výsledky procesů nejsou stálé a závisí na mnoha okolnostech.

zpětná vazba mezi informačním systémem a životním prostředím – Provoz environmentálního informačního systému zpětně ovlivňuje životní prostředí, neboť informace získané z informačního systému jsou použity pro rozhodnutí mající vliv na životní prostředí, ze kterého původní informace pocházejí. Může být požadováno, aby systém uměl sledovat zpětnou vazbu ve vstupních datech a vhodným způsobem ji prezentoval ve výstupních informacích.

časoprostorová závislost environmentální informace – Je třeba rozlišit environmentální data z různých prostorových lokalit a časových intervalů. Environmentální data je nutné ukládat a zpracovávat odděleně, a také rozlišovat původ dat vstupujících do procesu zpracování environmentální informace (např. při použití agregačních funkcí).

Výše uvedená specifika environmentálních informačních systémů vycházejí z vlastností environmentální informace a systému životního prostředí. Jedná o obecné vlastnosti, které mají vliv na kvalitu zpracování environmentální informace, na informační schopnost systému, a následně také na kvalitu rozhodnutí ovlivňujících životní prostředí. Z toho důvodu je způsob získávání environmentálních dat a zpracování environmentální informace často vázán standardy či legislativními předpisy, jak bude popsáno v následující kapitole. Zájemce o podrobnější informace o problematice environmentálních informačních systémů odkazujeme na [Hrebicek04].

Poznámky

1. např. lexikální databáze WordNet 2.0, http://www.cogsci.princeton.edu/cgibin/webwn?stage=1&word=information 2. viz další část podkapitoly

3. Vzhledem k rostoucím kapacitám paměťových médií a jejich nízké ceně je možné ukládat větší množství získaných environmentálních dat, než je potřeba pro zpracování informací. Nadbytečná data se mohou využít později při nových způsobech získání environmentální informace. Toto však neřeší problém výběru relevantních dat pro samotný proces zpracování informací.

3

Kapitola 2. Legislativa

V předchozí kapitole jsme stručně prezentovali základní charakteristiky environmentálních dat a informací, včetně jejich specifických vlastností a vlastností environmentálních informačních systémů. Vzhledem k tomu, že se jedná o informace týkající se životního prostředí a mající nezanedbatelný dopad na celou společnost, pojmy environmentální informace a její zpracování bývají vázány legislativními předpisy na národní i mezinárodní úrovni. Tato kapitola se pokusí popsat stav environmentální informace v legislativě České republiky a Evropské unie, s důrazem na legislativu odpadového hospodářství. Zvláštní pozornost bude věnována legislativním povinnostem organizace podnikající na území České republiky. Následující text vychází zejména z databází platných legislativních předpisů v [gov.cz] a [EUR-Lex].

Environmentální informace v České republice

V České republice definuje environmentální informaci zákon číslo 123/1998 Sb. ze dne 13. května 1998 „o právu na informace o životním prostředí“ novelizován zákony č. 132/2000 Sb. a č. 6/2005 Sb. Tento zákon vymezuje pojem „informace o životním prostředí“ jako informace v jakékoliv technicky proveditelné podobě, které vypovídají zejména o1: • •

•

•

•

•

• •

•

•

stavu a vývoji životního prostředí, o příčinách a důsledcích tohoto stavu,

připravovaných nebo prováděných činnostech a opatřeních a o uzavíraných dohodách, které mají nebo by mohly mít vliv na stav životního prostředí a jeho složek,

stavu složek životního prostředí… a o interakci mezi nimi, o látkách, energii, hluku, záření, odpadech včetně radioaktivních odpadů a dalších emisích do životního prostředí, které ovlivňují nebo mohou ovlivňovat jeho složky, a o důsledcích těchto emisí, využívání přírodních zdrojů a jeho důsledcích na životní prostředí a rovněž údaje nezbytné pro vyhodnocování příčin a důsledků tohoto využívání a jeho vlivů na živé organismy a společnost,

vlivech staveb, činností, technologií a výrobků na životní prostředí a veřejné zdraví a o posuzování vlivů na životní prostředí,

správních řízeních ve věcech životního prostředí, posuzování vlivů na životní prostředí…, informace obsažené v písemnostech týkajících se zvláště chráněných součástí přírody…,

zprávách o provádění a plnění právních předpisů v oblasti ochrany životního prostředí,

mezinárodních, státních, regionálních a místních strategiích a programech, akčních plánech apod., jichž se Česká republika účastní, a zprávách o jejich plnění, mezinárodních závazcích týkajících se životního prostředí a o plnění závazků vyplývajících z mezinárodních smluv, jimiž je Česká republika vázána, zdrojích informací o stavu životního prostředí a přírodních zdrojů, …

Zákon dále stanovuje rozsah a formu zveřejňovaných informací o životním prostředí a způsob podání a vyřízení žádosti o poskytnutí takové informace. Zdůrazněna je také zodpovědnost za environmentální vzdělávání, výchovu a osvětu.

4

Kapitola 2. Legislativa Další legislativu lze rozdělit podle složek životního prostředí, na které je nejvíce zaměřena. Takto je legislativně omezeno nakládání s chemickými látkami (např. zákon 356/2003 Sb. o chemických látkách a chemických přípravcích), odpady (např. zákon 185/2001 Sb. o odpadech a zákon 477/2001 Sb. o obalech), ochrana ovzduší (např. zákon 86/2002 Sb. o ochraně ovzduší), vody (např. zákon 254/2001 Sb. o vodách), půdy a zemědělství (např. zákon č. 334/1992 Sb. o ochraně zemědělského půdního fondu), lesnictví (např. zákon 289/1995 Sb. o lesích), myslivost (např. zákon č. 449/2001 Sb. o myslivosti), ochrana přírody (např. zákon č. 460/2004 Sb. o ochraně přírody a krajiny), atd. Vzhledem k rozsahu problematiky životního prostředí a její provázanosti s ostatními obory není možné určit přesné hranice legislativy životního prostředí či jeho jednotlivých složek. Vlastnosti obecných environmentálních informačních systémů nejsou v ČR legislativně omezeny. Výjimku tvoří informační systémy používané veřejnou správou. Základním legislativním předpisem pro vedení a správu informačních systémů veřejné správy je zákon č. 365/2000 Sb. o informačních systémech veřejné správy, který vymezuje pojmy z oblasti informačních systémů a postupy jejich zavádění. S tímto souvisí také ostatní zákony, jako je zákon č. 106/1999 Sb. o svobodném přístupu k informacím, zákon č. 101/2000 Sb. o ochraně osobních údajů nebo zákon č. 227/2000 Sb. o elektronickém podpisu. Existuje také celá řada standardů a doporučení, které by měly splňovat informační systémy veřejné správy, vydaných zejména Úřadem pro veřejné informační systémy (ÚVIS)2 a později Ministerstvem informatiky.

Odpadové hospodářství v České republice

Oblast odpadového hospodářství legislativně vymezuje zákon č. 185/2001 Sb. o odpadech a o změně některých dalších zákonů (zákon o odpadech), a zákon č. 477/2001 Sb. o obalech a o změně některých zákonů (zákon o obalech).

Zákon o odpadech

Zákon č. 185/2001 Sb.3 o odpadech a o změně některých dalších zákonů (dále jen zákon o odpadech) ze dne 15. května 2001, s účinností od 1. ledna 2002 až na výjimky, stanoví4 v souladu s právem Evropských společenství pravidla pro předcházení vzniku odpadů a pro nakládání s odpady. Zákon zdůrazňuje nutnost dodržování ochrany životního prostředí, zdraví člověka a trvale udržitelného rozvoje, a určuje práva a povinnosti osob v odpadovém hospodářství a působnost orgánů veřejné správy.

Zákon o odpadech definuje základní pojem „odpad“ jako každou movitou věc, které se osoba zbavuje nebo má úmysl nebo povinnost se jí zbavit, a která přísluší do některé z 16 skupin odpadů uvedených v příloze č. 1 k tomuto zákonu. Odpady se dále dělí na „ostatní“ odpady (kód kategorie O) a „nebezpečné“ odpady (kód N), přičemž nebezpečné jsou odpady uvedené v Seznamu nebezpečných odpadů5 nebo vykazující nejméně jednu nebezpečnou vlastnost uvedenou v příloze č. 2 k zákonu o odpadech (pokud se jedná o ostatní odpady s nebezpečnými vlastnostmi, mají kód O/N). Nebezpečné vlastnosti odpadu mohou být přehodnoceny osobou pověřenou ministerstvem, která může vydat žadateli osvědčení o vyloučení nebezpečných vlastností odpadu (takový odpad má kód N/O). Podrobnosti hodnocení nebezpečných vlastností odpadů upřesňuje vyhláška č. 376/2001 Sb. Do kategorie „komunální“ odpad patří odpad vznikající na území obce při činnosti fyzických osob (s výjimkou fyzických osob oprávněných k podnikání) a nevznikající u právnických osob, který je uveden jako komunální odpad v prováděcím právním předpise6.

V zákoně o odpadech jsou definovány také následující pojmy:

5

Kapitola 2. Legislativa odpadové hospodářství:

činnost zaměřená na předcházení vzniku odpadů, nakládání s odpady a následnou péči o místo, kde jsou odpady trvale uloženy, a kontrola těchto činností,

nakládání s odpady:

shromažďování, soustřeďování, sběr, výkup, třídění, přeprava a doprava, skladování, úprava, využívání a odstraňování odpadů,

shromažďování odpadů:

krátkodobé soustřeďování odpadů do shromažďovacích prostředků v místě jejich vzniku před dalším nakládáním s odpady,

sběr odpadů:

soustřeďování odpadů právnickou nebo fyzickou osobou oprávněnou k podnikání od jiných subjektů za účelem jejich předání k dalšímu využití nebo odstranění,

výkup odpadů:

sběr odpadů v případě, kdy odpady jsou právnickou nebo fyzickou osobou oprávněnou k podnikání kupovány za sjednanou cenu,

skladování odpadů:

přechodné umístění odpadů, které byly soustředěny (shromážděny, sesbírány, vykoupeny) do zařízení k tomu určeného a jejich ponechání v něm,

úprava odpadů:

každá činnost, která vede ke změně chemických, biologických nebo fyzikálních vlastností odpadů (včetně jejich třídění) za účelem umožnění nebo usnadnění jejich dopravy, využití a odstraňování, snížení jejich objemu, případně snížení jejich nebezpečných vlastností,

využívání odpadů:

činnosti uvedené v příloze č. 3 k tomuto zákonu (energetické využití, regenerace, recyklace, získání složek, atd.),

materiálové využití odpadů:

náhrada prvotních surovin látkami získanými z odpadů, které lze považovat za druhotné suroviny, nebo využití látkových vlastností odpadů k původnímu účelu nebo k jiným účelům, s výjimkou bezprostředního získání energie,

energetické využití odpadů:

použití odpadů hlavně způsobem obdobným jako paliva za účelem získání jejich energetického obsahu nebo jiným způsobem k výrobě energie,

odstraňování odpadů:

činnosti uvedené v příloze č. 4 k tomuto zákonu (skládkování, spalování, různé druhy ukládání, biologická či fyzikálně-chemická úprava, atd.),

zařízení:

technické zařízení, místo, stavba nebo část stavby,

6

Kapitola 2. Legislativa skládka odpadů:

technické zařízení určené k odstraňování odpadů jejich trvalým a řízeným uložením na zemi nebo do země,

původce odpadů:

právnická osoba, při jejíž činnosti vznikají odpady, nebo fyzická osoba oprávněná k podnikání, při jejíž podnikatelské činnosti vznikají odpady. Pro komunální odpady vznikající na území obce, které mají původ v činnosti fyzických osob, na něž se nevztahují povinnosti původce, se za původce odpadů považuje obec. Obec se stává původcem komunálních odpadů v okamžiku, kdy fyzická osoba odpady odloží na místě k tomu určeném; obec se současně stane vlastníkem těchto odpadů,

oprávněná osoba:

každá osoba, která je oprávněna k nakládání s odpady podle tohoto zákona nebo podle zvláštních právních předpisů,

uvedení výrobku do oběhu:

úplatné nebo bezúplatné předání výrobku jiné osobě za účelem distribuce nebo použití. Za uvedení do oběhu se považuje též dovoz výrobku.

Odpady jsou dále rozděleny do kategorií Katalogu odpadů v souladu s § 5 zákona o odpadech, podle vyhlášky č. 381/2001 Sb., kterou se stanoví Katalog odpadů, Seznam nebezpečných odpadů a seznamy odpadů a států pro účely vývozu, dovozu a tranzitu odpadů a postup při udělování souhlasu k vývozu, dovozu a tranzitu odpadů (zkráceně Katalog odpadů).

Zákon o odpadech zdůrazňuje povinnost předcházet vzniku odpadů a omezovat jejich množství a nebezpečné vlastnosti. Právnické osoby a fyzické osoby oprávněné k podnikání musí vyrábět tak, aby omezily vznik nevyužitelných (zejména nebezpečných) odpadů výrobků. U odpadů, jejichž vniku nelze zabránit, se upřednostňuje jejich využití před odstraněním, přičemž materiálové využití (recyklace) má přednost. Zákon připouští uložení odpadu na skládku, pouze pokud jiný způsob odstranění není dostupný nebo by přinášel vyšší riziko pro životní prostředí nebo riziko pro lidské zdraví, a pokud uložení neodporuje právním předpisům. Převzít odpad do svého vlastnictví je oprávněn pouze provozovatel (podnik) zařízení k využití, odstranění, sběru nebo výkupu určeného druhu odpadu, nebo provozovatel schváleného zařízení, do kterého vstupuje odpad jako surovina. Komunální odpad může převzít také obec. Subjekt, který odpad předává, smí předat odpad jen osobě, která je k jeho převzetí oprávněna (to je důležité zejména při předávání nebezpečných odpadů). Dle zákona o odpadech je původce odpadů dále povinen: •

•

•

•

odpady, které sám nemůže využít nebo odstranit, předat za tímto účelem osobě oprávněné k jejich převzetí,

zařazovat odpady, ověřovat jejich vlastnosti a shromažďovat je utříděné podle jednotlivých druhů a kategorií,

vést průběžnou evidenci o odpadech, způsobech nakládání s nimi, PCB7 a zařízeních obsahujících PCB, ohlašovat změny příslušnému správnímu úřadu a tuto evidenci archivovat po stanovenou dobu,

ustanovit odpadového hospodáře (tj. odborně způsobilou osobu zodpovědnou za zajištění odborného nakládání s odpady a jednání s orgány veřejné správy v oblasti odpadového hospodářství, zejména při

7

Kapitola 2. Legislativa kontrolní činnosti), pokud nakládal během posledních dvou let s více než 100 t nebezpečného odpadu za rok nebo se jedná o provozovatele skládky nebezpečných či komunálních odpadů,

•

vypracovat plán odpadového hospodářství původce odpadů, pokud původce produkuje ročně více než 10 t nebezpečného odpadu nebo více než 1000 t ostatního odpadu.

Zákon podrobněji stanovuje povinnosti obcím a osobám nakládajícím s komunálním odpadem, provozovatelům zařízení ke sběru nebo výkupu odpadů, skládek odpadů nebo spaloven, a povinnosti při přepravě odpadů. Zvláštní pozornost je věnována vyjmenovaným odpadům8, mezi které patří například PCB, odpadní oleje, baterie, akumulátory či autovraky. Podrobnostem nakládání s PCB se věnuje vyhláška č. 384/2001 Sb. Výrobcům a dovozcům některých výrobků9 nad stanovené množství nařizuje zákon o odpadech povinnost jejich zpětného odběru bez nároku na úplatu od spotřebitele, čímž se účinně sníží pravděpodobnost nevhodného nakládání s použitými výrobky (většinou se jedná o výrobky, kde je možné opakované použití). Předáním se použité výrobky stávají odpady a povinná osoba musí zajistit jejich využití nebo odstranění. Podrobnosti způsobu provedení zpětného odběru některých výrobků stanoví vyhláška č. 237/2002 Sb. Vedení evidence odpadového hospodářství podle zákona o odpadech a vyhlášky č. 383/2001 Sb. o podrobnostech nakládání s odpady bude věnována část kapitoly „Odpadové hospodářství z pohledu podniku v České republice“.

Zákon o obalech

Zákon č. 477/2001 Sb.10 o obalech a o změně některých dalších zákonů (dále jen zákon o obalech) ze dne 4. prosince 2001 nabývá účinnosti dnem 1. ledna 2002. Účelem zákona11 je chránit životní prostředí předcházením vzniku odpadů z obalů, zejména snižováním hmotnosti, objemu a škodlivosti obalů a chemických látek v těchto obalech obsažených, v souladu s právem Evropských společenství. Zákon o obalech vymezuje základní pojem „obal“ jako výrobek zhotovený z materiálu jakékoli povahy, určený k pojmutí, ochraně, manipulaci, dodávce, případě prezentaci jednoho nebo více výrobků určených spotřebiteli nebo jinému konečnému uživateli. Přitom zákon rozlišuje právě tři druhy obalů: 1. „spotřebitelský obal“ – pro spotřebitele nebo jiného konečného uživatele tvoří v místě nákupu prodejní jednotku,

2. „skupinový obal“ – pro spotřebitele nebo jiného konečného uživatele tvoří v místě nákupu z jakéhokoliv důvodu skupinu určitého počtu prodejních jednotek (přičemž skupina nemusí být prodávána jako celek) a může být z výrobku odstraněn, aniž se tím ovlivní jeho vlastnosti,

3. „přepravní obal“ – usnadňuje manipulaci či přepravu určitého množství prodejních jednotek nebo skupinových obalů, za účelem zabránění jejich fyzickému poškození.

Dále uvedený zákon definuje také následující pojmy: výrobek:

jakákoli věc, která byla vyrobena, vytěžena nebo jinak získána bez ohledu na stupeň jejího zpracování a je určena k uvedení na trh nebo do oběhu,

nakládání s obaly:

výroba, použití, úprava obalů, jejich opakované použití, uvádění obalů nebo balených výrobků na trh nebo do oběhu,

8

Kapitola 2. Legislativa uvedení obalu na trh:

okamžik, kdy je obal či balený výrobek v ČR poprvé úplatně či bezúplatně předán nebo nabídnut k předání za účelem distribuce nebo používání, nebo kdy jsou k němu poprvé převedena vlastnická práva, nebo okamžik dovozu do ČR,

uvedení obalu do oběhu:

úplatné nebo bezúplatné předání obalu nebo baleného výrobku jiné osobě za účelem distribuce nebo použití, s výjimkou uvedení obalu na trh,

dovoz obalu nebo baleného výrobku:

propuštění do režimu volného oběhu, aktivního zušlechťovacího styku, režimu dočasného použití nebo do režimu přepracování pod celním dohledem,

opakované použití obalu:

činnost, při níž se opakovaně použitelný obal znovu plní nebo se používá k témuž účelu, pro nějž byl určen, s pomocí nebo bez pomoci dodatečných prostředků, které opětovné plnění umožňují, jako jsou zejména náhradní doplňková balení a prostředky k jejich použití,

vratný obal:

obal, pro který existuje zvláště pro něj vytvořený způsob vracení použitého obalu osobě, která jej uvedla do oběhu,

zpětný odběr:

odebírání použitých obalů od spotřebitelů na území ČR za účelem opakovaného použití obalů nebo za účelem využití nebo odstranění odpadu z obalů,

obalový prostředek:

výrobek, z něhož je obal spotřebitelský, obal skupinový nebo obal přepravní přímo vyroben nebo který je součástí obalu sestávajícího se z více částí.

Osobě uvádějící obal, balený výrobek či obalový prostředek na trh ukládá zákon o obalech povinnost minimalizovat ekologickou zátěž možného odpadu z obalu. To znamená minimalizovat hmotnost a objem obalu, dodržet limitní koncentrace nebezpečných chemických látek a obsahu vyjmenovaných prvků, a zajistit jeho opakovatelnou použitelnost či využití (recyklací nebo energetickým využitím). Zákon též vymezuje způsob vyznačení uvedených skutečností na obal výrobku. Náležitosti těchto opatření stanoví přesněji vyhláška č. 115/2002 Sb. o podrobnostech nakládání s obaly.

Osobě uvádějící na trh nebo do oběhu výrobky ve vratných obalech stanoví zákon o odpadech povinnost zajistit jejich opakované využití, a v případě, že se jedná o zálohované vratné obaly, též vrácení zálohy. Povinnost zajistit zpětný odběr obalů se vztahuje na všechny obaly (nejen vratné) a povinná osoba ji může smluvně přenést společně s vlastnictvím obalu, případně smluvně zajistit její plnění autorizovanou obalovou společností12.

Osoba, která uvádí na trh nebo do oběhu obaly nebo balené výrobky, je dle zákona o dopadech povinna podat návrh na zápis do Seznamu osob, které jsou nositeli povinnosti zpětného odběru a využití odpadu z obalů, a musí vést evidenci obalů jí uvedených na trh nebo do oběhu, zpětně odebraných obalů a způsobu, jak s nimi bylo naloženo. Vedení evidence stanovené zákonem o obalech upřesňuje vyhláška č. 641/2004 Sb. o rozsahu a způsobu vedení evidence obalů a ohlašování údajů z této evidence.

9

Kapitola 2. Legislativa

Environmentální informace a odpadové hospodářství v Evropské unii

Pojem environmentální informace definovala pro Evropská společenství směrnice Rady číslo 90/313/EHS o svobodě přístupu k informacím o životním prostředí ze dne 7. června 1990, která zajišťuje veřejnosti přístup k environmentálním informacím a stanovuje podmínky pro šíření a poskytování těchto informací. Směrnice vymezuje environmentální informaci jako13: „jakoukoli dostupnou informaci v písemné, vizuální, zvukové či elektronické podobě týkající se stavu vody, ovzduší, půdy, živočichů, rostlin, krajiny a přírodních krajinných útvarů, dále činností (včetně činností, které mají rušivé účinky, jako například hluk) a opatření s nepříznivými či potenciálně nepříznivými účinky na životní prostředí, jakož i o činnostech a opatřeních, které mají za cíl vyjmenované jednotlivé složky chránit, a to včetně správních opatření a programů řízení životního prostředí“.

Výše uvedená směrnice 90/313/EHS platila od svého vyhlášení (v legislativě členských států od 1. ledna 1993) až do 14. února 2005, kdy ji nahradila směrnice Evropského parlamentu a Rady 2003/4/EC o veřejném přístupu k environmentální informaci. Nová směrnice rozšiřuje práva definované v předchozí směrnici, zejména s důrazem na moderní komunikační technologie (služby sítě Internet) jako prostředek pro šíření environmentální informace. Směrnice definuje pojem environmentální informace takto 14: jakákoliv psaná, vizuální, zvuková, elektronická nebo jinak zaznamenaná informace týkající se a. stavu složek životního prostředí, jako jsou atmosféra, voda, země, půda, krajina a přírodní plochy zahrnující mokřiny, pobřežní a mořské plochy, biologické druhy a jejich části, včetně geneticky modifikovaných organismů, a vztahy těchto složek,

b. činitelů, jako jsou látky, energie, hluk, radiace nebo odpad, zahrnující radioaktivní odpad, emise, nečistoty a jiné vlivy na životní prostředí, pokud ovlivňují nebo mohou ovlivňovat složky z bodu a. c. opatření (zahrnující administrativní opatření), jako jsou předpisy, legislativa, plány, programy, environmentální smlouvy, a aktivity ovlivňující nebo pravděpodobně ovlivňující složky a činitele z bodů a. a b., včetně opatření a aktivit chránící tyto složky,

d. zpráv o uskutečňování environmentální legislativy,

e. nákladů, zisků a dalších ekonomických analýz a předpokladů použitých v rámci opatření a aktivit z bodu c., f. stavu lidského zdraví a bezpečnosti, včetně kontaminace potravního řetězce, s důrazem na podmínky života lidí, stavu kulturních památek a staveb, jestliže ovlivňují nebo mohou ovlivňovat složky z bodu a. přímo nebo prostřednictvím činitelů či opatření z bodů b. a c.

Dne 15. července 1975 vydala Rada evropských společenství směrnici 75/442/EHS o odpadech, která měla sjednotit legislativu členských států v oblastech odpadového hospodářství s důrazem na ochranu lidského zdraví, životního prostředí a na vyrovnání podmínek hospodářské soutěže. Směrnice definovala pojmy „odpad“ a „odstraňování odpadu“ a uložila členským státům povinnost do dvou let od vydání směrnice přizpůsobit svou legislativu týkající se předcházení vzniku odpadu, jeho recyklace, energetického využití a odstranění bez ohrožení lidského zdraví a životního prostředí. Situace v oblasti odstraňování odpadů byla vyhodnocována v tříletých intervalech veřejnou souhrnnou zprávou. Od 1. května 1976 vznikl na základě rozhodnutí č. 76/431/EHS Rady evropských společenství ze dne 21. dubna 1976 Výbor pro nakládání s odpady, který měl za úkol předkládat komisi stanoviska týkající se politiky odpadového hospodářství společenství a provádění směrnic z této oblasti. V průběhu dalších

10

Kapitola 2. Legislativa let vznikly z podnětu uvedeného výboru směrnice a doporučení o postupech monitorování a regulace specifických odpadů, které mají nezanedbatelný vliv na životní prostředí.

Směrnice o odpadech byla novelizována směrnicí 91/156/EHS Rady evropských společenství ze dne 18. března 1991, která pozměnila stanovaná pravidla tak, aby byly respektovány zkušenosti získané prováděním původní směrnice o odpadech v členských státech. V rámci rozšíření jednotné terminologie a definice odpadů zavádí novela nové pojmy 15: původce, držitel, nakládání s odpady, využití a sběr. Novela klade důraz na omezování vzniku odpadů vývojem vhodných technologií šetrnějších k životnímu prostředí, na vývoj technologií k odstraňování nebezpečných látek z odpadů a vybudování jednotné sítě zařízení na bezpečné odstraňování odpadů. Novela též stanoví rámcový obsah plánů pro nakládání s odpady členských zemí, náležitosti povolení pro organizace nebo podniky, které provádějí odstraňování nebo využití odpadů, náležitosti evidence takového odstraňování nebo využití odpadů, a nutnost registrace podniků, které sbírají nebo přepravují odpad nebo které zařizují odstraňování či využití odpadů pro potřeby jiných osob. V přílohách novela kategorizuje odpady a způsoby odstraňování a využití odpadů. Legislativu skládkování a spalování odpadů podrobněji vymezují směrnice Rady evropských společenství č. 1999/31/ES o skládkách odpadů a směrnice Evropského parlamentu a Rady č. 2000/76/ES o spalování odpadů.

Nakládání s nebezpečnými odpady dále upřesňuje směrnice Rady evropských společenství č. 91/689/EHS16 o nebezpečných odpadech ze dne 12. prosince 1991, která definuje pojem „nebezpečný odpad“ a vymezuje legislativní omezení nakládání s takovým odpadem. Směrnice také kategorizuje druhy nebezpečných odpadů a definuje složky a vlastnosti odpadů, které způsobují jejich nebezpečnost. Odstranění nebezpečných odpadů spalováním podrobněji legislativně vymezuje směrnice Rady evropských společenství číslo 94/31/ES o spalování nebezpečných odpadů ze dne 27. června 1994.

Rozhodnutím Rady evropských společenství číslo 93/98/EEC ze dne 1. února 1993 se Evropská unie zavázala k dodržování Basilejské úmluvy o kontrole pohybu nebezpečných odpadů přes hranice států a jejich zneškodňování. Basilejská úmluva byla sjednána již v roce 1989 a pro členské státy nabyla platnosti dne 5. května 199217. Podle této úmluvy jsou členské státy povinny zneškodňovat nebezpečné odpady v místě jejich vzniku, a to způsobem, který nezatěžuje životní prostředí. Úmluva také kategorizuje nebezpečné odpady, definuje výčet nebezpečných vlastností odpadů, tzv. kódy dle Basilejské úmluvy.

Opatření týkající se nakládání s obaly a obalovými odpady sjednocuje směrnice Evropského parlamentu a Rady č. 94/62/ES18 o obalech a obalových odpadech. Tato směrnice se snaží předcházet vzniku obalového odpadu omezením celkového objemu obalů, upřednostňováním opakovaného použití obalů a recyklace, a snížením množství odstraňovaných obalových odpadů. Směrnice rovněž definuje19 pojem „obal“, včetně jeho kategorizace na prodejní, skupinový a přepravní obal, a další pojmy, jako jsou: obalové odpady, nakládání s obalovými odpady, opakované použití, využití, či recyklace.

Nařízení Evropského parlamentu a Rady evropských společenství číslo 2150/2002 o statistice odpadů ze dne 25. listopadu 2002 vymezuje rozsah a podrobnosti sběru statistických údajů o vzniku, využívání a odstraňování odpadů. Členské státy předávají požadovaná data Eurostatu 20, který je dále zpracovává a výsledné informace vyhodnotí do podoby environmentálních indikátorů. Získané informace jsou využívány pro rozhodování a pro vyhodnocení dodržování zásady předcházení vzniku odpadů. Výše vyjmenované právní předpisy reprezentují pouze zlomek z legislativy týkající se odpadového hospodářství v Evropských společenstvích a později v Evropské unii. Vzhledem k rychlému vývoji společnosti je třeba včas reagovat na nové druhy odpadů, které ohrožují životní prostředí21.

11

Kapitola 2. Legislativa

Odpadové hospodářství z pohledu podniku v České republice

Povinnosti podniku působícího v České republice vymezuje z hlediska odpadového hospodářství zákon č. 185/2001 Sb. o odpadech a o změně některých dalších zákonů (zákon o odpadech), zákon č. 477/2001 Sb. o obalech a o změně některých zákonů (zákon o obalech), zákon č. 89/1995 Sb. o státní statistické službě a jejich prováděcí vyhlášky. V této části se zaměříme na povinnosti podniku dle zákona o odpadech a zákona o statistické službě22, zejména na způsob a rozsah vedení evidence v oblasti odpadového hospodářství a na její vykazování.

Zájemce o podrobný popis povinností organizace odkazujeme na aktualizované vydání [Benes]23 nebo již neaktuální publikaci [Vejnar], která vychází z legislativy platné v roce 2002.

Povinnosti dle zákona o odpadech

Způsob nakládání s odpady a rozsah vedené evidence upřesňuje vyhláška č. 383/2001 Sb. o podrobnostech nakládání s odpady (dále jen vyhláška). Nakládání s některými odpady a jejich evidenci vymezují další vyhlášky, jako je vyhláška č. 382/2001 Sb. o podmínkách použití upravených kalů na zemědělské půdě a vyhláška č. 384/2001 Sb. o nakládání s PCB.

Průběžná evidence odpadů: Původci odpadů a oprávněné osoby nakládající s odpady (dále jen povinné subjekty) jsou podle § 21 vyhlášky povinni vést průběžnou evidenci o odpadech vlastních a převzatých a o způsobech nakládání s nimi, za každou samostatnou provozovnu a za každý druh odpadu zvlášť. Eviduje se zejména název odpadu dle Katalogu odpadů nebo upřesňující název, pokud je upřesnění vyžadováno, a dále katalogové číslo odpadu a jeho kategorie. V případě předaní odpadu k dalšímu využití nebo odstranění se také evidují identifikační údaje oprávněných osob, kterým byl odpad předán, v případě převzetí odpadu identifikační údaje původce nebo oprávněných osob, od nichž byl odpad přijat. Pokud se jedná o převzetí vyjmenovaných odpadů v rámci sběru a výkupu odpadů podle § 8 vyhlášky, musí povinný subjekt rovněž evidovat identifikační údaje fyzických osob, od nichž byl odpad přijat. Hlášení o produkci a nakládání s odpady: Povinné subjekty nakládající za jeden kalendářní rok s více než 50 kg nebezpečných odpadů anebo 50 tunami ostatních odpadů musí zpracovávat hlášení o roční produkci a nakládání s odpady a odevzdat ho obecnímu úřadu obce s rozšířenou působností příslušnému podle sídla povinného subjektu. Pokud povinný subjekt zahrnuje více provozoven, tak se výše uvedené množství počítá jako součet ze všech provozoven, přičemž hlášení se odevzdává za každou provozovnu zvlášť obecnímu úřadu obce s rozšířenou působností, do které provozovna spadá. Obsah hlášení je stanoven přílohou č. 20 k vyhlášce. Zvláštní pozornost je věnována provozovatelům zařízení ke sběru a zpracování autovraků, kteří zasílají hlášení společně s evidencí počtu a stavu převzatých autovraků a způsobu jejich zpracování podle příloh č. 20A a 20B k vyhlášce, a provozovatelům zařízení k oddělenému sběru, zpracování, využití a odstraňování elektroodpadu, kteří zasílají evidenci typu, množství a způsobu zpracování, využití nebo odstranění elektroodpadu.

Evidence skládek, zařízení a skladů: Provozovatelům skládek odpadů ukládá vyhláška povinnost zasílat údaje o skládce odpadů příslušnému obecnímu úřadu obce s rozšířenou působností na formuláři uvedeném v příloze č. 23 vyhlášky. Provozovatelé jiných zařízení k odstraňování, využívání, sběru nebo výkupu odpadů, a zařízení neurčených primárně k nakládání s odpady, ale využívající odpady jako vstupní suroviny, zasílají příslušnému obecnímu úřadu obce s rozšířenou působností údaje o zařízení na formuláři uvedeném v příloze č. 22. V případě shromažďovacích míst nebezpečných odpadů, sběrových

12

Kapitola 2. Legislativa míst a skladů odpadů zasílají jejich provozovatelé, tedy obce a osoby oprávněné ke sběru nebo výkupu odpadů, příslušnému obecnímu úřadu obce s rozšířenou působností údaje v rozsahu formuláře v příloze č. 24 vyhlášky. Výše uvedené údaje je třeba oznámit příslušnému úřadu nejpozději do 2 měsíců od zahájení nebo ukončení provozu daného zařízení či místa.

Přeprava nebezpečných odpadů: Má-li dojít k přepravě nebezpečných odpadů mimo areál povinného subjektu, musí vést účastníci této přepravy evidenci o přepravě nebezpečných odpadů. Evidence se vede samostatně pro každou přepravu a zahrnuje identifikační údaje odesílatele a příjemce, popis místa nakládky a vykládky, seznam přepravovaných nebezpečných odpadů (katalogové číslo, název dle katalogu nebo upřesňující název, a množství), seznam původců těchto odpadů a seznam dopravců přepravy společně s údaji zásilek a dopravních prostředků použitých v rámci jimi realizované části přepravy. Požadované údaje se zapíší na evidenční list přepravy nebezpečných odpadů, jehož vzor je uvedený v příloze č. 26 vyhlášky, přičemž každý účastník přepravy a obecní úřady obcí s rozšířenou působností v místech zahájení a ukončení přepravy obdrží po jednom průpisu přepravního listu. Jedno vyhotovení přepravního listu pošle odesílatel obecnímu úřadu obce s rozšířenou působností místa zahájení přepravy, jedno vyhotovení si nechá potvrdit dopravcem při předání a ponechá pro vlastní evidenci, a další vyhotovení odešle prostřednictvím přepravy jejímu příjemci. Dopravce si ponechá jedno vyhotovení přepravního listu potvrzené příjemcem při předání. Příjemce si po převzetí přepravy ponechá jedno vyhotovení přepravního listu pro vlastní evidenci, zbytek potvrzených přepravních listů odešle: po jednom vyhotovení obecním úřadům obcí s rozšířenou působností míst zahájení a ukončení přepravy a odesílateli přepravovaných odpadů. Při přepravě nebezpečných odpadů se tedy vyhotovuje přepravní list v sedmi průpisech.

Hlášení o plnění povinnosti zpětného odběru: Osoby, na které se vztahuje povinnost zajistit zpětný odběr některých výrobků podle § 38 zákona o odpadech, musí vést evidenci druhů a množství zpětně odebraných výrobků a nakládání s nimi. Na základě této evidence za uplynulý kalendářní rok zpracuje povinná osoba roční zprávu o plnění povinnosti zpětného odběru, která se zasílá jednou ročně na Ministerstvo životního prostředí. Zpráva obsahuje popis způsobu, jakým povinná osoba plní povinnost zpětného odběru, a pro jednotlivé zpětně odebírané výrobky popis způsobu plnění povinnosti, způsob výpočtu množství výrobků, na které se vztahuje povinnost, a rozpis množství odebraných výrobků podle původce a způsobu nakládání. Pokud se povinné osoby sdruží za účelem plnění povinnosti zpětného odběru, zpracovávají dohromady jednu zprávu o plnění povinnosti zpětného odběru, do které uvedou také úplný seznam sdružených osob. Vzorový formulář zprávy je obsažen v příloze č. 19 vyhlášky.

Plán odpadového hospodářství původce odpadů: Původci odpadů, kteří produkují ročně více než 10 t nebezpečných odpadů anebo více než 1000 t ostatních odpadů, jsou ze zákona o odpadech povinni zpracovat plán odpadového hospodářství původce odpadů (dále jen plán). Dle vyhlášky uvede původce v plánu přehled druhů a kategorií produkovaných odpadů a nakládání s nimi včetně vyhodnocení stávajícího způsobu nakládání, vyhodnocení souladu s plánem odpadového hospodářství kraje původce a plánovaný postup jeho dosažení, a to na dobu nejméně pěti následujících let. Dále musí plán obsahovat způsob organizačního zabezpečení řízení odpadového hospodářství původce včetně seznamu vnitřních dokumentů, a pokud je původce ze zákona o odpadech povinen ustanovit odpadového hospodáře, tak také jeho údaje. Vedle evidenčních a oznamovacích povinností stanoví vyhláška o podrobnostech nakládání s odpady také náležitosti žádostí o souhlas k provozování zařízení pro nakládání s odpady a o souhlas k nakládání s nebezpečnými odpady, podmínky shromažďování, soustřeďování, skladování, sběru a výkupu odpadů, technické podmínky nakládání s vybranými odpady a zabezpečení zařízení, a způsob vytváření a čerpání finanční rezervy.

13

Kapitola 2. Legislativa

Povinnosti dle zákona o statistické službě

Na základě § 27 písm. b) platného znění zákona č. 89/1995 Sb. o státní statistické službě Český statistický úřad vypracovává v součinnosti s ministerstvy a jinými správními úřady vždy nejpozději do 30. listopadu každého kalendářního roku Program statistických zjišťování na následující rok24. K únoru 2005 byla aktuální vyhláška č. 576/2004 Sb., kterou se stanoví Program statistických zjišťování na rok 2005, ze dne 8. listopadu 2004 s účinností od 1. ledna 2005. V příloze č. 1 uvedené vyhlášky je seznam statistických zjišťování prováděných Českým statistickým úřadem, kde je pod pořadovým číslem 57 uveden Roční výkaz o odpadech.

Roční výkaz o odpadech umožňuje získat od zpravodajských jednotek informace o produkci odpadů, způsobu využití a odstranění všech odpadů, se kterými bylo ve sledovaném období nakládáno, a o spotřebě odpadů jako druhotných surovin na výrobu vybraných výrobků. Zpravodajské jednotky jsou ekonomické subjekty s převažující činností zemědělskou, průmyslovou a dalších vybraných odvětví, dále subjekty s činností odstraňování odpadních vod a odpadů, čištění města, a vybrané obecní úřady. Po statistickém zpracování budou tyto informace využity pro souhrnné informování veřejnosti, mezinárodních organizací25 a pro potřeby Ministerstva životního prostředí, Ministerstva průmyslu a dalších státních orgánů. Přesný obsah ročního výkazu o odpadech definuje statistický formulář Odp 5-01, který musí zpravodajská jednota odevzdat vyplněný nejpozději do 3. března 200626 na odbor gesčního zpracování Českého statistického úřadu. Do formuláře zpravodajská jednotka vyplňuje u každého druhu vyprodukovaného či převzatého odpadu jeho katalogový kód, kategorii, původ, celkové množství a množství, se kterým bylo dále nakládáno, včetně způsobů a partnerů nakládání. Jako původ odpadu se rozlišuje produkce, převzetí, odebraní ze skladu a dovoz z ostatních zemí Evropské unie nebo z jejích nečlenských zemí. Formulář dále obsahuje přílohu pro vybrané ekonomické subjekty s ukazateli o spotřebě odpadu jako druhotných surovin na výrobu vyjmenovaných výrobků a přílohu určenou obecním úřadům, kde uvedou množství komunálního odpadu podle původu a typu sběru.

Poznámky

1. zkráceno, plné znění viz zákon č. 123/1998 Sb., dostupný např. na http://portal.gov.cz/

2. Úřad pro veřejné informační systémy vznikl dne 14. září 2000 z Úřadu pro státní informační systém na základě zákona č. 365/2000 Sb. (změny zákona č. 272/1996 Sb.) o informačních systémech veřejné správy a zanikl 1. ledna 2003, kdy jeho kompetence převzalo Ministerstvo informatiky (nově zřízené na základě zákona 517/2002 Sb.). 3. novelizován zákony č. 477/2001 Sb., č. 76/2002 Sb., č. 275/2002 Sb., č. 320/2002 Sb., č. 356/2003 Sb., č. 167/2004 Sb., č. 188/2004 Sb., č. 317/2004 Sb. a č. 7/2005 Sb. 4. viz § 1 zákona č. 185/2001 Sb. v platném znění

5. Seznam nebezpečných odpadů je definován ve vyhlášce č. 381/2001 Sb.

6. zejména odpady skupiny 20 v Katalogu odpadů definovaném ve vyhlášce č. 381/2001 Sb. a jim podobné odpady

7. zkratkou PCB se rozumějí polychlorované bifenyly, polychlorované terfenyly, monometyltetrachlordifenylmetan, monometyldichlordifenylmetan, monometyldibromdifenylmetan, a veškeré směsi obsahující jednu nebo více z uvedených látek v celkové koncentraci těchto látek vyšší než 50 mg/kg

14

Kapitola 2. Legislativa 8. podrobněji viz § 25 zákona č. 185/2001 Sb. v platném znění

9. ve znění zákona o odpadech platném k únoru 2005 se jednalo o tyto výrobky: oleje jiné než surové minerální oleje a surové oleje z živičných nerostů, přípravky jinde neuvedené ani nezahrnuté obsahující nejméně 70 % hmotnostních olejů, jsou-li tyto oleje podstatnou složkou těchto přípravků, elektrické akumulátory, galvanické články a baterie, výbojky a zářivky, pneumatiky, chladničky a mrazící zařízení a jejich kombinace, určené pro použití v domácnostech. 10. novelizován zákony č. 274/2003 Sb., č. 94/2004 Sb., č. 237/2004 Sb. a č. 257/2004 Sb.

11. viz § 1 zákona č. 477/2001 Sb. v platném znění

12. zákon o odpadech vymezuje pojem „autorizovaná obalová společnost“ a stanovuje podmínky udělení, trvání a zániku autorizace v § 16 až 29

13. česká jazyková verze směrnice v systému [EUR-Lex], http://europa.eu.int/eurlex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31990L0313:CS:HTML

14. překlad anglické jazykové verze směrnice ze systému [EUR-Lex], http://europa.eu.int/eurlex/lex/LexUriServ/LexUriServ.do?uri=CELEX:32003L0004:EN:HTML

15. definice vymezených pojmů je téměř shodná s definicemi uvedenými v části „Odpadové hospodářství v České republice“ 16. novelizována směrnicí 94/31/ES Rady evropských společenství ze dne 27. června 1994 17. Česká republika se stala členem Basilejské úmluvy 13. června 1991

18. novelizována směrnicí 2004/12/ES Evropského parlamentu a Rady evropské unie

19. definice vymezených pojmů je opět téměř shodná s definicemi uvedenými v části „Odpadové hospodářství v České republice“ 20. Eurostat je statistický úřad Evropských společenství založený v roce 1953

21. jako zástupce legislativy aktuálních problémů odpadového hospodářství uveďme například směrnici 2002/96/ES o odpadních elektrických a elektronických zařízeních ze dne 27. ledna 2003 nebo směrnici 2000/53/ES o vozidlech s ukončenou životností ze dne 18. září 2000

22. zákonem o obalech se nebudeme dále v této práci zabývat, a to ani při návrhu a implementaci informačního systému

23. zejména na 2. díl sedmé části, který se nachází ve 3. svazku publikace 24. viz platné znění § 10 zákona č. 89/1995 Sb. o státní statistické službě

25. zejména pro informování Organizace pro ekonomickou spolupráci a rozvoj (Organisation for Economic Co-operation and Development, OECD) a provádění nařízení Evropského parlamentu a Rady (ES) č. 2150/2002 o statistice odpadů ze dne 25. listopadu 2002 (viz podkapitola „Environmentální informace a odpadové hospodářství v Evropské unii“)

26. přesné datum je uvedeno ve vyhlášce stanovující Program statistických zjišťování na daný rok (pro rok 2005 je to vyhláška č. 576/2004 Sb.)

15

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému

Analýza požadavků na informační systém pro odpadové hospodářství podniku v České republice bude vycházet z platné legislativy, kterou stručně shrnuje předchozí kapitola této práce1. Následující text pojednává o analýze uvedené legislativy, tedy získání podkladů pro návrh požadovaného systému, ale také vymezení možných uživatelských požadavků, které nemusí být podloženy právními předpisy nebo jejichž legislativní původ není na první pohled zřejmý.

Pro analýzu problémové domény a pozdější návrh informačního systému budou použity prvky funkčně orientovaného přístupu klasické Yourdonovy strukturované analýzy 2 a datově orientovaný přístup konceptuálního modelování. Hranice informačního systému a události, na které má systém reagovat, zapíšeme detailně pomocí aktérů a případů užití systému. V návrhu systému bude upřesněna reakce na definované události diagramem datových toků a specifikací použitých procesů. Výsledky datově orientované části návrhu a analýzy vyjádříme na třech úrovních abstrakce jako ideální, logický a fyzický datový model, přičemž uvedené modely budou zapsány pomocí notace jazyka UML 3.

Požadavky

Informační systém pro odpadové hospodářství podniku umožní sběr, evidenci a zhodnocení informací v oblasti nakládání s odpady v rámci podniku. Požadavky na systém vycházejí především ze zákona č. 185/2001 Sb., prováděcí vyhlášky č. 383/2001 Sb. a ostatních, a zákona č. 89/1995 Sb. a jeho prováděcí vyhlášky stanovující Program statistických zjišťování. Další potřeby jsou důsledkem provázanosti jednotlivých legislativních požadavků a kontroly zodpovědností. Analýzou požadavků byly stanoveny následující uživatelské role a jejich potřeby: Administrátor:

Uživatel systému v roli administrátora je zodpovědný za zabezpečení správné funkce systému a jeho bezpečnost. Systém musí administrátorovi poskytnout prostředky pro provádění bezpečnostní politiky systému, její součinnosti s bezpečnostní politikou organizace, a pro udržování podpůrných systémových dat ve stavu, který odpovídá reálnému světu. Z hlediska bezpečnostní politiky je to zejména správa uživatelských účtů, oprávnění uživatelů v souvislosti s jejich rolemi, bezpečnost komunikační sítě systému (její zabezpečení proti odposlechu a narušení) a zálohování kritických dat systému. Udržování aktuálnosti podpůrných systémových dat (číselníků) je nezbytné, především pokud jsou tato data definována legislativně4.

Správce subjektů:

Role správce subjektů umožní uživateli udržovat údaje subjektů u nichž je vedena evidence odpadového hospodářství, osob zodpovědných za jednotlivé druhy výkazů evidence těchto subjektů a partnerů nakládání s odpady, nebo ostatních subjektů vstupujících do nějakého vztahu při evidenci odpadového hospodářství. V některých případech může být účelné udělit právo vstoupit do této role uživatelům s rolemi operátora odpadu (přidává partnery nakládání s odpady), operátora zpětného odběru (přidává partnery nakládání se zpětně odebranými výrobky), operátora přepravy

16

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému (přidává dopravce přepravy nebezpečných odpadů, případně původce přepravovaných odpadů), správce zařízení (přidává majitele zařízení) či správce identifikačních listů nebezpečných odpadů.

Operátor evidence odpadů:

V této roli uživatel eviduje dávky odpadů, se kterými je nakládáno, přičemž evidence zahrnuje údaje průběžné evidence v souladu s § 21 vyhlášky č. 383/2001 Sb. (viz část podkapitoly „Povinnosti dle zákona o odpadech“ v 2). U evidovaných dávek odpadů systém musí ověřovat platné povolení původce i partnerského subjektu nakládání (důležité zejména pro nakládání s nebezpečným odpadem). Systém dále bude operátorovi evidence odpadu poskytovat nástroje pro bilance nakládání s odpady podle druhu odpadu a druhu nakládání a nástroje pro korekci této bilance (tj. hromadné nakládání s přebytky5). Na konci kalendářního roku systém umožní uložit přebytky odpadů jako zůstatky z minulého roku a převést je do evidence odpadů v navazujícím roce.

Správce povolení odpadů:

Uživatel systému v této roli může spravovat evidenci povolení k nakládání s odpady, která se využije při vlastní evidenci odpadů. Do systému budou zanesena povolení udělená subjektům, u kterých je vedena evidence odpadů, a partnerům nakládání s odpady. Povolení mohou mít časově omezenou platnost a mohou (ale nemusí, např. u vnitropodnikových omezení nakládání s odpady) mít návaznost na osvědčení o vyloučení nebezpečných vlastností odpadu dle § 9 nebo oprávnění k převzetí odpadu dle § 12 odstavce d.) zákona č. 185/2001 Sb.

Operátor zpětného odběru:

Role operátora zpětného odběru bude opravňovat uživatele systému k evidenci zpětných odběrů některých výrobků v souladu s § 38 zákona č. 185/2001 Sb. Mezi evidované údaje bude patřit také původ zpětně odebraných výrobků a způsob nakládání s nimi.

Operátor přepravy nebezpečných odpadů:

Uživatel v roli operátora přepravy nebezpečných odpadů bude evidovat přepravu a přepravní listy nebezpečných odpadů podle § 24 zákona č. 185/2001 Sb. a § 25 vyhlášky č. 383/2001 Sb. Systém umožní vazbu přepravy nebezpečných odpadů na subjekty dopravců přepravy či původců přepravovaných odpadů.

Správce zařízení k nakládání s odpady:

Tato role umožní uživateli vést evidenci zařízení a údajů nezbytných pro ohlašování zařízení k nakládání s odpady v souladu s § 23 vyhlášky č. 383/2001 Sb. Evidované zařízení může být dále použito pro upřesnění vlastního nakládání s odpadem v evidenci odpadů se smyslem „s danou dávkou odpadu bylo nakládáno v daném zařízení“.

Správce identifikačních listů nebezpečných odpadů:

Uživatel systému v roli správce identifikačních listů nebezpečných odpadů bude oprávněn vést evidenci uvedených identifikačních listů za účelem naplnění § 5 odstavce 4 a § 7 odstavce 3 vyhlášky č. 383/2001 Sb. v souladu s přílohou č. 3 stejnojmenné vyhlášky. Systém umožní navázat identifikační listy na subjekty v rolích původce odpadu nebo oprávněné osoby a na subjekty zodpovědné za správnost údajů uvedených v identifikačním listu. Evidované identifikační listy rovněž poslouží pro upřesnění druhu nebezpečných odpadů, s nimiž je nakládáno.

17

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému Odběratel výkazů:

Tato role bude uživatele opravňovat k získání vyplněných formulářů hlášení evidence odpadového hospodářství subjektů. Hlášení budou vyplněna na základě aktuálního stavu evidence a budou použitelná k odevzdání na příslušné úřady v souladu se zákonem o odpadech, zákonem o statistické službě a jejich prováděcími vyhláškami. Jedná se především o následující výkazy: Hlášení o produkci a nakládání s odpady (příloha č. 20 vyhlášky č. 383/2001 Sb.), výpis průběžné evidence produkce a nakládání s odpady (podle § 21 vyhlášky č. 383/2001 Sb.), Roční výkaz o odpadech Odp 5-01 (podle platného Programu statistických zjišťování Českého statistického úřadu), Roční zpráva o plnění povinnosti zpětného odběru (příloha č. 19 vyhlášky č. 383/2001 Sb.), Zařízení na využívání a odstraňování odpadů (příloha č. 22 vyhlášky č. 383/2001 Sb.), Skládky odpadů (příloha č. 23 vyhlášky č. 383/2001 Sb.), Shromažďovací místa nebezpečných odpadů a sběrová místa a sklady odpadů (příloha č. 24 vyhlášky č. 383/2001 Sb.), Evidenční list pro přepravu nebezpečných odpadů pro území ČR (příloha č. 26 vyhlášky č. 383/2001 Sb.), Dopravce odpadů (příloha č. 27 vyhlášky č. 383/2001 Sb.) a identifikační list nebezpečných odpadů (podle přílohy č. 3 vyhlášky č. 383/2001 Sb.).

Potřeby výše uvedených rolí se mohou mírně překrývat v závislosti na konkrétním nasazení systému. V případech podniků s jednoduchou evidencí odpadového hospodářství může zastávat všechny role jeden uživatel systému (většinou u podniků, které nejsou ze zákona povinny stanovit odpadového hospodáře nebo podávat roční hlášení o produkci a nakládání s odpady).

Případy užití

Nyní podrobněji rozepíšeme jednotlivé případy užití navrhovaného informačního systému podle požadavků z předchozí podkapitoly. Navíc bude nutné přidat některé další případy užití související např. s bezpečností systému (přihlášení uživatele, atd.). Navržené případy užití budou později využity při návrhu diagramu datových toků a při testování. Pojmem „evidence“ určitých objektů bude dále rozuměno přidávání nebo odebírání záznamů o takových objektech a modifikace jejich vlastností. Někteří aktéři, jako je například inspekce životního prostředí, obec s rozšířenou působností nebo partner nakládání, nejsou v přímém kontaktu se systémem, a proto je následující výpis neuvádí (působí pouze mimo hranice systému, většinou přes některé z níže uvedených aktérů).

Aktér Uživatel

Aktér Uživatel reprezentuje roli uživatele systému před jeho autorizací a obecnou roli autorizovaného uživatele pracujícího se systémem. Pro zjednodušení případů užití definujme aktéra Uživatel, jako společného předka všech následujících aktérů (ostatní aktéři tedy vzniknou specializací aktéra Uživatel při přihlášení uživatele).

přihlášení uživatele

předpoklady: uživatel není dosud přihlášen do systému; cíle: přihlášení uživatele do systému, specializace aktéra podle jeho autorizace; postup: uživatel otevře dialog přihlášení do systému, vyplní přihlašovací informace (svůj login, heslo) a potvrzením je odešle k ověření systémem (autentizace), pokud systém odmítl přihlásit uživatele, uživatel zareaguje na systémem vygenerované chybové hlášení.

18

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému

odhlášení uživatele

předpoklady: uživatel je přihlášen do systému; cíle: odhlášení uživatele ze systému; postup: uživatel zvolí akci odhlášení ze systému, pokud existují neuložená data editovaná uživatelem, potvrdí uživatel jejich uložení či stornování změn.

Aktér Administrátor

Aktér Administrátor reprezentuje roli uživatele zodpovědného za prosazování bezpečnostní politiky systému a jeho údržbu.

evidence uživatelů

předpoklady: (nejsou)6; cíle: přidání, odebrání uživatele nebo změna jeho údajů; postup: administrátor zvolí akci přidání uživatele a zadá jeho údaje (login, heslo, atd.), nebo vybere uživatele a zvolí akci odebrat uživatele nebo upravit údaje uživatele (login, heslo, atd.).

změna oprávnění uživatele

předpoklady: (nejsou); cíle: změna rozsahu oprávnění uživatele systému; postup: administrátor vybere existujícího uživatele a přidělí mu či odebere oprávnění k provádění daných akcí (přidá či odebere role, které může zastávat vybraný uživatel).

zálohování kritických dat systému

předpoklady: systém je naplněn uživatelskými daty; cíle: vytvoření souboru se zálohou všech uživatelských dat přítomných v okamžiku zálohy; postup: administrátor zvolí akci záloha dat a obdrží soubor s požadovanou zálohou.

údržba číselníků

předpoklady: (nejsou); cíle: aktuální údaje v části číselníku obsahující předtím neplatné údaje; postup: administrátor vybere číselník obsažený v systému, zvolí akci importovat aktuální data a zvolí soubor s aktualizací dat číselníku, nebo vybere neaktuální položky číselníku a smaže je nebo opraví zadáním aktuálních údajů.

Aktér Správce subjektů

Role uživatele reprezentovaná aktérem Správce subjektů eviduje subjekty, které se účastní odpadového hospodářství podniku, a jejich zodpovědné osoby.

evidence subjektů

předpoklady: (nejsou); cíle: přidání, odebrání subjektu nebo změna jeho údajů;

19

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému postup: správce subjektů zvolí akci přidání subjektu a zadá jeho údaje (jméno, adresu, atd.), nebo vybere subjekt a zvolí akci odebrat subjekt nebo upravit údaje subjektu (jméno, adresu, zodpovědné osoby, atd.).

evidence osob

předpoklady: existuje nejméně jeden subjekt; cíle: přidání, odebrání osoby nebo změna jejích údajů; postup: správce subjektů zvolí akci přidání osoby a zadá její údaje (jméno, adresu, atd.) včetně povinné příslušnosti k nějakému subjektu, nebo vybere osobu a zvolí akci odebrat osobu nebo upravit údaje osoby (jméno, adresu, příslušnost k subjektu, atd.).

Aktér Operátor evidence odpadů

Aktér Operátor evidence odpadů reprezentuje roli uživatele vedoucího evidenci dávek odpadů a nakládání s nimi.

evidence odpadů

předpoklady: existuje nejméně jedno povolení odpadu (volitelně 7), v případě určení partnera nakládání nejméně jeden subjekt jiný od vlastníka povolení; cíle: přidání, odebrání dávky odpadu nebo změna jejích údajů; postup: operátor evidence odpadů zvolí akci přidání dávky odpadu a zadá její údaje (povolení odpadu nebo přesný druh odpadu, druh nakládání, množství, atd.), nebo vybere dávku odpadu a zvolí akci odebrat dávku odpadu nebo upravit údaje dávky odpadu (povolení odpadu, druh nakládání, množství, atd.).

kontrola bilance odpadu

předpoklady: existuje nejméně jedna dávka odpadu; cíle: poskytnutí informace o zůstatku množství odpadu dle druhu odpadu a nakládání; postup: operátor evidence odpadu zvolí akci kontrola bilance odpadu.

korekce bilance odpadu

předpoklady: existuje nejméně jedna dávka odpadu, nejméně jeden druh odpadu a nakládání má nenulovou bilanci; cíle: nulová bilance vybraného druhu odpadu a nakládání; postup: operátor evidence odpadu zvolí druh odpadu a nakládání, které mají nenulovou bilanci, dále zvolí způsob korekce bilance (tj. nakládání, kterým se má přebytek množství odpadu vyrovnat) a zvolí akci dorovnat bilanci odpadu.

převod uskladněných odpadů do následujícího roku

předpoklady: existuje nejméně jedna dávka odpadu se způsobem nakládání „zůstatek na skladu k 31.12. běžného roku“; cíle: nová dávka odpadu k 1.1. následujícího roku stejného druhu jako uskladněné množství odpadu v běžném roce s nakládáním „zůstatek z minulého roku“; postup: operátor evidence odpadu zvolí akci převod zůstatků odpadů do dalšího roku a vybere rozsah převodu (subjekt, celá firma subjektu nebo všechny subjekty).

20

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému

Aktér Správce povolení odpadů

Uživatel v roli reprezentované aktérem Správce povolení odpadů eviduje povolení odpadů, se kterými je nakládáno. Zejména kontroluje oprávnění partnerů nakládání a zavádí tato oprávnění do systému.

evidence povolení odpadů

předpoklady: existuje nejméně jeden subjekt; cíle: přidání, odebrání povolení odpadu nebo změna jeho údajů; postup: správce povolení odpadů zvolí akci přidání povolení odpadu a zadá jeho údaje (druh povolovaného odpadu, časová platnost, atd.) včetně příslušnosti k subjektu, nebo vybere povolení odpadu a zvolí akci odebrat povolení odpadu nebo upravit údaje povolení odpadu (druh povolovaného odpadu, časová platnost, subjekt vlastnící povolení, atd.).

Aktér Operátor zpětného odběru

Aktér Operátor zpětného odběru reprezentuje roli uživatele, který vede evidenci zpětného odběru některých výrobků v souladu se zákonem o odpadech.

evidence zpětného odběru

předpoklady: existuje nejméně jeden subjekt; cíle: přidání, odebrání příjmu či výdeje výrobků zpětného odběru nebo změna jejich údajů; postup: operátor zpětného odběru zvolí akci přidání příjmu či výdeje výrobků zpětného odběru a zadá jejich údaje (druh výrobku, původce při příjmu, způsob nakládání při výdeji, množství, atd.) včetně příslušnosti k subjektu provádějícímu zpětný odběr, nebo vybere příjem či výdej zpětného odběru a zvolí akci smazat zpětný odběr nebo upravit údaje zpětného odběru (druh odebraného výrobku, množství, subjekt nově vlastnící odebraný výrobek, atd.).

kontrola bilance zpětného odběru

předpoklady: existuje nejméně jeden příjem či výdej zpětně odebíraných výrobků; cíle: poskytnutí informace o rozdílu množství mezi příjmem a výdejem výrobků podléhajících zpětnému odběru dle druhu výrobku; postup: operátor zpětného odběru zvolí akci kontrola bilance zpětného odběru.

korekce bilance zpětného odběru

předpoklady: existuje nejméně jeden příjem či výdej zpětně odebíraných výrobků a rozdíl mezi přijatými a vydanými výrobky zpětného odběru je nenulový; cíle: nulový rozdíl mezi množstvím přijatých a vydaných výrobků daného druhu; postup: operátor zpětného odběru zvolí druh výrobků podléhajících zpětnému odběru, který má nenulovou bilanci, dále zvolí způsob korekce bilance (tj. údaje původu přijatých výrobků, způsobu nakládání s vydanými výrobky a subjektu partnera, kterými se má množství zpětně odebraných výrobků daného druhu vyrovnat) a zvolí akci dorovnat bilanci zpětného odběru.

Aktér Operátor přepravy nebezpečných odpadů

Uživatel v roli reprezentované aktérem Operátor přepravy nebezpečných odpadů vede evidenci přepravních listů nebezpečných odpadů daného subjektu.

21

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému

evidence přepravy nebezpečných odpadů

předpoklady: existují nejméně dva subjekty (odesílatel a příjemce); cíle: přidání, odebrání přepravního listu nebo změna jeho údajů; postup: operátor přepravy nebezpečných odpadů zvolí akci přidání přepravního listu a zadá jeho údaje (místo nakládky, vykládky, přepravované odpady, atd.) včetně subjektu vlastnícího přepravní list a subjektů odesílatele, příjemce a dopravců, nebo vybere přepravní list a zvolí akci odebrat přepravní list nebo upravit údaje přepravního listu (zúčastněné subjekty, časy předání mezi zúčastněnými subjekty, údaje přepravy, atd.).

Aktér Správce zařízení k nakládání s odpady

Role reprezentovaná aktérem Správce zařízení k nakládání s odpady opravňuje uživatele k evidenci zařízení k nakládání s odpady (dále zařízení) podle příloh č. 22, 23 a 24 vyhlášky č. 383/2001 Sb.

evidence zařízení k nakládání s odpady

předpoklady: existuje nejméně jeden subjekt; cíle: přidání, odebrání zařízení nebo změna jeho údajů; postup: správce zařízení zvolí akci přidání zařízení a zadá jeho údaje (id. kód, druh, umístění, atd.) včetně subjektů provozovatele a majitele, nebo vybere zařízení a zvolí akci odebrat zařízení nebo upravit údaje zařízení (provozní údaje, povolené odpady, zúčastněné subjekty, atd.).

Aktér Správce identifikačních listů nebezpečných odpadů

Aktér Správce identifikačních listů nebezpečných odpadů reprezentuje roli uživatele evidujícího identifikační listy nebezpečných odpadů (dále jen id. listy) v souladu se zákonem o odpadech a jeho prováděcími vyhláškami.

evidence identifikačních listů nebezpečných odpadů

předpoklady: existuje nejméně jeden subjekt; cíle: přidání, odebrání id. listu nebo změna jeho údajů; postup: správce id. listů zvolí akci přidání id. listu a zadá jeho údaje (druh odpadu, nebezpečnost, ochrana zdraví při manipulaci, atd.) včetně příslušnosti k subjektu a subjektu zodpovědného za správnost, nebo vybere id. list a zvolí akci odebrat id. list nebo upravit údaje id. listu (původce, vlastnosti a bezpečnostní opatření, atd.).

Aktér Odběratel výkazů

Uživatel v roli reprezentované aktérem Odběratel výkazů získává ze systému informace v podobě vyplněných hlášení v zákonem stanovené formě a rozsahu. Jedná se především o hlášení podle příloh 3, 19 až 24, 26 a 27 vyhlášky č. 383/2001 Sb. a formuláře Odp 5-01 prováděcí vyhlášky zákona o statistické službě (dále je požadované výkazy).

získání vyplněného výkazu

předpoklady: existují data požadovaná výkazem; cíle: vyplněný výkaz ve formátu vhodném pro tisk;

22

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému postup: odběratel výkazů vybere subjekt, za který chce získat výkaz, dále zvolí akci tisk hlášení a vybere druh požadovaného výkazu.

Ideální datový model

Z předchozí podkapitoly máme definovány potřeby uživatelů informačního systému. Ideálním datovým modelem vymezíme informační schopnost ideální podoby informačního systému vyhovujícího definovaným požadavkům. Model umožní vyjádřit seznam všech otázek, které mají pro uživatele smysl a na které bude odpovídat navrhovaný informační systém. Dále model sjednotí pojmy zavedené v oblasti odpadového hospodářství podniku a nastaví jejich jednotné vnímání. Z hlediska vývoje informačního systému představuje ideální datový model nejvyšší stupeň abstrakce řešení daného problému, proto nepostihuje konkrétní detaily formy jednotlivých informací8. Z výše uvedeného důvodu je tento model během vývoje informačního systému nejstabilnější a poskytuje pevný základ pro pozdější doplňování požadavků na informační schopnost systému. Obrázek 3-1. diagram ideálního datového modelu

Realizaci ideálního datového modelu odpadového hospodářství podniku popisuje diagram 9 na obrázku 3-1 a přesná sémantika v něm zobrazených objektů (entit) a vazeb (souvislostí) mezi nimi.

Objekty ideálního datového modelu dopravcePrepravyNO (slabý)

Objektem typu (#dopravcePrepravyNO) je každá dílčí doprava realizovaná v rámci dané přepravy neb. odp. (#prepravaNO), včetně údajů použitých dopravních prostředků a zásilky. idListNO

(kernel)

Objektem typu (#idListNO) je každý identifikační list nebezpečného odpadu ve smyslu příl. č. 3 k vyhl. č. 383/2001 Sb. v evidenci odpadového hospodářství podniku. obcanBezIC (podtyp)

Objektem typu (#obcanBezIC) je každá fyzická osoba bez přiděleného i. č., která vstupuje do evidence odpadového hospodářství podniku. odpad

(kernel)

Objektem typu (#odpad) je každá dávka odpadu, se kterou bylo nakládáno v evidenci odpadového hospodářství podniku.

odpadPrepravyNO (slabý)

23

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému Objektem typu (#odpadPrepravyNO) je každá dávka odpadu přepravovaná v rámci dané přepravy neb. odp. (#prepravaNO). osoba

(kernel)

Objektem typu osoba (#osoba) je každá osoba zaměstnance subjektu evidovaného v odpadovém hospodářství podniku, která je důležitá z hlediska odpadového hospodářství. Např. odpadový hospodář, zaměstnanec zodpovědný za roční hlášení o nakládání s odpady, atd. povoleni

(kernel)

Objektem typu (#povoleni) je každé povolení k nakládání s odpadem, ať už vnitropodnikové (např. na ostatní odpad) či úřední (na nebezpečný odpad) v evidenci odpadového hospodářství podniku.

povolenyOdpad (slabý)

Objektem typu (#povolenyOdpad) je každý druh povoleného odpadu, který smí být zpracováván, skladován či odstraněn v daném zařízení (#zarizeni). prepravaNO (kernel)

Objektem typu (#prepravaNO) je každá přeprava nebezpečných odpadů od odesílatele k příjemci realizovaná mimo areál podniku dle příl. č. 26 vyhl. č. 383/2001 Sb. v evidenci odpadového hospodářství podniku.

provozovna (podtyp)

Objektem typu (#provozovna) je každá provozovna firmy či obce, která není shodná se sídlem stejné firmy či obce a která vstupuje do evidence odpadového hospodářství podniku. sidloFirmy

(podtyp)

Objektem typu (#sidloFirmy) je každá firma, resp. její sídlo, která vstupuje do evidence odpadového hospodářství podniku. sidloObce

(podtyp)

Objektem typu (#sidloObce) je každá obec, resp. její sídlo, která vstupuje do evidence odpadového hospodářství podniku. subjekt

(kernel, abstraktní typ)

Objektem typu (#subjekt) je každý subjekt vstupující do evidence odpadového hospodářství podniku.

24

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému zarizeni

(kernel, abstraktní typ)

Objektem typu (#zarizeni) je každé evidované zařízení na zpracování, skladování či odstraňování odpadu v odpadovém hospodářství podniku. zarizeniSklad (podtyp)

Objektem typu (#zarizeniSklad) je každý sklad, který je využíván jako shromažďovací místo neb. odp., sběrové místo anebo sklad odpadů ve smyslu příl. č. 24 vyhl. č. 383/2001 Sb. v evidenci odpadového hospodářství podniku. zarizeniSkladka (podtyp)

Objektem typu (#zarizeniSkladka) je každá skládka odpadů ve smyslu příl. č. 23 vyhl. č. 383/2001 Sb. v evidenci odpadového hospodářství podniku. zarizeniZarizeni (podtyp)

Objektem typu (#zarizeniZarizeni) je každé zařízení na využívání a odstraňování odpadu ve smyslu příl. č. 22 vyhl. č. 383/2001 Sb. v evidenci odpadového hospodářství podniku. zpetnyOdberPrijem (kernel)

Objektem typu (#zpetnyOdberPrijem) je každý uskutečněný zpětný odběr výrobků podléhajících dle zákona zpětnému odběru v evidenci odpadového hospodářství podniku.

zpetnyOdberVydej (kernel)

Objektem typu (#zpetnyOdberVydej) je každé uskutečněné předání zpětně odebraných výrobků podléhajících dle zákona zpětnému odběru osobě oprávněné k jejich využití nebo odstranění, které je evidované v odpadovém hospodářství podniku.

Vazby ideálního datového modelu 01:

02:

Subjekt (#subjekt), kterému patří dané povolení k nakládání s odpadem (#povoleni). / 1,1:0,M

Povolení k nakládání s odpadem (#povoleni), které opravňuje k nakládání s danou dávkou odpadu (#odpad). / 1,1:0,M

25

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému 03:

Subjekt (#subjekt), který je partnerem při nakládání s danou dávkou odpadu (#odpad). / 0,1:0,M

04:

05:

Subjekt (#subjekt), který provozuje dané zařízení ke zpracování, odstraňování či skladování odpadu (#zarizeni). / 1,1:0,M

Subjekt (#subjekt), který vlastní dané zařízení ke zpracování, odstraňování či skladování odpadu (#zarizeni). / 1,1:0,M

06:

Zařízení ke zpracování, odstraňování či skladování odpadu (#zarizeni), které zpracovalo danou dávku odpadu (#odpad). / 0,1:0,M

07:

Druhy odpadů (#povolenyOdpad)-s povolené zpracovávat v daném zařízení ke zpracování, odstraňování či skladování odpadu (#zarizeni). / 0,M:1,1

08a:

Sídlo firmy (#sidloFirmy), ke které patří daná provozovna (#provozovna).10 / 1,1:0,M

08b:

Sídlo obce (#sidloObce), ke které patří daná provozovna (#provozovna). / 1,1:0,M

09:

Subjekt (#sidloFirmy), ve kterém vykonává daná osoba (#osoba) nějakou roli11.

/ 0,1:0,M 10:

Integritní omezení: U daného subjektu smí vykonávat danou roli nejvýše jedna osoba. Subjekt (#subjekt), který předal dané zpětně odebrané výrobky (#zpetnyOdberVydej). / 1,1:0,M

11:

Subjekt (#subjekt), kterému byly předány dané zpětně odebrané výrobky (#zpetnyOdberVydej).

26

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému / 1,1:0,M 12:

Subjekt (#subjekt), který je odesílatelem v dané přepravě nebezpečných odpadů (#prepravaNO). / 1,1:0,M

13:

Subjekt (#subjekt), který je příjemcem v dané přepravě neb. odp. (#prepravaNO). / 1,1:0,M

14:

15:

Subjekt (#subjekt), který provádí danou dopravu neb. odp.12 (#dopravcePrepravyNO). / 1,1:0,M

Subjekty (#subjekt)-s, které jsou původci dané dávky přepravovaného neb. odp. (#odpadPrepravyNO). / 0,N:0,M

16:

Identifikační list neb. odp. (#idListNO), který upřesňuje údaje o druhu povoleného odpadu v zařízení (#povolenyOdpad). / 0,1:0,M

17:

Pozn.: Vazbu je možné vytvořit a udržovat pouze upřesňuje-li nebezpečný odpad a shoduje-li se druh upřesněného odpadu s druhem uvedeným na identifikačním listu. Identifikační list neb. odp. (#idListNO), který upřesňuje údaje o druhu odpadu v povolení (#povoleni). / 0,1:0,M

18:

Pozn.: Vazbu je možné vytvořit a udržovat pouze upřesňuje-li nebezpečný odpad a shoduje-li se druh upřesněného odpadu s druhem uvedeným na identifikačním listu. Identifikační list neb. odp. (#idListNO), který upřesňuje údaje o druhu přepravované dávky neb. odp. (#odpadPrepravyNO). / 0,1:0,M

Pozn.: Vazbu je možné vytvořit a udržovat pouze upřesňuje-li nebezpečný odpad a shoduje-li se druh upřesněného odpadu s druhem uvedeným na identifikačním listu. 19:

Subjekt (#subjekt), do jehož evidence patří daná přeprava neb. odp. (#prepravaNO). / 1,1:0,M

27

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému 20:

Subjekt (#subjekt), který provedl daný zpětný odběr (#zpetnyOdberPrijem). / 1,1:0,M

21:

Subjekt (#subjekt), od kterého byly zpětně odebrány výrobky v daném zpětném odběru (#zpetnyOdberPrijem). / 0,1:0,M

Pozn.: Pokud není subjekt určen touto vazbou, musí být určena aspoň jeho kategorie (obec, průmysl či obchod) v atributu objektu (#zpetnyOdberPrijem). 22:

23:

Osoby (#osoba)-s důležité z hlediska evidence odpadového hospodářství daného subjektu (#subjekt). / 0,M:1,1

Dávky odpadů (#odpadPrepravyNO)-s přepravované v rámci dané přepravy neb. odp. (#prepravaNO). / 1,M:1,1

Pozn.: V rámci jedné přepravy smí být evidovány pouze dávky odpadů různých druhů (odpady stejného druhu jsou za účelem přepravy sloučeny do jedné dávky). 24:

25:

Dílčí dopravy (#dopravcePrepravyNO)-s realizované v rámci dané přepravy neb. odp. (#prepravaNO). / 1,M:1,1

Subjekt (#subjekt), který eviduje daný identifikační list neb. odp. (#idListNO). / 1,1:0,M

26:

Subjekt (#subjekt), který je původcem nebo oprávněnou osobou odpadu na daném identifikačním listu neb. odp. (#idListNO). / 0,1:0,M

Poznámky

1. konkrétně z povinností podniku daných zákonem o odpadech, zákonem o statistické službě a jejich prováděcími vyhláškami (viz podkapitola „Odpadové hospodářství z pohledu podniku v České republice“ v 2)

28

Kapitola 3. Analýza požadavků a předběžný návrh informačního systému 2. Yourdon Structured Method (YSM); volba strukturované analýzy umožní v závěrečné fázi návrhu jednoduše přenést aplikační rozhraní do prostředí databázového serveru (viz podkapitola „Architektura systému“ v 5)

3. Unified Modeling Language (UML); konkrétně bude použita zavedená notace diagramu tříd, která umožní standardizovaný zápis vztahů „is a“ hierarchie, existenčních závislostí, atd.

4. může se jednat například o Katalog odpadů (vyhláška č. 381/2001 Sb.), klasifikaci územních statistických jednotek (opatření Českého statistického úřadu k CZ-NUTS), údaje správních obvodů obcí s rozšířenou působností (zákon č. 314/2002 Sb.), atd. 5. pokud nastane opačná situace, tedy záporná bilance odpadu, jedná se o chybu evidence (v tom případě by bylo předaného nebo odstraněného odpadu více než odpadu vyprodukovaného či přijatého)

6. v tomto i v následujících případech užití v celé podkapitole existuje implicitní předpoklad přihlášení uživatele, který je zahrnut ve specializaci obecného aktéra Uživatel na ostatní aktéry

7. pokud není vybráno povolení odpadu a je určen přesně druh odpadu a příslušnost k subjektu, lze automaticky vytvořit povolení a přiřadit mu vzniklou dávku odpadu

8. ideální model tedy nezahrnuje např. číselníky, mezi které může patřit Katalog odpadů, Seznam nebezpečných vlastností odpadu dle Basilejské úmluvy, atd.

9. v diagramu datového modelu je použita notace diagramu tříd z UML

10. vazby 08a a 08b jsou vzájemně výlučné, pro každou provozovnu musí existovat právě jedna vazba typu 08

11. role bude určena druhem vazby – viz podkapitola „Logický datový model“ v 4

12. tzn. subjekt je dopravcem přepravy nebezpečných odpadů

29

Kapitola 4. Návrh informačního systému

V předchozí kapitole jsme analyzovali požadavky a provedli předběžný návrh informačního systému pro odpadové hospodářství podniku dle platné legislativy a požadavků vymezených skupin uživatelů systému. Následující text bude navazovat upřesněním datového modelu a popisem dynamického chování systému.

Logický datový model

Logický datový model navazuje na ideální datový model navržený v podkapitole „Ideální datový model“ v 3. Důsledněji se zaměřuje na zájmovou oblast řízenou informačním systémem, zejména definuje vlastnosti objektů a vazeb, a také formu zpracovávaných informací1. Avšak stejně jako ideální datový model, je i logický datový model nezávislý na technologiích, pomocí kterých bude navrhovaný systém implementován 2. Logický datový model informačního systému pro podporu odpadového hospodářství podniku zobrazuje diagram na obrázku 4-1. Z důvodů přehlednosti neobsahuje diagram objekty číselníků. Chybějící číselníky a všechny atributy s jejich typovým určením budou popsány v následujícím textu podkapitoly.

Význam objektů, resp. vazeb, v logickém datovém modelu je shodný s významem definovaným v sekci „Objekty ideálního datového modelu“ v 3, resp. „Vazby ideálního datového modelu“ v 3. Kromě dříve vymezených objektů přibyly v datovém modelu následující objekty s danou sémantikou: zodpOsoby

(vazební)

Objektem typu (zodpOsoby) je každá reprezentace vazby mezi osobou (#osoba) a subjektem (#subjekt) se smyslem:

Druh zodpovědnosti (kodDruhu) dané osoby (#osoba) v odpadovém hospodářství daného subjektu (#subjekt). / 0,N:0,M

skupSkladky (slabý)

Objektem typu (#skupSkladky) je každá skupina podle technického zabezpečení dané skládky (#zarizeniSkladka) ve smyslu § 11 odst. 5 vyhlášky 383/2001 Sb.

Vznikla také nová vazba s významem: 27:

Skupiny (#skupSkladky)-s dané skládky (#zarizeniSkladka). / 1,M:1,1

Obrázek 4-1. diagram logického datového modelu (bez číselníků)

30

Kapitola 4. Návrh informačního systému

Datové typy

Následující výčet udává sémantiku datových typů použitých v definicích atributů objektů logického datového modelu: adrCislo:

Prvkem typu (adrCislo) je každé nejvýše čtyřmístné číslo představující identifikační číslo dle odstavce 5 bodu 2002 přílohy A sdělení 159/1997 Sb. o přijetí změn příloh dohody ADR.

adrObalSk:

Prvkem typu (adrObalSk) je každý nejvýše osmimístný textový řetězec představující kód obalové skupiny dle bodu 2302 přílohy A sdělení 159/1997 Sb.

adrTrida:

Prvkem typu (adrTrida) je každý textový řetězec formátu N nebo N.M, kde N a M jsou číslice, představující třídu dle odstavce 5 bodu 2002 přílohy A sdělení 159/1997 Sb.

bool:

Prvkem typu (bool) je každá pravdivostní hodnota, tj. ANO nebo NE.

casovaZnamka:

Prvkem typu (casovaZnamka) je každý řetězec číslic, který má formát DDMMRRRRHHMM, kde DD.MM.RRRR je platné datum a HH:MM platný čas.

datum:

Prvkem typu (datum) je každý řetězec číslic, který má formát DDMMRRRR, kde DD.MM.RRRR je platné datum.

dic:

Prvkem typu (dic) je každý textový řetězec formátu daňového identifikačního čísla podle § 33 odst. 12 platného znění zákona č. 337/1992 Sb. o správě daní a poplatků.

druhDopravce:

Prvkem typu (druhDopravce) je každá celočíselná hodnota od čísla 1 do čísla 5, představující druh přepravy: 1 – silniční, 2 – železniční, 3 – vodní, 4 – letecká a 5 – kombinovaná přeprava.

ico:

ID:

Prvkem typu (ico) je každý řetězec osmi číslic, představující možné identifikační číslo dle § 21 platného znění zákona č. 89/1995 Sb. o státní statistické službě, korektní dle metody „add modulo“3. Prvkem typu (ID) je každý prvek z množiny identifikátorů jedinečný v dané třídě objektů (například z posloupnosti celých čísel o délce 8 bytů).

iKodZarizeni:

Prvkem typu (iKodZarizeni) je každé desetimístné číslo formátu identifikačního kódu zařízení popsaného v přílohách č. 22 až 24 platného znění vyhlášky č. 383/2001.

31

Kapitola 4. Návrh informačního systému kategorieOdpadu:

Prvkem typu (kategorieOdpadu) je znak „O“ (s významem „ostatní odpad“) nebo znak „N“ (s významem „nebezpečný odpad“).

penize:

Prvkem typu (penize) je každé číslo z množiny reálných čísel s přesností na dvě desetinná místa reprezentující peněžní částku v Kč.

prirozeneCislo:

Prvkem typu (prirozeneCislo) je každé číslo z množiny přirozených čísel.

psc:

Prvkem typu (psc) je každá pětice číslic bez mezer formátu poštovního směrovacího čísla dle § 5 platného znění vyhlášky 286/2004 Sb. o základních službách držitele poštovní licence a normy ČSN ISO 11180 Poštovní adresování.

realneCisloKladne:

Prvkem typu (realneCisloKladne) je každé číslo z množiny kladných reálných čísel (tj. bez čísla 0).

realneCisloNezaporne:

Prvkem typu (realneCisloNezaporne) je každé číslo z množiny nezáporných reálných čísel.

regZnacka:

rc:

rok:

Prvkem typu (regZnacka) je každý textový řetězec formátu registrační značky vozidla dle § 2 platného znění vyhlášky č. 243/2001 Sb. o registraci vozidel. Prvkem typu (rc) je každý řetězec šesti číslic, znaku lomítka a tří až čtyř číslic, který reprezentuje platné rodné číslo dle § 13 zákona 133/2000 Sb. o evidenci obyvatel. Prvkem typu (rok) je každé čtyřmístné číslo, které je, bude nebo bylo, platným kalendářním rokem.

skupinaSkladky:

Prvkem typu (skupinaSkladky) je textový řetězec z množiny následujících označení vymezených § 11 odst. 5 platného znění vyhlášky č. 383/2001 Sb.: „S-IO“ (inertní odpad), „S-OO“ (ostatní odpad), „S-NO“ (nebezpečný odpad), „ost.“ (jiný).

text:

Prvkem typu (text) je každý textový řetězec nenulové délky ve volitelném kódování.

Číselníky

Diagram na obrázku 4-2 zobrazuje vztahy a strukturu číselníků. Jejich napojení na ostatní objekty datového modelu je patrné z přílohy A. Obrázek 4-2. diagram logického datového modelu číselníků

32

Kapitola 4. Návrh informačního systému cBasilej

(kernel)

Objektem typu (#cBasilej) je každá kategorie kontrolovaných odpadů dle dodatku I a II sdělení č. 100/1994 Sb. o Basilejské úmluvě o kontrole pohybu nebezpečných odpadů přes hranice států a jejich zneškodňování.

cDruhZodpOsoby (kernel)

Objektem typu (#cDruhZodpOsoby) je každý druh zodpovědnosti osoby vůči subjektu v jeho odpadovém hospodářství. cKatalog

(kernel)

Objektem typu (#cKatalog) je každá položka katalogu odpadů dle přílohy č. 1 vyhlášky č. 381/2001 Sb., která má šestimístný katalogový kód (tj. ne skupina nebo podskupina). cKatalog_podsk (kernel)

Objektem typu (#cKatalog_podsk) je každá podskupina z katalogu odpadů, tedy položka dle přílohy č. 1 vyhlášky č. 381/2001 Sb., která má čtyřmístný katalogový kód. cKatalog_skup (kernel)

Objektem typu (#cKatalog_skup) je každá skupina z katalogu odpadů v souladu s přílohou č. 1 vyhlášky č. 381/2001 Sb. v platném znění.

cKatastr

(kernel)

Objektem typu (#cKatastr) je každá územně technická jednotka (katastrálních území a případně jeho část) dle číselníku4 Českého statistického úřadu. cKodSkladky (kernel)

Objektem typu (#cKodSkladky) je každý kód skládky dle příslušné tabulky v příloze č. 23 vyhlášky č. 383/2001 Sb. v platném znění. cKodSkladu (kernel)

Objektem typu (#cKodSkladu) je každý kód zařízení dle příslušné tabulky v příloze č. 24 vyhlášky č. 383/2001 Sb. v platném znění. cKodZarizeni (kernel)

33

Kapitola 4. Návrh informačního systému Objektem typu (#cKodZarizeni) je každý kód zařízení k úpravě, využití a odstraňování odpadů dle příslušné tabulky v příloze č. 22 vyhlášky č. 383/2001 Sb. v platném znění. cKraj

(kernel)

Objektem typu (#cKraj) je každý kraj NUTS 3, v souladu se sdělením 490/2003 Sb. o vydání Klasifikace územních statistických jednotek (CZ-NUTS). cNakladani (kernel)

Objektem typu (#cNakladani) je každý způsob nakládání s odpadem dle příloh č. 3 a 4 zákona č. 185/2001 Sb., doplněn o další potřebné způsoby nakládání dle tabulky č. 1 přílohy č. 20 platného znění vyhlášky č. 383/2001 Sb. a způsoby nakládání rozlišující odpad dovezený z členských zemí Evropské unie od odpadu dovezeného ze zemí mimo Evropskou unii podle metodických vysvětlivek oddílu 020 Ročního výkazu o odpadech Odp 5-015, který je součástí Programu statistických zjišťování podle zákona č. 89/1995 Sb. o státní statistické službě. Součástí položek tohoto číselníku je také příznak, zda-li se daný způsob nakládání nachází v seznamu způsobů nakládání povolených pro výkaz Odp 5-01. cNaklOdbVyrobku (kernel)

Objektem typu (#cNaklOdbVyrobku) je každý druh nakládání se zpětně odebraným výrobkem (viz výše), stanovený v příloze č. 19 platného znění vyhlášky č. 383/2001 Sb. cOblast

(kernel)

Objektem typu (#cOblast) je každá oblast NUTS 2, v souladu se sdělením 490/2003 Sb. o vydání Klasifikace územních statistických jednotek (CZ-NUTS). cOdbVyrobek (kernel)

Objektem typu (#cOdbVyrobek) je každý druh výrobku, na který se vztahuje povinnost zpětného odběru, v souladu s § 38 odst. 1 zákona č. 185/2001 Sb. v platném znění.

cOKEC

(kernel)

Objektem typu (#cOKEC) je každá odvětvová klasifikace ekonomické činnosti vymezená sdělením 86/2003 Sb. o vydání Odvětvové klasifikace ekonomických činností (OKEČ), v souladu s číselníkem6 Českého statistického úřadu.

cOkres

(kernel)

Objektem typu (#cOkres) je každý okres NUTS 4, v souladu se sdělením 490/2003 Sb. o vydání Klasifikace územních statistických jednotek (CZ-NUTS).

34

Kapitola 4. Návrh informačního systému cORP

(kernel)

Objektem typu (#cORP) je každá obec s rozšířenou působností a správní obvod hl. m. Prahy, v souladu se sdělením 471/2002 Sb. o zavedení Číselníku obcí s rozšířenou působností (CISORP), Číselníku obcí s pověřeným obecním úřadem (CISPOU) a Číselníku správních obvodů hl. m. Prahy (CISSOP). cPuvodOdbVyrobku (kernel)

Objektem typu (#cPuvodOdbVyrobku) je každý druh původu výrobku, na který se vztahuje povinnost zpětného odběru (viz výše), stanovený v příloze č. 19 vyhlášky platného znění č. 383/2001 Sb. cStat

(kernel)

Objektem typu (#cStat) je každý stát v souladu se sdělením č. 489/2003 Sb. o vydání Číselníku zemí (ČZEM), s kódem podle ČSN ISO 3166 „Kódy pro názvy zemí“, oddíl 1, kód A-2, a s příznakem, zda-li se jedná o členský stát Evropské unie.

cVahaOdbVyrobku (slabý)

Objektem typu (#cVahaOdbVyrobku) je každé upřesnění daného druhu výrobku (#cOdbVyrobek) včetně hmotnosti jeho jednoho kusu, na který se vztahuje povinnost zpětného odběru (viz výše, číselník slouží pro přepočet množství výrobku zadaného v kusech na jeho hmotnost).

cZUJ

(kernel)

Objektem typu (#cZUJ) je každá obec NUTS 5, v souladu se sdělením 490/2003 Sb. o vydání Klasifikace územních statistických jednotek (CZ-NUTS), dle číselníku základních územních jednotek7 Českého statistického úřadu. rKatBas

(vazební)

Objektem typu (rKatBas) je každá reprezentace vazby mezi položkou katalogu odpadů (#cKatalog) a kategorií dle Basilejské úmluvy (#cBasilej) se smyslem:

Skutečnost, že odpady druhu daného položkou katalogu (#cKatalog) mohou patřit8 do dané kategorie dle Basilejské úmluvy (#cBasilej). / 0,N:0,M

Atributy objektů logického datového modelu

Podrobnější specifikaci atributů objektů logického datového modelu vymezují tabulky v příloze A. Narozdíl od zobrazení logického datového modelu diagramem s poměrně vysokým stupněm abstrakce

35

Kapitola 4. Návrh informačního systému (viz obrázek 4-1) udává popis atributů přesnou specifikaci a v některých případech nahrazuje z důvodů přehlednosti symbolicky označené atributy objektů9 v diagramu.

Diagram datových toků

Pro vymezení dynamického chování systému bude použit diagram datových toků, který podrobněji definuje aktivity systému v požadovaných případech užití (viz podkapitola „Případy užití“ v 3). Protože kontextový model systému10 i seznam funkcí specifikuje právě výše zmiňovaný seznam případů užití, přistoupíme nyní přímo k prvnímu stupni dekompozice informačního systému.

Specifikace jednotlivých procesů diagramu datových toků bude pro větší přehlednost popsána použitím strukturovaného anglického jazyka v kombinaci s českým popisem objektů diagramu. Kromě standardních jazykových konstrukcí, jako je přiřazení, větvení či cykly, definujeme navíc funkce send11 a receive12 pro komunikaci procesu pomocí datových toků.

Procesy správy uživatelů

Obrázek 4-3. diagram datových toků procesů správy uživatelů (1. úroveň) Diagram na obrázku 4-3 popisuje interakci systému s terminátory uživatel a administrátor. Vymezené procesy umožňují uživateli jeho autentizaci vůči systému a ustanovení sdíleného tajemství používaného pro autentizaci. Administrátorovi nabízí systém akce spojené s evidencí uživatelů a jejich oprávnění. Dekompozice procesu č. 1 „přihlášení“ je zachycena diagramem na obrázku 4-4. Obrázek 4-4. diagram datových toků procesu č. 1 „přihlášení“ (2. úroveň) Specifikaci procesu č. 1.1 „přihlášení“ lze vymezit takto: receive(login, heslo) from terminator(uživatel) as "login a heslo"; send(login, heslo) to process(1.2) as "zadaný login a heslo"; receive(vysledek) from process(1.2) as "výsledek ověření"; if (vysledek is true) then send(update) to store(uživatelé[login]) as "nastavit příznak přihlášení";

Proces č. 1.2 „ověření hesla“ je pak definován následovně:

receive(login, heslo) from process(1.1) as "zadaný login a heslo"; receive(orig_heslo) from store(uživatelé[login]) as "heslo"; if (heslo = orig_heslo) then send(true) to process(1.1) as "výsledek ověření"; else send(false) to process(1.1) as "výsledek ověření";

V následujících procesech bude zapotřebí informace o identifikátoru konkrétního přihlášeného uživatele, který akce provádí. Formální specifikace by vyžadovala uchování této informace v příslušném úložišti13, avšak pro zjednodušení specifikace předpokládejme dřívější úspěšné přihlášení uživatele vystupujícího v roli daných terminátorů, přičemž jeho „login“ získáme z proměnné $user. Je třeba zdůraznit, že toto řešení je pouze zavedená zkratka a uvedené diagramy jsou vyjádřitelné pomocí korektních formálních diagramů datových toků.

36

Kapitola 4. Návrh informačního systému Při odhlášení uživatele ze systému se provede proces č. 2 „odhlášení“: receive() from terminator(uživatel) as "požadavek odhlášení"; send(update) to store(uživatelé[$user]) as "zrušit příznak přihlášení";

Proces č. 3 „změna hesla“ je dekomponován na obrázku 4-5. Jak je patrné ze struktury dekompozice, proces č. 3.2 „ověření hesla“ plní stejnou funkci jako dříve popsaný proces č. 1.2 „ověření hesla“, a proto zde nebudeme uvádět jeho specifikaci. Obrázek 4-5. diagram datových toků procesu č. 3 „změna hesla“ (2. úroveň)

Změnu hesla uživatele implementuje proces 3.1 „změna hesla“, který při úspěšném ověření původního hesla zapíše do záznamu uživatele jeho nové heslo. Proces lze definovat takto: receive(heslo, new_heslo) from terminator(uživatel) as "původní a nové heslo"; send($user, heslo) to process(3.2) as "login a původní heslo"; receive(vysledek) from process(3.2) as "výsledek ověření"; if (vysledek is true) then send(update, new_heslo) to store(uživatelé[$user]) as "změna hesla";

Dekompozice procesu č. 4 „evidence uživatelů“, znázorněná diagramem na obrázku 4-6, zahrnuje přidání, změnu, smazání a výpis záznamů uživatelů. Jedná o klasický vzor dekompozice evidence, který se bude dále často opakovat (např. evidence subjektů, osob, odpadů, atd.). Proto popíšeme evidenci uživatelů podrobně a další procesy implementující podobné evidence budeme pouze odkazovat na tento případ. Obrázek 4-6. diagram datových toků procesu č. 4 „evidence uživatelů“ (2. úroveň) Proces č. 4.1 „přidání“ má následující specifikaci: receive(uzivatel) from terminator(administrátor) as "nový uživatel"; send(insert, uzivatel) to store(uživatelé);

Podobně probíhá proces č. 4.2 „smazání“:

receive(login) from terminator(administrátor) as "mazaný uživatel"; send(delete) to store(uživatelé[login]) as "zmazání uživatele";

a také proces č. 4.3 „změna“:

receive(login, zmena) from terminator(administrátor) as "změna uživatele"; send(update, zmena) to store(uživatelé[login]) as "změna uživatele";

Proces č. 4.4 „výpis“ reaguje na požadavek výpisu uživatelů a odpovídá žadateli seznamem požadovaných záznamů. Proces je definován následovně14: receive() from terminator(administrátor) as "požadavek výpisu";

37

Kapitola 4. Návrh informačního systému receive(uzivatele) from store(uživatelé[*]); send(uzivatele) to terminator(administrátor) as "výpis uživatelů";

Posledním procesem, který nám zbývá definovat, je proces č. 5 „změna oprávnění uživatele“ z první úrovně diagramu datových toků. Tento proces provádí požadovanou změnu oprávnění uživatele nad úložištěm uživatelů a může být definován takto: receive(login, zmena) from terminator(administrátor) as "změna oprávnění uživatele"; send(update, zmena) to store(uživatelé[login]) as "změna oprávnění";

Procesy údržby systému

Obrázek 4-7. diagram datových toků procesů údržby systému (1. úroveň) Údržba systému zahrnuje zálohování kritických dat a údržbu číselníků (viz diagram na obrázku 4-7). Konkrétní implementace procesu č. 6 „záloha dat“ je silně závislá na použitých technologiích, obecná realizace může být znázorněna např. komunikací s terminátorem databázového systému a požadavku zálohy databáze15. Proces č. 7 „údržba číselníků“ lze dekomponovat podle vzoru procesu evidence (viz dekompozice procesu č. 4, evidence uživatelů).

Procesy správy subjektů, osob a jejich zodpovědností

Obrázek 4-8. diagram datových toků procesů správy subjektů, osob a zodpovědností (1. úroveň) Diagram na obrázku 4-8 znázorňuje část systému implementující evidenci subjektů, osob a zodpovědností osob vůči subjektům. Proces č. 8 „evidence subjektů“ a proces č. 9 „evidence osob“ jsou opět rozložitelné podle vzoru procesu evidence (viz dekompozice procesu č. 4, evidence uživatelů). Podobnou funkcionalitu zahrnuje proces č. 10 „evidence zodpovědností“, který navíc ověřuje existenci stran svázaných vztahem zodpovědnosti, případně doplňuje detaily subjektů a osob do výpisu zodpovědností.

Procesy evidence odpadů a povolení odpadů

Obrázek 4-9. diagram datových toků procesů evidence dávek a povolení odpadů (1. úroveň) Na obrázku 4-9 je znázorněn diagram evidence dávek a povolení odpadů a souvisejících procesů. Evidenci povolení tak, jak ji znázorňuje proces č. 11 „evidence povolení“, lze dekomponovat podle vzoru obecného procesu evidence (viz dekompozice procesu č. 4, evidence uživatelů), a proto zde její specifikaci uvádět nebudeme.

Z pohledu funkcionality je v této části systému nejvýznamnější proces č. 12 „evidence odpadů“, jehož dekompozici znázorňuje diagram na obrázku 4-10. Proces umožňuje přidání, změnu, smazání a výpis záznamů o dávkách odpadů s nimiž bylo nakládáno, včetně kontroly oprávnění k nakládání vycházející z evidence povolení odpadů. Jako volitelnou funkci nabízí proces také automatické vytvoření

38

Kapitola 4. Návrh informačního systému potřebného povolení odpadu16, což je vhodné zejména při evidenci nakládání s odpady kategorie „ostatní odpady“. Obrázek 4-10. diagram datových toků procesu č. 12 „evidence odpadů“ (2. úroveň)

Proces č. 12.1 „přidání“ rozšiřuje stejnojmenný proces ze vzoru obecné evidence, přičemž nová dávka odpadu může být zadána buď s přesně určeným povolením odpadu, nebo pouze s určením vlastností druhu odpadu bez přesného výběru povolení (přesné povolení bude vybráno automaticky na základě shody povoleného druhu odpadu se zadanými vlastnostmi druhu odpadu nové dávky). Proces je definován takto: receive(odpad) from terminator(operátor evidence odpadů) as "nový odpad"; send(odpad) to process(12.5) as "nový odpad"; receive(id_povoleni) from process(12.5) as "upřes. povolení"; if (id_povoleni is not null) then { odpad.id_povoleni = id_povoleni; send(insert, odpad) to store(odpady); }

Velmi podobně vypadá také proces č. 12.2 „změna“, který narozdíl od předchozího procesu neumožňuje měnit detaily druhu odpadu, ale jen přiřazení konkrétnímu povolení odpadu17: receive(id_odpadu, zmena) from terminator(operátor evidence odpadů) as "změna odpadu"; send(id_odpadu, zmena) to process(12.7) as "změna"; receive(vysledek) from process(12.7) as "výsledek kontroly"; if (vysledek is true) then send(update, zmena) to store(odpady[id_odpadu]) as "změna odpadu";

Proces č. 12.3 „smazání“ a proces č. 12.4 „výpis“ je možné definovat téměř shodně se stejnojmennými procesy v dekompozici podle vzoru obecného procesu evidence (viz dekompozice procesu č. 4, evidence uživatelů). Uvedenými procesy se tedy nebudeme dále zabývat.

Kontrolu existence povolení k danému odpadu zajišťuje proces č. 12.5 „kontrola povolení“ a proces č. 12.7 „kontrola přípustnosti změn“. Proces č. 12.5 „kontrola povolení“ používá proměnnou prostředí $autopovoleni18, dovolující automatické vytvoření povolení odpadu v případě, že nebylo nalezeno vyhovující platné povolení. Proces č. 12.5 je specifikován následovně: receive(odpad) from process(12.5) as "nový odpad"; if (odpad.id_povoleni is not null) then { receive(povoleni) from store(povolení[id_povoleni]); if (odpad.datum in povoleni.platnost) then send(odpad.id_povoleni) to process(12.1) as "upřes. povolení"; else send(null) to process(12.1) as "upřes. povolení"; } else { receive(povoleni) from store(povolení[ (id_subjektu = odpad.id_subjektu) && (kodKatalog = odpad.kodKatalog) && (zmenaKateg = odpad.zmenaKateg) && (upresneni = odpad.upresneni) && (kodBasilej = odpad.kodBasilej) && (odpad.datum in platnost) ]);

39

Kapitola 4. Návrh informačního systému

}

if (found povoleni) then send(povoleni.id) to process(12.1) as "upřes. povolení"; else { if ($autopovoleni is true) then { send(odpad.id_subjektu, odpad.kodKatalog, odpad.zmenaKateg, odpad.upresneni, odpad.kodBasilej) to process(12.6) as "požadované povolení"; receive(id_povoleni) from process(12.6) as "přidané povolení"; send(id_povoleni) to process(12.1) as "upřes. povolení"; } else send(null) to process(12.1) as "upřes. povolení"; }

Protože změna odpadu prováděná procesem č. 12.2 nemůže měnit detaily druhu odpadu, ale pouze přiřazení konkrétního povolení odpadu, je specifikace procesu č. 12.7 „kontrola přípustnosti změn“ výrazně jednodušší: receive(id_odpadu, zmena) from process(12.2) as "změna"; receive(odpad) from store(odpady[id_odpadu]); odpad = zmena(odpad); receive(povoleni) from store(povolení[odpad.id_povoleni]); if (odpad.datum in povoleni.platnost) then send(true) to process(12.2) as "výsledek kontroly"; else send(false) to process(12.2) as "výsledek kontroly";

Posledním procesem dekompozice procesu evidence odpadů je proces č. 12.6 „vytvoření povolení“, který je definován následovně: receive(id_subjektu, kodKatalog, zmenaKateg, upresneni, kodBasilej) from process(12.6) as "požadované povolení"; send(insert, (id_subjektu, kodKatalog, zmenaKateg, upresneni, kodBasilej)) to store(povolení); id_povoleni = store(povolení).last_insert_id; send(id_povoleni) to process(12.5) as "přidané povolení";

Nyní se vrátíme zpět k 1. úrovni procesů evidence dávek dopadů. Proces č. 13 „kontrola bilance odpadu“ počítá rozdíl mezi produkcí (resp. převzetím) a zneškodněním (resp. předáním) odpadu daného druhu (dle jeho povolení). Získaný rozdíl vyjadřuje zůstatek nezpracovaného odpadu k aktuálnímu datu podle druhu nakládání. Pokud je kód nakládání s dávkou odpadu roven BN6, jedná se o dovoz a musíme při výpočtu bilance rozlišit, zda-li je to dovoz ze států mimo Evropskou unii či ze členského státu Evropské unie (viz číselník cNakladani). Vstupem procesu je identifikátor povolení odpadů a výstupem je seznam bilance množství pro každý druh nakládání. Proces je definován takto: receive(povoleni) from terminator(operátor evidence odpadů) as "povolení odpadu"; for each "kód nakládání" do suma["první písmeno kódu"] = 0; while (receive(kod_nakladani, mnozstvi, id_partnera) from store(odpady[id_povoleni = povoleni])) do { if (kod_nakladani = "BN6") then { receive(stat) from store(subjekty[id_partnera]); if stat is "členský stát EU" then kod_nakladani = "E00"; else if stat is "stát mimo EU" then kod_nakladani = "D00";

40

Kapitola 4. Návrh informačního systému } druh = "první písmeno z" kod_nakladani; if (kod_nakladani is "přírůstek") then suma[druh] = suma[druh] + mnozstvi; else suma[druh] = suma[druh] - mnozstvi;

} send(suma) to terminator(operátor evidence odpadů) as "výpis zůstatku";

Proces č. 14 „korekce bilance odpadu“ spočítá zůstatek nezpracovaného odpadu podle jeho druhu (tj. povolení) a způsobu nakládání19 a výsledné množství dorovná vytvořením nové dávky odpadů příslušného druhu nakládání. Vstupem procesu je identifikátor povolení odpadů, způsob nakládání, partner nakládání a datum vytvářené dávky odpadů, a příznak, má-li se dorovnat přebytek či nedostatek množství odpadů. Proces je specifikován následovně: receive(povoleni, nakladani, jen_produkci, partner, datum) from terminator(operátor evidence odpadů) as "požadavek korekce"; for each "kód nakládání" do suma["první písmeno kódu"] = 0; druh_nakladani = "první písmeno z" nakladani; while (receive(kod_nakladani, mnozstvi, id_partnera) from store(odpady[(id_povoleni = povoleni) && ("první písmeno z" kod_nakladani = druh_nakladani)])) do { if (kod_nakladani = "BN6") then { receive(stat) from store(subjekty[id_partnera]); if stat is "členský stát EU" then kod_nakladani = "E00"; else if stat is "stát mimo EU" then kod_nakladani = "D00"; } if (kod_nakladani is "přírůstek") then suma = suma + mnozstvi; else suma = suma - mnozstvi; } if ((suma < 0) && (jen_produkci is "přírůstek")) || ((suma > 0) && (jen_produkci is not "přírůstek")) then send(insert, datum, povoleni, |suma|, nakladani, partner) to store(odpady);

Posledním procesem této části systému je proces č. 15 „převod uskladněných odpadů do následujícího roku“, který převede celkové množství odpadů evidovaných jako zůstatky na skladě k 31.12. běžného roku (kódy xN5) na nové dávky odpadů k 1.1. následujícího roku stejného druhu, označené nakládáním jako zůstatky z minulého roku (kód C00). Rozsah převodu je stanoven na vstupu procesu20 (odpady subjektu, odpady celé firmy subjektu, odpady všech subjektů). Proces provádějící uzávěrku evidence je definován takto 21: receive(rozsah, subjekt, novy_rok) from terminator(operátor evidence odpadů) as "požadavek převodu"; datum = "1.1." + novy_rok; nakladani = "C00"; while ( ((rozsah = "subjekt") && (receive(povoleni) from store(povolení[id_subjektu = subjekt]))) || ((rozsah = "firma") && (receive(povoleni) from store(povolení[id_subjektu in subjekty_firmy(subjekt)])))

41

Kapitola 4. Návrh informačního systému || ((rozsah = "všechny") && (receive(povoleni) from store(povolení))) ) do { suma = 0; while (receive(mnozstvi) from store(odpady[(id_povoleni = povoleni) && (datum in (novy_rok-1)) && (kod_nakladani like "xN5")])) do suma = suma + mnozstvi; send(insert, datum, povoleni, suma, nakladani) to store(odpady); }

Procesy evidence zpětného odběru

Obrázek 4-11. diagram datových toků procesů evidence zpětného odběru (1. úroveň) Diagram na obrázku 4-11 znázorňuje procesy evidence zpětného odběru některých výrobků a související procesy. Zobrazený proces č. 16 „evidence příjmu výrobků“ a proces č. 17 „evidence předání výrobků“ lze dekomponovat podle vzoru obecného procesu evidence (viz dekompozice procesu č. 4, evidence uživatelů). Zaměříme se tedy na následující proces č. 18 „kontrola bilance odběrů“, který počítá rozdíl mezi množstvím výrobků evidovaných jako přijaté výrobky zpětného odběru a množstvím výrobků evidovaných jako předané ke zpracování. Vstupem procesu je identifikátor vlastníka zpětně odebraných výrobků a výstupem je seznam bilancí množství jednotlivých druhů zpětně odebíraných výrobků. Samotný proces je specifikován takto: receive(subjekt) from terminator(operátor zpětného odběru) as "subjekt odběrů"; for each "kód druhu výrobku" as (kod) do suma[kod] = 0; while (receive(mnozstvi, kod_vyrobku) from store( přijaté výrobky zp. odb.[(id_subjektu = subjekt)] )) do suma[kod_vyrobku] = suma[kod_vyrobku] + mnozstvi; while (receive(mnozstvi, kod_vyrobku) from store( předané výrobky zp. odb.[(id_subjektu = subjekt)] )) do suma[kod_vyrobku] = suma[kod_vyrobku] - mnozstvi; send(suma) to terminator(operátor zpětného odběru) as "výpis bilance";

Posledním procesem této části systému je proces č. 19 „korekce bilance odběrů“, který umožňuje vyrovnat rozdíly mezi množstvím přijatých výrobků a výrobků předaných ke zpracování (to je vhodné např. při hromadném nakládání se zpětně odebranými výrobky). Vstupem procesu je druh výrobků, jejichž množství má být vyrovnáno, identifikátor přebírajícího partnera, datum, způsob nakládání s předanými výrobky a původ přijatých výrobků. Proces je definován následujícím popisem: receive(subjekt, vyrobek, partner, datum, zpusob, puvod) from terminator(operátor zpětného odběru) as "požadavek korekce"; suma = 0; while (receive(mnozstvi) from store(přijaté výrobky zp. odb.[ (id_subjektu = subjekt) && (kod_vyrobku = vyrobek) ])) do suma = suma + mnozstvi; while (receive(mnozstvi) from store(předané výrobky zp. odb.[

42

Kapitola 4. Návrh informačního systému (id_subjektu = subjekt) && (kod_vyrobku = vyrobek) ])) do suma = suma - mnozstvi; if (mnozstvi > 0) then send(insert, subjekt, datum, suma, partner, zpusob) to store(předané výrobky zp. odb.); else if (mnozstvi < 0) then send(insert, subjekt, datum, suma, partner, puvod) to store(přijaté výrobky zp. odb.);

Procesy evidence zařízení, přepravy a id. listů nebezpečných odpadů

Obrázek 4-12. diagram datových toků procesů evidence zařízení, přepravy a id. listů neb. odpadů (1. úroveň) Obrázek 4-12 obsahuje diagram části systému implementující evidenci zařízení k nakládání s odpady, přepravy nebezpečných odpadů a evidenci identifikačních listů nebezpečných odpadů. Specifikaci všech zobrazených procesů, tj. procesu č. 20 „evidence přepravy neb. odpadů“, procesu č. 21 „evidence zařízení k nakl. s odpady“ a procesu č. 22 „evidence id. listů neb. odpadů“, zde neuvádíme, protože tyto procesy jsou rozložitelné podle vzoru obecného procesu evidence (viz dekompozice procesu č. 4, evidence uživatelů).

Procesy zpracování výkazů

Obrázek 4-13. diagram datových toků v okolí procesu získání vyplněného výkazu (1. úroveň) Diagram na obrázku 4-13 zachycuje okolí procesu č. 23 „získání vyplněného výkazu“, který tvoří část informačního systému umožňující vyjádření zpracovaných environmentálních informací v legislativně stanoveném rozsahu a formě. Proces čte data skoro ze všech významných úložišť a zpracovává je do vhodné podoby. Dekompozici procesu znázorňuje diagram na obrázku 4-14. Obrázek 4-14. diagram datových toků procesu č. 23 „získání vyplněného výkazu“ (2. úroveň)

Prvním procesem dekompozice je proces č. 23.1 „získání vyplněného výkazu“ předávající požadavek výkazu s upřesňujícími údaji směrem k procesu daného druhu výkazu. Proces také formátuje zpětně přijatá data a předává je dále jako odpověď terminátoru odběratele výkazů. Následující text stručně popíše22 procesy 23.2 až 23.11 vytvářející jednotlivé druhy výkazů.

Proces č. 23.2 „Hlášení o produkci a nakládání s odpady“ poskytuje informace o Hlášení o produkci a nakládání s odpady dle přílohy č. 20 vyhlášky č. 383/2001 Sb. Vstupem procesu je subjekt podávající výkaz a vykazovaný rok. Proces prochází povolení odpadů daného subjektu a pro všechny jejich odpady v daném roce spočítá součet množství přírůstků odpadů a součet množství úbytků odpadů v tunách pro jednotlivé kódy a partnery nakládání. Kódy druhu nakládání „D“ a „E“, rozlišující nakládání s dovezenými odpady ze členských států Evropské unie od států mimo Evropskou unii, převede proces před zápisem do výkazu na příslušné kódy druhu nakládání „B“ (viz číselník cNakladani). Odpady evidované jako utajované skutečnosti proces označí a sečte výše uvedeným způsobem odděleně od

43

Kapitola 4. Návrh informačního systému neutajovaných. Dále proces získá informace o subjektu vlastnícím povolení, pokud je to provozovna, tak také o příslušném sídle firmy či obce, a informace o zodpovědné osobě, vše v rozsahu a formě dle formuláře uvedené přílohy vyhlášky. Výstupem procesu jsou tedy detaily sídla subjektu, případně provozovny subjektu, detaily zodpovědné osoby a posloupnost součtů odpadů, dle výše uvedených kritérií. Proces č. 23.3 „výpis průb. evidence prod. a nakl. s odpady“ umožňuje získat informace za přesně vymezené období v rozsahu a formátu vhodném pro § 21 vyhlášky č. 383/2001 Sb. Vstupem procesu je časové období výpisu a subjekt vlastnící evidenci. Výstup procesu je velmi podobný předchozímu procesu, avšak poskytované informace jsou výrazně podrobnější. Proces odešle na výstup detaily sídla subjektu, případně detaily provozovny subjektu, informace o zodpovědné osobě23 a posloupnost součtů odpadů, dle kritérií procesu č. 23.2, ale s podrobným popisem povolení odpadu a se součty pouze za přesně vymezené časové období.

Proces č. 23.4 „Roční výkaz o odpadech Odp 5-01“ poskytuje informace v rozsahu a formátu vhodném pro Roční výkaz o odpadech Odp 5-01 podávaný na Český statistický úřad. Vstupem procesu je subjekt, konkrétně sídlo subjektu podávajícího výkaz (ne provozovna), a vykazovaný rok. Proces vrací informace pro čtyři části výkazu: 1. úvodní strana – detaily subjektu a osoby zodpovědné za sestavení výkazu,

2. část 020 – pro každé povolení podávajícího subjektu a původu odpadu (dle formuláře): posloupnost součtů celkového množství jím povolených odpadů ve vykazovaném roce, dále rozčleněný na částečné součty dle způsobu nakládání, s kódy a kategoriemi odpadu, kódy původu odpadu a kódy způsobu nakládání24,

3. část 021 – pro každou skupinu povolení podávajícího subjektu se stejným katalogovým kódem odpadu: posloupnost součtů předaného množství odpadů s daným katalogovým kódem, rozdělených dle přebírajícího subjektu, včetně uvedení kódu odpadu a detailů přebírajícího subjektu (IČO, obchodní název a adresa), 4. část 322 – pro každou skupinu povolení podávajícího subjektu, kde povolení mají stejný, ve formuláři vyjmenovaný, katalogový kód či podskupinu: posloupnost součtů množství odpadů daného katalogového kódu či podskupiny, které byly zneškodněny ve vykazovaném roce s kódem nakládání obsahujícím písmeno „R“, jako písmeno způsobu nakládání.

Proces č. 23.5 „Roční zpráva o plnění povinnosti zpět. odb.“ umožňuje získat informace pro Roční zprávu o plnění povinnosti zpětného odběru v souladu s přílohou č. 19 vyhlášky č. 383/2001 Sb. Vstupem procesu je subjekt, konkrétně sídlo subjektu podávajícího výkaz (ne provozovna), a vykazovaný rok. Výstupem jsou detaily podávajícího subjektu a osoby zodpovědné za vyplnění (dle formuláře uvedené přílohy) a pro každý druh výrobku, na který se dle zákona vztahuje povinnost zpětného odběru, následující: součet množství výrobků daného druhu přijatých ve vykazovaném roce, rozdělený podle druhu původce, a součet množství výrobků daného druhu předaných ve vykazovaném roce ke zpracování, rozdělený podle druhu způsobu nakládání včetně zůstatků na skladu k 31.12. vykazovaného roku.

Proces č. 23.6 „Zařízení na využívání a odstraňování odpadů“ poskytuje informace pro výkaz Zařízení na využívání a odstraňování odpadů (dále jen zařízení) dle přílohy č. 22 vyhlášky č. 383/2001 Sb. Vstupem procesu je vykazovaný rok a zařízení. Výstupem jsou detaily sídla provozovatele zařízení a případně jeho provozovny, kde je provozováno dané zařízení, detaily subjektu majitele, informace o zodpovědně osobě, detaily vlastního zařízení (vše dle formuláře uvedené přílohy) a posloupnost odpadů povolených zpracovávat v zařízení (kód, kategorie a název dle katalogu odpadů).

44

Kapitola 4. Návrh informačního systému Proces č. 23.7 „Skládky odpadů“ poskytuje informace pro vyplnění výkazu Skládky odpadů v souladu s přílohou č. 23 vyhlášky č. 383/2001 Sb. Vstupem procesu je vykazovaný rok a skládka. Výstupem jsou detaily sídla provozovatele skládky a případně jeho příslušné provozovny, detaily subjektu majitele, informace o zodpovědně osobě, detaily vlastní skládky (dle formuláře uvedené přílohy) včetně jednotlivých skupin skládky s jejich kapacitami a posloupnost odpadů povolených skladovat (kód, kategorie a název dle katalogu odpadů).

Proces č. 23.8 „Shromažď. místa neb. odp. a sběr. místa a sklady odp.“ umožňuje získat informace pro vyplnění výkazu Shromažďovací místa nebezpečných odpadů a sběrová místa a sklady odpadů (dále jen sklady) dle přílohy č. 24 vyhlášky č. 383/2001 Sb. Vstupem procesu je vykazovaný rok a sklad odpadů. Výstupem jsou data výkazu zahrnující: detaily sídla provozovatele skladu a případně jeho příslušné provozovny, detaily subjektu majitele skladu, informace osobě zodpovědné za výkaz, detaily vlastního skladu (dle formuláře uvedené přílohy) a posloupnost odpadů povolených skladovat ve skladu (kód, kategorie a název dle katalogu odpadů).

Proces č. 23.9 „Evidenční list pro přepr. neb. odp. po území ČR“ slouží k získání informací o přepravě nebezpečných odpadů v podobě Evidenčního listu pro přepravu nebezpečných odpadů pro území ČR dle přílohy č. 26 vyhlášky č. 383/2001 Sb. Vstupem procesu je identifikátor přepravního listu. Výstupem je vyplněný formulář, který zahrnuje detaily subjektu odesílatele a příjemce, místa nakládky a vykládky, posloupnost dopravců (včetně jejich detailů, dopravních prostředků a údajů zásilky), posloupnost detailů přepravovaných odpadů (kód a název dle Katalogu odpadů, množství a detaily subjektu původce) a časy převzetí jednotlivými subjekty. Proces č. 23.10 „id. list neb. odpadů“ poskytuje informace v rozsahu a formě identifikačního listu nebezpečných odpadů (dále jen id. list) podle přílohy č. 3 vyhlášky č. 383/2001 Sb. Vstupem procesu je identifikátor id. listu a výstupem jsou jeho rozepsané detaily obsahující: název a kód odpadu dle Katalogu odpadů či upřesnění, kategorii odpadu, jeho kódy dle ADR, detaily původce odpadu, subjektu a osoby zodpovědných za správnost, fyzikální a chemické vlastnosti, nebezpečné vlastnosti, bezpečnostní opatření a opatření při nehodách, haváriích a požárech, a ostatní toxikologické, ekologické a jiné údaje.

Posledním procesem dekompozice je proces č. 23.11 „Dopravce odpadů“, který umožňuje získat informace pro vyplnění výkazu Dopravce odpadů podle přílohy č. 27 vyhlášky č. 383/2001 Sb. Vstupem procesu je identifikátor subjektu dopravce a výstupem je vyplněný formulář obsahující detaily sídla subjektu dopravce, případně včetně jeho provozovny, a osoby zodpovědné za vyplnění (dle formuláře uvedené přílohy).

Poznámky

1. např. použitím konstrukcí implementujících abstrakci vztahů či atributů (datový polymorfismus), pomocných datových struktur (číselníků), atd. 2. logický datový model neobsahuje např. cizí klíče vzniklé v důsledku vazeb mezi objekty, atd.

3. kontrolní algoritmus založený na součtu násobků číslic a jeho zbytku po dělení číslem 11, viz např. http://www.mvcr.cz/casopisy/kriminalistika/1999/9903/rak.html 4. číselník územně technických jednotek je v METIS označen číslem 0052, viz http://www.czso.cz/csu/rso.nsf/i/utj_rso

5. jedná se o způsoby nakládání jejichž kódy začínají písmeny „D“ (dovoz ze států mimo EU) a „E“ (dovoz ze členských států EU)

45

Kapitola 4. Návrh informačního systému 6. číselník OKEČ je v METIS označen číslem 5501, viz http://dw.czso.cz/pls/metis/TUCC_N.DETAILCIS?kodc=c5501 7. číselník NUTS 5 je v METIS označen číslem 0051, viz http://www.czso.cz/csu/rso.nsf/i/zakladni_uzemni_jednotka

8. podklady získány především z přílohy č. 5 původního znění vyhlášky 337/1997 Sb. a z [Benes] (část 7/2.5) 9. např. skupiny atributů objektu (#idListNO) uzavřené do složených závorek

10. tj. vysoce abstraktní model interakce navrhovaného informačního systému s jeho okolím

11. asynchronní odeslání daných dat danému příjemci pomocí daného datového toku

12. synchronní příjem od daného odesílatele pomocí daného datového toku zapisující data do daných proměnných 13. např. v úložišti hodnot proměnných aktuálního prostředí uživatelského sezení

14. funkce receive na 1. řádku definice procesu slouží pouze jako čekání na událost „požadavek výpisu“

15. v praxi např. volání externího programu či knihovní funkce pro získání obrazu aktuálního stavu databáze

16. z návrhu datové části systému vyplývá požadavek existence odpovídajícího povolení ke každé dávce odpadu (viz vazba 02 v sekci „Vazby ideálního datového modelu“ v 3)

17. viz vazba 02 v sekci „Vazby ideálního datového modelu“ v 3

18. tj. zkratka za formální vyjádření údaje z úložiště nastavení systému (viz také informace o přihlášeném uživateli, evidence uživatelů) 19. později bude tento proces implementován pomocí specializace předchozího procesu

20. z důvodu přehlednosti se jedná o jeden proces, přestože je možné rozdělit ho na tři samostatné procesy (každý pro jeden rozsah převodu)

21. pro zjednodušení (a pro zachování jisté míry abstrakce) není v popisu zahrnut případ, kdy k převáděnému odpadu neexistuje povolení platné v následujícím roce (tento případ bude ošetřen při implementaci procesu)

22. pro lepší srozumitelnost vyjádření a v důsledku existence přesných legislativních podkladů pro jednotlivá hlášení budou uvedené procesy popsány volným textem (zájemce odkazujeme na popis modelu uložený na CD, které je součástí práce) 23. rozsah a forma detailů subjektů a zodpovědné osoby jsou shodné s formulářem přílohy č. 20 vyhlášky č. 383/2001 Sb.

24. započítávají se pouze rozšířené způsoby nakládání platné pro tento výkaz (viz číselník cNakladani)

46

Kapitola 5. Architektura a podrobný návrh systému

Tato kapitola pojednává o výběru architektury informačního systému na základě daných požadavků a dříve zpracovaného návrhu. V rámci podrobného návrhu systému bude transformován logický datový model z předchozí kapitoly na vhodný fyzický datový model, který bude použitelný ve zvolené architektuře.

Architektura systému

Protože zadání práce předpokládá nasazení systému v síťovém prostředí byla zvolena architektura klient–server, kde klient zadává požadavky a odesílá je pomocí zabezpečeného síťového spojení na server, který tyto požadavky vyhodnocuje. Tato architektura umožňuje efektivně rozdělit zdroje: klient slouží pouze jako rozhraní mezi informačním systémem a uživatelem, server pak tvoří jádro systému – centrální úložiště dat a zpracování informací.

Na nižší úrovni abstrakce lze rozložit funkčnost serveru na aplikační a databázový server. Aplikační server řeší požadavky klienta a obsahuje výkonnou logiku, tj. provádí operace nad daty poskytovanými databázovým serverem. Databázový server spravuje úložiště dat systému, poskytuje uložená data a provádí jejich změny dle dotazů a příkazů aplikačního serveru. Vzhledem ke středně velkému rozsahu implementovaného informačního systému je typické trojvrstvé rozložení funkčnosti (tj. databázový server, aplikační server a klient) příliš nákladné. V dané situaci je možné při zachování kvality požadovaného řešení významně snížit náklady na vývoj, implementaci i údržbu systému přesunutím části výkonné logiky z aplikačního serveru do vrstvy relačního databázového serveru pomocí nástrojů jazyka SQL (viz [Kral]). Jedná se zejména o použití tzv. uživatelských pohledů, spouští a uložených procedur. Uvedený postup umožňuje v konečné fázi úplně vypustit aplikační server z architektury systému a prosadit komunikaci klienta přímo s příslušně upraveným rozhraním databázového serveru (jeho aplikační vrstvou), který plně převezme roli aplikačního serveru. Obrázek 5-1. diagram architektury systému

Architektura systému je zobrazena diagramem na obrázku 5-1, přičemž výkonná logika aplikačního serveru je výše uvedeným postupem přenesena a zapouzdřena do databázového serveru. Pro středně velký systém představuje toto řešení rozumný kompromis. Rozdělení úloh v rámci použité architektury popisuje následující seznam: server: • • •

správa úložiště dat

implementace procesů specifikovaných v návrhu systému kontrola integrity uložených informací

47

Kapitola 5. Architektura a podrobný návrh systému • • •

klient: • • • •

obousměrná transformace informací při komunikaci mezi serverem a klientem

změna chování v závislosti na konfiguraci prostředí předané klientem řízení přístupu a zabezpečená komunikace s klientem

grafické uživatelské rozhranní

formátování dat evidence a výkazů do tiskových sestav, jejich zobrazení a tisk

správa lokální konfigurace prostředí serveru a chování systému1

zabezpečená komunikace se serverem

Fyzický datový model

Obrázek 5-2. diagram 1. části fyzického datového modelu

Fyzický datový model navazuje na logický datový model (viz podkapitola „Logický datový model“ v 4) a doplňuje ho do podoby vhodné pro konkrétní databázový server. Dochází zde k přizpůsobení modelu použité architektuře a návrhu specifických vlastností objektů, jako jsou relační integritní omezení či další nastavení použitelná pro cílovou databázovou platformu. Výsledný fyzický datový model je vyjádřitelný prostředky použité databázové technologie. Obrázek 5-3. diagram 2. části fyzického datového modelu V naší práci jsme zvolili pro implementaci systému technologii relační databáze. Protože jsme dosud používali při vytváření datových modelů konceptuální modelování s prvky objektového návrhu (dědičnost), bude nutné převést objektové vlastnosti logického datového modelu na jejich reprezentaci ve fyzickém modelu relační databáze. Provedeme následující postup: 1. každou entitu s atributy převedeme na tabulku relačního schématu se sloupci odpovídajícími atributům (v poměru 1:1), s výjimkou objektů vázaných vztahem generalizace-specializace (viz níže),

2. každý neidentifikační vztah2 převedeme pomocí referenční integrity na vztah mezi tabulkami; vztah N:M rozložíme na dva vztahy 1:N vložením asociativní tabulky (v případě, že již existuje tabulka, která vznikla z vazebního objektu, tak novou tabulku nevkládáme a použijeme existující),

3. každý identifikační vztah3 převedeme pomocí referenční integrity na vztah mezi tabulkami, kde cizí klíče vzniklé v důsledku takového vztahu budou součástí primárního klíče tabulky, která vznikla ze slabého entitního typu.

V případě převodu vztahu dědičnosti (tj. generalizace-specializace) do fyzického datového modelu relační databáze máme více možností. V našem modelu nastane tato situace u objektu „subjekt“ a jeho specializací „sidloFirmy“, „sidloObce“, „provozovna“ a „obcanBezIC“, a u objektu „zarizeni“ a jeho specializací „zarizeniZarizeni“, „zarizeniSkladka“ a „zarizeniSklad“ (viz část podkapitoly „Objekty ideálního datového modelu“ v 3). V obou případech se jedná o úplnou specializaci, kdy jsou

48

Kapitola 5. Architektura a podrobný návrh systému generalizované objekty abstraktními entitními typy. Volba konkrétního postupu bude vycházet z očekávaného způsobu přístupu k objektům. Obrázek 5-4. diagram 3. části fyzického datového modelu

Pro entitní typ „zarizeni“ a všechny jeho specializace vytvoříme příslušné tabulky, přičemž tabulky vzniklé ze specializovaných objektů propojíme s generalizovaným objektem identifikačním vztahem s významem: „specializace daného objektu / 1,1:0,M“. To znamená, že v relačním schématu budou mít tabulky ze specializovaných objektů jako svůj primární klíč pouze cizí klíč tabulky z generalizovaného objektu. Do tabulky vzniklé z generalizovaného objektu dále umístíme atribut „druh“, který bude určovat druh specializace (skutečný typ uloženého objektu). Korektnost uvedených vztahů a atributů (zejména vzájemnou výlučnost vztahů) ohlídáme pomocí vhodných integritních omezení relačního schématu. Obrázek 5-5. diagram 4. části fyzického datového modelu

Při přístupu k záznamu specializovaného objektu ve schématu implementovaném podle předchozího odstavce musíme nejprve načíst část záznamu uloženou v tabulce generalizovaného objektu a dle druhu specializace načíst zbytek záznamu z příslušené specializované tabulky. Tento zdlouhavý přístup není vhodný pro časté čtení záznamů, což bude zcela jistě případ entitního typu „subjekt“ a jeho specializací. Pro optimalizaci přístupu zde vytvoříme z objektu „subjekt“ a všech jeho specializací pouze jednu relační tabulku, do které umístíme jako sloupce sjednocení atributů všech uvedených entitních typů4. Nový atribut „druh“, který bude opět vyjadřovat skutečný typ v tabulce uloženého objektu, bude také určovat, které atributy mají být naplněné. V takto řešeném schématu lze přečíst záznam libovolného typu pouze na jeden přístup. Obrázek 5-6. diagram 5. části fyzického datového modelu Je třeba poznamenat, že řešení popsané v předchozím odstavci úmyslně zavede do databáze tabulku „subjekt“, která nevyhovuje 3. normální formě. Korektnost záznamů tabulky a jejích vazeb je proto nutné ošetřit pomocí integritních omezení. Vzhledem k tomu, že frekvence čtení záznamů z uvedené tabulky několikanásobně převyšuje frekvenci modifikace jejích dat, je uvedené řešení optimální.

Konečný vzhled fyzického datového modelu zachycují diagramy na obrázcích 5-2 až 5-6. S modelem úzce souvisí prvky aplikačního rozhraní, kterým bude věnována podkapitola „Aplikační rozhraní serveru“ v 6.

Poznámky

1. ale bez implementace (bude na straně serveru); např. vymezení evidovaného období, vykazovaného roku, aktivního subjektu, za který jedná uživatel, volba možnosti automaticky vytvářet povolení odpadů, atd. 2. neidentifikační vztah znamená, že jsme schopni rozlišit mezi dvěma instancemi jednoho entitního typu na základě hodnot jeho vlastních atributů bez existence vztahu, tj. nejedná se o existenční závislost (v zápise UML je to prostá asociace a agregace, která není kompozicí)

49

Kapitola 5. Architektura a podrobný návrh systému 3. identifikační vztah znamená, že různé instance jednoho entitního typu jsou identifikovatelné tím, že jsou v povinném vztahu k instanci entity jiného typu, tj. jedná se o existenční závislost (v zápise UML je to kompozice)

4. pro zachování jednoznačnosti si vypomůžeme vhodným prefixem atributů

50

Kapitola 6. Implementace a testování informačního systému

Následující text popisuje výběr konkrétních technologií pro jednotlivé části systému a vlastní implementaci, která je rozdělena na tři fáze: specifikace rozhraní vrstev architektury, implementace serveru a implementace klienta. V souvislosti s implementací částí systému je v textu stručně zmíněno také jejich testování. V závěru kapitoly charakterizujeme rozšíření systému zpracovaná nad rámec původního návrhu a stav jejich implementace.

Technologie a nástroje

Pro implementaci databázového serveru informačního systému byl zvolen relační databázový server PostgreSQL1 verze 8.0. Jedná se o open source projekt s více než patnáctiletou historií vývoje, který je v současné době de facto standardem pro open source řešení databází podnikových informačních systémů. Server je k dispozici pro všechny moderní operační systémy, zahrnující operační systémy založené na technologiích Windows NT, UNIX, Linux, ale také méně běžné operační systémy, jako jsou os/2 či Novell. Funkčností je systém plně srovnatelný s komerčními databázovými systémy2.

Zvolený databázový systém nabízí nástroje potřebné pro implementaci výkonné logiky aplikační vrstvy informačního systému podle podkapitoly „Architektura systému“ v 5. Pro zachování nezávislosti na produktech třetích stran bude aplikační vrstva implementována pomocí nástrojů jazyka SQL dle standardu SQL:20033 rozšířeného o specifické vlastnosti databázového stroje PostgreSQL (dále jen DBMS). Pro implementaci algoritmů procesů použijeme procedurální jazyk PL/pgSQL.

Klient bude implementován pomocí programovacího jazyka Object Pascal ve vývojovém prostředí Borland Delphi 7.04, jako 32bitová aplikace primárně určená pro operační systém typu Microsoft Windows. Obrázek 6-1. diagram rozmístění technologií v architektuře systému

Pro přístup k databázovému serveru a vizualizaci dat budou použity komponenty Zeos Database Objects verze 5.5.0 (dále jen ZeosDBO) z projektu ZeosLib5 dostupné pod licencí GPL6. Tyto komponenty jsou přímo napojené na knihovnu libpq, která tvoří na straně klienta programátorské rozhraní k databázi PostgreSQL nad síťovým protokolem TCP/IP. Do komponent doplníme podporu spojení zabezpečených pomocí Secure Socket Layer (SSL) s certifikátem na straně serveru (podrobněji viz příloha E). Knihovna libpq i databázové komponenty ZeosDBO jsou použitelné také pod operačním systémem Linux. Formátování tiskových sestav a jejich tisk bude probíhat pomocí komponent QuickReport dodávaných společností QuSoft jako součást vývojového nástroje Borland Delphi. Tiskové komponenty rozšíříme o možnost tisku textů formulářů dělených na kolonky po jednotlivých písmenech. Rozmístění použitých technologií v architektuře systému ukazuje diagram na obrázku 6-1.

51

Kapitola 6. Implementace a testování informačního systému

Aplikační rozhraní serveru

V této části kapitoly specifikujeme aplikační rozhraní umožňující zapouzdření aplikační logiky uvnitř použitého databázového serveru. Prvky aplikační logiky budou odpovídat procesům z diagramu datových toků (viz podkapitola „Diagram datových toků“ v 4), které vyjádříme pomocí: •

•

• • •

zpřístupněných relačních tabulek hlídaných spouštěmi a použitím integritních omezení7 (takto budou implementovány především procesy „evidence“ a specifické vlastnosti datových typů atributů), uživatelských pohledů s přepisovacími pravidly pro přístup8 (odpovídající převážně procesům „evidence“ objektů vzniklých mapováním vztahu generalizace-specializace do fyzického modelu),

prostých uživatelských pohledů (zejména procesy kontrol bilancí a zpracování výkazů),

uložených procedur (ostatní procesy),

původních nástrojů a aplikačního rozhraní databázového serveru PostgreSQL (procesy správy uživatelů a údržby systému).

Zájemce o podrobný popis aplikačního rozhraní serveru odkazujeme na přílohu B.

Správa uživatelů a údržba systému

Procesy správy uživatelů lze plně zastoupit systémem pro řízení přístupu k objektům databází relačního databázového serveru PostgreSQL (podrobněji viz [PgSQL]).

Uživatelské role navržené v rámci případů užití (viz aktéři systému v podkapitole „Případy užití“ v 3) vyjádříme jako skupiny uživatelů databázového serveru. Do těchto skupin mohou být přidáváni jednotliví uživatelé podle toho, jaké role zastávají při užívání systému. V našem případě je pak účelné přidělovat oprávnění pro celé skupiny uživatelů představující uživatelské role.

Také proces přihlášení uživatele je realizován databázovým serverem, a to při přihlášení uživatele k databázi na základě sdíleného tajemství (viz také příloha E). Své přístupové heslo může uživatel změnit prostřednictvím příkazů jazyka SQL specifických pro systém řízení přístupu serveru PostgreSQL. Podrobný popis příkazů k vytváření a rušení uživatelů či uživatelských skupin, nastavení oprávnění k objektům databáze a změnu hesla uživatele je uveden v části přílohy „Řízení přístupu“ v D.

Z hlediska údržby systému je pověřený uživatel (či uživatelská skupina) schopen spravovat číselníky pomocí standardních příkazů jazyka SQL, jak je to popsáno v části podkapitoly „Obecná evidence“. Pro zálohování dat, které je nezbytnou součástí údržby informačního systému, lze opět využít nástroje serveru PostgreSQL, případně sestavit řešení průběžného zálohování systému po síti umožňující nepřetržitý provoz i během výpadků produkčního serveru. Zájemce o konkrétní příklady řešení zálohování systému odkazujeme na část přílohy „Záloha a obnova dat“ v D.

Nastavení prostředí

Část chování serveru k připojenému klientovi je závislá na konkrétním nastavení relace připojení. Jedná se například o aktivní období, tj. časové období, ve kterém je vedena aktuální evidence, či o kalendářní rok, ke kterému mají být tisknuty výkazy. Ke správě úložiště prostředí relace připojení bude systém poskytovat uložené procedury9: „session_start“, která inicializuje úložiště proměnných aktuální relace připojení10, a „session_destroy“, která úložiště odstraní. Samotné nastavení proměnných prostředí realizuje uložená procedura „session_putv“ nastavující proměnnou daného jména na danou hodnotu. Procedura „session_getv“ pak vrátí hodnotu proměnné daného jména.

52

Kapitola 6. Implementace a testování informačního systému Systém používá následující proměnné prostředí: filter_date_from:

datum začátku aktivního období, tj. období, od kterého (včetně) probíhá aktuální evidence,

filter_date_to:

datum konce aktivního období, tj. období, do kterého (včetně) probíhá aktuální evidence,

filter_date_year:

kalendářní rok, ve kterém se budou tisknout všechny výkazy (pokud neuveden, tak platí aktuální rok),

povoleni_self:

číselná hodnota udávající reakci systému v případě, že se uživatel pokusí vytvořit dávku odpadu bez platného povolení (viz část podkapitoly „Evidence odpadů a povolení odpadů“) 1. oznámit chybu

2. oznámit chybu, nabídnout automatické vytvoření není-li nebezpečný odpad, 3. oznámit chybu, nabídnout automatické vytvoření vždy,

4. automaticky vytvořit není-li nebezpečný odpad, jinak oznámit chybu,

5. automaticky vytvořit není-li nebezpečný odpad, jinak toto vytvoření nabídnout, 6. automaticky vytvořit příslušné povolení vždy. povoleni_part_check:

číselná hodnota udávající, zda-li se bude u dávky odpadu kontrolovat existence platného povolení partnera nakládání 1. povolit nakládání i bez povolení partnera, vždy,

2. povolit nakládání i bez povolení partnera, není-li nebezpečný odpad, 3. vždy vyžadovat vyhovující povolení partnera. povoleni_part:

číselná hodnota udávající reakci systému v případě, že se uživatel pokusí vytvořit dávku odpadu s partnerem, který nemá platné povolení k danému druhu odpadu (číselné hodnoty stejné jako u proměnné povoleni_self),

partevid_A00:

příznak, má-li se při převzetí odpadu od partnera (nakládání B00) generovat produkce odpadu (nakládání A00) v evidenci partnera,

partevid_AN3:

příznak, má-li se při převzetí odpadu od partnera (nakládání B00) generovat předání odpadu (nakládání AN3) v evidenci partnera,

53

Kapitola 6. Implementace a testování informačního systému partevid_B00:

příznak, má-li se při předání odpadu partnerovi (nakládání xN3) generovat převzetí odpadu (nakládání B00) v evidenci partnera.

Obecná evidence

Procesy evidence, tj. přidání a odebrání evidovaných záznamů a modifikace jejich údajů, lze realizovat pomocí standardních příkazů jazyka SQL a vhodnou volbou integritních omezení, spouští a uživatelských oprávnění k objektům, které uchovávají evidenci. Standardními nástroji jazyka SQL zde rozumíme dotazy SELECT v souladu s normou SQL:2003 (viz podkapitola „Technologie a nástroje“) a příkazy INSERT, UPDATE a DELETE pro vložení, modifikaci a smazání záznamů.

Změny provedené výše uvedenými operacemi jsou automaticky kontrolovány pomocí integritních omezení (např. nezáporné množství dávky odpadu, platný formát rodného čísla, atd.) a to včetně vazeb mezi objekty, plně v souladu s datovým modelem informačního systému. Při mazání záznamu platí, že pokud jsou na mazaný objekt navázány jeho komponenty pomocí vztahu obecné agregace, jsou smazány také. Pokud existuje jiná vazba druhu 1:M, nelze záznam smazat, dokud jsou na něj takto navázané další záznamy. Rovněž nelze odstranit položku číselníku, je-li někde použita. Složitější kontroly změn provedených příkazy INSERT, UPDATE a DELETE, případně doplnění údajů ovlivněných záznamů, jsou ošetřeny pomocí spouští. Takto jsou realizovány: 1. podmínka, že na identifikačním listu nebezpečného odpadu smí být uveden pouze nebezpečný odpad dle Katalogu odpadů či odpad s vlastnostmi nebezpečného odpadu,

2. podmínka, že pokud má dávka odpadu nakládání vyžadující partnera, je partner zvolen, v opačném případě úprava záznamu tak, aby byl partner nevyplněn, 3. podmínka, že datum dávky odpadu splňuje platnost povolení, které určuje druh odpadu,

4. podmínka, že partner nakládání s dávkou odpadu je jiný, než vlastník povolení odpadu (tedy i vlastník dávky odpadu), 5. úprava údajů o nákladech na zneškodnění dávky odpadů tak, aby byly vyplněny pouze je-li nakládání s dávkou odpadu zneškodněním,

6. v případě generování partnerské evidence automatické doplnění příslušných dávek v evidenci partnera nakládání,

7. podmínka, že identifikační list vybraný k danému odpadu je pro tento odpad vhodný (má stejný kód odpadu dle Katalogu odpadů), 8. podmínka, že se při změně údajů povolení odpadu neporuší podmínky č. 3 nebo č. 4,

9. podmínka, že tuzemský subjekt má určenu základní územní jednotku (ZÚJ) a zahraniční subjekt má vyplněn stát původu,

10. podmínka, že změna údajů identifikačního listu nebezpečných odpadů neporuší podmínku č. 7, 11. a doplnění údajů o druhu odpadu, pokud jsou nevyplněny a je zvolen identifikační list nebezpečného odpadu.

Zvláštní pozornost je třeba věnovat integritě údajů v tabulkách vzniklých převodem z generalizovaného objektu „subjekt“ a jeho specializací (viz podkapitola „Fyzický datový model“ v 5).

U tabulek vzniklých z generalizovaného objektu „zarizeni“ a jeho specializací je zachování integrity řešeno omezením přístupu k původním tabulkám a vytvořením uživatelského pohledu „zarizeni_detail“

54

Kapitola 6. Implementace a testování informačního systému s přepisovacími pravidly. Přepisovací pravidla obecně umožňují vkládání, mazání a modifikaci záznamů poskytnutých pohledem pomocí standardních prostředků jazyka SQL, stejným způsobem, jako by se jednalo o obyčejnou tabulku. Pohled pak zapouzdřuje tabulky vazeb generalizace-specializace a pomocí přepisovacích pravidel udržuje jejich integritu.

Evidence odpadů a povolení odpadů

Evidenci odpadů a povolení odpadů lze realizovat použitím standardních SQL nástrojů na příslušnou tabulku. Procesy kontrolující platnost povolení a přípustnost změny jsou zde zastoupeny pomocí příslušných integritních omezení zmíněných v předchozí podkapitole.

V případě evidence odpadů je navíc vytvořen uživatelský pohled „odpad_detail“ s přepisovacími pravidly, volitelně umožňující při přidání dávky odpadu automatické nalezení či vytvoření potřebného povolení u subjektu původce a u partnera nakládání. Záznamy poskytované pohledem mají podobné atributy, jako záznamy tabulky „odpad“, ale jsou zde navíc rozepsané podrobnosti o druhu odpadu, nacházející se v záznamu příslušného povolení. Při vkládání záznamu do pohledu jsou pak tyto údaje použity pro vytvoření odpovídajícího povolení, případně pro nalezení vyhovujícího platného povolení. Proces „kontrola bilance odpadu“ je realizován uživatelskými pohledy „odpad_bilance“ a „odpad_eu_bilance“. První z nich zobrazuje bilance množství odpadů seskupených dle povolení a nerozšířených způsobů nakládání, tj. bez rozlišení nakládání s dovezenými odpady dle státu dovozu. Druhý pohled zobrazuje také bilance množství odpadů seskupených dle povolení, ale s využitím rozšířených způsobů nakládání, tj. s rozlišením nakládání s odpady dovezenými ze členských zemí Evropské unie a ze zemí mimo Evropskou unii (viz číselník cNakladani).

Korekci nevyrovnané bilance odpadu zajišťují uložené procedury „odpad_dorovnat_ odpady_povoleni“ a „odpad_dorovnat_odpady_subjektu“, které pracují s nerozšířenými způsoby nakládání. První procedura vyrovná bilanci daného povolení a druhu nakládání v souladu s příslušným procesem diagramu datových toků. Druhá rozšiřuje proces dorovnání na odpady všech povolení daného subjektu. Pro vyrovnání bilance dle rozšířených způsobů nakládání existují odpovídající procedury „odpad_dorovnat_eu_odpady_povoleni“ a „odpad_dorovnat_eu_ odpady_subjektu“. Převod uskladněných odpadů do následujícího roku je realizován uloženou procedurou „odpad_prevod_zustatku“ v souladu s odpovídajícím procesem diagramu datových toků.

Evidence zpětného odběru

Evidence zpětného odběru zahrnuje procesy evidence příjmu výrobků a evidence předání výrobků, které jsou realizovány použitím standardních SQL nástrojů na příslušné tabulky podle vzoru popsaného v podkapitole „Obecná evidence“. Zvláštní pozornost musíme věnovat pouze procesům kontroly a korekce bilance odběrů. Proces kontrola bilance odběrů implementuje uživatelský pohled „odber_bilance“, který umožňuje zobrazit bilanci mezi přijatým a vydaným množstvím zpětně odebraných výrobků podle druhu výrobku. Kromě rozdílu množství zobrazuje pohled také rozdíl počtu kusů výrobků, a to jen pokud mají všechny započítané zpětné odběry počet kusů vyplněn 11. Korekce bilance příjmu a výdeje zpětně odebraných výrobků realizují uložené procedury „odber_dorovnat_odbery_vyrobku“ a „odber_dorovnat_odbery_subjektu“. První vyrovnává bilanci zpětných odběrů pouze u daného druhu výrobku daného subjektu, zatímco druhá vyrovnává bilanci u všech výrobků daného subjektu.

55

Kapitola 6. Implementace a testování informačního systému

Zpracování výkazů

Proces získání vyplněného výkazu (tj. proces č. 23.1 v diagramu datových toků, viz podkapitola „Procesy zpracování výkazů“ v 4) bude v souladu se zvoleným rozmístěním použitých technologií v architektuře implementován v části klienta informačního systému. Proces umožní uživateli zvolit požadovaný výkaz, který tento proces sestaví a zformátuje na základě dat poskytnutých serverem (resp. jedním z ostatních procesů této části systému). Ostatní procesy poskytující data pro jednotlivé výkazy (tj. procesy č. 23.2 až č. 23.11) jsou realizovány v uvedeném pořadí následujícími uživatelskými pohledy.

Data pro Hlášení o produkci a nakládání s odpady poskytují uživatelské pohledy „hlaseni_tisk“ (hlavička formuláře) a „hlaseni_odpady_tisk“ (položky odpadů uvedených na formuláři). Protože pro tento výkaz jsou legislativně stanoveny pouze nerozšířené způsoby nakládání s odpadem, převádí pohled způsoby nakládání druhu „D“ a „E“ na příslušné nakládání druhu „B“ (tj. slučuje způsoby nakládání s odpady dovezenými ze členských zemí Evropské unie dohromady se způsoby nakládání s odpady dovezenými ze zemí mimo Evropskou unii). Podobně pro výkaz výpisu průběžné evidence produkce a nakládání s odpady poskytují data pohledy „prubezna_tisk“ a „prubezna_odpady_tisk“ – opět s nerozšířenými způsoby nakládání. Proces Roční výkaz o odpadech Odp 5-01 realizuje skupina pohledů „csu501_tisk“ (hlavička výkazu), „csu501_020_tisk“ (řádky s produkcí odpadu v části 020), „csu501_020nakl_tisk“ (řádky obsahující nakládání s vyprodukovaným odpadem v části 020), „csu501_021_tisk“ (část 021) a „csu501_322_tisk“ (příloha 322). Definice pohledů jsou plně v souladu s uvedeným procesem diagramu datových toků. Výkaz Roční zpráva o plnění povinnosti zpětného odběru je sestavován z dat poskytovaných uživatelskými pohledy „rocni_odbery_tisk“, „rocni_odbery_vyrobky_tisk“ a „rocni_odbery_ partneri_tisk“. První z nich získává data pro hlavičku výkazu, další pak zobrazují stav zpětných odběrů jednotlivých výrobků a rozpis předání zpětně odebraných výrobků partnerům. Procesy Zařízení na využívání a odstraňování odpadů, Skládky odpadů a Shromažďovací místa nebezpečného odpadu a sběrová místa a sklady odpadu jsou implementovány v uvedeném pořadí pohledy „zarizeni_tisk“, „skladka_tisk“ a „sklad_tisk“. Navíc pro zobrazení seznamu povolených odpadů v zařízení a shromažďovacích místech je nutný pohled „zarizeni_obecne_odpady_tisk“.

Za účelem realizace procesu Evidenční list pro přepravu nebezpečných odpadů po území ČR implementujeme uživatelské pohledy „preprava_tisk“ (hlavička přepravního listu), „preprava_ odpady_tisk“ (seznam přepravovaných odpadů na přepravním listu), „preprava_ dopravci_tisk“ (příloha se seznamem třetího a následujících dopravců uvedených na přepravním listu 12) a „preprava_puvodci_tisk“ (příloha se seznamem původců přepravovaných odpadů). Proces identifikační list nebezpečného odpadu je implementován uživatelským pohledem „ilno_tisk“. Poslední uživatelský pohled „dopravce_ tisk“ pak realizuje proces pro výkaz Dopravce odpadů.

Ostatní

Ostatní prvky aplikačního rozhraní serveru je možné rozdělit na dvě skupiny. První tvoří uložené procedury pro hromadnou manipulaci s evidencí (zejména hromadná změna některých údajů, mazání evidence a přesun mezi evidujícími subjekty). Druhou skupinu prvků aplikačního rozhraní představují pomocné uložené procedury (např. formátování údajů či tvorba textových řetězců popisujících evidované záznamy). Úplný výčet těchto uložených procedur je uveden v příloze B.

56

Kapitola 6. Implementace a testování informačního systému

Implementace a testování serveru

Implementace serveru informačního systému pro odpadové hospodářství podniku spočívá ve vytvoření odpovídající databáze v souladu s fyzickým datovým modelem systému a implementací aplikačního rozhraní serveru. Výsledkem je zápis struktury databáze a na serveru uložené aplikační logiky pomocí části jazyka SQL pro definici dat a procedurálního jazyka PL/pgSQL. Odpovídající soubor13 s výše uvedeným zápisem implementace serveru je uložen na CD v příloze této práce (viz příloha F). Během implementace serveru informačního systému byly prováděny dva druhy testování:

1. testování funkčnosti prvků aplikačního rozhraní nad strukturou databáze podle navržené specifikace, bez jejich závislostí na okolních prvcích (případné závislosti byly dočasně vyřešeny pomocí prototypů simulujících prvky volané v důsledku závislostí), 2. testování spolupráce prvků aplikační logiky a srovnávání skutečného chování s očekávaným chováním dle specifikace aplikačního rozhraní (toto testování probíhalo postupně v průběhu implementace, podle umístění jednotlivých prvků v grafu závislostí).

Implementace a testování klienta

Pro vývoj klientské části informačního systému byl zvolen inkrementální vývojový proces, kde se střídaly fáze návrhu uživatelského rozhraní 14, jeho implementace a testování. Rámcovou podobu funkčnosti klienta udávala specifikace aplikačního rozhraní serveru, se kterým klient v systému komunikuje.

První fází implementace této části systému bylo integrování použitých technologií a jejich přizpůsobení požadavkům (viz podkapitola „Technologie a nástroje“). V rámci této fáze byla implementována do databázových komponent ZeosDBO podpora knihoven SSL pro zabezpečenou komunikaci se serverem. Bylo přidáno volání funkce PQgetssl knihovny pqsql a požadavek na SSL spojení při volání funkce PQconnectdb ustanovující spojení s databázovým serverem.

Druhá fáze vývoje a implementace klienta se zaměřila na návrh a implementaci uživatelského rozhraní pro zobrazení interaktivního formuláře s údaji evidence. Při implementaci byly použity standardní databázové komponenty15 vývojového prostředí Borland Delphi, které byly napojeny na ZeosDBO komponenty datových zdrojů. Zde byla výrazně rozšířena komponenta pro výpis výsledků databázového dotazu ve formě tabulky16 a zavedena nová grafická komponenta panelu s přepínáním viditelnosti záložek podle hodnoty datového zdroje17. Uživatelské rozhraní bylo úspěšně vyzkoušeno na modulech pro evidenci subjektů, osob a zodpovědností osob vůči subjektům. Další fáze zahrnovaly postupnou implementaci modulů uživatelského rozhraní pro povolení odpadů, dávky odpadů, zařízení a jeho specializace, přepravní a identifikační listy nebezpečných odpadů, a evidenci příjmů a výdejů zpětně odebíraných výrobků.

Poslední fáze implementace se zaměřila na uživatelské rozhraní pro správu a údržbu systému a podpůrné prvky aplikačního rozhraní (např. hromadné úpravy evidence či nastavení proměnných prostředí). Součástí této fáze byla také integrace komponent QuickReport pro formátování tiskových sestav a jejich rozšíření o možnost tisku formulářů výkazů. Na konci každé fáze inkrementálního vývojového procesu bylo provedeno testování uživatelského rozhraní ve spolupráci s uživatelem.

57

Kapitola 6. Implementace a testování informačního systému

Rozšíření

Při implementaci serveru byl v rámci sledování změn klíčových objektů evidence rozšířen fyzický datový model o objekt s atributy data a času poslední změny údajů záznamu a jména uživatele, který tuto změnu provedl (viz třetí část přílohy E). Atributy byly pomocí dědičnosti přeneseny do objektů, u kterých je požadováno evidovat poslední změnu záznamů. Na objekty jsou napojeny spouště, které po každém vložení či změně záznamu aktualizují příslušné atributy. Obrázek 6-2. diagram komunikace klienta inf. systému s Registrem ekonomických subjektů

Klient informačního systému, který realizuje uživatelské rozhraní a komunikaci s aplikačním rozhraním serveru, byl rozšířen o napojení na server Registru ekonomických subjektů18 provozovaný Českým statistickým úřadem. Server umožňuje hledání ekonomických subjektů podle IČ nebo obchodního názvu organizace a u nalezených subjektů poskytuje podrobné údaje včetně příslušných kódů z číselníků Českého statistického úřadu. Klient informačního systému pro odpadové hospodářství podniku provádí dotazy na server RSW pomocí protokolu HTTP a analyzuje výsledné XHTML dokumenty vrácené serverem (viz diagram na obrázku 6-2). Výsledkem analýzy jsou data ve formátu vhodném pro evidenci subjektů, která klient nabídne uživateli v podobě doplněného záznamu subjektu. Vzhledem k tomu, že rozhraní serveru RSW generuje stránky, které nejsou validní19 podle deklarovaného schématu XHTML 1.0 Transitional, analýza prováděná klientem vychází z heuristického přístupu a nemusí být vždy úspěšná.

Systém je připraven pro rozšíření aplikačního rozhraní serveru o prvky, které by poskytovaly informace ve formátu datového standardu 20 Ministerstva životního prostředí pro elektronický přenos dat o odpadech, zařízeních k nakládání s odpady a dalších informací od osob povinných tyto údaje ohlašovat na obce s rozšířenou působností. Stávající rozhraní informačního systému lze také využít pro získání informací požadovaných managementem podniku a podkladů vhodných pro sestavení plánu odpadového hospodářství organizace.

Poznámky

1. viz oficiální webové stránky http://www.postgresql.org/ nebo neoficiální české webové stránky http://postgresql.ok.cz/ 2. existují také komerční systémy založené přímo na PostgreSQL, jako jsou PowerGres (viz http://www.sraapowergres.com/) nebo dbExperts PostgreSQL Professional (viz http://www.dbexperts.net/)

3. návrh standardu je dostupný na adrese http://www.wiscorp.com/sql/sql_2003_standard.zip

4. viz http://www.borland.com/delphi/; možno použít vývojové prostředí Borland Kylix pod operační systém Linux, viz http://www.borland.com/kylix/

5. viz http://sourceforge.net/projects/zeoslib/

6. GNU General Public License (GPL, viz http://www.gnu.org/copyleft/gpl.html)

7. pojem spoušť je častěji známý pod anglickým názvem „trigger“ a pojem integritní omezení pod anglickým názvem „constraint“

58

Kapitola 6. Implementace a testování informačního systému 8. pojem uživatelský pohled je častěji známý pod anglickým názvem „view“ a pojem přepisovací pravidlo pod anglickým názvem „rule“

9. databázový server PostgreSQL umožňuje definovat uživatelské funkce (v textu zastoupené pojmem uložené procedury) v dotazovacím jazyku SQL a mnoha procedurálních jazycích (např. PL/pgSQL, PL/Tcl, atd.) – uživatelské funkce se spouští použitím v příkazech SQL

10. inicializace úložiště je nutná před voláním „session_putv“ či „session_getv“ a měla by proběhnout i pokud nebudou proměnné prostředí používány 11. pokud by některé záznamy příjmu či výdeje zpětně odebíraných výrobků neměly vyplněn počet kusů, nebyl by součet (tj. bilance) definován – proto tuto situaci řeší pohled nezobrazením bilance počtu kusů

12. 1. a 2. dopravce se zapíše přímo na přepravní list, další musíme uvést do přílohy generované tímto pohledem 13. výpis souboru zde neuvádíme, protože svou velikostí překračuje rozsah tištěné podoby diplomové práce

14. návrh uživatelského rozhraní zde zmiňujeme z důvodu jeho těsné souvislosti s nástroji vývojového prostředí

15. tzv. „Rapid Application Development“ (RAD) nástroje, kde grafické uživatelské prvky mají vazbu do datové části aplikace přes objekt datového zdroje – v našem případě odpovídá vazbě na aplikační rozhraní serveru

16. byl implementován export do souboru, hledání, tisk a nastavení viditelnosti a pořadí sloupců tabulky

17. grafická komponenta byla použita např. při volbě druhu subjektu v evidenci subjektů 18. RSW verze 4.0.3, viz http://dw.czso.cz/rswj/dotaz.jsp

19. dle W3C Markup Validation Service, např. http://validator.w3.org/check?uri=http://dw.czso.cz/rswj/detail.jsp?prajed_id=2

20. viz http://www.env.cz/www/zamest.nsf/0/72958c66a3890ed7c1256c860031a685

59

Kapitola 7. Závěr

Tato diplomová práce se zaměřila na popis situace v oblasti odpadového hospodářství České republiky a Evropské unie z pohledu organizace podnikající na území České republiky. Cílem byla důkladná analýza legislativních požadavků a souvisejících potřeb podniku a uvedení komplexního řešení v problémové oblasti. V rámci projektu byl navržen a implementován informační systém pro odpadové hospodářství podniku splňující platnou legislativu dle zákona o odpadech, zákona o statistické službě a jejich prováděcích vyhlášek. Funkčnost systému cíleně přesahuje současné povinnosti evidencí odpadového hospodářství za účelem splnění požadavků budoucích legislativních změn, které vycházející z aktuální politiky Evropské unie v oblasti odpadového hospodářství.

Vzhledem k očekávanému způsobu nasazení víceuživatelského informačního systému byla zvolena dvouvrstvá síťová architektura vhodná pro podniková řešení středně velkých organizací. Nemalý důraz byl kladen na bezpečnost systému a důvěryhodnost poskytovaných informací, které podpořil zejména formální návrh statické i dynamické části systému a přesná specifikace rozhraní vrstev použité architektury. Byly stanoveny základy pro vypracování bezpečnostní politiky informačního systému a její začlenění do bezpečnostní politiky organizace. Implementovaný informační systém je připraven pro nasazení v organizaci, buď jako samostatně provozovaný informační systém, nebo jako součást komplexního řešení informačních potřeb organizace. Přesná specifikace aplikačního rozhraní serveru umožňuje použití této části systému například v kombinaci s nadstavbou realizující webové rozhraní či bránou zapouzdřující server do služby architektury SOA1.

Poznámky

1. Service Oriented Architecture (SOA) – architektura informačního systému, kde každá komponenta systému tvoří samostatný objekt s přesně definovaným rozhraním nabízející své služby ostatním částem systému

60

Bibliografie

[Hrebicek99] Jiří Hřebíček, Tomáš Pitner a Jaroslav Ráček, Informační systém pro nakládání s odpady – Odpadový server České republiky, In Tvorba softwaru `99, Ostrava, 1999, strana 109, http://www.osu.cz/katedry/kip/aktuality/sbornik99/pitner.html (duben 2005). [Benes] Bohumil Beneš, Odpadové hospodářství, Verlag Dashöfer, Praha, 2005.

[Kral] Jaroslav Král, Informační systémy – Specifikace, realizace, provoz, SCIENCE, Veletiny, 1998.

[Dobda] Luboš Dobda, Ochrana dat v informačních systémech, Grada Publishing, Praha, 1998.

[Vejnar] Pavel Vejnar a Jaroslava Mlnaříková, Manuál pro vedení evidencí dle § 38, 39 a 40 zákona č. 185/2001 Sb., Výzkumný ústav vodohospodářský T.G. Masaryka, Centrum pro hospodaření s odpady, Praha, 2002, http://www.env.cz/env.nsf/0/bfcc8f50f0a7ae3bc1256cb400373d28 (duben 2005).

[POH CR] Plán odpadového hospodářství České republiky, Ministerstvo životního prostředí, odbor odpadů, Praha, 2003, http://www.env.cz/www/zamest.nsf/0/2c7cb0f9ea5981ffc1256b3c0048ada9 (duben 2005). [CDV] Problematika silniční přepravy nebezpečných věcí, Centrum dopravního výzkumu, Ministerstvo dopravy a spojů, Praha, 2003, http://www.cdv.cz/text/vz/vz1/pvz1_12.pdf (duben 2005).

[Hrebicek04] Jiří Hřebíček a Miroslav Kubásek, Environmentální informační systémy I: Elektronický učební text, Fakulta informatiky Masarykovy univerzity v Brně, Brno, 2004, http://www.fi.muni.cz/~xkubasek/eis/EIS_1.pdf (duben 2005).

[Hrebicek94] Jiří Hřebíček, Informační systémy pro odpadové hospodářství na okresních úřadech, Odpady: časopis pro odpadové hospodářství, Praha, 4. ročník, číslo 6–7/94, stránky 15–18, 1994, 1210-4922. [gov.cz] Portál veřejné správy České republiky – Zákony ČR, Ministerstvo informatiky, 2003–2005, http://portal.gov.cz/wps/portal/_s.155/701 (duben 2005).

[EUR-Lex] Europa EUR-Lex – The portal to European Union law, European Communities, Office for Official Publications of the European Communities, 1998–2005, http://europa.eu.int/eur-lex/ (duben 2005). [PgSQL] PostgreSQL 8.0.2 Documentation, The PostgreSQL Global Development Group, 2005, http://www.postgresql.org/docs/8.0/static/ (duben 2005).

[Walsh] Norman Walsh a Leonard Muellner, DocBook: The Definitive Guide, O'Reilly & Associates, 2005, http://www.docbook.org/tdg/en/html/docbook.html (verze 2.0.11, duben 2005).

61

Příloha A. Atributy objektů logického datového modelu Následující tabulky popisují atributy objektů logického datového modelu definovaného v podkapitole „Logický datový model“ v 4.

Součástí uvedených tabulek je také vyznačení klíčových atributů 1 (zvýrazněny), nepovinných atributů (uvedeny v kulatých závorkách) a atributů jejichž hodnoty jsou omezeny číselníky2 (popsány sémantikou vazby mateřského objektu na objekt číselníku). Případné další omezení k hodnotám jednotlivých atributů udávají jejich poznámky. Tabulka A-1. atributy objektu (#dopravcePrepravyNO) atribut

poradia druh

typ

popis

prirozeneCislo

pořadí dílčí dopravy (klíčový atribut)

druhDopravce

druh dopravce

(spzNavesu)

regZnacka

registrační značka návěsu

(hmotnostVozu)

realneCisloNezaporne

celková hmotnost vozu v tunách

(spzVozu)

(spzPrivesu)

regZnacka

registrační značka vozu

regZnacka

registrační značka přívěsu

(hmotnostNavesu)

realneCisloNezaporne

celková hmotnost návěsu v tunách

(cisloVagonu)

text

číslo vagónu železniční přepravy

(cisloLetZasilky)

text

(hmotnostPrivesu) (cisloVodZasilky)

realneCisloNezaporne

text

celková hmotnost přívěsu v tunách číslo zásilky vodní přepravy

číslo zásilky letecké přepravy

Poznámky: a. v rámci instance objektu (#prepravaNO), viz vazba č. 24 v části „Vazby ideálního datového modelu“ v 3 Tabulka A-2. atributy objektu (#idListNO) id

atribut

kodKatalog

(zmenaKateg) (upresneni)

ID

typ

popis

identifikátor (klíčový atribut)

„položka katalogu (#cKatalog) daného (#idListNO) / 1,1:0,M“

kategorieOdpadu text

změna kategorie odpadu a upřesnění názvu odpadub

62

Příloha A. Atributy objektů logického datového modelu atribut

typ

(adrUNCislo)

(adrObalovaSkup) (adrTrida)

adrCislo

adrObalSk

kód obalové skupiny ADRd

třída ADRc

text

fyzikálně-chemické vlastnosti

text

(nebezpVlast)

text

(mspTechOpatreni)

identifikační číslo ADRc

adrTrida

(adrPoznamka)

(fyzChemVlast)

popis

text

jiná poznámka k ADR nebezpečné vlastnosti

technická bezpečnostní opatření

(mspOchrDychani)

text

ochrana dýchacích orgánů

(mspOchrRuce)

text

ochrana rukou

(mspPozarVybav)

text

protipožární vybavení

(mspOchrOci)

(mspOchrOstatni)

text text

ochrana očí

ochrana ostatních části těla

(nhpLokalizace)

text

lokalizace nehody

(nhpPokyny)

text

další pokyny při nehodě

(nhpPomoc)

text

(nhpTelefon)

text

první pomoc při nehodě

telefonické spojení při nehodě

(udajeToxikolog)

text

toxikologické údaje

(udajeDalsi)

text

další důležité údaje

(udajeEkolog)

text

ekologické údaje

Poznámky: a. pokud je jiná než uvedená v Katalogu odpadů b. nutné zejména pro odpad katalogového čísla …99 c. podle odst. 5 bodu 2002 přílohy A sdělení 159/1997 Sb. d. podle bodu 2302 přílohy A sdělení 159/1997 Sb. Tabulka A-3. atributy objektu (#obcanBezIC) atribut

(RC)

rc

(titulPred)

text

(COP)

(titulZa)

text

text

typ

rodné číslo

popis

číslo občanského průkazu

titul před jménem titul za jménem

63

Příloha A. Atributy objektů logického datového modelu Tabulka A-4. atributy objektu (#odpad) id

atribut

ID

typ

popis

identifikátor (klíčový atribut)

datum

datum

kodNakladani

„způsob nakládání (#cNakladani) s daným (#odpad) / 1,1:0,M“

(naklDoprava)

penize

náklady na dopravu

(naklOstatni)

penize

ostatní náklady

mnozstvi UTS

(naklZneskod)

datum nakládání

realneCisloKladne

množství v tunách, se kterým bylo nakládáno

bool

příznak utajované skutečnosti

penize

náklady na zneškodnění

Tabulka A-5. atributy objektu (#odpadPrepravyNO) atribut

typ

popis

kodKatalo g

„pol. katal. (#cKatalog) daného (#odpadPrepravyNO) / 1,1:0,M“ (klíč. atr.)

mnozstvi

realneCisloKladne

upresneni

text

upřesnění názvu odpadua (klíčový atribut)

množství v tunách, se kterým bylo nakládáno

Poznámky: a. nutné zejména pro odpad katalogového čísla …99 Tabulka A-6. atributy objektu (#osoba) atribut

id

prijmeni

ID

text

typ

identifikátor (klíčový atribut)

příjmení

(jmeno)

text

křestní jména

(COP)

text

číslo občanského průkazu

(RC)

rc

rodné číslo

(titulPred)

text

titul před jménem

(telefon)

text

telefonické spojení

(email)

text

e-mailové spojení

(titulZa) (fax)

text

text

popis

titul za jménem

faxové spojení

64

Příloha A. Atributy objektů logického datového modelu Tabulka A-7. atributy objektu (#povoleni) id

atribut

kodKatalog

ID

typ

popis

identifikátor (klíčový atribut)

„položka katalogu (#cKatalog) daného (#povoleni) / 1,1:0,M“

(zmenaKateg)

kategorieOdpadu

(kodBasilej)

„Basilej. kateg. (#cBasilej) daného (#povoleni) / 0,1:0,M“

(upresneni)

(platnostOd) (platnostDo) (osvedceni)

text

změna kategorie odpadua upřesnění názvu odpadub

datum

datum začátku platnosti

text

údaje osvědčení o odpadu

datum

datum konce platnosti

Poznámky: a. pokud je jiná než uvedená v Katalogu odpadů b. nutné zejména pro odpad katalogového čísla …99 Tabulka A-8. atributy objektu (#povolenyOdpad) atribut

kodKataloga zmenaKateg a

typ

popis

„pol. katal. (#cKatalog) daného (#povolenyOdpad) / 1,1:0,M“ (klíč. atr.) kategorieOdpadu

změna kategorie odpadub (klíčový atribut)

Poznámky: a. v rámci instance objektu (#zarizeni), viz vazba č. 07 v části „Vazby ideálního datového modelu“ v3 b. pokud je jiná než uvedená v Katalogu odpadů Tabulka A-9. atributy objektu (#prepravaNO) id

atribut

ID

kyvadlova

bool

(naklObec)

rc

(cisloDokladu) (naklPSC)

(naklUlice)

(naklTelefon) (vyklObec)

typ

popis

identifikátor (klíčový atribut)

skutečnost, jedná-li se o kyvadlovou přepravu

text

číslo evid. listu přepravy neb. odp.

psc

PSČ místa nakládkya

text

text

text

obec místa nakládkya

ulice místa nakládky a

telefonické spojení místa nakládky a obec místa vykládkyb

65

Příloha A. Atributy objektů logického datového modelu atribut

(vyklPSC)

psc

(vyklUlice)

typ

PSČ místa vykládky

popis

b

text

ulice místa vykládky b

(vyklTelefon)

text

(casDopravce)

casovaZnamka

datum a čas předání příjemci

(pokynyNehoda)

text

pokyny pro případ nehody

(casOdesilatel)

casovaZnamka

(casPrijemce)

casovaZnamka

(dalsiDoklady)

text

telefonické spojení místa vykládky b

datum a čas předání dopravci

datum a čas převzetí příjemcem další doklady či pokyny

Poznámky: a. není-li místo stejné jako adresa odesílatele b. není-li místo stejné jako adresa příjemce

Tabulka A-10. atributy objektu (#provozovna) atribut

(kod)

sberKO

text

typ

bool

popis

číslo provozovny

skutečnost, je-li zapojena do sběru komunálního odpadu

Tabulka A-11. atributy objektu (#sidloFirmy) atribut

typ

popis

(IC)

ico

kodOKEC

„klas. ek. činnosti (#cOKEC) převládající v daném (#sidloFirmy) / 1,1:0,M“

(DIC)

dic

přidělené identifikační číslo organizace

přidělené daňové identifikační číslo organizace

Tabulka A-12. atributy objektu (#sidloObce) atribut

(IC)

(DIC)

ico

dic

typ

popis

přidělené identifikační číslo obce

přidělené daňové identifikační číslo obce

Tabulka A-13. atributy objektu (#skupSkladky) atribut

skupina

a

(kapProjekt) (kapPlan)

typ

skupinaSkladky

realneCisloKladne

realneCisloKladne

popis

skupina skládky (klíčový atribut) b

projektovaná kapacita v tunách plánovaná kapacita v tunách

66

Příloha A. Atributy objektů logického datového modelu atribut

(kapVolna)

typ

realneCisloKladne

volná kapacita v tunách

popis

Poznámky: a. v rámci instance objektu (#zarizeniSkladka), viz vazba č. 25 v části „Vazby ideálního datového modelu“ v 3 b. ve smyslu § 11 odst. 5 vyhlášky 383/2001 Sb. Tabulka A-14. atributy objektu (#subjekt) atribut

id

ID

typ

identifikátor (klíčový atribut)

popis

nazevHlavni

text

obchodní název (u osob příjmení)

(adrObec)

text

obec sídla subjektu

(nazevVedlejsi) (adrPSC)

(adrUlice)

text

vedlejší název (u osob jméno)

psc

PSČ sídla subjektu

text

ulice sídla subjektu

(telefon)

text

kodStatua

„stát (#cStat) adresy daného zahraničního (#subjekt) / 1,1:0,M“

kodZUJa

telefonické spojení na sídlo subjektu

„obec NUTS 5 (#cZUJ) adresy daného tuzemského (#subjekt) / 1,1:0,M“

Poznámky: a. musí být vyplněn právě jeden z atributů kodZUJ nebo kodStatu Tabulka A-15. atributy objektu (#zarizeni) atribut

id

(ikod)

(datumPovoleni)

ID

typ

ikodZarizeni

datum

popis

identifikátor (klíčový atribut)

identifikační kód přidělený příslušným úřadem

datum povolení provozu zařízení

(datumZahajeni)

datum

kodZUJ

„obec NUTS 5 (#cZUJ) adresy daného (#zarizeni) / 1,1:0,M“

(datumUkonceni)

datum

datum skutečného zahájení provozu

datum ukončení provozu, pokud je ukončen

Tabulka A-16. atributy objektu (#zarizeniSklad) atribut

(kapacita) kod

typ

realneCisloKladne

popis

celková kapacita zařízení v tunách

„kód (#cKodSkladu) daného (#zarizeniSklad) / 1,1:0,M“

67

Příloha A. Atributy objektů logického datového modelu Tabulka A-17. atributy objektu (#zarizeniSkladka) atribut

(rokPlanUkonc)

rok

plynOdcerp

bool

(mistniNazev)

typ

popis

rok předpokládaného ukončení provozu

text

v místě běžně užívaný název skládky

skutečnost, je-li skládkový plyn odčerpáván

(plynVyuzivan)

text

způsob využití skládkového plynu

(rekultPlanDo)

datum

předpokládaný termín ukončení rekultivace

rekultProbiha

bool

skutečnost, probíhá-li rekultivace skládky

(uzavrenaDo)

datum

kod

„kód (#cKodSkladky) daného (#zarizeniSkladka) / 1,1:0,M“

(finRezerva)

předpokládané datum opětovného zprovoznění

realneCisloNezaporne

kodKatastru

stav finanční rezervy k 31.12. posledně vykazovaného roku

„katastr (#cKatastr) polohy daného (#zarizeniSkladka) / 1,1:0,M“

Tabulka A-18. atributy objektu (#zarizeniZarizeni) atribut

mobilni

typ

bool

(techPopis)

text

popis

skutečnost, jedná-li se o mobilní zařízení

popis provozované technologie

(techVyrobce)

text

obchodní název výrobce technologie

(odstavenoDo)

datum

předp. termín zprovoznění v případě dočasného odstavení

(rokPlanUkonc)

rok

(kapProjekt)

realneCisloKladne

kod

rok předpokládaného ukončení provozu

projektovaná kapacita za rok v tunách

„kód (#cKodZarizeni) daného (#zarizeniZarizeni) / 1,1:0,M“

Tabulka A-19. atributy objektu (#zodpOsoby) atribut kod

typ

popis

„druh zodp. (#cDruhZodpOsoby) daného (#zodpOsoby) / 1,1:0,M“ (klíč. atr.)

Tabulka A-20. atributy objektu (#zpetnyOdberPrijem) id

atribut

datum

ID

datum

typ

popis

identifikátor (klíčový atribut)

datum uskutečnění zpětného odběru

68

Příloha A. Atributy objektů logického datového modelu atribut

typ

popis

kodVyrobku

„kód výrobku (#cOdbVyrobek) daného (#zpetnyOdberPrijem) / 1,1:0,M“

(kusu)

prirozeneCislo

mnozstvi

(kodPuvodu)a

realneCisloKladne

odebrané množství výrobku v tunách

odebrané množství výrobku v kusech

„původ (#cPuvodOdbVyrobku) daného (#zpetnyOdberPrijem) / 0,1:0,M“

Poznámky: a. pokud nevyplněn kodPuvodu, tak povinná vazba č. 21 v části „Vazby ideálního datového modelu“ v 3 Tabulka A-21. atributy objektu (#zpetnyOdberVydej) id

atribut

datum

ID

typ

popis

identifikátor (klíčový atribut)

datum

datum uskutečnění nakládání s výrobky

realneCisloKladne

předané množství výrobku v tunách

kodVyrobku

„kód výrobku (#cOdbVyrobek) daného (#zpetnyOdberVydej) / 1,1:0,M“

(kusu)

prirozeneCislo

mnozstvi

kodZpusobu

předané množství výrobku v kusech

„zp. nakl. (#cNaklOdbVyrobku) s daným (#zpetnyOdberVydej) / 1,1:0,M“

Poznámky

1. nutno poznamenat, že u slabých objektů zajišťují uvedené klíčové atributy pouze jedinečnost v rámci vlastnících kernel objektů (tedy celý klíč slabých objektů tvoří jejich klíčové atributy a cizí klíč vlastnícího kernel objektu)

2. cizí klíče vazeb na objekty číselníků

69

Příloha B. Specifikace aplikačního rozhraní serveru Uživatelské pohledy

Následující výčet udává specifikaci a sémantiku uživatelských pohledů, které jsou součástí aplikačního rozhraní serveru. Pohledy s přepisovacími pravidly pro přístup k evidenci: odpad_detail:

(numeric povoleni_kod_katalog, char povoleni_zmena_kateg, numeric povoleni_ykod_ basilej, int povoleni_id_subjektu, int povoleni_id_listu_no, bool cfg_vytvorit_povoleni_subjektu, bool cfg_vytvorit_povoleni_partnera) + atributy z tabulky „odpad“ (viz tabulka v příloze A)

Rozšiřuje údaje o dávce odpadu z původní tabulky „odpad“ o údaje o povolení, které při vkládání záznamu používá pro automatické vytvoření povolení (to závisí na proměnných prostředí a hodnotě posledních dvou parametrů vkládaného záznamu, viz podkapitola „Nastavení prostředí“ v 6).

zarizeni_detail:

atributy z tabulky zařízení + společné atributy specializovaných tabulek (varchar zzsa_kod, numeric zzs_kapacita, int zza_rok_plan_ukonc, date zza_odstaveno_do) + atributy specializovaných tabulek, které se nenachází ve výčtu společných atributů, označené jmény s prefixem dle tabulky

Spojuje přístup k evidenci generalizovaného objektu „zarizeni“ a jeho specializací. Pokud je v prefixu názvu atributu jako druhé či některé z dalších písmen písmeno: „z“ pochází atribut z tabulky „zarizeni_zarizeni“, „a“ pochází z „zarizeni_skladka“ a „s“ pochází ze „zarizeni_sklad“. Při práci s evidencí zařízení pomocí tohoto pohledu kontroluje systém distribuci dat do jednotlivých tabulek, případně jejich vytvoření či odstranění.

Pohledy pro kontrolu bilance: odpad_bilance:

(text kod_katalog, text kategorie_nzv, text ykod_basilej, varchar katalog_nzv, varchar pov_upresneni, text pov_nazev, char druh_nakladani, numeric mnozstvi_plus, numeric mnozstvi_minus, numeric mnozstvi_rozdil, int id_subjektu, int id_povoleni)

Bilance množství daného povolení (určuje druh odpadu) při daném druhu nerozšířeného způsobu nakládání. Kromě vlastního množství odpadů obsahuje pohled také rozepsané údaje povolení. odpad_eu_bilance:

(atributy viz předchozí pohled)

Bilance množství daného povolení při daném druhu rozšířeného způsobu nakládání. Podrobněji viz předchozí pohled.

70

Příloha B. Specifikace aplikačního rozhraní serveru odber_bilance:

(char kod_vyrobku, text kod_vyrobku_str, numeric mnozstvi_prijem, numeric mnozstvi_vydej, numeric mnozstvi_rozdil, int kusu_prijem, int kusu_vydej, int kusu_rozdil, int id_subjektu)

Bilance množství a počtu kusů mezi příjmem a výdejem zpětně odebíraných výrobků dle kódu druhu výrobku a vlastnícího subjektu. Pohled obsahuje také plný název druhu výrobku dle příslušného číselníku. Počet kusů je uváděn pouze pokud je tento údaj vyplněn u všech započítaných příjmů a výdejů zpětných odběrů.

Pohledy pro výkazy (uvádíme pouze specifikaci neboť sémantika je známá z podkapitoly „Zpracování výkazů“ v 6): hlaseni_tisk:

(int vykaz_rok, text firma_ic, text firma_nzv, varchar firma_ulice, varchar firma_obec, text firma_psc, text firma_orp, text firma_zuj, text firma_okec, text datum_ddmmyy, text provoz_cislo, text provoz_nzv, varchar provoz_ulice, varchar provoz_obec, text provoz_psc, text provoz_orp, text provoz_zuj, text vyplnil_nzv, varchar vyplnil_telefon, varchar vyplnil_fax, varchar vyplnil_email, text komunalT, text komunalF1, int id_puvodce, int id_subjektu)

hlaseni_odpady_tisk:

(text kod_katalog, text kod_katalog_nzv, text kategorie_nzv, text mnozstvi_plus, text mnozstvi_minus, varchar kod_nakladani, text partner, text uts, varchar osvedceni, int id_subjektu)

prubezna_tisk:

atributy pohledu „hlaseni_tisk“ + (date vykaz_od, date vykaz_do), ale bez atributů (vykaz_rok, komunalT, komunalF)

prubezna_odpady_tisk:

(text kod_katalog, text kategorie_nzv, text ykod_basilej, varchar katalog_nzv, varchar pov_upresneni, date datum, text mnozstvi_nzv, numeric mnozstvi_plus, numeric mnozstvi_minus, varchar kod_nakladani, text partner, int id_subjektu, int id_povoleni)

csu501_tisk:

(int vykaz_rok, text firma_ico, text firma_nzv_a_sidlo, date datum, text vyplnil_nzv, varchar vyplnil_telefon, varchar vyplnil_fax, varchar vyplnil_email, int id_zpravodaje, int id_subjektu)

csu501_020_tisk:

(varchar nzv_odp, text kod_odp, text ktg_odp, char kod_puvod, numeric mnozstvi_celk, int id_zpravodaje, numeric pov_kod_katalog, char pov_zmena_kateg)

csu501_020nakl_tisk:

(varchar kod_nakl, numeric mnozstvi_nakl, int id_zpravodaje, numeric pov_kod_ katalog, char pov_zmena_kateg, char kod_puvod)

csu501_021_tisk:

(text partner_nzv, text partner_ico, text kod_odp, numeric mnozstvi, int id_zpravodaje)

71

Příloha B. Specifikace aplikačního rozhraní serveru csu501_322_tisk:

(text ico, int vykaz_rok, numeric mnozstvi050105, … numeric mnozstvi1601032, int id_zpravodaje)

rocni_odbery_tisk:

(int vykaz_rok, text firma_ic, text firma_nzv, varchar firma_ulice, varchar firma_obec, text firma_psc, text firma_orp, text firma_zuj, text firma_okec, text vyplnil_nzv, varchar vyplnil_telefon, varchar vyplnil_fax, varchar vyplnil_email, text datum_ddmmyy, text za_spravnost_ nzv, int id_povinne_osoby, int id_subjektu)

rocni_odbery_vyrobky_tisk:

(char kod_vyrobku, text kod_vyrobku_str, text mnozstvi_celkem, text mnozstvi_obce, text mnozstvi_prumysl, text mnozstvi_obchod, text zpusob_opakovane, text zpusob_materialove, text zpusob_energeticke, text zpusob_odstraneni, text zpusob_spaleni, text zpusob_ostatni, text zpusob_zustatek, int id_povinne_osoby)

rocni_odbery_partneri_tisk:

(varchar nakladani, text mnozstvi, text partner, char kod_vyrobku, int id_povinne_osoby)

zarizeni_tisk:

atributy pohledu „hlaseni_tisk“ + (int id, varchar umisteni_nzv, text umisteni_zuj, text majitel, varchar kod, numeric id_kod, text mobilniT, text mobilniF, varchar popis_tech, varchar vyrobce_tech, date datum_povoleni, date datum_zahajeni, text rok_plan_ukonc, numeric kap_projekt, date docasne_odstaveno), ale bez atributů (komunalT, komunalF, id_puvodce, id_subjektu)

skladka_tisk:

atributy pohledu „hlaseni_tisk“ + (int id, varchar umisteni_nzv, text umisteni_zuj, text majitel, varchar kod, numeric id_kod, text rok_zahajeni, text rok_plan_ukonc, varchar mistni_nazev, text plyn_odcerp, varchar plyn_vyuzivan, text rekultivace, date docasne_uzavr, text fin_rezerva, text viceskupinova) + atributy (char sX_skupina, numeric sX_kap_projekt, numeric sX_kap_volna, numeric sX_kap_plan) pro X od 1 do 4, ale bez atributů (komunalT, komunalF, id_puvodce, id_subjektu)

sklad_tisk:

atributy pohledu „hlaseni_tisk“ + (int id, varchar umisteni_nzv, text umisteni_zuj, text majitel, varchar kod, numeric id_kod, date datum_zahajeni, text datum_ukonceni, numeric kapacita), ale bez atributů (komunalT, komunalF, id_puvodce, id_subjektu)

zarizeni_povolene_odpady_tisk:

(int id_zarizeni, text kod_katalog, varchar kod_katalog_nzv, text kategorie_nzv)

preprava_tisk:

(varchar cislo_dokladu, text kyvadlova_preprava) + (text odes_nzv, varchar odes_ulice, varchar odes_obec, text odes_psc, varchar odes_telefon, text odes_ic, text odes_zuj) + předchozí skupina atributů s prefixem „prij“ + (varchar nakl_ulice, varchar nakl_obec, text nakl_psc, varchar nakl_telfax, text nakl_zuj, varchar vykl_ulice, varchar vykl_obec, text vykl_psc, varchar vykl_telfax, text vykl_zuj, text pokyny_nehoda, text dalsi_doklady, text predan_dopravci_dne, text

72

Příloha B. Specifikace aplikačního rozhraní serveru predan_dopravci_hodin, text predan_prijemci_dne, text predan_prijemci_hodin, text prijat_dne, text prijat_hodin, int id) + atributy (text doprX_nzv, varchar doprX_ulice, varchar doprX_obec, text doprX_psc, varchar doprX_telefon, text doprX_ic, text doprX_zuj, numeric doprX_druh, varchar doprX_spz_vozu, numeric doprX_hmotnost_vozu, varchar doprX_spz_navesu, numeric doprX_hmotnost_navesu, varchar doprX_spz_privesu, numeric doprX_hmotnost_privesu, varchar doprX_cislo_vagonu, text doprX_cislo_zasilky) pro X rovno 1 a 2

preprava_dopravci_tisk:

(int id_prepravy, int poradi) + pátá skupina atributů v pohledu „preprava_tisk“

preprava_odpady_tisk:

(text od_katalog_nzv, text kod_katalog, numeric mnozstvi, int id_prepravy)

preprava_puvodci_tisk:

(text kod_katalog, text puvodce_nzv, int id_prepravy)

ilno_tisk:

(text kod_katalog_nzv, text kod_katalog, text kategorie_nzv, varchar adr_trida, varchar adr_ obalova_skup, numeric adr_un_cislo, varchar adr_pozn, text puv_nzv, text puv_ic, varchar puv_ ulice, varchar puv_obec, text puv_psc, text puv_osoba, varchar puv_tel, text fyz_chem_vlast, … text udaje_dalsi, text spr_nzv, text spr_ic, varchar spr_ulice, varchar spr_obec, text spr_psc, text spr_osoba, varchar spr_tel, date datum_vyhotoveni, int id)3

dopravce_tisk:

atributy pohledu „hlaseni_tisk“, ale bez atributů (vykaz_rok, komunalT, komunalF, id_puvodce)

Uložené procedury

V této části uvádíme seznam hlaviček uložených procedur, které jsou součástí aplikačního rozhraní serveru, včetně popisu jejich sémantiky. Procedury pro formátování údajů do podoby textového řetězce: •

• • • • • • •

•

text ic_str(numeric ico): formátuje IČO

text psc_str(numeric psc): formátuje poštovní směrovací číslo

text zuj_str(numeric zuj_kod): formátuje kód základní územní jednotky

text id_kod_str(numeric id_kod): formátuje identifik. číslo zařízení pro zpracování odpadů

text kod_katalog_str(numeric katalogovy_kod): formátuje kód odpadu dle Katalogu odpadů

text ykod_basilej_str(numeric ykod): formátuje kód vlastností odpadu dle Basilejské úmluvy

text subjekt_druh_str(char kod_druhu): vrací název druhu subjektu z kódu druhu

text subjekt_nazev_str(char kod_druhu, varchar hlavni_nazev, varchar vedlejsi_nazev): vrací textový řetězec s plným názvem subjektu z kódu jeho druhu a jeho názvů text subjekt_ids_str(char kod_druhu, numeric ico, int id_subjektu_sidla, varchar kod_provozu, varchar rodne_cislo, varchar cislo_op): vrací textový řetězec s úřadními identifikátory subjektu z jeho údajů

73

Příloha B. Specifikace aplikačního rozhraní serveru • •

•

•

• •

•

•

•

• • • •

text subjekt_str(int id): vrací úplný textový popis subjektu z jeho ID

text subjekt_str_popis(int id): vrací úplný textový popis subjektu z jeho ID ve formátu vhodném např. pro majitele zařízení

text subjekt_str_partner(int id): vrací úplný textový popis subjektu z jeho ID ve formátu vhodném pro popis partnera nakládání v Ročním hlášení o nakládání s odpady text osoba_nazev_str(varchar prijmeni, varchar jmeno, varchar titul_pred, varchar titul_za, varchar popis_funkce): vrací plné jméno osoby včetně titulů a popisu funkce ve formátu vhodném pro výkazy

text osoba_str(int id): vrací úplný textový popis osoby z jejího ID

text odpad_kategorie_str(char puvodni, char zmenena): formátuje kategorii odpadu z původní kategorie a změněné kategorie

text odpad_nazev_str(numeric katalogovy_kod, varchar katalogovy_nazev, varchar upresnujici_ nazev): sestaví název odpadu z kódu a názvu dle Katalogu a upřesňujícího názvu

text odpad_mnozstvi_str(real mnozstvi, bool je_kladne): formátuje množství s explicitně vyjádřeným znaménkem

varchar odpad_nakladani(varchar puvodni): převádí rozšířené kódy způsobů nakládání s odpadem na původní kódy text id_list_no_str(int id): vrací úplný textový popis id. listu neb. odp. z jeho ID text povoleni_str(int id): vrací úplný textový popis povolení z jeho ID

text zarizeni_druh_str(char kod_druhu): vrací název druhu zařízení z kódu druhu

text zarizeni_str(int id): vrací úplný textový popis zařízení z jeho ID

•

text odber_vyrobek_str(char): vrací plný název zpětně odebíraného výrobku z jeho kódu

•

void session_start(): inicializuje úložiště proměnných prostředí

Procedury pro práci s proměnnými prostředí: • • • • • •

void session_destroy(): odstraní úložiště proměnných prostředí

text session_putv(varchar name, text value): uloží proměnnou prostředí jména name s hodnotou value

text session_getv(varchar name): přečte proměnnou prostředí jména name

int filter_date_year(): vrací číselnou hodnotu stejnojmenné proměnné prostředí

date filter_date_from(): vrací hodnotu typu datum stejnojmenné proměnné prostředí date filter_date_to(): vrací hodnotu typu datum stejnojmenné proměnné prostředí

Procedury pro ověření, dohledání a přidání povolení odpadů: •

•

•

int povoleni_get_platne(int id_vlastnika, numeric katalogovy_kod, char zmena_kategorie, numeric basilejsky_kod, int id_listu_no, date datum): vrací identifikátor povolení odpadu, které vyhovuje daným podmínkám int povoleni_add(int id_vlastnika, numeric katalogovy_kod, char zmena_kategorie, numeric basilejsky_kod, int id_listu_no): vytvoří povolení daných parametrů a vrátí jeho identifikátor

int povoleni_recheck_from_data(int id_vlastnika, numeric katalogovy_kod, char zmena_kategorie, numeric basilejsky_kod, int id_listu_no, date datum, bool vytvorit, text komu): pokud existuje povolení vyhovující zadaným podmínkám platné k danému datu, tak vrací jeho identifikátor, v

74

Příloha B. Specifikace aplikačního rozhraní serveru opačném případě se ho pokusí vytvořit automaticky pokud jsou splněny podmínky nastavené proměnnými prostředí, případně navíc nastaven příznak vytvorit; parametr komu je buď „Subjekt“ nebo „Partner“, a je použit pro zjištění kontextu volání procedury •

int povoleni_recheck_from_povoleni(int id_vlastnika, int id_povoleni, date datum, bool vytvorit, text komu): pokud existuje povolení vlastníka platné k danému datu a shoduje se v základních údajích se zadaným povolením, tak vrátí identifikátor povolení vlastníka, v opačném případě se ho pokusí vytvořit (viz předchozí procedura)

Procedury převodu odpadů do nového roku a korekce bilancí: •

•

•

•

•

•

•

int odpad_prevod_zustatku(smallint stary_rok, int id_subjektu, bool cela_firma, bool vytvorit_ povoleni): převede uskladněné odpady starého roku (nakládání xN5) na zůstatky v novém roce (nakládání C00) s volitelným vytvořením povolení; pokud je zadán subjekt, tak se převádí pouze jeho odpady (případně celé firmy), jinak se převádí odpady všech subjektů v databázi

int odpad_dorovnat_odpady_povoleni(int id_povoleni, varchar druh_nakladani, varchar nakladani, date datum, bool uts, int id_partnera, bool vytvorit_povoleni_partnera): vyrovná bilanci odpadů daného povolení a druhu daným nakládáním s danými údaji

int odpad_dorovnat_eu_odpady_povoleni(int id_povoleni, varchar druh_nakladani, varchar zbytek_nakladani, date datum, bool uts, int id_partnera, bool vytvorit_povoleni_partnera): odpovídá funkčnosti předchozí procedury, ale pracuje s rozšířenými kódy nakládání int odpad_dorovnat_odpady_subjektu(int id_subjektu, bool kladna, varchar nakladani, date datum, bool uts, int id_partnera, bool vytvorit_povoleni_partnera): vyrovná kladnou nebo zápornou (podle parametru kladna) bilanci odpadů daného subjektu daným druhem nakládání s danými údaji int odpad_dorovnat_eu_odpady_subjektu(int id_subjektu, bool kladna, varchar nakladani, date datum, bool uts, int id_partnera, bool vytvorit_povoleni_partnera): odpovídá funkčnosti předchozí procedury, ale pracuje s rozšířenými kódy nakládání int odber_dorovnat_odbery_vyrobku(int id_subjektu, char kod_vyrobku, date datum, char kod_ puvodu, char kod_zpusobu, int id_partnera): vyrovná bilanci zpětného odběru daných výrobků u daného subjektu podle zadaných kritérií

int odber_dorovnat_odbery_subjektu(int id_subjektu, bool kladna, date datum, char kod_puvodu, char kod_zpusobu, int id_partnera): vyrovná kladnou nebo zápornou (podle parametru kladna) bilanci zpětného odběru všech druhů výrobků daného subjektu podle zadaných kritérií

Procedury pro hromadnou úpravu evidence: •

• •

•

• •

int move_povoleni_subjektu(int odkud, int kam, bool jen_neprazdne): přesune povolení včetně jejich odpadů mezi dvěma subjekty int move_odpady_povoleni(int odkud, int kam): přesune všechny odpady mezi dvěmi povoleními

int move_odber_prijmy_subjektu(int odkud, int kam): přesune příjmy zpětných odběrů mezi dvěma subjekty int move_odber_vydeje_subjektu(int odkud, int kam): přesune výdeje zpětných odběrů mezi dvěma subjekty

int move_zarizeni_subjektu(int odkud, int kam): změní provozovatele zařízení pro zpracování odpadů

int move_prepravy_no_subjektu(int odkud, int kam): přesune přepravy neb. odpadů mezi dvěma evidujícími subjekty

75

Příloha B. Specifikace aplikačního rozhraní serveru •

• •

•

•

• • • • • • •

• •

•

•

•

•

• •

•

•

int move_id_listy_no_subjektu(int odkud, int kam): přesune identifikační listy nebezpečných odpadů mezi dvěma subjekty int move_zodp_osoby(int odkud, int kam): přesune všechny zodpovědnosti z jedné osoby na druhou

int copy_povoleni_subjektu(int odkud, int kam, bool jen_neprazdne, bool jen_vobdobi, bool bez_ duplicit): zkopíruje povolení odpadů jednoho subjektu na druhý subjekt, volitelně jen nová povolení int change_odpadu_partnera(int odkud, int kam): změní partnera nakládání u všech dávek odpadů z jednoho subjektu na druhý int change_odpadu_zarizeni(int odkud, int kam): změní zařízení v dávkách odpadů z jednoho na druhé int change_odber_prijmu_partnera(int odkud, int kam): změní partnera příjmu zpět. odběrů

int change_odber_vydeju_partnera(int odkud, int kam): změní partnera výdeje zpět. odběrů

int change_zarizeni_majitele(int odkud, int kam): změní majitele všech zařízení

int change_prepravy_no_odesilatel(int odkud, int kam): změní odesílatele přeprav neb. odp.

int change_prepravy_no_prijemce(int odkud, int kam): změní příjemce přeprav neb. odp.

int change_prepravy_no_dopravce(int odkud, int kam): změní dopravce přeprav neb. odp.

int change_prepravy_no_puvodce(int odkud, int kam): změní původce přepravovaných nebezpečných odpadů int change_id_listu_no_puvodce(int odkud, int kam): změní původce odpadu v identifikačních listech

int change_id_list_no_v_odpadech(int odkud, int kam): změní id. list neb. odpadů z jednoho id. listu na druhý stejného druhu

int delete_povoleni_subjektu(int koho, bool jen_neprazdne): smaže všechny povolení odpadů daného subjektu, volitelně jen povolení bez dávek odpadů int delete_odpady_subjektu(int koho, bool jen_vobdobi): smaže všechny dávky odpadů daného subjektu

int delete_odber_prijmy_subjektu(int koho, bool jen_vobdobi): smaže všechny příjmy zpětných odběrů daného subjektu int delete_odber_vydeje_subjektu(int koho, bool jen_vobdobi): smaže všechny výdeje zpětných odběrů daného subjektu int delete_zarizeni_subjektu(int koho): smaže všechna zařízení daného subjektu

int delete_prepravy_no_subjektu(int koho, bool jen_neprazdne): smaže všechny přepravy neb. odpadů daného subjektu, volitelně jen přepravy s prázdným seznamem přepravovaných odpadů int delete_id_listy_no_subjektu(int koho): smaže všechny identifikační listy nebezpečných odpadů daného subjektu int delete_zodp_osoby(int ktere): odstraní všechny zodpovědnosti dané osoby

Poznámky

1. atribut „komunalT“ (resp. „komunalF“) nabývá hodnoty „X“, pokud je (resp. není) provozovna zapojena do sběru komunálního odpadu v obci

76

Příloha B. Specifikace aplikačního rozhraní serveru 2. zkrácený výčet všech atributů udávajících množství podle přílohy 322 Ročního výkazu o odpadech Odp 5-01 3. atributy s prefixem „puv“ označují údaje původce odpadu a atributy s prefixem „spr“ označují subjekt zodpovědný za správnost

77

Příloha C. Instalace

V této příloze popíšeme instalaci jednotlivých částí informačního systému pro odpadové hospodářství podniku a jejich zprovoznění. Následující text předpokládá dostupnost CD, které je přílohou této práce (viz příloha F).

Instalace serveru a databáze

Distribuci aktuální verze1 databázového serveru PostgreSQL získáme z FTP serveru2 PostgreSQL Global Development Group. Pokud není pro náš operační systém dostupná přímo distribuce binární verze serveru 3, musíme získat distribuci zdrojových kódů, kterou poté rozbalíme a dle přiložených pokynů zkompilujeme a nainstalujeme. V následujícím textu budeme používat pro zápis adresářové cesty jednoduché lomítko v souladu s prostředím operačních systémů typu UNIX (uživatelé jiných operačních systému nechť si laskavě v popisech upraví adresářové cesty podle pravidel konkrétního operačního systému).

Dále tedy předpokládejme, že máme úspěšně nainstalovaný databázový server PostgreSQL, který zatím není spuštěný. Před prvním spuštěním databázového serveru musíme inicializovat úložiště databází (pokud to již neprovedl instalační program): 1.

2. 3. 4.

vytvoříme uživatele, pod kterým má běžet databázový server (uživatel musí mít v operačním systému omezená oprávnění, tj. nemůže to být super-uživatel) – pro další postup předpokládejme, že název vytvořeného uživatele je „postgres“,

přesuneme se do adresáře, kde byl nainstalován databázový server, a uživateli „postgres“ přidělíme všechna práva na tento adresář a jeho obsah, včetně všech jeho podadresářů a souborů, přihlásíme se jako uživatel „postgres“ a zbytek instalace provádíme pod jeho oprávněním a z výše uvedeného adresáře,

spustíme příkaz, který inicializuje úložiště databází v lokálním adresáři ./data s českým národním prostředím a znakovou sadou UNICODE v kódování UTF-8 a který vytvoří databázového superuživatele se jménem „postgres“: ./bin/initdb -D ./data -E UNICODE --locale=czech -A md5 -U postgres -W

5. 6.

(na výzvu zvolíme nové heslo super-uživatele vytvářeného úložiště databází)

pro povolení vzdáleného přístupu k serveru z libovolné sítě modifikujeme soubor

./data/pg_hba.conf přidáním následujícího řádku: host all all 0.0.0.0/0 md5

nyní spustíme databázový server příkazem4:

./bin/pg_ctl start -w -p ./bin/postmaster -D ./data -o "-i"

Pokud používáme operační systém Windows, můžeme server nainstalovat jako automaticky spouštěnou službu jména „PostgreSQL“ pod oprávněním uživatele „postgres“ přihlašovaného s heslem „heslo“ (před názvem adresáře data musí být úplná cesta k jeho umístění; příkaz má být zapsán na jednom řádku): .\bin\pg_ctl.exe register -N PostgreSQL -U postgres -P "heslo" -D "plná_cesta_k_adresáři_data" -o "-i" && net start PostgreSQL

78

Příloha C. Instalace Po úspěšném spuštění serveru můžeme přistoupit k vytvoření databáze pro informační systém pomocí předpřipravených dávek SQL příkazů. Předpokládejme, že obsah CD s distribucí informačního systému pro odpadové hospodářství podniku je přístupný v adresáři /cdrom a že jsou následující příkazy spouštěny na stroji, na kterém běží databázový server5. Přesuneme se do podadresáře ./bin v adresáři, kde je nainstalován server PostgreSQL, a postupujeme takto: 1.

2. 3. 4. 5.

spustíme dávku příkazů pro vytvoření nové databáze pojmenované „piso“:

./psql -d template1 -f /cdrom/db/database.sql -U postgres -W -v db=piso

do nové databáze nainstalujeme interpret procedurálního jazyka PL/pgSQL:

./createlang -d piso -U postgres -W plpgsql

spustíme dávku příkazů pro instalaci vlastní datové struktury a aplikační logiky serveru informačního systému: ./psql -d piso -f /cdrom/db/install.sql -U postgres -W

spustíme dávku příkazů pro import předpřipravených dat číselníků:

./psql -d piso -f /cdrom/db/cisel.sql -U postgres -W -v cd=/cdrom/db

a spustíme poslední dávku příkazů, která vytvoří v databázi uživatelské skupiny odpovídající rolím aktérů systému a přidělí jim patřičná oprávnění: ./psql -d piso -f /cdrom/db/groups.sql -U postgres -W

Nyní můžeme spustit a nakonfigurovat klienta a přihlásit se v jeho modulu „Správa databáze“ jako uživatel „postgres“. Tam vytvoříme další požadované uživatele a přiřadíme jim odpovídající uživatelské role a počáteční hesla. Jednoho uživatele pojmenovaného „piso“ s počátečním heslem „heslo“, který má neomezený přístup k datům informačního systému, můžeme vytvořit také spuštěním dávky příkazů: ./psql -d piso -f /cdrom/db/first-user.sql -U postgres -W

Instalace podpory pro zabezpečení spojení mezi serverem a klientem pomocí SSL je popsána v části přílohy „Prosazování bezpečnostních opatření v informačním systému“ v E.

Instalace klienta

Klient informačního systému pro odpadové hospodářství podniku je aplikace primárně určená pro operační systém Microsoft Windows. Aplikace není závislá na prostředí operačního systému, a proto nevyžaduje instalaci a funguje i po prostém zkopírování používaných souborů. Klienta systému zprovozníme takto: 1. 2. 3.

rozbalíme ZIP archiv s distribucí klientské části informačního systému do vybraného umístění, případně spustíme samorozbalovací archiv a postupujeme podle zobrazených pokynů, po rozbalení archivu s distribucí vznikne na zvoleném místě složka PISO s aplikací v souboru

piso.exe, kterou spustíme,

v nabídce vybereme „Nastavení – Konfigurace“ a v zobrazeném dialogu správně vyplníme doménové jméno či IP adresu stroje, na kterém běží databázový server, a použitý port a název vytvořené databáze,

79

Příloha C. Instalace 4. 5. 6.

Migrace

pokud ještě neexistují žádní uživatelé informačního systému, tak je vytvoříme pomocí volby v dialogu přístupném z nabídky „Nastavení – Správa databáze“ po zadání jména a hesla superuživatele databáze,

pomocí volby „Přihlásit“ v nabídce „Databáze“ a zadáním uživatelského jména a odpovídajícího hesla provedeme připojení a přihlášení k databázi, klient je připraven a můžeme začít pracovat s informačním systémem.

Informační systém pokrývá převážně celou legislativně vymezenou oblast odpadového hospodářství podniku. Ideálním okamžikem pro produkční nasazení systému je přelom kalendářního roku, kdy se začínají vést nové evidence a ze starého období se převádějí pouze zůstatky na skladu (z uzávěrky evidence).

Situace přechodu na používání systému je obtížnější, pokud potřebujeme do nového systému převést větší množství dat z evidence vedené jinými prostředky. Díky přístupu k systému pomocí aplikačního rozhraní serveru je možné importovat data přímo do databáze bez použití standardního uživatelského rozhraní. V následujícím textu popíšeme import dat z „papírové“ a elektronické evidence pomocí formátu CSV.

Pokud máme data pouze v „papírové“ podobě, je nutné data převést do elektronické podoby. Zde se ve většině případů nevyhneme prostému opisování údajů použitím uživatelského rozhraní klienta systému. Alternativní způsob řešení je přepsání dat do nějakého tabulkového procesoru se strukturou sloupců podobnou tabulkám či pohledům aplikačního rozhraní serveru, přičemž část dat zadáváme pomocí standardního uživatelského rozhraní a do tabulkového procesoru zapíšeme na jejich místo pouze identifikátor (ID) odkazovaných záznamů vzniklých při zadaní dat. Poté postupujeme podobně, jako při dále popsaném importu z elektronické podoby. V případě, že data evidencí máme v elektronické podobě, upravíme je pomocí nějakého tabulkového procesoru, tak, aby měly sloupce podobnou strukturu jako tabulky aplikačního rozhraní serveru. Pokud je možné některá data vyjádřit odděleně (např. partnera nakládání), vyjmeme je do samostatné tabulky nebo zadáme přes standardní uživatelské rozhraní a na jejich místo doplníme odkazující identifikátor (ID). V ideálním případě, kdy jsou původní data uložena v databázi přístupné pomocí dotazovacího jazyka SQL, můžeme vhodně formulovat SQL dotaz pro vyjádření původních dat ve struktuře tabulek našeho systému.

Takto připravené tabulky s daty můžeme uložit ve formátu CSV a importovat do systému pomocí nástroje psql z distribuce databázového serveru. Při pořadí importu je nutno dodržovat závislosti importovaných záznamů a případně inicializovat úložiště dočasných proměnných prostředí. Například CSV soubor import.csv importujeme do databáze „piso“ běžící na stroji doménového jména pgserver pomocí tabulky „odpad“ aplikačního rozhraní jako uživatel „piso-admin“ spuštěním: ./psql -d piso -U piso-admin -W -h pgserver

a zadáním následující posloupnosti příkazů6 (zde předpokládáme, že původní data CSV souboru jsou uložena v kódování Windows-1250): select session_start(); \encoding win-1250 \copy odpad(datum, ...) from 'import.csv' delimiter ';' null '' csv

80

Příloha C. Instalace Opačný směr migrace, tj. export dat informačního systému pro odpadové hospodářství podniku, lze realizovat sestavením vhodných dotazů podle exportního formátu a uložením získaných dat do pomocných tabulek, které poté exportujeme do CSV souborů. Například kompletní obsah tabulky „odpad“ můžeme vyexportovat z databáze do CSV souboru export.csv následujícím příkazem7 nástroje psql: \copy odpad(datum, ...) to 'export.csv' delimiter ';' null '' csv

Import a export dat uživatelských pohledů lze realizovat například pomocí příkazu SELECT-INSERT a dočasných tabulek, nebo použitím speciálních nástrojů8.

Poznámky

1. informační systém vyžaduje PostgreSQL verze 8.0 a vyšší (této verze musí být také všechny nástroje z distribuce databázového serveru používané při instalaci) 2. ftp://ftp.postgresql.org/pub/

3. pro operační systém Microsoft Windows doporučujeme použít instalátor z ftp://ftp.postgresql.org/pub/win32/

4. parametr -i zpřístupní databázový server také vzdáleným klientům přes síťový protokol TCP/IP

5. při vzdáleném přístupu použijeme navíc parametr -h následovaný jménem databázového stroje a případně parametr -p následovaný číslem portu

6. v závorkách za názvem tabulky musí být úplný seznam sloupců importovaného CSV souboru

7. v závorkách za názvem tabulky musí být úplný seznam sloupců exportovaných do CSV souboru 8. např. EMS PostgreSQL Data Import&Export dostupný na http://www.sqlmanager.net/products/postgresql/

81

Příloha D. Provoz

Provoz informačního systému pro odpadové hospodářství podniku zahrnuje řízení přístupu, v souladu s opatřeními bezpečnostní politiky organizace a informačního systému, a zabezpečení systému proti ztrátě kritických dat, včetně garance jejich stálé dostupnosti. Tato příloha poskytuje stručný přehled základních nástrojů a postupů pro bezproblémový provoz systému.

Řízení přístupu

Následující SQL příkazy umožňují v uvedeném pořadí vytvořit a zrušit uživatelskou skupinu: CREATE GROUP jmeno_skupiny; DROP GROUP jmeno_skupiny;

Podobnými příkazy můžeme vytvořit či odstranit uživatele – v tom případě použijeme místo klíčového slova GROUP slovo USER. Při vytváření uživatele lze v SQL příkazu za jméno uživatele uvést klíčová slova CREATEUSER (uživatel má v databázi neomezená oprávnění, tj. role administrátor v našem systému), CREATEDB (uživatel smí vytvářet databáze) a PASSWORD 'heslo' (uživatel bude mít nastaveno počáteční heslo). Níže uvedené SQL příkazy v daném pořadí umožňují přidání a odebrání uživatele ze skupiny: ALTER GROUP jmeno_skupiny ADD USER jmeno_uzivatele; ALTER GROUP jmeno_skupiny DROP USER jmeno_uzivatele;

Databázový server PostgreSQL má poměrně rozsáhlý seznam druhů přístupových práv k objektům databáze. Řídit přistup je umožněno k databázi, tabulkám, uživatelským pohledům a uloženým procedurám, přičemž seznam možných oprávnění1 k objektu je závislý na jeho druhu. Následující příkaz umožňuje přidělit dané oprávnění dané skupině k danému objektu (odebrání oprávnění docílíme nahrazením klíčového slova GRANT slovem REVOKE): GRANT druh_opravneni ON jmeno_objektu TO GROUP jmeno_skupiny;

Pro úplnost je třeba poznamenat, že seznam všech uživatelů je uložen v systémové tabulce pg_user a seznam všech uživatelských skupin v tabulce pg_group. K uvedeným tabulkám lze přistupovat pomocí standardních příkazů jazyka SQL. Uživatel může změnit své přístupové heslo příkazem SQL:

ALTER USER jmeno_uzivatele WITH PASSWORD 'nove heslo'

Záloha a obnova dat

Pro zálohování dat lze využít např. nástroje serveru PostgreSQL pg_dump a psql. Následující příklad demonstruje použití zmíněných nástrojů pro jednorázovou zálohu a úplnou obnovu databáze: pg_dump jmeno_databaze > soubor_zalohy psql -d jmeno_databaze -f soubor_zalohy

82

Příloha D. Provoz Dalším způsobem zálohování je vytvoření fyzické kopie adresáře, ve kterém server uchovává údaje o databázích a jejich datech. Výhoda tohoto řešení spočívá především v nezávislosti na konkrétních prostředcích databázového serveru PostgreSQL, a tedy možnosti použít standardní nástroje pro zálohu souborového systému. Hlavní nevýhodou je skutečnost, že takto nelze zálohovat jednotlivé databáze, ale pouze celý obsah databázového serveru. Ve většině případů2 je také nutné mít databázový server po dobu kopie adresáře zastavený. Konkrétní postup vytvoření zálohy pomocí fyzické kopie a její obnovy je silně závislý na použitém zálohovacím nástroji a souborovém systému, a proto ho zde nebudeme podrobněji popisovat. Pro zálohování kompletního databázového serveru bez přerušení jeho funkčnosti lze využít tzv. „write ahead log“ (WAL), což je chronologicky utříděný seznam začátků, průběhů a konců databázových transakcí. WAL bývá standardně využíván pro obnovení integrity databáze po neočekávaném ukončení databázového stroje (např. v důsledku selhání hardwaru). Server PostgreSQL umožňuje stanovit příkaz, který se spustí při každém uložení souboru s WAL na pevný disk a který například zkopíruje tento soubor na záložní souborový server. Samotná záloha spočívá ve vytvoření kompletní jednorázové zálohy (např. pomocí pg_dump) a poté v průběžném zálohování souborů s WAL, které obsahují historii změn od kompletní zálohy (jsou to tzv. inkrementální zálohy). Takto lze zálohovat databázový server bez omezení jeho funkčnosti. Zájemce o podrobný popis odkazujeme na [PgSQL].

Pokud je vyžadována stálá dostupnost databází i během kritických výpadků databázového serveru, je nutné použít tzv. „on-line replikaci dat“ ze zdrojového serveru na server záložní. Cílem řešení je udržovat v každém okamžiku obraz obsahu databází záložního serveru plně synchronizovaný s obsahem databází primárního serveru. V případě kritického výpadku primárního databázového serveru (např. požár v dané lokalitě) dojde pouze k přesměrování požadavků na záložní server pomocí standardních síťových technologií3. Výhodou je velmi vysoká odolnost systému vůči výpadkům a spolehlivá eliminace rizik i v případě rozsáhlých hrozeb. Pro řešení on-line replikace dat databázového serveru PostgreSQL existuje mnoho nástrojů, jako zástupce uveďme například PostgreSQL Replicator4 či nadějný projekt Slony-I5.

Poznámky

1. použitelné jsou následující oprávnění: SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCES, TRIGGER, CREATE, TEMPORARY, EXECUTE, USAGE, a ALL PRIVILEGES (všechna oprávnění) – podrobněji viz http://www.postgresql.org/docs/8.0/static/privileges.html

2. na souborových systémech, které umožňují vytvoření konzistentní kopie datové oblasti, může být fyzická kopie adresáře databázového serveru provedena také „za běhu“ serveru

3. přesměrování požadavků může být realizováno např. převzetím IP adresy a doménového jména zdrojového serveru ve spolupráci se směrovači sítě

4. PostgreSQL Replicator, http://pgreplicator.sourceforge.net/ 5. Slony-I, http://gborg.postgresql.org/project/slony1/

83

Příloha E. Bezpečnost

Informační systém pro odpadové hospodářství podniku využívá pro komunikaci mezi prvky architektury systému firemní počítačovou síť. Po síti se tedy pohybují citlivá data a prostřednictvím sítě se též realizuje počáteční autentizace komunikujících stran. Z těchto důvodu je třeba stanovit bezpečnostní politiku splňující nejen nároky na ochranu samotného informačního systému, ale také nároky na ochranu komunikace v síťovém prostředí a ochranu jednotlivých prvků sítě. Je nezbytné, aby navržená bezpečnostní politika firemních informačních technologií byla na vyšší úrovni podporována celkovou bezpečnostní politikou organizace.

V této příloze se budeme zabývat bezpečnostní politikou informačního systému a počítačové sítě, na které je provozován. Bezpečnostní politiku zaměříme na ochranu dat informačního systému1 z hlediska důvěrnosti a integrity (ochranou z hlediska dostupnosti se částečně zabývá příloha D). Vycházet budeme především z [Dobda], kam také odkazujeme zájemce o další informace.

Hrozby a rizika

Analýzou zranitelných míst obecného informačního systému z dané oblasti a odhady jejich rizik byl sestaven následující seznam hrozeb seřazený sestupně podle očekávaných škod:

1. ztráta či narušení integrity evidovaných dat v kritickém období cizí osobou2 – důsledkem je porušení legislativy neodevzdáním zákonem stanovených výkazů, což může vést až k pokutě od příslušných úřadů 2. ztráta či narušení integrity evidovaných dat v kritickém období pověřenou osobou

3. odcizení či zfalšování identity a přístupových práv – v důsledku vede k obtížně zjistitelnému narušení důvěrnosti a integrity dat

4. narušení důvěrnosti dat odposlechem komunikace – může vést ke ztrátě konkurenční výhody či pokutě od Úřadu pro ochranu osobních údajů 5. ostatní hrozby (fyzické ohrožení, živelné katastrofy, atd.)

Opatření vedoucí ke snížení rizik a způsobených škod

Při snižování rizik se zaměříme především na preventivní opatření doplněné o vhodné detekční mechanismy. Na bezpečnosti se významně podílí také systém záloh nezbytný pro havarijní plán a úspěšnou obnovu dat systému s minimalizací škod (viz první část přílohy D).

Hrozbě ztráty či narušení integrity evidovaných dat v kritickém období cizí osobou budeme čelit vhodnou bezpečnostní politikou organizace (přístup do objektu, identifikace zaměstnanců, atd.) a povinnou autentizací uživatelů systému. Tyto opatření nám bohužel nepomohou proti útoků „zevnitř“ organizace, tj. úmyslným útokům zaměstnanců pověřených k práci s informačním systémem. Toto riziko budeme eliminovat omezením oprávnění uživatelů v rámci řízení přístupu (podrobněji viz druhá část přílohy D) a účtováním provedených změn.

Odcizení či zfalšování identity a přístupových práv se vyhneme šifrováním komunikačních spojení mezi částmi architektury systému a netriviálním protokolem autentizace uživatelů. Tato opatření nám také

84

Příloha E. Bezpečnost zajistí ochranu proti narušení důvěrnosti dat odposlechem komunikace. Nebytnou součástí výše uvedených opatření je také školení uživatelů systému zaměřené na bezpečnost.

Vliv ostatních hrozeb a jejich riziko můžeme snížit stanovením a dodržováním bezpečnostní politiky chodu organizace.

Prosazování bezpečnostních opatření v informačním systému

Způsob autentizace uživatelů databázového serveru PostgreSQL je možné nastavit v konfiguračním souboru pg_hba.conf, který je umístěn v adresáři úložiště databází. Proces autentizace lze konfigurovat podle typu spojení (lokální, vzdálené a vzdálené s použitím SSL), IP adresy klienta, jména databáze a databázového uživatele, a podle použité autentizační metody.

V našem případě použijeme autentizační metodu využívající principu sdíleného tajemství, realizovanou protokolem „výzva-odpověď“, který používá hash-funkci MD5. Tento protokol je odolný proti odposlechu hesla a proti útoku „přehráním“ zaznamenané komunikace. Dále povolíme vzdálený typ spojení, zabezpečený pomocí Secure Socket Layer (SSL), a server dostupný z libovolné adresy pro každého uživatele a databázi. Konkrétní zápis záznamu v souboru pg_hba.conf, kterým zapíšeme výše uvedené podmínky, je uveden v první části přílohy C. Implementaci vrstvy SSL na síťovým protokolem TCP/IP realizuje v databázovém serveru PostgreSQL knihovna OpenSSL. Vrstva SSL provádí šifrování dat mezi aplikací a transportní vrstvou síťového protokolu, a zaručuje důvěrnost a integritu přenášených dat včetně jednostranné či oboustranné autentizace komunikujících stran. Šifrované SSL spojení se vytvoří po navázání TCP spojení, ověření identity komunikujících stran pomocí asymetrické kryptografie a stanovení klíče relace pro šifrování vlastního spojení použitím symetrické kryptografie. Z výše uvedených důvodů musí být určena dvojice asymetrických klíčů serveru, které se použijí pro prokázání identity serveru a ustanovení symetrického klíče relace. Skutečnost, že daný klíč patří dané autoritě, se kterou chceme komunikovat, potvrzuje tzv. certifikát, jehož pravost je prokazatelná důvěryhodnou autoritou3. Pro vytvoření uvedeného certifikátu využijeme nástrojů OpenSSL4:

1.

následujícími příkazy vygenerujeme novou dvojici klíčů asymetrické kryptografie, dešifrujeme ji a připravíme žádost o vystavení certifikátu: openssl req -new -text -out server.req; openssl rsa -in privkey.pem -out server.key

2. 3. 4.

(na výzvu „Common Name“ musíme zadat doménové jméno stroje, na kterém běží databázový server) vytvořené soubory předáme certifikační autoritě a necháme si vystavit certifikát, případně si vytvoříme certifikát sami5 následujícím příkazem:

openssl req -x509 -in server.req -text -key server.key -out server.crt

soubory server server.key a server.crt umístíme do adresáře úložiště databází a souboru server.key nastavíme přístupová práva, která znemožní přístup jinému uživateli, než je uživatel spouštějící databázový server,

v konfiguračním souboru postgresql.conf, který se nachází v úložišti databází, aktivujeme podporu SSL přidáním následujícího řádku do oddílu „Security & Authentication“:

85

Příloha E. Bezpečnost ssl = true

Nyní je certifikát nainstalován a po restartu databázového serveru může být použit pro ustanovení SSL spojení.

Posledním bezpečnostním prvkem je účtování práce uživatelů s databázovými objekty. Při implementaci systému bylo pomocí spouští realizováno ukládání data poslední změny klíčových objektů evidence a ukládání názvu uživatele, který změnu provedl. Pro podrobnější účtování lze implementovat další rozšíření uvedených spouští nebo použít standardní nástroje serveru PostgreSQL.

Poznámky

1. specializací analýzy na ochranu dat se vyhneme nutnosti identifikace a ohodnocení aktiv v rámci bezpečnostní politiky

2. kritické období je zde časový úsek před zákonem stanovenou lhůtou, nedostatečný pro včasnou obnovu původních dat

3. certifikát je v podstatě elektronicky podepsaný veřejný klíč společně s údaji autority, které patří, přičemž důvěryhodnost certifikátu je zaručena jeho elektronickým podpisem certifikační autoritou (Certificate Authority, CA) 4. OpenSSL Project: The Open Source toolkit for SSL/TLS, viz http://www.openssl.org/

5. uvedeným způsobem vznikne certifikát podepsaný sám sebou, tzv. „Self–signed Certificate“

86

Příloha F. Obsah přiloženého CD

Součástí této práce je také disk CD, který je ve formátu Rock Ridge s rozšířením Joliet. Disk obsahuje následující adresářovou strukturu: /db:

SQL skripty pro instalaci databázové a aplikační části serveru a dat číselníků

/docs:

text diplomové práce a uživatelské příručky (DocBook, PDF, …), texty zákonů, vyhlášek a ostatní dokumenty

/models:

návrhové modely informačního systému pro odpadové hospodářství podniku

/server:

distribuce databázového serveru PostgreSQL verze 8.0 pro různé operační systémy

/server/instant:

funkční verze serveru s předpřipravenou ukázkovou databází IS

/server/src:

distribuce zdrojových kódů db. serveru PostgreSQL verze 8.0

/client:

distribuce klienta informačního systému pro odpadové hospodářství podniku

/client/src:

zdrojové kódy klienta informačního systému

87

Rejstřík

88