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

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

Tento kurz není jen pro uživatele, a proto se podíváme 05/04/2017 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 3

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

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á

Harward Medical School (1976) -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) -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

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ů

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

Projekt ARTEMIS (2004-06) http://www.srdc.metu.edu.tr/webpage/projects/artemis/ 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“

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“

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), 169-182. „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.

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

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

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

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

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

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

Průzkum za 24 hodin více než 12000 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

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

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

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ů

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

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

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: http://www.infomed.cz/ps/article.php?arid=25 http://www.medinfo.cz/oblasti/informacni-systemy-standardy/is/firmy-nabizejici-nis.php http://www.medinfo.cz/oblasti/informacni-systemy-standardy/is/firmy-nabizejici-lis.php.

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

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

05/04/2017 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. 30

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

„Režijní“ náklady autorizace přístupu různé přístupové metody 05/04/2017 „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 32

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

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

05/04/2017 35

05/04/2017 36

V současné době většina systémů na trhu jsou relační DBS 05/04/2017 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á 37

Přínosy relační technologie 05/04/2017 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 38

Transformace ER do relací 05/04/2017 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) 39

05/04/2017 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 40

Návrh relačního schématu 05/04/2017 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 41

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

Definice normálních forem 05/04/2017 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ů 43

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

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

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

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

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

Dotazy 1,2,3 Příjmení (všech) učitelů select PŘ from U 05/04/2017 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' 49

Dotaz 4 Názvy vyučovaných předmětů select NP from P,R where P.KP=R.KP 05/04/2017 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) select NP from P where KP in (select KP from R) 50

Dotaz 5 Učitelé, kteří nic neučí select * from U where not exists 05/04/2017 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) 51

Dotaz 6 Zaměstnanci s platem vyšším než jejich šéf 05/04/2017 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) 52

Dotaz 7 Spoje výchozí tabulka SPOJ(ZAC,KON)…ze ZAC do KON bez přestupu 05/04/2017 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) 53

SQL SQL zahrnuje ještě mnoho dalších příkazů – definice 05/04/2017 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. 54

05/04/2017 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ů. 55

05/04/2017 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í 56

Algebra vers. kalkul Relační algebra je procedurální jazyk. 05/04/2017 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. 57

N-ticový kalkul Příjmení všech učitelů: {(t[PŘ]): U(t)} 05/04/2017 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])} 58

Vyhodnocení dotazu SQL umožňuje zápisy dle kalkulu i dle algebry. 05/04/2017 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. 59

Optimalizace Nejběžnější je optimalizace statistická. 05/04/2017 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. 60

05/04/2017 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.). 61

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

Transakce Transakce je jistá posloupnost akcí, se kterou se 05/04/2017 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). 63

ACID Atomicity – transakce musí buď proběhnout celá, nebo vůbec ne. 05/04/2017 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. 64

Uspořádatelnost Rozvrh – časové rozložení operací. 05/04/2017 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. 65

05/04/2017 66

05/04/2017 Uspořádatelnost Máme-li rozvrhy S1 a S2 pro množinu transakcí T ={T1,...,TN},pak S1 s S2 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. 67

Uspořádatelnost Testování konfliktové uspořádatelnosti lze provádět 05/04/2017 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ý. 68

05/04/2017 Úč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. 69

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.

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

05/04/2017 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í. 72

Uváznutí (deadlock) T1 T2 Poznámka Lock(B) Lock(A) Unlock(A) Unlock(B) provede se Lock(A) 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ý 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

05/04/2017 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. 74

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

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.

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

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

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

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

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

OODBS ObjectStore® Anatomic Images for the Public, May 2003. Communications Engineering Branch, Lister Hill National Center for Biomedical Communications, U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894. http://archive.nlm.nih.gov/pubs/reports/bsc2003- AQ/BSC2003-AQ.pdf

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

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. http://www.nbirn.net/publications/presentations/pdf/ Zhang_SSDBM_2003.pdf

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 http://www.nbirn.net/publications/research_papers/pdf/Santini_COVLDB_2002.pdf

Caché „Postrelační databázový systém“ – Caché umožňuje jak relační tak objektový přístup http://www.intersystems.com/cache/index.html. Je použit např. v HIS firmy MEDOS http://www. medos.de.

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 http://archive.nlm.nih.gov/relatedwork/relwork.php. Další velmi významná databáze je „the genome database“, o níž nalezneme informace na http://gdbwww.gdb.org/gdb/.

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