Úvod do databázových systémů Cvičení 04 Ing. Pavel Bednář pavel.bednar.st1@vsb.cz

Opakování Entita Typ Entity Libovolná existující osoba, zvíře, věc či jev (obecně objekt) reálného světa. Entita musí být rozlišitelná od ostatních entit a existovat nezávisle na nich. Typ Entity Množina objektů stejného typu, charakterizovaných názvem typu a popsaných pomocí jejich vlastností - atributů. Jednotlivé entity nazýváme také výskyty nebo instancemi objektů entitního typu.

Vztahová entita Co zaznamenává ? Jaké jsou její atributy -Obyčejná entita popisuje některý objekt -Vztahová entita popisuje vztah mezi entitami Jaké jsou její atributy -Její atributy jsou typy entit, mezi kterými popisuje vztah Instance vztahu jsou pak konkrétní dvojice či n-tice entit vstupujících do vztahu Zaznamenává vztahy mezi entitami Obyčejná entita popisuje některý objekt Vztahová entita popisuje vztah mezi objekty Typ entity pojmenujeme názvem vztahu Její atributy jsou typy entit, mezi kterými popisuje vztah Instance vztahu jsou pak konkrétní dvojice či n-tice entit vstupujících do vztahu

Vztahová entita Příklad 1 Příklad 2 Typ vztahové entity – UČÍ (UČITEL, PŘEDMĚT) Instance vztahu – (Radoslav Fasuga, UDBS) Příklad 2 Entity: MUŽI, ŽENY Vztah – MANŽELSTVÍ (MUŽI, ŽENY) Další atributy vztahy – datum svatby, …

ER Diagram Jak se určuje kardinalita vztahu Určuje se dvěma větami Př. „Jeden učitel učí jeden nebo více předmětů“ (1:N) „Jeden předmět může mít jednoho nebo více učitelů“ (1:M)

ER Diagram Do některých vztahů musí vstupovat každá entita množiny entit, do jiného vztahu ne. Jaké existují povinnosti členství povinné (obligatorní) nepovinné (fakultativní) Jak se určuje povinnost členství Př. „Firma může, ale nemusí vyrábět výrobek“ ( o ) „Výrobek musí mít firmu“ (  ) Kolečko uvnitř obdélníku na straně entitního typu vyznačuje povinné členství ve vztahu. Obligatorní členství ve vztahu je velmi důležité IO. Vyjadřuje, že instance jednoho entitního typu nemůže existovat bez zapojení do vztahu s instancí druhého entitního typu. Často se pro toto integritní omezení používá pojem existenční závislost. Entitní typ, který má obligatorní členství ve vztahu, je existenčně závislý na jiném entitním typu.

Příklad – Vydavatel kuchařek V knihkupectví specializujícím se na prodej kuchařských knih potřebují vytvořit systém pro evidenci. Chtějí evidovat jednotlivá vydavatelství, vydané kuchařské knihy, recepty a použité suroviny. Obecně platí, že recept může být otištěn ve více knihách.

Příklad – Vydavatel kuchařek Entitní typy Vydavatelstvi (id_vydavatel, nazev, adresa, telefon) Kucharka (id_kucharka, nazev, id_vydavatelstvi) Recept (id_recept, nazev,postup) Surovina (id_surovina, nazev) Vztahy mezi entitními typy Vydáva (Vydavatelstvi,Kucharka) 1:N Obsahuje (Kucharka, Recept) M:N SeSkládá (Recept, Surovina) M:N

Příklad – Vydavatel kuchařek Kuchařka Recept M N Obsahuje N M Vydává SeSkládá 1 N Kardinalita Jedno vydavatelství může vydávat více kuchařek. Jedna Kuchařka musí mít jedno vydavatelství. Kuchařka může obsahovat více receptů. Jeden recept může být ve více kuchařkách. Recept se může skládat z více surovina. Jedna surovina může být použita ve více receptech. Povinnost členství Vydavatelství nemusí vydat žádnou kuchařku. Kuchařka musí mít vydavatelství. Kuchařka musí mít recept. Recept nemusí být v kuchařce. Recept musí být složen ze surovin. Surovina nemusí být použita v receptu. Vydavatelství Surovina

Příklad – Vydavatel kuchařek Entitní typy Vydavatelstvi (id_vydavatel, nazev, adresa, telefon) Kucharka (id_kucharka, nazev, id_vydavatelstvi) Recept (id_recept, nazev,postup) Surovina (id_surovina, nazev) ReceptKucharky (id_kucharka, id_recept) SurovinaReceptu (id_recept, id_surovina, mnozstvi) Vztahy mezi entitními typy Vydáva (Vydavatelstvi,Kucharka) 1:N Obsahuje1 (Kucharka, ReceptKucharky) 1:N Obsahuje2 (ReceptKucharky, Recept) N:1 SeSkládá1 (Recept, SurovinaReceptu ) 1:N SeSkládá2 (SurovinaReceptu, Recept ) N:1

Kuchařka Recept Recept Kuchařky 1 N N 1 N 1 1 N SurovinaReceptu N 1 Vydavatelství SurovinaReceptu Kardinalita Jedno vydavatelství může vydávat více kuchařek. Jedna Kuchařka musí mít jedno vydavatelství. Kuchařka má několik záznamů v ReceptKuchařky Jeden záznam ReceptKuchařky je pro jednu kuchařku. Recept má několik záznamů v ReceptKuchařky. Jeden záznam ReceptKuchařky je pro jeden recept Recept může obsahovat několik záznamů v SurovinaReceptu. Jeden záznam v SurovinaReceptu je pro jeden recept. Surovina může obsahovat několik záznamů v SurovinaReceptu. Jeden záznam v SurovinaReceptu je pro jednu surovinu. Povinnost členství Vydavatelství nemusí vydat kuchařku Kuchařka musí mít vydavatelství Kuchařka musí mít alespoň jeden záznam v ReceptKuchařky. Jeden záznam v ReceptKuchařky musí být přiřazen ke Kuchařce. Recept nemusí mít záznan v ReceptKuchařky Jeden záznam v ReceptKuchařky musí být přiřazen k receptu. Recept musí mít záznam v SurovinaReceptu (musí mít surovinu) SurovinaReceptu musí mít recept. Surovina nemusí být použiva v SurovinaReceptu. SurovinaReceptu musí být přiřazena k surovině. N 1 Surovina

Příklad – Dostihové závody Dostihová komise rozhodla o vybudování informačního systémů pro jednotlivé stáje, koně, dostihy a výsledky dostihů. Informační systém obsahoval informace o stájích, obsahoval registrační číslo stáje(unikátní pro každou stáj), majitele, adresa – město, ulice, PSČ/ZIP, země. Každá stáj musí mít minimálně jednoho koně. U koňů se evidovalo jejich číslo (jednoznačné v rámci jedné stáje v různých stájích mohou mít koně stejná čísla), jméno koně, stáří, zaměření (zaměření koně nemusí být vyplněno), pohlaví. Každý kůň patří právě jedné stáji. Další součástí evidence byl seznam absolvovaných závodů (těch které již proběhly). Závod je určen číslem závodu (jednoznačné číslo v rámci jedné sezony = jednoho roku), rokem konání, názvem závodu, dotací na závod. V každém závodu misí být minimálně jeden kůň, ale někteří koně dosud nestartovali v žádném závodě. Pro každý závod můžeme sledovat seznam všech koňí, kteří se závodu zúčastnili, i těch kteří nedokončili, u každého koně sledujeme startovní číslo v závodě a konečné umístění pro každého koně. Neuvažujeme dělená místa.

Příklad – Půjčovna DVD Půjčovna DVD se rozhodla vybudovat informační systém o půjčených discích bez možnosti rezervace. U jednotlivých disků se evidovalo číslo titulu (jednoznačně v rámci půjčovny), jméno filmu česky, jméno filmu anglicky (nemusí existovat), délka v minutách, jazyk audio, jazyk titulky. Dále se evidovaly jednotlivé exempláře daného filmu, protože půjčovna mohla mít více disků od stejného titulu. U exemplářů se evidovalo pořadové číslo, datum pořízení, datum vyřazení( které bylo prázdné pokud se titul nevyřadil.). Mohla nastat situace, že k filmu nebyl žádný exemplář (poškozen, připravovaný titul, atd.). Dále se evidoval seznam členů videopůjčovny číslem člena (jednoznačné pro každého člena v rámci videopůjčovny), jméno, příjmení, adresa – město, ulice, PSČ, telefon. Stěžejní operací bylo ukládání informací o vypůjčených titulech, kde se ukládaly informace o půjčeném titulu, který člen si jej půjčil, datum půjčení a vrácení. Při půjčení se evidovalo, který exemplář si člen půjčil, tak aby se dalo následně sledovat kdo konkrétní exemplář titulu poškodil. Stejný exemplář si člen může půjčit víckrát. Člen si nemusí půjčit žádny exemplář a nový exemplář nemusí být dosud vypůjčen.

Sledování historických dat Údaje o entitě se mohou v průběhu času měnit. Potřeba přistupovat k historickým údajům Příklad Zákazník si vytvoří objednávku, ale cena produktů, které si objednal se změní. Zákazník změní adresu bydliště. Je potřeba uložit informace, které se mohou časem změnit.

Sledování historických dat -V tabulce Objednávka replikujeme údaje o zákazníkovi, protože kontaktní informace se můžou v průběhu času změnit. -Totéž v tabulce Polozka_Objednavka, kde duplikujeme cenu z produktu, protože i ta se v průběhu času mění, pokud bychom tuto hodnotu neukládali, pak bychom měnili cenu i u již dříve vydaných objednávek.

Redundance a předpočítaná data Někdy je výhodné použít rendundantní data Je ale třeba zabezpečit aby odpovídali skutečnosti a zabezpečit, že se hodnoto předpočítaného atributu, přepočítá vždy když má. (transakce) Ušetření výpočetního výkonu a rychlosti vykonávání dotazu.

Redundance a předpočítaná data - Průměrná cena produktu se počítá jako průměrná cena z přijatého zboží, musel bych pro každé zjištění ceny produktu musel vypočítávat průměrnou cenu nad všemi záznamy produktu v tabulce „Prijem_sklad“, proto je výhodnější uložit si předpočítánou hodnotu. - Stejně tak je výhodné předpočítat si o počet kusů skladem.

Rozklad multiatributů Multiatribut je takový atribut, který jde rozložit na více částí. Atomický atribut je takový, který již není dále dělitelný. Příklad Adresa – jde rozložit na město, ulice, číslo popisné, psč Firma – jde rozložit na název společnosti a typ (s.r.o., a.s.) Zákazník – jde rozložit na titul, jméno, příjmení

Rozklad multiatributů Příkladem multiatributu může být i pole hodnot. (Například plat zaměstnance) Řešení Tabulka bude obsahovat tolik sloupečků, kolik platů chceme historicky evidovat. Vznikne nová tabulka, kde jeden plat bude jeden řádek.

Rozklad multiatributů Tabulka bude obsahovat tolik sloupečků, kolik platů chceme historicky evidovat.

Rozklad multiatributů Vznikne nová tabulka, kde jeden plat bude jeden řádek.

Příklad Přepravní společnost. Firma(id_firma, město, ulice, čp, psč) Kamion(spz, objem, nosnost, spotřeba) – můžeme přidat předpočítáný atribut náklady/km Preprava (id_preprava, id_firma_odkud, id_firma_kam, počet km, cena) – je nutno překopírovat informace o městě, ulici …. Tankování (id_tankovani, spz, datum, počet_litru, cena_litr)

Příklad pro generický návrh Máme databázi e-shopu Chceme evidovat různé informace o různých produktech

Každý produkt má svou tabulku Vyhledávání obecných (společných) informací (název, popis) se provádí pro každou tabulku zvlášť Specifické atributy jsou uloženy vždy pro každý produkt zvlášť Neefektivní, jelikož při změně nebo rozšíření produktové řady, je nutné měnit nebo přidávat datové struktury

Každý produkt má svou tabulku

Společná tabulka + specializace Společné atributy v tabulce produkt (tedy vyhledávání nad jedinou tabulkou) Specifické vlastnosti uloženy ve vlastní struktuře Opět závislost datových struktur a obsahu Tedy je nutné doplňovat tabulky se specifickými vlastnostmi Je zde však možné přidat nový produkt (jiný) bez specifických vlastností

Společná tabulka + specializace

Všechny vlastnosti u produktu Jedna tabulka společná pro všechny produkty Všechny specifické vlastnosti jsou uloženy v jedné tabulce Pro daný produkt se vyplní pouze ty vlastnosti, které mají význam Pro různé druhy produktů existuje mnoho rozdílných vlastností V tabulce bude existovat mnoho popisných atributů, z nichž jen část bude reálně vyplněna

Všechny vlastnosti u produktu

Generický design Každou vlastnost uložím jako řádek ve vazební tabulce. Mohu přidávat nové vlastnosti, aniž by se musela měnit strukturu databáze Náročnější na tvorbu

Generický design Produkt Vlastnost M N Popisuje N M Obsahuje N 1 JeZařazen Kategorie N Je Podkategorie

Příklad – Úspora na telefon Majitel firmy zjistil, že utrácí velké prostředky za mobilní telefony a rozhodl se tuto problematiku řešit. Sestavil seznam čísel, na které jeho zaměstnanci mohou telefonovat z určitého mobilního telefonu a ostatní nechal zablokovat. Každý mobil má svého vlastníka (zaměstnance). V seznamu se může vyskytnou číslo na které nesmí aktuálně volat žádný zaměstnanec. Každý zaměstnanec má stejný seznam povolených čísel. V seznamu bylo uvedeno číslo, majitel čísla a cenový tarif. Dále vytvořil seznam vlastních mobilních telefonních čísel, kde bylo uvedeno číslo telefonu, operator, osobní číslo zaměstnance. Jeden zaměstnanec nemohl vlastnit více mobilních čísel a dokonce nemusel vlastnit žádný firemní mobil. Z nového mobil nemuselo být ještě telefonováno. V evidenci zaměstnanců bylo uvedeno osobní číslo zaměstnance (jednoznačné v rámci firmy), jméno, příjmení, pozice ve firmě (pozice nemusí být vyplněna). Dále se eviduje, kdy který mobil volal, na některé z povolených čísel. Sleduje se datum a čas volání, číslo mobilního telefonu, cílové číslo, délka hovoru, cena.