Databázové systémy I. 3. přednáška

Transkript

1 Databázové systémy I. 3. přednáška

2 Co nás dnes čeká Procvičení datového modelování Převod z logického do fyzického modelu

3 Co víme z minule Co je to entita a jaké má vlastnosti? Co je to vztah a jaké má vlastnosti? Co je to integritní omezení a k čemu je to dobré? K čemu slouží maticový diagram? Proč a jak používáme ERDish? Kdy použít supertyp a subtyp? Co je to oblouková vazba?

4 Normální formy Množina pravidel pro správnou strukturu datového modelu Proces takové úpravy = normalizace Snahou je omezit nadbytečnost (redundanci) a závislosti, což usnadňuje např. modifikaci dat Obvykle je databáze normalizovaná do 3. normální formy

5 1. normální forma Všem atributům jsou jako jejich domény přiřazeny pouze atomické (nedělitelné) typy, neopakují se atributy stejného typu

6 neatomický atribut BUDOVA # kód * jméno * adresa o místnosti BUDOVA # kód * jméno * adresa obsahuje je umístěna MÍSTNOST # číslo * podlaží * velikost

7 opakující se atribut STUDENT # id * jméno * příjmení o předmět1 o předmět2 o předmět3 STUDENT # id * jméno * příjmení studuje je studován PŘEDMĚT # kód * název

8 2. normální forma Pro splnění 2NF musí být schéma v 1NF Schéma nesmí obsahovat žádné částečné závislosti neklíčových atributů na klíči (každá neklíčová hodnota musí záviset na celém klíči) Zavedením jednoduchých klíčů a splněním 1NF lze jednoduše dosáhnout 2NF

9 název_banky závisí pouze na kódu banky a ne na čísla účtu ÚČET # číslo # kód_banky * založeno * částka * název_banky BANKA # kód_banky * adresa spravuje je spravován ÚČET # číslo * otevřeno * částka

10 3. normální forma Pro splnění 3NF musí být schéma v 2NF Dále nesmí být žádný neklíčový atribut tranzitivně závislý na žádném klíči schématu (nesmí záviset na jiném neklíčovém atributu) Pro zavedení 3NF se často vytvoří různé číselníky

11 adresa skladu a telefon skladu závisí na atributu kód skladu a ne na klíčí (číslo objednávky) OBJEDNÁVKA # číslo * datum * částka * kód skladu * adresa skladu * telefon skladu OBJEDNÁVKA # číslo * datum * částka vyřízena z vyřizuje SKLAD # kód skladu * adresa skladu * telefon skladu

12 Podniková pravidla Co je cílem konceptuálního modelování? Uchování a poskytování informací Ve schématech uchováváme také IO Pro správné schéma databáze je nutné pokrýt i podniková pravidla Strukturální, popisují, jaká má být struktura uložených informací Procedurální souvisí se zpracováním dat, často spojené s časem

13 Zkuste navrhnout Procedurální podnikové pravidlo A strukturální?

14 Podniková pravidla Strukturované uvádějí typy informací, jež je možno pro daný atribut uchovávat (jen čísla, časové údaje od , primární klíč z jiné tabulky,...) Procedurální jedná se o pracovní postupy související s provozem systému (sumační údaje z prodeje se ukládají vždy prvního v každém měsíci) Strukturální podniková pravidla je možné téměř vždy možné zanést do ERD. Některá z procedurálních podnikových pravidel nelze do diagramu zaznamenat, ale i tak musí být zdokumentována.

15 Modelování historických dat Kdy musíme počítat s historií? Budou data auditována? Podléhají data času? Musíme udržovat vývoj v čase a jak dlouho? Co když budeme chtít sledovat výplaty zaměstnanců?

16 Půjčovna Jak namodelujme půjčovnu šperků?

17 Půjčovna Jak namodelujme půjčovnu šperků?

18 Modelování času Kdy použijeme datový typ DATE a den jako entitu? co je nové entitě špatně? Nápověda 3NF

19 Omezení související s časem

20 Modelování vývoje ceny Nejen cen, ale také vývojových ukazatelů Zavedeme si tzv. historickou entitu Co si uvědomit Z Bc. na Ing., co je dobré vědět? Sleva u obchodních aplikacích jako e-shop Kam sledování ceny zařadíme? A co když zákazník vrací zboží?

21 Přenesená závislost Jaké atributy sledovat? Čas u prodeje Čas platné ceny

22 Žurnálování Opomíjené při návrhu schématu databáze Používáme vždy, když uživatelé mají umožněno zásadně měnit data aplikace. Vytváření logu/žurnálu Uchováváme předchozí hodnotu, ale také kdo změnu provedl

23 Jsme gymnázium sídlící v České republice. Našim cílem je zjednodušit komunikaci s rodiči. Chtěli bychom tedy pro naše potřeby vytvořit interní informační systém, kam by měli přístup jak zaměstnanci a studenti, tak jejich rodiče. Na našem gymnáziu je možné studovat buď čtyřleté, šestileté a osmileté všeobecně zaměřené studium. Pro čtyřleté a šestileté vypisujeme také studium se zaměřením na programování. Každý rok tak přijímáme pět nových tříd a pět tříd vždy ukončí své studium maturitou.

24 Pro každý ročník daného studia je vždy konkrétní studijní plán obsahující předepsané předměty, které je nutno odstudovat, aby student mohl postoupit do dalšího ročníku. Všichni studenti mají povinně anglický jazyk a k němu volí druhý cizí jazyk. Aby byl jazyk vypsán, je potřeba minimálně patnácti studentů v daném ročníku. Ve vyšších ročnících pak mohou studenti vybírat z volitelných předmětů, kde platí stejná podmínka jako pro otevření jazyků. Výběr volitelného předmětu by měl probíhat prostřednictvím informačního systému.

25 Rozvrh vyučovaných hodin je určen vždy pro třídu jako celek. V případě, že se třída dělí (jazyky, volitelné předměty, tělesná výchova) mají studenti rozvrh na základě toho, do jaké skupiny patří. Z rozvrhu musí být jasné, kdo předmět vyučuje a v které učebně výuka probíhá. Protože máme speciální laboratoře určené pro specifické předměty, bylo by vhodné pro automatické generování rozvrhu uchovávat informace o tom, jaké předměty v dané učebně mohou být vyučovány.

26 Do systému musejí mít přístup všichni zaměstnanci. O zaměstnancích uchováváme osobní informace, jako jméno, bydliště rodné číslo, bankovní spojení apod. Zaměstnanci mohou mít různé profese. Vyučovat mohou pouze pedagogové. Každý pedagog může vyučovat jen předměty, na které má aprobaci. U pracovníků se eviduje jejich docházka, v případě, že se pedagog nemůže dostavit, je zapotřebí, aby bylo zajištěno suplování.

27 Uživateli systému jsou také studenti a jejich zákonní zástupci. O nich se uchovávají různé informace. Chtěli bychom, aby systém umožňoval elektronické vedení třídních knih. Je tedy potřeba evidovat docházku studentů, a co bylo na konkrétní hodině vyučováno. Současně chceme, aby bylo možné uchovávat známky z jednotlivých předmětů. Každý rok sestává ze dvou pololetí a v každém pololetí musí student v každém předmětu klasifikován známkou. Do systému se zanášejí i údaje o chování studentů jakou jsou pochvaly, poznámky či napomenutí. Ke všem údajům týkajícím se konkrétního studenta musí mít přístup jeho zákonní zástupci.

28 Data definition language Datový slovník Vytváření, úprava a rušení nových objektů v datovém slovníku Objekty v datovém slovníku: tabulky, indexy, omezení, pohledy, sekvence, synonyma Obvykle se provádí rozdělení databáze na jednotlivá schémata (sessions), přičemž každé má svůj datový slovník RDBMS mají datový slovník přístupný jako zvláštní datového schéma

29 Tabulka - opakování V tabulce EMLPOYES jsou uchována data o zákaznících. Každý sloupec je použit pro uložení specifického typu hodnot.

30 Převod ERD do fyzického modelu Konceptuální model (ER diagram) je převeden do fyzického modelu. Fyzický model bude implementován relační databází.

31 Změna terminologie Převod z konceptuálního modelu na fyzický s sebou přináší i změnu terminologie: Konceptuální entita instance atribut primární identifikátor sekundární identifikátor vztah Fyzický tabulka řádek sloupec primární klíč unikátní klíč cizí klíč

32 Notace zápisu tabulek První řádek obsahuje jméno tabulky Samotná tabulka popisující tabulku obsahuje tři sloupce: typ klíče (pk, uk, fk), povinnost (*, o) a název sloupce. Pro jména tabulek se užívají množná čísla. Jména sloupců zůstávají zachována kromě speciálních znaků (diakritiky). Mezery jsou nahrazeny podtržítkem.

33 Mapování vazeb Vztah vytváří cizí klíč, který musí být zanesen do jednoho nebo i více sloupečků tabulky. V závislosti na povinnosti vztahu je pak dáno, můželi odpovídající sloupec nabývat hodnotu NULL.

34 Problémy při převodu Povinnost vazby se v rámci relační databáze dá vynutit pouze na jedné straně vazby (té, která se promítne jako nový sloupec). Nepřevoditelnou vazbu v relační databázi také nelze zachytit. Je potřeba použít nadstavbu v podobě dodatečného programování. Tyto skutečnosti je vždy vhodné zanést do dokumentace.

35 Mapování vazeb N:M

36 Mapování oblouků Při tomto mapování je nezbytné ohlídat, aby byl cizí klíč právě v jednom z odpovídajících sloupců. CHECK (pse_id IS NOT NULL AND phe_id IS NULL) OR (pse_id IS NULL AND phe_id IS NOT NULL)

37 Mapování supertypů a subtypů jedna tabulka Vytváří se vždy pouze jedna tabulka nezávisle na počtu subtypů. Tabulka bude obsahovat všechny sloupce odpovídající atributům supertypu s deklarovanými povinnostmi. Do tabulky budou zahrnuty také sloupce patřící jednotlivým subtypům. Tyto sloupce budou nepovinné. K těmto sloupcům se pak přidá ještě jeden, který bude povinný a bude specifikovat, o jaký subtyp se jedná.

38 Jedna tabulka pokračování Je potřeba se ujistit, aby docházelo ke vkládání odpovídajících hodnot daným subtypům pomoci omezení CHECK.

39 Kdy použít jednu tabulku? Použití jedné tabulky je běžná a flexibilní implementace. Je vhodné ji použít především když: Většina atributů je společných (nachází se v supertypu). Většina vazeb je na úrovni supertypu. Podniková pravidla jsou globálně aplikovatelné na subtypy.

40 Mapování supertypů a subtypů dvě tabulky Vytváří se tabulka pro každý subtyp. Ve skutečnosti tak může vzniknout tabulek více. Všechny tabulky budou obsahovat sloupce odpovídající atributům supertypu a k tomu sloupce odpovídající atributům daného subtypu. Povinnost zůstane zachována podle ERD. Stejným způsobem se pak mapují i vztahy mezi entitami do cizích klíčů

41 Dvě tabulky pokračování

42 Kdy použít dvě tabulky? Subtypy mají pouze málo společného. Vyskytuje se málo atributů v supertypu a více v subtypech. Většina vztahů je na úrovni subtypů. Podniková pravidla se mezi subtypy výrazněji liší.

43 Mapování supertypů a subtypů oblouk Muže dojít k úpravě ERD a následně se postupuje jako by se jednalo o obloukovou vazbu.

44 Tabulky (tables) Představují relace. Vertikálně se dělí na řádky (instance). Horizontálně se dělí na sloupce (atributy). Platí zde všechna pravidla o relacích a normálních formách zmíněná dříve (zejména definice domény, integritní omezení, klíče, atomičnost atd.) jedná se o jednorozměrný Excel

45 Jak na tabulku v SQL CREATE TABLE jméno (relace) Relace je představována popisem atributů a integritních omezení navzájem oddělených čárkou Popis atributu: jméno typ [impl. hod.] [omezení] Implicitní hodnota je definovatelná pomocí fráze DEFAULT hodnota

46 CREATE TABLE příklad table název tabulky column název sloupce datatype datový typ sloupce (délka) DEFAULT expression specifikuje hodnotu, která bude vložena v případě, kdy je při vkládání tento sloupec vynechán

47 Vytvoření tabulky na základě poddotazu Další možností je vytvořit tabulku na základě poddotazu. Tímto způsobem je vytvořena tabulka a rovnou naplněna odpovídajícími daty.

48 Jak pojmenovat tabulky Základní pravidla pro pojmenovaní tabulek pro Oracle lze shrnout na: Začínají písmenem Název musí mít mezi 1 a 30 znaky Obsahují pouze znaky A-Z, a-z, 0-9, _, $ a # Nesmí mít stejný název jako jiný objekt vlastněný stejným uživatelem Nesmí být tvořeno vyhrazenými klíčovými slovy Názvy nejsou Case-Sensitive Volte popisná jména

49 Základní datové typy V jednotlivých DB systémech mohou být rozdíly v názvech. Zde uvedené platí pro dbs Oracle. Znakové typy: CHAR(n), VARCHAR2(n) Číselné typy: NUMBER(prec, scale), INT, DECIMAL, FLOAT, REAL, SMALLINT Typ datum a čas: DATE Velké objekty: LONG, LONG RAW, RAW(n) Rozsáhlé objekty: BLOB, CLOB, BFILE Vlastní definované typy Tabulkové a objektové typy

50 Definice integritního omezení Základní omezení označuje možnost existence nedefinovaného stavu atributu (NULL, NOT NULL), implicitně je NULL Další omezení lze zavést jako doplňující podmínku k doméně CHECK (podmínka) Každému atributu lze definovat klíč (primární PRIMARY KEY, unikátní UNIQUE nebo cizí klíč REFERENCES) Pojmenované omez. CONSTRAINT jméno

51 Vícesloupcová integrita Představuje integritní omezení definované jako atribut relace Může být definována jako primární klíč PRIMARY KEY(sloupce), unikátní klíč UNIQUE(sloupce), podmínku CHECK(podmínka) nebo jako cizí klíč FOREIGN KEY(sloupce) REFERENCES Zápis cizího klíče je REFERENCES tabulka(sloupce) [ON DELETE CASCADE SET NULL]

52 Příklad

53 ALTER TABLE Pomocí této klauzule je možné: přidat nový sloupec modifikovat stávající sloupec definovat výchozí hodnotu sloupce odstranit sloupec Nelze: nastavit, kde se sloupec zařadí. Nově zařazený sloupec se přidá vždy na konec nastavit nový sloupec jako nenulový, pokud se v tabulce již vyskytují nějaké řádky

54 Přidání sloupce ALTER TABLE nazev_tabulky ADD (nazev_sloupce datovy_typ [DEFAULT výraz], nazev_sloupce datovy_typ [DEFAULT výraz], )

55 Úprava sloupce Umožňuje rozšířit délku či přesnost číselného typu zvýšit maximální délku u řetězcových typů snížit maximální délku lze v závislosti na uchovaných datech. Pokud tabulka již obsahuje nějaké záznamy, není možné upravit datové typy tak, aby je existující záznamy nesplňovaly. změnit datový typ v případě, že ve sloupci nejsou jiné hodnoty než NULL Změna výchozí hodnoty ovlivní jen nově vkládané záznamy. ALTER TABLE nazev_tabulky MODIFY (nazev_sloupce datovy_typ)

56 Odstranění sloupce Lze mazat sloupce s hodnotami i bez nich. Během jedné operace lze odstranit jen jeden sloupec. V tabulce vždy musí zůstat alespoň jeden sloupec. Jakmile se sloupec odstraní nelze získat odstraněná data. ALTER TABLE nazev_tabulky DROP COLUMN nazev_sloupce;

57 Přidání omezení ALTER TABLE nazev_tabulky ADD CONSTRAINT nazev_omezeni typ_omezeni(sloupec); Typy omezení PRIMARY KEY, FOREING KEY, CHECK Pro NOT NULL je potřeba použít ALTER TABLE nazev_tabulky MODIFY (nazev_sloupce CONSTRAINT nazev_omezeni NOT NULL)

58 Úprava tabulky Přejmenování: RENAME stary_nazev TO novy_nazev Odstranění DROP nazev_tabulky Vyprázdnění tabulky a uvolnění prostoru TRUNCATE nazev_tabulky Vyprázdnění tabulky bez uvolnění prostoru DELETE nazev_tabulky