Podniková informatika

��

��

��

Edice Management v informaèní spoleènosti Edièní rada: Prof. Ing. Josef Basl, CSc. – Vysoká škola ekonomická v Praze – pøedseda Ing. Kateøina Drongová – Grada Publishing, a.s. – místopøedseda Prof. Ing. Jan Ehleman, CSc. – Technická univerzita Liberec Doc. RNDr. Josef Hynek, MBA, Ph.D. – Univerzita Hradec Králové JUDr. Martin Maisner – kanceláø ROWAN LEGAL Doc. Ing. Karol Matiaško, CSc. – Žilinská univerzita v Žilinì Prof. RNDr. Jaroslav Pokorný, CSc. – MFF UK v Praze Doc. Ing. Jan Pour, CSc. – VŠE v Praze Doc. Ing. Karel Richta, CSc. – FEL ÈVUT v Praze Doc. Ing. Petr Sodomka, Ph.D. – UTB ve Zlínì Doc. Ing. Milena Tvrdíková, CSc. – VŠB-TU Ostrava Prof. Ing. Ivan Vrana, DrSc. – Èeská zemìdìlská univerzita v Praze

Ing. Libor Gála Doc. Ing. Jan Pour, CSc. Ing. Zuzana Šedivá

Podniková informatika 2., pøepracované a aktualizované vydání © Grada Publishing, a.s., 2009 Cover Photo © profimedia.cz Vydala Grada Publishing, a.s., U Prùhonu 22, Praha 7 tel.: +420 220 386 401, fax: +420 220 386 400, jako svou 3750. publikaci Vytiskla tiskárna PBtisk, s.r.o. Dìlostøelecká 344, Pøíbram Recenzenti: Prof. Ing. Edvard Leeder, CSc. Ing. Milan Cvrkal Odpovìdný redaktor Mgr. Petr Mušálek Sazba Milan Vokál Poèet stran 496 Druhé vydání, Praha 2009 ISBN 978-80-247-2615-1

verze osvit 0; Wednesday, 19th August, 2009; upravit rozmìr (20.8. jen tiráž)

Obsah

O autorech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Èást I: Principy podnikové informatiky 1.

Podniková informatika . . . . . . 1.1 Informace . . . . . . . . . . 1.2 Informaèní systém . . . . . 1.3 Podnikové procesy . . . . . 1.4 Podnikový informaèní systém 1.5 Podniková informatika . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

21 22 23 25 27 34

2.

Informaèní a komunikaèní technologie . . . . . . . . . . . . . . . . . 2.1 Technické prostøedky . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Poèítaèe . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Další technické prostøedky . . . . . . . . . . . . . . . . . 2.2 Základní programové vybavení . . . . . . . . . . . . . . . . . . . 2.2.1 Operaèní systémy . . . . . . . . . . . . . . . . . . . . . 2.2.2 Podpùrné programy (utility) . . . . . . . . . . . . . . . . . 2.2.3 Služební programy – servery a jejich klienti . . . . . . . . . 2.3 Komunikaèní prostøedky . . . . . . . . . . . . . . . . . . . . . . 2.4 Programové prostøedky pro podporu vývoje a implementaci aplikací 2.4.1 Systémy a prostøedky vývoje software . . . . . . . . . . . 2.4.2 Programovací jazyky . . . . . . . . . . . . . . . . . . . . 2.5 Typy systémù a technologické výpoèetní modely . . . . . . . . . . 2.5.1 Modely související s centralizovaným zpracováním . . . . 2.5.2 Modely související s decentralizovaným zpracováním . . . 2.5.3 Modely související s distribuovaným zpracováním . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

37 37 37 39 39 40 43 44 45 47 48 49 51 53 54 55

3. Data v podnikové informatice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Data a metadata, informace, znalosti a informaèní systém . . . . . . . . . . . . 3.2 Prezentace, uložení a zpracování dat . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Prezentace dat a metadat . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Organizace dat a tradièní (souborový) a databázový pøístup k uložení dat 3.2.3 Objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Relaèní databáze a SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Principy relaèních databází . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 SQL – Structured Query Language . . . . . . . . . . . . . . . . . . . . 3.3.3 Kategorie relaèních databázových systémù . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

61 61 65 65 66 69 71 71 72 75

5

3.4

3.5

4.

3.3.4 Rozvoj relaèních databází . . . . . . . . . . . . . . . . . . . . . XML, eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . 3.4.1 Principy XML a jádro XML . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Zpracování XML dokumentù . . . . . . . . . . . . . . . . . . . . 3.4.3 Aplikace XML v podnikové informatice . . . . . . . . . . . . . . . Další formáty ukládání dat . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Formáty spojené s poèítaèovou grafikou . . . . . . . . . . . . . . 3.5.2 Formáty orientované na dlouhodobou archivaci elektronických dat .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

75 77 78 80 81 84 84 87

Aplikace osobní informatiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.1 Technické prostøedky osobní informatiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.2 Softwarové prostøedky osobní informatiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3 Kanceláøské prostøedky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.3.1 Zpracování textù, textové editory, MS Word . . . . . . . . . . . . . . . . . . . . . . . 93 4.3.2 Zpracování tabulek, tabulkové editory (spreadsheet) . . . . . . . . . . . . . . . . . . . 94 4.3.3 Zpracování elektronických prezentací – prezentaèní programy . . . . . . . . . . . . . . 96 4.3.4 Osobní databáze, MS Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.3.5 Sady kanceláøských aplikací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.3.6 Funkcionalita kanceláøského balíku MS Office 2007 . . . . . . . . . . . . . . . . . . . 103 4.4 Pøíprava a zpracování grafických dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.4.1 Úprava digitální fotografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.4.2 Pøíprava vektorové grafiky – ilustrací, schémat . . . . . . . . . . . . . . . . . . . . . 107 4.4.3 Archivace obrázkù a grafiky – digitální fotoalba . . . . . . . . . . . . . . . . . . . . . 109 4.5 Elektronické informaèní zdroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.5.1 Internet a služby pro vyhledávání informací . . . . . . . . . . . . . . . . . . . . . . . 111 4.5.2 Vyhledávací a metavyhledávací služby . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.5.3 Pøedmìtové katalogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.5.4 Placené informaèní elektronické databáze . . . . . . . . . . . . . . . . . . . . . . . 117 4.5.5 Vìrohodnost informací a citace informaèních zdrojù . . . . . . . . . . . . . . . . . . . 119 Èást II: Aplikace podnikové informatiky

5.

6

Vymezení aplikací podnikové informatiky . . . . . . . . . . . . . . 5.1 Podstata aplikací podnikové informatiky . . . . . . . . . . . . . 5.2 Klasifikace aplikací podnikové informatiky . . . . . . . . . . . . 5.3 Možnosti øešení aplikací . . . . . . . . . . . . . . . . . . . . . 5.4 Podstatné charakteristiky aplikaèních software . . . . . . . . . 5.4.1 Základní a obchodní charakteristiky . . . . . . . . . . . 5.4.2 Funkcionalita, obsahové vymezení aplikaèního software 5.4.3 Služby . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.4 Provozní prostøedí . . . . . . . . . . . . . . . . . . . . 5.4.5 Další vlastnosti produktù ASW . . . . . . . . . . . . . . 5.5 Efekty podnikové informatiky . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

123 123 124 127 128 128 129 130 131 131 133

Podniková informatika

6.

Infrastrukturní aplikace . . . . . . . . . . . . . . 6.1 Portály . . . . . . . . . . . . . . . . . . . . 6.1.1 Principy portálù . . . . . . . . . . . 6.1.2 Funkcionalita portálù . . . . . . . . 6.1.3 Orientace portálù . . . . . . . . . . 6.2 Správa dokumentù a obsahu . . . . . . . . 6.2.1 Životní cyklus dokumentu . . . . . . 6.2.2 Správa dokumentù . . . . . . . . . 6.2.3 Správa obsahu . . . . . . . . . . . 6.3 Øízení a podpora spolupráce . . . . . . . . 6.4 Øízení pracovních tokù . . . . . . . . . . . 6.5 Øízení znalostí . . . . . . . . . . . . . . . . 6.6 Komplexní øešení øízení podnikového obsahu

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

137 137 137 138 140 142 143 145 147 149 152 155 157

7.

Celopodnikové transakèní aplikace . . . . . . . . . . . 7.1 Principy øešení ERP . . . . . . . . . . . . . . . . . 7.1.1 Celková koncepce ERP . . . . . . . . . . . 7.1.2 Technologické a provozní principy ERP . . . 7.1.3 Øízení pøístupu k funkcím a informacím ERP 7.1.4 Úpravy software . . . . . . . . . . . . . . . 7.2 Funkcionalita ERP . . . . . . . . . . . . . . . . . . 7.2.1 Øízení financí . . . . . . . . . . . . . . . . 7.2.2 Prodej a marketing . . . . . . . . . . . . . 7.2.3 Øízení nákupu a skladù . . . . . . . . . . . 7.2.4 Øízení lidských zdrojù . . . . . . . . . . . . 7.2.5 Výroba . . . . . . . . . . . . . . . . . . . . 7.2.6 Správa servisu . . . . . . . . . . . . . . . . 7.2.7 Úètování projektù . . . . . . . . . . . . . . 7.3 Pøíklad využití ERP aplikace . . . . . . . . . . . . . 7.4 Branžová øešení ve vztahu k ERP . . . . . . . . . . 7.4.1 Strojírenská výroba . . . . . . . . . . . . . 7.4.2 Procesní výroba . . . . . . . . . . . . . . . 7.4.3 Služby . . . . . . . . . . . . . . . . . . . . 7.4.4 Správa nemovitostí . . . . . . . . . . . . . 7.5 Kategorie a pøíklady produktù ERP . . . . . . . . . 7.5.1 Kategorie ERP . . . . . . . . . . . . . . . . 7.5.2 Pøíklady produktù ERP . . . . . . . . . . . 7.6 Efekty ERP . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

159 160 160 162 162 166 167 167 168 170 171 172 173 174 176 179 179 179 180 181 182 183 183 184

8.

Aplikace pro øízení externích vztahù . . . . . . . . . . . . . . . . . 8.1 Principy aplikací pro øízení externích vztahù . . . . . . . . . . . 8.1.1 Základní vztahy mezi subjekty elektronického podnikání 8.2 Aplikace pro vztahy B2C . . . . . . . . . . . . . . . . . . . . . 8.3 Aplikace pro vztahy B2B . . . . . . . . . . . . . . . . . . . . . 8.3.1 Elektronické zásobování (e-Procurement) . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

185 185 186 187 188 190

7

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

196 199 200 202 203 205 205 210 214

9. Analytické aplikace, business intelligence . . . . . . . . . . 9.1 Podstata business intelligence . . . . . . . . . . . . . . . 9.2 Základní principy business intelligence . . . . . . . . . . 9.2.1 Výbìr a organizace dat . . . . . . . . . . . . . . 9.2.2 Dimenze a granularita dat . . . . . . . . . . . . . 9.2.3 Multidimenzionalita uložení a práce s daty . . . . . 9.2.4 Nároky na kvalitu dat . . . . . . . . . . . . . . . 9.3 Hlavní komponenty øešení business intelligence . . . . . . 9.3.1 Produkèní (zdrojové) databáze . . . . . . . . . . 9.3.2 ETL – Extract, Transform and Load . . . . . . . . 9.3.3 EAI – Enterprise Application Integration . . . . . . 9.3.4 Doèasné úložištì dat (DSA) . . . . . . . . . . . . 9.3.5 Operativní úložištì dat (ODS) . . . . . . . . . . . 9.3.6 Datový sklad (DWH) . . . . . . . . . . . . . . . . 9.3.7 Datové tržištì (DMA) . . . . . . . . . . . . . . . 9.3.8 OLAP databáze . . . . . . . . . . . . . . . . . . 9.3.9 Reporting . . . . . . . . . . . . . . . . . . . . . 9.3.10 Analytické aplikace . . . . . . . . . . . . . . . . 9.3.11 Dolování dat (Data Mining) . . . . . . . . . . . . 9.3.12 Nástroje pro øízení kvality dat a správu metadat . . 9.4 Pøíklad øešení aplikace BI . . . . . . . . . . . . . . . . . 9.4.1 Návrh a vytvoøení struktur datového skladu . . . . 9.4.2 Transformace dat (ETL) . . . . . . . . . . . . . . 9.4.3 Vytvoøení analytického dotazu do datového tržištì 9.4.4 Výbìr datových zdrojù pro analytické úèely . . . . 9.4.5 Vytvoøení pohledu nad daty pro analýzy . . . . . . 9.4.6 Vytvoøení dimenzí pro OLAP kostky . . . . . . . . 9.4.7 Vytvoøení OLAP kostky . . . . . . . . . . . . . . 9.4.8 Zprocesování dimenzí a OLAP kostky . . . . . . . 9.4.9 Prohlížení OLAP kostky . . . . . . . . . . . . . . 9.4.10 Práce s OLAP kostkou v prostøedí Excel . . . . . . 9.4.11 Práce s OLAP kostkou v prostøedí ProClarity . . . 9.5 Funkcionalita a aplikace BI . . . . . . . . . . . . . . . . . 9.6 Segment trhu business intelligence . . . . . . . . . . . . 9.7 Efekty business intelligence . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

215 215 217 218 220 221 225 226 227 227 227 228 228 229 229 229 230 230 230 231 231 234 234 236 238 239 239 240 242 242 242 243 245 246 248

8.4 8.5 8.6 8.7 8.8

8

8.3.2 Elektronické tržištì (e-Marketplace) . . . . 8.3.3 Elektronické aukce . . . . . . . . . . . . 8.3.4 Øízení dodavatelských øetìzcù (APS/SCM) 8.3.5 Zásoby øízené dodavatelem . . . . . . . . Aplikace pro vztahy B2G a C2G . . . . . . . . . . Aplikace pro vztahy C2C . . . . . . . . . . . . . . Mobilní obchodování . . . . . . . . . . . . . . . . Øízení vztahù k zákazníkùm (CRM) . . . . . . . . Efekty aplikací pro øízení externích vztahù . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .


10. Øízení rozvoje, inovací a podnikové výkonnosti 10.1 Podniková architektura . . . . . . . . . . . 10.2 Øízení podnikových procesù . . . . . . . . . 10.3 Øízení podnikové výkonnosti – CPM . . . . . 10.4 Øízení životního cyklu produktu – PLM . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

251 252 255 257 260

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

265 267 267 268 268 269 270 271 271 271 272 272 272 273 274 274 274 274 274 275 275 276 276 276 276 276 277 277 277 278 278 278 278 279 279

Èást III: Øešení aplikací podnikové informatiky 11. Životní cyklus aplikací podnikové informatiky . . . . . . . . . 11.1 Plánování a pøíprava aplikace . . . . . . . . . . . . . . . . 11.1.1 Vstupní analýza . . . . . . . . . . . . . . . . . . . 11.1.2 Plánování projektu aplikace . . . . . . . . . . . . . 11.1.3 Výbìr dodavatele aplikace . . . . . . . . . . . . . 11.1.4 Úvodní studie . . . . . . . . . . . . . . . . . . . . 11.2 Analýza a návrh aplikace . . . . . . . . . . . . . . . . . . 11.2.1 Analýza podnikových procesù . . . . . . . . . . . . 11.2.2 Analýza stávajících databází . . . . . . . . . . . . 11.2.3 Analýza stávajících aplikací . . . . . . . . . . . . . 11.2.4 Návrh zmìn podnikových procesù . . . . . . . . . . 11.2.5 Návrh databází . . . . . . . . . . . . . . . . . . . 11.2.6 Návrh aplikace . . . . . . . . . . . . . . . . . . . . 11.3 Implementace aplikace . . . . . . . . . . . . . . . . . . . 11.3.1 Detailní specifikace modulù . . . . . . . . . . . . . 11.3.2 Prototypy . . . . . . . . . . . . . . . . . . . . . . 11.3.3 Kastomizace typového software . . . . . . . . . . . 11.3.4 Vývoje a dovývoje . . . . . . . . . . . . . . . . . . 11.3.5 Akceptaèní øízení . . . . . . . . . . . . . . . . . . 11.4 Pøíprava na zavedení do provozu, migrace . . . . . . . . . 11.4.1 Detailní specifikace plánu a harmonogramu migrace 11.4.2 Instalace aplikaèního software a dalších technologií . 11.4.3 Migrace dat . . . . . . . . . . . . . . . . . . . . . 11.4.4 Organizaèní pøíprava provozu aplikace . . . . . . . 11.4.5 Pøedávací øízení . . . . . . . . . . . . . . . . . . . 11.5 Provoz a užití aplikace . . . . . . . . . . . . . . . . . . . . 11.5.1 Pøedání aplikace do provozu . . . . . . . . . . . . 11.5.2 Správa infrastruktury . . . . . . . . . . . . . . . . 11.5.3 Podpora uživatelù . . . . . . . . . . . . . . . . . . 11.5.4 Monitorování provozu aplikace . . . . . . . . . . . 11.5.5 Návrhy na zmìny aplikace . . . . . . . . . . . . . . 11.6 Další rozvoj a optimalizace aplikace. . . . . . . . . . . . . . 11.6.1 Zmìnové øízení . . . . . . . . . . . . . . . . . . . 11.6.2 Návrhy a realizace dílèích úprav aplikace . . . . . . 11.6.3 Zadání nového projektu . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

12. Datové modelování a návrh databází . . . . . . 12.1 Podstata datového modelování . . . . . . . 12.2 Konceptuální datové modelování . . . . . . 12.2.1 Entity . . . . . . . . . . . . . . . . 12.2.2 Vazby . . . . . . . . . . . . . . . . 12.2.3 Byznys pravidla . . . . . . . . . . . 12.3 Logický návrh databáze . . . . . . . . . . . 12.3.1 Specifikace databázových tabulek . 12.3.2 Definování klíèù . . . . . . . . . . . 12.3.3 Øešení a testování integrity databáze 12.4 Fyzický návrh databáze . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

281 281 282 285 287 290 293 293 293 294 294

13. Procesní modelování a zlepšování podnikových procesù . . 13.1 Úèel a uplatnìní procesního modelování . . . . . . . . . 13.2 Metodiky a dokumentace podnikových procesù . . . . . . 13.2.1 Modelování podnikových procesù . . . . . . . . . 13.2.2 Pøíklady dalších nástrojù pro procesní modelování 13.3 Reengineering podnikových procesù . . . . . . . . . . . 13.4 Možnosti procesních návrhù a zmìn . . . . . . . . . . . . 13.5 Efekty a rizika procesního reengineeringu . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

299 299 300 301 306 308 309 311

14. Dimenzionální modelování . . . . . . . . . . . . . . . . . . . . . . . 14.1 Podstata dimenzionálního modelování . . . . . . . . . . . . . . 14.2 Postup dimenzionálního modelování . . . . . . . . . . . . . . . 14.2.1 Pøípravná fáze . . . . . . . . . . . . . . . . . . . . . . . 14.2.2 Hrubý dimenzionální model . . . . . . . . . . . . . . . . 14.2.3 Analýza a návrh datového skladu a tržišť . . . . . . . . . 14.3 Tabulky faktù . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.1 Principy tabulky faktù . . . . . . . . . . . . . . . . . . . 14.3.2 Granularita v tabulce faktù . . . . . . . . . . . . . . . . . 14.3.3 Agregace dat . . . . . . . . . . . . . . . . . . . . . . . 14.4 Tabulky dimenzí . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.1 Principy návrhu dimenzionálních tabulek . . . . . . . . . 14.4.2 Zmìny v dimenzích (SCD – Slowly Changing Dimensions) 14.5 Fyzický návrh datového skladu . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

313 313 314 315 316 319 321 321 322 323 323 323 325 327

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

331 331 331 334 337 340 341 344

Èást IV: Provoz a rozvoj podnikové informatiky 15. Bezpeènost v informatice . . . . . . . . . . . 15.1 Øešení bezpeènosti IS/ICT . . . . . . . . 15.1.1 Základní pojmy . . . . . . . . . . 15.1.2 Pøístup k øešení bezpeènosti IS/ICT 15.2 Hrozby . . . . . . . . . . . . . . . . . . . 15.3 Protiopatøení . . . . . . . . . . . . . . . . 15.3.1 Zajištìní autentizace zprávy . . . . 15.3.2 Zajištìní dùvìrnosti . . . . . . . .

10

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .


15.3.3 15.3.4 15.3.5 15.3.6

Autentizace a autorizace uživatelù, programù a systémù Ochrana proti škodlivým kódùm . . . . . . . . . . . . . Firewall . . . . . . . . . . . . . . . . . . . . . . . . . Další protiopatøení . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

347 349 349 351

16. Integrace podnikové informatiky . . . . . . . . . . . . . . . 16.1 Specializace, integrace, evoluce integrace . . . . . . . 16.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . 16.2.1 Funkcionalita základního middleware . . . . . . 16.2.2 Funkcionalita integraèního middleware . . . . . 16.2.3 Funkcionalita middleware pro aplikaèní integraci 16.3 Služebnì orientovaná architektura . . . . . . . . . . . 16.3.1 Služby . . . . . . . . . . . . . . . . . . . . . . 16.3.2 Architektura . . . . . . . . . . . . . . . . . . . 16.3.3 XML a SOA . . . . . . . . . . . . . . . . . . . 16.4 Pøístupy k integraci . . . . . . . . . . . . . . . . . . . 16.4.1 Integrace aplikací . . . . . . . . . . . . . . . . 16.4.2 Informaèní integrace . . . . . . . . . . . . . . . 16.4.3 Integrace na úrovni pøístupu . . . . . . . . . . . 16.5 Systémová integrace . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

353 353 354 355 357 358 359 359 361 365 368 368 374 376 377

17. Øízení provozu a rozvoje podnikové informatiky . . . 17.1 Možnosti provozu a rozvoje podnikové informatiky 17.1.1 Outsourcing a offshoring . . . . . . . . . 17.1.2 Hosting . . . . . . . . . . . . . . . . . . 17.1.3 Vzdálené poskytování služeb (ASP) . . . . 17.1.4 Software-as-a-Service (SaaS) . . . . . . . 17.2 Øízení podnikové informatiky . . . . . . . . . . . 17.2.1 Informaèní strategie . . . . . . . . . . . . 17.2.2 Plánování projektù, projektový zámìr . . . 17.2.3 Øízení služeb podnikové informatiky . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

381 383 383 384 385 385 386 387 387 388

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Závìr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Pøílohy P1 Vývoj v informatice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 P2 Poèítaè a periferie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 P3 Mìrné jednotky a informaèní technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 P4 Pøehled poèítaèových rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 P5 Virtualizace a konsolidace systémù . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 P6 Technologie sítí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

11

6.1

6.2 6.3

Principy sítí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Topologie sítì . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Typy sítí a jejich konvergence . . . . . . . . . . . . . . . . . . . . . . 6.1.3 Síťový model, protokoly, síťové rozhraní a aktivní prvky poèítaèové sítì . Pøístup k poèítaèové síti prostøednictvím pøístupových sítí . . . . . . . . . . . . Klasifikace poèítaèových sítí . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Sítì podle rozsahu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Další specifické sítì . . . . . . . . . . . . . . . . . . . . . . . . . . .

P7 Technologie a služby internetu . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Protokolová sada TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Adresace a smìrování v internetu, spolehlivost pøenosu a vztah k aplikacím 7.3 Aplikaèní služby v internetu . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Systém doménových jmen . . . . . . . . . . . . . . . . . . . . . 7.3.2 Pøiøazení IP adres – Služba Dynamic Host Configuration Protocol . . 7.3.3 Služba elektronické pošty . . . . . . . . . . . . . . . . . . . . . . 7.3.4 Služba pøenosu souborù – FTP . . . . . . . . . . . . . . . . . . . 7.3.5 Služba World Wide Web . . . . . . . . . . . . . . . . . . . . . . . 7.3.6 Další významné služby . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

407 407 407 409 412 416 416 418

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

419 420 422 427 427 432 434 438 439 445

P8 Kódování znakù . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 P9 Pøehled XML specifikací a aplikací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 P10 Pøíklady vybraných funkcí editorù Word a Excel . . . . . . . . . . . . . . . . . . . . . . . . . . 455 10.1 Textový editor MS Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 10.2 Tabulkový editor MS Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Literatura a další zdroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 Pøehled zkratek a základních termínù . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Rejstøík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

12


O autorech Ing. Libor Gála Vystudoval obor „Automatizované systémy øízení“ na Vysoké škole ekonomické v Praze, kde od ukonèení studia v roce 1988 pùsobí jako odborný asistent. Ve své pedagogické i další práci se zamìøuje pøedevším na oblast integrace podnikových aplikací a otázky spojené s aplikací internetu do podnikové praxe. Zde se zabývá na jedné stranì problematikou návrhu a implementace použitelných a pøístupných webových aplikací a hypertextových systémù, a na druhé stranì pøístupy, které do vývoje a provozu aplikací pøináší servisnì orientovaná architektura. Na praktických projektech spolupracuje se spoleènostmi ITG a ÈSSI.

Doc. Ing. Jan Pour, CSc. Vystudoval Fakultu národohospodáøskou na Vysoké škole ekonomické v Praze. Je docentem katedry informaèních technologií VŠE v Praze. Souèasnì pracuje jako analytik ve spoleènosti ITG Praha. Profesnì se orientuje na otázky øízení podnikové informatiky, koncepcí a aplikaèních architektur informaèních systémù podnikù a úlohy business intelligence. Podílel se na øešení nìkolika desítek projektù pro nejrùznìjší podniky a organizace v energetice, prùmyslu, obchodì i ve státní správì. V souèasné dobì je èlenem Rady Èeské spoleènosti pro systémovou integraci a redaktorem èasopisu Systémová integrace.

Ing. Zuzana Šedivá Vystudovala obor „Automatizované systémy øízení“ na Vysoké škole ekonomické v Praze, kde od absolvování v roce 1985 pùsobí na katedøe informaèních technologií jako odborná asistentka. Ve své pedagogické práci i v ostatních odborných aktivitách se zamìøuje pøedevším na oblasti aplikací grafických dat a multimediálních prezentací. Souèasnì svou odbornost rozvíjí v oblasti podpory informaèních technologií ve vzdìlávání a výuce (e-learningu). V mezinárodní organizaci OBSE se dlouhodobì podílela na praktických projektech v oblasti zpracování a archivace dokumentù. Na praktických projektech spolupracuje i se spoleèností ITG. V souèasnosti je také externí lektorkou Vysoké školy ekonomie a managementu.

O autorech

13

Úvod Zøejmì je na tomto místì zbyteèné opakovat nejrùznìjší myšlenky a hesla o významu informatiky pro jednotlivce i podniky, pro jejich úspìch a konkurenceschopnost, o unikátní rychlosti rozvoje informaèních a komunikaèních technologií, o potøebì jisté informatické kvalifikace každého z nás poèínaje žáky základních škol a lidmi dùchodového vìku konèe. Omezme se proto na konstatování, že informatika tu je, musíme s ní pracovat, musíme s ní žít a musíme jí tedy i do jisté míry porozumìt. Toto porozumìní má však rùzný smìr, rozsah a rùznou úroveò detailu. Nìkdo potøebuje znát všechny potøebné detaily poèítaèe, protože je dodává, opravuje nebo kompletuje, jiný potøebuje znát všechny potøebné detaily programù, aplikací, s nimiž pracuje a s jejichž pomocí vydìlává pro firmu peníze. Pro všechny, nebo alespoò vìtšinu z nás, je ale úèelné mít celkový, byť rámcový pøehled o informatice, co nabízí, co na nás vyžaduje a kam se ubírá. Takový informatický základ se stává bìžnou souèástí vzdìlání lidí tohoto tisíciletí a souèasnì poskytuje podstatnì lepší výchozí prostor pro pochopení všech podstatných souvislostí v informatice i pro konkrétní práci s jednotlivými technickými nebo programovými prostøedky. První otázka, kterou si na poèátku musíme položit, je: Komu je tato kniha urèena a co je jejím úèelem? Otázka je to vcelku jednoduchá, odpovìï o poznání složitìjší. V informatice a kolem ní se pohybuje ohromné množství lidí, a to v nejrùznìjších profesích nebo rolích – programátoøi, analytici, technici a zejména uživatelé, tj. manažeøi, obchodníci, úèetní, nejrùznìjší podnikoví specialisté, ale i lidé mimo ekonomickou sféru. Uživatelù je logicky nejvíce, a zejména oni nakonec rozhodují o úspìchu èi neúspìchu informaèních systémù a programù, techniky, penìz i èasu do nich vložených. Jejich kvalifikace, schopnosti a zájem zhodnotí, nebo znehodnotí všechny tyto prostøedky, jejichž cena se mùže pohybovat od nìkolika tisíc až po desítky milionù korun. Prvním naším zámìrem je proto pøispìt uživatelùm, uživatelské sféøe v orientaci v souèasné informatice. Druhým naším zámìrem je naplnit tvrzení z prvního odstavce a poskytnout celkový výchozí pøehled o informatice, bez podrobností, ale s respektováním všech jejích nezbytných souèástí, jejích podstatných charakteristik a vzájemných vazeb. Takový souhrnný pohled na podnikovou informatiku zahrnuje aplikace v informatice, jim odpovídající technologie, projektové a analytické postupy a metody, a je proto obvykle východiskem pro práci a rozvoj další kvalifikace projektantù a analytikù informaèních systémù. Kniha je proto urèena i jako základ pro studium zaèínajícím projektantùm a analytikùm. Mluvíme-li v naší publikaci o podnikové informatice, máme tím na mysli informatiku v rùzných prostøedích prùmyslových, obchodních, dopravních a dalších spoleèností, ale i v prostøedí finanèních institucí a organizací veøejné správy. Zkrácený termín podniková informatika používáme jako zobecnìní tìchto prostøedí, a to i s vìdomím jisté nepøesnosti. Vycházíme z pøedpokladu, že k tomu, abychom byli pøipraveni porozumìt možnostem informatiky v reálném prostøedí jakéhokoli ekonomického subjektu, musíme si nejdøíve uvìdomit, proè informatiku potøebujeme. Jaké jsou vlastnì naše požadavky na informatiku a zejména na její obsah, jaké funkce má poskytovat, s jakými daty a informacemi má pracovat, jaké technologie a prostøedky lze pro naše požadavky nejefektivnìji využívat. Tyto otázky a jejich øešení jsou náplní èásti I publikace. Víme-li, co má být úèelem a obsahem informatiky, mùžeme uvažovat o tom, jaké druhy aplikací, aplikaèních software (napø. programù pro vedení úèetnictví, obchodování apod.) máme k dispozici a jaké jsou jejich možnosti a omezení v podnikovém øízení. V souèasné dobì je v praxi celá øada velmi rùznorodých aplikací. Jsou urèeny rùzným pracovníkùm podniku, poskytují rùzné funkce, jsou založeny na rùzných technologiích, mají rùzné možnosti využití. Je proto vždy otázkou, kterou z nich pro daný úèel a obsah nasadit a využít. Odpovìdi na tyto otázky tvoøí èást II.

Úvod

15

Jak naznaèuje pøedchozí odstavec, informatika se prakticky ve vìtšinì organizací prùbìžnì rozvíjí, øeší se nové úlohy a projekty a ty pùvodní se upravují podle nových požadavkù. Na øešení tìchto úloh a projektù obvykle kooperují jak analytici, tak uživatelé a využívá se pøi nich mnoha rùzných metod a postupù. Úèelem èásti III je objasnit jejich podstatu a zpùsob práce s nimi, neboť úroveò jejich zvládnutí ovlivòuje výslednou kvalitu øešení projektù i celého informaèního systému. Informatika v jakékoli organizaci se musí racionálnì provozovat i prùbìžnì rozvíjet tak, aby odpovídala skuteèným potøebám jejích uživatelù a potenciálu, který informatický trh aktuálnì nabízí. To ale také znamená, že provoz i vývoj tìchto stále složitìjších komplexù rùzných programových a technických prostøedkù se musí kvalifikovanì øídit. Øízení informatiky sice není hlavní orientací této publikace, pøesto pokládáme za úèelné poukázat zejména na to, co je tøeba øídit a co pro úspìšný chod podnikové informatiky zajistit. To jsou pak témata èásti IV. Uvedené okruhy otázek a témat jsou základem celkové struktury pøedkládané publikace, kterou dokumentuje obr. 0.1.


I. Principy podnikové informatiky podniková informatika, její obsah a zdroje (funkce, procesy, role) technologická infrastruktura (technika, software, komunikace) data, datové zdroje, informace osobní informatika II. Aplikace podnikové informatiky vymezení aplikací, jejich typy a podstatné charakteristiky infrastrukturní aplikace celopodnikové transakèní aplikace aplikace pro øízení externích vztahù podniku analytické aplikace a podpora podnikového øízení aplikace øízení podnikové výkonnosti a inovací

III. Øešení aplikací podnikové informatiky životní cyklus podnikové informatiky metody analýzy a návrhu podnikové informatiky

IV. Øízení podnikové informatiky principy øízení informatiky, obsah a organizace øízení bezpeènosti integrace podnikové informatiky

Obr. 0.1 Celková struktura knihy

16


Obvyklou souèástí úvodních informací ke každé knižní publikaci je vymezení základních formálních standardù. Proto na tomto místì upozorníme na použité piktogramy, které uvozují standardní èásti jednotlivých kapitol:

y

Úèel kapitoly nebo èásti textu.

`

Vymezení nebo definice nejdùležitìjších pojmù (nikoli všech).

2 F

Pøíklady – zadání k souhrnnému pøíkladu vybrané firmy nebo dílèí kroky pøi práci s programovými prostøedky, resp. pøi realizaci jejich jednotlivých funkcí. Základní pøípadová studie vybraného podniku, na níž jsou dokumentovány problémy a jejich øešení v bìžné praxi.

F

Doporuèení pro øešení úlohy, problému nebo operace.

Ò

Shrnutí kapitoly nebo vybrané èásti textu.

K tomu, abychom naše další úvahy o podnikové informatice a nìkterých jejích aplikacích a technologiích mohli pøiblížit na konkrétnìjších pøíkladech, použijeme k tomu pøípadovou studii (pro tyto úèely speciálnì založené) obchodní firmy; nazvìme ji NEON.

F

Naši firmu doplòme nìkolika dalšími charakteristikami: l

l

l

l l

Firma je akciovou spoleèností, patøí svým rozsahem ke støedním, má kolem 200 zamìstnancù a obrat 500 milionù Kè. Firma NEON nakupuje a prodává bìžné spotøební zboží – elektrické pøístroje, žárovky, kabely, CD a DVD atd. Firma dodává spotøební zboží obchodním øetìzcùm a dalším obchodním organizacím, ale i koneèným spotøebitelùm. Zboží nakupuje u rùzných dodavatelù, pøedevším od výrobních podnikù nebo distribuèních center. Firma vstupuje do rozmanitých vztahù s mnoha externími partnery, jak dokumentuje obr. 0.2.

V dalším textu se budeme na uvedený pøíklad odvolávat s tím, že na zaèátku uvedeme struènì daný problém a v závìru možnosti jeho øešení ve vazbì na probírané téma a vždy také upozorníme na pøípadné odlišnosti jednotlivých øešení a produktù i u jiných typù organizací. Standardním problémem každého textu tohoto charakteru je rychlost jeho zastarávání. To je dáno neobyèejnì rychlým rozvojem informaèních a komunikaèních technologií, který nemá v žádné jiné sféøe lidského poznání obdoby. Tomuto problému se samozøejmì nevyhneme ani v našem pøípadì. Na druhé stranì se ho snažíme alespoò èásteènì eliminovat odkazy na aktualizované webové stránky obsahující aktuální pøehledy produktù, služeb a jejich dodavatelù a na vývojové trendy na ICT trhu.

Úvod

17

Zákazník

Zákazník

Zákazník

Veøejná správa

Dodavatel

Zákazník

Dodavatel

Dodavatel

Obr. 0.2 Pøíklad obchodní firmy NEON Na závìr by autoøi chtìli touto cestou podìkovat spolupracovníkùm i absolventùm kateder informatiky na VŠE v Praze, zejména prof. Jiøímu Voøíškovi, prof. Josefu Baslovi, doc. Prokopu Tomanovi a dalším za spolupráci na pøípravì knihy. Tato publikace vznikla ve velmi úzké kooperaci s øadou externích partnerù z praxe, zejména se spoleèností KPC-Group, která je výhradním zastoupením spoleènosti Gartner v ÈR, na Slovensku a v Rumunsku. Zvláštní dík dále patøí tìmto spoleènostem a jejich pracovníkùm: Ing. Milanu Cvrkalovi, Ing. Drahoslavu Dvoøákovi, Ing. Petru Hampejsovi a Ing. Pavlu Šlesingrovi (Microsoft ÈR), Ing. Lumíru Srchovi, Ing. Václavu Derflerovi, Ing. Vladimíru Zykovi a Ing. Janu Novákovi (ITS), Ing. Ivì Stanovské (Aquasoft), Ing. Pavlu Šindeláøovi (AutoCont CZ), Ing. Milanu Štoèkovi a Ing. Jánu Zajícovi (Clever Decision) a celé øadì pracovníkù dalších spoleèností pùsobících na našem ICT trhu, kteøí poskytli pro tuto publikaci cenné materiály, pøíklady, pøipomínky a námìty. V knize byly využity výstupy a výsledky následujících výzkumných grantù: l

l l

18

GA ÈR è. 201/07/0455 – Model vztahu mezi výkonností podnikání, úèinností podnikových procesù a efektivností podnikové informatiky, CVKS MŠMT 2005 – 2009, 1M0524 – Centrum výzkumu konkurenèní schopnosti èeské ekonomiky, GA ÈR 201/08/0663 – Inovace informaèních systémù podporující konkurenceschopnost podnikù.


ÈÁST I: PRINCIPY PODNIKOVÉ INFORMATIKY Cílem úvodní èásti je vytvoøit potøebnou terminologickou základnu a pøedevším vymezit, z èeho se informatika skládá a co v praxi zahrnuje. Hlavní náplní èásti I je objasnìní podstatných principù a informatiky a vymezení jejího obsahu. Základní strukturu této èásti demonstruje obr. I.1.

Podniková informatika [1] vymezení informatiky, aplikované a podnikové informatiky obsah podnikové informatiky – podnikové procesy, role, zdroje

ICT - Informaèní a komunikaèní technologie [2]

Data v podnikové informatice [3]

Osobní informatika [4]

technické prostøedky základní programové vybavení komunikaèní prostøedky vývoj aplikací výpoèetní modely

data, informace, znalosti prezentace a zpracování dat relaèní databáze a SQL XML formáty ukládání dat

kanceláøské prostøedky prezentaèní techniky, grafika vyhledávání informací

Obr. I.1 Struktura èásti I Na informatiku se mùžeme dívat na zcela obecné úrovni a na úrovni jejích aplikací v urèitém oboru lidské èinnosti, tj. na aplikovanou informatiku, a konkrétnìji na informatiku v podnikovém prostøedí, tedy na podnikovou informatiku. Rozdíly v tìchto pohledech se zabývá kapitola 1. Vymezuje rovnìž její základní obsah, tj. role, funkce a procesy v podnikové informatice. Informatika je založena na širokém spektru technických, programových a komunikaèních prostøedkù, resp. technologické infrastruktuøe a její pøehled poskytuje kapitola 2. Následující kapitola je vìnována datùm, datovým zdrojùm, datovým bázím a informacím z nich odvozovaným. Ukazuje, jak lze data ukládat, pøistupovat k nim a prezentovat je. Poslední kapitola úvodní èásti je vìnována tzv. osobní informatice, tj. zejména programovým prostøedkùm, urèeným pro práci jednotlivce, jako jsou textové editory, tabulkové kalkulátory a další.

19

1

1. Podniková informatika y

Cílem této kapitoly je vymezit pojem podniková informatika, charakterizovat vztah k pojmu informaèní systém a definovat obsah informatických zdrojù.

Informatika, stejnì tak jako samotné poèítaèe, prošla svým historickým vývojem1. Tak, jak se informatika vyvíjela, vyvíjelo se i její pojetí, tedy i její chápání, vymezení a definice. Definic informatiky jako vìdní discipliny je v souèasné dobì celá øada a této otázce se vìnují i celé specializované publikace. Je zøejmé, že se názory na její vymezení èasto i podstatnì rùzní. Úèelem této publikace ale není øešit otázky vymezení vlastní informatiky, ale poskytnout obraz o možnostech jejích aplikací a technologií. Proto budeme definovat informatiku pouze následovnì:

`

Informatika je vìdou o informacích. „Studuje“2 jejich vyjádøení a podobu, zpracování a pøenášení v pøirozených (lidé a spoleènost) i umìlých (poèítaèe) systémech (Feather a kol., 2003). 2

Informatika ve svém studiu využívá jiných vìd. Jedná se napø. o filozofii, pøírodní vìdy (matematiku, fyziku, chemii a biologii), o poèítaèové vìdy (computer science), kognitivní vìdy a vìdy o umìlé inteligenci. Principy formulované informatikou jsou pak aplikovány v jiných vìdních disciplínách a oborech. Pro vyjádøení specializace informatiky v konkrétní oblasti se využívá spojení pojmu informatika s názvem pøíslušné disciplíny nebo oboru. Setkat se mùžeme s medicínskou (zdravotnickou, bio) informatikou, zemìdìlskou informatikou, chemickou (molekulární) informatikou atd. V oblasti ekonomie se využívá celá øada spojení, napø. hospodáøská informatika3, manažerská informatika, informatika v ekonomice, informatika v podnikání apod. V této publikaci budeme pro oznaèení takové aplikace používat slovní spojení podniková informatika4. Chceme tím vyjádøit, že se zamìøíme na podnik, jakožto reprezentaci institualizace podnikání. Protože ale nìkteré aktivity podnikatelských subjektù (nákup, øízení lidských zdrojù, finanèní øízení apod.) realizuje i stát a jeho územní složky (kraj, obec), reprezentované výkonnými orgány a státními organizacemi, lze principy podnikové informatiky aplikovat i u tìchto orgánù a organizací. Pro pochopení obsahu podnikové informatiky nejprve definujme nìkolik základních pojmù – informace, informaèní systém, zdroje v informaèním systému a procesy.

1 2 3 4

Základní momenty tohoto vývoje jsou pøedmìtem pøílohy 1. Synonyma – analyzuje, zkoumá, diskutuje, promýšlí, uvažuje o, hledá Z nìmeckého Wirtschaftsinformatik V zahranièní literatuøe se oznaèuje pojmem business informatics.


21

1

1.1 Informace Tak, jak se vyvíjela informatika, vyvíjel se i obsah pojmu informace. Pøi vymezení termínu informace pøipomeneme nejprve myšlenku N. Wienera, zakladatele kybernetiky, kterou formuloval již v roce 1948 – „Informace je informace, není to ani hmota, ani energie. Materialismus, který toto nepøipouští, nemùže pøetrvat dnešek.“ Pojem „informace“ používáme intuitivnì v prùbìhu celého našeho života. Není bez zajímavosti, že historicky se s tímto pojmem setkáváme již ve støedovìku – vždy v nejdùležitìjších sférách: v obchodì, v soudnictví a v církevním životì (tedy v ideologii). Samostatný výraz informace (z lat. informatio, resp. informare = dát tvar, formovat, tvoøit) je zaznamenán poprvé roku 1274 ve významu souboru aktù, které vedou k prokázání dùkazù trestného èinu a k odhalení jeho pachatelù. Informaèní kanceláø bývala zøizována pøi každém vìtším penìžním ústavu a podávala dùvìrná sdìlení o finanèním stavu jednotlivých obchodníkù. Processus informativus (lat.) bylo zvláštní øízení v církevním právu: Biskup delegovaný papežem zjišťoval, má-li kandidát na biskupský úøad potøebnou kvalifikaci. Dnes se setkáváme s rùzným chápáním pojmu informace. V pojetí této publikace je podstatné, že informace je èlánkem zpracovatelského øetìzce „reálný svìt – data – informace – znalosti“. V tomto kontextu se data oznaèují jako „surovina“ pro pøípravu informací. A informace spoleènì s uloženými pravidly se stávají znalostmi. Použití výrazu informace ve významu zpráva, údaj, sdìlení, pouèení bylo rozšíøeno až do padesátých let 20. století. Tehdy se s rozvojem pøenosu signálù, teorie telekomunikací, kybernetiky a elektronických poèítaèù vyèlenily nové samostatné obory mající svùj pøedmìt zkoumání, svou metodiku a vlastní terminologii. Jedním z nich byla a je „teorie informace“. U jejího zrodu stáli Shannon, Bell, Ashby, Wiener, Kolmogorov, Gabor, Szilard a Brillouin. Pùvodnì byl zájem expertù soustøedìn na technickou informaci. Vìdci vycházeli z potøeb sdìlovací techniky – pøenést maximum zpráv v nejkratším èase a co nejbezpeènìji. Další oblastí zkoumání bylo zajištìní potøebných informací pro øízení strojù. Biologické informace zkoumáme v souvislosti s pamìtí, s genetickými kódy, s myšlením a s jinými pøíbuznými jevy. Spoleèenské informace tvoøí nejrozsáhlejší oblast. Jsou to informace ekonomické, normotvorné, vìdeckotechnické, sociální, umìlecké, politické a další. Nyní mùžeme zejména v ekonomii sledovat tyto výklady informace: l l

l

ve všeobecném významu – sdìlení, zprávy, distribuované pùsobení na spoleènost (èi na její jedince) – hromadné sdìlovací prostøedky v širším slova smyslu (rozhlas, tisk, TV, reklama aj.), v obecném kybernetickém významu – „øízení a sdìlování v živých organismech a strojích“ (vèetnì ekonomických systémù).

Na každou informaci mùžeme aplikovat tøi rùzné úrovnì pohledu v odpovídajícím uspoøádání, v interpretaci a využití znakù: l

l

22

Úroveò syntaxe – zabývá se vnitøní strukturou zprávy složené ze znakù dané abecedy, tj. zkoumá uspoøádání vztahù mezi znaky. Zároveò pøedpokládá analýzu informace nezávisle na jejím vztahu k objektu, který odráží. Tedy nezávisle na významu informace a na pøíjemci, který bude informaci využívat. Pøíkladem jsou pravidla pro zápis zprávy v konkrétním (pøirozeném nebo umìlém) jazyce. Úroveò sémantiky – zajímá se o vztah znaku k objektu, procesu nebo jevu, který tento znak odráží, nezávisle na pøíjemci. Pøíkladem je pochopení napsaného textu.


1

l

Úroveò pragmatiky – zkoumá vztah informace k pøíjemci, využití této informace, její praktický dopad na daný (napø. ekonomický systém). Je to pro nás nejdùležitìjší, ale také nejobtížnìji formalizovatelná úroveò. Pøíklad: „praktický význam“ zprávy pro osobu pøíjemce.

Pojetí informace mùžeme shrnout do následující pracovní definice:

`

Informace je zpráva o nastalém jevu, která u nás (pøíjemcù) snižuje míru neznalosti o tomto jevu.

1.2 Informaèní systém Stejnì jako jiné obory i informatika se snaží vhodnì uspoøádat svoji pøedmìtnou oblast. Za jeden z podstatných principù považujeme koncept systému. Definic tohoto termínu existuje celá øada5 a pro naše úèely využijeme definici dle (Molnár, 2006).

`

Systém je úèelovì definovaná neprázdná množina prvkù a množina vazeb mezi nimi, pøièemž vlastnosti prvkù a vazeb mezi nimi urèují vlastnosti (chování) celku.

Pro takto definovaný systém (který je pøedmìtem našeho zájmu) identifikujeme pøedevším: l l l l l

l

úèel systému, tj. cíl, resp. cílové chování systému; strukturu systému, tj. prvky systému a vazby mezi nimi; vlastnosti prvkù systému významné pro celkové chování systému; vlastnosti vazeb mezi prvky systému, významné pro celkové chování systému; okolí systému, tj. vymezení prvkù, které již nepatøí do systému, ale jejichž vlastnosti a vazby systému na tyto prvky okolí významným zpùsobem ovlivòují chování systému; pøípadné subsystémy, pokud zkoumání systému jako celku je pøíliš složité a je tøeba (a hlavnì je možné) systém rozdìlit na menší relativnì samostatné (uzavøené) celky uvnitø systému.

V informatice se takový systém oznaèuje pojmem informaèní systém. Jeho úèelem je zajištìní vhodného vyjádøení informací, jejich zpracování a pøenášení v rámci nìjakého systému. Obecnì je pak tvoøen lidmi, vhodnými nástroji a metodami, které jsou seskupeny do tøí základních komponent: l

l l

5

vstup (input) – zahrnuje prvky, umožòující zachytit informaèní a další vstupy, které mají být pøedmìtem zpracování, pøípadnì vstupy vzájemnì propojit; zpracování (processing) – zahrnuje prvky, které zajišťují transformaci vstupù do požadovaného výstupu; výstup (output) – pøedstavuje prvky, které jsou schopny pøenést informaèní a další výstupy k jeho pøíjemci (uživateli). Napø. Ashby, W. R. 1961. Kybernetika. Orbis, Praha; von Bertalanffy, L. 1968. General system Theory. Braziller, New York; Hall, A. and Fagen, R. 1956. Yearbook of the Society for the Advancement of General Systems Theory, volume General Systems I, chapter Definition of System. Ann Arbor; nebo Vlèek, J. 1984. Metody systémového inženýrství. SNTL, Praha.


23

1

Takový systém je pak rozšíøen o komponenty, které zajišťují jeho øízení (control) a zpìtnou vazbu (feedback). Komponenta øízení zahrnuje následující aktivity – nastavení standardù zpracování, mìøení vyhovìní standardùm a vyvolání akcí vedoucích k minimalizaci odchylek od standardù. Øízení lze provádìt na výstupu a v závislosti na výsledku lze korigovat vstupy a zpracování, ale také lze øízení realizovat na vstupu a v závislosti na vstupu lze korigovat vlastní zpracování, aby bylo vyhovìno definovaným standardùm. Zpìtná vazba zastupuje mechanismus, kterým na základì vyhodnocení výstupu ovlivòujeme budoucí vstup do zpracování. Mùže také ovlivòovat zpracování samotné anebo jeho øízení. Mechanismus zpìtné vazby je základem systémù pro podporu rozhodování, kdy výstup (tj. rozhodnutí) koriguje v budoucnu vstup do procesu, který vede k dalšímu rozhodnutí. Obr. 1.1 ukazuje schematicky vazby mezi komponentami informaèního systému s informaèní zpìtnou vazbou. Informaèní systém existuje v urèitém prostøedí a je subsystémem systému jiného.

Vstup

Øízení

Øízení

Zpracování

Výstup

Zpìtná vazba Prostøedí (okolí systému)

Obr. 1.1 Komponenty informaèního systému Obvykle se setkáváme s tìmito informaèními systémy: l

l

l

s neformálním informaèním systémem, který je reprezentován výmìnou i zpracováním informací lidmi (word of mouth) a kdy vedle mluvy využíváme i další komunikaèní techniky (mimika, gesta apod.); s formálním informaèním systémem, který je založen na formalizovaných pracovních a informaèních tocích, realizovaných na základì popsaných politik, cílù, strategií, pravidel a pøedpisù; s informaèním systémem založeným na poèítaèích (computer-based).

Pøedmìtem našeho dalšího zájmu již bude pouze informaèní systém, který je založen na poèítaèích. Jak jsme uvedli výše, prvky tohoto systému tvoøí obecnì lidé, vhodné nástroje a metody. Nástroji budeme rozumìt technické prostøedky (hardware), metody pak tvoøí programové vybavení (software). Navíc doplníme systém o data, jakožto v minulosti zaznamenaná fakta. Hardware a software souhrnnì oznaèujeme pojmem technologie, a protože jsou orientovány na zpracování informací, používá se pro nì termín informaèní technologie. Vzrùstající akcent na zajištìní komunikace v systému vede k rozšíøení pojmu informaèní technologie na oznaèení informaèní a komunikaèní technologie (ICT – Information and Communication Technology). ICT a data dále chápeme jako informatické zdroje.

24


1

`

Informaèní systém6 pøedstavuje konzistentní uspoøádanou množinu komponent spolupracující za úèelem tvorby, shromažïování, zpracování, pøenášení a rozšiøování informací. Prvky informaèního systému tvoøí lidé, respektive uživatelé informací, a informatické zdroje. Komponenta je tvoøena jedním prvkem nebo více prvky. 6

I v oblasti definic informaèního systému existuje vìtší množství definic, které jsou si významovì blízké. Uveïme si pro pøíklad ještì další definice. V Ekonomickém slovníku z roku 2003 se uvádí, že „informaèní systém je systém, jehož prvky jsou informaèní a komunikaèní technologie, data a lidé“. Standard ISO/IEC 2382-17 formuluje informaèní systém jako „systém zpracování informací, který spolu s pøiøazenými zdroji (lidé, technické a finanèní zdroje), poskytuje a šíøí informace“. Standard ale dále doplòuje, že systém zpracování informací je jeden systém (nebo více systémù) zpracování dat a zaøízení (jako jsou kanceláøská a komunikaèní zaøízení), které slouží ke zpracování informací, a že systém zpracování dat8 je jeden poèítaè (nebo více poèítaèù), pøídavná zaøízení a programové vybavení, které slouží ke zpracování dat.

1.3 Podnikové procesy V pøedchozí èásti jsme použili tøi klíèové èásti systému – vstup, zpracování a výstup. Tento pøístup lze zobecnit a použít v rùzných oblastech, napøíklad u vyøízení požadavku zákazníka, vývoje nového produktu, vyøízení agendy sociální podpory apod. Ve všech pøípadech na základì vstupu (požadavku zákazníka) dochází k jeho zpracování (vyøizování požadavku), které vytváøí výstup (zákazník ne/získal to, co požadoval). Vlastní zpracování lze realizovat øadou aktivit, èinností, úloh apod. Souhrnnì budeme tento komplex oznaèovat pojmem proces.

`

Proces9 je definován jako soubor vzájemnì souvisejících nebo vzájemnì pùsobících èinností, který pøemìòuje vstupy na výstupy. Èinnosti využívají zdrojù (lidí, nástrojù, materiálu apod.). Proces mùže mít více vstupù a také více výstupù. 9

Obr. 1.2 schematicky ukazuje model10 procesu.

6

Dle (Ratzan, 2004). V dalším textu budeme pro oznaèení informaèního systému používat zkratku IS a pro zdùraznìní, že se jedná o IS založený na poèítaèích, budeme používat oznaèení (zkratku) IS/ICT. 7 ISO/IEC 2382-1:1993 Information technology, Vocabulary, Part 1: Fundamental terms 8 Synonymem je pojem poèítaèový systém, výpoèetní systém. 9 Dle normy ISO9000:2005, 2005 10 Model je každé úèelové a zjednodušené zobrazení skuteènosti. Pøi modelování zobrazujeme jeden systém jiným systémem. Napøíklad fyzickou poèítaèovou síť (kde prvkem je pøenosová cesta) zobrazujeme graficky (kde prvkem je namalovaná èára). Zobrazení mùže být homomorfní nebo izomorfní. Homomorfismus je pak takové zobrazení mezi systémy, které zachovává vztahy mezi systémy, ale vytváøí pøi zachování dùležité struktury jednodušší obraz, což vede k tomu, že homomorfní systém má ménì prvkù než pùvodní, zobrazovaný systém. Homomorfismus je vztah jednosmìrný, který vede k vytváøení analogií. Izomorfismus (bijektivní homomorfismus) pøedstavuje takový stav, kdy zobrazení prvkù jednoho systému na druhý je vzájemnì jednoznaèné, èili prvek je tvarovì „shodný“, tj. existuje vztah prvku jednoho systému s prvkem druhého systému a naopak. K výrazovým prostøedkùm pro tvorbu modelu patøí fyzické modely (napø. modely budov), matematicko-logické modely (napø. soustavy rovnic), rùzné grafické modely (napø. ikonografické modely), poèítaèové modely (programy) a verbální slovní popisy (napø. popisy podnikové kultury, procesu uèení se apod.).


25

1

Vstupy

Proces Událost

Cílový stav Výstupy

Obr. 1.2 Model procesu Proces je spouštìn definovanou událostí. Ty mohou být v praxi velmi rùznorodé. Jejich základní typy jsou: l

l

l

l

vstup (informací, lidí, materiálu) do podniku, napø. pøíchod objednávky od zákazníka spustí proces jejího vyøízení, pøíchod dodávky materiálu od dodavatele s dodacím listem spustí proces pøijetí dodávky apod.; èas, èasová událost – spouští procesy na základì stanoveného data nebo èasového okamžiku, napø. každé pondìlí v týdnu se spouští proces zpracování pøehledu ukonèených a rozpracovaných zakázek; interní potøeba zmìny, napø. vznik potøeby inovace produktu nebo služby (nápad nìkterého z pracovníkù), požadavek na zmìnu projektu, dokumentu; výjimeèný stav – mùže mít povahu výpadku nebo poruchy, pøíkladem mùže být porucha výrobní linky spouštìjící proces øízení oprav nebo náhradního provozu.

Informaèní a hmotnì-energetické vstupy procesu pøedstavují všechny vstupy do procesu na jeho zaèátku, pøípadnì v jeho prùbìhu. Nìkterý z tìchto vstupù mùže být spojen s jeho spouštìcí událostí. Pøíkladem mùže být materiál u výrobního procesu, objednávka apod. Výstupy procesu mají obdobnou povahu jako vstupy, tj. jsou informaèní a hmotnì-energetické. Pøíkladem mùže být hotový výrobek, odeslané zboží zákazníkovi apod. Proces pak konèí definovaným cílovým stavem, napø. výrobek byl dokonèen, objednávka byla realizována apod. S procesem je spojena celé øada charakteristik. Jedná se pøedevším o formulaci jeho cíle a úèelu, tj. odpovìdi na otázku, proè vlastnì probíhá, jaké jsou pro nìj dùvody. K dalším patøí: l l

l

l

l

26

Urèení zákazníkù procesu, tj. role, kterým jsou výsledky urèeny. Vlastnosti, jako je èas, náklady a kvalita. Tøeba u èasu se jedná celkový èas, který uplyne od spuštìní procesu k pøedání výstupù, napø. celkový èas od pøijetí objednávky po odeslání zboží zákazníkovi, nebo èistý èas procesu jako souèet dílèích èasových nárokù jednotlivých èinností v procesu. Náklady pak pøedstavují celkové náklady na všechny èinnosti v procesu, tj. náklady tøeba na materiál, mzdy a energie. Nejen pro výstupy je definovaná odpovídající úroveò kvality, ale i pro proces je i kvalita, kterou musí dodržet, formulována. Vnitøní obsah a logika procesu, která pøedstavuje jednotlivé èinnosti v procesu a jejich vzájemné vazby. V øadì pøípadù je proces rozsáhlý a komplikovaný, a proto ho rozdìlujeme na subprocesy, na které pak nahlížíme jako na samostatné procesy se všemi výše uvedenými charakteristikami. Podpùrné objekty, tj. stroje, nástroje, lidé nebo informace, které jsou procesem používány, ale nejsou procesem spotøebovány ani pøetváøeny. Øídící objekty, tj. objekty které øídí bìh procesu, reprezentované vlastníkem procesu, což je role nebo osoba kompletnì zodpovìdná za prùbìh a výsledky celého procesu. Napøíklad to mùže být pracovník, který je plnì


1

zodpovìdný za realizaci procesu vyøízení objednávky a jím formulovaná pravidla, politiky a procedury pro daný proces. Z výše uvedeného je také zøejmý vztah mezi procesem a informaèním systémem. Informaèní systém poskytuje aktérùm procesu vhodné informace pro zpracování (tj. realizaci procesu) a v pøípadì IS/ICT zajišťuje, pokud je to možné, nahrazení manuálních èinností pøi zpracování informací jejich automatizací (poèítaèovým zpracováním). Protože se v této publikaci vìnujeme podnikové informatice, budeme se dále zabývat pouze podnikovými procesy a jejich podporou informaèním systémem. Na podnikové procesy lze nahlížet z celé øady hledisek. Napøíklad z hlediska významu procesu pro naplnìní cílù organizace lze procesy rozdìlit na: l

l

l

Základní (core) procesy, kterými jsou zajišťovány hlavní podnikové aktivity bezprostøednì spojené s uspokojováním potøeb zákazníkù. Mají rozhodující podíl na „hodnotì“ finálního produktu, a tedy i na výkonnosti a kvalitì celého podniku. Pøíkladem takového procesu je proces øízení zakázky, procesy øízení inovací a vývoje nových výrobkù apod. Podpùrné procesy, které probíhají uvnitø podniku a mají, jak název napovídá, podpùrný charakter pro základní procesy. Pøíkladem mohou být napø. procesy zásobování materiálem, fakturace, pøijímání nových zamìstnancù apod. Øídící, resp. správní procesy, které pøedstavují procesy, jimiž firma definuje svoji organizaci a administrativní akty. Úèelem tìchto procesù je vìtšinou vytváøení øídících dat pro realizaci ostatních, tedy základních a podpùrných procesù. Tìmito daty jsou podnikové øády, smìrnice, pravidla apod.

Není to však hledisko jediné. Dalším mùže být èlenìní procesù podle jejich vztahu k subjektùm, které do nich vstupují nebo jsou procesem ovlivnìny. Z tohoto hlediska lze procesy dìlit na: l

l

Procesy interní, tj. probíhající v rámci jednoho podniku, pøípadnì pouze v jeho dílèích organizaèních jednotkách (závodech, divizích). Pro tyto procesy je charakteristické, že èinnosti procesu jsou vztažené pouze k danému podniku nebo útvaru, tedy zejména k vlastním pracovníkùm podniku. Pøíkladem interního procesu je øízení výrobní zakázky. Externí, mezipodnikové procesy, tj. procesy zahrnující vztahy podniku k externím subjektùm (obchodním partnerùm, státní správì), které pøekraèují hranice podniku. Jsou realizovány èásteènì u dodavatelù, u spolupracujících firem nebo pøímo u koneèného zákazníka. Hlavní charakteristikou tìchto procesù je, že èinnosti procesu se dìlí mezi nìkolik subjektù, které si v rámci prùbìhu procesu vzájemnì pøedávají vstupní a výstupní informace a rovnìž materiál, produkty atd. Pøíkladem takových procesù mùže být øízení obchodních zakázek.

Podle úrovnì øízení lze procesy dále rozdìlit na procesy strategického øízení, taktického øízení, operativního øízení, podle oblastí øízení, napø. na procesy finanèního øízení, obchodní procesy, procesy øízení majetku atd.

1.4 Podnikový informaèní systém Tak jak jsme již uvedli v obecné rovinì v kapitole 1.2, i podniková informatika si formuluje informaèní systém. Protože podniková informatika se soustøeïuje na podnik, pak tento systém oznaèujeme jako informaèní systém v podniku anebo podnikový informaèní systém.


27

1

Jeho úèel, respektive cílové chování je dáno základním požadavkem podniku na soulad ICT a podnikových procesù, resp. na adekvátní podporu podnikových procesù informaèními a komunikaèními technologiemi (business-IT alignment). V souèasné dobì je podnikový IS èasto i nositelem nových obchodních pøíležitostí, nové podoby podnikání nebo zvyšování celkové efektivity podniku. Prvky podnikového informaèního systému jsou lidé, ICT a data. Lidé pøedstavují významný prvek v informaèním systému. V podnikovém informaèním systému budeme rozdìlovat lidi do dvou základních kategorií – lidé jako uživatelé informací a ICT personál (informatici). Lidé jako uživatelé informací pøedstavují pracovníky, kteøí bezprostøednì pracují s informaèním systémem a využívají jeho výsledkù. Jsou to pracovníci nejrùznìjších podnikových útvarù, napø. úètáren, obchodních, personálních, výrobních a dalších oddìlení. Jsou to manažeøi v celé øídící struktuøe podniku, obchodníci, technici, administrativní pracovníci, kteøí sbírají data, aktualizují datové báze, zpracovávají obchodní dokumenty a nejrùznìjší pøehledy. Velmi podstatnou náplní uživatelské role je i konzultaèní a analytická kooperace s interními i externími informatiky na pøípravì a realizaci nových øešení a úloh. Role uživatele tak pøedpokládá: l l l l l

samostatnou obsluhu aplikaèních software a interpretaci získaných výsledkù, sledování a analýzy stavu provozovaných aplikací, specifikaci pøípadných problémù, formulaci nových potøeb a požadavkù vzhledem k potøebám podniku i ke zmìnám v legislativì, urèení vazeb dané aplikace k ostatním aplikacím, formulace zadání nových, resp. rozvoje stávajících aplikací IS/ICT.

V roli vlastníka chápeme majitele podnikù a èleny pøedstavenstva nebo dozorèích rad. Rozlišení mezi vlastníkem a uživatelem je významné pro èasto odlišný vztah obou tìchto skupin k vývoji a provozu informaèního systému – vlastník ho financuje, rozhoduje o jeho rozvoji a investicích do nìj, uživatel ho bezprostøednì využívá. Pøedevším vlastník musí reálnì posuzovat úroveò informatiky svého podniku, její oèekávané a skuteèné efekty a náklady s ní spojené. Rolí partner se rozumí všichni pracovníci dodavatelù, zákazníkù a dalších externích organizací, kteøí rùznou mìrou využívají informace a informaèní služby poskytované informatikou daného podniku anebo do jejích databází vstupují a zadávají vlastní (externí) data, napø. nové nabídky zboží, informace o místì a stavu dodávaného zboží apod. Pøi stále silnìjším propojování informaèních systémù mezi rùznými podniky, má proto i partnerská role vìtší význam. Role informatikù rozlišujeme na interní, tj. pracovníky útvarù informatiky v rámci vlastního podniku, a externí, tj. dodavatele technických a softwarových produktù a poskytovatele rùzných druhù služeb. Jsou to lidé pùsobící v poèítaèových, softwarových nebo konzultaèních firmách. Informatikem, respektive IT odborníkem je ten, „jehož pracovní zaøazení vyžaduje specifické informatické dovednosti a znalosti o tvorbì, nasazení a provozu informaèních a komunikaèních technologií a o využití ICT v aplikaèní oblasti“ (Doucek a další, 2007). K základním rolím patøí (Doucek a další, 2007): l

28

Byznys analytik – architekt. K jeho základním aktivitám patøí: n analýza, návrh, standardizace a optimalizace podnikových procesù a podnikové organizace, n analýza a návrh byznys efektù dosahovaných prostøednictvím IS/ICT, n analýza a návrh øízení znalostí v organizaci, n analýza rizik IS/ICT a zajišťování kontinuity podnikání, n návrh informatických služeb podporujících podnikové procesy, n nasazení a kastomizace standardního software,


1

n návrh, vytváøení a vyhledávání informaèního obsahu na podporu øízení organizace. V organizacích se v této roli mùžeme setkat s následujícími profesemi – analytik, návrháø podnikových procesù, byznys konzultant, implementátor standardního software, znalostní inženýr, informaèní zprostøedkovatel, pracovník competitive intelligence.

l

Manažer rozvoje a provozu IS/ICT, mezi jehož èinnosti patøí: n vypracování informaèní strategie, n vypracování sourcing11 strategie, n øízení ICT projektu, n øízení informatických služeb a jejich dodávky, n øízení provozu IS/ICT, jeho zmìn, rizik, ekonomiky kvality a øízení bezpeènosti. K profesím, které tuto roli naplòují, patøí – vedoucí IT oddìlení (útvaru)12, manažer projektu, manažer provozu, manažer bezpeènosti, manažer kvality IS/ICT a manažer ekonomiky IS/ICT.

l

Obchodník s ICT produkty a službami zajišťuje: n marketing, prodej, nákup ICT produktù a služeb (vèetnì formulace definované úrovnì služeb13), n dle principù sourcing strategie øízení dodavatelsko-odbìratelských vztahù a vyjednávání s partnery z rùzných národních a podnikových kultur. V této roli vystupuje øada profesí – napø. obchodník s ICT produkty a službami, pracovník øídící dodávky externích produktù a služeb do organizace, manažer klíèových zákazníkù14.

l

Vývojáø nebo IS architekt, k jehož aktivitám patøí: n analýza a návrh aplikací IS, vèetnì návrhu technologické a datové architektury IS/ICT organizace, n návrh databází vèetnì dolování dat z nich, n programování, testování a dokumentace aplikací, n údržba a správa verzí ICT a integrace. V této roli se jde setkat s øadou profesí – napø. vývojáø, programátor, tester, systémový integrátor, ICT architekt, manažer vývoje aplikaèních systémù a technologií.

l

Správce aplikací a IT infrastruktury zajišťuje typicky øadu aktivit – napø. správu aplikací, databází, datových skladù, komunikaèních sítí, základního software, technických prostøedkù, webu vèetnì správy konfigurací výše uvedených prostøedkù a také podpory uživatelù aplikací. Roli èasto zastupují následující profese: správce aplikace, databáze, sítì, dat, bezpeènosti, ale také tøeba poèítaèový technik apod.

Data (podniková data15), jakožto další prvek podnikového informaèního systému pøedstavují zaznamenaná fakta o všech podstatných skuteènostech, které souvisejí s aktivitami podniku. V zásadì je lze rozdìlit do tøí klíèových skupin na:16

11 12 13 14 15 16

Principy formulující, které služby, procesy a zdroje vlastnit (a internì spravovat) a které nakupovat od partnerù. Chief information officer (CIO) Service Level Agreement (SLA) Account manager Kromì podnikových dat ale IS/ICT zahrnuje i další data – viz kapitola 3. Dle (Kumar a další, 2004)


29

1

l

l

l

Data o spoleèenských podmínkách podnikání. Do této skupiny zahrnujeme zaznamenané údaje o politických a státních oèekáváních v oblasti úrovnì stability prostøedí, demografických, sociálních a ekonomických trendech, rozvoji technologií, jakožto inhibitoru vzniku nových produktù a služeb. Dále zde zahrnujeme údaje o faktorech ovlivòující výrobu, jako jsou pracovní síla, materiál a kapitál. Data o trhu, kam zaøazujeme data o poptávce po komoditách podniku, tj. zboží a službách, o stavu konkurence, resp. její výkonnosti, aktuálních aktivitách a plánech, o rozvoji komodit, oèekávaných fúzích a akvizicích. Interní data podniku tvoøící pøedpoklady k tomu, aby podnik mohl reagovat na své okolí. Do této skupiny patøí plány a pøedpovìdi prodeje, vèetnì finanèních plánù, údaje formulující požadavky na alokaci podnikových zdrojù. Patøí sem i data o úrovni vnitøní nabídky zdrojù, tj. pracovní síly, kapitálu, strojù a zaøízení a data o pøípadných omezeních fungování podniku, procedurách a pravidlech fungování podniku.

Informaèní a komunikaèní technologie pøedstavují širokou škálu technických prostøedkù a programového vybavení. Termín technické prostøedky (hardware – HW) vznikl z potøeby oddìlit fyzický aspekt poèítaèù, komunikaèních prostøedkù a dalších technických zaøízení od programù, které jsou do tìchto zaøízení vkládány a které s tìmito zaøízeními manipulují. Pro souhrn všech programù se používá termín programové vybavení (software – SW). Technické prostøedky zahrnují poèítaèe, pøídavná zaøízení poèítaèù, samostatné nosièe dat, kanceláøská zaøízení, komunikaèní prostøedky (telekomunikaèní a poèítaèové sítì, vèetnì koncových zaøízení) a další specializovaná zaøízení (napø. linky pro balení listovních zásilek, generátor elektrického proudu apod.). Komplex programového vybavení rozdìlujeme do tøí základních skupin: l

l

l

Základní programové vybavení (základní software – ZSW), kam patøí software, který umožòuje provozovat programy z ostatních skupin programù, zajišťuje komunikaci programù, které jsou provozovány na rùzných poèítaèích a které jsou propojeny v síti, a také prostøedky, které umožòují efektivnì integrovat programy do vìtších celkù. Aplikaèní programové vybavení (aplikaèní software – ASW), které realizuje zpracování informací a podporu podnikových procesù. V podniku se jedná o následující kategorie ASW: n aplikaèní software transakèního charakteru, který je orientován na informaèní podporu a automatizaci obchodních transakcí, jako jsou e-commerce aplikace, øízení výroby apod.; n aplikaèní software pro podporu rozhodování na všech úrovních øízení (strategické, taktické a operativní); n aplikaèní software pro podporu rozvoje a inovací produktù a služeb podniku; n infrastrukturní aplikaèní programové vybavení, které zahrnuje podporu aktivit napøíè organizací (pøípadnì jsou souèástí výše uvedených ASW) a kam patøí napø. správa dokumentù a obsahu, øízení pracovních týmù apod. Programové prostøedky pro podporu vývoje ASW, jeho implementaci a sledování provozu IS/ICT.

Obr. 1.3 schematicky znázoròuje ICT. ICT uvedené v obrázku rozdìlíme z dùvodu efektivnìjšího øízení informaèního systému na dvì kategorie. Obsahem první bude aplikaèní programové vybavení, u zbylých èástí ICT zùstaneme u oznaèení informaèní a komunikaèní technologie.

30


Programové vybavení

1

Aplikaèní programové vybavení

Základní programové vybavení

Programové vybavení pro podporu vývoje a implementaci ASW, sledování provozu IS/ICT

Internet

r o P g a r o mé v v b y va e n í

Technické prostøedky

Poèítaèové a telekomunikaèní sítì

Obr. 1.3 Základní skupiny prostøedkù tvoøící ICT Aplikaèní programové vybavení, ICT, data a ICT personál jsou zároveò zdroji podnikové informatiky (Boh a další, 2006–2007). ICT a ICT personál jsou základnou pro souèasné i budoucí aplikaèní programové vybavení a prostøedím pro uložení a transparentní zpøístupnìní dat a vytváøejí tzv. ICT infrastrukturu17 informaèního systému (Davenport a další, 1992). Vedle výše uvedených zdrojù podniková informatika využívá i další zdroje: spoleèné zdroje organizace (infrastrukturní zdroje) – energie, majetek (budovy, kanceláøské zaøízení), pravidla a smìrnice apod., infrastrukturní zdroje segmentu trhu (napø. de jure a de facto standardy v daném oboru), veøejné (spoleèenské) infrastrukturní zdroje (napø. vzdìlání, právo, telekomunikace apod.).

l

l l

ICT infrastruktura (viz obr. 1.4) je svému okolí poskytována formou služeb (Weill, 1992). Ke službám spojeným s fyzickou èástí infrastruktury patøí dle Weilla (2002) tyto služby: Služby komunikaèních kanálù, které zahrnují øízení a integraci všech elektronických komunikaèních kanálù, které organizaci propojují se zákazníky a partnery. Jedná se napø. o internet (Web, ICQ, e-mail), klasickou poštu (naskenovanou anebo oznaèenou), telekomunikace (fax, telefon), EDI (Electronic Data Interchange) apod. Služby spojené s øízením rizik a bezpeèností IS/ICT, v nichž je zahrnuto zajištìní stanovené úrovnì informaèní bezpeènosti, která je reprezentovaná sadou vlastností (dùvìrnost, integrita, dostupnost, prokazatelnost, spolehlivost, nepopiratelnost), a také vytvoøení prostøedí dùvìryhodnosti IS/ICT pro všechny zainteresované strany (zákazníci, partneøi, zamìstnanci, vlastníci). Komunikaèní služby orientované na zajištìní pøenosových tras mezi jednotlivými místy zpracování byznys aplikací prostøednictvím poèítaèových a telekomunikaèních sítí. Služby správy dat. Jejich cílem je nabídnout takové prostøedí, které umožní øídit data nezávisle na aplikacích, vèetnì zajištìní jejich transparentní dostupnosti pro všechny, kteøí data vyžadují.

l

l

l

l

17

ICT infrastruktura je dále rozšíøena o IT procedury, které propojují ICT personál a ICT (Darnton a další, 1992) a umožòují jejich využití v IS/ICT. V naší publikaci nebudeme IT procedury chápat jakožto samostatný zdroj.


31

1

l

l

Služby správy ICT vybavení jsou orientovány na aktivity spojené se správou a øízením technologických prvkù infrastruktury (hardware i základní software) a zahrnují napø. správu koncových zaøízení, serverù, ale také sestavení vhodného prostøedí pro vývoj a implementaci nových systémù (byznys aplikací). Služby správy infrastrukturních aplikací. Nìkteré aplikace (napø. správa lidských zdrojù, správa dokumentù, úèetnictví apod.) jsou využívány napøíè organizací. Takové aplikace jsou zaøazeny do ICT infrastruktury s cílem nabídnout unifikované a sdílené služby tìchto aplikací tam, kde jsou potøeba.

Aplikace

Øízení komunikaèních kanálù Øízení rizik a bezpeènosti Správa komunikací Správa dat Správa ICT vybavení Správa infrastrukturních aplikací

ICT

Data

Sdílné služby ICT infrastruktury IS/ICT øízení Architektura a standardy ICT vzdìlávání ICT výzkum a vývoj

ICT personál ICT infrastruktura

Infrastruktura organizace Infrastruktura segmentu trhu Spoleèenská infrastruktura

Obr. 1.4 Služby a zdroje tvoøící ICT infrastrukturu Ke službám orientovaným na øízení patøí: l

l

l

l

Služby øízení IS/ICT, tedy komplex služeb spojených s plánováním, øízením a koordinací projektù IS/ICT, SLA (Service Level Agreement) apod. Služby spojené s formulací architektury IS/ICT a adopcí ICT standardù. Do této skupiny služeb se zahrnují klíèové politiky a pøístupy, kterými formulujeme užití ICT a stanovujeme budoucí rozvoj IS/ICT tak, aby byl v souladu s cíli organizace, reprezentovanými formulovanou strategií. Služby spojené s ICT vzdìláváním. Do této kategorie patøí jak školící služby v užití IS/ICT tak i takové vzdìlávání manažerù, které jim umožní identifikovat hodnotu získanou užitím a investováním do ICT. Služby zamìøené na výzkum a vývoj se orientují na hledání nových možností a pøíležitostí, které mùže ICT podniku nabídnout.

Klíèovými vlastnostmi prvkù je úroveò schopnosti prvkù pružnì, hbitì a efektivnì reagovat na požadavky okolí systému (Byrd a další, 2000) a vyjadøují se:

32


1

l

l

l

Schopností být integrován do vìtšího celku, kterou vyjadøujeme schopností být propojen s jiným prvkem (ať již se nachází uvnitø anebo vnì organizace) a úrovní kompatibility (sluèitelnosti a snášenlivosti) integrovaných prvkù. Úrovní modularity, tj. stupnìm zpùsobilosti ke zmìnì a k rozšíøení bez závažných dopadù na celek, kterou charakterizujeme granularitou funkcionality, jež komponenta pro celek nabízí, a mírou, do jaké je komponenta transparentní ostatním prvkùm. Úrovní znalostí, zkušeností a dovedností, pøièemž se oèekává, že disponují technickými znalostmi a zkušenostmi (napø. jsou schopny spravovat napø. operaèní systémy, poèítaèové sítì, databáze anebo také programovat v konkrétním prostøedí apod.), mají dispozici k porozumìní, kde a jak nasadit ICT tak, aby efektivnì podpoøily cíle organizace, jsou schopny porozumìt podniku a mají dispozici k nalezení odpovídajících øešení a také disponují dovednostmi v oblasti øízení (napø. plánování, organizování, vùdcovství apod., vèetnì schopností pracovat v kolaborativním prostøedí).

Na konec mùžeme schematicky (viz obr. 1.5) znázornit podnikový informaèní systém a jeho vztah k podniku.

Podnik

Technologie (technický systém)

Podnikové procesy

Systém øízení

Lidé

Informaèní systém

Uživatelé informací a ICT personál

Informaèní systém

Aplikace (zpracování)

Data

ICT

Obr. 1.5 Podnikový informaèní systém a jeho vztah k podniku


33

1

Podnikový informaèní systém je subsystémem podniku a dodává vhodné informace. ICT v nìm hrají roli technického systému18, který je využíván pøi zpracování dat. Aplikace hrají roli dodavatele informací. ICT personál realizuje služby spojené s øízením informaèního systému.

1.5 Podniková informatika Na základì výše uvedených informací lze formulovat obsah podnikové informatiky. Lze ji chápat jako aplikaci, proces a systém. V pøípadì, kdy chápeme podnikovou informatiku jako aplikaci, pak je její obsah totožný s obsahem informatiky, kterou jsme uvedli na poèátku této kapitoly, jen s tím, že se omezujeme na prostøedí podniku jakožto systému. Definice podnikové informatiky potom zní:

`

Podniková informatika „studuje“ vyjádøení a podobu informací, jejich zpracování a pøenášení v podniku.

Na „studium“, respektive na jeho systematiènost je možné, podobnì jako to formuluje Kotler (Kotler a další, 2007) v oblasti marketingu, nahlížet jako na proces. Potom:

`

Podniková informatika je komplexním procesem zajištìní informaèních potøeb spojených s vykonáváním a øízením aktivit (procesù) podniku.

Uvedená definice akcentuje procesní pøístup, v jehož rámci jsou informaèní potøeby zajišťovány, pøièemž komplexní proces øeší i situace, kdy neexistují vhodné transformaèní mechanismy, tj. musí být „vytvoøeny“. Podnikový informaèní systém je pak prostøedkem, který je využíván v uvedeném procesu. V zásadì existuje øada pøístupù, které zaèleòují aktivity podnikové informatiky jakožto útvaru (IT útvar) podniku do jeho organizaèní struktury (Voøíšek a další, 2008). Ve stabilních organizaèních strukturách19 je IT útvar zaèlenìn jako samostatná odborná organizaèní jednotka zajišťující funkce rozvoje a provozu podnikového informaèního systému (viz obr. 1.6a) anebo IT útvar je sice samostatná organizaèní jednotka, ale na nižší organizaèní úrovni, tj. je podøízena jiné organizaèní jednotce, zpravidla financím (viz obr. 1.6b). U velkých podnikù, nadnárodních korporací apod. pak existuje kombinace obou pøístupù a na úrovni vedení spoleènosti existuje tzv. strategický IT útvar a u jednotlivých poboèek pak jejich vlastní IT útvary. U flexibilní organizaèní struktury20 se využívá maticové struktury (viz obr. 1.6c), ve které jsou vzájemnì propojeny dvì organizaèní struktury vytvoøené dle odlišných kritérií. Èasto se lze setkat také s projektovou organizaèní strukturou, která se vyznaèuje tím, že napøíè funkèními organizaèními jednotkami jsou vytváøeny realizaèní týmy pro jednotlivé projekty (viz obr. 1.6d).

18

Technickým systémem v podniku rozumíme množinu prostøedkù, které jsou využívány pøi zpracování vstupù na výstup. Vyznaèují se specializací, centralizací a vysokou formalizací. Pøi klasifikaci organizaèních struktur podle dìlby pravomocí patøí k historicky nejstarším organizaèní struktura, ve které je jednoznaèná vazba mezi podøízeným a nadøízeným (tj. podøízený má vždy pouze jednoho nadøízeného) a která je nazývána liniová. 20 Vyznaèují se decentralizací, malou formalizací, širokým rozsahem øízení a meziúrovòovými a mezifunkèními týmy. 19

34


1

Øeditel Výroba

Nákup

Prodej

Finance

Marketing

Personalistika

IT útvar

(a) Model funkèní organizaèní struktury Øeditel Výroba

Nákup

Prodej

Finance

Marketing

Personalistika

IT útvar (b) Postavení „IT útvaru“ ve vztahu podøízenosti k jiné organizaèní jednotce Øeditel Sklad

Distribuce

Øeditel IT útvar

Øízení projektù

Finance

Marketing

IT útvar

Obchod

Praèky Myèky Projekt A Lednice Projekt B (c) Model maticové organizaèní struktury

Tým A Tým B

(d) Model projektové organizaèní struktury

Obr. 1.6 Pozice podnikové informatiky jako útvaru v podniku (zdroj: Voøíšek a další, 2008)

Ò

Z kapitoly vìnované vymezení podnikové informatiky vyplývají následující závìry: l

l

l

„informace“ je zpráva o tom, že nastal urèitý jev z množiny možných jevù, a tím se u nás (u pøíjemce) snižuje (nebo zcela odstraòuje) neznalost o tomto jevu; informaèní systém pøedstavuje konzistentní uspoøádanou množinu komponent spolupracující za úèelem tvorby, shromažïování, zpracování, pøenášení a rozšiøování informací; podniková informatika je komplexním procesem zajištìní informaèních potøeb spojených s vykonáváním a øízením aktivit (procesù) podniku.


35

2

2. Informaèní a komunikaèní technologie Informaèní a komunikaèní technologie jsou zdrojem podnikové informatiky, prvkem informaèního systému a souèástí ICT infrastruktury informaèního systému.

y

Cílem této kapitoly je vytvoøit základní obsahový pøehled informaèních a komunikaèních technologií jako pøedpoklad pro lepší pochopení možností aplikací podnikové informatiky.

Jak jsme již uvedli v kapitole 1.4, pøedstavují informaèní a komunikaèní technologie (ICT) komplex technických a programových prostøedkù vèetnì komunikaèních prostøedkù, které umožòují zpracování aplikací a manipulaci s daty. Souèástí ICT je i vyjádøení principiálního uspoøádání komponent ICT, které oznaèujeme pojmem výpoèetní model a které formuluje také principy zpracování aplikací.

2.1 Technické prostøedky Technické prostøedky tvoøí široká škála rùzných zaøízení (stroje a pøíslušenství), zejména pak: l l l l

poèítaèe, jejich pøídavná zaøízení a samostatné nosièe dat, technické prostøedky komunikaèních sítí (napø. modemy, pøenosové linky apod.)1, kanceláøská zaøízení (napø. skartovací stroje apod.) a specializované technické zaøízení (napø. linky pro balení listovních zásilek, generátory elektrického proudu apod.).

2.1.1 Poèítaèe Poèítaè je strojem, jehož strukturu popsal matematik John von Neumann (von Neumann, 1945) s tím, že je nezávislá na zpracovávaných problémech. Pro øešení problému se musí zvenèí zavést a do pamìti poèítaèe uložit návod na jeho zpracování (program). Neumannem popsaný technický systém2 se v podstatì ve zdokonalené podobì používá dodnes. Rozrostl se pouze poèet rùzných pøídavných zaøízení, propojení na spotøební elektroniku a zajištìní komunikace v sítích. Klasifikovat poèítaèe je v dnešní dobì velmi obtížné. Jednou z možností je klasifikace podle generací3. Protože všechny souèasné poèítaèe patøí do tzv. ètvrté generace, volíme jako klasifikaèní hledisko zpùsob využití poèítaèe. Na jeho základì se dìlí poèítaèe na tzv. osobní poèítaèe (PC – Personal Computer), a služební poèítaèe (server).

1 2 3

Vìnovat se jim budeme v kapitole 2.3 a pøíloze 6. Jeho obsahu a principùm se vìnuje pøíloha 2. Viz napø. Wikipedia: Historie poèítaèù (http://cs.wikipedia.org/wiki/Historie_pocitacu)

Informaèní a komunikaèní technologie

37

2

Osobní poèítaèe pøímo zpracovávají požadavky uživatelù anebo vizualizují (zobrazují) výsledky zpracování jiných, zejména služebních poèítaèù. Osobní poèítaèe lze rozdìlit na nepøenosné, pøenosné a mobilní: l

l

l

Nepøenosné osobní poèítaèe (stacionární, desktop) jsou tvoøeny skøíní, která obsahuje základní komponenty, dále jsou tvoøeny samostatným zobrazovacím zaøízením (monitorem) a vstupními zaøízeními (klávesnicí a myší). Specifickým pøípadem nepøenosného PC je tzv. pracovní stanice, která je vybavena dostateènou kapacitou a výkonem pro zpracování nároèných výpoètù, napø. v oblasti konstrukèních prací (CAD – Computer Aided Design), zpracování videa apod. Pøenosné osobní poèítaèe (notebook, laptop) sdružují všechny komponenty, vèetnì zobrazovacího a vstupního zaøízení, do jedné skøínì. Vedle toho umožòují využít baterie jako zdroj napájení. Z dùvodu vìtšího komfortu práce se èasto využívá i externích vstupních a výstupních zaøízení. Lze pøitom využít i tzv. „docking station“ anebo replikátor portù, což jsou propojovací moduly, k nimž jsou jednotlivá zaøízení již pøipojena a pomocí standardizovaného rozhraní k nim lze jednoduše pøipojit i celý pøenosný poèítaè. V kategorii notebookù se objevuje i varianta tzv. netbookù, která je kompromisem mezi vysokou mobilitou (nízká hmotnost a malá velikost) a nízkou cenou na stranì jedné, a nižší použitelností a horší ergonomií na stranì druhé. Za samostatnou skupinu lze považovat zaøízení oznaèovaná jako mobilní (Handheld, Personal Digital Assistant, mobilní komunikátory), která umožòují realizovat operace jako osobní poèítaè a navíc je možné se s nimi pøi práci pohybovat.

Specifickou kategorií osobních poèítaèù, která však nesouvisí s podnikovou informatikou, jsou poèítaèe, které se oznaèují jako Home Media Center (centra domácí zábavy). Zpravidla se jedná o vyhrazený osobní poèítaè nebo specifická zaøízení (napø. herní konzole) se specifickou programovou výbavou. Ta je orientována na pøehrávání a zaznamenávání rùzných multimediálních dat (hudba, video, film apod.), na možnost sledování a zaznamenávání televizního vysílání a také na pøipojení do sítì internet. Vedle funkèních požadavkù (vèetnì nízké úrovnì hluku) se na taková zaøízení kladou i požadavky estetické. Služební poèítaèe vykonávají své èinnosti na základì požadavkù osobních èi jiných služebních poèítaèù, tzn. že uživatel na nì prostøednictvím osobního poèítaèe pøenáší požadavky na zpracování. Protože musí obsluhovat velké množství požadavkù a musí pracovat nepøetržitì, je nutné, aby jejich technická a technologická konstrukce byla k tomu pøizpùsobena. Pro zajištìní potøebného výkonu a využití existuje nìkolik kategorií služebních poèítaèù: l

l l

poèítaèe støední tøídy (Midrange) – používané pro øešení úloh na úrovni pracovních týmù a menších organizací, støediskové poèítaèe (Mainframe) – používané pro úlohy na úrovni vìtších organizací, superpoèítaèe (Supercomputer) – používané pro øešení velmi složitých technických výpoètù, provádìní simulací v oblastech molekulárního nebo genetického výzkumu, kosmického výzkumu apod.

Služební poèítaèe mohou vypadat obdobnì jako osobní poèítaèe, tj. jsou u nich použity obdobné skøínì, zpravidla s jinými rozmìry. Èastìjším pøípadem je jejich osazení do speciálních rámù (rack).

38


2

Obr. 2.1 Servery spoleènosti IBM, první ve skøíni obdobné PC, zbylé pro osazení do rámu

2.1.2 Další technické prostøedky V podnikové informatice se využívají vedle poèítaèù a jejich periferií i další technické prostøedky. Øada tìchto prostøedkù souvisí se zajištìním bezpeènosti informaèního systému, jsou to zejména: l

l

l l

prostøedky chránící systém pøed výpadky elektrického proudu (UPS, dieselové generátory) a pøed kolísáním elektrického napìtí (pod- a pøepìťová ochrana), prostøedky zajišťující požadované klimatické podmínky (klimatizace, vèetnì zajištìní vhodné vlhkosti vzduchu), prostøedky protipožární ochrany, prostøedky ochrany pøed neoprávnìným vstupem (elektronické zámky, dohledové systémy) atd.

Další skupina prostøedkù pak souvisí s konkrétní aplikací, napø.: l l

skartovací zaøízení v definované tøídì bezpeènosti pro nevratné znièení tiskových výstupù a optických diskù, specializované linky pro balení velkého objemu tiskových výstupù apod.

2.2 Základní programové vybavení Uvedli jsme, že do poèítaèe musíme zavést program, kterým øešíme konkrétní typ úlohy. Množina všech programù tvoøí programové vybavení. Z ryze praktických dùvodù došlo k rozdìlení programového vybavení na programové vybavení realizující základní funkce (základní programové vybavení) a aplikaèní programové vybavení, které implementují zpracování dodávající podnikovým procesùm informace. Základní programové vybavení (základní software – ZSW) pøedstavuje skupinu programového vybavení, které øadíme do ICT a které aplikacím a prostøedkùm vývoje aplikací zajišťuje: l

l

vhodné prostøedí, ve kterém mohou být aplikace provozovány, aniž by jejich provoz byl ovlivnìn skuteèností, že jsou provozovány na poèítaèi urèitého výrobce, možnost rùzné aplikace integrovat do (kvalitativnì) vìtších celkù,


39

2

l

transparentní komunikaci mezi èástmi aplikací èi mezi rùznými aplikacemi v pøípadì, že jsou provozovány na rùzných poèítaèích.

Do základního programového vybavení øadíme operaèní systémy, podpùrné programy (utility), služební programy, middleware a virtualizaèní prostøedky4.

2.2.1 Operaèní systémy Operaèní systém poskytuje komplex veškerých øídících funkcí nezbytných pro práci poèítaèe bez ohledu na to, jaké aplikaèní programy se na nìm provozují.

`

Operaèní systém (OS – Operating System) je množina programù, která øídí všechny ostatní programy zpracovávané poèítaèem.

Po spuštìní poèítaèe je jádro operaèního systému (kernel) zavedeno do vnitøní pamìti poèítaèe v prùbìhu procesu „bootování“. Operaèní systém pak poskytuje následující funkce: l

l

l

l

l

Øídí a spravuje technické prostøedky poèítaèe, napø. pøidìluje jednotlivým programùm èas procesoru, kapacitu vnitøní pamìti, pøístup k vstupním a výstupním zaøízením apod. Vytváøí pro zpracovávané programy odstiòující vrstvu, aby programy mohly pracovat s rùzným hardware (tj. odstiòuje je od technických specifik komponent poèítaèe). OS komunikuje s technickými prostøedky prostøednictvím specializovaných programù, tzv. ovladaèù (driverù), které jsou zpravidla vyvinuty výrobcem technického prostøedku a jsou tomuto prostøedku „ušity na míru“. Pro maximální využití schopností technického prostøedku je dùležité, aby jeho ovladaèe byly na poèítaèi instalovány. Prostøednictvím souborového systému zajišťuje pøístup k datùm a programùm, které jsou uloženy na discích a dalších vnìjších pamìtech poèítaèù. Øídí zpracování jednotlivých programù a v pøípadì jejich soubìžného zpracování urèuje, které programy budou zpracovány, v jakém poøadí, kolik èasu jim bude pøidìleno a s jakou prioritou. V pøípadì, že poèítaè disponuje více procesory, pak zajišťuje rozdìlení zpracování programù mezi nì. Prostøednictvím síťových rozhraní podporuje komunikaci mezi poèítaèi.

V souèasné dobì je k dispozici celá øada operaèních systémù. Tab. 2.1 ukazuje jejich možné rozdìlení a základní pøedstavitele. S operaèním systémem komunikují: l

4

40

Uživatelé prostøednictvím definovaného uživatelského rozhraní. To mùže být grafické, napø. známá „okna“ (Windows) nebo pøíkazovì orientované. V pøíkazovì orientovaném rozhraní zadáváme jednotlivé pøíkazy operaèního systému do pøíkazového øádku, napø. u OS MS Windows pøíkaz „dir“ slouží pro výpis adresáøe. U grafického rozhraní využíváme polohovacích zaøízení k výbìru a spouštìní požadovaných akcí, pøièemž uvedené aktivity mohou být vyvolány také rùznými kombinacemi kláves. Prostøedkùm middleware, které úzce souvisejí s integrací aplikací, se budeme vìnovat samostatnì v kapitole 16 a pøehled virtualizaèních technologií je uveden v pøíloze 5.


2

Programy prostøednictvím aplikaèního programového rozhraní (API – Application Programming Interface), což je množina programových funkcí spojených do programových knihoven, které programy využívají pøi požadavku na služby operaèního systému. Tak mohou programy pøistupovat k souborùm na vnìjších pamìtech poèítaèe (viz dále) anebo tøeba využívat prvkù grafického uživatelského rozhraní (tlaèítka, okna atd.)

l

Tab. 2.1 Pøehled operaèních systémù Pro osobní poèítaèe l

Rodina Microsoft Windows (Windows 98, Windows XP, rùzné edice Windows Vista)

l

Mac OS X

l

Linux

Serverové OS

Pro mobilní zaøízení

l

Windows 2008 server

l

Pocket PC

l

MAC OS Server

l

Palm OS

l

Solaris

l

Windows CE

l

Red Hat Linux

l

Symbian OS

l

Novell Netvare

l

Android

l

AIX

l

HP-UX

Speciální OS l

IOS pro komunikaèní zaøízení (routery/switche)

l

TRON – nejrozšíøenìjší OS na svìtì, používaný ve spotøební elektronice

l

Nucleus RTOS použitý v GPS zaøízeních

Operaèní systém chápe data a programy uložené ve vnìjší pamìti jako specifickou jednotku dat, kterou oznaèujeme termínem soubor.

`

Soubor je v poèítaèovém systému posloupnost (proud) bitù uložených jako samostatná jednotka. Základní operace se souborem zajišťuje operaèní systém (otevøení, ètení posloupnosti bytù, zrušení, pojmenování, pøejmenování apod.).

Soubory jsou organizovány a uloženy v souborovém systému (filesystem) operaèního systému. Ten se však nezajímá o vnitøní uspoøádání konkrétního souboru. To zajišťují jiné programy, jejichž úkolem je uspoøádat data do vhodné posloupnosti a této posloupnosti rozumìt (tøeba program pro úpravu fotografií, který zná jak uspoøádat data pro konkrétní formát uložení). Výjimkou jsou soubory, které obsahují spustitelný program. Operaèní systém musí rozumìt uspoøádání tohoto programu, aby byl schopen zajistit jeho vykonání (zpracování). Operaèní systémy nabízejí nìkolik rùzných souborových systémù, které se liší poskytovanou funkcionalitou (strategie ukládání souborù a pøístupu k nim, ochrana souborù apod.).5 Souborový systém se na pevné disky (èi jiné vnìjší pamìti) dívá pohledem tzv. svazkù (oddílù). Jeden svazek mùže být umístìn na jednom nebo u nìkterých OS na více pevných discích a zároveò na jednom pevném disku mùže být více svazkù. Svazky jsou pak rozdìleny na tzv. klastry (cluster) nebo sektory s definovanou velikostí. Klastry si lze pøedstavit jako „buòky vèelích pláství“. Soubor, který je v souborovém systému uložen, zabírá i nìkolik klastrù, pøièemž platí, že soubor nemusí zabírat za sebou jdoucí klastry. V takovém pøípadì se hovoøí o fragmentaci souboru. V pøípadì, že soubor neobsadí celý klastr, pak místo, které „zbylo“, již nemùže být doplnìno jiným souborem. Informaci o místì uložení souboru si souborový systém udržuje v alokaèní tabulce. Vysoká fragmentace souborù zpùsobuje prodlužování èasu pøístupu k souboru, a proto je vhodné pravidelnì fragmentaci souborù kontrolovat a pøípadnì provést tzv. defragmentaci, neboli pøeuspoøádání souborù tak, aby soubory zabíraly sektory kontinuálnì. 5

Napø. u operaèních systémù MS Windows XP je v nabídce souborový systém NTFS (New Technology File System), FAT (File Allocation Table) a FAT32 (Rozšíøený FAT), u Unixových operaèních systémù je to napø. UFS, ext2, ext3 ReiserFS, NFS.


41

2

Souborový systém nabízí též prostøednictvím svého rozhraní i logický pohled na soubory. Ve vìtšinì OS se jedná o hierarchickou (stromovou) strukturu, kde koøenem (root) struktury je buï pøíslušný svazek (OS MS Windows) èi obsahuje jeden strom pøes všechny svazky (OS Unix). Jeho oznaèování vychází z použitého operaèního systému, napø.: l l

v rámci OS MS Windows jsou pojmenovány písmeny anglické abecedy s oddìlovaèem „:“, napø. a:, f: apod.; v OS Linux je první disketová jednotka pojmenována jako /dev/fd0, první disk s rozhraním IDE je pojmenován jako /dev/hda.

Jednotlivé úrovnì hierarchické struktury obsahují jak bìžné soubory (napø. datové), tak i soubory speciální – tzv. adresáøe (directory, resp. složky souborù). V rámci adresáøe pak jsou opìt umístìny soubory pro danou úroveò a vìtev stromu. Každý adresáø obsahuje minimálnì dva soubory, které umožòují pohyb po adresáøové struktuøe. Jeden se jmenuje (teèka) a je to soubor, který v adresáøové struktuøe ukazuje na aktuální adresáø. Druhým je soubor (dvì teèky), který ukazuje na nadøízený adresáø. V øadì pøípadù tyto soubory nebývají zobrazovány, pøípadnì jsou nahrazeny nìjakou ikonou (viz obr. 2.2).

Obr. 2.2 Výpis adresáøe Souborový systém definuje i zpùsob pojmenování souborù. Jedná se pøedevším o strukturu jména souboru. Jméno je tvoøeno posloupností povolených znakù s tím, že mùže obsahovat rozšíøení (extenze). Rozšíøení se uvádí za oddìlovaè (znak teèka). K nepovoleným znakùm ve jménech souborù patøí napø. v MS Windows: \ / : * ? “ < > |. Celé jméno souboru je pak tvoøeno cestou vedoucí od koøene stromu k tomuto souboru, vèetnì jména souboru. Jednotlivé èásti cesty se oddìlují speciálním znakem – oddìlovaèem, napø. u OS MS Windows je to znak \ (zpìtné lomítko, backslash), v OS Unix znak / (normální lomítko, slash). Souborový systém v oblasti jmen obvykle podporuje:

42


2

l

l

l

l

Dlouhá jména souborù. Jméno souboru bez rozšíøení je delší než 8 znakù a kde rozšíøení je delší než 3 znaky, napø. technologie.docx. Národní abecedy a mezery ve jménech souborù. Lépe je však se znakùm národních abeced ve jménech vyhnout, a to z dùvodu pøenositelnosti souborù mezi rùznými operaèními systémy. Je rovnìž vhodnìjší namísto znaku mezera používat znak _ (podtržítko) anebo znak – (pomlèka), napø. informaèní-a-komunikaèní-technologie.docx. Vícenásobnou extenzi, kde jméno souboru mùže obsahovat více než jedno rozšíøení, napø. technologie.tar.gz. Rozlišování znakù, tzv. case-senzitivitu, tj. rozlišování velkých a malých písmen (verzálek a minusek) ve jménech souborù. OS MS Windows, který toto rozlišování nepodporuje, pak jmény Technologie.docx, TECHNOLOGIE.DOCX, technologie.Docx apod. pojmenovává stejný soubor, zatímco napø. u OS LINUX výše uvedená jména pojmenovávají soubory rùzné, pøestože jsou umístìny ve stejném adresáøi.

Z hlediska obsahu lze soubory rozdìlit na soubory, které obsahují data, metadata nebo obojí (viz kapitola 3), programy a programové knihovny a speciální soubory, které si dynamicky vytváøejí programy, napø. pro ukládání mezivýsledkù, pro vzájemnou komunikaci apod. Se soubory pracují programy. Aby pro daný typ souboru byl použit správný program, musí být v operaèním systému zabudovaná metoda, která pøi požadavku na zpracování souboru vyvolá automaticky pøíslušný program nebo situaci vyøeší jinak, pokud takový program není dostupný. V zásadì existují tøi základní metody rozpoznání typu souboru. Operaèní systém využívá: l

l

l

Rozšíøení jména souboru (extense). OS (napø. MS Windows) si eviduje, jaký program má být použit v souvislosti s konkrétní extenzí. Napøíklad extenze DOC6 je zpracována programem MS Word, extenze HTM je zpracována prohlížeèem Mozilla Firefox apod.; „Magické èíslo“, což je metoda známá pøedevším ve svìtì Unixových operaèních systémù. Na poèátku souboru je umístìn dvoubajtový identifikátor (magické èíslo) definující typ souboru, podle kterého OS vyvolává konkrétní program pro zpracování souboru. Postupem èasu je èíslo u nìkterých formátù nahrazeno textovým identifikátorem. Napøíklad u formátu GIF je to GIF87a nebo GIF89a, v pøípadì formátu HTML je to uvedení deklarace použitého znaèkovacího jazyka apod. Explicitní metadata. Do této kategorie patøí pøedevším tyto pøístupy: n „Apple Macintosh typové kódy“, které využívá operaèní systém Apple Macintosh, kde informace o typu souboru jsou samostatnì ukládány souborovým systémem. n „MIME typy“, které jsou využívány pøedevším u aplikací internetu a které identifikují formát došlých dat podle zaslané MIME informace. Jedná se o standardizovaný systém vyjádøení datového typu pomocí identifikátorù. Typ souboru je vyjádøen dvìma èástmi – typ/subtyp, napø. image/gif, text/txt, text/html apod.7

2.2.2 Podpùrné programy (utility) Do základního software patøí i nìkteré další podpùrné programy. Ty zpravidla rozšiøují možnosti operaèních systémù nebo zajišťují aplikacím èi uživatelùm další požadovanou funkcionalitu. Do této skupiny patøí tzv. pomocné 6 7

Pøehled nejèastìji používaných datových formátù a jejich oznaèení najdete na http://en.wikipedia.org/wiki/List_of_file_formats_(alphabetical). Pøehled MIME typù je možné najít napø. na adrese http://www.iana.org/assignments/media-types/.


43

2

programy (utility), jako napø. nejrùznìjší diagnostické prostøedky urèené pro testování funkènosti technických prostøedkù, prostøedky pro obnovu narušených souborù, prostøedky pro prohlížení dat rùzných datových formátù, prostøedky komprimace a dekomprimace souborù apod. Dále se mezi podpùrné programy øadí i univerzální prostøedky pro pøístup k aplikacím, jako jsou prohlížeèe (browser), prostøedky pro zpracování JAVA aplikací, napø. Java Virtual Machine, ale také nìkteré autoringové systémy, napø. prostøedky pro psaní textù, vytváøení prezentací, malování a úpravu grafiky apod.

2.2.3 Služební programy – servery a jejich klienti Služební programy jsou instalované a provozované zpravidla na služebních poèítaèích. Není to však podmínkou, protože jde o software, který je možné instalovat a spustit na libovolném poèítaèi splòujícím minimální technické nároky deklarované výrobcem. Úkolem tìchto programù je poskytovat služby aplikaènímu software. Využití služebních programù úzce souvisí s výpoèetním modelem, který aplikace používá. Souhrnnì se problematice výpoèetních modelù vìnuje kapitola 2.5.

`

Služební programy oznaèované jako servery zajišťují jiným programùm zpracování jejich specializovaných požadavkù. U serverù se pøedpokládá, že jsou spuštìny po startu operaèního systému a jsou trvale dostupné klientùm (klientským aplikacím, programùm).

Pøístup k serverùm mají klienti a také jiné servery prostøednictvím proprietárního (nativního) nebo standardizovaného aplikaèního programového rozhraní. Standardizované rozhraní umožòuje klientským programùm pøistupovat k serverùm od rùzných výrobcù stejnými mechanismy. Klientem mùže být samostatný program (napø. browser) nebo klient je souèástí programu byznys aplikace. Do kategorie serverù patøí: l l l l

souborové servery, databázové servery, specializované servery, pomocné servery.

Souborový server (File Server) zajišťuje pøístup k datùm prostøednictvím systému souborù a adresáøù (filesystem). Jeho úkolem je zabezpeèit ètení a zápis souborù na vnìjší pamìti poèítaèe podle pøidìlených pøístupových práv jednotlivých uživatelù. Server zajišťuje operace otevøení a zavøení souboru, ètení ze souboru, zápis do souboru, posun na konkrétní pozici v souboru a zajištìní soubìžného pøístupu k souboru a jeho zamykání, tj. zablokování pøístupu dalším uživatelùm. Klient serveru (program) mapuje logické disky serveru na virtuální souborový systém, tzv. síťové disky (napø. F:), a zaøízení fyzicky umístìná mimo poèítaè se jeví, jako kdyby byly lokálními disky poèítaèe. Podle požadavku uživatele na souborové služby klient pøedává požadavky buïto lokálnímu operaènímu systému (na uživatelském poèítaèi), nebo je pøesmìruje na souborový server. Pøedstavitelem je napø. souborový server integrovaný v síťovém operaèním systému Novell Netware. Existují ale také i systémy, které navíc dokážou pracovat s distribuovaným souborovým systémem (napø. AFS – Andrew File System), tj. øeší situaci, kdy soubor je rozmístìn na více poèítaèích. Protože aplikace zpravidla požadují provádìní operací s daty, které pøesahují možnosti souborových serverù, byly vyvinuty servery orientované na zpracování dat uložených v databázích – databázové servery (Database

44


2

Server). V závislosti na typu modelu databáze8 se využívají rùzné typy databázových serverù s rùznou nabízenou funkcionalitou. Mezi zástupce lze zaøadit Oracle, MS SQL Server, IBM DB2, MySQL èi PostgreSQL, MS Access apod. K základním funkcím databázových serverù patøí: l l l l l

správa metadat o uložených datech (jména tabulek a sloupcù, typy dat atd.), možnost pøístupu k datùm databáze z libovolných aplikací, podpora soubìžného (konkurenèního) pøístupu klientù ke spoleèné databázi, podpora rùzných strategií vyhledávání dat v databázi, centralizovaná správa a ochrana pøístupu k databázi.

Další skupinu serverù tvoøí specializované servery. Ty jsou orientovány na zajištìní široké škály služeb internetu a na další speciální èinnosti, napø. terminálový server (viz výpoèetní model host/terminal v kapitole 2.5). Pro další podpùrné služby IS se využívá celá øada pomocných serverù. Ty zahrnují napø.: l l

l

podporu soubìžného využití periferních zaøízení, napø. tiskové servery spravující síťové tiskárny, podporu komunikace mezi rùznými zaøízeními, napø. modemové servery zajišťující pøístup a soubìžné užívání modemù, pøístupové servery umožòující pøipojení vzdálených poèítaèù do místní poèítaèové sítì.

2.3 Komunikaèní prostøedky Již nìkolikrát jsme zdùraznili, že významnou roli v informaèních technologiích hrají komunikaèní prostøedky. Jedná se o komplex technologií zahrnující jak technické prostøedky, tj. fyzická zaøízení, tak také programové vybavení. Prostøedky umožòují vzájemnì propojit jednotlivé poèítaèe do sítì poèítaèù. Jsou konstruovány tak, aby pøi splnìní základních požadavkù (napø. držení oprávnìní ke komunikaci, fyzické pøipojení do sítì apod.) byly komunikaèní prostøedky aplikacím i lidem transparentní, neboli je vytvoøeno takové prostøedí, ve kterém si programy a aplikace provozované na rùzných poèítaèích toto nemusí uvìdomovat, a v pøípadì požadavku vzájemné komunikace se jim komunikace jeví, jako by probíhala v rámci jednoho poèítaèe. Aby spolu mohly komunikovat zaøízení a programy rùzných výrobcù, byly definovány pøíslušné standardy komunikace, tzv. protokoly9. Protokolù je definována celá øada a s nìkterými se setkávají i uživatelé. Jako pøíklad lze uvést protokol IEEE10 802.11, oznaèovaný jako WI-FI (Wireless Fidelity) nebo http (Hypertext Transfer Protocol), používaný pøi komunikaci v rámci služby World Wide Web. Asi nejznámìjší je v souèasnosti globální (celosvìtová) síť známá pod oznaèením internet. Tato síť je vytvoøena množinou komunikaèních (poèítaèových) sítí s definovanými pravidly propojení dílèích sítí a pravidly, která specifikují zpùsob komunikace jednotlivých prvkù sítí.

8

K databázím, databázovým serverùm a systémùm øízení báze dat (SØBD) se vrátíme podrobnìji v kapitole 3. Podrobnìjšímu popisu technologie sítí se vìnuje pøíloha 6. 10 Institute of Electrical and Electronics Engineers 9


45

2

`

Podle FNC11 (Government Internet Domain, 1995) se pojem internet vztahuje ke globálnímu informaènímu systému, který: (i) je logicky vzájemnì propojen prostøednictvím globálního a jednotného prostoru adres, který je založen na internet protokolu (IP), vèetnì dalších, které jsou jeho následníky; (ii) komunikaci prvkù sítì zajišťuje protokolovou sadou TCP/IP, pøípadnì (v budoucnu) dalšími protokoly, které jsou s protokolem IP kompatibilní12 a (iii) na své nejvyšší úrovni veøejnì nebo soukromì poskytuje, užívá nebo zpøístupòuje služby nad technologiemi, které jsou založeny na výše uvedených principech komunikace a souvisejí s infrastrukturou. 1112

Z uvedené definice vyplývá, že prvek sítì, který v síti internet bude komunikovat, musí disponovat jednoznaènou adresou (i) podle protokolu IP (internet protokol). Zpùsob získání adresy závisí na konfiguraci uzlu sítì a je definován správcem sítì. Vlastní komunikace je zajišťována øadou protokolù, které jsou uspoøádány do protokolové sady s názvem TCP/IP (ii). Na koncových uzlech (poèítaèích) jsou tyto protokoly souèástí operaèního systému a jejich nastavení je definováno správcem sítì. Pro pøístup ke službám a také pro jejich provozování je nutné na koncové uzly instalovat vhodné programové vybavení, napø. klientský program – prohlížeè (browser) služby World Wide Web (iii).

`

Z institucionálního hlediska (Hindls, a další, 2003) je síť internet množina komunikaèních (poèítaèových) sítí, které jsou vzájemnì propojeny na základì bilaterálních nebo multilaterálních smluv, vytváøející globální (celosvìtovou) síť. V rámci této množiny mohou oprávnìní uživatelé využívat jak pøenosové kapacity sítí, tak i zdroje, které jsou do sítí pøipojené (poèítaèe, servery, služby, data). Jednotlivé prvky sítí pøi komunikaci využívají dohodnutá pravidla, která jsou oznaèována jako protokolová sada TCP/IP.

Technologie internetu je postavena na následujících principech: l

l

l

Neexistuje žádný centrální prvek, který by mohl být úzkým hrdlem systému a pøi jehož výpadku by došlo k zastavení veškeré komunikace v síti internet. Pøedem je nutné poèítat s výpadky a nespolehlivostí, což je dáno tím, že globální síť vytváøejí sítì s rùznou kvalitou, jež mohou být provozovány v rùzných prostøedích (technických i politických). Existuje zde „maximální snaha, ale nezaruèený výsledek“, což je dáno tím, že v rùzných èástech sítì je rùzný provoz nebo zde mohou nastat výpadky èi komunikaèní cesta mezi komunikujícími body je abnormálnì dlouhá.

Internet poskytuje celou øadu služeb. Patøí k nim infrastrukturní služby, které slouží jako podpùrné služby uživatelùm, a aplikaèní služby, které jsou urèeny pøímo uživatelùm.

11 12

46

Federal Networking Council Podrobnìji je fungování internetu popsáno v pøíloze 7.


2

K infrastrukturním službám patøí napø.: Služba doménových jmen (Domain Name System), která umožòuje uživatelùm používat pøi adresaci objektù v síti èlovìku snadno zapamatovatelná jména, napø. www.vse.cz, kit.vse.cz, [email protected] apod. Služba automatického pøidìlování IP adres (Dynamic Host Configuration Protocol), která zajišťuje dynamické propùjèení IP adresy a dalších konfiguraèních informací koncovému uzlu sítì na základì pravidel definovaných správcem sítì. Služba øízení synchronizace èasu (Network Time Protocol), která zajišťuje správné nastavení vnitøních hodin jednotlivých uzlù sítì a tedy i koncových poèítaèù, aby všechny disponovaly stejným a pøesným èasem.

l

l

l

K aplikaèním službám patøí tøeba: služba World Wide Web, pùvodnì spojovaná pøedevším s tzv. hypertextovým systémem13, ale dnes zajišťuje i zobrazení uživatelského rozhraní nejrùznìjších aplikací v prohlížeèi uživatele; služba elektronická pošty (e-mail) zajišťuje pøenos zpráv mezi uživateli i s tím, že pøíjemce není v daném okamžiku k síti pøipojen; služba pøenosu souborù (FTP – File Transfer Protocol) umožòuje manipulovat s adresáøovou strukturou vzdáleného poèítaèe vèetnì možnosti nahrávat a stahovat soubory do/z adresáøù, aniž by uživatel musel znát, jaký souborový systém vzdálený poèítaè používá, tj. aby musel znát jednotlivé pøíkazy a øada dalších – služba síťových novin, služby internetové telefonie, služba umožòující komunikaci v reálném èase (Internet Relay Chat) atd.

l

l

l

l

2.4 Programové prostøedky pro podporu vývoje a implementaci aplikací Programové prostøedky urèené pro vývoj a implementaci software jsou specifickou skupinou programového vybavení. Jedná se ve skuteènosti o aplikaèní programové vybavení, které využívá informatika pro vývoj aplikací (a de facto libovolné softwaru). Z hlediska podnikové informatiky ho však øadíme do ICT a dìlíme ho na systémy a prostøedky vývoje software a na programovací jazyky. Ještì než pøejdeme k charakteristice jednotlivých prostøedkù, formulujme si vztah mezi pojmy proces, aplikace, program a algoritmus. Algoritmus oznaèuje pøesný a jednoznaènì urèený postup, kterým lze vyøešit daný typ úlohy, napø. výpoèet danì z pøidané hodnoty, setøídìní dat podle abecedy apod. Dùležitou vlastností algoritmu je opakovatelnost, to znamená, že algoritmus lze provést opakovanì vèetnì toho, že pokud algoritmus pøedpokládá nìjaké vstupní hodnoty, mohou tyto hodnoty být stejné nebo rùzné. Formulaci algoritmu, kterou vyjadøujeme pomocí programovacího jazyka, nazýváme program. Program mùže zahrnovat vícero algoritmù. Program se spouští na jednom poèítaèi, jedním pøíkazem, pøípadnì volbou jedné položky menu. Množina programù tvoøí programovou aplikaci, kdy každý z programù se specializuje na nìjakou aktivitu, napø. jeden program je schopen zobrazit data na obrazovce, jiný program poèítá cenu k zaplacení a další program zajišťuje uložení objednávky do databáze. Samozøejmì opìt mùže platit, že program mùže být pøímo aplikací (napø. program kalkulaèky). Pro zajiš13

Hypertext je text, který není omezen linearitou, na rozdíl tøeba od tištìné knihy. Hypertext obsahuje „odkazy“ na další texty (uložené v tomtéž nebo jiném souboru), pøièemž ètenáø se v textu pohybuje po trajektorii, kterou si sám zvolí. Pro hypertext, který se neomezuje pouze na texty, ale obsahuje i obrázky, video, zvuk apod. se užívá termín hypermédium. Pro popis hypertextu se používá znaèkovací jazyk HTML (HyperText Markup Language) a jeho nové nebo pøepracované verze (viz kapitola 3).


47

2

tìní procesu pak mùže být využito jedné nebo více aplikací. Zároveò platí, že stejný algoritmus mùže být použit v rùzných programech, stejný program mùže být použit v rùzných aplikacích a stejná aplikace mùže být použita v rùzných procesech (viz obr. 2.3).

Proces

Proces



Program

Algoritmus

Program

Algoritmus

Program

Algoritmus

Algoritmus

Obr. 2.3 Vztah algoritmu, programu, aplikace a podnikového procesu

2.4.1 Systémy a prostøedky vývoje software Mezi systémy a prostøedky vývoje software øadíme prostøedky, které podporují jednotlivé fáze vývoje software od analýzy pøes návrh až po implementaci: l

l

14

48

Prostøedky CASE (Computer Aided Software/System Engineering), což je komplex poèítaèových nástrojù pro podporu analýzy, návrhu a implementace IS/ICT a dalších èinností souvisejících s jeho vývojem.14 Integrovaná vývojová prostøedí podporující implementaci již navržené aplikace. Zpravidla jde o prostøedí, které zahrnuje editor zdrojového kódu, pøekladaè, interpret, ladící program (debugger), prostøedky øízení

K jejich pøedstavitelùm patøí Rational Rose (IBM), System Architect (Popkin Software), ERWin (Computer Associates), ArgoUML, CASE SELECT OMT a další.


2

verzí programu, nástroje zjednodušující implementaci grafického uživatelského rozhraní (GUI) a v souvislosti s objektovým pøístupem i nástroje pro práci s objekty.15 SDK (Software Development Kit), což jsou nástroje pro podporu snadnìjšího vývoje aplikací spolupracující s vybraným vývojovým prostøedím.16

l

2.4.2 Programovací jazyky Pøi vlastní implementaci programu se navržené algoritmy vyjadøují pomocí programovacího jazyka. Ten slouží k zápisu programu tak, aby mu následnì rozumìl poèítaè. Každý programovací jazyk má: abecedu, která je reprezentována množinou terminálních, dále nedìlitelných symbolù (napø. If); syntaktická pravidla, která umožòují konstrukci složitìjších, pøípustných výrazù (syntaktických výrazù, konstruktù) z terminálních symbolù (napø. konstrukce If-Then-Else); sémantiku (význam) pøiøazenou k jednotlivým syntaktickým konstruktùm (napø. zpracuj pøíkazy vìtve Then v pøípadì, že podmínka byla vyhodnocena jako pravdivá, jinak zpracuj pøíkazy vìtve Else).

l l

l

V prùbìhu rozvoje informaèních technologií se rozvíjely také programovací jazyky, ale pouze nìkolik se jich využívá i v souèasné dobì. Programovací jazyky se rozdìlují do rùzných skupin dle urèitých charakteristik, pøièemž mnohé programovací jazyky lze zaøadit do více skupin. 17

Tab. 2.2 Základní pøehled programovacích jazykù Skupina

Charakteristika

Pøíklad

strojový kód

Program je zapsán ve strojovém kódu jako posloupnost poèítaèových in- dle cílového strukcí pro konkrétní procesor a operaèní systém, pøièemž zápis je v binár- procesoru ním tvaru (použity jsou pouze nuly a jednièky). Ve strojovém kódu se programovaly první poèítaèe, nyní se však stále používá – je výsledkem pøekladu programu z vyšších programovacích jazykù (napø. soubor .exe ve Windows obsahuje program ve formì strojového kódu).

assemblery

Program je zapsán v jazyce, který odpovídá strojovému kódu pro pøíslušný rùzné assemblery procesor, nezapisuje se však v binárním tvaru, ale používají se symbolické dle cílové platformy názvy pro operace a pro adresy v pamìti.

procedurální Procedurální jazyky mají ètyøi základní rysy: Fortran, COBOL, jazyky Visual Basic, C, l používají se promìnné, které odpovídají úsekùm vnitøní pamìti, Perl, PHP, Ada l pro vložení hodnot do promìnných se používají pøiøazovací pøíkazy, l pro opakující se operace se používají cykly, l programy se èlení do jednotlivých procedur (v závislosti na jazyce se používají pojmy podprogram, funkce, metoda). Mezi procedurální jazyky lze zaøadit mnoho jazykù, mnoho z nich bylo v posledním desetiletí doplnìno o objektové prvky. Pokraèování 15

K pøedstavitelùm integrovaných prostøedí patøí napø. Visual Studio .NET (Microsoft), SUN One Studio, Borland Delphi apod. Pøíkladem SDK jsou Java SDK, DirectX SDK, Widget toolkits. 17 Zdrojem pro uvedené pøíklady zápisu programù je www.wikipedia.org, další ukázky jsou k dispozici na adrese http://en.wikipedia.org/ wiki/Hello_World. 16


49

2

Pokraèování Skupina

Charakteristika

Pøíklad

jazyky ètvrté generace (4GL)

Cílem této skupiny jazykù je zjednodušit vytváøení aplikací komunikujících FoxPro, Focus, s relaèními databázemi – zjednodušit manipulaci s daty, tvorbu výstupních ABAP, SAS, sestav, tvorbu uživatelského rozhraní. Nìkdy se do této skupiny jazykù Oracle Reports øadí i jazyk SQL.

funkcionální programovací jazyky

Funkcionální programovací jazyky se snaží vyjádøit algoritmus pomocí LISP, Haskel, funkcí, které pracují s parametry. Pro vyjádøení opakování se používá re- Scheme, ML, Excel kurze a ne cykly. Ve funkcionálních jazycích se obvykle neurèuje poøadí, v jakém se mají jednotlivé funkce vyhodnocovat. Pøíkladem specifického funkcionálního jazyka mùže být Excel – pro vyjádøení toho, co se má dìlat se používají funkce: = a1 * b1 = suma (c1 : c10). V Excelu neexistuje možnost vyjádøit cykly èi urèit poøadí vyhodnocování funkcí. Existují i univerzální funkcionální jazyky, z nichž nejstarší je LISP.

logické progra- Program není zápisem algoritmu, ale sadou definovaných pravidel a ome- Prolog, OPS5 movací jazyky zení, pøièemž poèítaè øeší urèitý problém dle tìchto pravidel a omezení. Jazyky této generace se užívají v oblasti umìlé inteligence. Program využívá objektového pøístupu (viz následující kapitola), kde ob- C#, Java, objektovì orientované ja- jekt obsahuje data i èinnosti. Vìtšina procedurálních programovacích ja- SmallTalk, Visual Basic, C++ zykù byla doplnìna o objektové rysy a lze je zaøadit do této kategorie. zyky skriptovací jazyky

Skripty oznaèují programy, které spojují døíve existující moduly dohromady. Programy ve skriptovacích jazycích jsou obvykle kratší a rychleji se píší než v neskriptovacích jazycích. Nevýhodou ale je nižší rychlost. Skriptovací jazyky se obvykle nepøekládají. Pùvodnì se mezi skriptovací jazyky øadily hlavnì jazyky pro øízení dávek programù (skripty pøíkazové øádky – soubory .bat v DOSu a ve Windows, shell skripty v Unixu, …), nyní se mezi nì øadí další skupiny jazykù. Nìkteré ze skriptovacích jazykù se èasem vyvinuly v univerzální programovací jazyky (Perl, PHP). Skriptovací jazyky lze rozdìlit následovnì: l

jazyky pro øízení dávek programù – MS DOS batch, sh, JCL, REXX,

l

zpracování textù – AWK, sed, Perl (pùvodnì),

l

obecné skriptovací jazyky – PHP, Perl, Python, Ruby, Jython, Groovy, ECMAScript, JavaScript, VBScript,

l

specializované jazyky obvykle spojené s konkrétní aplikaèní oblastí – Lingo, ActionScript, TCL Pokraèování

50


2

Pokraèování Skupina

Charakteristika

specializované programovací jazyky (domain specific languages)

Do této skupiny patøí jazyky, které jsou urèeny k øešení úloh nìjaké specifické oblasti (na rozdíl od univerzálních programovacích jazykù). Tyto jazyky jsou èasto umístìny v nìjaké aplikaci a rozšiøují její možnosti (napø. jazyk maker v tabulkových kalkulátorech). Existuje velké množství jazykù, které lze do této skupiny zaøadit, zde jsou uvedeny pouze nìkteré pøíklady: l

postscript – jazyk pro popis tiskové stránky, obsahuje i nìkteré rysy znaèkovacích jazykù,

l

YACC pro parsování jiných programovacích jazykù,

l

Csound pro vytváøení zvukových souborù,

l

GraphViz pro vytváøení obrázkù,

l

SQL – jazyk pro dotazování a manipulaci s daty v relaèních databázích,

l

XSLT – jazyk pro formátování a transformaci XML souborù,

l

grep – používá regulární výrazy pro výbìr øádkù z textových souborù,

l

SAS – jazyk zabudovaný ve statistickém balíku stejného jména.

Pøíklad

Programy zapsané v programovacím jazyce (s èásteènou výjimkou strojového kódu) musí být pøedem pøipraveny ke zpracování. V rámci této pøípravy jsou programy pøeloženy do tvaru, kterému rozumí pøíslušný poèítaèový systém. Pøeklad zajišťuje specializovaný program – pøekladaè jazyka (kompilátor), který symbolický zápis pøevede do strojového jazyka. V nìkterých pøípadech probíhá pøeklad opakovanì pøi každém spuštìní programu. Tehdy je nutné, aby pøi zpracování byl k dispozici jiný specifický program – interpret, který „za bìhu“ pøekládá symbolický zápis do strojových instrukcí. Pøíkladem mùže být interpret skriptovacího jazyka JavaScript, který je souèástí vìtšiny internetových prohlížeèù.

2.5 Typy systémù a technologické výpoèetní modely V pøedcházejících èástech kapitoly jsme se seznámili s technologiemi, které se používají v podnikových informaèních systémech. Jejich uspoøádání závisí na øadì okolností a vychází: l

l

z požadavkù podnikatelských aktivit a aplikací (napø. existuje požadavek na zajištìní komunikace prostøednictvím mobilních telefonù, existuje požadavek na integraci rùzných aplikací tak, aby komplexnì podporovaly podnikatelské aktivity apod.); z infrastruktury organizace (napø. organizace je geograficky dislokovaná, je souèástí nìjakého dodavatelského øetìzce, je ovlivnìna specifickou legislativou apod.).

V této souvislosti hovoøíme o rùzných typech systémù, v nichž aplikujeme rùzné výpoèetní modely. Za centralizovaný systém považujeme takový systém, jehož komponenty jsou omezeny na jedno místo. U tìchto systémù se veškeré zpracování provádí na jednom místì èi zaøízení (zpracování je centralizované). To umožòuje zajistit vysokou míru kontroly vlastního zpracování, ale na druhé stranì je významnì ovlivnìno výkonem a kapacitou centrálního zaøízení. Pøíkladem mùže být zpracování finanèních transakcí bankovních institucí, kde je nutné zajistit vysokou míru bezpeènosti.


51

2

U decentralizovaného systému jsou jeho komponenty na rùzných místech. Mezi komponentami neexistuje žádná vzájemná koordinace anebo je pouze èásteèná (zpracování je decentralizované). Pøíkladem je proces vydávání digitálního certifikátu osobì. Certifikaèní autorita na jednom místì a jedním systémem pøijme požadavek na vydání certifikátu, pøenese data do samostatného systému, který certifikát generuje a který z dùvodu zajištìní bezpeènosti není s jiným systémem propojen komunikaèními prostøedky. Následnì pak jiným systémem, který k pøedešlým systémùm není pøipojen komunikaèními prostøedky, zpøístupòuje certifikát k ovìøení. Jiným pøíkladem decentralizovaného zpracování mùže být psaní jedné knihy více autory – každý autor píše své kapitoly v samostatném systému. Pøi závìreèném spojování kapitol dohromady se pøemìní decentralizované zpracování na centralizované. Distribuovaný systém je takový systém, jehož komponenty jsou autonomními mechanismy, které koordinují svoje zpracování prostøednictvím nìjakého globálního mechanismu a znalostí, pøièemž ale disponují také lokálními mechanismy a znalostmi. Komponenta umožòuje samostatnou práci, ale to, kdy má práci realizovat a jak, je dáno požadavky a stavem jiných komponent. Pøíkladem mùže být objednávkový systém elektronického obchodu. Zde se jedna èást systému – služba WWW – postará o dodání informací uživateli, jiná èást se postará o zkompletování informací s tím, že pøi tomto kompletování vyžaduje služby jiných èástí, napø. programu, který obsluhuje katalog zboží, a programu, který obsluhuje zásoby zboží a pro objednávkový systém poskytuje informace o disponibilní zásobì konkrétního zboží. Dnešní podnikové informaèní systémy jsou distribuovanými systémy. Technologie a aplikace vytváøejí distribuovaný výpoèetní systém, což je kolekce autonomních poèítaèù, vzájemnì propojených prostøednictvím komunikaèní sítì, provádìjící definované obchodní funkce vložené do aplikací. Technicky, poèítaèe nesdílejí vnitøní pamìť, a tak informace nemohou být pøedávány prostøednictvím globálních promìnných, ale musí být vymìòovány prostøednictvím nìjakých zpráv v komunikaèní síti (Umar, 1993). Nutno podotknout, že i v tìchto systémech se uplatòují principy (pokud je to vhodné) centralizovaných a decentralizovaných systémù. Tak, jak se vyvíjel pøístup ke zpracování, vyvíjely se i tzv. výpoèetní modely.

`

Výpoèetní model je model, kterým charakterizujeme zpracování aplikací informaèního systému a který zároveò formuluje principiální požadavky na technologie. Historicky bylo použití konkrétního výpoèetního modelu v zásadì pøedurèeno aktuální úrovní a možnostmi technologií.

Obr. 2.4 znázoròuje postupný vývoj výpoèetních modelù a jejich vztahy k typu systému. V souèasné dobì v IS/ICT využíváme pozitivních vlastností jednotlivých modelù, které jsou postupnì zdokonalovány, a nelze øíci, že by se nìkterý z modelù dnes vùbec neužíval. Uvedené výpoèetní modely lze také rozdìlit podle toho, zda je umožnìno uživateli vstoupit do procesu vlastního zpracování. Buïto mu to není umožnìno a uživatel mùže zpracování pouze zastavit, tj. zrušit a novì ho spustit (tzv. dávkové zpracování), anebo uživatel aktivnì vstupuje do zpracování (ostatní výpoèetní modely). Systémy, které umožòují v prùbìhu zpracování do nìho vstupovat a ovlivòovat ho, se oznaèují jako interaktivní systémy.

52


2

Distribuované zpracování Klient/server Decentralizované zpracování Souborový server (sdílení souborù) Izolované PC (samostatná databáze) Centralizované zpracování Host/terminal Dávkové zpracování

Obr. 2.4 Výpoèetní modely a jejich vývoj

2.5.1 Modely související s centralizovaným zpracováním Model dávkového zpracování je typický tím, že je nutné nejprve jednotlivé požadavky na zpracování pøipravit a zkompletovat do dávky, a to ještì pøed spuštìním vlastní aplikace. Bìhem zpracování dávky již pak není možné ovlivòovat obsah dávky. Zpracování je možné buïto zrušit (pokud to systém umožòuje) a znovu spustit s upravenou dávkou, anebo poseèkat až na dokonèení zpracování. V dnešních informaèních systémech se model využívá v øadì situací. Pøíkladem mùže být systém, ve kterém organizace úètuje jednotlivé došlé faktury. V prùbìhu dne dochází postupnì na základì zaevidování faktury k pøípravì požadavku na její zaplacení. Na povel uživatele anebo automatizovanì ve stanovený okamžik systém sestaví ze všech požadavkù dávku, kterou odešle do banky. Na vstupu bankovního systému se postupnì shromažïují dávky jednotlivých organizací pro daný zúètovací den. Z tìchto dílèích dávek je v bankovním systému pøipravena dávka pro zúètování, která se ve stanovený okamžik spustí a aplikace provede zúètování všech pøíkazù dávky. Jiným pøíkladem mùže být práce komponenty ETL18 v rámci aplikací business intelligence (viz kapitola 9). Model host/terminal je prvním pøípadem, kdy uživatel prùbìžnì ovlivòuje zpracování aplikace a ihned jako odpovìï získává výsledky. Aplikace disponuje uživatelským rozhraním a je zpracována na jednom poèítaèi. Je však chápána jako monolitický blok, který øídí jak zpùsob zobrazování, tak také pøístup k datùm. Uživatel zadává své požadavky a zobrazuje si výsledky prostøednictvím „hloupého“ terminálu. „Hloupost“ terminálu je dána tím, že jeho úkolem je pouze zprostøedkovat vstup èi výstup jinému poèítaèi (oznaèen jako host), a ne provádìt zpracování programu. Terminálem oznaèujeme zaøízení, které nedisponuje procesorem, vnitøní a vnìjší pamìtí. Výhodou tohoto modelu je centralizace celé aplikace, a tedy možnost zajistit bezpeènost a kontrolu zpracování. Systémy založené na tomto modelu mají vysokou spolehlivost a relativnì nízké náklady na pøidání dalšího uživatele (pøidání dalšího terminálu). Za nevýhody lze považovat málo flexibilní aplikace (z dùvodu monolitiènosti), nízkou 18

Extract, Transformation, Load


53

2

schopnost naplnit uživatelská oèekávání v komunikaci se systémem (jednoduché textové rozhraní) a nemožnost realizace jiných operací než tìch, které byly aplikaci naprogramovány. V dnešní dobì již jsou uvedené nevýhody eliminovány užitím dalších výpoèetních modelù – uplatnìní najdeme napø. pøi realizaci požadavku na vzdálenou správu systému. V tìchto pøípadech prostøednictvím vhodných programù emulujeme terminál (napø. v OS Windows – Vzdálená plocha) a správce tak má možnost pracovat se vzdáleným poèítaèem, jako kdyby pøímo používal vstupní a výstupní zaøízení tohoto vzdáleného poèítaèe. Jiným pøípadem je virtualizace osobních poèítaèù, kdy kompletní „image“ daného poèítaèe je na serveru a je dostupné z libovolného osobního poèítaèe. Uživatel pak má vždy „své“ kompletní a stejné prostøedí, ať již použije jakýkoli poèítaè.

2.5.2 Modely související s decentralizovaným zpracováním S pøíchodem osobních poèítaèù a vznikem vhodného programového vybavení (tabulkový kalkulátor, pozdìji grafické uživatelské rozhraní) nadchází éra tzv. výpoètù realizovaných koncovými uživateli (EUC – End-User Computing). Uživatelé tak získávají dobrý nástroj, kterým odstraòují problémy modelu host/terminal, tj. nemožnost zpracovat jiné výpoèty než ty, které programátor implementoval. Za výhodu tohoto stádia rozvoje informaèních technologií lze považovat plnou kontrolu nad zpracováním, daty i jejich prezentací uživatelem. Vše je zpracováno, uloženo i zobrazeno na poèítaèi, který má uživatel k dispozici pøímo na svém stole. Nevýhodou, která dala i oznaèení tomuto výpoèetnímu modelu – model izolovaných PC, je nepropojenost jednotlivých osobních poèítaèù a nemožnost pøímého sdílení dat (každý uživatel má svoji samostatnou databázi). Jako další nevýhodu lze uvést i to, že aplikace musí být nainstalována na každém osobním poèítaèi a pøi jakékoli zmìnì v aplikaci musí být provedena její opìtovná reinstalace na všech poèítaèích, kde má být aplikace používána. V souèasných systémech stále využíváme výhody tohoto modelu, pøedevším kvalitní a standardizované grafické uživatelského rozhraní, jehož prvky používají jednotlivé provozované aplikace. Samozøejmostí je také dodateèné zpracování výsledkù (kopírovat–vložit mezi programy), jejich uložení na disk apod. Vady modelu izolovaných PC odstraòuje rozvoj poèítaèových sítí a vznik síťových operaèních systémù (Novell Netware). To umožòuje vyèlenit nìjaký poèítaè a s ostatními osobními poèítaèi ho propojit poèítaèovou sítí. Na vyhrazeném poèítaèi je nainstalován síťový operaèní systém, který stejnì jako operaèní systém osobního poèítaèe disponuje souborovým systémem. Vùèi osobním poèítaèùm vystupuje vyhrazený poèítaè jako sluha (server). Pro osobní poèítaèe zajišťuje základní operace se souborem – vytvoøení, ètení obsahu a jeho odeslání osobnímu poèítaèi, zrušení apod. a také umožòuje sdílet soubor s jinými poèítaèi. Z tìchto vlastností vychází i název tohoto výpoèetního modelu – souborový server. Dùležitou vlastností, kterou tento model zavádí, je tzv. transparence sítì, kdy soubor na disku vzdáleného vyhrazeného poèítaèe se osobnímu poèítaèi, tj. zde provozovaným aplikacím, jeví, jako kdyby byl umístìn pøímo na osobních poèítaèích. Základní nevýhoda modelu vyplývá z konceptu zpracování. Celé zpracování aplikace stále probíhá na osobním poèítaèi. Pøi požadavku aplikace na data uložená v souboru na vzdáleném souborovém serveru (napø. výpoèty v programu MS Excel), je celý soubor nejprve pøenesen do osobního poèítaèe a teprve zde je aplikací zpracován. Takové zpracování má nìkolik nepøíjemných dùsledkù. Síť se zatìžuje pøenosem celého souboru i v pøípadì, že aplikace potøebuje jen èást dat. Pøi požadavku jedné aplikace na data dojde k jejich uzamèení a ostatní aplikace musí èekat, až je operace dokonèena. A nakonec, protože veškeré zpracování dat probíhá na osobním poèítaèi, vzrùstají dále požadavky na jeho technickou konfiguraci. V souèasné dobì je používán model v situacích, kdy požadujeme uložit soubory tak, aby byly pøístupné z rùzných poèítaèù místní poèítaèové sítì.

54


2

2.5.3 Modely související s distribuovaným zpracováním V reakci na nevýhody výše uvedených modelù, ale s využitím všech výhod, vzniká koncept distribuovaného zpracování aplikací. Klíèový princip nového modelu lze charakterizovat následovnì: „data by se mìla zpracovávat pøedevším tam, kde jsou k dispozici“ (Peterka, 1996). To znamená, že pokud jsou data uložena na nìjakém vzdáleném poèítaèi, tak jejich zpracování by mìlo probìhnout na tomto poèítaèi a výsledky (napø. pouze vybraná data, výsledky výpoètù apod.) by mìly být zaslány tomu, kdo o zpracování žádal. Koncept vychází z dalšího rozvoje poèítaèových sítí a databázových systémù a reaguje na požadavky vytvoøit kooperativní distribuované zpracování. U tohoto konceptu je komponenta, která o nìco žádá, oznaèena pojmem klient, a komponenta, která poskytuje službu pojmem server. Aby bylo možné stanovit, co realizuje klient a co bude realizovat server, je aplikace vnitønì èlenìna na logiky (oblasti), viz obr. 2.5. Pro libovolnou aplikaci informaèního systému je pak definována: l

l

l

Prezentaèní logika. Ta obsluhuje vstup dat a povelù a zajišťuje pøípravu vhodného formátu výsledku v závislosti na tom, kdo bude pøíjemcem výsledkù (napø. formátuje formuláø vstupních dat dle pøíslušného prostøedí uživatele, odpovìï na požadavek, zprávu jinému programu apod.). Aplikaèní logika. Realizuje provedení zpracování vìcné (obchodní) logiky, neboli tzv. „byznys funkci“, pro kterou byla aplikace sestavena. Aplikaèní logika se èasto dále dìlí na: n aplikaènì specifické prvky (application logic), tj. takové prvky, které øídí postup zpracování (napø. nejprve musí být zadána data, pak probìhne jejich ovìøení, následnì bude objednávka zaznamenána apod.), realizují konkrétní výpoèty s daty (napø. výpoèet ceny objednávky apod.) a n prvky obchodních pravidel a omezení (business logic), tedy ty prvky aplikace, které zajišťují, aby aplikace respektovala definovaná pravidla organizace (napø. pøi objednávce nad 1000 musí být provedeno telefonické ovìøení zákazníka, nelze zaznamenat informaci o zákazníkovi, pokud neznáme jeho jméno apod.). Datová logika. Realizuje operace s daty, které vyžaduje konkrétní aplikaèní logika. Zpravidla to je kontrola, zda jsou data k dispozici a v potøebném tvaru (napø. pokud jsou data v nevhodném poøadí èi formátu, zajistí jejich vhodnou transformaci), a dále to je realizace ètení a zápisu dat.

Aplikaèní logika

Prezentaèní logika

Aplikaènì specifické prvky

Datová logika

Prvky obchodních pravidel a omezení

Aplikace

Obr. 2.5 Logiky aplikace


55

2

Logika aplikace je realizována jako množina programových komponent (programù). O zpracování pøíslušné logiky aplikace nebo její èásti se stará pøíslušný prvek technologické infrastruktury, tj. vhodný základní software (prohlížeè, aplikaèní server, systém øízení báze dat apod.) a poèítaè (osobní poèítaè, služební poèítaè).

`

Klient/server je model, kterým charakterizujeme distribuované zpracování aplikací informaèního systému. Popisuje komunikaci mezi programovými komponentami aplikace (prezentaèní, aplikaèní a datovou logikou) a zpùsob, jak je zpracování rozdìleno (distribuováno) v poèítaèovém prostøedí.

Zpùsoby rozmístìní zpracování byly popsány v modelech øady autorù, napø. Shedletsky (1993), Winsberg (1993), Cassell (1994) anebo Morisawa (1998). Jejich praktická implementace vede k tzv. dvouúrovòovému, tøíúrovòovému a n-úrovòovému modelu klient/server. U dvoúrovòového modelu je zpracování aplikace distribuováno mezi klientský systém a systém serveru. Klientským systémem rozumíme zpravidla prostøedí osobního poèítaèe uživatele, které umožní spustit a provozovat pøíslušnou èást aplikace, napø. pøímo v operaèním systému, prostøednictvím programu prohlížeèe nebo nìjakého virtuální stroje (JVM – Java Virtual Machine). Systémem serveru rozumíme typicky systém øízení báze dat, ale také rùzné servery spojené s prostøedím internetu (webový server, server elektronické pošty apod.). Podle toho, jak je rozdìleno zpracování aplikace mezi klientský systém a systém serveru, rozlišujeme variantu tzv. tlustého klienta a variantu tenkého klienta (obr. 2.6).

Datová logika Prezentaèní logika

Aplikaèní logika

Operaèní systém

Systém øízení báze dat

Operaèní systém

Klientský systém

Systém serveru

(a) varianta tzv. tlustého klienta Prezentaèní logika

Aplikaèní logika

Datová logika

Prohlížeè

Webový server

Operaèní systém

Operaèní systém

Klientský systém

Systém serveru

(b) varianta tzv. tenkého klienta Legenda Fyzická komunikace Logická komunikace

Obr. 2.6 Dvouúrovòový model klient/server

56


2

Varianta tlustý klient byla prvním implementovaným modelem distribuovaného zpracování aplikací. Umožnila efektivní sdílení dat, které v modelu zajišťuje systém øízení báze dat. Zároveò mezi serverem a klientem jsou pøenášena pouze data nezbytná pro zpracování aplikaèní logiky, tj. napø. pouze jeden záznam z databáze. Za nevýhody této varianty lze považovat to, že klade vyšší nároky na technickou konfiguraci klientského systému, který musí „zvládnout“ zpracování i tøeba složité a na výpoèty nároèné funkce, a také to, že správce musí èást aplikace instalovat do každého klientského systému. Jednoduchým pøíkladem použití modelu mùže být aplikace v MS Excelu, pøièemž data jsou získána prostøednictvím databázového dotazu (Data ® Importovat externí data). Varianta tenký klient souvisí jednak s dalším rozvojem databázových systémù, které nyní umožòují zpracování aplikaèní logiky (tzv. uložené procedury databázového systému), a jednak s nástupem technologií internetu. Serverový systém zajišťuje kompletní zpracování aplikaèní a datové logiky a pøipravuje nezbytná data pro prezentaèní logiku. Klientský systém zajišťuje zpracování prezentaèní logiky, tedy obsluhu vstupu od uživatele a zobrazení uživatelského rozhraní aplikace s daty, které dodá aplikaèní logika. Výhodou této varianty je snížení nárokù na správu aplikace. Klíèové èásti aplikace jsou centralizovány, pøièemž systémy umožòují, aby prezentaèní logika byla klientskému systému zaslána dynamicky až v okamžiku, kdy má být klientským systémem zpracována. Nevýhodou pak je to, že server se vedle zajištìní datové logiky (tj. správu dat) musí starat i o provádìní aplikaèní logiky, tj. konkrétních výpoètù.

Prezentaèní logika Prohlížeè

Webový server

Aplikaèní logika

Datová logika

Aplikaèní server


Operaèní systém

Operaèní systém

Operaèní systém

Operaèní systém

Operaèní systém

Operaèní systém

Prohlížeè Prezentaèní logika Klientský systém

Webový server

Aplikaèní server


Aplikaèní logika

Datová logika

Prostøední prvek

Prvek zpracovávající datovou logiku

Obr. 2.7 Tøíúrovòový model klient/server v internetové aplikaci Reakcí na nedostatky variant dvouúrovòového modelu je vznik tøíúrovòového modelu klient/server. Aplikaèní logika je zpracována novým prvkem systému. Tento prvek vystupuje vùèi klientskému systému, který zpracovává prezentaèní logiku, jako server. Zároveò vùèi systému, který zpracovává datovou logiku, vystupuje jako klient.


57

2

Prostøední vrstva pak také zajišťuje situace, kdy aplikaèní logika vyžaduje data, která dodává nìkolik datových logik najednou. Model zároveò umožòuje, aby prezentaèní logika byla realizována rùznými klientskými systémy (PC, mobilní telefon). Obr. 2.7 ukazuje užití modelu jednoduché internetové aplikace. V implementacích je tento prvek zastoupen prostøedky, které oznaèujeme pojmem transakèní monitor (ORB – Object Request Broker) a aplikaèní server. N-úrovòový model klient/server je pouze rozvinutím pøedchozího modelu. Pro zajištìní provádìní aplikace je k dispozici klientský systém, který zpracovává prezentaèní logiku aplikace. Ta je pøipravována specifickou komponentou (pøístupový systém) podle typu klientského systému (osobní poèítaè, mobilní telefon apod.). Aplikaèní logika je zpracována aplikaèní vrstvou modelu, pøièemž prostøednictvím integraèní vrstvy mùžou být aplikaèní logice dodávány výsledky zpracování jiných aplikací anebo data z jiných systémù. Výsledky a data pøedstavují datovou logiku aplikace. Komunikaci mezi programovými komponentami v jednotlivých modelech lze popsat jednoduchými komunikaèními vzory – vzory výmìny zpráv. Mezi tyto vzory patøí: dotaz–odpovìï, oznámení–odpovìï, požadavek bez odpovìdi a oznámení bez odpovìdi (obr. 2.8).

1. dotaz-odpovìï

3. požadavek bez odpovìdi

Dotaz Klient

Server

Klient

Požadavek

Server

Odpovìï

2. oznámení-odpovìï

4. oznámení bez odpovìdi

Oznámení

Oznámení Klient

Server

Server

Klient

Odpovìï

Obr. 2.8 Komunikaèní vzory

2

Pøíklady použití vzorù: l

l

58

Vzor dotaz–odpovìï patøí k nejèastìji užívaným. Komunikaci inicializuje klient. Napøíklad uživatel prostøednictvím prohlížeèe (klient) zadává adresu webové stránky. Webový server jako odpovìï zasílá požadovaný dokument (webovou stránku) jako proud dat. Tento vzor je také oznaèován jako blokovaná komunikace, protože klient èeká a jeho zpracování je blokováno, dokud nepøijde odpovìï. Jiným pøíkladem mùže být požadavek na vyhledání telefonního èísla osoby v telefonním seznamu. Klient zasílá dotaz tvoøený jménem (nebo pouze èástí jména). Server odpovídá seznamem osob a jejich telefonních èísel, které odpovídají požadavku. U vzoru oznámení–odpovìï inicializuje komunikaci server. Jako pøíklad lze použít aplikaci objednávkového systému, která oznamuje další objednávku jiné aplikaci, kterou používá nìjaká zodpo-


2

l

l

vìdná osoba k ne/schvalování objednávek. Po zhodnocení objednávky je aplikaci objednávkového systému zaslána odpovìï, jak má s objednávkou pracovat dále (schválena, zamítnuta apod.) Vzor požadavek bez odpovìdi patøí k èasto užívanému komunikaènímu vzoru. Jednoduchým pøíkladem použití vzoru mùže být aplikace pro plánování schùzek, kdy pro schùzku lze stanovit požadavek na upozornìní ve stanovený èas pøed zahájením schùzky. Aplikace pak pouze pøedá zprávu napø. systému elektronické pošty, který se stará o zaslání upozornìní. Systém elektronické plánovací aplikaci již neodpovídá. Jako pøíklad uplatnìní vzoru oznámení bez odpovìdi lze použít aplikaci, kterou používáme ke sledování stavu akcí. Naše aplikace komunikuje napø. s burzovním systémem. Burzovní systém (server) v pøípadì, že dojde ke zmìnì ceny akcie, zasílá zprávu aplikaci pro sledování cen akcií (klient). Naše aplikace (klient) neodpovídá serveru, ale pouze si zaktualizuje pøíslušné data.

Komunikace v konkrétní aplikaci i mezi aplikacemi je tvoøena kombinací tìchto vzorù. Souèasnì s možností distribuovat zpracování aplikace mezi klienta a server nebo øadu serverù, umožòují informaèní technologie s rozvojem databázových systémù øešit situaci, kdy data jsou sice uložena v místì jejich vzniku (anebo jejich nejvýznamnìjšího zpracování), ale nemají být chápána jako samostatné jednotky, nýbrž jako jedna databáze – distribuovaná databáze (Date, 2001; Özsu, 1999). Významné pro zpracování aplikací je to, že systém øízení distribuované databáze zajišťuje pro aplikaci transparentnost, jinak øeèeno aplikace se nemusí zajímat, zda data databáze jsou distribuovaná, nebo ne. Specifickým pøípadem distribuovaného zpracování a jeho dalším evoluèním stupnìm je využití pøístupù – grid a cloud computing. Grid pøedstavuje dynamické propojení výpoèetních zdrojù (poèítaèe, základní programové vybavení, poèítaèová síť a vhodné aplikace). Uživatel gridu je mùže využít pro øešení rozsáhlých a výkonovì nároèných výpoètù, pro nìž by sám nemìl dostateènou výpoèetní kapacitu. Standardizací jednotlivých vrstev gridu se zabývá Open Grid Forum (OGF, www.gridforum.org) a jako pøíklad lze uvést projekt METACentrum (meta.cesnet.cz), v jehož rámci je vytvoøen virtuální distribuovaný poèítaè složený z øady spolupracujících superpoèítaèových center.19 Cloud computing je definován jako výpoèetní služby provádìné a dostupné prostøednictvím veøejné IP sítì (internetu) (Pužmanová, 2008). Uživatelé, respektive jejich aplikaèní systémy, využívají pøístupných a dostupných služeb „oblaku“. Pøíkladem jsou diskové kapacity, služby databázových úložišť, bezpeènostní služby a také informaèní služby. Komerènì dostupným øešením je Amazon Web Services (aws.amazon.com)20 nebo tøeba v oblasti zajištìní bezpeènosti (ochrana proti malware) je to CloudAV (www.eecs.umich.edu/fjgroup/cloudav/) a další.

Ò

Z kapitoly vìnované technologiím jakožto jednomu ze zdrojù podnikové informatiky vyplývají následující závìry: l

l

Technologie pøedstavují širokou škálu rychle se rozvíjejících technických prostøedkù, programového vybavení a prostøedkù telekomunikaèních a poèítaèových sítí. Konkrétní výbìr, uspoøádání a nasazení technologií závisí na požadavcích organizace, které jsou implementovány jako aplikace podnikové informatiky.

19

Jako další pøíklad je možné uvést EGEE (Enabling Grids for E-scienceE), spolufinancovaný EU a využívající 250 lokalit (egee.cesnet.cz). 20 V rámci AWS jsou poskytovány napø. následující služby – elastický výpoèetní oblak (EC2 – Elastic Compute Cloud), služby diskových zdrojù (S3 – Simple Storage Service) apod.


59

3

3. Data v podnikové informatice Data jsou klíèovým zdrojem podnikové informatiky a patøí k základnímu bohatství a aktivùm organizace. Uživatelé se s daty setkávají: l l l

l

když zaznamenávají údaje prostøednictvím rozhraní aplikací, tj. když údaje pøiøazují ke vhodným pojmùm; když jsou jim data aplikacemi a technologiemi prezentována jako informace; v procesu modelování dat, kdy jsou formulovány požadavky na to, jaká data by mìla být v informaèním systému zachycena; v procesu, ve kterém uživatelé specifikují, jak mají být data transformována aplikacemi, aby poskytla vhodné informace.

y

Cílem této kapitoly je charakterizovat vztah mezi pojmy data, informace a znalost, uvést význam metadat a pøedstavit formy prezentace dat a také základní mechanismy, které jsou používány pro ukládání dat.

3.1 Data a metadata, informace, znalosti a informaèní systém Deset. Deset korun. Jednotková cena je deset a je v korunách. Z pohledu informaèního systému se jedná o øadu údajù pøedstavujících v systému data. Ale èlovìk po pøeètení výše uvedeného je schopen u uvedených vìt rozlišit rozdíly. Tyto rozdíly de facto odlišují pojmy data, informace a znalosti. Drucker (Drucker, 1998) uvádí následující: „Data reprezentují specifické vlastnosti objektù (entit a událostí v reálném svìtì). Data jsou množinou popisující objekt bez kontextu. Data se stávají informacemi, když je vhodnì zpracujeme (strukturujeme) a dodáme za urèitým úèelem. Data v kontextu jsou informacemi a informace, které jsou použity, jsou znalostí, tzn., že zkušenosti transformují informace do znalosti.“ Pro náš pøíklad je „deset“ údaj. Nemá však pro nás žádný význam. Pokud ale údaj pojmenujeme, tj. vytvoøíme si vhodný pojem (koncept) pro uvedený údaj v procesu konceptualizace (separace a pojmenování), získáme informaci. V našem pøíkladì jsme daný údaj pojmenovali tak, že jde o mìnu (deset korun) a že jde o jednotkovou cenu (jednotková cena je deset korun). Pøiøazením významu (v kontextu formulace P. Druckera jsme vlastnì urèili, kterou vlastnost objektu daný údaj reprezentuje) získáváme informaci. Hodnota pro uživatele vzrùstá, èím lépe je údaj zaøazen do vhodné kategorie pojmù (je to cena a je v korunách).

`

Údaj reprezentuje zachycený fakt o nìjakém objektu reality. Kolekci údajù oznaèujeme pojmem data. Informace je význam pøisouzený datùm.1 1

Zavedli jsme si pojem a pojmem vlastnì oznaèujeme (pojmenováváme) nìjakou vlastnost nìjakého objektu, jehož údaje jsme se rozhodli sledovat (zaznamenávat, zpracovávat a prezentovat). Pojem není pro poèítaèový 1

Obsah pojmu informace se v prùbìhu doby vyvíjel.

Data v podnikové informatice

61

3

systém nic jiného než opìt nìjaký údaj. Protože ale tento údaj vyjadøuje význam jiného údaje, používáme pro jeho odlišení od dat termín metadata.

`

Metadata jsou data popisující data jiná. Jejích prostøednictvím se lze na data dotázat, jsme schopni data doplòovat, konsolidovat je, vzájemnì je synchronizovat a integrovat.

Rozsah metadat k údaji mùže být rùzný a platí, že k urèitým datùm se vždy vztahuje urèitá konkrétní kolekce metadat. Kolekce metadat je množina dat, jejíž prvky lze popsat dvojicí „název“ a „hodnota“.

Metadata k danému údaji

Volta 75 ; 75 ; E27 ; 10 Soubor dat k nìjakému objektu reality, v tomto pøíkladì k žárovce

Název

Hodnota

name

Jednotková cena

typ

Mìna

Metadata k souboru dat

Název

Hodnota

name

Zboží

atributy

Název, Výkon, Závit, Jednotková cena

Obr. 3.1 Pøíklad metadat nìjakého objektu reality Obr. 3.1 ukazuje zjednodušený pøíklad zachycení metadat. Pro údaj (10) specifikujeme, že je to jednotková cena a že typ je mìna. Pro soubor dat uvádíme jako metadata pojmenování tohoto souboru dat (Zboží) a uvádíme výètem, které vlastnosti (atributy)2 jsou sledovány (Název, Výkon, Závit, Jednotková cena). Urèením, která data sledovat o kterých objektech reality, respektive formulací metadat k požadovaným údajùm, se zabývá datové modelování (viz kapitola 12). Mohou to být data o objektech reality, tj. jedná se buï o zachycení urèité entity (údaje o zákazníkovi, údaje objednávky apod.), anebo o události (stav procesu objednávky). Data v podnikové informatice pøedstavují: l

l

l

2

62

obchodní podniková data, napø. zákazník, objednávka, zboží, prùbìh procesu objednání, prùbìh procesu nákupu zboží na sklad apod.; data související s øízením IS/ICT zachycují údaje o jednotlivých zdrojích IS/ICT, napø. data o technických prostøedcích, softwaru, zaznamenané požadavky na funkcionalitu aplikací apod.; data, která si vytváøejí programové prostøedky pouze pro své úèely, napø. konfiguraèní data, rùzné zprávy a signály.

Na tomto místì platí, že vlastnost = atribut, èili oba pojmy mají shodný význam. V okamžiku zaèlenìní objektovì orientovaného pøístupu již ale tato významová rovnost neplatí (viz kapitola 3.2.3).


3

Kolekce metadat je vhodné v informaèních systémech vhodnì uspoøádat. Pro uspoøádání metadat sestavilo sdružení OMG3 architektonický model metadat (Metadata Architecture). Model uspoøádává data a metadata do ètyø vrstev. Vrstva 0 modelu (M0) pøedstavuje skuteèná data. Obr. 3.2 zjednodušenì znázoròuje objednávku. Èíslo objednávky: 12345 Datum objednávky: 12. 12. 2008 Fakturaèní adresa Jan Novák Pod návsí 15 150 00 Praha 5 Položka 1 2

Název Volta 75 Volta 100

Dodací adresa Jan Novák Pod návsí 15 150 00 Praha 5 Poèet

Jednotková cena

Cena

10 3

10,00 12,00

100,00 36,00

Celkem DPH Celkem k platbì

136,00 25,00 161,00

Legenda k obrázku: Text zapsaný kurzivou jsou zobrazená metadata. Text tuèný znázoròuje zobrazená data. Ostatní texty znázoròují data vypoèítaná.

Obr. 3.2 Pøíklad zachycení skuteèných dat Vrstva 1 pak obsahuje model dat a zachycuje metadata o skuteèných datech z vrstvy 0. Hovoøíme o vrstvì modelu (M1). Obr. 3.3 zachycuje jeden z možných modelù objednávky. Samozøejmì je možné si vytvoøit vlastní metadatový model (jako v našem pøíkladì), avšak èasto jsou pøedevším z dùvodu standardizace vytváøeny metadatové modely rùznými konsorcii a uskupeními. Ta formulují pro danou oblast nebo odvìtví vhodný model metadat, napø. HR XML (lidské zdroje), ACORD (pojišťovnictví), SID (telekomunikace), CIM (veøejné služby), PPDM (energetika), ebXML (dodavatelsko-odbìratelské øetìzce), HL7 a HIPAA (zdravotnictví), FPML a SWIFT (kapitálové trhy).4 Vrstva 2 obsahuje modely (metamodely, M2), kterými popisujeme, jak interpretovat model dat z vrstvy 1. Pomocí metamodelu definujeme základní elementy, vztahy mezi nimi a principy vytváøení modelù jednotlivých druhù. Poslední vrstva (vrstva 3, M3) obsahuje popis, jak interpretovat metamodely.5 Pokud informaci dáme do souvislostí (kontextualizujeme ji) s dalšími informacemi, napø. pro vìrné zákazníky mùže být sleva až 10 % z jednotkové ceny, získáváme znalost. Zahrneme-li i svoji intuici a zkušenost, obecnìji, zahrneme-li schopnost klást si otázky, na které nejsou snadné odpovìdi, schopnost rozlišovat co je dobré 3 4

5

OMG – Object Management Group (www.omg.org) HR XML (Human Resources XML vocabularies), ACORD (Association for Cooperative Operations Research and Development), SID (Shared Information/Data Model), CIM (Common Information Model), PPDM (Public Petroleum Data Model), ebXML (Electronic Business using eXtensible Markup Language), HL7 (Health Level 7), HIPAA (Health Insurance Portability and Accountability Act), FPML (Financial Product Markup Language), SWIFT (Society for Worldwide Interbank Financial Telecommunication) Pro úèely této publikace postaèuje uvìdomit si popis ve vrstvách 0 a 1. Pro studium modelù v dalších vrstvách lze odkázat napø. na kapitolu 6.3 publikace Podnikové procesy (Øepa, 2007) anebo pøímo na stránky OMG Model Driven Architecture (http://www.omg.org/mda/).


63

3

a co je špatné, adoptujeme-li to, co oznaèujeme pojmem morálka a principy, dostáváme se k moudrosti. V našem pøíkladì se napø. konkrétní obchodní zástupce rozhodne, za kolik dané žárovky prodá konkrétnímu zákazníkovi, tj. jak velkou slevu uplatní. Obr. 3.4 schematicky zachycuje trajektorii data–informace–znalosti–moudro. Objednávka Èíslo objednávky: èíslo Datum objednávky: datum Má detail/patøí k

Je poslána/obdrží Adresa objednavatele

Detail objednávky Položka: èíslo ID zboží: èíslo

Èíslo objednávky: èíslo ID adresy: èíslo

Èíslo objednávky: èíslo Poèet: èíslo

Typ adresy: text

Má zahrnuje/je v

Hraje roli/vyskytuje se Adresa

Zboží ID zboží: èíslo

ID adresy: èíslo Adresa Adresa1: text Adresa2: text Mìsto: text PSÈ: text

Název: text Výkon: èíslo Závit: text Jednotková cena: èíslo

Obr. 3.3 Jeden z možných metadatových modelù objednávky

Moudro Intuice a zkušenosti Informace v akci

Znalost Kontextualizace, aplikování øešení problémù, umožòující individuální uèení, personalizaci

produkování Data v kontextu (strukturovaná a zpracovaná)

Informace Konceptualizace, kategorizace, klasifikace

ukládání

Data

Obr. 3.4 Data, informace, znalost, moudrost (zdroj: /modifikace/ Vejlupek, 2005; de Vasconcelos, 2001)

64


3

Zmiòme ještì vztah kategorií data, informace, znalost k poèítaèovému systému. Poèítaèový systém pracuje s daty, ať již jsou to pro èlovìka data, informace nebo znalosti. Proto se také pro jeho oznaèení používá pojem systém zpracování dat (data processing system). Takový systém je chopen manipulovat s daty (transformovat je). Abychom ho mohli prohlásit za systém informaèní, musí být poèítaèový systém schopen na základì jiných dat (metadat) poskytovat data v kontextu a pøípadnì zpracovaná dle definovaných požadavkù. Nìkteré systémy dokážou konceptualizovaná data (informace) uvést do kontextu s jinými informacemi a nazýváme je znalostními systémy. V rámci podnikové informatiky ale budeme pojmem informaèní systém oznaèovat systém, ať již pracuje s daty, informacemi anebo znalostmi. Míra automatizovaného zpracování dat závisí na možnosti zachytit jejich strukturu, tj. uspoøádání dat a metadat. V zásadì hovoøíme o datech strukturovaných, nestrukturovaných a semistrukturovaných. U strukturovaných dat jsme pro sledovaný objekt schopni pøesnì popsat jejich strukturu, tj. jsme schopni data popsat exaktním formálním schématem a stanovit pro každý údaj vhodná metadata (napø. již zmínìné zboží). Další množinu dat oznaèujeme jako nestrukturovaná data – u nich nelze jejich metadaty popsat jejich strukturu a tedy poèítaèový systém není bez pomoci èlovìka schopný stanovit význam jednotlivých èástí. Pøíkladem mùže být dokument ve Wordu, kdy poèítaèový systém není schopný samostatnì a automaticky ve vìtì identifikovat, že právì toto slovo je názvem výrobku. Pokud se nám podaøí do nestrukturovaných dat zahrnout alespoò nìjakou volnou strukturu, pak hovoøíme o tzv. semistrukturovaných datech. Pøíkladem mùže být dopis, u kterého jsme schopni vyznaèit alespoò urèitou strukturu, napø. informace o adresátovi, vìc, odesílatele apod.

3.2 Prezentace, uložení a zpracování dat 3.2.1 Prezentace dat a metadat Data a metadata jsou uživateli prezentována aplikacemi jako obraz nebo zvuk. Obrazová data jsou uživateli zprostøedkována prostøednictvím zobrazovacího zaøízení, napø. zobrazením na monitoru, vytištìním na tiskárnì apod., oproti tomu zvuková data prostøednictvím zaøízení k reprodukci zvuku. V pøípadì obrazu lze zjistit, že ho tvoøí: l l

texty – vytváøené množinou dohodnutých znakù, zpravidla národních abeced, grafické objekty (grafika) – obrázky, fotografie, schémata apod., napø. logo zákazníka.

Textová data jsou prezentována jako neuspoøádané nebo uspoøádané texty. Pøíkladem neuspoøádaného textu mùže být text smlouvy. Pøestože i zde existuje vnitøní logika uspoøádání – smluvní strany, èlánky smlouvy atd., v systému toto vìtšinou nezachycujeme. Pøíkladem uspoøádaného textu je formuláø, napø. objednávky s definovanou strukturou a rozvržením zobrazení. Souèástí zobrazení strukturovaných dat je zobrazení i metadat, která uživateli napovídají, jak má hodnotu interpretovat (viz obr. 3.2). V rámci grafiky tvoøí významnou podmnožinu (z pohledu podnikové informatiky) tzv. obchodní grafika, tj. znázornìní textù (zde pøevážnì èísel) formou nejrùznìjších grafù. Za urèitých podmínek, zpravidla se jedná o frekvenci zmìny obrazu, vzniká u uživatele iluze pohybu obrazu. Takové objekty se oznaèují jako animace nebo video. U obou je možné kombinovat obraz se zvukem.


65

3

3.2.2 Organizace dat a tradièní (souborový) a databázový pøístup k uložení dat Pomocí modelù si rùznì seskupujeme a organizujeme data do vìtších celkù a lze u nich sledovat hierarchickou strukturu. Nejmenší jednotkou dat (a informace), kterou máme k dispozici, je bit. Ten však pro lidi nemá „smysluplný význam“. Proto za nejmenší jednotku z pohledu lidí budeme považovat znak (character), který reprezentuje písmeno národních abeced, èíslici nebo speciální symbol. Z hlediska poèítaèe je to množina uspoøádaných bitù nebo bajtù, pøièemž kolik bitù nebo bajtù je potøeba na zachycení znaku, závisí na použitém poèítaèovém kódování znakù (viz pøíloha 8). Znaky jsou seskupovány do vìtšího celku – položky (field). Položka reprezentuje urèitou vlastnost sledovaného objektu reality, napø. 12345 reprezentuje identifikátor objednávky, Praha 5 je mìsto apod., a ve výše uvedené terminologii je údajem. Jednotlivé položky jsou opìt seskupovány do vìtšího celku, tzv. záznamu (record). Záznam je kolekcí vzájemnì souvisejících položek. Kolekce položek popisující vlastnosti zboží vytváøí záznam o zboží. Položka je v záznamu identifikována svými metadaty, pokud byla definována, nebo poøadím položky v záznamu, pokud metadata definována nebyla. Jednotlivé položky v záznamu jsou od sebe oddìleny buïto speciálním oddìlovaèem anebo položka má vyhrazenu pøesnì stanovenou délku. Jednotlivé záznamy jsou seskupeny do vìtšího celku, tzv. souboru dat (file). Soubor je kolekcí vzájemnì souvisejících záznamù. Napø. kolekce záznamù o rùzném zboží vytváøí soubor dat zboží. Záznam je v souboru identifikován svým poøadím anebo existencí specifické položky v záznamu, kterou oznaèujeme jako klíè (napø. ID zboží). Jednotlivé záznamy jsou od sebe oddìleny speciálními oddìlovaèi. Pozor, termín soubor je v tomto pøípadì logickým konceptem a nemá nic spoleèného se souborem, jak jsme o nìm mluvili v souvislosti se souborovým systémem, i když jím samozøejmì mùže být. Na nejvyšší úrovni hierarchie dat je tzv. báze dat (database). Báze dat je kolekce vzájemnì souvisejících souborù dat. Napø. soubor dat objednávek spolu se souborem dat zboží a souborem adres vytváøí bázi dat objednávkového systému. Fyzickou realizaci modelu báze dat, tj. zpùsob uložení báze dat na vnìjších pamìtích, lze v zásadì realizovat dvìma základními pøístupy, pøípadnì jejich kombinací. První pøístup je oznaèován jako tradièní a vychází z historického vzniku báze dat, kdy postupnì vznikaly soubory dat se svojí vnitøní logikou a aplikace, aplikaèní software, které s tìmito soubory dat pracovaly. Obr. 3.5 znázoròuje tradièní pøístup k datùm. Báze dat je tvoøena samostatnými soubory a s každým souborem pracuje konkrétní aplikace. Aplikace pro pøístup k datùm využívají služeb souborového systému a k dispozici mají následující operace: l l l l

otevøení a zavøení souboru, vytvoøení nového souboru, zrušení souboru, ètení celého souboru, ètení záznamu nebo ètení definovaného poètu bajtù, zápis do souboru.

Tradièní pøístup k ukládání dat se pøes øadu nevýhod stále používá. Uživatelé si stále své dokumenty, obrázky a fotografie, hudbu apod. vytvoøené pomocí autoringových nástrojù (napø. aplikace kanceláøského balíku, grafické programy atd.) ukládají formou souborù do adresáøových struktur na disku.

66


3

Druhý pøístup se oznaèuje jako pøístup databázový. Jeho snahou je øešit problémy a omezení tradièního pøístupu. Soubor dat je zde oznaèován pojmem entita, záznamy jsou výskytem entity a položky se oznaèují pojmem atribut entity. Množina vzájemnì souvisejících entit tvoøí databázi. Organizaci entit a pøístup k datùm je øízen specializovaným programovým vybavením, tzv. systémem øízení báze dat (SØBD). Databáze a SØBD dohromady tvoøí databázový systém (viz obr. 3.6). Soubor dat Adresa Evidence adres zákazníkù

Jan Novák; Pod návsí 15; Praha 5, 150 00 Petr Honza; Na pøíkladì 1, Beroun; 266 01

Evidence zboží na skladì

Volta 75; 75; E27; 6.5; 10 Volta 100; 100; E27; 7; 15 Soubor dat Objednávka 12345; 12.12.2008; Jan Novák; Pod návsí 15; Praha 5, 150 00; Jan Novák; Pod návsí 15; Praha 5, 150 00; Volta 75; 75; 6.5; 10; Volta 100; 7; 3 99999; 14.12.2008; Petr Honza; Na pøíkladì 1, Beroun; 266 01; Petr Honza; Na pøíkladì 1, Beroun; 266 01; Volta 100; 7; 15

Evidence objednávek

Báze dat podniku

Soubor dat Zboží

Obr. 3.5 Tradièní pøístup k datùm

Databázový systém

Evidence zboží na skladì

Evidence objednávek

Databáze Systém øízení báze dat

Evidence adres zákazníkù

Implementovaný metadatový model

Entita Zboží Entita Adresa objednavatele

Entita Objednávka Entita Adresa

Entita Detail objednávky

Obr. 3.6 Databázový systém Výhody a nevýhody souborového a databázové pøístupu shrnuje tab. 3.12.


67

3

Tab. 3.1 Sumarizace výhod a nevýhod obou pøístupù k datùm Souborový pøístup l

snadná pøenositelnost dat, neboť soubor lze snadno pøenést z jednoho místa na jiné

l

optimalizované uložení u nìkterých typù dat (grafická data, zvuk, video)

l

možnost externího popisu vnitøní struktury u nìkterých typù dat standardizovanými prostøedky, èímž je snížena tìsná vazba s konkrétní aplikací (napø. XML – viz dále)

l

je podporován pøímo operaèním systémem, není potøeba instalovat (a mnohdy i platit) a spravovat další dodateèný SW, který zvyšuje složitost používání

Výhody

l

tìsná vazba mezi daty a aplikací, která je zpracovává, tzn. že jiná aplikace datùm nerozumí

l

prakticky nemožné sdílení dat pøi aktualizaci, neboť pøi požadavku zápisu do souboru souborový systém odmítá požadavky jiných programù, i když požadují zmìnu jiných záznamù v souboru

l

vysoká redundance (duplicity nebo multiplicity uložení) dat v rùzných souborech

l

soubor obsahuje pouze jeden typ dat (buïto text, nebo grafiku apod.)

l

pøístup k datùm je sekvenèní a pro získání požadovaných dat je nutno postupnì „probrat“ i data nepotøebná; existuje i pøístup pøímý, kdy je možné pøistoupit k požadovanému záznamu pomocí znalosti jeho poøadí nebo pøístupem na konkrétní znak, pokud známe jeho poøadí

l

neexistence možnosti øízení pøístupu na úrovni záznamu nebo položky, pøístup je øízen na úrovni celého souboru operaèním systémem

l

vysoké nároky na technologické zdroje pøi práci s velkými objemy dat

Nevýhody

68

Databázový pøístup l

data a aplikaèní programy nejsou tìsnì svázány, specifické programové prostøedky skrývají aplikacím vnitøní strukturu databáze a poskytují standardní prostøedky pøístupu k datùm – specializované jazyky, nezávislé na aplikaci

l

nízká míra redundance dat, protože data jsou umístìna v jednom datovém prostoru; pokud redundance existuje, pak se využívá pro zkrácení doby odezvy

l

vysoká míra zajištìní integrity dat, kdy pøi zmìnì dat je automatizovanì zajišťována zmìna dat, která na datech mìnìných závisí (jsou vzájemnì provázána)

l

robustní prostøedky pro øízení pøístupu k datùm, a to až na úroveò atributu

l

možnost sdílení dat rùznými aplikacemi pøi zajištìní konkurenèního (souèasného) pøístupu, a to až na úroveò atributu

l

optimalizace uložení a rychlý pøístup k velkým objemùm dat

l

data jsou nesnadno pøenositelná, pro pøenos musíme použít prostøedky pro exportování a importování dat

l

vysoké kvalifikaèní požadavky na administrátora databáze

l

nákladnost robustních SØBD, které data databáze spravují


3

Databázový pøístup se vyvíjel a postupnì vznikl model hierarchický, síťový, relaèní, objektovì-relaèní a objektový. V souèasné dobì je nejrozšíøenìjším modelem relaèní model databáze, pøípadnì objektovì relaèní model (viz další èást kapitoly). Pro pøístup k databázím, a to ať z dùvodu potøeby manipulace se strukturou databáze nebo z dùvodu potøeby manipulovat s konkrétními daty databáze, byly u všech modelù definovány jazyky, které tyto operace umožòují. Pro manipulaci se strukturou databáze se používá jazyk definice dat (DDL – Data Definition Language), který umožòuje definovat a popsat uspoøádání datových struktur databáze a vztahy mezi jejími jednotlivými èástmi. Pomocí tohoto jazyka implementujeme metadatový model. Zároveò vzniká i datový slovník (Data Dictionary), jako prostor soustøeïující informace o databázi (implementovaný metadatový model). Datový slovník obsahuje minimálnì detailní popis všech dat, respektive metadat, a vytváøí jak logický pohled na databázi (schéma), tak i pohled fyzický. Vedle jazyka definice dat zahrnuje databázový systém i jazyk manipulace s daty (DML – Data Manipulation Language). Ten nabízí specifické konstrukce, které umožòují jednoduchým zpùsobem zpøístupnit data z databáze, vèetnì možnosti jejich zmìn. K jednomu z jazykù, který se nejèastìji uplatòuje u relaèních databází a zahrnuje i vlastnosti jazykù definice dat vèetnì manipulace s nimi, se vrátíme v kapitole 3.3.2.

3.2.3 Objekty Na poèátku této kapitoly jsme uvedli, že „data reprezentují specifické vlastnosti objektù“. Význam pojmu objekt je široký a v praxi se používá témìø pro vše. V poèítaèovém svìtì se dnes používá jako klíèový princip pøi zpracování a prezentaci dat aplikacemi, pøi implementaci programù a aplikací (objektovì orientované programování), ale také v oblasti jejich analýzy a návrhu (objektovì orientovaná analýza a návrh). Zatímco v tradièním i databázovém pøístupu jsou vlastnosti objektù vyjádøeny v podobì atributù objektù, pak v objektovém pøístupu chápeme pojem vlastnost objektu šíøeji. Vedle atributù ji tvoøí i metody, které s hodnotami atributù manipulují. Napøíklad pro objekt Volta 75, který má atribut Jednotková cena jsou k dispozici metody Zjisti cenu a Nastav cenu. Uživatelé se s tímto principem mohou setkat pøi práci s textovým editorem. Pokud napø. manipulují s tabulkou, kterou si do textu vložili, mají k dispozici množinu metod, které se vážou pøímo k tabulce (viz obr. 3.7). Dále objektový pøístup rozlišuje mezi konkrétním a abstraktním. Objekt je vždy to konkrétní, tj. to, co je vyjádøeno skuteènými vlastnostmi. Abstrakcí pak získáváme abstraktní objekt, který se oznaèuje pro odlišení pojmem tøída. Objekt je pak instancí (výskytem) tøídy. V našem pøíkladì je tøídou Zboží a instancí konkrétní zboží, tj. napø. objekt s Názvem Volta 75. K objektùm se váže øada dalších principù6. Zmiòme zde pouze principy zapouzdøení (encapsulation) a ukrývání implementace (information hiding), dìdiènost (inheritance) a mnohotvarost (polymorfismus). Zapouzdøení (encapsulation) pøedstavuje umísťování dat a souvisejících metod k sobì (Pavlíèková a další, 2005) a spolu s ukrýváním implementace zajišťuje, aby se konkrétní metoda vázala ke konkrétnímu objektu a byla dostupná jiným objektùm v souvislosti s manipulací s objektem, jehož metodu chceme využít. To napø. pro náš pøíklad s objednávkou znamená, že pro objekt Objednávka není dostupná metoda Zjisti cenu konkrétního objednaného zboží, protože se jedná o metodu objektu Zboží. Pro pøíklad s tabulkou v MS Word jsou pro celou tabulku k dispozici pouze metody aplikovatelné na celou tabulku (viz na obr. 3.7 rámeèek vlevo) ostatní metody jsou skryty a jsou dostupné až v okamžiku, kdy k objektu pøistupujeme jiným zpùsobem (viz na obr. 3.7 rámeèek vpravo). 6

Pro detailní studium lze odkázat napø. na stránky Objektová analýza, návrh a programování (objekty.vse.cz).


69

3

Metody spojené s objektem tabulka

Obr. 3.7 Metody spojené s objektem tabulka v prostøedí MS Word Dìdiènost (inheritance) umožòuje, aby objekt byl potomkem jiného objektu a dìdil jeho atributy a metody. Pro pøípad objektu Zboží lze øíci, že se jedná o rodièe, který má atributy Název a Jednotková cena. Potomky pak mohou být jednotlivé žárovky, které dìdí výše uvedené vlastnosti, ale navíc mají další vlastnosti (Závit a Výkon). Jiným potomkem Zboží mùže být napø. Zásuvka s vlastnostmi Poèet zásuvek a Pøívodní šòùra, a také Kabel s vlastnostmi Délka a Typ. Obr. 3.8 ukazuje zachycení dìdiènosti. V pøíkladu s tabulkou MS Word si lze dìdiènosti povšimnout u metod Vyjmout, Kopírovat Vložit, které jsou zdìdìny od objektu Dokument. Zboží ID Zboží Název Jednotková cena Zjisti cenu Nastav cenu

Žárovka

Zásuvka

Kabel

Závit Výkon

Poèet zásuvek Pøívodní šòùra

Délka Typ

Obr. 3.8 Pøíklad zachycení popisu principu dìdiènosti

70


3

Mnohotvarost (polymorfismus) pøedstavuje (zjednodušenì) zajištìní situace, kdy existuje metoda se stejným názvem, ale co pøesnì bude metodou vykonáno, závisí na konkrétním použití. Po pøíklad s objednávkou to znamená, že kdyby existovala metoda Zjisti cenu u objektu Objednávka, pak se jedná o vypoèítanou hodnotu pro všechna objednaná zboží, zatímco tatáž metoda u objektu Zboží znamená zjištìní Jednotkové ceny. U pøíkladu s tabulkou si lze povšimnout, že zde existuje metoda Vložit, která znamená buïto vložení obsahu schránky, anebo vložení informací související s tabulkou, tj. vložení øádku nebo sloupce. Na závìr k objektùm ještì jednu poznámku. Atributem objektu mùže být samozøejmì také objekt, tj. mùže existovat situace, že objekt je kolekcí jiných objektù. Pro náš pøíklad s objednávkou to znamená, že konkrétní objednávka vedle atributù Èíslo objednávky a Datum objednávky má jako další atribut kolekci objektù vyjadøující detailní informace objednávky (v našem pøípadì je reprezentována tøídou Detail objednávky).

3.3 Relaèní databáze a SQL Relaèní databáze a jejich modifikace patøí k základním prostøedkùm uložení dat v dnešních podnikových informaèních systémech. V této èásti kapitoly budou prezentovány základní principy, jazyk, který se využívá pro pøístup a manipulaci s daty, a smìry, kterými se rozvoj relaèních databází ubírá.

3.3.1 Principy relaèních databází Relaèní databáze jsou založeny na matematickém principu relací a jejich principy formuloval E. F. Codd v roce 1970. Zjednodušenì (bez matematického aparátu) si na tomto místì øeknìme, že relace si znázoròujeme jako tabulku. Tabulka v zásadì odpovídá souboru dat hierarchického modelu a objektu metadatového modelu. Øádek tabulky odpovídá záznamu a sloupec odpovídá položce hierarchického modelu. V databázovém pojetí sloupec tabulky oznaèujeme pojmem doména. Využijme metadatového modelu s objednávkou (viz obr. 3.3). Pøi jeho implementaci je databáze tvoøena pìti relacemi – tabulkami (viz obr. 3.9). Relace Zboží, Adresa a Objednávka se oznaèují jako entitní relace a relace Adresa objednatele a Detail objednávky popisují vztah mezi entitními relacemi, a jsou proto oznaèovány pojmem relace vztahová. S databází je spojena také integrita, což je tvrzení, kterým omezujeme možné hodnoty atributù, pøípadnì možné manipulace se záznamy, které existují ve vazbì k záznamùm jiné tabulky. K významným integritním omezením patøí existence primárního klíèe (tzv. entitní integrita). Zajišťujeme jím jednoznaènou identifikaci záznamu v tabulce. V našem pøíkladì jsou položky, které hrají roli primárního klíèe, oznaèeny obrázkem klíèe. Primární klíè mùže vzniknout i jako kombinace hodnot zvolených atributù. Pøíkladem primárního klíèe mùže být Èíslo objednávky v tabulce Objednávka. Dalším typem integritního omezení je doménová integrita, která zajišťuje, aby údaj uvedený jako hodnota atributu byl vybrán z množiny definovaných pøípustných hodnot. Napøíklad pro sloupec (doménu) Typ adresy v tabulce Adresa objednatele mùže být takovým doménovým omezení možnost uvedení buïto hodnoty Fakturaèní nebo hodnoty Dodací. Posledním typem integritního omezení je tzv. referenèní integrita, která je reprezentována cizím klíèem (foreign key), a v našem pøíkladì je položka, která je cizím klíèem, oznaèena zkratkou FK. Princip referenèní integrity zajišťuje: l

aby nemohla být vložena jako hodnota atributu, který je oznaèen jako cizí klíè, hodnota, jež nemá odpovídající hodnotu atributu v tabulce, jejíž klíè jako cizí uvádíme. Tak je napø. zajištìn vztah mezi tabulkou Objednávka


71

3

l

a Detail objednávky, kdy platí, že v tabulce Detail objednávky se jako hodnota atributu Èíslo objednávky nesmí objevit jiné èíslo než to, které je uvedeno u nìkterého ze záznamù v tabulce Objednávka. aby z tabulky nebylo možno odstranit záznam, jehož hodnota je uvedena jako cizí klíè v tabulce jiné. To napø. znamená, že nelze odstranit záznam z tabulky Zboží, jehož ID zboží je rovno 1, protože se tato hodnota vyskytuje jako hodnota cizího klíèe v tabulce Detail objednávky. Tabulka: Objednávka

Tabulka: Adresa objednatele

Èíslo objednávky

Datum objednávky

Èíslo objednávky

12345

12.12.2008

99999

14.12.2008

Tabulka: Detail objednávky Položka

ID zboží (FK)

Èíslo objednávky

Poèet

1

1

12345

10

2

2

12345

2

1

2

99999

15

ID adresy (FK)

Typ adresy

12345

1

Fakturaèní

12345

1

Dodací

99999

2

Fakturaèní

99999

2

Dodací

Tabulka: Zboží ID zboží

Název

Výkon

Závit

Jednotková cena

1

Volta 75

75

E27

10

2

Volta 100

100

E27

7

Tabulka: Adresa Adresa1

Adresa2

Mìsto

1

Jan Novák

Pod návsí 15

Praha 5 150 00

2

Petr Honza

Na pøíkladì 1

Beroun

ID adresy

PSÈ

266 01

Obr. 3.9 Tabulky databáze

3.3.2 SQL – Structured Query Language Jak jsme uvedli, vnitøní fyzická struktura databáze je skryta za systém øízení báze dat (SØBD), který však nabízí formou schématu i logický pohled na data databáze. Ve skuteènosti nám nabízí prostøednictvím jazyka pro definici dat pøístup ke schématu dat s možností jeho zmìny a prostøednictvím jazyka pro manipulaci s daty prostøedky pøístupu ke konkrétním uloženým datùm. Protože existuje mnoho databázových systémù od rùzných výrobcù, kteøí relaèní model databáze implementovali do svých produktù, jevilo se jako výhodné standardizovat tyto jazyky, a usnadnit tak práci programátorùm a také uživatelùm, kteøí vyžadují pøístup k datùm uloženým v databázi. Výsledkem této snahy bylo ustavení standardu, který nese oznaèení SQL (Structured Query Language).

72


3

V rámci tohoto standardu byly definovány následující skupiny pøíkazù: l

l

l

l

pøíkazy pro manipulaci s daty (DML – Data Manipulation Language) – pro získávání dat z databáze a jejich zmìny, pøíkazy pro definici struktury databáze (DDL – Data Definition Language) – pro definování schématu databáze a její zmìny, pøíkazy pro øízení dat (DCL – Data Control Language) – pro definování pøístupových práv k databázi a k datùm a také pro øízení transakcí, ostatní pøíkazy – pro definování uživatelù, formulaci pravidel, napø. zpùsobu øazení dat podle národních abeced apod.

Toto èlenìní je zjednodušené a ve skuteènosti je skupin více, pro základní pøedstavu o jazyce však postaèuje.

Pøíkazy pro manipulaci s daty Pøíkazy této skupiny obecnì využívají vedle množinových operací, jako je kartézský souèin, sjednocení, prùnik a rozdíl, i relaèní operace, kam patøí: l

l

l

Projekce, kterou vybíráme pøíslušné atributy, neboli sloupce tabulky na základì výètu atributù (napø. název, závit). Ty atributy, které ve výètu uvedeny nejsou, se nebudou ve výsledku vyskytovat. Selekce, kterou vybíráme pøíslušné záznamy, neboli øádky tabulky na základì predikátù (výrokù), jako je napø. Poèet > 10. Do výsledku budou zaøazeny pouze ty záznamy, které odpovídají výroku. Jako operátor výroku jsou používány standardní relaèní operátory (=, <, >, <>, ³, £) a také operátory z oblasti množin Î, Ï, Ì reprezentované klíèovými slovy in, any, all, exists, not exists atd. Spojení, kterým spojujeme data z nìkolika relací, neboli nìkolika tabulek na základì predikátù. Napø. pro spojení tabulek Objednávka a Detail objednávky je pøi spojení definován výrok Objednávka.Èíslo objednávky = Detail objednávky.Èíslo objednávky. Jako operátor výroku se používají operátory booleovské algebry a dále specifické operátory urèující typ spojení – left join, right join, inner join atd.

Mezi základní pøíkazy pro manipulaci s daty patøí: l l l l

SELECT – zajišťuje výbìr dat z tabulek databáze, vèetnì jejich øazení a seskupení, INSERT – vložení dat do tabulek databáze, UPDATE – zmìna dat tabulek databáze, DELETE – smazání dat tabulek databáze.

2

Mìjme napø. databázi s definovaným modelem (viz obr. 3.3) a tabulkami (viz obr. 3.9). Nad touto databází si budeme formulovat nìkolik požadavkù, abychom si ukázali použití pøíkazù SQL. (1) Požadavek: Zjisti zboží, které má závit E27 a seøaï je abecednì. Analýza požadavku: data jsou v tabulce Zboží; l požadujeme z tabulky získat pouze hodnoty atributù Název, tj. budeme aplikovat operaci projekce; l požadujeme vybrat pouze ty øádky, které splòují podmínku, že Závit je E27, tj. budeme aplikovat selekci s podmínkou Závit =“E27“; l požadujeme setøídit výsledek abecednì. l


73

3

Formulace dotazu: SELECT Název FROM Zboží WHERE Závit=“E27“ ORDER BY Název Výsledek: Název Volta 75 Volta 100

(2) Požadavek: Zjisti dodací adresu pro objednávku èíslo 12345. Analýza požadavku: požadovaná data jsou v tabulce Adresa, protože ale tato tabulka neobsahuje informaci o objednávce, musíme do dotazu zapojit i tabulku Adresa objednatele; l požadujeme získat všechny atributy adresy; l požadujeme získat pouze takovou adresu, pro kterou platí, že patøí k objednávce s uvedeným èíslem a zároveò to má být adresa dodací. l

Formulace dotazu: SELECT Adresa.* FROM Adresa, Adresa objednatele WHERE Adresa objednatele.ID adresy=Adresa.ID adresy AND Adresa objednatele.Èíslo objednávky=12345 AND Typ adresy=“Dodací“ Výsledek: Id adresy

Adresa1

Adresa2

Mìsto

PSÈ

1

Jan Novák

Pod návsí 15

Praha 5

15000

Pøíkazy pro definici struktury databáze Do této skupiny patøí pøedevším následující pøíkazy: l l l

CREATE – umožní vytváøet v databázi nový objekt, napø. tabulku, vazbu mezi tabulkami apod.; ALTER – umožní mìnit objekty databáze, tedy strukturu databáze, její schéma; DROP – umožní zrušit objekty v databázi, tj. mìní strukturu databáze, její schéma.

Pøíkazy pro øízení dat Do této skupiny patøí pøedevším následující pøíkazy: l l l l l

74

GRANT – umožní pøiøadit definovanému uživateli databáze pøístupová práva k datùm èi funkcím; REVOKE – umožní odebrat definovanému uživateli pøístupová práva; BEGIN – umožní definovat zaèátek transakce; COMMIT – umožní definovat potvrzení transakce; ROLLBACK – umožní v pøípadì, že bìhem transakce došlo k chybì, návrat databáze do stavu pøed zahájením transakce.


3

Pøíkazy jazyka SQL zaèleòují implementátoøi do aplikací, ale mohou je využít i koncoví uživatelé. Protože se u nich nepøedpokládá detailní znalost syntaxe a sémantiky jazyka, výrobci databázových systémù doplòují systém o aplikaci, která umožní uživatelùm pomocí grafického rozhraní v zásadì intuitivnì zadávat dotazy a získávat výsledky. Takové prostøedky se oznaèují pojmem Query by Example (QBE). Obr. 3.10 znázoròuje použití QBE v prostøedí MS Access. Prostøedky QBE jsou pak souèástí nástrojù pro vytváøení výstupních sestav apod.

Obr. 3.10 Pøíklad použití QBE v prostøedí MS Access

3.3.3 Kategorie relaèních databázových systémù Již velmi brzy si výrobci databázových systémù uvìdomili, že zvolený pøístup k uložení dat je vhodný nejen pro rozsáhlou datovou základnu na úrovni organizace, ale že by tìchto principù bylo možno použít i v rovinì osobní informatiky. Vedle robustních systémù, jako jsou napø. multiplatformní databázové servery Oracle od stejnojmenné firmy, DB2 spoleènosti IBM, MS SQL Server spoleènosti Microsoft, MySQL a PostgreSQL jako open source projekty apod., vznikají systémy orientované na osobní potøebu jednotlivcù, pracovních skupin èi malých organizací, nebo systémy orientované na øešení jen vybraného subsystému. Takové databázové systémy se oznaèují jako osobní databáze a mezi pøedstavitele patøí pøedevším MS Access, pøípadnì i systémy dBase, FoxPro nebo Paradox). V zásadì je vùèi uživatelùm nebo programùm jejich funkcionalita totožná. Odlišnosti spoèívají pøedevším v mechanismech optimalizace zpracování požadavkù u velkých objemù dat, v rozsahu zajištìní dat pøi øešení nestandardních situací, v mechanismech zajištìní distribuce dat napøíè výpoèetní platformou atd.

3.3.4 Rozvoj relaèních databází Relaèní databáze jako dominantní pøedstavitel uložení dat se dále rozvíjejí tak, aby zajišťovaly vlastnosti spojené s potøebou: l l l

distribuce dat, uložení objektù a dokumentù XML, sledovat data i z jiných pohledù.


75

3

Distribuované databáze Pøedstava takové databáze spoèívá v tom, že požadujeme, aby data byla podle definovaných pravidel rozmístìna na více uzlù (poèítaèù) systému a zároveò, aby toto rozmístìní bylo programu (èi uživateli) transparentní, tj. aby se databáze jevila jako jeden celek a zároveò aby jednotlivé „ostrovy“ dat byly autonomní, tj. na ostatních nezávislé. V oblasti distribuovaných databází se setkáváme s pojmy fragmentace a replikace. V pøípadì fragmentace je snahou rozdìlit databázi do dílèích èástí (fragmentù), které se dle požadavkù rozmísťují na více uzlù. Pøitom se dbá na to, aby rozdìlení bylo disjunktní. Rozlišuje se fragmentace horizontální a vertikální. Horizontální fragmentaci si lze pøedstavit tak, že dochází k vodorovným øezùm v rámci tabulky a fragment obsahuje všechny atributy, ale pouze vybrané øádky, pøièemž výbìr je dán zvoleným pravidlem (predikátem). U vertikální fragmentace je øez veden svisle, tj. fragment je projekcí a obsahuje pouze vybrané atributy a vždy primární klíè a všechny øádky. Obr. 3.11 znázoròuje hypotetický pøíklad, kdyby tabulka Adresa byla doplnìna ještì o atribut Poboèka, pøièemž její hodnoty by mohly být Praha nebo Brno. Predikátem pro horizontální fragmentaci by byla právì tato položka a cílem horizontální fragmentace je zajištìní, aby objednávky zákazníkù byly dostupné lokálnì na poboèkách, tj. v Praze a v Brnì. Tabulka: Adresa Adresa1

Adresa2

Mìsto

PSÈ

Poboèka

1

Jan Novák

Pod návsí 15

Praha 5

150 00

Praha

ID adresy

2

Petr Honza

Na pøíkladì 1

Beroun

266 01

Praha

3

Jaroslav Nový

Kvìtná 1314

Uherský Brod

688 01

Brno

5

Alena Suchá

Topolová 1

Nový Jièín

741 01

Brno

6

Petr Slabý

Jasná 5

Davle

252 06

Praha

Fragment tabulky: Adresa (s predikátem Poboèka = "Praha") Adresa1

Adresa2

Mìsto

PSÈ

Poboèka

1

Jan Novák

Pod návsí 15

Praha 5

150 00

Praha

2

Petr Honza

Na pøíkladì 1

Beroun

266 01

Praha

6

Petr Slabý

Jasná 5

Davle

252 06

Praha

ID adresy

Fragment tabulky: Adresa (s predikátem Poboèka = "Brno") Adresa1

Adresa2

Mìsto

PSÈ

Poboèka

3

Jaroslav Nový

Kvìtná 1314

Uherský Brod

688 01

Brno

5

Alena Suchá

Topolová 1

Nový Jièín

741 01

Brno

ID adresy

Obr. 3.11 Pøíklad horizontální fragmentace V pøípadì replikace je zvolená množina dat, tj. celé tabulky, duplikována (replikována) na více uzlù.

76


3

Objekty, XML a databáze Pokud jsme hovoøili o objektech (a objektovì orientovaném programování), pak výrobci databází jako úložišť dat reagují na tuto skuteènost rùznì. V pøípadì relaèní databáze zpravidla dochází k jejímu rozšíøení o podporu ukládání objektù a práci s nimi. Znamená to, že databáze je rozšíøena o nový datový typ – objekt, pøièemž dochází u tohoto typu ke zmìnì pohledu na tvorbu vztahù mezi objekty. Místo relací využívajících klíèù, se používají odkazy (pointry). Pøedstaviteli jsou napø. databáze ORACLE, Informix, DB2. Databázové systémy tohoto typu jsou oznaèovány jako objektovì relaèní, což znamená, že využívají relaèní uložení dat, pøièemž jedním z typù dat je objekt.

2

Požadavek: Naším úkolem je vytvoøit tabulku Zboží, která bude objektem. Formulace pøíkazù (zjednodušenì): CREATE TYPE Zboží_o AS OBJECT ( ID zboží INT, Název VARCHAR(25) NOT NULL, Výkon INT, Závit VARCHAR(4) NOT NULL, Jednotková cena INT ) CREATE TABLE Zboží OF Zboží_o

Jiným pøístupem je zcela nový model databáze – tzv. objektový model definovaný standardem ODMG-V2 v rámci sdružení Object Management Group (OMG). Ten plnì podporuje vlastnosti objektového pøístupu. Pøedstaviteli jsou napø. Jasmina Object Database (Computer Associates International), Cache (Intersystems Corporation) nebo db4o (db4object). Dalším fenoménem je otázka ukládání dat strukturovaných jako XML dokumenty (viz dále). Opìt zde existuje možnost využít stávající relaèní databáze. Jedná se však vìtšinou o pøístup obtížný, protože XML dokument má hierarchickou strukturu (je stromem) na rozdíl od relaèních databází, kde se využívá tabulek. Pøedstavitelem databáze s takovou možností je napø. ORACLE. Druhým smìrem rozvoje jsou tzv. XML databáze (nìkdy oznaèované jako nativní XML databáze). Pro tyto databáze mimo jiné platí, že XML dokument pøedstavuje základní jednotku logické struktury, stejnì jako øádek v tabulce relaèní databáze. Vlastnosti takových databází jsou definovány v rámci XML:DB Initiative for XML Databases. Pøedstavitelem takové databáze je napø. NeoCore® XMS XML database (Xpriori, LLC).

Multidimenzionální databáze Multidimenzionální databáze pøedstavují specifické uspoøádání a uložení dat orientované na analytické a plánovací funkce podniku (viz kapitola 9).

3.4 XML, eXtensible Markup Language Jistì si lze pøedstavit, že pokud bychom potøebovali nìkomu pøedat (osobì èi jinému programu) data uložená v nìjaké konkrétní databázi, pak by tento subjekt musel disponovat pøíslušným programem, který jí bude rozumìt. A pøedevším z dùvodu snadného pøenosu dat mezi rùznými systémy a aplikacemi, které mohou být implemento-


77

3

vány v rùzných prostøedích, se do popøedí opìt dostává bìžný textový soubor, respektive data v takovém souboru uložená. Samozøejmì, pokud by šlo pouze o textový soubor, pak bychom zde naráželi na problém spojený s urèením, o jaká data jde, jaký mají význam, jakých hodnot mohou nabýt apod. Pro øešení tìchto problémù bylo využito principu znaèkování dat v souboru, napø. <jmeno>Jan Novák, kde <jmeno> je startovací znaèkou a øíká, že zde dané vyznaèení dat konèí. Východiskem pro použití znaèkování je SGML (Standard Generalized Markup Language), známý i jako standard ISO 8879. Byl publikován v roce 1986 jako prostøedek pro definování univerzálního formátu výmìny informací. Životaschopnost principu znaèkování se projevila v souvislosti se službou World Wide Web, respektive s použitím jazyka HTML (HyperText Markup Language), kterým jsme schopni popsat datovou strukturu tak, že je zobrazitelná v rùzném prostøedí (rùzným prohlížeèem) a prohlížeè této struktuøe rozumí. Ovìøený princip se pak stal základem dalšího rozvoje, který je reprezentován jazykem XML (eXtensible Markup Language) a jeho rùznými aplikacemi.

3.4.1 Principy XML a jádro XML XML je znaèkovacím jazykem a lze ho oznaèit za „generický“, což znamená, že poskytuje instrukce, které pouze popisují obsah dokumentu. Tím, že se detailnì zamìøuje na strukturu obsahu, umožòuje, aby si vzdálené systémy vymìòovaly a interpretovaly takové dokumenty bez lidského zásahu.

`

XML je znaèkovací jazyk, jehož aplikací na textové soubory vznikají jednotlivé XML dokumenty. Vlastní specifikace jazyka uvádí zpùsob zápisu struktury dokumentu, mechanismus vytváøení logických struktur v dokumentu, pravidla deklarace elementù a vlastností apod.

Pro XML byly definovány následující principy (Mlýnková a další, 2008): l l

l l

l

l

formát XML musí být použitelný v rámci internetu, tj. je otevøený a použitelný kýmkoli; formát XML by mìl podporovat širokou škálu aplikací, tj. mìlo by ho být možné použít v rùzných aplikaèních oblastech (základní pøehled uvádíme v pøíloze 4); formát XML musí být kompatibilní s formátem SGML, ze kterého vychází; musí být snadné vytváøet programy, které manipulují s dokumenty v XML, to je již dnes ovìøené øadou funkèních aplikací (napø. XML se používá v oblasti konfiguraèních souborù aplikací, v souvislosti s integrací služeb apod.); množství variant XML by mìlo být minimální, tj. neuvažují se žádné dialekty jazyka, které by omezovaly jejich vzájemnou sluèitelnost; XML dokumenty by mìly být èitelné a pochopitelné i pro èlovìka (tuto skuteènost si ukážeme v dalších pøíkladech).

XML dokument se z logického pohledu skládá z prologu, deklarací, elementù, komentáøù a pøípadnì instrukcí pro zpracování jinými aplikacemi. Obr. 3.12 Znázoròuje jednoduchý dokument. Prolog je uveden na øádku 1 a definuje vedle verze jazyka XML i kódování znakù dokumentu. Na øádku 4 je uveden element dokumentu, který je tvoøen startovací a koncovou znaèkou ( a ) a obsahem (Volta 75). Tento element je obsahem jiného elementu, který zaèíná na øádku 3 a konèí øádkem 8. Element zaèínající øádkem 3 obsahuje rozšiøující informaci v podobì zápisu atributu elementu. V tomto pøípadì je atributem id-zbozi a jako hodnota je uvedena hodnota 1. Každý dokument má pouze

78


3

jeden element, tzv. koøen a ostatní elementy jsou jeho obsahem. Koøen v našem pøípadì tvoøí element se znaèkou zbozi. Samotný XML a XML dokument pro zpracování nestaèí, a proto byl XML doplnìn o základní øadu specifikací, tvoøící jádro XML, nebo základní rodinu XML standardù (specifikací). Obr. 3.13 ukazuje základní vazby mezi specifikacemi. 1. < ?xml version = "1.0"encodi ng = " UT F-8" ?> 2. < zbozi> 3. 4. V ol ta 75 5. 75 6. < zavi t>E27 7. < j ednot k ov ac ena>10 8. 9. 10. Volta 100 11. < vykon> 100 12. < zavit >E27 13. < j ednotkovacena>7< / j ednotkovacena > 14. 15.

Obr. 3.12 Jednoduchý XML dokument obsahující data o zboží XSLT (Extensible Stylesheet Language Transformation)

DTD

transformuje

(Document Type Definition)

využívá popisuje XML dokumenty

vyhledává XPath

vytlaèuje popisuje

vyhledává

využívá

využívá XQuery

XSD (XML Schema Definition Language)

využívá

Obr. 3.13 Základní rodina XML standardù Jedná se o specifikace jazykù pro: l

Definici slovníkù (datových schémat) pro XML dokumenty, kterými popisujeme, jaké elementy jsou pøípustné, jaký je vztah mezi elementy, jaký je pøípustný obsah elementù, zda element má rozšiøující atributy a jakých hodnot mohou atributy nabýt. DTD (Document Type Definition) se orientuje na jednodušší datové struktury. XSD (XML Schema Definition) pøedstavuje robustní prostøedek pro popis složitých datových struktur, vèetnì možnosti precizního definování datových typù, závislostí mezi daty apod.


79

3

l

l

Popis zpùsobu transformace XML dokumentu z jednoho datového schématu do jiného. Do této skupiny patøí XSL (eXtensible Stylesheet Language) jako obecný jazyk, pøièemž pravidla transformace se popisují jazykem XSLT (eXtensible Stylesheet Language Transformation). XSL-FO (XSL Formating Object) se orientuje na popis formátování dat jako objektù pro konkrétní výstupní zaøízení. Vyhledávání a výbìr informací z XML dokumentù, kam patøí jazyky XPath a XQuery.

K dalším standardùm patøí ještì: l

l

l

l

vyjádøení odkazù mezi XML dokumenty, pøípadnì mezi èástmi dokumentu (jazyk XPointer), a vytváøení vhodných vztahù mezi odkazovanými èástmi (jazyk Xlink), vèetnì zajištìní možnosti, aby z jednoho odkazu vedlo nìkolik cest k rùzným dokumentùm; jmenné prostory XML (XML namespaces) umožòují kombinovat datová schémata obsahující shodné názvy znaèek a atributù a zároveò odlišit, zda daný obsah prezentuje data dle schématu X nebo napø. Y; významová množina XML (XML Infoset) pøedstavuje abstraktní model XML dokumentu obsahující definované informaèní položky a pro nì definované vlastnosti, které jsou využívány pøi dotazování; standardy pro identifikaci zdroje (URI, služba WWW).

3.4.2 Zpracování XML dokumentù XML dokument sám o sobì pøíliš neposlouží. Vìtšinou bude tøeba získat z nìj vyznaèená data a hodnoty atributù a ty použít ve vybrané aplikaci (aplikaèním software), modifikovat strukturu XML dokumentu apod. Aby to bylo možné, dokument se musí pøeèíst a interpretovat v procesu oznaèovaném jako parsing, který realizuje XML procesor (parser). Zpracování XML dokumentu zahrnuje tøi základní bloky. Na jedné stranì jsou XML dokumenty, které se budou zpracovávat, na opaèné stranì je aplikace, pro kterou bude XML dokument vstupem a pøípadnì výstupem. Mezi nimi je tøetí blok, pøipravující XML dokumenty pro danou aplikaci, tedy parser. Mezi parserem a aplikací je aplikaèní programové rozhraní (API – Application Program Interface), které zajišťuje korektní pøedání dat z parseru do aplikace. Celý postup dokumentuje schéma na obr. 3.14. Pøedání pøedpøipraveného dokumentu aplikací pøes API rozhraní

Naètení dokumentu

XML Dokument

Vrácení upraveného dokumentu v textové podobì

Parser (naètení, formální kontrola, dekompozice a pøíprava XML dokumentu pro zpracování aplikací)

Aplikace pracující s XML dokumentem

Dokument zpracovaný aplikací se vrací do databáze dokumentù, buï pøímo, nebo pøes parser a API

Obr. 3.14 Princip fungování parseru

80


Podniková informatika

Recommend Documents