@ViPserbia

@ViPserbia production BAZE PODATAKA

-KNJIGA-

@ViPserbia

Sadraj1.Uvod 1.1. Pojam baze 1.2. Istorijat baza 1.3. Neke od veih baza podataka 1.4. Neke od manjih baza podataka 5 9 10 10 11 14 14 24 29 32 41 44 45 46 49 50 52 53 54 58 60 61 63 64 65 67 68 69 70 70 72 74 75 76 76 2

2.

Modeli strukture podataka 2.1. Osnovne strukture podataka 2.2. Dodatna definisanja nad podacima 2.3. Definisanje baze

3.

Relacione baze podataka 3.1. Programsko okruenje za upravljanje podacima 3.2. Projektovanje aplikativnih reenja primenom relacionih baza 3.3. Projektovanje baze podataka 3.4. Projektovanje relacione baza podataka 3.5. Izrada dijagrama procesa 3.6. Izrada dijagrama funkcija 3.7. Izrada dijagrama toka podataka 3.8. Izrada matrinih dijagrama 3.9. Izrada dijagrama entiteta i relacija

4.

Elementi relacione baze podataka 4.1. Tabele Tables 4.2. Formulari Forms 4.3. Upiti Queries 4.4. Izvetaji Reports 4.5. Spajanje relacija spajanje tabela 4. 6. Auriranje unos, ispravka, dodavanje 4. 7. Indeksi 4. 8. Kljuevi 4. 9. Pretraivanja, sortiranja, selekcija 4.10. Makroi i primena VBA

5.

Primena Microsoft Accessa u razvoju baze podataka 5.1. Uvodne informacije - uputstva 5.2. Primer razvoja aplikacije (poslovna praksa) 5.3. Pokretanje rada MS Accessa 5.4. Izrada tabela

@ViPserbia

5.4.1. Izrada tabela primenom Design View 5.4.2. Pregledanje i dodavanje podataka u tabelu 5.4.3. Izrada relacija izmeu tabela 5.5 Izrada i izvoenje upita 5.5.1. Upiti nad jednom tabelom 5.5.2. Upiti nad vie tabela 5.6. 5.7. 5.8. Izrada forme za obuhvat podataka Izrada i realizacija izvetaja Microsoft Access 2000 dodatne mogunosti 5.6.1. Izrada forme nad jednom tabelom 5.7.1. Izrada izvetaja nad jednom tabelom 5.8.1. Switch board manager 5.8.2. Look Up Combo box 5.8.3. Upotreba alata Expression builder 5.9. Upotreba Makroa 5.10. Primena VBA Visual Basic for Applications 5.11. Pravljenje potanskih nalepnica 5.12. Specifikacije za baze podataka u Microsoft Accessu

83 88 91 97 97 105 110 110 116 116 125 125 141 146 151 164 152 168 171 173 177 185 189 196 197 198 212 221 225

6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

Rukovanje bazama podataka Distribuirane baze podataka. Rad u mrei Bezbednost baze Zatita integriteta baze Nadzor nad radom baze Kuda dalje Prilog 1 Primer Informacionog sistema biblioteke F@M-a Prilog 2 Primer baze podataka za Osnovnu kolu Jovan Popovi Posebni izrazi koji se esto koriste u bazama podataka Literatura

3

@ViPserbia

Baze podataka1. Uvod Savremeni informacioni sistemi se sve ee pored opreme, mrenih resursa i ljudskog potencijala baziraju i na skupovima informacija, koji se najee nazivaju bazom podataka i skupovima programskih modula koji omoguavaju pristup tim podacima. Ovi skupovi programskih modula se najee nazivaju sistemi za upravljanje bazom podataka ili skraeno SUBP. Pri tome je osnovna namena SUBP da omogui svim korisnicima jednostavan i efikasan pristup podacima, to je veoma sloen zadatak, koji esto zahteva veoma kompleksan softverski sistem, te ne treba da udi to je oblast baza podataka i informacionih sistema poslednjih godina doivela buran razvoj, kako u teorijskom, tako i u praktinom smislu. Ako se pogleda dosadanji razvoj sistema za upravljanje bazama podataka (SUBP) slobodno se moe rei da je tekao spiralnim tokom. Svaki novi ciklus je poinjao nauno istraivakim radom koji se obino konkretizovao u odreene metodologije. Nakon toga je sledila faza realizacije SUBP-a i njegova eksploatacija. Faza eksploatacije je otkrivala i negativne karakteristike koncepta i naina njegove realizacije to je opet uslovljavalo pojavu sledeeg ciklusa u razvoju SUBP-a. Informacioni sistem predstavlja model realnog sistema, a proces prevoenja pojedinih koncepata realnog sistema u koncepte modela podataka naziva se projektovanje. Zbog toga je veoma bitno da je model podataka dovoljno semantiki bogat da bi mogao, na relativno lak nain prihvatiti, ali isto tako i u sebe ukljuiti razliite koncepte realnog sistema. Svaki model podataka se sastoji od objekata, operatora nad tim objektima i ogranienja. Osnovna karakteristika svakog SUBP-a je model podataka na kome se on bazira. Kada se analizira odreeni SUBP analizira se, u stvari, model podataka i nain njegove implementacije. Korienje odreenog modela podataka se susree u fazi dizajna i u fazi implementacije SUBP-a . U fazi dizajna se koristi model podataka kao sredstvo za definisanje modela informacionog sistema, koji se u fazi implementacije realizuje u modelu podataka ugraenom u SUBP.5

@ViPserbia

Veoma je vano pitanje da li su to dva razliita tipa modela podataka ili ne. Ukoliko se radi o istom tipu modela podataka tada se postavlja pitanje da li je on dovoljno semantiki bogat da bi se mogao koristiti u fazi dizajna i da li je u isto vreme jednostavan da bi se, u fazi implementacije, mogao lako realizovati. Ukoliko se u navedenim fazama radi sa razliitim tipovima modela podataka tada postoji problem njihovih semantikih razlika i naina prevoenja jednog modela u drugi. Ukoliko je semantika razlika znaajna nije mogue izvriti prevoenje semantiki bogatijeg u semantiki siromaniji model. Oigledno je da se korienje razliitih modela podataka u razliitim fazama razvoja softvera svodi na efekte i mogunosti onog koji je siromaniji. Moderna obrada podataka se zasniva na dva osnovna koncepta: a) Na konceptu baze podataka kao jedinstvenog skladita svih informacija potrebnih za opis jednog realnog sistema, iz koga onda svaki korisnik moe da izvue one informacije koje su mu potrebne, b) Na konceptu sistema za upravljanje bazom kao sloenog softverskog proizvoda, iji je cilj da korisniku omogui lako i brzo rukovanje potrebnim podacima, ne optereujui ga pritom detaljima fizike organizacije, zatite, obezbeenja konkurentnosti i drugim sloenim administrativnim poslovima. Najvei broj komercijalnih SUBP je zasnovan na hijerarhijskom, mrenom, relacionom ili objektno orijentisanom modelu podataka. Prvi sistemi za upravljanje bazama podataka bili su hijerarhijskog tipa (sistem IMS information management system, firme IBM), mada u to vreme njihovi projektanti nisu toga bili ni svesni. Pojam modela podataka, pa samim tim i hijerarhijskog modela, uveden je tek kasnije. Mreni model se pojavio neto kasnije u odnosu na hijerarhijski, dok je relacioni model neto noviji u odnosu na njih - prvi ga je predloio Codd 1970. godine. Poslednjih godina se poeo veoma intenzivno poeo primenjivati objektno orijentisani model. Prvi komercijalni relacioni SUBP pojavio se krajem sedamdesetih godina i od tada praktino kompletan razvoj SUBP i najvei broj novih realizacija koristi relacioni model podataka. Prvi eksperimentalni sistemi koji su koristili relacioni model konstruisani su u firmi IBM. Na tritu je 80 tih i 90- tih godina postojalo preko stotinu raznih relacionih SUBP. Vcina njih su koristili strukturni upitni jezik SQL - Structured Query Language ili neku njegovu varijantu. U tom periodu veoma znaajnu ulogu u svetu baza podataka je imao Rdb/VMS proizvod amerike firme Digital Equipment Corporation, namenjen raunarima tipa VAX i mikroVAX pod operativnim sistemom VMS i predstavljao je sloen, ali veoma dobar sistem za upravljanje bazama podataka, koji je podravao sve osnovne operacije relacionog modela.6

@ViPserbia

Poto se radilo o proizvodu iste firme, koja je proizvodila i hardver i sistemski softver, bilo je realno oekivati dobre performanse. Uporedna merenja su pokazivala da je u to vreme Rdb/VMS bio najbra relaciona baza na VAX raunarima. Sistem Rdb/VMS se sastojao od vie komponenata, meu kojima su bili interpreteri RDO (Relational Database Operator) i VAX SQL, preprocesor za vie programske jezike RDBPRE (Fortran, Cobol, Ada, BASIC) i RDML-Record Data Management Language (C i Pascal), odnosno SQLPRE (za upitni jezik SQL, i jezikedomaine Fortran, Cobol, Pascal, C, PL/I), te usluni program RMU (Record Management Utility), koji je olakavao rad administratoru baze. Naravno, postojao je i sam sistem za upravljanje bazom u uem smislu, koji se u literaturi na engleskom jeziku obino nazivao data base engine. Ovaj deo Rdb/VMS sistema je u izvesnom smislu predstavljao produetak operativnog sistema, jer je sadravao osnovne rutine za rad sa datotekama, relacijama, indeksima. U stvari, bilo kakav rad sa Rdb/VMS bazom, bilo interaktivno, bilo preko prevedenih aplikacionih programa, bez njega je bio nemogu. Kasnije verzije operativnog sistema VMS su bile isporuivane zajedno sa ovim softverom, to je predstavljalo deo Digitalovih napora da se probije na tritu informacionih softvera. Rdb/VMS je takoe zahtevao korienje Digitalovog integrisanog renika podataka, poznatog pod komercijalnim nazivom CDD (Common Data Dictionary). Korienje CDD renika je bilo neophodno pri definisanju strukture baze, a i kasnije, ukoliko su se koristili drugi softverski paketi, meu kojima su od poznatijih bili FMS-File Management System, TDMS- Transaction Data Management System, kao i DECforms, svi oni su bili namenjeni generisanju i korienju ekranskih formi za unoenje i/ili prikazivanje podataka, ACMS (Application Control and Management System), pomou koga su se definisale viekorisnike aplikacije i upravljalo njihovim radom, kao i sistemi za upravljanje bazama podataka zasnovanim na drugaijim modelima (kao to je bio, recimo, DMS - Database Management system Digitalov sistem za upravljanje bazom podataka u mrei). CDD je predstavljao osnovno spremite struktura podataka, renik u kojem su se uvale definicije svih zapisa za sve ove pakete, i komunikacioni mehanizam preko koga je jedan softverski paket mogao da koristi podatke, ija struktura je bila definisana u nekom drugom paketu. Za Rdb/VMS upitni jezik (koji je Digital ponegde stidljivo oznaavao kao RDML, Relational Data Manipulation Language, a veoma esto i sa RDO) moe se rei da je bio relacioni, jer su se, praktino, sve naredbe za manipulisanje podacima mogle izdavati bilo u interaktivnom dijalogu, bilo ugraene u program pisan u nekom viem programskom jeziku tree generacije (jezik-domain), kakvi su bili COBOL, FORTRAN i slino. Tako napisani programi su se najpre obraivali preprocesorom za odgovarajui jezik, a zatim standardnim prevodiocem.7

@ViPserbia

Kako je upitni jezik SQL kasnije vremenom postao standard u oblasti relacionih baza podataka, to je Digital razvio i SQL interfejs za Rdb/VMS baze. Ovaj se softver, pod komercijalnim nazivom VAX SQL, isporuivao zajedno sa Rdb/VMS softverom, te je kupac imao na raspolaganju oba interfejsa i, shodno tome, imao mogunost da bira.

8

@ViPserbia

Pojam baze podataka Pod bazom podataka se podrazumeva organizovan skup podataka koji se odnosi na sline pojmove ili predmete i skup programskih modula koji omoguavaju pristup tim podacima. Kako je ve reeno ovi moduli se nazivaju sistem za upravljanje bazom podataka, skraeno SUBP. Naime dok se organizacija podataka u datoteke naziva klasinim nainom organizovanja podataka, organizacija podataka u takozvanoj integrisanoj formi se naziva baza podataka. Podaci u bazi podataka mogu biti organizovani po vie razliitih obeleja po kojima je kasnije primenom odgovarajuih mehanizama baze mogue vriti pretraivanja i nalaenje ba onih podataka koji su potrebni. Rad sa bazom podataka se ne sastoji samo od definisanja strukture baze i pisanja upita za izvetavanje i auriranje, ve postoje i neki poslovi koji se moraju obavljati periodino ili po potrebi: potrebno je dodeljivati prava pristupa pojedinim korisnicima baze, vriti periodino kontrolu dodeljenih prava, a po potrebi, ukidati jednom dodeljena prava korisnicima koji vie ne rade; u redovnim vremenskim intervalima treba proveravati integritet podataka u bazi; periodino se moraju vriti radnje potrebne za eventualan oporavak u sluaju otkaza: arhiviranje baze na traku, rezervne diskove, CD/ove i aktiviranje dnevnika uspeno zavrenih transakcija; povremeno se moraju ispitivati performanse baze i po potrebi vriti podeavanja fizikih parametara, kako bi se vreme odziva smanjilo na najmanju moguu vrednost. Da bi se to efikasnije i uspenije obavljali ovi i slini poslovi, baza mora da poseduje vei broj funkcija za upravljanje i administriranje bazom podataka. Upravo za izvrenje tih funkcija, po pravilu, je potrebna posebna osoba, obzirom da se radi o osetIjivim poslovima, koje je potrebno dobro poznavati, a to je delom i pitanje organizacije posla, a ne samo sistema za upravljanje bazom podataka. Nadalje, veoma esto je potrebno dobro razraditi koncept transakcije kao logike jedinice pristupa bazi, zakljuavanjem i drugim mehanizmima, koji omoguavaju korektan i efikasan viekorisniki rad.

9

@ViPserbia

Istorijat baza podataka Baze podataka su se razvile kao logian nastavak datoteka file podataka koje su veoma dugo koriene u raunarstvu, a i dan danas se koriste kao osnovne jedinice u koje se smetaju podaci raznih tipova tekstualni, tabele, slike i.t.d. Prve datoteke podataka su bile sekvencijalne podaci su smetani u nizu jedan za drugim, a i pretraivanje podataka se odvijalo na isti nain. Naime u poetnim godinama primene raunara podaci su bili smetani na kartice buene kartice, a kasnije na magnetne kasete i magnetne trake. Kao to je poznato i jedan i drugi medij su sekvencijalnog tipa i da bi se dolo do podatka, koji se nalazio na drugom kraju - strani trake ili kasete, bilo je neophodno premotati celu traku odnosno kasetu. Kasnije je dolo do razvoja ureaja kao to su disketa floppi disc i diskova hard disc, CD koji su omoguavali direktniji pristup podacima. U skladu sa tim novim mogunostima koriene su tzv. indeks-sekvencijalne i indeksne datoteke kod kojih je primenom indeksa i odgovarajuih kljueva bilo mogue daleko bre pretraivanje datoteka i nalaenje potrebnih podataka. Neke od veih baza podataka Oracle Oracle je vodei sistem za upravljanje bazama podataka, prenosiv, distributivan i otvoren, poseduje izvanredne mogunosti i ima veoma visoke performanse, omoguava rad sa veoma velikim bazama podataka. On je u svetu najrasprostranjeniji DBMS data base management system sistem za rukovanje bazama podataka jer na najbolji nain zadovoljava i zahteve dananjih najzahtevnijih informacionih sistema. On u sebi sadri podrku za najkompleksnije DSS decision support systems sisteme za podrku odluivanju preko najrigoroznijih OLTP on-line transaction processing aplikacija ak do aplikacija koje zahtevaju simultane DSS i OLTP pristupe do istih kritinih podataka, pa do vodee primene u industriji zahvaljujui dobrim performansama i mogunostima koje Oracle prua korisnicima. Ono to je posebno vano kod primene Oracle-a je injenica da on omoguava da korisnik moe da integrie sve svoje raunarske sisteme bez obzira pod kojim operativnim sistemom da rade UNIX, XENIX, VMS, OS-2, MVS, a pored toga omoguava meuoperativnost sa manjim bazama ili sa slinim aplikativnim alatima. Pored toga veoma je znaajna injenica da Oracle ima razvijene brojne SQL alate i CASE- Computer Aided Software Engineering-softver ininjering pomou raunara alate koji omoguavaju korisnicima da na to laki nain mogu da rade pod Oracle-om.10

@ViPserbia

Ingres Ingres je jedna od vodeih RDBMS Relational Data Base Management Systems sistema za upravljanje relacionim bazama podataka, koji je posebno pokazao svoje izvanredne mogunosti primene pod UNIX operativnim sistemom. Ingres se koristi u mnogim oblastima. Pomenuemo samo neke kao to su trgovina, bolnice, farmacija, industrija, telekomunikacije, proizvodnja, inenjerstvo, nauka, obrazovanje, seizmika itd. Ingres baze podataka se koriste na veini vanijih UNIX platformi od single-user pojedinanih korisnika na PC personal computer linim raunarima do main frames glavnih - centralnih raunara u velikim raunskim centrima. Od 1980. godine, kada je osnovana kompanija, Ingres je prilagoen i podeen za rad pod UNIX operativnim sistemom tako da je Ingres multi server arhitektura izuzetno dobra za rad u modelu client-server klijent server, koji je prihvaen kao standard u dananjem komercijalnom okruenju. Ingres se takoe veoma lepo i uspeno primenjuje kod VAX VMS sistema, u klijent server arhitekturi, bez obzira da li lokalno ili preko mree. Informix Informix Informiks je takoe jedna od vodeih i u svetu esto primenjivanih baza podataka. Ovo je baza koja ima otvorenu arhitekturu koja kombinuje efikasnu strukturu za transfer podataka, koristi snagu SQL-a Structured Query Language jezik za strukturno programiranje - za manipulaciju podacima, za definisanje podataka kao i za kontrolu podataka, a za poveanje brzine uzimanja podataka koristi pogodnosti C-ISAM a- Indexed Sequential Access Method for the C language indeks-sekvencijalni metod pristupa uz primenu C jezika. Programiranje sa Informiksovim 4GL Fourth Generation Programming Language, programski jezik etvrte generacije je mnogo bre i jednostavnije nego sa drugim programskim jezicima. To je neproceduralan jezik koji omoguava korisniku da veoma lako moe da kreira i najkompleksnije aplikacije. Pored toga i Informiks poseduje brojne pomone alate koji korisniku olakavaju pretraivanja kao i druge manipulacije sa podacima smetenim u bazu. Nadalje Informiks nudi i svoje integrisano reenje koje omoguava korisniku da brzo razvije eljeni sistem Neke od manjih baza podataka dBase Data Base ili skraeno dBASE je verovatno najrasprostranjenija baza podataka koja se u svojim razliitim varijantama od dBASE, pa preko dBASE II, dBASE III pa11

@ViPserbia

zatim Clippera gotovo uetala u veinu linih raunara koje su korisnici irom sveta koristili u prvim fazama primene PC raunara i baza podataka na njima, ak i u varijantama kada su PC raunari povezivani u raznovrsne mree. Postepeno je izgubila dah u konkurenciji sa novodolazeim bazama i mogunostima koje su one nudile. Ipak one e ostati u seanju kao alati koje su mnogi korisnici koristili u raznim fazama svoga rada sa bazama podataka i preko kojih su upoznali osnovne principe i pravila u radu sa bazama. Visual Fox pro Fox pro baza je nastala razvojem Fox base, da bi danas prerasla u bazu koja se kao standard koristi u Visual studio okruenju kao Visual Fox pro baza podataka. Ova baza podataka je pored dBASE verovatno baza podataka koja je godinama bila najprisutnija u PC okruenju, a koja je i danas u svojoj Visual Fox pro varijanti najprisutnija baza podataka u PC raunarima koju korisnici PC raunara irom sveta koriste za svoje potrebe. Ova baza je na veoma pogodan nain prilagoena Windows okruenju i kao takva je uspela da prevazie mnoge konkurentske baze tog nivoa. Visual Fox pro danas poseduje mnoge elemente koji omoguavaju korisniku da na brz i efikasan nain moe nainiti eljenu bazu i pratee ulazno-izlazne ekrane i izvetaje i da je za veoma kratko vreme uvede u neposrednu primenu. ZIM Jedna od baza podataka koja je u periodu 1990-tih godina bila veoma rasprostranjena na naim prostorima pa i u celom svetu bila je ZIM baza podataka. Ova baza je zbog svojih veoma malih zahteva u pogledu hardverskih resursa recimo u odnosu na Oracle, kao i zbog svoje veoma dobre transportabilnosti sa manjih na vee raunarske sisteme bila veoma dobro prihvaena od strane brojnih korisnika. Obzirom da je to ipak bila 4GL baza podataka, ona je bila sa svim pogodnostima koje nude takve baze, a imala je i sopstveni ER modeler Entity Relationship data modeler modeler za definisanje relacija izmeu entiteta u bazi, koji je omoguavao otvoren pristup u razvoju aplikacija, poveavao produktivnost u razvoju aplikacija i obezbeivao jednostruko uniformno okruenje u svim fazama razvoja aplikacija. Ono to je davalo posebnu prednost ovoj bazi podataka bila je injenica da ste mogli i najsloeniju aplikaciju baze razviti na jednom PC-u, recimo pod DOS-om disc operating system, a zatim je preneti na veliki recimo VAX sistem, koji je radio pod VMS-om Vax operating system, i da ta aplikacija lepo radi kao da je razvijena na samom VAX-u.

12

@ViPserbia

Progress Progress je takoe jedna od baza podataka koja je veoma prisutna na naim prostorima. Kao i ZIM i ova baza je zahtevala relativno skromne hardverske resurse i imala mogunost veoma lakog transportovanja sa jedne raunarske opreme ili operativnog sistema na druge. Zbog toga je i bila rado primenjivana kod onih firmi koje su se bavile razvojem aplikacija za druge korisnike, jer im je na taj nain bio olakan prenos i instalacija jednom razvijenih programskih paketa aplikacija na razliite platforme koje su bile prisutne kod razliitih korisnika. Ovo je takoe baza zasnovana na visokorazvijenom i potpuno proceduralom 4GL jeziku etvrte generacije, koja poseduje veoma veliku brzinu u radu, veoma veliku efikasnost, ve pomenutu prenosivost, mogunost veoma dobrog rada u raznim varijantama mrea i pod razliitim operativnim sistemima. Pored toga ova baza podataka obezbeuje i veoma visok integritet podataka kao i sigurnost u radu.

13

@ViPserbia

2. MODELI STRUKTURE PODATAKA Projektovanje automatizovanih informacionih sistema predstavlja kompleksan poduhvat. Jedan od takvih je projektovanje strukture ili organizacije podataka. Efikasnost obrade podataka se moe posredno odreivati putem takvih kriterijuma kao to su: vreme potrebno da se pronae traeni podatak, memorijski prostor potreban za smetaj strukture podataka (danas sve manje bitan) kompleksnost algoritama za formiranje, korienje i auriranje strukture podataka. Poto se isti skup podataka moe urediti na vie naina, prilikom projektovanja se obino postavlja pitanje izbora strukture koja e omoguiti, efikasniju obradu. U operativnoj kao i u eksternim memorijama grade se, u principu, isti tipovi strukture podataka, ali se za njihovu izgradnju koriste razliiti postupci. Za izgradnju strukture podataka u operativnoj memoriji, biraju se postupci koji dozvoljavaju efikasno korienje memorijskog prostora. Pri izgradnji struktura podataka na eksternim memorijama, osnovni cilj predstavlja minimizacija broja pristupa ureaju pri traenju odreenog podatka. 2.1. Osnovne strukture podataka Kao to je poznato osnovni zadatak automatizovanih informacionih sistema je prikupljanje, obrada i prezentiranje podataka o entitetima raznih klasa. Pri tome klase entiteta mogu da predstavljaju: - klase objekata, kao to su proizvodi, zgrade ili organizacije, - klase dogaaja, kao to su uplata, ulaz robe, materijala - klasa raznih pojmova i pojava. Svaka klasa entiteta ima odreene osobine kao to su naziv, boja, vrednost, trajanje i slino. Ove osobine se nazivaju obelejima. Sa take gledita zadataka informacionog sistema, nisu sva obeleja klase entiteta jednako vana. Od obeleja, bitnih za realizaciju zadataka informacionog sistema, gradi se odgovarajui model klase entiteta. Svakom od obeleja odgovara jedan skup svih moguih vrednosti koje to obeleje, u konkretnim sluajevima, moe imati. Obeleje boja uzima vrednosti iz skupa {bela, uta, crna, plava, ...}. Obzirom da, u optem sluaju, obeleje uzima pojedine vrednosti iz datog skupa sa razliitim verovatnoama, obeleje se moe smatrati sluajnom veliinom. U

14

@ViPserbia

tom sluaju se vrednosti, koje obeleje uzima, nazivaju njegovim konkretnim vrednostima. Postoje obeleja, koje se dalje ne mogu dekomponovati i ona se nazivaju elementarnim obelejima. Naziv proizvoda, boja automobila, ime stanovnika, predstavljaju elementarna obeleja razliitih klasa entiteta. Sa druge strane ako imamo niz elementarnih obeleja ili logiki proizvod elementarnih obeleja tada se kae da on predstavlja sloeno obeleje. Sloena obeleja predstavljaju na primer adresa stanovnika (mesto,ZIP kod, ulica, broj) Pri tome konkretizacija elementarnog obeleja predstavlja elementarni podatak, a konkretizacija sloenog obeleja predstavlja sloeni podatak. Ona obeleja ije se vrednosti dobijaju primenom nekog algoritma na vrednosti drugih obeleja nazivaju se izvedenim obelejem, a njihove vrednosti izvedenim podacima. (iznos je proizvod koliine i cene i on predstavlja izvedeno obeleje) Ona elementarna ili sloena obeleja ije vrednosti jednoznano identifikuju pojave jednog tipa sloga, nazivaju se kljuem ili pak primarnim kljuem. Razna sortiranja odreenog skupa pojava odreenog tipa sloga u datoteci se najee izvravaju u saglasnosti sa vrednostima primarnog kljua. Za razliku od primarnog sekundarni klju predstavlja ono obeleje kod koga se ista vrednost javlja kao elemenat veeg broja pojava istog tipa sloga. Kada se govori o bazama podataka onda je uz njih pojmovno najee vezano traenje ili pretraivanje baze, a pojam traenja pojave sloga u datoteci i pojam pretraivanja datoteke su veoma blisko povezani za pojmove primarnog i sekundarnog kljua. Naime traenje se vri uz pomo vrednosti primarnog kljua, pa se kao rezultat traenja moe dobiti najvie jedna pojava sloga, dok se pretraivanje vri na osnovu vrednosti sekundarnog kljua, pa se kao rezultat pretraivanja moe dobiti vei broj pojava datog sloga. Pri tome treba imati na umu da i traenje i pretraivanje mogu biti bezuspeni, tj. rezultat tih aktivnosti moe biti samo konstatacija da u datoteci ne postoji pojava sloga sa posmatranom vrednou kljua. Vrednost kljua sa kojom se vri traenje ili pretraivanje naziva se argumentom traenja ili pretraivanja. Sledei pojam koji je veoma prisutan kada su u pitanju datoteke ili baze podataka je auriranje. Auriranje predstavlja skup aktivnosti koje imaju zadatak da podatke u datoteci ili bazi dovedu u saglasnost sa stvarnim stanjem obeleja entiteta. Pod pojmom auriranja se podrazumeva sledei skup aktivnosti: upisivanje novih pojava sloga u datoteku - bazu, zatim modifikacija onih obeleja koja nisu15

@ViPserbia

kljuna u postojeoj pojavi sloga kao i brisanje postojeih pojava sloga i njihovih veza ukoliko je to dozvoljeno, tj. ukoliko se ne naruava integritet baze. U nastavku emo dati neke od osnovnih pojmova koji se odnose na strukture podataka. Tako naprimer skup S moe predstavljati skup obeleja, skup slogova razliitog tipa, skup podataka, skup pojava slogova istog tipa, skup pojava slogova razliitog tipa. esto se u skupove podataka uvode razne relacija Ri (i=1,2, ...,), a kao rezultantna relacija se moe pojaviti unija, presek ili neka druga forma relacija Ri. Tako se naprimer unija R relacija R1 i R2 se definie kao R = R1UR2. Relacija se mogu predstavlja spiskom ureenih parova, a kao prikaz relacija se moe se koristiti matrica aij sa vrstama ai i kolonama matrice aj (i,j = 1,2...,N) Zatim se kao jedan od moguih naina grafikog predstavljanja strukture podataka koristi usmereni graf tj. na taj nain se moe nacrtati neka struktura. Usmerani graf G predstavlja par (S,p), gde je S skup svih elemenata, a P skup svih potega strukture dok se elementi skupa S predstavljaju se pravougaonicima sa upisanim nazivom elementa, a usmereni potezi strelicama. Na slici 2.1 je dat primer jedne takve mogue strukture podataka.S1

S2

S3

S4

S5

S6

S7

Slika 2.1 Struktura podataka - usmereni graf

Strukture podataka se mogu klasifikovati uz pomo vie kriterija, a za projektovanje informacionih sistema vani su sledei kriterijumi: -dozvoljeni broj neposrednih prethodnika i sledbenika nekog elementa strukture -priroda elemenata skupa Obzirom na prvi kriterijum, u osnovi se razlikuju linearne, hijerarhijske i mrene strukture, sa odreenim varijetetima. Vezano za drugi kriterij, u osnovi se razlikuju logike strukture obeleja, logike strukture podataka i fizike strukture podataka, kao i njihovi varijeteti16

@ViPserbia

Linearne strukture podataka se obino nazivaju se listama ili lancima. Pri tome je struktura liste veoma jednostavna jer svaki elemenat liste moe imati samo jednog prethodnika i jednog sledbenika. Na slici 2.2 je prikazana jedna takva otvorena lista, a na slici 2.3 zatvorena listaS1 S2 S3

Slika 2.2 Otvorena lista

S1

S2

S3

S6

S5

S4

Slika 2.3 Zatvorena lista

Hijerarhijska struktura - model podataka podrazumeva hijerarhijsku strukturu podataka koja ima oblik stabla. Na prvom nivou je koren stabla odnosno osnovni element stabla, a zatim se odvajaju pojedine grane stabla. Model hijerarhijske baze podataka (kao podskup mrenog modela) je tip baze podataka orijentisan jo uvek na pojmu "slog". Pri tome ovaj model dozvoljava da se slogovi organizuju (grupiu) u skupove (setove). Vlasnik skupa se naziva "roditelj" (parent), a lan skupa se naziva "dete" (child). Veze izmeu setova se realizuju sa takozvanim "poveznim listama" (linked list). Slika 2.4 ukazuje na strukture hijerarhijske eme koja ima u organizacionom smislu strukturu "drveta". To znai da je postojao "prethodni" (previous) i "sledei" (next) slog u setu: Hijerarhijske baze podataka su organizovane u relaciji "jedan prema jedan" (1:1) i "jedan prema vie" (1:M).

17

@ViPserbia

S1

S2

S3

S4

S5

Slika 2.4 Nepotpuna nekompletna hijerarhijska struktura U zavisnosti od kljua nadreenog segmenta ili grane moe da zavisi jedan, ili vie podreenih segmenata, a moe se desiti da ne postoji ni jedan podreeni segment. Pri tome treba imati na umu da su segmenti grane stabla na niem nivou u podreenom odnosu tj. podreeni segmentima odnosno granama stabla na viem nivou. Hijerarhijske strukture se nazivaju i strukturama tipa stablo. Svaki elemenat strukture naziva se vorom stabla. Pri tome vor, kome odgovara nula kolona, odnosno, vor, u koji ne dolazi ni jedan poteg, naziva se koren stabla. vor, kome odgovara nula vrsta, odnosno, vor iz koga ne polazi nijedan poteg, naziva se listom. Svaki vor predstavlja koren jednog podstabla. Meu vorovima stabla postoji hijerarhija nivoa. Koren predstavlja vor prvog nivoa hijerarhije. Proizvoljan vor se nalazi se na k-tom nivou hijerarhije (k < (l, 2,... ,h), gde je h broj nivoa hijerarhije stabla, ako se nalazi na kraju puta duine k-l, a put poinje u korenu stabla. Duina puta se meri brojem potega izmeu dva posmatrana vora. Broj nivoa hijerarhije h naziva se visinom stabla. Visinu stabla h predstavlja broj, koji je za jedan vei od duine puta izmeu korena i najudaljenijeg lista. Za stablo se kae da je puno, ako se svi listovi nalaze na istom odstojanju od korena, odnosno, ako, od korena, svakom listu odgovara put duine h-1. Za stablo se kae da je kompletno, ako svi njegovi vorovi, koji ne predstavljaju listove, imaju svih n odlaznih potega. Stablo na slici 2.1 je kompletno i puno, dok je stablo na slici 2.5 kompletno, ali nije puno, a stablo na slici 2.4 je nekompletno i nepotpuno. Za pojmove punog i kompletnog stabla vezan je i pojam kapaciteta stabla. Pod kapacitetom stabla K podrazumeva se broj elemenata koji se mogu smestiti u vorove kompletnog punog stabla reda n i visine h. Kapacitet vora k predstavlja broj elemenata koji se moe smestiti u vor.

18

@ViPserbia

S1

S2

S3

S4

S5

S6

Slika 2.5 Nepotpuna kompletna hijerarhijska struktura

Broj vorova kompletnog punog stabla C iznosi K = (nh 1)/(n-1) k Za datu vrednost C, visina punog kompletnog stabla red n iznosi: h = logn ( l+ (n-l) C). Za stablo se kae da je balansirano, ako za svaki vor vai da se broj vorova u svakom njegovom podstablu ne razlikuje za vie od jedan. Primer: Setovi slogova jedne poslovne organizacije su: Odelenje knjigovodstva o Slogovi (zaposleni) Jovanovi Petrovi Kuko Odelenje marketinga o Slogovi (zaposleni) Ugren Odelenje za informacioni sistem (IS) o Slogovi (zaposleni) Radakovi Nei Napomenimo ovde da su se jo ranih 60-tih godina pojavile prve ideje o razvoju posebnih softvera za upravljanje bazama podataka. Poznati teoretiar toga doba Charles W. Bachman (General Electric Co.) razvio je tehniku dijagrama preko kojih je stvarao takozvane programske strukturne dijagrame (PSD-program structure diagrams). Ove tehnike su znaajno poboljale metodologiju analize informacionih19

@ViPserbia

sistema. Bachmannov dijagram je grafika prezentacija uglavnom malih delova programa pomou limitiranog skupa grafikih simbola. BAZA PODATAKASET-1 Odelenje knjigovodstva SET-2 Odelenje marketinga SET-3 Odelenje za IS

Jovanovi

Petrovi

Kuko

Ugren

Radakovi

Nei

Slika 2.6 Hijerarhijska struktura - primer Rezultat toga jeste da su se pojavili IDS (Integrated Data Store) softveri opremljeni sa mogunou realizacije eme podataka (data scheme) i urnaliziranja (logging). Ovaj softver je radio na GE raunarima i mogao je da koristi samo jednu datoteku kao bazu podataka, a sve generacije tabela sa podacima morale su runo da se kodiraju (progameri su pisali rutine za navigaciju kroz bazu podataka). Jedan od korisnika ovog softvera je bila poznata hemijska kompanija za proizvodnju guma BF Goodrich Chemical Co. i oni su preradili ovaj softver i kao rezultat toga pojavio se IDMS (Integrated Data Managmenet System). Jedna od najveih multinacionalnih kompanija u oblasti informatike tehnologije IBM (international Business Machine Corp.) je 1968. uvela svoj IMS (Information Management System) sistem koji je podravao hijerarhijsku organizaciju baze podataka za svoje raunare IBM/360 generacije. Pored ovoga razvili su i alat DL/1 (Data Language One) za potrebe navigacije kroz takvu bazu. IBM je za potrebe amerikih avio kompanija razvio i podvarijantu svog reenja pod komercijalnim nazivom SABRE. Neto kasnije, 1973. godine pojavila se Cullinane Corp. (kasnije nazvana Cullinet Software Inc.) koja je poela da plasira inoviranu verziju Goodrichevog IDMS softvera i zahvaljujui tome postali su u to vreme jedna od najveih kompanija u oblasti softvera. Ova kompanija se kasnije restruktuirala u danas poznatu kompaniju CA-Computer Asscociate. Imali su i tzv. preprocesore realizovane u COBOL okruenju. Pored ovih kompanija, na tritu su bili prisutni i Honeywell sa svojim reenjima (IMS), Univac (kasnije Unisys) sa DMS 1100, TOTAL/SUPRA (Cincom) i Digital VAX DBMS. Zbog komplikovane navigacije ove baze su bile veoma kompleksne i traile su dobro osposobljeno projektantsko/programersko osoblje. Lanci (poveznice) su lako pucali i takve baze je bilo jako teko oporavljati u sluajevima havarija.

20

@ViPserbia

Na kraju moemo rei za hijerahijski tip baze podataka : - sastoji se od slogova koji su povezani (link), - veze mogu biti jednostruke i dvostruke i poveznice imaju svoj kraj, - kako smo ve pomenuli govori se o relaciji "roditelj-dete", Ove baze funkcioniu na osnovu hardverskih adresa zapisa (slogova) tako da se u poveznicama (link) nalazila fizika adresa sloga odnosno relativna adresa u odnosu na prvi slog u setu. ICL (International Computer Limited) se pojavio sa specijalnim hardverom (ugraeni mikroprocesori u glave za pisanje/itanje na diskovima za brzo pretraivanje fizikih adresa podataka. Matematiki opisano, hijerarhijski model podataka je baziran na skupu sa strukturom "drveta". Pri tome, "drvo" je takva struktura u kojoj je slog tako definisan da je pored korisnikovih podataka obavezno sadrao i dva dodatna elementa (polja): - koren (root) odnosno slog sadri polje "gospodar" (master field), - klju za pristup (key field) koji identifikuje vrstu, lokaciju i/ili redosled slogova u subordinaciji, - svaki slog ima samo JEDNOG roditelja a svaki roditelj moe da ima jedno ili vie dece, - prednost ovakve organizacije: brzina i efikasnost za odreene aplikacije hijerarhijski orijentisane, - problem: kako je organizacija podataka unapred definisana mora se svaka relacija eksplicitno kreirati u bazi podataka, - hijerarhijska organizacija je podskup mrene organizacije baze podataka Mrene strukture podataka Ono to je posebno znaajno kod ove strukture je da svaki elemenat skupa moe imati vie direktnih prethodnika i vie direktnih sledbenika Mreni model podataka se zasniva na mrei podataka koji su tako povezani da ne postoje ni nadreeni niti podreeni segmenti baze. Ovakva struktura je mnogo sloenija u odnosu na hijerarhijsku strukturu. Mrena struktura se moe dobiti i odgovarajuom kombinacijom hijerarhijkih struktura. Pored toga ona znaajno smanjuje dupliranje nekih podataka u odnosu na hijerarhijsku strukturu i znaajno smanjuje vreme potrebno za pronalaenje nekih podataka. Hijerarhijska i mrena struktura podataka mogu zadovoljiti kada su veze izmeu podataka malobrojne ili pak jednostavne. Meutim u sluajevima sloenijih

21

@ViPserbia

veza predstavljanje meusobnih odnosa takvim strukturama postaje veoma oteano. U tom sluaju se koriste takozvane relacione strukture odnosno modeli podataka. Relacioni model podataka 1970. godine E.F. Kod (E.F.Codd - u to vreme je bio lan IBM-ove istraivake laboratorije u San Hozeu (San Hose, California) je publikovao sada ve klasini rad "A Relational model of Data for Large Shared Data Banks" Relacioni model podataka za velike distribuirane baze podataka. Pojava relacionog modela je bila uslovljena dobro poznatim negativnim karakteristikama hijerarhijskog i mrenog modela. U delu koji se odnosi na objekte, relacioni model je relativno siromaan jer raspolae objektima relacija, atribut, kandidat za klju, primarni klju i strani klju. Veze izmeu relacija se uspostavljaju na osnovu stranih kljueva ili uvoenjem asocijativnih relacija. Najznaajnija ogranienja relacionog modela su ogranienja integriteta entiteta i ogranienja referencijalnog integriteta. U nekim realizacijama SUBP-a definie se odreeni skup integriteta atributa (na domen, na opseg vrednosti i slino). Uopteno relacioni sistem se moe opisati kao grupa slobodno povezanih struktura podataka koje zajedno daju potrebne informacije o nekom subjektu. Naime u veini sluajeva je besvrsishodno drati ba sve informacije o nekom subjektu u jednoj datoteci ili tabeli ili zapisu. Ove informacije se grupiu u odreene logike celine i smetaju u posebne datoteke ili tabele, a relacije se koriste za povezivanje ovih srodnih grupa podataka. Poseban problem je pitanje ouvanja referencijalnog integriteta. On se u mnogim SUBP-ima razreava na nivou samog aplikativnog koda. Ukoliko je i ugraen, tada se troe veliki sistemski resursi za njegovo ouvanje pa ga je potrebno veoma paljivo i umereno koristiti. Najmoniji deo relacionog modela su operatori koji se baziraju na relacionoj algebri od kojih su svakako najvaniji restrikcija, projekcija i spajanje. Odmah nakon prvih naunih radova o relacionom modelu krenulo se u realizaciju relacionih jezika koji su trebali u konkretnoj sintaksnoj formi realizovati neke ili pak sve relacione operatore. Jedan od prvih je emberlenov (D.D. Chamberlin) SEQUL (Structured English Query Language) koji je kroz razradu IBMovog Sistema R uoblien u SOL struktuirani jezik za upite. Mada je relaciono kompletan on ima nedostatak ortogonalnosti. Isto tako, Kod navodi da i promovisani ANSI standard (1986) vie titi postojee implementacije ovog jezika nego to predstavlja zaista solidnu osnovu za budunost. SOL je jezik za definisanje, manipulisanje i kontrolu podataka u relacionoj bazi. Zbog njegovih osobina mnogi ga proizvodai dopunjuju svojim operatorima. Loe karakteristike SOL-a u radu sa ekranskim formama i izvetajima se nadopunjuju22

@ViPserbia

njegovim ekstenzijama u tim pravcima, to opet dovodi do daljeg odstupanja od standarda. Nimalo ne umanjujui pozitivne karakteristike relacionog modela, mora se rei da u prvim fazama primene nije predstavljao ba idealno sredstvo za fazu dizajna informacionog sistema jer je nametao obavezu stroge primene teorije normalizacije. Produkcione brzine relacionoh baza podataka su u prvim fazama razvoja relacionih baza bile znatno ispod brzine hijerarhijskih i mrenih. Ukoliko bi striktno primenjivali pravila za ocenu relacionog softvera tada bi u toj fazi razvoja njihov broj bio sveden na minimum dok su se ostali morali okarakterisati kao pseudorelacioni softveri. Kao to se relacioni model javio kao odgovor na nedostatke mrenog i hijerarhijskog modela tako se Entity Relationship model of data base entitet relaciona baza podataka je razvijena uvoenjem tzv. elementa relacije izmeu entiteta u bazi podataka. 1976 Peter Chen je na MIT- u je uveo pojam Entity-Relationship data model model podataka u kome postoje relacije izmeu entiteta. Neki autori nazivaju ovaj model i postrelacionim Taj model grafiki predstavlja osnovne karakteristike strukture aplikacije baze podataka. Ovakav nain predstavljanja podataka je veoma jednostavan, koncizan i gotovo da sam objanjava kakve su interakcije izmeu pojedinih entiteta baze. Prvobitna upotreba E-R modela podataka se svodila na fazu dizajniranja informacionog sistema zbog velikog broja koncepata koji poseduje. Svi koncepti relacionog modela (relacijom se u E-R modelu naziva tip entiteta) su i dalje zadrani ali je pridodat i skup novih. E-R model Kao to se relacioni model javio kao odgovor na nedostatke mrenog i hijerarhijskog modela, tako se enov (P.P.Chen) E-R model (Entity-Relationship Model) javio kao odgovor na nedostatke relacionog modela. Neki autori oval model nazivaju i postrelacionim. Prvobitna upotreba E-R modela podataka se svodila na fazu dizajniranja informacionog sistema, zbog velikog broja koncepata koji poseduje i, u to vreme, nepostojanja realizovanih operatora u nekom od SUBP-a. Svi koncepti relacionog modela (relacija se u E-R modelu zove tip entiteta) su i dalje zadani i pridodat im je skup novih: Slab tip entiteta - tip objekta koji je identifikaciono i/ili egzistencijalno zavisan od drugog tipa objekta pri emu ta zavisnost moe biti i zavisnost prethoenja. Tip veze - Objekat preko koga se uspostavlja veza izmeu tipova entiteta. Ukoliko se radi o vezi izmeu pojava jednog tipa entiteta tada govorimo o refleksivnoj vezi. Meoviti tip objekta (agregacija) - objekat preko koga se uspostavlja veza izmeu tipova entiteta, pri emu se on dalje moe povezivati sa drugim tipovima entiteta preko veza23

@ViPserbia

Uloga - Predstavlja ulogu koju objekat ima u vezi. Ukoliko se za navedenu ulogu ne postavi neki uslov tada govorimo o sinonimu. Generalizacija ili specijalizacija je koncept kojim se realizuje odnos podtipova i nadtipova objekata pri emu vai pravilo nasleivanja osobina (atributa) od nadtipa ka podtipovima, Kardinalnost - Koncept koji predstavlja ogranienje na osnovu minimalnog i maksimalnog broja veza jednog tipa entiteta sa drugim u konkretnoj vezi. Ovako definisan skup objekata ukazuje da se radi o semantiki bogatom modelu podataka koji je upravo zbog toga naao visok stepen upotrebe. Ukoliko se u fazi dizajna potuje mali skup neophodnih pravila, model podataka e bitl u 3NF ili u BCNF. 2.2 Dodatna definisanja nad podacima Logike strukture obeleja Kada se u skup obeleja jedne klase entiteta uvede relacija strogog poretka tako da svako obeleje moe imati najvie jednog neposrednog prethodnika i najvie jednog neposrednog sledbenika, dobija se linearna struktura obeleja. Ta linearna struktura obeleja naziva se tipom sloga. Uvoenjem relacija u skup slogova razliitog tipa ponovo se dobija logika struktura obeleja. Logika struktura obeleja definisana nad skupom slogova razliitog tipa, karakteristina je za baze podataka. Logike strukture obeleja baza podataka mogu biti linearne, hijerarhijske, mrene ili relacione. Tip sloga predstavlja logiku strukturu obeleja datoteke. Datoteci najee odgovara linearna logika struktura obeleja definisana nad skupom elementarnih obeleja. Svakom tipu sloga, kao linearnoj strukturi obeleja, odgovara skup pojava sloga. Svaka pojava sloga predstavlja jednu linearnu strukturu podataka. Ureenje podataka u pojavi sloga definisano je ureenjem obeleja u tipu sloga. Kada se u skup pojava, sloga jednog tipa, uvede relacija strogog poretka dobija se logika struktura podataka datoteke. Logika struktura podataka datoteke je najee linearna, a dobija se ureivanjem pojava sloga jednog tipa saglasno rastuim ili opadajuim vrednostima kljua. Logike strukture podataka u bazama podataka se definiu uvoenjem relacija u skup pojava slogova razliitog tipa. Pored relacija izmeu pojava slogova razliitog tipa, koje diktira logika struktura slogova razliitog tipa, skup pojava slogova snabdevaju i relacije izmeu pojava sloga.

24

@ViPserbia

Poto logika struktura obeleja ne poseduje informaciju o ureenju pojava sloga jednog tipa bez obzira na broj pojava sloga, jednoj logikoj strukturi obeleja odgovara vei broj logikih struktura podataka. Meutim, preslikavanje logike strukture podataka na logiku strukturu obeleja je jednoznano. Definisanje fizike strukture podataka Kada se podaci i veze logike strukture podataka smeste na magnetni medij nekog memorijskog ureaja (traka, disketa, disk, CD), dobija se fizika struktura podataka. Pri tome se, za predstavljanje podataka, umesto prirodne koristi binarna azbuka. Pored podataka, koje sadri logika struktura podataka, fizika struktura podataka se proiruje i podacima, svojstvenim postupcima memorisanja na konkretnom mediju, podacima koji opisuju odreene osobine pojava slogova (na primer: duina pojave sloga izraena brojem znakova prirodne azbuke, pripadnost tipu sloga i slino). Takoe, postoje razliiti postupci za predstavljanje veza logike strukture podataka, Istoj logikoj strukturi podataka moe odgovarati vie fizikih struktura podataka, ali je preslikavanje fizike na logiku strukturu podataka jednoznano. Podaci i veze logike strukture podataka, smeteni na medij memorijskog ureaja i proireni nizom elemenata svojstvenih postupcima za memorisanje podataka i veza na konkretnom ureaju, predstavljaju fiziku strukturu podataka. Smetanje podataka i veza u lokacije na memorijskom mediju predstavlja zadatak operativnog sistema, odnosno njegovog dela koji se naziva sistemom za upravljanje podacima. U cilju poveanja efikasnosti kasnije obrade podataka, sistem za upravljanje podacima snabdeva fiziku strukturu podataka nizom dodatnih podataka. Specifinosti smetanja podataka u lokacije na memorijskom prostoru i dodatni podaci su takoe elementi fizikih struktura podataka. Definisanje formata sloga Za predstavljanje pojave sloga S, kao elementa fizike strukture podataka, koristi se takozvana linearna struktura prema datoj slici 2.7. Struktura na slici predstavlja opti oblik formata sloga gde k(S) predstavlja vrednost kljua, p(S) konkretizaciju nekljunih obeleja sloga, u(S) vrednost pokazivaa, a s(S) status sloga. Dok se k(S) i p(S) dobijaju preslikavanjem logike na fiziku strukturu podataka, u(S) i s(S) predstavljaju mogua proirenja sloga svojstvena fizikoj strukturi podataka.

25

@ViPserbia

k(S)

p(S)

u(S)

s(S)

Slika 2.7 Opti format sloga Naini memorisanja veza logike strukture podataka Veze (relacije) logike strukture podataka mogu se fiziki realizovati na vie naina. Tu su pre svega u pitanju fiziko pozicioniranje, pokazivai, adresar (directory-datoteka u kojoj su memorisane veze pojava sloga iz druge datoteke), dvodimenzionalne binarne matrice i drugo. Fiziko pozicioniranje predstavlja veoma efikasno sredstvo, za memorisanje linearnih struktura podataka. U fiziki susedne lokacije memorijskog prostora smetaju se logiki, susedni slogovi. Fizika susednost nosi informaciju o vezama logike strukture podataka. Fiziko pozicioniranje predstavlja jedinstven postupak kada se smetaju podaci jednog sloga na memorijski medij, a esto se koristi i za fiziku realizaciju linearnih struktura slogova. Za predstavljanje kompleksnih logikih struktura, u datotekama i bazama podataka najee se koriste pokazivai. Pokazivai se memoriu ili uz slog, kada predstavljaju integralni deo sloga, ili u posebnoj datoteci-adresaru. U oba sluaja obezbeuju informaciju o adresi (ili adresama) lokacija sa slogovima koji su u logikoj vezi sa posmatranim slogom. Ta informacija moe biti data kao mainska adresa, relativna adresa ili simbolika adresa, odnosno vrednost kljua. Pokazivai u obliku mainske adrese obezbeuju najbru obradu, ali imaju nedostatak da su veoma nefleksibilni u odnosu na promene fizike strukture podataka. Izmena ureaja ili rasporeda slogova na memorijskom medijumu zahteva i izmene pokazivaa. Pokazivai u obliku relativne adrese sadre redni broj lokacije dela memorijskog prostora dodeljenog datoteci. Pretvaranje relativne u mainsku adresu predstavlja zadatak jednog algoritma. Promene adrese u fizlkoj strukturi podataka dovode samo do izmene tog algoritma, ali ne i do izmene samih pokazivaa i1i aplikativnlh programa. Primena simbolikih adresa kao pokazivaa predstavlja veoma fleksibilno, ali relativno sporo reenje. Numeriki klju se transformie u adresu uz pomo neke formule. Nenumeriki klju se prvo mora pretvoriti u numeriki ili zahteva postojanje tabela sa parovima (klju, adresa).

26

@ViPserbia

Definisanje pojma bloka podataka Blokiranje predstavlja postupak grupisanja slogova pre upisivanja na medij eksternog memorijskog ureaja. Takva grupa odreenog broja slogova naziva se blokom. Blokiranje poboljava iskorienje memorijskog prostora i poveava efektivnu brzinu razmene podataka izmeu operativne i eksterne memorije. esto, blokiranje poveava i efikasnost obrade podataka, jer smanjuje broj ulazno-izlaznih operacija neophodnih za obradu datoteke. Blok sadri jedan ili vie slogova. Broj slogova u jednom bloku naziva se faktorom blokiranja. Faktor blokiranja f se definie u postupku projektovanja datoteke, a moe imati konstantnu ili promenljivu vrednost. Moe se vriti i kompresija podataka u slogu, izostavljanjem nepopunjenih pozicija u pojedinim poljima, dobijaju se slogovi promenljive duine. Kombinovanjem konstantnog i promenljivog faktora blokiranja sa slogovima konstantne i promenljive duine, dobijaju se etiri mogue vrste blokova. To su: - blokovi sa konstantnim faktorom blokiranja i konstantnom duinom slogova - blokovi sa konstantnim faktorom blokiranja i promenljivom duinom slogova - blokovi sa promenljivim faktoram blokiranja i konstantnom duinom slogova - blokovi sa promenljivim faktorom blokiranja i promenljivom duinom slogova. Prilikom razmene podataka izmeu operativne memorije i eksterne memorije, u operativnu memoriju se uvek prenosi ceo blok. Ova injenica ograniava veliinu bloka, odnosno, namee potrebu da se pri izboru veliine bloka vodi rauna o zauzeu operativne memorije. Pojam bloka se odnosi na niz od N sukcesivnih slogova smetenih na nekoj lokaciji na memorijskom mediju. Ta lokacija se sastoji od N podlokacija. Poto, po definiciji, svaka podlokacija predstavlja lokaciju, u nastavku e se za lokaciju sa N podlokacija koristiti naziv fiziki blok, a za podlokacije e se koristiti naziv lokacije. Fiziki blok poseduje adresu na memorijskom prostoru. Ta adresa moe biti mainska ili relativna. Kada je re o jedinici magnetnog diska, mainska adresa moe imati oblik (C,T,S), gde je C broj cilindara T broj staze - traga na cilindru, a S broj sektora na stazi. Kada je re o jedinici magnetne trake, adresa se moe shvatiti kao redni broj fizikog bloka od poetka medija, mada se bloku na traci nikad ne pristupa na osnovu adrese. Relativna adresa predstavlja redni broj fizikog bloka od poetka memorijskog prostora dodeljenog datoteci. Upisivanje podataka na magnetni disk Upisivanje blokova na magnetni disk se moe vriti uz pomo jednog od dva meusobno razliita postupka. To su takozvani sektorski i programabilni postupak.27

@ViPserbia

Kod sektorskog postupka sve staze na aktivnim povrinama ploe diska su podeljene na odreeni broj sektora. Broj sektora varira od ureaja do ureaja. Obino predstavlja neki stepen broja 2, koji jc vei od 1, a moe biti manji ili jednak 128. Blokovi sa jednim ili vie slogova memoriu se tako to se nakon poetka sektora ostavi jedan mali meusektorski razmak, a zatim se upisuje blok na stazu. Ukoliko je blok dui od kapaciteta soktora, njegovo se momorisanje nastavlja u narednim scktorima, ali se nakon svakog poetka sektora ostavlja mali razmak. Svaki novi blok se poinje memorisati od meusektorskog razmaka novog sektora. Ukoliko se za memorisanje jednog bloka upotrebi samo deo nekog sektora, ostatak sektora ostaje prazan. Na slici 2.8 je prikazan upis podataka na magnetni disk. U sluaju promenljivog faktora blokiranja ili slogova promenljive duine, kod primene sektorskog postupka upisa podataka na disk koriste se rei za opis bloka i rei za opis sloga. Naziv programabilan potie od injenice da se razmaci, izmeu fizikih blokova sa podacima, generiu programskim putem, kao i od injenice da se uz svaki blok memoriu informacije o njegovom sadraju. O memorisanju razmaka i dodatnih informacija brine operativni sistem. Traenje bloka na stazi moe se vriti ili uz pomo adrese, odnosno rednog broja bloka, u kojem se slog nalazi ili uz pomo vrednosti argumenta traenja. Ako se traenje vri na osnovu adrese, u operativnu memoriju se prenosi samo sadraj lokacije svakog bloka. Tek kada se adresa bloka u lokaciji pokae jcdnakom adresi traenog bloka, u operativnu memoriju se prenosi i sadraj date lokacije.N TRAG STAZA n TRAG STAZA SEKTOR MEUSEKTORSKI RAZMAK 0 TRAG - STAZA SEKTOR

Slika 2.8 Upis podataka na magnetni disk

28

@ViPserbia

Ako se traenje vri na osnovu vrednosti argumenta traenja, u operativnu memoriju se prenosi sadraj kljua date lokacije. Ukoliko je vrednost argumenta traenja vea od vrednosti kljua u datoj lokaciji, uitava se sadraj lokacije narednog bloka. Tek kada vrednost argumenta traenja postane manja ili jednaka sadraju kljua date lokacije, u operativnu memoriju se prenosi i odgovarajui sadraj podruja podataka, jer se traeni slog moe nalaziti samo u tom bloku. Fizika organizacija baze podataka Performanse baze se uglavnom mere vremenom odziva na upite ili, to je uobiajeno kod viekorisnikih SUBP, brojem uspeno zavrenih transakcija u jedinici vremena. Najvaniji faktor koji utie na performanse je fizika organizacija baze. S druge strane, relacione baze i relacioni model podataka u celini su poznati po tome to su kod njih (relativno) uspeno razdvojeni logiki koncepti (i strukture podataka) od fizikih. Uprkos tome, pitanje fizike organizacije (i performansi) i kod njih je veoma bitno, moda i u veoj meri nego kod baza zasnovanih na drugim modelima podataka, za koje se ionako smatra da postiu bolje performanse. Definisanje baze u nekim SUBP Moda e izgledati udno zato se ovde bavimo definisanjem baze, kad je o tome ve ranije neto reeno. U poetnom delu, meutim, namerno su preskoene sve naredbe koje se odnose na fiziku organizaciju podataka. Sada emo se vratiti na te naredbe (DEFINE DATABASE, odnosno CREATE SCHEMA) i ukratko emo pokazati ta se sve moe specificirati prilikom definisanja baze. Pre svega, pojedini SUBP daju mogunost projektantu da svoju bazu dri u jednoj ili vie datoteka, koje se mogu nalaziti na razliitim fizikim jedinicama eksterne memorije (najee su to diskovi). Osnovni razlozi za deljenje baze na vie fizikih datoteka su dvojaki: prvo, na taj nain se poveava raspoloivi prostor za smetaj baze, i drugo, poboljavaju se performanse sistema, jer se ulazno-izlazne operacije kojima se pristupa bazi raspodeljuju na razliite diskove i disk kontrolere, pa je vreme ekanja krae. Prilikom definisanja baze, mogu se naprimer zadati sledei parametri fizike organizacije: . lokacija (ALLOCATION) i prostor rezervisan za bazu (EXTENT), kao i veliina stranice u blokovima (PAGE SIZE); . dozvoljeni prostor za irenje baze (za koji se navode MINIMUM i MAXIMUM broj stranica, kao i PERCENT GROWTH);29

@ViPserbia

. lokacija (SNAPSHOT snimak, ALLOCATION) i veliina datoteke snimka (SNAPSHOT EXTENT); . broj i veliina bafera za privremeno uvanje podataka (BUFFER SIZE, NUMBER OF BUFFERS); . najvei broj korisnika koji e istovremeno pristupati bazi. Ukoliko korisnik koji kreira bazu ne definie drugaije, ovi e parametri dobiti neke podrazumevane (default) vrednosti (za male i srednje baze vrednosti tih parametara uglavnom su zadovoljavajue). Ako i kada se ukae potreba, naredbom CHANGE DATABASE mogu se promeniti vrednosti nekih od pomenutih parametara, pa i nekih drugih, kao to je aktiviranje dnevnika zavrenih transakcija. Takoe se moe deaktivirati datoteka snimka, ime se dobija reijsko vreme potrebno za njeno auriranje, ali se istovremeno i poveava mogunost konflikta zakljuavanja pri viekorisnikom radu, jer e tada sve transakcije itati svoje podatke neposredno iz baze. Koje je reenje bolje, najbolje je utvrditi eksperimentalno. Ukoliko se radi o bazi sa vie desetina relacija i sa ukupnom koliinom podataka koja prelazi desetak megabajta, korisno je razmotriti mogunosti i prednosti definisanja baze sa vie fizikih datoteka (multifile database). Naprimer ako je u pitanju Rdb baza, za takvu bazu je potrebno prilikom definisanja, definisati jednu ili vie zona smetanja, storage areas, ime se kreiraju osnovna datoteka tipa .RDB, koja sadri podatke o strukturi i lokaciji podataka kao i posebne datoteke tipa .RDA, koje sadre samo podatke. Za multifile bazu potrebno je da se prilikom definisanja baze definie bar jedna zona smetaja, a kasnije naredbom CHANGE DATABASE odnosno ALTER SCHEMA (SQL), mogu se definisati i druge. Ukoliko je baza definisana kao single-file, naredba CHANGE DATABASE, odnosno ALTER SCHEMA, se ne mogu iskoristiti da se baza prevede u multifile bazu; za to se moraju koristiti naredbe EXPORT i IMPORT. Zona smetanja se naprimer definie iskazom DEFINE/CREATE STORAGE AREA, unutar naredbe DEFINE DATABASE (RDO), ili CREATE SCHEMA (SQL). Svaka zona smetanja dobija poseban naziv, koji se kasnije moe iskoristiti za definisanje fizikog smetanja pojedinih relacija/tabela i indeksa. Ovim se iskazom mogu odrediti veliine sledeih parametara: - nazivi, lokacije i veliine datoteka u kojima e biti smeteni delovi baze (FILENAME, ALLOCATION, EXTENT); - veliina stranica i nain popunjavanja stranica (PAGE SIZE, PAGE FORMAT), koji moe biti UNIFORM (ako stranice sadre podatke iz samo jedne relacije) ili MIXED (ako stranice mogu da sadre podatke iz vie od jedne relacije) ;30

@ViPserbia

- granine vrednosti popunjenosti za stranice iji je format definisan kao MIXED (THRESHOLDS); - parametre datoteke snimka koja odgovara .RDA datoteci, poto svaka datoteka u multifile bazi moe da poseduje sopstvenu datoteku snimka. Da bi se odredilo kako e relacije/tabele biti raspodeljene po fizikim datotekama, potrebno je izdati naredbu DEFINE/CREATE STORAGE MAP. Ovom naredbom se za svaku relaciju navodi naziv jedne ili vie zona gde e biti smetena, pri emu se moe zahtevati smetanje prema vrednostima podataka u jednoj ili vie kolona, ili smetanje u skladu sa jednim od indeksa definisanim nad dotinom relacijom/tabelom (naravno, naziv indeksa se mora navesti). Na ovaj nain projektant baze moe da optimizira fiziki raspored podataka, prilagoavajui ga najee korienim pristupnim putevima, tj. najee korienim upitima. Treba imati u vidu da se algoritam smetanja prema vrednostima polja/kolona koristi samo pri smetanju podataka naredbama STORE (RDO), ili INSERT (SQL); n-torke u kojima su vrednosti kasnije promenjene naredbama MODIFY ili UPDATE, nee biti premetene. Najzad, naredbom CREATE STORAGE MAP moe se zahtevati da se podaci iz neke relacije uvaju na disku u komprimovanom (ifrovanom) obliku. Na taj nain se, u prvom redu, tedi prostor na disku, a smanjuje se i mogunost da neko neovlaeno lice proita podatke gledajui sadraj datoteke na disku, meutim poveava se rad samog procesora, koji mora da izvri dekompresiju podataka pre korienja, odnosno kompresiju podataka pre no to se smeste na disk. Naredba DEFINE/CREATE STORAGE MAP moe se koristiti samo dok je relacija/tabela o kojoj se radi prazna, inae e SUBP javiti greku. Najbolje je koristiti ovu naredbu odmah po definisanju odgovarajue relacije, dok u nju jo nisu uneti podaci.

31

@ViPserbia

3. RELACIONE BAZE PODATAKAIstorijski gledano, kako je ve pomenuto u uvodnom delu, tokom 60-tih i 70-tih godina implementirani su prvi softveri za rukovanje (upravljanje) bazama podataka, koje su bile zasnovane na hijerarhijskim i mrenim modelima podataka i kada su se koristile takozvane flat datoteke. U praksi se pokazalo da je ovakva organizacija podataka bila nefleksibilna zbog toga to su strukture podataka bile veoma stroge i bilo je mnogo tekoa da se sa aplikativnim programima izvravaju rutinske obrade. Kasnih 70-ih godina se pojavio relacioni model podataka koga su u poetku koristili istraivai u akademskim krugovima, a kasnije je bio primenjen i za komercijalne svrhe u proizvodima DB2 i Oracle. Oracle je u stvari bio prva kompanija koja je implementirala ANSI SQL standarde i na taj nain stekla kompetitivnu prednost na svetskom tritu. Kasnije su se pojavili i drugi kao Sybase, MS SQL Server i Access. Relacioni model podataka operie sa podacima izmeu kojih postoje odgovarajue relacije tako da se govori da izmeu tabela sa podacima postoji relaciona veza. Fizika implementacija relacionog modela podataka je u osnovi zasnovana na primeni tabela. Svaka tabela se sastoji od odgovarajueg broja kolona koje se nazivaju polja - fields. Podaci smeteni u istoj koloni moraju biti istog tipa podataka kao to su znak - character, broj - number ili datum - date. Red - row u tabeli ili skup vrednosti svih kolona tabele u jednom istom redu se naziva slog - record. Razliite tabele mogu imati razliiti broj kolona. Ova osobina se koristi da se eksplicitno navede relacija izmeu dve tabele. Vrednosti koje se pojavljuju u koloni A tabele X mogu se deliti od strane druge tabele Y. Potrebno je da korisnik Accessa kao i drugih softvera za upravljanje bazama podataka upozna osnovnu metodologiju dizajna - projektovanja baza podataka, koja je u osnovi veoma slina, pri emu se polazi od definisanja i izrade osnovnih elemenata baze, a ozbiljnije razlike izmeu pojedinih SUBP se javljaju u mogunostima i kapacitetima baze kao i u raspoloivim razvojnim alatima. Radi jednostavnije ilustracije u nastavku su data dva primera tabela u relacionoj bazi podataka na primeru jedne male banke.

32

@ViPserbia

Tabela klijenata: KLIJENTI TableKlijentID Number Ime_i_Prezime Character Adresa Character Vase Stajia 3 Mesto Drzava Post_Broj Character Character Character Novi Sad SCG SCG SCG SCG 21000 23000 11000 24000

1001 Jovan Jovanovi 1002 Petar Petrovi

Stevana Sremca 23 Zrenjanin Beograd Subotica Petefi andora 3

1003 ore Arsenijevi Humska 23 1004 Ana Bodor

Tabela rauna: RACUNI TableKlijentID Number 1001 1001 1002 1003 1003 1004 1004 Broj_Racuna Number 9987 9980 8811 4422 4433 3322 1122 Vrsta_Stednje Dat_Otvaranja Character ekovi trednja tednja ekovi ekovi tednja ekovi Date 10/12/1999 10/12/1999 01/05/1992 12/01/1999 12/01/1999 08/22/1999 11/13/1998 Saldo Number 4000.00 2000.00 1000.00 6000.00 9000.00 500.00 800.00

Tabela "Klijenti" ima 6 kolona (KlijentID=identitet-ifra klijenta, Ime_i_Prezime, Adresa, Mesto, Drzava i Post_Broj) i 4 reda (ili sloga) sa podacima. Tabela "Racuni" ima 5 kolona (KlijentID, Broj_Racuna, Vrsta_Stednje, Dat_Otvaranja i Saldo) sa 7 redova podataka. Svaka od ovih kolona zadovoljava jedan od tri tipa podataka. Tip podataka jedne kolone oznaen je i vrednou podatka koji se moe smestiti u takvu kolonu. Number - mogu se smetati samo brojevi (celi i decimalni) Character - mogu se smetati brojevi, slova, znakovi punktuacije (u Access-u se ovakav tip podataka naziva tekst) Date - mogu se smetati samo podaci oblika datuma i vremena . Kod nekih baza podataka implementirane su druge vrste tipova podataka kao naprimer bit-mape slika (Images), ali ovi i napred navedeni su najtipiniji u upotrebi.33

@ViPserbia

Treba zapaziti da ove dve tabele dele istu kolonu "KlijentiID" tako da pojave ove kolone imaju iste vrednosti i u jednoj i u drugoj tabeli. To znai da postoji relacija koja dozvoljava da klijent pod imenom Jovan Jovanovi ima tekui raun sa ekovima (ekovi) i raun za tednju (tednja), a da su oba otvorena istoga dana: 1. XII 1999. Za ovakve relacije koristi se i specijalno ime relacije pod nazivom "sastavnice" (Master/Detail). U relacijama tipa sastavnica, jedan slog iz matine datoteke (kao npr. klijent sa ifrom KlijentID= 1001 odnosno imenom Ime_i_Prezime=Jovan Jovanovi) moe imati vie slogova u datoteci sa detaljima (u ovom sluaju su to dva rauna) dodeljena jednom slogu iz glavne matine datoteke - tabele. Mogue je da u ovakvim relacijama tipa "sastavnica" postoji slog u matinoj tabeli, a da taj slog nema detalje. Meutim, nemogue je da se pojavi slog u datoteci "detalji" koji nema odgovarajuu relaciju sa matinom datotekom. Na primer, moete imati klijente u tabeli "Klijent" a da nemate nikakve informacije o raunima takvog klijenta. Medjutim, bilo kakva informacija o raunu MORA biti asocirana jednom klijentu u tabeli "Klijent"- klijenata. U svrhu obezbeenja egzistencije relacija izmeu tabela, svaka tabela MORA imati i jednu kolonu koja se naziva "Klju" (indeks tabele, key) koja se koristi kao jedinstveni (unikatni) identifikator reda odnosno sloga u tabelama. U navedenim tabelama kolona-klju se nikada ne moe duplicirati. U primeru datom primeru to je kolona "KlijentID" za tabelu "Klijent" odnosno kolona "Broj_Racuna" je klju za tabelu "Racuni". Kako smo ranije napomenuli relacione baze podataka svoje funkcionisanje zasnivaju na teoriji relacione algebre. Ova algebra se sastoji od formalnih struktura kao to su skupovi i operatori nad skupovima. Relaciona algebra je formalni sistem za manipulaciju sa relacijama: Operandi ove algebre su relacije Operacije ove algebre ukljuuju uobiajeni skup operacija (jer i same relacije su skupovi n-torki) a osnovne operacije su: o selekcija (selection) o projekcija (projection) o sastavnica (join) Za skup operacija nad relacijama, svi operandi moraju imati istu emu, a rezultat mora takoe imati istu emu.

34

@ViPserbia

R1 U R2 (unija skupa R1 i R2) je relacija koja sadri sve n-torke koje se nalaze i u skupu R1 i u skupu R2 R1 R2 (presek skupa R1 i R2) je relacija koja sadri sve n-torke koje se pojavljuju samo u R1 i R2 skupovima. R1 - R2 (razlika skupova R1 i R2) je relacija koja sadri sve n-torke skupa R1, a koje nisu sadrane u skupu R2 Selekcija

Selekcija n-torke iz relacije R1 iji atributi zadovoljavaju kriterijum koji se izraava preko predikata P se moe iskazati kao: R2 = select(R1,P) To znai da se iz skupa R1 kreira nova relacija R2 koja sadri sve one n-torke iz R1 koji zadovoljavaju (iskaz je istinit) kriterijum (predikat) P. Predikat moe biti bilo koji Bool-ov izraz: "manje od" , "jednako ili vee od" >=, "jednako ili manje od" =