Relacijske podatkovne baze

1. Zbirke podatkov I
Študijsko gradivo
dr. Darko Golec
darko.golec@gmail.com
1

2. Podatkovna baza / SUPB / Aplikacija
(Database / DBMS / Application)
• Podatkovna baza je zbirka medsebojno logično povezanih podatkov
(in opisov podatkov), ki zadovoljuje informacijske potrebe
organizacije in njenih poslovnih procesov. Relacijska podatkovna
baza je podatkovna baza, v kateri so podatki organizirani v množici
relacij.
• SUPB je skupek programske opreme, ki omogoča kreiranje,
vzdrževanje in nadzor nad dostopom do podatkov v podatkovni
bazi.
• Aplikacija je program, ki v okviru informacijskega sistema delno ali v
celoti podpira enega ali več poslovnih procesov in za shranjevanje
podatkov uporablja podatkovno bazo.
2

3. SUPB
• Sistem za upravljanje s podatkovnimi zbirkami (SUPB) je množica programov,
namenjenih ustvarjanju, vzdrževanju in nadzoru dostopa do podatkov v
podatkovnih zbirkah.
• Nadzor nad dostopom do podatkov obsega več področij:
– Sistem varnosti: dostop do podatkov v skladu z avtorizacijo
– Sistem nadzora integritete: zagotavlja integriteto (smiselno vsebino, konsistenco) podatkov
– Sistem nadzora sočasnega dostopa
– Sistem obnove podatkovne baze (recovery)
– Sistemski katalog (data dictionary)
• Kreiranje podatkovnih struktur je omogočeno s pomočjo DDL (Data Definition
Language).
• Manipulacija podatkov (Insert, Update, Delete) je omogočeno s pomočjo DML
(Data Manipulation Language).
• Poizvedovanje (Select)
• Modeli SUPB
– Prva generacija (Hierarhični model, Mrežni model)
– Druga generacija (Relacijski model)
– Tretja generacija (Objektno-relacijski model, Objektni model)
3

4. Relacijski model
• (Prvoten) model je last osebe E. F. Codd, ki je bil raziskovalec v IBM-u. Codd velja za
izumitelja modela.
• Dandanes je model rezultat prizadevanja širše skupnosti.
• Prvoten model tvorijo tri komponente:
– Structure (Relation, Type, Attribute, Key)
– Integrity
• The entity integrity rule (Primarni ključi ne dovoljujejo NULL.)
• The referential integrity rule (Vrednosti v FK se morajo ujemati.)
– Manipulation
• Relational Algebra (Restrict, Project, Product, Intersect, Union, Difference, Join)
• Relational Assignment (r1 MINUS r2)
• Relacijski model temelji na matematični teoriji množic.
• Osnovni cilj relacijskega modela je zagotoviti visoko stopnjo neodvisnosti podatkov.
• Značilnosti relacijskega modela
– Podatki se združujejo v relacijah
– Relacije so medsebojno logično povezane
– Povezovanje tabel je izvedeno s pomočjo enakih atributov
4

5. Množica (Set)
• Množica je skupina natančno definiranih elementov.
• Množice spadajo med osnovna področja v matematiki
in predstavljajo osnovo nekaterim drugim področjem.
• Tipične operacije nad množico so presek, unija, razlika,
podmnožica.
5

6. IZHODIŠČA
6

7. Principi, ne produkti
• Namen predavanj je spoznati principe v teoriji in
ne posameznih produktov SUPB (npr. MS Access).
• Princip je nekaj, kar je osnova - teoretična
resnica. Ta je začetek in osnova nadaljevanja.
• Practice should always be based on a sound
knowledge of theory (Da Vinci, 1452-1519).
7

8. Model / Implementacija
• Model (podatkovni model) je abstraktna in logična
definicija podatkovnih struktur, operatorjev in vsega
drugega, ki skupaj tvorijo abstrakten sistem.
• Implementacija je fizična realizacija abstraktnega
sistema na dejanskem - računalniškem sistemu s
pripadajočimi komponentami.
• Razlike:
– Model je tisto, kar uporabniki morajo vedeti. Model je
vmesnik. Implementacija je tisto, kar uporabnikom ni treba
vedeti.
– Model je en sam, implementacij pa je več!
8

9. Načrtovanje podatkovne baze
• Splošni cilj razvijalcev informacijskih sistemov je razvoj aplikacij, ki
bodo podpirale dana opravila v realnem svetu.
• Načrtovanje podatkovne baze je postopek opredelitve in razvoja
strukture PB.
• V času načrtovanja podatkovne baze naredimo formalni model
nekaterih vidikov realnega sveta – problemske domene.
• Mera za pravilnost načrtovane sheme PB je realni svet. Od tod sledi,
da vsebina PB mora odražati podatke, pravila in izjeme iz realnega
sveta.
• Postopek načrtovanja in izdelave PB poteka po fazah.
9

10. Faze načrtovanja podatkovne baze
10

11. Postopek izdelave relacijskega diagrama
1. Opis problema v naravnem jeziku
2. Iskanje relacij (učitelj, študent, fakulteta itd.)
3. Iskanje razmerij med relacijami
4. Narisati osnovni relacijski model
5. Opredelitev karinalnosti (števnosti) razmerij
6. Dodajanje atributov
7. Opredelitev ključev
8. Verifikacija in validacija
9. Izbira ciljnega SUPB
10. Priprava skript za kreiranje relacijskega diagrama v izbranem SUPB
11. Zagon skript
11

12. Načrtovanje ali modeliranje (Design)
• Konceptualni model (Conceptual design)
– Je grafična predstavitev zamisli
– Pomembno je KAJ
• Logični model (Logical design)
– Kako je videti podatkovna baza za uporabnika?
– Struktura podatkov relacijskega modela
– Nima nič skupnega s performansami
– Pomembno je KAKO
• Fizični model (Physical design)
– Kako se logični model udejanji na fizični prostor?
– Pomembno še diskovje, RAM, optimizacija, razvrščanje, itd.
– Pomembno je KAKO (glede na izbrani SUPB)
12

13. Problemi pri načrtovanju
• Nepoznavanje področja
– Načrtovalec problemskega področja načeloma ne pozna. Zato se mora najprej seznaniti in
podrobno spoznati domeno problema in domeno bodoče aplikacije.
• Pravila in izjeme
– Poleg pravil v realnem svetu obstaja tudi veliko izjem.
– Načrtovalec pri svojem delu mora upoštevati pravila in tudi vse izjeme.
– Hkrati mora narediti sistem dovolj fleksibilen, ki bo odporen na bodoče spremembe.
• Velikost
– Načrti PB so pogosto zelo kompleksni. Zato so za načrtovalca težko obvladljivi.
• Sodelovanje
– Ključ uspeha je v sodelovanju z uporabniki.
– Pri sodelovanju morajo načrtovalci PB in uporabniki govoriti skupen jezik, sicer pride do večjih
razhajanj med dejanskimi in realiziranimi nalogami.
13

14. Dve past pri povezovanju
1. Fan trap (Dvoumnost modela se izkaže pri poizvedbi v katerem oddelku
dela Miha Novak?)
2. Chasm trap (kateri učbeniki obstajajo za kateri predmet?)
14

15. Strukturiranost podatkov
• Glede na strukturiranost so podatki:
– Strukturirani (relacijske tabele, xls, csv, tabele/stolpci)
– Delno strukturirani (dokumenti, Email, doc, beležnice)
– Nestrukturirani (vse ostalo, npr. slike, audio, video)
• Principi Big Data, Advanced Analytics
• 95 % podatkov v neposlovnem svetu
• 80 % podatkov v poslovnem svetu
15

16. LOGIČNI MODEL
16

17. Podatkovni tip (Data Type)
• Podatkovni tip
– Ima ime in predstavlja vrsto podatka – končno množico vrednosti
skupne vrste.
– Ima ime in predstavlja končno množico vseh vrednosti, ki ustrezajo
omejitvi tega tipa.
– Nekateri podatkovni tipi so:
• BOOLEAN
• CHARACTER (n)
• CHARACTER VARYING (n)
• FLOAT (p)
• NUMERIC (p,q)
• INTEGER
• SMALLINT
• DATE
• TIME
• TIMESTAMP
• INTERVAL
17

18. Relacija (Relation)
• Relacija je množica zapisov (set of tuples).
• Vsaka relacija ima glavo (heading) in telo (body). Glavo
imenujemo relacijska shema, telo pa predstavljajo
vrednosti atributov.
• Relacijska shema je množica atributov, kjer je vsak atribut
opredeljen z enoličnim imenom ter podatkovnim tipom.
• Telo relacije je množica zapisov, ki pripadajo relacijski
shemi.
• Stopnja relacije (degree) je enaka številu atributov.
• Števnost relacije (cardinality) je enaka številu zapisov.
• Relacijo „predstavljamo kot 2D-list z vrsticami in stolpci“.
Velja za logično strukturo podatkovne baze in ne za fizično.
18

19. Relacija - grafično
19

20. Relacija in relacijska shema – definicija
• Naj bo o element iz množice O, 𝑜 ∈ O ter naj bodo 𝐴𝑖, 1 ≤ 𝑖 < 𝑛, njegove lastnosti,
imenovane atributi. 𝐴𝑖: O → 𝑇𝐴𝑖
, kjer je 𝑇𝐴𝑖
podatkovni tip atributa 𝐴𝑖. Vsakemu
elementu 𝑜 ∈ O pripada zapis
𝑧0 = 𝐴1 𝑜 , 𝐴2 𝑜 , … , 𝐴𝑛 𝑜 .
• Relacija r je formalno definirana kot preslikava, ki slika iz kartezijskega produkta
vrednostnih množic atributov v binarno množico ⫟, ⫠ . Pripadajoč zapis je v
relaciji, kadar velja 𝑟 𝑧0 =⫟. V nasprotnem primeru objekt ni v relaciji. Relacijo r
pa lahko definiramo tudi kot množico zapisov, ki pripadajo relaciji.
{𝑧0|𝑜 ∈ O ∧ 𝑟 𝑧0 =⫟}.
• Imena atributov ter podatkovne tipe relacije imenujemo relacijska shema.
Relacijska shema R predstavlja semantično komponento relacije r in je definirana
kot
𝐴1: 𝑇1, 𝐴2: 𝑇2, … , 𝐴𝑛: 𝑇𝑛 = 𝑅 𝐴1, 𝐴2, … , 𝐴𝑛 = 𝐴1, 𝐴2, … , 𝐴𝑛.
• Vsaki relaciji pripada natačno ena relacijska shema, medtem ko relacijski shemi
lahko pripada več relacij. Sh je funkcija, ki relaciji priredi pripadajočo relacijsko
shemo 𝑆ℎ: 𝑟 → {𝑅}. Tabela vsebuje vrstice, medtem ko relacija vsebuje zapise!
20

21. Lastnosti relacije
• Relacija je model nekega stanja na nekem področju, zato njena
vsebina ne more biti poljubna.
• Relacija nikoli ne vsebuje dveh enakih zapisov oz. duplikatov
(TRUE of TRUE is a nonsense!)
• Vrstni red zapisov je nepomemben.
– ORDER BY ni relacijski operator!
• Vrstni red atributov je nepomemben.
21
SNO CITY
S1 London
S2 Paris
CITY SNO
London S1
Paris S2
SNO CITY
S1 London
S2 Paris
SNO CITY
S2 Paris
S1 London

22. Lastnosti relacije
• Lastnosti relacije so:
– Ime relacije je enolično.
– Ime atributa v relaciji je enolično.
– Relacija ne vsebuje duplikatov zapisov.
– Vrstni red atributov relacije ne obstaja.
– Relacije nikoli ne vsebujejo NULL.
– Podmnožica relacije je ponovno relacija.
– Relacije ne vsebujejo skritih komponent (npr. RowID,
ObjectID, Timestamp).
– Velja princip Closed World Assumption (resnične
vrednosti - TRUE).
22

23. Lastnosti relacije
• Relacije so vselej normalizirane (vsaj 1NO).
• Prva normalna oblika (1NO)
– Relacija vsebuje zapise, kjer vsaka od njih vsebuje
natanko eno vrednost pripadajočega podatkovnega
tipa za posamičen atribut.
• Relacije nikoli ne vsebujejo NULL.
• All logical differences are big differences.
23

24. Operacije relacijske algebre
• Osnovne
– Selekcija
– Projekcija
– Kartezijski produkt
– Unija
– Razlika
• Izpeljane
– Stik
– Presek
– Količnik
24

25. Operacije relacijske algebre
25

26. Operacije relacijske algebre
26

27. Stiki (Joins)
• Cross join (Cartesian product)
• Inner join
• Full outer join
• Left outer join
• Right outer join
• Self join
27

28. Domena tipa
28
• Domena je lastnost tipa.
• Predstavlja nabor vrednosti v tipu, med katerimi lahko izbiramo
vrednosti za dejanske atribute, ki imajo definiran ta tip.
• Pri definiciji tipa določimo domeno (npr. definiramo tip
HUMAN_LIFE_NUMBER, kjer je 0<domena<120. Atribut Starost (v
letih) ima definiran tip HUMAN_LIFE_NUMBER, s čimer so vrednosti
avtomatično omejene.)

29. Zapis
• Zapis je opredeljen s skupino tipov Ti i = 1,2, … , n , n ≥ 0, za katere ni
nujno, da so vsi enaki. Zapis je skupina n urejenih trojčkov oblike
Ai, Ti, vi , kjer je Ai ime atributa v relaciji, Ti ime tipa in vi vrednost od
tipa Ti.
• Duplikat zapisov
– Duplikat sta dva enaka zapisa, ki imata iste atribute, istega tipa in istih
vrednosti.
– t1 in t2 sta duplikata, če vključujeta natančno enake atribute A1, A2, … , An, za
vse i (i = 1, 2, … , n), vrednost za Ai v t1 pa je enaka vrednosti Ai v t2.
• Lastnosti zapisov so:
– Vsak zapis v relaciji je enoličen.
– Zapis vsebuje natanko eno vrednost pripadajočega tipa za vsak atribut.
– Vrstni red zapisov ne obstaja.
– Podmnožica zapisa je ponovno zapis.
29

30. Vaja
• Navedite 4 razloge zakaj tabela ni relacija!
30

31. KLJUČI
31

32. Značilnosti ključev
• V relacijski bazi se posamezni zapisi med seboj
ločijo po vrednostih atributov.
• V kolikor bi bila dva zapisa popolnoma enaka, ju
na logičnem nivoju ne bi mogli več ločiti -
dostopati do posameznega. Takšen scenarij ni
mogoč!
• Vsaka relacija mora imeti ključ, ki je identifikator.
• Kot ključ lahko služi tudi kombinacija več
atributov. V tem primeru je to sestavljeni ključ.
32

33. Ključ – definicija
• Naj bo X podmnožica atributov relacijske sheme R, 𝑋 ⊆
𝑅. Atributi X so ključ relacijske sheme R, če sta
izpolnjena naslednja dva pogoja:
– atributi X funkcionalno določajo vse atribute R in
– ne obstaja podmnožica 𝑋′ ⊂ 𝑋, ki prav tako določa vse
atribute R. To pomeni
¬∃𝑋′
(𝑋′
⊂ 𝑋 ∧ 𝑋′
→ 𝑅).
• Prvi pogoj predstavlja lastnost edinstvenosti, drugi
pogoj pa lastnost neločljivosti, nedeljivosti.
• Relacijska shema lahko ima več ključev. V praksi se
izbere eden od njih in ta se imenuje primarni ključ,
ostali pa so nadomestni ključi!
33

34. Tuj ključ in Referenčna integriteta
• Tuj ključ je množica atributov v relacijski spremenljivki, katerega vrednosti
se morajo ujemati z vrednostmi kandidatnega ključa v neki drugi (ali pa
isti) relacijski spremenljivki.
• Podatkovna baza ne sme vsebovati ne-ujemajočih vrednosti tujega ključa
(No database is ever allowed to contains any unmatched foreign key
values). Pravilo se imenuje REFERENČNA INTEGRITETA.
• V relacijskem modelu se relacije med sabo povezujejo s ključi.
34

35. Ključi v relacijski teoriji
• Super-ključ (Superkey)
– Enolično opredeljuje zapis.
– Lahko jih je več.
– Vsi so enako pomembni.
• Kandidatni ključ (Candidate key or Minimale superkey)
– Minimalen super-ključ.
– Vsak kandidatni ključ je hkrati super-ključ.
– V relacijski teoriji poimenovan preprosto ključ!
– Lahko jih je več.
– Vsi so enako pomembni.
• Tuj ključ (Foreign key)
• Lastnosti ključa K sta:
– Edinstvenost (relacija ne vsebuje dveh zapisov z isto vrednostjo za K)
– Neločljivost (nobena podmnožica od K je enolična)
• Ključ je po številu atributov lahko:
– Enostaven - tvori ga en atribut
– Sestavljen - tvori ga več atributov
– Trivialen - tvorijo ga vsi atributi relacije
35

36. Ključi v SUPB
• Vrste ključev v SUPB
– Primarni ključ (Primary key)
• Običajno eden izmed kandidatnih ključev.
• Lahko tudi dodaten stolpec tabele.
– Nadomestni ključ (Alternate key)
• Vsi kandidatni ključi razen tistega, ki je izbran kot primarni.
– Tuj ključ (Foreign key)
• Ključ je po vrednostih lahko:
– Naraven – tvorijo ga vrednosti atributov
– Umeten – surogaten – npr. zaporedne vrednosti (1, 2, …)
• Priporočila za ključe
– Za ključ ni priporočljivo izbrati atributa z nekim vsebinskim pomenom (govoreč
ključ).
– Vrednost, ki odraža pomen, je namreč potrebno včasih spremeniti. Tu so izjema
atributi, za katere vemo, da se ne bodo nikoli spremenili, npr. davčna številka ali
EMŠO.
– Ključi nastopijo v povezavah med relacijami, zato se njihove vrednosti ne smejo
spreminjati.
36

37. Vaja
• Relacijska spremenljivka R ima dve vrednosti
(r1 in r2).
• Kateri so kandidatni ključi za R?
• ODG:
– Superključi za r1
– Superključi za r2
– Superključi za R
– Kandidatni ključi za R
37

38. Primer izpitne naloge
• Podana je relacijska spremenljivka.
• Kateri ključ predstavljajo:
– {B}
– {A, B}
– {C, E}
38
A: NUMBER B: NUMBER C: CHAR D: DATE E: BOOLEAN
1 5 S1 16.03.2012 TRUE
5 2 S1 07.02.2012 FALSE
2 4 S3 06.01.2011 FALSE
4 1 S2 08.05.2012 TRUE

39. RELACIJSKA RAZMERJA
39

40. Relacijsko razmerje (Relationship)
• Naj bosta množici A in B ter elementi a (od A) in elementi b
(od B). Relacijsko razmerje od A do B je pravilo ujemanja a z
b.
• Relacijsko razmerje velja „od A do B“ in ne „med A in B“!
• Za določen a je lahko največ en b, točno en b, najmanj en b
ali pa več b-jev.
• Za določen b je lahko največ en a, točno en a, najmanj en a
ali pa več a-jev.
• Vseh kombinacij je 16 (4*4), različnih pa 10.
• Vnos vrednosti je:
– mandatoren (Mandatory); npr. 1
– opcionalen (Optional); npr. 0..1
40

41. Števnost / Večkratnost (Cardinality / Multiplicity)
• Števnost relacije je enaka številu zapisov.
• Večkratnost (npr. 1, 1..M) je definicija območja števnosti.
41
Notacija Pomen
1 Natančno ena
* Več
0..1 Nič ali ena
0..* 0 ali več
1..* Ena ali več

42. Vrste relacijskih razmerij
• 1.1 Mož - Žena
• 1.2 Zaposlenec vodja -
Oddelek
• 1.3 Zaposlenec - Oddelek
• 1.4 Zaposlenec - Oddelek
• 2.1 Enako kot 1.2
• 2.2 Pošiljka - Račun
• 2.3 Zaposlenec - Oddelek
• 2.4 Otrok - Mati
42

43. Vrste relacijskih razmerij
• 3.1 Enako kot 1.3
• 3.2 Enako kot 2.3
• 3.3 Knjiga - Avtor
• 3.4 Športni dogodek -
Oseba
• 4.1 Enako kot 1.4
• 4.2 Enako kot 2.4
• 4.3 Enako kot 3.4
• 4.4 Dobavitelj - Material
43

44. ODVISNOSTI
44

45. Odvisnosti (Dependencies)
• Funkcionalna odvisnost (Functional Dependency)
• Večvrednostna odvisnost (Multivalued
Dependency)
• Stična odvisnost (Join Dependency)
• Fokus je na funkcionalnih ter stičnih odvisnostih
45

46. Funkcionalna odvisnost
• Predpostavimo, da obstaja relacija R z množico atributov, katere
podmnožici sta X in Y.
– V relaciji R velja X → Y (X funkcionalno določa Y oz. Y je funkcionalno
odvisen od X), če v relaciji ne obstajata dva zapisa, ki bi se ujemala v
vrednostih podmnožice atributov X, a se ne bi ujemala v vrednostih
podmnožice atributov Y.
• Funkcionalne odvisnosti so značilne za relacije 1NO, 2NO, 3NO in
BCNO.
• Definicija – naj bosta X in Y neprazni podmnožici atributov relacijske
sheme R. 𝑋, 𝑌 ⊆ 𝑅, 𝑋, 𝑌 ≠ 0. Atributi X funkcionalno določajo
atribute Y (𝑋 → 𝑌), če v nobeni relaciji s shemo R ne moreta obstajati
dva zapisa, ki bi se ujemala v vrednostih atributov X, a se ne bi
ujemala v vrednostih atributov Y.
𝑋 → 𝑌 ∈ 𝐹𝑅 ⇔ ∀𝑟(𝑆ℎ 𝑟 = 𝑅 ⇒ ∀𝑧1∀𝑧2( 𝑧1 ∈ 𝑟 ∧ 𝑧2 ∈ 𝑟 ⇒ (𝑧1. 𝑋 = 𝑧2. 𝑋 ⇒ 𝑧1. 𝑌 = 𝑧2. 𝑌)))
46

47. Funkcionalna odvisnost - primer
• Imamo relacijo Izpit( VpŠt, Priimek, Ime, ŠifraPredmeta, DatumIzpita,
OcenaPisno, OcenaUstno) z naslednjim pomenom:
– Študent z vpisno številko VpŠt ter priimkom Priimek in imenom Ime je na
DatumIzpita opravljal izpit iz predmeta s šifro ŠifraPredmeta. Dobil je oceno
OcenaPisno in oceno OcenaUstno.
– Funkcionalne odvisnosti relacijske sheme Izpit so: F ≡ { VpŠt → (Priimek, Ime),
(VpŠt, ŠifraPredmeta, DatumIzpita) → (OcenaPisno, OcenaUstno)}
• Netrivialna funkcionalna odvisnost
– Netrivialna (nontrivial) funkcionalna odvisnost X→Y, kjer je Y podmnožica X.
– V nasprotnem primeru nastopi trivialna (trivial) funkcionalna odvisnost.
47

48. Armstrongovi aksiomi
1. Refleksivnost: Y⊆X ∧ X⊆R ⇒ X→Y.
2. Razširitev: X→Y ∧ Z⊆R ⇒ XZ→YZ.
3. Tranzitivnost: X→Y ∧ Y→Z ⇒ X→Z.
• Pravila, ki izhajajo iz aksiomov:
– Unija: X→Y ∧ X→Z ⇒ X→YZ.
– Dekompozicija: X→YZ ⇒ X→Y ∧ X→Z.
– Pseudotransitivnost: X→Y ∧ WY→Z ⇒ WX→Z.
48

49. Vaja
• Določite odvisnosti, ki evidentirajo vozila, model vozila in
kapaciteto motorjev. Upoštevajte naslednji pravili:
– Vsako vozilo ima unikatno številko vozila (USV).
– Vsako vozilo je en sam model (MV) in ima natanko eno kapaciteto
motorja (KM).
• Kaj je prav?
– USVKM
– KMUSV
– USVKMMV
– USVMVKM
– MVUSV
49

50. Stična odvisnost
• Naj bodo A, B, …, C podmnožice relacije R. Stična odvisnost ∗{A, B,
…, C} pomeni, da je relacijo R možno dobiti s stikom projekcij A, B,
…, C.
• Dekompozicija brez izgub nad relacijo R v projekcije A, B, …, C je
možna, če velja ∗{A, B, …, C}.
• Vsaka funkcionalna odvisnost je hkrati stična odvisnost. V kolikor
relacija R vsebuje funkcionalno odvisnost, je možna dekompozicija
(brez izgub) relacije R v njene projekcije.
• Stična odvisnost je trivialna, če je katerakoli od projekcij (projekcije
so tudi relacije) A, B, …, C, enaka R. Pomembna je netrivialna stična
odvisnost.
• Heath-ov teorem: Če R(A, B, C) izpolnjuje A→B, je R enak stiku
projekcij R1(A, B) in R2(A, C).
• Stična odvisnost, ki ni posledica funkcionalne odvisnosti, je v all-key
relacijah.
50

51. Stična odvisnost - definicija
• V stični odvisnosti so relacijska razmerja med
seboj neodvisna.
• Definicija: naj bo R relacijska shema in R1, R2,
…, Rn naj bodo dekompozicije od R. Relacija
r(R) zadošča stični odvisnosti * (R1, R2, …, Rn),
če velja
• V kolikor je katera od Ri enaka R, je stična
odvisnost trivialna.
51

52. Stična odvisnost - primer
Poišči stično odvisnost za relacijo Seznam_naročil = {naročilo, stranka, hrana, raznašalec}
Najprej poiščemo funkcionalne odvisnosti. Te so:
naročilostranka
naročilohrana
naročiloraznašalec
Funkcionalne odvisnosti načrtujemo kot ločene relacije, morebiten ostanek relacije pa pustimo v
prvotni relaciji.
Vsi atributi so del ene od funkcionalnih odvisnosti, ostanka ni. Relacijo Seznam_naročil nadomestimo z
množico relacij
Stranka = {naročilo, stranka}
Hrana = {naročilo, hrana}
Raznašalec = {naročilo, raznašalec}
Ker je po definiciji vsaka FD tudi JD, velja stična odvisnost
*((naročilo, stranka), (naročilo, hrana), (naročilo, raznašalec))
Stična odvisnost navedenih treh projekcij omogoča rekonstrukcijo relacije Seznam_naročil.
52

53. Iskanje super ključev ter
kandidatnih ključev - primer
Book ID Name Author
B1 XYZ A1
B2 ABC A1
B3 XYZ A2
B4 PQR A3
B5 LSP A1
B6 ABC A3
53
• Superključi: (Name, Author), (Book ID), (Book ID,
Name, Author), (Book ID, Author), (Book ID,
Name)
• Kandidatni ključi: (Name, Author), (Book ID)

54. Iskanje kandidatnih ključev - vaja
• R (A, B, C, D, E, F)
• A → C
• C → D
• D → B
• E → F
• Rešitev: Kandidatni ključ: AE (ni determiniran na desni strani)
• R (A, B, C, D, E)
• A → C
• C → B
• D → E
• Rešitev: Kandidatni ključ: AD
54

55. NORMALIZACIJA IN
NORMALNE OBLIKE
55

56. Atomarnost podatkov
• Codd-ova definicija: Atomaren podatek je tisti, ki ne more biti deljen na manjše
enote v SUPB .
• Kaj pa:
– String? LIKE, SUBSTR (substring), || (concatenate) itd. Ali so ti stringi atomarni?
– Ulomki? Celo število + ostanek
– Datum? 01.01.2012  Leto=2012
• Atomarnost podatkov ni absoluten pojem.
• Izraz izhaja iz grške besede Atomos (nedeljiv). Toda tudi atomi v fiziki niso nedeljivi.
Tvorijo jih protoni, nevtroni in elektroni. A tudi ti niso nedeljivi. Protone in
nevtrone tvorijo kvarki! Kaj pa Higsov bozon? Najmanjši delec materije je…?
56
SNO PNO
S2 P1
S2 P2
S3 P2
S4 P2
S4 P4
S4 P5
SNO PNO
S2 P1, P2
S3 P2
S4 P2, P4, P5
SNO PNO
S2 {P1, P2}
S3 {P2}
S4 {P2, P4, P5}

57. Atomarnost podatkov – primer
• Dvojni pomen atributov ni priporočljiv.
57

58. Anomalije podatkov
• Pri manipulaciji podatkov prihaja do težav:
– Anomalije večkratnih vrednosti
– Anomalije pri dodajanju (npr. nov dobavitelj brez izdelka)
– Anomalije pri posodabljanju (npr. telefon za Plezalke d.o.o.)
– Anomalije pri brisanju (npr. izdelki, ki niso več v prodaji,
brišejo podatke o partnerjih itd.)
58
Ime izdelka Latinsko ime Prodajalec Ime dobavitelja Telefon dobavitelja Cena
Brstična lilija Lycoris squamigera Kete Čebulnice, d.o.o. (01)555 01 35 31,60
Jesenski žafran Colchicum Ekart Čebulnice, d.o.o. (01)555 01 35 17,24
Forzicija Forsythia suspensa Gorjanc Klub grmičarjev, d.o.o. (01)555 01 21 17,04
Koristne trihine Neoplectana carpocapsae Kete Škodljivci STOP, d.o.o. (01)555 01 23 18,44
Grašica Coronilla varia Ekart Plezalke, d.o.o. (07)555 01 24 15,12
Angleški bršljan Hedera helix Gorjanc Plezalke, d.o.o. (07)555 01 24 12,46

59. Teorija načrtovanja (Design Theory)
• Teorija načrtovanja ne sporoča „kako načrtovati“,
temveč „kaj gre lahko narobe, če ne upoštevaš pravil“.
• Teorijo predstavljajo normalne oblike, ki so koraki v
procesu normalizacije.
• Višja kot je normalna oblika, boljše je iz stališča teorije
načrtovanja.
59

60. Normalizacija
• Je proces zagotavljanja učinkovite strukture podatkov.
• Neupoštevanje normalizacije je rezultat slabe
strukture. Ta vodi v nekonsistentnost, napake, težave
pri vzdrževanju in redundanco podatkov.
• Prednosti normalizacije:
– Hitrejši popravki in lažje dodajanje podatkov
– Večja konsistentnost in manj anomalij
– Jasna relacijska razmerja
– Fleksibilna struktura
– Manj zasedenega prostora
• Proces predstavlja več t.i. normalnih oblik, ki jih je
potrebno doseči.
60

61. Normalne oblike
61

62. Uvod v normalizacijo
• Obstaja več normalnih oblik (1NO, 2NO, …)
• V kolikor dosežemo (n+1)NO, dosežemo hkrati nNO.
• Za relacijo je možno, da je v nNO, a ne v (n+1)NO.
• Višja kot je NO, boljše je.
• Teorija načrtovanja predstavlja „zdravo pamet“, a
hkrati tudi „formalizirano zdravo pamet“.
• Normalizacija je zdravilo, a ne „zdravilo za vse
bolezni“.
62

63. Prva normalna oblika (1NO)
• Prvotna definicija: Relacija je v 1NO, ko vsak zapis vsebuje natanko
eno atomarno vrednost v vsaki poziciji atributa.
• Relacija je v 1NO (1971), ko vsak zapis vsebuje natanko eno
vrednost pripadajočega podatkovnega tipa za posamičen atribut.
• Ključ je definiran, NULL ne obstaja.
• Primer normalizacije v relacijo 1NO.
63
SNO PNO
S2 P1
S2 P2
S3 P2
S4 P2
S4 P4
S4 P5
SNO PNO
S2 P1, P2
S3 P2
S4 P2, P4, P5
S3 P2

64. 1NO – primer
• Uredi, da bo tabela Customer ustrezala relaciji 1NO!
64

65. Druga normalna oblika (2NO)
• Relacija je v 2NO (1971), če je v 1NO, hkrati pa so vsi
atributi, ki niso del ključa, odvisni od celotnega ključa in
to kateregakoli ključa!
• V kolikor je ključ enostaven (za razliko od sestavljenega)
in je en sam, je relacija avtomatično v 2NO.
• Lahko nastopijo anomalije pri spreminjanju podatkov:
npr. ukaz UPDATE.
65

66. 2NO – primer
• Slika kaže primer relacije, ki ima več ključev (npr. {Model Full
Name}, {Manufacturer, Model})
• Funkcionalna odvisnost: Manufacturer → Manufacturer Country
• Relacija še ni v 2NO.
66

67. Tretja normalna oblika (3NO)
• 3NO (1971) je v Computer Database Science običajna NO, ki
se koristi pri procesu normalizacije.
• Relacija je v 3NO, če je v 2NO, hkrati pa so vsi atributi, ki
niso del ključa, odvisni direktno od celotnega ključa relacije
in to kateregakoli ključa!
• V tem primeru ni tranzitivne odvisnosti.
• „Every non-key attribute must provide a fact about the key,
the whole key, and nothing but the key.“… „so help me
Codd.“
• Pri 3NO so anomalije glede UPDATE, INSERT in DELETE
večinoma odpravljene.
• Relacije z enim atributom, ki ni del ključa, so avtomatično v
3NO.
67

68. 3NO – primer
• (Tournament, Year) → Winner Birth → Winner
68
Tournament Year Winner Winner Birth
Indiana 1998 Al Fredrickson 21.7.2975
Cleveland 1999 Bob Albertson 28.9.1969
Bonn 1999 Al Fredrickson 21.7.1975
Indiana 1999 Chip Masterson 14.3.1977
Tournament Year Winner
Indiana 1998 Al Fredrickson
Cleveland 1999 Bob Albertson
Bonn 1999 Al Fredrickson
Indiana 1999 Chip Masterson
Winner Winner Birth
Al Fredrickson 21.7.2975
Bob Albertson 28.9.1969
Chip Masterson 14.3.1977

69. 3NO – vaja
• Podana je relacija R1 in odvisnosti. Pretvori v 3NO.
– R1 (A, B, C, D, E)
• A → BCDE
• BC → ADE
• D → E
• Postopek:
1. Poiščemo ključ(e) relacije: A, BC
2. Razdelimo atribute na ključne in neključne
• Ključni atributi: A, B, C
• Neključni atributi: D, E
3. Preverimo pravilo za 2NO (problem bi bil, če obstaja B → D,E oz. C → D,E), takšne funkc.
odvisnosti ni, zato R1 ustreza 2NO.
4. Preverimo pravilo za 3NO (problem bi bil, če obstaja D → E oz. E → D), 3NO ni izpolnjena, ker
obstaja D → E.
5. Normalizacija v 3NO: R1 načrtujemo kot R11 in R12. R11 (D, E) in R12 (A, B, C, D)
• Podana je relacija R2 in odvisnosti. Pretvori v 3NO.
– R2 (A, B)
• A → B
• Relacija je v 3NO
69

70. Boyce-Codd normalna oblika (BCNO ali 3.5NO)
• Relacija je v BCNO, če je v 3NO, hkrati pa je za
vse netrivialne funkcionalne odvisnosti (X→Y),
X superključ.
• Rešuje anomalije, ki jih dopušča 3NO.
• Definirana 1974, 3 leta po 3NO. BCNO bi bila
lahko poimenovana po avtorju Ian Heath
(1971).
70

71. BCNO - primer
71

72. BCNO – primer (nadaljevanje)
• 2NO ne dovoljuje delne funkcionalne odvisnosti neključnih atributov in to
kateregakoli (kandidatnega) ključa. 3NO ne dovoljuje tranzitivne odvisnosti
neključnih atributov in to kateregakoli (kandidatnega) ključa.
• V tem primeru neključni atributi sploh ne obstajajo! Vsi atributi so namreč del
nekega (kandidatnega) ključa.
• Relacija ustreza 2NO in 3NO.
• Relacija ne ustreza BCNO, ker obstaja funkcionalna odvisnost F ≡ {RateType →
Court}, kjer RateType ni superključ.
• (Kandidatni) ključi za Rate Types so {Rate Type} in {Court, Member Flag}.
(Kandidatni) ključi za Today's Bookings so {Rate Type, Start Time} and {Rate Type,
End Time}. Obe relaciji sta v BCNO.
• Anomalija enega Rate Type za dva Courts zdaj ni več možna.
72

73. BCNO – vaja
• Podana je relacija R(A, B, C, D) in funkcijske
odvisnosti:
a. C → D, C → A, B → C
b. B → C, D → A
c. ABC → D, D → A
d. A → B, BC → D, A → C
e. AB → C, AB → D, C → A, D → B
Za vsako ugotovi, v kateri normalni obliki je R, in jo
pretvori v BCNO.
73

74. Peta normalna oblika (5NO)
• Relacija je v 5NO, če je v 4NO ter je vsaka netrivialna
stična odvisnost od R, predstavljena s superključom
relacije R.
• To pomeni, da sta v *{A,B}, A in B superključa relacije R.
• 5NO je izpolnjena kadar:
– Obstaja 4NO
– Če JD ne obstaja > 5NO
– Če JD obstaja
• Če je trivialna > 5NO
• Če je netrivialna
– Vsi Ri so super ključi > 5NO
– Drugače je 4NO
74

75. 5NO – primer
75
S IME STATUS MESTO
1 Jones 15 Paris
2 Smith 20 London
3 Jones 10 Paris
4 Luc 15 London
5 Alice 10 Paris
6 Jones 15 London
S IME
1 Jones
2 Smith
3 Jones
4 Luc
5 Alice
6 Jones
S STATUS
1 15
2 20
3 10
4 15
5 10
6 15
S MESTO
1 Paris
2 London
3 Paris
4 London
5 Paris
6 London

76. Stična odvisnost - primer
Supplier Part Project
S1 P1 R1
S1 P2 R2
S2 P1 R1
S2 P1 R2
76
Supplier Part
S1 P1
S1 P2
S2 P1
Supplier Project
S1 R1
S1 R2
S2 R1
S2 R2
Part Project
P1 R1
P2 R2
P1 R2
Supplier Part Project
S1 P1 R1
S1 P1 R2
… … …
Additive join

77. Šesta normalna oblika (6NO)
• Relacija je v 6NO, če ne obstajajo netrivialne
stične odvisnosti.
• 6NO je uporabljana predvsem v časovnih
bazah.
77
NAROCILO POSTAVKA KOLICINA
1 A 2
1 B 2
2 A 7
2 B 5
3 A 2

78. Postopek normalizacije za relacijo R (A, B, C, D)
• Legenda: FD – funkcionalna odvisnost, MD – večvrednostna odvisnost, JD - stična odvisnost.
• 1NO: Relacija, ki ima vse vrednosti atomarne.
• 2NO: R je v 1NO in
– K = {A, B}
– FD: A → C
– Postopek normalizacije v 2NO: dekompozicija relacije R (A, B, C, D) v R1 (A, C) in R2 (A, B, D).
• 3NO: R je v 2NO in
– K = {A, B}
– FD: C → D
– Postopek normalizacije v 3NO: dekompozicija relacije R (A, B, C, D) v R1 (C, D) in R2 (A, B, C).
• BCNO: R je v 3NO in
– K: {A, B}, {A, C}
– FD: B → D
– Postopek normalizacije v BCNO: dekompozicija relacije R (A, B, C, D) v R1 (B, D) in R2 (A, B, C).
• 4NO: R je v 3.5NO in
– K = {A, B, C}
– MD: {A ↠ B}, {A ↠ C}
– Postopek normalizacije v 4NO: dekompozicija relacije R (A, B, C, D) v R1 (A, B, D) in R2 (A, C) ali v R1 (A, B) in R2 (A, C, D).
– Namig za 4NO: V kolikor je R v 3NO in vsebuje FD-je, kjer vsi temeljijo na SK-ju (to skupaj je 3.5NO) in ima MD-je, kjer vsi temeljijo na SK-ju, je R v 4NO.
• 5NO: R je v 4NO in
– JD: * {(A, B), (C, D)}
– SK: {A, B}
– Postopek normalizacije v 5NO: dekompozicija relacije R (A, B, C, D) v R1 (A, B) in R2 (C, D).
– Namig za 5NO: V kolikor je R v 4NO in vsebuje JD-je, kjer vsi temeljijo na SK-ju, je R v 5NO.
78

79. Vaja
• Preoblikujte v relacijo 3NO!
79
Invoice Customer Name Address Qnt1 Part1 Amt1 Qnt2 Part2 Amt2 Qnt3 Part3 Amt3
1001 43 Jones 121 1st 200 Screw 2 300 Nut 2.25 100 Wash 0.75
1002 55 Smith 222 2nd 1 Motor 52 5 Brace 44.44
1003 66 Marc 333 3rd 10 Saw 121

80. Vaja - rešitev
• Rešitev za 1NO
80
Invoice Line Customer Name Address Qnt Part Amt
1001 1 43 Jones 121 1st 200 Screw 2
1001 2 43 Jones 121 1st 300 Nut 2.25
1001 3 43 Jones 121 1st 100 Wash 0.75
1002 1 55 Smith 222 2nd 1 Motor 52
1002 2 55 Smith 222 2nd 5 Brace 44.44
1003 1 66 Marc 333 3rd 10 Saw 121

81. Vaja - nadaljevanje
81
Invoice Customer Name Address
1001 43 Jones 121 1st
1002 55 Smith 222 2nd
1003 66 Marc 333 3rd
Invoice Line Qnt Part Amt
1001 1 200 Screw 2
1001 2 300 Nut 2.25
1001 3 100 Wash 0.75
1002 4 1 Motor 52
1002 5 5 Brace 44.44
1003 6 10 Saw 121
Invoice Customer
1001 43
1002 55
1003 66
Customer Name Address
43 Jones 121 1st
55 Smith 222 2nd
66 Marc 333 3rd
Invoice Line Qnt Part Amt
1001 1 200 Screw 2
1001 2 300 Nut 2.25
1001 3 100 Wash 0.75
1002 4 1 Motor 52
1002 5 5 Brace 44.44
1003 6 10 Saw 121
• Rešitev za 2NO
• Rešitev za 3NO

82. Grafična podpora kot pomoč pri analizi
funkcionalnih odvisnosti
• Grafična analiza odvisnosti
• Poiščemo atribute, ki niso določljivi (without incoming edge)
• Ti atributi so ti. Essentials atributi in so gotovo del ključa
• V kolikor Essentials ne predstavljajo ključa dodamo sprva en
dodaten atribut in iščemo ključ dalje. Nato dodamo dva dodatna
atributa itd.
82
• Essentials:D
• D ne nastopa v nobeni FD
• Iščemo možnosti:
– AD: da
– BD: da
– CD: ne
– DE: da
– DF: da
– DG: ne
– DH: ne
– CDH: ne
– CDG: ne
– DGC: ne
– CDGH: ne
• ODG: 1NO

83. Vaja
• R (A, B, C, D)
• AB → C
• C → D
• Kaj je ključ in katera je normalna oblika?
83

84. Vaja - rešitev
• R (A, B, C, D)
• AB → C
• C → D
• Kaj je ključ in katera je normalna oblika?
• Rešitev naloge:
– Ključ: AB
– 2NO
– Normalizacija v 3NO:
• R1 (A, B, C)
• R2 (C, D)
84

85. Vaja
• R (A, B, C)
• AB → C
• C → B
• Kaj je ključ in katera je normalna oblika?
85

86. Vaja - rešitev
• R (A, B, C)
• AB → C
• C → B
• Kaj je ključ in katera je normalna oblika?
• Rešitev naloge:
– Ključ: AB, AC
– 3NO
– BCNO
• R1 (A, C)
• R2 (C, B)
86

87. Odvisnosti med ključnimi ter neključnimi
atributi, pravila za normalne oblike
• BCNO: α (super-key) → β (prime / non-prime)
• 3NO
– 2NO ter α (prime) → β (non-prime)
– IF α = SK ali K then 3NO else if β = prime then 3NO
else then !3NO
– 3NO ne ustreza v primeru α (non-prime) → β
(non-prime)
• 2NO ne ustreza: α (partial prime) → β (non-
prime)
87

88. Iskanje normalne oblike v
obratnem vrstnem redu
88
• R (A, B, C, D, E, F, G, H)
• AB → C
• A → DE
• B → F
• F → GH
• Key: AB
• ODG: 1NO
• R (A, B, C, D, E)
• CE → D
• D → B
• C → A
• Key: CE
• ODG: 1NO
• R (A, B, C, D, E, F)
• AB → C
• DC → AE
• E → F
• Key: ABD, BCD
• ODG: 1NO
• R (A, B, C, D, E, F, G, H, I)
• AB → C
• BD → EF
• AD → GH
• A → I
• Key: ABD
• ODG: 1NO
• R (A, B, C, D, E)
• AB → CD
• D → A
• BC → DE
• Keys: AB, BD, BC
• ODG: 3NO
• R (A, B, C, D, E)
• BC → ADE
• D → B
• Keys: BC, CD
• ODG: 3NO
• R (A, B, C, D, E, F)
• ABC → D
• ABD → E
• CD → F
• CDF → B
• BF → D
• Keys: ABC, ACD
• ODG: 1NO
• R (A, B, C)
• A → B
• B → C
• C → A
• Keys: A, B, C
• ODG: BCNO

89. Vaja
• R (A, B, C, D, E, F)
• C → F
• E → A
• EC → D
• A → B
• Rešitev:
– Ključi: CE
– Normalna oblika: 1NO
• R (A, B, C, D, E, F)
• A → B
• BC → D
• E → C
• D → A
• Rešitev:
– Ključi: AEF, BEF, DEF
– Normalna oblika: 1NO
89

90. Vaja
• Preoblikujte v relacijo BCNO!
90
ClientNo interviewDate interviewTime staffNo roomNo
CR76 13-May-02 10.30 SG5 G101
CR76 13-May-02 12.00 SG5 G101
CR74 13-May-02 12.00 SG37 G102
CR56 1-Jul-02 10.30 SG5 G102

91. Vaja - rešitev
• FD1: staffNo, interviewDate, interviewTime 
clientNo (Ključ)
• FD2: roomNo, interviewDate, interviewTime 
clientNo, staffNo (Ključ)
• FD3: staffNo, interviewDate  roomNo (Ni ključ)
• Težave z UPDATE: v primeru spremembe roomNo
za staffNo SG5 in 13-May-02 potrebujeta
spremembo dva zapisa.
91
ClientNo interviewDate interviewTime staffNo
CR76 13-May-02 10.30 SG5
CR76 13-May-02 12.00 SG5
CR74 13-May-02 12.00 SG37
CR56 1-Jul-02 10.30 SG5
staffNo interviewDate roomNo
SG5 13-May-02 G101
SG37 13-May-02 G102
SG5 1-Jul-02 G102

92. Normalizacija - primer
• Normaliziraj v 3NO
• 1NO
• 2NO
– Projekti (ProjektID, Ime Projekta)
– Delavci (DelavecID, Poklic, VrednostUre)
– Evidenca (ProjektID, DelavecID, OpravljenihUr)
• 3NO
– Projekti (ProjektID, Ime Projekta)
– Delavci (DelavecID, Poklic)
– Poklici (Poklic, VrednostUre)
– Evidenca (ProjektID, DelavecID, OpravljenihUr)
92
ProjektID ImeProjekta DelavecID Priimek Poklic VrednostUre OpravljenihUr
1 EU-1001 1 Kos Programer 20 35
2 Volk DBA 15 42
3 Senica Analitik 25 42
4 Vrabec Programer 20 30
2 EU-1002 2 Volk DBA 15 32
4 Vrabec Programer 20 32
ProjektID ImeProjekta DelavecID Priimek Poklic VrednostUre OpravljenihUr
1 EU-1001 1 Kos Programer 20 35
1 EU-1001 2 Volk DBA 15 42
1 EU-1001 3 Senica Analitik 25 42
1 EU-1001 4 Vrabec Programer 20 30
2 EU-1002 2 Volk DBA 15 32
2 EU-1002 4 Vrabec Programer 20 32

93. Normalizacija - primer
• 2NO
– Projekti (ProjektID, Ime Projekta)
– Delavci (DelavecID, Poklic, VrednostUre)
– Evidenca (ProjektID, DelavecID, OpravljenihUr)
• 3NO
– Projekti (ProjektID, Ime Projekta)
– Delavci (DelavecID, Poklic)
– DelovnoMesto (Poklic, VrednostUre)
– Evidenca (ProjektID, DelavecID, OpravljenihUr)
93

94. FIZIČNI MODEL
94

95. Fizični model
• Fizični model mora slediti relacijskemu modelu, ki je
povsem neodvisen od fizičnega modela.
• Relacijski model se osredotoča na „kaj podatki
pomenijo“, fizični model se osredotoča na „kako bodo
podatki uporabljani“.
• Pravilen pristop je oblikovanje logičnega modela, nato pa
podprtje s fizičnimi strukturami izbranega SUPB.
• Najprej definiramo relacijske spremenljivke, funkcionalne
odvisnosti, večvrednostne odvisnosti, stične odvisnosti,
itd.
• Fizični model naj izhaja predvsem iz logičnega modela.
95

96. Načrtovanje fizičnega modela
• Ne gre za direktno preslikavo modela (Direct image style)!
Stroga odvisnost od logičnega modela ni želena.
• V primeru težav s performansami je možna denormalizacija
v fizičnem modelu. Logični model se ne sme spremeniti, ker
nima ničesar skupnega s performansami!
• Želena je avtomatizacija preslikave v fizični model. Upanje
predstavlja tehnologija The TransRelationalTM Model.
96
…Atributi…
Zapis
Zapis
Zapis
Zapis
…Stolpci…
Vrstica
Vrstica
Vrstica
Vrstica

97. Omejitve (constraints) v SUPB
97

98. Transakcije
• Transakcija je zaporedje ukazov (akcij), ki predstavlja celoto.
• ACID
– Atomarnost (Atomicity)
• Neuspešna transakcija ne sme pustiti stanja delno izvedene transakcije.
– Konsistentnost (Consisteny)
• Podatki, ki so bili konsistentni pred transakcijo, morajo ostati konsistentni tudi
po njej.
– Izoliranost (Isolation)
• Ločena obravnava podatkov
• Konkurenčne akcije v bazi morajo biti izolirane. Na videz izgleda, kot da se izvaja
samo ena transakcija.
– Trajnost (Durability)
• Podatki po zaključeni transakciji morajo biti trajno shranjeni, četudi pride do
izpada sistema.
• Transakcija se zgodi v celoti ali pa se sploh ne (COMMIT / ROLLBACK)
98

99. Transakcije
• Primer transakcije je plačilo z bančno kartico
– Obremenimo račun imetnika kartice
– Dodamo znesek na račun trgovine
– Nesprejemljivo je, da se izvede samo prvi del.
• Če se transakcija iz kakršnega koli razloga prekine tekom izvajanja,
se mora SUPB vrniti na začetno stanje (ROLLBACK).
• Podatke o transakciji je potrebno pisati v nek začasen pomnilnik.
• Po izvršeni transakciji se vpišejo v trajni del baze. Zapisani morajo
biti na disk, da se ne izgubijo.
• Pri upravljanju s transakcijami se moramo zavedati razlik med načini
shranjevanja podatkov: začasno shranjevanje (RAM), trajnejše
shranjevanje (diski, diskovna polja), trajno shranjevanje (arhivi).
99

100. SQL
100

101. Poizvedovalni jezik SQL
• SQL (Structured Query Language)
• SQL je najbolj razširjen računalniški jezik, ki omogoča kreiranje,
spreminjanje, branje in manipulacijo s podatki, shranjenimi v
relacijski PB.
• Jezik SQL je standardiziran (ANSI / ISO), vendar je upoštevanje
standardov s strani nekaterih proizvajalcev SUPB le delno.
• Čeprav se imenuje „query language“, vsebuje tudi:
– DDL (Data Definition Language) - jezik za definicijo podatkov
– DML (Data Manipulation Language) - jezik za manipulacijo s podatki
– DCL (Data Control Language) – jezik za kontrolo nad podatki
– Zagotavljanje integritete podatkov
– Nadzor nad transakcijami
– Avtorizacijo
– Programske stavke (pogoji, zanke, spremenljivke itd.)
101

102. Nekateri konstrukti v SQL
• SELECT
• FROM
• WHERE
• INSERT, DELETE, UPDATE
• CREATE, ALTER
• IF, FOR, WHILE, CASE WHEN, LIKE
• INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN
• ORDER BY, GROUP BY, HAVING
• COUNT, SUM, AVG, MIN, MAX, STDEV, VAR, DISTINCT
• AS, =, <, <=, BETWEEN
• TO_CHAR, TO_DATE, TO_NUMBER
102