Lekcija 01: IT350 - Baze Podataka

IT350 - Baze podataka
Lekcija 01
O S N O V E B A Z E P O D ATA K A
Metropolitan
PRIRUČNIK ZA STUDENTE
Copyright © 2010 – UNIVERZITET METROPOLITAN, Beograd. Sva prava
zadržana. Bez prethodne pismene dozvole od strane Univerziteta
METROPOLITAN zabranjena je reprodukcija, transfer, distribucija ili
memorisanje nekog dela ili čitavih sadržaja ovog dokumenta.,
kopiranjem, snimanjem, elektronskim putem, skeniranjem ili na bilo koji
drugi način.
Copyright © 2010 BELGRADE METROPOLITAN UNIVERSITY. All rights

reserved. No part of this publication may be reproduced, stored in a
retrieval system or transmitted in any form or by any means, electronic,
mechanical, photocopying, recording, scanning or otherwise, without the
prior written permission of Belgrade Metropolitan University.
IT350 - Baze podataka
Lekcija 01
OSNOVE BAZE PODATAKA

Osnove baze podataka
Poglavlje 1: Potreba za čuvanjem podataka
Poglavlje 2: Cuvanje podataka u fajlovima
Poglavlje 3: Cuvanje podataka u BP
Poglavlje 4: Dizajn relacionih BP
Poglavlje 5: Objektno-orjentisane baze podataka (eng.
ORDBMS)
Poglavlje 6: Vežba:Sybase PowerDesigner
Poglavlje 7: Domaći zadatak
Zaključak
Lekcija 01: Osnove baze podataka
°°°°° Osnove baze podataka
UVOD
Šta ćemo naučiti u ovoj lekciji?
Od autora do autora, od knjige do knjige, od materijala do materijala,

naročito sa vremenskim distancama, primetna je raznolikost i evolucija
pojma baze podataka.
Za početak se treba saglasiti da baze podataka nisu ograničene samo na

sisteme koji se zasnivaju na računarima – one su mnogo više od toga.
Ovo uopštavanje stvara osnove da (kasnije) svaku kolekciju koja sadrži
podatke tretiramo kao bazu podataka.
Baza podataka je velika kolekcija podataka posebno organizovanih za

brzo pretraživanje i prihvat.
‘Ormari sa dokumentacijom u kancelariji su neka vrsta baze podataka. U
suštini baze podataka su se pojavile sa osvitom civilizacije – Sumerske
pločice, Aleksandrijska biblioteka i druge. Sa druge strane postoji sasvim
opravdan razlog zbog čega se BP vezuju za računare. Bazama podataka
na računarima se najefikasnije upravlja. Šta više termin «baza
podataka» je i nastao u računarskom okruženju negde oko 1962.
godine
4
Poglavlje 1: Potreba za čuvanjem podataka
Poglavlje 1 Potreba za čuvanjem

podataka
ZAŠTO TRAJNO ČUVATI PODATKE?
Da bi im se pristupilo i pošto programi završe sa svojim

izvršenjem
Mnoge aplikacije imaju potrebu da između dva sukcesivna izvršenja

programa podatke trajno sačuvaju. U slučaju informacionih sistema,
trajno pamćenje podataka predstavlja primarni zahtev. Poslovne i druge
organizacije svoje informacione sisteme zasnivaju na slogovima
podataka o drugim organizacijama, ljudima i fizičkim objektima i
transakcijama. Podaci koji se u informacioni sistem unesu danas, se
mogu upotrebiti u budućnosti; transakcije koje se u sistemu trenutno
izvršavaju, se mogu odnositi na podatke koji su bili zapamćeni u
prošlosti.Podaci koji se trenutno nalaze u operativnoj memoriji nekog
računara, kao što je poznato nisu dostupni većem broju korisnika. Ukoliko
veći broj korisnika treba da pristupi tim podacima, oni moraju biti
sačuvani na nakoj vrsti deljivog sistema za pamćenje podataka tako da
ih korisnici mogu pretraživati i pristupati im kad god je to potrebnio. To je
ono što se naziva trajnim čuvanjem podataka.
.
Podaci se trajno čuvaju na sekundarnim memorijama, tako da im se može
pristupiti i pošto programi završe sa svojim izvršenjem.
Trajni podaci mogu biti zapamćeni u datotekama ili bazama podataka.

Korišćenjem sistema za upravljanje bazama podataka (DBMS) ima niz
prednosti nad datotekama
KAKO KRAJNJI KORISNIK VIDI PODATKE

SAČUVANE U BAZAMA PODATAKA?
Ako su bazene relacione, vidi tabele koje sadrže

podatke, a ako su objektno orijentisane, vidi objekte i
5
veze između njih; Korisnika ne vidi da su podaci

zapamćeni u file-ovima
U principu, svi podaci se u računarima pamte u nekoj vrsti datoteka (file-

ova).
Međutim, sistema za upravljanje bazama podataka obezbeđuju jedan sloj

apstrakcije koji od korisnika skriva činjenicu da su podaci zapamćeni u
file-ovima.Ako je baza podataka relaciona, tada korisnik baze podatake
vidi tabele koje sadrže podatke. Svaka tabela mo že da se odnosi na deo
file-a, jedan file ili više file-ovaali to nije značajno za korisnika relacione
baze podataka (koji može biti dizajner ili programer). Način na koji baza
podataka pamti tabele u file-ovima je važan samo za administratora
baze podataka koji mora da zna gde su podaci zapamćeni, pravi back-up
podataka itd.
Ako je baza podataka objektna, tada korisnik vidi objekte i veze između
njih. I objekti se pamte u nekoj vrsti file-ova, ali dizajner ili programer
ne mora da zna te detalje. U objektno orijentisanim sistemima, baza
podataka je najčešći način za trajno čuvanje objekata. Međutim moguće
je objekte pamtiti i u file-ovima. Mnogi objektno orijentisani jezici
obezbeđuju mehanizme za konverziju objekata u formu koja može biti
zapisana u file i za njihovo čitanje nazad iz memorije u file.
Izbor sistema za upravljanje bazom podataka ima značajan uticaj na

rad dizajnera sistema. Ako se koristi objektna baza podataka, tada je
za dizajniranje načina na koji se objekti pamte, potrebno veoma malo
napora. Ako se koristi relaciona baza podataka, potrebno je mnogo
više rada.
6
Poglavlje 2 Cuvanje podataka u

fajlovima
ČUVANJE PODATAKA U FAJLOVIMA
File je podeljen na individualne slogove od kojih svaki

predstavlja grupu izvesnog broja polja u kojima su
smešteni podaci; Slogovi mogu imati različite forme
Najjednostavniji način za trajno čuvanje podataka u računarskim

informacionim sistemima je korišćenje file-ova. Mnogo korisnici
personalnih računara su familijarni s idejom i file-ovima. Word-procesori
na primer svoje podatke pamte u file-ovima; browser-i ih download-
uju sa web site-ova i takođe čuvaju u fajlovima. Na najnižem nivou,
file predstavlja niz bajtova zapamćenih podataka na nekom fizičkom
medijumu.
Programski jezici i u nekim slučajevima operativni sistemi, takođe koriste

strukture file-ova. U ovakvoj strukturi, file je podeljen na individualne
slogove od kojih svaki predstavlja grupu izvesnog broja polja koji
predstavljaju podatke koje treba zapamtiti u file-u. Na isti način kao što
svaki objekat sadrži određeni broj atributa, od kojih svaki sadrži određenu
vrstu podataka o tom objektu, svako polje u slogu sadrži određenu vrstu
podataka kojim se opisuje slog.
Slogovi u datoteci mogu imati različite forme:
• Slogovi fiksne dužine: svaki slog se satoji od više polja, od kojih

svako polje ima fiksnu dužinu u bajtovima. Svaki slog je iste, fiksne
dužine a s predhodong na sledeći slog je moguće
doći preskakanjem fiksnog broja bajtova
• Slogovi promenljive dužine – svaki slog se sastoji od izvesnog broja

polja od kojih svako može imati maksimalnu dužinu ali i minimalnu
dužinu od nula bajtova. Polja su često raudvojena delimiterima ili
specijalnim karakterima. Dužina svakog sloga može biti zapamćena
na početki sloga, pa se na početak sledećeg sloga može doći
preskakanjem navedenog broja karaktera.
• Zaglavlja i detalji – postoje dve vrste slogova: svaki slog transakcije
se sastoji od sloga zaglavlja koji je praćen izvesnim brojem slogova
detalja. Ovaj pristup se može koristiti u mnogim poslovnim
7
dokumentima kao što su porudžbenice, fakture. U svakom slogu je

zapamćen tip sloga. Broj slogova detalja se može pamtiti u zaglavlju
tako da je moguće reći gde počinje sledeći slog zaglavlja.
• Tagovani podaci – podaci mogu imati složenu strukturu, kao što su
na primer objektno orijentisani sistemi – i ponekad je neophodno
objekte različitih klasa pamtiti u istom file-u. Svaki objekat i atribut
može imati tag koji je opisan i na neki način saopštava programeru
koji čita file o kakvom se podatku radi. Ovaj pristup se koristi za
podatke u file-ovima koji koriste HTML i XML.
KAKO FAJOVI MOGU BITI

ORGANIZOVANI?
Serijski, sekvencijalno i random
Postoje tri načina na koji file-ovi mogu biti organizovani: serijski,

sekvencijalni i random:
• Serijska organizacija: Svaki sledeći slog u file-u se upisuje na kraj

predhodnog sloga. Ako se slog izbriše, file mora biti kopiran od
početka do izbrisanog sloga, koji se preskače, a tada se kopira i
ostatak file-a.
• Sekvencijalna organizacija: U osnovnoj formi sekvencijalne
organizacije, svaki slog se upisuje u file po nekom predefinisanom
redosledu, koji se najčešće bazira na vrednosti jednog polja u slogu,
kao što je na primer broj fakture. Slogovi se brišu na isti način
kao kod serijskih file-ova. Svaki slog mora biti dodat file-u na svoje
odgovarjuće mesto, i ako je neophodno uneti novi slog u file, file se
kopira do tačke gde je slog insertovan, novi slog se upisuje u file i
tada se kopira ostatak file-a.
• Random organizacija: Termin random je loš način da se opiše
organizacija random file-ova, jer je organizacija u istinu bilo šta
drugo a ne random. Slogovi se dodaju u file korišćenjem preciznog
algoritma koji dozvoljva da se slogovi upisuju i čitaju direktno bez
obaveze da se čita ostatak file-a. To znači da ako ste vi izabrali
bilo koji slog random, moguće je da njemu pristupite manje ili više
direktno ne prolazeci kroz ostatak file-a. Algoritam obično konvertuje
polje ključa svakog sloga u adresu file-a kojoj se može direktno
pristupiti.
Kod serijske organizacije se svaki sledeći slog u file-u se upisuje na

kraj predhodnog sloga. U sekvencijalnoj otganizaciji se svaki slog
upisuje u file po nekom predefinisanom redosledu, koji se najčešće
bazira na vrednosti ključa u slogu. Kod random organizacije , slogovi
8
se dodaju u file korišćenjem preciznog algoritma koji dozvoljva da se

slogovi upisuju i čitaju direktno bez obaveze da se čita ostatak file-a
SERIJSKI I DIREKTAN PRISTUP PODACIMA
Serijski pristup podrazumeva čitanje fajlova slog po

slog; Kod direktnog pristupa se koristi algoritam za
konverziju vrednosti ključa u adresu sloga
Zavisno od izabrane organizacije file-ova, postoje različiti načini za

pristup podacima u file-ovima: serijski, indeks-sekvencijalni i direktan:
• Serijski pristup: Serijski se može pristupiti serijskim i sekvencijalnim

file-ovima. Da bi se pronašao određeni slog, neophodno je čitati file
slog po slog sve dok se određeni slog ne locira.
• Direktan pristup: metoda direktnog pristupa se zasniva na korišćenju
algoritama za konverziju vrednosti polja ključa u adresu sloga u file-
u.
Prva i najjednostavnija od njih je relativna adresa. Ovaj metod pristupa

zahteva korišćenje slogova fiksne dužine i pozitivne sukcesivne vrednosti
ključeva. Ako je svaki slog dugačak 200 bajtova, tada će prvi slog početi
na prvom bajtu, drugi na bajtu 201, treći na bajtu 301 itd.
Drugi mogući pristup je hashing adresiranje. Gde se mogu koristiti

ključevi u bilo kojoj formi. Kao i kod indeks sekvencijalnih file-ova, file-u
se dodeljuje fiksan broj blokova. Tada, da bi se odredilo kojem će se bloku
dodeliti dati slog, vrši se heširanje ključa. Funkcija heširanja je algoritam
koja uzima ASCII string i konvertuje ga u intedžer. Postoji više pristupa.
Najjednostavniji
pristup je uzeti karaktere u stringu i konvertovati ih u njihove ASCII
vrednosti (na primer A je 65). Te ASCII vrednosti se sumiraju i suma
podeli sa brojem blokova u file-u. Ostatak deljenja daje broj bloka u file-u
u kojem treba staviti slog, počevši od bloka 0. Ako je taj blok pun, koristi
se dodadtni blok kao overflow a njegova adresa se čuva u bloku u kojem
je slog trebalo da bude zapamćen. Slika 1. prikazuje organizaciju file sa
direktnim hashing pristupom.
9
Slika 2.1 Organizacija

direktnog pristupa file-u
putem hešinga
INDEKS-SEKVENCIJALNI PRISTUP
PODACIMA
Pronalaženje sloga se vrši sekvencijalnim

pretraživanjem područja indeksa, dok se ne nađe
traženi ključ, a zatim se na osnovu adrese ključa
direktno pristupa traženom slogu
Pristup sekvencijalnim file-ovima se može unaprediti održavanjem

indeksa nad poljem koje se koristi za uređivanje podataka u file-u (polje
ključa). Indeks sekvencijalni file-ovi se koriste tamo gde je neophodno
čitati file sekvencijalno, slog po slog, i korišćenjem ključa otići pravo
do određenog sloga. Mehanizam indeksiranja koji se koristi u indeks
sekvencijalnim file-ovima nas vraća u vreme mainframe operativnih
sistem.
U ovakvom pristupu se izdvajaju tri područja podataka:
• Glavo područje u koje se upisuju slogovi prilikom unosa ili

ažuriranja slogova.
• Područje indeksa koje obično formira operativni sistem prilikom
unosa ili ažuriranja slogiva
10
• Prelazno područje koje služi da se u njega smeste slogovi koji

ispadaju iz glavog područja zbog ubacivanja novih slogova.
Pronalaženje nekog sloga se vrši sekvencijalnim pretraživanjem područja

indeksa, dok se ne nađe traženi ključ, a zatim se na osnovu adrese koja
odgovara nađenom ključu brzo pronalazi traženi slog. Vreme potrebno za
pronalaženje slogova se uglavnom troši na sekvencijalno pretraživanje
područja indeksa.
Da bi se podržali veliki file-ovi potrebno je imati dva ili više nivoa indeksa.
Na primer može postajati master indeks i serija blok indeksa. U master
indeksu se čuvaju vrednosti polja ključa zadnjeg sloga u svakom blok
indeksu. Svaki blok indeksa čuva polja ključa u zadnjem slogu svakog
bloka iz skupa blokova. Da bi se pronašao slog po njegovom ključu,
master indeks se čita sve dok se ne pronađe vrednost ključa koja je veća
ili jednaka ključu sloga koji se traži. To omogućava da se ode do bloka
u kojem je sačuvan slog. Slogovi u bloku se nadalje čitaju sekvencijalno,
sve dok se ne pronađe željeni slog. Sličan pristup se koristi i za dodavanje
slogova indeks sekvencijalnim file-ovima. Slika 2. prikazuje organizaciju
podataka i indeksa u indeks sekvencijalnim file-ovima.
Slika 2.2 Šematski prikaz
indeksa i podataka u indeks-
sekvencijalnom file-u koji je
uređen po imenu
PROBLEMI ČUVANJA PODATAKA U

FAJLOVIMA?
Redudantnost podataka, nemogućnost njihovog

sinhronizovanog ažuriranja, zavisnost programskog
koda od organizacije fajlova
11
Čuvanje podataka u file-ovima može da stvori mnogo problema:
• Kako broj aplikacija raste, raste i broj različitih file-ova. Neki od

tih file-ova mogu da sadrže iste podatake za različite aplikacije u
različitim formama. Na taj način se podaci dupliraju, zauzimajući
bezpotrebno prostor na diskovima. To je poznato kao redudantnost
podataka.
• Postoji rizik da ažuriranje podataka u različitim aplikacijama neće
biti sinhronizovano.Na primer, adresa kupca se može promeniti u
jednom file-u ali ne i u drugom što podatke može učiniti
nekonzistentnim.
• Svaka aplikacija mora da sadrži svoje sopstvene mehanizme za
čuvanje podataka u svom skupu file-ova, iukoliko se podaci promene
ili se promei način na koji su oni zapamćeni, tada svaki program
u okviru aplikacije koji pristupa tim podacima mora biti prilagođen
izmenama. Zbog toga je dodavanje novih programa aplikaciji koja
koristi isti podatke ali istovremeno zahteva i čuvanje dodatnih
podataka veoma teško.
• Prilagođavajući se promenama poslovnih zahteva, korisnici mogu

želeti da podacima pristupe na novi način, na primer pravljenjem
izveštaja u kojem se kombinuju podaci iz različitih aplikacija. To se
ne može implementirati bez značajnih napora programera.
Prvi korak u rešavanju ovih problema je analizirati zahteve za

pamćenjem podataka različitih aplikacija u okviru organizacije i
napraviti korporativnu bazu podataka koja će sadržati podatake iz
različitih aplikacija.
12
Poglavlje 3 Cuvanje podataka u BP
NA ČEMU SE ZASNIVA SISTEM ZA

UPRAVLJANJE BAZOM PODATAKA (ENG.
DATA BASE MANAGEMENT SYSTEM -
DBMS)
Na Tri-šeme arhitekturi koja omogućava da se način

fizičkog čuvanja podataka razdvoji od načina na koji se
oni koriste u aplikativnim programima
Baze podataka su nastale u pokušaju da se reše problemi sa čuvanjem

podataka u fajl sistemima.
Prvi korak u rešavanju ovih problema je analizirati zahteve za pamćenjem

podataka različitih aplikacija u okviru organizacije i napraviti
korporativnu bazu podataka koja će sadržati podatake iz različitih
aplikacija. Svaka aplikacija tada za zadovoljenje svojih zahteva koristi
podskup podataka iz zajedničke baze.
Drugi korak je iskoristiti sistem za upravljanje bazom podataka koji će

omogućiti da se podaci organizuju i njima upravlja tako da se mehanizmi
za pamćenje podataka razdvoje od aplikativnih programa.Cilj korišćenja
sistema za upravljanje bazom podataka je razdvojiti detalje o načinu na
koji se podaci fizički pamte od načina na koji se oni koriste u aplikativnim
programima. To se postize pravljenjem logičkog modela podataka koji je
nezavistan od zahteva aplikacije i koji se u bazi podataka može čuvati na
različite načine.
Danas je najčešće u upotrebi Tri-šeme arhitektura koja je prikazana na

slici 1.
13
Slika 3.1.1 Arhitektura tri-

šeme
Eksterna šema predstavlja način na koji se podaci koriste u aplikativnim

programima.
Konceptualna šema je logički model podataka i nezavisna je i od eksterne

šeme i od detalja o tome kako se podaci pamte.
Fizička organizacija podataka se nalazi u internoj šemi, kom se definišu

file-ovi za pamćenje podataka. Cilj ovog pristupa je izolovati aplikativne
programe od detalja o tome kako je zapamćena bilo koja stavka
podataka. To je osnovno za način na koji radi Sistem za upravljanje
bazom podataka (DBMS).
ŠTA OBEZBEĐUJE DBMS?
Alate koji se mogu koristiti za upravljanje podacima kao

što su: DDL, DML, upravljanje transakcijama, rešavanje
konkuretnosti, oraničenje itegriteta itd.
DBMS obezbeđuje više od samog načina za pamćenje podataka koje

mogu da koriste više aplikacija. On obezbeđuje alate koji se mogu
koristiti za upravljanje podacima.
• Data definition laguage (DDL): se koristi za specifikaciju podataka

koji se drže u sistemu za upravljanje bazom podataka i za strukture
koje se koriste za njihovo čuvanje
• Data manipulation language (DML): se koristi da bi se specificirale
ažuriranja i pretraživanja podataka u DBMS.
• Ograničenja integriteta: se specificiraju da bi se održao integritet
podataka
14
• Upravljanje transakcijama: Ažuriranja nad bazama podataka se

specificiraju kao transakcije u okviru kojih se moraju izvršiti sve
komponente ažuriranja jer se u suprotnom mora izvršiti roll back
transakcije, što znači da se ona neće trajno zapamtiti u bazi
podataka (izvršiti commit transakcije).
• Konkurentnost: Više korisnika može da simultano koristi bazu
podataka i ažurira njen sadržaj.
• Zaštita: pristup podacima u bazi podataka i dozvole koje su
dodeljene različitim korisnicima za različite nivoe pristupa (na primer
select, update, delete može biti kontrolisan)
Ove strukture će u internoj šemi biti predstavljene korišćenjem file-

ova. Značajna karakteristika DBMS-a je da vrste file-ova koje se koriste,
metodi pristupa i indeksi koje koriste file-ovi su u DBMS sakriveni od
korisnika (obično aplikativnih programera) i mogu se menjati bez uticaja
na programe koji koriste te podatake.
Te promene u bazi podataka se ne dešavaju automatski. Za velike

sisteme, mora se uposliti administrator baze podataka koji će upravljati
bazom podataka i obezbediti da ona efikasno radi. DBA će biti odgovoran
za kontrolisanje rečnika podataka koji definiše konceptuialnu šemu baze
podataka, za kontrolisani pristup podacima i za podešavanje performansi
baze podataka.
Za male sisteme, DBA nije neophodan, ali neko mora biti odgovoran za
upravljanje bazom podataka.
Korišćenje DBMS-a koje se zasniva na Arhitekturi tri šeme ima mnogo

prednosti nad korišćenjem file-ova za čuvanje podataka u
informacionom sistemu.
KOJI SU NEDOSTACI KORIŠĆENJA DBMS-

A?
Njihovo korišćenje iziskuje veliku količinu novca i

stručno osoblje koje je takođe skopčano s mnogo
troškova
Međutim, postoje i neki nedostaci korišćenja DBMS-a:
• Za investiranje u velike DBMS sisteme je potrebno mnogo novca

• Zapošljavanje osoblja koje će upravljati DBMS-om je takođe
skopčano s mnogo troškova
15
• Postupci konverzije podataka iz baze podataka u formate koje

zahtevaju aplikativni programi mogu biti složeni
3.1 PREGLED DBMS
KOMPONENTE DBMS
Na početku se mogu razdvojiti dve različite vrste

komandi DBMS-a: za obične korisnike i administratore
Na slici 1.1. data je potpuna šema DBMS-a. Kvadratima su predstavljene

komponente sistema, duplim kvadratima su predstavljene unutar
memorijske strukture podataka, punim linijama je predstavljena kontrola
unutar sistema i tok podataka u sistemu dok je isprekidanim linijama
predstavljen samo tok podataka.
Dijagram DBMS-a se na osnovu šeme sa slike 1. može raščlaniti na
nekoliko nivoa. Prvo, na vrhu se izdvajaju dve različite vrste komandi
DBMS-a:
1. Obični korisnici i aplikativni programi: koji samo pristupaju ili menjaju
podatke u bazi podataka
2. Administratori baze podataka: osobe koje su odgovorne za strukturu i
šemu baze podataka.
16
Slika 3.2.1 Komponente

DBMS
DATA-DEFINITION JEZIK (DDL)
DDL komande predstavljaju komande koje su

jednostavnija za obradu i izvršavaju ih administratori
sistema
17

DBMS
Druga vrsta komandi, DDL komande predstavljaju komande koje su

jednostavnija za obradu, i prikazane su u gornjem desnom uglu slike
1. Na primer administrator baze podataka DDL komandama za bazu
podataka univerziteta kreira tabele za studente, smerove i kurseve koje
student pohađa i ocene na kursevima, takođe ovim komandama on može
da ograniči da studenti jedino mogu da dobiju ocene 5, 6, 7, 8, 9 ili 10.
Ova struktura i ograničenja su delovi šeme baze podataka.
Na slici 1. je takođe prikazano da za izvršenje komandi kojim se menja
struktura baze podataka trebaju specijalna ovlašćenja, i uglavnom
ovakve komande izvršavaju administratori baza podataka, jer izmene
nastale ovim komandama mogu da imaju veoma veliki uticaj na samu
bazu i podatke. Komande DDL-a se parsiraju kroz DDL procesor i
izvršavaju na execution engine-u koji kroz index/file/record menadžer
dodaje meta podatke kako bi se dobila šema informacija unutar baze
podataka.
18
PROCESOR UPITA (ENG. QUERY PROCESSING)
Korisnik ili aplikativni program pokreće neki upit,

koristeći jezik za upravljanje podacima (eng. data-
manipulation language (DML)

DBMS
Korisnik ili aplikativni program pokreće neku akciju, koristeći jezik za

upravljanje podacima (eng. data-manipulation language (DML)). Ovakve
komande ne menjaju strukturu baze podataka već samo menjaju sadržaj
podataka unutar same baza (ukoliko je upit za izmenu podataka) ili
samo prikazuju podatke iz baze (ukoliko je upit za prikaz podataka. DML
komande se izvršavaju na sledećim podsistemima.
Upit se izvršava na sledeći način:Upit se prvo parsira i optimizuje u
kompajleru upita. Rezultat ovoga je plan izvršenja upita odnosno koraci
koje DBMS treba da preuzme kako bi izvršio upit, i koji se predaje
19
execution engine-u. Execution engine izdaje niz zahteva menadžeru

skladišta za zapise podataka ili torke relacija. Menadžer skladišta sadrži
podatke o skladištenim podacima, veličini podataka i indeksima, kako bi
ih što brže našao i kako bi se upit izvršio brže.
Zahtev za dostavljanje podataka se predaje menadžeru bafera. Zadatak
menadžera bafera je da dostavi podatke iz sekundarnog skladišta gde su
oni trajno sačuvani (disk) trenutnoj memoriji bafera. Jedinica podataka
koja se razmenjuje između bafera i diska je “disk blok”.
Izvršavanje transakcija: Upiti i ostale DML akcije su grupisane u
transakcije, koje moraju da budu izvršene atomično i izolovane jedna od
druge. Svaki upit ili bilo koja akcija modifikacije može biti transakcija.
Svaka transakcija mora da bude trajna što znači da i ukoliko sistem
padne odmah nakon izvršenja transakcije posledice izvršenja transakcije
moraju da budu vidljive. Izvršavanje transakcija možemo podeliti na dva
dela:
1. Menadžer paralelnog rada, ili raspoređivač, koji obezbeđuje
atomičnost i integritet transakcija, i
2. Sistem za logovanje i oporavak transakcija, koji je zadužen za trajno
izvršenje istih.
MENADŽER SKLADIŠTA I BAFERA (ENG. STORAGE

AND BUFFER MANAGEMEN)
Menadžer skladišta vodi evidenciju lokacija svakog fajla

na disku kako bi lakše izvršio naredbe menadžera
bafera
20

DBMS
U bazama podataka podaci se uglavnom skladište na sekundarno

skladište, koje je u današnje vreme hard disk. Kako god, da bi se izvršila
neka izmena podataka, podaci moraju biti smešteni u glavnu memoriju.
Posao menadžera skladišta je da upravlja podacima između glavne
memorije i sekundarnog skladišta.
U jednostavnim sistemima za upravljanje menadžer skladišta ne mora

biti ništa drugo već file sistem operativnog sistema, ali iz razloga
povećanja efikasnosti DBMS upravlja podacima direktno na disku.
Menadžer skladišta vodi evidenciju lokacija svakog fajla na disku kako bi
lakše izvršio naredbe menadžera bafera.
Menadžer bafera je odgovoran za deljenje skladišta glavne memorije u
bafere, koji su veličine bloka diska koji se prenose između diska i bafera.
Tako da sve komponente DBMS-a koje koriste informacije sa diska će
vršiti interakciju sa menadžerom bafera, bilo direktno ili preko execution
engine-a.
21
OBRADA TRANSAKCIJA
Transakcija predstavlja jedinicu posla koja mora biti

izvršena atomično i potpuno izolovana od drugih
transakcija, a DBMS obezbeđuje da će rezultat izvršene
transakcije biti sač
Slika 3.2.5 Komponenete

DBMS
U praksi je uobičajeno da se nekoliko operacija nad bazom podataka

grupišu u transakciju, koja predstavlja jedinicu posla koja mora biti
izvršena atomično i potpuno izolovana od drugih transakcija, a DBMS
obezbeđuje da će rezultat izvršene transakcije biti sačuvan u potpunosti.
Menadžer transakcija dobija transakcione komande od aplikativnih
programa, koje određuju početak i kraj samih transakcija kao i kroz
22
koje se određuju određeni izuzeci. Uloga procesora transakcija je da vrši

sledeće operacije:
1. Logovanja: kako bi se obezbedila dugotrajnost same baze podataka
svaka promena koja je nastala nad njom se beleži u poseban fajl na disku.
Menadžer logovanja je dizajniran tako da bude otporan na bilo kakve
prekide ili pad sistema, i da na osnovu log fajla bude omogućen povratak
baze podataka u konzistentno stanje. Menadžer logovanja uglavnom vrši
logovanja na mestima gde do pada sistema najčešće dolazi, a to je
uglavnom u baferima, jer mora da bude siguran da je svaki podatak iz
bafera uspešno upisan na disk.
2. Kontrola paralelnog rada: Transakcija se mora izolovano izvršiti, ali

će se u mnogim sistemima više transakcija izvršavati istovremeno.
Menadžer paralelnog rada mora da obezbedi da svaka akcija iz više
transakcija izvrši do kraja, samo jedna u istom trenutku nad jednim
entitetom, i ovo se uglavnom postiže zaključavanje nekih delova baze
u toku njenog izvršenja, odnosno zabranjivanjem drugim transakcija da
koriste entitet u okviru kog se izvršava trenutna akcija određene
transakcije.
3. Blokada transakcija: kako se transakcije međusobno nadmeću za

resurse kako bi bile izvršene, može se doći u situaciju da svakoj treba
neki resurs koji druga transakcija trenutno drži zaključanim odnosno
trenutno u menadžeru stoje transakcije blokirane jer su ostale zaključale
neke delove baze, pa se jer na red dolaze druge transakcije kojima
će možda trebati resursi koji nisu trenutno zaključani od strane drugih
transakcija.
PROCESOR UPITA (ENG. QUERY PROCESSOR)
Sastoji se od dve komponente: kompajlera upita i

execution engine
Deo DBMS-a koji najviše utiče na performanse sistema koje korisnici

najčešće vide je procesor upita. Na slici 1. on je predstavljen od dve
komponente:
1. Kompajler upita, koji prevodi upit u internu formu nazvanu plan upita,
odnosno niz akcija koje treba izvršiti nad podacima. U planu upita
operacije se najčešće zasnivaju na relacionoj algebri. Kompajler upita se
sastoji iz sledećih delova:
a) Parser upita – koji pravi stablastu strukturu od tekstualne forme upita,
b) Procesor upita – koji izvršava semantičku proveru upita (pr. da li
sve relacije naznačene u upitu postoje) i vrši transformaciju stablaste
strukture u stablastu strukturu algebarskih operacija koji predstavljaju
polazni plan upita
c) Optimizer upita – koji transformiše inicijalni plan upita u najbolji
mogući niz operacija koji se izvršava nad podacima.
23
Kompajler upita koristi meta podatke i statističku analizu podataka kako

bi odredio koji segment operacija je najbrži. Na primer, prisustvo indeksa,
strukture koja olakšava pristup podacima, jedan plan može učiniti mnogo
bržim za izvršenje od onog koji ne poseduje indeks.
2. Execution engine: je odgovoran za izvršenje svakog koraka
definisanim planom upita. On vrši interakciju sa većinom drugih
komponenti DBMS-a, bilo direktno ili preko bafera. Execution engine
mora da dovede podatke u bafer kako bi se manipulisalo njima, takođe,
vrši i interakciju sa menadžerom raspoređivanja kako bi se izbegao
pristup podacima koji su zaključani i sa log menadžerom kako bi se vršilo
logovanje svih promena nastalih nad bazom.
DBMS
24
3.2 RELACIONE BAZE PODATAKA

(ENG. RDBMS)
KARAKTERISTIKE
Podaci su sačuvani uz minimalnu redudantnost i

programi koji koriste te podatke ne zavise od načina
njihovog pamćenja
Relaciona baza podataka se može definisati kao celokupnost međusobno

povezanih podataka uskladištenih u spoljnoj memoriji računara uz
minimalnu redudansu(suvišna zavisnost), koja dozvoljava njihovo
korišćenje od strane jedne ili više aplikacija.Podaci se "pamte" tako da
budu nezavisni od programa koji koriste te podatke u smislu dodavanja
novih ili modifikacije postojećih a takođe i radi pretraživanja podataka.
Podaci su istovremeno dostupni raznim korisnicima i aplikativnim
programima. Ubacivanje, promena, brisanje i čitanje podataka obavljaju
se posredstvom zajedničkog softvera. Korisnici i aplikacije ne moraju
poznavati detalje fizičkog prikaza podataka, već se referenciraju na
logičku strukturu baze.
BP se ponekad definiše kao neredundantna celokupnost podataka.Ipak
u stvarnosti radi skraćenja vremena pristupa podacima ili
pojednostavljenja načina adresiranja redudantnost je prisutna na
određen način.Neki slogovi se ponavljaju da bi se obezbedila mogućnost
restauracije podataka kod slučajnih gubitaka. Da bi BP bila neredudantna
i zadovoljila druge zahteve treba ići na kompromis. U tom slučaju govori
se o upravljanoj ili minimalnoj redudansi, tako da je dobro projektovana
BP lišena suvišne redudanse. Jedna od dobrih strana baza podataka koje
reklamira IBM je da se administratori ili bilo koji službenik mogu obraćati
računarskom sistemu sa pitanjima koja nisu ranije predviđena.
OD ČEGA SE SATOJI RELACIONA BAZA PODATAKA?
Od podataka koji su smešteni u tabelama i relacijama

koje postoje između tabela
Relacionu bazu podataka sačinjavaju svi podaci sa kojim radimo,

smešteni u jednu ili više tabela. S lika 1. prikazuje bazu podataka sa
tri tabele: STUDENT koja sadrži podatke o studentima, GRADE (USPEH)
koja sadrži podatke o uspehu studenata i CLASS koja sadrži podatke o
predmetima koje studenti izučavaju.
Međutim, baza podataka na slici ne prikazuje samo podatke o

studentima, uspehu i predmetima već pokazuje i relacije koje postoje
među redovima tih tabela. N a primer, StudentNumber 400 ima ocenu
25
3.9 na predmetu 40 koji označava Acct101 i ocenu 3.5 na predmetu 50

koji označava predmet Acct102.
Slika za pravo prikazuje jednu veoma važnu karakteristiku baza

podataka: u njima se ne pamte samo podaci već i relacije među
podacima.
Teorijske osnove relacionog modela baze podataka su u relacionoj algebri

i matematičkoj specifikaciji operacija koje se mogu izvršavati nad
relacijama. Osnovni cilj relacionog modela je eliminisati redudantnost
podataka i obezbediti najjednostavniju moguću logičku prezentaciju
podataka. To se postiže
serijom koraka koji se mogu primeniti u analizi podataka s ciljem da se
dobiju tzv. normalizovani podaci koji se čuvaju u relacijama ili tabelma.
Ovim procesom se složena struktura podataka pojednostavljuje sve dok
se podaci ne mogu smestiti u seriju tabela. S vaka tabela se sastoji
od redova podataka a svaki red sadrži vrednosti atributa koje su
organizovane u kolone. Svaka kolana sadrži vrednost podataka istog tipa
atributa.
Slika 3.3.1 tabele relacione
baze podataka
RELACIONI MODEL-PRIMER
Kao pimer je prikazana tabela FILM
Kao što je rečeno, relacioni model baze podataka se bazira na tabelama,

čiji primer predstavlja slika 2. Ova relacija ili tabela opisuje filmove:
njihove nazive, godinu u kojoj su snimljeni, trajanje u minutima i žanr
filma. U ovoj tabeli smo prikazali tri filma, ali zamislite da u njoj postoji
red za svaki snimljeni film ikada.
Struktura relacionog modela se može uporediti sa nizom u jeziku C, gde

je zaglavlje tabele ekvivalentno nazivima polja, a svaki red jedan upis u
nizu. Kako god, mora se naglasiti da je ovo samo jedan od mogućnosti
26
fizičkog skladištenja podataka. U stvari, ovo čak i nije uobičajan način da

se predstavljaju relacije i veliki deo proučavanja baza podataka se bavi
kako pravilno implementirati tabele. Mnoge stvari potiču iz različitosti
relacija, jer uglavnom nisu implementirane kao glavne memorijske
struktura i njihova pravilna fizička implementacija potiče od toga kako su
podaci smešteni na samom disku.
Slika 3.3.2 Tabela FILM
Operacije koje se uglavnom povezane sa relacionim modelom su

orijentisane na tabele. Na primer možemo pretraživati vrednosti po
raznim kolonama, na primeru slike 2. možemo vršiti pretragu po žanru
“komedija”.
Kako u relacionom modelu možemo davati različita ograničenja, možemo
na primer dati ograničenje da žanr uzima vrednost iz nekog određenog
skupa podataka, a da trajanje svakog filma ne mora biti uneseno, ili pak
možemo zaključiti (pogrešno) da samo jedan film može imati jedno ime i
da ni jedan drugi film koji se nađe u tabeli ne može imati to ime
TABELE META PODATAKA
Opisuju tabele, kolone i ostale elemente baze podataka
Relaciona baza podataka pored tabela ko risničkih podataka sadrže i

tabele podataka koje opisuju te korisnike podataka. Ovi opisi se zovu
metapodaci jer su to podaci o podacima. Format i forma metapodataka
se razlikuje zavisno od DBMS-a. Slika 3 . prikazuje generičke tabele
metapodataka koja opisuje tabele i kolone baze podataka prikazane na
prethodnoj slici. M etapodaci se mogu pretraživati da bi se odredilo da li
neka tabela, k olona, indeks ili druga struktura pripadaju bazi podataka.
Da bi se iz baza podataka proizvodile različite vrste informacija koristi se

jezik koji se zove Structured Query Language (SQL).
Relacioni DBMS su trenutno najšire korišćeni DBMS-ovi. Najpoznatiji je

svakako Access a zatim Oracle, SQL-Server, DB2, Informix, Ingres,
Sybase, MySQL itd. Zato kada se govori o bazama podataka misli se na
relacione baze.
27
Slika 3.3.3 Tabele

metapodataka
PRIMER APLIKACIJE KOJA KORISTI RDBMS

(MICROSOFT ACCESS)
Korisnici su u interakciji sa bazom preko aplikacije koja

može da sadrži forme za unos podataka, da generiše
izveštaje ili postavlja upite
Slika 4 . može poslužiti kao primer za prikaz jedne jednostavne aplikacije

koja koristi Microsoft Access sistem za upravljanje bazom podataka.
Slika 3.3.4 Objektno-
orjentisana baza podataka
Korisnici su u interakciji sa aplikacijom kroz forme za unos podataka čiji

je jedan primer prikazan na slici 5 . Oni iz baze takodje traže različite
izveštaje i nad njom izvršavaju različite upite. Sve te zahteve korisnika
obrađuje sistem za upravljanje bazom podataka, u ovom slučaju Access.
28
Slika 3.3.5 za unos podataka

u RDBMS
KOMPONENTE RDBMS SISTEMA
Aplikacije, SQL i DBMS
Aplikacije su računarski programi sa kojima korisnici imaju direktnu

interakciju. Aplikacije prihvataju podatke od korisnika, obrađuju ih prema
zahtevima po kojima je aplikacija napravljena i koriste SQL za transfer
podataka prema i od baze podataka. U slučaju Access-a, aplikacije
kreiraju i obrađuju forme, izveštaje i upite. U drugim slučajevima,
aplikacije rade mnogo više.
Slika 6 . prikazuje šta se nalazi u okviru crne kutije koja je označena kao
Microsoft Access. Kao što se vidi, sistem za upravljanje bazom podatka
Access ima tri komponente: aplikacije, SQL i DBMS.
Slika 3.3.6 -RDSBMS ima tri
komponente: aplikacije, SQL i
DBMS.
SQL je internacionalni standardni jezik kojeg razumeju svi komercijalni

sistemi za upravljanje baza podataka. Kao što se vidi sa slike 4. Access
forme, izveštaji i upiti kreiraju SQL naredbe i prenose ih do DBMS gde se
obrađuju.
29
DBMS je veliki i komplikovan program koji je licenciran od strane

proizvođača kao što su Microsoft, Oracle i IBM
Microsoft Access nije samo DBMS, već je njima obuhvaćen DBMS +

generator aplikacija. On zapravo sadrži DBMS koji kreira, obrađuje i
administrira bazu podataka ali takodje i generatore formi, izveštaja i
upita uz pomoć kojih se može praviti aplikacija. Interno, sve komponente
aplikacije koriste SQL da bi pozvale DBMS.
U slučaju klasa aplikacija koje rade nad bazama podataka a koriste se

kao podrška radu kompanija, ove komponente su mnogo složenije od
prethodno opisanog slučaju na primeru Accessa.
KOMPONENTE SLOŽENOG RDBMS SISTEMA
Nad bazom podataka se mogu izvršavati različiti tipovi

aplikacija koje uzimaju i smeštaju podatke u bazu
podataka slanjem SQL naredbi DBMS-u
Slika 7 . prikazuje komponente jednog sistema za upravljanje bazama

podataka koji se koristi u kompanijama.
Nad bazom podataka se mogu izvršavati različiti tipovi aplikacija:
• SAP aplikacije koje se za bazu podataka konektuju preko lokalne

mreže kompanije. Takve aplikacije se nazivaju i klijent/server
aplikacije jer se aplikativni programi koji se nalaze na klijentu
konektuju na bazu podataka koja se nalazi na serveru. Često su
pisane u Visual Basicu, Javi ili C++.
• E-commerce aplikacije koje se izvršavaju na Web serveru.
Korisnici se na takve aplikacije konektuju preko Web browsera. Za
njihovu realizaciju se može koristiti Microsoft-ov Internet Information
Server (IIS) i Apache. Jezici koji se koriste na Web serverima su PHP,
Java, i Microsoftovi .NET jezici kao što je VB.NET
• Aplikacije za izveštavanje koje rezultate upita nad bazama
podataka publikuju na portalu kompanije ili na drugim Web site-
ovima. Takve aplikacije za izveštavanje se često kreiraju korišćenjem
posebnih generatora izveštaja
• XML servisi koji koriste kombinaciju XML jezika za označavanje

i drugih standarda koji omogućavaju komunikaciju između više
različitih programa. Na ovaj način se kod koji sadrži jedna aplikacija
distribuira na više različitih računara
Sve ove aplikacije uzimaju i smeštaju podatke u bazu podataka slanjem

SQL naredbi DBMS-u.
30

složenog RDBMS sistema
NAJPOZNATIJI RDBM SISTEMI
Microsoft Access, Microsoft SQL Server, IBM DB2,

Oracle
Sistemi za upravljanje bazama podataka (DBMD)upravljaju bazom

podataka. Oni obrađuju SQL naredbe i obezbeđuje druge karakteristike i
funkcije kojima se kreira, obrađuje i administrira baza podataka. Slika 8 .
predstavlja četiri najpoznatija RDBMS proizvoda.
Proizvodi su poređani po mogućnostima kojima raspolažu (od najmanjih

do najvećih) i lakoćom korišćenja (od onih koji se najlakše do onih koji se
najteže koriste). Tako se za Access može reći da je najlakši za korišćenje
ali su i njegove mogućnosti najmanje dok se Oracle može smatrati naj
moćnijim DBMS-om koji je i najteži za korišćenje.
Slika 3.3.8 Najpoznatiji
RDBMS proizvodi
VIDEO
What is Database &amp;amp; SQL?
Ova lekcija sadrži video materijal. Ukoliko želite da pogledate

ovaj video morate da otvorite LAMS lekciju.
31
Poglavlje 4 Dizajn relacionih BP
RAZLIČITI NAČINI ZA DIZAJNIRANJE

BAZA PODATAKA
Na osnovu postojećih podataka, razvojem novih BP,

redizajniranjem baza podataka
Dizajn baze podataka je veoma težak a ujedno i veoma važan.

Određivanje odgovarajuće strukture tabela, o dgovarajućih relacija
između tabela, o dgovarajućih ograničenja i drugih strukturnih
komponenti se može smatrati velikim izazovom. Baze podataka se mogu
projektovati na tri načina:
• Iz postojećih podataka
1. Analiziraju se različite tabele podataka

2. Izdvajaju se podaci iz postojećih baza
3. Baza podataka se projektuje korišćenjem principa normalizacije
• Razvojem novih BP
• Na osnovu zahteva za razvoj aplikacija kreira se model podataka
• Model podataka se transformiše u dizajn baze podataka
• Redizajniranjem baza podataka

• Vrši se migracija postojeće baze podataka u novu bazu
• Integrišu se dve ili više baze podataka
• Uradi se reverse inženjering pa se nova baza podataka kreira
korišćenjem principa normalizacije i transformacijom modela
podataka,
PRIMENJUJE SE U DVA SLUČAJA
(a) Kada podatke iz spredsheet-ova ili tekstualnih

fajlova treba importovatiu bazu podataka; (b)Kada iz
jedne baze podataka treba smestitii u drugu bazu
podataka
32
U ovom slučaju baza podataka se dizajnira osnovu postojećih podataka

kao što je šematski prikazano na slici 1. Mogu se izdvojiti dva slučaja:
1. Kada se razvojnom timu da skup spredsheet-ova ili tekstualnih

fajlova sa tabelam a podataka i od njega se traži da dizajnira
novu bazu podataka u koju treba da importuje te podatke.
2. Alternativno, baza podataka može da se kreira iz drugih baza
podataka. Ova alternativa je naročito prisutna prilikom kreiranja
aplikacija za izveštavanje ili data mining aplikacija. Na primer,
podaci se operativnih baza podataka kao što su CRM ili ERP mogu
kopirati u nove baze koje će se koristiti samo za potrebe analize
i studiranja.
Slika 4.1 Dizajniranje baza

podataka na osnovu
postojećih podataka
KAKO IMPORTOVATI PODATKE U

TABELE?
Odgovor se može dobiti korišćenjem principa

normalizacije koji sprečavaju moguću korupciju baza
podataka
Kada se baze podataka kreiraju iz postojećih podataka, razvojni tim mora

da definiše odgovarajuću strukturu te nove baze. Pitanje na koje u takvoj
33
situaciji treba dati odgovor je u kakvim relacijama u novoj bazi podataka

treba da budu fajlovi ili tabele koje treba importovati. To se pitanje
može postaviti i pri importovanju jedne jedine tabele. Slika 2. prikazuje
dva različita načina importovanja jedne jednostavne tabele koja sadrži
podatke o radnicima i odeljenjima u kojima oni rade. Da li te podatke
treba pamtiti u jednu ili dve tabele.
Odgovor na ovakva pitanja se mogu dobiti korišćenjem skupa principa

koji se zovu pravila normalizacije ili normalne forme.
Primarni razlog za normalizaciju baza podataka je što je normalizacija

moćno oružje protiv moguće korupcije baza podataka koja potiče od
onog što nazivamo "anomalije prilikom ubacivanja", "anomalije prilikom
brisanja" i "anomalije prilikom ažuriranja". Ovi tipovi grešaka mogu da se
uvuku u nedovoljno normalizovane baze podataka
Slika 4.2 Dva različita načina
importovanja jedne
jednostavne tabele
KAKO SE DIZAJNIRA NOVA BAZA

PODATAKA?
Na osnovu zahteva sistema se kreira model podataka

koji se transformiše u dizajn baze podataka.
U slučaju projektovanja baza podataka razvojem novog sistema, baze

podataka se kreira na osnovu zahteva koje definišu budući korisnici
sistema, njihovih želja vezanih za izgled formi za unos podataka i
izveštaja, use case-ova itd, kako je to prikazano na sledećoj slici. U svim,
pa i u najjednostavnijim sistemima, put od definisanja zahteva za razvoj
sistema do dizajna baze podataka je veoma dug i sastoji se od dva
koraka:
34
Slika 4.3 Dizajniranje nove

relacione baze podataka
1. na osnovu zahteva sistema se kreira model podataka

2. model podataka se transformiše u dizajn baze podataka.
Najpopularnija tehnika za pretstavljanje modela podataka su Entity

Relationship (E/R) dijagrami.
E/R dijagrami sadrže niz oznaka kojima se opisuju osnovni koncepti

za opis strukture baze podataka kao i osnovne operacije prikupljanja i
ažuriranja podataka. Osnovni koncepti E/R modela su: entiteti, atributi,
relacije
Za crtanje E/R dijagrama se koriste načešće CASE (Computer Aidid

Software Engineering).Izbor odgovarajućeg CASE alata sam po sebi je
manje ili više formalan, dok postupak modeliranja realnog sistema, zavisi
od sposobnosti, znanja i iskustva analitičara. Ne mogu se dati
strogo formalna pravila modeliranja koja bi vodila do jedinstvenog
modela složenog realnog sistema, bez obzira na to ko modeliranje vrši.
Mogu se dati samo opšte metodološke preporuke, opšti metodološki
pristupi, kao pomoć u ovom složenom poslu.
KADA SE VRŠI REDIZAJNIRANJE?
(a) U slučaju kada podatke treba migrirati kako bi se

prilagodila novim zahtevima (b) Kada treba izvršiti
integraciju podataka iz dve ili više baza
35
Na sledećoj slici su prikazana dva uobičajena tipa redizajna baza

podataka.
Slika 4.4 Redizajniranje baza
podataka
1. U prvom, baza podataka se adaptira novim, izmenjenim

zahtevima. Taj proces se često naziva migracija baze
podataka. U procesu migracije, može se vršiti kreiranje novih
tabela, m odifikovanje postojećih ili njihovo uklanjanje; relacije
između tabela se takodje mogu menjati; mogu se menjati i
definisana ograničenja.
1. Drugi tip redizajna baze podataka se odnosi na integraciju

dve ili više baza podataka. Ovaj tip redizajna sejavlja u
slučajevima kada se treba adaptirati nasleđenim bazama
podataka (legacy system)ili ih izbaciti iz upotrebe. Javlja se i u
slučajevima kada u okviru nekog sistema koji služi kao podrška
za poslovanje kompanije treba izvršiti neku integraciju aplikacija
tj. kada dva ili više informaciona sistema koja su predhodno
radila potpuno nezavisno, treba adaptirati da rade zajedno.
Redizajniranje baza podataka je veoma složen proces i da bi se on

razumeo treba znati SQL naredbe kojima se može definisati struktura
baze podataka i kojima se baza može ažurirati.
36
Poglavlje 5: Objektno-orjentisane baze podataka (eng. ORDBMS)
Poglavlje 5 Objektno-orjentisane
baze podataka (eng.
ORDBMS)
CILJ OBJEKTNO ORIJENTISANIH BAZA

PODATAKA (ENGL. ODBMS)
Da omoguće prirodniju manipulaciju podacima u

aplikacijama koje se razvijaju nad bazom
Objektna orjentacija (OO) je pristup u kome se neki sistem organizuje

kao kolekcija međusobno povezanih objekata koji ostvaruju postavljene
ciljeve. Poslednja decenija u softverskom inženjerstvu jeste decenija
objektne orjentacije. Ona danas preovladava u programiranju i
programskim jezicima, metodološkim pristupima razvoju softvera i
informacionih sistema, a sve se više koristi i u sistemima za upravljanje
bazom podataka, bilo preko čistih sistema za upravljanjem bazom
podataka, bilo preko objektno-relacionih DBMS-a koji predstavljaju
proširenje relacionih sa objektnim konceptima. Sistemi za upravljanje
OO baza podataka (engl. ODBMS ili OODBMS) imaju za cilj da omoguće
prirodniju manipulaciju podacima u aplikacijama koje se razvijaju nad
bazom.
Osnovni primitivni koncepti objektnog modela su objekat i literal. .
Literar je u osnovi vrednost, podatak koji se koristi u modelu.Brojevi

i karakteri su primeri „atomskih“ literala, a datum je primer složenog
literala.
Pod objektom se podrazumeva entitet koji je sposoban da čuva svoja

stanja i koji stavlja okolini na raspolaganje skup operacija preko kojih se
ta stanja prikazuju ili menjaju. Objekat je korisnički definisani, kompleksni
tip podataka koji ima svoju strukturu i
.
stanje (atributi i svojstva), kao i ponašanje (metode i operacije).Objekti
programskog jezika se bez ikakve izmene čuvaju u bazi. Mogu se opisati
sa četiri karakteristika:
1. Identifikator – univerzalni identiifikator objekta na nivou sistema
37
2. Ime – objekat bi trebao da ima jedinstveno ime u bazi, ali nije

neophodno
3. Životni vek – objekat može biti privremen ili postojan
4. Struktura – objekat se kreira uz pomoć konstruktora tipa podataka

Slika 5.1.1 Šema OO baza
podataka
KARAKTERISTIKE ODBMS
Ne postoji standard za ODBMS, kao ni univerzalno

prihvaćeni dogovor o modelima podataka, sastoje se
od objektnih modela, objektnih jezika, objektnih upitnih
jezika, programskih jezika
U OO modelu baze podataka (slika 2. ) ne postoji koncept primarnog

ključa, već ODBMS za svaki objekat pamti jedinstveni i neprimenljivi
identifikator - Object IDentifier (skraćeno OID)koji se koristi za
referenciranje objekta u okviru baze podataka. Ovaj identifikator ne
može se ručno definisati ili menjati jer ga sistem sam definiše.
Cilj je da se objekti baze podataka i objekti aplikacija napisanih u nekom

OO programskom jeziku izjednače. Objekti u aplikacijama su tranzijentni,
i životni vek im je jednak trajanju aplikacije dok su u bazi perzistentni i
nezavisni od postojanja aplikacija koje ih koriste.
38
Ne eliminiše se mogućnost da se više programa koriste istu bazu

podataka.
ODBMS na početku nije bio zasnovan na jedinstvenom standardu i ciljevi

su se ostvarivali na više načina sa manje ili više uspeha. U poslednjih
nekoliko godina intezivno se razvija standard za objektne baze podataka
u okviru ODMG (Object Database Management Group).Verzija 1.2 ODMG
standarda se pojavila 1996, a značajno je izmenjena i dopunjena verzija
2.0, 1997 godine.
Komponente ODBMS su: objektni modeli, objektni jezici, objektni upitni
jezici, programski jezici kao što su: C++, smalltalk, Java Language
Binding. Objektni specifikacioni jezici služe kao skup međusobno
povezanih objekata.
ODL objektno specifikaconi jezik ima istu ulogu koju JOP (DDL) ima
u konvencionalnim jezicima. C++, Smalltalk, Java Language Binding
predstavljaju nezavisne komponente arhitekture koje pokazuju kako se
u navedenim programskim jezicima (npr. C++-u) ugrađuju mogućnosti
manipulacije perzistentnim objektima, mehanizmi za povezivanje sa
OQL-om, upravljanje transakcijama i sl.
Za razliku od relacionih modela, u svetu objektno-orijentisanih baza

podataka ne postoji univerzalno prihvaćeni dogovor o modelima
podataka.
• Svaki OOMP mora minimalno posedovati sledeće osobine:

• Mora biti obezbeđena funkcionalnost baze podataka
• Mora podržavati identifikaciju objekata
• Mora postojati mogućnost enkapsulacije
• Mora podržavati objekte sa kompleksnim stanjem.
KORIŠĆENJE I NEDOSTACI ODBMS
Koriste se kada je potrebno podržati princip

nasleđivanja i karakterišu se mnogim nedostacima koji
proizilaze iz nepostojanja iskustva u radu sa njima
OO model baze podataka se koristi:
• 1. Kada je nasleđivanje kao osobina OO modela bitna

• 2. Kada je potrebna besprekorna integracija operativnih sistema
baze podataka, tabela, i sl.
• 3. Ukoliko je potrebna bilo kakvo deljenje informacija, proizvoda,
softvera.
Neki od osnovnih nedostataka OO DBMS-ova su:
39
• Nepostojanje univerzalnog modela podataka – kao što je već rečeno,

ne postoji univerzalni dogovor oko izgleda modela podataka za OO
DBMS-ove. Nedostaje i teoretska podloga za modele. Ipak udruženje
ODMG (Object Database Management Group) predložilo je objektni
model koji predstavlja de facto standard
• Nedostatak iskustva – korišćenje OO DBMS-ova je još uvek u povoju

što znači da ne postoji iskustvo u radu sa njima
• Nedostatak standarda – osim što ne postoji univerzalni dogovor oko
izgleda modela podataka za OO DBMS-ove, ne postoje ni standardi
za OO upitne jezike. Ipak udruženje ODMG (Object Database
Management Group) predložilo je objektni upitni jezik (OQL) koji
predstavlja standard de facto
• Složenost – uvođenje dodatnih funkcionalnosti, povećala se
kompleksnost DBMS-ova. Ovakva složenost dovodi do toga da su
aplikacije skuplje i teže za korišćenje
• Nedostatak podrške za poglede i bezbednost – trenutno, većina
OO DBMS-ova nema ugrađene mehanizme za poglede i bezbednost
pristupa podacima
5.1 OBJEKTNO-RELACIONE BAZE

PODATAKA (ENG. ORDBMS)
KARAKTERISTIKE
Tradicionalni relacioni model proširuje osnovnim

objektnim konceptima kao što su: abstraktni tipovi
podataka, enkapsulacija, polimorfizam, nasleđivanje i
sl.
Objektno-relacioni model i objektno-relacione baze podataka

reprezentuju takozvani evolucijski pristup koji se ogleda u integraciji
objektne pradigme u relacioni model podataka i njegovim proširenjem
objektno-orjentisanim karakteristikama. Objektno-relacione baze se
mogu nazvati i hibridne baze.
Osnovna postavka objektno-relacionih baza podataka je upravljanje

objektima i pravilima uz očuvanje kompatibilnosti sa relacionim modelom
i relacionim bazama podataka. SQL 2003 standardom ostvareno je
potpuno slaganje nad objektno-relacionim modelom i svi glavni
proizvođači sistema za upravljanje bazama nastoje u što je moguće
većem obimu da implementiraju taj standard. Objektno-relacioni sistem
za upravljanje bazom podataka(ORDBMS) je sličan sistemu za
upravljanje relacionim bazama podataka ali se bazira na objektno-
40
orjentisanom modelu baze podataka: objekti, klase i nasleđivanje su

direkno podržane u šemama baza podataka i upitnim jezicima.
.
Tradicionalni relacioni model se proširuje osnovnim objektnim
konceptima kao što su: abstraktni tipovi podataka, enkapsulacija,
polimorfizam, nasleđivanje i sl.Razvoj objektno-relacionih baza podataka
bazira se na saznanju da relacioni sistemi odgovaraju zahtevima
aplikacija koje upravljaju jednostavnim podacima sa kompleksnim
upitima.
OSNOVNI KONCEPTI
Korisnički definisani (apstraktni) tipovi podataka i

prošireni koncept relacije koji dopušta da atributi n-
torki relacija kao domene ne moraju imati samo proste
podataka
Osnovni koncepti su:
1.) Definisani tipovi podataka od strane korisnika - omogučuje kreiranje

aplikacijskih specifičnih, kompleksnih tipova podataka. Prekoračuje se
jedno od osnovnih ograničenja relacionog modela koji podrazumeva i
zahteva da domeni atributa relacije budu prosti. Korisnički definisani tip
utemeljen je na konceptu abstraktnih tipova podataka.
2.) Relacije – su i dalje jedan od osnovnih koncepata objektno-relacionog

modela. Koncept relacije je proširen dopuštanjem atributima n-torki
relacija, da kao domene ne moraju imati samo proste, nego i korisničke
tipove podataka. Ukoliko su elementi relacije primeri korisničkog tipa
podataka ona se naziva objektna relacija.
Korisnički tipovi podataka mogu biti, kao i standardni jednostavni tipovi,

domeni atributa standardnih relacija. Ne postoji formalna definicija
objektnog modela (ODMG specifikacija). Objektno-relacioni model bazira
se na konceptima objektne paradigme.
Objektni aspekti su:
1.) Apstraktni tipovi podataka - može se definisati klasa podataka koja se

sastoji od atributa i operacija uz skrivanje detalja njihove implementacije
2.) Nasleđivanje - mogućnost da više tipova podataka dele atribute i

operacije
3.) Identitet objekata - svaki primerak abstraktnog tipa podataka

poseduje jedinstveni ID, nevdljiv korisnicima
41
4.) Polimorfizam - egzistencija više operacija s istim imenom, a sa

različitom semantikom tj mogućnost rada nad različitim tipovima
podataka.
Objektno relacione baze podataka kombinuju jednostavnost i efikasnost

relacionih baza podataka sa mogućnostima objektnih baza podataka da
pamte složene objekte. Standardni SQL je izmenjen tako da relacionbom
modelu dozvoljva da inkorporira mnoge karakteristike objektno
orijentisanih sistema kao što su apstraktni tipovi podataka, nasleđivanje
i operacije. Open source proizvod PostgreSQL je verovatno najpoznatiji
hibridni DBMS. Oracle takođe uključuje neke hibridne karakteristike.
5.2 POREĐENJE RDBMS, OODBMS I

ORDBMS
PREDNOSTI I NEDOSTACI RELACIONIH BAZA

PODATAKA
Relacione baze podataka imaju mnoge prednosti ali i

nedostatke
Prednosti relacionih baza podataka:
1.) Standardizovan je, SQL se koristi
2.) Lak za modelovanje
3.) Referencijalni integritet (matematički zasnovane na teoriji skupova)
4.) Mnoštvo alata i implementacija baza
5.) Dobra podrška za izgrađenu infrastrukturu
6.) Relacioni model je zasnovan na vrednostima (Value-based), odnosno

redovi (rows) se mogu prepoznati po primarnim ključevima
Nedostaci relacionih baza podataka:
1.) Mogućnost korišćenja samo standardnih tipova podataka
2.) Nema mogućnosti proširivanja tipova podataka
3.) Nemogućnost prikaza ugnježdenih relacija
4.) Složene celine (entiteti) se ne mogu koristiti kao jedna celina
42
5.) Moraju se definisati ključevi i razne vrste relacija na nivou modela

podataka
PREDNOSTI I NEDOSTACI OBJEKTNIH BAZA

PODATAKA
Mnogi postojeći problemi sa objektnim bazama su

rešeni; Prednosti su korišćenje kompleksnih tipova
podataka, primena principa nasleđivanja i
enkapsulacije, visoke performanse itd.
Problemi sa objektnim sistemima za upravljanje bazom su:
1.) Još uvek ne postoji pravi standard za objektno-orjentisane baze

podatka
2.) ODBMS se koristi samo u industriji
3.) Teško se nalaze kvalifikovani stručnjaci
4.) Nedostatak alata za OODB u prošlosti
5.) ODBMS nema dobru podršku i kreiraju se proizvoljni upiti
6.) ODBMS zaostaje u performansama i skalabinosti za sistemom

relacionih baza podataka
7.) Nedostaje im formalna matematička formalizacija.
U suštini to je ono što se zamera objektnim bazama. Istina je da postoji

standard i zove se ODMG-93, koji je preraso u ODMG 2.0 a kasnije u
ODMG 3.0. Neke ODBMS su u potpunosti podržane od strane SQL-a sa
dodatkom za navigacioni pristup. Objektne baze podataka se sve više
koriste i van industrije, tačnije primena im je u velikom rastu, ali još uvek
imaju prednost relacione baze jer se više koriste.
Sve više je kvalifikovanih stručnjaka, ali još uvek nije dovoljno. Alati za
ODBMS su relativno laki za korišćenje. Neki smatraju da su objektno
orjentisane baze lakše za učenje od relacionih baza podataka i jeftinije.
Doduše postoji i dobra većina koja misli da ipak je lakše upravljati
relacionim bazama podataka. Objektno-orjentisani pristup je prirodna
alternativa za rastuće kompanije koje nemaju novca za kupovinu
relacione baze i može se kreirati vrlo intezivna obuka svojim
zapošljenima. Zbog niske cene i jednostavnosti, objektne baze podataka
su takođe savršen izbor za naučne zajendice i univerzitetska istraživanja.
Prednosti objetnih baza su:
1.) Visoke performanse
43
2.) Navigacioni interfejs za operacije (kao što je obilazak grafa)
3.)Objektni upitni jezik preuzima objekte deklarativno
4.) Kompleksni tipovi podataka
5.) Klase i hijerarhije (nasleđivanje i enkaspulacija)
6.) Semantičko modeliranje
PREDNOST OBJEKTNO-RELACIONIH BAZA

PODATAKA
Podrška za složene tipove podataka, podrška SQL-u,

podrška za nasleđivanje itd.
Prednosti objektno-relacionih baza podataka su:
1.) Podrška za složene tipove podataka kao što su kolekcije i sl.
2.) Objektno-orjentisano modeliranje podataka
3.) Podržan SQL
4.) Podrška za UDT (User Definied Types) nasleđivanje
5.) Moćan upitni jezik
6.) Različiti pristupi (OO, Relaciona baza, OODB) koji su nekada

neophodni za različite aplikacije.
U zavisnosti od svrhe korišćenja baze potrebno je i izabrati vrstu baza
koja će se koristiti.
VIDEO
The differences between relational, object, no-SQL, and

data warehouse databases
Ova lekcija sadrži video materijal. Ukoliko želite da pogledate

ovaj video morate da otvorite LAMS lekciju.
44
Poglavlje 6 Vežba:Sybase
PowerDesigner
ŠTA JE POWER DESIGNER?
PowerDesigner je Sybase-ov alat za modelovanje

procesa sistema i podataka
Sybase je vodeća kompanija u oblasti razvoja enterprise softverskih

rešenja i pružanja usluga vodećim svetskim kompanijama, sa fokusom
na menadžment i mobilnost informacija. Nastala je 1984. godine, tokom
studija njenih osnivača Marka Hoffmana i Boba Epsteina na Berkeley
Univerzitetu u Kaliforniji. Kompanija je nastala u garaži, a danas je
sedište u gradu Dublinu u Kaliforniji, SAD. Tržište Sybase kompanije
su elektronsko bankarstvo, modelovanje procesa i podataka, enterprajz
rešenja u oblasti upravljanja podacima. Sybase takođe ima i samostalne
sistme za upravljanje bazama podataka, ali još uvek su ispod Oracle, IBM
i Microsofta sa samo 5% tržišta.
PowerDesigner je Sybase-ov alat za modelovanje procesa sistema i

podataka. PowerDesigner je projektovan za Windows okruženje. Ona
sadrži i dodatke kako bi koristila Java platformu i programsko okruženje
Eclipse. PowerDesigner je 2002. godine zauzeo 40% tržišta. Poseduje
mnogo mogućnosti u oblasti modelovanja:
- Modelovanje poslovnih procesa
- Generisanje programskog koda (Java, C#, VB.NET, JSF, PowerBuilder

itd),
- Modelovanje podataka korišćenjem E/R dijagrama
- Modelovanje DataWarehouse-a,
- Eclipse programiranje,
- Objektno modeliranje
- Generisanje izveštaja,
- Rad sa repozitorijumima,
- Generisanje XML šema u DTD standardu itd.
45
Dva nivoa E/R modela koja će se razvijati uz pomoć PowerDesigner alata

su:
- Konceptualni model
- Fizički model
ŠTA JE MODEL PODATAKA?
Model podataka je apstraktno viđenje stanja realnog

sistema. Može se pretstaviti različitim tehnikama a
jedna od njih je tehnika E/R dijagrama
Model podataka je apstraktno viđenje stanja realnog sistema tj. on

predstavlja sredstvo pomoću koga se obezbeđuje interpretacijа podataka
o posmatranom realnom sistemu. Model sadrži skup koncepata koji
opisuju strukturu baze podataka kao i osnovne operacije prikupljanja i
ažuriranja podataka. Osnovna namena modela je da se prikaže korisničko
viđenje podataka, a da se pri tome ne zalazi previše u tehničke aspekte
baze podataka. Potrebno je naglasiti i da je kreirani model podataka
nezavistan od bilo kojeg sistema za upravljanje bazama podataka
(DBMS) kao i hardverske platforme na kojima će se implementirati baza
podataka.
Model podataka se može pretstaviti različitim tehnikama a jedna od njih

je tehnika E/R dijagrama. Interpretacija podataka se u modelu podataka
pretstavljenim E/R dijagramom ostvaruje kroz dve njegove osnovne
komponente:
• Strukturu podataka, preko koje se predstavljaju statičke

karakteristike sistema;
• Ograničenja na vrednosti podatka koja u svakom trenutku
posmatranja (stacionarnom stanju) treba da budu zadovoljena.
Postoji mnogo verzija E/R dijagrama i one se razlikuju po tome što

za predstavljanje različitih koncepata modela kao što su entiteti, veze
i atributi koriste različite simbole. Na slici su predstavljeni osnovni
koncepti modela u Chen-ovoj verzji E/R modela.
46
Slika 6.1 Chen-ova verzija E/R

modela: entiteti su
pretstavljeni
pravougaonicima, veze
rombovima a atributi
elipsama
ZA ŠTA MOGU POSLUŽITI ER MODELI?
Za pretstavljanje konceptualnog, logičkog i fizičkog

modela podataka
Mogu se razviti tri nivoa ER modela:
Konceptualni model podataka: To je najviši nivo E/R modela koji ne

sadrži sitne detalje već globalni pogled na ono što će biti uključeno
u modelu. Konceptualni model definiše samo glavne entitete koji se
koriste u organizaciji. Konceptrualni model se uhlavnom koristi za
dokumentovanje arhitekture podataka na nivou čitave organizacije. On
se može koristiti kao osnova za izradu jednog ili vise logičkih modela
podataka. Konceptualni model podataka se takođe može koristiti za
uspostavljanje veza između pojedinih ER modela kao osnova za
integraciju modela podataka.
Logički model podataka: Za crtanje logičkog modela podataka nije

obavezno imati konceptualni model podataka. Logički model podataka
sadrži vise detalja od konceptualnog E/R modela. Pored osnovnih entiteta
podataka potrebno je definisati i operativne i transakcione entitete. Svaki
entitet podataka se daje sa vise detalja i uspostavljaju se veze između
entiteta. Kao i konceptualni i logički model podataka se razvija nezavisno
od tehnologije u kojoj će biti implementiran.
Fizički model podataka: Za svaki logički E/R model se razvija jedan
ili vise fizičkih E/R modela. Svaku fizički model mora da sadrži dovoljno
47
detalja kako bi mogla da se generiše baza podataka i svaki fizički model

je tehnološki zavistan od konkretnog sistema za upravljanje bazama
podataka. Na osnovu fizičkog modela se u u bazi podatka generišu
odgovarajuće tabele, indeksi, jedinstveni ključevi , ograničenja
referncijalnog integriteta itd.
Za crtanje E/R modela se mogu koristiti različiti CASE alati. Ovde će

će biti korišćen CASE alat PowerDesigner kod koga su notacije za
pretstavljanje entiteta, atributa i veza drugačije od onih koje se koriste u
Chen-ovom modelu.
POKRETANJE POWER DESIGNER
Nakon pokretanja PowerDesigner alata pojaviće se

Welcome prozor
Nakon pokretanja PowerDesigner alata pojaviće se Welcome prozor koji

je prikazan na slici. Z a prikaz je korišćena 15.1 verzija PowerDesigner-a
i u zavisnosti od verzije korišćenja može doći do odstupanja od izgleda
interfejsa.
Slika 6.2 Welcome prozor
PowerDesigner-a
Nakon pokretanja PowerDesigner alata pojaviće se Welcome prozor koji

je prikazan na slici. Z a prikaz je korišćena 15.1 verzija PowerDesigner-a
i u zavisnosti od verzije korišćenja može doći do odstupanja od izgleda
interfejsa.
48
Slika 6.3 Selekcija potrebnih

dijagrama u PD-u
KREIRANJE KONCEPTUALNOG MODELA
Crta se korišćenjem palete koja sadrži relevantne

simbole
Kada se selektuje dijagram koji želi da se kreira (u ovom slučaju

konceptualni dijagram) potrebno je dati ime modelu i kliknuti na OK
dugme kako bi se otvorila radna povrsina konceptualnog modela.
49
Slika 6.4 Površina za kreiranje

konceptualnog modela
Kako bi kreirali neki konceptualni model prvenstveno selektujemo nekih

od ponuđenih alata iz palete.
Svaki alat u paleti ima određenu funkciju. Neki služe za selektovanje,
neki za kreiranje entiteta, relacija, nasleđivanja i sl. Nakon odabira alata
za kreiranje entiteta (prelaskom miša preko tabelic e, gde dolazi do
ispisvanja "Entity") mišem kliknemo na mesto gde želimo da postavimo
entitet. Nakon kreiranja više entiteta povezujemo ih relacijama.
50
Slika 6.5 Površina za kreiranje

51
ČUVANJE KONCEPTUALNOG DIJAGRAMA
Objašnjenje postupka čuvanja
Ukoliko želimo da sačuvamo kreirani dijagram to se izvršava pritiskom na

"File" meni i odabirom save as ili samo save ukoliko želimo da snimimo
samo kreirani dijagram, pri čemu smo pre toga selektovali dijagram koji
želimo da snimimo duplim klikom na određeni model. Ukoliko imamo
više različitih dijagrama, različitih modela, možemo snimiti i celu radnu
površinu klikom na
Slika 6.6 Konceptualni model
za čuvanje
Primer kreiranog konceptualnog modela u PowerDesigner-u prikazan je

na slici.
"Save Workspace". Ukoliko se snimi cela radna površina nakon
pokretanja sačuvane pokreću se i svi sačuvani modeli.
52
Slika 6.7 Čuvanje

KREIRANJE FIZIČKOG DIJAGRAMA
Moguće je na dva načina: generisanjem iz

konceptualnog modela ili pravljenjem novog fizičkog
modela
Ukoliko želimo da kreiramo fizički dijagram može se izvršiti na dva

načina. Ukoliko imamo konceptualni model možemo generisati fizički
model ulaskom u opciju "Tools" pa zatim "Generate Physical Data Model".
Potrebno je naglasiti prilikom kreiranja ili generisanja fizičkog modela da
se odabere vrsta DBMS-a (sistema za upravljanje baza podataka) koji će
se na dalje koristiti kako bi nakon generisanja baze iz fizičkog modela
dobili određeni DBMS (Mysql, oracle, MS Access itd.).
53
Slika 6.8 Prikaz kreiranja

fizičkog modela u PD-u
Ukoliko želimo da kreiramo fizički dijagram iz početka potrebno je

prilikom odabira novog modela izabrati "Phyisical Data Model" a zatim
izabrati "Physical diagram". Nakon toga otvara se prozor gde se nude
opcije za naziv modela kao i odabir DBMS-a. U ovom slučaju je izabran
Oracle 11g verzija. Nakon odabira otvara se okruženje za kreiranje
fizičkog modela.
54
Slika 6.9 Kreiranja fizičkog

modela u PD-u - izbor RDBMS
GENERISANJE .SQL SKRIPTE ZA

KREIRANJE TABELA U BAZI NA SNOVU
FIZIČKOG MODELA
Tabele se generišu za izabrani RDBMS
Alati u paleti se razlikuju od alata u konceptualnom modelu. Više se "ne

radi" sa entitetima već sa tabelam a. Razlikujemo alate za selektovanje,
za kreiranje tabela, k reiranja referenci nad tabelam a i dr. Prikaz
kreiranog fizičkog modela može se videti na sledećoj slici.
55
Slika 6.10 Fizičku model BP
Nakon kreiranog modela, model možemo sačuvati kao što je prikazano u

primeru konceptualnog modela. Osim toga možemo generisati kod baze
iz modela. To se izvršava tako što se nakon otvaranja taba "Database"
koji se pojavljuje kada nam je uključen fizički model klikne na "generate
database". S obzirom da smo odabrali za DBMS Oracle 11g on će
automatski biti selektovan i kod će biti prilagođen njemu. Nakon
generisanja, dobiće se .sql dokument sa kodom.
Slika 6.11 Generisanje skripte
za kreiranje BP
56
PRIKAZ GENERISANOG .SQL FILE-A
.SQL file za kreiranje tabela u bazi
Nakon generisanja, dobiće se .sql dokument sa kodom. Prikaz

generisanog koda je dat na slici.
Slika 6.12 Skripta za kreiranje
tabela u BP
57
Poglavlje 7 Domaći zadatak
TEKST ZADATKA
Uraditi rešenje zadatka prema sledećem tekstu
Nacrtajte konceptualni model relacione baze podataka sa dva entiteta:
RAČUN: koji ima atribute: BrojRacuna, TipRacuna i StanjeRacuna i
KORISNIK: koji ima atribute: ID, Ime, Prezime, BrojRacuna i povežite ih

relacijom tako da jedan KORISNIK može imati više RAČUNA:
Domaće zadatke slati na adresu: aleksandra.arsic@metropolitan.ac.rs i

veljko.grkovic@metropolitan.ac.rs
58
Zaključak
Zaključak
ŠTA SMO NAUČILI?
U ovom predavanju su date uvodne napomene o bazama podataka.

Najpre je objašnjena potreba za čuvanjem podataka a zatim način
smeštanja i čuvanja podataka u fajlovima. Baze podataka su nastale s
ciljem da se prevaziđu probemi čuvanja podataka u fajlovima, pre svega
problem redudantnosti (ponovljivost)i podataka.
U predavanjima se objašnjavaju tri tipa baza podataka: realcione,

objektne i relaciono objektne baze podataka kao i njihove međusobne
razlike. Međutim, kako su danas u upotrebi uglavnom relacione baze
podataka, opisane su karakteristike njihovih osnovnih komponenata kako
na primeru jednostavnih tako i na primeru složenih sistema.
U ovom predavanju su ukratko objašnjeni i različiti načini za dizajniranje

baza podataka u slučaju razvoja novih sistema, na osnovu podataka koji
su već smešteni u bazama podataka pa ih treba redizajnirati ili podataka
koje iz fajlova treba importovati u bazu podataka.
59

Lekcija 01: IT350 - Baze Podataka

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lekcija 01: IT350 - Baze Podataka

Uploaded by

Copyright:

Available Formats

IT350 - Baze podataka

Copyright © 2010 BELGRADE METROPOLITAN UNIVERSITY. All rights

OSNOVE BAZE PODATAKA

°°°°° Osnove baze podataka

Šta ćemo naučiti u ovoj lekciji?

Od autora do autora, od knjige do knjige, od materijala do materijala,

Za početak se treba saglasiti da baze podataka nisu ograničene samo na

Baza podataka je velika kolekcija podataka posebno organizovanih za

Poglavlje 1 Potreba za čuvanjem

ZAŠTO TRAJNO ČUVATI PODATKE?

Da bi im se pristupilo i pošto programi završe sa svojim

Mnoge aplikacije imaju potrebu da između dva sukcesivna izvršenja

Trajni podaci mogu biti zapamćeni u datotekama ili bazama podataka.

KAKO KRAJNJI KORISNIK VIDI PODATKE

Ako su bazene relacione, vidi tabele koje sadrže

veze između njih; Korisnika ne vidi da su podaci

U principu, svi podaci se u računarima pamte u nekoj vrsti datoteka (file-

Međutim, sistema za upravljanje bazama podataka obezbeđuju jedan sloj

Izbor sistema za upravljanje bazom podataka ima značajan uticaj na

Poglavlje 2 Cuvanje podataka u

ČUVANJE PODATAKA U FAJLOVIMA

File je podeljen na individualne slogove od kojih svaki

Najjednostavniji način za trajno čuvanje podataka u računarskim

Programski jezici i u nekim slučajevima operativni sistemi, takođe koriste

Slogovi u datoteci mogu imati različite forme:

• Slogovi fiksne dužine: svaki slog se satoji od više polja, od kojih

doći preskakanjem fiksnog broja bajtova

• Slogovi promenljive dužine – svaki slog se sastoji od izvesnog broja

dokumentima kao što su porudžbenice, fakture. U svakom slogu je

KAKO FAJOVI MOGU BITI

Serijski, sekvencijalno i random

Postoje tri načina na koji file-ovi mogu biti organizovani: serijski,

• Serijska organizacija: Svaki sledeći slog u file-u se upisuje na kraj

Kod serijske organizacije se svaki sledeći slog u file-u se upisuje na

se dodaju u file korišćenjem preciznog algoritma koji dozvoljva da se

SERIJSKI I DIREKTAN PRISTUP PODACIMA

Serijski pristup podrazumeva čitanje fajlova slog po

Zavisno od izabrane organizacije file-ova, postoje različiti načini za

• Serijski pristup: Serijski se može pristupiti serijskim i sekvencijalnim

Prva i najjednostavnija od njih je relativna adresa. Ovaj metod pristupa

Drugi mogući pristup je hashing adresiranje. Gde se mogu koristiti

Slika 2.1 Organizacija

Pronalaženje sloga se vrši sekvencijalnim

Pristup sekvencijalnim file-ovima se može unaprediti održavanjem

U ovakvom pristupu se izdvajaju tri područja podataka:

• Glavo područje u koje se upisuju slogovi prilikom unosa ili

• Prelazno područje koje služi da se u njega smeste slogovi koji

Pronalaženje nekog sloga se vrši sekvencijalnim pretraživanjem područja

PROBLEMI ČUVANJA PODATAKA U

Redudantnost podataka, nemogućnost njihovog

Čuvanje podataka u file-ovima može da stvori mnogo problema:

• Kako broj aplikacija raste, raste i broj različitih file-ova. Neki od

• Prilagođavajući se promenama poslovnih zahteva, korisnici mogu

Prvi korak u rešavanju ovih problema je analizirati zahteve za

Poglavlje 3 Cuvanje podataka u BP

NA ČEMU SE ZASNIVA SISTEM ZA

Na Tri-šeme arhitekturi koja omogućava da se način

Baze podataka su nastale u pokušaju da se reše problemi sa čuvanjem

Prvi korak u rešavanju ovih problema je analizirati zahteve za pamćenjem

Drugi korak je iskoristiti sistem za upravljanje bazom podataka koji će

Danas je najčešće u upotrebi Tri-šeme arhitektura koja je prikazana na

Slika 3.1.1 Arhitektura tri-

Eksterna šema predstavlja način na koji se podaci koriste u aplikativnim