Databázové systémy teorie a návrh relačních databázových systémů

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ů

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 RDS Databázové stroje - běžné Prostředí pro definici a správu dat Microsoft Accsess Visual Database Tools Microsoft Query SQL server Enterprise Manager SQL+ Toad Vývoj Front-end aplikací 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 JetSQL serverOracle

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 Úkol 1 – z příkladového zadání vypište seznam entit

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 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 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Ú ? 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ě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 - silná reál. ent. 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

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ů Silná entita Slabá entita Entita AEntita B vztah Entita A 1 : x Entita A n : x Entita A 0 : x Entita A 1 : x Entita AEntita B n : 1 Entita AEntita B n : m Entita AEntita B 1 : 0, n Entita A Self reference (unární vztah) 0, 1 : n Entita AEntita 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Ú Úkol 2 – nakreslete schéma známých entit a pomocí známých symbolů vyjádřete vztahy mezi entitami

Vztahy entit – jedna z možností řešení Výzkumný úkol Participace na VÚ ? StudentPedagog Forma studiaPracovní 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) Kardinalita Stupeň Skalární hodnota

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

Výzkumný úkol Participace na VÚ StudentPedagog Forma studiaPracovní zařazení Finance VÚ Oponentura datového modelu z hlediska normalizace Pracovní poznámka – nutno doplnit „pracovně právní vztah“ a „studium“

Výzkumný úkol Participace na VÚ StudentPedagog Forma studiaPracovní zařazení Finance VÚ Úprava datového modelu na základě oponentury StudiumPracovně 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 enitdefinice programových nebo datových entit definice vztahů entitdefinice vztahů a komunikací definice pravidel implementace entitimplementace 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 Úkol 5 – 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.

Výzkumný úkol Participace na VÚ StudentPedagog Forma studiaPracovní zařazení Finance VÚ Úprava datového modelu na základě úvahy Studium Pracovně právní vztah Adresa bydliště Elektr. adresa Úkol 6 – navrhněte vztahy

Výzkumný úkol Participace na VÚ StudentPedagog Forma studiaPracovní zařazení Finance VÚ Úprava datového modelu na základě úvahy Studium Pracovně právní vztah 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é

Výzkumný úkol Participace na VÚ StudentPedagog Forma studiaPracovní zařazení Finance VÚ Datový model Studium Pracovně právní vztah Adresa bydliště Elektr. adresa Úkol 7 – 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í hodnotajedinečná hodnota, právě jedna hodnota (informace) redundancenadbytečnost hodnot (informace), hodnota která se v relaci opakuje bezztrátová dekompozicemetoda 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 Úkol 8 – najděte „buňku“ relace dat, která neobsahuje (relativně k jiným hodnotám daného atributu) „skalární informaci“ tj. jedinečnou hodnotu Úkol 9 – najděte „buňky“ relace dat, které obsahují redundantní (nadbytečná, zdvojená, n-násobná) data Úkol 10 – 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… Úkol 11 – 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. Úkol 12 – 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 Úkol 13 – vyškrtněte z příkladu veškeré „neskalární“ hodnoty, které neodpovídají 1. Normálnímu tvaru relace dat Úkol 14 – 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 Úkol 14 – vypište relace dat, které jsou 100% v 2.N.f. Úkol 15 – vypište relace dat, které jsou pravděpodobně v 2.N.f. Úkol 16 – vypište relace dat, které určitě nejsou v 2.N.f

„Š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é Úkol 17 – 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 Úkol 18 – předpokládejme, že se jedná o entitu „student“, které atributy je třeba pravděpodobně odstranit, aby relace byla v 3.N.f

„Šestero přikázání RD“– 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á integritaobor hodnot (souvisí s datovými typy, nezaměňovat !) Přechodová / stavová i.definované stavy vektorů dat Entitová integritaPK, constrainty, triggery Referenční integritaFK – cizí klíč (sirotci) Transakční integrita Datová integrita Procedurální integritatriggery (Access nemá, respektive velmi omezené)

Trocha hloubání o NIČEM hodnota: NULL

Implementace databáze – atributy Analýza entit z hlediska atributů Definiční atribut (ID)nemá vlastní význam, zajišťuje identifikaci Proprietální (vlastní) atributobsahuje skalární informaci o „přirozeně“ vlastní vlastnosti entity z hlediska reálného světa Popisný (volný) atributobsahuje informaci o všeobecné vlastnosti, kterou definoval tvůrce aplikace, k realitě má více či méně volný vztah Statutární atributobsahuje informaci o statusu sledovaném z hlediska aplikace Úkol 19 – 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 Úkol 20 – u všech definovaných atributů vyznačte jejich zařazení do jedné z kategorií viz výše

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Ú StudentPedagog Forma studiaPracovní zařazení Finance VÚ Úprava datového modelu na analýzy atributů – zobecnění modelu Studium Pracovně právní vztah Adresa bydlištěElektr. adresa Partner

Implementace databáze – datové typy MS Access Vybrané datové typy MS Access: Autoincrement „samo-povyšující“ se číslo typu Long (-2* *10 9 ) Integer / Int číslo typu Integer (-3* *10 4 ) Long číslo typu Long (-2* *10 9 ) Number číslo s dvojitou přesností SmallInt malé celé číslo typu Integer (cca – ) Float číslo s plovoucí řádovou čárkou String textový řetězec typu Varchar Date „dlouhé datum“ Money přesný finanční formát Bit booleovské hodnoty True / False Memo „neomezeně“ dlouhý formátovaný text Image binární data / obrázek URL URL adresa a některé další…. Omezení Null / No Null: Hodnota Null třístavová logika (podrobněji dále)

ANSI SQL Pohádka o standardu který téměř nikdo nedodržuje, ale i přesto se jedná o jeden z nejužitečnějších standardů v oblasti IT… o jazyku SQL… Základ jazyka: SQLneprocedurální jazyk pro množinovou správu dat relačních databází Nástavby jazyka SQL: T-SQL, PL SQL obecně všechny procedurální rozšíření SQL Typy dotazů SQL: Dotazpro náhled / zpracování výsledku dat DDL dotazvytvářecí dotaz DML dotazmodifikační dotaz

DDL Data Definition Language – vytvářecí dotazy Dotazy DDL slouží k vytváření, rušení a modifikaci datových struktur datových omezení indexů pohledů triggerů (spouští) procedur pro manipulaci s daty

DDL Data Definition Language – vytvářecí dotazy CREATE TABLE [ database_name.[ owner ]. | owner. ] table_name ( { | column_name AS computed_column_expression | ::= [ CONSTRAINT constraint_name ] } | [ { PRIMARY KEY | UNIQUE } [,...n ] ) ::= [ CONSTRAINT constraint_name ] { [ NULL | NOT NULL ] | [ { PRIMARY KEY | UNIQUE } ] | [ [ FOREIGN KEY ] REFERENCES ref_table [ ( ref_column ) ] [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] ] }

DDL Data Definition Language – vytvářecí dotazy ALTER TABLE ALTER TABLE table { [ ALTER COLUMN column_name { new_data_type [ ( precision [, scale ] ) ] [ NULL | NOT NULL ] ] | ADD { [ ] | column_name AS computed_column_expression } [,...n ] | [ WITH CHECK | WITH NOCHECK ] ADD { } [,...n ] | DROP { [ CONSTRAINT ] constraint_name | COLUMN column } [,...n ] | { CHECK | NOCHECK } CONSTRAINT { ALL | constraint_name [,...n ] } | { ENABLE | DISABLE } TRIGGER { ALL | trigger_name [,...n ] } } ::= { column_name data_type } [ [ DEFAULT constant_expression ] [ WITH VALUES ] | [ IDENTITY [ (seed, increment ) [ NOT FOR REPLICATION ] ] ] ] [ ROWGUIDCOL ] [ COLLATE ] [ ] [...n ] ………………… …………………. ::= [ CONSTRAINT constraint_name ] { [ NULL | NOT NULL ] | [ { PRIMARY KEY | UNIQUE } [ CLUSTERED | NONCLUSTERED ] [ WITH FILLFACTOR = fillfactor ] [ ON { filegroup | DEFAULT } ] ] | [ [ FOREIGN KEY ] REFERENCES ref_table [ ( ref_column ) ] [ ON DELETE { CASCADE | NO ACTION } ] ] | CHECK [ NOT FOR REPLICATION ] ( logical_expression ) } ::= [ CONSTRAINT constraint_name ] { [ { PRIMARY KEY | UNIQUE } { ( column [,...n ] ) } | FOREIGN KEY [ ( column [,...n ] ) ] REFERENCES ref_table [ ( ref_column [,...n ] ) ] [ ON DELETE { CASCADE | NO ACTION } ] | DEFAULT constant_expression [ FOR column ] [ WITH VALUES ] | CHECK [ NOT FOR REPLICATION ] ( search_conditions ) }

DDL Data Definition Language – další vytvářecí dotazy - stručně CREATE INDEX… CREATE TRIGGER… CREATE PROCEDURE… CREATE VIEW… DROP INDEX, TRIGGER, PROCEDURE…. atd.

DML Data Modification Language – aktualizační dotazy UPDATE … INSERT.… DELETE.… Aktualizační dotazy slouží k změnám množin dat

DML Data Selection Language – výběrové dotazy SELECT … HAVING.… UNION.… ORDER.… GROUP.… Aktualizační dotazy slouží k změnám množin dat

Implementace databáze V tuto chvíli již víme dost na to, abychom se mohli pokusit implementovat „reálný“ příklad funkční relace dat na základě našeho příkladového zadání. Úkol 21 – pokuste se pomocí řádkových vytvářecích dotazů postupně implementovat veškeré potřebné datové entity, veškeré vytvářecí dotazy si postupně ukládejte jako vzestupně očíslované dotazy, v první fázi neřešte otázky datové integrity a vazeb Úkol 22 – u definovaných entit stanovte a implementujte PK Úkol 23 – u definovaných entit stanovte a implementujte FK Úkol 24 – implementujte potřebné indexy Úkol 25 – v případě potřeby pomocí vizuálního návrháře doplňte hodnotová omezení Úkol 26 – do realizovaných datových struktur zadejte určitý vzorek „reálných dat“