of 23 /23
18.4.2019 1 Databázové systémy Doc. Dr. Ing. Jiří Horák Institut geoinformatiky Literatura Pokorný J., Halaška I.: Databázové systémy. ČVUT Praha 2004. Šarmanová: Teorie zpracování dat, VŠB Ostrava, 1997. Pokorný J.: Konstrukce databázových systémů. ČVUT Praha 1998. Pokorný J., Halaška I.: Databázové systémy, ČVUT Praha 1995. Krčmář, Farana: Vybrané algoritmy zpracování informací, VŠB Ostrava, 1996. Churcher, Clare. Beginning Database Design. Berkeley, CA: Apress, 2007 Kolekce podkladů: http://homel.vsb.cz/~hor10/Vyuka/DBS/ PDF, 18 MB Data a informace. Modelování reality Data – formalizované aspekty reality, např. výsledky měření, pozorování Informace – vzniká interpretací dat, jejich význam, důležitý kontext Znalosti – zobecněné poznání reality, vyšší abstrakce, stálejší Příklad: sledování nabídek aut, zápis pro mne důležitých údajů (=data), jejich porovnání, co je běžné, co je zvláště výhodné (informace), delším sledováním získáme o vývoji cen a zkušenosti, co je ovlivňuje (znalosti) Data a informace. Modelování reality Data (stavy reality v určitém okamžiku) Informace (data + kontext + odvoz.mech.) Znalosti (informace + kontext + zkušenosti + odvoz.mech.) Historie zpracování dat Prehistorické období Problémy – vše je v mém programu, kopie dat, redundance, oprava dat vede k nové kompilaci atd. Agendové zpracování Systém pro zpracování souborů – součást OS Data vyčleněna do samostatných souborů

Databázové systémy - homel.vsb.czhomel.vsb.cz/~hor10/Vyuka/DBS/DBSosnova2019 po6.pdf · 18.4.2019 2 Problémy agendového zpracování dat Databázová technologie • Redundance

  • Author
    others

  • View
    1

  • Download
    0

Embed Size (px)

Text of Databázové systémy - homel.vsb.czhomel.vsb.cz/~hor10/Vyuka/DBS/DBSosnova2019 po6.pdf ·...

  • 18.4.2019

    1

    Databázové systémy

    Doc. Dr. Ing. Jiří Horák

    Institut geoinformatiky

    Literatura • Pokorný J., Halaška I.: Databázové systémy. ČVUT Praha

    2004. • Šarmanová: Teorie zpracování dat, VŠB Ostrava, 1997. • Pokorný J.: Konstrukce databázových systémů. ČVUT Praha

    1998. • Pokorný J., Halaška I.: Databázové systémy, ČVUT Praha

    1995. • Krčmář, Farana: Vybrané algoritmy zpracování informací,

    VŠB Ostrava, 1996. • Churcher, Clare. Beginning Database Design. Berkeley, CA:

    Apress, 2007 • Kolekce podkladů: http://homel.vsb.cz/~hor10/Vyuka/DBS/

    PDF, 18 MB

    Data a informace. Modelování reality

    • Data – formalizované aspekty reality, např. výsledky měření, pozorování

    • Informace – vzniká interpretací dat, jejich význam, důležitý kontext

    • Znalosti – zobecněné poznání reality, vyšší abstrakce, stálejší

    • Příklad: sledování nabídek aut, zápis pro mne důležitých údajů (=data), jejich porovnání, co je běžné, co je zvláště výhodné (informace), delším sledováním získáme o vývoji cen a zkušenosti, co je ovlivňuje (znalosti)

    Data a informace. Modelování reality

    • Data (stavy reality v určitém okamžiku)

    • Informace (data + kontext + odvoz.mech.)

    • Znalosti (informace + kontext + zkušenosti + odvoz.mech.)

    Historie zpracování dat

    • Prehistorické období

    • Problémy – vše je v mém programu, kopie dat, redundance, oprava dat vede k nové kompilaci atd.

    Agendové zpracování

    • Systém pro zpracování souborů – součást OS • Data vyčleněna do samostatných souborů

    http://homel.vsb.cz/~hor10/Vyuka/DBS/

  • 18.4.2019

    2

    Problémy agendového zpracování dat

    • Redundance – informace se v souborech zbytečně opakují, aplikace používají jiné formáty

    • Nekonzistence – varianty stejných dat zapsaných v různých souborech (či jen místech v souboru) se začnou lišit

    • Ztráta integrity – data jsou neaktuální, neodrážejí stav reality • Obtížná dosažitelnost dat – na každý nový dotaz je třeba novou

    aplikaci • Izolovanost dat - data různě uložena, na různých místech, různé

    formáty • Obtížný současný přístup více uživatelů – umí ho jen některé

    aplikace (CAD) a jen pro některé činnosti, jinak se otevře jen kopie na čtení apod.

    • Ochrana proti zneužití – nedostatečná soustava práv na úrovni OS, navíc je potřeba chránit rozdílně rozdílné údaje uvnitř souboru

    Databázová technologie

    Výhody databázové technologie 1. Oddělení datových struktur od programů – popis dat (datová struktura) je

    uložena přímo v datovém souboru (datový katalog) nebo externě, ale ne v programové aplikaci. Program si strukturu načte a pak mohou s daty provádět potřebné operace. Při změně datové struktury není třeba měnit programy a při změně programu není nutné měnit datovou strukturu.

    2. JDD (DDL) – existuje seznam základních datových typů, které jsou v SŘBD definovány, z nich se vytváří datové struktury. Jazyk pro definici dat JDD umožňuje definovat datové struktury. SŘBD řeší sám způsob jejich uložení a přístup k nim.

    3. JMD (DML) – jazyk pro manipulaci s daty. Soubor instrukcí pro provádění operací s daty. SŘBD řeší fyzický přístup k datům i realizaci operace.

    4. DJ (QL) – dotazovací jazyk. Instrukce pro dotazování i nečekané dotazy. Dotazy jsou formulovány bez nutnosti programování.

    5. Vazby mezi daty – SŘBD řeší způsob jak zaznamenat vztahy mezi daty. 6. Víceuživatelský režim 7. Ochrana dat – autorizace (definice přístupových práv na různých úrovních)

    a autentizace (hesla)

    Informační systém. Rozdělení IS

    • Informační systém (IS) - soubor lidí, technických prostředků a metod, zabezpečujících sběr, přenos, uchování a zpracování dat za účelem tvorby a prezentace informací pro potřeby uživatelů činných v systémech řízení.

    • IS je systémem (tj. souborem prvků ve vzájemných informačních a procesních vztazích, souhrnně informační procesy), které zpracovávají data a zabezpečují komunikaci mezi prvky.

    • IS se často člení na systém zpracování dat a komunikační systém.

    Rozdělení IS

    • automatizovaný informační systém (AIS)

    • podle informačního prostředí - podle daného světa objektů, pro podobná informační prostředí budou existovat podobná IS. Typové projekty. IS „Knihovna“ nebo „Lékárna“.

    • převládající funkce, kterou plní IS: 1. dokumentografické (Storage and Information Retrieval Systems)

    2. faktografické (Information Management Systems)

    3. měřící, regulační (používané v IS řízení technologických procesů).

    • režim činnosti IS: a) individuální zpracování požadavku b) dávkové zpracování dat c) zpracování dat v reálném čase d) integrované zpracování dat v centralizovaných databázích či

    v distribuovaném systému počítačů nebo distribuované bázi dat.

    • aplikace podnikové informatiky: – Infrastrukturní aplikace (aplikace pro správu dokumentů, správu

    webového obsahu, řízení pracovních toků apod.). Celé komplexy se označují jako ECM (Enterprise Content Management).

    – Celopodnikové transakční aplikace (ERP). Vytváření rozsáhlých datových bází, realizace procesů operačního charakteru, vytvářet a prezentovat výstupy.

    – Aplikace řízení externích vztahů

  • 18.4.2019

    3

    • 3 úrovně řízení • Transakční systémy

    • Management IS MIS (IS pro podporu taktického a operativního řízení)

    • Decision Support System

    • Datové sklady DWH – OLAP, data mart, cloud

    • Exekutivní IS EIS – Business Intelligence

    • Electronic Document Interchange

    • Office IS

    Databázový systém (DBS)

    • DBS = SŘBD + BD (DBS = DBMS + DB)

    • aIS = DBS + KS

    • aIS automatizovaný IS

    • KS komunikační subsystém

    • SŘBD Systém řízení báze dat

    SŘBD a jeho funkce

    • Programový systém – umožňuje definovat datové struktury a soubory, řeší fyzické uložení dat, řeší manipulaci s daty, ad hoc dotazování, řídí přístupy osob i aplikací, výstupní formátování, ochrana dat.

    • Založen na databázovém modelu (relační, hierarchický, objektový, objektově-relační,..)

    • JMD - 4 základní operace – výběr (SELECT), vložení (INSERT), smazání (DELETE), aktualizace (UPDATE)

    JMD

    • Výběr (SELECT) ... žádná změna uložených dat, virtuální tabulka, nemění se počet záznamů

    • Vložení (INSERT) … přidání dalších datových záznamů (roste počet řádků v tabulce)

    • Mazání (DELETE) … ubývají datové záznamy (snižuje se počet řádků v tabulce)

    • Aktualizace (UPDATE) …počet záznamů se nemění (počet řádků v tabulce je stejný), mění se hodnoty v atributech existujících záznamů

    Tři úrovně struktury dat

    1. Externí schémata – různé pohledy uživatelů, jednotlivé aplikace pro koncové uživatele, účelovost. Každé ES popisuje jen část IS.

    2. Konceptuální schéma – integrace všech požadavků, zobecněné, aplikačně nezávislé, společný a srozumitelný jazyk pro vývojáře i uživatele. Existuje jen 1.

    3. Interní schéma – fyzická úroveň organizace dat, soubory, fyzické záznamy, stromové struktury. Více variant.

    • logické schéma – popisuje db implementaci (konkrétní

    datové typy a konstrukty)

  • 18.4.2019

    4

    Konceptuální schéma

    • Sémantické modely různé úrovně

    • Např. plán výuky

    • Implementačně nezávislé, nezávislé na uložení dat

    • Pohled člověka na danou část reálného světa pro jistý účel

    • Popis přirozeným jazykem nestačí

    • Řada nástrojů implementace: – ERA

    – UML – diagram tříd

    – OR, HIT

    ERA diagram

    • Entita (entity) – rozlišovat typ a výskyt – objekt reálného světa, schopen nezávislé existence a odlišitelný od ostatních objektů

    • Vazba (relationship) – rozlišovat typ a výskyt – vztah mezi 2 či více entitami

    • Popisný atribut (attribute) - podstatná vlastnost entity nebo vztahu, nebo také funkce mapující pro daný výskyt entity hodnotu z dané domény

    • Hodnota popisného typu (value) – dvojice datový typ a hodnota

    • Není jednoznačné určit, co je entita, atribut, vztah – závisí i na účelu

    • Integritní omezení (IO) – logické omezení na data

    Typový diagram

    • Chenův diagram

    • Textový zápis: UČITEL(rč, jméno, příjmení, titul, datnar, bydliště)

    Výskytový diagram

    Entita

    • Definice • pojmenování • Sémantika – podrobné vysvětlení významu, co a

    jak se má zapsat (evidovat) • vznik/zánik – kdy a jak entita vzniká a kdy zaniká? • počet výskytů – kolik maximálně očekáváme

    výskytů? • Čas – např. vlastnictví teď a nebo kdykoliv?

    • Příklady – student, vlastnictví, kniha x exemplář

    Identifikační klíč

    • Kandidáti na roli IK

    • Identifikační klíč osoby:

    – RČ

    – ČOP

    – Č pasu

    – zaměstnanecké číslo

    – Křestní jméno + příjmení + datum narození

    – DNA

    • Zobrazení – podtržení, šipka od atributu k entitě

  • 18.4.2019

    5

    Vztahy mezi entitami - násobnost

    • Počet typů entit zapojených do vztahu

    • Unární – rekurzivní (př. je šéfem, je příbuzný s)

    • Binární – nejběžnější a „standardní“

    • Ternární (př. vlaková četa)

    • A další

    • transformace na binární

    Unární vazby – příklad:

    Vztahy mezi entitami - kardinalita • Počet výskytů entit zapojených do vztahu • 1:1 • 1:N • M:N • Příklad Učitel učí předmět:

    – Každý Učitel učí max. 1 Předmět – Každý Předmět je vyučován max. 1 Učitelem

    – Každý Učitel (může) učit více Předmětů – Každý Předmět je vyučován max. 1 Učitelem

    – Každý Učitel učí max. 1 Předmět – Každý Předmět může být vyučován více Učiteli

    – Každý Učitel může učit více Předmětů – Každý Předmět může být vyučován více Učiteli

    • Determinance – oboustranně determinující vztah, jednostranně determinující, nedeterminující • Symetrie vztahu • Grafické a popisné označení • Min-max

    příklady

    • Manželství (muž, žena)

    • Osoba - auto

    • Osoba - nemovitost

    • Student - fakulta

    Dekompozice M:N

    • Průniková entita

    • 2 vztahy 1:N

    • Povinné identifikační klíče v průnikové entitě

    Vztahy mezi entitami - parcialita

    • Členství ve vztahu – povinné x nepovinné

    • Totální

    • Jednostranně parciální

    • Oboustranně volné

    • Graficky, textově

  • 18.4.2019

    6

    Vztahy mezi entitami • Příklady:

    – Manželství – Osoba - auto – Osoba - nemovitost – Student - fakulta

    • Správné dotazy:

    – Kardinalita: Může být 1 výskyt entity A zapojen k více výskytům entity B? (tj. najdete aspoň 1 příklad, kdy je 1 výskyt A zapojen do vztahu s více výskyty B?)

    – Parcialita: Musí být každý výskyt entity A zapojen do vztahu s nějakým výskytem entity B? (tj. najdete aspoň 1 příklad, kdy je výskyt entity A volný, bez vztahu k B, pak jde o negaci)

    Přenositelnost vztahu

    • Transferable relationships - kosočtverec

    • Lze vztah přepojit k jiném výskytu entity?

    • Nelze např. recept

    Vztahy mezi entitami – přesnější kardinalita a parcialita

    • Min-max

    • E1: (min, max) – min a max počet výskytů entity ve vztahu

    • VÝPŮJČKA(ČTENÁŘ:(0,4), EXEMPLÁŘ:(0,1))

    • ZÁZNAMY(ČTENÁŘ:(0,4), KNIHA:(0,m))

    • MÁ-KOPIE(KNIHA:(1,n), EXEMPLÁŘ:(1,1))

    Slabé entitní typy

    • Barred relationships

    • Entitní typ samostatně nemůže existovat

    • Identifikační vztah

    • Identifikační vlastník

    • Vedoucí DP vypisuje téma DP

    • Téma DP nemůže existovat samostatně

    Atribut

    • Funkce (přiřazující výskytu entity konkrétní hodnotu z domény) či vlastnost (podstatná vlastnost)

    • Vlastnost – délka malíčku? • Musí příslušet k dané entitě či vztahu (např. počet

    spolupacientů není vhodný) • Doména • Klíčový atribut • Parcialita – musí být vyplněn? • Volatilita – problém např. věk

  • 18.4.2019

    7

    Neatomické atributy

    • Skupinové popisné atributy:

    • ADRESA (stát, obec, ulice, číslo)

    • Vícehodnotové popisné atributy:

    • ZAMĚSTNANEC(….., JMÉNA_DĚTÍ: multi)

    ISA hierarchie

    • Podtypy entit

    • OSOBA (ID, jméno, dat nar, ..)

    • ZAMĚSTNANEC (IDZAM, oddělení, plat, datum nástupu,..) ISA OSOBA

    • UČITEL (funkce, akademická hodnost, ..) ISA ZAMĚSTNANEC

    Jiné konceptuální modely • OR • HIT – Homogenní Integrovaný Typově orientovaný

    model – typ (popisný, objektový), pseudoatribut (6 typů)

    • UML – diagram tříd • Konstruktory:

    – Agregace - vztah objektů niž.typu považován za objekt vyššího typu

    – Sortalizace – třídění entit do sort (např. entitní typy) – Klasifikace – třídy objektů jako objekty vyššího typu

    (neoblíbené přednášky) – Specializace - podtyp – Generalizace - nadtyp – Seskupování – vytvoření podmnožin objektů (plán

    přednášek, měsíční program kina)

    Agregace, seskupení, generalizace/specializace

    OR Object-Role model

    • Objekt, asociace, role

    • Objekty – řetězcové (z domény), neřetězcové

  • 18.4.2019

    8

    UML - diagram tříd

    • Objekt, asociace

    • 3 části v obdélníku:

    – Jméno třídy

    – Atributy objektů třídy

    – Operace použitelné na objekty třídy

    • Asociace min – max, ale opačně psané

    UML - diagram tříd

    • Vztahy: – Agregace - třída je součástí jiné třídy (vztah celek-část) (prázdný

    kosočtverec)

    – Kompozice – silná agregace, část je součástí jen 1 celku, smazáním celku zaniká (plný kosočtverec)

    – Generalizace – šipka směřuje k nadtřídě

    – Je instancí ---

    • Prefixy:

    UML - diagram tříd • Pozor, kardinality jsou na opačné straně proti běžnému UML

    Funkční analýza

    • Diagram funkční struktury

    • Hierarchie, top-down

    • Př. Cestování vlakem

    • Diagram toku dat (data flow diagram)

    Diagram toku dat • návrh a zobrazení funkčního modelu systému.

    • DFD popisuje dynamiku systému, vyjadřuje transformace dat z jedné formy do druhé; modeluje funkce systému pomocí grafu a přitom používá následujících základních grafických prvků:

    • procesy (funkce, provádí transformaci dat)

    • paměti (zásobárny dat)

    • Terminátory (externí p.)

    • datové toky

    • Identifikace, popis

    • Pravidla

    • Hierarchie – kontextový, 0., … minispecifikace

    Hierarchie DFD

  • 18.4.2019

    9

    Pravidla DFD

    • Nesmí existovat proces generující výstupy bez pomoci vstupů (perpetum mobile).

    • Nesmí existovat proces, který má pouze vstupy a žádné výstupy (černá díra).

    • Datové paměti smějí být propojeny jen prostřednictvím funkce, tedy datový tok do / z paměti musí vycházet z / do procesu.

    • Datový tok z / do terminátoru musí procházet přes proces. • Datové toky mezi funkcemi znázorňují pouze přenášená data,

    nevyjadřují volání jedné funkce druhou ani předávání řízení. • Datový tok s týmž názvem může být v DFD použit na více místech

    pokud název znamená skutečně tentýž datový tok se stejným obsahem

    • Pravidla týkající se datových pamětí • Pravidla týkající se funkcí

    Relační databázový model

    • Def1: Relační databáze je taková databáze, kterou uživatel vnímá jako soustavu v čase proměnných normalizovaných tabulek s uspořádanými sloupci (Molnár)

    • Def2: Nechť je dán systém Di (i od 1 do n) neprázdných množin (domén). Potom podmnožinou kartézského součinu R D1 x D2 x D3 .. Dn nazveme relací stupně n (n-ární relací) nad D1, D2, D3,.. Dn. Prvky R jsou uspořádané n-tice (d1, d2, d3, .. dn), pro které platí, že každé di je prvkem Di. Bází dat nazveme konečnou množinu v čase proměnných konečných relací, které jsou definované nad doménami ze systému množin Di.

    Relační DBS a jeho podmínky

    • Relace je vybavena pomocnou strukturou = schéma relace, které se skládá ze jména relace, jmen atributů a domén.

    • R(A1:D1, A2:D2, …An:Dn)

    • Relační schéma databáze (R, I)

    • I je množina integritních omezení IO

    • Klíče – klíčové atributy.

    • Jednoduchý a složený klíč

    • Dotazování pomocí relační algebry či relačního kalkulu

    Podmínky relační DBS

    • Každá tabulka má jedinečný název • Každý sloupec má jedinečný název – v tabulce • Každá tabulka obsahuje jen řádky stejného typu (jednoduchá

    struktura tabulky) • Na pořadí sloupců nezáleží (identifikace jménem sloupce) • Na pořadí řádků nezáleží • Každý řádek je identifikován PK • Každý sloupec obsahuje jen hodnoty 1 typu, z 1 domény • Každý řádek tabulky odpovídá jednomu výskytu entity • Všechny hodnoty na řádku jsou plně závislé na PK (normalizace) • Každé políčko tabulky je buď neobsazené (NULL) nebo obsahuje

    právě 1 hodnotu z dané domény.

    Integritní omezení relačních DBS

    • IO – jakákoliv logická omezení dat:

    1. Integrita entit (primární klíč)

    2. Integrita domén

    3. Referenční integrita

    4. Ostatní IO

    Primární klíč

    • Jedinečný (unique)

    • Neprázdný (not null)

    • Minimální (složený jen těch atributů, které jsou nezbytné pro zajištění jedinečnosti; žádné navíc)

    • PRIMARY KEY

    • Kandidátní klíče

    • Alternativní klíče

  • 18.4.2019

    10

    Integrita domén

    • Atribut je vybírán právě z 1 domény

    • Např. nelze do číselného pole zadat „1996)

    Příklad volitelného umístění IO CREATE TABLE Student (idstud char(6) PRIMARY KEY, jmeno varchar2(60)

    UNIQUE); CREATE TABLE Referaty (id INTEGER PRIMARY KEY, student CHAR(6) REFERENCES Student, datum DATE DEFAULT SYSDATE, tema VARCHAR(50)); CREATE TABLE Referaty (id INTEGER, student CHAR(6), datum DATE DEFAULT SYSDATE, tema VARCHAR(50), PRIMARY KEY (id), FOREIGN KEY(student) REFERENCES Student);

    Relační algebra

    • Množinové operace: – kartézský součin x

    – Průnik ∩

    – Sjednocení U

    – Rozdíl -

    • Typicky relační operace: – Selekce R(φ) t1Θt2 , kde t1Θt2 je (, =, ≥, ≤, )

    – Projekce R[B]

    – Spojení R*S

  • 18.4.2019

    11

    Relační algebra – množinové operace

    Relační algebra – množinové operace v SQL

    SELECT id, jmeno, adresa FROM student1

    UNION

    SELECT id, jmeno, adresa FROM student2;

    Průnik – INTERSECTS

    Rozdíl - MINUS

    Relační algebra - spojení

    • Přirozené spojení R*S

    • Theta-spojení R[t1Θt2]S

    SELECT * FROM objednavka NATURAL JOIN zakaznik;

    SELECT * FROM objednavka JOIN zakaznik ON (objednavka.KODZAK= zakaznik.KODZAK);

    Atomické klauzule t1Θt2 Spojené logickými spojkami NOT, OR, AND, XOR

    t1 – název atributu nebo konstanta

    Θ =, ,

    Relační algebra - spojení

    • R*S

    • R[C=E]S

    • R[A

  • 18.4.2019

    12

    Bublinová metoda

    • Co určuje co (co na čem závisí)

    • ODBYT(CIS_ZAK, JMENO, ADRESA, CIS_UCTU, CIS_OBJ, DATUM, MISTO_DOD, CIS_VYR, NAZEV, MNOZ_OBJ, CENA, VAHA, CIS_SKL, MNOZ_NA_SKL, UMISTENI, PLOCHA, DRUH)

    • Vytvořte diagram s bublinami a šipky ukazují vazby

    Funkční závislosti

    • Definována mezi 2 množinami atributů v 1 schématu

    • B→C

    • B funkčně určuje C (C závisí funkčně na B), když ke každé B-hodnotě existuje nanejvýš 1 C-hodnota.

    • Přednáška, Učitel, Student, Hodina, Místnost, Známka

    • P→U, HM→P, HU→M, PS→Z, HS→M

    • Multizávislosti – k jedné B-hodnotě existuje více C-hodnot

    Funkční závislosti – Armstrongova p.

    1. Triviální funkční závislost: • Y c X => X→Y • Např. H c HM => HM→H 2. Tranzitivita • X→Y AND Y→Z => X→Z 3. Kompozice • X→Y AND X→Z => X→YZ 4. Dekompozice • X→YZ => X→Y, X→Z Ad 1: HM→H, HU→H Ad 2: HM→P AND P→U => HM→U Ad 3: HU→M AND HU→H => HU→HM

    Funkční závislosti - postup

    • Vytvořit elementární závislosti (na pravé straně 1 atribut)

    • Odstranění redundantních závislostí, není jednoznačné, závisí na pořadí

    • Minimální pokrytí (na levé straně nejsou redundantní atributy), uzávěr

    Normalizace relačních tabulek • Minimalizace redundance při zachování integrity a

    konzistence db • Jednoznačnost a správnost odpovědí na dotazy • Rozklad na menší tabulky • Bezztrátová dekompozice • Normální formy (každá další splňuje předchozí):

    – 1NF – pouze atomické hodnoty – 2NF – všechny neklíčové atributy jsou závislé na všech klíčových

    (na celém PK) – 3NF – neklíčové atributy jsou závislé na klíčových přímo a ne

    tranzitivně přes jiný neklíčový – BCNF (Boyce-Codd) – odstraňuje závislost mezi klíčovými at. – 4NF – odstraňuje škodlivé multizávislosti

    Příklad - zkoušková evidence

    • ZKOUSKY(CIS_STUD, JMENO, CIS_PREDM, NAZEV, VYSLEDKY_ZK),

    • kde

    • VYSLEDKY_ZK (RT_DAT, RT_ZNAM, 1OP_DAT, 1OP_ZNAM, 2OP_DAT, 2OP_ZNAM)

    • Klíč?

    • 1NF?

  • 18.4.2019

    13

    Příklad - zkoušková evidence

    • ZKOUSKY(CIS_STUD, JMENO, CIS_PREDM, NAZEV, TERMIN, DATUM, ZNAMKA)

    • Klíč?

    • ZKOUSKY(CIS_STUD, JMENO, CIS_PREDM, NAZEV, TERMIN, DATUM, ZNAMKA)

    • 1NF?

    • 2NF?

    • ZKOUSKY(CIS_STUD, CIS_PREDM, TERMIN, DATUM, ZNAMKA)

    • STUDENT(CIS_STUD, JMENO)

    • PREDMET(CIS_PREDM, NAZEV)

    • 3NF?

    Porušení 3NF

    • ŠKOLENÍ(REFERÁT, LEKTOR, TELEFON) • Řešení: • ŠKOLENÍ(REFERÁT, LEKTOR) • LEKTOR(LEKTOR, TELEFON)

    • FILM(FILM, HLAVNÍHEREC, NÁRODNOST, ROK) • Řešení: • FILM(FILM, HLAVNÍHEREC, ROK) • HEREC(HEREC, NÁRODNOST)

    Porušení BCNF

    • ADRESAR(MĚSTO, ULICE, PSČ)

    • (MĚSTO, ULICE)->PSČ a PSČ -> MĚSTO

    • nevýhoda i v tom, že pro zápis PSČ u města musíme znát alespoň 1 ulici

    • Řešení:

    • SEZNAM_ULIC(ULICE, PSČ)

    • MESTO(PSČ, MĚSTO)

    Porušení 4.NF • Škodlivé multizávislosti • AUTO(MODEL, POČET_VÁLCŮ, ZEMĚ_PŮVODU) • Pokud platí, že v každé zemi se vyrábí modely se všemi variantami

    počtu válců, musí se to opakovat v každé zemi (pokud by ale existoval v některé zemi jen omezený počet typů dle počtu válců, nelze dekompozici provést kvůli ztrátě informace)

    • Řešení • AUTO(MODEL, POČET_VÁLCŮ) • ODKUD(MODEL, ZEMĚ_PŮVODU)

    • ATELIÉR(ATELIÉR, REŽISÉR, UMÍSTĚNÍ) • Řešení • ATELIÉR(ATELIÉR, UMÍSTĚNÍ) • ATELIÉRREŽISÉR(ATELIÉR, REŽISÉR) • (dekompozici nelze provést, pokud by některý režisér odmítal

    pracovat v některém místě)

    Procedurální a neprocedurální jazyky

    • Vytváření databázových aplikací (umožňuje prohlížení, editaci, dotazování dat atd.)

    • Procedurální – popis ve formě procedur

    • Nalezení informace (cyklus, testuj podmínku, vyber a udělej operaci,.. tisk atd.)

    • Aplikační programové rozhraní API

    • PAL (Paradox), PL/SQL (Oracle), Transact-SQL MS SQL

    • Dbf nepotřebuje

    • Neprocedurální – SQL, QBE

    • Co a ne jak

    Jazyk SQL • Structured Query Language • Ale není jen dotazovací (+ def. struktury, vkládání dat, vztahy) • Ale není to (plnohodnotný) jazyk (- řídící konstrukce, GUI) • 1974, SEQUEL, IBM • Standardizace – SQL89, SQL92, SQL99 • Použití:

    – interaktivní, – hostovaný (embedded), – komunikační (mezi zdroji dat)

    • Části: – JDD (DDF) – JMD (DML) – JKD (DCL) – i řízení transakcí

  • 18.4.2019

    14

    Jazyk SQL • Příkaz, začíná klíčovým slovem • Konstanty – oddělovače:

    – ‘Text’ – #Datum# – Systémové datum (např. SYSDATE), uživatel (USER) – NULL

    • Zásady pojmenování – Uživatelské objekty se nesmí pojmenovat vyhrazenými slovy – Tabulky – podst.jm., množné číslo – Sloupce - podst.jm., jednotné číslo – Vyhrazená slova v SQL kapitálkami, jména tabulek 1.písmeno

    velké, jména atributů malými písmeny – Nepoužívat diakritické znaky

    Datové typy SQL • Čísla - přesné:

    – SMALLINT 2B rozsah -32768 až 32767 (6 číslic, vč. znaménka)

    – INTEGER 4B rozsah -2,147,483,648 až 2,147,483,647 (11 číslic, vč. znaménka)

    – DECIMAL(X,Y) x ..počet číslic celkem, y … počet desetinných míst (výchozí 30/6)

    – NUMERIC(X,Y) implementačně definovaná přesnost

    • Čísla – aproximativní (zápis pomocí mantisy a exponentu): – FLOAT(X) 8B pohybl.řádová čárka. Rozsah 10E-308 až 10E+308

    – REAL 4B reálné číslo s pevně danou přesností, ale menší než DOUBLE. 10E-38

    – DOUBLE 8B

    • Znakové řetězce: – CHAR(n)

    – VARCHAR(n)

    – LONG VARCHAR

    • Datum a čas: – DATE 4B

    – TIME 4B

    – TIMESTAMP 8B vteřina na 6 desetinných míst

    • Binární: – BINARY(n) nB, max. 32767B

    – LONG BINARY

    Příkaz SELECT • SELECT FROM zdroj WHERE

    GROUP BY HAVING ORDER BY ASC/DESC;

    • SELECT DISTINCT jmeno, telefon FROM student WHERE vek>20 ORDER BY jmeno;

    • SELECT Student.cislo, Student.jmeno, Count(*) AS zkousek FROM Student NATURAL JOIN Vysledky WHERE znamka

  • 18.4.2019

    15

    Příkaz ALTER, RENAME, DROP

    • ALTER TABLE student ADD telefon VARCHAR(80);

    • RENAME TABLE studentnew TO student2008;

    • DROP TABLE student2008;

    Příkazy GRANT, REVOKE, transakční • Systémová a objektová práva

    • GRANT INSERT ON student TO dvo27;

    • GRANT CREATE TABLE TO dvo27;

    • REVOKE DELETE ON student FROM dvo27;

    • Řazení do rolí

    • GRANT editor TO dvo27;

    • Transakce

    • SET TRANSACTION

    • COMMIT

    • ROLLBACK

    Vytvoření indexu

    • Viz indexové soubory

    • CREATE (UNIQUE) INDEX nazev ON Tabulka (atribut1, atribut2..)

    • CREATE INDEX StudentObor ON Student (obor);

    • DROP INDEX StudentObor;

    Jazyk QBE • Viz dotazování v MS Access (návrhové zobrazení)

    • IBM, pohodlné dotazování pro naivní uživatele

    • Dotaz se zapisuje formou příkladů do schématu tabulky/lek, do jednotlivých sloupců

    • P print (výstup)

    • AO ascending order, DO descending order

    Objektově orientovaný datový model

    • Objektové konstruktory – práce s objekty, typy a třídy, zapouzdření, polymorfismus, dědění

    • Typy – vztaženy ke konceptuálnímu modelu

    • Třídy – implementace typu

    • Není třeba normální formy – složitější struktury

    • ORSŘBD – SŘBD, OO

    Objektově orientovaný datový model

    • Objekt – 4 vlastnosti:

    – Identifikátor – OID, unikátní neměnný, není třeba FK

    – Jméno – nepovinný, odkazování na objekt

    – Perzistence – objekt persistentní nebo tranzientní

    – Struktura – atomický, složitý (set, list, array, bag)

  • 18.4.2019

    16

    Objektově orientovaný datový model

    • Zapouzdření – rozhraní. Metody – viditelná část objektu. Volání funkcí pomocí zpráv (posílání zpráv). Uzavření, oddělení implementace od uživatele.

    • Polymorfismus – např. 1 metoda třídění pro různé objekty (např. 2 různé atributy), pohyb

    • Dědění – vlastnosti i metody. Někdy omezení na jen 1 nadtřídu (vzniká orientovaný strom), nebo vícenásobné dědění (více nadtříd). Problémy s konflikty jmen.

    • Zatříditelnost – typy (obecné, koncepční) a třídy (implementace, nové objekty, instance)

    • Literál – hodnota, která nemá OID. • Literály – 3 typy: atomické (z.datové typy), kolekce a strukturované

    Objektově orientovaný datový model • Object Definition Language: • Např. definice třídy:

    – interface [: ] () [: ]{} • extent (seznam všech) • key nebo keys , ..., • Persistent nebo transient • Veřejné položky: deklarace typu, Definice konstanty, Definice výjimky, Deklarace atributu,

    Deklarace vztahu, Rozhraní operace

    • ADT • Object Query Language – problémy, nepřístupnost dat a komplikovaná

    struktura, proto omezen jen na vyhledávání dat • select [distinct] from [ where

    ] • select couple(student: Students.name, professor: teachers.name) from

    Students, Students.courses as courses courses.taught_by as teachers where teachers.rank = „full professor“

    • Dotaz vrací multimnožinu s prvky typu struct(name: string, professor: string) • http://tech.novosoft-us.com/products/oql_book.htm#p4.9.8

    Administrátor DB

    • Definování konceptuálního schématu

    • Definování interního schématu

    • Styk s uživatelem (externí schémata)

    • Definování bezpečnostních a integritních opatření, řízení práce

    • Záložní kopie, obnova db po havárii

    • Sledování provozu db, úzká místa, ..

    • Rozvoj db, aktualizace

    Metadata. Datový slovník • metainformační systém METIS (podniková encyklopedie)

    • vzniká již v etapě plánování (analýzy) a je pak dotvářen a průběžně udržován v aktuálním stavu po celou dobu výstavby a provozu IS. Obsahuje nejen pouhý přehled prvků IS, ale i celou řadu ostatních informací o podniku.

    • Základními prvky každého METIS by měly být: – SOUBOR

    – ÚDAJ

    – ČÍSELNÍK

    – DOKLAD

    – ZPRÁVA

    – ÚLOHA

    – UŽIVATEL

    – PROGRAM

    – ORGANIZAČNÍ STRUKTURA

    – TECHNICKÉ PROSTŘEDKY

    – PRACOVNÍ NÁVODY

    • SOUBOR: – identifikátor, tj. jméno souboru – struktura souboru (soupis datových položek – údajů) – délka věty a počet vět, tj. velikost souboru – nositel, případně způsob organizace souboru – soupis programů pracujících se souborem a typ operace – garant souboru odpovědný za obsahovou správnost

    • ÚDAJ: – identifikátor, tj. jméno údaje – sémantika, tj. popis obsahu údaje – formát (typ a rozsah) – doména možných hodnot (číselník) – užití ve zprávách, dokladech a souborech atd.

    • PROGRAM:

    – jméno, identifikátor

    – charakteristika účelu a popis funkce programu

    – příslušnost k úloze

    – návaznost na jiné programy

    – použitý programovací jazyk

    – programátor

    – verze a datum vzniku

    – způsob spuštění a obsluhy programu

    – vstupní soubory a doklady

    – výstupní soubory a zprávy atd.

    • UŽIVATEL:

    – identifikátor funkčního místa

    – postavení uživatele v organizační struktuře

    – oprávnění k přístupu do souborů

    – používané úlohy a programy

    – dislokace

    – telefonní linka atd.

    • DOKLAD/ZPRÁVA:

    – identifikace dokladu/zprávy

    – charakteristika dokladu/zprávy

    – nositel dokladu/zprávy (papír, obrazovka, disketa)

    – uživatel dokladu/zprávy

    – účel dokladu/zprávy

    – obsah dokladu/zprávy (soupis údajů)

    – případné uspořádání (setřídění) zprávy apod.

    – periodicita

    – počet vyhotovení atd.

    http://tech.novosoft-us.com/products/oql_book.htmp4.9.8http://tech.novosoft-us.com/products/oql_book.htmp4.9.8http://tech.novosoft-us.com/products/oql_book.htmp4.9.8http://tech.novosoft-us.com/products/oql_book.htmp4.9.8http://tech.novosoft-us.com/products/oql_book.htmp4.9.8

  • 18.4.2019

    17

    Architektura DBS - centralizované platformy

    • Na 1 místě SŘBD, data, db aplikace, komunikační SW • Přístup k db z terminálů: • Neinteligentní – žádné lokální zpracování, pouze obrazovka,

    klávesnice, HW pro komunikaci • Přihlášení uživatele, vše na centrální místě, přenos příkazů,

    instrukce pro zobrazení výsledků • Komunikace aplikace a SŘBD přes sdílenou paměť nebo

    paměťové oblasti aplikace • Vnější paměti – disky, zálohování • Centrální zabezpečení, obrovské objemy dat, mnoho

    současně pracujících uživatelů (tisíce i více) • Nákladnost, specializovaná zařízení • inteligentní (PC) – část zpracování na lokále, např. některé

    výpočty, zobrazování

    Architektura DBS - systémy na osobních počítačích

    • Miniverze centrálního • SŘBD a aplikace spojeny do 1 programu • Omezená kapacita, výkon, • Pro 1 uživatele, neřeší sdílení, bezpečnost, porušuje některá

    pravidla atd. • Flexibilní, přístup z různých aplikací, sdílení dat • Pozor na nečitelnost data při přístupech z různých aplikací • Rychlost • Server souborů – posílání všech podkladových dat na lokál,

    kde se zpracovávají • Velká síťová komunikace • Víceuživatelský systém, jisté zamykání

    Architektura DBS - DBS klient/server

    • Rozdělené zpracování

    • SŘBD – serverová (back-end) a klientská část (front-end)

    • Poslání požadavku na server, kde se zpracuje a výsledek se posílá zpět

    • Specializovaný (dedikovaný) stroj jako db server

    • Většina současných SŘBD

    • Procesy – listener, dispečer, fronty požadavků, fronty odpovědí

    Klient-server

    Architektury DBS Klient-server: back-end, front-end, net Databázový server: • Správa db pro více uživatelů • Kontrola přístupu k db, další činnosti pro zabezpečení db • Ochrana db informací pomocí zálohování a obnovy dat • Centrální kontrola integrity dat pro klientské aplikace Klientská aplikace: • poskytování uživatelského rozhraní • zobrazení dat ve formě formulářů, sestav, grafů apod. • obsahuje nástroje potřebné např. pro výpočet hodnot v polích formulářů • verifikace zadávaných dat • zasílání žádostí o informace a přijímání informací od serveru

    Architektura DBS - distribuované DBS • Logicky 1 databáze fyzicky rozmístěna na více místech, spojených komunikační

    sítí

    • Dokonce rozdílné lokální SŘBD + globální SŘBD

    • Výstavba – zespodu nahoru, shora dolů

    • Problémy heterogenity – nutnost homogenizace, sjednocení rozdílných schémat

    • Sémantické rozdíly: – Nekonzistentní schémata

    – Rozpory na úrovni atributů (synonyma, homonyma, jiné domény, jednotky)

    – Odlišné hodnoty odpovídajících atributů

    • Výhody: – Lokální transparence

    – Zvýšená spolehlivost

    – Vyšší odpovědnost za data

    – Modulární růst systému

    – Menší náklady na komunikace

    – Rychlejší odezva

    – Dražší a složitější SW

    – Vyšší provozní náklady

    – Obtížnější kontrola datové integrity

    – Nebezpečí pomalé odezvy

    Architektura DBS - distribuované DBS • Dotaz:

    – Odchytí GSŘBD, zjistí zda jsou data na lokále, pokud ano předá požadavek LSŘBD, pokud ne, zjistí, kde jsou data, převede do vhodné syntaxe, nechá zpracovat, přeloží výsledek do cílového SŘBD.

    • Problémy referenční integrity a vazeb mezi různými SŘBD

    • Formy replikace: – Vertikální

    – Horizontální

    – Totální

  • 18.4.2019

    18

    Interní formy uložení dat

    • Sekvenční soubory

    • setříděné sekvenční soubory

    • zřetězené organizace - lineární seznam, kruhový zásobník, stromy, Bayerovy stromy

    • Přímé adresování

    • Indexové soubory

    Interní formy uložení dat

    • Datový typ ukazatel – označení: p, p↑

    • 2B nebo 4B

    • p … adresa

    • p↑ … práce s daty uloženými na adrese p

    Sekvenční a setříděné sekvenční soubory

    • Věty v souboru, stejná délka, sekvenční zápis

    • Lze spočítat místo uložení

    • Operace: – Nový záznam – na konci vložit

    – Vyhledání – procházej vždy adresy části záznamu, kde je uložen prohledávaný atribut

    – Smazání – pouze označení neplatnosti

    – Modifikace – vyhledat a přepsat

    • Setříděné – podle 1 atributu

    Zřetězené organizace

    • Prvek – klíč, data, „další“

    • kořen

    • Lineární seznam, varianty:

    – Zásobník (LIFO = last in, first out)

    – Fronta (FIFO = first in, first out)

    – Setříděný seznam – podle vybraného atributu

    – Kruhový zásobník – pevný počet prvků

    • stromy

    Zřetězené organizace - vkládání prvků

    • New(wn)

    • wn↑.klíč = hodnota klíče nového prvku

    • wn↑.data = data nového prvku

    pro zásobník:

    • wn↑.další = kořen

    pro frontu:

    • wn↑.další = NULL

    • iterace hledání konce řetězce

    Optimalizace – přidá se ukazatel „konec“

    Zřetězené organizace – jiné operace

    • Aktualizace

    • Smazání – pouze se označí jako neplatný

    • vyhledej

  • 18.4.2019

    19

    Kruhový zásobník

    • Pevný počet prvků

    • Kořen odkazuje na poslední (nejnovější) prvek

    • Vložení nového prvku

    • Aktualizace

    • Mazání

    • vyhledání

    Stromy • Prvek • Podstrom • Stupeň stromu – max. počet podstromů v nějakém prvku (max.

    větvení) • nejvíce binární stromy – místo „další“ jsou ukazatele „levý“ a „pravý“ • Kořen, listy • Prvky na stejné úrovni mají stejný počet předchůdců • Hloubka stromu – max. úroveň • Délka cesty • Varianty:

    – Binární stromy – Vyvážené stromy – dokonale vyvážené, pokud počet prvků v levém a

    pravém podstromu se liší max. o 1, stačí ale většinou že se výšky 2 podstromů se liší max. o 1

    – Optimální stromy

    Binární stromy • Místo „další“ 2 ukazatele:

    – „vlevo“ ukazuje na prvky s hodnotou klíče < aktuální klíč

    – „vpravo“ ukazuje na prvky s hodnotou klíče > aktuální klíč

    • Vložení nového prvku

    • Aktualizace

    • Smazání

    • Vyhledej

    Vyvážené stromy • dokonale vyvážené, pokud počet prvků v levém

    a pravém podstromu se liší max. o 1,

    • stačí ale většinou že se výšky 2 podstromů se liší max. o 1

    • Rotace prvků

    • Vložení nového prvku

    • Aktualizace

    • Smazání

    • Vyhledej

    Optimální stromy • Pravděpodobnost hledání prvku

    • vyšší pravděpodobnost – blíže ke kořeni (délka cesty co nejkratší)

    • Celková optimalizace – suma vážených cest co nejmenší

    Bayerovy stromy • Není binární • Stránky • Každá stránka obsahuje n až 2n prvků = m prvků • n je řád stromu • Pravidla:

    – Každá stránka obsahuje max. 2n prvků – Každá stránka kromě kořenové obsahuje nejméně n prvků (zaplněnost

    nejméně z poloviny) – Každá stránka je koncová nebo obsahuje m+1 následovníků = vyvážený

    strom

    • Datová struktura stránky bez dat (p0, k1, p1, k2, p2,… km, pm) • Vyhledávání:

    – klíč < k1 -> jdi na stránku odkazovanou p0 – ki < klíč < ki+1 -> jdi na stránku odkazovanou pi – km < klíč -> jdi na stránku odkazovanou pm

  • 18.4.2019

    20

    Bayerovy stromy

    • Jak rostou: – Stránka není plná (m

  • 18.4.2019

    21

    Řešení transakcí • Metoda zpožděné aktualizace – zpracování dat během transakce se

    nezapisuje přímo do db, ale do logu (pomocný soubor). Pokud dojde k chybě, začne se znovu. Pokud bylo vše dokončeno OK, kopíruje se obsah logu do db (pokud dojde k chybě při kopírování, opakuje se)

    • Operace typu redo • Metoda přímé aktualizace - zpracování dat během transakce se zapisuje

    přímo do db, ale o všech operacích, kdy dojde ke změně původních hodnot, se vede podrobný zápis do logu (pomocný soubor). Při chybě se musí pomocí hodnot v logu spočítat zpátky původní hodnoty dat před transakcí

    • Operace typu undo • Check point • Metoda stínového stránkování – pro popis uložení dat v db se používají 2

    pomocné tabulky = tabulky stránek. Obsahují adresy bloků db na disku. Před transakcí jsou obě tabulky stejné (aktuální, platný stav). Při transakci se nové údaje zapisují na jiné místo v paměti a to se dokumentuje v tabulce stránek. Stínová tabulka stránek přitom zůstává původní (odkazy na nezměněná data). Pokud chyba – použije se stínová tabulka stránek

    • Problém garbage collection

    docs.oracle.com

    Ochrana transakcí Oracle • transakční žurnál (transaction log) TŽ

    • Všechny změny v db jsou zaznamenány do TŽ. I operace COMMIT.

    • TŽ se používá při obnově db. Po restartu db automaticky Oracle provede obnovu dat, rekonstrukci změn provádí podle zápisu v TŽ.

    • TŽ se skládá ze 2 nebo více skupin záznamových souborů pevné délky (Oracle7) (fyzický název redo-log soubory). Poté, co údaje o transakcích zaplní 1 skupinu, použije se další volná skupina.

    • Současně se zápisem provádí Oracle automaticky zálohování zaplněných skupin. Při přechodu mezi skupinami se rovněž zvyšuje přírůstkové pořadové číslo žurnálu. Po dokončení zálohování zaplněné skupiny je tato skupina určena k použití pro další záznam probíhajících transakcí.

    • Cyklické střídání záznamových skupin tak umožňuje nepřetržitý záznam transakcí při použití velmi malého diskového prostoru. Archivací zaplněných skupin se získává permanentní žurnál celé databáze.

    • Na zvýšení ochrany se navíc provádí zrcadlení skupin TŽ na různých discích.

    Princip rotace a archivování souborů transakčního žurnálu

    docs.oracle.com

    Ochrana dat • asynchronní aktualizace dat: zálohování je provedeno se zpožděním,

    např. posunuto o 15 minut za produkční db, a proto je šance do 15 minut zabránit přijetí chyby, možnost požádat o její opravu ze zálohy.

    • zálohování ostatních objektů mimo transakční žurnál si musí uživatel (správce) řídit sám

    • uživatel si musí zajistit zálohování řídícího souboru databáze. Správce by tento soubor měl extra zálohovat zejména po každé změně struktury db.

    • rozlišuje se kompletní zálohování a rozdílové zálohování.

    • Obnova db se provádí z poslední zálohy a pak se spustí proces zotavení. Ten zahrnuje fázi dopřednou (roll-forward) (aplikují se všechny operace zaznamenané v transakčním žurnálu), pak fázi zpětnou (rollback), ve které se zruší operace, které nebyly potvrzeny pomocí COMMIT.

    Řízení paralelních procesů v databázích

    • Víceuživatelský režim vyžaduje sériovost transakcí • Nemohou si transakce vzájemně přepisovat data • Musí se řešit vhodné zamykání • Co se zamyká:

    – Soubor – Pracovní soubor v SŘBD – Několik záznamů – 1 záznam – Jen některé položky v záznamu

    • Jak se zamyká: – Sdílené zámky (shared) – vícenásobné čtení povoleno LS(A) – Výlučné zámky (exclusive) LX(A) – Odemčeno (unlocked) UN(A)

  • 18.4.2019

    22

    Různé úrovně zámků Oracle

    Řízení paralelních procesů v databázích

    • Uváznutí – Prevence – Řešení – pomocí grafů, využití logů

    • Prevence: • předem zamknout vše potřebné • Plánovače – serializace do fronty • Časová razítka ČR • Pro každý objekt A se eviduje R/ČR(A) a W/ČR(A) • Čtení:

    – ČR< W/ČR(A) -> zamítne – Jinak provede a aktualizuje hodnotu R/ČR(A) novou hodnotou ČR,

    pokud je větší než stávající R/ČR(A)

    • Zápis: – ČR< W/ČR(A) OR ČR< R/ČR(A) -> zamítne – Jinak provede a aktualizuje hodnotu W/ČR(A) novou hodnotou ČR

    Datový sklad

    • značně frekventovaný pojem

    • někdy intuitivně pro označení rozsáhlého úložiště dat

    • varianty chápání datového skladu: – 1. datový sklad ve smyslu organizovaného, jednotného a integrovaného

    úložiště dat

    – 2. datový sklad typu warehouse, „analytický“ datový sklad, integrace dat z transakčních databází, jejich agregace a uložení v multidimenzionálních strukturách, optimalizace z hlediska dotazování a analýzy dat. Navazuje aplikace OLAP

    – 3. datový sklad používaný pro ukládání originálních dat v primární podobě ve formě multidimenzionální struktury především s cílem vytvoření centrálního úložiště s přesným popisem originálních dat. Jde tedy o transakční systém s multidimenzionální strukturou (jistá forma OLTP)

    Datový sklad

    • Pojem dimenzionalita, resp. multidimenzionální struktury není chápán jako prostorový

    • jako dimenze se nepoužívají prostorové souřadnicové osy, ale popis faktorů, které data ovlivňují a zajímají nás z hlediska analýzy

    • Datový sklad (data warehouse) představuje architekturu, která se používá pro údržbu historických dat získaných z databází operativních dat, která byla transformována, sjednocena a zkontrolována před jejich použitím v databázi datového skladu

    • nepoužívá přímo data získaná při běžných transakcích, provádí se jejich selekce, homogenizace a agregace podle vhodných kritérií

    • Cíl - uložit konsolidovaná a integrovaná data pro zefektivnění následující analytické a statistické práce s daty

    • historická data, v některých případech i externí

    Datový sklad • Odvozené informace slouží pro podporu rozhodování s využitím specifických

    technik dolování dat (typický nástroj datových skladů) nebo v navazujících systémech typu OLAP

    • OLAP (On Line Analytical Processing) - technologie pro zpracování dat z databáze na serveru (datovém skladu) s využitím velkého množství kladených dotazů, sledování trendů, porovnání vývoje atd., a s vhodným grafickým rozhraním pro koncové uživatele

    • Pravidla pro OLAP

    • Typické OLAP operace: – Drill-down

    – Roll-up

    – Slice-and-dice

    – Pivot

    Multidimenzionální struktura

    • Dimenze • reprezentují jednotlivé aspekty, podle kterých jsou

    organizována fakta a podle kterých došlo k agregaci dat. • Na jejich základě se provádí analýza agregovaných dat. • Dimenze mají zpravidla hierarchickou strukturu. • Jednotlivé prvky hierarchie se pak používají k seskupování

    dat (faktů). • V klasických ekonomických aplikacích je vždy přítomna

    ekonomická dimenze a čas, další dimenze se již navrhují s ohledem na preference uživatelů. Může to být dimenze výrobků, zaměstnanců, zákazníků, ale také geografická dimenze

  • 18.4.2019

    23

    Fakta

    • představují agregované hodnoty, které jsou zajímavé pro rozhodování.

    • obvykle jsou numerická a měřitelná.

    • získávají se opakovaně

    • Granularita - určuje úroveň podrobnosti faktů. Závisí na úrovni podrobnosti dimenzí. Vysoká granularita znamená uložení dat v nízkém stupni agregace (např. údaje za sčítací obvody), tedy s velkým detailem dat.

    • Aditivita faktů = vlastnost určující, zda je možné fakta sumarizovat podle dimenzí (aditivní – podle všech d., semiaditivní, neaditivní atributy)

    OLAP pivoting