Uvod u baze podataka singidunum

UNIVERZITET SINGIDUNUM

Prof. dr Mladen VeinovićDoc. dr Goran Šimić

U VOD U BAZ E P ODTAK A

Peto izdanje

Beograd, 2010.

UVOD U BAZE PODATAKA

Autori:Prof. dr Mladen VeinovićDoc. dr Goran Šimić

Recenzenti:Prof. dr Milan MilosavljevićProf. dr Ljubiša Stanojević

Izdavač:UNIVERZITET SINGIDUNUMBeograd, Danijelova 32www.singidunum.ac.rs

Za izdavača:Prof. dr Milovan Stanišić

Tehnička obrada:Novak Njeguš

Dizajn korica:Aleksandar Mihjalović

Godina izdanja:2010.

Tiraž:870 primeraka

Štampa:Mladost GrupLoznica

ISBN: 978-86-7912-252-0

Sadržaj III

p o g l a v l j e 1 2

Sadržaj

Predgovor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1. Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Osnovni koncepti i defi nicije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1. Podatak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Informacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3. Metapodaci - podaci o podacima (metadata) . . . . . . . . . . . . . . 102.4. Sistem za upravljanje bazama podataka . . . . . . . . . . . . . . . . . . . 11

3. Klasičan sistem zasnovan na datotekama . . . . . . . . . . . . . . . . . . . 133.1. Nedostaci sistema zasnovanog na datotekama . . . . . . . . . . . . . 15

4. Pristup zasnovan na bazama podataka . . . . . . . . . . . . . . . . . . . . . 174.1. Prednosti pristupa zasnovanog na bazama podataka . . . . . . . . 184.2. Troškovi i rizici pristupa zasnovanog na bazama podataka . . 194.3. Tipično okruženje baze podataka . . . . . . . . . . . . . . . . . . . . . . . . 21

5.Primene baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.1. Lične baze podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2. Baze podataka za radne grupe . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3. Baze podataka odeljenja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4. Baze podataka organizacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.5. Internet, Intranet i Extranet baze podataka . . . . . . . . . . . . . . . . 29

IV Sadržaj

6. Istorija razvoja baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7. Modelovanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1. Razvoj konceptualnih modela . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2. Entiteti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.3. Veze između entiteta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.4. Troslojna arhitektura baze podataka . . . . . . . . . . . . . . . . . . . . . . 45

8. Modeli baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.1. Hijerarhijski model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.2. Mrežni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.3. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.4. Objektni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9. Strukturna sistemska analiza (SSA) . . . . . . . . . . . . . . . . . . . . . . . . 579.1. Funkcionalna dekompozicija . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

9.1.1. Jacksonovi dijagrami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.1.2. Pravila u kreiranju Jacksonovih dijagrama . . . . . . . . . . . . 60

9.2. Dijagrami tokova podataka (DTP) . . . . . . . . . . . . . . . . . . . . . . . 629.2.1. Kontekstualni dijagrami . . . . . . . . . . . . . . . . . . . . . . . . . . . 689.2.2. Dijagram toka podataka 0. nivoa . . . . . . . . . . . . . . . . . . . . 699.2.3. Kompletan primer dekompozicije kroz DTP . . . . . . . . . . 70

9.3. Rečnik podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.3.1. Defi nisanje struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.3.2. Defi nisanje polja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.3.3. Defi nisanje domena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10. Model objekti-veze (MOV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8110.1. Dijagrami objekti-veze (DOV) . . . . . . . . . . . . . . . . . . . . . . . . . 8210.2. Objekti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8310.3. Atributi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8410.4. Veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8410.5. Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

11. Relacioni model podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9111.1. Istorija i razvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9211.2. Ključni koncepti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Sadržaj V

11.3. Objekti u relacionom modelu podataka . . . . . . . . . . . . . . . . . . 9511.3.1. Šema relacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9611.3.2. Relacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9611.3.3. Relaciona baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . 9711.3.4. Kandidat ključ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9711.3.5. Primarni ključ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9811.3.6. Spoljni ključ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.4. Integritet podataka u relacionom modelu . . . . . . . . . . . . . . . . 9911.4.1. Korisnička pravila integriteta . . . . . . . . . . . . . . . . . . . . . 10011.4.2. NULL vrednost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10111.4.3. Opšta pravila integriteta . . . . . . . . . . . . . . . . . . . . . . . . . 10211.4.4. Identifi kacioni integritet . . . . . . . . . . . . . . . . . . . . . . . . . 10211.4.5. Referencijalni integritet . . . . . . . . . . . . . . . . . . . . . . . . . . 102

12. Relaciona algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10512.1. Restrikcija - σ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10612.2. Projekcija - π . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10712.3. Unija - ��12.4. Razlika - / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11112.5. Presek - ��12.6. Dekartov proizvod - × . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

12.3.1. Spajanje - >< . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.6.2. θ spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.6.3. Ekvi spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.6.4. Prirodno spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

12.7. Deljenje - / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

13. SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11913.1. Terminologija SQL-a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11913.2. PRAVILA SQL-a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

13.2.1. Pravila za pisanje imena . . . . . . . . . . . . . . . . . . . . . . . . . 12113.2.2. O naredbama i izrazima . . . . . . . . . . . . . . . . . . . . . . . . . 12113.2.3. Tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12213.2.4. Defi nicija atributa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

13.3. Naredbe SQL-a za defi nisanje . . . . . . . . . . . . . . . . . . . . . . . . . 12313.3.1. Rad sa tabelama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

13.4. Pogledi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12513.5. Indeksi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

VI Sadržaj

13.6. SELECT upiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12713.6.1. Prost upit nad jednom tabelom: . . . . . . . . . . . . . . . . . . . 12713.6.2. Prost upit nad jednom tabelom sa svodnim rezultatom: . . . . . . . . . . . . . . . . . . . . . . . . . . 12913.6.3. WHERE klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13013.6.4. ORDER BY klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13013.6.5. GROUP BY klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13013.6.6. HAVING klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13113.6.7. Korišćenje NULL vrednosti . . . . . . . . . . . . . . . . . . . . . . 13113.6.8. LIKE klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

13.7. Naredbe ažuriranja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13113.7.1. INSERT naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13213.7.2. UPDATE naredba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13313.7.3. DELETE naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13313.8. Naredbe za kontrolu prava pristupa . . . . . . . . . . . . . . . . . 13413.8.1. GRANT naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13413.8.2. REVOKE naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

14. Relacije loše strukture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13714.1. Redundansa (ponavljanje) podataka i anomalije ažuriranja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

14.1.1. Anomalije unosa podataka . . . . . . . . . . . . . . . . . . . . . . . 13814.1.2. Anomalije brisanja podataka . . . . . . . . . . . . . . . . . . . . . 13814.1.3. Anomalije promene podataka . . . . . . . . . . . . . . . . . . . . 139

14.2. Funkcionalna zavisnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13914.3. Postupak normalizacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13914.4. Prva normalna forma (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . 14014.5. Druga normalna forma (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . 142

14.5.1. Potpuna funkcionalna zavisnost . . . . . . . . . . . . . . . . . . 14214.5.2. Defi nicija druge normalne forme . . . . . . . . . . . . . . . . . 142

14.6. Treća normalna forma (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . 14314.6.1. Tranzitivna zavisnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14314.6.2. Defi nicija treće normalne forme . . . . . . . . . . . . . . . . . . 143

14.7. Boyce-Codd normalna forma (BCNF) . . . . . . . . . . . . . . . . . . 14314.8. Četvrta normalna forma (4NF) . . . . . . . . . . . . . . . . . . . . . . . . 144

14.8.1. Zavisnost višestruke vrednosti . . . . . . . . . . . . . . . . . . . . 14414.8.2. Defi nicija četvrte normalne forme . . . . . . . . . . . . . . . . . 145

14.9. Peta normalna forma (5NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14614.9.1. Postojanost spajanja (lossless-join) . . . . . . . . . . . . . . . . 14614.9.2. Defi nicija pete normalne forme . . . . . . . . . . . . . . . . . . . 146

Sadržaj VII

15. Transakcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14715.1. Defi nicija transakcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14815.2. Osobine transakcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14915.3. COMMIT i ROLLBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15115.4. Konkurentno izvršavanje transakcija . . . . . . . . . . . . . . . . . . . 15215.5. Protokol zaključavanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15315.6. Oporavak baze podataka. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

16. Baze podataka i aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15716.1. Slojevita struktura aplikacija . . . . . . . . . . . . . . . . . . . . . . . . . . 15816.2. Troslojni model kao osnovni model . . . . . . . . . . . . . . . . . . . . 15916.3. Višeslojni modeli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15916.4. Aplikacije servisi (nezavisne soft verske komponente) . . . . . 16116.5. Specifi čnosti pristupa BP iz različitih aplikacionih slojeva . . . . . . . . . . . . . . . . . . . . . . . . . . 162

16.5.1. Pristup podacima iz prezentacionog sloja . . . . . . . . . . 16216.5.2. Pristup podacima iz sloja poslovne logike . . . . . . . . . . 16816.5.3. Pristup iz sloja podataka (poziv ugnježdenih procedura) . . . . . . . . . . . . . . . . . . . 170

16.6. Tehnologije koje omogućavaju razmenu podataka između BP i aplikacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

17. Dodatak 1. Informacioni sistem kafi ća . . . . . . . . . . . . . . . . . . .18317.1. Korisnički zahtev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18317.2. SSA – Strukturna Sistem Analiza . . . . . . . . . . . . . . . . . . . . . . . 183

17.2.1. Dijagram konteksta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18417.2.2. Prvi nivo dekompozicije . . . . . . . . . . . . . . . . . . . . . . . . . 18417.2.3. Drugi nivo dekompozicije (Nabavka) . . . . . . . . . . . . . . 18517.2.4. Drugi nivo dekompozicije (Prodaja) . . . . . . . . . . . . . . . 18517.2.5. Drugi nivo dekompozicije (Uplata banci) . . . . . . . . . . 186

17.3. Rečnik Podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18617.4. MOV – Model Objekti-Veze . . . . . . . . . . . . . . . . . . . . . . . . . . 188

17.4.1. Nabavka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18817.4.2. Prodaja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18917.4.3. Uplata banci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

17.5. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19017.5.1. Nabavka: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19017.5.2. Prodaja: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19017.5.3. Uplata banci: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

17.6. Access Tabele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

VIII Sadržaj

18. Dodatak 2. Servis za održavanje rada soft verskog sistema . . .19518.1. Korisnički zahtev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19518.2. SSA – Strukturna Sistem Analiza . . . . . . . . . . . . . . . . . . . . . . . 196

18.2.1. Dijagram konteksta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19618.2.2. Dekompozicija prvog nivoa . . . . . . . . . . . . . . . . . . . . . . 19618.2.1. Dekompozicija procesa . . . . . . . . . . . . . . . . . . . . . . . . . . 197

18.3. Rečnik podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19818.4. Specifi kacija primitivnog procesa . . . . . . . . . . . . . . . . . . . . . . 19918.5. Dijagram dekompozicije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20118.6. Model objekti veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20218.7. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20318.8. Opis scenarija korišćenja sistema . . . . . . . . . . . . . . . . . . . . . . 20318.9. Fizičko projektovanje modela podataka – Access tabele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20718.10. Strukturna ograničenja i pravila integriteta . . . . . . . . . . . . . 20818.11. Forme za unos podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

19. Dodatak 3. Uvoz i distribucija proizvoda bele tehnike . . . . . .21519.1. Korisnički zahtev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21519.2. Strukturna sistemska analiza . . . . . . . . . . . . . . . . . . . . . . . . . . 216

19.2.1. Dijagram konteksta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21619.2.2. DTP- prvi nivo dekompozicije . . . . . . . . . . . . . . . . . . . . 21719.2.3. Drugi nivo dekompozicije - nabavka . . . . . . . . . . . . . . 21819.2.4. Drugi nivo dekompozicije – prodaja . . . . . . . . . . . . . . . 21919.2.5. Drugi nivo dekompozicije – servis . . . . . . . . . . . . . . . . 220

19.3. Dijagram dekompozicije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22119.4. Model objekti-veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22219.5. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22519.6. Tabele, tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22619.7. Ekranske forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231

Rečnik pojmova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Predgovor 1

p o g l a v l j e 1 2

Predgovor

Knjiga Uvod u baze podataka je namenjena studentima Univerziteta Sin-gidunum za pripremu ispita iz predmeta Baze podataka, ali može biti od koristi i svima onima koji kroz praksu i teoriju savladavaju baze podataka. Nastala je kao rezultat višegodišnjeg rada na Fakultetu za fi nansijski menadžment i osiguranje i na Fakultetu za poslovnu informatiku Univerziteta Singidunum. U toku izlagan-ja materije autori se nisu vezivali za konkretan soft verski sistem za upravljanje bazama podataka, već su nastojali da na jednom mestu prikažu sve koncepte u bazama podataka u skladu sa savremenim kretanjima u ovoj oblasti. Domi-nantno je razmatran relacioni model podataka koji jeste osnova za najveći broj poslovnih aplikacija.

Knjiga je podeljena u nekoliko delova. Na početku se iznose osnovni kon-cepti i defi nicije koje se koriste u bazama podataka. Čitalac se polako vodi od klasičnih sistema za rad sa podacima, koji su zasnovani na programskim jezicima i datotekama, ka pravim bazama podataka koje se zasnivaju na sistemu za upra-vljanje bazama podataka. U nastavku se razmatra modelovanje i uvode različiti modeli podataka, onako kako su se istorijski pojavljivali. Baze podataka ne posto-je same za sebe. One su osnova informacionih sistema, kako velikih tako i malih organizacija, a projektuju se sa ciljem dobijanja pravovremenih informacija za donošenje odluka. Zbog toga je posebna pažnja posvećena strukturnoj sistemskoj analizi, kao početnom koraku u projektovanju baza podataka. Detaljno je razmo-tren relacioni model podataka, a u okviru njega posebna pažnja je posvećena inte-gritetskim komponentama, koje omogućavaju održavanje konzistentnosti jedne baze podataka. U nastavku je ukratko razmatrana relaciona algebra kao osno-va za upitne jezike, a zatim su prikazane mogućnosti ANSI SQL jezika za rad sa

2 Predgovor

relacionim bazama podataka. Na primerima relacija loše strukture diskutovani su karakteristični problemi koji se odnose na anomalije ažuriranja, a zatim je objaš-njen postupak normalizacije ovakvih relacija. Danas se baze podataka uglavnom koriste u mrežnom okruženju, gde se više transakcija konkurentno izvršava nad istom bazom podataka. Diskutovani su mehanizmi koji omogućavaju nesmetan paralelan rad više transakcija. Na kraju su prikazane različite tehnike povezivanja baza podataka i aplikacija. Posebno se razmatra raslojavanje aplikacija čime se postiže veća funkcionalnost samih aplikacija i lakše se zadovoljavaju naknadni zahtevi korisnika.

U dodatku su dati primeri razvoja baza podataka u Access-u za tri različita slučaja iz prakse, koji mogu da posluže studentima, kao i diplomiranim inženjeri-ma i ekonomistima za razvoj sopstvenih aplikacija. Zahvaljujemo se svim studen-tima Univerziteta Singidunum koji su kroz izradu seminarskih radova doprineli da ovaj tekst bude bogat konkretnim primerima.

Autori su se potrudili da izlaganje bude što jasnije, da ne opterete čitaoca kompleksnim matematičkim aparatom niti konkretnim soft verskim alatima, a sve u cilju što jasnijeg predstavljanja baza podataka. Pošto je ovo prvo izdanje knjige, svi saveti i eventualne primedbe na tekst su dobrodošli.

Beograd, mart 2007. godine Autori

Uvod 3

Po g l a v l j e 1 .

Uvod

Baze podataka se koriste za prikupljanje, čuvanje i manipulaciju podacima na osnovu kojih se dobijaju nove informacije u različitim organizacijama, kao što su poslovni sistemi, zdravstvo, školstvo, vladine institucije itd. Svakodnevno ih koriste pojedinci putem ličnih računara, radne grupe putem mrežnih servera i svi zaposleni putem aplikacija koje se nalaze u poslovnim sistemima. Bazama podataka takođe pristupaju kupci i drugi udaljeni korisnici korišćenjem različitih tehnologija kao što su govorni automati, web čitači (browser-i), digitalni telefo-ni i sl. Zbog velike konkurencije u svim oblastima poslovanja, može se očekivati da tehnologija baza podataka dobije još veći značaj. Menadžeri traže način da iz baze podataka brže dođu do novih saznanja kako bi bili u prednosti u odnosu na svoju konkurenciju. Na primer, detaljna baza podataka o prodaji se može iskoris-titi kako bi se saznalo koji kupci kupuju koje proizvode, što se koristi kao osno-va za reklamu i marketinšku kampanju. Organizacije mogu da uključe u svoje baze podataka procedure koje se zovu okidači - trigeri (alerts) koji upozoravaju o mogućim vanrednim događajima (kao što su predstojeći nedostatak zaliha neke robe ili šansa za prodaju dodatne količine robe) i na osnovu kojih mogu nastati odgovarajuće reakcije. Mnoge organizacije danas prave posebne baze podataka koje se zovu „skladišta podataka“ (data werehouses) koje služe za aplikacije za podršku u odlučivanju.

Izučavanje baza podataka i sistema za upravljanje bazama podataka jesu osnova za izučavanje informacionih sistema. Stručnjak za informacione sisteme mora biti spreman da analizira potrebe preduzeća i da dizajnira i implementira baze podataka u okviru razvoja informacionog sistema jedne organizacije. Takođe, mora biti spreman da se konsultuje sa krajnim korisnicima i da im pokaže kako

4 Uvod

se korišćenjem baza podataka može imati bolja podrška za odlučivanje, čime se stvara prednost nad konkurencijom. Široko rasprostranjeno korišćenje baza podataka vezanih za Internet sajtove, koji vraćaju dinamičke informacije korisni-cima web sajta, zahteva od projektanta da razume ne samo kako da poveže bazu podataka sa sajtom već i kako da je obezbedi tako da se njenom sadržaju može pristupiti ali ne i izmeniti od strane spoljnih korisnika.

Postoji puno načina kako se može defi nisati baza podataka. U osnovi to je skup podataka koji su organizovani prema potrebama korisnika, koji se održava-ju i koji se koriste za dobijanje informacija. Moderne baze podataka su čuvaju na računaru, ali to nije bitno za samu defi niciju. Na primer, adrese poznanika i prijatelja, kolekcija fi lmova na CD-ovima, telefonski imenik itd. su takođe baze podataka (mada ih većina ljudi tako ne zove). Međutim, smeštanje baze podataka na računar omogućava lakšu i bržu obradu podataka i dobijanje željene informa-cije. Karakterističan je primer sa telefonskim imenikom koji se nalazi na papiru. Jednostavno je pronaći telefonski broj željene osobe, ali je znatno teže pronaći ime osobe na osnovu telefonskog broja. Ako je telefonski imenik veći (više smeštenih podataka) prethodni problem se dodatno usložnjava. Računarski zasnovane baze podataka omogućavaju jednostavno i brzo dobijanje informacija. Pored osnov-nih informacija iz odgovarajuće baze podataka se mogu dobiti i posebne infor-macije. Na primeru telefonskog imenika mogu se izlistati podaci za sve osobe po imenu npr. Marko, mogu se izlistati sve osobe kojima telefonski broj počinje npr. sa 2, osobe kojima se telefonski broj završava sa 45 i još mnogo toga.

Na razvoj baza podataka presudno je uticao razvoj računara, računarskih mreža, kao i klijent/server obrade. Istraživanje, projektovanje i upotreba baza podataka su vrlo brzo pokazali niz svojih dobrih strana kao što su: smanjeni troš-kovi održavanja; smanjena potreba za mrežnim resursima; poboljšan integritet podataka; donošenje ispravnih odluka na osnovu objektivnih informacija, brža reakcija na tržištu, itd.

Baza podataka smeštena u računaru, predstavljena je nizom bita, organizo-vanih u bajtove, a sa više bajtova u odgovarajućem formatu zapisuju se vrednosti pojedinih podataka i predstavljaju jedno polje baze podataka. Niz polja se organi-zuje u zapise (rekorde) koji imaju značenje jer mogu da predstavljaju opis nekog objekta iz realnog sveta ili neke veze između objekata realnog sveta. Zapisi istog formata se slažu i čine datoteke, koje su fi zički zapisane na disku. Baza podataka obuhvata više povezanih datoteka i može biti centralizovana na jednom računaru

Uvod 5

ili distribuirana na više međusobno udaljenih računara. Pored podataka koji su zapisani u bazi podataka, postoje i posebni podaci kojima se opisuju pojedina-čne datoteke, njene osobine, karakteristični parametri iz datoteka, uspostavljene međusobne veze, pravila koja se odnos na pojave koje postoje i u realnom svetu i sl. Takvi podaci se zovu meta-podaci (metadata), tj. podaci o podacima. Koriste se pri pokretanju rada sa bazom podataka, kako bi se mogli učitati svi konfi guracio-ni podaci odgovarajuće baze (self-describing).

NEKADA

DANAS

Slika 1.1. – Baze podataka nekada i danas

Osnovni koncepti i defi nicije 7


Osnovni koncepti i defi nicije

Baza podataka se može defi nisati kao organizovani skup logički povezanih podataka. Ona može biti bilo koje veličine i kompleksnosti. Na primer, prodavac može da ima malu bazu podataka vezanu za kupce na svom notebook računaru koja se sastoji od nekoliko megabajta podataka. Preduzeće koje zapošljava hilja-du i više ljudi može da ima veoma veliku bazu podataka od nekoliko terabajta podataka (jedan terabajt = 1012 bajtova) na mainframe kompjuteru na kome se nalazi aplikacija za podršku odlučivanju. Veoma velika skladišta podataka ima-ju više od petabajta podataka (1 petabajt = 1015 bajtova). U širem smislu, bazu podataka možemo posmatrati kao integrisani skup podataka o nekom sistemu i skup postupaka za njihovo održavanje i korišćenje, organizovan prema potrebama korisnika. To je dobro struktuirana kolekcija podataka, koja postoji jedno određe-no vreme, koja se održava i koju koristi više korisnika ili programa.

2.1. PodatakIstorijski, pod terminom podatak se podrazumeva činjenica o nekom pred-

metu i/ili događaju koja se može zabeležiti i sačuvati na računaru. Na primer, u bazi podataka nekog prodavca podaci bi bile činjenice kao što su ime, adresa i broj telefona kupca. Ovakav tip podatka se zove struktuirani podatak. Najvažniji struktuirani podaci su brojevi, karakteri i datumi (vreme). Današnje baze podata-ka pored struktuiranih podataka sadrže i druge vrste podataka kao što su razna dokumenta, mape, fotografi je, zvuk, čak i video zapise. Na primer, u bazi podataka nekog prodavca mogla bi se naći i slika kupca. Takođe bi se mogao naći zvuč-ni ili video zapis poslednjeg razgovora sa kupcem. Ova vrsta podatka se naziva

8 Osnovni koncepti i defi nicije

nestruktuirani podatak ili multimedijalni podatak. Multimedijalni podaci se naj-češće mogu naći na web serverima i u Internet bazama podataka.

Danas se podatak defi niše kao sačuvana reprezentacija predmeta i/ili događaja koja ima smisla i važnosti za korisnika baze podataka. Ova defi nicija uključuje i struktuirane i nestruktuirane podatke. Često se u okviru jedne baze podataka mogu naći kombinovani struktuirani i nestruktuirani podaci kako bi se stvorilo multimedijalno okruženje. Na primer, automehaničarska radnja može kombinovati struktuirane podatke (koji opisuju klijenta i njegova kola) sa multi-medijalnim podacima (slika automobila i skenirana kopija osiguranja).

Pod podatkom se podrazumeva činjenica prihvaćena kao takva tj. kakva jeste. Podatak sam po sebi nema značenje, tek kada se interpretira nekom vrstom sistema za obradu podataka poprima značenje i postaje informacija. Tipično, ter-min “podatak” se odnosi na ono što je u bazi podatak. Dakle, podatak je sirova činjenica - neobrađena informacija. Računar vrši obradu podataka, prema zada-tom programu, te se na osnovu saznanja sadržanih u podacima, a kao rezultat njihove obrade, stiču nova saznanja - informacije.

2.2. InformacijaTermini podatak i informacija su usko povezani i često se koriste kao sinoni-

mi. Međutim, korisno je razlikovati termine podatak i informacija. Informaciju defi nišemo kao podatak koji je bio obrađen na takav način da se znanje osobe koja koristi podatak povećalo. Na primer, razmotrimo sledeći spisak činjenica:

Petar Petrović 1506983710325

Marko Marković 0211979850123

Janko Janković 1112985830456

- - - - - - - - - - - - - - - - - - - - - -

Prikazane činjenice po defi niciji predstavljaju podatke, ali bi se većina složila da su ovi podaci u sadašnjoj formi beskorisni. Čak iako pretpostavljamo da se radi o imenima osoba i njihovim matičnim brojevima, podaci ostaju beskorisni jer ne znamo čemu služe. Pogledajte šta se događa kada stavimo ove iste podatke u kontekst, kao što je pokazano na slici 2.1. Dodavanjem još nekoliko dodatnih


podataka i njihovim uređivanjem, prepoznajemo spisak upisanih studenata. Na ovaj način se dolazi do informacije koja je korisna npr. upravi fakulteta, profeso-rima, studentskoj službi i sl.

Ime i prezime JMBG Smer Godina upisa

Petar Petrović 1506983710325 PP 2002

Marko Marković 0211979850123 RGD 2001

Janko Janković 1112985830456 PP 2001

- - - - - - - - - - - - - - - - - - - - - - BIZ 2003

Slika 2.1. – Tabelarni prikaz podataka iz BP - informacija o upisu

Drugi način da se iz podataka dobiju informacije je da se podaci sumiraju ili na neki drugi način obrade i prezentuju. Na primer, na slici 2.2 se vide sumirani podaci o upisu studenata prezentirani u vidu grafi čke informacije. Ova informa-cija se može iskoristiti kao osnova za odlučivanje o dodavanju novih predavan-ja ili o zapošljavanju novog nastavnog kadra. Moderne baze podataka vrlo često sadrže i podatke i informacije. Podaci se često obrađuju i čuvaju u obrađenoj for-mi i služe za pomoć pri donošenju odluka, a takvim podacima (informacijama) se najbrže pristupa.

Slika 2.2. – Grafi čki prikaz podataka iz BP - informacija o upisu


Podaci obrađeni tako da dobijaju značenje čine informaciju. Informacija koja je precizna, relevantna, i dobijena na vreme je ključ za donošenje dobre odluke.

Slika 2.3. – Obradom prikupljenih podataka nastaje informacija

2.3. Metapodaci - podaci o podacima (metadata)Podaci koji se prikupljaju i čuvaju u bazi podataka često se nazivaju i podaci

krajnjih korisnika (end user data). Metapodaci su podaci koji opisuju svojstva ili karakteristike podataka krajnjih korisnika i kontekst tih podataka. Neka tipična svojstva podataka su naziv (ime) podatka, defi nicija, dužina (veličina), i dozvol-jene vrednosti. Kontekst podataka, koji opisuju metapodaci, podrazumeva izvor podataka, gde se čuvaju podaci,vlasništvo i korišćenje.

Tabela 2.1. – Primer metapodataka

Naziv Tip Dužina Min Max Opis Izvor

Ime Text 30 Ime i prezime studenta Lična karta

JMBG Integer 1 Jedinstven matični broj Lična karta

Smer CHAR 3 Smer na fakultetu Studentska služba

GodUpisa Number 2001 Godina upisa Studentska služba

Metapodaci opisuju svojstva podatka ali se nalaze odvojeno od tog podatka. Metapodaci iz tabele1.1 ne prikazuju ni jedan podatak. Oni omogućavaju dizajne-rima i korisnicima baza podataka da razumeju koji podaci postoje u bazi, šta oni


znače, i koja je razlika između podataka koji na prvi pogled izgledaju isto. Upra-vljanje metapodacima je veoma bitno jer podaci bez jasnog značenja mogu biti zbunjujući, pogrešno protumačeni ili puni grešaka.

2.4. Sistem za upravljanje bazama podatakaSistem za upravljanje bazama podataka (DBMS - Data Base Management

System) je soft verski sistem koji se koristi za kreiranje, održavanje i manipuli-sanje podacima, kao i za kontrolu prava pristupa bazi podataka. DBMS omo-gućava krajnjim korisnicima i programerima da dele podatke, tj. omoguća-va da se podaci koriste od strane više aplikacija, a ne da svaka aplikacija ima svoju kopiju podatka sačuvanu u posebnim datotekama. DBMS takođe pruža mogućnost kontrole pristupa podacima, osigurava integritet podataka, uspos-tavlja kontrolu konkurentnosti i vrši oporavak baze podataka. Programeri apli-kacija za rad sa bazama podataka ne moraju da poznaju detalje o načinu zapisa baze podataka na disku, ne moraju da formulišu algoritme za efi kasan pristup podacima, niti su opterećeni bilo kakvim aspektima oko upravljanja podacima u bazi podataka.

Danas je veoma bitan i značajan koncept baze podataka po kome je to, u stvari, zajednički resurs koga istovremeno (konkurentno) koristi veći broj pro-grama, jer se pravi efekti baze podataka ispoljavaju kada se radi u mrežnom okruženju. Posmatrajmo bazu podataka jedne banke u kojoj se nalaze računi građana. Moguće je da se u istom trenutku na šalteru u jednoj ekspozituri podiže novac sa jednog računa i uplaćuje na drugi račun, a da se istovremeno u sasvim drugoj ekspozituri uplaćuje novac na isti taj račun. Pomenuti DBMS je upravo tu da upravlja konkurentnim radom više korisnika i da obezbeđuje sinhroniza-ciju njihovog rada.

Takođe, DBMS ima funkciju da spreči štetne posledice (narušen integri-tet baze, nekonzistentno stanje baze...) pri promenama (transakcijama) koje se vrše nad bazom podataka u višekorisničkom okruženju. U tu svrhu postoje razne tehnike kao što su tehnika zaključavanja podataka, tehnika vremenskog markiranja itd. Posebno je značajno upravljanje istovremenim (konkurentnim) transakcijama. Tačnost, zaštita i dostupnost baza podataka, kao i korektnost i performanse transakcija koje pristupaju tim bazama su bitni parametri za uspeh svakog poslovnog sistema.


Termini baza podataka i upravljanje bazom podataka se ponekad meša-ju. Stručno govoreći, baza podataka je uvek skup činjenica, a ne računarski program.

DBMS je uveden kao interfejs između korisnika (korisničkih programa, aplikacija) i zapisa baze podataka na disku. Korisnički programi ne pristupaju podacima direktno, već komuniciraju sa ovim soft verom (programom). DBMS upravlja strukturom baze podataka: defi niše objekte baze, njihova svojstva (atri-bute), dozvoljene vrednosti atributa, veze između objekata, ograničenja nad objektima i međusobnim vezama. Omogućava manipulaciju podacima u bazi: unošenje, brisanje i izmene, tj. omogućava njeno održavanje. Kontroliše pristup podacima: ko može da pristupi podacima, kojim podacima i šta može sa njima da radi.. DBMS dozvoljava deljenje BP između više aplikacija/korisnika i čini upra-vljanje podacima uspešnijim i delotvornijim Uobičajeno je da kada se govori o soft veru za baze podataka, onda se misli upravo na DBMS. DBMS upravlja inter-akcijom između krajnjih korisnika (aplikacija) i baze podataka. Krajnji korisnici imaju bolji pristup većem broju bolje organizovanih podataka

Slika 2.3. – DBMS je interfejs između (aplikacija) korisnika i zapisa baze podataka na disku

Klasičan sistem zasnovan na datotekama 13


Klasičan sistem zasnovan na datotekama

Kada su se računari počeli koristiti za obradu podataka, nisu postojale baze podataka. Računari su u to vreme bili znatno slabiji nego današnji personalni računari, zauzimali su čitavu prostoriju i koristili su se skoro isključivo za naučna izračunavanja. Postepeno su računari uvođeni u poslovni svet. Da bi bili od koris-ti za poslovne aplikacije, računari moraju da skladište, manipulišu, i preuzimaju velike datoteke podataka. Kako su poslovne aplikacije postajale sve kompleksnije, postalo je očigledno da klasični sistemi zasnovani na datotekama imaju veliki broj nedostataka i ograničenja. U većini bitnih poslovnih aplikacija danas se umesto klasičnog sistema zasnovanog na datotekama koriste baze podataka.

Klasičan sistem obrade podataka zasnovan na datotekama i programskim jezicima prikazan je blok šemom na sledećoj slici. Programi su direktno povezani sa datotekama, svaki program mora da poznaje detaljan zapis podataka na disku.

Slika 3.1. – Klasičan sistem obrade podataka zasnovan na programskim jezicima i datotekama

14 Klasičan sistem zasnovan na datotekama

Da bi objasnili osnovne karakteristike sistema zasnovanog na datoteka-ma, posmatrajmo jednu fabriku sa određenim proizvodnim programom. Pret-postavimo da su nabavljene računarske aplikacije za vođenje poslovanja ove fabrike realizovane na klasičnim sistemima koji se zasnivaju na datotekama. Ovaj pristup dizajnu informacionog sistema se fokusira na potrebe za obradom podataka pojedinačnih odeljenja, a ne na potrebe organizacije kao celine. Kada bi se kod korisnika javila potreba za novim sistemima pisali bi se novi računar-ski programi za individualne aplikacije kao što su kontrola proizvoda, prijem računa, ili kadrovsko poslovanje. Svaki od programa pravi se tako da odgovara potrebama određenog odeljenja ili radne grupe. Prema tome, ne postoji opšti plan, mapa ili model kojim bi se rukovodili za planiranje razvoja sistema. Tri računarske aplikacije (A, B i C) pomoću kojih se obrađuju podaci zapisani u datotekama su prikazane na slici 3.2. Programima se održavaju tri nezavisna sis-tema porudžbine, naplate i plate. Na slici se takođe vide osnovne datoteke veza-ne za svaku aplikaciju. Na primer, proces porudžbina ima tri datoteke: podaci o kupcu, podaci o proizvodima, podaci o porudžbinama. Neke od datoteka se ponavljaju u sva tri procesa (redudansa) što je tipično za sistem obrade podata-ka koji se zasniva na datotekama.

Slika 3.2. – Klasična obrada podataka zasnovana na sistemu datoteka

Klasičan sistem zasnovan na datotekama 15

3.1. Nedostaci sistema zasnovanog na datotekamaPostoji više mana koje su tipične za sistem koji je zasnovan na datotekama i

klasičnim programskim jezicima. Ove mane za primer prikazan na slici 3.2 ukrat-ko su opisane u nastavku.

• Zavisnost između programa i podataka Opisi datoteka se čuvaju u okviru svakog programa koji pristupa toj dato-

teci. Na primer, u procesu porudžbine sa slike 3.2 program A pristupa datoteci sa podacima o kupcu. Stoga, ovaj program sadrži detaljan opis datoteke. Kao posledica ovoga, svaka promena koja se napravi u datoteci, a odnosi se na strukturu, momentalno podrazumeva da se mora menjati i opis datoteka u svakom programu koji pristupa tim podacima. Primetite na slici 3.2 da se podaci o kupcima nalaze i u procesu porudžbine i u pro-cesu naplate. Pretpostavimo da se veličina polja “adresa kupca” menja sa 20 karaktera na 30 karaktera. Opis datoteke u svakom programu (možda čak u svih pet) se mora ažurirati. Često je teško i samo lociranje svih pro-grama na koje je uticala ovakva promena. Što je još gore pri ažuriranju se često prave greške.

• Redudansa podataka Kako se u prikazanom sistemu procesi odvijaju nezavisno jedni od drugih,

ponavljanje podataka nije izuzetak već je pravilo. Na primer, na slici 3.2 proces porudžbina ima datoteke sa osnovnim podacima o proizvodima dok proces naplate ima datoteku o cenama proizvoda. Dakle, obe ove datoteke sadrže podatke o istim proizvodima kao što su: cena po jedinici proizvoda, opis proizvoda, i količina u skladištu. Zbog nepotrebnih duplikata potreban je veći prostor za njihovo čuvanje kao i više truda i rada pri njihovom ažuri-ranju. Neplanirana redudansa podataka može da dovede do gubitka podata-ka. Na primer, isti podaci mogu se voditi pod različitim imenima atributa u različitim dokumentima, ili obrnuto, isto ime se može koristiti za različite vrste podataka.

• Ograničenost deljenja podataka Korišćenjem klasičnog sistema zasnovanog na datotekama, svaki proces

ima svoje datoteke i korisnici nemaju šansu da međusobno dele podatke sa korisnicima iz drugih procesa. Na slici 3.2 se vidi da radnici u računo-vodstvu imaju pristup samo procesu naplate, dok nemaju pristup procesi-

16 Klasičan sistem zasnovan na datotekama

ma porudžbina i plata. Menadžeri su imali velike probleme pri sastavljanju izveštaja za koje su im bili potrebni podaci iz različitih procesa, jer bi se često desilo da su dokumenta nekompatibilna i da je potrebno dosta pro-gramiranja kako bi se svi ti podaci sakupili u jedan izveštaj. Takođe, dodatni problem je bio u tome što su se željeni podaci često nalazili u različitim odeljenjima organizacije.

• Dugo vreme za razvoj Sa klasičnim sistemom zasnovanom na datotekama postoji mala šansa za

korišćenje prethodnih razvojnih dostignuća. Svaka nova aplikacija zahteva od projektanta da krene od nule. Svaki put je neophodno defi nisati nove formate i opise podataka i pisati kod za pristup podacima za svaki program. Ovako veliko potrebno vreme za razvoj nije u skladu sa današnjim poslov-nim potrebama, gde je svaki minut bitan da bi se postigao uspeh.

• Teško održavanje programa Skup svih prethodno navedenih nedostataka dovodi do preterane potrebe

za održavanjem programa. Čak 80% budžeta predviđenog za razvoj sistema zasnovanog na datotekama odlazi na njegovo održavanje. Zbog toga, narav-no, ostaje jako malo prostora za razvoj novih aplikacija.

Važno je znati da većina mana klasičnog sistema zasnovanog na datote-kama, koje smo u prethodnom delu teksta pominjali, mogu isto tako biti ogra-ničenja za bazu podataka, pogotovo ako se ne promeni pristup razvoju baze podataka. Na primer, ukoliko preduzeće razvije nekoliko zasebnih baza podata-ka (recimo, za svaku radnu jedinicu ili proces po jednu bazu) sa malom ili nika-kvom vezom između njih, onda može doći do bespotrebnog ponavljanja istih podataka, ograničenja deljenja podataka, produžavanja vremena potrebnog za razvoj i preterane potrebe za održavanjem programa.

Pristup zasnovan na bazama podataka 17


Pristup zasnovan na bazama podataka

Pristup zasnovan na bazama podataka potencira integraciju i deljenje podataka između svih odeljenja jedne organizacije. Ovaj pristup zahteva potpunu promenu u načinu razmišljanja, počevši od najvišeg nivoa upravljanja. Takva pro-mena načina razmišljanja za većinu organizacija je veoma teška.

Da bi objasnili pristup zasnovan na bazama podataka posmatrajmo pre-thodno razmatrani zastareli informacioni sistem fabrike koji se klasično zasnivao na datotekama. Koncept pristupa razvoju informacionog sistema zasnovanog na bazama podataka prikazan je na slici 4.1. Odmah se može uočiti da podaci koji su prethodno čuvani u više različitih datoteka, sada su integrisani u jedinstvenu bazu podataka. Takođe, metapodaci koji opisuju ove podatke se nalaze zajedno sa njima u bazi podataka. Sistem za upravljanje bazama podataka pruža mogućnost stvaranja različitih pogleda na istu bazu podataka (ili baze podataka) za različite korisnike u organizaciji. DBMS dozvoljava korisnicima da dele, pretražuju, pristu-paju i ažuriraju integrisanim podacima.

Slika 4.1. – Blok šema informacionog sistema zasnovanog na bazama podataka

18 Pristup zasnovan na bazama podataka

4.1. Prednosti pristupa zasnovanog na bazama podatakaPristup zasnovan na bazama podataka ima mnogo potencionalnih pred-

nosti u odnosu na pristup zasnovan na datotekama. Te potencionalne prednosti su sledeće:

• Nezavisnost između programa i podataka Odvajanje metapodataka od aplikacija koje koriste podatke naziva se neza-

visnost podataka. Ova osobina kod baza podataka dozvoljava promenu i prenos podataka organizacije na druge računarske sisteme bez potrebe za promenom programa koji obrađuje ove podatke.

• Minimalna redudansa podataka Cilj pristupa zasnovanog na bazama podataka je da se podaci koji su se u

prethodnom pristupu čuvali odvojeno (i više puta su zbog toga ponavlja-ni) sada integrišu u jedinstvenu logičku strukturu. Svaki podatak se nala-zi samo na jednom mestu u bazi podataka. Pristup zasnovan na bazama podataka ne uklanja redudansu u potpunosti, ali omogućava projektantu baze podataka da pažljivo isplanira vrstu i količinu redudanse. U nekim slučajevima je poželjno napraviti ograničenu redudansu kako bi se perfor-manse baze podataka poboljšale (npr. brža pretraga).

• Poboljšana konzistentnost podataka Eliminisanjem (ili kontrolisanjem) redudanse podataka, u velikoj meri se

smanjuju šanse za nekonzistentnošću podataka. Na primer, ukoliko je adresa kupca zapisana na samo jednom mestu ne može da postoji ne podudaranje u podacima u bazi podataka. Takođe, ažuriranje podataka je u velikoj meri uprošćeno, kada je svaka vrednost zapisana na samo jednom mestu. Na kra-ju, uklanjanjem redudanse podataka dolazi do uštede memorije.

• Poboljšana razmena podataka Baza podataka je dizajnirana kao resurs organizacije koji koriste svi njeni

zaposleni (kojima je ona neophodna u opisu posla). Određenim internim i eksternim korisnicima je dozvoljeno korišćenje baze podataka, i svaki od njih (bio u pitanju jedan korisnik ili grupa) ima jedan ili više pogleda koji mu olakšavaju korišćenje baze podataka. Korisnički pogled je logički opis jednog dela baze podataka koji je neophodan korisniku da obavi neki zadatak.


• Povećana produktivnost u razvoju aplikacija Velika prednost pristupa zasnovanog na bazama podataka je ta što se u

znatnoj meri smanjuju troškovi i vreme potrebno za razvoj novih poslovnih aplikacija. Postoje dva važna razloga zašto se aplikacije baza podataka raz-vijaju znatno brže nego kod klasičnih sistema sa datotekama:1. Pretpostavljajući da su baza podataka i sve propratne aplikacije već napra-

vljene i implementirane, programer se može koncentrisati na određenu funkciju koja je neophodna za novu aplikaciju, a ne mora da razmišlja o defi nisanju podataka ili o detaljima vezanim za implementaciju.

2. DBMS pruža veliki broj alata za izveštavanje, kao što su generatori formi i izveštaja, i jezike uz pomoć kojih se automatizuju neke od aktivnosti kao što su dizajn i implementacija baza podataka.

• Smanjena potreba za održavanjem programa Sačuvani podaci se moraju često menjati iz velikog broja razloga: nove vrs-

te podataka se dodaju, formati podataka se menjaju, i tako dalje. Poznat primer ovoga problema je ulazak u 2000-tu godinu, kada se sa uobičaje-nog sistema prikazivanja godina sa dve cifre moralo preći na četiri cifre. U sistemu obrade datoteka, metapodaci i logika pristupanju podacima se nalaze u individualnim aplikacionim programima (ovo je zavisnost između programa i podataka o kojoj je ranije bilo reči). Kao rezultat ovoga, prome-na formata podataka i metoda pristupanja momentalno dovodi do potrebe menjanja aplikativnih programa. Kod baza podataka, podaci su znatno više nezavisni od aplikativnih programa koji ih koriste. U okviru određenih gra-nica, možemo da promenimo jednu od stavki, format podataka ili aplika-tivni program, a da ne moramo da promenimo drugu stavku. Kao rezultat ovoga, javlja se smanjenje potreba za održavanjem programa.

4.2. Troškovi i rizici pristupa zasnovanog na bazama podatakaU prethodnom delu teksta navedeno je nekoliko glavnih potencijalnih

prednosti pristupa zasnovanog na bazama podataka. Međutim, kod velikog bro-ja organizacija bilo je različitih problema kod ostvarenja i iskorišćenja tih pred-nosti. Na primer, postizanje nezavisnosti podataka (i stoga, smanjene potrebe za održavanjem programa) se pokazalo kao teško ostvarivo zbog ograničenja


starijih modela baza podataka i soft vera za upravljanje bazama podataka. Na sre-ću, relacioni modeli (kao i noviji objektno-orjentisani modeli) nemaju ovih pro-blema. Drugi razlog za neuspeh da se iskoriste ove prednosti, je loše planiranje i implementacija baza podataka – čak ni najbolji soft ver za upravljanje bazama podataka ne može da prevaziđe ovakve manjkavosti. Pristup zasnovan na baza-ma podataka sadrži neke dodatne troškove i rizike koji se moraju rešavati kada se sistem počne primenjivati.

• Novo, obučeno osoblje Često se dešava da preduzeće, koje se odluči za pristup zasnovan na bazama

podataka, mora da angažuje ili obuči ljude za projektovanje, implementi-ranje i održavanje baza podataka, kao i da te ljude uključi u postojeću radnu organizaciju. Dalje, zbog čestih izmena i brzine razvoja tehnologije, znanje ovog novog osoblja zahteva stalnu nadgradnju i unapređivanje. Jedino obu-čeno osoblje može da izvuče maksimum korisnosti iz novih tehnologija.

• Troškovi i složenost instaliranja, upravljanja i rada sistema sa bazama podataka

Višekorisnički sistem za upravljanje bazama podataka je veliki i složen soft ver koji u startu mnogo košta, zahteva obučeno osoblje za instaliranje i rad i ima značajne godišnje troškove za održavanje i tehničku podršku. Instaliranje ovakvog sistema može zahtevati nadogradnju hardvera. Stalne obuke se podrazumevaju, da bi se mogle pratiti nove verzije i nadogradnje soft vera. Takođe se može pojaviti potreba za dodatnim i skupljim soft verom za baze podataka radi veće sigurnosti podataka.

• Troškovi prilagođavanja (konvertovanja) podataka Termin nasleđeni sistemi se uglavnom koristi kada se govori o starijim apli-

kacijama u preduzeću koje su bazirane na datotečnom pristupu ili starijim bazama podataka. Troškovi prilagođavanja ovakvih starijih sistema za rad sa modernim bazama podataka (mereni u novcu, vremenu i zahtevnosti posla) često deluju kao velika prepreka za preduzeće.

• Potreba za izradom sigurnosnih kopija i oporavkom podataka (backup) Deljena baza podataka preduzeća uvek mora biti tačna i dostupna. To

zahteva razvijanje i korišćenje jasnih procedura izrade sigurnosnih kopija kao i oporavak baze podataka kada neko oštećenje nastane. U današ njem okruženju, gde postoje raznovrsni bezbednosni rizici, rešavanje ovog


problema je od izuzetne važnosti. Moderan sistem za upravljanje baza-ma podataka obično sam obavlja izradu sigurnosnih kopija i oporavak podataka u slučaju havarija.

• Konfl ikti u organizaciji Deljena baza podataka zahteva saglasnost u vezi sa defi nicijama i vlasniš-

tvom podataka, kao i utvrđenu osobu ili osobe odgovorne za održavanje podataka. Iskustvo je pokazalo da nesuglasice u pogledu defi nicija podata-ka, formata i kodiranja podataka, prava na ažuriranje deljenih podataka i sl. su česta i vrlo teška tema za rešavanje. Da bi se ovi problemi rešili potrebno je da je organizacija u potpunosti posvećena uvođenju/korištenju pristupa zasnovanog na bazama podataka. Zatim je potreban sposoban adminis-trator baze podataka kao i smislen pristup razvoju baza podataka. Ukoli-ko podrška i posvećenost glavnih menadžera za pristup okrenut bazama podataka izostane, velika je šansa da će krajnji korisnici razviti veći broj samostalnih baza podataka. Ove baze podataka će teško pružiti prednosti koje smo prethodno opisali. U krajnosti, one mogu da dovedu do donošenja loših odluka što naravno ugrožava celu organizaciju.

4.3. Tipično okruženje baze podatakaGlavni delovi tipičnog okruženja baze podataka i njihove veze su prikazani

na slici 4.2. 1. Baza podataka – Organizovan skup logički povezanih podataka, obično napra-

vljena da zadovolji potrebe za informacijama više korisnika u organizaciji. 2. Metapodaci – Centralna baza „znanja“ za sve defi nicije podataka, njihova

ograničenja, veze između podataka, izgleda ekrana i izveštaja, i drugih sis-temskih komponenti.

3. DBMS – Sistem za upravljanje bazama podataka (SUBP). Soft verski sistem koji se koristi za kreiranje, održavanje i kontrolu pristupa korisnika baze podataka.

4. Aplikativni programi – Računarski programi koji služe za kreiranje i održavanje baze podataka i pružaju informacije korisnicima.

5. Administratori podataka i baza podataka – Administratori podataka su osobe odgovorne za upravljanje svim izvorima podataka u organizaciji. Administratori podataka su odgovorni za fi zički dizajn baza podataka i za upravljanje tehničkim problematikama u okruženju baza podataka.


6. Projektanti sistema – Osobe kao što su sistemski analitičari i programeri koji dizajniraju nove aplikativne programe. Projektanti sistema često koriste CASE alate za analizu potreba sistema i dizajn programa.

7. Korisnički interfejs – Jezici, meniji, i itd. pomoću kojih korisnici koriste različite komponente sistema, kao što su CASE alati, aplikativni programi, DBMS i metapodaci.

8. Computer-aided soft ver engineering – (CASE) alati Alati koji se koriste za dizajniranje baza podataka i aplikativnih programa.

9. Krajnji korisnici – Osobe koje dodaju, brišu i modifi kuju/ažuriraju podat-ke u bazi podataka i koje zahtevaju ili primaju podatke iz njih. Svaka inter-akcija između korisnika i baze podataka dešava se preko DBMS-a.

Slika 4.2. – Komponente okruženja BP


Sa unapređenjem softvera, korisnički interfejs postaje sve lakši za upo-trebu. Primeri za ovakav napredak su sistemi zasnovani na menijima, siste-mi sa mogućnošću pristupa Internetu, i sistemi koji prepoznaju govor (pri-hvataju govorne komande). Cilj ovih sistema je da što više krajnjih korisnika može da koristi računar, što znači da korisnici koji nisu računarski eksperti mogu sami da naprave izveštaje i koriste jednostavne aplikacije. Naravno, u ovakvom okruženju administratori baza podataka moraju da obrate pažnju na bezbednost baze podataka. Okruženje baze podataka prikazano na slici 4.2 predstavlja integrisani sistem hardvera, softvera i ljudi koji je napravljen da olakša skladištenje, preuzimanje, i kontrolu izvora informacija i da poveća produktivnost preduzeća.

Primene baza podataka 25


Primene baza podataka

Vrste baza podataka variraju od onih pravljenih za jednog korisnika PC računara do baza koje su smeštene na glavni računar (mainframe) i kojima pristupaju hiljade korisnika. Po broju korisnika koji im pristupaju, baze podataka se mogu podeliti u više kategorija: lične baze podataka, baze podataka za radne grupe, baze podataka odeljenja, baze podataka preduzeća i Internet, intranet i ekstranet baze podataka.

5.1. Lične baze podatakaLične baze podataka se prave za korišćenje od strane jednog korisnika i već

su dugo prisutne u korišćenju personalnih računara. Pojavom ličnih digitalnih pomoćnika (PDA), lične baze podataka su našle primenu i u nizu mobilnih ure-đaja koji osim računarskih imaju i neke druge primene npr. mobilni telefoni, faks mašine, Internet čitači. Jednostavne aplikacije sa bazom podataka u kojoj čuvaju informacije i detalje o komunikaciji sa svakim klijentom, mogu da se koriste i sa računara i sa ličnog digitalnog pomoćnika, kao i da se prebacuju sa jednog na drugi uređaj radi izrade sigurnosnih kopija (backup) ili zbog zahteva posla. Uzmi-mo za primer preduzeće koje ima određeni broj prodavaca koji su u kontaktu sa postojećim i potencijalnim klijentima. Ako svaki prodavac ima još neke aplikacije, npr. grafi čke prezentacije, cenovnik sa uslovima prodaje po kojem klijentu može ponuditi najpovoljniju kombinaciju proizvoda i količina za naručivanje, onda bi mu za takav posao prenosni računar, zbog svojih performansi i skladišnog pro-stora, mogao biti optimalno rešenje. S druge strane, ako prodavac ima samo listu klijenata i kontakata, njemu bi lični digitalni pomoćnik i aplikacija koja koristi malu bazu podataka bili najbolje rešenje.

26 Primene baza podataka

Lične baze podataka se široko primenjuju jer često mogu bitno unaprediti produktivnost pojedinca. Međutim, one sadrže jedan faktor rizika: podatke ovih baza nije lako deliti sa drugim korisnicima. Na primer, ako bi menadžer prodaje želeo celokupan spisak klijenata i kontakata, to se ne bi moglo ni brzo ni lako ura-diti uzimanjem podataka iz ličnih baza svakog od prodavaca. Ovo ilustruje veoma čest problem: ako su neki podaci od interesa jednom čoveku, onda su verovatno (ili će brzo postati) od interesa i drugim ljudima. Zbog toga, lične baze podataka bi trebalo svesti na korišćenje pod posebnim okolnostima (npr. u veoma malim preduzećima) gde je verovatnoća potreba za deljenjem podataka između korisni-ka izuzetno mala.

5.2. Baze podataka za radne grupeRadnu grupu čini relativno mali broj ljudi koji sarađuju na jednom pro-

jektu ili aplikaciji ili na grupi sličnih projekata ili aplikacija. Radna grupa obično sadrži desetak ljudi. Oni mogu biti uključeni u npr. planiranje, projektovanje ili razvoj novog računarskog programa. Baza podataka za radne grupe služi za pod-ršku zajedničkog rada jedne takve grupe. Uzmimo za primer, radnu grupu koja pravi i standardne i programe po porudžbini, koji se prodaju soft verskim kom-panijama kao i krajnjim korisnicima.Obično, jedna ili više osoba rade na datom programu, ili dele programe, u isto vreme. Grupi je potrebna baza podataka koja će da prati razvoj svakog dela i koja će da omogući da se podaci što lakše razmen-juju među članovima tima.

Svaki član radne grupe ima svoj računar, a računari su umreženi putem LAN-a. Baza podataka se nalazi na centralnom računaru koji se zove server baze podataka, koji je takođe na mreži. Stoga, svaki član grupe ima pristup podacima. Različiti članovi grupe (u zavisnosti da li je u pitanju rukovodilac projekta ili projektant, programer) mogu imati različita ovlašćenja (privile-gije), a time i različite poglede na podatke. Primetićete da je glavna mana ličnih baza podataka, teško ostvariva razmena podataka, ovde prevaziđena (barem je razmena podataka u okviru grupe lako ostvariva). Međutim, raz-mena podataka otvara nova pitanja i probleme koji nisu postojali kod ličnih baza podataka. Glavni problemi upravljanja podacima su vezani za njihovu bezbednost i integritet, s obzirom da više korisnika može istovremeno da obavlja ažuriranje podataka.


5.3. Baze podataka odeljenjaOdeljenje je funkcionalna radna jedinica u okviru organizacije. Tipični pri-

meri odeljenja su: kadrovsko, marketing, proizvodnja, računovodstvo i sl. Odel-jenje je obično veće od radne grupe (nekada se sastoji i do 100 osoba) i odgovorno je za veći broj različitih poslova. Baze podataka odeljenja su napravljene da podrže različite oblike poslova i aktivnosti koje obavlja to odeljenje. Uzmimo za primer bazu podataka kadrovskog odeljenja u kojoj se prate podaci vezani za zaposlene, vrste poslova, stručnu spremu i poslovna zaduženja. Kada su svi relevantni podaci sačuvani u bazi podataka, korisnici mogu da pretražuju bazu podataka u cilju dobijanja odgovora na pitanja kao što su sledeća:

• Za određenu vrstu zanimanja (npr programer) kakve prilike za zaposlenje trenutno postoje u organizaciji?

• Za tu istu vrstu posla koja stručna sprema ili veština je neophodna?

• Koje veštine, znanje poseduje određeni radnik? I obrnuto, koji radnici pose-duju određenu veštinu, znanje?

• Koji sve radnici su obavljali određeni posao u organizaciji? I obrnuto, koje sve poslove je određeni radnik obavljao u organizaciji?

• Koje sve zaposlene nadgleda određeni menadžer?

Tipična pitanja na koja se treba odgovoriti pri pravljenju baze podataka odeljenja su:

1. Kako baza podataka i njeno okruženje trebaju da budu organizovani da bi se ostvarile zadovoljavajuće performanse, uzimajući u obzir veliki broj korisnika i veliki broj transakcija?

2. Kako na odgovarajući način obezbediti podatke od nedozvoljenog pristupa i/ili distribucije?

3. Koje alate za razvoj baze podataka i aplikacija treba koristiti u slučaju ovako kompleksnog okruženja?


4. Da li i druga odeljenja koriste iste vrste podataka, i ako je to slučaj, kako se najbolje može upravljati podacima po pitanju njihove redudantnosti i kon-zistentnosti i metapodacima po pitanju njihove konzistentnosti?

5. Da li su korisnici baze podataka geografski jedni od drugih udaljeni ili je veličina baze podataka tolika da se podaci moraju čuvati na više računara, tako stvarajući distribuirane baze podataka?

6. Da li se bazi podataka može pristupati preko Interneta i da li ona treba da bude uključena u intranet organizacije?

5.4. Baze podataka organizacijaBaza podataka organizacije obuhvata čitavu organizaciju ili više njenih ode-

ljenja. Ova vrsta baza podataka je namenjena da podrži sve procese organiza-cije i proces donošenja odluka. Važno je istaći da jedna organizacija može ima-ti više baza podataka, tako da jedna takva baza podataka ne sadrži sve podatke jedne organizacije. Jedna baza podataka za celu organizaciju srednjih do velikih dimenzija ne bi bila praktična iz mnogo razloga. Kao prvo zbog različitih potre-ba različitih korisnika, kompleksnosti stvaranja jedinstvenih metapodataka za sve korisnike baze podataka je ogromna. Baza podataka organizacije pruža podršku za jedan određeni broj (skup) odeljenja. Tokom poslednje decenije, razvoj baza podataka organizacije je doveo do dva najvažnija oblika:

1. Enterprise resource planning (ERP) sistem

2. Implementacija skladišta podataka (data werehouses)

ERP sistemi rade sa tekućim podacima organizacije, dok skladišta podataka sakupljaju podatke iz raznih operativnih baza podataka, uključujući i lične, radnih grupa, odeljenja i ERP baze podataka. Skladišta podataka pružaju mogućnost korisnicima da rade sa prethodnim podacima kako bi pronašli obrazce i trendove događaja i kako bi odgovorili na pitanja koja su vezana za strategiju poslovanja.

Uzmimo za primer veliku zdravstvenu organizaciju koja upravlja grupom medicinskih centara, u šta spadaju domovi zdravlja, bolnice, klinike i starački domovi. Svaki od ovih medicinskih centara ima svoju bazu podataka (ili baze


podataka) koja pruža podršku u obavljanju raznih poslova. Ove baze podataka imaju podatke o pacijentima, doktorima, medicinskim uslugama, poslovanju i drugim bitnim entitetima. Baza podataka pruža adekvatnu podršku za većinu poslova u svakom pojedinačnom medicinskom centru. Međutim, postoji potreba za jedinstvenim pogledom na celu organizaciju; na primer, da bi se videla sva poslovanja sa jednim dobavljačem ili pacijentom. Povećanje produktivnosti se može postići uvođenjem, na primer, centralnog sistema za naručivanje mate-rijala za sve zdravstvene centre i raspoređivanjem osoblja i usluga koje vrše na sve zdravstvenim centre. ERP sistem omogućava uvođenje prethodnih promena. Donošenje odluka na nivou cele organizacije, u vezi sa poslovanjem sa dobavljači-ma, i podnošenje izveštaja raznim agencijama zahteva sakupljene svih prethodnih podataka i informacija. Da bi se zadovoljile ove potrebe, organizacija koristi skla-dište podataka koje se održava i nalazi u sedištu organizacije. Podaci koji se nalaze u skladištu podataka su preuzeti (i potom sumirani) iz pojedinačnih baza podata-ka svakog medicinskog centra. Ovaj proces preuzimanja podataka se odvija peri-odično putem telekomunikaciono- računarske mreže.

5.5. Internet, Intranet i Extranet baze podatakaInternet tehnologije služe za olakšavanje deljenja podataka i informacija.

Na primer, u okviru fabrike može se koristiti lokalna mreža (LAN) koja pove-zuje radne stanice zaposlenih iz raznih odeljenja sa serverom na kome se nalazi baza podataka. LAN unapređuje komunikaciju i proces donošenja odluka u okviru same kompanije. Ako se uvede Intranet koji se zasniva na Web tehno-logiji, njemu se može pristupati samo u okvirima kompanije. Radna stanica svakog zaposlenog se može koristiti kao web browser, i na taj način se dobija brz pristup informacijama kompanije, uključujući i telefonski adresar, speci-fi kacije proizvoda, elektronsku poštu i tome slično. Takođe se radne stanice mogu koristiti i kao personalni računari koji povezani preko LAN-a pristupaju serveru na kome se nalazi baza podataka. Moguće je dodati i Web interfejse nekim poslovnim aplikacijama, kao što su unošenje porudžbina, da bi na taj način više internih poslovnih aktivnosti moglo biti obavljano od strane zapo-slenih preko intraneta.

U cilju efi kasnijeg ukupnog poslovanja intranet sistem se može otvoriti ka kupcima preko Interneta. Ovo omogućava maloprodajama da pretražuju katalog proizvoda (uključujući slike i specifi kacije proizvoda) i utvrde da li


željenog proizvoda ima u skladištu. Tada radnici u maloprodajnim objekti-ma mogu da obaveste svoje kupce i da poruče željeni komad proizvoda preko Interneta. Internet konekcija je konfi gurisana kao extranet što znači da samo odobrene maloprodaje mogu da pristupe intranet-u fabrike.

Sve veće korišćenje Interneta, svetske mreže koja povezuje korisnike, nebit-no koje platforme je dovelo i do promena u okruženju baza podataka. Prihva-tanje Interneta od strane poslovnog sveta je dovelo do bitnih promena u davno utvrđenim modelima poslovanja. Veoma uspešne kompanije su bile ugrožene zbog novih kompanija koje su prihvatile Internet pomoću koga su unapredi-le informisanje i usluge koje su pružale svojim klijentima, i koje su zaobišle tipične tokove marketinga i distribucije proizvoda. Na primer, kupci konfi guri-šu i poručuju svoj PC računar direktno od proizvođača računara. Informacije o upražnjenim mestima i aktivnostima organizacije se mogu dobiti preko Interne-ta za većinu organizacija.

Svaka od ovih radnji zahteva podršku baze podataka. Lak pristup Interne-tu svih vrsta platformi omogućava kompanijama da reorganizuju svoje poslove i razviju brže aplikacije i to po manjim troškovima. Standardni interfejsi omo-gućavaju veću produktivnost korisnika, uz manje provedenog vremena na obuci, i manju potrebnu podršku. Osnova razvoja korisnikove aplikacije je priključivanje baze podataka iz koje se mogu dobiti sveže informacije. Kada je baza podata-ka povezana sa nekom Internet lokacijom, korisnici preko Web browser-a mogu da postavljaju određena pitanja na koja će dobiti odgovore bazirane na svežim informacijama. Odgovaranje na pitanja je automatsko; nema potrebe da se putem telefona prolazi kroz niz opcija da bi se postavilo pitanje nekoj osobi i da bi se zatim od nje čekao odgovor. Internet baze podataka su nezamenljive u razvoju sajtova za kupovinu preko Interneta. Kompanije prate sva dešavanja na sajtu kako bi došli do što više informacija o svojim klijentima (obrazci pri kupovini, naviga-cija sajtom, dužina zadržavanja na svakoj stranici i tome slično) kako bi što više unapredili svoj odnos prema kupcima.

Većina primera koji su navedeni prikazuju Business-to-Customer (B2C) veze. Kada su kupci kod nekih fi rmi druge fi rme, takav odnos se obično naziva B2B (Business-to-Business) odnos. Internet se koristi da olakša B2C odnos, zato što su kupci obavezno spoljni faktor u odnosu na fi rmu, i mogućnost kupca da pristupi poslovnim podacima i informacijama je od velike važnosti za uspešan odnos. Dozvoljavanjem pristupa poslovnim bazama podataka, od strane osoba


koje nisu deo organizacije, javljaju se nova pitanja za rukovođenje informacionim sistemima vezana za sigurnost i integritet podataka.

Kompanije su godinama vršile razmenu informacija putem elektronske raz-mene podataka (EDI- eletronic data interchange). Mnoge kompanije i dalje koriste EDI sistem za obavljanje B2B poslovanja. Neke kompanije, uglavnom nove ili one koje nisu imale EDI sistem, koriste extranet za obavljanje B2B razmena podataka i informacija. Extranet koristi Internet tehnologiju, međutim, pristup extranetu je, za razliku od Interneta kome mogu svi pristupiti, ograničen. Ustvari, pristup je ograničen na kompanije koje su u ulozi dobavljača i kupca i koje imaju međusob-ni dogovor o pristupu podacima i informacijama jednih drugima. Obično, pre-thodno pomenuti akteri imaju pristup delu intranet-a drugog aktera. Ovaj način pristupa olakšava poslovne odnose tako što pruža brži i efi kasniji način obrade i pristupanja podacima.

Kao što je prethodno pomenuto mnoge organizacije su koristile Internet tehnologiju za stvaranje privatne mreže namenjene za upravljanje informacija-ma u okviru organizacije. Po izgledu ne postoji razlika između intranet i Inter-net stranica, ali pristup intranet stranici je ograničen samo na korisnike u okviru te organizacije. Stoga je i pristup bazi podataka organizacije ograničen. Intranet može da ostvari Internet konekciju ali ta konekcija će biti zaštićena fi rewall-om koji sprečava neovlašćeni pristup intranetu.

Istorija razvoja baza podataka 33


Istorija razvoja baza podataka

Nastanak baza podataka se vezuje za Herman-a Holerith-a koji je 1884. godine prijavio patent – sistem za automatsku obradu podataka (AOP) o popisu stanovništva u SAD. Podaci na bušenim karticama su ručno ubacivani u uređaj za očitavanje, a obrada podataka se odnosila na prebrojavanje. Programiranje se svodilo na izbor vrste prebrojavanja, a radilo se ručnim prespajanjem kontakata. Dotadašnja obrada podataka popisa trajala je 10-tak godina, a sa Holerith-ovim izumom vreme obrade bilo je smanjeno na šest nedelja. Herman Hollerith je osmislio ideju po kojoj se svaki stanovnik SAD predstavlja nizom od 80 karaktera – ime, godište itd. popunjenih praznim prostorima da bi se za sva imena obezbe-dila ista dužina, tako da baza podataka bude „poravnata“. On je uspeo da proda koncept svoje mašine i bušene kartice koje su služile za čuvanje podataka u statis-tičkom birou SAD. Tako je popis stanovništva iz 1890. godine bio prva automati-zovana baza podataka, koja se u suštini sastojala od hiljada kutija punih bušenih kartica. Od Holerith-ove kompanije nastao je današnji IBM.

Slika 6.1. – Izgled Holerith-ove bušene kartice i mašine za očitavanje kartica

34 Istorija razvoja baza podataka

Nakon Drugog svetskog rata, u kompanijama i vladinim institucijama poče-li su se pojavljivati prvi elektronski računari. Oni su se često koristili upravo za jednostavne linearne baze podataka, najčešće za računovodstvo. Ipak, vrlo brzo, bogati kupci su počeli da zahtevaju više od njihovih ekstremno skupih mašina. Sve je to vodilo do ranih baza podataka. Zanimljivo, ove rane aplikacije su nasta-vile da koriste Hollerith-ove bušene kartice, neznatno modifi kovane u odnosu na originalni dizajn. Nefl eksibilnost polja iste dužine, baze podataka pokretane 80 kolonskim bušenim karticama, učinile su rane računare metom napada i šala i potpunom misterijom za običnog čoveka.

Većina prvobitnih baza podataka se odnosila na specifi čne programe napisane za specifi čne baze podataka. Za razliku od modernih sistema koji mogu biti primenjeni na potpuno različite baze podataka, ovi sistemi su bili usko povezani za bazu podataka da bi osigurali brzinu na uštrb fl eksibilnosti. Sistemi upravljanja bazama podataka su se prvi put pojavili tokom 1960-tih godina i nastavili su da se razvijaju tokom sledećih decenija. U većini slučajeva, period uvođenja je dugo trajao, skoro deceniju pre navedene godine početka upotrebe. Na primer, relacioni model je prvi put defi nisan od strane E.F.Codd u tekstu objavljenom 1970 godine. Međutim, relacioni model nije bio široko prihvaćen sve do 1980-tih godina.

1960’te

Tokom ovog perioda, sistemi zasnovani na datotekama su i dalje imali dominantnu ulogu. Pa ipak, prvi sistemi za upravljanje bazom podataka su uve-deni u ovoj deceniji, i korišćeni su najpre samo kod velikih i složenih projeka-ta, kao što je to bio projekat sletanja Apollo-a na Mesec. Ovaj period možemo posmatrati kao period ’dokazivanja’, u kom je demonstrirana sposobnost ovih sistema da upravljaju ogromnim količinama podataka. Takođe, prvi napor da se standardizuju poduzet je sa formiranjem DBT Grupe (Data Base Task Group), tokom kasnih ’60-ih godina.

1970’te

Tokom ove decenije, upotreba sistema za upravljanje bazom podataka je postajala komercijalna stvarnost. Hijerarhijski i mrežni sistemi za upra-vljanje podacima su uvedeni, velikim delom zbog potrebe za sistemom koji će moći da upravlja složenim strukturama podataka, kao što su računi fabrika


pri nabavci sirovina, kojima je bilo izuzetno teško upravljati preko konvenci-onalnih metoda. Ovi modeli se i suštinski smatraju prvom generacijom siste-ma za upravljanje bazom podataka. Oba pristupa su se široko primenjivala, zapravo, mnogi od tih sistema su u upotrebi i danas. Pa ipak, imali su nekoliko velikih nedostataka:

• Težak pristup podacima. Za pristup i najjednostavnijim podacima bili su potrebni izuzetno složeni programi.

• Veoma ograničena nezavisnost podataka, tako da se programi nisu mogli izolovati od promena u formatu podataka.

• Nije postojala nijedna široko prihvaćena teorijska podloga za bilo koji od ovih modela, za razliku od relacionog modela podataka.

1980’te

Da bi se prevazišla ova ograničenja, E. F. Codd, kao i mnogi drugi, razvili su model relacionih podataka tokom ’70-ih godina. Ovaj model, koji se smat-ra drugom generacijom DBMS-a, doživeo je široku komercijalnu upotrebu u poslovnom svetu tokom ’80-ih godina. Sa relacionim modelom svi podaci su predstavljeni u formi tabele. Relativno jednostavan programski jezik četvrte generacije, nazvan SQL, korišćen je za dobijanje informacija. Ovaj model je obe-zbedio jednostavan pristup podacima i onim ljudima koji nisu bili programeri, prevazilazeći na taj način jednu od najvećih primedbi koja je pratila sisteme prvih generacija. Model je takođe pokazao i svoju pogodnost za komunikaciju na relaciji klijent/server, paralelni prenos podataka, i upotrebu grafi čkog koris-ničkog interfejsa (GUI).

1990’te

Ove godine se označavaju kao nova računarska era, najpre na nivou računarske komunikacije na relaciji klijent/server, a potom sa stvaranjem skla-dišta za podatke i upotrebom Internet aplikacija, koji su dobijali sve više na važnosti u ovom periodu. Kao što je upravljanje podacima od strane DBMS-a postalo visoko primenjivo (npr., u računovodstvu) tokom osamdesetih godina, multimedijalni podaci (uključujući i grafi ku, zvuk, slike i video zapis) su postali uobičajena stvar tokom devedesetih godina. Kako bi se izborili sa sve složenijim

36 Istorija razvoja baza podataka

podacima, tokom devedesetih su uvedeni sistemi okrenuti ka objektu, koji se smatraju trećom generacijom. Zbog velike potrebe za organizacijom ogromne količine podataka kako strukturisanih, tako i nestrukturisanih podataka, ovaj i prethodni sistem su u upotrebi i danas. Neki proizvođači čak rade na razvoju kombinovanih sistema za upravljanje bazama podataka, kako bi mogli da upra-vljaju obema vrstama istih.

Od 2000. godine

Naravno, navodimo se na razmišljanje u kom pravcu će da krene razvoj DBMS tehnologija tokom naredne decenije. Iako će nesumnjivo doći do novih iznenađenja, možemo očekivati nastavak dobro uspostavljenih trendova:

1. Mogućnost upravljanja sve složenijim tipovima podataka. Ovi tipovi uklju-čuju i multidimenzionalne podatke, koji su već dobili na važnosti u aplika-cijama skladištenja podataka.

2. Nastavak razvoja ’univerzalnih servera’. Zasnovani na sistemu treće genera-cije DBMs-a, to su serveri koji mogu da upravljaju širokom lepezom raznih tipova podataka, tako da budu transparentni svim korisnicima. Biće naroči-to važni kod Internet aplikacija.

3. Dok su u potpunosti distribuirane baze podataka postale realnost, trenutni trend ka centralizaciji istih će se nastaviti. Kako se troškovi komunikacije sve više smanjuju, nasuprot porastu tipova podataka,vrednost lociranja i pristupa centralizovanoj bazi podataka takođe se smanjuje. Manji troškovi, a visoke performanse svakako ohrabruju ovaj trend.

4. Skladišta sa adresiranim sadržajem će postajati sve popularnija. Sa ovakvim pristupom, korisnik može da izvuče bilo kakav podatak specifi kacijom kak-vu vrstu podatka želi, umesto kako da dođe do njega. Na primer, korisnik može da skenira fotografi ju i da traži od kompjutera pretragu, kako bi pro-našao istu takvu, ili njoj sličnu.

5. Baza podataka i druge tehnologije, poput veštačke inteligencije i televizije, kao informacionog servisa, olakšaće pristup podacima neobučenim koris-nicima. Na primer, korisnik će biti u mogućnosti da zahteva podatak na više jezika, a tehnologija baza podataka će da uključuje potrebe korisnika za podacima, na osnovu upita koji se čuvaju, i menjati se na taj način.


6. Rad na tehnologijama algoritama za tehniku analize podataka, koji teže ka upravljanju veoma velikim paketima podataka, kako bi organizacije što lakše analizirale svoja ogromna skladišta podataka. To će u velikoj meri olakšati u planiranju strategije organizacija za njihovo poslovanje za duže vremenske periode.

7. I na kraju skale se nalazi dalje širenje PDA, što će dovesti do poboljša-ne sinhronizacije malih baza podataka i poboljšanje brzine bežičnog prenosa. Bluetooth bežični standard će u velikoj meri ubrzati razvoj bežične konekcije na Internet. Ali će i nametnuti pitanje daljeg razvoja zaštite podataka.

Modelovanje 39


Modelovanje

Informacioni sistemi pojedinih fi rmi omogućavaju upravljanje podacima koji su bitni za njeno poslovanje. Međutim, broj internih podataka i podataka iz okruženja je ogroman te je nemoguće sve podatke i sve uočene detalje opisa-ti i sačuvati unutar informacionog sistema. Postupkom selekcije identifi kuju se i čuvaju samo relevantni podaci. Time se dolazi do pojma modela podataka. On je izraz i posledica zahteva za obradom podataka relevantnih za određeno područ-je primene. Modeli su čovekovo sredstvo pojednostavljivanja problema i njego-vo posmatranje samo sa stanovišta bitnih za ciljeve analize. Objekt posmatran-ja (npr. automobil) ima uvek više osobina (atributa) od kojih u datom trenutku analize može biti dovoljan samo njihov manji broj (npr. samo registarski broj, tip automobila, ime i prezime vlasnika). To su najvažniji atributi potrebni u postupku pretraživanja i pronalaženja vlasnika vozila na osnovu registarskog broja vozila unutar jednog informacionog sistema. Ostali atributi kao što su boja, godina pro-izvodnje, broj sedišta i sl. nisu bitni (mogu se zanemariti ) za takav postupak. Čo-vek, obdaren sposobnostima apstraktnog načina mišljenja, stvara jedan apstraktni model realnog sveta. Takav model realnog sveta (objekta posmatranja) zasniva se na simbolima i zove se konceptualni model podataka.

Modelovanje podataka se radi paralelno sa analizom potreba. Kako se infor-macije prikupljaju, objekti se identifi kuju, dodjeljuju im se imena koristeći termine bliske krajnjim korisnicima. Objekti se onda modeluju i analiziraju korištenjem dijagrama objekti-veze (ER dijagrami). Dijagram se može pregledati od strane dizajnera i krajnjeg korisnika da bi se osigurala njegova kompletnost i tačnost. Ako model nije tačan, modifi kuje se, što ponekad zahteva da se prikupe dodatne

40 Modelovanje

informacije. Ciklus pregledanja i modifi kovanja se nastavlja sve dok se ne dobije potvrda da je model korektan.

Slika 7.1. – Realan svet i njegov model

7.1. Razvoj konceptualnih modelaObjekti iz realnog sveta se u računarskoj primeni opisuju pomoću podata-

ka. Podaci su zato apstrakcija realnosti, tj. sredstva za kodiranje osobina objekata iz realnog sveta. Modelovane, kao postupak kojim se realni svet svodi na određeni broj podataka, predstavlja kompleksan posao i sastoji se iz više koraka:

• Izbor (selekcija). U prvom koraku se mnoštvo objekata iz realnog sveta redukuje na manji skup objekata, koji će činiti objekte modela. Npr. objekti mogu biti student, predmet, profesor, studentska služba, polaganje ispita i sl. U procesu selekcije ovaj broj objekata se može redukovati na manji broj, ako je cilj praćenje uspešnosti studiranja na fakultetu. Time se složenost realnog sistema smanjuje. Selekcija se ne odnosi samo na objekte nego i na njihove osobine, kao i na međusobne veze (relacije) između objekata.

• Imenovanje. Svakom objektu u realnom svetu, svakoj vezi između uočenih objekata, kao i svakom atributu (svojstvu) uočenog objekta ili veze dodelju-je se ime.

• Klasifi kacija. Nehomogeni skup objekata i odnosa se svrstava u homogene klase i tipove objekata. Klasifi kacija uvek zavisi od područja primene.

Modelovanje 41

Rezultat navedenih koraka modelovanja zove se konceptualni model. On sadrži, za posmatrani problem iz realnog sveta, sve relevantne tipove objekata, njihove osobine i međusobne veze. Rezultati proučavanja modela podataka doveli su do saznanja da svaki model podataka ima tri neodvojive komponente:

• strukturu podataka,

• operacije nad podacima,

• ograničenja (constraints).

Struktura i ograničenja, za razliku od operacija, opisuju stanje realnog sis-tema, tj. predstavljaju statički opis stanja sistema. Strukturu modela čine objekti, njihova svojstva, veze između objekata i njihovih svojstava. Operacije nad poda-cima u modelu su, u stvari, operacije nad strukturom modela kojima se izražava dinamika realnog sistema. Operacije izražavaju kretanje i promene tj. dinamiku realnog sistema. Ograničenja su pravila koja razdvajaju dopuštena od nedopuš-tenih stanja realnog sistema i u svojoj prirodi deo su strukture modela podataka. Ponekad se ne posmatraju kao odvojene komponenta, nego kao deo strukture modela podataka.

7.2. EntitetiModelima podataka nastoji se preslikati realan sistem. Realan sistem sastoji

se od objekata iz realnog sveta i njihovih veza između kojih se uspostavljaju razli-čiti odnosi. Pod entitetom se podrazumeva sve što se može jednoznačno odrediti, identifi kovati i razlikovati. Tako široko postavljena defi nicija pokazuje da entitet može biti svaki “realan” ili “apstraktan” objekt o kojem u određenom trenutku raz-mišljamo. Entitet je realan ako fi zički, stvarno postoji. Najopštije se može tvrditi da su granice entiteta u modelu podataka određene ljudskim pogledom i nači-nom razmišljanja.

Svaki entitet uočen u realnom sistemu ima svoje osobine koje ga čine složenim i njihove vrednosti omogućavaju razlikovanje entiteta. Svojstvo enti-teta uključuje dva elementa - atribut i vrednost atributa (npr. entitet Student ima atribute: Ime, Prezime, Broj indeksa, Adresu, Telefon i sl. i vrednosti Marko,

42 Modelovanje

Marković, 123/03, Danijelova, 15, 011/376-543 respektivno). Svaki put kada se promeni vrednost atributa, potrebno je promenu evidentirati, tj. ažurirati tu vrednost atributa za dati entitet.

Precizno govoreći, objekti koji se označe pojmom entiteta mogu se zvati klase entiteta. Svaki objekt ima osobine (atribute) klase entiteta kojoj pripada. Npr. klasu entiteta Student čine pojedinačni entiteti od kojih svaki ima zajedničke atribute: Ime, Prezime, Broj indeksa, Adresa, Telefon i sl. Svaki pojedinačni entitet ima sve navedene atribute, ali će se razlikovati od drugih entiteta po vrednostima pojedinih atributa.

Atribut opisuje entitet. Jedno konkretno pojavljivanje atributa naziva se vrednost. Ako je atribut dovoljno složen, tako da ima svoje dodatne atribute, može se posmatrati kao novi entitet.

Domen atributa je skup svih mogućih vrednosti koje atribut može poprimiti.

Primarni ključ je jedan ili više atributa čija vrednost jednoznačno određu-je primerak entiteta. Na primer, za entitet Auto, primarni ključ je atribut regis-tarski broj. Dva različita člana ili primerka entiteta ne mogu imati isti primarni ključ. Primarni ključ je jedinstven za svakog člana entiteta. Na primer, za entitet Student primarni ključ bi mogao biti broj indeksa.

7.3. Veze između entitetaBaza podataka se ne odnosi samo na pojedinačne objekte nego i na odnose

između objekata. U realnom sistemu objekti nisu međusobno izolovani, nego se nalaze u međusobnoj interakciji. Student se upisuje na fakultet, sluša predavanja iz pojedinih predmeta, prijavljuje polaganje ispita, polaže ispit itd. To su primeri logičkih i realnih veza između objekata, koje slede iz realnih odnosa u posmat-ranom sistemu studiranja na jednom fakultetu. Istražimo jedan skup odnosa iz-među studenata koji slušaju predavanja kod određenog profesora. Postavlja se pitanje šta su u takvim odnosima objekti, koje su njihove osobine (atributi) i kako prikazati njihove odnose.

Modelovanje 43

Identifi kovati objekte, njihove osobine i odnose znači praktično izgraditi model podataka. U modelu podataka ne postoje samo atributi objekta, nego i veze između objekata. Prvo se selektuju objekti, imenuju se, a zatim se analizira-ju tipovi odnosa koji se uspostavljaju između objekata. Odnosi između objeka-ta posmatranja prikazuju se najčešće primenom logike skupova i preslikavanja njihovih elemenata.

Najjednostavniji odnos između ta dva tipa objekata naziva se preslikavanje 1:1. Kod takvog preslikavanja svaki se element skupa X može preslikati na najviše jedan element skupa Y. Istovremeno, i svaki element skupa Y može biti preslikan na najviše jedan element skupa X. Karakterističan primer bi bio sa entitetima Fakultet i Dekan. Na jednom fakultetu može biti samo jedan dekan, a jedan de-kan može biti dekan na samo jednom fakultetu. Takvi odnosi između entiteta su retki, a mogu se predstaviti sledećom slikom:

Slika 7.2. – Preslikavanje entiteta 1:1

Druga vrsta odnosa naziva se preslikavanje N:1 (ili 1:N). Više elementa sku-pa X može se preslikati na najviše jedan element skupa Y. Istovremeno jedan ele-ment skupa Y može se preslikati na više elemenata skupa X. Pogodan primer za ovu vrstu odnosa između entiteta je odnos između entiteta Student i Dekan. Više studenata na jednom fakultetu ima samo jednog dekana, a jedan dekan je dekan za više studenata na svom fakultetu.

44 Modelovanje

Slika 7.3. – Preslikavanje entiteta N:1

Najsloženije preslikavanje je tipa M:N. Svaki element prvog skupa može se preslikati na više elemenata drugog skupa, ali se i svaki element drugog skupa može preslikati na više elemenata prvog skupa. Karakterističan primer ovakvih veza postoji ako se uoče entiteti Student i Profesor. Jednom studentu predaje više profesora, a ujedno jedan profesor predaje za više studenata.

Slika 7.4. – Preslikavanje tipa M:N

Modelovanje 45

7.4. Troslojna arhitektura baze podatakaOsnovni koncept baze podataka je ideja o skupu činjenica ili delova znan-

ja. Činjenice mogu da budu struktuirane na različite načine koji se nazivaju modeli podataka. Model podataka nije statična struktura nego se menja kako bi odražavao promene koje se dešavaju i u realnom sistemu. Na primeru informa-cionog sistema jednog fakulteta, studenti polažu pojedine ispite, neke poništa-vaju i dobijaju drugačije ocene, upisuju se novi studenti, drugi diplomiraju, neki asistenti postaju profesori itd.

Za jednostavne slučajeve, kao i mali broj promena relacija i entiteta, moguće je ažuriranje podataka vršiti ručno. Za kompleksnije sisteme (sa neko-liko stotina ili hiljada entiteta ili relacija) ažuriranje podataka postaje ogroman problem. Jedino se uz pomoć računara može održavati ažurnost podataka u velikim informacionim sistemima. Obrada podataka postaje ne samo pitan-je produktivnosti neke fi rme ili organizacije, nego i opstanka, rasta i razvoja u okruženju s intenzivnom konkurencijom. Obrada podataka je deo svakog poslovnog procesa, stoga je poznavanje baza podataka bitno ne samo za pro-jektante informacionih sistema i programere, nego i za krajnje korisnike rezul-tata takvih obrada. Oni nisu samo skup povremenih korisnika baza podataka, kao što se to može reći za programere ili projektante informacionih sistema. Danas veliki broj zaposlenih, koji nisu upoznati sa konceptualnom šemom BP, kreiraju, unose, ažuriraju ili jednostavno koriste baze podataka na različitim nivoima organiziranosti poslovnih sistema.

Model baze podataka koji je danas poznat kao ANSI/X3/SPARC model pri-kazan je na slici 7.5. Na bazi tog modela razvijeni su sistemi za upravljanje bazama podataka koji imaju troslojnu arhitekturu ili varijantu te arhitekture. Aplikativni programi komuniciraju s bazom podataka preko odgovarajućeg eksternog mode-la. Zahtev za učitavanje određenih podataka aplikativni sloj upućuje na eksterni sloj, odnosno odgovarajući korisnički model. DBMS preslikava eksterni model na konceptualni i konceptualni na interni model.

Konceptualni nivo je najbliži stvarnosti. Taj se nivo defi niše u procesu krei-ranja modela podataka. Jedan od ciljeva modela podataka je oblikovanje podata-ka za sadašnje i buduće aplikacije. Može se reći da konceptualni nivo čine sve rela-cione šeme modela podataka, sve relacije i ograničenja. Spoljašnji nivoi (modeli A,

46 Modelovanje

B i C) formiraju se na temelju konceptualnog nivoa i predstavljaju samo pogled (VIEW) prema potrebama pojedinih korisnika.

Slika 7.5. – Troslojna arhitektura baze podataka

Unutrašnji (interni) sloj baze odnosi se na zapisivanje konceptualnog sloja na nekom medijumu za čuvanje (najčešće disku). Radi se o slogovima zapisanim u datotekama. Niži sloj, uslovno rečeno, ili nivo bliži disku od internog sloja BP, je operativni sistem, koji na osnovu logičkih adresa slogova čita sadržaj diska.

Modeli baza podataka 47


Modeli baza podataka

Za modelovanje strukture podataka koriste se različite tehnike. Određeni modeli se lakše koriste za neke tipove sistema upravljanja bazama podataka nego drugi modeli. Model čini osnovu za osmišljavanje, defi nisanje i implementaciju baze podataka.

Istorijski gledano sistemi za upravljanje bazama podataka mogu se podeliti u sledeće osnovne modele:

• Hijerarhijski model – čine ga podaci složeni u hijerarhijsku strukturu;• Mrežni model – može se predstaviti usmerenim grafom u kojem su čvo-

rišta podaci, a lukovi među čvorištima defi nišu veze među podacima;• Relacioni model – zasnovan na matematičkom pojmu relacije. Podaci i

veze među podacima se prikazuju preko dvodimenzionalnih tabela.• Objektni model – bazira se na konceptu objekata, koji predstavljaju skup

podataka i operacija koje se na njima mogu izvršavati.

8.1. Hijerarhijski modelHijerarhijski model je najstariji od svih modela baza podataka, i za razliku

od mrežnog, relacionog ili objektno orjentisanog, nema dobro dokumentovanu istoriju svoje koncepcije i početne verzije ovakvog modela. Ovaj model se razvio iz informacionog sistema za upravljanje u 50-tim i 60-tim godinama prošlog veka. Usvojen je u mnogim bankama i osiguravajućim društvima koji ga, kao nasleđe, i danas koriste.

48 Modeli baza podataka

U hijerarhijskom modelu podaci su smešteni u seriju slogova (zapisa) Da bi se uspostavila veza između slogova, hijerarhijski model uspostavlja relaciju roditelj – naslednik. Ovo je takozvano 1:N mapiranje između slogova koje se radi korišćenjem stabla. U ovom modelu, relacije su takve da jedan nasled-nik može imati samo jednog roditelja, ali roditelj može imati više naslednika. Roditelji i naslednici su povezani vezama koje se nazivaju pokazivači (u fi zičkoj realizaciji to je adresa u memoriji gde se slog nalazi). Roditelj ima listu poka-zivača za svakog od svojih naslednika. Hijerarhijski model je dobro uređena struktura, koja podseća na hijerarhijsku strukturu u npr. državi, vojsci ili nekoj velikoj organizaciji.

Slika 8.1. – Šematski prikaz jednog hijerarhijskog modela

Pravilo roditelj – naslednik omogućava pristup podacima. Da bi se došlo do tabele na nižem nivou, kreće se od korena i ide prema dole kroz stablo dok se ne dođe do cilja. Naravno, očigledan problem sa ovim modelom je da korisnik mora da zna kako je stablo organizovano da bi pronašao bilo šta.

Hijerarhijski model ima ozbiljnih nedostataka. Na primer, ne može se doda-ti slog u tabelu naslednika dok se ne uključi u roditeljsku tabelu. Hijerarhijski model je sposoban da radi jedino sa jednostrukim stablima, ali ne može da se nosi sa povezivanjem ogranaka ili stvaranjem višestrukih veza. Zbog toga se stvara redudansa (višestruko pojavljivanje) podataka i mogućnost netačnog ažuriranja. Na primeru hijerarhijske organizacije nekog fakulteta koji ima katedre, profesore, studente itd. mogu se lako uočiti navedene slabosti. Lako je predstaviti da na jed-noj katedri ima više profesora, ali se ne može predstaviti da jedan profesor radi na više katedri. Da bi se ovo uradilo, mora postojati dva pojavljivanja istog profesora. To može dovesti do netačnosti kod ažuriranja podataka, npr. moguće je da infor-macije budu različite u dva zapisa, što vodi do konfuzije.


Hijerarhijski model se više ne koristi kao osnova za trenutne komercijal-ne sisteme, ali još uvek postoji mnogo nasleđenih sistema baziranih na ovom modelu. Zbog svih nedostataka koji postoje u hijerarhijskom modelu, razvijen je mrežni model.

8.2. Mrežni modelMrežni model je prvi put predstavljen 1971. godine. Može se smatrati sav-

remenikom relacionog modela, gledajući starost i prva istraživanja učinjena u 60-tim godinama prošlog veka. Omogućava da se višestruki skupovi podataka koriste zajedno putem pokazivača (ili pointera). Neke kolone sadrže pokazivače na druge tabele umesto samih podataka. Na taj način, tabele su povezane pokazi-vačima i mogu se posmatrati kao mrežna struktura. Dok u hijerarhijskom modelu svaki slog ima jedan „roditeljski“ slog i neograničeno „naslednika“, mrežni model omogućava svakom zapisu da ima višestruke roditelje i naslednike, kreirajući mrežastu strukturu.

Slika 8.2. – Šema mrežnog modela

Mrežni model se danas uglavnom ne upotrebljava za dizajniranje baza podataka, ali ipak ima slučajeva gde se kao deo nasleđa koristi u nekim kom-panijama. Predstavlja unapređenje hijerarhijskog modela, ali je kompleksan i težak za upotrebu. Pored toga, teško ga je podržati matematičkim aparatom, što onemogućava kasnije efi kasno programiranje.


8.3. Relacioni modelKao i mnoge druge tehnologije u računarskoj industriji, koreni relacionih

baza podataka potiču iz IBM-a i njihovog istraživanja automatizovanja kancela-rijskih operacija u 60-tim i 70-tim godinama XX veka. 1970. godine, IBM-ov istraživač Ted Codd je prezentovao prvi rad o relacionim bazama podataka. Zbog same tehničke prirode rada i oslanjanja na matematički aparat, njegova važnost nije odmah shvaćena. Ipak, doveo je do formiranja IBM-ove istraživačke gru-pe System R. Od projekta System R se očekivalo da stvori sistem relacione baze podataka koji bi mogao postati proizvod. Prvi prototip prezentovan je 1974/75. godine i eksperimentalno je korišćen. Nakon što je defi nisan relacioni model, napravljeni su neformalni modeli da bi se opisali hijerarhijski i mrežni model. Hijerarhijske i mrežne baze podataka su postojale pre relacionih baza podata-ka, ali su kao modeli opisani tek nakon što je relacioni model defi nisan, da bi se napravila osnova za poređenje.

U srcu relacionog modela nalazi se koncept tabele (koja se naziva i relacija) u kojoj su smešteni svi podaci. Svaka tabela je načinjena od slogova (redova u tabeli), a svaki slog ima svoja polja (atribute). Osnovne karakteristike relacionog modela podataka su sledeće:

• Sve se predstavlja relacijama (tabelama)• Zasniva se na strogoj matematičkoj teoriji• Minimalna redudansa podataka• Jednostavno ažuriranje podataka• Izbegnute su anomalije ažuriranja• Redosled kolona i redova ne utiče na informacioni sadržaj tabele• Ne mogu da egzistiraju dva identična reda (rekorda) u jednoj tabeli• Svaki red se može jednoznačno odrediti (postoji primarni ključ)• ...

U relacionom modelu podataka klase objekata se predstavljaju tabelama. Na primer klasa STUDENT se može opisati atributima BROJ INDEKSA i IME i klasa KNJIGA sa atributima ŠIFRA KNJIGE i NAZIV. Trenutno stanje studenata i knjiga koje je uneseno u ove tabele može biti sledeće:


Slika 8.3. – Tabela kao osnovni objekat relacione baze podataka

Prethodna dva objekta sa svojim atributima grafi čki se mogu predstaviti na sledeći način:

Slika 8.4. – Grafi čki prikaz objekata i njihovih atributa

U realnom svetu objekti međusobno stupaju u veze. Na jednom fakultetu studenti drže (pozajmljuju iz biblioteke) pojedine knjige. Može se uočiti da je veza između ova dva posmatrana objekta tipa M:N, tj. više studenata mogu da drže jed-nu knjigu, a jedna knjiga može biti kod više studenata. Neka je trenutna situacija iz realnog sveta prikazana na sledećoj slici:


Slika 8.5. – Veze između objekata realnog sveta – formira se klasa veza

Klasa veza se može posmatrati kao zaseban entitet, a taj entitet može da ima svoje posebne atribute. U našem primeru, klasa veza DRŽI može da ima kao atribut DATUM od kada student drži određenu knjigu. Neka je trenutna situacija iz realnog sveta prikazana sledećom slikom

Slika 8.6. – Klasa veza može da ima svoje atribute

Grafi čki prikaz navedenog dat je na sledećoj slici

Slika 8.7. – Klasa veza može da ima svoje atribute


Suština relacionog modela je da se i klase objekata i klase veza između objekata predstavljaju na jedinstven način, tj. preko tabela. U našem primeru postoje tri tabele: STUDENT, KNJIGA i DRŽI. U relacionom modelu podataka tabela se defi niše kao relacija, koja mora da ispuni odgovarajuće uslove. Svaka relacija mora da ima primarni ključ – jedan ili više atributa koji na jedinstven način opisuju svaki zapis u jednoj tabeli. Primarni ključ se pažljivo bira. Na primer u klasi studenata loš izbor primarnog ključa bi bio atribut IME, zato što se mogu pojaviti dva studenta sa istim imenom. Dobar izbor primarnog ključa je atribut Broj indeksa, zato što ne postoje dva studenta sa istim brojem indeksa. Za klase objekata Student i Knjiga vrši se prevođenje u relacioni model na sledeći način (podvlačenjem su označeni atributi koji čine primarni ključ):

STUDENT (BrInd, Ime),KNJIGA (SifK, Naziv)

Za klasu veza Drži, može se difi nisati prirodan primarni ključ u odnosu na objekte koje povezuje. U našem primeru relacija Drži bi glasila:

DRŽI(BrInd, SifK, Datum)

Dakle, za posmatrani realan slučaj gde studenti drže pojedine knjige, izvrše-no je modelovanje preko tri tabele tj. relacije. Tabele STUDENT i KNJIGA imaju dve kolone, a tabela DRŽI tri kolone. Sve tabele su povezane. Povezivanje se vrši preko vrednosti atributa u relacijama. na sledeći način:

Slika 8.8. – Relacije se povezuju vrednostima spoljnih i primarnih ključeva

Veoma je važno zapaziti da kako i gde su tabele smeštene ne pravi nikak-vu razliku. Svaka tabela se identifi kuje jedinstvenim imenom koje baza podataka koristi da bi pronašla tabelu. Korisniku je potrebno samo da zna ime tabele. Nema


potrebe da se vodi računa o tome kako su podaci smešteni na disku. Ovo je razli-čito od hijerarhijskog i mrežnog modela u kojima korisnik mora da razume kako su podaci struktuirani unutar baze podataka da bi mogao da ih pretražuje, unosi nove, ažurira ili briše postojeće slogove.

Relaciona baza podataka standardno se sastoji iz više tabela. Ipak, za razliku od mrežne baze podataka, tabele nisu povezane pokazivačima. Umes-to toga koriste se „ključevi“ da upare redove podataka u različitim tabelama. Ključ je samo još jedna ili više kolona u tabeli, koja odgovara kolonama u drugim tabelama.

Zahtev za podatkom iz relacione baze podataka se dobija izvršavanjem upita koji je napisan u posebnom jeziku, obično nekom od dijalekata SQL-a. Iako je SQL originalno namenjen za krajnje korisnike, mnogo češće se SQL upiti ugrađuju u soft ver koji omogućava lakši korisnički interfejs. Kao odgovor na upit, baza podataka vraća skup podataka, koji je u stvari lista redova koji sadrže odgovor. Najjednostavniji upit je da se dobiju svi redovi iz tabele, ali češće, redo-vi se fi ltriraju na neki način da bi se dobio traženi odgovor. Često se podaci iz više tabela kombinuju u jednu, procesom udruživanja.

Fleksibilnost relacionih baza podataka dozvoljava programerima da pišu upite koji nisu bili predviđeni od strane dizajnera baze podataka. Kao rezul-tat, relacione baze podataka mogu da se koriste u više aplikacija koje originalni dizajneri nisu predvideli, što je posebno važno za baze podataka koje se mogu koristiti decenijama. Ovo je model relacionih baza podataka učinilo veoma popu-larnim u poslovnoj primeni.

8.4. Objektni modelObjektno orjentisani model je jedan od novijih modela baza podataka.

Istraživači su za njega postali zainteresovani krajem 70-tih i početkom 80-tih godina prošlog veka, kada se koncept objektno orjentisanih sistema počeo pojavl-jivati. Bazira se na konceptu objekata, koji predstavljaju skup podataka i operacija koje se na njima mogu izvršavati.

Istraživanje se radilo i da bi se prevazišla mnoga ograničenja u relacio-nom modelu na određenim tipovima podataka. Tipovi podataka koji se mogu


koristiti u relacionim bazama su veoma ograničeni. Svaki atribut (polje) može da poprimi samo jednu vrednost. U objektno orijentisanom modelu podataka entitet se predstavlja klasom. Klasa obuhvata i atribute i ponašanje entiteta (moguće operacije nad podacima). Npr. Klasa: student

• Atributi: BrInd, Ime, Prezime, Fakultet

• Procedura: polaganje Ispita()

Objekti su samo jedno pojavljivanje u odgovarajućoj klasi. Objektno orijen-tisan model karakteriše bogatstvo tipova podataka – tip može biti i drugi objekat. Direktna veza između objekata u aplikaciji i objekata u BP rezultuje boljim per-formansama baze podataka.

Posmatrajmo primer u kome se vodi evidencija o Studentima sa svojst-vima: Broj indeksa, Ime, Prezime, Fakultet i Tip automobila koji student pose-duje. Dalje vodi se evidencija o Automobilima sa svojstvima Naziv automobila, Registarski broj, Boja, Godište i Vlasnik. Prethodni primer se može prikazati na sledeći način

Slika 8.9. – U objektno orijentisanim BP tip podatka može biti drugi objekat

Objektno orjentisani DBMS-ovi omogućavaju čuvanje objekata direktno, bez mapiranja za različite strukture podataka. Relacioni DBMS zahteva mapiranje iz objekata u tabele. U objektno orijentisanom modelu, informacija je sačuvana


kao stalni objekt, a ne kao red u tabeli. Ovo sistem čini efi kasnijim u smislu pro-stora potrebnog za smeštanje i čuvanje podataka i osigurava da korisnik manipu-liše podacima samo na onaj način koji je programer odredio.

S druge strane, obzirom da se kontrola vrši na veoma niskom nivou, mnogo je teže za treću stranu da napravi neki dodatak. Dok kod relacionih baza podataka možemo imati korist od soft vera izrađenog od strane trećeg dobavljača, korisni-ci objektno orjentisanih sistema za upravljanje bazama podataka ili moraju da naruče dodatni soft ver od originalnog programera ili da ga razviju u saradnji sa drugim fi rmama koje koriste isti sistem.

Strukturna sistemska analiza (SSA) 57


Strukturna sistemska analiza (SSA)

Strukturna sistemska analiza (SSA) predstavlja savremen pristup procesu razvoja poslovnih informacionih sistema. Analiza tokova podataka u sistemu, određivanje ključnih entiteta u sistemu i njihovih atributa i entiteta van sistema s kojima on komunicira predstavlja samo najvažnije u nizu zadataka SSA. Osnovne karakteristike SSA su:

• Razvijanje sistema se vrši od vrha-na dole;• Analiza i dizajn podrazumevaju korišćenje različitih alata, tehnika i

modela u cilju što preciznijeg snimanja aktuelnog sistema i korisničkih zahteva;

• Osnovni alati SSA su: funkcionalni dijagrami, dijagrami tokova podata-ka, rečnici podataka, specifi kacija procesa, dijagrami objekti-veze;

• Razdvajanje fi zičkog i logičkog modela - fi zički model je najčešće foku-siran na preživljavanje postojećeg sistema ili dizajn novog, dok je logički model više usmeren na analizu zahteva kojima sistem treba da odgovori;

• Uključivanje korisničkih uloga u različitim fazama razvoja;• SSA omogućava istovremeno izvršavanje pojedinih faza analize i dizajna;• SSA je podržana naprednim tehnologijama, što olakšava razvoj sistema;SSA predstavlja ključni proces u projektu razvoja poslovnih informacionih

sistema. Sistemska analiza je preduslov dobrog dizajna informacionog sistema i uključuje tehnike analize informacionog sistema, modelovanja podataka i tehnike normalizacije dobijenog modela.

U metodologiji 70-ih godina preovlađujući pristup je bio waterfall pristup koji se sastojao od 5 sekvencijalnih faza (odvijale su se jedna za drugom po tačno utvrđenom redosledu):

• Sistemska analiza;

58 Strukturna sistemska analiza (SSA)

• Sistemski dizajn;• Izgradnja i testiranje sistema;• Uvođenje i tranzicija sistema;• Održavanje produktivnosti sistema.Model vodopada (Slika 9.1) zamenio je spiralni model, koji se zasniva na

iterativnosti procesa razvoja informacionih sistema (Slika 9.2). Prednost ovakve metodologije je u tome što se sistem brzo uvodi u korišćenje (postizanjem samo osnovnih funkcionalnosti), a zatim se dograđuje i prilagođava potrebama kon-kretnih korisnika. Na taj način proces razvoja nije završen kada se informacioni sistem uvede u upotrebu, već se nastavlja dodavanjem novih soft verskih modula, osavremenjavanjem postojećih funkcionalnosti. To znači da razvoj sistema traje dok se sistem koristi (dok je živ).

Slika 9.1. – Waterfall metodologija

Razvoj poslovnih sistema predstavlja cikličan (iterativno inkrementalan) proces, koji se odvija po fazama. Zbog svoje stadijumske prirode, celokupan pro-ces se često naziva životni ciklus razvoja sistema (Slika 9.2).

U obe predstavljene metodologije SSA ima značajno mesto i predstavlja preduslov procesu dizajna sistema. Metodologija životnog ciklusa mnogo fl eksi-bilnije uključuje SSA u proces razvoja poslovno informacionog sistema.


Slika 9.2. – Faze životnog ciklusa razvoja sistema

SSA se realizuje po fazama, i dobro defi nisanoj metodologiji. Suštinski, sis-tem se analizira na različite načine. To može biti sa akcentom na:

• poslovne funkcije (funkcionalna dekompozicija), • tokove podataka (dekompozicija dijagrama tokova podataka), • defi nisanje rečnika podataka.• defi nisanje veza između entiteta u sistemu (izrada dijagrama objekti

veze),


9.1. Funkcionalna dekompozicijaDijagrami funkcionalne dekompozicije se koriste u određivanju osnovnih

sistemskih funkcija i njihovom dekomponovanju. Ove funkcije obično odgovara-ju u potpunosti predstavljenim procesima u dijagramima tokova podataka.

9.1.1. Jacksonovi dijagramiDijagrami funkcionalne dekompozicije se još nazivaju, prema svom tvorcu,

Jackson-ovim dijagramima (Primer na slici 9.3).

Slika 9.3. – Jackson-ov dijagram osnovnih poslovnih funkcija

Funkcionalni dijagram najvišeg nivoa predstavlja osnovne poslovne funk-cije organizacije. Na prethodnoj slici predstavljen je dijagram osnovnih poslovnih funkcija jedne spoljno-trgovinske organizacije. U vrhu dijagrama obavezno se predstavlja naziv IS koji se analizira. Slično hijerarhijskim organizacionim dija-gramima predstavljaju se osnovne funkcije preduzeća. Ove funkcije su selektivne, što znači da se odvijaju bez uzajamnih zavisnosti.

9.1.2. Pravila u kreiranju Jacksonovih dijagramaOsnovne funkcije najčešće imaju selektivnu prirodu tako da se dekompo-

nuju. Završetak funkcionalne dekompozicije je kada se dobiju elementarne sek-vencijalne funkcije (primitive). Primitivne funkcije su one koje se dalje mogu samo dekomponovati na konkretne naredbe u ciljnom programskom jeziku, ili u pseudo kodu. Na slici 9.4 predstavljen je primer dekomponovanja poslovne funk-cije prodaja. Pošto se razlikuje proces veleprodaje (rad sa pravnim licima, ugo-varanje, veleprodajne cene, rabat, naručivanje, dostavljanje, transakcije isključivo preko žiro-računa u bankama) od maloprodaje (rad sa fi zičkim licima, gotovinsko


plaćanje, manje količine robe, plaćanje na prodajnom mestu), tako je osnovna prodaja funkcija dekomponovana na navedene dve.

Slika 9.4. – Dekompozicija poslovne funkcije Prodaja

Praćenje dekompozicije je olakšano numeracijom funkcija. Tako se npr. funkcija maloprodaja (3.2) dekomponuje na dve manje funkcije: generisanje raču-na kupcu (3.2.1) i prijem uplate kupca (3.2.2). Može se uočiti da su funkcije gene-risanje računa i prijem uplate – sekvencijalne; kupac ne plaća robu dok ne dobije račun od prodavca. Tu je kraj dekomponovanja funkcije maloprodaja, sledi opis logike primitivne funkcije pseudo kodom.

Selektivni procesi na dijagramima funkcionalne dekompozicije označavaju se znacima <>, dok se sekvencijalni procesi označavaju znacima [].

Funkcionalni dijagrami se ne bave podacima koji postoje u sistemu, već samo treba da istaknu frekventnost (važnost) i kompleksnost pojedinačnih poslov-nih funkcija. Kroz funkcionalnu dekompoziciju mogu se identifi kovati sličnosti u dekompoziciji različitih poslovnih funkcija. Kao posledica ove činjenice mogu se identifi kovati nove funkcije, i već u fazi analize učiniti koraci koji će omogućiti optimizaciju rešenja IS.


Slika 9.5. – Primer identifi kovanja istih funkcija u funk.dekompoziciji

Na primer (Slika 9.5), organizacije (trgovine) koje se bave prodajom robus-ne robe (nameštaj, vozila, industrijske mašine) koriste istu funkciju otprema u dekompoziciji veleprodaje i maloprodaje. Roba se i u jednom i u drugom slučaju mora dostaviti kupcu. Na taj način, funkcija otprema se dizajnira i implementira umesto 2 puta – samo jedanput i ona treba da bude dostupna iz obe opcije (nad-funkcije) aplikacije (veleprodaje i maloprodaje).

Funkcionalna analiza uz pomoć alata za modelovanje obezbeđuje važne detalje koji se mogu koristiti u kasnijim fazama analize. Međutim, funkcionalni pristup nije sveobuhvatan – bavi se pitanjem šta sistem radi, ne i kako radi.

9.2. Dijagrami tokova podataka (DTP)Dijagrami tokova podataka (DTP) predstavljaju jednu od najpopularnijih

tehnika modelovanja poslovnih procesa [2]. DTP opisuju protok informacija u sistemu. Oni predstavljaju prirodan nastavak razvoja IS nakon funkcionalne ana-lize. DTP se sastoje od četiri vrste elemenata (Slika 9.6):

• Interfejsi• Procesi• Tokovi podataka • Skladišta podataka


Slika 9.6. – Struktura DTP

Interfejsi predstavljaju entitete (objekte) iz realnog sveta koji okružuje sis-tem. To mogu biti osobe koje se nalaze u određenoj ulozi u odnosu na sistem (npr. pacijent, nastavnik, student, kupac, dobavljač...), organizacije (banka, hotel, škola, carina...) ili sistem koji nudi neki servis za posmatrani IS (SMS servis, e-banking servis, čitač smart kartica, tržište nekretnina...). Interfejsi se prikazuju pravougao-nikom i nazivom (Slika 9.7).

Slika 9.7. – Primeri interfejsa

Zajedničko za sve interfejse je da su to objekti izvan analiziranog sistema, koji interaguju (razmenjuju podatke) sa sistemom. Kao što se može videti iz prethodnog primera, interfejsi nisu konkretna fi zička lica, niti konkretne organizacije; dobavljač može biti bilo koje fi zičko, ili pravno lice. Isti je slučaj sa vlasnikom nekretnine. Iz-davač oglasa može biti bilo koja izdavačka, ili novinarska kuća. Bitna je uloga koju interfejs obavlja, odnosno način na koji sistem komunicira s interfejsom. U toku dekomponovanja DTP, interfejsi moraju ostati konzistentni – oni se ne menjaju, niti dekomponuju. Drugim rečima, broj i nazivi interfejsa na početku dekompozicije mora da odgovara broju i nazivima interfejsa na kraju tog procesa.


U toku procesa dekomponovanja, radi preglednosti dijagrama, jedan inter-fejs se može ponoviti na istom dijagramu, s tim da je kopija označena zvezdicom (Slika 9.8).

Slika 9.8. – Original i kopija interfejsa

Procesi odgovaraju funkcijama iz prethodne faze SSA (funkcionalna dekompozicija). Interfejsi interaguju sa sistemom posredstvom procesa. Svaki proces predstavlja neku specifi čnu poslovnu aktivnost. Proces može predstavlja neku automatsku obradu podataka (generisanje izveštaja, računa, autentifi kacija korisnika...), ali isto tako neku manuelnu aktivnost (nabavka, isporuka, proiz-vodnja, učlanjivanje, izdavanje knjige...).

Slika 9.9. – Primer označavanja procesa

Procesi se označavaju krugom ili elipsom u koji se unosi naziv procesa (Slika 9.9). Za razliku od interfejsa, procesi se numerišu. Brojčano označavanje je iden-tično kao kod funkcionalnih dijagrama. Nije dozvoljeno praviti kopije procesa na istom DTP. Procesi se mogu dekomponovati. Suštinski, dekompozicija DTP se svodi na dekomponovanje poslovnih procesa. Na sledećem primeru (Slika 9.10) istaknut je primer dekomponovanja procesa nabavka. Na nultom nivou dekom-ponovanja predstavljeni su osnovni poslovni procesi. Ovi procesi se dekomponu-ju od 1. nivoa dekompozicije. Proces nabavka se dekomponuje na 3 podprocesa: obrada kataloga dobavljača, naručivanje i prijem robe. To znači da se osnovni pro-ces nabavka više ne pojavljuje od 1. nivoa dekompozicije, već samo njegovi pod-procesi. Na drugom nivou demonstrirana je dekompozicija podprocesa prijem


robe. Ovaj podproces se dekomponuje na tri nova, koja opisuju šta sistem radi po prijemu robe. To znači da se prijem robe od 2. nivoa više ne pojavljuje kao celovit proces, već njegovi podprocesi.

Slika 9.10. – Primer dekompozicije poslovnih procesa

Nije precizirano do kog nivoa se vrši dekomponovanje poslovnih proce-sa. Ne sme se zaboraviti da DTP treba da u potpunosti odgovaraju dijagramima funkcionalne dekompozicije. Analogno funkcionalnoj dekompoziciji, poslovni procesi se dekomponuju do nivoa pre dobijanja elementarnih sekvencijalnih pro-cesa. Gornji primer predstavlja završenu dekompoziciju podprocesa prijem robe procesa nabavke. Ako bi se nastavilo sa dekomponovanjem bilo kog od procesa označenih 1.3.1 do 1.3.3., dobili bi se potpuno sekvencijalni podprocesi koji se izvršavaju po unapred utvrđenom redosledu, što je više stvar implementacionih detalja, nego aktivnosti analize.

Tokovi podataka (TP) predstavljaju interakciju između interfejsa i procesa u sistemu. Oni obavezno moraju biti imenovani (Slika 9.11). TP imaju statičku prirodu, jer ne odslikavaju redosled izmene podataka između sistema i okoline, niti redosled akcija koje izazivaju unutar sistema. TP mogu sadržati osnovne tipo-ve – celi brojevi, realni brojevi, karakteri i izvedene tipove - struktuirane podat-ke, kao što su adresa, narudžbenica, katalog proizvoda (sadrže podatke različitih osnovnih tipova ili ugnježdene strukture). Važna karakteristika TP je njihova oba-vezna usmerenost, koja opisuje smer toka podataka u sistemu.


Slika 9.11. – Primer označavanja TP

Slika 9.12. – Primer tokova podataka na fragmentu DTP za IS biblioteke

I unutar sistema postoje TP (Slika 9.12): između procesa i skladišta podata-ka i između procesa uzajamno. Ti tzv. interni tokovi podataka nisu imenovani,


jer se podrazumeva da je njihova struktura defi nisana kroz spoljnje tokove (sis-tem - interfejs).

Namena internih TP između procesa i skladišta je da istaknu da li se i gde ulazni podaci pamte u sistemu, odnosno iz kojih izvora (skladišta) se generišu izlazni podaci prema interfejsima.

TP između procesa u sistemu odslikavaju njihovu uzajamnu povezanost. Nije preporučljivo da se ovakvi TP pojavljuju u DTP 0. nivoa. Oni se pojavljuju kao proizvod dekomponovanja osnovnih procesa, nisu imenovani i samo tre-ba da predstave podprocese koji se koriste od više drugih podprocesa na istom nivou dekompozicije (odgovaraju procesima u stereotipskoj uses vezi u dijagra-mima slučajeva korišćenja UML).

U dekomponovanju DTP, tokovi podataka moraju biti konzistentni poče-vši od kontekstualnih dijagrama do najkonkretnijih DTP. Konvencija je da se ne smeju pojaviti novi TP u procesu dekompozicije. Ako je to nužno, potrebno je ažurirati dijagrame na višim nivoima opštosti.

Skladišta podataka predstavljaju elemente sistema u kojima se poda-ci čuvaju (Slika 9.13). Skladište podataka ne predstavlja bazu podataka, niti tabelu u bazi. U ovoj fazi analize sistema skladišta samo treba da istaknu grupisanje podataka.

Slika 9.13. – Primer skladišta podataka

Za razliku od interfejsa, simbol skladišta podataka je pravougaonik koji nema bočne stranice. Imena skladišta su obično množine imenica – entiteta koji grupišu srodne podatke. Na primer, skladište STUDENTI može da obuhvata ne samo osnovne podatke studenata (ime i prezime, jmbg, broj indeksa...), već i detaljnije podatke (godina studija, rezultati ispita, smer-nastavna grupa...).Često se nazivima skladišta dodaje prefi ks SK koji još više ističe razliku u odnosu na interfejse. Isticanje razlike između skladišta i interfejsa nije neopravdano: na prethodnom primeru (Slika 9.12) postoji interfejs CITALAC i skladište CITAO-CI. U praksi je čest slučaj da interfejsi i skladišta imaju slične nazive, tako da je poželjno svako nastojanje isticanja razlike na dijagramima (naravno, u okvirima konvencije označavanja).


9.2.1. Kontekstualni dijagramiModelovanje poslovnih procesa započinje kontekstualnim dijagramom.

Kontekstualni dijagram je takav dijagram tokova podataka na kome je celokupan sistem prikazan kao jedan proces - crna kutija (Slika 9.14).

Slika 9.14. – Primer dijagrama konteksta


Težišni zadatak kontekstualnog dijagrama je defi nisanje svih interfejsa sa kojima sistem komunicira, kao i tokova podataka koji čine tu komunikaci-ju. U početku je najčešće nemoguće defi nisati sve interfejse i tokove podataka. Inicijalni sadržaj kontekstualnog dijagrama treba da obuhvati osnovne tokove i spoljnje entitete. U kasnijim fazama dekompozicije DTP je moguće naknadno dodati nove interfejse i tokove podataka, s napomenom da mora biti zadržana konzistentnost dekomponovanih DTP u odnosu na kontekstualni dijagram – svi interfejsi i tokovi podataka koji se koriste u dekomponovanju, moraju biti na dijagramu konteksta.

Na prethodnom primeru (Slika 9.14) prikazan je kompletan kontekstu-alan dijagram za informacioni sistem biblioteke. Može se uočiti da posto-ji mali broj interfejsa i veliki broj tokova podataka. Najčešće greške u ovoj fazi dekomponovanja je dodavanje interfejsa koji predstavljaju deo sistema, a ne spoljnji objekat s kojim sistem komunicira. Ovaj kontekstualni dijagram sadrži interfejs bibliotekar koji se naizgled može razmatrati kao deo sistema. Obično zabuna dolazi zbog toga što su entiteti kao bibliotekar zaista deo stvarnog sistema. Međutim, bibliotekara nikako ne možemo smatrati delom informacionog sistema biblioteke, već ga razmatramo kao spoljnji objekat koji, na primer zahteva da se prijavi prilikom počinjanja korišćenja IS, odnos-no odjavi prilikom završetka korišćenja sistema. Bibliotekar nije subjekat koji vrši registrovanje novih članova i koji izdaje knjige na korišćenje članovima – te aktivnosti su odgovornost sistema.

9.2.2. Dijagram toka podataka 0. nivoaNakon kreiranja kontekstualnog dijagrama sledi njegova dekompozicija

kroz dijagrame tokova podataka (Slika 9.15). Težište DTP 0. nivoa je identifi -kacija osnovnih poslovnih procesa koji se dešavaju u sistemu i distribuiranje TP između interfejsa i procesa. Pri kreiranju DTP 0. nivoa treba imati u vidu 3 važne činjenice:

• Moraju biti prikazani svi TP koji će se pojavljivati na detaljnijim DTP koji su proizvodi dekomponovanja (DTP 1, 2 nivoa),

• Moraju biti prikazani svi interfejsi koji će se pojavljivati na detaljni-jim DTP i

• Ne moraju biti prikazana sva skladišta i poslovni procesi, jer se mogu dekomponovati


Problem su dakle tokovi podataka, jer u slučaju velikog broja DTP 0. nivoa postaje vrlo nepregledan. To je indikator da je sistem koji se modeluje metodama SSA - preglomazan. U tom slučaju rešenje je da se informacioni sistem u samom početku deli na više komponenti – nezavisnih soft verskih modula. Tako će, na primer IS velikog međunarodnog hotelskog sistema biti podeljen na IS za rezer-vacije, IS održavanja i nabavke, IS vođenja kadrovskog sektora, IS za održavanje bezbednosti. Tek onda je moguća SSA takvih sistema (kroz modelovanje pojedi-načnih komponenti).

Slika 9.15. – Primer DTP 0. nivoa za IS medicinske klinike

9.2.3. Kompletan primer dekompozicije kroz DTPU ovom poglavlju biće opisana dekompozicija DTP jednog spoljnotrgovin-

skog preduzeća. Započinje se kontekstualnim dijagramom. Kontekstualni dija-gram predstavlja sistem kao crnu kutiju koja interaguje sa okruženjem (interfej-sima) posredstvom tokova podataka (Slika 9.16).


Slika 9.16. – Kontekstualni dijagram za IS spoljnotrgovinskog preduzeća

Težište modelovanja na kontekstualnom dijagramu je defi nisanje interfej-sa i tokova podataka. Postoje četiri osnovna entiteta s kojima preduzeće koje se bavi spoljnom trgovinom interaguje: dobavljač, kupac, carina i banka. Dobavljači i kupci mogu biti iz zemlje, ili inostranstva. Nabavci robe prethodi ugovaranje sa dobavljačem, kako bi se pravno zaštitile obe strane i kako bi nabavka iz inostran-stva u procesu carinjenja bila razmatrana kao legalna. Sama nabavka se odvija kroz dobro poznate TP: dobavljač dobija narudžbenicu (dokument za naručivan-je robe) na osnovu koje isporučuje robu uz fakturu (novčana vrednost narudžbe koji modelovano preduzeće mora da plati) i otpremnicu (dokument koji prati porudžbinu i na osnovu koga se vrši provera kompletnosti i ispravnosti pristigle robe; ovaj dokument se dalje može koristiti za regulisanje skladištenja robe).


U slučaju da roba pristigne iz inostranstva ona se najpre carini. Preduzeće koje uvozi robu podnosi carini zahtev za carinjenje. Takođe podnosi se dokument JCI (jedinstvena carinska isprava) koji predstavlja deklaraciju sa podacima o pore-klu, nameni, sastavu količini i vrednosti narudžbine koja se carini. Interfejs carina ispostavlja preduzeću fakturu za uplatu iznosa carine na uvezenu robu.

Nakon nabavke i carinjenja, roba se može prodavati. Procesi nabavke i pro-daje su veoma slični – samo je uloga preduzeća promenjena: prema dobavljačima, preduzeće je kupac, a prema kupcima ono prodaje robu. Pošto se preduzeće bavi veleprodajom, kupovina se ugovara kao i prilikom nabavke. Nakon ugovaranja kupovina započinje naručivanjem, zatim sledi isporuka robe uz fakturu i otpre-mnicu. Česta greška koja se javlja u ovom slučaju da su tokovi podataka prema dobavljačima i kupcima identično imenovani. Mora se naznačiti razlika, npr fak-tura_dob i faktura_kup. Ovo je neophodno jer, iako su strukture ovih dokumenata gotovo identične, modelovano preduzeće se nalazi u različitim ulogama u odnosu na svoje klijente (dobavljače i kupce).

U procesu modelovanja ne samo da treba uzeti stvarno stanje i funkcioni-sanje sistema. Poželjno je već u fazi SSA, omogućiti proširenje i poboljšanje kva-liteta delatnosti kojom se preduzeće bavi. TP nabavke i prodaje mogu biti pro-šireni u smislu povećanja kvaliteta usluga. Na primer TP – katalog_dobavljaca omogućava bolji kvalitet procesa nabavke. Ako postoje katalozi dobavljača koji sadrže ažurne podatke, IS može na osnovu zadatih kriterijuma dati predlog za najoptimalniju nabavku (npr. ukrštanje kriterijuma cena, isporuka, garancijski period, postgarancijsko održavanje...). Isti tako katalog prema kupcima će sigurno omogućiti kupcima da odaberu robu koja im najviše odgovara (najbolja reklama je preporuka kupca drugima).

U poslovanju fi zičkih i pravnih lica, sva plaćanja odvijaju se preko poslov-nih banaka. Tako da je ovaj interfejs gotovo nezaobilazan u modelovanju poslovnih sistema. Česta greška u modelovanju je da plaćanja i potraživanja postoje, ali se isključuje uloga banke, već se umesto nje pojavljuju konkretni potražioci (u našem slučaju to su dobavljači, carina, poreska uprava...). Banka predstavlja interfejs koji posreduje između strana koje učestvuju u novčanim transakcijama. Preduzeće u banci izmiruje sva novčana davanja preko TP uplata. Banka preduzeću dostavlja periodično, ili po promeni različite vrste izveštaja, koji mu omogućavaju upravljanje vlastitim novčanim sredstvima (izvod, priliv deviza, izveštaj o naplati).

Težište kod modelovanja DTP 0.nivoa (Slika 9.17) je na defi nisanju osnov-nih poslovnih procesa i pridruživanju tokova podataka tim procesima. Na ovom nivou dekomponovanja se pojavljuju i skladišta podataka, koja samo treba da istaknu grupisanje podataka. IS spoljnotrgovinskog preduzeća sadrži četiri osnov-na poslovna procesa: nabavka, carinjenje, prodaja i plaćanje.


Slika 9.17. – DTP 0. nivoa za IS spoljnotrgovinskog preduzeća

Proces nabavke obuhvata interakcije sistema sa dobavljačima, proces carinjenja – s carinom, proces prodaje obuhvata TP od i ka kupcima i proces plaćanje obuhvata interakcije prema banci. Mogu se uočiti skladišta čiji nazivi impliciraju koje vrste podataka sadrže. Proces carinjenja interaguje sa skladištem


dobavljači, koje je 2 put prikazano na istom dijagramu. Kopija je označena zvez-dicom, i na taj način su izbegnuta presecanja TP na dijagramu. Skladišta su sa procesima povezana internim, neimenovanim TP. Podrazumeva se da su ti tokovi u potpunosti opisani spoljnim TP (između procesa i interfejsa).

Zatim se vrši dekompozicija osnovnih poslovnih procesa. Proces nabav-ke se dekomponuje na 3 podprocesa (Slika 9.18): narucivanje, prijem_robe i skladistenje.

Slika 9.18. – DTP 1. nivoa za proces nabavke

Takođe, pojavila su se 3 nova skladišta, koja omogućavaju odvajanje osnovnih podataka dobavljača od tekućih podatka procesa nabavke. Svi tokovi podataka su zadržani i konzistentni sa TP na DTP 0. nivoa. Novina na ovom dij-agramu je direktna veza dva procesa (prijem robe i skladistenje). Proces skladis-tenje nema ni jednu direktnu vezu sa nekim spoljnim interfejsom, ali zato omo-gućava detaljnije snimanje procesa koji se odvijaju unutar sistema pri nabavci robe. Skladištenje na DTP ne znači fi zičko smeštanje robe u skladišni prostor, već njeno evidentiranje, označavanje i određivanje mesta gde će se roba čuvati. Na osnovu stanja zaliha IS može da odredi kada i koliko je robe potrebno za neometano poslovanje preduzeća.

Iz dijagrama se može uočiti da za predstavljanje TP nije obavezno koristiti isključivo krive ili izlomljene linije. Moguće ih je kombinovati, u cilju postizanja što bolje preglednosti i jasnoće dijagrama.


9.3. Rečnik podatakaNakon završetka dekomponovanja DTP, postoje svi potrebni uslovi za defi -

nisanje rečnika podataka. Rečnik podataka predstavlja skup podataka o podacima koji se koriste u analiziranom sistemu. To su generalizovani podaci, često u litera-turi zvani metapodacima (metadata). Rečnik podataka obuhvata tri celine:

• Opis struktura podataka koje se koriste u tokovima podataka,

• Opis polja defi nisanih nad podacima i

• Opis domena.

9.3.1. Defi nisanje strukturaPodaci koji se pojavljuju u interakcijama DTP između interfejsa i procesa

su najčešće struktuirani. Uzrok tome je činjenica da u sebi sadrže elementarne podatke različitih osnovnih tipova (tekstualne, celobrojne, realni brojevi), a koji su nerazdvojno vezani – izolovani nemaju nikakvo značenje. Na primer pojedina-čni podaci: smer, ocene položenih ispita nemaju konkretan informacioni značaj ako nisu objedinjeni u jedinstvenoj strukturi – student, kada dobijaju sasvim dru-gu semantiku – postaju podaci konkretnog studenta.

ISPITNA_PRIJAVA<<STUDENT>, <ISPIT>, <ISPITIVAC>, <PREDSEDNIK_ KOMISIJE>, BROJ_POKUSAJA>

ISPITNI_SPISAK<<ISPIT>, <ISPITIVAC>, <PREDSEDNIK_ KOMISIJE>, {<STUDENT>}>

REZULTATI_ISPITA< <ISPIT> ,{<JEDINACNI_REZULTAT>} >

ISPIT<DATUM_ISP, PREDMET >

JEDINACNI_REZULTAT<<STUDENT>,OCENA>


STUDENT<<OSOBA>,<INDEKS>>

OSOBA<IME,PREZIME,JMBG>INDEKS<GODINA_UPISA, PIN,DODATNO_OBELEZJE, <SEMESTAR>>

SEMESTAR<RBR_SEMESTRA,DATUM_UPISA>

PREDSEDNIK_ KOMISIJE<<ISPITIVAC>>

ISPITIVAC<<OSOBA>,NAUCNO_ZVANJE, NASTAVNO_ZVANJE, [ID_ZAPOSLENOG, BR_UGOVORA]>

Slika 9.19. – Primer defi nisanja struktura u rečniku podataka

Na prethodnom primeru (Slika 9.19) strukture su imenovane (boldira-ne), a njihov sadržaj predstavljen je uglastim zagradama < >. Može se uočiti da struktura u sebi sadrži drugu ugnježdenu strukturu. Na primer, Student je struktura koja se sastoji od 2 strukture: Osoba i Indeks. Strukture mogu sadrža-ti i nabrojive elemente (nabrajanja - enumerations). Tako na primer, struktu-ra Ispitni_spisak sadrži listu studenata, što je notirano korišćenjem vitičastih zagrada { }. Strukture mogu sadržati i opcione elemente. To su elementi koji se mogu alternativno koristiti. Na primer struktura Ispitivac sadrži dva opciona elementa – id_zapolsenog i broj_ugovora. Semantika ovih elementa je da ako je ispitivač stalno zaposlen u prosvetnoj ustanovi, onda on ima identifi kacioni broj. Ako isti nije stalno zaposlen, da bi bio u statusu ispitivača, mora da bude ovlašćen, što se reguliše ugovorom između u fakulteta i ispitivača. Notacija opcionih elemenata vrši se pravougaonim zagradama [].

Na primeru (Slika 9.19) predstavljen je završen rečnik podataka. Osnov-no načelo pri defi nisanju struktura je da svi podaci koji se vezano višestruko pojavljuju na više mesta u rečniku treba da se grupišu u imenovanu strukturu. Na taj način olakšava se modifi kacija sistema jer, ako izmenimo podatak u struktu-ri, ta promena će se odraziti na sve izvedene strukture koji tu strukturu koriste. Na primer ako se promeni način davanja broja indeksa na fakultetu, to ćemo


uraditi samo na jednom mestu – u strukturi indeks. Ta mala promena će se odraziti međutim na sve strukture koji u sebi sadrže indeks. Naizgled u gornjem primeru to je samo struktura Student. Ali promena je dakle i u strukturama koje koriste strukturu STUDENT: ISPITNA_PRIJAVA, ISPITNI_SPISAK, REZULTA-TI_ISPITA, JEDINACNI_REZULTAT !

Da broj indeksa nije defi nisan kao struktura, administrator podataka sis-tema bi morao da istu izmenu izvrši na svim mestima gde se pojavljuju podaci indeksa, što za kompleksnije sisteme može da predstavlja problem.

9.3.2. Defi nisanje poljaPolja su zapravo osnovni podaci iz kojih su sačinjene strukture koje su opi-

sane u prethodnom paragrafu. Polja se defi nišu tako što im se dodeljuje naziv, domen nad kojim su defi nisana i ograničenja.

NAZIV POLJA DOMEN OGRANICENJE

DATUM_ISP DATE

DATUM_UPISA DATE

GODINA_UPISA INT(4)

IME NAZIV

PREZIME NAZIV

PREDMET NAZIV

OCENA INT(2) IN(5,6,7,8,9,10)

RBR_SEMESTRA INT(1) IN(1,2,3,4,5,6,7,8)

PIN IDENTIFIKACIJA

ID_ZAPOSLENOG IDENTIFIKACIJA

BR_UGOVORA IDENTIFIKACIJA

DODATNO_OBELEZJE CHAR(3) IN(“II”,”III”,”IV”)

NAUCNO_ZVANJE NAZIV IN (“SPECIJALISTA”, “DOKTOR”, “MAGISTAR”, “DIPL.ING”)

NASTAVNICKO_ZVANJE NAZIV IN (“REDOVNI PROFESOR, “VANREDNI PROFESOR “, “DO-CENT”, “ASISTENT”,”ASISTENT PRIP-RAVNIK”)

Slika 9.20. – Primer defi nisanja polja u rečniku podataka


Na gornjem primeru (Slika 9.20) u prvoj koloni mogu se uočiti nazivi polja koji se podudaraju sa nazivima osnovnih podataka u strukturama istog rečnika podataka (Slika 9.19).

Domeni su predstavljeni u istoimenoj koloni. To su skupovi defi nisani nad osnovnim ili izvedenim tipovima podatka. Nad domenima su defi nisana polja. Ova indirekcija (polje > domen > tip) omogućava da se podaci precizno defi nišu. Domeni mogu biti:

• Predefi nisani – defi nisani nad osnovnim, ili izvedenim sistemskim tipo-vima (npr. INT- celi broj, osnovni tip, DATE – datumski tip, izveden, koji je implementiran u svim savremenim sistemima za upravljanje BP, CHAR(30) – karakterski niz, izveden tip...), ili

• Korisnički defi nisan domen (vidi sledeći paragraf)

U trećoj koloni su ograničenja koja precizno defi nišu opsege (skupove ili intervale) u kojima se vrednosti podataka mogu kretati. U primeru (Slika 9.20) može se uočiti da nije moguće defi nisati ograničenja nad svim poljima. Nemoguće je ograničiti spisak imena, prezimena studenata, ili unapred defi nisati konačan skup predmeta koji će se realizovati na fakultetu. S druge strane nužno je ograničiti skup mogućih ocena koje student može da dobije. Čest slučaj iz srednjoškolske prakse je da nastavnici pored ocena, u dnevnike upisuju tačke, pluseve, minuse. Zamislite IS koji dozvoljava takve unose i kakve posledice bi to imalo u proračunima pojedinačnih i zbirnih uspeha učenika/studenata. Isto tako uvođenjem ograničenja na naučna i nastavnička zvanja onemogućava neovlašće-no defi nisanje i dodeljivanje novih, nepostojećih i nepropisnih titula i zvanja. Suština ograničenja je da ograniči korisnički unos na zadate vrednosti/intervale i time sačuvaju konzistentnost podataka.

9.3.3. Defi nisanje domenaDomeni mogu biti predefinisani ili korisnički definisani. Korisnički

definisani domeni su uvek izvedeni (korisnik je u ovom slučaju analitičar/dizajner sistema). Za ovu vrstu domena može se naći naziv semantički što znači da se njihovim definisanjem se bliže određuje smisao podataka (polja koja ga koriste u svojoj definiciji). U primeru su navedena 2 izvedena dome-na: IDENTIFIKACIJA i NAZIV (Slika 9.21). Naziv domena je semantički, jer ukazuje na razlog definisanja: svi nazivi i imena u sistemu koriste u definiciji domen naziv; domen identifikacija namenjen je jednoznačnom određivanju entiteta u sistemu.


NAZIV DOMENA PREDEFINISANI DOMEN OGRANICENJE

NAZIV CHAR(25)

IDENTIFIKACIJA CHAR(10) IS_UNIQUE_CODE

Slika 9.21. – Primer defi nisanja domena u rečniku podataka

Korisnički domeni se defi nišu nad osnovnim tipovima podataka u situaciji kada se isti osnovni tipovi sa istim ograničenjima višestruko koriste pri defi nisanju polja. Na gornjem primeru (Slika 9.20) - IME, PREZIME, PREDMET, NAUC-NO_ZVANJE, NASTAVNICKO_ZVANJE, su polja defi nisana nad istim tipom podatka i sa istom dimenzijom CHAR(25). Iz razloga lakšeg ažuriranja, defi nisan je domen NAZIV . Kada 25 karaktera postane malo za unos podataka navedenih polja, promenom defi nicije domena NAZIV, automatski se menjaju i defi nicije polja koja su defi nisana nad tim domenom. Na primer, ako sistem pređe sa AS-CII kodiranja podataka na korišćenje UTF-8 – Unicode slovčanog formata, kako bi se podržala slova nacionalnih alfabeta, svaki ASCII 8-bitini karakter postaje niz od 4 do 7 karaktera (32 do 56 bita), što znači da je potreban 4 do 7 puta veći broj karaktera (naziv koji je sadržao 20 karaktera ASCII koda imaće 80 do 140 karaktera u UTF-8 formatu). Drugi defi nisani domen je IDENTIFIKACIJA. Ovaj domen se koristi za jednoznačno označavanje objekata (instanci struktura) koji ga poseduju. Zbog toga on poseduje ograničenje koje ističe da svaki generisani identifi kator mora biti jedinstven u sistemu.

Model objekti-veze (MOV) 81

Po g l a v l j e 1 0 .

Model objekti-veze (MOV)

Početi kreiranje baze podataka nekog informacionog sistema, u suštini zna-či doći do kompleta CREATE naredbi kojima se defi niše šema baze podataka - tabele, relevantni atributi, domeni, ograničenja, itd. U osnovi projektovanja baze podataka je utvrđivanje preciznog modela organizacije za koju se radi informa-cioni sistem. Kao i u ostalim inženjerskim disciplinama, složenost ovakvog posla zahteva da proces kreiranja bude izveden dobro defi nisanom metodologijom i da bude testiran u skladu sa objektivnim kriterijumima. Jedan od najvećih problema u procesu razvoja BP je činjenica da projektanti, programeri i krajnji korisnici na potpuno različite načine shvataju podatke i načine njihove upotrebe, kao i proce-se iz posmatranog okruženja koje treba modelirati. Da bi se obezbedio precizan opis prirode podataka i načina na koji se oni koriste, potrebno je proizvesti jasan model koji nije striktno tehničke prirode. Najčešće korišćeni model u praksi je model objekti-veze.

U ovom poglavlju data je metodologije kreiranja relacionih baza podataka na bazi standardnog Modela Objekti-Veze (Chen 1976). Kreiranje baza podata-ka je praktično proces u dva koraka. Početna faza je bazirana na MOV mode-lu, a druga faza je implementacija. Rezultat MOV faze se redefi niše primenom normalizacione teorije posle koje se garantuje kvalitet šema relacija u skladu sa odgovarajućim kriterijumima. Tipičan dizajn baze podataka obuhvata defi nisanje skupova relacija, na stotine atributa, i mnogo ograničenja koja proističu iz ogra-ničenja u realnom svetu. Dizajniranje baze podataka zahteva dobar nivo kreativ-nosti, iskustva, tehničke ekspertize i razumevanje osnovnih pravila. Glavna kom-ponenta MOV pristupa je koncept entiteta (objekata i veza) - opšti pojam za nešto što postoji i može se jednoznačno prepoznati. Entiteti obuhvataju objekte koji se

82 Model objekti-veze (MOV)

nalaze u jednoj organizaciji, npr. studenti, profesori i predavanja na univerzitetu. Dalje, entiteti obuhvataju i veze među objektima jedne organizacije, na primer profesor_predaje_predmet. Ograničenja integriteta eniteta i veza čine važan deo MOV opisa odnosno specifi kacije. Na primer profesor može da predaje jedno predavanje u određenom vremenu u jednoj sali na fakultetu.

MOV modelovanje obuhvata:

• Skup entiteta (objekti i veze)

• Uočavanje ograničenja

• Defi nisanje ključeva

• Grafi čka predstava (ER dijagram)

• Defi nisanje atributa

• Dizajn globalne šeme

• Svođenje globalne šeme na tabele (relacije)

10.1. Dijagrami objekti-veze (DOV)Dijagram objekti-veze (DOV1)je grafička prezentacija povezanih enti-

teta i ograničenja koja čine dati dizajn odnosno projekat. Kao i kod ostalih vizuelno orijentisanih dizajn metodologija, on pruža grafički sažetak struk-ture baze podataka koji je veoma koristan dizajneru - ne samo u procenji-vanju tačnosti, odnosno pravilnosti dizajna, nego i za savetovanje sa kolega-ma i za objašnjavanje programerima koji će je koristiti. Na žalost, ne postoji standardan plan za MOV dijagrame. Kada je jednom određena organizacija predstavljena setom DOV dijagrama, postoje klasični načini koji dijagrame pretvaraju u skupove CREATE TABLE naredbi. Važna prednost ove metodo-logije je da dizajner može da se usredsredi na celokupno i tačno modelovanje organizacije, a da efikasnost izvršavanja zadatih upita i ažuriranja u odnosu na krajnju bazu podataka stavi u drugi plan. Kasnije, kada se MOV dijagrami pretvore u CREATE naredbe, dizajner može dodati efikasnost koristeći teori-ju normalizacije polaznih šema relacija.

1 U originalu: ERD – entity relationships diagrams


U DTP (dijagramima tokova podataka) koji su analizirani u prethod-nom poglavlju nisu prikazane nikakve veze između tokova podatka, odnosno između skladišta podataka. U stvarnosti te veze postoje, a očigledan dokaz njihovog postojanja su rečnici podataka. Na primer struktuirani tip NAR-UDZBENICA sadrži podatke dobavljača, podatke artikala koji se naručuju i podatke naručioca. Sva tri navedena entiteta predstavljaju strukture za sebe. Dijagrami objekti veze (DOV) otklanjaju ovaj nedostatak. Oni se sastoje od tri osnovne komponente:

• Objekti (entiteti)

• Atributi

• Veze (relacije)

10.2. ObjektiObjekti grupišu srodne podatke. Mogu predstavljati entitete iz realnog sve-

ta, interfejse iz DTP, strukture iz rečnika podataka, ali mogu biti i čisti fabrika-ti, koji samo treba da istaknu povezanost različitih podataka pri procesiranju u sistemu. Entitet objekat egzistira nezavisno i može predstavljati fi zički, realni objekat (npr. Sredstvo) ili konceptualni, apstraktni objekat (npr. Radno iskustvo). Objekat se identifi kuje nazivom i listom svojstava, a grafi čki se predstavlja kao pravougaonik u kome se ispisuje naziv entiteta, koji je najčešće imenica.U DOV se razlikuju takozvani jaki i slabi objekti.

Slika 10.1. – Primer označavanja objekata

Na primeru označavanja objekata (Slika 1), narudžbenica je prikazana kao jak a stavka narudžbenice kao slab objekat. Između jakog i slabog objekta postoji identifi kaciona i egzistencijalna zavisnost što znači da stavka narudžbe-nice ne može postojati u skladištu podataka ako ne postoji narudžbenica koja ju identifi kuje.


10.3. AtributiAtributi su osobine (svojstva) entiteta. Atribut podrazumeva ime i vrednost

svojstva (npr. atribut “boja” i njegova vrednost “plavo”). Entitet se opisuje pomoću jednog ili više svojstava (atributa). Atributi su podaci osnovnog tipa, ili predefi nis-ani domeni. Označavaju se elipsoidima i povezani su pravolinijskim konektorima sa objektima (Slika 2).

Slika 10.2. – Primer označavanja atributa objekata

Broj atributa objekata nije ograničen, kao ni pozicija na kojoj će se atributi uneti u dijagram.

10.4. Veze Veze su najvažniji deo DOV, jer defi nišu načine na kojima su objekti uza-

jamno povezani. Veze se imenuju i njihovi nazivi oslikavaju sematniku poveza-nosti između objekata (Slika 10.3). Pored imena, vezu potpuno defi niše njena kardinalnost. Kardinalnost predstavlja odnos broja objekata koji se povezuju. Određivanje kardinalnosti se uglavnom vrši proučavanjem veza i odnosa između posmatranih objekata. Kardinalnosti može biti:

• Jedan prema jedan (1:1) - na primer jedna uplata dobavljaču se vrši po tačno jednoj fakturi dobavljača (Slika 10.3).


• Jedan prema više (1:*) - na primer jedna narudžbenica sadrži više stavki narudžbenice (Slika 4).

• Više prema više (*:*) - više dobavljača ima ugovore sa više špeditera.

Slika 10.3. – Primer imenovane veze između entiteta

U situacijama kada su veze između objekata implicitno jasne, radi ušte-de u prostoru na dijagramu, veze se ne moraju imenovati. Veza uglavnom ima samo jednosmerni smisao, pa je uobičajeno da se iscrta i strelica koja označava pravilan smer.

Slika 10.4. – Primer neimenovane veze

Na primeru narudžbenice, implicitno je jasno da se ona sastoji od stavki narudžbenice (Slika 10.4). Kardinalnost veze od jakog prema slabom objektu je uvek jedan (jedan jak objekat egzistencijalno određuje više slabih objekata).

Broj entiteta koji učestvuju u vezi se naziva stepen veze. Veza u kojoj učestvu-ju dva entiteta se naziva binarna, veza trećeg stepena (učestvuju tri entiteta) se naziva ternarna, itd. Veza u kojoj jedan entitet učestvuje više puta u različitim


ulogama naziva se rekurzivna ili unarna veza. Na primer, ako je uočen entitet Zaposleni, jedan od zaposlenih je i magacioner. Magacioner izdaje sredstva zapo-slenima pa se uočava veza IzdajeSredstvo. Po nekada magacioner mora i sebi da izda sredstvo. Drugim rečima, enetitet Zaposleni učestvuje dva puta u vezi Izdaje-Sredstvo: prvi put kao magacioner koji izdaje sredstva drugima, a drugi put kao jedan od zaposlenih kome takođe može da se izda sredstvo.

Slika 10.5. – Primer rekurzivne veze

Pored osnovnog, postoji i prošireni model objekti veze, koji omogućava detaljnije defi nisanje veza između objekata. Pored asocijativnih veza predstavljenih na prethodnom primeru, koje treba da oslikaju semantiku udruživanja objekata u sistemu, postoje i specifi čne veze kojima se izražava hijerarhija i komponovanje objekata. Postoje dve reprezentativne vrste ovakvih veza:

• Generalizacija/specijalizacija - na primeru iz rečnika podataka iz pre-thodnih lekcija, strukturom OSOBA izvršena ja generalizacija podataka studenata i ispitivača; oba entiteta poseduju ime, prezime i matični broj građana. Sve tri strukture se prevode u DOV i predstavljene su kao tri entiteta (Slika 10.6). Između njih se uspostavlja veza koja je imenovana kao vrsta. Smer veze predstavlja smer specijalizacije. To znači da su stu-denti i ispitivači samo specifi čni slučajevi (konkretizacije) entiteta OSO-BA. Obrnuti smer je smer generalizacije. Osoba je generalni objekt kojim su obuhvaćeni atributi zajednički za sve specijalizovane klase. Na ovaj način, izbegnuto je redundantno prikazivanje jmbg, imena i prezimena u specijalizovanim objektima – podrazumeva se da oni nasleđuju ove atribute od entiteta OSOBA.


Slika 10.6. – Veze generalizacija/specijalizacija i agregacija/dekompozicija

Agregacija/dekompozicija - agregacija je zapravo veza koja se tretira kao objekat i može da učestvuje u vezama sa drugim objektom. Agregati su objekti sastavnice koji semantički povezuju dva ili više drugih objekata u DOV. Agre-girani objekat se označava simbolom upisanog romba u pravougaonik, čime se izražava njegova dvojaka priroda. Agregati su veoma povoljni za preciznije defi -nisanje veza koje imaju kardinalnost više-više. Pošto su ovi tipovi veza teški za održavanje referencijalnog integriteta, onda se veza pretvara u objekat, koji ima kardinalnost jedan-više prema susednim objektima.

Zbog svoje dvojake prirode, agregati su uglavnom slabi objekti jer egzis-tencijalno zavise od dva ili više drugih objekata koji ih jednoznačno određuju (izuzetak je agregacija na sebe; na primer neko sredstvo može da se sastoji od više objekata koji su takođe tipa sredstvo; u toj situaciji kompozit ne mora da bude


slab objekat, jer postoje sredstva koja mogu da budu, ali nisu kompoziti). Agregati imaju svoje atribute, mogu da budu u vezama drugog tipa (generalizacije/specija-lizacije) sa nekim drugim objektima (moguće agreiranim, takođe).

10.5. PrimerNa narednoj slici predstavljen je primer DOV (Slika 10.7). Pri modelovanju

DOV, polazi se od DTP i rečnika podataka, kojima se opisuje određeni poslovni proces. Na osnovu interfejsa i tokova podataka (TP) iz DTP, defi nišu se objekti. TP su dekomponovani u rečniku podataka kao strukture.

Slika 10.7. – Primer dijagrama objekti veze za proces nabavke


Elementi strukture (polja) su atributi objekata. Ako je element ugnježde-na struktura (struktura u strukturi) ona se predstavlja kao drugi objekti koji se nalaze u vezi (na primer narudžbenica i stavaka narudžbenice, ispitni spisak i pojedinačni rezultat).

Ove veze su obično implicitne i predstavljena im je samo kardinalnosti i usmerenost. Zatim sledi defi nisanje preostalih veza između objekata. Veze se ime-nuju i određuje im se kardinalnost.

Opis DOV (Slika 10.7): u procesu nabavke, formira se narudžbenica (objekat NARUDZBENICA_DOB), kojom se potražuje roba od određenog dobavljača (objekat DOBAVLJAC). Za svaki artikal koji se nabavlja (objekat ARTIKAL), for-mira se jedna stavka narudžbenice (slabi objekat STAVKA_NAR_DOB). Pored podataka artikla, stavka sadrži i količinu koja se nabavlja (nar_kol). Kreirana nar-udžbenica se šalje dobavljaču i on na osnovu nje isporučuje robu, uz koju šalje fakturu - račun za naplatu (objekat FAKTURA_DOB). Kupac po fakturi vrši upla-tu dobavljaču (objekat UPLATA_DOB), a potvrdu (kopiju) o uplati šalje dobavlja-ču, kao dokaz izmirenja svojih obaveza.

Model objekti veze omogućava potpunije shvatanje funkcionisanja siste-ma semantičkim opisom objekata i njihovih uzajamnih veza. Korišćenjem DOV pojednostavljuje se prevođenje logičkog u fi zički model podatka.

Model objekti veze je kompatibilan sa UML2 dijagramom klasa, što znači da pored modelovanja podataka (data layer), omogućava i objektno orjentisano modelovanje aplikacione logike (buisness logic layer).

2 UML Uni� ed modeling language – standard za objektno-orjentisano modelovanje IS kroz razli�ite tipove dijagrama

Relacioni model podataka 91

Po g l a v l j e 1 1

Relacioni model podataka

Relacioni model podataka predstavlja teorijsku osnovu za baze podataka relacionog tipa. Njegovi principi i struktura predstavljeni su 1970. godine od stra-ne Edgara T. Koda. Istraživanje i razvoj baza podataka 70’ i 80’ godina prošlog veka su bili pod velikim uticajem ideja prezentovanih u Kodovim originalnim delima. Do danas, većina komercijalnih DBMS-ova se zasniva na relacionom modelu, iako počinju da se uključuju objektno-orjentisane opcije, pogotovo zbog šire upotrebe podataka baziranih na XML-u.

Relacioni model podataka ima podlogu u jednostavnoj i prirodnoj matema-tičkoj strukturi – relaciji (tj. tabeli). Relacije imaju niz moćnih operatora srodnih prirodnom jeziku, a jezici za manipulaciju relacionim podacima su zasnovani na matematičkoj teoriji – relacionoj algebri. Ova čvrsta matematička osnova znači da relacioni izrazi (tj. upiti) mogu da se analiziraju. Zbog toga, svaki upit može biti transformisan (od strane samog DBMS-a) u neki drugi ekvivalent, izraz koji može biti efi kasnije izvršen, u procesu zvanom optimizacija upita. Dalje, pro-grameri aplikacija ne moraju da poznaju unutrašnjost svake baze podataka do najsitnijih detalja i ne moraju biti svesni načina na koji funkcioniše izvršavanje upita. Aplikativni programer može da formuliše upit na jednostavan i prirodan način, a optimizatoru upita da prepusti traženje ekvivalentnog upita koji će se najefi kasnije izvršiti.

Međutim, optimizatori upita imaju ograničenja koja mogu rezultovati loši-jim performansama, a pogotovo za kompleksnije upite. Zbog toga je bitno i za programere i za dizajnere baza da razumeju logiku koju koriste. Sa ovim zna-njem programeri mogu da formulišu upite koje će DBMS lakše da optimizuje, a

92 Relacioni model podataka

dizajneri baza mogu da ubrzaju obradu važnih upita dodavanjem odgovarajućih indeksa i korišćenjem drugih tehnika.

11.1. Istorija i razvojKao i mnoge druge tehnologije u računarskoj industriji, koreni relacionih

baza podataka potiču iz IBM-a i njihovog istraživanja automatizovanja kancela-rijskog poslovanja u 60-tim i 70-tim godinama XX veka. U tom periodu velike organizacije su uvidele da postaje preskupo da zapošljavaju ogroman broj ljudi za poslove kao što su smeštanje i indeksiranje dokumenata, i da vredi ulagati u razvoj jeft inijih i efi kasnijih rješenja. Mnoga istraživanja su izvedena u toku ovog peri-oda. Razvijeni su hijerarhijski, mrežni i relacioni model, a pojavom mikroproce-sora, kao i razvojem memorijskih komponenata, računarska tehnologija je počela naglo da se razvija. Performanse novih računara su neprestano povećavane, što je praćeno i padom cena računarskih komponenata.

1970. godine, IBM-ov istraživač Edgar Ted Codd je objavio prvi rad o relaci-onim bazama podataka A Relational Model of Data for Large Shared Data Banks. Ovaj rad je dao osnove za korišćenje relacionog računa i algebre da bi se tehnički neobrazovanim korisnicima omogućilo da smeštaju i pretražuju velike količine informacija. Codd je zamislio sistem u kojem će korisnik biti u mogućnosti da podacima u bazi podataka pristupi komandama sličnim rečima na engleskom, i gde će podaci biti smešteni u tabelama.

Zbog same tehničke prirode rada i oslanjanja na matematički aparat, njegova važnost nije odmah shvaćena. Ipak, doveo je do formiranja IBM-ove istraživačke grupe System R. Od projekta System R se očekivalo da stvori sistem relacione baze podataka koji bi mogao postati proizvod. Prvi prototip, prezentovan 1974/75. godine je eksperimentalno korišćen u nekoliko organizacija. 1978. i 1979. godine radne višekorisničke verzije su testirane u proizvodnji i knjigovodstvu u neko-liko aeronautičkih kompanija. System R je evoluirao u SQL/DS koji je kasnije postao DB2 sistem za upravljane bazama podataka. Jezik kreiran u System-u R SQL (Structured Query Language) je postao standard za relacione baze podataka i danas je ISO standard.

Bez obzira što je IBM bio kompanija koja je izumela originalni koncept i SQL standard, oni nisu proizveli prvi komercijalni sistem za relacione baze podataka.


Prvi komercijalni proizvod realizovao je Honeywell u junu 1976. godine. Bio je baziran na istim principima kao i IBM-ov sistem, ali je dizajniran i implementiran odvojeno od IBM-ovog rada.

Soft ver za relacione baze podataka se kontinuirano usavršavao tokom 80-tih. Delom putem povratnih informacija od kupaca, a delom zbog razvoja računarskih sistema i povećane upotrebe personalnih računara i distribuiranih sistema. Prve baze podataka su imale mogućnost rada sa podacima veličine do 8 MB (Sistem R). Današnje baze podataka mogu biti i veličine terabajta ili peta-bajta podataka kada sadrže podatke za mailing liste, informacije o kupcima za veleprodajne lance itd.

SQL standard je prešao iz IBM-a u ANSI (American National Standards Institution) i ISO (International Standards Organization), koji je formirao i radnu grupu za nastavak njegovog razvoja. Ovaj razvoj je još uvek u toku.

11.2. Ključni konceptiIako je osnovna ideja relacionog sistema upravljanja bazama podataka

veoma popularna, veoma mali broj ljudi razume matematičku defi niciju, a samo neki veoma komplikovani sistem upravljanja. ORACLE, na primer, može da se koristi na potpuno relacioni način, ali isto tako on dozvoljava tabelama da budu defi nisane tako da se mogu pojaviti dupli redovi – što je proširenje (ali i destrukcija) relacionog modela. Sistem upravljanja bazama podataka se naziva relacionim ako podržava relacione operacije, bez obzira da li se striktno drži relacionog modela.

Nakon što je defi nisan relacioni model, napravljeni su neformalni modeli da bi se opisali hijerarhijski i mrežni model. Hijerarhijske i mrežne baze podataka su postojale pre relacionih baza podataka, ali su kao modeli opisani tek nakon što je relacioni model defi nisan, da bi se napravila osnova za poređenje.

U srcu relacionog modela nalazi se koncept tabele (koja se pod određenim uslovima naziva i relacija) u kojoj su smešteni svi podaci. Svaka tabela je načinje-na od slogova (redova u tabeli) i polja (kolona u tabeli, atributa).

Veoma je važno zapaziti da kako i gde su tabele smeštene ne pravi nikak-vu razliku. Svaka tabela se identifi kuje jedinstvenim imenom koje baza podataka


koristi da bi pronašla tabelu. Korisniku je potrebno samo da zna ime tabele. Nema potrebe da se vodi računa o tome kako su podaci smešteni na disku. Ovo je razli-čito od hijerarhijskog i mrežnog modela u kojima korisnik mora da razume kako su podaci struktuirani unutar baze podataka da bi mogao da ih pretražuje, umeće nove, ažurira ili briše slogove.

Relaciona baza podataka standardno se sastoji iz više tabela. Ipak, za razli-ku od mrežne baze podataka, tabele nisu povezane pokazivačima. Umesto toga koriste se „ključevi“ da upare redove podataka u različitim tabelama. Ključ je samo jedna ili više kolona u tabeli, koja odgovara kolonama u drugim tabelama. Bilo koja od kolona u tabeli može biti ključ (ako ispunjava određene uslove) ili se više kolona može grupisati u jedan ključ. Za razliku od pokazivača, nije potrebno da se defi nišu svi ključevi unapred; kolona se može koristiti kao ključ čak iako originalno nije bila namenjena za to.

Kada ključ sadrži podatke koji imaju eksterno, stvarno značenje (kao što je ime osobe, ISBN kod knjige ili serijski broj automobila), takav ključ se naziva „prirodni“ ključ. Ako prirodni ključ nije pogodan, može se dodeli-ti ključ (npr. davanje identifikacionog broja zaposlenim ili redni broj unosa podataka). U praksi, većina baza podataka ima oba – i generisane i prirodne ključeve, jer generisani ključevi mogu da se koriste interno da bi se stvorile veze između redova koji se ne mogu prekidati, dok se prirodni ključevi koris-te, manje pouzdano, za pretrage i integraciju sa drugim bazama podataka. (Na primer, zapisi u dve nezavisno kreirane baze podataka mogu da se upare po jedinstvenom matičnom broju, osim u slučajevima kada je JMBG pogrešan, nedostaje ili je promenjen).

Zahtev za podatkom iz relacione baze podataka se dobija slanjem upita koji je napisan u posebnom jeziku, obično nekom od dijalekata SQL-a. Iako je SQL originalno namenjen za krajnje korisnike, mnogo češće se SQL upiti ugrađuju u soft ver koji omogućava lakši korisnički interfejs. Kao odgovor na upit, baza podataka vraća skup podataka, koji je u stvari lista redova koji sadrže odgovor. Najjednostavniji upit je da se dobiju svi redovi iz tabele, ali češće, redovi se fi ltri-raju na neki način da bi se dobio traženi odgovor. Često se podaci iz više tabela kombinuju u jednu, procesom udruživanja.

Konceptualno, ovo se radi uzimanjem svih mogući kombinacija redo-va (proizvod ukrštanja), a zatim izbacivanjem svega osim odgovora. U praksi,


relacioni sistem upravljanja bazama podataka optimizuje upite da bi se obavljali brže, korišćenjem različitih tehnika: U „udruživanju“ primarna optimizacija se dobija korišćenjem indeksa da bi se sprečila izgradnja kompletnog proizvoda ukrštanja, koji bi inače bio neophodan.

Fleksibilnost relacionih baza podataka dozvoljava programerima da pišu upite koji nisu bili predviđeni od strane dizajnera baze podataka. Kao rezul-tat, relacione baze podataka mogu da se koriste u više aplikacija koje originalni dizajneri nisu predvidjeli, što je posebno važno za baze podataka koje se mogu koristiti decenijama. Ovo je model relacionih baza podataka učinilo veoma popu-larnim u poslovnoj primeni.

11.3. Objekti u relacionom modelu podatakaModel podataka je formalni sistem čiji su osnovni elementi: • objekti (entiteti); • pravila integriteta (ograničenja); • operacije sa objektima.

Već smo ranije objasnili da relacioni model podataka na realni svet gleda putem tabela. Tabele u relacionom modelu nazivamo relacijama. Redosled kolona u relaciji nije bitan. Tabelama se predstavljaju klase entiteta iz realnog sveta. Jedna klasa predstavlja skup entiteta koji imaju ista svojstva (osobine). Na primer, kla-sa studenata jednog fakulteta predstavlja skup svih studenata (entiteti) na datom fakultetu. Ova klasa se može predstaviti tabelom STUDENT.

Svaki entitet poseduje svojstva. Svojstva entiteta se nazivaju atributi. Atribu-tima dajemo značenje pojedinačnim podacima. Relacioni model razlikuje proste (jednostavne) i složene atribute.

Pojedinačan podatak (prost atribut) je najmanja nedeljiva jedinica u relaci-onom modelu. Pojedinačni podaci su “Beograd”, 125, “Marko” i td. Ako bi podelili bilo koji od pojedinačnih podataka on bi izgubio prvobitni smisao. Na primer podatak “Marko” možemo deliti na slogove ali dobijeni slogovi nemaju značenje koje je imao podatak pre podele.


Skup svih mogućih vrednosti nekog atributa nazivamo domenom atributa. Skup svih mogućih gradova je domen atributa GRAD. Skup svih mogućih boja je domen atributa BOJA itd. Svaki atribut mora imati samo jedan pridruženi domen. Više različitih atributa može se zadati nad istim domenom. Na primer, atribu-ti MESTO_BORAVKA i MESTO_ROĐENJA imaju isti domen. Takođe atributi IME_STUDENTA i IME_PROFESORA imaju isti domen.

Relacioni model podataka počiva na nekoliko formalnih pojmova.

11.3.1. Šema relacijeŠema relacije R, u oznaci R(A1,A2,...,AN), je konačan skup atributa

{A1,A2,...,AN} i konačan skup ograničenja nad vrednostima tih atributa. Kako je šema relacije defi nisana preko skupa, redosled atributa nije bitan i svaki naziv atributa je jedinstven u okviru šeme relacije (ne može se ponoviti isto ime atributa u jednoj šemi relacije).

Šemom relacije se predstavljaju svojstva klase objekata ili veza nekog siste-ma. Šema relacije može da se tumači i kao defi nicija strukture neke datoteke.

11.3.2. RelacijaRelacija r zadata nad šemom relacije je konačan skup n-torki šeme relacije R.

Posledica defi nicije relacije je da imamo sledeće 4 osobine:• Nazivi atributa u šemi relacije moraju da budu različiti• Redosled kolona u šemi relacije nije bitan.• Relacija ne sadrži dve jednake n-torke.• Redosled n-torki nije bitan.

Kako je relacija skup n-torki i sve n-torke su iste dužine, u relacionom modelu n-torke ne mogu imati promenljivu dužinu.

Jednostavnije rečeno, šema relacije je opis strukture jedne tabele, a sama relacija je sadržaj te tabele. Naravno, da bi takva tabela bila relacija poštuju se gore navedena ograničenja. Relaciji u praksi odgovara jedna datoteka, a svakoj n-torki odgovara jedan slog te datoteke. Slogovi u datoteci su zapisani u određenom redo-sledu, najčešće po redosledu unošenja


Primer: Šema relacije kojom se opisuje klasa studenata, gde su relevantni atributi Broj indeksa i Ime studenta, može da bude:

STUDENT (BrInd Ime),

a relacija nad ovakvom šemom u jednom trenutku može da bude:

student (BrInd Ime)123/02 J.Jankovic11/03 P.Petrovic151/02 J.JovanovicIII-15/04 M.Markovic

11.3.3. Relaciona baza podatakaRelaciona baza podataka je konačan skup relacija koje su defi nisane odgo-

varajućim šemama relacija {Ri} i konačan skup ograničenja koja važe između datih šema. Ona predstavlja stanje nekog sistema u vremenu. Relaciona BP je promenljiva, a promene se odnose na dodavanje (INSERT), brisanje (DELETE) i izmenu (UPDATE) n-torki.

11.3.4. Kandidat ključKandidat ključ predstavlja jedan ili više atributa i to je jedan od prvih

pojmova u relacionom modelu koji se koristi za pouzdan (siguran pristup) žel-jenim podacima. U suštini, baze podataka postoje da bi se u njih smeštali podaci, ali pristup željenim podacima mora biti nepogrešiv. Na osnovu kandidat ključa mogu se pouzdano razlikovati dve n-torke u jednoj relaciji.

Iz defi nicije relacije sledi da je svaka n-torka u relaciji je jedinstvena. Znači, postoji podskup K skupa atributa šeme relacije (u najgorem slučaju to su svi atri-buti iz šeme relacije), takav da za dve različite n-torke t1 i t2 postoji atribut AiK sa osobinom t1(Ai) ≠ t2(Ai). Obično u jednoj relaciji možemo naći više takvih podskupova atributa i njih nazivamo kandidat ključem.

Defi nicija: Neka je data šema relacije R. Podskup K�R je kandidat ključ za R ukoliko zadovoljava osobine:

- Jednoznačnost: za svake dve različite n-torke t1 i t2 postoji AiK takav da je t1(Ai) ≠ t2(Ai).

- Minimalnost: ne postoji pravi podskup K’ od K sa osobinom jednoznač-nosti.


11.3.5. Primarni ključIzborom jednog kandidat ključa koji nam služi za identifi kaciju n-torki u

odgovarajućoj relaciji, biramo njen primarni ključ. U relacionom modelu podata-ka primarni ključevi se obeležavaju (podvlačenjem ili se npr. u Accessu posle nazi-va upisuje znak ). Ostale kandidat ključeve nazivamo alternativnim ključevima. Primarni ključ se može sastojati iz jednog ili više atributa.

U šemi relacije DOBAVLJAČ(SIFD, IME, GRAD, STATUS); SIFD je pri-marni ključ. U šemi relacije STUDENT(BR_IND, IME ADRESA, SMER, RED-NI_BR_S) imamo dva kandidat ključa BR_IND i {SMER, REDNI_BR_S}. Pri-marni ključ relacije je BR_IND, dok je {SMER, REDNI_BR_S} alternativni ključ. Ovakav primarni ključ je odabran zbog jednostavnosti i zbog toga što zauzima manje memorijskog prostora (osobina minimalnosti).

Posmatrajmo šemu relacije NABAVKA(SIFD, SIFA, KOL) koja reprezen-tuje vezu iz realnog sveta koja postoji između dobavljača i određenih artikala. Primarni ključ šeme relacije NABAVKA, koji je ujedno i jedini kandidat ključ, je {SIFD, SIFA}. Atribut SIFD je primarni ključ u relaciji DOBAVLJAČ, a atribut SIFA je primarni ključ relacije ARTIKAL. Dakle, primarni ključ mogu da čine više atributa).

Posmatrajmo šemu relacije RADNIK(SIFR, IME, SIF_ODELJENJA, SIF_RUKOVODIOCA). Primarni ključ relacije je atribut SIFR. Svaki radnik ima ruko-vodioca, a to je osoba koja rukovodi odeljenjem kome pripada radnik. Kako je rukovodilac radnik, imamo da domen atributa SIF_RUKOVODIOCA je aktivni domen atributa SIFR.

Osobinama relacije možemo dodati i adresabilnost. Svaka kolona u rela-ciji jednoznačno je određena nazivom atributa. Svaka n-torka jednoznačno je određena vrednošću primarnog ključa te n-torke. Svaki pojedinačan podatak jed-noznačno je određen:

– nazivom relacije– nazivom atributa– vrednošću primarnog ključa

Atribute koji pripadaju primarnom ključu nazivamo primarnim atributi-ma. Ostale atribute nazivamo sporednim atributima.


11.3.6. Spoljni ključUloga spoljnih ključeva je prvenstveno u uspostavljanju veza između rela-

cija. Za atribute SIFD i SIFA u relaciji NABAVKA i atribut SIF_RUKOVODIOCA u relaciji RADNIK kažemo da su spoljni ključevi, jer su im vrednosti iz aktivnih domena primarnih ključeva iz druge ili iste relacije. SIFD i SIFA su primarni klju-čevi iz drugih relacija, dok je SIF_RUKOVODIOCA zadat na domenu primarnog ključa iz iste relacije. SIF_ODELJENJA je takođe spoljni ključ.

Defi nicija: Ukoliko je neki atribut u relaciji zadat na domenu primarnog ključa iste ili druge relacije, taj atribut nazivamo spoljnim ključem relacije. Spoljni ključ u šemi relacije R je svaki njen podskup atributa za koji važi ograničenje vrednosti u relaciji r na sledeće dve vrednosti:

• vrednost primarnog ključa u nekoj relaciji (tzv. ciljnoj relaciji)• vrednost NULL

Za spoljni ključ SIFD u relaciji NABAVKA(SIFD,SIFA,KOL) kažemo da se referencira na primarni ključ SIFD u relaciji DOBAVLJAČ. Za spoljni ključ SIF_RUKOVODIOCA kažemo da se referencira na primarni ključ SIFR iste tabele, a SIF_ODELJENJA se referencira na primarni ključ SIF_ODELJENJA u relaciji ODELJENJE(SIF_ODELJENJA, NAZIV, SIF_RUKOVODIOCA, ADRESA).

Jedna šema relacije može da sadrži više spoljnih ključeva. Spoljni ključ može biti u sastavu primarnog ključa. Spoljni ključ jedne relacije može istovremeno biti i primarni ključ date relacije u celini Spoljni ključ se može ili se ne mora obe-ležavati - obeležavanje doprinosi preglednosti modela

11.4. Integritet podataka u relacionom modeluKroz istoriju razvoja relacionog modela podataka najveće izmene je

pretrpeo integritet podatka. Jedan od razloga je i to što ova oblast nije pre-cizno utemeljena kao što su precizno zasnovani objekti relacionog modela i operacije nad objektima.

Integritet (konzistentnost) baze podataka je ispravnost i istinitost podata-ka sadržanih u bazi. Neispravni podaci mogu biti posledica ažuriranja (unoše-nja i brisanja podataka) bilo namernog, bilo nenamernog od strane korisnika u


slučajevima kada je relacioni model loše defi nisan. Integritet podataka u širem smislu podrazumeva sve mere kojima je cilj da spreči unos neispravnih podata-ka. Mere za sprečavanje slučajnih pogrešaka se značajno razlikuju od mera za sprečavanje namernih aktivnosti. Iz integriteta baza podataka izuzete su sve mere kojima je cilj sprečavanje ilegalnih operacija. One su predmet izučavanje posebne oblasti koja se odnosi na zaštitu podataka.

Pravila integriteta su ograničenja sadržaja baze podataka na neka dozvoljena stanja. Cilj je sprečavanje unosa neistinitih i neispravnih podataka u bazu. Sva ažuriranja, brisanja i ubacivanja n-torki moraju biti u skladu sa tim ograničenjima. Ako se ta pravila ispoštuju, ne mora da znači da je uneti podatak ispravan, ali ukoliko se ne ispoštuju, onda je podatak koji se unosi sigurno neispravan.

Pravila integriteta delimo u dve grupe:• Korisnička pravila integriteta.• Opšta pravila integritera;

11.4.1. Korisnička pravila integritetaOva pravila zavise od konkretne baze. Ona su specifi čna za konkretnu rea-

lizaciju baze i proističu iz ograničenja koja važe i u realnom svetu. Posmatrajmo bazu koja ima relacije:

STUDENT (BR_IND, IME, PREZIME, ADRESA, GODINA SMER, RB) 0001 Marko Antić Tolstojeva 21 2 PP 1 .......................................

PREDMET (SIFP, NAZIV, BČ) 01 Programiranje 2 .......................................

OCENE (BR_IND, SIFP, OC) 0001 01 8 .......................................

Možemo nad tim relacijama postaviti sledeća korisnička pravila integriteta:• BR_IND ima vrednost oblika nnnn tako da je podatak iz intervala 0001-

9999.• IME i PREZIME vrednost su podaci koji sadrže slova ili prazninu.


• ADRESA vrednost su podaci koji mogu biti slova, praznina i cifre.• GODINA uzima vrednost od 1 do 4.• SMER ima vrednost iz skupa FM, RV i OS.• RB je broj između 1 i 450.• SIFP uzima vrednost iz intervala 01 do 37.• NAZIV vrednost su podaci koji se sastoje iz slova, praznine i cifara.• BČ vrednost je ceo broj između 2 i 4.• OC ima vrednost od 5 do 10.

Pri defi niciji pravila integriteta koristimo razna ograničenja koja atributi mogu da uzimaju. Sva ograničenja nad atributima možemo podeliti u dva skupa:

• nezavisna ograničenja• zavisna ograničenja.U našem primeru sva navedena ograničenja su nezavisna, tj. vrednost se

defi niše isključivo na osnovu semantičkog značenja atributa za koji defi nišemo ograničenje.

Posmatrajmo relaciju zadatu nad relacionom šemom:

RADNIK(SIFR, IME, PREZIME, STAŽ, STAROST).

Vrednost atributa STAŽ nije nezavisna, već zavisi od vrednosti atributa STAROST. Ne može da postoji radnik kome je starost 25 godina, a staž 20 godi-na. U ovom slučaju morali bismo da defi nišemo ograničenje za atribut STAŽ i u zavisnosti od vrednosti atributa STAROST. Ovo je tipična relacija koja ima lošu strukturu što je posledica odabrane šeme relacije u kojoj jedan atribut zavisi od drugog. Ovakve probleme tretira posebna oblast (zavisnost i normalne forme). Relacije loše strukture se mogu popravljati u postupku koji se zove normalizacija. Normalizacijom se od relacije loše strukture formiraju dve ili više relacija u koji-ma se dekomponuju zavisni atributi.

11.4.2. NULL vrednostPosebnu ulogu u defi nisanju opštih pravila integriteta ima vrednost

“NULL”. Često nismo u stanju poznajemo vrednost za neki podatak. Razlozi mogu biti razni. Uzmimo na primer studenta koji se upisao na fakultet iz mes-ta boravka u kome nema matičnog fakulteta i još nije odlučio da li će biti u


domu ili u privatnom smeštaju. U ovom slučaju umesto da vrednost atributa ADRESA bude adresa studenta, vrednost atributa će biti NULL. Ovo je slučaj kada u momentu unosa n-torke ne znamo podataka, jer on u tom momentu i ne postoji. Postoji situacija da podatak koji nam je potreban postoji, ali ga je teško ili skoro nemoguće saznati. I u ovom slučaju umesto konkretne vrednosti za podatak unosimo NULL vrednost.

11.4.3. Opšta pravila integritetaOpšta pravila integriteta su sastavni deo relacionog modela podataka i

sastoje se iz dva pravila:• Identifi kacioni (egzistencijalni) integritet;• Referencijalni integritet.

Pravila su vezana za dozvoljena stanja primarnih ključeva i spoljnih ključe-va u bazi. Primarni ključ služi za identifi kaciju entiteta koje opisujemo n-torkama u relaciji, pa je jasno da su pravila o dozvoljenim stanjima tih atributa strožija od pravila za obične atribute.

11.4.4. Identifi kacioni integritet Odnosi se na opšta ograničenja za primarni ključ relacije. Već smo u defi ni-

sanju primarnog ključa zahtevali minimalnost i jednoznačnost. Vrednost primar-nog ključa jednoznačno određuju n-torke i ne može se iz njega izbaciti ni jedan atribut, a da on i dalje poseduje jednoznačnost. Ovim dobijamo uslov za integritet primarnog ključa:

• Ni jedna komponenta primarnog ključa relacije ne sme imati NULL vrednost.

11.4.5. Referencijalni integritetReferencijalni integritet se odnosi na dozvoljena stanja spoljnih ključeva.

Ako posmatramo relacije DOBAVLJAČ, NABAVKA i ARTIKAL, onda za n-torke iz NABAVKE kažemo da se referenciraju na relaciju DOBAVLJAČ. One takođe vrše referenciranje na relaciju ARTIKAL. Često kažemo za n-torku iz relacije NABAVKA da je pozivajuća, a njoj odgovarajuća u relaciji DOBAVLJAČ je ciljna n-torka.

Posmatramo li relaciju RADNIK, RADNA_JEDINICA, onda bi n-tor-ka u relaciji RADNIK bila pozivajuća, a direktori u radnim jedinicama bili bi


ciljne n-torke. N-torka u relaciji RADNIK mogla bi da bude i ciljna i pozivajuća. Direktor kao radnik pripada odgovarajućoj radnoj jedinici, pa u tom slučaju on je pozivajuća n-torika za pripadajuću radnu jedinicu. Sa drugre strane, n-torka radne jedinice u kojoj je radnik rukovodilac je pozivajuća, a njena ciljna je rad-nik koji joj je rukovodilac.

Uslov referencijalnog integriteta se može defi nisati na sledeći način:• Baza podataka ne sme da sadrži ni jednu nepovezanu vrednost za spoljni

ključ. Znači, vrednost spoljnog ključa može biti ili NULL vrednost ili vrednost primarnog ključa odgovarajuće ciljne n-torke.

Posmatramo li relaciju zadatu nad šemom relacije NABAVKA( SIFD,SIFA, KOL), primarni ključ te relacije je skup atributa {SIFD, SIFA}, pa se na njega odnosi identifi kacioni integritet (ni jedna komponenta ne sme imati NULL vred-nost). Sa druge strane, SIFD i SIFA su spoljni ključevi na odgovarajuće atribute u ciljnim relacijama, znači u n-torci moraju da postoje vrednosti za te ključeve u ciljnim n-torkama.

U relaciji RADNIK(SIFR, IME, SIFO_DELJENJA, SIF_RUKOVODIOCA) svi radnici imaju direktora, a i direktor je jedna n-torka te relacije. SIF_RUKOVO-DIOCA je spoljni ključ relacije a time će direktoru biti uneta NULL vrednost.

Suština referencijalnog integriteta je u ograničavanju vrednosti stranog ključa. Sa stanovišta izmena (ažuriranja) u relaciji koja sadrži spoljni ključ (pozi-vajuća relacija) to podrazumeva da važe sledeća ograničenja:

• Ne može se uneti n-torka sa vrednošću stranog ključa koja nije jednaka nekoj vrednosti primarnog ključa u ciljnoj relaciji ili NULL vrednosti.

• Ne može se izmeniti n-torka tako da vrednost stranog ključa ne bude jednaka nekoj vrednosti primarnog ključa u ciljnoj relaciji ili NULL vrednosti.

Sa stanovišta ciljne relacije važi sledeće:• Dodavanje nove n-torke (u ciljnoj relaciji) ne narušava referencijalni

integritet - nastaje samo nova vrednost primarnog ključa• Uklanjanjem n-torke (a izmena ponekad) dovodi do nestanka jedne

vrednosti primarnog ključa. Ako bi se ta operacija izvršavala bezuslovno to bi narušilo referencijalni integritet


Postavlja se pitanje kako postupiti kada se vrši ažuriranje u ciljnoj relaciji, a da se ne naruši referencijalni integritet. Takva specifi kacija se naziva: dinamič-ka specifi kacija referencijalnog integriteta i odnosi se samo na kritične opera-cije, a to su operacija uklanjanja (DELETE) i operacija izmene (UPDATE). Uz ove akcije neophodno je navesti jednu od sledeće tri klauzule: RESTRICTED, CASCADES, NULLS

• RESTRICTED: operacija se ne izvršava ako u pozivajućoj relaciji postoji vrednost stranog ključa koja odgovara vrednosti primarnog ključa u cilj-noj relaciji

• CASCADES: operacija se uvek izvršava. Ako je uklonjena n-torka iz ciljne relacije, u pozivajućoj relaciji se uklanjaju sve n-torke sa datim ključem. Ako je došlo do izmene, menjaju se sve vrednosti n-torki u pozivajućoj relaciji sa novim spoljnim ključem

• NULLS: operacija se uvek izvršava. U pozivajućoj relaciji se u svim n-torkama koje imaju dati promenjeni spoljni ključ, menja njegova vred-nost u NULL. NULLS klauzula se ne može sprovesti ako je spoljni ključ u sastavu primarnog ključa, ili ga čini u celini – to bi bilo u suprotnosti sa identifi kacionim integritetom.

Relaciona algebra 105


Relaciona algebra

Relaciona algebra pripada kategoriji formalnih upitnih jezika procedural-nog karaktera. Čini je skup operatora za rad sa relacijama, a rezultati operacija su takođe relacije. Relaciona algebra je osnova za upitne jezike koje koriste ljudi. Sva-ki od algebarskih izraza je jedan upit ili pretraživanje. Upitni jezik – jezik kojim korisnici zahtevaju informacije iz BP

Operacija je primena nekog operatora na jednu ili više izvornih relacija kako bi se formirala nova relacija. Relacionu algebru čini skup od 8 operacija koje se nazivaju osnovnim (5 elementarnih i 3 izvedene)

• Elementarne: restrikcija (selekcija), projekcija, unija, razlika, Dekartov proizvod

• Izvedene: presek, spajanje, deljenje

Operacije se mogu klasifi kovati i prema broju operanada. Pojedine operaci-je se izvršavaju nad jednim, a pojedine nad dve relacije.

• Unarne (1 operand)• Binarne (2 operanda)

Tabela: Klasifi kacija osam osnovnih operacija

Simbol Naziv Složenost Br. operanada

σ restrikcija elementarna unarna

π projekcija elementarna unarna

� unija elementarna binarna

106 Relaciona algebra

Simbol Naziv Složenost Br. operanada

- razlika elementarna binarna

� presek izvedena binarna

× Dekartov proizvod elementarna binarna

>< spajanje izvedena binarna

⁄ deljenje izvedena binarna

12.1. Restrikcija - σRestrikcija (selekcija, ograničenje, eng: restrict) - kao rezultat daje tačno

određene n-torke iz tabele tj. samo one n-torke koje zadovoljavaju zadati kriterij-um (izdvajanje redova u tabeli).

Defi nicija: Restrikcija je operacija relacione algebre koja iz polazne rela-cije po zadatom kriterijumu izdvaja podskup n-torki. Kriterijum je neki logički izraz koji je izračunljiv nad svakom n-torkom. Dobijena relacija ima istu struk-turu kao i polazna.

Ako je r relacija nad šemom R(X), a P(X) uslov restrikcije, formalna def. restrikcije je:

σP(X)(r) = t(X) = {x | xr � P(X)}

Operacija restrikcije kao rezultat može da da prazan skup n-torki.

Uslov restrikcije P se sastoji iz članova koji su povezani sa:

� (and),

� (or),

¬ (not),

a svaki član je u formi

<atribut> op <atribut> ili <konstanta>

gde je op jedan od: =, ≠, >, ≥, <, ≤


Primer .Selekcija studenta sa brojem indeksa 125/2004 iz klase studenata:

σ BrInd=‘125/2004’ (student) = t (BrInd, Ime, Prezime, Adresa, Telefon)

kao rezultat daje podatke samo za studenta sa BrInd=125/2004.

Primer .Iz relacije r(A;B;C;D):

A B C D

α α 1 7

α β 5 7

β β 12 3

β β 23 10

nakon operacije σ A=B ^ D > 5 (r) dobija se

A B C D

α α 1 7

β β 23 10

12.2. Projekcija - πProjekcija (eng: project) kao rezultat daje relaciju koja se sastoji samo od

određenih atributa zadate relacije (izdvajanje kolona u tabeli).

Defi nicija: iz polazne relacije po zadatom skupu atributa formira se nova relacija kao skup n-torki nad tim atributima. Zadati skup atributa mora biti pod-skup skupa atributa polazne relacije. Vrednosti atributa u n-torkama nastale rela-cije odgovaraju onima u polaznoj relaciji.


Ako je r relacija nad šemom R(X), Y zadati skup atributa, a x i y n-torke nad X i Y, formalna defi nicija restrikcije je: πY(r) = t(Y) = {t | Y�X � yx}

Primenom operacije projekcije moguće je da više n-torki polazne relacije daje iste vrednosti. Pošto rezultat operacije mora biti relacija, uzima se samo jedna rezultantna relacija

Primer .Projekcija relacije student po atributima BrInd, Ime i Prezime:

π BrInd, Ime, Prezime (student) = t (BrInd, Ime, Prezime)

kao rezultat daje relaciju koja sadrži samo podatke BrInd, Ime i Prezime. Kako je BrInd primarni ključ relacije r ne smanjuje se broj n-torki u novonastaloj relaciji. Projekcija samo po Imenu ili Prezimenu može da dovede do smanjenja broja n-torki u novonastaloj relaciji, kao i do gubitka podataka za studente sa istim ime-nom ili prezimenom.

Primer 2. Iz relacije r(A;B;C;D):

A B C

α 10 1

α 20 1

β 30 1

β 40 2

Nakon primene operacije projekcije π A,C (r) dobija se t1(A,C)

A C

α 1

α 1

β 1

β 2


a zbog uslova identifi kacionog integriteta krajnji rezultat je t2(A,C)

A C

α 1

β 1

β 2

Za razliku od restrikcije, rezultirajuće n-torke nemaju sve atribute koje ima originalna relacija, već samo one po kojima se izvodi projekcija.

12.3. Unija - �Rezultat unije dve relacije je relacija koja se sastoji od svih n-torki koje se

nalaze i u jednoj i u drugoj relaciji.

Defi nicija: Unija je operacija relacione algebre kojom se iz dve polazne rela-cije formira novu koja sadrži sve n-torke iz obe relacije. Ova operacija nije moguća između bilo koje dve relacije, tj. mora biti zadovoljeno:

• Šeme relacija moraju imati isti broj atributa• Atributi šema relacija redom odgovaraju po značenju i tipu (ne mora po

nazivu)Navedeni uslovi se nazivaju unijska kompatibilnost

Ako su r i s relacije nad šemom R(X) i S(X), gde X označava unijski kompa-tibilan skup atributa u obe relacije, formalna defi nicija unije je:

r � s = t(X) = {x | xr � xs}.

Svaka n-torka koja je prisutna u obe relacije pojavljuje se samo jednom u rezultantnoj.

Primer 1. Za unijski kompatibilne relacije r i s


r sA B A B

α 1 α 2

α 2 β 3

β 1

nakon operacije r � s dobija se sledeća relacija

A B

α 1

α 2

β 1

β 3

Primer 2.Unijom relacija A i B

ŠIFRA# PREZIME IME TEL.BROJ

3244 Aksentijević Petar 011 334 952

1772 Maksimović Ilija 015 723 543



2345 Petrović Petar 023 47 833

Dobija se relacija C = A � BŠIFRA# PREZIME IME TEL.BROJ





12.4. Razlika - /Rezultat razlike (eng: diff erence) - dve relacije je relacija koja se sastoji od

svih n-torki koje se nalaze u prvoj i ne nalaze u drugoj relaciji, tj. iz prve relacije se isključuju sve n-torke zajedničke s drugom relacijom.

Defi nicija: iz dve polazne relacije formira se nova koja sadrži sve n-torke prve relacije koje se ne nalaze u drugoj. Ova operacija je moguća samo između unijski kompatibilnih relacija.

Ako su r i s relacije nad šemom R(X) i S(X), X označava unijski kompatibilan skup atributa u obe relacije, formalna defi nicija razlike je:r - s = t(X) = {x | xr � x�s}

Primer 1.Za relacije A i B







primenom operacije razlike formira se relacija C = A - B



ili relacija C= B- A




Primer 2.

Nad relacijama

kredit(BR_KRED#, IME_EXP, IME_KL, IZNOS)racun(IME_EXP, BR_RAC#, IME_KL#, STANJE)

Naći sve klijente koji u ekspozituri IEX imaju račun ali još uvek nemaju kredit

Ovaj zadatak se rešava u koracima. Prvo se selektuju sve n-torke koje se odnose na ekspozituru IEX, a zatim se ostvari unijska kompatibilnost posmat-ranih relacija primenom operacije projekcije po željenom atributu. Na kraju se primeni operacija razlike novonastalih relacija:

• Naći sve klijente koji imaju racun u ekspozituri IEX

π IME_KL (σIME_EXP=IEX(racun)) � t1

• Naći sve klijente koji imaju kredit u ekspozituri IEX

π IME_KL (σIME_EXP=IEX(kredit)) � t2

• Rezultat je: t1 - t2

12.5. Presek - �Presek (eng. intersect) - rezultat preseka dve relacije je relacija koja se sastoji

od n-torki koje su zajedničke za obe relacije, odnosno koja sadrži sve n-torke koje se nalaze i u jednoj i u drugoj relaciji. Ova operacija je moguća samo između unij-ski kompatibilnih relacija.

Ako su r i s relacije nad šemom R(X) i S(X), X označava unijski kompatibi-lan skup atributa u obe relacije, formalna defi nicija preseka je:

r � s = t(X) = {x | x r � x s}.Presek je izvedena operacija, može se izvesti izr � s = r – (r-s)

Primer 1.

Za relacije A i B


ŠIFRA# PREZIME IME TEL.BROJ3244 Aksentijević Petar 011 334 9521772 Maksimović Ilija 015 723 543

ŠIFRA# PREZIME IME TEL.BROJ3244 Aksentijević Petar 011 334 9522345 Petrović Petar 023 47 833

primenom operacije preseka formira se relacija C = A � B

ŠIFRA# PREZIME IME TEL.BROJ3244 Aksentijević Petar 011 334 952

Primer 2.Nad relacijama

kredit(BR_KRED#, IME_EXP, IME_KL, IZNOS)racun(IME_EXP, BR_RAC#, IME_KL#, STANJE)

Naći sve klijente koji u ekspozituri IEX imaju i račun i kredit. Do rezultata se dolazi u koracima, uz ostvarivanje unijske kompatibilnosti.

• Naći sve klijente koji imaju racun u IEX π IME_KL (σIME_EXP=IEX(racun)) � t1• Naći sve klijente koji imaju kredit u IEX π IME_KL (σIME_EXP=IEX(kredit)) � t2• Rezultat je: t1 � t2

12.6. Dekartov proizvod - ×Dekartov proizvod dve relacije je relacija koja se sastoji od svih

mogućih kombinacija parova n-torki, pri čemu je prva n-torka iz prve, a druga iz druge relacije.

Defi nicija: iz dve polazne relacije formira novu sa n-torkama dobijenim tako što se svaka n-torka prve relacije spaja sa svakom iz druge. Šema nastale relacije sadrži sve atribute polaznih relacija.


Ako su r i s relacije nad šemom R(X) i S(Y), a X i Y su skupovi atri-buta u šemama relacija, formalna defi nicija Dekartovog proizvoda je:r × s = t(XY) = {xy | x r � y s}

Kod označavanja za puni naziv atributa se može koristiti relacija.atribut (ako je X � Y ≠ ), da bi se mogli razlikovati atributi iz jedne i druge relacije.

Primer 1. Za polazne relacije r i s

r s

A B C D E

α 1 α 10 a

β 2 β 10 a

β 20 b

γ 10 b

kao rezultat dekartovog proizvoda r×s dobija se

A B C D E

α 1 α 10 a

α 1 β 10 a

α 1 β 20 b

α 1 γ 10 b

β 2 α 10 a

β 2 β 10 a

β 2 β 20 b

β 2 γ 10 b

Nakon primene dekartovog proizvoda, u rezultujućoj relaciji samo pojedine n-torke imaju smisla.


Primer 1.Nad relacijama

klijent(IME_KL, UL_BR, GRAD),licni_bankar(IME_KL, IME_SL)

Naći sve klijente sa ličnim bankarom IS1 i gradove u kojima klijenti žive

Nakon primene dekartovog proizvoda, samo neke od n-torki sadrže tražene podatke.

licni_bankar × klijent � t(LB.IME_KL, LB.IME_SL, K.IME_KL, K.UL_BR, K.GRAD)

Klijent

Zoran Savska BeogradMilan Niška Novi SadPetar Kralja Milana Kruševac

Lični bankar

Zoran Sl1Milan Sl2Petar Sl3

Klijent × Lični bankar

Zoran Savska Beograd Zoran Sl1Zoran Savska Beograd Milan Sl2Zoran Savska Beograd Petar Sl3Milan Niška Novi Sad Zoran Sl1Milan Niška Novi Sad Milan Sl2Milan Niška Novi Sad Petar Sl3Petar Kralja Milana Kruševac Zoran Sl1Petar Kralja Milana Kruševac Milan Sl2Petar Kralja Milana Kruševac Petar Sl3


12.3.1. Spajanje - ><Defi nicija: iz dve polazne relacije formira novu sa n-torkama dobijenim u

dva koraka:• Svaka n-torka iz prve relacije redom se spaja sa svim n-torkama iz druge

relacije• Iz tako dobijenih n-torki izdvajaju se one koje zadovoljavaju zadati uslov PAko su r i s relacije nad šemom R(X) i S(Y), X i Y su skupovi atributa u

šemama relacija, formalna defi nicija operacije spajanja je:

r >P(XY)< s = σP(XY)(r×s) = {xy | x r � y s � P(xy)}

12.6.2. θ spajanjePrethodna defi nicija dozvoljava proizvoljni uslov P, pod uslovom da je izra-

čunljiv za svaku n-torku nakon Dekartovog proizvoda

Neka su r i s relacije nad šemom R(X) i S(Y). Neka su Xi i Yk atributi za koje važi da je

XiX i YiY. Pod θ spajanjem r > Xi θ Yi< s

podrazumeva se spajanje kod koga operator θ označava bilo koji operator poređenja: (=,≤,<,>,≥,≠)

12.6.3. Ekvi spajanjePrethodno θ spajanje ograničava formu uslova spajanja, međutim i dalje

dobijeni rezultat nema praktičnu primenu. Specijalni slučaj gde θ predstavlja jed-nakost (=) je čest slučaj u praksi.

Ekvi spajanje po jednom atributu:

r > Xi = Yi< s

Ekvi spajanje po više atributa označava se sa:

r > (X1,X2,...,Xn) = (Y1,Y2,...,Yn) < s


12.6.4. Prirodno spajanjePrethodno spajanje daje jedan suvišan atribut, zato što su vrednosti atributa

po kojima se vrši spajanje uvek iste. Nepotrebni atribut se eliminiše dodatnom operacijom projekcije. Navedeni slučaj je čest u praksi, pa je uvedena specijalna operacija prirodnog spajanja. Podrazumeva sekvencu tri elementarne operacije

• Dekartov proizvod relacija• Restrikciju po uslovu jednakosti atributa• Projekcija po razlici unije svih atributa i skupa spojnih atributa iz bilo

koje od relacija

Prirodno spajanje dve relacije po jednom atributu označava se sa:

r > Xi,*,Yk < s

Specijalni slučaj označavanja: r > * < s podrazumeva prirodno spajanje po svim atributima koji imaju jednake nazive u obe relacije.

Formalna defi nicija prirodnog spajanja: Ako su r i s relacije nad šemom R(X) i S(Y), a A�X i B�Y su uređeni podskupovi jednakog broja atributa relacija r i s, respektivno, prirodno spajanje defi nišemo kao:

r > (A)*(B) < s = πXY-B(σ (A)=(B) (r×s))=t(XY-B)

Jednakost uređenih podskupova A i B podrazumeva jednakost korespo-dentnih elemenata. Umesto XY-B sa desne strane može se navesti XY-A.

Primer 1. Za polazne relacije r i s

r sA B C D Eα 1 α 10 aβ 2 β 10 a

β 20 bγ 10 b

kao rezultat prirodnog spajanja r >*< s = π XY-B (σA=C(r × s)) dobija se


r>*< sA B D Eα 1 10 aβ 2 10 aβ 2 20 b

12.7. Deljenje - /Deljenje je najsloženija operacija relacione algebre.

Deljenje se ne može izvesti sa proizvoljnim tabelama. Za A/B potrebno je da se svi atributi relacije B nalaze u relaciji A.

Npr: Moguće je deljenje za: a (X1,X2,...,Xn,Y1,Y2,...,Ym) b (Y1,Y2,...,Ym)

Primer: Za dve relacije r i s, date sa: r s

A B C D E D E

α a α a 1 a 1

α a γ a 1 b 1

α a γ b 1

β a γ a 1

β a γ b 3

γ a γ a 1

γ a γ b 1

γ a β b 1

nakon operacije deljenja r/s dobija se:

A B Cα a γ

γ a γ

S Q L 119


SQL

SQL (Stuctiured Query Language) je standardni relacioni upitni jezik (ANSI - American National Standards Institute - standard). Služi za kreiranje, organizaci-ju i manipulaciju podacima u relacionim bazama podataka. Sam nastanak jezika se vezuje za IBM-ovu istraživačku laboratoriju u San Hozeu u Kaliforniji, gde je SQL razvijen kasnih 70-ih godina, u sklopu projekta System R.

Danas je SQL ugrađen u sve vodeće SUBP SQL je uspešno primenjen u sis-temima za upravljanje bazom podataka kao što su MS Access, DB2, Informix, MS SQL Server, Oracle, Sybase itd. Trenutno u svetu postoji više standarda SQL jezika, a najpoznatije su: ANSI-92, ISO, Microsoft SQL, itd. IBM je 1987. godine standar-dizovao sopstvenu verziju SQL-a. Zatim je ANSI 1989. godine objavio proširenu verziju, poznatu kao SQL-89. Sledeća standardizovana verzija je SQL-92, dok je najnovija verzija publikovana 1999. godine.

13.1. Terminologija SQL-a U terminologiji SQL-a umesto pojma relacije koristi se pojam tabele. Za

jednu n-torku u relaciji kažemo da predstavlja jedan red tabele, a kolone tabele odgovaraju atributima. Ova terminologija je nasleđena iz prakse koja je pretho-dila standardizaciji, a rezultat toga je krajnje neobična okolnost da u SQL-u, jezi-ku za relacione baze podataka, ne postoji ni jedna konstrukcija koja sadrži reč “RELATION”.

120 S Q L

SQL jezik podržava dva režima rada sa bazom podataka:

• Interaktivni: Korisnik zadaje jednu po jednu SQL naredbu interaktivno, preko tastature, a ishod svake se prikazuje preko monitora. Pristup bazi podataka je ograničen jedino pravima korisnika i

• Programski: Korisnik pokreće program u kome se nalaze “ugrađene” SQL naredbe. Pristup bazi podataka ograničen je pravima korisnika i sadržajem programa. Pri tome, ugrađene naredbe mogu biti statičke (fi ksirane u vreme prevođenja programa) ili dinamičke (konstruisane tokom izvršavanja programa).

Baza podataka sadrži tabele i druge objekte radi smeštanja i obrade podata-ka. Za kreiranje baze koristi se naredba:

CREATE DATABASE imeBaze

SQL podržava 3 osnovne funkcije BP: defi nicije, manipulacije i kontrolu.

DDL (Data Defi nition Language)

SQL DML (Data Manipulation Language)

DCL (Data Conrol Language)

Defi nicija baze podataka: Pre početka rada sa bazom podataka neophodno je defi nisati njenu strukturu - koje tabele postoje, koji atributi postoje u tabelama i kog su tipa, koja ograničenja postoje unutar tabela i između njih, koje pomoćne strukture (indeksi) za ubrzanje pristupa podacima postoje i za koje tabele. Ova komponenta jezika odgovara DDL-jeziku baze podataka (od “Data Defi niton Language”).

Manipulacija bazom podataka: Pored upita nad bazom podataka, kojima dobijamo željene informacije, neophodno je obezbediti i ažuriranje baze podata-ka, odnosno unos, izmenu i brisanje podataka. Ova komponenta je u stvari DML-jezik baze podataka (od “Data Manipulation Language”).

Kontrola pristupu podacima: U svakoj bazi podataka neophodno je ostva-riti kontrolu koji korisnici imaju pristup kojim podacima i šta mogu da rade sa tim podacima. Ova komponenta predstavlja DCL-jezik baze podataka (od “Data Control Language”).

S Q L 121

13.2. PRAVILA SQL-a

13.2.1. Pravila za pisanje imena Imena tabela, pogleda, atributa i drugih objekata baze podataka moraju da

poštuju sledeća pravila: 1) Maksimalna dužina imena je 30 znakova, 2) Ime ne sme da sadrži znak pitanja (?), 3) Nema razlike između malih i velikih slova, 4) Prvi znak mora biti slovo, 5) Dozvoljeni znaci su A-Z, 0-9, _, $ i #, 6) Kao imena se ne smeju koristiti rezervisane reči i 7) Imena se ne smeju ponavljati.

Radi lakšeg čitanja koda preporučuje se da ključne reči (naredbe) budu napisane velikim slovima, a svi ostali elementi malim slovima. U nekim bazama niz znakova (string) mora biti napisan kao što je u bazi.

13.2.2. O naredbama i izrazima

Naredbe mogu sadržati izraze u kojima se pojavljuju:

• Logičke operacije: AND, OR i NOT,

• Operacije upoređivanja: =, <, >, ≤, ≥, < >, kao i IN, ANY, ALL, BETWEEN, IS NULL, LIKE, ...

• Skupovne operacije: unija (UNION), presek (INTERSECT) i razlika (EXCEPT),

• Svodne funkcije na skupovima podataka: broj članova (COUNT), zbir članova (SUM), najmanji i najveći (MIN i MAX), srednja vrednost (AVG) itd.

• Ostale funkcije za rad s podacima.

Izrazi se mogu grupisati pomoću zagrada. Mogu sadržati zadate brojeve, tekstualne podatke i/ili ostale vrste podataka.

122 S Q L

13.2.3. Tipovi podataka Pri kreiranju tabela određujemo tip podatka koji će biti korišćen. Sledeća

tabela prikazuje najosnovnije standardne SQL tipove podataka, njihove karakte-ristike, kao i neke od alternativnih podtipova.

TIP PODATKA OPIS

CHAR(n) Podatak tipa niza karaktera fi ksne dužine n

VARCHAR(n) Podatak tipa niza karaktera promenljive dužine

NUMBER

Numerički podaci bilo kog tipa, do 38 cifara. Podtipovi:

DEC

DECIMAL

DOUBLE

DOUBLE_PRECISION

FLOAT

INT

NUMERIC

REAL

SMALLINT

DATE Koristi se za promenljive i konstante čiji je sadržaj informacija o vremenu, npr.: datumi, sati, min. i sec.

BOOLEN Koristi se za promenljive i konstante koje sadrže logičke vrednosti TRUE (istina) i FALSE (laž)

13.2.4. Defi nicija atributaAtribut defi nišemo izrazom od dva ili tri dela:

<ime_atributa> <tip_atributa> <dodatna_svojstva_atributa>

S Q L 123

Dodatna svojstva:

• DEFAULT - zadavanje predefi nisane vrednosti,

• NOT NULL - vrednost ne sme biti nepoznata ili ne zadata,

• CHECK - provera da je vrednost atributa u zadatim granicama,

• UNIQUE - jedinstvenost među n-torkama unutar relacije,

• PRIMARY KEY - primarni ključ,

• REFERENCES - vrednost mora biti među vrednostima iz druge relacije, obično ključ iz druge relacije.

13.3. Naredbe SQL-a za defi nisanjeDefi nicija neke baze podataka podrazumeva i mogućnost naknadne izme-

ne ili uklanjanja te defi nicije. U standardnom SQL jeziku se to postiže sa svega tri naredbe:

• CREATE: Služi za kreiranje nekog objekta (tabele, indeksa, itd.) u bazi podataka,

• DROP: Služi za uklanjanje defi nicije nekog objekta iz baze podataka i

• ALTER: Služi za izmenu defi nicije nekog objekta u bazi podataka.

124 S Q L

13.3.1. Rad sa tabelamaPrilikom kreiranja tabele, odnosno defi nicije njene strukture i osobina

(šema), neophodno je navesti sledeće: • Ime tabele, koje mora biti unikatno u bazi podataka, • Ime svake kolone, koja mora biti unikatno unutar tabele, • Tip svake kolone, • Jedno ili više ograničenja za kolone koje ih imaju i • Jedno ili više ograničenja za celu tabelu, ako postoje.

Primer:

JMBG Ime Prezime Ulica i broj Grad

0104983134526 Petar Petrović Njegoševa 46 Beograd

0505983871231 Ivan Ivanović Dunavska 55 Novi Sad

0901983987651 Marko Marković Durmitorska 3 Beograd

Naredba za kreiranje tabele glasi CREATE TABLE ImeTabele.

Sintaksa naredbe kreiranja tabele:

CREATE TABLE ImeTabele (imeKolone TipKolone OgraničenjeKolone ... {, imeKolone TipKolone OgraničenjeKolone ...} [OgraničenjeTabele {, OgraničenjeTabele}]);

• ImeTabele i ImeKolone - pravila koja važe za većinu varijabli: prvi znak je slovo, ostali znaci su slova, cifre, posebni znaci, itd.

• TipKolone - SQL tip podataka• Uz svaku kolonu mogu se navesti jedno ili više ograničenja za tu kolonu.

Naredba za uklanjanje tabele je DROP TABLE imeTabele. Tabela koja se uklanja mora biti prazna. U suprotnom SUBP neće izvršiti tu naredbu.

Izmena tabele se vrši naredbom ALTER TABLE imeTabele. Naknadna iz-mena se najčešće radi jer se kod prvobitnog kreiranja tabele nije uzeto u obzir

S Q L 125

sve šta je bilo potrebno, ili je došlo do zahteva za promenama aplikacije i baze podataka.

Naredba izmene tabele je nešto složenija, pošto treba da obezbedi sledeće mogućnosti izmene tabele:

• Dodavanje nove kolone, • Izmena postojeće kolone, • Uklanjanje postojeće kolone, • Dodavanje novog ograničenja tabele i• Uklanjanje postojećeg ograničenja tabele.

Izmena kolone je ograničena samo na mogućnost uvođenja nove ili uklan-janja podrazumevane vrednosti. U tim okolnostima, postojeća ograničenja kolo-ne se ne mogu uklanjati a nova se mogu dodavati samo preko dodavanja novog ograničenja tabele sa naznačenom jednom kolonom.

Uklanjanje kolone nije moguće ako je navedena kolona jedina u tabeli, kao i ako je navedena klauzula RESTRICTED, a u bazi podataka postoji bar jedno referenciranje koje referiše kolonu koja se uklanja.

13.4. PoglediPogled (view) predstavlja izvedenu tabelu, ima redove i kolone i nastaje

kao rezultat upita nad osnovnim tabelama i drugim pogledima. Redovi i kolone pogleda nisu nigde trajno zapisani. Umesto toga, svaki put kada se pristupa pogle-du izvršava se upit kojim je on defi nisan.

Prednosti koje imaju pogledi u radu sa RBP: • Pogled predstavlja jednu vrstu “podprograma” u SQL-u. Jednom kreiran,

može se koristiti u podupitima u WHERE i HAVING klauzulama, • Komplikovani i često korišćeni upiti se mogu formulisati u vidu pogleda

koje će korisnici jednostavno pozivati u upitima tipa SELECT * FROM imePogleda,

• Pogled razrešava problem pojavljivanja viška podataka u svodnim upi-tima (kada u određenim implementacijama pravila za SELECT naredbu

126 S Q L

nalažu da pored traženih podataka u rezultat uključimo i nepotrebne po kojima se grupiše)

• Pogledi znatno olakšavaju kontrolu pristupa bazi podataka.

Naredbe za rad sa pogledima:

CREATE VIEW iDROP VIEW

Kreiranje pogleda vrši se naredbom čija je sintaksna defi nicija:

CREATE VIEW Pogled [ ( Kolona ,.. ) ] AS Upit ;

gde je značenje pojedinih djelova ove defi nicije sledeće:

Pogled Unikatni naziv pogleda u bazi podataka, simbol formiran po pravilu za na-zive varijabli

Kolona Ako se navedu kolone pogled se ponaša kao tabela sa brojem, redosledom i imenima kolona kako je navedeno, a u suprotnom se preuzimaju imena Kolona iz osnovnih tabela i pogleda koje su navedene u naredbi upita. U oba slučaja, pogled nasleđuje tipove kolona iz osnovnih tabela i pogleda iz upita

Upit Naredba upita SELECT čiji rezultat izvršavanja daje “tabelu” koja predstavlja pogled

Pogled se uklanja naredbom čija je sintaksna defi nicija:

DROP VIEW Pogled ;

Uklanjanje pogleda nema nikakvog efekta na osnovne tabele iz upita.

13.5. IndeksiIndeks je pomoćna datoteka koja treba da ubrza pristup podacima u nekoj

osnovnoj datoteci. Pored toga, indeks ima još jednu namenu: zapisi u osnovnoj datoteci nalaze se u fi zičkom redosledu koji odgovara redosledu unosa podataka. Kada pristupamo neposredno toj datoteci zapise očitavamo tim redosledom, ali ako podacima pristupamo posredstvom indeksa, očitavaćemo ih redosledom koji odgovara rastućoj ili opadajućoj vrednosti indeksnog izraza.

S Q L 127

Sintaksa naredbe za kreiranje indeksa je:

CREATE [ UNIQUE ] INDEX ImeIndeksa ON Tabela ( Kolona ,.. );

gde je značenje pojedinih djelova ove defi nicije sledeće:

UNIQUE Kada se zada ova opcija, indeks mora biti unikatan, odnosno u tabeli na koju se indeks odnosi ne sme da se više puta ponovi neka vrednost Kolona

Ime Indeksa Unikatni naziv indeksa u bazi podataka, simbol formiran po pravilu za nazive varijabli

Kolona Jedna ili više kolona po kojima se formira indeks

Nad istom tabelom po potrebi može biti defi nisano više indeksa. To se koris-ti kada su potrebni različiti pristupi podacima i različiti redosledi podataka.

Indeks može biti kreiran odmah, dok je tabela na koju se odnosi prazna, ili naknadno. Ako se kreira naknadno, indeks dobija sadržaj koji odgovara sadrža-ju svoje tabele. Od tog trenutka, sadržaj indeksa i tabele je sinhronizovan: svako dodavanje ili uklanjanje podataka, kao i izmena vrednosti neke od kolona koja je u sastavu indeksnog izraza, odražava se na sadržaj indeksa.

Indeks se može bilo kada i bez obzira na sadržaj svoje tabele ukloniti nared-bom čija je sintaksna defi nicija:

DROP INDEX ImeIndeksa ;

13.6. SELECT upitiNaredba za upite, odnosno, SELECT naredba, predstavlja najznačajniju i

najčešće korišćenu SQL naredbu za manipulaciju podacima.

13.6.1. Prost upit nad jednom tabelom:Kod svakog upita se zadaje: • Koje podatke tražimo kao rezultat, • Iz kojih tabela to tražimo, • Koji uslov treba da zadovolje podaci da bi bili uključeni u rezultat i • Po kom redosledu želimo prikaz rezultata.

128 S Q L

Pod prostim upitom nad jednom tabelom podrazumeva se naredba SELECT nad jednom tabelom koja kao rezultat daje ni jedan red, jedan red ili niz redova podataka, od kojih svaki odgovara podacima iz jednog reda tabele koji zadovoljava eventualno zadati uslov.

Rezultat upita ne mora biti relacija u smislu unikatnosti redova koji ulaze u rezultat. To se ispoljava kada za rezultat upita biramo samo neke od kolona, kada može doći do pojave istovetnih redova u rezultatu. Stoga prilikom formulacije upita treba da postoji mogućnost specifi kacije da li želimo eliminaciju višestrukog pojavljivanja istih redova u rezultatu ili ne.

Prost upit nad jednom tabelom ima sledeću sintaksu:

SELECT R-Lista FROM Tabela[ WHERE R-Predikat ][ ORDER BY { R-Izraz [ ASC | DESC ] } ,.. ] ;

gde jeR-Lista ::= * | { [ ALL | DISTINCT ] R-Izraz ,.. }

Značenje:

* Specijalni slučaj kada želimo da uključimo sve kolone tabele, i to onim redosledom kojim su navedene u naredbi kreiranja tabele

ALL Tražimo da se u rezultatu prikažu svi redovi uključujući i one koji su istovetni, podrazumijeva se ako se ništa ne navede

DISTINCT Tražimo da se iz rezultata eliminišu suvišna pojavljivanja (osim jed-nog) istovetnih redova

R-Izraz Izraz izračunljiv nad svakim pojedinim redom tabele koji pored na-ziva kolona može da sadrži i operatore i konstante. Naješće je u formi navođenja jedne kolone

R-Predikat Logički izraz koji je izračunljiv nad svakim pojedinim redom tabele. U formiranje rezultata upita ulaze samo oni redovi za koje taj izraz daje istinit rezultat. U najjednostavnijim slučajevima, R-Predikat je u formi relacionog izraza u kome se sa jedne strane relacionog operatora ( >, <, =, itd.) javlja ime kolone, a sa druge strane ime kolone ili konstanta

S Q L 129

Primer 1.Najjednostavniji mogući SQL upit je u formi:

SELECT * FROM ImeTabele;

Ova naredba prikazuje sve redove tabele čije je ime navedeno iza FROM klauzu-le. U svakom redu prikazuju se vrednosti svih kolona, onim redom kako je to zapisano u datoteci (tj. kreirano sa CREATE TABLE). Kod upita se obično traži prikaz samo određenih kolona, ili prikaz svih kolona u redosledu koji je drugačije određen.

13.6.2. Prost upit nad jednom tabelom sa svodnim rezultatom:Sintaksa za SELECT (prost upit nad jednom T sa izvedenim rezultatom)

SELECT G-Lista FROM ImeTabele [WHERE R-Predikat];

G-Izrazi: najčešće ih čine posebne SQL funkcije (svodne ili agregatne funk-cije). One mogu biti:

• SUM (ImeKolone) Nalazi sumu svih ne-NULL vrednosti zadate kolone• AVG (ImeKolone) Nalazi prosečnu vrednost svih ne-NULL vrednosti

zadate kolone• MIN (ImeKolone) Nalazi minimalnu vrednost svih ne-NULL vred

nosti zadate kolone• MAX (ImeKolone) Nalazi maksimalnu vrednost svih ne-NULL vred-

nosti zadate kolone• COUNT(*) Nalazi ukupan broj redova u tabeli• COUNT([ALL�DISTINCT] ListaKolona) Bez DISTINCT nalazi ukupan broj ne-NULL vrednosti zadate kombina-

cije kolona Sa DISTINCT nalazi ukupan broj različitih ne-NULL vrednosti zadate

kombinacije kolona

Primer:Uz pretposatvku da su u tabeli Student uneseni svi studenti jednog fakulte-

ta, ukupan broj studenata tog fakulteta se može dobiti sa:

SELECT COUNT(*) FROM Student;

130 S Q L

13.6.3. WHERE klauzula WHERE klauzula služi za izbor zapisa na osnovu kriterijuma (fi ltriranje).

Prilikom defi nisanja kriterijuma možemo se koristiti logičkim (AND, OR, NOT) i komparativnim (<, >, < =, > =, < >) operatorima. WHERE klauzula nije obavezna, a može se koristiti sa SELECT, UPDATE I DELETE komandama.

Korišćena u SELECT bloku, WHERE klauzula omogućuje: • Selekciju specifi čnih n-torki relacije (redova tabele), • Selekciju n-torki koje zadovoljavaju višestruke uslove, • Selekciju n-torki koje zadovoljavaju bar jedan od više uslova, • Selekciju n-torki koje ne zadovoljavaju određene uslove, • Selekciju n-torki istovremenim korišćenjem AND i OR logičkih operatora, • Selekciju n-torki unutar izvesnog raspona, • Selekciju n-torki koje zadovoljavaju vrednost u listi vrednosti i • Selekciju n-torki koje sadrže određenu kombinaciju karaktera.

13.6.4. ORDER BY klauzula Korišćenjem ORDER BY klauzule moguće je sortirati rezultujuću tabelu po

jednom ili više atributa u rastućem ili opadajućem redosledu.

Za specifi kaciju rastućeg redosleda koristi se klauzula ASC, za specifi kaci-ju opadajućeg redosleda klauzula DESC. Rastući redosled se podrazumijeva, pa klauzulu ASC nije neophodno navoditi, za razliku od klauzule DESC koju uvek treba navesti kada se sortira u opadajućem redosledu.

ORDER BY je uvek poslednja klauzula u SELECT bloku.

13.6.5. GROUP BY klauzula Klauzula GROUP BY prouzrokuje dobijanje sumarne informacije za svaku

različitu vrednost kolone po kojoj se vrši grupisanje.

GROUP BY klauzula se može koristiti zajedno sa klauzulom WHERE, pri čemu WHERE klauzula uvek ide pre GROUP BY klauzule. WHERE klauzulom se najpre izvrši selekcija n-torki, zatim se selektovane n-torke grupišu GROUP BY klauzulom, pa se, eventualno, izvrši selekcija formiranih grupa HAVING klauzulom.

S Q L 131

13.6.6. HAVING klauzula HAVING klauzula određuje kriterijume za selekciju grupa, pošto su grupe

već formirane sa GROUP BY klauzulom.

13.6.7. Korišćenje NULL vrednosti NULL vrednosti su nedefi nisane vrednosti. Između NULL vrednosti i vred-

nosti nula postoji značajna razlika. Bez obzira o kom tipu da se radi NULL vred-nost određene kolone može se testirati samo pomoću dve specijalne klauzule: IS NULL ili IS NOT NULL. Operatori poređenja se ne mogu koristiti kod testiranja NULL vrednosti.

13.6.8. LIKE klauzulaKlauzula LIKE omogućava pretraživanje na osnovu “UZORKA”, odnosno,

dobijanje informacija i kada ne znamo potpun naziv (tj. vrednost) određenog atributa tipa character. Ona koristi dva specijalna karaktera (“%”,”_”) sa sledećim značenjem:

• “%” predstavlja string od 0 ili više karaktera, a • “_” predstavlja poziciju jednog karaktera. Ostali karakteri imaju uobičajeno značenje.

13.7. Naredbe ažuriranjaAžuriranje u širem smislu značenja te reči obuhvata dodavanje, izmenu

sadržaja i brisanje reda ili redova tabele. Te osnovne operacije realizuju se SQL naredbama: INSERT, UPDATE i DELETE sa sledećim značenjem:

INSERT: Dodavanje reda ili redova u tabelu, UPDATE: Izmena sadržaja postojećeg reda ili redova tabele i DELETE: Brisanje postojećeg reda ili redova tabele.

Posebno treba voditi računa da su sve tri navedene naredbe - naredbe nad jednom tabelom, tako da se njihovom primenom ne garantuje očuvanje integri-teta baze podataka. Direktno korišćenje ovih naredbi se zato ne preporučuje, jer

132 S Q L

je u tom slučaju procedura za očuvanje integriteta “spolja”, tj. sam korisnik mora voditi računa o njoj. Ove naredbe direktno treba da koristi samo administrator baze podataka i to za otklanjanje eventualno narušenog integriteta baze.

Normalno ažuriranje baze podataka vrši se aplikacijama za interaktivno ažuriranje u koje su ugrađene procedure za očuvanje integriteta. Te procedure se sastoje od naredbi INSERT, UPDATE i DELETE.

13.7.1. INSERT naredbaPostoje 3 slučaja korišćenja naredbe INSERT, i to kada se vrši: • Unos vrednosti SVIH atiributa n-torke, • Unos vrednosti NEKIH atributa n-torke i• Unos podataka iz jedne tabele u drugu.

Unos vrednosti SVIH atributa n-torke:

U ovom slučaju nije potrebno specifi cirati nazive atributa, pa INSERT nar-edba ima oblik:

INSERT INTO NazivTabeleVALUES (vrednost_atr1, vrednost_atr2, . . .) ;

Za svaki atribut MORA postojati vrednost, pri čemu je NULL dozvoljena opcija za svaki atribut koji nije NOT NULL.

Unos vrednosti NEKIH atributa n-torke:

Ako želimo da unesemo vrednost za samo neke atribute, nazivi tih atributa moraju se eksplicitno navesti. U tom slučaju naredba INSERT ima oblik:

INSERT INTO NazivTabele (atri1, atri2.)VALUES (vrednost_atr1, vrednost_atr2, . . . ) ;

Unos podataka iz jedne tabele u drugu:

Ukoliko obe tabele imaju isti broj atributa i ukoliko su atributi identično defi nisani, naredba INSERT je oblika:

S Q L 133

INSERT INTO tabela 1 SELECT * FROM tabela2 ;

inače:

INSERT INTO tabela1 (atribut1, atribut2, ...)SELECT atribut1, atribut2FROM tabela2WHERE kriterijum selekcije ;

13.7.2. UPDATE naredbaUz ovu naredbu mora se navesti:• U kojoj tabeli se vrše izmjene,• Za koje kolone u redu mijenjamo vrednosti,• Pod kojim uslovima mijenjamo vrednosti.

Opšti oblik naredbe je:

UPDATE ImeTabeleSET atribut1 =izraz1 [,atribut2=izraz2][WHERE kriterijum selekcije n-torki],

odnosno,

UPDATE ImeTabeleSET(alribut1, atribut2,..)=(podupit) [WHERE kriterijum selekcije n-torki]

Podupit mora vratiti najviše po jednu vrednost za svaki od atributa u listi atributa iza SET klauzule.

13.7.3. DELETE naredbaUz ovu naredbu mora se navesti:• Iz koje tabele se vrši uklanjanje i • Pod kojim uslovima se uklanja neki red.

Sintaksa naredbe:

DELETE FROM ImeTabele WHERE R-Predikat

134 S Q L

SUBP odbija uklanjanja, ako je to u suprotnosti sa dinamičkom specifi kaci-jom referencijalnog integriteta.

13.8. Naredbe za kontrolu prava pristupaNaredbe za kontrolu prava pristupa podacima u bazi podataka su: • GRANT: Naredba za dodeljivanje prava korišćenja, • REVOKE: Naredba za oduzimanje prava korišćenja

Ove naredbe čine osnovu dela SQL jezika za kontrolu pristupa bazi podataka.

Suština kontrole pristupa bazi podataka je u tome da se ostvare sledeći vido-vi kontrole:

• Ko uopšte može da pristupa bazi podataka, • Čemu može da pristupi u bazi podataka i • Šta može da radi sa onim čemu može da pristupi.

Deo SQL jezika za kontrolu pristupa bazi podataka sve to obezbeđuje pu-tem sledećih funkcija:

• Kreiranje i uklanjanje korisnika - naloga za rad za bazom podataka, • Dodela i uklanjanje opštih prava za rad sa bazom podataka i • Dodela i uklanjanje posebnih prava za rad sa bazom podataka.

13.8.1. GRANT naredbaOpšti oblik naredbe GRANT:

GRANT {ALL | [ALTER, DELETE, INDEX, INSERT, SELECT, UPDATE(atr) ] }ON [kreator {tabela | pogled}TO (PUBLIC ! korisnik1,korisnik2, ... }[ WITH GRANT OPTION] ;

Tabela koju kreira korisnik je njegova tabela. Drugi korisnik je ne može koristiti ukoliko mu kreator, vlasnik tabele eksplicitno ne dodeli pravo korišćenja. Dodela prava korišćenja tabele drugim korisnicima se vrši naredbom GRANT. Drugim korisnicima se mogu dati sva prava (ALL) ili samo neka od navedenih u listi iza GRANT klauzule. Ta prava se daju nad tabelom ili pogledom. Mogu

S Q L 135

se dati svim korisnicima (PUBLIC) ili samo nekim, u kom slučaju se eksplicitno navode identifi katori korisnika kojima se daje pravo korišćenja. Pravo korišćenja se daje drugom korisniku sa ili bez mogućnosti da to što je dobio dodeli još ne-kom korisniku (WITH GRANT OPTION).

13.8.2. REVOKE naredbaOpšti oblik naredbe REVOKE:

REVOKE {ALL[ALTER, DELETE, INDEX, INSERT, SELECT, UPDATE(atr) ] }ON [kreator.] {tabela | pogled}FROM {PUBLIC | korisnik1, korisnik2, ... } ;

Data prava korišćenja se oduzimaju naredbom REVOKE.

Relacije loše strukture 137


Relacije loše strukture

Glavni cilj u procesu razvoja baze podataka je da se kreira sistem koji verno reprezentuje podatke, njihove veze i odnose, kao i ograničenja. Da bi se postigao ovaj cilj, moraju se pravilno uočiti odgovarajuće tabele, a metoda koja se za to koristi naziva se normalizacija. Normalizacija je tehnika za kreiranje tabela sa odgovarajućim svojstvima, uzimajući u obzir zahteve okruženja za čije potrebe se projektuje baza. Normalizacija se često realizuje tako što se vrši serija testova nad tabelom da bi se utvrdilo da li ona zadovoljava zahteve određene normalne forme ili ne. Inicijalno su promovisane tri normalne forme, prva (1NF), druga (2NF) i treća (3NF) normalna forma. Kasnije su R.Boyce i E.F.Codd promovisa-li strožu defi niciju treće normalne forme koja se naziva Boyce-Codd normalna forma (BCNF). Sve normalne forme se baziraju na funkcionalnim zavisnostima između atributa tabele. Promovisane su i više normalne forme koje prevazilaze BCNF, i to su četvrta (4NF) i peta (5NF) normalna forma. Ipak, ove forme se bave situacijama koje su vrlo retke.

Normalizacija omogućava projektantu baze da izvrši optimalno grupisan-je atributa po tabelama. Proces normalizacije identifi kuje tabele na osnovu pri-marnih ključeva ili ključeva kandidata i na osnovu funkcionalnih zavisnosti koje postoje između atributa. Normalizacija sadrži pravila koja se mogu upotrebiti za testiranje tabela, tako da baza može da se normalizuje do bilo kog stepena. Tabela koja ne ispunjava zahteve normalizacije mora se rastaviti na dve ili više tabela od kojih svaka pojedinačno ispunjava zahteve normalizacije. Važno je napomenuti da je za kreiranje tabela u relacionom modelu podataka kritična samo 1NF. Sve ostale forme su opcione. Ipak, da bi se izbegle anomalije ažuriranja, preporučuje se normalizacija najmanje do 3NF.

138 Relacije loše strukture

U najopštijem smislu, normalizacija je postupak kojim se proizvoljna nenormalizovana relacija transformiše u skup manjih normalizovanih relacija. U okviru normalizacije ne sme doći do gubitaka informacija sadržanih u relaci-ji. Drugim rečima, mora biti moguće rekonstruisati prethodne relacija na osno-vu novodobijenih.

Dekompozicija šeme relacije R(A1,A2,...,An) je zamena šeme relacije R sa skupom šema relacija {R1, R2, ... , Rk} za koje važi Ri�R i R1� R2�...�Rk=R. Ako je r relacija zadata na R a relacije r1,r2, ... ,rk su dobijene projekcijama relacije r na skupove atributa R1, R2, ... , Rk onda se prirodnim spajanjem mora dobiti relacija r.

14.1. Redundansa (ponavljanje) podataka i anomalije ažuriranjaJedan od najvažnijih ciljeva prilikom projektovanja relacione baze podataka

je pravilno grupisanje atributa po tabelama, što rezultuje minimalnim ponavljan-jem podataka i smanjenjem prostora potrebnog za skladištenje fajlova u kojima se čuvaju podaci. Ponavljanje podataka je pojava da se isti podaci koji se odnose na neki entitet nepotrebno pojavljuju u dve ili više tabela. U tabelama koje sadrže podatke koji se ponavljaju mogu da se jave problemi poznati kao anomalije ažuri-ranja. Anomalije ažuriranja mogu biti anomalije unosa, anomalije brisanja ili ano-malije promene podataka.

14.1.1. Anomalije unosa podatakaPrilikom unosa novih podataka koji se odnose na jedan entitet, u tabelu

koja sadrži podatke koji se ponavljaju moraju se uneti i podaci koji se odnose na druge entitete čiji se podaci nalaze u istoj tabeli, što može dovesti do nekonzis-tentnosti ako se načini greška prilikom unosa.

14.1.2. Anomalije brisanja podatakaBrisanje poslednjeg zapisa koji se odnosi na jedan entitet iz tabele koja

sadrži podatke koji se ponavljaju može dovesti do kompletnog gubitka podataka o drugom entitetu čiji se podaci nalaze u istoj tabeli, u istom zapisu.


14.1.3. Anomalije promene podatakaPrilikom promene vrednosti atributa koji se odnosi na jedan entitet, u tabeli

koja sadrži podatke koji se ponavljaju moraju se promeniti i svi zapisi koji sadrže taj promenjeni atribut, kao i podaci koji se odnose na druge entitete, a koji stoje u direktnoj vezi sa promenjenim atributom. Ako se ne izvrše sve ove promene, baza postaje nekonzistentna.

14.2. Funkcionalna zavisnostFunkcionalna zavisnost opisuje odnose između atributa u tabeli i pred-

stavlja jedan od glavnih koncepata vezanih za normalizaciju. Osnovni raz-log zbog koga se pristupa definisanju funkcionalnih zavisnosti za tabelu je potreba određivanja ograničenja za očuvanje integriteta (integrity constraints). Verovatno najvažnije ograničenje za očuvanje integriteta je uočavanje klju-čeva kandidata, od kojih se jedan bira za primarni ključ tabele. U procesu njihovog definisanja, naročito je značajno pronaći one funkcionalne zavisnos-ti koje važe za sve moguće vrednosti atributa jedne tabele, jer one predstavlja-ju tipove ograničenja za očuvanje integriteta. Tipovi ograničenja za očuvanje integriteta definišu vrednosti koje tabela može legitimno da primi. Takođe je značajno ignorisati tzv. trivijalne funkcionalne zavisnosti, jer za njih važi da su uvek zadovoljene, pa stoga nisu od značaja.

14.3. Postupak normalizacijeNeka polazna šema relacije nije u određenoj normalnoj formi ako u

skupu funkcijskih zavisnosti F postoji bar jedna koja narušava definiciju nor-malne forme.

U svakom koraku normalizacije:1. Uočava se jedna takva zavisnost (X�Y)2. Vrši se dekompozicija u cilju uklanjanja takve zavisnosti3. Ako je u polaznoj važilo X�Y,dekompozicijom nastaju dve relacije.U

prvoj se gube atributi Y, a druga nastaje nad atributima X i Y.4. Ne dozvoljava se gubitak podataka


Krajnji je cilj normalizacije najverovatnije treća normalna forma.U veći-ni slučajeva ona predstavlja najbolji kompromis između ekstrema koji se odnose na funkcionalnost i lakoću implementacije. Nivoi iznad 3FN u praksi mogu da iskomplikuju dizajn baze podataka do tačke da smetaju funkcionalnosti. Svi nivoi normalizacije su kumulativni što znači da baza koja se nalazi u 2NF takođe mora da ispunjava i sve uslove zadate prvom normalnom formom.

Proces analize šeme relacije je proces primene serije testova na šemu rela-cije da bi se proverilo da li ispunjava sva pravila defi nisana za određenu normal-nu formu. Normalne forme pomažu projektantu baze podataka da ostvari željeni kvalitet relacione baze podataka.

14.4. Prva normalna forma (1NF)Pre diskusije o 1NF, najpre treba defi nisati stanje pre 1NF. Tabela koja sadrži

podatke koji se ponavljaju nalazi se u nenormalizovanoj formi (NNF) i naziva se nenormalizovana tabela.

Tabela je u 1NF ako presek svakog njenog reda i kolone sadrži jednu i samo jednu vrednost.

Šema relacije R je u prvoj normalnoj formi ako i samo ako domeni relacije R sadrže samo proste (“atomic”) vrednosti (proste vrednosti su vrednosti koje se ne mogu dalje deliti ili ako u konkretnoj situaciji nisu rastavljene na komponente). U 1NF nisu dozvoljeni viševrednosni i kompozitni atributi i njihove kombinacije tj.nisu dopuštene relacije u relacijama ili relacije kao atributi n-torki. Šema relacije je u 1NF, ako je svaki njen atribut skalarnog tipa, tj. vrednost svakog atributa je jednostruka i nedeljiva.

Ako šema relacije R(A1,A2,…,An) nije u 1NF, onda postoji takva dekompozicija sema relacije R u skup šema relacija {R1,…Rk} koje su u 1NF, na način da se operacijom prirodnog spajanja iz ovih šema relacija može ponovo dobiti šema relacije R.

Da bi se nenormalizovana tabela transformisala u 1NF, moraju se identi-fi kovati i ukloniti podaci koji se ponavljaju. Postoje dva uobičajena pristupa za uklanjanje podataka koji se ponavljaju iz nenormalizovanih tabela:


1. Po prvom pristupu, odgovarajući podaci se ubacuju u prazne kolone redova koji sadrže podatke koji se ponavljaju. Drugim rečima, tamo gde je to potrebno, prazna polja se popunjavaju dupliranim podacima koji se ne ponavljaju. Rezultujuća tabela sadrži atomične (pojedinačne) vred-nosti u preseku svakog reda i kolone, pa je stoga u 1NF. Dakle, u ovom postupku se u tabelu namerno unose podaci koji se ponavljaju, a oni se tokom sledećih, viših faza procesa normalizacije uklanjaju iz tabele.

2. Po drugom pristupu, podaci koji se ponavljaju se, zajedno sa kopijom originalne vrednosti atributa ključa (ili originalne vrednosti više atributa ključeva), izmeštaju u posebnu tabelu. Za novu tabelu se defi niše pri-marni ključ. Ponekad nenormalizovana tabela sadrži više od jedne grupe podataka koji se ponavljaju ili čak grupe unutar grupe. U takvim slučaje-vima postupak izmeštanja se ponavlja sve dok se ne ukloni i poslednja grupa podataka koji se ponavljaju. Za grupu tabela se kaže da je u 1NF ako ne sadrže podatke koji se ponavljaju.

Oba pristupa su ispravna, mada drugi pristup direktno daje tabele koje su u najmanje 1NF. I prvi pristup daje tabele koje su u 1NF, ali koje se tek u kasnijim fazama normalizacije razlažu na iste one tabele koje nastaju kao rezultat primene drugog pristupa. Dakle, može se zaključiti da je drugi pristup direktniji i praktičniji.

Primer: Šema relacije RADPROJ(JMBG, Ime, {ŠifP, Sati}) sadrži ugnježde-nu relaciju PROJEKAT(ŠifP,Sati). Atribut ŠifP je parcijalni primarni ključ rela-cije RADPROJ, tj. zajedno sa atributom JMBG čini njegov primarni ključ. Da bi ova šema relacije bila u 1NF nad njom se defi niše sledeća relacija (sa nekim trenutnim sadržajem):

JMBG Ime ŠifP Sati

123 Marko P1 3

123 Marko P3 2

123 Marko P5 2

222 Petar P3 4

222 Petar P4 2

333 Janko P1 5


Da bi se relacija RADPROJ prevela u bolju 1NF, potrebno je da se ugnježde-na relacija formira kao nezavisna relacija. Šeme relacija sada imaju oblik: RADNIK(JMBG,Ime) i PROJEKAT(JMBG, ŠifP, Sati):

RADNIK PROJEKATJMBG Ime JMBG ŠifP Sati

M1 I1 123 P1 3

M2 I2 123 P3 2

M3 I3 123 P5 2

222 P3 4

222 P4 2

333 P1 5

14.5. Druga normalna forma (2NF)Druga normalna forma se bazira na konceptu potpune funkcionalne zavis-

nosti, koja će najpre biti defi nisana.

14.5.1. Potpuna funkcionalna zavisnostFunkcionalna zavisnost A�B (čita se B je funkcionalno zavisno od A) je

potpuna funkcionalna zavisnost ako uklanjanje bilo kog atributa iz A rezultuje time što zavisnost prestaje da važi, pri čemu su A i B atributi tabele. Funkcionalna zavisnost A�B je delimično zavisna ako postoje neki atributi koji se mogu uklo-niti iz A, a zavisnost i dalje važi.

14.5.2. Defi nicija druge normalne formeDruga normalna forma se odnosi na tabele sa složenim ključevima, tj. tabe-

le čiji se primarni ključevi sastoje iz dva ili više atributa. Tabela čiji primarni ključ sadrži samo jedan atribut je automatski u najmanje 2NF. U tabeli koja nije u 2NF mogu da se pojave anomalije ažuriranja.

Tabela je u 2NF ako je u 1NF i ako je svaki atribut koji nije primarni ključ potpuno funkcionalno zavisan od primarnog ključa.


Normalizacija tabele iz 1NF u 2NF se vrši uklanjanjem delimičnih zavisnos-ti, tj. funkcionalno zavisni atributi se izmeštaju u novu tabelu zajedno sa kopijom njihovih determinanti (ključeva).

14.6. Treća normalna forma (3NF)Čak iako je u 2NF, u tabeli mogu da se pojave anomalije ažuriranja zbog

tranzitivnih zavisnosti, koje se moraju ukloniti iz tabele postupkom normalizacije do 3NF.

14.6.1. Tranzitivna zavisnostTranzitivna zavisnost je stanje u kome su A, B i C atributi tabele takvi da,

ako A�B (B je funkcionalno zavisno od A) i B�C (C je funkcionalno zavisno od B), onda je C tranzitivno zavisno od A preko B (pod uslovom da A nije funkcional-no zavisno od B ili C).

14.6.2. Defi nicija treće normalne formeTabela je u 3NF ako je u 1NF i u 2NF i ako u njoj ne postoje atributi ne-pri-

marni-ključevi koji su tranzitivno zavisni od primarnog ključa.

Normalizacija tabela iz 2NF u 3NF se vrši uklanjanjem tranzitivnih zavis-nosti, tj. tranzitivno zavisni atributi se izmeštaju u novu tabelu zajedno sa kopijom njihovih determinanti (ključeva).

14.7. Boyce-Codd normalna forma (BCNF)Druga i treća normalna forma eliminišu delimične i tranzitivne zavisnosti

za primarne ključeve, ali one ne razmatraju da li takve zavisnosti postoje i za klju-čeve kandidate, ako ih ima u tabeli. Dakle, i u 3NF mogu da postoje delimične i tranzitivne zavisnosti za ključeve kandidate, pa je stoga promovisana stroža nor-malna forma poznata kao Boyce-Codd normalna forma (BCNF).

BCNF se bazira na funkcionalnim zavisnostima koje uzimaju u obzir sve ključeve kandidate u tabeli, a sadrži i još neka ograničenja u poređenju sa 3NF.


Tabela je u BCNF ako i samo ako je svaka determinanta ključ kandidat.

Da bi se odredilo da li je tabela u BCNF, potrebno je uočiti determi-nante i proveriti da li su sve one ključevi kandidati. Podsetićemo se da je determinanta atribut ili grupa atributa od kojih je neki drugi atribut potpuno funkcionalno zavisan.

Razlika između 3NF i BCNF je u tome što 3NF dozvoljava funkcionalnu zavisnost A�B (B je funkcionalno zavisno od A) ako je B primarni ključ a A nije ključ kandidat, dok BCNF nalaže da A mora biti ključ kandidat. Dakle, BCNF je jača forma od 3NF, pa je svaka tabela koja je u BCNF automatski i u 3NF, a obrat-no ne važi.

Tabela se transformiše u BCNF tako što se vrši njena dekompozicija na dve ili više novih tabela. Međutim, ponekad nije poželjno normalizovati tabelu do BCNF. Naime, može se desiti da se prilikom dekompozicije tabele izgubi jedna ili više funkcionalnih zavisnosti zbog toga što se determinanta i od nje zavisni atri-buti izmeste u različite tabele. U ovakvoj situaciji treba proceniti da li je bolje stati kod 3NF, koja uvek čuva sve funkcionalne zavisnosti. Odluku da li normalizovati tabelu do BCNF ili stati kod 3NF treba doneti na osnovu sledeće analize:

• Da li će značajni podaci biti izgubljeni u slučaju dekompozicije tabele i gubitka jedne ili više funkcionalnih zavisnosti

• Kolika će biti količina redundantnih podataka (podataka koji se ponavlja-ju) u slučaju da se dekompozicija ne izvrši, tj. da se ostane na 3NF.

14.8. Četvrta normalna forma (4NF)Iako BCNF eliminiše sve anomalije koje proističu iz funkcionalnih zavis-

nosti, dalja istraživanja su dovela do uočavanja još jednog tipa zavisnosti koji se naziva zavisnost višestruke vrednosti koji takođe može da prouzrokuje redundat-nost podataka.

14.8.1. Zavisnost višestruke vrednostiPojava zavisnosti višestruke vrednosti u tabeli može da se desi zbog

1NF koja ne dozvoljava da atribut ima više vrednosti, tj. da se sastoji iz više podataka. Zavisnost višestruke vrednosti biće objašnjena na primeru tabele


EkspozituraZaposleniVlasnik iz baze podataka agencije za prodaju i izdavanje nekretnina.

Tabela: EkspozituraZaposleniVlasnik

IdentBrEkspoziture ImeZaposlenog ImeVlasnikaNekretnine

B003 Zoran Petrović Jelena Janković

B003 Miodrag Aleksić Jelena Janković

B003 Zoran Petrović Predrag Stefanović

B003 Miodrag Aleksić Predrag Stefanović

U ovom primeru zaposleni Zoran Petrović i Miodrag Aleksić rade u ekspozi-turi B003, a vlasnici nekretnina Jelena Janković i Predrag Stefanović su registrovani u istoj ekspozituri, dakle B003. Pošto ne postoji direktna veza između zaposlenih i vlasnika u datoj ekspozituri, mora se kreirati zapis za sve kombinacije zaposlenih i vlasnika da bi se obezbedila konzistentnost. Ova situacija predstavlja zavisnost višestruke vrednosti u tabeli EkspozituraZaposleniVlasnik. Drugim rečima, zavis-nost postoji zato što su u tabeli predstavljene dve nezavisne 1:* veze.

Zavisnost višestruke vrednosti predstavlja zavisnost između atributa A, B i C u tabeli, takvu da za svaku vrednost A postoji više vrednosti B i više vrednosti C, pri čemu su vrednosti B i C nezavisne jedna od druge.

14.8.2. Defi nicija četvrte normalne formeTabela je u 4NF ako je u BCNF i ako ne sadrži zavisnosti višestruke vrednosti.

4NF je jača normalna forma od BCNF, jer ne dozvoljava da tabele imaju zavisnost višestruke vrednosti, a samim tim i redundantne podatke (podatke koji se ponavljaju). Normalizacija iz BCNF u 4NF se vrši dekompozicijom tabele i izmeštanjem atributa zajedno sa njihovim determinantama u novu tabelu. Tabe-la EkspozituraZaposleniVlasnik iz prethodnog pasusa se dekomponuje na tabele EkspozituraZaposleni i EkspozituraVlasnik.

IdentBrEkspoziture ImeZaposlenog IdentBrEkspoziture ImeVlasnikaNekretnine

B003 Zoran Petrović B003 Jelena Janković

B003 Miodrag Aleksić B003 Predrag Stefanović

Tabela: EkspozituraZaposleni Tabela: EkspozituraVlasnik


4NF eliminiše redundantnost podataka (podatke koji se ponavljaju) i mogućnost pojave anomalija ažuriranja.

14.9. Peta normalna forma (5NF)Uvek kada se vrši dekompozicija tabele na dve nove, rezultujuće tabele ima-

ju svojstvo poznato kao postojanost spajanja (lossless-join). Ovo svojstvo se odnosi na činjenicu da se tabele nastale dekompozicijom mogu ponovo spojiti u origi-nalnu tabelu. Međutim, postoje slučajevi kada je potrebno izvršiti dekompoziciju originalne tabele na više od dve nove tabele. Iako se u praksi prilično retko sreću, ovakvi slučajevi se rešavaju primenom pete normalne forme (5NF).

14.9.1. Postojanost spajanja (lossless-join)Postojanost spajanja je svojstvo dekompozicije koje omogućava da se, prili-

kom ponovnog spajanja tabela, generišu samo originalni podaci.

Dakle, postojanost spajanja osigurava da se, prilikom ponovnog spajanja dve tabele u onu čijom su dekompozicijom nastale, generišu samo oni podaci koji su postojali u originalnoj tabeli pre dekompozicije, što znači da je zagarantovana potpuna rekonstrukcija originalne tabele.

14.9.2. Defi nicija pete normalne formeTabela je u 5NF ako nema zavisnosti spajanja.

Normalizacija do 5NF se vrši dekompozicijom tabele u kojoj se uoče zavisnosti spajanja na više od dve nove tabele. Važno je napomenuti da će ponovno spajanje bilo koje dve od novonastalih tabela generisati “lažne” podatke, ali će zato ponovno spajanje svih novonastalih tabela verno rekon-struisati originalnu tabelu.

Transakcije 147


Transakcije

Danas je veoma bitan i značajan koncept baze podataka po kome je to, u stvari, zajednički resurs koga istovremeno (konkurentno) koristi veći broj pro-grama, jer se pravi efekti baze podataka ispoljavaju kada se radi u mrežnom okruženju. DBMS je upravo tu da upravlja konkurentnim radom više korisnika, obezbeđuje sinhronizaciju njihovog rada...

Takođe, DBMS ima funkciju da spreči štetne posledice (narušen integritet baze, nekonzistentno stanje baze...) pri promenama (transakcijama) koje se vrše nad bazom podataka u višekorisničkom okruženju, a za to koristi tehnike zaklju-čavanja podataka. Dalje, u tom smislu posebno je značajno upravljanje istovreme-nim (konkurentnim) transakcijama.

Baze podataka kontinuirano skladište informacije koje opisuju trenutno stanje preduzeća. Na primer, baza podataka banke skladišti trenutni bilans na svakom računu deponenta. Kada se u stvarnom svetu dogodi nešto što men-ja stanje preduzeća, mora da se uradi odgovarajuća promena informacija u bazi podataka. Sa dostupnim DBMS-om, ove promene se dešavaju u realnom vremenu, uz pomoć programa koji se nazivaju transakcije koje deluju kada dođe do promena u stvarnom svetu. Na primer, kada klijent stavlja novac u banku (događaj u stvarnom svetu), izvršava se transakcija depozita. Svaka transakcija mora biti uređena tako da održava preciznost veze između stanja baze podataka preduzeća koje je kreira i stvarnog sveta. Pored toga što menja stanje baze podataka, transakcija sama po sebi može da inicira neke događaje u stvarnom svetu. Na primer, izdvojena transakcija kod bankomata, inicira događaj odliva novca.

148 Transakcije

Odobravanje kreditne kartice je samo jedan primer transakcije koja može biti sprovedena za vreme npr. godišnjeg odmora u inostranstvu. Pripreme za let uključuju transakciju sa bazom podataka za rezervaciju karata, prolazom kroz pasošku kontrolu na aerodrom, uključujemo i transakciju sa bazom podataka imigracione službe, a sa prijavljivanjem u hotelu uključili smo i transakciju sa hotelskom bazom podataka za rezervacije soba. Čak i telefonski poziv koji se oba-vi iz telefonske sobe uključuje transakciju sa hotelskom bazom podataka zajedno sa međunarodnim prenosnikom koji uspostavlja vezu. Drugi primeri transakcija koje se redovno sprovode u svakodnevnom životu, uključuju i bankomate, skener sistem u supermarketu, prijave na univerzitetima i sl.

U većini aplikacija baze podataka se koriste kako bi se modelovalo stan-je nekog stvarnog preduzeća. U takvim aplikacijama transakcija predstavlja program koji posreduje sa bazom podataka, tako da podržava slaganje stanja preduzeća i stanja baze podataka. Praktično rečeno, transakcija ažurira bazu podataka tako da prikazuje događaje koji su se odrazili na stanje stvarnog pre-duzeća. Jedan primer bi bila transakcija polaganja novca u banku. Klijent daje blagajniku novac kao depozit. Transakcijom se ažurira informacija o računu klijenta u BP kako bi se prikazao depozit.

15.1. Defi nicija transakcijeObično se transakcijom naziva niz operacija nad bazom podataka koji

odgovara jednoj logičkoj jedinici posla u realnom sistemu. Važno je istaći da ta logička jedinica posla se izvršava do kraja ili se poništava u celini. Drugim rečima, zahteva se da transakcija bude atomska (nedeljiva) i da sve instrukcije jedne transakcije moraju biti izvršene ili nijedna. U tom smislu, transakcija predstavlja osnovnu programsku jedinicu kojom se obezbeđuje očuvanje kon-zistentnosti baze.

Naravno, u jednom trenutku nad bazom podataka se može izvršavati više transakcija, i imajući u vidu gore rečeno, transakciona obrada označava grupi-sanje izmena sadržaja baze podataka u „paket“ koji se potom obrađuje kao nera-skidiva celina. Obrada se uvek odvija tako da se uspešno izvrše ili sve transakcije, ili nijedna od njih.

Transakcije 149

Transakciona obrada je korisna u aplikacijama u kojima jedna akcija mora da se izvrši u vezi sa jednom ili više drugih akcija. Transakciona obrada je uobi-čajena u bankarskim, računovodstvenim i mnogim drugim aplikacijama.

Na primer, kada u nekoj aplikaciji za bankarsko poslovanje premeštamo iznos sa jednog računa na drugi, ne bismo želeli da stanje na jednom računu povećamo, a da ga pri tom na drugom računu ne smanjimo. Zato ćemo te dve izmene grupisati u jednu transakciju.

Transakciona obrada je izuzetno važna u višekorisničkim aplikacijama. Kada više korisnika istovremeno unosi izmene u bazu podataka, više se ne možemo pouzdati u to da će uvek jedna izmena biti trajno upisana u bazu pre nego što započne naredna, osim ako određenu grupu izmena ne „uokvirimo“ u transakciju. Zbog toga bi u višekorisničkom okruženju trebalo da koristi-mo transakcionu obradu.

15.2. Osobine transakcijaSve transakcije imaju sledeće osobine:• atomnost (atomicity),• konzistentnost (consistency),• izolacija (izolation),• trajnost (durability).

Atomnost podrazumeva skup aktivnosti nad bazom podataka po prin-cipu „sve ili ništa“. Ili su sve aktivnosti uspešno obavljene ili je baza podataka ostala nepromenjena. DBMS, pored atomnosti transakcija, mora da garantuje atomnost svake aktivnosti (pojedinačne operacije). Primetimo da obični pro-grami ne moraju imati osobinu atomnosti. Npr. ako je sistem pao u trenutku dok je program ažurirao neki fajl, kada smo podigli sistem, fajl je ostao delimič-no promenjen. Atomnost izvršenja znači da je svaka transakcija ili potvrđena, ili smo odustali od nje.

Konzistentnost znači da transakcija treba da prevede bazu podataka iz jed-nog u drugo konzistentno stanje. Za vreme obavljanja transakcije konzistentnost baze podataka može da bude narušena. Ukoliko u toku transakcione obrade dođe

150 Transakcije

do greške, podaci moraju biti vraćeni u stanje pre početka transakcije. Transakcij-om se mora pristupati i ažurirati BP tako da sva ograničenja integriteta BP ostanu zaštićena. Svaka realna organizacija je organizovano u odnosu na određena pravi-la koja ograničavaju moguća stanja organizacije.

Npr. broj studenata prijavljenih za nastavu ne može preći broj mes-ta namenjenih za tu nastavu. Kada takvo pravilo postoji, moguća stanja BP su ograničena na isti način. Ograničenja integriteta, u odnosu na pomenuta pravila, potvrđuju da broj registrovanih studenata koji se unosi u polje BP ne sme da pređe vrednost polja BP koja odgovara veličini sale. Dakle, kada se transakcija registra-cije završi, BP mora da zadovolji ovo ograničenje integriteta (pretpostavljajući da je ograničenje zadovoljeno na početku transakcije).

Izolacija znači da kada se dve ili više transakcija izvršavaju istovremeno, njihovi efekti moraju biti međusobno izolovani. Efekti koje izazovu transakci-je koje se obavljaju istovremeno moraju biti jednaki efektima nekog njihovog seriskog (jedna posle druge) izvršenja. Zbog povećanja paralelizma u obradi transakcija dozvoljavaju se različiti nivoi izolovanosti.

Prilikom rasprave o konzistentnosti BP, usredsredili smo se na efekat jedne transakcije. Sledeće što ćemo ispitivati je efekat niza transakcija. Rekli smo da se niz transakcija izvodi sekvencijalno, ili serijski, ako se jedna transakcija niza izvrši pre nego što druga počne. Dobra vest kod serijskog izvršavanja je da ako su sve transakcije konzistentne i baza podataka je inicijalno u konzistentnom stanju. Serijsko izvršavanje čuva konzistentnost. Kada prva transakcija niza započne, BP je u konzistentnom stanju, a s obzirom da je transakcija konzistentna i nakon nje-nog izvršenja BP će biti u konzistentnom stanju. Zbog toga što je BP konzistentna pre početka druge transakcije, i druga će se obaviti korektno.

Serijsko izvršavanje je adekvatno za aplikacije čiji su zahtevi skromni. Međutim, mnoge aplikacije imaju stroge zahteve vremena odziva i pristupa, i često jedini način da se zahtevi zadovolje je konkurentno izvršavanje transacija. Moderni sistemi mogu da istovremeno izvršavaju više od jedne transakcije, a ovaj metod izvršavanja nazivamo konkurentnim. Konkurentno izvršavanje je adekvatno kada se sistemom za obradu transakcija služi više korisnika. U tom slučaju biće dosta aktivnih, delimično završenih transakcija u svakom trenutku. Kada se transakcije izvršavaju konkurentno, konzistentnost svake od njih nije dovoljna da obezbedi da baza posle izvršenja obe transakcije u potpunosti prika-zuje stanje preduzeća.

Transakcije 151

Trajnost znači da kada se transakcija završi (potvrđene promene), njeni efekti ne mogu biti izgubljeni, čak i ako se neposredno po njenom okončanju desi neki ozbiljan otkaz sistema. Ovaj zahtev sistema za obradu transakcija odnosi se na to da se informacije ne izgube. Sistem mora da osigura da transakcija, koja je jednom potvrđena, svoj efekat prenese na BP, pa čak i ako kompjuter, ili medijum na kojem je BP smeštena, iznenada prestane da radi.

Npr. ako ste se uspešno prijavili za kurs, očekujete da sistem zapamti vašu registraciju pa čak i ako posle toga prestane da radi. Možemo da primetimo da obični programi ne moraju imati osobinu trajnosti. Npr. ako se pojave problemi pošto je program izvršio promenu nekog fajla, fajl može biti vraćen u stanje pre izvršene promene.

15.3. COMMIT i ROLLBACKObezbeđenje ACID (akronim od reči Atomicity, Consistency, Isolati-

on, Durability) osobina transakcije se radi upotrebom određenih metoda i instrukcija:

• transakcija počinje sa BEGIN TRANSACTION,• završava se sa COMMIT, čime se potvrđuju promene u bazi podataka

ako su sve instrukcije uspešno izvršene,• završava se sa ROLLBACK, ako sve instrukcije nisu uspešno završene.

U stvari, postupak transakcije počinje pozivanjem metode BeginTrans, čime se označava početak niza operacija koje čine jednu logičku jedinicu. Metoda CommitTrans preuzima sve izmene načinjene od poslednjeg mesta na kome je bila pozvana metoda BeginTrans i upisuje ih na disk. Metoda RollbackTrans deluje na suprotan način od CommitTrans – ona poništava sve izmene i vraća stanje kakvo je bilo pre poslednjeg poziva metode CommitTrans.

SUBP inicira iz bilo kog razloga ROLLBACK instrukciju, ako dođe do neplaniranog završetka transakcije.

S obzirom da jedan program može predstavljati kolekciju transakcija, trans-akcije mogu biti i ugnježdene. U tom slučaju, COMMIT instrukcija se izvršava od najnižeg do najvišeg nivoa, a dovoljno je da se ROLLBACK pojavi samo na jednom mestu i poništavaju se promene svih transakcija.

152 Transakcije

SUBP poseduje i održava dnevnik transakcija (tj. dnevnik aktivnosti, log file). Za svaku transakciju i za svaki objekat baze podataka koji je ona ažurirala čuva se:

• vrednost pre ažuriranja (before-image)• vrednost posle ažuriranja (aft er-image)

Na naredbu Rollback, SUBP koristi vrednosti pre za datu transakciju. Pre Commit naredbe sistem prvo upisuje vrednosti pre i posle u log fajl. Ako se preki-ne Commit naredba, mogu se pročitati vrednosti posle sa log fajla, što omogućava očuvanje konzistentnog stanja.

15.4. Konkurentno izvršavanje transakcijaNad modernim bazama podataka transakcije se ne obavljaju u izolovanosti

već konkurentno. Više transakcija mogu istovremeno zahtevati iste resurse, isti zapis baze podataka, itd. U takvim situacijama otvara se mogućnost da nekontro-lisan međusobni uticaj transakcija dovede do nekonzistentnog stanja.

Već je nagovešteno da je jedan od zahteva SUBP da upravlja konkurentnim radom više korisnika, obezbeđuje sinhronizaciju njihovog rada... a sve u cilju sprečavanja štetnih posledica pri promenama koje se vrše nad bazom podataka u višekorisničkom okruženju.

Komponente SUBP koje učestvuju u ovom procesu su:• Planer (Scheduler),• Menadžer transakcija (Transaction manager).

Planer vodi računa o redosledu akcija kod više konkurentnih transakcija. Ako čitanje ili upisivanje može da naruši integritet baze podataka, zahtev se ili vremenski odlaže ili se poništava cela transakcija.

Menadžer transakcija upravlja celokupnim izvršenjem transakcija.

Idealan slučaj izvršavanja transakcija je serijsko izvršavanje. Posledica je korektan rezultat. Serijsko izvršavanje transakcija, u stvari, znači da:

• nema preplitanja transakcija,• prvo se završi jedna, zatim druga...

Transakcije 153

Konkurentno izvršavanje transakcija je serijabilno (linearno) ako daje isti rezultat kao i serijsko izvršavanje svih transakcija.

Interesantno je da kada se koriste transakcije, povećava se stepen integriteta izmena koje korisnik unosi, ali se smanjuje konkurentnost, odnosno mogućnost da pomoću date aplikacije veći broj korisnika istovremeno menja podatke, jer ima više zapisa koji su zaključani duže vreme.

Slika 15.1. – Paralelno i serijsko izvršavanje transakcija

15.5. Protokol zaključavanjaVelika je verovatnoća da, ako nema ograničenja, izvršavanje transakcija neće

biti serijabilno, a provera serijabilnosti se teško može obaviti u realnom vremenu. Zato se vrši jedan način ograničavanja, tj. zaključavanje i otključavanje podataka.

U stvari, mehanizam zaključavanja (locking) predstavlja upravo nasilno ostvarivanje serijabilnosti. Transakcija zaključava objekat baze podataka kome je pristupila, čime je onemogućeno drugim transakcijama da nekorektno operišu.

Postoje dva osnovna nivoa zaključavanja, na nivou stranice i na nivou zapisa. Zaključavanje na nivou stranice je u stvari zaključavanje čitave stra-nice sa zapisima, a ne zaključavanje samo pojedinih zapisa, što je slučaj sa

154 Transakcije

zaključavanjem na nivou zapisa. To znači da, na primer, kada se primenjuje zaključavanje na nivou zapisa, više korisnika može istovremeno da ažurira zapise u istoj tabeli, nasuprot slučaju kada bi bila zaključana cela tabela sa svim zapisima u njoj (na primer, verzije Accessa pre Accessa 2000 nisu omo-gućavale pravo zaključavanje na nivou zapisa).

Zaključavanje na nivou zapisa obezbeđuje znatno bolje mogućnosti višeko-risničkog pristupa podacima. Međutim, treba voditi računa da to ne znači uvek i bolje performanse. Kada se istovremeno ažurira veliki broj zapisa, zaključavanje na nivou stranice može da obezbedi bolje performanse. Ipak, u većini slučajeva, bolje mogućnosti višekorisničkog pristupa podacima, nadoknađuju nešto slabije performanse.

Postoje dva osnovna pristupa u strategiji zaključavanja objekata baze podataka, odakle se izdvajaju dve vrste zaključavanja:

• Ekskluzivno (exclusive lock ili write lock) ili pesimističko – XL• Deljivo (shared lock ili read lock) ili optimističko – SL

Ekskluzivno zaključavanje znači da u svakom datom trenutku samo jedan korisnik može da menja objekat baze podataka. Drugim rečima, ako jedna trans-akcija postavi XL katanac na objekat baze podataka to znači da ne može ni jedna druga transakcija da postavi katanac, i ne može se postaviti ni jedan drugi katanac. U slučaju ako se primenjuje zaključavanje na nivou stranice, to je veliki problem, jer u svakom trenutku samo jedan korisnik može da ažurira bilo koji zapis koji se nalazi na zaključanoj stranici.

Deljivo zaključavanje omogućava da više korisnika istovremeno ažurira iste zapise uz manji broj sukoba oko zaključavanja zapisa. Drugim rečima, ako jed-na transakcija postavi SL katanac na objekat baze podataka to znači da druga transakcija može da postavi SL katanac na isti objekat, i ni jedna druga ne može da postavi XL katanac na taj objekat. Međutim, time se povećava rizik nastajanja sukoba pri upisivanju podataka. Sukob pri upisivanju nastaje kada:

1. prvi korisnik počinje da ažurira objekat baze podataka.2. drugi korisnik upisuje u bazu podataka izmene objekta koje je on uneo.3. prvi korisnik pokuša da u tom trenutku upiše svoje izmene.

Sukob pri upisivanju je štetan, jer on znači da prvi korisnik ažurira drugačiji objekat od onoga sa kojim je počeo da radi.

Transakcije 155

Verovatno je u izboru vrste zaključavanja prihvatljivije ekskluzivno zaklju-čavanje, da bi se izbegli sukobi pri upisivanju. Međutim, uvek treba imati na umu korisnike koji duže vreme zaključavaju objekte baze podataka. U tom slučaju bi bilo dobro razmotriti upotrebu deljivog zaključavanja. Ovaj problem delimično može biti rešen i upotrebom ekskluzivnog zaključavanja sa vremenskim ogra-ničavanjem. Na primer, nekom obrascu se može dodati mogućnost vremenskog ograničavanja tako da izmene koje korisnik nije snimio posle deset minuta auto-matski bivaju poništene.

Protokol zaključavanja obuhvata sledeća pravila:1. Transakcija koja čita neki objekat baze podataka mora da postavi SL na

taj objekat2. Transakcija koja želi da ažurira neki objekat mora da postavi XL. Ako je

ta transakcija prethodno postavila SL treba da ga promeni u XL3. Ako transakcija nije postavila „katanac“, zato što je to pre uradila neka

druga, prelazi u stanje čekanja4. Transakcija oslobađa XL i SL na kraju, sa COMMIT ili ROLLBACK

naredbom

Oba katanca XL i SL se postavljaju implicitno.

15.6. Oporavak baze podatakaOporavak baze podataka (RECOVERY) predstavlja proces vraćanja baze

podataka u korektno stanje. Sasvim je realno, i dešava se, da usled otkaza sistema mora da se uradi oporavak baze podataka. Uzroci otkaza mogu biti različiti: greš-ke u programiranju, greške u operativnom sistemu, nestanak napajanja...

Proces oporavka se zasniva na redudansi podataka, tj. postojanje rezervnih kopija, koje mogu da se čuvaju na disku, traci... Tako, u slučaju otkaza sistema, oštećena baza podataka se rekonstruiše u ispravno stanje na osnovu poslednje kopije, a nekonzistentno stanje se rešava tako što se poništavaju nekonzistentne promene, a transakcije se ponavljaju.

Trajnost podrazumeva da nijedna promena u bazi podataka koju je napra-vila započeta transakcija, ne sme biti izgubljena. Iz tog razloga, a pošto hard disk

156 Transakcije

može da zakaže, baza podataka se mora čuvati na različitim hard diskovima. Jed-nostavan primer postizanja trajnosti jeste čuvanje različitih kopija baze podataka na različitim diskovima (koji se, po mogućstvu, napajaju iz različitih izvora ener-gije). Pošto je istovremeni pad oba diska malo verovatan, velika je verovatnoća da će barem jedna kopija hard diska biti uvek dostupna. Duplikat, ili disk imidž, podržava ovakav pristup. Slika hard-diska (duplikat – mirrored disk) je sistem čuvanja po kome, kad god aplikacija zahteva da disk izvrši operaciju upisa, sistem simultano beleži istu informaciju na dva različita diska. Tako je prvi disk identič-na kopija, ili disk imidž, onog drugog.

U transakcijama koje obrađuju aplikacije, sistem disk imidža može da dostigne izuzetnu dostupnost sistema. Ukoliko jedan disk imidž padne, sis-tem može da nastavi dalje koristeći drugi, bez usporavanja ili zaustavljanja. Kada se zameni disk koji je zakazao, sistem mora da ponovo sinhronizuje oba. Nasuprot tome, kada se trajnost postiže samo pomoću LOG fajla (dnevni-ka), proces oporavka nakon pada hard diska može trajati znatno duže, a u toku tog perioda sistem je nedostupan korisnicima. Ipak, treba podsetiti da čak i kada transakcija u procesu koristi disk imidž, i dalje se mora koristiti dnevnik kako bi se postigla atomičnost – na primer, da bi se poništila trans-akcija nakon pada.

Baze podataka i aplikacije 157


Baze podataka i aplikacije

Nije redak slučaj da proizvođači savremenih sistema za upravljanje bazama podataka (u daljem tekstu SUBP), pored serverske aplikacije (koja omogućava administriranje korisnika, kontrolu pristupa, održavanje referencijalnog integri-teta i konzistentnost podataka BP), najčešće nude i klijentske aplikacije (alate). Primeri ovakvih sistema su Access za Microsoft JetDB i MS SQL, Enerprise DB Designer za MySQL, Oracle, ..

Klijentski programi predstavljaju prijateljska grafička okruženja koja omogućavaju brzo kreiranje upita (QBE3), ugnježdenih procedura, izveštaja i formi za unos podataka. Prethodno navedene prednosti omogućavaju brzu izradu uslužnih aplikacija.

Slika 16.1. – Čvrsta sprega Access-a i MS JetDB

3 QBE – query by example, alat koji omogu�ava kreiranje SQL upita bez potrebe poznavanja sintakse SQL jezika. Primer QBE je Access-ov query designer i query wizard

158 Baze podataka i aplikacije

Nedostatak ovako koncipiranih aplikacija je da su čvrsto povezane za razvojno okruženje (high coupling) i da je komunikacija sa okruženjem (ostalim aplikacijama) obično teško izvodljiva, ili nemoguća (slika 16.1). Posledica ovakvog (jednoslojnog, ili dvoslojnog) modela je da se aplikacije dizajnirane na ovaj način teško održavaju (modifi kacija postojećeg rešenja, unapređenje dodavanjem novih komponenti, ažuriranje novim verzijama serverskih i klijentskih platformi i sl.). Drugu manjkavost predstavlja činjenica da je dizajn korisničkog interfejsa i implementacija logike obrade podataka ograničeno na mogućnosti klijentske tehnologije. Na primer, ne mogu se menjati svi parametri ekranskih formi (izgled kontrola), otežano je ubacivanje kontrola koje eksplicitno nisu ponuđene, oteža-na je izrada novih vrsta kontrola. Programiranje je ograničeno mogućnostima programskih jezika ugrađenog u klijentski alat (npr. Visual Basic for Access ne podržava sve koncepte objektno orjentisanog programiranja).

Pojavom objektno orjentisanog programiranja (u daljem tekstu OOP) omogućeno je potpuno razdvajanje podataka od logike njihove obrade i od inter-fejsa prema korisnicima podataka. Aplikacija se gradi od objekata, od kojih svaki preuzima odgovornost za obavljanje specifi čnih funkcionalnosti aplikacije. Tako se izdvajaju grupe objekata prema funkcionalnosti. Na primer, formira se grupa objekata od kojih se gradi korisnički interfejs, ili, grupa objekata koji ostvaruju konekciju sa BP, izvršavaju upite nad bazom i prihvataju rezultate upita. Objekti međusobno komuniciraju preko funkcionalnih poziva, pri čemu fi zički mogu biti razdvojeni (na različitim računarskim platformama), a aplikacija time postaje dis-tribuirana. Ova pojava grupisanja objekata prema osnovnim funkcionalnostima je nazvana raslojavanje aplikacije.

16.1. Slojevita struktura aplikacijaRaslojavanje aplikacije predstavlja odvajanje njenih delova prema funkcio-

nalnosti. U OOP, kao što je već napomenuto, grupišu se objekti srodnih funkcio-nalnosti (u daljem tekstu slojevi). Grupisanjem je postignuto da se komunikacija između slojeva (funkcionalni pozivi) svedu na najmanju moguću meru i time olakša održavanje aplikacije. Promene u funkcionalnosti (programskom kodu) objekata jednog sloja neće imati posledice na objekte u ostalim slojevima, a imaće sporadične efekte čak i za objekte u istom sloju. Jedno od pravila dobrog dizajna aplikacija je da se u između objekata (klasa) u istom sloju postigne visoka kohezija (high cohesion), a slaba sprega između slojeva (low coupling).


16.2. Troslojni model kao osnovni modelOsnovni aplikacioni model je troslojni model, koji nameće dizajnerima i

programerima zahtev da aplikacija ima razdvojene tri celine (Slika 16.2):1. Prezentacioni sloj (presentation layer)2. Sloj poslovne logike (buisness logic layer)3. Sloj podataka (data layer)Nazivi slojeva implicitno otkrivaju njihove funkcionalnosti. Objekti prezen-

tacionog sloja su zapravo objekti korisničkog interfejsa: forme za unos, prome-nu, brisanje i pregled podataka. Obradu podataka vrši sloj poslovne (aplikacione) logike. Ovaj sloj sadrži ključne objekte sistema, koji sinhronizuju procese pre-zentacionog i sloja podataka. Sloj podataka čine objekti koji komuniciraju sa BP, preciznije sistemom sa upravljanje BP.

Slika 16.2. – Troslojni aplikacioni model

Slojevi komuniciraju funkcionalnim pozivima. Pošto su podaci u trosloj-nom modelu dostupni (korisnicima posredstvom interfejsa prezentacionog sloja) preko sloja poslovne logike (indirektno), može se reći da su mogućnosti zaštite integriteta podataka mnogo veće nego kod dvoslojnih aplikacionih modela.

16.3. Višeslojni modeliAplikacije mogu imati više od tri sloja (Slika 16.3). Ova pojava je veza-

na za distribuirane poslovne sisteme, kod kojih podaci mogu biti razdvojeni na


više različitih mesta, i koji sadrže više nivoa obrade. Najčešći primer višeslojnih distribuiranih sistema su Web aplikacije. Kod Web aplikacija, korisniku su vidljive samo Web stranice, isporučene na klijentski pretraživač od strane Web servera i komponovane od različitih sadržaja. Komponente stranice mogu biti kontrole za interakciju sa korisnikom ili veze (linkovi) prema posebnim aplikacijama (modu-lima). Ove soft verske komponente mogu biti ugnježdene na konkretnom serveru, ali isto tako mogu biti distribuirane na različite platforme.

Slika 16.3. – Četvoroslojni aplikacioni model

Distribuiranjem aplikacija vrši se rasterećenje hardverskih (server-skih) platformi i veza (linkova) između korisnika i aplikacija. Pošto se razli-čite grupe funkcionalnosti odvijaju na različitim mestima, distribuiranjem je olakšano upravljanje i održavanje aplikacija. U primeru na prethodnoj slici, prezentacioni sloj je Web pretraživač na klijentskoj platformi, a sloj podataka čine 2 servera BP. Web server je zadužen za isporučivanje zahte-vanih Web stranica klijentima. Takođe odgovoran je za upravljanje korisnič-kom sesijom. Drugi međusloj čine različiti aplikacioni serveri (aplikacije): za servisiranje elektronske pošte, za upload i download fajlova, aplikacioni server koji omogućava dinamičko komponovanje Web stranica i transakci-onu obradu prema BP, itd.


16.4. Aplikacije servisi (nezavisne softverske komponente)Iako su Web aplikacije višeslojne i distribuirane, njene softverske kom-

ponente su i dalje uzajamno zavisne i predstavljaju deo jedne celine. Da bi se omogućilo da softverska komponenta bude dostupna različitim aplikacija-ma, bila je potrebna formalizacija interfejsa koja bi omogućila komuniciranje sa komponentom. Web servisi su zasnovani na tri osnovna standarda: XML 4(za prikazivanje podataka), SOAP 5(za razmenu podataka između davala-ca i korisnika servisa) i, za potrebe opisa servisa, definisan je poseban jezik – WSDL6 i način uspostave veze.

Slika 16.4. – Arhitektura Web servisa

Za postojanje servisa potrebne su 3 komponente: davalac servisa, korisnik servisa i provajder.Davalac Web servisa registruje svoj Web servis kod direkto-rijuma Web servisa (Slika 16.4). Registrovanje bi značilo da se Web servis for-malno opisuje WSDL-om (naziv servisa, lokacija servisa, način pristupa servisa), kako bi korisnici mogli da ga eksploatišu. Registrovanjem Web servisa, davalac ga zapravo publikuje – svoju aplikaciju čini dostupnom za sve zainteresovane korisnike. U ulogama korisnika Web servisa pojavljuju se druge aplikacije koje na taj način proširuju svoje funkcionalnosti koje pružaju krajnjim korisnicima. Što je dokumentacija za API7 kod konvencionalnih aplikacija, to je WSDL opis Web servisa kod njihovih davalaca. Najčešći način razmene podatka između

4 XML – extensible markup language5 SOAP – simple object access protocol6 WSDL – Web Service De� nition Language7 API – Application Programmable Interface


davalaca i korisnika Web servisa je korišćenjem SOAP-a. Format podataka koji se razmenjuju je u XML formatu.

Web servisi predstavljaju tehnologiju budućnosti, jer omogućavaju pove-zivanje različitih aplikacija, tehnologija, postavljenih na različitim platformama. Formalizacija opisa servisa omogućava njihovu mašinsku čitljivost tako da apli-kacije postaju uzajamno kooperativne bez posredovanja čoveka. Web servisi uki-daju i barijere između tzv.desktop i Web aplikacija.

16.5. Specifi čnosti pristupa BP iz različitih aplikacionih slojeva

16.5.1. Pristup podacima iz prezentacionog slojaPrezentacioni sloj sadrži objekte korisničkog interfejsa. Bez obzira da li se

radi o Desktop ili Web aplikacijama, to su uokvireni prozori sa naslovnom linijom i koji sadrže kontrole za interakciju sa korisnikom (Slika 16.5).

Slika 16.5. – Izgled korisničkog interfejsa Desktop aplikacije

Svaka kontrola prezentacionog sloja predstavlja poseban objekat, koji se može dodati prevlačenjem sa palete – tzv. Drag&Drop (ako se koristi vizuelni


alat za dizajn), ili unošenjem programskog koda u datoteku (ako se koristi običan tekstualni editor). Fizički gledano, formiraju se fajlovi (datoteke) određenog tipa, koji sadrže kod koji se kompajlira, linkuje i izvršava, ili se interpretira (od strane računara) generišući pritom korisnički interfejs.

Korisnički interfejsi kod Web aplikacija dizajniraju se u skladu sa ograni-čenjima Web čitača koji se koriste na klijentskoj strani (Internet Explorer, Nets-cape navigator, Modzila i sl). Čitač interpretira HTML skript koji je primljen od strane Web servera i otvara Web stranicu koja u sebi može da sadrži formu sa kontrolama. Ovi interaktivni elementi omogućavaju korisniku unos podataka i akcije slično kao kod desktop aplikacija.

Slika 16.6. – Izgled korisničkog interfejsa Web aplikacije

Izgled i funkcionalnosti interfejsa određeni su odgovarajućim program-skim kodom sadržan u datotekama aplikacija. U ove datoteke mogu da se doda-ju i funkcionalnosti za pristup podacima iz BP. Za slučaj kada se direktne funk-cije za čitanje, ažuriranje i dodavanje podataka iz/u BP defi nišu u fajlovima u kojima se defi niše korisnički interfejs kažemo da predstavlja pristup podacima iz prezentacionog sloja.

Access-ove datoteke predstavljaju najčešći primer pristupa podacima iz prezentacionog sloja. U fajlovima koji imaju mdb ekstenziju integriše se


kompletna BP, sa formama, izveštajima, makroima i modulima - kodiranim procedurama u VBA8 jeziku.

1:Private Sub Form_Close()2:DoCmd.RunSQL “UPDATE KolicineSred SET [KOLIC] =3:Forms![TSredstva]![RecSum] WHERE KolicineSred.ID_BR = 4:Forms![TSredstva]![ID_BR] AND 5:KolicineSred.SifDug=Forms![TSredstva]![SifDug];”6:End Sub

Fragment 1: Pristup tabeli korišćenjem VBA skripta koji sadrži SQL naredbu

Ovakve aplikacije su obično vođene događajima korisničkog interfejsa (Event Driven Applications). Prethodni primer (Fragment 1) predstavlja pro-ceduru koja je vezana za formu (korisn.interfejs) i koja se aktivira na događaj zatvaranja forme. U linijama 2-5 predstavljena je jedna SQL naredba koja ažurira tabelu KolicineSred postavljajući polje KOLIC u zapisu prema uslovima u WHE-RE klauzuli (id broj i šifra dugovanja) na vrednost sadržanu u kontroli RecSum u formi Tsredstva.

Na sličan način funkcioniše pristup podacima iz prezentacionog sloja u Web aplikacijama. Kao što je rečeno, ove aplikacije takođe sadrže forme popunje-ne kontrolama koje omogućavaju unos i pregled podataka.

Fragment 2: Izgled Web stranice Fragment 3: Kod Web stranice iz fragm.2

8 VBA – Visual Basic for Access


Forme u Web aplikacijama predstavljene su stranicama koje su kodirane u HTML jeziku (Fragment 3). Web čitač na klijentskoj mašini interpretira ovaj kod i prikazuje stranicu u svom prozoru (Fragment 2). U gornjem primeru pri-kazane su kontrole za unos teksta (fi rma, adresa,postkod). Kada korisnik unese potrebne podatke, pritiskom na dugme dodaj, pokreće se akcija u zaglavlju stra-nice (lin.1 - Fragment 3).

1: <html>2: <body>3: <%4: set conn=Server.CreateObject(“ADODB.Connection”)5: conn.Provider=”Microsoft .Jet.OLEDB.4.0”6: conn.Open “d:/webdata/partneri.mdb”7: sql=”INSERT INTO kupci (naz_fi rme, adresa, postbroj)”8: sql=sql & “ VALUES “9: sql=sql & “(‘” & Request.Form(“fi rma”) & “’,”10: sql=sql & “’” & Request.Form(“adresa”) & “’,”11: sql=sql & “’” & Request.Form(“postkod”) & “’)”12: on error resume next13: conn.Execute sql,recaff ected14: if err<>0 then15: Response.Write(“Nemate prava na dodavanje podataka!”)16: else 17: Response.Write(“<h3>Klijent “ & Request.Form(“fi rma”) 18: & “ je dodat</h3>”)19: end if20: conn.close21: %>22: </body>23: </html>

Fragment 4: Sadržaj demo_add.jsp

Razlika kod Web aplikacija je što se kod za pristup BP izvršava na Web ser-veru. Podaci koje je korisnik uneo prenose se u vidu HTTP9 zahteva na server, gde se koriste pri izvršavanju fajla demo_add.asp. Navedena datoteka kreirana je u ASP10 tehnologiji i predstavlja samo jednu od velikog broja Web tehnologija koje omogućavaju dinamičko generisanje sadržaja. Ova datoteka (Fragment 4), pored

9 HTTP – Hypertext Transfer Protokol – protokol koji omogu�ava transfer podataka izme�u Web stranica

10 ASP – Active Server Pages, Microsoft tehnologija za generisaje dinami�kih Web stranica


standardnog HTML koda, sadrži i programski kod pisan u nekom od jezika pro-izvedenih u Microsoft -u (C++, C#, VisualBasic), koji je korišćen za unos podata-ka u BP. Nakon uspostave konekcije sa Access-ovom BP partneri.mdb (lin.4-6), komponuje se SQL naredba koja treba da izvrši dodavanje podataka u tabeli kupci koje je korisnik uneo preko prethodne Web stranice (Fragment 2 i 3) (lin.7-11). Izvršenje stringa SQL naredbe vrši se preko objekta konekcije conn (lin.13). Ako je dodavanje zapisa uspešno, server isporučuje klijentskom čitaču zahtevanu stra-nicu s porukom Klijent <naziv> je dodat. Ako dodavanje nije uspelo, prikazaće se poruka Nemate prava na dodavanje podataka.

Osnovna karakteristika skripta koji se koristi u kreiranju Web stranica je da se isti zasniva na tzv. tag-ovima (npr. <html>, ili </body>). Proizvođači framowork -ova za razvoj Web aplikacija nude i tag-ove za komunikaciju sa BP. Na primer za JSP11 postoji biblioteka tag-ova JSTL12, koja sadrži sql tag-ove. Korišćenjem sql tag-ove, postiže se neposrednost i standardni pristup u razmeni podataka aplikacije i BP. Da bi se sql tag-ovi koristili u Web stranicama, potrebno je uključiti biblioteku tagova i izvršiti konekciju prema BP.

1: <sql:query var=”upit1”>2: SELECT * FROM moja_tabela3: </sql:query>4: <c:forEach var=”naziv_polja” items=”${upit1.columnNames}”>5: <th><c:out value=”${naziv_polja}”/></th>6: </c:forEach>7: <c:forEach var=”red” items=”${upit1.rows}”>8: <tr>9: <c:forEach var=”kolona” items=”${red}”>10: <td><c:out value=”${kolona.value}”/></td>11: </c:forEach>12: </tr>13: </c:forEach>

Fragment 5: Korišćenje SQL tag-ova za generisanje upita

U prethodnom primeru (Fragment 5) predstavljen je upit korišćenjem sql tag-a query. Sql tag predstavlja poseban entitet (lin.1-3), koji je imenovan kao upit1. U ovom tagu je ugnježden standardni SQL upit (lin.2). Pošto je upit izvršen,

11 JSP – Java Server Pages, Java tehnologija za generisaje dinami�kih Web stranica12 JSTL – JSP Standard Tag Library


dalje se predstavljaju rezultati upita. U tu svrhu koriste se c tag-ovi iz JSTL. Najpre se formira zaglavlje tabele u koje se smeštaju nazivi kolona (lin.4-6) koji se dobija-ju iz sql tag-a pozivom njegove metode columnNames. Nakon toga se pomoću 2 for petlje, ugnježdene jedna u drugoj (lin.7-13 – spoljnja, lin.9-11- unutrašn-ja), formiraju red po red, korišćenjem sql tag metode rows, a u svakom redu se, korišćenjem sql tag metode value, popunjavaju konkretne vrednosti podataka za svako polje (kolonu).

PHP je Web orijentisan programski jezik, ali i jedna od najmasovnije korišćenih tehnologija za kreiranje Web aplikacija. U početku čist proceduralan jezik, koji jako podseća na C, prerasta sa verzijama 4 i 5 u objektno orjentisan jezik koji se može integrisati sa drugim tehnologijama.

1: mysql_connect(“biblioteka.snemanja.net:3617”,$username,$password);2: @mysql_select_db(“biblioteka”) or die( “Nema konekcije sa BP”);3: $result = mysql_query(“SELECT * FROM knjige”);4: $num = mysql_numrows($result);5: mysql_close();6: $i=0;7: while ($i < $num) {8: $naslov = mysql_result($result,$i,”naslov”);9: $autor = mysql_result($result,$i,”autor”);10: $i++;11:}

Fragment 6: SQL upit kreiran u PHP-u

U prethodnom kodu (Fragment 6) predstavljen je upit pisan u PHP-u. Varijable su označene prefi ksom $ ($result, $num itd.). PHP jezik sadrži iz-uzetno bogatu podršku za MySQL SUBP. Postoji veliki broj ugrađenih funk-cija koje jako ubrzavaju pisanje koda a time i produktivnost izrade aplikacija: mysql_connect – za konekciju na SUBP (lin.1); @mysql_select_db – za izbor BP (lin.2); mysql_query – za izvršenje SQL INSERT/UPDATE/SELECT naredbe (lin.3); mysql_numrows – za dobijanje broja zapisa kao rezultata (lin.4); mys-ql_close – za zatvaranje konekcije sa BP i SUBP (lin.5). Za razliku od ostalih jezika, PHP omogućava pristup podacima u rezultujućem setu nakon raskida konekcije (lin.8,9), tako da je konekcija vremenski minimalna.

Prednosti pristupa podacima u BP iz prezentacionog sloja je jednostavnost i brzina implementacije. On je pogodan za jednostavne aplikacije (sve je na jednom


mestu), kao što su aplikacije za testiranje i isprobavanje. Ovakav pristup je pogo-dan i u slučajevima kada se izvršavaju jednostavne SQL naredbe (naredbe koje ne sadrže ugnježdavanje, ne obuhvataju kombinovane podatke iz više tabela) i kada je ciljni SUBP unapred poznat i nepromenjiv.

Za različite vrste SUBP, pa ček i za različite verzije SUBP od istih proiz-vođača, postoje razlike u sintaksi SQL naredbi. U slučaju promene, ili instalacijom nove verzije SUBP, neretko je potrebno menjati kod SQL naredbi koji se nalazi u objektima korisničkog inerfejsa. Ovo je jedna od ključnih slabosti pristupa poda-cima iz prezentacionog sloja.

Poslovne aplikacije su znatno složenije. Za složenije13 aplikacije, ovakav pristup bi doveo do konfuzije već u procesu implementacije, jer bi se preklapali poslovi dizajnera i programera. Održavanje i upravljanje neraslojenim soft verom je mukotrpno i često ispod očekivanih rezultata.

16.5.2. Pristup podacima iz sloja poslovne logikeOvo je najčešće korišćen pristup kod višeslojnih aplikacija. U sloju poslovne

logike postoje entiteti (klase ili moduli) koji su zaduženi za komunikaciju sa BP. Preostali delovi aplikacije razmenjuju podatke sa BP isključivo preko ovih entite-ta. U OOP, klase koje omogućavaju interakciju sa BP, obično su već dizajnirane i implementirane od strane proizvođača SUBP, ili proizvođača soft verskih alata za razvoj aplikacija. Takve klase su CDatabase, CRecordset klase iz Microsoft (MFC) fondacije klasa, ResultSet, Connection klase u Java-inom paketu java.sql.*. Posao programera je, ili da koristi navedene klase u originalnom obliku, ili da kreira nove klase izvođenjem iz ponuđenih, modifi kujući im funkcionalnosti prema specifi čnim potrebama aplikacije.

U sledećem primeru (Fragment 7), predstavljen je kod pisan u C++ koji koristi CDatabase klasu u osnovnom obliku da bi ostvario konekciju s BP (lin.4 – BP zvana baza) i izvedenu klasu ProizvodiSet iz CRecordset klase za preuziman-je podataka iz tabele proizvoda. Ako je konekcija s BP uspostavljena, dinamički se kreira pSet – objekat klase ProizvodiSet (lin.6). Funkcija Open nasleđena je iz CRecordset klase. Ova funkcija ima opcioni broj argumenata. Jedan od argumena-ta je SQL naredba koja treba da se izvrši u BP. Ako nema argumente, podrazume-va se da se uzima celokupan skup zapisa iz tabele proizvoda.

13 Složenost aplikacije, izme�u ostalog, predstavljena je brojem razli�itih fukcionalnosti koje aplikacija može da obavi


Fragment 7: Korišćenje MFC C++ klasa u komunikaciji s BP

Fragment 8: Korišćenje Java klasa iz paketa java.sql u komunikaciji s BP

Objekat pSet prihvata sve podatke dobijene iz BP. Konkretnim podacima pojedinačnih zapisa se pristupa u cikličnoj strukturi (while petlja, lin.8-12). Poda-ci se dobijaju posredno, preko pSet objekta, koji sadrži podatke koji odgovaraju poljima odgovarajuće tabele. Na primer, podatak m_Naziv u klasi ProizvodiSet (lin.10) odgovara polju naziv u tabeli proizvodi. Nakon preuzimanja podataka jed-nog zapisa, poziva se funkcija MoveNext nasleđena od klase CRecordset, tako da se u sledećoj iteraciji preuzimaju podaci sledećeg zapisa iz tabele. Nakon preuzi-manja podataka, zatvara se i uništava pSet objekat (lin.13,14) i konekcija s bazom (lin.15). Ostale naredbe (lin.17 do kraja) namenjene su za rešavanje grešaka to-kom konekcije s BP.

U sledećem fragmentu (Fragment 8) predstavljeno je korišćenje Java klasa iz paketa java.sql. Nakon instanciranja potrebnih objekata (Connection, ResultSet, ResultSetMetaData, Statement), vrši se povezivanje s bazom (lin.7), a zatim izvr-šenje SQL naredbe za dodavanje novog zapisa u tabelu t_mtutor_groups (lin.8). Nakon toga zatvara se konekcija sa BP, a sve naredbe se obmotavaju u try catch blok radi kontrole greške.


Slika 16.7. – Pristup BP iz klasa poslovne logike

Oba primera (Fragmenti 7 i 8) ukazuju na veoma sličnu metodologiju. Naj-pre se instanciraju potrebni objekti, zatim se uspostavi konekcija s ciljnom BP, obavi se željeni transfer podataka. Pri tome, podaci se uzimaju/menjaju/doda-ju iz/u tabele BP, korišćenjem objekata u sloju poslovne logike. Pre završetka metoda konekcija s BP se zatvara na način predviđen standardnim protokolom, a cela operacija se nadzire korišćenjem try catch blokova za kontrolu neželjenih izuzetaka. Prednost ovakvog pristupa je što se objekti koji razmenjuju podatke sa BP dizajniraju potpuno nezavisno od prezentacionog sloja (Slika 16.7). Ovi objekti (tzv. data brokers) preuzimaju ulogu posrednika između entiteta u BP i ostalih objekata aplikacije.

16.5.3. Pristup iz sloja podataka (poziv ugnježdenih procedura)Pristup podacima u BP iz sloja poslovne logike ima nekoliko nedostataka.

Ovi nedostaci proizilaze iz činjenice da se SQL naredbe (za upite, brisanja, doda-vanja i izmene podataka) nalaze direktno u izvornom kodu aplikacije (zapravo u klasama sloja poslovne logike). Takozvano hardcode-iranje narušava optimizova-nost koda - time i cele aplikacije. Pristup BP iz sloja podataka povećava obim koda,


čime se otežava njegovo ažuriranje. Na primer ako se vrši promena strukture, ili naziva jedne tabele u BP, ovo ažuriranje mora da se izvede u svim SQL naredbama u izvornom kodu, u kojima se referenciraju podaci te tabele. Tranzijentno, apli-kacija mora ponovo da se generiše, instalira i podešava. Kod aplikacija u velikim poslovnim sistemima, ovakav pristup može da stvori mnoge probleme.

Rešenje za ovakav problem je izmeštanje SQL naredbi iz izvornog koda apli-kacije u SUBP. SQL naredbe se ugnježdavaju kao procedure (stored procedure) u ciljnu BP (u jednom SUBP može biti više BP). Većina današnjih SUBP omogućava kreiranje ugnježdenih procedura.

1: CREATE PROCEDURE `spUsedTestSets`(IN u_id INTEGER(11))2: BEGIN3: SELECT * FROM `t_mtutor_used_test_sets` WHERE ( user_id = u_id );4: END;

Fragment 9: Primer defi nisanja ugnježdene procedure

U prethodnom fragmentu (Fragment 9) prikazana je defi nicija 1 ugnježde-ne procedure u SUBP MySQL 5.x. Ugnježdena procedura slična je bilo kojoj funk-ciji, izuzev što ne vraća vrednosti, već sadrži samo parametre. Parametri mogu biti ulazni – označeni službenom rečju IN, i izlazni – označeni službenom rečju OUT. Kod procedura koje vraćaju više zapisa, često se defi nišu samo ulazni para-metri. Umesto izlaznih parametara, rezultati (zapisi) se prihvataju korišćenjem klase koja enkapsulira skup zapisa (npr. ResultSet, ili CRecordset). Pri defi nisanju, procedura se najpre imenuje i deklarišu se njeni parametri (lin.1). Implementa-cija započinje službenom rečju BEGIN, a završava službenom rečju END. Između početka i kraja je telo procedure u vidu SQL izraza koji treba da se izvrši (lin.3). Ulazni prametri procedure se u telu koriste najčešće kao kriterijumi SQL izraza (u_id). Defi nisane procedure se pozivaju iz aplikacije, prosleđivanjem argumena-ta i prihvatanjem rezultata njihovog izvršenja.

U sledećem primeru (Fragment 10) prikazan je način korišćenja ugnje-ždene procedure u Java kodu. Najpre se (lin.1) preko objekta konekcije sa BP (conn) vrši njeno pozivanje (naziv procedure je spUsedTestSets) i preuziman-je od strane objekta aplikacije (cs). Zatim se preko istog objekta prosleđuju parametri (lin.2).

1: cs = conn.prepareCall(“{call spUsedTestSets(?)}”);2: cs.setInt(“user_id”, u_id);3: rs = cs.executeQuery();


4: while( rs.next() ){5: int test_id = rs.getInt(“test_set_id”);6: Date test_dat = rs.getDate(“date”);7: }

Fragment 10: Primer korišćenja ugnježdene procedure

Upit se izvršava eksplicitnim pozivanjem (lin.3). Rezultati upita se prihva-taju u objekat klase Recordset (rs). Kroz cikličnu strukturu (lin.5-7), preuzimaju se pojedinačni podaci iz skupa zapisa dobijenih upitom.

Slika 16.8. – Pristup BP preko ugnježdenih procedura

Korišćenje ugnježdenih procedura smanjuje kompleksnost sloja poslovne logike (Slika 16.8). S druge strane, povećava se kompleksnost BP i opterećuje se SUBP. Posledica toga je da se deo programerskih poslova prebacuje na adminis-tratore BP. Ugnježdavanje procedura ima još jednu značajnu prednost. Procedure se prave za ciljnu vrstu i verziju SUBP. One se testiraju bez potrebe povezivan-ja s bilo kakvom aplikacijom. Na taj način je olakšano održavanje i proširivanje složenih sistema na nivou podataka.


16.6. Tehnologije koje omogućavaju razmenu podataka između BP i aplikacijaODBC (Object Database Connectivity)

ODBC veznik se ostvaruje korišćenjem ODBC driver-a. ODBC driver je sistemski soft verski proizvod specijalne namene. ODBC driver-i su podprogra-mi koji se sami za sebe ne mogu koristiti. Aplikacije mogu pristupati podacima u SUBP preko ODBC veznika koji se defi niše nad specifi čnim ODBC driver-om. Za svaku verziju sistema za upravljanje BP i operativnog sistema dizajni-raju se zasebni ODBC driver-i. To znači da se, na primer ne može koristiti isti ODBC driver za verziju 3 i za verziju 5 SUBP MySQL. Isto tako, ODBC driver za istu verziju SUBP (npr.MySQL v5) ne može se koristiti na različitim platfor-mama (Linux, Windows OS).

Slika 16.9. – Postojeći ODBC veznici u sistemu


Proizvođači OS obično u instalaciji OS nude već niz veznika za njihove SUBP. Na primer, Microsoft uz Windows OS instalira na sistem ODBC veznike za njegove SUBP (Access, SQL server, FoxPro). Spisak veznika je dostupan iz admi-nistratorske konzole Control Panel-a (slika 16.9).

Tehnologija ODBC-a funkcioniše na sledeći način. Najpre se bira odgo-varajući ODBC driver. Nakon toga se bira baza podataka s kojom aplikacija treba da razmenjuje podatke. Pre kreiranja aplikacije potrebnije izvršiti registrovanje BP kojoj će se pristupati posredstvom ODBC veznika (slike 16.10 i 16.11).

Slika 16.10. – Davanje naziva ODBC vezniku

Slika 16.11. – Izbor BP

Registracija je obavezna i obuhvata dodelu naziva ODBC vezniku i označa-vanje BP koja će predstavljati izvor podataka u ODBC vezniku. Naziv ODBC veznika ne mora imati nikakve veze sa stvarnim nazivom BP u SUBP. Nakon ovog kratkog postupka, ODBC veznik je spreman za korišćenje.


Slika 16.12. – Korišćenje ODBC veznika iz C++ aplikacije

U aplikaciji (slika 16.12) se poziva izvor podataka (ODBC veznik) po svom imenu. Dalje se pristupa tabelama u BP preko naziva tabela, poljima u tabelama preko naziva polja. U primeru sa slike naziv ODBC je baza. Tabela kojoj se pristu-pa naziva se Zabeleske, a ID, datum, poruka su polja u tabeli. Komunikacija (preg-ledanje, dodavanje, uklanjanje i editovanje zapisa) vrši se korišćenjem SQL jezika specifi čnog za SUBP koji sadrži BP čije podatke aplikacija koristi.

ADO (ActiveX Data Objects)

ADO – ActiveX Data Objects predstavlja tehnologiju koja omogućava pristup svemu što može da poseduje podatke (e-mailovi, Excel tabele, dato-teke). ADO dakle poseduje mnogo veću fleksibilnost (u odnosu na vrstu iz-vora podataka) nego ODBC veznici. ADO tehnologija je dizajnirana da bol-je podrži savremene zahteve za distribuiranjem različitih vidova multime-dijalnih podataka.


ADO sloj predstavlja nadgradnju nad OLE14 radi uprošćavanja pristupa podacima. Podacima kao što su video, audio klipovi, ilustracije, mnogobrojni različiti formati dokumenata, moguće je prići iz korisničke aplikacije korišćenjem tzv. ActiveX komponenti. Postoji nekoliko vrsta komponenti:

1. Automatizacioni serveri (Automation Servers) i kontroleri – kompo-nente davaoci (serveri) i potražioci servisa (kontroleri); Primer ovakvog pristupa su aplikacije – mail agenti, koje koriste funkcionalnosti Micro-soft Outlook-a; pristup automatizacionim serverima vrši se korišćenjem IDispatch interfejsa.

2. ActiveX Kontrole –kontrole su ekvivalent OLE Controls (datoteke sa ekstenzijom OCX); one su najčešće namenjene proširenju funk-cionalnosti korisničkih interfejsa, npr. omogućavaju prevlačenje, premeštanje grafičkih objekata, tabelarnu prezentaciju podacima iz BP itd.

3. COM Objekti – u Windows operativnim sistemima postoji na stoti-ne ovih objekata; svaki od njih sadrži više specifičnih interfejsa koji-ma se pristupa iz korisničke aplikacije. COM objekti se proizvode za vrlo različite namene, pre svega za korisničke interfejse; najčešće spominjani su renderovanje 3D grafike i promena izgleda korisnič-kog interfejsa.

4. ActiveX Dokumenta –kreiraju se i edituju u ActiveX serverskim aplika-cijama (kao što su MSWord, MSExcel), a prikazuju se u ActiveX kontej-nerskim aplikacijama (npr. Internet Explorer);

5. ActiveX Kontejneri – to su najsloženije ActiveX komponente koje u sebe mogu da prihvate automatizacione servere, kontrole i dokumenta.

Korišćenjem ADO objekata u aplikacijama smanjuje se kompleksnost apli-kacije (broj linija koda napisanih radi ostvarivanja neke funkcionalnosti). Time se smanjuje vreme potrebno za izgradnju aplikacije i povećava produktivnost programiranja.

14 OLE (Object Linking and Embeding) – ova tehnologija je prethodnica ActiveX tehnologiji, i omogu�avala je integraciju podataka razli�itih formata i iz raznorodnih dokumenata u jednom dokument kontejneru. Razlika u odnosu na ActiveX je što je omogu�avala pregled ali ne i editovanje podataka iz drugog izvorišta.


DAO (Data Access Objects)

DAO predstavlja komponentu koja obezbeđuje zajednički interfejs između aplikacija i određenog skladišta podataka (ciljnog SUBP). Mesto koje zauzima DAO u višeslojnoj arhitekturi aplikacija je na granici sloja poslovne logike i sloja podataka (Slika 16.13).

Slika 16.13. – Aplikacije i DAO

DAO omogućava automatizaciju, odnosno potpunu nezavisnost objeka-ta aplikacije od prezentacije podataka u ciljnoj BP. DAO tehnologija izbega-va potrebu registrovanja kao što je to slučaj sa ODBC veznicima. Fokusirana je isključivo na BP kao izvore podataka. Bazi podataka preko DAO objekata pristupa se direktno. DAO objekti u aplikaciji ponašaju se kao klijenti u odno-su na SUBP. Omogućava potpuniju kontrolu i jednostavniji pristup svim enti-tetima u SUBP.

Slika 16.14. – Korišćenje DAO objekata za unos podataka u tabelu u BP


Slika 16.15. – Korišćenje DAO objekata za upit u BP

DAO tehnologija vrši obavijanje aplikacionim objektima svih objekata u SUBP: čitav sistem (SUBP), BP, tabele, polja, indeksi, upiti, korisničke grupe, pojedinačni korisnički nalozi itd. Na taj način izbegava se potreba pristupa nekom posredničkom entitetu (kao što je to ODBC). Unos podataka u tabelu iziskuje sve-ga 6 linija koda (slika 16.14), dok preuzimanje podataka po zadatom kriterijumu zahteva nekoliko linija koda više (slika 16.15).

JDBC (Java Database Connectivity)

U paleti tehnologija koje se koriste za povezivanje aplikacija sa BP izd-vajaju se kao posebna grupa Java tehnologije. Ove tehnologije zasnovane su na specifičnim svojstvima Java programskog jezika. Platformska nezavisnost, orjentisanost prema mrežnom programiranju i Interentu, kao i izgradnji dis-tribuiranih informacionih sistema učinilo je Java-u možda najdominantni-je korišćenim jezikom u izgradnji aplikacija u zadnjim godinama prošlog milenijuma i u ovom milenijumu. Java tehnologije su svugde: od aplikacija za velike poslovne sisteme do mobilnih aplikacija koje same migriraju sa jednog na drugu računarsku platformu (mobilni softverski agenti) ili aplikacija za mobilnu telefoniju.

Dominantna tehnologija za povezivanje Java aplikacija na SUBP je JDBC (slika 16.16). Postoji velika sličnost između ODBC i JDBC konektora. Suštinska razlika je da JDBC konektor ne treba da se registruje na sistem da bi bio ope-rativan i da se konektor pravi prema ciljnom SUBP. JDBC konektor ne koristi resurse OS već resurse Java virtualne mašine (JVM15). Isti JDBC konektor koriste 15 JVM – Java Virtual Machine predstavlja posrednika izme�u platformskog OS i Java

aplikacija


konkurentski različite java aplikacije. Na tržištu se mogu pronaći različiti JDBC konektori za iste SUBP. Najpouzdanije rešenje je korišćenje konektora koji za Java-u nudi proizvođač SUBP.

Slika 16.16. – JDBC tehnologija povezivanja aplikacija i SUBP

Enterprise Java Beans

Enterprise Java Beans (EJB) predstavljaju nadgradnju koja koristi JDBC konektore kombinovane sa drugim Java tehnologijama (npr. RMI, CORBA) u cilju postizanja visoke produktivnosti u izgradnji distribuiranih IS zasnovanih na Java tehnologijama. Postoji 2 vrste EJB objekata: EJB sesije i EJB entiteta. EJB sesije su klijentski orjentisani i traju koliko i sesija između klijentske i server-ske aplikacije (vidi poglavlje 16.3). EJB entiteta predstavlja posrednika između aplikacije i SUBP.

EJB entiteta su perzistentni (postojani) objekti koji predstavljaju pogle-de na željene podatke iz BP. Oni su smešteni u EJB kontejneru (delu serverske


aplikacije) i postojani su čak i ako dođe do pada JVM. Pri ponovnom podizanju sistema dolazi i do njihovog ponovnog instanciranja sa podacima do momenta pada. EJB entiteta interaguju posredstvom JDBC sa SUBP na isti način kao i Java klase koje ne koriste Eneterprise okruženje.

Slika 16.17. – Mesto EJB tehnologije u distribuiranim IS


Motivacija za korišćenje EJB je u mogućnostima kombinovanja različitih tehnologija (RMI, messaging, itd) i jednostavnijeg načina obezbeđivanja boljih performansi sistema (transakciona podrška, perzistentnost podataka).

Pristup bazama podataka iz aplikacija može se rešiti na veliki broj različitih načina. Mnogobrojne tehnologije imaju za cilj da vreme izgradnje složenih poslovnih aplikacija što više skrate, a s druge strane da poboljšaju kvalitet aplikacija u smislu performansi, pouzdanosti, fleksibilnosti i sigur-nosti podataka. U jednostavnijim aplikacijama i u radu sa transparentnijim podacima može se koristiti pristup podacima iz korisničkog interfejsa. Složeni sistemi koji su najčešće i distribuirani zahtevaju da se podacima pristupa iz sloja poslovne logike ili pozivanjem ugnježdenih procedura u SUBP. Platform-ski OS, programski jezik u kome se sistem implementira, korisnički zahtevi u pogledu funkcionalnosti aplikacije, ograničiće dizajnere i programere na izbor konkretne tehnologije za povezivanje aplikacije sa BP. Svaka od predstavljenih tehnologija ima različite prednosti i nedostatke koje implementatori moraju da razumeju kako bi napravili pravi izbor. Dobar izbor tehnologije predstavlja osnovu dobrog početka izgradnje IS.

Dodatak 1. Informacioni sistem kafi ća 183


Dodatak 1.

Informacioni sistem kafi ća

17.1. Korisnički zahtevNapraviti informacioni sistem koji će pratiti rad kafi ća. Potrebno je da IS

vodi evidenciju kataloga, narudžbenica, zaliha, otpremnica, narudžbi, računa, dobavljača, banaka, naloga za uplatu i potvrda o uplati.

Proizvodi se dobijaju od dobavljača. Funkcija uvođenja novih dobavljača treba da omogući uvođenje u evidenciju novih dobavljača sa kojima kafi ć posluje, radi kontakata oko nabavke novih kataloga proizvoda i eventualnih nedoumica ili problema. Preko kataloga se izdaju narudžbenice. Na osnovu narudžbenica se dobijaju otpremnice i fakture.

17.2. SSA – Strukturna Sistem AnalizaPre nego što počnemo da projektujemo informacioni sistem za neki

realni sistem potrebno je da uradimo detaljnu analizu tog sistema. U ovom slučaju kao metod za analizu koristimo Strukturnu sistemsku analizu (SSA) koja nam služi da relativno složen realni sistem prikažemo kao skup jed-nostavnijih podsistema čije funkcionisanje možemo lakše da shvatimo, a samim tim i implementiramo.

184 Dodatak 1. Informacioni sistem kafi ća

17.2.1. Dijagram konteksta

17.2.2. Prvi nivo dekompozicije


17.2.3. Drugi nivo dekompozicije (Nabavka)

17.2.4. Drugi nivo dekompozicije (Prodaja)


17.2.5. Drugi nivo dekompozicije (Uplata banci)

17.3. Rečnik PodatakaPolje Domen Uslov

SifraBanke AutoNumber NotNullNazivBanke Text Adresa Text Telefon Text SifraDobavljaca AutoNumber NotNullTelefonDobavljaca Text AdresaDobavljaca Text ZRDobavljaca Text NazivDobavljaca Text SifraFakture AutoNumber NotNullSifraDobavljaca Number NotNullRokPlacanja Date/Time

Polje Domen UslovIznosFakture Number DatumFakture Date/Time SifraOtpremnice Number BrojKataloga AutoNumber NotNullSifraDobavljaca Number Datum Date/Time SifraNaloga AutoNumber NotNullPrimalac Text SvrhaUplate Text Datum Date/Time Vreme Date/Time ZRPrimaoca Text


Polje Domen UslovSifraBanke Number SifraFakture SifraFakture SifraNarudzbe AutoNumber NotNullBrojStola Number SifraNarudzbenice AutoNumber NotNullDatum Date/Time Potpisol Text SifraDobavljaca Number NotNullSifraOtpremnice AutoNumber NotNullSifraDobavljaca Number NotNullValutaPlacanja Text Datum Date/Time UkupnoZaPlacanje Number Potpisol Text SifraPotvrde AutoNumber NotNullSifraBanke Number NotNullBrojZiroRacuna Text SvrhaPlacanja Text SifraNaloga Number SifraRacuna AutoNumber NotNullSifraNarudzbe Number NotNullVreme Date/Time Datum Date/Time BrojStola Number UkupnaCena Number RedniBroj AutoNumber NotNullBrojKataloga Number NotNullSifraDobavljaca Number NotNullJedinicaMere Text

Polje Domen UslovCena Number SifraArtikla Number RedniBroj AutoNumber NotNullSifraNarudzbe Number NotNullSifraArtikla Number RedniBroj AutoNumber NotNullSifraNarudzbenice Number NotNullKolicina Number Cena Number JedinicaMere Text SifraArtikla Number RedniBroj AutoNumber NotNullSifraOtpremnice Number NotNullSifraDobavljaca Number NotNullCena Number Kolicina Number JedinicaMere Text SifraArtikla Number RedniBroj AutoNumber NotNullSifraRacuna Number NotNullCena Number Kolicina Number SifraArtikla Number SifraArtikla AutoNumber NotNullKolicinaZaliha Number NazivArtikla Text VrstaArtikla Text OpisArtikla Text


17.4. MOV – Model Objekti-Veze

17.4.1. Nabavka


17.4.2. Prodaja

17.4.3. Uplata banci


17.5. Relacioni modelŠeme relacija su sledeće:

17.5.1. Nabavka:• DOBAVLJAC (SifraDobavljaca, TelefonDobavljaca, AdresaDobavljaca,

ZRDobavljaca, NazivDobavljaca)• NARUDZBENICA (SifraNarudzbenice, Datum, Potpisol, SifraDobavljaca)• STAVKA NARUDZBENICE (RedniBroj, SifraNarudzbenice, Kolicina,

Cena, JedinicaMere, SifraArtikla)• ZALIHE (SifraArtikla, KolicinaZaliha, NazivArtikla, VrstaArtikla,

OpisArtikla)• KATALOG (SifraDobavljaca, BrojKataloga, Datum)• STAVKA KATALOGA (SifraDobavljaca, BrojKataloga, RedniBroj, Jedi-

nicaMere, Cena, SifraArtikla)• OTPREMNICA (SifraDobavljaca, SifraOtpremnice, ValutaPlacanja,

Datum, UkupnoZaPlacanje, Potpisol)• STAVKA OTPREMNICE (SifraDobavljaca, SifraOtpremnice, RedniBroj,

Cena, Kolicina, JedinicaMere, SifraArtikla)• FAKTURA (SifraDobavljaca, SifraFakture, RokPlacanja, IznosFakture,

DatumFakture, SifraOtpremnice)

17.5.2. Prodaja:• NARUDZBA (SifraNarudzbe, BrojStola)• STAVKA NARUDZBE (SifraNarudzbe, RedniBroj, SifraArtikla)• RACUN (SifraNarudzbe, SifraRacuna, Vreme, Datum, BrojStola, Ukup-

naCena)• STAVKA RACUNA (RedniBroj, SifraNarudzbe, SifraRacuna, Cena,

Kolicina, SifraArtikla)

17.5.3. Uplata banci:• BANKA (SifraBanke, Ime, Adresa, Telefon)• POTVRDA O UPLATI (SifraPotvrde, SifraBanke, BrojZiroRacuna, Svr-

haPlacanja, SifraNaloga)• NALOG ZA UPLATU (SifraNaloga, Primalac, SvrhaUplate, Datum, Vre-

me, ZRPrimaoca, SifraBanke, SifraFakture)



17.6. Access Tabele


Dodatak 2. Servis za održavanje rada softverskog sistema 195


Dodatak 2.

Servis za održavanje rada

softverskog sistema

18.1. Korisnički zahtevStranka podnosi zahtev za popravku računara. Na osnovu razgovora ili ana-

lize računara isti se prihvata na popravku. Pri prijemu računara stranci se izdaje revers ili potvrda o prijemu.

Vrši se popravka računara (opravka sistema, spašavanje podataka, izrada Back up-a podataka i td.) Po završenoj popravci stranci se izdaje račun koji on plaća i nakon izvršene uplate izdaje se popravljen računar.

Takođe servis nabavlja odgovarajući softver i vodi računa o novim pro-gramima koji se izbacuju na tržište. Softver se nabavlja od specijalizovanih dobavljača.

Razvojno okruženje izabrano za aplikaciju Servis za održavanje Soft verskog Sistema je Access 2003. Korišćeni su tabele, SQL upit i forme.

196 Dodatak 2. Servis za održavanje rada softverskog sistema

18.2. SSA – Strukturna Sistem Analiza


18.2.2. Dekompozicija prvog nivoa


18.2.1. Dekompozicija procesa

Dekompozicija procesa 1 – prijem računara na popravku

Dekompozicija procesa 2 – nabavka soft vera


18.3. Rečnik podatakaDobavljac<SifraDobavljaca,Naziv,Adresa,Telefon,{Program}>

Program<Idprog,naziv,Proizvodjac>

Popravka<IDPopravka,Datum,Opis,{Program},{Uplata},<Stranka>>

Racunar<IDRacunara,Naziv,Opis,{Komponente}>

Komponente<RB,Naziv,Proizvodjac>

Stranka<IDStranke,Ime,Prezime,Adresa,Telefon>

Uplata<IDUplate,datum,Iznos,{Stavkeuplate}>

StavkeUplate<RB,Naziv,Iznos>


18.4. Specifi kacija primitivnog procesaPostoje 2 primitivna procesa:

1. Popravka računara

2. Nabavka soft vera

Proces nabavka soft vera se sastoji od sledećih slučajeva korišćenja

1. Evidentiranje dobavljača SK1

– Naziv: evidentiranje novog dobavljača

– Učesnici: radnik, program

– Preduslov: Sistem je uključen i radnik je ulogovan pod svojom šifrom

– Osnovni scenario SK:

1. Radnik poziva sistem da kreira novog dobavljača

2. Sistem kreira novog dobavljača


3. Sistem prikazuje radniku novog dobavljača

4. Radnik unosi podatke o novom dobavljaču

5. Radnik poziva sistem da uskladišti podatke

6. Sistem skladišti podatke o novom dobavljaču

7. Sistem obaveštava radnika da je skladištenje bilo uspešno

– Alternativni scenariji: 6.1 Ukoliko sistem ne može da uskladišti dobavlja-ča prikazuje poruku radniku

2. Nabavka soft vera SK1

– Naziv: evidentiranje novog programa

– Učesnici: radnik, program

– Preduslov: Sistem je uključen i radnik je ulogovan pod svojom šifrom

– Osnovni scenario SK:

1. Radnik poziva sistem da kreira novi program

2. Sistem kreira novi program

3. Sistem prikazuje radniku novi program

4. Radnik unosi podatke o programu

5. Radnik poziva sistem da uskladišti podatke

6. Sistem skladišti podatke o novom programu


– Alternativni scenariji: 6.1 Ukoliko sistem ne može da uskladišti program prikazuje poruku radniku


18.5. Dijagram dekompozicije


18.6. Model objekti veze


18.7. Relacioni modelDobavljac(SifraDobavljaca#,Naziv,Adresa,Telefon)SeNabavlja(SifraDobavljaca#,IDProg#)Program(Idprog#,naziv,Proizvodjac)SeKoristi(Idprog#,IDPopravka#)Popravka(IDPopravka#,Datum,Opis,IDRacunara#)Racunar(IDRacunara#,Naziv,Opis,IDStranke#)Komponente(Idracunara#,RB#,Naziv,Proizvodjac)Stranka(IDStranke#,Ime,Prezime,Adresa,Telefon)Uplata(IDUplate#,datum,Iznos,Idstranke#)StavkeUplate(IDUplate#,RB#,Naziv,Iznos)

18.8. Opis scenarija korišćenja sistema1. Evidentiranje dobavljača SK1

1. Radnik poziva sistem da kreira novog dobavljača


2. Sistem kreira novog dobavljača3. Sistem prikazuje radniku novog dobavljača

4. Radnik unosi podatke o novom dobavljaču5. Radnik poziva sistem da uskladišti podatke


6. Sistem skladišti podatke o novom dobavljaču


- Alternativni scenariji: 6.1 Ukoliko sistem ne može da uskladišti dobavlja-ča prikazuje poruku radniku

2. Evidentiranje novog programa SK1

1. Radnik poziva sistem da kreira novi program

2. Sistem kreira novi program

3. Sistem prikazuje radniku novi program


4. Radnik unosi podatke o programu5. Radnik poziva sistem da uskladišti podatke

6. Sistem skladišti podatke o novom programu7. Sistem obaveštava radnika da je skladištenje bilo uspešno

- Alternativni scenariji: 6.1 Ukoliko sistem ne može da uskladišti program prikazuje poruku radniku


18.9. Fizičko projektovanje modela podataka – Access tabele


18.10. Strukturna ograničenja i pravila integriteta

Update Dobavljac CASCADES SeNabavlja

Delete Dobavljac CASCADES SeNabavlja

Update Racunar CASCADES Komponente

Delete Racunar CASCADES Komponente


SELECT Dobavljac.Naziv, Program.NazivFROM Program INNER JOIN (Dobavljac INNER JOIN [Se Nabavlja] ON

Dobavljac.[Sifra dobavljaca] = [Se Nabavlja].[Sifra Dobavljaca]) ON Program.[ID Programa] = [Se Nabavlja].IDPrograma;


18.11. Forme za unos podataka




Dodatak 3. Uvoz i distribucija proizvoda bele tehnike 215


Dodatak 3.

Uvoz i distribucija

proizvoda bele tehnike

19.1. Korisnički zahtevFirma “Singidunum Technic” nam se obratila sa zahtevom za izradu i imple-

mentaciju sistema za upravljanje bazom podataka vezane za uvoz i distribuciju pro-izvoda bele tehnike. Uočeno je postojanje funkcija nabavke, prodaje i servisa.

Nabavka prima ponudu stranog dobavljača, koja sadrži spisak artikala i njihove cene. Po zahtevu, dobavljač šalje predračun za određen broj željenih arti-kala, na osnovu kog se pravi narudžbenica. Prema računu koji šalje dobavljač vrši se uplata. Uz pošiljku naručenih artikala prima se otpremnica, za koju se u odelu prijema vezuje odgovarajuća prijemnica.

Prodaja sastavlja različite ponude vezane za određeni broj artikala, koje šalje potencijalnim kupcima. Po prijemu porudžbine, kupcu se šalje račun, a iz magacina, prema nalogu, traženi artikli sa otpremnicom. Uplata kupca vrši se na odgovarajući račun u banci.

U slučaju kvara na nekom od artikala, kupac se obraća odeljenju servi-sa, koji uručuje odgovarajući nalog za rad nekom od ovlašćenih servisera. Po završenom radu, serviser uz nalog o završenom radu šalje i račun na osnovu kog se vrši odgovarajuća uplata.

216 Dodatak 3. Uvoz i distribucija proizvoda bele tehnike

19.2. Strukturna sistemska analiza


Spoljni objekti sa svojim tokovima podataka:Kupac• Ponuda• Porudžbina• Račun prodaje• Otpremnica prodajeDobavljač• Ponuda dobavljača• Narudžbenica• Uplata dobavljaču• Zahtev za predračun• Račun dobavljača• Predračun


Servis• Uplata servisu• Račun servisa• Nalog za rad• Nalog o završenom radu

19.2.2. DTP- prvi nivo dekompozicije

IS Singidunum Technic-a se sastoji od procesa:• Nabavka (od dobavljača)• Prodaja (kupcu)• Servis


Na prvom nivou dekompozicije postoje sledeća skladišta:• Ponude dobavljača• Dobavljači• Artikli• Kupci• Serviseri

19.2.3. Drugi nivo dekompozicije - nabavka


Nabavka se sastoji od sledećih procesa:• Obrada ponude• Naručivanje• Plaćanje• Prijem

Na drugom nivou dekompozicije postoje sledeća skladišta:• Narudžbenice• Predračuni• Dobavljači• Ponude dobavljača• Prijemnice• Računi• Artikli

19.2.4. Drugi nivo dekompozicije – prodaja

Prodaja se sastoji od sledećih procesa:• Obrada porudžbine• Otprema• Naplata

Na drugom nivou dekompozicije postoje sledeća skladišta :• Nalog magacinu


• Kupci• Artikli• Računi• Uplata kupca

19.2.5. Drugi nivo dekompozicije – servis

Servis se sastoji iz sledećih procesa:• Obrada naloga• Obrada računa

Na drugom nivou dekompozicije postoje sledeća skladišta :• Nalozi• Serviseri• Kupci• Artikli


19.3. Dijagram dekompozicije


19.4. Model objekti-vezeMOV Nabavka - podmodel za tok Ponude i Zahteva za predračun

MOV Nabavka - podmodel za tok za tok Predračuna i Narudžbenica

MOV Nabavka - podmodel za tok Računa i Uplate


MOV Nabavka - podmodel za tok Otpremnice i Prijemnice

MOV Prodaja - podmodel za tok Ponude

MOV Prodaja - podmodel za tok Porudžbine i Računa


MOV Prodaja - podmodel za tok Otpremnice i Naloga Magacinu

MOV Servis - podmodel za tok Naloga za rad

PMOV Servis - podmodel za tok Naloga o Završenom Radu, Računa Servisera, Uplate Serviserima


19.5. Relacioni modelNabavka - relacioni model• Dobavljac (#SifDob, ZemljaDob, NazivDob)• Uplata (#SifUpl, DatumUpl, IznosUpl, SifDob, SifRac)• PonudaDob (#SifPon, SifDob)• StavkaPon (#SifPon, #RedniBr, SifArt, NazivArt, CenaArt)• RacunD (#SifRac, SifDob, IznosRac, RokPl, SifUpl)• StavkaRacD (#SifRac, #RedniBr, SifArt, NazivArt, CenaArt, Iznos,

KolArt)• Prijemnica (#SifPrij, DatumPrij, SifOtpr)• StavkaPrij (#SifPrij, #RedniBr, SifArt, NazivArt, KolArt)• Predracun (#SifPred, SifDob, DatumPred)• StavkaPred (#SifPred, #RedniBr, SifArt, NazivArt, CenaArt, Iznos,

KolArt)• Narudzbenica (#SifNar, DatumNar, SifDob)• StavkaNar (#SifNar, #RedniBr, SifArt, NazivArt, KolArt)• Otpremnica (#SifOtpr, DatumOtpr, SifDob, NazivDob, SifPrij)• StavkaOtpr (#SifOtpr, #RedniBr, SifArt, NazivArt, KolArt)• Artikli (#SifArt, NazivArt, CenaArt, KolArt)• ZahtevZaPr (#SifZah, DatumZah, SifDob)• StavkaZahteva(#SifZah, #RedniBr, SifArt, NazivArt, KolArt)

Prodaja - relacioni model• Kupac (#SifKup, NazivKup, SedKup)• Banka (#BrRac, NazivBanke)• RacunP (#SifRP, NazivKup, Iznos, RokUpl, SifPor, BrRac)• StavkaRP (#SifRP, #RedniBr, SifArt, NazivArt, CenaArt, Iznos, KolArt)• OtpremnicaP (#SifOtpr, SifKup, NazivKup, DatumOtpr, SifNal)• StavkaOtprP (#SifOtpr, #RedniBr, SifArt, NazivArt, KolArt)• Porudzbina (#SifPor, SifKup, DatumPor, SifRac)• StavkaPor (#SifPor, #RedniBr, SifArt, NazivArt, KolArt)• NalogMag (#SifNal, SifOtpr)


• StavkaNal (#SifNal, #RedniBr, SifArt, KolArt)• Artikli (#SifArt, NazivArt, CenaArt, KolArt)• Ponuda (#SifPon)• StavkaPonP (#SifPon, #RedniBr, SifArt, NazivArt, CenaArt)

Servis - relacioni model• Servis (#SifSer, NazivSer, SedSer)• Kupac (#SifKup, NazivKup, SedKup)• NalogZaRad (#SifNalog, DatumN, SifSer, NazivSer, SifKup, NazivKup)• StavkaNZR (#SifNalog, #RedniBr, SifArt, NazivArt)• NalogZavR (#SifNZavR, SifSer, NazivSer, DatumNZavR, SifRac)• StavkaNZavR (#SifNZavR, #RedniBr, SifArt, NazivArt, CenaArt)• RacunS (#SifRacS, SifNZavR, NazivSer, Iznos, SifUpl)• UplataS (#SifUpl, SifRac, NazivSer, DatumUpl, IznosUpl)

19.6. Tabele, tipovi podataka



19.7. Ekranske formeGlavni meni:


Nabavka:

Artikli:


Prodaja:

Servis:

Literatura 231

d

Literatura

[1] James L. Johnson, Database: Models, Languages, Design, Oxford University Press, 1997., London.

[2] Michael Kifer, A. Bernstein, P.M. Lewis, Database, Systems, Pearson, Addison Wesley, 2004.

[3] S. Abiteboul, R. Hull, V.Vianu, Fundation of Databases, Addison Wesley, Boston, MA

[4] Branislav Lazarevi�, Z. Marjanovi�, N. Ani�i�, S. Babarogi�, Baze podataka, FON, Beograd, 2003.

[5] Vladimir Blagojevi�, Relacione baze podataka, Klub Nikola Tesla, Beograd, 2001.

[6] Phuong Lien, , Systems Analysis and Design, Tutorial, PPAC-VTVCompany, 2000

[7] Denis & Haley Wixom, Systems Analysis and Design, 2nd Edition, John Wiley & Sons, 2003

[8] Jeffrey A. Hoffer, M.B. Prescott, F.R. McFadden, Modern Database Management, Pearson, Prentice Hall, 2005.

[9] B. Thalheim, Fundamentals of ER Modeling, Springer Verlag, Berlin

[10] Craig S. Mullins, Administracija baza podataka, Kompjuter biblioteka, 2003.

Rečnik pojmova 233

d

Rečnik pojmova

Model procesa vodi projektanta kroz redosled aktivnosti vezanih za pro-jekat i predstavlja život ni ciklus projekta. Istorijski posmatrano, neki modeli pro-cesa su statički, a neki ne dozvoljavaju postojanje kontrolnih tačaka. Dva takva modela procesa su model vodopada i model spirale

Model vodopada. Ovaj model koristi markere kao prelazne i izvršne tačke. Kada koristite model vodopada, treba da obavite svaki skup zadataka u okviru jedne faze pre nego što predete na sledeću fazu. Najbolje je da ovaj model koristite za projekte kod kojih se zahtevi projekta mogu jasno defi nisati i koji u buduć-nosti neće biti podložni izmenama. Pošto model vodopada ima fi ksne prelazne tačke između faza, veoma lako možete da nadgledate raspored i dodeljujete jasna zaduženja i odgovornosti.

Model spirale. Ovaj model se zasniva na stalnoj potrebi za usavršavanjem zahteva i procena projekta. Model spirale je efi kasan kada se koristi za aplikacije koje se brzo razvijaju ili za male projekte. Ovaj pristup može da dovede do uspeš-ne saradnje između razvojnog tima i korisnika zato što je korisnik uključen u sve faze tako što obezbeđuje povratne informacije i daje odobrenja. Međutim, model spirale nema ugrađene jasne kontrolne tačke. To za posledicu može imati haoti-čan razvojni proces.

Microsoft solution framework - MSF model procesa kombinuje najbolje principe modela vodopada i modela spirale. MSF kombinuje planiranje zasnova-no na markerima i predvidljivosti rezultata kod modela vodopada sa Opšte pri-hvaćen ciklus razvoja poslovnih rešenja sastoji se iz nekoliko faza: prikupljanje

234 Rečnik pojmova

zahteva, sistemska analiza, projektovanje sistema, kodiranje, testiranje i implemen-tacija. MSF model procesa se sastoji od pet različitih faza: predviđanje; planiranje, razvoj; stabilizacija, uvođenje.

Faza predviđanja Prva faza procesnog modela MSF. Predviđanje se može defi nisati kao pravljenje grubog opisa ciljeva i ograničenja projekta. U ovoj fazi određujete radni tim i ono što on treba da postigne za naručioca. Svrha faze predviđanja je da napravi zajedničku viziju projekta za sve važne interesne gru-pe u projektu.

Faza planiranja (eng planning phase) Druga faza procesnog modela MSF, tokom koje tim određuje šta će se razvijati i planira kako da napravi poslovno rešenje. Radni tim priprema funkcionalnu specifikaciju, pravi nacrt rešenja i priprema radne planove, procene troškova i rasporede za razne isporučive rezultate. Za vreme faze planiranja prave se kolekcije modela i dokumenata sa zahtevima. Ta kolekcija modela i dokumenata čini funkcionalnu specifikaciju i nacrt rešenja. Za vreme faze planiranja počinjete da se radi na funkcionalnoj specifikaciji rešenja. Tokom faze planiranja postoje tri procesa projektovanja: konceptualno, logičko i fizičko projektovanje. Ova tri procesa se ne odvijaju paralelno. Njihove početne i krajnje tačke su međusobno povezane. Ovi pro-cesi zavise jedan od drugog. Logičko projektovanje zavisi od konceptualnog projektovanja, a fizičko projektovanje zavisi od logičkog projektovanja. Svaka izmena u konceptualnom dizajnu utiče na logički dizajn, što dalje dovodi do izmena u fizičkom dizajnu.

Konceptualno projektovanja Konceptualno projektovanja je proces sakupljanja, analize i postavljanja prioriteta problema i rešenja sa stanovišta posla i korisnika i pravljenje predstave rešenja visokog nivoa. Konceptualno projektovanje se pojavljuje za vreme faze planiranja. Neki od ciljeva pravl-jenja konceptualnog dizajna su: razumevanje poslovnog problema koji treba da se reši, razumevanje poslovnih zahteva i zahteva korisnika i opisivanje ciljnog budućeg stanja posla.

Logičko projektovanje se defi niše kao proces opisivanja rešenja u pogledu njegove organizacije, strukture i interakcije delova rešenja sa stanovišta projektnog tima. Logičko projektovanje: defi niše sastavne delove rešenja, obezbeđuje radni okvir koji sve delove rešenja drži zajedno, ilustruje način na koji se rešenje sas-tavlja i način na koji stupa u interakciju sa korisnicima i drugim rešenjima. Kada

Rečnik pojmova 235

pravi logički dizajn, radni tim uzima u obzir sve zahteve posla, korisnika, sistema i operacija koji utvrđuju potrebu za bezbednošću, vođenjem dnevnika, beleženjem događaja, skalabilnošću, upravljanjem stanjem, rukovanjem greškama, licencira-njem, globalizacijom, arhitekturom aplikacije i integracijom sa drugim sistemima. Rezultati logičkog projektovanja su: logički model objekata; dizajn visokog nivoa za korisnički interfejs; logički model podataka.

Fizičko projektovanje predstavlja poslednji postupak u okviru faze pla-niranja u MSF modelu procesa. Projektni tim prelazi na fizičko projektovanje onda kada se svi članovi slože sa tim da imaju dovoljno informacija na osnovu logičkog dizajna da bi mogli da predu na fizičko projektovanje. Tokom fizič-kog projektovanja, radni tim primenjuje tehnološka razmatranja i ograničenja na konceptualni i logički dizajn. Pošto fizičko projektovanje predstavlja nasta-vak konceptualnog i logičkog projektovanja, njegov uspeh zavisi od tačnosti prethodna dva dizajna. Oslanjanje fizičkog dizajna na konceptualni i logič-ki dizajn obezbeđuje timu mogućnost da završi fizički dizajn koji ispunjava poslovne i korisničke zahteve.

Faza razvoja Treća faza procesnog modela MSF. Za vreme faze razvoja, pro-jektni tim pravi rešenje. Ovaj proces uključuje pravljenje programskog kôda koji implementira rešenja i pravljenje dokumentacije za programskog kôd. Pored razvo-ja programskog kôda, radni tim razvija i infrastrukturu rešenja. Proces razvoja pro-lazi kroz nekoliko faza: pokretanje razvojnog ciklusa, pravljenje prototipa aplikacije, razvijanje komponenata rešenja, izgradnja rešenja, završetak faze razvoja.

Faza stabilizacije Četvrta faza procesnog modela MSF. Za vreme faze stabi-lizacije radni tim obavlja integraciju, učitavanje i beta testiranje poslovnog rešen-ja. Pored toga, tim testira scenarija za uvođenje rešenja. Tim usmerava pažnju na određivanje problema, postavljanje prioriteta i rešavanje problema tako da rešenje može biti pripremljeno za izdavanje. Za vreme ove faze, rešenje prelazi iz stanja u kome su sve karakteristike završene kao što je defi nisano u funkcionalnoj spe-cifi kaciji za ovu verziju, u stanje u kome se ispunjavaju defi nisani nivou kvaliteta. Pored toga, rešenje postaje spremno za uvođenje u posao.

Faza uvođenja Peta faza procesnog modela MSF. Za vreme ove faze, tim uvodi tehnologiju poslovnog rešenja i smešta komponente, stabilizuje uvođenje, prenosi projekat operativcima i podršci i dobija odobrenje projekta od krajnjeg kupca. Nakon uvođenja, radni tim vodi pregled projekta i nadzire zadovoljstvo naručioca projektom.

236 Rečnik pojmova

Sakupljanje i analiza informacija su postupci koje obavljate u okviru Microsoft Solutions Framework (MSF) modela procesa. Postoje različite katego-rije informacija koje treba sakupiti, postoje različiti izvori informacija i različite tehnike za njihovo sakupljanje.

Kategorije informacija Organizaciona arhitektura je prikaz projekta - dinamičkog sistema - u jednom trenutku vremena. Organizaciona arhitektura posla usklađuje grupe i procese informacionih tehnologija sa ciljevima posla. Da bismo sakupili informacije o organizacionoj arhitekturi, potrebno je da se koriste četiri opisne kategorije modela organizacione arhitekture kako bismo te informacije vodili i klasifi kovali. Te kategorije su: posao, aplikacije, opera-cije i tehnologija.

Tehnike za sakupljanje informacija Postoji šest osnovnih tehnika koje mogu da se koriste za sakupljanje informacija: posmatranje iz senke, intervjuisan-je; ciljne grupe; ankete; instrukcije korisnika, pravljenje prototipova.

Izvori informacija Postoje različiti tipovi informacija koje se mogu saku-pite o nekom poslu. Te informacije se mogu pronaći u različitim oblicima. Broj i raznovrsnost izvora informacija zavise od veličine posla. Neki izvori informacija su: artifakti, sistemi, ljudi.

Analiza informacija Procesi sakupljanja i analize informacija su iterativ-ni. Informacije se najpre sakupljaju a zatim analiziraju. Kod pregleda sakupljenih informacija, nesumnjivo se otkrivaju dodatna pitanja. Nove informacije pomažu da se nastavi analiza posla. Ovaj oblik saradnje trajaće tokom čitavog životnog ci-klusa projekta iako se veći deo sakupljanja i analize informacija odvija na početku životnog ciklusa.

Dokument nacrta zahteva Kada je radni tim sakupio informacije, jedan od postupaka u okviru analize je pravljenje dokumenta nacrta zahteva. Ovaj dokument sadrži uvodnu listu zahteva, sastavljenu na osnovu informacija koje je tim sakupio. Osnovna svrha ovog dokumenta je zapisivanje svih mogućih zahteva, čime se obezbeđuje da se dragocene informacije neće izgubiti. Infor-macije koje sakupite iz različitih izvora sadrže zahteve i želje sa poslovnog i korisničkog aspekta. Zahtevi ukazuju na ono šta poslovno rešenje treba da radi kako bi ispunili poslovnu ponudu, a to se izvodi iz poslovnog i korisnič-kog aspekta.

Rečnik pojmova 237

Slučaj korišćenja (eng. Use case) Opis interakcija visokog nivoa između pojedinca i sistema. Slučaj korišćenja označava redosled koraka koje će korisnik preduzimati u scenariju upotrebe.

Scenario upotrebe (eng. Usage scenario) Označava aktivnosti koje obavlja određen tip korisnika i obezbeđuje dodatne informacije o aktivnostima i sekven-cama zadataka koje čine proces.

Interna dokumentacija projektnog tima Nakon sakupljanja informa-cija, kao deo analize, tim pravi nekoliko internih dokumenata koja se obično ne dostavljaju kupcima. Ta dokumenta - katalog učesnika; katalog poslovnih pravila i rečnik - su aktivna dokumenta i preciznije se defi nišu tokom životnog ciklusa projekta.

Unifi ed Modeling Language – UML je standardni jezik modeliranja koji koristite za modeliranje soft verskih sistema različite složenosti. Ti sistemi mogu biti od velikih zajedničkih informacionih sistema do distribuiranih sistema zasno-vanih na Web tehnologiji. UML je razvijen da bi korisnicima obezbedio standard-ni vizuelni jezik modeliranja tako da mogu da razvijaju i razmenjuju značajne modele. UML ne zavisi od konkretnih programskih jezika i razvojnih procesa.

UML prikazi UML omogućuje sistemskim inženjerima da naprave stan-dardni nacrt bilo kog sistema. UML obezbeđuje nekoliko grafi čkih alata koje možete da koristite za vizuelno predstavljanje i razumevanje sistema sa različitih tačaka gledišta. Različiti UML prikazi opisuju nekoliko aspekata soft verskog siste-ma. Prikazi koji se obično koriste su: prikaz korisnika. struktuirani prikaz. prikaz ponašanja. prikaz implementacije. prikaz okruženja.

UML dijagrami Različiti UML prikazi sadrže dijagrame koji obezbeđuju više aspekata rešenja koje se razvija. Nije potrebno razvijati dijagrame za sva-ki sistem koji se pravi. Slično tome, ne koriste se svi dijagram za modeliranje sistema. Pomoću sledećih UML dijagrama mogu se opisati različiti prikazi sis-tema: dijagrami klasa. dijagrami objekata. dijagrami slučajeva korišćenja. dija-grami komponenata. dijagrami uvođenja. dijagrami saradnje. dijagrami toka i dijagrami stanja.

DBMS Baza podataka se defi niše kao skup podataka koji su organizovani na određen način. DBMS Database Management System je sistem koji upravlja bazama podataka.

238 Rečnik pojmova

SQL je skraćenica od Structured Query Language. To je najšire korišćeni programski jezik za komunikaciju sa relacionim bazama podataka. Pomoću ovog programskog jezika mogu da se uređuju, kreiraju, ili brišu baze podataka ili poda-ci u njima. SQL je takođe i ANSI/ISO standard.

Sloj predstavljanja je deo poslovne aplikacije koji obezbeđuje mehanizam za komunikaciju između korisnika i sloja poslovnog servisa sistema. Elementi slo-ja predstavljanja su komponente korisničkog interfejsa, kao na primer Windows ili Web interfejs.

Sloj podataka poslovnog rešenja se sastoji od skladišta podataka i servisa podataka. Skladište podataka najčešće je baza podataka u kojoj su podaci organi-zovani i pohranjeni.

Odlukom Senata Univerziteta “Singidunum”, Beogrаd, broj 636/08 od 12.06.2008, ovaj udžbenik je odobren kao osnovno nastavno sredstvo na studijskim programima koji se realizuju na integrisanim studijama Univerziteta “Singidunum”.

CIP - Каталогизација у публикацијиНародна библиотека Србије, Београд

004.65(075.8)

ВЕИНОВИЋ, Младен, 1962- Uvod u baze podataka / Mladen Veinović, Goran Šimić. - 5. izd. - Beograd : Univerzitet Singidunum, 2010 (Loznica : Mladost grup). - VIII, 238 str. : ilustr. ; 24 cm

Na vrhu nasl. str.: Fakultet za informatiku imenadžment. - Tiraž 870. - Rečnik pojmova: str. 233-238. - Bibliografija: str. 231.

ISBN 978-86-7912-252-01. Шимић, Горан, 1967- [аутор]a) Базе податакаCOBISS.SR-ID 176515596

© 2010.Sva prava zadržana. Ni jedan deo ove publikacije ne može biti reprodukovan u bilo kom vidu i putem bilo kog medija, u delovima ili celini bez prethodne pismene saglasnosti izdavača.

Education

Uvod u baze podataka singidunum