====== 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~~