Databázové systémy
teorie a návrh relačních databázových systémů
část I
0. Pracovní prostředky
S jakými prostředky budeme pracovat
Verze 10g
Vytvoření jednotlivých DBO schémat
Vytvoření jednotlivých schémat (USER) probíhá pod zvláštním
privilegovaným účtem system
Přihlášení uživatele do vlastního DBO schématu (pú 1)
uzivatelx (x=1-n)
heslo
Vnitřní organizace DBO schématu – TEBLESPACES &
DATAFILES
Vnitřní organizace DBO schématu - USERS
Jakým způsobem přistupujeme do DBO?
• Pro přístup do databáze používáme jednu ze dvou
základních možností Oracle Express – HTTP
klienta
výhodou je přístup odkudkoli pouze z internetového prohlížeče bez
nutnosti instalovat DBO klienta
nevýhodou je omezená použitelnost HTTP klienta zejména vůči
specifickým aplikacím a jejich požadavkům
• Alternativní možností je využití databázového
klienta Oracle
výhodou tohoto přístupu je všestrannější možnost využití databáze a
propojení s libovolným aplikačním klientem
nevýhodou je nutnost instalovat klienta Oracle na konkrétní PC
Podpis databázového schématu (pú 2)
SQL (DSL)> DESCRIBE autor;
SQL (DSL)> SELECT * FROM autor;
SQL (DML)> UPDATE autor;
SET jmeno = ‘jmeno’,
prijmeni = ‘prijmeni’,
e_mail = ‘adresa’;
SQL (DSL)> SELECT * FROM autor (použij „History“)
Základní způsoby práce s DBO
SQL> command line pro zadávání
jednotlivých SQL příkazů
SQL skript> možnost zadávání
sekvencí více SQL příkazů a jejich
hromadného spouštění (nejedná se o
programy)
SQL Query> možnost interaktivního
grafického vytváření SQL příkazů
prakticky bez znalosti SQL jazyka
I. Všeobecný úvod
Základní rozlišení bází dat
• Nestrukturované a částečně strukturované báze dat
souborové báze dat orientované na FS,
firemní elektronická agenda v různých podobách (dokumenty, tabulky, číselná
data)
• Nerelační báze dat a přechodné formy
historické souborové databáze (DBase IV)
tabulkově orientované databáze se zárodky relačního přístupu FoxPro 5, Paradox)
• Relační databázové systémy
Oracle, MSSQL Server, MS Access
• Objektově orientované báze dat
XML (….)
Objektový databázový koncept (ODC)
implementace ODC v současných relačních systémech
využití v komunikacích (Queuing)
II. Relační databázové systémy
Charakteristika relačního DS (RDS)
Hlavní požadavky
efektivita
(HW, SW, Lidské zdroje, rychlé vyhledávání)
spolehlivost
(bezpečnost dat, stabilita, zabezpečení proti zneužití)
implementace relačního modelu
Historie
teorii relačního modelu zpracoval v 60. Letech Dr. E. F. Codd
Axiomy relačního modelu (koncept)
 data jsou reprezentována v řádcích a sloupcích tzv. relacích
 všechny hodnoty obsažené v databázi jsou skalární tj. jednotkové neboli atomické
 operace v databázi se provádí vždy nad celou relací a jejich výsledkem je jiná
relace tzv. uzávěr
Implementace relací
např. MS Access – recordset – množina záznamů
např. MS SQL Server – resultset – množina výsledků
Co je relace dat
Co není relace dat
relace dat z hlediska teorie relačních databází nejsou vzájemné vztahy mezi daty (například
tabulkami) reprezentované vzájemnými vazbami (referenční integrita);
Poznámka: pozor existují také tzv. relace (vztahy) mezi datovými entitami (o těch později)
vázané na vztahovou integritu dat, ale to nesouvisí přímo s relační datovou teorií
Co je relace dat
relace dat na obecné úrovni jsou data uspořádaná do řádků a sloupců (matice) bez ohledu
na jejich konkrétní implementaci, s pevně danými datovými buňkami, kde je možno každou
jednotlivou datovou hodnotu definovat jako n – tou ve sloupci a m – tou v řádku
předpokládá se že jednotlivé hodnoty v datových buňkách mají skalární (atomický) charakter
Co je možno provádět s relacemi dat
s relacemi dat je možno provádět definované množinové operace (součet množin, kartézský
součin, rozdíl množin symetrický a asymetrický apod.)
relace dat je možno skládat, propojovat a vytvářet na jejich základě jiné relace dat
Typické implementace relací dat
tabulka
pohled
výsledková množina (prezentační množina dat)
datový kurzor (množina dat pro aplikační zpracování)
Co je možno provádět s relacemi dat
+
=
-
=
=>
Co je relace dat – příklady (pú 3)
SQL (DSL)> SELECT * FROM student; - plný výpis datové tabulky pomocí divokého znaku
SQL (DSL)> SELECT PRIJMENI, JMENO, ULICE, OBEC, PSC FROM student; - částečný
výpis atributů datové tabulky
SQL (DSL)> SELECT PRIJMENI, JMENO, ULICE, OBEC, PSC FROM student ORDER BY
PRIJMENI, JMENO; - částečný výpis atributů datové tabulky tříděný
SQL (DSL)> SELECT PRIJMENI || ',' || JMENO || ',' || ULICE || ',' || OBEC || ',' || PSC as
ADRESA FROM student ORDER BY PRIJMENI, JMENO;- konverze relace dat do jiné relace
dat – nakolik je obsažená hodnota skalární?
SQL (DSL)> SELECT ROWNUM, ADRESA FROM
(SELECT PRIJMENI || ',' || JMENO || ',' || ULICE || ',' || OBEC || ',' || PSC as ADRESA FROM
student ORDER BY PRIJMENI, JMENO); - relace dat vytvořená z jiné relace dat – ROWNUM –
klíčová funkce relace dat
SQL (DSL)> SELECT * FROM
(SELECT ROWNUM as PORADI, ADRESA FROM
(SELECT PRIJMENI || ',' || JMENO || ',' || ULICE || ',' || OBEC || ',' || PSC as ADRESA FROM
student ORDER BY PRIJMENI, JMENO))
WHERE PORADI IN (1,10,20); - relace 3 řádu – pokus zkuste variantu s aliasovaným ROWNUM
druhého řádu a s ROWNUM bez aliasu – pokuste se o vysvětlení tohoto jevu
Obecný koncept RDS
Aplikace –
Uživatelské rozhraní
Databázový stroj –
není součástí databáze
Vlastní
Databázový systém
Databáze – fyzická
implementace
databázového
schématu
Databázové schéma
– implementovatelný
popis dat. modelu
Myšlenkový
(konceptuální)
prostor problému
Datový model –
myšlenkový popis
daného prostoru
problému
Prostor problému – definovaná část reálného světa
Možnosti implementace RDS
Databázové stroje - běžné
Prostředí pro definici a správu dat
Vývoj Front-end aplikací
Microsoft Accsess
Visual Database Tools
Microsoft Query
SQL server Enterprise Manager
SQL+
Toad
Microsoft Accsess
Visual Basic
C++, C#
HTML
ASP
Java
Obj. komp. pro přístup k datům
ADO
DAO / Jet
DAO / ODBC
RDO
Oracle client
BDE, BD express
Databázové stroje
Microsoft Jet
SQL server
Oracle
Oracle Express s HTTP klientem
Server
Klient
Koncepční implementace datového modelu –
databázové objekty
Relace dat (relační koncept)
Relační databázový koncept sám o sobě je teoretická koncepce, myšlenkový
model.
Koncepce implementace RDS
Koncepce RDS je ve většině běžných DBO systémů konkretizována
implementací tzv. databázových objektů. Databázové objekty jsou nejrůznějšího
typu, přesto se v jednotlivých implementacích (Oracle, MS SQL server, DB2,
MySQL apod.) do značné míry shodují. Zejména základní databázové objekty RDS
systémů jsou velmi obdobné.
Datový katalog / katalog DBO objektů
Aby bylo možno se vůbec v DBO objektech elementárně vyznat, implementují
jednotlivé RDS různou formou tzv. katalogy databázových objektů
Katalog DBO objektů Oracle
Příklady uživatelských pohledů do datového katalogu:
user_catalog - všeobecný přehled o datových objektech
user_objects - detailní přehled o datových objektech
user_tables - všeobecný přehled o tabulkách
user_views - všeobecný přehled o pohledech
atd…
pú 4 – vypište na základě veřejného pohledu do datového
katalogu user_objects všechny typy datových objektů,
které se vyskytují ve vašem DBO schématu
Hlavní DBO objekty (nejen Oracle)
Typické datové objekty RDS systémů:
Základní:
TABLE, VIEW, PROCEDURE, TRIGGER,
FUNCTION
Rozšiřující:
INDEX, CONSTRAINT, SEQUENCE (Oracle)
Jiné:
TEMPORARY TABLE, MATERIALIZED VIEW,
FUNCTIONAL INDEX, TYPE
III. Příklad řešeného problému
Všeobecné zadání RDS - příklad
První neupřesněné zadání
Je třeba vytvořit evidenci výzkumných úkolů studentů a pedagogů naší vysoké školy. Na škole
probíhají výzkumné úkoly různé povahy. Jsou to například vnitřní granty, granty ministerstva
školství (MŠMT), bakalářské práce, diplomové práce, postgraduální výzkumné úkoly. Na
výzkumných úkolech se podílejí jak studenti tak pedagogové. Studenti se podílejí na
výzkumných úkolech jak v rámci prezenční formy studia tak i při kombinovaném a
postgraduálním studiu. V praxi je možné, že se student podílí na výzkumu i po ukončení
studia, ale pak se obvykle jedná se o zvláštní režim výzkumného úkolu. Na úkolech se podílejí
pedagogové všech zařazení (zaměstnanec, externista, práce na dohodu o provedení práce). V
praxi není možné, aby se na výzkumném úkolu podílel pedagog který nemá v průběhu úkolu
vyřešen pracovně právní vztah k fakultě nebo již tento vztah zanikl.
Cílem vytvářené aplikace je získat: operativní přehled o probíhajících projektech, evidenci již
dokončených projektů, možnost kontrolovat projekty z hlediska jejich časového průběhu
(každý typ projektu má stanoven termín zahájení a maximální délku trvání) a dodržování
dalších stanovených pravidel (pravidla pro probíhající projekty viz zvláštní zadání). Jedním z
výstupů aplikace by měla být možnost obeslat výzkumníky dle vybraných statusů jejich
projektů (termín dokončení ve skluzu, přečerpání přidělených finančních prostředků, dotaz při
změně pracovního zařazení nebo ukončení pracovně právního vztahu pedagoga, dotaz na
pokračování projektu při změně nebo ukončení formy studia studenty) a to jak formou mailu
tak i formou doporučeného dopisu.
IV. Přehled fází realizace projektu z hlediska
realizace RDS
Fáze realizace RDS
Úvodní studie
Cíl: co nejlépe běžným jazykem popsat požadavky uživatele a zaznamenat všechny známé
okolnosti, které mohou mít vliv na řešení problému
Procesní analýza
Cíl: co nejlépe s využitím vhodných prostředků pro vizualizaci procesů (CASE, Visio,
PowerDesigner) popsat procesy dané organizace které je nutno vzít při řešení ,
poznámka: u relativně jednoduchých nebo např. historických projektů je možno i v této části
ještě využít víceméně prostředky běžného jazyka.
Datová analýza
Cíl: popsat s využitím vhodných obvykle grafických prostředků nebo prostředků přímo
spojených s cílovou databází budoucí datový model RDS na abstraktní úrovni.
Implementace datového modelu (back-end)
Cíl: přenesení datového modelu do konkrétního prostředí pro realizaci back-end části RDS
(implementace vlastní databáze)
Implementace aplikace pro přístup k RDS (front-end)
Cíl: vytvoření aplikace, která umožní uživateli (nebo jiným systémům) přístup ke vzniklé
aplikaci typu RDS
Fáze realizace RDS – zúžený pohled
Úvodní studie
Cíl: co nejlépe běžným jazykem popsat požadavky uživatele a zaznamenat všechny známé
okolnosti, které mohou mít vliv na řešení problému
Procesní analýza
Cíl: co nejlépe s využitím vhodných prostředků pro vizualizaci procesů (CASE, Visio,
PowerDesigner) popsat procesy dané organizace které je nutno vzít při řešení ,
poznámka: u relativně jednoduchých nebo např. historických projektů je možno i v této části
ještě využít víceméně prostředky běžného jazyka.
Datová analýza
Cíl: popsat s využitím vhodných obvykle grafických prostředků nebo prostředků přímo
spojených s cílovou databází budoucí datový model RDS na abstraktní úrovni.
Implementace datového modelu (back-end)
Cíl: přenesení datového modelu do konkrétního prostředí pro realizaci back-end části RDS
(implementace vlastní databáze)
Implementace aplikace pro přístup k RDS (front-end)
Cíl: vytvoření aplikace, která umožní uživateli (nebo jiným systémům) přístup ke vzniklé
aplikaci typu RDS
V. První fáze řešení problému – analýza
požadavku zadavatele
Datová analýza – zavedení pojmů datového modelu
Entita
abstraktní kategorie, popisuje cokoli (jakýkoli výsek reality) o kterém v systému
potřebujeme uchovávat údaje…
silná (regulérní) entita – takový popisovaný výsek reality, který má smysl sám o sobě
slabá entita – takový popisovaný výsek reality, který má smysl pouze ve vztahu k nějaké
silné entitě
Doporučení při odhalování entit v úvodní studii, slovní procesní analýze, slovním zadání:
1.
vypsat nebo označit všechna podstatná jména a slovesa
2.
pokusit se převést slovesa na podstatná jména (označení)
3.
analýza dokumentů a požadovaných výstupů
4.
sestavit seznam kandidátů entit
5.
rozhodnout o kategorizaci subtypů entit
6.
provést kontrolu nadbytečností (redundancí, duplicit a multiplicit)
7.
pokusit se o zobecnění tam kde je to možné
Pozor, vždy je třeba počítat s tím, že v rámci řešení problému se bude původní seznam entit
rozrůstat i zužovat dle nových poznatků a dle zvoleného přístupu k realizaci
pů 5 – pokuste se z příkladového zadání vytipovat úplný seznam potenciálních datových entit
Všeobecné zadání RDS – příklad (pú 5)
První neupřesněné zadání
Je třeba vytvořit evidenci výzkumných úkolů studentů a pedagogů naší vysoké školy. Na škole
probíhají výzkumné úkoly různé povahy. Jsou to například vnitřní granty, granty ministerstva
školství (MŠMT), bakalářské práce, diplomové práce, postgraduální výzkumné úkoly. Na
výzkumných úkolech se podílejí jak studenti tak pedagogové. Studenti se podílejí na
výzkumných úkolech jak v rámci prezenční formy studia tak i při kombinovaném a
postgraduálním studiu. V praxi je možné, že se student podílí na výzkumu i po ukončení
studia, ale pak se obvykle jedná se o zvláštní režim výzkumného úkolu. Na úkolech se podílejí
pedagogové všech zařazení (zaměstnanec, externista, práce na dohodu o provedení práce). V
praxi není možné, aby se na výzkumném úkolu podílel pedagog který nemá v průběhu úkolu
vyřešen pracovně právní vztah k fakultě nebo již tento vztah zanikl.
Cílem vytvářené aplikace je získat: operativní přehled o probíhajících projektech, evidenci již
dokončených projektů, možnost kontrolovat projekty z hlediska jejich časového průběhu
(každý typ projektu má stanoven termín zahájení a maximální délku trvání) a dodržování
dalších stanovených pravidel (pravidla pro probíhající projekty viz zvláštní zadání). Jedním z
výstupů aplikace by měla být možnost obeslat výzkumníky dle vybraných statusů jejich
projektů (termín dokončení ve skluzu, přečerpání přidělených finančních prostředků, dotaz při
změně pracovního zařazení nebo ukončení pracovně právního vztahu pedagoga, dotaz na
pokračování projektu při změně nebo ukončení formy studia studenty) a to jak formou mailu
tak i formou doporučeného dopisu.
Všeobecné zadání RDS – příklad (pú 5)
Zadání – zvýraznění kandidáti entit
Je třeba vytvořit evidenci výzkumných úkolů |studentů a pedagogů naší vysoké školy. Na
škole probíhají výzkumné úkoly různé povahy. Jsou to například vnitřní granty, granty
ministerstva školství (MŠMT), bakalářské práce, diplomové práce, postgraduální výzkumné
úkoly. Na výzkumných úkolech se podílejí jak studenti tak pedagogové. Studenti se podílejí
na výzkumných úkolech jak v rámci prezenční formy studia tak i při kombinovaném a
postgraduálním studiu. V praxi je možné, že se student |podílí na výzkumu i po ukončení
studia, ale pak se obvykle jedná se o zvláštní režim |výzkumného úkolu. Na úkolech se
podílejí pedagogové všech zařazení (zaměstnanec, externista, práce na dohodu o provedení
práce). V praxi |není možné, aby se na výzkumném úkolu |podílel |pedagog který nemá v
průběhu úkolu vyřešen pracovně právní vztah k fakultě nebo již tento vztah zanikl.
Cílem vytvářené aplikace je získat: operativní přehled o probíhajících projektech, evidenci již
dokončených projektů, možnost kontrolovat projekty z hlediska jejich časového průběhu
(každý typ projektu má stanoven termín zahájení a maximální délku trvání) a dodržování
dalších stanovených pravidel (pravidla pro probíhající projekty viz zvláštní zadání). Jedním z
výstupů aplikace by měla být možnost obeslat výzkumníky dle vybraných statusů jejich
projektů (termín dokončení ve skluzu, přečerpání přidělených finančních prostředků,
dotaz při změně pracovního zařazení nebo ukončení pracovně právního vztahu |pedagoga,
dotaz na pokračování projektu při změně nebo ukončení formy studia studenty) a to jak
formou mailu tak i formou doporučeného dopisu.
Doporučení při sestavování seznamu kandidátů: ve fázi vytváření obecného datového modelu
pokud možno ignorujte veškerá doporučení zadavatele, která předjímají výsledek analýzy,
tato doporučení je možno vzít na vědomí, ale je velmi nevhodné s nimi přímo pracovat,
podobná doporučení v textu podtržena, doporučení však mohou obsahovat nové kandidáty
Seznam kandidátů entit
Krok 1 – nezpracovaný seznam entit (dekompozice)
výzkumné úkoly (VÚ)
studenti
pedagogové
vysoká škola
škole
výzkumné úkoly
povaha |výzkumného úkolu
vnitřní grant
grant ministerstva školství
bakalářská práce
diplomová práce
postgraduální výzkumný úkol
výzkumné úkoly
studenti
pedagogové
studenti
podíl na výzkumném úkolu
prezenční forma studia
kombinované a postgraduální studium
student
podíl na výzkumu
ukončení studia
obvykle jedná |zvláštní režim VÚ
podíl pedagogů na úkolech
zařazení |zaměstnanec
externista
práce na dohodu o provedení práce
praxi |není možné |výzkumném úkolu
|podílel |pedagog |vyřešen pracovně
právní vztah
termín zahájení VÚ
maximální délka trvání VÚ
stanovená pravidla (projektů)
možnost obeslat výzkumníky
statusů |projektů
termín dokončení VÚ
skluzu VÚ
přečerpání finančních prostředků VÚ
změna pracovního zařazení
ukončení pracovně právního vztahu
|pedagoga
mailu
doporučený dopis
Seznam kandidátů entit
Krok 2 – vyřazení kandidátů nesouvisejících s probl. (analýza)
výzkumné úkoly (VÚ)
studenti
pedagogové
vysoká škola ?
škole
výzkumné úkoly
povaha |výzkumného úkolu
vnitřní grant
grant ministerstva školství
bakalářská práce
diplomová práce
postgraduální výzkumný úkol
výzkumné úkoly
studenti
pedagogové
studenti
podíl na výzkumném úkolu
prezenční forma studia
kombinované a postgraduální studium
student
podíl na výzkumu
ukončení studia
obvykle jedná |zvláštní režim VÚ
podíl pedagogů na úkolech
zařazení |zaměstnanec
externista
práce na dohodu o provedení práce
praxi |není možné |výzkumném úkolu
|podílel |pedagog |vyřešen pracovně
právní vztah
termín zahájení VÚ
maximální délka trvání VÚ
stanovená pravidla (projektů)
možnost obeslat výzkumníky
statusů |projektů
termín dokončení VÚ
skluzu VÚ
přečerpání finančních prostředků VÚ
změna pracovního zařazení
ukončení pracovně právního vztahu
|pedagoga
mailu
doporučený dopis
Seznam kandidátů entit
Krok 3 – ztotožnění kandidátů (analýza)
výzkumné úkoly (VÚ)
povaha |výzkumného úkolu
vnitřní grant
grant ministerstva školství
bakalářská práce
diplomová práce
postgraduální výzkumný úkol
zvláštní režim VÚ
termín zahájení VÚ
termín dokončení VÚ
maximální délka trvání VÚ
statusů VÚ
skluz VÚ
podíl na výzkumném úkolu
pedagogové
studenti
studenti
pedagogové
finanční prostředky VÚ
pracovní zařazení
zaměstnanec
externista
práce na dohodu o provedení práce
změna pracovního zařazení
ukončení pracovně právního vztahu
forma studia
prezenční
kombinované
postgraduální studium
ukončení studia
Pravidla vyplývající z analýzy
v praxi |není možné |výzkumném úkolu
|podílel |pedagog |vyřešen pracovně
právní vztah
pokud student ukončí studium pak zvláštní
režim
? stanovená pravidla (projektů)
Doposud nevyjasněné záležitosti:
? možnost obeslat výzkumníky
? možnost zaslání mailu
? Zaslání Doporučeného dopisu
Klasifikace entit
Krok 4 – výběr entit – východisko pro datový model (analýza)
výzkumné úkoly (VÚ) – silná reálná entita
povaha |výzkumného úkolu
vnitřní grant
grant ministerstva školství
bakalářská práce
diplomová práce
postgraduální výzkumný úkol
termín zahájení VÚ
termín dokončení VÚ
maximální délka trvání VÚ
status VÚ ?
skluz VÚ ?
pracovní zařazení – slabá ? reál. ent.
zaměstnanec
externista
práce na dohodu o provedení práce
změna pracovního zařazení
ukončení pracovně právního vztahu
podíl na výzkumném úkolu – slabá abstr. ent.
podíl pedagogů
podíl studentů
Pravidla vyplývající z analýzy
v praxi |není možné |výzkumném úkolu
|podílel |pedagog |vyřešen pracovně
právní vztah
pokud student ukončí studium pak zvláštní
režim
? stanovená pravidla (projektů)
Studenti – silná reálná entita
forma studia - silná reál. ent.
prezenční
kombinované
postgraduální studium
ukončení studia
Pedagogové – silná reálná entita
finanční prostředky VÚ - ???
Doposud nevyjasněné záležitosti:
? možnost obeslat výzkumníky
? možnost zaslání mailu
? Zaslání Doporučeného dopisu
Vytváření datového modelu (DM)
Krok 5 – stanovení entit – základní krok tvorby DM
Definovali jsme tento seznam entit:
Výzkumné úkoly (VÚ)
Studenti
Pedagogové
Pracovní zařazení
Forma studia
Podíl na výzkumném úkolu
Finanční prostředky VÚ
Nezapomeňme, že nám zůstaly i otevřené zásadní problémy ke kterým jsem doposud nezaujali
stanovisko, k těmto problémům se vrátíme později:
Doposud nevyjasněné záležitosti:
? možnost obeslat výzkumníky
? možnost zaslání mailu
? Zaslání Doporučeného dopisu
Vztahy entit – zavedení pojmů a symbolů (UML)
Silná entita
Slabá entita
Entita A
Entita B
vztah
Entita A
1:x
Entita A
Entita B
n:m
Entita A
n:x
Entita A
Entita B
1 : 0, n
Entita A
0:x
Entita A
Self reference
Entita A
(unární vztah)
1:x
0, 1 : n
Entita A
Entita B
n:1
Entita A
Entita B
1 : 0, 1
Vytváření datového modelu (DM)
Krok 6 – analýza vztahů entit – rekapitulace entit
Do tohoto okamžiku jsme definovali tento seznam entit:
Výzkumné úkoly (VÚ)
Studenti
Pedagogové
Pracovní zařazení
Forma studia
Podíl na výzkumném úkolu
Finanční prostředky VÚ
pú 6 – vyznačte ve schématu slabé entity standardním způsobem značení
(UML)
pú 7 – pokuste se ve schématu zakreslit obecné vztahy mezi jednotlivými
datovými entitami (UML)
Vztahy entit – jedna z možností řešení
Finance VÚ ?
Forma studia
Výzkumný úkol
Pracovní zařazení
Participace na VÚ ?
Pedagog
?
Student
?
Dotaz 1 – jaké by byly nevýhody přímého vztahu Student <> VÚ ?
Dotaz 2 – proč není vztah Student <> Part. VÚ typu 1 : n ?
Dotaz 3 – najdete nějaké zjevné vady stanoveného datového modelu ?
(pokud nikoli, pak na ně možná přijdeme společně později)
Implementace entity – obecné vlastnosti relace dat
Relace - Student
Atribut
Záhlaví (Header)
1
2
3
4
Tělo (Body)
Vektor hodnot (Tuple)
Skalární hodnota
1
Kardinalita
2
Stupeň
3
4
Implementace entity – implementace relace dat
v MS SQL Server a MS Access
Množina záznamů / Množina výsledků / Tabulka - Student
Pole hodnot (Atribut)
Záhlaví (Caption)
Množina záznamů /
množina výsledků
Záznam
Hodnota
Oponentura datového modelu z hlediska normalizace
Finance VÚ
Forma studia
Výzkumný úkol
Pracovní zařazení
Student
Participace na VÚ
Pedagog
Pracovní poznámka – nutno doplnit „pracovně právní vztah“ a „studium“
Úprava datového modelu na základě oponentury
Finance VÚ
Forma studia
Výzkumný úkol
Pracovně právní
vztah
Studium
Student
Pracovní zařazení
Participace na VÚ
Pedagog
Užitečné otázky
V okamžiku kdy se zdá, že máme vyhovující a správný model enit je
vždy namístě položit si následující otázky:
Nechybí v našem modelu něco podstatného ?
tj. nezapomněli jsme zcela (vzhledem k zadání) na nějakou entitu nebo vztah
Je náš model správně navržen ?
tj. je náš model věrohodný, dostatečně podpisující realitu nebo daný problém a je
také zároveň dostatečně obecný tj. nezávislý na našem subjektivním (nebo také zaujatém,
předpojatém) úhlu pohledu
Je náš model normalizovaný z hlediska teorie RD ?
tj. je náš model věrohodný, dostatečně podpisující realitu nebo daný problém a je
také zároveň dostatečně obecný tj. nezávislý na našem subjektivním (nebo také zaujatém,
předpojatém) úhlu pohledu obsahuje informaci o všeobecné vlastnosti, kterou
Důležitá „filozofická“ poznámka:
V reálném světě neexistuje něco jako zcela optimální nebo objektivně správný návrh databáze.
Existují však různé vyzkoušené a doporučované postupy které omezují nebo vylučují základní a
později neodstranitelné vady návrhu.
Užitečné otázky – Chybí nám NĚCO ?
Jak na řešení této otázky:
U velkého a komplexního projektu budeme postupovat podle standardu
UML analýzy:
popis procesů
procesní analýza
definice aktorů
vymezení účastníků (hráčů) procesů
definice rolí
vymezení „úloh“ aktorů
vyplyne definice enit
definice programových nebo datových entit
definice vztahů entit
definice vztahů a komunikací
definice pravidel
implementace entit
implementace aplikačních a databázových struktur (tříd)
implementace vztahů entit
implementace obchodních pravidel
atd. atp.
V případě použití standardu UML (Unified Modeling Language) je už samo korektní použití daných
„Case“ prostředků částečnou zárukou úplnosti a správnosti navrženého modelu
U menšího projektu se musíme spolehnout zejména na vlastní kritický
úsudek
Dotaz 4 – pokuste se v zadání najít informaci, která signalizuje, že jsme
zapomněli na celou oblast, kterou je potřeba modelováním řešit
Všeobecné zadání RDS - příklad
První neupřesněné zadání
Je třeba vytvořit evidenci výzkumných úkolů studentů a pedagogů naší vysoké školy. Na škole
probíhají výzkumné úkoly různé povahy. Jsou to například vnitřní granty, granty ministerstva
školství (MŠMT), bakalářské práce, diplomové práce, postgraduální výzkumné úkoly. Na
výzkumných úkolech se podílejí jak studenti tak pedagogové. Studenti se podílejí na
výzkumných úkolech jak v rámci prezenční formy studia tak i při kombinovaném a
postgraduálním studiu. V praxi je možné, že se student podílí na výzkumu i po ukončení
studia, ale pak se obvykle jedná se o zvláštní režim výzkumného úkolu. Na úkolech se podílejí
pedagogové všech zařazení (zaměstnanec, externista, práce na dohodu o provedení práce). V
praxi není možné, aby se na výzkumném úkolu podílel pedagog který nemá v průběhu úkolu
vyřešen pracovně právní vztah k fakultě nebo již tento vztah zanikl.
Cílem vytvářené aplikace je získat: operativní přehled o probíhajících projektech, evidenci již
dokončených projektů, možnost kontrolovat projekty z hlediska jejich časového průběhu
(každý typ projektu má stanoven termín zahájení a maximální délku trvání) a dodržování
dalších stanovených pravidel (pravidla pro probíhající projekty viz zvláštní zadání). Jedním z
výstupů aplikace by měla být možnost obeslat výzkumníky dle vybraných statusů jejich
projektů (termín dokončení ve skluzu, přečerpání přidělených finančních prostředků, dotaz při
změně pracovního zařazení nebo ukončení pracovně právního vztahu pedagoga, dotaz na
pokračování projektu při změně nebo ukončení formy studia studenty) a to jak formou mailu
tak i formou doporučeného dopisu.
Všeobecné zadání RDS - příklad
První neupřesněné zadání
Je třeba vytvořit evidenci výzkumných úkolů studentů a pedagogů naší vysoké školy. Na škole
probíhají výzkumné úkoly různé povahy. Jsou to například vnitřní granty, granty ministerstva
školství (MŠMT), bakalářské práce, diplomové práce, postgraduální výzkumné úkoly. Na
výzkumných úkolech se podílejí jak studenti tak pedagogové. Studenti se podílejí na
výzkumných úkolech jak v rámci prezenční formy studia tak i při kombinovaném a
postgraduálním studiu. V praxi je možné, že se student podílí na výzkumu i po ukončení
studia, ale pak se obvykle jedná se o zvláštní režim výzkumného úkolu. Na úkolech se podílejí
pedagogové všech zařazení (zaměstnanec, externista, práce na dohodu o provedení práce). V
praxi není možné, aby se na výzkumném úkolu podílel pedagog který nemá v průběhu úkolu
vyřešen pracovně právní vztah k fakultě nebo již tento vztah zanikl.
Cílem vytvářené aplikace je získat: operativní přehled o probíhajících projektech, evidenci již
dokončených projektů, možnost kontrolovat projekty z hlediska jejich časového průběhu
(každý typ projektu má stanoven termín zahájení a maximální délku trvání) a dodržování
dalších stanovených pravidel (pravidla pro probíhající projekty viz zvláštní zadání). Jedním z
výstupů aplikace by měla být možnost obeslat výzkumníky dle vybraných statusů jejich
projektů (termín dokončení ve skluzu, přečerpání přidělených finančních prostředků, dotaz při
změně pracovního zařazení nebo ukončení pracovně právního vztahu pedagoga, dotaz na
pokračování projektu při změně nebo ukončení formy studia studenty) a to jak formou mailu
tak i formou doporučeného dopisu.
Užitečné otázky – Chybí nám NĚCO ?
Odpověď:
Zřejmě ano, chybí nám:
adresa – běžná pro korespondenci
adresa elektronická
Má něco společného běžná adresa s elektronickou ?
nic podstatného jedná se o dvě různé kategorie popisující zcela
odlišné věci v reálném světě, mají pouze podobný název
Zajímavost z hlediska návrhu:
Adresa (bydliště) je jedním z největších analytických „oříšků“, který v žádném reálném systému
není vyřešen ani zcela obecně ani zcela správně.
Příklady toho co je velmi těžké rozhodnout:
Je „skalárním údajem“ celá adresa - může být, ale j to velmi nepraktické
Je skalárním údajem údaj typu Date/Time
Co je správným „číslem popisným“
Jaké telefony zahrnout a jak je kategorizovat a jaký je například vztah čísla pevné linky nebo faxu k
adrese (tj. jedná se o atribut osoby nebo místa)
Jakou konvenci zavést pro směrové číslo
atd. atp.
Úprava datového modelu na základě úvahy
Finance VÚ
Forma studia
Výzkumný úkol
Pracovně právní vztah
Studium
Student
Pracovní zařazení
Participace na VÚ
Adresa bydliště
Elektr. adresa
pú 8 – doplňte chybějící vztahy
Pedagog
Úprava datového modelu na základě úvahy
Finance VÚ
Forma studia
Výzkumný úkol
Pracovně právní vztah
Studium
Student
Pracovní zařazení
Participace na VÚ
Pedagog
Adresa bydliště
Elektr. adresa
Dotaz – jaké výhody a nevýhody mají vztahy 1:N a 1:1, 1:0,n, 1:0,1, můžeme si v
praxi vůbec dovolit vztahy „bez možnosti nuly“
Užitečné otázky – Je náš model SPRÁVNĚ navržen ?
Odpověď:
Zcela jistě NE (z minula již víme, že prakticky není možno dosáhnout pozitivní odpovědi na tuto
otázku)
Zkusme to tedy jinak
Je model obecný ?
Na tuto otázku v tomto okamžiku ještě nedokážeme odpovědět, bude nutno důkladně prozkoumat
jednotlivé entity a zjistit
1. zda se nám některé entity nepřekrývají tj. zda nejsou fakticky totožné
2. zda se nám některé entity nerozpadají tj. zda jedna zdánlivá entita není
vlastně více entitami
Poznámka: tento typ úvahy již jsme intuitivně několikrát udělali (viz např. rozpad formy studia a studia
apod.)
=> musíme zkoumat navržené entity na hlubší úrovni jejich atributů
Je model optimální z hlediska implementace vztahů ?
Podíváme-li se podrobně na náš graf vztahů entit, zjistíme:
„vztahů daného typu / typ vztahu“ je více než „n-tic entit daného typu vztahu“ (prosím spočítejte)
vztahy se kříží
navržené vztahy jsou nejednoznačné (násobné)
Poznámka: obě tyto skutečnosti mohou naznačovat že je v rámci modelu nutné další zobecnění, ale
nemusí tomu tak nutně být, jedná se o indicie a na jejich základě je to nanejvýš pravděpodobné
Datový model
Finance VÚ
Forma studia
Výzkumný úkol
Pracovně právní vztah
Studium
Student
Pracovní zařazení
Participace na VÚ
Pedagog
Adresa bydliště
Elektr. adresa
pů 7 – chybně formulováno – neřešit, opravit spočítejte vztažené entity,
spočítejte vztahy a výsledek vzájemně porovnejte (nápověda vztahy unární,
binární, ternární)
Užitečné otázky – Je náš model SPRÁVNĚ navržen ?
Jak „exaktně“ postupovat při ověřování datového modelu
Nejdříve si budeme muset osvojit následující terminologii:
redundance (nadbytečnost) relací dat
bezztrátová dekompozice relací dat
kandidátní klíč relace dat
primární klíč relace dat
normalizace relací dat
normální (normalizovaná) forma relace dat
normalizovaný tvar relace dat 1 – 6 typu
Jednotlivé termíny se pokusím vysvětlit na příkladech:
Pro začátek předpokládejme, že máme hypotetickou relativně složitou množinu
(relaci) neuspořádaných dat; pro názornost si například představte
excelovskou tabulku která obsahuje následující údaje (atributy):
Trocha „optimalizační teorie“ – skalární hodnota, redundance
skalární hodnota
jedinečná hodnota, právě jedna hodnota (informace)
redundance
nadbytečnost hodnot (informace), hodnota která se v
relaci opakuje
bezztrátová dekompozice metoda optimalizace dat, jejímž cílem je rozdělení relace
dat, která obsahuje datové redundance na více relací
dat, které obsahují méně datových redundancí nebo
žádné datové redundance a to bez ztráty informace
pú 10 – najděte „buňku“ relace dat, která neobsahuje (relativně k jiným
hodnotám daného atributu) „skalární informaci“ tj. jedinečnou hodnotu
pú 11 – najděte „buňky“ relace dat, které obsahují redundantní (nadbytečná,
zdvojená, n-násobná) data
pú 12 – rozdělte příklad na více relací dat, tak, aby výsledné relace
neobsahovaly žádná redundantní data se zachováním veškeré informace
Trocha „optimalizační teorie“ – „klíč“ relace dat
kandidátní klíč atribut (jednoduchý klíč) nebo skupina atributů (složený klíč), která
v rámci dané relace dat jednoznačně definuje konkrétní vektor dat
(záznam); jinak řečeno v dané relaci dat se nesmí vyskytnout více
jak jeden záznam, s určitou kombinací hodnot kandidátního klíče (tj.
předpokladem kandidátního klíče je jednoznačnost); relace dat
může obsahovat více kandidátních klíčů
primární klíč
umělý klíč
je zvolený z hlediska implementace dat „ireducibilní“ kandidátní
klíč, který je v implementaci více vzájemně korelujících relací dat
využíván jako hlavní identifikátor určité relace dat
je uměle vytvořený kandidátní nebo primární klíč; objektivní potřeba
umělého klíče vzniká zejména v situaci, kdy přirozený klíč je příliš
složitý nebo potencionálně nejdnoznačný;
Doporučení: obecně je vhodné vždy nejdříve hledat reálný KK nebo PK, teprve pokud vyloučíme všechny možnosti reálného klíče
je vhodné přistoupit k definici umělého klíče, pozor však na skutečnost, že prakticky použitelné kandidátní klíče se v reálném
světě vyskytují poměrně zřídka…
pů 13 – ve vašem příkladu rozpadu původní datové relace určete všechny
možné kandidátní klíče
Trocha „optimalizační teorie“ – funkční závislost
dva atributy jsou funkčně závislé tehdy, pokud jeden určující atribut vyjadřuje
identitu vektoru dat (tj. jedná se o kandidátní klíč) a jiný (funkčně závislý) atribut,
který již nemusí být jednoznačný je funkčně určen určujícím atributem….
brrrr……….
Tohle určitě není možno si zapamatovat a nejedná se ani o přesnou definici daného
jevu. Přesná definice toto jevu by se musela opírat o matematickou teorii množin
(reflexivita, transitivita)….
Nicméně o funkční závislosti je potřeba se zmínit alespoň jako o jevu (bez bližšího
zkoumání) a to z toho důvodu, že na tomto jevu jsou v zásadě vystavěny moderní
databáze.
pů 14 – pokuse si představit a „osvojit“ představu funkční závislosti atributů na
příkladu
„Šestero přikázání RD“ – 1. Normální forma
Normalizace
„instantní“ doporučení jak postupovat při vytváření
„optimálního datového modelu“
1. Normální forma
datovou relaci je možno označit za 1NF, pokud jsou všechny její
atributy definovány nad skalárními obory hodnot; jinými slovy je
nutno vyloučit veškeré „neskalární“ hodnoty
POZOR! určení „jednotlivosti“ je v praxi často mnohem obtížnější než se na první pohled zdá, viz například
různé syntetické kódy, konvence apod.
datovou relaci je možno označit za 1NF, pokud neobsahuje tzv.
opakované atributy (skupiny hodnot); tj. atributy kterých může být
v praxi n., ale model relace dat počítá pouze s omezeným počtem
opakování
POZOR! v příkladu jsem použil „opakování“, které je sice teoreticky nepřípustné, ale v praxi je velmi často a
v podstatě oprávněně používáno; jedná se o klasický příklad rozporu teorie a praxe; přesto je pravidlo o
opakování velmi užitečným pravidlem a v jiných případech platí často téměř beze zbytku
pú 15 – vyškrtněte z příkladu veškeré „neskalární“ hodnoty, které neodpovídají
1. Normálnímu tvaru relace dat
pů 16 – označte v příkladu veškeré „opakující se atributy“ hodnoty, které
neodpovídají 1. Normálnímu tvaru relace dat
„Šestero přikázání RD“– 2. Normální forma
2. Normální forma
platí vzestupná hierarchie normálních formě, tj. relace dat je v 2.
Normální formě tehdy, pokud je v 1. Normální formě a zároveň
všechny její prvky jsou závislé na celém kandidátním klíči (v
implementaci PK); jinými slovy je možno tento požadavek
charakterizovat jako „přikázání“že jedna relace dat nemá obsahovat
popis více různých entit
pů 17 – vypište relace dat, které jsou 100% v 2.N.f.
pů 18 – vypište relace dat, které jsou pravděpodobně v 2.N.f.
pú 19 – vypište relace dat, které určitě nejsou v 2.N.f.
1
2
3
4
5
„Šestero přikázání RD“– 3. Normální forma
3. Normální forma
platí vzestupná hierarchie normálních formě, tj. relace dat je v 3.
Normální formě tehdy, pokud je v 2. Normální formě a zároveň
všechny její neklíčové atributy jsou vzájemně nezávislé
pú 20 – předpokládejme, že se jedná o entitu „student“, které atributy je třeba
určitě odstranit, aby relace byla v 3.N.f.,
doporučení: pokud můžete volit mezi funkčně závislým atributem a určujícím atributem, vždy volte
odstranění závislého atributu
pů 21 – předpokládejme, že se jedná o entitu „student“, které atributy je třeba
pravděpodobně odstranit, aby relace byla v 3.N.f.
1
2
3
4
5
6
7
8
„Šestero přikázání RD“– 4.-6. Normální forma
Těmito normalizovanými formami se zde nebudeme zabývat, protože se týkají
speciálních případů a modelování složitých (a také relativně vzácných) vztahů…
Ještě trocha teorie a pak už více praxe…
Posledním důležitým termínem je INTEGRITA dat.
Integrita dat v obecné rovině je „formální“ správnost a vzájemná hodnotová
korespondence dat v databázi.
Pro zajištění datové integrity existuje více (různě implementovaných) mechanizmů
zajištění datové integrity
Integrita je následujících typů:
Doménová integrita
obor hodnot (souvisí s datovými typy, nezaměňovat !)
Přechodová / stavová i. definované stavy vektorů dat
Entitová integrita
PK, constrainty, triggery
Referenční integrita
FK – cizí klíč (sirotci)
Transakční integrita
Datová integrita
Procedurální integrita
triggery
Trocha hloubání o NIČEM
velmi důležitá „hodnota“:
NULL
Pokus s „hodnotou“ NULL – tzv. ternární logika
POZOR platí že NULL != NULL
pú 22 – vyhledejte v uživatelské databázi pomocí
příkazu typu DSL studenty bez zadaného telefonního
čísla
VI. Vlastní implementace databáze dle
analytického příkladu
Implementace databáze – atributy
Analýza entit z hlediska atributů
Definiční atribut (ID)
nemá vlastní význam, zajišťuje identifikaci
Proprietální (vlastní) atribut obsahuje skalární informaci o „přirozeně“ vlastní vlastnosti
entity z hlediska reálného světa
Popisný (volný) atribut
obsahuje informaci o všeobecné vlastnosti, kterou definoval
tvůrce aplikace, k realitě má více či méně volný vztah
Statutární atribut
obsahuje informaci o statusu sledovaném z hlediska aplikace
pú 23 – pomocí pohledu do datového katalogu user_tables zjistěte které datové
entity jsou již ve vaší uživatelské databázi implementovány
pú 24 – pomocí Schématu 2 pracovního listu zjistěte které datové entity chybí
(tj. nejsou ve vaší uživatelské databázi implementovány)
pú 25 – zjistěte rozdíly v implementaci oproti datovému modelu
Implementace databáze – návrh nových entit
Analýza entit z hlediska atributů
Definiční atribut (ID)
nemá vlastní význam, zajišťuje identifikaci
Proprietální (vlastní) atribut obsahuje skalární informaci o „přirozeně“ vlastní vlastnosti
entity z hlediska reálného světa
Popisný (volný) atribut
obsahuje informaci o všeobecné vlastnosti, kterou definoval
tvůrce aplikace, k realitě má více či méně volný vztah
Statutární atribut
obsahuje informaci o statusu sledovaném z hlediska aplikace
pů 26 – rozdělíme se do dvojic a každá dvojice dostane přiřazenu jednu
chybějící datovou entitu a pokusí se navrhnout její konkrétní podobu, tj.
pokuste se nalézt a definovat dostatečný počet atributů jednotlivých
sledovaných entit, tak, aby v dostatečné míře určovaly základní vlastnosti
těchto entit, u všech definovaných atributů vyznačte jejich zařazení do jedné z
kategorií viz výše, datový typ apod. POZOR je nutno se snažit o kompatibilitu s
existujícími datovými entitami v uživatelské databázi
Hledání „správných“ atributů definovaných entit
Úkol 21 – společně se pokusíme navrhnout vhodné atributy pro jednotlivé entity
Úkol 22 – u navržených atributů navrhněte domény hodnot
Úkol 23 – u navržených atributů navrhněte omezení
Úprava datového modelu na analýzy atributů – zobecnění modelu
Finance VÚ
Forma studia
Výzkumný úkol
Participace na VÚ
Studium
Student
Pedagog
Partner
Adresa bydliště
Elektr. adresa
Pracovní zařazení
Pracovně právní vztah
Implementace databáze – datové typy MS Access
Vybrané datové typy Oracle:
Integer / Int
Number
Varchar2
Date
Memo
Blob
Clob
a některé další….
číslo typu Integer (-3*104 - 3*104 )
číslo s dvojitou s téměř libovolnou
textový řetězec typu Varchar
„dlouhé datum“
„neomezeně“ dlouhý formátovaný text
binární data / obrázek
binární data / dokument
Omezení Null / No Null:
Hodnota Null
třístavová logika (podrobněji dále)
Jiné:
Použití DBO sekvencí (obdoba datového typu Autoinkrement v jiných databázích)
Descargar

Prezentace aplikace PowerPoint