US - Uvod U Baze Podataka

UNIVERZITET SINGIDUNUM
Prof. dr Mladen Veinovi

Doc. dr Goran imi
U VOD U
BA Z E P O DTA K 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 Ljubia Stanojevi
Izdava:
UNIVERZITET SINGIDUNUM
Beograd, Danijelova 32
www.singidunum.ac.rs
Za izdavaa:
Prof. dr Milovan Stanii
Tehnika obrada:
Novak Njegu
Dizajn korica:
Aleksandar Mihjalovi
Godina izdanja:
2010.
Tira:
870 primeraka
tampa:
Mladost Grup
Loznica
ISBN: 978-86-7912-252-0
poglavlje12
Sadraj
Predgovor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1. Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Osnovni koncepti i denicije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Podatak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Informacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Metapodaci - podaci o podacima (metadata) . . . . . . . . . . . . . . 10
2.4. Sistem za upravljanje bazama podataka . . . . . . . . . . . . . . . . . . . 11
3. Klasian sistem zasnovan na datotekama . . . . . . . . . . . . . . . . . . . 13
3.1. Nedostaci sistema zasnovanog na datotekama . . . . . . . . . . . . . 15
4. Pristup zasnovan na bazama podataka . . . . . . . . . . . . . . . . . . . . . 17
4.1. Prednosti pristupa zasnovanog na bazama podataka . . . . . . . . 18
4.2. Trokovi i rizici pristupa zasnovanog na bazama podataka . . 19
4.3. Tipino okruenje baze podataka . . . . . . . . . . . . . . . . . . . . . . . . 21
5.Primene baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Line baze podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Baze podataka za radne grupe . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Baze podataka odeljenja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Baze podataka organizacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5. Internet, Intranet i Extranet baze podataka . . . . . . . . . . . . . . . . 29
Sadraj
III
6. Istorija razvoja baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7. Modelovanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Razvoj konceptualnih modela . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Entiteti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.3. Veze izmeu entiteta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4. Troslojna arhitektura baze podataka . . . . . . . . . . . . . . . . . . . . . . 45
8. Modeli baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1. Hijerarhijski model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2. Mreni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.3. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.4. Objektni model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9. Strukturna sistemska analiza (SSA) . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Funkcionalna dekompozicija . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1.1. Jacksonovi dijagrami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1.2. Pravila u kreiranju Jacksonovih dijagrama . . . . . . . . . . . . 60
9.2. Dijagrami tokova podataka (DTP) . . . . . . . . . . . . . . . . . . . . . . . 62
9.2.1. Kontekstualni dijagrami . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.2. Dijagram toka podataka 0. nivoa . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Kompletan primer dekompozicije kroz DTP . . . . . . . . . . 70
9.3. Renik podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.3.1. Denisanje struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.3.2. Denisanje polja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.3.3. Denisanje domena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
10. Model objekti-veze (MOV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Dijagrami objekti-veze (DOV) . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.2. Objekti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.3. Atributi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.4. Veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.5. Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
11. Relacioni model podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.1. Istorija i razvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.2. Kljuni koncepti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
IV
Sadraj
11.3. Objekti u relacionom modelu podataka . . . . . . . . . . . . . . . . . . 95

11.3.1. ema relacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.3.2. Relacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.3.3. Relaciona baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . 97
11.3.4. Kandidat klju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
11.3.5. Primarni klju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
11.3.6. Spoljni klju. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
11.4. Integritet podataka u relacionom modelu . . . . . . . . . . . . . . . . 99
11.4.1. Korisnika pravila integriteta . . . . . . . . . . . . . . . . . . . . . 100
11.4.2. NULL vrednost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
11.4.3. Opta pravila integriteta . . . . . . . . . . . . . . . . . . . . . . . . . 102
11.4.4. Identikacioni integritet . . . . . . . . . . . . . . . . . . . . . . . . . 102
11.4.5. Referencijalni integritet . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12. Relaciona algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
12.1. Restrikcija - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.2. Projekcija - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.3. Unija -
12.4. Razlika - / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.5. Presek -
12.6. Dekartov proizvod - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.3.1. Spajanje - >< . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
12.6.2. spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
12.6.3. Ekvi spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
12.6.4. Prirodno spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
12.7. Deljenje - /. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13. SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
13.1. Terminologija SQL-a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
13.2. PRAVILA SQL-a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
13.2.1. Pravila za pisanje imena . . . . . . . . . . . . . . . . . . . . . . . . . 121
13.2.2. O naredbama i izrazima . . . . . . . . . . . . . . . . . . . . . . . . . 121
13.2.3. Tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
13.2.4. Denicija atributa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
13.3. Naredbe SQL-a za denisanje . . . . . . . . . . . . . . . . . . . . . . . . . 123
13.3.1. Rad sa tabelama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
13.4. Pogledi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.5. Indeksi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Sadraj
13.6. SELECT upiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

13.6.1. Prost upit nad jednom tabelom: . . . . . . . . . . . . . . . . . . . 127
13.6.2. Prost upit nad jednom tabelom
sa svodnim rezultatom: . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13.6.3. WHERE klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.6.4. ORDER BY klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.6.5. GROUP BY klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.6.6. HAVING klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.6.7. Korienje NULL vrednosti . . . . . . . . . . . . . . . . . . . . . . 131
13.6.8. LIKE klauzula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.7. Naredbe auriranja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.7.1. INSERT naredba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
13.7.2. UPDATE naredba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.7.3. DELETE naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.8. Naredbe za kontrolu prava pristupa . . . . . . . . . . . . . . . . . 134
13.8.1. GRANT naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
13.8.2. REVOKE naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
14. Relacije loe strukture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
14.1. Redundansa (ponavljanje) podataka i
anomalije auriranja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
14.1.1. Anomalije unosa podataka . . . . . . . . . . . . . . . . . . . . . . . 138
14.1.2. Anomalije brisanja podataka . . . . . . . . . . . . . . . . . . . . . 138
14.1.3. Anomalije promene podataka . . . . . . . . . . . . . . . . . . . . 139
14.2. Funkcionalna zavisnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
14.3. Postupak normalizacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
14.4. Prva normalna forma (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . 140
14.5. Druga normalna forma (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . 142
14.5.1. Potpuna funkcionalna zavisnost . . . . . . . . . . . . . . . . . . 142
14.5.2. Denicija druge normalne forme . . . . . . . . . . . . . . . . . 142
14.6. Trea normalna forma (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . 143
14.6.1. Tranzitivna zavisnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
14.6.2. Denicija tree normalne forme . . . . . . . . . . . . . . . . . . 143
14.7. Boyce-Codd normalna forma (BCNF) . . . . . . . . . . . . . . . . . . 143
14.8. etvrta normalna forma (4NF) . . . . . . . . . . . . . . . . . . . . . . . . 144
14.8.1. Zavisnost viestruke vrednosti . . . . . . . . . . . . . . . . . . . . 144
14.8.2. Denicija etvrte normalne forme . . . . . . . . . . . . . . . . . 145
14.9. Peta normalna forma (5NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
14.9.1. Postojanost spajanja (lossless-join) . . . . . . . . . . . . . . . . 146
14.9.2. Denicija pete normalne forme . . . . . . . . . . . . . . . . . . . 146
VI
Sadraj
15. Transakcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

15.1. Denicija transakcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
15.2. Osobine transakcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
15.3. COMMIT i ROLLBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
15.4. Konkurentno izvravanje transakcija . . . . . . . . . . . . . . . . . . . 152
15.5. Protokol zakljuavanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
15.6. Oporavak baze podataka. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
16. Baze podataka i aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
16.1. Slojevita struktura aplikacija . . . . . . . . . . . . . . . . . . . . . . . . . . 158
16.2. Troslojni model kao osnovni model . . . . . . . . . . . . . . . . . . . . 159
16.3. Vieslojni modeli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
16.4. Aplikacije servisi (nezavisne softverske komponente) . . . . . 161
16.5. Specinosti pristupa BP iz
razliitih aplikacionih slojeva . . . . . . . . . . . . . . . . . . . . . . . . . . 162
16.5.1. Pristup podacima iz prezentacionog sloja . . . . . . . . . . 162
16.5.2. Pristup podacima iz sloja poslovne logike . . . . . . . . . . 168
16.5.3. Pristup iz sloja podataka
(poziv ugnjedenih procedura) . . . . . . . . . . . . . . . . . . . 170
16.6. Tehnologije koje omoguavaju razmenu podataka
izmeu BP i aplikacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
17. Dodatak 1. Informacioni sistem kaa . . . . . . . . . . . . . . . . . . .183
17.1. Korisniki zahtev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
17.2. SSA Strukturna Sistem Analiza. . . . . . . . . . . . . . . . . . . . . . . 183
17.2.1. Dijagram konteksta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
17.2.2. Prvi nivo dekompozicije . . . . . . . . . . . . . . . . . . . . . . . . . 184
17.2.3. Drugi nivo dekompozicije (Nabavka) . . . . . . . . . . . . . . 185
17.2.4. Drugi nivo dekompozicije (Prodaja) . . . . . . . . . . . . . . . 185
17.2.5. Drugi nivo dekompozicije (Uplata banci) . . . . . . . . . . 186
17.3. Renik Podataka. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
17.4. MOV Model Objekti-Veze . . . . . . . . . . . . . . . . . . . . . . . . . . 188
17.4.1. Nabavka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
17.4.2. Prodaja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
17.4.3. Uplata banci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
17.5. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
17.5.1. Nabavka: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
17.5.2. Prodaja: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
17.5.3. Uplata banci: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
17.6. Access Tabele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Sadraj
VII
18. Dodatak 2. Servis za odravanje rada softverskog sistema . . .195

18.2. SSA Strukturna Sistem Analiza. . . . . . . . . . . . . . . . . . . . . . . 196
18.2.2. Dekompozicija prvog nivoa . . . . . . . . . . . . . . . . . . . . . . 196
18.2.1. Dekompozicija procesa . . . . . . . . . . . . . . . . . . . . . . . . . . 197
18.3. Renik podataka. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
18.4. Specikacija primitivnog procesa . . . . . . . . . . . . . . . . . . . . . . 199
18.5. Dijagram dekompozicije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
18.6. Model objekti veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
18.7. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
18.8. Opis scenarija korienja sistema . . . . . . . . . . . . . . . . . . . . . . 203
18.9. Fiziko projektovanje modela
podataka Access tabele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
18.10. Strukturna ogranienja i pravila integriteta . . . . . . . . . . . . . 208
18.11. Forme za unos podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
19. Dodatak 3. Uvoz i distribucija proizvoda bele tehnike . . . . . .215
19.2. Strukturna sistemska analiza . . . . . . . . . . . . . . . . . . . . . . . . . . 216
19.2.2. DTP- prvi nivo dekompozicije . . . . . . . . . . . . . . . . . . . . 217
19.2.3. Drugi nivo dekompozicije - nabavka . . . . . . . . . . . . . . 218
19.2.4. Drugi nivo dekompozicije prodaja . . . . . . . . . . . . . . . 219
19.2.5. Drugi nivo dekompozicije servis . . . . . . . . . . . . . . . . 220
19.3. Dijagram dekompozicije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
19.4. Model objekti-veze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
19.5. Relacioni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
19.6. Tabele, tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
19.7. Ekranske forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Renik pojmova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
VIII
Sadraj
poglavlje12
Predgovor
Knjiga Uvod u baze podataka je namenjena studentima Univerziteta Singidunum za pripremu ispita iz predmeta Baze podataka, ali moe biti od koristi i
svima onima koji kroz praksu i teoriju savladavaju baze podataka. Nastala je kao
rezultat viegodinjeg rada na Fakultetu za nansijski menadment i osiguranje i
na Fakultetu za poslovnu informatiku Univerziteta Singidunum. U toku izlaganja materije autori se nisu vezivali za konkretan softverski sistem za upravljanje
bazama podataka, ve su nastojali da na jednom mestu prikau sve koncepte
u bazama podataka u skladu sa savremenim kretanjima u ovoj oblasti. Dominantno je razmatran relacioni model podataka koji jeste osnova za najvei broj
poslovnih aplikacija.
Knjiga je podeljena u nekoliko delova. Na poetku se iznose osnovni koncepti i denicije koje se koriste u bazama podataka. italac se polako vodi od
klasinih sistema za rad sa podacima, koji su zasnovani na programskim jezicima
i datotekama, ka pravim bazama podataka koje se zasnivaju na sistemu za upravljanje bazama podataka. U nastavku se razmatra modelovanje i uvode razliiti
modeli podataka, onako kako su se istorijski pojavljivali. Baze podataka ne postoje same za sebe. One su osnova informacionih sistema, kako velikih tako i malih
organizacija, a projektuju se sa ciljem dobijanja pravovremenih informacija za
donoenje odluka. Zbog toga je posebna panja posveena strukturnoj sistemskoj
analizi, kao poetnom koraku u projektovanju baza podataka. Detaljno je razmotren relacioni model podataka, a u okviru njega posebna panja je posveena integritetskim komponentama, koje omoguavaju odravanje konzistentnosti jedne
baze podataka. U nastavku je ukratko razmatrana relaciona algebra kao osnova za upitne jezike, a zatim su prikazane mogunosti ANSI SQL jezika za rad sa
Predgovor
relacionim bazama podataka. Na primerima relacija loe strukture diskutovani su

karakteristini problemi koji se odnose na anomalije auriranja, a zatim je objanjen postupak normalizacije ovakvih relacija. Danas se baze podataka uglavnom
koriste u mrenom okruenju, gde se vie transakcija konkurentno izvrava nad
istom bazom podataka. Diskutovani su mehanizmi koji omoguavaju nesmetan
paralelan rad vie transakcija. Na kraju su prikazane razliite tehnike povezivanja
baza podataka i aplikacija. Posebno se razmatra raslojavanje aplikacija ime se
postie vea funkcionalnost samih aplikacija i lake se zadovoljavaju naknadni
zahtevi korisnika.
U dodatku su dati primeri razvoja baza podataka u Access-u za tri razliita
sluaja iz prakse, koji mogu da poslue studentima, kao i diplomiranim inenjerima i ekonomistima za razvoj sopstvenih aplikacija. Zahvaljujemo se svim studentima 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 matematikim aparatom niti konkretnim softverskim alatima, a sve
u cilju to jasnijeg predstavljanja baza podataka. Poto je ovo prvo izdanje knjige,
svi saveti i eventualne primedbe na tekst su dobrodoli.
Beograd, mart 2007. godine
Predgovor
Autori
Poglavlje 1.
Uvod
Baze podataka se koriste za prikupljanje, uvanje i manipulaciju podacima
na osnovu kojih se dobijaju nove informacije u razliitim organizacijama, kao
to su poslovni sistemi, zdravstvo, kolstvo, vladine institucije itd. Svakodnevno
ih koriste pojedinci putem linih raunara, radne grupe putem mrenih servera
i svi zaposleni putem aplikacija koje se nalaze u poslovnim sistemima. Bazama
podataka takoe pristupaju kupci i drugi udaljeni korisnici korienjem razliitih
tehnologija kao to su govorni automati, web itai (browser-i), digitalni telefoni i sl. Zbog velike konkurencije u svim oblastima poslovanja, moe se oekivati
da tehnologija baza podataka dobije jo vei znaaj. Menaderi trae nain da iz
baze podataka bre dou do novih saznanja kako bi bili u prednosti u odnosu na
svoju konkurenciju. Na primer, detaljna baza podataka o prodaji se moe iskoristiti kako bi se saznalo koji kupci kupuju koje proizvode, to se koristi kao osnova za reklamu i marketinku kampanju. Organizacije mogu da ukljue u svoje
baze podataka procedure koje se zovu okidai - trigeri (alerts) koji upozoravaju o
moguim vanrednim dogaajima (kao to su predstojei nedostatak zaliha neke
robe ili ansa za prodaju dodatne koliine robe) i na osnovu kojih mogu nastati
odgovarajue reakcije. Mnoge organizacije danas prave posebne baze podataka
koje se zovu skladita podataka (data werehouses) koje slue za aplikacije za
podrku u odluivanju.
Izuavanje baza podataka i sistema za upravljanje bazama podataka jesu
osnova za izuavanje informacionih sistema. Strunjak za informacione sisteme
mora biti spreman da analizira potrebe preduzea i da dizajnira i implementira
baze podataka u okviru razvoja informacionog sistema jedne organizacije. Takoe,
mora biti spreman da se konsultuje sa krajnim korisnicima i da im pokae kako
Uvod
se korienjem baza podataka moe imati bolja podrka za odluivanje, ime

se stvara prednost nad konkurencijom. iroko rasprostranjeno korienje baza
podataka vezanih za Internet sajtove, koji vraaju dinamike informacije korisnicima web sajta, zahteva od projektanta da razume ne samo kako da povee bazu
podataka sa sajtom ve i kako da je obezbedi tako da se njenom sadraju moe
pristupiti ali ne i izmeniti od strane spoljnih korisnika.
Postoji puno naina kako se moe denisati baza podataka. U osnovi to je
skup podataka koji su organizovani prema potrebama korisnika, koji se odravaju i koji se koriste za dobijanje informacija. Moderne baze podataka su uvaju
na raunaru, ali to nije bitno za samu deniciju. Na primer, adrese poznanika i
prijatelja, kolekcija lmova na CD-ovima, telefonski imenik itd. su takoe baze
podataka (mada ih veina ljudi tako ne zove). Meutim, smetanje baze podataka
na raunar omoguava laku i bru obradu podataka i dobijanje eljene informacije. Karakteristian je primer sa telefonskim imenikom koji se nalazi na papiru.
Jednostavno je pronai telefonski broj eljene osobe, ali je znatno tee pronai ime
osobe na osnovu telefonskog broja. Ako je telefonski imenik vei (vie smetenih
podataka) prethodni problem se dodatno uslonjava. Raunarski zasnovane baze
podataka omoguavaju jednostavno i brzo dobijanje informacija. Pored osnovnih informacija iz odgovarajue baze podataka se mogu dobiti i posebne informacije. Na primeru telefonskog imenika mogu se izlistati podaci za sve osobe po
imenu npr. Marko, mogu se izlistati sve osobe kojima telefonski broj poinje npr.
sa 2, osobe kojima se telefonski broj zavrava sa 45 i jo mnogo toga.
Na razvoj baza podataka presudno je uticao razvoj raunara, raunarskih
mrea, kao i klijent/server obrade. Istraivanje, projektovanje i upotreba baza
podataka su vrlo brzo pokazali niz svojih dobrih strana kao to su: smanjeni trokovi odravanja; smanjena potreba za mrenim resursima; poboljan integritet
podataka; donoenje ispravnih odluka na osnovu objektivnih informacija, bra
reakcija na tritu, itd.
Baza podataka smetena u raunaru, predstavljena je nizom bita, organizovanih u bajtove, a sa vie bajtova u odgovarajuem formatu zapisuju se vrednosti
pojedinih podataka i predstavljaju jedno polje baze podataka. Niz polja se organizuje u zapise (rekorde) koji imaju znaenje jer mogu da predstavljaju opis nekog
objekta iz realnog sveta ili neke veze izmeu objekata realnog sveta. Zapisi istog
formata se slau i ine datoteke, koje su ziki zapisane na disku. Baza podataka
obuhvata vie povezanih datoteka i moe biti centralizovana na jednom raunaru
4
Uvod
ili distribuirana na vie meusobno udaljenih raunara. Pored podataka koji su

zapisani u bazi podataka, postoje i posebni podaci kojima se opisuju pojedinane datoteke, njene osobine, karakteristini parametri iz datoteka, uspostavljene
meusobne 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 uitati svi konguracioni podaci odgovarajue baze (self-describing).
NEKADA
DANAS
Slika 1.1. Baze podataka nekada i danas
Uvod
Poglavlje 2.
Osnovni koncepti i definicije

Baza podataka se moe denisati kao organizovani skup logiki povezanih
podataka. Ona moe biti bilo koje veliine i kompleksnosti. Na primer, prodavac
moe da ima malu bazu podataka vezanu za kupce na svom notebook raunaru
koja se sastoji od nekoliko megabajta podataka. Preduzee koje zapoljava hiljadu i vie ljudi moe da ima veoma veliku bazu podataka od nekoliko terabajta
podataka (jedan terabajt = 1012 bajtova) na mainframe kompjuteru na kome se
nalazi aplikacija za podrku odluivanju. Veoma velika skladita podataka imaju vie od petabajta podataka (1 petabajt = 1015 bajtova). U irem smislu, bazu
podataka moemo posmatrati kao integrisani skup podataka o nekom sistemu i
skup postupaka za njihovo odravanje i korienje, organizovan prema potrebama
korisnika. To je dobro struktuirana kolekcija podataka, koja postoji jedno odreeno vreme, koja se odrava i koju koristi vie korisnika ili programa.
2.1. Podatak
Istorijski, pod terminom podatak se podrazumeva injenica o nekom predmetu i/ili dogaaju koja se moe zabeleiti i sauvati na raunaru. 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. Najvaniji
struktuirani podaci su brojevi, karakteri i datumi (vreme). Dananje baze podataka pored struktuiranih podataka sadre i druge vrste podataka kao to su razna
dokumenta, mape, fotograje, zvuk, ak i video zapise. Na primer, u bazi podataka
nekog prodavca mogla bi se nai i slika kupca. Takoe bi se mogao nai zvuni ili video zapis poslednjeg razgovora sa kupcem. Ova vrsta podatka se naziva
nestruktuirani podatak ili multimedijalni podatak. Multimedijalni podaci se najee mogu nai na web serverima i u Internet bazama podataka.
Danas se podatak denie kao sauvana reprezentacija predmeta i/ili
dogaaja koja ima smisla i vanosti za korisnika baze podataka. Ova denicija
ukljuuje i struktuirane i nestruktuirane podatke. esto se u okviru jedne baze
podataka mogu nai kombinovani struktuirani i nestruktuirani podaci kako bi
se stvorilo multimedijalno okruenje. Na primer, automehaniarska radnja moe
kombinovati struktuirane podatke (koji opisuju klijenta i njegova kola) sa multimedijalnim podacima (slika automobila i skenirana kopija osiguranja).
Pod podatkom se podrazumeva injenica prihvaena kao takva tj. kakva
jeste. Podatak sam po sebi nema znaenje, tek kada se interpretira nekom vrstom
sistema za obradu podataka poprima znaenje i postaje informacija. Tipino, termin podatak se odnosi na ono to je u bazi podatak. Dakle, podatak je sirova
injenica - neobraena informacija. Raunar vri obradu podataka, prema zadatom programu, te se na osnovu saznanja sadranih u podacima, a kao rezultat
njihove obrade, stiu nova saznanja - informacije.
2.2. Informacija
Termini podatak i informacija su usko povezani i esto se koriste kao sinonimi. Meutim, korisno je razlikovati termine podatak i informacija. Informaciju
deniemo kao podatak koji je bio obraen na takav nain da se znanje osobe
koja koristi podatak povealo. Na primer, razmotrimo sledei spisak injenica:
Petar Petrovi
1506983710325
Marko Markovi
0211979850123
Janko Jankovi
1112985830456
-----------
-----------
Prikazane injenice po deniciji predstavljaju podatke, ali bi se veina

sloila da su ovi podaci u sadanjoj formi beskorisni. ak iako pretpostavljamo da
se radi o imenima osoba i njihovim matinim brojevima, podaci ostaju beskorisni
jer ne znamo emu slue. Pogledajte ta se dogaa kada stavimo ove iste podatke
u kontekst, kao to je pokazano na slici 2.1. Dodavanjem jo nekoliko dodatnih
8
podataka i njihovim ureivanjem, prepoznajemo spisak upisanih studenata. Na

ovaj nain se dolazi do informacije koja je korisna npr. upravi fakulteta, profesorima, studentskoj slubi 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 nain da se iz podataka dobiju informacije je da se podaci sumiraju
ili na neki drugi nain obrade i prezentuju. Na primer, na slici 2.2 se vide sumirani
podaci o upisu studenata prezentirani u vidu grake informacije. Ova informacija se moe iskoristiti kao osnova za odluivanje o dodavanju novih predavanja ili o zapoljavanju novog nastavnog kadra. Moderne baze podataka vrlo esto
sadre i podatke i informacije. Podaci se esto obrauju i uvaju u obraenoj formi i slue za pomo pri donoenju odluka, a takvim podacima (informacijama)
se najbre pristupa.
Slika 2.2. Graki prikaz podataka iz BP - informacija o upisu

Podaci obraeni tako da dobijaju znaenje ine informaciju. Informacija koja

je precizna, relevantna, i dobijena na vreme je klju za donoenje 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 tipina
svojstva podataka su naziv (ime) podatka, denicija, duina (veliina), i dozvoljene vrednosti. Kontekst podataka, koji opisuju metapodaci, podrazumeva izvor
podataka, gde se uvaju podaci,vlasnitvo i korienje.
Tabela 2.1. Primer metapodataka
Naziv
Tip
Duina Min Max Opis
Ime
Text
30
JMBG
Integer 1
Jedinstven matini broj Lina karta
Smer
CHAR
Smer na fakultetu
Studentska sluba
Godina upisa
Studentska sluba
GodUpisa Number
Izvor
Ime i prezime studenta Lina karta
3
2001
Metapodaci opisuju svojstva podatka ali se nalaze odvojeno od tog podatka.

Metapodaci iz tabele1.1 ne prikazuju ni jedan podatak. Oni omoguavaju dizajnerima i korisnicima baza podataka da razumeju koji podaci postoje u bazi, ta oni
10
znae, i koja je razlika izmeu podataka koji na prvi pogled izgledaju isto. Upravljanje metapodacima je veoma bitno jer podaci bez jasnog znaenja mogu biti
zbunjujui, pogreno protumaeni ili puni greaka.
2.4. Sistem za upravljanje bazama podataka

Sistem za upravljanje bazama podataka (DBMS - Data Base Management
System) je softverski sistem koji se koristi za kreiranje, odravanje i manipulisanje podacima, kao i za kontrolu prava pristupa bazi podataka. DBMS omoguava krajnjim korisnicima i programerima da dele podatke, tj. omoguava da se podaci koriste od strane vie aplikacija, a ne da svaka aplikacija ima
svoju kopiju podatka sauvanu u posebnim datotekama. DBMS takoe prua
mogunost kontrole pristupa podacima, osigurava integritet podataka, uspostavlja kontrolu konkurentnosti i vri oporavak baze podataka. Programeri aplikacija za rad sa bazama podataka ne moraju da poznaju detalje o nainu zapisa
baze podataka na disku, ne moraju da formuliu algoritme za e kasan pristup
podacima, niti su optereeni bilo kakvim aspektima oko upravljanja podacima
u bazi podataka.
Danas je veoma bitan i znaajan koncept baze podataka po kome je to, u
stvari, zajedniki resurs koga istovremeno (konkurentno) koristi vei broj programa, jer se pravi efekti baze podataka ispoljavaju kada se radi u mrenom
okruenju. Posmatrajmo bazu podataka jedne banke u kojoj se nalaze rauni
graana. Mogue je da se u istom trenutku na alteru u jednoj ekspozituri podie
novac sa jednog rauna i uplauje na drugi raun, a da se istovremeno u sasvim
drugoj ekspozituri uplauje novac na isti taj raun. Pomenuti DBMS je upravo
tu da upravlja konkurentnim radom vie korisnika i da obezbeuje sinhronizaciju njihovog rada.
Takoe, DBMS ima funkciju da sprei tetne posledice (naruen integritet baze, nekonzistentno stanje baze...) pri promenama (transakcijama) koje
se vre nad bazom podataka u viekorisnikom okruenju. U tu svrhu postoje
razne tehnike kao to su tehnika zakljuavanja podataka, tehnika vremenskog
markiranja itd. Posebno je znaajno upravljanje istovremenim (konkurentnim)
transakcijama. Tanost, zatita i dostupnost baza podataka, kao i korektnost i
performanse transakcija koje pristupaju tim bazama su bitni parametri za uspeh
svakog poslovnog sistema.
11
Termini baza podataka i upravljanje bazom podataka se ponekad meaju. Struno govorei, baza podataka je uvek skup injenica, a ne raunarski
program.
DBMS je uveden kao interfejs izmeu korisnika (korisnikih programa,
aplikacija) i zapisa baze podataka na disku. Korisniki programi ne pristupaju
podacima direktno, ve komuniciraju sa ovim softverom (programom). DBMS
upravlja strukturom baze podataka: denie objekte baze, njihova svojstva (atribute), dozvoljene vrednosti atributa, veze izmeu objekata, ogranienja nad
objektima i meusobnim vezama. Omoguava manipulaciju podacima u bazi:
unoenje, brisanje i izmene, tj. omoguava njeno odravanje. Kontrolie pristup
podacima: ko moe da pristupi podacima, kojim podacima i ta moe sa njima da
radi.. DBMS dozvoljava deljenje BP izmeu vie aplikacija/korisnika i ini upravljanje podacima uspenijim i delotvornijim Uobiajeno je da kada se govori o
softveru za baze podataka, onda se misli upravo na DBMS. DBMS upravlja interakcijom izmeu krajnjih korisnika (aplikacija) i baze podataka. Krajnji korisnici
imaju bolji pristup veem broju bolje organizovanih podataka
Slika 2.3. DBMS je interfejs izmeu (aplikacija) korisnika i

zapisa baze podataka na disku
12
Poglavlje 3.
Klasian sistem zasnovan na

datotekama
Kada su se raunari poeli koristiti za obradu podataka, nisu postojale baze
podataka. Raunari su u to vreme bili znatno slabiji nego dananji personalni
raunari, zauzimali su itavu prostoriju i koristili su se skoro iskljuivo za nauna
izraunavanja. Postepeno su raunari uvoeni u poslovni svet. Da bi bili od koristi za poslovne aplikacije, raunari moraju da skladite, manipuliu, i preuzimaju
velike datoteke podataka. Kako su poslovne aplikacije postajale sve kompleksnije,
postalo je oigledno da klasini sistemi zasnovani na datotekama imaju veliki broj
nedostataka i ogranienja. U veini bitnih poslovnih aplikacija danas se umesto
klasinog sistema zasnovanog na datotekama koriste baze podataka.
Klasian sistem obrade podataka zasnovan na datotekama i programskim
jezicima prikazan je blok emom na sledeoj slici. Programi su direktno povezani sa
datotekama, svaki program mora da poznaje detaljan zapis podataka na disku.
Slika 3.1. Klasian sistem obrade podataka zasnovan na

programskim jezicima i datotekama
Klasian sistem zasnovan na datotekama
13
Da bi objasnili osnovne karakteristike sistema zasnovanog na datotekama, posmatrajmo jednu fabriku sa odreenim proizvodnim programom. Pretpostavimo da su nabavljene raunarske aplikacije za voenje poslovanja ove
fabrike realizovane na klasinim sistemima koji se zasnivaju na datotekama.
Ovaj pristup dizajnu informacionog sistema se fokusira na potrebe za obradom
podataka pojedinanih odeljenja, a ne na potrebe organizacije kao celine. Kada
bi se kod korisnika javila potreba za novim sistemima pisali bi se novi raunarski programi za individualne aplikacije kao to su kontrola proizvoda, prijem
rauna, ili kadrovsko poslovanje. Svaki od programa pravi se tako da odgovara
potrebama odreenog odeljenja ili radne grupe. Prema tome, ne postoji opti
plan, mapa ili model kojim bi se rukovodili za planiranje razvoja sistema. Tri
raunarske aplikacije (A, B i C) pomou kojih se obrauju podaci zapisani u
datotekama su prikazane na slici 3.2. Programima se odravaju tri nezavisna sistema porudbine, naplate i plate. Na slici se takoe vide osnovne datoteke vezane za svaku aplikaciju. Na primer, proces porudbina ima tri datoteke: podaci
o kupcu, podaci o proizvodima, podaci o porudbinama. Neke od datoteka se
ponavljaju u sva tri procesa (redudansa) to je tipino za sistem obrade podataka koji se zasniva na datotekama.
Slika 3.2. Klasina obrada podataka zasnovana na sistemu datoteka

14
3.1. Nedostaci sistema zasnovanog na datotekama

Postoji vie mana koje su tipine za sistem koji je zasnovan na datotekama i
klasinim programskim jezicima. Ove mane za primer prikazan na slici 3.2 ukratko su opisane u nastavku.
Zavisnost izmeu programa i podataka

Opisi datoteka se uvaju u okviru svakog programa koji pristupa toj datoteci. Na primer, u procesu porudbine sa slike 3.2 program A pristupa
datoteci sa podacima o kupcu. Stoga, ovaj program sadri 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 porudbine i u procesu naplate. Pretpostavimo da se veliina polja adresa kupca menja sa
20 karaktera na 30 karaktera. Opis datoteke u svakom programu (moda
ak u svih pet) se mora aurirati. esto je teko i samo lociranje svih programa na koje je uticala ovakva promena. to je jo gore pri auriranju se
esto prave greke.
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 porudbina ima datoteke sa osnovnim podacima o proizvodima dok
proces naplate ima datoteku o cenama proizvoda. Dakle, obe ove datoteke
sadre podatke o istim proizvodima kao to su: cena po jedinici proizvoda,
opis proizvoda, i koliina u skladitu. Zbog nepotrebnih duplikata potreban
je vei prostor za njihovo uvanje kao i vie truda i rada pri njihovom auriranju. Neplanirana redudansa podataka moe da dovede do gubitka podataka. Na primer, isti podaci mogu se voditi pod razliitim imenima atributa u
razliitim dokumentima, ili obrnuto, isto ime se moe koristiti za razliite
vrste podataka.
Ogranienost deljenja podataka

Korienjem klasinog sistema zasnovanog na datotekama, svaki proces
ima svoje datoteke i korisnici nemaju ansu da meusobno dele podatke
sa korisnicima iz drugih procesa. Na slici 3.2 se vidi da radnici u raunovodstvu imaju pristup samo procesu naplate, dok nemaju pristup procesiKlasian sistem zasnovan na datotekama
15
ma porudbina i plata. Menaderi su imali velike probleme pri sastavljanju

izvetaja za koje su im bili potrebni podaci iz razliitih procesa, jer bi se
esto desilo da su dokumenta nekompatibilna i da je potrebno dosta programiranja kako bi se svi ti podaci sakupili u jedan izvetaj. Takoe, dodatni
problem je bio u tome to su se eljeni podaci esto nalazili u razliitim
odeljenjima organizacije.
Dugo vreme za razvoj

Sa klasinim sistemom zasnovanom na datotekama postoji mala ansa za
korienje prethodnih razvojnih dostignua. Svaka nova aplikacija zahteva
od projektanta da krene od nule. Svaki put je neophodno denisati nove
formate i opise podataka i pisati kod za pristup podacima za svaki program.
Ovako veliko potrebno vreme za razvoj nije u skladu sa dananjim poslovnim potrebama, gde je svaki minut bitan da bi se postigao uspeh.
Teko odravanje programa

Skup svih prethodno navedenih nedostataka dovodi do preterane potrebe
za odravanjem programa. ak 80% budeta predvienog za razvoj sistema
zasnovanog na datotekama odlazi na njegovo odravanje. Zbog toga, naravno, ostaje jako malo prostora za razvoj novih aplikacija.
Vano je znati da veina mana klasinog sistema zasnovanog na datotekama, koje smo u prethodnom delu teksta pominjali, mogu isto tako biti ogranienja za bazu podataka, pogotovo ako se ne promeni pristup razvoju baze
podataka. Na primer, ukoliko preduzee razvije nekoliko zasebnih baza podataka (recimo, za svaku radnu jedinicu ili proces po jednu bazu) sa malom ili nikakvom vezom izmeu njih, onda moe doi do bespotrebnog ponavljanja istih
podataka, ogranienja deljenja podataka, produavanja vremena potrebnog za
razvoj i preterane potrebe za odravanjem programa.
16
Poglavlje 4.
Pristup zasnovan na
bazama podataka
Pristup zasnovan na bazama podataka potencira integraciju i deljenje
podataka izmeu svih odeljenja jedne organizacije. Ovaj pristup zahteva potpunu
promenu u nainu razmiljanja, poevi od najvieg nivoa upravljanja. Takva promena naina razmiljanja za veinu organizacija je veoma teka.
Da bi objasnili pristup zasnovan na bazama podataka posmatrajmo prethodno razmatrani zastareli informacioni sistem fabrike koji se klasino zasnivao
na datotekama. Koncept pristupa razvoju informacionog sistema zasnovanog na
bazama podataka prikazan je na slici 4.1. Odmah se moe uoiti da podaci koji
su prethodno uvani u vie razliitih datoteka, sada su integrisani u jedinstvenu
bazu podataka. Takoe, metapodaci koji opisuju ove podatke se nalaze zajedno sa
njima u bazi podataka. Sistem za upravljanje bazama podataka prua mogunost
stvaranja razliitih pogleda na istu bazu podataka (ili baze podataka) za razliite
korisnike u organizaciji. DBMS dozvoljava korisnicima da dele, pretrauju, pristupaju i auriraju integrisanim podacima.
Slika 4.1. Blok ema informacionog sistema zasnovanog na bazama podataka

Pristup zasnovan na bazama podataka
17
4.1. Prednosti pristupa zasnovanog na bazama podataka

Pristup zasnovan na bazama podataka ima mnogo potencionalnih prednosti u odnosu na pristup zasnovan na datotekama. Te potencionalne prednosti
su sledee:
18
Nezavisnost izmeu programa i podataka

Odvajanje metapodataka od aplikacija koje koriste podatke naziva se nezavisnost podataka. Ova osobina kod baza podataka dozvoljava promenu i
prenos podataka organizacije na druge raunarske sisteme bez potrebe za
promenom programa koji obrauje ove podatke.
Minimalna redudansa podataka

Cilj pristupa zasnovanog na bazama podataka je da se podaci koji su se u
prethodnom pristupu uvali odvojeno (i vie puta su zbog toga ponavljani) sada integriu u jedinstvenu logiku strukturu. Svaki podatak se nalazi samo na jednom mestu u bazi podataka. Pristup zasnovan na bazama
podataka ne uklanja redudansu u potpunosti, ali omoguava projektantu
baze podataka da paljivo isplanira vrstu i koliinu redudanse. U nekim
sluajevima je poeljno napraviti ogranienu redudansu kako bi se performanse baze podataka poboljale (npr. bra pretraga).
Poboljana konzistentnost podataka

Eliminisanjem (ili kontrolisanjem) redudanse podataka, u velikoj meri se
smanjuju anse za nekonzistentnou podataka. Na primer, ukoliko je adresa
kupca zapisana na samo jednom mestu ne moe da postoji ne podudaranje
u podacima u bazi podataka. Takoe, auriranje podataka je u velikoj meri
uproeno, kada je svaka vrednost zapisana na samo jednom mestu. Na kraju, uklanjanjem redudanse podataka dolazi do utede memorije.
Poboljana razmena podataka

Baza podataka je dizajnirana kao resurs organizacije koji koriste svi njeni
zaposleni (kojima je ona neophodna u opisu posla). Odreenim internim
i eksternim korisnicima je dozvoljeno korienje baze podataka, i svaki
od njih (bio u pitanju jedan korisnik ili grupa) ima jedan ili vie pogleda
koji mu olakavaju korienje baze podataka. Korisniki pogled je logiki
opis jednog dela baze podataka koji je neophodan korisniku da obavi
neki zadatak.
Poveana produktivnost u razvoju aplikacija

Velika prednost pristupa zasnovanog na bazama podataka je ta to se u
znatnoj meri smanjuju trokovi i vreme potrebno za razvoj novih poslovnih
aplikacija. Postoje dva vana razloga zato se aplikacije baza podataka razvijaju znatno bre nego kod klasinih sistema sa datotekama:
1. Pretpostavljajui da su baza podataka i sve propratne aplikacije ve napravljene i implementirane, programer se moe koncentrisati na odreenu
funkciju koja je neophodna za novu aplikaciju, a ne mora da razmilja o
denisanju podataka ili o detaljima vezanim za implementaciju.
2. DBMS prua veliki broj alata za izvetavanje, kao to su generatori formi
i izvetaja, i jezike uz pomo kojih se automatizuju neke od aktivnosti
kao to su dizajn i implementacija baza podataka.
Smanjena potreba za odravanjem programa

Sauvani podaci se moraju esto menjati iz velikog broja razloga: nove vrste podataka se dodaju, formati podataka se menjaju, i tako dalje. Poznat
primer ovoga problema je ulazak u 2000-tu godinu, kada se sa uobiajenog sistema prikazivanja godina sa dve cifre moralo prei na etiri cifre.
U sistemu obrade datoteka, metapodaci i logika pristupanju podacima se
nalaze u individualnim aplikacionim programima (ovo je zavisnost izmeu
programa i podataka o kojoj je ranije bilo rei). Kao rezultat ovoga, promena formata podataka i metoda pristupanja momentalno dovodi do potrebe
menjanja aplikativnih programa. Kod baza podataka, podaci su znatno vie
nezavisni od aplikativnih programa koji ih koriste. U okviru odreenih granica, moemo da promenimo jednu od stavki, format podataka ili aplikativni program, a da ne moramo da promenimo drugu stavku. Kao rezultat
ovoga, javlja se smanjenje potreba za odravanjem programa.
4.2. Trokovi i rizici pristupa

zasnovanog na bazama podataka
U prethodnom delu teksta navedeno je nekoliko glavnih potencijalnih
prednosti pristupa zasnovanog na bazama podataka. Meutim, kod velikog broja organizacija bilo je razliitih problema kod ostvarenja i iskorienja tih prednosti. Na primer, postizanje nezavisnosti podataka (i stoga, smanjene potrebe
za odravanjem programa) se pokazalo kao teko ostvarivo zbog ogranienja
19
starijih modela baza podataka i softvera za upravljanje bazama podataka. Na sreu, relacioni modeli (kao i noviji objektno-orjentisani modeli) nemaju ovih problema. Drugi razlog za neuspeh da se iskoriste ove prednosti, je loe planiranje
i implementacija baza podataka ak ni najbolji softver za upravljanje bazama
podataka ne moe da prevazie ovakve manjkavosti. Pristup zasnovan na bazama podataka sadri neke dodatne trokove i rizike koji se moraju reavati kada
se sistem pone primenjivati.
20
Novo, obueno osoblje

esto se deava da preduzee, koje se odlui za pristup zasnovan na bazama
podataka, mora da angauje ili obui ljude za projektovanje, implementiranje i odravanje baza podataka, kao i da te ljude ukljui u postojeu radnu
organizaciju. Dalje, zbog estih izmena i brzine razvoja tehnologije, znanje
ovog novog osoblja zahteva stalnu nadgradnju i unapreivanje. Jedino obueno osoblje moe da izvue maksimum korisnosti iz novih tehnologija.
Trokovi i sloenost instaliranja, upravljanja i rada sistema sa bazama

podataka
Viekorisniki sistem za upravljanje bazama podataka je veliki i sloen
softver koji u startu mnogo kota, zahteva obueno osoblje za instaliranje
i rad i ima znaajne godinje trokove za odravanje i tehniku podrku.
Instaliranje ovakvog sistema moe zahtevati nadogradnju hardvera. Stalne
obuke se podrazumevaju, da bi se mogle pratiti nove verzije i nadogradnje
softvera. Takoe se moe pojaviti potreba za dodatnim i skupljim softverom
za baze podataka radi vee sigurnosti podataka.
Trokovi prilagoavanja (konvertovanja) podataka

Termin nasleeni sistemi se uglavnom koristi kada se govori o starijim aplikacijama u preduzeu koje su bazirane na datotenom pristupu ili starijim
bazama podataka. Trokovi prilagoavanja ovakvih starijih sistema za rad
sa modernim bazama podataka (mereni u novcu, vremenu i zahtevnosti
posla) esto deluju kao velika prepreka za preduzee.
Potreba za izradom sigurnosnih kopija i oporavkom podataka (backup)

Deljena baza podataka preduzea uvek mora biti tana i dostupna. To
zahteva razvijanje i korienje jasnih procedura izrade sigurnosnih kopija
kao i oporavak baze podataka kada neko oteenje nastane. U dananjem
okruenju, gde postoje raznovrsni bezbednosni rizici, reavanje ovog
problema je od izuzetne vanosti. Moderan sistem za upravljanje bazama podataka obino sam obavlja izradu sigurnosnih kopija i oporavak
podataka u sluaju havarija.
Konikti u organizaciji
Deljena baza podataka zahteva saglasnost u vezi sa denicijama i vlasnitvom podataka, kao i utvrenu osobu ili osobe odgovorne za odravanje
podataka. Iskustvo je pokazalo da nesuglasice u pogledu denicija podataka, formata i kodiranja podataka, prava na auriranje deljenih podataka i sl.
su esta i vrlo teka tema za reavanje. Da bi se ovi problemi reili potrebno
je da je organizacija u potpunosti posveena uvoenju/koritenju pristupa
zasnovanog na bazama podataka. Zatim je potreban sposoban administrator baze podataka kao i smislen pristup razvoju baza podataka. Ukoliko podrka i posveenost glavnih menadera za pristup okrenut bazama
podataka izostane, velika je ansa da e krajnji korisnici razviti vei broj
samostalnih baza podataka. Ove baze podataka e teko pruiti prednosti
koje smo prethodno opisali. U krajnosti, one mogu da dovedu do donoenja
loih odluka to naravno ugroava celu organizaciju.
4.3. Tipino okruenje baze podataka

Glavni delovi tipinog okruenja baze podataka i njihove veze su prikazani
na slici 4.2.
1.
Baza podataka Organizovan skup logiki povezanih podataka, obino napravljena da zadovolji potrebe za informacijama vie korisnika u organizaciji.
2.
Metapodaci Centralna baza znanja za sve denicije podataka, njihova
ogranienja, veze izmeu podataka, izgleda ekrana i izvetaja, i drugih sistemskih komponenti.
3.
DBMS Sistem za upravljanje bazama podataka (SUBP). Softverski sistem
koji se koristi za kreiranje, odravanje i kontrolu pristupa korisnika baze
podataka.
4.
Aplikativni programi Raunarski programi koji slue za kreiranje i
odravanje baze podataka i pruaju 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 ziki dizajn baza podataka i za
upravljanje tehnikim problematikama u okruenju baza podataka.
21
6.
7.
8.
9.
Projektanti sistema Osobe kao to su sistemski analitiari i programeri

koji dizajniraju nove aplikativne programe. Projektanti sistema esto koriste
CASE alate za analizu potreba sistema i dizajn programa.
Korisniki interfejs Jezici, meniji, i itd. pomou kojih korisnici koriste
razliite komponente sistema, kao to su CASE alati, aplikativni programi,
DBMS i metapodaci.
Computer-aided softver engineering (CASE) alati Alati koji se koriste za
dizajniranje baza podataka i aplikativnih programa.
Krajnji korisnici Osobe koje dodaju, briu i modikuju/auriraju podatke u bazi podataka i koje zahtevaju ili primaju podatke iz njih. Svaka interakcija izmeu korisnika i baze podataka deava se preko DBMS-a.
Slika 4.2. Komponente okruenja BP

22
Sa unapreenjem softvera, korisniki interfejs postaje sve laki za upotrebu. Primeri za ovakav napredak su sistemi zasnovani na menijima, sistemi sa mogunou pristupa Internetu, i sistemi koji prepoznaju govor (prihvataju govorne komande). Cilj ovih sistema je da to vie krajnjih korisnika
moe da koristi raunar, to znai da korisnici koji nisu raunarski eksperti
mogu sami da naprave izvetaje i koriste jednostavne aplikacije. Naravno, u
ovakvom okruenju administratori baza podataka moraju da obrate panju
na bezbednost baze podataka. Okruenje baze podataka prikazano na slici
4.2 predstavlja integrisani sistem hardvera, softvera i ljudi koji je napravljen
da olaka skladitenje, preuzimanje, i kontrolu izvora informacija i da povea
produktivnost preduzea.
23
Poglavlje 5.
Primene baza podataka

Vrste baza podataka variraju od onih pravljenih za jednog korisnika PC
raunara do baza koje su smetene na glavni raunar (mainframe) i kojima
pristupaju hiljade korisnika. Po broju korisnika koji im pristupaju, baze podataka
se mogu podeliti u vie kategorija: line baze podataka, baze podataka za radne
grupe, baze podataka odeljenja, baze podataka preduzea i Internet, intranet i
ekstranet baze podataka.
5.1. Line baze podataka

Line baze podataka se prave za korienje od strane jednog korisnika i ve
su dugo prisutne u korienju personalnih raunara. Pojavom linih digitalnih
pomonika (PDA), line baze podataka su nale primenu i u nizu mobilnih ureaja koji osim raunarskih imaju i neke druge primene npr. mobilni telefoni, faks
maine, Internet itai. Jednostavne aplikacije sa bazom podataka u kojoj uvaju
informacije i detalje o komunikaciji sa svakim klijentom, mogu da se koriste i sa
raunara i sa linog digitalnog pomonika, kao i da se prebacuju sa jednog na
drugi ureaj radi izrade sigurnosnih kopija (backup) ili zbog zahteva posla. Uzmimo za primer preduzee koje ima odreeni broj prodavaca koji su u kontaktu sa
postojeim i potencijalnim klijentima. Ako svaki prodavac ima jo neke aplikacije,
npr. grake prezentacije, cenovnik sa uslovima prodaje po kojem klijentu moe
ponuditi najpovoljniju kombinaciju proizvoda i koliina za naruivanje, onda bi
mu za takav posao prenosni raunar, zbog svojih performansi i skladinog prostora, mogao biti optimalno reenje. S druge strane, ako prodavac ima samo listu
klijenata i kontakata, njemu bi lini digitalni pomonik i aplikacija koja koristi
malu bazu podataka bili najbolje reenje.
25
Line baze podataka se iroko primenjuju jer esto mogu bitno unaprediti
produktivnost pojedinca. Meutim, one sadre jedan faktor rizika: podatke ovih
baza nije lako deliti sa drugim korisnicima. Na primer, ako bi menader prodaje
eleo celokupan spisak klijenata i kontakata, to se ne bi moglo ni brzo ni lako uraditi uzimanjem podataka iz linih 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, line baze podataka
bi trebalo svesti na korienje pod posebnim okolnostima (npr. u veoma malim
preduzeima) gde je verovatnoa potreba za deljenjem podataka izmeu korisnika izuzetno mala.
5.2. Baze podataka za radne grupe

Radnu grupu ini relativno mali broj ljudi koji sarauju na jednom projektu ili aplikaciji ili na grupi slinih projekata ili aplikacija. Radna grupa obino
sadri desetak ljudi. Oni mogu biti ukljueni u npr. planiranje, projektovanje ili
razvoj novog raunarskog programa. Baza podataka za radne grupe slui za podrku zajednikog rada jedne takve grupe. Uzmimo za primer, radnu grupu koja
pravi i standardne i programe po porudbini, koji se prodaju softverskim kompanijama kao i krajnjim korisnicima.Obino, jedna ili vie 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 omogui da se podaci to lake razmenjuju meu lanovima tima.
Svaki lan radne grupe ima svoj raunar, a raunari su umreeni putem
LAN-a. Baza podataka se nalazi na centralnom raunaru koji se zove server
baze podataka, koji je takoe na mrei. Stoga, svaki lan grupe ima pristup
podacima. Razliiti lanovi grupe (u zavisnosti da li je u pitanju rukovodilac
projekta ili projektant, programer) mogu imati razliita ovlaenja (privilegije), a time i razliite poglede na podatke. Primetiete da je glavna mana
linih baza podataka, teko ostvariva razmena podataka, ovde prevaziena
(barem je razmena podataka u okviru grupe lako ostvariva). Meutim, razmena podataka otvara nova pitanja i probleme koji nisu postojali kod linih
baza podataka. Glavni problemi upravljanja podacima su vezani za njihovu
bezbednost i integritet, s obzirom da vie korisnika moe istovremeno da
obavlja auriranje podataka.
26
5.3. Baze podataka odeljenja

Odeljenje je funkcionalna radna jedinica u okviru organizacije. Tipini primeri odeljenja su: kadrovsko, marketing, proizvodnja, raunovodstvo i sl. Odeljenje je obino vee od radne grupe (nekada se sastoji i do 100 osoba) i odgovorno
je za vei broj razliitih poslova. Baze podataka odeljenja su napravljene da podre
razliite 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, strunu spremu i poslovna zaduenja. Kada su svi relevantni podaci
sauvani u bazi podataka, korisnici mogu da pretrauju bazu podataka u cilju
dobijanja odgovora na pitanja kao to su sledea:
Za odreenu vrstu zanimanja (npr programer) kakve prilike za zaposlenje

trenutno postoje u organizaciji?
Za tu istu vrstu posla koja struna sprema ili vetina je neophodna?
Koje vetine, znanje poseduje odreeni radnik? I obrnuto, koji radnici poseduju odreenu vetinu, znanje?
Koji sve radnici su obavljali odreeni posao u organizaciji? I obrnuto, koje

sve poslove je odreeni radnik obavljao u organizaciji?
Koje sve zaposlene nadgleda odreeni menader?
Tipina pitanja na koja se treba odgovoriti pri pravljenju baze podataka

odeljenja su:
1.
Kako baza podataka i njeno okruenje trebaju da budu organizovani da

bi se ostvarile zadovoljavajue performanse, uzimajui u obzir veliki broj
korisnika i veliki broj transakcija?
2.
Kako na odgovarajui nain obezbediti podatke od nedozvoljenog pristupa

i/ili distribucije?
3.
Koje alate za razvoj baze podataka i aplikacija treba koristiti u sluaju ovako
kompleksnog okruenja?
27
4.
Da li i druga odeljenja koriste iste vrste podataka, i ako je to sluaj, kako se

najbolje moe upravljati podacima po pitanju njihove redudantnosti i konzistentnosti i metapodacima po pitanju njihove konzistentnosti?
5.
Da li su korisnici baze podataka geografski jedni od drugih udaljeni ili je

veliina baze podataka tolika da se podaci moraju uvati na vie raunara,
tako stvarajui distribuirane baze podataka?
6.
Da li se bazi podataka moe pristupati preko Interneta i da li ona treba da

bude ukljuena u intranet organizacije?
5.4. Baze podataka organizacija

Baza podataka organizacije obuhvata itavu organizaciju ili vie njenih odeljenja. Ova vrsta baza podataka je namenjena da podri sve procese organizacije i proces donoenja odluka. Vano je istai da jedna organizacija moe imati vie baza podataka, tako da jedna takva baza podataka ne sadri sve podatke
jedne organizacije. Jedna baza podataka za celu organizaciju srednjih do velikih
dimenzija ne bi bila praktina iz mnogo razloga. Kao prvo zbog razliitih potreba razliitih korisnika, kompleksnosti stvaranja jedinstvenih metapodataka za sve
korisnike baze podataka je ogromna. Baza podataka organizacije prua podrku
za jedan odreeni broj (skup) odeljenja. Tokom poslednje decenije, razvoj baza
podataka organizacije je doveo do dva najvanija oblika:
1.
Enterprise resource planning (ERP) sistem
2.
Implementacija skladita podataka (data werehouses)
ERP sistemi rade sa tekuim podacima organizacije, dok skladita podataka

sakupljaju podatke iz raznih operativnih baza podataka, ukljuujui i line, radnih
grupa, odeljenja i ERP baze podataka. Skladita podataka pruaju mogunost
korisnicima da rade sa prethodnim podacima kako bi pronali obrazce i trendove
dogaaja 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 staraki
domovi. Svaki od ovih medicinskih centara ima svoju bazu podataka (ili baze
28
podataka) koja prua podrku u obavljanju raznih poslova. Ove baze podataka
imaju podatke o pacijentima, doktorima, medicinskim uslugama, poslovanju i
drugim bitnim entitetima. Baza podataka prua adekvatnu podrku za veinu
poslova u svakom pojedinanom medicinskom centru. Meutim, postoji potreba
za jedinstvenim pogledom na celu organizaciju; na primer, da bi se videla sva
poslovanja sa jednim dobavljaem ili pacijentom. Poveanje produktivnosti se
moe postii uvoenjem, na primer, centralnog sistema za naruivanje materijala za sve zdravstvene centre i rasporeivanjem osoblja i usluga koje vre na
sve zdravstvenim centre. ERP sistem omoguava uvoenje prethodnih promena.
Donoenje odluka na nivou cele organizacije, u vezi sa poslovanjem sa dobavljaima, i podnoenje izvetaja raznim agencijama zahteva sakupljene svih prethodnih
podataka i informacija. Da bi se zadovoljile ove potrebe, organizacija koristi skladite podataka koje se odrava i nalazi u seditu organizacije. Podaci koji se nalaze
u skladitu podataka su preuzeti (i potom sumirani) iz pojedinanih baza podataka svakog medicinskog centra. Ovaj proces preuzimanja podataka se odvija periodino putem telekomunikaciono- raunarske mree.
5.5. Internet, Intranet i Extranet baze podataka

Internet tehnologije slue za olakavanje deljenja podataka i informacija.
Na primer, u okviru fabrike moe se koristiti lokalna mrea (LAN) koja povezuje radne stanice zaposlenih iz raznih odeljenja sa serverom na kome se nalazi
baza podataka. LAN unapreuje komunikaciju i proces donoenja odluka u
okviru same kompanije. Ako se uvede Intranet koji se zasniva na Web tehnologiji, njemu se moe pristupati samo u okvirima kompanije. Radna stanica
svakog zaposlenog se moe koristiti kao web browser, i na taj nain se dobija
brz pristup informacijama kompanije, ukljuujui i telefonski adresar, specikacije proizvoda, elektronsku potu i tome slino. Takoe se radne stanice
mogu koristiti i kao personalni raunari koji povezani preko LAN-a pristupaju
serveru na kome se nalazi baza podataka. Mogue je dodati i Web interfejse
nekim poslovnim aplikacijama, kao to su unoenje porudbina, da bi na taj
nain vie internih poslovnih aktivnosti moglo biti obavljano od strane zaposlenih preko intraneta.
U cilju ekasnijeg ukupnog poslovanja intranet sistem se moe otvoriti
ka kupcima preko Interneta. Ovo omoguava maloprodajama da pretrauju
katalog proizvoda (ukljuujui slike i specikacije proizvoda) i utvrde da li
29
eljenog proizvoda ima u skladitu. Tada radnici u maloprodajnim objektima mogu da obaveste svoje kupce i da porue eljeni komad proizvoda preko
Interneta. Internet konekcija je kongurisana kao extranet to znai da samo
odobrene maloprodaje mogu da pristupe intranet-u fabrike.
Sve vee korienje Interneta, svetske mree koja povezuje korisnike, nebitno koje platforme je dovelo i do promena u okruenju baza podataka. Prihvatanje Interneta od strane poslovnog sveta je dovelo do bitnih promena u davno
utvrenim modelima poslovanja. Veoma uspene kompanije su bile ugroene
zbog novih kompanija koje su prihvatile Internet pomou koga su unapredile informisanje i usluge koje su pruale svojim klijentima, i koje su zaobile
tipine tokove marketinga i distribucije proizvoda. Na primer, kupci konguriu i poruuju svoj PC raunar direktno od proizvoaa raunara. Informacije o
upranjenim mestima i aktivnostima organizacije se mogu dobiti preko Interneta za veinu organizacija.
Svaka od ovih radnji zahteva podrku baze podataka. Lak pristup Internetu svih vrsta platformi omoguava kompanijama da reorganizuju svoje poslove
i razviju bre aplikacije i to po manjim trokovima. Standardni interfejsi omoguavaju veu produktivnost korisnika, uz manje provedenog vremena na obuci, i
manju potrebnu podrku. Osnova razvoja korisnikove aplikacije je prikljuivanje
baze podataka iz koje se mogu dobiti svee informacije. Kada je baza podataka povezana sa nekom Internet lokacijom, korisnici preko Web browser-a mogu
da postavljaju odreena pitanja na koja e dobiti odgovore bazirane na sveim
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 deavanja na sajtu kako
bi doli do to vie informacija o svojim klijentima (obrazci pri kupovini, navigacija sajtom, duina zadravanja na svakoj stranici i tome slino) kako bi to vie
unapredili svoj odnos prema kupcima.
Veina primera koji su navedeni prikazuju Business-to-Customer (B2C)
veze. Kada su kupci kod nekih rmi druge rme, takav odnos se obino naziva
B2B (Business-to-Business) odnos. Internet se koristi da olaka B2C odnos, zato
to su kupci obavezno spoljni faktor u odnosu na rmu, i mogunost kupca da
pristupi poslovnim podacima i informacijama je od velike vanosti za uspean
odnos. Dozvoljavanjem pristupa poslovnim bazama podataka, od strane osoba
30
koje nisu deo organizacije, javljaju se nova pitanja za rukovoenje informacionim

sistemima vezana za sigurnost i integritet podataka.
Kompanije su godinama vrile razmenu informacija putem elektronske razmene 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, meutim, pristup extranetu
je, za razliku od Interneta kome mogu svi pristupiti, ogranien. Ustvari, pristup je
ogranien na kompanije koje su u ulozi dobavljaa i kupca i koje imaju meusobni dogovor o pristupu podacima i informacijama jednih drugima. Obino, prethodno pomenuti akteri imaju pristup delu intranet-a drugog aktera. Ovaj nain
pristupa olakava poslovne odnose tako to prua bri i ekasniji nain obrade i
pristupanja podacima.
Kao to je prethodno pomenuto mnoge organizacije su koristile Internet
tehnologiju za stvaranje privatne mree namenjene za upravljanje informacijama u okviru organizacije. Po izgledu ne postoji razlika izmeu intranet i Internet stranica, ali pristup intranet stranici je ogranien samo na korisnike u okviru
te organizacije. Stoga je i pristup bazi podataka organizacije ogranien. Intranet
moe da ostvari Internet konekciju ali ta konekcija e biti zatiena rewall-om
koji spreava neovlaeni pristup intranetu.
31
Poglavlje 6.
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
stanovnitva u SAD. Podaci na buenim karticama su runo ubacivani u ureaj
za oitavanje, a obrada podataka se odnosila na prebrojavanje. Programiranje se
svodilo na izbor vrste prebrojavanja, a radilo se runim prespajanjem kontakata.
Dotadanja 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, godite itd. popunjenih praznim prostorima da bi se za sva imena obezbedila ista duina, tako da baza podataka bude poravnata. On je uspeo da proda
koncept svoje maine i buene kartice koje su sluile za uvanje podataka u statistikom birou SAD. Tako je popis stanovnitva iz 1890. godine bio prva automatizovana baza podataka, koja se u sutini sastojala od hiljada kutija punih buenih
kartica. Od Holerith-ove kompanije nastao je dananji IBM.
Slika 6.1. Izgled Holerith-ove buene kartice i maine za oitavanje kartica

33
Nakon Drugog svetskog rata, u kompanijama i vladinim institucijama poeli su se pojavljivati prvi elektronski raunari. Oni su se esto koristili upravo za
jednostavne linearne baze podataka, najee za raunovodstvo. Ipak, vrlo brzo,
bogati kupci su poeli da zahtevaju vie od njihovih ekstremno skupih maina.
Sve je to vodilo do ranih baza podataka. Zanimljivo, ove rane aplikacije su nastavile da koriste Hollerith-ove buene kartice, neznatno modikovane u odnosu na
originalni dizajn. Neeksibilnost polja iste duine, baze podataka pokretane 80
kolonskim buenim karticama, uinile su rane raunare metom napada i ala i
potpunom misterijom za obinog oveka.
Veina prvobitnih baza podataka se odnosila na specine programe
napisane za specine baze podataka. Za razliku od modernih sistema koji
mogu biti primenjeni na potpuno razliite baze podataka, ovi sistemi su bili
usko povezani za bazu podataka da bi osigurali brzinu na utrb eksibilnosti.
Sistemi upravljanja bazama podataka su se prvi put pojavili tokom 1960-tih
godina i nastavili su da se razvijaju tokom sledeih decenija. U veini sluajeva,
period uvoenja je dugo trajao, skoro deceniju pre navedene godine poetka
upotrebe. Na primer, relacioni model je prvi put denisan od strane E.F.Codd
u tekstu objavljenom 1970 godine. Meutim, relacioni model nije bio iroko
prihvaen sve do 1980-tih godina.
1960te
Tokom ovog perioda, sistemi zasnovani na datotekama su i dalje imali
dominantnu ulogu. Pa ipak, prvi sistemi za upravljanje bazom podataka su uvedeni u ovoj deceniji, i korieni su najpre samo kod velikih i sloenih projekata, kao to je to bio projekat sletanja Apollo-a na Mesec. Ovaj period moemo
posmatrati kao period dokazivanja, u kom je demonstrirana sposobnost ovih
sistema da upravljaju ogromnim koliinama podataka. Takoe, prvi napor da se
standardizuju poduzet je sa formiranjem DBT Grupe (Data Base Task Group),
tokom kasnih 60-ih godina.
1970te
Tokom ove decenije, upotreba sistema za upravljanje bazom podataka
je postajala komercijalna stvarnost. Hijerarhijski i mreni sistemi za upravljanje podacima su uvedeni, velikim delom zbog potrebe za sistemom koji
e moi da upravlja sloenim strukturama podataka, kao to su rauni fabrika
34
pri nabavci sirovina, kojima je bilo izuzetno teko upravljati preko konvencionalnih metoda. Ovi modeli se i sutinski smatraju prvom generacijom sistema 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:
Teak pristup podacima. Za pristup i najjednostavnijim podacima bili su

potrebni izuzetno sloeni programi.
Veoma ograniena nezavisnost podataka, tako da se programi nisu mogli

izolovati od promena u formatu podataka.
Nije postojala nijedna iroko prihvaena teorijska podloga za bilo koji od

ovih modela, za razliku od relacionog modela podataka.
1980te
Da bi se prevazila ova ogranienja, E. F. Codd, kao i mnogi drugi, razvili

su model relacionih podataka tokom 70-ih godina. Ovaj model, koji se smatra drugom generacijom DBMS-a, doiveo 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, korien je za dobijanje informacija. Ovaj model je obezbedio jednostavan pristup podacima i onim ljudima koji nisu bili programeri,
prevazilazei na taj nain jednu od najveih primedbi koja je pratila sisteme
prvih generacija. Model je takoe pokazao i svoju pogodnost za komunikaciju
na relaciji klijent/server, paralelni prenos podataka, i upotrebu grakog korisnikog interfejsa (GUI).
1990te
Ove godine se oznaavaju kao nova raunarska era, najpre na nivou
raunarske komunikacije na relaciji klijent/server, a potom sa stvaranjem skladita za podatke i upotrebom Internet aplikacija, koji su dobijali sve vie na
vanosti u ovom periodu. Kao to je upravljanje podacima od strane DBMS-a
postalo visoko primenjivo (npr., u raunovodstvu) tokom osamdesetih godina,
multimedijalni podaci (ukljuujui i graku, zvuk, slike i video zapis) su postali
uobiajena stvar tokom devedesetih godina. Kako bi se izborili sa sve sloenijim
35
podacima, tokom devedesetih su uvedeni sistemi okrenuti ka objektu, koji se

smatraju treom generacijom. Zbog velike potrebe za organizacijom ogromne
koliine podataka kako strukturisanih, tako i nestrukturisanih podataka, ovaj i
prethodni sistem su u upotrebi i danas. Neki proizvoai ak rade na razvoju
kombinovanih sistema za upravljanje bazama podataka, kako bi mogli da upravljaju obema vrstama istih.
Od 2000. godine
Naravno, navodimo se na razmiljanje u kom pravcu e da krene razvoj
DBMS tehnologija tokom naredne decenije. Iako e nesumnjivo doi do novih
iznenaenja, moemo oekivati nastavak dobro uspostavljenih trendova:
36
1.
Mogunost upravljanja sve sloenijim tipovima podataka. Ovi tipovi ukljuuju i multidimenzionalne podatke, koji su ve dobili na vanosti u aplikacijama skladitenja podataka.
2.
Nastavak razvoja univerzalnih servera. Zasnovani na sistemu tree generacije DBMs-a, to su serveri koji mogu da upravljaju irokom lepezom raznih
tipova podataka, tako da budu transparentni svim korisnicima. Bie naroito vani kod Internet aplikacija.
3.
Dok su u potpunosti distribuirane baze podataka postale realnost, trenutni

trend ka centralizaciji istih e se nastaviti. Kako se trokovi komunikacije
sve vie smanjuju, nasuprot porastu tipova podataka,vrednost lociranja i
pristupa centralizovanoj bazi podataka takoe se smanjuje. Manji trokovi,
a visoke performanse svakako ohrabruju ovaj trend.
4.
Skladita sa adresiranim sadrajem e postajati sve popularnija. Sa ovakvim

pristupom, korisnik moe da izvue bilo kakav podatak specikacijom kakvu vrstu podatka eli, umesto kako da doe do njega. Na primer, korisnik
moe da skenira fotograju i da trai od kompjutera pretragu, kako bi pronaao istu takvu, ili njoj slinu.
5.
Baza podataka i druge tehnologije, poput vetake inteligencije i televizije,

kao informacionog servisa, olakae pristup podacima neobuenim korisnicima. Na primer, korisnik e biti u mogunosti da zahteva podatak na
vie jezika, a tehnologija baza podataka e da ukljuuje potrebe korisnika za
podacima, na osnovu upita koji se uvaju, i menjati se na taj nain.
6.
Rad na tehnologijama algoritama za tehniku analize podataka, koji tee

ka upravljanju veoma velikim paketima podataka, kako bi organizacije to
lake analizirale svoja ogromna skladita podataka. To e u velikoj meri
olakati u planiranju strategije organizacija za njihovo poslovanje za due
vremenske periode.
7.
I na kraju skale se nalazi dalje irenje PDA, to e dovesti do poboljane sinhronizacije malih baza podataka i poboljanje brzine beinog
prenosa. Bluetooth beini standard e u velikoj meri ubrzati razvoj
beine konekcije na Internet. Ali e i nametnuti pitanje daljeg razvoja
zatite podataka.
37
Poglavlje 7.
Modelovanje
Informacioni sistemi pojedinih rmi omoguavaju upravljanje podacima
koji su bitni za njeno poslovanje. Meutim, broj internih podataka i podataka
iz okruenja je ogroman te je nemogue sve podatke i sve uoene detalje opisati i sauvati unutar informacionog sistema. Postupkom selekcije identikuju se i
uvaju samo relevantni podaci. Time se dolazi do pojma modela podataka. On je
izraz i posledica zahteva za obradom podataka relevantnih za odreeno podruje primene. Modeli su ovekovo sredstvo pojednostavljivanja problema i njegovo posmatranje samo sa stanovita bitnih za ciljeve analize. Objekt posmatranja (npr. automobil) ima uvek vie osobina (atributa) od kojih u datom trenutku
analize moe biti dovoljan samo njihov manji broj (npr. samo registarski broj, tip
automobila, ime i prezime vlasnika). To su najvaniji atributi potrebni u postupku
pretraivanja i pronalaenja vlasnika vozila na osnovu registarskog broja vozila
unutar jednog informacionog sistema. Ostali atributi kao to su boja, godina proizvodnje, broj sedita i sl. nisu bitni (mogu se zanemariti ) za takav postupak. ovek, obdaren sposobnostima apstraktnog naina miljenja, 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 informacije prikupljaju, objekti se identikuju, dodjeljuju im se imena koristei termine
bliske krajnjim korisnicima. Objekti se onda modeluju i analiziraju koritenjem
dijagrama objekti-veze (ER dijagrami). Dijagram se moe pregledati od strane
dizajnera i krajnjeg korisnika da bi se osigurala njegova kompletnost i tanost.
Ako model nije taan, modikuje se, to ponekad zahteva da se prikupe dodatne
Modelovanje
39
informacije. Ciklus pregledanja i modikovanja se nastavlja sve dok se ne dobije

potvrda da je model korektan.
Slika 7.1. Realan svet i njegov model
7.1. Razvoj konceptualnih modela

Objekti iz realnog sveta se u raunarskoj primeni opisuju pomou podataka. Podaci su zato apstrakcija realnosti, tj. sredstva za kodiranje osobina objekata
iz realnog sveta. Modelovane, kao postupak kojim se realni svet svodi na odreeni
broj podataka, predstavlja kompleksan posao i sastoji se iz vie koraka:
40
Izbor (selekcija). U prvom koraku se mnotvo objekata iz realnog sveta

redukuje na manji skup objekata, koji e initi objekte modela. Npr. objekti
mogu biti student, predmet, profesor, studentska sluba, polaganje ispita i sl.
U procesu selekcije ovaj broj objekata se moe redukovati na manji broj, ako
je cilj praenje uspenosti studiranja na fakultetu. Time se sloenost realnog
sistema smanjuje. Selekcija se ne odnosi samo na objekte nego i na njihove
osobine, kao i na meusobne veze (relacije) izmeu objekata.
Imenovanje. Svakom objektu u realnom svetu, svakoj vezi izmeu uoenih

objekata, kao i svakom atributu (svojstvu) uoenog objekta ili veze dodeljuje se ime.
Klasikacija. Nehomogeni skup objekata i odnosa se svrstava u homogene

klase i tipove objekata. Klasikacija uvek zavisi od podruja primene.
Modelovanje
Rezultat navedenih koraka modelovanja zove se konceptualni model. On

sadri, za posmatrani problem iz realnog sveta, sve relevantne tipove objekata,
njihove osobine i meusobne veze. Rezultati prouavanja modela podataka doveli
su do saznanja da svaki model podataka ima tri neodvojive komponente:
strukturu podataka,
operacije nad podacima,
ogranienja (constraints).
Struktura i ogranienja, za razliku od operacija, opisuju stanje realnog sistema, tj. predstavljaju statiki opis stanja sistema. Strukturu modela ine objekti,
njihova svojstva, veze izmeu objekata i njihovih svojstava. Operacije nad podacima u modelu su, u stvari, operacije nad strukturom modela kojima se izraava
dinamika realnog sistema. Operacije izraavaju kretanje i promene tj. dinamiku
realnog sistema. Ogranienja su pravila koja razdvajaju doputena od nedoputenih 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. Entiteti
Modelima podataka nastoji se preslikati realan sistem. Realan sistem sastoji
se od objekata iz realnog sveta i njihovih veza izmeu kojih se uspostavljaju razliiti odnosi. Pod entitetom se podrazumeva sve to se moe jednoznano odrediti,
identikovati i razlikovati. Tako iroko postavljena denicija pokazuje da entitet
moe biti svaki realan ili apstraktan objekt o kojem u odreenom trenutku razmiljamo. Entitet je realan ako ziki, stvarno postoji. Najoptije se moe tvrditi
da su granice entiteta u modelu podataka odreene ljudskim pogledom i nainom razmiljanja.
Svaki entitet uoen u realnom sistemu ima svoje osobine koje ga ine
sloenim i njihove vrednosti omoguavaju razlikovanje entiteta. Svojstvo entiteta ukljuuje dva elementa - atribut i vrednost atributa (npr. entitet Student
ima atribute: Ime, Prezime, Broj indeksa, Adresu, Telefon i sl. i vrednosti Marko,
Modelovanje
41
Markovi, 123/03, Danijelova, 15, 011/376-543 respektivno). Svaki put kada se

promeni vrednost atributa, potrebno je promenu evidentirati, tj. aurirati tu
vrednost atributa za dati entitet.
Precizno govorei, objekti koji se oznae pojmom entiteta mogu se zvati
klase entiteta. Svaki objekt ima osobine (atribute) klase entiteta kojoj pripada.
Npr. klasu entiteta Student ine pojedinani entiteti od kojih svaki ima zajednike
atribute: Ime, Prezime, Broj indeksa, Adresa, Telefon i sl. Svaki pojedinani 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 sloen, tako da ima svoje dodatne atribute, moe
se posmatrati kao novi entitet.
Domen atributa je skup svih moguih vrednosti koje atribut moe
poprimiti.
Primarni klju je jedan ili vie atributa ija vrednost jednoznano odreuje primerak entiteta. Na primer, za entitet Auto, primarni klju je atribut registarski broj. Dva razliita 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 izmeu entiteta

Baza podataka se ne odnosi samo na pojedinane objekte nego i na odnose
izmeu objekata. U realnom sistemu objekti nisu meusobno izolovani, nego se
nalaze u meusobnoj interakciji. Student se upisuje na fakultet, slua predavanja
iz pojedinih predmeta, prijavljuje polaganje ispita, polae ispit itd. To su primeri
logikih i realnih veza izmeu objekata, koje slede iz realnih odnosa u posmatranom sistemu studiranja na jednom fakultetu. Istraimo jedan skup odnosa izmeu studenata koji sluaju predavanja kod odreenog profesora. Postavlja se
pitanje ta su u takvim odnosima objekti, koje su njihove osobine (atributi) i kako
prikazati njihove odnose.
42
Modelovanje
Identikovati objekte, njihove osobine i odnose znai praktino izgraditi

model podataka. U modelu podataka ne postoje samo atributi objekta, nego i
veze izmeu objekata. Prvo se selektuju objekti, imenuju se, a zatim se analiziraju tipovi odnosa koji se uspostavljaju izmeu objekata. Odnosi izmeu objekata posmatranja prikazuju se najee primenom logike skupova i preslikavanja
njihovih elemenata.
Najjednostavniji odnos izmeu ta dva tipa objekata naziva se preslikavanje
1:1. Kod takvog preslikavanja svaki se element skupa X moe preslikati na najvie
jedan element skupa Y. Istovremeno, i svaki element skupa Y moe biti preslikan
na najvie jedan element skupa X. Karakteristian primer bi bio sa entitetima
Fakultet i Dekan. Na jednom fakultetu moe biti samo jedan dekan, a jedan dekan moe biti dekan na samo jednom fakultetu. Takvi odnosi izmeu entiteta su
retki, a mogu se predstaviti sledeom slikom:
Slika 7.2. Preslikavanje entiteta 1:1

Druga vrsta odnosa naziva se preslikavanje N:1 (ili 1:N). Vie elementa skupa X moe se preslikati na najvie jedan element skupa Y. Istovremeno jedan element skupa Y moe se preslikati na vie elemenata skupa X. Pogodan primer za
ovu vrstu odnosa izmeu entiteta je odnos izmeu entiteta Student i Dekan. Vie
studenata na jednom fakultetu ima samo jednog dekana, a jedan dekan je dekan
za vie studenata na svom fakultetu.
Modelovanje
43
Slika 7.3. Preslikavanje entiteta N:1

Najsloenije preslikavanje je tipa M:N. Svaki element prvog skupa moe se
preslikati na vie elemenata drugog skupa, ali se i svaki element drugog skupa
moe preslikati na vie elemenata prvog skupa. Karakteristian primer ovakvih
veza postoji ako se uoe entiteti Student i Profesor. Jednom studentu predaje vie
profesora, a ujedno jedan profesor predaje za vie studenata.
Slika 7.4. Preslikavanje tipa M:N

44
Modelovanje
7.4. Troslojna arhitektura baze podataka

Osnovni koncept baze podataka je ideja o skupu injenica ili delova znanja. injenice mogu da budu struktuirane na razliite naine koji se nazivaju
modeli podataka. Model podataka nije statina struktura nego se menja kako bi
odraavao promene koje se deavaju i u realnom sistemu. Na primeru informacionog sistema jednog fakulteta, studenti polau pojedine ispite, neke ponitavaju i dobijaju drugaije ocene, upisuju se novi studenti, drugi diplomiraju, neki
asistenti postaju profesori itd.
Za jednostavne sluajeve, kao i mali broj promena relacija i entiteta,
mogue je auriranje podataka vriti runo. Za kompleksnije sisteme (sa nekoliko stotina ili hiljada entiteta ili relacija) auriranje podataka postaje ogroman
problem. Jedino se uz pomo raunara moe odravati aurnost podataka u
velikim informacionim sistemima. Obrada podataka postaje ne samo pitanje produktivnosti neke rme ili organizacije, nego i opstanka, rasta i razvoja
u okruenju s intenzivnom konkurencijom. Obrada podataka je deo svakog
poslovnog procesa, stoga je poznavanje baza podataka bitno ne samo za projektante informacionih sistema i programere, nego i za krajnje korisnike rezultata takvih obrada. Oni nisu samo skup povremenih korisnika baza podataka,
kao to se to moe rei za programere ili projektante informacionih sistema.
Danas veliki broj zaposlenih, koji nisu upoznati sa konceptualnom emom BP,
kreiraju, unose, auriraju ili jednostavno koriste baze podataka na razliitim
nivoima organiziranosti poslovnih sistema.
Model baze podataka koji je danas poznat kao ANSI/X3/SPARC model prikazan 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 odgovarajueg eksternog modela. Zahtev za uitavanje odreenih podataka aplikativni sloj upuuje na eksterni
sloj, odnosno odgovarajui korisniki model. DBMS preslikava eksterni model na
konceptualni i konceptualni na interni model.
Konceptualni nivo je najblii stvarnosti. Taj se nivo denie u procesu kreiranja modela podataka. Jedan od ciljeva modela podataka je oblikovanje podataka za sadanje i budue aplikacije. Moe se rei da konceptualni nivo ine sve relacione eme modela podataka, sve relacije i ogranienja. Spoljanji nivoi (modeli A,
Modelovanje
45
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

Unutranji (interni) sloj baze odnosi se na zapisivanje konceptualnog sloja
na nekom medijumu za uvanje (najee disku). Radi se o slogovima zapisanim
u datotekama. Nii sloj, uslovno reeno, ili nivo blii disku od internog sloja BP, je
operativni sistem, koji na osnovu logikih adresa slogova ita sadraj diska.
46
Modelovanje
Poglavlje 8.
Modeli baza podataka

Za modelovanje strukture podataka koriste se razliite tehnike. Odreeni
modeli se lake koriste za neke tipove sistema upravljanja bazama podataka nego
drugi modeli. Model ini osnovu za osmiljavanje, denisanje i implementaciju
baze podataka.
Istorijski gledano sistemi za upravljanje bazama podataka mogu se podeliti
u sledee osnovne modele:
Hijerarhijski model ine ga podaci sloeni u hijerarhijsku strukturu;
Mreni model moe se predstaviti usmerenim grafom u kojem su vorita podaci, a lukovi meu voritima deniu veze meu podacima;
Relacioni model zasnovan na matematikom pojmu relacije. Podaci i
veze meu podacima se prikazuju preko dvodimenzionalnih tabela.
Objektni model bazira se na konceptu objekata, koji predstavljaju skup
podataka i operacija koje se na njima mogu izvravati.
8.1. Hijerarhijski model

Hijerarhijski model je najstariji od svih modela baza podataka, i za razliku
od mrenog, relacionog ili objektno orjentisanog, nema dobro dokumentovanu
istoriju svoje koncepcije i poetne verzije ovakvog modela. Ovaj model se razvio
iz informacionog sistema za upravljanje u 50-tim i 60-tim godinama prolog veka.
Usvojen je u mnogim bankama i osiguravajuim drutvima koji ga, kao naslee,
i danas koriste.
47
U hijerarhijskom modelu podaci su smeteni u seriju slogova (zapisa) Da

bi se uspostavila veza izmeu slogova, hijerarhijski model uspostavlja relaciju
roditelj naslednik. Ovo je takozvano 1:N mapiranje izmeu slogova koje se
radi korienjem stabla. U ovom modelu, relacije su takve da jedan naslednik moe imati samo jednog roditelja, ali roditelj moe imati vie naslednika.
Roditelji i naslednici su povezani vezama koje se nazivaju pokazivai (u zikoj
realizaciji to je adresa u memoriji gde se slog nalazi). Roditelj ima listu pokazivaa za svakog od svojih naslednika. Hijerarhijski model je dobro ureena
struktura, koja podsea na hijerarhijsku strukturu u npr. dravi, vojsci ili nekoj
velikoj organizaciji.
Slika 8.1. ematski prikaz jednog hijerarhijskog modela

Pravilo roditelj naslednik omoguava pristup podacima. Da bi se dolo do
tabele na niem nivou, kree se od korena i ide prema dole kroz stablo dok se ne
doe do cilja. Naravno, oigledan problem sa ovim modelom je da korisnik mora
da zna kako je stablo organizovano da bi pronaao bilo ta.
Hijerarhijski model ima ozbiljnih nedostataka. Na primer, ne moe se dodati slog u tabelu naslednika dok se ne ukljui u roditeljsku tabelu. Hijerarhijski
model je sposoban da radi jedino sa jednostrukim stablima, ali ne moe da se nosi
sa povezivanjem ogranaka ili stvaranjem viestrukih veza. Zbog toga se stvara
redudansa (viestruko pojavljivanje) podataka i mogunost netanog auriranja.
Na primeru hijerarhijske organizacije nekog fakulteta koji ima katedre, profesore,
studente itd. mogu se lako uoiti navedene slabosti. Lako je predstaviti da na jednoj katedri ima vie profesora, ali se ne moe predstaviti da jedan profesor radi na
vie katedri. Da bi se ovo uradilo, mora postojati dva pojavljivanja istog profesora.
To moe dovesti do netanosti kod auriranja podataka, npr. mogue je da informacije budu razliite u dva zapisa, to vodi do konfuzije.
48
Hijerarhijski model se vie ne koristi kao osnova za trenutne komercijalne sisteme, ali jo uvek postoji mnogo nasleenih sistema baziranih na ovom
modelu. Zbog svih nedostataka koji postoje u hijerarhijskom modelu, razvijen je
mreni model.
8.2. Mreni model

Mreni model je prvi put predstavljen 1971. godine. Moe se smatrati savremenikom relacionog modela, gledajui starost i prva istraivanja uinjena u
60-tim godinama prolog veka. Omoguava da se viestruki skupovi podataka
koriste zajedno putem pokazivaa (ili pointera). Neke kolone sadre pokazivae
na druge tabele umesto samih podataka. Na taj nain, tabele su povezane pokazivaima i mogu se posmatrati kao mrena struktura. Dok u hijerarhijskom modelu
svaki slog ima jedan roditeljski slog i neogranieno naslednika, mreni model
omoguava svakom zapisu da ima viestruke roditelje i naslednike, kreirajui
mreastu strukturu.
Slika 8.2. ema mrenog modela

Mreni model se danas uglavnom ne upotrebljava za dizajniranje baza
podataka, ali ipak ima sluajeva gde se kao deo naslea koristi u nekim kompanijama. Predstavlja unapreenje hijerarhijskog modela, ali je kompleksan i
teak za upotrebu. Pored toga, teko ga je podrati matematikim aparatom, to
onemoguava kasnije ekasno programiranje.
49
8.3. Relacioni model

Kao i mnoge druge tehnologije u raunarskoj industriji, koreni relacionih
baza podataka potiu iz IBM-a i njihovog istraivanja automatizovanja kancelarijskih operacija u 60-tim i 70-tim godinama XX veka. 1970. godine, IBM-ov
istraiva Ted Codd je prezentovao prvi rad o relacionim bazama podataka. Zbog
same tehnike prirode rada i oslanjanja na matematiki aparat, njegova vanost
nije odmah shvaena. Ipak, doveo je do formiranja IBM-ove istraivake grupe System R. Od projekta System R se oekivalo da stvori sistem relacione baze
podataka koji bi mogao postati proizvod. Prvi prototip prezentovan je 1974/75.
godine i eksperimentalno je korien. Nakon to je denisan relacioni model,
napravljeni su neformalni modeli da bi se opisali hijerarhijski i mreni model.
Hijerarhijske i mrene baze podataka su postojale pre relacionih baza podataka, ali su kao modeli opisani tek nakon to je relacioni model denisan, da bi se
napravila osnova za poreenje.
U srcu relacionog modela nalazi se koncept tabele (koja se naziva i relacija)
u kojoj su smeteni svi podaci. Svaka tabela je nainjena od slogova (redova u
tabeli), a svaki slog ima svoja polja (atribute). Osnovne karakteristike relacionog
modela podataka su sledee:
Sve se predstavlja relacijama (tabelama)
Zasniva se na strogoj matematikoj teoriji
Minimalna redudansa podataka
Jednostavno auriranje podataka
Izbegnute su anomalije auriranja
Redosled kolona i redova ne utie na informacioni sadraj tabele
Ne mogu da egzistiraju dva identina reda (rekorda) u jednoj tabeli
Svaki red se moe jednoznano odrediti (postoji primarni klju)
...
U relacionom modelu podataka klase objekata se predstavljaju tabelama.
Na primer klasa STUDENT se moe 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 moe biti sledee:
50
Slika 8.3. Tabela kao osnovni objekat relacione baze podataka

Prethodna dva objekta sa svojim atributima graki se mogu predstaviti na
sledei nain:
Slika 8.4. Graki prikaz objekata i njihovih atributa

U realnom svetu objekti meusobno stupaju u veze. Na jednom fakultetu
studenti dre (pozajmljuju iz biblioteke) pojedine knjige. Moe se uoiti da je veza
izmeu ova dva posmatrana objekta tipa M:N, tj. vie studenata mogu da dre jednu knjigu, a jedna knjiga moe biti kod vie studenata. Neka je trenutna situacija
iz realnog sveta prikazana na sledeoj slici:
51
Slika 8.5. Veze izmeu objekata realnog sveta formira se klasa veza
Klasa veza se moe posmatrati kao zaseban entitet, a taj entitet moe da
ima svoje posebne atribute. U naem primeru, klasa veza DRI moe da ima kao
atribut DATUM od kada student dri odreenu knjigu. Neka je trenutna situacija
iz realnog sveta prikazana sledeom slikom
Slika 8.6. Klasa veza moe da ima svoje atribute

Graki prikaz navedenog dat je na sledeoj slici
Slika 8.7. Klasa veza moe da ima svoje atribute

52
Sutina relacionog modela je da se i klase objekata i klase veza izmeu

objekata predstavljaju na jedinstven nain, tj. preko tabela. U naem primeru
postoje tri tabele: STUDENT, KNJIGA i DRI. U relacionom modelu podataka
tabela se denie kao relacija, koja mora da ispuni odgovarajue uslove. Svaka
relacija mora da ima primarni klju jedan ili vie atributa koji na jedinstven
nain opisuju svaki zapis u jednoj tabeli. Primarni klju se paljivo bira. Na primer
u klasi studenata lo izbor primarnog kljua bi bio atribut IME, zato to se mogu
pojaviti dva studenta sa istim imenom. Dobar izbor primarnog kljua je atribut
Broj indeksa, zato to ne postoje dva studenta sa istim brojem indeksa. Za klase
objekata Student i Knjiga vri se prevoenje u relacioni model na sledei nain
(podvlaenjem su oznaeni atributi koji ine primarni klju):
STUDENT (BrInd, Ime),
KNJIGA (SifK, Naziv)
Za klasu veza Dri, moe se dinisati prirodan primarni klju u odnosu na
objekte koje povezuje. U naem primeru relacija Dri bi glasila:
DRI(BrInd, SifK, Datum)
Dakle, za posmatrani realan sluaj gde studenti dre pojedine knjige, izvreno je modelovanje preko tri tabele tj. relacije. Tabele STUDENT i KNJIGA imaju
dve kolone, a tabela DRI tri kolone. Sve tabele su povezane. Povezivanje se vri
preko vrednosti atributa u relacijama. na sledei nain:
Slika 8.8. Relacije se povezuju vrednostima spoljnih i primarnih kljueva

Veoma je vano zapaziti da kako i gde su tabele smetene ne pravi nikakvu razliku. Svaka tabela se identikuje jedinstvenim imenom koje baza podataka
koristi da bi pronala tabelu. Korisniku je potrebno samo da zna ime tabele. Nema
53
potrebe da se vodi rauna o tome kako su podaci smeteni na disku. Ovo je razliito od hijerarhijskog i mrenog modela u kojima korisnik mora da razume kako
su podaci struktuirani unutar baze podataka da bi mogao da ih pretrauje, unosi
nove, aurira ili brie postojee slogove.
Relaciona baza podataka standardno se sastoji iz vie tabela. Ipak, za
razliku od mrene baze podataka, tabele nisu povezane pokazivaima. Umesto toga koriste se kljuevi da upare redove podataka u razliitim tabelama.
Klju je samo jo jedna ili vie kolona u tabeli, koja odgovara kolonama u
drugim tabelama.
Zahtev za podatkom iz relacione baze podataka se dobija izvravanjem
upita koji je napisan u posebnom jeziku, obino nekom od dijalekata SQL-a.
Iako je SQL originalno namenjen za krajnje korisnike, mnogo ee se SQL upiti
ugrauju u softver koji omoguava laki korisniki interfejs. Kao odgovor na
upit, baza podataka vraa skup podataka, koji je u stvari lista redova koji sadre
odgovor. Najjednostavniji upit je da se dobiju svi redovi iz tabele, ali ee, redovi se ltriraju na neki nain da bi se dobio traeni odgovor. esto se podaci iz
vie tabela kombinuju u jednu, procesom udruivanja.
Fleksibilnost relacionih baza podataka dozvoljava programerima da piu
upite koji nisu bili predvieni od strane dizajnera baze podataka. Kao rezultat, relacione baze podataka mogu da se koriste u vie aplikacija koje originalni
dizajneri nisu predvideli, to je posebno vano za baze podataka koje se mogu
koristiti decenijama. Ovo je model relacionih baza podataka uinilo veoma popularnim u poslovnoj primeni.
8.4. Objektni model

Objektno orjentisani model je jedan od novijih modela baza podataka.
Istraivai su za njega postali zainteresovani krajem 70-tih i poetkom 80-tih
godina prolog veka, kada se koncept objektno orjentisanih sistema poeo pojavljivati. Bazira se na konceptu objekata, koji predstavljaju skup podataka i operacija
koje se na njima mogu izvravati.
Istraivanje se radilo i da bi se prevazila mnoga ogranienja u relacionom modelu na odreenim tipovima podataka. Tipovi podataka koji se mogu
54
koristiti u relacionim bazama su veoma ogranieni. Svaki atribut (polje) moe

da poprimi samo jednu vrednost. U objektno orijentisanom modelu podataka
entitet se predstavlja klasom. Klasa obuhvata i atribute i ponaanje entiteta
(mogue operacije nad podacima). Npr. Klasa: student
Atributi: BrInd, Ime, Prezime, Fakultet
Procedura: polaganje Ispita()
Objekti su samo jedno pojavljivanje u odgovarajuoj klasi. Objektno orijentisan model karakterie bogatstvo tipova podataka tip moe biti i drugi objekat.
Direktna veza izmeu objekata u aplikaciji i objekata u BP rezultuje boljim performansama baze podataka.
Posmatrajmo primer u kome se vodi evidencija o Studentima sa svojstvima: Broj indeksa, Ime, Prezime, Fakultet i Tip automobila koji student poseduje. Dalje vodi se evidencija o Automobilima sa svojstvima Naziv automobila,
Registarski broj, Boja, Godite i Vlasnik. Prethodni primer se moe prikazati
na sledei nain
Slika 8.9. U objektno orijentisanim BP tip podatka moe biti drugi objekat
Objektno orjentisani DBMS-ovi omoguavaju uvanje objekata direktno,
bez mapiranja za razliite strukture podataka. Relacioni DBMS zahteva mapiranje
iz objekata u tabele. U objektno orijentisanom modelu, informacija je sauvana
55
kao stalni objekt, a ne kao red u tabeli. Ovo sistem ini ekasnijim u smislu prostora potrebnog za smetanje i uvanje podataka i osigurava da korisnik manipulie podacima samo na onaj nain koji je programer odredio.
S druge strane, obzirom da se kontrola vri na veoma niskom nivou, mnogo
je tee za treu stranu da napravi neki dodatak. Dok kod relacionih baza podataka
moemo imati korist od softvera izraenog od strane treeg dobavljaa, korisnici objektno orjentisanih sistema za upravljanje bazama podataka ili moraju da
narue dodatni softver od originalnog programera ili da ga razviju u saradnji sa
drugim rmama koje koriste isti sistem.
56
Poglavlje 9.
Strukturna sistemska analiza (SSA)

Strukturna sistemska analiza (SSA) predstavlja savremen pristup procesu
razvoja poslovnih informacionih sistema. Analiza tokova podataka u sistemu,
odreivanje kljunih entiteta u sistemu i njihovih atributa i entiteta van sistema s
kojima on komunicira predstavlja samo najvanije u nizu zadataka SSA. Osnovne
karakteristike SSA su:
Razvijanje sistema se vri od vrha-na dole;
Analiza i dizajn podrazumevaju korienje razliitih alata, tehnika i
modela u cilju to preciznijeg snimanja aktuelnog sistema i korisnikih
zahteva;
Osnovni alati SSA su: funkcionalni dijagrami, dijagrami tokova podataka, renici podataka, specikacija procesa, dijagrami objekti-veze;
Razdvajanje zikog i logikog modela - ziki model je najee fokusiran na preivljavanje postojeeg sistema ili dizajn novog, dok je logiki
model vie usmeren na analizu zahteva kojima sistem treba da odgovori;
Ukljuivanje korisnikih uloga u razliitim fazama razvoja;
SSA omoguava istovremeno izvravanje pojedinih faza analize i dizajna;
SSA je podrana naprednim tehnologijama, to olakava razvoj sistema;
SSA predstavlja kljuni proces u projektu razvoja poslovnih informacionih
sistema. Sistemska analiza je preduslov dobrog dizajna informacionog sistema i
ukljuuje tehnike analize informacionog sistema, modelovanja podataka i tehnike
normalizacije dobijenog modela.
U metodologiji 70-ih godina preovlaujui pristup je bio waterfall pristup
koji se sastojao od 5 sekvencijalnih faza (odvijale su se jedna za drugom po tano
utvrenom redosledu):
Sistemska analiza;
57
Sistemski dizajn;
Izgradnja i testiranje sistema;
Uvoenje i tranzicija sistema;
Odravanje 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 korienje (postizanjem samo
osnovnih funkcionalnosti), a zatim se dograuje i prilagoava potrebama konkretnih korisnika. Na taj nain proces razvoja nije zavren kada se informacioni
sistem uvede u upotrebu, ve se nastavlja dodavanjem novih softverskih modula,
osavremenjavanjem postojeih funkcionalnosti. To znai da razvoj sistema traje
dok se sistem koristi (dok je iv).
Slika 9.1. Waterfall metodologija

Razvoj poslovnih sistema predstavlja ciklian (iterativno inkrementalan)
proces, koji se odvija po fazama. Zbog svoje stadijumske prirode, celokupan proces se esto naziva ivotni ciklus razvoja sistema (Slika 9.2).
U obe predstavljene metodologije SSA ima znaajno mesto i predstavlja
preduslov procesu dizajna sistema. Metodologija ivotnog ciklusa mnogo eksibilnije ukljuuje SSA u proces razvoja poslovno informacionog sistema.
58
Slika 9.2. Faze ivotnog ciklusa razvoja sistema

SSA se realizuje po fazama, i dobro denisanoj metodologiji. Sutinski, sistem se analizira na razliite naine. To moe biti sa akcentom na:
poslovne funkcije (funkcionalna dekompozicija),
tokove podataka (dekompozicija dijagrama tokova podataka),
denisanje renika podataka.
denisanje veza izmeu entiteta u sistemu (izrada dijagrama objekti
veze),
59
9.1. Funkcionalna dekompozicija

Dijagrami funkcionalne dekompozicije se koriste u odreivanju osnovnih
sistemskih funkcija i njihovom dekomponovanju. Ove funkcije obino odgovaraju u potpunosti predstavljenim procesima u dijagramima tokova podataka.
9.1.1. Jacksonovi dijagrami

Dijagrami 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 najvieg nivoa predstavlja osnovne poslovne funkcije 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. Slino hijerarhijskim organizacionim dijagramima predstavljaju se osnovne funkcije preduzea. Ove funkcije su selektivne,
to znai da se odvijaju bez uzajamnih zavisnosti.
9.1.2. Pravila u kreiranju Jacksonovih dijagrama

Osnovne funkcije najee imaju selektivnu prirodu tako da se dekomponuju. Zavretak funkcionalne dekompozicije je kada se dobiju elementarne sekvencijalne 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 funkcije prodaja. Poto se razlikuje proces veleprodaje (rad sa pravnim licima, ugovaranje, veleprodajne cene, rabat, naruivanje, dostavljanje, transakcije iskljuivo
preko iro-rauna u bankama) od maloprodaje (rad sa zikim licima, gotovinsko
60
plaanje, manje koliine robe, plaanje na prodajnom mestu), tako je osnovna

prodaja funkcija dekomponovana na navedene dve.
Slika 9.4. Dekompozicija poslovne funkcije Prodaja

Praenje dekompozicije je olakano numeracijom funkcija. Tako se npr.
funkcija maloprodaja (3.2) dekomponuje na dve manje funkcije: generisanje rauna kupcu (3.2.1) i prijem uplate kupca (3.2.2). Moe se uoiti da su funkcije generisanje rauna i prijem uplate sekvencijalne; kupac ne plaa robu dok ne dobije
raun od prodavca. Tu je kraj dekomponovanja funkcije maloprodaja, sledi opis
logike primitivne funkcije pseudo kodom.
Selektivni procesi na dijagramima funkcionalne dekompozicije oznaavaju
se znacima <>, dok se sekvencijalni procesi oznaavaju znacima [].
Funkcionalni dijagrami se ne bave podacima koji postoje u sistemu, ve
samo treba da istaknu frekventnost (vanost) i kompleksnost pojedinanih poslovnih funkcija. Kroz funkcionalnu dekompoziciju mogu se identikovati slinosti u
dekompoziciji razliitih poslovnih funkcija. Kao posledica ove injenice mogu se
identikovati nove funkcije, i ve u fazi analize uiniti koraci koji e omoguiti
optimizaciju reenja IS.
61
Slika 9.5. Primer identikovanja istih funkcija u funk.dekompoziciji

Na primer (Slika 9.5), organizacije (trgovine) koje se bave prodajom robusne robe (nametaj, vozila, industrijske maine) koriste istu funkciju otprema u
dekompoziciji veleprodaje i maloprodaje. Roba se i u jednom i u drugom sluaju
mora dostaviti kupcu. Na taj nain, funkcija otprema se dizajnira i implementira
umesto 2 puta samo jedanput i ona treba da bude dostupna iz obe opcije (nadfunkcije) aplikacije (veleprodaje i maloprodaje).
Funkcionalna analiza uz pomo alata za modelovanje obezbeuje vane
detalje koji se mogu koristiti u kasnijim fazama analize. Meutim, 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 analize. DTP se sastoje od etiri vrste elemenata (Slika 9.6):
Interfejsi
Procesi
Tokovi podataka
Skladita podataka
62
Slika 9.6. Struktura DTP

Interfejsi predstavljaju entitete (objekte) iz realnog sveta koji okruuje sistem. To mogu biti osobe koje se nalaze u odreenoj 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, trite nekretnina...). Interfejsi se prikazuju pravougaonikom i nazivom (Slika 9.7).
Slika 9.7. Primeri interfejsa

Zajedniko za sve interfejse je da su to objekti izvan analiziranog sistema, koji
interaguju (razmenjuju podatke) sa sistemom. Kao to se moe videti iz prethodnog
primera, interfejsi nisu konkretna zika lica, niti konkretne organizacije; dobavlja
moe biti bilo koje ziko, ili pravno lice. Isti je sluaj sa vlasnikom nekretnine. Izdava oglasa moe biti bilo koja izdavaka, ili novinarska kua. Bitna je uloga koju
interfejs obavlja, odnosno nain na koji sistem komunicira s interfejsom. U toku
dekomponovanja DTP, interfejsi moraju ostati konzistentni oni se ne menjaju, niti
dekomponuju. Drugim reima, broj i nazivi interfejsa na poetku dekompozicije
mora da odgovara broju i nazivima interfejsa na kraju tog procesa.
63
U toku procesa dekomponovanja, radi preglednosti dijagrama, jedan interfejs se moe ponoviti na istom dijagramu, s tim da je kopija oznaena 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 specinu poslovnu aktivnost. Proces moe predstavlja
neku automatsku obradu podataka (generisanje izvetaja, rauna, autentikacija
korisnika...), ali isto tako neku manuelnu aktivnost (nabavka, isporuka, proizvodnja, ulanjivanje, izdavanje knjige...).
Slika 9.9. Primer oznaavanja procesa

Procesi se oznaavaju krugom ili elipsom u koji se unosi naziv procesa (Slika
9.9). Za razliku od interfejsa, procesi se numeriu. Brojano oznaavanje je identino kao kod funkcionalnih dijagrama. Nije dozvoljeno praviti kopije procesa na
istom DTP. Procesi se mogu dekomponovati. Sutinski, dekompozicija DTP se
svodi na dekomponovanje poslovnih procesa. Na sledeem primeru (Slika 9.10)
istaknut je primer dekomponovanja procesa nabavka. Na nultom nivou dekomponovanja predstavljeni su osnovni poslovni procesi. Ovi procesi se dekomponuju od 1. nivoa dekompozicije. Proces nabavka se dekomponuje na 3 podprocesa:
obrada kataloga dobavljaa, naruivanje i prijem robe. To znai da se osnovni proces nabavka vie ne pojavljuje od 1. nivoa dekompozicije, ve samo njegovi podprocesi. Na drugom nivou demonstrirana je dekompozicija podprocesa prijem
64
robe. Ovaj podproces se dekomponuje na tri nova, koja opisuju ta sistem radi po
prijemu robe. To znai da se prijem robe od 2. nivoa vie ne pojavljuje kao celovit
proces, ve njegovi podprocesi.
Slika 9.10. Primer dekompozicije poslovnih procesa

Nije precizirano do kog nivoa se vri dekomponovanje poslovnih procesa. 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 procesa. Gornji primer predstavlja zavrenu dekompoziciju podprocesa prijem robe
procesa nabavke. Ako bi se nastavilo sa dekomponovanjem bilo kog od procesa
oznaenih 1.3.1 do 1.3.3., dobili bi se potpuno sekvencijalni podprocesi koji se
izvravaju po unapred utvrenom redosledu, to je vie stvar implementacionih
detalja, nego aktivnosti analize.
Tokovi podataka (TP) predstavljaju interakciju izmeu interfejsa i procesa
u sistemu. Oni obavezno moraju biti imenovani (Slika 9.11). TP imaju statiku
prirodu, jer ne odslikavaju redosled izmene podataka izmeu sistema i okoline,
niti redosled akcija koje izazivaju unutar sistema. TP mogu sadrati osnovne tipove celi brojevi, realni brojevi, karakteri i izvedene tipove - struktuirane podatke, kao to su adresa, narudbenica, katalog proizvoda (sadre podatke razliitih
osnovnih tipova ili ugnjedene strukture). Vana karakteristika TP je njihova obavezna usmerenost, koja opisuje smer toka podataka u sistemu.
65
Slika 9.11. Primer oznaavanja TP
Slika 9.12. Primer tokova podataka na fragmentu DTP za IS biblioteke

I unutar sistema postoje TP (Slika 9.12): izmeu procesa i skladita podataka i izmeu procesa uzajamno. Ti tzv. interni tokovi podataka nisu imenovani,
66
jer se podrazumeva da je njihova struktura denisana kroz spoljnje tokove (sistem - interfejs).
Namena internih TP izmeu procesa i skladita je da istaknu da li se i gde
ulazni podaci pamte u sistemu, odnosno iz kojih izvora (skladita) se generiu
izlazni podaci prema interfejsima.
TP izmeu procesa u sistemu odslikavaju njihovu uzajamnu povezanost.
Nije preporuljivo da se ovakvi TP pojavljuju u DTP 0. nivoa. Oni se pojavljuju
kao proizvod dekomponovanja osnovnih procesa, nisu imenovani i samo treba da predstave podprocese koji se koriste od vie drugih podprocesa na istom
nivou dekompozicije (odgovaraju procesima u stereotipskoj uses vezi u dijagramima sluajeva korienja UML).
U dekomponovanju DTP, tokovi podataka moraju biti konzistentni poevi od kontekstualnih dijagrama do najkonkretnijih DTP. Konvencija je da se ne
smeju pojaviti novi TP u procesu dekompozicije. Ako je to nuno, potrebno je
aurirati dijagrame na viim nivoima optosti.
Skladita podataka predstavljaju elemente sistema u kojima se podaci uvaju (Slika 9.13). Skladite podataka ne predstavlja bazu podataka, niti
tabelu u bazi. U ovoj fazi analize sistema skladita samo treba da istaknu
grupisanje podataka.
Slika 9.13. Primer skladita podataka

Za razliku od interfejsa, simbol skladita podataka je pravougaonik koji
nema bone stranice. Imena skladita su obino mnoine imenica entiteta koji
grupiu srodne podatke. Na primer, skladite STUDENTI moe 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 skladita dodaje preks SK koji jo vie istie razliku u odnosu na
interfejse. Isticanje razlike izmeu skladita i interfejsa nije neopravdano: na
prethodnom primeru (Slika 9.12) postoji interfejs CITALAC i skladite CITAOCI. U praksi je est sluaj da interfejsi i skladita imaju sline nazive, tako da je
poeljno svako nastojanje isticanja razlike na dijagramima (naravno, u okvirima
konvencije oznaavanja).
67
9.2.1. Kontekstualni dijagrami

Modelovanje poslovnih procesa zapoinje 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

68
Teini zadatak kontekstualnog dijagrama je denisanje svih interfejsa

sa kojima sistem komunicira, kao i tokova podataka koji ine tu komunikaciju. U poetku je najee nemogue denisati sve interfejse i tokove podataka.
Inicijalni sadraj kontekstualnog dijagrama treba da obuhvati osnovne tokove
i spoljnje entitete. U kasnijim fazama dekompozicije DTP je mogue naknadno
dodati nove interfejse i tokove podataka, s napomenom da mora biti zadrana
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 kontekstualan dijagram za informacioni sistem biblioteke. Moe se uoiti da postoji mali broj interfejsa i veliki broj tokova podataka. Najee greke u ovoj
fazi dekomponovanja je dodavanje interfejsa koji predstavljaju deo sistema,
a ne spoljnji objekat s kojim sistem komunicira. Ovaj kontekstualni dijagram
sadri interfejs bibliotekar koji se naizgled moe razmatrati kao deo sistema.
Obino zabuna dolazi zbog toga to su entiteti kao bibliotekar zaista deo
stvarnog sistema. Meutim, bibliotekara nikako ne moemo smatrati delom
informacionog sistema biblioteke, ve ga razmatramo kao spoljnji objekat
koji, na primer zahteva da se prijavi prilikom poinjanja korienja IS, odnosno odjavi prilikom zavretka korienja sistema. Bibliotekar nije subjekat koji
vri registrovanje novih lanova i koji izdaje knjige na korienje lanovima
te aktivnosti su odgovornost sistema.
9.2.2. Dijagram toka podataka 0. nivoa

Nakon kreiranja kontekstualnog dijagrama sledi njegova dekompozicija
kroz dijagrame tokova podataka (Slika 9.15). Teite DTP 0. nivoa je identikacija osnovnih poslovnih procesa koji se deavaju u sistemu i distribuiranje
TP izmeu interfejsa i procesa. Pri kreiranju DTP 0. nivoa treba imati u vidu 3
vane 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 detaljnijim DTP i
Ne moraju biti prikazana sva skladita i poslovni procesi, jer se mogu
dekomponovati
69
Problem su dakle tokovi podataka, jer u sluaju velikog broja DTP 0. nivoa
postaje vrlo nepregledan. To je indikator da je sistem koji se modeluje metodama
SSA - preglomazan. U tom sluaju reenje je da se informacioni sistem u samom
poetku deli na vie komponenti nezavisnih softverskih modula. Tako e, na
primer IS velikog meunarodnog hotelskog sistema biti podeljen na IS za rezervacije, IS odravanja i nabavke, IS voenja kadrovskog sektora, IS za odravanje
bezbednosti. Tek onda je mogua SSA takvih sistema (kroz modelovanje pojedinanih komponenti).
Slika 9.15. Primer DTP 0. nivoa za IS medicinske klinike
9.2.3. Kompletan primer dekompozicije kroz DTP

U ovom poglavlju bie opisana dekompozicija DTP jednog spoljnotrgovinskog preduzea. Zapoinje se kontekstualnim dijagramom. Kontekstualni dijagram predstavlja sistem kao crnu kutiju koja interaguje sa okruenjem (interfejsima) posredstvom tokova podataka (Slika 9.16).
70
Slika 9.16. Kontekstualni dijagram za IS spoljnotrgovinskog preduzea

Teite modelovanja na kontekstualnom dijagramu je denisanje interfejsa i tokova podataka. Postoje etiri osnovna entiteta s kojima preduzee koje se
bavi spoljnom trgovinom interaguje: dobavlja, kupac, carina i banka. Dobavljai
i kupci mogu biti iz zemlje, ili inostranstva. Nabavci robe prethodi ugovaranje sa
dobavljaem, kako bi se pravno zatitile obe strane i kako bi nabavka iz inostranstva u procesu carinjenja bila razmatrana kao legalna. Sama nabavka se odvija
kroz dobro poznate TP: dobavlja dobija narudbenicu (dokument za naruivanje robe) na osnovu koje isporuuje robu uz fakturu (novana vrednost narudbe
koji modelovano preduzee mora da plati) i otpremnicu (dokument koji prati
porudbinu i na osnovu koga se vri provera kompletnosti i ispravnosti pristigle
robe; ovaj dokument se dalje moe koristiti za regulisanje skladitenja robe).
71
U sluaju da roba pristigne iz inostranstva ona se najpre carini. Preduzee

koje uvozi robu podnosi carini zahtev za carinjenje. Takoe podnosi se dokument
JCI (jedinstvena carinska isprava) koji predstavlja deklaraciju sa podacima o poreklu, nameni, sastavu koliini i vrednosti narudbine koja se carini. Interfejs carina
ispostavlja preduzeu fakturu za uplatu iznosa carine na uvezenu robu.
Nakon nabavke i carinjenja, roba se moe prodavati. Procesi nabavke i prodaje su veoma slini samo je uloga preduzea promenjena: prema dobavljaima,
preduzee je kupac, a prema kupcima ono prodaje robu. Poto se preduzee bavi
veleprodajom, kupovina se ugovara kao i prilikom nabavke. Nakon ugovaranja
kupovina zapoinje naruivanjem, zatim sledi isporuka robe uz fakturu i otpremnicu. esta greka koja se javlja u ovom sluaju da su tokovi podataka prema
dobavljaima i kupcima identino imenovani. Mora se naznaiti razlika, npr faktura_dob i faktura_kup. Ovo je neophodno jer, iako su strukture ovih dokumenata
gotovo identine, modelovano preduzee se nalazi u razliitim ulogama u odnosu
na svoje klijente (dobavljae i kupce).
U procesu modelovanja ne samo da treba uzeti stvarno stanje i funkcionisanje sistema. Poeljno je ve u fazi SSA, omoguiti proirenje i poboljanje kvaliteta delatnosti kojom se preduzee bavi. TP nabavke i prodaje mogu biti proireni u smislu poveanja kvaliteta usluga. Na primer TP katalog_dobavljaca
omoguava bolji kvalitet procesa nabavke. Ako postoje katalozi dobavljaa koji
sadre aurne podatke, IS moe na osnovu zadatih kriterijuma dati predlog za
najoptimalniju nabavku (npr. ukrtanje kriterijuma cena, isporuka, garancijski
period, postgarancijsko odravanje...). Isti tako katalog prema kupcima e sigurno
omoguiti kupcima da odaberu robu koja im najvie odgovara (najbolja reklama
je preporuka kupca drugima).
U poslovanju zikih i pravnih lica, sva plaanja odvijaju se preko poslovnih banaka. Tako da je ovaj interfejs gotovo nezaobilazan u modelovanju poslovnih
sistema. esta greka u modelovanju je da plaanja i potraivanja postoje, ali se
iskljuuje uloga banke, ve se umesto nje pojavljuju konkretni potraioci (u naem
sluaju to su dobavljai, carina, poreska uprava...). Banka predstavlja interfejs koji
posreduje izmeu strana koje uestvuju u novanim transakcijama. Preduzee u
banci izmiruje sva novana davanja preko TP uplata. Banka preduzeu dostavlja
periodino, ili po promeni razliite vrste izvetaja, koji mu omoguavaju upravljanje
vlastitim novanim sredstvima (izvod, priliv deviza, izvetaj o naplati).
Teite kod modelovanja DTP 0.nivoa (Slika 9.17) je na denisanju osnovnih poslovnih procesa i pridruivanju tokova podataka tim procesima. Na ovom
nivou dekomponovanja se pojavljuju i skladita podataka, koja samo treba da
istaknu grupisanje podataka. IS spoljnotrgovinskog preduzea sadri etiri osnovna poslovna procesa: nabavka, carinjenje, prodaja i plaanje.
72
Slika 9.17. DTP 0. nivoa za IS spoljnotrgovinskog preduzea

Proces nabavke obuhvata interakcije sistema sa dobavljaima, proces
carinjenja s carinom, proces prodaje obuhvata TP od i ka kupcima i proces
plaanje obuhvata interakcije prema banci. Mogu se uoiti skladita iji nazivi
impliciraju koje vrste podataka sadre. Proces carinjenja interaguje sa skladitem
73
dobavljai, koje je 2 put prikazano na istom dijagramu. Kopija je oznaena zvezdicom, i na taj nain su izbegnuta presecanja TP na dijagramu. Skladita su sa
procesima povezana internim, neimenovanim TP. Podrazumeva se da su ti tokovi
u potpunosti opisani spoljnim TP (izmeu procesa i interfejsa).
Zatim se vri dekompozicija osnovnih poslovnih procesa. Proces nabavke se dekomponuje na 3 podprocesa (Slika 9.18): narucivanje, prijem_robe i
skladistenje.
Slika 9.18. DTP 1. nivoa za proces nabavke

Takoe, pojavila su se 3 nova skladita, koja omoguavaju odvajanje
osnovnih podataka dobavljaa od tekuih podatka procesa nabavke. Svi tokovi
podataka su zadrani i konzistentni sa TP na DTP 0. nivoa. Novina na ovom dijagramu je direktna veza dva procesa (prijem robe i skladistenje). Proces skladistenje nema ni jednu direktnu vezu sa nekim spoljnim interfejsom, ali zato omoguava detaljnije snimanje procesa koji se odvijaju unutar sistema pri nabavci
robe. Skladitenje na DTP ne znai ziko smetanje robe u skladini prostor,
ve njeno evidentiranje, oznaavanje i odreivanje mesta gde e se roba uvati.
Na osnovu stanja zaliha IS moe da odredi kada i koliko je robe potrebno za
neometano poslovanje preduzea.
Iz dijagrama se moe uoiti da za predstavljanje TP nije obavezno koristiti
iskljuivo krive ili izlomljene linije. Mogue ih je kombinovati, u cilju postizanja
to bolje preglednosti i jasnoe dijagrama.
74
9.3. Renik podataka

Nakon zavretka dekomponovanja DTP, postoje svi potrebni uslovi za denisanje renika podataka. Renik podataka predstavlja skup podataka o podacima
koji se koriste u analiziranom sistemu. To su generalizovani podaci, esto u literaturi zvani metapodacima (metadata). Renik podataka obuhvata tri celine:
Opis struktura podataka koje se koriste u tokovima podataka,
Opis polja denisanih nad podacima i
Opis domena.
9.3.1. Definisanje struktura

Podaci koji se pojavljuju u interakcijama DTP izmeu interfejsa i procesa
su najee struktuirani. Uzrok tome je injenica da u sebi sadre elementarne
podatke razliitih osnovnih tipova (tekstualne, celobrojne, realni brojevi), a koji
su nerazdvojno vezani izolovani nemaju nikakvo znaenje. Na primer pojedinani podaci: smer, ocene poloenih ispita nemaju konkretan informacioni znaaj
ako nisu objedinjeni u jedinstvenoj strukturi student, kada dobijaju sasvim drugu 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>
75
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 denisanja struktura u reniku podataka
Na prethodnom primeru (Slika 9.19) strukture su imenovane (boldirane), a njihov sadraj predstavljen je uglastim zagradama < >. Moe se uoiti
da struktura u sebi sadri drugu ugnjedenu strukturu. Na primer, Student je
struktura koja se sastoji od 2 strukture: Osoba i Indeks. Strukture mogu sadrati i nabrojive elemente (nabrajanja - enumerations). Tako na primer, struktura Ispitni_spisak sadri listu studenata, to je notirano korienjem vitiastih
zagrada { }. Strukture mogu sadrati i opcione elemente. To su elementi koji se
mogu alternativno koristiti. Na primer struktura Ispitivac sadri dva opciona
elementa id_zapolsenog i broj_ugovora. Semantika ovih elementa je da ako
je ispitiva stalno zaposlen u prosvetnoj ustanovi, onda on ima identi kacioni
broj. Ako isti nije stalno zaposlen, da bi bio u statusu ispitivaa, mora da bude
ovlaen, to se regulie ugovorom izmeu u fakulteta i ispitivaa. Notacija
opcionih elemenata vri se pravougaonim zagradama [].
Na primeru (Slika 9.19) predstavljen je zavren renik podataka. Osnovno naelo pri denisanju struktura je da svi podaci koji se vezano viestruko
pojavljuju na vie mesta u reniku treba da se grupiu u imenovanu strukturu. Na
taj nain olakava se modikacija sistema jer, ako izmenimo podatak u strukturi, ta promena e se odraziti na sve izvedene strukture koji tu strukturu koriste.
Na primer ako se promeni nain davanja broja indeksa na fakultetu, to emo
76
uraditi samo na jednom mestu u strukturi indeks. Ta mala promena e se

odraziti meutim na sve strukture koji u sebi sadre 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, REZULTATI_ISPITA, JEDINACNI_REZULTAT !
Da broj indeksa nije denisan kao struktura, administrator podataka sistema bi morao da istu izmenu izvri na svim mestima gde se pojavljuju podaci
indeksa, to za kompleksnije sisteme moe da predstavlja problem.
9.3.2. Definisanje polja

Polja su zapravo osnovni podaci iz kojih su sainjene strukture koje su opisane u prethodnom paragrafu. Polja se deniu tako to im se dodeljuje naziv,
domen nad kojim su denisana i ogranienja.
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 , DOCENT, ASISTENT,ASISTENT PRIPRAVNIK)
Slika 9.20. Primer denisanja polja u reniku podataka

77
Na gornjem primeru (Slika 9.20) u prvoj koloni mogu se uoiti nazivi polja
koji se podudaraju sa nazivima osnovnih podataka u strukturama istog renika
podataka (Slika 9.19).
Domeni su predstavljeni u istoimenoj koloni. To su skupovi denisani nad
osnovnim ili izvedenim tipovima podatka. Nad domenima su denisana polja.
Ova indirekcija (polje > domen > tip) omoguava da se podaci precizno deniu.
Domeni mogu biti:
Predenisani denisani nad osnovnim, ili izvedenim sistemskim tipovima (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
Korisniki denisan domen (vidi sledei paragraf)
U treoj koloni su ogranienja koja precizno deniu opsege (skupove
ili intervale) u kojima se vrednosti podataka mogu kretati. U primeru (Slika
9.20) moe se uoiti da nije mogue denisati ogranienja nad svim poljima.
Nemogue je ograniiti spisak imena, prezimena studenata, ili unapred denisati
konaan skup predmeta koji e se realizovati na fakultetu. S druge strane nuno
je ograniiti skup moguih ocena koje student moe da dobije. est sluaj iz
srednjokolske prakse je da nastavnici pored ocena, u dnevnike upisuju take,
pluseve, minuse. Zamislite IS koji dozvoljava takve unose i kakve posledice bi to
imalo u proraunima pojedinanih i zbirnih uspeha uenika/studenata. Isto tako
uvoenjem ogranienja na nauna i nastavnika zvanja onemoguava neovlaeno denisanje i dodeljivanje novih, nepostojeih i nepropisnih titula i zvanja.
Sutina ogranienja je da ogranii korisniki unos na zadate vrednosti/intervale
i time sauvaju konzistentnost podataka.
9.3.3. Definisanje domena

Domeni mogu biti predefinisani ili korisniki definisani. Korisniki
definisani domeni su uvek izvedeni (korisnik je u ovom sluaju analitiar/
dizajner sistema). Za ovu vrstu domena moe se nai naziv semantiki to
znai da se njihovim definisanjem se blie odreuje smisao podataka (polja
koja ga koriste u svojoj definiciji). U primeru su navedena 2 izvedena domena: IDENTIFIKACIJA i NAZIV (Slika 9.21). Naziv domena je semantiki, jer
ukazuje na razlog definisanja: svi nazivi i imena u sistemu koriste u definiciji
domen naziv; domen identifikacija namenjen je jednoznanom odreivanju
entiteta u sistemu.
78
NAZIV DOMENA
PREDEFINISANI DOMEN
NAZIV
CHAR(25)
IDENTIFIKACIJA
CHAR(10)
OGRANICENJE
IS_UNIQUE_CODE
Slika 9.21. Primer denisanja domena u reniku podataka

Korisniki domeni se deniu nad osnovnim tipovima podataka u situaciji
kada se isti osnovni tipovi sa istim ogranienjima viestruko koriste pri denisanju
polja. Na gornjem primeru (Slika 9.20) - IME, PREZIME, PREDMET, NAUCNO_ZVANJE, NASTAVNICKO_ZVANJE, su polja denisana nad istim tipom
podatka i sa istom dimenzijom CHAR(25). Iz razloga lakeg auriranja, denisan
je domen NAZIV . Kada 25 karaktera postane malo za unos podataka navedenih
polja, promenom denicije domena NAZIV, automatski se menjaju i denicije
polja koja su denisana nad tim domenom. Na primer, ako sistem pree sa ASCII kodiranja podataka na korienje UTF-8 Unicode slovanog formata, kako
bi se podrala slova nacionalnih alfabeta, svaki ASCII 8-bitini karakter postaje
niz od 4 do 7 karaktera (32 do 56 bita), to znai da je potreban 4 do 7 puta vei
broj karaktera (naziv koji je sadrao 20 karaktera ASCII koda imae 80 do 140
karaktera u UTF-8 formatu). Drugi denisani domen je IDENTIFIKACIJA. Ovaj
domen se koristi za jednoznano oznaavanje objekata (instanci struktura) koji
ga poseduju. Zbog toga on poseduje ogranienje koje istie da svaki generisani
identikator mora biti jedinstven u sistemu.
79
Poglavlje 10.
Model objekti-veze (MOV)

Poeti kreiranje baze podataka nekog informacionog sistema, u sutini znai doi do kompleta CREATE naredbi kojima se denie ema baze podataka tabele, relevantni atributi, domeni, ogranienja, itd. U osnovi projektovanja baze
podataka je utvrivanje preciznog modela organizacije za koju se radi informacioni sistem. Kao i u ostalim inenjerskim disciplinama, sloenost ovakvog posla
zahteva da proces kreiranja bude izveden dobro denisanom metodologijom i da
bude testiran u skladu sa objektivnim kriterijumima. Jedan od najveih problema
u procesu razvoja BP je injenica da projektanti, programeri i krajnji korisnici na
potpuno razliite naine shvataju podatke i naine njihove upotrebe, kao i procese iz posmatranog okruenja koje treba modelirati. Da bi se obezbedio precizan
opis prirode podataka i naina na koji se oni koriste, potrebno je proizvesti jasan
model koji nije striktno tehnike prirode. Najee korieni 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 podataka je praktino proces u dva koraka. Poetna faza je bazirana na MOV modelu, a druga faza je implementacija. Rezultat MOV faze se redenie primenom
normalizacione teorije posle koje se garantuje kvalitet ema relacija u skladu sa
odgovarajuim kriterijumima. Tipian dizajn baze podataka obuhvata denisanje
skupova relacija, na stotine atributa, i mnogo ogranienja koja proistiu iz ogranienja u realnom svetu. Dizajniranje baze podataka zahteva dobar nivo kreativnosti, iskustva, tehnike ekspertize i razumevanje osnovnih pravila. Glavna komponenta MOV pristupa je koncept entiteta (objekata i veza) - opti pojam za neto
to postoji i moe se jednoznano prepoznati. Entiteti obuhvataju objekte koji se
81
nalaze u jednoj organizaciji, npr. studenti, profesori i predavanja na univerzitetu.

Dalje, entiteti obuhvataju i veze meu objektima jedne organizacije, na primer
profesor_predaje_predmet. Ogranienja integriteta eniteta i veza ine vaan deo
MOV opisa odnosno specikacije. Na primer profesor moe da predaje jedno
predavanje u odreenom vremenu u jednoj sali na fakultetu.
MOV modelovanje obuhvata:
Skup entiteta (objekti i veze)
Uoavanje ogranienja
Denisanje kljueva
Graka predstava (ER dijagram)
Denisanje atributa
Dizajn globalne eme
Svoenje globalne eme na tabele (relacije)
10.1. Dijagrami objekti-veze (DOV)

Dijagram objekti-veze (DOV 1)je grafika prezentacija povezanih entiteta i ogranienja koja ine dati dizajn odnosno projekat. Kao i kod ostalih
vizuelno orijentisanih dizajn metodologija, on prua grafiki saetak strukture baze podataka koji je veoma koristan dizajneru - ne samo u procenjivanju tanosti, odnosno pravilnosti dizajna, nego i za savetovanje sa kolegama i za objanjavanje programerima koji e je koristiti. Na alost, ne postoji
standardan plan za MOV dijagrame. Kada je jednom odreena organizacija
predstavljena setom DOV dijagrama, postoje klasini naini koji dijagrame
pretvaraju u skupove CREATE TABLE naredbi. Vana prednost ove metodologije je da dizajner moe da se usredsredi na celokupno i tano modelovanje
organizacije, a da efikasnost izvravanja zadatih upita i auriranja u odnosu
na krajnju bazu podataka stavi u drugi plan. Kasnije, kada se MOV dijagrami
pretvore u CREATE naredbe, dizajner moe dodati efikasnost koristei teoriju normalizacije polaznih ema relacija.
1
82
U originalu: ERD entity relationships diagrams
U DTP (dijagramima tokova podataka) koji su analizirani u prethodnom poglavlju nisu prikazane nikakve veze izmeu tokova podatka, odnosno
izmeu skladita podataka. U stvarnosti te veze postoje, a oigledan dokaz
njihovog postojanja su renici podataka. Na primer struktuirani tip NARUDZBENICA sadri podatke dobavljaa, podatke artikala koji se naruuju i
podatke naruioca. 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. Objekti
Objekti grupiu srodne podatke. Mogu predstavljati entitete iz realnog sveta, interfejse iz DTP, strukture iz renika podataka, ali mogu biti i isti fabrikati, koji samo treba da istaknu povezanost razliitih podataka pri procesiranju
u sistemu. Entitet objekat egzistira nezavisno i moe predstavljati ziki, realni
objekat (npr. Sredstvo) ili konceptualni, apstraktni objekat (npr. Radno iskustvo).
Objekat se identikuje nazivom i listom svojstava, a graki se predstavlja kao
pravougaonik u kome se ispisuje naziv entiteta, koji je najee imenica.U DOV
se razlikuju takozvani jaki i slabi objekti.
Slika 10.1. Primer oznaavanja objekata

Na primeru oznaavanja objekata (Slika 1), narudbenica je prikazana
kao jak a stavka narudbenice kao slab objekat. Izmeu jakog i slabog objekta
postoji identikaciona i egzistencijalna zavisnost to znai da stavka narudbenice ne moe postojati u skladitu podataka ako ne postoji narudbenica koja
ju identikuje.
83
10.3. Atributi
Atributi su osobine (svojstva) entiteta. Atribut podrazumeva ime i vrednost
svojstva (npr. atribut boja i njegova vrednost plavo). Entitet se opisuje pomou
jednog ili vie svojstava (atributa). Atributi su podaci osnovnog tipa, ili predenisani domeni. Oznaavaju se elipsoidima i povezani su pravolinijskim konektorima
sa objektima (Slika 2).
Slika 10.2. Primer oznaavanja atributa objekata

Broj atributa objekata nije ogranien, kao ni pozicija na kojoj e se atributi
uneti u dijagram.
10.4. Veze
Veze su najvaniji deo DOV, jer deniu naine na kojima su objekti uzajamno povezani. Veze se imenuju i njihovi nazivi oslikavaju sematniku povezanosti izmeu objekata (Slika 10.3). Pored imena, vezu potpuno denie njena
kardinalnost. Kardinalnost predstavlja odnos broja objekata koji se povezuju.
Odreivanje kardinalnosti se uglavnom vri prouavanjem veza i odnosa izmeu
posmatranih objekata. Kardinalnosti moe biti:
Jedan prema jedan (1:1) - na primer jedna uplata dobavljau se vri po
tano jednoj fakturi dobavljaa (Slika 10.3).
84
Jedan prema vie (1:*) - na primer jedna narudbenica sadri vie stavki
narudbenice (Slika 4).
Vie prema vie (*:*) - vie dobavljaa ima ugovore sa vie peditera.
Slika 10.3. Primer imenovane veze izmeu entiteta

U situacijama kada su veze izmeu objekata implicitno jasne, radi utede u prostoru na dijagramu, veze se ne moraju imenovati. Veza uglavnom ima
samo jednosmerni smisao, pa je uobiajeno da se iscrta i strelica koja oznaava
pravilan smer.
Slika 10.4. Primer neimenovane veze

Na primeru narudbenice, implicitno je jasno da se ona sastoji od stavki
narudbenice (Slika 10.4). Kardinalnost veze od jakog prema slabom objektu je
uvek jedan (jedan jak objekat egzistencijalno odreuje vie slabih objekata).
Broj entiteta koji uestvuju u vezi se naziva stepen veze. Veza u kojoj uestvuju dva entiteta se naziva binarna, veza treeg stepena (uestvuju tri entiteta) se
naziva ternarna, itd. Veza u kojoj jedan entitet uestvuje vie puta u razliitim
85
ulogama naziva se rekurzivna ili unarna veza. Na primer, ako je uoen entitet
Zaposleni, jedan od zaposlenih je i magacioner. Magacioner izdaje sredstva zaposlenima pa se uoava veza IzdajeSredstvo. Po nekada magacioner mora i sebi da
izda sredstvo. Drugim reima, enetitet Zaposleni uestvuje dva puta u vezi IzdajeSredstvo: prvi put kao magacioner koji izdaje sredstva drugima, a drugi put kao
jedan od zaposlenih kome takoe moe da se izda sredstvo.
Slika 10.5. Primer rekurzivne veze

Pored osnovnog, postoji i proireni model objekti veze, koji omoguava
detaljnije denisanje veza izmeu objekata. Pored asocijativnih veza predstavljenih
na prethodnom primeru, koje treba da oslikaju semantiku udruivanja objekata u
sistemu, postoje i specine veze kojima se izraava hijerarhija i komponovanje
objekata. Postoje dve reprezentativne vrste ovakvih veza:
Generalizacija/specijalizacija - na primeru iz renika podataka iz prethodnih lekcija, strukturom OSOBA izvrena ja generalizacija podataka
studenata i ispitivaa; oba entiteta poseduju ime, prezime i matini broj
graana. Sve tri strukture se prevode u DOV i predstavljene su kao tri
entiteta (Slika 10.6). Izmeu njih se uspostavlja veza koja je imenovana
kao vrsta. Smer veze predstavlja smer specijalizacije. To znai da su studenti i ispitivai samo specini sluajevi (konkretizacije) entiteta OSOBA. Obrnuti smer je smer generalizacije. Osoba je generalni objekt kojim
su obuhvaeni atributi zajedniki za sve specijalizovane klase. Na ovaj
nain, izbegnuto je redundantno prikazivanje jmbg, imena i prezimena
u specijalizovanim objektima podrazumeva se da oni nasleuju ove
atribute od entiteta OSOBA.
86
Slika 10.6. Veze generalizacija/specijalizacija i agregacija/dekompozicija

Agregacija/dekompozicija - agregacija je zapravo veza koja se tretira kao
objekat i moe da uestvuje u vezama sa drugim objektom. Agregati su objekti
sastavnice koji semantiki povezuju dva ili vie drugih objekata u DOV. Agregirani objekat se oznaava simbolom upisanog romba u pravougaonik, ime se
izraava njegova dvojaka priroda. Agregati su veoma povoljni za preciznije denisanje veza koje imaju kardinalnost vie-vie. Poto su ovi tipovi veza teki za
odravanje referencijalnog integriteta, onda se veza pretvara u objekat, koji ima
kardinalnost jedan-vie prema susednim objektima.
Zbog svoje dvojake prirode, agregati su uglavnom slabi objekti jer egzistencijalno zavise od dva ili vie drugih objekata koji ih jednoznano odreuju
(izuzetak je agregacija na sebe; na primer neko sredstvo moe da se sastoji od vie
objekata koji su takoe tipa sredstvo; u toj situaciji kompozit ne mora da bude
87
slab objekat, jer postoje sredstva koja mogu da budu, ali nisu kompoziti). Agregati
imaju svoje atribute, mogu da budu u vezama drugog tipa (generalizacije/specijalizacije) sa nekim drugim objektima (mogue agreiranim, takoe).
10.5. Primer
Na narednoj slici predstavljen je primer DOV (Slika 10.7). Pri modelovanju
DOV, polazi se od DTP i renika podataka, kojima se opisuje odreeni poslovni
proces. Na osnovu interfejsa i tokova podataka (TP) iz DTP, deniu se objekti. TP
su dekomponovani u reniku podataka kao strukture.
Slika 10.7. Primer dijagrama objekti veze za proces nabavke

88
Elementi strukture (polja) su atributi objekata. Ako je element ugnjedena struktura (struktura u strukturi) ona se predstavlja kao drugi objekti koji se
nalaze u vezi (na primer narudbenica i stavaka narudbenice, ispitni spisak i
pojedinani rezultat).
Ove veze su obino implicitne i predstavljena im je samo kardinalnosti i
usmerenost. Zatim sledi denisanje preostalih veza izmeu objekata. Veze se imenuju i odreuje im se kardinalnost.
Opis DOV (Slika 10.7): u procesu nabavke, formira se narudbenica (objekat
NARUDZBENICA_DOB), kojom se potrauje roba od odreenog dobavljaa
(objekat DOBAVLJAC). Za svaki artikal koji se nabavlja (objekat ARTIKAL), formira se jedna stavka narudbenice (slabi objekat STAVKA_NAR_DOB). Pored
podataka artikla, stavka sadri i koliinu koja se nabavlja (nar_kol). Kreirana narudbenica se alje dobavljau i on na osnovu nje isporuuje robu, uz koju alje
fakturu - raun za naplatu (objekat FAKTURA_DOB). Kupac po fakturi vri uplatu dobavljau (objekat UPLATA_DOB), a potvrdu (kopiju) o uplati alje dobavljau, kao dokaz izmirenja svojih obaveza.
Model objekti veze omoguava potpunije shvatanje funkcionisanja sistema semantikim opisom objekata i njihovih uzajamnih veza. Korienjem DOV
pojednostavljuje se prevoenje logikog u ziki model podatka.
Model objekti veze je kompatibilan sa UML2 dijagramom klasa, to znai
da pored modelovanja podataka (data layer), omoguava i objektno orjentisano
modelovanje aplikacione logike (buisness logic layer).
UML Unied modeling language standard za objektno-orjentisano modelovanje IS

kroz razliite tipove dijagrama
89
Poglavlje 11
Relacioni model podataka

Relacioni model podataka predstavlja teorijsku osnovu za baze podataka
relacionog tipa. Njegovi principi i struktura predstavljeni su 1970. godine od strane Edgara T. Koda. Istraivanje i razvoj baza podataka 70 i 80 godina prolog
veka su bili pod velikim uticajem ideja prezentovanih u Kodovim originalnim
delima. Do danas, veina komercijalnih DBMS-ova se zasniva na relacionom
modelu, iako poinju da se ukljuuju objektno-orjentisane opcije, pogotovo zbog
ire upotrebe podataka baziranih na XML-u.
Relacioni model podataka ima podlogu u jednostavnoj i prirodnoj matematikoj strukturi relaciji (tj. tabeli). Relacije imaju niz monih operatora srodnih
prirodnom jeziku, a jezici za manipulaciju relacionim podacima su zasnovani na
matematikoj teoriji relacionoj algebri. Ova vrsta matematika osnova znai
da relacioni izrazi (tj. upiti) mogu da se analiziraju. Zbog toga, svaki upit moe
biti transformisan (od strane samog DBMS-a) u neki drugi ekvivalent, izraz koji
moe biti ekasnije izvren, u procesu zvanom optimizacija upita. Dalje, programeri aplikacija ne moraju da poznaju unutranjost svake baze podataka do
najsitnijih detalja i ne moraju biti svesni naina na koji funkcionie izvravanje
upita. Aplikativni programer moe da formulie upit na jednostavan i prirodan
nain, a optimizatoru upita da prepusti traenje ekvivalentnog upita koji e se
najekasnije izvriti.
Meutim, optimizatori upita imaju ogranienja koja mogu rezultovati loijim performansama, a pogotovo za kompleksnije upite. Zbog toga je bitno i za
programere i za dizajnere baza da razumeju logiku koju koriste. Sa ovim znanjem programeri mogu da formuliu upite koje e DBMS lake da optimizuje, a
91
dizajneri baza mogu da ubrzaju obradu vanih upita dodavanjem odgovarajuih

indeksa i korienjem drugih tehnika.
11.1. Istorija i razvoj

Kao i mnoge druge tehnologije u raunarskoj industriji, koreni relacionih
baza podataka potiu iz IBM-a i njihovog istraivanja automatizovanja kancelarijskog poslovanja u 60-tim i 70-tim godinama XX veka. U tom periodu velike
organizacije su uvidele da postaje preskupo da zapoljavaju ogroman broj ljudi za
poslove kao to su smetanje i indeksiranje dokumenata, i da vredi ulagati u razvoj
jeftinijih i ekasnijih rjeenja. Mnoga istraivanja su izvedena u toku ovog perioda. Razvijeni su hijerarhijski, mreni i relacioni model, a pojavom mikroprocesora, kao i razvojem memorijskih komponenata, raunarska tehnologija je poela
naglo da se razvija. Performanse novih raunara su neprestano poveavane, to je
praeno i padom cena raunarskih komponenata.
1970. godine, IBM-ov istraiva Edgar Ted Codd je objavio prvi rad o relacionim bazama podataka A Relational Model of Data for Large Shared Data Banks.
Ovaj rad je dao osnove za korienje relacionog rauna i algebre da bi se tehniki
neobrazovanim korisnicima omoguilo da smetaju i pretrauju velike koliine
informacija. Codd je zamislio sistem u kojem e korisnik biti u mogunosti da
podacima u bazi podataka pristupi komandama slinim reima na engleskom, i
gde e podaci biti smeteni u tabelama.
Zbog same tehnike prirode rada i oslanjanja na matematiki aparat, njegova
vanost nije odmah shvaena. Ipak, doveo je do formiranja IBM-ove istraivake
grupe System R. Od projekta System R se oekivalo da stvori sistem relacione baze
podataka koji bi mogao postati proizvod. Prvi prototip, prezentovan 1974/75.
godine je eksperimentalno korien u nekoliko organizacija. 1978. i 1979. godine
radne viekorisnike verzije su testirane u proizvodnji i knjigovodstvu u nekoliko aeronautikih 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.
92
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.
Softver za relacione baze podataka se kontinuirano usavravao tokom
80-tih. Delom putem povratnih informacija od kupaca, a delom zbog razvoja
raunarskih sistema i poveane upotrebe personalnih raunara i distribuiranih
sistema. Prve baze podataka su imale mogunost rada sa podacima veliine do
8 MB (Sistem R). Dananje baze podataka mogu biti i veliine terabajta ili petabajta podataka kada sadre podatke za mailing liste, informacije o kupcima za
veleprodajne lance itd.
SQL standard je preao 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. Kljuni koncepti

Iako je osnovna ideja relacionog sistema upravljanja bazama podataka
veoma popularna, veoma mali broj ljudi razume matematiku deniciju, a
samo neki veoma komplikovani sistem upravljanja. ORACLE, na primer, moe
da se koristi na potpuno relacioni nain, ali isto tako on dozvoljava tabelama
da budu denisane tako da se mogu pojaviti dupli redovi to je proirenje
(ali i destrukcija) relacionog modela. Sistem upravljanja bazama podataka se
naziva relacionim ako podrava relacione operacije, bez obzira da li se striktno
dri relacionog modela.
Nakon to je denisan relacioni model, napravljeni su neformalni modeli
da bi se opisali hijerarhijski i mreni model. Hijerarhijske i mrene baze podataka
su postojale pre relacionih baza podataka, ali su kao modeli opisani tek nakon to
je relacioni model denisan, da bi se napravila osnova za poreenje.
U srcu relacionog modela nalazi se koncept tabele (koja se pod odreenim
uslovima naziva i relacija) u kojoj su smeteni svi podaci. Svaka tabela je nainjena od slogova (redova u tabeli) i polja (kolona u tabeli, atributa).
Veoma je vano zapaziti da kako i gde su tabele smetene ne pravi nikakvu razliku. Svaka tabela se identikuje jedinstvenim imenom koje baza podataka
93
koristi da bi pronala tabelu. Korisniku je potrebno samo da zna ime tabele. Nema
potrebe da se vodi rauna o tome kako su podaci smeteni na disku. Ovo je razliito od hijerarhijskog i mrenog modela u kojima korisnik mora da razume kako
su podaci struktuirani unutar baze podataka da bi mogao da ih pretrauje, umee
nove, aurira ili brie slogove.
Relaciona baza podataka standardno se sastoji iz vie tabela. Ipak, za razliku od mrene baze podataka, tabele nisu povezane pokazivaima. Umesto toga
koriste se kljuevi da upare redove podataka u razliitim tabelama. Klju je
samo jedna ili vie kolona u tabeli, koja odgovara kolonama u drugim tabelama.
Bilo koja od kolona u tabeli moe biti klju (ako ispunjava odreene uslove) ili se
vie kolona moe grupisati u jedan klju. Za razliku od pokazivaa, nije potrebno
da se deniu svi kljuevi unapred; kolona se moe koristiti kao klju ak iako
originalno nije bila namenjena za to.
Kada klju sadri podatke koji imaju eksterno, stvarno znaenje (kao
to je ime osobe, ISBN kod knjige ili serijski broj automobila), takav klju
se naziva prirodni klju. Ako prirodni klju nije pogodan, moe se dodeliti klju (npr. davanje identifikacionog broja zaposlenim ili redni broj unosa
podataka). U praksi, veina baza podataka ima oba i generisane i prirodne
kljueve, jer generisani kljuevi mogu da se koriste interno da bi se stvorile
veze izmeu redova koji se ne mogu prekidati, dok se prirodni kljuevi koriste, 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 matinom broju, osim u sluajevima kada je JMBG pogrean,
nedostaje ili je promenjen).
Zahtev za podatkom iz relacione baze podataka se dobija slanjem upita koji
je napisan u posebnom jeziku, obino nekom od dijalekata SQL-a. Iako je SQL
originalno namenjen za krajnje korisnike, mnogo ee se SQL upiti ugrauju
u softver koji omoguava laki korisniki interfejs. Kao odgovor na upit, baza
podataka vraa skup podataka, koji je u stvari lista redova koji sadre odgovor.
Najjednostavniji upit je da se dobiju svi redovi iz tabele, ali ee, redovi se ltriraju na neki nain da bi se dobio traeni odgovor. esto se podaci iz vie tabela
kombinuju u jednu, procesom udruivanja.
Konceptualno, ovo se radi uzimanjem svih mogui kombinacija redova (proizvod ukrtanja), a zatim izbacivanjem svega osim odgovora. U praksi,
94
relacioni sistem upravljanja bazama podataka optimizuje upite da bi se obavljali

bre, korienjem razliitih tehnika: U udruivanju primarna optimizacija se
dobija korienjem indeksa da bi se spreila izgradnja kompletnog proizvoda
ukrtanja, koji bi inae bio neophodan.
Fleksibilnost relacionih baza podataka dozvoljava programerima da piu
upite koji nisu bili predvieni od strane dizajnera baze podataka. Kao rezultat, relacione baze podataka mogu da se koriste u vie aplikacija koje originalni
dizajneri nisu predvidjeli, to je posebno vano za baze podataka koje se mogu
koristiti decenijama. Ovo je model relacionih baza podataka uinilo veoma popularnim u poslovnoj primeni.
11.3. Objekti u relacionom modelu podataka

Model podataka je formalni sistem iji su osnovni elementi:
objekti (entiteti);
pravila integriteta (ogranienja);
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, klasa studenata jednog fakulteta predstavlja skup svih studenata (entiteti) na datom
fakultetu. Ova klasa se moe predstaviti tabelom STUDENT.
Svaki entitet poseduje svojstva. Svojstva entiteta se nazivaju atributi. Atributima dajemo znaenje pojedinanim podacima. Relacioni model razlikuje proste
(jednostavne) i sloene atribute.
Pojedinaan podatak (prost atribut) je najmanja nedeljiva jedinica u relacionom modelu. Pojedinani podaci su Beograd, 125, Marko i td. Ako bi podelili
bilo koji od pojedinanih podataka on bi izgubio prvobitni smisao. Na primer
podatak Marko moemo deliti na slogove ali dobijeni slogovi nemaju znaenje
koje je imao podatak pre podele.
95
Skup svih moguih vrednosti nekog atributa nazivamo domenom atributa.

Skup svih moguih gradova je domen atributa GRAD. Skup svih moguih boja je
domen atributa BOJA itd. Svaki atribut mora imati samo jedan pridrueni domen.
Vie razliitih atributa moe se zadati nad istim domenom. Na primer, atributi MESTO_BORAVKA i MESTO_ROENJA imaju isti domen. Takoe atributi
IME_STUDENTA i IME_PROFESORA imaju isti domen.
Relacioni model podataka poiva na nekoliko formalnih pojmova.
11.3.1. ema relacije

ema relacije R, u oznaci R(A1,A2,...,AN), je konaan skup atributa
{A1,A2,...,AN} i konaan skup ogranienja nad vrednostima tih atributa. Kako je
ema relacije denisana preko skupa, redosled atributa nije bitan i svaki naziv
atributa je jedinstven u okviru eme relacije (ne moe se ponoviti isto ime atributa
u jednoj emi relacije).
emom relacije se predstavljaju svojstva klase objekata ili veza nekog sistema. ema relacije moe da se tumai i kao denicija strukture neke datoteke.
11.3.2. Relacija
Relacija r zadata nad emom relacije je konaan skup n-torki eme relacije R.
Posledica denicije relacije je da imamo sledee 4 osobine:
Nazivi atributa u emi relacije moraju da budu razliiti
Redosled kolona u emi relacije nije bitan.
Relacija ne sadri dve jednake n-torke.
Redosled n-torki nije bitan.
Kako je relacija skup n-torki i sve n-torke su iste duine, u relacionom
modelu n-torke ne mogu imati promenljivu duinu.
Jednostavnije reeno, ema relacije je opis strukture jedne tabele, a sama
relacija je sadraj te tabele. Naravno, da bi takva tabela bila relacija potuju se gore
navedena ogranienja. Relaciji u praksi odgovara jedna datoteka, a svakoj n-torki
odgovara jedan slog te datoteke. Slogovi u datoteci su zapisani u odreenom redosledu, najee po redosledu unoenja
96
Primer: ema relacije kojom se opisuje klasa studenata, gde su relevantni

atributi Broj indeksa i Ime studenta, moe da bude:
STUDENT (BrInd Ime),
a relacija nad ovakvom emom u jednom trenutku moe da bude:
student
(BrInd
123/02
11/03
151/02
III-15/04
Ime)
J.Jankovic
P.Petrovic
J.Jovanovic
M.Markovic
11.3.3. Relaciona baza podataka

Relaciona baza podataka je konaan skup relacija koje su denisane odgovarajuim emama relacija {Ri} i konaan skup ogranienja koja vae izmeu
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 vie atributa i to je jedan od prvih
pojmova u relacionom modelu koji se koristi za pouzdan (siguran pristup) eljenim podacima. U sutini, baze podataka postoje da bi se u njih smetali podaci,
ali pristup eljenim podacima mora biti nepogreiv. Na osnovu kandidat kljua
mogu se pouzdano razlikovati dve n-torke u jednoj relaciji.
Iz denicije relacije sledi da je svaka n-torka u relaciji je jedinstvena. Znai,
postoji podskup K skupa atributa eme relacije (u najgorem sluaju to su svi atributi iz eme relacije), takav da za dve razliite n-torke t1 i t2 postoji atribut AiK
sa osobinom t1(Ai) t2(Ai). Obino u jednoj relaciji moemo nai vie takvih
podskupova atributa i njih nazivamo kandidat kljuem.
Denicija: Neka je data ema relacije R. Podskup KR je kandidat klju za
R ukoliko zadovoljava osobine:
- Jednoznanost: za svake dve razliite n-torke t1 i t2 postoji AiK takav
da je t1(Ai) t2(Ai).
- Minimalnost: ne postoji pravi podskup K od K sa osobinom jednoznanosti.
97
11.3.5. Primarni klju

Izborom jednog kandidat kljua koji nam slui za identikaciju n-torki u
odgovarajuoj relaciji, biramo njen primarni klju. U relacionom modelu podataka primarni kljuevi se obeleavaju (podvlaenjem ili se npr. u Accessu posle naziva upisuje znak ). Ostale kandidat kljueve nazivamo alternativnim kljuevima.
Primarni klju se moe sastojati iz jednog ili vie atributa.
U emi relacije DOBAVLJA(SIFD, IME, GRAD, STATUS); SIFD je primarni klju. U emi relacije STUDENT(BR_IND, IME ADRESA, SMER, REDNI_BR_S) imamo dva kandidat kljua BR_IND i {SMER, REDNI_BR_S}. Primarni 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 reprezentuje vezu iz realnog sveta koja postoji izmeu dobavljaa i odreenih 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
vie atributa).
Posmatrajmo emu relacije RADNIK(SIFR, IME, SIF_ODELJENJA, SIF_
RUKOVODIOCA). Primarni klju relacije je atribut SIFR. Svaki radnik ima rukovodioca, 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 moemo dodati i adresabilnost. Svaka kolona u relaciji jednoznano je odreena nazivom atributa. Svaka n-torka jednoznano je
odreena vrednou primarnog kljua te n-torke. Svaki pojedinaan podatak jednoznano je odreen:
nazivom relacije
nazivom atributa
vrednou primarnog kljua
Atribute koji pripadaju primarnom kljuu nazivamo primarnim atributima. Ostale atribute nazivamo sporednim atributima.
98
11.3.6. Spoljni klju

Uloga spoljnih kljueva je prvenstveno u uspostavljanju veza izmeu relacija. Za atribute SIFD i SIFA u relaciji NABAVKA i atribut SIF_RUKOVODIOCA
u relaciji RADNIK kaemo da su spoljni kljuevi, jer su im vrednosti iz aktivnih
domena primarnih kljueva iz druge ili iste relacije. SIFD i SIFA su primarni kljuevi iz drugih relacija, dok je SIF_RUKOVODIOCA zadat na domenu primarnog
kljua iz iste relacije. SIF_ODELJENJA je takoe spoljni klju.
Denicija: Ukoliko je neki atribut u relaciji zadat na domenu primarnog
kljua iste ili druge relacije, taj atribut nazivamo spoljnim kljuem relacije. Spoljni
klju u emi relacije R je svaki njen podskup atributa za koji vai ogranienje
vrednosti u relaciji r na sledee dve vrednosti:
vrednost primarnog kljua u nekoj relaciji (tzv. ciljnoj relaciji)
vrednost NULL
Za spoljni klju SIFD u relaciji NABAVKA(SIFD,SIFA,KOL) kaemo da se
referencira na primarni klju SIFD u relaciji DOBAVLJA. Za spoljni klju SIF_
RUKOVODIOCA kaemo 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 moe da sadri vie spoljnih kljueva. Spoljni klju moe
biti u sastavu primarnog kljua. Spoljni klju jedne relacije moe istovremeno biti
i primarni klju date relacije u celini Spoljni klju se moe ili se ne mora obeleavati - obeleavanje doprinosi preglednosti modela
11.4. Integritet podataka u relacionom modelu

Kroz istoriju razvoja relacionog modela podataka najvee izmene je
pretrpeo integritet podatka. Jedan od razloga je i to to ova oblast nije precizno utemeljena kao to su precizno zasnovani objekti relacionog modela i
operacije nad objektima.
Integritet (konzistentnost) baze podataka je ispravnost i istinitost podataka sadranih u bazi. Neispravni podaci mogu biti posledica auriranja (unoenja i brisanja podataka) bilo namernog, bilo nenamernog od strane korisnika u
99
sluajevima kada je relacioni model loe denisan. Integritet podataka u irem

smislu podrazumeva sve mere kojima je cilj da sprei unos neispravnih podataka. Mere za spreavanje sluajnih pogreaka se znaajno razlikuju od mera za
spreavanje namernih aktivnosti. Iz integriteta baza podataka izuzete su sve
mere kojima je cilj spreavanje ilegalnih operacija. One su predmet izuavanje
posebne oblasti koja se odnosi na zatitu podataka.
Pravila integriteta su ogranienja sadraja baze podataka na neka
dozvoljena stanja. Cilj je spreavanje unosa neistinitih i neispravnih podataka
u bazu. Sva auriranja, brisanja i ubacivanja n-torki moraju biti u skladu sa
tim ogranienjima. Ako se ta pravila ispotuju, ne mora da znai da je uneti
podatak ispravan, ali ukoliko se ne ispotuju, onda je podatak koji se unosi
sigurno neispravan.
Pravila integriteta delimo u dve grupe:
Korisnika pravila integriteta.
Opta pravila integritera;
11.4.1. Korisnika pravila integriteta

Ova pravila zavise od konkretne baze. Ona su specina za konkretnu realizaciju baze i proistiu iz ogranienja koja vae i u realnom svetu. Posmatrajmo
bazu koja ima relacije:
STUDENT
(BR_IND,
IME,
PREZIME,
0001
Marko Anti
.......................................
ADRESA,
Tolstojeva 21
PREDMET
(SIFP,
01
B)
2
OCENE
(BR_IND,
SIFP,
OC)
0001
01
8
.......................................
NAZIV,
Programiranje
.......................................
GODINA SMER,
2
PP
RB)
1
Moemo nad tim relacijama postaviti sledea korisnika pravila integriteta:

BR_IND ima vrednost oblika nnnn tako da je podatak iz intervala 00019999.
IME i PREZIME vrednost su podaci koji sadre slova ili prazninu.
100
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 izmeu 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 izmeu 2 i 4.
OC ima vrednost od 5 do 10.
Pri deniciji pravila integriteta koristimo razna ogranienja koja atributi

mogu da uzimaju. Sva ogranienja nad atributima moemo podeliti u dva skupa:
nezavisna ogranienja
zavisna ogranienja.
U naem primeru sva navedena ogranienja su nezavisna, tj. vrednost se
denie iskljuivo na osnovu semantikog znaenja atributa za koji deniemo
ogranienje.
Posmatrajmo relaciju zadatu nad relacionom emom:
RADNIK(SIFR, IME, PREZIME, STA, STAROST).
Vrednost atributa STA nije nezavisna, ve zavisi od vrednosti atributa
STAROST. Ne moe da postoji radnik kome je starost 25 godina, a sta 20 godina. U ovom sluaju morali bismo da deniemo ogranienje za atribut STA i u
zavisnosti od vrednosti atributa STAROST. Ovo je tipina relacija koja ima lou
strukturu to je posledica odabrane eme relacije u kojoj jedan atribut zavisi od
drugog. Ovakve probleme tretira posebna oblast (zavisnost i normalne forme).
Relacije loe strukture se mogu popravljati u postupku koji se zove normalizacija.
Normalizacijom se od relacije loe strukture formiraju dve ili vie relacija u kojima se dekomponuju zavisni atributi.
11.4.2. NULL vrednost

Posebnu ulogu u denisanju optih 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 mesta boravka u kome nema matinog fakulteta i jo nije odluio da li e biti u
101
domu ili u privatnom smetaju. U ovom sluaju umesto da vrednost atributa

ADRESA bude adresa studenta, vrednost atributa e biti NULL. Ovo je sluaj
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 teko
ili skoro nemogue saznati. I u ovom sluaju umesto konkretne vrednosti za
podatak unosimo NULL vrednost.
11.4.3. Opta pravila integriteta

Opta pravila integriteta su sastavni deo relacionog modela podataka i
sastoje se iz dva pravila:
Identikacioni (egzistencijalni) integritet;
Referencijalni integritet.
Pravila su vezana za dozvoljena stanja primarnih kljueva i spoljnih kljueva u bazi. Primarni klju slui za identikaciju entiteta koje opisujemo n-torkama
u relaciji, pa je jasno da su pravila o dozvoljenim stanjima tih atributa stroija od
pravila za obine atribute.
11.4.4. Identifikacioni integritet

Odnosi se na opta ogranienja za primarni klju relacije. Ve smo u denisanju primarnog kljua zahtevali minimalnost i jednoznanost. Vrednost primarnog kljua jednoznano odreuju n-torke i ne moe se iz njega izbaciti ni jedan
atribut, a da on i dalje poseduje jednoznanost. Ovim dobijamo uslov za integritet
primarnog kljua:
Ni jedna komponenta primarnog kljua relacije ne sme imati NULL
vrednost.
11.4.5. Referencijalni integritet

Referencijalni integritet se odnosi na dozvoljena stanja spoljnih kljueva.
Ako posmatramo relacije DOBAVLJA, NABAVKA i ARTIKAL, onda za ntorke iz NABAVKE kaemo da se referenciraju na relaciju DOBAVLJA. One
takoe vre referenciranje na relaciju ARTIKAL. esto kaemo za n-torku iz
relacije NABAVKA da je pozivajua, a njoj odgovarajua u relaciji DOBAVLJA
je ciljna n-torka.
Posmatramo li relaciju RADNIK, RADNA_JEDINICA, onda bi n-torka u relaciji RADNIK bila pozivajua, a direktori u radnim jedinicama bili bi
102
ciljne n-torke. N-torka u relaciji RADNIK mogla bi da bude i ciljna i pozivajua.

Direktor kao radnik pripada odgovarajuoj radnoj jedinici, pa u tom sluaju on
je pozivajua n-torika za pripadajuu radnu jedinicu. Sa drugre strane, n-torka
radne jedinice u kojoj je radnik rukovodilac je pozivajua, a njena ciljna je radnik koji joj je rukovodilac.
Uslov referencijalnog integriteta se moe denisati na sledei nain:
Baza podataka ne sme da sadri ni jednu nepovezanu vrednost za spoljni
klju. Znai, vrednost spoljnog kljua moe biti ili NULL vrednost ili
vrednost primarnog kljua odgovarajue 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 identikacioni integritet (ni jedna komponenta ne sme imati NULL vrednost). Sa druge strane, SIFD i SIFA su spoljni kljuevi na odgovarajue atribute
u ciljnim relacijama, znai u n-torci moraju da postoje vrednosti za te kljueve 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_RUKOVODIOCA je spoljni klju relacije a time e direktoru biti uneta NULL vrednost.
Sutina referencijalnog integriteta je u ograniavanju vrednosti stranog
kljua. Sa stanovita izmena (auriranja) u relaciji koja sadri spoljni klju (pozivajua relacija) to podrazumeva da vae sledea ogranienja:
Ne moe se uneti n-torka sa vrednou stranog kljua koja nije jednaka
nekoj vrednosti primarnog kljua u ciljnoj relaciji ili NULL vrednosti.
Ne moe se izmeniti n-torka tako da vrednost stranog kljua ne bude
jednaka nekoj vrednosti primarnog kljua u ciljnoj relaciji ili NULL
vrednosti.
Sa stanovita ciljne relacije vai sledee:
Dodavanje nove n-torke (u ciljnoj relaciji) ne naruava referencijalni
integritet - nastaje samo nova vrednost primarnog kljua
Uklanjanjem n-torke (a izmena ponekad) dovodi do nestanka jedne
vrednosti primarnog kljua. Ako bi se ta operacija izvravala bezuslovno
to bi naruilo referencijalni integritet
103
Postavlja se pitanje kako postupiti kada se vri auriranje u ciljnoj relaciji,

a da se ne narui referencijalni integritet. Takva specikacija se naziva: dinamika specikacija referencijalnog integriteta i odnosi se samo na kritine operacije, a to su operacija uklanjanja (DELETE) i operacija izmene (UPDATE). Uz
ove akcije neophodno je navesti jednu od sledee tri klauzule: RESTRICTED,
CASCADES, NULLS
RESTRICTED: operacija se ne izvrava ako u pozivajuoj relaciji postoji
vrednost stranog kljua koja odgovara vrednosti primarnog kljua u ciljnoj relaciji
CASCADES: operacija se uvek izvrava. Ako je uklonjena n-torka iz ciljne
relacije, u pozivajuoj relaciji se uklanjaju sve n-torke sa datim kljuem.
Ako je dolo do izmene, menjaju se sve vrednosti n-torki u pozivajuoj
relaciji sa novim spoljnim kljuem
NULLS: operacija se uvek izvrava. U pozivajuoj relaciji se u svim ntorkama koje imaju dati promenjeni spoljni klju, menja njegova vrednost u NULL. NULLS klauzula se ne moe sprovesti ako je spoljni klju
u sastavu primarnog kljua, ili ga ini u celini to bi bilo u suprotnosti
sa identikacionim integritetom.
104
Poglavlje 12
Relaciona algebra
Relaciona algebra pripada kategoriji formalnih upitnih jezika proceduralnog karaktera. ini je skup operatora za rad sa relacijama, a rezultati operacija su
takoe relacije. Relaciona algebra je osnova za upitne jezike koje koriste ljudi. Svaki od algebarskih izraza je jedan upit ili pretraivanje. Upitni jezik jezik kojim
korisnici zahtevaju informacije iz BP
Operacija je primena nekog operatora na jednu ili vie 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 klasikovati i prema broju operanada. Pojedine operacije se izvravaju nad jednim, a pojedine nad dve relacije.
Unarne (1 operand)
Binarne (2 operanda)
Tabela: Klasikacija osam osnovnih operacija
Simbol
Naziv
Sloenost
Br. operanada
restrikcija
elementarna
unarna
projekcija
elementarna
unarna
unija
elementarna
binarna
Relaciona algebra
105
Simbol
Naziv
Sloenost
Br. operanada
razlika
elementarna
binarna
presek
izvedena
binarna
Dekartov proizvod
elementarna
binarna
><
spajanje
izvedena
binarna
deljenje
izvedena
binarna
12.1. Restrikcija -
Restrikcija (selekcija, ogranienje, eng: restrict) - kao rezultat daje tano
odreene n-torke iz tabele tj. samo one n-torke koje zadovoljavaju zadati kriterijum (izdvajanje redova u tabeli).
Denicija: Restrikcija je operacija relacione algebre koja iz polazne relacije po zadatom kriterijumu izdvaja podskup n-torki. Kriterijum je neki logiki
izraz koji je izraunljiv nad svakom n-torkom. Dobijena relacija ima istu strukturu 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 moe 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: =, , >, , <,
106
Relaciona algebra
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
12
23
10
nakon operacije A=B ^ D > 5 (r) dobija se

A
23
10
12.2. Projekcija -
Projekcija (eng: project) kao rezultat daje relaciju koja se sastoji samo od
odreenih atributa zadate relacije (izdvajanje kolona u tabeli).
Denicija: iz polazne relacije po zadatom skupu atributa formira se nova
relacija kao skup n-torki nad tim atributima. Zadati skup atributa mora biti podskup skupa atributa polazne relacije. Vrednosti atributa u n-torkama nastale relacije odgovaraju onima u polaznoj relaciji.
Relaciona algebra
107
Ako je r relacija nad emom R(X), Y zadati skup atributa, a x i y n-torke nad
X i Y, formalna denicija restrikcije je: Y(r) = t(Y) = {t | YX yx}
Primenom operacije projekcije mogue je da vie n-torki polazne relacije
daje iste vrednosti. Poto 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 sadri 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 moe da dovede do smanjenja broja ntorki u novonastaloj relaciji, kao i do gubitka podataka za studente sa istim imenom ili prezimenom.
Primer 2.
Iz relacije r(A;B;C;D):
A
10
20
30
40
Nakon primene operacije projekcije A,C (r) dobija se t1(A,C)
108
Relaciona algebra
a zbog uslova identikacionog integriteta krajnji rezultat je t2(A,C)

A
Za razliku od restrikcije, rezultirajue 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.
Denicija: Unija je operacija relacione algebre kojom se iz dve polazne relacije formira novu koja sadri sve n-torke iz obe relacije. Ova operacija nije mogua
izmeu bilo koje dve relacije, tj. mora biti zadovoljeno:
eme relacija moraju imati isti broj atributa
Atributi ema relacija redom odgovaraju po znaenju 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 oznaava unijski kompatibilan skup atributa u obe relacije, formalna denicija 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
Relaciona algebra
109
s
A
nakon operacije r s dobija se sledea relacija

A
Primer 2.
Unijom relacija A i B
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
1772
Maksimovi
Ilija
015 723 543
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
2345
Petrovi
Petar
023 47 833
Dobija se relacija C = A B
110
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
1772
Maksimovi
Ilija
015 723 543
2345
Petrovi
Petar
023 47 833
Relaciona algebra
12.4. Razlika - /
Rezultat razlike (eng: dierence) - 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
iskljuuju sve n-torke zajednike s drugom relacijom.
Denicija: iz dve polazne relacije formira se nova koja sadri sve n-torke
prve relacije koje se ne nalaze u drugoj. Ova operacija je mogua samo izmeu
unijski kompatibilnih relacija.
Ako su r i s relacije nad emom R(X) i S(X), X oznaava unijski
kompatibilan skup atributa u obe relacije, formalna denicija razlike je:
r - s = t(X) = {x | xr xs}
Primer 1.
Za relacije A i B
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
1772
Maksimovi
Ilija
015 723 543
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
2345
Petrovi
Petar
023 47 833
primenom operacije razlike formira se relacija C = A - B

IFRA#
PREZIME
IME
TEL.BROJ
1772
Maksimovi
Ilija
015 723 543
ili relacija C= B- A
IFRA#
PREZIME
IME
TEL.BROJ
2345
Petrovi
Petar
023 47 833
Relaciona algebra
111
Primer 2.
Nad relacijama
kredit(BR_KRED#, IME_EXP, IME_KL, IZNOS)
racun(IME_EXP, BR_RAC#, IME_KL#, STANJE)
Nai sve klijente koji u ekspozituri IEX imaju raun ali jo uvek nemaju kredit
Ovaj zadatak se reava u koracima. Prvo se selektuju sve n-torke koje se
odnose na ekspozituru IEX, a zatim se ostvari unijska kompatibilnost posmatranih relacija primenom operacije projekcije po eljenom atributu. Na kraju se
primeni operacija razlike novonastalih relacija:
Nai sve klijente koji imaju racun u ekspozituri IEX
IME_KL (IME_EXP=IEX(racun)) o t1
Nai sve klijente koji imaju kredit u ekspozituri IEX
IME_KL (IME_EXP=IEX(kredit)) o 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 zajednike za obe relacije, odnosno koja sadri sve n-torke koje
se nalaze i u jednoj i u drugoj relaciji. Ova operacija je mogua samo izmeu unijski kompatibilnih relacija.
Ako su r i s relacije nad emom R(X) i S(X), X oznaava unijski kompatibilan skup atributa u obe relacije, formalna denicija preseka je:
r s = t(X) = {x | x r x s}.
Presek je izvedena operacija, moe se izvesti iz
r s = r (r-s)
Primer 1.
Za relacije A i B
112
Relaciona algebra
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
1772
Maksimovi
Ilija
015 723 543
IFRA#
PREZIME
IME
TEL.BROJ
3244
Aksentijevi
Petar
011 334 952
2345
Petrovi
Petar
023 47 833
primenom operacije preseka formira se relacija C = A B

IFRA#
PREZIME
IME
TEL.BROJ
3244
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)
Nai sve klijente koji u ekspozituri IEX imaju i raun i kredit. Do rezultata
se dolazi u koracima, uz ostvarivanje unijske kompatibilnosti.
Nai sve klijente koji imaju racun u IEX
IME_KL (IME_EXP=IEX(racun)) o t1
Nai sve klijente koji imaju kredit u IEX
IME_KL (IME_EXP=IEX(kredit)) o t2
Rezultat je: t1 t2
12.6. Dekartov proizvod -

Dekartov proizvod dve relacije je relacija koja se sastoji od svih
moguih kombinacija parova n-torki, pri emu je prva n-torka iz prve, a
druga iz druge relacije.
Denicija: 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
sadri sve atribute polaznih relacija.
Relaciona algebra
113
Ako su r i s relacije nad emom R(X) i S(Y), a X i Y su skupovi atributa u emama relacija, formalna denicija Dekartovog proizvoda je:
r s = t(XY) = {xy | x r y s}
Kod oznaavanja za puni naziv atributa se moe 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
10
10
20
10
kao rezultat dekartovog proizvoda rs dobija se

A
10
10
20
10
10
10
20
10
Nakon primene dekartovog proizvoda, u rezultujuoj relaciji samo pojedine

n-torke imaju smisla.
114
Relaciona algebra
Primer 1.
Nad relacijama
klijent(IME_KL, UL_BR, GRAD),
licni_bankar(IME_KL, IME_SL)
Nai sve klijente sa linim bankarom IS1 i gradove u kojima klijenti ive
Nakon primene dekartovog proizvoda, samo neke od n-torki sadre traene
podatke.
licni_bankar klijent o t(LB.IME_KL, LB.IME_SL, K.IME_KL, K.UL_BR, K.GRAD)
Klijent
Zoran
Milan
Petar
Savska
Nika
Kralja Milana
Beograd
Novi Sad
Kruevac
Lini bankar
Zoran
Sl1
Milan
Sl2
Petar
Sl3
Klijent Lini bankar

Zoran
Zoran
Zoran
Milan
Milan
Milan
Petar
Petar
Petar
Savska
Savska
Savska
Nika
Nika
Nika
Kralja Milana
Kralja Milana
Kralja Milana
Beograd
Beograd
Beograd
Novi Sad
Novi Sad
Novi Sad
Kruevac
Kruevac
Kruevac
Zoran
Milan
Petar
Zoran
Milan
Petar
Zoran
Milan
Petar
Sl1
Sl2
Sl3
Sl1
Sl2
Sl3
Sl1
Sl2
Sl3
Relaciona algebra
115
12.3.1. Spajanje - ><

Denicija: 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 P
Ako su r i s relacije nad emom R(X) i S(Y), X i Y su skupovi atributa u
emama relacija, formalna denicija operacije spajanja je:
r >P(XY)< s = P(XY)(rs) = {xy | x r y s P(xy)}
12.6.2. spajanje
Prethodna denicija dozvoljava proizvoljni uslov P, pod uslovom da je izraunljiv 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
vai da je
XiX i YiY. Pod spajanjem r > Xi Yi< s
podrazumeva se spajanje kod koga operator oznaava bilo koji operator poreenja:
(=,,<,>,,)
12.6.3. Ekvi spajanje

Prethodno spajanje ograniava formu uslova spajanja, meutim i dalje
dobijeni rezultat nema praktinu primenu. Specijalni sluaj gde predstavlja jednakost (=) je est sluaj u praksi.
Ekvi spajanje po jednom atributu:
r > Xi = Yi< s
Ekvi spajanje po vie atributa oznaava se sa:
r > (X1,X2,...,Xn) = (Y1,Y2,...,Yn) < s
116
Relaciona algebra
12.6.4. Prirodno spajanje

Prethodno spajanje daje jedan suvian atribut, zato to su vrednosti atributa
po kojima se vri spajanje uvek iste. Nepotrebni atribut se eliminie dodatnom
operacijom projekcije. Navedeni sluaj 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 oznaava se sa:
r > Xi,*,Yk < s
Specijalni sluaj oznaavanja: r > * < s podrazumeva prirodno spajanje po
svim atributima koji imaju jednake nazive u obe relacije.
Formalna denicija prirodnog spajanja: Ako su r i s relacije nad emom
R(X) i S(Y), a AX i BY su ureeni podskupovi jednakog broja atributa relacija
r i s, respektivno, prirodno spajanje deniemo kao:
r > (A)*(B) < s = XY-B( (A)=(B) (rs))=t(XY-B)
Jednakost ureenih podskupova A i B podrazumeva jednakost korespodentnih elemenata. Umesto XY-B sa desne strane moe se navesti XY-A.
Primer 1.
Za polazne relacije r i s
r
s
A
B
1
2
D
10
10
20
10
E
a
a
b
b
kao rezultat prirodnog spajanja r >*< s = XY-B (A=C(r s)) dobija se

Relaciona algebra
117
r>*< s
A
B
1
2
2
D
10
10
20
E
a
a
b
12.7. Deljenje - /
Deljenje je najsloenija operacija relacione algebre.
Deljenje se ne moe izvesti sa proizvoljnim tabelama. Za A/B potrebno je da
se svi atributi relacije B nalaze u relaciji A.
Npr: Mogue je deljenje za: a (X1,X2,...,Xn,Y1,Y2,...,Ym) b (Y1,Y2,...,Ym)
Primer: Za dve relacije r i s, date sa:
r
nakon operacije deljenja r/s dobija se:
118
Relaciona algebra
Poglavlje 13
SQL
SQL (Stuctiured Query Language) je standardni relacioni upitni jezik (ANSI
- American National Standards Institute - standard). Slui za kreiranje, organizaciju i manipulaciju podacima u relacionim bazama podataka. Sam nastanak jezika se
vezuje za IBM-ovu istraivaku laboratoriju u San Hozeu u Kaliforniji, gde je SQL
razvijen kasnih 70-ih godina, u sklopu projekta System R.
Danas je SQL ugraen u sve vodee SUBP SQL je uspeno primenjen u sistemima za upravljanje bazom podataka kao to su MS Access, DB2, Informix, MS
SQL Server, Oracle, Sybase itd. Trenutno u svetu postoji vie standarda SQL jezika,
a najpoznatije su: ANSI-92, ISO, Microsoft SQL, itd. IBM je 1987. godine standardizovao sopstvenu verziju SQL-a. Zatim je ANSI 1989. godine objavio proirenu
verziju, poznatu kao SQL-89. Sledea 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 kaemo da predstavlja jedan red tabele, a kolone tabele
odgovaraju atributima. Ova terminologija je nasleena iz prakse koja je prethodila standardizaciji, a rezultat toga je krajnje neobina okolnost da u SQL-u, jeziku za relacione baze podataka, ne postoji ni jedna konstrukcija koja sadri re
RELATION.
SQL
119
SQL jezik podrava dva reima 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 ogranien jedino pravima korisnika i
Programski: Korisnik pokree program u kome se nalaze ugraene
SQL naredbe. Pristup bazi podataka ogranien je pravima korisnika i
sadrajem programa. Pri tome, ugraene naredbe mogu biti statike
(ksirane u vreme prevoenja programa) ili dinamike (konstruisane
tokom izvravanja programa).
Baza podataka sadri tabele i druge objekte radi smetanja i obrade podataka. Za kreiranje baze koristi se naredba:
CREATE DATABASE imeBaze
SQL podrava 3 osnovne funkcije BP: denicije, manipulacije i kontrolu.
DDL (Data Denition Language)
SQL
DML (Data Manipulation Language)

DCL (Data Conrol Language)
Denicija baze podataka: Pre poetka rada sa bazom podataka neophodno je

denisati njenu strukturu - koje tabele postoje, koji atributi postoje u tabelama i kog
su tipa, koja ogranienja postoje unutar tabela i izmeu njih, koje pomone strukture
(indeksi) za ubrzanje pristupa podacima postoje i za koje tabele. Ova komponenta
jezika odgovara DDL-jeziku baze podataka (od Data Deniton Language).
Manipulacija bazom podataka: Pored upita nad bazom podataka, kojima
dobijamo eljene informacije, neophodno je obezbediti i auriranje baze podataka, odnosno unos, izmenu i brisanje podataka. Ova komponenta je u stvari DMLjezik baze podataka (od Data Manipulation Language).
Kontrola pristupu podacima: U svakoj bazi podataka neophodno je ostvariti 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).
120
SQL
13.2. PRAVILA SQL-a

13.2.1. Pravila za pisanje imena
Imena tabela, pogleda, atributa i drugih objekata baze podataka moraju da
potuju sledea pravila:
1) Maksimalna duina imena je 30 znakova,
2) Ime ne sme da sadri znak pitanja (?),
3) Nema razlike izmeu 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 rei i
7) Imena se ne smeju ponavljati.
Radi lakeg itanja koda preporuuje se da kljune rei (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 sadrati izraze u kojima se pojavljuju:
Logike operacije: AND, OR i NOT,
Operacije uporeivanja: =, <, >, , , < >, 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 najvei (MIN i MAX), srednja vrednost
(AVG) itd.
Ostale funkcije za rad s podacima.
Izrazi se mogu grupisati pomou zagrada. Mogu sadrati zadate brojeve,
tekstualne podatke i/ili ostale vrste podataka.
SQL
121
13.2.3. Tipovi podataka

Pri kreiranju tabela odreujemo tip podatka koji e biti korien. Sledea
tabela prikazuje najosnovnije standardne SQL tipove podataka, njihove karakteristike, kao i neke od alternativnih podtipova.
TIP
PODATKA
OPIS
CHAR(n)
Podatak tipa niza karaktera ksne duine n
VARCHAR(n)
Podatak tipa niza karaktera promenljive duine

Numeriki podaci bilo kog tipa, do 38 cifara. Podtipovi:
DEC
DECIMAL
DOUBLE
DOUBLE_PRECISION
NUMBER
FLOAT
INT
NUMERIC
REAL
SMALLINT
DATE
Koristi se za promenljive i konstante iji je sadraj

informacija o vremenu, npr.: datumi, sati, min. i sec.
BOOLEN
Koristi se za promenljive i konstante koje sadre logike

vrednosti TRUE (istina) i FALSE (la)
13.2.4. Definicija atributa

Atribut deniemo izrazom od dva ili tri dela:
<ime_atributa> <tip_atributa> <dodatna_svojstva_atributa>
122
SQL
Dodatna svojstva:
DEFAULT - zadavanje predenisane vrednosti,
NOT NULL - vrednost ne sme biti nepoznata ili ne zadata,
CHECK - provera da je vrednost atributa u zadatim granicama,
UNIQUE - jedinstvenost meu n-torkama unutar relacije,
PRIMARY KEY - primarni klju,
REFERENCES - vrednost mora biti meu vrednostima iz druge relacije,
obino klju iz druge relacije.
13.3. Naredbe SQL-a za definisanje

Denicija neke baze podataka podrazumeva i mogunost naknadne izmene ili uklanjanja te denicije. U standardnom SQL jeziku se to postie sa svega
tri naredbe:
CREATE: Slui za kreiranje nekog objekta (tabele, indeksa, itd.) u bazi
podataka,
DROP: Slui za uklanjanje denicije nekog objekta iz baze podataka i
ALTER: Slui za izmenu denicije nekog objekta u bazi podataka.
SQL
123
13.3.1. Rad sa tabelama

Prilikom kreiranja tabele, odnosno denicije njene strukture i osobina
(ema), neophodno je navesti sledee:
Ime tabele, koje mora biti unikatno u bazi podataka,
Ime svake kolone, koja mora biti unikatno unutar tabele,
Tip svake kolone,
Jedno ili vie ogranienja za kolone koje ih imaju i
Jedno ili vie ogranienja za celu tabelu, ako postoje.
Primer:
JMBG
Ime
Prezime
Ulica i broj
Grad
0104983134526
Petar
Petrovi
Njegoeva 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 OgranienjeKolone ...
{, imeKolone TipKolone OgranienjeKolone ...}
[OgranienjeTabele {, OgranienjeTabele}]);
ImeTabele i ImeKolone - pravila koja vae za veinu 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 vie ogranienja za tu kolonu.
Naredba za uklanjanje tabele je DROP TABLE imeTabele. Tabela koja se
uklanja mora biti prazna. U suprotnom SUBP nee izvriti tu naredbu.
Izmena tabele se vri naredbom ALTER TABLE imeTabele. Naknadna izmena se najee radi jer se kod prvobitnog kreiranja tabele nije uzeto u obzir
124
SQL
sve ta je bilo potrebno, ili je dolo do zahteva za promenama aplikacije i baze

podataka.
Naredba izmene tabele je neto sloenija, poto treba da obezbedi sledee
mogunosti izmene tabele:
Dodavanje nove kolone,
Izmena postojee kolone,
Uklanjanje postojee kolone,
Dodavanje novog ogranienja tabele i
Uklanjanje postojeeg ogranienja tabele.
Izmena kolone je ograniena samo na mogunost uvoenja nove ili uklanjanja podrazumevane vrednosti. U tim okolnostima, postojea ogranienja kolone se ne mogu uklanjati a nova se mogu dodavati samo preko dodavanja novog
ogranienja tabele sa naznaenom jednom kolonom.
Uklanjanje kolone nije mogue ako je navedena kolona jedina u tabeli, kao
i ako je navedena klauzula RESTRICTED, a u bazi podataka postoji bar jedno
referenciranje koje referie kolonu koja se uklanja.
13.4. Pogledi
Pogled (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 pogledu izvrava se upit kojim je on denisan.
Prednosti koje imaju pogledi u radu sa RBP:
Pogled predstavlja jednu vrstu podprograma u SQL-u. Jednom kreiran,
moe se koristiti u podupitima u WHERE i HAVING klauzulama,
Komplikovani i esto korieni upiti se mogu formulisati u vidu pogleda
koje e korisnici jednostavno pozivati u upitima tipa SELECT * FROM
imePogleda,
Pogled razreava problem pojavljivanja vika podataka u svodnim upitima (kada u odreenim implementacijama pravila za SELECT naredbu
SQL
125
nalau da pored traenih podataka u rezultat ukljuimo i nepotrebne po

kojima se grupie)
Pogledi znatno olakavaju kontrolu pristupa bazi podataka.
Naredbe za rad sa pogledima:
CREATE VIEW i
DROP VIEW
Kreiranje pogleda vri se naredbom ija je sintaksna denicija:
CREATE VIEW Pogled [ ( Kolona ,.. ) ] AS Upit ;
gde je znaenje pojedinih djelova ove denicije sledee:
Pogled
Unikatni naziv pogleda u bazi podataka, simbol formiran po pravilu za nazive varijabli
Kolona
Ako se navedu kolone pogled se ponaa 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
sluaja, pogled nasleuje tipove kolona iz osnovnih tabela i pogleda iz upita
Upit
Naredba upita SELECT iji rezultat izvravanja daje tabelu koja

predstavlja pogled
Pogled se uklanja naredbom ija je sintaksna denicija:

DROP VIEW Pogled ;
Uklanjanje pogleda nema nikakvog efekta na osnovne tabele iz upita.
13.5. Indeksi
Indeks je pomona 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 zikom redosledu koji odgovara redosledu unosa podataka.
Kada pristupamo neposredno toj datoteci zapise oitavamo tim redosledom, ali
ako podacima pristupamo posredstvom indeksa, oitavaemo ih redosledom koji
odgovara rastuoj ili opadajuoj vrednosti indeksnog izraza.
126
SQL
Sintaksa naredbe za kreiranje indeksa je:

CREATE [ UNIQUE ] INDEX ImeIndeksa ON Tabela ( Kolona ,.. );
gde je znaenje pojedinih djelova ove denicije sledee:
UNIQUE
Ime Indeksa
Kolona
Kada se zada ova opcija, indeks mora biti unikatan, odnosno u tabeli
na koju se indeks odnosi ne sme da se vie puta ponovi neka vrednost
Kolona
Unikatni naziv indeksa u bazi podataka, simbol formiran po pravilu
za nazive varijabli
Jedna ili vie kolona po kojima se formira indeks
Nad istom tabelom po potrebi moe biti denisano vie indeksa. To se koristi kada su potrebni razliiti pristupi podacima i razliiti redosledi podataka.
Indeks moe biti kreiran odmah, dok je tabela na koju se odnosi prazna, ili
naknadno. Ako se kreira naknadno, indeks dobija sadraj koji odgovara sadraju svoje tabele. Od tog trenutka, sadraj indeksa i tabele je sinhronizovan: svako
dodavanje ili uklanjanje podataka, kao i izmena vrednosti neke od kolona koja je
u sastavu indeksnog izraza, odraava se na sadraj indeksa.
Indeks se moe bilo kada i bez obzira na sadraj svoje tabele ukloniti naredbom ija je sintaksna denicija:
DROP INDEX ImeIndeksa ;
13.6. SELECT upiti

Naredba za upite, odnosno, SELECT naredba, predstavlja najznaajniju i
najee korienu SQL naredbu za manipulaciju podacima.
13.6.1. Prost upit nad jednom tabelom:

Kod svakog upita se zadaje:
Koje podatke traimo kao rezultat,
Iz kojih tabela to traimo,
Koji uslov treba da zadovolje podaci da bi bili ukljueni u rezultat i
Po kom redosledu elimo prikaz rezultata.
SQL
127
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
moe doi do pojave istovetnih redova u rezultatu. Stoga prilikom formulacije
upita treba da postoji mogunost specikacije da li elimo eliminaciju viestrukog
pojavljivanja istih redova u rezultatu ili ne.
Prost upit nad jednom tabelom ima sledeu sintaksu:
SELECT R-Lista
FROM Tabela
[ WHERE R-Predikat ]
[ ORDER BY { R-Izraz [ ASC | DESC ] } ,.. ] ;
gde je
R-Lista ::= * | { [ ALL | DISTINCT ] R-Izraz ,.. }
Znaenje:
*
Specijalni sluaj kada elimo da ukljuimo sve kolone tabele, i to onim

redosledom kojim su navedene u naredbi kreiranja tabele
ALL
Traimo da se u rezultatu prikau svi redovi ukljuujui i one koji su

istovetni, podrazumijeva se ako se nita ne navede
DISTINCT Traimo da se iz rezultata eliminiu suvina pojavljivanja (osim jednog) istovetnih redova
128
R-Izraz
Izraz izraunljiv nad svakim pojedinim redom tabele koji pored naziva kolona moe da sadri i operatore i konstante. Najee je u formi
navoenja jedne kolone
R-Predikat
Logiki izraz koji je izraunljiv nad svakim pojedinim redom tabele. U

formiranje rezultata upita ulaze samo oni redovi za koje taj izraz daje
istinit rezultat. U najjednostavnijim sluajevima, 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
SQL
Primer 1.
Najjednostavniji mogui SQL upit je u formi:
SELECT * FROM ImeTabele;
Ova naredba prikazuje sve redove tabele ije je ime navedeno iza FROM klauzule. U svakom redu prikazuju se vrednosti svih kolona, onim redom kako je to zapisano
u datoteci (tj. kreirano sa CREATE TABLE). Kod upita se obino trai prikaz samo
odreenih kolona, ili prikaz svih kolona u redosledu koji je drugaije odreen.
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: najee ih ine posebne SQL funkcije (svodne ili agregatne funkcije). One mogu biti:
SUM (ImeKolone) Nalazi sumu svih ne-NULL vrednosti zadate kolone
AVG (ImeKolone) Nalazi prosenu 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 vrednosti zadate kolone
COUNT(*)
Nalazi ukupan broj redova u tabeli
COUNT([ALL~DISTINCT] ListaKolona)
Bez DISTINCT nalazi ukupan broj ne-NULL vrednosti zadate kombinacije kolona
Sa DISTINCT nalazi ukupan broj razliitih ne-NULL vrednosti zadate
kombinacije kolona
Primer:
Uz pretposatvku da su u tabeli Student uneseni svi studenti jednog fakulteta, ukupan broj studenata tog fakulteta se moe dobiti sa:
SELECT COUNT(*) FROM Student;
SQL
129
13.6.3. WHERE klauzula

WHERE klauzula slui za izbor zapisa na osnovu kriterijuma (ltriranje).
Prilikom denisanja kriterijuma moemo se koristiti logikim (AND, OR, NOT) i
komparativnim (<, >, < =, > =, < >) operatorima. WHERE klauzula nije obavezna,
a moe se koristiti sa SELECT, UPDATE I DELETE komandama.
Koriena u SELECT bloku, WHERE klauzula omoguuje:
Selekciju specinih n-torki relacije (redova tabele),
Selekciju n-torki koje zadovoljavaju viestruke uslove,
Selekciju n-torki koje zadovoljavaju bar jedan od vie uslova,
Selekciju n-torki koje ne zadovoljavaju odreene uslove,
Selekciju n-torki istovremenim korienjem AND i OR logikih operatora,
Selekciju n-torki unutar izvesnog raspona,
Selekciju n-torki koje zadovoljavaju vrednost u listi vrednosti i
Selekciju n-torki koje sadre odreenu kombinaciju karaktera.
13.6.4. ORDER BY klauzula

Korienjem ORDER BY klauzule mogue je sortirati rezultujuu tabelu po
jednom ili vie atributa u rastuem ili opadajuem redosledu.
Za specikaciju rastueg redosleda koristi se klauzula ASC, za specikaciju opadajueg redosleda klauzula DESC. Rastui redosled se podrazumijeva, pa
klauzulu ASC nije neophodno navoditi, za razliku od klauzule DESC koju uvek
treba navesti kada se sortira u opadajuem 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
razliitu vrednost kolone po kojoj se vri grupisanje.
GROUP BY klauzula se moe koristiti zajedno sa klauzulom WHERE, pri
emu WHERE klauzula uvek ide pre GROUP BY klauzule. WHERE klauzulom
se najpre izvri selekcija n-torki, zatim se selektovane n-torke grupiu GROUP
BY klauzulom, pa se, eventualno, izvri selekcija formiranih grupa HAVING
klauzulom.
130
SQL
13.6.6. HAVING klauzula

HAVING klauzula odreuje kriterijume za selekciju grupa, poto su grupe
ve formirane sa GROUP BY klauzulom.
13.6.7. Korienje NULL vrednosti

NULL vrednosti su nedenisane vrednosti. Izmeu NULL vrednosti i vrednosti nula postoji znaajna razlika. Bez obzira o kom tipu da se radi NULL vrednost odreene kolone moe se testirati samo pomou dve specijalne klauzule: IS
NULL ili IS NOT NULL. Operatori poreenja se ne mogu koristiti kod testiranja
NULL vrednosti.
13.6.8. LIKE klauzula

Klauzula LIKE omoguava pretraivanje na osnovu UZORKA, odnosno,
dobijanje informacija i kada ne znamo potpun naziv (tj. vrednost) odreenog
atributa tipa character. Ona koristi dva specijalna karaktera (%,_) sa sledeim
znaenjem:
% predstavlja string od 0 ili vie karaktera, a
_ predstavlja poziciju jednog karaktera.
Ostali karakteri imaju uobiajeno znaenje.
13.7. Naredbe auriranja

Auriranje u irem smislu znaenja te rei obuhvata dodavanje, izmenu
sadraja i brisanje reda ili redova tabele. Te osnovne operacije realizuju se SQL
naredbama: INSERT, UPDATE i DELETE sa sledeim znaenjem:
INSERT: Dodavanje reda ili redova u tabelu,
UPDATE: Izmena sadraja postojeeg reda ili redova tabele i
DELETE: Brisanje postojeeg reda ili redova tabele.
Posebno treba voditi rauna da su sve tri navedene naredbe - naredbe nad
jednom tabelom, tako da se njihovom primenom ne garantuje ouvanje integriteta baze podataka. Direktno korienje ovih naredbi se zato ne preporuuje, jer
SQL
131
je u tom sluaju procedura za ouvanje integriteta spolja, tj. sam korisnik mora
voditi rauna o njoj. Ove naredbe direktno treba da koristi samo administrator
baze podataka i to za otklanjanje eventualno naruenog integriteta baze.
Normalno auriranje baze podataka vri se aplikacijama za interaktivno
auriranje u koje su ugraene procedure za ouvanje integriteta. Te procedure se
sastoje od naredbi INSERT, UPDATE i DELETE.
13.7.1. INSERT naredba

Postoje 3 sluaja korienja naredbe INSERT, i to kada se vri:
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 sluaju nije potrebno specicirati nazive atributa, pa INSERT naredba ima oblik:
INSERT INTO NazivTabele
VALUES (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 sluaju 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 identino
denisani, naredba INSERT je oblika:
132
SQL
INSERT INTO tabela 1 SELECT * FROM tabela2 ;

inae:
INSERT INTO tabela1 (atribut1, atribut2, ...)
SELECT atribut1, atribut2
FROM tabela2
WHERE kriterijum selekcije ;
13.7.2. UPDATE naredba

Uz ovu naredbu mora se navesti:
U kojoj tabeli se vre izmjene,
Za koje kolone u redu mijenjamo vrednosti,
Pod kojim uslovima mijenjamo vrednosti.
Opti oblik naredbe je:
UPDATE ImeTabele
SET atribut1 =izraz1 [,atribut2=izraz2]
[WHERE kriterijum selekcije n-torki],
odnosno,
UPDATE ImeTabele
SET(alribut1, atribut2,..)=(podupit)
[WHERE kriterijum selekcije n-torki]
Podupit mora vratiti najvie po jednu vrednost za svaki od atributa u listi
atributa iza SET klauzule.
13.7.3. DELETE naredba

Uz ovu naredbu mora se navesti:
Iz koje tabele se vri uklanjanje i
Pod kojim uslovima se uklanja neki red.
Sintaksa naredbe:
DELETE FROM ImeTabele WHERE R-Predikat
SQL
133
SUBP odbija uklanjanja, ako je to u suprotnosti sa dinamikom specikacijom referencijalnog integriteta.
13.8. Naredbe za kontrolu prava pristupa

Naredbe za kontrolu prava pristupa podacima u bazi podataka su:
GRANT: Naredba za dodeljivanje prava korienja,
REVOKE: Naredba za oduzimanje prava korienja
Ove naredbe ine osnovu dela SQL jezika za kontrolu pristupa bazi podataka.
Sutina kontrole pristupa bazi podataka je u tome da se ostvare sledei vidovi kontrole:
Ko uopte moe da pristupa bazi podataka,
emu moe da pristupi u bazi podataka i
ta moe da radi sa onim emu moe da pristupi.
Deo SQL jezika za kontrolu pristupa bazi podataka sve to obezbeuje putem sledeih funkcija:
Kreiranje i uklanjanje korisnika - naloga za rad za bazom podataka,
Dodela i uklanjanje optih prava za rad sa bazom podataka i
Dodela i uklanjanje posebnih prava za rad sa bazom podataka.
13.8.1. GRANT naredba

Opti 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 moe
koristiti ukoliko mu kreator, vlasnik tabele eksplicitno ne dodeli pravo korienja.
Dodela prava korienja tabele drugim korisnicima se vri 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
134
SQL
se dati svim korisnicima (PUBLIC) ili samo nekim, u kom sluaju se eksplicitno
navode identikatori korisnika kojima se daje pravo korienja. Pravo korienja
se daje drugom korisniku sa ili bez mogunosti da to to je dobio dodeli jo nekom korisniku (WITH GRANT OPTION).
13.8.2. REVOKE naredba

Opti oblik naredbe REVOKE:
REVOKE {ALL[ALTER, DELETE, INDEX, INSERT, SELECT, UPDATE(atr) ] }
ON [kreator.] {tabela | pogled}
FROM {PUBLIC | korisnik1, korisnik2, ... } ;
Data prava korienja se oduzimaju naredbom REVOKE.
SQL
135
Poglavlje 14
Relacije loe strukture

Glavni cilj u procesu razvoja baze podataka je da se kreira sistem koji verno
reprezentuje podatke, njihove veze i odnose, kao i ogranienja. Da bi se postigao
ovaj cilj, moraju se pravilno uoiti odgovarajue tabele, a metoda koja se za to
koristi naziva se normalizacija. Normalizacija je tehnika za kreiranje tabela sa
odgovarajuim svojstvima, uzimajui u obzir zahteve okruenja za ije potrebe
se projektuje baza. Normalizacija se esto realizuje tako to se vri serija testova
nad tabelom da bi se utvrdilo da li ona zadovoljava zahteve odreene normalne
forme ili ne. Inicijalno su promovisane tri normalne forme, prva (1NF), druga
(2NF) i trea (3NF) normalna forma. Kasnije su R.Boyce i E.F.Codd promovisali strou deniciju tree normalne forme koja se naziva Boyce-Codd normalna
forma (BCNF). Sve normalne forme se baziraju na funkcionalnim zavisnostima
izmeu atributa tabele. Promovisane su i vie 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 omoguava projektantu baze da izvri optimalno grupisanje atributa po tabelama. Proces normalizacije identikuje tabele na osnovu primarnih kljueva ili kljueva kandidata i na osnovu funkcionalnih zavisnosti koje
postoje izmeu atributa. Normalizacija sadri pravila koja se mogu upotrebiti za
testiranje tabela, tako da baza moe da se normalizuje do bilo kog stepena. Tabela
koja ne ispunjava zahteve normalizacije mora se rastaviti na dve ili vie tabela od
kojih svaka pojedinano ispunjava zahteve normalizacije. Vano je napomenuti
da je za kreiranje tabela u relacionom modelu podataka kritina samo 1NF. Sve
ostale forme su opcione. Ipak, da bi se izbegle anomalije auriranja, preporuuje
se normalizacija najmanje do 3NF.
137
U najoptijem smislu, normalizacija je postupak kojim se proizvoljna

nenormalizovana relacija transformie u skup manjih normalizovanih relacija.
U okviru normalizacije ne sme doi do gubitaka informacija sadranih u relaciji. Drugim reima, mora biti mogue rekonstruisati prethodne relacija na osnovu novodobijenih.
Dekompozicija eme relacije R(A1,A2,...,An) je zamena eme relacije R sa
skupom ema relacija {R1, R2, ... , Rk} za koje vai RiR 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 auriranja
Jedan od najvanijih ciljeva prilikom projektovanja relacione baze podataka
je pravilno grupisanje atributa po tabelama, to rezultuje minimalnim ponavljanjem podataka i smanjenjem prostora potrebnog za skladitenje 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 vie tabela. U tabelama koje sadre
podatke koji se ponavljaju mogu da se jave problemi poznati kao anomalije auriranja. Anomalije auriranja mogu biti anomalije unosa, anomalije brisanja ili anomalije promene podataka.
14.1.1. Anomalije unosa podataka

Prilikom unosa novih podataka koji se odnose na jedan entitet, u tabelu
koja sadri podatke koji se ponavljaju moraju se uneti i podaci koji se odnose na
druge entitete iji se podaci nalaze u istoj tabeli, to moe dovesti do nekonzistentnosti ako se naini greka prilikom unosa.
14.1.2. Anomalije brisanja podataka

Brisanje poslednjeg zapisa koji se odnosi na jedan entitet iz tabele koja
sadri podatke koji se ponavljaju moe dovesti do kompletnog gubitka podataka
o drugom entitetu iji se podaci nalaze u istoj tabeli, u istom zapisu.
138
14.1.3. Anomalije promene podataka

Prilikom promene vrednosti atributa koji se odnosi na jedan entitet, u tabeli
koja sadri podatke koji se ponavljaju moraju se promeniti i svi zapisi koji sadre
taj promenjeni atribut, kao i podaci koji se odnose na druge entitete, a koji stoje u
direktnoj vezi sa promenjenim atributom. Ako se ne izvre sve ove promene, baza
postaje nekonzistentna.
14.2. Funkcionalna zavisnost

Funkcionalna zavisnost opisuje odnose izmeu atributa u tabeli i predstavlja jedan od glavnih koncepata vezanih za normalizaciju. Osnovni razlog zbog koga se pristupa definisanju funkcionalnih zavisnosti za tabelu je
potreba odreivanja ogranienja za ouvanje integriteta (integrity constraints).
Verovatno najvanije ogranienje za ouvanje integriteta je uoavanje kljueva kandidata, od kojih se jedan bira za primarni klju tabele. U procesu
njihovog definisanja, naroito je znaajno pronai one funkcionalne zavisnosti koje vae za sve mogue vrednosti atributa jedne tabele, jer one predstavljaju tipove ogranienja za ouvanje integriteta. Tipovi ogranienja za ouvanje
integriteta definiu vrednosti koje tabela moe legitimno da primi. Takoe je
znaajno ignorisati tzv. trivijalne funkcionalne zavisnosti, jer za njih vai da su
uvek zadovoljene, pa stoga nisu od znaaja.
14.3. Postupak normalizacije

Neka polazna ema relacije nije u odreenoj normalnoj formi ako u
skupu funkcijskih zavisnosti F postoji bar jedna koja naruava definiciju normalne forme.
U svakom koraku normalizacije:
1. Uoava se jedna takva zavisnost (XoY)
2. Vri se dekompozicija u cilju uklanjanja takve zavisnosti
3. Ako je u polaznoj vailo XoY,dekompozicijom nastaju dve relacije.U
prvoj se gube atributi Y, a druga nastaje nad atributima X i Y.
4. Ne dozvoljava se gubitak podataka
139
Krajnji je cilj normalizacije najverovatnije trea normalna forma.U veini sluajeva ona predstavlja najbolji kompromis izmeu ekstrema koji se odnose
na funkcionalnost i lakou implementacije. Nivoi iznad 3FN u praksi mogu da
iskomplikuju dizajn baze podataka do take da smetaju funkcionalnosti. Svi nivoi
normalizacije su kumulativni to znai da baza koja se nalazi u 2NF takoe mora
da ispunjava i sve uslove zadate prvom normalnom formom.
Proces analize eme relacije je proces primene serije testova na emu relacije da bi se proverilo da li ispunjava sva pravila denisana za odreenu normalnu formu. Normalne forme pomau projektantu baze podataka da ostvari eljeni
kvalitet relacione baze podataka.
14.4. Prva normalna forma (1NF)

Pre diskusije o 1NF, najpre treba denisati stanje pre 1NF. Tabela koja sadri
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 sadri jednu i samo
jednu vrednost.
ema relacije R je u prvoj normalnoj formi ako i samo ako domeni relacije R
sadre 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 vievrednosni i kompozitni atributi i njihove kombinacije
tj.nisu doputene 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 nain da se operacijom prirodnog spajanja iz ovih ema relacija moe
ponovo dobiti ema relacije R.
Da bi se nenormalizovana tabela transformisala u 1NF, moraju se identikovati i ukloniti podaci koji se ponavljaju. Postoje dva uobiajena pristupa za
uklanjanje podataka koji se ponavljaju iz nenormalizovanih tabela:
140
1. Po prvom pristupu, odgovarajui podaci se ubacuju u prazne kolone

redova koji sadre podatke koji se ponavljaju. Drugim reima, tamo gde
je to potrebno, prazna polja se popunjavaju dupliranim podacima koji se
ne ponavljaju. Rezultujua tabela sadri atomine (pojedinane) vrednosti 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 sledeih, viih faza procesa normalizacije uklanjaju iz tabele.
2. Po drugom pristupu, podaci koji se ponavljaju se, zajedno sa kopijom
originalne vrednosti atributa kljua (ili originalne vrednosti vie atributa
kljueva), izmetaju u posebnu tabelu. Za novu tabelu se denie primarni klju. Ponekad nenormalizovana tabela sadri vie od jedne grupe
podataka koji se ponavljaju ili ak grupe unutar grupe. U takvim sluajevima postupak izmetanja se ponavlja sve dok se ne ukloni i poslednja
grupa podataka koji se ponavljaju. Za grupu tabela se kae da je u 1NF
ako ne sadre 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 razlau na iste one tabele koje nastaju kao
rezultat primene drugog pristupa. Dakle, moe se zakljuiti da je drugi pristup
direktniji i praktiniji.
Primer: ema relacije RADPROJ(JMBG, Ime, {ifP, Sati}) sadri ugnjedenu relaciju PROJEKAT(ifP,Sati). Atribut ifP je parcijalni primarni klju relacije RADPROJ, tj. zajedno sa atributom JMBG ini njegov primarni klju. Da
bi ova ema relacije bila u 1NF nad njom se denie sledea relacija (sa nekim
trenutnim sadrajem):
JMBG
Ime
ifP
Sati
123
Marko
P1
123
Marko
P3
123
Marko
P5
222
Petar
P3
222
Petar
P4
333
Janko
P1
5
141
Da bi se relacija RADPROJ prevela u bolju 1NF, potrebno je da se ugnjedena relacija formira kao nezavisna relacija. eme relacija sada imaju oblik:
RADNIK(JMBG,Ime) i PROJEKAT(JMBG, ifP, Sati):
RADNIK
PROJEKAT
JMBG
Ime
JMBG
ifP
Sati
M1
I1
123
P1
M2
I2
123
P3
M3
I3
123
P5
222
P3
222
P4
333
P1
14.5. Druga normalna forma (2NF)

Druga normalna forma se bazira na konceptu potpune funkcionalne zavisnosti, koja e najpre biti denisana.
14.5.1. Potpuna funkcionalna zavisnost

Funkcionalna zavisnost AoB (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 vai, pri emu su A i B atributi tabele. Funkcionalna
zavisnost AoB je delimino zavisna ako postoje neki atributi koji se mogu ukloniti iz A, a zavisnost i dalje vai.
14.5.2. Definicija druge normalne forme

Druga normalna forma se odnosi na tabele sa sloenim kljuevima, tj. tabele iji se primarni kljuevi sastoje iz dva ili vie atributa. Tabela iji primarni klju
sadri samo jedan atribut je automatski u najmanje 2NF. U tabeli koja nije u 2NF
mogu da se pojave anomalije auriranja.
Tabela je u 2NF ako je u 1NF i ako je svaki atribut koji nije primarni klju
potpuno funkcionalno zavisan od primarnog kljua.
142
Normalizacija tabele iz 1NF u 2NF se vri uklanjanjem deliminih zavisnosti, tj. funkcionalno zavisni atributi se izmetaju u novu tabelu zajedno sa kopijom
njihovih determinanti (kljueva).
14.6. Trea normalna forma (3NF)

ak iako je u 2NF, u tabeli mogu da se pojave anomalije auriranja zbog
tranzitivnih zavisnosti, koje se moraju ukloniti iz tabele postupkom normalizacije
do 3NF.
14.6.1. Tranzitivna zavisnost

Tranzitivna zavisnost je stanje u kome su A, B i C atributi tabele takvi da,
ako AoB (B je funkcionalno zavisno od A) i BoC (C je funkcionalno zavisno od
B), onda je C tranzitivno zavisno od A preko B (pod uslovom da A nije funkcionalno zavisno od B ili C).
14.6.2. Definicija tree normalne forme

Tabela je u 3NF ako je u 1NF i u 2NF i ako u njoj ne postoje atributi ne-primarni-kljuevi koji su tranzitivno zavisni od primarnog kljua.
Normalizacija tabela iz 2NF u 3NF se vri uklanjanjem tranzitivnih zavisnosti, tj. tranzitivno zavisni atributi se izmetaju u novu tabelu zajedno sa kopijom
njihovih determinanti (kljueva).
14.7. Boyce-Codd normalna forma (BCNF)

Druga i trea normalna forma eliminiu delimine i tranzitivne zavisnosti
za primarne kljueve, ali one ne razmatraju da li takve zavisnosti postoje i za kljueve kandidate, ako ih ima u tabeli. Dakle, i u 3NF mogu da postoje delimine i
tranzitivne zavisnosti za kljueve kandidate, pa je stoga promovisana stroa normalna forma poznata kao Boyce-Codd normalna forma (BCNF).
BCNF se bazira na funkcionalnim zavisnostima koje uzimaju u obzir sve
kljueve kandidate u tabeli, a sadri i jo neka ogranienja u poreenju sa 3NF.
143
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 uoiti determinante i proveriti da li su sve one kljuevi kandidati. Podsetiemo se da je
determinanta atribut ili grupa atributa od kojih je neki drugi atribut potpuno
funkcionalno zavisan.
Razlika izmeu 3NF i BCNF je u tome to 3NF dozvoljava funkcionalnu
zavisnost AoB (B je funkcionalno zavisno od A) ako je B primarni klju a A nije
klju kandidat, dok BCNF nalae da A mora biti klju kandidat. Dakle, BCNF je
jaa forma od 3NF, pa je svaka tabela koja je u BCNF automatski i u 3NF, a obratno ne vai.
Tabela se transformie u BCNF tako to se vri njena dekompozicija na dve
ili vie novih tabela. Meutim, ponekad nije poeljno normalizovati tabelu do
BCNF. Naime, moe se desiti da se prilikom dekompozicije tabele izgubi jedna ili
vie funkcionalnih zavisnosti zbog toga to se determinanta i od nje zavisni atributi izmeste u razliite 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 sledee analize:
Da li e znaajni podaci biti izgubljeni u sluaju dekompozicije tabele i
gubitka jedne ili vie funkcionalnih zavisnosti
Kolika e biti koliina redundantnih podataka (podataka koji se ponavljaju) u sluaju da se dekompozicija ne izvri, tj. da se ostane na 3NF.
14.8. etvrta normalna forma (4NF)

Iako BCNF eliminie sve anomalije koje proistiu iz funkcionalnih zavisnosti, dalja istraivanja su dovela do uoavanja jo jednog tipa zavisnosti koji se
naziva zavisnost viestruke vrednosti koji takoe moe da prouzrokuje redundatnost podataka.
14.8.1. Zavisnost viestruke vrednosti

Pojava zavisnosti viestruke vrednosti u tabeli moe da se desi zbog
1NF koja ne dozvoljava da atribut ima vie vrednosti, tj. da se sastoji iz vie
podataka. Zavisnost viestruke vrednosti bie objanjena na primeru tabele
144
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 ekspozituri B003, a vlasnici nekretnina Jelena Jankovi i Predrag Stefanovi su registrovani
u istoj ekspozituri, dakle B003. Poto ne postoji direktna veza izmeu 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
viestruke vrednosti u tabeli EkspozituraZaposleniVlasnik. Drugim reima, zavisnost postoji zato to su u tabeli predstavljene dve nezavisne 1:* veze.
Zavisnost viestruke vrednosti predstavlja zavisnost izmeu atributa A, B i
C u tabeli, takvu da za svaku vrednost A postoji vie vrednosti B i vie vrednosti
C, pri emu su vrednosti B i C nezavisne jedna od druge.
14.8.2. Definicija etvrte normalne forme

Tabela je u 4NF ako je u BCNF i ako ne sadri zavisnosti viestruke vrednosti.
4NF je jaa normalna forma od BCNF, jer ne dozvoljava da tabele imaju
zavisnost viestruke vrednosti, a samim tim i redundantne podatke (podatke koji
se ponavljaju). Normalizacija iz BCNF u 4NF se vri dekompozicijom tabele i
izmetanjem atributa zajedno sa njihovim determinantama u novu tabelu. Tabela EkspozituraZaposleniVlasnik iz prethodnog pasusa se dekomponuje na tabele
EkspozituraZaposleni i EkspozituraVlasnik.
IdentBrEkspoziture
ImeZaposlenog
B003
Zoran Petrovi
B003
Jelena Jankovi
B003
Miodrag Aleksi
B003
Predrag Stefanovi
Tabela: EkspozituraZaposleni
IdentBrEkspoziture ImeVlasnikaNekretnine
Tabela: EkspozituraVlasnik
145
4NF eliminie redundantnost podataka (podatke koji se ponavljaju) i

mogunost pojave anomalija auriranja.
14.9. Peta normalna forma (5NF)

Uvek kada se vri dekompozicija tabele na dve nove, rezultujue tabele imaju svojstvo poznato kao postojanost spajanja (lossless-join). Ovo svojstvo se odnosi
na injenicu da se tabele nastale dekompozicijom mogu ponovo spojiti u originalnu tabelu. Meutim, postoje sluajevi kada je potrebno izvriti dekompoziciju
originalne tabele na vie od dve nove tabele. Iako se u praksi prilino retko sreu,
ovakvi sluajevi se reavaju primenom pete normalne forme (5NF).
14.9.1. Postojanost spajanja (lossless-join)

Postojanost spajanja je svojstvo dekompozicije koje omoguava da se, prilikom ponovnog spajanja tabela, generiu samo originalni podaci.
Dakle, postojanost spajanja osigurava da se, prilikom ponovnog spajanja
dve tabele u onu ijom su dekompozicijom nastale, generiu samo oni podaci koji
su postojali u originalnoj tabeli pre dekompozicije, to znai da je zagarantovana
potpuna rekonstrukcija originalne tabele.
14.9.2. Definicija pete normalne forme

Tabela je u 5NF ako nema zavisnosti spajanja.
Normalizacija do 5NF se vri dekompozicijom tabele u kojoj se uoe
zavisnosti spajanja na vie od dve nove tabele. Vano je napomenuti da e
ponovno spajanje bilo koje dve od novonastalih tabela generisati lane
podatke, ali e zato ponovno spajanje svih novonastalih tabela verno rekonstruisati originalnu tabelu.
146
Poglavlje 15
Transakcije
Danas je veoma bitan i znaajan koncept baze podataka po kome je to, u
stvari, zajedniki resurs koga istovremeno (konkurentno) koristi vei broj programa, jer se pravi efekti baze podataka ispoljavaju kada se radi u mrenom
okruenju. DBMS je upravo tu da upravlja konkurentnim radom vie korisnika,
obezbeuje sinhronizaciju njihovog rada...
Takoe, DBMS ima funkciju da sprei tetne posledice (naruen integritet
baze, nekonzistentno stanje baze...) pri promenama (transakcijama) koje se vre
nad bazom podataka u viekorisnikom okruenju, a za to koristi tehnike zakljuavanja podataka. Dalje, u tom smislu posebno je znaajno upravljanje istovremenim (konkurentnim) transakcijama.
Baze podataka kontinuirano skladite informacije koje opisuju trenutno
stanje preduzea. Na primer, baza podataka banke skladiti trenutni bilans na
svakom raunu deponenta. Kada se u stvarnom svetu dogodi neto to menja stanje preduzea, mora da se uradi odgovarajua promena informacija u
bazi podataka. Sa dostupnim DBMS-om, ove promene se deavaju u realnom
vremenu, uz pomo programa koji se nazivaju transakcije koje deluju kada
doe do promena u stvarnom svetu. Na primer, kada klijent stavlja novac u
banku (dogaaj u stvarnom svetu), izvrava se transakcija depozita. Svaka
transakcija mora biti ureena tako da odrava preciznost veze izmeu stanja
baze podataka preduzea koje je kreira i stvarnog sveta. Pored toga to menja
stanje baze podataka, transakcija sama po sebi moe da inicira neke dogaaje
u stvarnom svetu. Na primer, izdvojena transakcija kod bankomata, inicira
dogaaj odliva novca.
Transakcije
147
Odobravanje kreditne kartice je samo jedan primer transakcije koja moe

biti sprovedena za vreme npr. godinjeg odmora u inostranstvu. Pripreme za let
ukljuuju transakciju sa bazom podataka za rezervaciju karata, prolazom kroz
pasoku kontrolu na aerodrom, ukljuujemo i transakciju sa bazom podataka
imigracione slube, a sa prijavljivanjem u hotelu ukljuili smo i transakciju sa
hotelskom bazom podataka za rezervacije soba. ak i telefonski poziv koji se obavi iz telefonske sobe ukljuuje transakciju sa hotelskom bazom podataka zajedno
sa meunarodnim prenosnikom koji uspostavlja vezu. Drugi primeri transakcija
koje se redovno sprovode u svakodnevnom ivotu, ukljuuju i bankomate, skener
sistem u supermarketu, prijave na univerzitetima i sl.
U veini aplikacija baze podataka se koriste kako bi se modelovalo stanje nekog stvarnog preduzea. U takvim aplikacijama transakcija predstavlja
program koji posreduje sa bazom podataka, tako da podrava slaganje stanja
preduzea i stanja baze podataka. Praktino reeno, transakcija aurira bazu
podataka tako da prikazuje dogaaje koji su se odrazili na stanje stvarnog preduzea. Jedan primer bi bila transakcija polaganja novca u banku. Klijent daje
blagajniku novac kao depozit. Transakcijom se aurira informacija o raunu
klijenta u BP kako bi se prikazao depozit.
15.1. Definicija transakcije

Obino se transakcijom naziva niz operacija nad bazom podataka koji
odgovara jednoj logikoj jedinici posla u realnom sistemu. Vano je istai da
ta logika jedinica posla se izvrava do kraja ili se ponitava u celini. Drugim
reima, zahteva se da transakcija bude atomska (nedeljiva) i da sve instrukcije
jedne transakcije moraju biti izvrene ili nijedna. U tom smislu, transakcija
predstavlja osnovnu programsku jedinicu kojom se obezbeuje ouvanje konzistentnosti baze.
Naravno, u jednom trenutku nad bazom podataka se moe izvravati vie
transakcija, i imajui u vidu gore reeno, transakciona obrada oznaava grupisanje izmena sadraja baze podataka u paket koji se potom obrauje kao neraskidiva celina. Obrada se uvek odvija tako da se uspeno izvre ili sve transakcije,
ili nijedna od njih.
148
Transakcije
Transakciona obrada je korisna u aplikacijama u kojima jedna akcija mora

da se izvri u vezi sa jednom ili vie drugih akcija. Transakciona obrada je uobiajena u bankarskim, raunovodstvenim i mnogim drugim aplikacijama.
Na primer, kada u nekoj aplikaciji za bankarsko poslovanje premetamo
iznos sa jednog rauna na drugi, ne bismo eleli da stanje na jednom raunu
poveamo, a da ga pri tom na drugom raunu ne smanjimo. Zato emo te dve
izmene grupisati u jednu transakciju.
Transakciona obrada je izuzetno vana u viekorisnikim aplikacijama.
Kada vie korisnika istovremeno unosi izmene u bazu podataka, vie se ne
moemo pouzdati u to da e uvek jedna izmena biti trajno upisana u bazu pre
nego to zapone naredna, osim ako odreenu grupu izmena ne uokvirimo
u transakciju. Zbog toga bi u viekorisnikom okruenju trebalo da koristimo transakcionu obradu.
15.2. Osobine transakcija

Sve transakcije imaju sledee osobine:
atomnost (atomicity),
konzistentnost (consistency),
izolacija (izolation),
trajnost (durability).
Atomnost podrazumeva skup aktivnosti nad bazom podataka po principu sve ili nita. Ili su sve aktivnosti uspeno obavljene ili je baza podataka
ostala nepromenjena. DBMS, pored atomnosti transakcija, mora da garantuje
atomnost svake aktivnosti (pojedinane operacije). Primetimo da obini programi ne moraju imati osobinu atomnosti. Npr. ako je sistem pao u trenutku
dok je program aurirao neki fajl, kada smo podigli sistem, fajl je ostao delimino promenjen. Atomnost izvrenja znai da je svaka transakcija ili potvrena,
ili smo odustali od nje.
Konzistentnost znai da transakcija treba da prevede bazu podataka iz jednog u drugo konzistentno stanje. Za vreme obavljanja transakcije konzistentnost
baze podataka moe da bude naruena. Ukoliko u toku transakcione obrade doe
Transakcije
149
do greke, podaci moraju biti vraeni u stanje pre poetka transakcije. Transakcijom se mora pristupati i aurirati BP tako da sva ogranienja integriteta BP ostanu
zatiena. Svaka realna organizacija je organizovano u odnosu na odreena pravila koja ograniavaju mogua stanja organizacije.
Npr. broj studenata prijavljenih za nastavu ne moe prei broj mesta namenjenih za tu nastavu. Kada takvo pravilo postoji, mogua stanja BP su
ograniena na isti nain. Ogranienja integriteta, u odnosu na pomenuta pravila,
potvruju da broj registrovanih studenata koji se unosi u polje BP ne sme da pree
vrednost polja BP koja odgovara veliini sale. Dakle, kada se transakcija registracije zavri, BP mora da zadovolji ovo ogranienje integriteta (pretpostavljajui da
je ogranienje zadovoljeno na poetku transakcije).
Izolacija znai da kada se dve ili vie transakcija izvravaju istovremeno,
njihovi efekti moraju biti meusobno izolovani. Efekti koje izazovu transakcije koje se obavljaju istovremeno moraju biti jednaki efektima nekog njihovog
seriskog (jedna posle druge) izvrenja. Zbog poveanja paralelizma u obradi
transakcija dozvoljavaju se razliiti nivoi izolovanosti.
Prilikom rasprave o konzistentnosti BP, usredsredili smo se na efekat jedne
transakcije. Sledee to emo ispitivati je efekat niza transakcija. Rekli smo da
se niz transakcija izvodi sekvencijalno, ili serijski, ako se jedna transakcija niza
izvri pre nego to druga pone. Dobra vest kod serijskog izvravanja je da ako su
sve transakcije konzistentne i baza podataka je inicijalno u konzistentnom stanju.
Serijsko izvravanje uva konzistentnost. Kada prva transakcija niza zapone, BP
je u konzistentnom stanju, a s obzirom da je transakcija konzistentna i nakon njenog izvrenja BP e biti u konzistentnom stanju. Zbog toga to je BP konzistentna
pre poetka druge transakcije, i druga e se obaviti korektno.
Serijsko izvravanje je adekvatno za aplikacije iji su zahtevi skromni.
Meutim, mnoge aplikacije imaju stroge zahteve vremena odziva i pristupa, i
esto jedini nain da se zahtevi zadovolje je konkurentno izvravanje transacija.
Moderni sistemi mogu da istovremeno izvravaju vie od jedne transakcije, a
ovaj metod izvravanja nazivamo konkurentnim. Konkurentno izvravanje je
adekvatno kada se sistemom za obradu transakcija slui vie korisnika. U tom
sluaju bie dosta aktivnih, delimino zavrenih transakcija u svakom trenutku.
Kada se transakcije izvravaju konkurentno, konzistentnost svake od njih nije
dovoljna da obezbedi da baza posle izvrenja obe transakcije u potpunosti prikazuje stanje preduzea.
150
Transakcije
Trajnost znai da kada se transakcija zavri (potvrene promene), njeni

efekti ne mogu biti izgubljeni, ak i ako se neposredno po njenom okonanju 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 potvrena, svoj efekat prenese na BP, pa ak i ako kompjuter, ili medijum
na kojem je BP smetena, iznenada prestane da radi.
Npr. ako ste se uspeno prijavili za kurs, oekujete da sistem zapamti vau
registraciju pa ak i ako posle toga prestane da radi. Moemo da primetimo da
obini programi ne moraju imati osobinu trajnosti. Npr. ako se pojave problemi
poto je program izvrio promenu nekog fajla, fajl moe biti vraen u stanje pre
izvrene promene.
15.3. COMMIT i ROLLBACK

Obezbeenje ACID (akronim od rei Atomicity, Consistency, Isolation, Durability) osobina transakcije se radi upotrebom odreenih metoda i
instrukcija:
transakcija poinje sa BEGIN TRANSACTION,
zavrava se sa COMMIT, ime se potvruju promene u bazi podataka
ako su sve instrukcije uspeno izvrene,
zavrava se sa ROLLBACK, ako sve instrukcije nisu uspeno zavrene.
U stvari, postupak transakcije poinje pozivanjem metode BeginTrans, ime
se oznaava poetak niza operacija koje ine jednu logiku jedinicu. Metoda
CommitTrans preuzima sve izmene nainjene od poslednjeg mesta na kome je
bila pozvana metoda BeginTrans i upisuje ih na disk. Metoda RollbackTrans deluje
na suprotan nain od CommitTrans ona ponitava sve izmene i vraa stanje
kakvo je bilo pre poslednjeg poziva metode CommitTrans.
SUBP inicira iz bilo kog razloga ROLLBACK instrukciju, ako doe do
neplaniranog zavretka transakcije.
S obzirom da jedan program moe predstavljati kolekciju transakcija, transakcije mogu biti i ugnjedene. U tom sluaju, COMMIT instrukcija se izvrava
od najnieg do najvieg nivoa, a dovoljno je da se ROLLBACK pojavi samo na
jednom mestu i ponitavaju se promene svih transakcija.
Transakcije
151
SUBP poseduje i odrava dnevnik transakcija (tj. dnevnik aktivnosti,

log file). Za svaku transakciju i za svaki objekat baze podataka koji je ona
aurirala uva se:
vrednost pre auriranja (before-image)
vrednost posle auriranja (after-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 prekine Commit naredba, mogu se proitati vrednosti posle sa log fajla, to omoguava
ouvanje konzistentnog stanja.
15.4. Konkurentno izvravanje transakcija

Nad modernim bazama podataka transakcije se ne obavljaju u izolovanosti
ve konkurentno. Vie transakcija mogu istovremeno zahtevati iste resurse, isti
zapis baze podataka, itd. U takvim situacijama otvara se mogunost da nekontrolisan meusobni uticaj transakcija dovede do nekonzistentnog stanja.
Ve je nagoveteno da je jedan od zahteva SUBP da upravlja konkurentnim
radom vie korisnika, obezbeuje sinhronizaciju njihovog rada... a sve u cilju
spreavanja tetnih posledica pri promenama koje se vre nad bazom podataka u
viekorisnikom okruenju.
Komponente SUBP koje uestvuju u ovom procesu su:
Planer (Scheduler),
Menader transakcija (Transaction manager).
Planer vodi rauna o redosledu akcija kod vie konkurentnih transakcija.
Ako itanje ili upisivanje moe da narui integritet baze podataka, zahtev se ili
vremenski odlae ili se ponitava cela transakcija.
Menader transakcija upravlja celokupnim izvrenjem transakcija.
Idealan sluaj izvravanja transakcija je serijsko izvravanje. Posledica je
korektan rezultat. Serijsko izvravanje transakcija, u stvari, znai da:
nema preplitanja transakcija,
prvo se zavri jedna, zatim druga...
152
Transakcije
Konkurentno izvravanje transakcija je serijabilno (linearno) ako daje isti

rezultat kao i serijsko izvravanje svih transakcija.
Interesantno je da kada se koriste transakcije, poveava se stepen integriteta
izmena koje korisnik unosi, ali se smanjuje konkurentnost, odnosno mogunost
da pomou date aplikacije vei broj korisnika istovremeno menja podatke, jer ima
vie zapisa koji su zakljuani due vreme.
Slika 15.1. Paralelno i serijsko izvravanje transakcija
15.5. Protokol zakljuavanja

Velika je verovatnoa da, ako nema ogranienja, izvravanje transakcija nee
biti serijabilno, a provera serijabilnosti se teko moe obaviti u realnom vremenu.
Zato se vri jedan nain ograniavanja, tj. zakljuavanje i otkljuavanje podataka.
U stvari, mehanizam zakljuavanja (locking) predstavlja upravo nasilno
ostvarivanje serijabilnosti. Transakcija zakljuava objekat baze podataka kome je
pristupila, ime je onemogueno drugim transakcijama da nekorektno operiu.
Postoje dva osnovna nivoa zakljuavanja, na nivou stranice i na nivou
zapisa. Zakljuavanje na nivou stranice je u stvari zakljuavanje itave stranice sa zapisima, a ne zakljuavanje samo pojedinih zapisa, to je sluaj sa
Transakcije
153
zakljuavanjem na nivou zapisa. To znai da, na primer, kada se primenjuje

zakljuavanje na nivou zapisa, vie korisnika moe istovremeno da aurira
zapise u istoj tabeli, nasuprot sluaju kada bi bila zakljuana cela tabela sa
svim zapisima u njoj (na primer, verzije Accessa pre Accessa 2000 nisu omoguavale pravo zakljuavanje na nivou zapisa).
Zakljuavanje na nivou zapisa obezbeuje znatno bolje mogunosti viekorisnikog pristupa podacima. Meutim, treba voditi rauna da to ne znai uvek i
bolje performanse. Kada se istovremeno aurira veliki broj zapisa, zakljuavanje
na nivou stranice moe da obezbedi bolje performanse. Ipak, u veini sluajeva,
bolje mogunosti viekorisnikog pristupa podacima, nadoknauju neto slabije
performanse.
Postoje dva osnovna pristupa u strategiji zakljuavanja objekata baze
podataka, odakle se izdvajaju dve vrste zakljuavanja:
Ekskluzivno (exclusive lock ili write lock) ili pesimistiko XL
Deljivo (shared lock ili read lock) ili optimistiko SL
Ekskluzivno zakljuavanje znai da u svakom datom trenutku samo jedan
korisnik moe da menja objekat baze podataka. Drugim reima, ako jedna transakcija postavi XL katanac na objekat baze podataka to znai da ne moe ni jedna
druga transakcija da postavi katanac, i ne moe se postaviti ni jedan drugi katanac.
U sluaju ako se primenjuje zakljuavanje na nivou stranice, to je veliki problem,
jer u svakom trenutku samo jedan korisnik moe da aurira bilo koji zapis koji se
nalazi na zakljuanoj stranici.
Deljivo zakljuavanje omoguava da vie korisnika istovremeno aurira iste
zapise uz manji broj sukoba oko zakljuavanja zapisa. Drugim reima, ako jedna transakcija postavi SL katanac na objekat baze podataka to znai da druga
transakcija moe da postavi SL katanac na isti objekat, i ni jedna druga ne moe
da postavi XL katanac na taj objekat. Meutim, time se poveava rizik nastajanja
sukoba pri upisivanju podataka. Sukob pri upisivanju nastaje kada:
1. prvi korisnik poinje da aurira objekat baze podataka.
2. drugi korisnik upisuje u bazu podataka izmene objekta koje je on uneo.
3. prvi korisnik pokua da u tom trenutku upie svoje izmene.
Sukob pri upisivanju je tetan, jer on znai da prvi korisnik aurira drugaiji
objekat od onoga sa kojim je poeo da radi.
154
Transakcije
Verovatno je u izboru vrste zakljuavanja prihvatljivije ekskluzivno zakljuavanje, da bi se izbegli sukobi pri upisivanju. Meutim, uvek treba imati na umu
korisnike koji due vreme zakljuavaju objekte baze podataka. U tom sluaju bi
bilo dobro razmotriti upotrebu deljivog zakljuavanja. Ovaj problem delimino
moe biti reen i upotrebom ekskluzivnog zakljuavanja sa vremenskim ograniavanjem. Na primer, nekom obrascu se moe dodati mogunost vremenskog
ograniavanja tako da izmene koje korisnik nije snimio posle deset minuta automatski bivaju ponitene.
Protokol zakljuavanja obuhvata sledea pravila:
1. Transakcija koja ita neki objekat baze podataka mora da postavi SL na
taj objekat
2. Transakcija koja eli da aurira neki objekat mora da postavi XL. Ako je
ta transakcija prethodno postavila SL treba da ga promeni u XL
3. Ako transakcija nije postavila katanac, zato to je to pre uradila neka
druga, prelazi u stanje ekanja
4. Transakcija oslobaa XL i SL na kraju, sa COMMIT ili ROLLBACK
naredbom
Oba katanca XL i SL se postavljaju implicitno.
15.6. Oporavak baze podataka

Oporavak baze podataka (RECOVERY) predstavlja proces vraanja baze
podataka u korektno stanje. Sasvim je realno, i deava se, da usled otkaza sistema
mora da se uradi oporavak baze podataka. Uzroci otkaza mogu biti razliiti: greke u programiranju, greke 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 sluaju otkaza sistema,
oteena baza podataka se rekonstruie u ispravno stanje na osnovu poslednje
kopije, a nekonzistentno stanje se reava tako to se ponitavaju nekonzistentne
promene, a transakcije se ponavljaju.
Trajnost podrazumeva da nijedna promena u bazi podataka koju je napravila zapoeta transakcija, ne sme biti izgubljena. Iz tog razloga, a poto hard disk
Transakcije
155
moe da zakae, baza podataka se mora uvati na razliitim hard diskovima. Jednostavan primer postizanja trajnosti jeste uvanje razliitih kopija baze podataka
na razliitim diskovima (koji se, po mogustvu, napajaju iz razliitih izvora energije). Poto je istovremeni pad oba diska malo verovatan, velika je verovatnoa
da e barem jedna kopija hard diska biti uvek dostupna. Duplikat, ili disk imid,
podrava ovakav pristup. Slika hard-diska (duplikat mirrored disk) je sistem
uvanja po kome, kad god aplikacija zahteva da disk izvri operaciju upisa, sistem
simultano belei istu informaciju na dva razliita diska. Tako je prvi disk identina kopija, ili disk imid, onog drugog.
U transakcijama koje obrauju aplikacije, sistem disk imida moe da
dostigne izuzetnu dostupnost sistema. Ukoliko jedan disk imid padne, sistem moe da nastavi dalje koristei drugi, bez usporavanja ili zaustavljanja.
Kada se zameni disk koji je zakazao, sistem mora da ponovo sinhronizuje oba.
Nasuprot tome, kada se trajnost postie samo pomou LOG fajla (dnevnika), proces oporavka nakon pada hard diska moe trajati znatno due, 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 atominost na primer, da bi se ponitila transakcija nakon pada.
156
Transakcije
Poglavlje 16
Baze podataka i aplikacije

Nije redak sluaj da proizvoai savremenih sistema za upravljanje bazama
podataka (u daljem tekstu SUBP), pored serverske aplikacije (koja omoguava
administriranje korisnika, kontrolu pristupa, odravanje referencijalnog integriteta i konzistentnost podataka BP), najee 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 grafika okruenja koja
omoguavaju brzo kreiranje upita (QBE3), ugnjedenih procedura, izvetaja
i formi za unos podataka. Prethodno navedene prednosti omoguavaju brzu
izradu uslunih aplikacija.
Slika 16.1. vrsta sprega Access-a i MS JetDB

3
QBE query by example, alat koji omoguava kreiranje SQL upita bez potrebe poznavanja
sintakse SQL jezika. Primer QBE je Access-ov query designer i query wizard
157
Nedostatak ovako koncipiranih aplikacija je da su vrsto povezane za

razvojno okruenje (high coupling) i da je komunikacija sa okruenjem (ostalim
aplikacijama) obino teko izvodljiva, ili nemogua (slika 16.1). Posledica ovakvog
(jednoslojnog, ili dvoslojnog) modela je da se aplikacije dizajnirane na ovaj nain
teko odravaju (modikacija postojeeg reenja, unapreenje dodavanjem
novih komponenti, auriranje novim verzijama serverskih i klijentskih platformi
i sl.). Drugu manjkavost predstavlja injenica da je dizajn korisnikog interfejsa
i implementacija logike obrade podataka ogranieno na mogunosti klijentske
tehnologije. Na primer, ne mogu se menjati svi parametri ekranskih formi (izgled
kontrola), oteano je ubacivanje kontrola koje eksplicitno nisu ponuene, oteana je izrada novih vrsta kontrola. Programiranje je ogranieno mogunostima
programskih jezika ugraenog u klijentski alat (npr. Visual Basic for Access ne
podrava sve koncepte objektno orjentisanog programiranja).
Pojavom objektno orjentisanog programiranja (u daljem tekstu OOP)
omogueno je potpuno razdvajanje podataka od logike njihove obrade i od interfejsa prema korisnicima podataka. Aplikacija se gradi od objekata, od kojih svaki
preuzima odgovornost za obavljanje specinih funkcionalnosti aplikacije. Tako
se izdvajaju grupe objekata prema funkcionalnosti. Na primer, formira se grupa
objekata od kojih se gradi korisniki interfejs, ili, grupa objekata koji ostvaruju
konekciju sa BP, izvravaju upite nad bazom i prihvataju rezultate upita. Objekti
meusobno komuniciraju preko funkcionalnih poziva, pri emu ziki mogu biti
razdvojeni (na razliitim raunarskim platformama), a aplikacija time postaje distribuirana. Ova pojava grupisanja objekata prema osnovnim funkcionalnostima
je nazvana raslojavanje aplikacije.
16.1. Slojevita struktura aplikacija

Raslojavanje aplikacije predstavlja odvajanje njenih delova prema funkcionalnosti. U OOP, kao to je ve napomenuto, grupiu se objekti srodnih funkcionalnosti (u daljem tekstu slojevi). Grupisanjem je postignuto da se komunikacija
izmeu slojeva (funkcionalni pozivi) svedu na najmanju moguu meru i time
olaka odravanje aplikacije. Promene u funkcionalnosti (programskom kodu)
objekata jednog sloja nee imati posledice na objekte u ostalim slojevima, a imae
sporadine efekte ak i za objekte u istom sloju. Jedno od pravila dobrog dizajna
aplikacija je da se u izmeu objekata (klasa) u istom sloju postigne visoka kohezija
(high cohesion), a slaba sprega izmeu slojeva (low coupling).
158
16.2. Troslojni model kao osnovni model

Osnovni aplikacioni model je troslojni model, koji namee 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 prezentacionog sloja su zapravo objekti korisnikog interfejsa: forme za unos, promenu, brisanje i pregled podataka. Obradu podataka vri sloj poslovne (aplikacione)
logike. Ovaj sloj sadri kljune objekte sistema, koji sinhronizuju procese prezentacionog 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. Poto su podaci u troslojnom modelu dostupni (korisnicima posredstvom interfejsa prezentacionog sloja)
preko sloja poslovne logike (indirektno), moe se rei da su mogunosti zatite
integriteta podataka mnogo vee nego kod dvoslojnih aplikacionih modela.
16.3. Vieslojni modeli

Aplikacije mogu imati vie od tri sloja (Slika 16.3). Ova pojava je vezana za distribuirane poslovne sisteme, kod kojih podaci mogu biti razdvojeni na
159
vie razliitih mesta, i koji sadre vie nivoa obrade. Najei primer vieslojnih
distribuiranih sistema su Web aplikacije. Kod Web aplikacija, korisniku su vidljive
samo Web stranice, isporuene na klijentski pretraiva od strane Web servera i
komponovane od razliitih sadraja. Komponente stranice mogu biti kontrole za
interakciju sa korisnikom ili veze (linkovi) prema posebnim aplikacijama (modulima). Ove softverske komponente mogu biti ugnjedene na konkretnom serveru,
ali isto tako mogu biti distribuirane na razliite platforme.
Slika 16.3. etvoroslojni aplikacioni model

Distribuiranjem aplikacija vri se rastereenje hardverskih (serverskih) platformi i veza (linkova) izmeu korisnika i aplikacija. Poto se razliite grupe funkcionalnosti odvijaju na razliitim mestima, distribuiranjem
je olakano upravljanje i odravanje aplikacija. U primeru na prethodnoj
slici, prezentacioni sloj je Web pretraiva na klijentskoj platformi, a sloj
podataka ine 2 servera BP. Web server je zaduen za isporuivanje zahtevanih Web stranica klijentima. Takoe odgovoran je za upravljanje korisnikom sesijom. Drugi meusloj ine razliiti aplikacioni serveri (aplikacije):
za servisiranje elektronske pote, za upload i download fajlova, aplikacioni
server koji omoguava dinamiko komponovanje Web stranica i transakcionu obradu prema BP, itd.
160
16.4. Aplikacije servisi (nezavisne softverske komponente)

Iako su Web aplikacije vieslojne i distribuirane, njene softverske komponente su i dalje uzajamno zavisne i predstavljaju deo jedne celine. Da bi se
omoguilo da softverska komponenta bude dostupna razliitim aplikacijama, bila je potrebna formalizacija interfejsa koja bi omoguila komuniciranje
sa komponentom. Web servisi su zasnovani na tri osnovna standarda: XML
4
(za prikazivanje podataka), SOAP 5(za razmenu podataka izmeu davalaca i korisnika servisa) i, za potrebe opisa servisa, definisan je poseban jezik
WSDL6 i nain 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 direktorijuma Web servisa (Slika 16.4). Registrovanje bi znailo da se Web servis formalno opisuje WSDL-om (naziv servisa, lokacija servisa, nain pristupa servisa),
kako bi korisnici mogli da ga eksploatiu. 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 nain proiruju svoje funkcionalnosti koje pruaju krajnjim korisnicima.
to je dokumentacija za API7 kod konvencionalnih aplikacija, to je WSDL opis
Web servisa kod njihovih davalaca. Najei nain razmene podatka izmeu
4
5
6
7
XML extensible markup language

SOAP simple object access protocol
WSDL Web Service Denition Language
API Application Programmable Interface
161
davalaca i korisnika Web servisa je korienjem SOAP-a. Format podataka koji

se razmenjuju je u XML formatu.
Web servisi predstavljaju tehnologiju budunosti, jer omoguavaju povezivanje razliitih aplikacija, tehnologija, postavljenih na razliitim platformama.
Formalizacija opisa servisa omoguava njihovu mainsku itljivost tako da aplikacije postaju uzajamno kooperativne bez posredovanja oveka. Web servisi ukidaju i barijere izmeu tzv.desktop i Web aplikacija.
16.5. Specifinosti pristupa BP iz

razliitih aplikacionih slojeva
16.5.1. Pristup podacima iz prezentacionog sloja
Prezentacioni sloj sadri objekte korisnikog interfejsa. Bez obzira da li se
radi o Desktop ili Web aplikacijama, to su uokvireni prozori sa naslovnom linijom
i koji sadre kontrole za interakciju sa korisnikom (Slika 16.5).
Slika 16.5. Izgled korisnikog interfejsa Desktop aplikacije

Svaka kontrola prezentacionog sloja predstavlja poseban objekat, koji se
moe dodati prevlaenjem sa palete tzv. Drag&Drop (ako se koristi vizuelni
162
alat za dizajn), ili unoenjem programskog koda u datoteku (ako se koristi obian
tekstualni editor). Fiziki gledano, formiraju se fajlovi (datoteke) odreenog tipa,
koji sadre kod koji se kompajlira, linkuje i izvrava, ili se interpretira (od strane
raunara) generiui pritom korisniki interfejs.
Korisniki interfejsi kod Web aplikacija dizajniraju se u skladu sa ogranienjima Web itaa koji se koriste na klijentskoj strani (Internet Explorer, Netscape navigator, Modzila i sl). ita interpretira HTML skript koji je primljen od
strane Web servera i otvara Web stranicu koja u sebi moe da sadri formu sa
kontrolama. Ovi interaktivni elementi omoguavaju korisniku unos podataka i
akcije slino kao kod desktop aplikacija.
Slika 16.6. Izgled korisnikog interfejsa Web aplikacije

Izgled i funkcionalnosti interfejsa odreeni su odgovarajuim programskim kodom sadran u datotekama aplikacija. U ove datoteke mogu da se dodaju i funkcionalnosti za pristup podacima iz BP. Za sluaj kada se direktne funkcije za itanje, auriranje i dodavanje podataka iz/u BP deniu u fajlovima u
kojima se denie korisniki interfejs kaemo da predstavlja pristup podacima
iz prezentacionog sloja.
Access-ove datoteke predstavljaju najei primer pristupa podacima
iz prezentacionog sloja. U fajlovima koji imaju mdb ekstenziju integrie se
163
kompletna BP, sa formama, izvetajima, 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 korienjem VBA skripta koji sadri SQL naredbu
Ovakve aplikacije su obino voene dogaajima korisnikog interfejsa
(Event Driven Applications). Prethodni primer (Fragment 1) predstavlja proceduru koja je vezana za formu (korisn.interfejs) i koja se aktivira na dogaaj
zatvaranja forme. U linijama 2-5 predstavljena je jedna SQL naredba koja aurira
tabelu KolicineSred postavljajui polje KOLIC u zapisu prema uslovima u WHERE klauzuli (id broj i ifra dugovanja) na vrednost sadranu u kontroli RecSum u
formi Tsredstva.
Na slian nain funkcionie pristup podacima iz prezentacionog sloja u
Web aplikacijama. Kao to je reeno, ove aplikacije takoe sadre forme popunjene kontrolama koje omoguavaju unos i pregled podataka.
Fragment 2: Izgled Web stranice

8
164
VBA Visual Basic for Access
Fragment 3: Kod Web stranice iz fragm.2
Forme u Web aplikacijama predstavljene su stranicama koje su kodirane

u HTML jeziku (Fragment 3). Web ita na klijentskoj maini interpretira ovaj
kod i prikazuje stranicu u svom prozoru (Fragment 2). U gornjem primeru prikazane su kontrole za unos teksta (rma, adresa,postkod). Kada korisnik unese
potrebne podatke, pritiskom na dugme dodaj, pokree se akcija u zaglavlju stranice (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_rme, adresa, postbroj)
8: sql=sql & VALUES
9: sql=sql & ( & Request.Form(rma) & ,
10: sql=sql & & Request.Form(adresa) & ,
11: sql=sql & & Request.Form(postkod) & )
12: on error resume next
13: conn.Execute sql,recaected
14: if err<>0 then
15: Response.Write(Nemate prava na dodavanje podataka!)
16: else
17: Response.Write(<h3>Klijent & Request.Form(rma) 18: & je dodat</h3>)
19: end if
20: conn.close
21: %>
22: </body>
23: </html>
Fragment 4: Sadraj demo_add.jsp
Razlika kod Web aplikacija je to se kod za pristup BP izvrava na Web serveru. Podaci koje je korisnik uneo prenose se u vidu HTTP9 zahteva na server,
gde se koriste pri izvravanju fajla demo_add.asp. Navedena datoteka kreirana je u
ASP10 tehnologiji i predstavlja samo jednu od velikog broja Web tehnologija koje
omoguavaju dinamiko generisanje sadraja. Ova datoteka (Fragment 4), pored
9
10
HTTP Hypertext Transfer Protokol protokol koji omoguava transfer podataka izmeu
Web stranica
ASP Active Server Pages, Microsoft tehnologija za generisaje dinamikih Web stranica
165
standardnog HTML koda, sadri i programski kod pisan u nekom od jezika proizvedenih u Microsoft-u (C++, C#, VisualBasic), koji je korien za unos podataka u BP. Nakon uspostave konekcije sa Access-ovom BP partneri.mdb (lin.4-6),
komponuje se SQL naredba koja treba da izvri dodavanje podataka u tabeli kupci
koje je korisnik uneo preko prethodne Web stranice (Fragment 2 i 3) (lin.7-11).
Izvrenje stringa SQL naredbe vri se preko objekta konekcije conn (lin.13). Ako
je dodavanje zapisa uspeno, server isporuuje klijentskom itau zahtevanu stranicu s porukom Klijent <naziv> je dodat. Ako dodavanje nije uspelo, prikazae 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>). Proizvoai framoworkova za razvoj Web aplikacija nude i tag-ove za komunikaciju sa BP. Na primer za
JSP11 postoji biblioteka tag-ova JSTL12, koja sadri sql tag-ove. Korienjem sql tagove, postie se neposrednost i standardni pristup u razmeni podataka aplikacije i
BP. Da bi se sql tag-ovi koristili u Web stranicama, potrebno je ukljuiti biblioteku
tagova i izvriti konekciju prema BP.
1: <sql:query var=upit1>
2: SELECT * FROM moja_tabela
3: </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: Korienje SQL tag-ova za generisanje upita
U prethodnom primeru (Fragment 5) predstavljen je upit korienjem sql
tag-a query. Sql tag predstavlja poseban entitet (lin.1-3), koji je imenovan kao
upit1. U ovom tagu je ugnjeden standardni SQL upit (lin.2). Poto je upit izvren,
11
12
166
JSP Java Server Pages, Java tehnologija za generisaje dinamikih Web stranica
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 smetaju nazivi kolona (lin.4-6) koji se dobijaju iz sql tag-a pozivom njegove metode columnNames. Nakon toga se pomou
2 for petlje, ugnjedene jedna u drugoj (lin.7-13 spoljnja, lin.9-11- unutranja), formiraju red po red, korienjem sql tag metode rows, a u svakom redu se,
korienjem sql tag metode value, popunjavaju konkretne vrednosti podataka za
svako polje (kolonu).
PHP je Web orijentisan programski jezik, ali i jedna od najmasovnije
korienih tehnologija za kreiranje Web aplikacija. U poetku ist proceduralan
jezik, koji jako podsea na C, prerasta sa verzijama 4 i 5 u objektno orjentisan
jezik koji se moe 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 oznaene preksom $ ($result, $num itd.). PHP jezik sadri izuzetno bogatu podrku za MySQL SUBP. Postoji veliki broj ugraenih funkcija 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 izvrenje SQL INSERT/UPDATE/SELECT naredbe
(lin.3); mysql_numrows za dobijanje broja zapisa kao rezultata (lin.4); mysql_close za zatvaranje konekcije sa BP i SUBP (lin.5). Za razliku od ostalih
jezika, PHP omoguava pristup podacima u rezultujuem 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
167
mestu), kao to su aplikacije za testiranje i isprobavanje. Ovakav pristup je pogodan i u sluajevima kada se izvravaju jednostavne SQL naredbe (naredbe koje ne
sadre ugnjedavanje, ne obuhvataju kombinovane podatke iz vie tabela) i kada
je ciljni SUBP unapred poznat i nepromenjiv.
Za razliite vrste SUBP, pa ek i za razliite verzije SUBP od istih proizvoaa, postoje razlike u sintaksi SQL naredbi. U sluaju promene, ili instalacijom
nove verzije SUBP, neretko je potrebno menjati kod SQL naredbi koji se nalazi u
objektima korisnikog inerfejsa. Ovo je jedna od kljunih slabosti pristupa podacima iz prezentacionog sloja.
Poslovne aplikacije su znatno sloenije. Za sloenije13 aplikacije, ovakav
pristup bi doveo do konfuzije ve u procesu implementacije, jer bi se preklapali
poslovi dizajnera i programera. Odravanje i upravljanje neraslojenim softverom
je mukotrpno i esto ispod oekivanih rezultata.
16.5.2. Pristup podacima iz sloja poslovne logike

Ovo je najee korien pristup kod vieslojnih aplikacija. U sloju poslovne
logike postoje entiteti (klase ili moduli) koji su zadueni za komunikaciju sa BP.
Preostali delovi aplikacije razmenjuju podatke sa BP iskljuivo preko ovih entiteta. U OOP, klase koje omoguavaju interakciju sa BP, obino su ve dizajnirane i
implementirane od strane proizvoaa SUBP, ili proizvoaa softverskih 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 izvoenjem iz ponuenih, modikujui im funkcionalnosti prema
specinim potrebama aplikacije.
U sledeem 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 preuzimanje podataka iz tabele proizvoda. Ako je konekcija s BP uspostavljena, dinamiki
se kreira pSet objekat klase ProizvodiSet (lin.6). Funkcija Open nasleena je iz
CRecordset klase. Ova funkcija ima opcioni broj argumenata. Jedan od argumenata je SQL naredba koja treba da se izvri u BP. Ako nema argumente, podrazumeva se da se uzima celokupan skup zapisa iz tabele proizvoda.
13
168
Sloenost aplikacije, izmeu ostalog, predstavljena je brojem razliitih fukcionalnosti

koje aplikacija moe da obavi
Fragment 7: Korienje MFC C++ klasa

u komunikaciji s BP
Fragment 8: Korienje Java klasa iz

paketa java.sql u komunikaciji s BP
Objekat pSet prihvata sve podatke dobijene iz BP. Konkretnim podacima

pojedinanih zapisa se pristupa u ciklinoj strukturi (while petlja, lin.8-12). Podaci se dobijaju posredno, preko pSet objekta, koji sadri podatke koji odgovaraju
poljima odgovarajue tabele. Na primer, podatak m_Naziv u klasi ProizvodiSet
(lin.10) odgovara polju naziv u tabeli proizvodi. Nakon preuzimanja podataka jednog zapisa, poziva se funkcija MoveNext nasleena od klase CRecordset, tako da
se u sledeoj iteraciji preuzimaju podaci sledeeg zapisa iz tabele. Nakon preuzimanja podataka, zatvara se i unitava pSet objekat (lin.13,14) i konekcija s bazom
(lin.15). Ostale naredbe (lin.17 do kraja) namenjene su za reavanje greaka tokom konekcije s BP.
U sledeem fragmentu (Fragment 8) predstavljeno je korienje Java klasa
iz paketa java.sql. Nakon instanciranja potrebnih objekata (Connection, ResultSet,
ResultSetMetaData, Statement), vri se povezivanje s bazom (lin.7), a zatim izvrenje 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 greke.
169
Slika 16.7. Pristup BP iz klasa poslovne logike

Oba primera (Fragmenti 7 i 8) ukazuju na veoma slinu metodologiju. Najpre se instanciraju potrebni objekti, zatim se uspostavi konekcija s ciljnom BP,
obavi se eljeni transfer podataka. Pri tome, podaci se uzimaju/menjaju/dodaju iz/u tabele BP, korienjem objekata u sloju poslovne logike. Pre zavretka
metoda konekcija s BP se zatvara na nain predvien standardnim protokolom,
a cela operacija se nadzire korienjem try catch blokova za kontrolu neeljenih
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 izmeu entiteta u BP i
ostalih objekata aplikacije.
16.5.3. Pristup iz sloja podataka

(poziv ugnjedenih procedura)
Pristup podacima u BP iz sloja poslovne logike ima nekoliko nedostataka.
Ovi nedostaci proizilaze iz injenice da se SQL naredbe (za upite, brisanja, dodavanja i izmene podataka) nalaze direktno u izvornom kodu aplikacije (zapravo u
klasama sloja poslovne logike). Takozvano hardcode-iranje naruava optimizovanost koda - time i cele aplikacije. Pristup BP iz sloja podataka poveava obim koda,
170
ime se oteava njegovo auriranje. Na primer ako se vri promena strukture, ili
naziva jedne tabele u BP, ovo auriranje mora da se izvede u svim SQL naredbama
u izvornom kodu, u kojima se referenciraju podaci te tabele. Tranzijentno, aplikacija mora ponovo da se generie, instalira i podeava. Kod aplikacija u velikim
poslovnim sistemima, ovakav pristup moe da stvori mnoge probleme.
Reenje za ovakav problem je izmetanje SQL naredbi iz izvornog koda aplikacije u SUBP. SQL naredbe se ugnjedavaju kao procedure (stored procedure) u
ciljnu BP (u jednom SUBP moe biti vie BP). Veina dananjih SUBP omoguava
kreiranje ugnjedenih procedura.
1: CREATE PROCEDURE `spUsedTestSets`(IN u_id INTEGER(11))
2: BEGIN
3: SELECT * FROM `t_mtutor_used_test_sets` WHERE ( user_id = u_id );
4: END;
Fragment 9: Primer denisanja ugnjedene procedure
U prethodnom fragmentu (Fragment 9) prikazana je denicija 1 ugnjedene procedure u SUBP MySQL 5.x. Ugnjedena procedura slina je bilo kojoj funkciji, izuzev to ne vraa vrednosti, ve sadri samo parametre. Parametri mogu
biti ulazni oznaeni slubenom reju IN, i izlazni oznaeni slubenom reju
OUT. Kod procedura koje vraaju vie zapisa, esto se deniu samo ulazni parametri. Umesto izlaznih parametara, rezultati (zapisi) se prihvataju korienjem
klase koja enkapsulira skup zapisa (npr. ResultSet, ili CRecordset). Pri denisanju,
procedura se najpre imenuje i deklariu se njeni parametri (lin.1). Implementacija zapoinje slubenom reju BEGIN, a zavrava slubenom reju END. Izmeu
poetka i kraja je telo procedure u vidu SQL izraza koji treba da se izvri (lin.3).
Ulazni prametri procedure se u telu koriste najee kao kriterijumi SQL izraza
(u_id). Denisane procedure se pozivaju iz aplikacije, prosleivanjem argumenata i prihvatanjem rezultata njihovog izvrenja.
U sledeem primeru (Fragment 10) prikazan je nain korienja ugnjedene procedure u Java kodu. Najpre se (lin.1) preko objekta konekcije sa BP
(conn) vri njeno pozivanje (naziv procedure je spUsedTestSets) i preuzimanje od strane objekta aplikacije (cs). Zatim se preko istog objekta prosleuju
parametri (lin.2).
1: cs = conn.prepareCall({call spUsedTestSets(?)});
2: cs.setInt(user_id, u_id);
3: rs = cs.executeQuery();
171
4: while( rs.next() ){
5: int test_id = rs.getInt(test_set_id);
6: Date test_dat = rs.getDate(date);
7: }
Fragment 10: Primer korienja ugnjedene procedure
Upit se izvrava eksplicitnim pozivanjem (lin.3). Rezultati upita se prihvataju u objekat klase Recordset (rs). Kroz ciklinu strukturu (lin.5-7), preuzimaju se
pojedinani podaci iz skupa zapisa dobijenih upitom.
Slika 16.8. Pristup BP preko ugnjedenih procedura

Korienje ugnjedenih procedura smanjuje kompleksnost sloja poslovne
logike (Slika 16.8). S druge strane, poveava se kompleksnost BP i optereuje se
SUBP. Posledica toga je da se deo programerskih poslova prebacuje na administratore BP. Ugnjedavanje procedura ima jo jednu znaajnu prednost. Procedure
se prave za ciljnu vrstu i verziju SUBP. One se testiraju bez potrebe povezivanja s bilo kakvom aplikacijom. Na taj nain je olakano odravanje i proirivanje
sloenih sistema na nivou podataka.
172
16.6. Tehnologije koje omoguavaju razmenu podataka

izmeu BP i aplikacija
ODBC (Object Database Connectivity)
ODBC veznik se ostvaruje korienjem ODBC driver-a. ODBC driver je
sistemski softverski proizvod specijalne namene. ODBC driver-i su podprogrami koji se sami za sebe ne mogu koristiti. Aplikacije mogu pristupati podacima
u SUBP preko ODBC veznika koji se denie nad specinim ODBC driverom. Za svaku verziju sistema za upravljanje BP i operativnog sistema dizajniraju se zasebni ODBC driver-i. To znai da se, na primer ne moe 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 moe se koristiti na razliitim platformama (Linux, Windows OS).
Slika 16.9. Postojei ODBC veznici u sistemu

173
Proizvoai OS obino 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 administratorske konzole Control Panel-a (slika 16.9).
Tehnologija ODBC-a funkcionie na sledei nain. Najpre se bira odgovarajui ODBC driver. Nakon toga se bira baza podataka s kojom aplikacija treba
da razmenjuje podatke. Pre kreiranja aplikacije potrebnije izvriti 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 oznaavanje 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 korienje.
174
Slika 16.12. Korienje 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 pristupa naziva se Zabeleske, a ID, datum, poruka su polja u tabeli. Komunikacija (pregledanje, dodavanje, uklanjanje i editovanje zapisa) vri se korienjem SQL jezika
specinog za SUBP koji sadri BP ije podatke aplikacija koristi.
ADO (ActiveX Data Objects)
ADO ActiveX Data Objects predstavlja tehnologiju koja omoguava
pristup svemu to moe da poseduje podatke (e-mailovi, Excel tabele, datoteke). ADO dakle poseduje mnogo veu fleksibilnost (u odnosu na vrstu izvora podataka) nego ODBC veznici. ADO tehnologija je dizajnirana da bolje podri savremene zahteve za distribuiranjem razliitih vidova multimedijalnih podataka.
175
ADO sloj predstavlja nadgradnju nad OLE14 radi uproavanja pristupa

podacima. Podacima kao to su video, audio klipovi, ilustracije, mnogobrojni
razliiti formati dokumenata, mogue je prii iz korisnike aplikacije korienjem
tzv. ActiveX komponenti. Postoji nekoliko vrsta komponenti:
1. Automatizacioni serveri (Automation Servers) i kontroleri komponente davaoci (serveri) i potraioci servisa (kontroleri); Primer ovakvog
pristupa su aplikacije mail agenti, koje koriste funkcionalnosti Microsoft Outlook-a; pristup automatizacionim serverima vri se korienjem
IDispatch interfejsa.
2. ActiveX Kontrole kontrole su ekvivalent OLE Controls (datoteke
sa ekstenzijom OCX); one su najee namenjene proirenju funkcionalnosti korisnikih interfejsa, npr. omoguavaju prevlaenje,
premetanje grafikih objekata, tabelarnu prezentaciju podacima iz
BP itd.
3. COM Objekti u Windows operativnim sistemima postoji na stotine ovih objekata; svaki od njih sadri vie specifinih interfejsa kojima se pristupa iz korisnike aplikacije. COM objekti se proizvode
za vrlo razliite namene, pre svega za korisnike interfejse; najee
spominjani su renderovanje 3D grafike i promena izgleda korisnikog interfejsa.
4. ActiveX Dokumenta kreiraju se i edituju u ActiveX serverskim aplikacijama (kao to su MSWord, MSExcel), a prikazuju se u ActiveX kontejnerskim aplikacijama (npr. Internet Explorer);
5. ActiveX Kontejneri to su najsloenije ActiveX komponente koje u
sebe mogu da prihvate automatizacione servere, kontrole i dokumenta.
Korienjem ADO objekata u aplikacijama smanjuje se kompleksnost aplikacije (broj linija koda napisanih radi ostvarivanja neke funkcionalnosti). Time
se smanjuje vreme potrebno za izgradnju aplikacije i poveava produktivnost
programiranja.
14
176
OLE (Object Linking and Embeding) ova tehnologija je prethodnica ActiveX tehnologiji,
i omoguavala je integraciju podataka razliitih formata i iz raznorodnih dokumenata
u jednom dokument kontejneru. Razlika u odnosu na ActiveX je to je omoguavala
pregled ali ne i editovanje podataka iz drugog izvorita.
DAO (Data Access Objects)

DAO predstavlja komponentu koja obezbeuje zajedniki interfejs izmeu
aplikacija i odreenog skladita podataka (ciljnog SUBP). Mesto koje zauzima
DAO u vieslojnoj arhitekturi aplikacija je na granici sloja poslovne logike i sloja
podataka (Slika 16.13).
Slika 16.13. Aplikacije i DAO

DAO omoguava automatizaciju, odnosno potpunu nezavisnost objekata aplikacije od prezentacije podataka u ciljnoj BP. DAO tehnologija izbegava potrebu registrovanja kao to je to sluaj sa ODBC veznicima. Fokusirana
je iskljuivo na BP kao izvore podataka. Bazi podataka preko DAO objekata
pristupa se direktno. DAO objekti u aplikaciji ponaaju se kao klijenti u odnosu na SUBP. Omoguava potpuniju kontrolu i jednostavniji pristup svim entitetima u SUBP.
Slika 16.14. Korienje DAO objekata za unos podataka u tabelu u BP

177
Slika 16.15. Korienje DAO objekata za upit u BP

DAO tehnologija vri obavijanje aplikacionim objektima svih objekata
u SUBP: itav sistem (SUBP), BP, tabele, polja, indeksi, upiti, korisnike grupe,
pojedinani korisniki nalozi itd. Na taj nain izbegava se potreba pristupa nekom
posrednikom entitetu (kao to je to ODBC). Unos podataka u tabelu iziskuje svega 6 linija koda (slika 16.14), dok preuzimanje podataka po zadatom kriterijumu
zahteva nekoliko linija koda vie (slika 16.15).
JDBC (Java Database Connectivity)
U paleti tehnologija koje se koriste za povezivanje aplikacija sa BP izdvajaju se kao posebna grupa Java tehnologije. Ove tehnologije zasnovane su
na specifinim svojstvima Java programskog jezika. Platformska nezavisnost,
orjentisanost prema mrenom programiranju i Interentu, kao i izgradnji distribuiranih informacionih sistema uinilo je Java-u moda najdominantnije korienim jezikom u izgradnji aplikacija u zadnjim godinama prolog
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 raunarsku platformu (mobilni softverski agenti) ili aplikacija za
mobilnu telefoniju.
Dominantna tehnologija za povezivanje Java aplikacija na SUBP je JDBC
(slika 16.16). Postoji velika slinost izmeu ODBC i JDBC konektora. Sutinska
razlika je da JDBC konektor ne treba da se registruje na sistem da bi bio operativan i da se konektor pravi prema ciljnom SUBP. JDBC konektor ne koristi
resurse OS ve resurse Java virtualne maine (JVM15). Isti JDBC konektor koriste
15
178
JVM Java Virtual Machine predstavlja posrednika izmeu platformskog OS i Java

aplikacija
konkurentski razliite java aplikacije. Na tritu se mogu pronai razliiti JDBC

konektori za iste SUBP. Najpouzdanije reenje je korienje konektora koji za
Java-u nudi proizvoa 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 izmeu klijentske i serverske aplikacije (vidi poglavlje 16.3). EJB entiteta predstavlja posrednika izmeu
aplikacije i SUBP.
EJB entiteta su perzistentni (postojani) objekti koji predstavljaju poglede na eljene podatke iz BP. Oni su smeteni u EJB kontejneru (delu serverske
179
aplikacije) i postojani su ak i ako doe 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 nain kao i
Java klase koje ne koriste Eneterprise okruenje.
Slika 16.17. Mesto EJB tehnologije u distribuiranim IS

180
Motivacija za korienje EJB je u mogunostima kombinovanja razliitih

tehnologija (RMI, messaging, itd) i jednostavnijeg naina obezbeivanja boljih
performansi sistema (transakciona podrka, perzistentnost podataka).
Pristup bazama podataka iz aplikacija moe se reiti na veliki broj
razliitih naina. Mnogobrojne tehnologije imaju za cilj da vreme izgradnje
sloenih poslovnih aplikacija to vie skrate, a s druge strane da poboljaju
kvalitet aplikacija u smislu performansi, pouzdanosti, fleksibilnosti i sigurnosti podataka. U jednostavnijim aplikacijama i u radu sa transparentnijim
podacima moe se koristiti pristup podacima iz korisnikog interfejsa. Sloeni
sistemi koji su najee i distribuirani zahtevaju da se podacima pristupa iz
sloja poslovne logike ili pozivanjem ugnjedenih procedura u SUBP. Platformski OS, programski jezik u kome se sistem implementira, korisniki zahtevi u
pogledu funkcionalnosti aplikacije, ograniie dizajnere i programere na izbor
konkretne tehnologije za povezivanje aplikacije sa BP. Svaka od predstavljenih
tehnologija ima razliite prednosti i nedostatke koje implementatori moraju
da razumeju kako bi napravili pravi izbor. Dobar izbor tehnologije predstavlja
osnovu dobrog poetka izgradnje IS.
181
Poglavlje 17
Dodatak 1.
Informacioni sistem kafia
17.1. Korisniki zahtev
Napraviti informacioni sistem koji e pratiti rad kaa. Potrebno je da IS
vodi evidenciju kataloga, narudbenica, zaliha, otpremnica, narudbi, rauna,
dobavljaa, banaka, naloga za uplatu i potvrda o uplati.
Proizvodi se dobijaju od dobavljaa. Funkcija uvoenja novih dobavljaa
treba da omogui uvoenje u evidenciju novih dobavljaa sa kojima ka posluje,
radi kontakata oko nabavke novih kataloga proizvoda i eventualnih nedoumica
ili problema. Preko kataloga se izdaju narudbenice. Na osnovu narudbenica se
dobijaju otpremnice i fakture.
17.2. SSA Strukturna Sistem Analiza

Pre nego to ponemo da projektujemo informacioni sistem za neki
realni sistem potrebno je da uradimo detaljnu analizu tog sistema. U ovom
sluaju kao metod za analizu koristimo Strukturnu sistemsku analizu (SSA)
koja nam slui da relativno sloen realni sistem prikaemo kao skup jednostavnijih podsistema ije funkcionisanje moemo lake da shvatimo, a
samim tim i implementiramo.
Dodatak 1. Informacioni sistem kafia
183
17.2.1. Dijagram konteksta
17.2.2. Prvi nivo dekompozicije
184
17.2.3. Drugi nivo dekompozicije (Nabavka)
17.2.4. Drugi nivo dekompozicije (Prodaja)
185
17.2.5. Drugi nivo dekompozicije (Uplata banci)
17.3. Renik Podataka

Polje
SifraBanke
NazivBanke
Adresa
Telefon
SifraDobavljaca
TelefonDobavljaca
AdresaDobavljaca
ZRDobavljaca
NazivDobavljaca
SifraFakture
SifraDobavljaca
RokPlacanja
186
Domen
AutoNumber
Text
Text
Text
AutoNumber
Text
Text
Text
Text
AutoNumber
Number
Date/Time
Uslov
NotNull
NotNull
NotNull
NotNull
Polje
IznosFakture
DatumFakture
SifraOtpremnice
BrojKataloga
SifraDobavljaca
Datum
SifraNaloga
Primalac
SvrhaUplate
Datum
Vreme
ZRPrimaoca
Domen
Uslov
Number
Date/Time
Number
AutoNumber NotNull
Number
Date/Time
AutoNumber NotNull
Text
Text
Date/Time
Date/Time
Text
Cena
Domen
Number
SifraFakture
SifraArtikla
Number
SifraNarudzbe
AutoNumber NotNull
RedniBroj
AutoNumber NotNull
BrojStola
Number
SifraNarudzbe
Number
SifraNarudzbenice AutoNumber NotNull
SifraArtikla
Number
Datum
Date/Time
RedniBroj
AutoNumber NotNull
Potpisol
Text
SifraNarudzbenice Number
SifraDobavljaca
Number
SifraOtpremnice
Polje
SifraBanke
Domen
Number
SifraFakture
Polje
Uslov
Uslov
NotNull
NotNull
Kolicina
Number
AutoNumber NotNull
Cena
Number
SifraDobavljaca
Number
JedinicaMere
Text
ValutaPlacanja
Text
SifraArtikla
Number
Datum
Date/Time
RedniBroj
AutoNumber NotNull
UkupnoZaPlacanje Number
SifraOtpremnice
Number
NotNull
Potpisol
Text
SifraDobavljaca
Number
NotNull
SifraPotvrde
AutoNumber NotNull
Cena
Number
SifraBanke
Number
Kolicina
Number
BrojZiroRacuna
Text
JedinicaMere
Text
SvrhaPlacanja
Text
SifraArtikla
Number
SifraNaloga
Number
RedniBroj
AutoNumber NotNull
SifraRacuna
AutoNumber NotNull
SifraRacuna
Number
SifraNarudzbe
Number
Cena
Number
Vreme
Date/Time
Kolicina
Number
Datum
Date/Time
SifraArtikla
Number
BrojStola
Number
SifraArtikla
AutoNumber NotNull
UkupnaCena
Number
KolicinaZaliha
Number
RedniBroj
AutoNumber NotNull
NazivArtikla
Text
BrojKataloga
Number
NotNull
VrstaArtikla
Text
SifraDobavljaca
Number
NotNull
OpisArtikla
Text
JedinicaMere
Text
NotNull
NotNull
NotNull
NotNull
NotNull
187
17.4. MOV Model Objekti-Veze

17.4.1. Nabavka
188
17.4.2. Prodaja
17.4.3. Uplata banci
189

eme relacija su sledee:
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, JedinicaMere, 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, UkupnaCena)
STAVKA RACUNA (RedniBroj, SifraNarudzbe, SifraRacuna, Cena,
Kolicina, SifraArtikla)
17.5.3. Uplata banci:

BANKA (SifraBanke, Ime, Adresa, Telefon)
POTVRDA O UPLATI (SifraPotvrde, SifraBanke, BrojZiroRacuna, SvrhaPlacanja, SifraNaloga)
NALOG ZA UPLATU (SifraNaloga, Primalac, SvrhaUplate, Datum, Vreme, ZRPrimaoca, SifraBanke, SifraFakture)
190
191
17.6. Access Tabele
192
193
Poglavlje 18
Dodatak 2.
Servis za odravanje rada
softverskog sistema
Stranka podnosi zahtev za popravku raunara. Na osnovu razgovora ili analize raunara isti se prihvata na popravku. Pri prijemu raunara stranci se izdaje
revers ili potvrda o prijemu.
Vri se popravka raunara (opravka sistema, spaavanje podataka, izrada
Back up-a podataka i td.) Po zavrenoj popravci stranci se izdaje raun koji on
plaa i nakon izvrene uplate izdaje se popravljen raunar.
Takoe servis nabavlja odgovarajui softver i vodi rauna o novim programima koji se izbacuju na trite. Softver se nabavlja od specijalizovanih
dobavljaa.
Razvojno okruenje izabrano za aplikaciju Servis za odravanje Softverskog
Sistema je Access 2003. Korieni su tabele, SQL upit i forme.
Dodatak 2. Servis za odravanje rada softverskog sistema
195
18.2. SSA Strukturna Sistem Analiza

18.2.2. Dekompozicija prvog nivoa
196
18.2.1. Dekompozicija procesa
Dekompozicija procesa 1 prijem raunara na popravku
Dekompozicija procesa 2 nabavka softvera

197
18.3. Renik podataka

Dobavljac<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>
198
18.4. Specifikacija primitivnog procesa

Postoje 2 primitivna procesa:
1. Popravka raunara
2. Nabavka softvera
Proces nabavka softvera se sastoji od sledeih sluajeva korienja
1. Evidentiranje dobavljaa SK1

Naziv: evidentiranje novog dobavljaa
Uesnici: radnik, program
Preduslov: Sistem je ukljuen i radnik je ulogovan pod svojom ifrom
Osnovni scenario SK:
1. Radnik poziva sistem da kreira novog dobavljaa
2. Sistem kreira novog dobavljaa
199
3. Sistem prikazuje radniku novog dobavljaa

4. Radnik unosi podatke o novom dobavljau
5. Radnik poziva sistem da uskladiti podatke
6. Sistem skladiti podatke o novom dobavljau
7. Sistem obavetava radnika da je skladitenje bilo uspeno
Alternativni scenariji: 6.1 Ukoliko sistem ne moe da uskladiti dobavljaa prikazuje poruku radniku
2. Nabavka softvera SK1

Naziv: evidentiranje novog programa
Uesnici: radnik, program
Preduslov: Sistem je ukljuen 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
6. Sistem skladiti podatke o novom programu
Alternativni scenariji: 6.1 Ukoliko sistem ne moe da uskladiti program
prikazuje poruku radniku
200
18.5. Dijagram dekompozicije
201
18.6. Model objekti veze
202

Dobavljac(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 korienja sistema

1. Evidentiranje dobavljaa SK1
1. Radnik poziva sistem da kreira novog dobavljaa
203
2. Sistem kreira novog dobavljaa

3. Sistem prikazuje radniku novog dobavljaa
4. Radnik unosi podatke o novom dobavljau

204
6. Sistem skladiti podatke o novom dobavljau

- Alternativni scenariji: 6.1 Ukoliko sistem ne moe da uskladiti dobavljaa 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
205
4. Radnik unosi podatke o programu

6. Sistem skladiti podatke o novom programu

- Alternativni scenariji: 6.1 Ukoliko sistem ne moe da uskladiti program
prikazuje poruku radniku
206
18.9. Fiziko projektovanje modela

podataka Access tabele
207
18.10. Strukturna ogranienja i pravila integriteta

Update Dobavljac CASCADES SeNabavlja
Delete Dobavljac CASCADES SeNabavlja
Update Racunar CASCADES Komponente

Delete Racunar CASCADES Komponente
208
SELECT Dobavljac.Naziv, Program.Naziv

FROM Program INNER JOIN (Dobavljac INNER JOIN [Se Nabavlja] ON
Dobavljac.[Sifra dobavljaca] = [Se Nabavlja].[Sifra Dobavljaca]) ON Program.[ID
Programa] = [Se Nabavlja].IDPrograma;
209
18.11. Forme za unos podataka
210
211
212
213
Poglavlje 19
Dodatak 3.
Uvoz i distribucija
proizvoda bele tehnike
Firma Singidunum Technic nam se obratila sa zahtevom za izradu i implementaciju sistema za upravljanje bazom podataka vezane za uvoz i distribuciju proizvoda bele tehnike. Uoeno je postojanje funkcija nabavke, prodaje i servisa.
Nabavka prima ponudu stranog dobavljaa, koja sadri spisak artikala i
njihove cene. Po zahtevu, dobavlja alje predraun za odreen broj eljenih artikala, na osnovu kog se pravi narudbenica. Prema raunu koji alje dobavlja vri
se uplata. Uz poiljku naruenih artikala prima se otpremnica, za koju se u odelu
prijema vezuje odgovarajua prijemnica.
Prodaja sastavlja razliite ponude vezane za odreeni broj artikala, koje
alje potencijalnim kupcima. Po prijemu porudbine, kupcu se alje raun, a iz
magacina, prema nalogu, traeni artikli sa otpremnicom. Uplata kupca vri se na
odgovarajui raun u banci.
U sluaju kvara na nekom od artikala, kupac se obraa odeljenju servisa, koji uruuje odgovarajui nalog za rad nekom od ovlaenih servisera. Po
zavrenom radu, serviser uz nalog o zavrenom radu alje i raun na osnovu
kog se vri odgovarajua uplata.
Dodatak 3. Uvoz i distribucija proizvoda bele tehnike
215
19.2. Strukturna sistemska analiza

Spoljni objekti sa svojim tokovima podataka:

Kupac
Ponuda
Porudbina
Raun prodaje
Otpremnica prodaje
Dobavlja
Ponuda dobavljaa
Narudbenica
Uplata dobavljau
Zahtev za predraun
Raun dobavljaa
Predraun
216
Servis
Uplata servisu
Raun servisa
Nalog za rad
Nalog o zavrenom radu
19.2.2. DTP- prvi nivo dekompozicije
IS Singidunum Technic-a se sastoji od procesa:

Nabavka (od dobavljaa)
Prodaja (kupcu)
Servis
217
Na prvom nivou dekompozicije postoje sledea skladita:

Ponude dobavljaa
Dobavljai
Artikli
Kupci
Serviseri
19.2.3. Drugi nivo dekompozicije - nabavka
218
Nabavka se sastoji od sledeih procesa:

Obrada ponude
Naruivanje
Plaanje
Prijem
Na drugom nivou dekompozicije postoje sledea skladita:
Narudbenice
Predrauni
Dobavljai
Ponude dobavljaa
Prijemnice
Rauni
Artikli
19.2.4. Drugi nivo dekompozicije prodaja
Prodaja se sastoji od sledeih procesa:

Obrada porudbine
Otprema
Naplata
Na drugom nivou dekompozicije postoje sledea skladita :
Nalog magacinu
219
Kupci
Artikli
Rauni
Uplata kupca
19.2.5. Drugi nivo dekompozicije servis
Servis se sastoji iz sledeih procesa:

Obrada naloga
Obrada rauna
Na drugom nivou dekompozicije postoje sledea skladita :
Nalozi
Serviseri
Kupci
Artikli
220
19.3. Dijagram dekompozicije
221
19.4. Model objekti-veze

MOV Nabavka - podmodel za tok Ponude i Zahteva za predraun
MOV Nabavka - podmodel za tok za tok Predrauna i Narudbenica
MOV Nabavka - podmodel za tok Rauna i Uplate
222
MOV Nabavka - podmodel za tok Otpremnice i Prijemnice
MOV Prodaja - podmodel za tok Ponude
MOV Prodaja - podmodel za tok Porudbine i Rauna
223
MOV Prodaja - podmodel za tok Otpremnice i Naloga Magacinu
MOV Servis - podmodel za tok Naloga za rad
PMOV Servis - podmodel za tok Naloga o Zavrenom Radu,

Rauna Servisera, Uplate Serviserima
224

Nabavka - 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)
225
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
226
227
19.7. Ekranske forme

Glavni meni:
228
Nabavka:
Artikli:
229
Prodaja:
Servis:
230
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. Anii, 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.
Literatura
231
Renik pojmova
Model procesa vodi projektanta kroz redosled aktivnosti vezanih za projekat i predstavlja ivot ni ciklus projekta. Istorijski posmatrano, neki modeli procesa su statiki, a neki ne dozvoljavaju postojanje kontrolnih taaka. Dva takva
modela procesa su model vodopada i model spirale
Model vodopada. Ovaj model koristi markere kao prelazne i izvrne take.
Kada koristite model vodopada, treba da obavite svaki skup zadataka u okviru
jedne faze pre nego to predete na sledeu fazu. Najbolje je da ovaj model koristite
za projekte kod kojih se zahtevi projekta mogu jasno denisati i koji u budunosti nee biti podloni izmenama. Poto model vodopada ima ksne prelazne
take izmeu faza, veoma lako moete da nadgledate raspored i dodeljujete jasna
zaduenja i odgovornosti.
Model spirale. Ovaj model se zasniva na stalnoj potrebi za usavravanjem
zahteva i procena projekta. Model spirale je ekasan kada se koristi za aplikacije
koje se brzo razvijaju ili za male projekte. Ovaj pristup moe da dovede do uspene saradnje izmeu razvojnog tima i korisnika zato to je korisnik ukljuen u sve
faze tako to obezbeuje povratne informacije i daje odobrenja. Meutim, model
spirale nema ugraene jasne kontrolne take. To za posledicu moe imati haotian razvojni proces.
Microsoft solution framework - MSF model procesa kombinuje najbolje
principe modela vodopada i modela spirale. MSF kombinuje planiranje zasnovano na markerima i predvidljivosti rezultata kod modela vodopada sa Opte prihvaen ciklus razvoja poslovnih reenja sastoji se iz nekoliko faza: prikupljanje
Renik pojmova
233
zahteva, sistemska analiza, projektovanje sistema, kodiranje, testiranje i implementacija. MSF model procesa se sastoji od pet razliitih faza: predvianje; planiranje,
razvoj; stabilizacija, uvoenje.
Faza predvianja Prva faza procesnog modela MSF. Predvianje se moe
denisati kao pravljenje grubog opisa ciljeva i ogranienja projekta. U ovoj fazi
odreujete radni tim i ono to on treba da postigne za naruioca. Svrha faze
predvianja je da napravi zajedniku viziju projekta za sve vane interesne grupe u projektu.
Faza planiranja (eng planning phase) Druga faza procesnog modela MSF,
tokom koje tim odreuje ta e se razvijati i planira kako da napravi poslovno
reenje. Radni tim priprema funkcionalnu specifikaciju, pravi nacrt reenja
i priprema radne planove, procene trokova i rasporede za razne isporuive
rezultate. Za vreme faze planiranja prave se kolekcije modela i dokumenata sa
zahtevima. Ta kolekcija modela i dokumenata ini funkcionalnu specifikaciju
i nacrt reenja. Za vreme faze planiranja poinjete da se radi na funkcionalnoj
specifikaciji reenja. Tokom faze planiranja postoje tri procesa projektovanja:
konceptualno, logiko i fiziko projektovanje. Ova tri procesa se ne odvijaju
paralelno. Njihove poetne i krajnje take su meusobno povezane. Ovi procesi zavise jedan od drugog. Logiko projektovanje zavisi od konceptualnog
projektovanja, a fiziko projektovanje zavisi od logikog projektovanja. Svaka
izmena u konceptualnom dizajnu utie na logiki dizajn, to dalje dovodi do
izmena u fizikom dizajnu.
Konceptualno projektovanja Konceptualno projektovanja je proces
sakupljanja, analize i postavljanja prioriteta problema i reenja sa stanovita
posla i korisnika i pravljenje predstave reenja visokog nivoa. Konceptualno
projektovanje se pojavljuje za vreme faze planiranja. Neki od ciljeva pravljenja konceptualnog dizajna su: razumevanje poslovnog problema koji treba
da se rei, razumevanje poslovnih zahteva i zahteva korisnika i opisivanje
ciljnog budueg stanja posla.
Logiko projektovanje se denie kao proces opisivanja reenja u pogledu
njegove organizacije, strukture i interakcije delova reenja sa stanovita projektnog
tima. Logiko projektovanje: denie sastavne delove reenja, obezbeuje radni
okvir koji sve delove reenja dri zajedno, ilustruje nain na koji se reenje sastavlja i nain na koji stupa u interakciju sa korisnicima i drugim reenjima. Kada
234
Renik pojmova
pravi logiki dizajn, radni tim uzima u obzir sve zahteve posla, korisnika, sistema i
operacija koji utvruju potrebu za bezbednou, voenjem dnevnika, beleenjem
dogaaja, skalabilnou, upravljanjem stanjem, rukovanjem grekama, licenciranjem, globalizacijom, arhitekturom aplikacije i integracijom sa drugim sistemima.
Rezultati logikog projektovanja su: logiki model objekata; dizajn visokog nivoa
za korisniki interfejs; logiki model podataka.
Fiziko projektovanje predstavlja poslednji postupak u okviru faze planiranja u MSF modelu procesa. Projektni tim prelazi na fiziko projektovanje
onda kada se svi lanovi sloe sa tim da imaju dovoljno informacija na osnovu
logikog dizajna da bi mogli da predu na fiziko projektovanje. Tokom fizikog projektovanja, radni tim primenjuje tehnoloka razmatranja i ogranienja
na konceptualni i logiki dizajn. Poto fiziko projektovanje predstavlja nastavak konceptualnog i logikog projektovanja, njegov uspeh zavisi od tanosti
prethodna dva dizajna. Oslanjanje fizikog dizajna na konceptualni i logiki dizajn obezbeuje timu mogunost da zavri fiziki dizajn koji ispunjava
poslovne i korisnike zahteve.
Faza razvoja Trea faza procesnog modela MSF. Za vreme faze razvoja, projektni tim pravi reenje. Ovaj proces ukljuuje pravljenje programskog kda koji
implementira reenja i pravljenje dokumentacije za programskog kd. Pored razvoja programskog kda, radni tim razvija i infrastrukturu reenja. Proces razvoja prolazi kroz nekoliko faza: pokretanje razvojnog ciklusa, pravljenje prototipa aplikacije,
razvijanje komponenata reenja, izgradnja reenja, zavretak faze razvoja.
Faza stabilizacije etvrta faza procesnog modela MSF. Za vreme faze stabilizacije radni tim obavlja integraciju, uitavanje i beta testiranje poslovnog reenja. Pored toga, tim testira scenarija za uvoenje reenja. Tim usmerava panju na
odreivanje problema, postavljanje prioriteta i reavanje problema tako da reenje
moe biti pripremljeno za izdavanje. Za vreme ove faze, reenje prelazi iz stanja
u kome su sve karakteristike zavrene kao to je denisano u funkcionalnoj specikaciji za ovu verziju, u stanje u kome se ispunjavaju denisani nivou kvaliteta.
Pored toga, reenje postaje spremno za uvoenje u posao.
Faza uvoenja Peta faza procesnog modela MSF. Za vreme ove faze, tim
uvodi tehnologiju poslovnog reenja i smeta komponente, stabilizuje uvoenje,
prenosi projekat operativcima i podrci i dobija odobrenje projekta od krajnjeg
kupca. Nakon uvoenja, radni tim vodi pregled projekta i nadzire zadovoljstvo
naruioca projektom.
Renik pojmova
235
Sakupljanje i analiza informacija su postupci koje obavljate u okviru

Microsoft Solutions Framework (MSF) modela procesa. Postoje razliite kategorije informacija koje treba sakupiti, postoje razliiti izvori informacija i razliite
tehnike za njihovo sakupljanje.
Kategorije informacija Organizaciona arhitektura je prikaz projekta dinamikog sistema - u jednom trenutku vremena. Organizaciona arhitektura
posla usklauje 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 klasikovali. Te kategorije su: posao, aplikacije, operacije i tehnologija.
Tehnike za sakupljanje informacija Postoji est osnovnih tehnika koje
mogu da se koriste za sakupljanje informacija: posmatranje iz senke, intervjuisanje; ciljne grupe; ankete; instrukcije korisnika, pravljenje prototipova.
Izvori informacija Postoje razliiti tipovi informacija koje se mogu sakupite o nekom poslu. Te informacije se mogu pronai u razliitim oblicima. Broj i
raznovrsnost izvora informacija zavise od veliine posla. Neki izvori informacija
su: artifakti, sistemi, ljudi.
Analiza informacija Procesi sakupljanja i analize informacija su iterativni. Informacije se najpre sakupljaju a zatim analiziraju. Kod pregleda sakupljenih
informacija, nesumnjivo se otkrivaju dodatna pitanja. Nove informacije pomau
da se nastavi analiza posla. Ovaj oblik saradnje trajae tokom itavog ivotnog ciklusa projekta iako se vei deo sakupljanja i analize informacija odvija na poetku
ivotnog ciklusa.
Dokument nacrta zahteva Kada je radni tim sakupio informacije, jedan
od postupaka u okviru analize je pravljenje dokumenta nacrta zahteva. Ovaj
dokument sadri uvodnu listu zahteva, sastavljenu na osnovu informacija koje
je tim sakupio. Osnovna svrha ovog dokumenta je zapisivanje svih moguih
zahteva, ime se obezbeuje da se dragocene informacije nee izgubiti. Informacije koje sakupite iz razliitih izvora sadre zahteve i elje sa poslovnog i
korisnikog aspekta. Zahtevi ukazuju na ono ta poslovno reenje treba da
radi kako bi ispunili poslovnu ponudu, a to se izvodi iz poslovnog i korisnikog aspekta.
236
Renik pojmova
Sluaj korienja (eng. Use case) Opis interakcija visokog nivoa izmeu
pojedinca i sistema. Sluaj korienja oznaava redosled koraka koje e korisnik
preduzimati u scenariju upotrebe.
Scenario upotrebe (eng. Usage scenario) Oznaava aktivnosti koje obavlja
odreen tip korisnika i obezbeuje dodatne informacije o aktivnostima i sekvencama zadataka koje ine proces.
Interna dokumentacija projektnog tima Nakon sakupljanja informacija, kao deo analize, tim pravi nekoliko internih dokumenata koja se obino
ne dostavljaju kupcima. Ta dokumenta - katalog uesnika; katalog poslovnih
pravila i renik - su aktivna dokumenta i preciznije se deniu tokom ivotnog
ciklusa projekta.
Unied Modeling Language UML je standardni jezik modeliranja koji
koristite za modeliranje softverskih sistema razliite sloenosti. Ti sistemi mogu
biti od velikih zajednikih informacionih sistema do distribuiranih sistema zasnovanih na Web tehnologiji. UML je razvijen da bi korisnicima obezbedio standardni vizuelni jezik modeliranja tako da mogu da razvijaju i razmenjuju znaajne
modele. UML ne zavisi od konkretnih programskih jezika i razvojnih procesa.
UML prikazi UML omoguuje sistemskim inenjerima da naprave standardni nacrt bilo kog sistema. UML obezbeuje nekoliko grakih alata koje
moete da koristite za vizuelno predstavljanje i razumevanje sistema sa razliitih
taaka gledita. Razliiti UML prikazi opisuju nekoliko aspekata softverskog sistema. Prikazi koji se obino koriste su: prikaz korisnika. struktuirani prikaz. prikaz
ponaanja. prikaz implementacije. prikaz okruenja.
UML dijagrami Razliiti UML prikazi sadre dijagrame koji obezbeuju
vie aspekata reenja koje se razvija. Nije potrebno razvijati dijagrame za svaki sistem koji se pravi. Slino tome, ne koriste se svi dijagram za modeliranje
sistema. Pomou sledeih UML dijagrama mogu se opisati razliiti prikazi sistema: dijagrami klasa. dijagrami objekata. dijagrami sluajeva korienja. dijagrami komponenata. dijagrami uvoenja. dijagrami saradnje. dijagrami toka i
dijagrami stanja.
DBMS Baza podataka se denie kao skup podataka koji su organizovani
na odreen nain. DBMS Database Management System je sistem koji upravlja
bazama podataka.
Renik pojmova
237
SQL je skraenica od Structured Query Language. To je najire korieni

programski jezik za komunikaciju sa relacionim bazama podataka. Pomou ovog
programskog jezika mogu da se ureuju, kreiraju, ili briu baze podataka ili podaci u njima. SQL je takoe i ANSI/ISO standard.
Sloj predstavljanja je deo poslovne aplikacije koji obezbeuje mehanizam
za komunikaciju izmeu korisnika i sloja poslovnog servisa sistema. Elementi sloja predstavljanja su komponente korisnikog interfejsa, kao na primer Windows
ili Web interfejs.
Sloj podataka poslovnog reenja se sastoji od skladita podataka i servisa
podataka. Skladite podataka najee je baza podataka u kojoj su podaci organizovani i pohranjeni.
238
Renik pojmova
Odlukom Senata Univerziteta Singidunum, Beogrd, broj 636/08 od 12.06.2008,

ovaj udbenik je odobren kao osnovno nastavno sredstvo na studijskim programima koji
se realizuju na integrisanim studijama Univerziteta Singidunum.
CIP -
,
004.65(075.8)
, , 1962Uvod 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 i
menadment. - Tira 870. - Renik pojmova:
str. 233-238. - Bibliograja: str. 231.
ISBN 978-86-7912-252-0
1. , , 1967- []
a)
COBISS.SR-ID 176515596
2010.
Sva prava zadrana. Ni jedan deo ove publikacije ne moe biti reprodukovan u bilo kom
vidu i putem bilo kog medija, u delovima ili celini bez prethodne pismene saglasnosti
izdavaa.

US - Uvod U Baze Podataka

Uploaded by

Copyright:

Available Formats

You might also like

US - Uvod U Baze Podataka

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

US - Uvod U Baze Podataka

Uploaded by

Copyright:

Available Formats

UNIVERZITET SINGIDUNUM

Prof. dr Mladen Veinovi

UVOD U BAZE PODATAKA

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

11.3. Objekti u relacionom modelu podataka . . . . . . . . . . . . . . . . . . 95

13.6. SELECT upiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

15. Transakcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

18. Dodatak 2. Servis za odravanje rada softverskog sistema . . .195

relacionim bazama podataka. Na primerima relacija loe strukture diskutovani su

se korienjem baza podataka moe imati bolja podrka za odluivanje, ime

ili distribuirana na vie meusobno udaljenih raunara. Pored podataka koji su

Osnovni koncepti i definicije

Prikazane injenice po deniciji predstavljaju podatke, ali bi se veina

Osnovni koncepti i definicije

podataka i njihovim ureivanjem, prepoznajemo spisak upisanih studenata. Na

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

Slika 2.2. Graki prikaz podataka iz BP - informacija o upisu

Podaci obraeni tako da dobijaju znaenje ine informaciju. Informacija koja

Slika 2.3. Obradom prikupljenih podataka nastaje informacija

2.3. Metapodaci - podaci o podacima (metadata)

Duina Min Max Opis

Jedinstven matini broj Lina karta

Ime i prezime studenta Lina karta

Metapodaci opisuju svojstva podatka ali se nalaze odvojeno od tog podatka.

Osnovni koncepti i definicije

2.4. Sistem za upravljanje bazama podataka

Slika 2.3. DBMS je interfejs izmeu (aplikacija) korisnika i

Osnovni koncepti i definicije

Klasian sistem zasnovan na

Slika 3.1. Klasian sistem obrade podataka zasnovan na

Slika 3.2. Klasina obrada podataka zasnovana na sistemu datoteka

Klasian sistem zasnovan na datotekama

3.1. Nedostaci sistema zasnovanog na datotekama

Zavisnost izmeu programa i podataka

Ogranienost deljenja podataka

ma porudbina i plata. Menaderi su imali velike probleme pri sastavljanju

Dugo vreme za razvoj

Teko odravanje programa

Klasian sistem zasnovan na datotekama

Slika 4.1. Blok ema informacionog sistema zasnovanog na bazama podataka

4.1. Prednosti pristupa zasnovanog na bazama podataka

Nezavisnost izmeu programa i podataka

Minimalna redudansa podataka

Poboljana konzistentnost podataka

Poboljana razmena podataka

Pristup zasnovan na bazama podataka

Poveana produktivnost u razvoju aplikacija

Smanjena potreba za odravanjem programa

4.2. Trokovi i rizici pristupa

Novo, obueno osoblje

Trokovi i sloenost instaliranja, upravljanja i rada sistema sa bazama

Trokovi prilagoavanja (konvertovanja) podataka

Potreba za izradom sigurnosnih kopija i oporavkom podataka (backup)

Pristup zasnovan na bazama podataka

4.3. Tipino okruenje baze podataka

Projektanti sistema Osobe kao to su sistemski analitiari i programeri

Slika 4.2. Komponente okruenja BP

Pristup zasnovan na bazama podataka