290 likes | 812 Views
Entitetno relacijski model podatkov. Postopek načrtovanja PB. Splošni cilj razvijalcev IS: razvoj aplikacij, ki bodo podpirale dana opravila v realnem svetu. Načrtovanje podatkovne baze - postopek opredelitve in razvoja strukture PB
E N D
Postopek načrtovanja PB • Splošni cilj razvijalcev IS: razvoj aplikacij, ki bodo podpirale dana opravila v realnem svetu. • Načrtovanje podatkovne baze - postopek opredelitve in razvoja strukture PB • V času načrtovanja podatkovne baze naredimo formalni model nekaterih aspektov (vidikov) realnega sveta – to je 'mini-sveta' ali 'problemske domene‘ • Mera za pravilnost načrtovane sheme PB = realni svet vsebina PB mora odražati podatke, pravila in izjeme iz realnega sveta.
Problemi načrtovanja PB • Nepoznavanje področja • načrtovalec problemskega področja načeloma ne pozna. Zato se mora najprej seznaniti in potem podrobno spoznati domeno problema in bodoče aplikacije. • Pravila in izjeme • Poleg pravil v realnem svetu obstaja tudi veliko izjem. Realni svet in njegovo okolje sta dinamična sistema, ki se pogosto spreminjata. Načrtovalec pri svojem delu mora upoštevati vsa pravila in tudi vse izjeme. Hkrati mora narediti sistem dovolj fleksibilno shemo, ki bo prilagojena bodočim spremembam. • Velikost • Načrti PB so pogosto zelo kompleksni za človeka težko obvladljivi. • Ključno sodelovanje z uporabniki
Postopek izdelave PB Izbira SUPB-ja Logična shema Notranja shema
Opis faz izdelava PB 1. Zbiranje in analiza zahtev spoznavanje segmenta realnega sveta ('mini sveta‘), ki ga bo predstavil z modelom Razumevanje: • katere podatke je potrebno hraniti v PB, • kako so podatki povezani, • katere operacije se izvajajo nad podatki in • kako bodo uporabniki uporabljali PB. 2. Konceptualno načrtovanje Izdelati konceptualni načrt oz. konceptualno shemo PB Konceptualni načrt zajema tudi omejitve, ki se nanašajo na podatke. Za predstavitev konceptualnega načrta se uporabljajo: • entitetno – relacijski diagrami, • diagrami razredov (UML notacija) in • diagrami objekt-vloga (Object-role model). uporabniki razvijalec pod. sistema
Opis faz izdelava PB (nad.) 3. Izbira SUPB-ja (vodja projekta + uporabniki) 4. Logično načrtovanje • Transformacija: konceptualne sheme podatkovni model, ki ga podpira izbrani SUPB. • natančen pregled dobljene logične sheme in iskanje morebitnih napak • Preverjanje, ali je PB normalizirana (preverimo funkcionalne odvisnosti med atributi, ali obstaja nepotrebno podvajanje podatkov, …). 5. Fizično načrtovanje podatkovne baze • izboljšanje performans končnega sistema • določamo indekse in parametre shranjevanja podatkovne baze • Identificiramo različne skupine uporabnikov in preverjamo ustreznost performans PB glede na potrebe in zahteve uporabnikov
Cilji konceptualnega modela • Izhodišče za razvoj podatkovnega sistema • Komunikacija z naročniki in vodstvom • Dokumentacija • Zagotavljanje kakovosti • Modularnost (lažje obvladovanje kompleksnih primerov) • Značilnosti ER modela • Avtor: Peter Pin-Shan Chen (1976) • semantična usmerjenost (usmerjen v pomensko predstavitev realnega sveta) • izrazna grafična notacija boljši pregled nad strukturo podatkov • nazorna preslikava realni svet podatkovni model • omogoča dobro komunikacijo z uporabniki (lažje jih vključimo v proces validacije načrta)
Orodja • CaseStudio • ERWin (Computer Associates) • Oracle Designer • DeZign for Databases • MS Visio • Open Source: DB Designer, MyERD
Primer težav pri komunikaciji: uporabniki načrtovalec
Osnovni konstrukti ER modela • Entiteta, entitetni tip • Atribut, tip podatkovnih elementov • Entitetni identifikator (ključ entitetnega tipa) • Razmerje, tip (števnost) razmerja • Močne / šibke entitete
Entiteta, entitetni tip • Entiteta • objekti (osebki) iz realnega sveta o katerih zbiramo, obdelujemo in hranimo podatke in informacije • Primeri entitet: človek Miha Novak, knjiga Vojna in mir, tečaj Angleščina 1, avto Ford Fiesta, … • Pomembno: mora obstajati možnost razlikovanja med posameznimi entitetami! (vsaka entiteta mora imeti neko lastnost, po kateri lahko enolično opredelimo posamezno entiteto) • Tej lastnosti pravimo tudi entitetni identifikator ali ključ entitete • Entitetni tip • predstava o množici podobnih entitet • podobnost entitete določamo glede na vrste informacij, ki jih želimo hraniti o entitetah • je abstraktna predstavitev entitet, ki imajo enake atribute
Atribut, tip podatkovnih elementov • Atribut • lastnost ali značilnost neke entitete ali razmerja med entitetami. • Vrednost atributa je podatkovni element nekega podatkovnega tipa (niz, število, …) in ga je možno prikazati v neki vidni ali slišni obliki (zaslonski prikaz, natisnjena oblika, zvok …) • Opcijski atribut • Atribut, katerega vrednost je lahko tudi NULL • Enovrednostni / večvrednostni atribut • Atribut neke entitete ima le eno vrednost (ime, datum rojstva, ….) • Atribut neke entitete ima več vrednosti (e-mail, telefon, …) // za potrebe relacijske PB jih s pomočjo razmerja preoblikujemo v enovrednostne atribute • Oznake za števnost atributa: • (1,1) – zahtevan vnos, enovrednostni atribut • (0,1) - opcijski enovrednostni atribut • (1,n) - zahtevan vnos, večvrednostni atribut • (0,n) – opcijski večvrednostni atribut • Tip podatkovnih elementov • Vsak podatek pripada določenemu tipu (nizi znakov, števila, datumi, slike, …). • Večina SUPB-jev ima določeno število vnaprej definiranih tipov podatkov, ki jih podpirajo. • Dokončna izbira tipa podatkovnih elementov se opravi v fazi fizičnega načrtovanja
Razmerje med entitetnimi tipi • Razmerje opredeljuje povezavo med entitetnimi tipi • ER model dovoljuje povezovanje poljubnega števila entitetnih tipov, CASE orodja pa omogočajo je binarna razmerja
Entitetni identifikator (ključ entitetnega tipa / primarni ključ) • Definicija: Ključ entitetnega tipa E je atribut (ali več atributov skupaj), ki enolično določajo / identificirajo posamezni primerek entitetnega tipa (entiteto). • Ključ entitetnega tipa ni nikoli opcijski atribut njegova vrednost mora biti podana. • Primarni ključ nekega entitetnega tipa je možno deklarirati tudi kot sestavljenko iz dveh ali več atributov // slabo dolgi ključi =>daljše (večje) indeksne datoteke =>počasnejše delovanje PB • Pri grafični predstavitvi entitetnega tipa z atributi, imena atributov, ki sestavljajo primarni ključ (entitetni identifikator) podčrtamo:
Števnost (kardinalnost) razmerja • Entiteta je lahko v razmerju z nič, eno ali več entitet drugega tipa (teoretično) • Praksa: obstajajo pravila, ki govorijo o dovoljenjem številu pojavitev neke entitete v nekem konkretnem razmerju • Ta pravila predstavimo s števnostjo razmerja • Notacija: (min,max) število pojavitev entitete v razmerju • Kardinalnost opredelimo za vsak entitetni tip posebej
Značilne števnosti razmerja • 1:1 (ena proti ena) • 1:M (ena – mnogo) oziroma M:1 (mnogo proti ena) • M:N (mnogo proti mnogo) // zaradi poenostavitve je splošna praksa, da se za števnost razmerja beleži le max. števnost na obeh straneh razmerja
Udeležba (participacija) entitete v razmerju • popolna ali totalna participacija: vsak primerek entitetnega tipa (vsaka entiteta) se mora udeležiti v razmerju • delna ali parcialna participacija: entitete se lahko udeležijo ali pa ne udeležijo razmerja. • Minimalne kardinalnosti ne vplivajo na klasifikacijo (razvrstitev) razmerji med osnovne zvrsti 'ena proti ena', ' ena proti mnogo' in ' mnogo proti mnogo'.
Alternativne (veljavne) notacije CASE Studio DBDesigner
Vaja za oceno • Izdelaj ER diagram za potrebe kina. • Upoštevaj, da: • ima kino več dvoran • Predvaja več filmov • Ima različne termine predvajanja • Sedeži so oštevilčeni
Izdelava PB s pomočjo CASE orodja • Izdelaj konceptualni model (ER diagram): • Dodaj entitetne tipe • Entitetne tipe opiši z atributi • Določi entitetni identifikator // če ga ni, dodaj ID ali šifro • Poveži entitetne tipe • Povezavi dodaj (morebitne) atribute • Preveri (verificiraj in validiraj )model • Shrani, izdelaj dokumentacijo • ===== • Izberi SUPB • Izdelaj skripto za ciljni SUPB • Kreiraj PB
Močne in šibke entitete • Značilnost močnega entitetnega tipa: • ključ sestavlja(jo) le atribut(i), ki pripada(jo) temu entitetnemu tipu • Šibka enititeta: • ne more obstajati brez svoje starševske entitete • med šibko in močno entiteto vedno obstaja razmerje, ki s kardinalnostjo (1:1) kaže proti močni entiteti • ključ starševske entitete se prenese šibki entiteti kot zunanji ključ in postane sestavni del ključa šibke entitete
Primer močnega in šibkega entitetnega tipa • Case Studio: • Močno in šibko entiteto povežemo z ‘identifying relationship’ • Dve močni entiteti povežemo z ‘non-identifying relationship’
Pasti ER načrtovanja • Najpogostejše pasti pri ER načrtovanju so pasti ‘povezovanja’ • Najbolj znani sta: • ‘fan-trap’ • ‘chasm-trap’
‘fan trap’ • Do fan pasti pride, ko model predstavlja razmerje med entitetnima tipoma, vendar so števnosti teh povezave nastavljene tako, da so povezave med posameznimi entitetami dvoumne. • Pojavlja se načeloma takrat, ko iz enega entitetnega tipa izhajata dve 1:m povezavi. • V katerem oddelku dela Miha Novak?
‘fan – trap’ - rešitev • preoblikovanje originalnega ER modela tako, da razmerja prestavimo (uredimo) tako, kot v resnici obstajajo • Primer: Delavec dela v oddelku, oddelek se nahaja na lokaciji.
‘chasm-trap’ • model nakazuje obstoj razmerja med entitetnimi tipi, vendar ne obstaja pot med posameznimi konkretnimi entitetami. • Pojavlja se, ko na poti med dvema povezanima entitetama obstaja razmerje z delno udeležbo. • kateri učbeniki obstajajo za kateri predmet?
‘chasm– trap’ - rešitev • Chasm past rešimo z dodajanjem manjkajočih relacij. • V ER diagramu manjka relacija 'obstaja', ki neposredno povezuje entitetna tipa Predmet in Učbenik.