3 pohledy na data • Vnější pohled – aplikační úroveň • Konceptuální schéma – logika modelu • Fyzické schéma – vlastní uložení dat
Konceptuální model modeluje funkční a informační potřeby podniku je založený na současných potřebách a může zohledňovat potřeby budoucí nezabývá se implementačními problémy bývá nazýván jako entitně relační model a je zobrazován entitně relačním diagramem • je nezávislý na modelu databáze (hierarchický, síťový, relační) Proč se využívá konceptuální model? • předně popisuje informační potřeby podniku • vyvolává a usnadňuje diskusi • odstraňuje chyby a nedorozumění • slouží pro dokumentaci • je východiskem pro tvorbu fyzického modelu • dokumentuje podnikové procesy (podnikové pravidla „business rules“) • • • •
Entitně relační model • seznam všech objektů (entit) a atributy, stejně jako všechny vztahů mezi entitami, které jsou důležité • poskytuje podkladové informace, jako je popis entit, datových typů a omezení cíle ERM • zachytit všechny potřebné informace • zajistit, aby se konkrétní informace objevila právě jednou • neuchovávat informace, které jsou odvoditelné z již uchovaných (pokud k tomu není důvod) • ukládat na logických a předvídatelných místech
Entitě relační diagram vzniká formalizací slovní (datové) analýzy do vybrané notace; vzniká tak datový model – schéma databáze • Entity • představují uchovávané informace zaznamenané podle skutečnosti; • reprezentují objekty reálného světa - fyzicky existující i abstraktní (umělé) • „něco“ významného pro podnik, o čemž musíme znát data • Entita je jméno pro množinu podobných „věcí“; pro entity se používají podstatná jména • mají instance • jsou charakterizovány svými atributy • do ERD je zanášíme jako obdélníky
Supertyp a subtyp II Supertypy a subtypy se často vyskytují v reálném světě. Nejlépe se to dá demonstrovat na příkladech: Taška – igelitová, papírová, textilní uživatel školního IS – student, učitel, technický pracovník, ... Rozhodnete-li se používat supertypy a subtypy je vhodné použít tři otázky, zda jste subtypy správně identifikovali: 1. Je subtyp druhem supertypu? 2. Jsou pokryty všechny možné případy? (Je seznam subtypů vyčerpávající?) 3. Spadá jakákoliv instance dané entity vždy právě do jednoho subtypu? (Jsou subtypy vzájemně se vylučující?)
Supertyp a subtyp II
V některých případech mohou být subtypy „vhnízděné“. V praxi se doporučuje používat maximálně dvě úrovně. Obratlovci jsou pak subtypem zvířat a zároveň supertypem pro plazi, savce, ptáky a ostatní obratlovce. Dále je důležité rozlišovat jedná-li se subtyp nebo o instanci.
Instance • je konkrétní výskyt entity; • Jak poznáte, jedná-li se o entitu nebo instanci? • Je pes entita nebo instance? Příklad: Z následujícího seznamu rozhodněte, zda se jedná o entitu či instanci a přiřaďte instanci ke správné entitě: • fakulta, dolar, hračka, nábytek, auto, předmět, Škoda Fabia, osoba, ovoce, hokej, měna, skříň, jablko, sport, databázové systém I, autíčko na dálkové ovládání, František Smutný, PEF řešení: entita, instance; hračka, autíčko na dálkové ovládání; nábytek, skříň; auto, Škoda Fabia; osoba, František Smutný; ovoce, jablko; sport, hokej; měna, dolar; předmět, databázové systém I; fakulta, PEF
Vztahy mezi entitami - vazby Schopnost identifikovat vztahy mezi entitami umožňuje lépe pochopit spojení mezi jednotlivými kusy dat. To vám pomůže zjistit, jak se jednotlivé části systému vzájemně ovlivňují. Pro správnost vytvářeného modelu jsou relace mezi entitami stejně důležité jako entity samy osobě. Vztahy: •představují něco významného pro podnik; •ukazují, jaké jsou vazby mezi entitami; •vždy existují právě mezi dvěma entitami nebo mezi jednou entitou, která má vazbu sama se sebou; •vždy má dvě strany; •je pojmenovaná na obou stranách; •určuje, je-li vazby povinná či volitelná; •má svoji kardinalitu (násobnost)
Maticový diagram při hledání vazeb mezi entitami je vhodné použít maticový diagram, kde jak sloupce, tak řádky představují jednotlivé entity. Do buněk se pak vpisují slovesa určující název vazby. Příklad: • Pracuji pro cestovní kanceláře. Uchovávám záznam ze zemí, které naši zákazníci navštívili a památek, které zákaznici viděli v každé zemi. Pomáhá nám přizpůsobit nabízené výlety.
Maticový diagram – řešení XXX
zákazník
zákazník země
byla navštívena
památka
byla shlédnuta
země
památka
navštívil
viděl má
se nachází v
Povinnost (volitelnost) • Musí mít každý zaměstnanec pracovní pozici? • Musí být každá pracovní pozice obsazena zaměstnanci?
Kardinalita (násobnost) 1:1
1:N
N:M
• Kolik pracovních pozic může zaměstnanec vykonávat? Právě jednu nebo i více? • Je pracovní pozice určena pouze pro jednoho zaměstnance nebo na ní může působit více zaměstnanců?
Dekompozice vazby M:N
Přenosnost • Je-li na začátku semestru přiřazen skupině studentů vyučující, můžeme zodpovědnost za tuto skupinu přenést na jiného učitele? Většinou ano. Co bychom dělali, kdyby vyučující onemocněl. Když si člověk platí úrazové pojištění, může toto pojištění přesunout na někoho jiného? Když někdo napíše báseň, může být přiřazena jinému autorovi? • To, že se jedná o nepřevoditelnou vazbu, se značí pomocí diamantu.
ERDish
• Při vytváření ERD je u všech relací nezbytné, uvědomit si jejich volitelnost a násobnost, pro usnadnění správně se rozhodnou je vhodné použít slovní zápis (v tzv. ERDish), z kterého pak lze přesně určit typy vazeb. Pro každou vazbu se jedná o dvě věty, které přesně danou vazbu popisují. Jak tvoříme věty pomocí ERDish: 1. Každá 2. entita A 3. povinnost (musí/může) 4. název vztahu (přísudek popisující vazbu) 5. kardinality (právě jeden/jeden nebo více) 6. entita B. • Každý ZEMĚ může mít jednu nebo více PAMÁTEK. • Každá PAMÁTKA se musí nacházet právě j jedné ZEMI.
Atributy • popisují, kvantifikují, kvalifikují, klasifikuji, specifikují entity • mají atomickou hodnotu • hodnotou může být číslo, textový řetězec, datum, obrázek, zvuk atd.; tzn. jsou určitého datového typu • mohou být: * povinné; o volitelné; # unikátní
Atributy – příklad přiřaďte správně atributy entitám. • Entity: zákazník, vozidlo, objednávka, zaměstnání, předměty; • Atributy: celková cena, pozice, jméno, věk, typ motoru, počet kreditů, počet kol, datum vystavení, plat, příjmení, adresa, datum nástupu, výuková místnost, rok výroby, počet položek, přednášející. řešení zákazník – jméno, příjmení, adresa, věk vozidlo – typ motoru, rok výroby, počet kol objednávka – datum vystavení, počet položek, celková cena zaměstnání – pozice, plat, datum nástupu předměty – počet kreditů, výuková místnost, přednášející
Klíče
• Téměř vždy je zapotřebí mít možnost jednoznačně identifikovat každý řádek v tabulce pokud neexistuje přirozený primární klíč (např. rodné číslo), zpravidla se vytváří umělý primární klíč. Primární klíč může být složený i z více atributů (např. entita lístek na koncert může mít primární klíč složený z data a sedadla). • V některých případech se cizí klíč stává součástí primárního klíče. Příkladem může být číslo účtu, kde číslo účtu musí být unikátní vždy v rámci jedné banky, v různých bankách se pak může opakovat. To se v rámci ERD značí pomocí svislé čáry u entity, která „dědí“ primární klíč.
Cizí klíč se atributem stává automaticky, avšak čárka značí, že bude součástí primárního klíče.
Podniková pravidla (business rules) Klíčem pro správnost a úplnost datového modelu je identifikace a dokumentace podnikových pravidel. Je důležité si uvědomit, že ne všechna podniková pravidla mohou být zanesena do ERD. Přesto je potřeba je zaznamenat, aby mohla být implementována. Lze je rozdělit na: • 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ány.
Integritní omezení – strukturovaná podniková pravidla Relační model dat specifikuje strukturu dat v databázi, ale k tomu, abychom mohli používat databázi jako zdroj dat, je nutné zajistit, aby se do ní dostali jen data, která tam patří a neztratila se data, která nemají. K tomu je potřeba mít určité mechanizmy tzv. integritní omezení (IO). Vzhledem k tomu, že k porušení integrity databáze může dojít několika způsoby, rozeznáváme několik druhů integritních omezení. A to: •Entitní Jde o specifikaci primárního klíče tabulky. Primární klíč je atribut, či minimální seznam atributů, které jednoznačně určují ntici (řádek) relace. Minimální ve smyslu, že z ní nelze odebrat žádný atribut, aniž by se ztratila jedinečnost. •Doménové Doménová integrita znamená, že na úrovni sloupců definujeme omezení na určitý datový typ, případně omezení rozsahu hodnot. V databázové hantýrce se tomu celému říká doména atributu. Více viz vaše oblíbená SQL a například CHECK(…) v definici sloupců. •Referenční Referenční integrita (RI) je již mezitabulkovou záležitostí. Definuje vztah dvou tabulek, a to pomocí cizích klíčů (FOREIGN KEY). Cizí klíč v relaci určuje atribut (skupinu atributů), které mají buďto hodnotu NULL, nebo hodnotu primárního klíče některého řádku nadřazené tabulky.
Ošetření IO • Jsou tři způsoby jak zajistit integritu databáze: Deklarativní na serveru • Databázové schéma se do databázového stroje ukládá včetně definice IO. Z hlediska ochrany dat je tento způsob ideální. Má však i své nevýhody při použití IO na straně databáze je uživatel aplikace upozorněn na chybu s určitým zpožděním, což nepřispívá komfortu uživatele. Procedurální na straně klienta • Kontrolní procedury a ochrany jsou na straně klienta. Toto je z hlediska uživatele aplikace nejkomfortnější, neboť aplikace bezprostředně reaguje na vstupy uživatele. Také pro vývojáře aplikací, kteří požadují nezávislost aplikace na databázovém stroji, je tento způsob vhodný. Bohužel i tato metoda má své nevýhody. Procedurální na straně serveru • Kontrolní procedury tvoří samostatné programové moduly uložené a prováděné na serveru. Speciálně pro kontrolu IO jsou v moderních DBMS implementovány TRIGGRY, což jsou procedury, které by se dali přirovnat k událostem z objektového programování.
Postup modelování 1. 2. 3. 4. 5. 6.
Podstatná jména Entity Atributy Maticový digram / ERDish Relace Integritní omezení
Vytvořte ERD pro následující zadání
Začali jsme jako skupina kamarádů, kteří organizovali večírky a přizpůsobovali jsme jim výběr hudby. Jednoho dne jsme se zamysleli a rozhodli se využít toho, co nás baví, k vydělávání peněz. Sami si říkáme „DJové na zakázku.“ Každý, kdo tady pracuje, je partner. Každý partner má svoji specifickou zodpovědnost. Projektový manažer navazuje kontakt s klientem a probírá s ním událost. Jedná o narozeninovou oslavu, svatbu, výročí, promoci? Kdy se daná událost koná? Jakmile je rozhodnuto, plánovač události začne jednat s klientem o konkrétním místě, občerstvení, výzdobě a dalších specifických detailech. DJ mluví s klientem o stylu hudby, která by měla na události hrát. Projektový manažer dohlíží na plánovače událostí a diskžokeje. Projektový manažer dále také schvaluje výdaje související s projektem. Máme rozsáhlou sbírku CD nosičů. Každé CD obsahuje několik písní. Stejná píseň se však může objevit na více různých CD. Každou píseň klasifikujeme podle jejího typu (hip hop, rock, R & B, polka, salsa, jazz, klasika atd.) Na základě typu události pak nabídneme klientovi počáteční seznam písní. Klient si samozřejmě může vybrat i jiné písně. Seznam našich klientů narůstá. Mnozí klienti poptávají naše služby opakovaně. Máme i zákazníky, kteří pořádají více než jednu událost ve stejnou dobu. Máme také seznam témat, která můžeme použít ke kategorizaci těchto událostí. Například: svatba může mít na tropické motivy, firemní večírek na karnevalové téma, výročí se zaměřením na šedesátá léta apod. To nám pomáhá vybrat místo a současně dává představu diskžokejům (a dalším) co si mají obléci. Někteří z našich DJů se specializují na určitá témata a plánovači mají odborné znalosti v určitých oblastech, což nám pomáhá přiřadit k dané události ty správné partnery. Události se konají buď na veřejných místech, nebo soukromém domě. V každém případě manažer události navštíví dané místo a dohodne se s pronajímatelem veřejného místa, nebo s vlastníkem domu. Jelikož událost může být přiřazena několika partnerům a jeden partner může pracovat na více událostech, potřebujeme uchovávat informace, kdo se na jaké události podílí. Dále chceme mít záznam o tom, na čem se daný partner podílel a kdy.
DJs on Demand Business Scenario We started out as a group of friends who organized parties and customized our own music. Then we thought we’d turn it into a business to pursue our interests and earn some money. We called ourselves the “DJs on Demand.” Everyone who works here is a partner. Every partner has a specific responsibility. The project manager makes the first contact with the client to discuss the event. Is it a birthday party, a wedding, an anniversary, a graduation? What is the date for the party or event? Once that’s decided, the event planner gets in touch with the client about specific locations, catering, decorations, and other specific details. The DJ talks with the client about the kind of music wanted. The project manager supervises the event planners and DJs. He/she also authorizes expenditures related to a project. We have a large collection of CDs. Each CD contains several songs, and the same song can appear on several CDs. We like to classify each song by type (hip hop, salsa, R & B (rhythm and blues), techno, salsa, polka, rock, jazz, new age, classical, etc.) We can propose an initial list of songs to the client depending on the event. Of course, a client can request other songs as well. Our client list is growing. We have a lot of repeat business – customers who like what we’ve done and ask us to work their other events. We have some very busy customers who can have more than one event going on at the same time. We also have a list of themes that we can use to categorize these events. For example: a wedding may have a tropical theme, a party may have a carnival theme, an anniversary could have a sixties theme, etc. This helps us pick a venue and also gives us an idea of what the DJ (and other musicians) should wear. Some partners have a specialty or expertise – so a theme also can help us assign the right person to the job. Events are held either in a public space or a private home. The event manager visits both and makes arrangements with the public-space renter or the private-home owner. Since several partners can work on an event, and an event can be assigned to several partners, we like to keep track of who is working on which event. We keep a log of what each event planner and DJ has done on an event, and when they did it.
