SEMINARSKI RAD

Tema:

RELACIONE BAZE PODATAKA

POSLOVNA INFORMATIKA:

GRUPA:
SADRŽAJ...............................................................................................strana

1. UVOD............................................................................................................................3

2.0. Šta je baza podataka ?................................................................................................3

2.1. Organizacija podataka........................................................................................4

2.2. Kreiranje baze podataka.....................................................................................4

2.3. PRISTUPI BAZAMA PODATAKA- programski jezici (sredstva)..................6

3.0. O modelima podataka................................................................................................7

3.1. Nastanak i razvoj relacionog modela baze podataka........................................8

3.1.1. Relacioni sistem za upravljane bazama podataka........................................8

3.1.2. Predstavljanje podataka.............................................................................10

3.1.3. Pristup podatcima.......................................................................................11

3.1.4. Sistemski tretman „NULL“ vrijednosti.....................................................11

3.1.5. Neprekidan pristup dinamičkom katalogu relacionog modela..................11

3.1.6. Sveobuhvatan jezik za rad sa podacima.....................................................12

3.1.7. Ažuriranje pogleda.................................................................................... 13

3.1.8. Dodavanje, brisanje i modifikovanje na visokom nivou...........................13

3.1.9. Fizička nezavisnost....................................................................................14

 3.1.10. Logička nezavisnost.................................................................................15

3.1.11. Integritetska nezavisnost..........................................................................15

3.1.12. Distribuciona nezavisnost........................................................................16

3.1.13. Rad sa jezicima niskog nivoa...................................................................17

4.0. ZAKLJUČAK...........................................................................................................18

1. UVOD

Od samog početka korištenja računara, obrada različitih vrsta podataka, bila je jedan od osnovnih
zadataka. Podaci i informacije su postali pokretačka snaga modernog poslovanja na Zapadu pa i u celom
svetu. Kada želimo da imamo kvalitetne informacije o svim segmentima našeg poslovnog ili čak i
privatnog života najbolje je da na određeni način organiziramo sve podatke koje mogu da nam pruže
informacije koje su od velike važnosti u trenutku kada su nam potrebne, pogotovo se to odnosi na
situacije kada u kratkom roku moramo doneti neku kvalitetnu ili sudbonosnu odluku.
Tada bi bilo najbolje da podaci za svaki pojedini element budu organizirani tako da se mogu smjestiti u
tabele sa istovrsnim zaglavljem. Može, a veoma često i mora da bude više tabela koje bi obuhvatili sve
segmente našeg interesovanja. Svi ti segmenti se nerijetko zbog svoje prirode moraju organizirati u
posebne tabele, a te tabele se mogu povezivati preko određenih zajedničkih elemenata. Skup više tih
tabela koje služe jednom zajedničkom cilju, skupa sa njihovim veznim elelmentima naziva se BAZOM
PODATAKA.

Njihov zajednički cilj se odnosi na svođenje veoma brze i uspješne infrormacije o svim događajima koji se
dešavaju unutar jedne cjeline. Kada kucamo nešto u Wordu, vršimo neke tabelarne proračune u Exelu u
više tabela onda imamo dodira sa bazom podataka. To je u svari pitanje organizacije naših podataka. Ako
ispisujemo datoteke u Wordu i smještamo ih po određenim direktorijima na neki način organiziramo
bazu podataka. U slučaju kada naša baza postane toliko komplikovana da nismo više u stanju da
jednostavno kontrolišemo tok i razvoj podataka potrebno je preći na viši stupanj organizacije podataka i
početi razmišljati o sistemu za upravljanje bazom podataka. Postoji više sistema za rad sa bazama
podataka kao što su: DBMS, ACCESS, FOXPRO, ORACLE, MICROSOFT SQL, DB2, XM.

2.0. Šta je baza podataka ?

Jednostavno rečeno, BAZA PODATAKA je softwerska konstrukcija namjenjena za pohranjivanje, analizu i

pretraživanje grupe srodnih i povezanih podataka, kao što su podaci o kupcima, pacijentima, telefonskim
brojevima i sl.

Baza podataka sastoji se od jedne ili više (dvodimenzionalnih) tabela koje međusobno mogu biti
povezane. Svaka tabela čuva istovrsne podatke (npr. podatke o nekoj osobi, predmetu i sl.). Svaki red u
tabeli predstavlja jedan slog u tabeli (najmanja grupa podataka u bazi koja u potpunosti opisuje neki od
koncepata koje baza modelira), a svaka kolona jedno od polja unutar tog sloga.

Dakle, slog može biti grupa podataka koja opisuje npr. neku osobu, a polja unutar tog sloga mogu
sadržavati ime, prezime, adresu stanovanja ili datum rođenja te osobe. Slog se u literaturi još ponegdje
naziva i entitet, a polje se naziva atribut. Svaki slog tabele se može jedinstveno identificirati putem jedne
ili kombinacijom vrijednosti nekog od polja tog sloga. To polje ili kombinaciju polja tada nazivamo
primarni dio ili osnovni ključ.

Tako neku osobu može jedinstveno identificirati njen matićni broj ili kombinacija vrijednosti polja imena
i prezimena.
U jednoj tabeli može postojati više polja ili kombinacija polja koji mogu biti kao primarni ključ. Pored
toga što primarni ključ ima ulogu jedinstvenog identificiranja sloga on igra ulogu i u povezivanju tabela.
Uzmimo da naša tabela ustvari predstavlja listu pisaca. Pored te tabela imamo i listu knjiga, te je
potrebno ove dvije tabele povezati kako bi smo znali koji je pisac napisao koju knjigu. Ako u slog knjige
ubacimo polje koje sadrži vrijednost primarnog kljuća pisca, ove dvije tabele su povezane. Ovo novo
polje (koje iskljućivo služi za povezivanje dvije tabele) u tabeli se zove strani ključ. Ovakav način
povezivanje podataka nazivamo relacioni model baza podataka.

2.1. Organizacija podataka

Organizacija podataka je od veoma velikog značaja kada želimo raditi sa bazom podataka. Jedan od
ključnih aspekata, dobrog kreiranja baze podataka jeste kako će podaci biti organizirani u bazi podataka.
Da bi postigli dobro kreiranu bazu podataka, podatke bi trebalo organizirati tako da su lahko dostupni i
da omogućavaju lahko održavanje baze podataka.

Treba odrediti koji će podaci ulaziti u bazu podataka, zatim koji će se podaci smjestiti u određene tabele
među kojima će biti uspostavljen odnos, te kakav je odnos među tim podacima. Potrebno je smanjiti
mogućnost koliko je moguće da se isti podatak zapisuje više puta (redundacija), jer višestrukim
zapisivanjem nastaju problemi očuvanja stvarne, jedinstvene vrijednosti svih podataka pri ažuriranju. To
utječe i na pouzdanost informacija koje se dobiju iz tih podataka. Potrebno je upravljati smještanjem
podataka i očuvanja tih podataka od namjernih i nenamjernih uništenja tj. da ne dođe do gubitka
integriteta podataka. Neke podatke treba zaštititi od toga da ih neovlašteni korisnici ne mijenjaju što se
zove tajnost ili privatnost podataka.

2.2. Kreiranje baze podataka

U svakodnevnom životu da bi počeli nešto praviti, kreirati potrebno je da unaprijed odredimo dizajn,
nacrt. Ako hoćemo da pripremimo neko jelo, potreban nam je recept, ako hoćemo graditi kuću potreban
nam je nacrt kako će izgledati i sl.

Pri kreiranju baze podataka, također prethodno trebamo organizirati podatke, odrediti ciljeve.
Ciljevi dizajniranja/kreiranja:

• eliminisati suvišne podatke

• omogućiti brzo pronalaženje pojedinačni podataka

• sačuvati jednostavno održavanje baze podataka

Ključne aktivnosti pri kreiranju baze podataka su:

• Modeliranje aplikacije

• Definisanje podataka neophodni za aplikaciju

• Organizovanje podataka u tabelama

• Uspostavljanje međusobnih veza između tabela

• Uspostavljanje zahtjeva indeksiranja i vrednovanja podataka

• Izrada i snimmanje svih potrebnih upita u vezi sa aplikacijama

Modeliranje aplikacije se odnosi na postupak pri kojem definišemo zadatke koje aplikacija treba da
obavi. Bilo bi dobro da definisane zadatke specifikujemo u određeni dokument koji nam može pomoći da
budemo usredsređeni na zadatak našeg programa. Prilikom organiziranja podataka u tabele možemo
lahko odrediti da li neki podatak pripada toj tabeli ili ne; npr. ako neki klub želi da prati informacije o
svojim članovima i zaposlenima, uprava kluba će u jednu tabelu staviti i zaposlene i članove. Obje grupe
zahtjevaju informaciju o imenu, adresi, telefonslom broju, dok zaposleni zhtjevaju i informacije o broju
socialnog osiguranja, visini plate i sl.

Ali ako napravimo više tabela gdje se svaki podatak pojavljuje samo jednom i mi ćemo prilikom izmjena
novu informaciju upisivati samo jednom.
Drugi način da se podaci normalizuju jeste da se formira tzv. tabela dijete. Tabela dijete je tabela u kojoj
svi unijeti podaci dijele zajedničku informaciju koja je smještena u nekoj drugoj tabeli. Ako uzmemo za
primjer neku porodicu gdje su kod svih ista prezimena, ista adresa, isti br. telefona, a različita imena,
njihove zajedničke podatke stavimo u jednu tabelu, a imena u drugu u tom slučaju tabela koja sadrži
imena članova je tabela dijete. Tabela pretraživanja je još jedan pristup smještaju informacija s ciljem
sprječavanja pojave suvišnih informacija i povećanje tačnosti unošenja podataka. Ona se obično koristi
za smještaj opštevažećih ulaznih podataka.

Kada neko u toku aplikacije unese takvu oznaku, program provjerava u odgovarajućoj tabeli da li ta
oznaka stvarno postoji. Kada normalizujemo podatke, međusobno povezane informacije obično
smještamo u nekoliko tabela. Međutim, kada je potrebno da pristupimo podacima želimo da vidimo
informacije iz svih tabela na jednom mjestu. Da bismo to postigli moramo formirati skupove zapisa koji
objedinjuju međusobno povezane informacije iz nekoliko tabela. Taj skup zapisa se formira upotrebom
SQL naredbe u kojoj navodimo željena polja, lokacije polja i odnos između tabela i te naredbe možemo
smjestiti kao upit u bazu podataka.

Upotreba upita ima nekoliko prednosti:

- premještanje aplikacije u server okruženje je jednostavnije,

- unošenje izmjena u SQL naredbu je jednostavnije,

- SQL naredbu možemo lakše koristiti na više mjesta u programu ili u više programa.

Ovi upiti rade brže od upita koji se izrađuju zadavanjem naredbe programa koda.

Dobro kreirana baza podataka omogućava:

• minimalno vrijeme potrebno za pronalaženje zapisa

• smještanje podataka na najefikasniji način tako da baza ne postane suviše velika

• najjednostavnije ažuriranje podataka

• zahvaljujući svojoj fleksibilnosti uključivanje novih funkcija koje bi se od programa

mogle zahtjevati
2.3. PRISTUPI BAZAMA PODATAKA- programski jezici (sredstva)

SQL omogućava puni pristup podacima u relacionim bazama podataka (kao što su: Oracle, SQL Server,
Acces, i dr.) tako što korisnik opiše podatke koje želi da vidi.

SQL omogućava i definisanje i modifikaciju izgleda tabela unutar baze podataka. Niti jedna operacija na
bazama podataka, izvršena direktno iz DBMS-a ili preko korisničke aplikacije, nebi mogla biti izvršena bez
direktne ili indirektne upotrebe SQL jezika. Često, sam SQL nije dovoljan ukoliko je potrebno izvršiti neki
upit u tačno određeno vrijeme ili ga ponoviti nekoliko puta. Zbog toga svaki DBMS pored SQL podržava
bar još jedan programski jezik pomoću kojeg se mogu izvršiti kompleksne operacije. Dakle, postoje još
neki programski jezici (sredstva) za pristup podacima koji se nazivaju Database API, a to su: ODBC, OLE
DB, JDBC, DAO, ADO…

ODBC –pomoću njega programeri mogu raditi sa tabelarnim podacima, kao što su SQL baze podataka ili
sa multidimenzionalnim podacima, kao što je OLAP kocke. Aplikacije za upravljanje bazama podataka
pozivaju funkcije u OBDC-u, a ODBC putem svojih drajvera za baze podataka, aplikaciji vraća podatke iz
baze.

OLE DB – se pojavio kao odgovor problemu pristupanja komleksnije organizacije podataka , kao što su
tekst fajlovi, e- mail sistemi i dr. To je nova verzija ODBC-a.

JDBC – je ekvivalent ODBC tehnologije namjenjen upotrebi prilikom razvoja aplikacija

DAO – se javlja kao rješenje u pravljenju objektnog modela za pristup bazi podataka koji sprečava da
dođe do eventualnih grešaka pri programiranju ODBC, OLE DB i JDBC.

On je sastavni dio Visual Basica. Služi za pristup MS Access bazama podataka. DAO također omogućava
pristup ODBC izvorima podataka i tu leži i njegov najveći nedostatak. Pošto se oslanja na Access, prilikom
pristupa ODBC bazama podataka sve naredbe za bazu podataka i svi podaci iz nje moraju proći kroz ovaj
dodatni sloj, što može znatno ugroziti performanse aplikacije.
ADO – nova tehnologija iz Mikrosofta čiji je cilj da zamijeni DAO kao standardni objektni model za
pristup bazama podataka.

3.0. O modelima podataka

Arhitektura največeg broja sistema baza podataka odgovara predlogu ANSI/SPARC studijske grupe
Američkog nacionalnog instituta za standarde, i poznata je kao ANSI arhitektura. Ova arhitektura
predstavljena je hijerarhijom apstrakcija, pri čemu svaki nivo hijerarhije uključuje specifični način
predstavljanja, reprezentaciju, objekata, odnosa među objektima i operacija nad objektima.

Hijerarhijska arhitektura omogućuje prirodnu dekompoziciju i efikasni razvoj sistema za upravljanje

bazama podataka. Najniži nivo ANSI arhitekture je unutrašnji nivo. On je najbliži fizičkoj reprezentaciji
baze podataka, koja u računarskom sistemu jedina zaista postoji. Zbog toga se unutrašnji nivo često i
zove “nivo fizičke baze podataka”. Sledeći nivo ANSI arhitekture je konceptualni (logički) i predstavlja
način na koji se podaci iz fizičke baze podataka predstavljaju korisniku u opštem slučaju. Najviši nivo
ANSI arhitekture je spoljašnji nivo koji predstavu o podacima iz baze prilagođava potrebama specifičnih
korisnika ili grupa korisnika.

Globalna ANSI arhitektura sistema baza podataka može se predstaviti shemom na slici 1.1.

Pogledi (podmodeli)

(spoljašnje šeme, spoljašnji nivo)

Model podataka
(konceptualna shema, logički nivo)

Strukture podataka, prosedure

(fizička baza podataka, unutrašnji nivo)

Slika 1.1

Reprezentacija koja se nalazi na “srednjem”, konceptualnom nivou ANSI hijerarhije zove se model
podataka. Modelom podataka predstavlja se logička struktura svih podataka u bazi i skup operacija koje
korisnik može izvršiti nad tim podacima. To znači da se na konceptualnom nivou mogu “vidjeti” svi
podaci iz fizičke baze podataka, samo što je njihova reprezentacija pogodnija za korisnika od fizičke (na
višem je nivou apstrakcije).

Pojedini korisnici ili grupe korisnika mogu imati svoja sopstvena specifična gledanja na model podataka
(npr. iz razloga zaštite ili udobnosti), pa se pogledi (podmodeli, spoljašnji nivo hijerarhije) nalaze iznad
modela u hijerarhiji apstrakcija. Isti podaci iz fizičke baze podataka (i sa konceptualnog nivoa), na ovom
nivou mogu se raznim korisnicima predstaviti na razne načine, dok se postojanje nekih podataka može
od nekih korisnika i sakriti. Zato postoji tačno jedan model podataka u sistemu, koji se odnosi na
cjelokupnost baze podataka, i veći broj spoljašnjih pogleda, od kojih se svaki sastoji od apstraktne slike
dijela baze podataka.

Na primer, baza podataka o studentima može da sadrži podatke iz dosijea studenata, sa ličnim podacima
i podacima o uspehu (predmetima, ocjenama, datumima polaganja, nagradama, kaznama) svakog
studenta. Na konceptualnom nivou podaci mogu biti predstavljeni tabelama DOSIJE, NASTAVNI PLAN,
NAGRADE I KAZNE i POLAGANJE. Na spoljašnjem nivou, korisnicima statističkih obrada ova baza
podataka može se predstaviti kao da sadrži samo podatke o uspjehu (npr. u virtuelnoj tabeli USPJEH PO
PREDMETIMA); ostali, lični podaci koji mogu da identifikuju studenta, skrivaju se od statističkih
aplikacija. Različitim podgrupama korisnika mogu odgovarati još apstraktnije predstave o podacima, koje
odgovaraju višim nivoima podmodela.

Primarni cilj modela podataka u kontekstu baza podataka jeste da obezbjedi formalni sistem za
predstavljanje podataka i manipulisanje podacima u bazi podataka.
3.1. Nastanak i razvoj relacionog modela baze podataka

Relaciona baza podataka se sastoji od serije dvodimenzionalnih tabela. Termin "relaciona baza
podataka" dolazi od činjenice da ona koristi relaciju (odnos) umjesto datoteke.

Relacija je tabela sastavljena od slogova. Unutar jedne tabele može postojati samo jedna vrsta slogova ili
entiteta. Relacione tabele pokazuju logičke, a ne fizičke odnose, a zanemaruje redosljed podataka
odnosno slogova uključenih u relaciju.

Relacioni model odvaja bazu podataka od operativnog sistema kao i od aplikacije. Kada se da zahtjev za
informacijama, sistem napravi tabelu koja sadrži te informacije. Standardni programski jezik za
izražavanje pristupa podacima i manipulaciju sa tabelama u relacionoj bazi podataka se naziva SQL
(Structured Query Language). U ovom jeziku, pitanja na jednostavnom engleskom jeziku se automaski
prevode u SQL. U ovom slučaju softverski program, koji se zove Natural language (prirodni jezik) i koji
dozvoljava upite u ograničenoj formi prirodnog jezika, analizira korisnikov upit, prevodi ga u upit na SQL,
prenosi SQL zahtjev DBMS-u i daje na displeju podatke korisniku.

Relacioni model je smišljen početkom osamdesetih godina od strane Ted Codda, uposlenika IBM
korporacije i trenutno je najraširenija paradigma za razvoj podataka.

3.1.1. Relacioni sistem za upravljane bazama podataka

Za realizaciju koncepta baze podataka pored odgovarajuće hardverske opreme potrebno je obezbediti i
programsku podršku (software), to jest zbirku programa koja predstavlja sistem za upravljanje bazom
podataka (DBMS - Data Base Management System).

DBMS u opštem slučaju ima dvije osnovne funkcije. Prva je da memoriše i održava podatke koji
izražavaju svojstva posmatranih objekata (entiteta). Ova funkcija se obavlja pomoću jezika za definisanje
podataka i strukturu podataka (DDL - Data Definition Language). Druga funkcija omogućava kontrolisan
pristup do memorisanih podataka i prikazivanje podataka na zahtev korisnika. Za sprovođenje ove
funkcije koristi se jezik za manipulaciju podacima (DML - Data Manipulation Language).

Baza podataka i aplikacije koje se na nju oslanjaju podložni su čestim promenama. Osim periodičnih
promjena izazvanih razvojem opreme (pojava “moćnijih” računara, veće brzine, memorijskog kapaciteta
i dr.), baza podataka izložena je promjenama korisničkih zahteva. Novi uslovi i pravila poslovanja
reflektuju se ne samo na promjene parametara korisničkih programa - aplikacija, već i na promjene u
fizičkoj i logičkoj strukturi baze podataka. DBMS ima ulogu da obezbjedi korisniku uvijek istu dostupnost
podataka bez obzira na eventualne promjene. On poznaje fizičku i logičku strukturu baze na jednoj strani
i zahtjeve korisnika programa na drugoj strani, što mu omogućava da djeluje kao specifičan posrednik
(interface).

Relaciona baza podataka se svojom razvijenom teorijskom osnovom i jednostavnim izražavanjem

odnosa između podataka u obliku dvodimenzionalnih tabela, izdvojila u odnosu na druge baze podataka
(hijerarhijske i mrežne). U njoj su podaci prezentovani skupovima vremenski promenljivih relacija.

Relacioni sistem za upravljanje bazom podataka (RDBMS - Relation Data Base Management System)
omogućava obavljanje najrazličitijih operacija nad relacijama i kombinovanje relacija da bi korisniku
obezbjedio odgovore na sva pitanja koja imaju smisla s obzirom na sadržaj baze podataka.

Osnivač relacione teorije E.F.Codd, još 1985. godine, definisao je 12 strogih pravila koja mora zadovoljiti
RDBMS da bi s pravom nosio epitet “relacioni”. Osnovni princip na kojem se zasnivaju pravila glasi:
“Svaki sistem koji tvrdi da je relacioni sistem za upravljanje bazom podataka, ili se tako reklamira, mora
biti u mogućnosti da u potpunosti upravlja bazom podataka svojim relacionim sposobnostima."

Iako je od vremena definisanja pravila ,do danas, razvoj ovih sistema bio intenzivan, još uvijek se na
tržištu softvera nije pojavio proizvod koji u potpunosti ispunjava svih 12 uslova.

Osnovna komponenta sistema za upravljanje relacionim bazama podataka koju korisnik vidi jeste
relacioni upitni jezik. To je sredstvo kojim korisnik ostvaruje komunikaciju sa relacionom bazom
podataka, kojim izražava i zadovoljava sve zahtjeve vezane za podatke u bazi. Zato se, sa korisničke tačke
gledišta, upitni jezik često identifikuje sa kompleksnim sistemom za upravljanje bazama podataka, koji u
stvari te zahteve izvršava, korektno i efikasno.

Sredstvo kojim sistem za upravljanje bazama podataka omogućuje većem broju korisnika istovremeni
pristup podacima, uz punu bezbjednost i korektnost podataka, jeste transakcija.

Transakcija je logička jedinica posla i može da se sastoji od jedne ili većeg broja radnji nad bazom
podataka, pri čemu obezbeđuje uslov da podaci i odnosi među njima, poslje završetka transakcije,
korektno odražavaju realnost koja se tim podacima modelira. Upravljanje transakcijama omogućuje da
se svi zahtjevi korisnika korektno izvršavaju, a realizuje se posebnim komponentama koje koristi sistem
za upravljanje bazama podataka.

Funkcija SUBP kojom se regulišu prava pristupa pojedinih korisnika pojedinim objektima (podacima i
drugim resursima), kao i prava izvršenja raznih operacija nad tim objektima, zove se autorizacija. Ona se
dijelom realizuje mehanizmom pogleda, ali i specifičnim podsistemom autorizacije i prava korisnika.

Poseban značaj u radu sa relacionim bazama podataka ima struktuiranje i organizacija samih podataka.
Podatke je na nivou korisnika potrebno struktuirati, a na fizičkom nivou organizovati tako da njihovo
održavanje bude najlakše, a operisanje njima najefikasnije. Skup postupaka kojima se dolazi do dobro
struktuiranih podataka u bazi podataka naziva se metodama logičkog projektovanja baze podataka.

Skup postupaka kojima se podaci fizički organizuju u bazi, tako da im je pristup i održavanje
najefikasnije, naziva se metodama fizičkog projektovanja, tj. metodama fizičke organizacije podataka.

Značajan segment relacione tehnologije predstavljaju distribuirane baze podataka. Mada su sistemi za
upravljanje distribuiranim bazama podataka takođe relacioni, problemi koji se u njima moraju rješavati,
kao i metode za njihovo rješavanje, znatno su složeniji nego u centralizovanim sistemima

3.1.2. Predstavljanje podataka

Svi podaci u relacionoj bazi predstavljaju se na logičkom nivou na jedinstven način - preko vrijednosti u
tabelama.

Pod pojmom “svi podaci” podrazumevaju se podaci koje je korisnik definisao i unio u bazu bez obzira na
to da li je riječ o:

- osnovnim podacima (koji se odnose na vrednosti atributa),

- tzv. meta-podacima (kojima su definisani nazivi tabela, kolona i dr.), ili

- definiciji različitih pravila kao što su pravila integriteta.

Naime, nezavisno od toga na šta se podaci odnose, oni su u relacionoj bazi dostupni kao neke vrijednosti
u određenim tabelama. Na taj način obezbeđena je jedinstvena struktura podataka i meta-podataka u
sistemu.

3.1.3. Pristup podatcima

Svakom osnovnom podatku (konkretnoj vrijednosti kolone u nekom slogu tabele) u relacionoj bazi uvijek
se može pristupiti korišćenjem kombinacije imena tabele (relacije), vrijednosti primarnog ključa i imena
kolone (atributa).

Posljedica navedene osobine je da relacioni model omogućava lako rukovanje podacima na logičkom
nivou, s obzirom na to da se do podataka dolazi bez primene postupka sekvencijalne pretrage ili nekog
sličnog, u svakom slučaju manje efikasnog postupka.
Mnogi sistemi koji se danas na tržištu softvera reklamiraju kao relacioni pokazuju izvesne nepravilnosti u
odnosu na opisano pravilo. Naime, oni dozvoljavaju kreiranje tabela bez definisanog primarnog ključa, to
jest tabela koje sadrže slogove sa potpuno identičnim vrijednostima u svim kolonama. U takvim
slučajevima, tabele bez definisanog primarnog ključa gube smisao relacije definisane u relacionom
modelu. Pristup podacima u takvim tabelama je otežan, a samim tim otežano je i rukovanje podacima.

Navedeni problem mogao bi se izbjeći uvođenjem “discipline” u postupku kreiranja relacija, tj.
obaveznom definicijom primarnog ključa za svaku tabelu.

3.1.4. Sistemski tretman „NULL“ vrijednosti

Potpuno relacioni sistem za upravljanje bazom podataka obavezno sistemski podržava predstavljanje
informacija koje nedostaju u bazi, upotrebom tzv. Null vrijednosti, nezavisno od tipa podataka.

Null vrijednost je specifičan indikator različit od praznog niza karaktera ili niza “blankova” i različit od
nule ili bilo kog drugog broja.

RDBMS obezbeđuje jedinstvenu prezentaciju Null vrijednosti, a na taj način i jednostavno rukovanje tim
vrijednostima. Vrijednost Null može biti potencijalna vrijednost svake kolone bez obzira na njen tip, osim
u slučaju kad se izričito zahtjeva da vrijednosti u nekoj koloni ne smiju biti nedefinisane (dodatno
ograničenje NONULL). Izuzetak predstavljaju kolone primarnog ključa koje, kao identifikatori zapisa u
tabeli, ne smiju uzeti Null vrijednost.

3.1.5. Neprekidan pristup dinamičkom katalogu relacionog modela

Relacioni sistem posjeduje katalog (riječnik) podataka koji se na logičkom nivou predstavlja na isti način
kao i sami podaci, tako da ovlašćeni korisnici mogu primenjivati jedinstveni relacioni jezik za pretragu
ovih meta-podataka.

Pod pojmom "katalog" podrazumeva se direktorij u kojem se nalaze sistemske definicije podataka.
Uvidom u katalog podataka može se saznati koje kolone poseduju određene tabele, koja su ograničenja
definisana, kao i druge informacije koje se odnose na sistemske tabele. U slučaju distribuiranih baza
podataka, katalog treba da sadrži podatke o lokaciji svakog djela baze.

Katalog nazivamo “dinamičkim” zbog činjenice da definicije podataka koje se mogu vidjeti odgovaraju
upravo tekućem stanju u bazi podataka. Bez obzira na to koji korisnik, na kojoj lokaciji, ili u kom djelu
opisa baze napravi neku izmjenu, novo stanje će biti dostupno za čitanje svim ovlašćenim korisnicima.

“On line” pristup katalogu praktično znači da je trenutnom stanju opisa baze obezbeđen neprekidan
pristup. Međutim, sve dok se stanje u opisu baze konačno ne promjeni, ovlašćenim korisnicima je
vidljivo stanje prije promjena. Naime, u relacionoj bazi sve operacije koje mjenjaju opis podataka
započinju i završavaju se određenim naredbama kojima se sistem obaveštava da je ažuriranje
kompletno. “On line” uvidom ne vidi se ni jedna izmjena koja nije konačna.
Veoma je važna činjenica da pravo pristupa opisu baze imaju samo za to ovlašćeni (autorizovani)
korisnici.

3.1.6. Sveobuhvatan jezik za rad sa podacima

Bez obzira na to koliko jezika i koliko načina korišćenja terminala podržava, relacioni sistem mora
posjedovati bar jedan jezik čije se naredbe mogu izraziti kao niz karaktera sa dobro definisanom
sintaksom, a koji sveobuhvatno može da podrži:

1) definiciju podataka

2) definiciju pogleda

3) rukovanje podacima

4) definiciju pravila integriteta

5) prava u sistemu (autorizaciju)

6) granice transakcije (BEGIN, COMMIT, ROLLBACK).

U navedenih 6 stavki obuhvaćene su sve funkcije jednog RDBMS-a, koje se saglasno suštini ovog pravila,
moraju odvijati u jedinstvenom okruženju, unutar jednog jezika.

To podrazumjeva da se svaki zadatak može kompletno izvršiti, bez napuštanja takvog sveobuhvatnog
okruženja.

Za administratore sistema postojanje sveobuhvatnog jezika omogućava da se, prilikom rukovanja

podacima, izbjegne niz suvišnih koraka.

Ilustracije radi, kad je potrebno sačuvati neke međurezultate ili slogove, izbegavaju se sledeći koraci:

- napuštanje datog okruženja,

- ulazak u drugu aplikaciju i definisanje nove tabele u njoj,

- povratak u staro okruženje i unos podataka u kreiranu tabelu.

3.1.7. Ažuriranje pogleda

Relacioni sistem poseduje efikasan algoritam za ažuriranje svih pogleda koji se teorijski mogu ažurirati.
Rezultat ovog algoritma smješta se u katalog (riječnik) baze podataka.

Pogledi predstavljaju virtuelne relacije koje fizički ne postoje ali se u svakom drugom smislu ponašaju
kao relacije. Može se reći da su to izvedene tabele nad kojima je moguće definisati upite kao i nad bilo
kojim postojećim tabelama u bazi. Pogled se ponaša kao “dinamički prozor” kroz koji se gledaju relacije
baze i putem kojeg je moguće vršiti promjene koje će se automatski reflektovati na relacijama baze.
Svaki put kada korisnik čita podatke kroz pogled, sistem formira rezultujući skup slogova na osnovu
definicije pogleda i podataka u tabelama baze. Rezultujući skupovi slogova, odnosno posebne kopije
podataka koji se vide kroz pogled, ne čuvaju se u sistemu, već se samo u katalogu baze čuvaju definicije
pogleda.

Pod ažuriranjem pogleda podrazumjevaju se operacije brisanja i dodavanja slogova, kao i modifikovanje
postojećih slogova. Codd naglašava da je “pogled teorijski moguće ažurirati ako postoji vremenski
nezavisan algoritam koji nedvosmisleno određuje niz izmena u baznim relacijama, čiji je konačni efekat
upravo zahtjevana izmjena nad pogledom."

3.1.8. Dodavanje, brisanje i modifikovanje na visokom nivou

Ne samo za izdavanje podataka, već i za operacije dodavanja, brisanja i modifikovanja podataka postoji
mogućnost da se rukuje baznim i izvedenim relacijama u cijelosti kao operandima.

Glavni objekat u relacionoj bazi podataka je relacija. Sve operacije relacione algebre rukuju relacijama
kao operandima, a rezultat svake operacije je takođe neka relacija. Ako izdvojimo jedan konkretan slog
iz relacije možemo ga posmatrati kao relaciju sa jednim slogom. Konkretan podatak (osnovna vrijednost)
izdvojen iz baze, takođe predstavlja relaciju nad samo jednim atributom sa samo jednim slogom (tabela
sa jednom kolonom i jednim redom). U tom smislu u bazi podataka se uvijek rukuje sa relacijama u
cjelosti.

Ova činjenica pozitivno utiče na optimizaciju postupka sprovođenja operacija u sistemu. Ilustracije radi,
posmatrajmo čitanje cijele relacije. Ukoliko za svaki slog koji se čita moramo sistemu da zadamo
posebnu komandu, sistem mora pojedinačno da optimizuje i izvršava svaku od njih. U slučaju čitanja
cijele relacije jednom operacijom, sistem određuje najbolji način pristupa slogovima u globalu za cijelu
relaciju. Iste prednosti odnose se i na operacije brisanja, modifikovanja i dodavanja slogova.

Opisano pravilo ima značajnu ulogu u obradi transakcije nad distribuiranom bazom podataka. Činjenica
da se relacijama rukuje kao operandima, reflektuje se na efikasniju obradu podataka. Uštede se
ostvaruju ne samo u vremenu već i u troškovima komunikacija. Upotrebom ovakvih upita na visokom
nivou izbjegava se prenos pojedinačnih zahtjeva, za svaki slog, prema udaljenom sistemu.

3.1.9. Fizička nezavisnost

Relacioni sistemi u obavezi su da zadovolje pravilo fizičke nezavisnosti čija je suština u sljedećem:
aplikacioni program i aktivnosti na terminalima ostaju neizmenjeni kada se promjeni fizička organizacija
baze ili fizički metod pristupa podacima.

Aplikacije i programi rukuju podacima isključivo na semantičkom i logičkom nivou. Sama fizička
organizacija podataka predstavlja internu stvar sistema i ima uticaja jedino na performanse (brzinu
pristupa podacima, odziv sistema). Neophodno je da u sistemu postoji oštra granica između logičkog
modela podataka i fizičkog razmještaja podataka na mediju.
Kreiranje i brisanje indeksa nad nekom tabelom iz baze, ne smije imati uticaja na logičku strukturu
programa i naredbi. Kod nerelacionih sistema za upravljanje bazom podataka sami programi bi morali
pretrpjeti izmjene u zavisnosti od postojanja indeksa nad određenim tabelama.

Navedeno pravilo omogućava da se uoče dvije osnovne grupe korisnika u sistemu:

- projektanti i programeri,

- administratori baze podataka.

Uloga projektanata i programera je da se bave logičkim dizajniranjem i programiranjem, dok se

administratori baze, između ostalog, bave i održavanjem interne organizacije podataka u sistemu.
Osnovna komponenta koja u aktuelnim relacionim sistemima obezbeđuje fizičku nezavisnost je tzv.
optimizator SQL naredbi.

Optimizator za svaku SQL naredbu određuje optimalan plan izvršenja u smislu vremena odziva i ukupnog
utroška resursa sistema. Sam proces optimizacije odvija se u trenutku izvršenja naredbe, a sastoji se od
analize dostupnih indeksa i načina pristupa podacima. Plan izvršavanja naredbe za koji se predviđaju
najbolje performanse u obradi bira se na osnovu heurističkih pravila ili statističkih podataka o bazi.

3.1.10. Logička nezavisnost

Kada se na tabelama baze izvrše izmjene koje ne izazivaju gubljenje podataka ili logička oštećenja,
aplikacioni programi i aktivnosti na terminalima ostaju logički neoštećeni. Ukoliko RDBMS ispunjava
uslov ažuriranja pogleda onda će bez problema moći da zadovolji i pravilo logičke nezavisnosti.

Kada spajamo dvije tabele mogućnost ažuriranja pogleda nad novom tabelom uslov je za očuvanje
logičke nezavisnosti.

Logička, kao i fizička nezavisnost, za posljedicu imaju jednu veoma važnu prednost koju relacioni sistemi
pokazuju u odnosu na nerelacione. Prednost se sastoji u tome što greške u početnom dizajnu modela
podataka nemaju teške posledice i dozvoljavaju naknadne korekcije. Projektanti u tom smislu mogu da
bez prevelikog opterećnja kreiraju inicijalne modele podataka, a da ih kasnije, čak i u poodmakloj fazi
implementacije aplikacije, ponovo dorađuju i prilagođavaju novim zahtjevima.

3.1.11. Integritetska nezavisnost

Sva pravila integriteta definišu se u okviru definicije baze podataka i čuvaju se u katalogu podataka, a ne
u aplikacionim programima.

Integritet podataka djeli se na 4 kategorije:

- integritet entiteta,
- integritet domena,

- referencijalni integritet, i

- korisnički definisan integritet.

Integritet entiteta podrazumeva da svaka vrijednost primarnog ključa mora biti jedinstvena na nivou
cijele relacije. Osim toga, mora biti ispunjen uslov da ni jedna stavka u koloni primarnog ključa ne smije
imati NULL vrednost.

Integritet domena određuje skup dozvoljenih vrijednosti kolone. Održavanje integriteta domena postiže
se navođenjem dozvoljenog tipa podataka, dozvoljenog formata za unos podataka, ili zadavanjem skupa
mogućih vrijednosti.

Referencijalni integritet odražava definisane odnose (relacije) među tabelama kada se u njih dodaju ili
se iz njih brišu zapisi.

Korisnički integritet omogućava definisanje specifičnih poslovnih pravila. Naime, za bazu podataka mogu
postojati dodatna ograničenja, formirana na osnovu određenih pravila poslovanja, koja definišu važeće
podatke u bazi.

RDBMS treba da obezbjedi definisanje svih navedenih kategorija integriteta podjezikom relacionih
podataka. Kada se pravila integriteta jednom definišu ona sprečavaju upis podataka koji ne
zadovoljavaju te definicije (nekonzistentni podaci).

U slučaju promjene pravila integriteta dolazi do izmjene jednog ili više iskaza ograničenja u katalogu
podataka, ali logička struktura programa i aktivnosti na terminalima ostaju neizmenjeni.

Jedino moguće sredstvo za čuvanje integriteta baze podataka, kod postojećih relacionih sistema, je
korišćenje tzv. okidača (Triggers). Okidač je pokretač procedure koja se automatski poziva kad god dođe
do dodavanja, ažuriranja ili brisanja podataka u tabeli. Okidač je objekat baze koji se čuva u katalogu
podataka i svaki je pojedinačno pridružen jednoj tabeli, pri čemu se navodi koje od operacija dodavanja,
ažuriranja ili brisanja izazivaju njegovo izvršenje. Tako se, na primer, za bazu podataka tekućih računa
građana u nekoj banci može definisati okidač koji se izvršava prilikom brisanja slogova iz tabele, a ima
ulogu da onemogući brisanje računa čije stanje nije ravno nuli.

3.1.12. Distribuciona nezavisnost

U zavisnosti od toga koliko primeraka vrijednosti logičkih objekata iz baze postoji i na koliko lokacija se
oni nalaze, razlikujemo dva tipa arhitekture sistema baze podataka:

1. centralizovani sistem, i

2. distribuirani sistem.

U centralizovanom sistemu baza podataka je skup logičkih objekata i njihovih vrijednosti, gdje postoji
samo jedan primjerak vrijednosti svakog logičkog objekta baze.
U distribuiranom sistemu vrijednost nekog logičkog objekta može imati više primjeraka, memorisanih u
više lokalnih baza, na različitim lokacijama.

E.F.Codd je definisao distribucionu nezavisnost RDBMS-a kao njegovu sposobnost da aplikacioni

programi i aktivnosti na terminalima ostanu logički neoštećeni:

- kada se prvi put uvede distribucija podataka, i

- kada se podaci predistribuiraju.

Prvi slučaj podrazumeva da je sistem prvobitno upravljao samo nedistribuiranim podacima, a onda je
došlo do njihove distribucije. U drugom slučaju sistem je već upravljao distribuiranim podacima, ali je
došlo do promjene njihovog rasporeda.

Relacioni sistem koji je distribuciono nezavistan omogućava da jedna transakcija rukuje podacima sa više
udaljenih sistema, a da korisnik pri tome ima utisak da se sve odvija u okviru lokalnog sistema. Ova
osobina daje veliku moć naredbama jezika podataka na visokom nivou, koje mogu unutar jedne
komande kombinovati podatke sa različitih mjesta.

3.1.13. Rad sa jezicima niskog nivoa

Iako u obavljanju svojih funkcija koristi jezike visokog nivoa (princip grupnog pristupa slogovima), sistem
za upravljanje bazom podataka može da sadrži i neke od jezika niskog nivoa (pojedinačni pristup
slogovima) i da podržava njihov rad.

Uslov koji RDBMS treba da zadovolji je da se u radu sa jezicima niskog nivoa ne smiju narušiti ili zaobići
pravila integriteta i ograničenja izražena relacionim jezikom visokog nivoa.

Kod nerelacionih sistema čest je slučaj da jezici niskog nivoa zaobilaze definicije iz kataloga podataka. U
tom slučaju proces obrade se ne oslanja na zapamćene definicije podataka, pravila integriteta i
ograničenja.

Visoke mogućnosti SQL-a u pogledu rukovanja relacijama kao operandima (u cijelosti), uglavnom nisu
primjenljive u jezicima kao što su C i PASCAL, iz jednostavnog razloga što u okruženju ovih jezika relacija
nema odgovarajuću prezentaciju.

U cilju prevazilaženja ovog problema morao se obezbediti pristup i rukovanje podacima na nivou slogova
primjenom koncepta kursora (cursor).

Kursor u suštini predstavlja objekat definisan SELECT naredbom, nad kojim se mogu realizovati tri
operacije:

- otvaranje kursora (OPEN),

- dohvatanje sledećeg sloga iz kursora (FETCH), i

- zatvaranje kursora (CLOSE).

 Otvaranjem kursora formira se aktivni skup slogova (neka vrsta interne kopije slogova koji se smještaju
u memoriju). Nad tim skupom slogova izvršavaju se operacije dohvatanja jednog po jednog sloga sve dok
se ne dođe do posljednjeg iz izdvojene grupe. Zatvaranjem kursora oslobađa se memorijski prostor
aktivnog skupa slogova.

Opisani postupak pojedinačnog pristupa slogovima, čitanjem tabela pomoću kursora, obezbeđuje
konzistentnost čitanja baze podataka.

4.0. ZAKLJUČAK

Relacioni model podataka, koji se zasniva na matematičkoj teoriji skupova, predložen je još 1969. godine
od strane E.F.Codd-a, tada istraživača u IBM-ovim laboratorijama. Ovaj model je svojim osobinama
prevazišao tada aktuelne hijerarhijske i mrežne modele podataka.

Relacione baze podataka se projektuju u vidu tabela, indeksiranih po različitim pojmovima (poljima) i sa
više ključeva. Već pri njihovom kreiranju mogu se uspostaviti logičke veze između pojedinih tabela preko
zajedničkih polja tako da se na lak i jednostavan način dolazi do svih potrebnih podataka, bilo da se radi
o podacima samo iz jedne tabele ili se podaci dobijaju spajanjem više tabela u jednu novu, koja je
privremenog karaktera, a sadrži samo polja koja su potrebna korisniku. Do podatka se u tabeli dolazi
direktno pozivanjem odgovarajućeg indeksnog ključa pri čemu se pokazivač automatski pozicionira na
slog sa traženim podatkom.

Osnivač relacionog modela, u cilju zaštite epiteta “relacioni”, koji se sve češće iz komercijalnih razloga
pripisivao i nekim nerelacionim sistemima za upravljanje bazama podataka, definisao je 12 strogih
pravila koje mora poštovati jedan RDBMS. On je takođe i argumentovao postojanje niza pozitivnih
efekata koje u praksi postiže sistem ukoliko zadovoljava definisane kriterijume.

Osnovne prednosti potpuno relacionog sistema za upravljanje bazom podataka su:

- administratorima baze omogućeno je da u svakom trenutku znaju koje se vrste podataka nalaze u bazi i
kako se njima može pristupiti;

- produktivnost programera je poboljšana s obzirom na činjenicu da je podržano iteraktivno testiranje

programa i naredbi u jedinstvenom okruženju, unutar jednog jezika;

- opšta nezavisnost aplikacionih programa od podataka olakšava razvoj i održavanje informacionih

sistema (posljedica fizičke, logičke, integritetske i distribucione nezavisnosti);

- smanjeni su troškovi izmjena opisa podataka u bazi, prilikom prilagođavanja programa novim
zahtjevima ( promjene performansi sistema, organizacione promjene, promjene pravila poslovanja)

- troškovi komunikacija u distribuiranoj bazi podataka su smanjeni zahvaljujući osobini dodavanja,

brisanja i modifikovanja na visokom nivou;
- obrada svih jezika za manipulaciju podacima u relacionom sistemu oslanja se na zapamćene definicije
podataka, uključujući pravila integriteta i ograničenja;

Poznavanje relacionog modela osnovni je preduslov za uspješno dizajniranje baze podataka koja će
podržavati rad prilagodljive i lako dogradive aplikacije.