@ViPserbia
@ViPserbia production BAZE PODATAKA
-KNJIGA-
@ViPserbia
Sadrţaj 1.
2.
3.
4.
5.
Uvod
5
1.1. Pojam baze
9
1.2. Istorijat baza
10
1.3. Neke od većih baza podataka
10
1.4. Neke od manjih baza podataka
11
Modeli – strukture podataka
14
2.1. Osnovne strukture podataka
14
2.2. Dodatna definisanja nad podacima
24
2.3. Definisanje baze
29
Relacione baze podataka
32
3.1. Programsko okruženje za upravljanje podacima
41
3.2. Projektovanje aplikativnih rešenja primenom relacionih baza
44
3.3. Projektovanje baze podataka
45
3.4. Projektovanje relacione baza podataka
46
3.5. Izrada dijagrama procesa
49
3.6. Izrada dijagrama funkcija
50
3.7. Izrada dijagrama toka podataka
52
3.8. Izrada matričnih dijagrama
53
3.9. Izrada dijagrama entiteta i relacija
54
Elementi relacione baze podataka
58
4.1. Tabele – Tables
60
4.2. Formulari – Forms
61
4.3. Upiti – Queries
63
4.4. Izveštaji – Reports
64
4.5. Spajanje relacija – spajanje tabela
65
4. 6. Ažuriranje – unos, ispravka, dodavanje
67
4. 7. Indeksi
68
4. 8. Ključevi
69
4. 9. Pretraživanja, sortiranja, selekcija
70
4.10. Makroi i primena VBA
70
Primena Microsoft Accessa u razvoju baze podataka
72
5.1. Uvodne informacije - uputstva
74
5.2. Primer razvoja aplikacije (poslovna praksa)
75
5.3. Pokretanje rada MS Accessa
76
5.4. Izrada tabela
76 2
@ViPserbia
5.4.1. Izrada tabela primenom »Design View«
83
5.4.2. Pregledanje i dodavanje podataka u tabelu
88
5.4.3. Izrada relacija izmeĎu tabela
91
5.5
97
Izrada i izvoĎenje upita
5.5.1. Upiti nad jednom tabelom 5.5.2. Upiti nad više tabela
105
5.6.
Izrada forme za obuhvat podataka
110
5.6.1. Izrada forme nad jednom tabelom
110
Izrada i realizacija izveštaja
116
5.7.1. Izrada izveštaja nad jednom tabelom
116
5.7. 5.8.
6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
97
Microsoft Access 2000 – dodatne mogućnosti
125
5.8.1. Switch board manager
125
5.8.2. Look Up – Combo box
141
5.8.3. Upotreba alata Expression builder
146
5.9.
151
Upotreba Makroa
5.10. Primena VBA – Visual Basic for Applications
164
5.11. Pravljenje poštanskih nalepnica
152
5.12. Specifikacije za baze podataka u Microsoft Accessu
168
Rukovanje bazama podataka
171
Distribuirane baze podataka.
173
Rad u mreţi
177
Bezbednost baze
185
Zaštita integriteta baze
189
Nadzor nad radom baze
196
Kuda dalje
197
Prilog 1 – Primer Informacionog sistema biblioteke F@M-a
198
Prilog 2 – Primer baze podataka za Osnovnu školu Jovan Popović
212
Posebni izrazi koji se često koriste u bazama podataka
221
Literatura
225
3
@ViPserbia
Baze podataka 1. Uvod Savremeni informacioni sistemi se sve češće pored opreme, mreţnih resursa i ljudskog potencijala baziraju i na skupovima informacija, koji se najčešće nazivaju bazom podataka i skupovima programskih modula koji omogućavaju pristup tim podacima. Ovi skupovi programskih modula se najčešće nazivaju sistemi za upravljanje bazom podataka ili skraćeno SUBP. Pri tome je osnovna namena SUBP da omogući svim korisnicima jednostavan i efikasan pristup podacima, što je veoma sloţen zadatak, koji često zahteva veoma kompleksan softverski sistem, te ne treba da čudi što je oblast baza podataka i informacionih sistema poslednjih godina doţivela buran razvoj, kako u teorijskom, tako i u praktičnom smislu. Ako se pogleda dosadašnji razvoj sistema za upravljanje bazama podataka (SUBP) slobodno se moţe reći da je tekao spiralnim tokom. Svaki novi ciklus je počinjao naučno istraţivačkim radom koji se obično konkretizovao u odreĎene metodologije. Nakon toga je sledila faza realizacije SUBP-a i njegova eksploatacija. Faza eksploatacije je otkrivala i negativne karakteristike koncepta i načina njegove realizacije što je opet uslovljavalo pojavu sledećeg ciklusa u razvoju SUBP-a. Informacioni sistem predstavlja model realnog sistema, a proces prevoĎenja pojedinih koncepata realnog sistema u koncepte modela podataka naziva se projektovanje. Zbog toga je veoma bitno da je model podataka dovoljno semantički bogat da bi mogao, na relativno lak način prihvatiti, ali isto tako i u sebe uključiti različite koncepte realnog sistema. Svaki model podataka se sastoji od objekata, operatora nad tim objektima i ograničenja. Osnovna karakteristika svakog SUBP-a je model podataka na kome se on bazira. Kada se analizira odreĎeni SUBP analizira se, u stvari, model podataka i način njegove implementacije. Korišćenje odreĎenog modela podataka se susreće 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 ugraĎenom u SUBP. 5
@ViPserbia
Veoma je vaţno pitanje da li su to dva različita tipa modela podataka ili ne. Ukoliko se radi o istom tipu modela podataka tada se postavlja pitanje da li je on dovoljno semantički 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 različitim tipovima modela podataka tada postoji problem njihovih semantičkih razlika i načina prevoĎenja jednog modela u drugi. Ukoliko je semantička razlika značajna nije moguće izvršiti prevoĎenje semantički bogatijeg u semantički siromašniji model. Očigledno je da se korišćenje različitih modela podataka u različitim fazama razvoja softvera svodi na efekte i mogućnosti onog koji je siromašniji. Moderna obrada podataka se zasniva na dva osnovna koncepta: a) Na konceptu baze podataka kao jedinstvenog skladišta svih informacija potrebnih za opis jednog realnog sistema, iz koga onda svaki korisnik moţe da izvuče one informacije koje su mu potrebne, b) Na konceptu sistema za upravljanje bazom kao sloţenog softverskog proizvoda, čiji je cilj da korisniku omogući lako i brzo rukovanje potrebnim podacima, ne opterećujući ga pritom detaljima fizičke organizacije, zaštite, obezbeĎenja konkurentnosti i drugim sloţenim administrativnim poslovima. Najveći broj komercijalnih SUBP je zasnovan na hijerarhijskom, mreţnom, 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. Mreţni model se pojavio nešto kasnije u odnosu na hijerarhijski, dok je relacioni model nešto noviji u odnosu na njih - prvi ga je predloţio Codd 1970. godine. Poslednjih godina se počeo veoma intenzivno počeo primenjivati objektno orijentisani model. Prvi komercijalni relacioni SUBP pojavio se krajem sedamdesetih godina i od tada praktično kompletan razvoj SUBP i najveći broj novih realizacija koristi relacioni model podataka. Prvi eksperimentalni sistemi koji su koristili relacioni model konstruisani su u firmi IBM. Na trţištu je 80 –tih i 90- tih godina postojalo preko stotinu raznih relacionih SUBP. Vcćina njih su koristili strukturni upitni jezik SQL - Structured Query Language ili neku njegovu varijantu. U tom periodu veoma značajnu ulogu u svetu baza podataka je imao Rdb/VMS proizvod američke firme Digital Equipment Corporation, namenjen računarima tipa VAX i mikroVAX pod operativnim sistemom VMS i predstavljao je sloţen, ali veoma dobar sistem za upravljanje bazama podataka, koji je podrţavao sve osnovne operacije relacionog modela. 6
@ViPserbia
Pošto se radilo o proizvodu iste firme, koja je proizvodila i hardver i sistemski softver, bilo je realno očekivati dobre performanse. Uporedna merenja su pokazivala da je u to vreme Rdb/VMS bio najbrţa relaciona baza na VAX računarima. Sistem Rdb/VMS se sastojao od više komponenata, meĎu kojima su bili interpreteri RDO (Relational Database Operator) i VAX SQL, preprocesor za više programske jezike RDBPRE (Fortran, Cobol, Ada, BASIC) i RDML-Record Data Management Language (C i Pascal), odnosno SQLPRE (za upitni jezik SQL, i jezikedomaćine Fortran, Cobol, Pascal, C, PL/I), te usluţni program RMU (Record Management Utility), koji je olakšavao rad administratoru baze. Naravno, postojao je i sam sistem za upravljanje bazom u uţem smislu, koji se u literaturi na engleskom jeziku obično nazivao data base engine. Ovaj deo Rdb/VMS sistema je u izvesnom smislu predstavljao produţetak operativnog sistema, jer je sadrţavao 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 isporučivane zajedno sa ovim softverom, što je predstavljalo deo Digitalovih napora da se probije na trţištu informacionih softvera. Rdb/VMS je takoĎe zahtevao korišćenje Digitalovog integrisanog rečnika podataka, poznatog pod komercijalnim nazivom CDD (Common Data Dictionary). Korišćenje CDD rečnika je bilo neophodno pri definisanju strukture baze, a i kasnije, ukoliko su se koristili drugi softverski paketi, meĎu kojima su od poznatijih bili FMS-File Management System, TDMS- Transaction Data Management System, kao i DECforms, svi oni su bili namenjeni generisanju i korišćenju ekranskih formi za unošenje i/ili prikazivanje podataka, ACMS (Application Control and Management System), pomoću koga su se definisale višekorisničke aplikacije i upravljalo njihovim radom, kao i sistemi za upravljanje bazama podataka zasnovanim na drugačijim modelima (kao što je bio, recimo, DMS - Database Management system – Digitalov sistem za upravljanje bazom podataka u mreţi). CDD je predstavljao osnovno spremište struktura podataka, rečnik 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 označavao kao RDML, Relational Data Manipulation Language, a veoma često i sa RDO) moţe se reći da je bio relacioni, jer su se, praktično, sve naredbe za manipulisanje podacima mogle izdavati bilo u interaktivnom dijalogu, bilo ugraĎene u program pisan u nekom višem programskom jeziku treće generacije (jezik-domaćin), kakvi su bili COBOL, FORTRAN i slično. Tako napisani programi su se najpre obraĎivali preprocesorom za odgovarajući 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, isporučivao zajedno sa Rdb/VMS softverom, te je kupac imao na raspolaganju oba interfejsa i, shodno tome, imao mogućnost da bira.
8
@ViPserbia
Pojam baze podataka Pod bazom podataka se podrazumeva organizovan skup podataka koji se odnosi na slične pojmove ili predmete i skup programskih modula koji omogućavaju pristup tim podacima. Kako je već rečeno ovi moduli se nazivaju sistem za upravljanje bazom podataka, skraćeno SUBP. Naime dok se organizacija podataka u datoteke naziva klasičnim načinom organizovanja podataka, organizacija podataka u takozvanoj integrisanoj formi se naziva baza podataka. Podaci u bazi podataka mogu biti organizovani po više različitih obeleţja po kojima je kasnije primenom odgovarajućih mehanizama baze moguće vršiti pretraţivanja i nalaţenje baš onih podataka koji su potrebni. Rad sa bazom podataka se ne sastoji samo od definisanja strukture baze i pisanja upita za izveštavanje i aţuriranje, već postoje i neki poslovi koji se moraju obavljati periodično ili po potrebi: potrebno je dodeljivati prava pristupa pojedinim korisnicima baze, vršiti periodično kontrolu dodeljenih prava, a po potrebi, ukidati jednom dodeljena prava korisnicima koji više ne rade; u redovnim vremenskim intervalima treba proveravati integritet podataka u bazi; periodično se moraju vršiti radnje potrebne za eventualan oporavak u slučaju otkaza: arhiviranje baze na traku, rezervne diskove, CD/ove i aktiviranje dnevnika uspešno završenih transakcija; povremeno se moraju ispitivati performanse baze i po potrebi vršiti podešavanja fizičkih parametara, kako bi se vreme odziva smanjilo na najmanju moguću vrednost. Da bi se što efikasnije i uspešnije obavljali ovi i slični poslovi, baza mora da poseduje veći broj funkcija za upravljanje i administriranje bazom podataka. Upravo za izvršenje 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 logičke jedinice pristupa bazi, zaključavanjem i drugim mehanizmima, koji omogućavaju korektan i efikasan višekorisnički rad.
9
@ViPserbia
Istorijat baza podataka Baze podataka su se razvile kao logičan nastavak datoteka – file – podataka koje su veoma dugo korišćene u računarstvu, a i dan danas se koriste kao osnovne jedinice u koje se smeštaju podaci raznih tipova – tekstualni, tabele, slike i.t.d. Prve datoteke podataka su bile sekvencijalne – podaci su smeštani u nizu jedan za drugim, a i pretraţivanje podataka se odvijalo na isti način. Naime u početnim godinama primene računara podaci su bili smeštani na kartice – bušene 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 došlo do podatka, koji se nalazio na drugom kraju - strani trake ili kasete, bilo je neophodno premotati celu traku odnosno kasetu. Kasnije je došlo do razvoja ureĎaja kao što su disketa – floppi disc i diskova – hard disc, CD koji su omogućavali direktniji pristup podacima. U skladu sa tim novim mogućnostima korišćene su tzv. indeks-sekvencijalne i indeksne datoteke kod kojih je primenom indeksa i odgovarajućih ključeva bilo moguće daleko brţe pretraţivanje datoteka i nalaţenje potrebnih podataka. Neke od većih baza podataka Oracle Oracle je vodeći sistem za upravljanje bazama podataka, prenosiv, distributivan i otvoren, poseduje izvanredne mogućnosti i ima veoma visoke performanse, omogućava rad sa veoma velikim bazama podataka. On je u svetu najrasprostranjeniji DBMS – data base management system – sistem za rukovanje bazama podataka jer na najbolji način zadovoljava i zahteve današnjih najzahtevnijih informacionih sistema. On u sebi sadrţi podršku za najkompleksnije DSS – decision support systems – sisteme za podršku odlučivanju preko najrigoroznijih OLTP – on-line transaction processing aplikacija čak do aplikacija koje zahtevaju simultane DSS i OLTP pristupe do istih kritičnih podataka, pa do vodeće primene u industriji zahvaljujući dobrim performansama i mogućnostima koje Oracle pruţa korisnicima. Ono što je posebno vaţno kod primene Oracle-a je činjenica da on omogućava da korisnik moţe da integriše sve svoje računarske sisteme bez obzira pod kojim operativnim sistemom da rade UNIX, XENIX, VMS, OS-2, MVS, a pored toga omogućava meĎuoperativnost sa manjim bazama ili sa sličnim aplikativnim alatima. Pored toga veoma je značajna činjenica da Oracle ima razvijene brojne SQL alate i CASE- Computer Aided Software Engineering-softver inţinjering pomoću računara – alate koji omogućavaju korisnicima da na što lakši način mogu da rade pod Oracle-om. 10
@ViPserbia
Ingres Ingres je jedna od vodećih RDBMS – Relational Data Base Management Systems – sistema za upravljanje relacionim bazama podataka, koji je posebno pokazao svoje izvanredne mogućnosti primene pod UNIX operativnim sistemom. Ingres se koristi u mnogim oblastima. Pomenućemo samo neke kao što su trgovina, bolnice, farmacija, industrija, telekomunikacije, proizvodnja, inţenjerstvo, nauka, obrazovanje, seizmika itd. Ingres baze podataka se koriste na većini vaţnijih UNIX platformi od single-user – pojedinačnih korisnika na PC – personal computer – ličnim računarima do main frames – glavnih - centralnih računara u velikim računskim centrima. Od 1980. godine, kada je osnovana kompanija, Ingres je prilagoĎen i podešen 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 prihvaćen kao standard u današnjem komercijalnom okruţenju. Ingres se takoĎe veoma lepo i uspešno primenjuje kod VAX – VMS sistema, u klijent server arhitekturi, bez obzira da li lokalno ili preko mreţe. Informix Informix – Informiks je takoĎe jedna od vodećih 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 povećanje 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 brţe i jednostavnije nego sa drugim programskim jezicima. To je neproceduralan jezik koji omogućava korisniku da veoma lako moţe da kreira i najkompleksnije aplikacije. Pored toga i Informiks poseduje brojne pomoćne alate koji korisniku olakšavaju pretraţivanja kao i druge manipulacije sa podacima smeštenim u bazu. Nadalje Informiks nudi i svoje integrisano rešenje koje omogućava korisniku da brzo razvije ţeljeni sistem Neke od manjih baza podataka dBase Data Base ili skraćeno dBASE je verovatno najrasprostranjenija baza podataka koja se u svojim različitim varijantama od dBASE, pa preko dBASE II, dBASE III pa 11
@ViPserbia
zatim Clippera gotovo ušetala u većinu ličnih računara koje su korisnici širom sveta koristili u prvim fazama primene PC računara i baza podataka na njima, čak i u varijantama kada su PC računari povezivani u raznovrsne mreţe. Postepeno je izgubila dah u konkurenciji sa novodolazećim bazama i mogućnostima koje su one nudile. Ipak one će ostati u sećanju 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 okruţenju kao Visual Fox pro baza podataka. Ova baza podataka je pored dBASE verovatno baza podataka koja je godinama bila najprisutnija u PC okruţenju, a koja je i danas u svojoj Visual Fox pro varijanti najprisutnija baza podataka u PC računarima koju korisnici PC računara širom sveta koriste za svoje potrebe. Ova baza je na veoma pogodan način prilagoĎena Windows okruţenju i kao takva je uspela da prevaziĎe mnoge konkurentske baze tog nivoa. Visual Fox pro danas poseduje mnoge elemente koji omogućavaju korisniku da na brz i efikasan način moţe načiniti ţeljenu bazu i prateće ulazno-izlazne ekrane i izveštaje 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 našim 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 veće računarske sisteme bila veoma dobro prihvaćena 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 izmeĎu entiteta u bazi, koji je omogućavao otvoren pristup u razvoju aplikacija, povećavao produktivnost u razvoju aplikacija i obezbeĎivao jednostruko uniformno okruţenje u svim fazama razvoja aplikacija. Ono što je davalo posebnu prednost ovoj bazi podataka bila je činjenica da ste mogli i najsloţeniju 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 takoĎe jedna od baza podataka koja je veoma prisutna na našim prostorima. Kao i ZIM i ova baza je zahtevala relativno skromne hardverske resurse i imala mogućnost veoma lakog transportovanja sa jedne računarske 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 način bio olakšan prenos i instalacija jednom razvijenih programskih paketa – aplikacija na različite platforme koje su bile prisutne kod različitih korisnika. Ovo je takoĎe baza zasnovana na visokorazvijenom i potpuno proceduralom 4GL jeziku četvrte generacije, koja poseduje veoma veliku brzinu u radu, veoma veliku efikasnost, već pomenutu prenosivost, mogućnost veoma dobrog rada u raznim varijantama mreţa i pod različitim operativnim sistemima. Pored toga ova baza podataka obezbeĎuje 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 moţe posredno odreĎivati putem takvih kriterijuma kao što su: vreme potrebno da se pronaĎe traţeni podatak, memorijski prostor potreban za smeštaj strukture podataka (danas sve manje bitan) kompleksnost algoritama za formiranje, korišćenje i ažuriranje strukture podataka. Pošto se isti skup podataka moţe urediti na više načina, prilikom projektovanja se obično postavlja pitanje izbora strukture koja će omogućiti, efikasniju obradu. U operativnoj kao i u eksternim memorijama grade se, u principu, isti tipovi strukture podataka, ali se za njihovu izgradnju koriste različiti postupci. Za izgradnju strukture podataka u operativnoj memoriji, biraju se postupci koji dozvoljavaju efikasno korišćenje memorijskog prostora. Pri izgradnji struktura podataka na eksternim memorijama, osnovni cilj predstavlja minimizacija broja pristupa ureĎaju pri traţenju odreĎenog 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 dogaĎaja, kao što su uplata, ulaz robe, materijala - klasa raznih pojmova i pojava. Svaka klasa entiteta ima odreĎene osobine kao što su naziv, boja, vrednost, trajanje i slično. Ove osobine se nazivaju obeleţjima. Sa tačke gledišta zadataka informacionog sistema, nisu sva obeleţja klase entiteta jednako vaţna. Od obeleţja, bitnih za realizaciju zadataka informacionog sistema, gradi se odgovarajući model klase entiteta. Svakom od obeleţja odgovara jedan skup svih mogućih vrednosti koje to obeleţje, u konkretnim slučajevima, moţe imati. Obeleţje boja uzima vrednosti iz skupa {bela, ţuta, crna, plava, ...}. Obzirom da, u opštem slučaju, obeleţje uzima pojedine vrednosti iz datog skupa sa različitim verovatnoćama, obeleţje se moţe smatrati slučajnom veličinom. U
14
@ViPserbia
tom slučaju se vrednosti, koje obeleţje uzima, nazivaju njegovim konkretnim vrednostima. Postoje obeleţja, koje se dalje ne mogu dekomponovati i ona se nazivaju elementarnim obeleţjima. Naziv proizvoda, boja automobila, ime stanovnika, predstavljaju elementarna obeleţja različitih klasa entiteta. Sa druge strane ako imamo niz elementarnih obeleţja ili logički proizvod elementarnih obeleţja tada se kaţe da on predstavlja sloţeno obeleţje. Sloţena obeleţja predstavljaju na primer adresa stanovnika (mesto,ZIP kod, ulica, broj) Pri tome konkretizacija elementarnog obeleţja predstavlja elementarni podatak, a konkretizacija sloţenog obeleţja predstavlja sloţeni podatak. Ona obeleţja čije se vrednosti dobijaju primenom nekog algoritma na vrednosti drugih obeleţja nazivaju se izvedenim obeleţjem, a njihove vrednosti izvedenim podacima. (iznos je proizvod količine i cene i on predstavlja izvedeno obeleţje) Ona elementarna ili sloţena obeleţja čije vrednosti jednoznačno identifikuju pojave jednog tipa sloga, nazivaju se ključem ili pak primarnim ključem. Razna sortiranja odreĎenog skupa pojava odreĎenog tipa sloga u datoteci se najčešće izvršavaju u saglasnosti sa vrednostima primarnog ključa. Za razliku od primarnog sekundarni ključ predstavlja ono obeleţje kod koga se ista vrednost javlja kao elemenat većeg broja pojava istog tipa sloga. Kada se govori o bazama podataka onda je uz njih pojmovno najčešće vezano traţenje ili pretraţivanje baze, a pojam traţenja pojave sloga u datoteci i pojam pretraţivanja datoteke su veoma blisko povezani za pojmove primarnog i sekundarnog ključa. Naime traţenje se vrši uz pomoć vrednosti primarnog ključa, pa se kao rezultat traţenja moţe dobiti najviše jedna pojava sloga, dok se pretraţivanje vrši na osnovu vrednosti sekundarnog ključa, pa se kao rezultat pretraţivanja moţe dobiti veći broj pojava datog sloga. Pri tome treba imati na umu da i traţenje i pretraţivanje mogu biti bezuspešni, tj. rezultat tih aktivnosti moţe biti samo konstatacija da u datoteci ne postoji pojava sloga sa posmatranom vrednošću ključa. Vrednost ključa sa kojom se vrši traţenje ili pretraţivanje naziva se argumentom traţenja ili pretraţivanja. Sledeći pojam koji je veoma prisutan kada su u pitanju datoteke ili baze podataka je aţuriranje. Aţuriranje predstavlja skup aktivnosti koje imaju zadatak da podatke u datoteci ili bazi dovedu u saglasnost sa stvarnim stanjem obeleţja entiteta. Pod pojmom aţuriranja se podrazumeva sledeći skup aktivnosti: upisivanje novih pojava sloga u datoteku - bazu, zatim modifikacija onih obeleţja koja nisu 15
@ViPserbia
ključna u postojećoj pojavi sloga kao i brisanje postojećih pojava sloga i njihovih veza ukoliko je to dozvoljeno, tj. ukoliko se ne narušava integritet baze. U nastavku ćemo dati neke od osnovnih pojmova koji se odnose na strukture podataka. Tako naprimer skup S moţe predstavljati skup obeleţja, skup slogova različitog tipa, skup podataka, skup pojava slogova istog tipa, skup pojava slogova različitog tipa. Često se u skupove podataka uvode razne relacija Ri (i=1,2, ...,), a kao rezultantna relacija se moţe pojaviti unija, presek ili neka druga forma relacija Ri. Tako se naprimer unija R relacija R1 i R2 se definiše kao R = R1UR2. Relacija se mogu predstavlja spiskom ureĎenih parova, a kao prikaz relacija se moţe se koristiti matrica aij sa vrstama ai i kolonama matrice aj (i,j = 1,2...,N) Zatim se kao jedan od mogućih načina grafičkog predstavljanja strukture podataka koristi usmereni graf tj. na taj način se moţe 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 moguće strukture podataka. S1
S2
S4
S3
S5
S6
S7
Slika 2.1 Struktura podataka - usmereni graf
Strukture podataka se mogu klasifikovati uz pomoć više kriterija, a za projektovanje informacionih sistema vaţni su sledeći kriterijumi: -dozvoljeni broj neposrednih prethodnika i sledbenika nekog elementa strukture -priroda elemenata skupa Obzirom na prvi kriterijum, u osnovi se razlikuju linearne, hijerarhijske i mreţne strukture, sa odreĎenim varijetetima. Vezano za drugi kriterij, u osnovi se razlikuju logičke strukture obeleţja, logičke strukture podataka i fizičke strukture podataka, kao i njihovi varijeteti 16
@ViPserbia
Linearne strukture podataka se obično nazivaju se listama ili lancima. Pri tome je struktura liste veoma jednostavna jer svaki elemenat liste moţe imati samo jednog prethodnika i jednog sledbenika. Na slici 2.2 je prikazana jedna takva otvorena lista, a na slici 2.3 zatvorena lista S1
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 mreţnog modela) je tip baze podataka orijentisan još uvek na pojmu "slog". Pri tome ovaj model dozvoljava da se slogovi organizuju (grupišu) u skupove (setove). Vlasnik skupa se naziva "roditelj" (parent), a član skupa se naziva "dete" (child). Veze izmeĎu 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 znači da je postojao "prethodni" (previous) i "sledeći" (next) slog u setu: Hijerarhijske baze podataka su organizovane u relaciji "jedan prema jedan" (1:1) i "jedan prema više" (1:M).
17
@ViPserbia
S1
S2
S4
S3
S5
Slika 2.4 Nepotpuna nekompletna hijerarhijska struktura U zavisnosti od ključa nadreĎenog segmenta ili grane moţe da zavisi jedan, ili više podreĎenih segmenata, a moţe se desiti da ne postoji ni jedan podreĎeni segment. Pri tome treba imati na umu da su segmenti – grane stabla na niţem nivou u podreĎenom odnosu tj. podreĎeni segmentima odnosno granama stabla na višem 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. MeĎu č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 duţine k-l, a put počinje u korenu stabla. Duţina puta se meri brojem potega izmeĎu dva posmatrana čvora. Broj nivoa hijerarhije h naziva se visinom stabla. Visinu stabla h predstavlja broj, koji je za jedan veći od duţine puta izmeĎu korena i najudaljenijeg lista. Za stablo se kaţe da je puno, ako se svi listovi nalaze na istom odstojanju od korena, odnosno, ako, od korena, svakom listu odgovara put duţine h-1. Za stablo se kaţe 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 moţe 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 kaţe da je balansirano, ako za svaki čvor vaţi da se broj čvorova u svakom njegovom podstablu ne razlikuje za više 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ć Nešić Napomenimo ovde da su se još ranih 60-tih godina pojavile prve ideje o razvoju posebnih softvera za upravljanje bazama podataka. Poznati teoretičar 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 značajno poboljšale metodologiju analize informacionih 19
@ViPserbia
sistema. Bachmannov dijagram je grafička prezentacija uglavnom malih delova programa pomoću limitiranog skupa grafičkih simbola. BAZA PODATAKA SET-1 Odelenje knjigovodstva
Jovanović
Petrović
Kukoč
SET-2 Odelenje marketinga
Ugren
SET-3 Odelenje za IS
Radaković
Nešić
Slika 2.6 Hijerarhijska struktura - primer Rezultat toga jeste da su se pojavili IDS (Integrated Data Store) softveri opremljeni sa mogućnošću realizacije šeme podataka (data scheme) i ţurnaliziranja (logging). Ovaj softver je radio na GE računarima i mogao je da koristi samo jednu datoteku kao bazu podataka, a sve generacije tabela sa podacima morale su ručno 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 najvećih multinacionalnih kompanija u oblasti informatičke tehnologije IBM (international Business Machine Corp.) je 1968. uvela svoj IMS (Information Management System) sistem koji je podrţavao hijerarhijsku organizaciju baze podataka za svoje računare IBM/360 generacije. Pored ovoga razvili su i alat DL/1 (Data Language One) za potrebe navigacije kroz takvu bazu. IBM je za potrebe američkih avio kompanija razvio i podvarijantu svog rešenja pod komercijalnim nazivom SABRE. Nešto kasnije, 1973. godine pojavila se Cullinane Corp. (kasnije nazvana Cullinet Software Inc.) koja je počela da plasira inoviranu verziju Goodrichevog IDMS softvera i zahvaljujući tome postali su u to vreme jedna od najvećih kompanija u oblasti softvera. Ova kompanija se kasnije restruktuirala u danas poznatu kompaniju CA-Computer Asscociate. Imali su i tzv. preprocesore realizovane u COBOL okruţenju. Pored ovih kompanija, na trţištu su bili prisutni i Honeywell sa svojim rešenjima (IMS), Univac (kasnije Unisys) sa DMS 1100, TOTAL/SUPRA (Cincom) i Digital VAX DBMS. Zbog komplikovane navigacije ove baze su bile veoma kompleksne i traţile su dobro osposobljeno projektantsko/programersko osoblje. Lanci (poveznice) su lako pucali i takve baze je bilo jako teško oporavljati u slučajevima havarija.
20
@ViPserbia
Na kraju moţemo reći 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 funkcionišu na osnovu hardverskih adresa zapisa (slogova) tako da se u poveznicama (link) nalazila fizička adresa sloga odnosno relativna adresa u odnosu na prvi slog u setu. ICL (International Computer Limited) se pojavio sa specijalnim hardverom (ugraĎeni mikroprocesori u glave za pisanje/čitanje na diskovima za brzo pretraţivanje fizičkih adresa podataka. Matematički 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 sadrţao i dva dodatna elementa (polja): - koren (root) odnosno slog sadrţi 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 moţe da ima jedno ili više dece, - prednost ovakve organizacije: brzina i efikasnost za odreĎene aplikacije hijerarhijski orijentisane, - problem: kako je organizacija podataka unapred definisana mora se svaka relacija eksplicitno kreirati u bazi podataka, - hijerarhijska organizacija je podskup mreţne organizacije baze podataka Mrežne strukture podataka Ono što je posebno značajno kod ove strukture je da svaki elemenat skupa moţe imati više direktnih prethodnika i više direktnih sledbenika Mreţni model podataka se zasniva na mreţi podataka koji su tako povezani da ne postoje ni nadreĎeni niti podreĎeni segmenti baze. Ovakva struktura je mnogo sloţenija u odnosu na hijerarhijsku strukturu. Mreţna struktura se moţe dobiti i odgovarajućom kombinacijom hijerarhijkih struktura. Pored toga ona značajno smanjuje dupliranje nekih podataka u odnosu na hijerarhijsku strukturu i značajno smanjuje vreme potrebno za pronalaţenje nekih podataka. Hijerarhijska i mreţna struktura podataka mogu zadovoljiti kada su veze izmeĎu podataka malobrojne ili pak jednostavne. MeĎutim u slučajevima sloţenijih
21
@ViPserbia
veza predstavljanje meĎusobnih odnosa takvim strukturama postaje veoma oteţano. U tom slučaju 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 istraţivačke laboratorije u San Hozeu (San Hose, California) je publikovao sada već klasični 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 mreţnog modela. U delu koji se odnosi na objekte, relacioni model je relativno siromašan jer raspolaţe objektima relacija, atribut, kandidat za ključ, primarni ključ i strani ključ. Veze izmeĎu relacija se uspostavljaju na osnovu stranih ključeva ili uvoĎenjem asocijativnih relacija. Najznačajnija ograničenja relacionog modela su ograničenja integriteta entiteta i ograničenja referencijalnog integriteta. U nekim realizacijama SUBP-a definiše se odreĎeni skup integriteta atributa (na domen, na opseg vrednosti i slično). Uopšteno relacioni sistem se moţe opisati kao grupa slobodno povezanih struktura podataka koje zajedno daju potrebne informacije o nekom subjektu. Naime u većini slučajeva je besvrsishodno drţati baš sve informacije o nekom subjektu u jednoj datoteci ili tabeli ili zapisu. Ove informacije se grupišu u odreĎene logičke celine i smeštaju u posebne datoteke ili tabele, a relacije se koriste za povezivanje ovih srodnih grupa podataka. Poseban problem je pitanje očuvanja referencijalnog integriteta. On se u mnogim SUBP-ima razrešava na nivou samog aplikativnog koda. Ukoliko je i ugraĎen, tada se troše veliki sistemski resursi za njegovo očuvanje pa ga je potrebno veoma paţljivo i umereno koristiti. Najmoćniji deo relacionog modela su operatori koji se baziraju na relacionoj algebri od kojih su svakako najvaţniji restrikcija, projekcija i spajanje. Odmah nakon prvih naučnih 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 uobličen u SOL – struktuirani jezik za upite. Mada je relaciono kompletan on ima nedostatak ortogonalnosti. Isto tako, Kod navodi da i promovisani ANSI standard (1986) više štiti postojeće implementacije ovog jezika nego što predstavlja zaista solidnu osnovu za budućnost. SOL je jezik za definisanje, manipulisanje i kontrolu podataka u relacionoj bazi. Zbog njegovih osobina mnogi ga proizvodači dopunjuju svojim operatorima. Loše karakteristike SOL-a u radu sa ekranskim formama i izveštajima se nadopunjuju 22
@ViPserbia
njegovim ekstenzijama u tim pravcima, što opet dovodi do daljeg odstupanja od standarda. Nimalo ne umanjujući pozitivne karakteristike relacionog modela, mora se reći 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 mreţnih. 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 mreţnog i hijerarhijskog modela tako se Entity Relationship model of data base – entitet relaciona baza podataka je razvijena uvoĎenjem tzv. elementa relacije izmeĎu entiteta u bazi podataka. 1976 Peter Chen je na MIT- u je uveo pojam Entity-Relationship data model – model podataka u kome postoje relacije izmeĎu entiteta. Neki autori nazivaju ovaj model i postrelacionim Taj model grafički predstavlja osnovne karakteristike strukture aplikacije baze podataka. Ovakav način predstavljanja podataka je veoma jednostavan, koncizan i gotovo da sam objašnjava kakve su interakcije izmeĎu 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 zadrţani ali je pridodat i skup novih. E-R model Kao što se relacioni model javio kao odgovor na nedostatke mreţnog 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 zadţani 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 moţe biti i zavisnost prethoĎenja. Tip veze - Objekat preko koga se uspostavlja veza izmeĎu tipova entiteta. Ukoliko se radi o vezi izmeĎu pojava jednog tipa entiteta tada govorimo o refleksivnoj vezi. Mešoviti tip objekta (agregacija) - objekat preko koga se uspostavlja veza izmeĎu tipova entiteta, pri čemu se on dalje moţe povezivati sa drugim tipovima entiteta preko veza 23
@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 vaţi pravilo nasleĎivanja osobina (atributa) od nadtipa ka podtipovima, Kardinalnost - Koncept koji predstavlja ograničenje na osnovu minimalnog i maksimalnog broja veza jednog tipa entiteta sa drugim u konkretnoj vezi. Ovako definisan skup objekata ukazuje da se radi o semantički bogatom modelu podataka koji je upravo zbog toga našao visok stepen upotrebe. Ukoliko se u fazi dizajna poštuje mali skup neophodnih pravila, model podataka će bitl u 3NF ili u BCNF. 2.2 Dodatna definisanja nad podacima Logičke strukture obeležja Kada se u skup obeleţja jedne klase entiteta uvede relacija strogog poretka tako da svako obeleţje moţe imati najviše jednog neposrednog prethodnika i najviše jednog neposrednog sledbenika, dobija se linearna struktura obeleţja. Ta linearna struktura obeleţja naziva se tipom sloga. UvoĎenjem relacija u skup slogova različitog tipa ponovo se dobija logička struktura obeleţja. Logička struktura obeleţja definisana nad skupom slogova različitog tipa, karakteristična je za baze podataka. Logičke strukture obeleţja baza podataka mogu biti linearne, hijerarhijske, mreţne ili relacione. Tip sloga predstavlja logičku strukturu obeleţja datoteke. Datoteci najčešće odgovara linearna logička struktura obeleţja definisana nad skupom elementarnih obeleţja. Svakom tipu sloga, kao linearnoj strukturi obeleţja, odgovara skup pojava sloga. Svaka pojava sloga predstavlja jednu linearnu strukturu podataka. UreĎenje podataka u pojavi sloga definisano je ureĎenjem obeleţja u tipu sloga. Kada se u skup pojava, sloga jednog tipa, uvede relacija strogog poretka dobija se logička struktura podataka datoteke. Logička struktura podataka datoteke je najčešće linearna, a dobija se ureĎivanjem pojava sloga jednog tipa saglasno rastućim ili opadajućim vrednostima ključa. Logičke strukture podataka u bazama podataka se definišu uvoĎenjem relacija u skup pojava slogova različitog tipa. Pored relacija izmeĎu pojava slogova različitog tipa, koje diktira logička struktura slogova različitog tipa, skup pojava slogova snabdevaju i relacije izmeĎu pojava sloga.
24
@ViPserbia
Pošto logička struktura obeleţja ne poseduje informaciju o ureĎenju pojava sloga jednog tipa bez obzira na broj pojava sloga, jednoj logičkoj strukturi obeleţja odgovara veći broj logičkih struktura podataka. MeĎutim, preslikavanje logičke strukture podataka na logičku strukturu obeleţja je jednoznačno. Definisanje fizičke strukture podataka Kada se podaci i veze logičke strukture podataka smeste na magnetni medij nekog memorijskog ureĎaja (traka, disketa, disk, CD), dobija se fizička struktura podataka. Pri tome se, za predstavljanje podataka, umesto prirodne koristi binarna azbuka. Pored podataka, koje sadrţi logička struktura podataka, fizička struktura podataka se proširuje i podacima, svojstvenim postupcima memorisanja na konkretnom mediju, podacima koji opisuju odreĎene osobine pojava slogova (na primer: duţina pojave sloga izraţena brojem znakova prirodne azbuke, pripadnost tipu sloga i slično). TakoĎe, postoje različiti postupci za predstavljanje veza logičke strukture podataka, Istoj logičkoj strukturi podataka moţe odgovarati više fizičkih struktura podataka, ali je preslikavanje fizičke na logičku strukturu podataka jednoznačno. Podaci i veze logičke strukture podataka, smešteni na medij memorijskog ureĎaja i prošireni nizom elemenata svojstvenih postupcima za memorisanje podataka i veza na konkretnom ureĎaju, predstavljaju fizičku strukturu podataka. Smeštanje podataka i veza u lokacije na memorijskom mediju predstavlja zadatak operativnog sistema, odnosno njegovog dela koji se naziva sistemom za upravljanje podacima. U cilju povećanja efikasnosti kasnije obrade podataka, sistem za upravljanje podacima snabdeva fizičku strukturu podataka nizom dodatnih podataka. Specifičnosti smeštanja podataka u lokacije na memorijskom prostoru i dodatni podaci su takoĎe elementi fizičkih struktura podataka. Definisanje formata sloga Za predstavljanje pojave sloga S, kao elementa fizičke strukture podataka, koristi se takozvana linearna struktura prema datoj slici 2.7. Struktura na slici predstavlja opšti oblik formata sloga gde k(S) predstavlja vrednost ključa, p(S) konkretizaciju neključnih obeleţja sloga, u(S) vrednost pokazivača, a s(S) status sloga. Dok se k(S) i p(S) dobijaju preslikavanjem logičke na fizičku strukturu podataka, u(S) i s(S) predstavljaju moguća proširenja sloga svojstvena fizičkoj strukturi podataka.
25
@ViPserbia
k(S)
p(S)
u(S)
s(S)
Slika 2.7 Opšti format sloga Načini memorisanja veza logičke strukture podataka Veze (relacije) logičke strukture podataka mogu se fizički realizovati na više načina. Tu su pre svega u pitanju fizičko pozicioniranje, pokazivači, adresar (directory-datoteka u kojoj su memorisane veze pojava sloga iz druge datoteke), dvodimenzionalne binarne matrice i drugo. Fizičko pozicioniranje predstavlja veoma efikasno sredstvo, za memorisanje linearnih struktura podataka. U fizički susedne lokacije memorijskog prostora smeštaju se logički, susedni slogovi. Fizička susednost nosi informaciju o vezama logičke strukture podataka. Fizičko pozicioniranje predstavlja jedinstven postupak kada se smeštaju podaci jednog sloga na memorijski medij, a često se koristi i za fizičku realizaciju linearnih struktura slogova. Za predstavljanje kompleksnih logičkih struktura, u datotekama i bazama podataka najčešće se koriste pokazivači. Pokazivači se memorišu ili uz slog, kada predstavljaju integralni deo sloga, ili u posebnoj datoteci-adresaru. U oba slučaja obezbeĎuju informaciju o adresi (ili adresama) lokacija sa slogovima koji su u logičkoj vezi sa posmatranim slogom. Ta informacija moţe biti data kao mašinska adresa, relativna adresa ili simbolička adresa, odnosno vrednost ključa. Pokazivači u obliku mašinske adrese obezbeĎuju najbrţu obradu, ali imaju nedostatak da su veoma nefleksibilni u odnosu na promene fizičke strukture podataka. Izmena ureĎaja ili rasporeda slogova na memorijskom medijumu zahteva i izmene pokazivača. Pokazivači u obliku relativne adrese sadrţe redni broj lokacije dela memorijskog prostora dodeljenog datoteci. Pretvaranje relativne u mašinsku adresu predstavlja zadatak jednog algoritma. Promene adrese u fizlčkoj strukturi podataka dovode samo do izmene tog algoritma, ali ne i do izmene samih pokazivača i1i aplikativnlh programa. Primena simboličkih adresa kao pokazivača predstavlja veoma fleksibilno, ali relativno sporo rešenje. Numerički ključ se transformiše u adresu uz pomoć neke formule. Nenumerički ključ se prvo mora pretvoriti u numerički 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 ureĎaja. Takva grupa odreĎenog broja slogova naziva se blokom. Blokiranje poboljšava iskorišćenje memorijskog prostora i povećava efektivnu brzinu razmene podataka izmeĎu operativne i eksterne memorije. Često, blokiranje povećava i efikasnost obrade podataka, jer smanjuje broj ulazno-izlaznih operacija neophodnih za obradu datoteke. Blok sadrţi jedan ili više slogova. Broj slogova u jednom bloku naziva se faktorom blokiranja. Faktor blokiranja f se definiše u postupku projektovanja datoteke, a moţe imati konstantnu ili promenljivu vrednost. Moţe se vršiti i kompresija podataka u slogu, izostavljanjem nepopunjenih pozicija u pojedinim poljima, dobijaju se slogovi promenljive duţine. Kombinovanjem konstantnog i promenljivog faktora blokiranja sa slogovima konstantne i promenljive duţine, dobijaju se četiri moguće vrste blokova. To su: - blokovi sa konstantnim faktorom blokiranja i konstantnom duţinom slogova - blokovi sa konstantnim faktorom blokiranja i promenljivom duţinom slogova - blokovi sa promenljivim faktoram blokiranja i konstantnom duţinom slogova - blokovi sa promenljivim faktorom blokiranja i promenljivom duţinom slogova. Prilikom razmene podataka izmeĎu operativne memorije i eksterne memorije, u operativnu memoriju se uvek prenosi ceo blok. Ova činjenica ograničava veličinu bloka, odnosno, nameće potrebu da se pri izboru veličine bloka vodi računa o zauzeću operativne memorije. Pojam bloka se odnosi na niz od N sukcesivnih slogova smeštenih na nekoj lokaciji na memorijskom mediju. Ta lokacija se sastoji od N podlokacija. Pošto, po definiciji, svaka podlokacija predstavlja lokaciju, u nastavku će se za lokaciju sa N podlokacija koristiti naziv fizički blok, a za podlokacije će se koristiti naziv lokacije. Fizički blok poseduje adresu na memorijskom prostoru. Ta adresa moţe biti mašinska ili relativna. Kada je reč o jedinici magnetnog diska, mašinska adresa moţe 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 moţe shvatiti kao redni broj fizičkog bloka od početka medija, mada se bloku na traci nikad ne pristupa na osnovu adrese. Relativna adresa predstavlja redni broj fizičkog bloka od početka memorijskog prostora dodeljenog datoteci. Upisivanje podataka na magnetni disk Upisivanje blokova na magnetni disk se moţe vršiti uz pomoć jednog od dva meĎusobno različita postupka. To su takozvani sektorski i programabilni postupak. 27
@ViPserbia
Kod sektorskog postupka sve staze na aktivnim površinama ploče diska su podeljene na odreĎeni broj sektora. Broj sektora varira od ureĎaja do ureĎaja. Obično predstavlja neki stepen broja 2, koji jc veći od 1, a moţe biti manji ili jednak 128. Blokovi sa jednim ili više slogova memorišu se tako što se nakon početka sektora ostavi jedan mali meĎusektorski razmak, a zatim se upisuje blok na stazu. Ukoliko je blok duţi od kapaciteta soktora, njegovo se momorisanje nastavlja u narednim scktorima, ali se nakon svakog početka sektora ostavlja mali razmak. Svaki novi blok se počinje memorisati od meĎusektorskog 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 slučaju promenljivog faktora blokiranja ili slogova promenljive duţine, kod primene sektorskog postupka upisa podataka na disk koriste se reči za opis bloka i reči za opis sloga. Naziv programabilan potiče od činjenice da se razmaci, izmeĎu fizičkih blokova sa podacima, generišu programskim putem, kao i od činjenice da se uz svaki blok memorišu informacije o njegovom sadrţaju. O memorisanju razmaka i dodatnih informacija brine operativni sistem. Traţenje bloka na stazi moţe se vršiti ili uz pomoć adrese, odnosno rednog broja bloka, u kojem se slog nalazi ili uz pomoć vrednosti argumenta traţenja. Ako se traţenje vrši na osnovu adrese, u operativnu memoriju se prenosi samo sadrţaj lokacije svakog bloka. Tek kada se adresa bloka u lokaciji pokaţe jcdnakom adresi traţenog bloka, u operativnu memoriju se prenosi i sadrţaj date lokacije. N TRAG – STAZA SEKTOR
n TRAG – STAZA
MEĐUSEKTORSKI RAZMAK 0 TRAG - STAZA SEKTOR
Slika 2.8 Upis podataka na magnetni disk
28
@ViPserbia
Ako se traţenje vrši na osnovu vrednosti argumenta traţenja, u operativnu memoriju se prenosi sadrţaj ključa date lokacije. Ukoliko je vrednost argumenta traţenja veća od vrednosti ključa u datoj lokaciji, učitava se sadrţaj lokacije narednog bloka. Tek kada vrednost argumenta traţenja postane manja ili jednaka sadrţaju ključa date lokacije, u operativnu memoriju se prenosi i odgovarajući sadrţaj područja podataka, jer se traţeni slog moţe nalaziti samo u tom bloku. Fizička organizacija baze podataka Performanse baze se uglavnom mere vremenom odziva na upite ili, što je uobičajeno kod višekorisničkih SUBP, brojem uspešno završenih transakcija u jedinici vremena. Najvaţniji faktor koji utiče na performanse je fizička organizacija baze. S druge strane, relacione baze i relacioni model podataka u celini su poznati po tome što su kod njih (relativno) uspešno razdvojeni logički koncepti (i strukture podataka) od fizičkih. Uprkos tome, pitanje fizičke organizacije (i performansi) i kod njih je veoma bitno, moţda i u većoj meri nego kod baza zasnovanih na drugim modelima podataka, za koje se ionako smatra da postiţu bolje performanse. Definisanje baze u nekim SUBP Moţda će izgledati čudno zašto se ovde bavimo definisanjem baze, kad je o tome već ranije nešto rečeno. U početnom delu, meĎutim, namerno su preskočene sve naredbe koje se odnose na fizičku organizaciju podataka. Sada ćemo se vratiti na te naredbe (DEFINE DATABASE, odnosno CREATE SCHEMA) i ukratko ćemo pokazati šta se sve moţe specificirati prilikom definisanja baze. Pre svega, pojedini SUBP daju mogućnost projektantu da svoju bazu drţi u jednoj ili više datoteka, koje se mogu nalaziti na različitim fizičkim jedinicama eksterne memorije (najčešće su to diskovi). Osnovni razlozi za deljenje baze na više fizičkih datoteka su dvojaki: prvo, na taj način se povećava raspoloţivi prostor za smeštaj baze, i drugo, poboljšavaju se performanse sistema, jer se ulazno-izlazne operacije kojima se pristupa bazi raspodeljuju na različite diskove i disk kontrolere, pa je vreme čekanja kraće. Prilikom definisanja baze, mogu se naprimer zadati sledeći parametri fizičke organizacije: . lokacija (ALLOCATION) i prostor rezervisan za bazu (EXTENT), kao i veličina 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 veličina datoteke snimka (SNAPSHOT EXTENT); . broj i veličina bafera za privremeno čuvanje podataka (BUFFER SIZE, NUMBER OF BUFFERS); . najveći broj korisnika koji će istovremeno pristupati bazi. Ukoliko korisnik koji kreira bazu ne definiše drugačije, ovi će parametri dobiti neke podrazumevane (default) vrednosti (za male i srednje baze vrednosti tih parametara uglavnom su zadovoljavajuće). Ako i kada se ukaţe potreba, naredbom CHANGE DATABASE mogu se promeniti vrednosti nekih od pomenutih parametara, pa i nekih drugih, kao što je aktiviranje dnevnika završenih transakcija. TakoĎe se moţe deaktivirati datoteka snimka, čime se dobija reţijsko vreme potrebno za njeno aţuriranje, ali se istovremeno i povećava mogućnost konflikta zaključavanja pri višekorisničkom radu, jer će tada sve transakcije čitati svoje podatke neposredno iz baze. Koje je rešenje bolje, najbolje je utvrditi eksperimentalno. Ukoliko se radi o bazi sa više desetina relacija i sa ukupnom količinom podataka koja prelazi desetak megabajta, korisno je razmotriti mogućnosti i prednosti definisanja baze sa više fizičkih datoteka (multifile database). Naprimer ako je u pitanju Rdb baza, za takvu bazu je potrebno prilikom definisanja, definisati jednu ili više zona smeštanja, storage areas, čime se kreiraju osnovna datoteka tipa .RDB, koja sadrţi podatke o strukturi i lokaciji podataka kao i posebne datoteke tipa .RDA, koje sadrţe samo podatke. Za multifile bazu potrebno je da se prilikom definisanja baze definiše bar jedna zona smeštaja, 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 smeštanja se naprimer definiše iskazom DEFINE/CREATE STORAGE AREA, unutar naredbe DEFINE DATABASE (RDO), ili CREATE SCHEMA (SQL). Svaka zona smeštanja dobija poseban naziv, koji se kasnije moţe iskoristiti za definisanje fizičkog smeštanja pojedinih relacija/tabela i indeksa. Ovim se iskazom mogu odrediti veličine sledećih parametara: - nazivi, lokacije i veličine datoteka u kojima će biti smešteni delovi baze (FILENAME, ALLOCATION, EXTENT); - veličina stranica i način popunjavanja stranica (PAGE SIZE, PAGE FORMAT), koji moţe biti UNIFORM (ako stranice sadrţe podatke iz samo jedne relacije) ili MIXED (ako stranice mogu da sadrţe podatke iz više od jedne relacije) ; 30
@ViPserbia
- granične vrednosti popunjenosti za stranice čiji je format definisan kao MIXED (THRESHOLDS); - parametre datoteke snimka koja odgovara .RDA datoteci, pošto svaka datoteka u multifile bazi moţe da poseduje sopstvenu datoteku snimka. Da bi se odredilo kako će relacije/tabele biti raspodeljene po fizičkim datotekama, potrebno je izdati naredbu DEFINE/CREATE STORAGE MAP. Ovom naredbom se za svaku relaciju navodi naziv jedne ili više zona gde će biti smeštena, pri čemu se moţe zahtevati smeštanje prema vrednostima podataka u jednoj ili više kolona, ili smeštanje u skladu sa jednim od indeksa definisanim nad dotičnom relacijom/tabelom (naravno, naziv indeksa se mora navesti). Na ovaj način projektant baze moţe da optimizira fizički raspored podataka, prilagoĎavajući ga najšešće korišćenim pristupnim putevima, tj. najčešće korišćenim upitima. Treba imati u vidu da se algoritam smeštanja prema vrednostima polja/kolona koristi samo pri smeštanju podataka naredbama STORE (RDO), ili INSERT (SQL); n-torke u kojima su vrednosti kasnije promenjene naredbama MODIFY ili UPDATE, neće biti premeštene. Najzad, naredbom CREATE STORAGE MAP moţe se zahtevati da se podaci iz neke relacije čuvaju na disku u komprimovanom (šifrovanom) obliku. Na taj način se, u prvom redu, štedi prostor na disku, a smanjuje se i mogućnost da neko neovlašćeno lice pročita podatke gledajući sadrţaj datoteke na disku, meĎutim povećava se rad samog procesora, koji mora da izvrši dekompresiju podataka pre korišćenja, odnosno kompresiju podataka pre no što se smeste na disk. Naredba DEFINE/CREATE STORAGE MAP moţe se koristiti samo dok je relacija/tabela o kojoj se radi prazna, inače će SUBP javiti grešku. Najbolje je koristiti ovu naredbu odmah po definisanju odgovarajuće relacije, dok u nju još nisu uneti podaci.
31
@ViPserbia
3. RELACIONE BAZE PODATAKA Istorijski 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 mreţnim 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 teškoća da se sa aplikativnim programima izvršavaju rutinske obrade. Kasnih 70-ih godina se pojavio relacioni model podataka koga su u početku koristili istraţivači 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 način stekla kompetitivnu prednost na svetskom trţištu. Kasnije su se pojavili i drugi kao Sybase, MS SQL Server i Access. Relacioni model podataka operiše sa podacima izmeĎu kojih postoje odgovarajuće relacije tako da se govori da izmeĎu tabela sa podacima postoji relaciona veza. Fizička implementacija relacionog modela podataka je u osnovi zasnovana na primeni tabela. Svaka tabela se sastoji od odgovarajućeg broja kolona koje se nazivaju polja - fields. Podaci smešteni 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. Različite tabele mogu imati različiti broj kolona. Ova osobina se koristi da se eksplicitno navede relacija izmeĎu 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 slična, pri čemu se polazi od definisanja i izrade osnovnih elemenata baze, a ozbiljnije razlike izmeĎu pojedinih SUBP se javljaju u mogućnostima i kapacitetima baze kao i u raspoloţivim 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 Table KlijentID
Ime_i_Prezime
Adresa
Number
Character
Character
Mesto
Drzava
Post_Broj
Character Character Character
1001 Jovan Jovanović
Vase Stajića 3
Novi Sad
SCG
21000
1002 Petar Petrović
Stevana Sremca 23 Zrenjanin
SCG
23000
Beograd
SCG
11000
Subotica
SCG
24000
1003 ĐorĎe Arsenijević Humska 23 Petefi Šandora 3
1004 Ana Bodor
Tabela računa: RACUNI Table KlijentID
Broj_Racuna
Number
Number
Vrsta_Stednje Dat_Otvaranja Character
Date
Saldo Number
1001
9987
Čekovi
10/12/1999
4000.00
1001
9980
Štrednja
10/12/1999
2000.00
1002
8811
Štednja
01/05/1992
1000.00
1003
4422
Čekovi
12/01/1999
6000.00
1003
4433
Čekovi
12/01/1999
9000.00
1004
3322
Štednja
08/22/1999
500.00
1004
1122
Čekovi
11/13/1998
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 označen je i vrednošću podatka koji se moţe smestiti u takvu kolonu. Number - mogu se smeštati samo brojevi (celi i decimalni) Character - mogu se smeštati brojevi, slova, znakovi punktuacije (u Access-u se ovakav tip podataka naziva tekst) Date - mogu se smeštati 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 najtipičniji 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 znači da postoji relacija koja dozvoljava da klijent pod imenom Jovan Jovanović ima tekući račun sa čekovima (Čekovi) i račun 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 matične datoteke (kao npr. klijent sa šifrom KlijentID= 1001 odnosno imenom Ime_i_Prezime=Jovan Jovanović) moţe imati više slogova u datoteci sa detaljima (u ovom slučaju su to dva računa) dodeljena jednom slogu iz glavne matične datoteke - tabele. Moguće je da u ovakvim relacijama tipa "sastavnica" postoji slog u matičnoj tabeli, a da taj slog nema detalje. MeĎutim, nemoguće je da se pojavi slog u datoteci "detalji" koji nema odgovarajuću relaciju sa matičnom datotekom. Na primer, moţete imati klijente u tabeli "Klijent" a da nemate nikakve informacije o računima takvog klijenta. Medjutim, bilo kakva informacija o računu MORA biti asocirana jednom klijentu u tabeli "Klijent"- klijenata. U svrhu obezbeĎenja egzistencije relacija izmeĎu 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 moţe 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 uključuju uobičajeni 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 takoĎe imati istu šemu.
34
@ViPserbia
R1 U R2 (unija skupa R1 i R2) je relacija koja sadrţi sve n-torke koje se nalaze i u skupu R1 i u skupu R2 R1 ∩ R2 (presek skupa R1 i R2) je relacija koja sadrţi sve n-torke koje se pojavljuju samo u R1 i R2 skupovima. R1 - R2 (razlika skupova R1 i R2) je relacija koja sadrţi sve n-torke skupa R1, a koje nisu sadrţane u skupu R2 Selekcija
Selekcija n-torke iz relacije R1 čiji atributi zadovoljavaju kriterijum koji se izraţava preko predikata P se moţe iskazati kao: R2 = select(R1,P) To znači da se iz skupa R1 kreira nova relacija R2 koja sadrţi sve one n-torke iz R1 koji zadovoljavaju (iskaz je istinit) kriterijum (predikat) P. Predikat moţe biti bilo koji Bool-ov izraz: "manje od" <, "veće od" >, "jednako ili veće od" >=, "jednako ili manje od" =<, "jednako" = kao i "nije jednako" !=).
Primer: Treba odabrati personalne računare koji se nalaze u kancelariji za oznakom 633: select(Radna stanica,Soba="633") Ime Popovic Pavlov Jovanov
Soba 633 633 633
Memorija 1,4GB 0,5GB 2GB
Procesor Pentium IV Pentium III Pentium IV
Monitor kolor 19 kolor 15 kolor 17
Projekcija Projekcija je izbor podskupa kolona u relaciji i odbacivanja ostatka kolona. R2 = project(R1,D1,D2,...Dn) To znači, da se iz n-torki skupa R1 kreira relacija R2 koja sadrţi samo domene imena ili konstanti D1,D2,..Dn. Primer: Iz tabele "Server" treba odabrati kolone "Name"- ime i "Status" project (Server,Name,Status) 35
@ViPserbia
Ime
Status
Asus Intel Intel Asus Asus
aktivan aktivan neaktivan aktivan aktivan
Sastavnica Sastavnica kombinuje atribute dve relacije u jednu. R3 = join(R1,D1,R2,D2) Svakoj relaciji R1 i R2 dodeljuju se domeni D1 i D2 respektivno. Tada se sastavnica posmatra kao skup svih mogućih parova n-torki ovih dveju relacija i ako su vrednosti izabranih domena jednaki tada je rezultat n-torka koja sadrţi sve atribute oba skupa uz izbacivanje duplikata iz domena D2! Polazeći od ove tri osnovne operacije, u implementaciji se koriste generisane operacije nad skupovima kao što su:
sortiranje (sort) mešanje (merge) kopiranje (copy) ubacivanje (insert) brisanje/odbacivanje) (delete/remove) rad sa indeksima (mogu biti jedinstveni, sa duplikatima, kombinovani odnosno sloţeni, strani ključevi) ugnjeţdene petlje
Krajnji korisnik relacionu bazu podataka vidi kao skup mnogo tabela koje su povezane sa nekom relacijom: - tabela je vertikalno izdeljena na "kolone" a horizontalno na "redove" - n kolona - m redova - presek kolone i reda predstavlja "polje" Primer:
36
@ViPserbia
Zaposleni Ime i prezime zaposlenog Jovan Jovanović … Petrović Petar … Ţivković Ţivko
Godina roĎenja 1961.
Zanimanje dipl. ekonomista
1950.
dipl.inţ.elektrotehnike
1978.
auto-mehaničar
Naziv tabele u bazi podataka: ZAPOSLENI Ime kolone: Godina roĎenja Red: Petrović Petar 1950. Polje: 1978.
dipl.inţ.elektrotehnike
Da bi se eliminisala redundantnost podataka, posebna oblast pri projektovanju baze podataka je normalizacija (prva, druga, treća, četvrta i peta) forme podataka.
Pravila normalizacije Normalizacija je formalizovani postupak za grupisanje atributa podataka u tabele i tabela u baze podataka. Ciljevi normalizacije sadrţe sledeće: - Eliminisanje dupliranih informacija u tabelama, - PrilagoĎavanje budućim izmenama u strukturi tabela, - Umanjivanje uticaja strukturnih izmena baze podataka na korisničke aplikacije koje pristupaju podacima.
Proces normalizacije se sprovodi u pet koraka. Prva normalna forma Prva normalne forma zahteva da tabele budu ravne i da ne sadrţe duplirane grupe.
Druga normalna forma Druga normalna forma zahteva da podaci u svim kolonama koje nisu deo ključa budu potpuno zavisni od primarnog ključa i svakog elementa primarnog ključa kada je on sloţeni primarni ključ. Potpuno zavisni znači da je vrednost podataka u svakoj koloni koja nije deo ključa zapisa, na jedinstven način odreĎena vrednošću primarnog
37
@ViPserbia
ključa. Ova normalna forma uklanja veći deo nepotrebnih (redudantnih) podataka, kojih verovatno ima u prvoj normalnoj formi.
Treća normalna forma Zahteva da sve kolone koje nisu deo ključa tabele budu zavisne od primarnog ključa tabele i nezavisne jedna od druge. Tabele moraju da odgovaraju prvoj i drugoj normalnoj formi da bi bile sposobne za treću normalnu formu.
Četvrta normalna forma Zahteva da se nezavisni entiteti podataka ne čuvaju u istoj tabeli kada prema njima postoje relacije više-prema-više.
Peta normalna forma Zahteva da mora postojati mogućnost da se tačno rekonstruiše originalna tabela pomoću tabela u koje je ona rastavljena. Peta normalna forma zahteva da tabele poštuju pravila treće normalne forme, a kada postoje relacije tipa više-prema-više i pravilo četvrte normalne forme. Smatra se da je idejni tvorac koncepta relacione baze podataka koja je danas najčešće zastupljena E. F. Codd. U nastavku su data osnovna sistematizovana pravila. Ova sistematizovana pravila, koja je postavio E.F. Codd, su danas implementirana na osnovu ANSI SQL-99 standarda (sa njegovim pravilima i proširenjima nastalim kao rezultat prakse). Karakteristike relacione baze podataka
Osnovni termini i definicije - Pojam "baza podataka" ima mnogostruke interpretacije a ovde je jednostavno to skup odrţivih podataka. - Relaciona baza podataka je ona u kojoj se podaci sastoje od skupa tabela u relaciji sa nekom drugom tabelom preko zajedničkih vrednosti. - Dve najvaţnije karakteristike relacione baze podataka su: a) podaci su smešteni u tabelama i b) postojanje relacija meĎu tabelama. - Tabele se još nazivaju entitetima ili relacijama i to su skupovi redova i kolona. - Red (drugačije se još nazivaju slog ili n-torka) reprezentuje konkretan skup informacija jedne pojave naprimer entiteta "Potrošač" 38
@ViPserbia
- Kolona (drugačije se još nazivaju polje ili atribut) reprezentuje karakteristike jedne pojave odnosno entiteta naprimer "Ime potrošača", "Poreski broj obveznika", itd. - Relacija je logička veza (spojnica) izmeĎu dve tabele. - Sistem za upravljanje relacionom bazom podataka (RDBMS) koristi sistem zadovoljavanja kriterijuma za odabir vrednosti iz više tabela. - Prezentacija podataka kao tabele je logička konstrukcija i ona je u potpunosti nezavisna od toga gde se podaci fizički nalaze na nekom mediju (naprimer disku).
Stanje trţišta u odnosu na relacione baze podataka - Iako je IBM kompanija prva započela kasnih 70-tih godina realizaciju Coddovog koncepta, Oracle je prvi objavio komercijalnu relacionu bazu podataka (1979. godine). Oracle je danas prisutan na trţištu sa verzijom Oracle 9i, a na pomolu je i noviji model - IBM je isporučio svoj prvi proizvod "SQL/DS-Data System" tokom 1982. godine - Microsoft je objavio SQL Server 6.0 tokom 1995. godine - kasnije su se pojavili i drugi porizvoĎači sa svojim rešenjima kao što su IBM DB/2, Sybase Sql Server, Informix-SQl, CA Ingres, Centrua SQLBase, Borlandov Database Engine, Interbase, mySQL (za Unix platforme), PostgreSQL (za Unix platformu)
Coddova pravila u teoriji relacione baze podataka: - relaciona baza podataka je zasnovana na matematičkoj teoriji relacione algebre - izvorni koncept modela je izradio dr E.F. Codd 1970. i objavio je taj model u svom poznatom članku " ‘A Relational Model of Data for Large Shared Data Banks’ - kasnije, Codd objavljuje za ovaj model 12 pravila poznatih pod imenom Coddova pravila koja moraju biti zadovoljena da bi se neka baza podataka posmatrala kao realciona baza podataka - u praksi se mnogi softveri koji podrţavaju rad sa bazama podataka ne mogu posmatrati kao relacione baze ako strogo ne zadovoljavaju ovih 12 pravila - Pravilo 1: Podaci se prikazuju kao tabele - Pravilo 2: Podacima se pristupa na logički način (a ne preko fizičkih adresa zapisa)
39
@ViPserbia
- Pravilo 3: Podaci sa tzv. zapisom "Null" (podatak bez konkretne vrednosti je zapis u polju tabele ali postoji rezervisan prostor) posmatraju se kao "nepoznata vrednost" - Pravilo 4: Baza podataka je samo-opisujuća: pored korisnikovih podataka, relaciona baza podataka sadrţi podatke i o samoj sebi postoje dva tipa tabela: korisnikove tabele koje sadrţe radne podatke i sistemske tabele koje sadrţe podatke o strukturi baze podataka metapodaci su podaci koji opisiju strukturu same baze podataka uključujući i definicije objekata (tabele, indeksi, memorisane procedure, paketi, funkcije, itd.) i njihove meĎuveze, skup sistemskih tabela se još označava i kao sistemski katalog ili rečnik podataka sistemskim tabelama se pristupa na isti način kao i korisnikovim podacima - Pravilo 5: Koristi se samo jedan jezik u komunikaciji sa sistemom za upravljanje bazama podataka (to je SQL jezik - neproceduralni i deklarativni koji ima tri podskupa: data modification – modifikacija podataka (INSERT, DELETE, SELECT, UPDATE), data definition – definicija podataka (CREATE, DROP, ALTER) i data administration – administraciju podataka (GRANT, REVOKE, DENY, BACKUP, RESTORE, ROLLBACK, COMMIT) - Pravilo 6: ObezbeĎenje alternativnih mogućnosti uvida u podatke preko "pogleda" (view) (rezultat nije tabela fizički upisana u bazu podataka nego tabela smeštena u privremeni radni prostor baze podataka) - virtuelne tabele - Pravilo 7: podrška relacionim operacijama odnosno operacijama baziranim na skupovima (union, intersection, division, difference) - Pravilo 8: Fizička nezavisnost podataka - Pravilo 9: Logička nezavisnost podataka - Pravilo 10: Integritet podataka je funkcija baze podataka (koja nije sastavni deo aplikativnog sistema!) konzistentnost i sigurnost podataka 3 tipa integriteta podataka: entitetni integritet, domenski integritet i referencijalni integeritet deklarativni integirtet podataka preko "ograničenja" (constraint) proceduralni integritet preko samog programskog koda (memorisane procedure i okidači (trigger)) 40
@ViPserbia
- Pravilo 11: Podrška distribuiranim operacijama podaci mogu biti smešteni centralno ili distribuirano moguće su sastavnice mešanjem podataka iz tabela smeštenih na raznim serverima (distribuirani upiti) ili iz raznih relacionih baza podataka (heterogeni upiti) integritet podataka mora biti očuvan bez obzira na broj kopija podataka (replication) fizičke veze se realizuju preko takozvanih linkova baze podataka - Pravilo 12: Integritet podataka ne moţe biti srušen ni pod kakvim okolnostima!
41
@ViPserbia
3.1. Programsko okruženje za upravljanje podacima Podaci se organizuju za potrebe nekog korisnika. Razvoj informatičke tehnologije ide u smeru da ponuĎač softvera u okviru svog sistema za upravljanje bazama podataka nudi komponente koje omogućavaju korisniku da na efikasan i svrsishodan način doĎe do podataka potrebnih za poslovanje. Na sledećoj šemi je dat prikaz osnovne strukture svakog sistema za upravljanje podacima. Obuka - Edukacija Da bi bilo koji sistem za upravljanje podacima mogao da se napravi, neophodna je obuka osoblja za upotrebu takvog sistema.
KORISNIK
SISTEM ZA UPRAVLJANJE BAZOM PODATAKA
Edukacija
Pretraţivanje i aţuriranje
Programski jezik
Aplikativni sistem
Baza podataka
Usluţni programi
Pretraţivanje i aţuriranje podataka: Svaki sistem za upravljanje podataka mora imati ugraĎene efikasne mehanizme za: - upisivanje novog podatka (insert) - aţuriranje postojećeg podatka (update) - za pronalaţenje (za upit) podatka (select) - za brisanje nepotrebnog podatka (delete) Kod brisanja postoje dve mogućnosti: postojanje referencijalnog integriteta podataka nepostojanje referencijalnog integriteta podataka
42
@ViPserbia
Programski jezik Programski jezik treba da omogući korisniku da model poslovnih funkcija transformiše u program koji će sa svojim interfejsom (preko aplikativnih sistema) omogućiti korisniku pristup podacima. Danas je na trţištu prisutno nekoliko standardnih programskih jezika: - C (sa svojim dijalektima) (kompajlerskog tipa) - Borlandov Delphi ko (kompajlerskog tipa) - Microsoftov VisualBasic (pseudointerpretativnog i/ili kompajlerskog topa) - COBOL sa preprocesorima za pristup podacima (kompajlerskog tipa) - ADA (kompajlerskog tipa) - Java (pseudointerpretatorskog tipa) - XML (Extented Mark-Up Language) (nije programski jezik u pravom smislu ali omogućava upravljanje interfejsima za obuhva podataka) - SQL (Structured Query Language) (nije pravi programski jezik) - i niz specifičnih drugih jezika Aplikativni sistemi o Aplikativni sistemi su programske celine napravljene po meri korisnika a na osnovu prihvaćenog glavnog odnosno izvoĎačkog projekta informacionog podsistema. o Aplikativni sistemi se realizuju sa konkretnim programskim jezikom primenjenim nad konkretnom fizičkom i logičkom bazom podataka. Baza podataka o Sistem za kreiranje fizičke organizacije baze podataka za smeštaj podataka (fizička organizacija podataka) o Sistem za kreiranje logičke organizacije baze podataka (tabele, relacije, indeksi) o Sistem za administraciju i nadzor logičke organizacije podataka o Skup alata za projektante baze podataka: - Rečnik podataka - Dijagrami za kontrolu projekata (upravljanje vremenom realizacije projekata) - Dijagrami poslovnih funkcija - Dijagrami poslovnih procesa 43
@ViPserbia
- Dijagrami matrice proces-funkcija - Dijagrami entiteti-relacije - Dijagrami modula - Dijagrami toka dokumenata - Dijagrami obrada - ... o Sistem za dinamički oporavak baze podataka u slučaju neuspešno izvedene transakcije (rollback i forward recovery procedure) o Sistem za ţurnaliziranje Usluţni programi sluţe za administraciju o Sistem za instalaciju softvera za upravljanje bazama podataka o Sistem odrţavanja "zakrpa" u softveru (patches) o Sistem nadzora rada i podešavanja performantnosti o Pristup i sigurnost pristupa (korisnički nalozi i lozinke) o Praćenje povrede pristupa preko "audit" sistema o Sistem za brza pretraţivanja (QBE-QueryByExample) od strane krajnjeg korisnika o Arhiviranje, zaštita i oporavak podataka - dnevno, mesečno ili periodično arhiviranje - trajna arhiviranja - procedure za oporavak
44
@ViPserbia
3.2. Projektovanje aplikativnih rešenja primenom relacionih baza podataka Slobodno se moţe reći da se moderna obrada podataka zasniva na dva osnovna koncepta: 1. na konceptu baze podataka kao jedinstvenog skladišta svih informacija potrebnih za opis jednog realnog sistema, iz koga svaki korisnik moţe da izvuče one informacije koje su mu potrebne, i 2. na konceptu sistema za upravljanje bazom podataka kao sloţenog softverskog proizvoda, čiji je cilj da korisniku omogući lako i brzo rukovanje potrebnim podacima. Korisnici se pri tome ne opterećuju detaljima vezanim za fizičku organizaciju, zaštitu, obezbeĎenje konkurentnosti i druge sloţene administrativne poslovima. Svi sistemi za upravljanje bazama podataka omogućavaju: 1. unošenje podataka, 2. ureĎivanje podataka, 3. pregled podataka i 4. štampanje podataka i informacija koje su sadržane u više tabela podeljenih po redovima i kolonama. Tri osnovne principijelne karakteristike izdvajaju sistem za upravljanje relacionom bazom podataka – RDBMS (Relational Database Management System) od aplikacija sa primenom radnih tabela: 1. Svi RDBMS su projektovani da efikasno rade sa veoma velikom količinom podataka; 2. RDBMS lako povezuju dve ili više tabela, tako da korisnicima deluje kao da je to jedna tabela 3. RDBMS minimizuju dupliranje informacija U osnovi sam postupak projektovanja sistema relacione baze podataka se sastoji od 10 osnovnih koraka a to su: 1. Identifikacija objekata koje sistem baze podataka predstavlja; 2. Otkrivanje veza izmeĎu objekata (ukoliko postoji više objekata); 3. OdreĎivanje značajnih svojstava i ponašanja objekata; 4. Ustanovljavanje kako svojstva objekata utiču jedna na druge;
45
@ViPserbia
5. Izrada uvodnog rečnika podataka koji bi pomogao u definiciji tabela koje čine osnovu baze podataka; 6. OdreĎivanje relacija izmeĎu tabela baze podataka na osnovu veza izmeĎu objekata koje se nalaze u njima i ove informacije svakako treba uključiti u rečnik podataka; 7. Uspostavljanje tipova aţuriranja i transakcija koje prave i menjaju podatke u tabelama uključujući i sve neophodne zahteve u vezi sa integritetom podataka; 8. OdreĎivanje načina korišćenja indeksa kako bi se ubrzalo kreiranje upita, s tim da se izrazito ne uspori dodavanje podataka u tabele ili da se dodatno ne zauzme veliki prostor na disku; 9. ObezbeĎivanje zaštite podataka – odreĎivanje ko moţe da pristupi i menja podatke u svakoj tabeli i da promeni strukturu tabela; 10.Dokumentovanje dizajna baze podataka kao jedne celine, pisanje procedura za odrţavanje baze podataka uključujući i one za izradu rezervne kopije datoteke i restauraciju. Posebno treba imati na umu da u postupku projektovanja svaki korak zavisi od prethodnog. Kao što je već pomenuto teorija projektovanja relacione baze podataka utemeljena je na grani matematike koja se naziva Teorija skupova, zajedno sa velikim udelom kombinatorike i nešto malo statističke metodologije. Skup pravila i simbola pomoću kojih se relacione baze podataka definišu naziva se relaciona algebra.
3.3 Projektovanje baze podataka Projektovanje baze podataka obuhvata sve aktivnosti počevši od definisanja svih zahteva od strane korisnika buduće baze pa do kompletne izrade i provere baze. Na osnovu definisanih zahteva korisnika i odabira ţeljenog alata, mora se izvršiti logičko oblikovanje baze kao i definisanje i opis svih podataka i odnosa izmeĎu podataka u bazi. Zatim sledi dizajniranje baze, a to podrazumeva da se moraju
46
@ViPserbia
definisati logički modeli podataka i kako će ti podaci biti smešteni na računarskoj opremi (lokalno ili distribuirano), a zatim da li će biti korišćeni u mreţnom radu ili lokalnom Prilikom projektovanja baze mora se poći od realnog sistema za koji se projektuje baza. Potrebno je izvršiti adekvatnu analizu tog sistema, definisati hijerarhiju tokova, a zatim i definisati tokove podataka od ulaznih do izlaznih. Pri tome se uvek moraju imati na umu zahtevi korisnika i celokupan rad i primenu baze prilagoditi tim zahtevima. Za većinu korisnika je potrebno obezbediti takvu bazu koja će omogućiti da se unesu raspoloţivi podaci uz mogućnost redovnog aţuriranja tih podataka i da se omogući da se ti podaci mogu pretraţivati po odreĎenim kriterijumima definisanim od strane samih korisnika. Pored toga je potrebno da korisnici mogu selektovane podatke dobijene pretraţivanjem videti na ekranu u ţeljenim formama koje se često razlikuju od korisnika do korisnika, kao i da ti podaci mogu biti sačuvani ili pak odštampani po ţelji korisnika. Kriterijumi po kojima se moţe vršiti pretraţivanje će svakako zavisiti od vrste podataka u bazi, od samih korisnika kao i od specifičnosti pojedinih poslova za koje se baza koristi. 3.4 Projektovanje relacione baze podataka Projektovanje informacionih sistema svodi se na sledeće: - donošenje odluke o projektovanju informacionog sistema realizovanog uz pomoć informatičke tehnologije, - konstituisanje projektnog tima, - analiza poslovnih procesa i funkcija: o izrada idejnog, glavnog i izvoĎačkog projekta, o snimanje toka dokumentacije (ulazna i izlazna dokumenta poslovnog procesa), o intervjuisanje profesionalaca-učesnika u poslovnom procesu koji opisuje tehnologiju rada u njegovom domenu, o planiranje rokova okončanja projekata, o verifikacija i usvajanje idejnog, glavnog i izvoĎačkog projekta - dizajn poslovnih procesa i funkcija, - realizacija i implementacija - izrada uputstava za rad i obuka - eksplaotacija - usavršavanje(otklanjanje grešaka, podešavanje performansi)
47
@ViPserbia
Informacioni sistem je model realnog sistema u kome deluje pa se postupak projektovanja informacionog sistema svodi na neku vrstu modeliranja realnog sistema. Za modeliranje su nam neophodni alati: - modeli podataka: sluţe kao sredstvo za prikazivanje objekata realnog sistema, njihovih atributa i njihovih meĎusobnih veza preko tzv. logičke organizacije baze podataka. Modeli podataka daju statičke karakteristike sistema, a - modeli procesa: sluţe kao sredstvo za opisivanje dinamike sistema, dejstva ulaza na stanje sistema i izlazne transformacije, preko programa nad definisanim modelom podataka. Modeli podataka i modeli procesa podleţu apstrakcijama. Modeli podataka sa aspekta apstrakcije se kreiraju po principima: - Klasifikacija (tipizacija) i uzorkovanje tako da se skup sličnih objekata u realnom sistemu predstavlja jednom klasom objekata. Na primer skup {Ana, Petar, Zoran, Dušan, Maja} čine klasu STUDENT. Odnosno, svaki objekat iz ovog posmatranog skupa je tip objekta STUDENT - Generalizacija i specijalizacija: To je apstrakcija u kojoj se skup sličnih tipova objekata predstavlja opštijim generičkim tipom. Pod sličnim tipom obejkata ovde se misli na tipove objekata koji imaju jedan broj zajedničkih (istih) atributa sa drugim objektima operacijama. Na primer, skup tipova objekata {Student, Radnik, Dete, Penzioner} mogu se generalizovati u tip objekta GRAĐANIN. Inverzni postupak generalizaciji je specijalizacija. Tip objekta GRADJANIN se specijalizuje u podtipove STUDENT, RADNIK, DETE i PENZIONER. - Agregacija i dekompozicija: Agregacija je apstrakcija u kojoj se skup tipova objekata i njihovih veza tretira kao jedinstveni agregirani tip objekta. Na primer, tipovi objekata Student, Predmet, Profesor se agregiraju u tip objekta Prijava čiji atributi su na primer "Ocena" i "Datum_polaganja". Postupak inverzan agreagciji je dekompozicija. Sam objekat se u sistemu moţe tretirati kao najniţi nivo asptrakcije, kao agregacija njegovih atributa. Modeli podataka se primenjuju u svim fazama razvoja informacionog sistema: - u fazi planiranja razvoja (idejni projekat) definiše se globalni model podataka koristeći odgovarajuće generičke modele i grubo date podmodele za pojedine osnovne funkcije sistema. Ovaj model sadrţi samo najznačajnije objekte i veze i samo osnovne atribute objekata, koji su neophodni da bi definicija objekata i veza bila sjajna. - u fazi detaljne specifikacije zahteva razraĎuju se detaljni podmodeli za sve obuhvaćene podsisteme i funkcije u njima i oni se integrišu u jedinstveni 48
@ViPserbia
model podataka sistema. Ovde se definišu svi atributi objekata i sva pravila integriteta podataka. - u fazi projektovanja i implementacije sistema, model podataka je osnova za projektovanje baze podataka i aplikacije. Iz modela objekti-veze se formalno i automatizovano (uz pomoć softverskih alata) mogu definisati logička struktura baze podataka i programi za odrţavanje baze podataka. - u fazi operativnog rada sistema, model podataka implementiran kao rečnik baze podataka je osnova za odrţavanje sistema (izmene koje se zahtevaju). Ova objašnjenja idu ka tome da se danas sistematizuju postupci projektovanja relacione baze podataka. Većina današnjih softverskih alata namenjenih projektovanju relacionih baza podataka sadrţe komponente koje omogućavaju brzo i efikasno (ispravno) generisanje programa za odrţavanje baze podataka:
Konceptualni model funkcija Suština ovog koraka je da se ispitaju, utvrde, pronaĎu informacije o poslovnim funkcijama tokom analize: - poslovne funkcije o hijerarhija poslovnih funkcija o dekompozicija do nivoa elementarnih funkcija o detalji o funkcijama kao što su učestalost pojave, odgovor na funkciju, ko je "roditelj" funkcije, da li je funkcija zajednička sa još nekom ili ne, ko okida – aktivira obavljanje funkcije o definisanje entiteta i atributa (korišćenje entiteta se obavlja npr. preko SQL jezika: Create, Retrieve, Update, Delete i Archive a korišćenje atributa moţe da se obavlja npr. preko SQL jezika: Insert, Retrieve, Update, Nullify, Archive i druge o definisanje ulaza i izlaza funkcije o učestalost korišćenja funkcije - model matrice.
Implementacija funkcija Poslovne funkcije se transformišu u programske module pa se poslovne funkcije implementiraju kao: - forme za obuhvat podataka (obrasci, maske,...) na ekranu terminala, - izveštaji koji se mogu štampati ili ne, - zasebne programske jedinice kojima se obraĎuju podaci (sprovodi se proces vezan za konkretnu pojavu funkcije) ili - uputstva za obavljanje funkcije.
49
@ViPserbia
Osnovna suština projektovanja relacionih baza podataka jeste da se preko modela kroz prototip doĎe do relacija izmeĎu varijabila funkcija i da se to pretoči u programske module. Smatra se da današnji alati za projektovanje relacionih baza podataka treba da imaju sledeće softverske komponente: - upravljanje projektima (project management), - izrada dijagrama procesa, - izrada modela entiteta i relacija, - izrada dijagrama funkcija, - izrada dijagrama toka podataka i - izrada matričnog dijagrama. 3.5 Izrada dijagrama procesa Kod izrade dijagrama procesa najčešće se koristi opisivanje rečima. Pored toga, navodi se startna tačka procesa (okidač) i finalni proizvod procesa (rezultat), Primer: Dijagram baznog (osnovnog) procesa ima nekoliko komponenti: - korake procesa (svaka aktivnost unutar baznog procesa); diskretan "komadić - delić" posla koji se obavlja, - prenošenja kontrola unutar procesa iskazanih kao koraci (tok procesa), - gde se smeštaju materijali ili podaci ("magacin-skladište") sa periodom vremena, - identifikacija i definisanje dogaĎaja (okidači i rezulati procesa), - definisanje i opis organizacione jedinice u čijoj je nadleţnosti proces - kreiranje sirove verzije modela i - verifikacija modela procesa. Polja u tabeli se koriste za smeštanje jedinica informacija. Imena pojedinih polja mogu sadrţavati slova engleskog alfabeta, brojeve i donju crticu (_) i ne mogu sadrţavati prazna mesta. Polja mogu biti znakovna, numerička, datumska, logička ili MEMO polja. Dakle, sa odgovarajućim skupom simbola koje nudi konkretan alat opisuje se proces. Često konkretni alati nude i mogućnost korišćenja video i audio zapisa o procesu, animacije itd. tako da se u nekom vremenu na ovaj način obavlja sistematično opisivanje realnog sistema koje predstavlja tekuće i buduće znanje o poslovnom sistemu. 50
@ViPserbia
"Da" DogaĎaj
Uslov? "Ne"
Tok
Sačini Izveštaj
Korak "x" procesa "a"
Organizaciona jedinica "i"
Magacin
Kako ovakav model za izradu dijagrama procesa nije dovoljan onda se ide na izradu dijagrama funkcija. 3.6 Izrada dijagrama funkcija Poslovna funkcija je nešto što radi posao ili što treba da se uradi, odnosno, identifikuje se, definiše i opisuje misija i ciljevi posla. Jedan proces moţe imati na stotine a ponekad i na hiljade funkcija (npr. proizvodnja aviona). Poslovne funkcije se dekomponuju u iterativnom postupku da bi se dobila hijerarhija funkcija. Za svaki nivo hijerarhije koja je strukture stabla ("koren" "roditelj" "dete") obavlja se detaljno specificiranje funkcije. U opisu funkcije navode se strateški nivo, portfelji, ključni indikatori za performanse, kritični faktori uspešnosti funkcije. Dakle, u postupku dekompozicije funkcije: - prikupljaju se informacije o funkciji, - pravi se spisak kandidata za funkciju, - pronalazi se funkcija koja je "na vrhu", - u iterativnom postupku se dekomponuje funkcija do elementarnog nivoa (atomskog nivoa). Sa odreĎenim skupom grafičkih simbola i operacija mogu se definisati u rečniku relacione baze podataka dijagrami funkcija.
51
@ViPserbia
Primer: ADMIN (naziv - mnemonik funkcije) Podrţati upravljanje proizvodnjom i klijente-korisnike proizvoda *** ADM1 Obraditi i promovisati proizvode na zalihama i pruţiti usluge klijentima
ADM2 Kontrolisati zalihe proizvoda
*** ADM3 Identifikovati akcije prema nelikvidnim klijentima
ADM4 Arhivirati transakcije *** - nastavak dekompozicije funkcija
Kućica za ADM4 funkciju označava da se radi o "opštoj, zajedničkoj" funkciji. Na kraju moţemo reći da detaljna analiza funkcija obuhvata: - referenciranje funkcije u modelu (ADMi, i=1,2,3,..), - definisanje funkcije (kao glagol, jasno i nedvosmisleno uz upotrebu imena koja ukazuju na entitete i relacije: proizvod, klijent, ...), - opis funkcije (detaljni tekstualni opis funkcije koji se ne stavlja na dijagram već je deo rečnika baze podataka, a u tom opisu se navode pravila izvoĎenja funkcija: sekvencijalna, iterativna, uslovljena, ...). Potrebno je navesti i dokumentaciju na kojoj se bazira funkcija (interni akt poslovne organizacije, zakonski akt, ...). Potrebno je navesti i mehanizme kako se funkcija menja, - učestalost (treba proceniti koliko često se funkcija izvodi u nekom periodu vremena a ako je potrebno, navesti u kojoj organizacionoj jedinici se obavlja), - potreban odgovor (identifikovati traţene odgovore na informacioni zahtev i kada se traţe: tokom dana, tokom noći, u jednom trenutku npr. u 13 sati,...). 52
@ViPserbia
Pored toga navodi se da li je funkcija "u realnom vremenu" (on-line) ili se realizuje u tzv. "paketnom radu" (batch), - unakrsna referenca upotrebe funkcije (navodi se spisak svih organizacionih jedinica gde se koristi opisana funkcija), - dogaĎaji (šta okida-aktivira početak funkcije i da li funkcija kada se završi okida start neke druge funkcije). 3.7 Izrada dijagrama toka podataka Ovaj dijagram omogućava više-nivooski (višeslojni) pogled na domen poslovanja pri čemu se prikazuju aktivnosti i podaci zajedno sa tokom kolanja podataka izmeĎu aktivnosti. Dakle, dijagram toka podataka iskazuje model toka podataka tj. kako informacije kruţe u poslovanju. Ovaj model takoĎe podleţe dekompoziciji i uspostavljanju komunikacije izmeĎu pojedinih aktivnosti. Primer mogućih grafičkih simbola: Poslovna funkcija: 1
"Rent-a-car"
Aktivnost "Rent-a-car" koja transformiše podatke unutar poslovanja
Uradi procenu najma automobila i procenu prihoda preduzeću Tok podataka: ime-klijenta
Strelica pokazuje smer kretanja podataka unutar poslovanja i njenog ambijenta
Izvor/Cilj podataka:
KLIJENT
Izvor podataka ili cilj podataka koji se nalazi izvan poslovanja (to moţe biti neka druga funkcija, neki drugi realni svet, neki drugi objekat)
Memorija za podatke: D1 POTROŠAČ
Podaci koje poslovanje čuva za buduću upotrebu
53
@ViPserbia
Primer:
KLIJENT
KATALOG
"zahtevam..."
"odgovaram..."
"gledam..."
1 "Rent-a-car" "dovozim auto.."
VOZILO
"trebujem..."
"zahtevam..."
"generišem..."
RAČUN
3.8 Izrada matričnog dijagrama Matrica ranga 2 je matrica kojom se poslovne funkcije preslikavaju (mapiraju) na entitete. Tamo gde se pojavljuje ukrštanje reda "poslovna funkcija" i kolone "entitet" tu imamo postojanje "relacije". Na taj način se veoma brzo dobija uvid u to šta treba da proglasimo entitetima u smislu relacionog modela (u fizičkoj implementaciji to su tabele). Detaljnije govoreći, prisutne su dve matrice: matrica "funkcija/entitet" i matrica "funkcija/atribut". U svakoj ćeliji matrice "funkcija/entitet" navodi se akcija (C-create, R-retrieve, U-update, D-delete i/ili A-arhive). Na primer: Entitet Elementarna funkcija
RENTA2 RENTA3 RENTA3.1
Stavka najma
Klijent
Zaposleni
CRUD RU
CRUD RU R
R
U svakoj ćeliji matrice "funkcija/atribut" navodi se akcija nad atributom (Iinsert, R-retrieve, U-update, N-nullify i/ili A-arhive). Na primer: Atribut Elementarna funkcija
RENTA2 RENTA3 RENTA3.1
"Stavka najma" Redni broj stavke
"Stavka najma" Period najma
"Stavka najma" Dnevni trošak
IR R
IRU R
IRUN RU
54
@ViPserbia
U primer, -
zavisnosti od proizvoĎača softvera mogući su i drugi tipovi matrica. Na matrica "funkcija/korisnikova uloga-rola", matrica "funkcija/organizaciona jedinica", matrica "organizaciona jedinica/entitet", ...
3.9. Izrada dijagrama entiteta i relacija Ovo je najvaţniji deo projektovanja relacionih baza podataka jer preko ovakvog modela se obavlja povezivanje logičke i fizičke organizacije baze podataka. Komponente dijagrama su: - entitet - relacija - atribut i - jedinstveni identifikator entiteta (indeksi, ključevi,...) Entitet je stvar, predmet sa nekim značajem, koja opisuje suštinu odnosno ono što moramo znati o toj stvari, odnosno mesto gde čuvamo informaciju o toj stvari. Primer: "Student", "Predmet", "Knjiga". Svaki entitet ima svoj skup identifikacija kojim se on opisuje (atributi). Identifikuju se samo atributi od značaja a ne svi mogući atributi entiteta. IzmeĎu entiteta se uspostavljaju asocijacije (relacije) tako da je relacija jedan ureĎen par i svaki kraj relacije se imenuje: - "Student" sluša "Predmet" - "Predmet" koristi "Knjigu" - "Knjigu" je uzeo "Student" - "Predmet" slušaju "Studenti" Relacija moţe biti opcionalna (pod nekim uslovima se moţe pojaviti). Relacija u smislu skupova ima svoju kardinalnost (broj elementa skupa): 1:1; 1:M ili M:M (M=mnogo). Da bi se jedna pojava nekog entiteta razlikovala od druge, uvodi se jedinstveni identifikator. Za identifikatore se koristi: - jedan atribut ili grupa atributa, - jedna ili više relacija i/ili 55
@ViPserbia
- kombinacija atributa i relacija. Primer:
VIDEO KASETA -
# Identifikator kasete Naslov Trajanje Opis Starosna klasifikacija Cena Status:"Zauzeto"/"Slobodno" Reţiser Godina snimanja Tip filma:Akcioni/Horor/...
KORISNIK - # Identifikator korisnika - Prezime i ime - Adresa (mesto, ulica i kućni broj) - Telefon
Entiteti: VIDEO KASETA i KORISNIK Atributi: Video_Kaseta.Naslov, Korisnik.Telefon, ... Relacija: "1:M": Jedan KORISNIK moţe da iznajmi jednu ili više "VIDEO KASETA".
56
@ViPserbia
4. Elementi relacionih baza podataka Relaciona baza podataka, a posebno ona koja se razvija u Accessu u osnovi moţe da se sastoji od sledećih elemenata: tabele, upiti, maske i izveštaji; a moţe sadrţati: Data Access strane, makroe i/ili VBA module (Visual Basic for Application - programski jezik za programiranje operacija u Office aplikacijama).U principu moţemo reći da u osnovne elemente novijih baza podataka spadaju radne tabele, upiti, formulari i izveštaji, a u osnovne aktivnosti koje se izvršavaju kod korišćenja baze spadaju aţuriranje - odrţavanje baze podataka koje obuhvata unos novih podataka, izmenu ili brisanje postojećih podataka, zatim pretraţivanje baze podataka koje obuhvata pretraţivanje po definisanim kriterijumima. Pored toga obezbeĎuje se i dobijanje različitih pregleda podataka na ekranu kao i mogućnost štampanja odgovarajućih izveštaja ili pak arhiviranja na nekom od medija za kasniju upotrebu ili za neke druge namene. Pri tome treba imati na umu da je skup podataka u bazi kao i njihove meĎusobne veze u stvari slika stanja nekog realnog sistema u datom trenutku i da verovatno sadrţi odreĎene informacije o prošlosti, sadašnjosti i budućnosti tog sistema. Kao što je već rečeno baza podataka se moţe definisati i kao skup odgovarajućih entiteta koji odgovaraju stvarnim elementima, dogaĎajima ili konceptima realnog sistema za koji je baza načinjena. Ovi entiteti su u bazi povezani odreĎenim meĎusobnim vezama. Entiteti i veze izmeĎu njih su opisani takozvanim atributima. Veoma je vaţno kako su definisani modeli podataka u bazi jer oni imaju veoma vaţnu ulogu u svim fazama baze, počev od analize zahteva korisnika pa do kreiranja baze, puštanaja u rad do redovne primene baze u praksi. U praksi je kao što smo pomenuliu drugom poglavlju tokom primene raznih vrsta skupova podataka i njihovih meĎusobnih veza bio prisutan i veliki broj različitih tehnika modeliranja podataka. Dok je klasični pristup koji se odnosio na kreiranje klasičnih datoteka podataka bio više vezan za načine obrade koji su se primenjivali nad tim podacima, a manje na same podatke, noviji model podataka koji je omogućio mnogo bolju i efikasniju realizaciju baza podataka je zasnovan na primeni relacija tj. veza izmeĎu entiteta i to je takozvani Entity – relationship model. Primenom ovakvog modela je obezbeĎen mnogo veći stepen nezavisnosti podataka od programa koji ih koriste tj. omogućeno je, da kada korisnik ima formiran skup podatka na takav način, da posle moţe na tim podacima graditi veoma različite aplikacije i praviti veoma različita programska rešenja.
57
@ViPserbia
Pored entiteta i veza meĎu njima kao elementi baze se pojavljuju i atributi koji im se pojedinačno dodeljuju. Oni zajedno čine osnovni koncept modela entitet-veza. Pre svega definišimo entitet – to je jedan od objekata nekog realnog sistema koji se preko njega mogu lako definisati i identifikovati. Veza izmeĎu entiteta je ono što u stvari povezuje jedan entitet sa drugim u pojmovnom ili funkcionalnom smislu. Veze mogu biti parcijalne pojedinačne ili sveukupne odnosno totalne. Veza je totalna ako svaki entitet tog tipa ima bar po jednu vezu , a ako nema tada je veza parcijalna. Što se tiče atributa oni označavaju neke od karakterističnih odlika entiteta ili veze. Nadalje veoma je vaţno i ovom prilikom napomenuti da izmeĎu entiteta mogu postojati različiti stepeni veza tako na primer postoji veze tipa 1:1 – jedan prema jedan, zatim 1: N – jedan prema više i N : N – više prema više kada se entitetu jednog tipa pridruţuje više entiteta drugog tipa i obrnuto. Jednom definisane relacije postaju osnova za realizaciju same baze. Da bi se definisani model podataka mogao realizovati u formi realne baze neophodno je da se definišu relacije izmeĎu podataka koji su prisutni u sistemu. Zatim je potrebno te podatke grupisati u odreĎene logičke celine. Prilikom prevoĎenja modela entiteta i veza u relacije tj. prevoĎenja u relacioni model potrebno je da se vodi računa o sledećim osnovnim pravilima: a) Svi entiteti koji su definisani u modelu podataka će postati relacije, a atributi entiteta će postati ujedno i atributi relacija dok će identifikator entiteta postati primarni ključ relacije. b) Entitet podtip će postati relacija, a njegovi atributi će postati atributi relacije dok će primarni ključ relacije će postati identifikator nadreĎenog entiteta. c) Veza izmeĎu entiteta podtipa i nadreĎenog entiteta neće postati posebna relacija. Postoje i druga pravila koja se odnose na različite stepene relacija i koja se moraju primenjivati u zavisnosti od stepena relacije. Jednom definisani model podataka se moţe koristiti za razne primene i u različitim sredinama. Moţe se desiti da se za neku primenu definisani model podataka mora proširiti novim entitetima i novim vezama izmeĎu entiteta. Tada će se nakon izvršene analize i utvrĎivanja novih entiteta i veza morati definisati i odgovarajući atributi, a model podataka će dobiti odgovarajuću novu varijantu koja će se nesmetano moći koristiti i u novom aplikativnom okruţenju. Kod razvoja aplikacija vezanih za odreĎenu bazu podataka potrebno je izvesti odgovarajuće aktivnosti počevši od realizacije same baze podataka na nekoj računarskoj osnovi do programiranja i testiranja načinjenih programa. Definisani modeli podataka i relacija predstavljaju dobru osnovu za izradu aplikacije. Realizacija aplikacije predstavlja skup programa i procedura kojima se generišu informacije koje 58
@ViPserbia
korisnici ţele i kojima se aţurira baza podataka. Kao prvo javlja se zahtev da se kreira ţeljeni skup podataka i da se on i fizički realizira na računarskoj podlozi. Kod novijih baza podataka ovaj postupak se svodi na kreiranje odgovarajućih tabela podataka.
4.1. Tabele – tables Radi lakšeg razumevanja moţe se reći da tabele odgovaraju datotekama u klasičnim aplikacijama i u njima se čuvaju podaci date baze. Svaka tabela se sastoji od kolona i redova, dok se presek kolone i reda naziva polje. Polja u tabeli se koriste za smeštanje jedinica informacija. Imena pojedinih polja mogu sadrţavati slova engleskog alfabeta, brojeve i donju crticu (_) i ne mogu sadrţavati prazna mesta. Polja mogu biti znakovna, numerička, datumska, logička ili MEMO polja. Pojedino polje moţe dakle biti sledećeg tipa: tekst, broj, datum/vreme, logičko polje, memo polje (polje u koga se moţe uneti tekst proizvoljne veličine do cca 65 K), polje za unos brojeva u novčanom formatu, posebno polje u kome se automatski po započetom unosu sloga inkrementira broj (polje AutoNumber), hiperlink polje (pokazivač na adresu na Internetu), OLE objekt polje (polje sa objektom povezanim iz drugog programa) i Look Up polje (polje čiji prikazani sadrţaj se nalazi u drugoj tabeli). Znakovna polja mogu sadrţati bilo koji znak sa tastature, dok numerička polja sadrţe samo numeričke vrednosti, znakove + i – kao i decimalnu tačku. Datumska polja sadrţe datum. Kod većine baza je obezbeĎena automatska kontrola datuma. Logička polja sadrţe elemente Bulove algebre tj. logičko Da (T-True-istina) , logičko Ne (F- False – laţ), Y- yes – da, N – no- ne. Što se tiče MEMO polja ona su predviĎena da se u njih mogu smestiti tekstualne informacije. Što se tiče vrednosti memorijskih podataka oni mogu biti konstante i biće u tom slučaju posmatrane kao da su slova, a mogu biti karakteri, numerici ili pak prazna polja. Pored toga vrednosti memorijskih podataka mogu biti i promenljive i sluţe kako za smeštanje polaznih podataka tako i za smeštanje meĎurezultata. Pored toga memorijske promenljive se mogu definisati i kao nizovi koji sadrţe odgovarajući broj elemenata. Za davanje naredbi za izvoĎenje odgovarajućih operacija nad podacima koriste se odgovarajući simboli koji se nazivaju operatori i preko njih se definišu odgovarajuće operacije koje će se izvoditi kao naprimer sabiranje, oduzimanje, mnoţenje, deljenje itd.Operatori mogu biti aritmetički, logički, string kao i relacioni operatori. Pri kreiranju baze podataka veoma je bitno dobro definisati tip polja, jer su brzina rada, organizovanost podataka i veličina same baze u direknoj vezi sa ispravno definisanim tipom polja. Naprimer za datum tipa 01/05/2004 tip polja ćemo postaviti na Date/Time (datum/vreme); za isključivo numeričke vrednosti postavljamo tip polja 59
@ViPserbia
na Number; za kombinovani alfanumerički unos tip polja postavljamo na Text kod koga se predviĎa maksimalni broj karaktera u unosu, itd.
Slika 4.1 Primer jedne tabele u Accessu Baza podataka moţe da sadrţi više tabela koje se preko relacija meĎusobno povezuju. Npr. čitaoce ćemo drţati u jednoj tabeli, knjige u drugoj, a iznajmljivanja/vraćanja knjiga u trećoj. Relacije se uspostavljaju samo meĎu istovetnim podacima, a najčešće izmeĎu šifara (npr. šifru čitalaca u tabeli čitaoci_osnovni_podaci i šifru čitalaca u tabeli izdavanje_knjiga valja meĎusobno povezati relacijom jedan prema više - jedan čitalac moţe uzeti više knjiga, ali se jedna knjiga ne moţe nalaziti kod više čitalaca istovremeno). Na ovaj način se izbegava višestruki unos podataka za čitaoca pri svakoj njegovoj poseti biblioteci, a mogućnost grešaka pri unosu adrese ili naziva čitaoca je praktično anulirana.
4.2 Formulari – forms - ekranske forme maske za unos podataka ili za ažuriranje podataka Mnogi dobro uraĎeni programski paketi, koji se odnose na baze podataka, neće vredeti mnogo za korisnike ako su ekranske forme i meniji za rad sa bazom loše dizajnirani odnosno ako ih je teško koristiti u svakodnevnom radu. Kada je dobro organizovan i dizajniran sistem menija on značajno olakšava korisniku rad sa bazom. Nekada je (sa ranijim bazama) tj. kod klasičnog programiranja sistema menija izmena u nekom delu povlačila za sobom izmenu celog programa vezanog za menije.
60
@ViPserbia
Zbog toga se vremenom prešlo na sistem gde se struktura stabla menija čuvala u datoteci i zatim se ona koristila za kreiranje menija tako da bi program klizio po stablu po svim nivoima i gde bi se birala opcija za dati posao, a čije bi se ime takoĎe nalazilo u datoteci menija. Forma je u stvari samo "pogled" na tabelu u čoveku prihvatljivijem izgledu.
Slika 4.2 Primer jedne forme u Accessu
Nad formiranom tabelom koja sadrţi naprimer podatke o nekom čitaocu formira se maska za unos koja ima izgled papirnog obrasca - kartice, te operater korisnik ne mora da poznaje rad sa Accessom, nego samo koristi elektronske obrasce (maske) i unosi podatke primenom miša i pomoću tastature, baš kao što je to ranije činio olovkom ili u klasičnim programima. Veoma je značajna činjenica da forma za unos podataka moţe sadrţati slike, komandne tastere (pritiskom na koje moţe da se aktivira neka komanda kao što je naprimer štampanje trenutne kartice ili prelaz na drugu formu), moţe sadrţati odreĎena logička polja ili pak moţe sadrţavati odreĎenu podformu itd. Forma takoĎe ne mora da sadrţi niti jedno polje za unos ili prikaz podataka. Ona jednostavno moţe biti kreirani pozdravni ekran vza datu aplikaciju sa prigodnim tekstom i slikom, koji se posle isteka definisanog vremenskog intervala sam zatvara.
61
@ViPserbia
Takve forme mogu uzeti oblik pozdravne slike koja se pojavljuje prilikom starta nekog većeg programa, kao što se to često dogaĎa u programima paketa Microsoft Office. 4.3. Upiti – queries Osnovni upiti, sortiranje, selekcija, sloţene selekcije su najčešće aktivnosti koje se primenjuju od strane većine korisnika prilikom korišćenja neke baze podataka. Naime jedna od najvaţnijih dobrih osobina baza podataka jeste mogućnost da se brzo i jednostavno pristupi ţeljenim podacima. Upiti se mogu koristiti i za aţuriranje podataka u tabelama, ali taj deo će biti analiziran kasnije. Kada se koriste za biranje odreĎenih grupa podataka moraju se definisati odgovarajući kriterijumi po kojima će se podaci selektirati i grupisati radi prezentiranja korisniku. U stvari moţemo reći da su upiti posebni pregledi kojima se postavlja neki upit nad tabelom i koji izdvajaju podatke za pregled na ekranu ili štampanje putem izveštaja. Naprimer ukoliko ţelimo pregled svih narudţbina ostvarenih posle meseca januara u kriterijum za upit se moţe upisati >31.01.2000. Sem izdvajanja podataka postoje i posebni upiti koji mogu kreirati tabelu koristeći drugu tabelu ili više drugih tabela nad kojom je postavljen upit, odnosno mogu brisati podatke iz postojeće tabele takoĎe po nekom kriterijumu. Veoma često se podaci nalaze u različitim tabelama podataka i tada je potrebno da se obezbedi selekcija i grupisanje podataka iz svih tih tabela u saglasnosti sa definisanim kriterijumima. Upiti znači mogu filtirati podatke ne samo iz jedne tabele već se to moţe činiti iz više tabela ili čak iz jednog ili više drugih upita. TakoĎe mogu istovremeno filtrirati podatke po više kriterijuma.
4.4 Izveštaji – reports Izveštaj je grupa podataka koji su meĎusobno povezani na odgovarajući način. Oni sluţe da se korisniku baze mogu predstaviti potrebni podaci. Izveštaji mogu biti usmereni na ekran, na štampač ili u neku posebnu datoteku na neki poseban medij za kasniju upotrebu. Dobijanje izveštaja se ostvaruje primenom nekog od potrebnih programa ili primenom odgovarajućih generatora izveštaja kakve uglavnom poseduju novije baze podataka u svom asortimanu. MeĎutim ukoliko korisnik nije zadovoljan postojećom formom izveštaja koji su ponuĎeni od strane proizvoĎača baze programer moţe iskoristiti dobijene podatke u selektovanoj formi i u nekom od drugih programskih alata napraviti izveštaj po ţelji korisnika.
62
@ViPserbia
Podaci prikazani u izveštaju mogu biti izvedeni iz tabela ili iz upita (filtrirani podaci). Dizajniranje izveštaja je veoma slično dizajniranju formi, ali se priprema za selekciju podataka i generisanje izveštaja radi na sličan način i kao priprema upita.
Slika 4.3 Primer jednog upita u Accessu
Slika 4.4 Primer jednog izveštaja u Accessu 63
@ViPserbia
4.5. Spajanje relacija - spajanje tabela Veoma često je potrebno obezbediti odgovarajuće preglede podataka koji se nalaze u nekoliko različitih tabela podataka. MeĎutim povezivanje takvih tabela u jednu novu tabelu je moguće samo ako te tabele sadrţe zajednička polja. Ova polja su neophodna da bi se moglo izvršiti povezivanje i nazivaju se ključna polja. Neophodno je obezbediti da ova ključna polja imaju jednoznačne vrednosti bar u jednoj od tabela. Pri tome je neophodno da ova ključna polja na pravi način tj. nedvosmisleno obezbede identifikaciju datog zapisa u tabeli. Za veze odnosno moguće relacije izmeĎu tabela postoji više mogućnosti kao što su naprimer veza jedan prema jedan, jedan prema više, više prema jedan ili pak više prema više. Slika 4.5: Primer šeme "entieti-relacije" realizovane za potrebe aplikacije na Famu:
64
@ViPserbia
Slika 4.6: Primer šeme "entieti-relacije" realizovane za potrebe aplikacije na Famu:
65
@ViPserbia
4.6. Ažuriranje - unos, ispravka,brisanje, dodavanje novih podataka Unos Da bi se mogli unositi podaci u bazu podataka, a posebno kada to čini veći broj korisnika poţeljno je ili bolje rečeno potrebno je da se naprave odgovarajuće ekranske forme na kojima će se lepo kreirati ţeljeni oblik dokumenta za unos sa svim poljima koja korisnik treba da unosi. Pri tome se definišu tipovi podataka, odgovarajuće duţine polja, kao i odgovarajuće kontrole koje će obezbediti da korisnici sa što manje grešaka ili propusta unose potrebne podatke. Većina savremenih baza ima gotove odreĎene forme ekrana za unos koji se mogu u takvoj ili donekle izmenjenoj i po ţelji korisnika prilagoĎenoj formi koristiti. Ispravka Ukoliko je prilikom unosa korisnik napravio grešku i pogrešno uneo neki podatak ili neki njegov deo ili su pak odreĎeni podatak ili grupa podataka u bazi tokom vremena i promena koje ono nosi sobom postali nevaţeći ili neadekvatni tada je potrebno obezbediti mogućnost njihove ispravke delimične ili potpune ili pak kompletnog brisanja nekog podatka. Zavisno od programera koji realizuje aplikaciju na datoj bazi ove izmene ili ispravke se realizuju uglavnom primenom ekranskog formulara za unos pri čemu se vrši ili unosi samo ispravka ili se pak unosi ceo podatak iznova koji će prilikom aţuriranja prebrisati postojeći podatak koji je neispravan. Pri tome treba imati na umu da se ne mogu sve ispravke vršiti na takav način jer postoje u različitim bazama podataka i različite grupe podataka koje podleţu raznim propisima i dok je kod jednih podataka dozvoljeno da se nesmetano neispravan podatak zameni ispravnim kod grugih se mora ispoštovati odgovarajuća procedura. Veoma često je u takvim slučajevima potrebno da i neispravan i ispravan podatak ostanu u bazi kao evidencija o promenama u bazi ali sam krajnji korisnik kada pristupi bazi će dobiti na uvid samo poslednji ispravljeni podatak. Brisanje Kako je pomenuto u prethodnom pasusu ponekad je potrebno obrisati neki podatak u celini jer više nije vaţeći ili je bio ceo pogrešno unesen. Tada se primenjuje opcija brisanja koja omogućava korisniku da trajno izbriše neki podatak iz baze. Postoje takoĎe i podaci u bazama podataka za koje nije dozvoljeno brisanje jer neki podaci predstavljaju hronologiju ili istoriju nekih promena ili kretanja i ako bi se ti podaci izbrisali izgubio bi se tok promena. Sa druge strane postoje naprimer grupe knjigovodstvenih i drugih podataka koje se nikako ne smiju brisati i moraju ostati uvek u evidenciji sa svim mogućim greškama i ispravkama koje su unošene i za koje mora da postoji validna podloga – 66
@ViPserbia
dokument na osnovu čega se izvode. U suprotnom bi se omogućila manipulacija podacima koja nije dozvoljena niti po zakonu o knjigovodstvu niti po drugim zakonskim propisima. Dodavanje novih podataka Baza podataka je u većini slučajeva podloţana promenama ili zbog svakodnevnih promena vezanih za podatke koji se nalaze u bazama recimo baza kupaca, dobavljača, roba, knjiga itd. koje se sakodnevno moraju dopunjavati novima ili se pak u nekim bazama sa protokom vremena pojavljuju nove grupe podataka koje je potrebno uneti. Kao i kod prvobitnih unosa podataka u polaznu bazu i ovde se koriste ekranske forme za unos podataka koje omogućavaju korisnicima da mogu da unose i te nove podatke ili grupe podataka. Ubacivanje novih polja u bazu Ma koliko se kreatori baze trudili da prilikom kreiranja baze obuhvate sve potrebne podatke i polja koja će biti potrebna korisniku u eksploataciji baze uvek postoji mogućnost ili da je prevideo neko polje ili da se u toku eksploatacije baze pojavi potreba za ubacivanjem dodatnih polja. Dok je to kod ranijih baza ponekad predstavljalo problem i zahtevalo ozbiljnije zahvate u aplikaciji, današnje baze odnosno alati baza omogućavaju da se ubacivanje jednog ili više novih polja u bazu mogu izvoditi bez ikakvih problema. Na taj način je omogućen nesmetan razvoj baza u kladu sa ţeljama, zahtevima ili pak razvojem potreba ili obima poslovanja pojedinih korisnika. 4.7. Indeksi Indeksi predstavljaju odgovarajuće pomoćne strukture koje imaju zadatak da ubrzaju pristup podacima u bazi. Definisanje indeksa se vrši odgovarajućim naredbama što naravno zavisi od baze koja se koristi. Prilikom definisanja indeksa potrebno je navesti sledeće: naziv relacije, naziv polja nad kojim treba definisati indeks, odnosno za više njih ako se nad više polja definiše indeks, zatim je potrebno definisati dozvolu ili zabranu postojanja polja sa jednakim vrednostima podataka tj. mogućih duplikata. Ukoliko duplikati nisu dozvoljeni, a to je obično slučaj kada kombinacija polja predstavlja primarni ključ relacije, tada recimo nijedno od polja komponenata ne sme sadrţavati nula vrednosti. Indeksi se naprimer u nekim SUBP mogu definisati na dva načina: kao SORTED ili kao HASHED. U prvom slučaju indeks je struktura poznata kao hijerarhijska stablo, pri čemu se u samom indeksu, uz lokaciju zapisa odreĎene n-torke, dupliraju neki podaci iz polja/kolona nad kojima je indeks definisan. U drugom slučaju indeks je takozvana hash-tablica, kod koje se lokacija zapisa n-torke izračunava na osnovu vrednosti podataka u njoj; vreme pristupa trebalo bi da bude relativno konstantno, 67
@ViPserbia
dakle nezavisno od vrednosti podataka u n-torci. Nasuprot tome, kod indeksa u obliku stabla moţe se desiti da se neki zapis pronaĎe već na najvišem, prvom nivou stabla, a neki drugi na najniţem nivou stabla (dobro projektovana stabla obično imaju jednocifren broj nivoa, čak i za vrlo veliki broj n-torki). Indeksi u obliku stabla, imaju još jednu prednost: kod upita za koje je potrebna vrednost podataka samo iz onih polja/kolona nad kojima je indeks definisan, dovoljno je pročitati indeks, dok se samim n-torkama ne mora uopšte pristupiti. Kod indeksa u obliku hash-tablice, podaci iz n-torki uvek se moraju čitati. Za standardni SORTED indeks moţe se predvideti i veličina čvora u bajtima, procenat popunjenosti i način korišćenja indeksa. Naime, ako je namena indeksa u prvom redu brţi pristup pri pretraţivanju, onda je bolje da stranice indeksa budu u potpunosti popunjene: broj stranica biće manji, pa će biti manji i srednji broj stranica koje treba pretraţiti. S druge strane, ukoliko indeks valja koristiti pri aţuriranju, onda je bolje da stranice imaju i slobodnog prostora, jer će prilikom dodavanja novih ntorki broj prepakivanja indeksnih stranica biti manji. Ukoliko je baza raspodeljena na više fizičkih datoteka (multifileschema), iskazom STORE... moţe se zahtevati da indeks bude u jednoj ili više zona (storage area), kao i da se raspodela po zonama vrši bilo po slučajnom redosledu, bilo ravnomerno po svim raspoloţivim zonama. Treba primetiti da neke baze dozvoljavaju da se nad istim poljem/kolonom, ili kombinacijom polja/kolona, definiše i SORTED i HASHED indeks, budući da je prvi efikasniji kod upita kod kojih se traţi opseg vrednosti nekih podataka, a drugi ima prednost kod upita koji zahtevaju tačno slaganje nekih podataka. Reţijsko vreme potrebno za odrţavanje dva indeksa, meĎutim, veće je nego za odrţavanje samo jednog, pa i tu valja proceniti šta se više isplati. 4.8. Ključevi Ključevi su karakteristični podaci u svakom pojedinačnom redu neke transakcije ili stavke koji su nedvosmisleno vezani za odreĎenog kupca – šifra kupca, robu – šifra robe, dobavljača – šifra dobavljača, dokumenta – šifra ili broj dokumenta i preko kojih se cela transakcija moţe direktno dovesti u vezu sa datim kupcem, robom, dobavljačem ili dokumentom. UvoĎenje ključa je bilo prisutno i kod konvencionalnih – klasičnih datoteka iz istih razloga, a sa prelaskom na baze podataka kao viših integrisanih oblika klasičnih datoteka je dobilo još više na zbačaju. Mogu se koristiti jedan ili više ključeva, pri čemu ako ih je više onda je jedan primarni, a ostali su sekundarni. Kod selekcionisanja, grupisanja i pretraţivanja podataka kjučevi nalaze svoju punu primenu jer su oni pored drugih kriterijuma koje korisnici postave jedan od osnovnih elemenata po kojima se vrši selekcija i sortiranje.
68
@ViPserbia
4.9. Pretraživanja, sortiranja, selekcija Mada je ovaj segment delimično spomenut u okviru upita zbog njegove vaţnosti daćemo neka dodatna objašnjenja. Baze podataka su i dobile svoju punu vrednost u odnosu na druga klasičnija rešenja baš zbog činjenice da su omogućile laka i jednostavna pretraţivanja, sortiranja i selekcije podataka po različitim i često veoma sloţenim kriterijumima, od kojih poneki nisu ni bili predviĎeni u fazi kreiranja baze, nego su se naknadno pojavili kao neminovnost i potreba u datom trenutku vremena ili poslovanja neke firme ili institucije. Lepota u primeni baza podataka je baš u činjenici da se kod većine baza mogu obezbeĎivati najrazličitiji pregledi na osnovu odgovarajućih pretraţivanja, selekcija ili sortiranja podataka u bazi, po odgovarajućim kriterijumima koje korisnici mogu kombinovati od slučaja do slučaja prema trenutnim potrebama ili zahtevima posla. 4.10 Makroi i VBA Makroi i moduli načinjeni primenom VBA – Visual Basic for Applications visual basic za aplikacije - predstavljaju dve dodatne mogućnosti koje se mogu koristiti prilikom izrade aplikacija u nekim bazama kao i kod primene Accessa.
Slika 4.7 Primer pozivanja VBA u Accessu Naime često se javlja potreba za korišćenjem grupisanih naredbi koje su obuhvaćene pojedinim modulima ili pak za formiranje funkcija koje ne postoje u 69
@ViPserbia
datoj bazi ili se pak grupe funkcija moraju vezati u jedan sloţeniji sklop, te se za razvijanje i automatizovanje baze podataka mora pristupiti pisanju programa. Makroima se iz konačnog skupa funkcija i naredbi automatizuje rad baze; meĎutim, njihovo korišćenje se u novijim aplikacijama sve više izbegava, jer se puna sloboda i funkcionalnost ostvaruju primenom VBA. Makroi, zapravo, postoje uglavnom zbog kompatibilnosti sa prethodnim verzijama Accessa i drugih baza.
70
@ViPserbia
5. Razvoj aplikacija primenom Microsoft Access-a Microsoft Access je program za rad sa bazama podataka firme Microsoft. Microsoft Access se pojavljivao u raznim modelima od kojih su u poslednje vreme aktuelni Access97, Access2000, Access2002, Access2003, sa više desetina miliona prodatih kopija. Access 2003 je ovog časa najnovija varijanta i dolazi u paketu sa Microsoft Office XP Professional Iako je u početnim verzijama bio prilično nesavršen, program je danas prerastao u ozbiljan paket za razvoj aplikacija kod kojih je osnova baza podataka. Dok se nekada programirala svaka operacija nad bazom, u Accessu je danas većina stvari automatizovana i uz oslanjanje na odreĎene alate operativnog sistema do gotove, jednostavne baze, se često dolazi koristeći isključivo rad sa mišem i primenom raznih pomoćnih alatki (čarobnjak – wizard) bez napisane gotovo ijedne linije programskog koda. Napomena: Namena ovog uputstva za primenu Accessa je da se studenti Fakulteta za menaţdment uvedu u osnove rada sa Microsoft Access softverom za rad i upravljanje sa relacionom bazom podataka. Osnovni razlog je njegova rasprostranjenost na trţištu, jednostavnost razvoja baze podataka, jednostavnost rada i odrţavanja. MeĎutim ono što je najvaţnije je da primena nekih od ovde navedenih principa vaţi za sve relacione baze podataka bez obzira na to ko su njihovi proizvoĎači, takoĎe način definisanja i postavljanja aplikacije u bilo kojoj od tih baza je gotovo identičan. Razlika je više izraţena u pojedinim dodatnim alatima, wizardima, Cases – kejsovima koji se dobijaju uz pojedine baze pa je aplikacije nešto teţe ili lakše projektovati I kreirati. Bitno je da se studenti osposobe i nauče da naprave sami pojedine aplikacije u bazi, da uoče najvaţnije stvari o kojima se mora voditi računa pri takvom radu, da nauče o čemu moraju voditi računa u mreţnom ili distribuiranom radu ili pak nadzoru ili zaštiti baze, a svaki od njih će na svom budućem radnom mestu gde budu radili imati prilike da se iz dokumentacije upozna detaljnije sa specifičnostima pojedinih baza koje se budu koristile u njihovim preduzećima. 1) Ovo uputstvo za rad je bazirano na Help funkcijama koje su ugraĎene u Microsoft Access 2000 softveru kao deo Microsoft Office 2000 paketa. 2) Uputstvo je namenjeno za potrebe obučavanja studenata, a dato je na primeru projekta voĎenja biblioteke Fakulteta za menadţment u Novom Sadu (kao jedno od mogućih rešenja). 3) Sva imena i informacije koja su u ovom uputsvu upotrebljena su hipotetička. 71
@ViPserbia
5.1. Uvodne informacije - uputstva Ovo uputstvo je predviĎeno za rad sa Microsoft-ovim Accessom iz paketa Office 2000. Microsoft Access će se nadalje u tekstu označavati kao Access jer se aplikacije mogu razvijati na veoma sličan način i u Accessu 2003 kao i u Accessu 97. U ovom uputstvu će biti prikazan rad sa tabelama, formama, izveštajima i upitima. Tokom instalacije Accessa, obično se instaliraju se i primeri koji se isporučuju uz dati tip Accessa kao naprimer Northwind uz Access 97 ili pak Sweet Lil’s uz Access 2000 tako da se i ovaj primer moţe koristiti za usavršavanje rada sa Accessom. Primer biblioteke se u ovom uputstvu koristi kao osnova za razvoj jedne jednostavne baze podataka. Pretpostavka je da su studenti koji će koristiti ova uputstva već familijarni u radu sa operativnim sistemima koje Microsoft isporučuje trţištu kao što su Windows '95, Windows '98, Windows NT / 2000 ili Windows XP. U okviru toga znanja očekuje se i poznavanje rada sa tastaturom i mišem. Pretpostavka je da studenti korisnici poznaju i rad sa disketom, kao i da znaju da koriste Windows Explorer (pronalaţenje datoteka, kopiranje, brisanje, izradu posebnih fascikli za svoje potrebe [folder], minimiziranje i maksimiziranje prozora te njegovo zatvaranje, startovanje programa bilo sa radne površine Windowsa preko odgovarajućih ikona ili preko Start Programs menija, ...). Danas je kod nas najšire rasprostranjena upotreba Access 2000, mada su i Access 2002 odnosno 2003 sve više u upotrebi. Većina današnjih arhitektura odnosno organizacija podataka u bazama podataka su relacionog tipa i nudi se ceo dijapazon softvera za upravljanje relacionim bazama podataka, a tu spada i Access. On je namenjen za mala pa i srednja preduzeća. U nastavku je dat primer razvoja jedne baze podataka sa pratećim detaljima o tome kako se izraĎuju tabele, forme, izveštaji i upiti, a to se sve preko raznih mogućnosti koje nudi Access moţe upakovati u jednu poslovnu aplikaciju.
72
@ViPserbia
5.2 Primer razvoja aplikacije (iz poslovne prakse) U ovom poglavlju dat je jedan primer iz poslovne prakse koji će omogućiti da se na osnovu njega prati rad kroz ovo uputstvo. Kod svake poslovne organizacije, sprovode se postupci analize posla, definišu se odgovarajuće strukture baze podataka, a sve to se pod jednim zbirnim nazivom naziva "Sistem analiza". U teoriji se danas koriste i drugi nazivi tehnika projektovanja informacionih sistema poslovnih organizacija. Sistem analitičar ima zadatak da prikuplja informacije o tome kako se odvijaju poslovni procesi odnosno aktivnosti i na osnovu takvih informacija da formira model podataka. Preko modela podataka se izačunava, procenjuje kapacitet memorije (diskova), Preko modela podataka, programer bez podataka će formirati tabele u bazi podataka i one se onda koriste u aplikaciji da bi se zadovoljio zahtev za informacijama koji je postavljen od strane korisnika aplikacije, odnosno predstavnika poslovne funkcije. Razmotrimo kao primer rad jedne male banke. Pretpostavimo da banka ima nekoliko klijenata koji otvaraju i rade sa jednim ili više računa. Za svakog klijenta se čuvaju podaci o imenu, adresi i mestu sedišta odnosno stanovanja. Jednom klijentu se pridruţuje jedinstveni identifikator KlijentID koji po nalogu progamera moţe da se generiše i mašinski (računarski). Ovaj identifikator je potreban da bude jedinstven jer se moţe desiti da u banci se pojave dva klijenta sa istim imenom i prezimenom. Sličnim postupkom, svim računima se dodeljuje pripadajući vlasnik preko jedinstvenog identifikatora vlasnika, a svaki račun dobija svoj jedinstveni identifikator tj. broj tekućeg računa odnosno broj partije preko koje klijent banke realizuje svoje finansijske transakcije. Tip računa opredeljuje i vrstu transakcije sa računom jer otplata stambenog kredita nije isto što i štednja po viĎenju. Dali smo primere tabela za klijente i račune ("Klijenti" i "Racuni"). One će nam biti podloga za razvoj jedne poslovne - bankarske aplikacije. U bilo kojoj aplikaciji za rad sa bazom podataka, koriste se termini obuhvata podataka: upis novog, aţuriranje postojećeg, brisanje postojećeg i uvid u stanje sloga u tabeli baze podataka uz eventualno štampanje. Da bi se obuhvat podataka realizovao koriste se forme za obuhvat podataka. Da biste dobili podatke izvučene iz tabela sa takozvanim filterima i / ili da ih štampate potrebno je koristiti mehanizme izrade upita (query) i izrade izveštaja (report). Ovde će biti pokazan primer kako se pravi jedna forma za svaku tabelu, kako se pravi upit za svaku tabelu i kako se prave izveštaji za svaku od navedenh tabela. U nastavku, ćemo početi od toga kako se polazi od takozvane prazne (odnosno nove) baze podataka uz pomoć MS Access-a 2000. 73
@ViPserbia
5.3. Pokretanje rada Microsoft Access 2000 Postoje razni načini navigacije kroz Windows da se aktivira pristup MS Access-u. Prikazane su neki od mogućnosti. Pristup Access-u preko radne površine Windowsa (desktop):
Slika 5.1 Primer pozivanja Accessa Napomenimo da je izgled radne površine različit od raznih vlasnika personalnih računara. Aranţmani menija zavise od toga kako je instaliran Microsoft Office 2000 paket, a zavise i od tipa personalnog računara odnosno verzije Windowsa. Druga mogućnost je da se preko dugmeta "StartProgramsAccess" doĎe do startovanja rada u Access-u. Pogledaćemo sledeći primer:
74
@ViPserbia
Slika 5.2. Primer pozivanja Accessa - StartProgramsAccess ili
Slika 5.3. Primer pozivanja Accessa iz menija Offisa
75
@ViPserbia
Čim je Access pokrenut, pojave se inicijalni ekrani na kojima se biraju obrasci rada (template):
Slika 5.4. Primer a menija za pozivanje odgovarajućih template iz menija Accessa Kod pokretanja rada sa Access-om, mogu se koristiti i unapred definisani obrasci (template) za izradu sopstvene baze podataka, pri čemu se spretniji programeri mogu pozabaviti i modifikacijama tako generisanih baza podataka odnosno njenih sadrţaja (tabele, forme, izveštaji, upiti).
Slika 5.5. Primer b menija za pozivanje odgovarajućih template iz menija Accessa 76
@ViPserbia
Slika 5.6. Primer menija za izbor odgovarajućih template iz menija Accessa Od ovog početnog ekrana, korisnik Accessa moţe početi sa formiranjem nove baze podataka (bilo da je ona prazna - BLANK ili je zasnovana na nekom od postojećih modela - obrazaca. Kada se započinje novi projekat onda je poţeljno da se započne sa izradom "prazne" baze podataka. Nakon toga se tako formirana baza svaki put "poziva" (otvara) da bi se u njoj vršile modifikacije (ako je u pitanju odrţavanje baze podataka) ili da bi se koristila za potrebe poslovanja. Ako je korisnik ranije kreirao bazu podataka i kreira novu sa istim imenom biće upozoren da moţe prebrisati postojeću. Potrebno je proći sve ove korake pa izabrati kreiranje nove, prazne baze podataka (new, blank) kao što je prikazano na napred datim slikama. Zatim je potrebno izabrati Blank Database i kliknuti na OK dugme te nastaviti sa praćenjem ekrana koji slede odnosno uneti polje ime baze podataka File Name kao bankdb.mdb i kliknuti na dugme Create:
77
@ViPserbia
Slika 5.7. Primer za izbor banka baze – bankdb.mdb iz menija baza Accessa bankdb je ime konkretne baze podataka a .mdb je rezervisano ime ekstenzije naziva datoteke kojom Microsoft obeleţava Access-ove baze podataka. Postoje sintaksna pravila u dodeli naziva baze podataka kao što su makismalna duţina naziva datoteke, zabrana korišćenja nekih specijalnih simbola kao što su znak praznine (space), znakovi punktuacije (, . ? itd.). Pored toga, preporučuje se da naziv baze podataka odraţava i sadrţaj baze podataka. U zavisnosti od verzija instaliranog Access-a moţe se pojaviti jedan od sledećih ekrana: MS Access '97
Slika 5.8. Primer menija za rad sa bazom u Accessu 97 ili
78
@ViPserbia
MS Access 2000
Slika 5.9. Primer menija za rad sa bazom u Accessu 2000 Na ovim glavnim ekranima se preko odgovarajućeg menija nude dve mogućnosti, ukoliko se nalazite na objektu "Table" u glavnom ekranu Access-a. Meniji su veoma slični Word-u i Exel-u Meniji uključuju sledeće:
File - Stavke ovog menija su funkcije Open, Close, Create new, Save i Print baze podataka i njenog sadrţaja. U ovom meniju je i funkcija Exit za izlazak iz Access-a. Edit - Funkcije su Cut, Copy, Paste, Delete View - Uvid (upit) u razne objekte baze podataka (tabele, upiti, forme izveštaji) Insert - Insert nove tabele, upita, forme, izveštaja itd. Tools - Skup alata kao što su overa pravopisa, izrada relacija izmeĎu tabela, obavljanje analize performansi baze podataka i izveštavanje o sadrţaju baze podataka (aplikativni deo, a ne deo o podacima). Window – Korisnik se moţe prikoključivati na različite baze podataka koje su u isto vreme otvorene. Help - Ukoliko korisniku nešto nije jasno moţe koristiti pomoć o Access-u – Help (u zavisnosti od instaliranog Access-a to moţe biti ili na maternjem jeziku ili na engleskom)
79
@ViPserbia
Glavni tab u glavnom prozoru uključuje sledeće: Tables - Prikazi skupa svih tabela sačuvanih u bazi podataka Queries - Prikazi skupa svih upita sačuvanih u bazi podataka Forms - Prikazi skupa svih formi sačuvanih u bazi podataka Reports - Prikazi skupa svih izveštaja sačuvanih u bazi podataka Macros - Prikazi skupa svih privatnih (koje ste vi napravili) makroa (kratki programi koji su pisani internim makro jezikom Access-a), a sačuvani u bazi podataka Modules - Prikazi skupa svih sopstvenih modula (pisanih u VBA-Visual Basic for Applications jeziku), a koji su sačuvani u bazi podataka.
U MS Access 2000 ovi tabovi se pojavljuju na levoj strani glavnog ekrana koji se pojavljuje kao default. MS Access 2000 ima mogućnosti da radi i sa Web Pages (Web stranicama) i sa Favorites, ali ove mogućnosti nisu ovde obuhvaćene. Ovde će biti obuhvaćene sledeće teme: * Tables (tabele) * Queries (upite) * Forms (forme za obuhvat podataka) i * Reports (izveštaji). U nastavku je dat kratak pregled aktivnosti za početak rada sa Microsoft Access-om: 1. Koristi se dugme "Start" u donjem levom uglu trake za poslove (task bar) Windowsa na sledeći način Programs MS Office Microsoft Access 2. Napraviti novu bazu izborom Blank Database i dodeliti ime datoteke u koju će biti smeštena nova baza podataka (ne mora se kucati i ekstenzija .mdb). Klikom na Ok tipku -dugme obavljeno je kreiranje baze podataka. 3. Za otvaranje postojećih baza podataka koristi se funkcija Open an Existing Database a ukoliko imate dopunsku poruku More Files... (ima još ... - zahtev za više fajlova - datoteka) onda kliknite na OK dugme. Navigacionim pomagalima dolazi se do ţeljenih baza podataka. Za napuštanje Access-a koristi se funkcija File i odabirom stavke Exit.
80
@ViPserbia
5.4
Izrada tabela
Tabele su glavne jedinice za smeštanje odnosno pamćenje podataka u Access-u. Tabele se sastoje od jedne ili više kolona (ili polja) pri čemu jedna kolona u jednoj tabeli moţe da bude relacija sa nekom kolonom u drugoj tabeli (ili tabelama). Iz razvijenog primera se zaključuje da imamo dve tabele koje bi trebale da budu dovoljne da se smeste podaci o klijentima mini banke Klijenti i podaci o njihovim računima (ako ih imaju) Računi. Sada ćemo objasniti korak-po-korak kako se prave ove dve tabele u Access-u. Najjednostavniji način za izradu tabela u Access-u je upotreba takozvanog čarobnjaka (wizard) koji vode korisnika Access-a, predlaţući mu imena za tabele i kolone. Drugi način izrade tabela jeste upotreba funkcije Design View kojom se "pešački" definišu kolone (polja) u tabeli i njihovi tipovi podataka. Iako se čini da je sa čarobnjacima brţi način formiranja tabela, korisnik (pogotovo ako je iskusniji) ima slabiju kontrolu nad imenima kolona i tipovima podataka. Ovde ćemo opisati "pešački" način izrade tabele pomoću funkcije Design View. Studentima se preporučuje da sami više eksperimentišu sa čarobnjakom Create Table. 5.4.1. Izrada tabele korišćenjem "Design View" Da bi se moglo doći do funkcije Design View, mora se doći do taba Tables (videti mogući izgled ekrana na sledećoj slici): 1. Duplim klikom na "Create Table in Designe View" i klikom na dugme Ok pojaviće se sledeći ekran:
Slika 5.10. Primer izbora opcije Design View u meniju za rad sa tabelama 81
@ViPserbia
2. Sledi ekran sa nazivima specijalnih kolona Field Name (Ime polja), Data Type (Tip podataka) i Description (opis) za svaku kolonu (polje) u tabeli koju ćemo sada kreirati. Polje KlijentID se kreira kao što je prikazano:
Slika 5.11. Primer rada sa tabelama u meniju Design View u Accessu 2000 Treba napomenuti da Access nudi podrazumevano (default) ime tabele Table1. Ono se moţe promeniti odmah ili kasnije (pokazaćemo kako). Popunićemo informacije za preostale kolone u skladu sa sledećim opisom: Field Name Data Type Description KlijentID Number Jedinstveni identifikator klijenta minibanke BLUE HILLS Ime_i_Prezime Text
Ime i prezime klijenta
Adresa
Text
Adresa klijenta
Mesto
Text
Mesto stanovanja klijenta
Drzava
Text
Drţava stanovanja klijenta
Post_Broj
Text
Poštanski broj mesta stanovanja klijenta
Slika 5.12. Primer definisanja polja za tabelu Klijenata Finalna kreacija u DesignView funkciji je prikazana na sledećem ekranu - slici:
82
@ViPserbia
Slika 5.13. Primer popunjenih – definisanih polja u tabeli Klijenata 3. Sada kada imamo definisana sva polja tabele, odreĎujemo primarni ključ (indeks) Primary Key i to prvo desnim klikom na polje KlijentID, a zatim u padajućem meniju odaberemo Primary Key kao što je pokazano na sledećoj slici.
Slika 5.14. Primer definisanja primarnog ključa u tabeli Klijenata
83
@ViPserbia
Posle ovoga se u imenu ove kolone sa leve strane pojavljuje simbol malog ključića. Da biste izbacili definiciju primarnog indeksa, treba opet ponoviti proceduru te isključiti Primary key. Dobro je znati da sa F6 funkcijskom tipkom moţe prelaziti iz FiledName u detalje definisanja obeleţja (svojstava) te kolone. 4. Konačan korak postupka je da se tabela sačuva, a to se radi tako što se u padajućem meniju File izabere stavka Save. U dijalogu sa korisnikom Access nudi ime tabele koju korisnik ţeli sačuvati pri čemu da podestimo Access uvek nudi nešto kao Table1, Table2, itd. Korisnik jednostavno prbriše ponuĎeno ime sa imenom koje smo definisali u projektu male banke: Klijenti te klikom na dugme Ok potvrdi upis definicije tabele u bazu podataka bankdb.mdb.
KLIJENTI
Slika 5.15. Primer – primena funkcije Save na tabelu KLIJENTI Vratimo se ponovo na glavni meni Access-a u funkcijski meni File i odabirom funkcije Close (zatvori) odabrali smo da se zatvori DesignView za tabele i pogledajmo efekat koji je pokazan na sledećoj slici:
Slika 5.16. Primer – izbor tabele KLIJENTI u osnovnom meniju baze
84
@ViPserbia
Treba zapaziti da je veoma bitno da se pri definisanju naziva polja (kolona) odrede jasna imena polja i tabela koja na neki način odraţavaju njihov sadrţaj. Na primer, na šta vas naziv polja BK upućuje, na Broj Klijenta ili Broj kontejnera? U Access-u se mogu koristiti imena polja maksimalne duţine 64 znakova. a ona mogu sadrţati i znak "prazno". MeĎutim, znakove "prazno" u nazivima polja i tabela bi trebalo izbegavati (ovo je praksa pokazala). Moţe se koristiti i donja crtu (underscore) karakter radi lakše čitljivosti naziva polja i tabela odnosno kao znak za razdvajanje kao naprimer Sifra_Korisnika ili Ime_i_Prezime itd (naravno, uz izbegavanje znaka "prazno"). U sledećoj tabeli su dati neki primeri različitih označavanja imena polja: Opis Jedinstveni identifikator korisnika
Loše
Opis proizvoda
PDESC
Kućni telefon zaposlenog
Employee_home_telephone_number HomePhone
Račun u banci
BA#
AccountNumber
Naslov knjige
Tit
Book_Title
Slika naslovne strane
Pic
Cover_Picture
CID
Dobro CustomerID ili Customer_ID ProductDescription
Slika 5.17. Primeri označavanja imena polja Primer - Izrada tabele Sada ćemo kao primer napraviti tabelu računa pod nazivom Racuni koristeći iste korake kao kada smo kreirali tabelu Klijenti. 1. Kliknite na dugme New i odaberite Design View u dijalog prozoru koji se pojavio i potom kliknite na dugme Ok. 2. Pojaviće se prozor "Table Design View" (koji je ranije opisan). Popunićemo Field Name, Data Type i Description za svaku kolonu (polje) tabele Accounts kako je to pokazano u tabeli na slici 5.18. 3. Na sledećoj slici 5.19. je prikazan finalni rezultat novo kreirane tabele popunjene na napred navedeni način.
85
@ViPserbia
Field
Name Naziv polja
Data Type Description Tip podataka Opis
KlijentID
Number
Jedinstveni identifikator korisnika (klijenta)
Broj_Racuna Number
Jedinstveni identifikator bankovnog računa (broj partije)
Vrsta_Stednje Text
Tip računa (Čekovi, štednja, kredit, itd.)
Dat_Otvaranja Date
Datum otvaranja računa
Saldo
Trenutni saldo računa u tekućoj valuti zemlje (npr. CSD meĎunarodna oznaka za dinar drţavne zajednice SCG)
Number
Slika 5.18. Primeri popunjavanaja polja tabele
Slika 5.19. Primeri popunjavanaja polja tabele – Design View Definisaćemo primarni ključ u tabeli Racuni. Na polju Broj_Racuna desnim klikom odaberaćemo iz padajućeg menija Primary Key.
4.
5. Sačuvaćemo ovako kreiranu novu tabelu pod imenom Racuni (preko File menija i izborom funkcije Save). Popunićemo ime tabele sa Racuni i potom kliknuti na dugme Ok.
86
@ViPserbia
5.4.3. Pregledanje i dodavanje podataka u tabelu Podaci u formiranim tabelama se mogu dodavati, brisati ili modifikovatgi upotrebom ekrana u takozvanom spreadsheet obliku. U nastavku ćemo pokazati kako se to realizuje. Jednostavno kliknućemo na ime tabele i na taj način kao da smo dozvali Open dugme. Na sledećoj slici je prikazano kako to izgleda a tabela izgleda kao neka tablica (spreadsheet) po kojoj se moţe šetati:
Slika 5.20. Primer - spreadsheet izgled tabele Zapazimo da imamo specijalnu traku Record u donjem delu porzora kojom pratimo, navigiramo kroz tabelu. Ovde se vidi koliko maksimalno ima slogova (odrednica "of n"), a broj ukazuje na trenutnu vidljivu poziciju u otvorenoj tabeli. Kako je tabela otvorena prvi put onda je normalno da je ona prazna i da je KlijentId generisan kao 0. Da bi dodali podatke u tabelu, jednostavno kucamo vrednosti svakog polja i sa tipkom Tab krećemo se unutar reda, a primenom tipke strelice kao , , itd. krećemo se izmeĎu slogova u tabeli. Unećemo odreĎene vrednosti i odmah videti efekte:
87
@ViPserbia
KlijentID Ime_i_Prezime
Adresa
Mesto
Number
Character
Character
Character Character Character
1001
Jovan Jovanović
Vase Stajića 3
Novi Sad
SCG
21000
1002
Petar Petrović
Stevana Sremca 23 Zrenjanin SCG
23000
1003
ĐorĎe Arsenijević Humska 23
1004
Ana Bodor
Petefi Šandora 3
Drzava
Post_Broj
Beograd
SCG
11000
Subotica
SCG
24000
Slika 5.21. Primer - izgled tabele Klijenti
Slika 5.22. Primer - izgled tabele Klijenti – Design View Sačuvaćemo unete podatke funkcijom Save u padajućem meniju File. Osim prethodno pomenute navigacije, postoji i specijalna samogovoreća navigaciona traka:
Slika 5.23. Primer - izgled navigacione trake
88
@ViPserbia
Za modifikaciju postojećih podataka, moraćemo navigirati do sloga koji menjamo. Za brisanje sloga moramo doći do tog sloga, a onda u padajućem meniju Edit odabrati funkciju Delete. Zatvorićemo svaku promenu u tabeli i vratiti se na glavni ekran Access-a. (padajući meni File, a potom aktivirati funkciju Close. Kao primer otvorićemo tabelu računa Racuni i dodati podatke o računima prikazanim ranije u tabelama. Pri tome moramo biti paţljivi da tačno unosimo podatke (uključujući i voĎenje računa o tome da li su slova mala ili velika), a naročito kod vrste računa jer Savings nije isto što i SAVINGS. Kada unosimo datume godinu ćemo kucati sa 4 cifre. Access prikazuje samo 2 cifre što je po defaultu – podrazumevano, ali se kao opcija Access-a ovo moţe menjati). Pri tome se u tabeli sačuvaju sve 4 cifre godine. Kada smo sve uneli onda ćemo sačuvati podatke unete u tabelu računa Accounts.
Slika 5.24. Primer - izgled tabele Racuni Prema tome do sada smo naučili - da pravimo tabele, i - da unosimo podatke, menjamo sadrţaje i eventualno brišemo podatke u tabeli. U nastavku ćemo da vidimo kako se prave upiti i izveštaji primenom Accessovih čarobnjaka 89
@ViPserbia
5.5 Izrada relacija izmeĎu tabela Treba imati na umu da je glavna karakteristika svih relacionih baza podataka postojanje relacija izmeĎu pojedinih tabela. U maloj banci, koju smo uzeli za primer, tabela Customers je u relaciji sa tabelom Accounts strogom vezom izmeĎu polja CustomerID u obe tabele. U Access-u postoji posebna alatka kojom se uspostavljaju relacije izmeĎu tabela korišćenjem ekrana Relationships. Pri tome treba imati na umu da Access sve informacije koje navedemo u dijagramu entiteta i realcija (E-R dijagrami) koristi kod izrade izveštaja, formi i upita i da će čak traţiti da koristimo delove dijagrama. U traci alata koje nam Access nudi, odaberaćemo funkciju Relationships da bi smo pozvali ţeljeni alat:
Slika 5.25. Primer – izbor podmenija za definisanje relacija
90
@ViPserbia
Slika 5.26. Ekran podmenija za definisanje relacija Da bi smo napravili dijagram moramo imati spisak tabela i odabirom korak-pokorak uspostavljati relacije preko primarnih ključeva. Desnim klikom na bilo koji deo ekrana Relationships odaberaćemo Show Tables... opciju za prikaz svih tabela koje imamo u bazi podataka:
Slika 5.27. Meni za izbor prikazivanja tabela Kada se pojavi dijalog kutijica Show Table osvetlićemo (odabrati) obe kreirane tabele i pritisnuti dugme Add:
91
@ViPserbia
Slika 5.28. Meni za izbor odgovarajuće tabele Posle toga ćemo klikom na dugme Close zatvoriti kutijicu za dijalog. Ekran Relationship će imati izgled kao na sledećoj slici:
Slika 5.29. Primer - izbor odgovarajućih tabela koje ţelimo povezati Da bi smo povezali ove dve tabele Klijenti i Racuni i na taj način formirali relacije, kliknućemo na polje KlijentID u tabeli Klijenti i prevući preko polja
92
@ViPserbia
KlijentID u tabeli Racuni. OslobaĎanjem miša dijalog kutijica Edit Relationships će izgledati kao na sledećoj slici:
Slika 5.30. Primer - izbor odgovarajućih tabela koje ţelimo povezati Access će učiniti sve što je najbolje da definiše tip relacije (u većini slučajeva to su relacije 1:M One-to-Many). U ovom slučaju, Access zna da je KlijentID primarni ključ tabele Klijenti i na taj način smo izabrali stranu tabele "1" ("One"). Povezivanjem sa drugom stranom u tabeli Racuni izabrali smo stranu "više" ("Many") tako da imamo relaciju 1:M odnosno za jednog korisnika moţemo imati M otvorenih računa, uzimajući u obzir i slučaj da nema otvorene račune. Osim relacije 1:M postoje još dve relacije 1:1 ("jedan prema jedan") ili M:M ("mnogo-prema-mnogo"). Treba napomenuti da se relacija M:M postupkom normalizacije na naprimer takozvanu 3 normalnu formu eliminiše, a na taj način se kontroliše i redundancija u bazi podataka. Sledeći korak je da overimo ili obezbedimo mogućnost očuvanja referencijalnog integriteta podataka "Enforce Referential Integrity". Ova opcija uvodi ograničenja takva da slogovi tabele Racuni ne mogu biti formirani bez ispravno formiranih slogova u tabeli Klijenti, a sa druge strane Access će sprečiti bilo kakvo brisanje sloga u tabeli Klijenti, ako taj slog ima neku relaciju sa postojećim slogovima u tabeli Racuni. Brisanje je moguće samo ako korisnik, to potvrdi na upozorenje Accessa. Ovde ćemo kliknuti na dugme Create i na taj način je okončana izrada relacije. Ekran Relationships bi trebalo da se ponovo pojavi, ali sa ubačenom relacijom izmeĎu dve tabele kao što je to prikazano na sledećoj slici:
93
@ViPserbia
Slika 5.31. Primer - izgled povezanih tabela koje smo ţeleli povezati Treba uočiti da simbol "1" (ukazuju na stranu "One"), a simbol beskonačnosti ∞ (ukazuje na stranu "Many") u relaciji 1:M. Na kraju je potrebno zatvoriti ovaj ekran relacije i odabrati dugme Yes da bi sačuvali promene u obrascu Relationships. Ako se kojim slučajem ne pojavi slika relacija na napred prikazani način to znači da ste negde pogrešili u definisanju relacije. Da bi se to poprevilo osvetlite veznu liniju i pritisnite tipku delete pa obrišite loše formiranu relaciju. Tada se vratite na tab za tabele, pogledajte u Design view i proverite da li je polje KlijentID kreirano kao ključ tabele Klijenti. Ako to nije slučaj, izvršite korekciju i ponovite aktivnost sa ekranom za relacije Relationships pa napravite relaciju. Na kraju ćemo rezimirati preĎenu temu. Ukratko moţemo reći da izrada nove tabele zahteva da se obave sledeće aktivnosti: 1. Kliknite na Tables tab na glavnom ekranu Access-a 2. Kliknite na dugme New 3. Odaberite funkciju Design View i kliknite na dugme OK 4. Popunite imena kolona, tip podataka i opis kolona (ova kolona nije obavezujuća) za svaku kolonu nvoe tabele 5. Odredite i obeleţite primarni ključ desnim klikom na polje u tabeli koje postaje primarni ključ i onda iz padajućeg menija izaberite funkciju Primary Key. 6. Sačuvajte tabelu izborom funkcije Save u padajućem meniju File. 94
@ViPserbia
7. Zatvorite novo formiranu tabelu izborom funkcije Close u padajućem meniju File. Ako ţelimo da promenimo opis postojeće tabele (naprimer da se doda, promeni ili obriše polje potrebno je da uradimo sledeće): 1. Kliknite na Tables tab na Access-ovom glavnom ekranu 2. Osvetlite ime tabele koja se modifikuje i kliknite mišem na dugme Design view. 3. Napravite potrebne promene u definicijama kolona tabele ili dodajte novu ili obrišite postojeću. 4. Sačuvajte tabelu izborom funkcije Save u padajućem meniju File. 5. Zatvorite novo formiranu tabelu izborom funkcije Close u padajućem meniju File. Za dodavanje, brisanje ili izmenu podataka u postojećoj tabeli potrebno je sledeće: 1. Kliknite na Tables tab na Access-ovom glavnom ekranu 2. Osvetlite ime tabele koja se modifikuje i kliknite mišem na dugme Open. 3. Napravite potrebne promene u podacima. 4. Sačuvajte tabelu izbor funkcije Save u padajućem meniju File. 5. Zatvorite novo formiranu tabelu izborom funkcije Close u padajućem meniju File Izrada ili editovanje relacija izmeĎu tabela: 1. Dozovite padajući meni Tools i odaberite funkciju Relationships. 2. Za prikaz spiska tabela, desnim klikom pozovite poseban dijalog kutijicu i daberite Add Tables 3. Za izradu nove relacije, prevucite preko polja ključa iz jedne tabele u drugu tabelu i otpustite nad asociranim poljem druge tabele. 4. Da biste editovali postojeću relaciju, dvostrukim klikom preko relacione linije pozovite potreban dijalog. 5. Da biste obrisali postojeću relaciju, kliknite na relacionu liniju i pritiskom na tipku Delete će te obaviti brisanje uz prethodno upozorenje od strane softvera baze.
95
@ViPserbia
5.5. Izrada i izvoĎenje upita Upiti omogućavaju pristup podacima smeštenim u tabelama i njihov prikaz na ekranu ili štampaču. Pomoću upita se moţe pristupati jednoj tabeli ali se upiti mogu praviti i nad više tabela. Primeri upita vezani za bazu podataka formiranu iz ovog našeg primera (mala banka) bi mogli biti: Koji klijenti ţive u naprimer SCG (drţavna zajednica Srbije i Crne Gore) Koji računi imaju saldo manji od 500 Din Prikazaćemo u nastavku kako se koristi odgovarajući Access-ov čarobnjak za izradu upita nad jednom i više tabela. 5.5.1 Upiti nad jednom tabelom Upiti nad jednom tabelom su korisni da se izvuku pogledi na podatke u tabeli tako: da se prikazuju samo neke kolone u izlazu upita da se obavi sortiranje slogova odabrane kolone za sort odreĎenim redosledom da se obave odreĎene statistike nad slogovima kao naprimer izračunavanje zbira vrednosti podataka u koloni ili prebrojavanje slogova u tabeli, ili filtriranje slogova tako da se vide samo oni slogovi koji zadovoljavaju neki postavljeni kriterijum kao naprimer prikaz korisnika mini banke koji ţive u DZSCG (SCG). Kao i kod tabela, kreiranje upita moţe biti realizovano ili funkcijom Design view ili odgovarajućim čarobnjakom Access-ovog segmenta za upite - Query. U primeru koji sledi, koristićemo čarobnjak da bismo napravili upit. U Access-ovom glavnom ekranu dolazimo do taba Queries kao što je to prikazano na sledećoj slici:
Slika 5.32. Primer - izgled menija Accessa povezanih tabela 96
@ViPserbia
Za izradu novog upita, kliknite na dugme New. Pojavljuje se meni sistem za upite i tada treba odabrati čarobnjaka Simple Query i kliknuti na dugme OK (kao što je pokazano na sledećoj slici):
Slika 5.33. Primer - izgled menija za izbor načina rada pri izredi upita Prvi korak u Simple Query čarobnjaku jeste da se navede tabela nad kojom se pravi upit i koje kolone (polja) će biti prikazane kao rezultat upita (izlaz upita). Tri glavne sekcije ovoga su: 1. Tables/Queries - Odaberite iz spiska tabela onu koja vas zanima za kreiranje upita. 2. Available Fields – Ovde je dat spisak raspoloţivih kolona odabrane tabele 3. Selected Fields – Ovde su data odabrana polja koja će se prikazati. Naprimer odaberite tabelu preko padajućeg menija Tables/Queries pod nazivom Klijent. Zapazite da se odmah posle toga pojavljuje i spisak raspoloţivih polja (Available fields) koja pripadaju tabeli Klijenti. Na slici 5.34. je dat grafički prikaz opisanog postupka. Na levoj strani imate spisak raspoloţivih polja Available fields te preselite polja Ime_i_Prezime, Adresa, Mesto i Drzava u zonu odabranih polja Selected Fields na desnu stranu. To se radi tako da se označi odabrano polje i klikom na dugme preseljavate.
ga
97
@ViPserbia
Slika 5.34. Primer - izgled menija za izbor polja pri izradi upita Ovo ponavljate za svako navedeno polje tabele koje ţelite da prenesete. Kada ste ovo uradili, čarobnjak vam daje stanje kao što je pokazano na sledećoj slici:
Slika 5.35. Primer - izgled menija sa izabranim poljima za upit 98
@ViPserbia
Klikom na dugme Next se preseljavaju sva polja i nakon toga se dolazi do poslednje tačke Simple Query čarobnjaka. Na kraju: upitu treba dati ime. Neka to bude u ovom slučaju na primer qryklijenti.
Slika 5.36. Primer - izgled menija za definisanje imena upita Opisanim postupkom, čarobnjak će napraviti novi upit sa nekom od opcija: Open the query to view information - ovo znači da će čarobnjak izvesti upit i prikazati traţene podatke koji se nalaze u odabranim kolonoma, Modify the query design - čarobnjak će vas prebaciti na Design View i ovde će vam biti dozvoljeno da modifikujete upit.
U ovom primeru, odaberite Open the query to view information – otvorite upit da biste pogledali informacije i kliknite na dugme Finish. Kada se upit izvede, dobijate samo ime korisnika, adresu, mesto i drţavu, ali se svi redovi pojavljuju kao što se to pokazano na sledećoj slici:
99
@ViPserbia
Slika 5.37. Primer - izgled upita klijenti Zatvorite ovaj upit preko menija File i odabirom funkcije Close. Nakon toga dobijate standardni glavni ekran Access-a odnosno treba da se pojavi Queries tab. Pri tome će se na Query tabu pojaviti novi upit qryklijent. U sledećem primeru ćemo promeniti upit qryklijent tako da se prikaţu polja (kolone) o korisnicima odreĎenih drţava. Da bi se ovo ostvarilo, koristićemo Query Design View. Pomoću funkcije Design view otvorite upit qryklijent, a zatim markirajte ime upita klikom na njegovo ime i posle toga kliknite na dugme Design. Funkcija Design view će vam omogućiti da dobijete ekran kao što je pokazano na slici 5.38. Funkcija Query Design view ima dve glavne sekcije. U prvoj (gornjoj) sekciji, pojavljue se spisak tabela (ili samo jedna tabela-u zavisnosti od toga šta je ranije kreirano) zajedno sa pripadajućim kolonama tabele koje su na raspolaganju. U drugoj sekciji se pojavljuju samo odabrane kolone (polja) koja se ţele dobiti sa upitom.
100
@ViPserbia
Slika 5.38. Primer - izgled upita klijenti – design view Svako polje ima nekoliko opcija koje moţete pridruţiti polju:
Field - Ime polja u tabeli Table - Tabela iz koje je došlo polje Sort - Redosled po kome će se sortirati imenovano polje (Ascending Rastući, Descending Opadajući ili Not Sorted Nesortirano) Show – Izbor da li da se polja u izlazu upita prikaţu ili ne Criteria - Označava koji kriterijum (filter) je postavljen za slogove za kreiranje prikaza izlaza iz upita. Pretpostavimo da u ovom primeru ţelimo da filtriramo samo slogove o onim korisnicima koji ţive u drţavi sa oznakom DZSCG (SCG). Pri tome, ţelimo da sortiramo sve slogove koji se odnose na polje po nazivima gradova: polje Mesto. Za sortiranje polja Mesto, dovoljno je kliknuti u zonu Sort od polja Mesto. Odaberite iz padajućeg menija opciju - tip Ascending (rastući abecedni redosled). Kao rezultat ćete dobiti ekran kakav je prikazan na sledećoj slici:
101
@ViPserbia
Slika 5.39. Primer - izgled upita po mestima klijenata – design view Da bismo napravili filter za prikaz klijenata mini banke Klijenti koji ţive u drţavi DZSCG, potrebno je kliknuti na područje Criteria polja Drzava i otkucati uslov = 'SCG'
Slika 5.40. Primer - izgled upita po drţavama klijenata – filtar SCG – design view 102
@ViPserbia
Uslov ='SCG' će kazati Access-u da se prikazuju samo oni slogovi čija vrednost polja Drzava je ispunila jednakost tj. da je jednaka 'SCG'. Sada se moţe izvesti ovaj upit tako da u padajućem meniju Query odaberete komandu Run. Izlaz upita bi trebao da izgleda kao na sledećoj slici:
Slika 5.41. Primer - izgled rezultata upita po drţavama klijenata – filtar SCG Na kraju treba sačuvati upit, zatvoriti aktivnosti i vratiti se na glavni ekran Access-a. U svrhu veţbanja, moţete koristiti čarobnjaka Simple Query i napraviti upit u tabelu Racuni da biste prikazali sledeće kolone (polja) Broj racuna (broj računa), Tip racuna (tip računa) i Saldo (saldo). 1. U glavnom ekranu Access-a treba kliknuti na tab Queries a zatim na dugme New. 2. Odaberite opciju Simple Query wizard i posle toga kliknite na dugme OK. 3. Kada se nalazite u podmeniju Table/Queries: odaberite iz padajućeg menija tabelu Racuni. Zatim preselite polja Broj racuna, Tip racuna i Saldo preko Selected zone i kliknite na dugme Next. 4. Na sledećem podmeniju, bićete pitani da li ţelite da izaberete detaljni (detail) ili sumarni (summary) upit. Odaberite detaljni upit i kliknite na dugme Next. 103
@ViPserbia
5. Ovom novom upitu moţete dati ime: QryRacuni i zatim kliknite na dugme Finish. Kao rezultat ćete dobiti izgled izlaza iz ovakvog upita otprilike kao na sledećoj slici:
Slika 5.41. Primer - izgled rezultata upita po tipovima računa Zatvorite upit preko padajućeg menija File odabirom funkcije Close. U sledećem delu veţbe, promenićemo upit tako da se izlaz upita sortira po broju računa i da se pokaţu samo oni računi koji imaju Vrstu štednje (Štednja). 1. Na glavnom Access ekranu pozovite tab Queries i obeleţite ranije napravljen upit QryRacuni a zatim treba kliknuti na dugme Design. 2. Promenite redosled sortiranja za polje Broj racuna, tako da se prikazuje u rastućem redosledu (Ascending). 3. Pored toga moţete dodati sledeći uslov za kriterijum Criteria: polje Vrsta racuna treba da zadovolji uslov = 'Štednja'
104
@ViPserbia
Slika 5.42. Primer - izgled upita – Design view po tipu računa - Štednja 4. Upit izvodite tako da u padajućem meniju Query odaberete komandu Run. Izlaz bi trebao da izgleda poput primera prikazanog na sledećoj slici:
Slika 5.43. Primer - izgled rezultata upita po tipu računa - Štednja 5. Na kraju, moţete sačuvati i zatvoriti upit i vratiti se na glavni ekran Access-a.
105
@ViPserbia
5.5.3. Upiti nad više tabela Do sada smo kreirali upite koji se sprovode nad jednom tabelom. Sada ćemo preći na prikazivanje mogućnosti da se upiti prave tako da se u njih uvlače podaci iz više tabela. Na primer, pretpostavimo da neki menadţer ţeli da vidi listu svih klijenata kao i koje tipove računa banka ospluţuje. Očigledno je da se upit pravi od dve tabele Klijenti i Racuni. Kod takvih upita, Access će iskoristiti relacije uspostavljene u takvim tabelama i dovesti vas do rešenja kako će se prikupiti podaci za potrebe ţeljenog upita. Pre nego što nastavimo sa radom napravimo 1:M (jedan-prema-više) relaciju izmeĎu tabela Klijenti i Racuni koje su prethodno kreirane i na na;in koji smo opisali u segmentu o kreiranju relacija. Pre započinjanja procesa stvaranja upita nad više tabela, izabrane tabele se moraju "osvetliti" u podmeniju Query, a zatim se klikne na dugme New da bi se kreirao ţeljeni upit. Odaberite opciju čarobnjaka - "Simple Query Wizard" kao što smo to činili ranije. Kada se čarobnjak odazove odaberite polje KlijentID i polje Ime_i_Prezime iz tabele Klijenti, a zatim se prebacite na Tables/Queries i odaberite u tabeli Racuni polja KlijentID, Tip racuna i Saldo. Rezultat ovakvog postupka bi trebao da dovede pojave ekrana poput onoga prikazanog na sledećoj slici:
Slika 5.45. Meni za izbor odgovarajućih polja iz tabela za upit
106
@ViPserbia
Za nastavak postupka kreiranja upita kliknite na dugme Next. U sledećem koraku čarobnjaka, pojaviće se opcija koja treba da obezbedi odgovarajuće nivoe u kategoriji Summary (finalni prikaz). Za potrebe ove veţbe, ostavite podrazumevanu opciju "Detail ..." kao što je prikazano na sledećoj slici i tada za nastavak kliknite na dugme Next.
Slika 5.46. Meni za izbor detaljnog ili zbirnog upita Na kraju, imenujmo upit kao naprimer "qryKlijentRacun" i kliknimo na dugme Finish. Efekti izrade upita nad više tabela bi trebali da se pojave na ekranu i izgledaju kao na sledećoj slici:
Slika 5.47. Rezultat upita nad više tabela 107
@ViPserbia
Kao što smo pokazali kod upita nad jednom tabelom, moţete i upite nad više tabela da menjate tako da im dodajete dopunske filtere odnosno uslove za odabir podataka koji će se prikazivati (preko alata Design view) (naprimer ţelimo prikazati sve informacije za klijente koji imaju kao drţavu oznaku 'SCG'). Na kraju ćemo kao primer napraviti upit koji će se zvati "qryZbirni". Upit spaja tabelu Klijenti (uključujući polja KlijentID i Ime_i_Prezime) sa tabelom Racuni (uključujući samo polje salda ). U drugom koraku čarobnjaka, kliknite na opciju Summary (umesto na Details) a potom kliknite na dugme "Summary Options...". Isključite sve kućice u opcijama "Summary option" kao što su Sum (zbir), AVG (prosek), Min i Max kao što je pokazano na sledećoj slici:
Slika 5.48. Meni za izbor odgovarajućeg upita Rezultat stvorenog upita bi trebao da izgleda poput ekrana na slici 5.49. U ovoj sekciji, prikazali smo osnovne korakei za izradu i izvoĎenje upita. Pri tome, se moţe koristiti čarobnjak za izradu upita da bi se napravili jednostavni upiti kojima se pristupa jednoj tabeli. Pored toga, moguće je modifikovati upit da bi se ostvarilo sortiranje po nekoj koloni tabele ili da se filtriraju slogovi u tabeli. Napravićemo na kraju kratak pregled postupka kreiranja upita uz pomoć čarobnjaka: 1. Iz Access-ovog glavnog ekrana kliknite na tab Queries. Potom kliknite na dugme New. 2. Iz taba Queries (upiti) na glavnom ekranu Access-a, kliknite na dugme New i odaberite opciju čarobnjaka kojom kreirate upit nad jednom tabelom Simple Query.
108
@ViPserbia
Slika 5.49. Rezultat ostvarenog zbirnog upita nad dve tabele Postavite se ispod Table/Queries: odaberite odgovarajuću tabelu nad kojom pravite upit, a tada obeleţite polja u tabeli koja će se pojavljivati kao izlaz upita. Ako pravite upit nad više tabela tada opet u Table/Queries potrebno je da odaberete da se prikaţu dopunske tabele i odaberete potrebna polja tih tabela koja učestvuju u upitu. 3. Ako tabela sadrţi numerička polja, tada se mogu prikazivati ili detaljne ili sumarne (zbirne) informacije kao rezultat upita (uključujući i funkcije kao SUM, AVG, MIN i MAX). 4. Konačno, dajte ime novom upitu i kliknite na dugme Finish. Često je korisno napraviti upit koga moţete da iskoristite u formi i/ili izveštaju.
109
@ViPserbia
5.6. Izrada forme i obuhvat podataka primenom forme Forme za obuhvat podataka su glavno sredstvo za unos podataka i njihovih promena u tabele u bazi podataka. U prethodnom tekstu, opisivali smo kako se dodaju podaci u tabele upotrebom tabelarnog prikaza podataka u samoj tabeli. Forme za obuhvat podataka nude bolje mogućnosti za izradu jednostavnog korisničkog interfejsa jer će na njima pored polja za unos podataka biti i prateće oznake, a i druge informacije koje su od koristi u radu (user-friendly interface) MS Access softver omogućava nekoliko različitih načina izrade formi za obuhvat podataka. One uključuju kreiranje formi manuelno (ručno) preko Design View funkcije kao i preko niza čarobnjaka koji vas vode kroz proces kreiranja forme. U ovom delu ćemo govoriti o osnovnim koracima prilikom izrade forme pomoću čarobnjaka. 5.6.1. Izrada forme nad jednom tabelom upotrebom čarobnjaka U ovom primeru ćemo napraviti jednu jednostavnu formu za unos podataka za potrebe tabele klijenata mini banke Klijenti. Da bi započeli ovaj proces, na glavnom ekranu Access-a treba kliknuti na tab Forms. Kao i kod drugih komponenti u Accessu, postoje dugmići za kreiranje nove forme poput New, otvaranje potojeće forme poput Open i dugme za modifikaciju postojeće forme Design. U ovom primeru za potrebe veţbe, sada kliknite na dugme New da biste napravili novu formu. Otvara se kućica za dijalog New Form sa nekoliko opcija za kreiranje nove forme. U ovom priručniku sada izaberite čarobnjaka Form wizard. Na dnu kućice za dijalog postoji podsetnik da zadate ime tabele ili upita koje koristite u novoj formi. U ovom slučaju izaberite tabelu Klijenti (dobićete ekran poput onoga koji je prikazan na sledećoj slici), a potom kliknite na dugme OK.
Klijenti
Slika 5.50. Meni za izbor načina izrade forme 110
@ViPserbia
U narednom koraku čarobnjaka Form wizard, treba da specificirate polja tabele Klijenti koja će se pojavljivati na formi. Pretpostavimo da u ovom slučaju ţelimo da se pojave sva polja. Preselite sva raspoloţiva polja sa strane Available Fields na stranu Selected Fields kao što se to moţe videti na sledećoj slici. Posle toga kliknite na dugme Next.
Slika 5.51. Meni za izbor polja prilikom kreiranja forme Forme mogu biti napravljene sa različitim obrascima (šablonima) ili različitim aranţmanima oznaka uz polja na ekranu. Columnar - Smeštaju se oznake na levu stranu svakog polja na formu. To je veoma slično kao kada pravite papirnu formu izgleda tabele. Ovakav obrazac je podesan za posmatranje podataka iz odreĎenog sloga u ţeljenom trenutku. Tabular - Smešta oznake polja na vrh ekrana a ispod toga se prikazuju svi podaci te se koriste klizači "gore-dole" ili "levo-desno" za pomeranje ekrana da bi se videli podaci koji prevazilaze gabarite ekrana. Ovaj tip kreiranja je sličan tabelarnom prikazu kao što se dobija u naprimer Exel knjigama, a pogodan je za prikaz više slogova istovremeno. Datasheet - Podaci se pojavljuju na isti način kao kada ih posmatrate ili dodajete u tabelu.
111
@ViPserbia
Justified (poravnato) - Smeštaju se oznake polja iznad svakog polja, a proporcionalno su razmeštene po formi. Ovaj obrazac je pogodan za posmatranje jednog sloga u odreĎenom trenutku nešto kao i kod Columnar šablona. Za potrebe ovog primera, treba da izaberete obrazac Columnar kao što je prikazano na sledećoj slici i kliknete na dugme Next.
Slika 5.52. Meni za izbor načina prikazivanja polja u formi Access ima nekoliko primera za prikaz stilova kojima se odreĎuje kako će se forma pojavljivati na ekranu, uključujući takve elemente kao što su fontovi, boje i pozadine koje će se koristiti u formi. U ovom primeru izaberite stil Standard kao što se to vidi na saledećoj slici a zatim kliknite na dugme Next.
Slika 5.53. Meni za izbor stila prilikom kreiranja forme
112
@ViPserbia
Kao finalni korak, treba dati ime formi: frmKlijentObuhvatPodataka, a potom kliknuti na dugme Finish kao što je pokazano na sledećoj slici:
Slika 5.54. Meni za definisanja imena forme Nova forma će biti napravljena sa čarobnjakom, a potom otvorena. Kao rezultat treba da se pojavi ekran poput onoga koji je prikazan na sledećoj slici:
Slika 5.55. Izgled kreirane forme 113
@ViPserbia
Za navigaciju kroz polja u slogu treba koristiti tipku "Tab" (/) koja se vidi na formi. Za kretanje kroz tabelu preko forme (da biste videli slogove), koristi se navigaciona traka koja je smeštena pri dnu forme (u podnoţju forme).:
Slika 5.56. Izgled navigacione trake za kretanje kroz tabelu preko forme Dugmad za navigaciju mogu da obave sledeće funkcije: - Idi na prvi slog. - Idi na prethodni slog. - Idi na sledeći slog. - Idi na poslednji slog.
- ProĎi poslednji slog i stvori uslove za unos novog sloga. Na kraju treba zatvoriti formu i vratiti se na glavni ekran Access-a (potrebno je da pozovete padajući meni File i unutar njega da odaberete funkciju Close). Za otvaranje forme u bilo kom trenutku, dovoljno je samo da je odaberete (osvetlite) preko odgovarajućeg imena koje se vidi na tabu Forms u glavnom ekranu Access-a, a potom kliknite na dugme Open da biste otvorili formu. Za veţbu, ćemo kreirati formu za obuhvat podataka iz tabele računa Racuni koja je napravljena ranije i napunjena sa inicijalnim podacima za veţbanje. 1. Na glavnom ekranu Access-a kliknite na tab Forms, a potom na dugme New da biste kreirali novu formu. 2. Odaberite čarobnjaka Form wizard i odaberite tabelu Klijenti a onda kliknite na dugme OK. 3. Odaberite sva raspoloţiva polja ove tabele za prikaz na formi i kliknite na dugme Next. 4. Odaberite obrazac Tabular pa kliknite na dugme Next. 5. Odaberite stil Standard pa kliknite na dugme Next. 6. Dajte formi ime naprimer: frmRacuniObuhvatPodataka. Potom kliknite na dugme Finish da biste kreirali, sačuvali i pogledali novu formu. Rezultat nove forme je prikazan na sledećoj slici:
114
@ViPserbia
Slika 5.57. Izgled nove forme za obuhvat podataka Zatvorite ovu formu i vratite se na glavni ekran Access-a izborom funkcije Close u padajućem meniju File. Na kraju ćemo dati osnovne korake pri izradi jednostavne forme za obuhvat podataka nad jednom tabelom, a to su: 1. 2. 3. 4. 5.
Izaberite tabelu i čarobnjaka za forme. Navedite sa kojim poljima (kolonama) ćete raditi na formi. Navedite obrazac forme koji ţelite koristiti. Navedite stil (fontovi, boje, itd.) za odabrani obrazac. Sačuvajte, izradite i izvedite novu formu.
Na ovaj način smo obuhvatili osnovne korake koji se moraju proći da bi se kreirala forma za obuhvat podataka. Access vam nudi niz čarobnjaka koji su prilagoĎeni za tipične vrste jednostavnih formi sa minimalnom količinom rada. Za napredniji rad nad formama trebalo bi da se fokusirate na funkciju Design View ukoliko ţelite da promenite izgled forme odnosno da biste dodali ili izbacili polja i oznake polja iz jednom već kreirane forme.
115
@ViPserbia
5.7. Kreiranje izveštaja Izveštaji su slični upitima jer kao i oni pretraţuju i pronalaze podatke iz jedne ili više tabela i kao rezultat prikazuju takve podatke. MeĎutim, za razliku od upita, izveštaji omogućavaju formatiranje izlaza sa mogućnošću izbora fontova, boja, pozadine kao i niza drugih mogućnosti. Izveštaji se često štampaju na papiru radije nego da se gledaju na ekranu. U ovom segmentu ćemo pokriti oblast kreiranja jednostavnijih izveštaja i to upotrebom odgovarajućeg čarobnjaka. 5.7.1. Kreiranje izveštaja nad jednom tabelom upotrebom čarobnjaka U ovom primeru ćemo napraviti jednostavan izveštaj upotrebom jedne tabele. Pri tome ćemo koristiti mogućnost Access-a da upotrebimo čarobnjaka za izveštaje. Kao što smo radili kod kreiranja upita i formi, opet počinjemo od glavnog ekrana Access-a gde biramo tab za izveštaje Reports. Za izradu novog izveštaja kliknite na dugme New. Posle toga se pokreće dijalog New Report i dobijate ekran poput onoga koji je prikazan na sledećoj slici. Odaberite zatim čarobnjaka Report wizard, a potom odaberite tabelu za koju pravite izveštaj Klijenti. Za nastavak postupka kliknite na dugme OK.
Klijenti
Slika 5.58. Izgled menija za izbor načina kreiranja izveštaja U narednom koraku čarobnjaka Report wizard, treba da navedemo polja iz tabele Klijenti koja će se pojavljivati na izveštaju. U ovom slučaju pretpostavimo da ţelimo da se pojave sva polja. Preselite sva polja sa strane raspoloţivih Available Fields na stranu odabranih polja Selected Fields, a zatim kliknite na dugme OK I dobićete ekran kao na sledećoj slici. 116
@ViPserbia
Slika 5.59. Izgled menija za izbor polja kod kreiranja izveštaja Sada imamo mogućnost da dodajemo i nivoe grupisanja u izveštaju primenom opcije Grouping Levels. To je mogućnost kojom se grupišu slogovi u tabeli po jednoj vrednosti za dato polje koje je odabrano kao vodilja. Pri tome se takva vrednost moţe pojaviti samo jednom, a zatim se reĎaju slogovi koji zadovoljavaju taj kriterijum. U našem slučaju, nećemo za sada koristiti ovu mogućnost tako da ćemo jednostavno kliknuti na dugme Next.
Slika 5.60. Izgled menija koji omogućava grupiranje nivoa u izveštaju
117
@ViPserbia
U sledećem koraku, imamo mogućnost da izvršimo sortiranje po nekom polju (koloni) kao i da specificiramo redosled sortiranja odabranog polja u izveštaju. U ovom našem primeru ćemo sortirati slogove po polju KlijentID. Da bi realizovali ovakvu ţelju, treba u padajućem meniju liste na broj 1 odabrati polje KlijentID, a zatim treba kliknuti na dugme Next (dobićemo ekran kao što je pokazano na sledećoj slici).
Slika 5.61. Izgled menija za izbor varijante sortiranja u izveštaju U narednom koraku čarobnjaka se navode šabloni (obrasci) izveštaja. Postoje tri opcije: Columnar - Postavlja oznake polja na levu stranu od pozicije polja. Ovo je najsličnije papirnoj formi. Tabular - Postavlja oznake polja na vrh izveštaja, a ispod toga se smeštaju (reĎaju) slogovi. Ovo je najsličnije prikazu podataka u Exel-ovim izveštajima. Justified - Smeštaju se oznake polja za svako polje i onda se takvo reĎanje širi u izveštaju. Generalno, izveštaji se prave u tabelarnom obrascu. Za ovaj primer, odaberite obrazac Tabular, postavite orijentaciju Orientation stranice na Landscape ("pejzaţ") tako da sva polja stanu na stranicu i da se proporcionalno rasporede. Na sledećoj slici je prikazan efekat odabira, a zatim pritisnite na dugme Next za nastavak.
118
@ViPserbia
Slika 5.62. Izgled menija za izbor oblika i orjentacije izveštaja U sledećem koraku se bira stil izveštaja. Za potrebe ovog primera, odaberite stil Corporate, a zatim kliknite na dugme Next za nastavak.
Slika 5.63. Izgled menija za izbor stila izveštaja
119
@ViPserbia
Na kraju, dajte ime izveštaju - naprimer: rptKlijenti, a zatim kliknite na dugme Finish da biste kreirali, sačuvali i prikazali izveštaj.
Slika 5.64. Izgled menija za definisanje imena izveštaja Izlaz iz izveštaja je prikazan na sledećoj slici. Treba primetiti da na nekim ekranima, poslednje polje, poštanski broj Zip ne moţe da se prikaţe bez skroliranja (klizanja) na desno.
Slika 5.65 Izgled izveštaja rptKlijenti
120
@ViPserbia
Kada je izveštaj prikazan, on, pored toga što moţe biti posmatran na ekranu, moţe biti odštampan ili moţe biti prenet u Microsoft Word ili Microsoft Excel okruţenje. Dugmići koji se vide na gornjem delu ekrana imaju sledeće značenje: Štampaj izveštaj Zumiraj u odreĎeni region izveštaja Prikaţi izveštaj sa jednom stranicom, dve ili više stranica Zumiraj + ili - unutar izveštaja Prenesi izveštaj u MS Word Zatvori izveštaj
Zatvorite izveštaj i vratite se na glavni ekran Access-a, a zatim iz padajućeg menija File odaberite funkciju Close pa pritisnite na dugme Close. U nastavku ćemo kao veţbu napraviti izveštaj koji pokazuje sve informacije o računima mini-banke. 1. Preko glavnog ekrana Access-a odnosno taba za izveštaje Reports pritisnite dugme New. 2. Pozovite čarobnjaka za izradu izveštaja Report wizard, odaberite tabelu Racuni i pritisnite dugme OK. 3. Odaberite sva polja tabele Racuni i prebacite ih u stranu Selected Fields a zatim pristinite dugme Next. 4. Grupišite izveštaj preko identifikacije klijenta KlijentID tako što ćete pritisnuti na polje KlijentID a potom pritisnite na dugme . (Slika 5.66) Nakon toga pritisnite dugme Next. - Izaberite da sortni pojam u izveštaju bude polje broj računa klijenta Broj_Racuna. - Treba primetiti da se pojavljuje jedno novo dugme koje se naziva Summary Options (sumarne opcije). (Slika 5.67) - Pritisnite na to dugme Summary Options. - Odaberite da vam za sumiranje bude polje salda Saldo a potom odaberite opciju sabiranja pojedinih iznosa u saldo Sum.. (Slika 5.68) - Izborom ovakvog rada odnosno opcija dobićete podatke detalja Detail i podatke sabiranja Summary. .. (Slika 5.68) - Nakon toga kliknite na polje OK.
121
@ViPserbia
- Nastavite rad sa pritiskom na dugme Next.
Slika 5.66 Izgled menija za izbor opcije grupiranja u izveštaju
Slika 5.67 Izgled menija za izbor opcije sumiranja u izveštaju
122
@ViPserbia
Slika 5.68 Izgled menija za izbor opcije sumiranja i detalja u izveštaju 5. Odaberite da vam obrazac za izgled izveštaja bude Block layout, a zatim kliknite na dugme Next. 6. Odaberite stil Corporate i kliknite na dugme Next. 7. Na kraju, dajte ime izveštaju AccountsReport i pritisnite na dugme Finish a potom okončajte kreiranje, sačuvajte listu i generišite izveštaj.
Slika 5.69 Izgled izveštaja kreiranog na prethodno opisani način 123
@ViPserbia
Treba zapaziti da je grupisanje podataka (opcija Grouping) na nivou polja KlijentID,a da se sabiranje iznosa obavlja u zbirni saldo preko funkcije Sum. Zatvorite izveštaj tako što ćete se vratiti na glavni ekran Access-a pozivom padajućeg menija File, a zatim izabrati funkciju Close. Kao što je pokazano prilikom uveţbavanja izrade izveštaja, postojali su mnogi načini da se naprave izveštaji za prikaz sumarnih, sortiranih i formatiranih podataka. Dalje učenje o izveštajima će pokazati kako se mogu modifikovati obrasci upotrebom funkcije Design View. Potrebno je više veţbati i raditi sa čarobnjacima za izradu izveštaja da bi se mogli napraviti izveštaje raznih stilova i tipova.
124
@ViPserbia
5.8. Microsoft Access 2000 – dodatne mogućnosti 5.8.1 Switchboard Manager Funkcija: Za izradu panela za izbor funkcija aplikativnog softvera (interfejs prema korisniku)
Slika 5.70 Izgled menija za izbor Switch board managera Pri generisanju Switchboard panela, prvi put Access upozori projektanta-programera da menadţer ne moţe da pronaĎe odgovarajuće definicije u bazi i postavlja pitanje da li da se nastavi (Yes) ili ne (No): U ovom primeru ćemo odgovoriti YES
Slika 5.71 Izgled menija za odluku o kreiranju Switch board managera
125
@ViPserbia
Slika 5.72 Izgled menija za odluku o kreiranju Switch board managera
Slika 5.73 Izgled menija za definisanje imena novog Switch board managera
Slika 5.74 Izgled menija za definisanje komande pri kreiranju Switch board managera 126
@ViPserbia
Srediti "Text", odabrati "Command" i odabrati "Switchoboar" objekat (forma, izveštaja, izlaz iz aplikacije):
Slika 5.75. Izgled menija za definisanje pojedinih elemenata pri kreiranju Switch board managera Access generiše odgovarajuću formu "Switchboard" i tabelu "Switchboard Items". Podrazumeva se (default) da na formi ima maksimalno 8 stavki. SwitchboardID
ItemNumber
ItemText
Command
Argument
1
0 GLAVNI MENI
1
1 Obuhvat podataka o klijentima
2 frmCustomers
1
2 Obuhvat podataka o partijama
2 frmAccounts
1
3 Izveštaj o partijama - sve, po abecedi imena klijenta
4 rptCustomers-qry
1
10 Izlaz iz aplikacije
Default
6
Slika 5.76. Sadrţaj Switchboard Items tabele
127
@ViPserbia
Slika 5.77. Primer izgleda panela za izbor poslova minibanka.mdb: Broj stavki na formi "Switchboard" se moţe menjati i traţi se minimalmo reprogramiranje. Koristimo Design View funkciju da promenimo VBA kod za formu Switchboard:
Klikom dozvati "CODE" odn. VBA editor!
Slika 5.78. Primer izbora – pozivanja VBA editora za potrebe Switchboarda 128
@ViPserbia
Umesto 8 stavite npr. 10 i zatvorite prozor VBA editora odn. vratite se u formu!
Slika 5.79. Primer VBA koda za potrebe Switchboarda Na formi treba dodati još dva reda:
129
@ViPserbia
Slika 5.80. Izgled Switchboarda sa 10 stavki Za ova dva reda dodata na formi moraju se prilagoditi odgovarajuće Properties-i osobine: Za dugme
Slika 5.81. Izgled komandnog menija za opciju – stavku broj 9 130
@ViPserbia
Za tekst pored dugmeta
Slika 5.82. Izgled komandnog menija za opciju – stavku broj 9 odnosno "Option10" i "OptionLabel10" za poslednju dodatu stavku. U Switchboard Items tabeli moţete i manuelno dodavati stvake umesto sa Siwtchobaord Manager-om pri čemu treba da znate nuemričke oznake pojedinih komandi: OpenFormAdd =2 OpenFormBrowse = 3 OpenReport =4 ExitApplication = 6 RunMacro =7 RunCode =8 OpenPage =9
131
@ViPserbia
Slika 5.83. Podešavanje prve forme kod startovanja pristupa bazi podataka
Slika 5.84. Podešavanje kompresije baze podataka pri izlasku iz Access-a
132
@ViPserbia
Slika 5.85. Meni za izbor opcija
Slika 5.86. Meni za definisanje pojedinih opcija
133
@ViPserbia
Slika 5.87. Meni za postavljanje dugmeta za štampu (ekran/štampač) Postupak je sledeći: U Toolbox odabrati alat CommandButton (obeleţeno sa krugom),
Slika 5.88. Meni za izbor menija odgovarajućih alata
134
@ViPserbia
Slika 5.89. Meni za definisanje grupe akcija i pojedinačne akcije a zatim stisnuti dugme Next i odabrati izveštaj u Reports tabu - meniju za izveštaje koji koristite za prikaz podataka:
Slika 5.90. Izbor izveštaja koji će biti pozvan aktiviranjem taba Posle pritiska na dugme Next odabrati simbol na dugmetu:
135
@ViPserbia
Slika 5.91. Meni za definisanje teksta ili slike na tabu - dugmetu Posle klika na Next promeniti tekst u naprimer MyPreviwerButton i kliknuti na dugme Finish:
Slika 5.92. Meni za definisanje imena – naziva dugmeta Potrebno je potom desnim klikom na dugmetu podesiti Properties:
136
@ViPserbia
Slika 5.93 Meni a za izbor osobina - properties dugmeta
137
@ViPserbia
Slika 5.94. Meni b za definisanje osobina dugmeta
Slika 5.95. Meni c za definisanje osobina dugmeta
138
@ViPserbia
Odlaskom na dogaĎaj "On Click" potrebno je još podesiti VBA kod tako da naša rutina obezbedi prikaz onih podataka koji su u tekućoj formi, a ne prikaz svih podataka u tabeli. Generisan VBA kod koji treba promeniti: Private Sub MyPreviewerButton_Click() On Error GoTo Err_MyPreviewerButton_Click Dim stDocName As String stDocName = "rptCustomers-qry" DoCmd.OpenReport stDocName, acPreview Exit_MyPreviewerButton_Click: Exit Sub Err_MyPreviewerButton_Click: MsgBox Err.Description Resume Exit_MyPreviewerButton_Click End Sub Modifikovan VBA kod: Private Sub MyPreviewerButton_Click() On Error GoTo Err_ MyPreviewerButton_Click If IsNull(Me![AccountID]) Then MsgBox "Pre pregleda podataka mora se uneti NEKI podatak." Else DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 DoCmd.OpenReport "rptCustomers-qry", acPreview, , "[AccountId] = " & [AccountId] End If Exit_MyPreviewerButton_Click: Exit Sub Err_MyPreviewerButton_Click: MsgBox Err.Description Resume Exit_ MyPreviewerButton_Click End Sub
139
@ViPserbia
Rezultat pritiska na ovako definisano dugme je prikazan na sledećoj slici:
Slika 5.96. Izveštaj kao rezultat aktiviranja na prethodni način definisanog dugmeta
140
@ViPserbia
5.8.2 Look Up / Combo Box Access nudi mogućnost da se na jednostavan način bez potrebe programiranja koristi mogućnost da se tokom obuhvata podataka preko neke forme dozivaju podaci iz raznih tabela na osnovu "slovne senzitivnosti". Ako se podatak ne pronaĎe u takvoj tabeli onda se naprimer dvo-klikom aktivira dogaĎaj (event procedure) nad odgovarajućim poljem forme. Dvo-klik treba da omogući poziv spoljne korespondentne forme za unos podataka u odgovarajuću tabelu (bez napuštanja glavne forme). Ovo se sve realizuje pomoću Look Up (kod kreiranja tabele koja je u relaciji sa nekom drugom tabelom) i modifikacijom LookUp-a izborom Combo box-a. Kao primer uzećemo evidenciju knjiga sa odgovarajućim opisom tblKnjige:
Slika 5.97. Meni za definisanje tabele Knjige
141
@ViPserbia
Pretpostavimo ţelimo naprimer da kod šifre autora knjige ID_Autora doradimo Look Up na sledeći način:
Slika 5.98. Meni za definisanje Combo Box u tabeli Knjige SQL SELECT rečenica je napravljena pomoću integrisanog Access-ovog buildera:
Slika 5.99. Meni za pozivanje SQL naredbe u okviru Combo Box Pre tabele tblKnjige, treba da se kreira posebna tabela tblAutori tj. tabela autora knjiga:
142
@ViPserbia
Slika 5.100. Meni za definisanje tabele autora IzmeĎu tabela tblAutori i tblKnjige postoji relacija takva da je primarni ključ u tabeli tblAutori ID_Autora u relaciji sa stranim (foreign) ključem u tabeli tblKnjige ID_Autora. Sada je potrebno da napravimo formu nad tabelom tblAutori:
Slika 5.101. Meni za definisanje forme za tabelu autora Posle toga je potrebno da napravimo formu nad tabelom tblKnjige:
143
@ViPserbia
Slika 5.102. Meni za definisanje forme za tabelu knjige Zahvaljujući Look Up odnosno Combo Box mogućnostima, čarobnjak (wizard) za izradu forme je automatski napravio polje ID_Autora sa padajućim menijem "drop down" (padajući meni za izbor podataka).
Slika 5.103. Meni - a za definisanje osobina polja ID_Autora Ako pogledamo Properties – osobine polja ID_Autora videćemo da se u row source javlja jedna SQL SELECT rečenica koja je kreirana u fazi izrade tabele tblKnjige. Pored toga navodimo da ţelimo da vidimo drugu kolonu (column count) (tj. ime i prezime autora) i da se prva kolona ne vidi (0 cm) a druga se vidi (4 cm). Pored toga, obratite paţnju da je na ON DBL CLICK ubačena jedna procedura dogaĎaja (event procedure): 144
@ViPserbia
Slika 5.103. Meni – b za definisanje osobina polja ID_Autora Detalji o toj proceduri su sledeći: Private Sub Id_Autora_DblClick(Cancel As Integer) On Error GoTo Err_Id_Autora_DblClick Dim lngId_Autora As Long If IsNull(Me![Id_Autora]) Then Me![Id_Autora].Text = "" Else lngId_Autora = Me![Id_Autora] Me![Id_Autora] = Null End If DoCmd.OpenForm "frmAutori", , , , , acDialog, "GotoNew" Me![Id_Autora].Requery If lngId_Autora <> 0 Then Me![Id_Autora] = lngId_Autora Exit_Id_Autora_DblClick: Exit Sub Err_Id_Autora_DblClick: MsgBox Err.Description Resume Exit_Id_Autora_DblClick End Sub
145
@ViPserbia
5.8.3. Upotreba alata "Expression Builder" U okviru dosadašnjeg izlaganja smo pokrili osnovne informacije o kreiranju baze podataka i njenih objekata pomoću alata poznatog pod imenom Microsoft Access. Ti objekti su tabele, upiti za pretraţivanje podataka, forme za obuhvat podataka i izveštaji za prikaz podataka ili sumarni izveštaji na ekranu i / ili na hartiji (štampani izveštaji). Pored toga smo objasnili izradu glavnog menija – Switch board kao i Look Up opcije. U nastavku ćemo dati opis primene alata za primenu funkcija Expression Builder Expression Builder ima tri sekcije (obeleţeno sa 1,2 i 3):
Slika 5.103. Meni – b za definisanje osobina polja ID_Autora 1 Kućica za izraz: O gornjem delu sekcije za builder nalazi se kućica gde se smešta izraz koji formirate uz pomoć Access-ovog alata builder. Pod izrazom se podrazumeva bilo koja kombinacija matematičkih ili logičkih operatora, konstanti, funkcija, imena polja iz tabela, formi ili upita, kontrole i svojstva (property) pri čemu se izraz podvrgava oceni kao jedna vrednost. Primenjenim izrazima se mogu obavljati izračunavanja, manipualcije sa znakovima (karakterima) ili testiranja podataka. Donji deo sekcije ovog alata omogućava kreiranje elemanta izraza, a oni se onda prenose u kućicu za formiranje izraza. Ukoliko dobro poznajete semantiku i sintaksu Access-ovih programskih mogućnosti onda moţete direktno ukucavati sve što je potrebno da se formira ţeljeni izraz neposredno u kućici za izraz. 2 Dugmići za operator: U srednjem delu sekcije builder alata se nalaze dugmići koji su poznati pod opštim imenom operatori (znak ili simbol kojim se obeleţava vrsta izračunavanja, koje će se obaviti unutar formiranog izraza. Postoje matematički, logički operatori, operatori poreĎenja i operatori referenci). Ako kliknete na neki od tih dugmića, Expression Builder prenosi operator na mesto gde se zatekao kursor u kućici za izraz. 146
@ViPserbia
3 Elementi izraza: U niţem delu sekcije builder-a se nalaze tri kućice:
Leva kućica sadrţi fasciklu u kojoj je lista tabela, upita, formi i izveštaja kao objekata baze u kojoj se trenutno nalazite. Zatim sledi deo sa ugraĎenim funkcijama (built-in) a onda dolazi deo sa funkcijama koje je napravio i definisao sam korisnik (user-defined), potom konstante (vrednost koja nije izračunata i prema tome se ne menja tokom rada. Na primer broj 210 ili tekst "Kvartalni bilans". Napomena: Izraz ili vrednost koja proizilazi iz izraza nije konstanta u Access-ovoj terminologiji), operatori i opšti (zajednički) izrazi. Srednja kućica sadrţi specifične elemente ili kategorije elemenata iz fascikle u levoj kućici. Na primer, ako kliknete na ugraĎene funkcije (Built-In) u levoj kućici, u srednjoj kućici se prikazuje spisak kategorija svih Microsoft Accessovih funkcija. Desna kućica daje spisak vrednosti bilo kojeg izabranog elementa, koga ste izabrali u levoj i srednoj kućici. Na primer, ako ste kliknuli u ugraĎene funkcije (built-in) u levoj kućici, a dobijete kategorije funkcija u srednjoj kućici onda u levoj kućici dobijate spisak svih ugraĎenih funkcija odabrane kategorije. Napomena: Ako upotrebom ovog alata prenosite identifikatore koji su reference polja u nekoj tabeli, ili kontrole, ili svojstva tada se obrazuje posebna sintaksa. Na primer Forms![Orders]![OrderID] označava identifikator sa vrednošću OrderID koja se dobija preko kontrole u formi Orders.
Primer Pretpostavimo da u okviru aplikativnog softvera napravljenog za trgovine treba da se napravi popisna lista nakon obavljenog popisa i da se vidi da li postoji manjak, višak ili kakvo je stanje robe u magacinu u odnosu na stanje koje je evidentirano u bazi – knjigovodstveno stanje. Jedno od mogućih rešenja jeste da se izveštaj modifikuje ubacivanjem odgovorajuće kućice za tekst (text-box) koje će imati radni naslov STANJE. Najpre se iz menija Toolbox odabere alat "Text-Box":
Slika 5.104. Meni za izbor ţeljenog alata - u ovom slučaju Text box 147
@ViPserbia
Zatim se prenese na odgovarajući deo izveštaja, a potom se u unbound polju obavi formiranje izraza koji će biti ugnjeţdeni (If-Then-Else struktura): =IIF(([tblKol]-[rptKol])=0;"Ok!";IIF(([tblKol]-[rptKol])>0;"MANJAK";"VIŠAK"))
Koristimo Expression Builder:
Slika 5.104. Meni za definisanje odgovarajućeg funkcijskog izraza Nakon izvršene modifikacije dobićemo izgled izveštaja u Design View u obliku koji je prikazan na sledećoj slici.
148
@ViPserbia
Ovde se klikanjem doziva Expression Builder
Slika 5.105. Meni izveštaja - report u Design View obliku za definisanje odgovarajućeg funkcijskog izraza Na na sledećoj slici je dat izveštaj koji je nastao kao rezultat ovakvog rada:
149
@ViPserbia
Lista artikala posle popisa Šifra Artikla Nazivartikla
JedinicaMere
Kol
Zatečeno stanje Razlika u popisu STANJE
1
tastatura
kom
12
100
-88
VISAK
2
zvucnici
kol
15
20
-5
VISAK
3
kablovi
kom
200
10
190
MANJAK
4
disketa
kol
300
5
295
MANJAK
5
olovke
kol
20
20
0
Ok!
6
podloge za mis
kom
333
333
0
Ok!
7
kucista
kom
100
100
0
Ok!
8
stolovi
kom
10
0
10
9
monitori
kom
30
30
0
Ok!
10
tft-screen
kom
25
20
5
MANJAK
11
hard diskovi
kom
70
70
0
Ok!
12
maticne ploce
kom
20
VISAK
13
zvucne kartice
kom
25
VISAK
14
telefoni
kom
50
VISAK
15
stampaci laser
kom
130
VISAK
16
stampaci ink-jet
kom
70
VISAK
17
toneri laser
kom
80
VISAK
18
toneri ink-jet
kom
35
VISAK
MANJAK
5. jun 2004
Page 1 of 2
150
@ViPserbia
5.9. Upotreba Makroa Vaţno je napomenuti da za svako malo pa i srednje preduzeće Access kao alat daje dovoljno dobre performanse i da nisu potrebne posebne specijalnosti. Ukoliko je potrebno, mogu se primeniti odreĎeni matematički izrazi i funkcije zahvaljujući upotrebi alata koji nudi Access pod nazivom Expression builder, zatim odreĎeni makroi koje nudi Access kao gotove skupove naredbi kao i programske mogućnosti Microsoft Access baza podataka (.mdb) koje su prisutne i koriste se pod nazivom VBA - Visual Basic for Applications. U nastavku su dati samo neki primeri načina primene makroa i VBA Kao i sve druge funkcije vezane za objekte Accessa 2000, potrebno je pozicionirati se na odgovarajući tab radi iskorišćenja mogućnosti rada sa makroima:
Slika 5.106. Meni za izbor opcije Makroi - Macro Makroi se prave klikom na dugme New (ako je nov) ili desnim klikom na makro koji se redizajnira kao što je pokazano na sledećim slikama.
151
@ViPserbia
Slika 5.107. Meni za definisanje Makroa - efekat klika na dugme NEW
Slika 5.108. Meni - Efekat desnog klika na odabrani makro macLOAD
152
@ViPserbia
Makroi su skupovi naredbi - instrukcija - akcija, koje se mogu koristiti za potrebe automatizacije opštih poslova, najčešće u takozvanom paketnom (batch, a ne on-line) radu. Grupisanjem makroa koje nudi Access 2000, moţe se sprovoditi nekoliko poslova odjednom. Akcija je osnovni gradivni blok bilo kog makroa odnosno isntrukcija koja se kombinuje sa nekom drugom akcijom radi automatizacije poslova. Ponekad se pozivaju i komande preko makro jezika. To je slučaj na primer, ako ţelimo da otvorimo (ranije napravljenu) formu ili da štampamo (ranije napravljen) izveštaj. Pored toga, moţe se napraviti jedno komandno dugme na formi, pomoću koga se doziva odgovarajući makro napravljen za štampu izveštaja
Slika 5.109. Meni za definisanje akcije i odreĎenog makroa 1. Kada se ţeli kreirati makro, unosi se akcija (postoji ograničen skup akcija koje nudi Access 2000) (OpenReport). 2. Za tu akciju potrebno je navesti argumente akcije naprimer ime izveštaja (Invoice) i mesto prikaza izveštaja (Print) Makro moţe biti komponovan u sekvenci više akcija ili se moţe koristiti grupa makroa koje je korisnik sam napravio. Moguće je koristiti uslovne izraze (naprimer If...Then...Else ili Select Case naredbe). Ako je uslov zadovoljen obavlja se jedna ili više operacija a ako nije operacija (-e) se preskače. Na sledećoj slici je dat prikaz jedne serije akcija koje Microsoft Access izvodi svaki put kada se aktivira makro.
153
@ViPserbia
Slika 5.110. Meni - prikaz serije akcija koje izvodi odreĎeni makro Na primer, ako ţelite da se nekoliko makroa, koji su nekoj relaciji sprovedu odjednom. Neka je makro imenovan kao Buttons, a da su nanizana tri makroa Employes, Products i Reps. Sva tri makroa izvode otvaranje odgovarajuće forme, a makro Products izvodi još i dopunsku akciju MoveSize:
Slika 5.111. Meni - prikaz serije Makroa koji se izvode odjednom Ukoliko koristite uslovljene akcije, onda na raspolaganju stoje neke akcije ugraĎene u Accessu 2000 pri čemu se navodi kriterijum (uslov) grananja akcija. Uslovi sluţe za grananje odnosno kontrolu toka rada makroa. Uslov je logički izraz (ispunjen - TRUE ili nije ispunjen - FALSE odnosno YES/NO). Izraz moţe biti bilo kakva kombinacija matematičkih ili logičkih operatora, konstanti, funkcija, imena polja iz tabela i/ili formi, kontrola odnosno osobina (property) koje se sve ocenjuju kao JEDNA vrednost i kao takva dobija se rezultat TRUE/FALSE ili YES/NO. Sledi kratak prikaz jedne uslovljene akcije (IsNull) tako da makro "Review Products" radi akciju MsgBox i StopMacro ako se pronaĎu šifre dobavljača koje nisu vrednosti nula:
154
@ViPserbia
Slika 5.112. Meni - prikaz uslovljenog aktiviranja Makroa Microsoft Access 2000 u svom asortimanu nudi sledeće akcije:
Slika 5.113. Meni - prikaz Microsoft Access 2000 raspoloţivih akcija
155
@ViPserbia
Primer Fakultet za menadţment ţeli da sačuva evidenciju o studentima koji su uradili seminarske radove, diplomske radove i postdiplomske radove (magistarski i doktorski radovi, specijalističke studije). Potrebno je u organizacionom smislu definisati ko šta radi: 1. Operater: Mentor ili drugi zaposleni na F@M-u pomoću Exel obrasca SpisakRadova.xlt formira listu. Operater moţe dati Exel knjizi bilo koje ime. Operater dostavlja datoteku sa spiskom radova administratoru (disketa, CD, email, memory-stick,...). 2. Administrator: Svaka osoba koja je zaduţena za centralno prikupljanje spiskova i aktiviranje Access-ovog makroa za punjenje tabele u bazi SpisakRadova.mdb. 3. Administrator primljenu listu mora preimenovati u PuniListu.xls. Ako ţeli, moţe u arhivske svrhe čuvati spiskove onako kako ih je formirao operater. To znači da je ime Exel knjige PuniListu.xls rezervisano. 4. Baza podataka sa spiskom radova se nalazi u fascikli (folder) pod nazivom C:\SpisakRadova. Ovo je obavezno ime jer je makro podešen na putanju čitanja liste za punjenje na C:\SpisakRadova\PuniListu.xls. 5. Sve ostale akcije nad podacima administrator obavlja preko Access-ovog menija (switchboard), koji se pojavljuje kod otvaranja baze podataka: Dakle, obuhvat podataka je zamišljen i organizovan tako da svi asistenti odnosno mentori grupa obavljaju obuhvat podataka baziran na upotrebi Exel šablona (template) pod nazivom SpisakRadova.XLT. Dostavljanjem obuhvaćenih podataka na nekom medijumu, administrator po aktiviranju odgovarajuće baze obavi SAMO JEDNOM punjenje baze.
156
@ViPserbia
Slika 5.114. Meni - prikaz osnovnog menija za izbor posla
157
@ViPserbia
Slika 5.115. Prikaz - Izgled dela Exel-ovog šablona Podaci se pomoću makroa macLoad prebacuju iz Exel knjige PuniListu.xls u tabelu tblSpisakRadova Columns Name RadoviID F1-Redni broj spiska F2-Smer F3-Godina studiranja F4-Predmet F5-Tip rada F6-Autor F7-Naslov F8-Mentor F9-Školska godina F10-Ocena F20-Komentar
Type Long Integer Long Integer Text Text Text Text Text Text Text Text Number Memo
Size 4 4 50 50 50 50 120 50 50 50 4 158
@ViPserbia
Primer Exel knjige PuniListu.xls (osloboĎeno od nepotrebnih informtivnih poruka koje se javljaju u šablonu):
Slika 5.116. Prikaz – Primer Exel knjige PuniListu.xls
159
@ViPserbia
Slika 5.115. Prikaz – Makro koji olakšava rad macLoad Obratite paţnju da se u TransferSpreadheet akciji forsira putanja Exel-ove knjige PuniListu.xls jer se time ţeli izbeći da administrator pogreši.
160
@ViPserbia
5.10. Primena VBA (Visual Basic for Application ) Visual Basic je programski jezik orijentisan na upravljanje dogaĎajima (event procedure). U primeni uz Access pored toga što zamenjuje i makroe VBA se koristi uglavnom u sledećim situacijama: Kada se želi da upravljanje bazom kao i održavanje baze podataka bude lakše: Kako su makroi posebni objekti, izdvojeni iz formi i izveštaja, iako ih koriste, baza podataka moţe sadrţavati mnogo makroa koji odgovaraju na odreĎene dogaĎaje u formama ili izveštajima, ali to je mnogo teţe u domenu odrţavanja. Nasuprot tome, VBA je programski jezik orjentisan upravo na pisanje procedura za upravljanje dogaĎajima, a na njima su zasnovane mnoge funkcije unutar forme ili izveštaja. Ako premestite formu ili izveštaj iz jedne baze u drugu, zajedno će se preseliti i njima pridruţene procedure za upravljanje dogaĎajima. Upotreba ugraĎenih funkcija ili izrada sopstvenih funkcija: Access sadrţi u svojoj okolini mnogo ugraĎenih funkcija kao što je naprimer IPmt funkcija, kojom se moţe recimo izračunavati plaćanje po osnovu kamate. Pored toga ove funkcije moţete koristiti da obave kalulacije i bez toga da kreirate komplikovane izraze. S druge strane, pomoću VBA moţete kreirati sopstvene funkcije ili da izvršavaju izračunavanja koja prevazilaze mogućnosti ugraĎenih funkcija ili da zamene kompleksne izraze. Nadalje moţete koristiti funkcije i u samim izrazima tako da su opšte primenljive uz navoĎenje parametarskih listi sa vraćenom vrednošću. Opsluživanje poruka o greškama: Ako se ponekad pojavi nešto neočekivano dok korisnik koristi bazu podataka, Access prikazuje poruku o grešci. MeĎutim, greška moţe biti prilično misteriozna za korisnika, a naročito za one koji nisu familijarni sa Access-om. Pomoću VBA se prave procedure koje detektuju grešku i kada se ona pojavi prikazuje se odreĎena poruka koju sam programer osmisli i predloţi akciju koju korisnik treba da preduzme. Kreiranje ili manipulisanje sa objektima U većini slučajeva, pronaći ćete da je najlakše kreirati i menjati objekte preko mogućnosti koja se nudi u funkciji Design view (kod tabela, formi, upita, izveštaja ili makroa). U nekim situacijama, meĎutim, mogli bi poţeleti da manipulišete sa definicijom objekta u samom programskom kodu. VBA vam dozvoljava da radite sve manipulacije sa svim objektima raspoloţivim za javnu upotrebu od strane programera, a stoje na raspolganju u samoj bazi podataka. IzvoĎenje akcija na sistemskom nivou Moţete da izvodite naprimer RunApp akciju u makrou kojom dozivate neku aplikaciju baziranu na Microsoft Windows-u ili MS DOS-u iz vaše sopstvene aplikacije, ali makro ne omogućava da izlazite iz Accesa i da se potom ponovo vraćate u bazu podataka. Korišćenjem VBA uvek moţete
161
@ViPserbia
overiti i proveriti da li neka datoteka postoji u sistemu ili ne, a to se radi uz pomoć Automation ili dynamic data exchange (DDE) postupaka koje omogućavaju komunikaciju sa svim Windows orijentisanim aplikacijama kao što su Microsoft Excel, ili da pozivate funkcije iz Windows dynamic-link libraries (DLLs) biblioteka (naprimer kalendar). Manipulacija slogovima u jednom trenutku: Moţete koristiti VBA za obradu slogova "korak-po-korak" u jednom trenutku (naprimer za takozvane paketne obrade (batch processing)) i da obavite operacije nad jednim slogom. Sa druge strane, makroi rade sa svim slogovima bez izuzetka u jednom trenutku. Prenos argumenata u vaše VBA procedure: Moţete postaviti argumente za potrebe makro akcija (u donjem delu Macro prozora) kod kreiranja makroa, ali ne moţete ih menjati tokom izvoĎenja makroa. Ta vrsta ograničenja ne postoji, ako koristite VBA, jer moţete napraviti procedure u koje prenosite spisak argumenata (varijabli), a kao rezultat dobijate povratnu akciju procedure. U nastavku su date dve slike. Na prvoj se prikazuje kako se doziva VBA okruţenje, a na drugoj se daje primer sadrţine. VBA omogućava da tokom rada sa bazom podataka uključite i tzv. debugger (komponenta kojom se prati izvoĎenej programa korak-po-korak tako da se prave prekidne tačke ili se program zasutavlja na mestu greške npr. u sintaksi i sl.). Detalji rada sa VBA komponentom su sadrţani u posebnom predmetu.
Slika 5.116. Način pozivanja VBA okruţenja
162
@ViPserbia
Slika 5.117. Primer koji pokazuje sadrţinu VBA okruţenja Ovim izlaganjem se ne završava zadatak studenata, nego oni treba da dalje izučavaju i stiču šira znanja o Access-u i osposobljavaju se za rad sa drugim mogućnostima Access-a od kojih su mnoge objašnjene u okviru Access-ovog Help-a.
163
@ViPserbia
5.11. Pravljenje poštanskih nalepnica U okviru ovog segmenta ćemo opisati postupak izrade poštanskih nalepnica primenom Accessa i njegovih čarobnjaka koji su se pokazali veoma pogodnim za ovu namenu. Pretpostavimo da ţelite da pošaljete neke informacije ili čestitke svojim poslovnim partnerima. Umesto da se na svaku kovertu kucaju kompletni adresni podaci poslovnih partnera, oni se primenom odgovarajućeg čarobnjaka mogu pozivati iz Access baze poslovnih partnera i štampati na nalepnice ţeljenog oblika i veličine i tako odštampani zalepiti na koverte. Na taj način se obezbeĎuje mnogo veća efikasnost u radu, kao i veća tačnost. Pored toga obezbeĎena je i mogućnost sortiranja u skladu sa ţeljama ili pak zahtevima korisnika. U Accessu 2000 komplet poštanskih nalepnica je samo vrsta izveštaja čiji izgled odgovara nalepnicama. Izveštaj u vidu poštanskih nalepnica uzima imena i poštanske adrese iz baze podataka, sortira ih zadatim redosledom i priprema ih za format nalepnica koji izaberete. Pomoćna alatka Label Wizard vas vodi kroz postupak pravljenja izveštaja sa poštanskim nalepnicama. Izveštaj koji će posluţiti kao poštanska nalepnica dizajniran je kao poštanska nalepnica (sa odgovarajućim tipom slova, rasporedom i redosledom sortiranja), ali nema imena i adrese koje bi se štampale na nalepnicama za koverte. Ti podaci se i dalje nalaze u tabeli poslovnih partnera koja se aţurira u skladu sa potrebama svakodnevnog posla u preduzeću. Svaki put kada se koristi izveštaj sa poštanskim nalepnicama, Access uzima najnovije podatke iz baze podataka. Postojeći dizajn izveštaja biće sačuvan i moţe ponovo da se koristi, ali su podaci uvek aţurni. U ovom primeru ćemo pokazati kako da uz pomoć čarobnjaka Label napravite i štampate nalepnice sortirane po poštanskim brojevima. Stavite nalepnice u štampač i sada ćemo videti kako ih pripremite. Postupak je sledeći: - U prozoru Database mora da bude prikazana lista izveštaja. - Na paleti alatki prozora Database pritisnite dugme New. Otvara se okvir za dijalog New Report. - Iz liste sa desne strane okvira za dijalog New Report izaberite Label Wizard. - Otvorite padajuću listu New Report pritiskom na dugme sa strelicom i izaberite na primer tabelu vaših poslovnih partnera ili moţemo izabrati i našu kreiranu tabelu Klijenti.
@ViPserbia
Tabela Klijenti sadrţi sve informacije o poslovnim partnerima, uključujući imena i adrese. - Pritisnite OK. Otvara se prvi okvir za dijalog čarobnjaka Label i vi sad moţete da izvršite izbor odgovarajuće nalepnice. Ako nijedna nalepnica sa liste ne odgovara vašim potrebama, sami definšite dimenzije prema nalepnicama koje koristite. Access ima obimnu biblioteku standardnih formata nalepnica sortiranih po proizvoĎaču i dimenzijama u engleskim jedinicama mere (inčima) ili jedinicama metričkog sistema (milimetrima) za štampače koji koriste pojedinačne listove papira ili beskonačnu štampu. Kada utvrdite koji format nalepnica je za vas najprikladniji - U okviru sa listom Filter By Manufacturer izaberite nalepnicu po proizvoĎaču - Za jedinicu mere izaberite English ili cm po ţelji. - Pod Product number izaberite red koji odgovara tipu nalepnice koji ste odabrali. - Pritisnite Next. Otvara se drugi okvir za dijalog čarobnjaka Label koji vam omogućava detaljnije doterivanje nalepnice. Tak onbaprime za nalepnice koje pravite moţete da izaberete bilo koji tip slova, koji je instaliran na vašem računaru i bilo koju boju koju podrţava štampač. Izbor tipa slova moţe da zavisi od vrste štampača. Na primer, neki štampači podrţavaju za više veličina slova isti font ili više atributa formatiranja (polucrno ili kurziv) od drugih štampača. Dalje doterivanje se moţe ostvariti u pogledu teksta. Da bi poštanske nalepnice imale poseban i lep izgled i da bi na najbolji način odrazile imidţ preduzeća, moţda moţete koristiti kurzivni font Century Gothic Light veličine 9 tačaka. - U drugom okviru za dijalog čarobnjaka Label, iz liste Font Name izaberite Century Gothic light. Pretpostavimo da kao poruku ţelite da dodate reč Informaciju. Reč Informacija u okviru sa primerom se ispisuje se fontom Century Gothic light. - Iz liste Font Size izaberite 9. Veličina slova reči Informacija u okviru sa primerom se menja u 9 tačaka. - Potvrdite polje Italic. Reč Informacija se ispisuje kurzivom. - Pritisnite Next. 165
@ViPserbia
Otvara se treći okvir za dijalog čarobnjaka Label, koji vam omogućava odreĎivanje rasporeda elemenata nalepnice. Iz tabele Klijenti moţete da izaberete bilo koje polje i da ga stavite na čarobnjakov prototip nalepnice onako kako vi ţelite da odgovarajuća informacija bude odštampana. Pretpostavimo da ţelite da koristite raspored podataka u tri reda sa punim imenom kupca i standardnom adresom u dva reda. Takav raspored tada primenjujete na nalepnicu. Osenčena traka pokazuje koji red treba da popunite na nalepnici. Pored toga moţete da izaberete naziv polja i zatim pritisnete na Add. - U trećem okviru za dijalog čarobnjaka Label, iz liste Available Fields sa dva pritiska na taster miša izaberite FirstName. Polje FirstName se dodaje prvom redu prototipa nalepnice i na kraju polja se pojavljuje kursor. - Pritisnite razmaknicu. Iza polja FirstName na nalepnici se pojavljuje prazno mesto. - U listi Available Fields, pritisnite dva puta last Name. Polje lastName dodaje se iza polja FirstName u prvom redu nalepnice, sa jednim razmakom izmeĎu dva polja. Ako pogrešite, izaberite red na prototipu nalepnice i pritisnite taster Backspace da biste unetu vrednost uklonili. - Na kraju prvog reda nalepnice pritisnite Enter. Kursor i osenčena traka premeštaju se u drugi red prototipa nalepnice. - U drugom redu dodajte polje Ulica i pritisnite Enter. - U trećem redu dodajte polja Mesto i Poštanski broj. Unesite zarez i razmak od jednog mesta izmeĎu polja Mesto i razmak izmeĎu polja Mesto i Poštanski broj. Pritisnite Enter. - U četvrtom redu dodajte polje Country. - Pritisnite Next. Pojavljuje se četvrti okvir za dijalog čarobnjaka label. Sortiranje nalepnica prema poljima Tabelu Klijenti moţete da sortirate prema bilo kom polju. Moguće je sortiranje i prema više polja. Na primer, moţete da sortirate po prezimenu a zatim po imenu da biste dobili sve nalepnice sa prezimenima sortiranim abecednim redosledom i na 166
@ViPserbia
kojima su sva ista prezimena sortirana abecednim redosledom po imenu. Da biste grupisali sva pisma čije su adrese u istom regionu, nalepnice sortirajte po poštanskim brojevima. - U četvrtom okviru za dijalog čarobnjaka label, iz liste Available Fields pritisnite dva puta Poštanski broj. Listi Sort By dodaje se polje Poštanski broj. - Pritisnite Next. Pojavljuje se poslednji okvir za dijalog čarobnjaka label. Access 2000 predlaţe naziv labels Klijenti za izveštaj sa poštanskim nalepnicama i daje vam mogućnost da vidite kako će nalepnice izgledati kada se odštampaju ili da ih izmenite. Sada ćemo videti kako da snimite izveštaj i štampate nalepnice kad god vam trebaju. - U poslednjem okviru za dijalog label izaberite opciju See the labels as they will look printed i pritisnite Finish. Izveštaj sa poštanskim nalepnicama se snima kao labels Klijenti i otvara se u prikazu Print Preview. Ukoliko ţelite da odštampate taj izveštaj: - Na paleti alatki Print Preview pritisnite dugme Print. Access štampa izveštaj labels Klijenti direktno na kompletu nalepnica koje ste ubacili u štampač. Kada se završi štampanje: - U prozoru Report pritisnite dugme Close da biste zatvorili izveštaj.
167
@ViPserbia
5.12. Specifikacije za baze podataka u Microsoft Access-u Atribut
Vrednosti maksimuma
Veličina baze u Microsoft Access-u (.mdb datoteka)
2 GB - prostor potreban za sistemske objekte ugraĎene po definiciji u .mdb bazu.
Broj objekata u bazi podataka
32.768
Moduli (uključujući forme i izveštaje sa svojstvom HasModule postavljen na True)
1.000
Broj znakova u imenovanju bilo kog objekta MS Access-a
64
Broj znakova u lozinci
14
Broj znakova u imenu korisnika ili imenu grupe
20
Broj konkurentnih korisnika nad jednom bazom podataka
255
Specifikacije za tabele u Microsoft Access-u Atribut
Vrednosti maksimuma
Broj znakova u imenovanju tabele
64
Broj znakova u imenovanju kolone (polja)
64
Broj polja u jednoj tabeli
255
Broj otvorenih tabela istovremeno
2048; stvarni broj moţe biti i manji zato što postoje tabele koje Microsoft Access otvara za svoje potrebe (interno)
Veličina tabele
2 GB - prostor potreban za sistemske objekte ugraĎene po definiciji u .mdb bazu.
Broj znakova u polju tipa Text
255
Broj znakova u polju tipa Memo
65.535 kada se podaci unose preko korisničkog interfejsa; 1 GB memorisanih znakova ako se oni unose preko programiranog interfejsa
Veličina polja OLE objekta (npr. JPG,...)
1 GB
Broj indeksa (ključeva) po jednoj tabeli
32
Broj polja u jednom indeksu
10
168
@ViPserbia
Broj znakova u poruci za validaciju unosa
255
Broj znakova u pravilima za validaciju
2,048
Broj znakova u opisu tabele ili opisu polja
255
Broj znakova u slogu (isključena su Memo 2,000 i OLE objektna polja) Broj znakova u postavkama svojstava polja (field property)
255
Specifikacije za upite u Microsoft Access-u Atribut
Vrednosti maksimuma
Broj prisilnih relacija
32 po jednoj tabeli minus broj indeksa koje su nad tabelom sa poljima ili kombinacijama polja a koje nisu uvučene u relacije
Broj tabela koje učestvuju u upitu
32
Broj polja koja učestvuju u jednom skupu slogova
255
Veličina skupa slogova
1 GB
Ograničenje sorta
255 znakova u jednom ili više polja
Broj nivoa u ugnjeţdenim upitima
50
Broj znakova u ćeliji u rešetki za izradu upita
1.024
Broj znakova za parametar u parametrizovanom upitu
255
Broj AND uslova u WHERE ili HAVING klauzuli SQL upita
99
Broj znakova u SQL naredbi
pribliţno 64.000
169
@ViPserbia
Specifikacije za izveštaje i forme u Microsoft Access-u Atribut
Vrednosti maksimuma
Broj znakova u labeli (nalepnici)
2.048
Broj znakova u tekstualnoj kućici (text box)
65.535
Širina forme ili izveštaja
55.87 cm (22 in.)
Visina sekcije ( Section height )
55.87 cm (22 in.)
Visina svih sekcija + zaglavlja sekcija (u Design view funkciji)
508 cm (200 in.)
Broj nivoa u ugnjeţdenim formama ili izveštajima
7
Broj polja ili izraza koje moţete da sortirate ili grupišete u jednom izveštaju
10
Broj zaglavlja (header) i podnoţja (footer) u izveštaju
1 header/footer po izveštaju; 1 header/footer po stranici; 10 header-a/footer-a po grupi
Broj štampanih stranica koje se mogu generisati po jednom izveštaju
65.536
Broj kontrola i sekcija koje se mogu dodati u toku ţivotnog veka forme ili izveštaja - report
754
Broj karaktera u SQL naredbi koje sluţe kao osobine Recordsource ili Rowsource forme, izveštaja-reporta, ili kontrole (oboje .mdb i .adp)
32,750
Specifikacije za makroe u Microsoft Access-u Atribut
Maksimum
Broj akcija u makrou
999
Broj znakova u uslovu
255
Broj znakova u komentaru
255
Broj znakova u argumentu akcije
255
170
@ViPserbia
6. Rukovanje bazama podataka Ova oblast je vrlo vaţna sama za sebe i mnoge tehnike su bile razvijene u te svrhe počevši od vrlo jednostavnih podrutina do celih sistema za rukovanje bazom podataka. Obzirom da se pod bazom podataka podrazumeva skup tabela koje se odnose na istu oblast, u tom slučaju na primer tabele o ličnim podacima radnika, plaćanjima, radu i efikasnosti itd. mogu formirati bazu podataka radnika. Takva baza podataka ima daleko veće zahteve sa aspekta obrade podataka nego pojedine tabele pošto upit ili unos nekog podatka mogu zahtevati nalaţenje uporednih elemenata u nekoliko raznih tabela simultano. Organizacija i rukovanje bazom podataka u on line reţimu rada je svakako jedna od kritičnih oblasti u celokupnoj postavci bilo koje baze podataka.. U izboru najadekvatnijih oblika u rukovanju bazom podataka moraju biti uzeta u obzir sledeća ključna pitanja: - raspoloţivost memorijskog medija - lakoća i efikasnost programiranja - način korišćenja baze podataka, - frekvencija pristupa, - zahtevano vreme odgovora, - frekvencija i obim aţuriranja itd. - cena programiranja i korišćenja, plus cena baza podataka - sigurnost koja podrazumeva odrţavanje integriteta baza podataka, autorizaciju pristupa, zaštitu od dupliciranja itd. Projektant prema tome ima veoma teţak zadatak u traţenju najboljeg rešenja uzimajući u obzir sve ove faktore. Pored toga analiza moţe značajno varirati od jednog slučaja do drugog. Do pojave PC računara baze su uglavnom bile smeštene na centralnim – host računarima. MeĎutim sa uvoĎenjem PC-a u svakodnevno poslovanje i baze su se počele koristiti na PC opremi. Obrada baza podataka u PC i PC/LAN mreţama se pokazala veoma pogodnom za segmente ili odelenja velikih firmi. Naime niska cena u poreĎenju na prethodne i visoka raspoloţivost ovih sistema su im davali značajnu prednost u odnosu na host rešenja. Izrada aplikacija na PC opremi je bila takoĎe brţa, jednostavnija i jeftinija. Iako se obrade na hostu mogu izvršiti brţe nego na PC računaru zbog veće raspoloţivosti PC računara svakom pojedinom korisniku je bilo brţe da obradu izvrši kod sebe na PC- u nego da čeka raspoloţiv slobodan termin na host-u. 171
@ViPserbia
Male korisničke, na PC-u bazirane baze, podataka su prerastale u PC-LAN bazirane baze podataka. Ove baze i brzina pristupa i obrade su bile zadovoljavajuće sem ako su u pitanju bile veoma velike baze podataka ili pak kada je trebalo povezati nekoliko takvih mreţa kada se kao problem javljala redundantnost podataka, dupliciranje ili povećana neispravnost zbog unosa od strane mnogo različitih korisnika i nejedinstvene kontrole unosa. Pored toga kod različitih upita i pretraţivanja dešava se da pojedini korisnici ne poznajući dobro način rada sa bazama podataka blokiraju ili prenose često velike blokove podataka usporavajući ili ometajući značajno rad ostalih korisnika.
172
@ViPserbia
7. Distribuirne baze podataka Sa razvojem mreţa javila se potreba da se baze podataka mogu koristiti od strane korisnika koji su se nalazili na raznim često i veoma udaljenim lokacijama. MeĎutim dok su se baze podataka u početku nalazile na jednom mestu u glavnom, odnosno centralnom računaru, kasnije sa daljim razvojem računarskih mreţa i mreţne distribucije - podele računarskih resursa, javila se potreba da se i baze podataka raspodele – distribuiraju na više lokacija odnosno na nekoliko različitih računarskih resursa. Tako su razvijene takozvane distribuirane baze podataka koje su smeštene ponekad i na par stotina računara sa pojedinim segmentima baze pri čemu korisnik koji koristi bazu ima utisak da su svi ti podaci smešteni na jednom mestu. Distribuirane baze podataka su uvedene prevashodno zbog: Povećane raspoloţivosti podataka Korisnik moţe pristupiti podacima lokalno ili nekom udaljenom čvorištu preko tzv. "poveznice baze podataka" (data base link), Ovakav tip organizovanja baza podataka je sve više u porastu zahvaljujući ubrzanom razvoju brze komunikacione infrastrukture. Autor teorije relacionih baza podataka C. J. Codd je koncipirao i 12 pravila za distribuirane baze podataka koje se sve više danas implementiraju od strane proizvoĎača softvera za upravljanje bazama podataka: Pravilo 1: Nezavisnost lokalnog sedišta baze podataka: Svako sedište u sistemu DDB – Distributed Data Base – distribuirane baze podataka bi trebalo da funkcioniše nezavisno i da se pri tome poštuju i očuvaju vitalne funkcije upravljanja bazom podataka: - bezbednost, - kontrola konkurentnosti pristupa podacima - arhiviranje - oporavak podataka Pravilo 2: Nezavisnost centralnog sedišta baze podataka: Svako sedište u sistemu distribuiranih baza podataka funkcioniše nezavisno u odnosu na centralno sedište i u odnosu na sva udaljena sedišta.
173
@ViPserbia
Napomena: Sva sedišta bi trebala da imaju iste mogućnosti, čak i ako neko sedište ne moţe da zadovolji sve te mogućnosti u jednom trenutku. Pravilo 3: Nezavisnost pri greškama bilo koje vrste: Softver za upravljanje bazama podataka bi trebalo da bude neosteljiv na greške čvora ili čvorišta tako da ostatak čvorišta i softver za upravljanje distribuiranim bazama podataka (DDBM) kao celina moţe da nastavi sa radom. Napomena: Na sličan način DDBMS – Distributed Data Base Management System bi trebalo da nastavi sa radom i kada se dodaju nova čvorišta. Pravilo 4: Transparentnost lokacije: Korisnici ne bi trebalo da imaju nikakvo saznanje o lokaciji podataka prilikom pretraţivanja. Pravilo 5: Transparentnost fragmentacije: Korisnik ne bi trebalo da niti da ima ikakvo saznanje o fragmentaciji (iscepkanosti) distribuirane baze podataka. Korisnik moţe pretraţivati podatke bez potrebe da zna da li su oni fragmentirani unutar distribuirane baze podatka. Pravilo 6: Transaparentnost replikacije: Korisnik bi trebalo da bude u mogućnosti da koristi distribuiranu bazu podataka bez saznanja da li su ili ne podaci replicirani unutar sistema baze podataka. Pravilo 7: Obrada distribuiranih upita: Trebalo bi da postoji mogućnost upita da se izvede u bilo kom čvorištu sistema za upravljanje distribuiranom bazom podataka koja sadrţi relevantne podatke traţene preko upita. Nekoliko čvorišta moţe učestvovati u odgovoru na korisnikov upit a da pri tome korisnik ne mora da zna gde je pronaĎen podatak (u slučaju zadovoljavanja kriterijuma u selekciji podatka). Pravilo 8: Distribuirana obrada transakcija: Transakcijom se moţe pristupiti i menjati podatak na nekoliko različitih sedišta unutar sistema distribuirane baze podataka bez saznanja i učešća korisnika tokom izvoĎenja transakcije.
174
@ViPserbia
Pravilo 9: Nezavisnost hardvera: Distribuirana baza podataka i njoj pridruţeni sistem za upravljanje distribuiranom bazom podataka bi trebalo da se implementira na bilo kojoj pogodnoj paltformi tj. na bilo kom računarskom sistemu sa odgovorajućim hardverskim resursima bez obzira na to koja kompanija je proizvela računar. Naţalost jedan broj današnjih sistema distribuiranih baza podataka još uvek ne zadovoljavaju ovaj cilj, tj. ovo pravilo. Pravilo 10: Nezavisnost operativnih sistema: Distribuirana baza podataka i njoj pridruţeni sistem za upravljanje distribuiranom bazom podataka bi trebali da budu sposobni da se implementiraju na bilo kom pogodnom operativnom sistemu tj. operativni sistem bi trebalo da bude sposoban za opsluţivanje različitih i mnogobrojnih korisnika. Napomena: Danas, ovaj uslov zadovoljavaju Windows 2000 i XP i različiti varijeteti Unixa (uključujući i Linux). Pravilo 11: Mreţna nezavisnost: Distribuirana baza podataka i njoj pridruţeni sistem za upravljanje distribuiranom bazom podataka bi trebali da budu sposobni da se implementiraju na bilo kojoj pogodnoj mreţnoj platformi. Napomena: U današnje vreme to su uglavnom sistemi za upravljanje distribuiranom bazom podataka koji se izvode na Windows 2000 ili XP operativnim sistetima, na raznim varijantama Unixa (preko Ethernet mreţe) i na Novell mreţama. Pravilo 12: Nezavisnost baze podataka: Dizajn distribuirane baze podataka bi trebala da pokaţe sposobnost da bude podrţana sa zadovoljavajućim performansama i sa sofisticiranim alatima koje obezbeĎuju proizvoĎači softvera za upravljanje distribuiranim bazama podataka. ProizvoĎači softvera i hardvera se dovijaju na razne načine da pronaĎu optimalne algoritme za brzo i efikasno pretraţivanje podataka u sistemu upravljanja distribuiranom bazom podataka odnosno pronalaţenje algoritama za izbegavanje konflikata i zaglavljenih (deadlock) situacija. Distribuirane baze podataka su najosetljivije na pitanju pojave otkaza u nekom od hardverskih resursa. Pri dizajnu distribuirane baze podataka polazi se od toga kao da je ona centralno smeštena u jednoj bazi a preko mehanizama replikacije i paralelizma 175
@ViPserbia
(proširenje Coddovih 12 pravila) se u implementaciji obavlja distribucija. Paralelizam jednostavno znači da se u sistemu distribuirane baze podataka definišu strateške tabele na raznim lokacijama i svaka promena u tabeli na jednoj lokaciji se paralelno obavlja u istim tabelama na drugim lokacijama. Replikacija podataka omogućava raspoloţivost podataka u slučajevima havarija a paralelizam omogućava bolju performantnost distribuirane baze podataka. Primer: Kompanija "Turistička organizacija" Sistem za distribuiranu obradu u rezervaciji karata Klijent
Klijent
Klijent
Klijent
Kontroler toka rada
Menadžer transakcijama
Menadžer resursima
Menadžer resursima
Menadžer resursima
Menadžer resursima
Letovi
Hoteli
Vozila
Korisnici
CS 347
Lecture 2
3
Sedište baze podataka London
HongKong
Beč
Pariz
Slika 7.1. Primer sistema sa distribuiranom bazom podataka Ovakva organizacija baze podataka ima smisla kod multinacionalnih ili transnacionalnih kompanija sa sedištima na nekoliko kontinenata. Podrazumeva se da se u ovakvoj koncepciji primenjuje tehnika replikacije i paralelizma.
176
@ViPserbia
Zahvaljujući Internetu, pojavila se mogućnost i n-slojne (n-tier) arhitekture dizajna baze podataka pa se opet razmišlja o napuštanju tehnologije distribuiranih baza podataka.
177
@ViPserbia
8. Rad u mreţi Savremeni način poslovanja podrazumeva da se rad informacionih sistema u većini slučajeva odvija na mreţama računara, a to automatski podrazumeva da i same baze kao nosioci informacionih podataka moraju da rade u mreţi. Većina baza podataka poseduje ovu mogućnost, a one baze kod kojih nije na vreme razvijena ta opcija su nestale sa trţišta. Pri tome su kod rada u mreţi prisutne dve osnovne varijante. U jednoj varijanti baza podataka je smeštena na jednom – centralnom računaru tj. na njegovim hardverskim resursima, a korisnici, koji mogu biti rasporeĎeni bilo gde u računarskoj mreţi, pristupaju tim podacima i u zavisnosti od nivoa dozvole korišćenja baze izvode razne manipulacije sa podacima u bazi počevši od pretraţivanja baze pa do aţuriranja pojedinih podataka ili pak celih segmenata baze. U drugoj varijanti baza je rasporeĎena na nekoliko različitih računara i njihovih hardverskih resursa na raznim segmentima mreţe i takva varijanta baze se naziva distribuirana baza podataka. Već kod prvih mreţa koje su bile namenjene za širu upotrebu pojavio se zahtev da se koriste baze podataka. Tako naprimer kod nas su za manji broj računara bile veoma široko rasprostranjene mreţe sa operativnim sistemima tipa Novell, Unix, Xenix i na njima su veoma dobro funkcionisale pa čak i danas funkcionišu neke od baza podataka kao što su Clipper, Fox pro, ZIM, Progress itd. U većim mreţama sa većim brojem računara bile su korišćene, a i danas se koriste baze podataka kao što su Oracle, Ingres, Informix itd.
Rad u mreži - primena Tradicionalna 2-slojna arhitektura ili klijent-server arhitektura ima svoje slabosti. Zbog intenzivne interakcije izmeĎu klijenata i servera dolazi do preopterećenja komunikacija. Kompanije su zbog toga bile primorane da koriste skupe iznajmljene veze sa širokim opsegom prenosa podataka. Pored toga, poseban problem je bio odrţavanje aplikativnog sistema koji je morao imati svoju sliku i na svakom klijentu: Poznata je priča o Oracle-ovoj aplikaciji Application (obuhvatala je standardno poslovanje svake kompanije: knjigovodstvo, zalihe, fakture, kadrovi, zarade itd.) koja se u toku godine menjala i do četiri puta pa su ekipe jedne kanadske čeličane koja je imala oko 60 lokacija morale četiri puta godišnje da obilaze lokaciju i rade instalaciju dopune ove aplikacije na klijentima (ukupno oko 650 klijenata)!
178
@ViPserbia
Osim toga, softverska arhitektura u klijent-server (2-slojnoj) arhitekturi je nepodesna za elektronsko poslovanje. Pojavila se nova filozofija za rad sa bazama podataka u mreţi posredstvom Internet (Web) infrastrukture koja je pruţala veću fleksibilnost: n-slojna (u početku 3slojna arhitektura). Ovakav rad podrazumeva da se funkcionalnost aplikacije deli u tri sloja koji su meĎusobno nezavisni, a na taj način se omogućava lakša integracija poslovanja u okviru elektronskog poslovanja: Sloj 1: Prezentaciona logika aplikacije (odnosi se na tzv. Web servere na prednjem kraju (front-end)) Sloj 2: Poslovna logika aplikacije (odnosi se na servere opšte namene) Sloj 3: Upravljanje bazom podataka (odnosi se na servere koji su domaćini baze podataka ili Web server na zadnjem kraju (back-end)). Osnovna ideja uvoĎenja ove tehnologije je značajno smanjenje troškova potrebnog hardvera za realizaciju uz povećanje performantnosti korišćenjem brzih komunikacionih linija sa naglaskom na upotrebu Internet infrastrukture (smanjenje troškova najma iznajmljenih vodova). Pored toga, uvoĎenjem ovakve tehnologije trebalo je da se omogući bezbednost pristupa podacima (autentifikacija, autorizacija i kriptovanje pristupa) i transakciona obrada (rad u realnom vremenu) unutar Interneta i Intraneta. Dopunski zahtev je bio i interoperabilnost raznorodnih proizvoĎača hardvera i softvera. U nastavku je dat pregled današnje situacije na trţištu n-slojne arhitekture: Većina ponuĎača se u početku više orijentisala na Javu kao programski jezik i platformu za razvoj n-slojne arhitekture. Klijent strana: - Java VM (Virtual Machine) sa pratećim Javinim komponentama koje omogućavaju Servlet korisničkog interfejsa i Servlet servera - HTTP protokol osposobljen sa pratećim Web Internet pretraţivačem (Netscape Navigator, Microsoft Internet browser, Sun-ova HotJava, Opera, …), - Preko Ethernet mreţe (TCP/IP protokolom) (LAN ili Internet ili po pozivu (dial-up)) se uspostavlja komunikacija sa serverom,
179
@ViPserbia
Server strana (komponente) realizovane na raznim paltformama operativnih sistema (UNIX, Sun Solaris, Windows 2000 ili XP, AS/400, Digital-VMS, IBM-MVS, Linux-Red Hat ili SuSe ili Mandrake). Serveri imaju instaliran JDK (Java Development Kit 2.1) za podršku ove tehnologije - Web server (Apache, Orion Web server, Microsoft IIS, Java 2 Enterprise Edition, Sun Java Web server,…) - Servlet server (neki navedeni proizvoĎači Web server softvera uključuju i ovu komponentu), - Servleti za korisnički interfejs (pišu ga sami korisnici), - Aplikativni softver za pristup bazi podataka (pišu ga sami korisnici), Baza podataka - Tehnologija relacionih baza podataka (centralizovane ili distribuirane) (Oracle, Microsoft SQL, Sybase, Ingres, Informix, IBM DB/2, MySQL, PostgreSQL (RDBMS), - Tehnologija objektno orijentisanih baza podataka (OODBS – Object Oriented Data Base System). Prednosti n-slojne arhitekture: Iako su otklonjeni problemi 2-slojne arhitekture, ova tehnologija stvara i svoje probleme, ali su oni još uvek takvi da ih prednosti umanjuju.
Potpuno razdvajanje kontrole korisnikovog interfejsa i prezentacije podataka od aplikativne logike. Ovo razdvajanje omogućava da puno klijenata ima mogućnost pristupa raznim apliakcijama smeštenim na serveru bez narušavanja performansi. Aplikativni kod nije smešten na klijentu što omogućava centralizovanu kontrolu izmene aplikativne logike. Redefinisanje strategije smeštanja podataka bez uticaja na klijenta odnosno klijent i ne zna način logičkog i fizičkog organizovanja baze podataka (RDBMS i/ili OODBS). Ovo obezbeĎuje budućnost n-slojnoj arhitketuri jer neće biti pod uticajem prelaska kompanije sa RDBMS na OODBS tehnologiju organizovanja podataka. U dobro dizajniranom informacionom sistemu, klijent će još uvek pristupati preko dobrog i stabilnog interfejsa sa ugnjeţdenim i nevidljivim delovima o smeštanju podataka. Poslovne objekte i memorisanje podataka bi trebalo što više obuhvatiti na jednom fizičkom mestu, na jednom serveru. To omogućava da se preopterećenje mreţe umanji zbog eventualnih kompleksnih zahteva za
180
@ViPserbia
podacima od strane klijenta. Bolje rečeno, klijent dobije samo rezultate koji su mu potrebni o poslovnom objektu unutar poslovne funkcije. Za razliku od 2-slojnog modela, gde se podacima pristupalo kao javno dostupnim, poslovni objekti mogu da se smeste unutar aplikativne logike i da se proglase "servisom" (uslugom) unutar mreţe. Na primer, identifikacioni broj moţe se proveravati po modulu 10 ili 11, a kalkulacija ne mora biti uraĎena na serveru nego na klijentu kao standardni servis tog klijenta. Serveri su osetljivi delovi sistema tako da autorizacija mora biti maksimalno pouzdana i pojednostavljena prilikom naleta na stotine klijenata. Takvi algoritmi i rešenja već postoje na trţištu. Upotreba jeftinih servera u grozdu (cluster) omogućava da se dinamički balansira preopterećenje servera. Najvaţnija i najkorisnija pogodnost n-slojne arhitekture jeste jednostavna izmena komponenti aplikativne logike na strani servera bez prenošenja izmene klijentu. To je bila noćna mora onog dela kompanije koja se bavila razvojem i odrţavanjem klijent-server modela.
Moguće šeme prikaza n-slojne arhitekture:
Dvoslojna arhitektura Sloj 1:
KLIJENT
Sloj 2: SERVER
Server obavlja sve operacije
M REŢ A Baza podataka
Slika 8.1. Primer dvoslojne arhitekture
181
@ViPserbia
3-slojna arhitektura Sloj 1: KLIJENT
Sloj 2: Server front-end
Sloj 3: Server baze back-end
Aplikativni server prebacuje obradu na sloj 3
Baza podataka
Slika 8.2. Primer troslojne arhitekture
n-slojna arhitektura Optimizirano za isporuku Web stranice
Programira se (kodira) za specifičnu namenu poslovne funkcije
Upravlja i podešava DBA
Slika 8.3. Primer n - slojne arhitekture n – slojna arhitektura Odvajanje klijenta od servera je pruţalo programerima veliku pomoć jer oni više nisu bili vezani za resurse jedne mašine kod izvršavanja njihovih zadataka - poslova.
182
@ViPserbia
Resursi i implementacija su mogli biti pomereni na računar koji je na najbolji način mogao da ostvari postavljeni zadatak. U stvari aplikacije sa bazama podataka su rasle u svojoj kompleksnosti pa je postalo više nego očigledno da će biti potrebne višestruke klase servera. Relacione baze podataka su uvele mogućnost da izvrše obradu tako da je administrator baze mogao da ugradi pravila integriteta i zaštite. Aktivatori i memorisane procedure su počeli da izgledaju kao mali programi u punom smislu reči. U isto vreme je postalo očigledno da su baze podataka zahtevale više obrade nego što je to striktno bilo potrebno sa aspekta integriteta podataka. One su uvele pravila poslovanja: jedinice obrade ili algoritme koji predstavljaju odreĎeni koncept vaţnosti za organizacije koje koriste baze podataka. Pošto su poslovna pravila postala široko prihvaćena potrebno ih je jednom ugraditi na centralni upravljački server. Pošto ona nisu direktno vezana za integritet podataka ponekad nije jasno da li bi ona trebala biti implementirana u relacione baze podataka primenom odgovarajućih alata i jezika orijentisanih prema podacima. Podaci su smešteni na jedan ili više servera podataka. Samo oni programi koji su potrebni za pristup podacima i odrţavanje integriteta baze se implementiraju na ovom sloju. Ovo uključuje SQL sistem za upite i rukovanje transakcijama za komercijalne softvere kao i za aktiviranje i memorisanje procedura napisanih za administratore baza podataka MeĎutim nasuprot modelu Klijent – server ova aktiviranja i memorisanja su ograničena na aspekte upravljanja integritetom podataka koji se nalaze u ovom sloju. Poslovna pravila su pomerena na nivo aplikacione logike, ponekad preferisane kao poslovni servis ili srednji nivo. Pohranjene procedure u bazi podataka se ponekad koriste za implementaciju i pojačanje poslovnih pravila. Dok ovo moţe da vodi poboljšanju performansi, pristup ne ide u korak sa osnovnim konceptom n-slojne arhitekture gde se niz za podatke n-tog sloja striktno čuva za podatke. Izraz n-ti sloj dolazi od činjenice da je aplikacioni logički sloj-nivo podeljen na dalje logičke nivoe namenjene jednom ili drugom zadatku – poslu. Aplikacioni nivo je veoma retko homogen. 183
@ViPserbia
Neki programeri vide podelu nivoa kao tri nivoa dok drugi vide razne klase aplikacionih logika kao individualne nivoe. Podela zadataka u tri ili više nivoa donosi sledeće pogodnosti: - Podela prezentacije prema funkciji. - Sposobnost optimizacije svakog nivoa kao nezavisne celine radi poboljšanja performansi. - Neograničen paralelalizam u vreme razvoja - Sposobnost za izbor odgovarajuće platforme za svaki pojedini posao zadatak
184
@ViPserbia
9. Bezbednost baze Bezbednost baze je jedan od veoma vaţnih elemenata o kojima se mora voditi računa prilikom eksploatacije neke baze. Pre nego što se neka baza preda korisnicima na korišćenje mora se definisati primenom odgovarajućih identifikacionih metoda koji korisnici će imati prava pristupa pojedinim podacima ili grupama podataka u smislu dobijanja potrebnih podataka i pregleda, kao i koji korisnici će imati prava pristupa bazi i pojedinim podacima ili grupama podataka u smislu mogućnosti da menjaju bazu ili neke parametre, relacije ili polja u bazi. Bezbednost sa aspekta prava pristupa Kada neki korisnik kreira bazu, programski paket baze mu dodeljuje sva prava manipulacije i kontrole nad tom bazom, a ista prava dobijaju i svi ostali korisnici sistema. U realnim situacijama, meĎutim, svi korisnici nemaju i ne treba da imaju ista prava pristupa bazi. U tom cilju, baza pruţa izdiferencirane metode dodeljivanja i provere prava pristupa, na nivou baze, relacija i pogleda, za svakog korisnika posebno. Vrste prava pristupa Kako je već pomenuto prava pristupa dodeljuju se preko liste prava pristupa (Access Control List), u kojoj se za celu bazu, kao i za objekte u njoj, navodi ko im sme pristupiti i kakve radnje sme da radi. Sličan pristup problemima bezbednosti primenjen je obično i u samim operativnim sistemima gde se razlikuje tri vrste prava pristupa: kontrolna prava, koja se odnose na mogućnost dodele drugih prava pristupa, u početku ih ima vlasnik baze, koji ga sebi ne moţe uskratiti; definiciona prava, koja se odnose na pravo kreiranja novih objekata i menjanja postojećih objekata u bazi, tj. na manipulaciju podacima u metabazi, i
manipulaciona prava, kojima se dozvoljava manipulisanje podacima u bazi.
U tabeli 9.1 je prikazan primer raspoloţivog prava pristupa podacima u bazi podataka, implementiran preko lista prava pristupa.
185
@ViPserbia
manipulaciona
definiciona
kontrolna
READ WRITE MODIFY ERASE DEFINE CHANGE DELETE SHOW CONTROL ADMINISTRATOR OPERATOR
SELECT INSERT UPDATE DELETE CREATETAB ALTER DROP SHOW DBCTRL DBADM OPERATOR
Tabela 9.1 Primer dodele prava Prava pristupa se definišu posebno za celu bazu, a posebno za relacije i poglede u njoj. Prilikom svakog pristupa bazi, baza najpre proverava da li korisnik uopšte ima odgovarajuća prava da pristupi bazi, pa tek zatim i prava koja se odnose na konkretnu relaciju/tabelu ili pogled. Pri tome, da bi se vršilo aţuriranje podataka u nekoj relaciji/tabeli potrebno je imati pravo čitanja podataka iz nje (READ/SELECT), a to pravo morate imati i ako ţelite da aţurirate definicije objekata u bazi. Posebno, pravo pristupa nekom pogledu (query – upit) ne podrazumeva i pravo da se pristupi baznoj relaciji/tabeli nad kojom je pogled definisan. Problemi mogu nastati ukoliko takav korisnik ima pravo DEFINE, jer on tada moţe sam sebi da kreira pogled kakav ţeli. Stoga pravo DEFINE treba da bude uskraćeno svim korisnicima, osim projektantima baze i, eventualno, administratoru. Korisnik koji je kreirao bazu moţe ostalim korisnicima da dodeli ili ukine sva prava. Ovo vaţi i za njega samog, sa izuzetkom prava CONTROL/DBCTRL, koje se moţe ukinuti samo uz pravo BYPASS, i pravo READ/SELECT, koje se ne moţe ukinuti. Dodeljivanje prava pristupa Prava pristupa dodeljuju se korisnicima koji se mogu identifikovati (i klasifikovati) na nekoliko načina. Najpre, OPS – operativni sistem korisnike prepoznaje po korisničkom identifikatoru, User Identification Code - UIC, koje moţe biti alfanumerički ili čisto numerički. Grupe korisnika mogu dobiti od upravnika sistema grupni identifitor, recimo SEKRETARICE, PROGRAMERI i slično. Posebni sistemski identifikatori mogu da 186
@ViPserbia
posluţe podjednako dobro za istu namenu. Mogući sistemski identifikatori su: BATCH, NETWORK, INTERACTIVE, LOCAL, DIAL-UP, REMOTE i oni uglavnom zavise od načina pristupa računarskom sistemu. Za svakog korisnika ili grupu korisnika sa odgovarajućim identifikatorom, mogu se definisati dozvoljena prava pristupa. Ona se pamte u ACL listi – autentifikaciono kontrolna lista – Autentification Control List, koju SUBP ispituje prilikom svakog pristupa bazi. Redosled navoĎenja identifikatora pojedinih korisnika, pritom, moţe biti veoma značajan. Naime, prilikom odreĎivanja da li neki korisnik ima prava da izvrši traţenu operaciju, SUBP ispituje listu prava pristupa od početka prema kraju, sve dok ne naĎe prvi identifikator koji odgovara identifikatoru korisnika. Tako, recimo, ako grupa [10,*] ima sva prava i nalazi se na početku liste, a korisnik [10,03] nema definiciona prava i nalazi se u listi iza grupnog. identifikatora, SUBP će mu, ipak, dozvoliti sve, jer njegova stavka u listi neće nikada biti pročitana. TakoĎe, ako grupa ima manja prava nego neki njen član kao pojedinačni korisnik, a stavka za grupu se nalazi ispred njegove stavke u ACL listi, na njega će se primenjivati grupna prava. Posebno se mora paziti ako neki korisnik ima lična ili grupna prava po osnovu UIC koda – User Identification Code – kod za identifikaciju korisnika, a pripada grupi sa posebnim identifikatorom, koja opet ima sopstvena prava. Uglavnom, moţe se reći da korisnici sa manjim pravima treba da budu što bliţe vrhu liste, a korisnici sa većim pravima što bliţe dnu liste. TakoĎe, specifični korisnici treba da budu pre grupnih korisnika, kako bi odgovarajuća ograničenja imala efekta. Definisanje prava pristupa – primer Za dodeljivanje prava pojedinim korisnicima sluţi - naredba DEFINE PROTECTION, čija sintaksa izgleda ovako: DEFINE PROTECTION FOR tip-objekta naziv-objekta poloţaj vrednost-poloţaja IDENTIFIER korisnički-id ACCESS lista-prava-pristupa, a pojedini parametri imaju sledeće značenje: tip-objekta moţe biti DATABASE, RELATION ili VIEW; naziv objekta je stvarni naziv baze, relacije ili pogleda; poloţaj moţe biti AFTER ili POSITION; ako se ovaj podatak ne navede, SUBP smešta novododatu stavku na sam vrh ACL liste.
187
@ViPserbia
vrednost-poloţaja moţe biti redni broj ili korisnički-id; Naredbom CHANGE PROTECTION mogu se promeniti prava pristupa za jednog korisnika ili celu grupu. Naredbom DELETE PROTECTION moţe se ukinuti pravo pristupa nekom korisniku. Posebno je vaţno da se ukloni pravo ALL koje neki SUBP, po kreiranju baze, dodeljuju korisniku čiji je UIC (*, *] - dakle, sva prava svim korisnicima. Najzad, naredbom SHOW PROTECTION moţe se saznati kolika su ovlašćenja dodeljena pojedinim korisnicima. Naredba SHOW PRIVILEGES ima sličnu funkciju, ali umesto prikazivanja prava za sve korisnike, prikazuje isključivo prava pristupa koja ima pojedini korisnik baze. Za dodelu prava pristupa SQL koristi listu prava pristupa (ACL), jednako kao i neki drugi SUBP. Za dodavanje novih prava pristupa koristi se naredba GRANT, čija je sintaksa: GRANT spisak-prava ON spisak-objekata TO spisak-korisnika [opis-mesta]; Moguća prava pristupa ekvivalentna su odgovarajućim pravima koja poznaju većina SUBP. Pravo ALL obuhvata sva moguća prava, a korisnik PUBLIC ekvivalentan je svim korisnicima, dakle stavki čiji je identifikator u ACL listi (*,*]. Prava pristupa mogu se definisati posebno za šemu, a posebno za tabele (relacije) i poglede u okviru šeme ,korisnik mora imati potrebno pravo i za šemu i za tabelu inače će mu pristup biti uskraćen. Za identifikaciju korisnika sluţi UIC identifikator, generalni ili sistemski identifikator. Nova stavka se moţe staviti u listu bilo na zadato mesto (POSITION..), ili posle odreĎenog identifikatora (AFTER...), a ako se mesto ne navede, SQL stavlja novu stavku na sam početak ACL liste. Za uklanjanje pojedinih prava nadleţna je naredba REVOKE, kojom se mogu uskratiti samo neka prava (ako se eksplicitno navedu) ili sva prava (ako se briše kompletna stavka iz ACL liste, REVOKE ENTRY ON ...), za pojedine objekte ili celu šemu, korisniku koji se identifikuje bilo mestom, bilo identifikatorom. Pravo DBCTRL- Data Base Control, koje dozvoljava korisniku da drugima dodeljuje i menja prava pristupa, slično je, ali ne i sasvim ekvivalentno standardnom SQL pravu GRANT OPTION. U standardnim implementacijama SQL-a korisnik sa GRANT OPTION pravom moţe drugim korisnicima da dodeljuje samo ona prava koja sam ima; dok u nekim SUBP, korisnik sa CONTROL, odnosno DBCTRL pravom moţe, sebi i drugima, dodeljivati sva moguća prava pristupa bazi.
188
@ViPserbia
10. Zaštita integriteta baze Pod pojmom integriteta neke baze podataka se podrazumeva neophodnost da podaci smešteni u bazi budu ispravni, zatim da budu potpuni u meri u kojoj je to moguće, da budu zaštićeni od neovlašćenih delovanja izvana ili iznutra kao i da se obezbedi potreban nivo tajnosti. Da bi se zaštitio integritet baze potrebno je da se obezbedi meĎusobna usaglašenost i povezanost podataka koji se nalaze u bazi. Da bi se ostvario recimo logički integritet podataka koriste se odgovarajuća ograničenja koja sprečavaju pojavu i prisustvo nekih podataka u bazi koji bi u logičkom smislu odstupali od zadatih parametara. Što se tiče zaštite integriteta baze ona se odnosi pre svega na mogući oporavak u slučaju neke nezgode, nestanak struje naprimer i slično, kada se javlja potreba za delimičnim ili potpunim rekonstruisanjem baze, zatim mogućeg konkurentnog pristupa od strane više korisnika istovremeno, kao i na bezbednost pojedinih podataka pa i čitave baze od mogućih destruktivnih uticaja, i na kraju zaštita ispravnosti i konzistentnosti podataka u bazi. Kao jedna od veoma dobrih mera u zaštiti integriteta baze je primena takozvanih transakcija što podrazumeva jednu logičku jedinicu posla koja se ili izvršava u celini ili se uopšte ne izvršava. Naime za integritet baze bi bilo veoma loše ako bi se zbog odreĎenih smetnji pola podataka u jednoj transakciji unelo u bazu a recimo druga polovina ne. Pored toga se koriste i druge operacije nad transakcijom koje omogućavaju da se svi podaci vezani za datum transakcije prethodno logički provere pre nego što se pokrene akcija aktiviranja te transakcije. Bilo bi veoma nezgodno da se pola transakcije obavi, a tek onda ustanovi da neki podaci u drugom delu transakcije nisu adekvatni i da se ne mogu uključiti u bazu. Pored toga koriste se mehanizmi poznati kao voĎenje dnevnika prethodnog stanja koji predstavlja jednu od osnova za primenu transakcije kao osnovne jedinice za pristup nekoj bazi. Pod integritetom baze se takoĎe podrazumeva meĎusobna usaglašenost i povezanost podataka u bazi, tamo gde postoji eksplicitno izraţena potreba za očuvanjem te usaglašenosti, odnosno povezanosti. TakoĎe se pod integritetom baze podrazumeva obezbeĎenje logičkog i fizičkog integriteta. Osnovni mehanizam očuvanja logičkog integriteta podataka jesu ograničenja i logika aplikacionih programa. Osnovna zaštita fizičkog integriteta podataka se moţe ostvariti primenom mehanizma poznatog kao voĎenje dnevnika prethodnog stanja (before-image journaling), koji predstavlja osnovu za implementaciju transakcija kao osnovnih jedinica pristupa bazi. Pomenućemo još neke mehanizme zaštite fizičkog integriteta podataka:
@ViPserbia
arhiviranje, import i eksport operacije, te voĎenje dnevnika završenih transakcija. Arhiviranje i dnevnik završenih transakcija Kao i za sve druge datoteke na bilo kom računarskom sistemu, potrebno je periodično arhiviranje datoteke baze podataka na neku drugu jedinicu masovne memorije najčešće je to druga jedinica magnetnog diska, (pre je to bila magnetna traka). Operacija arhiviranja se vrši periodično, a pre svega sa ciljem da se sačuva kopija datoteka za slučaj oštećenja glavne jedinice spoljn memorije: diska. Pošto se obično radilo o povremenim situacijama, a ne o svakodnevnom radu, brzina pristupa arhiviranim podacima nije bila od primarnog značaja, pa je čak i traka bila sasvim prihvatljiv medij. Arhiviranje, se u većini operativnih sistema vršilo i vrši naprimer naredbom BACKUP; pa ako doĎe do oštećenja podataka u bazi, recimo prilikom kvara nekog fizičkog ureĎaja, baza se moţe lako obnoviti iz arhivirane verzije, ponovo naredbom BACKUP. Sve izmene koje su učinjene nakon poslednjeg arhiviranja, meĎutim biće izgubljene. Kao zaštita u takvim slučajevima, u mnogim SUBP je implementiran takozvani after-image journaling mehanizam. Ovaj postupak se zasniva na tome što se u posebnu privremenu datoteku upisuju sve izmene koje su nastale kao posledica uspešno okončanih transakcija i to neposredno pre okončanja odgovarajuće transakcije (podsetimo se da su izmene već upisane u bazu i samo se obeleţavaju kao vaţeće, a stari podaci iz privremene datoteke se brišu). Kao predostroţnost za slučaj da doĎe do oštećenja baze - narušavanja konsistentnosti podataka, tada se relativno lako mogao izvršiti oporavak baze. Gotovo da i ne treba naglašavati da je neophodno da privremena datoteka ne bude na istom fizičkom disku na kojem se nalazila i baza, inače je pouzdanost ovakve zaštite bila ništavna. Posle oštećenja, najpre treba da se arhivirane datoteke restauriraju, ali na drugi disk (ili pak na originalni, ukoliko - i kada – se moţe vratiti u radno stanje). Za to ponovo moţe da posluţi naredba BACKUP: Tokom procesa rekonstrukcije svaka transakcija koja se uspešno ponovi je obeleţena u after-image datoteci. Samo one transakcije koje nisu bile unete u afterimage journal ne budu sačuvane, a takvih je obično bio mali broj jer samo one transakcije koje su u toku u trenutku kada je došlo do kvara sistema (jer se izmene prvo unose u after-image journal, pa tek onda u bazu). Jedna od dodatnih mogućnosti je izbor potpunog ili inkrementalnog arhiviranja, tj. da li će se vršiti arhiviranje cele baze ili samo onih delova koji su izmenjeni od trenutka poslednjeg arhiviranja. Druga je mogućnost da se arhiviranje baze obavlja u prisustvu aktivnih korisnika, bez prekidanja rada sa bazom. Sve transakcije koje su u toku u trenutku započinjanja arhiviranja mogu se neometano završiti, ali nije dozvoljeno započinjanje novih. Kada baza dostigne mirno stanje, u kome više nema 190
@ViPserbia
otvorenih transakcija, počinje postupak arhiviranjia, tokom koga bazi mogu pristupati drugi korisnici. SUBP moţe da arhivira i dnevnik završenih transakcija i na taj način se štedi prostor na disku. Postoji i mogućnost da se arhiviranje dnevnika obavlja periodično, u zadatim vremenskim intervalima, čime se prostor koji dnevnik zauzima na disku odrţava u zadatim granicama. Baza se restaurira iz arhivirane kopije odgovarajućom naredbom RESTORE; pri čemu se mogu promeniti vrednosti nekih parametara; takoĎe, mogu se aţurirati definicije struktura podataka u rečniku podataka, na osnovu strukture zapisane u bazi. Ako se baza poziva preko naziva datoteke, a ne preko naziva CDD putanje – Code Data Definition , bilo koja naredba kojom se menja struktura baze neće promeniti odgovarajuće definicije u rečniku podataka, pa postoji opasnost da pristup preko nekog drugog softvera ne bude moguć. Da bi se aţurirale definicije strukture baze u rečniku podataka, potrebno je izdati odgovarajuću naredbu kojom se definicije objekata kopiraju u rečnik podataka. Ova se naredba se ne moţe izdati dok je baza čija se definicija kopira aktivna, već ili pre pozivanja, ili posle zatvaranja baze. Korisnik mora imati dozvolu za aţuriranje za CDD katalog. Po izvršavanju ove naredbe navedena baza postaje aktivna, iako nije eksplicitno aktivirana. Razmena podataka Većina korisničkih interfejsa prema bazama poseduju dva para naredbi čiji je cilj obezbeĎivanje i olakšavanje razmene podataka izmeĎu različitih verzija istoga SUBP. Pri tome, naprimer naredbe BACKUP i RESTORE sluţe za razmenu podataka sa jednog računarskog sistema na drugi. Jedan od tih sistema moţe da radi i pod operativnim sistemom koji sluţi za upravljanje procesima, po mogućnosti u realnom vremenu, a da je drugi operativni sistem, da se tako izrazimo, opšte namene. Pored ovih preporučuje se da se koriste i naredbe EXPORT i IMPORT, sa sličnom namenom, ali sa više mogućnosti. Naredba EXPORT formira kopiju baze u komprimovanom obliku. Kopija dobijena na taj način moţe se iskoristiti za prestruktuiranje, tj. promenu fizičkih parametara baze (čak i onih koji se ne mogu menjati naprimer standardnim naredbama za promenu baze kao što su CHANGE DATABASE, odnosno ALTER SCHEMA), pretvaranje single-file baze u multifile bazu, ili za prenos baze sa jednog računarskog sistema na drugi itd.
191
@ViPserbia
Transakcije i zaštita integriteta podataka Osnovni aspekti zaštite podataka jesu oporavak u slučaju nezgode, arbitraţa pri konkurentnom pristupu bazi od strane više korisnika, bezbednost pojedinih podataka i čitave baze, te zaštita integriteta - ispravnosti i konzistentnosti podataka u bazi. Transakcija je logička jedinica posla, pristup bazi koji ima atomski karakter - ili se izvršava u celosti, ili se ne izvršava uopšte. Naime, ukoliko se upis, brisanje ili izmena podataka uspešno završi, podaci bi trebalo da budu aţurirani. Sa druge strane, ukoliko iz bilo kojeg razloga doĎe do greške, baza bi trebalo da bude vraćna u prvobitno stanje, ono koje je postojalo pre početka pristupa bazi od strane dotičnog korisnika. Razlog za postojanje transakcija jeste opasnost od grešaka do kojih moţe doći bilo usled neispravno zadatih upita od strane jednog korisnika, bilo usled konkurentnog pristupa podacima od strane više korisnika, bilo usled otkaza softvera ili hardvera u toku aţuriranja podataka. Stoga su gotovo u sve relacione SUBP ugraĎene naredbe COMMIT (naredba za izvršenje) i ROLLBACK (naredba za vraćanje u nazad). Naredbom COMMIT korisnik obaveštava SUBP da je upit korektan i da sve izmene treba da se zaista izvrše, tj. da se podaci u bazi aţuriraju. Ukoliko doĎe do neke greške, ili ako korisnik primeti da upit nije bio korektno postavljen, naredbom ROLLBACK sve izmene se poništavaju i sadrţaj baze se dovodi u stanje u kojem se nalazio pre početka transakcije. Kako se ovo izvodi? Sistem ne samo da izvršava naredbe, već ih i pamti u sklopu posebnih datoteka - dnevnika izvršenih aktivnosti (log ili journal); u slučaju da doĎe do ROLLBACK naredbe, na osnovu podataka iz tih datoteka baza se vraća u prvobitno stanje. Fizički, transakcije su podrţane putem mehanizma poznatog kao before-image journaling. Postupak se odvija u dva koraka: prilikom svake izmene podataka u bazi, najpre se u posebnu datoteku (koja se zove run-unit journal, RUJ, a vodi se za svakog korisnika posebno) upisuje prethodno stanje svih izmenjenih podataka. Zatim se nove vrednosti podataka upisuju direktno u bazu. Postupak se ponavlja za svaku izmenu izvršenu tokom tekuće transakcije. Pošto se sve izmene unesu, naredbom COMMIT korisnik obaveštava SUBP da ţeIi da izmene ostanu za stalno u bazi. Ukoliko sistem nije otkrio nikakvu grešku (naprimer dupliranje neke n-torke, ili narušavanje nekih), po naredbi COMMIT prethodno stanje podataka se briše iz .RUJ datoteke, a u bazi ostaje novo stanje. Transakcija se tek tada smatra uspešno okončanom. Ukoliko sistem detektuje grešku, transakcija ostaje otvorena: u bazi se nalaze izmenjeni podaci, ali je i .RUJ datoteka otvorena i sadrţi prethodno stanje. U tom slučaju SUBP obaveštava korisnika, čija je duţnost da izda naredbu ROLLBACK i da poništi efekte neispravne transakcije. Kada se transakcija poništi (korisnik je 192
@ViPserbia
izdao naredbu ROLLBACK), svi podaci izmenjeni tokom transakcije vraćaju se u prvobitno stanje (transakcija se "odvrti unazad" , otuda termin roll back). Na ovaj način je obezbeĎeno da se sve operacije unutar jedne transakcije ili izvrše ili ne izvrše. Iz praktičnih razloga, da bi se smanjio broj U/I operacija u slučaju višekorisničkog rada i zbog zauzeća prostora na disku, poţeljno je da transakcije budu što je moguće kraće. _ Postavlja se pitanje da li se postupak moţe obrnuti, tako da se u run-unit journal upisuju izmene, a da stanje u bazi ostane nepromenjeno sve do naredbe COMMIT? Na prvi pogled redosled operacija nema značaja, meĎutim nije tako. Naime, direktno upisivanje izmena u bazu obezbeĎuje korektnost podataka u bazi u slučaju da do otkaza doĎe u intervalu izmeĎu izdavanja naredbe COMMIT i njenog okončanja. Za izvršenje COMMIT naredbe potrebno je, naime, samo izbrisati podatke iz run-unit journal datoteke, bez pristupa samoj bazi. U suprotnom, ako bi se izmene unosile u bazu tek naredbom COMMIT, bilo bi potrebno znatno više vremena (pa je verovatnoća otkaza veća), a postojala bi i opasnost da se tek tada detektuje narušavanje nekog ograničenja. Najzad, realno je očekivati da će se većina transakcija uspešno završiti, pa je upotrebljeni način brţi, iz čisto statističkih razloga. U nekim SUBP before-image journaling postupak se vodi automatski i korisnik na njega moţe da utiče utoliko što moţe da promeni katalog u koji će biti smeštena .RUJ datoteka. Tačna lokacija ove datoteke moţe se menjati predefinisanjem logičkog naziva na nivou operativnog sistema, uz pomoć odgovarajuće naredbe posle čega će run-unit journal datoteka biti smeštena u katalog čije ime se zada tom naredbom. Gotovo da nije ni potrebno pominjati da je za efikasan rad mehanizma transakcija u slučaju otkaza sistema dobro da run-unit journal datoteka ne bude na istoj memorijskoj jedinici na kojoj i baza. Inače, transakcija se započinje eksplicitnom naredbom, a završava sa COMMIT ili ROLLBACK. većina SUBP, predviĎa postojanje transakcija različitih vrsta: jednih koje se obraćaju bazi samo u cilju čitanja (READONLY), i drugih koje mogu vršiti i aţuriranje podataka (READ-WRITE). Vrsta transakcije se mora naznačiti prilikom njenog započinjanja. Ukoliko se transakcija ne započne eksplicitnom naredbom, SUBP automatski startuje transakciju za upisivanje pri naredbama DEFINE, CHANGE, DELETE ili STORE, a transakciju za čitanje u ostalim slučajevima. Bez obzira na to ko je započeo transakciju, na kraju se mora naći naredba COMMIT ili ROLLBACK. Transakcija za čitanje je tesno povezana sa datotekom snimka (snapshot file). Naime, transakcije tipa READ-ONLY ne obraćaju se samoj bazi, već njenoj slici delu relacije koji se po potrebi prekopira u .SNP datoteku. Na taj način se poboljšava brzina odziva: pošto je datoteka kraća, pretraţivanje je brţe, a snimak se ne zaključava te se prava pristupa ne proveravaju. Kako nema opasnosti od konflikta oko zaključavanja izmeĎu transakcije koja čita snimak i transakcije koja aţurira podatke u 193
@ViPserbia
bazi, vreme odziva je kraće, i to za obe transakcije. Naravno, ne moţe baš sve biti idealno, uvek postoji opasnost da podaci u datoteci snimka nisu sasvim ispravni: moţda su stvarni podaci u bazi izmenjeni, a izmene još nisu unete u datoteku snimka. Ukoliko takav rizik nije prihvatljiv, mora se specificirati transakcija za upisivanje, koja pristupa direktno bazi a ne snimku, ako ţelimo da čitamo samo podatke iz baze. Problemi konkuretnosti Posebni problemi nastaju kada dva ili više korisnika pokušaju da istovremeno pristupe podacima u bazi. Ako se tom prilikom vrši samo čitanje podataka sa obe strane, sve je u redu; ali ako bilo koji upit ima za cilj aţuriranje podataka, moţe doći do problema. Postoji više mogućih scenarija u kojima dolazi do greške, do stanja u kome su sve transakcije okončane, a podaci u bazi su ipak u nekonsistentnom stanju; navešćemo tri karakterističcna slučcaja: 1. Recimo da dva korisnika, A i B, istovremeno aţuriraju podatke. Korisnik A pročita podatak, zatim korisnik B pročita taj isti podatak, onda mu A izmeni vrednost, pa mu zatim B, na osnovu prethodno pročitane vrednosti, takoĎe izmeni vrednost. Rezultat: izmena koju je napravio A nije ostala u bazi (the lost update problem, problem neuspelog aţuriranja). 2. Recimo da A čita ili aţurira podatke, dok ih B istovremeno aţurira. Najpre B izmeni podatak, A ga zatim pročita, a onda B-ova transakcija propadne i podatak dobije prethodnu vrednost ili pak B izmeni podatak, zatim ga i A izmeni, a onda B-ova transakcija propadne i podatak dobije vrednost koju je imao pre no što su ga menjali i A i B. Rezultat: izmena koju vrši A zavisi od uspeha transakcije u okviru koje radi B (the uncommitted dependency problem, problem zavisnosti od druge transakcije). 3. Moguća je i situacija u kojoj A vrši neku zbirnu analizu podataka, dok B istovremeno aţurira podatke u istoj relaciji: tako A moţe da urašuna u zbir neki podatak, koji potom B izmeni. Rezultat: iako je B-ova transakcija uspešno završena, zbir koji je izračunao A nije više ispravan (the inconsistent analysis problem, problem nekonsistentne analize). Naravno, stvari mogu biti još sloţenije kada više korisnika pristupa bazi. Da bi se osigurao integritet baze i korektnost aplikacija pri višekorisničkom radu, pored transakcije uvodi se i zaključavanje pojedinih podataka. Ukoliko jedan korisnik ţeli da izmeni podatak u odreĎenoj vrsti ili celoj tabeli, za vreme njegove transakcije svim ostalim korisnicima moţe biti uskraćen pristup vrsti ili tabeli čiji se sadrţaj menja. Naravno, stvari nisu postavljene na principu sve ili ništa, već postoji relativno 194
@ViPserbia
sloţen mehanizam zaključavanja kojim se osigurava kako integritet podataka u bazi, tako i efikasan pristup sa najmanje čekanja. Nivoi zaključavanja Postoje tri načina (ili nivoa) zaključavanja: deljivi (sharedlock), zaštićeni (protected lock) i ekskluzivno zaključavanje (exclusive lock). Postaviti ekskluzivni lokot na neku relaciju znači sprečiti sve ostale korisnike da joj pristupe, nezavisno od toga šta ţele da rade, za sve vreme izvršavanja transakcije; postaviti zaštićeni lokot znači sprečiti ostale korisnike da upisuju podatke u zaključanu relaciju, ali im je pristup dozvoljen ako imaju nameru samo da čitaju podatke. Najzad, deljivi lokot omogućava ostalim korisnicima i da pišu, i da čitaju podatke iz zaključane relacije. Jasno je da će postavljanje lokota višeg reda sprečiti pristup drugim korisnicima, ali je zato izvršavanje takve transakcije brţe, budući da se u tom slučaju zaključavanje vrši na višem nivou, te je manje reţijsko vreme tokom kojeg SUBP odreĎuje ko ima preče pravo pristupa relaciji, delu relacije ili indeksu. Dakle, verovatnoća kolizije je veća, ali je vreme kraće, pa se ne moţe odreĎeno reći koju je vrstu lokota bolje koristiti. Naravno, ima situacija kada izbora nema, bez obzira na eventualne posledice. Nekiu proizvoĎači SUBP recimo preporučuju da se upisivanje veće količine podataka (pod tim se podrazumeva programsko unošenje podataka iz neke druge baze ili datoteke) vrši primenom naredbe EXCLUSIVE WRITE, naredba za ekskluzivno upisivanje transakcija, jer je na taj način upis brţi, neće se vršiti upisivanje u datoteku snimka, te nema opasnosti da drugi korisnici pokvare te podatke. Na početku transakcije moţe se navesti i podatak o tome da li je transakcija (tj. korisnik) spremna da čeka, ukoliko su podaci kojima treba da pristupi već zaključani od strane drugih korisnika. Ukoliko se za stanje-čekanja stavi naredba za čekanje WAIT (što se inače podrazumeva, ako se ništa ne stavi), transakcija koja ne moţe da pristupi nekom zapisu usled istovremenog pristupa transakcije sa lokotom višeg reda moraće da sačeka da se ţeljena lokacija oslobodi.
195
@ViPserbia
11. Nadzor nad radom baze Nadzor nad radom baze je neophodan jer u toku rada sa bazom posebno od strane velikog broja korisnika koji recimo pune bazu ili vrţe aţuriranja u bazi. Naime u takvom radu moţe doći do pojave neţeljnih podataka u bazi, pojave dupliranja, pojave takozvanog smeća koje je potrebno u odreĎenim periodima vremena pregledati, eliminisati, očistiti bazu, ako je potrebno izvršiti odreĎenu regeneraciju ili pak restauraciju baze ili pek ponekad je potrebno leiminisati neke konfliktne situacije. U firmama u kojima se koriste velike baze podataka obično postoje osobe čiji je osnovni zadatak da pored odgovarajućih programskih alata koje sadrţi većina modernih baza i koji brinu o zaštiti i integritetu baze i oni vode posebnu brigu o bazi dodeljuju prava pristupa i korišćenja odreĎenih podataka u bazi pa do napred pomenutih operacija nad bazom u cilju obezbeĎenja njenog besprekornog funkcionisanja. Naprimer u nekim SUBP se odgovarajućom naredbom aktivira monitorski proces (naprimer MONITOR START) koji nadzire rad baze podataka. Monitor se zaustavlja odgovarajućom naredbom (naprimer MONITOR STOP), pri čemu se aktivnim korisnicima baze moţe dopustiti da neometano završe rad, ili se pak nasilno prekida rad drugih korisnika, bez zaustavljanja njihovih procesa, a moţe i da se prekida rad drugih korisnika i zaustavljaju njihovi procesi. Spisak trenutno aktivnih korisnika baze moţe se dobiti odgvarajućom naredbom (naprimer SHOW USERS ), dok naprimer naredba SHOW SYSTEM prikazuje sve aktivne baze u datom cluster čvoru. Naredbom SHOW MONITOR moţe se takoĎe dobiti informacija o trenutnim korisnicima svih baza u sistemu.
196
@ViPserbia
Kuda dalje – Budući razvoj Sa sve većim i brţim razvojem informacionih sistema, sa njihovom distribucijom na velike prostore i veoma razuĎene računarske resurse, kao i sa sve većom primenom Interneta kao najveće svetske računarske mreţe stiče se utisak da je stvarna budućnost baza podataka u njihovoj distribuciji na širokoj sklali računarske podloge i mogućnošću korišćenja od strane veoma velikog broja korisnika iz najudaljenijih krajeva sveta. Normalno da će poslovne baze podataka iako distribuirane u većoj ili manjoj meri biti pristupačne samo uţem krugu korisnika i to onih koji imaju dozvolu za pristup odgovarajućoj grupi podataka.Ipak će najveće svetske baze podataka kao i Internet postati opšte dobro koje će moći da koriste i da im pristupaju korisnici iz celog sveta i to je najveća vrednost informatizacije sveta ili to moţemo nazvati informatičkom revolucijom ili pak epohom informatičkog društva. Naime učinjen je mogućim pristup brojnim informacijama relevantnim za društvo kao celinu, ali i dostupnim svim ljudima na svetu i deci i starijima, domaćicama i penzionerima, radnicima i naučnicima i zato moţemo reći iskreno hvala svim onim pionirima koji su u poslednijh pedesetak godina dali svoj manji ili veći doprinos razvoju kako baza podataka tako i informatizaciji čovečanstva.
197
@ViPserbia
13. Prilog 1 - PRIMER PROJEKTA INFORMACIONOG SISTEMA BIBLIOTEKE F@M - a Za potrebe Fakulteta zahtevano je da se na osnovu idejnog-izvoĎačkog projekta za biblioteku realizuje podsistem evidentiranja podataka o literaturi. Bilo je neophodno da se obave intervjui sa zaposlenima koji rade na tim poslovima da bi se upoznalo sa tehnologijom procesa rada u segmentu Fakulteta za menadţment koji se odnosi na biblioteku. Procenjeno je da će se evidentirati oko 5000 knjiga-naslova. Na osnovu intervjua predloţen je idejno-izvoĎački projekat na osnovu koga je realizovano aplikativno rešenje kao deo ukupnog sadašnjeg i budućeg informacionog sistema Fakulteta za menadţment. Aplikativno rešenje se odnosi na formiranje i korišćenje baze podataka o literaturi. Aplikativno rešenje je realizovano alatima Microsoft Access 2000 (kao deo MS Office 2000 Professional softvera). Aplikativno rešenje je isporučeno u izvornom kodu (source code) da bi svi zaposleni na tim poslovima mogli po potrebi da sprovode izmene u realizovanom rešenju. Posle okončanja ovoga projekta odnosno završetka aplikativnog rešenja, izvršena je obuka zaposlenih koji operativno koriste aplikativno rešenje uz prateću dokumentaciju, Pored obuke osposobljen je jedan od zaposlenih na budućim poslovima odrţavanja aplikativnog rešenja u smislu daljne nadgradnje (projektovanje i programiranje modaliteta koji se u praksi pokaţu potrebnim). U nastavku će biti prikazani izgledi nekih ekrana (formi) i izveštaja. Forme sluţe za obuhvat podataka. Navigacija kroz forme je realizovana sistemom menija. Obuhvat podataka podrazumeva da se nad jednom pojavom jednog podatka iz entiteta mogu obavljati funkcije insert (novo evidentiranje), update (izmena postojećeg stanja), select/query (pronalaţenje po nekom kriterijumu) i print (prikaz podatka na ekranu i/ili u štampanoj formi na hartiji). Funkcija delete (brisanje) nije blokirana, nego je zbog takozvanog referencijalnog integriteta uspostavljenog na nivou cele MS Access baze, operateru odnosno zaposlenom koji koristi aplikativno rešenje prepušteno da na osnovu profesionalnog stava potvrdi ili opozove brisanje.
198
@ViPserbia
Pristup bazi podataka je ograničen samo na one koji znaju pristupnu lozinku. Tokom obuke je prezentiran način arhiviranja (backup) podataka na neki medij (naprimer diskete, drugi računar u mreţi, CD-RW). 1. Ulazna dokumentacija na osnovu koje je formirana baza podataka o literaturi nije postojala tako da je predviĎeno da se direktnim uvidom u podatke na samoj knjizi omogući kasnije evidentiranje i štampanje "kartona knjige". 2. Revers je dokument čija forma isto nije definisana u dokumentaciji, ali je iskazana potreba za takvim dokumentom u aplikativnom rešenju pa je bilo potrebno da se dizajnira forma. To je dokument kojim se evidentiraju sva zaduţenja studenata, nastavnog osobolja i drugih lica koja imaju odobrenje za pristup biblioteci. Potrebno je bilo predvideti takav sistem rada da ako se ne obavi povraćaj litearture na vreme studentska sluţba i operater u biblioteci dobiju odgovarajuću. 3. Izlaznu dokumentaciju čine raznorazni izveštaji: abecedne liste po naslovima, autorima, izdavačima ili liste po godinama izdavanja i po lokacijama-policama smeštaja literature. Ovi izveštaji se generišu iz agregiranih podataka smeštenih u bazu podataka. 4. Aplikativnim rešenjem je predviĎeno i pronalaţenje literature po nekom kriterijumu i filtriranje takvih podataka dobijenih iz postavljenog kriterijuma. Logički model je postavljen na osnovi E-R modela relacione baze podataka. Identifikovani su sledeći entiteti sa pripadajućim atributima: 1 AUTORI 1. Identifikacija autora 2. Prezime i ime 3. e-mail 4. Biografija
AutoNum Char Char Memo
* Primarni indeks
2 OBLASTI 1. Identifikacija oblasti 2. Opis oblasti
AutoNum Char
* Primarni indeks
199
@ViPserbia
3 IZDAVAČI 1. Identifikacija izdavača 2. Naziv izdavača 3. Adresa uzdavača (mesto,ulica i broj) 4. Telefoni 5. Dosije izdavača 4 JEZICI 1. Identifikacija jezika indeks 2. Naziv jezika 5 REVERSI 1. Identifikacija zaduţenja 2. Prezime i ime duţnika 3. Opis zaduţenja 4. Datum početka zaduţenja 5. Datum završetka zaduţenja 6. Odobrio revers (ime i prezime) 7. Poništio revers (ime i prezime) 8. Status zaduţenja 6 KNJIGE 1. Identifikacija knjige 2. Autor 3. Naslov 4. Kratak sadrţaj 5. Izdavač 6. Godina izdavanja 7. Oblast 8. Jezik 9. ISBN oznaka 10. Lokacija (orman-polisa) 11. Identifikacija reversa 12. Slika naslovne strane 13. Broj stranica 14. Sadrţaj knjige 15. Tip literature 16. Status knjige(foto-kopija)
AutoNum Char Char Char
AutoNum
* Primarni indeks
* Primarni
Char
AutoNum Char Char Date() Date() Char Char Yes/No
* Primarni indeks
AutoNum * Primarni indeks Num ** Strani ključ Char Memo Num ** Strani ključ Date() Num ** Strani ključ Num ** Strani ključ Char Char Num ** Strani ključ OLE objekat (.BMP format slike) Num Memo Num ** Strani ključ Yes/No
200
@ViPserbia
Slika 13.1 Oosnovni meni informacionog sistema studentske sluţbe
Slika 13.2 Meni poslova biblioteke
201
@ViPserbia
Slika 13.3.
E-R dijagram relacija i entieta
Slika 13.4 Spisak tabela u projektu sa definicijama tabela i prikazom delimičnog sadrţaja 202
@ViPserbia
Slika 13.5 Spisak - tabela autora –design view
Slika 13.6 Spisak - tabela autora – tabelarni – spead sheet view
203
@ViPserbia
Slika 13.7 Spisak - tabela izdavača –design view
Slika 13.8 Spisak - tabela izdavača tabelarni – spead sheet view
204
@ViPserbia
Slika 13.9 Spisak - tabela jezici–design view
Slika 13.10 Spisak - tabela jezici tabelarni – spead sheet view
205
@ViPserbia
Slika 13.11 Spisak tabela knjige –design view
Slika 13.12 Spisak tabela knjige tabelarni – spead sheet view
206
@ViPserbia
Slika 13.13 Spisak tabela oblasti –design view
Slika 13.14 Spisak tabela oblasti tabelarni – spead sheet view
207
@ViPserbia
Slika 13.15 Spisak - tabela reversi oblasti –design view
Slika 13.16 Spisak - tabela reversi tabelarni – spead sheet view
208
@ViPserbia
Slika 13.17 Forma za obuhvat podataka o knjigama
Slika 13.18 Forma za obuhvat podataka o oblastima
209
@ViPserbia
Slika 13.19 Forma za obuhvat podataka o jezicima
Slika 13.20 Primeri izveštaja – karton knjige
210
@ViPserbia
Slika 13.21 Primer izveštaja - Spisak literature po naslovima
Slika 13.23 Primer izveštaja - Spisak literature po autorima
211
@ViPserbia
14. Prilog 2 Primer baze podataka za osnovnu školu Jovan Popović U okviru ovog primera je data baza sa kompletnom evidencijom svih učenika, profesora, predmeta i evidencija uspeha učenika po predmetima, kao i evidencija o nagradama i kaznama
Slika 14.1 Glavni meni
212
@ViPserbia
Slika 14.2 Pomoćni meni za izveštaje
Slika 14.3 Dijagram entiteta i relacija
213
@ViPserbia
Prikaz tabela u dizajnerskom prozoru Slika 14.4 Prikaz tabele Nastavnik
Slika 14.5 Prikaz tabele Učenici
214
@ViPserbia
Slika 14.6 Prikaz tabele Predmeti
Slika 14.7 Prikaz tabele za dnevni unos ocena, opravdanih i
neopravdanih časova, nagrada i kazni
215
@ViPserbia
Prikaz formi za obuhvat podataka Slika 14.8 Prikaz forme za obuhvat podataka o nastavnom osoblju
Slika 14.9 Prikaz forme za obuhvat podataka o učenicima
216
@ViPserbia
Slika 14.10 Prikaz forme za obuhvat podataka o nastavnim predmetima
Slika 14.11 Prikaz forme za obuhvat podataka o ocenama, opravdanim i neopravdanim časovima,nagradama i kaznama
217
@ViPserbia
Prikaz upita dizajnerskom prozoru Slika 14.12 Prikaz upita o kaznama i nagradama za učenike
Slika 14.13 Prikaz upita o profesorima i predmetima koje predaju
218
@ViPserbia
Slika 14.14 Prikaz upita o srednjim ocenama za učenike pojedinačno
Prikaz izveštaja Slika 14.15 Prikaz izveštaja o srednjim ocenama grupisanim po učenicima
219
@ViPserbia
Slika 14.16 Prikaz izveštaja o nagradama i kaznama
Slika 14.17 Prikaz izveštaja o nastavnicima i predmetima
koje predaju
220
@ViPserbia
15. Posebni izrazi koji se koriste u bazama podataka ACL Adresa
Access Control List Address
Aktivan
Active
Aplikacija
Applications
Aţurirati
Update
Baza podataka
Data Base
CDD Bit
Code Data Definition Bit (Binary Digit)
Datoteka
File
DB DBADM DBCTRL DDBMS
Data Base Data Base Administrator Data Base Control Dstributed Data Base Management System
Dokument
Document
Dţoker
Wildcard
Elemenat
Data entity
Funkcija
Function
Grupa
Group
Indeks
Index
Kontrolna lista pristupa Numerička vrednost lokacije u memoriji Aplikacija koja se trenutno izvršava Softverski proizvod nastao programiranjem Dopunjavanje ili izmena vrednosti podataka Skup elemenata baze i softvera za upravljanje bazom podataka Definicija koda podataka Najmanji deo binarne informacije Logički skup podataka – ekvivalentan tabelama Baza podataka Administrator baze Kontrola baze Sistem za upravljanje distribuiranim bazama podataka Programski objekat koga kreira projektant a ne aplikacija Znak ili znakovi koji zamenjuju jedan ili više bilo kojih znakova Vrednost koja se nalazi u nekoj ćeliji podataka Podprogram za proračun odreĎene vrednosti Više zapisa koji se sakupljaju u istu kategoriju Odgovarajuća vrednost u 221
@ViPserbia
Integritet podataka
Data Integrity
Izraz
Expression
Klijent
Client
Ključ
Key
Komanda Komandno dugme
Command Command Button
LAN Makro
Local Area Network Macro
Meni Niz
Menu String
Normalna forma Objekat u bazi podataka Obrazac
Normal Form
off-line Okvir sa alatima Okvir za text OLE
off-line Tool box
on-line Operativni sistem
on-line Operating system
Data Base Object Form
Text box Object Linking and Embedding
tabeli za traţenje Pravila koja obezbeĎuju tačnost i čitljivost podataka Skup vrednosti, funkcija, promenljivih i operatora koji vraćaju rezultat Računar ili aplikacija koji komuniciraju sa serverom Polje koje identifikuje odreĎeni zapis Naredba - instrukcija Objakat koji aktivira neku akciju ako se na njega klikne Lokalna mreţa Skup nekoliko naredbi koje reaguju na dogaĎaje Skup mogućih izbora Podaci koji imaju tekstualni sadrţaj, mogu sadrţavati i brojeve Skup od pet pravila za projektovanje baza Komponenta u bazi podataka Korisnički definisan prozor u Accessu autonoman, nezavisan rad Skup komandih dugmadi koja pozivaju alate Okvir za ubacivanje teksta Tehnika koja omogućava ubacivanje i povezivanje objekata neprekidna veza u radu Programi koji prevode osnovne naredbe u jezik koji računar razume
222
@ViPserbia
OODBMS
Object Oriented Data Base Management System
OODBMS
Object Oriented Data Base
Osnovne tabele
Base Tables
Paket
Batch
Podmeni
Submenu
Podprocedura
Subprocedure
Polje
Field
Prevuci i pusti
Drag and drop
Primarni ključ
Primary key
Procedura
Procedure
Promenljiva
Variable
RDBMS
Relational Data Base Managemnet System
Referentni integritet
Referential integrity
RUJ Server
Run Unit Journal Server
SNP Stavka
Snapshot Item
Objektno orijentisan sistem za upravljanje bazama podataka Objektno orijentisana baza podataka Osnovne – stalne tabele na osnovu kojih se kreira upit Niz iskaza koji se obraĎuju kao jedan paket Niţi njivo izbornih mogućnosti Pomoćna procedura koja se poziva glavnom procedurom Naziv za kolonu u kojoj se nalaze vrednosti atributa Postupak za premeštanje mišem na drugu lokaciju Kolona ili više kolona koje na jedinstven način identifikuju neki slog Skup iskaza koji se izvršavaju kao celina Naziv koji predstavlja odreĎen broj, slovo ili niz Sistem za upravljanje relacionim bazama podataka Pravila za utvrĎivanje odnosa izmeĎu primarnih i stranih ključeva Radni ţurnal - pregled Računar koji svoje resurse i usluge daje računarima klijentima Snimak Ime elementa u tabeli
223
@ViPserbia
Strani ključ
Foreign key
Stranica
Page
SUBP Svojstvo
DBMS - Data Base Managemnet System Property
SQL Tabela
Simple Query Language Table
Transakcija
Transaction
Traţenje
Seek
Upit
Query
Višekorisnički sistem
Multiuser system
Zapis
Record
Kolona ili skup kolona čije vrednosti odgovaraju primarnom ključu u nekoj tabeli sa kojom se spajaju Blok od 2 kilobajta koji sadrţi zapise neke tabele Sistem za upravljanje bazama podataka Osnovna karakteristika nekog objekta Jednostavan jezik za upite Objekat baze podataka koji se sastoji iz redova i kolona Jedinstven skup operacija potrebnih za postizanje ţeljenog rezultata Pronalaţenje ţeljenog zapisa u bazi ili datoteci Poseban zahtev za dobijanje potrebnih podataka iz baze Ovaj sistem omogućava istovremeno korišćenje resursa ili baze od strane više korisnika Jedan elemenat tabele u relacionoj bazi podataka
224
@ViPserbia
16. LITERATURA: 1. 2. 3. 4. 5.
Access '97 tutorial Access 2000 tutorial Access 2002 tutorial Access 2003 tutorial Kao dopunski izvori informacija su posluţili: - Operating and user manuals - Radni i korisnički manuali za razne baze - internet izvori čije su adrese date u nastavku: - http://mis.bus.sfu.ca/tutorials/MSAccess/tutorials.html - http://www.bcschools.net/staff/AccessHelp.htm - http://www.jmu.edu/computing/tutorials/microsoft/access/ http://cisnet.baruch.cuny.edu/holowczak/classes/2200/access/accessall .html - http://cru.cahe.wsu.edu/training/Access97/ - http://isds.bus.lsu.edu/cvoc/learn/introit/access/ - http://www.fgcu.edu/support/office2000/access/begin.html http://www.customguide.com/access_tutorial/access_tutorial_2000_de mo.htm - http://www.oit.duke.edu/ats/training/docs/access1/
225
