Modeli i baze podataka

Modeli i baze podataka priručnik za III razred 1

Kratki istorijat baza podataka Praistorija Nastanak baza podatakaa se vezuje za Herman-aa Holerith-a koji je 1884. godine prijavio patent sistem za automatsku obradu podataka (AOP) o popisu stanovništva u SAD. Podaci na bušenim karticama su ručno r ubacivani u uredaj za očitavanje, a obrada a podataka se odnosila na prebrojavanje. Programiranje se svodilo na izbor vrste prebrojavanja a, a radilo se ručnim prespajanjem kontakata. Dotadašnja obrada podataka popisaa trajala je 10-tak godina, a sa Holerith-ovim izumom vremee obrade bilo je smanjeno na šest nedelja. Herman Hollerith je osmislio ideju po kojoj see svaki stanovnik SAD predstavlja p nizom od 80 karaktera ime, godište itd. popunjenih praznim prostorima da bi se za sva imena i obezbedila ista dužina, tako da baza podataka bude poravnata. On je uspio da proda koncept svoje mašine statističkom birou SAD. Tako je popis stanovništva iz 1890. godine bio prva automatizovana baza podataka, koja se u suštini sastojala od hiljada kutija punih bušenih kartica. Od Holerith-ove kompanije nastao je današnji IBM. Istorija Nakon Drugog svijet skog rata počeli su se pojavljivati prvi elektronski računari. Oni su se često koristili upravo za jednostavne linearnee baze podataka, najčešće za računovodstvo. Uskoro su kupci počeli da zahtjevaju više od njihovih ekstremno skupih mašina.. Sve je to vodilo do ranih baza podataka. Zanimljivo, ove rane aplikacije su nastavile da koriste Hollerith-ove bušene kartice, neznatno modifikovane u odnosu na originalni dizajn. Moderna vremena Sistemi upravljanja bazama podataka su se prvi put pojavili tokom 1960-tih godina i nastavili su da se razvijaju tokom sljedećih decenija. U većini slučajeva, periodd uvođenja je dugo trajao, t skoroo deceniju Prije navedene godine početka upotrebe. Prvi sistemi upravljanja bazom podataka razvijeni su u 1960-ima. Začetnik u tom polju bio je Charles Bachman. Bachmanovi rani radovii pokazuju da je njegov cilj bio stvaranje djelotvornije upotrebe novih uređaja s izravnim pristupom pohrane koji su postali dostupni: do tada se obrada podataka temeljila na bušenim karticama i magnetskoj vrpci, pa je takoo serijska obrada bila dominantna aktivnost. Dva su se ključna modela podatakaa pojavila u to vrijeme: CODASYLL je razvio mrežni model baziran na Bachmanovim idejama Gotovo istovremeno se počinje primjenjivati hijerarhijski model u sistemu koji je razvio North American Rockwell, a kojeg je kasnije prihvatio IBM kao kamen temeljac svojeg SUI S proizvoda. Najranija poznata upotreba termina baza podataka potječe iz 1963. kadaa je Društvoo za razvoj sistema uzelo pod pokroviteljstvo simpozij pod naslovom Razvoj i upravljanje računarski centriranom bazom podataka. Baza podataka (eng. ) kao jedinstvena riječ postala je uobičajena u Evropi E u ranim 1970-ima, a krajem desetljeća koristila se u glavnim američkim novinama. Ekvivalentni termin banka podataka koristio se vrlo rano u novinama Washington Post, 1966. Relacioni model je predložio E. F. Codd 1970. godine. On je kritikovao postojeće modele zbog zbrke apstraktnih opisa informacijskih struktura s opisima mehanizama fizičkog pristupa. Ipak je dugo vremena je relacioni model ostao samo u području akademskog interesa. Dokk su CODASYL sistemi i SUI bili zamišljeni kao rješenja praktičnog inženjerstva, uzimajući u obzir tehnologiju koja je postojala u ono vrijeme, relacioni model je zauzeo mnogo veću teoretsku perspektivu, smatrajući (ispravno) da će hardverska i softverska tehnologija uhvatiti korak s vremenom. Među prvim praktičnim realizacijamaa bili su Stonebrakerov Ingres na Berkeleyju, te projekt Sistem R u IBM-u. Obaa navedena su bili istraživački prototipovi objavljeni tijekom 1976. Prvi komercijalni proizvodi, p Oracle i DB2, nisu se pojavili sve do oko 1980. 2

1980-ih istraživačka aktivnost se usredotočila na sisteme distributivnih baza podataka i na data engine: mašine baza podataka međutim taj je napredak imao malen učinak na tržište. Druga važna teoretska zamisao bio je funkcionalni model podataka, ali bez obzira na neke specijalizirane primjene u genetici, molekularnoj biologiji i istraživanju prevara, svijet nije na njega obratio veliku pažnju. U 1990-im pažnja se prebacila na baze podataka orijentirane prema objektu. To je postiglo nekakav uspjeh u poljima gdje je bilo potrebno rukovati kompleksnijim podacima nego što bi se mogli udobno nositi relacioni sistemi: prostorne baze podataka, inženjerski podaci, multimedijski podaci. U 2000-im područje za inovacije postale su XML baze podataka. XML je kratica za EXtensible Markup Language - odnosno jezik za označavanje podataka. Ideja je bila stvoriti jedan jezik koji će biti jednostavno čitljiv i ljudima i računarskim programima. Princip realizacije je vrlo jednostavan: odgovarajući sadržaj treba se uokviriti odgovarajućim oznakama koje ga opisuju i imaju poznato, ili lako shvatljivo značenje. Format oznaka u XMLu vrlo je sličan formatu oznaka u npr. HTML jeziku. Danas je XML jezik vrlo raširen i koristi se za različite namjene: odvajanje podataka od prezentacije, razmjenu podataka, pohranu podataka, povećavanje dostupnosti podataka i izradu novih specijaliziranih jezika za označavanje. XML je standardizirani jezik i za njegovu standardizaciju brine se World Wide Web Consortium. Vremenom su se osnovne ideje tog koncepta integrisale u poboljšane relacione proizvode. XML baze podataka imaju za cilj ukoniti tradicionalnu podjelu između dokumenata i podataka, dopuštajući svim organizacijskim informacijskim resursima da se drže na jednom mjestu bez obzira da li su visoko strukturirani ili ne. Šta dalje Može se očekivati nastavak već uspostavljenih trendova a kao najzanimljivije i najperspektivnije oblasti: Nastavak razvoja univerzalnih servera, to su serveri koji mogu da upravljaju širokom lepezom raznih tipova podataka, tako da budu transparentni svim korisnicima. Implementacija veštačke inteligencije i neuronskih mreža Kombinacija interneta i televizije, kao jedinstvenog informacionog servisa u sklopu razvoja globalnih baza podataka Osnovni pojmovi Podatak, informacija, sistem i informacioni sistem Sistem predstavlja skup elemenata i njihovih međusobnih veza. Da bi bilo jasno šta cini jedan sistem, sistem se mora posmatrati u odnosu na njegovo okruženje. Granica sistema razdvaja sistem od spoljnih sistema. Interakcija sistema sa okruženjem se sastoji iz skupa ulaznih i izlaznih dejstava. Dejstvo okoline na sistem naziva se ulaz. Dejstvo sistema na okolinu je izlaz sistema. Podatak je iskaz definisan jednom prostom izjavnom rečenicom. Informacija je novi podatak koji posjeduje neku relevantnu novinu. Sistem je skup objekata, relacija između objekata i relacija između atributa (ili obilježja) tih objekata. Sistemi se dijele na prirodne i organizacione. Prirodni sistemi su oni kod kojih su relаcije između objekаtа zаsnovаne nа prirodnim zаkonimа rаzmjene mаterije i energije, dok su orgаnizаcioni izgrаđeni nа određenim principimа od strаne čovjekа i relаcije između objekаtа su zаsnovаne nа rаzmjeni informаcijа. Svi sistemi imаju osobinu otvorenosti tj. postoji rаzmjenа mаterije i energije, odnosno informаcijа između sistemа i spoljаšnje sredine. (Objekat se opisuje svojim atributima ili obilježjima, gdje atributi predstavljaju svojstva, bitne osobine koje ga karakterišu. Npr. Objekat je škola, atributi bitni za školu su naziv, vrsta, mjesto, adresa itd.) Informacioni sistem je podsistem organizacionog sistema i predstavlja skup različitih operacija nad informacijama neophodnih zа odlučivаnje u orgаnizаcionom sistemu. Te operаcije su : prikupljаnje, čuvаnje, obrаdа, rаspodjelа i prenos. Strukturu svаkog informаcionog sistemа čine izvori informаcijа, veze zа prenos i rаzmjenu informаcijа, sredstvа i ljudi zа obrаdu informаcijа i orgаni zа uprаvljаnje sistemom. 3

Cilj informacionog sistema: Obrada prikupljenih podataka u informacije, radi njihove transformacije u znanje za specifičnu (poslovnu) namenu. Osnovni zadatak informacionog sistema je prikupljanje, obrada, arhiviranje, analiza i distribucija informacija. Šta su to baze podataka Najjednostavnija definicija bi mogla glasiti: organizovani skup podataka! Šta znači organizovani? Skup podataka pripremljen tako da se s mogu jednostavno koristiti, tj. pregledavati, pretraživati, sortirati, porediti, itd., ali takođe i mijenjati (dopunjavati, brisati). Znači baza podataka je organizovana zbirka podataka. Termin je izvorno nastao unutar računarskee industrije, a njegovo se značenje proširilo popularnom upotrebom toliko da Europska direktiva za baze podataka (koja za baze podataka donosi prava za intelektualno vlasništvo) uključuje i ne elektronskee baze podatakaa unutar svoje definicije.naziv baza podataka se strogo govoreći odnosi na zbirku zapisa, a na softver r bi se trebalo odnositi o kao na sistem upravljanja bazom podataka ili SUBP. Kada je kontekst nedvojben, mnogi administratori za baze podataka i programeri p ipak koriste termin baza podatakaa da pokriju obaa značenja. Baza podataka je skup međusobnoo povezanih podataka koji se čubaju na nekom trajnom mediju obično na disku. Ti podaci su na raspolaganju korisnicima za pregledavanje, pretraživanje, brisanje, nadopunjavanje, ispravljanje. Baze podataka predstavljaju viši nivo rada s podacima u odnosu na klasične programske jezike. Riječ je o tehnologiji koja je nastala s namjerom da se uklone slabosti tradicionalne "automatske obrade podataka". Ta tehnologija osigurala je veću produktivnost, kvalitet i pouzdanost u razvoju r aplikacija koje se svode na pohranjivanje i pretraživanje podataka u računaru. Daćemo i definiciju James Martina Baza podataka je skup istovrsnih podataka s višestrukom namjenom.. Korisnik nije zainteresiran za sve vrste podataka u bazi, već samo za one o koji su mu potrebni u njegovom poslu. Korisnik može imati uvid u samo jednu, njemu potrebnu datoteku koja ima uvijek istu i to vrlo jednostavnu strukturu, iako je u biti izvedena iz mnogo kompleksnije strukture podataka. Različiti korisnici uzimaju u obzir različite datoteke izvedene iz iste baze podataka. Dakle, iako je baza podatakaa zajedničkaa većem broju korisnika, različiti korisnici je različito shvaćaju. Komponente sistema baza podatakaa i mjesto sistema za z upravljanje bazama Sistem bazaa podataka sadrži 4 osnovne komponente: 1. korisnici, 2. aplikacija nad bazom podataka, 3. sistem za upravljanje bazama podataka (Database Management System S - DBMS (SUBP)), i 4. baza podataka. Ovaj sistem možemo predstaviti slikom: Sistem za upravljanje bazom podataka (Database Menagment system (software) - DBMS (-SUBP-)): (korisničkih programa, aplikacija) i SUBP jee software uveden kao interfejs između korisnika zapisa baze podataka na disku. Korisnički programi ne pristupaju podacima direktno, već komuniciraju s ovim software-om (programom). 4

Administrator i projektant BP Administrator baze podataka je osoba odgovorna za projektovanje, implementiranje, održavanje (popravku i podešavanje) baze podataka. Njegove obaveze gotovo obuhvataju periodično stvaranje obnovljive baze podataka (backups), analiza egikasnosti i održavanje sadržaja baze podataka. Obaveze i zadaci administratora baze podataka zavise od opisa posla kompanije u kojoj radi i tehničkih karakteristika i mogućnosti administrirane baze podataka. Vrlo često se koristi i naziv projektant baze: Database Developer, ali tada je naglasak na razvoju novih baza, dok administrator uređuje i održava postojeće baze podtaka. Primjene baza podataka Baze podataka se koriste u mnogim aplikacijama, protežući se na kompletan obim računarskog softvera. Operativni sistem može da se shvati kao baza podataka. Bilo koji programski jezik može da se shvati kao baza podataka. Bilo koja aplikacija i aplikativni program može da se shvati kao baza podataka.... Jer svi oni obrađuju neke podatke i daju neke informacije korisniku. Ciljevi korišćenja baza podataka Baze podataka predstavljaju viši nivo rada s podacima u odnosu na klasične programske jezike. Taj viš nivo se sastoji uglavnom u tome da tehnologija baza podataka nastoji sljedeće ciljeve: 1. Fizička nezavisnost podataka. Razdvaja se logička definicija baze od njene stvarne fizičke građe. Znači, ako se fizička građa promijeni to neće zahtijevati promjene u postojećim aplikacijama. Prekticno to znaci da se fizicki raspored i organizacija podataka mogu mijenjati, a da se pri tome ne mora mijenjati šema, podšema i programi. 2. Logička nezavisnost podataka. Razdvaja se globalna logička definicija cijele baze podataka od lokalne logičke definicije za jednu aplikaciju. Znači, ako se logička definicija promijeni to neće zahtijevati promjene u postojećim aplikacijama. Lokalna logička definicija obično se svodi na izdvajanje samo nekih elemenata iz globalne definicije, uz neke jednostavne transformacije tih elemenata. 3. Fleksibilnost pristupa podacima. U starijim mrežnim i hijerarhijskim bazama, staze pristupanja podacima bile su unaprijed definisane a danas se zahtijeva da korisnik može slobodno upravljati podacima. Ovom zahtjevu odgovaraju jedino relacione baze. 4. Istovremeni pristup podacima. Baza mora omogućiti da veći broj korisnika istovremeno koristi iste podatke. Pritom ti korisnici ne smiju ometati jedan drugoga, te svaki od njih treba imati utisak da sam radi s bazom. 5. Čuvanje integriteta. Nastoji se automatski sačuvati korektnost podataka, i to u situaciji kad postoje greške u aplikacijama, te konfliktne istovremene aktivnosti korisnika. 6. Mogućnost oporavka nakon kvara. Mora postojati pouzdana zaštita baze u slučaju kvara hardvera ili grešaka u radu sistemskog softvera. 7. Zaštita od neovlaštenog korištenja. Mora postojati mogućnost da se korisnicima ograniče prava korištenja baze, dakle da se svakom korisniku regulišu ovlaštenja šta on smije a šta ne smije raditi s podacima. 8. Zadovoljavajuća brzina pristupa. Operacije s podacima moraju se odvijati dovoljno brzo, u skladu s potrebama određene aplikacije. Na brzinu pristupa može se uticati izborom pogodnih fizičkih struktura podataka, te izborom pogodnih algoritama za pretraživanje. 9. Mogućnost podešavanja i kontrole. Velika baza zahtijeva stalnu brigu: praćenje performansi, mijenjanje parametara u fizičkoj građi, rutinsko pohranjivanje rezervnih kopija podataka, regulisanje ovlaštenja korisnika. 5

Ostvarivanje ciljeva omogućava projektanta) ). pravilno modeliranje i upravljanjee BP (od strane administratora i Životni ciklus baze podatakaa Svaka bazaa podatak ima svoj životni vijek, početak kadaa je projektirana, pa do njene implementacije i održavanja. Uvodenje baze podataka u neko poduzeće ili ustanovu predstavlja složeni zadatak koji zahtijevaa 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 dijagramm koji pokazuje interakciju pojedinih faza razvoja i životnog ciklusa baze podatakaa 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 b podataka, budućii 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 zovee 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 vrstee operacija potrebne nad podacima. Modeliranje podatakaa 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 opiss naziva se šema. Šema opisuje o predmete koji su prikazani u bazi podataka, te odnose među njima. Ovom tematikom ćemo se kasnije detaljnoo pozabaviti. Implementacija Prethodni koraci su bili vrsta planiranja - sve na papiru (ili računaru),ali ovaj korak je realizacijaa zamišljenog. Na osnovu šeme i pod-šema, 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 realizujuu pojedine transakcije te pokrivaju potrebe raznihh aplikacija.. Baza se inicijalno puni podacima. te uz pomoć dostupnog DBMS-a (SUBP-a), fizički see realizuje baza podatakaa na računaru. Obuhvata: Implementacija šeme. Razvoj potrebnih aplikacija za rad. Inicijalno punjenje baze podataka s podacima potrebnim za početak rada. 6

Testiranjee Korisnici rade s bazom i provjeravaju da li ona zadovoljavaa sve zahtjeve. Nastoje see otkriti greške.u novije vrijeme, prije prave implementacije, razvijaju i približni prototipovi baze podataka, te se oni pokazujuu korisnicima. Jeftinu izradu prototipova omogućuju jezici 4. generacije i objektno-orijo jentisani jezici. 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šavanjee 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ćenjee ne ometa korisnike. Arhitektura BP Arhitektura baze podataka sastoji se od tri sloja i veza: interfejsa međuu slojevima. Riječ je o tri nivoa apstrakcije: Lokalni logički nivo - Čine je aplikacioni programi. Aplikacioni programi se služe samo dijelom podataka koje postoje u BP. Taj dio koji oni vide ili se služe, zove se pogled (view). Globalni logički nivo - Odnosi se na logičku predstavu o cijeloj bazi. To je ono što vidi administrator, ili projektant baze. Zapis logičke definicije zove se šema (schema). To je tekst ili dijagram kojim se imenujuu i definišeju svi podaci, veze medju podacima, te pravila kojima se čuva integritet baze podataka. Fizički nivo - To je fizički prikaz i raspored podataka na diskovima, tj. vanjskoj memoriji gdje se podacicuvaju. S ovom razinom su upoznati samo programeri koji su napisali DBMS (-SUBP-). Ovaj nivo ima svoje podstrukture: prostor na disku (cilindri i blokovi) te datoteke s zapisima. Raspored pohranjivanja opisuje kako se logičke definicije preslikavaju na fizičke uređaje. Za stvaranje baze podataka potrebnoo je zadati šemu š i poglede, a DBMS (-SUBP-) će tada automatski se pobrinuti za raspored i zapisivanje podatak na fizickoj razini.. Programi i korisnici ne pristupaju podacima direktno, već prekodbms ( SUBP). Komunikacija programaa i korisnika sa DBMS see obavlja na lokalnoj logičkom nivou. Jezici za rad s bazama podataka Komunikacija korisnika odnosno aplikacionog programa i DBMS -a odvija se pomoću posebnih jezika. Ti jezici tradicionalno se dijele na sljedeće kategorije: Jezik za opis podataka (Data Description Language - DDL). Služi projektantu p baze ili administratoru u svrhu zapisivanja šeme ili pogleda. Dakle tim jezikom definišemo podatke i veze među podacima, i to na logičkom nivou. Koji put postoji posebna varijanta jezika za šemu, a posebna za poglede. Naredbe DDL obično podsećaju na naredbe za definisanje složenih tipova podataka u jezicima poput COBOL, PL/I, C, Pascal. Jezik za manipulisanje podacima (Data Manipulationn Languagee - DML). Služi programeru za 7

uspostavljanje veze između aplikacionog programa i baze. Naredbe DML omogućuju "manevrisanje" po bazi, te jednostavne operacije kao što su upis, promjena, brisanje ili čitanje č zapisa. U nekim softverskim paketima, DML je zapravo biblioteka potprograma: "naredba" u DMLL svodi se naa poziv potprograma. U drugim paketima zaistaa se radi o posebnom jeziku: programer tada piše p programm u kojem su s izmešanee naredbe dvaju jezika, pa takav program treba prevoditi s dva prevodioca (DML-precompiler, običnii compiler). Jezik za postavljanje upita (Query Language - QL). Služi neposrednom korisniku za interaktivno pretraživanje baze. To je jezik koji podseća naa govorni (engleski) jezik Naredbe su neproceduralne, dakle takve da samo specifikuju rezultat koga želimo dobiti, a ne i postupak za dobijanje rezultata. Ovakva podela na tri jezika danas je već prilično zastarjela. Naime, kodd relacionih baza postojii tendencija da se sva tri jezika objedine u jedan sveobuhvatni. Primjer takvog integrisanog jezika za relacione baze je SQL: on služi za definisanje podataka, manipulisanje i pretraživanje. Primjeri DDL i DML jezikaa integrisanih u novije verzije SQL-a Integrisanii jezik se može koristiti interaktivno (preko online interpretera) ili se on može pojavljivatii uklopljen u aplikacione programe. Naglasimo da gore spomenute vrste jezika nisu programski jezici. Dakle ti jezici i su nam nužni da bi se povezali s bazom, no oni nam nisu dovoljni za razvoj aplikacija koje će nešto n raditi s podacima iz baze. Tradicionalni način razvoja aplikacija koje rade s bazom je korišćenje klasičnih programskih jezika (COBOL, PL/I, C, Pascal... ) s ugneždenim DML-naredbama. U 80- tim godinama 20. vijeka bili su s dosta popularni i tzv. jezici 4. generacije (4-th Generation Languages - 4GL): Riječč je o jezicima koji su bili namijenjeni isključivo za rad s bazama, te su zato u tom kontekstu bilii produktivniji od klasičnih programskih jezika opšte namene. Problemm s jezicimaa 4. generacije je bio u njihovoj nestandardnosti: svaki od njih je u pravilu bio dio nekog određenog softverskog paketa za baze podataka, te se nije mogao koristiti izvan i tog paketa (baze). U današnje vreme, aplikacije se najčešće razvijaju u standardnim objektno o orijentisanim programskim m jezicima (Java, C++,... ). Za interakcije s bazom koriste se unapred pripremljenee klase objekata. Ovakva tehnika je dovoljnoo produktivna zbog korišćenja gotovih klasa, a rezultirajući program se lako dotjeruje, uklapa u veće sistemee ili prenosi s jedne baze na drugu. 8

Poznati softverski paketi za rad s bazama podataka Baze podataka se u pravilu realizuju korišćenjem nekog od proverenih softverskih paketa. Tabelarni prikaz 1.1 daje pregled softvera koji u ovom trenutku predstavljaju tehnološki relevantni tee imaju značajan udio na svijetskom tržištu. Tabela: Softverski paketi za rad sa bazama: Proizvođačč Produkt Operativni sistem Jezici Oracle Corporation IBM Corporation Oraclee DB2 IBM Corporation (prije: Informix Informix Software Inc.) MySQL AB MySQL MS Windows (razni), Mac OS, UNIX (razni), Linux i drugi Linux. UNIX (razni), MS Windows, VMS, MVS, VM, OS/400 UNIX (razni), Linux, MS Windows Linux, UNIX (razni), MS Windows (razni), Mac OS SQL, Java i drugi SQL, COBOL, Java,... SQL. Java i drugi SQL, C, PHP.... Sybase Inc. Sybasee SQL Serverr MS Windows, OS/2, Mac, UNIX (razni), UNIXWare SQL. COBOL,... Hewlett Packard Co. Allbase/SQL UNIX (HP-UX) SQL. 4GL, C,... Cincom Systems Inc. Supra MS Windows NT/2000, Linux, L UNIX (razni), VMS, MVS, VM SQL, COBOL,... Microsoft MS SQL Server MS Windows NT/7/8 SQL. C+ +.... Microsoft Corporation MS Access MS Windows (razni) Gotovo svi današnji softverski paketi podržavaju relacioni model i SQL. Svaki od njih sadrži svoj s DBMS, uobičajene klijente (npr interaktivnii interpreter SQL), te biblioteke i alate za razvojj aplikacija. Svaki paket isporučuje se u verzijama za razne računarske platforme (operacione sisteme). Konkurencija među proizvođačima softvera za baze podataka je izuzetno velika, tako da je poslednjih godina čestoo dolazilo do njihovog nestanka, spajanja ili preuzimanja. Lista relevantnih softverskih paketa zato je svake godine sve kraća. Može se reći da je posljednje relevantnoo osveženje predstavlja pojava p public-domain sotvera poput MySQL. Access je alat koji možete koristiti za brz i lak razvoj aplikacija za relacione baze podataka koje vam pomažu u upravljanju informacijama. Možete kreirati bazu podataka koja će vam pomoći da pratite skoro sve vrste informacija, na primjer zalihe, profesionalne kontakte ili poslovne procese. U stvari, Access sadrži uzorke i predloške koje odmah možete koristiti zaa praćenje raznih informacija, što je lako čak i za početnika. Koraci i poslovi pri oblikovanju baze podataka Access, Basic, SQL 9

Modeli baza podataka Modeli su čovjekovo sredstvo pojednostavljivanja problema i njegova promatranja p samo s gledišta bitnih za ciljeve analize. Model podataka je formalni sistem koji se sastoji od: skupa objekata, - osnovnih elemenata (koncepata) baze podatakaa skupa operacijaa koje se provode nad objektima skupa integritetskih ograničenja (integrity constraints) kojima se definiše skup važećih pravila Objekt promatranja (npr. knjiga ) ima i uvijek više obilježja od kojih u danom trenutku analize može bitii dovoljan samo njihov manji broj (npr. samo naslov i inventarni broj). To T su najvažnija obilježja potrebna u postupku pretraživanja i pronalaženja knjige u knjižnici ili pretraživanja unutar informacijskog sistema. Ostala obilježja, npr. boja knjige, format, brojj stranica, autor nisu bitna (mogu se zanemariti) za takav postupak. Podaci su logički organizovani po nekom modelu. Model čini osnovu za osmišljavanje, definisanje i implementiranje baze podataka. Različite tehnike se koriste za strukturu modela podataka. Sistem baze podataka se gradi oko jednog određenog modela podataka, iako je u porastu zajedničko proizvodima da nude podršku za više od jednog modela. Za bilo koji logički model mogu biti mogućee različite fizičke izvedbe, a većinaa će proizvoda ponuditii korisniku neki nivo kontrole u prilagođenju fizičke implementacije. Primjer toga je relacioni model: sve ozbiljne implementacijee relacionog modela dopuštaju stvaranje indeksa, koji omogućuju brzi pristup redovima u tabeli, ako su poznate vrijednosti određenih kolona. Model nije podacima. samo način strukturiranja podataka: on takođe definiše skupp operacija koje se mogu izvoditi na Baze podataka mogu se organizovati na različitee načine. Tri su najčešća i najrasprostranjenijaa modela baza podataka: hijerarhijski model podataka, mrežni model podataka i relacijski model podataka. Razlikuju se međusobno u troškovima primjene, brzini pristupa podacima, stepenu redundanse podataka, načinima zadovoljenja potreba korisnika za informacijama. Hijerarhijski model Struktura hijerarhijskog modela je u obliku drveta. 10

Podaci su organizovanii u entitete, pri čemu je entitet na najvišem nivou, tzv. korijen. Svaki entitet višeg nivoa povezan je sa entitetom nižeg nivoa relacijom tipa roditelj - djete, tako da je jednom entitetu višeg nivoa podređeno više entiteta nižeg nivoa, a jedan entitet nižeg nivoa imaa samo jedann nadređeni entitet. Hijerarhijskom strukturom može se prikazati odnos 1:više, dok se odnos više:više ne može dobroo izvesti. Osnovni nedostatci hijerarhijskog modela, pored krutosti u predstavljanju podataka, su problemi pri unošenju, brisanju i ažuriranju. Unošenje bilo kog segmenta nije moguće ako nee postoji njegov nadređeni segment. Brisanje nadređenog segmenta dovodi do brisanja njemu podređenih segmenata. Problem ažuriranja je u tome što često ažuriranjee jednog podatka zavisi od o ažuriranjaa drugih podataka. Primjer 2: Hijerahijski model organizacije kod pristupa fajlovima Mrežni model Mrežni model je nastao kao posljedica ograničenja hijerarhijskog modela. Too je u stvari varijacijaa hijerarhijskog modela i hijerarhijski model možee se prevesti u mrežni i obratno. Mrežni model opisan je skupom međusobno povezanih slogova. Slog, preciznije tip (odnosno vrsta) sloga, u mnogim je aspektima sličann tipu entitetaa modela entiteta veze. Jedan slog sadrži podatke jedne pojave entiteta. Sastoji se od polja koja odgovaraju atributima. Savako polje sadrži jednu vrijednost atributa. Slogovi se povezuju fizičkim vezama (eng. link) koje su srodne binarnim vezama modela entiteti-vezepodataka mrežnog modela opisuje se dijagramom strukture podataka, čija je namjena jednakaa dijagramu entiteti veze. Slog se označava pravokutnikom, a veza linijom između dva sloga. Struktura Mrežni model se može se predstavitii usmjerenim grafom u kojem su čvorovi podaci a lukovi među čvorovima definišu vezee među podacima. Skupovi (nee treba ih mješati s matematičkim skupovima) definišu odnose "jednog naprama svima" između zapisa: jedan vlasnik, mnogo članova. Zapis može biti i vlasnik i član u bilo b kojem broju skupova. Operacije mrežnog modela navigacijske su u stilu da: program održavaa tekući položaj i upravlja od jednog do drugog zapisa prateći odnose u kojima sudjeluje zapis. Zapisi moguu takođe biti smješteni dobavljanjem ključnih vrijednosti. Mrežna struktura prikazuje relacijee među podacima u obliku više:više. Sa ovom strukturom u odnosu na hijerarhijsku smanjuje se redudantnost i skraćuje vrijeme pristupa podacima, ali je sama struktura složenija, pa samim tim i implementacija komplikovanija. Mrežni i hijerarhijski model su prilično slični.. Ustvari, hijerarhijski model m možemo smatrati specijalnom vrstom mrežnog. S druge strane, relacioni modell se po svom pristupu bitno razlikuje od ostala dva. Osnovna razlika je u načinu prikazivanja veza medu entitetima, te načinuu korišćenja tih veza. U mrežnomm ili hijerarhijskom modelu moguće je direktno prikazati vezu. Doduše,, postoje ograničenja na funkcionalnost veze, te na konfiguraciju svih veza u šemi. Veza se "materijalizuje" pomoću pointera, tj. u jednom zapisu piše adresa drugog (vezanog) zapisa. Mrežni odnosno hijerarhijski DML omogućuje samo jednostavne operacije o s jednim zapisom (upis, 11

promjena, brisanje, čitanje), te "manevrisanje" kroz šemu putem veza (dohvat prvog zapisa, koji je u zadatoj vezi sa zadatim zapisom, dohvat idućeg zapisa,... ). Ovakav pristup ima svoje prednosti i mane. Prednost je da je rad s bazom u tehničkom pogledu brz i efikasan. Mana je da korisnik može upotrebiti samo one veze koje su predviđene šemom pa su u skladu s time i materijalizovane. Relacioni odnosni- model U slučajevima složenijih veza hijerarhijski i mrežni model postaju nepogodni i zato je razvijen relacioni model. Relacioni model je uveo E. F. Codd 1970. godine u svom akademskom radu kao način stvaranja sistema upravljanja bazom podataka nezavisnije od bilo koje druge posebne primjene. To je matematički model definisan u terminima predikatne logike i teorije skupova. Sredinom 80-tih godina 20. veka relacioni model je postao prevladavajući. I danas većina DBMS koristi taj model. Iako je osnovna ideja relacione baze podataka bila veoma popularna, relativno malen broj ljudi razumije SUBP se naziva relacionim ako podržava relacione operacije, bez obzira da li provodi strogo pristajanje prema formalnom relacionom modelu. U relacionoj bazi podataka podaci se organizuju u obliku dvodimenzionalnih tabela, sa vrstama u kojima su slogovi, različiti među sobom, i kolonama u koje se smeštaju određene vrste podataka Za razliku od mrežnih baza podataka, tabele nisu povezane pokazivačima. Umjesto toga ključevi se koriste za slaganje redova podataka u različitim tabelama. Ključ je samo jedan ili više kolona u jednoj tabeli koja odgovara kolonema u drugoj tabeli. Svaka kolona može biti ključ ili se mnogostruke kolone mogu grupisati zajedno u pojedinačan ključ. Za razliku od pokazivača, nije potrebno definisati sve ključeve unaprijed; kolona se može koristiti kao ključ čak ako nije izvorno namjeravao biti jednim od njih. Ključ koji se može koristiti za jedinstveno identifikovanje reda u tabeli naziva se jedinstvenim ključem. Tipično je jedan od jedinstvenih ključeva preferirani način za povezivanje njega s redom; takav ključ definiše se kao tablični primarni ključ. U relacionom modelu veze su samo implicitno naznačene time što se isti ili sličan atribut pojavljuje u više relacija. Veza nije materijalizovana, već se dinamički uspostavlja za vreme rada s podacima, uporedbom vrijednosti atributa u n-torkama raznih relacija. Relacioni DML, osim jednostavnih operacija s jednom relacijom, mora omogućiti slobodno kombinovanje podataka iz raznih relacija. I ovaj pristup ima svoje prednosti i mane. Mana je da se veza svaki put mora iznova uspostavljati; potrebno je pretraživanje podataka, a to troši vreme. Prednost je da korisnik može uspostaviti i one veze koje nisu bile predviđene u fazi modelovanja podataka. Šta više, kao kriterijum za povezivanje, osim jednakosti za vrijednost atributa, mogu poslužiti i razni drugi (složeniji) kriterijumi. To još više povećava fleksibilnost korištenja baze U relacionom modelu težište je na dinamičkom aspektu (manje memorisanja a više manipulisanja). Zato upotrebljivost relacionog DBMS -a bitno zavisi o izražajnim mogućnostima njegovog jezika za rad s podacima. Poželjno je da taj jezik bude u što većoj mjeri neproceduralan i razumljiv neposrednim korisnicima. Ponegdje se kao poseban model izdvaja objektni model. To je model inspiriran je objektno-orijentiranim programskim jezicima. Baza je skup trajno pohranjenih objekata koji se sastoje od svojih internih podataka i metoda (operacija) za rukovanje s tim podacima. Svaki objekt pripada nekoj klasi. Između klasa se uspostavljaju veze nasljeđivanja, agregacije, odnosno međusobnog korištenja operacija. Većina osobina objektnog modela ugrađena je moderne relacione modele. 12

Modelovanje (modeliranje) podataka Stvarni svijet, zbog njegove složenosti, ne možemo prikazatii sa svim detaljima. Bazaa podataka nekog informacionog sistema predstavlja sliku stvarnogg organizacijskog sistema. Stvarni svijet predstavlja se pojednostavnje- stvarnog svijeta predstavlja preslikavanje stvarnog svijeta u oblik pogodan za nim, zamjenskim modelom. Modeliranje računarsku obradu. Model stvarnog svijeta predstavlja se uz pomoć nekog formalnog sistema. Model podataka je formalni sistem koji koristimo kod modeliranja baza podataka Apstrakcija i šemee za modeliranje baze podataka 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 podrazumjevaa 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. 13

Konceptualna, interna i eksterna šema Kao rezultat kreiramo model baze podataka kogaa predstavljamo odgovarajućom šemama. Pojam šemee odgovara pojmu strukture baze podataka se opisuje na tri nivoa apstrakcije: 1. Na konceptualnom nivou opisuje se KONCEPTUALNA ŠEMAA 2. Na unutaršnjem nivou opisuje se INTERNA ŠEMA 3. Na vanjskom nivou opisuju se EKSTERNE ŠEME Jedna bazaa podataka ima jednu konceptualnu u, jednu internu i (najčešće) više eksternih šema. Šema baze podataka se relativno rijetko mijenja.. Sadržaj ili instanca baze podataka (skup svih podataka baze podataka u određenom o trenutku) se ČESTO mijenja. Konceptualna šema često se koristi i naziv LOGIČKA ŠEMA sadrži opis svih entiteta i veza, atributa, domena i integritetska ograničenja konceptualna šema se može opisatii korištenjemm modela podataka, npr. relacijskog ili ER modela. Interna šema opisuje detalje fizičke strukture pohrane pohranjeni i koje se metode koriste za pristup podacima. i metode pristupa p podacima: kako su podaci Logička šema Eksterna šema opisuje "pogled" na dio baze podataka koji je namijenjenn specifičnojj grupi korisnika. Osnova za opis eksternih šema je konceptualna šema. 14

Relacija, atribut, n torka Relacioni model zahtjeva da se bazaa podataka sastoji od skupa pravougaonih tabela - tzv. relacija. Svaka relacija ima svoje ime po kojem je razlikujemo od ostalih u istoj bazi. Jedna kolona relacije običnoo sadrži vrijednost jednog atributa ( za entitet ilii vezu) - zato kolonu poistovećujemo s atributom i obratno. Atribut ima svoje ime po kojem ga razlikujemo r od ostalih u istoj relaciji. Vrijednosti jednog atributa su podaci istog tipa. Dakle, definisan jee skup dozvoljenih vrijednosti za atribut, koji se zove domen atributa. Relacija je podjeljena na dva dijela: zaglavlje i tijelo. Torke čine tijelo relacije r dok se zaglavlje sastoji od... zaglavlja. Obratite pažnju na to da se u relacionoj notaciji natpis u zaglavlju svakog atributa sastoji od dva dijela, razdvojena dvotačkom na primjer, UnitPrice:Currency. Prvi dio natpisa je ime atributa, dok je drugi domen atributa. Vrijednost atributa mora biti jednostruka i jednostavna (ne da se rastaviti na dijelove). Pod nekim uslovima tolerišemo situaciju da vrijednost atributa nedostaje (nije upisana). Jedan red relacije (tabele) običnoo predstavlja jedan primjerak entiteta, ili beleži vezu između dva ili više primjeraka. Red nazivamo n-torka. U jednoj relaciji ne smeju postojati dvije jednakee n-torke. Broj atributa je stepen relacije, a broj n-torki je kardinalnost relacije. Uvedena terminologija potiče iz matematike. Naime, neka je R relacija stepena n i neka su domeni njenih atributa redom D1, D2,..., Dn. Tada se R može interpretirati kao podskup Dekartovog proizvoda D1 x D2 x... x Dn. Znači, naš pojam relacijee odgovara matematičkom pojmu n-narne relacije. U komercijalnim DBMS, umjesto "matematičkih" termina (relacija, n-torka, atribut), češće se koriste neposredni termini (tabela - table, red - row,, kolona - column) ili termini iz tradicionalnih programskih jezika (datoteka, zapis, polje). Terminologija relacione baze podataka Tabelarna terminologija relaciona baza podatakaa skup tabela relacija jedna tabela atribut (karakteristika) zaglavlje kolone u tabeli slog vrsta od podataka u tabeli mjera veličine skupa određenih objekata broj vrsta u tabeli stepen broj kolona u tabeli domen postavka važećihh vrijednostii za podatke u koloni MOV (Model objekti veze) ili ER model objekti-veze ili Entity-Relationship Model 15

Napomena (koja najčešće bez obzita na svoju važnost ima samo formalno značenje, jer u praksi je teško provodiva): Da bi se određena tabela kvalifikovala kao relacija, svaki zapis mora da bude nedvosmisleno identifikovan i tabela ne smije da sadrži duplirane zapise. (vidi Kodova pravila.) Ne zna se šta je teže nedvosmisleno je odrediti ili izbjeći dupliranje!!! Teorija relacionih baza podataka koristi relacionu algebru, ali taj dio nije od presudne važnosti za dizajniranje baze podataka. Relaciona algebra je potrebna za precizan opis operacija koje se izvode nad podacima u relacionoj bazi podataka čime se postiže veza između opisa podataka u korisnikovom pogledu i opisa podataka u konceptualnom modelu podataka konkretne baze podataka. Najviše zabune izaziva ER model i mi ćemo pri modeliranju uglavnom koristiti tabelarnu terminologiju, koja pojednostavljuje i uglavnom zadovoljava sve bitne uslove za projektovanje baze podataka. Glavna komponenta MOV pristupa je koncept entiteta (objekata i veza). Entiteti obuhvataju objekte koji se nalaze u jednoj organizaciji, kao i veze među objektima jedne organizacije, Ograničenja integriteta eniteta i veza čine važan dio MOV opisa odnosno specifikacije. Entiteti i atributi Entitet je nešto o čemu želimo pamtiti podatke, nešto što je u stanju postojati ili ne postojati, te se može identifikovati. Entitet je stvar, objekt, od značaja, realan ili imaginaran za koji je potrebno poznavati i čuvati određene informacije. Entitet može biti objekt ili biće (na primjer kuća, student, auto), odnosno događaj ili pojava Na primjer: imenice Kupci, Roba, Prodavci i Dobavljači predstavljaju očigledne entitete; ali događaji predstavŕeni glagolima kupiti i prodati takođe su entiteti.) Entitet je sve o čemu sistem treba da skladišti podatke. Entitet je opisan atributima (na primjer atributi kuće su: adresa, broj spratova, boja fasade,... ). Atribut je svaki detalj koji služi da pobliže odredi, identificira, klasificira, kvantificira ili izrazi stanje entiteta, dakle može se reći da atribut predstavlja opis entiteta. Postupkom klasifikacije može se ustanoviti skup srodnih entiteta (npr.osobe) što se može predstaviti tipom entiteta (npr. OSOBA), što znači da se tip entiteta sastoji od pojava entiteta koji imaju zajedničke atribute. JAKI entitet tip entiteta čija egzistencija nije vezana za postojanje nekog drugog tipa entiteta. SLABI entitet tip entiteta čija egzistencija zavisi o postojanju nekog drugog tipa entiteta, tj. onaj tip entiteta koji ne može postojati u bazi podataka ukoliko neki drugi tip entiteta takođe ne postoji u bazi. ID-zavisni entitet tip entiteta kod kojega identifikator jednog entiteta uključuje identifikator drugog entiteta Tipovi entiteta omogućuju da se, umjesto u formi iskaza o odnosima među entitetima, informacija može formulisati u formi iskaza o odnosima između tipova entiteta (npr. svaki sektor je u tačno jednom odeljenju.) Ukoliko neki atribut i sam zahtjeva svoje atribute, tada ga radije treba smatrati novim entitetom (na primjer model auta). Isto pravilo vrijedi i ako atribut može istovremeno imati više vrijednosti (na primjer kvar koji je popravljen pri servisiranju auta). Ime entiteta, zajedno sa pripadnim atributima, zapravo odreduje tip entiteta. Može postojati mnogo primjeraka (pojava, instanci) entiteta zadatog tipa (na primjer STUDENT je tip čiji primjerci su Petrović Petar, Marković Marko,... ). 16

Domen atributa (Domain) Domen (domain) je skup svih prihvatljivih vrijednosti koje atribut može imati. Za svaki entitet, atribut poprima vrijednosti iz određenog skupa vrijednosti koji predstavlja domen tog atributa. Domeni se formalno ne trebaju mješati s tipovima podataka; to su dva različita pojma. Tip podataka je fizički pojam, dok je domen logički pojam. Broj je tip podataka; Starost je domen. I Ulica i Prezime mogu biti predstavljeni poljima tekstualnog tipa, ali je očigledno da su u pitanju različite vrste tekstualnih polja, koja pripadaju različitim domenima. Domen je uži pojam od tipa podataka jer definicija domena zahtjeva precizniji opis validnih podataka. Uzmite kao primjer domen StručnaSprema, koji predstavlja stručnu spremu osobe. U šemi baze podataka, taj atribut se može definisati kao Text, ali to ne može biti bilo koji tekst, već samo element iz skupa {niža, srednja, viša, visoka, magistratura, doktorat}. Razumije se, ne možete sve domene definisati pojedinačnim navođenjem prihvatljivih vrijednosti. Starost, na primer, sadrži otprilike stotinak vrijednosti ako je u pitanju starost osoba, ali to mogu biti desetine hiljada razliĺitih vrijednosti kada su u pitanju muzejski eksponati. U takvim slučajevima, umjesto u obliku liste vrijednosti, lakše je definisati domen u obliku pravila koja utvrđuju da li određena vrijednost pripada skupu prihvatŕivih vrijednosti. Kategorije i tipovi atributa Kategorije podataka: Znakovni tipovi podataka, Binarni podaci, Numerički tipovi podataka, Podaci formata datum - vrijeme. Najčešći tipovi atributa: 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 bytea, BIGINT cijeli broj prikazan s 8 bytea, SMALLINT cijeli broj prikazan s 2 bytea, REAL realni broj prikazan s 4 bytea, DOUBLE PRECISION - realni broj prikazan s 8 bytea, NUMERIC [(p,s)] - realni broj zadane preciznosti, MONEY - novac, SERIAL - cijeli broj koji se samo-povećava (auto-inkrementima)), Binarni podaci, Logički podaci, Datum i vrijeme (DATE, TIME, TIMESTAMP datum+vrijeme). Dodatna svojstva atributa: DEFAULT (zadavanje predefinirane 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). 17

Relacioni model baze podataka Relacioni model ispisuje isključivo logičke aspekte podataka,odnosno relacije koje postoje među različitim podacima i ne bavi se problemom fizičkog smještaja podataka u memoriju računara. Relacione baze podataka se projektuju u vidu tabela, indeksiranih po različitim pojmovima (poljima) i sa više ključeva. Već pri njihovom kreiranju mogu se uspostaviti logičke veze između pojedinih tabela preko zajedničkih polja tako da se na lak i jednostavan način dolazi do svih potrebnih podataka, bilo da se radi o podacima samo iz jedne tabele ili se podaci dobijaju spajanjem više tabela u jednu novu, koja je privremenog karaktera, a sadrži samo polja koja su potrebna korisniku. Do podatka se u tabeli dolazi direktno pozivanjem odgovarajućeg indeksnog ključa pri čemu se pokazivač automatski pozicionira na slog sa traženim podatkom. Osnivač relacionog modela, u cilju zaštite epiteta relacioni, koji se sve češće iz komercijalnih razloga pripisivao i nekim nerelacionim sistemima za upravljanje bazama podataka, definisao je 12 (13 vidi kasnije) strogih pravila koje mora poštovati jedan RDBMS 1. On je takođe i argumentovao postojanje niza pozitivnih efekata koje u praksi postiže sistem ukoliko zadovoljava definisane kriterijume. Većina prozvođača alata i programa koji omogućavaju rad sa relacionim bazama ne pridržavaju se u potpunisti ovih pravila pa ćemo nešto detaljnije obraditi: Sistemski tretman NULL vrijednosti Neprekidan pristup dinamičkom katalogu Fizičku nezavisnost Logičku nezavisnost Integritetsku nezavisnost koje većina poštuje, a dati Osnovni pojmovi relacionog modela koje je Codd preuzeo iz matematičke teorije skupova su: Domen; Relacija i Atribut. Domen se definiše nabrajajući vrijednosti koje ulaze u sastav domena. Npr. Naziv dana u sedmici={ponedjeljak,utorak,srijeda,četvrtak,petak,subota,nedjelja} Relacija je imenovani podskup Dekartovog (Kartezijevog) proizvoda dva ili više domena. Neka su definisana dva domena. 1. Ime_prezime_studenta={Petar Petrović,Dragana IME_PREZIME_UČENIKA NAZIV_PREDMETA Draganović} Petar Petrović Matematika 2. Naziv predmeta={matematika,fizika,biologija} Petar Petrović Fizika Petar Petrović Biologija Dragana Draganović Matematika Kombinacije vrijednosti domena nazivaju se n-torke. Dragana Draganović Fizika Dragana Draganović Biologija Prema tome, relacija je skup n-torki. Tabela Relacija UČENIK_PREDMET Relaciona tabela se još naziva i relaciona šema,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 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; Redosljed kolkona,odnosno atributa je nebitan; Redosljed n-torki je nebitan i Nove se tabele mogu stvarati povezivanjem preko vrijednosti polja podataka iz istog domena iz dvije postojeće tabele. 1 Relational Database Management System-sistem relacionih baza podataka 18

Skup operacija koje se provode na relacijama, odnosno tabelama naziva se relacionom algebrom. Najčešće korišene operacije relacione algebre nad podacima su sljedeće: Operacija selekcije (Selection); Operacija projekcije (Projection) i Operacija spajanja (Join) 12 Pravila koji određuju relacioni sistem (Je li Kod sujevjeran?) 12 Kodovih pravila čini skup od trinaest pravila koja je predložio Edgar F. Kod 2, 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, 2 izvor wikipedija prema Codd, Edgar Frank (14 October 1985), "Is Your DBMS Really Relational?", ComputerWorld. 19

(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. 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. Operacija selekcije (SELECTION) SELECT operacija (označava se sa σ (sigma)) se koristi za izbor podskupa ntorki iz relacije i bazirana je na uslovu selekcije (izbora). Selekcijski uslov se ponaša kao filter: zadržava samo one ntorke koje ispunjavaju kvalifikacijski uslov Ntorke koje ispunjavaju uslov se selektuju dok se ostale ntorke odbijaju(filtriraju). Operacija selekcije predstavlja selekciju n-torki jedne relacije koje udovoljavaju zadanom kriteriju. Ntorke koje čine izraz lažnim (false) se filtriraju Izbacuju se iz rezultata operacije. RELACIJA: UČENIK IME_PREZIME GOD_ROĐENJA GOD_ŠKOLOVANJA SMJER Petar Petrović 1989. II A Drago Dragić 1987. IV B Jovan Jovanović 1989. III C Mile Milić 1990. I A Janko Janković 1989. II B RELACIJA: ROĐENI_1989. IME_PREZIME GOD_ROĐENJA GOD_ŠKOLOVANJA SMJER Petar Petrović 1989. II A Janko Janković 1989. II B Jovan Jovanović 1989. III C Tabela Primjer relacione operacije selekcije 20

Operacija projekcije (PROJECTION) PROJECT operacija se označava s π(pi) Ova operacija zadržava određene kolone (atribute) iz relacijee a druge kolone PROJECT kreira vertikalno particioniranje. Lista specificiranih stupaca (atributa) se zadržava u svakoj ntorki. Ostali atributi se izbacuju iz svake ntorkeoperacija projekcije uklanja bilo koju dupliranuu ntorku. To je zato što rezultat operacije projekcije mora bitii skup ntorki Matematički skupovi nee dozvoljavaju duplirane elemente. Operacijom projekcije iz relacione šeme se eliminišu postojeći atributi, odnosno kolone relacione tabele, koje iz nekog razloga više nisu interesantne. RELACIJA: UČENIK IME_PREZIME GOD_ROĐENJAA GOD_ŠKOLOVANJAA SMJER Petar Petrović Dragana Draganović Jovan Jovanović Milan Milanović Janko Janković 1989.. 1987.. 1989.. 1990.. 1989.. II IV III I II A B C A B RELACIJA: UČENICI_PO_GODINAMA_ŠKOLOVANJA IME_PREZIME Petar Petrović GOD_ŠKOLOVANJA II Dragana Draganović IV Jovan Jovanović Milan Milanović Janko Janković IIII I II Tabela. Primjer relacione operacije projekcijee Dekartov (Kartezijev) proizvod RXS Sastoji se od n-torki nastalih spajanjem svake n-torke relacijee R sa svakom n-torkom relacije S Dekartov proizvos se još naziva i nekontrolisano spajanje. Nastaje bezuslovnim spajanjem dvije ili više tabela. Svaki zapis jednee tabele se spaja s svim zapisima druge tabele. Primjer: Kod: SELECT * FROM RowsetA,RowsetB; 21