US - Uvod U Baze Podataka

UNIVERZITET SINGIDUNUM
Prof. dr Mladen Veinovi

Doc. dr Goran imi
UVOD U
BAZE PODTAKA
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
Sadraj III
pogl av l j e 12
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
IV Sadraj
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
Sadraj V
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 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.4. Razlika - / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.5. Presek - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
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
VI 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
Sadraj VII
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 sofverske 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
VIII Sadraj
18. Dodatak 2. Servis za odravanje rada sofverskog 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
Predgovor 1
pogl av l j e 12
Predgovor
Knjiga Uvod u baze podataka je namenjena studentima Univerziteta Sin-
gidunum 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 izlagan-
ja materije autori se nisu vezivali za konkretan sofverski 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. Domi-
nantno je razmatran relacioni model podataka koji jeste osnova za najvei broj
poslovnih aplikacija.
Knjiga je podeljena u nekoliko delova. Na poetku se iznose osnovni kon-
cepti 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 upra-
vljanje bazama podataka. U nastavku se razmatra modelovanje i uvode razliiti
modeli podataka, onako kako su se istorijski pojavljivali. Baze podataka ne posto-
je same za sebe. One su osnova informacionih sistema, kako velikih tako i malih
organizacija, a projektuju se sa ciljem dobijanja pravovremenih informacija za
donoenje odluka. Zbog toga je posebna panja posveena strukturnoj sistemskoj
analizi, kao poetnom koraku u projektovanju baza podataka. Detaljno je razmo-
tren relacioni model podataka, a u okviru njega posebna panja je posveena inte-
gritetskim komponentama, koje omoguavaju odravanje konzistentnosti jedne
baze podataka. U nastavku je ukratko razmatrana relaciona algebra kao osno-
va za upitne jezike, a zatim su prikazane mogunosti ANSI SQL jezika za rad sa
2 Predgovor
relacionim bazama podataka. Na primerima relacija loe strukture diskutovani su
karakteristini problemi koji se odnose na anomalije auriranja, a zatim je obja-
njen 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 inenjeri-
ma i ekonomistima za razvoj sopstvenih aplikacija. Zahvaljujemo se svim studen-
tima Univerziteta Singidunum koji su kroz izradu seminarskih radova doprineli
da ovaj tekst bude bogat konkretnim primerima.
Autori su se potrudili da izlaganje bude to jasnije, da ne opterete itaoca
kompleksnim matematikim aparatom niti konkretnim sofverskim 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 Autori
Uvod 3
Pogl av l j e 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 telefo-
ni 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 iskoris-
titi kako bi se saznalo koji kupci kupuju koje proizvode, to se koristi kao osno-
va 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
4 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 korisni-
cima 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 odrava-
ju 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 informa-
cije. 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 osnov-
nih informacija iz odgovarajue baze podataka se mogu dobiti i posebne infor-
macije. Na primeru telefonskog imenika mogu se izlistati podaci za sve osobe po
imenu npr. Marko, mogu se izlistati sve osobe kojima telefonski broj 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 tro-
kovi 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, organizo-
vanih u bajtove, a sa vie bajtova u odgovarajuem formatu zapisuju se vrednosti
pojedinih podataka i predstavljaju jedno polje baze podataka. Niz polja se organi-
zuje 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
Uvod 5
ili distribuirana na vie meusobno udaljenih raunara. Pored podataka koji su
zapisani u bazi podataka, postoje i posebni podaci kojima se opisuju pojedina-
ne 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 konguracio-
ni podaci odgovarajue baze (self-describing).
NEKADA
DANAS
Slika 1.1. Baze podataka nekada i danas
Osnovni koncepti i defnicije 7
Pogl av l j e 2.
Osnovni koncepti i defnicije
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 hilja-
du i vie ljudi moe da ima veoma veliku bazu podataka od nekoliko terabajta
podataka (jedan terabajt = 10
12
bajtova) na mainframe kompjuteru na kome se
nalazi aplikacija za podrku odluivanju. Veoma velika skladita podataka ima-
ju vie od petabajta podataka (1 petabajt = 10
15
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 odree-
no vreme, koja se odrava i koju koristi vie korisnika ili programa.
2.1. Podatak
Istorijski, pod terminom podatak se podrazumeva injenica o nekom pred-
metu 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 podata-
ka 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 zvu-
ni ili video zapis poslednjeg razgovora sa kupcem. Ova vrsta podatka se naziva
8 Osnovni koncepti i defnicije
nestruktuirani podatak ili multimedijalni podatak. Multimedijalni podaci se naj-
ee 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 multi-
medijalnim 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, ter-
min podatak se odnosi na ono to je u bazi podatak. Dakle, podatak je sirova
injenica - neobraena informacija. Raunar vri obradu podataka, prema zada-
tom 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 sinoni-
mi. 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
podataka i njihovim ureivanjem, prepoznajemo spisak upisanih studenata. Na
ovaj nain se dolazi do informacije koja je korisna npr. upravi fakulteta, profeso-
rima, 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 informa-
cija se moe iskoristiti kao osnova za odluivanje o dodavanju novih predavan-
ja ili o zapoljavanju novog nastavnog kadra. Moderne baze podataka vrlo esto
sadre i podatke i informacije. Podaci se esto obrauju i uvaju u obraenoj for-
mi 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 dozvol-
jene 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 Izvor
Ime Text 30 Ime i prezime studenta Lina karta
JMBG Integer 1 Jedinstven matini broj Lina karta
Smer CHAR 3 Smer na fakultetu Studentska sluba
GodUpisa Number 2001 Godina upisa Studentska sluba
Metapodaci opisuju svojstva podatka ali se nalaze odvojeno od tog podatka.
Metapodaci iz tabele1.1 ne prikazuju ni jedan podatak. Oni omoguavaju dizajne-
rima i korisnicima baza podataka da razumeju koji podaci postoje u bazi, ta oni
znae, i koja je razlika izmeu podataka koji na prvi pogled izgledaju isto. Upra-
vljanje 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 sofverski sistem koji se koristi za kreiranje, odravanje i manipuli-
sanje podacima, kao i za kontrolu prava pristupa bazi podataka. DBMS omo-
guava krajnjim korisnicima i programerima da dele podatke, tj. omogua-
va 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, uspos-
tavlja kontrolu konkurentnosti i vri oporavak baze podataka. Programeri apli-
kacija za rad sa bazama podataka ne moraju da poznaju detalje o nainu zapisa
baze podataka na disku, ne moraju da formuliu algoritme za ekasan 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 pro-
grama, 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 sinhroniza-
ciju njihovog rada.
Takoe, DBMS ima funkciju da sprei tetne posledice (naruen integri-
tet 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.
Termini baza podataka i upravljanje bazom podataka se ponekad mea-
ju. 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 sofverom (programom). DBMS
upravlja strukturom baze podataka: denie objekte baze, njihova svojstva (atri-
bute), 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 upra-
vljanje podacima uspenijim i delotvornijim Uobiajeno je da kada se govori o
sofveru za baze podataka, onda se misli upravo na DBMS. DBMS upravlja inter-
akcijom 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
Klasian sistem zasnovan na datotekama 13
Pogl av l j e 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 koris-
ti 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
14 Klasian sistem zasnovan na datotekama
Da bi objasnili osnovne karakteristike sistema zasnovanog na datoteka-
ma, posmatrajmo jednu fabriku sa odreenim proizvodnim programom. Pret-
postavimo 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 raunar-
ski 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 sis-
tema porudbine, naplate i plate. Na slici se takoe vide osnovne datoteke veza-
ne 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 podata-
ka koji se zasniva na datotekama.
Slika 3.2. Klasina obrada podataka zasnovana na sistemu datoteka
Klasian sistem zasnovan na datotekama 15
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 ukrat-
ko su opisane u nastavku.
Zavisnost izmeu programa i podataka
Opisi datoteka se uvaju u okviru svakog programa koji pristupa toj dato-
teci. 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 pro-
cesu 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 pro-
grama 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 auri-
ranju. Neplanirana redudansa podataka moe da dovede do gubitka podata-
ka. 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 rauno-
vodstvu imaju pristup samo procesu naplate, dok nemaju pristup procesi-
16 Klasian sistem zasnovan na datotekama
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 pro-
gramiranja 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 poslov-
nim 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, narav-
no, ostaje jako malo prostora za razvoj novih aplikacija.
Vano je znati da veina mana klasinog sistema zasnovanog na datote-
kama, koje smo u prethodnom delu teksta pominjali, mogu isto tako biti ogra-
nienja za bazu podataka, pogotovo ako se ne promeni pristup razvoju baze
podataka. Na primer, ukoliko preduzee razvije nekoliko zasebnih baza podata-
ka (recimo, za svaku radnu jedinicu ili proces po jednu bazu) sa malom ili nika-
kvom 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.
Pristup zasnovan na bazama podataka 17
Pogl av l j e 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 pro-
mena naina razmiljanja za veinu organizacija je veoma teka.
Da bi objasnili pristup zasnovan na bazama podataka posmatrajmo pre-
thodno 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, pristu-
paju i auriraju integrisanim podacima.
Slika 4.1. Blok ema informacionog sistema zasnovanog na bazama podataka
18 Pristup zasnovan na bazama podataka
4.1. Prednosti pristupa zasnovanog na bazama podataka
Pristup zasnovan na bazama podataka ima mnogo potencionalnih pred-
nosti u odnosu na pristup zasnovan na datotekama. Te potencionalne prednosti
su sledee:
Nezavisnost izmeu programa i podataka
Odvajanje metapodataka od aplikacija koje koriste podatke naziva se neza-
visnost podataka. Ova osobina kod baza podataka dozvoljava promenu i
prenos podataka organizacije na druge 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 ponavlja-
ni) sada integriu u jedinstvenu logiku strukturu. Svaki podatak se nala-
zi 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 perfor-
manse 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 kra-
ju, 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 raz-
vijaju znatno bre nego kod klasinih sistema sa datotekama:
1. Pretpostavljajui da su baza podataka i sve propratne aplikacije ve napra-
vljene 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 vrs-
te podataka se dodaju, formati podataka se menjaju, i tako dalje. Poznat
primer ovoga problema je ulazak u 2000-tu godinu, kada se sa uobiaje-
nog 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, prome-
na 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 gra-
nica, moemo da promenimo jednu od stavki, format podataka ili aplika-
tivni program, a da ne moramo da promenimo drugu stavku. Kao rezultat
ovoga, javlja se smanjenje potreba za 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 bro-
ja organizacija bilo je razliitih problema kod ostvarenja i iskorienja tih pred-
nosti. Na primer, postizanje nezavisnosti podataka (i stoga, smanjene potrebe
za odravanjem programa) se pokazalo kao teko ostvarivo zbog ogranienja
starijih modela baza podataka i sofvera za upravljanje bazama podataka. Na sre-
u, relacioni modeli (kao i noviji objektno-orjentisani modeli) nemaju ovih pro-
blema. Drugi razlog za neuspeh da se iskoriste ove prednosti, je loe planiranje
i implementacija baza podataka ak ni najbolji sofver za upravljanje bazama
podataka ne moe da prevazie ovakve manjkavosti. Pristup zasnovan na baza-
ma podataka sadri neke dodatne trokove i rizike koji se moraju reavati kada
se sistem pone primenjivati.
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, implementi-
ranje 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 obu-
eno 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
sofver 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
sofvera. Takoe se moe pojaviti potreba za dodatnim i skupljim sofverom
za baze podataka radi vee sigurnosti podataka.
Trokovi prilagoavanja (konvertovanja) podataka
Termin nasleeni sistemi se uglavnom koristi kada se govori o starijim apli-
kacijama 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 dana njem
okruenju, gde postoje raznovrsni bezbednosni rizici, reavanje ovog
problema je od izuzetne vanosti. Moderan sistem za upravljanje baza-
ma 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 vlasni-
tvom podataka, kao i utvrenu osobu ili osobe odgovorne za odravanje
podataka. Iskustvo je pokazalo da nesuglasice u pogledu denicija podata-
ka, 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 adminis-
trator baze podataka kao i smislen pristup razvoju baza podataka. Ukoli-
ko 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 napra-
vljena 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 sis-
temskih komponenti.
3. DBMS Sistem za upravljanje bazama podataka (SUBP). Sofverski 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.
6. 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.
7. Korisniki interfejs Jezici, meniji, i itd. pomou kojih korisnici koriste
razliite komponente sistema, kao to su CASE alati, aplikativni programi,
DBMS i metapodaci.
8. Computer-aided sofver engineering (CASE) alati Alati koji se koriste za
dizajniranje baza podataka i aplikativnih programa.
9. Krajnji korisnici Osobe koje dodaju, briu i modikuju/auriraju podat-
ke u bazi podataka i koje zahtevaju ili primaju podatke iz njih. Svaka inter-
akcija izmeu korisnika i baze podataka deava se preko DBMS-a.
Slika 4.2. Komponente okruenja BP
Sa unapreenjem softvera, korisniki interfejs postaje sve laki za upo-
trebu. Primeri za ovakav napredak su sistemi zasnovani na menijima, siste-
mi sa mogunou pristupa Internetu, i sistemi koji prepoznaju govor (pri-
hvataju 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.
Primene baza podataka 25
Pogl av l j e 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 ure-
aja 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. Uzmi-
mo 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 pro-
stora, 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.
26 Primene baza podataka
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 ura-
diti 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 korisni-
ka izuzetno mala.
5.2. Baze podataka za radne grupe
Radnu grupu ini relativno mali broj ljudi koji sarauju na jednom pro-
jektu 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 pod-
rku zajednikog rada jedne takve grupe. Uzmimo za primer, radnu grupu koja
pravi i standardne i programe po porudbini, koji se prodaju sofverskim kom-
panijama 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 razmen-
juju 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 (privile-
gije), 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, raz-
mena 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.
5.3. Baze podataka odeljenja
Odeljenje je funkcionalna radna jedinica u okviru organizacije. Tipini pri-
meri odeljenja su: kadrovsko, marketing, proizvodnja, raunovodstvo i sl. Odel-
jenje 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 pose-
duju 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?
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 kon-
zistentnosti 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 ode-
ljenja. Ova vrsta baza podataka je namenjena da podri sve procese organiza-
cije i proces donoenja odluka. Vano je istai da jedna organizacija moe ima-
ti 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 potre-
ba 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
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 mate-
rijala 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 dobavljai-
ma, i podnoenje izvetaja raznim agencijama zahteva sakupljene svih prethodnih
podataka i informacija. Da bi se zadovoljile ove potrebe, organizacija koristi skla-
dite podataka koje se odrava i nalazi u seditu organizacije. Podaci koji se nalaze
u skladitu podataka su preuzeti (i potom sumirani) iz pojedinanih baza podata-
ka svakog medicinskog centra. Ovaj proces preuzimanja podataka se odvija peri-
odino 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 pove-
zuje 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 tehno-
logiji, 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, speci-
kacije 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 zapo-
slenih 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
eljenog proizvoda ima u skladitu. Tada radnici u maloprodajnim objekti-
ma 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, nebit-
no koje platforme je dovelo i do promena u okruenju baza podataka. Prihva-
tanje 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 unapredi-
le informisanje i usluge koje su pruale svojim klijentima, i koje su zaobile
tipine tokove marketinga i distribucije proizvoda. Na primer, kupci konguri-
u i poruuju svoj PC raunar direktno od proizvoaa raunara. Informacije o
upranjenim mestima i aktivnostima organizacije se mogu dobiti preko Interne-
ta za veinu organizacija.
Svaka od ovih radnji zahteva podrku baze podataka. Lak pristup Interne-
tu svih vrsta platformi omoguava kompanijama da reorganizuju svoje poslove
i razviju bre aplikacije i to po manjim trokovima. Standardni interfejsi omo-
guavaju 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 podata-
ka 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, naviga-
cija 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
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 raz-
mene podataka (EDI- eletronic data interchange). Mnoge kompanije i dalje koriste
EDI sistem za obavljanje B2B poslovanja. Neke kompanije, uglavnom nove ili one
koje nisu imale EDI sistem, koriste extranet za obavljanje B2B razmena podataka
i informacija. Extranet koristi Internet tehnologiju, 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 meusob-
ni dogovor o pristupu podacima i informacijama jednih drugima. Obino, pre-
thodno 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 informacija-
ma u okviru organizacije. Po izgledu ne postoji razlika izmeu intranet i Inter-
net 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.
Istorija razvoja baza podataka 33
Pogl av l j e 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 obezbe-
dila 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 statis-
tikom birou SAD. Tako je popis stanovnitva iz 1890. godine bio prva automati-
zovana 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
34 Istorija razvoja baza podataka
Nakon Drugog svetskog rata, u kompanijama i vladinim institucijama poe-
li 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 nasta-
vile 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 uve-
deni u ovoj deceniji, i korieni su najpre samo kod velikih i sloenih projeka-
ta, 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 upra-
vljanje podacima su uvedeni, velikim delom zbog potrebe za sistemom koji
e moi da upravlja sloenim strukturama podataka, kao to su rauni fabrika
pri nabavci sirovina, kojima je bilo izuzetno teko upravljati preko konvenci-
onalnih metoda. Ovi modeli se i sutinski smatraju prvom generacijom siste-
ma za upravljanje bazom podataka. Oba pristupa su se iroko primenjivala,
zapravo, mnogi od tih sistema su u upotrebi i danas. Pa ipak, imali su nekoliko
velikih nedostataka:
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 smat-
ra 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 obe-
zbedio 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 koris-
nikog interfejsa (GUI).
1990te
Ove godine se oznaavaju kao nova raunarska era, najpre na nivou
raunarske komunikacije na relaciji klijent/server, a potom sa stvaranjem skla-
dita 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
36 Istorija razvoja baza podataka
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 upra-
vljaju 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:
1. Mogunost upravljanja sve sloenijim tipovima podataka. Ovi tipovi uklju-
uju i multidimenzionalne podatke, koji su ve dobili na vanosti u aplika-
cijama skladitenja podataka.
2. Nastavak razvoja univerzalnih servera. Zasnovani na sistemu tree genera-
cije DBMs-a, to su serveri koji mogu da upravljaju irokom lepezom raznih
tipova podataka, tako da budu transparentni svim korisnicima. Bie naroi-
to 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 kak-
vu vrstu podatka eli, umesto kako da doe do njega. Na primer, korisnik
moe da skenira fotograju i da trai od kompjutera pretragu, kako bi pro-
naao istu takvu, ili njoj slinu.
5. Baza podataka i druge tehnologije, poput vetake inteligencije i televizije,
kao informacionog servisa, olakae pristup podacima neobuenim koris-
nicima. 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 pobolja-
ne 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.
Modelovanje 39
Pogl av l j e 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 opisa-
ti 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 podru-
je primene. Modeli su ovekovo sredstvo pojednostavljivanja problema i njego-
vo posmatranje samo sa stanovita bitnih za ciljeve analize. Objekt posmatran-
ja (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 pro-
izvodnje, broj sedita i sl. nisu bitni (mogu se zanemariti ) za takav postupak. o-
vek, 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 infor-
macije 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
40 Modelovanje
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 podata-
ka. Podaci su zato apstrakcija realnosti, tj. sredstva za kodiranje osobina objekata
iz realnog sveta. Modelovane, kao postupak kojim se realni svet svodi na odreeni
broj podataka, predstavlja kompleksan posao i sastoji se iz vie koraka:
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 dodelju-
je se ime.
Klasikacija. Nehomogeni skup objekata i odnosa se svrstava u homogene
klase i tipove objekata. Klasikacija uvek zavisi od podruja primene.
Modelovanje 41
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 sis-
tema, tj. predstavljaju statiki opis stanja sistema. Strukturu modela ine objekti,
njihova svojstva, veze izmeu objekata i njihovih svojstava. Operacije nad poda-
cima 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 nedopu-
tenih stanja realnog sistema i u svojoj prirodi deo su strukture modela podataka.
Ponekad se ne posmatraju kao odvojene komponenta, nego kao deo strukture
modela podataka.
7.2. Entiteti
Modelima podataka nastoji se preslikati realan sistem. Realan sistem sastoji
se od objekata iz realnog sveta i njihovih veza izmeu kojih se uspostavljaju razli-
iti 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 raz-
miljamo. Entitet je realan ako ziki, stvarno postoji. Najoptije se moe tvrditi
da su granice entiteta u modelu podataka odreene ljudskim pogledom i nai-
nom razmiljanja.
Svaki entitet uoen u realnom sistemu ima svoje osobine koje ga ine
sloenim i njihove vrednosti omoguavaju razlikovanje entiteta. Svojstvo enti-
teta ukljuuje dva elementa - atribut i vrednost atributa (npr. entitet Student
ima atribute: Ime, Prezime, Broj indeksa, Adresu, Telefon i sl. i vrednosti Marko,
42 Modelovanje
Markovi, 123/03, Danijelova, 15, 011/376-543 respektivno). Svaki put kada se
promeni vrednost atributa, potrebno je promenu evidentirati, tj. 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 odreu-
je primerak entiteta. Na primer, za entitet Auto, primarni klju je atribut regis-
tarski 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 posmat-
ranom sistemu studiranja na jednom fakultetu. Istraimo jedan skup odnosa iz-
meu 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.
Modelovanje 43
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 analizira-
ju tipovi odnosa koji se uspostavljaju izmeu objekata. Odnosi izmeu objeka-
ta 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 de-
kan 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 sku-
pa X moe se preslikati na najvie jedan element skupa Y. Istovremeno jedan ele-
ment 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.
44 Modelovanje
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
Modelovanje 45
7.4. Troslojna arhitektura baze podataka
Osnovni koncept baze podataka je ideja o skupu injenica ili delova znan-
ja. 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 informa-
cionog sistema jednog fakulteta, studenti polau pojedine ispite, neke ponita-
vaju 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 neko-
liko 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 pitan-
je 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 pro-
jektante informacionih sistema i programere, nego i za krajnje korisnike rezul-
tata takvih obrada. Oni nisu samo skup povremenih korisnika baza podataka,
kao to se to 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 pri-
kazan je na slici 7.5. Na bazi tog modela razvijeni su sistemi za upravljanje bazama
podataka koji imaju troslojnu arhitekturu ili varijantu te arhitekture. Aplikativni
programi komuniciraju s bazom podataka preko odgovarajueg eksternog mode-
la. 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 krei-
ranja modela podataka. Jedan od ciljeva modela podataka je oblikovanje podata-
ka za sadanje i budue aplikacije. Moe se rei da konceptualni nivo ine sve rela-
cione eme modela podataka, sve relacije i ogranienja. Spoljanji nivoi (modeli A,
46 Modelovanje
B i C) formiraju se na temelju konceptualnog nivoa i predstavljaju samo pogled
(VIEW) prema potrebama pojedinih korisnika.
Slika 7.5. Troslojna arhitektura baze podataka
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.
Modeli baza podataka 47
Pogl av l j e 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 vo-
rita 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.
48 Modeli baza podataka
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 nasled-
nik 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 poka-
zivaa 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 doda-
ti 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 jed-
noj 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 infor-
macije budu razliite u dva zapisa, to vodi do konfuzije.
Hijerarhijski model se vie ne koristi kao osnova za trenutne komercijal-
ne 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 sav-
remenikom 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 pokazi-
vaima 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 kom-
panijama. Predstavlja unapreenje hijerarhijskog modela, ali je kompleksan i
teak za upotrebu. Pored toga, teko ga je podrati matematikim aparatom, to
onemoguava kasnije ekasno programiranje.
8.3. Relacioni model
Kao i mnoge druge tehnologije u raunarskoj industriji, koreni relacionih
baza podataka potiu iz IBM-a i njihovog istraivanja automatizovanja kancela-
rijskih 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 gru-
pe 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 podata-
ka, 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:
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 jed-
nu knjigu, a jedna knjiga moe biti kod vie studenata. Neka je trenutna situacija
iz realnog sveta prikazana na sledeoj slici:
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
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, izvre-
no 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 nikak-
vu razliku. Svaka tabela se identikuje jedinstvenim imenom koje baza podataka
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 razli-
ito 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. Umes-
to 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 sofver 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, redo-
vi 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 rezul-
tat, 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 popu-
larnim 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 pojavl-
jivati. 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 relacio-
nom modelu na odreenim tipovima podataka. Tipovi podataka koji se mogu
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 orijen-
tisan model karakterie bogatstvo tipova podataka tip moe biti i drugi objekat.
Direktna veza izmeu objekata u aplikaciji i objekata u BP rezultuje boljim per-
formansama baze podataka.
Posmatrajmo primer u kome se vodi evidencija o Studentima sa svojst-
vima: Broj indeksa, Ime, Prezime, Fakultet i Tip automobila koji student pose-
duje. Dalje vodi se evidencija o Automobilima sa svojstvima Naziv automobila,
Registarski broj, Boja, 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
kao stalni objekt, a ne kao red u tabeli. Ovo sistem ini ekasnijim u smislu pro-
stora potrebnog za smetanje i uvanje podataka i osigurava da korisnik manipu-
lie 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 sofvera izraenog od strane treeg dobavljaa, korisni-
ci objektno orjentisanih sistema za upravljanje bazama podataka ili moraju da
narue dodatni sofver od originalnog programera ili da ga razviju u saradnji sa
drugim rmama koje koriste isti sistem.
Strukturna sistemska analiza (SSA) 57
Pogl av l j e 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 podata-
ka, renici podataka, specikacija procesa, dijagrami objekti-veze;
Razdvajanje zikog i logikog modela - ziki model je najee foku-
siran 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;
58 Strukturna sistemska analiza (SSA)
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 kon-
kretnih korisnika. Na taj nain proces razvoja nije zavren kada se informacioni
sistem uvede u upotrebu, ve se nastavlja dodavanjem novih sofverskih 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 pro-
ces 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 eksi-
bilnije ukljuuje SSA u proces razvoja poslovno informacionog sistema.
Slika 9.2. Faze ivotnog ciklusa razvoja sistema
SSA se realizuje po fazama, i dobro denisanoj metodologiji. Sutinski, sis-
tem 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),
9.1. Funkcionalna dekompozicija
Dijagrami funkcionalne dekompozicije se koriste u odreivanju osnovnih
sistemskih funkcija i njihovom dekomponovanju. Ove funkcije obino odgovara-
ju 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 funk-
cije organizacije. Na prethodnoj slici predstavljen je dijagram osnovnih poslovnih
funkcija jedne spoljno-trgovinske organizacije. U vrhu dijagrama obavezno se
predstavlja naziv IS koji se analizira. Slino hijerarhijskim organizacionim dija-
gramima 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 dekompo-
nuju. Zavretak funkcionalne dekompozicije je kada se dobiju elementarne sek-
vencijalne funkcije (primitive). Primitivne funkcije su one koje se dalje mogu
samo dekomponovati na konkretne naredbe u ciljnom programskom jeziku, ili u
pseudo kodu. Na slici 9.4 predstavljen je primer dekomponovanja poslovne funk-
cije prodaja. Poto se razlikuje proces veleprodaje (rad sa pravnim licima, ugo-
varanje, veleprodajne cene, rabat, naruivanje, dostavljanje, transakcije iskljuivo
preko iro-rauna u bankama) od maloprodaje (rad sa zikim licima, gotovinsko
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 rau-
na kupcu (3.2.1) i prijem uplate kupca (3.2.2). Moe se uoiti da su funkcije gene-
risanje 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 poslov-
nih 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.
Slika 9.5. Primer identikovanja istih funkcija u funk.dekompoziciji
Na primer (Slika 9.5), organizacije (trgovine) koje se bave prodajom robus-
ne 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 (nad-
funkcije) 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 ana-
lize. DTP se sastoje od etiri vrste elemenata (Slika 9.6):
Interfejsi
Procesi
Tokovi podataka
Skladita podataka
Slika 9.6. Struktura DTP
Interfejsi predstavljaju entitete (objekte) iz realnog sveta koji okruuje sis-
tem. 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 pravougao-
nikom 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. Iz-
dava 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.
U toku procesa dekomponovanja, radi preglednosti dijagrama, jedan inter-
fejs 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, proiz-
vodnja, 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 iden-
tino 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 dekom-
ponovanja predstavljeni su osnovni poslovni procesi. Ovi procesi se dekomponu-
ju od 1. nivoa dekompozicije. Proces nabavka se dekomponuje na 3 podprocesa:
obrada kataloga dobavljaa, naruivanje i prijem robe. To znai da se osnovni pro-
ces nabavka vie ne pojavljuje od 1. nivoa dekompozicije, ve samo njegovi pod-
procesi. Na drugom nivou demonstrirana je dekompozicija podprocesa prijem
robe. Ovaj podproces se dekomponuje na tri nova, koja opisuju ta sistem radi po
prijemu robe. To 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 proce-
sa. Ne sme se zaboraviti da DTP treba da u potpunosti odgovaraju dijagramima
funkcionalne dekompozicije. Analogno funkcionalnoj dekompoziciji, poslovni
procesi se dekomponuju do nivoa pre dobijanja elementarnih sekvencijalnih pro-
cesa. Gornji primer predstavlja 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 tipo-
ve celi brojevi, realni brojevi, karakteri i izvedene tipove - struktuirane podat-
ke, kao to su adresa, narudbenica, katalog proizvoda (sadre podatke razliitih
osnovnih tipova ili ugnjedene strukture). Vana karakteristika TP je njihova oba-
vezna usmerenost, koja opisuje smer toka podataka u sistemu.
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 podata-
ka i izmeu procesa uzajamno. Ti tzv. interni tokovi podataka nisu imenovani,
jer se podrazumeva da je njihova struktura denisana kroz spoljnje tokove (sis-
tem - 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 tre-
ba da predstave podprocese koji se koriste od vie drugih podprocesa na istom
nivou dekompozicije (odgovaraju procesima u stereotipskoj uses vezi u dijagra-
mima sluajeva korienja UML).
U dekomponovanju DTP, tokovi podataka moraju biti konzistentni poe-
vi 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 poda-
ci 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 CITAO-
CI. 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).
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
Teini zadatak kontekstualnog dijagrama je denisanje svih interfejsa
sa kojima sistem komunicira, kao i tokova podataka koji ine tu komunikaci-
ju. 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 kontekstu-
alan dijagram za informacioni sistem biblioteke. Moe se uoiti da posto-
ji 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, odnos-
no 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 identi-
kacija 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 detaljni-
jim DTP i
Ne moraju biti prikazana sva skladita i poslovni procesi, jer se mogu
dekomponovati
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 sofverskih modula. Tako e, na
primer IS velikog meunarodnog hotelskog sistema biti podeljen na IS za rezer-
vacije, IS odravanja i nabavke, IS voenja kadrovskog sektora, IS za odravanje
bezbednosti. Tek onda je mogua SSA takvih sistema (kroz modelovanje pojedi-
nanih 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 spoljnotrgovin-
skog preduzea. Zapoinje se kontekstualnim dijagramom. Kontekstualni dija-
gram predstavlja sistem kao crnu kutiju koja interaguje sa okruenjem (interfej-
sima) posredstvom tokova podataka (Slika 9.16).
Slika 9.16. Kontekstualni dijagram za IS spoljnotrgovinskog preduzea
Teite modelovanja na kontekstualnom dijagramu je denisanje interfej-
sa 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 inostran-
stva u procesu carinjenja bila razmatrana kao legalna. Sama nabavka se odvija
kroz dobro poznate TP: dobavlja dobija narudbenicu (dokument za naruivan-
je 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).
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 pore-
klu, 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 pro-
daje 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 otpre-
mnicu. esta greka koja se javlja u ovom sluaju da su tokovi podataka prema
dobavljaima i kupcima identino imenovani. Mora se naznaiti razlika, npr fak-
tura_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 funkcioni-
sanje sistema. Poeljno je ve u fazi SSA, omoguiti proirenje i poboljanje kva-
liteta delatnosti kojom se preduzee bavi. TP nabavke i prodaje mogu biti pro-
ireni 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 poslov-
nih 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 osnov-
nih 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 osnov-
na poslovna procesa: nabavka, carinjenje, prodaja i plaanje.
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
dobavljai, koje je 2 put prikazano na istom dijagramu. Kopija je oznaena zvez-
dicom, 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 nabav-
ke 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 dij-
agramu je direktna veza dva procesa (prijem robe i skladistenje). Proces skladis-
tenje nema ni jednu direktnu vezu sa nekim spoljnim interfejsom, ali zato omo-
guava 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.
9.3. Renik podataka
Nakon zavretka dekomponovanja DTP, postoje svi potrebni uslovi za de-
nisanje renika podataka. Renik podataka predstavlja skup podataka o podacima
koji se koriste u analiziranom sistemu. To su generalizovani podaci, esto u litera-
turi 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. Defnisanje 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 pojedina-
ni podaci: smer, ocene poloenih ispita nemaju konkretan informacioni znaaj
ako nisu objedinjeni u jedinstvenoj strukturi student, kada dobijaju sasvim dru-
gu semantiku postaju podaci konkretnog studenta.

ISPITNA_PRIJAVA
<<STUDENT>, <ISPIT>, <ISPITIVAC>, <PREDSEDNIK_ KOMISIJE>, BROJ_POKUSAJA>
ISPITNI_SPISAK
<<ISPIT>, <ISPITIVAC>, <PREDSEDNIK_ KOMISIJE>, {<STUDENT>}>
REZULTATI_ISPITA
< <ISPIT> ,{<JEDINACNI_REZULTAT>} >
ISPIT
<DATUM_ISP, PREDMET >
JEDINACNI_REZULTAT
<<STUDENT>,OCENA>
STUDENT
<<OSOBA>,<INDEKS>>
OSOBA
<IME,PREZIME,JMBG>
INDEKS
<GODINA_UPISA, PIN,DODATNO_OBELEZJE, <SEMESTAR>>
SEMESTAR
<RBR_SEMESTRA,DATUM_UPISA>
PREDSEDNIK_ KOMISIJE
<<ISPITIVAC>>
ISPITIVAC
<<OSOBA>,NAUCNO_ZVANJE, NASTAVNO_ZVANJE, [ID_ZAPOSLENOG, BR_UGOVORA]>

Slika 9.19. Primer denisanja struktura u reniku podataka
Na prethodnom primeru (Slika 9.19) strukture su imenovane (boldira-
ne), 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 sadra-
ti i nabrojive elemente (nabrajanja - enumerations). Tako na primer, struktu-
ra 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 identikacioni
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. Osnov-
no 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 struktu-
ri, 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
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, REZULTA-
TI_ISPITA, JEDINACNI_REZULTAT !
Da broj indeksa nije denisan kao struktura, administrator podataka sis-
tema 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. Defnisanje polja
Polja su zapravo osnovni podaci iz kojih su sainjene strukture koje su opi-
sane 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 , DO-
CENT, ASISTENT,ASISTENT PRIP-
RAVNIK)
Slika 9.20. Primer denisanja polja u reniku podataka
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 tipo-
vima (npr. INT- celi broj, osnovni tip, DATE datumski tip, izveden,
koji je implementiran u svim savremenim sistemima za upravljanje BP,
CHAR(30) karakterski niz, izveden tip...), ili
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 neovlae-
no 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. Defnisanje 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 dome-
na: 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.
NAZIV DOMENA PREDEFINISANI DOMEN OGRANICENJE
NAZIV CHAR(25)
IDENTIFIKACIJA CHAR(10) 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, NAUC-
NO_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 AS-
CII 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.
Model objekti-veze (MOV) 81
Pogl av l j e 10.
Model objekti-veze (MOV)
Poeti kreiranje baze podataka nekog informacionog sistema, u sutini zna-
i 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 informa-
cioni 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 proce-
se 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 podata-
ka je praktino proces u dva koraka. Poetna faza je bazirana na MOV mode-
lu, 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 ogra-
nienja u realnom svetu. Dizajniranje baze podataka zahteva dobar nivo kreativ-
nosti, iskustva, tehnike ekspertize i razumevanje osnovnih pravila. Glavna kom-
ponenta MOV pristupa je koncept entiteta (objekata i veza) - opti pojam za neto
to postoji i moe se jednoznano prepoznati. Entiteti obuhvataju objekte koji se
82 Model objekti-veze (MOV)
nalaze u jednoj organizaciji, npr. studenti, profesori i predavanja na univerzitetu.
Dalje, entiteti obuhvataju i veze 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 enti-
teta i ogranienja koja ine dati dizajn odnosno projekat. Kao i kod ostalih
vizuelno orijentisanih dizajn metodologija, on prua grafiki saetak struk-
ture baze podataka koji je veoma koristan dizajneru - ne samo u procenji-
vanju tanosti, odnosno pravilnosti dizajna, nego i za savetovanje sa kolega-
ma 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 metodo-
logije 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 teori-
ju normalizacije polaznih ema relacija.
1
U originalu: ERD entity relationships diagrams
U DTP (dijagramima tokova podataka) koji su analizirani u prethod-
nom poglavlju nisu prikazane nikakve veze izmeu tokova podatka, odnosno
izmeu skladita podataka. U stvarnosti te veze postoje, a oigledan dokaz
njihovog postojanja su renici podataka. Na primer struktuirani tip NAR-
UDZBENICA 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 sve-
ta, interfejse iz DTP, strukture iz renika podataka, ali mogu biti i isti fabrika-
ti, 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 narudbe-
nice ne moe postojati u skladitu podataka ako ne postoji narudbenica koja
ju identikuje.
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 predenis-
ani 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 uza-
jamno povezani. Veze se imenuju i njihovi nazivi oslikavaju sematniku poveza-
nosti 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).
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 ute-
de 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 uestvu-
ju 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
ulogama naziva se rekurzivna ili unarna veza. Na primer, ako je uoen entitet
Zaposleni, jedan od zaposlenih je i magacioner. Magacioner izdaje sredstva zapo-
slenima pa se uoava veza IzdajeSredstvo. Po nekada magacioner mora i sebi da
izda sredstvo. Drugim reima, enetitet Zaposleni uestvuje dva puta u vezi Izdaje-
Sredstvo: 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 pre-
thodnih 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 stu-
denti i ispitivai samo specini sluajevi (konkretizacije) entiteta OSO-
BA. 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.
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. Agre-
girani objekat se oznaava simbolom upisanog romba u pravougaonik, ime se
izraava njegova dvojaka priroda. Agregati su veoma povoljni za preciznije de-
nisanje 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 egzis-
tencijalno 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
slab objekat, jer postoje sredstva koja mogu da budu, ali nisu kompoziti). Agregati
imaju svoje atribute, mogu da budu u vezama drugog tipa (generalizacije/specija-
lizacije) sa nekim drugim objektima (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
Elementi strukture (polja) su atributi objekata. Ako je element ugnjede-
na 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 ime-
nuju 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), for-
mira se jedna stavka narudbenice (slabi objekat STAVKA_NAR_DOB). Pored
podataka artikla, stavka sadri i koliinu koja se nabavlja (nar_kol). Kreirana nar-
udbenica se alje dobavljau i on na osnovu nje isporuuje robu, uz koju alje
fakturu - raun za naplatu (objekat FAKTURA_DOB). Kupac po fakturi vri upla-
tu dobavljau (objekat UPLATA_DOB), a potvrdu (kopiju) o uplati alje dobavlja-
u, kao dokaz izmirenja svojih obaveza.
Model objekti veze omoguava potpunije shvatanje funkcionisanja siste-
ma semantikim opisom objekata i njihovih uzajamnih veza. Korienjem DOV
pojednostavljuje se prevoenje logikog u ziki model podatka.
Model objekti veze je kompatibilan sa UML
2
dijagramom klasa, to znai
da pored modelovanja podataka (data layer), omoguava i objektno orjentisano
modelovanje aplikacione logike (buisness logic layer).
2
UML Unied modeling language standard za objektno-orjentisano modelovanje IS
kroz razliite tipove dijagrama
Relacioni model podataka 91
Pogl av l j e 11
Relacioni model podataka
Relacioni model podataka predstavlja teorijsku osnovu za baze podataka
relacionog tipa. Njegovi principi i struktura predstavljeni su 1970. godine od stra-
ne Edgara T. Koda. 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 matema-
tikoj 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, pro-
grameri 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 loi-
jim performansama, a pogotovo za kompleksnije upite. Zbog toga je bitno i za
programere i za dizajnere baza da razumeju logiku koju koriste. Sa ovim zna-
njem programeri mogu da formuliu upite koje e DBMS lake da optimizuje, a
92 Relacioni model podataka
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 kancela-
rijskog 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
jefinijih i ekasnijih rjeenja. Mnoga istraivanja su izvedena u toku ovog peri-
oda. Razvijeni su hijerarhijski, mreni i relacioni model, a pojavom mikroproce-
sora, 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 relaci-
onim 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 neko-
liko 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.
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.
Sofver 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 peta-
bajta 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 nainje-
na od slogova (redova u tabeli) i polja (kolona u tabeli, atributa).
Veoma je vano zapaziti da kako i gde su tabele smetene ne pravi nikak-
vu razliku. Svaka tabela se identikuje jedinstvenim imenom koje baza podataka
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 razli-
ito 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 razli-
ku 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 dodeli-
ti 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 koris-
te, manje pouzdano, za pretrage i integraciju sa drugim bazama podataka. (Na
primer, zapisi u dve nezavisno kreirane baze podataka mogu da se upare po
jedinstvenom 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 sofver 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 ltri-
raju 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 redo-
va (proizvod ukrtanja), a zatim izbacivanjem svega osim odgovora. U praksi,
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 rezul-
tat, 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 popu-
larnim 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, kla-
sa 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. Atribu-
tima dajemo znaenje pojedinanim podacima. Relacioni model razlikuje proste
(jednostavne) i sloene atribute.
Pojedinaan podatak (prost atribut) je najmanja nedeljiva jedinica u relaci-
onom 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.
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, atribu-
ti 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(A
1
,A
2
,...,A
N
), je konaan skup atributa
{A
1
,A
2
,...,A
N
} 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 siste-
ma. 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 redo-
sledu, najee po redosledu unoenja
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 Ime)
123/02 J.Jankovic
11/03 P.Petrovic
151/02 J.Jovanovic
III-15/04 M.Markovic
11.3.3. Relaciona baza podataka
Relaciona baza podataka je konaan skup relacija koje su denisane odgo-
varajuim 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) el-
jenim 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 atri-
buti iz eme relacije), takav da za dve razliite n-torke t1 i t2 postoji atribut A
i
eK
sa osobinom t1(A
i
) t2(A
i
). Obino u jednoj relaciji moemo nai vie takvih
podskupova atributa i njih nazivamo kandidat kljuem.
Denicija: Neka je data ema relacije R. Podskup KcR je kandidat klju za
R ukoliko zadovoljava osobine:
- Jednoznanost: za svake dve razliite n-torke t1 i t2 postoji A
i
eK takav
da je t1(A
i
) t2(A
i
).
- Minimalnost: ne postoji pravi podskup K od K sa osobinom jednozna-
nosti.
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 podata-
ka primarni kljuevi se obeleavaju (podvlaenjem ili se npr. u Accessu posle nazi-
va 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 pri-
marni klju. U emi relacije STUDENT(BR_IND, IME ADRESA, SMER, RED-
NI_BR_S) imamo dva kandidat kljua BR_IND i {SMER, REDNI_BR_S}. Pri-
marni klju relacije je BR_IND, dok je {SMER, REDNI_BR_S} alternativni klju.
Ovakav primarni klju je odabran zbog jednostavnosti i zbog toga to zauzima
manje memorijskog prostora (osobina minimalnosti).
Posmatrajmo emu relacije NABAVKA(SIFD, SIFA, KOL) koja reprezen-
tuje vezu iz realnog sveta koja postoji 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 ruko-
vodioca, a to je osoba koja rukovodi odeljenjem kome pripada radnik. Kako je
rukovodilac radnik, imamo da domen atributa SIF_RUKOVODIOCA je aktivni
domen atributa SIFR.
Osobinama relacije moemo dodati i adresabilnost. Svaka kolona u rela-
ciji jednoznano je odreena nazivom atributa. Svaka n-torka jednoznano je
odreena vrednou primarnog kljua te n-torke. Svaki pojedinaan podatak jed-
noznano je odreen:
nazivom relacije
nazivom atributa
vrednou primarnog kljua
Atribute koji pripadaju primarnom kljuu nazivamo primarnim atributi-
ma. Ostale atribute nazivamo sporednim atributima.
11.3.6. Spoljni klju
Uloga spoljnih kljueva je prvenstveno u uspostavljanju veza izmeu rela-
cija. 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 klju-
evi 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 obe-
leavati - 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 pre-
cizno utemeljena kao to su precizno zasnovani objekti relacionog modela i
operacije nad objektima.
Integritet (konzistentnost) baze podataka je ispravnost i istinitost podata-
ka sadranih u bazi. Neispravni podaci mogu biti posledica auriranja (unoe-
nja i brisanja podataka) bilo namernog, bilo nenamernog od strane korisnika u
sluajevima kada je relacioni model loe denisan. Integritet podataka u irem
smislu podrazumeva sve mere kojima je cilj da sprei unos neispravnih podata-
ka. 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 rea-
lizaciju baze i proistiu iz ogranienja koja vae i u realnom svetu. Posmatrajmo
bazu koja ima relacije:
STUDENT (BR_IND, IME, PREZIME, ADRESA, GODINA SMER, RB)
0001 Marko Anti Tolstojeva 21 2 PP 1
.......................................
PREDMET (SIFP, NAZIV, B)
01 Programiranje 2
.......................................
OCENE (BR_IND, SIFP, OC)
0001 01 8
.......................................
Moemo nad tim relacijama postaviti sledea korisnika pravila integriteta:
BR_IND ima vrednost oblika nnnn tako da je podatak iz intervala 0001-
9999.
IME i PREZIME vrednost su podaci koji sadre slova ili prazninu.
ADRESA vrednost su podaci koji mogu biti slova, praznina i cifre.
GODINA uzima vrednost od 1 do 4.
SMER ima vrednost iz skupa FM, RV i OS.
RB je broj 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 godi-
na. 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 koji-
ma 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 mes-
ta boravka u kome nema matinog fakulteta i jo nije odluio da li e biti u
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 kljue-
va 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. Identifkacioni integritet
Odnosi se na opta ogranienja za primarni klju relacije. Ve smo u deni-
sanju primarnog kljua zahtevali minimalnost i jednoznanost. Vrednost primar-
nog 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 n-
torke 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-tor-
ka u relaciji RADNIK bila pozivajua, a direktori u radnim jedinicama bili bi
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 rad-
nik 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 vred-
nost). 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_RUKOVO-
DIOCA 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 (pozi-
vajua 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
Postavlja se pitanje kako postupiti kada se vri auriranje u ciljnoj relaciji,
a da se ne narui referencijalni integritet. Takva specikacija se naziva: dinami-
ka specikacija referencijalnog integriteta i odnosi se samo na kritine opera-
cije, 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 cilj-
noj 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 n-
torkama koje imaju dati promenjeni spoljni klju, menja njegova vred-
nost 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.
Relaciona algebra 105
Pogl av l j e 12
Relaciona algebra
Relaciona algebra pripada kategoriji formalnih upitnih jezika procedural-
nog 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. Sva-
ki 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 operaci-
je 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
106 Relaciona algebra
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 kriterij-
um (izdvajanje redova u tabeli).
Denicija: Restrikcija je operacija relacione algebre koja iz polazne rela-
cije po zadatom kriterijumu izdvaja podskup n-torki. Kriterijum je neki logiki
izraz koji je izraunljiv nad svakom n-torkom. Dobijena relacija ima istu struk-
turu kao i polazna.
Ako je r relacija nad emom R(X), a P(X) uslov restrikcije, formalna def.
restrikcije je:
P(X)
(r) = t(X) = {x | xer . P(X)}
Operacija restrikcije kao rezultat moe da da prazan skup C n-torki.
Uslov restrikcije P se sastoji iz lanova koji su povezani sa:
. (and),
v (or),
(not),
a svaki lan je u formi
<atribut> op <atribut> ili <konstanta>
gde je op jedan od: =, , >, , <,
P .
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.
P .
Iz relacije r(A;B;C;D):
A B C D
1 7
5 7
12 3
23 10
nakon operacije
A=B ^ D > 5
(r) dobija se
A B C D
1 7
23 10
12.2. Projekcija -
Projekcija (eng: project) kao rezultat daje relaciju koja se sastoji samo od
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 pod-
skup skupa atributa polazne relacije. Vrednosti atributa u n-torkama nastale rela-
cije odgovaraju onima u polaznoj relaciji.
Ako je r relacija nad emom R(X), Y zadati skup atributa, a x i y n-torke nad
X i Y, formalna denicija restrikcije je:
Y
(r) = t(Y) = {t | Y_X . yex}
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
P .
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 n-
torki u novonastaloj relaciji, kao i do gubitka podataka za studente sa istim ime-
nom ili prezimenom.
P 2.
Iz relacije r(A;B;C;D):
A B C
10 1
20 1
30 1
40 2
Nakon primene operacije projekcije
A,C
(r) dobija se t
1
(A,C)
A C
1
1
1
2
a zbog uslova identikacionog integriteta krajnji rezultat je t
2
(A,C)
A C
1
1
2
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 rela-
cije 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 kompa-
tibilan skup atributa u obe relacije, formalna denicija unije je:
r s = t(X) = {x | xer v xes}.
Svaka n-torka koja je prisutna u obe relacije pojavljuje se samo jednom u
rezultantnoj.
P 1.
Za unijski kompatibilne relacije r i s
r s
A B A B
1 2
2 3
1
nakon operacije r s dobija se sledea relacija
A B
1
2
1
3
P 2.
Unijom relacija A i B
IFRA# PREZIME IME TEL.BROJ
3244 Aksentijevi Petar 011 334 952
1772 Maksimovi Ilija 015 723 543
2345 Petrovi Petar 023 47 833
Dobija se relacija C = A B
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 | xer . xes}
P 1.
Za relacije A i B
primenom operacije razlike formira se relacija C = A - B
ili relacija C= B- A
P 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 posmat-
ranih 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)) t1
Nai sve klijente koji imaju kredit u ekspozituri IEX

IME_KL
(
IME_EXP=IEX
(kredit)) t2
Rezultat je: t1 - t2
12.5. Presek -
Presek (eng. intersect) - rezultat preseka dve relacije je relacija koja se sastoji
od n-torki koje su 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 unij-
ski kompatibilnih relacija.
Ako su r i s relacije nad emom R(X) i S(X), X oznaava unijski kompatibi-
lan skup atributa u obe relacije, formalna denicija preseka je:
r s = t(X) = {x | x e r . x e s}.
Presek je izvedena operacija, moe se izvesti iz
r s = r (r-s)
P 1.
Za relacije A i B
primenom operacije preseka formira se relacija C = A B
P 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)) t1
Nai sve klijente koji imaju kredit u IEX

IME_KL
(
IME_EXP
=IEX(kredit)) t2
Rezultat je: t1 t2
12.6. Dekartov proizvod -
Dekartov proizvod dve relacije je relacija koja se sastoji od svih
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.
Ako su r i s relacije nad emom R(X) i S(Y), a X i Y su skupovi atri-
buta u emama relacija, formalna denicija Dekartovog proizvoda je:
r s = t(XY) = {xy | x e r . y e s}
Kod oznaavanja za puni naziv atributa se moe koristiti relacija.atribut
(ako je X Y C), da bi se mogli razlikovati atributi iz jedne i druge relacije.
P 1.
Za polazne relacije r i s
r s
A B C D E
1 10 a
2 10 a
20 b
10 b
kao rezultat dekartovog proizvoda rs dobija se
A B C D E
1 10 a
1 10 a
1 20 b
1 10 b
2 10 a
2 10 a
2 20 b
2 10 b
Nakon primene dekartovog proizvoda, u rezultujuoj relaciji samo pojedine
n-torke imaju smisla.
P 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 t(LB.IME_KL, LB.IME_SL, K.IME_KL, K.UL_BR, K.GRAD)
Klijent
Zoran Savska Beograd
Milan Nika Novi Sad
Petar Kralja Milana Kruevac
Lini bankar
Zoran Sl1
Milan Sl2
Petar Sl3
Klijent Lini bankar
Zoran Savska Beograd Zoran Sl1
Zoran Savska Beograd Milan Sl2
Zoran Savska Beograd Petar Sl3
Milan Nika Novi Sad Zoran Sl1
Milan Nika Novi Sad Milan Sl2
Milan Nika Novi Sad Petar Sl3
Petar Kralja Milana Kruevac Zoran Sl1
Petar Kralja Milana Kruevac Milan Sl2
Petar Kralja Milana Kruevac Petar Sl3
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 e r . y e s . P(xy)}
12.6.2. spajanje
Prethodna denicija dozvoljava proizvoljni uslov P, pod uslovom da je izra-
unljiv za svaku n-torku nakon Dekartovog proizvoda
Neka su r i s relacije nad emom R(X) i S(Y). Neka su Xi i Yk atributi za koje
vai da je
XieX i YieY. 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 jed-
nakost (=) 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
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 A_X i B_Y 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 korespo-
dentnih elemenata. Umesto XY-B sa desne strane moe se navesti XY-A.
P 1.
Za polazne relacije r i s
r s
A B C D E
1 10 a
2 10 a
20 b
10 b
kao rezultat prirodnog spajanja r >
*
< s =
XY-B
(
A
=C(r s)) dobija se
r>
*
< s
A B D E
1 10 a
2 10 a
2 20 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)
P: Za dve relacije r i s, date sa:
r s
A B C D E D E
a a 1 a 1
a a 1 b 1
a b 1
a a 1
a b 3
a a 1
a b 1
a b 1
nakon operacije deljenja r/s dobija se:
A B C
a
a
S Q L 119
Pogl av l j e 13
SQL
SQL (Stuctiured Query Language) je standardni relacioni upitni jezik (ANSI
- American National Standards Institute - standard). Slui za kreiranje, organizaci-
ju 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 sis-
temima 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, Microsof SQL, itd. IBM je 1987. godine standar-
dizovao 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 pretho-
dila standardizaciji, a rezultat toga je krajnje neobina okolnost da u SQL-u, jezi-
ku za relacione baze podataka, ne postoji ni jedna konstrukcija koja sadri re
RELATION.
120 S Q L
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 podata-
ka. 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 podata-
ka, odnosno unos, izmenu i brisanje podataka. Ova komponenta je u stvari DML-
jezik baze podataka (od Data Manipulation Language).
Kontrola pristupu podacima: U svakoj bazi podataka neophodno je ostva-
riti kontrolu koji korisnici imaju pristup kojim podacima i ta mogu da rade sa
tim podacima. Ova komponenta predstavlja DCL-jezik baze podataka (od Data
Control Language).
S Q L 121
13.2. PRAVILA SQL-a
13.2.1. Pravila za pisanje imena
Imena tabela, pogleda, atributa i drugih objekata baze podataka moraju da
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.
122 S Q L
13.2.3. Tipovi podataka
Pri kreiranju tabela odreujemo tip podatka koji e biti korien. Sledea
tabela prikazuje najosnovnije standardne SQL tipove podataka, njihove karakte-
ristike, kao i neke od alternativnih podtipova.
TIP
PODATKA
OPIS
CHAR(n) Podatak tipa niza karaktera ksne duine n
VARCHAR(n) Podatak tipa niza karaktera promenljive duine
NUMBER
Numeriki podaci bilo kog tipa, do 38 cifara. Podtipovi:
DEC
DECIMAL
DOUBLE
DOUBLE_PRECISION
FLOAT
INT
NUMERIC
REAL
SMALLINT
DATE
Koristi se za promenljive i konstante iji je 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. Defnicija atributa
Atribut deniemo izrazom od dva ili tri dela:
<ime_atributa> <tip_atributa> <dodatna_svojstva_atributa>
S Q L 123
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 defnisanje
Denicija neke baze podataka podrazumeva i mogunost naknadne izme-
ne 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.
124 S Q L
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.
P:
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 iz-
mena se najee radi jer se kod prvobitnog kreiranja tabele nije uzeto u obzir
S Q L 125
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 uklan-
janja podrazumevane vrednosti. U tim okolnostima, postojea ogranienja kolo-
ne 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 pogle-
du 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 upi-
tima (kada u odreenim implementacijama pravila za SELECT naredbu
126 S Q L
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 na-
zive 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.
S Q L 127
Sintaksa naredbe za kreiranje indeksa je:
CREATE [ UNIQUE ] INDEX ImeIndeksa ON Tabela ( Kolona ,.. );
gde je znaenje pojedinih djelova ove denicije sledee:
UNIQUE 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
Ime Indeksa Unikatni naziv indeksa u bazi podataka, simbol formiran po pravilu
za nazive varijabli
Kolona Jedna ili vie kolona po kojima se formira indeks
Nad istom tabelom po potrebi moe biti denisano vie indeksa. To se koris-
ti 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 sadra-
ju 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 nared-
bom 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.
128 S Q L
Pod prostim upitom nad jednom tabelom podrazumeva se naredba SELECT
nad jednom tabelom koja kao rezultat daje ni jedan red, jedan red ili niz redova
podataka, od kojih svaki odgovara podacima iz jednog reda tabele koji zadovoljava
eventualno zadati uslov.
Rezultat upita ne mora biti relacija u smislu unikatnosti redova koji ulaze u
rezultat. To se ispoljava kada za rezultat upita biramo samo neke od kolona, kada
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 jed-
nog) istovetnih redova
R-Izraz Izraz izraunljiv nad svakim pojedinim redom tabele koji pored na-
ziva 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
S Q L 129
P 1.
Najjednostavniji mogui SQL upit je u formi:
SELECT * FROM ImeTabele;
Ova naredba prikazuje sve redove tabele ije je ime navedeno iza FROM klauzu-
le. U svakom redu prikazuju se vrednosti svih kolona, onim redom kako je to zapisano
u datoteci (tj. kreirano sa CREATE TABLE). Kod upita se 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 funk-
cije). 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 vred-
nosti zadate kolone
COUNT(*) Nalazi ukupan broj redova u tabeli
COUNT([ALL|DISTINCT] ListaKolona)
Bez DISTINCT nalazi ukupan broj ne-NULL vrednosti zadate kombina-
cije kolona
Sa DISTINCT nalazi ukupan broj razliitih ne-NULL vrednosti zadate
kombinacije kolona
P:
Uz pretposatvku da su u tabeli Student uneseni svi studenti jednog fakulte-
ta, ukupan broj studenata tog fakulteta se moe dobiti sa:
SELECT COUNT(*) FROM Student;
130 S Q L
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 specikaci-
ju 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.
S Q L 131
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 vred-
nosti nula postoji znaajna razlika. Bez obzira o kom tipu da se radi NULL vred-
nost 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 integri-
teta baze podataka. Direktno korienje ovih naredbi se zato ne preporuuje, jer
132 S Q L
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 nar-
edba 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:
S Q L 133
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
134 S Q L
SUBP odbija uklanjanja, ako je to u suprotnosti sa dinamikom specikaci-
jom 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 vido-
vi 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 pu-
tem 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
S Q L 135
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 ne-
kom 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.
Relacije loe strukture 137
Pogl av l j e 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 promovisa-
li 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 grupisan-
je atributa po tabelama. Proces normalizacije identikuje tabele na osnovu pri-
marnih 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.
138 Relacije loe strukture
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 relaci-
ji. Drugim reima, mora biti mogue rekonstruisati prethodne relacija na osno-
vu novodobijenih.
Dekompozicija eme relacije R(A1,A2,...,An) je zamena eme relacije R sa
skupom ema relacija {R1, R2, ... , Rk} za koje vai RicR 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 ponavljan-
jem 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 auri-
ranja. Anomalije auriranja mogu biti anomalije unosa, anomalije brisanja ili ano-
malije 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 nekonzis-
tentnosti 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.
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 pred-
stavlja jedan od glavnih koncepata vezanih za normalizaciju. Osnovni raz-
log 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 klju-
eva kandidata, od kojih se jedan bira za primarni klju tabele. U procesu
njihovog definisanja, naroito je znaajno pronai one funkcionalne zavisnos-
ti koje vae za sve mogue vrednosti atributa jedne tabele, jer one predstavlja-
ju 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 nor-
malne forme.
U svakom koraku normalizacije:
1. Uoava se jedna takva zavisnost (XY)
2. Vri se dekompozicija u cilju uklanjanja takve zavisnosti
3. Ako je u polaznoj vailo XY,dekompozicijom nastaju dve relacije.U
prvoj se gube atributi Y, a druga nastaje nad atributima X i Y.
4. Ne dozvoljava se gubitak podataka
Krajnji je cilj normalizacije najverovatnije trea normalna forma.U vei-
ni 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 rela-
cije da bi se proverilo da li ispunjava sva pravila denisana za odreenu normal-
nu 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 identi-
kovati i ukloniti podaci koji se ponavljaju. Postoje dva uobiajena pristupa za
uklanjanje podataka koji se ponavljaju iz nenormalizovanih tabela:
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) vred-
nosti u preseku svakog reda i kolone, pa je stoga u 1NF. Dakle, u ovom
postupku se u tabelu namerno unose podaci koji se ponavljaju, a oni se
tokom 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 pri-
marni klju. Ponekad nenormalizovana tabela sadri vie od jedne grupe
podataka koji se ponavljaju ili ak grupe unutar grupe. U takvim sluaje-
vima 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 ugnjede-
nu relaciju PROJEKAT(ifP,Sati). Atribut ifP je parcijalni primarni klju rela-
cije RADPROJ, tj. zajedno sa atributom JMBG ini njegov primarni klju. Da
bi ova ema relacije bila u 1NF nad njom se denie sledea relacija (sa nekim
trenutnim sadrajem):
JMBG Ime ifP Sati
123 Marko P1 3
123 Marko P3 2
123 Marko P5 2
222 Petar P3 4
222 Petar P4 2
333 Janko P1 5
Da bi se relacija RADPROJ prevela u bolju 1NF, potrebno je da se ugnjede-
na 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 3
M2 I2 123 P3 2
M3 I3 123 P5 2
222 P3 4
222 P4 2
333 P1 5
14.5. Druga normalna forma (2NF)
Druga normalna forma se bazira na konceptu potpune funkcionalne zavis-
nosti, koja e najpre biti denisana.
14.5.1. Potpuna funkcionalna zavisnost
Funkcionalna zavisnost AB (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 AB je delimino zavisna ako postoje neki atributi koji se mogu uklo-
niti iz A, a zavisnost i dalje vai.
14.5.2. Defnicija druge normalne forme
Druga normalna forma se odnosi na tabele sa sloenim kljuevima, tj. tabe-
le 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.
Normalizacija tabele iz 1NF u 2NF se vri uklanjanjem deliminih zavisnos-
ti, 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 AB (B je funkcionalno zavisno od A) i BC (C je funkcionalno zavisno od
B), onda je C tranzitivno zavisno od A preko B (pod uslovom da A nije funkcional-
no zavisno od B ili C).
14.6.2. Defnicija tree normalne forme
Tabela je u 3NF ako je u 1NF i u 2NF i ako u njoj ne postoje atributi ne-pri-
marni-kljuevi koji su tranzitivno zavisni od primarnog kljua.
Normalizacija tabela iz 2NF u 3NF se vri uklanjanjem tranzitivnih zavis-
nosti, 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 klju-
eve 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 nor-
malna 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.
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 determi-
nante 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 AB (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 obrat-
no 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 atri-
buti 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 ponavlja-
ju) 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 zavis-
nosti, dalja istraivanja su dovela do uoavanja jo jednog tipa zavisnosti koji se
naziva zavisnost viestruke vrednosti koji takoe moe da prouzrokuje redundat-
nost 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
EkspozituraZaposleniVlasnik iz baze podataka agencije za prodaju i izdavanje
nekretnina.
Tabela: EkspozituraZaposleniVlasnik
IdentBrEkspoziture ImeZaposlenog ImeVlasnikaNekretnine
B003 Zoran Petrovi Jelena Jankovi
B003 Miodrag Aleksi Jelena Jankovi
B003 Zoran Petrovi Predrag Stefanovi
B003 Miodrag Aleksi Predrag Stefanovi
U ovom primeru zaposleni Zoran Petrovi i Miodrag Aleksi rade u ekspozi-
turi B003, a vlasnici nekretnina Jelena Jankovi i Predrag Stefanovi su registrovani
u istoj ekspozituri, dakle B003. 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, zavis-
nost 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. Defnicija 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. Tabe-
la EkspozituraZaposleniVlasnik iz prethodnog pasusa se dekomponuje na tabele
EkspozituraZaposleni i EkspozituraVlasnik.
IdentBrEkspoziture ImeZaposlenog IdentBrEkspoziture ImeVlasnikaNekretnine
B003 Zoran Petrovi B003 Jelena Jankovi
B003 Miodrag Aleksi B003 Predrag Stefanovi
Tabela: EkspozituraZaposleni Tabela: EkspozituraVlasnik
4NF 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 ima-
ju svojstvo poznato kao postojanost spajanja (lossless-join). Ovo svojstvo se odnosi
na injenicu da se tabele nastale dekompozicijom mogu ponovo spojiti u origi-
nalnu tabelu. 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, prili-
kom 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. Defnicija 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 rekon-
struisati originalnu tabelu.
Transakcije 147
Pogl av l j e 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 pro-
grama, 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 zaklju-
avanja podataka. Dalje, u tom smislu posebno je znaajno upravljanje istovreme-
nim (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 men-
ja 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.
148 Transakcije
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 oba-
vi 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 stan-
je 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 pre-
duzea. 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. Defnicija 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 kon-
zistentnosti baze.
Naravno, u jednom trenutku nad bazom podataka se moe izvravati vie
transakcija, i imajui u vidu gore reeno, transakciona obrada oznaava grupi-
sanje izmena sadraja baze podataka u paket koji se potom obrauje kao nera-
skidiva celina. Obrada se uvek odvija tako da se uspeno izvre ili sve transakcije,
ili nijedna od njih.
Transakcije 149
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 uobi-
ajena 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 koristi-
mo 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 prin-
cipu 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 pro-
grami 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 delimi-
no 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 jed-
nog u drugo konzistentno stanje. Za vreme obavljanja transakcije konzistentnost
baze podataka moe da bude naruena. Ukoliko u toku transakcione obrade doe
150 Transakcije
do greke, podaci moraju biti vraeni u stanje pre poetka transakcije. Transakcij-
om se mora pristupati i aurirati BP tako da sva ogranienja integriteta BP ostanu
zatiena. Svaka realna organizacija je organizovano u odnosu na odreena pravi-
la koja ograniavaju mogua stanja organizacije.
Npr. broj studenata prijavljenih za nastavu ne moe prei broj mes-
ta 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 registra-
cije 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 transakci-
je 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 nje-
nog 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 prika-
zuje stanje preduzea.
Transakcije 151
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, Isolati-
on, 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, trans-
akcije 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.
152 Transakcije
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 (afer-image)
Na naredbu Rollback, SUBP koristi vrednosti pre za datu transakciju. Pre
Commit naredbe sistem prvo upisuje vrednosti pre i posle u log fajl. Ako se preki-
ne Commit naredba, mogu se 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 nekontro-
lisan 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...
Transakcije 153
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 stra-
nice sa zapisima, a ne zakljuavanje samo pojedinih zapisa, to je sluaj sa
154 Transakcije
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 omo-
guavale pravo zakljuavanje na nivou zapisa).
Zakljuavanje na nivou zapisa obezbeuje znatno bolje mogunosti vieko-
risnikog 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 trans-
akcija 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 jed-
na 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.
Transakcije 155
Verovatno je u izboru vrste zakljuavanja prihvatljivije ekskluzivno zaklju-
avanje, 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 ogra-
niavanjem. Na primer, nekom obrascu se moe dodati mogunost vremenskog
ograniavanja tako da izmene koje korisnik nije snimio posle deset minuta auto-
matski 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: gre-
ke 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 napra-
vila zapoeta transakcija, ne sme biti izgubljena. Iz tog razloga, a poto hard disk
156 Transakcije
moe da zakae, baza podataka se mora uvati na razliitim hard diskovima. Jed-
nostavan primer postizanja trajnosti jeste uvanje razliitih kopija baze podataka
na razliitim diskovima (koji se, po mogustvu, napajaju iz razliitih izvora ener-
gije). 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 identi-
na 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, sis-
tem 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 (dnevni-
ka), 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 trans-
akcija nakon pada.
Baze podataka i aplikacije 157
Pogl av l j e 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 integri-
teta i konzistentnost podataka BP), najee nude i klijentske aplikacije (alate).
Primeri ovakvih sistema su Access za Microsof JetDB i MS SQL, Enerprise DB
Designer za MySQL, Oracle, ..
Klijentski programi predstavljaju prijateljska grafika okruenja koja
omoguavaju brzo kreiranje upita (QBE
3
), 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
158 Baze podataka i aplikacije
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, otea-
na 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 inter-
fejsa 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 dis-
tribuirana. Ova pojava grupisanja objekata prema osnovnim funkcionalnostima
je nazvana raslojavanje aplikacije.
16.1. Slojevita struktura aplikacija
Raslojavanje aplikacije predstavlja odvajanje njenih delova prema funkcio-
nalnosti. U OOP, kao to je ve napomenuto, grupiu se objekti srodnih funkcio-
nalnosti (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).
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 prezen-
tacionog sloja su zapravo objekti korisnikog interfejsa: forme za unos, prome-
nu, brisanje i pregled podataka. Obradu podataka vri sloj poslovne (aplikacione)
logike. Ovaj sloj sadri kljune objekte sistema, koji sinhronizuju procese pre-
zentacionog i sloja podataka. Sloj podataka ine objekti koji komuniciraju sa BP,
preciznije sistemom sa upravljanje BP.
Slika 16.2. Troslojni aplikacioni model
Slojevi komuniciraju funkcionalnim pozivima. Poto su podaci u trosloj-
nom 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 veza-
na za distribuirane poslovne sisteme, kod kojih podaci mogu biti razdvojeni na
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 (modu-
lima). Ove sofverske 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 (server-
skih) platformi i veza (linkova) izmeu korisnika i aplikacija. Poto se razli-
ite 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 zahte-
vanih Web stranica klijentima. Takoe odgovoran je za upravljanje korisni-
kom 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 transakci-
onu obradu prema BP, itd.
16.4. Aplikacije servisi (nezavisne softverske komponente)
Iako su Web aplikacije vieslojne i distribuirane, njene softverske kom-
ponente su i dalje uzajamno zavisne i predstavljaju deo jedne celine. Da bi se
omoguilo da softverska komponenta bude dostupna razliitim aplikacija-
ma, 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 davala-
ca i korisnika servisa) i, za potrebe opisa servisa, definisan je poseban jezik
WSDL
6
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 direkto-
rijuma Web servisa (Slika 16.4). Registrovanje bi znailo da se Web servis for-
malno 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 API
7
kod konvencionalnih aplikacija, to je WSDL opis
Web servisa kod njihovih davalaca. Najei nain razmene podatka izmeu
4
XML extensible markup language
5
SOAP simple object access protocol
6
WSDL Web Service Denition Language
7
API Application Programmable Interface
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 pove-
zivanje razliitih aplikacija, tehnologija, postavljenih na razliitim platformama.
Formalizacija opisa servisa omoguava njihovu mainsku itljivost tako da apli-
kacije postaju uzajamno kooperativne bez posredovanja oveka. Web servisi uki-
daju i barijere izmeu tzv.desktop i Web aplikacija.
16.5. Specifnosti 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
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 ograni-
enjima Web itaa koji se koriste na klijentskoj strani (Internet Explorer, Nets-
cape navigator, Modzila i sl). ita interpretira HTML skript koji je primljen od
strane Web servera i otvara Web stranicu koja u sebi 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 program-
skim kodom sadran u datotekama aplikacija. U ove datoteke mogu da se doda-
ju i funkcionalnosti za pristup podacima iz BP. Za sluaj kada se direktne funk-
cije 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
kompletna BP, sa formama, izvetajima, makroima i modulima - kodiranim
procedurama u VBA
8
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 pro-
ceduru 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 WHE-
RE 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 popunje-
ne kontrolama koje omoguavaju unos i pregled podataka.

Fragment 2: Izgled Web stranice Fragment 3: Kod Web stranice iz fragm.2
8
VBA Visual Basic for Access
Forme u Web aplikacijama predstavljene su stranicama koje su kodirane
u HTML jeziku (Fragment 3). Web ita na klijentskoj maini interpretira ovaj
kod i prikazuje stranicu u svom prozoru (Fragment 2). U gornjem primeru pri-
kazane su kontrole za unos teksta (rma, adresa,postkod). Kada korisnik unese
potrebne podatke, pritiskom na dugme dodaj, pokree se akcija u zaglavlju stra-
nice (lin.1 - Fragment 3).
1: <html>
2: <body>
3: <%
4: set conn=Server.CreateObject(ADODB.Connection)
5: conn.Provider=Microsof.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 ser-
veru. Podaci koje je korisnik uneo prenose se u vidu HTTP
9
zahteva na server,
gde se koriste pri izvravanju fajla demo_add.asp. Navedena datoteka kreirana je u
ASP
10
tehnologiji i predstavlja samo jednu od velikog broja Web tehnologija koje
omoguavaju dinamiko generisanje sadraja. Ova datoteka (Fragment 4), pored
9
HTTP Hypertext Transfer Protokol protokol koji omoguava transfer podataka izmeu
Web stranica
10
ASP Active Server Pages, Microsoft tehnologija za generisaje dinamikih Web stranica
standardnog HTML koda, sadri i programski kod pisan u nekom od jezika pro-
izvedenih u Microsof-u (C++, C#, VisualBasic), koji je korien za unos podata-
ka u BP. Nakon uspostave konekcije sa Access-ovom BP partneri.mdb (lin.4-6),
komponuje se SQL naredba koja treba da 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 stra-
nicu 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 framowork -
ova za razvoj Web aplikacija nude i tag-ove za komunikaciju sa BP. Na primer za
JSP
11
postoji biblioteka tag-ova JSTL
12
, koja sadri sql tag-ove. Korienjem sql tag-
ove, 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
JSP Java Server Pages, Java tehnologija za generisaje dinamikih Web stranica
12
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 dobija-
ju 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- unutran-
ja), 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 iz-
uzetno bogatu podrku za MySQL SUBP. Postoji veliki broj ugraenih funk-
cija koje jako ubrzavaju pisanje koda a time i produktivnost izrade aplikacija:
mysql_connect za konekciju na SUBP (lin.1); @mysql_select_db za izbor
BP (lin.2); mysql_query za izvrenje SQL INSERT/UPDATE/SELECT naredbe
(lin.3); mysql_numrows za dobijanje broja zapisa kao rezultata (lin.4); mys-
ql_close za zatvaranje konekcije sa BP i SUBP (lin.5). Za razliku od ostalih
jezika, PHP 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
mestu), kao to su aplikacije za testiranje i isprobavanje. Ovakav pristup je pogo-
dan 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 proiz-
voaa, 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 poda-
cima iz prezentacionog sloja.
Poslovne aplikacije su znatno sloenije. Za sloenije
13
aplikacije, ovakav
pristup bi doveo do konfuzije ve u procesu implementacije, jer bi se preklapali
poslovi dizajnera i programera. Odravanje i upravljanje neraslojenim sofverom
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 entite-
ta. U OOP, klase koje omoguavaju interakciju sa BP, obino su ve dizajnirane i
implementirane od strane proizvoaa SUBP, ili proizvoaa sofverskih alata za
razvoj aplikacija. Takve klase su CDatabase, CRecordset klase iz Microsof (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 preuziman-
je 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 argumena-
ta je SQL naredba koja treba da se izvri u BP. Ako nema argumente, podrazume-
va se da se uzima celokupan skup zapisa iz tabele proizvoda.
13
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). Poda-
ci 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 jed-
nog zapisa, poziva se funkcija MoveNext nasleena od klase CRecordset, tako da
se u sledeoj iteraciji preuzimaju podaci sledeeg zapisa iz tabele. Nakon preuzi-
manja 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 to-
kom 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 izvr-
enje SQL naredbe za dodavanje novog zapisa u tabelu t_mtutor_groups (lin.8).
Nakon toga zatvara se konekcija sa BP, a sve naredbe se obmotavaju u try catch
blok radi kontrole greke.
Slika 16.7. Pristup BP iz klasa poslovne logike
Oba primera (Fragmenti 7 i 8) ukazuju na veoma slinu metodologiju. Naj-
pre se instanciraju potrebni objekti, zatim se uspostavi konekcija s ciljnom BP,
obavi se eljeni transfer podataka. Pri tome, podaci se uzimaju/menjaju/doda-
ju iz/u tabele BP, 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, doda-
vanja i izmene podataka) nalaze direktno u izvornom kodu aplikacije (zapravo u
klasama sloja poslovne logike). Takozvano hardcode-iranje naruava optimizova-
nost koda - time i cele aplikacije. Pristup BP iz sloja podataka poveava obim koda,
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, apli-
kacija 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 apli-
kacije 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 ugnjede-
ne procedure u SUBP MySQL 5.x. Ugnjedena procedura slina je bilo kojoj funk-
ciji, 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 para-
metri. 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). Implementa-
cija 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 argumena-
ta i prihvatanjem rezultata njihovog izvrenja.
U sledeem primeru (Fragment 10) prikazan je nain korienja ugnje-
dene procedure u Java kodu. Najpre se (lin.1) preko objekta konekcije sa BP
(conn) vri njeno pozivanje (naziv procedure je spUsedTestSets) i preuziman-
je 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();
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 prihva-
taju 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 adminis-
tratore BP. Ugnjedavanje procedura ima jo jednu znaajnu prednost. Procedure
se prave za ciljnu vrstu i verziju SUBP. One se testiraju bez potrebe povezivan-
ja s bilo kakvom aplikacijom. Na taj nain je olakano odravanje i proirivanje
sloenih sistema na nivou podataka.
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 sofverski proizvod specijalne namene. ODBC driver-i su podprogra-
mi koji se sami za sebe ne mogu koristiti. Aplikacije mogu pristupati podacima
u SUBP preko ODBC veznika koji se denie nad specinim ODBC driver-
om. Za svaku verziju sistema za upravljanje BP i operativnog sistema dizajni-
raju 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 platfor-
mama (Linux, Windows OS).
Slika 16.9. Postojei ODBC veznici u sistemu
Proizvoai OS obino u instalaciji OS nude ve niz veznika za njihove
SUBP. Na primer, Microsof uz Windows OS instalira na sistem ODBC veznike za
njegove SUBP (Access, SQL server, FoxPro). Spisak veznika je dostupan iz admi-
nistratorske konzole Control Panel-a (slika 16.9).
Tehnologija ODBC-a funkcionie na sledei nain. Najpre se bira odgo-
varajui 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 oznaa-
vanje BP koja e predstavljati izvor podataka u ODBC vezniku. Naziv ODBC
veznika ne mora imati nikakve veze sa stvarnim nazivom BP u SUBP. Nakon ovog
kratkog postupka, ODBC veznik je spreman za korienje.
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 pristu-
pa naziva se Zabeleske, a ID, datum, poruka su polja u tabeli. Komunikacija (preg-
ledanje, 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, dato-
teke). ADO dakle poseduje mnogo veu fleksibilnost (u odnosu na vrstu iz-
vora podataka) nego ODBC veznici. ADO tehnologija je dizajnirana da bol-
je podri savremene zahteve za distribuiranjem razliitih vidova multime-
dijalnih podataka.
ADO sloj predstavlja nadgradnju nad OLE
14
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 kompo-
nente davaoci (serveri) i potraioci servisa (kontroleri); Primer ovakvog
pristupa su aplikacije mail agenti, koje koriste funkcionalnosti Micro-
sof 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 funk-
cionalnosti korisnikih interfejsa, npr. omoguavaju prevlaenje,
premetanje grafikih objekata, tabelarnu prezentaciju podacima iz
BP itd.
3. COM Objekti u Windows operativnim sistemima postoji na stoti-
ne ovih objekata; svaki od njih sadri vie specifinih interfejsa koji-
ma 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 korisni-
kog interfejsa.
4. ActiveX Dokumenta kreiraju se i edituju u ActiveX serverskim aplika-
cijama (kao to su MSWord, MSExcel), a prikazuju se u ActiveX kontej-
nerskim aplikacijama (npr. Internet Explorer);
5. ActiveX Kontejneri to su najsloenije ActiveX komponente koje u
sebe mogu da prihvate automatizacione servere, kontrole i dokumenta.
Korienjem ADO objekata u aplikacijama smanjuje se kompleksnost apli-
kacije (broj linija koda napisanih radi ostvarivanja neke funkcionalnosti). Time
se smanjuje vreme potrebno za izgradnju aplikacije i poveava produktivnost
programiranja.
14
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 objeka-
ta aplikacije od prezentacije podataka u ciljnoj BP. DAO tehnologija izbega-
va 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 odno-
su na SUBP. Omoguava potpuniju kontrolu i jednostavniji pristup svim enti-
tetima u SUBP.
Slika 16.14. Korienje DAO objekata za unos podataka u tabelu u BP
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 sve-
ga 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 izd-
vajaju 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 dis-
tribuiranih informacionih sistema uinilo je Java-u moda najdominantni-
je 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 ope-
rativan i da se konektor pravi prema ciljnom SUBP. JDBC konektor ne koristi
resurse OS ve resurse Java virtualne maine (JVM
15
). Isti JDBC konektor koriste
15
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 server-
ske aplikacije (vidi poglavlje 16.3). EJB entiteta predstavlja posrednika izmeu
aplikacije i SUBP.
EJB entiteta su perzistentni (postojani) objekti koji predstavljaju pogle-
de na eljene podatke iz BP. Oni su smeteni u EJB kontejneru (delu serverske
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
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 sigur-
nosti 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. Platform-
ski 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.
Dodatak 1. Informacioni sistem kafa 183
Pogl av l j e 17
Dodatak 1.
Informacioni sistem kafa
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 jed-
nostavnijih podsistema ije funkcionisanje moemo lake da shvatimo, a
samim tim i implementiramo.
184 Dodatak 1. Informacioni sistem kafa
17.2.1. Dijagram konteksta
17.2.2. Prvi nivo dekompozicije
17.2.3. Drugi nivo dekompozicije (Nabavka)
17.2.4. Drugi nivo dekompozicije (Prodaja)
17.2.5. Drugi nivo dekompozicije (Uplata banci)
17.3. Renik Podataka
Polje Domen Uslov
SifraBanke AutoNumber NotNull
NazivBanke Text
Adresa Text
Telefon Text
SifraDobavljaca AutoNumber NotNull
TelefonDobavljaca Text
AdresaDobavljaca Text
ZRDobavljaca Text
NazivDobavljaca Text
SifraFakture AutoNumber NotNull
SifraDobavljaca Number NotNull
RokPlacanja Date/Time
Polje Domen Uslov
IznosFakture Number
DatumFakture Date/Time
SifraOtpremnice Number
BrojKataloga AutoNumber NotNull
SifraDobavljaca Number
Datum Date/Time
SifraNaloga AutoNumber NotNull
Primalac Text
SvrhaUplate Text
Datum Date/Time
Vreme Date/Time
ZRPrimaoca Text
Polje Domen Uslov
SifraBanke Number
SifraFakture SifraFakture
SifraNarudzbe AutoNumber NotNull
BrojStola Number
SifraNarudzbenice AutoNumber NotNull
Datum Date/Time
Potpisol Text
SifraOtpremnice AutoNumber NotNull
ValutaPlacanja Text
Datum Date/Time
UkupnoZaPlacanje Number
Potpisol Text
SifraPotvrde AutoNumber NotNull
SifraBanke Number NotNull
BrojZiroRacuna Text
SvrhaPlacanja Text
SifraNaloga Number
SifraRacuna AutoNumber NotNull
SifraNarudzbe Number NotNull
Vreme Date/Time
Datum Date/Time
BrojStola Number
UkupnaCena Number
RedniBroj AutoNumber NotNull
BrojKataloga Number NotNull
JedinicaMere Text
Polje Domen Uslov
Cena Number
SifraArtikla Number
SifraNarudzbe Number NotNull
SifraArtikla Number
SifraNarudzbenice Number NotNull
Kolicina Number
Cena Number
JedinicaMere Text
SifraArtikla Number
SifraOtpremnice Number NotNull
Cena Number
Kolicina Number
JedinicaMere Text
SifraArtikla Number
SifraRacuna Number NotNull
Cena Number
Kolicina Number
SifraArtikla Number
SifraArtikla AutoNumber NotNull
KolicinaZaliha Number
NazivArtikla Text
VrstaArtikla Text
OpisArtikla Text
17.4. MOV Model Objekti-Veze
17.4.1. Nabavka
17.4.2. Prodaja
17.4.3. Uplata banci
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, Jedi-
nicaMere, Cena, SifraArtikla)
OTPREMNICA (SifraDobavljaca, SifraOtpremnice, ValutaPlacanja,
Datum, UkupnoZaPlacanje, Potpisol)
STAVKA OTPREMNICE (SifraDobavljaca, SifraOtpremnice, RedniBroj,
Cena, Kolicina, JedinicaMere, SifraArtikla)
FAKTURA (SifraDobavljaca, SifraFakture, RokPlacanja, IznosFakture,
DatumFakture, SifraOtpremnice)
17.5.2. Prodaja:
NARUDZBA (SifraNarudzbe, BrojStola)
STAVKA NARUDZBE (SifraNarudzbe, RedniBroj, SifraArtikla)
RACUN (SifraNarudzbe, SifraRacuna, Vreme, Datum, BrojStola, Ukup-
naCena)
STAVKA RACUNA (RedniBroj, SifraNarudzbe, SifraRacuna, Cena,
Kolicina, SifraArtikla)
17.5.3. Uplata banci:
BANKA (SifraBanke, Ime, Adresa, Telefon)
POTVRDA O UPLATI (SifraPotvrde, SifraBanke, BrojZiroRacuna, Svr-
haPlacanja, SifraNaloga)
NALOG ZA UPLATU (SifraNaloga, Primalac, SvrhaUplate, Datum, Vre-
me, ZRPrimaoca, SifraBanke, SifraFakture)
17.6. Access Tabele
Dodatak 2. Servis za odravanje rada softverskog sistema 195
Pogl av l j e 18
Dodatak 2.
Servis za odravanje rada
softverskog sistema
Stranka podnosi zahtev za popravku raunara. Na osnovu razgovora ili ana-
lize 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 pro-
gramima koji se izbacuju na trite. Softver se nabavlja od specijalizovanih
dobavljaa.
Razvojno okruenje izabrano za aplikaciju Servis za odravanje Sofverskog
Sistema je Access 2003. Korieni su tabele, SQL upit i forme.
196 Dodatak 2. Servis za odravanje rada softverskog sistema
18.2. SSA Strukturna Sistem Analiza
18.2.2. Dekompozicija prvog nivoa
18.2.1. Dekompozicija procesa
Dekompozicija procesa 1 prijem raunara na popravku
Dekompozicija procesa 2 nabavka sofvera
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>
18.4. Specifkacija primitivnog procesa
Postoje 2 primitivna procesa:
1. Popravka raunara
2. Nabavka sofvera
Proces nabavka sofvera 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
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 dobavlja-
a prikazuje poruku radniku
2. Nabavka sofvera 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
18.5. Dijagram dekompozicije
18.6. Model objekti veze
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
2. Sistem kreira novog dobavljaa
3. Sistem prikazuje radniku novog dobavljaa
4. Radnik unosi podatke o novom dobavljau
6. Sistem skladiti podatke o novom dobavljau
- Alternativni scenariji: 6.1 Ukoliko sistem ne moe da uskladiti dobavlja-
a prikazuje poruku radniku
2. Evidentiranje novog programa SK1
1. Radnik poziva sistem da kreira novi program
2. Sistem kreira novi program
3. Sistem prikazuje radniku novi program
4. Radnik unosi podatke o programu
6. Sistem skladiti podatke o novom programu
- Alternativni scenariji: 6.1 Ukoliko sistem ne moe da uskladiti program
prikazuje poruku radniku
18.9. Fiziko projektovanje modela
podataka Access tabele
18.10. Strukturna ogranienja i pravila integriteta
Update Dobavljac CASCADES SeNabavlja
Delete Dobavljac CASCADES SeNabavlja
Update Racunar CASCADES Komponente
Delete Racunar CASCADES Komponente
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;
18.11. Forme za unos podataka
Dodatak 3. Uvoz i distribucija proizvoda bele tehnike 215
Pogl av l j e 19
Dodatak 3.
Uvoz i distribucija
proizvoda bele tehnike
Firma Singidunum Technic nam se obratila sa zahtevom za izradu i imple-
mentaciju sistema za upravljanje bazom podataka vezane za uvoz i distribuciju pro-
izvoda bele tehnike. 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 arti-
kala, 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 servi-
sa, 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.
216 Dodatak 3. Uvoz i distribucija proizvoda bele tehnike
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
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
Na prvom nivou dekompozicije postoje sledea skladita:
Ponude dobavljaa
Dobavljai
Artikli
Kupci
Serviseri
19.2.3. Drugi nivo dekompozicije - nabavka
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
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
19.3. Dijagram dekompozicije
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
MOV Nabavka - podmodel za tok Otpremnice i Prijemnice
MOV Prodaja - podmodel za tok Ponude
MOV Prodaja - podmodel za tok Porudbine i Rauna
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
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)
StavkaNal (#SifNal, #RedniBr, SifArt, KolArt)
Artikli (#SifArt, NazivArt, CenaArt, KolArt)
Ponuda (#SifPon)
StavkaPonP (#SifPon, #RedniBr, SifArt, NazivArt, CenaArt)
Servis - relacioni model
Servis (#SifSer, NazivSer, SedSer)
Kupac (#SifKup, NazivKup, SedKup)
NalogZaRad (#SifNalog, DatumN, SifSer, NazivSer, SifKup, NazivKup)
StavkaNZR (#SifNalog, #RedniBr, SifArt, NazivArt)
NalogZavR (#SifNZavR, SifSer, NazivSer, DatumNZavR, SifRac)
StavkaNZavR (#SifNZavR, #RedniBr, SifArt, NazivArt, CenaArt)
RacunS (#SifRacS, SifNZavR, NazivSer, Iznos, SifUpl)
UplataS (#SifUpl, SifRac, NazivSer, DatumUpl, IznosUpl)
19.6. Tabele, tipovi podataka
19.7. Ekranske forme
Glavni meni:
Nabavka:
Artikli:
Prodaja:
Servis:
Literatura 231
d
Literatura
[1] James L. Johnson, Database: Models, Languages, Design, Oxford University Press,
1997., London.
[2] Michael Kifer, A. Bernstein, P.M. Lewis, Database, Systems, Pearson, Addison
Wesley, 2004.
[3] S. Abiteboul, R. Hull, V.Vianu, Fundation of Databases, Addison Wesley, Boston, MA
[4] Branislav Lazarevi, Z. Marjanovi, N. 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, 2
nd
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.
Renik pojmova 233
d
Renik pojmova
Model procesa vodi projektanta kroz redosled aktivnosti vezanih za pro-
jekat i predstavlja ivot ni ciklus projekta. Istorijski posmatrano, neki modeli pro-
cesa su 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 budu-
nosti 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 uspe-
ne 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 haoti-
an razvojni proces.
Microsof solution framework - MSF model procesa kombinuje najbolje
principe modela vodopada i modela spirale. MSF kombinuje planiranje zasnova-
no na markerima i predvidljivosti rezultata kod modela vodopada sa Opte pri-
hvaen ciklus razvoja poslovnih reenja sastoji se iz nekoliko faza: prikupljanje
234 Renik pojmova
zahteva, sistemska analiza, projektovanje sistema, kodiranje, testiranje i implemen-
tacija. 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 gru-
pe 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 pro-
cesi 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 pravl-
jenja 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 sas-
tavlja i nain na koji stupa u interakciju sa korisnicima i drugim reenjima. Kada
Renik pojmova 235
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, licencira-
njem, 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 pla-
niranja 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 fizi-
kog projektovanja, radni tim primenjuje tehnoloka razmatranja i ogranienja
na konceptualni i logiki dizajn. Poto fiziko projektovanje predstavlja nasta-
vak konceptualnog i logikog projektovanja, njegov uspeh zavisi od tanosti
prethodna dva dizajna. Oslanjanje fizikog dizajna na konceptualni i logi-
ki 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, pro-
jektni tim pravi reenje. Ovaj proces ukljuuje pravljenje programskog kda koji
implementira reenja i pravljenje dokumentacije za programskog kd. Pored razvo-
ja programskog kda, radni tim razvija i infrastrukturu reenja. Proces razvoja pro-
lazi 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 stabi-
lizacije radni tim obavlja integraciju, uitavanje i beta testiranje poslovnog reen-
ja. 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 spe-
cikaciji 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.
236 Renik pojmova
Sakupljanje i analiza informacija su postupci koje obavljate u okviru
Microsof Solutions Framework (MSF) modela procesa. Postoje razliite katego-
rije 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, opera-
cije i tehnologija.
Tehnike za sakupljanje informacija Postoji est osnovnih tehnika koje
mogu da se koriste za sakupljanje informacija: posmatranje iz senke, intervjuisan-
je; ciljne grupe; ankete; instrukcije korisnika, pravljenje prototipova.
Izvori informacija Postoje razliiti tipovi informacija koje se mogu saku-
pite 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 iterativ-
ni. 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 ci-
klusa 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. Infor-
macije 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 korisni-
kog aspekta.
Renik pojmova 237
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 sekven-
cama zadataka koje ine proces.
Interna dokumentacija projektnog tima Nakon sakupljanja informa-
cija, 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 sofverskih sistema razliite sloenosti. Ti sistemi mogu
biti od velikih zajednikih informacionih sistema do distribuiranih sistema zasno-
vanih na Web tehnologiji. UML je razvijen da bi korisnicima obezbedio standard-
ni vizuelni jezik modeliranja tako da mogu da razvijaju i razmenjuju znaajne
modele. UML ne zavisi od konkretnih programskih jezika i razvojnih procesa.
UML prikazi UML omoguuje sistemskim inenjerima da naprave stan-
dardni 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 sofverskog siste-
ma. 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 sva-
ki sistem koji se pravi. Slino tome, ne koriste se svi dijagram za modeliranje
sistema. Pomou sledeih UML dijagrama mogu se opisati razliiti prikazi sis-
tema: dijagrami klasa. dijagrami objekata. dijagrami sluajeva korienja. dija-
grami 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.
238 Renik pojmova
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 poda-
ci 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 slo-
ja 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 organi-
zovani i pohranjeni.
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)
, , 1962-
Uvod u baze podataka / Mladen Veinovi,
Goran imi. - 5. izd. - Beograd :
Univerzitet Singidunum, 2010 (Loznica :
Mladost grup). - VIII, 238 str. : ilustr. ;
24 cm
Na vrhu nasl. str.: Fakultet za informatiku 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

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

You might also like