Download ppt - Databázové systémy teorie a návrh relačních databázových systémů část I

Databázové systémyteorie 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 klientanevý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 datsouborové 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é formyhistorické 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émyOracle, MSSQL Server, MS Access

• Objektově orientované báze datXML (….)Objektový databázový koncept (ODC)implementace ODC v současných relačních systémechvyužití v komunikacích (Queuing)

II. Relační databázové systémy

Charakteristika relačního DS (RDS)

Hlavní požadavkyefektivita (HW, SW, Lidské zdroje, rychlé vyhledávání)spolehlivost (bezpečnost dat, stabilita, zabezpečení proti zneužití)implementace relačního modelu

Historieteorii 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 datrelace 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 datrelace 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 řádkupř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 dats 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í dattabulkapohledvý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

Prostor problému – definovaná část reálného světa

Datový model – myšlenkový popis daného prostoru

problému

Databázové schéma – implementovatelný

popis dat. modelu

Databáze – fyzická implementace databázového

schématu

Databázový stroj – není součástí databáze

Aplikace – Uživatelské rozhraní

Vlastní Databázový systém

Myšlenkový (konceptuální)

prostor problému

Možnosti implementace RDSDatabázové stroje - běžné

Prostředí pro definici a správu dat

Microsoft AccsessVisual Database Tools

Microsoft QuerySQL server Enterprise Manager

SQL+Toad

Vývoj Front-end aplikací

Microsoft AccsessVisual Basic

C++, C#HTMLASPJava

Obj. komp. pro přístup k datům

ADODAO / Jet

DAO / ODBCRDO

Oracle clientBDE, 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 RDSKoncepce 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ýzaCí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ýzaCí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

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



Všeobecné zadání RDS – příklad (pú 5)

Zadání – zvýraznění kandidáti entitJe 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ů entitKrok 1 – nezpracovaný seznam entit (dekompozice)

výzkumné úkoly (VÚ)studentipedagogové vysoká školaškolevýzkumné úkolypovaha |výzkumného úkoluvnitřní grantgrant ministerstva školstvíbakalářská prácediplomová prácepostgraduální výzkumný úkolvýzkumné úkolystudentipedagogovéstudentipodíl na výzkumném úkoluprezenční forma studiakombinované a postgraduální studiumstudentpodíl na výzkumuukončení studiaobvykle jedná |zvláštní režim VÚ

podíl pedagogů na úkolechzařazení |zaměstnanecexternistapráce na dohodu o provedení prácepraxi |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íkystatusů |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 |pedagogamailu doporučený dopis

Seznam kandidátů entitKrok 2 – vyřazení kandidátů nesouvisejících s probl. (analýza)

výzkumné úkoly (VÚ)studentipedagogové vysoká škola ?školevýzkumné úkolypovaha |výzkumného úkoluvnitřní grantgrant ministerstva školstvíbakalářská prácediplomová prácepostgraduální výzkumný úkolvýzkumné úkolystudentipedagogovéstudentipodíl na výzkumném úkoluprezenční forma studiakombinované a postgraduální studiumstudentpodíl na výzkumuukončení studiaobvykle jedná |zvláštní režim VÚ

podíl pedagogů na úkolechzařazení |zaměstnanecexternistapráce na dohodu o provedení prácepraxi |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íkystatusů |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 |pedagogamailu doporučený dopis

Seznam kandidátů entitKrok 3 – ztotožnění kandidátů (analýza)výzkumné úkoly (VÚ)

povaha |výzkumného úkoluvnitřní grantgrant ministerstva školstvíbakalářská prácediplomová prácepostgraduální výzkumný úkolzvláš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 úkolupedagogovéstudenti

studenti

pedagogové

finanční prostředky VÚ

pracovní zařazenízaměstnanecexternistapráce na dohodu o provedení práce

změna pracovního zařazení ukončení pracovně právního vztahu

forma studiaprezenčníkombinovanépostgraduální studiumukončení studia

Pravidla vyplývající z analýzyv 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 entitKrok 4 – výběr entit – východisko pro datový model (analýza)výzkumné úkoly (VÚ) – silná reálná entita

povaha |výzkumného úkoluvnitřní grantgrant ministerstva školstvíbakalářská prácediplomová prácepostgraduální výzkumný úkoltermí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 – slabá abstr. ent.podíl pedagogůpodíl studentů

Studenti – silná reálná entita

Pedagogové – silná reálná entita

finanční prostředky VÚ - ???

pracovní zařazení – slabá ? reál. ent.zaměstnanecexternistapráce na dohodu o provedení práce

změna pracovního zařazení ukončení pracovně právního vztahu

forma studia - silná reál. ent.prezenčníkombinovanépostgraduální studiumukončení studia

Pravidla vyplývající z analýzyv 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ů)


Vytváření datového modelu (DM)Krok 5 – stanovení entit – základní krok tvorby DM

Definovali jsme tento seznam entit:Výzkumné úkoly (VÚ)StudentiPedagogovéPracovní zařazeníForma studiaPodíl na výzkumném úkoluFinanční prostředky VÚ

Nezapomeňme, že nám zůstaly i otevřené zásadní problémy ke kterým jsem doposud nezaujalistanovisko, k těmto problémům se vrátíme později:


Vztahy entit – zavedení pojmů a symbolů (UML)

Silná entita Slabá entita Entita A Entita B

vztah

Entita A 1 : x

Entita A n : x

Entita A 0 : x

Entita A 1 : x

Entita A Entita B n : 1

Entita A Entita B n : m

Entita A Entita B 1 : 0, n

Entita ASelf reference(unární vztah)

0, 1 : n

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Ú)StudentiPedagogovéPracovní zařazeníForma studiaPodíl na výzkumném úkoluFinanční prostředky VÚ

pú 7 – pokuste se ve schématu zakreslit obecné vztahy mezi jednotlivými datovými entitami (UML)

pú 6 – vyznačte ve schématu slabé entity standardním způsobem značení (UML)

Vztahy entit – jedna z možností řešení

Výzkumný úkol

Participace na VÚ ?Student Pedagog

Forma studia Pracovní zařazení

Finance VÚ ?

?

?

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)

Tělo (Body)

Vektor hodnot (Tuple)

1234

Kardinalita

1 2

3

4

Stupeň

Skalární hodnota

Implementace entity – implementace relace datv 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áznamHodnota

Výzkumný úkol

Participace na VÚStudent Pedagog


Finance VÚ

Oponentura datového modelu z hlediska normalizace

Pracovní poznámka – nutno doplnit „pracovně právní vztah“ a „studium“

Výzkumný úkol



Finance VÚ

Úprava datového modelu na základě oponentury

Studium Pracovně právní vztah

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 entitdefinice vztahů entit definice vztahů a komunikacídefinice pravidelimplementace entit implementace aplikačních a databázových struktur (tříd)implementace vztahů entitimplementace obchodních pravidelatd. 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







Užitečné otázky – Chybí nám NĚCO ?

Odpověď:Zřejmě ano, chybí nám:

adresa – běžná pro korespondenciadresa 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/TimeCo 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é čísloatd. atp.

Výzkumný úkol



Finance VÚ

Úprava datového modelu na základě úvahy


Adresa bydliště

Elektr. adresa

pú 8 – doplňte chybějící vztahy

Výzkumný úkol



Finance VÚ

Úprava datového modelu na základě úvahy


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 jinakJe 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 zjistit1. 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é

Výzkumný úkol



Finance VÚ

Datový model


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í datbezztrátová dekompozice relací datkandidátní klíč relace datprimární klíč relace datnormalizace relací datnormá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 vrelaci 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íč 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 umělý klíč 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í

Výzkumný úkol

Participace na VÚ

Student Pedagog


Finance VÚ

Úprava datového modelu na analýzy atributů – zobecnění modelu


Adresa bydliště Elektr. adresa

Partner

Implementace databáze – datové typy MS Access

Vybrané datové typy Oracle:Integer / Int číslo typu Integer (-3*104 - 3*104 )Number číslo s dvojitou s téměř libovolnouVarchar2 textový řetězec typu VarcharDate „dlouhé datum“Memo „neomezeně“ dlouhý formátovaný textBlob binární data / obrázekClob binární data / dokumenta některé další….

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)