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ř. 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 a metrika1)

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

Formáty metrik

  1. Příslušnost ke třídě (například výskyt určitého znaku, třeba čísla tramvaje)
  2. Fuzzy (dobrý, lepší, nejlepší) – prvek uspořádané množiny, pro níž je jedinou přípustnou operací operace porovnání.
  3. Intervalové (například teplota).
  4. Čí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íra2) 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

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.

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í

  • 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:
  1. Uživatel vykoná akci v uživatelském rozhraní.
  2. Akce je zachycena Controllerem, který promítne změny do modelu. Controller nebo Model informuje View.
  3. View aktualizuje uživatelské rozhraní a promítne tak provedené změny zpět uživateli.

Service Oriented Architecture

Definice SOA dle 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 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
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

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

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

Použitá literatura

Přílohy

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

1)
Převzato z otázky 1.
2)
míra je v tomto textu pravděpodobně zaměnitelná s metrikou, viz „Míra a metrika“

Diskuze

, 2012/01/29 20:53

Za pripominky, navrhy a opravy sem vdecny.

, 2012/01/30 00:54

Otázku som si prešiel, mám tieto pripomienky (sorry za taký dlhý zoznam):

  • Sekciu Atributy kvality nechápem. Tie dve následujúce vety hovoria o atribútoch kvality, alebo o kvalite? Ak o atribútoch, šlo by nejak (príkladom) vysvetliť, čo sa nimi myslí? Mne to pripadá tak, že to má hovoriť o kvalite, alebo jej vlastnostiach a potom je divné, že je tam plurál. Najlepšie by to bolo nejak preformulovať.
  • V boxe Formáty metrik by som pre predstavu vymenoval vždy na konci operácie, ktoré s danou metrikou je možné robiť, takým trošku informatickejším spôsobom:
    • Příslušnost ke třídě (například výskyt určitého znaku, třeba čísla tramvaje). Operace: ==, !=
    • Fuzzy (dobrý, lepší, nejlepší) – prvek uspořádané množiny, pro níž je jedinou přípustnou operací operace porovnání. Operace: všechny z 1. plus: <, >, ≤, ≥
    • Intervalové (například teplota). Operace: všechny z 2. plus: +, -
    • Číselné – jsou povoleny všechny aritmetické operace (všechny z 3. plus: × a ÷). Příkladem je rozsah souboru nebo jeho průměrná hodnota.
  • Nadpis: Problémy s kvalitou dat při dolování dat a na webu
    • Aká miera? Čo sa myslí mierou?
  • Nadpis Proč konfederace - je tu divné štruktúrovanie tých odrážok:
    • 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ů
  • Do rámčeka s vysvetlením ALIANCIE a KONFEDERÁCIE by som dal tiež definíciu ÚNIE, nech je to na jednom mieste
  • U pojmov a skratiek, ktoré sa v otázke nevysvetľujú (RDF, CRM, SCM) by mohli byť aspoň odkazy na wikipediu
  • Nadpis: Kdy použít SO - Čo je SO? Nemyslel SOA?
  • Odrážka: Jako prostředek sdružování kapacit (gridovské systémy, viz projekt CETI) – Neviem, či Král nemyslel náhodou SETI@home
  • Strašne je poznať, že je to prepísané zo skrípt, chcelo by to preformulovať niektoré body a napr. zjednotiť začiatočné písmená (veľké?/malé?) u odrážok. Takisto niektoré body by si zaslúžili dlhšie vety namiesto tej odrážky. Chápem ale, že zdrojom sú Králove skriptá :-) a tie nie vždy dávajú zmysel

Napísal som kamarátovi, čo robí výskum v data miningu, či ho ešte niečo nenapadne pre tú prvú podsekciu Data management - principy, koncepce zpracování dat.

Díky za vypracovanie!
– Adam

, 2012/01/30 09:32

Jo, hodne se na tom odrazi ze je to v podstate Copy & Paste z Kralovych skript. Zkusim to trosku vylepsit. Nektere veci sou mi stejne nejasne jako tobe :). Zkusim to vysvetlit tak jak to chapu. Dik za kontrolu.

, 2012/01/30 11:21

Formáty metrik - Příslušnost ke třídě Nejsou tam spíš operace: ∈, ∉?
Kdy použít SO - Kdy použít servisní orientaci?

, 2012/01/30 22:44

Formáty metrik - asi máš pravdu, ja som vychádzal zo štyroch typov štatistických znakov v štatistike (napr. https://is.muni.cz/auth/el/1441/jaro2011/MA2BP_CPR1/um/budikova-Statistika.pdf, str. 40). Je pravda, že to nie je úplne to isté. Ale ak sa nad tým zamyslím ako programátor, na to, aby si mal ∈, potrebuješ prechádzať množinu a porovnávať prvky. Aj keď matematik by asi odvodil == z ∈. Neviem, nechám na teba :)

SO = servisní orientace - Aha, ok.

Díky za úpravy.

, 2012/01/31 20:48

Když jsem si to teď procházel, tak mě u třívrstvé architektury napadlo zmínit ještě architekuru MVC, která z ní vychází a je v dnešní době dost používaná. Co vy na to?

Info se k tomu dá najít ve slajdech k objektovýmu návrhu IS, co má Radek Ošlejšek. A určitě je to popsaný i v mnoha diplomkách - např. v mojí :) Pokud bude zájem, tak to klidně doplním.

, 2012/02/01 11:16

Nesouvisí architektura MVC spíš s GUI? Implementace klienta?

, 2012/02/02 08:49

Súvisí. Ja by som ho tam aj tak spomenul, ale asi to nie je bezpodmienečne nutné. Necháme to na teba :)

, 2012/02/02 12:42

Je pravda, že MVC je docela dominantni.

, 2012/02/03 11:22

OK, během dneška tam přidám krátký shrnutí MVC, ať to tam je aspoň zmíněný. Pokud o tom náhodou někdo neslyšel, tak ať není úplně mimo mísu :)

edit: hotovo

, 2012/02/02 12:47

Trochu problem je ale ten data management. Mam pocit, že tam něco chybi, ale nevim co.

, 2012/02/03 10:29

Takéto rozdelenie som nasiel u jednej spoločnosi zaoberajúcej sa Data managementom profinit

Data management:
- riadenie dátovej architektúry
- riadenie kvality dát
- metadata management
- master data management
- riadenie vývoja dát
- riadenie zabezpečenia dát

Takže je dosť možné, že niečo chýba …

You could leave a comment if you were logged in.
mgr-szz/in-ins/3-ins.txt · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0