Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Databázové systémy Antonín Říha. Databáze alespoň implicitně v každém systému informačním, znalostním,….., s vhodným uživatelským rozhraním.

Podobné prezentace


Prezentace na téma: "Databázové systémy Antonín Říha. Databáze alespoň implicitně v každém systému informačním, znalostním,….., s vhodným uživatelským rozhraním."— Transkript prezentace:

1 Databázové systémy Antonín Říha

2 Databáze alespoň implicitně v každém systému informačním, znalostním,….., s vhodným uživatelským rozhraním

3 Tento kurz není jen pro uživatele, a proto se podíváme i na východiska a „vnitřek“ systémů v rámci jedné prezentace však nelze říci vše

4 Dále pro inspiraci uvedeme „klasické“ požadavky na nemocniční informační systém a příklad takového systému

5 Harward Medical School (1976) -informace nebude zaznamenávána na papír, ale vkládána přímo do počítače z místa kde vzniká -zobrazování informace na terminálu má přednost před tiskem, protože tištěná informace může být zastaralá

6 -informace vložená z jednoho terminálu musí být bezprostředně přístupná ze všech ostatních terminálů v systému -odezva počítače musí být velmi rychlá, někdy několik vteřin může být příliš dlouhá doba Harward Medical School (1976)

7 -počítač musí být spolehlivý, s výpadky nejvýše několik minut, data nesmějí být ztracena při výpadku -data musejí být chráněna před zneužitím, přístup musí být omezen podle přístupových práv

8 Harward Medical School (1976) -všechny programy musejí být uživatelsky přátelské, manipulace s nimi musí být tak jednoduchá jak je to jen možné, práce s nimi nesmí vyžadovat studium manuálů

9 Harward Medical School (1976) - systém musí obsahovat jeden centrální soubor pro všechny pacienty, pro každého pacienta musí existovat jen jedna kolekce dat přístupná pro všechny autorizované uživatele systému; tato data musejí být užívána všemi softwaro- vými nástroji, které pracují s identifikací pacientů.

10 Projekt ARTEMIS ( ) mis/ index.html „A semantic web service-based infrastructure for the interoperability of Medical Information Systems“. „in many cases several identifiers for a patient exist even within a single organisation“

11 Východisko projektu „a common problem in the healthcare sector that is likely to become very important with the increasing mobility of the workforce in Europe: locating and accessing prior clinical records for continuity of care“

12 Příklad nemocničního systému „The HELP hospital information system: update 1998“ (autoři Gardner, Pryor, Warner), Int. J. Of Medical Informatics 54 (1999), „Building a Comprehensive Clinical Information System from Components – The Approach at Intermountain Health Care“ (Clayton P.D. et al.), Meth Inf Med 2003, 42, 1-7.

13 Vznikl ve spolupráci nemocnice LDS v Salt Lake City a Univerzity v Utahu s podporou organizace Agency for Healthcare Research and Quality (AHRQ), zpočátku navržen pro nemocniční kardiovas- kulární laboratoř jako nástroj k získávání a zobrazování fyziologických dat, existuje od 1967,dodnes používán a rozvíjen

14 Později zahrnul integrovanou počítačovou databázi kombinovanou s modulem pro podporu rozhodování ve formě znalostních rámců, byl snad vůbec prvním systémem slučujícím podporu rozhodování s uchováváním dat o pacientech

15 Používal terminály přímo u lůžek pacientů a automatické odečítání některých údajů o pacientech - signalizoval některé stavy pacientů sestrám a lékařům

16 Vývoj systému sledoval i vývoj hardware i software začali analogovými počítači, pak programováním v assembleru, Pentium PC jako terminály s lokálními sítěmi, respektování standardů – např. HL7 pro přenos laboratorních výsledků.

17 Další varianta z roku 1998 plánování služeb, operací atd., infekční nemoci, patologii, přepis textových údajů do strukturovaného záznamu, ECG, EKG, krevní banku, příjem nemocných, slovník pro zamezení víceznačnosti popisů, tvorbu zpráv, dlouhodobé (longitudinal) studie

18

19

20 Již v roce 1998 pokrytí 82-86% pacientů, devět „základních“ nemocnic a dále ještě 5 míst nasazení – celkem 3900 lůžek, 4700 terminálů, 1100 laserových tiskáren; jednou denně přenos dat do účtovacího systému

21 Průzkum za 24 hodin více než zalogování, z toho sestry přes 47.4%, z terminálů od lůžek akutní péče 51.7% zalogování, i v noci cca 120 zalogování za hodinu

22 Průzkum využití terminálů v podstatě rovnoměrné od 7 do 18 hod., i když přece jen nejvíce od 8 do 9 hod.; z bezpečnostních důvodů se terminály u lůžek odlogovávaly po 3 minutách nečinnosti

23 Bariéry akceptování systému -rozdílné styly práce mezi nemocnicemi -ne vždy vhodná výchozí zkušenost řídícího pracovníka (pokud byl dříve např. účetní) -velká počáteční investice a ne zcela krátká doba návratnosti -při původním návrhu nerespektován integrovaný dlouhodobý zdravotní záznam

24 Přechod na nový systém zahrnuli také ambulantní pacienty, rozšířili ukládání dat v “longitudinal electronic patient record”; se systémem bylo možné stále pracovat - nový systém budován dle zásad otevřených systémů

25 Otevřený systém důraz na vytváření rozhraní mezi komponentami (v budoucnu to může být snazší v důsledku standardizace), lze využívat i hotových komponent i od jiných výrobců a lze vyměňovat jednotlivé části

26 HELP2 založili systém na komerčním produktu – zde 3M Health Enterprise Management System (HEMS), klient-server produkt „data repositories“ – vytvořená v databázovém systému ORACLE

27 Nemáme čas dělat přehled našich NIS, jsou obsahem jiné přednášky tohoto kurzu (Ing. Přibík : Elektronická zdravotní dokumentace, registry a nemocniční IS). Proto jen indikace, kde např. lze informace najít: standardy/is/firmy-nabizejici-nis.php standardy/is/firmy-nabizejici-lis.php.

28 Databáze přejdeme k informatické charakterizaci databází a databázových systémů můžeme porovnávat s požadavky citovanými na začátku přednášky

29 Základní důvod existence sdílení dat zajištění bezespornosti snížení celkového objemu dat

30 Databáze „Obsah kolekce je takový, že podporuje ty rysy univerza diskurzu, které jsou relevantní pro defi- novanou množinu účelů (sadu aplikací).“ Ale protože shromážděná data do jisté míry modelují instituci – lze je někdy využít i pro další aplikace.

31 Uložená databáze pacientů Vnitřní schéma databáze pacientů Logické schéma databáze pacientů Vnější pohled lékaře Vnější pohled administrativy Vnější pohled sestry VNĚJŠÍ ÚROVEŇ KONCEPTUÁLNÍ a LOGICKÁ ÚROVEŇ VNITŘNÍ ÚROVEŇ Konceptuální schéma

32 „Režijní“ náklady autorizace přístupu různé přístupové metody řízení vícenásobného přístupu integrita databáze zabezpečení proti chybám

33 Databáze „Systém řízení databáze je obecný softwarový systém, který řídí sdílený přístup k databázi, a poskytuje mechanizmy pomáhající zajistit bezpečnost a integritu uložených dat.“

34 Návrh databází účast uživatele na návrhu systému ER-model - datová analýza popř. charakteristické dotazy a charakteristické aktualizace

35

36

37 V současné době většina systémů na trhu jsou relační DBS pro reprezentaci všeho máme v relačních databázích jediný prostředek – tabulky "strukturní chudoba" se relačním databázím mnohdy vytýká

38 Přínosy relační technologie jednoduchost (i „tabulková“ terminologie) neprocedurální jazyky použití teorie pro optimalizaci neutrálnost vůči implementaci neutrálnost vůči přístupu k datům

39 Transformace ER do relací provádí se algoritmicky – ve skutečnosti to může dělat CASE-systém (pravidla : v zásadě pro každou entitu i vztah tabulka, ale lze ušetřit při vhodných kardinalitách; vztahy u Case Studio nemají separátní tabulky)

40 Klíč relace překladem identifikátorů entit do relací jsou klíče relací (přesněji klíče schémat relací) v relačním datovém modelu říkáme, že klíč funkčně určuje n-tici relace (řádek tabulky), neboli že řádek tabulky funkčně závisí na klíči

41 Návrh relačního schématu zkušenost návrhářů ukazuje, že překladem „správně vytvořeného“ ER-schématu je téměř vždy „správné“ relační schéma

42 Ne každé schéma je dobré DODAVATEL_ODBĚRATEL (IdDodavatele | …Data o dodavateli… | IdOdběratele | …Data o odběrateli…) aktualizační anomálie

43 Definice normálních forem hlavním požadavkem v nich je, aby všechny údaje v řádcích relace jednoznačně (funkčně) závisely na klíči relace to je teoreticky vystižený požadavek, aby tabulka obsahovala jediný typ údajů

44 V praxi i od normální formy se někdy ustupuje v zájmu efektivity vyhodnocení dotazů

45 Dekompozice, syntéza musíme však umět normalizovanost schémat ověřit popř. schéma opravit relační datový model pro tuto úlohu poskytuje algoritmy (dekompozice, syntéza) popis těchto postupů – lze nalézt v učebnicích, překračuje rámec tohoto úvodního kurzu

46 Manipulace s daty dosud jsme mluvili o návrhu (definici) databáze – nyní přejdeme k dotazům

47 SQL “mateřský jazyk” databází původně pro databáze relační, ale nyní již i pro objektové atd.

48 Databáze pro příklady: U (učitel) nad schématem {KU,PŘ,KA}, kde KU...kód učitele, PŘ...příjmení, KA…katedra P (předmět) nad schématem {KP,NP,TV,PH}, kde KP...kód předmětu, NP...název předmětu, TV...typ výuky, PH...počet hodin R (rozvrh) nad schématem {KU,KP,DT,HZ,PO}, kde DT...den v týdnu,HZ..hodina začátku, PO...posluchárna

49 Dotazy 1,2,3 Příjmení (všech) učitelů select PŘ from U Učitelé katedry algebry select * from U where KA='Alg' Příjmení učitelů katedry algebry select PŘ from U where KA='Alg'

50 Dotaz 4 Názvy vyučovaných předmětů select NP from P,R where P.KP=R.KP nebo select NP from P where exists (select * from R where P.KP=R.KP) nebo select NP from P where KP in (select KP from R)

51 Dotaz 5 Učitelé, kteří nic neučí select * from U where not exists (select * from R where KU=U.KU) nebo (select KU from U) except (select KU from R)

52 Dotaz 6 Zaměstnanci s platem vyšším než jejich šéf výchozí tabulka ZAM(ČZ,PLAT,ČV) select t.ČZ from ZAM t, ZAM u where (t.PLAT > u.PLAT) and (t.ČV = u.ČZ)

53 Dotaz 7 Spoje výchozí tabulka SPOJ(ZAC,KON)…ze ZAC do KON bez přestupu Přidání spojů s jedním přestupem: (select * from SPOJ) union (select t.ZAC,s.KON from SPOJ t, SPOJ s where t.KON=s.ZAC)

54 SQL SQL zahrnuje ještě mnoho dalších příkazů – definice tabulek, aktualizace tabulek, administraci databáze (zejména přidělování přístupových práv) atd. Kromě toho se SQL také vyvíjí podle vývoje databází – nejnovější verze SQL už obsahují i příkazy pro práci s objektovými databázemi, příkazy převzaté z programo- vacích jazyků, nové datové typy (XML) apod.

55 Relační algebra Základním teoretickým nástrojem pro manipulaci s relacemi je relační algebra, tj. soubor unárních a binárních operací, jejichž operandy i výsledky jsou relace. Algebra se uplatňuje při vyhodnocování dotazů.

56 Relační algebra Příklad projekce: Příjmení (všech) učitelů: U[PŘ] - výběr sloupce - duplikáty se vypouštějí Příklad selekce: Učitelé katedry algebry: U[KA = 'Alg'] – výběr řádků Příklad spojení: Názvy vyučovaných předmětů: (P*R)[NP] – tzv. přirozené spojení

57 Algebra vers. kalkul Relační algebra je procedurální jazyk. Pro uživatele je vhodnější popsat požadavek neprocedurálně a ponechat volbu postupu vyhodnocení databázovému systému. Teoretickým podkladem neprocedurálního zápisu je relační kalkul.

58 N-ticový kalkul Příjmení všech učitelů: {(t[PŘ]): U(t)} Učitelé katedry algebry: {(t[KU], t[PŘ], t[KA]): U(t) & t[KA] = 'Alg'} Názvy vyučovaných předmětů: {(t[NP]): P(t) & R(u) (t[KP] = u[KP])}

59 Vyhodnocení dotazu SQL umožňuje zápisy dle kalkulu i dle algebry. Pro vyhodnocení se musí dotaz převést do relační algebry. Vyhodnotit dotaz lze různými postupy, jednak je důležité pořadí operací, jednak algoritmy operací, velice důležité je snížit potřebný počet čtení z disku.

60 Optimalizace Nejběžnější je optimalizace statistická. Systémy umí informovat o zvoleném postupu vyhodnocení. Další možná optimalizace je algebraická, založená na relační teorii.

61 Optimalizace Lze i přizpůsobit strukturu databáze převládajícím dotazům (např. denormalizace, materializace joinů apod.) – tuning. Dokonalejší systémy mohou optimalizovat i na hardwarové úrovni (paralelismus apod.).

62 Aktualizační operace Aktualizační operace na rozdíl od dotazů do databáze zapisují. Problém může způsobit jednak to, že aktualizační operace nejsou okamžité, a dále časové prokládání aktualizačních operací více uživatelů.

63 Transakce Transakce je jistá posloupnost akcí, se kterou se zachází jako s jedním celkem. Databázový systém v případě nedokončení transakce vrátí stav databáze do konzistentního stavu před začátkem transakce, tj. provede její ROLLBACK – k tomu nutný tzv. žurnál (log).

64 ACID Atomicity – transakce musí buď proběhnout celá, nebo vůbec ne. Consistency – transakce transformuje databázi z jednoho konsistentního stavu do jiného konsis- tentního stavu. Independence – transakce jsou nezávislé, tj. dílčí efekty transakce nejsou viditelné jiným trans- akcím. (Alternativně se zde užívá „Isolation“). Durability – efekty úspěšně ukončené (potvrzené) transakce jsou uloženy trvale do databáze.

65 Uspořádatelnost Rozvrh – časové rozložení operací. Přirozeným požadavkem na korektnost je, aby efekt paralelního (prokládaného) zpracování transakcí byl týž, jako by byly transakce provedeny v nějakém sériovém rozvrhu. O systému řízení transakcí, který zaručuje tuto vlastnost se říká, že zaručuje uspořádatelnost.

66

67 Uspořádatelnost Máme-li rozvrhy S 1 a S 2 pro množinu transakcí T ={T 1,...,T N },pak S 1 s S 2 jsou ekvivalentní vzhle- dem ke konfliktům, jsou–li v obou rozvrzích všechny dvojice konfliktních operací prováděny ve stejném (časovém) pořadí. O rozvrhu říkáme, že je konfliktově uspořádatelný, jestliže existuje sériový rozvrh s ním ekvivalentní vzhledem ke konfliktům.

68 Uspořádatelnost Testování konfliktové uspořádatelnosti lze provádět algoritmicky.Časové nároky takového přístupu by však přesahovaly rozumnou míru a museli bychom předem znát celé transakce. Je možné provádět transakce podle jistých pravidel (protokolu) tak, že vzniklý rozvrh bude uspořádatel- ný.

69 Účinek protokolu Protokoly vyhovují příchozím požadavkům na operace v pořadí, které samy pro dosažení uspořádatelnosti stanoví, nikoli v pořadí jejich příchodu ani v nějakém konkrétním pořadí požadovaném uživatelem.

70 Povinnost uživatele Uživatel tedy musí naprogramovat svou aplikaci tak, aby nezávisela např. na tom, zda proběhne až po nějaké operaci jiné aplikace, nebo musí požadované pořadí jinak (např. otestováním) sám zajistit.

71 Dvoufázové zamykání zámek dvě fáze legální rozvrh správně formované transakce

72 Postačující podmínka Jestliže všechny transakce v dané množině transakcí T jsou dobře formované a dvoufázové, pak každý jejich legální rozvrh je uspořádatelný. Dvoufázovost nemusí zajišťovat nepřítomnost uváznutí – je nutná detekce nebo prevence uváznutí.

73 Uváznutí (deadlock) T1T2Poznámka Lock(B) provede se Lock(A) provede se Lock(B) nelze provést, buď se bude čekat, nebo při prevenci se T2 odroluje Unlock(A) při prevenci se v důsledku odrolování zámek uvolní, při čekání zůstane zamknutý Lock(A) při detekci se zjistí deadlock, při prevenci nejspíše proběhne Unlock(B) při detekci záleží na volbě oběti, při prevenci nejspíše proběhne

74 Kaskádové rušení Dalším problémem je též kaskádové rušení transakcí. Provede-li se ROLLBACK transakce T, může to znamenat nutnost provést ROLLBACK pro další transakce, které využívaly hodnoty aktualizované transakcí T.

75 Striktní dvoufázové protokoly Tento nedostatek lze odstranit pomocí striktních dvoufázových protokolů, které uvolňují zámky až po ukončení transakce (po jejím potvrzení nebo odrolování).

76 Chyba systému Globální chyba systému, především např. výpadek proudu, vede ke ztrátě obsahu vnitřní paměti včetně vyrovnávacích pamětí. Stav transakcí se stane nedefinovaným - je nutné po restartu systému použít rollback na neúplné transakce a provést znovu transakce, jejichž operace zcela proběhly před započetím chyby systému, avšak nebylo dokončeno odeslání vyrovnávacích pamětí na disk.

77 Žurnál (log) Je nezbytné zaznamenávat všechny důležité operace do tzv. žurnálu (logu), a to ještě před jejich vlastním provedením. Záznamy logu musejí být zaznamenány do stabilní paměti včas – před COMMIT resp. před odesláním aktualizované stránky do databáze.

78 Kontrolní body Aby nebyl žurnál „nekonečný“, je možno defino- vat tzv. synchronizační body – po doběhu všech transakcí se vyrovnávací paměti zapíší na disk. V praxi se však spíše užívají tzv. kontrolní body (checkpoints), při nichž k zastavení práce nedochází.

79 Zotavení- optimalizace Existují ovšem optimalizace tohoto postupu. Záznamy žurnálu jsou pořadově očíslovány a relevantní číslo záznamu logu se uvádí i v atributech. Záznamy v logu jsou propojené do spojových seznamů dle příslušnosti k transakcím. Je tedy možno aplikovat jen nezbytné operace. Používá se tzv. fuzzy checkpoint, tzn. jednak se při checkpointu vytvoří „jen“ seznam dirty pages a ty se teprve během další práce systému na pozadí ukládají na disk, a za druhé ukládají se „pouze“ ty stránky, které nebyly uloženy během dvou posledních checkpointů.

80 Nedostatky relačního modelu -strukturní chudoba, -ponechání většiny sémantiky mimo schéma, -nepřítomnost rekurzívních dotazů, -„impedanční“ neshoda, -statičnost konceptuálního schématu, -krátké transakce bez interakce s uživatelem, -výkonnostní charakteristiky (transformace klíčů na adresy).

81 Trendy temporální databáze objektově-orientovaný databázový systém objektově-relační databázový systém moderní trendy v realizaci transakcí

82 OODBS ObjectStore® Anatomic Images for the Public, May Communications Engineering Branch, Lister Hill National Center for Biomedical Communications, U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD AQ/BSC2003-AQ.pdf

83 Objektově-relační systémy -bližší realitě či „lidskému chápání“ i k ER -možnost složitých strukturovaných dat -možnost multimediálních dat -metody, dědičnost, pozdní vazba, odkazy -zpětná kompatibilita s relačními systémy -solidní databázové základy

84 ORDBS Oracle Na University of California, San Diego – použita kombinace ORDBS Oracle a middleware „Storage resource broker“ pro správu nejrůznějších zařízení, na nichž uloženy obrázky. Zhang_SSDBM_2003.pdf

85 RDBMS Oracle s obálkou Na University of California, San Diego pro další projekt použit RDBMS Oracle s obálkou (wrapper) překládající reprezentace obrázků do relačních tabulek pdf/Santini_COVLDB_2002.pdf

86 Caché „Postrelační databázový systém“ – Caché umožňuje jak relační tak objektový přístup Je použit např. v HIS firmy MEDOS medos.de.

87 Další druhy databází Velmi frekventované jsou databáze bibliografické, a to jak citační, tak fulltextové. Za všechny uveďme MEDLINE - sledující 3400 periodik. O obrazových databázích se lze dovědět např. na Další velmi významná databáze je „the genome database“, o níž nalezneme informace na

88 Závěr tato prezentace se věnovala především relačním databázím některé další důležité směry byly alespoň zmíněny a předpokládá se jejich výklad v navazující budoucí publikaci


Stáhnout ppt "Databázové systémy Antonín Říha. Databáze alespoň implicitně v každém systému informačním, znalostním,….., s vhodným uživatelským rozhraním."

Podobné prezentace


Reklamy Google