Baze podatakaŠta je baza podataka?

Najjednostavnije rečeno baza podataka je skup organizovanih informacija koje se odnose na određenu temu: telefonski imenik, spisak veoma važnih poslovnih partnera, kolekcija DVD filmova ili diskova sa muzikom a može biti i spisak prijatelja koji vam duguju novac. Baze podataka ne moraju da budu komplikovane; možete formirati bazu podataka tako da bude onoliko laka za upotrebu kao i bilo kakav tekst na računaru ili softverski paket za tabelarni prikaz.

Baze podataka su svuda oko vas: telefonski imenik, rečnik, čak i vaš orman. I dok su neke od ovih baza podataka organizovanije od drugih, svaka predstavlja skladište informacija. Zapazićete takođe da skoro svako oko vas koristi baze podataka.

Kasirke u prodavnicama se oslanjaju na bazu podataka o proizvodima svaki put kada skeniraju odrđeni proizvod. Mehaničar u radionici koristi bazu podataka delova kako bi video da li može pronaći isporučioca koji poseduje onu stvarčicu koja je upravo otpala sa vaših kola. Možda čak i koristite kompjuterizovanu bazu podataka dok tražite knjige u lokalnoj biblioteci (vidite, baze podataka i nisu tako strašne).

Osnovni razlog korišćenja baze podataka je imati uvid u informacije. Ali, postoji mnogo više postupaka sa bazom od pukog stavljanja informacija u nju; vi takođe želite da ponovo pozivate, sortirate, sređujete, editujete i dobijate izveštaje o informacijama. Prema tome, formiranje baze podataka važnih poslovnih partnera, na primer, zahteva da unesete sve informacije koje se odnose na poslovne partnere. Ovo zvuči kao velika količina rada, posebno ako imate stotine poslovnih partnera, ali možete manipulisati i pretraživati informacije lakše i kompletnije.

Nadam se da ste do sad promenili početno mišljenje koje ste imali o bazama podataka i možda čak i razmišljate o svim stvarima koje možete organizovati korišćenjem baze podataka.

U savremenom svetu računar je postao nezaobilazno sredstvo za obradu podataka i najefikasniji uređaj za dobijanje informacija. Pravovremena informacija je osnov poslovanja u savremenom svetu. Količina informacija koja se svakodnevno proizvodi svakim danom se uvećava s tendencijom ubrzanog rasta.

U svakoj delatnosti postoji svakodnevna potreba za operisanjem sa velikom količinom podataka. Da bi rad sa podacima bio efikasan, neophodno je da se oni grupišu prema određenim kriterijumima. Grupisanjem srodnih podataka u oblike pogodne za korišćenje nastaju baze podataka.

“Baze podataka” su postojale i pre masovne upotrebe računara, najčešće u vidu papirne dokumentacije, a pojavom računara su dobile elektronski oblik. U početku su postojale značajne razlike u organizaciji podataka, što je za posledicu imalo nemogućnost korišćenja skupine podataka formiranih u jednom programu od strane drugog programa. Praktični razlozi su primoravali stručnjake da uvedu određene standarde pri korišćenju baza podataka. Najveći broj savremenih sistema baza podataka poštuje ANSI standard (standard Američkog nacionalnog instituda za standarde).

Da bi lakše razumeli baze podataka krenućemo od nekih, uglavnom poznatih, pojmova koji su bitni za temu koju obrađujemo.

Podatak je činjenica ili ideja pogodna za obradu od strane ljudi ili mašina.Informacija je novo saznanje. Informaciju dobijamo obradom podataka. Podatak postaje informacija

kad dobije svoju upotrebnu vrednost.Sistem u kom vlada informacija je uređen sistem.

1

Baze podatakaORGANIZACIJA PODATAKA

Organizacija pdataka pdrazumeva uređenost podataka, kojom se definiše: Način prikupljanja i prihvatanje podataka Obrada podataka (ažuriranje) Način memorisanja podataka Različiti načini prikazivanja podataka preko izlaznih jedinica

Organizacione jedinice podataka možemo prikazati šemom

BAZA PODATAKA

DATOTEKA . . . DATOTEKA

SLOG . . . . . . . . . . SLOG

SEGMENT. . . . . . SEGMENT

POLJE . . . . . . . . . . . POLJE

ZNAK . . . . . . . . . ZNAK

BIT . . . . . . . . . . .BIT

Klasična organizacija podataka

Smeštanje podataka u datoteke kao najviši nivo organizacije podataka naziva se klasičnom organizacijom podataka. Istovrsni podaci sa zajedničkim obeležjima grupišu se u datoteke da bi se efikasnije obrađivali.

2

BIT – najmanja organizaciona jedinica odn. Najmanja količina podatka koja se može izraziti

ZNAK (bajt)- 8 bita – najmanja adresibilna jedinica podatka kojoj se može direktno pristupiti

POLJE (podatak) – obeležava se imenom polja. Polje ima svoj sadržaj odn. značenje, vrednost, način predstavljanja. Sadržaj polja određuje njegovu vrstu (numeričko, tekstualno...)

SEGMENT ili grupno polje sadrži dva ili više polja nad kojima se može izvršiti neka logička operacija (npr. adresa stanovanja)

SLOG ili zapis. Sadržaj sloga se odnosi na jedan pojam, pojavu ili događaj. Strukturu sloga određuju: broj, vrsta i dužina polja.

Slogovi se grupišu u DATOTEKE i zapisuju na medijumu za čuvanje podataka. Datoteka sadrži, po nekom kriterijumu, srodne podatke.

Bazu podataka čine međusobno povezane datoteke.

Program A Program B Program C Program A Program B Program A Program B

Porudžbine Naplate Plate

Podaci o kupcu Podaci o porudžbinama Cene proizvoda Podaci o

zaposlenimaPodaci o kupcuPodaci o

proizvodima

Odeljenje prodaje Računovodstvo Finansije

Baze podataka

Osnovne karakteristike datoteka su: Dvojni karakter, što znači da predstavlja i logičku i fizičku jedinicu podataka U strukturi podataka datoteke uvek postoji neki formalni red U kompjuterskoj organizaciji uvek predstavlja najčešći oblik organizacije, čuvanja i

arhiviranja podataka Datoteke se međusobno razlikuju prema sledećim osobinama

Vrsti odnosno tipu datoteke Veličini datoteke Brzini pristupa slogovima u datoteci Uređenosti podataka Mogućnosti povezivanja sa drugim datotekama

Organizacija datoteka može biti: Sekvencijalna Indeks-sekvencijalna Direktna

Datoteka se može posmatrati kao fizička i logička, odnosno kod baze podataka imamo fizički i logički pogled na podatke.

LOGIČKI pogled predstavlja viđenje podataka onako kako ih opažaju krajnji korisnici odn. Logička datoteka je organizovan niz logički povezanih podataka koji i maju svoj naziv

FIZIČKI pogled pokazuje kako su podaci stvarno o rganizovani i struktuirani na fizičkom medijumu za skladištenje podataka (struktura podataka i fizički redosled)

Često se dešava da različite datoteke sadrže iste podatke, čime se otežava njihovo održavanje i nepotrebno se zauzima memorija

Organizacijom podataka u datoteke gubi se potrebna elastičnost jer izmena u strukturi sloga dovodi do izmene u svim programima koji obrađuju taj slog

Dupliranje podataka (redundansa) dovodi do otežanog održavanja organizacije podataka.

Nedostaci klasične organizacije podataka su: Zavisnost između programa i podataka. (Svaki program mora da poznaje detaljan opis datoteka) Redudansa podataka. (Pojavljivanje istih podataka u različitim datotekama) Ograničenost deljenja podataka.(Zasebni podaci odeljenja, nema integrisanih izveštaja) Dugo vreme za razvoj. (Nema nastavka razvoja, najlakše je ispočetka) Teško održavanje programa. (80% budžeta za razvoj se troši na održavanje) Raste broj grešaka u procesu obrade Zbog nepouzdanih podataka nepouzdane su i odluke zasnovane na njima

3

Baze podatakaBaze podataka

Istorijat

Najranija poznata upotreba termina baza podataka potiče iz juna 1963. kada je Društvo za razvoj sistema uzelo pod pokroviteljstvo simpozijum pod naslovom Razvoj i upravljanje kompjuterski centriranom bazom podataka. Baza podataka (eng. ) kao jedinstvena riječ postala je uobičajena u Europi u ranim 1970-im, a krajem decenije koristila se u glavnim američkim novinama. (Banka podataka, uporedni termin, koristio se vrlo rano u novinama Washington Post, 1966.)

Prvi sistemi upravljanja bazom podataka razvijeni su 1960-ih. Začetnik u tom polju bio je Charles Bachman. Bachmanovi rani radovi pokazuju da je njegov cilj bio stvaranje delotvornije upotrebe novih uređaja s direktnim pristupom čuvanja(skladištenja) koji su postali dostupni: do tada se obrada podataka temeljila na bušenim karticama i magnetskoj traci, pa je tako serijska obrada bila dominantna aktivnost. Dva su se ključna modela podataka pojavila u to vrijeme: CODASYL je razvio mrežni model baziran na Bachmanovim idejama, te se hijerarhijski model koristio u sistemu koji je razvio North American Rockwell, a kojeg je kasnije prihvatio IBM kao kamen temeljac svojeg SUI proizvoda.

Relacioni model je predložio E. F. Codd 1970. godine. On je kritizirao postojeće modele zbog zbrke apstraktnih opisa informacijskih struktura s opisima mehanizama fiziškog pristupa. Ipak je dugo vremena relacioni model ostao samo u području akademskog interesa. Dok su CODASYL sistemi i SUI bili zamišljeni kao rešenja praktičnog inženjerstva, uzimajući u obzir tehnologiju koja je postojala u ono vrijeme, relacioni model je zauzeo mnogo veću teorijsku perspektivu, smatrajući da će hardverska i softverska tehnologija uhvatiti korak s vremenom. Među prvim verzijama bili su Stonebrakerov Ingres na Berkeleyju, te projekat Sistem R u IBM-u. Oba navedena su bili istraživački prototipovi objavljeni tokom 1976. Prvi komercijalni proizvodi, Oracle i DB2, pojavili su se oko 1980.

Tokom 1980-ih istraživačka aktivnost se usresredila na sisteme distribuiranih baza podataka i na mašine baza podataka međutim taj je napredak imao mali učinak na tržište. Druga važna teorijska zamisao bio je funkcionalni model podataka, ali bez obzira na neke specijalizirane primjene u genetici, molekularnoj biologiji i istraživanju prevara, svet nije na njega obratio veliku pažnju.

U 1990-im pažnja se prebacila na baze podataka orijentisane prema objektu. To je postiglo nekakav uspeh u poljima gdje je bilo potrebno rukovati kompleksnijim podacima od onih u relacionim sistemima: prostorne baze podataka, inženjerski podaci, multimedijalni podaci. Neke od tih ideja prihvatili su projektanti relacionih baza, koji suintegrisali nove osobine u svoje proizvode.

U 2000-im novo područje za inovacije postale su XML baze podataka. To je izbacilo novu zbirku pokrenutih društava, ali su se istovremeno ključne ideje integrisale u uspostavljene relacione proizvode. XML baze podataka imaju za cilj ukloniti tradicionalnu podelu između dokumenata i podataka, dopuštajući svim organizacionim informacionim resursima da se drže na jednom mestu bez obzira da li su visoko struktuirani ili ne.

Sistem baza podataka

4

Baze podatakaSistem baza podataka sadrži 4 osnovne komponente (slika 1): (1) korisnici, (2) aplikacija nad bazom podataka, (3) sistem za upravljanje bazama podataka (Database Management System - DBMS), i (4) baza podataka.

Slika 1. Komponente sistema baza podataka

Šta je baza podataka?

Baza podataka predstavlja kolekciju međusobno povezanih podataka koji su organizovani u tabele i druge strukture podataka, a koriste za jednu ili više aplikacija.

Osnovna namena baze podataka je da bude repozitorijum (skladište) za podatke. Podaci mogu biti različitog tipa, tekstualni, numerički, slike, audio i video zapisi i sl.

Podaci u bazi čuvaju se tako da je unos novih podataka, čitanje i pretraživanje postojećih jednostavno, efikasno i ako je moguće, bez grešaka.

Iz „definicije" baze podataka vidi se da je ona kolekcija međusobno povezanih podataka organizovanih u tabele. U ovoj „definiciji" dve su činjenice od značaja - organizacija podataka u tabele i njihova međusobna povezanost.

Podaci u bazama podataka su organizovani u dvodimenzionalne tabele. Tabela može da ima više kolona, gde svaka kolona predstavlja neku osobinu ili atribut. Vrste tabele čine konkretni podaci, odnosno konkrente vrednosti osobina/atributa nekog objekta.

Na primer, jedna tabela može da sadrži informacije o učenicima. Kolone tabele mogu da definišu ime, prezime, godinu rođenja učenika, i sl. Vrste u takvoj tabeli su učenici, tako da se svaka vrsta odnosi na jednog učenika.

Koje će tabele da sadrži baza podataka zavisi od problema za koji treba realizovati bazu podataka. Na primer, baza podataka se može odnosti na školu, pa će u tom slučaju tabele biti o učenicima, nastavnicima, odeljenjima, i sl. Postupak izbora i definisanja tabela za bazu podataka je deo procesa modeliranja odnosno izgradnje modela podataka.

Međusobna povezanost podataka je ono po čemu se baza podataka razlikuje u odnosu na fajl sisteme (datoteke) i programe za unakrsna izračunavanja ko što je Excel. Povezanost podataka obezbeđuje značajne prednosti kod pretraživanja kada korisnik može da na osnovu veza izvuče mnogo više podataka. Na primer, ako postoji tabela koja čuva podatke o učenicima i tabela sa podacima o odeljenjima, veza između učenika i odeljenja može da obezbedi da odgovarajućim zahtevom (SQL upitom) izvučete sve učenike željenog odeljenja.

Baza podataka sadrži i tzv. metapodatke, odnosno podatke o samoj strukturi baze podataka. Metapodaci mogu da se odnose na imena tabela, imena kolona u svakoj tabeli, na podatke o korisnicima podataka, kao i raznim pomoćnim strukturama koje obezbeđuju brz prstup podacima (indeksi).

Integrisanjem podataka u bazu postižu se sledeći ciljevi:

1. Smanjuje se dupliranje podataka5

Baze podataka2. Svaki korisnički program uzima podatke u odgovarajućoj strukturi i formatu3. Korišćenje podataka nije uslovljeno poznavanjem unutrašnje strukture baze podataka4. Postojeće aplikacije ne moraju se ponovo programirati pri uvođenju novog hardvera i

softvera5. Lakše se zadovoljava potreba za proširivanjem baze novim podacima6. Lakša je konrola i zamena podataka

Šta je Sistem za upravljanje bazama podataka (DBMS)?

Softverski sistem koji omogućava korisnicima definisanje, ažuriranje i kontrolu pristupa bazi podataka naziva se sistem za upravljanje bazama podataka (eng. Database Management System - DBMS). DBMS obično nudi:

Jezik za opis podataka (eng. Data Definition Language - DDL), koji omogućava korisnicima definisanje tipa i strukture podataka, kao i ograničenja nad podacima memorisanim u bazi podataka

Jezik za manipulaciju podacima (eng. Data Manipulation Language - DML), koji omogućava korisnicima umetanje, ažuriranje, brisanje i pretraživanje podataka iz baze podataka.

Jezik za definisanje načina memorisanja podataka (eng. Storage Definition Language - SDL), koji se koristi za specificiranje interne šeme baze podataka.

Kontrolisani pristup bazi podataka, što uključuje različite funkcije i mehanizme za pristup podacima u bazi podataka

Funkcije DBMSa

DBMS treba da obezbedi sledeće funkcije za kontrolisani pristup podacima u bazi podataka: Sigurnosni sistem, koji onemogućava pristup bazi podataka neautorizovanim korisnicima

(sigurnosni servisi), odnosno samo autorizovani korisnici mogu da koriste podatke u skladu sa definisanim privilegijama (autorizacioni servisi)

Integritetni sistem, koji održava konzistentnost podataka u bazi podataka, odnosno da se sve promene dešavaju u skladu sa definisanim pravilima.

Sistem za kontrolu konkurencije, koji dopušta deljivi pristup podacima iz baze podataka, tj da se obezbedi korektno ažuriranje podataka kada više korisnika pokušava istovremeno da vrši ažuriranja.

Sistem za kontrolu oporavka baze podataka, koji omogućava rekonstrukciju prethodnog konzistentnog stanja u slučaju neke hardverske ili softverske neispravnosti.

Katalog kome korisnici mogu pristupati, koji sadrži opis podataka koji su memorisani u bazi podataka.

Podrška za transakcije, koja obezbeđuje korektno izvršavanje niza transakcija koje mogu biti međusobno zavisne; transakcija je skup operacija upisa i čitanja iz baze podataka koji se tretira kao celina tj ima svoj početak i kraj.

Razne korisničke funkcije, kao što su import, eksport podataka, statističke analize, funkcije za nadgledanje,...

Administrator baze podataka

Odgovoran za organizaciju i efikasno korišćenje baze podataka. Administrator može da reorganizuje logičku i fizičku strukturu u cilju povećanja efikasnosti sistema. Administrator definiše postupke obnove oštećenih podataka i vrši oporavak baze nakon oštećenja. Administrator osigurava zahtevani nivo integriteta, pouzdanosti i privatnosti podataka. Administrator je zadužen za korišćenje i održavanje sistema obeležavanja, uvođenje standarda i

unifikaciju korišćenja baze podataka. Administrator mora biti uključen u planiranje, projektovanje i korišćenje resursa informacionog

sistema.

6

Baze podatakaTipovi sistema baza podataka

Tehnologija baza podataka se može koristiti za veliki broj aplikacija. Praktično danas skoro i da ne možete da realizujete aplikaciju koja ne koristi neki sistem baza podataka za čuvanje podataka - bez obzira da li se radi o standardnim desktop aplikacijama, kao što su knjigovodstvene aplikacije, sistemi za upravljanje dokumentima, sistemi za banke, i sl, ili se radi o modernim Web aplikacijama koje obezbeđuju složenu funkcionalnost u distribuiranom okruženju, od on-line kupovine do raznih socijalnih mreža i sl. U zavisnosti od aplikacije, zahtevi prema bazi podataka mogu značajno da se razlikuju.

Jedan granični slučaj je da vam treba aplikacija za evidenciju kućnih troškova. U tom slučaju ona obično sadrži samo nekoliko tabela, gde svaka tabela može da ima samo nekoliko stotina vrsti. Aplikaciju, a samim tim i bazu podataka, koristite samo vi, odnosno samo jedan korisnik. Za takve sisteme se obično koristi naziv personalni sistemi baza podataka. Naravno, ovakvi sistemi mogu da se primene i na mnogo složenije aplikacije od evidencije kućnog budžeta. Na primer, mogu da pokriju i poslovane manjeg preduzeća, ili da podrže rad nekog Web sajta.  

Slika 2. Personalni sistem baza podataka

S druge strane, ako imate veliku kompaniju koja ima više organizacionih jedinica, gde svaka od njih ima sopstvene poslovne procese, neophodna vam je podrška sistema baza podataka koji može da obezbedi čuvanje i pretragu velike količine informacija na više distribuiranih lokacija. Takvi sistemi sadrže veliki broj tabela, a neke od njih mogu da imaju i nekoliko stotina hiljada vrsta i više. Podacima može konkurentno da pristupa veliki broj korisnika. Takvi sistemi obično moraju da rade 24 časa dnevno, 7 dana u nedelju. Takvi sistemi su poznati kao enterprise sistemi baza podataka.  

Slika 3. Enterprise sistem baza podataka

Na slici 3. su prikazane aplikacije razvijane u različitim jezicima: Java, C#, HTML i ASP.NET. Takve aplikacije koriste velike DBMS sisteme za upravljanje bazom podataka. Nema čarobnjaka ili sličnih alata da pomognu u razvoju takvih sistema. Programeri moraju da napišu kod koji će da obezbedi pristup i pretraživanje podataka korišćenjem funkcija DBMSa.

Vrste baza podataka

7

Baze podataka Postoje različite vrste baza podataka, zavisno od toga, na koji način su podaci interno organizovani.

Tako se razlikuju: hijerarhijske, mrežne (CODASYL), relacionalne, objektno-orijentisane, objektno-relacione, prilagođene za WEB,  XML i multimedijalne baze podataka.

Svaki od ovih modela ima svoje prednosti i nedostatke.

Relacione baze podatakaRelativno niska fleksibilnost hijerarhijske i mrežne strukture baza podataka, koje zahtevaju da

elementi baze budu unapred specificirani (direktorijumi, indeksi…) uslovili su pojavu fleksibilnijih struktura organizacije baze podataka, te se od 1970.te godine zapažaju prve najave relacionih baza podataka.

Osnovna karakteristika relacionih baza podataka je da su informacije podeljene u logičke skupove podataka. Svaki logički skup podataka predstavlja tabelu baze podataka.

Tabele su osnovni objekti relacione baze podataka.Kad se podaci smeste u tabele, moguće je s njima obavljati razne operacije npr. prikazivanje,

dodavanje, brisanje, pretraživanje i štampanje.Postoji nekoliko značajnih razloga za raspodelu podataka u tabele u okviru baze podataka:o Smanjuje se broj ponavljanja istih podataka u okviru bazeo Ako je potrebna promena podataka u bazi ona se vrši samo na jednom mestu (u tabeli)o Svaka tabela u relacionoj bazi podataka predstavljaj jedan objekat s podacima koji predstavljaju

logičku celinu (učenici, ocene, zaposleni...)o Tabele mogu biti među sobom povezane što omogućava grupisanje, pretraživanje i dobijanje

informacija u različitim oblicimao Lakše se i brže dolazi do potrebnih informacijaRelacioni model je još uvek najpopularniji model podataka zbog svoje jednostavne strukture i

jednostavnog jezika baze podataka (SQL).Modeli poslovnih sistema poseduju pretežno jednostavne objekte.Relacione baze podataka se uspešno primenjuju za veliki broj tzv. “poslovnih baza podataka”.

Modeli podataka

U procesu razvoja baze podataka najpre se formira model realnog sistema, tako što se izaberu značajne karakteristike sistema koje se predstavljaju modelom.

Postoji mnogo različitih mogućnosti da se modelira sistem. U fazi modeliranja zadatak projektanta baze podataka je da otkrije funkcije koje sistem mora izvršavati, podatke koje mora pamtiti i obrađivati, informacije koje mora obezbeđivati za potrebe korisnika, sekvence u kojima se funkcije moraju izvršavati i u kojima se može pristupati podacima.

Deo modela sistema koji se odnosi na podatke naziva se model podataka. Svaki objekat, odnosno entitet, poseduje neka svojstva. Na primer, entitet "vozilo" ima vlasnika,

registarski broj, datum registracije, godinu proizvodnje, proizvođača, marku, boju, tip motora, i dodatnu opremu.

Objekti međusobno mogu biti povezani različitim odnosima odnosno relacijama. Svaka takva relacija može da poseduje posebna svojstva. Relacije se mogu iskoristiti kod pretraživanja međusobno povezanih podataka, na primer, kod pretraživanja podataka o registrovanim vozilima i njihovim vlasnicima.

Važno

8

Baze podatakaIzborom objekata, definisanjem njihovih svojstava i prepoznavanjem veza između objekata,

izvršili smo modeliranje dela realnog sveta koji predstavlja naš problem!

Osnove relacionog modela

Relacioni model ima snažnu teorijsku osnovu, koja se zasniva na matematičkoj teoriji relacija i na logici prvog reda, i za korisnika vrlo prihvatljivu reprezentaciju u vidu dvodimenzionalne tabele.

Relacioni model oslobađa korisnika frustracija oko rukovanja podacima na niskom nivou, zalaženja u detalje smeštanja podataka i metodama pristupa iz korisničkog interfejsa. Relacioni model obezbeđuje sredstva za opis podataka sa njihovom prirodnom strukturom, bez dodatnih struktura za potrebe mašinske reprezentacije. Ovaj model daje osnovu za jezik visokog nivoa za pristup  podacima koji obezbeđuje maksimalnu nezavisnost između programa, s jedne strane, i mašinske reprezentacije, s druge strane.

U relacionom modelu podataka relacije se koriste za čuvanje informacije o objektima koje treba predstaviti u bazi podataka.

U fazi projektovanja baze podataka, za konkretan problem, treba najpre prepoznati objekte realnog sveta (entiteti) za koje treba čuvati podatke i prepoznati njihove atribute. Svaki takav objekat predstavlja se relacijom u relacionom modelu.

Atributi su zajedničke osobine koje poseduju svi entiteti jednog skupa entiteta. Iz skupa atributa entiteta za potrebe konkretnog informacionog sistema bira se samo određeni podskup. Pošto se entiteti odnosno objekti realnog sveta predstavljaju relacijom, atributi predstavljaju svojstva te relacije. Pošto je relacija predstavljena tabelom, atributi predstavljaju kolone te tabele. Svaka relacija predstavlja skup torki, gde se svaka torka odnosi na konkretan entitet iz skupa entiteta. U tabelarnom prikazu relacije, vrste tabele su podaci o konkretnim entitetima, odnosno torke, tako da atribut za svaki konkretni entitet iz skupa entiteta poseduje određenu vrednost.

Skup vrednosti koje neki atribut može uzimati zovemo domen atributa. Praktično, svaki atribut u relaciji je definisan nad nekim domenom. Koncept domena je vrlo važan. Omogućava korisniku da definiše na jednom centralnom mestu značenje i izvor vrednosti koje atribut može uzimati. Svaki domen atributa se definiše: tipom podataka, dužinom podataka i opsegom vrednosti.

NULL Vrednosti atributa

Atributi uzimaju vrednosti iz odgovarajućeg domena koji im je dodeljen, što u praksi znači da će vrednosti u tabeli za neku kolonu da budu onog tipa podataka koji smo izabrali za tu kolonu. Međutim, DBMS dozvoljava da atribut nema dodeljenu vrednost što podrazumeva korišćenje tzv NULL vrednosti. Ova specijalna vrednost se mora uvesti zato što u odgovarajuću ćeliju tabele treba da stoji neka vrednost da bi pretrage i analize radile. NULL vrednost može da ima dva značenja:

Vrednost atributa za posmatrani entitet ne postoji ili još uvek nije poznata. Na primer, za radnika koji je tek treba ili je tek počeo da radi vrednost atributa prethodni radni staž nije poznata.

Vrednost atributa za posmatrani nije primenjiva. Na primer, ako za relaciju RADNIK imamo atribut FAKULTET u kome se čuva naziv fakulteta koji je radnik završio, svi radnici sa srednjom školskom spremom će imati NULL vrednost za taj atribut.

Važno Relacija se u bazi podataka predstavlja dvodimenzionalnom tabelom, gde vrste odgovaraju

pojedinim slogovima, a kolone atributima. Atributi se mogu pojavljivati u bilo kom redosledu u tabeli. Redosled vrsta tabele takođe nije bitan. Svaka tabela, kao i svaka kolona u tabeli imaju ime.

Osnovni koncepti relacionog modela podataka su:

9

Baze podatakaRelacija - Relacija odgovara pojmu tabela sa vrstama i kolonama. Atribut relacije - Predstavlja osobinu entiteta predstavljenog relacijom. Atribut je praktično imenovana kolona relacije odnosno tabele, koje se odnose na svojstva objekta predstavljenog relacijom. Domen atributa - Domen je skup dozvoljenih vrednosti za jedan ili više atributa. Praktično se odnosi na tip podatka za kolonu. Torka relacije - Torka je vrsta relacije i odnosi se na jedan slog podataka. Stepen relacije - Broj atributa relacije (unarna, ako ima jednu kolonu, binarna sa dve kolone i sl) Kardinalnost relacije - Broj vrsta (torki) relacije. Šema relacije - Šema relacije je opis relacije. Sadrži ime relacije, imena atributa i domene atributa. Relaciona baza podataka - Kolekcija normalizovanih relacija. Šema relacione baze podataka - Skup šema relacija, pri čemu svaka ima različito ime.

Očigledno je da relacija u relacionom modelu odgovara pojmu tabela u bazi podataka. U svetu baza podataka, obično se koriste jedni termini kada se govori o relacionom modelu, a drugi kada se govori o bazi podataka, odnosno implementaciji relacionog modela. Uporedni prikaz termina i njihovog značenja dat je u sledećoj tabeli (slika 4).

Relacioni model Baza podataka Relacija Tabela Torka Vrsta Atribut Kolona Domen atributa Tip podatka kolone Šema relacije Opis tabele

Slika 4. Ekvivalentni skup pojmova

Svojstva relacije

Relacija ima sledeća svojstva: Svaka relacija ima ime koje se razlikuje od imena svih ostalih relacija u šemi relacione baze podataka, Svaka ćelija tabele (određena vrstom i kolonom) kojom je relacija predstavljena sadrži samo jednu

atomičnu (prostu) vrednost, Svi atributi jedne relacije imaju različito ime, Sve vrednosti jednog atributa su iz istog domena, Sve torke relacije su različite, tj. u relaciji ne postoje duple torke, Redosled atributa u relaciji nema značaja, i Redosled torki u relaciji teoretski nema značaja, ali praktično redosled torki u relaciji može uticati na

efikasnost pristupa torkama!

Primer Recimo da RADNIK predstavlja skup radnika nekog preduzeća (entiteta, tj objekata iz realnog

sveta). RADNIK je relacija u relacionom modelu koju predstavljamo tabelom u koju ćemo da čuvamo sve radnike. Za radnike treba čuvati informacije o imenu, prezimenu, matičnom broju, adresi stanovanja i plati – sve ovo su svojstva/osobine koje su nam važne i koje smo izabrali da ih predstavimo atributima relacije, odnosno to su nam kolone u tabeli. Svaka vrsta te tabele se odnosi na konkretnog radnika. U rešenju  narednog zadatka, dat je izgled tabele koja odgovara relaciji RADNIK.

Zadatak 1

10

Baze podatakaIzbor relacija

Ako je neophodno projektovati bazu podataka koja se odnosi na preduzeće, prepoznati entitete i njihova svojstva, koje ćete predstaviti relacijama u relacionom modelu, odnosno tabelama u bazi podataka. 

Rešenje Pretpostavimo da preduzeće ima više radnika, i za svakog od njih treba čuvati informacije: ime, matični broj, stručna sprema, datum rođenja, pol, plata, adresa. Neka je preduzeće organizovano u sektore (sektor ima naziv, broj). Podaci o radnicima preduzeća se mogu predstavljaju relacijom/tabelom RADNIK sa atributima LIME (lično ime), SSL (srednje slovo), PREZIME, MBR (matični broj), DATRODJ (datum rođenja), POL, PLATA i ADRESA. Niže je prikazana jedna instanca relacije RADNIK (tabela RADNIK) i jedna instanca relacije ODELJENJE (tabela SEKTOR).

 RADNIK

LIME SSL PREZIME MBR DATRODJ POL PLATA ADRESA Ivana S Gocić 123456 15-10-87 Ž 17000 Niška 4 Milan I Savić 234567 01-03-57 M 32000 Humska 2 Ana P Rodić 666777 03-12-50 Ž 27000 Savska 34 Pera K Kostić 555333 31-12-53 M 43000 Čairska 3

SEKTOR  BRSEK NAZIV SEKTORA

SBROJ40 projektovanje60 proizvodnja80 razvoj

  Zadatak 2

Domeni atributa Identifikovati domene atributa relacije RADNIK iz prethodnog primera.

Rešenje Domeni nekih atributa relacije RADNIK su prikazani u sledećoj tabeli:

Atribut Domen Značenje Definicija domena LIME Imena Osoba Skup mogućih imena osoba Niz karaktera, dužine do 15. PREZIME Prezime Osoba Skup mogućih prezimena

osoba Niz karaktera, dužine do 15.

MBR Maticni Broj Skup mogućnih matičnih brojeva radnika

Celi brojevi, napr. opsega 111111-999999*

DATRODJ Datum Rodjenja

Moguće vrednosti za datume rođenja zaposlenih u preduzeću

Datum, opseg, od 01-JAN-44 nadalje

POL Pol Pol radnika Karakter (1), vrednost M i Ž PLATA PlataRadnika Moguće vrednosti plata

radnika Broj, opseg od minLD do 40000.00, gde je minLD minimalni republički lični dohodak

ADRESA AdresaRadnika Moguće adrese radnika preduzeća

Niz karaktera (30)

11

Baze podatakaKljučevi relacije

Da bismo jedan entitet jednoznačno identifikovali u posmatranom skupu entiteta on mora posedovati neko svojstvo, ili kombinaciju od nekoliko svojstava, takvu da vrednost tog ili tih svojstava jednoznačno određuju svaku pojavu tog tipa entiteta. Takva svojstva nazivamo karakterističnim, a njihove vrednosti koristimo kao identifikator entiteta unutar skupa.

Na primer, skup entiteta RADNIK predstavljamo relacijom/tabelom gde svaka vrsta odgovara jednom entitetu, odnosno predstavlja jednog konkretnog radnika. U tom slučaju neophodno je prepoznati svojstva (atribute) koje možemo da koristimo za identifikaciju radnika unutar skupa radnika.

U relacionom modelu podataka atribut ili skup atributa čije vrednosti predstavljaju identifikator entiteta (torke u relaciji) nazivamo ključem relacije. Takvi atributi se nazivaju ključni atributi.

Ako relacija ne poseduje atribut ili skup atributa koji je identifikuju, tada se uvodi specijalni identifikacioni atribut - ključ surogat, koji se obično označava sa ID.

U relacionom modelu podataka postoji više termina koji se koriste za relacione ključeve, što će niže biti uvedeno.   Terminologija

Ključ Pošto su sve torke relacije različite, u relaciji mora postojati atribut ili skup atributa (tzv kompozitni ključ – ključ od više atributa), nazvani relacioni ključevi ili ključevi relacije, koji na jedinstven način identifikuje svaku torku relacije.

Primarni ključ Ključ kandidat koji je odabran da na jedinstven način identifikuje torke unutar relacije.

Ključ surogat Identifikator koji je dodat relaciji kao primarni ključ, zato što relacija nema odgovarajući atribut ili skup atributa koji može biti primarni ključ relacije.

Spoljni ključ / Strani ključ Atribut ili skup atributa jedne relacije koji se uparuje sa ključem kandidatom neke druge ili iste relacije. Važan za ostvarivanje međusobnih veza između tabela!!!

Zadatak 3

Ključ relacije Identifikovati primarne ključeve relacija RADNIK i SEKTOR iz prethodnog primera.

Rešenje Primarni ključ u relaciji SEKTOR je broj sektora, odnosno atribut BRSEK, zato što na jedinstven način identifikuje svaki sektor u preduzeću (ne mogu da postoje dva sektora sa istim brojem). Ključ kandidat (i potencijalni primarni ključ) u ovoj relaciji može biti i naziv sektora, uz pretpostavku da sektori ne mogu da imaju ista imena. U relaciji RADNIK primarni ključ je očigledno matični broj radnika. Kod radnika se može identifikovati i potencijalni kompozitni ključ kandidat, na primer od kombinacije atributa ime (ime, srednje slovo i prezime zajedno) i datuma rođenja. Naravno, ovakav ključ se može izabrati ako ne postoji neki očigledniji i jednostavniji kao što je u ovom slučaju matični broj.

Relacioni integritet

Već smo ukazali da se za svaki atribut u relaciji vezuje određeni domen. Ustvari radi se o domenskim ograničenjima (eng. domain constraints), kojima se ograničava skup dozvoljenih vrednosti atributa relacije.

Postoje još dva pravila integriteta, poznata kao integritet entiteta (eng. entity integrity) i referencijalni integritet (eng. referential integrity), koja ograničavaju ili zabranjuju pojave određenih torki u relaciji.

12

Baze podatakaOgraničenja Integritet entiteta

Nijedan atribut primarnog ključa bazne relacije ne sme imati NULL vrednost. Referencijalni integritet

Ako postoji neki spoljni ključ u relaciji, njegova vrednost mora biti jednaka vrednosti ključa kandidata neke torke u matičnoj relaciji ili njegova vrednost mora biti NULL. Referencijalni integritet je važan kod definisanja međusobnih veza između tabela.

Ograničenja poslovanja (Business constraints, business logic) To su ograničenja koja definiše korisnik ili administrator baze podataka, a proističu iz pravila poslovanja realnog sistema za koji se baza projektuje. Jedno od pravila poslovanja u preduzeću je da rukovodilac mora imati veću platu od svog osoblja. Drugo pravilo može biti da radnici koji rade na lokaciji X imaju platu uvećanu za 10% od radnika na istom poslu na ostalim lokacijama sektora.

Referencijalni integritet i spoljni ključevi

Jedna od osnovnih osobina relacionih baza podataka je međusobna povezanost podataka. Za ostvarivanje veza između podataka predstavljenih relacijom koriste se strani (spoljni) ključevi. Kao što je već navedeno, strani ključ predstavlja atribut koji se uparuje sa ključem iz neke relacije.

Šta to znači u praktičnoj realizaciji? Pretpostavimo da imamo relacije RADNIK i SEKTOR, kako je to navedeno u prvom primeru, i da za

radnike treba čuvati informacije o sektoru u kome rade. U tom slučaju, dovoljno je da se u relaciju RADNIK doda atribut čije vrednosti odgovaraju ključevima u relaciji SEKTOR, tako da za konkretnog radnika ovaj atribut ima vrednost koja odgovara ključu sektora u kome radnik radi. Za relaciju RADNIK koju smo imali u primeru 1, treba dodati atribut BRSEK kao spoljni ključ relacije.

S druge strane, za SEKTOR se može zahtevati da se čuvaju informacije o rukovodiocu sektora. Rukovodioci su takođe radnici, pa se svi podaci o njima čuvaju u tabeli RADNIK. Zbog toga je dovoljno u relaciju SEKTOR dodati atribut MBRS (sa značenjem „matični broj šefa“) koji odgovara ključu relacije RADNIK i čuva vrednost koja odgovara šefu sektora. Uz strani ključ koji predstavlja vezu mogu se čuvati i druge vrednosti preko atributa veze. Na primer, uz podatak o šefu sektora može se čuvati i informacija o datumu postavljanja tako što se doda atribut DATPOST. Na primeru relacija koje smo imali u primeru 1, može se videti sadržaj tabela RADNIK sa dodatim stranim ključevima BRSEK i MBRS (prvi je primarni ključ u matičnoj relaciji SEKTOR, a drugi je primarni ključ u relaciji RADNIK), i SEKTOR sa MBR koji je primarni ključ u tabeli radnik.

Može se uočiti da je Ivani Gocić šef radnik sa matičnim brojem 66777, a to je Ana Rodić, dok je Anin šef radnik sa matičnim brojem 55333, odnosno Pera Kostić. Radnici Milan i Petar nemaju šefove, odnosno vrednost atributa MBRS je NULL.

Na osnovu vrednosti atributa BRSEK, vidi se da tri radnika rade u sektoru čiji je broj 40 (iz tabele SEKTOR to je Projektovanje), a samo jedan u sektoru sa brojem 60 (iz tabele SEKTOR to je Proizvodnja).

RADNIKLIME SSL PREZIME MBR DATRODJ POL PLATA ADRESA MBRS BRSEK Ivana S Gocić 123456 15-10-87 Ž 17000 Niška 4 66777 40 Milan I Savić 234567 01-03-57 M 32000 Humska 2 NULL 60 Ana P Rodić 666777 03-12-50 Ž 27000 Savska 34 55333 40 Pera K Kostić 555333 31-12-53 M 43000 Čairska 3 NULL 40

13

Baze podatakaSEKTOR

BRSEKNAZIV

NAZIV SEKTORA

SBROJ

MBRMATBRR

DATPOSTDATPOST

40 Projektovanje 55533 15-01-2000

60 Proizvodnja NULL 01-01-1999

80 Razvoj 23456 01-01-2001 

Navedeni primeri pokazuju kako se preko stranih ključeva mogu ostvariti veze između podataka u tabelama. Međutim, ovakav način povezivanja omogućava predstavljanje veza 1:1 i 1:N. Pri tome, 1 i N se odnose na kardinalnost (brojnost). Ako posmatrate vezu između dve relacije, gledate najpre odnos između jednog entiteta iz prve relacije i svih ostalih entiteta iz druge. Nakon toga isti postupak ponovite za drugi smer, odnosno odnos jednog entiteta iz druge relacije sa svim entitetima iz prve.

Na primer, pomenuta veza između relacija RADNIK i SEKTOR (odnosi se na radnike koji rade u nekom sektoru):

RADNIK : SEKTORX : Y

- Najpre posmatramo jednog radnika i određujemo sa koliko sektora je on u vezi. Pošto jedan radnik može da radi samo u jednom sektoru, kardinalnost sa strane sektora je 1:

RADNIK : SEKTORX : 1

- Nakon toga posmatramo jedan sektor i određujemo sa koliko radnika je u pomenutoj vezi. Jedan sektor može da ima više radnika, pa je kardinalnost sa strane radnika u ovoj vezi N:

RADNIK : SEKTORN : 1

Veze tipa 1:1 i 1:N se jednostavno definišu dodavanje stranog ključa. Kod veza 1:N, strani ključ se dodaje na N strani (u primeru, u relaciju RADNIK se doda strani ključ iz relacije SEKTOR). Kod veza 1:1 strani ključ se može dodati bilo kojoj relaciji, ali se obično bira ona kod koje svi entiteti učestvuju u vezi (ako takva postoji, ili proizvoljno na jednu ili drugu stranu ako ne postoji). Na primer, ako posmatramo vezu RADNIK:SEKTOR, ali u smislu rukovodioca sektora, svaki sektor ima jednog rukovodioca, i jedan radnik rukovodi samo jednim sektorom. Veza je očigledno 1:1. U tom slučaju treba izabrati dodavanje stranog ključa u relaciju SEKTOR zato što svi entiteti iz ove relacije učestvuju u vezi, dok to nije slučaj za entitete iz relacije RADNIK (svi sektori imaju šefa, ali nisu svi radnici šefovi).

Komplikovanija situacija je ako je veza između dve relacije više-na-više, odnosno M:N. Na primer, ako imamo relacije PREDMET koja se odnosi na predmete, i relaciju UČENIK, veza između njih (PREDMET:UČENIK) koja definiše koji učenici pohađaju odgovarajući predmet je M:N. Jedan predmet pohađa više učenika (x:N), a jedan učenik ima više predmeta (M:N). Kako predstaviti ovakvu vezu?

Predstavljanje veza tipa M:N je jedino moguće kreiranjem nove relacije koja sadrži ključeve iz obe relacije koje učestvuju u vezi, plus eventualno dodatne atribute veze ako postoje. U primeru veze PREDMET:UČENIK treba kreirati novu relaciju POHAĐA, koja sadrži atribute: ključ relacije PREDMET, ključ relacije UČENIK, i eventualno dodatne atribute veze. Ključ te nove relacije je kombinacija atributa ključeva obe relacije.  

14

Baze podataka

Predstavljanje šema relacione baze podataka

Uobičajena konvencija za predstavljanje relacione šeme je dijagram relacije. Svaka relacija se predstavlja jednim izduženim pravougaonikom koji ima onoliko ćelija koliko je atributa u relaciji. Ime relacije se ispisuje iznad pravougaonika, a imena atributa u ćelijama, pri čemu ostaje pravilo da se primarni ključ podvlači, a da se spoljni ključevi pišu italikom. Niže je prikazan dijagram relacione šeme baze podataka PREDUZEĆE:

RADNIK LIME SSLOVO PREZIME MBR DATRODJ POL ...

  ... PLATA ADRESA MBRS BRSEK

PROJEKAT NAZIV LOKPR BROJPR BRS

SEKTOR NAZIV BRSEK MBR DATPOST

CLAN_PORODICE MBR IME POL SRODSTVO DATRODJ

LOK_SEKTOR                                         RADI_NA BRSEK LOKACIJA MBR BRPR SATI

Normalizacija

Normalizacija modela baze podataka je proces definisanja strukture baze podataka (entiteti, atributi i relacije) u optimalni format. Standardne normalne forme su aditivne, dakle ako je neki model sveden na trecu normalnu formu, automatski je u drugoj i prvoj normalnoj formi. 

Osnovni ciljlj normalizacije je: Baza podataka treba biti oblikovana tako da se svaki podatak upisuje samo jednom (ili: samo na jednom mjestu)

Osnovne forme modela baze podataka su:

Prva normalna forma (1NF) Druga normalna forma (2NF) Boyce Codd Normalna Forma (BCNF) Treća normalna forma (3NF) Četvrta normalna forma (4NF) Peta normalna forma (5NF)

Prva normalna formaDa bi se postigla prva normalna forma sve kolone moraju biti atomični. Primer : ime i prezime ne

mogu se nalaziti u jednom polju jer se teže manipuliše složenim podacima.

Druga normalna formaSve kolone tabele moraju u potpunosti zavisiti od primarnog ključa tabele. Svaka tabela mora da

sadrži podatke samo o jednom subjektu.

Treća normalna forma

15

Baze podatakaTabela mora biti u prvoj i drugoj normalnoj formi i sve kolone koje nisu deo ključa moraju biti

nezavisne jedna od druge.

16