Analýza dat a modelování Přednáška 2
E-R model jiné notace většina současných modelovacích nástrojů case používá jinou grafickou notaci než původní Chenovu nástroj SQL Developer Data Modeler: entity obdélník atributy seznam uvnitř obdélníka primární klíč označen znakem # povinná hodnota (NOT NULL) označena znakem * nepovinná hodnota označena kolečkem
E-R model jiné notace vztahy čára kardinalita a povinnost členství ve vztahu se vyjadřuje typem čáry kardinalita 1:N, resp. M:N : rozvětvení čáry plná: povinný výskyt ve vztahu přerušovaná: nepovinný výskyt ve vztahu
Vztah M:N atribut vztahu rozvětvení vícenásobný výskyt přerušovaná čára nepovinný výskyt ve vztahu vztah: SI_REZERVOVAL (ČTENÁŘ - 0..*:0..* - KNIHA)
Vztah M:N jméno ani atributy vztahu se standardně nezobrazí, pro zobrazení jména musíme vyplnit položky Name on Source a Name on Target
Vztah M:N a ještě zapnout ve vlastnostech výkresu zobrazování názvů (Label) a atributů (Relationship Attributes)
Vztah 1:N vztah: JE_OD(EXEMPLÁŘ 1..1: 0..* - KNIHA)
Vztah 1:N (slabý entitní typ) identifikační závislost a povinné členství ve vztahu vztah: PATŘÍ_K(KOPIE 1..1: 0..* - FILM)
ISA vztah (ISA hierarchie) z anglického is a (česky: je) vyjadřuje hierarchické uspořádání entitních typů programátoři hovoří o nadtypech a podtypech v objektově orientovaných jazycích o nadtřídách (rodičích) a podtřídách (potomcích) jednoduchá hierarchie má podobu stromu
kořen stromu zdroj hierarchie RČ JMÉNO VIN ZNAČKA MODEL OSOBA AUTO MUŽ ŽENA OSOBNÍ_A NAKLADNÍ_A VĚK DELKA_PRAXE POČET_MÍST NOSNOST
ISA vztah v lineárním zápisu (nikoliv stromovém) lze hierarchii popsat výčtem dvojic a tvrzením být podtypem pomocí slovesa je (is a) MUŽ JE OSOBA (MAN IS A PERSON) ŽENA JE OSOBA NÁKLADNÍ_A JE AUTO OSOBNÍ_A JE AUTO
ISA vztah notace v Oracle SQL Modeleru vytvoření: vytvoříme samostatné Entity, ve vlastnostech zamýšlených podtypů vybereme nadřazenou entitu v políčku Super Type
ISA vztah předpokládá se výlučnost, tj. výskyt entity osoba s určitým RČ může být buď muž nebo žena u hierarchie: HEREC JE OSOBA REŽISÉR JE OSOBA nelze mít v databázi osobu, která by byla současně hercem a režisérem v tomto případě je lépe vytvořit samostatné entitní typy HEREC, OSOBA, REŽISÉR a zavést mezi nimi vztah
ISA vztah postup modelování hierarchií: shora dolů: specializace zdola nahoru: generalizace
Výlučné typy vztahů konstrukt, který (zdánlivě) rozšiřuje původní E-R model případ, kdy entity z jedné entitní množiny rozdělíme do dvou (nebo více) disjuktních podmnožin (nikoliv na podtypy a nadtypy) a entity z těchto podmnožin mají výlučné vztahy s jinou entitou
Výlučné typy vztahů Příklad: uvažujme vstupenky dvojího druhu jedny na konkrétní promítání filmu (představení) v určitý den druhé na film (zákazník je může použít na jakékoliv promítání daného filmu) entita vstupenky podle svého druhu má buď vztah s entitou představení nebo film
Výlučné typy vztahů vytvoření: označíme entitní typ a oba vztahy, klikneme na tlačítko Add Arc
Notace UML třída v OOP značena obdélníkem ze tří částí jméno třídy atributy operace (metody) E-R model x UML entity = třídy entitní typ = jméno třídy atribut = jméno atributu operace v E-R modelu nejsou
Notace UML vztahy = asociace jejich výskyty jsou spoje (links) atributy vztahů se zapisují do obdélníku připojeného přerušovanou čárou k čáře asociace kardinalita se značí *, v případě min-max jsou umístěny dvojice obráceně než u E-R modelu odpovídají značení 1:N v E-R modelu
Notace UML * *
Notace UML 1..* 1..1
Poznámka - vztahy M:N některé nástroje nemají vztahy M:N řešení: dekompozice vztahu mezi entitami E1 a E2 na dva vztahy 1:N vzpomeňme: jak se do relačního modelu transformuje vztah M:N vztah M:N převedu na samostatnou relaci s cizími klíči již do E-R modelu zavedu entitní typ E3 odpovídající relaci M:N a zavedu vztahy 1:N mezi E1-E3, E2-E3
Databázové modely hierarchický síťový probereme si dnes relační detailně probíráme v předmětu Databáze I
Hierarchický model Hierarchický model vytvořen v době, kdy byla všechna data uložena v souborech (na páscích, sekv. přístup) entity jsou uloženy jako běžné záznamy (na pásce) sekvenčně, seřazeny
vztahy jsou realizovány záznamy typu vlastník-člen (otec a syn) na pásku zapíši nejprve záznam otec (vlastník), za něj seznam synů (členů) záznamy tvoří strom každý otec může mít více synů, ale syn pouze jednoho rodiče nelze realizovat přímo vztahy M:N, pomohu si opět dekompozicí na dva vztahy 1:N databáze je les stromů
Příklad: ukážeme si uložení záznamu o vypůjčených exemplářích jeden strom srovnáme jej s relačním modelem
Relační model ČTENÁŘ RČ JMÉNO PŘÍJMENÍ 320612/1234 František Kuldanů 521006/5678 Josef Novák KNIHA ISBN TITUL AUTOR 80-11111-22-3 U nás A. Jirásek 80-85190-38-9 Babička B. Němcová EXEMPLÁŘ PŘÍR_Č CENA 1 100 2 100 3 150 D_NÁK 25.3.1990 25.3.1990 26.3.1990 ISBN 80-85190-38-9 80-85190-38-9 80-11111-22-3
Relační model SI_VYPŮJČIL RČ PŘÍR_Č DAT 320612/1234 1 10.11.2005 320612/1234 3 10.11.2005 521006/5678 2 20.11.2005
Hierarchický model SI_VYPŮJČIL 320612/1234 František Kuldanů (záznam otec ) 1, 100, 25.3.1990,10.11.2005 (záznamy syn ) 3, 150, 26.3.1990,10.11.2005 521006/567 Josef Novák (záznam otec ) 2, 100, 25.3.1990,20.11.2005 (záznam syn ) je možné obrátit role vlastník -člen (otec syn), tedy záznamy mohou vypadat takto:
Hierarchický model Kuldanů Novák 1 3 2 je možné obrátit role vlastník -člen (otec syn), tedy záznamy mohou vypadat takto:
Hierarchický model SI_VYPŮJČIL 1, 100, 25.3.1990,10.11.2005 (záznam otec ) 320612/1234 František Kuldanů (záznam syn ) 2, 100, 25.3.1990,20.11.2005 (záznam otec ) 521006/567 Josef Novák (záznam syn ) 3, 150, 26.3.1990,10.11.2005 320612/1234 František Kuldanů (záznam syn )
Hierarchický model nabývá opět významu i dnes soubory typu XML mají hierarchickou strukturu mnoho objektů reálného světa má hierarchickou organizaci
Hierarchický model fyzická pošta, uzemní správa internetové domény firemní organizace souborový systém LDAP textové dokumenty, html
Hierarchický model - ceník <ceník> <název>počítačové komponenty</název> <platnost> <od>1.1.2009</od> <do>31.3.2009</do> </platnost> <dodavatel> <název>první hardwarová, s.r.o.</název> <adresa> <ulice>průmyslová</ulice> <město>praha 10</město> <psč>100 00</psč> <email>info@prhw.cz</email> </adresa> <nabídka> <kategorie> <název>polohovací zařízení</název> <produkt kód="pxbd-21"> <název>hyperoptická digitální myš</název> <cena měna="czk">850</cena> </produkt>... zdroj následujících snímků (kromě SNMP): RNDr. Palovská
Hierarchický model - objednávka
Hierarchický model oddělení ve firmě
Hierarchický model kusovník první hierarchická databáze (a SŘBD) byl kusovník součástek (cca 2 milióny) pro program Apollo kosmická loď se skládá z mnoha dílů, které mohou být složeny také z dalších dílů typická hiearchická organizace
Hierarchický model kusovník první hierarchická databáze (a SŘBD) byl kusovník součástek (cca 2 milióny) pro program Apollo kosmická loď se skládá z mnoha dílů, které mohou být složeny také z dalších dílů typická hiearchická organizace
Kusovník
Kusovník
Kusovník Poznámka: tečkovou notací se také odkazujeme na položky struktury MIB v protokolu SNMP
Kusovník srovnání s relačním modelem
SNMP protokol pro vzdálenou správu a ovládání síťových prvků pomocí protokolu je možné nastavovat síťové komponenty (např. vypínat porty), číst statistická data (počet prošlých TCP paketů přes port apod.) a různé další informace (směrovací tabulky) softwarové aplikace SNMP agent server na sledovaném zařízení SNMP manažer sbírá informace z agenta 43
množina objektů, které je možné spravovat, je definována pomocí MIB (Management Information Base) MIB je hierarchická, má stromovou strukturu každému uzlu je přiřazeno číslo objekty se definují a identifikují tečkovou notací pomocí jmen, resp. čísel 44
Část stromové struktury 45
Příklad: proměnná ipinrecieves počet přijatých datagramů iso.org.dod.internet.mgmt.mib-2.ip.ipinreceives 1.3.6.1.2.1.4.3.0 instance v SNMP protokolu jsou požadavky na to, co chceme spravovat, zapsány číselnou reprezentací uživatel softwarů může požadavek zadat pomocí textu 46
Kategorie zboží
Typový kusovník
Hierarchický model procházení databáze: snadný průchod od kořene k listům (rekurze) každý rodič zná potomky hledání: nutnost mít indexy, často hierarchické nevýhody: obtížná realizace vztahů M:N vztah od potomků k rodičům je obtížněji dohledatelný