baze predavanja

8/10/2019 BAZE Predavanja

http://slidepdf.com/reader/full/baze-predavanja 1/180

Ak.god. 2014/2015. B AZE PODATAKA 1

B AZE PODATAKA

FAKULTET STROJARSTVA I RAĈUNARSTVA

SVEUĈILIŠTE U MOSTARU

Doc.dr.sc. GORAN K RALJEVIĆ




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 bodovadobit ć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 bodovadobit će 5 bodova koji će im se pribrojiti na svim pismenim ispitnimrokovima 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ČIVOkroz 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/ilistrojne opreme




Ciljevi razvoja baza podataka

• Razdvajanje podataka od aplikacija koje ih koriste

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

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




Faze razvoja baza podataka

FAZE razvoja Baza podataka Aplikacija

Zahtjevi

(analiza)

Izrada modela podataka

Specificiranje podataka

Definiranje ograničenja iposlovnih pravila

UtvrĎivanje zahtjeva zaaplikaciju

Dizajn

Tablice

RelacijeIndeksi

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 UpitaPisanje 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 izravnoadresiraju mjesto zapisa na disku



Ak.god. 2014/2015.

B AZE PODATAKA 13

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



Ak.god. 2014/2015.

B AZE PODATAKA 14

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



Ak.god. 2014/2015.

B AZE PODATAKA 15

Sustav za upravljanje bazama podataka

• SUBP (DBMS - Database Management System)

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

• K orisnički programi ne pristupaju podacimadirektno već preko DBMS-a

• Korisnik ili korisnički program postavlja zahtjevza obavljanjem neke operacije s podacima, aSUBP ga analizira, provjerava, optimizira,transformira u niz operacija koje je potrebno

obaviti na fizičkoj razini, obavlja operacije ivraća rezultat.



Ak.god. 2014/2015.

B AZE PODATAKA 16

Fiziĉka i logiĉka organizacija podataka

• Vaţna posljedica primjene SUBP jest razdvajanje fiziĉke i logiĉke

organizacije podataka. Dok logičkaorganizacija podataka predstavljaorganizaciju sa stanovišta korisnika bazepodataka ili programera te jekoncentrirana na vrste podataka injihove meĎusobne logičke veze, fizičkaorganizacija predstavlja organizaciju

fizičke pohrane podataka unutarračunala. Oblik i organizacijapohranjenih podataka tu su čestopotpuno različiti od njihovog logičkogoblika i organizacije.

• U okviru toga, zadaća je SUBP-aomogućiti korisniku (programeru)manipuliranje podacima uzpoznavanje samo logiĉkog opisabaze podataka, a ne nužno ipoznavanja načina fizičke pohranepodataka.



Ak.god. 2014/2015.

B AZE PODATAKA 17


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 odneovlaštenog pristupa

̶ Očuvanje integriteta(backup i recovery)

̶ Statističko praćenje

rada baze podataka ̶ Optimizacija rada



Ak.god. 2014/2015.

B AZE PODATAKA 18


Glavni proizvoĊaĉi SUBP (DBMS):



Ak.god. 2014/2015.

B AZE PODATAKA 19

Relacijski model podataka



Ak.god. 2014/2015.

B AZE PODATAKA 20


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

̶ Relacija

̶ Atribut

̶ Domena



Ak.god. 2014/2015.

B AZE PODATAKA 21


• 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



Ak.god. 2014/2015.

B AZE PODATAKA 22

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 nemanijedan odgovarajući podskup koji bi bio super ključ unutar relacije.

• Primarni kljuĉ (primary key) – kandidat ključ koji je odabranda jedinstveno odredi n-torku unutar relacije.

• Jedinstveni kljuĉ (unique key) – kandidat ključ koji nijeodabran da bude primarni ključ.



Ak.god. 2014/2015.

B AZE PODATAKA 23


Primjer:

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

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

• Primarni kljuĉ: {Matbr}• Jedinstveni kljuĉ: {JMBG}



Ak.god. 2014/2015.

B AZE PODATAKA 24


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

• Jedinstvenost … na relacijskoj shemi niti u jednom trenutkune mogu postojati dvije n-torke s jednakim vrijednostimaskupa atributa K.

• Minimalnost … niti jedan pravi podskup od skupa atributa Knema 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ĉevamoţe imati više.



Ak.god. 2014/2015.

B AZE PODATAKA 25


• 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:



Ak.god. 2014/2015.

B AZE PODATAKA 26

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



Ak.god. 2014/2015.

B AZE PODATAKA 27

Entitetski integritet

• Vrijednost primarnog kljuĉa kao cjeline, ne smije biti

jednaka NULL vrijednosti. Ako je primarni ključ relacije složen, niti jedna njegova komponentane 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 jednakimvrijednostima kljuĉa (vrijedi za sve moguće kljuĉeve).



Ak.god. 2014/2015.

B AZE PODATAKA 28

Referencijalni integritet

• Ako u relacijskoj shemi R postoji strani kljuĉ (foreign key)

koji odgovara primarnom kljuĉu (primary key) relacijskesheme 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 urelaciji OSOBA postoji vrijednost stranog ključa (77000) za koju ne postojiodgovarajuća n-torka u relaciji MJESTO.



Ak.god. 2014/2015.

B AZE PODATAKA 29

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 skupomdozvoljenih 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.



Ak.god. 2014/2015.

B AZE PODATAKA 30

Operacije u relacijskom modelu

Osnovne operacije u relacijskom modelu:

• Unija

• Razlika

• Presjek

• Kartezijev produkt

• Projekcija

• Selekcija

• Spajanje (join)



Ak.god. 2014/2015.

B AZE PODATAKA 31


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



Ak.god. 2014/2015.

B AZE PODATAKA 32


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

ali se ne nalaze u drugoj relaciji



Ak.god. 2014/2015.

B AZE PODATAKA 33


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

ij l ij k d l



Ak.god. 2014/2015.

B AZE PODATAKA 34


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

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

O ij l ij k d l



Ak.god. 2014/2015.

B AZE PODATAKA 35


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

O ij l ij k d l



Ak.god. 2014/2015.

B AZE PODATAKA 36


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

one n-torke koje zadovoljavaju postavljene uvjete

O ij l ij k d l



Ak.god. 2014/2015.

B AZE PODATAKA 37


• 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 sevrijednosti uspostavlja veza

O ij l ij k d l



Ak.god. 2014/2015.

B AZE PODATAKA 38


• 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 relacijskealgebre može izvesti veliki broj kombinacija za obradu i analizupodataka.

• Prijevod operacija relacijske algebre u jezik za definiciju i

manipulaciju podacima koji danas predstavlja osnovni standardza relacijske baze podataka: SQL.



Ak.god. 2014/2015.

B AZE PODATAKA 39

Modeliranje podataka




Ak.god. 2014/2015.

B AZE PODATAKA 40


ER modeliranje



Ak.god. 2014/2015.

B AZE PODATAKA 41

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



Ak.god. 2014/2015.

B AZE PODATAKA 42

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 optimalnijaod drugih

Entitet



Ak.god. 2014/2015.

B AZE PODATAKA 43

Entitet

• Entitet je bilo koji objekt u sustavu koji ţelimo modelirati io 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



Ak.god. 2014/2015.

B AZE PODATAKA 44

Jaki i slabi tip entiteta

• JAKI entitet

Tip entiteta čija egzistencija nije vezana za postojanje nekogdrugog tipa entiteta.

• SLABI entitet

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

Atribut



Ak.god. 2014/2015.

B AZE PODATAKA 45

Atribut

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

identificira, klasificira, kvantificira ili izrazi stanje entiteta.• Predstavlja opis entiteta

Veze



Ak.god. 2014/2015.

B AZE PODATAKA 46

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 putaegzistira u različitimulogama

Kardinalnost veze



Ak.god. 2014/2015.

B AZE PODATAKA 47

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



Ak.god. 2014/2015.

B AZE PODATAKA 48

Grafiĉki prikaz veze

Razbijanje M:N veza



Ak.god. 2014/2015.

B AZE PODATAKA 49

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žiatribut datum_najma

Preslikavanje ER modela u relacije



Ak.god. 2014/2015.

B AZE PODATAKA 50

VEZA JEDAN:VIŠE

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

VEZA VIŠE:VIŠE

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

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


Usporedne i povratne veze



Ak.god. 2014/2015.

B AZE PODATAKA 51

Usporedne i povratne veze

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

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




Ak.god. 2014/2015.

B AZE PODATAKA 52

Usporedne veze

• Svaku vezu zamijenimo s po jednim stranim ključem u relacijina strani veze VIŠE (usporedne veze se preslikaju u jednu, alis 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 primarnomključu relacije, ali pod drugim imenom.


UML (Unified Modeling Language)



Ak.god. 2014/2015.

B AZE PODATAKA 53

UML (Unified Modeling Language)

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

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

cjeline.

Relacije u UML-u



Ak.god. 2014/2015.

B AZE PODATAKA 54

Relacije u UML u

ZAVISNOST (dependency)

ASOCIJACIJA (association)

AGREGACIJA (aggregation)

GENERALIZACIJA (generalization)

REALIZACIJA (realization)

1 1..*

UML notacija ...



Ak.god. 2014/2015.

B AZE PODATAKA 55

UML notacija ...



Ak.god. 2014/2015.

B AZE PODATAKA 56

Normalizacija podataka




Ak.god. 2014/2015.

B AZE PODATAKA 57

j p

• 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



Definicije funkcijskih ovisnosti



Ak.god. 2014/2015.

B AZE PODATAKA 59

j j

Funkcijska ovisnost atributa

• Ako promatramo tablicu R sa atributima X i Y koji mogu bitikompozitni tj. složeni: za atribut Y tablice R kaže se da jefunkcijski 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.




Ak.god. 2014/2015.

B AZE PODATAKA 60

j j

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 funkcijskiovisan o X i nije funkcijski ovisan niti o jednom manjem podskupuatributa X.

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




Ak.god. 2014/2015.

B AZE PODATAKA 61

j j

Tranzitivna funkcijska ovisnost atributa

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

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

1NF



Ak.god. 2014/2015.

B AZE PODATAKA 62

Prva normalna forma (1NF)

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

Uklanjanje ponavljajućih atributa ili grupa atributa

2NF



Ak.god. 2014/2015.

B AZE PODATAKA 63

Druga normalna forma (2NF)

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

Uklanjanje atributa ovisnih samo o dijelu jedinstvenogidentifikatora.

3NF



Ak.god. 2014/2015.

B AZE PODATAKA 64

Treća normalna forma (3NF)

Tablica je u trećoj normalnoj formi ako i samo ako je u2NF i ako niti jedan nekljuĉni atribut nije tranzitivnoovisan o kljuĉu.

Uklanjanje atributa ovisnih o atributima koji nisu dio jedinstvenog identifikatora.

Primjer normalizacije podataka



Ak.god. 2014/2015.

B AZE PODATAKA 65

• Na slici je dana denormalizirana tablica s nazivima stupaca i

vrijednostima redaka.

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

Normalizacija podataka (1NF)



Ak.god. 2014/2015.

B AZE PODATAKA 66

– Postoji funkcijska zavisnost :

Matbr→ Prezime, Ime

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

Matbr→ SifNas Matbr→ PrezNas




Ak.god. 2014/2015.

B AZE PODATAKA 67

Rješenje:

PK (STUDENT) = {Matbr}

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




Ak.god. 2014/2015.

B AZE PODATAKA 68

{Matbr, SifPred, DatIsp} → {NazPred}

{SifPred}→

{NazPred} dakle, ne postoji potpuna funkcijska ovisnostneključnih atributa o ključu

ISPIT ne zadovoljava 2 NF !

Rješenje:




Ak.god. 2014/2015.

B AZE PODATAKA 69

{Matbr, SifPred, DatIsp} → {SifNas}

{SifNas}→

{PrezNas} dakle, postoji tranzitivna funkcijska ovisnost(koju je potrebno eliminirati)

ISPIT ne zadovoljava 3 NF !

Rješenje:




Ak.god. 2014/2015.

B AZE PODATAKA 70

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)



Ak.god. 2014/2015.

B AZE PODATAKA 71



Ak.god. 2014/2015.

B AZE PODATAKA 72

Modeliranje podatakaPrimjeri

Primjer 1.



Ak.god. 2014/2015.

B AZE PODATAKA 73

• Profesionalni programer Ivo Ivić odlučio je napraviti program za

evidentiranje svih programa koje je uradio, korisnika kod kojih tiprogrami 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 programakorisničkim zahtjevima, kad je program pušten u rad kod korisnika,

kao i koliko je od korisnika naplaćeno za taj program. TakoĎer seevidentira da li je program u uporabi tj. aktivan ili ne.



Primjer 2.



Ak.god. 2014/2015.

B AZE PODATAKA 76

• Faktura je dokument koji se šalje kupcu kako bi mogao izvršiti plaćanje

kupljene robe. Da bi se napravila faktura moraju postojati osnovnipodaci o kupcu (naziv, adresa, telefon i sl.), podaci o fakturi (brojfakture, datum izdavanja, broj narudžbe prema kojoj je raĎena, rokplać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 2. ( ER model )



Ak.god. 2014/2015.

B AZE PODATAKA 77

Primjer 2. ( Relacijski model )



Ak.god. 2014/2015.

B AZE PODATAKA 78

Primjer 3.



Ak.god. 2014/2015.

B AZE PODATAKA 79

• 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 inaziv 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 nekomrazredu (godini), npr. Matematika u 1.razredu i Matematika u 2.razreduimaju različite šifre. Isti predmeti u različitim školama imaju istu šifrunpr. 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 svakipojedini zadatak mogu biti A, B, C, D, E ili ništa)

Primjer 3. ( ER model )



Ak.god. 2014/2015.

B AZE PODATAKA 80




Ak.god. 2014/2015.

B AZE PODATAKA 81

Primjer 4.



Ak.god. 2014/2015.

B AZE PODATAKA 82

• 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žinapri polijetanju. Za svaki aerodrom se evidentira šifra i naziv aerodroma.

Zrakoplov prema namjeni može biti ili putnički ili teretni (jedno isključujedrugo). Za svaki pojedini zrakoplov, ovisno o njegovoj namjeni, evidentirase je li u zrakoplov ugraĎena dodatna oprema: za svaki pojedini putničkizrakoplov evidentira se ima li ugraĎenu internu televiziju, ima li ureĎaj zasatelitsku komunikaciju, a za svaki pojedini teretni zrakoplov broj dodatno

ugraĎenih klimatiziranih kontejnera za prijevoz životinja i je li ugraĎenkatapult za izbacivanje tereta padobranom.



Ak.god. 2014/2015.

B AZE PODATAKA 85



Ak.god. 2014/2015.

B AZE PODATAKA 86

Modeliranje podatakaPrimjeri za vjeţbu

Primjer 1. (Evidentiranje objavljenih radova)



Ak.god. 2014/2015.

B AZE PODATAKA 87

• Profesor programiranja Ivo Ivić odlučio je napraviti program zaevidentiranje 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 ilidomaćem časopisu.Za svaki rad unose se podaci o naslovu rada, klasifikacijama,koautorima i časopisu u kojem je rad objavljen.

Primjer 2. (Ugovori)



Ak.god. 2014/2015.

B AZE PODATAKA 88

• Na slici je dana denormalizirana tablica UGOVORI s nazivima stupaca ivrijednostima redaka. Napraviti normalizirani model podataka s

pripadajućim entitetima, atributima i vezama izmeĎu njih.

Primjer 3. (Filmovi)



Ak.god. 2014/2015.

B AZE PODATAKA 89

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

Uz svaki film evidentiraju se različiti izvoĎači (šifra, ime, prezime) ifunkcije 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)



Ak.god. 2014/2015.

B AZE PODATAKA 90

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

U bazi podataka je potrebno evidentirati sljedeće podatke o filmovima:šifra, naziv, naziv originala, godina proizvodnje, trajanje filma, šifru inaziv žanra, glumce u filmu (šifra, ime, prezime).Baza podataka takoĎer treba sadržavati popis dvorana u multiplekskinu (sifra, naziv, broj mjesta) kao i raspored svih projekcija filmovapo dvoranama (datum i vrijeme projekcije, cijena karte za projekciju).



Primjer 6. (Tehniĉki biro)



Ak.god. 2014/2015.

B AZE PODATAKA 92

• Napraviti normalizirani model podataka s pripadajućim entitetima, atributima ivezama 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čiteljuprojekta (šifra, naziv, adresa, telefon, mail). Za svaki projekt postoji samo jedanglavni naručitelj s kojim se sklapa ugovor o poslu. O projektu se vode slijedećipodaci: naziv projekta, opis projekta, planirani datum početka rada na projektu,

planirani svršetak rada na projektu, stvarni početak rada na projektu, stvarnisvrš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Ďenomradnom mjestu u birou (šifra, naziv radnog mjesta, opis). Projekt se razlaže naviš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, planiranisvršetak, stvarni početak, stvarni svršetak, vrijednost i napomena.



Ak.god. 2014/2015.

B AZE PODATAKA 93

Uvod u SQL

SQL



Ak.god. 2014/2015.

B AZE PODATAKA 94

• SQL = Structured Query Language

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

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

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

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

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

SQL



Ak.god. 2014/2015.

B AZE PODATAKA 95

• 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



Ak.god. 2014/2015.

B AZE PODATAKA 96

• 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 sven-torke kojima je vrijednost atributa poštanski broj jednaka 88000):

SELECT *

FROM mjesto

WHERE pbr = 88000;

Izvršavanje SQL iskaza (ORACLE server)



Ak.god. 2014/2015.

B AZE PODATAKA 97



Ak.god. 2014/2015.

B AZE PODATAKA 98

DDL naredbeKreiranje tablica

Kreiranje tablica



Ak.god. 2014/2015.

B AZE PODATAKA 99

SQL – Kreiranje i brisanje tablica



Ak.god. 2014/2015.

B AZE PODATAKA 100

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 ...



Ak.god. 2014/2015.

B AZE PODATAKA 101

• NULL/NOT NULL

• UNIQUE

• PRIMARY KEY

• FOREIGN KEY

• CHECK

Tipovi podataka (ORACLE)



Ak.god. 2014/2015.

B AZE PODATAKA 102

• VARCHAR2(size )

• CHAR [(size )]

• NUMBER [( p ,s )]

• DATE

Tipovi podataka Veliki objekti



Ak.god. 2014/2015.

B AZE PODATAKA 103

PRIMJER – Relacijski model



Ak.god. 2014/2015.

B AZE PODATAKA 104

SQL – Kreiranje tablica



Ak.god. 2014/2015.

B AZE PODATAKA 105

CREATE TABLE MJESTO

( PBR NUMBER(10) NOT NULL ,

NAZIV VARCHAR2(40) NOT NULL ,

CONSTRAINT mjesto_pk PRIMARY KEY (PBR));

SQL – Kreiranje tablica



Ak.god. 2014/2015.

B AZE PODATAKA 106

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));



Ak.god. 2014/2015.

B AZE PODATAKA 109

DML naredbeSELECT, INSERT, UPDATE, DELETE



INSERT – Unos podataka u tablicu



Ak.god. 2014/2015.

B AZE PODATAKA 111

• 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 podatakaiz 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] SETstupac [,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=10000WHERE 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 mjestoWHERE 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



Korisnici i sigurnost



Sistemske privilegije



Ak.god. 2014/2015.

B AZE PODATAKA 124

• 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




Ak.god. 2014/2015.

B AZE PODATAKA 125

• 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




Ak.god. 2014/2015.

B AZE PODATAKA 126

Primjeri:

• GRANT create session, create table,

create sequence, create view

TO pero;

• REVOKE create view

FROM pero;

Uloga (Role)



Ak.god. 2014/2015.

B AZE PODATAKA 127

Korisnici

Privilegije

Uloga

Dodjeljivanje privilegija korisnicimabez definirane uloge

Dodjeljivanje privilegija korisnicimanakon definiranja uloge

Uloga (Role)



Ak.god. 2014/2015.

B AZE PODATAKA 128

• 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



Ak.god. 2014/2015.

B AZE PODATAKA 130

• 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

Objektne privilegije



Ak.god. 2014/2015.

B AZE PODATAKA 131

Primjer:

• GRANT select, insert

ON osoba

TO pero, mate

WITH GRANT OPTION;

• GRANT select

ON mjesto

TO PUBLIC;



Ak.god. 2014/2015.

B AZE PODATAKA 132

Upravljanje transakcijama




Ak.god. 2014/2015.

B AZE PODATAKA 133

• Pod transakcijom se podrazumijeva aktivnost ili niz

aktivnosti koje izvršava jedan korisnik ili aplikacijskiprogram, 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 zasebe




Ak.god. 2014/2015.

B AZE PODATAKA 134

1) UPDATE racun SET saldo=saldo-500WHERE 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 obeUPDATE naredbe) ili nikako – “SVE ili NIŠTA”

Raĉun 1 Raĉun 2

500 KM

5.000 KM 1.000 KM

Osobine transakcija



Ak.god. 2014/2015.

B AZE PODATAKA 135

Tzv. ACID osobine transakcija:

• Atomicity – „sve ili ništa‟ (transakcije nije moguće samodjelomič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žebiti 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 zbognaknadnih grešaka (čak ni u slučaju pada sustava)

Upravljanje transakcijama (ORACLE)



Ak.god. 2014/2015.

B AZE PODATAKA 136

• 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



Ak.god. 2014/2015.

B AZE PODATAKA 137

SELECT placa FROM djelatnikWHERE id_djelatnika=1;

UPDATE djelatnikSET placa=placa+1000WHERE id_djelatnika=1;

COMMIT;

t1

t2

t3

t4

t5

Vrijeme Sesija 1 Sesija 2

SELECT placa FROM djelatnikWHERE id_djelatnika=1; SELECT placa FROM djelatnikWHERE id_djelatnika=1;

2000

2000 3000

SELECT placa FROM djelatnik

WHERE id_djelatnika=1;


WHERE id_djelatnika=1;3000 3000

Upravljanje transakcijama Primjer



Ak.god. 2014/2015.

B AZE PODATAKA 138

SELECT placa FROM djelatnikWHERE id_djelatnika=1;

UPDATE djelatnikSET placa=placa+1000WHERE id_djelatnika=1;

ROLLBACK ;

t1

t2

t3

t4

t5

Vrijeme Sesija 1 Sesija 2

SELECT placa FROM djelatnikWHERE id_djelatnika=1; SELECT placa FROM djelatnikWHERE id_djelatnika=1;

2000

2000 3000


WHERE id_djelatnika=1;


WHERE id_djelatnika=1;2000 2000



Zakljuĉavanje (locking)



Ak.god. 2014/2015.

B AZE PODATAKA 140

Dijeljeno zakljuĉavanje (shared lock, read lock)

̶ Kljuĉ za ĉitanje – npr. transakcija SQL naredbom SELECT zaključaobjekt 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šenozaključavanje ne otključa.




Ak.god. 2014/2015. B AZE

PODATAKA

141

Proces1 – postavio ključ na objekt

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




Ak.god. 2014/2015. B AZE

PODATAKA

142

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žitinikakav 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Ďenjatransakcija naziva se serijalizabilnost.

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

Razine izolacije (isolation levels)




• Kod zapisivanja se uvijek traži ekskluzivno zaključavanje koje sezadrž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 kojedrži druga transakcija.



Upravljanje transakcijama i zakljuĉavanje

St j t ij COMMIT ili ROLLBACK db




• Stanje sustava prije COMMIT ili ROLLBACK naredbe:

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

– korisnik koji radi izmjene podataka kroz transakciju moževidjeti 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 korisniciih ne mogu mijenjati

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

Upravljanje transakcijama i zakljuĉavanje




• 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 kroztransakciju

Zakljuĉavanje:

– n-torke nad kojima su vršene izmjene kroz transakcijunisu više zaključane i navedene n-torke postaju dostupneza 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 grupeo 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

ASSELECT 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 ipodatke 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ćavanesekvencijalni pristup do n-torke u relaciji. Nesekvencijalnipristup 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 kojihsvaki može sadržavati jedan ili više atributa.

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

Kreiranje indeksa (INDEX)

AUTOMATSKI




AUTOMATSKI

• UNIQUE INDEX se automatski kreira kada se definiraPRIMARY KEY ili UNIQUE CONSTRAINT u definicijitablice.

RUĈNO

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

Primjer:

• CREATE INDEX djelatnik_prez_idxON 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 trebakoristiti samo tamo gdje je njihova uporabaopravdana.

• Indeksi zauzimaju značajan prostor

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

Indeks (INDEX)

d k bi b l i j ji i k lik




Indekse ne bi trebalo primjenjivati ukoliko:

• vrijednosti atributa za kojeg se gradi indeks imaju relativnomali broj različitih vrijednosti (npr. spol_osobe s dopuštenimvrijednostima 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 indekseizbrisati, te ih ponovo izgraditi tek nakon obavljenih promjenana podacima.

• relacija sadrži vrlo mali broj n-torki (npr. do stotinu). U takvimsluč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)

P i j




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_seqINCREMENT BY 1

START WITH 1

MAXVALUE 9999

NOCACHENOCYCLE;

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;



• ProizvoĎači SUBP koriste vlastite inačice jezika za definiranje

Pohranjena procedura (STORED PROCEDURE)




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-SQLT-SQL (Transact-SQL)

• Navedeni jezici proširuju mogućnosti SQL jezika proceduralnimelementima 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

Pohranjena procedura (STORED PROCEDURE)




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 ]



Primjer (klijent-server arhitektura oslonjena na server)

Primjer: Prebacivanje iznosa s jednog raĉuna na drugi P j t j li d i b j i č i k t j b j i




EXECUTE PROCEDURE

prebaci (1, 2, 500);

CREATE PROCEDURE prebaci (...)

DEFINE ...

SELECT ...SELECT ...

UPDATE ...UPDATE ...

END PROCEDURE;

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).



Okidaĉ (TRIGGER)

“Pasivni” SUBP




• konvencionalni SUBP je pasivan• operacije nad podacima se izvršavaju isključivo na temeljueksplicitnog 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 seizvršavaju automatski, reakcijom na odreĎeni dogaĎaj ili stanje

• SUBP – definiranje aktivnih pravila (active rules)

Okidaĉ (TRIGGER)




• 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 nadpodacima

ON event IF condition THEN action

• Okidaĉi (trigeri) se izvršavaju automatski kod izvršavanja akcijskihSQL it (INSERT UPDATE DELETE) d j di i t bli

Okidaĉ (TRIGGER)




SQL upita (INSERT, UPDATE, DELETE) nad pojedinim tablicama u

bazi podataka.

• Pri definiciji okidača moguće je specificirati koje akcije (operacije)kti i j kid č (t i )

Okidaĉ (TRIGGER)




aktiviraju okidač (triger):

INSERT, UPDATE, DELETE

• TakoĎer, pri definiciji okidača moguće je specificirati da li se akcijenavedene 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



Baze podataka



Web:

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

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: [email protected]

goran kraljevic@sve mo ba

baze predavanja

Documents