Modeli i baze podataka Modeliranje i uvodni pojmovi · Modeli i baze podataka 2 Realan sistem je uređen i međuzavisan skup objekata koji formiraju cjelinu. . Slika 1.1 odnos realnog

Miroslav Mihaljišin

PRIRUČNIK SAMO ZA INTERNU UPOTREBU

kompilacija sadržaja sa sajta razno.sveznadar.info i knjige Računarstvo i informatika 2.

Modeli i baze podataka

SadržajModeliranje i simulacija ................................................................................................................................. 1

1.1 Terminolgija: Šta je ustvari model .......................................................................................................... 1

1.1.1 Pojam sistema i realnog sistema ........................................................................................................... 1

1.1.2 Odnos modela, realnog sistema i teorije ............................................................................................... 2

1.1.3 Cilj modeliranja .................................................................................................................................... 3

1.1.4 Procedure modeliranja .......................................................................................................................... 4

1.2 Metodologija i klasifikacija modela ........................................................................................................ 4

1.3 Podjela modela na osnovu formalizma i detaljnosti ................................................................................ 5

1.1.1 Neformalni opis modela ................................................................................................................... 5

1.1.2 Formalni opis modela ....................................................................................................................... 5

1.1.3 Savršeni i referentni modeli .............................................................................................................. 5

1.4 Formalna podjela modela ........................................................................................................................ 6

1.4.1 Fizički modeli ................................................................................................................................... 6

1.4.2 Apstraktni modeli ............................................................................................................................. 7

1.4.2.1 Opisni (verbalni) modeli ................................................................................................................ 8

1.4.2.2 Analogni modeli ............................................................................................................................ 8

1.4.2.3 Matematčki modeli ....................................................................................................................... 9

1.4.2.4 Konceptualni modeli...................................................................................................................... 9

1.4.2.5 Računarski i simulacioni modeli ..................................................................................................10

1.5 Simulacija ...................................................................................................................................................11

1.5.1 Šta je simulacija ...................................................................................................................................11

1.5.2 Modeliranje i simulacija ......................................................................................................................11

1.5.3 Životni ciklus simulacije: Koraci simulacionih procesa ......................................................................12

1.5.4 Objedinjeni jezik modeliranja – UML ......................................................................................13

1.6 Simulacija dinamičkih sistema ...............................................................................................................14

1.6.1 Statički i dinamički sistemi ..............................................................................................................14

1.6.2 Deterministički i stohastički sistemi ................................................................................................15

1.7 Vrste analize modela ..............................................................................................................................15

1.8 Razvoj modeliranja i simulacije .............................................................................................................16

1.9 Kratki pregled razvoja modela baza podataka ........................................................................................18

1.9.1 Davna istorija ...................................................................................................................................18

1.9.2 Istorija: Vrijeme dokazivanja ..........................................................................................................18

1.9.3 Vrijeme stvaranja standarda ............................................................................................................18

1.9.4 Moderna vremena ............................................................................................................................19


2. Sistem za upravljanje bazom podataka – Uvod- .....................................................................................20

2.1 Šta su to baze podataka ..........................................................................................................................20

2.1.1 Sistem za upravljanje bazom podataka ...........................................................................................20

2.1.2 Podatak i informacija ......................................................................................................................21

2.1.3 Entiteti i atributi ..............................................................................................................................21

2.1.4 Domen atributa ...............................................................................................................................22

2.2 Arhitektura baze podataka i njeno predstavljanje šemama ....................................................................22

2.3 Jezici za upravljanje bazama podataka ...................................................................................................23

2.3.1 Softverski paketi za rad s bazama podataka ...................................................................................24

2.3.2 Životni ciklus baze podataka ..........................................................................................................24

2.3.2.1 Analiza potreba ............................................................................................................................25

2.3.2.2 Modeliranje podataka ..................................................................................................................25

2.3.2.3 Implementacija.............................................................................................................................25

2.3.2.4 Testiranje .....................................................................................................................................25

2.3.2.5 Održavanje ...................................................................................................................................25

2.4 Apstrakcija i šeme za modeliranje baze podataka ..................................................................................26

2.5. Relacioni model ................................................................................................................................27

2.5.1 Modeli baze podataka .....................................................................................................................27

2.5.2 Vrste modela baza podataka ...........................................................................................................27

2.5.2.1 Ravni (tabelarni) model ...............................................................................................................28

2.5.2.2 Hijerarhijski model podataka .......................................................................................................28

2.5.2.3 Mrežni model podataka ...............................................................................................................28

2.6 Pojam relacije i relacione baze ...............................................................................................................29

2.6.1 Šema relacije: Relaciona tabela i Šema relacione baze ..................................................................30

2.6.2 Predstavljanje relacija i šema relacija .............................................................................................30

2.6.3 Osnovne osobine koje treba da ima relacioni model .....................................................................31

2.6.3.1 Zadatak: uvod u kreiranje relacionog modela ..............................................................................31

2.7 Kandidati za ključ i primarni ključ .........................................................................................................32

2.8 Veze kod relacionog modela baze ..........................................................................................................33

2.9 Kardinalnost entiteta ............................................................................................................................34

2.10 Dvanaest pravila koji određuju relacioni sistem (Je li Kod sujevjeran?) .............................................35

2.10.1 Sistemski tretman „NULL“ vrijednosti ........................................................................................36

2.10.2 Neprekidan pristup dinamičkom katalogu relacionog modela .....................................................36

2.10.3 Fizička nezavisnost .......................................................................................................................37

2.10.4 Logička nezavisnost ......................................................................................................................37

2.10.5 Integritetska nezavisnost ...............................................................................................................37

2.11 Tabelarna terminologija .......................................................................................................................38


Modeliranje i simulacija

1


1.1 Terminolgija:Štajeustvarimodel Model je približni prikaz sistema ili procesa koji služi za razumijevanje sistema, te njegovo mijenjanje ili upravljanje njime. Model je francuska riječ (modéle), koja se pojavljuje u sličnom obliku u većini evropskih jezika: njemački modell, italijanski modello, španski modelo, ruski модель. Originalno, riječ vuče korjene od latinskih riječi modellus tj. modulus (mjera, standard) i modus (način, mjera).

Prema Rječniku Oxford 2012 model je: „Osoba ili predmet koja se smatra za izuzetan primjer nečega1“.

“Umanjena slika planiranog ili postojećeg objekta” Webster New World Dictionary

“Matematički ili fizički sistem koji podleže specifičnim pravilima, a koristi se za razumijevanje fizičkih, bioloških i društvenih sistema sa kojima je u određenoj analogiji” McGraw-Hill Dictionary of Scientific and Technical Terms U govornom jeziku ima više značenja, pa ćemo navesti neka: 1. Uzor, uzorak, obrazac. 2. Kalup po kojem se izrađuje neki predmet. 1. Osoba koja pozira umjetniku. 4. Predmet (najčešće odjevni ili ukrasni) načinjen samo u jednom primjerku; unikat. Modeliranje (ili modelovanje) je proces korišćenja modela umjesto realnog sistema. 1.1.1 Pojam sistema i realnog sistema Čak ni opšta teorija sistema (General systems theory) kojoj je pojam sistem polazni i bazični element, nema jedinstvenu definiciju pojma sistema već nudi više definicija. Za našu analizu ćemo uzeti najjednostavniju koja kaže: Sistem je uređeni skup elemenata. Kako postoje (često) i neuređeni sistemi možemo naglasiti da su neki objekti ili pojave sređeni: Sistem je skup objekata (realnih ili apstraktnih) koji čine cjelinu, gdje je svaki element koji čini objekt, zavisan i ima vezu sa najmanje jednim od preostalih elemenata, a svi zajedno grade i čine cjelinu koja postoji radi određenog cilja ili zajedničke svrhe2. Ako prihvatimo ovu definiciju sistem možemo simbolički predstaviti u obliku: S= {E, V, F} S - sistem; E - skup elemenata sistema; V - skup veza; F- funkcija cilja sistema. Realan svijet je izvor podataka za formiranje modela što je predstavljeno na Slici 1.1. Shodno ranijoj definiciji sistema:

1 Originalno: a person or thing that is considered an excellent example of something 2 Zajednički cilj i svrha ne znači da mu svi elementi doprinose.


2

Realan sistem je uređen i međuzavisan skup objekata koji formiraju cjelinu.

.

Slika 1.1 odnos realnog svijeta, sistema i modela 1.1.2 Odnos modela, realnog sistema i teorije Na osnovu iskustva i znanja, čovjek pomoću apstrakcije razvija model koji odgovara realnom sistemu. Nivo apstrakcije (koji najčešće znači uprošćavanje) utiče na validnost modela, tj. na valjanost i uspješnost predstavljanja realnog sistema preko modela. Model treba da što vjernije predstavi stvarnost, ali istovremeno da ima izabrane samo elemente i karakteristike sistema koje su značajne za realizaciju cilja modela (za projektovano istraživanje).

Slika 1.2 Teorija kao poveznica realnog sistema i modela Model se ne može uspješno realizovati ako nema odgovarajuću teoriju koja ga opisuje. Teorija je neophodan element koji povezuje model i sistem. Prije nastanka modela neophodno je formulisati teoriju. Model je uprošćena i idealizovana apstrakcija realnosti (realnog sistema) koja ne obuhvata sve aspekte realnog sistema, a realizuje se u određenoj okolini na osnovu teorije. Model3 je, dakle, praktično predstavljena teorija, koji služi za razumijevanje nekog realnog sistema, te njegovo mijenjanje ili upravljanje njime. U ovom slučaju pod teorijom smatramo uopštene principe i iskaze koji su dobijeni posmatranjem sistema. Znači u konkretnim podacima realnog sistema pronašli smo univerzalne principe: teoriju koja važi za model.

3 Ovdje smo na dvije uvodne stranice dali tri definicije modela. Ako vam se čini mnogo, postoji onoliko definicija modela koliko i autora koji se bave modeliranjem. Jedna knjiga o ovoj temi počinje sa 25 definicija modela koje se potom analiziraju i pravi sinteza od 5 predočenih definicija, koja objašnjava ovaj nesumnjivo interesantan i kompleksan pojam. Mi se nadamo da vam je pojam modela intuitivno jasan, a da ćete pravu predstavu o modelu i modeliranju imati na kraju ovog poglavlja.


3

Navedimo glavne elemente i osobine sistema koje ga određuju: elementi (komponente) sistema Granice sistema Struktura sistema Okolina sistema Veze sistema Cilj sistema Funkcije sistema Procesi Projektovanje i analiza sistema znači definisanje svih ovih elemenata. Vremenski slijed promjena stanja sistema naziva se proces. Procesi predstavljaju mehanizam pomoću kojeg sistem izvršava svoje funkcije i ostvaruje ciljeve, te su glavna osobina sistema. Na procese koji se dešavaju u sistemu i na stanja sistema utiču mnogobrojni faktori (od kojih smo glavne nabrojali), pa je postavka univerzalne teorije koja bi dovela do nekog univerzalnog modela bespredmetna. Takav pokušaj je dovođenje samog principa modela koji uprošćava stvarnost, do apsurda; zahtjevom za kompleksnim i univerzalnim ali da bude jednostavno. Pažnja treba da se fokusira na konkretnu prirodu problema i, zavisno od mogućih sredstava za njegovo rješavanje, definiše logika i teorijska postavka sistema. 1.1.3 Cilj modeliranja Modeliranje treba da omogući stvaranje jasne i realne predstave - vizuelizaciju sistema, tako da možemo da ga „vidimo“ onakvog kakav jeste, odnosno onakvog kakavog želimo da ga realizujemo. Model treba da omogući razumijevanje sistema, a time i bolju specifikaciju strukture i ponašanja sistema. Na osnovu modela trebalo bi biti moguće definisati šablon-obrazac koji pomaže prilikom konstruisanja ili upravljanja sistema. Očigledno je da su mnogobrojni ciljevi korištenja modela, a mogli bismo reći da su 4 glavna: 1) korišćenje modela umjesto realnog sistema radi sticanja ili provjere određenog saznanja 2) mogućnost analize dobijenih rezultata koja treba da obezbijedi efikasnije uprav-ljanje realnim

sistemom 3) smanjenje troškova projektovanja i izrade realnog sistema 4) izbjegavanje opasnosti eksperimenta nad realnim sistemom Različiti su zadaci na kojima se ostvaruju ovi ciljevi. Već i samo nabrajanje zadataka bi značilo nabrajanje gotovo svih ljudskih, proizvodnih, strateških, marketinških (itd, itd...) problema. Često se modeliranje pogrešno veže samo za izradu velikih sistema, jer i mali sistemi mogu imati koristi od njega. Ipak, što je sistem kompleksniji to je veća važnost mode-liranja.


4

1.1.4 Procedure modeliranja Elementarna procedura modeliranja realizuje se kroz 3 koraka:

1. definisati i obrazložiti svrhu modeliranja. 2. odrediti strukturu modela (projektovati dizajn modela). 3. kreirati model (obično pomoću matematičkog izraza).

U poglavlju 1.5.3 Životni ciklus simulacije ćemo se nešto detaljnije pozabaviti procedurama i koracima koji omogućavaju implementaciju modela u procesu simulacije.

1.2 Metodologija i klasifikacija modela Postoje različite metodologije modeliranja pa je moguća klasifikacija u odnosu na:

1. formalnu podjela modela prema formalnom opisu modela 2. metode modeliranja 3. formalizam i detaljnost 4. vrste promjenljive (analogni, digitalni, hibridni) 5. prirodu opsega vrijednosti promjenljivih modela 6. prirodu zavisnosti i opsega vrijednosti promjenljive ‘vrijeme’ 7. način definisanja kauzalnosti ulaza i izlaza: determinizam 8. metode predviđanje budućnosti (statističke i metode teorije vjerovatnoće) 9. linearnosti (jednostavne i višestruke regresije) 10. itd...

Analiza svake od ovih klasifikacija zavisi od njene konkretne primjene (namjene modela i simulacije). Klasifikacije omogućavaju da izaberemo pravi model za određen problem, ali često zbunjuju svojom kompleksnošću. Pokušaćemo to izbjeći dajući samo dvije:

podjelu modela na osnovu formalizma i detaljnosti formalnu klasifikaciju modela u odnosu na nivo apstrakcije i metode

Iste metode pojavljuju se u različitim klasifikacijama. Bez obzira na klasifikaciju kojoj pripadaju, mi ćemo posebnu pažnju obratiti na matematičke, konceptualne i računarske modele. Savremeno modeliranje je ustvari sin-teza više metoda, pa ćemo pokazati da se računarski model realizuje konceptualno, tako da mu je podloga matematički model.


5

1.3 Podjela modela na osnovu formalizma i detaljnosti 1.1.1 Neformalni opis modela Neformalni (ili slobodni) opis modela opisuje sistem tako da definiše:

objekte – to su dijelovi iz kojih se sastoji model; opisne promjenljive – opisuju stanje u kome se objekat nalazi u nekom vremenskom trenutku; pravila interakcije objekata – definišu kako objekti modela utiču jedni na druge i na opisne

promjenljive u cilju promjena njihovog stanja. On daje samo osnovne pojmove o modelu, zanemarujući (apstrahujući) sve ostale bez korištenja unaprijed propisanih procedura i strukture. To ima za posljedicu da neformalni model može biti:

1. nekompletan (ne sadrži sve situacije koje mogu da nastupe), 2. nekonzistentan (predviđanje dva ili više pravila za istu situaciju, što može dovesti do zabune i

kontradiktorne akcije), i 3. nejasan (kad nije precizno definisan redoslijed akcija).

Ovi problemi (1-3) se rješavaju pravilima i konvencijama u komuniciranju koji se nazivaju formalizmi pa se i model koji se pridržava tih pravila naziva model sa formalnim opisom. 1.1.2 Formalni opis modela Formalni opis modela opisuje sistem na nedvosmislen način tako da se obezbijedi preciznost i potpunost koristeći se unaprijed definisanom strukturom i procedurama. Omogućava i formalizovanje nekompletnosti, nekonzistentnosti i nejasnosti definišući stepene pouzdanosti. Kod formalnog opisa modela, model se može procjenjivati i u odnosu na detaljnost, što znači s obzirom na broj objekata i veza koje u sebe uključuje. Detaljnost se odnosi na odnos broja komponenti realnog sistema i broja komponenti modela koji opisuju realni sistem (nivo apstrahovanja -opažajnost). 1.1.3 Savršeni i referentni modeli Savršeni model je onaj model koji uključuje sve promjenljive i veze među njima kao u realnom sistemu pa je samim tim apsolutno pouzdan i valjan: Za iste ulaze daje iste izlaze kao i realan sistem. Ovakvi modeli se ne mogu praktično realizovati izuzev za ekstremno jednostavne i proste sisteme (za koje modeli nisu ni potrebni). Savršeni modeli su idealizacija stvarnih modela. Obično služe kao referentni modeli na osnovu kojih se razvijaju praktični modeli. Referentni model je skup smjernica i preporuka na osnovu kojeg se razvija (projektuje) neki sistem. Najčešće je propisan od neke nadležne organizacije koja propisuje standarde kako treba da izgleda uređaj-sistem. Ako proizvođač želi da proizvodi neki uređaj on treba da se pridržava propisanih pravila. Njegov uređaj treba da zadovolji propisane procedure definisane referentnim modelom. Jedan od primjera je OSI referentni mrežni model. OSI referentni model (Open Systems Interconnection) je konceptualni model koji se koristi kao smjernica za razvoj uređaja i programa pri mrežnim komunikacijama. To je opisni model koji je stvorila međunarodna organizacija za standardizaciju ISO (International Organization for Standardization). Proizvođačima se propisuje skup standarda i tako osigurava kompatibilnost i povezivanje među različitim mrežnim tehnologijama. TCP/IP (Transmission Control Protocol/ Internet Protocol) su protokoli pomoću kojih se vrši praktična implementacija OSI modela. Odnos OSI i TCP/IP predstavljen je na Slici 1.3. TCP/IP je model razvijen na osnovu OSI referentnog modela.


6

Slika 1.3 Ilustracija koja pokazuje odnos OSI modela i TCP/IP

gdje je OSI referentni model preuzeto sa: http://www.protocols.com/pbook/tcpip1/

1.4 Formalna podjela modela Standardna klasifikacija metoda izrade modela, zasnovana na podjeli prema nivou apstrakcije i vrsti modeliranja, predstavljena je na Slici 1.4.

Slika 1.4 Standardna klasifikacija modela Pod terminom fizički misli se na materijalne (hemijska struktura molekula, model aviona), a klasa apstraktnih modela predstavlja simboličke mentalne modele (koji mogu imati različitu reprezentaciju u zavisnosti od metode predstavljanja: od verbalnog opisa preko analogije i matematičke analitike do konceptualne predstave računarskim modelima i simulacijama). 1.4.1 Fizički modeli Fizički model često se naziva i samo model, ali ako želimo da napravimo razliku u odnosu na druge vrste (naročito konceptualni) naglasićemo da je riječ o fizičkom modelu. Fizički modeli sistema predstavljaju srazmjerno umanjenu kopiju realnog sistema iz koga su izdvojene bitne fizičke i funkcionalne karakteristike. Objekt modeliranja može biti ekstremno mali (na primjer, atom) pa u tom slučaju fizički model predstavlja uvećanje.


7

Slika 1.5 Odnos i interakcija fizičkog i apstraktnog modela Mada je jasno (vidi 1.1.2 Odnos modela, realnog sistema i teorije i Sliku 1.5) naglasimo: I kod izrade fizičkog modela se polazi od logičkog modela (apstrakcije), a rezultat je izrađeni fizički model. Kada je definisan fizički model nekog fizičkog (realnog) sistema, idući korak bi bio stvaranje matematičkog modela, koji predstavlja matematičku interpretaciju fizičkog modela, pomoću odgovarajućih fizičkih zakonitosti, koje su predstavljene analitički. Statički modeli zadržavaju uvijek iste karakteristike, dok se dinamički mijenjaju u zavisnosti od promjene ulaza. Dinamički aspekti modela se fokusiraju na njegovo ponašanje, kreirajući model procesa u vremenskom domenu. Napomenimo da je korištenje fizičkih modela ograničeno troškovima i vremenom izrade. 1.4.2 Apstraktni modeli Osnov apstrakcija je promišljanje i analiza (odnosno način izdvajanja nekih osobina i svojstava predmeta od samog predmeta), pa se metode modeliranja mogu podijeliti prema načinu apstrakcije pri obavljanju i prezentovanju analize. Mentalni (misaoni) modeli su modeli nastali apstrakcijom. Predstavljaju apstrakciju koju stvara ljudski um. Omogućavaju komunikaciju među ljudima, planiranje aktivnosti itd. Na Slici 1.6 možete vidjeti strukturnu šemu ovog modela kao i osnovne elemente koji određuju mentalni model i njegov odnos prema sistemu i realnom (stvarnom) svijetu. Ovaj model omogućuje donošenje odluke, na osnovu unaprijed propisanih pravila i strategije i strukture koje model sadrži.

Slika 1.6 Strukturna šema mentalnog modela


8

1.4.2.1 Opisni (verbalni) modeli Kod opisnog metoda, analiza sistema ili njegovih dijelova se vrši opisno, opisivanjem u vidu teksta. Verbalni model je način predstavljanja mentalnih modela govornim jezikom. Uobiča-jeno se predstavlja u pisanom obliku i spada u klasu neformalnih (vidi 1.4) modela. Opisni modeli su široko primijenjeni i koriste se u svakidašnjim aktivnostima. Osnovne mane ovog modela su ograničenost pri rješavanju složenih problema zbog mogućnosti različite interpretacije i dvosmislenosti pri shvatanju opisa, kao i proiz-voljnost pri ocjeni značaja pojedinih faktora. 1.4.2.2 Analogni modeli Analogni modeli su zasnovani na fizičkoj sličnosti i ekvivalenciji sa nekom od karakteristika fizičkog–realnog sistema, gdje se putem analogije dolazi do rješenja problema. Kao primjer koji ilustruje ovaj metod navešćemo metod elektronsko-hidrauličke analogije prikazan na Slici 1.7. Pošto je električna struja nevidljiva i procesi u elektronici se teško demonstriraju, različite elektronske komponente su prikazane hidrauličkim ekvivalentima.

Slika 1.7 Analogija između hidrauličkog kola i elektronskog kola Nadamo se da je vaše znanje iz mehanike i elektronike dovoljno da možete sami shvatiti i proanalizirati obje šeme. Razmotrite analogiju hidrauličkog i elektronskog kola, tako da se uspostavi korelacija između jednačina koje opisuju mehaničke (hidrauličke) i elektronske procese.

Više detalja o analogiji na: https://sr.wikipedia.org/wiki/Metod_hidrauli%C4%8Dke_analogije.


9

1.4.2.3 Matematčki modeli Matematičkim modelom se pomoću matematičkih postupaka i operacija, na osnovu određenih podataka, opisuje ponašanje sistema. Matematički modeli pripadaju klasi apstraktnih modela, a primjenjuju se u naučnim i inženjerskim disciplinama.

Metodologija i struktura matematičkog modela je različita i određena prirodom realnog sistema i cilja matematičkog modeliranja. Matematičko modeliranje počinje definisanjem procesnog prostora P u kojem se odvija neki proces. Posmatrani procesi mogu biti složene prirode i osnova pristupa matematičkog modeliranja je sažimanje i apstrakcija istraživanih procesa. Na određenom nivou modela u istraživanom procesnom prostoru se definišu dva osnovna skupa veličina modela, skup ulaznih veličina X i izlaznih veličina Y. Osnov matematičkog modela M je određivanje matematičko-statističkih relacija koje povezuju skup izlaznih veličina Y (koje su zavisne veličine), sa skupom nezavisnih ulaznih veličina X.

Slika 1.8 Razdvajanje skupova ulaznih i izlaznih veličina kod matematičkog modela Na Slici 1.8 dat je prikaz matematičkog modela M u kome se procesni prostor P razdvaja u skupove ulaznih veličina X i izlaznih veličina Y. Definisanje ovih skupova se realizuje na osnovu analize realnog sistema koji se želi modelirati i kauzalnosti između veličina X koje su uzrok promjena i zavisnih veličina Y koje su posljedica ovih promjena. Definisanje skupova {X,Y} zahtijeva (bar) dva ekspertna nivoa

a) poznavanje procesa obuhvaćenih procesnim prostorom u realnom svijetu (eksperta za realan problem)

b) poznavanje teorije (eksperta koji može da matematički opiše odgovarajućim jednačinama realan problem)

Razmislite o dvije naoko kontradiktorne činjenice: Isti procesni prostor može se predstaviti različitim modelima. Isti model može se koristiti za predstavljanje različitih procesa. 1.4.2.4 Konceptualni modeli Konceptualni modeli nastaju na osnovu strukture logike rada sistema. Zovu se još i strukturni modeli pošto u grafičkom obliku prikazuju strukturu i pomoću nje omogućuju modeliranje. Predstavljaju osnovu za izradu računarskih modela. Struktura modela se uobičajeno predstavlja grafički dijagramom entiteta i veza ili UML4 dijagramom klasa, kao što je prikazano na Slici 1.9., a što ćemo nešto detaljnije komentarisati u 1.5.4.1. Konceptualni model sadrži:

1. Strukturu podataka – statički opis stanja realnog svijeta 2. Operacije – izražavaju dinamiku iz realnog svijeta 3. Ograničenja (constraints) – Ograničenja u modelu koja su posljedica ograničenja iz realnog svijeta

4 UML (Unified Modeling Language) standardizovani jezik za modeliranje, služi za vizue-lizaciju, specifikaciju, konstruisanje i dokumentovanje softverskih sistema. vidi više 4.8.4.1.


10

Slika 1.9 Primjer konceptualnog modela koji koristi XML5 i UML izvor: https://www.researchgate.net/figure/229424210_fig2_Figure-2-modeling-level-3-in-Eduweaver-left-activity-description-in-

IMSLD-right Jedna od namjena konceptualnog modela je automatsko generisanje programa i pomoć u razvoju programa. 1.4.2.5 Računarski i simulacioni modeli Simulacioni modeli su svi oni modeli gdje se „nešto“ predstavlja pomoću „nečeg drugog“. Pojam simulator označava uređaj u kome se vještački stvaraju takve prilike kakve postoje u realnom svijetu. Ako se simulacija obavlja na računaru, simulacioni modeli predstavljaju računarske modele. Računarski modeli su prikaz konceptualnih modela u obliku računarskih programa6 korišćenjem programskih jezika. Računarski model je program koji generiše ponašanje simuliranog sistema. Objekti računarskog modela su opisani promjenljivim (ulazno/izlaznim varijablama) i njihovim osobinama (atributima). Kod kompleksnijih sistema moguće je primijeniti modularni princip, koji olakšava projektovanje sistema na način da se prvo projektuju moduli a potom vrši njihovo povezivanje. Modularnost pojednostavljuje i ubrzava proces modeliranja, jer omogućava timski rad i parcijalno rješavanje problema, ali krije i mnogobrojne zamke, sa čuvenim pitanjem: Svi moduli rade, a sistem ne radi. Zašto? Zasad ćemo ukazati na osnovni uzrok kako je to moguće. Odgovor je u definiciji sistema: Sistem ne postoji bez uticaja okoline (vidi Sliku 1.1). Simulacioni modeli se dijele prema dva kriterija: prema vrsti promjenljivih u modelu i prema načinu na koji se mijenja stanje modela u vremenu. Podjela prema vrsti promjenljivih u modelu:

Deterministički modeli su modeli čije se stanje može predvidjeti, tj. novo stanje je potpuno određeno prethodnim.

Primjer: stanje sistema Sn se mijenja pod uticajem aktivnosti A, determinističkog trajanja od n sekundi, u stanje Sn+1. Primjer simulacije bilijara: za poznatu brzinu i ugao može se predvidjeti putanja kugle.

Stohastički modeli čije se ponašanje ne može predvidjeti, ali se mogu predvi-djeti vjerovatnoće promjena stanja.

Primjer: stanje Sn se pod uticajem aktivnosti A može promijeniti u stanja S’n+1, S’’n+1 ili S’’’n+1 ( es prim, es drugo, es treće) prema uniformnoj raspodjeli vjerovatnoća stanja. Ovakav model se može koristiti za simulaciju igara na sreću, ili sportskih simulacija kao što je tenis. 5 XML EXtensible Markup Language - jezik za označavanje podataka. Nastao je na osnovu ideje da se stvori jedan jezik koji će biti čitljiv i ljudima i računarskim programima. 6 možda bi preciznije bilo reći softvera i softverskih paketa


11

Podjela prema načinu na koji se stanje modela mijenja u vremenu: 1. Diskretni modeli u kojima se stanje sistema mijenja samo u pojedinim tačkama u vremenu, nema

kontinualne promjene stanja. Te promjene se nazivaju događaji. 2. Kontinualni modeli u kojima se promjenljive stanja mijenjaju kontinualno u vremenu. Na

digitalnim računarima se ne mogu izvoditi kontinualne promjene veličina već se moraju aproksimirati skupom diskretnih vrijednosti.

3. Kontinualno - diskretni modeli sadrže i kontinualne i diskretne promjenljive.

1.5 Simulacija 1.5.1 Šta je simulacija

Simulacija je prema Šenonu (Shanon, 1975) „proces dizajniranja modela realnog sistema i provođenje eksperimenata sa tim modelom radi razumijevanja ponašanja sistema ili evaluiranja različitih strategija (u okviru granica zadatih kriterijumima ili setom kriterijuma)“.

Slika 1.10 Osnovni elementi koji čine simulaciju

Da pojasnimo i naglasimo: Simulacija je proces koji uspostavlja vezu između modela i računara. Simulacija je eksperimentalna metoda koja omogućuje proučavanje stvarnog procesa pomoću njegovog modela. Model prikazuje statičko stanje sistema, odnosno stanje u jednom momentu. Simulacija pretpostavlja praćenje stanja sistema u vremenu. To znači da je za izvođenje simulacije potrebno definisati vremenski slijed: vremenski hodogram koji određuje hronologiju stanja sistema. Modeliranjem izrađujemo model, a simulacijom pratimo ponašanje modela. 1.5.2 Modeliranje i simulacija U literaturi i praksi često se koristi termin modeliranje i simulacija (engl. Modeling and simulation (M&S)), koji objedinjuje ova dva pojma što je dijelom opravdano jer:

Realni sistem opisuje se modelom. Stanje sistema predstavljeno je stanjem modela koje je određeno varijablama stanja. Model se definiše simulacijskim jezikom. Nakon izrade modela pristupa se simulaciji koja se odvija izvođenjem posebnog programa -

simulatora7 - na računaru. Rad simulatora je upravljan modelom.

Modeliranje i simulacija predstavljaju složenu aktivnost koja sadrži tri elementa:

1. Realni sistem 2. Model 3. Računar

7 Ovdje pod simulatorom podrazumijevamo program u izvršenju, pa bi mogli napraviti analogiju između programa i procesa (kao programa koji se izvršava) i modela (statički) i simulacije (dinamički)


12

Podsjećamo: Realni sistem koji je izvor podataka, može se predstaviti u obliku jednačine y=f(x), kojom se definiše model. Modeliranje je proces kojim se uspostavlja veza između realnog sistema i modela. U računarstvu, model predstavlja skup instrukcija (program) koje služe da se generiše ponašanje simuliranog sistema. Model ima svoje objekte koji su opisani promjenljivim i njihovim atributima.

Povezivanje modela predstavlja pripremnu fazu simulacije u kojoj se vrši priprema i obezbjeđuju potrebni resursi za proces simulacije (kao što je obezbjeđivanje memorije, definisanje redoslijeda budućih koraka u smislu prioriteta, provjera eventualno loše unesenih ulaznih podataka i slično).

Nakon povezivanja pristupa se stvarnoj simulaciji. U fazi stvarne simulacije vrši se sukcesivno izračunavanje prelaznih stanja i izlaza iz sistema. Obično se proračun provodi i prikazuje u diskretnim vremenskim intervalima koji mogu, ali i ne moraju biti jednoliki. Izbor intervala se definiše posebnim „rješavačem jednačina“ (solver). 1.5.3 Životni ciklus simulacije: Koraci simulacionih procesa Životni ciklus simulacije ćemo predstaviti nizom koraka koji opisuju pojedine faze rješavanja problema. Osnovni koraci simulacionog procesa prikazani na Slici 1.11 su sljedeći: 1. Definicija cilja istraživanja-simulacione studije; 2. Identifikacija sistema (opis komponenata, način rada, veza sa okolinom, formalni prikaz sistema); 1. Prikupljanje podataka o sistemu i njihova analiza; 4. Izgradnja simulacionog modela (stvaranje konceptualnog modela koji adekvatno opisuje sistem); 5. Izgradnja simulacionog programa (izbor softverskog paketa, ili programskog jezika i stvaranje simulacionog programa); 6. Verifikacija simulacionog programa (da li program vjerno predstavlja model); 7. Validacija (vrednovanje) simulacionog modela Vrlo značajna karika koja najčešće dovodi do ponovnog projektovanja modela. Validacija je provjera sličnosti ili preklapanja izlaznih vrijednosti iz modela i eksperimentalnih podataka. 8. Planiranje simulacionih eksperimenata i njihovo izvođenje; 9. Analiza rezultata eksperimenata (najčešće statistička analiza); 10. Zaključci i preporuke. Ove korake su definisali formulisali Law i Kelton 1982. godine, Law AM, Kelton WD. Simulation modeling and analysis. New York: McGraw-Hill, 1982 izvor INTRODUCTION TO MODELING AND SIMULATION, Anu Maria,State University of New York at Binghamton, Department of Systems Science and Industrial Engineering Binghamton, NY 13902-6000, U.S.A.

Slika 1.11 Koraci simulacionog procesa


13

1.5.4 Objedinjeni jezik modeliranja – UML

Kod konceptualnog modeliranja smo na Slici 1.9 dali primjer UML šeme objektno-orijentisanog sistema. Daćemo nekoliko razjašnjenja koje će vas uvesti u svijet modela baziranih na klasama i objektno-orijentisanom pristupu. Objektno-orijentisani (OO) razvoj predstavlja proces, ideju (apstrakciju) i problemsku specifikaciju (formalni opis modela) u formi objektno-orijentisanog programa koji se sastoji od niza objekata koji komuniciraju jedni sa drugima. Objekti se kreiraju kao klase koje su definisane u izvornom kodu programa. UML je pogodna notacija za OO analizu i dizajn. Realizovan je kao korisnički grafički jezik pogodan za vizuelizaciju, specifikaciju, konstruisanje i dokumentovanje modela. Postoje tri osnovna elementa UML modela, a to su:

1. Gradivni blokovi 2. Pravila za povezivanje gradivnih blokova 3. Opšti mehanizmi koji se primjenjuju u UML-u

Gradivni blokovi UML-a su: objekti-stvari (osnovni entiteti predstavljeni kao apstraktni objekti), veze-relacije koje povezuju objekte i dijagrami koji grupišu interesantne skupove povezanih objekata. UML omogućava konstruisanje preglednih šema (vidi Sliku 1.9) koje modeliraju sistem opisujući njegov koncept, npr. proces poslovanja i funkcije sistema i konkretne stvari koje definišu i opisuju sistem, npr. klasne tipove, domene, šeme baza podataka, softverske komponente.

Slika 1.12 Osnovne kategorije korisnika UML-a

Postoje različite kategorizacije korisnika UML-a i one su obično domenski grupisane prema pravima pristupa određenim blokovima i mehanizmima. Osnovne kategorije korisnika koji koriste UML-a su: sistem-projektanti i krajnji korisnici. U zavisnosti od kompleksnosti sistema mogući korisnici su razvojni inženjeri (koji mogu da vrše izmjene programa), kontrolori kvaliteta (provjeravaju strukturu i ponašanje sistema), tzv. bibliotekari (zaduženi za kreiranje i katalogizaciju objekata i tipova sistema), itd. kao što je predstavljeno na Slici 1.12.


14

1.6 Simulacija dinamičkih sistema Za simulaciju dinamičkih sistema koriste se matematički modeli koji analitički vrše optimizaciju procesa. Matematički modeli koriste nekoliko vrsta optimizacije procesa koje ih opisuju, od kojih su najznačajniji:

Nelinearno optimizovanje - Koristi se u kontinuiranom optimizovanju, a primjenjuje se za traženje optimalne raspodjele, odnosno pri traženju najpovoljnijih rješenja

Račun vjerovatnoće Prognoziranje optimuma Matematička statistika

Navešćemo osnovne strukture koje određuju matematičke modele: - jednačine regresijskog pravca (najjednostavnije aplikativno primjenjive u Excel-u), - regresijski polinomi i regresijski modeli, - obične diferencijalne jednačine, - parcijalne diferencijalne jednačine, - multivarijantni linearni regresijski modeli (MIMO) - autoregresijski linearni modeli (MISO) - neuronske mreže, - modeli neizrazite logike, - stohastički modeli, itd. Pošto je očigledno da su ovo vrlo zahtjevna znanja, mi ćemo praktičan rad nastaviti na dosta provizornim i neformalnim temeljima, koji su dovoljni tek za početne korake u modeliranju i simulaciji. 1.6.1 Statički i dinamički sistemi Statički modeli opisuju sisteme kod kojih vrijeme ne utiče na ponašanje sistema. Dinamički modeli opisuju ponašanje sistema u vremenu prateći stanja sistema preko vrijednosti različitih veličina koje se odnose na pojedine elemente modela. Pojednostavljeno, dinamički sistemi prate fenomene koji se privremeno mijenjaju u realnom sistemu. Promjena vrijednosti neke osobine objekta se povezuje sa vremenom. Npr. veličine (kao što su brzina, težina, brojnost i slično) zavise od vremena. U tom slučaju je model koji povezuje veličinu i vrijeme dinamički. U slučaju nekih društvenih ili prirodnih fenomena (kao što su npr. porast populacije ili industrijske proizvodnje) moguće je planirati i predvidjeti budućnost kreiranjem i praćenjem dinamičkih modela.


15

1.6.2 Deterministički i stohastički sistemi Deterministički simulacioni modeli su oni kod kojih su sve promjenljive stanja determinističke veličine, a stohastički su oni kod kojih je bar jedna promjenljiva slučajna veličina i u tom slučaju govorimo o modelu vjerovatnoće.

1.7 Vrste analize modela Analiza modela može se obaviti korišćenjem mnogobrojnih metoda, a mi ćemo predstaviti 4 glavne:

1. Šta-ako (What-if) analiza Na realizovanom modelu korisnik mijenja jednu ili više nezavisnih (ulaznih) varijabli, i posmatra kako se mijenja zavisna (izlazna) varijabla. Primjer: analiza rizika, najbolje je ako se obavlja simulacijom na način da se nezavisne varijable mijenjaju na slučajan način koristeći neku od distribucija (recimo Monte-Karlo). Ova metoda je direktno dostupna iz Excel-a, vidi Sliku 1.11.

Slika 1.13 Poziv Scenario menadžera iz Excela

Scenario menadžer (Scenario Manager) omogućava da se analiziraju sve moguće vrijednosti jedne funkcije kada se promijeni jedan parametar.

2. Traženje cilja (Goal seeking ili How can)

Kod ove analize kao polazište se koriste algoritmi sa pretraživanjem unazad (Backtracking algoritmi). Korisnik zadaje ciljnu vrijednost zavisne varijable, i traži da se mijenjaju vrijednosti nezavisnih varijabli sve dok se ne dostigne ciljna vrijednost zavisne varijable. Primjer: Želimo postići profit od 10.000 KM, i zadamo da se mijenja cijena, dok se ne pronađe cijena koja daje toliki profit. Ovo takođe pripada standardnom Excel arsenalu (vidi Sliku 1.13)

3. Analiza osjetljivosti Ispituje se kako promjena jednog parametra (nezavisne/ulazne varijable) utiče na funkciju cilja (zavisnu varijablu). Obično se izražava procentualno. Primjer: ako se mijenja cijena, posmatra se kako ona utiče na promjenu profita.

4. Optimizacija Optimizacija je metod određivanje ekstrema (minimuma ili maksimuma) realne funkcije cilja promjenama i izborom jedne ili više nezavisnih varijabli uz zadana ograničenja. Primjer: Treba optimizovati (pronaći maksimalni) profit, ako su zadane cijene proizvoda, količine, troškovi, a ograničenja su raspoloživi kapacitet mašina i ljudi, te potražnja. Kreiranje optimizacionih modela obično se rješava metodama linearnog programiranja, gdje se definiše: Funkcija cilja (šta se želi optimizovati), te da li se želi pronaći minimum ili maksimum Koje su varijable odlučivanja – koje su ulazne varijable koje će se mijenjati u modelu Ograničenja – funkcije i konstante.


16

1.8Razvojmodeliranjaisimulacije Osobina koja određuje ljude kao vrstu: mišljenje, je osnov za kreiranje misaonog mo-dela; pa se može reći da izrada „nekakvih“ modela postoji oduvijek: Crteži pećinskih ljudi su način na koji su oni predstavljali svijet. Hermann Schichl, u svom radu Models and History of modeling, kao prvu apstrakciju koju možemo nazvati modelom navodi broj i veže ga za 30000 godina prije Hrista. U istom radu kao prve modele upotrebljive u praksi navodi Astronomske modele kalendara nastale 3-4000 godina prije Hrista, paralelno na područjima današnje Indije, Vavilona i Egipta. Ovi modeli su se koristili u planiranju sjetve. Dalji razvoj modeliranje doživljava sa razvojem matematike u staroj Grčkoj, gdje se Euklidovi Elementi mogu smatrati prvom matematičkom teorijom koja se primjenjivala u praksi. Primjer modela koji je promijenio shvatanje svijeta je Keplerov (Johannes Kepler 1571. -1630.) model Sunčevog sistema iz 1596. godine (vidi Sliku 1.26), koji je, kad se na njega primijene Njutnova i Ajnštajnova mehanika i principi, važeći i danas.

Slika 1.26 Keplerov model preuzet iz knjige Istorija

kosmosa (Mysterium Cosmographicum) izvor Wikipedia

Promjena principa izrade modela se umnogome može vezati za razvoj matematike i njene primjene u elektronici i računarstvu, pa bi razrada ove teme podrazumijevala razradu misli značajnih matematičara od Lajbnica (Gottfried Wilhelm Leibniz 1646.- 1716.), preko Bula (George Boole, 1815.- 1864.) Kantora (Georg Ferdinand Ludwig Filip Kantor 1845.-1918.) i Rasela (Bertrand Arthur William Russell 1872. - 1970.), do Nojmana (John von Neumann 1901. - 1957.) i Tjuringa (Alan Mathison Turing 1912.-1954.), da nabrojimo samo najznačajnije. Svakako je interesantan primjer Teslinog modela daljinski upravljanog čamca koga je demonstrirao 1898. godine. Ovim modelom se pomoću električnih signala bežično upravljalo na daljinu, a originalnu prijavu Teslinog patenta ovog modela možete vidjeti na Slici 1.27. Ovaj model je bio daleko ispred svog vremena i sa pravom se može smatrati pretečom modernih sistema automatske regulacije. Sredinom XX vijeka sa pojavom elektronskih računara modeliranje doživljava procvat i počinje njegova prava primjena u modernom smislu.

Slika 1.27 Teslin model daljinski upravljanog čamca

(kopija dijela originalne šeme iz Tesline prijave Patentnom birou izvor http://iqnova.com/)


17

Prvo značajno modeliranje na računaru obavljeno je u sklopu projekta Menhetn (projekt razvoja atomske bombe). Napravljen je model kretanja neutrona pri lančanoj reakciji kojeg su razradili Ulam (Stanisław Marcin Ulam 1909. -1984.) i Nojman. Zbog tajnosti projekta detalji nisu bili šire dostupni javnosti. Tek naknadno, kad su 1949. Ulam i Metropolis (Nicholas Constantine Metropolis 1915.- 1999.) objavili zajednički rad The Monte Carlo method, ovaj metod počinje da se značajnije primjenjuje i njegova popularnost raste. Ovaj metod je odranije bio poznat, a Ulam ga je unaprijedio i dao mu ime Monte Karlo (pa smo ga i mi kao takvog dijelom obradili, (1.6.3). Pedesetih godina su razvijeni mnogobrojni modeli, posebno u vojnoj i avio industiji. Šezdesete godine dovode do popularizacije računarskih modela i simulacija koji se koriste u „trci u svemiru“, a u javnosti su popularisane kroz Apolo program. Projektant modela je morao da poznaje arhitekturu računara i procese koje želi simulirati. Sedamdesetih godina računari postepeno iz domena vojne industrije lagano prelaze u područje velikih industrijskih sistema, pa se počinje sa simulacijom ne samo kompleksnih proizvodnih sistema i uređaja, već se simuliraju i ekonomski, društveni ali i biološki i ekološki sistemi. Napredovanje tehnologije osamdesetih godina dovodi do moćnog i jeftinog hardvera, jeftinih PC konfiguracija i jeftinih CNC (programski upravljanih) mašina. U fabrikama se masovno koriste proizvodi čiji modeli su prethodno testirani i simulirani na računarima. Devedesetih godina se u praksi primjenjuju metode modeliranja koje u sebe uključuju i integrišu kompleksne sisteme računarskih mreža i vještačke inteligencije. Pad cijena računara omogućio je stvaranja alata za kućnu primjenu (tačnije za primjenu na PC računarima), kakvi su Matlab, Mathematica, AutoCAD, OrCAD, Space, ArchiCad,… koji u sebi integrišu kompletno crtanje/modeliranje te produkciju i proizvodnju 2D i 3D modela. 3D printeri su omogućili revoluciju u izradi modela i prototipova integracijom CAD dizajna (Computer-aided Design). Danas je obavezno da proizvodni proces započne izradom 3D CAD modela, tj. virtualnog prototipa proizvoda.

Slika 1.28 Integracija 3D printera i softvera za modeliranje

Moderna ekonomija tvrdi da je proizvod sve ono što se može ponuditi na tržištu, pa shodno tome modeliranje obuhvata i ekonomske odnose. Naše primjere Excel-a shvatite kao početne korake u tom domenu.

Današni trendovi modeliranja su zasnovani na agentima (Agent-Based Modelling; ABM modeliranje) i konceptu vještačke inteligencije.


18

1.9Kratkipregledrazvojamodelabazapodataka 1.9.1Davnaistorija Prva masovna automatska obrada podataka desila se davne 1882. godine u SAD-u. Te godine je obavljen popis stanovništva. Herman Holerit (vidi Sliku 2.27) je napravio i prodao statističkom birou SAD-a (gdje je bio zaposlen) mašinu koja je mogla da automatski obrađuje bušene kartice. Koncept i ideja su bili jednostavni, svaki stanovnik SAD-a je predstavljen nizom od 80 karaktera (ime, godište, itd) koji je bio „poravnat“ praznim prostorom (svi podaci su uniformno bili iste dužine).

Slika 2.27 Herman Hollerith (1860 – 1929) i njegova mašina za obradu bušenih kartica

Hiljade kutija punih bušenih kartica činile su prvu bazu podataka. Podatke je obrađivala elektromehanička mašina sa senzorima. Ova mašina je mogla da obradi oko 100 kartica u minuti (a svaka kartica je imala 12 redova sa 80 karaktera). To je dovelo do nevjerovatnog skraćenja obrade rezultata popisa. Rezultati su bili poznati već poslije mjesec dana od završetka popisa, umjesto nakon desetak godina što je bila ranija praksa.

1.9.2Istorija:Vrijemedokazivanja U narednih pola vijeka se od tehnologije elektromehaničkih uređaja i releja, preko elektronskih cijevi i tranzistora stiglo do integrisanih kola i relativno jeftinih računara. Tehnologija izrade računara je napredovala, ali od prvobitnog koncepta zasnovanog na tabelarnom modelu i bušenoj kartici dugo vremena se nije odustajalo. Tek 1951. (opet za potrebe popisa stanovništva) firma Remington Rand napravila je prema dizajnu Mauchly-a i Eckert-a UNIVAC I (Universal Automatic Computer), prvi komercijalni računar koji je koristio magnetne trake. UNIVAC je prvi serijski proizvođen računar.

Ne samo kao zanimljivost, spomenućemo Grace Hopper (1906-1992) ženu sa činom kontraadmirala, koja je učestvovala u razvoju UNIVAC-a, a bila je glavni tvorac pomalo zaboravljenog Cobol-a. Smatra se da je još uvijek više od pola poslovnog svjetskog softvera realizovano u Cobol-u.

Sistemi zasnovani na datotekama su imali dominantnu ulogu i nisu mogli da se koriste van strogo definisanog okruženja. Za razliku od modernih sistema ovi sistemi su bili direktno povezani na bazu. Korišćeni su uglavnom u vojne svrhe ili kod velikih projekata, od kojih je sigurno najpoznatiji Apollo. Ovaj period može se smatrati periodom u kome je dokazana sposobnost računarskih sistema da upravlja-ju ogromnim količinama podataka smještenih u namjenski strukturisane datoteke. Umjesto termina baze podataka koristio se termin banke podataka. 1.9.3Vrijemestvaranjastandarda

Krajem šezdesetih godina XX vijeka dolazi do koncepcijskih promjena u dizajniranju i obradi podataka. Iz tog perioda potiče i termin baza podataka: 1963. je pod pokrovi-teljstvom Društva za razvoj sistema (System Development Corporation) održan simpozijum sa naslovom Razvoj i upravljanje računarsko-centralizovanom bazom podataka - Development and Management of a Computer-centered Data Base. Iz tog vremena su i prvi sistemi upravljanja bazama podataka razvijeni na principima hijerahijskog modela kojeg je prihvatio IBM.


19

Radna grupa DBTG (Data Base Task Group) američke organizacije CODASYL (Conference On Data Systems Languages) 1959. prezentuje i standardizuje mrežni model za obradu podataka.

Edgar Frank "Ted" Codd (1923 –

2003) Engleski matematičar i računarski naučnik

Charles Bachman (rođen

11.12.1924) američki računarski naučnik

Autor mrežnog modela je bio Čarls Bakman (Slika 2.28). Bakman se na-stavio baviti bazama podataka i smatra se da je on razvio prvi navigacioni sistem za upravljanje bazama (Integrated Data Store, IDS). Bakman je kreirao i prvu višeprogramsku aplikaciju koja je omogućavala online pristup bazi podataka još 1965. Dobitnik je Tjuringove nagrade za 1973. godinu, a 2015. dobio je prestižno priznaje za neprocjenjiv doprinos u oblasti sistema baza podataka od Muzeja istorije računarstva (Computer History Museum).

Slika 2.28 Kod i Bakman: Dvojica ljudi koji se smatraju tvorcima modernih baza podataka

IBM je tih godina bio apsolutno dominantan, pa nije ni čudo što je velik broj ideja osmišljen i realizovan u ovoj kompaniji. Kao velik i gotovo monopolski sistem IBM je bio dosta konzervativan i sporo je prihvatao nove ideje.

Edgar Frank Kod (Edgar Frank Codd), direktor IBM-ovog razvojnoj centra iz San Hozea, 1970. predlaže novi koncept koji je nazvan relacioni model podataka. U to vrijeme njegove ideje su smatrane čisto akademskim i praktično neprimjenjivim jer nije bilo jasno kako bi računar mogao uspješno i efikasno da obrađuje tabele i relacije, umjesto u praksi provjerenog sistema datoteka i mrežnog modela. U početku je IBM odbio da implementira relacioni model, ali Kod je nastavio da uporno promoviše svoje ideje što je dovelo do razvoja najuspješnijeg modela baza podataka: relacionog modela. Dobio je Tjuringovu nagradu 1981. i od tada ustvari počinje dominacija relacionog modela. Kod nije samo izmislio termin OLAP (Online Analytical Processing) već je i tvorac višedimenzionih upita koji su osnov ove tehnike obrade podataka.

Tvorac SQL-a je Čemberlin (Donald D. Chamberlin američki naučnik rođen 1944). SQL je promovisan 1972. a nastao je u istoj IBM-ovoj istraživačkoj laboratoriji gdje je Kod definisao relacioni model. Kasnije se Čemberlin aktivno uključio u rad W3C konzorcija i smatra se jednim od ljudi koji su definisali XML. 1.9.4Modernavremena

Pred kraj prošlog vijeka se programiranje u svim domenima, pa i kod baza podataka, okreće prema objektu. Objektno-orijentisano programiranje postaje dominantno. Značajne novine donosi XML koncept koji pokušava da prevaziđe tradicionalnu podjelu između dokumenta i podatka. XML baze su naročito pogodne za korišćenje na internetu (HTML i XML se izuzetno dopunjuju) i za rad sa polustrukturiranim podacima. Razvoj interneta dovodi do popularizacije multimedijalnih sadržaja, pa nastaju i multimedijalne baze i sistemi za upravljanje njima: MMDBMS -Multimedia Database Management System. Pošto u svojoj osnovi multimedija ima nestrukturirane podatke, objektno-orijentisan stil je omogućio sredstva za definisanje novih tipova podataka i operatora za nove vrste medija, kao što su video, grafika i audio.

Relacioni model pokazuje snagu i vitalnost. Prihvata nove ideje i neprestano se dograđuje. Zadržan je osnovni koncept, a relacijama su pridružene osobine objekta. Tako je nastao objektno-relacioni sistem (ORDBMS) predstavljen 1999. god. sa SQL-3 standardom. Kao jedan od mogućih pravaca razvoja je mapiranje objektnog u relaciono, gdje se stvaraju virtuelne objektne baze korišćenjem okvira (framework).


20

2.Sistemzaupravljanjebazompodataka–Uvod‐2.1Štasutobazepodataka Naziv baza podataka se strogo1 govoreći odnosi na zbirku zapisa (bilo kakvu, pa i neelektronsku). Ako se za pristup koristi softver, onda bi se za taj softver trebao koristiti naziv sistem upravljanja bazom podataka. Pošto nam primarni predmet interesovanja nije pravo, daćemo definiciju iz knjige Uvod u baze podataka2: „Baza podataka je skup podataka koji su organizovani prema potrebama korisnika, koji se održavaju i koriste za dobijanje informacija.“ Uobičajeno se baze podataka čuvaju na računaru i na nekom trajnom mediju-disku (što nije bitno za samu definiciju). Za bazu je bitno da je to organizovani skup logički povezanih podataka, gdje se pod organizovan i logički smatra da je to skup podataka pripremljen tako da se mogu jednostavno koristiti, tj. pregledavati, pretraživati, sortirati, porediti i mijenjati. Baza podataka različitim korisnicima i programima pruža mogućnost da iste podatke različito koriste. Osim podataka namijenjenih korisnicima, baza podataka sadrži i metapodatke. Metapodaci su podaci o strukturi baze podataka (imena tabela-relacija, imena i domene atributa-kolona koji čine relacije), veze među podacima, pomoćne strukture za pristup podacima (ključevi i indeksi), podaci o korisnicima (prava i privilegije) i sve ostale sistemske komponente (izgled ekrana, izvještaja i slično). 2.1.1Sistemzaupravljanjebazompodataka Sistem za upravljanje bazom podataka SUBP (Database Management System – DBMS) je softver koji je spona i veza (interfejs) između korisnika (aplikativnih-korisničkih programa) i zapisa baze podataka na disku.

Slika 2.1 Sistem baza podataka Sistem baza podataka predstavlja jedinstvo baze podataka i neophodnih hardverskih, softverskih i ljudskih resursa i predstavljen je na Slici 2.1. Sistem sadrži 4 osnovne komponente:

1. korisnici, 2. aplikacija nad bazom podataka, 3. sistem za upravljanje bazama podataka i 4. baza podataka.

1 Ovo strogo, znači pravno gledano, a autori vam mogu ponuditi adresu direktive Evropske unije (Directive 96/9EC) gdje se na 576 stranica propisuje način korištenja podataka iz različitih baza podataka. Adresa je:

http://ec.europa.eu/internal_market/copyright/docs/databases/etd2001b53001e72_en.pdf 2 Mladen Veinović, Goran Šimić, Uvod u baze podataka, Univerzitet Singidunum, Beograd 2010

Sistem za upravljanje bazom podataka – Uvod-

21

2.1.2 Podatak i informacija Sjećate li se pojma sistema? (iz poglavlja Modeliranje i simulacija). Za potrebe analize modela sistema baze podataka daćemo proširenje ranije definicije: Sistem predstavlja skup elemenata i njihovih međusobnih veza.

U „realnom svijetu“ podatak je pojam koji opisuje i kvantifikuje stanje nekog procesa. Podatak je činjenica koja predstavlja reprezentaciju nekog predmeta ili događaja. Oblici podataka su zvučni, slikovni, brojčani i tekstualni. Podaci mogu biti strukturirani (npr. slovni, brojevi, datumi), i nestrukturirani (slika, zvuk).

Informacija3 je novi podatak koji posjeduje neku relevantnu novinu. Podatak sam po sebi nema značenje, tek kad se obradi i interpretira postaje informacija. U sklopu sistema za upravljanje podacima vrši se obrada podataka iz baze podataka, tako da oni postanu korisne informacije. 2.1.3Entitetiiatributi Entitet predstavlja pojam nečega što posebno i samosvojno postoji, a kod baza podataka entitet je osnovni element koji smještamo u bazu. Entitet je realan ili imaginaran objekat (odnosno biće, događaj ili pojava) koji se može jednoznačno identifikovati, razlikovati i opisati. Entitet je nešto o čemu želimo sačuvati podatke. Entitet se opisuje atributima, a konkretne vrijednosti entiteta određuju se vrijednostima atributa.

Atributi predstavljaju opis entiteta, odnosno atributima se definišu opšte osobine koje određuju entitet. Konkretna vrijednost entiteta dobije se kada se atributima daju konkretne vrijednosti. Npr.: entitet Imenik ima atribute Ime, Prezime, Adresa, Grad, Br_Tel, a vrijednost tog entiteta može biti: Petar, Petrović, Banja Luka, Fruškogorska, 051/123-122. Atribut je definisan izrazom: <ime atributa> <tip atributa> <dodatna svojstva atributa> Atribut ima svoje ime po kome se razlikuje od ostalih atributa entiteta kojem pripada. Ne mogu postojati dva atributa sa istim imenom u sklopu jednog entiteta; normalno ista imena se mogu koristiti za atribute različitih entiteta. Tip podatka4 pridružen konkretnom atributu bliže opisuje atribut i određuje način njegovog memorisanja. Najčešći tipovi atributa su:

Tekstualni / strings (CHAR(n) – tekst dužine n slova, VARCHAR(n) – tekst dužine najviše n slova, TEXT – tekst proizvoljne dužine),

Numerički (INT – cijeli broj prikazan s 4 bajta, BIGINT – cijeli broj prikazan s 8 bajta, SMALLINT – cijeli broj prikazan s 2 bajta, REAL – realni broj prikazan s 4 bajta, DOUBLE PRECISION - realni broj prikazan s 8 bajta, NUMERIC [(p,s)] - realni broj zadane preciznosti,

MONEY - novac, Logički podaci, Datum i vrijeme (DATE, TIME, TIMESTAMP – datum+vrijeme).

Atributi mogu imati i neka dodatna svojstva koja mogu da ograniče domen atributa (vidi iduću lekciju). Dodatna svojstva atributa:

DEFAULT (zadavanje predefinisane vrijednosti), NOT NULL (vrijednost ne smije biti nepoznata), CHECK (provjera da li je vrijednost atributa u zadanim granicama), UNIQUE (jedinstvenost među n-torkama unutar relacije), PRIMARY KEY (primarni ključ), REFERENCES (vrijednost odgovara vrijednostima atributa iz druge relacije (najčešće ključ te

relacije)), UNSIGNED (Ako ne trebamo negativne brojeve), FLOATING POINT (decimalni brojevi), DOUBLE F.P. (pozitivne i negativne vrijednosti).

3 Šenon je informaciju definisao kao podatak koji smanjuje neizvjesnost. 4 većinu tipova i dodatnih svojstava ćemo provježbati kroz primjere u Access-u


22

2.1.4Domenatributa Domen (domain) je skup svih prihvatljivih vrijednosti koje atribut može imati. Domen atributa se definiše: tipom podataka, dužinom podataka i opsegom vrijednosti. Definicija domena zahtijeva potpun opis važećih podataka. To može biti lista sa svim prihvatljivim vrijednostima (npr. domen atributa Ocjena: {1,2,3,4,5} ili StručnaSprema, {niža, srednja, viša, visoka, master, doktorat}. U praksi se ne mogu svi domeni definisati pojedinačnim navođenjem prihvatljivih vrijednosti. Ponekad je lakše definisati domen u obliku pravila koja utvrđuju da li određena vrijednost pripada skupu prihvatljivih vrijednosti. Ako se atributu ne definiše domen onda on uzima sve vrijednosti tipa koji ga određuje, što ponekad dovodi do zabune. Domen i tip nisu jedno te isto, izuzev u slučajevima kad zadržimo predefinisanu sistemsku vrijednost domena (INTEGER, CHAR...). Domen je skup vrijednosti istog tipa, npr. skup imena rijeka nekog sliva, skup imena igrača nekog tima, skup imena mjesnih zajednica nekog grada, skup naslova knjiga neke biblioteke, itd. 2.2Arhitekturabazepodatakainjenopredstavljanješemama

Arhitektura baze podataka sastoji se od tri nivoa-sloja i veza-interfejsa među slojevima. Struktura baze podataka je na ovakav način prvi put predstavljena sedamdesetih godina i poznata je kao ANSI/X3/SPARC model5. Riječ je o tri nivoa apstrakcije predstavljena na Slici 2.3.

Slika 2.3 Troslojna arhitektura baze podataka

Svaki nivo ima specifičan način definisanja i predstavljanja objekata, odnosa i operacija među njima. Hijerarhijska organizacija omogućava modularan pristup i, što je još važnije, logičku i fizičku nezavisnost programa od podataka. Korisnički (vanjski) eksterni logički nivo čine aplikacioni programi kojima mogu pristupiti korisnici. Oni se služe samo dijelom podataka koji postoje u bazi podataka i taj dio se zove pogled (view) i opisuje se eksternim šemama. Za kreiranje baze podataka na lokalnom nivou dovoljno je zadati samo šemu i poglede. DBMS automatski generiše potrebni raspored arhiviranja i fizičku bazu. Globalni logički nivo opisuje se konceptualnom šemom i sadrži opis svih entiteta i veza, atributa, domena i integritetska ograničenja. Konceptualna šema se može opisati korištenjem modela podataka, npr. relacionog i često se naziva i logička šema. To je tekst ili dijagram kojim se imenuju i definišu svi podaci, veze među podacima, te pravila kojima se čuva integritet baze podataka. Logičku šemu definiše, vidi i uređuje administrator, ili projektant baze.

5 preliminarno predstavljen od strane ANSI (American National Standards Institute) 1972., kao potpun standard definisan je 1975. kao “ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report), a zadnja verzija je iz 1996


23

Fizički nivo - To je fizički prikaz i raspored podataka na diskovima, tj. vanjskoj memoriji gdje se podaci smještaju. Raspored smještanja i pamćenja podataka na fizičkom nivou opisuje kako se logičke definicije preslikavaju na fizičke uređaje. Fizičkom nivou pristupaju programeri koji kreiraju DBMS. DBMS „prevodi“ korisničke zahtjeve za podacima s lokalnog nivoa na globalni logički nivo, a potom ih realizuje kao ekvivalentne na fizičkom nivou (vidi Sliku 2.3)

Jedna baza podataka ima jednu konceptualnu, jednu fizičku i (najčešće) više eksternih šema. 2.3Jezicizaupravljanjebazamapodataka Komunikacija korisnika, tačnije aplikacionog programa i DBMS -a (na lokalnom nivou, vidi Sliku 2.3) se tradicionalno obavljala preko:

1. Jezika za opis podataka (Data Description Language - DDL) koji definiše podatke i veze među podacima na logičkom nivou. Koristi se za definisanje nove ili promjenu postojeće šeme podataka.

2. Jezika za manipulisanje podacima (Data Manipulation Language - DML) koji definiše i uspostavlja vezu između aplikacionog programa i baze.

3. Jezika za postavljanje upita (Query Language - QL). Služi neposrednom korisniku za interaktivno pretraživanje baze. Obično je to jezik koji podsjeća na govorni (engleski) jezik i osim pretraživanja omogućuje operacije unosa, izmjene i brisanja podataka.

Ovakva podjela je prilično zastarjela. Naime, kod relacionih baza postoji tendencija da se sva tri jezika integrišu. Primjer takvog jezika je SQL (Structured Query Language). SQL je strukturni upitni jezik koji u sebi objedinjuje mogućnosti kreiranja, manipulacije i zaštite objekata baze. Na Slici 2.4 može se vidjeti blok šema koja pokazuje odnos SQL-a prema DDL-u i DML-u, kao i osnovni tipovi i komande koje ovaj jezik podržava.

Slika 2.4 Tipovi i komande SQL-a

Moderne aplikacije se razvijaju u standardnim objektno orijentisanim programskim jezicima (Java, C++, . . . ). Za interakcije s bazom koriste se unaprijed pripremljene klase objekata. Ali, to je tema nekog drugog udžbenika.


24

2.3.1Softverskipaketizaradsbazamapodataka Baze podataka se u pravilu realizuju korišćenjem nekog od provjerenih (i skupih) softverskih paketa. U Tabeli 2.1 dat je pregled nekih od najznačajnijih softverskih proizvoda i paketa za rad sa bazama podataka.

Proizvod Proizvođač Operativni sistem Jezici ADABAS

Software AG Unix, Linux i Microsoft Windows serveri

SQL COBOL

Adaptive Server Enterprise

Sybase Inc. MS Windows , OS/2, Mac, UNIX (razni), UNIXWare

SQL, COBOL, ...

Advantage Database Server

Sybase Inc. MS Windows , OS/2, Mac, UNIX (razni), UNIXWare

SQL, COBOL, ...

Allbase/SQL Hewlett Packard Co. UNIX (HP-UX) SQL. 4GL, C, ...

DB2 IBM Corporation Linux. UNIX (razni), MS Windows, VMS, MVS, VM, OS/400

SQL, COBOL, Java, ...

FileMaker Pro Go 14 FileMaker Inc Linux, MS Windows (razni), Mac OS SQL i ODBC

Informix IBM Corporation (prije: Informix)

UNIX (razni), Linux, MS Windows

SQL. Java i drugi

MS Access Microsoft MS Windows (razni) Access, Basic, SQL MS SQL Server Microsoft MS Windows NT/7/8/10 SQL, C+ + . ...

MySQL MySQL AB Linux, UNIX (razni), MS Windows (razni), Mac OS

SQL, C, PHP. ...

Oracle Oracle Corporation MS Windows (razni), Mac OS, UNIX (razni), Linux i drugi

SQL, Java i drugi

Supra Cincom Systems Inc. UNIX, Linux, OpenVMS SQL, COBOL, ...

Teradata Database Teradata Corporation Windows Server 2003, Linux Enterprise Server 10

SQL

Tabela 2.1: Softverski paketi za rad sa bazama Vašoj pažnji preporučujemo pregled 2000 najboljih softverskih proizvoda (Top Database Management Software Products) na adresi: http://www.capterra.com/database-management-software/ Posebno preporučujemo MySQL. Možda nije najbolji, ali je jedan od najpopularnijih jer je besplatan (open source) sistem za upravljanje bazom podataka.

2.3.2ŽivotniciklusbazepodatakaSvaka baza podatak ima svoj životni vijek, početak kada je projektirana, pa do njene implementacije i održavanja. Uvodenje baze podataka u neko poduzeće ili ustanovu predstavlja složeni zadatak koji zahtijeva timski rad stručnjaka raznih profila. Grubo se to može podjeliti na 5 faza: 1. Analiza potreba 2. Modeliranje podataka 3. Implementacija 4. Testiranje 5. Održavanje

Alternativni dijagram koji pokazuje interakciju pojedinih

faza razvoja i životnog ciklusa baze podataka


25

2.3.2.1 Analiza potreba Porebno je ustanoviti način poslovanja , koji se podaci koriste, i na koje načine, i gdje. Proučavaju se tokovi informacija u firmi. Uočavaju se podaci koje treba pohranjivati i veze među njima. Analiza potreba takođe treba obuhvatiti analizu transakcija (operacija) koje će se obavljati nad bazom podataka, budući da to može isto imati uticaja na sadržaj i konačni oblik baze. Važno je procijeniti frekvenciju i opseg pojedinih transakcija, te zahtjeve na performanse. Rezultat analize je dokument koji se zove specifikacija potreba.

Treba pronaći veze među podacima. Sve te informacije o podacima treba objediniti i uskladiti, stvoriti konzistentnu sliku o njima. Zatim je ustanoviti kako će se ti podaci koristiti, koliko često, i koje su vrste operacija potrebne nad

podacima.

2.3.2.2 Modeliranje podataka Ovaj dio pripada onome sto se zove globalna šema. Za bazu podataka tipično postoji strukturni opis vrste činjenica sadržanih u toj bazi podataka: taj opis naziva se šema. Šema opisuje predmete koji su prikazani u bazi podataka, te odnose među njima. Ovom tematikom ćemo se kasnije detaljno pozabaviti. 2.3.2.3Implementacija Prethodni koraci su bili vrsta planiranja - sve na papiru (ili računaru),ali ovaj korak je realizacija zamišljenog. Na osnovu šeme i pod-šema, te uz pomoć dostupnog DBMS-a (SUBP-a), fizički se realizuje baza podataka na računaru. U DBMS-u (SUBP-u) obično postoje parametri kojima se može uticati na fizičku organizaciju baze. Parametri se podešavaju tako da se osigura efikasan rad najvažnijih transakcija. Razvija se skup programa koji realizuju pojedine transakcije te pokrivaju potrebe raznih aplikacija. Baza se inicijalno puni podacima. Obuhvata:

Implementacija šeme. Razvoj potrebnih aplikacija za rad. Inicijalno punjenje baze podataka s podacima potrebnim za početak rada.

2.3.2.4TestiranjeKorisnici rade s bazom i provjeravaju da li ona zadovoljava sve zahtjeve. Nastoje se otkriti greške.U novije vrijeme, prije prave implementacije, razvijaju i približni prototipovi baze podataka, te se oni pokazuju korisnicima. Jeftinu izradu prototipova omogućuju jezici 4. generacije i objektno-orijentisani jezici. 2.3.2.5 Održavanje Odvija se u vrijeme kad je baza već ušla u redovnu upotrebu. Sastoji se od sljedećeg: popravak grešaka koje nisu bile otkrivene u fazi testiranja; uvođenje promjena zbog novih zahtjeva korisnika; podešavanje parametara u DBMS (-SUBP-) u svrhu poboljšavanja performansi. Održavanje zahtijeva da se stalno prati rad s bazom, i to tako da to praćenje ne ometa korisnike.


26

2.4Apstrakcijaišemezamodeliranjebazepodataka Ovaj dio pripada onome sto se zove izrada globalne šeme i definisanje baze podataka:

definisanje vrste podataka i veza među njima a prema informacijama dobivenim analizom potreba.

normalizacija (regrupiranje) podataka u cilju budućceg efikasnijeg rada baze podataka.

definisanje podšema za pojednine aplikacije. Pošto baza podataka ne postoji u relnom svijetu primjenjujemo koncept apstrakcije:

Apstrakcija podrazumjeva tri procedure

Klasifikaciju gdje se obavlja klasificiranje,opis i grupisanje entiteta u klase, razrede, odnosno tipove prema zajedničkim obilježjima. Opisuje se vezom (odnosom) “jest pojava” (engl. instance of).

Generalizaciju gdje se tipovi entiteta niže razine uopštavaju se tipom entiteta. Opisuje se vezom “jest” (engl. is a)

Agregacija vrši formiranje novog pojma na osnovu odnosa postojećih pojmova.


27

2.5.Relacionimodel Model je reprezentacija skupa entiteta (objekata) i njihovih međusobnih veza. Izbor i definisanje entiteta i veza između njih je suština procesa modeliranja. Za sada možemo reći da postupak definisanja relacija-tabela i veza među njima znači kreiranje modela relacione baze podataka. Prije nego što definišemo relacioni model, upoznaćemo se sa modelima baza podataka uopšte, potom sa elementima i uslovima kreiranja relacionog modela. 2.5.1Modelibazepodataka Prilikom objašnjenja arhitekture baze objasnili smo da se na konceptualnom nivou definiše konceptualni model sa odgovarajućom logičkom šemom koja sadrži opis svih entiteta i veza, atributa, domena i integritetska ograničenja. Hijerarhijsko mjesto konceptualnog modela vidi se na Slici 2.5 (između korisnika i fizičkog nivoa).

Slika 2.5 Hijerarhija modela

Eksterni modeli (1-3) nastaju na osnovu konceptualnog modela i predstavljaju samo pogled (view) koji je nastao prema potrebama korisnika. Na Slici 2.5 može se primijetiti da fizički model omogućava predstavljanje konceptualnog modela u formi zapisa podataka na neki fizički medij (najčešće je to disk, a „posrednik“ između medija i fizičkog modela je operativni sistem-OS). Kad se govori o modelima baze podataka najčešće se misli na konceptualni model, pa ćemo mi ubuduće kad kažemo model smatrati da je to konceptualni model (a kad to ne bude slučaj to ćemo posebno naglasiti). Definisanje logičke šeme, odnosno pravljenje konceptualnog modela (uopšte, pa i kod baza podataka) podrazumijeva tri koraka:

1. detekciju i selekciju objekata (entiteta) i veza između objekata 2. imenovanje objekata, njihovih atributa i veza 3. klasifikaciju, gdje se objekti svrstavaju u klase i tipove

2.5.2Vrstemodelabazapodataka Model baze podataka je formalni sistem koji se sastoji od:

skupa objekata - osnovnih elemenata (koncepata) baze podataka skupa operacija koje se provode nad objektima skupa integritetskih ograničenja (integrity constraints) kojima se definiše skup važećih pravila

Razlikujemo nekoliko vrsta modela. Mi ćemo se baviti relacionim modelom (što je i naslov ove (2.4) sekcije), a ostale modele, koji su uglavnom istorijski ćemo samo informativo obraditi.


28

2.5.2.1Ravni(tabelarni)modelRavni model poznat i kao model ravnih datoteka (flat files) je model gdje se svi podaci čuvaju u samo jednoj tabeli. Glavni nedostatak je velika redundansa, a primjer koji bi odgovarao ovom modelu bila bi Excel tabela. Može se smatrati pretečom relacionog modela samo zbog forme tabele kao načina organizacije podataka. 2.5.2.2HijerarhijskimodelpodatakaHijerarhijski model je najstariji model. Zasnovan je na hijerarhijskoj strukturi koje ima oblik stabla prikazan na Slici 2.6. Kod hijerarhjskog modela podaci su organizovani kao čvorovi.

Slika 2.6 Hijerarhijski model predstavljen mrežnim stablom

Hijerarhijska struktura odgovara stablu i postoje različiti matematički opisi i procedure pretrage mrežnog stabla6. Element na jednoj strani relacije “jedan-prema-više” naziva se element višeg nivoa ili roditelj, koji je povezan sa elementima nižeg nivoa ili djecom. Hijerarhijska baza podataka se predstavlja kao stablo aplikacionih elemenata, gdje relacija “jedan-prema-više” povezuje svakog roditelja i dijete. Pretraga se obavlja od osnovnog sloga (root) i kreće prema naniže (ako se ne pronađe, vraća se unazad i ide na iduće dijete...) 2.5.2.3MrežnimodelpodatakaMrežni model nastao je kao paralela hijerarhijskom modelu, ali kod njega je dopušteno da svaki slog ima više od jednog roditelja. Moglo bi se reći da je hijerarhijski model specijalni slučaj mrežnog modela. I mrežni model se može predstaviti mrežnim grafom (kako ovdje ne postoji obavezan odnos roditelj-dijete, ne govori se o stablu, već o mrežnom grafu). Kod mrežnih struktura moguće je da se svaki element povezuje sa svakim. Podaci u mrežnom modelu se prikazuju skupovima slogova, a njihovi odnosi pomoću veza. Na Slici 2.7 data je ilustracija mrežnog modela predstavljena mrežnim grafom i modelom jedne konkretne baze.

Slika 2.7 Mrežni graf kojim se može predstaviti mrežna struktura podataka Relacioni model podataka Ovaj model je trenutno najrasprostranjeniji i on je predmet našeg interesovanja.

6 Teorija grafova je grana matematike koja se bavi proučavanjem grafova. Graf je vrsta strukture podataka koji se sastoji od skupa čvorova i skupa grana, koje predstavljaju odnose (veze) između čvorova. Mrežno stablo je najjednostavnija klasa grafa. U računarstvu se grafovi često koriste za opis modela ili struktura podataka.


29

2.6Pojamrelacijeirelacionebaze Osnivač relacionog modela Kod7 je osnovne pojmove relacionog modela preuzeo iz matematičke teorije. Relacija, kao osnovni koncept relacionog modela je matematička relacija8. Relacija je imenovani podskup Dekartovog (Kartezijevog) proizvoda dva ili više domena. Kombinacije vrijednosti domena nazivaju se n-torke.

Pojednostavljeno objašnjenje Dekartovog proizvoda daćemo u sekciji o relacionoj algebri (sekcija 2.5), a za više detelja o ovoj problematici preporučujemo knjigu Gordane Pavlović-Lažetić, Uvod u relacione baze podataka, iz koje ćemo dati nešto precizniju definiciju relacije: „Neka su D1,D2,...,Dn (n N) domeni (ne obavezno različiti). Dekartov proizvod tih domena, u oznaci D1 × D2 × ... × Dn, jeste skup n-torki (v1, v2, ... ,vn) takvih da je viDi za sve i=1,2, ...,n. Relacija R stepena n, definisana na domenima D1,D2,...Dn, je proizvoljni konačni podskup navedenog Dekartovog proizvoda.“ Prema tome, relacija je skup n-torki. Relaciji bi u standardnoj računarskoj trminologiji odgovarala jedna datoteka, a n-torci jedan slog te datoteke. Relacija ima jednostavnu reprezentaciju u obliku dvodimenzionalne tabele sa podacima, prikazanu na Slici 2.8.

Slika 2.8 Tabela kao reprezentacija relacije

Napokon možemo da definišemo relacionu bazu: Relaciona baza podataka je skup vremenski promjenljivih relacija (n-torki u relacijama). Sistemi relacionih baza podataka imaju sljedeće odlike:

Svi podaci se predstavljaju preko relacija (relation) u obliku dvodimenzionalne tabele sa podacima. Osim atributa svakog entiteta, model podataka mora da definiše i veze ili odnose koje postoje između entiteta. Veza ili odnos (relationship) je udruživanje-asocijacija između entiteta.

Sve vrijednosti su skalarne. (vidi 2.6.5 1NF). Sve operacije obavljaju se nad cijelom relacijom, a rezultat je takođe cijela relacija. Taj koncept je

poznat kao cjelovitost (closure). Skup operacija koje se provode na relacijama, odnosno tabelama naziva se relacionom algebrom. Kasnije ćemo se upoznati sa osnovnim pojmovima iz relacione algebre i računa.

7 Edgar Kod, engleski matematičar i naučnik, više detalja vidi u 2.9 8 često se može sresti pogrešna tvrdnja da se relacioni model tako zove zbog veza (engl. relationships), relacioni model je dobio ime po relacijama na kojima se model zasniva.


30

2.6.1Šemarelacije:RelacionatabelaiŠemarelacionebaze Šema relacije predstavlja opis strukture tabele. Relaciona šema se još naziva i relaciona tabela, a nju karakterišu sljedeća svojstva:

U relacionoj šemi može postojati samo jedan tip slogova, odnosno n-torki; Svaki red, odnosno slog ili n-torka (tuple) uključuje tačno određen broj polja podataka, tj. atributa i

svaki od njih je eksplicitno imenovan; Relaciona šema ne sadrži dva jednaka naziva atributa, odnosno relacija ne sadrži dvije jednake

kolone; Redoslijed kolona, odnosno atributa je nebitan; Redoslijed n-torki je nebitan;

relacija nije uređena. Relaciju možete zamisliti kao košaru u kojoj su torke nagomilane bez ikakvog posebnog redoslijeda. Redni brojevi zapisa, uobičajen mehanizam za pristupanje zapisima u nerelacionim bazama podataka, ne postoje u relacijama.

Nove se tabele mogu stvarati povezivanjem preko vrijednosti polja podataka iz istog domena iz dvije postojeće tabele.

Naglasimo: relacija i tabela nisu isto. Kod tabela je bitan redoslijed redova i kolona, dok kod relacija nije bitan redoslijed atributa i n-torki. Šemu relacije možemo shvatiti dvojako: kao definiciju strukture neke datoteke (kako smo naveli u definiciji), ali i kao predstavu svojstava klase objekata i veza unutar nekog sistema. Šema relacione baze podataka je skup šema njenih relacija. 2.6.2Predstavljanjerelacijaišemarelacija Relaciju možemo predstaviti tako da navedemo njeno ime i skup atributa koji je čine: R(A1:D1, A2:D2,..., An:Dn), ako domeni nisu bitni dovoljno je navesti samo atribute: R(A1, A2,..., An). Primjer: Ucenik(Razred, BrojDnevnik, Ime, Prezime) Uobičajena konvencija za predstavljanje relacione šeme je dijagram relacije. Relaciju predstavljamo pravougaonom tabelom koja ima onoliko ćelija koliko je atributa u relaciji. Ime relacije se ispisuje iznad tabele, a imena atributa u ćelijama9. Kao primjer, na Slici 2.9 daćemo dijagram relacione šeme baze podataka Generacija2016. L_Podaci

JMBG Odjeljenje Br_dnevnik Prezime Ime Dat_rodj Pol Adresa Grad

Odjeljenja Odjeljenje Smjer

Slika 2.9 Primjer dijagrama relacija

9 pri čemu se atribut koji je primarni ključ podvlači, a spoljni ključevi pišu italikom, a šta to znači vidi 2.2.5


31

2.6.3Osnovneosobinekojetrebadaimarelacionimodel SUBP (DBMS) se naziva relacionim ako podržava relacione operacije (kanije ćemo objasniti relacione operacije). Osim što podržava relacione operacije, da bi neki model mogao da se nazove relacionim on treba da ima osnovne osobine kao što su:

Sistemski tretman „NULL“ vrijednosti NULL je univerzalna vrijednost "nepoznato". Koristi se kad iz bilo kog razloga u momentu unosa podataka nije poznata vrijednost nekog ulaznog podatka. NULL može biti vrijednost svake kolone bez obzira na njen tip, osim primarnog ključa i u slučaju kad se izričito zahtijeva da vrijednosti u nekoj koloni ne smiju biti nedefinisane (dodatno ograničenje NOTNULL).

Neprekidan pristup dinamičkom katalogu relacionog modela Katalog relacionog modela predstavlja zapis o strukturi baze podataka. Spada u tzv. metapodatke, koje smo spomenuli u uvodu. Zapisan je u istoj formi (relacije-tabele) kao i sami podaci. Pravo pristupa ovom katalogu imaju samo ovlašteni korisnici-administratori. Naziva se dinamički, jer definicije podataka koje se mogu vidjeti odgovaraju upravo tekućem stanju u bazi podataka.

Fizička nezavisnost znači da korisničke aplikacije ostaju neizmijenjene kada se promijeni fizička organizacija baze ili fizički metod pristupa podacima (vidi Arhitektura baze podataka). Praktično, fizička organizacija podataka ima uticaj samo na performanse (brzinu pristupa podacima, odziv sistema).

Logička nezavisnost Ekvivalentno prethodnom uslovu, samo u obrnutom smjeru;

Integritetska nezavisnost o Integritet entiteta definiše da je primarni ključ jedinstven na nivou cijele relacije. o Integritet domena određuje skup dozvoljenih vrijednosti kolone o Relacioni integritet

Svaki atribut u relaciji vezuje se za određeni domen, pa povezivanjem atributa ne smije da se naruši (analiziraj kasnije kardinalnost).

o Referencijalni integritet odražava definisane odnose (relacije) među tabelama kada se u njih dodaju ili se iz njih brišu zapisi (analiziraj kasnije anomalije), naglašava da izmjena bilo kog podatka ne smije da mijenja karakter drugog.

2.6.3.1Zadatak:uvodukreiranjerelacionogmodela Želimo kreirati bazu podataka Generacija2016 koja predstavlja generaciju učenika (npr. neke gimnazije, koju ćemo analizirati kao sistem iz realnog svijeta koga želimo modelirati i dizajnirati bazu koja ga predstavlja). Izbor relacija i definisanje atributa Prvo analiziramo problem, odredimo podatke koje želimo pamtiti (poželjno je da to uradimo u pisanoj formi), na osnovu toga definišemo objekte i podatke, prepoznamo entitete i njihova svojstva, koje želimo predstaviti relacijama; odnosno definišemo tabele i kolone. Krenućemo od skupa učenika škole koga želimo predstaviti relacijom-tabelom Ucenik u kojoj ćemo smještati i čuvati podatke o razredu, odjeljenju, smjeru, broju u dnevniku, imenu, prezimenu, datumu rođenja, polu i adresi stanovanja. Nedostaju predmeti i ocjene, njihovo uvođenje ostavljamo za napredne učenike kad se upoznaju ne samo sa preostalim temama modeliranja baza već i Access-om. Moguće rješenje je definisanje baze Generacija 2016 sa dvije tabele-relacije: L_Podaci i Odjeljenja i njihovih atributa (kolona).

L_Podaci

JMBG Odje ljenje

Br_ dnevnik

Prezime Ime Dat_rodj Pol Adresa Grad

0123456 I-1 18 Marković Marko 10-01-01 M Beogradska 7 Zvornik 0123456 I-1 3 Žarić Ana 05-03-00 Ž Lj. Bogdana 3 Višegrad 2345678 I-2 22 Petrović Milan 02-01-01 M Karađorđa 7 Teslić 3466677 I-2 23 Rodić Ana 05-12-99 Ž Savska 34 Kotor Varoš 4565553 I-3 22 Petrović Petar 09-12-00 M Čairska 3 Laktaši 3219871 I-3 1 Adžić Zlatko 07.07-00 M S. Đaka 19 Banja Luka


32

Odjeljenja Odjeljenje Smjer I-1 opšti I-2 opšti I-3 društveno-jezički I-4 matematički I-5 računarski

Nastavak zadatka: Definisati domene atributa relacije L_podaci. Rješenje: Atribut Domen Značenje Definicija domenaJMBG Jedinstveni broj

građanina Skup mogućih matičnih brojeva radnika

Niz karaktera, dužine 1210

Odjeljenje Oznaka i broj odjeljenja

Skup mogućih imena osoba Niz karaktera, dužine do 5.

Br_dnevnik Broj u dnevniku Skup mogućih brojeva u dnevniku

Cijeli brojevi, opseg 1-32

Prezime Prezime učenika Skup mogućih prezimena Niz karaktera, dužine do 15. Ime Ime učenika Skup mogućih imena Niz karaktera, dužine do 15. Dat_Rodj Datum Rodjenja Moguće vrijednosti za datume

rođenja učenika prvog razreda Datum, opseg, od 01-JAN-99 nadalje

Pol Pol Pol učenika Karakter (1), vrijednost M i Ž Adresa Adresa učenika Moguće adrese učenika Niz karaktera (25) Mjesto Mjesto stanovanja Moguće mjesto stanovanja Niz karaktera (15)

2.7Kandidatizaključiprimarniključ Kandidat za ključ (candidate key) je atribut, ili skup atributa, čije vrijednosti jednoznačno određuju n-torku unutar relacije. Na primjer kandidat za ključ relacije Auto mogao bi biti atribut RegistarskiBroj. Svaka relacija mora da ima barem jednog kandidata za ključ: to je skup svih atributa koji čine torku. Kandidat za ključ mora da ispuni još jedan dodatan uslov, a to je da se ne može razbiti na prostije dijelove; zbog toga skup svih atributa relacije ne mora obavezno biti kandidat za ključ. Kandidat za ključ može se sastojati od samo jednog atributa - prost ključ (simple key), ili od više njih - složen ključ (composite key). Neki autori smatraju da složeni ključevi nisu dobro rješenje i zato dodaju svojim tabelama vještačke identifikatore – npr. polja tipa autonumber; da bi izbjegli složene ključeve. Ukoliko relacija ima više kandidata za ključ, tada biramo jednog od njih i proglašavamo ga primarnim ključem. Sada, kad smo se upoznali sa primarnim ključem, relaciji možemo pridružiti i osobinu adresabilnosti: Svaka n-torka relacije određena je vrijednošću primarnog ključa. Svaki podatak je određen nazivom relacije, nazivom atributa i vrijednošću primarnog ključa. Atributi koji čine primarni ključ zovu se primarni atributi, svi ostali zovu se sporedni atributi. Primarni ključ ima dvostruku ulogu: jednoznačno definiše n-torke (red u tabeli) i omogućava da se preko njega ostvari veza sa drugim relacijama (tabelama). Nastavak zadatka 2.2.2.1: Prepoznaj - definiši primarne ključeve relacija L-Podaci i Odjeljenja.

10 Zašto nije ispravno (mada je moguće) da se JMBG definiše kao broj?


33

2.8Vezekodrelacionogmodelabaze Ako ste pažljivo čitali odjeljak o konceptualnom modelu, mogli ste zaključiti da izbor objekata, njihovo imenovanje i klasifikacija znači potpuno definisanje modela, jer izbor objekata znači i izbor veza. Pod relacijom-vezom smatramo uspostavljanje nekog odnosa između dva objekta. Događaj opisuje vezu između dva objekta. Primjer: rečenica “Učenici pišu zadaću” pokazuje da događaj „pišu“ uspostavlja vezu između dva objekta - učenika i zadaće. Objekti između kojih postoji veza ili odnos zovu se učesnici veze (participants). Kod relacionih modela veze se uspostavljaju između atributa relacija. Pojednostavljeno: Terminom veza, tj. „odnos“ (Relationships) ukazuje se na međusobne odnose između primarnih i stranih ključeva tabela. Strani ključ (Foreign key) tabele je atribut (skup atributa) koji ukazuje na zavisnost od neke druge tabele. Polazna tabela se obično zove tabela-dijete, a tabela od koje ona zavisi roditeljska tabela. Strani ključ mora zadovoljiti uslov da je skup njegovih atributa primarni ključ roditeljske tabele. Primjer sa Slike 2.10 pokazuje kako to izgleda u bazi Regionalno poslovanje, koja ima dvije tabele/relacije PoslovanjeSektora i Regije.

Slika 2.10 Odnos primarnog i stranog ključa U relacionom modelu veza nije materijalizovana, već se dinamički uspostavlja pri radu s podacima, poređenjem vrijednosti atributa u n-torkama raznih relacija. Primarni i sekundarni ključ povezuje jednakost značenja, pa jednakost naziva može, ali i ne mora biti zadovoljena.


34

2.9Kardinalnostentiteta Kardinalnost (cardinality) predstavlja odnos broja objekata koji se povezuju. Kardinalnost entiteta je uređeni par (a:b), koji pokazuje koliki je broj veza pojedinog elementa tog entiteta sa elementima entiteta s kojim je relacijski povezan.

Slika 2.13 Tipovi kardinalnosti entiteta

Postoje tri tipa kardinalnosti entiteta prema broju veza: 1. Jedan-ka-jedan (1 : 1),

Jedan primjerak prvog tipa entiteta može biti u vezi s najviše jednim primjerkom drugog tipa entiteta, te takođe jedan primjerak drugog tipa može biti u vezi s najviše jednim primjerkom prvog tipa.

2. Jedan-ka-mnogo (1 : n) Jedan primjerak prvog tipa entiteta može biti u vezi s 0, 1 ili više primjeraka drugog tipa entiteta, no jedan primjerak drugog tipa može biti u vezi s najviše jednim primjerkog prvog tipa.

3. Mnogo-ka-mnogo (M : N) Veza m:n znači da jedan primjerak prvog tipa entiteta može biti u vezi s 0, 1 ili više primjeraka drugog tipa entiteta, te takođe jedan primjerak drugog tipa može biti u vezi s 0, 1 ili više primjeraka prvog tipa.

Na Slici 2.13 dato je nekoliko ilustracija koje pokazuju različite tipove kardinalnosti i različite načine njihovog predstavljanja. Veza m:n je veza (više prema više) koja se u modelima vrlo često javlja, a ne može da se direktno implementira u relacionom modelu baze podataka. Problem veze m:n između dva entiteta se prevazilazi "razbijanjem" ove veze na dvije veze tipa l:n. Ova veza ne može da se direktno realizuje u relacionim bazama podataka, već mora posredno preko još jedne tabele, kao što je prikazano na Slici 2.13. Kardinalnost je pojam koji označava brojnost, pa se govori i o kardinalnosti relacije (entiteta), atributa i veze, što može dovesti do zabune.


35

2.10 Dvanaest pravila koji određuju relacioni sistem (Je li Kod sujevjeran?) 12 Kodovih pravila čini skup od trinaest pravila koja je predložio Edgar F. Kod11, sa ciljem da definiše šta je potrebno da poseduje jedan sistem za manipulaciju bazom podataka da bi ga mogli smatrati relacionim (RDBMS). Kod je sročio ova pravila kao deo lične potrebe da spreči razbijanje svoje vizije relacione baze podataka, s obzirom da su prodavci baza podataka nastojali početkom osamdesetih godina dvadesetog vijeka da zapakuju postojeće proizvode u relacionu oblandu. Pravilo broj 12 je posebno bilo navedeno da se suprotstavi takvim nastojanjima.

Edgar Frank Codd

(Engleska, 1923. – 2003.) dok je radio za IBM, stvorio je relacioni model za upravljanje bazom podataka

0. Sistem se mora kvalifikovati kao relacioni, kao baza podataka, i kao sistem za manipulaciju.

Da bi sistem nazvali relacionim sistemom za manipulaciju bazom podataka (RDBMS), on isključivo mora koristiti svoje relacione mogućnosti da upravlja bazom podataka.

1. Pravilo informacije: Sve informacije u bazi podataka moraju biti predstavljene na jedinstven način, svojim vrijednostima u kolonama u okviru redova tabela.

2. Pravilo garantovanog pristupa: Svi podaci moraju biti dostupni bez dvosmislenosti. Ovo pravilo je u suštini reformulacija osnovnog zahtjeva za postojanjem primarnih ključeva. Ono traži da je svaka pojedinačna vrijednost u bazi logički adresibilna navođenjem naziva tabele koja je sadrži, naziva kolone u kojoj se nalazi i vrijednosti primarnog ključa reda koji je sadrži.

3. Sistematično tretiranje null vrijednosti: Sistem mora dozvoljavati da svako polje može, po potrebi, ostati prazno (ili imati vrijednost null). Posebno, mora podržavati predstavljanje "informacija koje fale ili se ne mogu primjenti" koje je sistematično, različito od svih regularnih vrijednosti (na primer, "različito od nule i bilo kog drugog broja," u slučaju brojevnih vrijednosti), i nezavisno od tipa podataka. Takođe se naglašava da takve reprezentacije sistem mora tretirati dosljedno.

4. Aktivni, uvijek dostupan katalog zasnovan na relacionom modelu: Sistem sadrži opis baze podataka na logičkom nivou u vidu tabela, tj. relacioni katalog dostupan autorizovanim korisnicima kroz upotrebu njihovog standardnog jezika za upite. To znači da korisnici moraju biti u mogućnosti da pristupe strukturi baze podataka (katalogu) koristeći isti jezik za upite kojim se služe da bi pristupili samim podacima.

5. Pravilo razumljivog podjezika: Sistem mora da podržava bar jedan relacioni jezik koji (a) Ima linearnu sintaksu, (b) može da se koristi i interaktivno i u okviru aplikativnih programa, (c) podržava operacije definisanja podataka (uključujući definisanje pogleda), operacije manipulisanja podacima (ažuriranje podjednako kao i izdvajanje), pravila integriteta i autorizaciju, kao i operacije manipulisanja transakcijama (begin, commit, i rollback).

6. Pravilo ažuriranja pogleda: Sve poglede koje je teorijski moguće ažurirati, ažurira sistem.

7. Unošenje, ažuriranje i uklanjanje podataka na nivou skupova: Sistem mora da podržava skupovne insert, update, i delete operatore. To znači da se informacije iz relacione baze mogu izdvajati u skupovima koje čine podaci iz više redova i više tabela. Ovo pravilo traži da operacije dodavanja, ažuriranja i brisanja budu primjenjive na bilo koji skup podataka koji se može izdvojiti iz baze, a ne samo na pojedinačni red u jednoj tabeli.

8. Fizička nezavisnost podataka: Promjene na fizičkom nivou (način na koji se čuvaju podaci, da li su u pitanju nizovi ili povezane liste itd.) ne smiju zahtjevati promjene aplikacija zasnovanih na datoj strukturi.

11 izvor wikipedija prema Codd, Edgar Frank (14 October 1985), "Is Your DBMS Really Relational?", ComputerWorld.


36

9. Logička nezavisnost podataka: Promjene na logičkom nivou (tabela, kolona, redova, i tako dalje) ne smiju zahtjevati promjene aplikacija koje su zasnovane na toj strukturi. Mnogo je teže postići logičku nego fizičku nezavisnost podataka.

10. Nezavisnost od pravila integriteta: Pravila integriteta moraju biti definisana nezavisno od aplikativnih programa i sačuvana u katalogu. Mora biti predviđena mogućnost njihove izmjene u bilo kom trenutku bez nepotrebnog uticanja na postojeće aplikacije.

11. Nezavisnost od distribucije: Distribucija dijelova baze na različite lokacije mora biti nevidljiva za korisnike baze. Postojeće aplikacije moraju nastaviti da rade: (a) kada se prvi put uvodi distribucija baze; i (b) pri bilo kojoj sledećoj distribuciji podataka u sistemu.

12. Pravilo zaštite podataka: Ako sistem podržava upotrebu jezika koji rade na niskom nivou (manipulacija jednim slogom u datom trenutku), onda oni ne mogu biti korišćeni za napad na sistem, u smislu zaobilaženja pravila integriteta ili relacione sigurnosti.

2.10.1Sistemskitretman„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 obezbjeđ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.

2.10.2Neprekidanpristupdinamičkomkatalogurelacionogmodela 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 primjenjivati jedinstveni relacioni jezik za pretragu ovih meta-podataka. Pod pojmom "katalog" podrazumjeva se direktorij u kojem se nalaze sistemske definicije podataka. Uvidom u katalog podataka može se saznati koje kolone posjeduju 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 dijela 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 dijelu 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. Važna je činjenica da pravo pristupa opisu baze imaju samo za to ovlašćeni (autorizovani) korisnici.


37

2.10.3Fizičkanezavisnost 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 neizmjenjeni 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.

2.10.4Logičkanezavisnost 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 posljedice 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.

2.10.5Integritetskanezavisnost 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 vrijednost.


38

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 neizmjenjeni. 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. 2.11Tabelarnaterminologija

Za kraj ovog poglavlja u Tabeli 2.3 dajemo jednostavan pregled termina koji se koriste u relacionoj algebri i onih koji su uobičajeni u tabelarnoj terminologiji kod većine programskih jezika koji podržavaju relacione baze (npr. Access), a koji često izazivaju zabunu.

Terminologija relacione baze podataka

Tabelarna terminologija

relaciona baza podataka skup tabela

relacija jedna tabela

atribut (svojstvo) zaglavlje kolone u tabeli

slog red od podataka u tabeli

mjera veličine skupa određenih objekata broj redova u tabeli

stepen broj kolona u tabeli

domen postavka važećih vrijednosti za podatke u koloni

MOV (Model objekti veze) ili ER model objekti-veze ili Entity-Relationship Model

Tabela 2.3 Tabelarna i standardna terminologija relacionih baza

Documents

Modeli i baze podataka Modeliranje i uvodni pojmovi · Modeli i baze podataka 2 Realan sistem je uređen i međuzavisan skup objekata koji formiraju cjelinu. . Slika 1.1 odnos realnog