zeljo_seminarskirad1

Embed Size (px)

Citation preview

UNIVERZITET APEIRON FAKULTET INFORMACIONIH TEHNOLOGIJA BANJA LUKA Vanredne studije Smjer Nastavnika informatika

Predmet RDBMS (SQL administracija & CASE alati)

RELACIONi MODEL BAZa PODATAKA (seminarski rad)

Predmetni nastavnik Prof. dr Zoran . Avramovi, dipl.in.elek.

Student

Saa BlagojeviIndex br. 83/11

Banja Luka, decembar 2011.

Sadraj

1. 2. 2.1. 2.2. 2.3. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12. 3.13. 3.14. 3.15. 4. 5.

Uvod............................................................................................................................. ta je baza podataka ?.................................................................................................. Organizacija podataka.................................................................................................. Kreiranje baze podataka............................................................................................... PRISTUPI BAZAMA PODATAKA- programski jezici (sredstva)............................ Relacioni model baza podataka.................................................................................... Nastanak i razvoj relacionog modela baze podataka................................................... Relacioni sistem za upravljane bazama podataka........................................................ Relaciona Algebra........................................................................................................ Predstavljanje podataka................................................................................................ Pristup podacima.......................................................................................................... Sistemski tretman NULL vrijednosti........................................................................ Neprekidan pristup dinamikom katalogu relacionog modela..................................... Sveobuhvatan jezik za rad sa podacima....................................................................... Auriranje pogleda....................................................................................................... Dodavanje, brisanje i modifikovanje na visokom nivou.............................................. Fizika nezavisnost...................................................................................................... Logika nezavisnost..................................................................................................... Integritetska nezavisnost.............................................................................................. Distribuciona nezavisnost............................................................................................ Rad sa jezicima niskog nivoa....................................................................................... Zakljuak..................................................................................................................... Literatura.....................................................................................................................

1 2 3 4 5 6 11 12 15

1. UvodOd samog poetka koritenja raunara, obrada razliitih vrsta podataka, bila je jedan od osnovnih zadataka. Podaci i informacije su postali pokretaka snaga modernog poslovanja na 2

Zapadu pa i u cijelom svijetu. Kada elimo da imamo kvalitetne informacije o svim segmentima naeg poslovnog ili ak i privatnog ivota najbolje je da na odreeni nain organizujemo sve podatke koje mogu da nam prue informacije koje su od velike vanosti u trenutku kada su nam potrebne, pogotovo se to odnosi na situacije kada u kratkom roku moramo donijeti neku kvalitetnu ili sudbonosnu odluku. Tada bi bilo najbolje da podaci za svaki pojedini element budu organizovani tako da se mogu smjestiti u tabele sa istovrsnim zaglavljem. Moe, a veoma esto i mora da bude vie tabela koje bi obuhvatili sve segmente naeg interesovanja. Svi ti segmenti se nerijetko zbog svoje prirode moraju organizirati u posebne tabele, a te tabele se mogu povezivati preko odreenih zajednikih elemenata. Skup vie tih tabela koje slue jednom zajednikom cilju, skupa sa njihovim veznim elelmentima naziva se BAZOM PODATAKA. Njihov zajedniki cilj se odnosi na svoenje veoma brze i uspjene infrormacije o svim dogaajima koji se deavaju unutar jedne cjeline. Kada kucamo neto u Wordu, vrimo neke tabelarne proraune u Exelu u vie tabela onda imamo dodira sa bazom podataka. To je u svari pitanje organizacije naih podataka. Ako ispisujemo datoteke u Wordu i smjetamo ih po odreenim direktorijima na neki nain organizujemo bazu podataka. U sluaju kada naa baza postane toliko komplikovana da nismo vie u stanju da jednostavno kontroliemo tok i razvoj podataka potrebno je prei na vii stepen organizacije podataka i poeti razmiljati o sistemu za upravljanje bazom podataka. Postoji vie sistema za rad sa bazama podataka kao to su: DBMS, ACCESS, FOXPRO, ORACLE, MICROSOFT SQL, DB2, XM.

2. ta je baza podataka ?Jednostavno reeno, BAZA PODATAKA je softverska konstrukcija namjenjena za pohranjivanje, analizu i pretraivanje grupe srodnih i povezanih podataka, kao to su podaci o kupcima, pacijentima, telefonskim brojevima i sl.

3

Baza podataka sastoji se od jedne ili vie (dvodimenzionalnih) tabela koje meusobno mogu biti povezane. Svaka tabela uva istovrsne podatke (npr. podatke o nekoj osobi, predmetu i sl.). Svaki red u tabeli predstavlja jedan slog u tabeli (najmanja grupa podataka u bazi koja u potpunosti opisuje neki od koncepata koje baza modelira), a svaka kolona jedno od polja unutar tog sloga. Dakle, slog moe biti grupa podataka koja opisuje npr. neku osobu, a polja unutar tog sloga mogu sadravati ime, prezime, adresu stanovanja ili datum roenja te osobe. Slog se u literaturi jo ponegdje naziva i entitet, a polje se naziva atribut. Svaki slog tabele se moe jedinstveno identificirati putem jedne ili kombinacijom vrijednosti nekog od polja tog sloga. To polje ili kombinaciju polja tada nazivamo primarni dio ili osnovni klju. Tako neku osobu moe jedinstveno identifikovati njen matini broj ili kombinacija vrijednosti polja imena i prezimena. U jednoj tabeli moe postojati vie polja ili kombinacija polja koji mogu biti kao primarni klju. Pored toga to primarni klju ima ulogu jedinstvenog identificiranja sloga on igra ulogu i u povezivanju tabela. Uzmimo da naa tabela ustvari predstavlja listu pisaca. Pored te tabela imamo i listu knjiga, te je potrebno ove dvije tabele povezati kako bi smo znali koji je pisac napisao koju knjigu. Ako u slog knjige ubacimo polje koje sadri vrijednost primarnog kljua pisca, ove dvije tabele su povezane. Ovo novo polje (koje iskljuivo slui za povezivanje dvije tabele) u tabeli se zove strani klju. Ovakav nain povezivanje podataka nazivamo relacioni model baza podataka.

2.1. Organizacija podataka

4

Organizacija podataka je od veoma velikog znaaja kada elimo raditi sa bazom podataka. Jedan od kljunih aspekata, dobrog kreiranja baze podataka jeste kako e podaci biti organizovani u bazi podataka. Da bi postigli dobro kreiranu bazu podataka, podatke bi trebalo organizovati tako da su lako dostupni i da omoguavaju lako odravanje baze podataka. Treba odrediti koji e podaci ulaziti u bazu podataka, zatim koji e se podaci smjestiti u odreene tabele meu kojima e biti uspostavljen odnos, te kakav je odnos meu tim podacima. Potrebno je smanjiti mogunost koliko je mogue da se isti podatak zapisuje vie puta (redundacija), jer viestrukim zapisivanjem nastaju problemi ouvanja stvarne, jedinstvene vrijednosti svih podataka pri auriranju. To utie i na pouzdanost informacija koje se dobiju iz tih podataka. Potrebno je upravljati smjetanjem podataka i ouvanja tih podataka od namjernih i nenamjernih unitenja tj. da ne doe do gubitka integriteta podataka. Neke podatke treba zatititi od toga da ih neovlateni korisnici ne mijenjaju to se zove tajnost ili privatnost podataka.

2.2. Kreiranje baze podataka

5

U svakodnevnom ivotu da bi poeli neto praviti, kreirati potrebno je da unaprijed odredimo dizajn, nacrt. Ako hoemo da pripremimo neko jelo, potreban nam je recept, ako hoemo graditi kuu potreban nam je nacrt kako e izgledati i sl. Pri kreiranju baze podataka, takoer prethodno trebamo organizovati podatke, odrediti ciljeve. Ciljevi dizajniranja/kreiranja: eliminisati suvine podatke omoguiti brzo pronalaenje pojedinani podataka sauvati jednostavno odravanje baze podataka

Kljune aktivnosti pri kreiranju baze podataka su: Modeliranje aplikacije Definisanje podataka neophodnih za aplikaciju Organizovanje podataka u tabelama Uspostavljanje meusobnih veza izmeu tabela Uspostavljanje zahtjeva indeksiranja i vrednovanja podataka Izrada i snimanje svih potrebnih upita u vezi sa aplikacijama Modeliranje aplikacije se odnosi na postupak pri kojem definiemo zadatke koje aplikacija treba da obavi. Bilo bi dobro da definisane zadatke specifikujemo u odreeni dokument koji nam moe pomoi da budemo usredsreeni na zadatak naeg programa. Prilikom organizovanja podataka u tabele moemo lako odrediti da li neki podatak pripada toj tabeli ili ne; npr. ako neki klub eli da prati informacije o svojim lanovima i zaposlenima, uprava kluba e u jednu tabelu staviti i zaposlene i lanove. Obje grupe zahtjevaju informaciju o imenu, adresi, telefonskom broju, dok zaposleni zhtjevaju i informacije o broju socjialnog osiguranja, visini plate i sl. Ali ako napravimo vie tabela gdje se svaki podatak pojavljuje samo jednom i mi emo prilikom izmjena novu informaciju upisivati samo jednom.

6

Drugi nain da se podaci normalizuju jeste da se formira tzv. tabela dijete. Tabela dijete je tabela u kojoj svi unijeti podaci dijele zajedniku informaciju koja je smjetena u nekoj drugoj tabeli. Ako uzmemo za primjer neku porodicu gdje su kod svih ista prezimena, ista adresa, isti br. telefona, a razliita imena, njihove zajednike podatke stavimo u jednu tabelu, a imena u drugu u tom sluaju tabela koja sadri imena lanova je tabela dijete. Tabela pretraivanja je jo jedan pristup smjetaju informacija s ciljem sprjeavanja pojave suvinih informacija i poveanje tanosti unoenja podataka. Ona se obino koristi za smjetaj optevaeih ulaznih podataka. Kada neko u toku aplikacije unese takvu oznaku, program provjerava u odgovarajuoj tabeli da li ta oznaka stvarno postoji. Kada normalizujemo podatke, meusobno povezane informacije obino smjetamo u nekoliko tabela. Meutim, kada je potrebno da pristupimo podacima elimo da vidimo informacije iz svih tabela na jednom mjestu. Da bismo to postigli moramo formirati skupove zapisa koji objedinjuju meusobno povezane informacije iz nekoliko tabela. Taj skup zapisa se formira upotrebom SQL naredbe u kojoj navodimo eljena polja, lokacije polja i odnos izmeu tabela i te naredbe moemo smjestiti kao upit u bazu podataka. Upotreba upita ima nekoliko prednosti: premjetanje aplikacije u server okruenje je jednostavnije, unoenje izmjena u SQL naredbu je jednostavnije, SQL naredbu moemo lake koristiti na vie mjesta u programu ili u vie programa.

Ovi upiti rade bre od upita koji se izrauju zadavanjem naredbe programa koda. Dobro kreirana baza podataka omoguava: minimalno vrijeme potrebno za pronalaenje zapisa smjetanje podataka na najefikasniji nain tako da baza ne postane suvie velika najjednostavnije auriranje podataka zahvaljujui svojoj fleksibilnosti ukljuivanje novih funkcija koje bi se od programa mogle zahtjevati

2.3. Pristupi bazama podataka- programski jezici (sredstva)

7

SQL omoguava puni pristup podacima u relacionim bazama podataka (kao to su: Oracle, SQL Server, Acces, i dr.) tako to korisnik opie podatke koje eli da vidi. SQL omoguava i definisanje i modifikaciju izgleda tabela unutar baze podataka. Niti jedna operacija na bazama podataka, izvrena direktno iz DBMS-a ili preko korisnike aplikacije, nebi mogla biti izvrena bez direktne ili indirektne upotrebe SQL jezika. esto, sam SQL nije dovoljan ukoliko je potrebno izvriti neki upit u tano odreeno vrijeme ili ga ponoviti nekoliko puta. Zbog toga svaki DBMS pored SQL podrava bar jo jedan programski jezik pomou kojeg se mogu izvriti kompleksne operacije. Dakle, postoje jo neki programski jezici (sredstva) za pristup podacima koji se nazivaju Database API, a to su: ODBC, OLE DB, JDBC, DAO, ADO ODBC pomou njega programeri mogu raditi sa tabelarnim podacima, kao to su SQL baze podataka ili sa multidimenzionalnim podacima, kao to je OLAP kocke. Aplikacije za upravljanje bazama podataka pozivaju funkcije u OBDC-u, a ODBC putem svojih drajvera za baze podataka, aplikaciji vraa podatke iz baze. OLE DB se pojavio kao odgovor problemu pristupanja komleksnije organizacije podataka , kao to su tekst fajlovi, e- mail sistemi i dr. To je nova verzija ODBC-a. JDBC je ekvivalent ODBC tehnologije namjenjen upotrebi prilikom razvoja aplikacija DAO se javlja kao rjeenje u pravljenju objektnog modela za pristup bazi podataka koji spreava da doe do eventualnih greaka pri programiranju ODBC, OLE DB i JDBC. On je sastavni dio Visual Basica. Slui za pristup MS Access bazama podataka. DAO takoer omoguava pristup ODBC izvorima podataka i tu lei i njegov najvei nedostatak. Poto se oslanja na Access, prilikom pristupa ODBC bazama podataka sve naredbe za bazu podataka i svi podaci iz nje moraju proi kroz ovaj dodatni sloj, to moe znatno ugroziti performanse aplikacije. ADO nova tehnologija iz Mikrosofta iji je cilj da zamijeni DAO kao standardni objektni model za pristup bazama podataka.

3.0. Relacioni model baza podataka

8

Arhitektura najveeg broja sistema baza podataka odgovara predlogu ANSI/SPARC studijske grupe Amerikog nacionalnog instituta za standarde, i poznata je kao ANSI arhitektura. Ova arhitektura predstavljena je hijerarhijom apstrakcija, pri emu svaki nivo hijerarhije ukljuuje specifini nain predstavljanja, reprezentaciju, objekata, odnosa meu objektima i operacija nad objektima. Hijerarhijska arhitektura omoguuje prirodnu dekompoziciju i efikasni razvoj sistema za upravljanje bazama podataka. Najnii nivo ANSI arhitekture je unutranji nivo. On je najblii fizikoj reprezentaciji baze podataka, koja u raunarskom sistemu jedina zaista postoji. Zbog toga se unutranji nivo esto i zove nivo fizike baze podataka. Sledei nivo ANSI arhitekture je konceptualni (logiki) i predstavlja nain na koji se podaci iz fizike baze podataka predstavljaju korisniku u optem sluaju. Najvii nivo ANSI arhitekture je spoljanji nivo koji predstavu o podacima iz baze prilagoava potrebama specifinih korisnika ili grupa korisnika. Globalna ANSI arhitektura sistema baza podataka moe se predstaviti shemom na slici 1.1.

Slika 1.1.

Reprezentacija koja se nalazi na srednjem, konceptualnom nivou ANSI hijerarhije zove se model podataka. Modelom podataka predstavlja se logika struktura svih podataka u bazi i skup operacija koje korisnik moe izvriti nad tim podacima. To znai da se na konceptualnom nivou mogu vidjeti svi podaci iz fizike baze podataka, samo to je njihova reprezentacija pogodnija za korisnika od fizike (na viem je nivou apstrakcije). 9

Pojedini korisnici ili grupe korisnika mogu imati svoja sopstvena specifina gledanja na model podataka (npr. iz razloga zatite ili udobnosti), pa se pogledi (podmodeli, spoljanji nivo hijerarhije) nalaze iznad modela u hijerarhiji apstrakcija. Isti podaci iz fizike baze podataka (i sa konceptualnog nivoa), na ovom nivou mogu se raznim korisnicima predstaviti na razne naine, dok se postojanje nekih podataka moe od nekih korisnika i sakriti. Zato postoji tano jedan model podataka u sistemu, koji se odnosi na cjelokupnost baze podataka, i vei broj spoljanjih pogleda, od kojih se svaki sastoji od apstraktne slike dijela baze podataka. Na primjer, baza podataka o studentima moe da sadri podatke iz dosijea studenata, sa linim podacima i podacima o uspjehu (predmetima, ocjenama, datumima polaganja, nagradama, kaznama) svakog studenta. Na konceptualnom nivou podaci mogu biti predstavljeni tabelama DOSIJE, NASTAVNI PLAN, NAGRADE I KAZNE i POLAGANJE. Na spoljanjem nivou, korisnicima statistikih obrada ova baza podataka moe se predstaviti kao da sadri samo podatke o uspjehu (npr. u virtuelnoj tabeli USPJEH PO PREDMETIMA); ostali, lini podaci koji mogu da identifikuju studenta, skrivaju se od statistikih aplikacija. Razliitim podgrupama korisnika mogu odgovarati jo apstraktnije predstave o podacima, koje odgovaraju viim nivoima podmodela. Primarni cilj modela podataka u kontekstu baza podataka jeste da obezbjedi formalni sistem za predstavljanje podataka i manipulisanje podacima u bazi podataka.

3.1. Nastanak i razvoj relacionog modela baze podataka10

Relaciona baza podataka se sastoji od serije dvodimenzionalnih tabela. Termin "relaciona baza podataka" dolazi od injenice da ona koristi relaciju (odnos) umjesto datoteke. Relacija je tabela sastavljena od slogova. Unutar jedne tabele moe postojati samo jedna vrsta slogova ili entiteta. Relacione tabele pokazuju logike, a ne fizike odnose, a zanemaruje redosljed podataka odnosno slogova ukljuenih u relaciju. Relacioni model odvaja bazu podataka od operativnog sistema kao i od aplikacije. Kada se da zahtjev za informacijama, sistem napravi tabelu koja sadri te informacije. Standardni programski jezik za izraavanje pristupa podacima i manipulaciju sa tabelama u relacionoj bazi podataka se naziva SQL (Structured Query Language). U ovom jeziku, pitanja na jednostavnom engleskom jeziku se automaski prevode u SQL. U ovom sluaju softverski program, koji se zove Natural language (prirodni jezik) i koji dozvoljava upite u ogranienoj formi prirodnog jezika, analizira korisnikov upit, prevodi ga u upit na SQL, prenosi SQL zahtjev DBMS-u i daje na displeju podatke korisniku. Relacioni model je smiljen poetkom osamdesetih godina od strane Ted Codda, uposlenika IBM korporacije i trenutno je najrairenija paradigma za razvoj podataka.

3.2. Relacioni sistem za upravljane bazama podataka11

Za realizaciju koncepta baze podataka pored odgovarajue hardverske opreme potrebno je obezbediti i programsku podrku (software), to jest zbirku programa koja predstavlja sistem za upravljanje bazom podataka (DBMS - Data Base Management System). DBMS u optem sluaju ima dvije osnovne funkcije. Prva je da memorie i odrava podatke koji izraavaju svojstva posmatranih objekata (entiteta). Ova funkcija se obavlja pomou jezika za definisanje podataka i strukturu podataka (DDL - Data Definition Language). Druga funkcija omoguava kontrolisan pristup do memorisanih podataka i prikazivanje podataka na zahtjev korisnika. Za sprovoenje ove funkcije koristi se jezik za manipulaciju podacima (DML - Data Manipulation Language). Baza podataka i aplikacije koje se na nju oslanjaju podloni su estim promjenama. Osim periodinih promjena izazvanih razvojem opreme (pojava monijih raunara, vee brzine, memorijskog kapaciteta i dr.), baza podataka izloena je promjenama korisnikih zahtjeva. Novi uslovi i pravila poslovanja reflektuju se ne samo na promjene parametara korisnikih programa aplikacija, ve i na promjene u fizikoj i logikoj strukturi baze podataka. DBMS ima ulogu da obezbjedi korisniku uvijek istu dostupnost podataka bez obzira na eventualne promjene. On poznaje fiziku i logiku strukturu baze na jednoj strani i zahtjeve korisnika programa na drugoj strani, to mu omoguava da djeluje kao specifian posrednik (interface). Relaciona baza podataka se svojom razvijenom teorijskom osnovom i jednostavnim izraavanjem odnosa izmeu podataka u obliku dvodimenzionalnih tabela, izdvojila u odnosu na druge baze podataka (hijerarhijske i mrene). U njoj su podaci prezentovani skupovima vremenski promenljivih relacija. Relacioni sistem za upravljanje bazom podataka (RDBMS - Relation Data Base Management System) omoguava obavljanje najrazliitijih operacija nad relacijama i kombinovanje relacija da bi korisniku obezbjedio odgovore na sva pitanja koja imaju smisla s obzirom na sadraj baze podataka. Osniva relacione teorije E.F.Codd, jo 1985. godine, definisao je 12 strogih pravila koja mora zadovoljiti RDBMS da bi s pravom nosio epitet relacioni. Osnovni princip na kojem se zasnivaju pravila glasi: Svaki sistem koji tvrdi da je relacioni sistem za upravljanje bazom podataka, ili se

12

tako reklamira, mora biti u mogunosti da u potpunosti upravlja bazom podataka svojim relacionim sposobnostima." Iako je od vremena definisanja pravila ,do danas, razvoj ovih sistema bio intenzivan, jo uvijek se na tritu softvera nije pojavio proizvod koji u potpunosti ispunjava svih 12 uslova. Osnovna komponenta sistema za upravljanje relacionim bazama podataka koju korisnik vidi jeste relacioni upitni jezik. To je sredstvo kojim korisnik ostvaruje komunikaciju sa relacionom bazom podataka, kojim izraava i zadovoljava sve zahtjeve vezane za podatke u bazi. Zato se, sa korisnike take gledita, upitni jezik esto identifikuje sa kompleksnim sistemom za upravljanje bazama podataka, koji u stvari te zahtjeve izvrava, korektno i efikasno. Sredstvo kojim sistem za upravljanje bazama podataka omoguuje veem broju korisnika istovremeni pristup podacima, uz punu bezbjednost i korektnost podataka, jeste transakcija. Transakcija je logika jedinica posla i moe da se sastoji od jedne ili veeg broja radnji nad bazom podataka, pri emu obezbeuje uslov da podaci i odnosi meu njima, poslije zavretka transakcije, korektno odraavaju realnost koja se tim podacima modelira. Upravljanje transakcijama omoguuje da se svi zahtjevi korisnika korektno izvravaju, a realizuje se posebnim komponentama koje koristi sistem za upravljanje bazama podataka. Funkcija SUBP kojom se reguliu prava pristupa pojedinih korisnika pojedinim objektima (podacima i drugim resursima), kao i prava izvrenja raznih operacija nad tim objektima, zove se autorizacija. Ona se dijelom realizuje mehanizmom pogleda, ali i specifinim podsistemom autorizacije i prava korisnika. Poseban znaaj u radu sa relacionim bazama podataka ima struktuiranje i organizacija samih podataka. Podatke je na nivou korisnika potrebno struktuirati, a na fizikom nivou organizovati tako da njihovo odravanje bude najlake, a operisanje njima najefikasnije. Skup postupaka kojima se dolazi do dobro struktuiranih podataka u bazi podataka naziva se metodama logikog projektovanja baze podataka. Skup postupaka kojima se podaci fiziki organizuju u bazi, tako da im je pristup i odravanje najefikasnije, naziva se metodama fizikog projektovanja, tj. metodama fizike organizacije podataka.

13

Znaajan segment relacione tehnologije predstavljaju distribuirane baze podataka. Mada su sistemi za upravljanje distribuiranim bazama podataka takoe relacioni, problemi koji se u njima moraju rjeavati, kao i metode za njihovo rjeavanje, znatno su sloeniji nego u centralizovanim sistemima

14

3.3.Relaciona AlgebraRelaciona algebra spada u kategoriju formalnih upitnih jezika imperativnog karaktera. ini je skup operatora za rad sa relacijama, a rezultati operacija relacione algebre takoe su relacije. Operacije relacione algebre Prema prvobitnoj definiciji relacione algebre, ustaljeno je gledite da je ini skup od 8 operacija koje se nazivaju osnovnim, ali su samo 5 od njih elementarne, dok se preostale 3 mogu izvesti iz njih. Pored osnovne podjele na elementarne i izvedene, operacije relacione algebre mogu se prema broju operanada (relacija koje uestvuju u operaciji) klasifikovati na unarne (1 operand) i binarne (2 operanda). Uz to, postoji i podjela na tradicionalne skupovne i posebne relacione operacije. Postoji 8 osnovnih operacija relacione algebre: Restrikcija (simbol ) je elementarna, unarna i posebna operacija koja iz polazne relacije po zadatom kriterijumu izdvaja podskup torki. Kriterijum je neki logiki izraz koji je izraunljiv nad svakom torkom. Dobijena relacija ima istu strukturu kao i polazna.

Projekcija (simbol ) je elementarna, unarna i posebna operacija koja iz polazne relacije po zadatom skupu atributa formira novu relaciju kao skup torki nad tim atributima. Zadati skup atributa mora biti podskup skupa atributa polazne relacije, a vrijednosti atributa u torkama nastale relacije odgovaraju onima u torkama polazne relacije. Unija (simbol U ) je elementarna, binarna i skupovna operacija koja iz dvije polazne relacije formira novu koja sadri sve torke koje se nalaze u bilo kojoj ili eventualno u obije polazne relacije. Ova operacija nije mogua izmeu bilo koje dve relacije, nego samo izmeu onih koje zadovoljavaju uslove: eme relacija imaju isti broj atributa; atributi ema relacija redom odgovaraju jedni drugim.

15

Navedeni uslovi zajedno ine tzv. uslov unijske kompatibilnosti koji vai i za jo dvije skupovne operacije relacione algebre. Drugi uslov podrazumjeva da atributi odgovaraju po znaenju i tipu. Jednakost naziva atribita nije neophodna, a nije uvek ni mogua.

Razlika (simbol ) je elementarna, binarna i skupovna operacija koja iz dvije polazne relacije formira novu koja sadri sve torke prve relacije koje se ne nalaze u drugoj relaciji. Ova operacija je mogua samo izmeu unijski kompatibilnih relacija. Presjek (simbol ) je izvedena, binarna i skupovna operacija koja iz dvije polazne relacije formira novu koja sadri sve torke prve relacije koje se nalaze i u drugoj relaciji. Ova operacija je mogua samo izmeu unijski kompatibilnih relacija. Dekartov proizvod (simbol ) je elementarna, binarna i skupovna operacija koja iz dvije polazne relacije formira novu, sa torkama dobijenim tako {to se svaka torka iz prve relacije redom "spoji" sa svakom torkom druge relacije, pri emu ema nastale relacije sadri redom sve atribute polaznih relacija. Spajanje (simbol >< ) je izvedena, binarna i posebna operacija koja iz dvije polazne relacije formira novu, sa torkama dobijenim u dva koraka: svaka torka iz prve relacije redom se spaja sa svim torkama iz druge relacije; iz tako dobijenih torki izdvajaju se one koje zadovoljavaju zadati uslov P.

Dijeljenje (simbol / ) je izvedena, binarna i posebna operacija koja predstavlja najsloeniju operaciju relacione algebre. Formalna definicija deljenja, koja postaje sasvim jasna tek poslije pogodnog primjera, moe se iskazati na sledei nain. Neka je r relacija eme R(XY) a s relacija eme S(Z), gdje su X i Y disjunktni skupovi atributa, a Y i Z unijski kompatibilni skupovi atributa u smislu tipa i znaenja.

16

Za objanjenja operacija relacione algebre neophodne su izvjesne napomene o notaciji. Nazivi ema relacija pisani su velikim, a nazivi relacija malim slovima. Nazivi atributa uvijek se piu velikim slovima. Sa X se najee oznaava slup atributa eme relacije, a sa x torka odgovarajue relacije. Y, Z i slino najeeoznaavaju podskupove od X. Radi jasnoe definicija, ponekad se sa r(Y) naglaava da je u pitanju relacija kao skup torki nad skupom atributa Y. Pod kardinalnou relacije N(r) podrazumjeva se broj torki u relaciji r. Za uspjeno rjeavanje problema u oblasti relacione algebre bitno je da imamo uvid u eme relacija koje nastaju poslije svakog koraka u izraunavanju sloenih izraza. Iz tog razloga, praksa je da uz naziv relacije piemo i atribute u sastavu njene eme.

17

3.4. Predstavljanje podatakaSvi podaci u relacionoj bazi predstavljaju se na logikom nivou na jedinstven nain - preko vrijednosti u tabelama. Pod pojmom svi podaci podrazumjevaju se podaci koje je korisnik definisao i unio u bazu bez obzira na to da li je rije o: - osnovnim podacima (koji se odnose na vrijednosti atributa), - tzv. meta-podacima (kojima su definisani nazivi tabela, kolona i dr.), ili - definiciji razliitih pravila kao to su pravila integriteta. Naime, nezavisno od toga na ta se podaci odnose, oni su u relacionoj bazi dostupni kao neke vrijednosti u odreenim tabelama. Na taj nain obezbjeena je jedinstvena struktura podataka i meta-podataka u sistemu.

18

3.5. Pristup podacimaSvakom osnovnom podatku (konkretnoj vrijednosti kolone u nekom slogu tabele) u relacionoj bazi uvijek se moe pristupiti korienjem kombinacije imena tabele (relacije), vrijednosti primarnog kljua i imena kolone (atributa). Posljedica navedene osobine je da relacioni model omoguava lako rukovanje podacima na logikom nivou, s obzirom na to da se do podataka dolazi bez primjene postupka sekvencijalne pretrage ili nekog slinog, u svakom sluaju manje efikasnog postupka. Mnogi sistemi koji se danas na tritu softvera reklamiraju kao relacioni pokazuju izvjesne nepravilnosti u odnosu na opisano pravilo. Naime, oni dozvoljavaju kreiranje tabela bez definisanog primarnog kljua, to jest tabela koje sadre slogove sa potpuno identinim vrijednostima u svim kolonama. U takvim sluajevima, tabele bez definisanog primarnog kljua gube smisao relacije definisane u relacionom modelu. Pristup podacima u takvim tabelama je otean, a samim tim oteano je i rukovanje podacima. Navedeni problem mogao bi se izbjei uvoenjem discipline u postupku kreiranja relacija, tj. obaveznom definicijom primarnog kljua za svaku tabelu.

3.6. Sistemski tretman NULL vrijednostiPotpuno relacioni sistem za upravljanje bazom podataka obavezno sistemski podrava predstavljanje informacija koje nedostaju u bazi, upotrebom tzv. Null vrijednosti, nezavisno od tipa podataka. Null vrijednost je specifian indikator razliit od praznog niza karaktera ili niza blankova i razliit od nule ili bilo kog drugog broja. RDBMS obezbeuje jedinstvenu prezentaciju Null vrijednosti, a na taj nain i jednostavno rukovanje tim vrijednostima. Vrijednost Null moe biti potencijalna vrijednost svake kolone bez obzira na njen tip, osim u sluaju kad se izriito zahtjeva da vrijednosti u nekoj koloni ne smiju biti nedefinisane (dodatno ogranienje NONULL). Izuzetak predstavljaju kolone primarnog kljua koje, kao identifikatori zapisa u tabeli, ne smiju uzeti Null vrijednost.

19

3.7. Neprekidan pristup dinamikom katalogu relacionog modelaRelacioni sistem posjeduje katalog (rijenik) podataka koji se na logikom nivou predstavlja na isti nain kao i sami podaci, tako da ovlaeni korisnici mogu primenjivati jedinstveni relacioni jezik za pretragu ovih meta-podataka. Pod pojmom "katalog" podrazumijeva se direktorij u kojem se nalaze sistemske definicije podataka. Uvidom u katalog podataka moe se saznati koje kolone posjeduju odreene tabele, koja su ogranienja definisana, kao i druge informacije koje se odnose na sistemske tabele. U sluaju distribuiranih baza podataka, katalog treba da sadri podatke o lokaciji svakog djela baze. Katalog nazivamo dinamikim zbog injenice da definicije podataka koje se mogu vidjeti odgovaraju upravo tekuem stanju u bazi podataka. Bez obzira na to koji korisnik, na kojoj lokaciji, ili u kom djelu opisa baze napravi neku izmjenu, novo stanje e biti dostupno za itanje svim ovlaenim korisnicima. On line pristup katalogu praktino znai da je trenutnom stanju opisa baze obezbeen neprekidan pristup. Meutim, sve dok se stanje u opisu baze konano ne promjeni, ovlaenim korisnicima je vidljivo stanje prije promjena. Naime, u relacionoj bazi sve operacije koje mjenjaju opis podataka zapoinju i zavravaju se odreenim naredbama kojima se sistem obavjetava da je auriranje kompletno. On line uvidom ne vidi se ni jedna izmjena koja nije konana. Veoma je vana injenica da pravo pristupa opisu baze imaju samo za to ovlaeni (autorizovani) korisnici.

20

3.8. Sveobuhvatan jezik za rad sa podacimaBez obzira na to koliko jezika i koliko naina korienja terminala podrava, relacioni sistem mora posjedovati bar jedan jezik ije se naredbe mogu izraziti kao niz karaktera sa dobro definisanom sintaksom, a koji sveobuhvatno moe da podri: 1) definiciju podataka 2) definiciju pogleda 3) rukovanje podacima 4) definiciju pravila integriteta 5) prava u sistemu (autorizaciju) 6) granice transakcije (BEGIN, COMMIT, ROLLBACK). U navedenih 6 stavki obuhvaene su sve funkcije jednog RDBMS-a, koje se saglasno sutini ovog pravila, moraju odvijati u jedinstvenom okruenju, unutar jednog jezika. To podrazumjeva da se svaki zadatak moe kompletno izvriti, bez naputanja takvog sveobuhvatnog okruenja. Za administratore sistema postojanje sveobuhvatnog jezika omoguava da se, prilikom rukovanja podacima, izbjegne niz suvinih koraka. Ilustracije radi, kad je potrebno sauvati neke meurezultate ili slogove, izbegavaju se sledei koraci: - naputanje datog okruenja, - ulazak u drugu aplikaciju i definisanje nove tabele u njoj, - povratak u staro okruenje i unos podataka u kreiranu tabelu.

21

3.9. Auriranje pogledaRelacioni sistem poseduje efikasan algoritam za auriranje svih pogleda koji se teorijski mogu aurirati. Rezultat ovog algoritma smjeta se u katalog (rijenik) baze podataka. Pogledi predstavljaju virtuelne relacije koje fiziki ne postoje ali se u svakom drugom smislu ponaaju kao relacije. Moe se rei da su to izvedene tabele nad kojima je mogue definisati upite kao i nad bilo kojim postojeim tabelama u bazi. Pogled se ponaa kao dinamiki prozor kroz koji se gledaju relacije baze i putem kojeg je mogue vriti promjene koje e se automatski reflektovati na relacijama baze. Svaki put kada korisnik ita podatke kroz pogled, sistem formira rezultujui skup slogova na osnovu definicije pogleda i podataka u tabelama baze. Rezultujui skupovi slogova, odnosno posebne kopije podataka koji se vide kroz pogled, ne uvaju se u sistemu, ve se samo u katalogu baze uvaju definicije pogleda. Pod auriranjem pogleda podrazumjevaju se operacije brisanja i dodavanja slogova, kao i modifikovanje postojeih slogova. Codd naglaava da je pogled teorijski mogue aurirati ako postoji vremenski nezavisan algoritam koji nedvosmisleno odreuje niz izmjena u baznim relacijama, iji je konani efekat upravo zahtjevana izmjena nad pogledom."

3.10. Dodavanje, brisanje i modifikovanje na visokom nivouNe samo za izdavanje podataka, ve i za operacije dodavanja, brisanja i modifikovanja podataka postoji mogunost da se rukuje baznim i izvedenim relacijama u cijelosti kao operandima. Glavni objekat u relacionoj bazi podataka je relacija. Sve operacije relacione algebre rukuju relacijama kao operandima, a rezultat svake operacije je takoe neka relacija. Ako izdvojimo jedan konkretan slog iz relacije moemo ga posmatrati kao relaciju sa jednim slogom. Konkretan podatak (osnovna vrijednost) izdvojen iz baze, takoe predstavlja relaciju nad samo jednim atributom sa samo jednim slogom (tabela sa jednom kolonom i jednim redom). U tom smislu u bazi podataka se uvijek rukuje sa relacijama u cjelosti. Ova injenica pozitivno utie na optimizaciju postupka sprovoenja operacija u sistemu. Ilustracije radi, posmatrajmo itanje cijele relacije. Ukoliko za svaki slog koji se ita moramo sistemu da 22

zadamo posebnu komandu, sistem mora pojedinano da optimizuje i izvrava svaku od njih. U sluaju itanja cijele relacije jednom operacijom, sistem odreuje najbolji nain pristupa slogovima u globalu za cijelu relaciju. Iste prednosti odnose se i na operacije brisanja, modifikovanja i dodavanja slogova. Opisano pravilo ima znaajnu ulogu u obradi transakcije nad distribuiranom bazom podataka. injenica da se relacijama rukuje kao operandima, reflektuje se na efikasniju obradu podataka. Utede se ostvaruju ne samo u vremenu ve i u trokovima komunikacija. Upotrebom ovakvih upita na visokom nivou izbjegava se prenos pojedinanih zahtjeva, za svaki slog, prema udaljenom sistemu.

3.11. Fizika nezavisnostRelacioni sistemi u obavezi su da zadovolje pravilo fizike nezavisnosti ija je sutina u sljedeem: aplikacioni program i aktivnosti na terminalima ostaju neizmjenjeni kada se promjeni fizika organizacija baze ili fiziki metod pristupa podacima. Aplikacije i programi rukuju podacima iskljuivo na semantikom i logikom nivou. Sama fizika organizacija podataka predstavlja internu stvar sistema i ima uticaja jedino na performanse (brzinu pristupa podacima, odziv sistema). Neophodno je da u sistemu postoji otra granica izmeu logikog modela podataka i fizikog razmjetaja podataka na mediju. Kreiranje i brisanje indeksa nad nekom tabelom iz baze, ne smije imati uticaja na logiku strukturu programa i naredbi. Kod nerelacionih sistema za upravljanje bazom podataka sami programi bi morali pretrpjeti izmjene u zavisnosti od postojanja indeksa nad odreenim tabelama. Navedeno pravilo omoguava da se uoe dvije osnovne grupe korisnika u sistemu: projektanti i programeri, administratori baze podataka.

Uloga projektanata i programera je da se bave logikim dizajniranjem i programiranjem, dok se administratori baze, izmeu ostalog, bave i odravanjem interne organizacije podataka u sistemu. Osnovna komponenta koja u aktuelnim relacionim sistemima obezbeuje fiziku nezavisnost je tzv. optimizator SQL naredbi. 23

Optimizator za svaku SQL naredbu odreuje optimalan plan izvrenja u smislu vremena odziva i ukupnog utroka resursa sistema. Sam proces optimizacije odvija se u trenutku izvrenja naredbe, a sastoji se od analize dostupnih indeksa i naina pristupa podacima. Plan izvravanja naredbe za koji se predviaju najbolje performanse u obradi bira se na osnovu heuristikih pravila ili statistikih podataka o bazi.

3.12. Logika nezavisnostKada se na tabelama baze izvre izmjene koje ne izazivaju gubljenje podataka ili logika oteenja, aplikacioni programi i aktivnosti na terminalima ostaju logiki neoteeni. Ukoliko RDBMS ispunjava uslov auriranja pogleda onda e bez problema moi da zadovolji i pravilo logike nezavisnosti. . Kada spajamo dvije tabele mogunost auriranja pogleda ouvanje logike nezavisnosti. Logika, kao i fizika nezavisnost, za posljedicu imaju jednu veoma vanu prednost koju relacioni sistemi pokazuju u odnosu na nerelacione. Prednost se sastoji u tome to greke u poetnom dizajnu modela podataka nemaju teke posljedice i dozvoljavaju naknadne korekcije. Projektanti u tom smislu mogu da bez prevelikog opterenja kreiraju inicijalne modele podataka, a da ih kasnije, ak i u poodmakloj fazi implementacije aplikacije, ponovo dorauju i prilagoavaju novim zahtjevima. nad novom tabelom uslov je za

3.13. Integritetska nezavisnostSva pravila integriteta definiu se u okviru definicije baze podataka i uvaju se u katalogu podataka, a ne u aplikacionim programima. Integritet podataka djeli se na 4 kategorije: - integritet entiteta, - integritet domena, 24

- referencijalni integritet, i - korisniki definisan integritet. Integritet entiteta podrazumijeva da svaka vrijednost primarnog kljua mora biti jedinstvena na nivou cijele relacije. Osim toga, mora biti ispunjen uslov da ni jedna stavka u koloni primarnog kljua ne smije imati NULL vrednost. Integritet domena odreuje skup dozvoljenih vrijednosti kolone. Odravanje integriteta domena postie se navoenjem dozvoljenog tipa podataka, dozvoljenog formata za unos podataka, ili zadavanjem skupa moguih vrijednosti. Referencijalni integritet odraava definisane odnose (relacije) meu tabelama kada se u njih dodaju ili se iz njih briu zapisi. Korisniki integritet omoguava definisanje specifinih poslovnih pravila. Naime, za bazu podataka mogu postojati dodatna ogranienja, formirana na osnovu odreenih pravila poslovanja, koja definiu vaee podatke u bazi. RDBMS treba da obezbjedi definisanje svih navedenih kategorija integriteta pod jezikom relacionih podataka. Kada se pravila integriteta jednom definiu ona spreavaju upis podataka koji ne zadovoljavaju te definicije (nekonzistentni podaci). U sluaju promjene pravila integriteta dolazi do izmjene jednog ili vie iskaza ogranienja u katalogu podataka, ali logika struktura programa i aktivnosti na terminalima ostaju neizmenjeni. Jedino mogue sredstvo za uvanje integriteta baze podataka, kod postojeih relacionih sistema, je korienje tzv. okidaa (Triggers). Okida je pokreta procedure koja se automatski poziva kad god doe do dodavanja, auriranja ili brisanja podataka u tabeli. Okida je objekat baze koji se uva u katalogu podataka i svaki je pojedinano pridruen jednoj tabeli, pri emu se navodi koje od operacija dodavanja, auriranja ili brisanja izazivaju njegovo izvrenje. Tako se, na primjer, za bazu podataka tekuih rauna graana u nekoj banci moe definisati okida koji se izvrava prilikom brisanja slogova iz tabele, a ima ulogu da onemogui brisanje rauna ije stanje nije ravno nuli.

25

3.14. Distribuciona nezavisnostU zavisnosti od toga koliko primjeraka vrijednosti logikih objekata iz baze postoji i na koliko lokacija se oni nalaze, razlikujemo dva tipa arhitekture sistema baze podataka: 1. centralizovani sistem, i 2. distribuirani sistem. U centralizovanom sistemu baza podataka je skup logikih objekata i njihovih vrijednosti, gdje postoji samo jedan primjerak vrijednosti svakog logikog objekta baze. U distribuiranom sistemu vrijednost nekog logikog objekta moe imati vie primjeraka, memorisanih u vie lokalnih baza, na razliitim lokacijama. E.F.Codd je definisao distribucionu nezavisnost RDBMS-a kao njegovu sposobnost da aplikacioni programi i aktivnosti na terminalima ostanu logiki neoteeni: - kada se prvi put uvede distribucija podataka, i - kada se podaci predistribuiraju. Prvi sluaj podrazumijeva da je sistem prvobitno upravljao samo nedistribuiranim podacima, a onda je dolo do njihove distribucije. U drugom sluaju sistem je ve upravljao distribuiranim podacima, ali je dolo do promjene njihovog rasporeda. Relacioni sistem koji je distribuciono nezavistan omoguava da jedna transakcija rukuje podacima sa vie udaljenih sistema, a da korisnik pri tome ima utisak da se sve odvija u okviru lokalnog sistema. Ova osobina daje veliku mo naredbama jezika podataka na visokom nivou, koje mogu unutar jedne komande kombinovati podatke sa razliitih mjesta.

26

3.15. Rad sa jezicima niskog nivoaIako u obavljanju svojih funkcija koristi jezike visokog nivoa (princip grupnog pristupa slogovima), sistem za upravljanje bazom podataka moe da sadri i neke od jezika niskog nivoa (pojedinani pristup slogovima) i da podrava njihov rad. Uslov koji RDBMS treba da zadovolji je da se u radu sa jezicima niskog nivoa ne smiju naruiti ili zaobii pravila integriteta i ogranienja izraena relacionim jezikom visokog nivoa. Kod nerelacionih sistema est je sluaj da jezici niskog nivoa zaobilaze definicije iz kataloga podataka. U tom sluaju proces obrade se ne oslanja na zapamene definicije podataka, pravila integriteta i ogranienja. Visoke mogunosti SQL-a u pogledu rukovanja relacijama kao operandima (u cijelosti), uglavnom nisu primjenljive u jezicima kao to su C i PASCAL, iz jednostavnog razloga to u okruenju ovih jezika relacija nema odgovarajuu prezentaciju. U cilju prevazilaenja ovog problema morao se obezbjediti pristup i rukovanje podacima na nivou slogova primjenom koncepta kursora (cursor). Kursor u sutini predstavlja objekat definisan SELECT naredbom, nad kojim se mogu realizovati tri operacije: - otvaranje kursora (OPEN), - dohvatanje sljedeeg sloga iz kursora (FETCH), i - zatvaranje kursora (CLOSE). Otvaranjem kursora formira se aktivni skup slogova (neka vrsta interne kopije slogova koji se smjetaju u memoriju). Nad tim skupom slogova izvravaju se operacije dohvatanja jednog po jednog sloga sve dok se ne doe do posljednjeg iz izdvojene grupe. Zatvaranjem kursora oslobaa se memorijski prostor aktivnog skupa slogova. Opisani postupak pojedinanog pristupa slogovima, itanjem tabela pomou kursora, obezbeuje konzistentnost itanja baze podataka. 27

4.0. ZAKLJUAK Relacioni model podataka, koji se zasniva na matematikoj teoriji skupova, predloen je jo 1969. godine od strane E.F.Codd-a, tada istraivaa u IBM-ovim laboratorijama. Ovaj model je svojim osobinama prevaziao tada aktuelne hijerarhijske i mrene modele podataka. Relacione baze podataka se projektuju u vidu tabela, indeksiranih po razliitim pojmovima (poljima) i sa vie kljueva. Ve pri njihovom kreiranju mogu se uspostaviti logike veze izmeu pojedinih tabela preko zajednikih polja tako da se na lak i jednostavan nain dolazi do svih potrebnih podataka, bilo da se radi o podacima samo iz jedne tabele ili se podaci dobijaju spajanjem vie tabela u jednu novu, koja je privremenog karaktera, a sadri samo polja koja su potrebna korisniku. Do podatka se u tabeli dolazi direktno pozivanjem odgovarajueg indeksnog kljua pri emu se pokaziva automatski pozicionira na slog sa traenim podatkom. Osniva relacionog modela, u cilju zatite epiteta relacioni, koji se sve ee iz komercijalnih razloga pripisivao i nekim nerelacionim sistemima za upravljanje bazama podataka, definisao je 12 strogih pravila koje mora potovati jedan RDBMS. On je takoe i argumentovao postojanje niza pozitivnih efekata koje u praksi postie sistem ukoliko zadovoljava definisane kriterijume. Osnovne prednosti potpuno relacionog sistema za upravljanje bazom podataka su: - administratorima baze omogueno je da u svakom trenutku znaju koje se vrste podataka nalaze u bazi i kako se njima moe pristupiti; - produktivnost programera je poboljana s obzirom na injenicu da je podrano iteraktivno testiranje programa i naredbi u jedinstvenom okruenju, unutar jednog jezika; - opta nezavisnost aplikacionih programa od podataka olakava razvoj i odravanje informacionih sistema (posljedica fizike, logike, integritetske i distribucione nezavisnosti); 28

- smanjeni su trokovi izmjena opisa podataka u bazi, prilikom prilagoavanja programa novim zahtjevima ( promjene performansi sistema, organizacione promjene, promjene pravila poslovanja) - trokovi komunikacija u distribuiranoj bazi podataka su smanjeni zahvaljujui osobini dodavanja, brisanja i modifikovanja na visokom nivou; - obrada svih jezika za manipulaciju podacima u relacionom sistemu oslanja se na zapamene definicije podataka, ukljuujui pravila integriteta i ogranienja;

Poznavanje relacionog modela osnovni je preduslov za uspjeno dizajniranje baze podataka koja e podravati rad prilagodljive i lako dogradive aplikacije.

29

Literatura 1. 2. 3. 4. 5. 6. Uvod u relacione baze podataka - Gordana Pavlovi-Laeti Relacione baze podataka Vladimir Blagojevi www.wikipedia.org Prirunik za predmet Strukture i baze podataka Jasmin Helji Baze podataka skripta Robert Manager http://www.elitesecurity.org/

30