Překlady této stránky:

Semestrální práce

Semestrální práce je hlavním výstupem studenta z předmětu. Každý student pracuje individuálně na svém projektu dle vlastního tématu.

Cílem praktické části předmětu DBS je vyzkoušet si návrh a vývoj datového úložiště v SQL databázi. Provedete vývoj nějakého menšího informačního systému – od datové analýzy přes návrh struktury úložiště až po jeho vytvoření a naplnění testovacími daty. Správnost návrhu ověříte sadou SQL příkazů.

Téma práce není nijak omezeno, musíte však vyučující uvést do jeho problematiky pomocí přiloženého „příběhu“ – popisu řešené domény. Zkuste být originální, léta se tu objevují dokola knihovny a videopůjčovny; oblíbené jsou také databáze RPG her. Mezi zajímavé projekty vašich předchůdců patřily třeba informační systémy krematoria, hřbitova, vězení, nebo databáze milenců, králíků a žížal.

Odevzdání semestrální práce probíhá v několika krocích na jednotlivých cvičeních, za nedodržení termínu odevzdání těchto kroků následuje nemalá bodová penalizace. Požadavky a termíny jednotlivých kontrolních bodů naleznete vždy v kalendáři.

V semestru B162 (Letní semestr ak. roku 2016/2017) bude poprvé celá semestrální práce povinně kompletně řešena přes portál http://dbs.fit.cvut.cz.

Obsah

  1. Úvodní odborný článek s popisem domény, který slouží jako podklad pro návrh struktury datového úložiště. Součástí je alespoň 25 rozmanitých dotazů formulovaných v přirozeném jazyku. Tyto dotazy musí, mimo další kategorie, pokrývat povinně kategorie A, B, C, D atd z Tabulky kategorií dotazů.
  2. Návrh struktury datového úložiště ve formě konceptuálního schématu, které odpovídá popisu domény.
  3. Implementace ve zvoleném databázovém stroji (k dispozici máte databázi Oracle, implementovat však můžete v libovolném stroji - to však nedoporučujeme v souběhu s portálem DBS)
  4. SQL skript pro naplnění databáze vhodnými testovacími daty v dostatečném množství
  5. Alespoň 10 dotazů zmíněných v popisu formulovaných v relační algebře
  6. Alespoň 25 dotazů v jazyce SQL nad vaším úložištěm, mezi nimiž bude deset dotazů formulovaných výše v relační algebře a také příkazy pro manipulaci s daty

Struktura

Zadání

Téma si určujete sami, je třeba je však popsat a specifikovat pro dostatečné pochopení souvislostí (cca 300 slov).

Návrh struktury datového úložiště

Jedná se o formalizaci zadání v standardizované grafické notaci. Ta souvisí s nástrojem, ve kterém model vytvoříte, typicky je to UML Class Diagram (Enterprise Architect), binární ER model (Oracle SQL Developer) či relační model (SQL Power Architect).

Grafický návrh vám dá přehledný pohled na celou situaci bez zbytečných implementačních detailů (neobsahuje cizí klíče, tabulky vynucené databázovými vztahy) a donutí vás doplnit důležitá integritní omezení: domény atributů, identifikátory entit, kardinality a parciality vztahů.

Při použití vhodného nástroje můžete rovnou získat i vygenerovaný SQL kód pro vybraný databázový stroj.

Výsledkem této části práce je úplný návrh úložiště na konceptuální úrovni, to znamená:

  • obrázek databázového schématu v nějakém rozumném formátu (např. PNG),
  • zdrojový soubor pro příslušný nástroj (ZIP soubor),
  • slovní vyjádření integritních omezení, které nejdou zahrnout do vizuálního modelu (např. „čtenář si smí půjčit jen deset knih současně“),
  • diskuse rizik, plynoucích ze smyček, které se ve vašem schématu vyskytnou. Smyčka může a nemusí být zdrojem nekonzistencí dat a proto je nutné se nad nimi zamyslet a sdělit výsledek vašeho zamyšlení. Nepopisujte zde to, co lze při pojmenovaných hranách vyčíst ze schématu, diskutujte rizika,
  • celkem by ve schématu mělo být cca 10 typů entit.
  • všechny hrany musí být ohodnoceny názvy rolí účastníka odpovídajího typu vztahu.

Implementace úložiště

V tuto chvíli již musíte rozhodnout o použitém databázovém stroji (k dispozici máte Oracle, ale použít můžete libovolný relační stroj). Ve vybraném stroji byste se měli umět pohybovat jak v řádkovém, tak i grafickém editoru, velmi vám to usnadní tvorbu semestrální práce.

Create script

SQL script, který po spuštění vytvoří relační schéma datového úložiště. Typicky vám ho může téměř hotový poskytnout modelovací nástroj. Nezapomeňte však zkontrolovat, že skutečně bude dělat to, co chcete, a také doplňte další integritní omezení, která nebyla zachycená ve vytvořeném schématu. Na začátek dávky přidejte příkazy, které zruší případně dříve vytvořené tabulky schématu (rada, jak na to je uvedena zde ). S výjimkou příkazů DROP, které ruší dříve vytvořené tabulky (při prvním spuštění ještě nebudou existovat) musí všechny příkazy skončit bez chyby.

Pokud použijete procedury uložené do databáze, jejichž definice je uvedena v DEMO semestrálce (což je dovoleno), uveďte to výslovně v seznamu použitých zdrojů

Insert script

Všechny vytvořené relační tabulky je třeba naplnit konzistentními testovacími daty tak, abyste nad nimi mohli ladit jednotlivé dotazy. Vhodné množství jednotlivých záznamů je takové, aby vás neomezovalo při tvorbě dotazů – ty by neměly vracet ani prázdný výsledek, ale typicky ani všechny záznamy z té které tabulky.

Žádný příkaz nesmí skončit chybou. Máte-li zapnuté kontroly integritních omezení typu reference (cizí klíč), je potřeba plnit data v takovém pořadí, aby byly vytvořeny nejdříve odkazované záznamy a pak teprve odkazující. Usnadnit si to můžete tím, že na začátku kontroly vypnete. Na konci pak ale MUSÍTE kontroly zase zapnout. Při zapnutí kontrol se projdou všechna data a zkontrolují, zda tomu kterému zapínanému IO vyhovují. Když nevyhovují, tak nastane chyba a kontrola se nezapne, což u vás nesmí nastat. V DEMO semestrálce jsou pro hromadná zapnutí a vypnutí kontrol připraveny dvě procedury, které můžete převzít (uvedete to mezi využité zdroje).

V tvorbě tohoto skriptu vám může pomoci vhodný databázový klient – naplňte databázi například pomocí formulářového rozhraní a pak si nechte insert script vygenerovat. Studenty oblíbený je také Generuj data.

Nezapomínejte na transakční zpracování – do jedné transakce se sdružují pouze vzájemně podmíněné DML příkazy a má být co nejkratší. Všechny transakce musí být korektně potvrzeny (commit). Výsledkem této části je jeden skript, který inicializuje data ve všech relačních tabulkách navrženého úložiště. Dávku připravte tak, aby ji bylo možné spouštět bez chyb opakovaně.

Dotazy

Obecné požadavky na dotazy:

  • musí vracet rozumné výsledky, ne například jen identifikátory,
  • příkazy musí být rozmanité – po dokončení všech 25 dotazů musíte mít pokryté všechny řádky předepsané V tabulce kategorií dotazů (jeden příkaz může pokrývat více kategorií současně), přičemž dotazy napsané v RA musí povinně pokrývat kategorie A, B, C a D.
  • výsledek dotazu musí být neprázdný, proto doplňte potřebná testovací data (výjimka je dotaz kategorie D2, který kontroluje správnost odpovědi na dotaz z kategorie D2) ),
  • výsledek dotazu musí mít „čitelný“ tvar, nesmí obsahovat pouze id-čka (například, ne pouze id zákazníka, nýbrž i jméno a příjmení zákazníka),
  • u složitých dotazů proveďte raději kontrolu výsledku inverzním dotazem. Případné kontrolní dotazy se také počítají do limitu 10, resp.25,
  • Je-li dotaz zpracovaný jak v RA, tak SQL, obě formulace musí vracet stejnou množinu řádků (případně výsledky mohou být vizuálně jinak setříděné)

Dotazy v relační algebře

Deset dotazů je třeba formulovat v relační algebře, později i v SQL. Dotazy v relační algebře musí pokrývat kategorie A, B, C a D v Tabulce kategorií dotazů. Nezapomeňte, že relační algebra je matematický formalismus s menší vyjadřovací možností než SQL a ne všechny SQL příkazy dokážeme zadat také v relační algebře v RA např. chybí funkce, ať už skalární, či agregační.
Dotazy musí vyhovovat výše uvedeným obecným požadavkům. U dotazů, které máte pokryty i v RA je užitečné formulovat je v SQL v jiné podobě, než vnikla překladem výrazu RA do SQL. Nicméně, toleruje se to, když použijete stejnou podobu, ale nelze čekat, že práce bude hodnocena jako kvalitní, která si zaslouží bonifikaci.

SQL příkazy

Tato část je ze všech nejpracnější. Očekává se od vás aspoň 25 odladěných a smysluplných SQL příkazů. Příkazy musí splňovat výše uvedená obecná pravidla.

  • příkazy musí být rozmanité – pokrývat všechny řádky předepsané Tabulky kategorií dotazů (jeden příkaz může pokrývat více kategorií současně),
  • u složitých dotazů proveďte raději kontrolu výsledku inverzním dotazem.

Forma

Oproti předchozím běhům bude práce povinně odevzdávána přes portál http://dbs.fit.cvut.cz. Cílem je ještě více usnadnit odevzdání, kontrolu a zpětnou vazbu jednotlivých částí vaší semestrálky.

Níže odkazovaný příklad je exportem hotové semestrálky do formátu XML, zobrazitelný ve WWW prohlížeči.

Ukázka hotové semestrální práce

 
/mnt/www/courses/BI-DBS/data/pages/project/start.txt · Poslední úprava: 2018/04/14 14:53 autor: kovarpa7
 
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki