Uvod u relacione baze podataka

2,558 views
2,426 views

Published on

Uvod u relacione baze podataka

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,558
On SlideShare
0
From Embeds
0
Number of Embeds
83
Actions
Shares
0
Downloads
71
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Uvod u relacione baze podataka

  1. 1. Uvod u relacione baze podataka Gordana Pavlovi´-Laˇeti´ c z c
  2. 2. Sadrˇaj z0 Uvod 1I Relaciona tehnologija 51 Relacioni model podataka 7 1.1 O modelima podataka . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Strukturni deo relacionog modela . . . . . . . . . . . . . . . . . . . . 14 1.3 Manipulativni deo relacionog modela . . . . . . . . . . . . . . . . . . 18 1.3.1 Nedostaju´e vrednosti . . . . c . . . . . . . . . . . . . . . . . . 19 1.4 Integritetni deo relacionog modela . . . . . . . . . . . . . . . . . . . 20 1.4.1 Primarni kljuˇ . . . . . . . . c . . . . . . . . . . . . . . . . . . 21 1.4.2 Strani kljuˇ . . . . . . . . . . c . . . . . . . . . . . . . . . . . . 22 1.4.3 Trigeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Manipulativni formalizmi relacionog modela 28 2.1 Relaciona algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.1 Unarne operacije . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.1.2 Binarne operacije . . . . . . . . . . . . . . . . . . . . . . . . 31 2.1.3 Proˇirena relaciona algebra . . . . . . s . . . . . . . . . . . . . 35 2.2 Relacioni raˇun . . . . . . . . . . . . . . . . c . . . . . . . . . . . . . 37 2.2.1 Relacioni raˇun n-torki . . . . . . . . c . . . . . . . . . . . . . 38 2.2.2 Relacioni raˇun domena . . . . . . . . c . . . . . . . . . . . . . 41 2.3 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47II Relacioni upitni jezici 493 Upitni jezik SQL 52 3.1 Istorijat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.2 Definisanje podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2.1 Shema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.2 Bazne tabele . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 i
  3. 3. ii ˇ SADRZAJ 3.2.3 Indeksi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.4 Pogledi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3 Manipulisanje podacima . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.3.1 Pretraˇivanje . . . . . . . . . . . . . . z . . . . . . . . . . . . . 63 3.3.2 Jednorelacioni upiti . . . . . . . . . . . . . . . . . . . . . . . 64 3.3.3 Upiti spajanja . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.3.4 Podupiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.3.5 Korelisani podupiti . . . . . . . . . . . . . . . . . . . . . . . . 73 3.3.6 Egzistencijalni kvantifikator . . . . . . . . . . . . . . . . . . . 74 3.3.7 Agregatne funkcije . . . . . . . . . . . . . . . . . . . . . . . . 76 3.3.8 Operator grupisanja . . . . . . . . . . . . . . . . . . . . . . . 79 3.3.9 Puni upitni blok . . . . . . . . . . . . . . . . . . . . . . . . . 81 ˇ 3.3.10 Operator uredenja i operator WITH . . . . . . . . . . . . . . 82 3.3.11 Naˇin izvrˇavanja SELECT iskaza . . c s . . . . . . . . . . . . . 85 3.3.12 Relaciona kompletnost SQL-a . . . . . . . . . . . . . . . . . . 86 3.3.13 Unoˇenje . . . . . . . . . . . . . . . . s . . . . . . . . . . . . . 87 3.3.14 Aˇuriranje . . . . . . . . . . . . . . . . z . . . . . . . . . . . . . 90 3.3.15 Brisanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.4 Aplikativni SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 3.5 Dinamiˇki SQL . . . . . . . . . . . . . . . . . c . . . . . . . . . . . . . 103 3.6 Autorizacija i prava korisnika baze podataka . . . . . . . . . . . . . . 105 3.7 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084 Pogledi 111 4.1 Definisanje pogleda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.1.1 Kreiranje pogleda . . . . . . . . . . . . . . . . . . . . . . . . 111 4.1.2 Eksplicitno imenovanje kolona pogleda . . . . . . . . . . . . . 114 4.1.3 Kreiranje pogleda nad drugim pogledima . . . . . . . . . . . 115 4.1.4 Uklanjanje pogleda . . . . . . . . . . . . . . . . . . . . . . . 115 4.2 Pretraˇivanje pogleda . . . . . . . . . . . . . . . z . . . . . . . . . . . 115 4.3 Aˇuriranje, unoˇenje i brisanje nad pogledima . z s . . . . . . . . . . . 116 4.4 Prednosti pogleda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.5 Novi pristup pogledima . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.5.1 Unija, presek, razlika . . . . . . . . . . . . . . . . . . . . . . 121 4.5.2 Restrikcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.5.3 Projekcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.5.4 Prirodno spajanje . . . . . . . . . . . . . . . . . . . . . . . . 123 4.6 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235 Standardi SQL-a 125 5.1 Standardni jezik baza podataka SQL2 . . . . . . . . . . . . . . . . . 127 5.1.1 Definisanje podataka . . . . . . . . . . . . . . . . . . . . . . 127 5.1.2 Manipulisanje podacima . . . . . . . . . . . . . . . . . . . . 131 5.1.3 Aplikativni SQL . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.2 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
  4. 4. ˇSADRZAJ iii6 Upitni jezik QUEL 137 6.1 Interaktivni QUEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 6.1.1 Definisanje podataka . . . . . . . . . . . . . . . . . . . . . . . 137 6.1.2 Manipulisanje podacima . . . . . . . . . . . . . . . . . . . . . 138 6.1.3 Agregatne operacije i funkcije . . . . . . . . . . . . . . . . . . 140 6.1.4 Relaciona kompletnost QUEL-a . . . . . . . . . . . . . . . . . 141 6.1.5 Iskazi DEFINE i MODIFY . . . . . . . . . . . . . . . . . . . 142 6.2 Aplikativni QUEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.3 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457 Optimizacija upita 147 7.1 Katalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 7.2 Sistematski pristup optimizaciji . . . . . . . . . . . . . . . . . . . . . 149 7.3 Optimizacija u SYSTEM R . . . . . . . . . . . . . . . . . . . . . . . 154 7.4 Optimizacija u INGRES-u . . . . . . . . . . . . . . . . . . . . . . . . 156 7.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158III Logiˇko projektovanje c 1608 Teorija zavisnosti 162 8.1 Funkcionalne zavisnosti i dekompozicija . . . . . . . . . . . . . . . . 162 ˇ 8.2 Aksiome izvodenja . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 8.3 Zatvorenje skupa funkcionalnih zavisnosti . . . . . . . . . . . . . . . 168 8.4 Pokrivanje skupa funkcionalnih zavisnosti . . . . . . . . . . . . . . . 170 8.5 Viˇeznaˇne zavisnosti . . . . . . . . . . . . s c . . . . . . . . . . . . . . . 173 8.6 Osnovne osobine viˇeznaˇnih zavisnosti . . s c . . . . . . . . . . . . . . . 175 8.7 Zavisnosti spajanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.8 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789 Normalne forme 180 9.1 Druga normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . 180 9.2 Tre´a normalna forma . . . . c . . . . . . . . . . . . . . . . . . . . . . 183 9.3 Boyce-Codd normalna forma . . . . . . . . . . . . . . . . . . . . . . 187 9.4 Dobre i loˇe dekompozicije . . s . . . . . . . . . . . . . . . . . . . . . . 189 ˇ 9.5 Cetvrta normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . 190 9.6 Peta normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 9.7 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19210 Semantiˇko modeliranje c 195 10.1 Proˇireni relacioni model RM/T s . . . . . . . . . . . . . . . . . . . . 199 10.1.1 Strukturni deo modela . . . . . . . . . . . . . . . . . . . . . . 200 10.1.2 Integritetni deo modela . . . . . . . . . . . . . . . . . . . . . 201 10.1.3 RM/T katalog . . . . . . . . . . . . . . . . . . . . . . . . . . 202 10.1.4 Manipulativni deo modela . . . . . . . . . . . . . . . . . . . . 203
  5. 5. iv ˇ SADRZAJ 10.2 Proˇireni model entiteta i odnosa (PMEO) . s . . . . . . . . . . . . . . 204 10.3 Strukturni deo PMEO . . . . . . . . . . . . . . . . . . . . . . . . . . 205 10.3.1 Primer logiˇkog projektovanja . . . c . . . . . . . . . . . . . . 210 10.4 Semantiˇki model baze podataka . . . . . . c . . . . . . . . . . . . . . 213 10.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214IV Fiziˇka organizacija podataka c 21611 Strukture podataka i pristupne metode 218 11.1 Fiziˇka reprezentacija relacije . . . . . . . . . . . . c . . . . . . . . . . 220 11.2 Sortiranje sekvencijalne datoteke . . . . . . . . . . . . . . . . . . . . 223 11.3 Sekvencijalna organizacija . . . . . . . . . . . . . . . . . . . . . . . . 228 11.3.1 Efikasnost izvrˇavanja jednorelacionih upita s . . . . . . . . . . 229 11.3.2 Izvrˇavanje viˇerelacionih upita . . . . . . . s s . . . . . . . . . . 231 11.4 Indeks-sekvencijalna organizacija . . . . . . . . . . . . . . . . . . . . 233 11.4.1 Efikasnost izvrˇavanja jednorelacionih upita s . . . . . . . . . . 235 11.4.2 Izvrˇavanje viˇerelacionih upita . . . . . . . s s . . . . . . . . . . 238 11.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23812 Indeksna organizacija 240 12.1 Efikasnost izvrˇavanja jednorelacionih upita . . s . . . . . . . . . . . . 241 12.1.1 Pretraˇivanje . . . . . . . . . . . . . . . z . . . . . . . . . . . . 241 12.1.2 Aˇuriranje, unoˇenje i brisanje . . . . . z s . . . . . . . . . . . . 242 12.2 Izvrˇavanje viˇerelacionih upita . . . . . . . . . s s . . . . . . . . . . . . 244 12.3 Struktura indeksa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 12.3.1 Pretraˇivanje indeksa . . . . . . . . . . z . . . . . . . . . . . . 247 12.3.2 Unoˇenje u indeks, brisanje i aˇuriranje s z . . . . . . . . . . . . 248 12.4 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25113 Direktna organizacija 253 13.1 Funkcija direktnog pristupa . . . . . . . . . . . . . . . . . . . . . . . 255 13.2 Reˇavanje kolizije – posebno ulanˇavanje s c . . . . . . . . . . . . . . . . 256 13.3 Reˇavanje kolizije – otvoreno adresiranje s . . . . . . . . . . . . . . . . 260 13.4 Efikasnost izvrˇavanja operacija . . . . . s . . . . . . . . . . . . . . . . 265 13.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267V Upravljanje transakcijama 26914 Transakcija, integritet i konkurentnost 271 14.1 Transakcija i integritet . . . . . . . . . . . . . . . . . . . . . . . . . . 271 14.2 Konkurentnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 14.2.1 Izvrˇenja skupa transakcija . . s . . . . . . . . . . . . . . . . . 274 14.3 Problemi konkurentnosti . . . . . . . . . . . . . . . . . . . . . . . . . 276 14.4 Zakljuˇavanje . . . . . . . . . . . . . . c . . . . . . . . . . . . . . . . . 278
  6. 6. ˇSADRZAJ v 14.4.1 Reˇenje problema konkurentnosti . . . . . . . . . . . . . . . . 282 s 14.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28415 Oporavak 286 15.1 Oporavak od pada transakcije . . . . . . . . . . . . . . . . . . . . . . 288 15.2 Oporavak od pada sistema . . . . . . . . . . . . . . . . . . . . . . . . 289 15.2.1 Poboljˇanje procedure oporavka s od pada sistema . . . . . . . 291 15.3 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294VI Distribuirane baze podataka 29516 Problemi distribuiranih sistema 297 16.1 O distribuiranim sistemima . . . . . . . . . . . . . . . . . . . . . . . 297 16.2 Fragmentacija podataka . . . . . . . . . . . . . . . . . . . . . . . . . 300 16.3 Distribuirana obrada upita . . . . . . . . . . . . . . . . . . . . . . . 301 16.4 Preneto aˇuriranje . . . . . . . z . . . . . . . . . . . . . . . . . . . . . 305 16.5 Upravljanje katalogom . . . . . . . . . . . . . . . . . . . . . . . . . 305 16.6 Heterogeni distribuirani sistemi . . . . . . . . . . . . . . . . . . . . 306 16.7 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30817 Distribuirano upravljanje transakcijama 309 17.1 Konkurentnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 17.2 Dvofazno zakljuˇavanje . . . . . . . . . c . . . . . . . . . . . . . . . . 311 17.3 Vremenske oznake . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 17.3.1 Klase transakcija . . . . . . . . . . . . . . . . . . . . . . . . . 315 17.3.2 Analiza grafa konflikta . . . . . . . . . . . . . . . . . . . . . . 316 17.4 Oporavak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 17.5 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32218 Klijent-server sistemi baza podataka 323 18.1 Jedna realizacija klijent-server RSUBP . . . . . . . . . . . . . . . . . 326 18.1.1 DB2 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 18.1.2 DB2 klijent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 18.1.3 Ostali DB2 proizvodi . . . . . . . . . . . . . . . . . . . . . . . 327 18.1.4 Priprema i izvrˇavanje aplikativnih porograma s . . . . . . . . 329 18.1.5 Fiziˇka organizacija podataka u sistemu DB2 . c . . . . . . . . 333 18.2 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336A Objektno orijentisane baze podataka 337 A.1 Objektno orijentisani model podataka . . . . . . . . . . . . . . . . . 339 A.1.1 Jezgro objektno orijentisanog modela podataka . . . . . . . . 339 A.1.2 Ostali koncepti objektno orijentisanih modela podataka . . . 344 A.2 Objektno orijentisani sistemi baza podataka . . . . . . . . . . . . . . 348 A.2.1 Dugotrajne transakcije . . . . . . . . . . . . . . . . . . . . . . 348 A.2.2 Upitni jezici . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
  7. 7. A.3 Sistemi baza podataka nove generacije . . . . . . . . . . . . . . . . . 353 A.4 Pitanja i zadaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355Bibliografija 357
  8. 8. 0UvodTradicionalni pristup razvoju programskih sistema za ˇuvanje i obradu podataka, cdo pojave baza podataka krajem ˇezdesetih godina, bio je u suˇtini ad hoc: polaze´i s s cod definicije aplikacije, kreirala bi se datoteka ili skup datoteka podataka potrebnih ˇza definisanu aplikaciju, i pisali bi se programi koji obraduju podatke tih datotekau skladu sa aplikacijom ([52]). Sva proˇirenja definisane aplikacije realizovala bi se sdodavanjem novih datoteka i pisanjem dodatnih programa. Ovakav pristup je brzopokazao sve svoje nedostatke: • Ponavljanje istih podataka uz razliˇite aplikacije. Na primer, u jednom bibli- c oteˇkom okruˇenju, aplikacije za obradu knjiga, reversa i ˇitalaca mogle bi da c z c ˇ koriste odgovaraju´e datoteke – KNJIGE, REVERSI, CITAOCI, redom. pri c tom bi, s obzirom na potrebe ovih aplikacija, datoteka REVERSI sadrˇala sve z podatke o knjizi i ˇitaocu koji su ve´ sadrˇani i u datoteci KNJIGE odnosno c c z ˇ CITAOCI. • Nekonzistentnost podataka. Zbog ponavljanja istih podataka u raznim da- totekama, moˇe se dogoditi da se promena vrednosti primercima istog po- z datka ne izvede dosledno, tj. da se jednom primerku istog podatka vrednost promeni (namerno ili nenamerno), a da se to ne uˇini sa ostalim primercima c tog podatka. Na primer, adresa istog ˇitaoca moˇe da bude razliˇito zapisana c z c ˇ u datotekama CITAOCI i REVERSI, ˇto ´e proizvesti nekonzistentnost (neko- s c rektnost) podataka. • Programi za obradu podataka zavise od naˇina struktuiranja podataka. Tako c ´e ti programi biti razliˇiti u sluˇajevima razliˇite organizacije datoteka c c c c (sekvencijalna, indeks-sekvencijalna, direktna, indeksirana, itd). Zato pro- mena strukture podataka zahteva promenu programa. • Obrada podataka je skupa, s obzirom na nekonzistentnost i zavisnost pro- grama od organizacije podataka. 1
  9. 9. 2 0 Uvod • Koriˇ´enje istih podataka od strane ve´eg broja korisnika je oteˇano. Na sc c z primer, istovremeni pokuˇaj dva ili viˇe korisnika da promene sadrˇaj datoteke s s z REVERSI zavrˇi´e se, u mnogim sluˇajevima, pam´enjem promena samo sc c c onog korisnika koji je poslednji zavrˇio rad sa datotekom. Ostali korisnici ni s na koji naˇin ne´e biti obaveˇteni o tome da njihove promene nisu upam´ene. c c s c U drugim sluˇajevima viˇekorisniˇkog pristupa podacima smeˇtenim u sistem c s c s datoteka, kada se pristup vrˇi istoj kopiji datoteke, mogu´i su i teˇi primeri s c z naruˇavanja korektnosti podataka. s • Neadekvatna realizacija oporavka od pada sistema. U sluˇaju pada sistema c (npr. nestanka elektriˇnog napajanja), aktivni poslovi nemaju mogu´nost c c poniˇtavanja svojih delimiˇnih izvrˇenja (ako su ona deo jedinstvene logiˇke s c s c celine), a ˇesto, po uspostavljanju sistema, ni evidenciju o svom delimiˇnom c c izvrˇenju. Na primer, ako bi svim ˇitaocima trebalo produˇiti (na reversu) s c z rok zaduˇenja za po 10 dana, i ako bi usred izvrˇavanja tog posla doˇlo do z s s pada sistema, po uspostavljanju rada ne bi postojala informacija o tome koji ˇ su reversi obradeni a koji joˇ nisu. s Da bi se mogle iskoristiti pogodnosti raˇunara za ˇuvanje podataka, neophodno c cje obezbediti i programske alate prenosa podataka, upravljanja podacima i komu-nikacije sa korisnikom. Zato nova organizacija podataka, nazvana baza podataka,zajedno sa programskim alatima koji je podrˇavaju, treba da obezbedi: z ˇ • nezavisnost struktura podataka od programa koji ih obraduju, i programa od struktura podataka (izmena podataka ne utiˇe na programe); c • minimalnost ponavljanja podataka; • da obrada podataka nije vezana za programski jezik opˇte namene, ve´ za viˇi s c s “upitni” jezik; • koriˇ´enje baze podataka od strane ve´eg broja korisnika. sc c Pojam baza podataka pojavio se krajem ˇezdesetih godina i oznaˇavao je skup s c ˇ ˇmedusobno povezanih podataka koji se ˇuvaju zajedno, i medu kojima ima samo conoliko ponavljanja koliko je neophodno za njihovo optimalno koriˇ´enje pri viˇe- sc skorisniˇkom radu. Podaci se pamte tako da budu nezavisni od programa koji ih ckoriste, i struktuiraju se tako da je omogu´en porast baze. Posle svake aktivnosti cnad bazom, koja predstavlja logiˇku celinu posla, stanje baze mora biti konzis- c ˇtentno (valjano); to znaˇi da podaci u bazi i odnosi medu njima moraju zadovol- cjavati unapred zadate uslove koji odslikavaju deo realnosti modelirane podacima ubazi. Za efikasan rad sa podacima i odrˇavanje konzistentnog stanja baze koristi zse specifiˇni programski proizvod – sistem za upravljanje bazama podataka (kra´e c cSUBP – DBMS, Data Base Management System). Baze podataka zajedno sa SUBPˇine sistem baza podataka. U ˇirem smislu, u sistem baza podataka spada i odgo-c s c ˇvaraju´i hardver, svi programski alati koji se nadgraduju na SUBP i olakˇavaju rad s
  10. 10. 0 Uvod 3sa bazama, kao i raznorodni korisnici baza podataka (od krajnjih korisnika, prekoaplikativnih programera do administratora baza podataka). U razvoju sistema baza podataka moˇe se uoˇiti nekoliko generacija SUBP, koje z csu ili koegzistirale na trˇiˇtu ili smenjivale jedna drugu. Fundamentalna razlika zs ˇizmedu sistema ovih generacija je razlika u modelu podataka, koja se u imple-mentaciji odgovaraju´ih SUBP reflektuje na efikasnost pristupa podacima i obrade cpodataka, produktivnost korisnika, funkcionalnost sistema i podrˇku raznovrsnim saplikacijama. Tako se u prve dve generacije svrstavaju tzv. mreˇni (CODASYL) z ˇsistemi i hijerarhijski sistemi, koji su gotovo u potpunosti prevazideni, osamdesetihgodina, relacionom tehnologijom kao tre´om generacijom SUBP (Relacioni SUBP c– RSUBP). Sve tri generacije namenjene su pre svega poslovno-orijentisanim ap-likacijama. Ograniˇenja relacione tehnologije odnose se na neadekvatnu podrˇku aplikaci- c sjama nad podacima kompleksnijim od podataka u poslovnoj obradi, npr. nadprostornim ili tekstuelnim podacima. Zato se relacioni model podataka proˇiruje skonceptima objektnog modela, koji na adekvatniji naˇin apstrahuje svojstva kom- cpleksnih objekata; istovremeno, relaciona tehnologija se integriˇe sa objektnom stehnologijom grade´i tako novu, ˇetvrtu generaciju SUBP. Objektna tehnologija c cje joˇ uvek u istraˇivaˇkoj fazi, mada postoje i prototipske i komercijalne im- s z cplementacije sistema za upravljanje bazama podataka. Teorijske osnove objektnetehnologije, za razliku od relacione, joˇ nisu postavljene; ovo vaˇi i za sam objektni s zmodel. Ova knjiga odnosi se pre svega na relacionu tehnologiju baza podataka, poˇevˇi c sod osnovnih postavki relacionog modela i relacionih upitnih jezika, preko teorijelogiˇkog projektovanja relacione baze podataka i semantiˇkog modeliranja, pa do c cproblema i reˇenja vezanih za implementaciju pune funkcionalnosti RSUBP. s Osnovna komponenta sistema za upravljanje relacionim bazama podataka kojukorisnik vidi jeste relacioni upitni jezik. To je sredstvo kojim korisnik ostvaruje ko-munikaciju sa relacionom bazom podataka, kojim izraˇava i zadovoljava sve zahteve zvezane za podatke u bazi. Zato se, sa korisniˇke taˇke glediˇta, upitni jezik ˇesto c c s cidentifikuje sa kompleksnim sistemom za upravljanje bazama podataka, koji u stvarite zahteve izvrˇava, korektno i efikasno. Jedan od upitnih jezik koji se u ovoj knjizi sdetaljno izlaˇe i kojim se ilustruje funkcionalnost RSUBP jeste SQL. Bez obzira zna sve nedostatke, SQL je standard relacionih upitnih jezika, i daleko je najzas-tupljeniji u relacionim sistemima; zato je njegovo detaljno poznavanje neophodnoza efikasno koriˇ´enje tih sistema. Kako se varijante SQL-a u razliˇitim sistemima sc crazlikuju, ovde se, zbog preciznosti, izlaˇe jedna od tih varijanti – SQL sistema zIBM DB2 UDB (Universal DataBase) Verzija 5, bez specifiˇnosti tesno vezanih za covaj RSUBP. Sredstvo kojim sistem za upravljanje bazama podataka omogu´uje ve´em broju c ckorisnika istovremeni pristup podacima, uz punu bezbednost i korektnost podataka,jeste transakcija. Transakcija je logiˇka jedinica posla i moˇe da se sastoji od jedne c z c c ˇili ve´eg broja radnji nad bazom podataka, pri ˇemu obezbeduje uslov da podaci iodnosi meduˇ njima, posle zavrˇetka transakcije, korektno odraˇavaju realnost koja s z
  11. 11. 4 0 Uvodse tim podacima modelira. Upravljanje transakcijama omogu´uje da se svi zahtevi ckorisnika korektno izvrˇavaju, a realizuje se posebnim komponentama koje koristi ssistem za upravljanje bazama podataka. Funkcija SUBP kojom se reguliˇu prava pristupa pojedinih korisnika pojedinim sobjektima (podacima i drugim resursima), kao i prava izvrˇenja raznih operacija snad tim objektima, zove se autorizacija. Ona se delom realizuje mehanizmompogleda, ali i specifiˇnim podsistemom autorizacije i prava korisnika. Naˇini real- c cizacije autorizacije predstavljeni su u ovoj knjizi. Poseban znaˇaj u radu sa relacionim bazama podataka ima struktuiranje i orga- cnizacija samih podataka. Podatke je na nivou korisnika potrebno struktuirati, a nafiziˇkom nivou organizovati tako da njihovo odrˇavanje bude najlakˇe, a operisanje c z snjima najefikasnije. Skup postupaka kojima se dolazi do dobro struktuiranih po-dataka u bazi podataka naziva se metodama logiˇkog projektovanja baze podataka. cSkup postupaka kojima se podaci fiziˇki organizuju u bazi, tako da im je pristup ci odrˇavanje najefikasnije, naziva se metodama fiziˇkog projektovanja, tj. meto- z cdama fiziˇke organizacije podataka. Zato metode logiˇkog projektovanja i fiziˇke c c corganizacije imaju posebno mesto u ovoj knjizi. Znaˇajan segment relacione tehnologije predstavljaju distribuirane baze po- cdataka. Mada su sistemi za upravljanje distribuiranim bazama podataka takode ˇrelacioni, problemi koji se u njima moraju reˇavati, kao i metode za njihovo sreˇavanje, znatno su sloˇeniji nego u centralizovanim sistemima. U ovoj knjizi s zrazmatraju se posebno karakteristiˇni problemi u realizaciji pune funkcionalnosti c ˇdistribuiranih sistema. Takode se izlaˇe i specijalni sluˇaj arhitekture distribuiranih z csistema – ˇiroko rasprostranjena klijent-server arhitektura. s Pored relacione tehnologije kojoj je ovaj udˇbenik posve´en, izuzetno aktuelnu z ctemu u oblasti baza podataka predstavljaju objektno orijentisane baze podataka.Objektna tehnologija nema tendenciju potiskivanja starije – relacione tehnologije.Umesto toga, integracija koncepata relacione i objektne tehnologije vidi se kaoosnov za izgradnju modelˆ i sistemˆ baza podataka nove generacije. Zato je kon- a aceptima objektno orijentisanih modela i nekim od kljuˇnih komponenti objektno corijentisanih sistema posve´en dodatak ovog udˇbenika. c z
  12. 12. Deo IRelaciona tehnologija
  13. 13. Deo I sastoji se od dve glave:• Glava 1, Relacioni model podataka, prikazuje relacioni model podataka i ˇ odreduje njegovo mesto u arhitekturi sistema baza podataka. Relacioni model se definiˇe preko tri bitne komponente modela; to su strukturni, manipulativni s i integritetni deo modela. Strukturni i integritetni deo relacionog modela izlaˇu se detaljno u ovoj glavi, dok je manipulativni deo samo naznaˇen. z c Zbog znaˇaja i kompleksnosti manipulativnih formalizama relacionog modela, c njihovo razmatranje izdvojeno je u posebnu, drugu glavu.• U glavi 2, Manipulativni formalizmi relacionog modela, izlaˇu se dva z osnovna formalizma za manipulisanje podacima u relacionom modelu, rela- ciona algebra i relacioni raˇun. S obzirom na znaˇajna odstupanja postoje´ih c c c relacionih implementacija od osnovnih postavki relacionog modela, pre svega u upitnim jezicima, aktuelizovano je istraˇivanje implikacijˆ manipulativnih z a formalizama relacionog modela na razvoj novih sistema. 6
  14. 14. 1Relacioni model podataka1.1 O modelima podatakaArhitektura najve´eg broja sistema baza podataka odgovara predlogu ANSI/SPARC cstudijske grupe Ameriˇkog nacionalnog instituta za standarde, i poznata je kao cANSI arhitektura ([6]). Ova arhitektura predstavljena je hijerarhijom apstrak-cija, pri ˇemu svaki nivo hijerarhije ukljuˇuje specifiˇni naˇin predstavljanja, c c c c ˇreprezentaciju, objekata, odnosa medu objektima i operacija nad objektima. Hi-jerarhijska arhitektura omogu´uje prirodnu dekompoziciju i efikasni razvoj sistema cza upravljanje bazama podataka. Najniˇi nivo ANSI arhitekture je unutraˇnji nivo. On je najbliˇi fiziˇkoj z s z creprezentaciji baze podataka, koja u raˇunarskom sistemu jedina zaista postoji. cZbog toga se unutraˇnji nivo ˇesto i zove “nivo fiziˇke baze podataka”. Slede´i s c c cnivo ANSI arhitekture je konceptualni (logiˇki) i predstavlja naˇin na koji se po- c cdaci iz fiziˇke baze podataka predstavljaju korisniku u opˇtem sluˇaju. Najviˇi nivo c s c s ˇANSI arhitekture je spoljaˇnji nivo koji predstavu o podacima iz baze prilagodava spotrebama specifiˇnih korisnika ili grupa korisnika. c Globalna ANSI arhitektura sistema baza podataka moˇe se predstaviti shemom zna slici 1.1. Objasnimo neˇto detaljnije njenu strukturu. s Reprezentacija koja se nalazi na “srednjem”, konceptualnom nivou ANSI hije-rarhije zove se model podataka. Modelom podataka predstavlja se logiˇka struktura csvih podataka u bazi i skup operacija koje korisnik moˇe izvrˇiti nad tim podacima. z sTo znaˇi da se na konceptualnom nivou mogu “videti” svi podaci iz fiziˇke baze c cpodataka, samo ˇto je njihova reprezentacija pogodnija za korisnika od fiziˇke (na s cviˇem je nivou apstrakcije). s Pojedini korisnici ili grupe korisnika mogu imati svoja sopstvena specifiˇna cgledanja na model podataka (npr. iz razloga zaˇtite ili udobnosti), pa se pogledi s(podmodeli, spoljaˇnji nivo hijerarhije) nalaze iznad modela u hijerarhiji apstrak- scija. Isti podaci iz fiziˇke baze podataka (i sa konceptualnog nivoa), na ovom nivou c 7
  15. 15. 8 1 Relacioni model podataka (spoljaˇnje sheme, s pogledi (podmodeli) spoljaˇnji nivo) s d s T   d   d  (konceptualna shema, model podataka logiˇki nivo) c T (fiziˇka baza podataka, c strukture podataka, procedure unutraˇnji nivo) s Slika 1.1: ANSI arhitektura sistema baza podatakamogu se raznim korisnicima predstaviti na razne naˇine, dok se postojanje nekih po- cdataka moˇe od nekih korisnika i sakriti. Zato postoji taˇno jedan model podataka z cu sistemu, koji se odnosi na celokupnost baze podataka, i ve´i broj spoljaˇnjih c spogleda, od kojih se svaki sastoji od apstraktne slike dela baze podataka. Na primer, baza podataka o studentima moˇe da sadrˇi podatke iz dosijea z zstudenata, sa liˇnim podacima i podacima o uspehu (predmetima, ocenama, da- ctumima polaganja, nagradama, kaznama) svakog studenta. Na konceptualnomnivou podaci mogu biti predstavljeni tabelama DOSIJE, NASTAVNI PLAN, NA-GRADE I KAZNE i POLAGANJE. Na spoljaˇnjem nivou, korisnicima statistiˇkih s cobrada ova baza podataka moˇe se predstaviti kao da sadrˇi samo podatke o us- z zpehu (npr. u virtuelnoj tabeli USPEH PO PREDMETIMA); ostali, liˇni podaci ckoji mogu da identifikuju studenta, skrivaju se od statistiˇkih aplikacija. Razliˇitim c cpodgrupama korisnika mogu odgovarati joˇ apstraktnije predstave o podacima, koje sodgovaraju viˇim nivoima podmodela. s Korisnik svoje zahteve za operacijama nad bazom podataka postavlja na koncep-tualnom ili spoljaˇnjem nivou, i to interaktivno, na posebnom “jeziku podataka”, ili sprogramski, kada je jezik podataka ugnjeˇden u neki programski jezik opˇte namene z s(tzv. matiˇni jezik, v. odeljak 3.4). c Na nivou fiziˇke baze podataka – unutraˇnjem nivou, model podataka pred- c sstavlja se specifiˇnim, fiziˇkim strukturama podataka (datotekama sa sekvenci- c cjalnim, indeksnim ili direktnim pristupom), i procedurama za fiziˇku realizaciju coperacija koje korisnik zadaje na viˇem nivou. s Primarni cilj modela podataka u kontekstu baza podataka jeste da obezbediformalni sistem za predstavljanje podataka i manipulisanje podacima u bazi po-dataka.
  16. 16. 1.1 O modelima podataka 9 Model podataka se moˇe posmatrati kao kolekcija slede´a tri skupa: z c a) skup tipova objekata b) skup operacija nad objektima definisanih tipova c) skup pravila integriteta. Opiˇimo ukratko svaki od ovih skupova. s a) Skup tipova objekata ˇini strukturni deo modela. Tipovima objekata opisuju c ˇ se entiteti (objekti, stvari, lica, pojave, dogadaji od znaˇaja koji se mogu c jednoznaˇno identifikovati) koji su relevantni za korisnike baze (objekat i en- c titet ´e se nadalje uglavnom upotrebljavati sinonimno, osim ako se naglasi c drugaˇije). Sami tipovi entiteta karakteriˇu se svojstvima. c s c z z ˇ Na primer, izdavaˇka baza podataka moˇe da sadrˇi, izmedu ostalih, tipove ˇ entiteta KNJIGA, PISAC i IZDAVAC, sa odgovaraju´im svojstvima (slika c 1.2). Znaˇenje svojstava je uglavnom oˇigledno: svaka knjiga ima naslov i c c oblast kojoj pripada, uz pisca se kao znaˇajna svojstva navode njegovo ime, c broj objavljenih naslova i drˇava ˇiji je drˇavljanin, dok izdavaˇa karakteriˇu z c z c s njegov naziv, status (u funkciji broja izdatih naslova) i drˇava u kojoj je z registrovan. Specifiˇni model (npr. relacioni, mreˇni, hijerarhijski) izabra´e c z c specifiˇan naˇin za opisivanje ovih tipova entiteta i njihovih svojstava. c c KNJIGA naslov oblast PISAC ime br naslova drˇava z ˇ IZDAVAC naziv status drˇava z Slika 1.2: Tipovi entiteta izdavaˇke baze podataka c b) Skup operacija ˇini manipulativni deo modela. Operacijama se zadaju upiti c i radnje nad entitetima, tj. pretraˇivanje i menjanje (aˇuriranje) podataka o z z entitetima. Na primer, radnje nad pojedinaˇnim entitetima mogu biti: c – registrovati novu knjigu – rashodovati knjigu
  17. 17. 10 1 Relacioni model podataka – izmeniti drˇavljanstvo pisca z – izmeniti status izdavaˇa. c Primer operacije kojom se zadaje upit nad pojedinaˇnim tipom entiteta moˇe c z biti: – ˇtampati spisak knjiga iz zadate oblasti. s c) Skup pravila integriteta ˇini integritetni deo modela. Pravila integriteta c definiˇu uslove integriteta podataka u bazi podataka, tj. svojstva podataka s ˇ ili odnosa medu podacima, koji moraju biti zadovoljeni da bi stanje baze bilo valjano. Na primer, uslovi integriteta pridruˇeni pojedinaˇnim tipovima entiteta mogu z c biti: – dva razna izdavaˇa ne mogu imati isti naziv c – pri promeni broja naslova pisca, novi broj naslova mora biti ve´i od c prethodnog (starog). Osim upita, radnji i uslova integriteta koji se odnose na pojedinaˇne tipove centiteta, kao u prethodnim primerima, neki upiti i radnje mogu se odnositi na viˇe stipova entiteta, kao na primer: – ˇtampati spisak svih knjiga datog pisca s – promeniti izdavaˇa za datu knjigu. c I upiti i radnje ove vrste (nad viˇe tipova entiteta) zadaju se nad odnosima s ˇ ˇmedu tipovima entiteta. Na primer, IZDAVASTVO se moˇe definisati kao odnos z ˇ ˇizmedu tipova entiteta IZDAVAC i KNJIGA, dok se AUTOR moˇe definisati kao z ˇodnos izmedu tipova entiteta PISAC i KNJIGA. Ti odnosi se mogu posmatrati ikao apstraktni tipovi entiteta u modelu (sa svojim svojstvima). Svojstva odnosa ˇIZDAVASTVO i AUTOR mogu se prikazati slikom 1.3. Redni broj mogao bi daoznaˇava da je dati pisac naveden kao prvi (drugi, tre´i, itd.) autor date knjige. c c ˇ IZDAVASTVO KNJIGA godina tiraˇ z ˇ IZDAVAC AUTOR PISAC redni broj KNJIGA Slika 1.3: Tipovi odnosa izdavaˇke baze podataka c Nad odnosima se mogu zadavati i uslovi integriteta, na primer:
  18. 18. 1.1 O modelima podataka 11 – dva razna izdavaˇa ne mogu u istoj godini izdati istu knjigu. c Najpoznatiji klasiˇni modeli podataka su hijerarhijski, mreˇni i relacioni model. c zZa hijerarhijski i mreˇni model karakteristiˇno je da su nastali u procesu apstrak- z ccije ili indukcije iz postoje´ih implementacija SUBP, a ne kao apstraktni modeli. cSami mreˇni i hijerarhijski sistemi su prerelacioni i karakteriˇu se niˇim nivoom z s zapstrakcije nego relacioni sistemi, pre svega slogovnom prirodom podataka i ma-nipulisanja podacima. Detaljni opis hijerarhijskog i mreˇnog modela kao i elementi znjihovih najpoznatijih implementacija, IMS i IDMS redom, mogu se na´i u [22], ci u ovoj knjizi ne´e biti razmatrani. Umesto toga, ilustrujmo slede´im primerom c cnaˇin na koji se u hijerarhijskom, mreˇnom i relacionom sistemu realizuju delovi c zodgovaraju´ih modela. c ˇ ˇ Neka medu entitetima KNJIGA i IZDAVAC postoji funkcionalni odnos, tj. nekavaˇi da jednu knjigu moˇe da izdaje samo jedan izdavaˇ, dok jedan izdavaˇ moˇe da z z c c zizdaje ve´i broj knjiga. Strukturni deo hijerarhijskog modela u ovom sluˇaju sastoji c c ˇse od dva tipa entiteta – KNJIGA i IZDAVAC sa pripadnim svojstvima, i jednog ˇtipa funkcionalne veze – KNJIGA → IZDAVAC (slika 1.4). U ovoj funkcionalnoj ˇvezi tip entiteta IZDAVAC je tzv. roditeljski tip, a tip entiteta KNJIGA je tzv. tipdeteta. Jedan tip deteta moˇe imati najviˇe jedan roditeljski tip. z s ˇ IZDAVAC c KNJIGA Slika 1.4: Funkcionalna veza u hijerarhijskom modelu U hijerarhijskom SUBP IMS definicija baze ukljuˇuje naziv baze i, za svaki ctip entiteta, definiciju tog tipa (u IMS terminologiji – segment, SEGM). Definicijatipa entiteta ukljuˇuje ime entiteta, duˇinu odgovaraju´eg segmenta u bajtovima, c z cime roditeljskog tipa entiteta (PARENT) i imena atributa (u IMS terminologiji –polja, FIELD), a za svako polje – duˇinu u bajtovima, adresu prvog bajta polja u z ˇokviru segmenta, i eventualnu uredenost segmenata po tom polju (engl. sequencing,SEQ). Deo definicije hijerarhijske baze u naˇem sluˇaju mogao bi da ima slede´i s c coblik (polja I SIF, K SIF predstavljaju ˇifru izdavaˇa odnosno ˇifru knjige): s c s 1 DBD NAME = IZDAVASTVO 2 SEGM NAME = IZDAVAC, BYTES=44 3 FIELD NAME = (I SIF, SEQ), BYTES=2, START=1
  19. 19. 12 1 Relacioni model podataka 4 FIELD NAME = NAZIV, BYTES=20, START=3 5 FIELD NAME = STATUS, BYTES=2, START=23 6 FIELD NAME = DRZAVA, BYTES=20, START=25 7 SEGM NAME = KNJIGA, PARENT = IZDAVAC, BYTES=52 8 FIELD NAME = (K SIF, SEQ), BYTES=2, START=1 9 FIELD NAME = NASLOV, BYTES=40, START=3 10 FIELD NAME = OBLAST, BYTES=10, START=43 Ova definicija hijerarhijske baze ukljuˇuje i integritetni deo u smislu da u bazi cne moˇe postojati informacija o knjizi ako ne postoji informacija o njenom izdavaˇu, z cjer se entitet tipa KNJIGA definiˇe u okviru “roditeljskog” entiteta tipa IZDAVAC s ˇ(uslov koji je u relacionom modelu poznat kao referencijalni integritet). Manipulisanje podacima u hijerarhijskom modelu je u znatnoj meri procedu- ˇralno i podrazumeva precizno navodenje hijerarhijskog puta ka traˇenom segmentu. zTako bi, na primer, zahtev za nalaˇenjem prve knjige – romana izdavaˇa ’Prosveta’ z cmorao da sadrˇi i precizno uputstvo kako se do odgovaraju´eg segmenta o toj knjizi z cdolazi, i pojednostavljenom sintaksom jezika za manipulisanje podacima sistemaIMS izrazio bi se u obliku GET UNIQUE IZDAVAC WHERE NAZIV = ’Prosveta’ KNJIGA WHERE OBLAST = ’roman’ ˇ(redosled navodenja entiteta je veoma bitan i mora da odgovara redosledu roditelj– dete iz definisane funkcionalne veze). Ovakav iskaz ne moˇe se zadavati interaktivno, ve´ iskljuˇivo iz programa na z c cprogramskom jeziku opˇte namene (npr. COBOL, PL/I). s ˇ ˇ U sluˇaju da medu tipovima entiteta IZDAVAC i KNJIGA ne postoji funkcio- cnalna veza, hijerarhijski model pokazuje svoje slabosti (jer ne moˇe da definiˇe viˇe z s sod jednog tipa roditelja za jedan tip entiteta). Mreˇni model dopuˇta da jedan z stip deteta moˇe imati ve´i broj roditeljskih tipova entiteta u okviru razliˇitih (ime- z c cnovanih) funkcionalnih veza. Svaki tip entiteta – domen funkcionalne veze zovese tip ˇlana te funkcionalne veze, a kodomen funkcionalne veze – tip vlasnika te cfunkcionalne veze. Tako se naˇ primer u mreˇnom modelu moˇe izraziti pomo´u s z z c ˇtri tipa entiteta – IZDAVAC, KNJIGA i “veznog” tipa entiteta IZDAVASTVO, i ˇpomo´u dve imenovane funkcionalne veze: c ˇ IZDAJE SE: IZDAVASTVO → KNJIGA IZDAJE: ˇ IZDAVASTVO → IZDAVAC (slika 1.5).ˇ U mreˇnom SUBP IDMS definicija baze ukljuˇuje naziv baze, definiciju tipa z centiteta za svaki tip entiteta (u IDMS terminologiji – slog, RECORD) i definicijuimenovanog tipa veze za svaki tip veze (u terminologiji IDMS – skup, SET). Manipulisanje podacima u mreˇnim sistemima, sliˇno hijerarhijskim, procedu- z cralno je orijentisano i izvrˇava se paketno – operacijama umetnutim u programski s
  20. 20. 1.1 O modelima podataka 13 KNJIGA ˇ IZDAVAC IZDAJE SE IZDAJE c c ˇ IZDAVASTVO Slika 1.5: Imenovane funkcionalne veze – skupovi u mreˇnom modelu zjezik opˇte namene, npr. COBOL. Pri tome sintaksa operacija omogu´uje pre- s c ˇ ˇcizno navodenje puta kojim se pristupa pojedinom slogu, ukljuˇuju´i navodenje c cskupa, vlasnika skupa, prvog, slede´eg, poslednjeg ˇlana skupa za datog vlasnika, c citd. Tako bi se zahtev za nalaˇenjem prve knjige – romana izdavaˇa ’Prosveta’ z c z c ˇizrazio proceduralno, prvo nalaˇenjem prvog ˇlana (IZDAVASTVO) skupa IZDAJEu kome je izdavaˇ ’Prosveta’ vlasnik, zatim pronalaˇenjem vlasnika (KNJIGA) c z c c ˇskupa IZDAJE SE ˇiji je ˇlan – slog naden u prvom koraku i, najzad, ponavljanjem ˇprethodna dva koraka sve dok se ne dode do primerka sloga KNJIGA koji je roman.Izraˇen pojednostavljenom sintaksom, ovaj zahtev ima slede´i oblik: z c MOVE ’Prosveta’ TO NAZIV IN IZDAVAC FIND IZDAVAC FIND FIRST IZDAVASTVO WITHIN IZDAJE PERFORM FIND OWNER WITHIN IZDAJE SE GET KNJIGA IF OBLAST IN KNJIGA = ’roman’ izdati NASLOV teku´eg sloga KNJIGA; c iza´i iz PERFORM petlje c END-IF FIND NEXT IZDAVASTVO WITHIN IZDAJE END-PERFORM Hijerarhijski i mreˇni model ne ostvaruju nezavisnost nivoa predstavljanja po- zdataka ANSI arhitekture. Na logiˇkom nivou prisutna je velika koliˇina informacija c co fiziˇkoj reprezentaciji i grupisanju podataka. Nasuprot njima, relacioni model po- c ˇdataka na logiˇkom nivou predstavlja i entitete i odnose medu njima na jedinstven cnaˇin – relacijama tabelarnog izgleda. Jezik za definisanje podataka i manipulisanje cpodacima je neproceduralan i ne ukljuˇuje informaciju o putu kojim se fiziˇki pris- c ctupa podacima. Tako bi se entiteti i odnosi iz prethodnog primera u relacionommodelu prikazali pomo´u tri tabele: c KNJIGA (K SIF, NASLOV, OBLAST) IZDAVAC (I SIF, NAZIV, STATUS, DRZAVA)
  21. 21. 14 1 Relacioni model podataka IZDAVASTVO (I SIF, K SIF, GODINA, TIRAZ)a zahtev za nalaˇenjem svih romana izdavaˇa ’Prosveta’ izrazio bi se relacionim z cjezikom, na primer SQL-om, na slede´i naˇin: c c SELECT NASLOV FROM KNJIGA, IZDAVAC, IZDAVASTVO WHERE OBLAST = ’roman’ AND KNJIGA.K SIF = IZDAVASTVO.K SIF AND NAZIV = ’Prosveta’ AND IZDAVAC.I SIF = IZDAVASTVO.I SIF ˇ Redosled navodenja relacija u FROM liniji je nebitan jer sve relacije imaju ˇravnopravan tretman; isto vaˇi i za redosled poredenja u WHERE liniji. Prethodni zrelacioni iskaz moˇe se izvrˇavati i interaktivno i u okviru aplikativnog programa. z s Za izlaganje najznaˇajnijih aspekata sistema baza podataka koristi´e se rela- c ccioni model. Razlozi za ovaj izbor mogu se naslutiti iz prethodnog primera, a upotpunosti se mogu sagledati tek detaljnim upoznavanjem svih modela (v. [22]).Ti razlozi su mnogobrojni i prirodni, i nalaze se u svim bitnim karakteristikama ˇrelacionog modela. Najvaˇnije medu njima su: z • strukturna jednostavnost • formalno i strogo zasnivanje • ekonomiˇni upitni jezici c • razgraniˇenje nivoa predstavljanja podataka. c Relacioni model ´e biti izloˇen u narednim odeljcima u verziji koja je posluˇila c z zkao osnov za kasnija proˇirenja (RM/T, RM/2), i koju je autor relacionog modela sEdgar Codd (Edgar Kˆd) prikazao u [18], [19]. o1.2 Strukturni deo relacionog modelaDva osnovna tipa objekata koji karakteriˇu strukturu relacionog modela su domen si relacija. Domen je skup vrednosti istog tipa, kao ˇto je skup naslova knjiga, skup s ˇimena gradova ili skup datuma nekih dogadaja. Domen je jednostavan ako su musve vrednosti atomiˇne, tj. ako SUBP ne moˇe da ih razloˇi u komponente sa c z zspecifiˇnim znaˇenjem; u suprotnom, domen je kompozitan. U daljem tekstu ´e se c c cpodrazumevati da su svi domeni jednostavni (osim ako se naglasi drugaˇije).c Neka su D1 , D2 , . . . , Dn (n ∈ N) domeni (ne obavezno razliˇiti). Dekartov cproizvod tih domena, u oznaci D1 ×D2 ×· · ·× Dn , jeste skup n-torki (v1 , v2 , . . . , vn )takvih da je vi ∈ Di za sve i = 1, 2, . . . , n. Relacija R stepena n, definisana nadomenima D1 , D2 , . . . , Dn , je proizvoljni konaˇni podskup navedenog Dekartovog cproizvoda. Ova relacija, za razliku od matematiˇkog pojma relacije, je dinamiˇkog c c
  22. 22. 1.2 Strukturni deo relacionog modela 15sadrˇaja, jer se neke njene n-torke1 tokom “ˇivota” relacije briˇu, neke se dodaju z z sa neke se menjaju. Ako se umesto skupa indeksa domenˆ {1, 2, . . . , n} uzme proizvoljni skup (ra- azliˇitih) imenovanih indeksa {A1 , A2 , . . . , An }, onda je svaki element vi n-torke crelacije R karakterisan ne samo domenom Di ve´ i indeksom Ai . Razliˇiti imeno- c cvani indeksi Ai (i = 1, 2, . . . , n) zovu se atributi relacije R i oznaˇavaju razliˇite c c z c ˇuloge (ne nuˇno razliˇitih) domena nad kojima je izgradena relacija R. Sada sesvaka n-torka relacije R moˇe posmatrati kao skup n parova (Ai , vi ), i = 1, 2, . . . , n, zgde je vi vrednost iz domena Di . Relacijom R predstavlja se neki tip entiteta E, dok se n-torkama relacije Rpredstavljaju pojedinaˇni entiteti tipa E. Zato se svaki atribut Ai relacije R moˇe c zinterpretirati kao preslikavanje tipa entiteta E u odgovaraju´i domen Di , tj. c Ai : E → Di . Sliˇno, svaki podskup {Ai1 , Ai2 , . . . , Aik } skupa atributa relacije R moˇe se in- c zterpretirati kao preslikavanje (Ai1 , Ai2 , . . . , Aik ) : E → Di1 × Di2 · · · × Dik . Mada je skup Di kodomen preslikavanja (tj. atributa) Ai , u terminologiji rela-cionog modela on se zove domen atributa Ai , ˇto se oznaˇava sa dom(Ai ). Sliˇno, s c csa dom(Ai1 , Ai2 , . . . , Aik ) oznaˇava se domen skupa atributa {Ai1 , Ai2 , . . . , Aik }, tj. cskup Di1 × Di2 · · · × Dik . Neka je e entitet tipa E. Tada je element vi ∈ Di vrednost atributa Ai entitetae (tj. odgovaraju´e n-torke) ako je Ai (e) = vi . Sliˇno, element (vi1 , vi2 , . . . , vik ) ∈ c cDi1 × Di2 · · · × Dik je vrednost skupa atributa {Ai1 , Ai2 , . . . , Aik } entiteta e (tj.odgovaraju´e n-torke) ako je (Ai1 , Ai2 , . . . , Aik )(e) = (vi1 , vi2 , . . . , vik ). c Ako su svi domeni atributa relacije R jednostavni, onda relacija R ima tabelarniizgled i nalazi se u prvoj normalnoj formi, u oznaci 1NF, tj. normalizovanaje (o viˇim normalnim formama bi´e reˇi u delu o logiˇkom projektovanju baze s c c cpodataka). Kolone tabele odgovaraju atributima relacije, a vrste – n-torkamarelacije.2 Takva tabela ima slede´e karakteristike: c – nema dupliranih vrsta (jer je relacija skup) – redosled vrsta je nebitan (jer je relacija skup) – redosled kolona je nebitan (jer atributi relacije ˇine skup) c – sve vrednosti u tabeli su atomiˇne. c 1 Kada je iz konteksta jasno kojoj relaciji pripada neka n-torka, ili kada to nije od znaˇaja, cn-torka ´e se jednostavno zvati torka; pri tome se za dimenziju torke uzima stepen odgovaraju´e c crelacije. 2 U daljem tekstu parovi termina relacija/tabela, atribut/kolona i n-torka/vrsta upotrebljava´e cse kao sinonimi; uobiˇajeno je da se u razmatranju samog relacionog modela upotrebljavaju prve ckomponente ovih parova, a u kontekstu implementacija relacionog modela – druge.
  23. 23. 16 1 Relacioni model podatakaOznaka R(A1 : D1 , A2 : D2 , . . . , An : Dn ) koristi se za predstavljanje relacije Rˇiji atribut A1 uzima vrednost iz domena D1 , atribut A2 iz domena D2 , itd. iczove se relacijska shema relacije R. Kada je jasno o kojim se domenima radi, ilikada domeni (odnosno atributi) nisu bitni za izlaganje, za relaciju R upotrebljavase oznaka R(A1 , A2 , . . . , An ) (odnosno samo R). Umesto oznake za nabrajanjeatributa R(A1 , A2 , . . . , An ), ˇesto se, u identiˇnom znaˇenju, koristi i oznaka sa c c c ˇdopisivanjem atributa, R(A1 A2 . . . An ). Takode, ako su od znaˇaja dva istaknuta cdisjunktna podskupa X, Y skupa atributa relacije R (ˇija je unija jednaka celom cskupu), ona se obeleˇava i sa R(X, Y ). z Relaciona baza podataka je skup skupova podataka koji se na logiˇkom nivou cmogu posmatrati kao normalizovane relacije odgovaraju´ih stepena i dinamiˇkog c csadrˇaja. Skup relacijskih shema relacione baze podataka je shema relacione baze zpodataka. Bazne relacije su relacije koje su definisane nezavisno od drugih relacija ubazi podataka, i koje se ne mogu izvesti iz drugih baznih relacija. One su na fiziˇkom cnivou predstavljene odgovaraju´im strukturama podataka. Izvedene relacije su crelacije koje se mogu izvesti iz baznih relacija primenom skupa operacija. Oneobiˇno nemaju fiziˇku reprezentaciju, i predstavljaju razliˇite poglede koje razni c c ckorisnici mogu imati na istu bazu podataka. Neke druge definicije relacionog modela ne ukljuˇuju pojam domena u osnovne c ˇtipove objekata strukture relacionog modela. Medutim, ovaj pojam ima svoj ope- c s ˇracioni znaˇaj u tome ˇto domeni odreduju skup operacija koje se nad njihovimvrednostima mogu izvrˇavati. Tako se vrednosti atributa nad istim domenima smogu porediti (a vrednosti atributa nad razliˇitim domenima ne mogu), pa se nad catributima, definisanim nad istim domenima, mogu izvrˇavati i sve operacije koje s ˇukljuˇuju poredenje. Ve´ina upitnih jezika, kao ˇto je SQL, ne poznaje semantiˇki c c s caspekt domena, pa je mogu´e, na primer, postavljati upite kojima se porede naslovi cknjiga sa imenima drˇava (kao niske simbola). z Sva naredna razmatranja bi´e ilustrovana jednom aproksimacijom izdavaˇke c crelacione baze sa slede´om shemom: cP (P SIF, IME, BR NASLOVA, DRZAVA)I (I SIF, NAZIV, STATUS, DRZAVA)K (K SIF, NASLOV, OBLAST)KP (K SIF, P SIF, R BROJ)KI (K SIF, I SIF, IZDANJE, GODINA, TIRAZ) ˇ Prve tri relacije predstavljaju tipove entiteta PISAC, IZDAVAC i KNJIGA re-dom, i imaju sliˇnu strukturu kao i odgovaraju´i tipovi entiteta. Nov je prvi atribut c cu svakoj od relacija, koji predstavlja ˇifru, tj. jedinstveni identifikator pisca, iz- sdavaˇa i knjige. Na primer, ˇifra knjige, K SIF, moˇe biti ISBN (International c s zStandard Book Number), P SIF i I SIF mogu biti matiˇni broj pisca i izdavaˇa, c credom. Relacija KP predstavlja apstraktni tip entiteta AUTOR, tj. odnos izmedu ˇtipova entiteta KNJIGA i PISAC, dok relacija KI predstavlja apstraktni tip entiteta ˇ ˇIZDAVASTVO, tj. odnos izmedu tipova entiteta KNJIGA i IZDAVAC. ˇ
  24. 24. 1.2 Strukturni deo relacionog modela 17 Neka je sadrˇaj3 tih relacija (koji ´e se podrazumevati u svim primerima) slede´i: z c c P P SIF IME BR NASLOVA DRZAVA p1 ´ c B.Copi´ 2 Jugoslavija p2 M.Benson 1 Engleska p3 ˇ c ˇ sc B.Sljivi´-Simˇi´ 1 Jugoslavija p4 D.Maksimovi´ c 2 Jugoslavija p5 C.J.Date 1 Amerika I I SIF NAZIV STATUS DRZAVA i1 Prosveta 30 Jugoslavija i2 Addison Wesley Publ. Comp. 20 Amerika i3 Deˇje novine c 10 Jugoslavija i4 Matica srpska 30 Jugoslavija K K SIF NASLOV OBLAST k1 Osma ofanziva roman k2 Nemam viˇe vremena s poezija k3 Pionirska trilogija roman k4 Srpskohrvatsko-engleski reˇnik c leksikografija k5 An Introduction to Database Systems raˇunarstvo c k6 Traˇim pomilovanje z poezija KP K SIF P SIF R BROJ k1 p1 1 k2 p4 1 k3 p1 1 k4 p2 1 k4 p3 2 k5 p5 1 k6 p4 1 KI K SIF I SIF IZDANJE GODINA TIRAZ k1 i1 2 1965 10000 k2 i1 2 1974 7000 k3 i1 1 1975 10000 k4 i1 2 1979 10000 k5 i2 4 1986 5000 k6 i3 1 1966 3000 k6 i4 3 1988 5000 3 Stvarni sadrˇaj ukljuˇio bi samo simbole iz dopuˇtenog skupa. z c s
  25. 25. 18 1 Relacioni model podataka1.3 Manipulativni deo relacionog modelaManipulativni deo relacionog modela predstavlja formalizam za definisanje rela-cionog izraza opˇteg oblika, ˇija je vrednost proizvoljni podskup skupa podataka iz s cbaze. Definicija relacionog modela ukljuˇuje dva formalna jezika za rad sa relacijama, ckoja imaju traˇeno svojstvo: jedan algebarski u suˇtini – relaciona algebra, i drugi, z szasnovan na predikatskom raˇunu prvog reda – relacioni raˇun ([14]). Dokazana je c cekvivalentnost ovih formalizama u pogledu izraˇajne mo´i ([17]). Sami formalizmi z ckao i skica dokaza njihove ekvivalentnosti bi´e izloˇeni u slede´oj glavi. Da bismo c z cilustrovali mogu´nosti ovih formalizama, ovde ´emo samo neformalno uvesti pojam c crelacione algebre. Relaciona algebra je skup operacija nad relacijama. Relacioni izraz u relacionoj c ˇalgebri sastoji se od niza operacija nad odgovaraju´im relacijama. Medu vaˇnijim zoperacijama relacione algebre su projekcija, restrikcija i prirodno spajanje (slika1.6, [27]): • neka je X podskup skupa atributa relacije R; projekcija R[X] relacije R na atribute X je relacija koja sadrˇi (samo) kolone relacije R koje odgovaraju z atributima X (v. i taˇku 2.1.1); c • restrikcija R[X = x], za x ∈ dom(X), jeste relacija koja sadrˇi (samo) n-torke z relacije R ˇija je vrednost skupa atributa X jednaka x (v. i taˇku 2.1.1); c c • prirodno spajanje R ∗ S je dopisivanje torki relacije S na torke relacije R ako imaju iste vrednosti na zajedniˇkim atributima, uz eliminaciju po jednog c atributa iz svakog para zajedniˇkih atributa (v. i taˇku 2.1.2). c c Mada se operacije relacione algebre definiˇu nad relacijama, one se primenjuju i sna pojedinaˇne n-torke, jer su i n-torke – (jednoˇlane) relacije; na primer, projekcija c cn-torke (v1 , v2 , . . . , vn ) na prva dva atributa (A1 , A2 ) je (v1 , v2 , . . . , vn )[A1 A2 ] =(v1 , v2 ) (v. i taˇke 2.1.1, 2.1.2). c Specifiˇni sistemi relacionih baza podataka (kra´e – relacioni sistemi) imple- c cmentiraju manipulativni deo relacionog modela relacionim jezicima za definisanjepodataka i manipulisanje podacima, specifiˇne sintakse. Da bi jezik za definisanje cpodataka bio relacioni, mora da ima konstrukcije za definisanje osnovnih koncepatastrukture relacionog modela (ali i pravila integriteta, opˇtih i eventualno posebnih, sv. odeljak 1.4). Da bi jezik za manipulisanje podacima bio relacioni, mora dabude relaciono kompletan, tj. da ima izraˇajnu mo´ bar kolika je izraˇajna mo´ z c z crelacionog raˇuna ili relacione algebre. Osim toga, jezik za manipulisanje podacima cjednog relacionog sistema mora da ima joˇ neka svojstva. Naime, formalizam rela- scionog modela ima mogu´nost pretraˇivanja podataka, tj. pronalaˇenja podataka c z zkoji predstavljaju vrednost relacionog izraza. Pored ove mogu´nosti, relacioni jezik ctreba da omogu´i i aˇuriranje podataka u najˇirem smislu, tj. unoˇenje novih i c z s sbrisanje i izmenu postoje´ih podataka u bazi. Zahtev za pretraˇivanjem zove se c zupit, dok se zahtev za aˇuriranjem zove radnja. z
  26. 26. 1.3 Manipulativni deo relacionog modela 19 projekcija restrikcija prirodno spajanje ¨ B rr ¨¨ T r j a1 b1 b1 c1 a1 b1 c1 a2 b1 b2 c2 a2 b1 c1 a3 b2 b3 c3 a3 b2 c2 Slika 1.6: Operacije projekcije, restrikcije i prirodnog spajanja Jezik za definisanje podataka i jezik za manipulisanje podacima zajedno ˇine cupitni jezik . Osnova za izgradnju upitnog jezika, s obzirom na potrebu za njegovomrelacionom kompletnoˇ´u, uvek leˇi u jednom od pomenutih formalizama. sc z1.3.1 Nedostaju´e vrednosti cU bazi podataka moˇe postojati potreba za registrovanjem semantiˇki razliˇitih z c cvrsta nedostaju´ih vrednosti, kao ˇto su trenutno nepoznata vrednost (npr. status c sizdavaˇa), ili neprimenljivo svojstvo (npr. vrednost atributa IME SUPRUZNIKA c ˇza osobu koja nije u braku). Semantika nedostaju´e vrednosti moˇe biti i drugaˇija c z c([46]) (npr. nepoznata vrednost koja je u poznatom intervalu), ali se prve dvenavedene vrste semantiˇki najviˇe razlikuju i najˇeˇ´e pojavljuju u realnosti. c s c sc Da bi se relacioni model proˇirio ovim dvema vrstama nedostaju´ih vrednosti, s c ˇneophodno je definisati proˇirene relacije poredenja nad vrednostima iz domena i srazliˇitim nedostaju´im vrednostima, kao i proˇirene relacije pripadnosti skupu i c c s ˇinkluzije. Rezultat poredenja sada moˇe biti, osim taˇno ili netaˇno, i drugaˇije z c c cokvalifikovan (npr. ’ne zna se’, ’moˇda’, itd). Tako se dolazi do viˇevalentnih logika z su relacionom modelu. Kako se definicije operacija relacione algebre baziraju na ˇ ˇporedenju vrednosti atributa n-torki, a rezultat tog poredenja moˇe biti taˇan, z cnetaˇan ili ’moˇda’, potrebno je za svaku operaciju relacione algebre definisati viˇe c z sod jedne operacije u proˇirenom modelu. Pored toga, i ostali koncepti relacionog s ˇmodela koji su bazirani na poredenju vrednosti (npr. funkcionalne, viˇeznaˇne s czavisnosti) dobijaju kompleksniju formu, ˇto dosta usloˇnjava sam model. Stoga po- s zstoje´i sistemi za upravljanje bazama podataka, ako uopˇte podrˇavaju nedostaju´e c s z cvrednosti, podrˇavaju samo jednu vrstu takve vrednosti. Jedno proˇirenje relacione z salgebre kao osnove za upitne jezike koji manipuliˇu i nedostaju´im vrednostima dao s cje Codd u radu [18]; ovo proˇirenje bi´e izloˇeno u taˇki 2.1.3 – Proˇirena relaciona s c z c salgebra.

×