Databázové systémy I. 3. přednáška
Co nás dnes čeká Procvičení datového
modelování Převod z logického do fyzického modelu
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?
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
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
neatomický atribut
BUDOVA # kód * jméno * adresa
BUDOVA # kód * jméno * adresa o místnosti
obsahuje je umístěna
MÍSTNOST # číslo * podlaží * velikost
opakující se atribut
STUDENT # id * jméno * příjmení
STUDENT # id * jméno * příjmení o předmět1 o předmět2 o předmět3
studuje je studován
PŘEDMĚT # kód * název
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
název_banky závisí pouze na kódu banky a ne na čísla účtu
BANKA # kód_banky * adresa
ÚČET # číslo # kód_banky * založeno * částka * název_banky
je spravován spravuje
ÚČET # číslo * otevřeno * částka
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
adresa skladu a telefon skladu závisí na atributu kód skladu a ne na klíčí (číslo objednávky)
OBJEDNÁVKA # číslo * datum * částka
OBJEDNÁVKA # číslo * datum * částka * kód skladu * adresa skladu * telefon skladu
vyřizuje vyřízena z
SKLAD # kód skladu * adresa skladu * telefon skladu
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
Zkuste navrhnout • •
Procedurální podnikové pravidlo A strukturální?
Podniková pravidla Strukturované – uvádějí
typy informací, jež je možno pro daný atribut uchovávat (jen čísla, časové údaje od 2. 1. 2012, 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.
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
zaměstnanců?
výplaty
Půjčovna Jak namodelujme půjčovnu
šperků?
Půjčovna Jak namodelujme půjčovnu
šperků?
Modelování času Kdy použijeme datový
co je nové
typ DATE a den jako entitu?
entitě špatně? Nápověda 3NF
Omezení související s časem
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ží?
Přenesená závislost Jaké atributy sledovat?
Čas u prodeje Čas platné ceny
Ž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
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.
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.
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.
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í.
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.
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
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.
Převod ERD do fyzického modelu Konceptuální model (ER diagram) je převeden
fyzického modelu. Fyzický model bude implementován relační databází.
do
Změna terminologie Převod
z konceptuálního modelu na fyzický s sebou přináší i změnu terminologie: Konceptuální
Fyzický
entita
tabulka
instance
řádek
atribut
sloupec
primární identifikátor
primární klíč
sekundární identifikátor
unikátní klíč
vztah
cizí klíč
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.
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.
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.
Mapování vazeb N:M
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)
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á.
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.
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.
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íčů
Dvě tabulky – pokračování
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ší.
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.
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“
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
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
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.
Jak pojmenovat tabulky Základní pravidla pro pojmenovaní
Oracle lze shrnout na:
tabulek pro
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
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
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
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]
Příklad
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
Přidání sloupce ALTER TABLE nazev_tabulky ADD (nazev_sloupce datovy_typ [DEFAULT výraz], nazev_sloupce datovy_typ [DEFAULT výraz], … )
Ú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)
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;
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)
Ú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í
DELETE nazev_tabulky
prostoru
