====== N-INS 3. Data management, Architektury systémů ======
===== Zadání ====
// Data management - principy, koncepce zpracování dat. Architektura klient-server. Třívrstvá architektura. Konfederativní systémy.//
===== Vypracování =====
==== Data Management ====
**DAMA (Data Management Association)** -- organizácia zastrešujúca Data Management
Data management je široký pojem, ktorý sa dá rozdeliť do niekoľkých podtém:
* bezpečnosť dát (logovanie prístupov, správa užívateľov, šifrovanie...)
* kvalita dát (rozobraná nižšie)
* dátové sklady (ETL, OLAP/OLTP)
* metadata management
* database management (DBMS, správa DB)
==== Kvalita dat ====
Kvalita dat a následně kvalita informací se s rozvojem Internetu a podporou manažerských informací stává stále významnější.
**Co je kvalita, ISO 8402**
* Quality of an entity is a subjective concept dependent on requirements that the user of the entity requests in an implicit or explicit manner.
* Quality is a multidimensional concept tied to various characteristics.
**Atributy kvality (charakteristika dimense kvality)**
* Mají význam pokud možno pro řadu různých aplikací pracujících s danými daty, jsou použitelné obecně (např. rozptyl).
* Nejsou pokud možno přímo vázány na potřeby určité konkrétní aplikace (nejsou vstupem či parametrem algoritmů této aplikace).
**Proč se problém kvality dat (a informací) stává rozhodující**
* Bez vyřešení problému, jak data ukládat, vyhledávat a prezentovat, nemělo dříve řešení otázky kvality dat smysl.
* Je nutné zajistit nejen ochranu dat, ale také zajistit jejich kvalitu a zavést procedury jak jednat, není-li kvalita dat ideální
* Dat je mnoho a jsou na webu nutně všelijaká, přesto ale nejsou bezcenná
* Chyběly:
* metody a způsoby zápisu atributů kvality dat do metadat (např. [[http://cs.wikipedia.org/wiki/Resource_Description_Framework|RDF]]), nebyl dostatečně rozvinut pojmový aparát umožňující specifikovat různé aspekty a dimenze kvality dat
* vědomí důsledků statistických vlastností a jiných metrik kvality datových souborů pro aplikace využívající data určité kvality
* V managementu se musí používat data, která nejsou zcela spolehlivá a relevantní. Podpora managementu se stává hlavním úkolem informatiky.
**Míra**
* Kvantitativní indikace rozsahu, množství, dimenze, kapacity, nebo velikosti nějakého atributu
* Počet chyb
**Metrika**
* Kvantitativní míra úrovně po kterou je dosažen atribut kvality. “A handle or guess about a given attribute.”
* Počet chyb nalezených / manday
- **Příslušnost ke třídě** (například výskyt určitého znaku, třeba čísla tramvaje)
- **Fuzzy** (dobrý, lepší, nejlepší) – prvek uspořádané množiny, pro níž je jedinou přípustnou operací operace porovnání.
- **Intervalové** (například teplota).
- **Číselné** – jsou povoleny všechny aritmetické operace. Příkladem je rozsah souboru nebo jeho průměrná hodnota.
Metriky kvality dat jsou většinou fuzzy nebo číselné. Fuzzy metriky jsou subjektivní.
===Řízení kvality dat (informací)===
* Rozhodnutí o metrikách a procesech jejich měření (assessment) a nápravných opatřeních (control)
* Sběr a zlepšování jejich kvality (data cleaning)
* Odvozené procesy pro informace založené na zpracování daných dat
* Rozhodnutí o modernizaci nebo zrušení používaných metrik a postupů jejich měření
=== Objektivní metriky ===
* Objektivní metriky jsou metriky které lze vždy znovu vypočítat z dat, kterých se týkají.
* Jsou to často statistické charakteristiky datového souboru (rozsah souboru, průměr, rozptyl, výběrové momenty, např. Σixi3, korelace, atd.). Objektivní metriky jsou obvykle číselné.
* Objektivní metriky kvality dat odpovídají externím metrikám kvality softwaru ve smyslu ISO 9126-1 (např. délka programu)
* Často se používají při zlepšování kvality dat (Čištění dat).
=== Subjektivní metriky ===
* Subjektivní metriky jsou metriky hodnotící způsob, jakým data vznikla, případně kvalitu zdroje dat. Subjektivní jsou metriky hodnotící důvěryhodnost dat, stupeň jejich utajení, dostupnost, atd.
* Subjektivní metriky odpovídají metrikám interním ( in process metrics , např. doba řešení, pracnost) podle ISO 9126
* Jsou de de facto subjektivním hodnocením vlastností dat experty založeným na zkušenostech a nikoliv na měření v běžném slova smyslu.
* Pro zkvalitnění dat je i v tomto případě nutno specifikovat, či standardizovat proces „měření“, mnohdy zákonem. Často s použitím komplikovaných dotazníků.
=== Čištění dat ===
* **Okrajová data** (chyby měření) - ze souboru se vylučují data, která jsou zjevně nesprávná: úmyslně změněná, chybně zanesená (překlepy), nesprávného formátu.
* **Chybějící data** - do souboru se doplní chybějící data, aby bylo možno soubor rozumně zobrazovat (například časové řady) a přitom nedošlo k chybným výsledkům (k významným změnám charakteristik daného souboru).
* **Vyloučení duplicitních dat**
* **Sjednocení formátů**
* A další
==Nejčastěji používané atributy kvality dat==
* **Relevantnost** (Relevance) – míra, do jaké míry data splňují účel, pro který jsou používána, týkají se daného problému.
* **Přesnost** (Accuracy) – jak přesná jsou používaná data (např. směrodatná odchylka). Kupodivu se neuvažují posunutá data
* **Včasnost** (Timeliness) – za jakou dobu lze data aktualizovat, jak jsou data aktuální.
* **Dostupnost** (Accessibility) – jak jsou již existující data dostupná. Obtížný problém díky nesmyslným předpisům pro ochranu privátních dat
* **Porovnatelnost** (Comparablity) – metrika hodnotící možnost porovnávat, ale také spojovat data z různých zdrojů.
* **Koherence** (Coherence) – metrika vyjadřuje, do jaké míry byla data vytvořena podle, z hlediska výsledku, kompatibilních pravidel
* **Úplnost** (Completeness) – metrika udávající jaká část potenciálních dat je zachycena v databázi, případně, zda výběr dat pokrývá „rovnoměrně“ celý výběrový prostor
==Problémy s kvalitou dat při dolování dat a na webu==
* Daná míra((míra je v tomto textu pravděpodobně zaměnitelná s metrikou, viz "Míra a metrika")) má pro různé zdroje různé hodnoty
* Daná míra je i různě vyhodnocována (jiné procedury vyhodnocování)
* Daná míra se na některých zdrojích vůbec nevyhodnocuje
* Je pro nás lepší soubor s milionem údajů a rozptylem 2 nebo soubor s 100 údaji a rozptylem 1? Má smysl tyto soubory spojit?
----
----
==== Architektura ====
* Struktura systému ve velkém. Komponenty, jejich vlastnosti a spolupráce a rozhraní navenek
* Dekompozice na nejvyšší úrovni do kooperujících částí (pokud možno autonomních), skládání komponent do sítí-sestav-vrstev
* Systém může mít různé architektury z hlediska HW, logiky a fyzické dekompozice softwaru
* Architektura ovlivňuje uživatelské vlastnosti systému, dostupné operace, techniky specifikací a metodologii vývoje
* Většinou prostředek dekompozice, porozumění, analýzy (např. konzistentnost a kvalita návrhu)
* Důležité pro
* Zvládnutí vývoje
* Znovupoužitelnost částí
* Údržbu
* Dostupnost některých manažerských operací
* Podporu decentralizace ...
* Usnadňuje řízení (procesy, malé etapy, inkrementální vývoj, minimální rozsah, rozšiřování)
----
====Architektura klient – server====
Společná správa dat a aplikací
**Charakteristika klienta**
* Aktivní
* Posílá žádosti serveru
* Čeká a dostává odpovědi
* Obvykle je připojen k malému počtu serverů najednou
* Obvykle komunikuje přímo s koncovými uživateli, pomocí grafického uživatelského rozhraní
**Charakteristika serveru**
* Pasivní
* Naslouchá na síti a reaguje na žádosti připojených, autorizovaných klientů
* Při přijetí požadavku jej obslouží
* Může vzdáleně instalovat/odinstalovat aplikace a přenášet data ke klientům
{{:mgr-szz:in-ins:3-datamanagementklientserver.jpg|}}
===Srovnání s Peer-to-peer architekturou===
Další typ síťové architektury se nazývá Peer-to-peer, nebo taky zkráceně P2P. U této architektury může každý hostitel nebo instance programu fungovat zároveň jako klient i jako server (mají rovnocenné postavení i zodpovědnost).
===Výhody tenkého klienta:===
* Úspory nákladů na hardware klientů
* Snazší správa
* Bezpečnost
* Méně záplat
* Méně příležitostí k flákání hraním her
* Lepší kontrola práce (nesmí se ale přehánět)
* Snazší upgrade
===Nevýhody tenkého klienta:===
* Výpadek centrálních služeb znamená totální výpadek systému
* Některé služby mohou být lépe proveditelné lokálně.
* Neochota zvládat nové a cena přechodu na novou architekturu
* Ztráta lokální prestiže (odpovědnost je na centru)
* Obtížnější outsourcing (viz ale servisní orientaci)
* U systémů s několika málo klienty neefektivní
----
==== Třívrstvá architektura ====
Druh klient-server architektury často používaný u webových aplikací.
** Prezentační vrstva**
Zobrazuje informace pro uživatele, většinou formou grafického uživatelského rozhraní, může kontrolovat zadávané vstupy, neobsahuje však zpracování dat.
** Aplikační vrstva (též Business Logic)**
Zde leží jádro aplikace, její logika a funkce, výpočty a zpracování dat.
** Datová vrstva**
Tuto vrstvu tvoří nejčastěji databáze, která data uchovává, zpřístupňuje a zaručuje jejich konzistenci. Může zde být ale také (síťový) souborový systém, webová služba nebo jiná aplikace.
{{:mgr-szz:in-ins:3-datamanagementtrivrstvaarch.jpg|}}
===Spoje s jinými systémy===
* Spoje na aplikační vrstvu jsou nejbezpečnější, poskytuje přístup k funkcím partnera, avšak jsou málo flexibilní neboť umožňují jen to, s čím tvůrce počítal
* Spoj na datovou vrstvu je flexibilnější, neposkytuje ale funkce partnera a je riskantnější, i když ne příliš.
* Spoj na DB závisí na konkrétní implementaci, mohou být proto problémy s přenositelností, a je velmi riskantní (pokud není omezen na čtení)
===Architektura MVC===
* architektura Model-View-Controller vychází z třívrstvé architektury, ale lépe odpovídá aktuálním technologiím a trendům moderních webových aplikací
* systém dělí na 3 logické celky, které jsou podobné vrstvám třívrstvé architektury.
* má jednoduchou a lehce pochopitelnou strukturu, která ale může vést k nesprávnému použití
{{:mgr-szz:in-ins:3_mvc.jpg|}}
* jednotlivé vrstvy se ovlivňují jen minimálně, takže např. změny ve vzhledu aplikace by neměly ovlivnit funkčnost ani datové schéma. Tím je usnadněn vývoj i následná údržba systému.
* důležité je i provázání komponent:
* existuje přímá vazba mezi Controllerem a Modelem (Controller upravuje data Modelu)
* dále mezi View a Modelem (View zobrazuje data Modelu)
* často bývá i vazba mezi Controllerem a View v tom smyslu, že Controller informuje View o změnách.
* **nikdy** by ale neměla být vazba z Modelu na ostatní dvě komponenty
==Model==
* tvoří datovou vrstvu a business logiku (doménovou logikou)
* neřeší formu ukládaných dat (relační DB, objektová DB, XML souborech apod.)
* business logika představuje funkce pro manipulaci s uloženými daty, základní operace, výpočty, business pravidla, validační kritéria atd.
==View==
* představuje uživatelské rozhraní, pomocí kterého uživatel interaguje se systémem
* zobrazuje data požadovaným způsobem
* lze definovat různé pohledy na stejná data (např. tabulka nebo graf), různé barevné profily, profily s ohledem na výstupní zařízení (malá obrazovka PDA vs. velká obrazovka monitoru) apod.
==Controller==
* obsahuje kód, který řídí procesy uvnitř aplikace
* stará se o realizaci funkčních procesů a o správné provázání ostatních komponent aplikace do jednoho funkčního celku
* Příklad: Pokud dojde k zadání nových dat ve View, musí se postarat o jejich zpracování Modelem a následnou aktualizaci (překreslení) těch View, které jsou na nových datech závislé.
** Příklad interakce uživatele s MVC systémem:**
- Uživatel vykoná akci v uživatelském rozhraní.
- Akce je zachycena Controllerem, který promítne změny do modelu. Controller nebo Model informuje View.
- View aktualizuje uživatelské rozhraní a promítne tak provedené změny zpět uživateli.
----
====Service Oriented Architecture====
**Definice SOA dle [[http://en.wikipedia.org/wiki/OASIS_(organization)|OASIS group]]**
//A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.//
* Klíčové paradigma současného softwaru
* Komponenty spolupracují předáváním zpráv
* Základní styl komunikace je asynchronní, sekvenční je nadstavba
* Virtuální síť p2p velkých volně spolupracujících autonomních komponent, spolupráce podobná spolupráci služeb v reálném světě,
* Služby jsou většinou stále k dispozici, asynchronně reagují na požadavky z různých zdrojů, jsou používány jako černé skříňky
* Enterprise service bus, NetWeaver, Web services, semantic web, Composite applications, assembled applications
====Konfederativní systémy====
**ALIANCE**
* Na začátku komunikace se partner musí vyhledat. Typické pro e-komerci, reservační systémy atp. Je nutné pužívat celosvětové standardy
**KONFEDERACE**
* Partneři jsou zpravidla známi. Široká paleta aplikací, historicky nejstarší SOA systémy (soft RT systémy, e-government, řízení globálních společností, výrobní systémy, koalice podniků a zdrav. zařízení). Protokoly komunikace mohou být proprietární
* Komunikace může být i jiného typu, než výměna zpráv založená na internetu
** UNIE **
* Konfederace ve které musí být rozhraní služeb uživatelsky orientováno
==Konfederace volné a úzce vázané, otevřené a uzavřené:==
* IS podniku, části musí poslouchat centrum a systém není extrémně velký, typická oblast použití pro Enterprise Service Bus ESB (může být synchronní)
* IS státní správy nebo globálního podniku, části jsou téměř nezávislé – unie
* Řídící systém menší technologie - Menší komponenty, programátorské rozhraní, uzavřenost
Klíčová výhoda konfederací – rozhraní služeb může být uživatelsky orientováno, variantu konfederace, kde musí být rozhraní uživatelsky orientováno (podniky) nazveme **unie**.
==Příklady konfederativních SOA od nejvolnějších vazeb k nejtěsnějším:==
* E-komerce
* Informační systém státní správy
* Spolupráce zdravotnických zařízení
* Možná implementace [[http://cs.wikipedia.org/wiki/CRM|CRM]], [[http://cs.wikipedia.org/wiki/SCM|SCM]]
* Informační systém globálního podniku
* Lokální divize globálního podniku, menší podnik.
* Řízení procesů (soft real-time)
* OO aplikace
==Proč konfederace==
* Chceme-li použít uživatelsky orientované nebo existující rozhraní a middleware jiný než webovský
* Propojování systémů různých zdrojů
* Existující aplikace, vývoj, třetí strany
* a různých vlastníků,
* Organizační subsystémy, decentralizace
* Spolupráce samostatných podniků
* a různých technologií a úkolů
* Příliš velký systém na monolit
* Chceme inteligentní rozhraní, a někdy i dávkové techniky
{{:mgr-szz:in-ins:3-datamanagementkonfederace.jpg|}}
A – aplikační služba,
B – její rozhraní (primární brána)
UR je uživatelské rozhraní, např. portál
==Kdy použít SO==
* Jako prostředek podpory distribuovanosti
* Jako prostředek dekompozice na daném místě, v daném počítači
* Jako prostředek sdružování kapacit (gridovské systémy, viz projekt CETI ([[http://setiathome.berkeley.edu/|SETI@home]] ?))
* Podpora inkrementálního vývoje a jiné SW inženýrské výhody, např. znovupoužitelnost, kombinace produktů různého původu
* Podpora otevřenosti, CRM a SCM
* Aby to vůbec šlo napsat (Neexistence SOA v sedmdesátých létech byla jedním z důvodů krachu projektu protiraketové obrany SALT). Velký systém musí být budován po částech.
* Spolupráce existujících systémů které je lepší použít tak jak jsou (nelze je rychle přepsat, politika, autonomní systémy)
==Výhody SOA==
* **Chyby zůstanou lokalizované**, modernizaci lze provádět po částech
* Stávající systémy mohou sloužit nadále bez podstatnějších změn, lze integrovat produkty třetích stran
* **Flexibilita**: Produkt se dá snadněji upravit pro trošku jiné účely
* **Škálovatelnost**: Lze snadno doplňovat nové služby a také je klonovat
* **Autonomie částí** zvětšuje odolnost systému proti výpadkům
* Dosavadní uživatelé existujících služeb jim mohou věřit, protože se v podstatě neměnní. Nemusí se učit příliš nového a mohou důvěřovat i datům.
* **Úspory nákladů** z důvodů znovupoužitelnosti, použití produktů třetích stran a snadnějšího vývoje všeobecně
===== Předměty =====
[[https://is.muni.cz/auth/predmet/fi/podzim2011/PA102|FI:PA102]] - Technologie IS I.
[[https://is.muni.cz/auth/predmet/fi/jaro2012/PA105|FI:PA105]] - Technologie IS II.
===== Použitá literatura =====
{{:mgr-szz:in-ins:3-datamanagement_prednsoa08.ppt|TIS I. - SOA}}
{{:mgr-szz:in-ins:3-datamanagement_kvalitadat08.ppt|TIS I. - Kvalita Dat}}
{{:mgr-szz:in-ins:3-datamanagement_technologieis08.ppt|TIS I. - Technologie IS }}
[[http://cs.wikipedia.org/wiki/Klient-server|CS Wikipedie - Klient-Server]]
[[http://cs.wikipedia.org/wiki/V%C3%ADcevrstv%C3%A1_architektura|CS Wikipedie - Vícevrstvá architektura]]
===== Přílohy =====
{{:mgr-szz:in-ins:3.pdf|}} -- rozšíření některých témat a soukromé zpracování, vycházelo se z této wiki na přelomu roku 2013/2014. Nekonzultováno s kantory.
===== Vypracoval =====
Ondřej Božek - ICQ: 148979645
stav - cca 99%, je potřeba nějaká kontrola
Nejsem si jistý tím "Data management - principy, koncepce zpracování dat."
Jediné co se mi zdálo relevantní je zmíněná Kvalita dat.
==Changelist==
30.1.2012 - přidána definice SOA, drobné doplnění odkazů a textu
31.1.2012 - definice metriky a míry
~~DISCUSSION~~