Modeliranje podataka i analiza

1. Modeliranje podataka i analiza Doc. dr Angelina Njeguš Modeliranje podataka Osnovni pojmovi modela podataka Logičko modeliranje podataka

2. Modeliranje podataka • Modeliranje podataka je tehnika za organizovanje i dokumentovanje strukture podataka sistema. Modeliranje podataka se ponekad zove modeliranje baze podataka jer se model podataka na kraju implementira kao baza podataka. Modeliranje podataka je naše apstraktno viđenje stanja realnog sistema. • Model podataka je pojednostavljeno predstavljanje realnog sistema preko skupa objekata (entiteta), veza između objekata i njihovih atributa. • Model podataka (u literaturi definisan kao Model Objekti-Veze - MOV ili Entity-Relationship - E-R model), preko skupa podataka i njihovih međusobnih veza, predstavlja stanje sistema u jednom trenutku vremena i sadrži skup informacija o prošlosti i sadašnjosti sistema koja je potrebna da se pod dejstvom budućih poznatih ulaza mogu odrediti njegovi budući izlazi. • Postoji nekoliko notacija modela objekti-veze. Mnogi su imenovani prema njihovim tvorcima (npr., Chen, Martin, Bachman, Merise) ili prema objavljenim standardima (npr., IDEF1X). Svi „jezici“ modeliranja podataka podržavaju iste fundamentalne koncepte i konstrukcije.

3. Osnovni pojmovi modela podataka • Objekat je klasa osoba, mesta, objekata, događaja ili koncepata o kojima treba da prikupljamo i skladištimo podatke. • Objekat je nešto što se može videti, dodirnuti ili drugačije osetiti, koji ima svoja svojstva i ponašanja i o kome korisnici mogu da skladište podatke. • Tipovi objekata se mogu klasifikovati u osobe, mesta, stvari ili događaje. U okviru tipa objekta osobe mogu se svrstati radnici, klijenti, prodavci, studenti i dr. Skladišta, zgrade, sobe su primeri tipa objekata mesta. Primeri tipa objekata stvari uključuju proizvod, vozilo, opremu, videotraku i dr. Na kraju objekti događaja uključuju porudžbinu, plaćanje, račun, aplikaciju, registraciju ili rezervaciju. • Atribut je osobina ili karakteristika objekta.

4. Osnovni pojmovi modela podataka • Tip podatka definiše koja klasa podataka može biti skladištena u taj atribut. • Domen definiše koje vrednosti može da ima jedan atribut. • Difoltna vrednost je ona vrednost koja će biti uskladištena za dati atribut ukoliko je korisnik ne promeni.

5. Osnovni pojmovi modela podataka(nastavak) • Svaki objekat mora da ima jedinstveni ključ po kome će se pretraživati u bazi podataka. Osnovna svrha ključa jeste da jedinstveno identifikuje svaki objekat. • Grupa atributa koja jedinstveno identifikuju objekat se zovu složeni ključ. ŠIFRA_KASETE (PRIMARY KEY) . ŠIFRA_NASLOVA . BROJ_KOPIJE • Objekat može imati više od jednog ključa. Na primer, objekat RADNIK se može jedinstveno identifikovati preko matičnog ličnog broja ili preko šifre zaposlenog ili preko e-mail adrese. Svaki od ovih atributa se nazivaju kandidati za ključ. Kandidati za ključ su kandidati za primarni ključ. • Primarni ključ (PRIMARY KEY) je kandidat za ključ koji će se najčešće koristiti da jedinstveno identifikuje dati objekat. Svi drugi kandidati za ključ koji nisu izabrani za primarni ključ se zovu alternativni ključevi. • Difoltna vrednost primarnog ključa je NOT NULL, odnosno ključ ne sme da bude prazno polje, jer onda neće moći da jedinstveno identifikuje dati objekat.

6. Ključevi • Ključevi se definišu kao jedan ili više atributa čija vrednost jedinstveno identifikuje jedan red (zapis) u tabeli. • Ako je ključ definisan samo jednim atributom, onda je to prost ključ, a ukoliko je definisan sa više atributa, onda je to složeni ključ. • Ključ mora da zadovolji sledeće osobine: • jedinstvenost i • neredundantnost. • U jednom objektu može postojati više različitih atributa koje zadovoljavaju definiciju ključa - svi se nazivaju kandidati za ključ. • Spoljni (Strani ili preneseni) ključ je atribut ili grupa atributa jednog objekta, čija se vrednost koristi za povezivanje sa vrednošću primarnog ključa u drugom objektu. • Spoljni ključevi i njima odgovarajući primarni ključevi definisani su nad istim domenom. • Spoljni ključevi služe da se uspostave veze između tabela u bazama podataka.

7. Osnovni pojmovi modela podataka(nastavak) • Objekti ne ekzistiraju sami već moraju biti u nekoj relaciji ili vezi sa drugim objektima. • Ukoliko posmatramo objekte Zaposleni i RadnoMesto, jedna od relacija između ova dva objekta će biti Angažovan, što znači da je zaposleni angažovan na određeno radno mesto u nekoj organizaciji.

8. Kardinalnost ili višestrukost • Kardinalnost definiše minimalni i maksimalni broj događaja jednog objekta koji se nalazi u konkretnoj relaciji sa drugim objektom. Pošto su sve relacije dvosmerne, kardinalnost se mora definisati za oba smera. • Pošto su sve relacije dvosmerne, kardinalnost se mora definisati za oba smera. Kao što je prikazano na prethodnoj slici, u zagradama, konkretan zaposleni (npr., Petar Petrović) može da bude angažovan minimum na jedno (1), a maksimalno na više radnih mesta (M). • Na primer, Petar je angažovan na radno mesto programera i konsultanta za prodaju softvera. Međutim, na određeno radno mesto može biti minimum jedan (1), a maksimalno više zaposlenih (M). Na primer, na radno mesto konsultanta može biti angažovano više zaposlenih, odnosno u organizaciji je zaposleno više konsultanata.

9. Agregacija • Agregacija istovremeno predstavlja i objekat i vezu, odnosno udruženi ili asocijativni objekat (associative entity), između dva ili više objekta • Ukoliko postoji potreba da se u toku relacije čuvaju dodatni atributi, tada relacija postaje udruženi objekat. • Udruženi objekat je objekat koji nasleđuje primarne ključeve svojih tzv. „roditelja“. • Na primer, atributi udruženog objekta Poručeni proizvod su Poručena količina i Jedinična cena, a njeni ključevi bi bili atributi PorudžbinaID i ProizvodID.

10. Spoljni ili strani ključ • Objekti se povezuju pomoću spoljnjeg ključa. • Spoljni ključ (Foreign key) je atribut ili grupa atributa jednog objekta, čija se vrednost koristi za povezivanje sa vrednošću primarnog ključa drugog objekta. • Odnosno, spoljni ključ objekta 1 je primarni ključ objekta 2 sa kojim je objekat 1 u vezi. • Spoljni ključevi i njima odgovarajući primarni ključevi definisani su nad istim domenom. Na primer, pogledajmo relaciju Klijent i Porudžbina sa slike. S obzirom da klijent može da ima više porudžbina, tada ćemo primarni ključ objekta Klijent (u našem primeru to je KlijentID) preneti u objekat Porudžbina, gde će taj atribut predstavljati njegov spoljni ključ. Za konkretnu porudžbinu, postojanjem spoljnog ključa KlijentID, znaće se ko je načinio konkretnu porudžbinu.

11. Problem relacije više-prema-više • Kod onih relacija gde postoji veza više prema više, onda se ubacuje među objekat, kako bi rešio problem višeznačne zavisnosti. • U slučaju da zaposlen može biti angažovan na više radnih mesta, a na jednom radnom mestu može da bude angažovano više zaposlenih, tada se ubacivanjem udruženog objekta pravi veza jedan prema više (1,M) prema ovim objektima. Jedini atributi ovog među-objekta su primarni ključevi objekata koje povezuje.

12. Slab objekat • Ukoliko postoji potreba da se ponavljaju vrednosti jednog atributa u okviru određenog objekta, tada se takav atribut izdvaja i formira se slab objekat. • Na primer, za objekat zaposleni koji ima atribut telefon, želimo da pamtimo više telefona. Tada ćemo napraviti slab objekat telefon koji će naslediti primarni ključ svog nad objekta

13. Generalizacija/specijalizacija • Generalizacija je tehnika gde se objekti sa zajedničkim atributima, vezama i/ili operacijama, grupišu (generalizuju) u jedan objekat koji se zove nadtip. • Inverzni postupak, gde se za neki tip objekta, definišu njegovi podtipovi, koji imaju neke njima specifične atribute, veze i/ili operacije, je specijalizacija. • Na primer, objekti Student, Zaposleni, Dete i Penzioner imaju zajedničke atribute kao što su Ime i prezime, JMBG, Starost i Adresa, tako da se mogu predstaviti generičkim tipom Osoba. S obzirom da Student ima sebi svojstvene atribute kao što je Broj indeksa, a Zaposleni ima npr., Platu, tada se objekat Osoba specijalizuje u objekte Student i Zaposleni.

14. Jednostavan primer

15. Primer

16. Logičko modeliranje podataka • Mnoge kompanije prvo obavljaju strateško planiranje gde se razvija strateški plan informacionog sistema u kome se definišu vizija i arhitektura informacionog sistema. • Arhitektura informacionih sistema uključuje model podataka kompanije. • Model podataka kompanije identifikuje osnovne objekte bez opisivanja njegovih atributa ili ključeva, a takođe može da uključi, a ne mora, relacije između objekata. • Prvi zadatak u modeliranju podataka je da se odrede osnovni objekti sistema. Postoji nekoliko tehnika koje se mogu koristiti za identifikaciju objekata: • Tokom intervjua sa vlasnicima i korisnicima sistema, treba obratiti pažnju na ključne reči njihove diskusije. Na primer, ukoliko korisnik kaže «Treba informisati naše stalne kupce, o novom kvalitetu proizvoda», primetićemo da su ključne reči u ovoj rečenici Kupci i Proizvod, a oni su ujedno i objekti sistema. • U toku intervjua treba pitati vlasnike i korisnike sistema da identifikuju one stvari za koje žele da prikupljaju, skladište i dobijaju informacije. Često su to objekti koji treba da budu opisani u modelu podataka. • Druga tehnika za identifikaciju objekta je da se prouče postojeći formulari i kartoteke. Neki formulari identifikuju događaj objekata. Na primer, porudžbina, uplata, depozit itd. • Neki CASE alati takođe mogu da identifikuju objekte. • Kada se identifikuju objekti sistema, treba im dati jednostavna, značajna, poslovno-orjentisana imena.

17. Logičko modeliranje podataka • Drugi zadatak u modeliranju podataka je identifikovanje atributa objekata. Predlaže se sledeći način: • Mnoge kompanije koriste standardna imena i skraćenice. Administrator podataka obično održava takve standarde. • Pažljivo birajte imena atributa. Mnogi nazivi atributa imaju istu osnovu, npr. ime, adresa, datum, njih bi trebalo razdvojiti, kao npr., NazivDobavljača, NazivKlijenta i sl. • Treći korak je da se identifikuju ključevi za svaki objekat. Predlaže se sledeće: • Vrednost ključa ne sme da se menja u toku veka trajanja svakog objekta. Na primer, Prezime osobe se ne može uzeti kao ključ, jer osoba može da promeni svoje prezime ukoliko se venča ili razvede. • Vrednost ključa ne može da bude prazno polje. • Kontrole ključa moraju da budu instalirane, kako bi vrednost ključa bila uvek validna. • Identifikovanje zavisnih entiteta - entiteti čija egzistencija i identifikacija zavisi od drugog ili drugih entiteta.

18. Logičko modeliranje podataka • Definisanje veza - Veza je asocijacija između dva ili više entiteta, tj. predstavlja odnos koji postoji među objektima, bilo u realnosti ili u mislima. Entitet od koga je uspostavljena veza zove se "roditelj" (parent) ili domen, a entitet ka kome je uspostavljena veza zove se "dete" (child) ili kodomen. Način povezivanja dva entiteta (kardinalnost) pokazuje "koliko nečega" od dva entiteta može biti uključeno (sadržano). • U toku određivanja objekata sistema, njihovih atributa, ključeva i relacija iscrtava se kontekstualni (konceptualni) model podataka, na kome će se jasno uočiti objekti i njihove međusobne veze. • Normalizacija relacionog modela podataka - Normalizacija je tehnika analize podataka koja organizuje atribute na način kako bi se dobili neredundantni, stabilni, fleksibilni i prilagodljivi objekti. U toku normalizacije proverava se da li su atributi dobro postavljeni i određuju se odgovarajući spoljni ključevi koji povezuju objekte. • Poslednji korak je prevođenje logičkog modela podataka u fizički model (šema baze podataka) u zavisnosti od izabranog sistema za upravljanje bazom podataka (Database Management System – DBMS).

19. Primer logičkog i fizičkog modela podataka

20. Logičko modeliranja podataka na primeru FAKTURE • Polazi se od EDIFACT standarda koji je definisan dokumentom UN/ECE WP.4 koji svojom preporukom broj 6, izdanje iz 1975. godine, preporučuje da se obrazac za fakturu u međunarodnoj trgovini zasniva na obrascu prema ISO 6422 (skraćeno: UNLK) – JUS ISO 6422. • Obrazac je baziran na principu "box design". Razmeštaj rubrika je fiksiran kao npr. adresa primaoca, koja je definisana zbog koverata sa prozirom i pritom su razmatrani administrativni, pravni i trgovinski aspekti. Prostor "za slobodno raspolaganje" u najnižem delu obrasca namenjen je za više posebnih potreba za individualne aplikacije. Ako trgovački partneri primenjuju dokumente koji sadrže šire polje podataka nego set UNLK, ili od onog što je propisano u standardima za odgovarajuće podatke, o tome se moraju posebno dogovoriti. Sve ovo je išlo u prilog da se prihvati jedan standardizovani obrazac (ISO 7372), kao što je prikazano na sledećoj slici.

21. Obrazac EDIFACT fakture

22. Slika. Logički model podataka EDIFACT fakture

23. Logički model baze agencijskog poslovanja