Database engine (databázový stroj, databázový motor, databázové jádro) Systém řízení báze dat SŘBD. Typy SŘBD podle způsobu práce s daty

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

programový systém umožňující vytvoření, údržbu a použití báze dat databáze

Database engine

(databázový stroj, databázový motor, databázové jádro)

funkce: „ přenos (načítání) dat z místa jejich uložení do místa jejich zpracování

program data

ƒ database engine ƒ jazyky pro definici, manipulaci a řízení dat

Místo uložení dat (např. pevný disk)

Operační paměť

ƒ datový slovník (metadata)

Databázová aplikace databázový systém

data

SŘBD

Typy SŘBD podle způsobu práce s daty „ souborové

aplikační program

„ klient/server

1

SŘBD klient/server

souborové SŘBD „

„

program (aplikace) manipuluje přímo se soubory dat při víceuživatelském přístupu není možnost koordinace program 1

data

program 2

Hierarchie datových struktur databáze

záznam, věta (record) pole, položka (field)

program 1 program 2

program 3

soubor

oddělení SŘBD a databázové aplikace: program (aplikace) komunikuje s procesem (serverem), který obhospodařuje databázi a manipuluje s daty úloha serveru: „ manipulace s daty (podle požadavků klientských programů) „ koordinace víceuživatelského přístupu

datové struktury datové typy

server

data

program 3

Kritéria pro srovnávání efektivnosti datových struktur „ Jak odpovídají reálným objektům, jež znázorňují (možnost vyjádřit vztahy 1:1, 1:N, N:1, N:M) „ Obtížnost návrhu „ Obtížnost dodatečných změn v uspořádání dat „ Efektivnost vyhledávání dat „ rychlost přístupu k datům „ vícekriteriální vyhledávání

„ Míra redundance

2

Lineární (sekvenční) struktura

Užití lineárních struktur „zálohy dat (sekvenční ukládání na magnetickou pásku) „fulltextové systémy (doplněné indexovými soubory)

Lineární (sekvenční) struktura

Lineární struktura − klady a zápory „ možnost vyjádřit pouze vztahy 1:1 „ jednoduchý návrh „ obtížnost dodatečných změn v uspořádání dat „ rychlost přístupu k datům: malá – sekvenční prohledávání „ vícekriteriální vyhledávání – nelze „ redundance – nutná při vyjádření vztahů 1:N a N:M

3

Stromová (hierarchická) struktura

Užití stromových struktur „indexové soubory „HTML a XML dokumenty „objektově orientovaná technologie

Stromová (hierarchická) struktura

Stromová struktura − klady a zápory „ možnost vyjádřit jednosměrné vztahy 1:N „ obtížný návrh „ obtížnost dodatečných změn v uspořádání dat „ rychlost přístupu k datům: vysoká – přímý přístup (navigace) „ vícekriteriální vyhledávání – nelze „ redundance – nutná při vyjádření vztahů N:M

4

Síťová struktura

Užití síťových struktur „hypertext „World Wide Web

Síťová struktura

Síťová struktura − klady a zápory „ možnost vyjádřit vztahy N:M „ obtížný návrh „ obtížnost dodatečných změn v uspořádání dat „ rychlost přístupu k datům: vysoká – přímý přístup (navigace) „ vícekriteriální vyhledávání – nelze „ redundance – žádná

5

Nevýhoda lineárních, stromových a síťových datových struktur

Relační struktura

„procedurálnost aby systém provedl požadovanou operaci s daty, je třeba mu přesně určit procedury, kterými to má realizovat „trvalost vztahů vztahy mezi záznamy nelze v průběhu aktualizace systému ani v průběhu vyhledávání měnit

Edgar F. Codd:

Kartézský součin

Relační SŘBD je takový systém, který má 2 vlastnosti:

„ spojení prvků různých množin stylem "každý s každým"

1. databáze je uživatelem chápána jako množina relací (a nic jiného)

„ výsledek: upořádané n-tice (relace)

2. jsou k dispozici minimálně operace selekce, projekce a spojení, aniž by se vyžadovaly explicitně předdefinované přístupové cesty pro realizaci těchto operací

„ na pořadí prvků v n-ticích nezáleží „ doména: množina hodnot stejného významového typu (např. jména čtenářů), použitá v kartézském součinu

6

Kartézský součin

Vznik relace kartézským součinem nad doménami – 1

M x N = {[A,X],[A ,W],[B,X],[B,W],[C,X],[C,W]}

Vznik relace kartézským součinem nad doménami – 2

Relační databáze = množina relací (relačních tabulek)

7

Relační struktura

Srovnání databázových struktur

„možnost vyjádřit vztahy N:M „jednoduchý návrh „snadné dodatečné změny v uspořádání dat „rychlost přístupu k datům: malá „vícekriteriální vyhledávání – lze „redundance – minimální

Cíl návrhu informačního systému – převést realitu do počítače

Fyzický svět reálné objekty ("skutečné" i abstraktní)

Počítačový svět reprezentace reálných objektů v podobě softwarových a datových objektů

8

ERA model Peter Pin–Shan Chen 1976 „typ konceptuálního modelu – množina pojmů sloužící k statickému (datovému) popisu systému

Cíl návrhu (modelu) databáze „mít v systému všechna potřebná data „nemít v systému žádná nepotřebná data „vyjádřit vztahy mezi daty „popsat transformaci dat v systému

ERA model „ entita jakýkoli objekt, prvek, který nás zajímá „ atribut charakteristika (vlastnost) entity vymezuje hodnoty, kterých mohou nabývat její instance „ vztah sémantické spojení mezi dvěma nebo více prvky modelu

Entitně–relační diagram (ERA, E–R, ER, ERD) 1. ENTITA (entity) 2. ATRIBUT (attribute) 3. VZTAH (relationship)

9

Kardinalita (mohutnost) „ počet prvků množiny „ určení počtu prvků nějakého vztahu – kolik výskytů jedné entity má vztah k výskytu druhé entity?

Kardinalita vztahu

Kardinalita vztahu 1:1 role herců v nastudované divadelní hře 1:N role herců v divadelní sezóně N:M role herců v několika sezónách a divadlech spolupráce herců např. v jedné divadelní hře HEREC

ROLE

10

Způsoby vyjádření kardinality

Vladimír Koutecký z Prahy 4 si 14. října 2004 půjčil na tři týdny "Tajný deník Laury Palmerové" (signatura A1586)

Vladimír Koutecký z Prahy 4 si 14. října 2004 půjčil na tři týdny "Tajný deník Laury Palmerové" (signatura A1586)

a) grafické vyjádření

b) lineární textový zápis E: ČTENÁŘ (Jméno, Adresa) KNIHA (Signatura, Název) R: VÝPŮJČKA (Datum, Lhůta)

11

ERA diagram pro pojišťovnu Pojišťovna nabízí klientům různé produkty (např. životní pojištění, pojištění domácnosti, povinné ručení, cestovní pojištění, úrazové pojištění…) Rozhodne-li se klient pro určitý produkt, uzavře s pojišťovnou pojistnou smlouvu. K uzavřeným pojistným smlouvám pak pojišťovna přiřazuje evidenci plateb sjednaných pojistných částek a dále evidenci pojistných událostí a jejich vyřízení.

Entita 1. Popsatelný objekt (odlišitelný od okolí) atributy 2. Jednoznačně identifikovatelný objekt identifikátory

Primární klíč (primary key)

∗

Pole nebo kombinace polí, jejichž hodnoty jednoznačně identifikují každý z řádků tabulky „ je jednoznačný – nesmí mít 2x stejný obsah „ je minimální – žádné pole z něj nelze vypustit „ musí vždy obsahovat hodnotu

12

Primární klíč pro seznam umělců „

„ „ „ „ „ „ „ „ „

Vstupenky do divadla

Alternativní verze jména (např. v různých jazycích) Datum narození Muž / žena Národnost Pořadové číslo v seznamu Rodné jméno Rodné příjmení Umělecké jméno Umělecký obor Životopis

Primární klíč pro vstupenky do divadla

Primární klíč v Paradoxu „

„ „ „ „ „ „

Cena Název představení Řada Sedadlo Termín (datum a čas) Umístění (přízemí – balkón – galerie)

„

„ „

ve struktuře tabulky musí být klíčová pole na prvním místě tabulka se automaticky setřídí podle klíčových hodnot vytvoří se indexový soubor s příponou .px v případě dodatečného definování primárního klíče budou záznamy s duplicitními hodnotami v klíčovém poli přemístěny do dočasné tabulky KEYVIOL

13

Odkazy v síťových databázích – pointery (fyzické vazby)

Cizí klíč (foreign key) odkaz na primární klíč rodičovského záznamu prostřednictvím zopakování jeho hodnoty v dětském záznamu herec B hraje roli A (role odkazuje na herce) herec C hraje roli D (herec odkazuje na roli) HERCI pk

ROLE B

fk

C

fk pk

A

Odkazy v relačních databázích – cizí klíče (logické vazby)

Referenční integrita „ všechny odkazy z jednoho záznamu do druhého jsou kontrolovány na správnost „ správné je, když: hodnota či existence atributu v jednom záznamu (odkazujícím, dětském) závisí na hodnotě či existenci téhož atributu v jiném záznamu (odkazovaném, rodičovském)

D

14

Podstata omezení daného referenční integritou „zabránění vzniku osiřelých záznamů

Terminologie referenční integrity v Paradoxu Týká se záznamů nebo tabulek

„sirotek: záznam, ke kterému chybí doplňující informace, jež má být obsažena v druhém (rodičovském) záznamu „týká se vkládání dat, aktualizace i rušení dat

Referenční integrita 1. Pole společné oběma záznamům (propojovací – primární a cizí klíč) musí být stejného datového typu a velikosti 2. Vazbu definujeme pro dětský záznam

parent

child

master

detail

rodič

dítě

Referenční integrita 1. Rodičovská tabulka „ „

„

musí mít primární klíč propojovací pole musí být součástí primárního klíče ve složeném primárním klíči musí být propojovací pole na prvním místě

2. Dětská tabulka „ „

musí mít primární klíč propojovací pole (cizí klíč) může být umístěno kdekoli ve struktuře tabulky

15

Referenční integrita v Paradoxu

Referenční integrita v Paradoxu

Co se stane, když…

Co se stane, když…

1) Definujeme referenční integritu pro dětské záznamy, které mají v cizích klíčích hodnoty neodpovídající primárnímu klíči v rodičovském záznamu?

2) Vložíme do cizího klíče hodnotu neodpovídající primárnímu klíči žádného rodičovského záznamu?

vytvoří se tabulka KEYVIOL

Referenční integrita v Paradoxu

záznam se nepodaří uložit (master record missing)

Referenční integrita v Paradoxu

Co se stane, když…

Co se stane, když…

3) Při editaci cizího klíče stiskneme kombinaci kláves Ctrl–Shift–Mezerník?

4) Definujeme referenční integritu jako Cascade?

Objeví se pohled na rodičovské záznamy s možností výběru a vložení hodnoty

Při změně hodnoty primárního klíče v rodičovském záznamu se automaticky změní hodnoty odpovídajících cizích klíčů

16

Referenční integrita v Paradoxu

Referenční integrita v Paradoxu

Co se stane, když…

Co se stane, když…

5) Definujeme referenční integritu jako Prohibit?

6) Budeme chtít smazat rodičovský záznam?

Má-li rodičovský záznam odpovídající cizí klíče v dětském záznamu, nelze provést změnu jeho hodnoty (master has detail records)

LZE – nejsou-li v dětských záznamech odpovídající cizí klíče NELZE – jsou-li v dětských záznamech odpovídající cizí klíče (master has detail records)

17