N-INS 3. Data management, Architektury systémů

Data management - principy, koncepce zpracování dat. Architektura klient-server. Třívrstvá architektura. Konfederativní systémy.

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 a následně kvalita informací se s rozvojem Internetu a podporou manažerských informací stává stále významnější.

• 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ř. 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.

• 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 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 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ů.

• 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ší

• 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

• Daná míra²⁾ 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?

• 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í)

Společná správa dat a aplikací

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).

• Ú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

• 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í

Druh klient-server architektury často používaný u webových aplikací.

• 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 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í

• 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

• 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.

• 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.

• 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é.

• 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

• 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.

• E-komerce
• Informační systém státní správy
• Spolupráce zdravotnických zařízení
• Možná implementace CRM, 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

• 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

A – aplikační služba,
B – její rozhraní (primární brána)
UR je uživatelské rozhraní, např. portál

• 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 (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)

• 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ě

FI:PA102 - Technologie IS I.
FI:PA105 - Technologie IS II.

TIS I. - SOA TIS I. - Kvalita Dat TIS I. - Technologie IS CS Wikipedie - Klient-Server CS Wikipedie - Vícevrstvá architektura

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.

Ondřej Božek - ICQ: 148979645
stav - cca 99%, je potřeba nějaká kontrola

30.1.2012 - přidána definice SOA, drobné doplnění odkazů a textu
31.1.2012 - definice metriky a míry