Databáze - úvod do problematiky Data, informace, znalosti - data - soubor údajů, které vznikly měřením, statistickým pozorováním, … ▪ sama o sobě nemají žádný význam - informace - k datům se přidá jejich interpretace - znalosti - vznikají, učiní-li se nějaké závěry, kterými se dále řídíme - přechod od dat k informacím - prostředky nazýváme informační systémy ▪ určené pro sběr, uchovávání, vyhledávání a zpracovávání informací za účelem jejich poskytování ▪ umožňují efektivní práci s informacemi ▪ tvorbou se zabývá Informatika, vydělená z oboru Kybernetika ▪ mají část ▫ technickou (počítače, programové, vybavení, ale také papír a tužka) ▫ sociální (lidé, organizace práce) ▪ rozvoj je úzce spjat s rozvojem výpočetní techniky ▪ při realizaci pomoci počítačů - nejvíce využívané databázové systémy - přechod od informací ke znalostem - pomocí znalostních systémů ▪ expertní systémy ▪ systémy pro rozpoznávání obrazu ▪ další metody nazývány metody umělé inteligence Hromadné zpracování dat - zpracování velkých informačních objemů - z počátku na jednom počítači ▪ systémy hromadného zpracování dat nebo agendové zpracování ▪ největší rozšíření 60. až 70.léta ▫ data se ručně zaznamenávají na stanovené formuláře a následně se přepisují na vhodné médium (děrné štítky, diskety) ▫ následuje zpracování, výsledkem ⇒ výstupní sestavy ▫ doba zpracování je poměrně dlouhá ▫ není možné vyhodnocovat dynamické děje ▫ používají se účelově vyvinuté programy, většinou v jazyce Cobol db 1 / 1
▫ úzká provázanost fyzických a logických datových struktur ⇒ nesnadnost získat údaje v jiné podobě - používaly se systémy řízení souborů podporující techniky zpracování ▪ sekvenční, indexsekvenční a přímou - popisy souborů jsou součástí uživatelských programů ⇒ náročná údržba - nevýhody ▪ redundance a nekonzistence dat ▫ soubory jsou navrhovány různými programátory • dochází k duplikaci uložených informací • z redundance snadno plyne nekonzistence ▪ obtížnost přístupu k datům ▫ data jsou v různých souborech často různých formátů • každý nový požadavek ⇒ vytvořit nový speciální program • obtížné vytváření nových aplikačních programů ▪ problémy s více uživateli ▫ aktualizace dat více uživateli může vést k nekonzistenci dat ▪ problémy s utajením dat ▫ uživatelé nemají stejná práva přístupu ke všem datům v aplikaci • aplikace obsahují definice souborů ⇒ je obtížné zajistit utajení dat ▪ problémy s integritou dat ▫ hodnoty dat mají omezení - odráží vlastnosti skutečných objektů ▫ programy pro kontrolu vstupních dat a vkládají se do aplikačních programů ▫ týkají-li se kontroly více souborů - aplikační program se zkomplikuje ▪ prostředky pro vytváření vazeb mezi záznamy souborů jsou velmi malé ▫ př. knihovnický systém - vazby mezi záznamy o čtenářích a výpůjčkách • jde vytvořit spojový seznam příslušných souborů • problém řeší programátor ve vhodném programovacím jazyku ⇒ vytváří složité částí kódu - tvorba projektu se prodlužuje Databázové systémy - počátky databázových systémů spadají do konce 60. let db 1 / 2
- databáze ▪ strukturovaná množina dat, většinou na discích počítače ▪ místo, kam se ukládají všechny potřebné údaje - vlastní data – samostatná datová báze ▪ potřebné informace si z ní programy vybírají - nový kvalitativní stupeň oproti agendovému zpracovávání ▪ technické a programové prostředky umožňující získávání informací z dat - databázový systém je tvořen databází a systémem řízení báze dat - SŘBD ▪ SŘBD obstarává přístup a manipulaci s daty uloženými v databázi ▪ SŘBD jsou např. Oracle, MS SQL Server, Sybase, Informix, Progress ▫ cena v desítkách a většinou spíše ve stovkách tisíc korun ▫ existují i šířené zdarma např. mSQL, MySQL, PostgreSQL ▪ SŘBD souhrn procedur a datových struktur zajišťující nezávislost databázových aplikací ▫ na detailech vytváření, výběru, uchování, modifikaci a zabezpečení ochrany databází ▪ většina současných SŘBD vychází z relačního modelu dat ▫ název vychází z relační algebry - matematický aparát, na kterém je relační model dat postaven - model dat - souhrn pravidel, prostředků a soubor pojmů ▪ jejich pomocí se formuluje definice dat (logická organizace dat) ▪ druhy modelů organizací dat v databázových systémech ▫ síťový ▫ hierarchický ▫ relační ▫ objektový ▪ každý datový model musí definovat ▫ datové struktury ▫ operace ▫ integritní omezení db 1 / 3
- databázová orientace - vytvoření nové technologie přístupu k souborům ▪ odtržení definice dat a procesu údržby dat od uživatelských programů ▪ data nejsou organizována v izolovaných souborech, ale v centrálně zpracovávané struktuře dat, zvané databáze DB ▪ centrální správa je organizována prostřednictvím SŘBD ▪ v SŘBD existují dva typy jazyků ▫ jazyk pro definici dat DDL • vytváření definic uživatelských dat v aplikaci • je založen na pojmech, které vyjadřují podstatu přístupu k datům • popis dat jedné databáze - schéma databáze (logické) ○ existuje také popis databáze na fyzické úrovni - fyzické schéma • v logickém schématu je uživatelský popis databáze • ve fyzickém schématu se řeší uložení dat na vnější paměti, metody přístupu, ... • v pozadí DDL stojí databázový model umožňující popis dat • všechny definice jsou organizovány v modulu - slovníku dat ▫ jazyk pro manipulaci s daty DML • k aktualizaci dat • k výběru dat podle daných požadavků – dotazování ○ část DML určená k výběru dat - dotazovací jazyk db 1 / 4
- centralizovaný přístup k datům ▪ databáze vyžadují prostředky pro zajištění spolehlivosti dat ▫ obnova databáze (výpadek proudu, zničení disku, chyba v programu) ▫ ochrana dat v databázi • přidělování práv (autorizace) - kontrolované SŘBD - správce dat – zabývá se návrhem databázových schémat, rekonstrukcí databáze po chybě, přidělování práv, vyhodnocováním provozu, … ▪ jeho role je spojená se SŘBD - databázové technologie (datové inženýrství) ▪ unifikovaný soubor pojmů, prostředků a technik sloužící pro vytváření informačních systémů ▪ zabývají se řízením velkého množství v čase přetrvávajících (perzistentních) spolehlivých a sdílených dat ▪ obecnější pojem je softwarového inženýrství - v databázových systémech se klade důraz na data a nikoliv na algoritmy pracující s daty Architektura databází - centrální architektura
▪ data i SŘBD jsou v centrálním počítači ▪ typická pro terminálovou síť ▫ po síti se přenáší údaje z terminálu na centrální počítač do příslušné aplikace, výstupy z aplikace se přenáší na terminál
db 1 / 5
- architektura file-server
▪ souvisí s rozšířením osobních počítačů a sítí LAN ▪ SŘBD a příslušné databázové aplikace jsou provozovány na jednotlivých počítačích ▪ data jsou umístěna na file-serveru a mohou být sdílena ▫ SŘBD musí používat vhodný systém zamykání (položek nebo celých tabulek), aby nedocházelo ke kolizím při přístupu více uživatelů k jedněm datům ▪ komunikace uživatele se systémem probíhá následujícím způsobem ▫ uživatel zadá dotaz ▫ SŘBD přijme dotaz, zasílá požadavky na data file-serveru ▫ file-server posílá bloky dat na lokální počítač, kde jsou data zpracovávána podle zadaného dotazu (vyhledávání, setřídění atd.) ▫ výsledek dotazu se zobrazí se na obrazovce osobního počítače - architektura klient-server
▪ je založena na lokální síti PC počítačů a databázovém serveru ▪ na PC běží program podporující např. vstup dat, formulaci dotazu, ... db 1 / 6
▪ dotaz se předává pomocí jazyka SQL (Structured Query Language) na databázový server, který jej vykoná a vrátí výsledky zpět PC, kde se zobrazí ▪ databázový server je nejvíce zatíženým prvkem systému ▪ redukuje přenos dat po síti ▪ vyhovuje i náročným aplikacím a je využívána většinou renomovaných databázových firem ▪ jazyka SQL představuje standardní dotazovací jazyk - distribuovaná databáze ▪ množina databází, která je uložena na několika počítačích ▫ uživateli se jeví jako jedna velká databáze ▪ v databázi neexistuje žádný centrální uzel nebo proces odpovědný za vrcholové řízení funkcí celého systému ▫ výrazně to zvyšuje odolnost systému proti výpadkům jeho částí ▪ charakterizována je vlastnostmi ▫ transparentností - z pohledu klienta se zdá, že data jsou zpracovávána na jednom serveru v lokální databázi • jsou syntakticky shodné příkazy pro lokální i vzdálená data, nespecifikuje se místo uložení dat (řeší to distribuovaný SŘBD) ▫ autonomností - s každou lokální bází dat zapojenou do distribuované databáze je možno pracovat nezávisle na ostatních databázích • lokální databáze je funkčně samostatná, propojení do jiné části distribuované databáze se v případě potřeby zřizují dynamicky ▫ nezávislostí na počítačové síti - jsou podporovány různé typy architektur lokálních i globálních počítačových sítí (LAN, WAN) • v distribuované databázi mohou být zapojeny počítače i počítačové sítě různých architektur, pro komunikaci se používá jazyk SQL Databázové modely - databázový model slouží k vyjádření typů dat ▪ používá několik primitivních pojmů a aparát pro podpůrné diagramy - modely, které používají dnešní komerční SŘBD ▪ síťový, hierarchický a relační ▪ vznikly v 60.letech - říká se jim klasické. První dva vznikly v praxi db 1 / 7
- výsledkem modelování je schéma databáze (Anglosaská terminologie) - ve světě databází je databázový model prostředkem a schéma je cílem Síťový a objektový model dat vlastník síťový model členové - síťový model - obvyklý v 70. letech na velkých sálových počítačích - znám z databázové skupiny DBTG Codasyl - zpráva z roku 1971 (1978) ▪ vycházejí z ní veškeré komerční implementace (IDMS, Total, …) - základní myšlenka spočívá v existenci velkého množství samostatných segmentů s rozdílnou strukturou. Mezi segmenty existují vazby, které vytváří síť - je nejobecnější ze všech databázových modelů - rozsáhlejší databáze se obtížně a náročně udržují - postupem času se od jeho používání upustilo - síťová databáze je kolekce záznamů a C-množin vyhovujících schématu - schéma databáze se skládá z typů záznamů, které obsahují popis atributů, a z typů C-množin, které definují vztahy mezi záznamy daných typů ▪ každý záznam má přiřazen databázový klíč - diskovou adresu ▪ typ C-množiny je pojmenovaná uspořádaná dvojice typu záznamu ▫ vlastník a člen ▪ záznam typu člen však nemůže být obsazen jako člen ve dvou C-množinách stejného typu ▪ nejsou povoleny rekurzivní vztahy ▫ jeden typ nemůže být současně vlastníkem a členem v jednom typu C-množiny ▪ C-množina – lze si jí představit jako jeden záznam typu vlastník a n záznamů typů člen (n >=0) ▫ k záznamu vlastníka pro typ C-množiny existuje nejvýše jedna taková Cmnožina ▫ z typů C-množin lze vytvořit složitou strukturu připomínající orientovaný graf db 1 / 8
- myšlenka síťového modelu byla znova využita v tzv. objektové databázi ▪ data popisují objekty ▫ mohou mít různou strukturu ▫ mohou obsahovat též metody (odkazy na programy s nimi svázané) ▪ mezi objekty existuji vazby připomínající síť ze síťového modelu ▪ pro práci s objektovými databázemi je potřeba velmi výkonné počítače - mezistupněm mezi objektovým a dnes nejpoužívanějším relačním modelem je tzv. objektově-relační databáze Hierarchický model dat hierarchický model
rodič
děti
- speciální případ modelu síťového - vhodný pro ukládání dat, která mají hierarchickou strukturu - vychází z hierarchické struktury dat, zavedené pro potřeby jazyka Cobol ▪ zobrazení hodnot dat a jejich vzájemných vztahů - jeho používání je spojeno hlavně se sálovými počítači v 70. a 80. létech - je na něm založena řada SŘBD - IMS, český DBS používaný v řadě EC, ... - standardem je De facto IMS firmy IBM - model se neopírá o matematickou teorii ▪ přejímá část terminologie z teorie grafů - databázové schéma - dáno datovými strukturami - stromy - data jsou uspořádána do hierarchického stromu ▪ každý objekt (uzel) má odkaz ▫ na jednoho předchůdce (otce), od kterého dědí jeho vlastnosti ▫ na libovolné množství následovníků (synů), kterým předává. své i od otce zděděné vlastnosti - terminologie se zde používá odlišně ▪ typ záznamu je typem segmentu db 1 / 9
▪ záznam je segment ▪ ... - důležitý rys je omezení na vztahy ▪ v rámci jednoho typu C-množiny může být jeden záznam-člen přiřazen nejvýše do jedné C-množiny a mít tedy pouze jeden záznam-vlastník ▪ toto omezení typu vztahu se označuje 1 : N. - umožňuje definovat vazby mezi záznamy souborů - nalezení dat vyžaduje navigaci přes záznamy směrem dolů ▪ pro popis se používá tzv. přístupová cesta ▪ je to vlastnost hierarchické struktury, která zaručuje, že od kořene k danému záznamu lze dojít jediným způsobem - v současnosti se informace s hierarchickou strukturou ukládají pomocí modelu relačního (někdy za cenu nárůstu množství ukládaných dat) ▪ je s nimi jednodušší manipulace - nevýhody hierarchického modelu ▪ je velmi obtížná implementace odkazů ▪ složité jsou operace vkládání a rušení záznamů ▪ v některých případech je nepřirozená organizace dat (např. vztah M:N) Relační model dat - nejmladší databázový model - byl popsán v roce 1970 Dr. Coddem - zpočátku úspěšný jen teoreticky - "zaostával" v úspěšných implementacích ▪ nepředpokládá žádné explicitní vazby mezi záznamy v databázi ▪ potřeba nové technologii, prosadila se v 80. letech s rozšířením PC - je používán nejčastěji, vzhledem k jeho snadné implementaci - v současné době jde o nejvýznačnější databázový model - sobory v něm jsou chápány logicky jako relace a vazby mezi jejich prvky se vytvářejí pomocí silného jazyka pro manipulaci s daty. - úspěšnost provozu DBS je citlivá na návrh struktury dat mnohem více než u původního zpracování - v 70. letech se objevují metody návrhu dat a souběžně se analyzují funkce (procesy) využívající data ▪ později se staly základem programových produktů CASE db 1 / 10
- dva nejdůležitější důvody pro existenci RDM ▪ získá se vyšší nezávislost dat na jejich fyzickém uložení ▫ tj. zjednoduší se uživatelský pohled na data ▪ získají dva silné manipulační prostředky ▫ relační algebru • je dána množina operací nad relacemi, výsledkem jsou opět relace ○ sjednocení, rozdíl, průnik, součin, projekce, selekce, spojení • dá se dokázat, že minimální množinu operací tvoří operace ○ sjednocení, kartézský součin, rozdíl, selekce, projekce ▫ relační kalkul • vychází z jazyka logiky • je neprocedurální - dotaz neprogramujeme, ale pouze specifikujeme ▪ oba manipulační prostředky slouží jako dotazovací jazyky resp. jako teoretické pozadí existujících dotazovacích jazyků nad RDM - model má jednoduchou strukturu ▪ data jsou organizována v tabulkách, které se skládají z řádků a sloupců ▫ tabulka zpravidla obsahuje ucelené údaje o jednom druhu objektů např.: tabulka s osobními údaji zaměstnanců • jednotlivé řádky (nazývají se záznamy) odpovídají jednotlivým zaměstnancům • sloupce obsahují informace o pracovnících např.: osobní číslo, jméno, rodné číslo, adresa a výše platu • sloupcům tabulky se obvykle říká položky nebo atributy ▫ tabulky a v nich uložené údaje, musí být jednoznačně identifikovány • každá tabulka má své jméno - v rámci databáze jednoznačné • každý sloupec je pojmenován (má svůj název) • názvy se používají při odvolávání se na obsah určitého atributu (ne na celý záznam) např. jméno, plat ... ▫ mezi tabulkami mohou existovat vztahy • např. student může (má) zapsáno několik předmětů ○ vztah označovaný 1 : N db 1 / 11
○ tabulka studenti má atribut pro primární klíč určující předmět • existují i jiné vztahy než 1 : N (1 : 1, M : N) - relační model zavádí jedinou datovou strukturu n-ární relaci s pomocnou strukturou schématem relace - schéma n-ární relace S={(A1:M1),(A2:M2),...} ▪ Ai je atributové jméno a Mi je doména př.
OSOBA={( Jméno:CHAR[10]), (Příjmení:CHAR[20]), (Datum_narození: DATUM)}
▪ prvky domén jsou atomické hodnoty ▫ atomičnost komponent prvků relací se označuje jako 1. normální forma - schéma relační databáze DB={S1,S2,...} - klíč schématu je minimální množina atributů, jejíž hodnoty jednoznačně určují ntice relace (požadovaný záznam) ▪ existuje-li více klíčů, zvolený klíč se označuje jako primární ▫ primární klíč je kombinace hodnot atributů • pro každý záznam je jedinečná • v každé tabulce vždy jen jeden ▪ klíč obsahující pouze jeden atribut je jednoduchý ▪ klíč obsahující více atributů se označuje jako složený ▪ atribut, který je součástí nějakého klíče, je klíčový - jinak je neklíčový ▪ atributu sloužící jako odkaz na jinou tabulku, říkáme cizí klíč ▫ obsahuje primární klíče jiné tabulky ▫ cizích klíčů může tabulka obsahovat i více - relace je obecně podmnožina kartézského součinu množin A1, A2,..., An ▪ A1, A2,..., An jsou množiny atributu - vlastností jednotlivých entit (objektu) - relace – nejjednodušší abstrakce souboru ▪ místo o souboru hovoříme o relaci ▪ místo o záznamech hovoříme o n-ticích - databázové relace (na rozdíl od souboru) musí tvořit množinu ▪ tj. žádná n-tice se neopakuje db 1 / 12
▪ tento fakt není u některých SŘBD dodržován ▫ jejich relace mohou tvořit tzv. kolekce obsahující i opakující se n-tice př.
vlastnosti studentů mohou vyjadřovat následující množiny atributu ▫ A1... množina všech českých jmen a příjmení ▫ A2... množina všech přípustných rodných čísel. ▫ A3... množina všech českých měst a obcí. ▫ A4... množina všech českých okresů ▫ A5... množina všech českých krajů
▪ relace je podmnožina kartézského součinu A1xA2xA3xA4xA5 ▫ množina uspořádaných 5-tic [a1,a2,a3,a4,a5] • první člen a1 je prvek množiny A1 • druhý člen a2 je prvkem množiny A2 • ... ▪ pětice [a1,a2,a3,a4,a5] zařazená v relaci se chápe jako existence objektu ▫ studenta s danými vlastnostmi • jménem a příjmením a1 • rodným číslem a2 • bydlícím v obci a3 • okrese a4 • kraji a5 • př.
relační tabulka jméno
rodné číslo
obec
okres
kraj
Zdena Malá
765212/1245 Benešov
Benešov
SČ
Hana Slavíková
775123/1248 Zdice
Beroun
SČ
Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
Ivan Vidím
370212/1245 Klatovy
Klatovy
ZČ db 1 / 13
Jiří Vlak
511220/0666 Huslenky
Vsetín
SM
Jiří Vlk
711230/0666 Huslenky
Vsetín
SM
▪ objekt tabulky je určen pouze hodnotami svých atributů ▪ tabulka nemůže obsahovat dva řádky se stejnými hodnotami atributů ▪ tabulka je grafický zápis relace ▫ není určeno žádné pořadí řádků tabulky ani pořadí jejich sloupců - vytvořit (definovat) relaci znamená: ▪ pojmenovat relaci ▪ definovat její strukturu, tzn. určit pro každý atribut relace: ▫ název ▫ datový typ ▫ přípustnost/nepřípustnost neurčených hodnot (NULL) ▪ přípustnost/nepřípustnost duplicitních hodnot ▪ specifikovat nepřípustnost duplicitních hodnot určených skupin atributů - v SŘBD mohou být atributy pouze z povolené množiny datových typů ▪ znakový řetězec (string) předem dané maximální délky ▪ číselné hodnoty ▫ celá čísla ▫ desetinná čísla ▪ logické hodnoty (ano/ne) ▪ méně obvyklé typy ▫ hodnoty typu datum ▫ hodnoty typu obrázek ▫ úseky programu (triger) ▫ texty proměnné délky (memo) ▪ mnoho SŘBD podporuje i složitější typy ▫ obrázek ▫ video ▫ audioklip Operace s relačními tabulkami db 1 / 14
- základním nástrojem pro manipulaci s relacemi je relační algebra ▪ soubor unárních a binárních operací, operandy i výsledky jsou relace - relace jsou množiny a lze na ně použít množinové operace ▪ sjednocení, průnik, rozdíl, kartézský součin - dalšími operacemi jsou ▪ selekce / restrikce ▫ zúžení relace na řádky vyhovující dané podmínce (vybírá řádky) ▪ projekce ▫ zúžení relace na sloupce s atributy (vybírá sloupce) ▫ vstupem operace projekce je jedna relační tabulka a seznam atributů ▫ výstupem je tabulka obsahující • jen sloupce uvedené v seznamu atributů • a jen ty řádky ve kterých se alespoň z hodnot atributů lišila. ▪ spojení ▫ prvky tabulek jsou jejich řádky ▫ výsledkem spojení obou tabulek je jedna tabulka • obsahuje všechny sloupce ze spojovaných tabulek • počet řádek je roven součinu řádků první a druhé tabulky ▫ ve výsledné tabulce je množství řádků, které nejsou zapotřebí • při operaci spojení se provede ještě navíc selekce • zadána je podmínka, zajišťující výběr řádků ○ popíší se v ní spojovací sloupce obou tabulek ○ hodnota sloupce 1. tabulky se rovná hodnotě sloupce 2. tabulky př.
selekce - vstupem je dříve uvedená relační tabulka a výraz
▪ okres='Beroun' jméno
Hana Slavíková
rodné číslo
775123/1248
obec
Zdice
okres
kraj
Beroun SČ db 1 / 15
Zuzana Šustrová
515420/0646
Zdice
Beroun SČ
▪ datum narozeni < 1970 jméno
př.
rodné číslo
obec
okres
kraj
Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
Ivan Vidím
370212/1245 Klatovy
Klatovy
ZČ
Jiří Vlak
511220/0666 Huslenky Vsetín
SM
projekce - vstupem je dříve uvedená relační tabulka a seznam sloupců
▪ pouze sloupec obec obec
Benešov Zdice Klatovy Huslenky
▪ při projekci je možné použít sumarizační (agregační) funkce ▫ provádí přes všechny řádky, které jsou v průběhu projekce spojeny ▪ nejjednodušší sumarizační funkcí je prostý počet řádků ▪ dalšími funkce jsou ▫ součet číselných hodnot ▫ průměrná hodnota ▫ minimální či maximální hodnota ▫ ... př.
projekce s agregačními funkcemi
▪ tabulka vznikla z dříve definované tabulky prostřednictvím ▫ projekce na sloupec okres db 1 / 16
▫ a přidáním atributů, které jsou výsledky agregačních funkcí • cnt - počet řádek • min(rodné číslo) - minimální rodné číslo ▪ ve výsledné tabulce je u každého okresu uveden ▫ počet lidí, kteří v něm bydlí ▫ rodné číslo nejstaršího obyvatele min(rodné číslo)
př.
okres
cnt
765212/1245
Benešov
1
515420/0646
Beroun
2
370212/1245
Klatovy
1
511220/0666
Vsetín
2
spojení dříve definované tabulky s následující tabulkou předmětů kód
název
IS
učitel
Informační systémy
Tomáš Okurka
MODEL Modelování
Jaroslav Kučera
TEPO
Eduard Východ
Teorie pole
▪ výsledkem spojení je tabulka: jméno
rodné číslo
obec
okres
kraj
kód
název
učitel
Zdena Malá
765212/1245 Benešov
Benešov
SČ
IS
Informační systémy
Tomáš Okurka
Hana Slavíková
775123/1248 Zdice
Beroun
SČ
IS
Informační systémy
Tomáš Okurka
Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
IS
Informační systémy
Tomáš Okurka
Ivan Vidím
370212/1245 Klatovy
Klatovy
ZČ
IS
Informační systémy
Tomáš Okurka
Jiří Vlak
511220/0666 Huslenky
Vsetín
SM IS
Informační systémy
Tomáš Okurka
Jiří Vlk
711230/0666 Huslenky
Vsetín
SM IS
Informační systémy
Tomáš Okurka
Zdena Malá
765212/1245 Benešov
Benešov
SČ
MODEL Modelování
Jaroslav Kučera
Hana Slavíková
775123/1248 Zdice
Beroun
SČ
MODEL Modelování
Jaroslav Kučera
Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
MODEL Modelování
Jaroslav Kučera db 1 / 17
Ivan Vidím
370212/1245 Klatovy
Klatovy
ZČ
MODEL Modelování
Jaroslav Kučera
Jiří Vlak
511220/0666 Huslenky
Vsetín
SM MODEL Modelování
Jaroslav Kučera
Jiří Vlk
711230/0666 Huslenky
Vsetín
SM MODEL Modelování
Jaroslav Kučera
Zdena Malá
765212/1245 Benešov
Benešov
SČ
TEPO
Teorie pole
Eduard Východ
Hana Slavíková
775123/1248 Zdice
Beroun
SČ
TEPO
Teorie pole
Eduard Východ
Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
TEPO
Teorie pole
Eduard Východ
Ivan Vidím
370212/1245 Klatovy
Klatovy
ZČ
TEPO
Teorie pole
Eduard Východ
Jiří Vlak
511220/0666 Huslenky
Vsetín
SM TEPO
Teorie pole
Eduard Východ
Jiří Vlk
711230/0666 Huslenky
Vsetín
SM TEPO
Teorie pole
Eduard Východ
▪ rozsáhlá tabulka obvykle není potřeba ▫ zároveň se provádí selekce tabulky podle logického výrazu ▪ logický výraz - např. student navštěvuje přednášky z daného předmětu ▪ výsledná tabulka může vypadat třeba následovně jméno
rodné číslo
obec
okres
kraj
kód
název
učitel
Zdena Malá
765212/1245 Benešov
Benešov
SČ
IS
Informační systémy
Tomáš Okurka
Hana Slavíková
775123/1248 Zdice
Beroun
SČ
IS
Informační systémy
Tomáš Okurka
Zdena Malá
765212/1245 Benešov
Benešov
SČ
MODEL Modelování
Jiří Vlak
511220/0666 Huslenky
Vsetín
SM TEPO
Teorie pole
Eduard Východ
Jiří Vlk
711230/0666 Huslenky
Vsetín
SM TEPO
Teorie pole
Eduard Východ
Jaroslav Kučera
Normalizace - využívá se při návrhu struktury relačních tabulek - existuje sedm tzv. normálních forem (NF) - rad či doporučení - praktický význam mají první tři normální formy ▪ 1NF hovoří o nedělitelnosti jednotlivých atributů ▪ 2NF hovoří o existenci primárního klíče v každé tabulce ▪ 3NF zakazuje existenci redundantních dat - úroveň řízení báze dat (úroveň programů) je daleko jednodušší při zpracování relací ve vyšší NF než relací v nižší NF ▪ jednodušší zpracování vyžaduje i jednodušší programování ▫ čím jednodušší je program, tím méně potenciálních chyb obsahuje db 1 / 18
▪ údržba nenormalizovaných dat, koncovým uživatelem je nemožná ▫ bez rizika porušení integrity dat ▫ bez obslužných programových nadstaveb ▫ riziko (v menší míře) se vyskytuje i v relacích 2NF - obecný postup normalizace logické struktury dat ▪ nenormalizovaný tvar 1NF ▫ rozložení datových struktur, na dvourozměrné, nejsou-li dvourozměrné ▪ 1NF 2NF ▫ odstranění neúplných závislostí neprimárních atributů na možných klíčích ▪ 2NF 3NF ▪ odstranění závislostí neprimárních atributů na sobě - splněni NF se vždy do všech důsledku nepožaduje První normální forma - každý atribut tabulky obsahuje data, která jsou dále nedělitelná - všem atributovým jménům jsou jako domény přiřazeny jednoduché datové typy (hodnoty atributů jsou v rámci databázového systému vnitřně nedělitelné) př.
převedeni tabulky do první normální formy
▪ atribut jméno je potřeba rozdělit na atributy dva – křestní a příjmení křestní
příjmení
rodné číslo
obec
okres
kraj
Zdena
Malá
765212/1245 Benešov
Benešov
SČ
Hana
Slavíková
775123/1248 Zdice
Beroun
SČ
Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
Ivan
Vidím
370212/1245 Klatovy
Klatovy
ZČ
Jiří
Vlak
511220/0666 Huslenky
Vsetín
SM
Jiří
Vlk
711230/0666 Huslenky
Vsetín
SM
Druhá normální forma, klíčové atributy - je v 1NF - žádný neklíčový atribut není funkčně závislý na žádné vlastní podmnožině žádného (možného) klíče db 1 / 19
- v případě, že přirozený primární klíč v relaci neexistuje, je ho potřeba uměle vyrobit (očíslovat řádky tabulky) ▪ primární klíč řeší zákaz existence dvou totožných řádků v tabulce ▫ řádky se budou lišit existencí primárního klíče a neexistenci pořadí mezi řádky relační tabulky (pořadí může být dáno hodnotou primárního klíče) - pokud tabulka obsahuje primární klíč, říkáme, že je v druhé normální formě. př.
přidání atributu ID - primárního klíče: ID křestní
příjmení
rodné číslo
obec
okres
kraj
1 Zdena
Malá
765212/1245 Benešov
Benešov
SČ
2 Hana
Slavíková
775123/1248 Zdice
Beroun
SČ
3 Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
4 Ivan
Vidím
370212/1245 Klatovy
Klatovy
ZČ
5 Jiří
Vlak
511220/0666 Huslenky
Vsetín
SM
6 Jiří
Vlk
711230/0666 Huslenky
Vsetín
SM
Třetí normální forma, redundance dat - tabulky neobsahující redundantní data jsou tabulky ve třetí normální formě - redundance (nadbytečnosti) dat je situace, kdy některé hodnoty lze odvodit na základě hodnot jiných uložených v téže bázi dat př.
redundance v naší tabulce je následující situace ID křestní
příjmení
rodné číslo
obec
okres
kraj
1 Zdena
Malá
765212/1245 Benešov
Benešov
SČ
2 Hana
Slavíková
775123/1248 Zdice
Beroun
SČ
3 Zuzana Šustrová
515420/0646 Zdice
Beroun
SČ
4 Ivan
Vidím
370212/1245 Klatovy
Klatovy
ZČ
5 Jiří
Vlak
511220/0666 Huslenky
Vsetín
SM
6 Jiří
Vlk
711230/0666 Huslenky
Vsetín
SM
▪ z 2. řádku tabulky vyplývá, že okres Beroun je částí Středočeského kraje ▪ ta samá informace je i v řádku třetím ▫ zde je nadbytečná (redundantní) ▫ lze jí odvodit na základě hodnot obsažených v bázi dat na jiném místě ▪ redundantní informace je i na posledních dvou řádcích • o příslušnosti obce Huslenky do okresu Vsetín db 1 / 20
• a okresu Vsetín do Severomoravského kraje ▪ redundance se z relační tabulky odstraní tak, že se rozdělí na tabulky dvě ▪ v příkladě se místo atributu okres zavede atribut id_o. ▫ atribut je cizím klíčem a odkazem do nově vzniklé tabulky okresy tabulka lidé ID křestní
příjmení
rodné číslo
obec
id_o
1 Zdena
Malá
765212/1245 Benešov
BN
2 Hana
Slavíková
775123/1248 Zdice
BE
3 Zuzana Šustrová
515420/0646 Zdice
BE
4 Ivan
Vidím
370212/1245 Klatovy
KT
5 Jiří
Vlak
511220/0666 Huslenky
VS
6 Jiří
Vlk
711230/0666 Huslenky
VS
tabulka okresy id_o
jméno
kraj
BE
Beroun
SČ
BN
Benešov
SČ
KT
Klatovy
ZČ
VS
Vsetín
SM
- obě tabulky obsahují stejné informace jako tabulka původní - odstranění závislosti atributu obec a id_o by - podobným způsobem - v tabulkách existují i další redundantní informace ▪ desátou cifru rodného čísla je možné odvodit na základě předchozích devíti cifer podle pravidla, že rodné číslo je dělitelné jedenácti ▪ ne vždy je potřeba redundanci odstraňovat a trvat na důsledném převodu baze dat do třetí normální formy - proč odstranit redundanci ▪ velikost dat - redundantní data je zbytečné ukládat ▫ klesne objem ukládaných dat a tím i nároky na velikost paměti ▪ hrozí narušení vnitrní identity (nerozpornosti dat) ▫ administrativním zásahem se okres Vsetín přesune ze Severomoravského kraje do kraje Jihomoravského ▫ v tabulce s redundancí je nutné provést db 1 / 21
• ve všech řádcích, kde se ve sloupci okres vyskytuje řetězec 'Vsetín' přepsat hodnotu atributu kraj na JM • může dojít k chybě či opomenutí a tím vznikne rozpor v datech ▫ v tabulce ve 3NF (lidé a okresy) stačí zaměnit hodnotu jednoho atributu v tabulce (okresy) - proč neodstraňovat redundanci ▪ při odstraněni redundance lze data, která nebudou ukládána, zpětně odvodit z již uložených dat ▫ odvozeni může být někdy dost komplikované • při častém provádění nebude vyvážena úspora prostředků počítače ▪ redundantní data mohou sloužit pro kontrolu nerozpornosti dat ▫ při získávání dat, ručním zadáváním, může snadno dojít k chybě ▫ je vhodné jistou redundanci nechat, pro možnost odhalení těchto chyb ▫ někdy je z tohoto důvodu redundance do dat uměle zanesena Modelování reálného světa, konceptuální modelování - E-R modely - popis struktury uživatelské aplikace se nazývá konceptuální schéma ▪ není to popis dat v počítači ani neřeší funkční analýzu aplikace ▪ konceptuální úroveň je považována za nejbližší člověku - prostředky pro vyjádření konceptuálního schématu se označují ▪ konceptuální modely ▪ objektové modely - užívají pojmy blízké konceptuálnímu pohledu - nejznámější je model entita-vztah ( Entity Relationship Model, ER-model), v r. 1976 ho zavedl Peter Chen - existuje i lineární textová notace pro zápis konceptuálního schématu - výsledek konceptuálního modelování (tzv. datové analýzy) zobrazíme ▪ ER-diagramem (ER-schématem) - provedeme konceptuální návrh ▪ vzniklý zápis je nezávislý na fyzické implementaci, ale i na datovém modelu, ve kterém bude definováno logické schéma databáze - ER-diagramem se potom přeloží např. do relačního datového modelu ▪ překlad je součástí tzv. logického návrhu - ER-schéma slouží jako prostředek komunikace mezi db 1 / 22
▪ zadavatelem (budoucím uživatelem) ▪ návrhářem ▪ případně jako součást dokumentace systému - pokud se přeložené schéma upraví a modifikace se nepřeneseme zpět do ERschématu mohou nastat problémy - „zpětné“ generování ER-schématu ke schématu logickému se nazývá „reengineering“ - složité aplikace mají "vzdálenost" mezi zobrazovanou realitou a tabulkami (relacemi) příliš velikou, pro překročení "naráz" - ER-diagramů existuje celá řada ("dialektů") ▪ liší hlavně tím, kolik typů IO se "vejde" do jimi používaných primitivních pojmů. Zbylá IO je nutné popsat explicitně - větami přirozeného jazyka! ▪ používají se zkratky ERA model, E-R-A model, ER model a E-R model ▫ E = Entita (množina dat, objekt reálného světa, jednoznačně identifikovatelný a schopný nezávislé existence) ▫ R = Relace (vztah mezi entitami, mohou být i obecně n-ární) ▫ A = Atribut (jednotlivé položky popisující množinu dat). ▫ ER (E-R) model představuje relace entit bez popisných atributů ▫ ERA (E-R-A) model představuje relace entit včetně popisných atributů ▫ rozdíl mezi ER a E-R nebo mezi ERA a E-R-A není žádný. ▪ do ER-diagramů se "nevejdou" všechny charakteristiky použitých pojmů ▫ dokumentace se doplní např. tabulkami atributů, slovníky pojmů, komentáři a omezeními formulovanými v přirozeném jazyce ▫ popisům se říká "business rules", kromě strukturních a datových omezení zahrnují i pravidla pro korelaci mezi různými vztahy • zaměstnanec může být vedoucím jen oddělení, ke kterému náleží • vedoucím oddělení se může stát jen pracovník, který má více než desetiletou praxi • zaměstnanec nesmí mít vyšší plat než jeho vedoucí ▫ pro velké a složité systémy je obtížné ER-diagram přehledně nakreslit • nemusí to řešit ani zápis ER-schématu v "lineárním" jazyce
db 1 / 23
▫ základním postupem vytváření konceptuálního schématu je vytváření pohledů a jejich spojování do celkového schématu ▪ užívá se postupů shora dolů, zdola nahoru, zevnitř ven ▪ návrh E-R modelu postupem "shora dolu" ▫ identifikace typu entit (ZAMESTNANEC) ▫ identifikace typu vztahu (PRACUJE) ▫ přiřazení popisných atributů (JMENO, PRIJMENI) entitám ▫ formulace integritních omezení - typový E-R diagram ▪ obrázek podobný klasickému vývojovému diagramu ▪ entity jsou znázorněny obdélníky ▪ vztahy kosočtvercem ▪ spojovací čáry mezi entitami a vztahy určují, co k čemu patří ▪ atributy - přirazení hodnoty vztahu nebo entitě ▫ znázorněny malými kroužky spojené s obdélníkem či kosočtvercem ▫ mohou být i neatomické, tj.složené – značeny kroužkem či malým oválem, k němuž jsou teprve připojeny „atributové“ kroužky ▫ identifikační klíč - atribut s jednoznačnou identifikací konkrétní entity • značen je vyplněným kroužkem • musí ho mít každý entitní či vztahový typ ▪ integritní omezení ▫ konceptuální model umožňuje specifikovat integritní omezení - IO ▫ jsou to podmínky, které popisované objekty musí splňovat ▫ nejvíce viditelné jsou kardinality vztahů a členství ve vztahu • uspořádané dvojice (min,max) • min=1 - povinné členství ve vztahu (zaměstnanec musí být zařazen do některého oddělení) - značí se kroužkem uvnitř obdélníku entity • min=0 - nepovinné členství (oddělení nemusí mít žádné zaměstnance) – značí se kroužkem vně obdélníku entity ▫ kardinalita vztahu db 1 / 24
• 1:1 - do vztahu vstupuje nejvýše jedna hodnota obou entit (každý čtenář si může vypůjčit jednu knihu) • 1:N - do vztahu vstupuje nejvýše jedna hodnota jedné z entit a neomezený počet hodnot druhé entity (čtenář si může rezervovat více knih) ○ 1:N(0) - do vztahu vstupuje nejvýše jedna hodnota jedné z entit a neomezený počet nebo žádná hodnota druhé entity • M:N - do vztahu vstupuje neomezený počet hodnot obou zúčastněných entit (každý čtenář si může rezervovat více knih a každá kniha může být rezervována více čtenáři) ○ M:N je vztah, mající „z jedné strany“ kardinalitu (0,N) a „z druhé strany“ kardinalitu (0,M) ○ transformace vztahu (vytvořením umělého entitního typu) - původní vztah se nahradí dvojicí vztahů (1:N a N:1) k umělému typu • vztah ISA - používá-li se několik entitních typů s některými atributy společnými, je vhodné pracovat s nimi jako s podtypy jednoho entitního typu(z anglického "is a") ○ př. UCITEL ISA OSOBA, STUDENT ISA OSOBA ○ entitní typ OSOBA obsahuje např. rodné číslo, adresu, … ○ entitní typ UCITEL obsahuje např. akademickou hodnost, … ○ entitní typ STUDENT obsahuje např. obor, ročník. … - slabý entitní typ ▪ instance entitního typu, které pro svou jednoznačnou identifikaci potřebují ještě další entitu ▫ př. zaměstnanec vypisuje téma diplomové práce, avšak více zaměstnanců může vypsat stejné téma - úplné schéma ▪ kombinace E-R schématu a tabulek popisujících atributy jednotlivých entitních a vztahových typů ▪ tabulky jsou vypracovány pro každý entitní typ a obsahují ▫ jméno atributu, ▫ typ atributu, případně hodnotovou množinu (doménu) a operace ▫ klíčovost atributu ▫ povolení prázdné hodnoty atributu (NULL) db 1 / 25
- návrh informačních systémů zahrnuje ještě funkční analýzu a dynamické modelování jako podklad pro návrh aplikačních programů - rys datového inženýrství - proces vytváření IS ve více úrovních abstrakce - v praxi je běžná čtyřúrovňová architektura schémat v DBS ▪
ES1 ES2 ES2 ..... ESn
externí schéma
▪
KS
konceptuální schéma
▪
SD
schéma databáze
▪
FS
fyzické schéma
- fyzické uložení dat a metody přístupu ▪ neexistuje uspokojivá odpověď na otázku, který ze SŘBD je nejlepší ▪ klasické metody přístupu k datům ▫ souborová organizace jazyků 3. generace. • sekvenční soubory setříděné • indexsekvenční soubory • přímý přístup ▫ jednoduché soubory s jedním typem záznamu, který obsahuje několik položek odpovídající uživatelským typům dat ▫ některé tvoří primární klíč, jehož hodnoty jednoznačně identifikují záznamy v souboru ▫ takový soubor s uživatelskými daty se nazývá primární soubor • pro odlišení od dalších pomocných struktur dat (např. index) • pomocná struktura může být nahrazena přímým výpočtem adresy záznamu pomocí programu (funkce) - "hašovací funkce" ▫ nevýhodou těchto metod je statičnost použitých struktur • akce se záznamy se odehrávají v pevném adresovacím prostoru • nebo se používají speciálně vyhrazené části disku - oblast přetečení • chování souboru se může změnit v důsledku statičnosti v lineárním prohledávání velké části souboru v oblasti přetečení ▪ B - stromy - progresivní technologie pro 80. léta ▫ dynamická struktura, která se rozšiřuje (zužuje) s tím jak do souboru přidáváme (ubíráme) jednotlivé záznamy db 1 / 26
▫ složitost vyhledávání se v průběhu života databáze mění málo - závisí na jistém algoritmu z celkového množství klíčů ▫ B-strom je vlastně vyvážený m-arní strom • každý uzel má nejvýše m následníků ▫ uzel je blok organizovaný tak, aby se do něj vešlo co nejvíce informace nutné pro vyhledávání • obvykle obsahuje hodnoty klíčů daného typu, vazby a ukazatele ▫ struktura B-stromu pro m sudé (p0, k1, p1, k2, p2, ......kn, pn), kde m/2 <= n+1 <= m pi jsou ukazatelé na bezprostřední následníky ki jsou klíče takové, že k1
db 1 / 27
Databázové jazyky - prostředek pro komunikaci s databázovými systémy - můžeme je dále rozlišovat na ▪ procedurální - je třeba popsat, jakým způsobem (jak) chceme určitou operaci s daty provést ▪ neprocedurální - můžeme přímo definovat, jakou operaci (co) chceme s danými daty provést - dotazovací jazyk, který umožňuje realizovat všechny operace relační algebry, se nazývá relačně úplný jazyk - existuje několik požadavků na dotazovací jazyk ▪ neprocedurální jazyk ▪ soběstačný jazyk (na bázi hostitelského jazyka) ▪ zajištění funkce DML ▪ relační úplnost (etalon vyjadřovací síly) ▪ v rámci výběru provádět jednoduché výpočty pomocí základních aritmetických operací (*, /, +, -) ▪ relační algebrou se nedá realizovat dotaz "kolik je v knihovně rezervací" ▫ řeší se pomocí agregační funkcí COUNT, MIN, MAX, SUM, … ▪ zajímavý problém tvoří dotaz typu "kusovník" ▫ je-li relace kusovník (součástka, podsoučástka) • pomocí relační algebry není možné formulovat dotaz ○ "najdi pro danou součást všechny její podsoučástky" ▫ komerční jazyky většinou obsahují konstrukty řešící tyto problémy ▫ docílit úplnost relačního jazyka ve smyslu ekvivalence běžného programovacího jazyka (Cobol, Pascal, C, …) je obtížné • problém se řeší vnořením relačního jazyka do vyššího programovacího jazyka ▪ 4GL - programové nástroje umožňující produktivní tvorbu programových aplikací, které jsou charakterizovány ▫ jednoduchým dotazovacím jazykem ▫ kompletním jazykem pro tvorbu interaktivních aplikací ▫ generátory výstupu db 1 / 28
▫ generátory vstupně / aktualizačních obrazovkových aplikací ▫ interpretem, překladačem ▫ podporou pro příjemné ladění ▪ typy 4GL ▫ samostatné (interface na různé databázové systémy) - uniface, delphi ▫ integrované v databázových systémech • Progress 4GL, AREV, Informix 4GL, SQL+Forms, Oracle
db 1 / 29
Dotazovací jazyky - pro pokládání dotazu slouží syntaktické konstrukty - dotazovací jazyky - koncepce nejznámějších vychází z poloviny 70. let ▪ SQL (Structured Query Language) stal se standardem ▪ Quel součást SŘBD Ingres, vychází z modifikace relačního kalkulu ▪ QBE "Query-by-example" má přímější souvislost s relačním kalkulem ▫ byl vyvinut f. IBM pro kancelářský SW na sálových počítačích ▫ znám je i implementací f. Borland v SŘBD Paradox ▪ kromě prostředků dotazování zahrnují i další rysy DML a kompletní DDL ▪ všechny jsou relačně úplné - pro zápis požadavků na databázový server se nejčastěji používá jazyk SQL ▪ posloupností operací selekce, projekce a spojení s relačními tabulkami je možné odpovídat na dotazy a získávat informace ▪ prošel dlouhým vývojem a v různé míře ho podporují téměř všechny běžně používané databázové servery ▫ databázovým serverům se někdy zjednodušeně říká SQL servery ▪ nabízí vše potřebné pro ▫ vytváření, modifikování a rušení tabulek ▫ práci s údaji v tabulce - vyhledávání, přidávání, modifikování a mazání ▪ neprocedurální jazyk, zadáváme co chceme s daty provést ▫ u procedurálních jazyků je třeba popsat, postup operace - komunikace se SŘBD probíhá nejčastěji ▪ na serveru je nepřetržitě je spuštěn ▫ démon (na Unixu) ▫ služba (ve Windows NT) ▪ na určitém socketu očekává požadavky klientů (ostatních aplikací) ▪ na požadavky pak odpovídá ▪ funguje jako model klient / server ▫ v roli serveru je SŘBD, proto se nazývá databázový server - v roli klienta pro SQL server může vystupovat i skript zapsaný v PHP či ASP ▪ musí umět zpracovávat výsledky předané SQL serverem db 1 / 30
- SQL server má svůj vlastní protokol, s kterým může klient komunikovat ▪ komunikuje klient s více různými servery, musí podporovat více protokolů ▪ rozhraní ODBC vzniklo na platformě Windows - slouží jako prostředník mezi klientskou aplikací a databázovým serverem • rozhraní ODBC se volá jednotně • ovladač ODBC předá požadavek databázovému serveru ▪ PHP nabízí pro některé servery přímou podporu ▫ přístup k datům je obvykle rychlejší ▫ přímo podporované databáze jsou Oracle, Sybase, Solid, MySQL, PostgreSQL, ... Jazyk SQL - vyvinut f IBM v r. 1974 pod jménem SEQUEL - SQL vznikal živelným způsobem (jako kdysi Fortran) ▪ vznikly různé SQL produkty - 35 v r. 1986, více než 55 v r. 1989 ▪ ISO a ANSI publikovaly v r.1986 identické standardy SQL (SQL86) ▫ v podstatě dialekt SQL f. IBM ▪ revize normy v r. 1989 (SQL89), v r.1992 (SQL 2, SQL92), ... - SQL86 má části ▪ jazyk pro definici dat - popis tabulek, pohledů a přístupových práv ▪ jazyk pro manipulaci s daty - přístup a aktualizace ▪ jazyk pro konstrukci modulů ▫ vytváření rozhraní mezi databází a aplikačním programem napsaném v běžném programovacím jazyku ▪ vnořenou syntax ▫ zápis SQL do aplikačních programů jako alternativu pro jazyk modulů - příkazy jazyka SQL se dělí do oblastí ▪ DDL (Data Definition Language) - definice dat a jejich vazeb ▫ založení struktury databáze • CREATE TABLE, CREATE VIEW, CREATE INDEX ▫ redefinici struktury databáze • ALTER TABLE, DROP TABLE, DROP VIEW, DROP INDEX db 1 / 31
▪ DCL (Data Control Language) - zabezpečení dat ▫ příkaz GRANT - přidělování přístupových privilegií k dané databázi ▫ příkaz REVOKE - odebírání již přidělených práv ▪ DML (Data Manipulation Language) - manipulace s daty (výběr) ▫ příkaz SELECT - formulace výběrových požadavků ▫ příkaz INSERT - vkládání dat do již založené tabulky ▫ příkaz UPDATE - modifikace řádků tabulky ▫ příkaz DELETE - odstraňování řádků tabulky, nikoli celé tabulky ▫ příkaz DROP TABLE - smaže se tabulka i všechny řádky v tabulce !!! - relační databázový model použitý v SQL není totožný definicí Codda ▪ n-tice mohou obsahovat prázdné hodnoty ▫ interpretují se jako "neznámé", nedefinované ▫ ovlivňují vyhodnocování logických formulí a agregačních funkcí ▪ výsledek dotazu není obecně množinou, ale kolekcí (jsou duplicitní řádky) ▫ množina se získá zadáním DISTINCT do dotazu - pohled (view) ▪ uživatelské tabulky odvozené z tabulek v relačním schématu ▫ jsou virtuální, tj. n-tice nejsou uloženy přímo v databázi ▫ pohledem se vlastně implementuje externí schéma ▪ jsou na něj kladena omezení např. možnost provést jeho aktualizaci - kritika současného standardu SQL ▪ v relační algebře lze operace používat v jakémkoliv vhodném pořadí ▫ SQL to obecně neumožňuje - tj. SELECT nelze libovolně hnízdit ▪ prvky obvyklé v programovacích jazycích jsou splněny nedostatečně ▫ lze porovnávat pouze hodnoty domén, nikoliv složitější struktury ▫ relaci nelze tvořit z řádků nebo sloupců ▫ přiřazovací příkaz je omezeně suplován konstruktem INSERT ▪ mnoho produktů SQL neumožňuje vytvářet přechodné tabulky ▪ při práci s databází mohou v relacích vznikat celé prázdné řádky ▫ COUNT(*) je neignoruje db 1 / 32
▫ DISTINCT chápe prázdné řádky jako navzájem duplicitní a ponechá v relaci právě jeden ▪ ... ▪ kritika vedla k vytvoření nového standardu SQL2 - transakce, zotavení z chyb, distribuované databáze ▪ některé posloupnosti operací nad databází chápeme jako celek – transakci ▪ transakce se buď provedou celé, nebo se celé neprovedou ▪ slouží zároveň jako jednotka zotavení z chyb ▫ přerušení proudu, zhroucení systému, zničení disku, ... ▪ po chybě je třeba uvést databázi do původního stavu ▫ před začátek provádění transakce ▫ slouží k tomu speciální soubor – deník transakcí (log file, žurnál) ▪ ve víceuživatelském prostředí se provádí paralelní zpracování transakcí nad stejnou databází ▫ stanovené pořadí provádění transakcí se nazývá rozvrh ▫ korektní rozvrh musí být srovnatelný s nějakým rozvrhem, kde transakce jsou provedeny za sebou tak, že jejich akce se vykonávají pohromadě ▫ takové rozvrhy se nazývají sériové ▫ rozvrh je pak uspořadatelný vede-li po provedení všech akcí ke stejným výsledkům jako nějaký sériový rozvrh ▫ uspořadatelnost je možné zajistit např. uzamykáním a odemykáním databázových objektů • relace, n-tice relací, komponenty n-tic, věta B-stromu obsahující indexy ▫ prostředkem k dosažení uspořadatelnosti rozvrhu je dvoufázový uzamykatelný protokol - nezabraňuje uváznutí (dead lock) ▪ v distribuovaných databázových systémech se problémy znásobují ▫ nejčastější způsob řízení zpracování transakcí v distribuovaném prostředí je dvoufázový potvrzovací protokol - příkaz SELECT SELECT [co se má vybrat] FROM [odkud se to má vybrat] WHERE [logická podmínka] db 1 / 33
▪ za slovem SELECT je seznam atributů popisujících operaci projekci ▫ mezi atributy mohou byt i hodnoty sumarizačních (agregačních) funkcí ▫ při použití sumarizačních funkcí se uvádí na konci příkazu fráze GROUP BY, za kterou následuje seznam atributů ▫ místo seznamu atributů je možné uvést znak * • projekce se neprovádí a do výsledné tabulky se přenesou všechny atributy tabulky původní ▪ za slovem FROM je seznam tabulek z kterých je nutno vybírat ▫ seznam nesmí být prázdný ▫ pro více tabulek se provede operace spojení ▪ za slovem WHERE je logická podmínka vymezující operaci selekce - výběr řádků ▫ část WHERE může chybět neprovádí-li selekce ▪ GROUP BY vytváří skupiny řádků z jejichž hodnot jsou odvozeny ▫ souhrnné hodnoty ▫ skupina musí být i za selectem ▪ HAVING uvádí výběrové podmínky (podobně jako WHERE), vztahující se k odvozeným souhrnným hodnotám ▪ ORDER BY setřídění výsledku, ASC vzestupně, DESC sestupně ▪ agregační funkce - používají se společně s GROUP BY, výsledek je číslo ▫ SUM
součet v dané skupině
▫ CNT
počet záznamů ve skupině, nepočítají se hodnoty NULL
▫ AVG
průměr
▫ MIN ▫ MAX ▪ DISTINCT
stejné záznamy se zobrazují pouze jednou
▪ NULL
hodnota není definovaná
▪ DATUM = 1.1.1999 ▫ Ale! DATUM IS NULL ▪ NOT (DATUM = 1.1.1999) ▫ Ale! DATUM IS NOT NULL db 1 / 34
▪ BETWEEN 2 AND 12 ▪ BETWEEN 2..12 ▪ LIKE 'N%'
% zastupuje libovolný počet znaků i nulový
▪ LIKE '_ova'
_ zastupuje 1 znak
▪ v podmínkách lze používat i logické spojky AND a OR př.
použití příkazu SELECT na tabulky lidé a okresy
▪ select * from okresy vypíše celou tabulku okresy id_o
kra j
jméno
BE Beroun
SČ
BN Benešov SČ KT Klatovy ZČ VS Vsetín
SM
▪ select krestni, prijmeni from lide projekce vypíše jména a příjmení všech lidí z tabulky křestní příjmení
Zdena Malá Hana
Slavíková
Zuzana Šustrová Ivan
Vidím
Jiří
Vlak
Jiří
Vlk
▪ select * from lide, okresy spojení dvou tabulek bez použití spojovací filtrační podmínky I křestní příjmení D
1 Zdena Malá 2 Hana
rodné číslo
obec
765212/1245 Benešov
Slavíková 775123/1248 Zdice
id_o
BN BE Beroun
SČ
BE BE Beroun
SČ
3 Zuzana Šustrová
515420/0646 Zdice
BE BE Beroun
SČ
4 Ivan
Vidím
370212/1245 Klatovy
KT BE Beroun
SČ
5 Jiří
Vlak
511220/0666 Huslenky VS BE Beroun
SČ db 1 / 35
6 Jiří
Vlk
1 Zdena Malá 2 Hana
711230/0666 Huslenky VS BE Beroun 765212/1245 Benešov
Slavíková 775123/1248 Zdice
SČ
BN BN Benešov SČ BE BN Benešov SČ
3 Zuzana Šustrová
515420/0646 Zdice
BE BN Benešov SČ
4 Ivan
Vidím
370212/1245 Klatovy
KT BN Benešov SČ
5 Jiří
Vlak
511220/0666 Huslenky VS BN Benešov SČ
6 Jiří
Vlk
711230/0666 Huslenky VS BN Benešov SČ
1 Zdena Malá 2 Hana
765212/1245 Benešov
Slavíková 775123/1248 Zdice
BN KT Klatovy ZČ BE KT Klatovy ZČ
3 Zuzana Šustrová
515420/0646 Zdice
BE KT Klatovy ZČ
4 Ivan
Vidím
370212/1245 Klatovy
KT KT Klatovy ZČ
5 Jiří
Vlak
511220/0666 Huslenky VS KT Klatovy ZČ
6 Jiří
Vlk
711230/0666 Huslenky VS KT Klatovy ZČ
1 Zdena Malá 2 Hana
765212/1245 Benešov
Slavíková 775123/1248 Zdice
BN VS Vsetín
SM
BE VS Setin
SM
3 Zuzana Šustrová
515420/0646 Zdice
BE VS Setin
SM
4 Ivan
Vidím
370212/1245 Klatovy
KT VS Setin
SM
5 Jiří
Vlak
511220/0666 Huslenky VS VS Setin
SM
6 Jiří
Vlk
711230/0666 Huslenky VS VS Setin
SM
db 1 / 36
▪ select obec from lide where prijmeni ='Vlak' selekce spojená s projekcí - vypíše jméno obce, kde bydlí pan Vlak Huslenky
▪ select * from lide where id_o = 'BE' vypíše všechny údaje o všech lidech bydlících v okrese Beroun I křestní příjmení D
rodné číslo
2 Hana
775123/1248 Zdice BE
Slavíková
3 Zuzana Šustrová
obec id_o
515420/0646 Zdice BE
select cnt, id_o from lide group by id_o projekce podle atributu id_o spojená s použitím sumarizační funkce cnt BN 1 BE 2 KT 1 VS 2
▪ select okresy.kraj from lide, okresy where lide.id_o=okresy.id_o and lide.krestni='Zuzana' and lide.prijmeni='Šustrová' kombinace všech tří operací odpovídá na dotaz: "V kterém kraji bydlí Zuzana Šustrová?" SČ
▪ select * from OSOBA CL, OSOBA NAD where CL.ID = NAD.ID_NAD AND CL.PLAT > NAD.PLAT spojení tabulky sama se sebou, používá se alias pro název tabulky dotaz vybere zaměstnance, kteří mají větší plat než jejich nadřízený ▪ select distinct * from OSOBA vypuštění duplicitních řádků db 1 / 37
▪ select * from OSOBA, FIRMA where OSOBA.ICO = FIRMA.ICO vybere z kartézského součinu tabulek Osoba a Firma unikátní záznamy ▪ select * from OSOBA where PLAT = (select MAX(PLAT) from OSOBA) dotaz s poddotazem (složený SQL) ▪ SELECT * FROM Zamestnanci WHERE Jmeno LIKE 'Novák Jan'; vybere všechny zaměstnance, jejichž jméno je 'Novák Jan'. ▪ SELECT * FROM Zamestnanci WHERE Jmeno LIKE 'Nov%'; vybere všechny zaměstnance, jejichž jméno začíná na Nov ▪ SELECT * FROM Zamestnanci WHERE OsobniCislo = 1230; vybere zaměstnance s osobním číslem 1230 ▪ SELECT * FROM Zamestnanci WHERE Plat > 10000; vybere všechny zaměstnance, jejichž plat převyšuje 10 000 Kč ▪ SELECT * FROM Zamestnanci WHERE Jmeno LIKE 'Novák %' AND Plat < 6000; vybere všechny Nováky, jejichž plat je menší než 6 000 Kč ▪ SELECT Jmeno, Plat FROM Zamestnanci WHERE Plat > 15000 vybere jména a platy zaměstnanců, kteří mají plat větší než 15 000 Kč Vytvoření nové tabulky CREATE TABLE <jméno tabulky>
(<jméno sloupce 1>
CHAR
(
)
NUMBER DATE db 1 / 38
<jméno sloupce 2>
CHAR
()
NUMBER DATE ... ); př.
CREATE TABLE vcelari (jmeno CHAR (20), adresa CHAR (25), kraj CHAR (15), vcelstvo NUMBER (4), medu NUMBER (4) );
db 1 / 39
Vložení nové řádky do tabulky INSERT INTO <jméno tabulky> VALUES (<seznam konstant odpovídající prvkům řádky>); př.
INSERT INTO vcelari VALUES ('Adam, Adolf', 'Medova 15, Praha 5', 'Praha', 63, 482); INSERT INTO vcelari VALUES ('Beran Alois', 'Voskova 16, Praha 6', 'Praha', 85, 523);
př.
přidání nového včelaře, který ještě nemá včely
INSERT INTO vcelari VALUES ('Žihadlo, Emil', 'Na květné 4, Praha 4', 'Praha', NULL, NULL); příkaz může mít i tvar INSERT INTO vcelari jmeno, adresa - neuvedené prvky budou NULL VALUES ('Žihadlo, Emil', 'Na květné 4, Praha 4', 'Praha'); př.
kopie tabulky
SELECT * FROM vcelari; př.
zjistit kraje, kde se pěstují včely
SELECT DISTINCT kraje FROM vcelari; př.
najít všechny včelaře z krajů Praha, Ústí a Ostrava, kteří mají 50 až 100 včelstev
SELECT * FROM vcelari WHERE kraj IN ('Praha', 'Usti', 'Ostrava') AND vcelstvo BETWEEN 50 AND 100; př.
najít všechny včelaře, jejichž jméno začíná písmenem 'K'
SELECT * FROM vcelari WHERE jmeno LIKE 'K%';
db 1 / 40
př.
najít všechny včelaře, jejichž jméno končí na 'ova'
SELECT * FROM vcelari WHERE jmeno LIKE '%ova%'; př.
pojem prázdná hodnota (NULL) je různý od pojmu nulová hodnota
SELECT jmeno FROM vcelari WHERE medu=0; SELECT jmeno FROM vcelari WHERE medu IS NULL;
db 1 / 41
př.
vypsat včelaře v pořadí podle získaného medu od 500 kg výše
SELECT * FROM vcelari WHERE medu > 500 ORDER BY medu DESC; pokud by dva včelaři získali stejné množství medu, uvede se první ten, který má méně včelstev SELECT * FROM vcelari WHERE medu > 500 ORDER BY medu DESC, vcelstev; př.
mějme tabulky osobni, med85, med86 a med87, které mají stejnojmenné sloupce vypsat jméno, adresu a množství medu včelaře Žáry, Jiřího v roce 1985
SELECT jmeno, adresa, med85.medu FROM osobni, med85 WHERE osobni.jmeno = med85.jmeno AND jmeno = 'Žára, Jiří'; za sebe spojí řádky tabulek, které mají stejnou hodnotu klíče sloupce chybí-li hodnota klíče - ve spojení se tato hodnota neobjeví chceme-li i tuto hodnotu ve spojení, označí se symbolem (+) v podmínce spojení SELECT jmeno, adresa, med85.medu FROM osobni, med85 WHERE osobni.jmeno = med85.jmeno (+); př.
vypsat včelaře, kteří jsou v evidenci, ale nejsou v tabulce med85
SELECT jmeno, adresa FROM osobni, med85 WHERE osobni.jmeno = med85.jmeno (+) AND med85.medu IS NULL; v kvalifikaci lze místo jmen tabulek použít prefixy SELECT jmeno, adresa, T2.* FROM osobni T1, med85 T2 WHERE T1.jmeno = T2.jmeno (+) AND med85.medu IS NULL; př.
lze pracovat s dvěma kopiemi jedné tabulky, které se chovají jako různé tabulky (kopie jsou zdánlivé) vypsat jméno a adresy všech včelařů, kteří získali více medu než jejich předseda (tabulku vcelari rozšíříme o sloupec jmeno_predsedy) db 1 / 42
SELECT x.jmeno, x.adresa, x.medu FROM vcelari x, vcelari y WHERE.x.jmeno_predsedy = y.jmeno AND x.medu > y.medu; př.
podmínka spojení není jenom rovnost vypsat všechny včelaře, kteří získali více medu než Novák, Josef
SELECT x.jmeno, x.adresa, x.medu FROM vcelari x, vcelari y WHERE. y.jmeno = 'Novák, Josef' AND x.medu > y.medu;
db 1 / 43
př.
zařazení včelařů do kategorií podle tabulky hodnoceni kategorie
dolni_mez
horni_mez
1
100
999
2
50
99
3
10
49
SELECT kategorie, jmeno, vcelstvo FROM vcelari, hodnoceni WHERE. vcelstvo BETWEEN dolni_mez AND horni_mez ORDER BY kategorie; není-li žádná podmínka spojení - provede se kartézský součin tabulek př.
dotazy SQL lze řetězit - pro formulaci dotazu na vyšší úrovni lze použít výsledky dotazu na nižší úrovni vypsat včelaře, kteří patří do stejné organizace jako Novák, Josef
SELECT jmeno, adresa FROM vcelari WHERE jmeno_predsedy = (SELECT jmeno_predsedy FROM vcelari WHERE jmeno = 'Novák, Josef'); př.
v podotázce můžeme získat více hodnot (množinu) - musí se předřadit ANY
pro minimální prvek
ALL
pro maximální prvek
IN
má stejný význam jako ANY
vypsat všechny včelaře, kteří získali více medu než alespoň jeden včelař v kraji Ústí SELECT jmeno, adresa FROM vcelari WHERE medu > ANY (SELECT medu FROM vcelari WHERE kraj = 'Ústí') ORDER BY medu DESC; př.
vypsat všechny včelaře z kraje Praha, kteří mají více včelstev než kterýkoliv včelař z kraje Ústí db 1 / 44
SELECT jmeno, adresa FROM vcelari WHERE vcelstvo > ALL (SELECT vcelstvo FROM vcelari WHERE kraj = 'Ústí') AND kraj = 'Praha' ORDER BY vcelstvo DESC; př.
v klauzuli WHERE lze porovnat i n-tice prvků řádky tabulky vypsat všechny včelaře, kteří mají stejný počet včelstev a stejné množství získaného medu jako včelař Novák, Josef
SELECT jmeno, adresa, vcelstvo, medu FROM vcelari WHERE (vcelstvo, medu) = (SELECT vcelstvo, medu FROM vcelari WHERE jmeno = 'Novák, Josef'); př.
občas je potřeba přenášet do podotázky informace z nadřazeného dotazu a často se podřízený dotaz musí provádět opakovaně vypsat všechny včelaře, kteří získali více medu než je průměr v jejich kraji
SELECT jmeno, adresa, kraj, medu FROM vcelari X WHERE medu > (SELECT AVG(medu) FROM vcelari WHERE X.kraj = kraj) ORDER BY kraj DESC; př.
na řadě míst, kde se používá jméno sloupce lze použít výraz
SELECT jmeno, medu / vcelstvo FROM vcelari; má-li proměnná s prázdnou hodnotu, má prázdnou hodnotu celý výraz př.
náhradu prázdné hodnoty konkrétní hodnotou umožňuje funkce NVL NVL (<proměnná>, )
SELECT jmeno, medu / NVL (vcelstvo, 1) Průměr FROM vcelari; př.
zjistit průměrný, minimální a maximální počet včelstev v kraji Praha db 1 / 45
SELECT AVG(vcelstvo), MIN(vcelstvo), MAX(vcelstvo) FROM vcelari WHERE kraj = 'Praha'); př.
zjistit počet včelařů v kraji Praha
SELECT COUNT(jmeno) FROM vcelari WHERE kraj = 'Praha'); př.
zjistit včelaře, který získal nejvíce medu v kraji Praha
SELECT jmeno, adresa, medu FROM vcelari WHERE kraj = 'Praha' AND medu = (SELECT MAX(medu) FROM vcelari WHERE kraj = 'Praha'); př.
zjistit v kolika krajích včelaři pracují
SELECT COUNT(DISTINCT kraj) FROM vcelari; př.
klauzule GROUP BY - skupiny podle klíče vypsat průměrné množství medu v jednotlivých krajích
SELECT kraj, AVG(medu) Průměr FROM vcelari GROUP BY kraj; př.
zjistit počet a průměrný plat zaměstnanců rozdělených do skupin
SELECT katedra, funkce, COUNT(*), AVG(plat) FROM fakulta GROUP BY katedra, funkce; př.
zjistit průměrný plat skupin, které mají více než 25 členů
SELECT funkce, COUNT(*), AVG(plat) FROM fakulta GROUP BY funkce HAVING COUNT(*) > 25; prázdné hodnoty se nezúčastňují výpočtů GROUP BY, HAVING př.
nalézt všechny katedry, které mají alespoň dvě sekretářky
SELECT katedra FROM fakulta WHERE funkce = 'sekretářka' GROUP BY katedra db 1 / 46
HAVING COUNT(*) >= 2; př.
nalézt všechny katedry, kde průměrný plat odborného asistenta je větší jak 3000 Kč
SELECT katedra, AVG(plat) FROM fakulta WHERE funkce = 'odborný asistent' GROUP BY katedra HAVING AVG(plat) > 3000; př.
nalézt druhy zaměstnání, které mají vyšší průměrný plat než je průměrný plat docentů
SELECT funkce, AVG(plat) FROM fakulta GROUP BY funkce HAVING AVG(plat) > (SELECT AVG(plat) FROM fakulta WHERE funkce = 'docent'); př.
změnit údaje v tabulce - pan Beran, Alois se přestěhoval a má 92 včelstev
UPDATE vcelari SET adresa = 'Na vsi 256, Benešov', vcelstvo = 92 WHERE jmeno = 'Beran, Alois'; př.
přidání platu o 20% dostali zaměstnanci fakulty, kteří jsou uvedeni v seznamu zmenapl
UPDATE fakulta SET plat = plat * 1.2 WHERE (SELECT jmeno FORM zmenapl)'; př.
přidat sloupec "varoaza" do tabulky vcelari
ALTER TABLE vcelari ADD (varoaza NUMBER (1)); př.
sloupci plat v tabulce fakulta upravit rozsah db 1 / 47
ALTER TABLE fakulta MODIFY (plat NUMBER (8,2));
db 1 / 48
Datové sklady (warehause) - obrovská databáze obsahující data za dlouhé časové období ▪ často slučuje data z více rozdílných zdrojů, které mohou obsahovat data různé kvality nebo používat nejednotné formáty a reprezentace ▪ objemově zabírá stovky GB až několik TB ▪ nemusí být databází v běžném smyslu, tj. pro přesné provádění transakcí ▪ je určena pro rychlé vyhledávání a přidávání ▪ nejsou kladeny nijak důrazné požadavky na správnost a úplnost dat - data jsou uložena na různých místech ve formě relačních tabulek ▪ uživatelé mohou tabulky jen číst ▪ zapisovat může aktualizační program pravidelně udržující tabulky - dotazy jsou většinou komplexní ▪ podporují tzv. on-line analytické zpracování (OLAP) ▫ výrazně se liší od on-line transakčního zpracování (OLTP) ▫ operační databáze je přizpůsobena pro podporu OLTP, složité OLAP dotazy by vyústily do nepřijatelné odezvy ▫ typické OLAP operace • rollup (zvýšení stupně agregace) • drill-down (snížení stupně agregace) • slice_and_dice (selekce a projekce) • pivot (přeorientování vícerozměrného pohledu na data) - na základě dotazu si pospojuje potřebná data do vícerozměrné tabulky (nebo více tabulek), do kterých lze klást SQL dotazy - pro častější dotazy si uchovávají předem připravené vícerozměrné tabulky - zátěž je většinou způsobena složitými dotazy, jež přistupují k miliónům záznamů a provádějí množství operací - data bývají modelována vícerozměrně ▪ např. v obchodním data warehouse mohou těmito rozměry být ▫ čas prodeje, místo prodeje, prodavač, výrobek ▪ rozměry mohou být i hierarchické např. ▫ čas prodeje jako den-měsíc-čtvrtletí-rok db 1 / 49
▫ zboží jako výrobek-kategorie-průmysl ▪ spojení více tabulek pomocí odkazu na řádky jednotlivých tabulek ▪ používají speciální organizaci dat, přístupové a implementační metody, jež obecně nejsou v komerčních databázových systémech určených pro OLTP podporovány Architektura data warehouse - data z externích zdrojů a z operačních databází jsou vyčištěna, transformována a uložena do samotného data warehouse ▪ vše je obhospodařováno OLAP servery - navržení a vytvoření je proces skládající se z následujících bodů ▪ definovat architekturu, umístění a rozčlenění dat a fyzickou organizaci ▪ naplánovat kapacitu ▪ vybrat OLAP servery a nástroje ▪ spojit servery, klientské nástroje, zdroje přes gatewaye, drivery ODBC, ... ▪ navrhnout schéma a pohledy, přístupové metody, některé složité dotazy ▪ vytvořit skripty pro získávání, čištění, transformaci, ukládání a aktualizaci dat ▪ vytvořit koncové uživatelské aplikace ▪ spustit data warehouse i aplikace ▪ vytvoření je složitý proces trvající mnohdy i několik let ▫ mnoho organizací proto používá tzv. data marts • jde o jakési součásti data warehouse orientované určitým směrem • umožňují rychlejší práci • při obecnějším dotazu dochází k problémům - čištění dat se používá pocházejí-li data z více různých zdrojů a je pravděpodobné, že budou obsahovat chyby (nesprávné přiřazení hodnoty, chybějící vstupy, …) - obecně se rozlišují tři druhy čištění dat: ▪ data migration - jednoduché nahrazování řetězců ▪ data scrubbing - při čištění dat z více zdrojů eliminace duplicitních dat, možnost definovat si tzv. "relativní čistotu" ▪ data auditing - využití pravidel a vztahů, v podstatě data-mining - ukládání dat přináší problémy (otázky) db 1 / 50
▪ jak uložit obrovský objem dat během krátkého časového rámce (jedné noci) a zajistit obnovení dat pro případ neúspěchu při ukládání ▫ místo sekvenčního ukládání využít paralelismus, checkpointy ▪ aktualizace dat - uvážit, jak často aktualizovat Data Mining - důležitá součást větších skladů dat - dotazy v SQL poskytují málo komplexní výběr ▪ většina dotazu na Data warehouse je v jistém smyslu tak podobná ▪ vyplatí se pro ně připravit specializovaný dotazovací jazyk ▪ je bližší více umělé inteligenci než běžnému dotazovacímu jazyku ▪ v současnosti má velmi malou výkonnost - princip - uživatel zadá dotaz a vyhledávací stroj mu poté nabídne ▪ odpověď na to co chtěl ▪ případně nějakou nejbližší informaci podobnou tomu na co se ptal ▪ přiklad dotazu ▫ co se vyskytuje v blízkosti golfových hřišť (max 3 km)? ▫ jaký byl největší vzestup na burze, který byl do 2 dnů následován poklesem? ▫ jaké zboží si koupí zákazník navíc, pokud si koupí plnicí péro? - pro zodpovězení podobných dotazů, je potřeba ▪ vytvořit vhodný jazyk ▪ vyhledávací program musí rozumět datům ▫ existují systémy data miningu 2 generací • jednoduché vyhledávání a odvozování jednoduchých závislostí • vyhledávání vícenásobných závislostí a hledání ve špatně strukturovaných datech jako je např. html, WWW, ... ▫ zatím jsme někde v blízkosti první generace - v datech je potřeba vyhledávat nějaké znalosti ▪ jedná se o odvozovací pravidla např. koupil si pero --> koupil si i tužku ▫ pravidlo nemusí mít stoprocentní pravdivost ▫ ke každému pravidlu se přidávají doplňující čísla db 1 / 51
• podpora (support) - počet řádků, ve kterých si zákazník koupil pero • důvěryhodnost (confidence) - počet řádků, ve kterých si zákazník koupil pero i tužku ▫ tyto údaje je možné zadat z dotazovacího jazyka • jsou klíčové, pro celý proces hledání a odvozování dalších pravidel ▪ lze hledat i pravidla, která mají na levé i pravé straně pravidla množinu - z pravidel se dá postavit struktura závislostí připomínající strom - klade to velké nároky na prostor i čas - nevhodná pravidla s malou podporou či důvěryhodnosti nepoužívat nebo nějak omezit - pro rychlé vyhledávání se vytváří indexy, pro často dotazované sloupce - index se vytváří pro každý sloupec zvlášť ▪ musí se vědět jaké hodnoty se v sloupci mohou vyskytnout ▪ př. sloupec typ_jídla může obsahovat {zelenina, ovoce, maso, sója} ▫ pro každou z hodnot vytvoříme jeden index ▪ indexování má několik principů např. ▫ RID-LIST indexing ▫ BITMAP indexing ▪ pro další předpokládáme, že každá řádka má svoje id ▫ na jednoznačné určení řádek tabulky, stačí klíč tabulky ▫ id pomoci pořadí je nejkratší, což klíč nemusí splňovat ▫ vypouští-li se z databáze minimálně a rozhodně ne s náhodným přístupem (jako v transakcích), potom je id dobrým řešením ▪ RID-LIST je seznam id těch řádků, které mají danou hodnotu ▫ tabulka osob a oblíbených jídel ▫ pepa
zelenina
▫ franta
sója
▫ rudolf
ovoce
▫ jitka
ovoce
▫ jakub
sója
▫ honza
maso
▫ .. db 1 / 52
▫ potom RID-LISTy budou vypadat následovně • zelenina
1
• ovoce
3,4
• maso
6
• sója
2,5
▪ BITMAP indexing ▫ zde se id nepředpokládají ▫ BITMAP je pole, ve kterém je pro každý řádek 0 nebo 1 • 0 sledovaná hodnota je v konkrétním řádku • 1 sledovaná hodnota není v konkrétním řádku ▫ BITMAPy budou vypadat následovně • zelenina
100000
• ovoce
001100
• maso
000001
• sója
010010
▪ RID-LIST zabírá na disku vždy stejné velké množství místa ▪ BITMAP je výhodný pokud je málo různých hodnot ▫ zpravidla je hodně řídký - dá se speciální kompresí zkrátit ▫ pro více hodnot je BITMAP nepoužitelný - používají se občas oba principy - zjišťuje se, který je výhodnější ▪ případně se provede konverze na druhy ▪ konverze jsou jednoduché a rychlé ▪ ušetří-li konverze např. 100MB, tak je vhodná ▪ nepředpokládá se, že by se konverze tam a zpět prováděly často - výhoda BITMAPu ▪ jednoduchý přístup ▪ možnost provádět logické operace and, or, ... ▪ jednoduché stránkování – lze načíst jen konkrétní stránku BITMAPy
db 1 / 53
