0% found this document useful (0 votes)
44 views

Model Podataka I Server Model

The document discusses modeling data at both the logical and physical levels. It describes transforming an entity-relationship model into a server model by mapping classes/entities to tables, attributes to columns, and relationships to constraints and keys. Denormalization is also covered as a way to optimize query performance. Finally, the document outlines how to use UML profiling to design a database diagram by visually representing tables, columns, keys, relationships and other database elements and constraints.

Uploaded by

77tesla
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
44 views

Model Podataka I Server Model

The document discusses modeling data at both the logical and physical levels. It describes transforming an entity-relationship model into a server model by mapping classes/entities to tables, attributes to columns, and relationships to constraints and keys. Denormalization is also covered as a way to optimize query performance. Finally, the document outlines how to use UML profiling to design a database diagram by visually representing tables, columns, keys, relationships and other database elements and constraints.

Uploaded by

77tesla
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 45

Model podataka i server model

mr piro Gopevi dipl. in. E-mail:[email protected] at: 53-45

Sadraj
Model podataka Priprema za projektovanje server modela Transformacija ERM-a u server model UML profil za projektovanje baze podataka Realizovanje fizikih aspekata baze podataka

Model podataka
Pojednostavljena reprezentacija o relevantnim karakteristikama sistema data preko skupa objekata(entiteta), veza meu objektima i atributa objekata i veza

Model podataka
Podela modela podataka obzirom na koncepte koji omoguavaju semantiki bogatiju prezentaciju podataka:
I generacije svaki programski jezik je zaseban model podataka, a podaci se modeliraju preko koncepata kojima taj jezik raspolae (pointer, integer, matrica itd) II generacije- sadre koncepte za prezentaciju podataka kao: stablo, set, relacija itd. i semantiki su siromani: funkcionalni, hijerarhijski, mreni, klasini relacioni model (Codd 1970), warnier-ovi dijagrami III generacije- imaju koncepte generalizacije i agregacije i semantiki su bogatij :model objekti veze (MOV) - Entity relationship model (ERM) - Entity relationship atribut model(ERA) (Chen 1976), proireni relacioni model(RMT)(Codd 1979) IV generacije -objektno relacioni model, objektni orijentisani model itd

Model podataka
Objektno orijentisana A/D-> Objektno orijentisani model podataka -> Dizajn dijagrama klasa Relaciono modeliranje -> Relacioni model podataka -> ERD

Model podataka
Model podataka se sastoji iz tri dela:
Strukture - predstavljena skupom objekata i njihovih veza Ogranienja - razdvajaju dozvoljena od zabranjenih stanja skupa podataka Operatora - omoguavaju manipulaciju podacima u modelu podataka

Struktura i ogranienja opisuju statika svojsta sistema, a operatori dinamika

Model podataka
Logiki model podataka
Dizajn dijagrama klasa Dizajn dijagrama Dizajn dijagrama klasa klasa za aplikaciju za bazu Model objekti veze

Server model Fiziki model baze podataka

Notacija
Notacija
Chen 1976 -Entity relationship atribut model(ERA) Codd 1979 - proireni relacioni model(RM-T) UML (Booch, Rumbaugh, Jacobson) objektno relacioni, objekti model

UML pravljen imajui u vidu Chen-ovu i Codd-ovu notaciju UML je superskup ER notacije Dodavanjem Profila za projektovanje Baza Podataka UML podrava poslovne modele, logike i fizike modele aplikacija kao i modele podataka

Priprema za projektovanje server modela

Osnovna pravila preslikavanja


Model podataka
Ime objekta u mnoini Ime atributa Primarni jedinstveni identifikator Sekundarni jedinstveni identifikator Neopcionalna veza

Server model
Ime tabele Ime kolone Primarni klju Jedinstveni identifikator NOT NULL kolona na strani stranog kljua i ogranienje nad stranim kljuem Kolona na strani stranog kljua i ogranienje nad stranim kljuem

Opcionalna veza

Objekat klasa (objektni model), entitet (ERM)

Preslikavanje klasa/entiteta u tabele


Ne preslikava se model nego elementi modela
Klase u tabele Atributi u kolone Tipovi u tipove podataka Asocijacije u relacije

Preslikavanje klasa/entiteta u tabele


Naini preslikavanja klasa/entiteta u tabele
1-1 1-n n-1 n-n

Klase/entiteti se mogu se preslikavati na razliite naine zbog:


Performansi Sigurnosti Lakoe postavljanja upita, administratorove elje Posebnih potreba unutar baze podataka itd

Preslikavanje klasa/entiteta u tabele


Prema optoj metodologiji relacionih baza podataka
Asocijacije n-n
Mora da se razloi na relacije 1-n pravljenjem jedne tabele asocijacija

Klase asocijacija
Ako u modelu podataka postoji tabela asocijacija i sadri dodatne kolone pored stranog kljua onda mora u logikom modelu da postoji klasa asocijacija
Klasa1 n n Klasa 2

Klasa asocijacija

Klasa asocijacije

Preslikavanje klasa/entiteta u tabele


Podtipovi i supertipovi
Jedna tabela po klasi/entitetu svaka se klasa/entitet preslikava u odgovarajuu tabelu Jedna tabela po konkretnoj klasi/entitetu poznato kao sputanje tabela supertipova u njene podtipove Jedna tabela po hirjerarhiji poznato kao podizanje podtipova u supertip

Preslikavanje atributa u kolone


Mogu postojati atributi koji ne postoje u bazi podataka ili kolone koje se u stvari nigde ne prikazuju niti se koriste u aplikaciji ali postoje zbog specifinih potreba baze podataka Kada se atributi preslikavaju u kolone mogu se uzimati u obzir performanse baze podataka Spajanjem atributa iz vie klasa/entiteta mogu da se stvaraju pogledi u kojima postoje samo odreene potrebne informacije Preslikavanje atributa u kolone delimino potpada i pod preslikavanje klasa/entiteta u tabele
Kolone se ne mogu menjati bez uticaja na tabelu i obratno

Preslikavanje atributa u kolone


Vano je razumeti kako se tipovi podataka preslikavaju u tipove podataka za izabranu bazu podataka
U fazi analize i projektovanja tipovi podataka su opteg tipa (String, Date, Currency, Integer) U fazi analize i projektovanja nije toliko bitna ni duina tipova podataka. Kada se atributi preslikavaju u odreene kolone u bazi podataka, potrebno je odrediti i duzinu podataka

Treba proveriti i ogranienja i domene za dalje definisanje tih kolona

Pristup
Kod objektnog modela
Koje e klase iz modela logike analize biti transformisane u model baze podataka i kako (kod objektnog modela vano)? Polazimo od dizajna dijagrama klasa Svaku trajnu klasu treba oznaiti U bazu podataka se preslikavaju samo trajne klase
U trajnim klasama mogu se nai atributi koji se ne preslikavaju u kolone (umesto da se smetaju u bazu oni se prosto izraunavaju u aplikaciji)

Ne vodimo rauna o RDBMS-u

Pristup
Veza izmeu modela logike analize, projekta baze podataka i projekta aplikacije
Objektni pristup Projekat aplikacije (klase)

Sinhronizuj

Logika analiza (Klase/entiteti) Sinhronizuj

Objektno relaciono preslikavanje Projekat baze podataka (tabele)

Relacioni pristup

Pristup
Potrebno je da razumemo klase/entitete u modelu Uoiti atribute koji postoje u aplikaciji
Zadravamo ih u logikom modelu podataka, ali ih ne elimo nigde u bazi Pravimo izvedeni atribut i metod za njegovo izraunavanje i on postoji u aplikaciji

U logikom modelu atribute definisemo preko optih tipova, tipova za potrebe analize i domena (korisniki definisani tipovi)
Ne definiemo tipove podataka koji odgovaraju odreenom RDBMS-u Opti tipovi se u toku realizacije preslikavaju u tipove koji odgovaraju konkretnom RDBMS-u

Pristup
U ovoj fazi postaje bitno i nasleivanje i generalizacija
Treba odgovoriti na pitanje hoemo li sve tabele da podignemo u jednu, da ih spustimo na podtipove ili da ih ostavimo u relaciji 1-1 ?

Definiemo primarne kljueve


Neke klase sadre atribute koji e biti primarni kljuevi i njih oznaavamo, ali neki e biti napravljeni tamo gde identifikator nije potreban iz drugih razloga sem da bi se identifikovala tabela

Pristup
Treba se uveriti da svaka klasa/entitet definie samo jednu stvar koncept normalizacije
Ako definie vie od jedne stvari treba je razloiti na vie klasa/entiteta

Sada moe da se uradi denormalizacija modela -Pojedine klase/entiteti se mogu kombinovati radi optimizacije ali tek kada smo se uverili da je model normalizovan

Transformacija ERM u server model

Sadraj
Transformacija ERM u server model Denormalizacija Kreiranje objekta baze podataka Primena Oracle CASE alata Literatura

Nadtip i podtip I varijanta

Nadtip i podtip - II varijanta

Nadtip i podtip - III varijanta

Nadtip i podtip - IV varijanta

Ekskluzivna veza

Crtica na relaciji

Rekurzivna veza

Surograt kljuc

Vie prema vie veza

Presecni ent.

Denormalizacija
Normalizacija
Uklanja redundansu podataka Garantuje integritet podataka uva prostor

Denormalizacija
Uvodi redundansu Ispravlja performanse upita

Kada se definie denormalizovana kolona ona mora da se dobro dokumentuje

Server model

Primena Oracle CASE alata

Literatura
Designer/2000 R2: Server Design and Generation, Oracle Education Designer/2000:First Class, Oracle Education Designer/2000 R2: System Modeling, Oracle Education UML za projektovanje baza podataka, Eric J. Naiburg, Roberta A. Maksimchuk, CET Sistem analiza I modeliranje podataka, Mile Pavi, Nauna knjiga Korienje CASE alata u razvoju IS, skripte, FON Proireni model objekti veze, skripte, FON, Beograd 1997

UML profil za Projektovanje baze podataka

Uvod
UML profil slui za projektovanje baze podataka -> dijagram baze podataka (Sinonimi: server model, fiziki model) UML notacija omoguava da na dijagramu vizuelno obuhvatimo mnogo vie stavki nego pomou tradicionalne ER notacije Moemo da modelujemo domene, interne procedure, ogranienja, tabele, kolone , relacije

Elementi dijagrama
Element Tabela (table) Primarni klju (Primary key) Strani klju (Foreign key) Relacija sa identifikacijom (Identifying relationship) Relacija bez identifikacije (Non identifying relationship) View Memorisana procedura (Stored procedure) Domen (Domain) <<Identifying>> <<Non Identifying>> <<View>> <<SP>> <<SP Container>> <<Domain>> Stereotip <<Table>> PK FK
0..* 1

Ikona

1..*

Elementi tabela i kolona


Element Klju (key) Provera (Check) Jedinstveni (Unique) Index (Index) Tip podatka (Datatype) Tanost (precision) Tanost skale (Scale) Duina (lenght) Nula (NULL) Vlasnik (Owner) Komentar (Comment) Identitet (Identity) Maks doyv broj cifara za pojed num pod Broj cifara u decimalnom delu Maksimalni doyvoljeni broj slova za pojedinani znakovni podatak Kolona koja ne mora obavezno da sadrzi podatke Tvorac baze podataka Opis baze podataka Kolona za primarni kljuc Stereotip <<PK>> <<FK>> <<Check>> <<Unique >> <<Index >> Napomena Ogranienje kljueva Ogranienje provere Ogranienje jedinstvenosti Operacija na tabeli

Server model
< < Vie w > > K lije n t P o ru d zb in a < < D e rive d > >

< < D e ri ve d > > < < id e n tifyin g > > + is p o s ta vlje n a o d 1 ..n P o ru d zb in a < < P K > > b ro jP o r : In te g e r < < P F K > > b ro jK lij : In te g e r o p is : S trin g < < N o n Id e n tifyin g > > + is p o s ta vlja + k u pu j e o d 1 0 ..n lije n t K < < P K > > b ro jK lij : In te g e r < < F K > > b ro jZ a p : S trin g Im e : S trin g < < P K > > p k _ k lije n t2 () < < F K > > fk _ k lije n t3 () < < C h e c k > > s ta n je () < < T rig g e r> > p o b u d _ k lije n t() < < U n iq u e > > T C _ k lije n t1 3 () < < In d e x> > im e k lije n ta ()

+ p ro d a je

0 ..1 Z a p o s le n i < < P K > > P K b ro jZ a p : In te g e r im e Ip re zim e : S trin g < < S P C o n ta in e r> > P ra vila p o ru d zb in e < < S P > > p o ru d z_ s ta n je ()

Realizovanje fizikih aspekata baze podataka

Uvod
Veliina baze podataka Smetanje baze podataka
Hardverski Softverski

Particionisanje podataka Specifina svojstva izabranog DBMSa Komuniciranje aplikacije sa bazom podataka

Kreiranje objekata baze


Pomou generatora server modela dobijamo naredbe u DDL (Data Definition Language) za
Kreiranje Kreiranje Kreiranje Kreiranje tabela ogranienja sekvenci indeksa

Literatura
Eric J. Naiburg, Robert A. MaksimChuk, UML za projektovanje baza podataka, CET

You might also like