1

Informatika 2 – aplikační oblast

1 Datové modely, okruh II, otázka č. 1

Při vytváření informačních systémů zpravidla nevystačíme s jedinou strukturou věty. Protože

všechny informace nemůžeme dát do jedné tabulky, vznikl by chaos, špatná vypovídací

schopnost, proto se informace dávají do tabulek – databází různých modelů. Pro každý typ

datového objektu, potřebujeme samostatnou datovou strukturu věty. Máme 5 typů datových

modelů:

Lineární

Hierarchický

Síťový

Relační

Objektový

Budeme-li budovat jednoduchý IS posluchačů vysoké školy, potřebujeme navrhnout datové

struktury přinejmenším pro objekt student, zkouška, předmět, učitel.

Lineární datový model

Každý obdélník představuje jeden soubor s větami o příslušných objektech v pevné struktuře.

V lineárních datových modelech není žádná vazba mezi jednotlivými skupinami objektů –

tabulkami, s výjimkou vztahu „předchůdce“ a „následovníka“. Nemůžeme tedy nijak přímo

stanovit, který student složil zkoušku a z jakého předmětu. Příklad lineárního modelu je

například kartotéka pacientů. Každá karta představuje jednu větu databázového souboru.

Zkouška Student

Předmět Učitel

2

Hierarchický datový model

Tento model je tvořen rodičovským segmentem (větou), ze které vedou vazby na jemu

podřízené segmenty (děti) – což jsou segmenty (věty) jiné struktury a obsahu. Jestliže

rodičovský segment nahoře bude představovat například větu s údaji o studentovi, potom

obsahuje podřízené segmenty o jeho uskutečněných zkouškách Vazby na jednotlivé segmenty

jsou vedeny tzv. pointery (ukazateli), které vytváří databázový systém na kterém je model

implementován.

Výhody: rychlost vyhledávání požadovaných údajů, přehlednost

Nevýhody: delší doba nutná reorganizaci databázových souborů při vkládání nebo rušení

segmentů, složitost rekonstrukce dat při poškození databáze

Síťový model

Tento model je obdobou hierarchického, pointery však vedou mezi segmenty databáze

v různých směrech. Již nehovoříme o rodičích a dětech, ale pouze o segmentech. Šipky

v schématu naznačují, kudy jsou mezi segmenty vedeny vazby.

Výhody: viz. hierarchický model + libovolné propojený segmentů, rychlý přístup k datům

Nevýhody: viz. hierarchický model

Hierarchický i síťový model se na počítačích řady PC prakticky nepoužívá.

Student Učitel

Zkouška Předmět

Student Učitel

Zkouška Předmět

3

Relační datový model

Patří k nepoužívanějším datovým modelům. Vzniká z několika lineárních modelů spojených

dohromady pomocí položky (položek), kterým říkáme relační klíč. Toto spojení není trvalé,

ale vzniká v okamžiku, kdy potřebujeme mít společně k dispozici data ze všech spojených

tabulek a zaniká, když práci s modelem ukončíme.

Objektový datový model

Jedná se o nejnovější datový model. Objektové datové modely jsou vystavěny na základním

prvku – objektu (odpovídá přibližně pojmu věta), kde tento objekt má kromě svých atributů i

definované metody, které určují chování objektu.

Tento objekt zkouška může mít definovány své metody, např. metodu „vytvoř záznam o

zkoušce“, kde se zkontroluje, zda daný posluchač nemá již tuto zkoušku hotovou či nemá

vyčerpané termíny.

Každý objekt v databázi má přidělen svůj unikátní identifikátor – OID, pomocí kterého

můžeme mezi objekty vést přímé vazby obdobně jako v síťovém modelu. Kromě toho

v objektovém modelu mohou existovat i relační vazby.

Student Učitel

Zkouška Předmět

Student Učitel

Zkouška Předmět

4

2 Relační datový model

Relační model byl popsán v roce 1970. Jedná se o model dat, který nám umožňuje zachytit

nejenom data o zkoumaných objektech, ale také vzájemné vztahy těchto objektů, což dává

možnost přiblížit se více reálnému světu. Formou reprezentace relací může být dvojrozměrná

tabulka.

Základní pojmy:

Doména - je množina datových hodnot stejného typu. Tyto hodnoty popisují nějakou

vlastnost objektu (např. doména názvů států).

Relace - je množina vztahů mezi jednotlivými prvky domén

Atribut - je pojmenování pro každé užití hodnoty z domény v relaci

Záhlaví relace - obsahuje jméno relace a jména atributů v relaci. Je v čase neměnné.

Tělo relace - obsahuje v čase proměnnou množinu n-tic hodnot, jejichž pořadí je dáno

záhlavím relace.

Stupeň relace - je počet atributů relace (počet sloupců v tabulce)

Kardinalita relace - je počet řádků relace

Tabulky - jsou konktrétními instancemi relačního schématu

Primární klíč - je sloupec, který jednoznačně určuje řádky v tabulce. Pokud je třeba

použít více sloupců pro jednoznačné určení řádků, potom hovoříme o tzv. složeném klíči.

Pokud je více atributů, které splňují pravidlo pro primární klíč, jeden zvolíme jako

primární. Ostatní jsou alternativní klíče.

Definice primárního klíče:

Primární klíč je podmnožina atributů relace, která:

1) jednoznačně identifikuje každý prvek relace

2) není redundantní, tj. žádný její atribut nelze vynechat, aniž by podmínka 1) přestala platit

Podmínky, které musí splňovat relační tabulka:

všechny hodnoty v tabulce musí být elementární - tzn. dále nedělitelné - podmínka

1.NF

5

sloupce mohou být v libovolném pořadí

řádky mohou být v libovolném pořadí

sloupce musí být homogenní = ve sloupci musí být údaje stejného typu

každému sloupci musí být přiřazeno jednoznačné jméno (tzv. atribut)

žádné dva atributy (názvy sloupců) nejsou stejné

v relační tabulce nesmí být dva zcela stejné řádky, každý řádek je jednoznačně

rozlišitelný

Příklad:

ZAMESTNANEC

ID jméno funkce plat

12 Čáp Ladislav ředitel 34000

27 Holub Stanislav asistent 23000

39 Kos Zbyněk asistent 13000

43 Orel David účetní 24000

...

Jméno relačního schématu: ZAMESTNANEC

Jména atributů: ID,jméno,funkce,plat

Domény: D1 je množina řetězců tvaru Un, kde n je přirozené číslo; prvky množiny jsou

osobní čísla zaměstnanců, D2 je množina možných jmen učitelů; D3 množina textů

označujících funkční zařazení zaměstnanců; D4 množina nezáporných celých čísel

vyjadřující plat zaměstnanců

Zobrazení: f(ČU)=D1, f(jméno)=D2, ...

Relační schéma: ZAMESTNANEC (ID,jméno,funkce,plat)

Kartézský součin domén: D1 x D2 x D3 x D4 je množina všech možných čtveřic

takových, že první prvek čtveřice je hodnota z D1, …, poslední je hodnota z D4.

Relace:

ZAMESTANANEC={(12,Čáp Ladislav,ředitel,34000),(U27,Holub Stanislav,asistent,23000),

(U39,Kos Zbyněk,asistent,13000),(U43,Orel David,účetní,24000), …}

přičemž do relace patří jen ty čtveřice, které odpovídají skutečným hodnotám 4 atributů

odpovídajících evidovaným zaměstnancům.

6

Realizace vazeb v relačním modelu

Charakteristickou vlastností relačního modelu je realizace vazeb mezi relacemi pomocí

relace (1:1, 1:N, N:M). V ní každou entitu do vazby vstupující zastupuje její primární klíč.

V některých případech (vazby 1:1, 1:N) však není nutné použít samostatnou vazební

tabulku, ale stačí doplnění tabulky na straně N o další atribut - cizí klíč.

Relační algebra

je nástrojem pro manipulaci relací. Je to jazyk, který pracuje s celými relacemi. Operátory

relační algebry se aplikují na relace a výsledkem jsou opět relace.

Základní operace relační algebry

- projekce - umožňuje potlačit označené atributy v relaci.

- selekce - operací selekce vznikne nová relace odstraněním nepotřebných řádků na

základě logické podmínky

- spojení - spojení dvou relací vytvoří třetí relaci. Výsledná relace vždy obsahuje všechny

kombinace, které vyhovují zadané podmínce. Podmínka vyjadřuje vztah mezi dvěma

relacemi. Relace se nespojují podle názvů atributů, ale podle jejich hodnot.

Výhody relačního modelu:

Existence formálního matematického aparátu, který napomohl ve srovnání se síťovými

databázemi k velkému zjednodušení práce s daty pomocí relační rozhraní SŘDB na

logické úrovni

Více méně existující a používaný standard, kterým je jazyk SQL, jenž slouží k definici

nejrůznějších rozhraní mezi různými softwarovými aplikacemi

Všeobecná znalost práce uživatelů s relačními databázemi včetně uspokojivých

teoretických znalostí

Dlouhodobé praktické zkušenosti s relačním SŘDB mají důsledek ve velmi slušné

programové kvalitě většiny relačních SŘDB, které se projevuje v úspěšných

technikách transakčního řízení, indexování a používání cache pro urychlení databáze

apod.

Nevýhody relačního datového modelu,

které jsou však známy vlivem svého návrhu již od samého počátku:

Nízká výkonnost systému při manipulaci se složitými datovými strukturami, které

nelze transformovat do záznamů jedné tabulky, a které je třeba rozkládat a skládat do

více mezi sebou propojených tabulek

7

Relační datový model vyžaduje předpoklad, že databáze je normalizovaná minimálně

do první normální formy, (ve většině praktických příkladů do 3NF) aby se eliminovalo

nebezpečí redundancí a nekonzistencí v databázi

Relační datový model dovoluje implementovat pouze množiny (jak tabulky) složené

z prvků jednoho datového typu (který je vymezený doménami příslušné tabulky)

Relační datový model není hierarchický, takže databáze je tvořena jen jedním

seznamem tabulek

8

3 Integritní omezení v relačním datovém modelu

Kardinalita relačních vazeb a vazba N:M

Normalizace dat

Integritní omezení v relačním datovém modelu

Integrita modelu

Je to stav, při kterém data uložená v modelu odpovídají vlastnostem objektů reálného světa.

Integritní omezení relačního modelu se dělí na:

Integritní omezení pro entity (relace)

Integritní omezení pro vztahy entit (relační vazby)

Integritní omezení pro entity

a) Doménová kritéria

b) Entitní integrita

c) Referenční integrita

Doménová integrita (integrita hodnot)

Každá hodnota každého z atributů relace (položky věty) musí být z množiny hodnot (domény)

pro daný atribut přípustných:

1) definice domény jako množiny hodnot (může být využito více atributy)

2) specifikace povolených hodnot pro daný atribut (položku věty)

typ pole (datový typ)

povinné zadání položky, neprázdná hodnota

jedinečnost hodnot v rámci sloupce

rozsah hodnot – minimální, maximální hodnota

implicitní (standardní) hodnota

maska pro vkládání

seznam přípustných hodnot (číselník)

Entitní integrita

Každá relace musí mít určen tzv. primární klíč – jeden nebo více atributů, jejichž hodnoty

jednoznačně identifikují každý z řádků relace.

Primární klíč (primary key) – je množina atributů relace, která má tyto vlastnosti:

9

1) je jednoznačná, tzn. v relaci neexistuje druhá n-tice (věta tabulky), která by pro

tuto množinu atributů měla stejné hodnoty

2) je minimální, tzn. žádný atribut není možné vypustit, aniž by se porušilo pravidlo

1 (žádná z jejích podmnožin nemá tuto vlastnost)

Primární klíč je základním prostředkem adresace n-tic relace a platí zde tato pravidla:

U každého atributu primárního klíče nesmí chybět hodnota (doména)

Každá n-tice relace musí být v každém okamžiku identifikovatelná hodnotou

primárního klíče

Kandidátní klíč (Candidate key) je totéž jako primární klíč, se stejnými vlastnostmi, ale není

vybrán jako primární klíč. V relaci může být více kandidátních klíčů, jeden z nich je vybrán

jako primární klíč, ostatní kandidátní klíče se nazývají alternativní.

Způsob výběru primárního klíče není předepsán, záleží na volbě analytika.

Referenční integrita

Cizí klíč (Foreign key) je atribut, který splňuje tyto nezávislé vlastnosti:

1) každá hodnota je buď plně zadaná nebo plně nezadaná

2) existuje jiná relace s takovým primárním klíčem, že každá zadaná hodnota cizího klíče

je identická s hodnotou primárního klíče nějaké n-tice této jiné relace

Cizí klíč nám tedy společně s primárním klíčem jiné tabulky umožňuje vytvářet spojení mezi

relacemi, což je hlavní účel relačního datového modelu. Platí zde pravidla referenční

integrity:

cizí a odpovídající primární klíč musí být identifikovány na stejné doméně

(soulad hodnot)

databáze nesmí obsahovat žádnou nesouhlasnou hodnotu cizího klíče

Integritní omezení pro vztahy

Integritní omezení pro vztahy omezuje kardinalitu vztahu na poměry 1:1, 1:N, N:1, N:M.

Tento poměr uvádí, kolik n-tic relací sobě navzájem odpovídá.

Vztah 1 : 1

10

Vztah 1 : N

Vztah N : M

Kardinalita vztahu

Jak určit kardinalitu vztahu?

Firma

Zaměstnanec m

N 1

JEDNA firma má kolik

zaměstnanců? N

JEDEN zaměstnanec

pracuje pro kolik firem?

1

11

člověk VlastníŘidičský

průkaz

Vztah 1 : 1

Vztahy si můžeme přiblížit na příkladech. Vztah 1 : 1 nám říká, že vždy jedné n-tici relace

(větě) odpovídá jedna (nebo žádná) n-tice jiné relace. Příkladem může být vztah mezi

datovými objekty „člověk“ a „řidičský průkaz“. Jeden člověk může mít jeden nebo žádný

řidičský průkaz.

1 1

VránaJiří810712/4521

NovákJan821010/1021

PříjmeníJménoRodné číslo

VránaJiří810712/4521

NovákJan821010/1021

PříjmeníJménoRodné číslo

TFT15.7.2000810712/4521201VV421

FTT10.2.1995821010/1021100AB275

TraktorMotocyklAutomobilDatum vydáníRodné čísloČíslo průkazu

TFT15.7.2000810712/4521201VV421

FTT10.2.1995821010/1021100AB275

TraktorMotocyklAutomobilDatum vydáníRodné čísloČíslo průkazu

12

Student Skládá Zkouška

Jiří

Jan

Jméno

Vrabec

Novák

Příjmení

101

100

Číslo studenta

Jiří

Jan

Jméno

Vrabec

Novák

Příjmení

101

100

Číslo studenta

4215.1.20051004/051000100

1

Termín

11.1.2005

Datum

zkoušky

4

Známka

04/05

Školní

rok

10

Číslo

učitele

1000

Číslo

předmětu

100

Číslo

studenta

4215.1.20051004/051000100

1

Termín

11.1.2005

Datum

zkoušky

4

Známka

04/05

Školní

rok

10

Číslo

učitele

1000

Číslo

předmětu

100

Číslo

studenta

Student Studuje Předmět

Jiří

Jan

Jméno

Vrabec

Novák

Příjmení

101

100

Číslo studenta

Jiří

Jan

Jméno

Vrabec

Novák

Příjmení

101

100

Číslo studenta

Vztah 1 : N

Vztah 1 : N nám říká, že vždy jedné n-tici relace (větě) odpovídá jedna nebo více n-tic jiné

relace. Příkladem může být vztah mezi entitami „student“ a „zkouška“. Jeden student může

vykonat (a obvykle vykoná) více zkoušek. jedna konkrétní zkouška přísluší jednomu

konkrétnímu studentovi. Vztah N : 1 je totéž, pouze se na něj díváme z opačné strany.

1 N

Vztah N : M

Vztah N : M nám říká, že obecně několika n-ticím relace odpovídá jedna nebo více n-tic jiné

relace. Příkladem může být vztah mezi entitami „student“ a „předmět“. Jeden student si

vybere více předmětů, ale jeden předmět navštěvuje také více studentů.

N M

13

Matematika

Algoritmizace

Název

1100

1000

Číslo předmětu

Matematika

Algoritmizace

Název

1100

1000

Číslo předmětu

Student

Předmět

Zapsané

předměty

se

vyu

čuje

se

vyu

čuje

N N

1 1

ře

N M se

vyuč

N M

Zde můžeme bez potíží stanovit kandidátní klíče v obou tabulkách, vybrat z nich klíč

primární, ale zjistíme, že logika vazby N : M nám neumožňuje vést vazbu mezi oběma

entitami. Vidíme, že řešení vazby N : M není možné pouze na těchto dvou entitách, neboť

minimální kandidátní klíč k zachycení vztahu studentů a zapsaných předmětů je:

číslo studenta + číslo předmětu

Řešení vazby N : M spočívá ve vytvoření nové entity – v našem případě „zapsané předměty

studenta“ s primárním klíčem složeným z obou primárních klíčů původních entit.

Nová entita – zapsané předměty studenta – bývá nazývána průniková entita.

14

Kardinalita relačních vazeb a vazba N:M

Integritní omezení pro vztahy omezuje kardinalitu vztahu na poměry 1:1, 1:N, N:1, N:M.

Tento poměr uvádí, kolik n-tic relací sobě navzájem odpovídá.

Vztah 1:1 – každá jedna n-tice relace odpovídá jedné (nebo žádné) n-tici jiné relace.

Vztah 1:N – každá jedna n-tice relace odpovídá jedné nebo více n-ticím jiné relace.

Vztah N:M – několik n-tic relace odpovídá jedné nebo více n-ticím jiné relace. V praxi se

tento vztah aplikuje pomocí spojovací tabulky, tzn. vztah N:M se rozloží na dva vztahy N:1

15

Normalizace dat

Klíčová slova: normalizace dat, optimalizace, normalizační forma, normalizační formule,

redundance, integrita, konzistence

NORMALIZACE DAT

Normalizace dat je činnost, při které upravujeme návrhy datových struktur tak, aby splňovaly

zvolené normalizační formy - úrovně. Tyto normalizační formy či pravidla vycházejí z

požadavku na efektivní ukládání dat a minimalizují redundance při zachování integrity a

konsistence dat. Datový model který porušuje některou z normalizačních forem není navržený

optimálně. Při normalizaci databáze na vyšší normalizační úrovni musí být normalizován na

všech předcházejících.

NORMALIZAČNÍ FORMY

1. normalizační forma - (multizávislost) věta obsahuje položky, které se neopakují.

2. normalizační forma - (funkční závislost) položky věty, které nejsou relačním klíčem jsou

významově plně závislé na těchto klíčových položkách.

3. normalizační forma - problém tzv. tranzitivní závislosti. Položka, která není klíčová nesmí

být závislá na jiné neklíčové položce.

Normalizaci dat si můžeme ukázat na následujících příkladech:

Máme za úkol navrhnout datový model evidenci osobních dat pro potřeby podniku. Nejprve si

stanovíme položky, které chceme o osobách sledovat a z nich sestavíme tabulku.

Osoba

Jméno Přijmení Adresa Telefony

Jan Novák Havlíčkova 2 Praha 3 125789654;601258987;789456123

Petr Kovář Svatoplukova 15 Brno 369852147;357951456;963852741

Pavel Pavel Papalášova 25 Kocourkov 546789123;123456789;987456123

16

1NF - Vidíme, že u jednotlivých osob máme více než jedno telefonní číslo. S takovouto

tabulkou by byla spousta problémů, například by se dost špatně prováděly změny čísel,

případně vyhledávání podle telefonního

čísla.

Aby tabulka byla v 1NF musíme buďto

rozdělit atribut telefon do více atributů

(pouze za předpokladu, že jsme si jisti, že

se množství telefonních čísel nezvýší),

nebo oddělit telefonní čísla do samostatné

tabulky, což já osobně preferuji, protože je

to podstatně flexibilnější řešení:

Navržená věta odporovala první normalizační formuli, která říká, že položky ve větě se

nesmí opakovat. V našem případě se položky Telefony opakovala třikrát. Je také dobré si

Osoba

ID Jméno Příjmení Adresa

1 Jan Novák Havlíčkova 2 Praha 3

2 Petr Kovář Svatoplukova 15 Brno

3 Pavel Pavel Papalášova 25 Kocourkov

Telefon

ID_osoby Cislo

1 125789654

1 601258987

1 789456123

2 369852147

2 357951456

2 963852741

3 546789123

3 123456789

3 987456123

17

uvědomit, že věta má vyjadřovat údaje týkající se konkrétního objektu. V naší větě jsme měli

ale objekty dva - osobu a telefon. Větu jsme převedli do první normalizační formy tak, že

jsme vyčlenili opakující se položky do nové věty a relačně ji spojili s původní.

2NF - Druhá normalizační formule nám říká, že všechny položky ve větě, které nejsou

relačním klíčem, musí záviset na relačních klíčích.

Sklad

Název Výrobce Telefon Výrobce Cena Množství

Mléčná čokoláda Milka +420123456789 30Kč 2500

Oříšková čokoláda Milka +420123456789 30Kč 2800

Tyčinka milkyway Milka +420123456789 10Kč 7000

Mléčná čokoláda Orion +420987654321 25Kč 5800

Oříšková horalka Horalka +420897654321 7Kč 4560

V našem případě máme v tabulce zboží v obchodě položky název zboží, výrobce, telefon na

výrobce, cena zboží a množství na skladě. Klíčem této relace je kombinace atributů Název a

Výrobce. Telefon výrobce ovšem není závislí na celém klíči, ale pouze na atributu výrobce.

To by vedlo k aktualizační anomálii a to k té, že pokud by se vymazaly veškeré výrobky

od výrobce Milka, ztratilo by se telefonní číslo na výrobce Milka, což není zrovna žádané.

Výrobek

Název Výrobce_ID Cena Množství

Mléčná čokoláda 1 30Kč 2500

Oříšková čokoláda 1 30Kč 2800

18

Řešením je opět rozpad na dvě tabulky:

3NF - Je-li model normalizován v druhé formě,

zkontrolujme ještě, zda je i ve třetí

normální formě. Ta nám říká, že ve větě nesmí být položky, které nejsou relačním

klíčem, závislé jedna na druhé.

Tyčinka milkyway 1 10Kč 7000

Mléčná čokoláda 2 25Kč 5800

Oříšková horalka 3 7Kč 4560

Výrobce

Vyrobce_ID Vyrobce Telefon

1 Milka +420123456789

2 Orion +420987654321

3 Horalka +420897654321

Zaměstnanec

r.č Jméno Příjmení Město PSČ Funkce Plat

1 Jack Smith Jihlava 58601 CEO 150000

2 Franta Vomáčka Praha10 10000 Senior Software Architect 80000

3 Pepa František Plzeň 10000 Senior Software Architect 80000

4 Pavel Novák Kocourkov 99999 Junior Developer 30000

5 Petr Koukal Praha10 12345 Database Designer 75000

6 Honza Novák Plzeň 12345 Junior Developer 30000

19

Prozkoumáme-li pozorně náš model, patrně nás napadne, že údaje město a poštovní

směrovací číslo na sobě jednoznačně závisí. Další závislost je mezi položkou Funkce a Plat.

Tyto položky tedy porušují třetí normální formu.

Řešením problému je opět rozpad na více relací, v tomto případě dokonce na 3, protože jsme

3.NF porušily rovnou dvakrát.

Zaměstnanec

r.č Jméno Příjmení Město_ID Funkce_ID

1 Jack Smith 1 1

2 Franta Vomáčka 2 2

3 Pepa František 4 2

4 Pavel Novák 3 4

5 Petr Koukal 2 3

6 Honza Novák 4 4

Město

Město_ID Město PSČ

1 Jihlava 58601

2 Praha10 10000

3 Kocourkov 99999

4 Plzeň 12345

20

Normalizovat je určitě potřeba a čím

složitější databáze a čím více dat, tím více

je potřeba normalizovat. Ale i tady platí

všeho s mírou. Například u příkladu u

3.NF by firma s několika desítkami

zaměstnanců asi neměla potřebu dávat

PSČ do další tabulky a bylo by to

zbytečné. Ale v tabulce zákazníků

některého z mobilních operátorů s milióny zákazníků to už význam určitě má.

Funkce

Funkce_ID Funkce Plat

1 CEO 150000

2 Senior Software Architect 80000

3 Database Designer 75000

4 Junior Developer 30000

21

4 Slovní popis funkčního modelu IS Vývojový diagram

Slovní popis funkčního modelu IS

Klíčová slova:

Informační systém, funkční model, funkce, data, procesy, toky, DFD, transformace

Informační systém se skládá ze vstupní a výstupní části, kudy se do systému vkládají, resp.

se získávají informace (víme, že jsou to data, která interpretuje uživatel jako informace). Mezi

vstupem a výstupem probíhá transformace těchto dat. V části transformace probíhají nějaké

algoritmy, které data vhodným způsobem zpracovávají.

Jako celý tento proces si zjednodušeně můžeme představit několik případů.

Vyhledání nějakého objektu podle zadaných kriterií v databázi. Zadáme některé klíčové

vlastnosti, které IS akceptuje pro vyhledávání. V rámci transformace těchto vstupních dat se

provede selekce v databázi na základě zadaných priorit. Nalezená data se mohou dále

zpracovat, aby byl výsledný formát vhodný pro uživatele (priorita řazení nalezených objektů,

formát výstupu dat) a následně jsou data zobrazena.

Jiný případ lze hledat například v IS spravujícím účetnictví, fakturace, odběratele atd. Při

vytváření nového účetního dokladu, např. faktury, zadáme příslušné informace do systému

(datum, č. faktury, odběratele, typ skladové položky, počet kusů, způsob daňového výpočtu,

typ platby atd). V další fázi dochází ke transformaci dat. Data se ukládají do systému, vypočte

se konečná částka, DPH, popř. splátkový kalendář, a na závěr jsou data interpretována jako

hotová tisková sestava.

Funkční model zachycuje funkce systému, toky dat mezi systémem a okolím. Toky dat mezi

funkcemi systému a data ukládaná v systému. Jednotlivé funkce jsou blížeji specifikovány

pomocí minispecifikací.

Základním modelem je Data Flow Diagram (DFD)1

Diagram datových toků (DFD, Data Flow Diagram) patří k nejpoužívanějším nástrojům

strukturované analýzy informačních systémů. Zvýrazňuje funkční vlastnosti systému. Systém

1 Diagram vznikl původně v ekonomické oblasti pro analýzu toků dokumentů v organizaci.

22

zobrazuje jako síť procesů, představující místa transformace dat, zásobníků jako míst ukládání

dat - kartotéky, soubory- a externích entit, které reprezentují okolní prostředí systému. Tyto

spojujeme pomocí datových toků. Pro grafické znázorňování DFD používáme grafické

značky.

Diagram datový toků zachycuje funkce systému, které má systém nabízet. Z tohoto pohledu je

tedy podobný diagramu případu užití (Use case diagram). Oproti UCD však zachycuje také

datové sklady a taky dat mezi funkcemi a datovými sklady. DFD model je tedy mnohem blíže

návrhu.

Další vlastností je hierarchie modelu. Většinou se při modelování postupuje směrem zhora

dolu. Definuje se na nejvyšší úrovni celý (informační) systém, a jeho okolí a tento systém je

dále rozvíjen na nižších úrovních DFD.

Další definice

DFD diagramy obsahují aktéry (obdélník - například osoba, instituce, jiný systém a podobně),

datové sklady (obdélník se zaoblenými rohy bez pravé strany - uchovává data), procesy

(obdélníky se zaoblenými rohy - manipulují s daty, jsou algoritmy) a konečně datové toky

(šipky - předávání datových záznamů). DFD model je hierarchický, to znamená, že procesy se

dají postupně zjemňovat. Každý proces tedy obsahuje „vnořený“ diagram, a tak dále až po

takzvané listové procesy, které jsou atomické (nedělitelné). Každý proces v DFD obsahuje

textový popis (například pseudokód, přirozený jazyk, různé podmínky a podobně), popis

omezení (constraints) a také dodatečné informace (možnosti optimalizace atd). Dynamický

model přispívá k pochopení změn v systému.

23

Obr 1 - 1 : Příklad obecného diagramu datových toků

Vývojový diagram

Klíčová slova: Vývojový diagram, Diagram vývojový, Vývojové diagramy

Vývojový diagram je grafické znázornění nějakého algoritmu nebo procesu. Algoritmus

je přesný postup, který vede k vyřešení určitého výsledku. Vývojový diagram používá pro

znázornění jednotlivých dílčích operací grafickými symboly, které jsou navzájem

propojeny pomocí orientovaných šipek (spojnic). Vývojový diagram má nečastější použití v

informatice a programování.

Vývojový diagram sestavujeme ještě před zápisem programu nebo procesu, neboť jej

považujeme za jakýsi plán, podle kterého budeme program tvořit, nebo podle kterého budeme

postupovat. Vývojový diagram je deterministický, to znamená, že pokud programu dáme

určitá data, tak nám vrátí určitý výsledek, a pokud mu tatáž data zadáme znovu, výsledek

bude totožný s předchozím.

Vývojové diagramy se skládají z grafických značek. Značky jsou různé a různě se kombinují,

tím se simulují různé situace a různé příkazy, do těchto značek se pak vypisují upřesňující

údaje. Co se zapíše do jednotlivých značek vývojového diagramu, závisí pouze na řešiteli.

Někomu se líbí psát do značek nebo dokonce vedle nich podrobné komentáře, jiný naopak

dává přednost stručné symbolice. Nelze jednoznačně rozhodnout, co je lepší.

Spojnice jsou svislé nebo vodorovné čáry, které se mohou spojovat, ale nesmějí se křížit.

Směr postupu na spojnicích nemusíme vyznačovat šipkami v případech shora dolů nebo zleva

doprava. V ostatních případech šipky uvedeme. Proto se vývojové diagramy kreslí s hlavním

postupem shora dolů nebo zprava doleva nebo i kombinovaně.

Grafické značky vývojového diagramu :

Začátek / konec

Proces Podproces

24

Obsahuje-li náš algoritmus podmínku, na které závisí další postup,

vyznačíme ji rozhodovacím blokem. Tento znak má dva výstupy:

jeden je označen ano, druhý ne. Je jedno, zda výstup označený ano

vede směrem nahoru, napravo, dolů nebo nalevo. Totéž platí o

výstupu ne, ten také může vycházet z kteréhokoliv vrcholu

kosočtverce.

(např z klávesnice)

Proces – běžný příkaz,

přiřazení proměnné

Rozhodovací blok

Vstup / výstup dat

Ruční vstup datDokument Uložení dat

Zobrazení /

monitorCyklusUložení dat /

databáze Spojka

Uložení dat

do souboru

Zpracování souboru /

Dokumet

25

Spojka slouží v rozsáhlých vývojových diagramech ke spojení vzdálených míst. Do kroužků

dané dvojice vepíšeme shodné znaky, např. čísla , abychom zajistili vzájemnou vazbu.

Příklad vývojového diagramu: (zápis studenta na zkoušku)

Shrnutí:

Vývojový diagram je grafické znázornění nějakého algoritmu nebo procesu. Vývojový

diagram je deterministický (pro stejné vstupy – stejné výstupy).

Vývojový diagram používá pro znázornění jednotlivých dílčích operací grafickými symboly,

které jsou navzájem propojeny pomocí orientovaných šipek (spojnic). Spojnice jsou svislé

nebo vodorovné čáry, které se mohou spojovat, ale nesmějí se křížit.

Vývojové diagramy se kreslí s hlavním postupem shora dolů nebo zprava doleva.

Je termín

zkoušky?

U331

Vypsání

termínu

ne

Je volný?

Výber

termínu

zkoušky

ano

ne

U33 Termíny

Chce se

odhlásit?

ne

Byl přihlášen?

ano

ano

U333

Odhlášení

Konec

ne

D124 Zápis na

zkoušku

ano

1

1

26

5 DFD diagram Stavový diagram Základy relační

algebry

Klíčová slova:

DFD, proces, datová pamět, datový tok, terminátor, hierarchie diagramů,

minispecifikace

Úvod:

Data flow diagram je grafickou reprezentací toku dat v daném informačním systému. Každý

návrh systému byl měl začít nakreslením kontextového DFD, který jasně ukazuje jak daný

systém komunikuje s prostředím. Na nižších úrovních je pak modelován DFD tak, aby bylo

jasné jak jednotlivé součásti uvnitř systému spolu komunikují a jak si vyměnují data. Data

flow diagramy byly poprvé představeny panem Larry Constantinem, který je otcem

strukturovaného návrhu. Je to jeden ze tří základních prostředků pro modelování a analýzu

strukturovaných systémů. Data flow diagramy jsou používány především na znázornění jak

bude systém fungovat, co systém dokáže a v neposlední řadě také jak bude implementován.

Výhodou také je, že staré diagramy lze porovnávat s aktuálními a je jasně patrný směr, kterým

se systém vyvýjí. Existuje mnoho notací pro kreslení data flow diagramů. Ukážeme si jednu z

nich.

Prvky systému:

Existují 4 základní prvky systému. Jsou to:

-Procesy: procesy představují části systému, které provádějí transformaci vstupů na výstupy.

Název se volí tak, aby vystihoval podstatu funkce. Vstupy a výstupy se pojmenovávají

rozlišně, i v případě, že mají stejnou strukturu.

- Datové paměti: znázorňují uchovávaná data. Realizace paměti může být rozlišná. Může být

například v počítači na disku, nebo mimo něj na pásce, či v kartotéce. Paměti ve své podstatě

znázorňují místa, kde jsou dočasně umístěny informace, aniž by byla porušena jejich

struktura, a odkud mohou být čerpány.

Mohou být různé důvody pro jejich existenci. Mohou být vyžadovány uživatelem (data

předávaná mezi procesy, které pracují v různých časových intervalech), nebo jsou součástí

implementace (například mezivýsledky a tak podobně). Do každé paměti alespoň jeden tok

vstupuje a jeden vystupuje.

27

-Datové toky: popisuje přesun dat mezi jednotlivými komponentami systému, nebo mezi

systémem a okolím. Na rozdíl od paměti reprezentuje data v pohybu. Názvy volíme podle

typu přenášených informací.

-Terminátory: představují zdroje a příjemce dat v okolí systému. Mohou to být osoby, objekty

atd.

Terminátory musí splňovat následující vlastnosti:

Náchází se mimo modelovaný systém. Toky mezi terminátory a systémem znázorňují

jeho rozhraní.

Nelze ovlivnit chování terminátorů.

Vztahy mezi terminátory nejsou předmětem zkoumání, ale pokud jsou podstatné pro

chování systému, je nutné je zapracovat do DFD tak, že jsou nahrazeny procesy a model je

nutné přestrukturovat.

28

Hierarchie diagramů:

Popis celého systému jedním DFD je nemyslitelný. Pro lepší čitelnost se používá hierarchická

reprezentace.

Kontextový diagram:

Je na nejvyšší úrovni. Znázorňuje komunikaci s prostředím. Celý systém je znázorněn jako

jeden proces.

DFD typu 0:

Rozloží celý systém na jeho hlavní konponenty. Doporučuje se dodržovat pravidlo

sedmi, Tedy maximálně 7 subsystémů.

DFD typu 1:

Podrobnější popis každého subsystému typu 0. Jejich počet tedy závisí na počtu

subsystémů z kroku 0.

DFD typu 2:

Znázorňují jednotlivé funkce z kroku jedna. Nemělo by jich tedy být více než 49.

DFD nižších úrovní:

Pokračujeme v rozkládání do takové doby, než jsou jednotlivé procesy tak

jednoduché, že je lze popsat minispecifikací.

Minispecifikace

Popisuje logiku každé z funkcí na poslední úrovni DFD. V některých případech jsou uváděny

jako zvláštní model. Pro jednoduchost a pocjhopitelnost zákazníkem není minispecifikace

zapisována v programovacím jazyce, ale je popsána množinou slov z přirozeného jazyka.

Postup pro minispecifikaci:

Každému elementárnímu problému odpovídá jedna minispecifikace.

Popisuje postup jak jsou vstupní data transformována na výstupní.

Je nutné hlídat redundanci!

Pravidla pro tvorbu DFD:

Číslování porcesů:

Kontextový diagram bez čísel.

Procesy na úrovní 0 se očíslují a to se pak dodržuje i dále.

Počet číslic znamená úroveň rozkladu.

Názvy procesů se volí výstižně a jednoznačně.

29

Složitost jednoho DFD by neměla přesáhnou velikost A4. Dodržujeme pravidlo sedmi.

Formulace DFD by měla být jasná a přehledná pro analytika i pro uživatele.

Konzistentnost DFD – je nutné dodržet konzistentnost s ostatními modely. ER-diagram, DD

STD a podobně. Navíc je nutné kontrolovat správnost po technické stránce.

Pravidla pro datové toky:

Nesmí existovat proces jen s výstupními datovými toky.

Nesmí existovat proces jen s vstupními datovými toky.

Datové paměti mohou být propojeny jen pomocí procesu.

Datový tok do a z terminálu musí procházet přes proces.

Datový tok mezi procesy znázorňuje jen data ne volání procedur.

Datový tok se stejným názvem může být použit vícekrát, pokud jde o tentýž tok s

totožnými daty.

Pro pojmenovávání toků platí: jestliže tok z paměti přenáší celá data musí se

pojmenovat.

Přenáší-li jeden nebo více záznamů, pojmenovává se

jako pamět.

Přenáší-li pouze část záznamů, pojmenovává se jinak.

Podobná logická pravidla se užívají i u procesů a datových pamětí.

30

Stavový diagram

V této metodě zkoumáme možné stavy objektů, které mohou nastat, a snažíme se popsat, co

tyto změny přechodu mezi stavy vyvolá. U tohoto diagramu si musíme uvědomit, že jej vždy

kreslíme pro určitou entitu (objekt) a zkoumáme možné přechody jeho stavů. V elipsách jsou

zakresleny možné stavy. Šipky určují, za jaké podmínky přechází systém z jednoho stavu do

druhého, přičemž u šipek rozepisujeme příslušné podmínky.

Př.

Kardinalita relačních vazeb a vazba N:M

Integritní omezení pro vztahy omezuje kardinalitu vztahu na poměry 1:1, 1:N, N:1, N:M.

Tento poměr uvádí, kolik n-tic relací sobě navzájem odpovídá.

Vztah 1:1 – každá jedna n-tice relace odpovídá jedné (nebo žádné) n-tici jiné relace.

Vztah 1:N – každá jedna n-tice relace odpovídá jedné nebo více n-ticím jiné relace.

Vztah N:M – několik n-tic relace odpovídá jedné nebo více n-ticím jiné relace. V praxi se

tento vztah aplikuje pomocí spojovací tabulky, tzn. vztah N:M se rozloží na dva vztahy N:1.

31

Základy relační algebry

Relační algebra je nejzákladnějším prostředkem pro práci s tabulkami. Mezi základní operace

patří projekce, selekce a spojení. Tyto operace lze definovat takto:

Projekce tabulky (relace) R s položkami A na množinu položek B, kde BA:

vytvoří tabulku s položkami B a záznamy, které vzniknou z původní tabulky R

odstraněním položek A-B. Odstraněny jsou i eventuelně opakující se záznamy.

-značení: R[B]

Selekce tabulky R s položkami A podle logické podmínky :

-vytvoří tabulku s týmiž položkami a ponechá ty záznamy z původní tabulky, které

splňují logickou podmínku . Podmínka je logický výraz, jehož formule nad

jednoduchými položkami tabulky mají tvar:

kde:

t1, t2 jména položek tabulky, konstanty nebo výrazy

logické operátory -

-značení: R()

Spojení tabulek R a S se položkami A a B:

vytvoří minimalizovanou tabulku se schématem AB a se záznamy, jejichž projekce

na A je z tabulky R a projekce na B je z tabulky S.

-značení: R * S

U spojení pracujeme s několika možnými případy. Nejčastější je spojení přes rovnost

(přirozené spojení). Výsledná tabulka obsahuje jen ty záznamy z obou zdrojových tabulek,

které se shodují v položkách, přes které se spojení provádí. Pokud některý záznam z jedné

tabulky nemá odpovídající záznam v tabulce druhé, ve výsledné tabulce se neobjeví.

Takový postup se nám však ve všech případech nehodí, proto je nutno používat další typy

spojení, levé -polospojení a pravé -polospojení, které z určené tabulky (stojící v operaci jako

levý či pravý argument) připojí všechny záznamy, bez ohledu na to, zda mají odpovídající

záznam v druhé zdrojové tabulce. Použití polospojení je důležité tam, kde není programově

zajištěna plná integrita dat, případně pokud nemáme jistotu, že nemůže být porušena.

Příklad jednotlivých operací relační algebry si ukážeme na dvou tabulkách - OPRAVY a

VOZIDLO.

Tabulky OPRAVY a VOZIDLO jsou definované položkami podle obrázku č.1. Tyto tabulky

obsahují jednotlivé záznamy podle obrázku Obr. č.2 a Obr. č.3.

32

Obr. č.1: Struktura tabulek příkladu.

Obr. č.2: Tabulka OPRAVY.

Obr.č.3: Tabulka Vozidlo.

Na těchto tabulkách provedeme jednotlivé operace:

a) Projekce tabulky OPRAVY položkami Dat_opravy, Zakázka. Výsledek je na Obr. č.4.

Obr. č.4: Projekce OPRAVY[Dat_opravy,Zakázka].

b) Selekce tabulky OPRAVY.

Podmínka pro selekci je dána výrazem : Dat_opravy = 7.5.2000

Výsledná tabulka je na obrázku Obr. č.5.

33

Obr. č.5: Selekce OPRAVY[Dat_opravy = 7.5.2000].

c) Spojení tabulek OPRAVY a VOZIDLA.

Spojení těchto tabulek se děje pomocí spojení přes rovnost položek OPRAVY.SPZ a

VOZIDLA.SPZ (viz Obr. č.6). Vznikne tabulka obsahující záznamy, jejichž struktura je dána

souhrnem všech položek spojovaných tabulek. Takto vzniklá tabulky je ukázkou

nejjednodušší formy spojení.

Obr. č.6: Vazba položek při spojení.

Obr. 7: Spojení OPRAVY*VOZIDLO přes OPRAVY.SPZ = VOZIDLO.SPZ (zobrazeny jen

některé položky tabulky).

Z příkladu a předchozích definic je zřejmé, že operace projekce vybírá sloupce, operace

selekce vybírá řádky (záznamy) a operace spojení provádí spojení dvou tabulek přes

zvolenou položku nebo skupinu položek.

34

6 Vlastní a standardní datové typy (jednoduché i

strukturované) Strukturované příkazy – podmínky

Vlastní a standardní datové typy (jednoduché i strukturované)

Klíčová slova

Datový typ, integer, char, boolean, ordinální, pole, záznam

Jednoduchý datový typ

Jednoduché datové typy jsou definovány svým identifikátorem a typem v deklarační oblasti.

Pro tyto typy jsou definovány relace rovnost a nerovnost dvou hodnot a dále relace větší a

menší. Jednoduché datové typy se dále ještě dělí na ordinální a neordinální typy.

Ordinální - hodnota, náležící do tohoto typu, má svého předchůdce, svého

následovníka a její pozici lze číselně ohodnotit. Ordinálních typů je několik: integer,

boolean, char a uživatelem definované typy interval a výčtový typ.

Neordinální - hodnoty datového typu nejsou zobrazitelné na množině celých čísel

Pro ordinální typy platí:

hodnoty ordinálního typu jsou uspořádanou množinou hodnot

každá hodnota je sdružena s ordinalitou, což je celočíselná hodnota, udávající pozici v

uspořádané množině hodnot

první ordinální hodnota každého typu (kromě typu integer) je 0, další 1, 2, atd.

každá hodnota ordinálního typu má předchůdce (kromě první hodnoty) a následovníka

(kromě poslední hodnoty)

pro zjišťování ordinální hodnoty argumentu, předchůdce a následovníka existují funkce:

succ(x) . . . vrací ordinální hodnotu následovníka

pred(x) . . . vrací ordinální hodnotu předchůdce

ord(x) . . . vrací ordinální hodnotu argumentu, kde x je hodnota ordinálního typu

inc(x) . . . zvětší hodnotu proměnné x o jedničku

inc(x,y) . . . zvětší hodnotu proměnné x o y

dec(x) . . . zmenší hodnotu proměnné x o jedničku

dec(x,y) . . . zmenší hodnotu proměnné x o y

BOOLEAN

35

Tento datový typ je reprezentován dvěma hodnotami true (pravda) a false (nepravda), které

slouží k vyjádření logických hodnot. Pro hodnoty typu boolean jsou definovány všechny

relační operace (=, <>, <, >, <=, >=).

INTEGER

Tento datový typ specifikuje konečnou souvislou podmnožinu celých čísel. Umožňuje

uživateli využít několik datových typů, které se od sebe liší rozsahem hodnot a tím i použitou

velikostí paměti.

Typ Rozsah Velikost [bit]

shortint -128 .. 127 8

integer -32 768 .. 32 767 16

longint -231

.. 231

-1 32

byte 0 .. 255 8

word 0 .. 65 535 16

comp -263

+ 1 .. 263

- 1 64

CHAR

Je to takový datový typ, jehož hodnotami jsou znaky. Množina hodnot však není definována

tímto typem, ale kódem znaků, který je v počítači implementován. Nejčastěji se používá kód

ASCII (American Standard Code for Information Interchange), jeho evropská verze ISO a

kód EBCDIC (Extended Binary Coded Decimal Information Code). většinou se zapisuje v

uvozovkách, např. 'A', '%', '1'. V paměti zabírá 1 byte.

INTERVAL

Tento datový typ specifikuje souvislou neprázdnou podmnožinu hodnot nějakého ordinálního

typu. Dolní a horní mez této podmnožiny udávají dvě konstanty daného ordinálního typu.

Např.: zápis 1 .. 100 definuje interval, specifikující množinu celočíselných hodnot. Typ

interval však nemusí být definován pouze nad číselnými typy, může být definován i nad typy

výčet či char, jak ukazuje následující příklad:

type

pracovni_dny = pondeli .. patek;

velke_pismeno = 'A' .. 'Z';

36

REAL

Tento datový typ specifikuje konečnou podmnožinu reálných čísel. Používá se pro vyjádření

hodnot s pohyblivou desetinnou čárkou. V paměti počítače se hodnoty vyjadřují jako dvojice

(M,N), kde M je mantisa a N je exponent. Rozsahy hodnot jsou uvedeny v následující tabulce:

STRUKTUROVANÉ DATOVÉ TYPY

Strukturované datové typy používáme pro uchování více hodnot, mezi kterými jsou určité

vazby. Způsob strukturování určuje možný počet složek, charakter typů složek a operace

přístupu ke složkám.

POLE

Tento datový typ se skládá z pevného počtu položek stejného typu. Položky se vzájemně

rozlišují pomocí indexu. Mezi položkami dat a hodnotami indexů existuje jednoznačné

přiřazení. Při definici pole se určuje jeho rozměr a datový typ složek. Rozměr pole určuje

počet prvků, které se do pole mohou vložit. Index pole je většinou typu integer. Může jím

však být i jiný ordinální typ. Velikost pole je vždy omezena paměťovými nároky.

ZÁZNAM

Záznam je heterogenní datová struktura. Je složena z jednotlivých dílčích komponent, které

můžou být různého typu. Každá komponenta má přidělen svůj identifikátor a datový typ.

Navenek se však chová jako kompaktní datový celek.

ŘETĚZEC

Řetězec je posloupnost znaků, proto se svým způsobem hodně podobný poli. Některé

programovací jazyky (např. C/C++) definují řetězec jako pole o prvcích typu char.

K jednotlivým prvkům můžeme stejně jako u pole přistupovat jednotlivě pomoci indexu.

V Pascalu, a nejen v něm, můžeme pro práci s řetězci využívat spoustu funkcí, které jsou

přímo implementovány. Například můžeme řetězce sčítat, zjišťovat jejich délku, vyhledávat

v nich a podobně.

VÝČET

Pomoci typu výčet můžeme reprezentovat data, která mohou nabývat malého počtu různých

hodnot např. dny v týdnu. Hodnoty výčtového typu jsou ordinální a můžeme požívat funkce

pro práci s ordinálními typy (předešlý člen, další člen, atd.).

Typ Rozsah Velikost [byte]

real 2.9*10-31

.. 1.7*1038

6

single 1.5*10-45

.. 3.4*1038

4

double 5.5*10-324

.. 1.7*10308

8

extended 1.9*10-4932

.. 1.1*104932

10

37

Strukturované příkazy – podmínky

Klíčová slova

if, else, case, příkaz, struktura, begin, end, podmínka, pascal, větvení programu

Obsah otázky

Příkazy předpisují provedení jistých algoritmických činností. Podle struktury je lze dělit na jednoduché a strukturované.

Strukturované příkazy předpisují postupné, podmíněné nebo opakované provádění svých

příkazů dílčích. Každý ze strukturovaných příkazů je jako celek ze syntaktického hlediska

jediným příkazem - tam, kde je ve zdrojovém textu povolen příkaz, může být uveden buď

jednoduchý, nebo strukturovaný příkaz (i dílčím příkazem strukturovaného příkazu může tedy

být příkaz rovněž strukturovaný).

Pomocí podmíněných příkazů můžeme větvit běh programu podle aktuálních výsledků jeho

výpočtu. Podmíněným příkazem je vybrán a proveden jediný z uvedených příkazů dílčích.

Příkaz If

Příkazem if (jestliže platí) je vybrán a proveden jeden ze dvou alternativních dílčích příkazů, uvedených ve dvou větvích — větvi then (pak) a větvi else (jinak).

Příkaz if používáme, pokud potřebujeme provést nějaký

příkaz jen za určitých podmínek.

Rozlišujeme dva typy podmíněného příkazu if. První typ je

tzv. neúplný podmíněný příkaz a druhý typ je úplný

podmíněný příkaz.

Neúplný podmíněný příkaz

•umožňuje, aby se posloupnost příkazů chovala jako jeden příkaz

Složený příkaz

•umožňuje větvení programu (příkazy if a case)

Podmíněný příkaz

•provádí opakování dílčích příkazů (příkazy repeat, while a for)

Příkaz cyklu

38

Je-li splněna podmínka, provede se příkaz, není-li podmínka splněna, příkaz se neprovede.

Úplný podmíněný příkaz

Je-li splněna podmínka, provede se příkaz 1, není-li splněna podmínka, provede se příkaz 2.

Příkaz case

Příkaz se používá pro větvení programu. Umožňuje rozvětvení programu na více větví. Lze jej nahradit příkazy if, které jsou vnořeny do sebe. Potřebujeme-li rozlišit více hodnot jedné proměnné, můžeme místo vnořených příkazu if použít příkaz case. Ten obsahuje seznam významných hodnot a k nim přirazené příkazy nebo programové bloky. Příkaz case je ukončen slovem end.

Jak příkaz funguje:

- Vyhodnotí se výraz (selektor) – zjistí se jeho hodnota

- Zjištěná hodnota se postupně porovnává s uvedenými výběrovými konstantami

- Narazí-li se na výběrovou konstantu, která je rovna hodnotě výrazu (selektoru),

provede se příkaz, který je za dvojtečkou.

- Chceme-li provést víc příkazů, je nutné je uzavřít mezi begin a end.

V pascalu neúplný podmíněný příkaz zapíšeme takto:

• if Podmínka then Příkaz

V pascalu úplný podmíněný příkaz zapíšeme takto:

• if Podmínka then Příkaz 1 else Přikaz 2

39

Shrnutí

Podmíněné strukturované příkazy slouží k rozhodování v programu. Asi jedna

z nejpoužívanějších podmínek je právě podmínka if ať už v úplném nebo jen částečném znění.

Tato funkce vrací booleanovský typ proměnné resp. 1 nebo 0, kde 1 znamená „pravda“ a 0

pak „nepravda“. Dále pak máme příkaz case, který umožňuje větvení programu na více větví.

Je používán v situacích, kdy je příliš zdlouhavé, neefektivní či nepraktické používat příkaz if.

Funguje na principu, že vyhodnocuje příkaz na vstupu a pomocí podmínek jej vyhodnotí a

případně provede požadovanou funkci.

40

7 Strukturované příkazy – cykly

Klíčová slova

Základy programování, cyklus programováni, reapeat-until, do-while, while-do, for

Obsah otázky

Cyklus je řídící struktura počítačového programu. Příkazy pro vytváření cyklů používáme

v případě, že potřebujeme nějaký příkaz vykonávat opakovaně. K řízení opakování

používáme podmínky (II-12. Strukturované příkazy - podmínky), která určí, kolikrát se příkaz

provede. Základní předpoklad je, že pokud je podmínka splněna, dojde k vykonání jednoho

přechodu cyklem (obráceně v případě repeat-until). Pokud podmínka splněna není, program

pokračuje za cyklem.

Nejznámější a nejpoužívanější cykly:

For

While-do

Do-while (repeat-until)

For

Cyklus for je taky označován jako cyklus se známým (pevným) počtem přechodů a kontrolou podmínky na začátku cyklu je podobný cyklu while-do.

Typicky se cyklus skládá z inicializátoru (inicializační proměnné), podmínky, inkrementu a

těla cyklu. V různých programovacích jazycích (Pascal, Visual Basic) existují různé

modifikace for cyklu, kde je např. místo inicializátoru, podmínky a inkrement uveden výčet

hodnot, které se budou přiřazovat nějaké proměnné.

Výčet intervalu a syntax cyklu for v programovacím jazyce Pascal:

for i:= 0 to N do { i nabývá postupně hodnot od 0 do N }

begin

{ tělo cyklu }

end;

Příklad:

for i:= 0 to 2 do

begin

writeln(‘Vystup cyklu for je cislo: ’, i);

41

end;

Vykonáním programu získáme výstup:

Vystup cyklu for je cislo: 0

Vystup cyklu for je cislo: 1

Vystup cyklu for je cislo: 2

While-do

Cyklus while-do se používá v případě, že neznáme počet opakování cyklu. Podmínka se testuje hned na začátku cyklu, takže když je podmínka neplatná, cyklus nepřeběhne ani jedenkrát. Tuhle podmínku můžeme nazvat podmínkou setrvání v cyklu. Je třeba tento typ odlišit od cyklu do-while (reapeat-until).

Syntax v jazyku Pascal:

while (logicka_podminka) do

begin

{ tělo cyklu }

end;

Příklad:

Cyklus while-do se může použít např. při ověřování vstupů od uživatele programu. Příklad

ukazuje jednoduchou hru, kdy si myslím nějaké číslo (12) a vašim úkolem je ho uhodnout.

readln(x); { nacteni promenne – uzivatel hada cislo}

while (x <> 12) do { podminka setrvani v cyklu – uzivatel netrefi cislo 12}

begin

writeln(‘Netrefil si cislo, na ktere myslim. Hadej znovu!’);

readln(x);

end;

writeln(‘Uhodl si, gratuluji!’);

Program ještě před cyklem načte od uživatele číslo. Když se trefí, cyklus neproběhne ani

jednou a program mu ihned pogratuluje (podmínka zabezpečuje, že když uživatel uhodne

42

číslo 12, tak se cyklus neprovede). V případě, že se netrefí, je požádán o nové zadání a to se

opakuje až do momentu, kdy uživatel uhodne myšlené číslo.

Do-while (repeat-until)

Do-while cyklus představuje případ cyklu, kdy se nejprve jednou vykoná tělo cyklu a až po provedení tohoto přechodu se rozhoduje, zdali cyklus bude ukončen, nebo se bude opakovat.

Podobný cyklus cyklu do-while je cyklus repeat-until, který vypadá a probíhá naprosto stejně,

jen závěrečná podmínka je opačná. Při její nesplnění se cyklus opakuje a naopak při její

splnění program z cyklu vyskočí. Tato struktura je využita v jazyce Pascal nebo Visual Basic

(do-until).

Syntax v jazyku Pascal:

repeat

{ tělo cyklu }

until (logicka_podminka); { podminka vystoupeni z cyklu}

Příklad:

reapeat

random(9); { generovani nahodneho cisla od 0 do 9}

writeln(x, ‘,’); { zapsani vygenerovaneho cisla}

until (x = 5); {podmínka vystoupeni – kdyz promenna x se rovna 5 }

Program generuje a zapisuje čísla až do momentu, kdy nevygeneruje číslo 5. Tehdy program

končí.

Shrnutí

Cyklus je řídící struktura počítačového programu. Mezi známé a často používané cykly patří

cyklus for, while-do a do-while (repeat-until). Každý z nich má svoje specifické použití.

Cyklus for se používá v případě, že víme nebo máme stanový počet opakování cyklu.

Cyklus while-do je podobný cyklu for, ale nemusí si jednat o stanovený počet opakování.

Podmínka je ověřována na začátku cyklu a testuje setrvání v cyklu.

Cyklus do-while se vykoná vždy minimálně jednou. Po provedení cyklu se testuje podmínka

setrvání v cyklu (v případě repeat-until se testuje podmínka vystoupení z cyklu). Pokud je

podmínka splněna, cyklus pokračuje (v případě repeat-until cyklus končí a pokračuje

v případě, že podmínka není splněna).

43

8 Program, knihovny (moduly) Procedury a funkce

Klíčové slovo Program musí být uvedeno na začátku každého programu. Za klíčovým slovem

následuje název programu :

- Jednoslovný název

- Nepoužívat vyhrazená slova systémem (název interních konstant, funkcí a

procedur)

- Jako 1. znak v názvu programu nesmí být číslice

- Za názvem programu následuje středník

Program <jméno programu>;

Uses <seznam jednotek>;

Label <deklarace návěští>;

Const <deklarace konstant>;

Type <deklarace datových typů>;

Var <deklarace proměnných>;

<deklarace uživatelských procedur a funkcí>;

Begin

<tělo hlavního programu>;

End.

Procedury a funkce

Klíčová slova

programování, procedury, funkce, subroutine, podprogram

Obsah otázky

Procedury a funkce tvoří posloupnost instrukcí, které potřebujeme v programu na různých místech zopakovat a jsou to ve své podstatě podprogramy, logické uzavřené programové celky. Existuje mnoho výhod rozdělení programu na podprogramy:

Zamezení opakování částí programu

Možnost znovupoužití podprogramu v jiných částech programu nebo jiných

programech

Rozsekání komplexních problému na jednodušší části – lepší možnost

manipulace a rozšíření

44

Zvýšení čitelnosti a přehlednosti programu

Modulovatelnost a flexibilita

Podprogram může obsahovat:

Tělo podprogramu, které se vykoná v případě, že je podprogram zavolán

Parametry, které jsou předány do podprogramu z místa volání hlavního

programu

Hodnotu, která je vrácena do místa volání podprogramu

Identifikátor vyvolaného podprogramu – v takovém případě se podprogram

vykonává rekurzivně

Další podprogramy

Mnoho programovacích jazyků (Pascal, Fortran, Ada) rozlišují mezi funkcemi, které vracejí

hodnoty programu (přes zpětnou proměnnou) a procedurami, které to nedělají. Některé jazyky

(C, Lisp) nedělají tenhle rozdíl a posuzují procedury a funkce jako synonymum.

Datový typ parametru z volaného místa musí zodpovídat datovému typu

parametru definovanému v podprogramu.

Pro ukázku procedur byl zvolený programovací jazyk Pascal, který je názorným a

jednoduchým jazykem používaným pro výuku.

Procedury

procedure <jmeno_proc> (<par1> : type, …; var <par2> : type, <par3> : type, …);

label <deklarace návěští>; const <deklarace konstant>; type <definice typů>;

var<deklarace proměnných>; procedure; function; <deklarace procedur a funckí>;

{deklarační část – stejné pravidla jako při deklaraci hlavního programu, kromě uses}

begin

<tělo procedury>; {příkazová část}

end;

procedure – formální deklarace procedury

<jmeno_proc> - jméno procedury, pod kterým je volaná z nadřazeného

programu

45

(<par1> : type, …; var <pa2> : type, …) – definice parametrů – procedura

nemusí obsahovat definici parametrů (v takovém případe podprogram může

pracovat jenom s globálními přeměnnými).

<par1> : type – jméno vstupního parametru a datový typ parametru. Definice

parametrů nemusí obsahovat tento typ parametru

var <par2> : type – definice parametru pomocí var, za kterým pokračují

vstupno-výstupní parametry (proměnné, které jsou odeslány při volání

procedury programem a odeslány z procedury do programu) a jejich datové

typy

Příklad:

Program PRIKLAD_PROC; {hlavička hlavního programu}

Procedure DruhaMocnina(Index : Integer; Var Vysledek : Integer); { hlavička procedury}

Begin

Vysledek := Index * Index; {tělo procedury}

End;

Var vysled : Integer; {deklarační část hl. programu}

Begin

Write(‘Druha mocnina cisla je : ');

DruhaMocnina(5, vysled); {tělo hl. programu, volání procedury}

Writeln(vysled);

End.

Funkce

Funkce je další typ podprogramu. Jediný rozdíl od procedury spočívá v tom, že funkce na svém konci vrací jednu hodnotu. Když chceme více jak jednu vrácenou hodnotu, je potřebné využít procedur. function <jmeno_funkce> (<par1> : typ; <par2> : type;…) : RetrunType;

{ostatní častí jsou stejné jak při procedurách}

function – formální deklarace funkce

<jmeno_funkce> - jméno funkce, pod kterým je volaná z nadřazeného

programu

46

(<par1> : type, …; <pa2> : type, …) – definice parametrů – procedura nemusí

obsahovat definici parametrů (v takovém případe podprogram může pracovat

jenom s globálními přeměnnými)

<par1> : type – jméno a datový typ vstupního parametru.

function <jmeno_funkce> (<par1> : typ; <par2> : type;…) : ReturnType; -

datový typ vrácené hodnoty funkce, který v hlavičce podprogramu musí být. V

těle samotné funkce se musí použít přiřazovací příkaz <jmeno_funkce> :=

<vracena_hodnota>;

Příklad:

Function PRIKLAD_FUNKCE (n : Byte) : Longint; { hlavička funkce} Var i : Byte;

pomocna : Longint; Begin

pomocna := 1; For i:=1 to n Do pomocna := pomocna * i; PRIKLAD_FUNKCE := pomocna; {tělo funkce, přiřazení hodnoty

k navrácení do hlavního programu} End;

Shrnutí

Procedury a funkce jsou podprogramy, které obecně práci usnadňují a zpřehledňují.

V jazyce Pascal je rozdíl mezi funkcí a procedurou v tom, že funkce musí vracet určitou jednu

hodnotu.

Tělo podprogramu může zavolat samo sebe, co se nazývá rekurze.

47

9 Práce se soubory

Pod pojmem soubor se v informatice myslí pojmenovaná uspořádaná množina dat uložená na

nějakém datovém médiu (viz např. pevný disk, disketa, CD, Flash disk). Každý soubor má

svůj název, délku a případně další atributy požadované operačním systémem. Obsahem

souboru mohou být různá data, textová a binární.Fyzické uspořádaní souborů na datovém

médiu zajišťuje souborový systém (filesystem).

Adresář- (někdy též složka) je organizační jednotka v souborovém systému na elektronickém

datovém médiu. Může obsahovat další adresáře (v moderních souborových systémech) a

soubory.

Obvykle tvoří adresáře na disku stromovou strukturu. Některé filesystémy umožňují i

neorientované cykly, podpora orientovaných cyklů ale klade příliš velkou zátěž na operační

systém.

Složka v počítači je jako složka v reálném světě. Sama o sobě nemá hodnotu. Ani když

přesuneme do složky dokumenty, nemá jinou hodnotu, než tu, že nám ty dokumenty třídí.

Složka v počítači (adresář) sdružuje na disku dokumetny (soubory) a další složky

(podadresáře), které k sobě logickým způsobem patří (nebo by měly patřit). I my si můžeme

vytvořit složku a v ní logicky uspořádat další složky a do nich soubory. Pro přehlednost

nemohou v jednom adresáři existovat dva soubory nebo adresáře se shodným jménem.

Formát souboru- (neboli typ souboru) určuje význam dat v elektronickém souboru.

Neboť na záznamová media, například pevný disk, mohou být ukládány jen bity, laicky

řečeno jedničky nebo nuly, musí být počítač schopen na ně a zpět převést informaci. Existuje

množství různých formátů, přizpůsobených pro ukládání různých typů informace. Často

existuje více formátů pro reprezentaci jednoho typu dat.

Některé formáty jsou navrženy pro ukládání přesně daného typu dat, například JPEG je určen

na uchovávání statických obrázků. Jiné mohou sloužit pro několik typů dat. GIF slouží pro

uchovávání jak statických obrázků, tak jednoduché animace a Quicktime může obsahovat

různá multimediální data.

Textový soubor je určen pro uchovávání textu ve znakové sadě například ASCII, Unicode,

nebo ISO-8859-2 s málo, pokud vůbec, řídícími znaky. Některé formáty jako HTML, nebo

zdrojový kód jsou vlastně také textové soubory, ale platí pro ně složitější pravidla, aby mohly

sloužit speciálním úkolům.

Je sice možné některé programy přimět, aby otevřely soubor cizího formátu, ale obvykle se

pak zobrazí jen jako změť znaků. Nebo pokud si necháte přehrát textový formát Microsoft

Wordu jako proud hudebních dat bez uvození (.raw) uslyšíte pravděpodobně neharmonické

zvuky, protože takto ztrácí význam a jedná se jen o „náhodný“ shluk tónů.

48

Rozdíl mezi formátem souboru a programovacím jazykem se může jevit malý. Jazyk může

být chápán jako formát pro ukládání algoritmů a prohlížeč jakéhokoli formátu například PNG

jako interpret „jazyka“ PNG.

Rozpoznávání formátu souboru- Pro správné zacházení s daty, bylo potřeba, aby operační

systém rozeznal jaká data se v souboru v souborovém systému nacházejí. Operační systémy v

minulosti zavedly několik způsobů řešení. Dnes se částečně prolínají a na jednom operačním

systému (s aplikacemi) zpravidla najdeme vícero přístupů.

Podle přípony-Jednou z metod, využívanou například na operačních systémech

vyvíjených DEC a CP/M, na operačních systémech typu DOS a Windows je určit

formát na základě části jména následující po poslední tečce „.“ (první zprava). Tato

část se nazývá přípona souboru (označení přípona se může používat i pro další části

nacházející se mezi libovolnými dvěma tečkami, ale ty nemají vliv na určování typu

souboru a mohou mít jiný význam než přípony). Například „index.html“ je soubor

jménem „index“, formátu HTML. V původním verzi souborového systému FAT byl

název omezen na 8 znaků jména a 3 přípony, dnes už toto omezení neplatí, přesto je

mnoho přípon právě třípísmenných. Navíc je díky tomuto omezení více formátů

používajících stejnou zkratku, což může uživatelům vadit či způsobovat nepříjemnosti,

když je soubor otvírán nevhodným programem.Výhodou tohoto řešení byla snadná

změna formátu přejmenováním, například z HTML na text přejmenujeme index.html

na index.txt. Toto však oceňovali spíše zkušenější uživatelé. Méně zkušeným se pak

stávalo, že nebyli schopni soubor otevřít čí ho považovali za ztracený. To vedlo v

novějších operačních systémech jako je Windows 95 a vyšší čí Mac OS X k skrývání

přípon při zobrazování.

Podle hlavičky-Naproti tomu Unix a od něj odvozené operační systémy využívají

prvních bytů souboru. Ty obsahují jednoznačnou sekvenci k určení typu souboru.

Původně to byly první dva byty, ale dnes je běžně delší. Například obrázky formátu

GIF uvozuje sekvence GIF87a nebo GIF89a dle použitého standardu GIF.Tento

způsob sice umožňuje přesnou identifikaci formátu, ale pro zjištění formátu je třeba

projít databázi možných hlaviček, což může zpomalovat v grafických aplikacích, kde

kliknutí způsobí vykonání, proto je běžnější při práci s příkazovou řádkou.

Podle metadat-Další možností je ukládat data mimo soubor a jeho název. Toto splňují

metadata uložená zvlášť souborovým systémem. Tento systém je méně přenosný mezi

souborovými systémy, běžně se musí konvertovat.

Souborový systém- (anglicky filesystem) je označení pro způsob organizace informací (ve

formě souborů) tak, aby bylo možné je snadné najít a přistupovat k nim. Souborové systémy

mohou používat paměťová média jako pevný disk nebo CD, mohou poskytovat přístup k

datům uloženým na serveru (síťové souborové systémy, např. NFS, SMB nebo 9P) nebo

mohou poskytovat přístup k čistě virtuálním datům (např. procfs v Linuxu). Souborový

systém umožňuje ukládat data do souborů, které jsou označeny názvy. Obvykle také

umožňuje vytvářet adresáře, pomocí kterých lze soubory organizovat do stromové struktury.

49

Organizace dat na disku –Pevné disky jsou obvykle logicky rozděleny na oddíly (partition),

takže souborový systém se rozkládá jen na konkrétním oddílu a ne na celém disku. To

umožňuje mít na pevném disku více nezávislých souborových systémů, které mohou být

různého typu.

Infomace uložené v systému souborů dělíme na metadata a data. Metadata popisují strukturu

systému souborů a nesou další služební a doplňující informace, jako je velikost souboru, čas

poslední změny souboru, čas posledního přístupu k souboru, vlastník souboru, přístupová

práva k souboru, seznam bloků dat, které tvoří vlastní soubor atd. Pojmem data pak míníme

vlastní obsah souboru, který můžeme přečíst, když soubor otevřeme.

Software, který realizuje souborový systém, bývá obvykle součástí operačního systému.

Většina operačních systémů podporuje několik různých souborových systémů. V Microsoft

Windows nalezneme podporu pro souborové systémy FAT a NTFS a ISO 9660 pro ukládání

souborů na CD a DVD. V Linuxu nalezneme kromě již zmíněných také ext2, ext3, ReiserFS,

JFS, XFS a mnoho dalších. DOS podporuje systémy FAT, po instalaci CD/DVD driveru také

ISO 9660. Solaris podporuje především UFS a ZFS, ale i mnoho dalších.

Žurnálování v systému souborů- Zápis dat a metadat do systému souborů probíhá v

několika krocích. Proto nejsou data a metadata v každém okamžiku konzistentní. Dojde-li v

takové chvíli k havárii počítače (např. výpadek elektrického proudu, chyba hardware,

software a podobně), zůstane systém souborů v nekonzistentním stavu. Z tohoto důvodu je při

dalším startu operačního systému vhodné, aby byla provedena kontrola a nekonzistentní data

byla opravena. K tomu může dojít automaticky (např. v Linuxu nebo ve Windows 95 a

novějších systémech) nebo je nutné spustit kontrolu ručně (systémy DOS).

Celková kontrola systému souborů a všech vazeb mezi daty a metadaty je časově velmi

náročná operace, při které navíc může dojít ke zbytečné ztrátě již částečně zapsaných

informací. Proto jsou moderní systémy souborů rozšířeny o žurnálování, které umožňuje po

havárii rychlou opravu eventuálních nekonzistencí. Principem techniky je uchovávání

chronologického záznamu prováděných operací, do kterého se zapisují všechny prováděné

činnosti. Pokud dojde např. k výpadku napájení, je po restartu nekonzistence opravena

návratem do předchozího zaznamenaného stavu za pomoci záznamů z žurnálu.

Mezi žurnálovací souborové systémy patří např. NTFS, HFS+, ext3 nebo ReiserFS.

Síťové souborové systémy -(network filesystem) je označení pro systémy souborů, které jsou

dostupné prostřednictvím počítačové sítě. Ve skutečnosti leží soubory a adresáře na jiném

počítači a přistupujeme k nim pomocí speciálních síťových volání služeb (např. SMB, NFS,

CODA apod.). Na vzdáleném počítači jsou pak soubory a adresáře fyzicky uloženy v podobě

klasického systému souborů. Speciálními síťovými systémy souborů jsou distribuované

souborové systémy (např. GFS v Linuxu), které se mohou rozkládat na několika počítačích,

které jsou navzájem propojeny pomocí počítačové sítě.

50

Databázové souborové systémy- V poslední době se začínají objevovat souborové systémy,

které se odklánějí od klasické hierarchické struktury souborů a přiklánějí se více k

databázovému pojetí reprezentace dat založené na jejich charakteristikách, tj. například na

typu souboru, datu vytvoření, autoru a jiných metadat.

51

10Objekty, metody, vlastnosti a události nad objekty

Techniky pro ladění programu a ošetření chyb

Dialogy

Objekty, metody, vlastnosti a události nad objekty

Skupina objektů stejné třídy je Kolekce. Kolekce sama je objekt. Chceme-li odkazovat na jednotlivý

objekt kolekce, vloží se název objektu nebo jeho index do závorky za název kolekce :

Worksheets(“List1”) nebo Worksheets(1)

Kolekce SHETS pak sdružuje jak pracovní listy, tak listy s grafy

Při odkazu na nějaký objekt pomocí VBA se objekt určuje pomocí tečky – tečkový operátor :

Odkazy na objekty

Range(“A1”) = 10

Worksheets(“List1”).Range(“A1”) = 10

WorkBooks(“Sešit1.xls”). Worksheets(“List1”).Range(“A1”) = 10

Application. WorkBooks(“Sešit1.xls”). Worksheets(“List1”). Range(“A1”) = 10

Vlastnosti objektu

Každý objekt má vlastnosti

Použití : MsgBox Worksheets(“List1”).Range(“A1”). Value

Worksheets(“List1”).Range(“A1”).Value = “ABCD”

Každý objekt má výchozí vlastnost, objekt Range má výchozí vlastnost Value. Výchozí vlastnost

objektu se při psaní kódu může vynechat, můžeme tedy napsat :

MsgBox Worksheets(“List1”).Range(“A1”)

Worksheets(“List1”).Range(“A1”) = “ABCD”

Vlastnosti objektu, které mají parametry píšeme zásadně do závorek :

MsgBox Worksheets(“List1”).Range(“A1”).Address(False)

Metody objektu

Každý objekt má své metody. Metoda je nějaká činnost, kterou s objektem provádíme.

Použití : Worksheets(“List1”).Range(“A1:D7”). Clear

52

Většina metod má parametry, které blíže určují činnost

Parametry metody se umísťují za název metody a oddělují se čárkou :

Worksheets(“List1”).Protect “ABCDE”, True, True (odemknuti false)

Nepovinné parametry metod se nemusí psát, nahrazují se však prázdným místem :

Worksheets(“List1”).Protect , True, True

Kód lze psát i včetně pojmenování parametrů, pak u nepovinných parametrů není důležité psát

čárky : Worksheets(“List1”).Protect , Structure := True, Windows := True

Techniky pro ladění programu a ošetření chyb

Ladění programů se nazývá debugging. Tyto techniky může provádět buď programátor sám,

nebo pomocí programu zvaného debugger.

Klíčová slova: Programátorská chyba

Ladící program

Ladící proces

Programátorská chyba (Bug)

Programátorská chyba je chyba, kterou udělal programátor při vytváření programu.

Zdroje chyb

Chyba může být:

Syntaktická

Taková chyba spočívá v narušení syntaxe gramatiky použitého programovacího jazyka. U

kompilovaných programů ji překladač zahlásí přímo při překladu během syntaktické analýzy.

Inteligentní editory hlásí tyto chyby přímo při psaní programu.

Sématická

Program se bez problému přeloží, ale nedělá co má. Například skončí v nekonečném cyklu,

spadne (je násilně ukončen operačním systémem pro porušení přidělených práv) nebo vydá

naprosto špatný výsledek (což je většinou ta nejhorší možná varianta). Ve složitějším

programu (například operačním systému) se může stát, že program pozná, že se dostal do

chybné situace, ale není schopen pokračovat ve funkci a proto se zastaví nebo ukončí,

obvykle se specifickým chybovým hlášením.

Neočekávaná událost

Při běhu programu nastane situace, se kterou programátor nepočítal a na kterou neumí

program správně zareagovat. Může to být situace vnitřní (například se pokouší psát do

53

souboru na disku, ale disk je plný) nebo neočekávaná hodnota vstupu.

Ladící program (Debugger)

Debugger je počítačový program, který se používá pro nalézání chyb v jiných programech.

Většinou je možné zobrazit zdrojový kód laděného programu, takže je ihned možné vidět

místo, kde se objevila programátorská chyba.

Většina vývojových prostředí má integrovaný debugger, případně se připojuje na externě

spuštěný nezávislý debugger, takže je možné ladit program ve stejném oknu, ve kterém se

vyvíjí samotný program. To velmi urychluje vývojový cyklus softwaru.

Většina debuggerů má již dnes zabudované funkce jako „prohlížení programu krok po

kroku(singel-steping)“ a „zastavení programu(breaking)“, což znamená, že se program

zastaví v místě, kde jsme mu předem určili a nedoběhne dokonce jako při běžném provozu.

Takové místo se nazývá breakpoint. Obě tyto funkce jsou velmi užitečnými nástroji při ladění

programu, zejména programátorovi umožní sledovat hodnoty proměnných v každé fázi

programu a zjistit, kde se poprvé objevila chyba.

Debugger se také používá při crackingu (nebo revers engeneeringu) pro pochopení jak

program pracuje, pak je možné odstranit například ochranu proti kopírování nebo vytvořit

mod do hry.

Ladicí proces (Debugging)

Přestože každý ladící proces je jedinečný, existují určitá doporučení, sled kroků, jak

postupovat. Většina ladících programů postupuje podle těchto kroků.

- Odhalit chybu (Recognize that a bug exists)

- Izolovat zdroj chyby (Isolate the source of the bug)

- Identifikovat příčinu chyby(Identify the cause of the bug)

- Určit způsob opravy (Determine a fix for the bug)

- Opravit chybu a testovat (Apply the fix and test it)

Odhalit chybu

Zkušený programátor často ví, kde je největší pravděpodobnost výskytu chyb, zejména

vzhledem ke složitosti jednotlivých částí programu a možnostem poškození dat. Například

všechny data obdržená od uživatele by měla být považována za podezřelá. Velký důraz by

měl být kladen na kontrolu správnosti formátu a obsahu dat. Data získaná různými druhy

přenosu by měla být zkontrolována, zda jsou celá. Komplexní data, která musí být

54

analyzována a/nebo zpracovávána mohou obsahovat nepředvídanou kombinaci hodnot.

Podobné chyby může program sám odhalit, pokud jsou v něm zabudovány správné kontrolní

systémy.

Pokud je chyba dostatečně velká na to, aby se program nechoval správně, její

existence je zřejmá. Ovšem pokud je chyba malá, taková, která neovlivňuje chod programu,

ale pouze jeho výstup, může být její odhalení velmi obtížné, a to zejména v případech, kdy

nemůžeme ověřit, zda jsou výstupní data korektní.

Cílem tohoto kroku je určit příznaky chyby. Pozorování toho, co chyba způsobuje a za

jakých se objevuje okolností, velmi usnadní další kroky ladění.

Izolovat zdroj chyby

Tento krok je velmi často nenáročnějším krokem ladění. Měli bychom při něm zjistit,

která část systému způsobuje chybu. Naneštěstí zdroj chyby není vždy stejný s místem

výskytu příznaků chyby. Například, pokud jsou poškozena vstupní data, chyba se může

projevit až při vytváření výstupních dat nebo při spuštění určité akce, která pracuje s

poškozenými daty. To ale může být dlouho po načtení vstupních dat.

Tento krok obvykle vyžaduje opakované testování. Programátor by měl nejprve zjistit,

zda není poškozen vstup, následně, jestli je správně načten, správně zpracován. Opakovaným

testováním vstupů a výstupů je programátor (nebo debugger) schopen určit, na kterých

několika málo řádcích zdrojového kódů se chyba vyskytuje. Zkušený programátor je často

schopen odhadnout, kde se chyba vyskytuje a testovat pouze určitou část programu. Méně

zkušený programátor bude program zkoumat postupně, hledat místo, kde se chová jinak, než

očekával. Dalším způsobem hledání chyby je dělení programu na dvě části("binary search").

Tímto zjistíme, zda se chyba vyskytuje v dřívější nebo pozdější části programu.

Identifikovat příčinu chyby

Pokud jsme našli místo výskytu chyby, dalším krokem je zjištění příčiny chyby, ta

může zasahovat i do jiných částí programu.

Detailní obeznámenost se systémem je zásadní pro pro úspěšné odhalení chyby.

Zkušený programátor může odhalit, kde problém vzniká, ale pouze někdo, kdo zná program

do nejmenšíchj podrobností, může odhalit skrytou příčinu chyby. V některých případech

může být chyba externí: vstupní data jsou nesprávná. V jiném případě se může jednat o

logickou chybu, vstupní data jsou nesprávně zpracována. Další možností jsou nepředvídané

hodnoty, původní předpoklad byl, že dané proměné mohou mít poze určitý druh hodnot, což

se ve skutečnosti změnilo. Chyba může být i ve špatném propojení dat.

Určit způsob opravy

55

Pokud jsme zjistili původ problému, musíme určit způsob opravy. Detailní znalost

systému je nezbytná pro řešení každé chyby. Je to kvůli tomu, že oprava změní původní

chování systému, to může vést k dalším chybám nebo k odhalení dosud neodhalených chyb,

které se dosud neprojevily kvůli chybě právě opravené. Tyto problémy jsou většinou

způsobeny tím, že program začne využívat předtím netestovanou část zrdojového kódu, nebo

že začne pracovat za dosud netestovaných podmínek.

V některých případech je oprava jednoduchá a zřejmá. Jde hlavně o logické chyby,

kde byl již originální design chybný. Na druhou stranu, pokud zjistíme, že jde o zásadní

chybu, která zasahuje do velké části programu, oprava může být velmi složitá až nemožná

vyžadující přepsání celého programu.

Opravit chybu a testovat

Po provedení opravy je důležité systém testovat a zjistit, zda byla oprava úspěšná a

systém pracuje správně. Testování by mělo být prováděno ze dvou důvodů: (1) byla původní

chyba opravena? a (2) nevytvořili jsme další chybu způsobující nežádoucí chování programu?

Pro rozsáhlé systémy je dobré mít vytvořenou skupinu testů, které prověří celý systém

komplexně. Takové testování by mělo být prováděno po každé větší změně v systému. Pokud

je do systému přidána nějaká část, měl by se pro ní vytvořit test její funkčnosti a ten přidán ke

skupině již existujících testů.

Dialogy

Klíčová slova: Programování

Operační systém

Dialogy

Windows okna

Funkce, parametry

Každá aplikace v operačním systému Windows (a vlastně v libovolném grafickém

uživatelském rozhraní) je protkána řadou oken, pomocí nichž může uživatel zadat různá

nastavení v této aplikaci. Uživatel vede s aplikací pomocí takových oken v podstatě dialog.

Proto se taková okna nazývají dialogová okna. Typickým dialogovým oknem je například

dialogové okno Písmo v aplikaci MS-Word.

InputBox

56

slouží na přijetí vstupu. Syntax funkce je nasledovný:

InputBox(prompt[, title] [, default] [, xpos] [, ypos] [, helpfile, context])

Parametr prompt - slouží jako informace na to, aby uživatel věděl, jaký vstup má zadat

Parametr title - slouží stejně jako u predchádzající funkce na zobrazení textu na titulní liště

okna dialogu.

Parametr default - můžeme přednastavit takovou hodnotu, jakou si myslíme, že uživatel

najpravdopodobněj zadá, a tím mu ulehčíme práci

Pomocí parametrů - xpos a ypos můžeme nastavit souřadnice v jednotkách „twips“ místa na

obrazovce, kde sa dialog zobrazí.

Poslední dva parametry jsou stejné jako při predchádzající funkci.

Funkce MsgBox

funkce MsgBox slouží na zobrazení zprávy pro uživatela programu. Parametrem této funkce

je text výzvy, který funkce zobrazí v diaogovém okně. Kromě tohoto parametru má funkce

MsgBox další volitelné parametry, které můžeme, ale nemusíme uvést. V pomocníkovi je

syntax funkcie popsaný tak, že nepovinné parametry jsou uváděné v hranatých závorkách:

Syntax:MsgBox(prompt[, buttons] [, title] [, helpfile, context])

Parametr prompt -je již zmiňovaná výzva, která sa zobrazuje v dialogovém okně.

Parametr buttons -můžeme určit, které tlačítko bude obsahovat dialogové okno, které z nich

bude předvolené, ale také jaký obrázek se zobrazí spolu s tlačítky, a jak se bude chovat

dialogové okno. Tento parametr můžeme zadat jako součet preddefinovaných číselných

konstant.

Konstanty používáné u MsgBox-u

vbOKOnly – 0 - Zobrazí jen OK tlačítko

vbOKCancel – 1 - Zobrazí tlačítko OK a Zrušit

GetOpenFileName

Jistě znáte z windows standartní dialogy pro otevření, nebo uložení souboru

Syntax: Objekt.GetOpenFilename (souborový_filtr, index_filtru, titulek,text_tlačítka,více

násobný_výběr)

Parametry metod GetOpenFilename

Souborový filtr – určuje,co se zobrazí v rozbalovacím seznamu –Soubory typu Parametr je

tvořen párem řetězcu a specifikaci masky pro filtr. Části páru jsou od sebe oddělený čárkou

Standarní filtr - (pokud nebude zadán žádný jiný): Všechny soubory (*.*), *.*

Dialog pro zadávaní názvu souboru GetSaveAsFilename

Zobrazí dialog pro uložený souboru, ten však neuloží, místo toho vráti název souboru , včetně

cesty, který měl být uložen.

Syntaxe- Objekt.GetSaveAsFilename

(výchozí_název,souborový_filtr,index_filtru,titulek,text_tlačítka)

Dialog pro určení adresáře – Objekt FileDialog pouze u Office XP

57

Syntaxe - Objekt.FileDialog (FileDialogType)

Parametr FileDialogType určuje druh dialogu:

- msoFileDialogFilePicker – povoluje uživateli vybrat soubor

- msoFileDialogFolderPicker – povoluje uživateli vybrat složku

- msoFileDialogOpen – povoluje uživateli otevřít soubor

- msoFileDialogSaveAs – povoluje uživateli uložit soubor

58

11Postup návrhu relační databáze (konceptuální,

logické a fyzické schéma)

Má 3 části:

a) Konceptuální schéma

b) Logické schéma

c) Fyzické schéma

Konceptuální schéma:

Cílem je vytvořit E-R model, který je nezávislý na použitém SŘBD.

Postup:

1) Identifikace entit – popis jednotlivých položek databáze – Zaměstnanec, Pobočka,

Zákazník

2) Identifikace relací – vztahů mezi entitami + multiplicita vztahů (kardinalita)

3) Identifikace atributů entit – Jaké vlastnosti u entit sledovat a definice typů a omezení

atributu

4) Určení domén atributů – množiny hodnot, kterých můžou hodnoty atributu nabývat

5) Určení atributů pro kandidátní klíč – primární klíč a kandidátní klíče

6) Specializace (generalizace) – volitelná část – rozšíření E-R modelu o nadtřídy a

podtřídy

7) Kontrola redundance vztahů – přezkoumání vazeb 1:1 a odstranění redundantních

vazeb

8) Kontrola podpory uživatelských transakcí – popis transakcí, definice cest transakcí

9) Předložení návrhu a pohovor o něm se zadavatelem

Logické schéma:

Vychází z E-R modelu v konceptuálním schématu. Zahrnuje konkrétní SŘBD. Kontroluje

strukturu, integritu a podporu transakcí z hlediska tabulek.

1) Vytvoření tabulek

Binární relace 1:1, 1:N, M:N, Rekurzivní relace 1:1, 1:N, Povinná (Nepovinná)

participace na jedné (obou) stranách, Komplexní relace

2) Kontrola struktury tabulek

3) Kontrola podpory transakcí

4) Kontrola integritních omezení

5) Posouzení návrhu uživateli

59

Fyzické schéma:

Samotná implementace.

1) Návrh a implementace tabulek (CREATE TABLE)

2) Návrh reprezentace odvozených položek (SELECT, INSERT)

3) Návrh zbývajících integritních omezení (DBMS)

4) Organizace souborů a indexů

5) Návrh uživatelských pohledů (CREATE VIEW)

6) Návrh bezpečnostních mechanismů

7) Kontrolované zavedení redundance (porušení normalizace)

8) Vyladění systému

60

12ANSI‐SPARC model

Jedním z hlavních úkolů databázového systému je umožnit uživatelům abstraktní pohled na

data v databázi. Uživatel tedy nevidí detaily uložení a správu dat.

V 70 letech probíhá snaha o standardizaci terminologie a obecné architektury databázových

systémů. Výsledkem je model ANSI-SPARC, který se sice standardem v pravém slova

smyslu nestal, nicméně poskytuje základní pohled na některé funkce DBMS.

Model ANSI-SPARC rozlišuje tři základní úrovně pro abstraktní pohled na data:

Externí (úroveň pohledů) – popisuje, jaká data vidí jednotliví uživatelé.

Konceptuální úroveň (logická) – popisuje, jaká data jsou uložena v databázi

(strukturu dat) a jaké vztahy mezi nimi existují.

Fyzická úroveň (interní) – popisuje, jak jsou data skutečně uložena.

Hlavním cílem této tříúrovňové architektury je poskytnout nezávislost dat. Tu rozlišujeme na

logickou nezávislost dat a fyzickou nezávislost dat.

Logická nezávislost dat představuje skutečnost, kdy změna konceptuálního schématu

(přidání nebo odebrání entity, relace,…) nevyvolá nutnost změny externího schématu

(úroveň pohledů) nebo nutnost přepisu databázové aplikace.

Fyzická nezávislost dat představuje skutečnost, kdy změna interního schématu (fyzická

úroveň) nevyvolá nutnost změny konceptuálního schématu. Může se jednat například o

vytvoření indexu za účelem zvýšení výkonu.

61

13Datová integrita

Klíčová slova:

Integrita dat; doménová, entitová, referenční integrita; primární klíč; databázový systém;

entity; relace; kaskádování; parametry

V datovém modelu musíme zachytit i pravidla, pomocí nichž hotový databázový systém

zajistí, že skutečná fyzická data v něm uložená budou správná, přesná, platná a

věrohodná. Zajištění této věrohodnosti znamená, že data musí vyhovovat jistým omezením

integrity (omezujícím podmínkám), která pro ně byla definována.

Datová integrita se implementuje na několika různě podrobných úrovních:

1. Doménová integrita – stanovení oboru přípustných hodnot pro daný atribut; patří

sem volba správného logického datového typu, měřítka a přesnosti (např. maxim.

délky), povolení neznámých a neexistujících hodnot. V některých případech

definujeme omezující podmínky (např. ode dne po den) nebo použijeme seznam

platných hodnot (dny v týdnu).

doménové omezení je pravidlo, které definuje platné hodnoty daného

atributu

prvním krokem při definici doménových omezení bývá výběr logického

datového typu (např. „datum“, „obrázek“ … nic přesnějšího)

dále je vhodné definovat měřítko a přesnost číselného typu (nebo maximální

délku řetězcové hodnoty)

je nutné zvážit, zda smí daná doména obsahovat neznámé nebo neexistující

hodnoty (neznámá a neexistující hodnoty jsou rozdílné: př. víte, že doma

nemáte myčku na nádobí (neexistující hodnota), ale nevíte, zda myčku na

nádobí mají sousedi (neznámá hodnota)

na závěr je třeba popsat co nejkonkrétněji množinu hodnot reprezentovaných

určitou doménou (např. omezení datumu zadání objednávek od data otevření

obchodu, …)

62

všechna omezení je nutné zachytit co nejúplněji

2. Přechodová integrita – definuje stavy, kterými může určitý vektor hodnot

právoplatně přecházet (viz diagram vztahů – svobodný, ženatý, vdovec, rozvedený

atd.). Stav entity může kontrolovat jediný atribut (můžeme považovat za typ

speciální doménové integrity)

3. Entitová integrita – zajištění jedinečnosti záznamu na úrovni entity; nejčastěji

primárním klíčem, v některých případech může omezení zasahovat i do více

atributů např. DatumOdeslání musí být větší nebo rovno jako DatumObjednávky.

za entitové omezení lze považovat existenci primárního klíče – zajišťuje

pravidlo, podle kterého každou entitu musí být možné jednoznačně

identifikovat

integrita jednotlivého atributu se modeluje především definicí v určité

doméně (oboru hodnot), atribut v relaci zdědí veškerá omezení integrity

definovaná pro jeho doménu, která je možné dále zpřísnit

entitové omezení může zasahovat také do více atributů najednou (př.

DatumOdeslání musí být větší nebo rovno DatumuObjednávky)

4. Referenční integrita – má za úkol udržovat a ochraňovat vazby mezi relacemi, cizí

klíče se nesmí stát sirotky (žádný řádek v cizí tabulce nesmí obsahovat takovou

hodnotu cizího klíče, která nemá odpovídající záznam v primární tabulce).

Přerušení vazeb mezi relacemi znamená nespolehlivost nebo úplnou nefunkčnost

systému. K narušení referenční integrity může dojít případech, kdy se do cizí

tabulky přidá vektor hodnot s klíčem, který neodpovídá žádnému kandidátnímu

klíči v primární tabulce, při změně kandidátního klíče v primární tabulce a

odstranění záznamu v primární tabulce, na který odkazuje záznam v cizí tabulce.

V některých případech lze povolit kaskádovitou aktualizaci a kaskádovité

odstranění, eventuálně komplikovaným přeřazením dotčených záznamů.

63

5. Databázová integrita – pravidlo týkající se obsahu databáze, odkazujeme se na

více než jednu relaci; např. „Stav zákazníka nesmí být Přednostní, pokud během

posledních 12 měsíců neuskutečnil alespoň jeden nákup“.

6. Transakční integrita – přípustné manipulace s databází; procedurální charakter,

nejsou součástí datového modelu. Transakce je nedělitelná skupina určitých

operací, které se buďto musí všechny společně dokončit, nebo se nesmí dokončit

žádná z nich (např. převod na účet).

Integrita dat bývá zajišťována kontrolními součty, hashovacími funkcemi, samoopravnými

kódy, žurnálováním atd. V kryptografii a v zabezpečení informací všeobecně integrita

znamená platnost dat.V informatice a telekomunikacích má termín integrita dat i následující

významy:

Stav, kdy přečtená data jsou totožná s daty uloženými. Tzn. během uložení

(přenosu) dat nedošlo k jejich neočekávaným změnám.

Zajištění kompletnosti dat. Například osobní číslo patří nějaké osobě. Pokud

by osobní číslo nikomu nepatřilo, jedná se o osiřelá nebo nekompletní data.

Zachování dat pro jejich zamýšlené použití.

64

14Výběr dat z více tabulek (propojení tabulek)

Klíčová slova: Relační databáze, SQL, vnitřní spojení, vnější spojení.

Vazby mezi tabulkami

Jedním z hlavních rysů relačních databází jsou vazby mezi tabulkami. Představme si např., že

budujeme databázi obsahující katalog produktů a jejich objednávek. O jednotlivých

produktech budeme chtít uchovávat řadu údajů (název, popis, cena, dostupnost…), což budou

jednotlivé sloupce v tabulce. To stejné platí i u objednávek.

V tomto případě si musíme uvědomit, že neexistuje efektivní řešení, jak takovéto informace

zachytit v jedné tabulce. Pokud by jsme to udělali, v tabulce by se vyskytovaly údaje

k jednomu produktu, resp. objednávce opakovaně (redundance dat). Důsledkem toho se

s databází těžko pracuje, je pomalá a velká.

Řešením je rozdělit tabulku do dvou nebo více tabulek, kde každý záznam obsahuje svůj

jedinečný identifikátor (primární klíč). K propojení záznamů se pak využije tzv. cizí klíč, což

je sloupec obsahující hodnotu primárního klíče, s kterým je daný záznam svázán.

Ve výše zmíněném příkladě se jedná o nejobecnější vazbu N:N a údaje by tak měly být

rozděleny do tří tabulek, z nichž jedna bude obsahovat pouze informace o samotném

produktu, jedna informace o objednávce jako celku a třetí bude vazební. Vazební (průniková)

tabulka bude obsahovat pouze cizí klíče, kterými bude vytvořena vazba mezi produkty a

objednávkami.

Propojení tabulek

Vnitřní spojení

Tento typ spojení se využívá v případech, kdy chceme zjistit související záznamy. Existují

přitom dva základní způsoby k dosažení vnitřního spojení. Přepokládejme, že chceme znát

všechny objednané produkty v rámci určité objednávky (např. objednávka_id = 1):

a. select p.* from produkty p, produkty_objednavky po where

p.produkt_id = po.produkt_id and po.objednavka_id = 1

Objednávky *

objednávka_id

Produkty *

produkt_id

produkty_objednávky *

produkt_id

objednávka_id

65

V tomto případě se využívá kartézského součinu, kdy každý záznam z jedné tabulky je

spojen s každým záznamem z druhé tabulky. Následně pak všechny neexistující vazby

jsou odfiltrovány pomocí podmínky p.produkt_id = po.produkt_id.

b. select p.* from produkty p inner join produkty_objednavky

po on (p.produkt_id = po.produkt_id) where

po.objednavka_id = 1

Zde je využito klíčové slovo inner join, které vytváří spojení mezi tabulkami na

základě podmínky uvedené za on (podle).

Vnější spojeni

V případě výše uvedeného vnitřního spojení se do výsledné množiny dostanou pouze

produkty, které mají odpovídající záznam ve vazební tabulce. S tímto typem spojení si ovšem

vždy nevystačíme. Proto standard SQL definuje tzv. vnější spojení, které do výsledné

množiny zahrne všechny záznamy z určené tabulky, bez ohledu na výskyt ve vazební tabulce.

Existují tři varianty vnějšího spojení, tzv. LEFT JOIN, RIGHT JOIN a FULL JOIN (resp.

LEFT OUTER JOIN, RIGHT OUTER JOIN a FULL OUTER JOIN). Rozdíl spočívá v tom,

která z tabulek má být vybrána celá, zdali tabulka na levé straně od klíčového slova JOIN

(LEFT JOIN) nebo pravá (RIGHT JOIN) resp. obě zaráz (FULL JOIN).

Pro zjištění celkového počtu objednání jednotlivých produktů lze použít následující dotaz:

select p.produkt_id, count(po.objednávka_id) from produkty p

left join produkty_objednávky po on (p.produkt_id =

po.produkt_id) group by p.produkt_id

U produktů, které doposud nebyly objednány LEFT JOIN do druhého sloupce pro hodnotu

po.objednávka_id vygeneruje hodnotu NULL, která je posléze agregační funkcí

COUNT() interpretována jako 0.

CROSS JOIN

Výsledkem spojení typu CROSS JOIN je kartézský součin, kdy každý záznam z jedné tabulky

je spojen s každým záznamem z druhé tabulky a tak jsou vytvořeny všechny možné

kombinace.

select * from tabulka1 cross join tabulka2;

V praxi se tento typ spojování téměř nevyužívá, přestože jeho výsledek je totožný

s výsledkem spojení v klauzuli FROM, které se naopak k dosažení vnitřního spojení využívá

velice často.

select * from tabulka1, tabulka2;

NATURAL (OUTER) JOIN

66

Tento typ propojuje dvě zadané tabulky svázáním všech sloupců s totožnými názvy. Jsou-li

jedinými sloupci se stejnými názvy právě spojovací sloupce, lze použít:

select * from tabulka1 natural outer join tabulka2

JOIN USING

I v tomto typu propojení se využívají k propojení sloupce se stejnými názvy, nicméně použití

USING nám poskytuje možnost tyto sloupce vyjmenovat.

select * from tabulka1 join tabulka2 using(sloupce1);

Skládání dotazů

Mimo samotná propojení tabulek existuje ještě možnost skládání dotazů pomocí různých

množinových operací. Podmínkou je, že výsledné množiny jednotlivých dílčích dotazů musí

obsahovat stejné sloupce. Telegraficky se jedná o sjednocení (union), průnik (intersect), rozdíl

(minus).

67

15Skripty a dávky v T‐SQL, příkazy pro řízení toku

programu (větvění ve skriptech a dávkách)

Klíčová slova:

skript, dávka, proměnná, systémové funkce

Cíl:

Vysvětlení pojmů skript a dávky, použití příkazu USE ve skriptu, vysvětlení pojmu

proměnná, možné způsoby deklarace a přiřazení hodnot do proměnných. Vysvětlení několika

systémových funkcí

SKRIPTY

Skripty chápeme jako sekvenci příkazů, kterou jako skript můžeme definovat v okamžiku kdy

tuto sekvenci uložíme do souboru odkud je možné jej znovu načíst a spustit.

Všechny příkazy ve skriptu zpravidla pracují na jednom konkrétním úkolu – může to být

například vytvoření databáze, údržba systému (skripty pro zálohování), apod…

Se skripty se pracuje jako s ucelenou sadou příkazů. Znamená to, že buď provedeme celý

skript najednou nebo neprovedeme vůbec nic. Ve skriptu lze využívat systémové funkce

(globální proměnné), lokální proměnné, příkazy USE, INSERT, přořazovací příkazy, běžné

varianty příkazu SELECT, apod…

Příkaz USE ve skriptech

Využitím příkazu USE nastavujeme aktuální databázi. V rámci skriptu má tedy vliv na každé

místo, kde pracujeme s konkrétní databází (například modifikace dat v tabulce). Pracujeme-li

tedy v rámci skriptu s tabulkami v rámci konkrétní databáze, potom je použití příkazu USE

žádoucí. Stejně tak při provádění jakékoliv modifikace databáze.

V případě, že skript slouží k obecným účelům (nepotřebujeme pro jeho provádění využívat

konkrétní databázi) příkaz USE použít nemusíme, v některých případech ani nesmíme.

Příklad:

Nastavení aktuální databáze.

�USE Nazev_databaze

68

PROMĚNNÉ V SQL

V rámci tvorby skriptů můžeme použít i deklarace vlastních proměnných, které používáme

pro uložení hodnot, výpočty, předávání hodnot v rámci uložených procedur,…

Proměnná se označuje znakem @ a názvem proměnné. Tuto proměnnou je potřeba deklarovat

včetně určení datového typu a přiřadit do takto vytvořené proměnné hodnotu. Deklarované

proměnné bez přiřazení hodnoty se přiřadí hodnota NULL do doby než je naplněna konkrétní

hodnotou.

Syntaxe – dva možné způsoby deklarace

DECLARE @<název proměnné> <typ proměnné>,

@<název proměnné> <typ proměnné>,

@<název proměnné> <typ proměnné>

nebo také

DECLARE @<název proměnné> <typ proměnné>

DECLARE @<název proměnné> <typ proměnné>

DECLARE @<název proměnné> <typ proměnné>

Příklad:

/* Deklarace promennych */

declare @cena int,

@navyseni float

* Deklarace promennych */

declare @cena int

declare @navyseni float

Přířazení hodnoty do proměnné

Existují dva možné způsoby, kterými je možné naplnit deklarovanou proměnou. Využíváme

k tomu příkazy SET a SELECT.

69

Z funkčního hlediska jsou naprosto shodné, příkaz SELECT všask na rozdíl od příkazu SET

může převzít zdrojovou hodnotu také ze sloupce tabulky uvedeného v jeho výběrovém

seznamu.

Příklad:

/*Priřazení hodnot do proměnných - SET */

set @cena=100

set @navyseni=1.05

/*Prirazeni hodnot do promennych - SELECT */

use pohled

declare @cislo int

select @cislo = max(id) from majitel

Z toho plyne že:

- pro jednoduché přiřazení proměnné, kdy požadovanou hodnotu známe a tvoří ji

explicitní hodnota nebo jiná proměnná použijeme příkaz USE

- pro přiřazení hodnot založených na výsledku dotazu použijeme příkaz SELECT

Závěr

Dále je uveden skript, který ve své první části deklaruje dvě explicitní proměnné příkazem

SET, provádí přiřazení hodnot do těchto proměnných a provádí jednoduchý výpočet

s výpisem výsledků.

V této části skriptu není použit příkaz USE protože se neprovádí zásah do žádné databáze.

Druhá část skriptu používá pro přiřazení hodnoty do proměnné databázi Pohled a z tabulky

majitel vybírá ze sloupce ID maximální hodnotu, kterou přiřadí do deklarované proměnné.

Zde je nutné použít příkaz USE pro nastavení aktuální databáze a přiřazení provést příkazem

SELECT.

Je dobré si uvědomit, že tento uvedený skript se zpracovává jako celek. To znamená, že

pokud dojde v kterémkoliv místě skriptu k chybě, celý skript tzv. „zhavaruje“ a nebude

dokončen.

70

Skript

/* 1 část skriptu */

/* Deklarace promennych */

declare @cena int

declare @navyseni float

/*Prirazeni hodnot do promennych */

set @cena=100

set @navyseni=1.05

print 'Pùvodní cena produktu'

print @cena

print 'Navýšení ceny o 5%'

print @navyseni

set @cena=@cena*@navyseni

print 'Cena produktu po navýšení je rovna'+ ' ' + convert (varchar,@cena)

/* 2 část skriptu */

use pohled

declare @cislo int

select @cislo = max(id) from majitel

print ''

print 'Maximální ID v tabulce majitel je cislo'+ ' ' + convert (varchar,@cislo)

DÁVKY

Dávka je skupina příkazů T-SQL spojená do ucelené logické jednotky. V předchozím

souhrném příkladu jsme vytvořili skript, který se skládal z jedné dávky. Dávky vytvoříme

takovým způsobem, že skript rozdělíme pomocí příkazu GO do jednotlivých dávek, které se

zpracovávají samostaně.

71

Platí:

příkaz GO musí být napsán v rámci skritpu na samostatném řádku

vyvolá společnou kompilaci všech příkazů od začátku dávky

není příkazem jazyka T-SQL, ale tzv. zvláštním příkazem

každá dávka se v rámci skriptu zpracovává samostatně, znamená to tedy, že chyba

v jedné dávce nezabrání spuštění a provedení dávky jiné.

V rámci dávek však lze nastavit jisté závislosti – například pokouší-li se jedna dávka vyvolat

činnost, která je závislá nevykonání dávky předchozí.

Využití dávek

Oddělení operací, které musí proběhnout v určitém pořadí (z důvodu zajištění

referenční integrity atp..) Každá dávka se na server odesílá samostatně. Využívají se tehdy,

pokud potřebujeme něco vykonat před ostatními části skriptu nebo odděleně od nich.

Některé příkazy přímo vyžadují samostatné dávky, např:

CREATE DEFAULT CREATE PROCEDURE CREATE RULE CREATE TRIGGER CREATE VIEW

Pozor na správné nastavení implicitní databáze.

Na následující straně je provedeno rozdělení skriptu na tři dávky, kde se provede korektní

zpracování všech tří dávek. Následuje ukázka, stejného skriptu, kdy ve druhé dávce je

záměrně vytvořena chyba. Provede se tedy (dle výše uvedeného) zpracování pouze první a

třetí dávky. V tomto případě nezhavaruje celý skript právě díky tomu, že je rozdělen na

jednotlivé dávky.

Rozdělení skriptu na dávky – zpracování bez chyby

/* Deklarace promennych */

declare @cena int

declare @navyseni float

/*Prirazeni hodnot do promennych */

set @cena=100

72

set @navyseni=1.05

print 'Pùvodní cena produktu'

print @cena

print 'Navýšení ceny o 5%'

print @navyseni

set @cena=@cena*@navyseni

print 'Cena produktu po navýšení je rovna'+ ' ' + convert (varchar,@cena)

print 'Prvni davka je hotova'

go

use pohled

declare @cislo int

select @cislo = max(id) from majitel

print ''

print 'Maximální ID v tabulce majitel je cislo'+ ' ' + convert (varchar,@cislo)

print 'Druha davka je hotova'

go

use pohled

declare @text varchar(10)

set @text=(select jmeno from majitel where id=1)

print ''

print @text

print 'Treti davka je hotova'

Rozdělení skriptu na dávky – chyba ve druhé dávce

/* Deklarace promennych */

declare @cena int

declare @navyseni float

73

/*Prirazeni hodnot do promennych */

set @cena=100

set @navyseni=1.05

print 'Pùvodní cena produktu'

print @cena

print 'Navýšení ceny o 5%'

print @navyseni

set @cena=@cena*@navyseni

print 'Cena produktu po navýšení je rovna'+ ' ' + convert (varchar,@cena)

print 'Prvni davka je hotova'

go

use pohled

declare @cislo int

select @cislo = max(id) from majitel

/* Záměrná chyba – cislo není prevedeno na text */

print 'Maximální ID v tabulce majitel je cislo'+@cislo

print 'Druha davka je hotova'

go

use pohled

declare @text varchar(10)

set @text=(select jmeno from majitel where id=1)

print ''

print @text

print 'Treti davka je hotova

Závěrem

pochopení mechanismu skritů a dávek je klíčové pro provádění nejrůznějších funkcí

(uložené procedury, spouště, vytvoření kompletních databází)

74

oborem platnosti lokálních proměnných je vždy pouze jedna dávka. Pokud se na

proměnnou odvoláváme ve druhé dávce – i v rámci stejného skritpu – je nutné ji

znovu deklarovat a přiřadit jí hodnotu

pomocí dávek definujeme prioritu provádění jednotlivých částí skriptu

Systémové vestavěné funkce

Přikládám seznam některých systémových vestavěných funkcí, jež se Vám mohou hodit.

� @@CURSOR_ROWS – počet řádků aktuálního kurzoru

� @@CPU_BUSY - počet milisekund práce od posledního spuštění SQL Serveru

� @@DATEFIRST – vrátí nastavený první den týdne 1 – pondělí, 7 – neděle,

je možno nastavit SET DATEFIRST number

� @@DBTS – vrátí aktuální časové razítko (unikátní v rámci databáze)

� @@ERROR – číslo chyby po posledním příkazu T-SQL

� @@FETCH_STATUS – indikuje výsledek posledního použití FETCH

(0 – OK, -1 – konec, -2 – záznam není)

� @@IDENTITY – poslední hodnota identity vložená INSERT

� @@IDLE - počet milisekund nečinnosti od posledního spuštění SQL Serveru

� @@IO_BUSY - počet milisekund vstupních a výstupních operací od posledního spuštění SQL Serveru

� @@LANGID – vrátí číslo aktuálního použitého jazyka

� @@LOCK_TIMEOUT - počet milisekund po které bude systém čekat na zablokovaný prostředek

� @@NESTLEVEL – aktuální úroveň vnoření při provádění vnořených procedur

� @@OPTIONS – informace o volbách nastavených příkazem SET

� @@PACK_RECEIVED – počet vstupních paketů od posledního spuštění serveru

� @@REMSERVER – vrací číslo serveru, který vyvolal vnořenou proceduru

� @@ROWCOUNT – počet řádků dotčených posledním příkazem

� @@SERVERNAME – jméno serveru

� @@SERVICENAME – jméno služby SQL Serveru (MSSQLServer)

� @@TIMETICKS – počet milisekund jednoho tiku (31,25)

� @@TOTAL_ERRORS – počet chyb vstupu/výstupu od posledního spuštění

� @@TOTAL_READ - počet člení z disku od posledního spuštění

75

� @@TOTAL_WRITE - počet zápisů na disk od posledního spuštění

� @@TRANCOUNT – počet aktivních transakcí v aktuálním spojení

� @@VERSION – verze SQL serveru

76

16Pohledy, dočasné tabulky, uložené procedury

Pohledy

Pohledy si lze představit jako virtuální (logické) tabulky v databázi. Pohledy nám mohou

přinést řadu výhod. Jednou z nich je zpřehlednění práce s daty a sestavování dotazů. Dále

mají své velké uplatnění z hlediska ochrany dat, např. můžeme vytvořit pohled, který bude

mít stejný obsah jako tabulka záznamů o lidech ve firmě, s tím, že nebude ale obsahovat

sloupec RODNÉ_ČÍSLO. My jako správci systému nemusíme nastavovat právo na čtení

tabulky LIDÉ, ale dáme právo na čtení takového pohledu a máme zajištěno, že si rodná čísla

nepřečte žádná neoprávněná osoba.

Pohled nemusí být vytvářen pouze nad jednou tabulkou, ale můžeme pohledem tabulek spojit

více. A přesto, můžeme nad pohledy vykonávat standardní operace INSERT, DELETE,

UPDATE, SELECT a SQL server už zajistí správnou manipulaci s odpovídajícími

"fyzickými" tabulkami. Z hlediska práce s tabulkami se nám pohled (často nazývaný view)

jeví jako normální tabulka.

Pohled se vytváří příkazem CREATE VIEW, jehož syntaxe je následující:

CREATE VIEW název_pohledu [(názvy sloupců)] AS

SELECT ...

Zápis [(názvy sloupců)] použijeme, chceme-li nějakým způsobem změnit názvy sloupců.

Příklady pohledů

Máme tabulku LIDÉ v níž evidujeme údaje o zaměstnanci ve firmě. Obsahuje sloupce ID,

JMÉNO, PŘÍJMENÍ, RODNÉ_ČÍSLO, VZDĚLÁNÍ. Uživatelům budeme chtít zpřístupnit

údaje z této tabulky, vyjma rodných čísel:

CREATE VIEW lidé_bez_rc AS

SELECT id, jméno, příjmení, vzdělání

FROM lidé

Dále lze view použít pro změnu názvů i formátů sloupců. Vytvoříme pohled, který bude mít

stejnou strukturu jako tabulka LIDÉ, jediný rozdíl bude v tom, že JMÉNO a PŘÍJMENÍ bude

jako jeden sloupec s názvem CELÉ_JMÉNO:

CREATE VIEW lidé2 (id, celé_jméno, rodné_číslo, vzdělání) AS

SELECT id, příjmení+','+' '+jméno, rodné_číslo, vzdělání

FROM lidé

Poslední příklad uvedu pro případ tvorby pohledu skrz více tabulek. V naší firmě bude

skupina ekonomů, která má právo vědět, kolik má kdo základní plat, ale už nechceme, aby

měli přístup k osobnímu ohodnocení. Mějme tabulku LIDÉ a dále tabulku PLATY, která

obsahuje sloupce ID_OSOBA, ZÁKL_PLAT, OSOBNÍ, PŘÍPL_VEDENÍ. Pro ekonomy

zkonstruujeme následující pohled:

CREATE VIEW osoby_platy AS

SELECT id, jméno, příjmení, zákl_plat

77

FROM lidé, platy

WHERE lidé.id = platy.id_osoba

Dočasné tabulky

Jsou v podstatě normální tabulky, které jsou v databázi pouze dočasně. Jsou automaticky

odstraněny, jakmile se uživatel odhlásí nebo ukončí své připojení. Dočasné tabulky se vytváří

v databázi TEMPDB.

Používají se dvě různé syntaxe zápisu:

1. create table #tabulka1(

jmeno char(30),

rok int)

2. create table tempdb..tabulka2(

jmeno char(30),

rok int)

Znak # umístěny před názvem tabulky u první syntaxe představuje identifikátor pomocí něhož

se označuje dočasná tabulka. Každý z uživatelů tak může vytvořit vlastní soukromou tabulku

včetně aktualizování, vkládání a odstraňování záznamů.

Tabulka se odstraní bud zadáním příkazu: drop table #tabulka1

nebo se odstraní automaticky v okamžiku, kdy se uživatel, který ji vytvořil odhlásí z SQL

serveru.

Rozdíl mezi syntaxí 1 a 2

Zásadní rozdíl je v tom, že tabulka vytvořená pomocí druhé syntaxe nebude automaticky

odstraněna při odhlášení z SQL serveru, ale pro její odstranění musí být použít příkaz drop

table.

78

Příklad využití – např. dočasné uchování informací z dotazu pro další použití

create table #temp_CR (

jmeno char (30),

zeme_puvodu char(40),

styl char(20),

id_umelec int)

insert into #temp_CR select * from umelci where

zeme_puvodu='ČR'

select * from #temp_CR

79

Uložené procedury

Uložené procedury jsou uloženy přímo v databázi spolu s ostatními objekty. To tedy

znamená, že do databáze je možné umístit kromě údajů i část nebo i celou aplikační logiku

pro zpracování těchto údajů. To umožňuje jednodušší distribuci aplikace, přispívá ke

spolehlivosti, kdy aplikační logika je zabezpečená a zálohovaná stejně spolehlivě jako

samotné údaje. Uložené procedury se ukládají do databáze v předkompilované podobě.

Uloženou proceduru si můžeme představit jako blok kódu, kterému předáme nějaké

parametry. Výsledkem činnosti uložené procedury mohou být úpravy údajů v databázi,

odevzdání nějakého parametru např. výsledek výpočtu nebo vytvořený řetězec.

Uloženou proceduru vytvoříme příkazem CREATE PROCEDURE. Její základní syntaxe je:

CREATE PROCEDURE nazev_procedury <seznam parametrů>

AS

Programový kód

GO

Speciálním druhem uložené procedury je tzv. trigger (spouštěč), který je automaticky

vyvoláván v okamžiku, když dojde k určité nastavené změně dat v tabulce. Může být navázán

třeba na přidání nových dat, jejich aktualizaci či výmaz. Triggery se využívají pro kaskádové

zřetězení změn v souvisejících tabulkách. Jinými slovy se jedná o systém automatického

vyvolávání činností, které vedou k zachování integrity databáze. Za nevýhodu aktivačních

procedur lze považovat fakt, že při každé operaci musí server zjišťovat, zda se na ni neváže

nějaká procedura. Tím ztrácí čas a tolik žádaný výkon.

Za klady uložených procedur lze považovat:

Výkon v porovnání s posloupností standardních příkazů SQL, neboť příkazy jsou

v uložených procedurách obvykle předkompilovány. Při prvním provádění uložené

procedury je vytvořen prováděcí plán činnosti. Plán je po vytvoření uložen do

vyrovnávací paměti a následné opakování téže procedury je pak mnohem rychlejší než

provádění obdobných příkazů SQL.

Lze vykonat složitější operace, než bychom vykonali přímo pomocí SQL.

Nepřerušitelnost provádění procedury. Po jejím spuštění je procedura provedena

sekvenčně jako celek, i když má třeba vnitřní strukturu složitou. Správná konstrukce

procedur potom zajišťuje minimum kolizí s integritními omezeními.

80

Možnost nastavování a předávání parametrů umožňuje propojení více uložených

procedur, a tím vlastně vytvářet jakési dávkové programy.

Umožňují vytvořit další vrstvu zabezpečení databáze. Existuje totiž možnost zrušit

uživatelům veškerý přístup k tabulkám a pohledům a vytvoříit uložené procedury,

které mohou pracovat s těmito objekty databáze. Uživatelům pak stačí přidělovat

práva pro spuštění (execute) procedur.

Velká část aplikační logiky může být přesunuta na databázový server – díky uloženým

procedurám s vlastními proměnnými, podmínkami, cykly, popř. vyvoláváním

vestavěných funkcí databázového serveru.

Za nevýhodu uložených procedur lze považovat zejména nutnost správy procedur –

parametry, vlastnosti, vhodnost použití

81

17Transakce, spouště (triggery) a kurzory

Transakce

Zjednodušeně řečeno je transakce operací, resp. skupinou operací, která by měla jako celek

úspěšně proběhnout, nebo by veškeré změny provedené touto operací měly být anulovány.

Důvodů pro zrušení transakce, tedy pro její odvolání může být celá řada – nejčastěji se jedná

o nějakou chybu při provádění či o vědomý požadavek na zrušení uživatelem.

Druhým nejčastějším přínosem transakčního zpracování je fakt, že při určitém nastavení

ostatní uživatelé nevidí změny v databázi před jejich potvrzením tím uživatelem, který změny

provádí. Z tohoto pravidla ovšem existuje celá řada výjimek a mnohé platformy umožňují toto

chování ovlivnit.

Velmi často uváděným příkladem transakčního zpracování jsou finanční pohyby mezi

bankovními účty, pro které platí, že převáděná částka musí být správně z jednoho účtu

odepsána a na druhý připsána. Pokud by došlo k nějakému problému, vše se musí vrátit do

původního stavu, tedy do stavu před začátkem odepisování částky z prvního účtu.

Vyspělé databázové platformy nabízí pro transakční zpracování celou řadu prostředků, takže

se prakticky nemusíte o moc věcí starat – postačí vám "pouze" navrhnout vlastní logiku

zpracování (tedy správně určit, jak chcete, aby se aplikace chovala) a použít na vhodných

místech v aplikaci příkazy pro zahájení a ukončení transakce. Nejčastěji se pro potvrzení

transakce používá SQL příkazu COMMIT a pro odvolání ROLLBACK.

Transakce nám zajišťují kontinuitu a nedělitelnost změn.

Transakce proběhne buď jako celek nebo se transakce jako celek zruší.

Ošetření i chybových stavů, kdy dojde k technickým výpadkům a nekorektnímu

uzavření databáze.

Průběh transakce řídíme SQL příkazy SAVE POINT, COMMIT a ROLLBACK.

SAVE POINT pro_jistotu

UPDATE zbozi SET cena = cena * 1.05

Pod transakcí si můžeme představit příkaz nebo skupinu příkazů, které převedou databázi

(resp. data) z jednoho konzistentního stavu do druhého. Další definice říká, že transakce je

skupina příkazů, která se navenek tváří jako jeden příkaz.

82

Pokud budu provádět UPDATE jednoho sloupce velké tabulky, tak konzistentní stav je před

zahájením příkazu a po dokončení příkazu. V mezičase je obsah tabulky nekonzistentní – část

je modifikovaná, část nikoliv. Pokud je příkaz spuštěn v rámci transakce, tak prostředky

databáze je zajištěno, že uživatelé budou mít vždy přístup pouze ke konzistentním datům.

Dalším dnes již klasickou ukázkou je převod částky z účtu na účet.

BEGIN;

UPDATE ucty SET castka = castka - 100 WHERE ucet = 1234;

UPDATE ucty SET castka = castka + 100 WHERE ucet = 4321;

COMMIT;

Transakce zajišťují jednak bezpečnost – viz problém v případě výpadku po provedení prvního

příkazu UPDATE (pozn. vypařila by se částka 100), a jednak konzistenci dat – data v

okamžiku, kdy došlo k odečtu účtu, a ještě nedošlo k přičtení částky na druhý účet jsou

nekonzistentní. Pravidlo pro konzistenci by mohlo vypadat následovně (pro operaci MOVE):

celková částka na účtech je konstantní (pokud nedojde k přijetí nebo k odeslání určité částky

jinam).

Trigger

Co jsou triggery

V řadě informačních systémů, které běží nad nějakou databází, potřebujeme v případě vzniku

nějaké události, např. modifikujeme řádek v nějaké tabulce, automaticky spustit příkaz, který

provede nějaké operace. K tomuto účelu slouží triggery (z angl. trigger = 'spoušť'). V této

práci se seznámíte s jejich tvorbu a praktickým využitím. Sami uvidíte, že se jedná o mocný

nástroj, který nám může někdy usnadnit práci s daty.

Během práce s databázovým systémem může dojít k různým událostem. Např. z naší firmy

odejde zaměstnanec. My budeme při rušení jeho záznamu v tabulce LIDÉ chtít automaticky

zrušit relevantní záznamy v jiných tabulkách. Např. v tabulce PLATY budeme chtít odstranit

záznam, který příslušel danému pracovníkovi. Nebo v evidenci knihovny vyřazujeme nějakou

knihu, tj. rušíme její záznam v tabulce KNIHA, ale zároveň chceme, aby se nám vytvořil nový

záznam o této knize v tabulce VYŘAZENÉ_KNIHY. Nebo budeme našim zaměstnancům ve

firmě měnit průbežně platy, ale při každé změně platu budeme chtít uchovat informaci, jaký

plat dosud daný zaměstnanec chtěl. Tj. zcela automaticky budeme generovat tabulku

HISTORIE_PLATU, kde budou uloženy jednotlivé výše platů. Všechny tyto události bychom

mohli ošetřit na aplikační úrovni, ale databáze nám právě nabízí řadu takovýchto věcí plně

zautomatizovat, že se o ně dál nebudeme muset starat a bude v tabulkách zajištěna aktuálnost

informací.

Jak triggery funguji

83

Trigger je nástroj, který zajišťuje automatické provedení programu v jazyce SQL při vložení,

zrušení nebo změně záznamu v určité tabulce. Trigger může například zajistit, že:

před vložením nového záznamu do tabulky bude provedena kontrola jeho obsahu a

doplněny hodnoty některých sloupců;

po smazání záznamu se provedou následné akce;

při změně hodnoty určitého sloupce v záznamu se porovná stará a nová hodnota a na

základě jejich vztahu se provedou další akce.

Triggery zjednodušují tvorbu aplikací, protože přenášejí část práce databázové aplikace na

server. Umožňují centralizované definování pravidel platných pro informační systém.

Existuje-li například v podnikovém informačním systému tabulka zaměstnanců, lze pomocí

triggerů popsat, jaké všechny akce musí být provedeny při přijetí nebo propuštění

zaměstnance, změně platu nebo přeřazení do jiného oddělení. Tyto akce se naprogramují na

jednom místě, ale budou sloužit všem aplikacím, které manipulují s tabulkou zaměstnanců.

Dodržení pravidel pro údržbu evidence zaměstnanců pak bude zajišťovat server automaticky a

konzistence dat bude zajištěna bez ohledu na možné chyby v měnících se aplikacích.

Trigger je pojmenovaným objektem patřícím do databázové aplikace. Má tyto vlastnosti:

je svázán s určitou tabulkou a reaguje na změny v této tabulce;

reaguje na právě jednu z SQL akcí INSERT, DELETE nebo UPDATE, triggery

reagující na UPDATE mohou navíc specifikovat množinu sloupců, jejichž změna je

spouští; trigger se spouští také prováděním obdobných akcí při práci s formuláři;

provádí se buď před (BEFORE) provedením výše specifikované akce, nebo po ní

(AFTER);

pokud akce ovlivňuje více než jeden záznam, pak se může spouštět buď pro každý

ovlivněný (tj. vložený, zrušený nebo změněný) záznam zvlášť, nebo pro všechny

záznamy najednou;

může obsahovat podmínku, která se vyhodnotí před provedením triggeru a pokud není

splněna, trigger nebude spuštěn;

specifikuje akci (zapsanou v jazyce SQL), která bude automaticky provedena, jakmile

jsou splněny podmínky pro spuštění triggeru.

Při provedení konkrétní akce mohou být splněny podmínky pro spuštění více než jednoho

triggeru. V takovém případě jsou spuštěny po řadě všechny.

Provádění triggerů může měnit obsah databáze a tím spouštět další triggery. Spouštění

triggerů se může do sebe libovolně zanořovat.

Při provádění triggerů se nekontrolují práva (triggery se provádějí s maximálními právy). Aby

díky tomu nemohlo dojít k neoprávněnému přístupu k datům, může triggery vytvářet pouze

84

uživatel obsazený do role AUTHOR v aplikaci, do níž trigger patří. V zamčené aplikaci není

tedy možné triggery vytvářet.

INSERT a UPDATE triggery se nespouštějí při importu dat do tabulky. DELETE triggery se

nespouštějí při smazání tabulky jako objektu (při mazání záznamů samozřejmě ano).

Vytvoření triggeru

1) Trigger se tvoří pomocí příkazu CREATE TRIGGER.

2) Jméno triggeru musí být pro danou databázi jedinečné. To znamená, že nelze mít dva

shodně pojmenované triggery ani na dvou různých tabulkách. Zvykl jsem si názvy

triggerů začínat písmeny tr, abych je na první pohled odlišil od jiných objektů v

databázi (jako jsou uložené procedury).

3) U každého triggeru musí být uvedeno, před nebo po jaké akci je spuštěn. Možnosti

jsou BEFORE INSERT, BEFORE UPDATE, BEFORE DELETE, AFTER INSERT,

AFTER UPDATE, AFTER DELETE. V MySQL navíc platí omezení, že pro každou z

vyjmenovaných akcí smí existovat nejvýše jeden trigger. To mě trochu mrzí, protože v

praxi někdy bývá zapotřebí provést více souvisejících akcí a nejpřehlednější by bylo

umístit tyto akce do samostatných triggerů. Aby těch omezení nebylo málo,

neumožňuje MySQL definovat jeden trigger pro dvě akce najednou, což je v jiných

databázích obvyklé.

4) Každý trigger musí souviset právě s jednou tabulkou. V našem případě souvisí s

tabulkou bezpecna. Mimochodem - jestliže je tabulka odstraněna, jsou odstraněny i

všechny související triggery.

5) Tělo spouště v MySQL začíná klauzulí FOR EACH ROW a ta značí, že následující

akce bude provedena tolikrát, kolik je řádků ovlivněných akčním dotazem. Většinou

předem nevíte, kolik řádků bude ovlivněno, takže byste neměli spoléhat na to, zda a

kolikrát bude tělo triggeru provedeno.

6) Jak jsem uvedl již v minulém díle seriálu, triggery mají přístup k měněným datům.

Ten je reprezentován virtuálními tabulkami old a new. Jejich význam je ten, že tabulka

old obsahuje původní data (ta, která se mají mazat pomocí DELETE nebo ta, která se

upravují pomocí UPDATE) a tabulka new obsahuje konečná data (ta, která se vkládají

pomocí INSERT nebo ta, která budou v tabulce po provedení UPDATE). My jsme v

příkladu právě toho využili a data "schovali" do jiné tabulky.

7) Konečně, v triggeru lze využít i vestavěných funkcí. My jsme použili jednu funkci

vracející současný čas a další vracející právě aktivního uživatele. Díky tomu máme

kompletní přehled o tom, kdo a kdy data měnil.

Efektivita triggeru

Provedení akcí pomocí triggeru reagujícího na příkaz SQL je zpravidla efektivnější než

explicitní volání stejných akcí klientem. Nicméně v efektivitě provádění triggerů existují

rozdíly:

Nejefektivnější jsou triggery AFTER INSERT a BEFORE DELETE. Jejich provedení

neznamená pro server prakticky žádnou dodatečnou zátěž.

85

Dosti efektivní jsou také triggery AFTER DELETE a AFTER UPDATE. Jejich

provedení vyžaduje pouze vykopírování určitých řádků z databáze do transientních

proměnných.

Triggery BEFORE INSERT a BEFORE UPDATE poněkud snižují rychlost provádění

operací, protože nutí server, aby kvůli vytvoření správných transientních proměnných

prováděl operaci INSERT resp. UPDATE méně efektivním způsobem.

V řadě situací nehraje roli, zda se použije BEFORE nebo AFTER trigger. Pak lze využít výše

uvedených řádek k zefektivnění práce serveru.

Kurzory

Kurzor představuje speciální způsob práce s daty množinového tvaru, při němž nepracujeme

najednou s celou sadou záznamů, ale zpracováváme jeden záznam za druhým. Kurzory slouží

k načítání údajů z databáze do proměnných, které lze dále použít pří zpracovávání

programové jednotky. MySQL nyní umožňuje použití kurzorů pouze s příkazem SELECT.

Proměnná, do které chceme načtenou informaci uložit, musí být stejného datového typu a

délky jako sloupec, ze kterého informace pochází.

Rozdělení kurzorů

Implicitní kurzory

nejsou předem definované

SQL Server si je vytváří sám pro svoji potřebu pro příkaz SELECT, kde vracejí jen

jednu hodnotu, nebo pro příkazy INSERT, UPDATE, DELETE, kde nevracejí žádnou

hodnotu.

jsou použity přímo v těle triggeru / uložené funkce či procedury

smí obsahovat pouze SQL příkazy, které vracejí jen jeden řádek

Explicitní kurzory

jsou předem definované (uživatel, programátor)

mohou vracet více řádků

pracuje se s nimi jako se soubory. (deklarace) Nejprve je třeba kurzor otevřít, poté se

čtou data a na závěr se musí kurzor zavřít

Deklarace kurzoru

86

Deklarace se skládá ze dvou částí – nejdříve deklarujeme jméno kurzoru a následně SQL

dotaz:

declare Kurzor1 cursor for select * from majitel

Tato deklarace vytvoří kurzor s názvem Kurzor1 nad tabulkou majitel.

Otevření kurzoru

open kurzor1

Od tohoto okamžiku jsou k dispozici údaje, které jsou výsledkem výběru SQL dotazu.

Výběr údajů prostřednictvím kurzoru

Pro výběr údajů slouží příkaz FETCH, který načítá údaj z kurzoru a uloží ho do proměnných.

Po každém výběru údajů se kurzor automaticky přesune na následující záznam.

fetch next from kurzor1 into @Kid,@Kjm,@Kpr,@Kti

Zavření kurzoru

close Kurzor1

deallocate kurzor1

Obor platnosti

U kurzorů můžeme určit obor platnosti a to zda kurzor bude lokální (LOCAL) nebo globální

(GLOBAL).

declare Kurzor1 cursor LOCAL for select * from majitel nebo

declare Kurzor1 cursor GLOBAL for select * from majitel

Výchozí obor platnosti je globální. V praxi to znamená, že na globální kurzor, který jsme

vytvořili, např. v nějaké uložené proceduře se můžeme odvolávat i z ostatních uložených

procedur.

87

Druhy kurzorů

Kurzory pouze vpřed

výchozí typ kurzoru, při jeho procházení máme pouze jedinou možnost a to příkazem

FETCH NEXT se posunout na následující záznam.

declare Kurzor1 cursor for select * from majitel

open kurzor1

fetch next from kurzor1 into @Kid,@Kjm,@Kpr,@Kti

Kurzory rolovací

těmito kurzory můžeme libovolně přecházet mezi jednotlivými záznamy pomocí

následujících parametrů:

NEXT – přechod na následující záznam

PRIOR – přechod na předchozí záznam

FIRST – přechod na první záznam

LAST – přechod na poslední záznam

declare Kurzor1 cursor scroll for select * from majitel

open kurzor1

fetch last from kurzor1 into @Kid,@Kjm,@Kpr,@Kti

Příklady

Příklad 1

Use _Cocker

Vytvoření jednoduchého kurzoru - výpis dat z tabulky majitel po jednotlivých větách.

88

declare @Kid int

declare @Kjm varchar(15)

declare @Kpr varchar(20)

declare @Kti varchar(10)

declare Kurzor1 cursor for select * from majitel

open kurzor1

fetch next from kurzor1 into @Kid,@Kjm,@Kpr,@Kti

while @@fetch_status = 0

begin

print 'Identifikátor:'+ ' ' + cast(@Kid as varchar(5))

print 'Jméno:' + ' ' + @Kjm

print 'Příjmení:'+ ' ' + @Kpr

print 'Tituly:'+ ' ' + @Kti

print 'Hodnota systémové proměnné:' + ' ' +

cast(@@fetch_status as varchar(1))

print ' '

fetch kurzor1 into @Kid,@Kjm,@Kpr,@Kti

89

end

close Kurzor1

deallocate kurzor1

Systémová funkce @@FETCH_STATUS se aktualizuje při každém načtení řádku a

oznamuje nám, jak načtení dopadlo. Možné vrácené hodnoty:

0: načtení proběhlo úspěšně

-1: operace načtení selhala, nacházíme se před prvním nebo za posledním záznamem

kurzoru

-2: operace načtení selhala z důvodu chybějícího záznamu

Příklad 2

Vytvoření cvičné tabulky.

90

Use _Cocker

Delete from test

Create table test

(id integer not null,

jmeno varchar(10),

prijmeni varchar(15),

titul varchar(15))

go

Vytvoření jednoduchého kurzoru - vložení dat z tabulky majitel do cvičné tabulky test.

declare @Kid int

declare @Kjm varchar(15)

declare @Kpr varchar(20)

declare @Kti varchar(10)

declare Kurzor1 cursor for select * from majitel

open kurzor1

fetch next from kurzor1 into @Kid,@Kjm,@Kpr,@Kti

91

while @@fetch_status = 0

begin

insert into test values (@Kid,null,@Kpr,null)

fetch next from kurzor1 into @Kid,@Kjm,@Kpr,@Kti

end

close Kurzor1

deallocate kurzor1

select * from test

92

18Replikace dat (co je to replikace, plánování replikací,

proces publikování, typy replikací) Relační a

multidimenzionální model dat – vlastnosti, výhody a

nevýhody Multidimezionální databáze (OLAP

kostka), multidimenzionální úložiště dat

Replikace = Publikování distribuovaných dat.

O replikaci bychom mohli říci, že jde o nástroj pro distribuci dat mezi více servery. Ve své

podstatě se pak jedná o duplikaci (či synchronizaci) dat pro hladký chod více serverů.

Plánování replikací

Klíčové faktory plánování replikací:

Autonomie – Jedná se o úroveň nezávislosti serveru. Zde dochází k určení dat, která

budou replikována a ke stanovení četnosti jejich replikace.

Zpoždění – Jedná se o časový interval mezi aktualizacemi. Obvykle platí, že čím větší

je autonomie jednotlivých serverů, tím větší je i zpoždění. Tento faktor určuje

přípustnou dobu zpoždění.

Konzistence dat – O konzistenci dohovoříme při využití datové konvergence a

konzistence transakcí.

o Datová konvergence – na všech serverech budou nakonec stejné hodnoty

o Konzistence transakcí – výsledné hodnoty budou shodné, pokud byly všechny

transakce spuštěny na jediném serveru.

Konzistence schématu – Jedná se o dodržení přísnějších pravidel v případech, kdy

dochází ke změnám ve struktuře databáze.

Další náležitosti – Geografické umístění, typ spojení, přenosová šířka, …

Proces publikování

Replikaci lze popsat jako proces publikování

Vydavatel – zdrojová databáze, vlastník dat

Distributor – shromažďuje data

vydavatele dle transakčního

protokolu

Odběratel – příjemce dat

93

Klíčová komponenta Distributora je distribuční databáze obsahující všechny transakce

čekající na distribuci. Kopie distribuovaných dat je uložena u Odběratele a změny dat jsou

odesílány v periodickém intervalu. Občas bývají změny možné v i u Odběratele – nejen u

vydavatele.

Odběry

Odběry jsou označovány jako publikace a mohou obsahovat jeden či více článků. Ty

jsou tvořeny obvykle tabulkou či její částí. Může to však být i uložená procedura či

jejich skupina.

Odběratel si nemůže vybrat články, které bude přijímat! (Všechno nebo nic!)

Obsah článků není omezen jen na celou tabulku – možnost filtrovat:

o horizontální – horizontální partitioning (omezení řádků)

o vertikální – vertikální partitioning (omezení sloupců)

Typologie odběrů

Odběry se zasíláním (push subscription)

o Vydavatel určuje kdy

o Replikace plnou měrou ovládá vydavatel – doporučuje se udržovat co

nejmenší zpoždění

Odběry s vybíráním (pull subscription)

o Odběratel sám žádá aktualizaci

o Je možné povolit vyšší míru autonomie – odběratel určuje kdy

Odběratel

Typologie odběratelů:

Místní – Vydavatel je jediným serverem, který zná totožnost odběratele. Využívá se i

jako bezpečnostní mechanismus, či když je potřeba maximalizace autonomie

jednotlivých serverů.

Globální – Všechny servery znají odběratele. Užívají se především v prostředí více

serverů, kde chcete kombinovat data různých vydavatelů u jednoho odběratele.

Anonymní – Vydavatel tohoto odběratele vnímá, jen když je připojen. Obvyklé u

internetových aplikací.

Typy replikací

Možnost kombinací jednotlivých typů dle požadavků, které na ně klademe.

Snímková replikace

Princip: Ve zdrojové databázi je sejmut „snímek“ všech dat, která budou replikována a ten

pak nahradí data v cílovém serveru.

Replikační agent:

94

Snímkový – synchronizuje zdrojové a cílové tabulky. Převezme „snímek“

publikovaných dat a uloží data na Distributorovi.

Distribuční - Zodpovědný za přesun transakcí a snímků z Vydavatele k Odběratelům.

Může být umístěn u Distributora (obvykle push) nebo u Odběratele (obvykle pull).

Vhodné u serverů určených pro čtení a u serverů, ke kterým se připojujete občas jen občas

Slučovaná replikace

Princip: Změny dat provedené na všech serverech jsou sloučeny do sebe po jejich přijetí na

Vydavateli.

Vysoká úroveň autonomie, nejvyšší zpoždění, nebezpečí nižší konzistence transakcí.

Slučovací replikační agent – kopíruje změny za všech Odběratelů a aplikuje je na Vydavateli.

Následně zkopíruje všechny změny na jednotlivé odběratele.

Transakční replikace

Princip: Během této replikace dochází u Odběratelů jen k zapisování přírůstkových změn dat,

nikoliv celé tabulky. Veškeré změny v publikovaných článcích jsou sledovány a následně

replikovány. U Odběratele jsou všechny transakce prováděny ve stejném pořadí, v jakém byly

aplikovány u Vydavatele.

Možnost aktualizací téměř v reálném čase – minimalizace zpoždění

Replikační agent pro čtení protokolu – monitoruje transakční protokol a hledá změny.

Kopíruje transakce určené pro replikaci z Vydavatele na Distributora.

Distribuční agent – zodpovědný za přesun transakcí z Distributora na jednotlivé Odběratele.

Relační a multidimenzionální model dat – vlastnosti, výhody,

Relační model dat

Ač je informatika svým způsobem nová vědní oblast, byl relační model definován již v roce

1969 doktorem Coddem. Tento model udává jakým způsobem jsou organizována data. Data

se shromažďují do takzvaných entit(tabulek), které jsou základním kamenem relační databáze.

Tabulka je struktura záznamů s pevně stanovenými položkami(atributy). Každý atribut je

definován názvem, type a rozsahem. Název relační vystihuje podstatu tohoto modelu, mezi

jednotlivými entitami totiž mohou vznikat vazby, takzvané relace. Aby tyto relace mohly

vzniknout je třeba aby obě tabulky obsahovaly stejný sloupec dat. Dle relační teorie lze

pomocí základních operací (sjednocení, kartézský součin, rozdíl, selekce, projekce a spojení)

uskutečnit veškeré operace s daty a ostatní operace jsou již jen kombinacemi těchto pěti.

Vlastnosti

symetrický přístup k datům

S daty se pracuje pomocí relačního kalkulu a algebry

95

Pro omezení redundance dat, máme k dispozici funkce pro normalizaci relací

použití u jednoduchých transakcí

postavené na použití primárního klíče – jednoznačného záznamu každé tabulky

Výhody

jednoduchost návrhu a s tím související pořizovací náklady

podpora napříč celým IT spektrem

rychlost operací a menší náročnost na hardware

Nevýhody

nebere v úvahu veličinu času

nelze aplikovat u obtížnějších návrhů

při větším počtu tabulek roste náročnost dotazů k vyhledání potřebných údajů

Multidimenzionální model dat

Na rozdíl od relačního modelu je základním stavebním kamenem krychle, která je tvořená

vícero dimenzemi. Pod pojmem dimenze si můžeme představit pohled, ze kterého se na daná

data díváme a kde výsledkem je průnik takovýchto dimenzí. Na rozdíl od jednoduchosti

relačních databází, představuje tento model pro výpočetní jednotku náročný proces z důvodu

průchodu velkého množství dat. Uspořádání dimenzí se obvykle provádí pomocí hierarchií,

mapováním sloupců v relačních databázích.

Vlastnosti

některé z výpočtů (často opakované) jsou prováděny dopředu za účelem úspory času

primárním cílem je rychlost přístupu k datům a nedbá se tolik na zachování

redundance dat

tabulky dimenzí obsahují velké množství dat

Výhody

bere v úvahu veličinu času

větší přehlednost, lepší pro použití u modelu s vyšším obsahem dat

výborné schopnosti pro modelování a prognózy

jednodušší údržba, data se ukládají tak jak se zobrazují

Nevýhody

vyšší nároky na hardware

vyšší náklady při budování takového modelu

96

náročné na prvotní analýzu a návrh

Multidimenzionální databáze

(rok 2009 - Příkazy pro řízení toku programu - větvění ve skriptech a dávkách)

Klíčové výrazy: multidimenzionální databáze, OLAP, MOLAP, ROLAP, HOLAP, vytvoření

kostky

Tyto databáze slouží jako podklad pro získání sumarizovaných a agregovaných dat k podpoře

strategického rozhodování, plánování a řízení.

Do multidimenzionálních databází vkládáme upravená a vyčištěná data – používáme převážně

nenormalizované tabulky, které rozdělujeme na tabulky faktů a tabulky dimenzí.

Výsledkem takovéto agregace a analýzy dat je obvykle multidimezionální datová struktura –

kostka (OLAP kostka).

Nástroje OLAP (Online Analytical Processing) poskytují vizualizované zobrazení výsledků

analýz, kde druh analýzy si volí sám uživatel. OLAP je volně definovaná řada principů, které

poskytují dimezionální rámec pro podporu rozhodování.

Multidimenzionální model

Výhody:

- rychlý komplexní přístup k velkému objemu dat

- přístup k multidimenzionálním a relačním datovým strukturám

- možnost komplexních analýz

- silné schopnosti pro modelování a prognózy

Nevýhody:

- problémy při změně dimenzí, bez přizpůsobení časové dimenze

- vyšší nároky na kapacitu úložiště

97

Můžeme ji chápat jako ekvivalent tabulky v relačním datovém modelu. Data se nacházejí

v průnicích jednotlivých dimenzí. Dají se analyzovat data např. jen za určité časové období

např. výsledky reklamní kampaně za období.

Multidimezionální modely můžeme dále rozdělit:

Multidimezionální OLAP (MOLAP)

- Multidimezionální on-line analytické zpracování. Data se získávají buď z datového

skladu nebo z operačních zdrojů. Mechanismus MOLAP potom uloží analytická data

ve vlastních datových strukturách a sumářích.

Relační databázový OLAP (ROLAP)

- Relační on-line analytické zpracování dat získává data pro analýzy z relačního

datového skladu. Tato data se z relačních databází po zpracování předkládají uživateli

jako multidimenzionální pohled. Data a metadata se ukládají jako záznamy v relační

databázi – data zůstavjí uložena v relačních databázích, nedochází k redundanci.

Hybridní OLAP (HOLAP)

- Kombinace obou předchozích úložišť, kdy se využívají výhody jednotlivých typů a

tím se eliminují jejich nevýhody. Data zůstavají v relačních databázích a agregace se

ukládají do multidimenzionálních struktur.

98

19Datový sklad – principy a vlastnosti datového skladu,

metody budování datového skladu

Klíčová slova: dimenze, fakta, datový sklad, OLAP

Datový sklad - strukturované úložiště údajů

Definováno mnoha způsoby, většinou neformálně:

Databáze sloužící k podpoře rozhodování, která je uložena odděleně od operační databáze

Podpora pro zpracování informací poskytnutím platformy sloučených historických dat pro analýzu

Klasický vs. Datový sklad

Klas.: Ukládáme za účelem rychlé expedice

Dat.: Ukládáme za co nejdelší období…

Porovnání vlastností

Vlastnost Klasická DB Datový sklad

Čas odezvy ms - s s - hod

Operace DML, např. SQL Jen čtení, zápis

Původ dat 30 – 60 dní Snímky za čas.

úsek

Organizace dat Podle aplikace Podle předmětu,

času

Velikost Malá až velká Velká až velmi

velká

Zdroje dat operační, interní operační, interní,

externí

Činnosti Procesy Analýza

Požadavky na datový sklad

Databáze navržená pro analytické dotazy

Možnost integrovat data z více aplikací

99

Častá operace čtení z databáze

Interaktivní, jednoduché a dlouhodobé využití bez nutnosti výpomoci IT odborníků

Nahrání dat po určité časové periodě

Možnost využití současných i historických dat

Možnost spustit dotaz a získat výsledek on-line

Možnost získat libovolnou tiskovou sestavu

Znaky datových skladů

Subjektová orientace

Data jsou organizována podle hlavních subjektů (zákazník, výrobek, apod.)

Integrovanost

Údaje týkající se konkrétního předmětu se ukládají pouze jednou -> jednotná

terminologie, jednotky veličin

Časová variabilita

Čas = klíčový atribut

Časový horizont datového skladu je zpravidla podstatně delší než u operační

databáze

o Operační databáze: pouze současně aktuální data o Data v datovém skladu: poskytují informace z historické perspektivy (např.

posledních 5-10 let) Každá klíčová struktura v datovém skladu

o obsahuje časový element

o klíč u operačních dat nemusí vždy obsahovat časový element

Neměnnost

Fyzicky oddělené uložení dat transformovaných z operačních databází

V datových skladech se data většinou nemění ani neodstraňují, jen se přidávají –

manipulace s daty je tedy jednodušší.

o Jen dva typy operací: vkládání dat a přístup k datům

Zdrojová data

Produkční data

Data získaná z různých operačních DB podniku pomocí jednoznačných dotazů

Interní data

Data uložená v privátních souborech (zpravidla XLS) zaměstnanců organizace

Archivní data

Jeden ze základních předpokladů úspěšné analýzy – jde většinou o velká kvanta

dat

Externí data

100

Data z různých zdrojů, která mohou být pro organizaci užitečná

Místo přípravy dat

Místo, kde probíhá tzv. příprava údajů – fáze ETL (mezistupeň mezi vstupními daty a

datovým skladem)

Může být i součástí datového skladu

Místo speciálně k tomuto účelu určené

Uložení dat

Jde o oddělené „skladiště“ pro uložení velkého množství především historických dat

Je navrženo pro analýzu, ne pro rychlý přístup k datům

Předání informace

Poskytuje informace pro různé uživatele

Začínající uživatelé: tiskové sestavy, jednoduché dotazy

Běžní uživatelé: statistická analýza, různá zobrazení dat, předdefinované dotazy

Pokročilí uživatelé: provádí multidimenzionální analýzu, formuluje vlastní OLAP dotazy, používá exekutivní IS (data mining…)

Příprava údajů – etapa ETL

Klíčová úloha správy datového skladu

ETL = Extraction, Transformation, Loading

Extrakce – výběr dat různými metodami

Transformace – ověření, čištění, integrace a časové označení dat

Loading – přesun dat do datového skladu

Hlavní cíl: centralizace údajů

o Nutné především proto, aby v datovém skladu byla dostatečně kvalitní data

Nikdy nekončící proces (neustále nutnost aktualizovat).

Hlavní úkoly ETL procesu

Určit data, která mají být uložena v datovém skladu

Určit zdroje dat, interní i externí

Příprava mapování mezi zdrojovými a cílovými daty

Stanovení pravidel pro extrakci dat

Určit pravidla pro transformaci a čištění dat

Plán pro agregaci tabulek

Návrh oblasti přípravy dat

Napsat procedury pro nahrávání dat

ETL pro tabulky dimenzí a faktů

101

Návrh datového skladu

1. Volba schématu datového skladu

2. Návrh celkové struktury datového skladu

3. Návrh dimenzí

4. Návrh tabulky faktů

5. Návrh transformací vstupních dat na data výstupního datového skladu

Návrh celkové struktury datového skladu

Zákazník

Čas

Produkt

102

20Příprava údajů pro datový sklad – fáze extrakce,

transformace a zavedení údajů Analýza OLAP – fakta

a dimenze, schémata tabulek dimenzí, operace OLAP

analýzy Úvod do problematiky získávání znalostí z

databází (data mining) – typy znalostí, kroky procesu

získávání znalostí

DEFINICE

Zkratka ETL pochází ze slov Extract, Transform and Load. Jde o označení procesů, které

firmám dovolují brát data z mnoha zdrojů, přeformátovat je, vyčistit a nahrát do společné

databáze, do datového tržiště nebo do datového skladu. Zde mohou sloužit jako podklad pro

následnou analýzu nebo jako přímá podpora nějakého obchodního procesu.V zařízeních

zapojených ve firemních počítačových sítích se zpravidla nachází množství cenných dat a

zaměstnanci většiny firem si to dnes už uvědomují. Problémem ovšem je, že uvedená data je

často nezbytné přesunout do jiné destinace a současně provést jejich přeformátování například

v okamžiku, kdy je třeba poskytnout informace z jedné obchodní aplikace aplikaci další,

případně když je třeba sebrat data pro datový sklad, kde poslouží pro další analýzu.Hlavním

problémem je skutečnost, že data leží v mnoha druzích heterogenních systémů, a tedy v řadě

odlišných formátů. Například systém CRM může definovat zákazníka jedním způsobem,

zatímco účetní systém toho samého zákazníka často vidí zcela odlišně.K řešení tohoto

problému používají firmy software označovaný zkratkou ETL (Extract, Transform and Load),

který zahrnuje funkce čtení dat z jejich zdrojů, jejich vyčištění, unifikované zformátování a

zápis do cílového úložiště pro další využití.Data, se kterými procesy ETL pracují, mohou

pocházet z libovolného zdroje z mainframové aplikace, z aplikace ERP, z nějakého nástroje

CRM, z prostého souboru, z tabulky Excelu nebo dokonce z fronty zpráv na serveru.

Získání dat

"Extrakce dat může být prováděna prostřednictvím JDBC (Java DataBase Connectivity),

ODBC (Open DataBase Connectivity) Microsoftu, za použití nějaké proprietární technologie,

případně prostřednictvím tvorby běžných textových souborů," říká Mike Schiff, analytik

konzultační společnosti Current Analysis.Po extrakci jsou data transformována nebo

modifikována v závislosti na zahrnuté specifické obchodní logice tak, aby mohla být

přesunuta do cílového úložiště. V praxi existuje množství různých požadavků na realizaci

těchto proměn. Některá data mohou vyžadovat pouze přeformátování, většina operací ETL

však zahrnuje rovněž vyčištění dat vyřazující případné duplicity a zajišťující

konzistenci."Jednou z věcí, které tento druh softwaru provádí, je prohlížení jednotlivých

datových záznamů a aplikování pravidel pro konzistentní konverzi obsahu do formy

požadované cílovým úložištěm nebo aplikací," vysvětluje Schiff. Například kategorie

103

"muž" může být reprezentována třemi odlišnými systémy, jako M, muž a 0/1. Software

ETL by měl rozpoznat, že tyto položky znamenají to samé, a konvertovat je do stejného

formátu.Navíc může proces ETL zahrnovat standardizaci jmenných a adresových polí,

kontrolu telefonních čísel nebo rozšíření záznamů o další pole obsahující demografické

informace nebo jiná data z dalších systémů.

Příklad

Harriet Frymanová, ředitelka produktového marketingu kalifornské společnosti Informatica,

nabízí následující příklad: Řekněme, že zákazník provozuje aplikace Oracle financials a

PeopleSoft HR. K tomu používá aplikaci SAPu pro řízení výroby. A potřebuje přistupovat k

datům každého z těchto systémů, aby mohl realizovat elektronicky kompletní proces od

objednávky po zaplacení zboží. To bude po firemním softwaru ETL vyžadovat, aby

extrahoval data z původních systémů, což ale není ve všech případech tak snadné, jak to na

první pohled vypadá. V případě získání dat ze zmiňované aplikace SAPu to například bude

vyžadovat napsání proprietárního kódu v ABAPu, aby mohly být extrahovány informace o

dodání a o objednávkách.Jakmile jsou data z každého zdroje namapována, dojde k

transformacím, čištění a uspořádání dat tak, aby mohla být složena dohromady. Zde už jsou

příjemci provázáni s fakturačními informacemi a podobně. Po novém uspořádání jsou data

transportována a nahrána do datového skladu pro analýzu tady lze například zjistit dobu

potřebnou pro uspokojení každé objednávky nebo celkový objem objednávek, jejich cenu a

podobně.Podle Frymana zákazníci využívají ETL nejen pro aktivity související s datovými

sklady nebo s procesy business intelligence; dle jeho slov tímto způsobem rovněž realizují

přesun dat z jednoho operačního systému do druhého například z toho, na kterém běží systém

ERP, do toho, kde se nachází aplikace CRM.

Jediná realita

"ETL dovoluje týmům firemních uživatelů pracovat s jedinou verzí reality," říká Chet

Phillips, ředitel IT pro oblast business intelligence společnosti Motorola. Jeho firma používá

ETL pro naplnění svých datových skladů pořízených od firmy Informatica."ETL dovolilo

Motorole shromáždit data z 30 rozdílných systémů používaných ve výrobě a poslat je do

jejího globálního datového skladu systému SCM k analýze, za co firma celkově utrácí a

kolik," říká Phillips."V minulosti společnosti, které pracovaly na projektech datových skladů,

často používaly pro realizaci procesů ETL vlastní kód," vysvětluje Schiff. Nicméně dokonce i

ty z nich, kterým se podařila úspěšná implementace, zjistily, že zdrojové datové formáty a

validační pravidla aplikovaná na sebraná data vyžadují, aby byl kód ETL průběžně měněn a

udržován. A firmy zažívaly problémy, když přidávaly další systémy a zvětšoval se objem dat.

U doma na koleně vyrobených ETL řešení byla závažným problémem chybějící

škálovatelnost.

104

Od koho

K výrobcům balíků systémů ETL patří společnost Microsoft, která nabízí služby pro

transformaci dat spolu se svou databází SQL Server, Oracle zahrnul některé schopnosti ETL

do své databáze a IBM nabízí komponentu DB2 Information Integrator ke svým řešením

datových skladů. Existují také další výrobci, kteří dodávají příslušné nástroje. Patří k nim

například Informatica, Ascential Software z USA nebo kanadská společnost Hummingbird.

Software od těchto výrobců může podle Schiffa nabídnout integraci pro širší škálu

heterogenních aplikací a datových struktur.

105

Analýza OLAP – fakta a dimenze, schémata tabulek dimenzí,

operace OLAP analýzy

Klíčová slova: OLAP analýza, dimenze, operace

Definice pojmů:

OLAP (on-line analytical processing) znamená okamžité zpracování dat, nebo také pružné

(rychlé) zpracování dotazů a analýz. Typicky se OLAP využívá pro analýzu velkého množství

údajů. Výsledkem analýzy jsou souhrny a reporty, které slouží jako podklady pro podporu

rozhodování, ať už v oblasti řízení firmy, řízení ekonomických a technologických procesů a

podobně.

Základní typy operací analýzy OLAP:

Drill–down – umožňuje uživateli ve zvolených instancích jisté agregační

úrovně nastavit nižší (jemnější) agregační úroveň.

Roll–up – jde o opak předešlé operace. Ve zvolených instancích jisté agregační

úrovně nastavuje vyšší (hrubší) agregační úroveň.

Pivoting – umožňuje „otáčet“ datovou krychlí, tj. měnit úhel pohledu na data

na úrovni presentace obsahu datového skladu.

Slicing – dovoluje provádět řezy datovou kostkou, tj. nalézt pohled, v němž je

jedna dimenze fixována v jistých instancích jisté agregační úrovně. Jinými

slovy tato dimenze aplikuje filtr na instance příslušné agregační úrovně dané

dimenze.

Diviny – je obdobou „slicingu“, jenž

umožňuje nastavit takový filtr pro více dimenzí.

Architektura OLAP systému:

1. spodní vrstva – „Datový sklad“ – server skladu, na

106

kterém jsou uloženy relační databáze.

2. prostřední vrstva – „Aplikační“ –

zahrnuje OLAP server, který obvykle

implementuje ROLAP nebo MOLAP.

3. vrchní vrstva – „Prezentační“ –

klient – obsahuje nástroje pro

provádění dotazů a vytváření zpráv a

analýzy, dále zahrnuje nástroje určené

pro analýzy trendu, predikce, apod.

Datová krychle a dimenze:

Datové krychle OLAP (Cube) představují výkonný nástroj pro vytváření sestav a pro

komplexní OLAP analýzu dat. Obsahují informace o úkolech, zdrojích, projektech,

přiřazeních, problémech, rizicích a závazcích. Jsou základním stavebním kamenem

multidimenzionálních databází, nad kterými se OLAP analýzy provádí.

Krychle může mít na rozdíl od běžného fyzikálního modelu více dimenzí (až 64). Dimenze

kostky reprezentují rozdílné

kategorie pro analýzu dat. Typickými kategoriemi jsou čas, geografické umístění nebo různé

výrobkové řady.

Dimenze jsou obvykle uspořádány do hierarchií tak, že mapují sloupce v relačních

databázích. Hierarchie dimenzí jsou seskupovány do úrovní obsahujících hodnoty dané

dimenze.

Schémata tabulek:

Hvězda

Jediná tabulka faktů a pro každou dimenzi jedna dimenzní tabulka

Nezachycuje přímo hierarchii

107

T

i

m

e

p

r

o

d

c

u

s

t

c

i

t

y

f

a

c

t

date, custno, prodno, cityname, sales

108

Vločka

Reprezentuje hierarchii dimenzí přímo přes normalizované tabulky

Snadné pro údržbu a šetří místo

Člen rodiny

Čas

109

Souhvězdí

Více tabulek faktů, které sdílí mnoho tabulek dimenzí

Rezervace a Pokladna mohou v hoteliérství sdílet mnoho dimenzí

Produkt

metrika

Cizí klíče

T

i

m

e

p

r

o

d

f

a

c

t

110

Úvod do problematiky získávání znalostí z databází (data mining)

– typy znalostí, kroky procesu získávání znalostí

Klíčová slova: data mining, dolování, asociační pravidla, shlukování, klasifikace,

predikce

CO JE TO DATA MINING?

Data mining není žádná aplikace nebo nástroj. Definic můžeme najít více, ale většinou se

shodují v tom, že jde o „netriviální proces zjišťování platných, neznámých (skrytých),

potenciálně užitečných a snadno pochopitelných závislostí v datech“. Ve většině případů ve

velkém objemu dat. Metody data miningu jsou založeny na statistice, nových poznatcích z

umělé inteligence či strojového učení. Jedná se o metody netriviální, které však mají společné

to, že se snaží zjištěné výsledky prezentovat formou co možná nejpřístupnější koncovému

uživateli. Jedná se například o shluky dat s podobnými charakteristikami, rozhodovací stromy

nebo o jednoduchá pravidla.

KROKY PROCESU ZÍSKÁVÁNÍ ZNALOSTÍ

1. Definice problému:

Nejprve je třeba definovat oblast, která je pro management zajímavá a je řešitelná pomocí

data miningu. Dále je třeba specifikovat, co hledáme, co chceme předvídat a na základě čeho.

2. Příprava dat:

date, custno, prodno, cityname,

r

e

g

i

o

n

Hotels

Travel

111

Je třeba definovat datové zdroje, které by měly být konzistentní a měly by obsahovat čistá

data. Data v primárních systémech mohou být uložena v mnoha různých formátech na mnoha

různých místech společnosti. V datech se mohou vyskytovat různé chyby typu „zákazník

nakoupil zboží předtím, než se narodil“, „prodej se realizoval v obchodě, který ještě

neexistoval“, …. Tyto možné nekonzistence v datech je třeba odhalit a odstranit. Pokud ve

firmě existuje datový sklad, který požadovaná data obsahuje, je tento krok výrazně urychlen.

V datovém skladu by se měly nalézat už vyčištěná a konzistentní data. Pokud není datový

sklad dosud zaveden, bývají právě data miningové problémy dobrým důvodem, proč ho

zavést. Na čistých datech se provádějí dále transformace do tvaru vhodného pro použití data

miningu.

3. Profilování a popis dat:

Než se lze pustit do vytváření a testování modelů, je potřeba plně rozumět připraveným datům

a zkontrolovat je. Zjistí se charakteristiky hodnot jednotlivých atributů, statistické parametry

jako: minima, maxima, průměry, odchylky atributů, rozložení dat. Poté lze zodpovědně říci,

zda připravená jsou bez vady, a případně navrhnout opravu dat.

4. Vytváření modelu:

Následuje iterativní proces tvorby miningového modelu a jeho kontroly (viz následující

kapitola), kdy se hledá co nejlepší možná metoda a její parametry. Data se zde rozdělují na

„učící“ a „testovací“. Na základě učících dat se data miningová metoda „naučí“ předpovídat

to, co chceme, a na testovacích datech se potom zkouší, jak dobře je tento model schopný

predikce a vhodný k nasazení. Data lze rozdělit náhodně, nebo třeba podle času, kdy se model

nechá naučit na prodejích za půl roku a poté je otestován na datech za poslední měsíc.

Znalosti dat z předchozího kroku velmi pomůžou při vytváření modelu.

5. Ověřování modelu:

Předtím, než je model převeden do produkčního prostředí, je dobré otestovat, jak dobře je

schopen provádět predikce. Lze také postavit takových modelů, které odpovídají

definovanému problému a připraveným datům, více, porovnat je mezi sebou a najít ten

nejvhodnější.

Pokud si žádný model nevede nejlépe, je potřeba vrátit se k předchozím kroku a vytvořit jiný

model, nebo předefinovat původní problém.

6. Uvedení modelu do praxe:

Vytvořený a ověřený model je pak uveden do praxe a na jeho základě lze vytvářet predikce,

podle kterých lze poté přijímat obchodní rozhodnutí. Lze například vyplnit sloupec nějaké

tabulky na základě predikcí modelu, na základě modelu rozdělovat příchozí data do dvou

tabulek, nebo vytvořit report v Reporting Services, který se bude dotazovat do modelu.

112

TYPY ZNALOSTÍ

Aplikace zvoleného algoritmu na předzpracovaná data, dle typu znalosti a dat.

Asociační pravidla - hledání vazeb mezi objekty.

Vyhledávání hodnot, které se spolu často vyskytují v určité transakci, to je důležité hlavně pro

prodej. Znalost produktů, které se nejčastěji kupují společně, pomáhá prodeji - umístění

produktů vedle sebe, vytvoření vhodných balíčků a to nejen produktů, ale i služeb.

Shlukování - seskupování podobných objektů

Shlukování je forma reprezentace dat, při které dochází za cenu jisté ztráty informace ke

snížení objemu relevantních dat.Zpracovávaná data můžeme obvykle reprezentovat jako

množinu X objektů, z nichž každý obsahuje stejnou množinu A atributů. Podle hodnot

vybraných atributů jsou data dále zpracovávána.

Speciálním případem shlukování je histogram (každý prvek představuje jeden shluk).

Shlukování netvoří ucelenou oblast, ale spadá do více oblastí vědy, jako je například

matematika, statistika, numerická analýza či umělá inteligence.

Klasifikace - přiřazení třídy objektu. Rozdělování objektů do předem známých skupin.

Nejčastěji se využívají rozhodovací stromy

1. krok: konstrukce rozhodovacího stromu na základě vzorku dat

2. krok: klasifikace objektů na základě vytvořeného rozhodovacího stromu

Úspěšnost se měří procentem úspěšně klasifikovaných objektů

Predikce - předpověď chování objektu v čase.

Např. Jsou dána stará data o zákaznících a platbách. Z nich se predikuje vhodnost nových

zájemců o půjčky.

113

21Holisticko‐procesní pohled na podnikový informační

systém, dekompozice interních a externích procesů,

hodnototvorný řetězec, podpůrné a rozhodovací

procesy

Holisticko-procesní pohled na podnikový informační systém

Podle holisticko-procesní klasifikace tvoří podnikový informační systém:

a) ERP jádro, zaměřené na řízení interních podnikových procesů

b) CRM systém obsahující proces směřující k a od zákazníků (externí procesy)

c) SCM řízení dodavatelského řetězec, jehož integrální součástí bývá APS systém sloužící

k pokročilému plánování a rozvrhování výroby

d) MIS manažerský informační systém, který sbírá data od ERP, CRM, SCM/APS systému

(a samozřejmě z externích zdrojů) a na jejich základě poskytuje informace pro

rozhodování.

Systémová integrace pak poskytuje prostředky k vytvoření permanentní údržbě podnikového

informačního systému, a to jak technologické, tak i řídící, projektové a strategické úrovni.

Proces je soubor vzájemně souvisejících nebo vzájemně působících činností, které přeměňují

vstupy na výstupy.

Systems

Integration

Enterprise

Resource

Planning

Business Intelligence (MIS)

Suply

Chain

Management

Customer

Relationship

Management

114

Interní procesy,

které má management podniku plně pod kontrolou a může jim přidělit vlastníka – manažera

odpovědného za jejich chod a inovaci.

Externí procesy,

u nichž není přesně definovaný vlastník a jejichž efektivní řízení nemá management plně pod

kontrolou. Jedná se o procesy spadající do oblasti řízení vztahu se zákazníky a řízení

dodavatelského řetězce.

115

22Budování podnikového informačního systému, životní

cyklus ERP projektu, řízení změny, projektové řízení

a specifika ERP projektů

Budování informačního systému nesmí postrádat behaviorální, normativní a kulturní rozměr

Change Management

Risk Management

Respektování podnikové kultury

Životní cyklus a inovace

Životní cyklus ERP projektu:

Strategická analýza – tvorba celopodnikové strategie a dílčích strategických koncepcí,

návrhy na změny v organizaci a jednotlivých oblastech řízení

Strategická analýza IS/ICT – definování informační strategie a návrh na řízení

životního cyklu IS/ICT

Procesní analýza – definování a popis podnikových procesů vč. hodnototvorného

řetězce, podpůrných a řídících procesů a návrhy na zlepšení

Zpracování dokumentace

Pro čerpání dotace (např. z programu ICT v podnicích)

Pro výběrové řízení na IS/ICT (zadávací dokumentace, poptávka)

Organizace a vyhodnocení výběrového řízení na IS/ICT

Uzavření smluvního vztahu

Proces implementace IS/ICT

Řízení servisních služeb

116

Vyhotovení projektu

Diagnostika potřeb zákazníka

Stanovení řídících týmu implementace

Stanovení implementačních týmů

Školení pracovníků implementačního týmu

Předimplementační analýza

Stanovení harmonogramu implementace

Implementace informačního systému

Běh implementačních prací

Testování a akceptace milníků a implementace

Běh školících kursů

Zkušební provoz

Převod dat

Reální provoz

Etapy řízení změny dle Lewinova modelu

analytická etapa,

117

návrhová etapa, jejíž jádro spočívá

o ve vytvoření modelu změny (který bude akceptován a podporován

sponzorem),

o ve stanovení agenta změny (který má podporu sponzora),

o v určení dílčích firemních procesů (subsystémů), které budou plánovanou

změnou ovlivněny,

realizační etapa, kdy dojde k provedení vlastní plánované změny,

zpětnovazební vyhodnocení provedené změny, na jejímž základě následuje

eventuální úprava stávajícího změnového procesu popř. zamražení změny.

Projektové řízení a specifika IT projektů

Specifika IT projektů

IT projekt charakterizují čtyři společně se vyskytující znaky s následujícími specifiky:

Cíl projektu je vždy trojrozměrný – (náklady, cíle projektu, časový harmonogram)

Projekt je jedinečný – žádný projekt není stejný (např. v týmu jsou jiní lidé)

o projekt je neopakovatelný nebo opakovatelný jen do určité míry

o projekty jsou časově omezeny s výjimkou neustálých inovací

Projekt je vždy realizován za využití lidských a materiálových zdrojů

o lidé jsou vedeni k práci v týmu

Realizace projektu v rámci organizace – sladění cíle projektu s cíli organizace

118

23Implementace ERP systémů, její hlavní fáze, klíčové

charakteristiky a smluvní zajištění realizace

implementačního projektu

Charakteristika ERP projektu ERP projekt

charakterizují 4 společně se vyskytující znaky s následujícími specifiky: • Cíl – je vždy trojrozměrný

• Jedinečnost – sestavení unikátního týmu lidí (ne)opakovatelnost projektu – specifikum One-to-Many řešení dočasnost jeho řešení – specifikum „nekonečného“ ERP projektu

• Realizace projektu za využití lidských a materiálových zdrojů – vedení lidí a efektivní týmová komunikace – specifikum vzdělání (hybridních kariér), morálně-volních vlastností lidí a organizace implementačního týmu

• Realizace projektu v rámci organizace – sladění cíle projektu s cíli organizace – specifikum souladu podnikových strategických cílů a cílů IS/IT

119

Implementace ERP systému z pohledu

dodavatele

Koncepční návrh Zahrnuje provedení prvotních analýz proveditelnosti implementace ERP systému. Proveditelnost implementace je zkoumána z hlediska: 1) Technologického - analyzuje se technologická proveditelnost implementace požadovaných funkčností daného systému (specifické požadavky na úpravu systému nad rámec standardního řešení ERP systému apod.). 2) Finančního a ekonomického - analyzuje se způsob financování projektu, jeho předpokládané náklady apod. (používá se řada ukazatelů, jako například návratnost prostředků, analýza nákladů/přínosů apod.). 3) Operačního a organizačního - analyzuje se oblast

operativních činností během implementace a organizace

jejich zabezpečení (definice rozsahu školení budoucích

uživatelů apod.).

Návrh projektu •Časový harmonogram projektu s vazbou na plán a vytížení kapacit zdrojů;

•Definice rozpočtu projektu;

•Definice organizační struktury projektu;

120

•Definice rozsahu odpovědností a pravomocí pozic organizační struktury projektu. Výstupy této fáze projektu představují:

• Organizační struktura projektu;

• Rozsah odpovědností a pravomocí členů projektu;

• Rámcový harmonogram projektu

Plánování projektu •Detailní rozpracování všech částí projektu;

•Definování plánů aktivit a zdrojů;

•Definování plánů komunikací, kontrolních bodů a cílů projektu s konečnými termíny jejich dosažení;

•Definování kritické cesty projektu a vznik plánu eliminace rizik a nepředvídaných událostí;

Výstupy této fáze projektu představují: •Harmonogram projektu (vychází z plánu požadavků na ERP systém ze strany zákazníka, z plánů aktivit a zdrojů, z plánu vytížení zdrojů projektu a případně dalších souvisejících plánů);

•Rozpočet projektu (vychází z plánu aktivit a zdrojů projektu, plánu pevných nákladů a případně dalších souvisejících plánů);

•Plán realizace projektu (vychází z harmonogramu projektu, definovaných milníků projektu a mapy kritické cesty);

121

•Plán eliminace rizik (vychází z mapy kritické cesty, analýzy rizik projektu, plánu nepředvídaných situací a případně dalších souvisejících plánů).

Realizace projektu Časově nejrozsáhlejší fáze projektu – uskutečňují se všechny požadavky na ERP systém podle definovaného harmonogramu projektu (nemusí být vždy realizovány všechny níže uvedené činnosti, záleží na konkrétních požadavcích zákazníka): •Instalace databázového serveru a instalace ERP systému na tento server;

•Nastavení standardních parametrů systému;

•Programování a implementace specifických úprav systému;

•Školení budoucích uživatelů systému;

•Převod dat do systému.

Kritické faktory úspěšnosti ze strany dodavatele ERP systému. •Poslání a cíle - správně definované a pochopené cíle projektu jsou základem pro plánování a realizaci projektu.

•Plánování - plánování času, financí, zdrojů, komunikace a řízení je pojítkem mezi cíli a realizací projektu. Mnoho projektů nesplnilo očekávání z důvodů chybného plánování, ale i nepochopení dynamiky tohoto faktoru. Plánování

122

nekončí prvním návrhem, ale v průběhu projektu se stále aktualizuje podle stavu zdrojů a podle změn cílů projektu.

•Konzultace se zákazníkem - uživatel výstupů z projektu je klíčovým posuzovatelem úspěšnosti projektu. Pro počáteční fázi stanovení cílů a koncepce řešení je nutné spolupracovat s budoucím uživatelem. Projekty zpracovávané izolovaně končí často neúspěchem (zákazník mnohdy neví, co si má pod budoucími výstupy představit). •Personální vztahy a komunikace - dobré vztahy mezi členy projektového týmu, mezi členy projektového týmu a ostatními zaměstnanci dodavatele a mezi členy projektového týmu a zaměstnanci zákazníka jsou nutnými předpoklady úspěchu projektu. Neformální informační kanály mohou přispět k práci na projektu stejně jako ji mohou i komplikovat.

•Technologie - v projektech je nutno využívat aktuální technologie. Pro vedoucího projektu to znamená především výběr pracovníků s odpovídajícími znalostmi.

•Řízení projektu - obvyklým problémem řízení je nedokonalé sledování odchylek mezi plánem a realitou. Není tak zajištěna zpětná vazba, která je pro řízení nezbytná.

•Příprava na řešení problému - každý projekt vyžaduje plán opatření pro případ výskytu možných problémů. Minimalizuje časová zpoždění a související náklady

Ukončení projektu Závěrečná fáze – zákazníkovi je předáván plně funkční ERP systém, kdy ze strany zákazníka je následně uskutečněna přijetí takto předávaného systému. Tímto dochází k ukončení projektu.

123

Klíčovou podmínkou úspěšné implementace ERP systému je podrobná analýza procesních toků zákazníka a všech jeho požadavků. ERP projekt se pak ve většině případů skládá ze dvou samostatných a na sebe plně navazujících projektů: • Předimplementační analýza systému;

• Implementace systému.

Implementace ERP systému z pohledu

zákazníka

Volba rozhodnutí – otázka potřeby nového ERP systému nebo inovace stávajícího. Kritické faktory úspěchu: - Definice celopodnikové a informační strategie firmy a jejich soulad (např. předpoklad změny vlastníka, reengineeringu procesů, firmy apod.) - Velikost organizace a její struktura

- Existence více informačních systémů Důležité aspekty této fáze Nestabilita podnikatelského prostředí a vývoj IS/ICT jsou charakteristické rychlými změnami požadavků z hlediska potřeb organizace i jejich uživatelských skupin a dynamicky se vyvíjejícími možnostmi IS/ICT produktů, jejichž uplatnění pro podnik manažeři ani často nedokážou rozpoznat a zhodnotit. Zavádění IS je velmi složitý proces, typická prosazováním

124

mnoha často protichůdných požadavků, obtížnou řiditelností nesourodého týmu různých lidí (konzultanti dodavatele, programátoři, klíčoví uživatelé, manažeři) s různými vlastnostmi a schopnostmi.

Pořízení systému a volba implementačního partnera Kritické faktory úspěchu: - Volba vhodného systému

- Volba vhodného implementačního partnera – dodavatele systému (při realizaci rozsáhlých ERP projektů využívají podniky služeb některé z poradenských společností, speciálně pak ve fázi implementace)

- Minimalizace potřeb zakázkových úprav, neboť tzv. customizace přináší časové ztráty a dodatečné vysoké náklady. Důležité aspekty této fáze Důležitou roli hrají reference v oboru a osobní kontakty managementu podniku. Platí však, že nejvhodnějším nástrojem volby je výběrové řízení. K objektivnímu posouzení jednotlivých nabídek slouží zejména tzv. úvodní studie vypracované zájemci z řad dodavatelů. Důležitou roli hrají v této fázi faktory jako např. funkcionalita, cena, služby školení a údržba, které bývají analyzovány a definovány smluvními vztahy. Je rovněž žádoucí vyhodnotit návratnosti investice do projektu.

125

Proces implementace Kritické faktory úspěchu: - Customizace (One-to-One řešení), adaptace (parametrizace, pokud jde o One-to Many řešení) dle požadavků zákazníka

- Dostatečné investice na customizaci a školení uživatelů

- Dodržování časového harmonogramu, plánu investic a organizaci prac. týmů

- Asymetrie informací a znalostí Důležité aspekty této fáze Vysoké nároky na dodržování časového harmonogramu prací, plánu investic a organizaci pracovních týmů předpokládají pevně stanovený limit investovaných prostředků a podrobný časový plán projektu. U renomovaných dodavatelů lze využít možnosti splácení investice v delším časovém období. Při řešení operativních úkolů vznikají neočekávané nadbytečné náklady plynoucí z chyb a časových ztrát. Klíčovou roli hraje personální složení implementačního týmu, morálně-volní vlastnosti jednotlivých pracovníků a profily jejich hybridních kariér.

126

Mapa kvalifikačního růstu - hybridní kariéry

Proces užívaní systému a jeho údržby Kritické faktory úspěchu: - Realizace očekávaných přínosů za minimálního narušení podnikového provozu

- Schopnost vyhodnotit měřitelné a neměřitelné efekty z provozu ERP systému Důležité aspekty této fáze Rozhoduje především plná funkčnost systému při řízení pokrytých podnikových procesů (výroba, logistika, obchod atd.). Důležitá je samozřejmě také jeho správa a údržba, neboť každý výpadek má negativní (někdy až kritický) dopad na chod podniku (např. nedodržení termínu expedice zakázek). Podmínky poskytování služeb jsou obvykle součástí SLA smlouvy. Ta definuje měřitelnou úroveň poskytovaných služeb pro splnění uzavřeného kontraktu. V případě poklesu pod určitou úroveň (doba výpadku systému, objem transakcí)

127

následuje definovaná sankce vůči dodavateli. Vhodné je aplikovat odpovídající systém metrik pro hodnocení přínosů ERP projektu. Mnoho zejména neměřitelných přínosů se přitom projeví až po době delší jak jeden rok od ukončení implementace.

Proces rozvoje, inovace a „odchodu do důchodu“ Kritické faktory úspěchu: - Schopnost vhodně zvolit a časově naplánovat pokrytí procesů pro: * získání dodatečných přínosů * vertikální a horizontální integraci Důležité aspekty této fáze Životní cyklus ERP se neustále zkracuje a stává se, že během rozpracovaného projektu je nutno rozšířit jeho zadání. K tomuto jevu dochází zejména ve velkých podnicích, kde zavádění systému trvá déle jak jeden rok. Pokud však ERP systém přestane dostačovat podnikatelským potřebám nebo se management při plánování ERP projektu dopustí vážných chyb, pak je třeba učinit obtížné rozhodnutí, které může také znamenat dočasnou ztrátu investic v nedokončeném projektu. Praxe ukazuje, že překonat tuto fázi je nesmírně obtížné. Pokračování v „nikdy nekončící implementaci“ nevhodného produktu s nevhodným partnerem však přinese v konečném důsledku daleko větší ztráty.

128

Na co je třeba pamatovat při rozhodování o

ERP systému

129

•Změny ve strategii, procesech, organizační struktuře

•Definování informačních potřeb

•Výběr dodavatele (výrobce a systémového integrátora)

•Obchodní model dodávky (přímý, nepřímý, hybridní)

•Výběr vhodné metodiky (COBIT, ITIL) k systematickému řízení životního cyklu

•Důkladné zvážení potřeb v oblasti servisních služeb

•ERP systém jako nositel standardizace (rozdíl mezi skutečným stavem a deklarováním stavu navenek)

•Lidé jako uživatelé a iniciátoři inovací

Praktický pohled podniku na ERP a rizika při

výběrovém řízení

Vytvoření dlouhodobého partnerství, jehož cílem je

zvyšovat růst, výkonnost a know-how zákaznické

organizace

•Jistota budoucího vývoje informačního systému

•Best Practices ze světa i z českých firem

•Reference procesní i oborové

130

•Špičková úroveň a dostatečný počet specializovaných konzultantů

•Špičková úroveň servisních služeb po celou dobu životního cyklu

•Cenové relace, více možností financování IS/ICT projektu

131

24Servisní služby k ERP systémům a jejich smluvní

zajištění v rámci dodávky ERP systému Klasifikace

ERP systémů, komplementární produkty a

informační technologie v ERP systémech, obchodní

modely dodávky, implementace a provozu ERP

systémů, problematika outsourcingu

Smyslem servisních služeb je zajistit plynulý, bezproblémový chod systému a jeho další

rozvoj.

Servisní služby – slouží k zajišťování záručního i pozáručního servisu, nabídce

komplementárních produktů a služeb s cílem posílit spokojenost a loajalitu zákazníka.

Zasahují obchodní cyklus ve všech fázích, proto je také dělíme na předprodejní, prodejní a

poprodejní. Servisní služby jsou v rámci CRM řízeny funkcionalitou, kterou označujeme jako

CSS (Customer Service and Support).

Servisní služby dále dělíme na:

poskytované záruky

služby pozáruční

služby dodatečné

Základní členění služeb k podnikovým informačním systémům vychází z podstaty a časového

průběhu obchodního cyklu dodavatele => předprodejní služby, prodejní a poprodejní.

Předprodejní služby

Zpracování strategické analýzy, procesní analýzy, analýzy IS/ICT, informační strategie či

studie proveditelnosti (Feasibility Study – úkolem definovat rozsah implementace, zaměřit se

na úskalí, navrhnout způsob řešení a hodnocení projektu). V této fázi ještě není rozhodnuto o

produktu ani dodavateli nebo implementačním partnerovi.

Zpracování tzv. předimplementační analýzy či studie řadíme podle toho kým a jak je

vypracována do předprodejních nebo prodejních služeb.

132

Standardní servisní služby prodejní a poprodejní fáze jsou implementační práce, školení,

převod dat, testování či asistence při spuštění ostrého provozu.

Servisní služby

Z hlediska garancí dodavatele dělíme do tří kategorií. První z nich se týká poskytované

záruky, další představují služby pozáruční a služby dodatečné (doplňkové). Pojmy záruka a

záruční doba nelze u ERP systémů aplikovat tak, jak je běžné u průmyslového zboží. Záruka

se v případě ERP systému vztahuje na jeho stav a řádnou funkčnost dle schválené

předimplementační analýzy v době, kdy byl předán a zákazníkem řádně akceptován. Smlouva

o technické podpoře zahrnuje veškeré služby, definuje pravidla a sazby pro řešení budoucích

servisních požadavků, uzavírá se z důvodu, aby zákazník nebyl nechán po implementaci na

pospas osudu. Při zmínce o servisním poplatku nemůžeme vynechat platbu tzv. maintenance.

Tento specifický poplatek se vyskytuje především u zahraničních produktů typu Oracle E-

Business Suite nebo IFS aplikace a označuje se jím roční platba určený výrobci systému.

Obvykle je počítán z ceny licence a opravňuje zákazníka k upgradu a updatu, u některých

systémů je tato platba dokonce povinná. Servisní smlouva může být rozšířena o dokument

typu SLA (Service Level Agreement). Tato dohoda o úrovni poskytovaných služeb obsahuje

konkrétní specifikaci podmínek poskytovaných služeb (zejména jde o stanovení doby reakce

na zadaný problém, jeho vyřešení či způsob jeho předání na vyšší úroveň), zahrnuje sankce

pro případ neuspokojivého řešení. Profylaxe nabízená některými dodavateli (např. Aimtec)

obsahuje preventivní kontroly a prohlídky příslušných zařízení, popř. provedení jejich

drobných oprav.

133

Klasifikace ERP systémů, komplementární produkty a informační

technologie v ERP systémech, obchodní modely dodávky,

implementace a provozu ERP systémů, problematika

outsourcingu

Klasifikace ERP systémů

ERP systém Charakteristika Výhody Nevýhody

All-in-One Schopnost integrovat

všechny interní

procesy

Vysoká úroveň

integrace dostačující

většině podniků

Nižší detailní

funkcionalita,

nákladná customizace

Best-of-Breed Orientace na

specifické obory

nebo procesy

Špičková detailní

funkcionalita nebo

spec. oborová řešení

Obtížnější koordinace

procesů, nutnost

řešení více projektů

Lite ERP „Odlehčená“ verze

standardního ERP

řešení

Nižší cena, orientace

na rychlou

implementaci

Omezení ve

funkcionalitě, počtu

uživatelů, customizaci

atd.

Komplementární produkty a informační technologie v ERP systémech

Nasazení ERP systémů se neobejde bez databázových platforem, operačních systémů, síťové

infrastruktury, hardwaru – tedy komplementární produktů. Mezi operačními systémy

dominuje Microsoft. Dalším stabilní rodinou operačních systémů je UNIX.

Mezi nejrozšířenější databázové platformy patří Microsoft SQL Server a Oracle Database.

Moderní ERP systém je založen na vysoce sofistikovaných hardwarových a softwarových

komplementárních produktech jako jsou databázové systémy, síťové operační systémy,

víceprocesorové servery apod.

Outsourcing ERP systémů

Outsourcing ERP systémů není v České republice masovou záležitostí a společnosti se k ní

přiklánějí málo kdy.

134

25Výrobní proces jako hodnototvorný řetězec, základní

typy výrob, typy informačních systémů a

informačních technologií používaných pro operativní

řízení výroby

Základní typy výrob

Dle spojitosti výroby:

1. Diskrétní (nespojitá) výroba – zahrnuje v moderních systémech kombinaci řízení

diskrétních i spojitých procesů. Finální produkt diskrétní výroby principiálně vzniká na

základě kusovníku, typicky ve strojírenském odvětví.

2. Procesní (spojitá) výroba – je zpravidla nasazována v úzké návaznosti na řízení

kvality. Charakteristickými odvětvími, které se neobejdou bez tohoto typu výroby,

jsou farmaceutický, potravinářský a chemický průmysl. Procesní výroba totiž kromě

standardní funkcionality pokrývající spotřebu materiálu či plánování výroby zahrnuje

také sledování a testování složení výrobků, jejich klasifikaci, sledování kvalitativních

ukazatelů a toku materiálů výrobou tak, aby jej bylo možno zpětně identifikovat.

3. Opakovatelná linková výroba (plynulá výrobní linka, nebo také proudová výroba) –

uskutečňuje tento proces v tzv. výrobních buňkách. Výrobní buňky jsou tvořeny

uspořádáním strojů na malém prostoru do uzavřeného celku s jednostranně

definovaným tokem materiálu.

Dle odběru produkce

1. Výroba na sklad (Make-to-Stock) – vytváří se skladové zásoby na základě predikce

očekávaných objednávek od zákazníků. Většina zákaznických produktů, například

konzervované potraviny, spotřební elektronika, knihy nebo koupelnová technika jsou

vyráběny právě tímto způsobem.

2. Výroba na zakázku (Production-to-Order) – je realizována proto, aby uspokojila

specifické požadavky zákazníka. Tento přístup je obvykle využíván při výrobě zboží,

které má vysoké náklady na skladování, nebo výrobků, které je třeba sestavovat na

přání zákazníka. K takovýmto výrobkům patří například drahé dopravní prostředky

(letadla) nebo investiční celky v podobě výrobních zařízení (strojní automaty).

3. Montáž na zakázku (Assembly-to-Order) – využívá kombinace výroby na zakázku a

výroby na sklad. Konečný produkt je kompletován podle specifické objednávky z

vybraných komponent, které byly vyráběny na sklad. Typickým příkladem výrobku

montovaného na zakázku je osobní počítač.

4. Inženýrské práce na zakázku (Engineer-to-Order) – jsou charakteristické tím, že v

okamžiku příjmu objednávky od zákazníka není zakázka předem přesně technicky

135

specifikovaná. Existuje pouze zevrubná představa o tom, jak bude daný produkt

vypadat. Práce na zakázce pak začíná návrhem řešení. Vyjasnění konečné podoby

produktu ze strany zákazníka může trvat týdny až měsíce. Roční produkce se pak

pohybuje v řádu desítek (speciální stroje) či jednotek (rozsáhlé investiční celky,

například celé výrobní linky).

Operativní řízení výroby

Při automatizaci výroby je nutné zabezpečit nejen vazbu na logistické procesy, ale také

návaznost na samotný výrobní proces => požadavek na MES.

MES (Manufacturing Execution Systems) – slouží k získávání provozních dat v reálném čase.

Zpravidla se využívají tzv. výrobní informační systémy.

MES se zabývají detailním sběrem dat a jejich zpracováním pro účely vyhodnocení výroby z

mnoha různých úhlů pohledu a operativního řízení. Funkcionalitu MES nelze přesně vymezit

tak, jako je tomu u ERP systémů. Je to dáno zejména tím, že výrobní informační systémy jsou

více ovlivněny typem výroby, než ERP systémy.

Jsou využívány v automobilovém, potravinářském, elektrotechnickém, chemickém průmyslu.

136

26Metody a principy plánování a řízení výroby v

informačních systémech, pokročilé plánování a

rozvrhování výroby a jeho praktické uplatnění

Metody a principy řízení výroby v informačních systémech

1. Řízení výroby podle minimálních zásob – výroba byla rozdělena na několik fází a byl

určen minimální stav zásob pro určitou fázi, a pokud poklesl stav. Byly zásoby

doplněny.

2. MRP (Material Requirements Planning) – MRP udržuje pouze nezbytné skladové

zásoby a neplánované požadavky plní podle časových priorit.

3. Kombinace MRP a řízení podle minimálních zásob – u zásob jež je výhodné držet

minimální zásoby a u ostatních jsou jen nezbytné zásoby.

4. MRP II (Manufacturing Resource Planning) – rozšíření MRP o přesnou kontrolu

plánování nákupu ve vazbě na výrobu a prodej.

5. JIT (Just-in-Time) – JIT představuje tažný princip řízení, podle něhož je výroba

produktu iniciována zákazníkem. Všechny potřebné komponenty jsou přitom „právě

včas“ taženy podnikovými procesy až k finální kompletaci produktu a předání

zákazníkovi.

6. Kanban - Jednotlivá pracoviště, výrobní linky apod. vyvolávají své aktivity u

předcházejícího výrobního stupně prostřednictvím tzv. kanban karty – objednávky,

která plní funkci dodacích listů. Na tomto základě se vytváří samořídící regulační –

kanbanové okruhy, které předpokládají decentralizaci řízení zakázek. Při určování

priority "co vyrábět dříve" se vychází z počtu jednotlivých objednávek, jejich vztahu k

požadovaným výrobkům a dalších pravidel.

7. Teorie omezení – je založena na principu úzkého místa systému, které je považováno

za omezení, které omezuje produkci systému vzhledem k jeho cíly

8. Seiban - Metoda Seiban funguje na základě přidělování specifického identifikačního

čísla seiban všem dílům, materiálu a objednávkám vázaným na zakázku pro určitého

zákazníka, konkrétní projekt nebo pro cokoli jiného. To umožňuje snadno sledovat

vše, co se vztahuje k určitému produktu, projektu nebo zákazníkovi.

Pokročilé plánování a rozvrhování výroby a jeho praktické uplatnění

Plánování i rozvrhování může probíhat obousměrně – dopředu i zpětně v čase.

Pokročilé plánování a rozvrhování kombinuje dopředný i zpětný způsob, což umožňuje určit

optimální termín zahájení výroby a objednávky. Přidáme-li k této kombinaci možnost

plánovat s omezenými kapacitami a možnost řídit výrobu pomocí omezení identifikovaného

137

úzkého místa, pak dosáhneme skutečně reálného plánu výroby, jímž je možné efektivně splnit

zákaznické požadavky.

138

27Řízení ekonomického procesu v informačních

systémech

Řízení ekonomiky je typický podpůrný proces, který nepřidává hodnotu, nemá externí

zákazníky a negeneruje tržby. Do ekonomického procesu podniku patří finanční účetnictví,

řízení nákladů a jejich kontrola, řízení cash-flow, plánování a rozpočtování.

Účetnictví můžeme rozdělit na dvě základní oblasti:

Finanční účetnictví – poskytování věrohodných informací o situaci podniku pro různé

uživatele

Manažerské účetnictví – poskytování informací manažerům pro řízení a hodnocení

firmy

Controlling

Finanční

účetnictví

Manažerské účetnictví

Vstup Výstup

Rozpočtová

ní

Vnitropodnikové

účetnictví

Kalkulace

Řízení Cash-flow Rozhodovací úlohy

139

28Řízení nákupní, prodejní, výrobní logistiky a

skladového hospodářství v informačních systémech

Jedná se o interní procesy řízené ERP systémem. Na který jsou kladeny tyto nároky:

Realizace měřitelných přínosů v oblasti snižování celé struktury nákladů vznikající

neefektivním řízením firmy.

Realizace neměřitelných přínosů v oblasti řízení podnikových procesů a dostupnosti

informací v reálném čase.

Nákupní logistika

Hlavním úkolem nákupu je sledovat vývoj na trhu, výhodně uzavírat smlouvy s dodavateli a

účelně organizovat fyzické činnosti materiálových toků. Což zjednodušeně znamená, že

úkolem zásobování je optimálně získávat vstupy do výrobního procesu.

Prodejní logistika

neboli také distribuce, je po nákupní a výrobní logistice dalším velice důležitým mezníkem.

Jejím hlavním cílem je uspokojení potřeb zákazníků.

Výrobní logistika

Výroba je jakýmsi mezičlánkem mezi nákupem a prodejem. Výrobní logistika má za úkol

sledovat pohyb materiálu ve výrobním procesu.

Skladové hospodářství

zahrnuje všechny procesy a podprocesy související se skladováním zásob.

140

29Řízení lidských zdrojů v informačních systémech

Řízení lidských zdrojů v informačních systémech

HRM (Human Resource Management). Malé a střední firmy výrobní a obchodní firmy si

mnohdy vystačí jen se základním zpracováním mezd, jednoduchou personální evidencí, popř.

aplikacemi určenými k řízení některých důležitých operativních činností, jako jsou výpočty a

výkazy služebních cest. Protipól nadnárodní firmy, pro něž je systematická práce s vlastními

lidmi nezbytná k udržení konkurenceschopnosti. (Pozn. čeští dodavatelé HRM společnosti –

Vema, KS – program a Elanor.) Obrázek znázorňuje hlavní procesy HRM zakomponované v

aplikacích, z nichž se skládá standardní personální informační systém (HRIS – Human

Resource Information Systém).

HRIS se v organizaci vytváří dvěma způsoby:

All-in-One ERP systém, jehož součástí je funkcionalita pro HRM. Obvykle se jedná o moduly

subdodavatele, jež implementuje implementační partner celého projektu. (např. KS –

program, Elanor, Kvasar.)

Best-of-Breed řešení, detailnější pokrytí celého procesu nebo jeho částí. (zejména společnost

Vema. K uživatelům (zákazníkům) patří mj. sektor veřejné správy – státní úřady, příspěvkové

a rozpočtové organizace.)

Řízení mzdové agendy

(Pozn. standardní personální systémy umí zpracovat všechny typy mezd pro všechny druhy

pracovních poměrů včetně výpočtu daní a odvodů sociálního a zdravotního pojištění.)

Zpracování mezd – individuálně po jednom osobním čísle, nebo hromadně výběrem několika

zaměstnanců najednou a postupným zpracováním všech náležitostí. Důležitá podpora

pravidelných měsíčních uzávěrek, k nimž je třeba vytisknout celou řadu různých sestav a

rekapitulací. (Vyspělé systémy k dispozici nejpoužívanější sestavy – přehled zaplaceného

sociálního pojištění, výkaz dávek nemocenského, soupis srážek ze mzdy apod. Nadstandardní

systémy poskytované společností Vema a KS mzdy zahrnují zpětné přepočty. Využití pro

opravu v případech pozdního dodání

podkladů k výpočtu mzdy – narození dítěte, neschopenka, opožděné nahlášení dovolené.

Proběhne tak kompletní přepočet mzdy do minulosti, a změny se promítnou do současné

mzdy včetně správných odvodů.) Podpora platné legislativy země v níž se systém provozuje!

141

Personalistika

Vymezení subprocesů, agendy a činností v této oblasti:

- V užším slova pojetí personalistika poskytuje evidenci základních osobních údajů a

pracovně právních dokumentů. Vzory dokumentů bývají předdefinovány a pravidelně

upravovány dle legislativy.

- V širším pojetí personalistika zahrnuje kromě evidence údajů o zaměstnancích a příslušných

dokumentech také agendu pro ochranu zdraví při práci, systematizaci pracovních míst,

vzdělávání a řízení kariérního růstu, hodnocení zaměstnanců, sociální programy, uchazeče o

práci a výběrová řízení.

Vzdělávání zaměstnanců

Personální informační systémy slouží mimo jiné k:

Sledování plnění kvalifikačních požadavků

Plánování vzdělávacích akcí

Evidenci a vyhodnocování vzdělávacích akcí včetně jejich nákladovosti

Evidenci platnost osvědčení, certifikátů a jiných kvalifikačních dokladů

Administraci lektorů

Správě kurzů pro samostudium

Ve vyspělých systémech jsou tyto činnosti vysoce automatizovány. (Jedno tlačítko vyhledá

zaměstnance s prošlou certifikaci, požadavkem na školení k naplánování vzdělávací akce.

Personalista stanoví pouze datum a rozešle pozvánky.) (Důležitá úroveň integrace – schopnost

jednotlivých aplikací úzce komunikovat vzdělávání součástí systematizace pracovních míst.

Nový zaměstnanec nemá potřebné školení, automaticky požadavek.)

Budoucnost

Základním rysem moderního HRIS je jeho zaměření na ovlivňování a hodnocení výkonnosti

zaměstnanců. K tomu bude využívat možnosti tzv. Talent Managementu. (Myšlenka úspěchu

podnikání závislého na využívání schopností a nadání lidí. HRIS by tak navíc obsahoval

moduly pro Talent Management (pokrývající zejména výběr, vzdělávání, plánování kariéry a

odměňování se zaměřením na výkonnost zaměstnanců.

Talent management

lze znázornit jako cyklus, který obsahuje tyto hlavni fáze:

142

Získávání nadaných zaměstnanců – aplikace HRM shromažďuje a konsoliduje

požadavky na nové zaměstnance přes celou organizaci a zvláště napomáhá při

procesu jejich přijímání (organizace výběrových řízení, vstupní pohovory, výběr z

vlastních zdrojů atd.)

Personální rozvoj zaměstnanců – aplikace HRM napomáhá při periodickém

hodnocení výkonnosti, nastavení parametrů, managementu kompetencí, definování

pracovních postupů a sebehodnocení zaměstnanců. Stěžejní součástí proces

vzdělávání.

Plánování a řízení kariéry – zaměstnancem řízený proces, v HRM aplikaci podporuje

tvorba kariérních scénářů a jejich uživatelské vyhledávání, spolupráce s odborným

poradcem (mentorem), nástroje pro porovnávání pracovních zařazení a kariérní

upozornění. (Plánování pracovních postupů obsahuje modelování pracovních týmů,

plány, postupové řetězce, vyhledání a porovnání vhodných kandidátů a evidence

kontaktů na personální agentury.

Personální integrace zaměstnanců – správné stanovení cílů a vyhodnocení jejich

plnění. Do strategického plánování a řízení jsou zakomponovány cílové plány

zaměstnanců a jejich úkolů. Součást HRM aplikace, nazvaná jako Talent Management

je za účelem personální integrace zaměstnanců provázána s manažerským

informačním systémem tak, aby bylo možné hierarchicky rozkládat podnikové

výkonnostní cíle na cíle pracovních týmů a jednotlivých zaměstnanců. Při této

činnosti se obvykle používá koncept Balanced Scorecard.

Hodnocení zaměstnanců – používají se pro management odměňování, který spočívá v

realizaci kompenzačních plánů, zařazování pracovníků do globálních pobídkových

plánů, přidělování bonusů pro podnikové úseky, cílových odměn a dalších benefitů.

143

30Řízení majetku, údržby a správa kritických aktiv v

informačních systémech

Enterprise Asset Managment (EAM) slouží ke správě majetku a podnikových zařízení. Jeho

funkční podpora v informačním systému umožňuje sledovat všechny náklady a aktivity

spojené s kritickými hmotnými zdroji organizace.

Přínosy EAM

úspora nákladů (na údržbu, provoz a správu aktiv) – identifikace zařízení s vysokou

poruchovostí.

zvýšení produktivity výroby (odstraňování výpadků strojů a zařízení a zlepšování

výrobních procesů)

zvýšení produktivity údržby (zlepšení organizace práce, snižování prostojů pracovníků

údržby, zvýšení podílů preventivní a plánované údržby)

zlepšení podpory rozhodování (přesné a detailní informace o každém zařízení, jeho

využití, hodnotě, nákladech opravách apod.)

Funkcionalitu EAM poskytují buď moduly ERP systému nebo specializované EAM aplikace.

Využívá se v podnicích z oblasti těžkého průmyslu, dopravních a logistických organizacích,

nemocnicích, armádě, u energetických společností či servisních organizací spravujících areály

budov.

144

31Procesy a cykly v dodavatelském řetězci, strategické

řízení a hledání strategické pozice, metody a principy

řízení dodavatelského řetězce, informační technologie

a jejich využití při řízení dodavatelského řetězce

Procesy a cykly v dodavatelském řetězci

Dodavatelský řetězec (Supply Chain) je systém tvořený podnikovými procesy všech

organizací, které jsou přímo či nepřímo zapojeny do uspokojování potřeb zákazníka.

(producenti, dodavatelé, dopravci, velkoobchody a skladové prostory atd.)

Procesy v řetězci děleny podle toho zda jsou realizovány na základě tahu nebo tlaku.

(zákaznická objednávka tažné, procesy prováděné před zákaznickou objednávkou jsou

tlačné).

Nahlížíme-li na dodavatelský řetězec jako na cyklus, pak jasně definujeme integrované

procesy a vlastníky těchto procesů. Tento pohled je užitečný ke zvažování operativních

rozhodnutí, protože specifikuje role a odpovědnosti každého článku řetězce a požadovaný

výsledek pro každý proces.

Objednávkový => Doplňovací => Výrobní => Dodací cyklus

Objednávkový cyklus - probíhá mezi zákazníkem a maloobchodem – zahrnuje od vytvoření

objednávky až po její převzetí zákazníkem a zaplacení.

Doplňkový cyklus – uskutečňuje se mezi maloobchodníkem a distributorem – zahrnuje

všechny procesy spojené s doplňováním zásob.

Výrobní cyklus – probíhá mezi producentem a distributorem – zahrnuje všechny procesy

týkající se doplňování zásob distributora či obchodu.

Dodací cyklus – probíhá mezi producentem a dodavatelem – zahrnuje všechny procesy

spojené s dodáním materiálu pro nezbytnou výrobu podle rozvržení výroby.

145

Strategické řízení dodavatelského řetězce – SCM koncepce a hledání

strategické pozice

SCM koncepce – je procesně orientovaná strategie založená na úzké provázanosti

informačního systému a řízení externích procesů, jejichž spoluvlastníkem jsou dodavatelé,

popř. odběratelé společnosti.

SCM koncepce je prakticky realizována prostřednictvím SCM systému, popř. podnikových

aplikací, které jako integrovaný celek primárně slouží k řízení procesů dodavatelského řetězce

či procesů umožňujících efektivní začlenění organizace do dodavatelského řetězce jako jeho

součásti.

Systém partnerství – vyžaduje dobře vybudované vztahy koordinace a kooperace. Partneři se

snaží kooperovat v poskytování zlepšených služeb, technologické inovaci a návrhu produktu.

Vytvoření partnerského systému přináší synergický efekt, kdy řetězec jako celek funguje

efektivněji, než by v součtu samostatně fungovaly jeho jednotlivé součásti.

K dosažení strategické pozice je třeba správně porozumět:

Požadavkům cílové skupiny zákazníků

Nepředvídatelnosti poptávky

Vztahu mezi akceschopností a výkonností dodavatelského řetězce

Pro dosažení strategické pozice platí:

Čím větší je implikovaná nepředvídatelnost poptávky, tím by měl být dodavatelský řetězec

akceschopnější.

Zákazní

k

Maloobcho

d

Distributo

r

Producent Dodavatel

Objednávkov

ý cyklus

Doplňkov

ý cyklus

Výrobní

cyklus

Dodac

í

cyklus

Tlačné procesy

Tažné procesy

146

Principy a metody řízení dodavatelského řetězce, společné plánování a

predikce v dodavatelském řetězci

Systém plynulého zásobování – dodávky zajišťuje dodavatel ve spolupráci

s maloobchodem – příjme data od maloobchodu a uloží si je pro další případnou

předpověď a plánování zásobování

Řízení zásob dodavatelem – od distributorů obdrží informace o stavu zásob a vytvoří

objednávky a realizuje objednávky a přebírá odpovědnost za zásobování.

Efektivní reakce na požadavky zákazníka – důležitá je hlavně spolupráce všech

subjektů v řetězci, aby byl vytvořen optimální stav zásob v dodavatelském řetězci.

Optimální stav zásob je sestavován na základě očekávaného vývoje poptávky a

zabezpečuje tak stav zásob.

147

32CRM jako součást podnikové architektury,

klasifikace CRM systémů, principy fungování a

praktické uplatnění kontaktního centra, SFA a

analytického CRM, řízení servisních služeb v

ERP/CRM systémech

CRM jako součást podnikové architektury, principy fungování a praktické

uplatnění kontaktního centra, SFA a analytického CRM

CRM systém jako součást CRM koncepce je založen na třech základních kamenech:

komunikaci, operativním řízení CRM procesů a analýze zpracovaných dat. Tyto složky musí

být vzájemně propojení a vyvážené.

Cílem nasazení CRM systému by mělo být vytvoření automatizovaných procesů, směřujících

k efektnímu rozestavění zákazníků tak, aby firmy mohly využít pro stanovení podnikových

strategií v celé jejich hierarchii.

Princip tahu

Umožňuje maximální připravenost na další setkání se zákazníkem, nejlépe až do takové míry

kdy bude možno kvalifikovaně odhadnout jeho motivy, proč kontaktuje právě nás, a to ještě

dříve, než se k tomu sám rozhodne.

Princip tlaku

Další důležitou vlastností CRM je využitelnost získaných informací všemi odděleními firmy.

Ta si zvolí kritéria pro výběr konkrétních dat, ať už jde o frekvenci nákupů, vydaných částek,

reklamací či způsobu jejich vyřízení. Z těchto údajů lze pak vyvodit, jaké zvolit účinné

metody pro nabídku nových výrobků či služeb (cross-selling, up-selling) a s tím související

vhodný distribuční kanál a jak tedy dosáhnout maximální ziskovosti a dlouhodobé loajality

zákazníků.

148

Kontaktní centrum

Kontaktní centrum slouží primárně k zabezpečení procesu Řízení kontaktů. Spojuje dva dříve

neslučitelní světy, počítačové aplikace a distribuci telefonních hovorů. KC je tedy v širším

slova smyslu střediskem obsluhy kontaktů mezi organizací a jejími zákazníky a jako takové

zahrnuje různé druhy médií.

Praktické využití KC

Např. Společnost podniká v oblasti bankovních služeb. Hlavním úkolem kontaktního centra

této instituce je získávání nových klientů a obsluha stávajících s cílem posilování jejich

loajality.

SFA

SFA představuje manažerský koncept zaměřený na automatizaci všech činností podporujících

obchod, u nichž je to žádoucí a proveditelné. SFA má za úkol zbavit obchodníky zbytečné

administrativy a zvýšit produktivitu koordinací a jejich aktivit.

Analytické CRM

Analytickou funkcionalitu CRM zabezpečují aplikace typu BI (business Intelligence) a CI

(Customer Intelligence). BI zpracovávají data z interních transakčních systémů (ERP,SCM,

apod), CI představují soubor aplikací úzce svázaných s CRM, které shromažďují a analyzují

informace z interakcí se zákazníky.

149

Klasifikace CRM systémů

CRM podle úrovně funkcionality

Typ CRM Výhody Nevýhody Typický

uživatel

Typický

zástupce

All-in-One CRM Vysoká úroveň

integrace CRM

procesů,

bohatá

komplexní

funkčnost

Vysoké

náklady,

nízká

využitelnost

všech funkcí

Velká

společnost s

velkým

počtem

zákazníků v

řadě různých

zákaznických

skupin

Siebel, SAP,

Oracle, Onyx,

PeopleSoft

Best-of-Breed

CRM

Špičková

detailní

funkcionalita,

zaměření na

specifické

procesy popř.

oborová řešení

Vysoké

náklady,

nutnost

realizace více

CRM

projektů

Velká nebo

středně velká

firma s velkým

počtem

různých

zákaznických

skupin

Selectica

(konfigurátor),

SAS

(analytické

nástroje)

Lite CRM

(„odlehčené“)

Nízké náklady,

integrovaná

součást ERP

řešení

Nízká

detailní

funkcionalita

Středně velká

nebo malá

firma

zavádějící své

první CRM

řešení

MAX CRM

Lite, Visual

CRM

150

33Manažerský informační systém jako součást

podnikové architektury, technologie a

nástroje,Corporate Performance Management a jeho

podpora v informačních systémech

Manažerské informační systémy, technologie a nástroje

Manažerské informační systém tvoří IT/ICT podporu pro vrcholové i operativní rozhodování,

která může mít buď podobu sjednocených, předmětově orientovaných databází navržených za

tímto účelem, nebo zabezpečení jednoduchých analýz prováděných v databázích transakčních

systémů.

Využívá technologii datového skladu. Do kterého jsou pomocí ETL ukládány očištěné data

v jednotném formátu z interní a externích zdrojů.

Corporate Performance Management a jeho podpora v informačních

systémech

CPM je „souhrnný pojem, který popisuje metodiky, metriky, podnikové procesy a systémy,

které se používají pro monitorování a řízení výkonnosti celého podniku”.

151

Manažerský informační systém nebo specializovaný modul ERP systému, který podporuje

komplexní řízení výkonnosti firmy, řadíme do kategorie aplikací nazvaných Corporate

Performance Management.

152

34Jazyk HTML

Klíčová slova

html, webové stránky, Hyper Text Markup Language, www

Jazyk HTML

HyperText Markup Language, označovaný zkratkou HTML, je značkovací jazyk pro

hypertext. Je jedním z jazyků pro vytváření stránek v systému World Wide Web, který

umožňuje publikaci dokumentů na Internetu.

Vývoj jazyka

V roce 1990 byl navržen jazyk HTML a protokol pro jeho přenos v počítačové síti – HTTP

(HyperText Transfer Protocol – přenosový protokol hypertextu). Zároveň vznikl také první

webový prohlížeč nazvaný WorldWideWeb.

První verze jazyka HTML (r. 1991) nepodporuje grafický režim. Ale verze z roku 1994

obsahuje i interaktivní formuláře a podporu grafiky.

Verze 3.0 z roku 1996 nebyla nikdy přijata jako standard, protože byla příliš složitá a žádná

firma nebyla schopna naprogramovat její podporu. Standard už vydalo W3C, stejně jako

následující verze. Přidává k jazyku tabulky, zarovnávání textu a stylové elementy pro

ovlivňování vzhledu.

Ve verzi 4.0.do specifikace jazyka přibyly nové prvky pro tvorbu tabulek, formulářů a nově

byly standardizovány rámy (frames). Tato verze se snaží dosáhnout původního účelu – prvky

by měly vyznačovat význam (sémantiku) jednotlivých částí dokumentu, vzhled má být

ovlivňován připojovanými styly.

Připravovanou verzí je HTML 5, která je vyvíjena od r. 2007. Plánuje se přibližně až do roku

2022.

Koncepce jazyka

Jazyk HTML je charakterizován množinou značek a jejich atributů definovaných pro danou

verzi. Mezi značky se uzavírají části textu dokumentu a tím se určuje význam (sémantika)

obsaženého textu. Názvy jednotlivých značek se uzavírají mezi úhlové závorky (< a >). Část

dokumentu tvořená otevírací značkou, nějakým obsahem a odpovídající ukončovací značkou

tvoří tzv. element (prvek) dokumentu. Například <strong> je otevírací značka pro zvýraznění

textu a <strong>Tento text bude tučně</strong> je element obsahující zvýrazněný text.

Součástí obsahu elementu mohou být další vnořené elementy. Atributy jsou doplňující

informace, které upřesňují vlastnosti elementu.

Značky (zvané tagy) jsou obvykle párové (v XHTML jsou párové všechny), přičemž koncové

značka je shodná se značkou počáteční, jen má před názvem znak lomítko. Příklad pro

označení odstavce:

<p>Text odstavce</p>

Některé značky jsou nepárové – nemají žádný obsah a nepoužívají koncovou značku. Příklad

pro vykreslení vodorovné čáry:

<hr>

153

Tagy mohou obsahovat atributy, které popisují jejich vlastnosti nebo nesou jinou informaci.

Příkladem může být odkaz (tag a), jehož atribut href říká, kam se uživatel po kliknutí na něj

dostane:

<a href="http://www.cilovastranka.cz">Zde klikni</a>

Nebo jiné možnosti zápisu odkazu - odkaz, který se otevře v novém okně/panelu:

<a href="http://www.cilovastranka.cz" target="_blank">text odkazu</a>

Pro každou verzi existuje definice pravidel DTD (Document Type Definition). Od verze 4.01

musí být odkaz na deklaraci DTD v dokumentu uveden pomocí klíčového slova DOCTYPE.

DTD definuje pro určitou verzi elementy a atributy, které lze používat.

Dokument může mimo značkování obsahovat další prvky:

Direktivy – začínají znaky <!, jsou určeny pro zpracovatele dokumentu (prohlížeč).

Komentáře – pomocné texty pro programátora, nejsou součástí obsahu dokumentu a

nezobrazují se (prohlížeč je ignoruje).

Kód skriptovacích jazyků.

Definice událostí a kód pro jejich obsluhu.

Struktura dokumentu

Dokument v jazyku HTML má předepsanou strukturu:

Deklarace DTD – je povinná až ve verzi 4.01, je uvedena direktivou <!DOCTYPE.

Kořenový element – element html (značky <html> a </html>) reprezentuje celý

dokument. Kořenový element je povinný, ale otevírací a ukončovací značka samotná

povinná není (pokud tyto značky nebudou v těle dokumentu uvedeny, prohlížeč si je

sám doplní podle kontextu).

Hlavička elementu – obsahuje metadata, která se vztahují k celému dokumentu.

Definují např. název dokumentu, jazyk, kódování, klíčová slova, popis, použitý styl

zobrazení. Hlavička je uzavřena mezi značky <head> a </head>. Element head je opět

povinný, ale jeho otevírací a koncová značka povinná není, prohlížeč ji sám doplní

podle kontextu.

Tělo dokumentu – obsahuje vlastní text dokumentu. Vymezuje se značkami <body> a

</body>. Element body je povinný, ale jeho otevírací a koncová značka povinná není,

prohlížeč ji sám doplní podle kontextu.

Příklad zdrojového kódu (HTML dokument verze 4.01)

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"

"http://www.w3.org/TR/html4/strict.dtd">

<html>

<!-- toto je komentář, nezobrazuje se, slouží pro moje poznámky -->

<head>

<title>Titulek stránky uplne nahore v hlavicce okna</title>

</head>

<body>

<h1>Hlavní nadpis stránky</h1>

<p>Toto je tělo dokumentu, libovolný text</p>

</body>

154

</html>

Druhy značek

Strukturální značky dodávají dokumentu formu. Rozvrhují strukturu dokumentu, příkladem

jsou odstavce (<p>), nadpisy (<h1>, <h2>).

Sémantické značky popisují povahu obsahu elementu, příkladem je nadpis (<title>). Současný

trend je orientován právě na sémantické značky, které usnadňují automatizované

zpracovávání dokumentů a vyhledávání informací v záplavě dokumentů na webu.

Vyvrcholením této snahy je v současné době jazyk XML.

Stylistické značky určují vzhled elementu při zobrazení, typickým příkladem je značka pro

tučné písmo (<b>).

Shrnutí

HTML (Hypertext Markup Language) je standardním jazykem pro tvorbu hypertextových

dokumentů. Tento standard je spravován konsorciem W3C. V současné době je používaná

verze 4.01, a verze 5 se připravuje.

Každá webová stránka je primárně tvořena dokumentem v jazyce HTML případně rozšířeným

o další data a rozšíření.

S jazykem se pracuje pomocí značek, vyhradených slov a samotného textu.

Soubory mají příponu .htm nebo .html . Textem dokumentu je neformátovaný text. Češtinu

kódujeme jako ISO-8859-2, CP1250, nebo UTF-8.

155

35Jazyk XHTML – rozdíly oproti HTML

Co je XHTML

Poměrně často se v redakční poště objevují dotazy, co je XHTML, jak se liší od tradičního

HTML a zda má význam se jím zabývat. Protože by odpověď přesáhla rozsah rubriky dotazů,

napsal jsem raději tento článek.

Definice praví, že XHTML je reformulací HTML jako aplikace XML. Nejste z toho moudří?

Není divu. Nejprve totiž musím vysvětlit, co to je XML.

Základem je XML

Extensible Markup Language, neboli rozšiřitelný značkovací jazyk, zkráceně XML je velmi

obecný jazyk pro vytváření dokumentů obsahujících alespoň částečně strukturovaná data.

Něco podobného, jako jsou databáze (třeba Access, nebo stará dobrá Foxka). S databázemi

byla ale vždy potíž — co výrobce, to jiný formát, navíc jsou zde omezení daná relačním

modelem.

Proto vzniklo XML. Není sice vhodné pro ukládání rozsáhlých dat, zato přináší standardní a

tudíž obecně "srozumitelný" formát. Proto je velmi vhodné zejména pro výměnu dokumentů

(např. objednávek či faktur), komunikaci (např. mezi 2 aplikačními servery v internetu), ale i

pro prezentaci informací na WWW.

Dost však teorie, XML nejlépe pochopíte na praktickém příkladu.

<article>

<title>Javascript napříč okny prohlížeče</title>

<perex>Rámce, okna, a JavaScript podle Martina Kopty</perex>

<url>http://www.sovavsiti.cz/c01211.html</url>

</article>

<article>

<title>Jak psát nadpisy</title>

<perex>Jak psát nadpisy, aby upoutaly vaše návštěvníky</perex>

<url>http://www.sovavsiti.cz/c01212.html</url>

</article>

156

To, co zde vidíte je popis dvou článků Sovy ve formátu pro systém WebSpy (přibližně). V

podstatě se jedná o XML, s jehož pomocí jsou popsány jednotlivé články (prvek <article>) a

jejich tituly, perexy a url. Jelikož znáte HTML, je to jednoduché, že ano.

Zkusme si nyní do tohoto popisu článků doplnit ještě údaje o autorovi článků. Lze to udělat

dvojím způsobem. Buď přidáme nový prvek <author>, nebo použijeme atribut prvku

<article>. První způsob by vypadal takto:

<article>

<author>Martin Kopta</author>

<title>Javascript napříč okny prohlížeče</title>

<perex>Rámce, okna, a JavaScript podle Martina Kopty</perex>

<url>http://www.sovavsiti.cz/c01211.html</url>

</article>

a druhý takto:

<article author="Martin Kopta">

<title>Javascript napříč okny prohlížeče</title>

<perex>Rámce, okna, a JavaScript podle Martina Kopty</perex>

<url>http://www.sovavsiti.cz/c01211.html</url>

</article>

Na rozdíl od tradičního HTML, má však XML o něco přísnější pravidla. Např. všechny názvy

značek (tagů) a atributů musí být malými písmeny, všechny prvky musí být uzavřeny (i

nepárové značky), atd. A na rozdíl od HTML, XML žádné značky předem nedefinuje.

Kdybych v příkladu výše použil <clanek> místo <article> a <nazev> místo <title>, bylo by to

stále platné a správně strukturované (well-formed) XML.

Nyní si jistě řeknete, k čemu je vlastně XML dobré, když je definováno jen pár syntaktických

pravidel a nic víc. Vždyť dáme-li náš příklad Číňanovi, stejně z něho nic nepochopí. Tak

jakýpak univerzálně srozumitelný jazyk? A máte pravdu. Aby náš příklad měl smysl a

alespoň dva lidé si takto mohli předávat data, musí se dohodnout, co jaká značka znamená.

Takové dohodě se říká aplikace XML.

157

Aplikace XML

Jednoduše shrnuto, XML je vlastně jakýsi "nadjazyk" a jeho aplikace pak jsou již konkrétními

jazyky pro praktické použití. Aplikace mohou k základnímu XML přidávat další pravidla a

tím ho omezovat a významově zpřesňovat. Např. jedno pravidlo pro náš příklad říká, že prvek

<article> musí obsahovat právě jeden prvek <title>. Zároveň však, a to je zásadní, musí každá

aplikace dodržovat základní množinu pravidel XML.

Dnes již existuje mnoho aplikací XML používaných okrajově, většinou privátně. Existují ale i

aplikace všeobecně rozšířené, například jazyk pro transformaci jedné aplikace XML do druhé.

Dokonce i jazyk, kterým se definují upřesňující pravidla aplikací XML, tzv. DTD (Document

Type Definition, definice typu dokumentu) je aplikací XML. A jednou z aplikací XML je i

XHTML.

XHTML

Jak jste si jistě všimli na uvedeném příkladu, XML se od HTML, kromě použitých značek,

moc neliší. Proto se od HTML ani nijak podstatně neliší XHTML. Trochu jinak vypadá

definice typu dokumentu (první řádek), hlavička, která je povinná, o malých písmenech a

povinných koncových značkách už jsem hovořil. K tomu patří ještě uvozovky, do kterých se

povinně uzavírají hodnoty atributů a je to skoro vše.

Proč tedy o XHTML vůbec uvažovat a proč se ho učit? Stojí to za to? Dle mého názoru, stojí.

Většina expertů se totiž shoduje, že XML a tím pádem i XHTML patří budoucnost. Důvodů je

několik, mj.:

Díky přísným a zároveň jednoduchým pravidlům, mohou počítače XML a tedy i XHTML velmi snadno automatizovaně zpracovávat. Kdyby prohlížeči stačilo "umět" XHTML, byl by mnohem jednodušší (a tedy menší a rychlejší), než když musí zvládat veškeré "nevyzpytatelnosti" HTML.

Všechny aplikace XML mohou s výhodou těžit ze stejného základu syntaktických pravidel. Již nyní tedy existuje mnoho univerzálních programů a knihoven funkcí, které velmi usnadňují vznik a implementaci každé nové aplikace XML.

158

Dá se očekávat, že právě díky vyšší srozumitelnosti počítačům, budou časem stránky vytvořené v XHTML "oblíbenější" u vyhledávačů, katalogů stránek, výměnných reklamních systémů a dalších automatizovaných služeb.

Dříve nebo později začnou prohlížeče podporovat pouze XHTML (případně jiné aplikace XML) a neuškodí, budete-li na to připraveni. Mimochodem IE již od verze 4 a NN od verze 6 "umí" čisté XML a v kombinaci s CSS, nebo ještě lépe XSL (obdoba CSS v XML) s ním dokáže velmi zajímavé věci.

Zbývá poslední otázka, zda se již dnes vyplatí převést vaše HTML dokumenty do XHTML. Po pravdě řečeno si to nemyslím. Snížíte tím kompatibilitu svých stránek se staršími prohlížeči, zkomplikujete si práci s JavaScripty a nic moc positivního nezískáte. To však brzy nemusí platit. Určitě tedy stojí za to XML a XHTML alespoň trochu nastudovat.

Rozdíly

Všechny hodnoty atributů jsou v uvozovkách

V HTML se nemusejí hodnoty atributů, které neobsahují mezeru, uzavírat do uvozovek. Když

například napíšu kód pro obrázek

<img src=obrazek.gif width=100 height=91>

tak to bude v prohlížečích fungovat a podle starších verzí HTML to je i správný zápis. V

XHTML se ale kolem všech hodnot vyžadují uvozovky:

<img src="obrazek.gif" width="100" height="91" />

Dávat uvozovky kolem hodnot je mimochodem dobrý mrav i v normálním HTML. Kód je

rozhodně přehlednější a lépe se automaticky zpracovává.

Uvozovky se mohou nahradit apostrofy:

<a href='adresa'>odkaz</a>

Zákaz křížení tagů

Toto se třeba nesmí:

<b><i>tučná kurzíva</b></i>

takto je to správně:

<b><i>tučná kurzíva</i></b>

159

Křížení tagů se samozřejmě nesmělo už v HTML. Ironií zůstává, že když takovouto neplatnou

křížovou konstrukci vyrobíte, prohlížeče to většinou vezmou a pochopí. XML parser to

nevezme a nepochopí.

Tagy a atributy jsou malými písmeny

V HTML bylo jedno, jestli se píše <A HReF="..."></a> nebo <a href="..."></A>. HTML je

tedy jazyk non-case sensitivní, takže v něm na velikosti písmen nezáleží.

Naopak XHTML je jazyk case sensitivní a na velikosti písmen v něm záleží (jako v každém

jiném XML).

Navíc, podle specifikace se všechny tagy a atributy píšou malými písmeny. Takže například

<a href="...">Odkaz</a> je v XHTML správně

ale

<A HREF="...">Odkaz</a> je v XHTML špatně

Další příklady doufám nejsou potřeba. Já k tomu dodám dva postřehy:

* Pokud náhodou napíšete nějaký tag nebo atribut velkým písmenem, je to sice jako špatně,

ale v prohlížeči by to problém dělat nemělo.

* Já osobně striktně doporučuji psát všechny tagy a jejich atributy malými písmeny, i když

píšete v HTML! Nadělá se pak méně chyb při případném automatickém zpracování.

Nepárové tagy končí lomítkem

V HTML je spousta tagů nepárových. Například obrázek (<img>) nebo čára (<hr>). V XML -

- a tedy i v XHTML -- nic jako nepárový tag neexistuje. Když to vezmu na příkladu

horizontální čáry (tag <hr>), tak:

* v HTML je to nepárový tag <hr>

* což se v XHTML musí rozšířit na párový tag <hr></hr>

* který se vzápětí může smrsknout na <hr />. To lomítko tam znamená, že už se to nebude

uzavírat.

Takže zjednodušeně řečeno nepárové tagy v sobě mají na konci lomítko. Taková úprava je co

do funkčnosti zpětně kompatibilní s HTML -- když do HTML tagu napíšete lomítko, tak to

prohlížeč pochopí jako neznámý parametr a ignoruje to. Proto nepárové tagy s lomítkem

nedělají problémy v HTML ani v XHTML.

Opět si musíte uvědomit, že pokud píšete v XHTML a to lomítko tam nedáte, tak sice nemáte

validní zápis, ale v prohlížeči to fungovat bude.

160

Na druhou stranu pokud píšete v HTML, tak lomítko jako neznámý parametr není v HTML

validní. To sice prakticky nevadí, ale občas je to k smíchu. Vždycky si představím toho

bastliče, jak sice píše HTML, ale aby šel s módou, tak tam práská lomítka, aniž by věděl, proč

to dělá.

Pamatujte: před zavíracím lomítkem má být mezera.

Shrnutí o lomítku:

Toto je správně v HTML:

<br>

a toto je správně v XHTML:

<br />

a v obou případech v prohlížečích funguje oboje.

Párové tagy jsou párové povinně

Prohlížečům nevadí, když se nějaký tag občas neuzavře. Například tag <p> se nemusel dříve

uzavírat, protože když prohlížeč na stránce viděl další tag <p>, tak si ten předchozí v duchu

uzavřel -- to protože jeden odstavec nemůže být částí druhého. Nebo podobně to funguje u

buněk tabulky -- u tagu <td>. Když začnu jedno <td>, neuzavřu ho (nedám tam </td>) a pak

napíšu další <td>, tak si prohlížeč řekne: aha, další buňka, to ta předtím skončila. A chybějící

</td> si doplní. (Podobně funguje např. tag. option.)

Takový přístup je v praxi přípustný (ačkoliv jej nedoporučuji). Starší verze HTML

neuzavírání některých tagů akceptovaly. Novější verze HTML a XHTML neuzavírání

párových tagů zapovídají. Všechny párové tagy se tedy musejí uzavírat a mít v dokumentu

svůj protějšek.

Samozřejmě doporučuji všechny tagy striktně zavírat, ať už píšete v XHTML nebo v HTML.

Co konkrétně prohlížeč vydejchá, pokud nechcete některé tagy uzavírat, musíte vždycky

vyzkoušet.

Všechny atributy musejí mít hodnotu

V HTML se občas vyskytují atributy, které namají hodnotu. Třeba u tagu select (rozevírací

nabídka) se vyskytují atribut multiple nebo disabled. Atribut multiple například dovoluje

vybrání více položek z nabídky (podržením klávesy Ctrl) a do kódu se v HTML zapisuje

například takto:

<select name="auta" size="3" multiple>

161

... několik tagů <option> ...

</select>

Podstatné je to multiple, všimněte si, že nemá hodnotu (není tam žádné multiple rovná se

něco).

V XHTML je ale atribut bez hodnoty zakázaný. Aby byl zápis zpětně kompatibilní s HTML,

přidává se atributu v XHTML nějaká vycpávková hodnota. Takže například

multiple="multiple"

Výše uvedený příklad se selectem v XHTML vypadá takto:

<select name="auta" size="3" multiple="multiple">

... několik tagů <option> ...

</select>

Jediná změna je tam to ="multiple".

Podobně se rozvádějí další atributy, např. disabled="disabled", readonly="readonly" (oboje u

formulářových polí), noresize="noresize" u tagů <frame> a <iframe> apod.

Souhrnný příklad

Všechno se píše malými písmeny a ty značky, kterým se říká "párové", musí být uzavřené.

Všechny atributy musí mít přiřazenu hodnotu, všechny hodnoty atributů musí být v

uvozovkách (i čísla).

Například takovýhle HTML kód:

<select multiple>

<option>opt1

<option>opt2

</select>

<img src="x.jpg" width=10 height=10>

V XHTML se tentýž kód zapíše takhle:

<select multiple="multiple">

<option>opt1</option>

162

<option>opt2</option>

</select>

<img src="x.jpg" width="10" height="10" />

Na začátku je XML deklarace (prolog)

<?xml version="1.0" encoding="iso-8859-2"?>

<?xml version="1.0" encoding="windows-1250"?>

<?xml version="1.0" encoding="UTF-8"?>

Samozřejmě záleží na použitém kódování. Pozor, tento zápis nenahrazuje meta tag pro

kódování češtiny (zejména Google pak může mít problémy). V praktickém použití na webu se

tento prolog většinou vypouští, protože (ačkoli tak vzniká neplatný dokument) Explorer 6

chce mít na prvním řádku doctype.

163

36Kaskádové styly CSS – selektory, vlastnosti, kaskáda

a dědičnost, řádkové a blokové elementy, box model,

plovoucí prvky, pozicování

Klíčová slova

Kaskádové styly, css, web, CSS styly, formátování (x)HTML, dědičnost, pozicování

Charakteristika

CSS je kolekce metod pro grafickou úpravu webové prezentace. Zkratka CSS znamená

Cascading Style Sheets, česky "kaskádové styly". Kaskádové, protože se na sebe mohou

vrstvit definice stylu, ale platí jenom ta poslední. Bez kaskádových stylů (CSS) si už dnes

moderní web nelze představit.

Základní vlastnosti CSS

CSS definují vzhled dokumentu nezávisle na jeho obsahu

Styly umožňují přesně určit, jak bude který element vypadat

Řídí se standardy a pravidly W3C

Ve srovnání s formátováním pomocí atributů v HTML formátovací schopnosti

rozšiřuje

Musí být ve spojení s (x)HTML kódem ((x)HTML definuje pouze strukturu a obsah

dokumentu)

Jeden styl můžeme snadno použít pro libovolné množství stránek

CSS nabízí mnohem větší možnosti a volnost ve formátování stránek než pouhé

(X)HTML

Pomocí CSS se jednak zbavíme velkého množství kódu, jednak se tento kód stane

mnohem přehlednější

Řádkové a blokové elementy

Řádkové – neovlivňují tok textu

- <b>, <i>, <u>, <tt>, <s>, <strike>, <akronym>, <del>, <strong>, <em>, <cite>, <code>,

<dfn>, <ins>, <q>, <abbr>, <samp>, <span>

Blokové – způsobují zalomení řádku a mohou způsobit odsazení

164

<p>, <br />, <center>, <h1> - <h6>, <blockquote>, <address>, <pre>, <hr />

Použití CSS

Styl můžeme k dokumentu připojit několika způsoby, můžeme definovat přímo v dokumentu

nebo v externím souboru, způsoby můžeme i kombinovat.

Externí soubor s CSS

CSS styl můžeme mít uložený v externím souboru (což je velmi výhodné při používání

jednoho stylu pro více dokumentů. Ten pak připojíme k dokumentu zápisem v hlavičce (tj.

mezi tagy <head> a </head>).

<link rel="stylesheet" type="text/css" href="styl.css" />

Přímý styl

CSS se uvede na začátku každého (X)HTML dokumentu (v hlavičce).Formátování

jednotlivých prvků se zapisuje mezi tagy <style> a </style>.

<style type="text/css">html {padding:0;margin:0}</style>

Inline zápis

CSS příkazy se zapíší přímo k potřebným tagům do atributu „style“.

<H3 "style=text-decoration: underline">nadpis</H3>

Základní pojmy

Pravidlo = definované pravidlo pro zobrazení daného prvku

Selektor = určuje, na které elementy se dané pravidlo použije

Třída = pravidlo platí pro elementy s danou hodnotou atributu class

Identifikátor = pravidlo platí pro elementy s danou hodnotou atributu id,

identifikátor musí být v rámci dokumentu jediněčný

Definice = definované vlastnosti a hodnoty v dané třídě

Vlastnosti = definují vizuální vlastnosti daných elementů, každá vlastnost má

jméno

Hodnoty = konkrétní hodnoty u CSS vlastností (vlastnosti s danými hodnotami

se oddělují středníkem)

165

Důležitost stylů

Pokud ve stylu definujeme pro stejný element stejnou vlastnost dvakrát, vyšší váhu má ta

deklarace, která byla definovaná později (myšleno na pozdějším řádku) a ta se také provede.

Pokud bychom chtěli některé deklaraci přiřadit větší důležitost, použijeme !important.

h1 {color: white !important}

Dědičnost

Většina hodnost CSS vlastností se dědí na jejich potomky. To znamená, že element, který

nemá vlastnost definovanou jí dědí po nadřazeném elementu. Týká se to především vlastností

písma — barvy, velikosti, stylu atd. Pokud tedy chceme definovat nějakou vlastnost, kterou

budou mít všechny elementy společnou, definujeme ji např. pro element body.

body {color:gray} ( h3 {} dědí barvu písma)

Box model

Model popisující rozměry libovolného objektu na stránce. Objektu můžeme nastavit jeho

výšku, šířku, rámeček, vnější či vnitřní okraje, ořezávání, ad.

.box {width:200px; height:300px; padding:10px 0; margin:3px; overflow:auto; bordur: 1px

solid lime}

Plovoucí prvky

Objekty obtékané okolním obsahem se stávají zároveň objekty blokovými. Každý plovoucí

element musí mít nastavenou šířku. Plovoucí objekt je vyjmut z ostatního textu a je odsunut

ke kraji rodičovského prvku.

.box {float:left}

Pozicování

Ruční nastavení polohy objektu na stránce. Může být absolutní (objekt je umístěn na stránce

nezávisle na ostatním obsahu) nebo relativní (objekt je posunut oproti jeho normální pozici na

stránce).

.box {position:absolute; top:30px; left: 10%}

166

37Skriptování na straně klienta – JavaScript

Přístupnost webových stránek

Definice

Skript = zdrojový kód programu, který je interpretovaný (čtený, překládaný a vykonávaný za

jeho běhu).

Klient = v počítačové terminologii se jedná o počítač resp. program, který využívá služeb

jiného počítače resp. programu. V našem případě prohlížeč www stránek.

Skriptování na straně klienta = spouštění skriptů v prohlížeči www stránek.

Přístupnost = bezbariérovost

Přístupnost webu = charakteristika webu, která vyjadřuje míru jeho použitelnosti pro

všechny skupiny uživatelů, včetně těch se zdravotním nebo mentálním omezením,

s omezenými hardwarovými a/nebo softwarovými prostředky, robotů.

Klíčová slova

Skript (script), skriptování (scripting), skriptování na straně klienta (client side scripting),

JavaScript, VBScript, přístupnost, Novela zákona č. 365/2000 Sb.

Skriptování na straně klienta

Od počátku samotného internetu byl jeho podstatou jazyk HTML pro tvorbu dokumentů.

Jazyk HTML je vhodný pro návrh struktury dokumentů, která je ovšem statická, neměnná.

S informačním boomem a celosvětovým rozvojem internetu přestali uživatelům, ale hlavně

provozovatelům webových stránek, webmasterům a webdesignerům statické dokumenty

přestávaly stačit.

Pro přidání dynamičnosti a interaktivity do stránek jsou dvě možnosti, konkrétně

skriptování na straně serveru (server side scripting) a skriptování na straně klienta (klient side

scripting). Každá z těchto možností má své výhody a nevýhody, proto se časem uplatnili obě,

které se obvykle kombinují.

Výhody skriptování na straně klienta

Výpočetně nezatěžují server, ale klienta (byť nepatrně, na straně serveru by se však

mohlo sejít i tisíce požadavků za sekundu)

Mají přístup k prostředkům prohlížeče (sice omezený, ale server side skripty jej

nemají vůbec)

Umí ošetřit události na straně klienta rychleji a efektivněji, než skripty na straně

serveru, které většinu událostí neumí ošetřit vůbec.

Ošetřením událostí na straně klienta snižují přenos dat a požadavky na výpočetní

výkon serveru.

Používané skriptovací jazyky na straně klienta

167

(Server side) JavaScript – je nejrozšířenější, podporují jej téměř všechny prohlížeče

dovolující skriptování na straně klienta, vyvinut a zaveden společností Netscape. Microsoft ve

svých prohlížečích používá jeho ekvivalent pod názvem JScript.

VBScript – skriptovací jazyk z dílny Microsoftu vycházející z jazyků Visual Basic (VB) a

Visual Basic for Applications (VBA), je podporován jen prohlížeči společnosti Microsoft a

nyní s nárůstem podílu alternativních prohlížečů (např.: Mozilla Firefox, Opera) se již téměř

nepoužívá.

Charakteristika JavaScriptu

Interpretovaný – je jazykem, který je přeložen a vykonán až za jeho běhu.

Objektový – využívá objektů prohlížeče a zabudovaných objektů, umí tvořit vlastní.

Závislý na prohlížeči – funguje ve většině prohlížečů, ale s různou podporou.

Case sensitive – rozlišuje malá a velká písmena. Např.: promenna, Promenna a

PrOmEnNa jsou z pohledu JavaScriptu tři různé identifikátory (názvy).

Velmi jednoduchý a podobný Javě, jazyku C a C++.

Omezení JavaScriptu

Funguje pouze v prohlížeči, nemá přístup k prostředkům serveru.

Uživatel jej může vypnout (a cca 1% uživatelů to i dělá)

Různé prohlížeče mají zabudovanou podporu různých verzí JavaScriptu, některé jej

nepodporují vůbec.

Z bezpečnostních důvodů neumí přistupovat k souborům (kromě cookies) a neumí

(kromě cookies) ukládat data.

Seznam zdrojů

Wikipédie, otevřená encyklopedie [online]. 2007 [cit. 2007-11-03]. Dostupný z WWW:

<http://cs.wikipedia.org/wiki/Hlavn%C3%AD_strana>.

JANOVSKÝ, Dušan. Jak psát web : návod na HTML stránky [online]. [2004- ] , 12. října

2007 [cit. 2007-10-14]. Dostupný z WWW: <http://www.jakpsatweb.cz/>.

Přístupnost webových stránek

K internetu má přístup spousta lidí a nemalé procento z nich trpí zdravotním omezením

nebo postižením. Nejčastěji to bývají lidé se zrakovým a sluchovým postižením, poruchou

učení, soustředění nebo postižením pohyblivosti horních končetin. Ovšem ani zdraví lidé

nepoužívají vždy standardní software a hardware a některé softwarové nebo hardwarové

prostředky nemusí mít k dispozici. Toto omezení nebo postižení jim prohlížení stránek

ztěžuje, u těch špatně navržených jim prohlížení zcela znemožňuje.

Proto existují všeobecně známá a platná pravidla pro přístupnost webových stránek, která

jsou různou měrou (ne)respektována. Stránky, které jsou navrženy s ohledem na maximální

přístupnost, můžou zvýšit svou návštěvnost až o 30%.

Přístupnost a legislativa

Některé země přístupnost webů uzákonily:

Země Pro koho je závazná povinnost přístupnosti

Česko, USA Instituce veřejné správy a samosprávy

168

Velká Británie Všechny weby financované z veřejných rozpočtů

Německo Všechny subjekty, které zaměstnávají zaměstnance.

Pravidla přístupnosti www stránek:

Novela zákona č. 365/2000 Sb. (ČR)

Section 508 (USA)

WCAG2.0 (doporučení World Wide Web Consorcium – W3C)

Rozdělení zásad přístupnosti

Většina norem rozděluje zásady pro přístupnost do tří skupin:

1. Priorita 1 – web musí splňovat dané pravidlo, jinak je nepřístupným pro

hendikepované uživatele

2. Priorita 2 – web by měl splňovat danou zásadu, jinak je obtížně přístupný pro některé

skupiny uživatelů

3. Priorita 3 – web by mohl splňovat danou zásadu, aby umožnil přístup co největšímu

počtu uživatelů

Česká norma rozděluje zásady přístupnosti do šesti skupin:

Obsah webových stránek je dostupný a čitelný

Netextové prvky, které nesou nějaké významové sdělení, mají textovou alternativu pro

uživatele, kteří nemohou nebo nechtějí pracovat s obrázky, skripty, objekty, applety, styly.

Text je dostatečně kontrastní a bez rušivých vzorků na pozadí a viditelný i bez barevného

rozlišení. Velikost písma je zadávána relativně.

Práci s webovou stránkou řídí uživatel

Webová stránka svévolně nemění svůj obsah ani uživatelské prostředí. Nová okna se otevírají

jen v odůvodněných případech a jen na základě předchozího upozornění uživatele. Na stránce

nebliká nic rychleji než 1 krát za sekundu, nebrání uživateli posouvat obsahem rámů a hlavně

nelze předpokládat použití konkrétního výstupního nebo ovládacího zařízení na straně

uživatele.

Informace jsou srozumitelné a přehledné

Informace jsou sdělovány jednoduchou formou a jednoduchým jazykem. Úvodní stránka

jasně popisuje smysl a účel webu, hlavní sdělení každého webu je na jejím počátku. Rozsáhlé

textové celky jsou rozděleny do menších bloků a jsou výstižně nadepsány.

Ovládání webu je jasné a pochopitelné

Každá stránka je pojmenovaná tak, aby smysluplně vystihovala svůj obsah. Navigace webu je

srozumitelná a konzistentní, obsah a navigace jsou zřetelně odděleny. Navigací lze vždy přejít

na úvodní stránku nebo na vyšší stránku v hierarchii stránek, kromě té úvodní. U rozsáhlejších

webů by neměla chybět mapa stránek.

Obsah kódu stránky nesmí předpokládat, že uživatel již navštívil jinou stránku! Každý rám

má výstižné jméno a každý formulářový prvek je nadepsán.

169

Odkazy jsou zřetelné a návodné

Cíl každého odkazu je zřetelný i bez jeho okolního kontextu a každý odkaz je od zbytku textu

odlišen nejen barevně. Stejně pojmenované odkazy mají stejný cíl. Vede-li odkaz na jiný

dokument, než je webová stránka, je na to jasně upozorněn, včetně typu a velikosti cíle.

Kód je technicky způsobilý a strukturovaný

Kód odpovídá některé specifikaci (X)HTML a je bez chyb. Je v něm uvedena použitá

znaková sada pomocí META elementu. Nadpisy a seznamy se tvoří pomocí odpovídajících

elementů, naopak pomocí těchto elementů nejsou tvořeny žádné jiné prvky. Pro popis vzhledu

se používá CSS. Tabulky obsahující tabulková data jsou vybaveny záhlavím řádků a sloupců,

naopak tabulky pro rozvržení stránky je neobsahují. Tabulky dávají smysl, jsou-li čteny po

řádcích.