BAZE PODATAKAuni-mo.sve-mo.ba/~goran/nastava/BAZE_Predavanja.pdf · Punjenje baze podataka Testiranje Kreiranje formi Kreiranje izvješća Kreiranje Upita Pisanje koda aplikacije

Ak.god. 2014/2015. BAZE PODATAKA 1

BAZE PODATAKA

FAKULTET STROJARSTVA I RAĈUNARSTVA

SVEUĈILIŠTE U MOSTARU

Doc.dr.sc. GORAN KRALJEVIĆ


Web:

http://www.fsr.ba/~goran

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: [email protected]

[email protected]

Baze podataka


Baze podataka

Sadrţaj predmeta:

o Uvod u baze podataka;

o Sustav za upravljanje bazom podataka;

o Relacijski model podataka;

o Modeliranje podataka (Model entiteti-veze, UML notacija);

o Normalizacija podataka (Normalne forme);

o Relacijske baze podataka;

o SQL (standardni upitni jezik);

o Korisnici i sigurnost baze podataka;

o Višekorisnički rad i upravljanje transakcijama;

o Zaključavanje podataka;

o Objekti u bazi podataka (tablice, pogledi, indeksi, ...);

SQL (detaljno na vjeţbama)


Polaganje ispita (kolokviji ...)

Prolazna ocjena putem kolokvija: min. 50 bodova

50,0 bod. ............ dovoljan (2)

62,5 bod. ............ dobar (3)

75,0 bod. ............ vrlodobar (4)

87,5 bod. ............ izvrstan (5)

1. kolokvij (Modeliranje + Teorija) 45 bodova

2. kolokvij (SQL) 45 bodova

Aktivno sudjelovanje na nastavi 10 bodova

Ukupno : 100 bodova


Polaganje ispita (ispitni rokovi ...)

Pismeni + Usmeni

Prolazna ocjena na ispitu: min. 60 bodova

60-69 bod. .......... dovoljan (2)

70-79 bod. .......... dobar (3)

80-89 bod. .......... vrlodobar (4)

90-100 bod. ........ izvrstan (5)

Napomena:

Studenti koji tijekom semestra (kolokviji ...) osvoje 40-49 bodova dobit će 10 bodova koji će im se pribrojiti na svim pismenim ispitnim rokovima do kraja akademske godine.

Studenti koji tijekom semestra (kolokviji ...) osvoje 30-39 bodova dobit će 5 bodova koji će im se pribrojiti na svim pismenim ispitnim rokovima do kraja akademske godine.


Uvod u baze podataka


Baza podataka

• Baza podataka je skup meĎusobno povezanih podataka,

pohranjenih zajedno bez štetne ili nepotrebne (nekontrolirane)

zalihosti (redundancije), s ciljem da ih koriste različite aplikacije.

Podaci su pohranjeni u obliku neovisnom od programa koji ih

koriste. Unos, izmjena i dohvat podataka obavlja se ISKLJUČIVO

kroz zajedničko i kontrolirano sučelje.


Zajedniĉke osobine za sve sustave baza podataka (Ullman)

• Apstraktni model podataka

• Visoka razina pristupa ili upitnih jezika

• Upravljanje transakcijama u višekorisničkom okruženju

• Kontrola pristupa i vlasništvo nad podacima

• Validacija podataka i provjera konzistentnosti

• Konzistentni oporavak podataka nakon ispada sustava i/ili strojne opreme


Ciljevi razvoja baza podataka

• Razdvajanje podataka od aplikacija koje ih koriste

• Prezentiranje logičkog pogleda na podatke neovisno od fizičkih detalja njihove pohrane u bazu podataka

• Omogućavanje različitih pogleda na istu bazu podataka, ovisno o korisničkim i aplikativnim potrebama


Faze razvoja baza podataka

FAZE razvoja Baza podataka Aplikacija

Zahtjevi

(analiza)

Izrada modela podataka

Specificiranje podataka

Definiranje ograničenja i poslovnih pravila

UtvrĎivanje zahtjeva za aplikaciju

Dizajn

Tablice

Relacije

Indeksi

Ograničenja

Pohranjene procedure i okidači

Forme

Izvješća (Reports)

Upiti (Queries)

Kod aplikacije

Implementiranje

Kreiranje tablica

Kreiranje relacija

Kreiranje ograničenja

Pisanje procedura i okidača

Punjenje baze podataka

Testiranje

Kreiranje formi

Kreiranje izvješća

Kreiranje Upita

Pisanje koda aplikacije

Testiranje


Povijesni razvoj baza podataka

Sustavi bazirani na datoteĉnim sustavima (filesystem)

• podaci su spremljeni u datotekama (files)

• svaka datoteka ima svoj format

programi koji koriste bazu moraju poznavati taj format

• Problemi:

nema standarda

višestruko ponavljanje podataka

meĎuovisnost podataka

teško je vršiti neuobičajena pretraživanja

integritet podataka

sigurnost

istovremeni pristup, ...


Modeli podataka

• Model podataka je skup pravila koji odreĎuju kako može izgledati logička struktura baze

• U 60-tim i 70-tim godinama su bili u upotrebi hijerarhijski i mrežni model

• Hijerarhijski model baza je predočena stablom ili skupom stabala jedan član može imati samo jednog vlasnika putovi pretraživanja su fiksni

• Mreţni model opći slučaj hijerarhijskog modela odnosi definirani eksplicitno aplikacija mora poznavati interni model baze podataka

• Implementacije u raĉunalu koristile su pokazivaĉe koji izravno adresiraju mjesto zapisa na disku


Hijerarhijski i mreţni model

Hijerarhijski model podataka Mreţni model podataka

Ograniĉenja hijerarhijskih i mreţnih baza:

- Nemaju pokriće u formalnoj teoriji - Sva pretraživanja se izvode po unaprijed definiranim i točno navedenim putovima - Svi odnosi izmeĎu objekata se moraju unaprijed i točno definirati - Optimizacija se provodi ručno - programer sam optimizira kod i odreĎuje metodu koja će biti korištena pri komunikaciji izmeĎu aplikacije i baze podataka


Modeli podataka

• Relacijski model

1970. dogaĎa se relacijska "revolucija“

E.F.Codd objavljuje članak "A Relational Model of Data for Large Shared Databanks"

koji postavlja osnove skoro svim današnjim sustavima baza podataka

• Objektni model

inspiriran objektno orijentiranim programskim jezicima

baza je skup objekata koji se sastoje od podataka i metoda koje vrše operacija nad njima


Sustav za upravljanje bazama podataka

• SUBP (DBMS - Database Management System)

Programski sustav koji omogućava upravljanje bazom podataka je sustav za upravljanje bazama podataka.

• Korisnički programi ne pristupaju podacima direktno već preko DBMS-a

• Korisnik ili korisnički program postavlja zahtjev za obavljanjem neke operacije s podacima, a SUBP ga analizira, provjerava, optimizira, transformira u niz operacija koje je potrebno obaviti na fizičkoj razini, obavlja operacije i vraća rezultat.


Fiziĉka i logiĉka organizacija podataka

• Vaţna posljedica primjene SUBP jest razdvajanje fiziĉke i logiĉke organizacije podataka. Dok logička organizacija podataka predstavlja organizaciju sa stanovišta korisnika baze podataka ili programera te je koncentrirana na vrste podataka i njihove meĎusobne logičke veze, fizička organizacija predstavlja organizaciju fizičke pohrane podataka unutar računala. Oblik i organizacija pohranjenih podataka tu su često potpuno različiti od njihovog logičkog oblika i organizacije.

• U okviru toga, zadaća je SUBP-a omogućiti korisniku (programeru) manipuliranje podacima uz poznavanje samo logiĉkog opisa baze podataka, a ne nužno i poznavanja načina fizičke pohrane podataka.



Funkcije SUBP-a:

• Definiranje baze podataka (DDL–Data Definition Language)

• Manipuliranje podacima u bazi (DML–Data Manipulation Language)

• Upravljačke funkcije:

Sigurnost i zaštita od neovlaštenog pristupa

Očuvanje integriteta (backup i recovery)

Statističko praćenje rada baze podataka

Optimizacija rada



Glavni proizvoĊaĉi SUBP (DBMS):


Relacijski model podataka



• Relacijski model je osnovne koncepte preuzeo iz matematičke teorije skupova, a to su:

Relacija

Atribut

Domena



• Relacijski model podataka se temelji na matematičkoj teoriji relacija

• Većina suvremenih DBMS je bazirana na relacijskom modelu

• Informacije su pohranjene kao zapisi ili slogovi (records) u relacijama (tablicama)

• Baza podataka je skup relacija (tablica)

Podaci su u n-torkama (redovima) Zaglavlje definira atribute (stupce) relacije


Kljuĉevi u relacijskoj bazi podataka

• Super kljuĉ (superkey) – atribut ili skup atributa koji

jedinstveno odreĎuje n-torku unutar relacije.

• Kandidat kljuĉ (candidate key) – super ključ takav da nema

nijedan odgovarajući podskup koji bi bio super ključ unutar relacije.

• Primarni kljuĉ (primary key) – kandidat ključ koji je odabran

da jedinstveno odredi n-torku unutar relacije.

• Jedinstveni kljuĉ (unique key) – kandidat ključ koji nije

odabran da bude primarni ključ.



Primjer:

• Super kljuĉ: npr. {Matbr, Prezime}

• Kandidat kljuĉ: {Matbr}, {JMBG}

• Primarni kljuĉ: {Matbr}

• Jedinstveni kljuĉ: {JMBG}



Kandidat (za PRIMARNI) kljuĉ mora zadovoljiti 2 uvjeta:

• Jedinstvenost … na relacijskoj shemi niti u jednom trenutku

ne mogu postojati dvije n-torke s jednakim vrijednostima skupa atributa K.

• Minimalnost … niti jedan pravi podskup od skupa atributa K

nema svojstvo jednoznačnosti.

I primarni i jedinstveni kljuĉ moraju ispuniti uvjete

jedinstvenosti i minimalnosti, ali relacija moţe imati

samo jedan primarni kljuĉ, dok jedinstvenih kljuĉeva

moţe imati više.



• Vanjski ili strani kljuĉ (foreign key) – atribut ili skup

atributa unutar jedne relacije koji odgovara kandidat ključu neke (moguće i iste) relacije.

• Vanjski kljuĉevi omogućuju povezivanje n-torki iz razliĉitih tablica.

Primjer:


Ograniĉenja u relacijskom modelu podataka

Dva opća ograniĉenja:

• Entitetski integritet

- povezan sa primarnim ključem

• Referencijalni integritet

- povezan sa stranim ključem


Entitetski integritet

• Vrijednost primarnog kljuĉa kao cjeline, ne smije biti jednaka NULL vrijednosti.

Ako je primarni ključ relacije složen, niti jedna njegova komponenta ne smije poprimiti NULL vrijednost.

Primjeri:

NASTAVNIK = {SifNas, PrezNas} PK (NASTAVNIK) = {SifNas} → SifNas ne smije biti NULL

ISPIT = {Matbr, SifPred, DatIsp} PK (ISPIT) = {Matbr, SifPred, DatIsp} → Matbr, SifPred, DatIsp ne smiju biti NULL

• Integritet ključa:

U relaciji ne smiju postojati dvije n-torke s jednakim vrijednostima kljuĉa (vrijedi za sve moguće kljuĉeve).


Referencijalni integritet

• Ako u relacijskoj shemi R postoji strani kljuĉ (foreign key) koji odgovara primarnom kljuĉu (primary key) relacijske sheme S, tada svaka vrijednost stranog kljuĉa u relaciji r(R) mora biti ili jednaka vrijednosti primarnog kljuĉa neke n-torke iz relacije s(S) ili jednaka NULL vrijednosti.

Primjer:

Relacije OSOBA i MJESTO ne zadovoljavaju pravilo referencijalnog integriteta jer u relaciji OSOBA postoji vrijednost stranog ključa (77000) za koju ne postoji odgovarajuća n-torka u relaciji MJESTO.


Ograniĉenja u relacijskom modelu podataka

Domenski integritet

• Kako svaki atribut ima pridruženu domenu, postoje ograničenja (engl. domain constraints) koja čine restrikcije nad skupom dozvoljenih vrijednosti atributa relacije.

NULL / NOT NULL

• NULL – predstavlja vrijednost atributa koja je trenutno nepoznata ili nije primjenjiva za konkretnu n-torku.

• NULL je način rada s nepotpunim podacima ili izuzetcima.

• NULL nije nula (0) za numeričke vrijednosti ili “spaces” za tekst.

• NULL znači ODSUSTVO (nepostojanje) vrijednosti.


Operacije u relacijskom modelu

Osnovne operacije u relacijskom modelu:

• Unija

• Razlika

• Presjek

• Kartezijev produkt

• Projekcija

• Selekcija

• Spajanje (join)



• Unija … relacija koju čine sve n-torke prve i druge relacije



• Razlika … relacija koju čine sve n-torke koje se nalaze u prvoj,

ali se ne nalaze u drugoj relaciji



• Presjek … relacija koju čine n-torke zajedničke za obje relacije



• Kartezijev produkt … relacija koju čine sve moguće kombinacije

parova n-torki s tim da je prva n-torka iz prve, a druga iz druge relacije



• Projekcija … rezultat je izbor odreĎenih atributa polazne relacije



• Selekcija (ograničenje, restrikcija, izbor) … rezultat su samo

one n-torke koje zadovoljavaju postavljene uvjete



• Spajanje … iz dvije relacije stvara novu relaciju od svih

kombinacija parova n-torki koji zadovoljavaju postavljene uvjete

• U svakoj se tablici (relaciji) bira stupac (polje) preko čijih se vrijednosti uspostavlja veza



• Opisane operacije relacijske algebre primjenjuju se uvijek u kombinaciji:

iz više tablica selektiramo samo one zapise koji udovoljavaju uvjetima

napravimo spajanje (join) projekcijom odaberemo željena polja

• Na taj se način iz vrlo malog broja osnovnih operacija relacijske algebre može izvesti veliki broj kombinacija za obradu i analizu podataka.

• Prijevod operacija relacijske algebre u jezik za definiciju i manipulaciju podacima koji danas predstavlja osnovni standard

za relacijske baze podataka: SQL.


Modeliranje podataka


Modeliranje podataka


ER modeliranje

Model entiteti - veze (entity-relationship model)

• ili bolje: model entiteti - veze - atributi

ER modeliranje:

• je sastavljeno iz entiteta, veza i atributa

• je slikovni prikaz sustava baze podataka

• je neovisno o DBMS i hardveru

• predstavlja konceptualni model visokog nivoa

• podržava korisnikovu percepciju podataka

• je alat za projektiranje


ER modeliranje

• ER modeliranje je iterativan postupak – realno je očekivati više “razvojnih” verzija modela

Entiteti

Atributi

Veze

• Postoji više rješenja problema – neka su optimalnija od drugih


Entitet

• Entitet je bilo koji objekt u sustavu koji ţelimo modelirati i

o kojem ţelimo saĉuvati informaciju

Pojedinačni objekti zovu se entiteti

Skupine objekata istog tipa zovu se tipovi entiteta ili skupovi entiteta

Moguća su dva tipa entiteta: jaki i slabi


Jaki i slabi tip entiteta

• JAKI entitet

Tip entiteta čija egzistencija nije vezana za postojanje nekog drugog tipa entiteta.

• SLABI entitet

Tip entiteta čija egzistencija ovisi o postojanju nekog drugog tipa entiteta, tj. onaj tip entiteta koji ne može postojati u bazi podataka ukoliko neki drugi tip entiteta takoĎer ne postoji u bazi.


Atribut

• Atribut je svaki detalj koji sluţi da pobliţe odredi,

identificira, klasificira, kvantificira ili izrazi stanje entiteta.

• Predstavlja opis entiteta


Veze

• Entiteti se mogu povezivati jedan s drugim u veze (relacije).

• Broj entiteta u vezi predstavlja STUPANJ VEZE.

Binarna veza

veza 2 entiteta

Ternarna veza

veza 3 entiteta

Unarna veza

isti entitet više puta

egzistira u različitim ulogama


Kardinalnost veze

• Odnos omjera meĊu povezanim entitetima nazivamo kardinalnost veze

- Jedan na jedan (1:1)

- Jedan na više (1:m)

- Više na jedan (m:1)

- Više na više (m:n)


Grafiĉki prikaz veze


Razbijanje M:N veza

• Veza m:n u ER modelu se moţe razbiti uvoĊenjem novog posredniĉkog entiteta.

Primjer:

• Vezu više na više možemo razbiti uvoĎenjem entiteta najam, koji sadrži atribut datum_najma


VEZA JEDAN:VIŠE

• Primarni ključ entiteta sa strane veze JEDAN doda se kao strani ključ u entitet sa strane veze VIŠE.

VEZA VIŠE:VIŠE

• Doda se novi entitet, koji sadrži primarne ključeve obaju rubnih entiteta.

• Ti atributi zajedno tvore složeni primarni ključ novonastalog entiteta.

Preslikavanje ER modela u relacije


Usporedne i povratne veze

Usporedne veze – dvije usporedne veze izmeĎu dva entiteta ...

Povratne veze – veza entiteta “na samog sebe” ...


Usporedne veze

• Svaku vezu zamijenimo s po jednim stranim ključem u relaciji na strani veze VIŠE (usporedne veze se preslikaju u jednu, ali s uvoĎenjem dodatnog stranog ključa).

• Da bi razlikovali veze meĎu entitetima stranim ključevima damo različite nazive.

Povratne veze

• Doda se strani ključ jednak primarnom ključu relacije.

• Za povratne veze vrijedi da je strani ključ jednak primarnom ključu relacije, ali pod drugim imenom.

Preslikavanje ER modela u relacije


UML (Unified Modeling Language)

Zašto UML (odnosno korištenje jedne notacije)?

• Korištenje jednog jezika i notacije bitno olakšava komunikaciju izmeĎu članova različitih timova (projektanti baze podataka, analitičari, programeri aplikacije) i time doprinosi da se svi sudionici koji participaraju u projektu osjećaju dijelom jedne cjeline.


Relacije u UML-u

ZAVISNOST (dependency)

ASOCIJACIJA (association)

AGREGACIJA (aggregation)

GENERALIZACIJA (generalization)

REALIZACIJA (realization)

1 1..*


UML notacija ...


Normalizacija podataka



• Normalizacija je proces kojime se nastoji eliminirati redundancija, ali tako da se sačuva integritet podataka u bazi

• Redundancija se izražava kroz pojam funkcijske zavisnosti

• Definiraju se normalne forme (NF)

prva NF, druga NF, treća NF, itd.

svaka normalna forma garantira da nema odreĎenog tipa zavisnosti

svaka viša NF uključuje prethodnu NF te dodatno ureĎuje model, tj. eliminira dodatne redundantnosti


Normalne forme

• 1. NF – Prva normalna forma

• 2. NF – Druga normalna forma

• 3. NF – Treća normalna forma

• BCNF – Boyce-Coddova normalna forma

1 NF, 2 NF, 3 NF i BCNF se temelje na funkcijskim zavisnostima.

• 4. NF – Četvrta normalna forma

Temelji se na višeznaĉnim zavisnostima.

• PJNF – Projekcijsko-spojna normalna forma

Temelji se na spojnim zavisnostima.


Definicije funkcijskih ovisnosti

Funkcijska ovisnost atributa

• Ako promatramo tablicu R sa atributima X i Y koji mogu biti kompozitni tj. složeni: za atribut Y tablice R kaže se da je funkcijski ovisan o atributu X iste tablice

R.X->R.Y

ako je svaka pojedina vrijednost atributa X povezana sa samo jednom vrijednošću atributa Y.



Potpuna funkcijska ovisnost atributa

• U tablici R s atributima X i Y koji mogu biti kompozitni tj. složeni, Y je potpuno funkcijski ovisan o X ako vrijedi da je Y funkcijski ovisan o X i nije funkcijski ovisan niti o jednom manjem podskupu atributa X.

Odnosno, ako vrijedi X->Y tada ne smije postojati niti jedan podskup Z koji sadrži samo dio atributa od kojih se sastoji atribut X, za koji bi vrijedilo da je Z->Y.



Tranzitivna funkcijska ovisnost atributa

• Ako vrijedi X->Y i Y-/->X (Y je funkcijski ovisan o X, a X nije funkcijski ovisan o Y), i ako Y->A (A je funkcijski ovisan o Y) tada vrijedi da je A funkcijski ovisan i o X (X->A).

Ako vrijedi A-/->Y tada je A striktno tranzitivno ovisan o X.


1NF

Prva normalna forma (1NF)

Tablica se nalazi u prvoj normalnoj formi ako su svi nekljuĉni atributi funkcijski ovisni o kljuĉu.

Uklanjanje ponavljajućih atributa ili grupa atributa


2NF

Druga normalna forma (2NF)

Tablica je u drugoj normalnoj formi ako i samo ako je u 1NF i ako su svi nekljuĉni atributi potpuno funkcijski ovisni o kljuĉu.

Uklanjanje atributa ovisnih samo o dijelu jedinstvenog identifikatora.


3NF

Treća normalna forma (3NF)

Tablica je u trećoj normalnoj formi ako i samo ako je u 2NF i ako niti jedan nekljuĉni atribut nije tranzitivno ovisan o kljuĉu.

Uklanjanje atributa ovisnih o atributima koji nisu dio jedinstvenog identifikatora.


Primjer normalizacije podataka

• Na slici je dana denormalizirana tablica s nazivima stupaca i vrijednostima redaka.

Napraviti normalizirani model podataka s pripadajućim entitetima, atributima i vezama izmeĊu njih.


Normalizacija podataka (1NF)

– Postoji funkcijska zavisnost :

Matbr → Prezime, Ime

– Ne postoji funkcijska zavisnost : Matbr → SifPred Matbr → NazPred Matbr → DatIsp Matbr → Ocjena Matbr → SifNas Matbr → PrezNas



Rješenje:

PK (STUDENT) = {Matbr}

PK (ISPIT) = {Matbr, SifPred, DatIsp}



{Matbr, SifPred, DatIsp} → {NazPred}

{SifPred} → {NazPred} dakle, ne postoji potpuna funkcijska ovisnost

neključnih atributa o ključu

ISPIT ne zadovoljava 2 NF !

Rješenje:



{Matbr, SifPred, DatIsp} → {SifNas}

{SifNas} → {PrezNas} dakle, postoji tranzitivna funkcijska ovisnost

(koju je potrebno eliminirati)

ISPIT ne zadovoljava 3 NF !

Rješenje:



Sve tablice zadovoljavaju 3 NF !

STUDENT (Matbr, Prezime, Ime)

PREDMET (SifPred, NazPred)

NASTAVNIK (SifNas, PrezNas)

ISPIT (Matbr, SifPred, DatIsp, Ocjena, SifNas)

Vaţno:

- Baza podataka treba biti barem u 3 NF !

- Osim 1NF, 2NF, 3NF postoje i BCNF (Boyce-Coddova normalna forma), 4NF i 5NF.


Relacijski model (UML notacija)


Modeliranje podataka Primjeri


Primjer 1.

• Profesionalni programer Ivo Ivić odlučio je napraviti program za evidentiranje svih programa koje je uradio, korisnika kod kojih ti programi rade, kao i ostvarene zarade po svakom programu.

Za svaki program se evidentira vrijeme utrošeno za njegovu izradu, kao i vrijeme utrošeno kod korisnika za prilagodbu programa korisničkim zahtjevima, kad je program pušten u rad kod korisnika, kao i koliko je od korisnika naplaćeno za taj program. TakoĎer se evidentira da li je program u uporabi tj. aktivan ili ne.


Primjer 1. ( ER model )


Primjer 1. ( Relacijski model )


Primjer 2.

• Faktura je dokument koji se šalje kupcu kako bi mogao izvršiti plaćanje kupljene robe. Da bi se napravila faktura moraju postojati osnovni podaci o kupcu (naziv, adresa, telefon i sl.), podaci o fakturi (broj fakture, datum izdavanja, broj narudžbe prema kojoj je raĎena, rok plaćanja, iznos za plaćanje i sl.), kao i podaci o kupljenim artiklima (naziv, jedinica mjere, kupljena količina, cijena i sl.).

Faktura se sastoji od 2 osnovna dijela:

- Zaglavlje fakture koje sadrži zajedničke, opće podatke

- Stavke fakture s pojedinačnim artiklima, količinama i cijenama.

Definirati sve entitete, atribute i veze za proces Fakturiranja kupcima.






Primjer 3.

• Na Fakultetu strojarstva i računarstva u Mostaru evidentirani su podaci o kandidatima koji su se prijavili na razradbeni ispit i njihovim rezultatima. Evidentiraju se podaci o:

- kandidatu: JMBG, ime, prezime, mjesto roĎenja, završena srednja škola (šifra, naziv, adresa, poštanski broj mjesta, mjesto, šifra općine i naziv općine u kojoj se škola nalazi)

- za svakog kandidata ocjena iz pojedinih predmeta iz srednje škole – šifra i naziv predmeta, razred i ocjena. Šifra odreĎuje predmet u nekom razredu (godini), npr. Matematika u 1.razredu i Matematika u 2.razredu imaju različite šifre. Isti predmeti u različitim školama imaju istu šifru npr. Matematika iz 1.razreda ima istu šifru za sve škole

- podaci o zadacima na razradbenom ispitu – redni broj zadatka, tekst zadatka, točan odgovor (A, B, C, D ili E)

- za svakog kandidata odgovori koje je dao na zadatke (odgovor za svaki pojedini zadatak mogu biti A, B, C, D, E ili ništa)






Primjer 4.

• U bazi podataka potrebno je evidentirati podatke o zrakoplovima, aerodromima i letovima.

Zrakoplov je identificiran svojim jedinstvenim registracijskim brojem (npr. N6061U). Za zrakoplov se evidentiraju godina proizvodnje i tip zrakoplova. Za svaki tip zrakoplova evidentira se šifra tipa i naziv tipa zrakoplova (npr. šifra: 123, naziv tipa: "Airbus-A319") te najveća ukupna dozvoljena težina pri polijetanju. Za svaki aerodrom se evidentira šifra i naziv aerodroma.

Zrakoplov prema namjeni može biti ili putnički ili teretni (jedno isključuje drugo). Za svaki pojedini zrakoplov, ovisno o njegovoj namjeni, evidentira se je li u zrakoplov ugraĎena dodatna oprema: za svaki pojedini putnički zrakoplov evidentira se ima li ugraĎenu internu televiziju, ima li ureĎaj za satelitsku komunikaciju, a za svaki pojedini teretni zrakoplov broj dodatno ugraĎenih klimatiziranih kontejnera za prijevoz životinja i je li ugraĎen katapult za izbacivanje tereta padobranom.


Primjer 4. (nastavak zadatka ...)

...

Evidentiraju se letovi samo putničkih zrakoplova. Let je identificiran šifrom i datumom leta (npr. "OU763", 1.6.2010), a za let se evidentira s kojeg aerodroma zrakoplov polijeće, na koji aerodrom slijeće te vrijeme polijetanja i vrijeme slijetanja. Evidentira se koji zrakoplov leti na kojem letu.

Evidentiraju se kategorije cijena karata. Svaka kategorija cijena ima svoju šifru (jedinstveno identificira kategoriju) i naziv (npr. "poslovna", "ekonomska", "s popustom za zaposlenika kompanije", "s popustom za osobe mlaĎe od 27 godina", itd). Putnik kupuje kartu točno odreĎene kategorije cijene za odreĎeni let. Putnik ne može za jedan let kupiti više od jedne karte. Za svakog putnika se evidentira jmbg (jedinstveno odreĎuje putnika), prezime i ime.






Modeliranje podataka Primjeri za vjeţbu


Primjer 1. (Evidentiranje objavljenih radova)

• Profesor programiranja Ivo Ivić odlučio je napraviti program za evidentiranje svojih objavljenih radova.

To podrazumijeva evidentiranje svih do sada objavljenih radova, naslova radova, koautora koji su s njim učestvovali u pisanju radova, godina objavljivanja kao i časopisa u kojima je objavljivano.

TakoĎer treba uspostaviti klasifikaciju radova po principu: znanstveni, stručni ili pregledni rad, te da li je rad objavljen u meĎunarodnom ili domaćem časopisu.

Za svaki rad unose se podaci o naslovu rada, klasifikacijama, koautorima i časopisu u kojem je rad objavljen.


Primjer 2. (Ugovori)

• Na slici je dana denormalizirana tablica UGOVORI s nazivima stupaca i vrijednostima redaka. Napraviti normalizirani model podataka s pripadajućim entitetima, atributima i vezama izmeĎu njih.


Primjer 3. (Filmovi)

• U bazi podataka su evidentirani podaci o filmovima. Za svaki film evidentira se žanr (šifra, naziv) i država (šifra, naziv).

Uz svaki film evidentiraju se različiti izvoĎači (šifra, ime, prezime) i funkcije koje su obavljali u filmu.

Funkcije su predstavljene kraticom i nazivom, a mogu biti npr. GL-glumac, RED-redatelj, SC-scenarist, SKL-skladatelj, itd.

Obratite pozornost na tip veze izmeĎu entiteta funkcija, izvoĎač i film:


Primjer 4. (Multipleks kino)

• Napraviti normalizirani model podataka s pripadajućim entitetima, atributima i vezama izmeĎu entiteta koji će podržavati proces rezervacije karata za multipleks kino.

U bazi podataka je potrebno evidentirati sljedeće podatke o filmovima: šifra, naziv, naziv originala, godina proizvodnje, trajanje filma, šifru i naziv žanra, glumce u filmu (šifra, ime, prezime).

Baza podataka takoĎer treba sadržavati popis dvorana u multipleks kinu (sifra, naziv, broj mjesta) kao i raspored svih projekcija filmova po dvoranama (datum i vrijeme projekcije, cijena karte za projekciju).


Primjer 5. (Tvrtka informatiĉke opreme)

• Tvrtka koja se bavi prodajom informatičke opreme prilikom prodaje iste sa svojim kupcima dogovara uvjete servisiranja opreme. U tvrtki radi više servisera i pri kupnji se ugovara koji je serviser zadužen za kojeg kupca s tim da na jednog servisera doĎe više kupaca. Jednim ugovorom se definira točno razdoblje servisiranja (od kojeg do kojeg datuma), a podrazumijeva više izlazaka servisera na teren unutar definiranog vremenskog razdoblja. Naravno, intervencija servisera nije nužna. Prilikom izlaska na teren potrebno je zabilježiti točno vrijeme odlaska i povratka, vrijeme provedenu na terenu izraženo u satima, te na kojoj je komponenti, ili više njih, vršena popravka.

Napraviti normalizirani model podataka s pripadajućim entitetima, atributima i vezama izmeĎu entiteta.


Primjer 6. (Tehniĉki biro)

• Napraviti normalizirani model podataka s pripadajućim entitetima, atributima i vezama izmeĎu entiteta koji bi osigurao evidentiranje projekata, rokova i izvršitelja u jednom tehničkom birou.

Osnovni način poslovanja tehničkog biroa jeste rad na izradi odreĎenih projekata, što znači da se za svaki projekt trebaju evidentirati osnovni podaci o naručitelju projekta (šifra, naziv, adresa, telefon, mail). Za svaki projekt postoji samo jedan glavni naručitelj s kojim se sklapa ugovor o poslu. O projektu se vode slijedeći podaci: naziv projekta, opis projekta, planirani datum početka rada na projektu, planirani svršetak rada na projektu, stvarni početak rada na projektu, stvarni svršetak rada na projektu, vrijednost projekta, ugovoreni penali za kašnjenje, dodatna napomena. Na svakom projektu radi više djelatnika iz biroa (šifra, ime, prezime, zanimanje, titula, adresa, telefon, mail) koji rade na odreĎenom radnom mjestu u birou (šifra, naziv radnog mjesta, opis). Projekt se razlaže na više različitih poslova (zadataka). Svakom članu projektnog tima dodjeljuje se točno odreĎeni posao (zadatak) što se posebno i evidentira. Uz svaki posao (zadatak) evidentira se i naziv zadatka, kratak opis, planirani početak, planirani svršetak, stvarni početak, stvarni svršetak, vrijednost i napomena.


Uvod u SQL


SQL

• SQL = Structured Query Language

• SQL je upitni jezik temeljen na relacijskoj algebri i predikatnom računu.

• SQL se koristi kao programski jezik i interaktivni upitni jezik. Kao programski jezik može se ugraĎivati u jezike treće i četvrte generacije.

• Zadaća SQL-a je omogućiti definiciju podataka, upravljanje podacima i provoĎenje kontrole nad podacima u relacijskoj bazi podataka.

• ProizvoĎači komercijalnih sustava takoĎer ugraĎuju i svoje, uglavnom nestandardne, DDL i DML naredbe.

Ti su nestandardni dijelovi problematični jer programski kod postaje neprenosiv izmeĎu različitih SQL sustava, a takoĎer se bitno otežava usaglašavanje oko budućih standarda.


SQL

• DDL (Data Definition Language)

= izrazi za definiranje podataka

CREATE, ALTER, DROP, GRANT, REVOKE ...

• DML (Data Manipulation Language)

= izrazi za upravljanje podacima

SELECT, INSERT, UPDATE, DELETE ...


SQL

• Primjer SQL naredbe iz DDL dijela jezika (kreiranje tablice mjesto):

CREATE TABLE mjesto

( pbr_mjesta VARCHAR2(5) NOT NULL ,

naziv_mjesta VARCHAR2(30) NOT NULL ,

sifra_opcine NUMBER(4)

);

• Primjer SQL naredbe iz DML dijela jezika (iz tablice mjesto dohvaća sve

n-torke kojima je vrijednost atributa poštanski broj jednaka 88000):

SELECT *

FROM mjesto

WHERE pbr = 88000;


Izvršavanje SQL iskaza (ORACLE server)


DDL naredbe Kreiranje tablica


Kreiranje tablica


SQL – Kreiranje i brisanje tablica

Kreiranje tablice:

CREATE TABLE ime_tablice

(ime_stupca tip (veličina) (ograničenje),

ime_stupca tip (veličina) (ograničenje),

ime_stupca tip (veličina) (ograničenje),

...);

Brisanje tablice:

DROP TABLE ime_tablice;


Ograniĉenja nad stupcima tablice i nad tablicama ...

• NULL/NOT NULL

• UNIQUE

• PRIMARY KEY

• FOREIGN KEY

• CHECK


Tipovi podataka (ORACLE)

• VARCHAR2(size)

• CHAR[(size)]

• NUMBER[(p,s)]

• DATE


Tipovi podataka Veliki objekti


PRIMJER – Relacijski model


SQL – Kreiranje tablica

CREATE TABLE MJESTO

( PBR NUMBER(10) NOT NULL,

NAZIV VARCHAR2(40) NOT NULL,

CONSTRAINT mjesto_pk PRIMARY KEY(PBR)

);


SQL – Kreiranje tablica

CREATE TABLE OSOBA

( MBR NUMBER(10) NOT NULL,

IME VARCHAR2(25) NOT NULL,

PREZIME VARCHAR2(25) NOT NULL,

EMAIL VARCHAR2(40),

PBR NUMBER(10) NOT NULL,

CONSTRAINT osoba_pk PRIMARY KEY(MBR),

CONSTRAINT osoba_mjesto_fk FOREIGN KEY(PBR)

REFERENCES MJESTO(PBR)

);


SQL – Izmjena definicije tablice

ALTER TABLE

dodavanje novih atributa

modificiranje postojećih atributa

definiranje default-ne vrijednosti za novi atribut

brisanje atributa


SQL – ALTER TABLE

Primjeri:

ALTER TABLE osoba

DROP COLUMN email;

ALTER TABLE osoba

ADD (email VARCHAR2(25));

ALTER TABLE mjesto

MODIFY (naziv VARCHAR2(50));


DML naredbe SELECT, INSERT, UPDATE, DELETE


Najĉešće korišteni DML izrazi

SELECT - Pretraţivanje podataka

INSERT - Upisivanje novih podataka

UPDATE - Promjena vrijednosti podataka

DELETE - Brisanje postojećih podataka


INSERT – Unos podataka u tablicu

• INSERT INTO ime_tablice (stupac, stupac,…) VALUES (vrijednost, vrijednost, …);

Primjeri:

• INSERT INTO osoba (mbr, ime, prezime, email)

VALUES (1, 'Ivo', 'Ivic', '[email protected]');

• INSERT INTO osoba

VALUES (1, 'Ivo', 'Ivic', '[email protected]');


INSERT – Unos podataka u tablicu

• INSERT se može koristiti i za kopiranje podataka

iz druge tablice.

Primjer:

• INSERT INTO osoba_2 (mbr, ime, prezime, email)

SELECT mbr, ime, prezime, email

FROM osoba;


UPDATE – Aţuriranje podataka u tablici

• UPDATE ime_tablice [alias] SET

stupac [,stupac…] = {iskaz, podupit}

[WHERE uvjet];

Primjer:

• UPDATE osoba SET email='[email protected]'

WHERE mbr=1;


DELETE – Brisanje podataka u tablici

• DELETE FROM ime_tablice

[WHERE uvjet];

Primjer:

• DELETE FROM osoba

WHERE mbr=2;


SELECT – Selektiranje podataka iz tablice

• SELECT stupac, stupac, stupac, …

FROM ime_tablice

[WHERE uvjet];

Primjeri:

• SELECT mbr, ime, prezime, email

FROM osoba;

• SELECT * FROM osoba;


INSERT – Primjeri

• INSERT INTO mjesto (pbr, naziv)

VALUES (88000, 'Mostar');

• INSERT INTO mjesto (pbr, naziv)

VALUES (88220, 'Široki Brijeg');

• INSERT INTO osoba (mbr, ime, prezime, email, pbr) VALUES (1, 'Ivo', 'Ivic', '[email protected]', 88000);

• INSERT INTO osoba (mbr, ime, prezime, pbr) VALUES (2, 'Mate', 'Matic', 88220);


INSERT – Primjeri

• INSERT INTO osoba (mbr, ime, prezime, email, pbr) VALUES (2, 'Pero', 'Peric', '[email protected]', 88000);

→ ORA-00001: unique constraint (PC-1.OSOBA_PK) violated

• INSERT INTO osoba (mbr, ime, prezime, email, pbr) VALUES (3, 'Pero', 'Peric', '[email protected]', 90000);

→ ORA-02291: integrity constraint (PC-1.OSOBA_MJESTO_FK) violated - parent key not found

• INSERT INTO osoba (mbr, ime, email, pbr) VALUES (3, 'Pero', '[email protected]', 88000);

→ ORA-01400: cannot insert NULL into ("OSOBA"."PREZIME")


UPDATE – Primjeri

• UPDATE mjesto SET pbr=10000

WHERE naziv='Mostar';

→ ORA-02292: integrity constraint (PC-1.OSOBA_MJESTO_FK) violated - child record found

• UPDATE mjesto SET naziv='Š.Brijeg'

WHERE pbr=88220;

• UPDATE osoba SET email='[email protected]'

WHERE mbr=2;


DELETE – Primjeri

• DELETE FROM mjesto

WHERE pbr=88000;

→ ORA-02292: integrity constraint (PC-1.OSOBA_MJESTO_FK) violated - child record found

• DELETE FROM osoba

WHERE mbr=1;

• DELETE FROM mjesto

WHERE pbr=88000;


Sigurnost baze podataka


Sigurnost i integritet

• Sigurnost baze podataka se brine da samo ovlašteni korisnici pristupaju podacima

• Integritet baze podataka se brine da ovlašteni korisnici koriste podatke na ispravan način

Integritet:

korektnost (dopuštene zdravorazumske vrijednosti podataka)

konzistencija (meĎusobna suglasnost podataka)


Korisnici i sigurnost


Korisnici i sigurnost

• CREATE USER pero IDENTIFIED BY pero;

• CONNECT pero/pero;

• ALTER USER pero IDENTIFIED BY pero1;


Sistemske privilegije

• više od 100 sistemskih privilegija

• Tipiĉne DBA privilegije:

– CREATE USER

– DROP USER

– DROP ANY TABLE

– BACKUP ANY TABLE

– SELECT ANY TABLE

– CREATE ANY TABLE



• Osnovna sintaksa za dodjeljivanje sistemskih privilegija:

GRANT sistemske_privilegije

TO korisnik | uloga | PUBLIC

[WITH ADMIN OPTION]

• Osnovna sintaksa za ukidanje sistemskih privilegija:

REVOKE sistemske_privilegije

FROM korisnik | uloga | PUBLIC



Primjeri:

• GRANT create session, create table,

create sequence, create view

TO pero;

• REVOKE create view

FROM pero;


Uloga (Role)

Korisnici

Privilegije

Uloga

Dodjeljivanje privilegija korisnicima bez definirane uloge

Dodjeljivanje privilegija korisnicima nakon definiranja uloge


Uloga (Role)

• CREATE ROLE uloga_1 IDENTIFIED BY uloga_1;

• GRANT create session, create table, create view

TO uloga_1;

• GRANT uloga_1

TO pero;


Objektne privilegije

Najčešće korištene objektne privilegije su:

• SELECT – tablice, pogledi, sekvence

• INSERT, UPDATE, DELETE – tablice, pogledi

• INDEX, REFERENCES – tablice

• ALTER – tablice, sekvence

• EXECUTE – procedure

• ALL, ALL PRIVILEGES



• Osnovna sintaksa za dodjeljivanje objektnih privilegija:

GRANT objektne_privilegije

ON ime_objekta

TO korisnik | uloga | PUBLIC

[WITH GRANT OPTION]

• Osnovna sintaksa za ukidanje objektnih privilegija:

REVOKE objektne_privilegije

ON ime_objekta

FROM korisnik | uloga | PUBLIC



Primjer:

• GRANT select, insert

ON osoba

TO pero, mate

WITH GRANT OPTION;

• GRANT select

ON mjesto

TO PUBLIC;


Upravljanje transakcijama



• Pod transakcijom se podrazumijeva aktivnost ili niz aktivnosti koje izvršava jedan korisnik ili aplikacijski program, a koja ĉita ili aţurira sadrţaj baze podataka.

• To je logička radna jedinica baze podataka

• Transakcija se logički mora provesti kao nedjeljiva cjelina

svaka transakcija unosi promjenu u bazi

pojedinačne operacije unutar transakcije nisu bitne same za sebe



1) UPDATE racun SET saldo=saldo-500

WHERE id_racuna=1;

2) UPDATE racun SET saldo=saldo+500

WHERE id_racuna=2;

Transakcija se mora izvršiti u potpunosti (u gornjem sluĉaju obe

UPDATE naredbe) ili nikako – “SVE ili NIŠTA”

Raĉun 1 Raĉun 2

500 KM

5.000 KM 1.000 KM


Osobine transakcija

Tzv. ACID osobine transakcija:

• Atomicity – „sve ili ništa‟ (transakcije nije moguće samo

djelomično izvršiti)

• Consistency – transakcija mora transformirati bazu iz jednog

konzistentnog stanja u drugo

• Isolation – učinak transakcije postaje vidljiv drugim transakcijama

tek nakon završetka transakcije promatrajući izvana transakcija može biti ili izvedena ili ne

• Durability – rezultat uspješno završenih (potvrĎenih) transakcija

se trajno bilježi u bazu podataka i ne smije se izgubiti zbog naknadnih grešaka (čak ni u slučaju pada sustava)


Upravljanje transakcijama (ORACLE)

• 2 tipa transakcija:

o DDL – sadrži jedan DDL iskaz

o DML – sadrži jedan ili više DML iskaza

• Transakcija zapoĉinje kada je:

o DDL naredba izdana

o Pokrenut prvi DML iskaz nakon COMMIT-a

• Transakcija se moţe završiti na sljedeći naĉin:

o COMMIT iskazom – potvrdi sve izmjene

o ROLLBACK iskazom – poništi sve izmjene

o DDL iskazom → automatski COMMIT

o Padom sustava → automatski ROLLBACK


Upravljanje transakcijama Primjer

SELECT placa FROM djelatnik WHERE id_djelatnika=1;

UPDATE djelatnik SET placa=placa+1000 WHERE id_djelatnika=1;

COMMIT;

t1

t2

t3

t4

t5

Vrijeme Sesija 1 Sesija 2



2000

2000 3000



3000 3000


Upravljanje transakcijama Primjer



ROLLBACK;

t1

t2

t3

t4

t5




2000

2000 3000



2000 2000


Tehnike kontrole konkurentnosti

Konzervativne (pesimistiĉne) tehnike

• uzrokuju odgaĎanje transakcija u slučaju da će biti u konfliktu s drugim transakcijama u budućnosti

-> Zakljuĉavanje (locking)

Optimistiĉne tehnike

• bazirane na pretpostavci da su konflikti rijetki tako da dozvoljavaju transakcijama da nastave i nesinkronizirane

• provjeravaju konflikt na kraju (kada se transakcija potvrĎuje)


Zakljuĉavanje (locking)

Dijeljeno zakljuĉavanje (shared lock, read lock)

Kljuĉ za ĉitanje – npr. transakcija SQL naredbom SELECT zaključa objekt za čitanje.

Bilo koja druga transakcija taj objekt moţe zakljuĉati za ĉitanje, ali ga niti jedna transakcija ne moţe zakljuĉati za pisanje.

Ekskluzivno zakljuĉavanje (exclusive lock, write lock)

Kljuĉ za pisanje – npr. transakcija SQL naredbom (INSERT, UPDATE ili DELETE) zaključa objekt za pisanje.

Niti jedna transakcija taj objekt ne moţe zakljuĉati niti za ĉitanje niti za pisanje, dok ga transakcija u kojoj je izvršeno zaključavanje ne otključa.



Proces1 – postavio ključ na objekt

Proces2 – pokušava postaviti ključ na isti objekt kao i Proces1


Protokol dvofaznog zakljuĉavanja

Two-phase locking protocol (2PL)

1) prije obavljanja operacije nad objektom (npr. n-torkom iz baze), transakcija mora za taj objekt zatražiti ključ

2) nakon otpuštanja ključa, transakcija ne smije više zatražiti nikakav ključ

Transakcije koje poštuju 2PL protokol imaju 2 faze:

1) fazu pribavljanja ključeva (faza rasta - growing phase)

2) fazu otpuštanja ključeva (fazu suţavanja - shrinking phase) -> COMMIT ili ROLLBACK na kraju transakcije



• Svojstvo nesmetanog konkurentnog (višekorisničkog) izvoĎenja transakcija naziva se serijalizabilnost.

• Serijalizabilnost (serializability) redoslijeda izvršavanja transakcija je osigurana ako sve transakcije poštuju protokol dvofaznog zaključavanja (2PL).



Razine izolacije (isolation levels)

• Kod zapisivanja se uvijek traži ekskluzivno zaključavanje koje se zadržava do kraja transakcije.

• Kod ĉitanja možemo imati različite načine zaključavanja:

o read uncommitted

čitanje bez zaključavanja;

o read committed

zahtijeva dijeljeno zaključavanje za sve zapise koji su dohvaćeni upitima;

otključava zapise odmah nakon što su pročitani;

o repeatable read

zahtijeva dijeljeno zaključavanje za sve zapise koji su dohvaćeni upitima;

podaci ostaju zaključani do kraja transakcije;


Granulacija zakljuĉavanja

• Granulacija je odreĎena veličinom objekta koji se zaključava:

o n-torka, stranica (fizički blok na kojem su zapisi pohranjeni), tablica ili baza podataka.


Mrtva toĉka (deadlock)

• Mrtva toĉka (deadlock) nastaje kada dvije (ili više)

transakcija, obje (sve) čekaju da se otpusti zaključavanje koje drži druga transakcija.


Deadlock Primjer

UPDATE djelatnik SET placa=placa-500 WHERE id_djelatnika=2;

t1

t2

t3

t4

t5



UPDATE djelatnik SET placa=placa-500 WHERE id_djelatnika=2;


→ ORA-00060: deadlock detected while waiting for resource


Upravljanje transakcijama i zakljuĉavanje

• Stanje sustava prije COMMIT ili ROLLBACK naredbe:

– moguće je vratiti sustav u stanje prije izvršavanja naredbi iz transakcije

– korisnik koji radi izmjene podataka kroz transakciju može vidjeti efekte tih izmjena (npr. izvršavanjem SELECT iskaza)

– ostali korisnici ne mogu vidjeti efekte navedenih izmjena

Zakljuĉavanje:

– n-torke nad kojima se rade izmjene kroz transakciju (INSERT, UPDATE, DELETE) automatski se zaključavaju i ostali korisnici ih ne mogu mijenjati

Napomena: Npr. u Oracle sustavu implicitno zakljuĉavanje će se desiti za sve SQL iskaze osim SELECT-a



• Stanje sustava nakon izvršavanja COMMIT naredbe:

– izmjene podataka u bazi postaju trajne

– sustav se više ne može vratiti u stanje prije izvršavanja naredbi iz transakcije

– svi korisnici mogu vidjeti efekte izmjena učinjenih kroz transakciju

Zakljuĉavanje:

– n-torke nad kojima su vršene izmjene kroz transakciju nisu više zaključane i navedene n-torke postaju dostupne za izmjenu i drugim korisnicima


• Stanje sustava nakon izvršavanja ROLLBACK naredbe:

– izmjene podataka u bazi se poništavaju

– sustav se vraća u stanje prije izvršavanja naredbi iz transakcije

Zakljuĉavanje:

– n-torke koje su bile implicitno zaključane kroz transakciju nisu više zaključane te postaju dostupne za izmjenu i drugim korisnicima



Objekti u bazi podataka TABLE, VIEW, INDEX, SEQUENCE, SYNONYM,

STORED PROCEDURE, TRIGGER


Objekti u bazi podataka

• TABLE – Tablica

• VIEW – Pogled

• INDEX – Indeks

• SEQUENCE – Sekvenca (Oracle)

• SYNONYM – Sinonim

• STORED PROCEDURE – Pohranjena procedura

• TRIGGER – Okidač


Pogled (VIEW)

Što je pogled?

o “prozor” u podatke

o podaci se izvode, ne posjeduju

o pohranjuje se kao SELECT izraz u rječnik podataka

Uporaba pogleda

o za ograničenje pristupa podacima

o za pojednostavljenje složenih upita

o za omogućavanje neovisnosti podataka

o za prikaz različitih pogleda na iste podatke


Pogled (VIEW)


Pogled (VIEW)

Jednostavni pogled

o podaci su iz jedne tablice

o ne sadrži funkcije ili grupe

o može izvršiti DML

Sloţeni pogled

o podaci su iz više tablica

o sadrži funkcije ili grupe

o ne može izvršiti DML


Kreiranje pogleda (VIEW)

CREATE OR REPLACE VIEW djelatnik_imenik

AS

SELECT id_djelatnika, ime, prezime, email, telefon

FROM djelatnik;

CREATE VIEW radno_mj_stat (radmj,minplac,maxplac,prosjek)

AS

SELECT rm.naziv_radmj, min(placa), max(placa), avg(placa)

FROM djelatnik d, radno_mjesto rm

WHERE d.sifra_radmj=rm.sifra_radmj

GROUP BY rm.naziv_radmj;


Brisanje pogleda (VIEW)

• Pogled možete izbrisati bez ikakvog gubitka podataka jer je pogled (view) baziran na tablicama u bazi.

• Brisanje pogleda nema nikakvog utjecaja na te tablice i podatke u njima.

DROP VIEW ime_pogleda


Indeks (INDEX)

o Brzina pristupa podacima u relaciji je važno svojstvo sustava za upravljanje podacima. Najjednostavniji način pristupa, sekvencijalna pretraga, u većini slučajeva ne zadovoljava.

o Kreiranjem indeksa formira se struktura B-stabla koja omogućava nesekvencijalni pristup do n-torke u relaciji. Nesekvencijalni pristup moguć je prema vrijednostima onih atributa nad kojima je izgraĎena indeksna struktura.

o Nad jednom relacijom može biti izgraĎeno više indeksa, od kojih svaki može sadržavati jedan ili više atributa.

o Osim radi poboljšanja performansi sustava, indeksi se kreiraju i radi osiguranja jedinstvenosti vrijednosti atributa u relaciji.


Kreiranje indeksa (INDEX)

AUTOMATSKI

• UNIQUE INDEX se automatski kreira kada se definira PRIMARY KEY ili UNIQUE CONSTRAINT u definiciji tablice.

RUĈNO

• Korisnik može ručno dodati indeks na neki drugi atribut (radi ubrzanja pristupa podacima).

Primjer:

• CREATE INDEX djelatnik_prez_idx

ON djelatnik(prezime);


Indeks (INDEX)

Indekse bi u principu trebalo primjenjivati u sljedećim sluĉajevima:

• za atribute prema kojima se obavlja spajanje relacija

• za atribute koji se često koriste za postavljanje uvjeta selekcije

• za atribute prema kojima se često obavlja grupiranje ili sortiranje


Indeks (INDEX)

Prilikom kreiranja indeksa treba voditi raĉuna i o nekim njihovim negativnim aspektima, te ih treba koristiti samo tamo gdje je njihova uporaba opravdana.

• Indeksi zauzimaju značajan prostor

• Ažuriranje vrijednosti atributa nad kojima je izgraĎen indeks traje znatno dulje nego ažuriranje vrijednosti nad kojima nema indeksa (ovdje treba razlikovati atribute prema kojima se pronalaze n-torke koje treba ažurirati, od atributa čije se vrijednosti ažuriraju)


Indeks (INDEX)

Indekse ne bi trebalo primjenjivati ukoliko:

• vrijednosti atributa za kojeg se gradi indeks imaju relativno mali broj različitih vrijednosti (npr. spol_osobe s dopuštenim vrijednostima M, Ţ, u relaciji s 30 000 n-torki)

• u relaciji predstoji velik broj upisa, izmjena ili brisanja n-torki. Preporučljivo je u takvim slučajevima postojeće indekse izbrisati, te ih ponovo izgraditi tek nakon obavljenih promjena na podacima.

• relacija sadrži vrlo mali broj n-torki (npr. do stotinu). U takvim slučajevima sustav lakše pristupa sekvencijalnom pretragom, nego prolaskom kroz strukturu B-stabla.


Primarni kljuĉ (PK) – Automatsko generiranje vrijednosti

• Oracle –> SEQUENCE, IDENTITY (od v.12c)

• MS SQL Server –> IDENTITY

• MS Access –> AUTONUMBER

• MySQL –> AUTO_INCREMENT

• PostgreSQL –> SERIAL, BIGSERIAL

• ...


Sekvenca (SEQUENCE)

Primjer:

Sekvenca (Oracle)

o automatski generira jedinstveni broj

o najčešće se koristi za dodijeljivanje vrijednosti PK (PRIMARNOM KLJUČU)

o sekvenci može pristupati više korisnika


Sekvenca (SEQUENCE)

• CREATE SEQUENCE odjel_sifra_seq

INCREMENT BY 1

START WITH 1

MAXVALUE 9999

NOCACHE

NOCYCLE;


Sekvenca (SEQUENCE)

• INSERT INTO odjel (sifra_odjela, naziv_odjela)

VALUES (odjel_sifra_seq.NEXTVAL, 'Strategija i razvoj');

• SELECT odjel_sifra_seq.CURRVAL

FROM dual;


Sinonim (SYNONYM)

Sinonim (Synonym) je drugi naziv za objekt

koristan kod referenciranja na objekte drugih korisnika.

Primjer:

CREATE [PUBLIC] SYNONYM ime_sinonima

FOR [vlasnik.]ime_objekta;

CREATE SYNONYM djelatnik

FOR fsr.djelatnik;


Pohranjena procedura (STORED PROCEDURE)

• Pohranjena procedura ili pohranjena funkcija je

potprogram koji je pohranjen u rječniku podataka i koji se izvršava u kontekstu sustava za upravljanje bazama podataka.

• Može se promatrati kao procedura ili funkcija kojom se proširuje skup SQL funkcija ugraĎenih u SUBP.

o Pohranjena procedura je potprogram koji u pozivajući

program ne vraća rezultat.

o Funkcija je potprogram koji u pozivajući program vraća

rezultat.


• ProizvoĎači SUBP koriste vlastite inačice jezika za definiranje pohranjenih procedura (standard postoji, ali je rijetko gdje implementiran)

o Oracle: PL/SQL PL/SQL (Procedural Language / Structured Query Language)

o Microsoft SQL Server: T-SQL T-SQL (Transact-SQL)

• Navedeni jezici proširuju mogućnosti SQL jezika proceduralnim elementima koji se koriste u strukturiranim jezicima (C, Java, ...).

Osim SQL naredbi, pohranjene procedure omogućuju korištenje:

o varijabli

o naredbi za kontrolu toka programa (if, for, while, ...)

o naredbi za rukovanje iznimkama (exception handling)



• Upotrebom pohranjenih procedura omogućena je zaštita podataka na razini funkcije (a ne samo objekta).

• Osnovna sintaksa za dodjeljivanje dozvole za izvršavanje procedure:

GRANT EXECUTE

ON { ime_procedure | ime_funkcije } TO { korisnici | uloge | PUBLIC } [ WITH GRANT OPTION ]

• Osnovna sintaksa za ukidanje dozvole za izvršavanje procedure:

REVOKE EXECUTE

ON { ime_procedure | ime_funkcije } FROM { korisnici | uloge | PUBLIC } [ CASCADE | RESTRICT ]



• Upotrebom pohranjenih procedura omogućena je upotreba klijent-server arhitekture oslonjene na server.

o postiže se veća učinkovitost (efikasnost) SUBP

(SUBP ne mora ponavljati prevoĎenje i optimiranje SQL upita)

o postiže se veća produktivnost programera i smanjuje se mogućnost pogreške

(Programski kôd potreban za obavljanje nekog postupka koji čini logičku cjelinu implementira se i testira na samo jednom mjestu)



Primjer (klijent-server arhitektura oslonjena na klijenta)

1) SELECT COUNT (*) FROM racun

WHERE id_racuna=1;

2) SELECT COUNT (*) FROM racun

WHERE id_racuna=2;

3) UPDATE racun SET saldo=saldo-500

WHERE id_racuna=1;

4) UPDATE racun SET saldo=saldo+500

WHERE id_racuna=2;

Primjer: Prebacivanje iznosa s jednog raĉuna na drugi Prvo se provjerava postoje li zadani brojevi računa i ako postoje, prebacuje se iznos (od 500 KM) s jednog računa na drugi.


Primjer (klijent-server arhitektura oslonjena na server)

EXECUTE PROCEDURE

prebaci (1, 2, 500);

CREATE PROCEDURE prebaci (...)

DEFINE ...

SELECT ...

SELECT ...

UPDATE ...

UPDATE ...

END PROCEDURE;

Primjer: Prebacivanje iznosa s jednog raĉuna na drugi Prvo se provjerava postoje li zadani brojevi računa i ako postoje, prebacuje se iznos (od 500 KM) s jednog računa na drugi (rješenje s korištenjem pohranjene procedure).


Primjer (klijent-server arhitektura oslonjena na klijent / server)


Okidaĉ (TRIGGER)

“Pasivni” SUBP

• konvencionalni SUBP je pasivan

• operacije nad podacima se izvršavaju isključivo na temelju eksplicitnog zahtjeva korisnika / aplikacije

“Aktivni” SUBP i “aktivne” baze podataka

• aktivni SUBP autonomno reagira na odreĎene dogaĎaje (events)

• u aktivnim bazama podataka neke operacije nad podacima se izvršavaju automatski, reakcijom na odreĎeni dogaĎaj ili stanje


• SUBP – definiranje aktivnih pravila (active rules)

• DogaĊaj-Uvjet-Akcija (ECA: Event-Condition-Action)

→ Okidaĉi (triggers)

o dogaĊaj (event): ako se dogodi, izračunava se uvjet (npr. unos - INSERT, izmjena - UPDATE ili brisanje - DELETE podataka)

o uvjet (condition): ako je rezultat izračunavanja uvjeta istina, obavljaju se akcije

o akcije (action): niz operacija, najčešće operacije nad podacima

ON event IF condition THEN action

Okidaĉ (TRIGGER)


• Okidaĉi (trigeri) se izvršavaju automatski kod izvršavanja akcijskih SQL upita (INSERT, UPDATE, DELETE) nad pojedinim tablicama u bazi podataka.

Okidaĉ (TRIGGER)


• Pri definiciji okidača moguće je specificirati koje akcije (operacije) aktiviraju okidač (triger):

INSERT, UPDATE, DELETE

• TakoĎer, pri definiciji okidača moguće je specificirati da li se akcije navedene u samom okidaču obavljaju:

o nakon što se obavi operacija koja je aktivirala okidač

AFTER INSERT, AFTER UPDATE, AFTER DELETE

o prije nego se obavi operacija koja je aktivirala okidač

BEFORE INSERT, BEFORE UPDATE, BEFORE DELETE

o te da li se akcije u okidaču obavljaju jednom za svaku n-torku na koju je djelovala operacija koja je aktivirala okidač

FOR EACH ROW

Okidaĉ (TRIGGER)


• Primjeri primjene okidaĉa (trigera):

o evidentiranje (logiranje) promjena nad podacima,

o implementacija integritetskih ograničenja,

o ažuriranje izvedenih atributa (npr. saldo računa),

o praćenje rada korisnika (logiranje pristupa bazi ...),

o sustavi obavještavanja,

o itd.

Okidaĉ (TRIGGER)


Web:

http://www.fsr.ba/~goran

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: [email protected]

[email protected]

Baze podataka

Documents

BAZE PODATAKAuni-mo.sve-mo.ba/~goran/nastava/BAZE_Predavanja.pdf · Punjenje baze podataka Testiranje Kreiranje formi Kreiranje izvješća Kreiranje Upita Pisanje koda aplikacije