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

1. Databázové systémyteorie a návrh relačních databázových systémůčást I

2. 0. Pracovní prostředky

3. S jakými prostředky budeme pracovat Verze 10g

4. Vytvoření jednotlivých DBO schémat Vytvoření jednotlivých schémat (USER) probíhá pod zvláštním privilegovaným účtem system

5. Přihlášení uživatele do vlastního DBO schématu (pú 1) uzivatelx (x=1-n) heslo

6. Vnitřní organizace DBO schématu – TEBLESPACES & DATAFILES

7. Vnitřní organizace DBO schématu - USERS

8. 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

9. 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“)

10. 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

11. I. Všeobecný úvod

12. 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)

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

14. 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ů

15. 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í)

16. Co je možno provádět s relacemi dat + = - = =>

17. 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ýpisatributů datové tabulky SQL (DSL)>SELECT PRIJMENI, JMENO, ULICE, OBEC, PSC FROM student ORDER BY PRIJMENI, JMENO;-částečný výpisatributů 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é relacedat – 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ýmROWNUM druhého řádu a s ROWNUM bez aliasu – pokuste se o vysvětlení tohoto jevu

18. 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

19. Možnosti implementace RDS 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 Databázové stroje - běžné 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

20. Oracle Express s HTTP klientem Server Klient

21. 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ů

22. 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

23. 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

24. III. Příklad řešeného problému

25. 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.

26. IV. Přehled fází realizace projektu z hlediska realizace RDS

27. 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

28. 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

29. V. První fáze řešení problému – analýza požadavku zadavatele

30. 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í: • vypsat nebo označit všechna podstatná jména a slovesa • pokusit se převést slovesa na podstatná jména (označení) • analýza dokumentů a požadovaných výstupů • sestavit seznam kandidátů entit • rozhodnout o kategorizaci subtypů entit • provést kontrolu nadbytečností (redundancí, duplicit a multiplicit) • 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

31. 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.

32. 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 obsahovatnové kandidáty

33. Seznam kandidátů entit podílpedagogů 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 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Ú Krok 1 – nezpracovaný seznam entit (dekompozice)

34. Seznam kandidátů entit podílpedagogů 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 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Ú Krok 2 – vyřazení kandidátů nesouvisejících s probl. (analýza)

35. Seznam kandidátů entit • 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 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Ú Krok 3 – ztotožnění kandidátů (analýza)

36. Klasifikace entit • 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 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Ú statusVÚ? 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Ú - ??? Krok 4 – výběr entit – východisko pro datový model (analýza)

37. Vytváření datového modelu (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 Krok 5 – stanovení entit – základní krok tvorby DM

38. Vztahy entit – zavedení pojmů a symbolů (UML) Silná entita Entita A Entita B Slabá entita vztah Entita A Entita A Entita B n : m 1 : x Entita A Entita A Entita B 1 : 0, n n : x Entita A Entita A 0 : x Self reference (unární vztah) 0, 1 : n Entita A 1 : x Entita A Entita B n : 1 Entita A Entita B 1 : 0, 1

39. Vytváření datového modelu (DM) • 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Ú Krok 6 – analýza vztahů entit – rekapitulace entit 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)

40. Vztahy entit – jedna z možností řešení Finance VÚ ? Forma studia Výzkumný úkol Pracovní zařazení ? Student Participace na VÚ ? Pedagog ? 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)

41. 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 2 3 4 Kardinalita Stupeň

42. 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áznam Hodnota

43. 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“

44. Úprava datového modelu na základě oponentury Finance VÚ Forma studia Výzkumný úkol Pracovní zařazení Studium Pracovně právní vztah Student Participace na VÚ Pedagog

45. 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.

46. 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

47. 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.

48. 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.

49. 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.

50. Úprava datového modelu na základě úvahy Finance VÚ Forma studia Výzkumný úkol Pracovní zařazení Studium Pracovně právní vztah Participace na VÚ Student Pedagog Adresa bydliště Elektr. adresa pú 8 – doplňte chybějící vztahy