SZZ INFON26 – Státní závěrečná zkouška

II · 1

Generativní gramatika a její použití pro definici formálních jazyků, regulární jazyky, bezkontextové jazyky, Chomského hierarchie formálních jazyků.

📋 Co je generativní gramatika?

Chceme popsat programovací jazyky matematicky přesně — říct, která slova (programy) jsou „správná" a která ne. K tomu slouží formální gramatika (= matematicky přesná sada pravidel, jak se slova jazyka tvoří). Noam Chomsky rozdělil všechny gramatiky do 4 tříd podle toho, jak složitá pravidla povolují. Každá třída rozpoznává jiný typ jazyka jiným typem počítače. Klíčová čtveřice gramatiky: (N, T, P, S) — proměnné, hotové symboly, pravidla a výchozí symbol.

📐 Vysvětlení čtveřice: N = neterminály = „proměnné" (zatím nehotové, ještě se přepíší na něco jiného). T = terminály = „hodnoty" (finální symboly, z nichž se skládá výsledné slovo). P = přepisovací pravidla (říkají, co se na co přepíše). S = startovací symbol (odkud se začíná generovat). N a T jsou disjunktní (= nemají žádný společný prvek, nesdílejí nic).

🔤 Základní pojmy

🔡 Abeceda (V) — neprázdná konečná množina symbolů (např. {a, b, 0, 1})

📝 V* — množina všech slov nad V, včetně prázdného slova (ε = epsilon = prázdné slovo, slovo bez jediného symbolu)

📝 V+ — totéž jako V*, ale bez prázdného slova (aspoň 1 symbol)

🗣️ Slovo — řetězec prvků abecedy konečné délky

📚 Jazyk L — libovolná podmnožina V* (= sada slov, která „patří" do jazyka)

🏗️ Čtveřice (N, T, P, S)

🔵 N — neterminály = proměnné (ještě se přepíší, jsou „rozpracované")

🟢 T — terminály = hodnoty (finální symboly, tvoří výsledné slovo)

📜 P — přepisovací pravidla (tvar závisí na typu gramatiky)

🎯 S — startovací symbol (vždy z N; odvozování začíná tady)

N a T jsou disjunktní (bez společných prvků); výsledné slovo obsahuje jen symboly z T

🟩 Regulární jazyky (Typ 3) — nejslabší

Pravidla pouze ve tvaru: A → aB nebo A → a

Číst jako: „neterminál A se přepíše na terminál a + neterminál B"

➡️ Pravá lineární: neterminál (= proměnná) je vždy napravo

⬅️ Levá lineární: neterminál je vždy nalevo

⚠️ Levou a pravou nelze kombinovat

Rozpoznává: Konečný automat (KA) — počítač bez paměti

Příklad: jazyk všech řetězců začínajících 'a'

🟦 Bezkontextové jazyky (Typ 2)

Pravidla ve tvaru: A → α kde α (alfa) = libovolný řetězec terminálů a neterminálů

Na levé straně je vždy jen jeden neterminál — bez „kontextu" (= sousedů)

Rozpoznává: Zásobníkový automat (ZA) — má navíc zásobník (= pamětový stack)

Příklad: párování závorek (()()) — regulárním automatem nerozpoznatelné

📌 CNF (Chomského normální forma): každé pravidlo ve tvaru A→BC nebo A→a; slouží pro efektivní parsery

🟧 Kontextové jazyky (Typ 1)

Pravidla ve tvaru: αAβ → αγβ

Čteme: „α (alfa) = levý kontext, β (béta) = pravý kontext — neterminál A se přepíše na γ (gama = neprázdný řetězec) pouze pokud je obklopen právě tímto kontextem"

Rozpoznává: Lineárně ohraničený Turingův stroj

🟥 Obecné/frázové jazyky (Typ 0) — nejsilnější

Na pravidla nejsou kladena žádná omezení — vše je dovoleno

Zahrnují všechny formální jazyky

Rozpoznává: Turingův stroj (neomezená paměť)

📊 Chomského hierarchie

Typ	Název gramatiky	Tvar pravidel P	Generuje	Rozpoznává
0	Obecná (neomezená)	bez omezení	Obecné jazyky	Turingův stroj
1	Kontextová	αAβ → αγβ (A s kontextem)	Kontextové jazyky	Lineárně ohraničený TS
2	Bezkontextová	A → α (A sám, bez sousedů)	Bezkontextové jazyky	Zásobníkový automat
3	Regulární	A → aB nebo A → a	Regulární jazyky	Konečný automat (KA)

💡 Intuitivní příklad

Regulární: „všechna slova nad {a,b} začínající 'a'" — KA zvládne (žádná paměť nepotřeba). Bezkontextový: „stejný počet 'a' a 'b'" jako aabb, aaabbb — KA to nezvládne (nemá kde si pamatovat count), zásobníkový automat ano. Kontextový: „stejný počet a, b, c" (aabbcc). Obecný: cokoliv co Turingův stroj rozpozná.

⚠️ Časté záludnosti

❌ Levou a pravou lineární gramatiku nelze kombinovat v jedné regulární gramatice.

❌ „Bezkontextová" neznamená, že nemá kontext — jde o to, že neterminál na levé straně je sám, bez sousedů (není „v kontextu").

❌ CNF ≠ Chomského hierarchie — CNF (Chomského normální forma) je speciální tvar Typ 2 gramatiky, hierarchie je klasifikace všech čtyř typů.

❌ Typ 3 ⊂ Typ 2 ⊂ Typ 1 ⊂ Typ 0 — vyšší číslo = přísnější omezení = slabší gramatika, menší třída jazyků.

❌ Jeden jazyk může mít více různých gramatik — gramatika není jazyk, je to jen jeden způsob jeho popisu.

🧩 Laicky — analogie z kuchařky

Gramatika je jako kuchařský recept. N (neterminály) jsou mezivýrobky: „těsto", „omáčka" — ještě nejsou hotové, musí se dál zpracovat. T (terminály) jsou finální suroviny: „mouka", „vejce" — to už se nepřepíše na nic jiného, to je výsledek. P (pravidla) jsou kroky receptu: „těsto → mouka + vejce + voda". S je název výsledného pokrmu: „svíčková". Čím přísnější omezení pravidel (Typ 3 → Typ 0), tím složitější jídla dokážeš uvařit — ale potřebuješ silnější „kuchyni" (automat).

🎓 Napojení na DP

II · 2

Konečné deterministické a nedeterministické automaty a jejich vztah k regulárním jazykům, regulární automaty a regulární výrazy.

📋 Co jsou konečné automaty (KDA/NDA) a regulární výrazy?

Konečný automat je nejjednodušší teoretický počítač — nemá žádnou paměť kromě informace, v jakém je právě stavu. Čte symboly ze vstupu jeden po druhém a přechází mezi stavy. Pokud po přečtení celého vstupu skončí v „přijímacím" stavu, slovo patří do jazyka. Deterministický (DFA) má pro každý symbol vždy právě jeden možný přechod. Nedeterministický (NFA) může mít více možných přechodů najednou — nebo i přechody bez čtení symbolu (ε-přechody = epsilon přechody = „skoky zadarmo" bez spotřeby vstupu). Obě varianty rozpoznávají přesně stejnou třídu jazyků — regulární jazyky. Třetím způsobem popisu téže třídy jsou regulární výrazy.

📖 Slovníček symbolů v definici KA

🔵 S — konečná množina stavů (= všechny možné „situace", ve kterých automat může být)

🔤 Σ (sigma velké) — vstupní abeceda (= množina symbolů, které automat umí číst)

🔁 δ (delta) — přechodová funkce: říká „v jakém stavu + jaký symbol čteš → do jakého stavu přejdi"

🟢 s — počáteční stav (odkud automat začíná)

✅ F — množina přijímacích (koncových) stavů (= „cíle", po jejichž dosažení automat řekne ANO)

🔤 ε (epsilon) — prázdné slovo / prázdný přechod (= přechod bez čtení jakéhokoli symbolu)

⚙️ Formální definice KA — pětice

🔵 S — konečná množina stavů

🔤 Σ (sigma) — vstupní abeceda

🔁 δ (delta) — přechodová funkce: (stav × symbol) → nový stav

🟢 s — počáteční stav

✅ F — přijímací stavy (podmnožina S, tedy F ⊆ S, čteme: F je podmnožina S)

Slovo je přijato ⟺ (právě tehdy, když) po přečtení celého vstupu je automat ve stavu z F

🔤 Regulární výrazy — operace

🔗 Konkatenace (= spojení, zřetězení): ab — nejprve a, pak b. Jako přilepení slov k sobě.

↔️ Alternace (= výběr, nebo): a|b — buď a, nebo b

🔄 Iterace (= opakování): a* — nula nebo více opakování a (hvězdička = Kleeneova uzávěra)

📌 Příklady:

(a|b)* — všechny řetězce nad {a,b}

a*b* — libovolně a, pak libovolně b

Každý reg. výraz ↔ ekvivalentní KA a naopak

📊 DFA vs NFA — srovnání

Vlastnost	DFA (deterministický)	NFA (nedeterministický)
Přechody na symbol	Právě 1 (nebo 0 = zamítnutí)	0, 1 nebo více najednou
ε-přechody (bez čtení symbolu)	❌ Nemá	✅ Povoleny
Možné cesty výpočtu	Vždy 1 deterministická	Paralelně více cest
Přijímá, pokud…	Skončí v F	Alespoň 1 cesta skončí v F
Implementační složitost	Jednodušší	Složitější (simulace)
Rozpoznávané jazyky	Identické — regulární jazyky (Typ 3)

🔄 Determinizace: NFA → DFA

Determinizace = převod nedeterministického automatu na deterministický. Algoritmus se nazývá podmnožinová konstrukce (subset construction): stavy výsledného DFA jsou podmnožiny stavů NFA. Počet stavů může vzrůst exponenciálně (NFA s n stavy → DFA až 2ⁿ stavů), ale vyjadřovací síla zůstane stejná.

🌐 Použití regulárních automatů v praxi

🔍 Lexikální analýza v překladačích (rozpoznávání tokenů — klíčových slov)

✅ Validace vstupů (email, PSČ, datum, tel. číslo)

🔎 Vyhledávání vzorů v textu (grep, sed v terminálu)

🌐 Síťové protokoly (stavové stroje)

✅ DFA vs NFA — kdy co použít

⚡ DFA — pro implementaci (rychlý, jednoznačný)

✏️ NFA — pro návrh (pohodlnější na popis, méně stavů)

🔄 Workflow: navrhni NFA → deterministizuj na DFA → implementuj DFA

💡 Příklad z praxe

Validace emailu pomocí regulárního výrazu [A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,} — prohlížeče a jazyky (Python re, Java Pattern) tuto šablonu převedou na NFA a deterministizují na DFA pro efektivní zpracování. Grep v terminálu je regulární automat v akci.

⚠️ Časté záludnosti

❌ NFA není silnější než DFA — rozpoznávají přesně stejnou třídu jazyků (regulární). NFA je jen pohodlnější pro návrh.

❌ Převod NFA→DFA může exponenciálně zvýšit počet stavů (až 2ⁿ), ale vyjadřovací síla zůstane stejná.

❌ Regulární výrazy popisují pouze regulární jazyky — nelze jimi popsat párování závorek (to je bezkontextový jazyk, Typ 2).

❌ δ (delta = přechodová funkce) u DFA je totální — definovaná pro každou kombinaci stavu a symbolu; u NFA může být parciální (0 přechodů = zamítnutí té cesty).

🧩 Laicky — turniket v metru

Konečný automat funguje přesně jako turniket: má dva stavy (zamčeno / odemčeno), přechází dle vstupu (vložíš žeton → odemkne, projdeš → zamkne zpět). Deterministický automat = turniket, kde každá akce má přesně jeden výsledek. Nedeterministický automat = kouzelný turniket, který může při stejném vstupu jít do více stavů najednou — stačí, aby alespoň JEDNA z těchto cest dovedla do cíle. Regulární výraz [A-Z][a-z]+ interně řeší právě takovýto automat.

🎓 Napojení na DP

II · 3

Konečné automaty jako akceptory a převodníky, Mealyho a Moorův automat.

📋 Co jsou Mealyho a Moorův automat?

Konečný automat může pracovat ve dvou módech: jako akceptor (= rozpoznávač — jen říká ANO/NE, patří slovo do jazyka?) nebo jako převodník (= transformátor — generuje výstupní řetězec, transformuje vstup na výstup). Existují dva typy převodníků lišící se tím, na čem závisí výstup: Mealyho automat generuje výstup na základě aktuálního stavu a vstupního symbolu zároveň, zatímco Mooreův automat generuje výstup pouze na základě aktuálního stavu (nezáleží na tom, co přišlo na vstupu). Oba typy jsou navzájem převoditelné.

📖 Slovníček symbolů převodníku

🔤 Σ (sigma velké) — vstupní abeceda (symboly, které automat ČTE)

🖨️ Γ (gama velké) — výstupní abeceda (symboly, které automat PRODUKUJE na výstup)

🔁 δ (delta) — přechodová funkce (jaký stav → jaký nový stav)

📤 λ (lambda) — výstupní funkce (co se vypíše — liší se u Mealy vs Moore)

Převodník = šestice (S, Σ, Γ, δ, λ, s) = oproti akceptoru (pětice) má navíc výstupní abecedu Γ a výstupní funkci λ

🎯 Akceptor — rozpoznávač jazyka

📥 Čte vstupní řetězec symbol po symbolu

🔁 Mění stav dle přechodové funkce δ (delta)

✅ Přijme → skončí v přijímacím stavu (q ∈ F, čti: q patří do F)

❌ Odmítne → skončí mimo F nebo uvízne

📤 Výstup: pouze ANO / NE

Použití: validace vstupů, lexikální analýza, rozpoznávání vzorů

🔄 Převodník — transformátor

Formálně šestice (S, Σ, Γ, δ, λ, s):

🔤 Σ (sigma) — vstupní abeceda (co čte)

🖨️ Γ (gama) — výstupní abeceda (co produkuje)

🔁 δ (delta) — přechodová funkce stavů

📤 λ (lambda) — výstupní funkce (liší se u Mealy vs Moore)

📤 Výstup: výstupní řetězec (konkrétní symboly z Γ)

⚡

Mealyho automat

Výstup závisí na stavu i vstupu

Výstupní funkce: λ(stav, vstup)

Výstupy přiřazeny přechodům (šipkám)

Obvykle méně stavů než Moore

⚡ Rychlá reakce na změnu vstupu

🔒

Mooreův automat

Výstup závisí pouze na stavu

Výstupní funkce: λ(stav)

Výstupy přiřazeny stavům (uzlům)

Obvykle více stavů než Mealy

🔒 Stabilnější výstupy, nezávisí na vstupu

📊 Mealy vs Moore — srovnání

Kritérium	Mealyho automat	Mooreův automat
Výstupní funkce λ	λ(stav, vstup) — na přechodech (šipkách)	λ(stav) — na stavech (uzlech)
Počet stavů	Obvykle méně	Obvykle více
Stabilita výstupu	Mění se s každým vstupem	Stabilní v daném stavu
Reakce na vstup	Okamžitá (v přechodu)	Až po přechodu do nového stavu
Vzájemná převoditelnost	✅ Oba typy jsou navzájem ekvivalentní (stejně silné)

💡 Příklad z praxe

Mealyho automat: Převodník kódování znaků (ASCII na Unicode) — výstup závisí na kombinaci aktuálního stavu (multibyte sekvence) a čteného bajtu. Mooreův automat: Semafor — každá fáze (stav) má pevně daný výstup (barva světla), bez ohledu na to, jak jsem do té fáze přišel.

⚠️ Časté záludnosti

❌ Mealy ≠ slabší než Moore — oba mají stejnou vyjadřovací sílu, lze je vzájemně převést.

❌ U Mealyho automatu výstup závisí na stavu i vstupu — nikoli jen na stavu. λ(stav, vstup), ne λ(stav).

❌ Akceptor nevytváří výstupní řetězec — jen rozhoduje příslušnost slova k jazyku (ANO/NE).

❌ Šestice převodníku má navíc výstupní abecedu Γ (gama) a výstupní funkci λ (lambda) oproti pětici akceptoru.

🧩 Laicky — semafor vs kalkulačka

Mooreův automat = semafor. Semafor svítí určitou barvou čistě podle toho, v jakém je stavu (fázi). Nezáleží na tom, jak se do toho stavu dostal — červená je vždy červená. Výstup závisí jen na stavu. Mealyho automat = kalkulačka. Stiskneš „5" a pak „+" — výstup závisí jak na tom, co jsi předtím zadal (stav), TAK na tom, co stiskneš (vstup). Bez znalosti obou věcí nevíš výsledek. Obě varianty jsou stejně silné — jen se jinak zapisují.

🎓 Napojení na DP

II · 4

Turingův stroj a jeho výpočet, Turingův stroj jako akceptor, rekurzivní a rekurzivně spočetné jazyky.

📋 Co je Turingův stroj?

Turingův stroj (TS) je teoretický model nejsilnějšího možného počítače — popsaný Alanem Turingem v roce 1936. Na rozdíl od konečného automatu má neomezenou páskovou paměť, do které může libovolně číst i zapisovat a pohybovat se oběma směry. Díky tomu dokáže provést libovolný algoritmicky popsatelný výpočet — to je základ Churchovy-Turingovy teze (= hypotéza, že vše algoritmicky vypočitatelné jde vypočítat Turingovým strojem). Používá se hlavně jako teoretický nástroj k prokázání, co lze a nelze algoritmicky vyřešit. Rekurzivní jazyk = TS vždy skončí (ANO nebo NE). Rekurzivně spočetný jazyk = TS přijme platná slova, ale pro neplatná může cyklit donekonečna.

⚙️ Složení Turingova stroje

🧠 Procesorová jednotka — konečný automat (stavy + přechodová pravidla)

📼 Páska — pravostranně nekonečná; jde číst I zapisovat (na rozdíl od KA!)

👆 Čtecí/zapisovací hlava — pohybuje se o 1 políčko doleva (L) nebo doprava (R)

📋 Přechodová pravidla — (stav, symbol) → (nový stav, co zapsat, L nebo R)

🔄 Princip výpočtu — krok za krokem

1️⃣ Vstupní slovo je zapsáno na pásku; hlava na prvním symbolu

2️⃣ Hlava přečte symbol pod sebou

3️⃣ Dle přechodové funkce: změn stav + zapiš symbol + posuň hlavu L nebo R

4️⃣ Pokud je stav přijímací → výpočet úspěšný (ANO)

5️⃣ Pokud pro aktuální (stav, symbol) neexistuje pravidlo → výpočet selže (NE nebo zacyklení)

✅ Rekurzivní jazyky

📌 Rozhodnutelné — TS vždy zastaví a odpoví

✅ Pro platné slovo: zastaví a přijme

❌ Pro neplatné slovo: zastaví a odmítne

🔄 Uzavřené pod doplňkem (= negací): pokud jazyk L je rekurzivní, pak i „vše co není v L" je rekurzivní

Příklad: syntaxe programovacích jazyků

⚠️ Rekurzivně spočetné jazyky

📌 Částečně rozhodnutelné — TS nemusí vždy zastavit

✅ Pro platné slovo: zastaví a přijme

🔄 Pro neplatné slovo: může cyklit donekonečna (nebo odmítne — nevíme předem)

❗ Nejsou uzavřené pod doplňkem — nemůžeš zaručit NE

Příklad: problém zastavení TS — lze přijmout „zastaví", nelze vždy odmítnout „nezastaví"

⚖️ Churchova-Turingova teze

Teze (= hypostéza, neprokázaná věta, ale obecně přijímaná) říká: vše, co lze algoritmicky vypočítat, lze vypočítat Turingovým strojem. TS je ekvivalentní Lambda kalkulu, RAM modelu i reálnému počítači (z pohledu co jde vypočítat — ne jak rychle). Není to formálně dokazatelná věta — ale nikdo nikdy nenašel protipříklad.

📊 Rekurzivní vs Rekurzivně spočetné jazyky

Typ jazyka	TS zastaví pro platná slova?	TS zastaví pro neplatná slova?	Uzavřenost pod doplňkem
Rekurzivní	✅ Ano	✅ Ano (odmítne)	✅ Ano
Rekurzivně spočetný	✅ Ano	❌ Může cyklit	❌ Ne

💡 Analogie soudce

Rekurzivní jazyk = soudce, který vždy vynese rozsudek (guilty / not guilty) — pro každého obviněného. Rekurzivně spočetný jazyk = soudce, který vždy odsoudí viné, ale u nevinných se může soudit donekonečna. Problém zastavení TS = rekurzivně spočetný (ale ne rekurzivní).

⚠️ Časté záludnosti

❌ Rekurzivně spočetný ≠ rekurzivní — TS pro neplatná slova u rekurzivně spočetného jazyka nemusí zastavit; u rekurzivního vždy zastaví.

❌ Turingův stroj není reálný počítač — je to teoretický model; reálné počítače mají omezenou paměť (TS má nekonečnou pásku).

❌ Rekurzivní jazyky jsou uzavřeny pod doplňkem — rekurzivně spočetné ne.

❌ TS může přepisovat pásku; KA nemůže nic ukládat — zásadní rozdíl.

🧩 Laicky — nekonečná páska a paradox

Turingův stroj = ideální počítač s nekonečnou páskou. Představ si obrovský nekonečný papírový pásek, na kterém jsou napsána vstupní data. Stroj čte jedno políčko, může ho přepsat, pak se posune doprava nebo doleva. To je vše — a přesto dokáže spočítat cokoliv, co jde vůbec spočítat. Problém zastavení je jako tato otázka: „Zastaví se tento program pro tento vstup?" Alan Turing dokázal, že ŽÁDNÝ program tuto otázku obecně nedokáže zodpovědět — protože pokud by existoval, vedl by sám k sobě ke sporu (podobně jako věta „tato věta je lež").

🎓 Napojení na DP

II · 5

Výpočetní složitost algoritmů, lineární, polynomiální a exponenciální složitost.

📋 Co je výpočetní složitost algoritmů?

Výpočetní složitost říká, jak moc roste spotřeba zdrojů (nejčastěji čas, někdy paměť) algoritmu při zvyšování velikosti vstupu n. Vyjadřuje se pomocí O-notace (vyslov: „velké O"), která popisuje asymptotické chování (= jak se algoritmus chová pro velká n, přičemž ignorujeme konstanty a menší členy). O(n) = lineární = roste přímo úměrně. O(n²) = kvadratická = roste jako druhá mocnina. O(2ⁿ) = exponenciální = roste závratně rychle.

📐 O-notace přesněji: f(n) = O(g(n)) čteme jako „f roste nejvýše tak rychle jako g". Jinými slovy — g(n) je horní mez růstu f(n). Ignorujeme konstanty (proto O(3n) = O(n)).

📈 O(n) — Lineární

Nároky rostou přímo úměrně n

🔁 Typicky: jeden průchod celými daty

Příklady:

🔍 Hledání maxima v poli

📊 Součet všech prvků

🔎 Lineární vyhledávání (od začátku do konce)

for i in range(n): sum += a[i]

📊 O(nᵏ) — Polynomiální

Nároky rostou jako polynom stupně k (= k-tá mocnina n)

🔁 Typicky: vnořené smyčky (smyčka v smyčce)

Příklady:

🔀 O(n²): bubble sort, selection sort

🔀 O(n³): násobení matic (naivní)

🚀 O(n log n): quicksort, mergesort (sub-kvadratická)

Poznámka: O(n log n) je rychlejší než O(n²)

💥 O(2ⁿ) — Exponenciální

Nároky explodují s n — každý přidaný prvek zdvojnásobí čas

🔁 Typicky: brute-force = zkus všechny kombinace

Příklady:

🏙️ Problém obchodního cestujícího (TSP)

🧩 Problém batohu (brute-force)

📜 Výčet všech podmnožin množiny

Pro n=50: více než 10¹⁵ operací

📊 Srovnání složitostí

Třída	Notace	n = 10	n = 100	n = 1 000	Praktická použitelnost
Konstantní	O(1)	1	1	1	✅ Vždy
Logaritmická	O(log n)	3	7	10	✅ Vždy
Lineární	O(n)	10	100	1 000	✅ Vždy
Linearitmická (= n krát log n)	O(n log n)	33	664	9 966	✅ Velká data
Kvadratická	O(n²)	100	10 000	1 000 000	⚠️ Střední data
Exponenciální	O(2ⁿ)	1 024	10³⁰	10³⁰¹	❌ Jen malé n

📏 Best / Average / Worst case — nejlepší / průměrný / nejhorší případ

Best case (nejlepší případ) — nejpříznivější vstup (quicksort na již seřazeném poli → O(n log n)). Average case (průměrný případ) — typický vstup. Worst case (nejhorší případ) — nejnepříznivější vstup (quicksort na obrácené řadě → O(n²)). O-notace bez upřesnění obvykle znamená worst case.

💡 Praktická ukázka dopadu

Procesor provede ~10⁹ operací za sekundu. Pro n = 10 000 prvků: O(n log n) = ~130 000 op. = 0,0001 s. O(n²) = 100 000 000 op. = 0,1 s. O(2ⁿ) pro n=50 = 10¹⁵ op. = ~11 dní. Proto se NP-úplné problémy řeší aproximacemi (přibližným řešením).

⚠️ Časté záludnosti

❌ O-notace vyjadřuje asymptotické chování — pro malé n může být „pomalejší" algoritmus fakticky rychlejší (O(n²) s malou konstantou vs O(n log n) s velkou).

❌ O(n log n) je sub-kvadratická (= rychlejší než n²), ne kvadratická.

❌ Složitost časová ≠ složitost paměťová — jsou to dva různé parametry.

❌ „Polynomiální složitost = efektivní" — jen relativně; O(n¹⁰⁰) je sice polynomiální, ale v praxi nepoužitelná.

🧩 Laicky — co to znamená v sekundách

Procesor zvládne zhruba 10⁹ (= miliarda) operací za sekundu. Máš-li 1 000 prvků (n=1000): O(log n) = 10 operací = okamžik. O(n) = 1 000 operací = okamžik. O(n²) = 1 000 000 operací = 0,001 sekundy. O(2ⁿ) = 10³⁰⁰ operací = déle než věk vesmíru. Proto se NP-těžké problémy (jako hledání nejlepší trasy pro obchodního cestujícího) řeší jen přibližně — přesné řešení by trvalo věčně.

🎓 Napojení na DP

II · 6

Řešitelné a neřešitelné problémy, problém zastavení Turingova stroje, problémy P-těžké, NP-těžké a NP-úplné.

📋 Co jsou třídy P, NP a problém zastavení?

Ne každý problém lze algoritmicky vyřešit — existují problémy, pro které žádný algoritmus neexistuje a nikdy neexistovat bude. Nejslavnějším příkladem je Problém zastavení (Halting Problem): nelze napsat program, který by pro libovolný jiný program a vstup spolehlivě rozhodl, zda program někdy skončí, nebo poběží věčně. Třídění složitostí P a NP pak rozděluje řešitelné problémy na ty, které jdou vyřešit rychle (P = polynomiální čas), a ty, kde řešení ověříme rychle, ale najít ho neumíme efektivně (NP = nedeterministicky polynomiální). Zda P = NP je největší otevřený problém informatiky — za jeho vyřešení je 1 milion dolarů.

📐 Slovníček: Polynomiální čas = čas růstu O(nᵏ) = „rozumně rychlý algoritmus". Nedeterministicky polynomiální = problém, kde ověření daného řešení jde provést v polynomiálním čase (i když nalezení řešení je pomalé). Redukce = převod jednoho problému na jiný (pokud umím řešit B, a dokážu A přeformulovat jako B, umím řešit i A).

🔑 Řešitelné vs neřešitelné

✅ Řešitelné (rozhodnutelné): existuje algoritmus, který vždy odpoví v konečném počtu kroků

❌ Neřešitelné (nerozhodnutelné): žádný takový algoritmus neexistuje — ani sebevýkonnější počítač to nevyřeší

⏳ Částečně rozhodnutelné: algoritmus odpoví ANO pro správné vstupy, ale pro špatné může cyklit (= běžet donekonečna)

🛑 Problém zastavení (Halting Problem)

❓ Otázka: „Zastaví program P pro vstup x?"

📜 Alan Turing 1936 dokázal: tato otázka je nerozhodnutelná

🔄 Důkaz diagonalizací (= sebereferenční argument): předpokládáme, že existuje HALT(P, x), konstruujeme program, který vede ke sporu — „tento program zastaví, právě když nezastaví"

🔧 V praxi: heuristiky, statická analýza, omezení na podmnožinu programů

🟢 Třída P — Polynomiální

Problémy řešitelné deterministickým algoritmem v polynomiálním čase

= „rozumně rychlá" řešení — O(nᵏ) pro nějaké k

Příklady:

🔀 Třídění (O(n log n))

🔍 Binární vyhledávání (O(log n))

🔗 Nejkratší cesta v grafu (Dijkstrův algoritmus)

🟡 Třída NP — Nedeterministicky Polynomiální

Problémy, kde lze dané řešení ověřit v polynomiálním čase

Nalezení řešení může být exponenciálně náročné

Příklady NP-úplných:

🏙️ Problém obchodního cestujícího (TSP) — nejkratší trasa přes všechna města

🎒 Problém batohu (Knapsack) — co dát do batohu s max. hodnotou?

🧩 SAT (splnitelnost booleovské formule) — první NP-úplný problém (Cook 1971)

Problém

Existuje algoritmus řešící v konečném čase?

ANO — řešitelný

Polynomiální čas?

ANO

P
deterministicky polyn.

NE (ověřitelný polyn.?)

NP / NP-úplné
ověřit ano, najít ne

NE — neřešitelný

Nerozhodnutelný
Halting problem atd.

🔴 NP-těžké vs NP-úplné

NP-těžké (NP-hard): každý NP problém lze redukovat (= přeformulovat) na tento problém v polynomiálním čase. Nemusí sám patřit do NP. NP-úplné (NP-complete): NP-těžký A zároveň patří do NP (řešení lze ověřit v polynomu). NP-úplné = průnik NP-těžkých a NP.

💡 NP v praxi — kryptografie

Kryptografie (RSA) stojí na předpokladu P ≠ NP: rozložit velké číslo na prvočinitele je (pravděpodobně) NP těžký problém — snadno ověřitelný, těžce nalezitelný. Pokud by někdo dokázal P = NP, veškerá moderní kryptografie by padla přes noc.

⚠️ Časté záludnosti

❌ NP neznamená „nevypočitatelný" — NP = „nedeterministicky polynomiální" = lze ověřit rychle, ale nenajít rychle.

❌ Problém zastavení je nerozhodnutelný (mimo řešitelné problémy úplně), ne jen NP-těžký — jsou to zcela různé kategorie.

❌ P ⊆ NP vždy platí (každý P problém lze i ověřit v polyn. čase); zda P = NP je stále otevřená otázka.

❌ NP-úplný = NP-těžký AND v NP — ne každý NP-těžký problém je NP-úplný.

🧩 Laicky — sudoku a P vs NP

P = umím rychle NAJÍT řešení (jako sčítání čísel). NP = umím rychle OVĚŘIT řešení, ale nenacházím ho rychle (jako sudoku: ověřit hotové sudoku je triviální — najít řešení prázdného sudoku je těžké). NP-úplné = těžší než jakýkoli jiný NP problém (nejhorší z NP). P = NP? = Otázka: je rychlé ověření vždy ekvivalentní rychlému nalezení? Téměř všichni věří, že NE — ale nikdo to nedokázal.

🎓 Napojení na DP

II · 7

Relační, post-relační a grafové databáze, princip činnosti, dotazovací jazyky.

📋 Co jsou relační, NoSQL a grafové databáze?

Databáze jsou základ každého IS — ukládají a zpřístupňují data. Relační databáze (navrhl Edgar F. Codd) organizují data do tabulek propojených klíči a používají standardizovaný jazyk SQL. Post-relační / NoSQL databáze vznikly pro potřeby velkých dat a cloudových aplikací — nabízejí flexibilnější schéma za cenu oslabení konzistenčních garancí. Grafové databáze jsou specializované na vysoce propojená data, kde jsou samotné vztahy tím nejdůležitějším.

📐 Slovníček: ACID = čtyři záruky relační transakce: Atomicita (celá transakce nebo nic), Konzistence (DB zůstane v platném stavu), Izolovanost (transakce se navzájem neovlivní), Trvanlivost (po commitu data přežijí pád). BASE = alternativa k ACID v NoSQL: Basically Available (vždy dostupné), Soft state (stav se může měnit), Eventually consistent (konzistence nastane postupně, ne okamžitě). Traversal = procházení grafu (přecházení po hranách/vztazích).

📋 Relační databáze

🏗️ Model: tabulky (relace) = řádky × sloupce

🔗 Propojení: primární klíč (PK = jedinečný identifikátor řádku) a cizí klíče (FK = odkaz na PK jiné tabulky)

⚛️ ACID záruky transakcí

🔍 Dotaz: SQL (SELECT, JOIN, INSERT, UPDATE, DELETE)

📦 Příklady: MySQL, PostgreSQL, Oracle, MS SQL Server

✅ Vhodné pro: transakční systémy, strukturovaná data, OLTP

🗃️ Post-relační (NoSQL)

🏗️ Modely: dokumentové (JSON/BSON), klíč-hodnota (jako slovník), sloupcové, vícemodelové

📈 Škálovatelnost: horizontální = přidáš server místo výkonnějšího serveru

🔄 Schéma: flexibilní — každý dokument může mít jiná pole

⚡ Konzistence: BASE místo ACID (Eventually Consistent = konzistentní po čase)

📦 Příklady: MongoDB (dokumenty), Redis (klíč-hodnota), Cassandra (sloupcová)

✅ Vhodné pro: Big data, IoT, logy, nestrukturovaná data

🕸️ Grafové databáze

🏗️ Model: uzly (entity = objekty) + hrany (vztahy) + vlastnosti

⚡ Traversal (= procházení): vztahy procházeny přímo, bez JOIN

🔍 Dotaz: Cypher (Neo4j), Gremlin, SPARQL (pro sémantický web)

📦 Příklady: Neo4j, Amazon Neptune, OrientDB

✅ Vhodné pro: sociální sítě, doporučovací systémy, detekce podvodů

🔑 Klíčové rozdíly

Kritérium	Relační (SQL)	Post-relační (NoSQL)	Grafové
Datový model	Tabulky, řádky, sloupce	Dokumenty / K-V / sloupce	Uzly + hrany + vlastnosti
Schéma	Pevné (musí být definováno předem)	Flexibilní (bez pevného schématu)	Flexibilní
Vztahy mezi daty	JOIN operace (mohou být pomalé pro hluboké vztahy)	Embeddované nebo denormalizované	Přímé hrany — velmi rychlé
Konzistence	ACID (silná, okamžitá)	BASE (eventual = postupná)	Závisí na produktu
Škálovatelnost	Vertikální (výkonnější server)	Horizontální (více serverů)	Horizontální
Dotazovací jazyk	Standardizovaný SQL	Vlastní API	Cypher, Gremlin, SPARQL

💡 Příklad z praxe

Twitter/X používá PostgreSQL (relační) pro metadata tweetů a uživatelů — ACID transakce zajišťují konzistenci. LinkedIn přešel na grafovou DB pro analýzu profesních sítí — dotaz „kdo jsou spojení 2. stupně?" v SQL = desítky JOINů, v grafové DB = traversal za milisekundy. Airbnb využívá MongoDB (dokumentová NoSQL) — každý výpis nemovitosti má jiné atributy, flexibilní schéma je klíčové. Redis (klíč-hodnota NoSQL) jako cache pro session management na většině velkých webů.

⚠️ Časté záludnosti

❌ NoSQL neznamená „žádné SQL" — některé NoSQL systémy SQL podporují. NoSQL = „Not only SQL".

❌ Grafové DB nejsou podmnožinou NoSQL — jsou to samostatná kategorie.

❌ ACID Atomicita = celá transakce nebo nic (ne „přesnost/accuracy").

❌ BASE (Eventually Consistent) ≠ nekonzistentní navždy — konzistentnost nastane postupně, ne okamžitě.

🧩 Laicky — kartotéka, JSON soubory a mapa přátel

Relační DB = excelová tabulka s pravidly: každý řádek je záznam, sloupce jsou vždy stejné, propojuješ tabulky přes ID (jako vlookup). Perfektní pro bankovní transakce — musíš mít 100% konzistenci. NoSQL = JSON soubory na disku: každý dokument může vypadat jinak, přidáš pole kdy chceš, škáluješ na tisíce serverů. Perfektní pro produktový katalog e-shopu, kde každý produkt má jiné atributy. Grafová DB = mapa přátel: uzly jsou lidé, hrany jsou vztahy. Otázka „kdo jsou přátelé přátel přátel Alice?" je v SQL hůl — v grafové DB jde v millisekendách (Facebook používá grafovou DB).

🎓 Napojení na DP

II · 8

Pokročilé metody návrhu relačních a grafových databází, datová normalizace.

📋 Co je normalizace a pokročilý návrh databáze?

Dobře navržená databáze šetří místo, zabraňuje nekonzistencím a zrychluje dotazy. Návrh probíhá ve třech fázích: konceptuální (co ukládáme — ER diagram), logický (jak to strukturujeme — tabulky, klíče) a fyzický (jak to optimalizujeme — indexy). Normalizace je systematické odstraňování nadbytečných dat pomocí normálních forem (1NF, 2NF, 3NF, BCNF). Denormalizace je záměrné porušení normálních forem pro výkonnostní účely — typicky v datových skladech.

📐 Slovníček: Normalizace = odstranění redundance (= nadbytečnosti, duplicit) a anomálií. Redundance = stejná informace uložená na více místech. Tranzitivní závislost = atribut závisí na jiném neklíčovém atributu místo na klíči (A→B→C: C závisí na B, ne přímo na A). Kardinalita = počet různých hodnot (málo hodnot = nízká kardinalita). Partitioning = dělení velké tabulky na menší části. Surrogátní klíč = uměle vytvořené ID (1, 2, 3…), ne přirozený identifikátor.

🖊️ Konceptuální návrh

🗺️ ER diagram (Entity-Relationship = entita-vztah)

👤 Entity = objekty reálného světa (STUDENT, PŘEDMĚT)

🔗 Vztahy = vazby mezi entitami (ZAPISUJE_SE)

📋 Atributy = vlastnosti entit (jméno, datum)

⚙️ Nezávislý na konkrétní DB technologii

📐 Logický návrh

🔄 Převod ER diagramu na konkrétní tabulky

📋 Entity → tabulky, vztahy → cizí klíče (FK)

🔑 Určení primárních klíčů (PK)

🎯 Cíl: správná struktura bez redundance (= bez duplicit)

📊 Výstup: relační schéma

⚙️ Fyzický návrh

📦 Tvorba indexů pro rychlejší dotazy

🔀 Partitioning (= dělení velkých tabulek na menší části)

🔁 Replikace dat (= kopie na více serverech pro zálohu)

🚀 Optimalizace výkonu (query planner = plánovač dotazů)

🔑 Normalizace — normální formy

Normální forma	Podmínka	Co odstraňuje	Příklad problému
1NF	Atomické (= nedělitelné) hodnoty, žádné opakující se skupiny	Vícehodnotové atributy	Sloupec „telefony" = „123, 456, 789" — měl by být 3 řádky
2NF	1NF + každý neklíčový atribut závisí na celém PK	Částečné závislosti (jen u složeného PK)	PK=(OrderID, ProductID), NázevProduktu závisí jen na ProductID — závislost na části PK
3NF	2NF + žádné tranzitivní závislosti neklíčových atributů	Závislosti přes jiný neklíčový atribut	ZákazníkID→Město→PSČ — PSČ závisí na Město (ne na PK), to je tranzitivní závislost
BCNF	Každý determinant (= to, na čem ostatní závisí) je kandidátní klíč	Anomálie u překrývajících se kandidátních klíčů	Přísnější než 3NF, ne vždy dosažitelná bez ztráty

📈 Indexy — typy a použití

🌳 B-tree (strom) — výchozí typ; rozsahové dotazy, ORDER BY, LIKE 'abc%'

#️⃣ Hash — rychlé přesné shody (=); nevhodný pro rozsahy

🗺️ Bitmap (bitová mapa) — sloupce s nízkou kardinalitou (= málo různých hodnot: pohlaví, stav); datové sklady

🔤 Fulltext — hledání v textu; náhrada za LIKE '%slovo%'

⚠️ Index zrychluje SELECT, ale zpomaluje INSERT/UPDATE/DELETE (musí se aktualizovat)

🔄 Denormalizace

🎯 Záměrné porušení normálních forem pro rychlost čtení

📉 Méně JOIN operací → rychlejší analytické dotazy

📦 Typické použití: datové sklady, OLAP, materialized views (= předpočítané pohledy)

⚠️ Cena: větší objem dat, riziko nekonzistence

Tabulky dimenzí v hvězdicovém schématu jsou záměrně denormalizované

💡 Příklad 3NF porušení a opravy

Špatně (porušení 3NF): Objednávka(ID, ZákazníkID, MěstoZákazníka, PSČ) — PSČ závisí na Městě, ne na ID objednávky. Správně: Objednávka(ID, ZákazníkID) + Zákazník(ZákazníkID, Město, PSČ). Extrahuj vše, co závisí na neklíčovém atributu, do vlastní tabulky.

⚠️ Časté záludnosti

❌ 2NF je relevantní pouze u složeného PK — u jednoduchého PK je 2NF splněna automaticky (pokud je v 1NF).

❌ BCNF je přísnější než 3NF, ale ne každou tabulku lze normalizovat do BCNF bez ztráty závislostí.

❌ Index zrychluje SELECT, ale každý index zpomaluje zápisy.

❌ Denormalizace ≠ špatný návrh — v analytických systémech je záměrná a správná volba pro výkon čtení.

❌ Tranzitivní závislost A→B→C: C závisí na B (ne přímo na PK A) — řeší se extrakcí B, C do separátní tabulky.

🧩 Laicky — telefonní seznam jako příklad normalizace

Špatná tabulka: Objednávka(ID, JménoZákazníka, MěstoZákazníka, PSČMěsta, Produkt, Cena). Problémy: pokud se zákazník přestěhuje, musíš změnit stovky řádků. PSČ závisí na Městě, ne na Objednávce — to je tranzitivní závislost. Správně: rozděl na Zákazník(ID, Jméno, MěstoID), Město(ID, Název, PSČ), Objednávka(ID, ZákazníkID, ProduktID), Produkt(ID, Název, Cena). Teď stačí změnit PSČ na jednom místě. To je normalizace — každá informace žije jen na jednom místě.

🎓 Napojení na DP

II · 9

Manažerské informační systémy, systémy pro podporu rozhodování, koncept analytických systémů a jeho základní vrstvy, agregace a sumarizace.

📋 Co jsou MIS, DSS a analytické systémy?

Informační systémy se liší podle toho, komu slouží a na jaké úrovni řízení pracují. TPS (Transaction Processing System = transakční IS) jsou pro operativní pracovníky — evidují, co se právě děje. MIS (Management Information System = manažerský IS) jsou pro střední management — agregují data z TPS a tvoří pravidelné reporty. EIS (Executive Information System = executive IS) jsou pro vrcholové vedení — strategické přehledy a dlouhodobé trendy. DSS (Decision Support System = systém pro podporu rozhodování) pomáhají porovnat varianty a předvídat důsledky — ale rozhodnutí vždy zůstává na člověku.

📐 Slovníček: Agregace = výpočet jedné hodnoty ze všech řádků (COUNT, SUM, AVG bez GROUP BY — vrací 1 číslo). Sumarizace = GROUP BY — vrací tabulku hodnot (každá skupina má svůj výsledek). Inference = odvozování závěrů ze znalostní báze (IF-THEN pravidla). EDI = Electronic Data Interchange = elektronická výměna dat. OIS = Office Information System = kancelářský IS.

⚡ TPS — Transakční IS

🎯 Úroveň: operativní (provozní) řízení

⏱️ Horizont: krátkodobý (hodiny, dny)

🔄 Funkce: evidence transakcí a výrobních operací v reálném čase

📊 Výstupy: faktury, pokladní doklady, objednávky

Příklady: ERP provozní modul, pokladní systém, bankovní transakce

📈 MIS — Manažerský IS

🎯 Úroveň: taktické řízení (střední management)

⏱️ Horizont: střednědobý (týdny, měsíce)

🔄 Funkce: pravidelné plánované reporty z TPS dat

📊 Výstupy: prodejní reporty, analýzy zásob, hodnocení

Zahrnuje: EDI (el. výměna dat), OIS (kancelářské IS)

🏆 EIS — Executive IS

🎯 Úroveň: strategické řízení (vrcholové vedení, CEO)

⏱️ Horizont: dlouhodobý (roky)

🔄 Funkce: přehledy, situace na trhu, plánování hospodaření

📊 Zdroj: data z TPS i MIS (vysoká agregace = hodně zprůměrováno)

Dashboardy CEO, KPI monitorování celé organizace

🔍 DSS — Systémy pro podporu rozhodování

🤝 Poskytuje varianty k rozhodnutí — nenahrazuje rozhodovatele

💻 Tři části:

🖥️ UI — uživatelské rozhraní

🧠 Znalostní báze — modely a pravidla

💾 Databáze — data pro analýzu

🤖 Hledá skryté vztahy, predikuje trendy

Strojové učení v DSS: s učitelem (labeled data) / bez učitele (clustering) / posilující (reward)

∑ Agregace vs Sumarizace

📌 Agregace = jedna hodnota ze všech řádků

SELECT COUNT(*) FROM grades
WHERE date='2024-01-30'
-- Výsledek: 1 číslo, např. 42

📌 Sumarizace = tabulka hodnot dle seskupení (GROUP BY)

SELECT name, AVG(grade) FROM grades
GROUP BY name
-- Výsledek: tabulka (jméno, průměr)

🏗️ Tři vrstvy analytického systému

Slouží pro podporu analytického zpracování dat, odhalování skrytých informací (pochopení a předvídání potřeb uživatelů)

1️⃣ Vrstva transformace dat — ETL nástroje (extrakce z TPS, čištění, transformace)
2️⃣ Vrstva ukládání dat — datové sklady, datová tržiště, operativní databáze
3️⃣ Vrstva analytického zpracování — OLAP, reporting, data mining (= dolování dat = hledání vzorů), BI

💡 Příklad z praxe

E-shop Alza.cz: TPS = každá objednávka (transakce v ERP). MIS = týdenní report pro kategoriového manažera — kolik se prodalo GPU, jaké jsou zásoby. EIS = roční dashboard tržeb pro ředitele — trendy, srovnání poboček. DSS = nástroj pro rozhodnutí „otevřeme nové výdejní místo v Olomouci?" — systém porovná demografiku, zákaznický dosah, logistické náklady a presentuje varianty. Rozhodnutí zůstává na manažerovi.

⚠️ Časté záludnosti

❌ MIS ≠ celé „IS pro management" — MIS je konkrétní typ na taktické úrovni; EIS je pro strategické vrcholové vedení.

❌ DSS nenahrazuje rozhodovatele — nabízí varianty, důsledky, rizika; rozhodnutí dělá vždy člověk.

❌ Agregace vrací jedinou hodnotu (bez GROUP BY); sumarizace vrací tabulku (se GROUP BY).

❌ Strojové učení s učitelem (= trénovací data jsou ohodnocená) ≠ bez učitele (= data bez cílových hodnot, jen clustering).

🧩 Laicky — pyramida řízení

Představ si firmu jako pyramidu: nahoře CEO, uprostřed manažeři, dole zaměstnanci. TPS = pokladna v supermarketu — eviduje každou transakci v reálném čase. MIS = týdenní report pro vedoucího prodejny — kolik jsme prodali, co se rychle prodává. EIS = dashboard pro ředitele řetězce — jaké jsou trendy za rok, kde otevřít novou pobočku. DSS = nástroj pro rozhodnutí „otevřít novou pobočku v Brně vs Ostravě?" — porovná data, ale nerozhodne za tebe.

🎓 Napojení na DP

II · 10

Principy Business Intelligence, tradiční architektura versus aktuální hlavní komponenty a jejich vazby, vrstva zdrojových dat, vrstva příjmu dat, vrstva analytických dat, analytická vrstva a prezentační vrstva.

📋 Co je Business Intelligence a jeho architektura?

Business Intelligence (BI) je sada procesů, aplikací a technologií pro podporu rozhodovacích procesů v organizaci (H.J. Dresner, Gartner 1989). Nejde o to dělat rozhodnutí, ale o to podpořit rozhodování relevantními informacemi. Tradiční architektura: OLTP systémy → ETL → Datový sklad → OLAP → Reporty. Moderní BI má 5 vrstev: od zdrojů dat přes příjem a uložení až po analytické zpracování a vizualizaci.

📐 Slovníček: OLTP (Online Transaction Processing) = systémy pro zápis aktuálních dat (bankovní transakce, objednávky). OLAP (Online Analytical Processing) = analytické zpracování historických dat, dotazy přes kostku. Data Lake = jezero dat = úložiště surových dat bez schématu (nahraje se vše, filtruje se až při čtení). Schema-on-read = schéma (= struktura dat) se definuje až při čtení. Schema-on-write = schéma se definuje při zápisu. 3V = Volume (objem), Variety (rozmanitost), Velocity (rychlost generování) — charakteristiky Big Data.

🏛️ Tradiční architektura BI

📥 Strukturovaná data (OLTP, ERP, CRM)

↓ ETL (Extract = vytáhni, Transform = uprav, Load = nahraj)

🏦 Datový sklad (Data Warehouse = centrální úložiště čistých historických dat)

↓ OLAP (multidimenzionální analytické dotazy)

📊 Reportovací nástroje (dashboardy, reporty)

🎯 Podstata a cíl BI

📌 „Sada konceptů a metod pro zkvalitnění rozhodnutí firmy" (Dresner, 1989)

🎯 Posláním BI není tvorba reportů — je to podpora procesu rozhodování

📊 Nejčastější výstupy: kontingenční tabulky (= cross-tab = pivotní), grafy, dashboardy, score cards

💡 Rozhodnutí vychází z analytického zpracování velkého množství historických dat

🏗️ Moderní architektura BI

#	Vrstva	Obsah	Technologie / příklady
1	Zdrojových dat	Vstupní data v různých formách	Strukturovaná (relační DB, OLTP, ERP), Semi-strukturovaná (XML, JSON, CSV), Nestrukturovaná (dokumenty, emaily), Streamovaná (IoT, akcie, senzory)
2	Příjmu dat	Sběr a ukládání surových dat	Data Lake (Apache Hadoop, AWS S3); 3V: Volume, Variety, Velocity; data v původní struktuře — schéma-on-read (struktura až při čtení)
3	Analytických dat	Transformovaná data pro dotazy	Datové sklady (DW), Datová tržiště (DM), Operativní úložiště (ODS), Staging Areas (dočasné meziuložiště)
4	Analytická	Zpracování analytickými metodami	BPM (KPIs), OLAP (multidim. dotazy), Reporting, Data mining (= dolování vzorů)
5	Prezentační	Výstupy pro uživatele	Power BI, Tableau, dashboardy, reporty, score cards

💧 Data Lake vs Datový sklad

💧 Data Lake: surová data bez struktury; schema-on-read (strukturuješ při čtení); vše se uloží, filtruje se později

🏦 Datový sklad: transformovaná, schematizovaná data; schema-on-write (strukturuješ při zápisu); optimalizované pro analytické dotazy

Příklad Data Lake: Apache Hadoop, AWS S3 + Athena

📦 3V — charakteristika velkých dat

📦 Volume (Objem) — terabajty a petabajty dat denně

🌈 Variety (Rozmanitost) — od relačních DB po video a sociální sítě

⚡ Velocity (Rychlost) — data se generují a mění v reálném čase

Někdy se přidává 4. V: Veracity (věrohodnost = kvalita dat)

💡 Příklad z praxe

Maloobchodní řetězec Lidl: Vrstva 1 (zdroje): pokladní ERP systémy, věrnostní karty, IoT senzory chlazení. Vrstva 2 (příjem): Data Lake na AWS S3 — surová data z celé Evropy. Vrstva 3 (analytická data): AWS Redshift datový sklad — transformovaná, vyčištěná data. Vrstva 4 (analýza): OLAP dotazy, predikce prodejů, detekce krádeží. Vrstva 5 (prezentace): Power BI dashboardy pro category managery — „kolik prodáme rohlíků příští týden v Brně?"

⚠️ Časté záludnosti

❌ Data Lake ≠ Datový sklad — Data Lake ukládá surová data (schema-on-read); DW obsahuje transformovaná data (schema-on-write).

❌ 3V (Volume, Variety, Velocity) charakterizují vrstvu příjmu dat (Big Data), ne BI jako celek.

❌ BI neřídí podnik — podporuje rozhodování; rozhodnutí dělá management.

❌ OLAP patří do analytické vrstvy (č. 4), ne do vrstvy zdrojových dat.

🧩 Laicky — od surových dat k rozhodnutí

Představ si supermarket. Vrstva 1 (zdroje): pokladní systémy, věrnostní karty, senzory teploty v lednicích, sociální sítě. Vrstva 2 (příjem): vše se hodí do Data Lake (jako do velké krabice — zatím netřídíme). Vrstva 3 (analytická data): z krabice vytáhneme jen ta data, která potřebujeme, vyčistíme je a dáme do datového skladu. Vrstva 4 (analýza): OLAP dotazy — kolik se prodalo rohlíků po regionech minulý rok? Vrstva 5 (prezentace): Power BI dashboard pro manažera. Celé to spolu = BI pipeline.

🎓 Napojení na DP

II · 11

Analytické potřeby uživatelů Business Intelligence a podstata integrace dat, přístupy integrace dat v BI, příprava v ETL systémech.

📋 Co je ETL a integrace dat v BI?

Uživatelé BI potřebují historická data v čitelné podobě — produkční systémy ale historii neuchovávají a kódují hodnoty pro počítače, ne lidi (místo „Praha" je tam číslo „19"). ETL (Extract-Transform-Load) je tradiční proces, který data z různých zdrojů vybere (Extract = vytáhni), transformuje do čitelné a konzistentní podoby (Transform = uprav) a nahraje do datového skladu (Load = nahraj). ELT (Extract-Load-Transform) nejprve vše nahraje do Data Lake v surové podobě a transformuje až když jsou data potřeba — typické pro cloudové Big Data systémy. ETL má přesně definovaných 9 kroků.

📐 Slovníček: Staging area = dočasné meziuložiště dat (jako odkládací stůl před úklidem — data jsou tam než se přesunou dál). Datová pumpa = softwarový nástroj pro (polo)automatizaci ETL procesu. Batch = dávkové zpracování (naráz velký objem dat, typicky v noci). Deduplication = odstranění duplicit (= duplicitních záznamů). Mapování = přiřazení: „toto pole ze zdroje jde do tohoto sloupce v cíli".

🔄 ETL vs ELT — klíčový rozdíl

📤 ETL (tradiční, strukturovaná data):

1. Extrahuj ze zdrojů → 2. Transformuj (čisti, mapuj kódy) → 3. Nahraj do DW

✅ Výhoda: DW obsahuje čistá, konzistentní data

❌ Nevýhoda: pomalejší, musíš znát strukturu předem

📥 ELT (Big Data, cloud):

1. Extrahuj → 2. Nahraj surová data do Data Lake → 3. Transformuj v cílovém systému

✅ Výhoda: flexibilnější, škálovatelný pro masivní data

⚙️ Datová pumpa

🔧 Softwarový nástroj pro (polo)automatizaci ETL procesu

🚰 „Kopíruje" data ze zdrojového do cílového úložiště

📋 Definuje: přenos + transformaci dat

⏰ Spouštěna periodicky (noční batch), při události nebo kontinuálně

Příklady: SSIS (SQL Server Integration Services), Apache NiFi, Talend, Azure Data Factory

📋 9 kroků návrhu ETL procesu

1️⃣ Analýza požadavků na datové pohledy (co analytici potřebují vidět)
2️⃣ Vytvoření referenčních dat (číselníky = tabulky pro převod kódů, mapovací tabulky)
3️⃣ Extrakce dat z různých zdrojů (databáze, soubory, API)
4️⃣ Validace extrahovaných dat (kontrola formátů, rozsahů, null hodnot = prázdných polí)
5️⃣ Transformace dat (čištění, sjednocení formátů, odvozené hodnoty)
6️⃣ Uložení do dočasného úložiště (staging area = odkládací místo)
7️⃣ Výběr cílového zdroje a mapování atributů (= které pole jde kam)
8️⃣ Nahrání dat do datového skladu
9️⃣ Monitorování a protokolování stavu (logy, chybová hlášení)

📐 Konceptuální model ETL

Popis zdrojů a vztahů k DW

📦 Koncepty (= entity dat)

🏷️ Atributy (= pole, sloupce)

🔗 Vztah „je součástí" (Part-of)

🔄 Transformace (= co se změní)

➡️ Sekvence transformací (= pořadí kroků)

📊 Logický model ETL

Dokumentace pracovního postupu

🔀 Workflow ETL — sekvence toků dat (odkud → kam)

⚙️ Procesy ETL — návrh aktivit a transformací

📅 Scénář ETL — plán provádění, synchronizace (= kdy co spustit), monitorování

🛠️ Fyzický model ETL

📩 Konfigurace zasílání chybových zpráv

📈 Trendové křivky spuštěných ETL balíčků

⏱️ Nastavení pořadí spouštění procesů

Moderní nástroje: Azure Data Factory, AWS Glue, Apache Spark, Informatica

💡 Příklad z praxe

Bankovní ETL pipeline: nočně (02:00) se extrahují transakce z core banking systému, CRM a risk platformy. T = anonymizace PII (GDPR), konverze měn na CZK, mapování produktových kódů (číslo → název), deduplication duplicit. L = nahrání do Azure Synapse Analytics DW. Nástroj: Azure Data Factory. Výsledek: ráno má risk management kompletní report o portfoliu. Staging area drží data 7 dní pro re-run při chybě.

⚠️ Časté záludnosti

❌ ETL není jen kopírování dat — transformace zahrnuje čištění, deduplication (= odstranění duplicit), mapování kódů (číslo „19" → text „Praha"), sjednocení formátů.

❌ ELT není „špatný ETL" — je optimalizovaný pro masivní paralelní zpracování v cloudových Data Lake prostředích.

❌ Staging area ≠ datový sklad — je to dočasné úložiště (krok 6), než se data nahrají do finálního DW.

❌ Datová pumpa není fyzické zařízení — je to softwarový nástroj.

🧩 Laicky — ETL jako stěhování bytu

Máš tři různé byty (= tři různé zdrojové systémy: ERP, CRM, Excel tabulky). Chceš přestěhovat jen vybrané věci do nového většího domu (= datový sklad). Extract = vybaleš z každého bytu to, co potřebuješ. Transform = přebalíš, přebarví, opravíš poškozené věci, přejmenuj krabice — všechno musí sedět do nového systému. Load = nastěhuješ do nového domu. ETL se typicky spouští v noci (batch zpracování), aby nepřetěžoval provozní systémy přes den.

🎓 Napojení na DP

II · 12

Datový sklad a jeho vlastnosti, datové tržiště a rozdíly mezi datovým skladem a datovým tržištěm. Kimballův vs. Inmonův přístup v návrhu datových skladů.

📋 Co je datový sklad a datové tržiště?

Datový sklad (Data Warehouse, DS) je centrální úložiště dat určené výhradně pro analytické dotazy a podporu rozhodování — není to běžná produkční databáze. Bill Inmon jej v roce 1991 definoval čtyřmi klíčovými vlastnostmi: předmětově orientovaný, integrovaný, neměnný, časově rozlišený. Datové tržiště (Data Mart, DM) je menší podmnožina DS zaměřená na jedno oddělení. Dva hlavní přístupy návrhu jsou Kimballův (zdola-nahoru, začíná od DM) a Inmonův (shora-dolů, začíná od centrálního DS).

📐 Slovníček: Historizace = uchovávání dat v čase (nejen aktuální stav, ale i všechny minulé stavy). Integrace = sjednocení dat z různých zdrojů do jednotné podoby. CIF (Corporate Information Factory) = Inmonova architektura — centrální datový sklad jako továrna na informace. Granularita = míra podrobnosti uložených dat (denní granularita = jeden řádek = jeden den). OLTP = systém pro zápis transakcí (pokladna, bankovní systém); DW = systém pro čtení a analýzu historických dat.

🏛️ 4 vlastnosti DS podle Inmona (1991)

🎯 Předmětově (subjektově) orientovaný
Data organizovaná kolem předmětů zájmu (zákazníci, produkty, prodeje) — ne kolem procesů

🔗 Integrovaný
Data ze všech provozních systémů s jednotnou sémantikou (= stejným významem pojmů) a formátem

🔒 Neměnný (nízká proměnlivost)
Data se po nahrání nemění ani neodstraňují; změny = nové záznamy (historické snímky)

📅 Časově rozlišený (historizace)
Data za desítky let; umožňuje analýzu trendů, vzorů a korelací z historického pohledu

🏪 Datové tržiště (Data Mart)

📌 Podmnožina datového skladu pro jednu obchodní jednotku (jedno oddělení)

🎯 Zaměření: prodej, finance, marketing, HR — vždy jen jeden subjekt

📊 Data jsou obvykle mírně agregovaná (ne atomická = transakční jako v DS)

📥 Zdroj dat: z DS nebo přímo z provozních systémů

✅ Výhoda: rychlejší dotazy, jednodušší správa pro oddělení

❌ Nevýhoda: riziko nekonzistence mezi DM různých oddělení

⚔️ Kimball vs Inmon — dva přístupy k návrhu DS

Kritérium	Datový sklad (DS)	Datové tržiště (DM)
Zaměření	Celý podnik (zákazníci, produkty, zaměstnanci)	Jedna obchodní jednotka (pouze marketing)
Granularita dat	Transakční (atomická) úroveň = každý řádek = 1 událost	Mírně agregovaná = sečtená po skupinách
Historické pokrytí	Plně historické	Omezeno na potřeby oddělení
Velikost	Velká (terabajty)	Menší (gigabajty)

⬇️

Kimball — Zdola-nahoru

Nejprve DM pro jednotlivé procesy

DS = konsolidovaný pohled na množinu DM

📌 Dimenzionální modelování, hvězdicové schéma

✅ Rychlejší implementace, viditelnější výsledky

❌ Obtížnější údržba, risk nekonzistence

⬆️

Inmon — Shora-dolů

Nejprve centrální DS pro celý podnik

Pak z něj vznikají DM

📌 CIF = Corporate Information Factory

✅ Konzistentní, jeden zdroj pravdy

❌ Složitější implementace, pomalejší start

💡 Příklad z praxe

Supermarket Lidl: OLTP databáze (produkční) — MariaDB, 15 000 transakcí/minutu, data aktuální do sekundy. DW (Kimball přístup) — nejdřív datové tržiště pro kategorii „mléčné výrobky" (tabulka faktů PRODEJE + dimenze PRODUKT, ČAS, PRODEJNA), pak „pekárna", pak konsolidace do DS. Inmon: nejdřív centrální DS pro celý řetězec, pak z něj DM pro oddělení. V praxi dominuje Kimball — rychleji vidíš výsledky pro jednotlivá oddělení.

⚠️ Časté záludnosti

❌ DS ≠ klasická databáze — DS je primárně jen pro čtení, nemění se a je optimalizovaný pro analytické dotazy; OLTP je pro zápis.

❌ Kimball nepopírá existenci DS — říká, že DS je konsolidovaný pohled na datová tržiště, ne separátní systém.

❌ CIF = Corporate Information Factory = Inmonova architektura (nezaměňovat s Kimballem).

❌ „Neměnný" neznamená, že se nikdy nic nepřidá — přidávají se nové záznamy (historické snímky), existující záznamy se ale nemění.

🧩 Laicky — muzeum vs supermarket

Produkční DB (OLTP) = supermarket: neustálý provoz, zboží přichází a odchází, zajímá tě aktuální stav (kolik rohlíků je teď na skladě?). Datový sklad = muzeum: data se přidávají (nové exponáty), ale nemažou (historické exponáty zůstávají). Zajímají tě trendy a historie (jak se vyvíjely prodeje rohlíků za posledních 10 let?). Kimball = postav každý sál (DM) zvlášť a pak propoj. Inmon = postav nejdřív celé muzeum (DS) a pak v něm urči specializované sály.

🎓 Napojení na DP

II · 13

Charakteristika multidimenzionální databáze, datová kostka, míry, dimenze.

📋 Co je multidimenzionální databáze a datová kostka?

Multidimenzionální databáze (MD) jsou specializované databáze navržené pro analytické zpracování — ukládají data ve vícerozměrné struktuře, která odpovídá tomu, jak analytici přirozeně přemýšlí (podle produktu, zákazníka, času, regionu...). Základní stavební kámen je datová kostka — analogie „tabulky" v relačních DB. Kostka se skládá ze dimenzí (osy, kategorie, popisky) a měr (číselné hodnoty pro agregaci). Klíčový pojem je granularita — jak podrobně jsou data uložena.

📐 Slovníček a formální zápis: Datová kostka = ⟨D, M, A, f⟩ (čti: čtveřice D, M, A, f) kde: D = množina dimenzí (= osy kostky, popisky), M = množina měr (= číselné ukazatele v buňkách), A = množina atributů dimenzí (= konkrétní vlastnosti dimenzí), f = zobrazení (= funkce) přiřazující každé dimenzi sadu atributů. D a M jsou disjunktní (= nemají žádný společný prvek — co je dimenze, nemůže být míra a naopak).

📦 Datová kostka — definice

🔷 Datová struktura pro ukládání a analýzu vícerozměrných dat

📐 Formálně čtveřice ⟨D, M, A, f⟩:

🔵 D — množina dimenzí (= kategorické osy: PRODUKT, ČAS, REGION)

🟢 M — množina měr (= číselné ukazatele: TRŽBY, MNOŽSTVÍ)

🏷️ A — množina atributů dimenzí (= vlastnosti os: den/měsíc/rok v dimenzi ČAS)

🔗 f — zobrazení (= funkce): každá dimenze → sada atributů

⚠️ D a M jsou disjunktní (= bez průniku — nesdílejí žádný prvek)

📏 Dimenze vs Míry

📐 Dimenze = hierarchicky uspořádané kategorické osy kostky

→ Popisují co, kde, kdy, kdo

→ Typicky: PRODUKT, ZÁKAZNÍK, ČAS, REGION

→ Mají hierarchie (= stromové úrovně): Den → Měsíc → Rok

📊 Míry = kvantitativní (= číselné) ukazatele v buňkách

→ Hodnoty pro agregaci (SUM = součet, AVG = průměr, COUNT = počet)

→ Typicky: PRODEJE (Kč), MNOŽSTVÍ (ks), NÁKLADY

⚠️ Atribut je buď dimenze NEBO míra — nikdy obojí!

📏 Granularita — přesnost dat

Granularita = míra podrobnosti dat. Dimenze ČAS může mít granularitu: Den → Měsíc → Čtvrtletí → Rok. Čím nižší granularita (= den), tím více dat, tím přesnější analýzy — ale pomalejší dotazy. Čím vyšší (= rok), tím méně dat, rychlejší dotazy — ale ztratíš denní detaily. Granularita se definuje při návrhu kostky a nelze ji pak snadno změnit.

💾 MOLAP — Multidimenzionální OLAP

Data uložena přímo v MD struktuře (kostce)

✅ Rychlé analytické dotazy — data jsou přednačtena

❌ Vyšší nároky na diskový prostor

❌ Omezená škálovatelnost (velké kostky = problém)

Příklad: Microsoft SSAS, IBM Cognos TM1

📋 ROLAP — Relační OLAP

MD data uložena v relačních tabulkách (hvězdicové schéma)

✅ Neomezený objem dat

✅ Flexibilnější pro velká data

❌ Pomalejší než MOLAP (= musí JOINovat)

Příklad: SQL Server + SSAS Tabular

🔀 HOLAP — Hybridní OLAP

Kombinace: agregáty (= předpočítané součty) v kostce (MOLAP) + detailní data v relační DB (ROLAP)

✅ Kompromis výkon vs prostor

❌ Složitější architektura

Dotaz na agregát → rychlé (z kostky); dotaz na detail → z relační DB

💡 Vizualizace datové kostky

Kostka se třemi dimenzemi: PRODUKT (osa X) × ZÁKAZNÍK (osa Y) × ČAS (osa Z). Každá „buňka" v prostoru = tržby konkrétního produktu u konkrétního zákazníka v konkrétní den. Míra = Kč tržeb. Granularita ČAS = den. Pro „výběr" jednoho zákazníka z kostky použijeme Slice operaci (viz slide 14).

⚠️ Časté záludnosti

❌ Datová kostka může mít více než 3 dimenze — „kostka" je metafora; v praxi běžně 5–20 dimenzí.

❌ Dimenzionální atribut nelze použít jako míru a naopak — D a M jsou disjunktní.

❌ MD databáze ≠ datový sklad — MD je způsob ukládání dat, DW je architektonický koncept.

❌ MOLAP ≠ ROLAP — MOLAP ukládá přímo v kostce (rychlé, ale náročné na prostor), ROLAP v relačních tabulkách (flexibilní, pomalejší).

🧩 Laicky — excel s filtry vs 3D kostka

Představ si tabulku prodejů: řádky = produkty, sloupce = měsíce, hodnoty = tržby v Kč. To je 2D tabulka. Přidej třetí rozměr = regiony → dostaneš kostku. Dimenze = osy: PRODUKT, ČAS, REGION. Míra = tržby (Kč) v každé buňce kostky. Granularita ČAS = den = každý den má svůj řádek (více dat, přesnější). Granularita ČAS = rok = jen roční součty (méně dat, rychlejší). MOLAP = tato kostka je uložena přímo jako kostka. ROLAP = tato kostka je uložena v normálních SQL tabulkách a teprve při dotazu se „rozbalí" do kostky.

🎓 Napojení na DP

II · 14

Technologie OLAP (On Line Analytical Processing), hierarchie dimenzí, OLAP operace.

📋 Co je OLAP a jeho operace?

OLAP (On-Line Analytical Processing = online analytické zpracování) je technologie pro multidimenzionální analýzu dat nad datovými kostkami. Analytikům umožňuje klást složité dotazy a zkoumat data z různých úhlů pohledu interaktivně. Zavedl jej E.F. Codd v roce 1993, který také definoval 12 pravidel pro OLAP systémy. Klíčové jsou hierarchie dimenzí (stromová struktura dat na různých úrovních detailu) a čtyři základní OLAP operace: Roll-up, Drill-down, Slice, Dice.

📐 Slovníček: Roll-up = „sroluj nahoru" = agreguj (= sečti/průměruj) na vyšší úroveň hierarchie (z dnů na měsíce). Drill-down = „vrtej dolů" = jdi na nižší úroveň detailu (z měsíce na dny). Slice = „ukrojení" = vyber jednu konkrétní hodnotu z jedné dimenze → dostaneš plátěk (nižší-dimenzionální pohled). Dice = „nakrájení na kostičky" = filtruj podle více dimenzí najednou → dostaneš menší podkostku. Hierarchie = stromová struktura (Den → Měsíc → Rok).

📐 Hierarchie dimenzí

🌳 Logická stromová struktura uvnitř dimenze

📌 Každý člen má 1 nadřazeného a 0+ podřízených

📅 Příklad ČAS: Den → Týden → Měsíc → Čtvrtletí → Rok

📦 Příklad PRODUKT: Konkrétní typ → Výrobce → Kategorie

🌍 Příklad REGION: Město → Kraj → Stát → Kontinent

🎯 Hierarchie = umožňují vidět data na různé úrovni detailu

🔧 SQL rozšíření pro OLAP

📜 ISO/IEC standard přidal do GROUP BY:

🧊 CUBE — vypočítá všechny možné kombinace dimenzí (= totální křížová tabulka)

📈 ROLLUP — hierarchická agregace (nejprve detaily, pak součty nadřazených úrovní)

🎯 GROUPING SETS — výběr konkrétních kombinací skupin

SELECT KVARTAL, REGION, SUM(PRODEJE)
FROM PRODEJE
GROUP BY CUBE(KVARTAL, REGION)
-- vypočte SUM pro každou kombinaci hodnot

⬆️

Roll-up — agreguj nahoru

Z detailu na celkový pohled

Den → Měsíc → Rok

Typ → Výrobce → Kategorie

Méně detailů, širší pohled

Případně odebere celou dimenzi úplně

Jako GROUP BY na vyšší úrovni

⬇️

Drill-down — jdi do detailu

Z celku na podrobnosti

Rok → Měsíc → Den

Více detailů, užší pohled

Přidá novou dimenzi nebo úroveň

Opak Roll-up

✂️

Slice — ukroj plátěk

Vyber jednu hodnotu z dimenze

Výsledek: pohled bez té dimenze (nižší rozměr)

Příklad: jen rok 2024 z dimenze ČAS

Redukuje kostku o 1 dimenzi

Dimenze zmizí (je fixní)

🎲

Dice — nakrájej podkostku

Vyber rozsah hodnot ze 2+ dimenzí

Výsledek: podkostka (menší kostka)

Příklad: (LCD, 2023-24, EU) → nová kostka

Filtruje, ale dimenze ZŮSTÁVAJÍ

💡 Příklad z praxe

E-commerce OLAP kostka (PRODUKT × ČAS × REGION): Roll-up: z denních tržeb → měsíční → roční přehled pro ředitele. Drill-down: rozklikni Q3 → zobrazíš jednotlivé týdny → zjistíš „prodeje explodovaly 15.7. kvůli Summer Sale". Slice: zobrazit jen zákazníky segmentu „Gold" (zafixuj dimenzi ZÁKAZNÍK.Segment). Dice: LCD televize + rok 2024 + trh EU → podkostka pro category managera. SQL: GROUP BY CUBE(KVARTAL, REGION) vypočte všechny kombinace najednou.

⚠️ Časté záludnosti

❌ Roll-up ≠ Drill-down — roll-up agreguje nahoru (méně detailů), drill-down jde dolů (více detailů). Jsou přesné opaky!

❌ Slice pracuje s jednou dimenzí, Dice s dvěma nebo více dimenzemi.

❌ OLAP ≠ OLTP — OLAP je pro analýzu (čtení historických dat), OLTP je pro transakce (zápis aktuálních dat).

❌ Slice odstraní dimenzi z kostky (zafixuje jednu hodnotu = dimenze zmizí); Dice dimenzi ponechá, jen omezí rozsah hodnot.

🧩 Laicky — analýza prodejů jako Google Maps

Představ si Google Maps. Roll-up = přiblíž výřez mapy (uvidíš celou ČR, přestaneš vidět ulice). Drill-down = oddal výřez (uvidíš ulice a čísla domů). Slice = „zobraz jen Prahu" = z celé mapy ČR vyřízneš jediný plátěk (Praha) a zbytek zahodíš. Dice = „zobraz jen velká města v Čechách (ne na Moravě) a v letních měsících" = vybereš podoblast podle více kritérií najednou — dostaneš menší mapu (podkostku).

🎓 Napojení na DP

II · 15

Techniky dimenzionálního modelování, tabulka faktů, tabulka dimenzí. Tvorba klíčových ukazatelů výkonnosti (KPI) a vizualizace dat v Self-service Business Intelligence.

📋 Co je dimenzionální modelování, KPI a Self-service BI?

Dimenzionální modelování je přístup k navrhování databázových struktur pro analytické systémy. Na rozdíl od normalizovaných relačních schémat je záměrně denormalizované (= nadbytečné kopie dat jsou OK) pro maximální výkon čtení. Výsledkem je typicky hvězdicové schéma (star schema): uprostřed jedna velká tabulka faktů (obsahuje číselné míry pro analýzu) a kolem ní tabulky dimenzí (obsahují textový kontext a popisy). KPI (Key Performance Indicators = klíčové ukazatele výkonnosti) jsou měřitelné ukazatele definované přes tabulku faktů. Self-service BI umožňuje i netechnickým uživatelům vytvářet vlastní analýzy.

(Schéma hvězda versus OLAP kostka)

📐 Slovníček: Fakt = numerická (= číselná) míra z obchodního procesu (cena, množství, tržba). Dimenze = textový kontext (název produktu, jméno zákazníka, datum). Surrogátní klíč = uměle vygenerované ID (1, 2, 3...) v tabulce dimenzí — ne přirozený klíč ze zdrojového systému. Denormalizace = záměrné uložení stejné info na více místech pro rychlost (víceúrovňová hierarchie v jedné tabulce dimenzí). Aditivita = míra, kterou lze sčítat přes dimenze (tržby se sčítají). Neaditivní míra = nelze sčítat (průměrná cena — nelze jen sečíst průměry).

📊 Tabulka faktů

🎯 Ukládá číselné míry z obchodních procesů

🔑 PK (primární klíč): složený z cizích klíčů dimenzí — každý řádek = jedna měřená událost

🔗 FK (cizí klíče): 2 nebo více, odkazující na tabulky dimenzí

📊 Aditivita: míry se sčítají přes dimenze (SUM prodejů)

⚙️ Typy faktů:

📋 Transakční (1 řádek = 1 transakce)

📸 Periodické snímky (stav k určitému datu)

🔄 Akumulované snímky (průběh celého procesu)

📋 Tabulka dimenzí

🏷️ Ukládá textový kontext — popis, kategorie, hierarchie

🔑 PK: vlastní surrogátní klíč (= uměle vygenerované ID, ne přirozený klíč ze zdroje)

📊 Charakteristika: méně řádků, mnoho sloupců

🌳 Hierarchie: produkt → značka → kategorie (redundantně = nadbytečně uloženy v jedné tabulce)

📌 Záměrně denormalizované — rychlost čtení > normalizace

🎯 Slouží k: filtrování (WHERE), seskupení (GROUP BY), popisu (SELECT)

❓ Fakt nebo Dimenze? — klíčová otázka návrhu

Fakt = číselné měření, nabývá mnoha různých hodnot, účastní se výpočtů (agregací). Příklad: cena transakce = 199 Kč, 299 Kč, ... Dimenzionální atribut = diskrétní (= s omezenými hodnotami) popis, víceméně konstantní, slouží k filtrování. Příklad: kategorie produktu = „Elektronika". Pokud máš pochybnosti — ptej se: „Agreguju (SUM, AVG) tuto hodnotu?" Ano → fakt. „Filtruji nebo seskupuji podle ní?" Ano → dimenze.

🎯 KPI — klíčové ukazatele výkonnosti

📌 Měřitelné ukazatele pro sledování výkonnosti

✅ Požadavky na dobrý KPI:

🎯 V souladu s cíli podniku

📏 Měřitelný — má konkrétní číslo (ne „zákazníci jsou spokojeni" ale „NPS > 50")

📊 Definovaný na metrice (čas, kvalita, náklady, spokojenost)

⏱️ Sledovaný v čase (= trendy)

🖥️ Vizualizovaný v dashboardech nebo score cards

📱 Self-service BI

🎯 Uživatel bez IT oddělení vytváří vlastní analýzy

🔧 Nástroje: Power BI, Tableau, Qlik Sense, Google Looker Studio

📊 Výstupy: dashboardy, pivotní tabulky, grafy, heatmapy

✅ Výhoda: rychlost, nezávislost na IT, demokratizace dat

❌ Riziko: nekonzistentní definice metrik, „shadow analytics" (= každé oddělení si počítá KPI jinak)

⚠️ Adtivní vs Neaditivní míry

Schéma	Struktura dimenzí	Výkon čtení	Složitost
⭐ Hvězdicové (Star)	Denormalizované — vše v jedné tabulce dimenzí	Nejrychlejší (méně JOIN)	Jednodušší dotazy
❄️ Sněhové (Snowflake)	Normalizované — dimenze rozděleny do více tabulek	Pomalejší (více JOIN)	Složitější dotazy
🌌 Souhvězdí (Galaxy)	Více tabulek faktů sdílejících dimenze	Závisí	Nejsložitější

💡 Příklad z praxe

Power BI report pro e-shop: Tabulka faktů PRODEJE (FK→Zákazník, FK→Produkt, FK→Datum, Množství, TržbaKč). Dim ZÁKAZNÍK: ID, Segment (B2B/B2C), Region. Dim PRODUKT: ID, Kategorie, Značka. Dim DATUM: Den, Týden, Měsíc, Rok, Sezóna. KPIs: Konverzní poměr > 3 %, průměrná hodnota košíku > 1 200 Kč, NPS > 45, obrátka zásob < 14 dní. Pozor: průměrná sleva je neaditivní KPI — nelze sčítat přes regiony (průměr průměrů ≠ celkový průměr).

⚠️ Časté záludnosti

❌ Tabulka faktů má složený PK z FK dimenzí, ne vlastní vygenerovaný klíč.

❌ Tabulky dimenzí jsou záměrně denormalizované — hvězdice je záměrně nenormalizovaná pro výkon; sněhové schéma je normalizovanější (pomalejší).

❌ KPI musí být měřitelný a definovaný — „zákazníci jsou spokojeni" není KPI; „NPS skóre > 50" je KPI.

❌ Neaditivní míra (průměrná cena, procenta) se nesmí sčítat přes dimenze — dostaneš špatný výsledek.

🧩 Laicky — hvězda je jako sluneční soustava

Tabulka faktů = Slunce (střed, velká, číselná data). Tabulky dimenzí = planety kolem (popisky, méně řádků, mnoho sloupců s textem). Příklad: Faktura (= tabulka faktů): obsahuje jen čísla — PartnerID, ProduktID, DatumID, Částka (Kč), Množství (ks). Zákazník (= tabulka dimenzí): ZákazníkID, Jméno, Město, Segment. Kategorie (= tabulka dimenzí): KategorieID, Název, Nadkategorie. Ptáš se „kolik jsme prodali produktů kategorie Elektronika zákazníkům z Prahy v Q1 2024?" — JOINuješ Faktura + Zákazník + Kategorie + Datum a sečteš Částku.

🎓 Napojení na DP

II · 16

Lambda kalkul, redukce a konverze výrazů; použití lambda kalkulu pro formální popis databázových struktur a specifikaci dotazů.

📋 Co je lambda kalkul?

Lambda kalkul je minimalistický formální systém pro popis výpočtů pomocí funkcí — vynalezl jej Alonzo Church ve 30. letech 20. stol. Celý systém stojí na třech věcech: proměnné, abstrakce (= definice funkce) a aplikace (= volání funkce). Nic jiného nepotřebujete. Přesto je Turingovsky úplný. Základní operace jsou α-konverze (alfa-konverze = přejmenování vázané proměnné), β-redukce (béta-redukce = dosazení argumentu do těla funkce) a η-konverze (éta-konverze = zjednodušení zbytečné abstrakce). Je teoretickým základem funkcionálního programování.

📐 Vysvětlení symbolů: λ (lambda) = symbol pro anonymní funkci: λx.výraz čteme „funkce s parametrem x, která vrací výraz". → = „se přepíše na" nebo „přechází na". α (alfa) = název pro přejmenování proměnné. β (béta) = název pro dosazení (substituci) argumentu. η (éta) = zjednodušení. Volná proměnná = proměnná, která není vázaná žádnou lambdou v daném výrazu (jako globální proměnná). Vázaná proměnná = proměnná zavedená lambdou (jako parametr funkce).

λ Syntaxe lambda kalkulu

Výraz (= lambda term) je definován rekurzivně — může být:

e ::= x          -- proměnná (jméno)
    | lambda x.e  -- abstrakce (definice funkce s parametrem x)
    | e1 e2       -- aplikace (e1 volaná s argumentem e2)

🔵 Volná proměnná — není vázaná lambdou v tom výrazu (jako globální proměnná)

🟢 Vázaná proměnná — zavedena lambdou, platí v těle (jako lokální parametr)

Příklad: lambda x. lambda y.(x y) = funkce dvou argumentů, aplikuje x na y

⚙️ Tři základní konverze

🔵 α-konverze (alfa) = přejmenování parametru

lambda x.x → lambda y.y

Výsledek je stejný — jen jsme přejmenovali parametr

🟢 β-redukce (béta) = dosazení argumentu

(lambda x.x+1) 5 → 5+1 → 6

Dosaď 5 za každé x v těle funkce

🟡 η-konverze (éta) = zjednodušení zbytečné funkce

lambda x.(f x) → f

„Funkce, která jen volá f s argumentem x, JE f"

🔢 Churchovy numerály — čísla jako funkce

V čistém lambda kalkulu neexistují čísla — kódují se jako funkce:

= lambda f. lambda x.x     -- aplikuj f nula-krát, vrať x
= lambda f. lambda x.(f x) -- aplikuj f jednou
= lambda f. lambda x.(f(f x)) -- aplikuj f dvakrát
n = aplikuj f n-krát

Číslo n = „funkce, která aplikuje jinou funkci n-krát"

♾️ Y-kombinátor — rekurze bez jmen

🔁 Rekurze = funkce, která volá samu sebe

Problém: v čistém lambda kalkulu nemůžeš napsat „zavolej sebe sama" (funkce nemá jméno)

Řešení: Y-kombinátor = funkce, která „vytvoří pevný bod" = f(Y f) = Y f

🟢 Lambda kalkul je Turingovsky úplný = umí spočítat cokoliv, co Turingův stroj

🧩 Základ pro: Lisp, Scheme, Haskell, ML, Clojure

💡 Propojení s Pythonem

Python lambda = přímá implementace lambda kalkulu: lambda x: x + 1 je lambda x.x+1. β-redukce = volání: (lambda x: x+1)(5) → 6. Uzávěry (closures) v Pythonu = zachycení volných proměnných z vnějšího scope — přesně jako v lambda kalkulu.

⚠️ Časté záludnosti

❌ β-redukce (= dosazení) není prosté nahrazení textu — musíš hlídat zachycení proměnné: pokud argument obsahuje proměnnou se stejným názvem jako vázaná, nejdřív proveď α-přejmenování.

❌ Lambda kalkul sám o sobě nemá čísla, řetězce ani podmínky — vše se kóduje funkcemi (Churchovy numerály, Boolean = pravda jako lambda t. lambda f.t, nepravda jako lambda t. lambda f.f).

❌ η-konverze (éta) platí jen pokud x není volná proměnná ve f — jinak by se změnil význam.

🧩 Laicky — lambda kalkul jako matematika bez čísel

Lambda kalkul je jako matematika, kde existují jen funkce — žádná čísla, žádné typy, žádné podmínky. Vše jsou jen funkce. Číslo 3 je funkce, která aplikuje jinou funkci třikrát. Sčítání je funkce. IF-THEN-ELSE je funkce. λx.x+1 čteme: „funkce, která dostane x a vrátí x+1". (λx.x+1) 5 čteme: „zavolej tu funkci s argumentem 5" → výsledek je 6. α-konverze = přejmenuj parametr: λx.x je totéž co λy.y (jako přejmenovat parametr funkce, výsledek je stejný). β-redukce = dosaď argument: (λx.x+1) 5 → 5+1 → 6.

🎓 Napojení na DP

II · 17

Funkcionální programování a základy algoritmizace v jazyku Scheme (Lisp), rekurze a práce se seznamy.

📋 Co je Scheme a funkcionální programování?

Scheme je minimalistický dialekt jazyka Lisp (LISt Processing = zpracování seznamů), navrženého v roce 1958 Johnem McCarthym — prvního plně funkcionálního jazyka. Oba mají jedinou syntaktickou formu: S-výrazy (= symbolické výrazy, prefix notace), zapsané jako (operátor argument1 argument2 ...). Scheme přidává lexikální rozsah platnosti (= proměnná je viditelná tam, kde je definována, ne kde je volána) a tail-call optimalizaci (TCO) — rekurzivní volání v tail pozici (= jako poslední operace) nepřidává nový rámec zásobníku, takže Scheme zvládne nekonečnou rekurzi bez přetečení paměti.

📐 Slovníček: S-výraz (symbolický výraz) = základní syntaktická forma: (operátor arg1 arg2). Tail pozice = poslední volání ve funkci — nic dalšího se po něm nepočítá, takže zásobník nepotřebuje uchovávat rámec. Zásobník volání (call stack) = struktura paměti, kde jsou uloženy aktivní rámce funkcí (při normální rekurzi roste, při TCO nemusí). Closure (uzávěr) = funkce + zachycené proměnné z prostředí, kde byla vytvořena. Mutace = destruktivní změna hodnoty proměnné (v čistě FP stylu se jí vyhýbáme).

📝 Základní syntaxe Scheme

; Definice funkce
(define (factorial n)
  (if (= n 0)
      1
      (* n (factorial (- n 1)))))

; Volání
(factorial 5)  ; => 120

; Lambda (anonymní funkce)
(define double (lambda (x) (* x 2)))
(double 7)  ; => 14

; Let — lokální proměnné (paralelní)
(let ((x 3) (y 4))
  (+ (* x x) (* y y)))  ; => 25

📋 Práce se seznamy

; cons = "construct" (přidej prvek na začátek)
(cons 1 '(2 3))   ; => (1 2 3)
; car = "Contents of Address Register" = první prvek
(car '(1 2 3))    ; => 1
; cdr = "Contents of Decrement Register" = zbytek
(cdr '(1 2 3))    ; => (2 3)

; map — aplikuj funkci na každý prvek
(map (lambda (x) (* x x)) '(1 2 3 4))
; => (1 4 9 16)

; filter — vyber prvky splňující podmínku
(filter odd? '(1 2 3 4 5))
; => (1 3 5)

🔁 Tail-call optimalizace (TCO)

🟢 Scheme garantuje TCO (standard R5RS, R7RS)

📐 Volání v tail pozici = je poslední operací — žádný výpočet po návratu

; Tail-rekurzivní factorial (s akumulátorem)
(define (fact-iter n acc)
  (if (= n 0)
      acc
      (fact-iter (- n 1) (* n acc))))
; (fact-iter 1000000 1) — konstantní zásobník!
; Neexploduje, protože TCO = jako smyčka

vs. neoptimalizovaná verze = každý krok přidá rámec na zásobník → přetečení pro velká n

🗂️ Speciální formy Scheme

🔵 define — pojmenovaná vazba (globální nebo lokální)

🟢 lambda — anonymní funkce = uzávěr (closure)

🟡 let — paralelní lokální proměnné (definuj naráz)

🟡 let* — sekvenční (každá vidí předchozí)

🟠 letrec — vzájemně rekurzivní definice

🔵 cond — vícevětvová podmínka (jako switch/else-if)

🟢 begin — sekvence výrazů, vrátí poslední

🔴 set! — destruktivní přiřazení (= mutace = mění hodnotu; vyhni se v FP stylu)

💡 Closures (uzávěry) — funkce s pamětí

Scheme funkce „si pamatuje" prostředí, kde byla vytvořena:

(define (make-counter)
  (let ((count 0))        ; lokální proměnná count
    (lambda ()            ; vrátí anonymní funkci
      (set! count (+ count 1))
      count)))

(define c (make-counter))
(c)  ; => 1  -- count se zvýšil
(c)  ; => 2  -- count přetrvává i po návratu z make-counter!

Uzávěr = funkce + zachycené proměnné z vnějšího scope. Základ pro objekty, generátory a moduly v FP.

⚠️ Časté záludnosti

❌ let váže paralelně — v inicializátorech nevidíš ostatní nové proměnné (všechny se definují „naráz"). Pro sekvenční závislost použij let*.

❌ set! je imperativní (= mutuje stav) — v čistě funkcionálním stylu se vyhýbáme mutaci.

❌ Scheme rozlišuje #t/#f od prázdného seznamu '() — (null? #f) vrátí #f (false není null)!

🧩 Laicky — Lisp jako kalkul přicestoval do praxe

Lisp/Scheme vypadá divně, protože závorky jsou všude: (+ 1 2) místo 1 + 2. Proč? Protože operátor je vždy první — žádné precedenční pravidlo, žádná nejednoznačnost. (* 2 (+ 3 4)) = 2 × (3+4) = 14. Tail-call optimalizace: normální rekurze factorial(1000000) = exploduje zásobník (milion rámců na zásobníku). TCO verze = zásobník má vždy jen 1 rámec, funguje jako smyčka. Closure je jako tajná schránka: funkce si „pamatuje" proměnné z místa, kde byla vytvořena — i po návratu z nadřazené funkce.

🎓 Napojení na DP

II · 18

Struktura překladače, scanner, parser, derivační strom.

📋 Co je struktura překladače?

Překladač (compiler) je program, který vezme zdrojový kód a přeloží jej do jiného jazyka (typicky z C/Java do strojového kódu). Celý proces probíhá ve dvou hlavních fázích: analýza (co kód říká) a syntéza (vygeneruji výstupní kód). Analýza má tři podkroky: lexikální analýza (scanner = „skener" — rozbij text na tokeny), syntaktická analýza (parser = „rozbor" — postav strom podle gramatiky) a sémantická analýza (zkontroluj typy, deklarace). Syntéza pak pracuje s mezikódem a generuje výstup.

📐 Slovníček: Token = základní lexikální jednotka (klíčové slovo, číslo, operátor) — jako slova ve větě. AST (Abstract Syntax Tree = abstraktní syntaktický strom) = stromová reprezentace struktury kódu bez zbytečností. Lexikální chyba = neplatný symbol/token (jako překlep). Syntaktická chyba = správné tokeny, špatná struktura (jako věta se špatnou gramatikou). Sémantická chyba = správná gramatika, špatný typ/smysl (přiřadit řetězec do čísla). 3-adresový kód (TAC) = mezikód ve tvaru výsledek = operand1 op operand2. Tabulka symbolů = slovník proměnných — mapuje jméno → typ, adresu, scope.

🔍 Fáze 1: Lexikální analýza (Scanner)

📥 Vstup: proud znaků (zdrojový text)

📤 Výstup: proud tokenů (= lexikálních jednotek)

🔵 Token = (typ, hodnota, pozice v souboru)

Typy tokenů: klíčové slovo, identifikátor, číslo, operátor, závorka, …

int x = 42 + y;
→ [KW:int] [ID:x] [OP:=]
   [NUM:42] [OP:+] [ID:y] [SEMI]

⚡ Implementace: DFA (deterministický automat) nebo regulární výrazy

🗂️ Odstraní: mezery, komentáře, prázdné řádky

🌳 Fáze 2: Syntaktická analýza (Parser)

📥 Vstup: proud tokenů

📤 Výstup: AST (Abstract Syntax Tree = abstraktní syntaktický strom)

🔵 Ověří strukturu dle bezkontextové gramatiky

Metody parsování:

🟢 LL(1) — shora dolů, přediktivní, 1 token lookahead (koukání dopředu)

🟡 LR(1) — zdola nahoru, shift-reduce, mocnější

assign_stmt → ID '=' expr ';'
expr → expr '+' term | term
term → NUM | ID

🧠 Fáze 3: Sémantická analýza

📥 Vstup: AST

📤 Výstup: anotovaný AST + tabulka symbolů

Kontroluje:

🔵 Typová kontrola — kompatibilita typů (nelze přiřadit string do int)

🟢 Deklarace — použité proměnné musí být deklarovány

🟡 Scope (= obor platnosti) — proměnná viditelná jen ve svém bloku

🟠 Koerce (= implicitní přetypování, automatická konverze) — int → float

📚 Tabulka symbolů: mapuje ID → typ, adresa, scope

⚙️ Fáze 4–6: Syntéza

🔵 Generátor mezikódu — 3-adresový kód (TAC = Three-Address Code)

x = a + b * c      (zdrojový kód)
→  t1 = b * c       (mezikód: každá instrukce má max 3 operandy)
   t2 = a + t1
   x  = t2

🟢 Optimalizace — eliminace mrtvého kódu (= kódu, který se nikdy nespustí), inlining funkcí, smyčkové optimalizace

🟡 Generátor cílového kódu — přiřazení registrů CPU, výstup v assembleru / strojovém kódu

📊 Tabulka symbolů

🔵 Datová struktura sdílená všemi fázemi překladače

Uchovává pro každý identifikátor (= proměnnou/funkci):

📝 Jméno a typ (int, float, pointer)

📍 Adresu (offset = posun v zásobníkovém rámci od začátku)

🔒 Scope (= obor platnosti: globální / lokální / parametr)

📐 Rozměry (pro pole)

🔗 Implementace: hash tabulka (rychlé vyhledávání) nebo B-strom pro velké programy

💡 Příklad: průchod celým pipeline

Zdrojový kód: int z = x + 2 * y;

1. Lexer: [KW:int][ID:z][OP:=][ID:x][OP:+][NUM:2][OP:*][ID:y][SEMI]

2. Parser: AST: assign(z, add(x, mul(2, y)))

3. Sémantika: ověř, že x,y,z jsou int; 2 je int literál → ok

4. Mezikód: t1=2*y; t2=x+t1; z=t2;

5. Optimalizace: pokud y je konstanta, spočítej t1 v compile time (= v čase překladu)

6. Strojový kód: MOV EAX, y; IMUL EAX, 2; ADD EAX, x; MOV z, EAX

⚠️ Časté záludnosti

❌ Lexikální vs syntaktická chyba: 123abc je lexikální chyba (neplatný token); int = x je syntaktická (správné tokeny, špatná gramatická struktura).

❌ AST ≠ parse tree: Parse tree zachovává všechna gramatická pravidla; AST je zjednodušená reprezentace bez zbytečných mezivýsledků.

❌ Sémantická analýza nekontroluje runtime chyby (null pointer, dělení nulou) — to se projeví až za běhu programu.

🧩 Laicky — překladač jako redaktor knihy

Máš rukopis v češtině a chceš ho přeložit do angličtiny. Lexer (scanner) = rozseká text na slova a interpunkci (tokeny). Parser = zkontroluje, jestli věty dávají gramatický smysl (AST = syntaktický strom vět). Sémantická analýza = zkontroluje, jestli věty dávají logický smysl (přestat mi, nejde říct „přiřaď jablko do čísla"). Mezikód = hrubý překlad do esperanta (jazyk, který pochopí oba). Optimalizace = zjednoduš věty. Generátor kódu = přelož z esperanta do angličtiny.

🎓 Napojení na DP

II · 19

Kompilátory a interprety, dynamický kompilátor, zdrojový kód, p-kód/bytecode, strojový kód. Runtime (virtuální stroj).

📋 Co jsou kompilátory, interprety a JIT?

Existují tři fundamentálně odlišné způsoby, jak „spustit" program napsaný ve vyšším jazyce: kompilace (přelož celý program do strojového kódu předem), interpretace (čti a prováděj instrukce jednu po druhé za běhu) a JIT kompilace (Just-In-Time = „právě včas" — za běhu kompiluj nejpoužívanější části do strojového kódu). Většina moderních systémů kombinuje: Java a Python kompilují do bytekódu (= přenosného mezikódu pro virtuální stroj), který pak JVM nebo CPython interpretuje nebo JIT kompiluje. Runtime (= prostředí za běhu) je celé prostředí, které program provozuje: garbage collector, standardní knihovny, bezpečnostní sandbox.

📐 Slovníček: Bytekód = přenosný mezikód pro virtuální stroj (VM) — není to strojový kód procesoru, ale instrukce pro VM. JVM = Java Virtual Machine = virtuální stroj pro Java bytekód. JIT = Just-In-Time kompilace = překlad za běhu programu. Warm-up = zahřívání = počáteční fáze, kdy JIT identifikuje „horká místa". Garbage Collector (GC) = automatický správce paměti = hledá nepoužívané objekty a uvolní paměť. Deoptimalizace = JIT zahodí zkompilovaný kód (když se předpoklad ukáže jako špatný) a vrátí se k interpretaci.

🔍 Kompilace vs interpretace

Vlastnost	Kompilátor	Interpret	JIT
Kdy překládá	Před spuštěním (compile time)	Za běhu (řádek po řádku)	Za běhu (blok po bloku, jen horká místa)
Rychlost spuštění	Rychlé (hotový .exe)	Pomalé (parsuje stále)	Střední (warm-up fáze)
Rychlost za běhu	Nejrychlejší (nativní kód)	Nejpomalejší (overhead)	Rychlá po warm-up
Přenositelnost	Nízká (vázaná na OS/CPU)	Vysoká (jeden interpret)	Vysoká (bytekód)
Ladění (debug)	Těžší (ztracené info)	Snadné (vidíš zdroják)	Střední
Příklady	C, C++, Rust, Go	Python (CPython), Ruby	Java (JVM), JS (V8), C# (.NET)

📦 Bytekód a virtuální stroj

🔵 Bytekód = přenosný mezikód pro virtuální stroj (VM)

📝 Instrukce pro zásobníkový VM (= operace nad zásobníkem) nebo registrový VM

☕ Java: .java → javac (překladač) → .class (JVM bytekód) → JVM spustí

🐍 Python: .py → CPython → .pyc (bytekód) → CPython VM interpretuje

🟢 Výhoda: Write once, run anywhere (napiš jednou, spusť kdekoliv)

🔴 Nevýhoda: nutnost VM → startovací overhead (= zpomalení při startu) a paměť

⚡ JIT kompilace

🔁 Profiling (= profilování) — VM sleduje, které části kódu jsou „horké" (volané opakovaně)

🔥 Kompilace za běhu — horká místa se zkompilují do nativního strojového kódu

💾 Cache (= mezipaměť) — zkompilovaný kód se uloží, příště přeskočí VM overhead

🟡 Deoptimalizace — pokud se předpoklad (typ proměnné) změní, JIT zahodí zkompilovaný kód a vrátí se k interpretaci

Příklady: HotSpot JVM, V8 (Chrome/Node.js), PyPy

🏗️ Runtime prostředí

Runtime = vše co program potřebuje za běhu (mimo OS):

🗑️ Garbage Collector (GC) — automatická správa paměti (uvolní nepoužívané objekty)

📚 Standardní knihovny — I/O, síť, kolekce

🔒 Bezpečnostní sandbox — JVM security manager (omezí přístup k souborům/síti)

📞 FFI / JNI = Foreign Function Interface / Java Native Interface = volání nativního (= nepsaného v Javě) kódu z VM

🔍 Reflexe = introspekce (= zkoumání) tříd a metod za běhu programu

🗑️ Garbage Collection strategie

🔵 Reference counting (= počítání referencí) — počítej, kolik proměnných ukazuje na objekt; nulový count = uvolni. Selhává u cyklů.

🟢 Mark-and-Sweep (= označ a zameť) — označ dostupné objekty, zbytek zameť (JVM)

🟡 Generational GC (= generační GC) — mladé objekty sbírej častěji (většina objektů umírá brzy)

🟠 Compacting GC (= kompaktující) — defragmentuj haldu (= paměťový prostor pro objekty) po sběru

⚠️ Časté záludnosti

❌ JIT není automaticky rychlejší než kompilátor — kód musí nejprve „zahřát" (warm-up fáze). Pro krátce žijící procesy (CLI nástroje, skripty) je JIT pomalejší.

❌ Python bytekód (.pyc) se stále interpretuje v CPythonu — není to JIT. PyPy je jiná implementace Pythonu s JIT.

❌ GC nezaručuje okamžité uvolnění paměti — finalizéry (= destruktory) se volají nedeterministicky (= nevíme přesně kdy).

💡 Java: celý pipeline v jednom obrázku

Hello.java (zdrojový kód) → javac (překladač/kompilátor) → Hello.class (bytekód) → JVM (virtuální stroj, spustí bytekód) → HotSpot JIT (zkompiluje horké metody do nativního kódu) → CPU. Na každém OS/CPU stačí jen přeinstalovat JVM, bytekód je přenosný.

🧩 Laicky — recept, kuchař vs robot

Kompilátor = přelož celou kuchařku do robotího jazyka ještě před vařením. Robot pak vaří bleskově (čte přeložené instrukce přímo). Nevýhoda: kuchařka pro robota HP-200 nefunguje na robotu HP-300 (jiný CPU = jiný strojový kód). Interpret = kuchař čte originální českou kuchařku za pochodu, každý krok překládá sám, jak vaří. Pomalé, ale kuchářka funguje na každém kuchaři. JIT = chytrý kuchař, který si zapamatuje nejčastěji vařené recepty v robotím překladu. Prvních 10 porcí pomalé, pak bleskové. Bytekód = kuchařka v esperantu — přenosná (každý VM ji pochopí), ale stále potřebuje interpretaci nebo JIT.

🎓 Napojení na DP

II · 20

Regulární, LL1 a LR1 zásobníkové automaty, gramatiky a jazyky. Vztahy a možnosti transformace mezi nimi.

📋 Co jsou LL(1) a LR(1) zásobníkové automaty?

Parser (= syntaktický analyzátor) potřebuje algoritmus pro rozhodování, jak zpracovat příchozí tokeny. Dvě hlavní rodiny algoritmů jsou LL(1) a LR(1). LL(1) čte vstup zleva doprava, staví derivaci levostranně, koukne 1 token dopředu (lookahead = „prohlédnutí dopředu") — provádí analýzu shora dolů pomocí zásobníkového automatu. LR(1) čte zleva, ale staví derivaci zprava — analýza probíhá zdola nahoru (shift-reduce) a je výkonnější. Zásobníkový automat (PDA) je formální základ pro obě metody: konečný automat rozšířený o zásobník.

📐 Slovníček formálního zápisu PDA = (Q, Σ, Γ, δ, q₀, Z₀, F): Q = konečná množina stavů. Σ (sigma) = vstupní abeceda. Γ (gama) = zásobníková abeceda (symboly, které smí být na zásobníku). δ (delta) = přechodová funkce (pravidla přechodů). q₀ (q nula) = počáteční stav. Z₀ (Z nula) = počáteční symbol zásobníku. F = množina přijímacích stavů. Derivace = postup odvozování slov z gramatiky aplikací pravidel. Levostranná derivace = vždy rozviň nejlevější neterminál. Pravostranná derivace = vždy rozviň nejpravější neterminál.

📐 Zásobníkový automat (PDA)

PDA = (Q, Σ, Γ, δ, q₀, Z₀, F)

🔵 Q — konečná množina stavů

🟢 Σ (sigma) — vstupní abeceda (co čte ze vstupu)

🟡 Γ (gama) — zásobníková abeceda (co může mít na zásobníku)

🟠 δ (delta) — přechodová funkce: (stav, vstupní symbol nebo ε, vrchol zásobníku) → (nový stav, nový vrchol zásobníku)

🔴 q₀ — počáteční stav; Z₀ — počáteční symbol zásobníku

Přijímá: prázdným zásobníkem nebo koncovým stavem (obě jsou ekvivalentní)

🔵 Deterministický PDA (DPDA) = základ LL(1) a LR(1)

⬆️ LL(1) — shora dolů

🔵 Čte vstup zleva doprava (L)

🟢 Derivace levostranná (L) — vždy rozviň nejlevější neterminál

👁️ Lookahead (= „předvídání") 1 token — stačí se podívat na 1 token dopředu

📋 Řídí se rozkladovou tabulkou M[neterminál, token]

Zásobník: [S, $]  Vstup: id + id $
S → E         [E, $]     id+id$
E → T E'      [T,E',$]   id+id$
T → id        [id,E',$]  id+id$
match id      [E',$]     +id$
E' → + T E'   [+,T,E',$] +id$
...

⬇️ LR(1) — zdola nahoru

🔵 Čte vstup zleva doprava (L)

🟢 Derivace pravostranná (R) — redukuj, dokud nedostaneš startovací symbol

👁️ Lookahead 1 token

⚙️ Dvě operace:

➡️ Shift (= přesuň) — přesuň token ze vstupu na zásobník

⬆️ Reduce (= redukuj) — nahraď vrchol zásobníku levou stranou pravidla

📋 Řídí se Action/Goto tabulkou

🟢 Varianty: SLR(1) (nejjednodušší), LALR(1) (praktický — yacc/bison), Canonical LR(1) (nejsilnější, největší tabulky)

📊 LL(1) vs LR(1) srovnání

Vlastnost	LL(1)	LR(1)
Směr derivace	Levostranná	Pravostranná
Síla (co umí)	Slabší	Silnější
Levá rekurze	Nelze (zacyklí se)	Podporuje
Implementace	Jednoduchá (ručně)	Generátor (yacc/bison)
Nástroje	ANTLR, LL(k)	yacc, bison, LALR
Jazyky	LL(1) ⊂ LR(1) (méně gramatik)	Superset LL(1)

💡 FIRST a FOLLOW množiny (pro LL(1) tabulku)

🔵 FIRST(α) = množina terminálů (= tokenů), kterými může začínat řetězec odvozený z α (= „co může přijít jako první?")

🟢 FOLLOW(A) = množina terminálů, které mohou následovat za neterminálem A v jakémkoliv odvozeném řetězci (= „co přijde po A?")

Pravidlo patří do tabulky M[A, a]: pokud a je v FIRST(pravé strany) nebo (pravá strana může derivovat ε a a je v FOLLOW(A))

Pokud jsou dvě pravidla v jedné buňce tabulky → konflikt → gramatika není LL(1).

⚠️ Časté záludnosti

❌ Levá rekurze zakáže LL(1): pravidlo E → E + T | T způsobí nekonečnou smyčku při shora-dolů parsování (vždy rozviješ E, vždy dostaneš E, ...). Řeší se přepsáním: E → T E'; E' → + T E' | ε

❌ LALR(1) ≠ LR(1) — LALR sloučí stavy a může způsobit konflikty, které kanonický LR(1) nemá. V praxi se LALR(1) používá (menší tabulky, méně paměti).

❌ PDA přijímající prázdným zásobníkem a PDA přijímající koncovým stavem jsou ekvivalentní — přijímají stejnou třídu jazyků (= bezkontextové jazyky, Typ 2 Chomského hierarchie).

🧩 Laicky — stavebnice LEGO shora vs zdola

LL(1) = skládání shora dolů. Začneš od výsledku (celá věta/program) a postupně rozkládáš na menší části. „Program se skládá z funkcí. Funkce se skládá z příkazů. Příkaz se skládá z..." — jako číst návod od nadpisu dolů. Podíváš se na jeden příští token a víš, do jakého pravidla jít. LR(1) = skládání zdola nahoru. Začneš od tokenů (základních dílů) a postupně je skládáš do větších celků. Vidíš „id + id" → to je výraz. „výraz;" → to je příkaz. Silnější, ale složitější — proto se většinou generuje automaticky (yacc, bison).

🎓 Napojení na DP

PIS · 1

ICT management, modely životního cyklu vývoje projektu.

📋 Co je ICT management a životní cyklus projektu?

ICT management = řízení informačních a komunikačních technologií v podniku tak, aby IT sloužilo firemním cílům a přinášelo hodnotu.

Životní cyklus vývoje projektu (anglicky Software Development Life Cycle, SDLC) = metodika, která říká, ve kterém pořadí a jakým způsobem se projekt plánuje, analyzuje, navrhuje, implementuje a provozuje. Bez metodiky by projekt byl chaos.

Obecné fáze vývoje (dle Merunky):

⚙️ 1. Iniciace – požadavky, proveditelnost, dokumentace, infrastruktura

🔨 2. Konstrukce – analýza, návrh, implementace, testování (sekvenčně nebo iteračně)

🚀 3. Dodání – testování na produkci, nasazení, vyhodnocení

🔧 4. Provoz – uživatelská podpora, údržba

📐 Typy modelů: Sekvenční = striktní pořadí fází. Iterativní = vracíme se zpět a upřesňujeme. Adaptivní = extrémně zkrácené iterace, průběh určován se zákazníkem.

🌊 Waterfall (Vodopád)

Sekvenční model – každá fáze musí být dokončena, než začne další. Výstup jedné = vstup další.

📋 Požadavky → 🎨 Návrh → 💻 Implementace → 🧪 Testování → 🔧 Údržba

✅ Jednoduchý, snadno plánovatelný

❌ Nepružný – změny jsou drahé

🔄 Agile

Iterativní + adaptivní model – krátké cykly (sprinty, cca 1–2 týdny), zpětná vazba po každé iteraci.

📋 Plánování → 🔍 Analýza → 🎨 Návrh → 💻 Implementace → 🧪 Testování → 🚀 Vydání → opakovat

✅ Flexibilní, rychlá reakce na změny

❌ Těžší plánování rozpočtu a termínů

🌀 Spiral

Iterativní model zaměřený na rizika – každý cyklus obsahuje analýzu rizik.

📋 Plánování → ⚠️ Analýza rizik → 🎨 Návrh → 💻 Implementace → 🧪 Testování → 📊 Evaluace → opakovat

✅ Vhodný pro velké/rizikové projekty

❌ Složitý, nákladný

💡 Příklad z praxe:

Waterfall: Stavba mostu – nejprve celý projekt na papíře, pak kopáš základy, pak nosníky, pak střecha – nelze přeskočit pořadí.

Agile: Vývoj mobilní aplikace – každé 2 týdny vydáme novou verzi, zákazník ji otestuje a řekne, co chce jinak.

Spiral: Vývoj řídicího systému jaderné elektrárny – každý cyklus důkladně analyzujeme, co se může pokazit, a teprve pak postoupíme dál.

⚠️ Časté záludnosti

❌ Waterfall není špatný model – je nevhodný pro projekty, kde se požadavky mění. Pro pevně definované projekty je stále nejlepší volbou.

❌ Agile ≠ žádné plánování. Agile má plánovací fáze, jen jsou kratší a opakují se v každém sprintu.

❌ Spiral ≠ jednoduchá spirála – každý cyklus musí obsahovat formální analýzu rizik, jinak to není Spiral model.

❌ Adaptivní model je podtyp iterativního – liší se extrémně zkrácenou dobou iterace, ne absencí plánu.

🧩 Laicky

Představ si, že stavíš dům. Waterfall = nejprve celý projekt na papíře, pak kopáš základy, pak zdi, pak střecha – nelze přeskočit. Agile = nejprve postavíš obytnou buňku, zákazník ji vyzkouší, pak přidáš pokoj, zákazník řekne „chci větší kuchyň" a ty to upravíš. Spiral = před každou fází se zastavíš a ptáš se „co se může pokazit a jak tomu předejdeme?"

🎓 Napojení na DP

PIS · 2

Analýza a návrh IS, nástroje datového a funkčního modelování.

📋 Co je analýza a návrh IS?

IS (Informační systém) = soubor lidí, technických prostředků a metod pro sběr, přenos, uchovávání a zpracování dat za účelem tvorby a prezentace informací uživatelům.

Analýza IS = modelování budoucího systému na konceptuální úrovni (CO má systém dělat, bez ohledu na technologii). Jinak: PIM = Platform Independent Model (model nezávislý na platformě).

Návrh IS = modelování na technologické úrovni (JAK to bude technicky realizováno). Výsledkem jsou: architektura, logický datový model, popis komponent, projektová dokumentace.

Typy požadavků: Funkční = co systém musí dělat (přímé požadavky na funkce). Nefunkční = jak dobře to musí dělat (výkon, bezpečnost, spolehlivost).

Sběr požadavků: interview, workshopy, pozorování, dotazníky, analýza dokumentace zákazníka.

📊 Datové modelování

Modeluje statickou strukturu dat a jejich vztahů. Odpovídá na otázku: Jaká data existují a jak spolu souvisí?

ER diagram

(Entity-Relationship; není součástí UML)

📦 Entity (obdélníky) = objekty reálného světa (Student, Faktura)

🔗 Relace/Vztahy (kosočtverce) = slovesa (Navštěvuje, Platí)

📝 Atributy = vlastnosti entity (jméno, datum)

Class diagram (UML)

🏷️ Třídy + atributy + metody

🔗 Asociace = obecná vazba; Agregace = slabší celek-část (student v více skupinách); Kompozice = silnější celek-část (stránka patří jen jedné knize); Generalizace = dědičnost (Zaměstnanec → Manažer)

⚙️ Funkční modelování

Modeluje co systém dělá – funkce a toky dat.

DFD – Data Flow Diagram (Diagram datových toků; není součástí UML):

⭕ Proces = transformuje vstupy na výstupy

➡️ Datový tok = přesun informací (ne řízení!)

📂 Data store = úložiště dat

👤 Terminátor = externí entita (uživatel, jiný systém)

Nultá úroveň DFD = Kontextový diagram – celý systém jako jediný proces; vymezuje IS vůči okolí.

UML nástroje: Use Case diagram, Diagram aktivit, Stavový diagram

💡 Příklad z praxe:

Navrhujeme e-shop. ER diagram zachytí entity Zákazník, Produkt, Objednávka a jejich vztahy. DFD ukáže tok dat: Zákazník → zadá objednávku → Systém → vygeneruje fakturu → Zákazník. Use Case ukáže, co zákazník může se systémem dělat (přihlásit se, koupit, sledovat zásilku).

⚠️ Časté záludnosti

❌ ER diagram ≠ Class diagram. ER se používá primárně pro modelování databází (entity = tabulky). Class diagram modeluje objekty v kódu (třídy mají i metody).

❌ DFD nemá řídicí tok ani rozhodování – pouze ukazuje, kudy tečou data. Podmínky a větvení nejsou součástí DFD.

❌ Nultá úroveň DFD (kontextový diagram) zobrazuje systém jako JEDEN proces – nedekomponuje ho. Dekompozice začíná na 1. úrovni.

❌ Agregace ≠ Kompozice: agregovaný objekt může existovat bez celku (student bez skupiny); při kompozici ne (stránka bez knihy neexistuje).

🧩 Laicky

Datové modelování je jako kreslit mapu vztahů: „zákazník nakupuje produkty, produkty patří do kategorií." Funkční modelování je jako kreslit výrobní linku: „surovina vstoupí, projde přes stroj A, pak stroj B, vyjde hotový výrobek." ER diagram je schéma skladu (co tam je a jak to spolu souvisí). DFD je schéma toho, jak se věci pohybují.

🗂️ Doménový model a abstrakční úrovně

Doménový model = speciální případ Class diagramu (součást UML), kde jsou zobrazeny pouze názvy tříd, atributy bez datových typů a relace. Slouží jako technické řešení systému / návrh databáze.

Abstrakční úrovně datového modelování (míra abstrakce se snižuje →):

🔵 Konceptuální úroveň – CO existuje, nezávislé na technologii (PIM = Platform Independent Model)

🟡 Technologická úroveň – JAK to bude realizováno (výběr platformy, DB technologie)

🟢 Implementační úroveň – konkrétní implementace (DDL skripty, fyzické tabulky, indexy)

💡 Výsledný konceptuální model analýzy IS je složen z: ER diagram + Class diagram + DFD (kontextový diagram) + Use Case diagramy.

🎓 Napojení na DP

PIS · 3

Objektově orientovaná analýza a modelování, diagramy a jejich vzájemné souvislosti.

📋 Co je OOA/OOD?

OOA (Objektově orientovaná analýza) = přístup k analýze systému, kde se systém popisuje jako skupina objektů, které na sebe navzájem působí zasíláním zpráv. Výsledkem je konceptuální model (use case diagramy, class diagramy, interakční diagramy).

OOD (Objektově orientované modelování/design) = přetváří konceptuální model z OOA na implementační třídy a rozhraní. Bere v potaz omezení: HW, OS, programovací jazyk.

Klíčové pojmy OOP:

🎁 Zapouzdření (Encapsulation) = skrytí vnitřních dat objektu před okolím – ostatní vidí jen to, co jim dovolíme (public interface)

👨‍👩‍👦 Dědičnost (Inheritance) = podtřída zdědí vlastnosti a metody nadtřídy a může přidat nové nebo přepsat stávající

🎭 Polymorfismus = stejná zpráva může být různými objekty zpracována různě (přetěžování + přepisování metod)

🔌 Rozhraní (Interface) = definuje, co objekt umí (hlavičky metod), ale ne jak to dělá

🔍 Strukturní diagramy UML

📐 Diagram tříd (Class diagram) – třídy, jejich atributy, metody a vztahy (asociace, agregace, kompozice, generalizace). Popis datového modelu objektů.

🎯 Objektový diagram – instance tříd v konkrétním okamžiku. Je to „vyplněný class diagram" – ukazuje konkrétní objekty, ne obecné třídy.

🧩 Diagram komponent – komponenty systému, jejich rozhraní a závislosti. Vhodný pro návrh SW architektury.

🎬 Diagramy chování a interakce

🔄 Stavový diagram – životní cyklus objektu: v jakých stavech se může nacházet a jak přechází mezi nimi na základě událostí.

👤 Use Case diagram – vnější pohled: kdo (aktér) co se systémem dělá. Zachycuje funkční požadavky.

⚡ Diagram aktivit – průběh procesu: kroky, větvení, paralelismus, rozhodování. Vhodný i pro business procesy.

📬 Sekvenční diagram – chronologická výměna zpráv mezi objekty. Ukazuje kdo komu co říká a kdy.

🔗 Vzájemné souvislosti diagramů

📌 Class diagram → Objektový diagram: Třída definuje strukturu, objektový diagram ukazuje konkrétní instance v čase.

📌 Use Case → Sekvenční diagram: Každý případ užití (use case) je detailně rozpracován jako sekvenční diagram (kdo co v jakém pořadí volá).

📌 Class diagram → Stavový diagram: Třídy (objekty) mohou mít stavové diagramy popisující jejich životní cyklus.

📌 UML dovoluje, aby diagramy byly neúplné nebo nekonzistentní – to je záměr (slouží pro komunikaci, ne jako právní dokument).

💡 Příklad z praxe – e-shop:

Class diagram: Třídy Zákazník, Objednávka, Produkt s atributy a metodami. Objektový diagram: Konkrétní zákazník Jan Novák s objednávkou č. 101. Use Case: Zákazník může „přihlásit se", „přidat do košíku", „zaplatit". Sekvenční diagram: Zákazník → klikne Zaplatit → Systém → ověří platbu → Banka → potvrdí → Systém → zobrazí potvrzení zákazníkovi.

⚠️ Časté záludnosti

❌ OOA ≠ OOD. OOA = CO systém dělá (konceptuální model bez technologií). OOD = JAK to bude technicky realizováno (konkrétní třídy, platformy, frameworky).

❌ Objektový diagram není totéž co class diagram – je to jeho konkrétní instance v daném okamžiku za běhu programu.

❌ Polymorfismus ≠ jen přetěžování metod. Zahrnuje i přepisování (overriding) a v dynamických jazycích duck typing.

❌ Zasílání zpráv v OO ≠ volání funkcí v procedurálním programování – objekt po přijetí zprávy sám rozhodne, co udělá (dle svého stavu a implementace).

🧩 Laicky

Myslím na restauraci. Objekty jsou číšník, kuchař, pokladna. Každý má své vlastnosti (jméno, věk) a umí určité věci (obsloužit stůl, uvařit, zaúčtovat). Posílají si zprávy (zákazník říká číšníkovi „dejte mi svíčkovou", číšník to předá kuchaři). Zapouzdření = zákazník neví, jak kuchař vaří, jen dostane jídlo. Dědičnost = Manažer je Zaměstnanec + přidává „řídí tým".

🎯 Objektově orientovaný systém (OOS) a základní pojmy

OOS (Objektově orientovaný systém) = systém složený z objektů, které navzájem spolupracují zasíláním zpráv – liší se od volání funkcí: objekt po přijetí zprávy sám rozhodne, jakou funkci použije (na základě aktuálního stavu) – stejná zpráva tak může být zpracována různě.

Objekty/Třídy = datové struktury a metody pro přístup a práci s nimi; každý objekt má svou jedinečnou funkci, je definován svými vlastnostmi (tím, co je a co umí).

📋 Fáze OOA (3 fáze)

1. Analýza požadavků – sběr informací o požadavcích na systém, stanovení jeho funkcí

2. Návrh modelu – vytvoření modelu systému popisujícího jeho strukturu a chování

3. Verifikace a validace – ověření, zda model systému odpovídá požadavkům a specifikaci

📤 Výstup OOA: konceptuální model – use case diagramy, class diagramy, interakční diagramy

🔧 Fáze OOD (4 fáze)

1. Identifikace objektů/tříd – identifikace tříd tvořících systém, určení atributů a metod

2. Návrh tříd – model tříd popisující strukturu a vztahy mezi třídami

3. Implementace – třídy implementovány v programovacím jazyce podle návrhu

4. Testování – ověření funkčnosti implementovaného softwaru

📤 Výstupy OOD: sekvenční diagramy a diagram tříd. Bere v potaz omezení: HW, OS, programovací jazyk, nefunkční požadavky.

📐 Diagramy dle J. Arlow – záměrné vlastnosti

UML diagramy nemusí být komplexní, úplné ani konzistentní – slouží pro komunikaci, ne jako právní dokument. J. Arlow říká, že diagramy mohou být:

✂️ Proškrtané – nemusí obsahovat vše, co je v podkladu (zjednodušení záměrné)

🔲 Neúplné – určité prvky mohou v modelu zcela chybět

⚡ Nekonzistentní – model může obsahovat protimluvy

🎓 Napojení na DP

PIS · 4

Standard UML, jeho vznik, vývoj, ISO, vlastnosti, součásti a možnosti využití.

📋 Co je UML?

UML (Unified Modeling Language) = grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci softwarových systémů. Standardizovaný, objektově orientovaný. Unified = sjednocený – vznikl sloučením více starších notací (Booch, OMT, OOSE).

UML neobsahuje metodiku – říká, jak kreslit diagramy, ale ne jak analyzovat ani navrhovat. Diagramy mohou být neúplné, nekonzistentní a proškrtané – to je záměr (slouží pro komunikaci, ne jako právní dokument).

ISO/IEC 19505 = mezinárodní standard UML pod záštitou ISO (International Organization for Standardization = Mezinárodní organizace pro normalizaci). Spravuje jej OMG (Object Management Group).

Části UML standardu:

📐 Superstructure = základní konstrukty (třídy, vztahy, aktivity, komponenty)

🏗️ Infrastructure = meta-model (model modelů) stojící v pozadí, specifikovaný pomocí MOF (Meta Object Facility)

📏 OCL (Object Constraint Language) = jazyk pro podmínky (invarianty, vstupní/výstupní podmínky na modely)

🔄 Diagram Interchange = XML formát pro výměnu diagramů mezi různými CASE nástroji

📅 Vznik a vývoj UML

Verze	Rok	Novinky
UML 1.x	1997	Základní diagramy (třídní, stavové, sekvenční). Firma Rational Software, standard OMG.
UML 2.x	2005	Rozšíření: aktivity, komponenty, nasazení, komunikace, kompozice.
UML 2.5.x	2015	Nejnovější verze. Datové architektury, async zpracování, výkon, moderní trendy.

✅ Vlastnosti UML

🖼️ Grafická notace – různé pohledy na systém pomocí diagramů

📏 Standardizace – pojmy a značky jsou přesně definovány (ISO/IEC 19505)

🌐 Obecnost – použitelný pro libovolnou velikost a typ systému

🔧 Flexibilita – podpora analýzy, návrhu, implementace, testování i dokumentace

🔌 Rozšiřitelnost – lze přizpůsobit přes stereotypy a profily

🗣️ Komunikace – srozumitelný pro techniky i netechniky

🧱 Stavební bloky UML

1. Předměty – elementy modelu: třídy, rozhraní, use case, komponenty, uzly, aktéři

2. Relace (Vztahy) – propojení předmětů: asociace, dědičnost, kompozice, agregace, závislost, realizace

3. Diagramy – vizualizace: složeny z předmětů a relací; 14 typů diagramů ve 2 skupinách (strukturní + behaviorální)

+ Společné mechanismy (stereotypy, tagged values, constraints) + Architektura (4+1 pohledový model na navrhovaný systém)

💡 Možnosti využití UML v praxi:

🤝 Sezení s klientem – kreslíme procesy a požadavky na papír (use case, activity). 💰 Finanční ohodnocení projektu – přesná specifikace = přesný odhad. 💬 Komunikace mezi programátory (class diagram jako kontrak). ⚙️ Generování základní struktury kódu (skeletonů tříd). 📚 Dokumentace systému pro nové vývojáře.

⚠️ Časté záludnosti

❌ UML ≠ metodika. UML je jen jazyk (jak kreslit). Metodika říká, jak postupovat (RUP, Agile, SCRUM). Nelze říct „vyvíjíme v UML".

❌ UML diagramy nemusí být konzistentní ani úplné – UML to dovoluje záměrně pro flexibilitu komunikace.

❌ Infrastructure ≠ Superstructure: Infrastructure je meta-model (model modelů), Superstructure definuje konkrétní konstrukty pro modelování.

❌ OCL není programovací jazyk – je to jazyk pro zápis formálních podmínek a omezení v diagramech (např. invariant „věk musí být > 0").

🧩 Laicky

UML je jako gramatika jazyka – řekne ti, jak se píší věty (jak kreslit diagramy), ale neřekne ti, co máš napsat (jak navrhnout systém). Je to sdílená řeč architektů: místo slov „tady bude zeď" kreslíš čáru v plánu – a všichni vědí, co to znamená. Vznikl v roce 1997, protože každý tým dřív kreslil jinak – teď je jedna kuchařka pro všechny.

🎓 Napojení na DP

PIS · 5

Modelování dynamických vlastností systému pomocí UML.

📋 Co jsou dynamické vlastnosti systému?

Dynamické vlastnosti = chování systému v čase – jak se systém chová, jak reaguje na události, jak probíhají procesy. Na rozdíl od statických diagramů (class diagram = struktura), dynamické diagramy zachycují změny a průběh.

Tři hlavní dynamické diagramy v UML pro modelování procesů a chování:

⚡ Diagram aktivit – průběh procesů a algoritmů (workflow)

🔄 Stavový diagram – životní cyklus objektu (stavy a přechody na základě událostí)

👤 Use Case diagram – vnější pohled: kdo co se systémem dělá (funkční požadavky)

⚡ Diagram aktivit

Modeluje průběh procesů – kroky, větvení, smyčky, paralelismus.

▶️ Počáteční uzel (plný kruh) = start

📦 Aktivita = akce nebo soubor akcí

🔀 Rozdělovník/Spojovník (Fork/Join) – paralelní větve

🔷 Podmínka/větvení (kosočtverec) = rozhodování

🏊 Lane/Role = pruh s aktérem (zodpovědnost)

⏹️ Koncový uzel

Vhodný pro: procesy, algoritmy, workflow, business procesy

🔄 Stavový diagram

Modeluje životní cyklus objektu – v jakých stavech může být a jak mezi nimi přechází.

⚫ Počáteční pseudostav (plný kruh)

📦 Stav = situace, ve které objekt čeká (entry/do/exit akce)

➡️ Přechod = změna stavu (event[guard]/action)

🎯 Událost = vnější podnět způsobující přechod

⊙ Koncový pseudostav

Vhodný pro: objekty s komplexním životním cyklem (objednávka, uživatelský účet, protokol)

👤 Use Case diagram

Zachycuje vnější pohled na systém – kdo ho používá a jak.

🧍 Aktér/Účastník (figurka) = externí objekt interagující se systémem

⭕ Případ užití (ovál) = posloupnost akcí vedoucí k výsledku

➡️ Vazba include = UC vždy obsahuje jiný (povinné zahrnutí)

⤴️ Vazba extend = UC rozšiřuje jiný podmíněně

🔼 Vazba generalization = specializace use case nebo aktéra

Vhodný pro: definici funkčních požadavků, komunikaci se zákazníkem

💡 Příklad z praxe – bankovní aplikace:

Diagram aktivit: Přihlášení → Zobrazení účtu → Vybrat akci [větvení] → buď Výběr hotovosti nebo Převod → Potvrzení → Odhlášení.

Stavový diagram objednávky: Nová → Potvrzená → Odeslaná → Doručená → Uzavřená (nebo Zrušená z každého stavu).

Use Case: Aktéři = Zákazník, Administrátor. Use cases = Přihlásit se, Zobrazit zůstatek, Provést platbu (include: Ověřit identitu).

⚠️ Časté záludnosti

❌ Diagram aktivit ≠ vývojový diagram. Diagram aktivit podporuje paralelismus (fork/join) a objektové toky. Klasický vývojový diagram tyto prvky nemá.

❌ Stavový diagram ≠ diagram aktivit. Stavový diagram modeluje STAVY objektu (čeká, zpracovává). Diagram aktivit modeluje TOK AKCÍ (kroky procesu).

❌ Use Case diagram neříká NIC o tom, jak je funkce implementována – pouze zachycuje, co aktér se systémem dělá.

❌ Include ≠ Extend: Include = vždy se zavolá (povinné). Extend = zavolá se jen za určité podmínky (volitelné rozšíření).

🧩 Laicky

Diagram aktivit je jako kuchařský recept: krok 1, krok 2, pokud nemáš vejce → nahraď banánem, jinak pokračuj krokem 3. Paralelně: mezitím předehřej troubu. Stavový diagram je jako semafor: stav Červená → přechod (uplyne čas) → stav Oranžová → přechod → stav Zelená. Use Case je jako seznam služeb restaurace z pohledu zákazníka: „Zákazník může: objednat jídlo, zaplatit, reklamovat."

🎓 Napojení na DP

PIS · 6

Modelování interakcí s využitím UML.

📋 Co je modelování interakcí?

Interakce = výměna zpráv mezi objekty v rámci systému. Interakční diagramy popisují, jak objekty spolupracují pro dosažení konkrétního cíle.

Postup: 1) Identifikuj objekty → 2) Identifikuj scénáře → 3) Vytvoř diagram.

Interakční diagramy slouží k: dokumentaci toku zpráv uvnitř use casů, nalezení tříd a operací, dokumentaci návrhových vzorů, ukázání spolupráce objektů.

UML 2.0 přidalo dva nové typy: Diagram časování (Timing diagram) a Diagram přehledu interakcí (Interaction Overview diagram).

📬 Sekvenční diagram

Popisuje interakce v časové posloupnosti – kdo komu co říká a v jakém pořadí.

📦 Účastník (obdélník) = objekt, aktér, subsystém

⬇️ Životní linie (svislá čára) = existence objektu v čase

📊 Aktivace (obdélník na životní linii) = čas, kdy objekt zpracovává

➡️ Zpráva (šipka) = synchronní (čeká), asynchronní (nečeká), odpověď (přerušovaná)

🔷 Operátory: alt (podmínka, if-else), opt (volitelné), par (paralelní), loop (smyčka)

Zpráva nese informaci a spouští akci v cílovém objektu.

🗺️ Komunikační diagram

Ukazuje interakce podle propojení objektů, ne v časové ose. Zachycuje vztahy a strukturu spolupráce.

📦 Objekty propojeny čarami (vazbami)

🔢 Sekvenční čísla = pořadí zpráv (místo časové osy)

❌ Časová dimenze chybí – neukazuje KDY, ale KDO s KÝM komunikuje

Vhodný pro: ukázání topologie komunikace, kdo je s kým propojen

⏱️ Diagram časování (Timing diagram)

Speciální forma sekvenčního diagramu s obrácenou osou – čas jde zleva doprava, životní linie jsou vodorovné.

🕐 Zaměřen na časová omezení a závislosti

📏 Ukazuje, kdy se mění stav objektu a jak dlouho trvá každý stav

Novinka od UML 2.0. Vhodný pro real-time a embedded systémy.

🗂️ Diagram přehledu interakcí

Kombinuje sekvenční diagramy + diagram aktivit. Ukazuje přehled, jak na sebe navazují různé interakce.

🔀 Místo aktivit jsou vložené interakce (sekvenční diagramy jako uzly)

📋 Ukazuje celkový tok scénářů s větvením a smyčkami

Novinka od UML 2.0. Vhodný pro složité procesy s více interakčními scénáři.

💡 Příklad – přihlášení uživatele (sekvenční diagram):

Uživatel → [zadá heslo] → LoginForm → [ověřuje] → AuthService → [kontroluje] → Database → [vrátí výsledek] → AuthService → [vrátí token] → LoginForm → [zobrazí dashboard] → Uživatel. Operátor alt: pokud heslo špatně → zobrazí chybu (jiná větev).

⚠️ Časté záludnosti

❌ Sekvenční diagram ≠ komunikační diagram. Sekvenční = časová osa (kdo co říká KDY). Komunikační = topologie (kdo s kým je propojen).

❌ Synchronní zpráva ≠ asynchronní. Synchronní = odesílatel čeká na odpověď (plná šipka). Asynchronní = odesílatel pokračuje dál (otevřená šipka).

❌ Operátor alt ≠ opt: alt = buď/anebo (větve podmínky, obdoba if-else). opt = volitelné provedení (může nebo nemusí nastat, obdoba if bez else).

🧩 Laicky

Sekvenční diagram je jako scénář divadelní hry: Herec A říká větu, Herec B odpoví, pak Herec C přijde na scénu – vše v přesném časovém pořadí shora dolů. Komunikační diagram je jako schéma telefonní sítě – ukazuje, kdo je s kým propojen, ale ne přesně kdy volali. Timing diagram je jako EKG nebo muzikantská partitura – vodorovná osa je čas.

🎓 Napojení na DP

PIS · 7

Principy činnosti CASE nástrojů. Možnosti modelování požadavků na IS. Podpora implementace IS. Projektová dokumentace.

📋 Co jsou CASE nástroje?

CASE = Computer Aided Software Engineering (počítačem podporované softwarové inženýrství). Jde o softwarové nástroje, které modelují IT systém pomocí diagramů a podporují různé fáze vývoje IS.

Proč diagramy? Člověk chápe lépe obrázek než text. CASE nástroje umožňují zachytit požadavky, navrhnout systém, generovat kód a dokumentaci.

Integrované CASE nástroje mají centrální databázi (datový slovník), která propojuje elementy ze všech modelů a umožňuje automaticky kontrolovat konzistenci.

MDD = Model Driven Development (modelem řízený vývoj) = přístup, kde je tvorba SW séria transformací od modelu požadavků až po vygenerovaný kód. Tři úrovně:

📋 Konceptuální model – CO (nezávislé na platformě)

🔧 Logický model PIM (Platform Independent Model) – JAK obecně

⚙️ Fyzický model PSM (Platform Specific Model) – ČÍM konkrétně (Oracle DB, Java…)

📂 CASE nástroje dle fáze životního cyklu

⬆️ Pre CASE – tvorba globální strategie podniku

⬆️ Upper CASE – analýza, plánování, specifikace požadavků

➡️ Middle CASE – podrobná specifikace, návrh, dokumentace, vizualizace

⬇️ Lower CASE – kódování, testování, údržba, reverse engineering

📊 Post CASE – podpora organizačních a manažerských činností

📝 Projektová dokumentace

Úvodní studie

📄 Zadání projektu

📄 Specifikace požadavků

📄 Koncept systému

📄 Studie proveditelnosti

Globální analýza a návrh

📄 Hrubé konceptuální modely

📄 Návrh rozhraní mezi subsystémy

📄 Návaznost na okolní systémy

Detailní analýza a návrh

📄 Podrobné konceptuální modely

📄 Datový, objektový, funkční model

📄 Fyzický a logický model

🛠️ Kompletní přehled CASE nástrojů

Příklady CASE nástrojů pokrývající různé fáze vývoje IS:

Nástroj	Typ	Charakteristika
MetaEdit+	Upper/Middle CASE	Metamodelování – tvorba vlastních DSL (Domain Specific Languages) a CASE nástrojů
Visual Paradigm	Middle CASE	UML + BPMN + Agile, webová i desktopová verze
Enterprise Architect (Sparx)	Middle/Lower CASE	Komplexní UML, BPMN, ArchiMate, generování kódu, reverse engineering
MagicDraw / Cameo (No Magic)	Middle CASE	Pokročilý UML, SysML, aerospace & defense
PowerDesigner (Sybase/SAP)	Middle CASE	Datové modelování (ERD, PDM), business analýza, generování DDL skriptů
Oracle Designer (Oracle)	Middle/Lower CASE	CASE nástroj integrovaný s Oracle DB, modelování a generování kódu pro Oracle
Case Studio	Middle CASE	Datové modelování (ER diagramy), generování DDL pro různé DBMS
Rational Rose (IBM)	Middle CASE	Historický klasický UML nástroj (dnes nahrazen IBM RSA)
MS Visio	Post CASE	Kancelářský diagramovací nástroj, jednoduchý, není specializovaný CASE
Draw.io / Diagrams.net	Post CASE	Zdarma, online, rychlé prototypování – není plnohodnotný CASE

Schopnosti CASE nástrojů: modelování diagramů, reverse engineering, datové modelování, refaktoring kódu, generování zdrojových kódů a dokumentace, verzování kódu, návrh GUI.

📋 Modelování požadavků na IS – etapy (7.2)

Aktivity modelování požadavků se týkají zejména Pre CASE, Upper CASE a Middle CASE fází. Zahrnují čtyři etapy:

1. Sběr požadavků

Popis rozsahu IS a jeho vize
Definice tříd uživatelů (stakeholders) a jejich klíčová osoba
Use Case pro typické uživatele
Workshop, sledování uživatelů při práci
Systémové události a odpovědi na ně

2. Analýza požadavků

Kontextový diagram (DFD 0. úrovně)
Prototyp GUI
Analýza proveditelnosti a prioritizace požadavků
Modelování: ERD, STD, DFD, class diagram, mapa dialogů, sekvenční diagramy, rozhodovací tabulky
Vytvoření datového slovníku (Data Dictionary)
Rozdělení požadavků do subsystémů

3. Specifikace požadavků

Psaní požadavků dle šablony
Nalezení zdrojů požadavků, jejich ID
Zápis pravidla, popis kvalitativních parametrů (výkon, efektivita, spolehlivost, použitelnost)

4. Kontrola požadavků

Revize specifikace
Testování požadavků (verifikace + validace)

Způsob zachycení požadavků:

Strukturovaný text (specifikace)
Grafické zobrazení: UML use case diagram, scénáře, kontextový diagram

Kategorizace požadavků: Funkční (co systém dělá) × Nefunkční (jak dobře to dělá – výkon, bezpečnost, spolehlivost; mají zásadní dopad na návrh architektury)

💡 Příklad z praxe – Reverse Engineering:

Zdědíme starý systém bez dokumentace. CASE nástroj (Enterprise Architect) načte zdrojový kód nebo strukturu databáze a automaticky z ní vygeneruje class diagram nebo ER diagram. Tím zjistíme, jak systém funguje, aniž bychom museli číst tisíce řádků kódu.

⚠️ Časté záludnosti

❌ MDD ≠ automatické generování celé aplikace. CASE nástroj vygeneruje kostru (skeleton) kódu, ale business logiku musí programátor doplnit.

❌ PSM může být více pro různé platformy – jeden logický PIM model → Oracle PSM + PostgreSQL PSM + Java PSM. Transformace PIM→PSM je klíčový krok MDD.

❌ Lower CASE ≠ vývojové prostředí (IDE). Funkce se překrývají, ale IDE je obecnější nástroj. Lower CASE je zaměřen na podporu konkrétní metodiky vývoje.

❌ Reverse engineering není jen generování diagramů – zahrnuje i kontrolu konzistence mezi kódem a modelem (round-trip engineering).

❌ MetaEdit+ ≠ běžný CASE nástroj – MetaEdit+ je nástroj pro metamodelování, tj. pro tvorbu vlastních CASE nástrojů a jazyk DSL. Je výjimečný tím, že programátor může definovat vlastní diagramové notace.

❌ PowerDesigner vs. Enterprise Architect – PowerDesigner je zaměřen především na datové modelování (ER, PDM, generování DDL). Enterprise Architect je komplexnější a pokrývá celý životní cyklus IS včetně UML, BPMN, ArchiMate.

❌ Sběr požadavků ≠ analýza požadavků – Sběr = získání informací od stakeholderů. Analýza = zpracování, modelování, prioritizace a kontrola konzistence požadavků. Obojí je nutné pro úspěšný projekt.

🧩 Laicky

CASE nástroj je jako CAD software pro architekty. Místo tužky a papíru kreslíš dům v počítači – a software ti rovnou zkontroluje, zda zeď nezasahuje do základů, vygeneruje výkaz materiálu a 3D vizualizaci. MDD je jako skládání LEGO podle návodu: nejprve kresba (konceptuální), pak popis dílků (logický PIM), pak fyzické skládání konkrétní sady (PSM pro danou platformu).

🎓 Napojení na DP

PIS · 8

Vývoj přístupů k analýze a modelování procesů, historický kontext, různé techniky, diagramy a notace, standardizace.

📋 Historický vývoj analýzy a modelování procesů

Technika modelování procesů se vyvíjela od jednoduchých grafů (50. léta) přes formální síťové metody (60.–70. léta) až po dnešní standardizované notace (BPMN, UML).

📅 50. léta – Ganttovy diagramy (vizualizace časového průběhu projektů)

📅 60.–70. léta – PERT a CPM (síťové metody pro plánování projektů); DFD (diagramy toku dat)

📅 80. léta – Strukturované programování (Dijkstra), první CASE nástroje, začátky BPMN předchůdců

📅 1997 – UML 1.0 jako de facto standard objektového modelování (sloučení Booch, OMT, OOSE)

📅 2004+ – BPMN jako de facto standard procesního modelování (OMG)

📅 Dnes – Process Mining (dolování procesů z dat systémů), AI-asistované modelování

Standardizace: BPMN a UML spravuje OMG (Object Management Group). ISO 9001 zahrnuje požadavky na modelování procesů pro řízení jakosti.

📊 Ganttův diagram

Vizualizace plánu projektu v čase.

📏 Horizontální osa = čas

📋 Vertikální osa = úkoly/fáze

▬ Bloky = délka trvání úkolu

🔗 Závislosti mezi úkoly (šipky)

Jednoduchý, srozumitelný pro management. Nevhodný pro složité závislosti a rizika.

🔀 PERT vs CPM

PERT (Program Evaluation and Review Technique):

📊 Stochastická – bere v úvahu nejistotu časových odhadů

3 odhady: optimistický (O), pesimistický (P), nejpravděpodobnější (M)

Vzorec: E = (O + 4M + P) / 6

AOA (Activity on Arrow) notace

CPM (Critical Path Method = Metoda kritické cesty):

📏 Deterministická – pevné odhady časů

🔍 Hledá kritickou cestu = nejdelší sekvenci závislých úkolů

Zpoždění na kritické cestě = zpoždění celého projektu

📊 DFD a ER diagram

DFD (Data Flow Diagram):

🔄 Reprezentuje toky dat procesu (ne řídící tok)

👥 Vhodný i pro netechnické publikum (analytici, zákazník)

⚠️ Dnes méně vhodný pro real-time systémy

ER diagram:

🗄️ Modelování datových vztahů v IS

📦 Entity + Atributy + Vztahy (kardinalita)

🏗️ Základ pro relační databáze (normalizace)

🏆 BPMN – De facto standard

BPMN (Business Process Model and Notation) = grafická notace pro modelování podnikových procesů. Standard OMG od 2004, verze BPMN 2.0.2 od 2014. ISO norma.

Výhoda oproti DFD/UML: přehledná pro management i IT, standardizovaná, bohatá na prvky (události, brány, bazény, plavecké dráhy), spustitelná sémantika v BPMN 2.0.

💡 Příklad z praxe – stavba domu:

Gantt: Na ose x je čas (týdny), na ose y jsou úkoly (základy, zdi, střecha, elektrika). CPM: Kritická cesta = základy → zdi → střecha (nesmí se zpozdit). Elektrika může čekat. PERT: Kopání základů – optimisticky 2 týdny, pesimisticky 6 týdnů (možné problémy se zeminou), nejpravděpodobnější 3 týdny → E = (2 + 4×3 + 6)/6 = 3,33 týdne.

⚠️ Časté záludnosti

❌ PERT ≠ CPM. PERT je stochastická (pracuje s pravděpodobnostmi a třemi odhady), CPM je deterministická (pevné časy, zaměřená na kritickou cestu).

❌ Kritická cesta ≠ nejkratší cesta. Je to NEJDELŠÍ cesta závislých úkolů – zpoždění na ní způsobuje zpoždění celého projektu.

❌ DFD nemá žádný řídicí tok ani podmínky – pouze zobrazuje, kudy tečou data. Není to flowchart ani BPMN.

❌ BPMN 2.0 ≠ BPMN 1.0. Verze 2.0 přidala spustitelnou sémantiku – diagramy lze přímo procesním engine spustit (Camunda, Activiti).

🧩 Laicky

Gantt je jako rozvrh ve škole – na tabuli jsou hodiny a předměty v čase. CPM je jako vaření nedělního oběda: polévka trvá 45 min, pečeně 2 hod – kritická cesta je pečeně, polévku mohu začít kdykoli. PERT je jako cestování Prahou: „optimisticky 20 min (žádné kolony), pesimisticky 90 min (zácpa), nejspíše 40 min."

🎓 Napojení na DP

PIS · 9

Modelování procesů s využitím Unified Modeling Language (UML), diagramy, výhody a nevýhody.

📋 UML jako nástroj procesního modelování

Proces = série akcí vedoucí ke konkrétnímu výsledku; soubor činností, které transformují vstupy na výstupy hodnotné pro zákazníka.

Procesní modelování = znázornění procesu ve formě grafického modelu pro lepší přehlednost, srozumitelnost, identifikaci, optimalizaci a simulaci.

UML není primárně navržen pro procesní modelování, ale má diagramy, které se pro to hodí:

⚡ Diagram aktivit – hlavní nástroj pro procesní modelování v UML

👤 Use Case diagram (okrajově – vnější pohled na systém)

🔄 Stavový diagram (okrajově – životní cyklus objektu)

Oproti BPMN je UML obecnější – BPMN je specializovaný přímo na business procesy s bohatší sadou prvků.

⚡ Diagram aktivit pro procesní modelování

Prvky diagramu aktivit:

▶️ Počáteční uzel = start procesu (plný kruh)

📦 Aktivita = dílčí krok procesu

🔷 Rozhodovací uzel (kosočtverec) = větvení na základě podmínky (guard)

⚡ Fork (čára s více výstupy) = rozdělení do paralelních větví

⚡ Join (čára s více vstupy) = sloučení paralelních větví (čeká na všechny)

🏊 Swimlane/Lane = pruh s aktérem nebo oddělením (zodpovědnost)

⏹️ Koncový uzel (tučný kruh)

Možnosti modelování:

➡️ Sekvenční aktivity (jedna za druhou)

🔀 Paralelní aktivity (Fork/Join)

🔷 Podmíněné větvení (guard conditions)

🔄 Cykly/Smyčky (zpětné hrany)

📤 Vstupní a výstupní tokové hrany (control flow)

📬 Objektové toky (předávání objektů/dat mezi aktivitami)

✅ Výhody UML pro procesní modelování

✅ Zlepšení porozumění procesům a vztahům v týmu

✅ Zjednodušení komunikace se zákazníkem

✅ Lepší plánování SW projektů (podklad pro odhad pracnosti)

✅ Zvýšení kvality a snížení nákladů (chyby odhaleny v modelu, ne v kódu)

✅ Konzistence a jednotnost při vývoji (standardizovaná notace)

❌ Nevýhody UML pro procesní modelování

❌ Náročné na čas a odbornost (nutná znalost UML notace)

❌ Méně specializovaný než BPMN pro business procesy

❌ UML neumí nativně modelovat komunikaci mezi organizacemi (BPMN má bazény)

❌ Možnost chybné interpretace diagramu bez přesné specifikace

❌ Diagramy mohou zastarat, pokud nejsou aktualizovány s kódem

💡 Příklad – proces zpracování objednávky (diagram aktivit):

Zákazník odešle objednávku → [Fork: paralelně] → Skladník zkontroluje dostupnost || Účetní ověří platbu → [Join: obě dokončeny] → Expedice připraví balíček → Zásilka odeslána → Zákazník obdrží potvrzení.

Lane „Zákazník": Odeslat objednávku, Obdržet potvrzení. Lane „Sklad": Zkontrolovat dostupnost, Připravit balíček. Lane „Účetní": Ověřit platbu.

⚠️ Časté záludnosti

❌ Diagram aktivit ≠ vývojový diagram. Diagram aktivit podporuje objektové toky a paralelismus pomocí Fork/Join. Klasický vývojový diagram (flowchart) to neumí.

❌ Fork ≠ rozhodovací uzel. Fork = VŠECHNY větve probíhají PARALELNĚ. Rozhodovací uzel = vybere se JEDNA větev na základě podmínky.

❌ UML diagram aktivit a BPMN nejsou ekvivalentní – BPMN má bohatší sadu prvků (events, message flows, pools, různé typy bran).

🧩 Laicky

Diagram aktivit je jako výrobní linka v továrně nakreslená na papíře: zde se frézuje, pak se souběžně lakuje a testuje, pak se skládá. Swimlane = každý pracovník má svůj pruh pásového dopravníku. Fork = přijde zásilka a paralelně ji eviduje sklad i účetní. Join = teprve až oba potvrdí, zásilka se pošle dál.

🎓 Napojení na DP

PIS · 10

Modelování procesů s využitím Business Process Model and Notation (BPMN), specifikace, submodely, typy diagramů, základní a rozšířené kategorie elementů v diagramech.

📋 Co je BPMN?

BPMN (Business Process Model and Notation) = grafická notace pro modelování podnikových procesů. De facto standard, ratifikovaný jako ISO norma. Spravuje jej OMG (Object Management Group). Verze BPMN 2.0 platí od 2014.

Výhoda: jasná vizualizace procesů srozumitelná pro všechny úrovně organizace (od CEO po vývojáře). Přesná pravidla pro tvorbu diagramů. BPMN 2.0 přidalo spustitelnou sémantiku – modely lze přímo nasadit do procesního engine.

3 základní submodely BPMN:

🏭 Orchestrace – chování procesu UVNITŘ jedné organizace (interní pohled, jedno bazén)

💬 Choreografie – vzájemná komunikace MEZI účastníky (zaměřena na výměnu zpráv)

🤝 Kolaborace – detailní popis úloh VÍCE účastníků (více bazénů s interními procesy)

🧱 Základní elementy BPMN

1. Tokové objekty (průchod procesem):

📦 Aktivity (obdélník se zakulacenými rohy) = úkol v procesu; piktogram v levém horním rohu upřesňuje typ (User Task, Service Task, Script Task…)

⭕ Události (kruh) – Začátek (tenká čára) / Konec (tlustá čára) / Mezilehlé (dvojitá čára)

🔷 Brány (kosočtverec) – Exkluzivní XOR (jedna větev), Paralelní AND (všechny), Inkluzivní OR (jedna nebo více)

2. Data: datové objekty, vstupy, výstupy, sklady (Data Store)

3. Spojovací objekty:

➡️ Sekvenční tok (plná šipka) = logická návaznost UVNITŘ bazénu

✉️ Tok zpráv (přerušovaná šipka) = komunikace MEZI bazény

🔗 Asociace (tečkovaná) = spojení s artefakty (poznámky, data)

4. Bazény a plavecké dráhy:

🏊 Bazén (Pool) = účastník procesu (firma, systém)

🏊‍ Plavecká dráha (Lane) = sub-účastník v rámci bazénu (oddělení, role)

5. Artefakty: komentáře, skupiny, datové objekty

📋 Typy BPMN diagramů

🔒 Soukromý proces – jeden aktér, jeho interní průběh (orchestrace)

🌐 Veřejný proces – jak různí aktéři interagují s veřejným procesem

💬 Choreografie – interakce a vztahy mezi účastníky (komunikace v popředí)

📬 Konverzace – výměna zpráv mezi účastníky (vysokoúrovňový pohled)

🤝 Spolupráce – vztahy a interakce více účastníků s detailními procesy

Rozšířené kategorie elementů:

🔄 Různé typy bran (inkluzivní OR, událostní, složená)

🔁 Větvení a smyčky (loop, multi-instance)

⚡ Různé typy událostí (zpráva, časovač, chyba, signál, eskalace, kompenzace)

📦 Sub-procesy (collapsed/expanded), Call Activity

💡 Příklad – proces přijímání objednávky:

Bazén „Zákazník": Odeslat objednávku → [tok zpráv] → Bazén „E-shop": Přijmout objednávku → [XOR brána: skladem?] → Ano: Vystavit fakturu → Odeslat → [tok zpráv] → Zákazník: Obdržet zásilku → Konec. Ne: Informovat zákazníka o nedostupnosti → Konec.

⚠️ Časté záludnosti

❌ Sekvenční tok ≠ tok zpráv. Sekvenční tok je UVNITŘ jednoho bazénu. Tok zpráv jde MEZI bazény (mezi organizacemi/systémy).

❌ Exkluzivní brána XOR ≠ paralelní brána AND. XOR = vybere se JEDNA větev. AND = probíhají VŠECHNY větve souběžně.

❌ Choreografie ≠ Kolaborace. Choreografie se zaměřuje na KOMUNIKACI (kdo komu co posílá). Kolaborace na DETAILNÍ POPIS ÚLOH (co každý účastník uvnitř dělá).

❌ BPMN 2.0 přidalo spustitelnou sémantiku – diagramy mohou být přímo vykonány procesním engine (Camunda, Bizagi). Starší BPMN 1.x bylo jen vizualizační.

🧩 Laicky

BPMN je jako detailní plán výroby v továrně. Bazén = oddělení (sklad, výroba, účtárna). Plavecká dráha = konkrétní pracovník v oddělení. Událost = zvoní telefon (začátek). Brána XOR = „je zboží na skladě? Ano → balí. Ne → objednej." Tok zpráv = faktura poslaná zákazníkovi. Artefakt = poznámka přilepená k úkolu.

🎓 Napojení na DP

PIS · 11

Decision Model and Notation (DMN), hlavní části, využití v procesním modelování, vztah k BPMN.

📋 Co je DMN?

DMN (Decision Model and Notation) = standardizovaná notace pro modelování a specifikaci rozhodovacích pravidel a logiky. Standard OMG. Umožňuje přesně popsat, jak se v procesu dělají rozhodnutí, nezávisle na platformě.

DMN se hodí, když rozhodnutí závisí na kombinaci podmínek (např. schválení úvěru závisí na věku, příjmu, historii plateb).

Hlavní části DMN:

📥 Vstupy = datové prvky (číslo, text, objekt, datum)

📤 Výstupy = konkrétní hodnoty nebo výsledky rozhodnutí

📋 Podmínky = výroky/pravidla určující, za jakých okolností se co provede

📊 Rozhodovací tabulky (Decision Table) = sada pravidel: řádek = jeden případ, sloupce = podmínky a výsledky

🔣 FEEL (Friendly Enough Expression Language = dostatečně přívětivý výrazový jazyk) = jazyk pro složitější výrazy v DMN (podmínky, funkce, filtry)

Vztah DMN a BPMN: BPMN popisuje TOK práce (co se dělá), DMN popisuje LOGIKU ROZHODNUTÍ (jak se rozhoduje). Propojení přes „Decision Task" v BPMN – speciální typ aktivity, která volá DMN model.

📊 Rozhodovací tabulka (Decision Table)

Nejčastější způsob záznamu rozhodovací logiky v DMN. Každý řádek = jedno pravidlo, všechny podmínky v řádku musí platit najednou.

Věk	Příjem	Výsledek
< 18	libovolný	Zamítnout
18–65	< 20 000	Posoudit
18–65	>= 20 000	Schválit
> 65	libovolný	Posoudit

Hit Policy: U (Unique) = max 1 pravidlo platí; F (First) = první platné; A (Any) = všechna platná dávají stejný výsledek; C (Collect) = sbírá výsledky všech

🔗 Vztah k BPMN

DMN a BPMN se doplňují:

🏭 BPMN = co se DĚLÁ (tok aktivit, kdo co vykonává)

🧠 DMN = jak se ROZHODUJE (která pravidla platí pro konkrétní vstup)

V BPMN diagramu je Decision Task (obdélník se symbolem tabulky) = volání DMN modelu. Rozhodovací tabulky a pravidla z DMN mohou být vstupem pro modelování procesů v BPMN.

Příklad: BPMN proces „Zpracuj žádost o úvěr" → Decision Task „Vyhodnoť bonitu" → DMN tabulka vrátí „Schválit/Zamítnout" → BPMN pokračuje dle výsledku (XOR brána).

💡 Příklad z praxe – e-commerce slevový systém:

DMN rozhodovací tabulka: Zákazník VIP + objednávka > 5 000 Kč → sleva 20%. Zákazník VIP + objednávka ≤ 5 000 Kč → sleva 10%. Zákazník Standard → sleva 0%. Tato tabulka se volá z BPMN procesu „Vyřiď objednávku" jako Decision Task. Business analytik může měnit pravidla v DMN bez nutnosti upravovat BPMN model nebo kód.

⚠️ Časté záludnosti

❌ DMN ≠ BPMN. DMN = rozhodovací logika (co se rozhodne). BPMN = tok procesů (jak se postupuje). Jsou komplementární, ne zaměnitelné.

❌ Decision Table ≠ if-else v kódu. Tabulka je deklarativní (říká co, ne jak). Je čitelnější pro business analytiky bez znalosti programování.

❌ FEEL není programovací jazyk – je to výrazový jazyk pro podmínky v DMN (podmínky, funkce, filtry). Nelze v něm psát procedurální logiku.

❌ Rozhodovací pravidla mohou být nejednoznačná – DMN umožňuje definovat prioritu pravidel (Hit Policy). Bez správné hit policy může být výsledek nedefinovaný.

🧩 Laicky

Pojišťovna zpracovává škodní událost. BPMN popisuje krok po kroku: zákazník podá hlášení → úředník zaeviduje → rozhodne se o výplatě → zákazník dostane peníze. DMN je tabulka v tomto procesu: „Jak vysoká je škoda? Kdo zavinil? Jaké je pojistné krytí?" → DMN tabulka vrátí: „Vyplatit 15 000 Kč." BPMN = šéfkuchař organizuje kuchyni. DMN = recept říkající, kolik soli dát.

🎓 Napojení na DP

PIS · 12

Softwarové nástroje podporující BPMN, simulace procesů, optimalizace procesů.

📋 SW nástroje pro BPMN, simulace a optimalizace procesů

Softwarové nástroje pro BPMN umožňují vytvářet, vizualizovat, simulovat, automatizovat a optimalizovat podnikové procesy. Každý nástroj má jiné zaměření – od jednoduchého kreslení po plnohodnotné procesní engine.

Simulace procesů = virtuální spuštění procesu s testovacími daty pro odhalení úzkých míst, optimalizaci zdrojů a ověření funkčnosti před nasazením do produkce.

Optimalizace procesů = cílem je snížit plýtvání časem a zdroji, eliminovat úzká místa a chyby. Postup: Identifikuj → Zmapuj → Implementuj změny → Kontroluj výsledky.

🛠️ Softwarové nástroje pro BPMN

Nástroj	Typ	Hlavní využití
DrawIO / Diagrams.net	Zdarma, online	Jednoduché BPMN diagramy, rychlé prototypy
Bizagi	Freemium	Kreslení + automatizace + simulace + reporty
Camunda	Open-source	Procesní engine: automatizace, řízení úkolů, DMN
Signavio	Komerční	Vizualizace, simulace, monitorování výkonu

⚙️ Optimalizace procesů – postup

1. Identifikuj potřeby a procesy

🔍 Jaký je účel procesu? Kde začíná a končí? Kdo je zapojen?

2. Zmapuj a přehodnoť

🗺️ Existuje lepší způsob? Kde se proces zastavuje (úzká místa)? Kolik času zabere každý krok?

3. Implementuj změny

🚀 Přijmout nový proces → Kontrola výsledků → Při neúspěchu začít znovu (iterace)

🔬 Simulace procesů

Simulace umožňuje spustit BPMN proces virtuálně s nastavenými parametry (časy aktivit, počty zdrojů, pravděpodobnosti větvení) a sledovat:

⏱️ Průměrné časy průchodu procesem (throughput time)

🚧 Úzká místa (bottleneck = krok, který zdržuje vše ostatní)

👷 Vytížení zdrojů (kdo je přetížen, kdo nevyužit?)

💰 Náklady na průchod procesem (activity-based costing)

Petriho sítě jsou matematickým základem pro formální simulaci procesů – poskytují exaktní sémantiku tokenů.

💡 Příklad z praxe – optimalizace schvalovacího procesu faktury:

Původní proces: Faktura → Sekretářka → Účetní → Vedoucí oddělení → Finanční ředitel → Zaplaceno. Simulace odhalila: Vedoucí oddělení zpracovává 80 faktur/den a je úzké místo (průměrné čekání 3 dny). Optimalizace: Faktury do 10 000 Kč schvaluje přímo účetní (bez vedoucího). Výsledek: průměrná doba zpracování klesla z 5 na 2 dny.

⚠️ Časté záludnosti

❌ DrawIO ≠ procesní engine. DrawIO jen kreslí diagramy. Camunda nebo Bizagi diagramy i SPOUŠTĚJÍ (workflow engine spravuje instance procesů).

❌ Simulace ≠ automatizace. Simulace testuje proces virtuálně s testovacími daty. Automatizace ho skutečně spouští s reálnými daty a uživateli.

❌ Optimalizace neznamená vždy zrychlení – někdy je cílem snížení chyb, nákladů nebo zvýšení spokojenosti zákazníků. KPI musí být definováno předem.

🧩 Laicky

BPMN nástroje jsou jako GPS navigace pro procesy. DrawIO = vytisknutá mapa (vidíš, ale nic jiného nedělá). Bizagi = GPS co navrhne trasu. Camunda = autonomní auto co trasu samo projede. Simulace procesů je jako zkoušení recepce na hotelu pomocí figurín – zjistíš, kde se tvoří fronty, aniž bys obtěžoval skutečné hosty. Optimalizace je pak přidání dalšího recepčního přesně tam, kde je největší fronta.

🎓 Napojení na DP

PIS · 13

Petriho sítě a jejich využití v procesním modelování.

📋 Co jsou Petriho sítě?

Petriho sítě (Carl Adam Petri, 1962) = matematický model pro popis paralelních a distribuovaných systémů. Nabízejí nejen grafické znázornění, ale i formální matematický aparát užitečný pro implementaci a ověřování procesů.

Jsou vhodné pro procesy s nedeterministickým chováním (není předem jasné, co nastane), pro analýzu bezpečnosti a životaschopnosti systémů. Rozšiřují možnosti modelování konečných automatů.

Čtyři základní prvky:

⭕ Místa (places) – kolečka; reprezentují různé stavy procesu

▬ Přechody (transitions) – obdélníky; reprezentují změny v systému (události, akce)

➡️ Hrany (arcs) – orientované; spojují místa a přechody (NIKDY dvě místa nebo dva přechody navzájem!)

🔴 Tokeny/Značení (tokens/marking) – černé tečky v místech; aktuální stav sítě

+ Inhibiční hrany = od místa k přechodu; přechod NELZE odpálit, pokud je v místě token (negace podmínky)

🔥 Pravidla odpálení přechodu (Firing)

Přechod je uschopněn (enabled) pokud:

🔹 V každém vstupním místě je alespoň jeden token

🔹 Žádná inhibiční hrana nevede z místa s tokenem do přechodu

Odpálení (firing) přechodu:

1️⃣ Zkontroluj podmínky (inhibiční hrany)

2️⃣ Pokud uschopněn: odeber tokeny ze vstupních míst

3️⃣ Vlož tokeny do výstupních míst

Jeden krok = provedení jednoho povoleného přechodu (nedeterministický výběr při více povolených).

✅ / ❌ Výhody a nevýhody

Výhody:

✅ Jednoduchost a srozumitelnost základní notace

✅ Schopnost modelovat složité toky dat a řízení

✅ Formální analýza (bezpečnost, živost, dosažitelnost)

✅ Schopnost vizualizovat chování procesu (animace tokenů)

✅ Vhodný pro paralelní a nedeterministické systémy

Nevýhody:

❌ Tvorba a úpravy jsou složité u větších systémů (stavový prostor exploduje)

❌ Omezená schopnost modelovat datový obsah zpráv

❌ Přísně formální – méně čitelný pro business analytiky

🔍 Analýza vlastností sítě

🔒 Bezpečnost (Safety)

Síť je bezpečná (1-safe), pokud v každém místě je nejvýše 1 token. Zabraňuje přetečení (overflow).

💚 Živost (Liveness)

Přechod je živý, pokud může vždy znovu nastat (z libovolného dosažitelného stavu). Neexistuje uváznutí (deadlock).

🔄 Dosažitelnost (Reachability)

Z výchozího značení M₀ lze dosáhnout určitého cílového značení Mₙ. Základ pro verifikaci správnosti.

💡 Příklad – Producent a konzument:

Místo M1 = „buffer prázdný", M2 = „buffer plný". Přechod T1 (Producent produkuje): vstup M1, výstup M2. Přechod T2 (Konzument konzumuje): vstup M2, výstup M1. Iniciální stav: token v M1. Producent odpálí → token v M2. Konzument odpálí → token zpět v M1. Systém cyklí – modeluje synchronizaci producent-konzument bez deadlocku.

⚠️ Časté záludnosti

❌ Hrany nesmí spojovat dvě místa nebo dva přechody navzájem – vždy místo↔přechod. Petriho síť je bipartitní graf.

❌ Inhibiční hrana ≠ normální hrana. Inhibiční hrana ZAKAZUJE přechod (pokud je v místě token). Normální hrana UMOŽŇUJE (přechod potřebuje token).

❌ Petriho sítě nejsou totéž jako BPMN – jsou formálnější a matematicky ověřitelné (state space analysis), ale hůře čitelné pro business.

❌ Deadlock ≠ livelock. Deadlock = žádný přechod nelze odpálit. Livelock = přechody se střídají, ale systém nepostupuje k cílovému stavu.

🧩 Laicky

Petriho síť je jako tabulka s červenými žetony. Místa jsou sloupce (stavy jako „čeká", „zpracovává", „hotovo"). Přechod je jako pravidlo „pokud jsou v sloupcích A a B žetony, přesuň je do C." Tokeny jsou žetony – přemísťují se při každém pravidle. Inhibiční hrana = pravidlo „přesuň C do D, ale POUZE pokud v E nejsou žetony".

🎓 Napojení na DP

PIS · 14

Podnikové informační systémy a jejich integrace v podniku. Tradiční architektura informačního systému versus architektura ERP systému.

📋 Data, informace, IS a ERP

Data = fakta, čísla, texty – mohou a nemusí mít strukturu. Strukturovaná data = relační databáze (pole → záznam → relace). Nestrukturovaná data = video, audio, texty bez přesné struktury.

Informace = zpracovaná data s významem. Mají velký vliv na rozhodování v podniku; jejich manipulace ovlivňuje konkurenceschopnost.

IS (Informační systém) = soubor lidí, technických prostředků a metod pro sběr, přenos, uchovávání a zpracování dat za účelem tvorby a prezentace informací uživatelům.

ERP (Enterprise Resource Planning = Plánování podnikových zdrojů) = integrovaný IS poskytující jednotnou platformu pro řízení všech funkcí podniku – od skladu přes finance po HR a marketing. Sdílená databáze eliminuje datová sila.

🏭 ERP moduly

💰 Financování a účetnictví (hlavní kniha, pohledávky, výkaznictví)

👥 HRM – Human Resource Management (řízení lidských zdrojů, payroll)

📦 SCM – Supply Chain Management (řízení dodavatelského řetězce)

🤝 CRM – Customer Relationship Management (řízení vztahů se zákazníky)

🔩 SRM – Supplier Relationship Management (řízení dodavatelských vztahů)

🔄 PLM – Product Lifecycle Management (řízení životního cyklu produktu)

🏗️ Výroba (MRP/MRP II), sklad, logistika

📊 Tradiční vs ERP architektura

Vlastnost	Tradiční	ERP
Struktura	Oddělené aplikace (datová sila)	Integrovaná platforma
Data	Duplikovaná, nekonzistentní	Sdílená, konzistentní
Integrace	Obtížná, nákladná	Nativní
Reporting	Ruční konsolidace	Centralizovaný real-time
Flexibilita	Snadná výměna části	Změna je složitá

🔗 Integrace IS v podniku

📊 Datová integrace (ETL)

Kategorizace dat: kmenová (trvalá – zákazník, produkt), pohybová (transakce – objednávka), řídící (parametry, číselníky), dokumentace.

⚙️ Procesní integrace (BPMN)

Interní (výrobní procesy), externí (dodavatel, zákazník). Základní, podpůrné, řídící procesy. BPM engine orchestruje tok.

🔌 Metody integrace

Vertikální (zdola nahoru, přímá, rychlá ale pevná). Horizontální (ESB/API sběrnice, flexibilní, škálovatelná).

💡 Příklad z praxe – výrobní firma:

Tradiční přístup: sklad má vlastní systém, účtárna jiný, HR třetí. Zákazník vrátí výrobek → informace se ručně přepisuje do 3 systémů, chyby garantovány. ERP (SAP): zákazník vrátí výrobek → automaticky se aktualizuje sklad, vystaví dobropis v účtárně, zaznamená se do CRM. Jeden systém, jedno zadání, tři efekty.

⚠️ Časté záludnosti

❌ ERP ≠ databáze. ERP je celý systém s business logikou, procesy a integracemi. Databáze je jen technická součást uložení dat.

❌ CRM ≠ ERP. CRM řeší vztahy se zákazníky. ERP integruje celý podnik. CRM může být modul ERP (SAP CRM) nebo samostatný systém (Salesforce).

❌ Vertikální integrace ≠ lepší. Je rychlá, ale při změně jednoho systému je nutné vytvořit nová propojení. Horizontální (ESB/API) je flexibilnější a škálovatelnější.

❌ Implementace ERP není automaticky úspěch – bez správného nastavení procesů a change managementu je ERP drahý a nevyužitý systém.

🧩 Laicky

Tradiční IS je jako restaurace, kde si sál, kuchyně a pokladna vedou každý vlastní papírový seznam – a večer se to ručně srovnává. Chyby garantovány. ERP je jako modern restaurace: číšník zadá objednávku do tabletu → okamžitě se zobrazí v kuchyni, připíše se na účet a aktualizuje se sklad surovin. Jeden zápis, tři efekty.

🎓 Napojení na DP

PIS · 15

Typy informačních systémů. Globální a informační strategie podniku, kritické faktory úspěchu (CSF). Postup vytvoření informační strategie.

📋 Typy IS, globální strategie a CSF

Informační systémy lze dělit podle rozsahu/oblasti a podle úrovně řízení.

Obecné typy IS dle oblasti:

🏢 IS organizace – všechny informace pro všechny uživatele v celé firmě

📰 Zpravodajský/Redakční IS – informace jako komodita (mediální firmy, vědecké databáze, rozhlas)

🏛️ Státní IS – systémy pro veřejnou správu (e-government, datové schránky)

🏭 Podnikový IS – univerzální nebo pro specifické účely (ERP, CRM, SCM)

Typy IS dle úrovně řízení: TPS (transakce) → MIS (management) → DSS (rozhodování) → EIS (vrcholový management).

CSF = Critical Success Factors (Kritické faktory úspěchu) = klíčové oblasti, které musí být splněny pro dosažení cílů organizace. Dělí se na: kritéria řízení projektů, technického úspěchu a podnikového úspěchu.

🎯 Podniková vs. informační strategie

Podniková strategie = obecné cíle, rozsah a zaměření podnikání (kam firma chce dojít).

Informační strategie = součást podnikové strategie; přímý plán, jak globálních cílů dosáhnout pomocí IS/ICT. Říká: jaké informace potřebujeme, jaké systémy, jak propojené.

Přínosy informační strategie:

✅ Zabraňuje ztrátě času zbytečnými aktivitami

✅ Jednotnost informačních aktivit napříč organizací

✅ Podporuje spolupráci manažerů (shared vision)

✅ Předchází zbytečným nákladům na nekoordinované IT projekty

📋 Postup tvorby informační strategie

1️⃣ Formulace cílů, struktura, omezující podmínky

2️⃣ Analýza podnikových dokumentů (globální strategie, marketing, org. struktura)

3️⃣ Formulace CSF – jasně definované a měřitelné faktory úspěchu

4️⃣ Analýza současného stavu IS/ICT v organizaci (AS-IS)

5️⃣ Příprava rámcové architektury – moduly a vztahy (TO-BE)

6️⃣ Definice funkční struktury a datových zdrojů

7️⃣ Řešení klíčových, technických, personálních a ekonomických aspektů

8️⃣ Určení částí a fází realizace projektu (roadmapa)

⭐ Kritické faktory úspěchu (CSF)

🏗️ Technický úspěch

🔹 Systém funguje spolehlivě (dostupnost, výkon)

🔹 Bezpečnost a ochrana dat

🔹 Splněny nefunkční požadavky

📋 Úspěch řízení projektů

🔹 Projekt dokončen v čase a v rámci rozpočtu

🔹 Splňuje specifikované požadavky

🔹 Stakeholdeři jsou spokojeni

🏢 Podnikový úspěch

🔹 IS přináší obchodní hodnotu (ROI)

🔹 Uživatelé ho skutečně používají (adopce)

🔹 Podpora top managementu trvá

💡 Příklad z praxe – e-shop na oblečení:

Podniková strategie: Stát se jedničkou v online prodeji sportovního oblečení v ČR. Informační strategie: Implementovat ERP (sklad, fakturace), CRM (věrnostní program), B2C e-shop a BI systém (analýza prodejů). CSF: 99,9% dostupnost e-shopu, doba doručení max 2 dny, zákaznická spokojenost >4.5/5.

⚠️ Časté záludnosti

❌ Informační strategie ≠ IT strategie. Informační strategie řeší JAKÉ informace podnik potřebuje a jak je využije. IT strategie řeší JAKOU technologií to zajistit. Informační strategie musí být první.

❌ CSF nejsou cíle – jsou to podmínky, které musejí být splněny pro dosažení cílů. Cíl = „zvýšit tržby o 20%". CSF = „zákazníci musí být spokojeni s dodacími lhůtami."

❌ Informační strategie musí být SOUČÁSTÍ podnikové strategie, ne separátní dokument IT oddělení schovaný v šuplíku.

🧩 Laicky

Firma je jako výprava na Everest. Podniková strategie = cíl: vylézt na vrchol. Informační strategie = plán: jaké mapy potřebujeme, jaké komunikační vybavení, jak sdílet informace o počasí. CSF = podmínky úspěchu: správné vybavení (technický úspěch), zkušení průvodci (projektový úspěch), příznivé počasí (podnikový kontext). Bez splnění CSF ani nejlepší plán nestačí.

🎓 Napojení na DP

PIS · 16

Architektura informačních systémů – metody a frameworky, TOGAF.

📋 Architektura IS, metody a TOGAF

Architektura IS = celkový návrh a struktura informačního systému podniku. Zahrnuje business procesy, aplikace, data a technologie.

Klíčová terminologie:

🏢 Podniková architektura (EA) = daný systém je celý podnik (Enterprise Architecture)

👷 Architekt = osoba zodpovědná za návrh architektury

📄 Artefakt = specifický dokument, report, analýza nebo model

📁 Arch. popis = sbírka artefaktů popisující architekturu

🏗️ Arch. rámec = struktura definující, jaké artefakty jsou potřeba

🔄 Arch. proces = definovaná řada akcí směřující k vytvoření architektury

Zachmannův rámec = konceptuální model pro plánování IS; klade 6 otázek: Proč? Kdo? Co? Kde? Kdy? Jak? – každou z pohledu různých stakeholderů (Executive → Implementor). Zachmann = CO dokumentovat. TOGAF = JAK architekturu vytvořit.

🏛️ TOGAF (The Open Group Architecture Framework)

TOGAF = průmyslový standard pro vývoj a implementaci podnikové architektury. Sada metodik a průvodních procesů. Aktuálně verze 10 (2022).

4 domény TOGAF:

🏢 Business architektura – procesy pro splnění cílů podniku (strategie, organizace)

💻 Aplikační architektura – konkrétní aplikace a jejich spolupráce (rozhraní, integrace)

📊 Datová architektura – uspořádání a přístupnost dat (modely, CRUD matice, MDM)

⚙️ Technologická architektura – HW, SW infrastruktura, výkon, bezpečnost, cloud

ADM (Architecture Development Method) = iterativní proces TOGAF:

0️⃣ Přípravná fáze (Preliminary)

A. Vize architektury (Architecture Vision)

B. Business architektura

C. IS architektury (Data + Aplikace)

D. Technologická architektura

E. Možnosti a řešení

F. Migrační plánování

G. Řízení implementace

H. Správa architektury (Change Management)

+ Requirements Management (průřezová fáze)

🔷 MDA (Model Driven Architecture)

Metodika pro správu modelů IS. Oddělení návrhu a implementace. PIM (Platform Independent Model) → PSM (Platform Specific Model) → Kód. Zlepšuje opakovatelnost a flexibilitu portování na různé platformy.

🔌 SOA (Service Oriented Architecture)

Servisně orientovaná architektura. Návrh IS jako sady volně propojených služeb s definovanými rozhraními (WSDL, REST). Každá služba = samostatná funkčnost. Zlepšuje škálovatelnost a znovupoužitelnost komponent.

🔄 Agile metodiky v EA

Flexibilita, spolupráce a rychlost dodání. Iterativní přístup i k architektuře – architektura se vyvíjí spolu s projektem (Emergent Architecture). Lean Architecture, Architecture Runway v SAFe.

💡 Příklad z praxe – banka implementuje nový systém:

Zachmannův rámec: Proč? = Zlepšit zákaznický servis. Kdo? = Retail zákazníci + back-office. Co? = Nový mobilní banking. Kde? = ČR + SK. Kdy? = Q4 2025. Jak? = React Native app + microservices API. TOGAF ADM: nejprve Business architektura (nové procesy), pak Aplikační (mobilní app + napojení na ERP), pak Datová (CRUD matice), pak Technologická (cloud AWS, autentizace).

⚠️ Časté záludnosti

❌ TOGAF ≠ metodika vývoje SW. TOGAF je rámec pro architektonické plánování na úrovni podniku, ne pro vývoj konkrétních aplikací (Scrum, Kanban jsou pro to).

❌ SOA ≠ microservices. SOA je obecný přístup (větší, ucelené služby, SOAP/WSDL). Microservices jsou jemnozrnnější implementace SOA principů (REST, lightweight, container).

❌ Zachmannův rámec ≠ TOGAF. Zachmann = taxonomie (co dokumentovat, 6×6 matice). TOGAF = metodika (jak architekturu vytvořit, ADM proces).

❌ Datová architektura bez CRUD analýzy = neúplná. CRUD ukazuje, které funkce s jakými daty pracují a jakým způsobem – klíčový artefakt pro integraci systémů.

🧩 Laicky

Podniková architektura je jako masterplán města. Zachmann = sada otázek: Proč toto město existuje? Kdo tam bydlí? Co se tam vyrábí? Kde jsou silnice? Kdy se stavělo? Jak funguje doprava? TOGAF = stavební řád + postup, jak masterplán vytvořit. Business architektura = zónování. Datová architektura = vodovod a kanalizace. Technologická = elektrická síť. ADM = pořadí, v jakém se to vše plánuje.

🎓 Napojení na DP

PIS · 17

Business architektura – podnikové procesy a implementace požadavků na informační systémy, nástroje pro podporu analýzy.

📋 Co je Business architektura?

Business architektura (BA) = popis procesů, které podnik používá ke splnění svých cílů. Klíčová role: zajistit soulad mezi vizí podniku a vývojem organizace. BA je součástí TOGAF a je vstupem pro ostatní vrstvy (Aplikační, Datová, Technologická).

BA zahrnuje: procesy, organizační strukturu, lidi, informace, systémy a jejich vzájemné vazby.

Nástroje pro podporu analýzy BA = softwarová řešení pro kvalifikované rozhodování na základě podnikových dat. Příklady: PowerBI, OLAP kostky, dashboardy, Enterprise Architect.

📋 Postup implementace požadavků na IS v rámci BA

1️⃣ Výběr referenčních modelů, pohledů a nástrojů

🔹 Pokrytí pohledů: operativní, management, finanční

🔹 Stanovení granularity (detailu) požadavků – granularita = úroveň detailu; hrubá granularita = méně detailů, jemná = více detailů

2️⃣ Tvorba popisu výchozí BA (AS-IS)

🔹 Popis aktuálního stavu podniku (kontextový diagram)

🔹 Prvky a vazby mezi nimi

3️⃣ Tvorba popisu cílové architektury (TO-BE)

🔹 Kam chce podnik dospět

🔹 Vstup: výchozí architektura + globální strategie podniku

4️⃣ Analýza rozdílů (Gap Analysis)

🔹 Rozdíly mezi AS-IS a TO-BE architekturou

🔹 Ověření konzistentnosti modelů

🔹 Dokumentace změn a jejich dopadů

5️⃣ Definování komponent pro roadmapu

🔹 Plán a harmonogram přechodu na novou architekturu

🔹 Nastavení priorit (MoSCoW, quick wins vs. long-term)

6️⃣ Analýza očekávaných dopadů

🔹 Dopad na existující procesy a zaměstnance

🔹 Využitelnost poznatků v jiných oblastech podniku

7️⃣ Konzultace se zúčastněnými stranami

🔹 Formální ověření s vrcholovým managementem

🔹 Potvrzení správnosti řešení a finalizace (sign-off)

8️⃣ Vytvoření finální dokumentace

🔹 Podrobný záznam vývojového cyklu

🔹 Podklad pro práci na dalších vrstvách architektury

💡 Příklad z praxe – výrobní firma zavádí nový IS:

Výchozí BA (AS-IS): Sklad má papírové záznamy, výroba oddělený systém, účtárna Excel. Gap analýza: chybí propojení sklad–výroba, duplicitní zadávání dat, 3× přepis stejné informace. Cílová BA (TO-BE): ERP spojující sklad, výrobu a účtárnu na jedné platformě. Roadmapa: Q1 implementace ERP skladu, Q2 napojení výroby, Q3 migrace účtárny. Dopad: úspora 3 FTE na administrativě.

⚠️ Časté záludnosti

❌ Business architektura ≠ IT architektura. BA popisuje podnikové procesy a cíle. IT architektura popisuje technologické řešení. BA musí být navržena první.

❌ Gap analýza ≠ jen seznam problémů. Je to systematické porovnání: kde jsme teď (AS-IS), kde chceme být (TO-BE), co přesně chybí a co je třeba změnit.

❌ Granularita popisu závisí na tom, zda prvky budou zachovány. Prvky, které se změní nebo zaniknou, potřebují jemnější granularitu pro správnou analýzu dopadů.

❌ Roadmapa ≠ projektový plán. Roadmapa je strategický přehled priorit a milníků, ne operativní harmonogram s úkoly a osobami zodpovědnými.

🧩 Laicky

BA je jako renovace staré budovy. Nejprve zdokumentuješ stávající stav (kde jsou zdi, kde elektrika – AS-IS). Pak navrhneš cílový stav (otevřený plán, moderní kuchyň – TO-BE). Gap analýza říká: „Stará zeď musí pryč, elektrika nestačí." Roadmapa: Q1 bourání, Q2 elektrika, Q3 vybavení. Konzultace: zákazník potvrdí, že to tak chce, než se začne bourat.

🎓 Napojení na DP

PIS · 18

Datová architektura, postupy tvorby datové architektury, interakční analýza – CRUD analýza. Aplikační architektura, technologická architektura.

📋 Tři vrstvy architektury IS

Podle TOGAF se IS architektura dělí na datovou, aplikační a technologickou část. Každá vrstva popisuje jiný aspekt systému.

Datová architektura = jak jsou v podniku uspořádána a přístupná datová úložiště. Cíl: centralizovat data, vytvořit rámec pro komunikaci, umožnit flexibilní modulární návrh.

CRUD analýza = Create (Vytvoř) / Read (Čti) / Update (Aktualizuj) / Delete (Smaž). Matice mapující, které funkce systému pracují s jakými daty a jakým způsobem. Nástroj interakční analýzy – odhaluje vlastnictví dat, redundance a závislosti.

📊 Postup tvorby datové architektury

1️⃣ Vypracování popisu struktury základních vstupních dat

2️⃣ Přezkoumání referenčních modelů dat a pohledů (standardy odvětví)

3️⃣ Tvorba modelů: logický datový model + model procesů správy dat + CRUD matice

4️⃣ Formální přezkoumání se zúčastněnými stranami

5️⃣ Kontrola: bezpečnost, efektivita, rychlost, spolehlivost

6️⃣ Dokončení a dokumentace artefaktů

7️⃣ Analýza dopadů nové architektury na existující systémy

📋 CRUD matice

Tabulka: řádky = funkce/moduly systému, sloupce = datové entity. Odhalí: kdo s jakými daty manipuluje, jsou data redundantní, kde je vlastník dat.

Funkce / Data	Zákazník	Objednávka	Produkt
Registrace zákazníka	C	–	–
Zobrazení profilu	R	R	–
Vytvoření objednávky	R	C	R
Správa produktů	–	–	CUD
Zrušení objednávky	–	D	–

💻 Aplikační architektura

Popisuje konkrétní aplikace a jak spolu spolupracují. Hlavní role: integrovat aplikace do jednoho funkčního celku.

🎯 OO architektura – objektově orientovaná (Java EE, .NET)

🧩 Komponentová – moduly s definovanými rozhraními (COM, EJB)

🤖 Agentová – autonomní agenti komunikující zprávami

🔌 SOA – servisně orientovaná (volně vázané služby, WSDL/REST)

🔬 Microservices – jemnozrnnější SOA, container-native (Docker, Kubernetes)

⚙️ Technologická architektura

Popisuje HW a SW infrastrukturu podporující aplikace.

Aspekty: bezpečnost, výkon, přístupnost, velikost DB, objemy transakcí, šifrování, zotavení po havárii (DR), SLA.

Komponenty:

🖥️ DB server (HW, OS, DBMS = Database Management System = Systém řízení báze dat)

💻 Klientská aplikace (GUI, přívětivost, responzivita)

🌐 Prostředí (pracovní stanice, síť, firewall, load balancer)

🔗 Interakční analýza – rozšířené techniky

Kromě CRUD matice zahrnuje interakční analýza další tři techniky pro detailní pochopení vazeb mezi entitami, procesy a událostmi v IS:

📅 Entity Life Cycle Analysis (ELC)

Technika pro analýzu životního cyklu entit v systému – sleduje každou entitu od jejího vytvoření po její smazání.

Mapuje stavy entity a přechody mezi nimi (Create → Active → Archived → Deleted)
Umožňuje identifikovat kritické body životního cyklu, na které je třeba se zaměřit
Přímá vazba na stavové diagramy UML (State Machine Diagram)
Příklad: životní cyklus objednávky: Nová → Potvrzená → Zaplacená → Expedovaná → Doručená → Uzavřená (nebo Stornovaná)

Výstup: stavový diagram entity; slouží jako vstup pro návrh workflow a DRP.

🔀 Process Dependency Diagram (PDD)

Diagram závislostí procesů = grafické zachycení vazeb a závislostí mezi procesy v systému.

Umožňuje identifikovat kritické procesy – ty, na kterých závisí ostatní
Zobrazuje pořadí spouštění procesů a jejich datové vstupy/výstupy
Pomáhá zlepšit vazby mezi procesy a odhalit nadbytečné závislosti
Příklad: Proces „Výpočet mezd" závisí na procesech „Správa docházky" a „Správa zaměstnanců" – oba musí být ukončeny dříve než mzdy

Výstup: síťový diagram procesů; využívá se pro analýzu kritické cesty a plánování výpadků.

⚡ Event Analysis (Analýza událostí)

Technika pro analýzu událostí v systému a jejich vlivu na procesy a entity.

Identifikuje klíčové události, které spouštějí procesy nebo mění stav entit
Rozlišuje typy událostí: časové (každý den ve 23:00), stavové (platba přijata), podmíněné (zásoba pod minimum)
Umožňuje posílit odolnost systému vůči chybám a výpadkům
Příklad: Událost „Pokles zásoby pod 10 ks" → spustí proces „Generuj objednávku u dodavatele"

Výstup: katalog systémových událostí; základ pro event-driven architecture (EDA) a BPMN mezilehlé události.

Technika	Zaměření	Výstup	Vztah k UML/BPMN
CRUD analýza	Funkce × datové entity	CRUD matice	Class diagram, ER diagram
Entity Life Cycle Analysis	Stavy jedné entity v čase	Stavový diagram entity	State Machine Diagram (UML)
Process Dependency Diagram	Závislosti mezi procesy	Síťový diagram procesů	BPMN kolaborace, DFD
Event Analysis	Události a jejich dopady	Katalog událostí	BPMN mezilehlé události, EDA

💡 Příklad CRUD analýzy – HR systém:

Funkce „Přijmout zaměstnance" → C pro Zaměstnanec (vytvoří záznam), C pro Pracovní smlouva, R pro Oddělení (čte). Funkce „Výpočet mezd" → R pro Zaměstnanec, C pro Výplatní páska, U pro Bankovní účet. CRUD matice ukáže, že Zaměstnanec je klíčová entita dotýkající se 80% funkcí → nutné zajistit integritu a MDM (Master Data Management).

⚠️ Časté záludnosti

❌ CRUD ≠ jen pro databáze. CRUD analýza se dělá na úrovni funkcí a entit – odhaluje závislosti v systému bez ohledu na konkrétní implementaci.

❌ Datová architektura ≠ databázové schéma. Datová architektura je vyšší úroveň – řeší tok, správu a vlastnictví dat v celém podniku. DB schéma je fyzická implementace.

❌ SOA ≠ microservices. SOA = větší, ucelené služby (obchodní funkce). Microservices = velmi malé, nezávislé služby (technická funkce). Jiná granularita dekompozice.

❌ DBMS (Database Management System) ≠ databáze. DBMS je software pro správu databáze (Oracle, PostgreSQL, MySQL). Databáze jsou samotná uložená data.

🧩 Laicky

Datová architektura = plán archivu: kde jsou složky, kdo k nim má přístup, jak jsou pojmenovány. CRUD matice = kdo smí co se složkami: sekretářka může číst (R) a vytvářet (C), ale ne mazat (D). Ředitel může vše (CRUD). Aplikační architektura = popis kanceláří a jejich propojení. Technologická architektura = fyzická budova, elektrika, síť a zabezpečení.

🎓 Napojení na DP

PIS · 19

Systémová integrace a její typy, metody systémové integrace. CI/CD procesy – průběžná integrace a průběžné nasazování.

📋 Systémová integrace a CI/CD

Systémová integrace = proces spojování nezávislých IS nebo technologií tak, aby spolupracovaly jako jeden celek. Cíl: ulehčit výměnu informací a umožnit spolupráci v podniku.

CI/CD = Continuous Integration (průběžná integrace) / Continuous Delivery nebo Deployment (průběžné dodávání nebo nasazování). Praktiky DevOps pro rychlejší a bezpečnější vydávání SW.

Cíle CI/CD: zkrátit čas na trh (time-to-market), zlepšit kvalitu kódu, zefektivnit vývoj a spolupráci týmu. Automatizace = opakovatelnost + self-dokumentace. Manažeři vidí pokroky průběžně v dashboardu.

🔗 Typy systémové integrace

Typ	Princip	Vlastnosti
Vertikální	Integrace zdola nahoru (sila)	Rychlá implementace, ale při změně nutná nová integrace (point-to-point)
Horizontální	Jeden subsystém = sběrnice (ESB/API)	Flexibilní, škálovatelná (REST API, Webhook, WebSocket, Kafka)

Vertikální integrace:

Nástroje pro SI: Apache Kafka (streaming zpráv), Apache Camel (integrační framework), MuleSoft, IBM Integration Bus, Microsoft BizTalk, Oracle SOA Suite.

🔄 Continuous Integration (CI)

Průběžné slučování změn kódu do hlavní větve několikrát denně.

Proces:

1️⃣ Vývojáři pracují na vlastních větvích (feature branch)

2️⃣ Commitují změny a vytvoří Pull Request / Merge Request

3️⃣ CI server automaticky spustí build + testy (unit, integration)

4️⃣ Pokud projde → merge do main. Neprojde → oprav a opakuj.

Nástroje: Jenkins, GitHub Actions, GitLab CI, CircleCI

🚀 Continuous Delivery/Deployment (CD)

Automatické nasazení na testovací nebo produkční prostředí.

Delivery: Po CI → CD server sestaví a nasadí na staging → testy → manuální schválení → produkce.

Deployment: Plně automatické nasazení i na produkci (bez manuálního schválení).

Blue-Green deployment: Dvě identická prostředí (modrá = aktivní, zelená = nová verze). Přepnutí je okamžité → nulový downtime. Při problému přepnout zpět.

✅ Výhody CI/CD

⚡ Rychlejší iterace a opravy chyb (feedback loop v minutách)

🛡️ Nižší riziko – automatizované testy chrání produkci

👥 Lepší týmová spolupráce (konflikty odhaleny brzy)

💰 Nižší náklady díky automatizaci (méně manuální práce)

📊 Průběžná viditelnost pokroku pro management

🔁 Opakovatelné nasazení (infrastructure as code)

💡 Příklad CI/CD pipeline pro e-shop:

Vývojář pushne opravu chyby → GitHub Actions automaticky: 1) Spustí unit testy (500 testů, 2 min). 2) Integrační testy. 3) Sestaví Docker image. 4) Nasadí na staging. 5) Smoke testy. 6) Čeká na schválení QA. 7) Po schválení: Blue-Green deployment na produkci → přepne load balancer → stará verze zůstane jako záloha 24h → automatický rollback pokud chybovost >1%.

⚠️ Časté záludnosti

❌ CI ≠ CD. CI = integrace kódu (build, testy). CD = nasazení. CI je prerekvizita pro CD. Lze mít CI bez CD.

❌ Continuous Delivery ≠ Continuous Deployment. Delivery = připraveno k nasazení, ale vyžaduje manuální souhlas. Deployment = automatické nasazení na produkci bez lidského zásahu.

❌ Blue-Green ≠ A/B testování. Blue-Green = přepnutí celé aplikace najednou (infrastrukturní strategie). A/B = část uživatelů vidí verzi A, část verzi B (produktová strategie).

❌ ESB (Enterprise Service Bus = podniková servisní sběrnice) ≠ API gateway. ESB = komplexní integrační platforma s transformacemi a orchestrací. API gateway = vstupní bod pro API volání (autentizace, rate limiting).

🧩 Laicky

CI je jako sdílený Google Doc: každý přidá svou část a dokument se automaticky kontroluje na překlepy (testy). CD je jako tiskárna co se spustí sama, jakmile je dokument hotový. Blue-Green deployment je jako přepínání vlaku na paralelní kolej: vlak jede na modré koleji (verze 1), mezitím je připravena zelená (verze 2), výhybkář přepne → žádné zdržení pasažérů.

🎓 Napojení na DP

PIS · 20

Výběr systémového integrátora, softwarové nástroje pro systémovou integraci. Životní cyklus vývoje informačního systému, náklady IS (TCO). Outsourcing informačních systémů.

📋 Výběr integrátora, TCO a Outsourcing IS

Systémový integrátor = partner, který přebírá zodpovědnost za výsledné řešení IS projektu. Na větších projektech se podílí více dodavatelů (HW, SW, síť) – integrátor je „single point of contact" pro zákazníka a zodpovídá za výsledný celek.

TCO = Total Cost of Ownership (Celkové náklady vlastnictví) = všechny přímé i nepřímé náklady spojené s pořízením a provozem IS po celou dobu jeho životnosti. Nejen cena licence nebo hardwaru, ale i implementace, školení, podpora, opravy a upgrady.

Outsourcing IS = přenesení části nebo celé správy IS z organizace na externího poskytovatele. Cílem je snížit náklady, zvýšit flexibilitu a soustředit se na core business.

Životní cyklus vývoje IS (SDLC) = viz otázka 1 (Iniciace → Konstrukce → Dodání → Provoz).

🤝 Výběr systémového integrátora

💰 Nelpět na nejnižší ceně – integrace je nákladná a opravy špatné integrace mohou několikanásobně převýšit ušetřenou sumu

🤝 Hledat dlouhodobého partnera – ne jen dodavatele jednoho projektu

🧠 Posoudit pochopení business procesů – nejen technické parametry a reference

📋 Zkontrolovat reference – zejména z podobného odvětví a velikosti projektu

🔧 SW nástroje pro SI: Apache Kafka, MuleSoft, IBM Integration Bus, Microsoft BizTalk, Oracle SOA, Azure Integration Services

💰 TCO – Celkové náklady vlastnictví

🖥️ CAPEX (pořizovací náklady) – HW, SW licence, infrastruktura, implementace

⚙️ Implementační náklady – konfigurace, migrace dat, customizace, testování

👨‍🎓 Školení – uživatelé, správci, change management

🔧 OPEX (provozní náklady) – podpora, údržba, upgrady, hosting

🔄 Náklady na změnu procesů – reorganizace, ztracená produktivita při přechodu

Model	TCO aspekty
On-premise	Vysoký CAPEX (HW), nižší OPEX (vlastní IT tým)
SaaS	Nízký CAPEX, pravidelné měsíční poplatky (OPEX)
PaaS/IaaS	Platba za využití, škálovatelné OPEX

🌐 Outsourcing IS

✅ Výhody outsourcingu:

💰 Snížení nákladů – levnější než interní tým (úspory ze škálování)

🧠 Přístup k expertíze specialistů bez interního náboru

⚡ Zvýšení flexibility – rychlá reakce na změny poptávky

🛡️ Snížení rizik – lepší bezpečnost, záložní plány, SLA

🎯 Soustředění na core business (IT není core pro většinu firem)

❌ Rizika outsourcingu:

🔒 Ztráta kontroly nad vlastním řešením a daty

🤝 Závislost na dodavateli (vendor lock-in)

🔐 Bezpečnostní rizika (citlivá data u třetí strany)

📋 Nutnost pečlivé smluvní dokumentace (SLA = Service Level Agreement)

💬 Komunikační bariéry (offshore outsourcing do jiné kultury/časového pásma)

💡 Příklad z praxe – volba modelu pro středně velkou firmu:

Firma 100 zaměstnanců zvažuje ERP. On-premise SAP: TCO 5 let = 8 mil Kč (server 1M + licence 3M + implementace 2M + IT tým 2M). SaaS SAP Business One: TCO 5 let = 5 mil Kč (žádný HW, měsíční poplatek 80K × 60 měsíců). Rozhodnutí: SaaS + outsourcing správy = úspora 3M Kč a IT tým se může věnovat core businessu (digitalizaci obchodu).

⚠️ Časté záludnosti

❌ TCO ≠ pořizovací cena. Systém za 100 000 Kč s ročními náklady 200 000 Kč je po 5 letech dražší (1,1M) než systém za 500 000 Kč s ročními 50 000 Kč (750K). TCO = celý horizont životnosti.

❌ Outsourcing ≠ vzdání se kontroly. Správně nastavená SLA (Service Level Agreement = smlouva o úrovni služeb) definuje přesné parametry výkonu, bezpečnosti a dostupnosti.

❌ Vendor lock-in = závislost na jednom dodavateli. Při výběru SW zvažuj, jak snadná je migrace na jiný systém (přenositelnost dat, otevřené formáty, API).

❌ SaaS ≠ vždy levnější. Pro velké organizace s prediktabilním zatížením může být on-premise po 5+ letech výhodnější. Cloud vyhrává při variabilním zatížení a malém CAPEX budgetu.

🧩 Laicky

TCO je jako skutečná cena auta. Sticker price (pořizovací cena) = jen cena auta u dealera. Ale ještě zaplatíš: pojištění, benzín, servis, dálniční známky, pneumatiky, garáž. TCO = všechno dohromady za 5 let. Kupuješ-li Tesla místo Škody, CAPEX je vyšší, ale OPEX (benzín → elektřina, méně servisu) může být nižší. Break-even point řekne, kdy se Tesla „zaplatí". Outsourcing = přenechat auto půjčovně a platit jen za kilometry.

🎓 Napojení na DP

IT · 1

Architektura výpočetního systému, princip činnosti počítače, uložení dat v počítači, komponenty výpočetního systému, trendy v oblasti technického vybavení, virtualizace.

🏛️ Von Neumannova architektura (1945)

Model navržený Johnem von Neumannem – základ naprosté většiny dnešních počítačů. Pět klíčových částí:

ALU (Arithmetic Logic Unit = aritmeticko-logická jednotka) – provádí výpočty a logické operace
Řadič (Control Unit) – řídí ostatní části řídicími signály a přijímá stavová hlášení
Operační paměť – uchovává zpracovávaný program i jeho data ve STEJNÉ paměti (klíčový princip!)
Vstupní zařízení – klávesnice, myš, skener, mikrofon
Výstupní zařízení – monitor, tiskárna, reproduktory

Omezení: Von Neumannovo úzké hrdlo (bottleneck) – procesor nemůže číst instrukci a zároveň data, sdílená sběrnice je úzkým místem.

🔬 Harvardská architektura (1949)

Fyzicky odděluje paměť programu (instrukce) a paměť dat do dvou samostatných úložišť s vlastními sběrnicemi. Procesor může číst instrukce a data současně paralelně → výkonnostní výhoda.

Typické nasazení:

MCU (Microcontroller Unit = mikrokontrolér integrovaný na jednom čipu) – Arduino, PIC, AVR
DSP (Digital Signal Processor = procesor digitálního signálu) – audio/video zpracování
IoT (Internet of Things = internet věcí) čipy, embedded systémy (vestavěné systémy)

Modifikovaná harvardská architektura (Modern Harvard) – kombinace: oddělené cache (mezipaměti), ale společná hlavní RAM. Používají ji moderní CPU (x86, ARM).

💾 Uložení dat v počítači

Hierarchie: Data → Informace → Znalosti

Základní jednotky:

Bit – nejmenší jednotka (hodnota 0 nebo 1)
Nibble – 4 bity (jedna hexadecimální = šestnáctková číslice)
Byte – 8 bitů, nejmenší adresovatelná jednotka
KB (kilobyte) = 1 024 B; MB = 1 024 KB; GB = 1 024 MB; TB = 1 024 GB

Data jsou ukládána binárně (dvojková soustava). Každé paměťové místo má unikátní adresu. Typy paměti: RAM (Random Access Memory – rychlá, volatilní = ztrácí obsah po vypnutí), ROM (Read Only Memory – stálá), HDD (Hard Disk Drive – magnetické plotny), SSD (Solid State Drive – flash paměť, rychlejší).

🖥️ Komponenty výpočetního systému

Hardware (HW) – fyzické součásti:

Základní deska (motherboard) – propojuje vše přes sběrnice (bus)
CPU (Central Processing Unit) – obsahuje řadič, ALU, cache
RAM – operační paměť, dočasné uložení běžících programů
GPU (Graphics Processing Unit) – grafická karta, výpočty pro obraz i AI
HDD/SSD – trvalé úložiště, I/O zařízení, napájení (PSU)

Software (SW) – programy:

Firmware – BIOS (Basic Input/Output System) nebo UEFI (Unified Extensible Firmware Interface) – spouštěn při startu
OS (operační systém) s GUI (Graphical User Interface)
Aplikační SW – kancelářské balíky, prohlížeče, hry

☁️ Virtualizace

Virtualizace = soubor technik umožňujících přistupovat ke zdrojům jiným způsobem, než fyzicky existují. Klíčový prvek: hypervisor (software/firmware spravující virtuální stroje).

Typy virtualizace:

Plná virtualizace – kompletní emulace HW, VM (Virtual Machine = virtuální stroj) nerozezná virtuální od fyzického (VMware ESXi, Microsoft Hyper-V)
Paravirtualizace – hostovaný OS je upraven pro spolupráci s hypervisorem (Xen)
OS-level / kontejnery – jádro OS sdíleno, izolované prostory (Docker, LXC, Kubernetes)
Desktopová virtualizace – VDI (Virtual Desktop Infrastructure), DaaS (Desktop as a Service)

Výhody: jeden výkonný server nahradí více fyzických strojů, snadný přesun VM, záloha celého stavu, úspora nákladů a energie.

📈 Trendy v HW

Moorův zákon – počet tranzistorů na čipu se každé 2 roky zdvojnásobí (stále platí, ale zpomaluje)
Vícejádrové CPU (multi-core) – více výpočetních jader na jednom čipu pro paralelismus
GPU computing – masivní paralelní výpočty (AI, strojové učení, kryptoměny)
ARM architektura – nízká spotřeba, dominantní v mobilních zařízeních a IoT (Apple M-série, Raspberry Pi)
NVMe SSD – přes PCIe sběrnici, rychlosti přes 7 GB/s
Kvantové počítače – qubity (kvantové bity), superpozice a provázanost, přelomová výpočetní síla
Neuromorphic computing – čipy inspirované mozkem (Intel Loihi)

🏛️ Von Neumann vs. Harvardská architektura

Von Neumann vs. Harvardská architektura
Vlastnost	Von Neumann	Harvard
Paměť programu a dat	Společná	Oddělená
Sběrnice	Jedna sdílená	Dvě nezávislé
Paralelní přístup k ins. a datům	Ne	Ano
Hlavní použití	PC, servery, notebooky	MCU, DSP, IoT, embedded
Příklady	Intel x86, AMD Ryzen	Arduino AVR, ARM Cortex-M, PIC
Flexibilita	Vysoká (program lze měnit za chodu)	Nižší (oddělený program. prostor)

💡 Příklad z praxe: serverová virtualizace v datovém centru

Firma provozovala 20 fyzických serverů s průměrným vytížením 10–15 % – zbytek výkonu byl nevyužit. Nasazením VMware vSphere (hypervisor typu 1 – běží přímo na HW) všechny pracovní zátěže (workloady) konsolidovali na 4 výkonné fyzické servery. Vzniklo 20 VM (virtuálních strojů) s různými OS (Windows Server, Linux). Každou VM lze za chodu přesunout na jiný fyzický server (vMotion), zálohovat jako soubor a rychle obnovit po havárii. Výsledek: úspora 80 % fyzického HW, snížení spotřeby energie o 60 %, zkrácení doby nasazení nového serveru z týdnů na minuty.

⚠️ Časté záludnosti

❌ Von Neumann bottleneck – sdílená sběrnice pro instrukce i data je skutečné omezení, moderní CPU ho řeší cache (L1/L2/L3 mezipaměti) a prefetchingem (předčítáním).

❌ RAM ≠ úložiště – RAM je volatilní (data zmizí po vypnutí), HDD/SSD jsou non-volatilní. Záměna vede k nepochopení, proč po restartu zmizí neuložená práce.

❌ Hypervisor typ 1 vs. typ 2 – Typ 1 (bare-metal) běží přímo na HW (VMware ESXi, Hyper-V) = vyšší výkon. Typ 2 běží jako aplikace nad OS hostitele (VirtualBox, VMware Workstation) = jednodušší, nižší výkon.

❌ Kontejner ≠ VM – kontejner (Docker) sdílí jádro OS hostitele, je lehčí a rychlejší. VM emuluje celý HW včetně vlastního OS, je izolovanější ale těžší.

🧩 Laicky: kuchyně jako počítač

Von Neumann = kuchyňská linka, kde je recept (program) i suroviny (data) na stejném stole – kuchař musí střídavě koukat na recept a brát suroviny, nikdy obojí najednou. Harvard = dvě místnosti: v jedné je recept přilepený na zeď (ROM s programem), ve druhé jsou suroviny (RAM s daty) – kuchař (CPU) může číst recept a zároveň sahat po surovinách. Virtualizace je jako pronajímat jeden velký byt jako Airbnb – různí hosté (VM) si myslí, že mají celý byt pro sebe, ale ve skutečnosti sdílejí jednu budovu (fyzický server) řízenou správcem (hypervisorem).

🎓 Napojení na DP

IT · 2

Systémové programové vybavení: typy operačních systémů, jádro, zavaděč, ovladače, systémové programy, architektury OS, vývojové trendy.

⚙️ Co je operační systém a proč ho potřebujeme

Operační systém (OS – Operating System) je základní systémový software, který spravuje HW (hardware = fyzické součásti počítače) a poskytuje prostředí pro běh aplikačního softwaru. Bez OS by každá aplikace musela přímo komunikovat s HW – přidávat ovladače pro každý kus HW zvlášť.

Základní funkce OS:

Správa procesů – spouštění, plánování (scheduling) a ukončování procesů (process = běžící instance programu)
Správa paměti – alokace RAM mezi procesy, virtuální paměť (swap)
Správa úložiště – souborový systém (file system: NTFS, ext4, FAT32)
Správa I/O zařízení – ovladače (drivers), HAL (Hardware Abstraction Layer)
Zabezpečení a ochrana – uživatelská práva, izolace procesů
Uživatelské rozhraní – CLI (Command Line Interface) nebo GUI (Graphical User Interface)

🏗️ Typy jader OS (kernel architectures)

Jádro (kernel) = nejnižší vrstva OS, běží v privilegovaném režimu (ring 0), má přímý přístup k HW.

Monolitické jádro – celý OS v jednom bloku kódu v privilegovaném prostoru; rychlé, ale chyba v jednom modulu může shodit celý systém. Příklady: Linux, MS-DOS, starší Unix.
Mikrojádro (microkernel) – v privilegovaném prostoru jen minimum (správa paměti, IPC), vše ostatní (ovladače, souborový systém) běží v uživatelském prostoru jako servery; odolnější, ale pomalejší kvůli přepínání kontextu. Příklady: Mach, MINIX, QNX, L4.
Hybridní jádro – kompromis mezi monolitickým a mikrojádrem; ovladače v jádře, ale modulárně. Příklady: Windows NT, macOS (XNU).
Exokernel – ultra-minimalistické, aplikace spravují HW přímo; výzkumné účely.

🚀 Bootloader a spouštění systému

Bootloader = program, který po zapnutí počítače (POST – Power-On Self-Test = test HW při zapnutí) načte a spustí OS. Fáze spouštění:

BIOS/UEFI – firmware (BIOS = Basic Input/Output System; UEFI = Unified Extensible Firmware Interface, novější, podporuje GPT disky, Secure Boot)
MBR/GPT – Master Boot Record (starý, 32-bit, max 2TB disk) nebo GUID Partition Table (novější, 64-bit, 9,4 ZB)
Bootloader – GRUB (GRand Unified Bootloader – pro Linux, umí nabídnout výběr OS), Windows Boot Manager
Jádro OS – načtení do paměti, inicializace ovladačů, start init/systemd procesu

Secure Boot – UEFI funkce, která ověří digitální podpis bootloaderu před spuštěním (ochrana proti bootkitům).

🗂️ Typy operačních systémů

Desktopové OS – pro osobní počítače; Windows 11, macOS Sonoma, Ubuntu, Fedora
Serverové OS – Windows Server, Red Hat Enterprise Linux (RHEL), Ubuntu Server, FreeBSD
Mobilní OS – Android (jádro Linux, ARM), iOS (vrstvená arch., uzavřený ekosystém)
RTOS (Real-Time Operating System = OS reálného času) – deterministická odezva v mikro/milisekundách; FreeRTOS, VxWorks, QNX; pro průmyslové automaty, letadla, automobily
Embedded OS (vestavěné systémy) – minimální paměťové nároky; RTOS nebo stripped-down Linux
Distribuované OS – koordinace více počítačů jako jednoho systému; Amoeba, Plan 9
Síťový OS (NOS) – Windows Server, NetWare; správa sítí a sdílených zdrojů

📋 Správa procesů a plánování

Proces = běžící instance programu s vlastním adresovým prostorem, zásobníkem a systémovými prostředky. Vlákno (thread) = lehčí jednotka uvnitř procesu, sdílí paměť procesu.

Stavy procesu: Nový → Připravený → Běžící → Čekající → Ukončený

Plánovací algoritmy (CPU scheduling):

FCFS (First Come First Served) – pořadí příchodu, jednoduché
Round Robin – každý proces dostane časový kvant (time slice), pak se vystřídá
Priority scheduling – vyšší priorita = dřívější přístup k CPU
Preemptivní – OS může násilně přerušit běžící proces

📁 Souborové systémy a správa disku

Souborový systém (file system) organizuje data na úložišti do souborů a adresářů:

NTFS (New Technology File System) – Windows; žurnálování, ACL, šifrování EFS, max. 256 TB
ext4 – Linux; žurnálování, max. 1 EB (exabyte), fragmentace není problém
FAT32 – starý, kompatibilní; max. soubor 4 GB, max. disk 32 GB
exFAT – pro flash disky a SD karty, bez omezení FAT32
APFS (Apple File System) – macOS/iOS; šifrování, snapshoty
ZFS / Btrfs – pokročilé; copy-on-write, RAID, snapshoty, deduplikace

Žurnálování (journaling) – OS si zapisuje záznamy o chystaných změnách → obnovení po výpadku proudu.

🔧 Ovladače (Device Drivers)

Ovladač (driver) = software, který umožňuje OS komunikovat s konkrétním HW zařízením. Bez ovladače OS "neví", jak s daným zařízením pracovat.

Kernel-mode drivers – běží v privilegovaném prostoru (ring 0), přímý přístup k HW; grafické karty (GPU driver), síťové karty, řadiče disků
User-mode drivers – běží v uživatelském prostoru, menší riziko pádu systému; tiskárny, skenery, zvuková zařízení
HAL (Hardware Abstraction Layer) – vrstva oddělující OS od konkrétního HW; umožňuje přenositelnost OS

Plug and Play (PnP) – automatické rozpoznání a konfigurace HW zařízení po připojení. OS sám vyhledá a nainstaluje ovladač (z lokálního úložiště nebo Windows Update). Signed drivers – digitálně podepsané ovladače; Windows 10/11 vyžaduje podpis (ochrana integrity jádra).

Správa ovladačů: Device Manager (Windows), lsmod/modprobe (Linux kernel modules).

🛠️ Systémové programy

Systémové programy poskytují různé služby operačního systému a tvoří "výbavu" OS pro správu prostředků a uživatelskou interakci:

Správce souborů – umožňuje práci se soubory a adresáři: vytváření, kopírování, přesun, mazání, přejmenování; File Explorer (Windows), Nautilus (GNOME), ls/cp/mv
Správce procesů – řízení běhu procesů: spouštění nových procesů, ukončování, nastavení priority (nice); Task Manager (Windows), top/htop/ps (Linux)
Správce paměti – alokace a uvolňování paměti pro procesy a aplikace; správa stránkovacího souboru (swap), virtuální paměť
Správce sítě – konfigurace síťového připojení, DNS, protokolů; Network Manager (Windows/Linux), ifconfig/ip
Správce ovladačů – správa HW ovladačů: instalace, aktualizace, odinstalace; Device Manager, dmesg
Systémové služby – dlouho běžící procesy na pozadí: časovače, plánovač úloh (cron/Task Scheduler), zabezpečení (Windows Defender Service), syslog; UNIX démoni (daemon)

🖥️ Virtualizovaná architektura OS

Vedle monolitického, mikrojádra a hybridního jádra existuje virtualizovaná architektura:

Virtualizovaná architektura – operační systémy jsou virtualizovány a běží jako instance (VM – Virtual Machine) na hostitelském OS nebo přímo na HW. Umožňuje běh více OS na jednom fyzickém počítači.

Hypervisor (VMM – Virtual Machine Monitor) = SW vrstva zprostředkovávající virtualizaci:

Typ 1 (bare-metal) – běží přímo nad HW (bez hostitelského OS); VMware ESXi, Microsoft Hyper-V, KVM (Linux); vysoký výkon, pro datová centra
Typ 2 (hosted) – běží jako aplikace nad hostitelským OS; VirtualBox, VMware Workstation, Parallels Desktop; pro vývoj a testování

Kontejnerizace (Docker) = odlehčená virtualizace; nesdílí celý kernel jako VM, sdílí jádro hostitele → méně overhead; izolace na úrovni procesů.

📈 Vývojové trendy OS

Cloud-native operační systémy – navrženy pro efektivní běh v cloudu; minimalizovaná image (Alpine Linux, Container OS); integrace s Kubernetes a cloudovými službami
Virtualizace – běh více OS na jednom stroji; snížení nákladů na HW, zvýšení flexibility a využití zdrojů; kontejnerizace (Docker, Kubernetes) jako evoluce
Zabezpečení – narůstající kybernetické hrozby → nové technologie: Secure Boot, TPM (Trusted Platform Module), Kernel Control Flow Integrity (kCFI), Memory-safe OS komponenty (Rust)
Inteligentní OS – využití AI/ML: prediktivní správa zdrojů, anomaly detection, adaptivní plánování; Windows Copilot, AI-optimized schedulers
Mobilní OS – stále větší vývoj pro zařízení s omezeným výkonem a baterií; Android/iOS dominantní; Wear OS, watchOS pro wearables; IoT OS (FreeRTOS, Zephyr)

💡 Příklad z praxe: Linux server s více procesy

Webový server (Apache/Nginx) na Linuxu obsluhuje stovky HTTP požadavků současně. Každý požadavek může být obsluhován buď jako samostatný proces (Apache prefork model) nebo jako vlákno (Apache worker model). Linuxový plánovač CFS (Completely Fair Scheduler) přiděluje každému procesu spravedlivý podíl CPU. Pokud by paměť RAM nestačila, kernel aktivuje swap (odkládací oddíl na disku – pomalá, ale nouzová náhrada RAM). Administrátor sleduje procesy příkazem top nebo htop a může procesům nastavit prioritu (nice value -20 až +19).

⚠️ Časté záludnosti

❌ BIOS vs. UEFI – BIOS je 16-bitový firmware z 70. let, UEFI je jeho moderní 64-bitový nástupce s GUI, rychlejším startem a Secure Boot. Nové počítače mají UEFI, ale pro zpětnou kompatibilitu ho někdy nazývají "BIOS".

❌ Monolitické jádro ≠ špatné – Linux je monolitické jádro a je základem Androidu, serverů i superpočítačů. Modulární přístup (loadable kernel modules) mu dává dostatečnou flexibilitu.

❌ Proces ≠ vlákno – každý proces má vlastní paměťový prostor (crash jednoho procesu neohrozí jiný); vlákna sdílejí paměť procesu (vlákno musí synchronizovat přístup k datům, jinak nastane race condition).

❌ RTOS ≠ "rychlý OS" – RTOS garantuje deterministickou dobu odezvy (deadline), ne nutně maximální rychlost. Kritické je, že odpověď přijde vždy včas, ne co nejdříve.

🧩 Laicky: OS jako správce kanceláře

OS je jako správce kanceláře. Má klíče od všech místností (HW) a rozhoduje, kdo (proces) dostane přístup ke kopírce (CPU), tiskárně (I/O) nebo archívu (disk). Monolitické jádro je správce, který dělá vše sám – je rychlý, ale když dostane chřipku (chyba v kódu), zavře celou kancelář. Mikrojádro je správce, který deleguje každou činnost na speciálního asistenta – pokud jeden onemocní, ostatní fungují dál. GRUB/bootloader je noční hlídač, který ráno otevře kancelář a zkontroluje, jestli je vše v pořádku (POST), než vpustí zaměstnance (OS).

🎓 Napojení na DP

IT · 3

Informační systémy, architektury IS a jejich vývoj, architektura klient-server, SOA, cloud computing. Management IT: frameworky, normy a metodiky, ITIL, COBIT, IT Governance, virtuální týmy, specifika práce ve virtuálním prostředí.

📊 Informační systémy – základní pojmy

Informační systém (IS) = soubor lidí, nástrojů, dat a procesů, které sbírají, zpracovávají, ukládají a distribuují informace pro podporu rozhodování a řízení organizace.

Typy IS podle účelu:

ERP (Enterprise Resource Planning) – plánování podnikových zdrojů, integruje finanční, výrobní, personální procesy (SAP, Oracle ERP)
CRM (Customer Relationship Management) – správa vztahů se zákazníky (Salesforce, HubSpot)
SCM (Supply Chain Management) – řízení dodavatelského řetězce
BI (Business Intelligence) – analytické nástroje pro rozhodování (Tableau, Power BI)
DMS (Document Management System) – správa dokumentů

🏗️ Architektury IS – vrstvený přístup

1-vrstvá (monolitická) – vše na jednom místě (starý mainframe model); jednoduché, ale špatně škálovatelné
2-vrstvá (klient/server) – prezentace u klienta, data na serveru; tlustý klient (fat client) obsahuje část aplikační logiky
3-vrstvá – prezentační vrstva (UI), aplikační vrstva (business logika), datová vrstva (databáze); oddělení zodpovědností, nejrozšířenější model
N-vrstvá – více specializovaných vrstev (API gateway, microservices, message broker)

MVC (Model-View-Controller) – návrhový vzor: Model = data a business logika; View = zobrazení; Controller = zpracování požadavků a koordinace. Odděluje logiku od prezentace.

🔗 SOA a mikroslužby

SOA (Service-Oriented Architecture = architektura orientovaná na služby) – systém je rozložen do samostatných, interoperabilních (vzájemně komunikujících) webových služeb propojených přes standardizovaná rozhraní (SOAP, REST). Výhoda: znovupoužitelnost, integrabilita.

Mikroslužby (microservices) – evoluce SOA; každá funkce systému je samostatná malá služba s vlastní databází, nasazená nezávisle (Docker, Kubernetes). Výhoda: nezávislé nasazení, škálování jen části systému. Nevýhoda: složitější orchestrace (řízení).

API (Application Programming Interface = rozhraní pro programování aplikací) – definované rozhraní pro komunikaci mezi systémy. REST API (Representational State Transfer) používá HTTP metody GET/POST/PUT/DELETE.

☁️ Cloud Computing – modely služeb

IaaS (Infrastructure as a Service) – virtualizovaná infrastruktura; zákazník spravuje OS, middleware i aplikace. Příklady: AWS EC2, Azure Virtual Machines, Google Compute Engine
PaaS (Platform as a Service) – platforma pro vývoj aplikací; zákazník spravuje jen aplikaci. Příklady: Heroku, Google App Engine, Azure App Service
SaaS (Software as a Service) – hotová aplikace jako služba. Příklady: Microsoft 365, Google Workspace, Salesforce, Dropbox
FaaS/Serverless – platba jen za volání funkce (AWS Lambda, Azure Functions)

Typy nasazení: veřejný cloud (public – sdílená infrastruktura), privátní cloud (private – jen pro organizaci), hybridní (kombinace), multi-cloud (více poskytovatelů).

📋 IT Governance – ITIL a COBIT

IT Governance (IT řízení) = rámec pro strategické řízení IT, zajišťující soulad IT cílů s cíli organizace.

ITIL (Information Technology Infrastructure Library) – nejrozšířenější rámec pro správu IT služeb (ITSM = IT Service Management). Popisuje best practices pro:

Service Strategy (strategie služeb)
Service Design (návrh služeb)
Service Transition (přechod)
Service Operation (provoz) – incident management, problem management
Continual Service Improvement (CSI – neustálé zlepšování)

COBIT (Control Objectives for Information and Related Technologies) – rámec pro IT governance zaměřený na kontrolní cíle a audit.

🔐 ISO/IEC 27001 – bezpečnost IS

ISO/IEC 27001 = mezinárodní norma pro systémy řízení bezpečnosti informací (ISMS – Information Security Management System). Definuje požadavky na:

Identifikaci a hodnocení rizik
Výběr a implementaci bezpečnostních opatření (controls)
Pravidelné audity a přezkoumání
Neustálé zlepšování

SLA (Service Level Agreement = dohoda o úrovni služeb) – smlouva mezi poskytovatelem a zákazníkem definující: dostupnost (uptime, typicky 99,9 % = "three nines" = max 8,7 hodin výpadku/rok), reakční dobu na incidenty, dobu opravy (RTO – Recovery Time Objective), maximální ztrátu dat (RPO – Recovery Point Objective).

⚙️ ITIL – procesy Service Operation

ITIL popisuje doporučení pro kvalitu IT služeb – jedná se o kruh událostí: návrh služby → nasazení služby → provoz služby. Klíčové procesy:

Incident management – neplánované přerušení IT služby; cílem je co nejrychlejší obnova
Event management – monitorovací nástroje, detekce událostí, výstrahy služeb
Request fulfilment – vyřizování standardních požadavků uživatelů (nová hesla, SW instalace)
Access management – přiřazení a odebírání přístupových práv uživatelům
Problem management – řeší příčiny incidentů; Známá chyba = zdokumentovaný problém s možností náhradního řešení (workaround)
Service asset and configuration management – evidence IT aktiv a jejich konfigurací (CMDB)
Change management – při jakékoliv změně se změní i návazné systémy; kontrolovaný proces schvalování
IT service continuity management – obnova kritických služeb po vážném výpadku
Capacity management – zajištění dostupnosti služeb dle požadavků na kapacitu a výkon
Availability management – zajištění dostupnosti služeb dle SLA
Financial management for IT services – rozpočtování, účtování, zpoplatnění IT služeb

🎛️ COBIT – 4 domény

COBIT (Control Objectives for Information and Related Technologies) = soubor praktik pro dosažení strategických cílů organizace efektivním využitím IT zdrojů a minimalizací IT rizik. Definuje rozdělení IT do čtyř domén:

Plánování a organizace – IT strategie, architektura, standardy, řízení kvality a bezpečnosti
Akvizice a implementace – výběr a nasazení IT řešení, řízení změn, testování
Dodání a podpora – provozování služeb, správa výkonu, bezpečnosti a kontinuity
Monitorování a vyhodnocování – audit, kontrola plnění cílů, soulad s předpisy

💡 Nejpoužívanější frameworky IT Governance: COBIT, ITIL, ISO 27001 a ISO 38500.

👥 Virtuální týmy a specifika práce ve virtuálním prostředí

Virtuální týmy = týmy, kde členové pracují na různých místech pomocí virtuálních (digitálních) technologií. Umožňují organizacím najímat talentované lidi bez ohledu na fyzickou polohu.

Klíčové prvky úspěšné práce:

Společná vize a jasně definované cíle
Efektivní komunikace a spolupráce (Slack, Teams, Zoom)
Stanovení jasných očekávání (časy dostupnosti, odpovědnosti za úkoly, komunikační kanály)
Průběžné hodnocení výkonu týmu

Specifika a výzvy virtuálního prostředí:

Vzdálené, anonymní a méně formální prostředí → vyšší riziko konfliktů a neporozumění
Kulturní rozdíly a časové zóny členů → nutnost flexibility a respektu
Vyžaduje specifické dovednosti: komunikace, self-management, time management
Větší důraz na písemnou komunikaci a dokumentaci rozhodnutí
Motivace a angažovanost: pravidelné interakce, uznání úspěchů, team building

💡 Příklad z praxe: migrace ERP do cloudu (IaaS → SaaS)

Výrobní firma provozovala SAP ERP na vlastních serverech (on-premise). Upgrade na SAP S/4HANA probíhal ve dvou etapách: nejprve přesun na IaaS (virtuální stroje v Azure) – firma sama spravuje OS a databázi; poté přechod na SaaS model (SAP BTP – Business Technology Platform). Výsledek: IT oddělení přestalo řešit záplaty OS a HW výpadky, ITIL procesy (incident management, change management) zůstaly, ale operační náklady klesly o 35 %. SLA garance cloudu: 99,95 % dostupnost (max. 4,4 hodiny výpadku ročně).

⚠️ Časté záludnosti

❌ IaaS vs. PaaS – v IaaS zákazník instaluje a spravuje OS, middleware a databáze sám; v PaaS platformu (OS, runtime, databázi) spravuje poskytovatel. Záměna vede ke špatnému odhadu provozních nákladů.

❌ MVC ≠ 3-vrstvá architektura – 3-vrstvá je fyzická/logická architektura nasazení (kde co běží), MVC je návrhový vzor (jak je kód organizován). V praxi se kombinují: 3-vrstvá arch. s MVC frameworkem (Ruby on Rails, Django, Spring MVC).

❌ ITIL není metodika vývoje SW – ITIL řeší provoz IT služeb (operations), ne vývoj softwaru. Pro vývoj existují Agile, Scrum, DevOps.

❌ Mikroslužby nejsou vždy lepší – pro malé projekty přinášejí zbytečnou složitost (distributed systems complexity, network overhead). Monolith first, microservices later je rozumnější přístup.

🧩 Laicky: pizza jako IS architektura

Monolitická architektura = celá pizzerie v jednom lokále – kuchař, pokladní i rozvozce je táž osoba. Rychle to přestane stačit. 3-vrstvá = oddělená obsluha (UI), kuchyně (logika) a sklad surovin (databáze). MVC = šéfkuchař dostane objednávku (Controller), vytáhne recept z kartotéky (Model) a předá výsledek obsluze (View). Mikroslužby = řetězec fast foodů, kde každý dělá jen pizzu, jiný jen burgery, jiný jen saláty – každý může škálovat nezávisle. IaaS = pronájem prázdné kuchyně, PaaS = pronájem kuchyně s vybavením, SaaS = objednání hotové pizzy s dovozem – nestaráte se o nic.

🎓 Napojení na DP

IT · 4

Budování bezpečnosti IS v organizaci, jednotlivé kroky, postup, analýza rizik, bezpečnostní politika – celková, systémová, havarijní plán, bezpečnostní funkce.

🛡️ CIA triáda – základní bezpečnostní cíle

Bezpečnost informačních systémů stojí na třech pilířích (CIA triáda):

Confidentiality (Důvěrnost) – k informacím mají přístup jen oprávnění. Zajišťuje: šifrování, řízení přístupu (ACL), NDA (Non-Disclosure Agreement)
Integrity (Integrita) – data nejsou neoprávněně změněna. Zajišťuje: hashování (kontrolní součty), digitální podpisy, verzování
Availability (Dostupnost) – systém je dostupný oprávněným uživatelům. Zajišťuje: redundance, zálohy, UPS, DDoS ochrana, SLA

Rozšíření: Non-repudiation (nepopiratelnost) – uživatel nemůže popřít provedení akce (logy, digitální podpisy). Authenticity (autentičnost) – informace pochází od deklarovaného zdroje.

⚠️ Analýza rizik

Riziko = pravděpodobnost vzniku škody × dopad škody (Risk = Probability × Impact). Cílem není eliminovat veškerá rizika (to by bylo příliš nákladné), ale snížit je na přijatelnou úroveň (residual risk).

Základní pojmy:

Aktivum (asset) – co chráníme: data, HW, reputace, procesy
Hrozba (threat) – potenciální příčina škody: útočník, havárie HW, požár
Zranitelnost (vulnerability) – slabé místo, které může hrozba využít: neopravená chyba v SW (zero-day), slabé heslo
Dopad (impact) – výše škody při realizaci hrozby

Metody zpracování rizika: akceptace (přijmout), mitigace (snížit opatřeními), transfer (pojistit, outsourcovat), vyhnutí (eliminovat aktivitu).

📜 Bezpečnostní politiky

Bezpečnostní politika (BP) = dokument popisující, jak organizace chrání svá aktiva. Hierarchie:

Celková bezpečnostní politika (CBP) – strategický dokument, schvaluje top management; definuje cíle, odpovědnosti, principy
Systémová bezpečnostní politika (SBP) – technická pravidla pro konkrétní IS: hesla, zálohy, šifrování, přístupová práva
Havarijní plán (Disaster Recovery Plan, DRP) – postup obnovy po katastrofě; definuje RTO (Recovery Time Objective = čas do obnovení provozu) a RPO (Recovery Point Objective = maximální přijatelná ztráta dat)
BCP (Business Continuity Plan) – jak organizace funguje při výpadku IS

🔧 Bezpečnostní funkce a opatření

Firewall – filtruje síťový provoz podle pravidel (ACL)
IDS/IPS (Intrusion Detection/Prevention System) – detekuje/blokuje útoky
SIEM (Security Information and Event Management) – centrální sběr a analýza bezpečnostních událostí
DLP (Data Loss Prevention) – zabraňuje úniku citlivých dat
VPN (Virtual Private Network) – šifrovaný tunel přes veřejnou síť
WAF (Web Application Firewall) – chrání webové aplikace (SQL injection, XSS)
Šifrování dat – v klidu (at rest: šifrovaný disk) i při přenosu (in transit: TLS)
Zálohy – pravidlo 3-2-1: 3 kopie, 2 různá média, 1 off-site
Penetrační testy (pen-testing) – řízené etické hackování pro nalezení zranitelností

🎯 Typy bezpečnostních hrozeb a útoků

Síťové útoky:

DoS/DDoS (Denial of Service / Distributed DoS) – zahlcení serveru, znepřístupnění služby
MITM (Man-in-the-Middle) – odposlech a manipulace komunikace
Phishing – podvodné e-maily/weby pro získání přihlašovacích údajů
SQL injection – vložení škodlivého SQL kódu do formuláře
XSS (Cross-Site Scripting) – vložení škodlivého JS do webové stránky

Malware typy:

Virus – připojuje se k souborům, šíří se při jejich spuštění
Worm (červ) – šíří se sítí samostatně bez interakce uživatele
Trojan (trojský kůň) – maskuje se jako legitimní SW
Ransomware – zašifruje data a požaduje výkupné
Spyware – sleduje aktivitu uživatele
Rootkit – skrytý, získá administrátorský přístup
Botnet – síť napadených strojů ovládaných útočníkem

🔍 6-krokový postup analýzy rizik

Analýza rizik je nejdůležitější dokument týkající se tvorby bezpečnosti v organizaci. Má identifikovat a kvantifikovat rizika, jejich možné následky a náklady na odstranění. Postup sestává ze 6 kroků:

Identifikace a ocenění aktiv – co chráníme a jakou má to hodnotu (data, HW, SW, reputace, procesy)
Nalezení zranitelných míst – slabá místa, která mohou být zneužita (neopravené chyby, slabá hesla, fyzický přístup)
Odhad pravděpodobností využití zranitelných míst – jak pravděpodobné je, že daná hrozba zranitelnost skutečně využije

Výpočet očekávaných ztrát – dopad × pravděpodobnost → finanční vyjádření rizika
Přehled použitelných opatření a jejich cen – co lze udělat pro snížení rizika a za jakou cenu
Odhad ročních úspor zvolených opatření – náklady vs. přínosy zavedení opatření (ROI bezpečnostní investice)

Přístupy k tvorbě analýzy rizik:

Elementární – převzetí již vytvořených standardů na základě podobných systémů
Neformální – stanovení na základě vyjádření odborníků z oblasti bezpečnosti IS
Detailní – použití standardizovaných strukturovaných metod ve všech fázích analýzy
Kombinovaná – kombinace předchozích přístupů

🔒 Fyzická vs. logická bezpečnost

Základem budování bezpečnosti IS je bezpečnostní politika – určuje přístupy k datům, IS, proškolování a pravidla bezpečnosti na pracovišti. Bezpečnost dělíme na dvě oblasti:

Fyzická bezpečnost – fyzické bariéry, trezory, zámky, kamerové systémy, UPS (Uninterruptible Power Supply), ochrana před přírodními jevy, kontrola přístupu do server roomu; hrozby: vloupání, požár, povodeň, sabotáž
Logická bezpečnost – softwarová a síťová opatření: autentizace, autorizace, šifrování, firewally, IDS/IPS; hrozby: malware, hackeři, neautorizovaný přístup, sítové útoky

Hrozby na zhodnotitelných zdrojích: prozrazení tajných informací, porušení dat, zničení dat, bránění v dostupnosti/přístupu.

⚙️ Klasifikace bezpečnostních funkcí

Bezpečnostní funkce jsou samotnou realizací bezpečnostní politiky. Dělí se podle dvou hledisek:

Dle okamžiku uplatnění:

Preventivní – odstranění zranitelných míst dříve, než jsou zneužita (patch management, silná hesla, školení)
Heuristické – snížení rizika hrozby (behaviorální analýza, anomaly detection, sandboxing)
Detekční a opravné – minimalizace škod po útoku (IDS/SIEM detekce, zálohy a obnova, DRP)

Dle způsobu implementace:

SW opatření – autorizace, autentizace, kódování, antivirus, šifrování, firewall SW
HW opatření – stínění kabeláže, trezory, UPS, fyzické zámky, čtečky karet, bezpečnostní kamery
Administrativní opatření – školení zaměstnanců, vnitřní normy a vyhlášky, bezpečnostní politika, audity

💡 Příklad z praxe: ransomware útok na nemocnici

V roce 2020 byl ransomware útok (WannaCry a jeho varianty) příčinou kolapsu několika nemocnic. Útočník využil zranitelnost EternalBlue (zero-day v SMB protokolu Windows, odcizený NSA exploit), zašifroval všechny dostupné soubory v nemocniční síti. Nemocnice bez offline záloh (porušení pravidla 3-2-1) zaplatily výkupné nebo obnovily provoz ze zálohy po týdnech. Opatření: pravidelné záplaty (patch management), segmentace sítě (VLAN), offline zálohy, monitoring SIEM, školení zaměstnanců (lidský faktor = nejslabší článek). Správná analýza rizik by identifikovala hrozbu + zranitelnost a navrhla mitigaci.

⚠️ Časté záludnosti

❌ Bezpečnost ≠ antivirus – antivirus je jen jedna z mnoha vrstev obrany (defense in depth). Komplexní bezpečnost zahrnuje fyzickou bezpečnost, organizační opatření, školení lidí i technická řešení.

❌ RTO vs. RPO – RTO = za jak dlouho obnovíme provoz; RPO = jak stará data si můžeme dovolit ztratit (závisí na frekvenci záloh). Záměna způsobuje chybné plánování DR.

❌ Hrozba ≠ zranitelnost ≠ riziko – hrozba je potenciální útočník/incident, zranitelnost je slabé místo ve vašem systému, riziko je kombinace obojího s pravděpodobností a dopadem.

❌ DRP ≠ BCP – DRP řeší technickou obnovu IT systémů; BCP řeší, jak organizace funguje celkově při výpadku (náhradní pracoviště, klíčoví zaměstnanci, komunikace s klienty).

🧩 Laicky: zámky, pokladna a hasič

CIA triáda: Důvěrnost = zámek na trezoru (jen oprávnění mají klíč). Integrita = plomba na zásilce (víte, jestli ji někdo otevřel). Dostupnost = záložní generátor (obchod funguje i při výpadku proudu). Analýza rizik = pojišťovna, která hodnotí, co se může stát, jak pravděpodobné to je a jak moc to bolí – a pak navrhne, co pojistit. Havarijní plán = hasičský plán evakuace – nevíte, kdy hoří, ale víte přesně, kudy utéct a kdo zhasíná. Ransomware je jako únos, kde vám zloděj vezme klíče od domu a chce výkupné – ale pokud máte záložní klíč u souseda (offline záloha), smějete se mu do tváře.

🎓 Napojení na DP

IT · 5

Identifikace a autentizace: hesla, útoky, biometrické metody, čipové karty, aj. Ochrana proti virům, principy antivirů, chování uživatelů, sociální inženýrství.

🔑 Identifikace, autentizace, autorizace

Tři různé kroky kontroly přístupu – nesmí se zaměňovat:

Identifikace – Kdo jsi? Uživatel oznámí svoji identitu (zadá uživatelské jméno/login). Systém ještě neví, jestli to je pravda.
Autentizace (authentication) – Dokažeš, že jsi to ty? Ověření identity předložením důkazu. Tři faktory:
- Co znáš – heslo, PIN, bezpečnostní otázka
- Co vlastníš – fyzický token, OTP (One-Time Password), smart card, SMS kód
- Čím jsi – biometrika: otisk prstu, oční duhovka, hlas, obličej
Autorizace (authorization) – Co smíš dělat? Po ověření identity systém přidělí oprávnění (read/write/delete, role, ACL).

MFA (Multi-Factor Authentication) = kombinace 2+ faktorů → výrazně zvyšuje bezpečnost.

🔒 Metody autentizace

Hesla: nejrozšířenější, ale nejslabší faktor. Bezpečné heslo: min. 12 znaků, kombinace písmen/číslic/symbolů, unikátní pro každý účet. Hashování hesel: bcrypt, Argon2 (nikdy nešifrovat hesla, vždy hashovat!).

OTP (One-Time Password) – jednorázové heslo generované TOTP (Time-based OTP, RFC 6238) algoritmem – základ Google Authenticator, Microsoft Authenticator. Platnost 30 sekund.

Biometrika:

Fyziologická – otisk prstu (minutiae), oční duhovka, sítnice, DNA, tvar obličeje (3D)
Behaviorální – dynamika psaní na klávesnici, chůze, podpis
Výhody: nelze zapomenout, obtížné napodobit. Nevýhody: nelze změnit po úniku, FRR/FAR chyby

Smart card / čipová karta: kryptografický čip, soukromý klíč nikdy neopustí kartu – autentizace probíhá výpočtem uvnitř čipu (PKI, eIDAS, eObčanka).

SSO (Single Sign-On) – přihlásíte se jednou, přístup k více systémům (Kerberos, SAML, OAuth 2.0, OpenID Connect).

🦠 Malware – typy a charakteristiky

Typ	Charakteristika	Příklad
Virus	Připojí se k souboru, šíří se jeho spuštěním	ILOVEYOU, Melissa
Worm	Šíří se sítí samostatně, bez interakce	Conficker, WannaCry
Trojan	Maskuje se jako legit SW, otevře zadní vrátka	Emotet, Zeus
Ransomware	Zašifruje data, žádá výkupné	WannaCry, Ryuk, LockBit
Spyware	Sleduje aktivitu, krade data	Pegasus, FinFisher
Rootkit	Skrytý, admins. přístup, těžko detekovatelný	Sony BMG rootkit
Adware	Zobrazuje reklamy, méně škodlivý	Gator, BonziBuddy
Botnet	Síť ovládaných strojů (C2 server)	Mirai, Necurs

🛡️ Ochrana před malwarem

Technická opatření:

Antivirus / EDR (Endpoint Detection and Response) – signaturová + behaviorální detekce
Firewall – blokuje neoprávněný síťový provoz
Sandbox – spuštění podezřelého souboru v izolovaném prostředí
Patch management – pravidelné aktualizace OS a SW (záplaty zranitelností)
Princip nejmenších oprávnění (PoLP – Principle of Least Privilege) – uživatel má jen ta oprávnění, která nutně potřebuje
Segmentace sítě – VLAN, DMZ (demilitarizovaná zóna pro veřejné servery)

Organizační opatření:

Školení uživatelů – phishing awareness
Bezpečnostní politika hesel
Incident response plán

🦠 Principy fungování antivirů

Princip antiviru se zakládá na znalosti kódu virů (signatur) a analýze chování. Antivirus využívá on-access scanner – skenuje programy při jejich spuštění a při přenosech souborů. Tři základní techniky:

1. Sekvenční (vyhledávací) technika

Na základě určité sekvence instrukcí (signatury) lze vir jednoznačně specifikovat. Antivirus porovnává soubory s databází známých virových signatur.

✅ Rychlá, přesná pro známé viry

❌ Nedokáže detekovat nové (zero-day) viry

2. Emulační technika

Spustí program pod svou kontrolou a emuluje jeho chování v izolovaném prostředí (sandbox). Zjistí, zda je chování programu adekvátní, nebo podezřelé.

✅ Detekuje polymorfní a mutující viry

❌ Náročná na výkon procesoru

3. Kontrola integrity

Hlídá změny v systému, v adresářích nebo na disku (hashuje soubory a porovnává). Nenajde konkrétní vir, pouze odhalí neoprávněnou změnu v systému.

✅ Detekuje skryté a neznámé modifikace

❌ Neidentifikuje typ hrozby, jen změnu

💳 Typy čipových karet

Čipové karty jsou karty s integrovaným obvodem (čipem), který je schopen zpracovávat data. Nejčastěji slouží k digitální autentizaci. Dělí se na tři typy:

Memory Card

Naprogramovány výrobcem, levné. Vhodné pouze tam, kde není velký důraz na bezpečnost (věrnostní karty, telefonní karty).

Hard-Wired Card

Podobné Memory Card, ale přidává tajný kód (PIN), který je nutné zadat. Vyšší bezpečnost než Memory Card.

Microprocesor Card

Jsou schopné odhalit neoprávněný pokus o získání dat a smazat je (self-destruct). Lze je programovat dodatečně (ne jen při výrobě). Základ pro PKI karty a eID (eObčanka).

PKI karty = čipové karty se zašifrovaným digitálním certifikátem. Autentizace probíhá pomocí veřejného klíče. Digitální certifikát obsahuje: informace o uživateli, veřejný klíč, digitální podpis CA, datum vypršení.

👁️ Biometrika – markanty a etalon

Při registraci biometrické metody se sejmou tzv. markanty (charakteristické a významné příznaky biometrického rysu – například minutiae u otisku prstu: zakončení linií, větvení). Z markantů se vytvoří etalon (číselný vzor). Při přihlašování se nově načtený etalon srovnává s uloženým. Etalon se ukládá do databáze, čtecího zařízení nebo přenosného média.

Využívají se optické, kapacitní a tlakové senzory. Základní metriky přesnosti biometrie:

FRR (False Rejection Rate) – oprávněný uživatel je odmítnut → nepohodlí
FAR (False Acceptance Rate) – neoprávněná osoba je přijata → bezpečnostní riziko
EER (Equal Error Rate) – bod, kde FRR = FAR; nižší EER = lepší systém

⚔️ Útoky na hesla

Pasivní útoky (odposlech):

Sniffing (odposlech) – zachytávání síťové komunikace (nešifrované protokoly HTTP, FTP, Telnet); obrana: HTTPS, VPN, šifrování
Keylogger – HW nebo SW nástroj zaznamenávající stisky kláves; skryté sledování uživatele; obrana: antivirus, fyzická ochrana zařízení
Shoulder-surfing (pohled přes rameno) – fyzické sledování obrazovky nebo klávesnice; obrana: privacy screen, vědomost prostředí

Aktivní útoky:

Brute-force – systematické vyzkoušení všech možných kombinací znaků; obrana: zámek účtu po N pokusech, prodloužení doby mezi pokusy, CAPTCHA
Slovníkový útok – zkoušení slov ze slovníků nebo předdefinovaných seznamů; obrana: nepoužívat slovní hesla, salt+hash
Uhádnutí hesla – na základě znalosti uživatele (jméno, datum narození, RČ); obrana: nezahrnutí osobních údajů do hesla

Softwarové útoky:

Malware / zadní vrátka (backdoor) – škodlivý kód, který ukradne přihlašovací údaje nebo otevře vzdálený přístup; obrana: antivirus, aktualizace SW
Phishing – podvodné e-maily/weby napodobující legitimní služby; vylákání přihlašovacích údajů; obrana: MFA, vzdělávání uživatelů, anti-phishing filtry
Replay attack – odposlechnutá autentizační zpráva je přehrána znovu; obrana: nonce, timestamp, session tokens
Man-in-the-Middle (MitM) – útočník se vloží do komunikace; obrana: šifrování (HTTPS/TLS), certifikáty, VPN

Obecná obrana: zámek účtu, prodloužení doby mezi pokusy, vícefaktorová autentizace (MFA), HTTPS, monitorování neúspěšných přihlášení, silná a unikátní hesla.

👤 Chování uživatele a bezpečnostní hygieně

Lidský faktor je v současné době nejrizikovějším faktorem z hlediska bezpečnosti IS. V rámci každé organizace by uživatelé měli absolvovat školení bezpečnosti. Klíčová doporučení:

Volba kvalitního hesla – min. 12 znaků, kombinace písmen/číslic/symbolů, silné heslo nezahrnuje osobní údaje (jméno, RČ, datum narození)
Heslo si nikam nezapisovat ani neodesílat – ani IT podpoře, ani e-mailem; správce hesel (password manager) jako bezpečná alternativa
Citlivá data pravidelně zálohovat – pravidlo 3-2-1; ztracená data nelze obnovit
Pravidelně aktualizovat zabezpečení – antivirus (databáze i program), OS, primární systémové aplikace; záplaty uzavírají zranitelnosti
Neotvírat podezřelé e-maily a přílohy – podezřelou aktivitu okamžitě hlásit IT oddělení
Nepouštět ke svému počítači nedůvěryhodné osoby – fyzická bezpečnost je stejně důležitá jako logická
Nenavštěvovat podezřelé stránky – ověřovat HTTPS, správnost domény (typosquatting)
Uvědomělost o aktuálních hrozbách – pravidelná školení, phishing simulace; IT bezpečnostní povědomí (security awareness training)

🎭 Sociální inženýrství

Sociální inženýrství (social engineering) = psychologická manipulace lidí za účelem získání citlivých informací nebo přístupu do systémů. Na rozdíl od technických útoků útočí na lidský faktor, nikoliv na technologii.

Typický průběh útoku sociálního inženýrství (4 fáze):

Výběr oběti – útočník si vybere konkrétní osobu nebo organizaci (admin, účetní, CEO); high-value target s přístupem k citlivým datům
Sbírání informací (OSINT) – veřejně dostupné informace o oběti: LinkedIn, Facebook, firemní web, GitHub; zjištění struktury org., jmen nadřízených, pracovní e-mailové formáty
Příprava scénáře (Pretext) – vytvoření věrohodné legendy: IT technik, bankovní zaměstnanec, kolega z jiné pobočky; přizpůsobeno informacím z kroku 2
Provedení útoku – na základě spoofingového útoku (podvržené telefonní číslo, e-mailová adresa) útočník postupuje dle scénáře a získá přihlašovací údaje, přístupy nebo citlivá data

Formy sociálního inženýrství: Phishing (e-mail), Vishing (hlas/telefon), Smishing (SMS), Spear phishing (cílený na konkrétní osobu), Whaling (cílený na vrcholné manažery – CEO fraud), Pretexting, Baiting (USB stick s malwarem ponechán na parkovišti).

Obrana: vzdělávání a testování uživatelů, vícekanálové ověřování identity, "zero trust" přístup, hlášení podezřelých kontaktů.

💡 Příklad z praxe: phishing kampaň ve firmě

Útočník rozeslal 500 zaměstnancům e-mail imitující interní IT oddělení s výzvou "obnovte heslo k VPN". Odkaz vedl na falešnou přihlašovací stránku (typosquatting domény). 47 zaměstnanců zadalo přihlašovací údaje. IT security team to zachytil díky SIEM alertu na neobvyklé přihlášení z nových IP adres. Okamžitá reakce: reset hesel, zapnutí MFA pro všechny VPN účty, forenzní analýza. Poučení: samotné heslo nestačí – MFA by útok zastavilo i po prozrazení hesla. Následovalo povinné školení phishing awareness + simulované phishing testy.

⚠️ Časté záludnosti

❌ Autentizace ≠ autorizace – autentizace ověřuje identitu (jsi to ty?), autorizace přiděluje oprávnění (co smíš?). Lze být autentizován, ale neautorizován pro konkrétní akci.

❌ Šifrování hesel ≠ hashování hesel – hesla se NIKDY nešifrují (šifrování lze reverzovat), vždy se hashují jednosměrnou funkcí (bcrypt, Argon2). Úniku hashů sice nezabrání, ale útočník musí hesla brute-forcovat.

❌ Biometrika je neměnná – pokud uniknou vaše biometrická data, nemůžete si změnit otisk prstu jako heslo. Proto biometrika bývá kombinována s jiným faktorem (MFA).

❌ Antivirus nezachytí vše – zero-day exploity a fileless malware (běží jen v paměti) klasický AV nedetekuje. EDR řeší behaviorální analýzu a je efektivnější.

🧩 Laicky: noční klub jako bezpečnostní systém

Identifikace = u vstupu řeknete jméno. Autentizace = ukážete průkaz totožnosti (co vlastníte). Autorizace = vrátný zkontroluje seznam VIP hostů a rozhodne, jestli jdete do hlavního sálu nebo VIP sekce. MFA = průkaz + biometrická kontrola obličeje + kód z SMS. Virus = kamarád, který si na botě přinese bahno a všude ho zanechá; červ = bahno, které se šíří samo, pokud ho někdo šlápne; trojan = balíček označený jako "dárek", který uvnitř obsahuje bahno. Rootkit = úředník v clubu, který se skryje a přepíše bezpečnostní záznamy, takže ho kamery "nevidí".

🎓 Napojení na DP

IT · 6

Kryptografické mechanismy, metody a jejich funkce v bezpečnosti IS: rozdělení, hash funkce, digitální podpis, útoky.

🔐 Co je kryptografie a základní pojmy

Kryptografie (z řeckého kryptós = skrytý, graphein = psát) = věda o metodách ochrany informací před neoprávněným přístupem jejich matematickým přetvořením. Kryptoanalýza = věda o prolomení kryptografické ochrany.

Základní pojmy:

Plaintext (otevřený text) – původní, nechráněná zpráva
Ciphertext (šifrovaný text) – výsledek šifrování
Klíč (key) – tajná hodnota, která řídí šifrování/dešifrování
Šifrování (encryption) – převod plaintext → ciphertext
Dešifrování (decryption) – převod ciphertext → plaintext
Šifrovací algoritmus (cipher) – matematický postup transformace

Kerckhofsův princip: bezpečnost systému závisí pouze na tajnosti klíče, ne algoritmu. Algoritmus může být veřejný (a obvykle je – open source crypto je důvěryhodnější).

🔑 Symetrická kryptografie

Symetrická kryptografie = stejný klíč pro šifrování i dešifrování. Odesilatel i příjemce musí klíč sdílet bezpečným kanálem (key distribution problem).

Výhody: vysoká rychlost, malá výpočetní náročnost. Nevýhoda: problém distribuce klíče, n uživatelů = n(n-1)/2 klíčů.

Algoritmy:

DES (Data Encryption Standard, 1977) – 56-bitový klíč; dnes prolomitelný hrubou silou v hodinách – nepoužívat!
3DES (Triple DES) – DES aplikovaný 3× se dvěma/třemi klíči; bezpečnější, ale pomalý – dnes deprecated
AES (Advanced Encryption Standard, 2001) – klíče 128/192/256 bitů; bloková šifra (block cipher), standardní volba; používá Rijndael algoritmus; rychlý i v HW (AES-NI instrukce v moderních CPU)
ChaCha20 – proudová šifra (stream cipher), rychlá v SW bez HW akcelerace; TLS 1.3

🔏 Asymetrická kryptografie (PKI)

Asymetrická kryptografie (veřejného klíče) = každý uživatel má pár klíčů: veřejný klíč (public key – sdílí se s kýmkoli) a soukromý klíč (private key – přísně tajný, nikdy neopustí vlastníka).

Princip: co je zašifrováno veřejným klíčem, lze dešifrovat pouze soukromým (a naopak). Řeší problém distribuce klíčů symetrické kryptografie.

Výhoda: bezpečná komunikace bez předchozí výměny tajemství. Nevýhoda: pomalé (1000× pomalejší než symetrie) – proto se v praxi kombinují (hybrid: asymetrie pro výměnu symetrického klíče, pak symetrie pro šifrování dat).

Algoritmy:

RSA (Rivest–Shamir–Adleman, 1977) – bezpečnost na obtížnosti faktorizace velkých čísel; klíče 2048–4096 bitů
ECC (Elliptic Curve Cryptography) – kratší klíče při stejné bezpečnosti (256-bit ECC ≈ 3072-bit RSA)
Diffie-Hellman – protokol pro bezpečnou výměnu klíčů přes nezabezpečený kanál

#️⃣ Hashovací funkce a digitální podpis

Hashovací funkce (hash function) = jednosměrná matematická funkce, která z libovolně dlouhého vstupního textu vytvoří vždy stejně dlouhý výstup (hash/otisk). Vlastnosti:

Deterministická (stejný vstup = stejný výstup)
Jednosměrná (z hashe nelze rekonstruovat vstup)
Lavina (malá změna vstupu → úplně jiný hash)
Bezkoliznost (obtížné najít dva vstupy se stejným hashem)

Algoritmy: MD5 (128 bitů, 1992) – dnes prolomený, nepoužívat pro bezpečnost; SHA-1 (160 bitů) – prolomený 2017, deprecated; SHA-256 / SHA-3 – aktuální standard (část SHA-2/SHA-3 rodiny).

Digitální podpis: podepisující hashuje zprávu a hash zašifruje svým soukromým klíčem. Příjemce ověří pomocí veřejného klíče odesílatele. Zajišťuje: autenticitu, integritu, nepopiratelnost.

Certifikát (X.509) – digitální dokument vydaný CA (Certification Authority = certifikační autorita), který váže veřejný klíč na identitu. TLS/HTTPS certifikáty fungují takto.

⚔️ Typy kryptografických útoků

Brute-force – systematické vyzkoušení všech možných klíčů; obrana: dostatečná délka klíče
Dictionary attack – útok pomocí slovníku hesel; obrana: solení (salt) hashů
Rainbow table – předpočítané tabulky hashů; obrana: solení (náhodná hodnota přidaná před hashováním)
Kolizní útok – hledání dvou různých zpráv se stejným hashem (MD5, SHA-1 jsou zranitelné)

MITM (Man-in-the-Middle) – odposlech a modifikace komunikace; obrana: PKI, certifikáty, HSTS
Side-channel attack – útok na implementaci (měření spotřeby proudu, elektromagnetického záření, časování)
Replay attack – opětovné odeslání zachycené autentizační zprávy; obrana: nonce (číslo použité jen jednou), timestamp
Kvantová hrozba – Shorův algoritmus na kvantovém počítači prolomí RSA/ECC; post-quantum kryptografie (NIST standardizuje Kyber, Dilithium)

✍️ Podrobný postup digitálního podpisu – přenos zprávy

Digitální podpis zajišťuje: autentičnost (záruka identity odesílatele), integritu (zpráva nebyla modifikována), nepopiratelnost (nelze zpochybnit podpis), časový rámec.

Kompletní postup přenosu zprávy s podpisem a šifrováním (5 kroků):

Na straně odesílatele:

Odesílatel vytvoří hash původní zprávy (SHA-256) a zašifruje jej svým privátním klíčem → vznikne digitální podpis
Odesílatel původní zprávu zašifruje veřejným klíčem adresáta → nikdo jiný zprávu nepřečte
Odesílatel odešle: zašifrovanou zprávu + digitální podpis

Na straně příjemce:

Příjemce digitální podpis rozšifruje veřejným klíčem odesílatele → získá hash zprávy + ověří identitu odesílatele
Příjemce zašifrovanou zprávu rozšifruje svým privátním klíčem → získá obsah zprávy
Příjemce ze zprávy sám vytvoří hash, porovná jej s hashem z podpisu → pokud se shodují, integrita je zajištěna

Podepisovaná data: email, dokumenty, HTTP požadavky při volání webových služeb, software update packages.

Certifikační autorita (CA) = důvěryhodná třetí strana, která vydává X.509 certifikáty – váže veřejný klíč na identitu (firma, osoba). Hierarchie CA: Root CA → Intermediate CA → End-entity certifikát. Prohlížeče mají předinstalované Root CA (Mozilla NSS, Microsoft Root Store).

💡 Příklad z praxe: HTTPS a TLS handshake

Při otevření bankovní stránky probíhá TLS 1.3 handshake: 1) Prohlížeč zašle "ClientHello" (seznam podporovaných šifer). 2) Server odpoví "ServerHello" + svůj X.509 certifikát (veřejný klíč podepsaný důvěryhodnou CA, např. DigiCert). 3) Prohlížeč ověří certifikát u CA (řetězec důvěry). 4) Výměna klíčů pomocí ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) – vznikne dočasný symetrický klíč (session key). 5) Veškerá komunikace dále šifrována AES-256-GCM (symetricky, rychle). Zelený zámek v URL = certifikát je platný a komunikace šifrovaná.

⚠️ Časté záludnosti

❌ Šifrování ≠ hashování – šifrování je reverzibilní (lze dešifrovat klíčem); hashování je jednosměrné (nelze obrátit). Hesla se hashují, citlivá data se šifrují.

❌ MD5 a SHA-1 nejsou bezpečné – obě funkce mají nalezené kolize. Pro integrity check (kontrolní součty stažených souborů) jsou ještě OK, ale pro hashování hesel nebo digitální podpisy absolutně ne.

❌ Asymetrická kryptografie nešifruje velká data – RSA je pomalé a má omezení délky dat (max. délka = velikost klíče minus padding). Proto se používá jen pro výměnu symetrického klíče (hybrid encryption).

❌ Digitální podpis ≠ elektronický podpis – elektronický podpis (např. naskenovaný ruční podpis) nemá právní ani kryptografickou váhu. Zaručený elektronický podpis (dle eIDAS) ano.

🧩 Laicky: trezory a otiskovačky

Symetrická kryptografie = oba máte stejný klíč od trezoru – bezpečné jen pokud si klíč předáte osobně. Asymetrická = veřejný klíč je jako otevřená schránka s otvorem (každý může hodit zprávu dovnitř), soukromý klíč je váš jedinečný klíč od zámku (jen vy dokážete zprávu vytáhnout). Hashování = otiskovačka prstu – z otisku nelze zrekonstruovat prst, ale dvě různé ruce nikdy nedají stejný otisk (ideálně). Digitální podpis = pečeť vosku na dopisu – ověří, že ho opravdu poslal ten, kdo tvrdí (soukromý klíč jako pečetní prsten), a nikdo ho cestou neotevřel (integrita). TLS/HTTPS = brnění pro vaše data na cestě po internetu.

🎓 Napojení na DP

IT · 7

Elektronické podnikání a elektronické obchodování (e-business a e-commerce): principy, vztahy mezi subjekty, e-shop, vyhledávače, SEO, SEM, platební služby.

🛒 E-business vs. E-commerce

E-business (elektronické podnikání) = širší pojem; zahrnuje veškeré podnikatelské procesy realizované prostřednictvím elektronických sítí – interní procesy (řízení, výroba, logistika), komunikaci se zákazníky i dodavateli, sdílení informací.

E-commerce (elektronický obchod) = užší pojem; obchodní transakce (nákup a prodej zboží/služeb) uskutečňované přes internet. Je součástí e-businessu.

Modely e-commerce podle účastníků:

B2C (Business to Consumer) – firma prodává koncovému zákazníkovi (Amazon, Mall.cz, Alza)
B2B (Business to Business) – firma prodává firmě; EDI, elektronické aukce, katalogové systémy
B2G (Business to Government) – firma dodává státu; veřejné zakázky, e-procurement
C2C (Consumer to Consumer) – zákazník prodává zákazníkovi; Aukro, eBay, Vinted, Facebook Marketplace
C2B (Consumer to Business) – zákazník nabízí firmám (freelancer platformy: Upwork)

🏪 E-shop – klíčové součásti

Funkční e-shop potřebuje:

Produktový katalog – kategorizace, filtry, vyhledávání, fotogalerie, varianty
Nákupní košík – správa položek, uložení stavu (session/cookie/databáze)
Uživatelský účet – registrace, přihlášení, historie objednávek, adresář
Checkout – dokončení objednávky, volba dopravy a platby
Platební brána – integrace s platebními systémy
Správa skladu – skladové zásoby, skladové hospodářství
CMS (Content Management System) – správa obsahu bez programování
Analytika – sledování konverzí, chování zákazníků

Platforma: vlastní vývoj, Shoptet, WooCommerce (WordPress plugin), Magento, Shopify.

📢 Internetový marketing – SEO a SEM

SEO (Search Engine Optimization = optimalizace pro vyhledávače) – organické (neplacené) zlepšení pozice webu ve výsledcích vyhledávání (SERP = Search Engine Results Page). Kategorie:

On-page SEO: title tag, meta description, H1-H6 nadpisy, alt texty obrázků, rychlost načítání (Core Web Vitals), mobilní přívětivost, strukturovaná data (Schema.org)
Off-page SEO: zpětné odkazy (backlinks) z autoritativních webů (PageRank algoritmus)
Technical SEO: sitemap.xml, robots.txt, HTTPS, strukturovaný markup, canonicalization

SEM (Search Engine Marketing) – placená reklama ve vyhledávačích. Google Ads (dříve AdWords), Sklik (Seznam.cz).

PPC (Pay Per Click) – platba za každé kliknutí na reklamu. Model aukce: inzerenti soutěží o klíčová slova, cena závisí na konkurenci a Quality Score (skóre kvality).

💳 Elektronické platby

Metody elektronických plateb:

Platební karta – credit/debit card, standardy Visa/Mastercard/Amex; online platba přes 3D Secure (Verified by Visa, Mastercard SecureCode)
Převod online banking – přímá platba z účtu (Pay by Bank)
Digitální peněženka – PayPal, Apple Pay, Google Pay, Samsung Pay; tokenizace čísla karty
Kryptoměny – Bitcoin (BTC), Ethereum (ETH); decentralizované, blockchain technologie
Okamžité platby – SEPA Instant (do 10 sekund po celé EU, 24/7)
Buy Now Pay Later (BNPL) – Klarna, Splitit; odložená nebo splátkovaná platba

PCI DSS (Payment Card Industry Data Security Standard) – standard bezpečnosti platebních karet, povinný pro e-shopy zpracovávající platby kartou.

📊 Webová analytika a výkonové ukazatele

Klíčové metriky e-shopu:

Konverzní poměr (Conversion Rate, CR) – % návštěvníků, kteří nakoupili; průměr ~2–3 %
AOV (Average Order Value) – průměrná hodnota objednávky
CLV (Customer Lifetime Value) – celková hodnota zákazníka za celou dobu vztahu
CAC (Customer Acquisition Cost) – náklady na získání zákazníka
Bounce Rate – % okamžitých odchodů (návštěvník odešel bez interakce)
ROAS (Return on Ad Spend) – výnos na každou investovanou Kč do reklamy

Nástroje:

Google Analytics 4 (GA4) – bezplatná webová analytika; sleduje uživatele, sezení, události, konverze
Google Search Console – výkon v Google Search (klíčová slova, CTR, pozice)
Heatmapy (Hotjar, Clarity) – vizualizace klikání a pohybu myši
A/B testování – porovnání dvou verzí stránky/CTA na reálných uživatelích

🔄 EDI, E-Procurement a E-Marketplace

EDI (Electronic Data Interchange = elektronická výměna dat) = výměna strukturovaných obchodních dokumentů (faktury, objednávky, dodací listy) dle dohodnutých standardů přímo mezi informačními systémy obchodních partnerů – bez lidského zásahu.

Vlastnosti EDI: Integrita, Autentičnost, Důvěrnost, Rychlost, Jedinečnost, Prokazatelnost, Archivace, Spolehlivost.

Standardy: EDIFACT (mezinárodní), ANSI X12 (USA), XML/EDI (moderní). Velké společnosti (retail, automotive, logistika) často vyžadují EDI od svých dodavatelů. EDI operátoři: EDITEL, IBM, TELEDIN.

E-Procurement (elektronické zásobování) = elektronizace nákupního procesu mezi firmami (B2B); online výběrová řízení, správa dodavatelů, automatizované objednávky; úspora nákladů a času; systémy SAP Ariba, Jaggaer.

E-Marketplace (elektronická tržiště) = online platformy, kde se setkávají nabídka a poptávka více subjektů současně. Mohou fungovat jako:

B2B marketplace – firmy prodávají firmám; Alibaba, Amazon Business, IndiaMart
B2C marketplace – firmy prodávají spotřebitelům; Amazon, Mall, Alza, eBay
B2G marketplace – firmy dodávají státu; veřejné zakázky, NEN (Národní elektronický nástroj v ČR)
C2C marketplace – spotřebitelé si prodávají navzájem; Vinted, Aukro, Facebook Marketplace

Výhody marketplace: velká zákaznická základna, nízká bariéra vstupu, sdílená infrastruktura (platby, logistika).

Sémantický web = snaha doplnit strojově čitelné metainformace (sémantiku – význam) k informacím na webu. K těmto účelům slouží RDF (Resource Description Framework), mikroformáty nebo mikrodata (Schema.org). Pomáhají vyhledávačům a prohlížečům lépe pochopit obsah stránky → rich snippets ve výsledcích vyhledávání.

💡 Příklad z praxe: spuštění e-shopu s PPC kampaní

Malý výrobce ručně dělané keramiky spustil e-shop na Shoptetu. Prvních 6 měsíců investoval do Google Ads PPC kampaně s rozpočtem 5 000 Kč/měsíc, cílil na klíčová slova "keramika handmade" a "ručně vyráběná keramika". CPC (cena za klik) = 8 Kč, 625 kliků měsíčně, konverzní poměr 3 % = ~19 prodejů/měsíc, AOV = 850 Kč → měsíční obrat ~16 150 Kč, ROAS = 3,2 (na každou 1 Kč reklamy = 3,2 Kč příjmů). Paralelně budoval SEO – optimalizoval produktové stránky, získával backlinky z blogerů o lifestylu. Po 6 měsících organická návštěvnost pokryla 40 % objednávek bez dalších nákladů na reklamu.

⚠️ Časté záludnosti

❌ E-commerce ≠ e-shop – e-commerce je obchodní model (nákup/prodej online), e-shop je konkrétní technické řešení (webová aplikace). Firma může dělat e-commerce přes marketplace (Amazon) bez vlastního e-shopu.

❌ SEO není jednorázová věc – výsledky SEO jsou vidět po 3–6 měsících, vyžadují neustálou péči. Algoritmy vyhledávačů se mění stovkykrát ročně (Google: přes 500 aktualizací/rok).

❌ Vysoká návštěvnost ≠ úspěch e-shopu – klíčový je konverzní poměr. 10 000 návštěvníků s CR 0,1 % = 10 prodejů; 1 000 návštěvníků s CR 5 % = 50 prodejů. Kvalita over kvantita.

❌ B2B ≠ jen "firmy nakupují od firem" – B2B e-commerce má jiné charakteristiky: větší objemy, vyjednané ceny (ne ceníkové), schvalovací procesy, faktury se splatností 30/60 dní.

🧩 Laicky: tržiště a reklama

E-commerce je jako klasický tržiště přesunutý na internet. B2C = prodavač na tržišti prodává lidem jdoucím kolem. B2B = výrobce, který prodává velkoobchodníkům v zadní části tržiště. C2C = bleší trh, kde zákazníci prodávají navzájem. SEO je jako mít výhodné místo přímo u vchodu na tržiště (zákazníci vás vidí první, zadarmo). PPC je jako platit za billboard před tržištěm – vidíte ho všichni, ale platíte za každého, kdo přijde kvůli vám. Konverzní poměr je poměr lidí, kteří vstoupili do vašeho stánku, vůči těm, kteří skutečně koupili – průměr 3 % znamená, že 97 z každých 100 lidí odejde s prázdnou. Platební brána je moderní elektronická pokladna.

🎓 Napojení na DP

IT · 8

Internet: standardy a protokoly, infrastruktura, metody přenosu dat, systém DNS.

🌐 Co je internet a jak vznikl

Internet = globální síť propojující miliardy zařízení pomocí standardizované sady protokolů TCP/IP. Není vlastněn nikým – je to decentralizovaná infrastruktura řízená komunitními organizacemi (IETF, ICANN, W3C).

Historie: ARPANET (1969, USA ministerstvo obrany) → NSFNET (1985, vědecké sítě) → komercionalizace (1990s) → WWW (Tim Berners-Lee, 1991) → dnešní internet.

Fyzická infrastruktura: transoceánické podmořské kabely (subsea cables), pozemní optické sítě (backbone), páteřní routery (core routers), IXP (Internet Exchange Points = body vzájemného propojení sítí), přístupové sítě (access networks – DSL, optika, 4G/5G).

ISP (Internet Service Provider = poskytovatel internetového připojení) – firma, která poskytuje přístup k internetu. Hierarchie: Tier 1 (globální páteřní sítě, peering zdarma), Tier 2 (regionální, nakupují transit od Tier 1), Tier 3 (lokální ISP pro koncové zákazníky).

📡 TCP/IP zásobník protokolů

TCP/IP = sada protokolů tvořící základ internetu. 4 vrstvy:

Aplikační vrstva – protokoly pro konkrétní aplikace: HTTP/HTTPS (web), SMTP/IMAP/POP3 (e-mail), FTP/SFTP (přenos souborů), SSH (vzdálená správa), DNS, DHCP
Transportní vrstva – end-to-end přenos:
- TCP (Transmission Control Protocol) – spojovaný, spolehlivý (potvrzení doručení, pořadí paketů, retransmise); pro HTTP, FTP, e-mail
- UDP (User Datagram Protocol) – nespojovaný, nespolehlivý, rychlý (bez potvrzení); pro video streaming, DNS, VoIP, online hry
Síťová vrstva – IP protokol, adresování, směrování (routing) přes routery
Vrstva síťového rozhraní – fyzické připojení (Ethernet, Wi-Fi, optika)

🏷️ IP adresy – IPv4 a IPv6

IP adresa = číselný identifikátor zařízení v síti.

IPv4: 32 bitů, zapsáno jako 4 oktety (0–255), např. 192.168.1.100. Celkem ~4,3 miliardy adres – vyčerpány! (2011 IANA, 2012 RIPE NCC). Speciální rozsahy: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 = privátní adresy (RFC 1918), přes NAT (Network Address Translation) sdílí jednu veřejnou adresu.

IPv6: 128 bitů, zapsáno hexadecimálně, např. 2001:0db8:85a3::8a2e:0370:7334. Celkem ~340 undecilionů adres = prakticky nevyčerpatelné. Podporuje autokonfiguraci (SLAAC), IPsec nativně.

CIDR (Classless Inter-Domain Routing) – notace sítě: 192.168.1.0/24 = první 24 bitů je síťová část, posledních 8 bitů = hostitelé (254 použitelných adres).

🔍 DNS – Domain Name System

DNS (Domain Name System = systém doménových jmen) = distribuovaná hierarchická databáze, která překládá lidsky čitelná doménová jména (www.google.com) na IP adresy (142.250.185.46) a zpět (reverzní DNS).

Hierarchie DNS:

Root DNS – 13 logických serverů (A–M.root-servers.net) spravovaných IANA; odpovídají na dotazy pro TLD
TLD (Top-Level Domain) – .com, .cz, .org, .net, .edu, gTLD (generic) vs. ccTLD (country-code)
Autoritativní DNS server – uchovává záznamy pro konkrétní doménu
Rekurzivní resolver – (DNS cache na ISP nebo v OS) – ptá se hierarchie za uživatele a cachuje výsledky

DNS záznamy (resource records): A (IPv4 adresa), AAAA (IPv6), CNAME (alias), MX (mail server), TXT (ověření, SPF, DKIM), NS (nameserver), SOA (Start of Authority).

DNS over HTTPS (DoH) / DNS over TLS (DoT) – šifrované DNS dotazy (ochrana soukromí).

📧 Aplikační protokoly internetu

E-mailové protokoly:

SMTP (Simple Mail Transfer Protocol, port 25/587) – odeslání e-mailu ze klienta na server a přenos mezi servery
IMAP (Internet Message Access Protocol, port 143/993) – přístup k e-mailům uloženým na serveru; e-maily zůstávají na serveru, synchronizace více zařízení
POP3 (Post Office Protocol v3, port 110/995) – stažení e-mailů ze serveru do klienta; e-maily se ze serveru smažou (nebo zůstanou podle nastavení)

Přenosové protokoly:

HTTP (HyperText Transfer Protocol, port 80) – přenos webového obsahu; textový, nešifrovaný
HTTPS (HTTP Secure, port 443) – HTTP přes TLS/SSL šifrování
FTP (File Transfer Protocol, port 21) – přenos souborů; nešifrovaný
SFTP (SSH File Transfer Protocol, port 22) – šifrovaný přenos souborů přes SSH
DHCP (Dynamic Host Configuration Protocol, port 67/68) – automatické přidělování IP adres

💡 Příklad z praxe: co se stane, když napíšete URL do prohlížeče

Zadáte https://www.example.com/product. 1) OS zkontroluje lokální DNS cache → nenalezeno. 2) Dotaz na rekurzivní resolver ISP → ten se ptá Root DNS → .com TLD server → autoritativní DNS pro example.com → vrátí IP adresu (93.184.216.34). 3) Prohlížeč navazuje TCP spojení na port 443 (three-way handshake: SYN → SYN-ACK → ACK). 4) TLS handshake – výměna certifikátu, verifikace CA, dohodnutí šifrovací sady. 5) Odeslání HTTP GET požadavku. 6) Server vrátí HTML odpověď. 7) Prohlížeč renderuje stránku (HTML → DOM → CSSOM → Render tree → Paint). Celý proces trvá typicky 200–500 ms.

⚠️ Časté záludnosti

❌ TCP vs. UDP výběr – TCP pro spolehlivý přenos (web, e-mail, přenos souborů); UDP pro real-time aplikace kde je latence důležitější než spolehlivost (video streaming, VoIP, DNS dotazy). Záměna způsobí buď nespolehlivý přenos nebo zbytečnou latenci.

❌ IMAP vs. POP3 – IMAP ponechává e-maily na serveru a synchronizuje více zařízení; POP3 e-maily stáhne a (typicky) smaže ze serveru. Pro moderní použití (telefon + počítač) je správnou volbou IMAP.

❌ DNS cache poisoning – útočník může podstrčit falešné DNS záznamy do cache (útok MITM). Ochrana: DNSSEC (DNS Security Extensions – digitální podpisy záznamů).

❌ IP adresa ≠ MAC adresa – IP adresa (logická, přiřazená sítí, může se měnit) vs. MAC adresa (fyzická, výrobcem přidělená síťové kartě, prakticky trvalá). Komunikace v LAN používá MAC (ARP protokol přeloží IP na MAC).

🧩 Laicky: internet jako poštovní systém

IP adresa = PSČ + číslo domu vašeho domu na internetu. DNS = poštovní adresář, který vyhledá adresu podle jména (google.com → 142.250.185.46). TCP = doporučená zásilka s potvrzením převzetí a opakovaným odesláním, pokud zásilka nedorazí. UDP = pohlednice – pošlete, doufáte, že dorazí, ale nikdo to neřeší (pro video streaming nevadí, když jeden snímek zmizí). HTTP = jazyk, kterým si prohlížeč a server povídají ("dej mi tuto stránku"). HTTPS = to samé, ale v utajené šifrované místnosti. DNS resolver vašeho ISP je jako informační přepážka na poště – zná odpovědi na nejčastější dotazy z paměti (cache), a pokud ne, jde se zeptat do hlavní pošty (root DNS).

🎓 Napojení na DP

IT · 9

World Wide Web: hypertext, URI, HTTP(S), značkovací jazyky a jejich principy: jazyk HTML, XML. Webové prohlížeče, cache stránek, sémantický web, hluboký web.

🌍 WWW – World Wide Web

WWW (World Wide Web) = systém propojených hypertextových dokumentů přístupných přes internet pomocí protokolu HTTP. Vynalezl Tim Berners-Lee v CERN (1989–1991). WWW ≠ internet – WWW je jedna ze služeb internetu (stejně jako e-mail, FTP).

Tři základní technologie WWW: URL (adresa dokumentu), HTTP (protokol přenosu), HTML (formát dokumentu).

Vývoj webu:

Web 1.0 (1990s) – statické stránky, jen čtení (read-only web)
Web 2.0 (2000s) – interaktivní, uživatelský obsah (social media, wiki, blogy), AJAX, dynamické aplikace
Web 3.0 – sémantický web, AI, decentralizace (blockchain, DeFi), IoT integrace

Deep web = části webu, které nejsou indexovány vyhledávači (přihlášené zóny, databáze, intranet). Dark web = záměrně skrytá část, přístupná jen přes speciální software (Tor), anonymita.

🔗 URI, URL, URN

URI (Uniform Resource Identifier) = obecný identifikátor zdroje. Dvě podmnožiny:

URL (Uniform Resource Locator) = adresa + způsob přístupu: https://www.example.cz:443/path?q=dotaz#sekce
- Schéma: https
- Host: www.example.cz
- Port: 443 (výchozí pro HTTPS, lze vynechat)
- Cesta: /path
- Query string: ?q=dotaz
- Fragment (kotva): #sekce
URN (Uniform Resource Name) = trvalé jméno bez umístění: urn:isbn:978-80-247-4252-4

Procentové kódování (URL encoding) – speciální znaky v URL se kódují: mezera = %20, & = %26.

📄 HTML – HyperText Markup Language

HTML = značkovací jazyk (markup language) pro strukturu webových dokumentů. Aktuální verze: HTML5 (2014, WHATWG Living Standard). Není programovací jazyk – popisuje strukturu, ne chování.

Klíčové HTML5 prvky:

Sémantické elementy: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer> – přidávají význam obsahu pro vyhledávače a screen readery
Formuláře: nové typy input (date, email, range, color), validace, placeholder
Média: nativní <video>, <audio>, <canvas> (2D/3D grafika přes JS), <svg>
Offline/storage: Local Storage, Session Storage, IndexedDB, Service Workers (PWA)

DOM (Document Object Model) = stromová reprezentace HTML dokumentu v paměti prohlížeče; JS může DOM manipulovat (přidávat/mazat/měnit elementy).

📋 XML a datové formáty

XML (eXtensible Markup Language) = flexibilní značkovací jazyk pro přenos a uložení strukturovaných dat. Na rozdíl od HTML: tagy si definuje uživatel, zaměřen na data (ne prezentaci), přísná syntaxe (well-formed).

Technologie XML ekosystému:

DTD / XML Schema – validace struktury dokumentu
XSLT – transformace XML do jiného formátu (HTML, PDF, jiný XML)
XPath – dotazovací jazyk pro navigaci v XML stromě
RSS/Atom – XML formáty pro syndikaci obsahu (novinky, blogy)
SOAP – webové služby přes XML zprávy
SVG – vektorová grafika v XML

JSON (JavaScript Object Notation) – odlehčená alternativa XML; čitelnější, méně verbose, preferovaný formát REST API. YAML – ještě čitelnější, pro konfiguraci (Kubernetes, CI/CD).

📡 HTTP protokol

HTTP (HyperText Transfer Protocol) – textový protokol žádost-odpověď (request-response), bezstavový (stateless). Verze:

HTTP/1.1 (1997) – persistent connections, chunked transfer; jedno požadavek po druhém (head-of-line blocking)
HTTP/2 (2015) – multiplexing (více požadavků paralelně po jednom spojení), server push, header komprese (HPACK)
HTTP/3 (2022) – nad protokolem QUIC (UDP místo TCP), rychlejší handshake, lepší výkon při výpadcích paketů

HTTP metody: GET (získej zdroj), POST (odešli data/vytvoř), PUT (nahraď), PATCH (aktualizuj část), DELETE (smaž), HEAD (jen hlavičky), OPTIONS (co server umí).

Stavové kódy: 2xx (úspěch), 3xx (přesměrování), 4xx (chyba klienta: 404 Not Found, 403 Forbidden), 5xx (chyba serveru: 500 Internal Server Error).

🧠 Sémantický web a Linked Data

Sémantický web (Semantic Web) – vize Tima Berners-Leeho (2001): web, kde data mají strojově čitelný význam, nejen strukturu. Stroje mohou automaticky porozumět obsahu a provádět uvažování.

Technologie:

RDF (Resource Description Framework) – trojice subjekt-predikát-objekt pro popis dat
OWL (Web Ontology Language) – ontologie, definice tříd a vztahů
SPARQL – dotazovací jazyk pro RDF databáze (knowledge graphs)
Schema.org – mikrodata/JSON-LD anotace pro vyhledávače (structured data, rich snippets)

Praktické využití dnes: Google Knowledge Graph, Wikidata, DBpedia, rich snippets ve výsledcích vyhledávání, AI tréninkové datové sady.

🔗 Hypertext

Hypertext je způsob prezentace informací na webových stránkách umožňující uživatelům snadno navigovat mezi dokumenty prostřednictvím hypertextových odkazů.

Odkazy mohou být textové, grafické nebo multimediální prvky propojené s jinými stránkami nebo s konkrétními částmi téže stránky
Díky hypertextu jsou stránky interaktivní a uživatelsky přívětivé – umožňují procházení, vyhledávání a navigaci jednoduchým klikáním
Hypertextové odkazy jsou klíčovým prvkem pro indexování stránek vyhledávači (Google, Bing) – procházejí je pomocí crawlerů
Základ hypertextu: Tim Berners-Lee (CERN, 1989) – myšlenka propojit dokumenty přes globální síť odkazů

Hypertext = obsah; HTTP = protokol přenosu; HTML = formát zápisu; URL = adresa dokumentu.

🌐 Webové prohlížeče – jak fungují

Webový prohlížeč je softwarová aplikace sloužící jako klient v modelu klient-server. Postup načtení stránky:

Uživatel zadá URL → prohlížeč se dotáže DNS serveru na IP adresu domény (DNS = „telefonní seznam internetu")
DNS vrátí IP adresu → prohlížeč naváže TCP/TLS spojení s webovým serverem
Prohlížeč odešle HTTP GET požadavek na server
Server vrátí HTML, CSS, JS, obrázky → prohlížeč je zpracuje a vykreslí stránku

Hlavní prohlížeče: Chrome (V8/Blink), Firefox (SpiderMonkey/Gecko), Safari (JavaScriptCore/WebKit), Edge (Chromium-based).

Renderovací jádra: Blink (Chrome/Edge), Gecko (Firefox), WebKit (Safari). Jádro parsuje HTML → DOM strom, CSS → CSSOM, spojí je → Render tree → Layout → Paint.

💾 Cache stránek

Caching = ukládání kopií souborů do mezipaměti (dočasného úložiště) pro rychlejší přístup. Tři úrovně cache:

Prohlížečová cache – prohlížeč ukládá HTML, JS, CSS, obrázky lokálně; při opakované návštěvě načítá z disku místo ze sítě → výrazně rychlejší načítání (kontrolováno HTTP hlavičkami Cache-Control, ETag, Expires)
DNS cache – DNS servery ukládají záznamy (TTL = Time to Live); prohlížeč si pamatuje IP adresu domény po dobu TTL → méně DNS dotazů
CDN cache (Content Delivery Network) – statický obsah je distribuován na servery po celém světě; uživatel dostává soubory z geograficky nejbližšího serveru → nižší latence (Cloudflare, AWS CloudFront, Akamai)

Výhody cache: rychlejší stránky, nižší zátěž serveru, nižší přenosové náklady. Nevýhoda: stará verze může být servírována, dokud nevyprší TTL (cache invalidation).

📝 Typy značkovacích jazyků

Značkovací jazyky (Markup Languages) = jazyky, jejichž zdrojový text obsahuje jak vlastní obsah, tak instrukce pro jeho zpracování (ve formě tagů/příkazů). Dělí se na dvě skupiny:

Popisné (deskriptivní) jazyky – značky popisují co jsou informace, ne jak je zobrazit. Oddělují obsah od prezentace.
- HTML – popisuje strukturu webového dokumentu (nadpis, odstavec, odkaz)
- XML – univerzální popis struktury dat pro výměnu mezi systémy
Výkonné (procedurální) jazyky – obsahují instrukce na úrovni programovacího jazyka (proměnné, podmínky, cykly, paměť).
- TeX / LaTeX – profesionální sazba dokumentů (matematika, akademické texty)
- PostScript – programovací jazyk pro popis stránky při tisku; základ PDF

Zdrojovým textem bývá ASCII soubor editovatelný i jednoduchými textovými editory.

💡 Příklad z praxe: HTTP/2 vs. HTTP/1.1 výkon

Zpravodajský web načítá na úvodní stránce 80 různých zdrojů (CSS, JS, obrázky, fonty). HTTP/1.1: prohlížeč otevírá 6 paralelních TCP spojení (max. dle spec.), zbylé zdroje čekají v řadě – celková doba načítání 3,2 sekundy. HTTP/2: vše přes jedno TCP spojení s multiplexingem, server push předem pošle kritické CSS – celková doba 1,1 sekundy. HTTP/3 (QUIC): 0-RTT handshake (žádné zdržení při navázání spojení), vynikající i při pohybu mezi Wi-Fi a 5G sítí – 0,8 sekundy. Výsledek: přechod na HTTP/2 zvýšil Core Web Vitals skóre a pozici ve vyhledávačích (Google řadí rychlé weby výše).

⚠️ Časté záludnosti

❌ WWW ≠ internet – internet je fyzická síť, WWW je jedna z jejích služeb (protokol HTTP). E-mail, SSH, FTP jsou také internetové služby, ale nejsou součástí WWW.

❌ HTML není programovací jazyk – HTML je deklarativní značkovací jazyk popisující strukturu, ne logiku. Programovacím jazykem pro web je JavaScript.

❌ URL encoding – mezery v URL nelze zadat přímo; musí být zakódovány jako %20 nebo + (v query stringu). Nezakódované URL způsobí chyby nebo bezpečnostní problémy.

❌ HTTP je bezstavový – HTTP sám o sobě neudržuje stav mezi požadavky. Stav (přihlášení, košík) se udržuje pomocí cookies, session storage nebo JWT (JSON Web Token).

🧩 Laicky: web jako knihovna

Internet = budova knihovny. WWW = sbírka knih v té knihovně (ne celá budova – jsou tam i jiné věci). URL = přesná lokace knihy (regál A3, police 2, číslo 47). HTTP = jazyk, kterým si říkáte o knihu od knihovníka. HTML = jazyk, ve kterém je kniha napsána (nadpisy, odstavce, obrázky). XML = univerzální jazyk pro přenos dat mezi knihovnami (každá může mít vlastní "tagy"). HTTP/2 = nový systém, kdy si najednou půjčíte celou polici místo knih jednu po druhé. Sémantický web = knihy navíc opatřené strojovými štítky ("tato kapitola pojednává o fyzice kvantové mechaniky") – počítač nejen přečte text, ale pochopí jeho obsah.

🎓 Napojení na DP

IT · 10

Metody, postupy a nástroje používané při projektování a realizaci webových projektů, prototypování, responzivní design.

📐 Metodiky vývoje webových projektů

Správná metodika (methodology) = plán jak postupovat při tvorbě webu. Výběr závisí na velikosti projektu, stabilitě požadavků a týmu.

Vodopádová metoda (Waterfall) – sekvenční, lineární průběh: Analýza → Návrh → Implementace → Testování → Nasazení → Údržba. Fáze nesmí překrývat; po dokončení fáze se (téměř) nevracíme. Vhodné pro: dobře definované projekty s neměnnými požadavky. Nevýhody: neflexibilní, zákazník vidí výsledek pozdě, chyby z analýzy jsou drahé opravit.

Agilní metodiky (Agile) – iterativní, inkrementální vývoj v krátkých cyklech (sprintech). Manifesto: fungující software nad dokumentací, spolupráce se zákazníkem nad smlouvou, reakce na změnu nad plánem. Nejznámější: Scrum (sprinty 1–4 týdny, Product Backlog, Daily Standup, Sprint Review) a Kanban (vizuální nástěnka, WIP limity, průběžné doručování).

🔄 Agilní vs. Vodopád – srovnání

Kritérium	Waterfall	Agile (Scrum)
Požadavky	Pevné od začátku	Mohou se měnit
Délka cyklu	Měsíce–roky	1–4 týdny (sprint)
Zákazník	Zapojený na začátku a konci	Průběžně zapojený
Dokumentace	Rozsáhlá	Jen nezbytná
Testování	Na konci	Průběžně (TDD)
Riziko	Velké (pozdní zpětná vazba)	Malé (rychlá zpětná vazba)
Vhodné pro	Jasně definované projekty	Inovativní, měnlivé projekty

✏️ Prototypování a wireframy

Prototypování = tvorba zjednodušeného modelu výsledného produktu za účelem testování a ověřování nápadů s uživateli ještě před plnou implementací. Šetří náklady: opravit prototyp je 100× levnější než opravit hotový produkt.

Úrovně věrnosti (fidelity):

Wireframe (drátěný model) – černobílý skelet stránky; zobrazuje rozvržení (layout) bez barev a grafiky; rychlé, levné. Nástroje: pero a papír, Balsamiq, Whimsical
Low-fidelity (lo-fi) prototyp – papírový prototyp nebo jednoduchá digitální verze; klikatelné přechody mezi stránkami
High-fidelity (hi-fi) prototyp – vizuálně věrný finálnímu produktu, reálné interakce; Figma, Adobe XD, Sketch, InVision

User story = stručný popis funkce z pohledu uživatele: "Jako [typ uživatele] chci [cíl], abych [důvod]". Základ Agile specifikace.

📱 Responzivní design a přístupnost

Responzivní design (Responsive Web Design, RWD) = web se automaticky přizpůsobuje rozlišení a velikosti displeje. Techniky:

Fluid grid – relativní šířky (%, fr) místo pevných px
Flexible images – max-width: 100%; srcset pro různá rozlišení
Media queries – CSS podmínky pro různé breakpointy (576px, 768px, 992px, 1200px)
Mobile-first přístup – navrhujeme nejprve pro malý displej, postupně rozšiřujeme

Přístupnost (Accessibility, a11y) – web musí být použitelný i pro lidi s handicapem. Standard: WCAG 2.1 (Web Content Accessibility Guidelines); 4 principy: Perceivable (vnímatelný), Operable (ovladatelný), Understandable (srozumitelný), Robust (robustní). Úrovně: A (základní), AA (standard, zákon 99/2019 pro veřejné weby ČR), AAA (nejvyšší).

🎨 Fáze tvorby webového projektu

Analýza a plánování – cíle webu, cílová skupina, konkurence, obsah, rozpočet, harmonogram
Informační architektura – sitemap (mapa stránek), struktura navigace, taxonomie obsahu
UX design – user research (průzkum uživatelů), personas, user journey maps, wireframy, testování použitelnosti
UI design – vizuální design (barvy, typografie, ikonografie), design system, hi-fi prototyp

Vývoj front-endu – HTML/CSS/JS implementace designu, responzivita, přístupnost
Vývoj back-endu – serverová logika, databáze, API, CMS integrace
Testování – funkční testy, cross-browser testování, výkonnostní testy, bezpečnostní audit, a11y audit
Nasazení a provoz – CI/CD pipeline, monitoring (výkon, chyby), SEO, analytika, iterativní zlepšování

📐 Adaptivní a statistický design – rozdíly od responzivního

Vedle responzivního designu existují dvě další strategie přizpůsobení webu různým zařízením:

Responzivní design

Stránka se dynamicky mění a přizpůsobuje velikosti obrazovky zařízení pomocí CSS (fluid grid, media queries).

Jedna verze kódu pro všechna zařízení
Přizpůsobení čistě na straně klienta (CSS)
Příklad: Bootstrap grid přeskládá sloupce na mobilu

Adaptivní design

Stránka se mění dle konkrétního zařízení, rozlišení a orientace – mohou existovat různé verze stránek.

Kombinace server-side a client-side detekce zařízení
Server rozpozná typ zařízení (User-Agent) a servíruje jinou šablonu
Výhoda: dokonalý zážitek pro konkrétní zařízení (mobil dostane jinou stránku než desktop)
Příklad: m.facebook.com vs. facebook.com

Statistický design

Stránka se vytváří a přizpůsobuje na základě statistických dat o uživatelích a jejich preferencích.

Využívá A/B testování – dvě verze stránky, porovnání konverzí
Heatmapping – sledování pohybu myši a klikání (Hotjar)
Data z analytiky (GA4) určují, které prvky fungují nejlépe
Příklad: Amazon testuje různá rozvržení tlačítka "Koupit" a sleduje, která verze zvyšuje prodeje

Typ	Princip	Kdo rozhoduje	Výhoda
Responzivní	Fluid layout, CSS media queries	CSS / prohlížeč	Jedna kódová báze, nejjednodušší
Adaptivní	Server detekuje zařízení → servíruje jinou šablonu	Server	Optimální UX pro každé zařízení
Statistický	A/B testy, heatmapy, analytika	Data + vývojář	Design podložený reálnými daty uživatelů

💡 Příklad z praxe: redesign e-shopu Agile metodou

E-shop s oblečením se rozhodl pro redesign mobilní verze. Sprint 1 (2 týdny): wireframy produktové stránky, uživatelské testování s 5 uživateli (nalezeny 3 kritické UX problémy – špatně viditelné tlačítko "Přidat do košíku"). Sprint 2: hi-fi prototyp opravených obrazovek, A/B test na 10 % provozu – konverzní poměr +23 %. Sprint 3: implementace redesignu produktové stránky, nasazení. Sprint 4: kategorie produktů a filtrování. Výsledek po 8 sprintech (4 měsíce): kompletně redesignovaná mobilní verze, konverzní poměr mobil +34 %, průměrná doba načítání klesla z 4,2 s na 1,8 s (LCP).

⚠️ Časté záludnosti

❌ Wireframe ≠ design – wireframe je o rozvržení a funkci, ne o estetice. Přidávání barev a fontů do wireframu odvádí pozornost od diskuse o UX k diskusi o designu.

❌ Responzivní ≠ mobile-friendly – responzivní web se technicky přizpůsobuje, ale nemusí být použitelný na mobilu. Mobile-first přístup navrhuje primárně pro dotykový displej a malou obrazovku.

❌ Agile ≠ žádná dokumentace – Agile preferuje fungující software nad rozsáhlou dokumentací, ale neříká "žádná dokumentace". API dokumentace, architekturní rozhodnutí (ADR) a uživatelské příručky jsou stále potřeba.

❌ Přístupnost není jen pro nevidomé – WCAG pomáhá i uživatelům s motorickými problémy (ovládání klávesnicí), starším uživatelům, lidem v hlučném prostředí (captions), nebo uživatelům na pomalém internetu.

🧩 Laicky: stavba domu vs. webový projekt

Waterfall = tradiční stavba domu: nejprve projekt, pak základy, pak zdi, pak střecha – nemůžete položit střechu před zdmi. Agile = modulární prefabrikovaná výstavba: každé 2 týdny přidáte jednu místnost a zákazník může vstoupit, prohlédnout si ji a říct "dejte mi okno jinam". Wireframe = výkres architekta na papíru – žádné barvy, jen kde jsou dveře a okna. Hi-fi prototyp = 3D vizualizace nebo model domu v plném detailu. Responzivní design = dům, který se sám přestavuje podle počtu obyvatel – rodin 5 osob dostane 4 pokoje, singles dostane garsonku. A přístupnost = výtah a rampa pro vozíčkáře – web musí fungovat i pro ty, kdo nemohou používat myš nebo nevidí barvy.

🎓 Napojení na DP

IT · 11

UX, použitelnost, přístupnost: metody, principy měření a hodnocení. Kontinuální zlepšování UX. SLA a softwarové licence. Sociální sítě a jejich principy. Webová analytika.

🎯 UX – User Experience

UX (User Experience = uživatelský zážitek) = celková zkušenost uživatele při interakci s produktem nebo systémem. Zahrnuje nejen vizuální stránku, ale celý průběh: co uživatel cítí, jak snadno dosáhne cíle, zda byl spokojen.

Morvillových 7 faktorů UX (honeycomb):

Useful (užitečný) – splňuje potřeby uživatele
Usable (použitelný) – snadné a intuitivní ovládání
Desirable (žádoucí) – esteticky přitažlivý design
Findable (nalezitelný) – obsah lze snadno najít (navigace, vyhledávání)
Accessible (přístupný) – použitelný pro lidi s handicapem
Credible (důvěryhodný) – uživatel věří produktu a organizaci
Valuable (hodnotný) – přináší hodnotu uživateli i organizaci

UX výzkum: interview, dotazníky, A/B testy, heatmapy, eye-tracking, usability testování (5 uživatelů odhalí 85 % problémů – Nielsen's rule).

👆 Použitelnost (Usability)

Použitelnost (usability) = míra, do jaké mohou uživatelé dosáhnout svých cílů efektivně, eficientemente a se spokojeností.

Nielsenovych 10 heuristik použitelnosti:

Viditelnost stavu systému (feedback)
Shoda s reálným světem (přirozený jazyk)
Uživatelská kontrola a svoboda (undo/redo)
Konzistentnost a standardy
Prevence chyb
Rozpoznání místo vzpomínání (recognition over recall)
Flexibilita a efektivita (zkratky pro pokročilé)
Estetický a minimalistický design
Pomoc uživateli rozpoznat, diagnostikovat a napravit chyby
Nápověda a dokumentace

KISS princip (Keep It Simple, Stupid) – jednoduché rozhraní je lepší než složité. Méně funkcí, jasnější cesta k cíli.

♿ Přístupnost – WCAG 2.1

Přístupnost (Accessibility, a11y) = web je použitelný pro všechny, včetně osob se zdravotním postižením (zrakovým, sluchovým, motorickým, kognitivním).

WCAG 2.1 (Web Content Accessibility Guidelines) – standard W3C. 4 principy (POUR):

Perceivable (Vnímatelný) – alternativní text k obrázkům, titulky k videím, dostatečný kontrast (min. 4,5:1)
Operable (Ovladatelný) – vše ovladatelné klávesnicí, dostatečný čas na přečtení, žádné blikání >3×/sec
Understandable (Srozumitelný) – čitelný text, předvídatelné chování, nápověda při chybách formuláře
Robust (Robustní) – kompatibilní s asistivními technologiemi (screen readery)

Úrovně: A základní, AA standard (povinný zákon 99/2019 Sb. pro veřejné weby ČR), AAA nejvyšší.

Asistivní technologie: screen readery (NVDA, JAWS, VoiceOver), braillský řádek, přepínač (switch access), eye-tracking.

📜 SLA a softwarové licence

SLA (Service Level Agreement = dohoda o úrovni služeb) – smlouva definující garantované parametry služby:

Dostupnost (uptime): 99,9 % = "three nines" = max 8,77 hod. výpadku/rok; 99,99 % = "four nines" = max 52,6 min./rok
RTO (Recovery Time Objective) = doba do obnovení provozu
RPO (Recovery Point Objective) = max. přijatelná ztráta dat
Reakční doba (response time) na incidenty

Softwarové licence:

OEM – vázáno na konkrétní HW, nepřenosné
Retail – zakoupeno individuálně, přenosné
Volume/Enterprise – hromadné licence pro organizace
Freeware – zdarma, ale uzavřený kód
Open source – otevřený zdrojový kód; GPL (copyleft – odvozené práce musí být také open source), MIT/Apache 2.0 (permissive – lze použít v komerčním SW), LGPL (pro knihovny)
Creative Commons – licence pro kreativní obsah (CC-BY, CC-BY-SA, CC0)

📱 Sociální sítě v kontextu webových projektů

Sociální sítě (social media) jsou součástí marketingové strategie a integrace webu:

Open Graph (Facebook/Meta protokol) – meta tagy pro sdílení obsahu na sociálních sítích s náhledem (og:title, og:image)
Twitter Cards – podobné pro Twitter/X
Social login – přihlášení přes Facebook/Google (OAuth 2.0)
Integrace komentářů (Disqus), tlačítek sdílení, live feedů
UGC (User Generated Content) – obsah vytvořený uživateli (recenze, fotky)

📊 Webová analytika

Analytika pomáhá pochopit chování uživatelů a měřit úspěšnost webu:

Google Analytics 4 (GA4) – events-based model, cross-device tracking, machine learning insights
Bounce rate – % okamžitých odchodů (ukazatel relevance obsahu)
Konverzní poměr – % návštěvníků, kteří provedli požadovanou akci
Session duration – průměrná délka návštěvy
Funnel analysis – analýza nákupního trychtýře (kde uživatelé odcházejí)
Heatmapy (Hotjar, MS Clarity) – vizualizace klikání a pohybu myši
Core Web Vitals – Google metriky: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint)

🧪 Metody testování použitelnosti

Testování použitelnosti odhaluje, jak skuteční uživatelé interagují s produktem. Metody se dělí dle několika hledisek:

Dle typu dat:

Kvalitativní – zjišťuje proč a jak uživatel přemýšlí: rozhovory (interview), focus groups, think-aloud protokol, kognitivní průchod (cognitive walkthrough)
Kvantitativní – měří výkon: čas splnění úkolu (task completion time), úspěšnost (success rate), počet chyb, eye-tracking metriky

Dle místa konání:

Osobně (in-person): laboratorní (kontrolované prostředí) nebo in-situ (v přirozeném prostředí uživatele)
Vzdáleně (remote): moderované (moderátor v online hovoru) nebo nemoderované (uživatel sám, automatizované – UserZoom, Maze)

Dle účastníků:

Uživatelské testování – skuteční nebo reprezentativní uživatelé; 5 uživatelů odhalí ~85 % problémů (Nielsenovo pravidlo)
Expertní hodnocení: Heuristická evaluace (expert porovnává s 10 Nielsonovými heuristikami), Kognitivní průchod (expert simuluje kroky nového uživatele krok po kroku)

🔄 Kontinuální zlepšování UX

Kontinuální zlepšování UX = proces průběžného vylepšování produktů a služeb na základě zpětné vazby uživatelů a analýzy dat. Není to jednorázová aktivita, ale cyklický proces:

Sběr zpětné vazby – dotazníky (NPS, CSAT), uživatelské rozhovory, podpora (helpdesk tickety), analytická data
Sledování UX metrik – konverzní poměr, bounce rate, task completion rate, NPS (Net Promoter Score), heatmapy, session recordings
Identifikace problémů – kde uživatelé selhávají, opouštějí stránku, jsou frustrováni
Prioritizace – dle dopadu na uživatele a obchodní cíle (impact vs. effort matrix)
Implementace změn – A/B testy pro ověření hypotéz před plným nasazením
Měření výsledků – porovnání metrik před a po změně → cyklus začíná znovu

Nástroje: Google Analytics 4, Hotjar (heatmapy, session recordings), Mixpanel (produktová analytika), UserVoice (feedback).

Klíčový princip: data-driven design – každé rozhodnutí o UX by mělo být podloženo daty, ne jen intuicí.

💡 Příklad z praxe: UX audit veřejného webu úřadu

Krajský úřad chtěl redesign webu. UX tým provedl audit: eye-tracking test ukázal, že 73 % uživatelů hledá formuláře pro podání žádostí, ale navigace je skryta v submenu. Heuristická analýza podle Nielsena: 6 z 10 heuristik porušeno (chybí breadcrumbs, chybové zprávy formulářů jsou nesrozumitelné, mobilní verze nefunguje pro uživatele se čtečkou). WCAG 2.1 audit: kontrastní poměr textu jen 2,8:1 (požadavek 4,5:1), formuláře bez label elementů (screen reader nečte). Po redesignu: kontrastní poměr 7:1, all-keyboard navigace, clear error messages – skóre WCAG AA splněno, požadavek zákona 99/2019 splněn. Bounce rate klesl o 28 %.

⚠️ Časté záludnosti

❌ UX ≠ UI – UI (User Interface) je vizuální design tlačítek, barev, typografie; UX je celková zkušenost uživatele, zahrnuje i UI, ale i informační architekturu, rychlost načítání, onboarding a zákaznický servis.

❌ Přístupnost není jen pro menšinu – permanentní handicap má ~15 % populace, ale situační handicap (ruka v sádře, oslunění displeje, rušné prostředí) postihuje každého. Přístupný web je lepší pro všechny.

❌ GPL licence "infikuje" komerční projekty – pokud váš SW obsahuje GPL kód, celý projekt musí být vydán pod GPL. MIT/Apache 2.0 toto omezení nemají – jsou vhodné pro komerční použití.

❌ SLA 99,9 % neznamená žádné výpadky – 99,9 % uptime = 8,77 hodin výpadku ročně. Plánované výpadky (maintenance window) se do SLA typicky nezapočítávají.

🧩 Laicky: obchod jako UX

UX je jako celý zážitek z nákupu v obchodě – nejen jak vypadají police (UI), ale jestli najdete co hledáte, jestli je kasírka přívětivá, jestli je dostatek parking míst. Přístupnost je jako rampa pro vozíčkáře a Brailleovy etikety – bez nich část zákazníků do obchodu vůbec nevejde. WCAG AA je zákonná povinnost, ne "bylo by hezké mít". SLA je jako garance dostupnosti obchodu – "budeme otevřeni 99,9 % roku, jinak vám vrátíme peníze". GPL licence je jako recept se závazkem: pokud ho upravíte a budete prodávat, musíte zveřejnit i váš upravený recept. MIT licence je jako recept bez podmínek – dělejte si co chcete, jen nám říkejte, odkud recept pochází.

🎓 Napojení na DP

IT · 12

Počítačová grafika a multimédia: barevné modely, formáty pro uložení obrazové informace. Příklady formátů pro audio a video. Komprese.

🖼️ Rastrová vs. vektorová grafika

Rastrová grafika (bitmap/raster) = obraz složený z mřížky pixelů (pixel = picture element = nejmenší barevný bod). Každý pixel má přiřazenu barvu (hodnotu RGB nebo CMYK). Rozlišení v DPI (dots per inch = bodů na palec) nebo PPI (pixels per inch).

Výhody: fotorealistický výsledek, snadné editování fotografií
Nevýhody: ztráta kvality při zvětšování (pixelizace), velká velikost souboru
Použití: fotografie, digitální malba, web (rastrové obrázky)
Programy: Adobe Photoshop, GIMP, Affinity Photo

Vektorová grafika = obraz popsán matematickými křivkami (Bézierovy křivky), přímkami a tvaremi. Není závislá na rozlišení.

Výhody: nekonečná škálovatelnost bez ztráty kvality, malé soubory
Nevýhody: nevhodná pro fotografie, složité scény mají velké soubory
Použití: loga, ikony, ilustrace, tisk, animace
Programy: Adobe Illustrator, Inkscape, CorelDRAW

🎨 Barevné modely

RGB (Red, Green, Blue) = aditivní mísení (sčítáme světlo); používá se pro obrazovky, monitory, telefony. Hodnoty 0–255 pro každou složku; čistá bílá = (255,255,255), černá = (0,0,0). Hexadecimální zápis: #FF5733. ~16,7 milionu barev.
CMYK (Cyan, Magenta, Yellow, Key/Black) = subtraktivní mísení (odebíráme světlo od bílého papíru); používá se pro tisk. Hodnoty v %. Smícháním CMY nevznikne dokonalá černá → K (key = černá tiskárna). Každá tiskárna má trochu jiný CMYK gamutu.
HSB / HSV / HSL (Hue, Saturation, Brightness/Value/Lightness) = intuitivní model; Hue = odstín barvy (0–360°), Saturation = sytost (0–100 %), Brightness = jas (0–100 %). Snadné pro ruční výběr barvy.
LAB (CIELAB) – percepční model navržený tak, aby číselné rozdíly odpovídaly vizuálním rozdílům; používá se pro profesionální barevné korekce.
Gamut = rozsah barev, které dokáže zařízení reprodukovat; sRGB (web standard), Adobe RGB (fotografie), P3 (kino, moderní displeje).

📁 Obrazové formáty

Formát	Typ	Vlastnosti	Použití
JPEG/JPG	Raster	Ztrátová komprese, malý soubor	Fotografie na webu
PNG	Raster	Bezztrátová, průhlednost (alfa kanál)	Logo, UI prvky, screenshoty
GIF	Raster	Max 256 barev, animace, průhlednost	Jednoduché animace, memy
WebP	Raster	Google formát, 25–34 % menší než JPEG/PNG	Moderní web
AVIF	Raster	Ještě lepší komprese než WebP	Budoucnost webu
BMP	Raster	Nekomprimovaný, velký soubor	Windows systémové obrázky
TIFF	Raster	Bezztrátový, velký soubor	Profesionální tisk, archivace
RAW	Raster	Surová data z fotoaparátu	Fotografie (post-processing)
SVG	Vektor	XML, škálovatelný, animovatelný	Loga, ikony, ilustrace
PDF	Vektor+Raster	Přenosný dokument	Tisk, dokumenty

🎵 Audio a video formáty

Audio formáty:

WAV – nekomprimovaný, CD kvalita, velký soubor; Windows standard
FLAC (Free Lossless Audio Codec) – bezztrátová komprese, ~50 % menší než WAV; audiofily
MP3 (MPEG Audio Layer III) – ztrátová komprese, psychoakustický model (odstraní frekvence, které ucho neslyší); 320 kbps = velmi dobrá kvalita; standard pro hudbu
AAC (Advanced Audio Coding) – lepší kvalita než MP3 při stejném bitrate; Apple, YouTube, Spotify
OGG Vorbis – open source, dobrá kvalita; webové hry

Video formáty (kontejnery):

MP4 (H.264/H.265) – univerzální standard; H.265 (HEVC) = 2× lepší komprese než H.264
MKV (Matroska) – otevřený kontejner, podporuje více audio/sub stop
AVI – starý Microsoft formát, velký soubor, zastaralý
WebM (VP8/VP9/AV1) – Google open source pro web; AV1 = nejlepší komprese
MOV – Apple QuickTime formát

🗜️ Komprese dat – principy a algoritmy

Bezztrátová komprese (lossless) – po dekompresi jsou data identická s originálem. Vhodná pro texty, programy, kritická data.

RLE (Run-Length Encoding) – kóduje opakující se sekvence: "AAAABBBB" → "4A4B". Efektivní pro obrázky s plochami jedné barvy (BMP, GIF, FAX)
Huffmanovo kódování – frekvenční analýza symbolů; časté symboly = kratší kód (méně bitů), vzácné = delší kód. Základ ZIP, JPEG, DEFLATE
LZW (Lempel-Ziv-Welch) – slovníkové kódování; opakující se sekvence nahrazuje kódy; GIF, TIFF, PDF
DEFLATE = kombinace LZ77 + Huffman; základ ZIP, gzip, PNG, HTTP komprese
Brotli / Zstandard – moderní algoritmy pro HTTP komprese

Ztrátová komprese (lossy) – odstraňuje informace, které lidský vnímací systém přehlédne. Po dekompresi data nejsou identická.

JPEG komprese – DCT (Discrete Cosine Transform = diskrétní kosinová transformace); obraz rozdělí na bloky 8×8 px, vysoké frekvence (detaily) jsou redukovány; stupeň kvality 0–100
MP3 komprese – psychoakustický model; odstraní frekvence maskované hlasitějšími zvuky (maskování), zvuky pod prahem sluchu
H.264/H.265 video – predikce pohybu (motion estimation); ukládá jen rozdíly mezi snímky (I-frame = plný snímek, P/B-frame = rozdíl)

🎬 Multimédia – definice a kategorie

Multimédia vznikají spojením textu, obrázků, grafiky, zvuku, animace (případně videa a interaktivních prvků) za účelem zprostředkování určitého druhu informací. Jde o spojení různých typů dat na jednom nosiči.

Kategorie multimediálního obsahu:

Statická multimédia: text, obrázky (rastrové i vektorové), grafické prvky
Dynamická multimédia: zvuk, video, animace (snímky za sebou), interaktivní prvky

Základní charakteristiky multimédií: digitalizace (převod analogového obsahu na bity), komprese (zmenšení objemu dat), přenositelnost (stejný obsah na různých zařízeních), interaktivita (uživatel ovlivňuje průběh prezentace).

Využití: e-learning, prezentace, web, hry, digitální kino, VR/AR aplikace.

📐 Vektorové formáty – rozšířený přehled

Vektorová grafika = obraz popsaný matematickými objekty (křivky, přímky, plochy). Základ: PostScript (Adobe, 1982) – programovací jazyk popisující objekty na stránce; základ moderního tisku a PDF.

Formát	Původ	Použití
EPS (Encapsulated PostScript)	Adobe/PostScript	Tisk, vkládání vektorů do dokumentů
PS (PostScript)	Adobe	Přímé tiskové soubory, RIP tiskáren
AI	Adobe Illustrator	Loga, ilustrace, editace v Illustratoru
CDR	CorelDRAW	Grafický design, reklamní materiály
DXF	AutoCAD (Autodesk)	Technické výkresy, CAD/CAM
SVG	W3C (XML-based)	Webová vektorová grafika, ikony
VRML	ISO standard	3D scény a virtuální realita na webu

🎵 Audio a video formáty – rozšíření

Audio formáty dle kategorie komprese:

Kategorie	Formáty	Charakteristika
Nekomprimované	WAV, AIFF	CD/studiová kvalita; i ticho zabírá stejně místa jako zvuk; velké soubory
Bezztrátové	FLAC, WavPack, ALAC	Ticho nezabírá místo; ~50 % menší než WAV; pro audiofily
Ztrátové	MP3, AAC, M4A, OGG	Cílem je, aby komprese nebyla člověkem vnímatelná; psychoakustický model

AIFF = Audio Interchange File Format (Apple); WavPack = open source bezztrátový kodek s hybridním režimem.

Video formáty – kontejnery vs. kodeky:

MPEG-1 – VCD kvalita, 352×240 px; historický standard (1993)
MPEG-2 – DVD, DVB (digitální televize), Blu-ray; 576i/720p
MPEG-4 (H.264) – HD video; základ MP4 kontejneru; komprese 2× lepší než MPEG-2
H.265 (HEVC) – 4K/8K; 2× lepší komprese než H.264
WMV (Windows Media Video) – Microsoft; historicky pro Windows Media Player
AVI – starý Microsoft kontejner; velký soubor, zastaralý
MKV (Matroska) – otevřený kontejner; více audio/subtitle stop
WebM (VP9/AV1) – Google open source; optimalizovaný pro web

Kontejner (AVI, MKV, MP4) = obal nesoucí video, audio, titulky; kodek (H.264, AAC) = algoritmus komprese/dekomprese.

💡 Příklad z praxe: optimalizace obrázků pro webový e-shop

E-shop měl stránku kategorie s 48 produktovými fotkami, každá původně ve formátu PNG (průměrně 2,4 MB). Celková stránka = 115 MB – katastrofa pro mobilní připojení. Řešení: 1) Konverze PNG → WebP s bezztrátovou kompresí → průměrně 380 KB (−84 %). 2) Lazy loading (načítání obrázků až při scrollování). 3) Srcset atribut pro různá rozlišení (300w, 600w, 1200w). 4) CDN (Content Delivery Network) pro doručení z nejbližšího serveru. 5) Progresivní JPEG pro hero obrázky (nejdřív nízká kvalita, pak postupně zpřesní). Výsledek: LCP (Largest Contentful Paint) klesl z 8,2 s na 1,4 s, stránka na 14 MB, konverzní poměr mobil +19 %.

⚠️ Časté záludnosti

❌ RGB ≠ CMYK při přípravě pro tisk – monitor v RGB zobrazí živou oranžovou, ale tiskárna v CMYK ji nedokáže věrně reprodukovat. Grafici musí konvertovat a uvidí, co bude skutečně vytisknuto.

❌ PNG není vždy lepší než JPEG – pro fotografie je JPEG obvykle lepší (menší soubor při přijatelné kvalitě). PNG je lepší pro screenshoty, loga a UI prvky s ostrými hranami a transparentností.

❌ Ztrátová komprese je kumulativní – každé uložení JPEG znovu ztratí informaci. Pokud editujete fotku opakovaně, vždy pracujte s RAW nebo TIFF, JPEG exportujte jen na konci.

❌ Rozlišení pro web ≠ rozlišení pro tisk – web: 72–96 PPI stačí (displej má 96 PPI). Tisk: min. 300 DPI pro ostrost. Obrázek 1000×1000 px vypadá na webu dobře, ale vytisknout na A4 (21×29,7 cm = 3,3 pal.) = jen 303 DPI – na hraně.

🧩 Laicky: malíř vs. inženýr

Rastrová grafika = mozaika z dlaždic (pixelů) – zblízka vidíte každou dlaždici, z dálky krásný obraz. Přiblížíte-li, dlaždice se zvětší a obraz je kostičkovaný. Vektorová grafika = matematický popis ("čára od bodu A do bodu B, oblouk s poloměrem R") – ať tisknete na vizitku nebo billboard, vždy je ostrá. RGB = míchání světla reflektorů na divadelní scéně: červené + zelené + modré světlo = bílá. CMYK = tiskárna, která tiskne barvami na bílý papír a bílé místo nechává svítit skrz barvy. Huffman = Morseova abeceda, kde E (nejčastější písmeno) má jen jednu tečku, Q (vzácné) má 4 znaky. JPEG komprese = zatřese s obrazem a jemné detaily ze sítě vypadnou – nevadí, mozek si je domyslí.

🎓 Napojení na DP

IT · 13

Technologie na straně klienta: DHTML, DOM a jeho komponenty. CSS – preprocesory a frameworky. JavaScript – knihovny a frameworky, AJAX, JSON.

🌐 DHTML a DOM

DHTML (Dynamic HTML) = kombinace HTML + CSS + JavaScript + DOM, umožňující dynamické změny obsahu stránky bez nutnosti znovu načíst celou stránku. Pojem z late 90s, dnes se jednoduše říká "webový frontend".

DOM (Document Object Model = objektový model dokumentu) = stromová struktura reprezentující HTML/XML dokument v paměti prohlížeče. Každý element je uzel (node) ve stromě.

document
- html
  - head → title, meta, link
  - body → header, main, footer
    - div → p, span, a, img

JavaScript umí DOM manipulovat: document.querySelector(), .innerHTML, .addEventListener(), .appendChild(). Každá DOM manipulace může spustit reflow (přepočet layoutu) a repaint (překreslení) → performance implikace.

🎨 CSS – kaskádové styly

CSS (Cascading Style Sheets) = jazyk pro popis prezentace HTML dokumentu (barvy, fonty, rozložení). "Kaskádování" = více pravidel se aplikuje v pořadí specifičnosti (specificita selektoru) a pořadí v kódu.

Moderní CSS layout:

Flexbox – jednorozměrný layout (řádek nebo sloupec); ideální pro navigaci, karty, centrování
CSS Grid – dvourozměrný layout (řádky + sloupce); ideální pro komplexní rozvržení stránky
CSS Variables (custom properties) – --color-primary: #3B82F6; snadná úprava tématu
CSS animace – @keyframes, transition; hardwarově akcelerované přes GPU

CSS preprocesory – rozšiřují CSS o proměnné, vnořování, mixiny, funkce: Sass/SCSS (nejrozšířenější), Less, Stylus. Kompilují se do standardního CSS.

CSS frameworky: Bootstrap (grid systém, komponenty, utility třídy), Tailwind CSS (utility-first, inline třídy), Bulma, Foundation.

BEM (Block, Element, Modifier) = konvence pojmenování CSS tříd: .card, .card__title, .card--featured.

⚡ JavaScript – jazyk webu

JavaScript (JS) = dynamický, interpretovaný programovací jazyk pro web. Standardizován jako ECMAScript (ES); aktuálně ES2023+. Spouštěn v prohlížeči (V8 engine – Chrome/Node.js, SpiderMonkey – Firefox).

Klíčové ES6+ funkce: let/const, arrow functions, template literals, destructuring, spread operator, async/await, modules (import/export), Promises.

JavaScript frameworky/knihovny (front-end):

React (Meta) – komponentový, Virtual DOM, JSX, hooks; dominantní ekosystém
Vue.js – progresivní, snadné učení, Composition API
Angular (Google) – full-featured framework, TypeScript, dependency injection
Svelte – kompiluje do čistého JS bez runtime overhead

TypeScript = nadmnožina JavaScriptu s statickým typováním; kompiluje se do JS; odhalí chyby při vývoji, ne až za běhu.

Node.js = JS runtime na serveru (V8 engine); umožňuje spouštět JS mimo prohlížeč, tvorbu serverů, API, CLI nástrojů.

🔄 AJAX a asynchronní komunikace

AJAX (Asynchronous JavaScript and XML) = technika pro asynchronní komunikaci s serverem bez znovunačtení celé stránky. Dnes se název zachoval, ale XML je nahrazen JSON.

Moderní API pro síťové požadavky:

Fetch API – moderní, Promises-based: fetch('/api/data').then(r => r.json())
XMLHttpRequest – starší, callback-based
Axios – populární knihovna s interceptory a automatickým JSON parsováním

JSON (JavaScript Object Notation) = odlehčený datový formát: klíč-hodnota páry, pole, vnořené objekty. Lidsky čitelný, snadno parsovatelný. Příklad:

{
  "produkt": "Notebook",
  "cena": 24990,
  "tagy": ["elektronika", "pc"],
  "dostupnost": true
}

WebSockets – obousměrné trvalé spojení pro real-time komunikaci (chat, živé kurzy, online hry). Na rozdíl od AJAX: server může posílat data bez požadavku klienta.

PWA (Progressive Web App) – web aplikace s nativními vlastnostmi (offline, notifikace, instalace na plochu) přes Service Workers.

🏗️ CSS metodiky – organizace kódu

CSS metodiky = přístupy k psaní CSS kódu, které usnadňují jeho organizaci, čitelnost a údržbu ve větších projektech. Bez metodiky CSS rychle přeroste v nepřehledný "spaghetti" kód.

Metodika	Princip	Typické použití
BEM (Block, Element, Modifier)	Pojmenování tříd: `.card`, `.card__title`, `.card--featured`. Blok = komponenta; Element = část bloku; Modifier = varianta	Obecně nejrozšířenější; dobrá izolace komponent
SMACSS (Scalable and Modular Architecture for CSS)	Kategorizace pravidel do 5 typů: Base, Layout, Module, State, Theme. Každá kategorie má prefix (l-, is-, t-)	Větší projekty vyžadující jasné oddělení vrstev
OOCSS (Object-Oriented CSS)	Oddělení struktury od vzhledu (skin); znovupoužitelné "objekty" (komponenty) napříč projektem; minimalizace duplicity	Projekty s opakujícími se vzory UI
Atomic CSS / Utility-first	Každá třída dělá jednu věc: `.mt-4`, `.text-center`, `.flex`. Styl přímo v HTML bez custom tříd	Tailwind CSS; rychlý vývoj, snadná customizace
ITCSS (Inverted Triangle CSS)	Organizace dle specifičnosti: Settings → Tools → Generic → Elements → Objects → Components → Utilities. Nejspecifičtější pravidla na konci	Velké enterprise projekty

V praxi se metodiky kombinují – např. ITCSS struktura + BEM pojmenování.

🔧 JavaScript – knihovny, jQuery a WebAssembly

Knihovny vs. frameworky:

Knihovna – poskytuje konkrétní funkcionalitu, vývojář rozhoduje kdy a jak ji použít (volá knihovnu)
Framework – komplexní řešení, které řídí architekturu aplikace (framework volá kód vývojáře = Inversion of Control)

jQuery – historicky nejvýznamnější JS knihovna; zjednodušuje práci s DOM ($('#id').hide()), AJAX požadavky a cross-browser kompatibilitu. Dnes z velké části nahrazena nativním JS (ES6+) a moderními frameworky (React/Vue), ale stále používána na starších webech.

Alternativní jazyky pro klientskou stranu (transpilace do JS):

TypeScript – nadmnožina JS se statickými typy (nejrozšířenější)
Dart – Google; základ Flutter frameworku
CoffeeScript – čistší syntaxe, kompiluje do JS (méně populární)
Elm – funkcionální jazyk, nulové runtime chyby

WebAssembly (WASM) – nový nízkoúrovňový formát pro běh kódu v prohlížeči s výkonem blízkým nativní aplikaci. Kompilovat do WASM lze z C/C++/Rust/Go. Využití: hry, video editory, CAD aplikace v prohlížeči, výpočetně náročné úlohy.

💡 Příklad z praxe: React SPA s REST API

Firma vyvíjí e-shop jako SPA (Single Page Application) v Reactu. Při kliknutí na "Zobrazit detail" React Router přepne komponentu bez načítání stránky. Fetch API odešle GET požadavek na /api/products/42, server vrátí JSON s daty produktu. React aktualizuje pouze změněnou část DOM (díky Virtual DOM – diffing algoritmus porovná předchozí a nový stav, přepíše jen změněné uzly). TypeScript na front-endu zabrání type errorům (nelze přiřadit string tam, kde se čeká number). Celá aplikace je kompilována přes Vite/Webpack do optimalizovaných statických souborů (bundle splitting, tree shaking = odstraní nepoužívaný kód) a nasazena na CDN.

⚠️ Časté záludnosti

❌ JavaScript ≠ Java – jsou to dva zcela odlišné jazyky. Název je historická marketingová shoda (Netscape + Sun Microsystems, 1995). Java je kompilovaný, staticky typovaný jazyk pro JVM; JavaScript je interpretovaný, dynamicky typovaný jazyk prohlížeče.

❌ Přímá DOM manipulace v React je anti-pattern – React spravuje DOM sám přes Virtual DOM. Přímá manipulace (document.getElementById) obejde React a způsobí nekonzistentní stav. Správný způsob: refs (useRef).

❌ AJAX není zastaralý – i moderní React/Vue/Angular aplikace pod kapotou používají Fetch API (nástupce AJAX). Název přetrvává jako obecný termín pro asynchronní HTTP požadavky.

❌ CSS specificita matou – !important přebije vše, ale způsobí spaghetti CSS. Správné řešení: dodržovat BEM nebo CSS Modules pro izolaci stylů.

🧩 Laicky: orchestr a dirigent

DOM je jako partitury orchestru – každý nástroj (element) je na svém místě ve stromě. JavaScript je dirigent – může kdykoli říct houslistům "ztište" nebo klarinetistům "zahrajte toto". AJAX je jako tichý asistent za scénou, který nosí noty z tisku bez přerušení koncertu – stránka se nenačte znovu, jen se aktualizují data. React/Vue je jako chytrý dirigent s pamětí – pamatuje si, co bylo před chvílí, a přepíše jen ty strany, kde se nota změnila (Virtual DOM). TypeScript je jako dirigent, který odmítne vzít od tiskaře noty s chybami ještě před koncertem. Flexbox je jako seřazení hudebníků do jedné řady, CSS Grid je jako celý půdorys orchestřiště s přesně danými místy.

🎓 Napojení na DP

IT · 14

Technologie na straně serveru. Přehled řešení (proprietární, open source). Principy komunikace s databázemi, typy a příklady databázových řešení, architektura MVC. Webové služby, webové protokoly.

🖥️ Serverové technologie – přehled

Server-side technologie = kód běžící na serveru, zpracovává požadavky klientů, generuje odpovědi, komunikuje s databázemi. Klient (prohlížeč) vidí jen výsledek – HTML, JSON, binární data.

Populární serverové jazyky a frameworky:

PHP – nejrozšířenější pro web (WordPress, Laravel, Symfony); interpretovaný, integrovaný do Apache/Nginx
Node.js – JavaScript na serveru; event-driven, non-blocking I/O; Express.js, NestJS; ideální pro real-time aplikace
Python – čitelný, rychlý vývoj; Django (full-featured), Flask (lightweight), FastAPI (moderní async REST)
Java / Spring Boot – enterprise standard; silné typování, robustní; Spring MVC, Spring Security
Ruby on Rails – convention over configuration; rychlý vývoj, MVC out-of-the-box
Go (Golang) – kompilovaný, vysoký výkon, nízká paměťová náročnost; microservices, CLI
Rust – systémový jazyk, paměťová bezpečnost bez GC; WebAssembly

⚖️ Proprietární vs. open source

Proprietární řešení (komerční, uzavřený zdrojový kód):

Microsoft Azure (.NET/C#, Azure SQL, IIS)
Oracle (Java EE, Oracle DB)
IBM (WebSphere, DB2)
Výhody: komerční podpora, SLA záruky, certifikace
Nevýhody: licenční poplatky, vendor lock-in, závislost na dodavateli

Open source řešení:

Linux + Apache/Nginx + MySQL/PostgreSQL + PHP (LAMP/LEMP stack)
Node.js, Python, Ruby – vše open source
Docker, Kubernetes, Elasticsearch
Výhody: zdarma, velká komunita, transparentní kód, žádný vendor lock-in
Nevýhody: komunitní podpora (ne vždy), nutnost vlastní správy

🗄️ Relační vs. NoSQL databáze

Relační databáze (RDBMS = Relational Database Management System) – data uložena v tabulkách (relacích) s řádky a sloupci; schéma pevně definováno; dotazovací jazyk SQL (Structured Query Language).

MySQL – nejpopulárnější open source RDBMS; WordPress, e-shopy
PostgreSQL – pokročilý open source; JSON podpora, full-text search, geospatial (PostGIS)
Microsoft SQL Server – komerční, .NET integrace
SQLite – souborová DB, embedded aplikace, mobilní OS

Vlastnosti SQL DB: ACID (Atomicity, Consistency, Isolation, Durability), cizí klíče, JOINy, transakce.

NoSQL databáze – flexibilní schéma, různé datové modely; škálovatelné horizontálně:

Dokumentové: MongoDB (JSON/BSON dokumenty)
Klíč-hodnota: Redis (in-memory, cache, sessions), DynamoDB
Sloupcové: Cassandra, HBase (big data)
Grafové: Neo4j (vztahy mezi entitami, social networks)

🏗️ MVC architektura

MVC (Model-View-Controller) = návrhový vzor oddělující aplikaci do tří vrstev:

Model – data a business logika; komunikace s databází; neví nic o zobrazení
View – prezentační vrstva; šablony (template); zobrazuje data z Modelu; neřeší logiku
Controller – orchestrátor; přijímá HTTP požadavky, volá Model, předává data do View, vrací odpověď

Tok požadavku v MVC:

HTTP Request → Router → Controller
- Controller volá → Model (dotaz do DB)
- Model vrací data → Controller
- Controller předává data → View (šablona)
- View renderuje → HTTP Response (HTML/JSON)

Frameworky implementující MVC: Laravel (PHP), Django (Python), Spring MVC (Java), Ruby on Rails, ASP.NET MVC.

🔌 REST API vs. SOAP

Kritérium	REST	SOAP
Formát zpráv	JSON, XML, text	pouze XML (envelope)
Protokol	HTTP/HTTPS	HTTP, SMTP, TCP
Stav	Stateless (bezstavový)	Může být stavový
Výkon	Lehčí, rychlejší	Těžší (XML overhead)
Standardizace	Architekturní styl	Přísný standard (WSDL)
Bezpečnost	OAuth2, JWT, TLS	WS-Security (silná)
Použití	Moderní API, mobilní apps	Enterprise, bankovnictví

GraphQL – alternativa REST; klient přesně specifikuje, jaká data chce (žádné over/under-fetching); Facebook/Meta vyvinul pro mobilní aplikace.

🌐 Webové protokoly serveru

HTTP/HTTPS – základ webové komunikace; viz slide 9
SMTP (Simple Mail Transfer Protocol, port 25/587) – odesílání e-mailu
IMAP (port 143/993) – přístup k e-mailu na serveru
POP3 (port 110/995) – stahování e-mailu ze serveru
FTP (port 21) – přenos souborů (nešifrovaný)
SFTP / SCP (port 22) – šifrovaný přenos souborů přes SSH
SSH (Secure Shell, port 22) – šifrovaný vzdálený přístup k serveru (terminál)
DHCP (port 67/68) – automatická konfigurace IP adres
WebSocket (port 80/443) – obousměrná real-time komunikace

Webové servery: Nginx (event-driven, reverse proxy, load balancer, statické soubory), Apache (procesový model, .htaccess), Caddy (automatický HTTPS, moderní).

💡 Příklad z praxe: REST API pro mobilní aplikaci

Startupová fintech firma vyvíjí mobilní aplikaci. Back-end je Python FastAPI server s PostgreSQL databází, nasazený v Dockeru na AWS. Mobilní aplikace (React Native) komunikuje přes REST API: GET /api/v1/accounts/me vrátí JSON s údaji o účtu, POST /api/v1/transactions přidá transakci. Autorizace přes JWT (JSON Web Token) – po přihlášení server vydá signed token s expirací 1 hodina; klient ho posílá v Authorization headeru (Bearer TOKEN). Databáze PostgreSQL s ACID transakcemi zajistí, že bankovní převod se buď celý provede, nebo vůbec ne (atomicita). Výkonnostní bottleneck byl v N+1 query problému – vyřešen eager loadingem (SELECT JOIN místo N oddělených dotazů).

⚠️ Časté záludnosti

❌ NoSQL ≠ "bez SQL" – NoSQL znamená "Not Only SQL". Mnoho NoSQL databází má vlastní dotazovací jazyk. MongoDB má MQL (MongoDB Query Language). Volba NoSQL vs. SQL závisí na datovém modelu, ne na preferencích.

❌ REST ≠ HTTP – REST je architekturní styl (soubor principů), HTTP je protokol. REST API typicky používá HTTP, ale není to nutnost. Principy REST: bezstavovost, uniform interface, cacheable, client-server oddělení.

❌ MVC ≠ 3-vrstvá architektura – MVC je návrhový vzor pro organizaci kódu; 3-vrstvá (presentation/application/data) je fyzická architektura nasazení. V praxi se kombinují.

❌ ORM nezajistí výkon automaticky – ORM (Object-Relational Mapper, např. SQLAlchemy, Eloquent) zjednodušuje práci s DB, ale může generovat neefektivní SQL dotazy. N+1 problém je klasický příklad.

🧩 Laicky: restaurace jako server architektura

MVC = restaurace: zákazník (HTTP request) přijde, číšník (Controller) ho obslouží, jde do kuchyně (Model/databáze) pro ingredience, kuchař uvaří a číšník donese hotové jídlo (View/HTML). REST API = moderní jídelní lístek QR kódem – mobilní aplikace si objedná přes standardní interface a server vrátí jídlo (JSON). SOAP je jako staromódní telefon na objednávky – musíte dodržet přesný formát, ale máte garanci, že objednávka projde i do velkých firemních systémů. SQL databáze = tabulky v excelu, pevně definované sloupce; NoSQL databáze = krabice, kam dáte cokoliv ve formátu JSON. Redis = lednice v baru – nejpopulárnější položky jsou hned po ruce (cache), zbytek se musí jít do skladu (databáze).

🎓 Napojení na DP

IT · 15

Výpočetní model a jeho vývoj, Cloud Computing jako současný provozní model, taxonomie počítačových sítí, základní paradigmata počítačových sítí, proces konvergence.

💻 Vývoj výpočetních modelů

Výpočetní model = kde jsou aplikace uloženy a kde běží, jak jsou rozděleny a jak uživatel s nimi komunikuje. 8 historických etap:

Batch processing (dávkové zpracování) – historicky nejstarší; úkoly se řadily do front (batch = dávka), žádná interaktivita; výhoda: efektivní využití CPU
Host/Terminál – výkonný centrální počítač (host), uživatelé pracují přes terminály (vstup/výstup, bez vlastního výpočtu); sdílení strojového času (time-sharing)
Izolovaná PC – úplná decentralizace; každý počítač pracuje samostatně; GUI, myš; problém: sdílení dat a správa na více místech
File Server / Workstation – jeden server ukládá soubory (FS), pracovní stanice (WS) spouštějí aplikace; LAN; sdílené disky se jeví jako lokální
Klient/Server – aplikace rozdělena: serverová část pracuje s daty, klientská část zajišťuje UI; efektivní komunikace požadavek-odpověď; základ internetu (WWW, e-mail)

💻 Výpočetní modely – pokračování

PC vs. NC – Thick client (PC = Personal Computer = tlustý klient; předem instalované aplikace, vyšší výkon) vs. Thin client (NC = Network Computer = tenký klient; aplikace se stahují ze sítě v okamžiku potřeby; nízké HW nároky, jednoduchá správa – neujal se v 90s, ale dnes: Chromebook, VDI)
Network-centric – vše je v síti; stahování k uživateli (NC, webové aplikace, RIA = Rich Internet Application, streaming) nebo použití na dálku (aplikační servery = server-based computing); uživatelský počítač jen terminál
Cloud computing – moderní evoluce; služby poskytovány jako utilita (pay-per-use); data a aplikace virtualizovány a dostupné odkudkoli; IaaS/PaaS/SaaS; public/private/hybrid cloud

Trend: přechod od vlastnictví HW ke spotřebě služeb. "Otočím kohoutkem" (utility computing) = platím jen za spotřebované zdroje.

☁️ Cloud Computing – modely a typy

Modely "jako služba" (aaS = as a Service):

Model	Zákazník spravuje	Příklady
IaaS	OS, middleware, aplikace, data	AWS EC2, Azure VMs, GCP Compute
PaaS	Aplikace a data	Heroku, Google App Engine, Azure App Service
SaaS	Jen konfiguraci a svá data	Gmail, MS 365, Salesforce, Dropbox
FaaS	Funkce (kód)	AWS Lambda, Azure Functions

Typy nasazení: Veřejný cloud (sdílená infrastruktura, platba dle spotřeby), Privátní cloud (jen pro organizaci, vlastní HW nebo pronajatý dedicated), Hybridní (kombinace), Multi-cloud (více poskytovatelů pro resilience).

Výhody cloudu: dostupnost odkudkoli, elasticita (rychlé škálování), žádné CAPEX (Capital Expenditure = investice do HW), automatické zálohování, SLA. Nevýhody: závislost na internetu, vendor lock-in, bezpečnost dat u třetí strany, latence.

🌐 Taxonomie počítačových sítí

Taxonomie = klasifikace podle různých kritérií:

Podle dosahu:

PAN (Personal Area Network) – osobní zařízení, Bluetooth, NFC; ~10 m
LAN (Local Area Network) – budova, kampus; Ethernet, Wi-Fi; vlastní infrastruktura; 100 m – 1 km
MAN (Metropolitan Area Network) – město; např. síť Praha 5; 10 km+
WAN (Wide Area Network) – země, kontinenty; pronájem infrastruktury; CESNET (WAN pro VŠ ČR); 100 km+

Podle topologie: hvězda (star) – vše propojeno přes centrální switch; sběrnice (bus) – sdílené médium; kruh (ring) – token passing; strom (tree) – hierarchická hvězda; mesh – každý s každým (resilience).

Podle vlastnictví: privátní (LAN firmy), veřejná (internet), VPN (Virtual Private Network = šifrovaný tunel přes veřejnou síť).

Podle mobility: pevné (drátové Ethernet/optika) vs. mobilní (Wi-Fi, 4G/5G).

🔀 Paradigmata počítačových sítí

Telekomunikační paradigma – "chytrá síť, hloupé uzly"; základ: telefonní síť; přepojování okruhů (circuit switching) – před přenosem se vyhradí přímá linka; QoS (Quality of Service) garantováno; cloud computing s tenkými klienty a NC je moderní varianta.

Počítačové paradigma – "hloupá síť, chytré uzly (počítače)"; základ: internet; přepojování paketů (packet switching) – každý paket jde svou cestou; Best Effort (maximální snaha bez garance); IP je jednoduchý, efektivní; inteligenci mají koncová zařízení.

Přepojování okruhů (circuit switching): vyhrazené spojení po celou dobu hovoru; garantovaná kapacita; zbytek kapacity se vyplýtvá; typické pro telefonní síť.

Přepojování paketů (packet switching): data rozdělena na pakety; každý paket nese adresu cíle a jde vlastní cestou; kapacita sdílena; variabilní zpoždění; základ internetu (IP).

🔗 Konvergence sítí

Konvergence (convergence) = proces postupného splývání telekomunikační (hlasové) sítě a počítačové (datové) sítě do jedné IP sítě.

Proč konvergence: IP protokol je jednoduchý, efektivní a funguje nad jakýmkoli přenosovým médiem (IP over everything). Všechny aplikace fungují nad IP (everything over IP).

Příklady konvergence:

VoIP (Voice over IP) – telefonování přes internet (Skype, WhatsApp, MS Teams, SIP trunky ve firmách)
IPTV – televizní vysílání přes IP síť (O2 TV, Vodafone TV)
Video konference – audio + video + sdílení obrazovky přes IP (Zoom, Teams, Google Meet)
Unified Communications (UC) – integrace všech komunikačních nástrojů do jednoho systému

Historické pokusy o konvergenci (neúspěšné): ISDN (Integrated Services Digital Network), ATM (Asynchronous Transfer Mode) – oba příliš složité.

ISP hierarchie: Tier 1 (globální, peering), Tier 2 (regionální), Tier 3 (lokální). Problém poslední míle: jak fyzicky připojit koncového uživatele.

🖥️ ASP, VDI a DaaS – rozšíření výpočetních modelů

ASP (Application Service Provider = Poskytovatel aplikačních služeb) – historický předchůdce SaaS (90s, 2000s). Firma si místo nákupu SW pronajímala přístup k aplikaci provozované poskytovatelem přes internet (model klient/server nebo jednoduché webové aplikace). Předběhl dobu – neuchytil se kvůli pomalému internetu a bezpečnostním obavám. Dnes nahrazen SaaS.

VDI (Virtual Desktop Infrastructure = Virtuální desktopová infrastruktura) – virtuální pracovní plochy jsou provozovány na centrálním serveru organizace (vlastní řešení, ne cloudová služba). Uživatel se přihlásí z tenkého klienta nebo PC a dostane plnohodnotný vzdálený desktop.

Výhody: centralizovaná správa, snadná údržba a patching, bezpečnost dat (vše zůstává v datovém centru), snadná obnova po havárii
Nevýhody: nákladná serverová infrastruktura, závislost na síti, latence

DaaS (Desktop as a Service) – virtuální desktopy jsou umístěny v cloudu u poskytovatele a uživatelé je využívají na dálku. Na rozdíl od VDI nemusí organizace vlastnit a spravovat serverovou infrastrukturu.

Příklady: Amazon WorkSpaces, Azure Virtual Desktop (AVD), Citrix DaaS
Výhody: model pay-per-use, rychlé nasazení, elasticita, žádný CAPEX
Nevýhody: průběžné OPEX náklady, závislost na dostupnosti cloudu, bezpečnost dat u třetí strany

Model	Kde běží	Kdo spravuje infrastrukturu	Příklady
VDI	Vlastní datacentrum	Organizace	VMware Horizon, Citrix XenDesktop
DaaS	Cloud poskytovatele	Cloud provider	Azure Virtual Desktop, Amazon WorkSpaces
RDS/SBC	Vlastní server	Organizace	Windows Remote Desktop Services

☁️ Hosting a cloudové služby – typy

Hostingové služby = pronájem IT zdrojů u poskytovatele. Dělí se dle toho, co je sdíleno/pronajímáno:

File hosting – ukládání souborů (Dropbox, Google Drive, OneDrive, ownCloud)
Web hosting – provozování webových stránek na serveru poskytovatele (sdílený hosting, VPS, dedikovaný server)
Server hosting – pronájem celého fyzického nebo virtuálního serveru
Aplikační hosting – provozování aplikací na serverech poskytovatele (PaaS)
Server housing – umístění vlastního fyzického serveru do datacentra poskytovatele (colocation); zákazník vlastní HW, poskytovatel zajistí prostor, napájení, chlazení, konektivitu

Virtualizace = techniky umožňující přistupovat ke zdrojům jiným způsobem, než jakým fyzicky existují. Jeden fyzický server = desítky virtuálních serverů (VM). Základ cloudu. Typy: serverová virtualizace (VMware vSphere, Hyper-V), desktopová virtualizace (VDI), síťová virtualizace (SDN), storage virtualizace (SAN).

Utility Computing = platíte přesně tolik, kolik spotřebujete ("otočím kohoutkem") – základ cloud computingu. Umožňuje libovolně a rychle zvyšovat/snižovat využívané zdroje. Kontrast s tradičním nákupem HW = CAPEX (Capital Expenditure).

💡 Příklad z praxe: migrace firmy na hybrid cloud

Výrobní firma měla 15 fyzických serverů on-premise (privátní "cloud" = vlastní datacentrum). Analýza ukázala: ERP systém (kritická data, nesmí opustit EU) → zůstane on-premise. Webový e-shop (sezónní špičky 10× vyšší zátěž v prosinci) → přesun na IaaS (Azure VMs s auto-scaling). Firemní e-mail a kalendáře → přesun na SaaS (Microsoft 365). Výsledek: hybridní cloud architektura. ERP zůstal bezpečný, e-shop škáluje automaticky bez přenasazení HW, IT tým se nestará o Exchange server. Celkové náklady na IT klesly o 22 %, dostupnost e-shopu vzrostla na 99,95 %.

⚠️ Časté záludnosti

❌ Cloud ≠ outsourcing – cloud je technologický model (on-demand, self-service, elasticita), outsourcing je obchodní model (třetí strana spravuje IT). Mohou se překrývat, ale nejsou totéž.

❌ LAN ≠ Wi-Fi – LAN je síť na krátkou vzdálenost (může být drátová Ethernet nebo bezdrátová Wi-Fi). Wi-Fi je jen přenosová technologie v LAN.

❌ VPN nezajistí anonymitu – VPN šifruje provoz a skryje vaši IP před navštívenými weby, ale váš VPN provider váš provoz vidí. Anonymita (Tor) a soukromí (VPN) jsou různé věci.

❌ Packet switching vs. circuit switching confusion – circuit switching garantuje kapacitu (telefon), ale plýtvá zdrojem pokud linka mlčí; packet switching sdílí kapacitu efektivně, ale nezaručuje latenci (proto QoS = Quality of Service mechanismy v IP sítích).

🧩 Laicky: od sálového počítače k cloudu

Mainframe/batch = jedna výkonná pec, u které stojí fronta lidí se svými dávkami k upečení. Host/terminál = pec je stále jedna, ale každý má svůj dálkový ovladač. Izolovaná PC = každý si koupí vlastní troubu domů. File server = sdílená spíž s potravinami, ale trouba je u každého doma. Klient/server = centrální kuchař (server) vaří, zákazníci (klienti) si jdou jen vyzvednout hotové jídlo. Cloud = Foodora – nikdy nevlastníte kuchyni, platíte za každé jídlo, a kuchyně škáluje sama: přes Vánoce přidá 10 kuchařů (auto-scaling), v lednu je opět zmenší. IaaS = pronajmete si vybavenou kuchyni. PaaS = kuchyně i personál jsou tam, přinesete jen suroviny. SaaS = objednáte hotové jídlo s dovozem.

🎓 Napojení na DP

IT · 16

Základy datových komunikací, analogový a digitální přenos, modulace, multiplexing. Přístupové metody. Broadband – stav a rozvoj, drátové a bezdrátové technologie.

📡 Základy datových komunikací

Datová komunikace = soubor principů umožňujících přenos dat (informací zakódovaných do signálů) mezi zařízeními v sítích. Zahrnuje přípravu signálu k odeslání, řízení přenosu a zpracování na příjemci.

Analogový přenos – spojitý signál, jehož hodnota se plynule mění v čase (kontinuální vlna). Typické: hlas po analogové telefonní lince, FM rádio. Citlivý na šum – šum se zesiluje spolu se signálem.

Digitální přenos – data vyjádřena jako série bitů (0 a 1), reprezentovaných diskrétními napěťovými úrovněmi nebo světelnými pulsy. Odolnější vůči šumu; chyby lze detekovat a opravit. Je to standard pro moderní komunikaci.

Přenos v základním pásmu (baseband) – signál jde přímo na médium bez modulace; napěťové úrovně = 0/1; krátké vzdálenosti; Ethernet v LAN.

Přenos v přeloženém pásmu (passband) – signál je namodulován na nosnou frekvenci; umožňuje přenos na větší vzdálenosti nebo sdílení média více signály (FDM).

📻 Modulace – typy a principy

Modulace = proces, při němž se mění parametry nosného (carrier) harmonického signálu modulačním (informačním) signálem. Nosný signál má 3 parametry: amplitudu (výška vlny), frekvenci (Hz = kmity/sec) a fázi (posunutí vlny).

Analogové modulace:

AM (Amplitude Modulation) – mění se amplituda; AM rádio (střední/krátké vlny)
FM (Frequency Modulation) – mění se frekvence; FM rádio, lepší odolnost vůči šumu
PM (Phase Modulation) – mění se fáze; základem digitálních modulací

Digitální modulace:

ASK (Amplitude-Shift Keying) – digitální obdoba AM; optická vlákna
FSK (Frequency-Shift Keying) – digitální obdoba FM; starší modemy, RFID
PSK (Phase-Shift Keying) – digitální obdoba PM; BPSK (2 stavy), QPSK (4 stavy), 8PSK, 16PSK; GPS, satelitní komunikace
QAM (Quadrature Amplitude Modulation) – kombinuje ASK+PSK; QAM-16 = 4 bity/symbol, QAM-256 = 8 bitů/symbol; Wi-Fi (802.11ax = QAM-1024), ADSL, kabelový internet

Klíčové pojmy: Baud = modulační rychlost (počet změn signálu/sec); bit/s = přenosová rychlost; Modem (MODulátor+DEModulátor) = přenos digitálních dat po analogovém kanálu.

🔀 Multiplexing

Multiplexování = sdílení jednoho přenosového média více signály současně. MUX (multiplexor) kombinuje signály, DEMUX (demultiplexor) je na druhém konci odděluje. Cíl: maximálně efektivní využití přenosové kapacity.

FDM (Frequency Division Multiplexing = frekvenční dělení) – každý signál dostane svůj frekvenční kanál; analogové rádio/TV, kabelová TV, ADSL (upstream/downstream na různých frekvencích)
TDM (Time Division Multiplexing = časové dělení) – každý signál dostane svůj časový slot, střídají se; ISDN, T1/E1 linky, SDH optické sítě
WDM (Wavelength Division Multiplexing = vlnové dělení) – speciální FDM pro optická vlákna; různé barvy světla = různé kanály; DWDM (Dense WDM) = desítky až stovky kanálů v jednom vláknu; páteřní optické sítě
CDM (Code Division Multiplexing = kódové dělení) – každý signál má jedinečný kód; CDMA mobilní sítě (3G), GPS
OFDM/OFDMA (Orthogonal FDM) – moderní varianta FDM; Wi-Fi 5/6, LTE, DVB-T2 digitální televize

🚦 Přístupové metody

Přístupové metody (Media Access Control, MAC) = pravidla, jak více zařízení sdílí jedno přenosové médium bez kolizí (srážek dat).

CSMA/CD (Carrier Sense Multiple Access with Collision Detection) – před odesláním naslouchám; pokud detekuji kolizi, zastavím a čekám náhodnou dobu; klasický Ethernet (dnes nahrazen full-duplex switched Ethernet, kde kolize nevznikají)
CSMA/CA (Collision Avoidance) – před odesláním oznámím záměr (RTS/CTS); kolizím předcházím; bezdrátové sítě Wi-Fi (IEEE 802.11) – nelze detekovat kolizi, protože device nemůže zároveň vysílat a přijímat
Token Passing – právo vysílat má jen držitel "žetonu" (token); Token Ring (IEEE 802.5), FDDI; deterministické, bez kolizí, ale pomalejší
CSMA/BA (Bitwise Arbitration) – CAN bus (Controller Area Network); automobily, průmyslová zařízení
TDMA – přidělení časových slotů; mobilní sítě 2G (GSM), satelitní

🌐 Broadband – stav a technologie

Broadband (širokopásmové připojení) = vysokorychlostní přípojka (typicky >25 Mb/s dle EU definice).

Drátové technologie:

ADSL/VDSL – přes telefonní linku (kroucená dvojlinka); ADSL2+: stahování 24 Mb/s; VDSL2: 100+ Mb/s na krátkou vzdálenost
Optické vlákno (FTTH) – Fiber To The Home; rychlosti 1–10 Gb/s symetricky; nejkvalitnější; ČR pokrytí roste (60 % domácností plánováno do 2030)
Kabelová TV (CATV) – koaxiální kabel; standard DOCSIS 3.1: 10 Gb/s stahování; asymetrické (stahování > nahrávání)
Ethernet – 1G/10G ve firemních sítích

Bezdrátové technologie:

Wi-Fi (WLAN) – 2,4/5/6 GHz; Wi-Fi 6E: 9,6 Gb/s; dosah ~100 m
Mobilní sítě – 4G LTE: 100 Mb/s, 5G: 20 Gb/s; ubiquitní pokrytí
Satelitní – Starlink (LEO = Low Earth Orbit): 100–300 Mb/s, 20–40 ms latence; dostupný i v odlehlých oblastech
WiMAX – IEEE 802.16; 70 Mb/s, dosah km; nástupce DSL v oblastech bez infrastruktury

🔌 Fyzická přenosová média

Kroucená dvojlinka (twisted pair) – páry kroucených vodičů; STP (stíněná) vs. UTP (nestíněná); kategorie Cat5e (1 Gb/s), Cat6 (10 Gb/s do 55 m), Cat6a (10 Gb/s do 100 m); Ethernet, telefon, DSL
Koaxiální kabel (coaxial) – centrální vodič, izolace, stínění; odolný vůči elektromagnetickému rušení; kabelová TV, starší Ethernet (10BASE-2/5)
Optické vlákno (optical fiber) – přenos světelných pulsů skleněným nebo plastovým vláknem; SM (Single-Mode = jednovidové) – pro velké vzdálenosti (km); MM (Multi-Mode = vícevidové) – pro krátké vzdálenosti (datová centra); imunní vůči elektromagnetickému rušení, nízký útlum, obrovská přenosová kapacita
Bezdrátová média – rádiové vlny (Wi-Fi, mobilní sítě, Bluetooth), mikrovlny (point-to-point spoje, satelit), infračervené záření (IrDA, dálkové ovládání)

💡 Příklad z praxe: Wi-Fi 6E v podnikovém prostředí

Velké výrobní středisko s 500 zaměstnanci přecházelo z Wi-Fi 5 (802.11ac) na Wi-Fi 6E (802.11ax). Původní problém: 2,4 GHz pásmo přetížené (výrobní haly plné zařízení), rušení od mikrovlnných troub a motorů, propustnost 150 Mb/s celkem pro 200 zařízení. Wi-Fi 6E přidalo 6 GHz pásmo (nové, bez rušení, 1200 MHz šířky pásma), OFDMA (efektivní sdílení kanálu), BSS Coloring (redukce rušení od sousedních AP). Výsledek: propustnost 4,2 Gb/s, latence 2 ms, 500 zařízení najednou – IoT senzory, tablet zařízení a VoIP telefony bez rušení. Modemová infrastruktura: CSMA/CA s MU-MIMO (Multi-User MIMO) a TWT (Target Wake Time) pro IoT bateriová zařízení.

⚠️ Časté záludnosti

❌ Baud ≠ bit/s – Baud je modulační rychlost (změny signálu za sekundu). Při QAM-16 přenáší každý stav 4 bity → 1000 Bd = 4000 bit/s. Záměna způsobí zkreslení rychlosti přípojky.

❌ CSMA/CD vs. CSMA/CA – CD je pro drátový Ethernet (kolizi detekuje po výskytu a reaguje); CA je pro Wi-Fi (kolizi se snaží předejít, protože Wi-Fi zařízení nemohou současně vysílat a přijímat na stejné frekvenci).

❌ WDM ≠ FDM – WDM je speciální případ FDM pro optická vlákna, kde se rozlišují vlnové délky světla (barvy) místo rádiových frekvencí.

❌ Broadband ≠ jen rychlý Wi-Fi – broadband je jakékoli širokopásmové připojení (FTTH, DOCSIS, 4G/5G, satelit). Dial-up a základní ISDN broadband nejsou.

🧩 Laicky: dálnice a vlny

Modulace je jako vzkaz zakódovaný do mávání vlajkou: AM = mávám silněji nebo slaběji (amplituda), FM = mávám rychleji nebo pomaleji (frekvence), PM = začínám mávat v jiný okamžik (fáze). QAM kombinuje všechno najednou – jste jak rychlý, silný i časovaný mávač = přenese 8 bitů v jednom záchvěvu. Multiplexing je jako víceproudová dálnice: FDM = každé auto jede v jiném pruhu (frekvence); TDM = auta se střídají v jednom pruhu v přesném čase; WDM = optické vlákno jako dálnice, kde každá barva světla je jiný pruh. CSMA/CD je jako přetížená konferenční linka – nasloucháte, pak mluvíte, ale pokud dva mluví najednou, oba ztichnou a zkusí to znovu. CSMA/CA je jako zdvořilý Japonec – nejdříve řekne "smím mluvit?", počká na souhlas a pak teprve mluví.

🎓 Napojení na DP

IT · 17

Síťové modely a architektury – RM ISO/OSI a TCP/IP, koncepce, protokoly, standardizace, vrstvy a jejich základní úloha, hodnocení a srovnání.

📚 Proč potřebujeme referenční modely

Referenční model (reference model) = abstraktní rámec, který rozděluje složitou síťovou komunikaci do vrstev (layers). Každá vrstva plní přesně definovanou roli, komunikuje pouze se sousedními vrstvami (nad a pod sebou) a poskytuje služby vrstvě výše.

Výhody vrstvené architektury: nezávislý vývoj vrstev, snadné odhalení problémů (chyba je v konkrétní vrstvě), standardizace, interoperabilita (různí výrobci, ale standardní protokoly).

Zapouzdření (encapsulation) – každá vrstva přidá ke zprávě svou hlavičku (header) s řídícími informacemi. Na příjemci vrstvy hlavičky postupně odebírají (decapsulation). Název datové jednotky se mění: zpráva (message) → segment → paket → rámec (frame) → bity.

Dva hlavní modely: ISO/OSI (7 vrstev, teoretický standard) a TCP/IP (4 vrstvy, praktická implementace internetu).

🏛️ Referenční model ISO/OSI

ISO/OSI (International Standards Organization / Open Systems Interconnection) – navržen 1984, 7 vrstev. Model ze světa telekomunikací. Paradoxně se v praxi nepoužívá jako celek (prohrál souboj s TCP/IP), ale je výborný pedagogický nástroj. Vrstvy 1–3 = orientovány na přenos, 5–7 = orientovány na aplikace, 4 = most.

7 Aplikační – HTTP, FTP, SMTP, DNS; rozhraní pro aplikace
6 Prezentační – konverze dat (ASCII↔UTF-8), šifrování (TLS), komprese
5 Relační – správa relací/sezení; v praxi málo využívaná vrstva
4 Transportní – end-to-end přenos; porty; jen v koncových zařízeních
3 Síťová – pakety; IP adresy; směrování (routing); routery
2 Linková – rámce (frames); MAC adresy; přepínače (switches)
1 Fyzická – bity; kabely, konektory, huby; elektrické/optické signály

🌐 Architektura TCP/IP

TCP/IP = sada protokolů ze světa počítačů (ARPANET, 1970s). Základ celého internetu. Méně vrstev, pragmatičtější, důraz na jednoduchost a efektivitu. Principy: "IP over everything" (IP funguje nad jakýmkoli médiem) a "Everything over IP" (všechny aplikace fungují nad IP).

4 Aplikační vrstva – HTTP, HTTPS, FTP, SMTP, IMAP, DNS, DHCP, SSH, SNMP
3 Transportní vrstva – TCP (spolehlivý, spojovaný) a UDP (rychlý, nespojovaný)
2 Síťová vrstva (IP) – IPv4, IPv6, ICMP (ping), ARP, OSPF, BGP
1 Vrstva síťového rozhraní – Ethernet, Wi-Fi, PPP; vše co je "pod IP"

TCP (Transmission Control Protocol) – spojovaný (three-way handshake: SYN→SYN-ACK→ACK), spolehlivý (potvrzení, retransmise, řazení paketů), řízení toku (flow control) a zahlcení (congestion control). Použití: HTTP, FTP, SMTP, SSH.

UDP (User Datagram Protocol) – nespojovaný, nespolehlivý, bez handshake, minimální overhead. Rychlejší. Použití: DNS, DHCP, VoIP, video streaming, online hry, SNMP.

⚖️ ISO/OSI vs. TCP/IP – srovnání

Kritérium	ISO/OSI	TCP/IP
Počet vrstev	7	4
Původ	Telekomunikace (ITU, ISO)	Počítačové sítě (DARPA)
Přístup	Teoretický, normativní	Pragmatický, "funguje to"
Využití dnes	Výuka, terminologie	Základ celého internetu
L5+L6 OSI	Relační + Prezentační	Součást aplikační vrstvy
L1+L2 OSI	Fyzická + Linková	Síťové rozhraní (1 vrstva)
Paradigma	Telekomunikační (QoS)	Počítačové (Best Effort)
IP protokol	Není specifikován	Základ (L2 = IP)

Klíčový rozdíl: OSI L5 a L6 v TCP/IP nejsou implementovány jako samostatné vrstvy – jejich funkce (šifrování TLS, kódování UTF-8) jsou zabudovány přímo do aplikací nebo TLS knihoven.

🔑 Klíčové protokoly vrstev

Síťová vrstva (L3):

IP (Internet Protocol) – adresování a směrování; IPv4 (32 bit), IPv6 (128 bit); nespolehlivý, nespojovaný
ICMP (Internet Control Message Protocol) – chybové zprávy, diagnostika; ping (echo request/reply), traceroute
ARP (Address Resolution Protocol) – překlad IP adresy na MAC adresu v LAN
OSPF, BGP – směrovací protokoly (routing protocols); OSPF uvnitř AS, BGP mezi AS (páteř internetu)

Linková vrstva (L2):

Ethernet (IEEE 802.3) – dominantní LAN standard; CSMA/CD; rámce s MAC adresami
Wi-Fi (IEEE 802.11) – bezdrátový Ethernet; CSMA/CA
VLAN (Virtual LAN) – logické oddělení sítě na L2 (IEEE 802.1Q tag)

Transportní vrstva (L4):

TCP – porty 0–65535; spojovaný, spolehlivý
UDP – porty 0–65535; nespojovaný, rychlý
TLS/SSL – šifrování na transportní vrstvě (technicky mezi L4 a L7)

Aplikační vrstva (L7):

HTTP (80), HTTPS (443), FTP (21), SSH (22)
SMTP (25/587), IMAP (143/993), POP3 (110/995)
DNS (53 UDP/TCP), DHCP (67/68 UDP)
SNMP (161 UDP) – správa sítě
NTP (123 UDP) – synchronizace času

💡 Příklad z praxe: troubleshooting sítě pomocí OSI modelu

Uživatel hlásí "nefunguje internet". Síťový administrátor systematicky prochází vrstvy OSI zdola nahoru: L1 – fyzická: kabel zapojen? LED na portu switchě svítí? → OK. L2 – linková: ipconfig ukazuje MAC adresu, Ethernet připojen → OK. L3 – síťová: ipconfig ukazuje IP adresu 169.254.x.x (APIPA = automatická adresa bez DHCP → problém!). Zjištění: DHCP server nedostupný. ping 192.168.1.1 (gateway) selhává. Příčina: DHCP server crash. Řešení: restart DHCP serveru → uživatel dostane IP adresu → L4-L7 fungují automaticky. OSI model jako checklist ušetřil 30 minut hledání "náhodné" příčiny.

⚠️ Časté záludnosti

❌ TCP ≠ TCP/IP – TCP/IP je celá rodina protokolů (suite). TCP je jen jeden protokol z ní (transportní vrstva). IP je druhý klíčový protokol (síťová vrstva). Říkat "posílám přes TCP/IP" je správné jen jako generický termín pro internetovou komunikaci.

❌ IP je záměrně nespolehlivý – to není chyba! Spolehlivost zajišťuje TCP na vyšší vrstvě. Pokud by IP byl spolehlivý i TCP byl spolehlivý, duplikujeme funkcionalitu a přidáváme zbytečnou latenci. UDP to demonstruje: vynikající pro video, kde jeden ztracený paket nevadí.

❌ Switch ≠ Router – switch pracuje na L2 (MAC adresy, přepíná rámce uvnitř LAN); router pracuje na L3 (IP adresy, směruje pakety mezi různými sítěmi). Moderní L3 switch umí obojí.

❌ OSI vrstvy 5 a 6 jsou v TCP/IP "ukryty" – TLS šifrování (OSI L6 = prezentační) je v TCP/IP implementováno jako knihovna v aplikaci (knihovna OpenSSL), ne jako samostatná vrstva. Proto HTTP + TLS = HTTPS stále patří do L4/aplikační vrstvy TCP/IP.

🧩 Laicky: poštovní zásilka jako TCP/IP

Píšete dopis (aplikační vrstva: obsah). Vložíte do obálky s adresami a číslem zásilky (transportní vrstva: TCP = doporučeně s potvrzením; UDP = pohlednice bez potvrzení). Pošta ho označí poštovním kódem a zařadí do síťového systému (síťová vrstva: IP adresa). Kurýr ho fyzicky naloží do auta a přiveze (vrstva síťového rozhraní: Ethernet kabel). OSI model je jako 7-dílný manuál pro poštovní úředníky, kde každé oddělení přidá svůj razítek a zapíše do knihy. TCP/IP je jako moderní DHL – méně papírování, ale zásilka dorazí. Router je třídírna zásilek (vybere správnou cestu), switch je recepce v budově (doručí konkrétnímu příjemci ve stejné budově).

🎓 Napojení na DP

IT · 18

Vývoj mobilních sítí a komunikací, datové přenosy, sítě LTE, 5G a 6G, IoT a sítě, mobilní OS a aplikace, aktuální stav ČR a svět, vývojové trendy.

📱 Vývoj mobilních sítí – od 1G k 6G

Gen.	Rok	Tech.	Rychlost	Klíčová vlastnost
1G	1980s	AMPS	2,4 kb/s	Analogový hlas, snadné odposlouchávání
2G	1991	GSM	64 kb/s	Digitální, SMS, MMS, SIM karta
2.5G	1997	GPRS/EDGE	144 kb/s	Přepínání paketů, první mobilní data
3G	2001	UMTS/HSPA	14,4 Mb/s	Mobilní internet, videohovory
LTE	2009	LTE	100 Mb/s	Přechod k 4G, low latency
4G	2012	LTE-A	1 Gb/s	VoLTE, dominantní technologie ČR
5G	2020	NR	20 Gb/s	1 ms latence, masivní IoT, network slicing
6G	~2030	THz	1 Tb/s?	AI-native, THz frekvence, výzkum

Datové přenosy = přenos dat z jednoho zařízení na druhé; point-to-point nebo broadcast; dominantně bezdrátové. LTE jako mezistupeň (3,9G). 5G: až 20 Gb/s, latence <1 ms, podpora 1 mil. zařízení/km². 6G: ve výzkumu – kognitivní AI, THz pásmo, dosud nevyužité frekvence.

🌍 IoT – Internet věcí

IoT (Internet of Things = internet věcí) = síť fyzických zařízení (čidla, senzory, aktuátory, spotřebiče) schopných sbírat a vyměňovat data přes internet. Typické vlastnosti: omezený výkon CPU, nízká spotřeba energie, bezdrátová konektivita.

Síťové technologie pro IoT:

RFID (Radio Frequency Identification) – čip + čtečka; pasivní (bez baterie) nebo aktivní; dosah cm–m; supermarkety, vstupní karty, logistika
BLE (Bluetooth Low Energy) – dosah 10–100 m; baterie roky; chytré hodinky, fitness náramky, beacony
Zigbee / Z-Wave – mesh síť pro chytrou domácnost; dosah 10–100 m; interoperabilní standard Matter (Apple/Google/Amazon)
LPWAN (Low Power Wide Area Network) – LoRa/LoRaWAN, SigFox, NB-IoT (Narrowband IoT); dosah km, baterie roky; zemědělství, smart city, průmyslové senzory
MQTT (Message Queuing Telemetry Transport) – odlehčený publish/subscribe protokol nad TCP/IP; broker (zprostředkovatel) distribuuje zprávy; standard pro IoT komunikaci
Wi-Fi, 4G/5G – pro IoT zařízení s větším výkonem a potřebou rychlého přenosu

Aplikace IoT: chytrá domácnost, smart city, precision farming (zemědělství 2.0), průmysl 4.0 (IIoT), zdravotnictví (wearables), autonomní vozidla.

📲 Mobilní OS a aplikace

Mobilní OS = operační systém navržený specificky pro přenosná zařízení (telefony, tablety, chytré hodinky).

Android (Google) – open source (AOSP); jádro Linux; architektura ARM; Java/Kotlin; ~72 % světového trhu; fragmentovaný ekosystém (Samsung One UI, Xiaomi MIUI)
iOS (Apple) – uzavřený ekosystém; vrstvená architektura (Core OS → Core Services → Media → Cocoa Touch); Swift/Objective-C; ~28 % trhu; uniformní ekosystém, vyšší bezpečnost
Historické: Symbian (Nokia), Windows Mobile/Phone (Microsoft), BlackBerry OS

Typy mobilních aplikací:

Nativní – Kotlin/Java (Android), Swift (iOS); maximální výkon, plný přístup k HW; nutný samostatný vývoj pro každou platformu
Webové – responzivní web v prohlížeči; bez instalace, multiplatformní; omezený přístup k HW, nutnost internetu
Hybridní – HTML/CSS/JS zabalené do nativního kontejneru; React Native (JS → nativní komponenty), Flutter (Dart → GPU renderování), Ionic (WebView)

📊 Aktuální stav ČR a světové trendy

Pokrytí mobilními sítěmi:

95 % světové populace má přístup k mobilním sítím
85 % má přístup k 4G sítím
5G pokryto v 70+ zemích světa (2022); do konce 2023 plánováno pokrytí celé ČR 5G
ČR: 3 operátoři (T-Mobile, O2, Vodafone) + MVNO (virtuální operátoři)

Vývojové trendy:

5G private networks – soukromé 5G sítě pro výrobní závody (Industry 4.0)
Network slicing – virtuální "plátky" 5G sítě pro různé aplikace (emergency services vs. IoT vs. video)
V2X (Vehicle-to-Everything) – komunikace vozidel s infrastrukturou, 5G low latency
Starlink – satelitní internet (SpaceX LEO) dostupný kdekoliv na světě; 100–300 Mb/s, 20–40 ms latence
AI-native 6G – AI integrováno přímo do síťové architektury
Edge computing – výpočty blízko IoT zařízení, minimální latence

💡 Příklad z praxe: precision farming s LoRaWAN

Zemědělský podnik v Jihomoravském kraji (2 500 ha polí) nasadil IoT monitoring. 800 senzorů vlhkosti půdy, teploty a výšky hladiny podzemní vody – každý na baterii s životností 5 let. Komunikace přes LoRaWAN (dosah 8 km, přenosová rychlost 250 b/s – 50 kb/s, ale stačí pro kB dat ze senzorů). Data putují na server přes LoRa gateway, ukládají se do InfluxDB (time-series databáze pro IoT), vizualizovány přes Grafana dashboard. Systém automaticky odesílá MQTT příkazy zavlažovacím pumpám přes 4G gateway. Výsledek: úspora vody 23 %, výnos +8 %, pokrytí i oblastí bez 4G signálu. Celková cena systému: ~400 Kč/senzor + cloudový hosting.

⚠️ Časté záludnosti

❌ LTE ≠ 4G – technicky LTE (Long Term Evolution) je "3.9G" – nesplňuje původní IMT-Advanced specifikaci pro 4G (1 Gb/s). V praxi se ale LTE označuje jako 4G a LTE-Advanced jako "skutečné 4G".

❌ 5G není jen rychlejší 4G – 5G přináší kromě rychlosti nové capabilities: ultra-low latency (<1 ms), masivní počet připojených zařízení (mMTC), network slicing, private networks. To umožňuje nové use cases (autonomní vozidla, průmysl 4.0), ne jen rychlejší Netflix.

❌ IoT ≠ jen chytrá domácnost – chytrá domácnost je jen zlomek IoT. Průmyslový IoT (IIoT) v výrobě, zemědělství, logistice a zdravotnictví je mnohem větší segment.

❌ Flutter není hybridní app – Flutter kompiluje do nativního kódu (ne WebView), renderuje vlastním enginem (Skia/Impeller). Je blíže nativní aplikaci než Ionic (WebView).

🧩 Laicky: generace sítí jako generace aut

1G mobilní síť = Ford Model T: jezdí, ale analogový, pomalý, slyší vás kdekdo. 2G = první moderní auto: bezpečnější, SMS je jako klakson (jen text). 3G = auto s GPS a rádiem: poprvé dostanete informace z internetu za jízdy. 4G = Tesla Model 3: rychlé, spolehlivé, streamujete Netflix bez zadrhávaní. 5G = autonomní auto: nejen rychlé, ale i schopné komunikovat s každým semaforem, chodcem a jiným autem zároveň – to je network slicing a latence 1 ms. IoT je jako smart city – semafory, odpadkové koše, pouliční lampy, vše má svůj senzor a "mluví" spolu přes LoRa nebo 5G. MQTT broker je jako centrální dispečink, přijímá zprávy od všech a posílá příkazy zpět.

🎓 Napojení na DP

IT · 19

Síťové operační systémy – desktop systémy, MS Windows Server, Unix/Linux, NetWare/OES – charakteristika a architektura, systém zabezpečení a ochrana dat, správa systému, adresářové služby – LDAP, eDirectory, Active Directory, identity management.

🖥️ Síťové operační systémy – přehled

Síťový operační systém (NOS – Network Operating System) = OS specializovaný pro správu síťových zdrojů: uživatelů, počítačů, souborů, tiskáren, oprávnění a síťových služeb. Klíčový důraz: centralizovaná správa, bezpečnost, dostupnost 24/7.

Na rozdíl od desktopového OS: více uživatelů současně, správa vzdálených zařízení, autentizace a autorizace pro celou síť, adresářové služby.

🪟 Microsoft Windows Server

Hierarchická struktura – doménový řadič (DC = Domain Controller) s rolí AD DS spravuje doménu
Modulární architektura – role (Roles): File Server, Web Server (IIS), DNS Server, DHCP Server, AD DS, Hyper-V; Features jako RSAT, .NET Framework
Zabezpečení: integrovaný firewall (Windows Defender Firewall), šifrování EFS/BitLocker, Kryptografické funkce PKI, Group Policy
Výhody: snadná integrace s Windows desktopy, grafická správa (Server Manager, RSAT), komerční podpora
Nevýhody: licenční náklady, méně flexibilní než Linux, vendor lock-in

🐧 Unix / Linux servery

Open source, modulární architektura, vysoká flexibilita
Dominantní pro webové, databázové a cloudové servery
Distribuce: RHEL (Red Hat Enterprise Linux) + CentOS/AlmaLinux (klon), Ubuntu Server, Debian, SUSE Linux Enterprise Server
Zabezpečení: SELinux (Security-Enhanced Linux – mandatory access control), AppArmor, iptables/nftables (firewall), fail2ban, auditd
Správa balíčků: rpm/dnf (Red Hat), apt (Debian/Ubuntu), zypper (SUSE)
Silná konzolová (CLI) podpora, scripting (bash, Python)
Výhody: zdarma, stabilní, bezpečný, konfigurovatelný
Nevýhody: vyšší nároky na znalosti správce

📦 NetWare / OES a historické NOS

NetWare (Novell) – průkopník síťových OS (80s–90s); první s robustní správou síťových souborů a tiskáren; NDS (Novell Directory Services) = předchůdce LDAP
OES (Open Enterprise Server) – novější Novell produkt; podporuje Linux i Windows; stále existuje v některých organizacích
Dnes nahrazen Windows Serverem a Linuxem
Výhody (historicky): vysoká stabilita, rychlost
Nevýhody: omezená komunita, zastaralý ekosystém
Samba – open source implementace SMB/CIFS protokolu na Linuxu; umí fungovat jako DC (Domain Controller) pro Windows domény bez Windows Serveru

📁 LDAP – protokol adresářových služeb

LDAP (Lightweight Directory Access Protocol) = standardní protokol (RFC 4511) pro přístup a správu adresářových služeb. Adresář = speciální databáze optimalizovaná pro čtení (mnoho čtení, málo zápisů), ukládá informace o objektech v hierarchické stromové struktuře (DIT – Directory Information Tree).

Klíčové pojmy:

DN (Distinguished Name) – jednoznačné jméno objektu v hierarchii: cn=Jan Novák,ou=Users,dc=firma,dc=cz
CN (Common Name) – jméno objektu (celé jméno)
OU (Organizational Unit) – organizační jednotka (oddělení, divize)
DC (Domain Component) – část domény (firma → dc=firma, dc=cz)
Atributy (attributes) – vlastnosti objektu: mail, telephoneNumber, memberOf, userPassword

Porty: 389 (nešifrovaný LDAP), 636 (LDAPS = LDAP přes TLS). Operace: Bind (přihlášení), Search (dotaz), Add, Modify, Delete.

eDirectory (Novell/Micro Focus) – multiplatformní adresářová služba; hierarchická, LDAP kompatibilní; dnes méně rozšířena.

🔑 Active Directory

Active Directory (AD) – adresářová a identity management služba od Microsoftu, součást Windows Serveru od roku 2000. De facto standard v enterprise prostředí.

Klíčové komponenty AD:

AD DS (Domain Services) – adresářová databáze uživatelů, počítačů, skupin
AD CS (Certificate Services) – interní certifikační autorita (CA) pro PKI
AD FS (Federation Services) – SSO pro webové aplikace (SAML, OAuth2, OpenID Connect)
AD RMS (Rights Management) – ochrana dokumentů (Digital Rights Management)

Klíčové pojmy:

Doména (domain) – logická skupina počítačů a uživatelů se sdílenou bezpečnostní politikou
Forest (les) – kolekce domén sdílejících schéma a Global Catalog
GPO (Group Policy Object) – hromadné nastavení počítačů a uživatelů (software, bezpečnostní politiky, USB restrikce)
Kerberos – autentizační protokol; lístky (tickets) s expiací 8 hodin
NTLM – starší autentizace (backward compatibility)

Microsoft Entra ID (dříve Azure AD) – cloudová verze AD pro SaaS aplikace, hybridní prostředí, MFA, Conditional Access.

🔐 Identity Management

Identity management (IdM, správa identit) = soubor technologií a procesů pro správu digitálních identit v organizaci: kdo je kdo, co smí dělat, jak se přihlašuje.

Klíčové procesy:

Provisioning – automatické vytváření účtů při nástupu zaměstnance
Deprovisioning – zrušení přístupu při odchodu zaměstnance
Role review – pravidelný přezkum oprávnění (access recertification)
Audit trail – záznamy o přístupu k citlivým datům

Klíčové technologie IdM:

SSO (Single Sign-On) – přihlásíte se jednou, přístup ke všem systémům (Kerberos, SAML 2.0, OAuth 2.0, OpenID Connect)
MFA (Multi-Factor Authentication) – povinné pro citlivé systémy
RBAC (Role-Based Access Control) – oprávnění přidělena rolím, ne osobám
PAM (Privileged Access Management) – správa administrátorských oprávnění
Produkty: Okta, Microsoft Entra ID, Keycloak (open source), SailPoint, CyberArk (PAM)

💡 Příklad z praxe: automatizovaný onboarding v AD

Nový zaměstnanec nastoupí v pondělí. HR systém (Workday) odešle přes API notifikaci do Identity Manager (Microsoft Identity Manager). Ten automaticky vytvoří účet v Active Directory (OU=Zaměstnanci, skupiny dle oddělení), mailbox v Exchange/Microsoft 365, přístup do ERP systému (SAP) dle role "Finanční analytik". Administrátor dostane e-mail ke schválení. Po schválení zaměstnanec dostane přihlašovací údaje. Přihlásí se na doménový počítač – Kerberos ticket se vydá na 8 hodin. GPO automaticky připojí síťový disk \\fileserver\Finance, nainstaluje firemní VPN klienta a zablokuje USB. SSO přes Azure AD (SAML) ho přihlásí do Salesforce, SharePointu a Zendesku bez zadání hesla. Při odchodu stiskne HR systém "terminate" → vše se automaticky zablokuje do 1 hodiny.

⚠️ Časté záludnosti

❌ LDAP ≠ Active Directory – LDAP je protokol (standard, jak komunikovat s adresářem). AD je konkrétní implementace adresářové služby od Microsoftu, která LDAP používá jako jeden ze svých komunikačních protokolů (spolu s Kerberos, RPC). OpenLDAP je open source implementace LDAP serveru.

❌ AD DC ≠ DNS server – Domain Controller má roli AD DS (adresářové služby), ale AD intenzivně závisí na DNS (pro lokalizaci DC přes SRV záznamy). V praxi se DNS role instaluje na DC, ale jsou to dvě různé role.

❌ GPO se aplikuje v hierarchii – GPO se aplikuje v pořadí: Local → Site → Domain → OU (LSDOU). Pozdější GPO přepíše dřívější (pokud není "enforced" nebo "Block inheritance"). Záměna pořadí je klasická chyba administrátorů.

❌ Identity management ≠ jen správa hesel – zahrnuje celý životní cyklus identity (provisioning, deprovisioning, access review, audit), SSO, MFA, PAM. Správa hesel je jen jeden aspekt.

🧩 Laicky: škola a knihovna jako AD

Active Directory je jako kompletní evidence celé školy. Každý žák (uživatel) má průkaz (účet) s rodným číslem (SID). Ředitel (Domain Admin) rozhoduje o vše. LDAP je jazyk, kterým si sekretářka a kartotéka "povídají": "Hledám žáka jménem Novák v třídě 3.B (OU=3B,dc=skola,dc=cz)". GPO je školní řád rozeslaný automaticky všem – kdo smí do tělocvičny, kdo ne. Kerberos je turniket u vstupu – ráno vám vydá průkaz (ticket) platný celý den, nepotřebujete se znovu prokazovat u každých dveří. SSO = ten samý průkaz otevře učebnu, tělocvičnu, jídelnu i knihovnu. Identity Management je celý HR proces – nový žák dostane průkaz automaticky po zápisu, maturant ho vrátí při odchodu.

🎓 Napojení na DP

IT · 20

Informační – znalostní společnost. Stát v informační společnosti, Státní politika v elektronických komunikacích – Digitální Česko. Aktuální trendy a vývojové tendence.

📖 Informační a znalostní společnost

Informační společnost (information society) = společnost, ve které ICT (Information and Communication Technologies = informační a komunikační technologie) pronikly do všech oblastí společenského, ekonomického a kulturního života v takové míře, že zásadně mění společenské vztahy a procesy.

Charakteristiky:

Dominantní uchování informací v elektronické podobě
Rostoucí závislost na elektronizaci (práce, bankovnictví, zdravotnictví, vzdělávání)
Změny v pracovním prostředí (home office, gig economy, digitální nomádi)
Nárůst informačních zdrojů a toků nad možnosti tradičního zpracování

Znalostní společnost (knowledge society) – jde dál: nestačí mít přístup k informacím, je nutné je transformovat na znalosti a inovace. Klíče: celoživotní vzdělávání (lifelong learning), rozvoj kvalifikace, kritické myšlení. Znalostní ekonomika = motor hospodářského růstu 21. století.

Digitální propast (digital divide) = nerovnoměrný přístup k ICT a počítačová negramotnost; generační, geografická (venkov vs. město), socioekonomická. Snižování propasti = cíl EU i ČR.

⚖️ Přínosy a rizika informační společnosti

Přínosy	Rizika
Zvýšení kvality života, širší výběr služeb	Závislost na technologiích, výpadky
Podpora vzdělanosti a celoživotního učení	Dezinformace, fake news, deepfakes
Profesní flexibilita, práce odkudkoli	Kybernetické hrozby, kybernetická válka
Racionální řízení krizových situací	Ztráta soukromí, surveillance kapitalismus
Vyšší stabilita a bezpečnost infrastruktury	Prohlubování nerovností (digital divide)
Nová pracovní místa (IT sektor)	Automatizace = zánik některých povolání
Dostupnost státních služeb 24/7	Technologické překážky pro starší generaci

🏛️ eGovernment – elektronická veřejná správa

eGovernment = využití moderních elektronických nástrojů pro správu věcí veřejných. Cíle:

Usnadnit styk veřejnosti s úřady (úspora času, místa, papíru)
Zvýšit efektivitu veřejné správy
Snížit náklady (méně úředníků, méně papíru)
Dostupnost služeb 24/7, 365 dní
Transparentnost veřejné správy

Oblasti eGovernmentu v ČR:

Základní registry (ROBP – obyvatel, ROS – osob, RÚIAN – adres, RPP – práv a povinností) propojeny přes ISZR
Datové schránky – elektronická komunikace s úřady (od 2009); právní váha doporučeného dopisu
Czech POINT – kontaktní místa pro výpisy z registrů
eObčanka s čipem – elektronická identifikace (eIdentita), eIDAS; elektronický podpis
Elektronické zadávání veřejných zakázek (NEN – Národní elektronický nástroj)
e-Podatelny, elektronická správní řízení
Princip "once only" – stát nepožaduje data, která již má

🇨🇿 Digitální Česko a EU regulace

Digitální Česko = strategický plán ČR pro digitální transformaci ekonomiky a veřejné správy.

DIA (Digitální a informační agentura, 2023) – nová vládní agentura pověřená koordinací digitalizace; nastavuje standardy, metodiku, sdílení dat mezi úřady.

Strategické cíle: pokrytí celé ČR vysokorychlostním internetem (100 Mb/s do 2030), digitalizace veřejných služeb, kybernetická bezpečnost.

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) – koordinace kybernetické bezpečnosti ČR, regulátor pro strategickou infrastrukturu.

EU regulační rámec:

GDPR (General Data Protection Regulation, 2018) – ochrana osobních údajů; právo na výmaz, přenositelnost dat, povinné hlášení incidentů; pokuty až 4 % celosvětového obratu
eIDAS – elektronická identifikace a důvěryhodné služby; cross-border elektronický podpis
NIS2 (2022/2555) – kybernetická bezpečnost pro provozovatele klíčových služeb
AI Act (2024) – nařízení o umělé inteligenci; kategorizace AI systémů dle rizika
DSA (Digital Services Act) – regulace online platforem a obsahu
DMA (Digital Markets Act) – regulace velkých technologických firem (gatekeepers)

🔮 Aktuální trendy a vývojové tendence

AI a generativní AI – ChatGPT, Gemini, Claude; automatizace kreativních i analytických úloh; AI Act reguluje
Průmysl 4.0 – IIoT, digitální dvojčata (digital twins), kolaborativní roboti (cobots), prediktivní údržba
5G a privátní sítě – výrobní závody s private 5G, ultra-nízká latence pro robotiku
Edge computing – výpočty blízko zdroje dat (IoT gateway, MEC = Mobile Edge Computing); minimalizace latence
Kvantové počítače – Shorův algoritmus ohrozí RSA; post-quantum kryptografie (NIST standardy: Kyber, Dilithium)

Blockchain a Web3 – DeFi (Decentralized Finance), NFT, smart contracts; Ethereum, Solana
AR/VR/XR a Metaverse – rozšířená, virtuální a smíšená realita; Apple Vision Pro, Meta Quest
Green IT – energetická efektivita datových center (PUE – Power Usage Effectiveness); obnovitelné energie; uhlíková neutralita (AWS, Google, Microsoft = 100% RE do 2030)
Starlink LEO – satelitní internet kdekoliv; transformace připojení ve venkovských oblastech a na palubách lodí/letadel
Digitální euro – centrální bankou vydaná digitální měna (CBDC); ECB ve fázi výzkumu

💡 Příklad z praxe: Czech POINT a datové schránky v praxi

Citizen chce zřídit živnostenské oprávnění. Dříve: osobně na živnostenský úřad s vytištěnými formuláři, výpisem z rejstříku trestů (jiný úřad) a ověřenými kopiemi. Nyní: přihlásí se na portál gov.cz přes eObčanku s čipem (eIDAS = zaručená elektronická identita), vyplní formulář online. Živnostenský úřad přes ISZR si automaticky stáhne výpis z trestního rejstříku (systém ROS), adresu z RÚIAN, totožnost z ROBP – bez žádosti zákazníka ("once only" princip). Potvrzení přijde do datové schránky do 5 pracovních dní. Celá komunikace bez jediného papíru. Czech POINT na poště slouží pro ty bez eObčanky – vytisknou výpis na místě za 100 Kč/strana.

⚠️ Časté záludnosti

❌ Informační ≠ znalostní společnost – informační společnost je o přístupu k datům a jejich šíření (mám internet, mohu číst); znalostní jde dál – o tvorbě hodnot z dat pomocí vzdělání a inovací (rozumím, co čtu, a vytvářím nové znalosti).

❌ eGovernment ≠ jen webový portál – eGovernment je celý ekosystém (registry, datové schránky, elektronický podpis, integrace systémů, legislativa). Portál gov.cz je jen viditelná část.

❌ GDPR ≠ jen "cookie lišta" – GDPR je komplexní nařízení: právo na výmaz, přenositelnost dat, povinné hlášení incidentů do 72 hodin, jmenování DPO (Data Protection Officer) pro velké organizace, pokuty až 20 mil. EUR nebo 4 % celosvětového obratu.

❌ Digitální Česko ≠ DIA – Digitální Česko je strategický plán (cíle), DIA (Digitální a informační agentura) je výkonný orgán pověřený jeho realizací. DIA nahradila rozdrobenou koordinaci přes MVČR.

🧩 Laicky: vesnice vs. chytré město

Informační společnost je přechod ze staré vesnice (každý osobně na úřad, do banky, do knihovny) na chytré město: všechny služby z pohovky. eGovernment je starosta chytrého města, který říká: "Nechci, abyste chodili 5× na různá okénka – zajdete jednou (nebo vůbec) a vše si zařídíme my." Datová schránka je elektronická dveřní schránka od státu – pošta z úřadu chodí sem, má právní váhu doporučeného dopisu. Digitální propast je problém, že babička nemá chytrý telefon ani internet – bez pomoci se k žádným digitálním výhodám nedostane. GDPR je jako zákon o poštovním tajemství: nikdo nesmí otevřít vaše dopisy (data) bez vašeho svolení, a kdo to poruší, platí tučnou pokutu. DIA je jako nový ředitel digitalizace magistrátu, který konečně sjednotí 50 různých IT systémů do jednoho.

🎓 Napojení na DP

Obhajoba a prezentace diplomové práce

ℹ️

Prezentace DP

Zaměřit se na cíl, metodiku, dosažené výsledky a vlastní přínos. Max. 10 slidů včetně titulní strany. SZZ trvá průměrně 60 minut.

📋 Rámcový postup SZZ

1. Interní seznámení komise s materiály

2. Pozvání studenta, představení komisi

3. Úvodní slovo předsedy

4. Prezentace DP studentem (max 10 slidů)

5. Posudky vedoucího a oponenta

6. Stanovisko studenta k posudkům

7. Rozprava k DP

8. Zkouška z předmětů (II, PIS, IT)

9. Interní porada komise

10. Sdělení výsledků studentovi

⏱️ Praktické informace

čas SZZ trvá průměrně 60 minut

doklady Občanský průkaz nebo pas

s sebou Osnova prezentace, psací potřeby

oblečení Společenský oděv

Termíny 2025/2026:
Přihláška ke SZZ: do 31. 3. 2026
Odevzdání DP: do 31. 3. 2026

🎨 Design manuál

Design manuál & šablona komponent

Barevná paleta (CSS proměnné)

--accent-primary
modrá

--accent-secondary
fialová

--success
zelená

--warning
oranžová

--danger
červená

--tab-ii
II

--tab-pis
PIS

--tab-it
IT

--tab-dp
DP

--surface-color
povrch

--surface-hover
hover

Badges (inline štítky)

blue green purple orange

<span class="badge blue">text</span>
<span class="badge green">text</span>
<span class="badge purple">text</span>
<span class="badge orange">text</span>

Okruh badgy (záhlaví otázky)

II · 7 PIS · 3 IT · 15 DP

<div class="q-label"><span class="q-badge ii">II · 7</span></div>
<!-- třídy: ii | pis | it | dp -->

Alert / upozornění

ℹ️

Nadpis alertu

Popis nebo doplňující informace, na které chcete upozornit studenta.

<div class="alert alert-info">
  <span class="icon">ℹ️</span>
  <div>
    <h4>Nadpis</h4>
    <p>Text...</p>
  </div>
</div>

Karta (card)

🗒️ Název karty

Obsah karty – body, definice, klíčové pojmy. Karty lze řadit do mřížky grid-2 nebo grid-3 (pokud přidáte třídu).

zelená libovolné štítky uvnitř karty.

📊 Druhá karta

Každá karta má automatický hover efekt. Nadpis h3 se zobrazí v accent-primary barvě s oddělovačem.

<div class="grid-2">
  <div class="card">
    <h3>🗒️ Název</h3>
    <p>Text...</p>
  </div>
  <div class="card">...</div>
</div>
<!-- grid-2 = 2 sloupce, grid-3 = 3 sloupce -->

Prázdná šablona obsahu otázky (content-area)

Každá otázka má prázdný <div class="content-area">. Doplňte dovnitř libovolnou kombinaci karet, alertů, tabulek nebo prostého textu.

← Sem přijde váš obsah: karty, tabulky, bullet-listy, code bloky, alertY...

<!-- Příklad vyplněné content-area -->
<div class="content-area">
  <div class="alert alert-info">...</div>

  <div class="grid-2">
    <div class="card">
      <h3>Pojem A</h3>
      <p>Definice A...</p>
    </div>
    <div class="card">
      <h3>Pojem B</h3>
      <p>Definice B...</p>
    </div>
  </div>

  <div class="code-block">příklad kódu</div>
</div>

Srovnávací tabulka

Vlastnost	Varianta A	Varianta B
Řádek 1	✔ Ano	✘ Ne
Řádek 2	hodnota	jiná hodnota

<div style="overflow:hidden; border:1px solid var(--border-color); border-radius:.75rem;">
  <table class="comparison-table">
    <thead><tr><th>...</th></tr></thead>
    <tbody><tr><td>...</td></tr></tbody>
  </table>
</div>

Blok kódu / pseudokódu

-- příklad SQL
SELECT produkt, SUM(prodeje) AS celkem
FROM fakta
GROUP BY produkt
ORDER BY celkem DESC;

<div class="code-block">váš kód nebo pseudokód</div>

Všechny typy alertů

ℹ️

alert-info – informace

Neutrální doplňující informace, definice, kontext.

✅

alert-example – příklad / správně

Konkrétní příklad použití, správná odpověď, pozitivní výsledek.

⚠️

alert-trap – pozor / chyták

Časté chyby, záludnosti u zkoušky, výjimky z pravidla.

<div class="alert alert-info">    <!-- modrá -->
<div class="alert alert-example"> <!-- zelená -->
<div class="alert alert-trap">    <!-- červená -->
  <span class="icon">⚠️</span>
  <div><h4>Nadpis</h4><p>Text...</p></div>
</div>

Inline highlight blok (grid-1 alert alert-warning) – uvnitř karet

🗂️ Karta s highlight bloky uvnitř

Varianta modrá (default)

Definice, hlavní bod, klíčová informace.

Varianta oranžová

Upozornění, podmínka, výjimka.

Varianta zelená

Správný postup, výhoda, pozitivní aspekt.

Varianta červená

Chyba, zakázáno, nebezpečí.

<div class="hl-block">...</div>           <!-- modrá -->
<div class="hl-block hl-warning">...</div>  <!-- oranžová -->
<div class="hl-block hl-success">...</div>  <!-- zelená -->
<div class="hl-block hl-danger">...</div>   <!-- červená -->

Karta s barevným pruhem nahoře (border-top)

🧮 Modrá

border-top: 4px solid var(--tab-ii)

🏗️ Zelená

border-top: 4px solid var(--tab-pis)

🔴 Červená

border-top: 4px solid var(--danger)

🟡 Oranžová

border-top: 4px solid var(--warning)

Plurality diagram – horizontální boxy s ikonami

🅐

Varianta A

Krátký popis varianty A.

Doplňující detail.

🅑

Varianta B

Krátký popis varianty B.

Doplňující detail.

🅒

Varianta C

Krátký popis varianty C.

Doplňující detail.

<div class="plurality-diagram">
  <div class="plurality-box" style="border-color: var(--tab-ii);">
    <div class="icon-circle">🅐</div>
    <h4>Nadpis</h4>
    <p>Popis...</p>
  </div>
  <!-- další boxy -->
</div>

Decision tree / rozhodovací strom

🚀 Výchozí stav

❓ Rozhodnutí?

ANO

✅ Výsledek A

❌ Výsledek B

<div class="tree">
  <div class="tree-node">Výchozí stav</div>
  <div class="tree-line-v"></div>
  <div class="tree-node decision">❓ Rozhodnutí?</div>
  <div class="tree-row">
    <div style="display:flex; flex-direction:column; align-items:center;">
      <span class="tree-edge-label">ANO</span>
      <div class="tree-line-v"></div>
      <div class="tree-node success">✅ Výsledek A</div>
    </div>
    <div style="display:flex; flex-direction:column; align-items:center;">
      <span class="tree-edge-label">NE</span>
      <div class="tree-line-v"></div>
      <div class="tree-node danger">❌ Výsledek B</div>
    </div>
  </div>
</div>
<!-- tree-node třídy: (none)=modrý | decision=oranžový čárkovaný | success=zelený | danger=červený -->

Tabulka s barevnými buňkami (td-highlight / td-danger / td-warning)

Vlastnost	Varianta A	Varianta B	Poznámka
Vznik ochrany	Automaticky	Registrací	td-highlight = modrý
Riziko	Vysoké	Střední	td-danger / td-warning

<td class="td-highlight">modrý</td>
<td class="td-danger">červený</td>
<td class="td-warning">oranžový</td>

Emoji seznam (ul bez odrážek)

📋 Příklad karty s emoji listem

🔒 Nepřevoditelnost: nelze prodat ani darovat
⏳ Časové omezení: platí 70 let po smrti autora
🌍 Teritorialita: omezeno na území státu
❌ Výjimka: algoritmus samotný chráněn není

<ul style="list-style:none; margin:0; line-height:1.8;">
  <li>🔒 <strong>Klíčový pojem:</strong> popis</li>
  <li>❌ <span style="color:var(--danger)">Výjimka</span></li>
</ul>

CTA tlačítko (navigace mezi slidy)

<button class="btn-cta" onclick="showSlideById('slide-...')">
  📊 Název akce →
</button>

Mřížky – grid-2, grid-3, grid-4

🅐

grid-3 – 3 sloupce

🅑

gap: 1.25rem

🅒

responsive → 1 sloupec

<div class="grid-2">...</div>  <!-- 2 sloupce -->
<div class="grid-3">...</div>  <!-- 3 sloupce -->
<div class="grid-4">...</div>  <!-- 4 sloupce -->

1 / 20 –