1

Jože Smolnikar, univ. dipl. mat.

ZBIRKE PODATKOV 1
Delovno gradivo

Ljubljana, september 2014

Zbirke podatkov 1
2

Zbirke podatkov 1
 3

KAZALO
KAZALO ..................................................................................................................... 3
UVOD .......................................................................................................................... 5
PREGLED POJMOV ................................................................................................................. 6
OSNOVE ZBIRK PODATKOV.................................................................................. 16
RAZVOJ PODATKOVNIH SISTEMOV ......................................................................................... 18
ZBIRKA PODATKOV .............................................................................................................. 22
ARHITEKTURA ZP IN PODATKOVNA NEODVISNOST.................................................................. 31
JEZIKI IN PRIHODNOST ZBIRK PODATKOV ............................................................................... 38
SUZP - SISTEM ZA UPRAVLJANJE ZBIRKE PODATKOV ............................................................. 40
UPORABNIKI ZP IN ORODJA .................................................................................................. 50
RAZVOJ APLIKACIJ ZA DELO Z ZP .......................................................................................... 59
KONCEPTUALNO MODELIRANJE ......................................................................... 70
OBLIKOVANJE KONCEPTUALNEGA MODELA ............................................................................ 70
MODEL E-R ........................................................................................................................ 76
RELACIJSKI PODATKOVNI MODEL ...................................................................... 93
RELACIJSKI MODEL PODATKOV ............................................................................................. 93
PRESLIKAVA MODELA E-R V RELACIJSKI MODEL ................................................................... 106
NORMALIZACIJA ................................................................................................................ 111
STRUKTURIRANI POVPRAŠEVALNI JEZIK (SQL) ............................................. 127
SQL DDL (DATA DESCRIPTION LANGUAGE) ........................................................................ 128
SQL DCL (DATA CONTROL LANGUAGE) ............................................................................. 136
SQL DML (DATA MANIPULATION LANGUAGE) ..................................................................... 138
POIZVEDBE S PRIMER ELEMENTI (QBE) ........................................................... 155
UPORABA POIZVEDB .......................................................................................................... 156
DOLOČANJE POGOJEV ....................................................................................................... 160
UPORABA IZRAČUNLJIVIH POLJ ........................................................................................... 166
POIZVEDBA S PARAMETROM ............................................................................................... 168
KALKULACIJE NAD SKUPINAMI PODATKOV (GRUPIRANJE) ...................................................... 168
POIZVEDBE S SPREMEMBO (AKCIJSKE POIZVEDBE) .............................................................. 170
VIRI IN LITERATURA ............................................................................................. 175

Zbirke podatkov 1
4

Zbirke podatkov 1
 5

UVOD
Zbirke podatkov (podatkovna baza; ZP) postajajo vse bolj nepogrešljiv del kateregakoli
računalniško podprtega poslovnega ali tehničnega sistema. Besedna zveza podatkovna
baza je bolj ali manj dobesedni prevod ameriškega izraza database in ne odraža pravega
pomena originala. Po slovensko bi morali govoriti o podatkovni osnovi, s čimer bi še veliko
bolj približali pravemu pomenu, saj gre za tisto osnovo, ki omogoča izvajanje vseh mogočih
uporabniških programov, ki morajo za svoje izvajanje podatke od nekod črpati. Podatkovna
osnova (opis okolja s pomočjo podatkov) je običajno namreč tisti temelj, ki omogoča
komunikacijo z okoljem.
Za področje tradicionalne avtomatske obdelave podatkov (AOP) je značilno, da so podatki
shranjeni v obliki datotek, katerih »lastniki« so funkcionalne enote, na katere je organizacija
razdeljena. Vsaki enoti pripada množica datotek, ki predstavljajo podatkovno osnovo, na
kateri temelji njeno delovanje. Zaradi težnje po podatkovni samozavestnosti skrbi vsaka
enota za svoje datoteke, ki jih vzdržuje in obdeluje s svojimi uporabniškimi programi ter si jih
praviloma ne deli z drugimi enotami. Tipični problemi, ki izhajajo iz take privatizacije
podatkov in programov, so:
 neustrezna predstavitev modela organizacije in njenega okolja,
 nemoč odgovoriti na vnaprej nepredvidena vprašanja,
 oteženo prilagajanje podatkov spremembam v okolju,
 vprašljiva kvaliteta podatkov.
Datotečno shranjevanje podatkov omejuje možnosti predstavitve modela organizacije in
njenega okolja v naravni, za uporabnike razumljivi obliki. Povezava podatkov iz različnih
datotek v smiselno celoto je izvedena preko uporabniških programov. Model torej ni
sestavljen le s podatki, pač pa je v veliki meri zakodiran tudi v uporabniške programe.
Modeliranje je tako odvisno tudi od programerjev in njihovega razumevanja pomena
podatkov v datotekah.
Nekaterih vidikov modela se zaradi po enotah ločenih in ne povezljivih datotek preprosto ne
da predstaviti in tako ni mogoče poiskati podatkov, ki sicer obstajajo v datotekah, za
oblikovanje odgovora na preprosta vprašanja. Če sama povezljivost ni problem, pa je ob
naprej nepredvidenih vprašanjih težava v tem, da bi bilo potrebno za iskanje odgovora razviti
ustrezen uporabniški program, pred tem pa seveda ugotoviti, v katerih datotekah, ki lahko
pripadajo različnim enotam v organizaciji, se podatki nahajajo. Vse to je težko izvesti v
realnem času - namreč do takrat, ko je ukrepanje na osnovi zahtevanega odgovora še
smiselno oziroma pravočasno.

Beležke

Zbirke podatkov 1
6

Če naj človek ukrepa na osnovi podatkov, mora iz njih pridobiti najprej ustrezno informacijo,
pri čemer mora natanko vedeti, kaj ti podatki pomenijo. V datotekah so tipično shranjene le
vrednosti, na kaj se te vrednosti nanašajo oziroma kaj pomenijo pa je preprosto prepuščeno
njihovemu interpretiranju v stilu "Saj to je pa vsem jasno!". Ker ene in iste podatke uporablja
več ljudi, jih morajo vsi razumeti pravilno in na enak način, saj napačna interpretacija pomeni
tudi napačno ukrepanje.
Shranjevanje podatkov v zbirki podatkov odpravlja večino slabosti in pomanjkljivosti, uvaja
pa seveda nekatere nove probleme, kot sta npr. zaupnost in sočasna uporaba podatkov.

Pregled pojmov
O podatkih
Vtise, ki jih človek sprejema s svojimi čutili iz sveta v katerem živi, s pomočjo svojega znanja
ovrednoti ter si tako dopolnjuje svoje znanje – svoj miselni model sveta, ki se nanaša tako na
fizično obstoječi svet kakor tudi na svet idej.
Posameznikov ali skupinski pogled na svet so ljudje že od nekdaj zapisovali in s tem
omogočili dostop do lastnega, tujega oziroma skupnega znanja. Če se pri zapisovanju
uporablja konvencija, ki omogoča jedrnato predstavitev dejstev, pravimo takim zapisom
podatki.
Podatek je predstavitev nekega dejstva na formaliziran način, ki je dogovorjen s konvencijo
in primeren za komunikacijo, interpretacijo ter obdelavo s strani človeka ali stroja. Podatek je
diskreten, če se pri njegovi predstavitvi uporabljajo simboli, ali pa analogen, če se za
predstavitev uporablja kakšna fizikalna veličina. Podatku se lahko pripiše pomen le v
določenem kontekstu.
Informacija je pomen (spoznanje), ki ga človek pripiše podatkom s pomočjo znanih
konvencij, ki so uporabljene pri njihovi predstavitvi. Podatki posredujejo informacijo
prejemniku, katerega sprejemna struktura je konsistentna z izbrano predstavitvijo podatkov
in modelom sveta, na katerega se nanašajo.
Osnovne komponente podatkovnega sistema so človek, program, podatki in računalnik. Z
razvojem strojne in programske opreme se je odnos med njimi spreminjal. V prvem obdobju
je bil v središču pozornosti računalnik (stroj), ki so se mu prilagajale ostale tri komponente. S
programsko revolucijo je prešla pozornost na program (programski jezik), ki se je
približeval človeku in postal bolj neodvisen od računalnika. Po podatkovni revoluciji je
največ pozornosti posvečene podatkom, ki so se kot pred tem programi, približevali človeku
in postali razmeroma neodvisni od strojne in programske opreme.
Zbirka podatkov
Zbirka podatkov (ZP) je model okolja, ki služi kot osnova za sprejemanje odločitev in
izvajanje akcij, in je mehanizirana, večuporabniška, formalno definirana in centralno
nadzorovana zbirka podatkov.
Upravljanje ZP, ki ga izvaja sistem za upravljanje zbirke podatkov (SUZP; SUPB; DBMS),
zajema zagotavljanje razpoložljivosti podatkov in nadzor nad uporabo podatkov, v katerega
okvir sodi skrb za celovitost podatkov, uporabo podatkov v skladu z njihovim namenom in
uporabnost podatkov tudi v prihodnje. Razpoložljivost podatkov pomeni, da je zagotovljen
učinkovit dostop vsem uporabnikom sočasno do vseh vrst podatkov in to ves čas. Celovitost
podatkov v ZP se zagotavlja s preverjanjem vhodnih podatkov ob ažuriranjih ZP,
obnavljanjem ZP v primerih nesreč, nadzorom nad sočasnim dostopom do podatkov, in
sočasnim ažuriranjem vseh kopij podatkov v ZP, če le-te obstajajo. Za zagotovitev pravilne

Zbirke podatkov 1
 7

in dovoljene uporabe podatkov v skladu z njihovim namenom, mora v okviru ZP obstajati

uporabnikom razumljiv opis njihovega pomena in sistem nadzorovanih dostopov do njih.
Razen zbirk podatkov za shranjevanje formatiranih podatkov obstajajo tudi druge vrste
podatkovnih sistemov kot npr. referenčni sistemi, sistemi za obdelavo besedil, bibliografski
sistemi, specializirane zbirke podatkov, zbirke znanja in objektne zbirke podatkov. Zbirko
podatkov sestavljajo podatki, uporabniki in uporabniški programi, upravitelj zbirke podatkov
in SUZP.
Podatkovni del ZP sestavlja:
 fizična zbirka podatkov (FZP),
 metazbirka podatkov (MZP).
V skladu s trinivojsko arhitekturo ZP je razdeljena MZP na notranjo shemo, konceptualno
shemo in zunanje sheme, ki predstavljajo tri vrste opisov FZP.
Na nivoju operacijskega sistema se FZP kaže kot zbirka fizičnih datotek, shranjenih v
zunanjem pomnilniku računalniškega sistema, na notranjem nivoju je FZP predstavljena kot
zbirka logičnih zapisov različnih tipov in njihovih medsebojnih povezav, na konceptualnem
nivoju pa jo dojemamo kot imena, lastnosti in povezave entitet iz modeliranega okolja ter ji
pravimo tudi konceptualna ZP, predstavljajoča logični model okolja. Na zunanjem nivoju se
FZP pokaže kot uporabnikov model okolja.
Trinivojska arhitektura ZP omogoča in zagotavlja podatkovno neodvisnost, ki jo delimo na
fizično in logično podatkovno neodvisnost. Fizična podatkovna neodvisnost je mera za vpliv
sprememb z notranjega nivoja na konceptualni nivo, logična podatkovna neodvisnost pa je
mera za vpliv sprememb s konceptualnega nivoja na zunanji nivo.
Uporabnike ZP delimo na posredne in neposredne, slednje pa na končne uporabnike, kot so
parametrični, menijsko vodeni in uporabniki povpraševalnega jezika, ter uporabnike ZP, kot
so upravitelj ZP ter uporabniški in sistemski programerji, ki so v pomoč končnim
uporabnikom.
SUZP izvaja dostopne in kontrolne funkcije pri upravljanju ZP. Dostopne funkcije
omogočajo upravitelju ZP definiranje shem ter kreiranje in reorganiziranje ZP, splošnim
uporabnikom pa zajemanje in ažuriranje podatkov v ZP. Kontrolne funkcije delimo v
zaščitne in nadzorne funkcije, katerih delovanje je prikrito uporabnikom in se samodejno
aktivirajo pri uporabi dostopnih funkcij. Zaščitne funkcije skrbijo za celovitost zbirke
podatkov in preverjajo uporabniške pravice do rokovanja s podatki.
Poglavitni moduli, iz katerih je sestavljen SUZP so:
 kontrolni sistem,
 povpraševalni procesor,
 menijski procesor,
Beležke

Zbirke podatkov 1
8

 metapodatkovni procesor,
 predprevajalniki.
SUZP se lahko nahaja v istem računalniku kot uporabniški programi, lahko pa se nahaja v
samostojnem podatkovnem strežniku, ki je preko hitre komunikacijske poti povezan z enim
ali več računalniškimi sistemi, na katerih se izvajajo uporabniški programi.
Zbirka podatkov je lahko shranjena zgolj v enem strežniku, lahko pa je porazdeljena preko
več strežnikov. Od stopnje porazdelitvene transparentnosti je odvisno, ali dojema uporabnik
zbirko podatkov kot enotno, ali pa se zaveda njene porazdelitve, ki jo mora potem pri
povpraševanju tudi upoštevati.
Fizična zbirka podatkov
Podatkovni del zbirke podatkov sestavljata fizična in metazbirka podatkov. V obliki fizičnih
datotek se shranjujeta v zunanjem pomnilniku, ki je v današnjem času najpogosteje
diskovni pomnilnik. Za dostop do fizičnih datotek v znanjem pomnilniku skrbi operacijski
sitem.
Elementarne pomnilniške enote v diskovnem pomnilniku so sektorji, od katerih se vsak
nahaja na določenem cilindru, določeni površini in ima določen odmik od začetka sledi, na
kateri leži. Sektorji se grupirajo v dodelitvene enote, ki so najmanjši deli diskovnega
pomnilnika, ki se lahko dodelijo posamezni fizični datoteki. Diskovni pomnilnik je razdeljen na
del, ki vsebuje podatke o diskovni enoti, na del, ki vsebuje dodelitveno tabelo, na del, ki
vsebuje datotečni seznam na disku shranjenih fizičnih datotek, in del, ki je razdeljen na
dodelitvene enote, v katerih so shranjene fizične datoteke. S stališča SUZP je fizična
datoteka sestavljena iz enako velikih fizičnih blokov, katerih vsak obsega enega ali več
sektorjev oziroma eno ali več dodelitvenih enot. V notranjem pomnilniku je vsaki aktivni
fizični datoteki prirejenih eden ali več datotečnih vmesnikov v velikosti fizičnega bloka, preko
katerih se izvaja dostop do datoteke.
Logična datoteka je množica logičnih zapisov istega tipa, ki s pomočjo podatkovnih
elementov opisujejo enakovrstna dejstva. Tip zapisa je formalizem, s pomočjo katerega se
lahko oblikujejo in berejo zapisi pripadajočega tipa. S tipom zapisa je predstavljena struktura
zapisov ter vrsta in oblika podatkovnih elementov, ki sestavljajo zapise. Zapisi so lahko
spremenljive ali nespremenljive dolžine.
Podatkovne elemente, na osnovi katerih je možna identifikacija posameznih zapisov,
imenujemo ključ zapisa, ki obsega enega ali več podatkovnih elementov navedenih v tipu
zapisa. Ključ je lahko razločevalen ali nerazločevalen, služi pa tudi za urejanje zapisov v
fizičnih datotekah.
Logični zapisi se s pomočjo fizičnih zapisov shranjujejo v fizičnih datotekah. Fizični zapisi
so po strukturi lahko enaki logičnim zapisom, lahko pa vsebujejo tudi dodatne
(meta)podatkovne elemente. Fizični zapisi se zapisujejo v naslovljiva polja, na katera so
razdeljeni fizični bloki. Posamezna polja lahko vsebujejo zapise ali pa so prosta
(nezasedena). Če je pomemben naslov polja, v katerem je shranjen posamezen zapis,
potem je zapis vezan na polje, v nasprotnem primeru pa nevezan.
Osnovne operacije nad zapisi v fizičnih datotekah so iskanje zapisov po datoteki, dodajanje
zapisov v datoteko, ter brisanje in spreminjanje v datoteki obstoječih zapisov. Zapise lahko
iščemo po vrednosti poljubne kombinacije podatkovnih elementov, pri čemer je iskanje po
vrednosti ključa najhitreje izvedljivo, ker je podprto z datotečno organizacijo. Iščemo jih lahko
tudi s pomočjo naslovov polj ali skupin polj, v katerih naj bi se nahajali.
Najpreprostejša datotečna organizacija je neurejena datoteka, pri kateri ni predpisa, ki bi
urejal lego zapisov v njej. V zaporedni datoteki so zapisi urejeni po vrednosti ključa – ključ

Zbirke podatkov 1
 9

predhodnega zapisa mora biti manjši ali enak ključu naslednika. Zaporedje je lahko urejeno s
fizičnim zaporedjem zapisov v datoteki ali pa s kazalci.
V razpršenih datotekah urejajo lego zapisov v njih razpršilne funkcije. Zapisom se lahko
prirejajo polja ali pa skupine polj. Pri statičnem razprševanju se število skupin ne spreminja,
pri dinamičnem pa se prilagaja zasedenosti datoteke z zapisi. Pri razpršenih datotekah je
možen hiter dostop do posameznih zapisov.
Indeks je datoteka, ki s pomočjo sistema kazalcev omogoča hiter dostop do zapisov z njo
indeksirane osnovne datoteke in tudi zaporedni dostop do zapisov nezaporedne datoteke. Z
ozirom na to ali si indeksirani vsi zapisi osnovne datoteke ali ne, je indeks lahko gost ali
redek. Če je indeksiranje izvedeno po ključu, je indeks primaren, sicer pa sekundaren. V
primeru, ko je tudi indeks indeksiran, govorimo o večnivojskem indeksiranju. V primeru, ko se
indeks prilagaja vsebini indeksirane datoteke, je indeksiranje dinamično, sicer pa statično.
Podatkovni modeli
Podoba sveta je človekova predstava o svetu, v katerem živi, in ki vključuje tudi njega
samega. Človekovo modeliranje sveta s zbirko podatkov temelji na podobi sveta, ki jo je
možno opisati s propozicijami, ki predstavljajo posamezni dogodek ali stanje.
Entiteta je tisti najmanjši del, ki ga lahko ločimo ali ga želimo ločiti od drugih delov podobe
sveta, in je predstavnik posamezne stvari ali dogajanja, ki obstaja ali mislimo, da obstaja v
svetu. Entitete, ki obstajajo, imenujemo participativne entitete, in so udeleženke v dogodkih,
entitete pa, ki se dogajajo, imenujemo predikatne entitete.
Entitete pripadajo entitetnim tipom, ki se delijo na naravne tipe in tipe z ozirom na vlogo.
Entitetnemu tipu pripada entitetna množica, ki je časovno spremenljiva. Entitete
poimenujemo s pomočjo besed, ki jih imenujemo entitetna imena. Entitetna imena so
podatki.
Za vse dogodke, ki pripadajo določenemu dogodkovnemu tipu, veljajo določene
zakonitosti. Pravilo predstavlja veljavno in nespremenljivo zakonitost o razmerjih med
entitetami v dogodkih določenega tipa. Pravila se delijo na preslikovalna in vrednostna.
Za modeliranje podobe sveta s zbirko podatkov se uporabljajo podatkovni modeli.
Obsegajo podatkovno strukturo, operacije nad podatkovno strukturo in integritetne omejitve.
Pri modeliranju s zbirko podatkov se na konceptualnem in zunanjem nivoju uporabljajo
logični modeli, na notranjem nivoju pa fizični modeli. Logične modele delimo na površinske in
globinske. Med površinske podatkovne modele, ki so zapisno orientirani, štejemo relacijski,
mrežni in hierarhični podatkovni model. Poglavitni globinski modeli so podatkovni model
»entiteta – razmerje«, binarni podatkovni modeli, podatkovni modeli na osnovi semantičnih
mrež in infološki podatkovni modeli.

Beležke

Zbirke podatkov 1
10

Problem sožitja med površinskimi in globinskimi podatkovnimi modeli rešuje koeksistenčni

princip, po katerem je konceptualni nivo zbirke podatkov razdeljen na infološki in dataloški
del.
Relacijski podatkovni model
Relacijski podatkovni model se uporablja za predstavitev zbirke podatkov na konceptualnem
in zunanjem nivoju, hkrati pa je tudi sredstvo za specifikacijo zunanjih shem. Je formalno
definiran, ne vsebuje elementov fizičnega shranjevanja podatkov. Relacije, na katerih temelji,
pa so predstavljive s tabelami. Osnovna koncepta relacijskega podatkovnega modela sta
domena in relacija.
Domene so množice, njihovi elementi pa so vrednosti predstavljive v obliki podatkov.
Relacija je podmnožica kartezijskega produkta liste domen oziroma množice n-teric, katerih
komponente so elementi domen. Število domen, nad katerimi je relacija definirana, se
imenuje stopnja relacije, število n-teric v njej pa moč relacije. Relacijo lahko definiramo tudi
kot množico preslikav imenovanih atributi. Vsak atribut preslika množico objektov v atributu
pripadajočo domeno.
Relacijska shema pojasnjuje pomen pripadajoče relacije. Sestavljata jo oznaka relacijske
sheme in lista oznak atributov s pripadajočimi oznakami domen. Relacijske sheme
predstavljajo semantično komponento relacijske zbirke podatkov in so del zunanjih shem.
Relaciji, ki se razlikujeta med seboj le v vrstnem redu komponent v n-tericah, z
matematičnega stališča nista enaki, po pomenu – informacijski vsebini – pa sta ekvivalentni.
Nekatere zakonitosti v svetu, ki ga relacije modelirajo, se v relacijskem podatkovnem modelu
opišejo s pomočjo funkcionalnih, večvrednostnih in stičnih odvisnosti. Funkcionalna
odvisnost množice atributov Y od množice atributov X velja v relacijski shemi, če v nobeni
pripadajoči relaciji ne moreta obstajati dve n-terici, ki bi se ujemali v vrednostih atributov X in
se ne bi ujemali v vrednostih atributov Y.
Ključ relacije oziroma njene sheme je tista minimalna množica atributov, ki funkcionalno
določa vse ostale atribute v relacijski shemi. S pomočjo vrednosti ključa lahko določimo med
seboj poljubni dve n-terici v relaciji. Relacijska shema ima lahko tudi več ključev, eden izmed
njih se izbere kot primarni ključ.
Operacije nad relacijami delimo v operacije, ki omogočajo povpraševanje oziroma iskanje
podatkov v zbirki podatkov, in operacije, ki omogočajo ažuriranje podatkov. Omenjene
operacije so sestavni del povpraševalnega jezika. Z ažurnimi operacijami se n-terice
dodajajo relacijam, se brišejo iz njih in se spreminjajo vrednosti njihovim komponentam.
Povpraševalni del povpraševalnega jezika lahko temelji na relacijski algebri ali relacijskem
računu.
Povpraševanje s pomočjo operacij relacijske algebre temelji na zaporedju operacij, ki se
izvedejo nad relacijami zbirke podatkov. Rezultat povpraševanja je spet relacija. Osnovne
operacije so unija, razlika, kartezijski produkt, projekcija in selekcija, izvedene pa presek,
stik, naravni stik in količnik.
Povpraševanje s pomočjo relacijskega računa temelji na specifikaciji lastnosti relacije, ki
jo želimo kot rezultat povpraševanja. Iskana relacija se opiše z izrazom, ki zajema formulo
predikatnega računa z eno prosto n-terično spremenljivko (n-terični račun) ali več prostimi
domenskimi spremenljivkami (domenski račun). Izraz relacijskega računa je varen, če
določa končno relacijo, pri čemer je za zagotovitev, da posamezna n-terica v njej nastopa,
dovolj preiskati le relacije v zbirki podatkov.
Primer relacijskega povpraševalnega jezika, ki združuje ukaze za rokovanje s podatki, s
tistimi za njihovo deklariranje in kreiranje ter zaščito, je SQL. Podatki so predstavljeni v obliki
tabel in pogledov, pri katerih deklaraciji se lahko specificirajo integritetne omejitve kot sta
ključ in obvezno podana vrednost atributov ob dodajanju vrstic. Povpraševalni del jezika sloni
Zbirke podatkov 1
 11

na n-teričnem relacijskem računu, kar uvršča SQL med nepostopkovne jezike. SQL je
primeren za interaktivno rabo, njegovi ukazi pa so tudi ugnezdeni v programske jezike.
Mrežni podatkovni model
Podatkovni strukturi, v kateri nastopajo med seboj povezani zapisi, pravimo mreža. Njena
osnovna gradnika sta zapis in set. Povezave med zapisi so določene s funkcijo S, ki
preslikuje zapise enega tipa v zapise drugega tipa. S sme biti totalna ali parcialna funkcija
in je v mreži predstavljena s seti. Set je urejena množica zapisov, ki jo sestavljajo lastnik
(zapis enega tipa) in člani (zapisi drugega tipa). Posamezen zapis je lahko sočasno lastnik
enega ali več setov in član enega ali več setov, lahko pa, da ne nastopa v nobenem setu.
Posebne vrste set je sistemski set, ki služi za ureditev in zaporedni dostop do zapisov
določenega tipa.
Mrežna shema pojasnjuje obliko in pomen zapisov ter njihovih povezav v mreži. Sestavljajo
jo deklaracije tipov zapisov in tipov setov. Deklaracija tipa zapisa obsega ime tipa, imena in
zaporedje podatkovnih elementov ter navedbo ključa, ki je lahko razločevalen ali
nerazločevalen. Deklaracija tipa seta obsega ime tipa seta, ime tipa lastnikov, ime tipa
članov ter navedbe urejenosti setov, vrste članstva in načina včlanjevanja v sete. Set je lahko
urejen z zaporedjem dodajanja članov vanj ali po vrednosti ključa članov. Članstvo v setu je
lahko fiksno, obvezno ali opcijsko. Način včlanjevanja članov v set je lahko ročen ali
avtomatičen.
Vrednostne integritetne omejitve so v mrežni shemi specificirane s pomočjo tipov
podatkovnih elementov v zapisih, preslikovalne omejitve pa s pomočjo deklaracije ključa
zapiskov in deklaracije vrste članstva v setih.
Operacije nad mrežo se dele v operacije za iskanje, ažuriranje in včlanjevanje zapisov.
Zapis se lahko poišče s pomočjo specifikacije vrednosti ključa (ali kakega drugega
podatkovnega elementa) ali s pomočjo setov (povezav med zapisi). Z ozirom na tekoči zapis
lahko poiščemo njegovega predhodnika ali naslednika v okviru specificiranega seta. Zapisu
članu lahko poiščemo lastnika seta, prav tako pa tudi prvi ali zadnji zapis v tekočem setu.
Zapis lahko dodamo mreži, na podlagi poiskanega naslova zapisa pa preberemo,
ažuriramo ali izbrišemo iz mreže. Brisanje se lahko nanaša le na tekoči zapis, lahko pa
prizadene kaskadno tudi člane njegovih setov. Zapisi se z ozirom na vrsto članstva lahko v
sete včlanijo, se iz njih izčlanijo ali pa prečlanijo iz enega v drugi set istega tipa.
Operacije nad mrežo se lahko izvedejo uspešno ali neuspešno. Kako se je operacija izvedla,
sporoča SUZP preko statusnega polja, ki ga mora uporabniški program po zaključku vsake
operacije nad zbirko podatkov preveriti.

Beležke

Zbirke podatkov 1
12

Hierarhični podatkovni model

Osnovni gradnik hierarhične podatkovne strukture je drevo. Množica dreves istega tipa tvori
gozd, hierarhična zbirka podatkov pa obseg enega ali več gozdov. Uporabnikov pogled na
zbirko podatkov je v določenem trenutku omejen na en sam gozd.
Drevesa so sestavljena iz med seboj povezanih zapisov. Povezave zapisov v drevesa
določajo preslikave med logičnimi datotekami. Preslikava ene logične datoteke v drugo je
totalna funkcija, pri čemer sme posamezna datoteka nastopati kot domena le v eni
preslikavi. Zapisom, ki nastopajo v domeni preslikave pravimo otroci, zapisi, ki nastopajo v
območju preslikave, pa so njihovi starši. List drevesa so le otroci, zapis v korenu pa le starš,
preostali zapisi pa nastopajo v obeh vlogah hkrati. Zapisi so v drevesih in gozdu urejeni v
hierarhično zaporedje.
Vsa drevesa posameznega gozda so enako strukturirana, v vseh se na istih nivojih nahajajo
zapisi iz istih logičnih datotek. Tip drevesa, ki mu pripadajo, izraža njihove skupne lastnosti
in pomen. Deklaracija tipa drevesa obsega ime tipa drevesa in deklaracije tipov zapisa, ki
zajemajo ime tipa zapisa, ime starša, deklaracijo ključa in listo imen podatkovnih elementov
vključno z njihovimi osnovnimi tipi. Hierarhično shemo hierarhične zbirke podatkov
sestavljajo deklaracije tipov dreves, ki nastopajo v posameznih gozdovih.
Operacije nad gozdom omogočajo dostop do zapisov in njihovo ažuriranje v drevesih gozda,
ki predstavlja trenutni uporabniški pogled. Povpraševanje se izvaja z uporabo iskalnih
ukazov, ki omogočajo poiskati in prebrati prvi zapis navedenega tipa, ki ustreza iskalnemu
pogoju, poiskati in prebrati naslednji zapis ob enakem iskalnem pogoju ter poiskati in prebrati
naslednji zapis v okviru istega starša (istega poddrevesa). Iskanje zapisov poteka vedno v
skladu s hierarhičnem zaporedjem.
Ažurirane operacije omogočajo brisanje, dodajanje in spreminjanje zapisov v gozdu.
Brisanje in spreminjanje se nanašata na tekoči zapis – zapis, ki je bil nazadnje poiskan. Pri
brisanju se ne izbriše le tekoči zapis, pač pa tudi poddrevo, v katerega korenu se tekoči
zapis nahaja. Spreminjanje vsebine zapisa je omejeno le na podatkovne elemente, ki niso
vsebovani v ključu, saj je s ključem določena lega zapisa v drevesu (in gozdu). Zapis se
doda tako, da se na določenem mestu vključi v enega izmed dreves oziroma poddreves.
Mesto vključevanja (poddrevo) je določeno s trenutnim tekočim zapisom ter tipom drevesa.
Za predstavitev nehierarhičnih struktur se uporablja koncept povezanih dreves, kjer se
povezujejo med seboj drevesa različnih fizičnih gozdov. Zapisi so povezani v fizično drevo s
pomočjo fizičnih kazalcev. Kazalci, ki povezujejo med seboj zapise različnih tipov, pripadajo
tipu otrok, kazalci, ki povezujejo med seboj zapise istih tipov, pa pripadajo tipu dvojček.
Drevesa različnih tipov se povezujejo med seboj s pomočjo kazalcev tipa logični otrok, tipa
logični dvojček in tipa logični starš. S povezanimi drevesi rešujemo problem zapisov, ki bi se
naj kot otroci nahajali v več gozdovih in s tem povzročali redundantne težave. Nad
povezanimi fizičnimi naslovi gozdov je možno definirati vrsto uporabniških pogledov –
logičnih gozdov.
Logični gozd lahko definiramo tudi s pomočjo inverzije dreves. Inverzija dreves temelji na
direktnem dostopu (sekundarni indeks) do zapisov določenega tipa, ki se v drevesih
fizičnega gozda nahajajo hierarhično pod korenom. Zapis z direktnim dostopom postane v
logičnem drevesu korenski zapis, ki vključuje tudi nadrejene zapise, hierarhija podrejenih
zapisov pa ostane nespremenjena.
Obnavljanje zbirke podatkov
Postopke, s katerimi se ohranja konsistentnost zbirke podatkov v primernih podatkovnih
nesreč, imenujemo obnavljanje. Izvaja jih SUZP pod nadzorom upravitelja zbirke podatkov.
Obnavljanje obsega pripravo podatkov za obnovitev, detekcijo podatkovne nesreče in
obnovitev zbirke podatkov v veljavno stanje pred nesrečo. Podatkovne nesreče se dele v
Zbirke podatkov 1
 13

transakcijske nesreče, ki jih odkrijejo uporabniški programi sami, transakcijske nesreče, ki jih
odkrijeta SUZP ali pa operacijski sistem, sistemske nesreče in diskovne nesreče. Prvi dve
vrsti nesreč sta lokalnega značaja, vplivata le na posamezno transakcijo, drugi dve vrsti pa
prizadeneta vse trenutno aktivne transakcije.
Množico ažuriranj, ki povzroče prehod zbirke podatkov iz enega veljavnega stanja v drugo,
imenujemo transakcija. Ažuriranja zbirke podatkov, ki sestavljajo transakcijo, se morajo
izvesti vsa ali pa niti eno. Transakcija se prične z operacijo Začetek transakcije, zaključi pa
se uspešno z ukazom Pomni, ali pa neuspešno z ukazom Pozabi. Transakcija v času
svojega obstoja prehaja iz ene faze v drugo in je v začetku aktivna transakcija, nato postane
uspešna ali ponesrečena transakcija, konča pa kot uspešno ali neuspešno zaključena
transakcija.
Podatki, ki jih obdeluje transakcijski program, se kot fizična zbirka podatkov nahajajo na
disku in kot delovni podatki v notranjem pomnilniku. Pomnilniški ukazi, ki jih v okviru
transakcij izvaja transakcijski program, so PoiščiPreberi, ki priredi delovni spremenljivki
vrednost podatka na disku, Spremeni, ki priredi podatku vrednost delovne spremenljivke,
Dodaj, ki na disk doda podatek z vrednostjo delovne spremenljivke, in Izbriši, ki iz diska
izbriše podatek. Omenjene ukaze podpirata operacija PreberiBlok, ki prenese fizični blok z
diska v datotečni vmesnik, in IzpišiBlok, ki prenese fizični blok iz vmesnika na disk.
Obnavljanje zbirke podatkov temelji na zapisovanju redundantnih podatkov, kot so dvojna
zbirka podatkov, kopija zbirke podatkov, ki omogoča obnovitev celotne zbirke podatkov,
vhodni transakcijski podatki, ki omogočajo ponovno izvajanje transakcij, stare vrednosti
podatkov pred ažuriranjem, ki omogočajo razveljavitev ažuriranj, in nove vrednosti podatkov
po ažuriranju, ki omogočajo uveljavitev ažuriranj. Vhodni transakcijski podatki ter stare in
nove vrednosti podatkov se beležijo v dnevnik.
Dvojna zbirka podatkov temelji na podvojenem zapisovanju fizične zbirke podatkov v dva
ločena diskovna pomnilnika. Zagotavlja dobro zaščito pred diskovnim nesrečami ter
neprekinjeno dostopnost zbirke podatkov, saj je v času obnavljanja ene kopije na voljo
druga.
Obnavljanje s senčnimi stranmi služi za obnovitev zbirke podatkov po transakcijskih
nesrečah. Temelji na zapisovanju ažuriranih fizičnih blokov na dotlej neuporabljen prostor na
disku, pri čemer se ohranjajo tudi prvotni fizični bloki. V primeru transakcijske nesreče
obsega zbirka podatkov prvotne bloke. Če se transakcija uspešno zaključi, pa se vanjo
vključijo namesto prvotnih ažurirani bloki.
Obnavljanje z dnevnikom in kopijo temelji na občasni izdelavi kopije zbirke podatkov, s
katero lahko zbirko podatkov v primeru diskovne nesreče obnovimo v takratno veljavno
stanje, ter pisanju dnevnika, v katerega se zapisujejo podatki, s katerimi je možno s kopijo
obnovljeno zbirko podatkov obnoviti v zadnje veljavno stanje tik pred podatkovno nesrečo.
Dnevnik pa lahko vsebuje tudi podatke, s katerimi je možno vse v trenutku nesreče
prekinjene transakcije ponovno izvesti. Pri odloženem ažuriranju se nove vrednosti
Beležke

Zbirke podatkov 1
14

podatkov shranijo najprej v dnevnik, po uspešnem zaključku transakcije pa se uveljavijo v

zbirki podatkov. Pri neposrednem ažuriranju se ažuriranje zbirke podatkov izvaja sproti, v
dnevnik pa se zapisujejo stare vrednosti podatkov. V primeru transakcijske nesreče se
ažuriranja v zbirki podatkov z njihovo pomočjo razveljavijo.
V okviru izvajanja kontrolne točke (pri uporabi neposrednega ažuriranja) se izvede izsiljeni
izpis datotečnih vmesnikov na disk in registriranje vseh trenutno aktivnih transakcij, s čimer
je v tem trenutku popolnoma definirano stanje fizične zbirke podatkov. V primeru sistemske
nesreče, se obnovitev zbirke podatkov omeji le na uveljavljanje oziroma razveljavljanje
transakcij, ki so bile aktivne ob času izvajanja kontrolne točke oziroma so se pričele izvajati
kasneje.
Nadzor nad sočasno uporabo zbirke podatkov
Izmenično izvajanje transakcijskih programov pod nadzorom večuporabniškega
operacijskega sistema povzroča posledično tudi izmenično izvajanje transakcij, ki
potencialno ogroža konsistentnost zbirke podatkov. Naloga nadzora nad sočasno uporabo
zbirke podatkov je ohraniti zbirko podatkov v konsistentnem stanju in zagotoviti
konsistentnost povpraševanj, pri tem pa dopustiti kar največjo sočasnost izvajanja transakcij.
Zaporedje izvajanja ukazov v okviru transakcij imenujemo razpored, ki je zaporeden, če se
pri sočasnem izvajanju transakcij izvedejo najprej vsi ukazi ene transakcije, nato vsi ukazi
druge transakcije in tako naprej, in je izmeničen, če se časovno med ukazi ene transakcije
izvedejo tudi ukazi drugih transakcij. Za zaporedni razpored velja, če vsaka izmed transakcij
ohranja konsistentnost zbirke podatkov, potem jo ohranja tudi vsak njihov zaporedni
razpored. Izmenični razpored transakcij, ki učinkuje na zbirko podatkov enako kot kakšen
izmed možnih zaporednih razporedov, imenujemo zaporedniški razpored. Če vsaka izmed
transakcij ohranja konsistentnost zbirke podatkov, potem jo ohranja tudi vsak njihov
zaporedniški razpored.
Zaporedniško izvajanje transakcij se lahko doseže z izvajanjem po protokolu, ki temelji na
zaseganju podatkov, ali protokolu, ki temelji na časovnih oznakah. Podatki, ki se v okviru
transakcije nameravajo uporabljati, se lahko zasežejo ekskluzivno, deljeno ali pa se sploh
ne zasežejo. Ekskluzivno zaseženi podatek ne more dodatno zaseči še kakšna druga
transakcija, deljeno zaseženi podatek pa se lahko še dodatno deljeno zaseže, ne more pa se
zaseči ekskluzivno. Protokol, ki temelji na ekskluzivnem in deljenem zaseganju s sprostitvijo
zaseženj ob zaključku transakcije, je protokol PSC. Ukazi za zaseganje podatkov lahko
nastopajo samostojno ali pa se povezujejo z ukazi za rokovanje s podatki. Pri protokolu PSC
obstaja razen standardnega ukaza za iskanje, tudi ukaz, ki podatek poišče in ga hkrati tudi
deljeno zaseže, vsi ažurirani ukazi pa vključujejo hkrati ekskluzivno zaseženje. Sprostitev
vseh zaseženj je vključena v ukaza Pomni in Pozabi, ki ju transakcija izda ob svojem
zaključku.
Objekti zaseženja so lahko logični ali fizični objekti. Logični objekti so v odvisnosti od vrste
podatkovnega modela relacije, n-terice v relacijah, seti določenega tipa, posamezni seti,
logične datoteke, posamezni logični zapisi, drevesa določenega tipa, posamezna drevesa,
poddrevesa, posamezna vozlišča v drevesih. Fizični objekti pa so lahko celotna fizična zbirka
podatkov, fizične datoteke, fizični bloki oziroma strani, fizični zapisi.
Če se transakciji zaseženje ne more pri priči odobriti, preide v stanje čakanja na odobritev, iz
česar izvirata dve nevarnosti. Posamezno transakcijo lahko pri odobritvi zaseženja
določenega podatka prehitevajo vse ostale transakcije in se s tem njeno čakanje raztegne na
nedoločen čas, kar se rešuje z ustreznim algoritmom dodeljevanja zaseženj, ki mora
upoštevati čas čakanja transakcij na odobritev zaseženj. Druga nevarnost je mrtva zanka, ki
nastopi v primeru, ko dve ali več transakcij čaka druga drugo na sprostitev podatkov.
Mrtvi zanki se lahko izognemo z urnikom izvajanja transakcij, z vnaprejšnjim zahtevami po
zaseženju podatkov, z ureditvijo objektov zaseženja in dopustitvijo zaseženj le v pravilnem
Zbirke podatkov 1
 15

zaporedju, s prepustitvijo odločitve čakati ali prekiniti transakcijo transakcijskemu programu

in s prekinitvijo transakcije, če z ozirom na izvedena zaseženja obstaja potencialna
nevarnost za nastop mrtve zanke. Če je protokol tak, da omogoča nastanek mrtve zanke, je
potrebno preverjati ali je le-ta nastopila, nato pa eno izmed transakcij v mrtvi zanki prekiniti.
Protokol, ki tudi preprečuje nastop mrtve zanke in ne uporablja zaseganja podatkov, je
časovno označevanje aktivnih transakcij in prebranih ali ažuriranih podatkov. Po tem
protokolu se transakcije izvajajo tako, da je njihov zaporedniški razpored ekvivalenten
zaporednemu razporedu, po katerem se starejša transakcija izvede pred mlajšo. Konfliktne
oziroma potencialno konfliktne zahteve po branju ali ažuriranju podatkov se razrešujejo s
prekinitvijo in ponovnim izvajanjem starejše transakcije.

Beležke

Zbirke podatkov 1
16

OSNOVE ZBIRK PODATKOV

Trajno hranjenje podatkov
Uporabniki zahtevajo različne informacije. Včasih za posredovanje odgovora zadoščajo le
vhodni podatki, včasih pa so potrebni tudi podatki, shranjeni na nekem trajnem nosilcu
podatkov.
Prvi primer:
Danes: Koliko je 53? Odgovor: 125.
3
Čez 14 dni: Koliko je 5 ? Odgovor: 125.

Trajno hranjenje podatkov v tem primeru ni potrebno!

Drugi primer:
Danes: Koliko (ne)opravičenih izostankov ima Jure? Odgovor: 2.
Čez 14 dni: Koliko (ne)opravičenih izostankov ima Jure? Odgovor: 17. (!!!)

V tem primeru se morajo podatki o izostankih dijaka hraniti trajno (ne le v času obdelave
podatkov).

Trajno hranjenje informacije ali podatka oziroma trajna informacija je informacija, katere
življenjski čas je daljši od življenjskega časa enega procesa (poenostavljeno gledano izvedbe
programa).
Implementacija trajnosti podatkov:
 klasični način - podatki se zapisujejo v binarne ali tekstovne datoteke,
 uporaba zbirke podatkov (ZP) in sistema za upravljanje s zbirko podatkov
(SUZP) - podatki se zapisujejo v zbirko podatkov, SUZP pa omogoča dostop do ZP
in varuje njeno vsebino.

Klasični načini implementacije trajnosti

Zbirke podatkov 1
 17

Na nivoju operacijskega sistema je datoteka le zaporedje zlogov. Iz navedenega dejstva

izhajajo naslednje posledice:
 Programi za obdelavo podatkov morajo poznati strukturo podatkov - struktura
podatkov je zapisana v kodi programa.
 Operacijski sistem ne pozna strukture datotek in zato ne more preprečiti morebitne
napake med podatki.
 Vse zaščite in druge omejitve morajo biti realizirane znotraj programa!
 Če več programov oziroma uporabnikov sočasno uporablja eno datoteko, je
potrebno programsko zagotoviti zaščito podatkov (in to v vseh programih, ki delajo
s podatki).

Aplikacija 1

Aplikacija 2 Operacijski sistem

Datoteke

Aplikacija n

Slabosti klasičnih sistemov

 Časovno požrešna metoda razvoja programske opreme (veliko programiranja).
 Ni podpore 'ad hoc' poizvedbam.
 Obstajajo izolirani ‘otoki’ informacij (primer: ločene datoteke po različnih oddelkih
podjetja).
 Obstaja močna odvisnost med podatki in programi (sprememba strukture datoteke
zahteva tudi spremembo vseh programov, ki jo uporabljajo).
 Obstaja možnost večkratnega zapisovanja istih podatkov. To je t.i. nenadzorovana
redundanca podatkov. Pri dodajanju, spreminjanju in brisanju podatkov pogosto
prihaja do anomalij med podatki.
 Zaradi pomanjkanje kontrole nad podatki lahko prihaja do nekonsistence
(neskladnosti) med podatki.
 Podatki, shranjeni s pomočjo ene aplikacije, ne morejo biti obdelani s strani druge
aplikacije (zaradi nekompatibilnosti formatov).

Beležke

Zbirke podatkov 1
18

Uporaba zbirke podatkov in SUZP-ja za implementacijo trajnosti

Če se odločimo za implementacijo trajnosti podatkov s pomočjo zbirke podatkov, potem
mora biti struktura shranjenih podatkov podana na način, ki ga SUZP razume. Primer:
Create Table "Dijak" (
"DijakID" Integer NOT NULL,
"Priimek" Char(20) NOT NULL,
"Ime" Char(10) NOT NULL,
"Razred" Char(3),
Primary Key ("DijakID") );

Aplikacija 1

Aplikacija 2 SUZP OS Zbirka

podatkov

Aplikacija n

Prednosti uporabe ZP
 SUZP sam odkriva in preprečuje napake.
 Programiranje se poenostavi in se prestavi na višji nivo abstrakcije.
 SUZP je vmesnik med operacijskim sistemom in aplikacijskimi programi oziroma
uporabniki.
 Koda SUZP-ja je testirana in dobro optimizirana.
 SUZP-ji imajo vgrajene rutine za razvrščanje in iskanje podatkov, za upravljanje z
izrabo datotečnih izravnalnikov (bufferjev), za shranjevanje datotek, statistične
funkcije, …
 SUZP je optimiziran za delo z velikimi količinami podatkov in podpira
večuporabniško okolje. Ima vgrajene varnostne funkcije, ki preprečujejo dostop do
podatkov nepooblaščenim osebam in tudi mehanizme, ki zagotavljajo zaščito
podatkov v primeru porušitve sistema ter obnavljanje sistema.
 ZP je dostopna le s pomočjo SUZP. Omogočeno je skrivanje ali prikrivanje internih
sprememb znotraj zbirke podatkov uporabnikom in uporabniškim programom.
Vodilo abstraktnih podatkovnih tipov je možnost implementacije sprememb na
nižjem nivoju in hkrati ohranjanje vmesnika proti višjem nivoju.

Razvoj podatkovnih sistemov

Obdobja
0. Obdobje pred pojavitvijo zbirk podatkov - čas datotek
 Časovno to obdobje sega do 60. let prejšnjega stoletja.

Zbirke podatkov 1
 19

 Datoteke omogočajo direktni dostop do podatkov in trajno hranjenje razmeroma

velikih količin podatkov.
 Aplikacijski sistemi so uporabljali ločene datoteke - vsaka datoteka je bila nek ločen
'podatkovni otok‘.
 Edini pogled na podatke je fizični pogled.
 Vse operacije nad podatki so prilagojene fizični predstavitvi podatkov.
 Obdobje zaznamuje rast števila aplikacij, s tem narašča tudi število deljenih datotek
in različnih formatov zapisa.
 Problematična postaja izmenjava podatkov med aplikacijami.
 Pojavljajo se večkratne kopije istih podatkov (redundanca). Podvajanje podatkov ni
nadzorovano!
 Podatki so postajali neskladni (nekonsistentni).
 Pomanjkljiva skrb za varnost podatkov, težavno sledenje dogodkov.
 Sistemi postajajo nefleksibilni.

1. Obdobje ZP - hierarhični in mrežni podatkovni model

 Obdobje se začne konec 60. let in predstavlja začetek komercialne uporabe ZP.
 Pojavljajo se in uvajajo mehanizmi za opis podatkov - podatkovni modeli:
► hierarhični podatkovni model in
► mrežni podatkovni model.
 V 70. letih sta ta dva modela predstavljala standard za uporabo ZP.
 Prvič se pojavlja delitev pogledov na podatke:
► fizični pogled in
► logični pogled.
 Lažje posodabljanje sistemov.
 Avtomatiziran je nadzor nad sočasnim dostopom do podatkov.
 SUZP-ji zagotavljajo možnost obnavljanja ZP.
 Beleženje dogodkov v sistemu postane avtomatizirano.

2. Obdobje ZP - relacijski podatkovni model

 Leta 1970 je Edgar F. 'Ted' Codd predstavi koncept relacijskega podatkovnega
modela.

Beležke

Zbirke podatkov 1
20

 Bistvo modela:
► ZP se uporabnikom predstavi kot množica podatkov, ki so organizirani v tabelah;
► uporabniki relacijskega sistema se ne obremenjujejo s strukturo shranjevanja;
► striktno ločevanje med logičnim in fizičnim pogledom na podatke.
 Za tabele Codd vpelje naziv relacija.
 Poizvedbe se podajo v visoko-nivojskih jezikih. S tem se doseže večja učinkovitost
programerjev.
 Posledica uvedbe relacijskega modela podatkov: razvili so zmogljiv deklarativni
jezik, namenjen delu s zbirko podatkov imenovan Structured Query Language.
 Glavni razvijalci sistemov za upravljanje z relacijsko ZP so podjetje IBM in različne
univerze.
 Komercialne uspešnice:
► INGRES, ki je bil razvit na University of California, Barkley,
► System R (ki je pozneje prerasel v DB2), razvit v IBM San Jose laboratorijih.
 V 80-ih letih relacijski model postane osrednji in najbolj razširjen model podatkov.
 Še danes (v poslovnem okolju) prevladujejo zbirke podatkov, ki temeljijo na
relacijskem modelu.
 80. leta zaznamuje razvoj porazdeljenih zbirk podatkov.

3. Obdobje - objektno relacijski in objektni podatkovni model

 Obdobje se začne na začetku 90. let.
 Dodana je podpora objektom - poleg podatkov v ZP hranimo tudi metode
(postopke) za delo s podatki.
 Uporaba novih modelov sega na specializirana področja, ki zahtevajo procesiranje
zelo kompleksnih podatkov.
 Aplikacije za delo z ZP so se razširile tudi na področje svetovnega spleta in e-
poslovanja.
 Uvajajo se novi standardi za beleženje podatkov, kot je to XML (eXtended Markup
Language). ML je le za nov način beleženja (zapisovanja) podatkov - to NI
podatkovni model!

Zbirke podatkov 1
 21

4. Obdobje - post-relacijski podatkovni sistemi

 Obdobje se začne konec 90. let in sega v današnje čase.
 Značilnost post-relacijskih podatkovnih sistemov je veliko novih funkcionalnosti, ki
segajo na področje:
► podatkovnega skladiščenja,
► OLAP sistemov (on-line analitical processing),
► podatkovnega rudarjenja,
► podpirajo kompleksnejše podatkovne tipe (temporal, prostorske podatke),
► pojavljajo se t.i. aktivne zbirke podatkov, ...

Prednosti in slabosti uporabe zbirk podatkov

Prednosti uporabe ZP
 Omogoča nadzorovano redundanco podatkov. Zato je vzdrževanje podatkov manj
naporno.
 Omogoča skupno rabo podatkov (načeloma) neomejenemu številu uporabnikov.
 Preprečuje nepooblaščen dostop do podatkov.
 V objektnih zbirkah omogoča hranjenje opisov podatkov in metod za delo s podatki
(objekti).
 Zagotavlja tako strukturo shranjevanja, ki omogoča učinkovito izvajanje poizvedb.
 Zagotavlja storitve arhiviranja in restavriranja podatkovnega sistema in podatkov.
 Omogoča večkratne uporabniške vmesnike (poglede) za dostop do podatkov.
 Vzdržuje kompleksne sisteme povezav med podatki.
 Vsiljuje izvajanje integritetnih omejitev nad podatki.
 Podpira in spodbuja uveljavljanje standardov v organizaciji. Standardi se lahko
nanašajo na imena podatkov, formate prikaza podatkov, strukture poročil, opise
podatkov in tudi na poslovna pravila organizacije.
 Skrajša čas razvoja in vzdrževanja aplikacij (posebej pri dodajanju novih modulov
ali funkcij programa).
 Zagotavlja fleksibilnost pri spreminjanju strukture podatkov.
 Zagotavlja dostop do 'svežih' trenutnih podatkov.

Beležke

Zbirke podatkov 1
22

 Lahko pomaga tudi pri iskanju in odpravljanju podvojenih virov v organizaciji. S tem
posredno pomaga tudi zmanjšanju stroškov organizacije.

Slabosti uporabe ZP
 Cena potrebne programske opreme. Sistemi za upravljanje zbirke podatkov, ki ne
sodijo med prosto dostopno programsko opremo, so praviloma dragi. Pri prosto
dostopnih SUZP-jih pa moramo natančno prebrati licenčne pogoje.
 Odvisnost od proizvajalca/dobavitelja SUZP-ja.
 Zahteva čas za učenje in privajanje na sistem.
 Šibke točke SUZP-ja (lahko) vplivajo na šibkost ZP (optimizacija kode, varnost).
 Računalniški sistem, na katerem bo nameščen SUZP, mora biti zmogljivejši.
Praviloma se uporabljajo večprocesorski sistemi, ki imajo veliko RAM-a in zelo hitre
trde diske.

Zbirka podatkov
Opredelitev termina Zbirka podatkov
Zbirka podatkov je osnova, na kateri temelji celotno delovanje organizacije.
Uspešnost delovanja organizacije je odvisna od znanja, znanje pridobimo iz informacij,
informacije pridobimo iz podatkov, podatke pa hranimo v ZP (‘neskončna zanka’).
Poenostavljeno gledano je zbirka podatkov zelo velika shramba prej vnesenih podatkov, ki
zadošča določenim pogojem
Pogoji zagotavljajo celovitost podatkov in učinkovitost delovanja. Tako zbirka podatkov
prispeva k uspešnejšem delu uporabnikov.

Definicije zbirke podatkov

 Zbirka podatkov je zbirka povezanih podatkov. Podatki so dejstva, so shranjena na
nekem računalniškem trajnem pomnilniku, ki se jim lahko pripiše pomen (ki
implicitno imajo pomen). (Elmasri and Navathe)
 Zbirka podatkov je upravljana zbirka povezanih podatkov, shranjena na
računalniškem sistemu, deljena med več uporabniki, zaščitena z varnostnimi
mehanizmi in shranjena z nadzorovano redundantnostjo. (Stamper and Price)
 Zbirka podatkov je organizirana zbirka logično povezanih podatkov in opisov le teh,
načrtovana tako, da zadovoljuje informacijske potrebe organizacije. (Connolly and
Begg)
Zbirke podatkov 1
 23

Podatkovni sistem
Podatkovni sistem je računalniško podprt sistem, ki s pomočjo sistema za upravljanje zbirke
podatkov omogoča uporabo in upravljanje s podatki, ki so shranjeni v zbirki podatkov.
Da bi podatkovni sistem deloval, so potrebni:
 strojna in komunikacijska oprema,
 programska oprema: operacijski sistem, sistem za upravljanje zbirke podatkov,
uporabniške aplikacije,
 zbirka podatkov, ki jo sestavljata opisi podatkov (meta podatki oziroma opisi
podatkov) in fizični podatki (vrednosti podatkovnih elementov),
 administrator ZP,
 uporabniki ZP.

Uporabniške
aplikacije
Administrator ZP

Sistem za
Upravljanje
Zbirke
Podatkov

Uporabniki ZP Operacijski Sistem

Zbirka Podatkov
Sheme ZP Stanje ZP
(opisi ZP) (fizični podatki)

Shematski prikaz podatkovnega sistema

Beležke

Zbirke podatkov 1
24

Stanje zbirke podatkov

Stanje ZP je predstavljeno z množico podatkov, ki so trenutno shranjeni v ZP.
Najpogostejša operacija nad podatki je branje podatkov (v jeziku SQL je to stavek SELECT).
Branje podatkov ne spremeni stanja zbirke podatkov.
Vse ostale osnovne operacije spremenijo stanje ZP. To so operacije:
 dodajanja novih podatkov (SQL stavek INSERT),
 spreminjanja podatkov (SQL stavek UPDATE),
 brisanja podatkov (SQL stavek DELETE).

ZP ZP

ZP

Stanje ZP pred in po izvedbi stavka SELECT

ZP ZP

ZP

Stanje ZP pred in po izvedbi stavka INSERT

Zbirke podatkov 1
 25

Strukturiranost podatkov
Podatki v ZP so strukturirani. To pomeni, da ustrezajo vnaprej opredeljeni strukturi.
Strukturiranost podatkov omogoča kompleksnejša vrednotenja stanja zbirke podatkov.
Premislek: Kaj bi se zgodilo, če imamo v ZP zapisane le stavke v naravnem jeziku (tekst)?
Podatkovni sistemi, ki več vedo o podatkih, ponujajo uporabnikom boljše storitve in s tem
bolje podpirajo delo uporabnikov.
Shema zbirke podatkov
Shema ZP je formalna definicija strukture vsebine zbirke podatkov in opredeli vsa možna
stanja zbirke podatkov. Definirana je le enkrat in sicer pri kreiranju ZP.
Sprememba sheme že kreirane ZP včasih povzroča težave. Zato je pomembno dobro in
temeljito načrtovanje sheme zbirke podatkov. Pozneje bo potrebno narediti manj sprememb
sheme ZP in upravitelj zbirke podatkov bo imel manj težav.
Kot sinonim za shemo zbirke podatkov se uporablja izraz metazbirka podatkov (to so
podatki o podatkih).
Poenostavljena primerjava z višjimi programskimi jeziki: shema zbirke ustreza deklaraciji
strukture, stanje zbirke pa ustreza trenutni vrednosti spremenljivke.

Primerjava stanja s shemo zbirke podatkov

Povzetek
 Zbirka podatkov je zbirka logično povezanih podatkov.
 Za delovanje ZP potrebujemo:
► podatkovni del ZP (podatke + opise podatkov),
► programsko opremo (SUZP),
► kadre: administratorja (upravitelja) ZP in uporabnike.
 Prednosti uporabe ZP
► Podvajanje podatkov je nadzorovano.

Beležke

Zbirke podatkov 1
26

► Večja varnost podatkov.

► Boljša celovitost podatkov (pravilnost, preverjanje vhodnih podatkov).
► Centraliziran nadzor nad podatki (avtomatično zaklepanje, preverjanje upr. pravic,
sledenje dogodkov).
► Podatki so neodvisni od aplikacij.
 Stanje ZP je množica vrednosti podatkov zapisanih v ZP. Stanje ZP se pogosto
spreminja.
 Shema ZP je opis strukture podatkov. Naredi se ob kreiranju ZP in se redko
spreminja. Če pride do spremembe sheme ZP, le ta pogosto povzroča težave pri
uporabi podatkov.
Podatkovni model
Uporaba modela omogoča preučevanje realnega sveta. Uporaba modelov je cenejša od
praktičnih eksperimentov. Model poudarja le določen pogled na realni svet. Predstavitev
modela se izvede s pomočjo dobro formaliziranega jezika.
Modele uporabljajo osebe različnih poklicev, vendar morajo imeti skupno predznanje.
Primer (ne)razumevanja modela:
Na mizi je geografska karta Slovenije. Pride Janezek in komentira: 'Cesta, ki
pelje skozi naš kraj ni rdeča in tudi sredi potoka ni nobene črtkaste črte, ki bi
označevala meje med Slovenijo in Hrvaško!!!!'
Definicija: Podatkovni model je povezana zbirka konceptov namenjenih opisovanju in
manipulaciji s podatki.
Podatkovni model opredeljuje sintakso in semantiko stavkov formalnega jezika, ki
omogočajo:
 definiranje sheme zbirke podatkov (DDL - Data Definition Language omogoča
opredeljevanje podatkovnih struktur in integritetnih omejitev),
 poizvedovanje po trenutnem stanju zbirke podatkov (poizvedovalni jezik QL - Query
Language, ki je del Data Manipulation Language),
 izvajanje operacij ažuriranja podatkov in s tem spreminjanje stanja zbirke podatkov
(stavki jezika DML: INSERT, DELETE, UPDATE).

ZP

ZP

ZP

Postopek izdelave in uporabe podatkovnega modela

Pri podatkovnem modeliranju se izvaja abstrakcija in poenostavitev nekega segmenta

realnega sveta. Načrtovalec se usmeri na elemente, bistvene za uporabnike modela. Na
osnovi modela se izdela zbirka podatkov.

Zbirke podatkov 1
 27

Podatkovni modeli v praksi

Danes so v uporabi:
 relacijski,
 entitetno-relacijski,
 objektno-relacijski in
 objektni podatkovni model.
Starejša modela iz 70-ih let, ki postopoma izginevata iz prakse sta:
 hierarhični,
 mrežni podatkovni model.
Sistem za Upravljanje Zbirke podatkov (SUZP)
SUZP predstavlja programsko opremo, nujno potrebno za delo z ZP. V literaturi se uporablja
kratica DBMS (DataBase Management System).
Osnovne naloge SUZP so:
 omogoča kreiranje ZP,
 zagotavlja dostop do ZP,
 skrbi za veljavnost stanja ZP,
 preprečuje nenadzorovano redundanco podatkov.
Redundantnost podatkov
Redundanca pomeni podvajanje. Redundanca podatkov pomeni, da so isti podatki shranjeni
večkrat. Nenadzorovana redundanca je nezaželen pojav. Neželene posledice
nenadzorovane redundance podatkov so:
 podvoji se potreba po vnosu in ažuriranju podatkov,
 prej ali slej nekateri uporabniki pozabijo spremeniti (posodobiti) eno od kopij
podatka - zato podatki postanejo nekonsistentni (neskladni, nasprotujoči si),
 pretirana poraba trajnega pomnilnika, tudi arhivske kopije so pretirano velike.

Beležke

Zbirke podatkov 1
28

Zbirka podatkov - vprašanja

Kaj je zbirka podatkov?
Množica podatkov.

Množica informacij.

Urejena zbirka logično povezanih podatkov.

Zbirka datotek, v katerih se nahajajo podatki.

Katera od navedenih lastnosti NE velja za sisteme, ki temeljijo na uporabi ZP?

Skromnost glede potrebne strojne
opreme
Nadzorovano podvajanja podatkov.

Izboljšana kakovost podatkov.

Manjša potreba po vzdrževanju aplikacij.

Dostop do podatkov v zbirki podatkov omogoča in nadzoruje:

upravitelj zbirke podatkov

uporabniška aplikacija.

operacijski sistem.

SUZP.

Zbirke podatkov 1
 29

Podvojeno shranjevanje podatkov v ZP

je dovoljeno, lahko je nenadzorovano.

je dovoljeno, vendar mora biti nadzorovano.

ni dovoljeno.

lahko je dovoljeno ali nedovoljeno, odvisno od odločitve programerjev.

Programsko orodje, ki omogoča kreiranje in vzdrževanje zbirke podatkov ter dostop do

podatkov je
orodje za računalniško podprto programsko inženirstvo (CASE).

prevajalnik.

sistem za upravljanje s zbirko podatkov.

uporabniška aplikacija.

operacijski sistem.

Zbirka podatkov je vir podatkov in informacij, ki jih uporabniki uporabljajo pri odločanju.
DA

NE

Prvi SUZP so bili uvedeni v 80-ih letih prejšnjega stoletja.

DA

NE

Uporaba zbirke podatkov omogoča lažji razvoj in vzdrževanje uporabniških aplikacij.

DA

Beležke

Zbirke podatkov 1
30

NE

Sočasnost dostopov do zbirke podatkov omogoča in nadzoruje upravitelj zbirke podatkov.

DA

NE

Zbirke podatkov 1
 31

Za veljavnost (legalnost) stanja zbirke podatkov skrbi SUZP.

DA

NE

Shema zbirke podatkov opredeljuje veljavna stanja zbirke podatkov.

DA

NE

Arhitektura ZP in podatkovna neodvisnost

Arhitektura ZP
Trinivojska arhitektura zbirke podatkov
Drugo ime za trinivojsko arhitekturo je ANSI/SPARC arhitektura. Leta 1975. jo je razvil
Standards Planning and Requirements Commitee (SPARC) American National Standards
Institute (ANSI). Opredeljuje 3 nivoje opisov ZP:
 zunanji nivo (opredeljuje različne poglede uporabnikov na podatke),
 konceptualni nivo (celovit pregled vseh vrst podatkov in povezav med podatki v
ZP),
 fizični nivo (opredeljuje fizični način shranjevanja in dostope do podatkov).
Zelo poenostavljeno: zunanji nivo opisuje uporabo podatkov, konceptualni pomen podatkov,
notranji pa način shranjevanja podatkov. Opis posameznega nivoja se imenuje shema zbirke
podatkov.

Beležke

Zbirke podatkov 1
32

ZP

Shematski prikaz ANSI/SPARC arhitekture zbirke podatkov

Opisi posameznih nivojev

Zunanji nivo
 Predstavlja različne poglede uporabnikov na ZP.
 Vsak pogled je ena zunanja shema.
 Ena shema opisuje podatke, zanimive za posameznega uporabnika.
 Pogledi so prilagojeni potrebam posameznega uporabnika.
 Za različne uporabnike obstajajo različne sheme za prikaz istih podatkov.
 Zunanji pogledi (pogosto) prikazujejo izračunane podatke.
 Pomagajo pri zagotavljanju varnosti - uporabnik vidi le omejeno množico podatkov.
 Število zunanjih shem je (teoretično) neomejeno.

Konceptualni nivo
 Vsebuje celovito informacijo o vsebini in strukturi zbirke podatkov.
 Opisani so podatki in povezave med podatki v ZP.
 Konceptualna shema vsebuje le logične podatke o ZP.
 Vsaka ZP ima le 1 konceptualno shemo.
 Konceptualna shema:
► odraža potrebe uporabnikov,
► je popolnoma neodvisna od SUZP-ja in strojne opreme.
Opomba: Vsaka izmed zunanjih shem sloni na enem delu konceptualne sheme. Zato vsi
podatki, ki jih prikažemo na zunanjem nivoju, morajo biti zajeti ali izpeljani iz podatkov,
opisanih na konceptualnem nivoju.

Zbirke podatkov 1
 33

Notranji nivo
 Opisuje fizično predstavitev ZP v računalniku.
 Opisuje KAKO so podatki shranjeni v ZP, opisi zajemajo:
► podatkovne strukture
► datotečne organizacije,
► indekse, ...
Kakovost notranje sheme določa performanse ZP in optimalnost izrabe prostora na disku!
Notranja shema je odvisna od SUZP-ja!
Opomba: Pod notranjim nivojem obstaja še fizični nivo, s katerim upravlja OS na osnovi
navodil, ki jih dobi od SUZP-ja. Ločitev funkcij med SUZP-jem in OS na fizičnem nivoju ni
striktno določena in se med sistemi zelo razlikuje.
Preslikave med shemami ZP
Preslikave izvaja SUZP. SUZP preverja tudi skladnost med nivoji.
Samodejno izvajanje preslikav s strani SUZP-ja zagotavlja neodvisnost med posameznimi
nivoji opisov ZP!

Beležke

Zbirke podatkov 1
34

Trinivojska arhitektura ZP v praksi (MS Access)

Podatkovna neodvisnost
Podatek je sam po sebi neodvisen resurs (načeloma neodvisen od programov oz. aplikacij,
ki ga uporabljajo). Ena od glavnih pridobitev uporabe zbirk podatkov in SUZP-jev =
neodvisnost aplikacij od podatkov!

SUZP

ZP ZP

P
odatkovna neodvisnost

Podatkovna neodvisnost (na splošno) pomeni imunost oz. odpornost višjega nivoja na
spremembe, ki se zgodijo na nižjem nivoju opisov ZP. Obstajata 2 vrsti podatkovne
neodvisnosti:

Zbirke podatkov 1
 35

 fizična,
 logična.
Fizična podatkovna neodvisnost
Predstavlja neodvisnost konceptualne sheme od sprememb v notranji shemi. Programi ne
smejo biti odvisni od načinov shranjevanja podatkov in obratno: strukturo podatkovne
datoteke ne sme narekovati aplikacijski program.
Fizična podatkovna neodvisnost zmanjšuje potrebo po vzdrževanju:
 programov,
 konceptualnega modela ZP.
Logična podatkovna neodvisnost
Zagotavlja neodvisnost zunanjih shem od sprememb v konceptualni shemi. Omogoča
spreminjanje konceptualne sheme, ne da bi pri tem morali nujno spremeniti tudi zunanje
sheme.
Uporaba:
 Logična podatkovna neodvisnost zagotavlja starim aplikacijskim programom
neodvisnost od novo-dodanih podatkov, ki jih ti programi ne potrebujejo.
 Logično podatkovno neodvisnost lahko uporabimo tudi pri integraciji prej
razdeljenih / različnih zbirk podatkov.

Beležke

Zbirke podatkov 1
36

Arhitektura - vprašanja
Podvojeno shranjevanje podatkov v ZP
je dovoljeno, lahko je nenadzorovano.

je dovoljeno, vendar mora biti nadzorovano.

ni dovoljeno.

je dovoljeno ali nedovoljeno, odvisno od odločitve upravitelja ZP.

Namen trinivojske arhitekture ZP je

poenostaviti strukturo zbirke.

zagotoviti podatkovno neodvisnost.

poenotiti strukturo zbirke.

zagotoviti neodvisnost uporabnikov od upravitelja ZP.

zagotoviti neodvisnost uporabnikov od uporabniških aplikacij.

Podatkovno neodvisnost zagotavlja

upravitelj zbirke podatkov.

uporabniška aplikacija.

SQL.

sistem za upravljanje zbirke podatkov.

Konceptualna shema (opis podatkov na konceptualnem nivoju) prikazuje ZP kot

zbirko fizičnih zapisov.

zbirko logičnih zapisov in njihovih povezav.

zbirko entitet in povezave (razmerja) med entitetami.

zbirko vseh uporabniških pogledov na podatke.

Zbirke podatkov 1
 37

Podatkovna neodvisnost zagotavlja

neodvisnost aplikacij od načina hranjenja in dostopa do podatkov v ZP.

neodvisnost SUZP-ja od operacijskega sistema.

neodvisnost uporabnikov od uporabniških aplikacij.

neodvisnost programerjev od upravitelja ZP.

neodvisnost uporabnikov od dodeljenih pravic.

Podatkovna neodvisnost pomeni, da je predstavitev podatkov na zunanjem nivoju neodvisna

od potreb uporabnikov.
DA

NE

Uporabniški pogled na podatke (zunanji nivo) je prilagojen potrebam uporabnikov..

DA

NE

Za opisovanje zbirke podatkov uporabljamo višje programske jezike.

DA

NE

V metazbirki podatkov so zajeti vsi opisi zbirke podatkov.

DA

NE

Beležke

Zbirke podatkov 1
38

Posledica spreminjanja konceptualnega nivoja so obvezno tudi spremembe na notranjem

nivoju.
DA

NE

Fizična podatkovna neodvisnost je mera za vpliv sprememb s konceptualnega na notranji

nivo opisov zbirke podatkov.
DA

NE

Preslikave med posameznimi nivoji opisov podatkov izvajajo uporabniške aplikacije.

DA

NE

Jeziki in prihodnost zbirk podatkov

SQL - jezik za delo s zbirko podatkov
Značilnosti naravnega jezika so neformalnost ali šibka formalizacija. Stavki v naravnem
jeziku so velikokrat dvoumni. Zato ni primeren za delo z računalnikom ali zbirko podatkov.
Za delo z ZP najbolj razširjen jezik SQL (Structured Query Language).
SQL je programski jezik, ki v svoji osnovni inačici nima nekaterih klasičnih programskih
konstruktov (vejitev, zanka).
SQL je deklarativni jezik, namenjen manipulaciji s podatki.
V SQL-u povemo le KAJ želimo, NE pa tudi KAKO naj se to izvede.
Opomba: Obstajajo tudi izvedenke SQL-a, denimo PL/SQL, PSQL,TSQL ki zadoščajo vsem
kriterijem programskega jezika (imajo krmilne stavke, zanke, …).

Delitev stavkov jezika SQL

 stavki SQL DDL (Data Definition Language) - omogočajo kreiranje in spreminjanje
opisov podatkov,
 stavki SQL DML (Data Manipulation Language) - omogočajo branje, vnos,
spreminjanje in brisanje fizičnih podatkov.
Deklarativni poizvedovalni jeziki dovoljujejo in potrebujejo močne optimizatorje poizvedb, ki
so sestavni deli SUZP-jev! Uporaba deklarativnih jezikov omogoča večjo neodvisnost od
tehnologij strojne in programske opreme.

Zbirke podatkov 1
 39

Trenutno sta v uporabi sta naslednja standarda SQL:

 SQL 92,
 SQL 3.

Kdaj uporabiti/ne uporabiti ZP?

Zbirko podatkov je smiselno uporabiti, ko Zbirke podatkov ni smiselno uporabiti, če
se zahteva:
Trajno hranjenje podatkov So začetni stroški investicije v strojno in
programsko opremo in v izobraževanje osebja
Centraliziran nadzor nad podatki
previsoki
Nadzor redundance
Nadzor nad konsistentnostjo in integriteto Se ne zahtevajo funkcionalnosti, ki jih ponujajo
podatkov SUZP
Večuporabniška podpora So aplikacije in podatki preprosti in stabilni
Deljenje podatkov ZP ne bi mogla zadostiti zahtevam po delu v
realnem času
Dokumentacija podatkov
Podatkovna neodvisnost Se ne zahteva več uporabniška podpora
Nadzor dostopa in varnost
Možnost arhiviranja in restavriranja
podatkovnega sistema

Prihodnost ZP je zagotovljena!
Razširitve in razvoj v smeri podpore odločanju:
 Podatkovno skladiščenje (data warehousing),
 OLAP sistemi (on-line analytical processing),
 Podatkovno rudarjenje (Data Mining).
Razširitve in razvoj v smeri drugačnih zvrsti podatkov:
 Iskalni stroji (Search Engine),
 Prostorske zbirke (Spatial databases),
 Tekstovne in multimedijske zbirke,
 ...

Beležke

Zbirke podatkov 1
40

SUZP - sistem za upravljanje zbirke podatkov

Opredelitev pojma SUZP
Sistem za upravljanje zbirke podatkov (Database Management System)
SUZP je programski sistem, ki zagotavlja učinkovito, uporabnikom prijazno in varno
večuporabniško okolje namenjeno shranjevanju, dostopanju in vzdrževanju velikih količin
medsebojno povezanih podatkov, shranjenih na trajnem pomnilniku. Je od aplikacij
neodvisna programska oprema, s pomočjo katere je implementiran podatkovni model.
SUZP omogoča:
 definiranje sheme zbirke podatkov in shranjevanje sheme na zunanjem pomnilniku,
 shranjevanje stanja zbirke podatkov,
 poizvedovanje po trenutnem stanju zbirke podatkov,
 spreminjanje stanja zbirke podatkov.

ZP

SUZP

ZP

Mesto SUZP v podatkovnem sistemu

Definicije SUZP:
SUZP je programska oprema, ki uporabnikom omogoča definiranje, kreiranje in
vzdrževanje ZP in hkrati zagotavlja nadzorovan dostop do ZP.
SUZP je programska oprema, ki ravna z vsemi dostopi do podatkov v ZP in je odgovorna za
izvajanje postopkov preverjanja avtorizacij uporabnikov in veljavnosti podatkov.
SUZP je zbirka programov, ki:
 omogoča kreiranje nove ZP in definiranje njene strukture,
 omogoča učinkovito poizvedovanje in spreminjanje podatkov,
 varuje podatke pred nesrečami in neavtoriziranimi dostopi,
 nadzoruje sočasen dostop večjega števila uporabnikov do podatkov.
Arhitektura SUZP
Arhitektura SUZP je dokaj kompleksna. V osnovi je sestavljen in štirih osnovnih modulov:
Zbirke podatkov 1
 41

1. Uporabniški vmesnik - namenjen upravitelju ZP, sofisticiranim uporabnikom, ...; lahko je

tekstovni ali grafični.
2. Procesor poizvedb (query processor), ki ima naslednje podmodule:
 DML prevajalnik (DML compiler),
 vgrajen DML predprevajalnik (Embedded DML precompiler): DML stavke, vgrajene
v aplikacijske programe, prevede v običajne klice procedur gostiteljskega jezika,
 DDL interpreter, ki pretvori DDL stavke v množico tabel z metapodatki (opisi
podatkov); tabele se shranijo v podatkovnem slovarju,
 modul za ovrednotenje poizvedb (Query evaluation engine) ki prevede (in
optimizira) stavke poizvedovalnega jezika v nizkonivojske instrukcije, ki jih razume
upravitelj shranjevanja.
3. Upravitelj transakcij (transactions manager) - njegova naloga je, da zaklepa, beleži in
izvaja transakcije.
4. Upravitelj shranjevanja (storage manager), ki ima naslednje podmodule:
 upravitelj avtorizacij in celovitosti (authorization and integrity manager) - nadzoruje
dostope in celovitost podatkov,
 upravitelj datotek (file manager) - dostopa do datotek na disku
 upravitelj izravnalnika (buffer manager) - prepisuje bloke podatkov med trdim
diskom in RAM pomnilnikom.

Beležke

Zbirke podatkov 1
42

SUZP

ZP ZP

Moduli SUZP

Arhitektura SUZP-ja - uporabniški vmesnik

SUZP ima uporabniški vmesnik, ki omogoča komunikacijo med uporabniki SUZP-ja in samim
programom.
Večina (današnjih) SUZP-jev ima grafične uporabniške vmesnike. Le ti so uporabnikom
prijazni in enostavni za uporabo. Še vedno obstajajo sistemi (predvsem prostodostopni
SUZP-ji), ki imajo v osnovi le tekstovne vmesnike.

Arhitektura SUZP-ja - procesor poizvedb

Osnovna naloga je procesorja poizvedb:
 prevzem poizvedb, ki jih načeloma dobi v obliki stavkov SQL in
 prevajanje le teh v zaporedje zahtevkov po podatkih.
Velikokrat je najzahtevnejši del procesiranja optimizacija poizvedb. Opomba: izdelava dobre
poizvedovalne strategije je ključnega pomena za učinkovitost sistema.

Arhitektura SUZP-ja - upravitelj transakcij

SUZP zagotavlja ACID lastnost vsake transakcije.
ACID = Atomicity (atomarnost) + Consistency (konsistentnost) + Isolation (samostojnost/
izolacija/neodvisnost) + Durability (trajnost)
Atomarnost pomeni, da
 se ena transakcija mora izvesti do konca ali pa v celoti zavrniti;
 je treba opraviti bodisi vse zahtevane spremembe ali pa nobene.

Zbirke podatkov 1
 43

Postopek zagotavljanja atomarnosti transakcij:

 beleži se 'log' oz. zgodovina vseh izvedenih akcij;
 pred izvedbo katerekoli sprememba v ZP mora biti ustrezen log zapis shranjen na
varnem mestu. V primeru nesreče je enostavno razveljaviti učinek le delno
izvedene transakcije.
Konsistentnost
 Transakcija transformira stanje zbirke podatkov iz enega veljavnega stanja v drugo
veljavno stanje. Transakcija je veljavna / legalna le, če upošteva vse integritetne
omejitve zbirke podatkov. Če stanje po izvedbi transakcije ni več veljavno, se
transakcija zavrne v celoti (vrnemo se v prejšnje veljavno stanje zbirke podatkov).
Izolacija
 Rezultat izvedbe transakcije je drugim transakcija prikrit, dokler se transakcija ne
izvede do konca.
Trajnost
 Rezultati uspešno izvedene transakcije so trajno shranjeni in dostopni tudi, če se
takoj po izvedbi transakcije sistem poruši

Arhitektura SUZP-ja - upravitelj shranjevanja

Upravitelj izravnalnika (buffer manager)
 ravna s prostorom v glavnem pomnilniku,
 s pomočjo upravitelja datotek pridobiva bloke podatkov z diska in izbira stran v
glavnem pomnilniku, v katero se podatki prepišejo,
 algoritem ostranjevanja določa, koliko časa bo posamezna stran (blok podatkov)
ostala v pomnilniku.
Upravitelj datotek (file manager)
 beleži lokacije datotek na disku in na zahtevo upravitelja izravnalnika pridobiva blok
ali bloke podatkov iz datoteke. Opomba: področje diska je največkrat razdeljeno na
bloke neprekinjenega prostora velikost med 212 in 214 zlogov (od 4K do 16KB).

Beležke

Zbirke podatkov 1
44

Funkcije SUZP
SUZP izvaja vrsto funkcij. Glavne funkcije SUZP so:

Omogoča definiranje in spreminjanje opisa ZP ter kreiranje ZP

 Integrirani SQL DDL interpreter omogoča administratorju ZP opisovanje in
spreminjanje opisov zbirke podatkov.
 Na osnovi opisov SUZP tudi kreira ZP.

Manipuliranje s podatki
 Omogoča uporabnikom in uporabniškim aplikacijam izvedbo osnovnih operacij nad
podatki: branje, spreminjanje, dodajanje in brisanje podatkov.

Izvajanje transakcij
 Transakcija je zaporedje ukazov zbirke podatkov, ki se izvede kot ena celota
(atomarna enota) po principu 'vse ali nič'.
 Transakcija se mora izvesti do konca ali pa se sploh ne sme izvesti.
 V primeru porušitve sistema pred koncem izvedbe transakcije SUZP zagotovi, da
se ob naslednjem zagonu SUZP-ja obnovi sistem (podatki) v prejšnje stanje - to je
da se vse spremembe prekličejo ('zavrtijo nazaj' / 'rolled back'.
 Če se pa sistem poruši po izvedbi transakcije (stanje = izvršeno / committed),
SUZP zagotavlja, da so vse spremembe shranjene v zbirki podatkov.

Zaščita podatkov
 Vgrajeni varnostni mehanizmi, ki omogočajo nastavljanje (dodeljevanje) različnih
dostopnih pravic uporabnikom do različnih podatkov in tudi skrbi za delovanje /
upoštevanje teh pravic.

Sledenje dogodkov
 SUZP beleži vse dogodke / dostope do podatkov v zbirki podatkov, izdela pregled
in statistiko dostopov.

Zagotavljanje integritete podatkov

 Pred izvedbo kakršne koli spremembe podatkov SUZP (pred dodajanjem,
brisanjem ali spreminjanjem) preveri vrednosti novih podatkov glede na domeno
(veljavno zalogo vrednosti) podatka in glede na omejitve, ki so opredeljene glede
na povezave z drugimi podatki.
 S tem SUZP preprečuje kršenje določenih poslovnih pravil.

Vzdrževanje podatkovnega slovarja

 Informacije od podatkih (denimo notranja shema, seznam uporabnikov, dostopne
pravice, omejitve) hrani v sistemskih tabelah.

Zagotavlja podatkovno neodvisnost

 Ena od najpomembnejših funkcij SUZP-ja.
 S tem je zagotovljena neodvisnost aplikacij od načina hranjenja in načina dostopa
do podatkov.

Nudi podporo arhiviranju in restavriranju sistema

Zbirke podatkov 1
 45

Spremlja delovanje ZP - izvaja nadzor performans

Proizvajalci SUZP
Vse proizvajalce SUZP v grobem delimo na 'veliko trojico' in 'ostali svet'.
Velika trojica Ostali svet
Oracle Sysbase
IBM DB2 NCR Teradata
Microsoft SQL Server MySQL
PostgreSQL
Firebird
Microsoft Access
Paradox
Skupna lastnost vseh (sodobnih) sistemov je, da podpirajo bodisi relacijski ali pa objektno-
relacijski podatkovni model.
Razlikujejo pa se po:
 kategoriji programske opreme (licenčna, prostodostopna, odprtokodna),
 ceni,
 zmogljivosti,
 funkcijah,
 hitrosti, platformah (Windows / UNIX / ...),
 različni podpori razvijalcem,
 obsegu in kakovosti dokumentacije, ...
Proizvodnja in vzdrževanje SUZP-jev je tudi ekonomsko gledano velik 'posel'. Leta 2004 je
zabeležena 12% rast svetovnega trga SUZP-jev.

Beležke

Zbirke podatkov 1
46

Tržni delež proizvajalcev SUZP-jev leta 2004

Glavni proizvajalci SUZP leta 2004

Kriteriji za izbiro SUZP

1. Cena in pogoji (omejitve) licenc
 Pri nabavi SUZP-ja ne upoštevamo le nabavne cene za licenco, temveč tudi vseh
stroškov, ki jih bomo imeli z lastništvom in uporabo izbranega SUZP-ja (TCO = total
cost of ownership).
 Nekaj (pomembnejših) parametrov, ki naj bi jih upoštevali pri izračunu TCO:
► ceno, ki jo plačamo za produkcijski strežnik ZP (znesek za CPU licence, za
uporabniške licence, za pomožna orodja ‘tuning',diagnosticiranje),
► ceno, ki jo plačamo za rezervni strežnik ZP (t.i. Failover Database Server),
► ceno za SW storitve (nadgradnje, telefonska podpora),
► ceno licenc za razvijalce (začetna cena, cena za letno podaljšanje licence).
 TCO izračunamo vsaj za obdobje 3 - 4 let.

2. Dostopnost SUZP-ja za različne platforme strojne opreme.

3. Performanse in skalabilnost.

4. Dostopnost razvojnih orodij.

5. Količina časa, ki bo potrebna za administracijo sistema.

6. Zanesljivost, tehnična podpora 7 x 24 x 365, kakovost podpore arhiviranju in

restavriranju sistema, čas, potreben za restavriranje sistema.

7. Znanje ljudi.

8. Podpora varnosti:
 verjetnost, da obstajajo hrošči, ki omogočijo hackerjem vdor v sistem,

Zbirke podatkov 1
 47

 hitrost reševanja varnostnih težav,

 kako dobro in hitro je administrator ZP informiran o varnostnih težavah,
 enostavnost / kompleksnost postopka vzdrževanja sistema (krpanja lukenj).

9. Podpora jeziku SQL

 Preverimo, kateri SQL standard podpira SUZP. Danes je minimalna zahteva, da
SUZP podpira SQL-92 standard. Če uporabimo SUZP, ki ne podpira standardov,
bo prehod na nek nov sistem zelo drag.
Značilnosti uporabe SUZP
Prednosti uporabe SUZP Slabosti uporabe SUZP

Nadzorovano podvajanje podatkov. Kompleksnost.

Konsistentnost podatkov. Cena SUZP.

Iz istih podatkov lahko pridobimo več

Zahteva zmogljivo strojno opremo.
informacij.

Dajanje podatkov v skupno rabo. Cena prehoda z enega sistema na drugi.

Potreba po dodatnem izobraževanju kadrov

Izboljšana integriteta podatkov.
(še posebej tehničnega osebja).

Izboljšana varnost podatkov. Odvisnost od proizvajalca SUZP.

Uvedba standardov.

Večja dostopnost podatkov.

Večja učinkovitost podatkovnega

sistema.

Lažje arhiviranje in restavriranje

podatkov.

Lažje vzdrževanje aplikacij.

Najpomembnejše pridobitve uporabe SUZP so:

 podatkovna neodvisnost,

Beležke

Zbirke podatkov 1
48

 učinkovit dostop do podatkov,

 zmanjšanje časa, potrebnega za razvoj aplikacij,
 enotna, centralizirana administracija podatkov,
 zagotovljena integriteta in varnost podatkov,
 zagotovljen nadzor nad sočasnim dostopom do podatkov,
 enostavno obnavljanja po nesrečah,
 nadzorovano (morebitno) podvajanje podatkov,
 ...

SUZP - vprašanja
Kateri modul SUZP-ja interpretira stavke SQL DDL?
Procesor poizvedb

Upravitelj transakcij.

Upravitelj izravnalnika.

Upravitelj datotek.

Katera od navedenih značilnosti ne sodi med pridobitve uporabe SUZP-ja?

Krajši čas za razvoj aplikacij.

Prepovedano podvajanje podatkov.

Zagotovljena integriteta podatkov.

Zagotovljena točnost podatkov.

Zagotovljena podatkovna neodvisnost.

Zbirke podatkov 1
 49

Pri nabavi SUZP-ja upoštevamo samo

ceno licence za uporabnike.

ceno licence za razvijalce.

zmogljivost SUZP.

TCO.

primerjalne analize proizvajalca SUZP-ja.

Pravilo atomarnosti transakcij ('vse ali nič') zagotavlja porabnik

da se vsako opravilo opravi do konca.

da se izvajajo le elementarni (atomarni) procesi.

obnovo podatkov v primeru nesreče med izvedbo transakcije.

dostop do vseh ali nobenega atomarnega podatka.

da do podatkov lahko dostopajo bodisi vsi ali noben uporabnik.

Dostop do podatkov v ZP omogoča in nadzoruje

SUZP.

upravitelj zbirke podatkov.

uporabniška aplikacija.

operacijski sistem.

Beležke

Zbirke podatkov 1
50

Kateri od navedenih programov sodijo med SUZP-je?

MySQL.

Java.

DB2.

MS SQL Server.

SQL.

Oracle.

SUZP omogoča izdelavo arhivskih kopij, vendar preprečuje kakršno koli drugo podvajanje
podatkov.
DA

NE

Operacije branja in zapisovanja podatkov v ZP izvaja SQL.

DA

NE

SUZP ima vgrajen interpreter za jezik SQL DDL.

DA

NE

Pri obnavljanju ZP po nesrečah se uporabljajo 'log' datoteke.

DA

NE

Sočasnost dostopov od ZP omogoča SUZP.

DA

NE

Uporabniki ZP in orodja
Glavne skupine uporabnikov ZP:

Zbirke podatkov 1
 51

ZP

SUZP

Zbirka
podatkov

Uporabniki ZP in načini dostopa do ZP

Administrator (skrbnik) ZP (DataBase Administrator)

 Pozna celotno shemo (opis) zbirke podatkov.
 Po potrebi izvaja spremembe sheme in le te dokumentira.
 Administrator ZP je tudi odgovoren za fizično realizacijo ZP vključno z fizičnim
načrtom in implementacijo.
 Definira sheme (pri tem uporablja SQL Data Definition Language). Primer SQL DDL
stavka, ki kreira tabelo Dijak (ZP je mySQL):

Beležke

Zbirke podatkov 1
52

Create table Dijak (

DijakID Char(7) NOT NULL,
Priimek Char(20) NOT NULL,
Ime Char(10) NOT NULL,
Datum_rojstva Datetime ,
UNIQUE (DijakID),
Primary Key (DijakID)
) TYPE = MyISAM
ROW_FORMAT = Default;
 Definira strukturo shranjevanja in pristopnih metod.
 Modificira sheme in fizično organizacijo.
 Koordinira in nadzoruje uporabo ZP.
 Daje dostopne pravice uporabnikom, zagotavlja varnost sistema. Osnovne
dostopne pravice so: 1. brez pravic, 2. pravica branja podatkov, 3. pravica
dodajanja podatkov, 4. pravica spreminjanja podatkov, 5. pravica brisanja
podatkov, 6. pravica kreiranja novih in izločanja obstoječih tipov podatkov. Primer
SQL DDL stavka, ki uporabnikom dodeli dostopne pravice do tabele Dijak:
/* Users permissions */
Grant select on Dijak to Misko;
Grant select on Dijak to Miki;
Grant update on Dijak to Miki;
Grant delete on Dijak to Miki;
Grant insert on Dijak to Miki;
Grant references on Dijak to Miki;
 Opazuje performanse podatkovnega sistema, % zasedenosti diskov, po potrebi
izvaja fino nastavljanje sistema.
 Skrbi za izdelavo arhivskih kopij podatkov; v primeru porušitve sistema opravi
restavriranje sistema
 Sledi razvoj SUZP-jev; inštalira nove verzije SUZP-ja.
 Je odgovoren za uporabo licenčne programske opreme (SUZP-ja in ostalih orodij).
 Sodeluje s proizvajalcem SUZP-ja, ga obvešča o težavah in prosi za podporo.
 Na uspešnost dela administratorja ZP vpliva njegovo poznavanje vseh
funkcionalnosti, podrobnosti in specifičnih lastnosti izbranega SUZP-ja.
 Je strokovnjak na področju sistemov za upravljanje zbirk podatkov.
 Ima največja pooblastila in hkrati največjo odgovornost, temu skladno tudi dobro
plačo.
 Uporablja: SUZP in orodja CASE.
Administrator (skrbnik) podatkov (Data Administrator)
 Odgovoren je za upravljanje s podatkovnimi resursi podjetja.

Zbirke podatkov 1
 53

 Načrtuje ZP, razvija in vzdržuje standarde, politiko in postopke, ki se nanašajo na

podatke, konceptualno in logično načrtovanje ZP.
 Uporablja orodja CASE.
Primerjava nalog administratorja ZP (DBA) in administratorja podatkov (DA):
DA DBA

Nivo Strateško planiranje Operativni in taktični nadzor

Cilji Postavlja dolgoročne cilje Izvaja načrt za dosego ciljev
Delo Postavlja politike in Uveljavlja politiko in standarde
standarde glede podatkov v praksi
Doseg dela Širok doseg – nivo podjetja Ožji doseg – nivo ZP

Čas Dolgoročnost Kratkoročnost (usmerjenost na

dnevna opravila)
Usmeritev Managerska usmeritev Tehnična usmeritev
Povezava s SUZP-jem Neodvisen Odvisen in tesno povezan s
SUZP-jem

Načrtovalec ZP
 Definira vsebino in strukturo zbirke podatkov.
 Opredeli omejitve in funkcije zbirke podatkov.
 Komunicira s končnimi uporabniki.
 Poglobljeno pozna potrebe uporabnikov.
 Uporablja orodja CASE.

Beležke

Zbirke podatkov 1
54

Aplikacijski programer
 Piše programe – uporabniške aplikacije za (največkrat) naivne uporabnike.
 Včasih izdeluje tudi spletne vmesnike.
 Pozna in uporablja:
► (vsaj en) programski jezik iz 3. ali 4. generacije programskih jezikov(C++, Java,
PHP, …),
► jezik SQL,
► razvojna orodja (RAD) in
► semantiko sheme zbirke podatkov.
Del programa, ki se nanaša na delo z ZP, je (načeloma) napisan v DML jeziku (kliče
izvajanje DML stavkov). Temu pravimo, da so DML stavki vgrajeni (embedded) v kodo, ki je
napisana v jeziku gostitelja (host language).
Programer ima pravico vpogleda v shemo zbirke podatkov, vendar NIKOLI nima pravice
spreminjanja sheme!
 Primer vključevanja SQL DML stavka v pascalski (Delphi) program
// sestavljamo poizvedbo (query)
Query1.Sql.Clear;
Query1.Sql.Add('Select * from Kandidat');
Query1.Sql.Add('Where Priimek=:p');
Query1.ParamByName('p').Value:=Edit1.Text;
// zahtevano izvajanje poizvedbe
Query1.Open;
// prikaz podatkov
DataSource1.DataSet:=Query1;
 Primer vključevanja SQL DML stavka v ASP program (skripto)
<%
dim con
‘odpremo povezavo z ZP
set con=Server.CreateObject("ADODB.connection")
con.open("Avto")
dim rs
‘sestavimo in poženemo ppoizvedbo
set rs=con.execute("Select * from Vozilo")
‘prikažemo rezultate
response.write rs.fields("ID_vozila") & " "
response.write rs.fields("Znamka") & "<br>"
%>

Zbirke podatkov 1
 55

Končni uporabniki – naivni uporabniki

 Do ZP dostopajo izključno s pomočjo aplikacijskih programov
 Nič ne vedo, s čem delajo (ali gre za ZP ali datoteke).
 Glavna naloge naivnih uporabnikov:
► vnos in morebitno popravljanje vnesenih podatkov,
► skrb za točnost podatkov,
► uporaba poizvedb in standardnih poročil, ki so implementirana v aplikacijah (npr.:
pregled prodaje za pretekli mesec, stanje zalog, bilanca).

Končni uporabniki – sofisticirani uporabniki

 Izvajajo nestandardne ('ad hoc') poizvedbe nad podati. To so poizvedbe, ki niso
implementirane v uporabniških aplikacijah.
 Značilna delovna mesta sofisticiranih uporabnikov so:
► planske in analitske službe,
► direktorski položaji na srednjem nivoju managementa, ki potrebujejo nekatere
agregate podatkov kot osnovno za sprejemanje odločitev.
 Sofisticirani uporabniki morajo poznati strukturo ZP in zmožnosti, ki jih ponuja
SUZP.
 Pri svojem delu uporabljajo SQL in / ali poizvedovalna grafična orodja.
Orodja za delo z ZP
To so orodja, ki omogočajo in / ali olajšajo delo z ZP. Boljši SUZP imajo tovrstna orodja že
vgrajena (vdelana). Uporabljajo jih predvsem skrbniki zbirke podatkov, skrbniki podatkov,
načrtovalci, programerji pa tudi sofisticirani uporabniki.
Vrste pomožne programske opreme:
 orodja za načrtovanje ZP (CASE orodja),
 interaktivni SQL interpreterji (CuteSQL),
 grafična poizvedovalna orodja,
 vmesniki za dostop do zbirke podatkov iz standardnih višjih programskih jezikov
(BDE, ODBC, JDBC, …),
 orodja za izdelavo okenskih aplikacij za uporabo zbirk podatkov (4GL),
 generatorji poročil,
 generatorji spletnega vmesnika za dostop do podatkov (spletnih strani),
Beležke

Zbirke podatkov 1
56

 orodja za uvažanje ali izvažanje podatkov v druge formate,

 orodja za izdelavo arhivskih kopij in obnovo sistema,
 orodja za izdelavo replik podatkov (repliciranje pomeni nadzorovano podvajanje
podatkov),
 orodja za nadzor performans,
 orodja za analizo učinkovitosti zbirke podatkov, …

DB Designer - prostodostopno orodje za načrtovanje MySQL ZP

Zbirke podatkov 1
 57

Uporabniki ZP - vprašanja
Pravica kreiranja in spreminjanja shem (opisov podatkov) je namenjena
končnim uporabnikom

programerjem

upravitelju ZP

upravitelju ZP in vodjem projektov

upravitelju ZP in programerjem

Za točnost (pravilnost) podatkov v zbirki podatkov je odgovoren

programer aplikacije

administrator ZP

SUZP

administrator podatkov

končni uporabnik

Integritetne omejitve, ki se nanašajo na podatke nastavi

naivni uporabnik.

administrator zbirke podatkov.

programer.

sofisticirani uporabniki.

SUZP.

Beležke

Zbirke podatkov 1
58

Uporabnik, ki mora dobro poznati in razumeti delovanje sistema za upravljanje zbirke

podatkov je
sofisticirani uporabnik.

aplikacijski programer.

administrator podatkov.

administrator zbirke podatkov.

Aplikacijski programerji pri svojem delu praviloma uporabljajo jezike?

višje programske jezike (denimo C++).

nižje programske jezike.

jezik SQL DDL.

jezik SQL DML.

skriptne jezike (denimo PHP).

Od aplikacijski programerjev se zahteva dobro poznavanje jezika SQL DDL.

DA

NE

Posodobitve sistema za upravljanje s zbirko podatkov opravlja administrator zbirke podatkov.

DA

NE

Upravljanje z opisi podatkov sodi med najpomembnejša opravila naivnih in sofisticiranih

uporabnikov.
DA

NE

Zbirke podatkov 1
 59

Za razvoj uporabniških aplikacij programerji uporabljajo kombinacijo jezika SQL in nekega

višjega programskega jezika.
DA

NE

Naivni uporabniki morajo poznati konceptualno shemo zbirke podatkov.

DA

NE

Razvoj aplikacij za delo z ZP

Aplikacije 'odjemalec - strežnik'
Porazdeljeno procesiranje pomeni, da se podatki v ZP procesirajo na neodvisnih
računalnikih, ki so povezani s strežnikom. Pozor: porazdeljeno procesiranje NE POMENI, da
so porazdeljeni tudi podatki (da se uporablja porazdeljena ZP!).

Aplikacije ‘odjemalec - strežnik‘ (client - server)

 Odjemalec (client)
► je enouporabniška delovna postaja, na kateri se izvaja primeren uporabniški
vmesnik (praviloma GUI - Graphical User Interface);
► zagotavlja predstavitev podatkov, njihovo obdelavo, povezovanje in storitve zbirke
podatkov.
 Strežnik (server)
► en ali več večuporabniških računalnikov z deljenim (shared) spominom, ki
omogočajo obdelavo, povezovanje, storitve zbirke in primeren vmesnik.

Beležke

Zbirke podatkov 1
60

Značilnosti aplikacij 'odjemalec-strežnik'

 Delitev procesiranja in podatkov med enim ali več odjemalčevimi računalniki, ki
izvajajo aplikacijo, in strežnikom, ki nudi storitve vsakemu izmed odjemalcev.
 Računalniki so med seboj povezani v omrežje.
 Okolje je heterogeno - strojna in programska oprema (operacijski sistem)
odjemalca in strežnika sta lahko različni.
 Komunikacija poteka s pomočjo dobro definiranega niza standardnih aplikacijskih
programskih vmesnikov (API - Application Programming Interface) in klicev
oddaljenih procedur (RPC - Remote Procedure Call).
Razvoj arhitekture aplikacij 'odjemalec - strežnik'
Enonivojska arhitektura (datotečni strežnik)
Pri enonivojski arhitekturi aplikacij se uporablja t.i. datotečni strežnik. Datotečni strežnik ima
nameščene le datoteke, ki tvorijo ZP in dostopa do le-teh s pomočjo operacijskega sistema.
Vsi programski moduli potrebni za dostop do podatkov (SUZP in uporabniške aplikacije) so
nameščeni na strani odjemalca.

SUZP

SUZP

Datotečni strežnik (1-tier architecture)

Zbirke podatkov 1
 61

Naloge, ki jih opravlja odjemalec Naloge, ki jih opravlja strežnik

Izvaja uporabniški vmesnik. Shranjuje datoteke.

Izvaja procesiranje podatkov. Zaklepa zapise.

Izvaja poizvedbe. Za odjemalca igra vlogo'dodatnega diska'.

Skrbi za integriteto in varnost podatkov. Malo zaposlen.

Potek komunikacije med odjemalcem in strežnikom

Značilnosti uporabe datotečnega strežnika:

 Celotno procesiranje se izvaja na strani računalnika, ki zahteva podatke (‘fat
client').
► Aplikacija in podatki so tesno povezani.
► Vse akcije se izvajajo znotraj ene aplikacije.
 Za potrebe obdelave se od strežnika do odjemalca prenašajo celotne datoteke.
 Problemi:
► prenos velikih količin podatkov po omrežju, posledično tudi veliko prometa v
omrežju,
► zahteva zmogljivo strojno opremo na strani odjemalca,
► odjemalčev SUZP mora poznati zaklepanje zapisov, preverjanje integritete,
► zahtevno nameščanje in vzdrževanje aplikacij.

Dvonivojska arhitektura
Pri dvonivojski arhitekturi aplikacij pride do ločevanja programskih modulov. Program, ki
omogoča in nadzoruje dostop do ZP je nameščen na podatkovnem strežniku, pri odjemalcih
pa so nameščene le uporabniške aplikacije.

Beležke

Zbirke podatkov 1
62

SUZP

ZP

ZP

Dvonivojska arhitektura (2-tier arhitecture)

Naloge, ki jih opravlja odjemalec (1.

Naloge, ki jih opravlja strežnik (2.nivo)
nivo)

Izvaja uporabniški vmesnik. Opravlja shranjevanje podatkov.

Zahteva podatke. Izvaja shranjene procedure.

Izvaja procesiranje podatkov. Zagotavlja zaklepanje zapisov.

Skrbi za integriteto in varnost podatkov.

Značilnosti dvonivojske arhitekture:
 Zbirki podatkov je dodan strežniški in odjemalčev modul.
 Odjemalec je odgovoren za logiko I/O procesiranja in za logiko nekaterih poslovnih
pravil.
 Strežnik je odgovoren za vse funkcije shranjevanja in dostopa do podatkov.
 SUZP je nameščen le na strani strežnika.
 Prednosti dvonivojske arhitekture:
► odjemalčeve postaje so lahko manj zmogljive,
► manj prometa poteka po omrežju,
► izboljšana je integriteta podatkov (centralizacija nadzora),
► shranjene procedure omogočajo, da se nekatera poslovna pravila izvajajo na
strežniku.

Trinivojska arhitektura
Pri trinivojski arhitekturi se pojavi dodatni t.i. aplikacijski strežnik, na katerem je nameščena
uporabniška aplikacija. To povzroči dodatno razbremenitev odjemalčevega sistema.

Zbirke podatkov 1
 63

SUZP

ZP

ZP

Trinivojska arhitektura (3-tier arhitecture)

Naloge, ki jih izvaja odjemalec (1. nivo):

 izvaja uporabniški vmesnik,
 zahteva podatke.
Naloge, ki jih izvaja aplikacijski strežnik (2. nivo):
 izvaja poslovna pravila,
 izvaja procesiranje.
Naloge, ki jih izvaja podatkovni strežnik (3. nivo):
 shranjuje podatke,
 izvaja shranjene procedure,
 zaklepa zapise,
 skrbi za integriteto in varnost podatkov.

Beležke

Zbirke podatkov 1
64

Potek komunikacije med odjemalcem, aplikacijski in podatkovnim strežnikom

Značilnosti trinivojske arhitekture

 Odjemalčeva aplikacija izvaja malo ali nič procesiranja.
 Aplikacijski strežnik izvaja celotno procesiranje in uporabo poslovne logike.
 Strežnik ZP izvaja preverjanja veljavnosti podatkov in nadzor nad vsemi dostopi do
podatkov.

Prednosti in slabosti 3-nivojske arhitekture

 Prednosti
► Skalabilnost - Lahko imamo več aplikacijskih strežnikov (št. aktivnih apl. strežnikov
se lahko dinamično uravnava (Transaction Processing monitor ali Object Request
Broker). Dostop do ZP zahteva le povezavo z aplikacijskim strežnikom, zato je lažja
zamenjava oz. nadgradnja posameznih ključnih komponent sistema.
► Večja možnost za ponovno uporabo istih programskih komponent. Če se
uporabljajo standardi (COM/DCOM ali CORBA), so značilnosti programskega
jezika, v katerem je implementiran 2. nivo, transparentne.
► Boljša integriteta podatkov - Vse spremembe podatkov potekajo skozi 2. nivo, le ta
pa zagotavlja in prepušča le veljavne / dovoljene spremembe (odpravljeno tveganje,
da ‘marsovske' ali 'padalske' odjemalčeve aplikacije poškodujejo podatke).
► Boljša varnost podatkov - Število varnostnih nivojev je povečano (+1 na
aplikacijskem nivoju).
Zmanjšana potreba po redistribuciji aplikacij - spremembe poslovnih pravil
posodobimo le na aplikacijskih strežnikih, odpade potreba po redistribuciji aplikacij
odjemalcem.
► Izboljšana razpoložljivost - lahko imamo podvojene aplikacijske in/ali podatkovne
strežnike (manjša verjetnost, da bo vse odpovedalo naenkrat).
 Slabosti
► Večja kompleksnost in več napora pri izdelavi aplikacij. Potrebna je dvojna
komunikacija: z odjemalcem in s podatkovnim strežnikom.
► Manj programskih razvojnih orodij - na trgu je (zaenkrat) veliko več razvojnih orodij
za izdelavo 2-nivojskih aplikacij.

Zbirke podatkov 1
 65

N-nivojska arhitektura
Večina današnjih spletnih aplikacij sloni na uporabi n-nivojske arhitekture aplikacij 'odjemalec
- strežnik'. Poleg podatkovnega in aplikacijskega strežnika ta arhitektura vključuje še spletni
strežnik. Tako je odjemalčev sistem maksimalno razbremenjen. N-nivojska arhitektura je
omogočila silovit razvoj mobilnega poslovanja.

SUZP

ZP

ZP

N-nivojska (n-tier) arhitektura

Glavni problem delovanja v omrežnem okolju je visoka stopnja ranljivosti sistema. Zato je
potrebno zagotoviti kompleksno (večnivojsko) varovanje. Varnostni nivoji in načini varovanja:
 omrežni nivo: za dostop se uporablja uporabniško ime in geslo;
 aplikacijski nivo: uporabljajo se varnostni mehanizmi, vgrajeni v aplikacijo;
 nivo podatkovnega strežnika: za vsakega uporabnika ali skupino uporabnikov
kreirajo njihove ‘vloge' in se jim dodelijo ustrezna dovoljenja za dostop do podatkov,
 varna komunikacija med odjemalcem in strežnikom (uporaba enkripcije /
dekripcije podatkov, certifikatov).

Beležke

Zbirke podatkov 1
66

Kdaj je primerno uporabiti 3 ali n-nivojsko arhitekturo aplikacij 'odjemalec-strežnik'?

 Če imamo veliko aplikacijskih storitev.
 Če so aplikacije napisane v različnih jezikih / s strani različnih organizacij.
 Če podatke črpamo iz dveh ali več heterogenih podatkovnih virov (različni SUZP-je
ali SUZP-ji + datotečni strežniki).
 Če je predvidena življenjska doba aplikacije daljša od treh let (še posebej, če
pričakujemo veliko sprememb ali dopolnitev aplikacije).
 Če pričakujemo veliko količino prometa (denimo, več kot 50000 dnevnih transakcij
ali več kot 300 sočasnih uporabnikov na istem sistemu, ki dostopajo do iste ZP).
 Če pričakujemo veliko komunikacij med aplikacijami (denimo pri elektronski
izmenjavi podatkov - Electronic Data Interchange).
Prednosti arhitekture 'odjemalec-strežnik'
 Medsebojna povezljivost (interoperability) - ključne komponente delujejo
neodvisno po skupnem protokolu.
 Skalabilnost (scalability) - vsako od ključnih komponent lahko zamenjamo, brez
večjih sprememb drugod.
 Prilagodljivost (adaptability) - enostavno vključevanje novih tehnologij.
 Podatkovna integriteta (data integrity) - vzdržuje se le na podatkovnem strežniku,
zato je vzdrževanje enostavno.
 Dosegljivost (accessability) - podatki so enostavno dosegljivi s pomočjo omrežja in
aplikacij odjemalca.
 Učinkovitost (performance) - učinkovitost se lahko optimizira s optimizacijo strojne
opreme in procesov.
 Redundančnost (redundancy) - z vgradnjo redundančnih komponent lahko
omogočimo delovanje sistema, kljub izpadu določenih komponent.

Razvoj aplikacij - vprašanja

Aplikacije za delo z ZP izvajajo neko kombinacijo naslednjih osnovnih operacij:
kreiranje, branje in kopiranje podatkov.

branje, spreminjanje in brisanje podatkov

kreiranje, spreminjanje in tiskanje podatkov.

branje, tiskanje in kopiranje podatkov.

Zbirke podatkov 1
 67

Katera od navedenih zahtev ne predstavlja težavo za uporabo datotečnih strežnikov?

Velika obremenjenost omrežja.

Zmogljiv odjemalčev računalnik.

Zmogljiv strežniški računalnik.

Odjemalčeve aplikacije morajo upravljati z integriteto podatkov.

V 3-nivojski arhitekturi aplikacij 'odjemalec-strežnik' preverjanje integritete podatkov in skrb

za zaklepanje zapisov izvaja:
datotečni strežnik.

podatkovni strežnik

aplikacijski strežnik.

odjemalec.

Z razvojem arhitekture aplikacij 'odjemalec/strežnik' so se naloge odjemalca

bistveno povečale.

rahlo povečale.

ostale nespremenjene.

rahlo zmanjšale.

bistveno zmanjšale.

Beležke

Zbirke podatkov 1
68

3- nivojska arhitektura C/S aplikacij dovoljuje podvajanje (več odgovorov):

podatkovnih strežnikov.

aplikacijskih strežnikov.

odjemalčevih postaj.

transakcij.

3-nivojska arhitektura aplikacij 'odjemalec/strežnik' je primerna predvsem za (več

odgovorov):
manjša podjetja (do 5 ljudi).

aplikacije, ki se dinamično posodabljajo.

homogene ZP.

aplikacije namenjene osebni uporabi.

aplikacije, ki zahtevajo izmenjavo velikih količin podatkov.

V prvem (začetnem) obdobju aplikacij 'odjemalec/strežnik' se je večina procesiranja

podatkov izvajala na odjemalčevem sistemu.
DA

NE

V trinivojski arhitekturi aplikacij 'odjemalec/strežnik' tretji nivo vedno pripada aplikacijskemu

strežniku.
DA

NE

Odjemalcu, na katerem je shranjenih veliko podatkov, pravimo 'debeli' (fat) odjemalec.

DA

NE

Zbirke podatkov 1
 69

N-nivojska arhitektura aplikacij 'odjemalec/strežnik' zahteva zmogljive uporabniške

računalnike.
DA

NE

S povečanjem števila nivojev aplikacij 'odjemalec/strežnik' se je povečala tudi kompleksnost

izdelave aplikacij.
DA

NE

Skalabilnost pri N-nivojski arhitekturi pomeni, da lahko neposredno z odjemalčeve postaje

dostopamo do podatkov v ZP.
DA

NE

S povečanjem števila nivojev arhitekture aplikacij 'odjemalec/strežnik' se je poenostavil

postopek vzdrževanja aplikacij.
DA

NE

Beležke

Zbirke podatkov 1
70

KONCEPTUALNO MODELIRANJE

Oblikovanje konceptualnega modela

Načrtovanje zbirke podatkov
Splošni cilj razvijalcev IS je razvoj aplikacij, ki bodo podpirale dana opravila v realnem svetu.
Načrtovanje zbirke podatkov je postopek opredelitve in razvoja strukture ZP.
V času načrtovanja zbirke podatkov naredimo formalni model nekaterih aspektov (vidikov)
realnega sveta – to je 'mini-sveta' ali 'problemske domene‘
Mera za pravilnost načrtovane sheme ZP je realni svet. Od tod sledi, da mora vsebina ZP
odražati podatke, pravila in izjeme iz realnega sveta.
Postopek načrtovanja in izdelave zbirke podatkov poteka po fazah.

Postopek izdelave ZP

Problemi načrtovanja ZP
Pri načrtovanju zbirke podatkov se razvijalci soočajo z vrsto težav:
 Nepoznavanje področja
► Načrtovalec problemskega področja načeloma ne pozna. Zato se mora najprej
seznaniti in potem podrobno spoznati domeno problema in bodoče aplikacije.

Zbirke podatkov 1
 71

 Pravila in izjeme
► Poleg pravil v realnem svetu obstaja tudi veliko izjem. Realni svet in njegovo okolje
sta dinamična sistema, ki se pogosto spreminjata. Načrtovalec pri svojem delu mora
upoštevati vsa pravila in tudi vse izjeme. Hkrati mora narediti sistem dovolj
fleksibilno shemo, ki bo prilagojena bodočim spremembam.
 Velikost
► Načrti ZP so pogosto zelo kompleksni. Zato so za človeka (načrtovalca) težko
obvladljivi.

Ključ uspeha je v sodelovanju z uporabniki!

Pri sodelovanju morajo načrtovalci ZP in uporabniki govoriti 'isti' jezik, sicer pride do večjih
razhajanj med dejanskimi in realiziranimi nalogami.

Primer težav pri komunikaciji med načrtovalci in uporabniki

Beležke

Zbirke podatkov 1
72

Postopek izdelave ZP
Postopek izdelave ZP poteka po naslednjih fazah:
 zbiranje in analiza zahtev uporabnikov,
 konceptualno načrtovanje,
 izbira SUZP,
 logično načrtovanje,
 fizično načrtovanje,
 implementacija ZP.

Izbira
SUZP-ja

Odvisno od SUZP-ja

Faze izdelave ZP

Opis faz izdelave ZP

1. Zbiranje in analiza zahtev
V tej fazi načrtovalci spoznavajo segment realnega sveta ('mini svet‘), ki ga bodo predstavil z
modelom.
Morajo dojeti in razumeti:
 katere podatke je potrebno hraniti v ZP,
 kako so podatki povezani,
 katere operacije se izvajajo nad podatki in
 kako bodo uporabniki uporabljali ZP.

Zbirke podatkov 1
 73

V začetni fazi lahko pride do napačnega razumevanja realnega sveta, zato zahteva temeljito
sodelovanje načrtovalcev z uporabniki.

2. Konceptualno načrtovanje
Cilj te faze je izdelati konceptualni načrt oz. konceptualno shemo ZP. Konceptualni načrt
zajema tudi omejitve, ki se nanašajo na podatke. Za predstavitev konceptualnega načrta se
uporabljajo:
 entitetno - relacijski diagrami,
 diagrami razredov (UML notacija) in
 diagrami objekt-vloga (Object-role model).

3. Izbira SUZP-ja (vodja projekta + uporabniki)

Izbiro ciljnega sistema za upravljanje ZP izvede vodja projekta v sodelovanju z vodjo
naročnikov projekta (uporabnikov).

4. Logično načrtovanje
Izvede se transformacija: konceptualne sheme v podatkovni model, ki ga podpira izbrani
SUZP. Opravi se tudi natančen pregled dobljene logične sheme, iščejo se morebitne napake
ali pomanjkljivosti modela.
Pred prehodom v naslednjo fazo je potrebno preveriti, ali je ZP normalizirana (preverimo
funkcionalne odvisnosti med atributi, ali obstaja nepotrebno podvajanje podatkov, ...).

5. Fizično načrtovanje zbirke podatkov

Cilj te faze je izboljšanje performans končnega sistema. Določijo se indeksi in parametri
shranjevanja zbirke podatkov. Identificirajo se različne skupine uporabnikov in preverja
ustreznost performans ZP glede na potrebe in zahteve uporabnikov.
Cilji konceptualnega modela
 Konceptualni model je izhodišče za razvoj podatkovnega sistema.

Beležke

Zbirke podatkov 1
74

 Omogoča in olajša komunikacijo načrtovalcev z naročniki in vodstvom projekta.

 Konceptualni model predstavlja tudi dokumentacijo projekta.
 Zagotavlja boljšo kakovost končnega izdelka (podatkovnega sistema).
 Z modularnostjo omogoča lažje obvladovanje kompleksnih primerov iz realnega
sveta.
Opomba: Med najbolj uporabljane modele za izdelavo konceptualnega modela zagotovo sodi
entitetno relacijski (E-R) model.

CASE orodja, ki se uporabljajo za izdelavo konceptualnega modela:

 CaseStudio
 ERWin (Computer Associates)
 Oracle Designer
 DeZign for Databases
 MS Visio
 DB Designer
 ...

Oblikovanje - vprašanja
Zbirka konceptov, ki se uporablja pri opisu strukture zbirke podatkov je
SUZP.

podatkovni model.

podatek.

relacija.

Kako se imenujejo orodja, ki jih uporabljamo za izdelavo konceptualnega modela?

Prevajalniki.

Interpreterji.

CASE orodja.

HTML urejevalniki

Zbirke podatkov 1
 75

Katera od navedenih faz načrtovanja ZP je neodvisna od bodočega SUZP, ki bo upravljal z

ZP?
Faza konceptualnega načrtovanja.

Faza logičnega načrtovanja.

Faza fizičnega načrtovanja.

Vse faze so odvisne od bodočega SUZP.

Konceptualni model NE uporabljamo

za optimizacijo performanz ZP.

za dokumentiranje ZP.

za nazorno predstavitev opisa ZP.

kot izhodišče za izdelavo logičnega načrta ZP.

Pri izdelavi konceptualnega modela je potrebno sodelovanje z uporabniki.

DA

NE

Beležke

Zbirke podatkov 1
76

Model E-R
Značilnosti modela E-R
 Avtor je Peter Pin-Shan Chen (l. 1976).
 Za E-R model je značilna semantična usmerjenost - usmerjen v pomensko
predstavitev realnega sveta. Za predstavitev se uporablja izrazna grafična notacija,
kar omogoča boljši pregled nad strukturo podatkov. Preslikava med realnim svetom
in podatkovnim modelom je nazorna. Zato omogoča dobro komunikacijo z
uporabniki, ki jih lažje jih vključimo v proces izdelave in validacije načrta zbirke
podatkov.
Osnovni konstrukti modela E-R
Med osnovne konstrukte modela E-R štejemo:
 entiteto in entitetni tip;
 atribut in tip podatkovnega elementa;
 entitetni identifikator (ključ entitetnega tipa);
 razmerje med entitetnimi tipi in tip (števnost) razmerja;
 močne in šibke tipe entitet.
Entiteta in entitetni tip
Entiteta
 Entitete so objekti (osebki) iz realnega sveta o katerih zbiramo, obdelujemo in
hranimo podatke in informacije. Primeri entitet:
človek Miha Novak, knjiga Vojna in mir, tečaj Angleščina 1, avto Ford Fiesta, ...
Pomembno: mora obstajati možnost razlikovanja med posameznimi entitetami! (Vsaka
entiteta mora imeti neko lastnost, po kateri lahko enolično opredelimo posamezno entiteto).
Tej lastnosti pravimo tudi entitetni identifikator ali ključ entitete.

Entitetni tip
 Entitetni tip je predstava o množici podobnih entitet. Podobnost entitete določamo
glede na vrste informacij, ki jih želimo hraniti o entitetah. Entitetni tip je abstraktna
predstavitev entitet, ki imajo enake atribute.
Atribut, tip podatkovnega elementa
Atribut
 Atribut je lastnost ali značilnost neke entitete ali razmerja med entitetami. Vrednost
atributa je podatkovni element nekega podatkovnega tipa (niz, število, ...) in ga je
možno prikazati v neki vidni ali slišni obliki (zaslonski prikaz, natisnjena oblika, zvok
...).
► Opcijski atribut - atribut, katerega vrednost je lahko tudi NULL.
► Enovrednostni atributi - atributi neke entitete, ki imajo le eno vrednost (ime,
datum rojstva, kraj rojstva, ....).
► Večvrednostni atributi - atributi neke entitete, ki imajo lahko tudi več vrednosti (e-
mail, telefon, ...). Opomba: za potrebe relacijske zbirke podatkov, ki ne dovoljuje

Zbirke podatkov 1
 77

večvrednostih atributov, jih s pomočjo razmerja preoblikujemo v enovrednostne

atribute.

Oznake za števnost atributa

 (1,1) - zahtevan vnos, enovrednostni atribut
 (0,1) - opcijski enovrednostni atribut
 (1,n) - zahtevan vnos, večvrednostni atribut
 (0,n) - opcijski večvrednostni atribut

Tip podatkovnih elementov

Vsak podatek pripada določenemu tipu (nizi znakov, števila, datumi, slike, ...). Večina SUZP
ima določeno število vnaprej definiranih tipov podatkov, ki jih podpirajo. Nekateri SUZP
ponujajo možnost ustvarjanja uporabniško definiranih podatkovnih tipov oziroma domen.
Dokončna izbira tipa podatkovnih elementov se opravi v fazi fizičnega načrtovanja zbirke
podatkov.
Razmerje med entitetnimi tipi
Razmerje opredeljuje povezavo med entitetnimi tipi. E-R model dovoljuje povezovanje
poljubnega števila entitetnih tipov, CASE orodja pa praviloma omogočajo le binarna razmerja
t.j. z enim razmerjem lahko povežemo le 2 entitetna tipa.

Simboli v diagramu E-R - teoretično, orodja CASE uporabljajo nekoliko spremenjene simbole

Beležke

Zbirke podatkov 1
78

Entitetni identifikator (ključ)

Definicija: Ključ entitetnega tipa E je atribut (ali več atributov skupaj), ki enolično določajo /
identificirajo posamezni primerek entitetnega tipa (entiteto).
Ključ entitetnega tipa ni nikoli opcijski atribut. To pomeni, da njegova vrednost mora biti
podana. Primarni ključ nekega entitetnega tipa je možno deklarirati tudi kot sestavljenko iz
dveh ali več atributov. Praviloma se temu izogibamo, ker dolgi ključi zahtevajo daljše (večje)
indeksne datoteke, kar povzroča počasnejše delovanje ZP.
Pri grafični predstavitvi entitetnega tipa z atributi, imena atributov, ki sestavljajo primarni ključ
(entitetni identifikator) podčrtamo:

Atribut EMSO je entitetni identifikator za Osebo

Števnost (kardinalnost) razmerja

Entiteta je lahko v razmerju z nič, eno ali več entitet drugega tipa (teoretično). V praksi pa
obstajajo pravila, ki govorijo o dovoljenjem številu pojavitev neke entitete v nekem
konkretnem razmerju. Ta pravila predstavimo s števnostjo razmerja:

Razmerje OBISKUJE povezuje entitetni tip DIJAK z entitetnim tipom KROZEK

Notacija predstavitve števnosti razmerja: (min,max).

Min je najmanjše število pojavitev entitete v razmerju, max pa največje število pojavitev
entitete v razmerju.
Kardinalnost opredelimo za vsak entitetni tip posebej.

Predstavitev števnosti razmerja

Zbirke podatkov 1
 79

Značilne števnosti razmerja so:

 1:1 (ena proti ena),
 1:M (ena proti mnogo) oziroma M:1 (mnogo proti ena),
 M:N (mnogo proti mnogo).
Opomba: zaradi poenostavitve je splošna praksa, da se za števnost razmerja beleži le
največja števnost (max) na obeh straneh razmerja.
Udeležba (participacija) entitete v razmerju:
 Popolna ali totalna participacija: vsak primerek entitetnega tipa (vsaka entiteta) se
mora udeležiti v razmerju.
 Delna ali parcialna participacija: entitete se lahko udeležijo ali pa ne udeležijo
razmerja.
Opomba: minimalne kardinalnosti ne vplivajo na klasifikacijo (razvrstitev) razmerji med
osnovne zvrsti 'ena proti ena', ' ena proti mnogo' in ' mnogo proti mnogo'. Zato jih lahko pri
nekaterih notacijah tudi izpustimo.
V praksi se uporablja še nekaj različnih, pa vendar veljavnih notacij za predstavitev števnosti
razmerja.

Prva možnost za predstavitev števnosti razmerja

Druga možnost za predstavitev števnosti razmerja

Minimalne števnosti so izpuščene, strani za predstavitev števnosti sta glede na entitetna tipa
zamenjani.

Beležke

Zbirke podatkov 1
80

Tretja možnost za predstavitev števnosti razmerja

To notacijo uporablja orodje Case Studio.

Četrta možnost za predstavitev števnosti razmerja

To je le ena od notacij, ki jih ponuja orodje DBDesigner.

Močne in šibke entitete (entitetni tipi)
Značilnost močnega entitetnega tipa
 Ključ močnega entitetnega tipa sestavlja(jo) le atribut(i), ki pripada(jo) temu
entitetnemu tipu.

Značilnosti šibkega entitetnega tipa

 Ne more obstajati brez svoje starševske entitete.
 Med šibko in močno entiteto vedno obstaja razmerje, ki s kardinalnostjo (1:1) kaže
proti močni entiteti.
 Ključ starševske entitete se prenese šibki entiteti kot zunanji ključ in postane
sestavni del ključa šibke entitete.

Primer močnega in šibkega entitetnega tipa

Opomba: v orodju Case Studio močno in šibko entiteto povežemo z identifikacijskim

razmerjem (identifying relationship), dve močni entiteti pa povežemo z ne-identifikacijskim
razmerjem (non-identifying relationship).

Zbirke podatkov 1
 81

Postopek izdelave modela E-R - primer

0. Scenarij – opis problema v naravnem jeziku
Univerza ima več fakultet. Posamezno fakulteto sestavlja več oddelkov. Vsak oddelek ponuja
različne programe in vsak program je sestavljen iz več tečajev. Učitelji lahko izvajajo več
tečajev in posamezni tečaj lahko izvajajo tudi večkrat. Posamezne tečaje lahko poučuje tudi
več učiteljev. Študent je vključen le v en program, vendar v en program je vključenih več
študentov. Študent lahko hkrati obiskuje tudi več tečajev in en tečaj obiskuje več študentov.

1. Opredelite (poiščite) entitetne tipe

 Univerza
 Fakulteta
 Oddelek
 Program
 Tečaj
 Učitelj
 Študent

2. Opredelite (poiščite) razmerja med entitetnimi tipi

Univerza Fakulteta Oddelek Program Tečaj Učitelj Študent
Univerza ima
Fakulteta sestavljena
Oddelek ponuja zaposlen
Program Je vpisan
sestavljen
Tečaj poučuje obiskuje
Učitelj
Študent

3. Narišite (skicirajte) osnovni ERD

Beležke

Zbirke podatkov 1
82

Osnovni diagram E-R

4. Opredelite kardinalnost (števnost) razmerja

 Univerza ima več fakultet.
 Vsaka fakulteta je sestavljena iz več oddelkov.
 Vsak oddelek ponuja več programov.
 Vsak program je sestavljen iz več tečajev.
 Na vsakem oddelku je zaposlenih več učiteljev.
 Učitelj poučuje več tečajev.
 Učitelj (lahko) poučuje en tečaj večkrat.
 Tečaj lahko vodi tudi več učiteljev.
 Študent je vpisan v le en program.
 Študent lahko obiskuje več tečajev hkrati.
 V tečaj je vpisanih več študentov.

Zbirke podatkov 1
 83

E-R diagram dopolnjen s števnostjo povezav

5. Opredelite (dodajte) primarne ključe

 Univerza – UniID
 Fakulteta – FID
 Oddelek – OddelekID
 Program – ProgramID
 Učitelj – UciteljID
 Tečaj – TecajID
 Študent – StudentID
Preverite, ali pri razmerjih s števnostjo M:N za sestavo primarnega ključa zadoščata le tuja
ključa (ključi povezanih entitet), ali pa morate dodati še nek atribut razmerja, ki bo sestavni
del sestavljenega primarnega ključa razmerja.
V primeru univerzitetnega IS Poučuje in Obiskuje imata števnosti M:N. V primeru Obiskuje za
primarni ključ zadoščata le tuja ključa (StudentID in TečajID), v ključ razmerja Poučuje pa

Beležke

Zbirke podatkov 1
84

moramo dodati atribut še atribut zaporedna_st, sicer nek učitelj ne more večkrat poučevati
isti tečaj.

6. Dodajte ostale atribute

Na osnovi opisa informacijskih potreb (zahtev) uporabnikov, dodajte vse manjkajoče atribute.
Denimo, pri učitelju bi dodali priimek, ime, izobrazbo, davčno številko, številko TTR, naslov, kraj,
telefon, email, starost, …

7. Verifikacija & validacija

Preverite, ali je končni model dejansko abstraktni prikaz 'mini sveta'. Nemudoma odpravite
katerekoli pomanjkljivosti, dvoumnosti ali nedoslednosti.

ERD za univerzitetni IS (logični pogled, prikazani so le primarni in tuji ključi)

Zbirke podatkov 1
 85

Postopek izdelava ZP s pomočjo orodja CASE

1. Izdelajte konceptualni model (E-R diagram):
 Dodajte entitetne tipe
 Entitetne tipe opišite z atributi
 Določite entitetni identifikator // če ga ni, dodajte ID ali šifro
 Povežite entitetne tipe
 Povezavi dodajte (morebitne) atribute
 Preverite (verificirajte in validirajte) model
 Shranite model in izdelajte dokumentacijo

2. Izberite ciljni SUZP

3. Izdelajte skripto za kreiranje zbirke podatkov v izbranem SUZP

4. V izbranem SUZP poženite skripto in kreirajte ZP

Pasti načrtovanja modela E-R

Najpogostejše pasti pri E-R načrtovanju so pasti 'povezovanja'. Najbolj znani sta:
 'fan-trap' in
 'chasm-trap'.
Fan trap
Do fan pasti pride, ko model predstavlja razmerje med entitetnima tipoma, vendar so
števnosti teh povezave nastavljene tako, da so povezave med posameznimi entitetami
dvoumne. Pojavlja se načeloma (vendar ne nujno) takrat, ko iz enega entitetnega tipa
izhajata dve 1:m povezavi.

Primer pasti fan

Dvoumnost modela se izkaže pri poizvedbi: V katerem oddelku dela Miha Novak?

Rešitev pasti fan

Beležke

Zbirke podatkov 1
86

 Izvede se preoblikovanje originalnega modela E-R tako, da razmerja prestavimo

(uredimo, razvrstimo) tako, kot v resnici obstajajo.
Primer: Delavec dela v oddelku, oddelek se nahaja na lokaciji.

Rešitev pasti fan

Chasm trap
Chasm past je zajeta v modelu, ki nakazuje obstoj razmerja med entitetnimi tipi, vendar ne
obstaja pot med posameznimi konkretnimi entitetami. Pojavlja se, ko na poti med dvema
povezanima entitetama obstaja razmerje z delno udeležbo.

Primer pasti chasm

Napaka modela je razvidna pri poizvedbi:kateri učbeniki obstajajo za kateri predmet? V

odgovoru bodo zajeti le tisti učbeniki, ki jih učitelj tudi dejansko uporablja in ne vsi učbeniki, ki
obstajajo za nek predmet.

Rešitev pasti ‘chasm’

Chasm past rešimo z dodajanjem manjkajočih relacij. V diagramu E-R manjka relacija
'obstaja', ki neposredno povezuje entitetna tipa Predmet in Učbenik.

Rešitev pasti chasm

Model E-R - vprašanja

Močan entitetni tip
ima vedno natanko enega kandidata za ključ.

ima vedno natanko en primarni ključ.

ima vedno več kandidatov za ključ.

ima vedno več primarnih ključev.

Zbirke podatkov 1
 87

nima ključa.

Denimo, da je šibki entitetni tip X povezan z svojim 'nadrejenim' močnim entitetnim tipom Y.
Ključ šibkega entitetnega tipa X je
enak ključu močnega entitetnega tipa Y.

je le del ključa močnega entitetnega tipa Y.

je kombinacija ključa močnega entitetnega tipa Y in ključnega atributa šibkega

entitetnega tipa X.
je kombinacija ključa močnega entitetnega tipa Y in vseh atributov šibkega
entitetnega tipa X.
neodvisen od ključa močnega entitetnega tipa Y.

V kateri fazi načrtovanja ZP določimo ključe entitetnih tipov?

V fazi analize zahtev.

V fazi konceptualnega načrtovanja.

V fazi logičnega načrtovanja.

V fazi fizičnega načrtovanja.

Denimo, da imamo dva entitetna tipa: Ime_osebe in Oseba, ki sta povezana z razmerjem
'pripada' ('ime_osebe' pripada 'osebi'). Števnost tega razmerja je:
ena proti mnogo.

mnogo proti ena.

ena proti ena.

mnogo proti mnogo.

poljubna.

Beležke

Zbirke podatkov 1
88

Denimo, da imamo dva entitetna tipa: Ime_osebe in Oseba, ki sta povezana z razmerjem
'pripada' ('ime_osebe' pripada 'osebi'). Udeležba entitetnega tipa Oseba v razmerju 'pripada'
do entitetnega tipa Ime je
delna.

totalna.

nedoločljiva.

Denimo, da je entitetni tip Oseba povezan sam z seboj z refleksivno relacijo 'je_otrok'
('oseba' je otrok 'osebe'). Števnost tega razmerja je:
ena proti mnogo.

mnogo proti ena.

ena proti ena.

mnogo proti mnogo.

Denimo, da je entitetni tip Oseba povezan sam z seboj z refleksivno relacijo 'je_otrok'
('oseba' je otrok 'osebe'). Udeležba entitetnega tipa Oseba v refleksivnem razmerju
'ima_otroka' v vlogi starša je
delna.

totalna.

nedoločljiva.

Zbirke podatkov 1
 89

Denimo, da je entitetni tip Oseba povezan sam z seboj z refleksivno relacijo 'je_otrok'
('oseba' je otrok 'osebe'). Udeležba entitetnega tipa Oseba v refleksivnem razmerju
'ima_otroka' v vlogi otroka je
delna.

popolna.

nedoločljiva.

Razmerje R povezuje močan entitetni tip X z šibkim entitetnim tipom Y. Katera od navedenih
števnosti razmerja je neveljavna?
1:1

M:N

1:M

Od modela E-R modela se zahteva (možnih več odgovorov),

da je točen.

da je nedvoumen.

da v pomnilniku porabi malo prostora.

da ga podpira izbrani SUZP.

da je razumljiv.

Beležke

Zbirke podatkov 1
90

Katera faza načrtovanja ZP je neodvisna od bodočega SUZP-ja, ki bo upravljal z ZP (možnih

več odgovorov)?
Faza analize zahtev

Faza konceptualnega načrtovanja.

Faza logičnega načrtovanja.

Faza fizičnega načrtovanja.

Vse faze so odvisne od bodočega SUZP-ja

Grafična predstavitev modela E-R modela ni standardizirana. Osnovni koncepti modela se,
odvisno od izbranega orodja, lahko predstavijo na različne načine.
DA

NE

Načrt zbirke podatkov pripravijo bodoči uporabniki zbirke podatkov.

DA

NE

Posamezno entiteto nekega entitetnega tipa identificiramo s pomočjo kateregakoli atributa.

DA

NE

Diagram E-R se uporablja za ponazoritev fizičnega modela zbirke podatkov.

DA

NE

Vrednost NULL pogosto uporabljamo za predstavitev neznane vrednosti atributa.

DA

NE

Zbirke podatkov 1
 91

Razmerje lahko poveže entitetni tip samega s seboj.

DA

NE

Entiteta in entitetni tip sta eno in isto.

DA

NE

Dva različna entitetna tipa imata lahko enega ali več atributov z enakimi imeni.
DA

NE

Model E-R je zaradi grafične predstavitve uporabnikom lažje razumljiv od relacijskega

modela.
DA

NE

Z enim entitetnim tipom lahko predstavimo več entitet.

DA

NE

Močan entitetni tip je vedno povezan vsaj z enim šibkim entitetnim tipom.
DA

NE

Beležke

Zbirke podatkov 1
92

Značilnost šibkega entitetnega tipa je, da je vedno povezan vsaj z enim močnim entitetnim
tipom.
DA

NE

Model E-R je neodvisen od SUZP.

DA

NE

Zbirke podatkov 1
 93

RELACIJSKI PODATKOVNI MODEL

Relacijski model podatkov

Značilnosti relacijskega modela
Glavne značilnosti relacijskega modela podatkov
 Podatki se združujejo v tabelah.
 Tabele so medsebojno logično povezane.
 Povezava tabel je izvedena s pomočjo enakih stolpcev tabel.

Primer relacijske zbirke podatkov

Relacijska ZP je sestavljena iz množice poimenovanih in logično povezanih tabel.

Zakaj potrebujemo relacijski model podatkov (ko že imamo model E-R)?

Beležke

Zbirke podatkov 1
94

Odgovor: SUZP neposredno podpira relacijski (in/ali) objektni model (ne pa tudi modela E-
R).
Koncepti relacijskega modela
Osnovni koncepti relacijskega modela podatkov so:
 relacija in atributi,
 shema relacijske zbirke podatkov,
 stanje relacije,
 vrednosti in zaloge vrednosti atributov,
 atomarnost vrednosti atributov,
 domene.

Zbirka podatkov

Shematski prikaz strukture relacijske ZP

Relacija in atributi
Relacija in atributi:
 Relacija je predstavljena s tabelo. Atributi so predstavljeni s stolpci tabele.
Relacijska ZP je sestavljena iz 1 ali več tabel.
 Tabela je sestavljena iz 1 ali več stolpcev.
 V tabeli je zapisanih 0, 1 ali več vrstic - t.i. n-teric relacije. Opomba: za n-terica se
uporablja tudi angleški izraz 'tuple'.
 Vrednosti podatkovnih elementov so zapisane v presečišču vrstic in stolpcev. To so
vrednosti atributov za določeno n-terico.
 Relacija (matematično gledano) = množica n-teric. Iz tega dejstva sledi, da:
► je vrstni red vrstic znotraj tabele (načeloma) nedefiniran in
► v relaciji (ker gre za množico elementov) ni podvajanj n-teric (vrstic).
Opomba: Večina današnjih SUZP-jev dovoljuje podvajanje vrstic tabele, dokler le-ta nima
definiranega ključa.
RM ne zahteva in ne opredeljuje nobene posebne podatkovne strukture za fizično
shranjevanje podatkov. Tabele oziroma relacije predstavljalo le logični pogled na podatke.

Zbirke podatkov 1
 95

Shematski prikaz relacije

Shema relacijske zbirke podatkov

Vse sestavine relacijske zbirke podatkov morajo biti opisane. Opis relacijske ZP je shema
ZP. Shema ZP je sestavljena iz shem posameznih relacij. Shema relacijske ZP opredeljuje:
 imena tabel, ki sestavljajo zbirko podatkov,
 atribute oziroma imena stolpcev vsake tabele,
 podatkovne tipe posameznih stolpcev - v vsakem stolpcu lahko shranjujemo le
podatke nekega določenega tipa (nize znakov, cela ali realna števila, datume, ...),
 integritetne omejitve - to so pogoji, ki jih morajo izpolnjevati podatki, ki so zapisani v
zbirki podatkov.

Primer relacije Dijak

Shema relacije Dijak

 Ime tabele = Dijaki
 Atributi tabele Dijaki: IDDijak, Priimek, Ime, Razred, Telefon
Beležke

Zbirke podatkov 1
96

 Podatkovni tipi in integritetne omejitve atributov:

► IDDijak = TEXT(5); zahtevan vnos 5 števk, vrednost se v tabeli ne ponovi
► Priimek = TEXT(20); vpisani podatki se prikažejo kot velike črke
► Ime = TEXT(10)
► Razred = TEXT(3); zahteva vnos ČrkaŠtevkaČrka; "G2A"|"G2B"|"G2C"|null
► Telefon = TEXT(11)

Stanje relacije
Stanje relacije je primerek podane relacijske sheme. Opredeljeno je z množico vrstic, ki so
zapisane v relaciji. Vzorčna tabela Dijaki ima trenutno 5 vrstic. Stanje relacije je lahko:
 legalno (dovoljeno) - vrednosti vseh atributov so skladne z opredeljenimi
integritetnimi omejitvami ali
 nelegalno (nedovoljeno).
Za legalnost stanja relacije v praksi skrbi SUZP.
Za vpogled v stanje relacije uporabljamo notacijo:
tabela.Ai ali tabela[Ai].
Formalno zapisane vrednosti četrte vrstice tabele Dijak:
Dijaki.IDDijak ='10205'
Dijaki.Priimek='Mlinar'
Dijaki.Ime='Mateja'
Dijaki.Razred='G2A'
Dijaki.Telefon='01-123-333'
Vrednosti in zaloge vrednosti atributov
Vnosi v tabelo (podatki) so podatkovne vrednosti iz neke določene zaloge vrednosti, ki je
opredeljena za vsak podatek posebej. Izbor možnih zalog vrednosti določa SUZP; različni
SUZP-ji ponujajo različne tipe podatkov. Osnovni tipi podatkov so nizi znakov, števila (cela,
realna), datum, čas, valuta, binarni podatki, …
Relacijski podatkovni model je neodvisen od katerekoli konkretne izbire podatkovnih tipov!
Pri opredelitvi relacijskega modela je množica tipov le parameter sheme.
Razširitve nekaterih sodobnih SUZP-jev omogočajo uporabnikom definiranje novih
podatkovnih tipov – to je lastnost predvsem sodobnih OR sistemov.
Atomarnost vrednosti atributov
En vnos podatka v tabelo je atomaren (nedeljiv) podatek. Klasični relacijski model ne
dovoljuje uvajanja struktur in večvrednostnih vrednosti atributov. To pomeni, da vsaka celica
v tabeli lahko vsebuje le eno število, niz znakov, datum ... Podpora kompleksnim vrednostim
(množice, seznami, zapisi, gnezdene tabele, ...) je značilna za objektno-relacijske sisteme.
Opomba: v resnici obstajajo kompleksne strukture, katerih kompleksnost je s pomočjo
vgrajenih funkcij uporabnikom prikrita; primer: DATE, TEXT(n), DATETIME, ... V teh primerih
je deljivost vrednosti atributov vidna šele na nivoju vrednosti podatkov in ne na nivoju
samega podatkovnega modela.

Zbirke podatkov 1
 97

Domene
Domena je okrajšano ime za standardne tipe podatkov. Za domeno lahko opredelimo tudi
dodatne integritetne omejitve: zahtevan podatek, le pozitivna vrednost, .... Domene
zagotavljajo:
 enoličnost in konsistentnost podatkovnih tipov in
 boljše razumevanje strukture ZP.
Primeri:
// Primer kreiranja domene za podatek Številka vaje v zbirki podatkov FireBird
Create Domain "Zap_st_vaje" As Smallint NOT NULL Check (>0);

// Isti primer za zbirko podatkov MS SQL server

Exec sp_addtype 'Zap_st_vaje', 'Smallint', 'NOT NULL'
Go

Opomba: zmožnost kreiranja domen je odvisna od izbranega SUZP-ja ( denimo mySQL 4,

Paradox ne podpirata domen).
Notacije relacijske sheme
Relacijska shema zbirke podatkov S opredeljuje:
 končno množico imen relacij {R1, ..., Rm},
 za vsako relacijo Ri, relacijsko shemo sch(Ri)
 množico C integritetih omejitev (ključe, zunanje ključe, vrste referencialnih
integritet)
Primer podajanja relacijske sheme ZP: S = ({R1, R2, R3},sch,C).
Za podajanje relacijskih shem zbirke podatkov obstaja veliko različnih notacij!
Relacijska shema relacije s opredeljuje:
 končno zaporedje A1 ... An imen atributov in
 za vsak atribut Ai podatkovni tip (ali domeno) Di, naj bo dom(Ai):=val(Di) - domena
atributa Ai je množica vseh možnih vrednosti, ki jih ponuja domena Di.
Primer podajanja relacijske sheme relacije: s = (A1:D1, ..., An : Dn)
Opomba: imena atributov ene relacijske sheme morajo biti različna.
Beležke

Zbirke podatkov 1
98

V praksi se relacijska shema lahko poda na več načinov:

 kot oris tabele,
 s tabelarično predstavitvijo,
 v formalni notaciji ali
 s stavki jezika SQL DDL.

Oris tabele

Tabelarična predstavitev

Formalna notacija
Formalna notacija predstavi ime relacije oz. tabele, ki ji v oklepajih sledi le seznam atributov.
Po potrebi lahko dodamo tudi podatkovne tipe stolpcev. Primarni ključ relacije podčrtamo.
Opcijske atribute označimo z o. Tuje ključe označimo na naslednji način:
ime_atributa→ime_starševske_tabele.
Primeri:
 Oseba(EMSO, Priimek, Ime, Telefono)
 Izpit(StudentID→Student, PredmetID→Predmet, Datum, Ocena)
 Obiskuje(DijakID→Dijak, KrozekID→Krozek)
 Vaja(Kategorija, Številka_vaje, Opis, Max_št_točk)
 Rezultati(DijakID→Dijak, (Kategorija, Številka_vaje)→Vaja, Datum,
Dosežene_točke)

Stavek SQL DDL jezika

Stavki SQL so odvisni od izbranega SUZP-ja. Za uporabnike je ta predstavitev relacijske
sheme pretirano ‘tehnična'. Primerna je le za primerna za komunikacijo med tehničnim
osebjem (načrtovalci, administrator ZP, programerji, ...).

Relacijski model - vprašanja

Termin Relacija se uporablja kot sinonim za
stolpec tabele.

vrstico tabele.

tabelo.

Zbirke podatkov 1
 99

atribut.

Zbirka konceptov, ki se uporablja pri opisu strukture zbirke podatkov je

SUZP.

podatkovni model.

podatek.

informacija.

relacija.

Beležke

Zbirke podatkov 1
100

Pravilo, ki določa da se vrednost enega atributa mora pojaviti v nekem drugem atributu, se
imenuje
tranzitivna odvisnost.

anomalija pri dodajanju zapisov.

integritetna omejitev - omejitev referencialne integritete.

normalna forma.

Kako se imenuje skupina enega ali več atributov, ki enolično identificira vrstico tabele?
Ključ.

Determinanta.

N-terica.

Relacija.

Katera od navedenih lastnosti ne velja za relacije?

Nobeni dve vrstici ne moreta biti enaki.

Vrstni red vrstic je enoličen.

Vsak stolpec ima enolično ime.

V vrstici so zapisani podatki o entiteti.

Ključ, ki vsebuje 2 ali več atributov se imenuje

sestavljeni ključ.

primarni ključ.

kandidat za ključ.

zunanji ključ.

Zbirke podatkov 1
 101

Katera od navedenih interpretacij ni sprejemljiva za vrednost NULL?

Ne obstaja ustrezna vrednost.

Katerakoli vrednost je ustrezna.

Null vrednost je prazna..

Vrednost je neznana

Katera od navedenih lastnost ne sodi med značilnosti tabel, ki so hkrati tudi relacije?
V polja tabele lahko zapišemo le nedeljive vrednosti.

Vrstni red stolpcev je pomemben.

Vsi vnosi v nek stolpec tabele morajo pripadati isti domeni.

Vsak stolpec ima enolično ime.

Lastnost, ki ima enolično vrednost za vsako entiteto in jo dodamo relaciji, da bi dobili primarni
ključ se imenuje
sestavljeni ključ.

kandidat za ključ.

generični ključ.

zunanji ključ.

Beležke

Zbirke podatkov 1
102

Katera od navedenih operacij spremeni shemo relacije?

Branje zapisov.

Dodajanje zapisov.

Brisanje zapisov.

Spreminjanje zapisov.

Nobena od navedenih operacij ne spremeni sheme relacije.

Dana je relacijska shema Oseba(Priimek_in_Ime,Datum_rojstva,Spol). Kateri atribut krši

pravilo atomarnosti atributa?
Priimek_in_Ime

Datum_rojstva

Spol

Noben od atributov ne krši pravila atomarnosti atributov.

Stanje relacije je legalno, ko

so vpisani vsi podatki

so vsi vpisani podatki točni

noben podatek ne krši integritetnih omejitev

so podatki relacije dostopni uporabnikom.

Relacijska zbirka podatkov je predstavljena z množico

celic.

atributov.

vrstic.

tabel.

polj.

Zbirke podatkov 1
 103

Vrednost NULL vpišemo v polje atributa tako, da

vpišemo 0.

vpišemo NULL.

vpišemo presledek.

vpišemo null.

pritisnemo Enter brez predhodnega vnosa kakršnekoli vrednosti.

Podana je relacijska shema relacije Dijak (Dijak_ID, Priimek, Ime, Telefono). Katere od
naslednjih zapisov bo pri dodajanju SUZP zavrnil in zakaj?
Dijak_ID Priimek Ime Telefon
1022 Kralj 123-33-45
Babnik Tilen
1023 Kralj Tina 334-34-34
1024 Kralj Tina
1023 Kos Darko 443-32-32

Dana je tabela:
Izdelek
IDIzdelek Ime Cena Dobavitelj
0324 Fanta 180SIT ABC
0444 Cocta 170SIT CCC
1323 Frupi 190SIT CCC
1333 Fruc 120SIT CCC
V formalni notaciji zapišite:
a) relacijsko shemo tabele
b) vrednosti podatkovnih elementov, ki ste jih prebrali v prvi vrstici tabele

Beležke

Zbirke podatkov 1
104

Večina komercialnih zbirk podatkov je načrtovana in implementirana na osnovi relacijskega

modela podatkov.
DA

NE

Relacijski podatkovni model podpira sestavljene vrednosti atributov (denimo množice,

strukture, ….).
DA

NE

Vrstni red n-teric (zapisov) relacije je nedefiniran.

DA

NE

Vse vrednosti nekega atributa relacije morajo biti različne.

DA

NE

Podatki o podatkih so metapodatki.

DA

NE

V relaciji je v določenih primerih dovoljeno podvajanje atributov.

DA

NE

Ključ relacije je en ali več atributov relacije, ki jih uporabljamo za enolično identifikacijo ene
n-terice relacije.
DA

NE

V zbirki podatkov imamo lahko več atributov z enakim imenom.

Zbirke podatkov 1
 105

DA

NE

Vrednost NULL lahko uporabimo v vseh opcijskih atributih ne glede na osnovni tip podatka
atributa.
DA

NE

Uporaba domen poenostavi postopek vzdrževanja zbirke podatkov.

DA

NE

Ključ, ki je sestavljen iz dveh ali več atributov se imenuje sestavljeni ključ.

DA

NE

Relacijski podatkovni model zahteva vnos vrednosti v vse atribute relacije.

DA

NE

V zbirki podatkov imamo lahko več atributov, ki so opisani z istim podatkovnim tipom.
DA

NE

Vse tabele neke zbirke podatkov so tudi relacije.

Beležke

Zbirke podatkov 1
106

DA

NE

Dovoljenje za uporabo vrednosti NULL pri posameznem atributu opredelimo v relacijski

shemi relacije.
DA

NE

V povezanih tabelah morata zunanji in primarni ključ imeti enaki imeni.

DA

NE

Preslikava modela E-R v relacijski model

Preslikava modela E-R v relacijski model
Obstajata dva razloga za preslikavo modela E-R v relacijski podatkovni model:
 SUZP neposredno ne podpira modela E-R in
 SUZP podpira (praviloma) relacijski ali objektno-relacijski podatkovni model.
Sam postopek preslikave lahko opravimo na 2 načina:
 avtomatizirano - orodja CASE načeloma podpirajo avtomatizacijo procesa
kreiranja zbirke podatkov in s tem avtomatično preslikajo model E-R v relacijski ali
 ročno - uporabimo pravila za preslikavo in naredimo sheme relacij.
Kaj je potrebno preslikati? Odgovor je preprost: vse - torej entitente tipe in razmerja.
Preslikava entitetnih tipov
V relacijske sheme preslikamo vse močne in šibke entitetne tipe. Pri preslikavi uporabimo
naslednja pravila:
 Za vsak entitetni tip kreiramo eno relacijsko shemo. Ime relacije naj bo ime
entitetnega tipa (priporočilo).
 Atributi relacije so atributi entitetnega tipa.
 Opcijske atribute prevedemo v atribute, v katerih dovolimo vrednosti 'NULL' oz.
neobvezna polja (non-required field).
 Ključ entitetnega tipa postane primarni ključ pripadajoče relacije.
 Tuji ključi entitetnega tipa postanejo tuji ključi relacije.
Primer preslikave entitetnih tipov:

Zbirke podatkov 1
 107

Model E-R

Mode E-R ima 2 močna entitetna tipa in en šibki entitetni tip. Zato moramo narediti 3
relacijske sheme.
Relacijski model
Potovalna_agencija – relacija, ki predstavlja močno entiteto
 Potovalna_agencija(AgencijaID:A20, ImeA:A20, Naslov:A20o, url:A20o)
Katalog – relacija, ki predstavlja močno entiteto
 Katalog(KatalogID:A5, ImeKataloga:A20, AgencijaID→Potovalna_agencija:A20)
Vsebina – relacija, ki predstavlja šibko entiteto
 Vsebina(ZapSt:N, KatalogID→Katalog:A5, Opis:A20, Opomba:A20o)
Preslikava razmerja
Način preslikave razmerja v relacijsko shemo je določen s števnostjo razmerja. Glede na
števnost razmerja: 1:M, M:N ali 1:1 je potrebno uporabiti ustrezno pravilo.

Beležke

Zbirke podatkov 1
108

Preslikava razmerja s kardinalnostjo 1:M

Pri preslikavi razmerja s števnostjo 1:M uporabimo naslednja pravila:
 Ključ na strani razmerja s kardinalnostjo 1 dodamo kot nov stolpec v tabelo, ki
predstavlja entitetni tip na strani M. Takemu ključu pravimo tuji (foreign) ključ.
► Če gre za identifikacijsko razmerje (identifying relationship - povezava predstavlja
razmerje med šibko in močno entitete), je tuji ključ sestavni del ključa šibke entitete.
► Če gre za neidentifikacijsko razmerje (nonidentifying relationship - povezava
predstavlja razmerje med močnimi entitetami), ostaneta ključa entitet
nespremenjena.

Preslikava razmerja s kardinalnostjo M:N

Pravila pri preslikavi razmerja s števnostjo M:N v relacijsko shemo so:
 Razmerje s kardinalnostjo M:N vedno preslikamo v novo relacijo.
 Atributi tabele so ključi entitetnih tipov, ki so povezani z razmerjem in skupaj tvorijo
ključ novonastale relacije. Ključ relacije, ki nastane kot posledica razmerja M:N, je
vedno sestavljen.
 V novonastalo relacijsko shemo dodamo še atribute razmerja. Ti atributi načeloma
niso sestavni del ključa razmerja, obstajajo pa tudi izjeme.

Primer preslikave razmerja s števnostjo M:N

Model E-R

Model E-R ima tri močne entitetne tipe (Igralec, Film in Nagrada) in dve razmerji s števnostjo
M:N (Igra in Dobi). Zato moramo v relacijskem modelu narediti pet relacijskih shem.
Relacijski model
Igralec - relacija, ki predstavlja močan entitetni tip
 Igralec(IgralecID:N, Priimek:A20, Ime:A20)
Film - relacija, ki predstavlja močan entitetni tip
 Film(FilmID:N, Ime_filmao:A20)
Nagrada - relacija, ki predstavlja močan entitetni tip
 Nagrada(NagradaID:A4, ImeNagrade:A20, Opiso:A20)
Zbirke podatkov 1
 109

Igra - relacija, ki predstavlja razmerje s števnostjo M:N (razmerje ima svoj atribut Vloga )
 Igra(IgralecID→Igralec:N, FilmID→Film:N, Vlogao:A20)
Dobi - relacija, ki predstavlja razmerje s števnostjo M:N (razmerje nima lastnih atributov)
 Dobi(IgralecID→Igralec:N, FilmID→Film:N, NagradaID→Nagrada:A4)

Preslikava razmerja s kardinalnostjo 1:1

V principu je preslikava razmerja s števnostjo 1:1 enaka, kot v primeru preslikave razmerja s
števnostjo 1:M. Pri enem od entitetnih tipov ustvarimo oziroma dodamo tuji ključ (nikakor pa
ne pri obeh, ker bi to pripeljalo do nenadzorovane redundance).
Primer preslikave razmerja s števnostjo 1:1

Model E-R

V relacijskem podatkovnem modelu lahko naredimo 3 inačice relacijskih shem.

Prva varianta
Eni od relacij dodamo znani ključ:
Delavec (DelavecID,PMestoID→Parkirno_mesto)
ali
Parkirno_mesto(PMestoID,DelavecID→Delavec)
Druga varianta
Preslikavo razmerja s števnostjo 1:1 lahko rešimo tudi tako, da vpeljemo dodatno tabelo, ki
vsebuje le ključe povezanih entitetnih tipov. Oba ključa predstavljata kandidata za ključ
novonastale relacije. Zato, za ključ novonastale tabele izberemo le enega od atributov,
nikakor pa ne obeh, ker bi to porušilo kardinalnost razmerja 1:1. Kot rešitev po drugi varianti
bi lahko naredili eno od naslednjih dveh relacij:

Beležke

Zbirke podatkov 1
110

Ima(DelavecID→Delavec, PMestoID→Parkirno_mesto)
ali
Ima(DelavecID→Delavec, PMestoID→Parkirno_mesto)
Tretja varianta
Če imamo razmerje 1:1 s popolno udeležbo obeh entitet v razmerju (na obeh straneh je
kardinalnost (1,1)), potem za obe entiteti in razmerje kreiramo le eno skupno relacijo, v kateri
združimo atribute obeh entitet. V tem primeru imamo dva kandidata za ključ relacije. To sta
ključa povezanih entitetnih tipov. Za ključ relacije izberemo samo enega. Možni rešitvi:
Delavec(DelavecID, PMestoID)
ali
Parkirno_mesto(PMestoID, DelavecID)
Ta rešitev ni ravno priporočljiva, ker v primeru brisanja podatkov o delavcu, hkrati izgubimo
tudi podatke o parkirnem mestu in obratno.

Preslikava modela E-R - vprašanja

E-R model prosilcev za službo

Oglejte si E-R diagram, ki prikazuje model ZP, v kateri hranimo podatke o prosilcih za
službo.
 Na osnovi modela določite shemo relacijske ZP (shemo zapišite v formalni notaciji).
 Katere tabele predstavljajo močne entitetne tipe?
 Katere tabele predstavljajo šibke entitetne tipe?
 Katere tabele predstavljajo razmerja?
 Kateri atributi so opcijski?

E-R diagram za vodenje krožkov

Koliko tabel bo nastalo v relacijskem modelu iz E-R diagrama za vodenje krožkov?

Katere tabele bodo imele primarni ključ, katere pa tuji ključ?

Zbirke podatkov 1
 111

Normalizacija
Normalizacija ZP
Pri izdelavi načrta ZP se načrtovalci pogosto vprašajo:
 'Kako naj izmerim oz. ocenim kakovost logičnega načrta ZP?'
 'Kako naj "vem", ali je načrt ZP dober?'
 'Kako naj preverim kakovost načrta?'
Kot pomoč pri načrtovanje kakovostne ZP, se uporabljajo različna vodila:
 Neformalna vodila:
► Upoštevanje semantike atributov.
► Zmanjševanje (omejevanje) podvajanja vrednosti v vrsticah tabele.
► Zmanjševanje (omejevanje) števila opcijskih atributov (NULL).
► Preprečevanje ‘sumljivih’ zapisov.
► ...
 Formalno vodilo:
► S postopkom normalizacije se načrt ZP transformira vsaj do 3NF ali BC normalne
forme.

Neformalna vodila
Neformalno vodilo - semantika atributov
Posledica grupiranja atributov pri ustvarjanju relacij je tudi pridruževanje določenega pomena
(semantike) posameznemu atributu. Pri tem je potrebno upoštevati nasvete:
 relacije načrtujte tako, da bo enostavno pojasniti njen pomen;
 ne kombinirajte (mešajte) atributov različnih tipov entitet v eni relaciji.
Primer 'slabe' relacije: Delavec (Davčna_st, Priimek, Ime, Naslov, Ime_Oddelka,
Vodja_oddelka, Naslov oddelka)
Relacija vsebuje atribute entitetnega tipa Delavec (njegovo davčno številko, priimek, ime,
naslov in oddelek, v katerem dela) in atribute entitetnega tipa Oddelek (oddelek, vodjo
oddelka in naslov oddelka).

Neformalno vodilo - zmanjševanje podvajanj vrednosti v vrsticah tabele

Beležke

Zbirke podatkov 1
112

En od ciljev načrtovanja je tudi zmanjšanje potrebnega pomnilniškega prostora za hranjenje

podatkov v relaciji. Način grupiranja atributov v relacije ima velik vpliv na porabo pomnilnika,
t.j. napačno grupiranje atributov lahko ima za posledico tudi anomalije, do katerih pride pri
posodabljanju podatkov. Posledice anomalij so neskladnosti in dvoumnosti med podatki ali
(celo) njihova izguba.
Primer relacije s podvajanjem vrednosti:
Delavec

DelavecID Priimek OddelekID ImeOddelka Kraj oddelka

104 Perko 3 Prodaja Ljubljana

180 Medved 2 Finance Maribor

192 Volk 2 Finance Maribor

197 Pihlar 3 Prodaja Ljubljana

199 Kalin 2 Finance Maribor

Vrste anomalij pri posodabljanju podatkov

1. Anomalije pri dodajanju novih zapisov:
 ker je ključ relacije Delavec atribut Davčna številka, ne moremo dodati novega
oddelka, v katerem ni še nihče zaposlen;
 vnos vseh podatkov o oddelku, v katerem je delavec zaposlen, mora biti povesem
točen ali pa povsod moramo vpisati NULL -> za avtomatizacijo preverjanja
veljavnosti novih podatkov moramo napisati del programske kode
Delavec

DelavecID Priimek OddelekID ImeOddelka Kraj oddelka

104 Perko 3 Prodaja Ljubljana

180 Medved 2 Finance Maribor

192 Volk 2 Fruinance Maribor

197 Pihlar 3 Prodaja Ljubljana

199 Kalin 2 Finance Maribor

Zbirke podatkov 1
 113

2. Anomalije pri brisanju zapisov - lahko pride do izgube podatkov:

 če pride do brisanja vseh delavcev iz oddelka 2, hkrati izgubimo tudi vse ostale
podatke o oddelku (ime oddelka, kraj oddelka).
Delavec

DelavecID Priimek OddelekID ImeOddelka Kraj oddelka

104 Perko 3 Prodaja Ljubljana

180 Medved 2 Finance Maribor

192 Volk 2 Finance Maribor

197 Pihlar 3 Prodaja Ljubljana

199 Kalin 2 Finance Maribor

Kam je 'izginil' oddelek 2?

3. Anomalije pri spreminjanju vrednosti atributov - lahko pripeljejo do nekonsistentnosti

(neskladnosti) podatkov:
 če se je oddelek 2 preselil iz Maribora v Kranj, moramo to spremembo vpisati v vse
vrstice relacije, v katerih so delavci, ki delajo v oddelku 2.
 posledici: zamudnost pri posodabljanju podatkov in možnost nepopolne
posodobitve (dvoumni podatki).
Delavec

DelavecID Priimek OddelekID ImeOddelka Kraj oddelka

104 Perko 3 Prodaja Ljubljana

180 Medved 2 Finance Kranj

192 Volk 2 Finance Kranj

197 Pihlar 3 Prodaja Ljubljana

199 Kalin 2 Finance Maribor

Beležke

Zbirke podatkov 1
114

Nasveti:
 ZP načrtujte tako, da se ne more pojaviti nobena od anomalij pri dodajanju, brisanju
ali modificiranju podatkov.
 Če pride do katerekoli anomalije, poskrbite, da vse aplikacije, ki dostopajo do ZP
posodobijo vsebino zbirke tako, da ohranijo integriteto (celovitost) podatkov. To je
sicer težja naloga, ker zahteva dobro koordinacijo z vsemi programerji, ki pišejo
uporabniške aplikacije.

Neformalno vodilo - zmanjševanje števila opcijskih atributov

Posledice pogoste pojavitve vrednosti NULL v zapisih so:
 izguba pomnilniškega prostora in
 manjša semantična vrednost podatkov - NULL vrednosti vplivajo na semantiko
(pomen) relacije in na opredelitev različnih operacij (povezovanje relacij ,
agregacija (združevanje) podatkov, ..).
Možne interpretacije pomena vrednosti NULL so:
 atribut nima pomena za to relacijo,
 vrednost atributa je za ta zapis neznana,
 vrednost atributa je sicer znana, vendar še ni zabeležena.
Zaradi enake predstavitve (vrednost NULL) za vse navedene možnosti, je pridobivanje
informacij iz tovrstnega zapisa dvoumno in zato vprašljivo.
Nasveti:
 V največji možni meri se izogibajte dovoljevanju null vrednosti za atribute osnovnih
relacij.
 Če so vrednosti null neizogibne, zagotovite, da se pojavljajo le v izjemnih primerih
in da se ne pojavljajo v večini primerov.

Neformalno vodilo - preprečiti 'sumljive zapise'

Nekakovostna (slaba) dekompozicija (delitev) velike relacije v množico manjših lahko
povzroča množico težav. V praksi lahko pride do situacije, da se zaradi dekompozicije
informacije osnovne relacije lahko tudi izgubijo ali popolnoma popačijo. To lahko ugotovimo
takrat, ko manjše relacije ponovno povežemo nazaj. V tem primeru je ciljna relacija večja od
originalne, ker vsebuje množico neveljavnih oz. sumljivih zapisov.

Zbirke podatkov 1
 115

Primer slabo opravljene dekompozicije:

a) osnovna relacija:
Delavec
DelavecID Priimek Kraj Država Poštna št.
104 Perko Ljubljana Slovenija 1000
180 Medved Maribor Slovenija 2000
192 Volk Trst Italija 3006
197 Pihlar Ljubljana Slovenija 1000
199 Kalin Ljubljana Slovenija 1000

b) delitev relacije Delavec na relaciji Delavec1 in Seznam pošt:

Delavec1
DelavecID Priimek Kraj Država
104 Perko Ljubljana Slovenija
180 Medved Maribor Slovenija
192 Volk Trst Italija
197 Pihlar Ljubljana Slovenija
199 Kalin Ljubljana Slovenija

Seznam pošt
Poštna št. Država
1000 Slovenija
2000 Slovenija
3006 Italija

Beležke

Zbirke podatkov 1
116

c) posledica izvedbe povezovanja tabel Delavec1 in Seznam pošt:

 dobljena tabela je večja od osnovne,
 tabela ima neveljavne (sumljive) zapise.
Delavec
DelavecID Priimek Kraj Država Poštna
št.
104 Perko Ljubljana Slovenija 1000
104 Perko Ljubljana Slovenija 2000
180 Medved Maribor Slovenija 2000
180 Medved Maribor Slovenija 1000
192 Volk Trst Italija 3006
197 Pihlar Ljubljana Slovenija 1000
197 Pihlar Ljubljana Slovenija 2000
199 Kalin Ljubljana Slovenija 1000
199 Kalin Ljubljana Slovenija 2000

Nasveti za preprečevanje neveljavnih zapisov:

Relacijske sheme načrtujte tako, da jih lahko povežete na osnovi enakih vrednosti atributov,
ki so bodisi primarni ali tuji ključi. Tako se izognemo rezultatom povezovanj, ki imajo
neveljavne zapise.
Funkcionalne odvisnosti
Funkcionalne odvisnosti so glavni koncept, povezan s postopkom normalizacije ZP.
Koraki normalizacije temeljijo na določenih pravilih, ki se nanašajo na funkcionalne
odvisnosti med atributi tabele. Pravilno opredeljene funkcionalne odvisnosti na začetku
postopka normalizacije so pogoj za uspešno izvedbo normalizacije.
Funkcionalna odvisnost opisuje razmerja med atributi relacije. Če sta A in B atributa
relacije R, potem je atribut B funkcionalno odvisen od atributa A (notacija: A -> B), če je vsaki
vrednosti atributa A pridružena natanko ena vrednost atributa B. V tem primeru atribut A
predstavlja determinanto za atribut B. Za funkcionalno odvisnost lahko rečemo, da je to
lastnost pomena (semantike) atributov relacije.

Diagramski prikaz funkcionalne odvisnosti

Primer funkcionalne odvisnosti: DelavecID =14 -> Delovno mesto = Prodajalec

Atribut DelavecID predstavlja determinanto za atribut DelovnoMesto

Zbirke podatkov 1
 117

Funkcionalna odvisnost NI komutativna

Če atribut DelavecID funkcionalno določa vednost atributa Delovno mesto, to še ne pomeni,

da atribut Delovno mesto funkcionalno določa vrednost atributa DelavecID.

Le na osnovi vrednosti atributa Delovno mesto ne moremo enolično opredeliti vrednost atributa DelavecID.

Glavne značilnost funkcionalnih odvisnosti, ki jih uporabimo pri normalizaciji so:

 razmerje med atributi na levi in desni strani funkcionalne odvisnosti je 1:1,
 odvisnosti so trajne (veljajo za vse primerke stanja ZP),
 so netrivialne.
Opombe glede določanja funkcionalnih odvisnosti:
 Celotna množica funkcionalnih odvisnosti za dano relacijo je lahko zelo obsežna.
 Pomembno je najti pristop, s katerim se zmanjša število funkcionalnih odvisnosti na
obvladljivo količino Vzeti si je treba čas za iskanje množice funkcionalnih odvisnosti
(X) za relacijo, ki je manjša od celotne množice funkcionalnih odvisnosti (Y) in ima
lastnost, da je vsaka funkcionalna odvisnosti v množici Y implicirana (posledica)
funkcionalnih odvisnosti v množici X.
 Določanje funkcionalnih odvisnosti je zahtevno opravilo.

Beležke

Zbirke podatkov 1
118

Vrste funkcionalnih odvisnosti

Obstajajo tri vrste funkcionalnih odvisnosti:
 delna funkcionalna odvisnost,
 polna funkcionalna odvisnost in
 tranzitivna funkcionalna odvisnost.
Pri postopku normalizacije ZP mora načrtovalec poznati značilnosti različnih vrst
funkcionalnih odvisnosti in načine za odpravljanje delnih in tranzitivnih funkcionalnih
odvisnosti.

Delna funkcionalna odvisnost

Delna funkcionalna odvisnost obstaja, ko je atribut relacije funkcionalno odvisen le od dela
ključa relacije. Lahko se pojavil le, če ima tabela sestavljene ključe.
Primer: Izdelki(IzdelekID, Dobavitelj, ImeIzdelka, OpisIzdelka)
Izdelki
IzdelekID Dobavitelj ImeIzdelka OpisIzdelka
305 Rupro FujiFilmNF300 Drobni inventar
305 ABCComputer FujiFilmNF300 Drobni inventar
320 Murkart Putek02 Pijača
320 Šumko Putek02 Pijača

V relaciji Izdelki obstajajo naslednje funkcionalne odvisnosti:

 IzdelekID,Dobavitelj -> ImeIzdelka, OpisIzdelka in
 IzdelekID -> ImeIzdelka, OpisIzdelka
Očitno je, da sta atributa ImeIzdelka in OpisIzdelka funkcionalno odvisna le od dela ključa
tabele Izdelki in sicer le od atributa IzdelekID.

Polna funkcionalna odvisnost

Polna funkcionalna odvisnost obstaja, ko je atribut funkcionalno odvisen od celotnega ključa.
Denimo, da sta A in B atributa relacije R. Atribut B je polno funkcionalno odvisen od atributa
A le, če je B funkcionalno odvisen od atributa A in hkrati ni funkcionalno odvisen od
katerekoli podmnožice atributov iz skupine A.

Zbirke podatkov 1
 119

Primer: Indeksi(StudentID, ProfesorID, PredmetID, Ocena) // Opomba: v indeks se vpisujejo

le pozitivne ocene.
Indeksi
StudentID ProfesorID PredmetID Ocena
305 100 MA1 10
305 200 KE1 9
320 100 MA1 6
305 100 MA2 10

Funkcionalna odvisnost v relaciji Indeksi:

 StudentID, ProfesorID, PredmetID -> Ocena
Atribut ocena je polno funkcionalno odvisen od celotnega ključa tabele Indeksi.

Tranzitivna funkcionalna odvisnost

Tranzitivna funkcionalna odvisnost obstaja, ko je atribut posredno funkcionalno odvisen od
ključa tabele. V tem primeru je posrednik atribut, ki je polno ali delno funkcionalno odvisen od
ključa relacije.
Razlaga koncepta tranzitivnosti:
 Denimo, da so A, B, in C atributi relacije R, za katere velja A->B in B->C.
 Potem lahko rečemo, da je atribut C tranzitivno (posredno) funkcionalno odvisen od
atributa A preko atributa B.
Primer: Dijak(DijakID, Ime, KrajRojstva, DržavaRojstva)
Dijak
DijakID Ime KrajRojstva DrzavaRojstva
305 Jure Ljubljana Slovenija
306 Charles Pariz Francija
307 Mateja Ljubljana Slovenija
308 John London Anglija

Funkcionalne odvisnosti v relaciji Dijak:

Beležke

Zbirke podatkov 1
120

 DijakID->Ime,KrajRojstva in
 KrajRojstva->DržavaRojstva // Atribut Država rojstva je tranzitivno odvisna od
DijakID preko atributa KrajRojstva
Povzetek:
 Poznavanje funkcionalnih odvisnosti predstavlja osnovo za izvedbo postopka
normalizacije ZP.
 Funkcionalna odvisnost opisuje razmerje med atributi relacije. Funkcionalne
odvisnosti lahko določimo le, če poznamo pomen podatkov in poslovna pravila v
modeliranem okolju (scenarij).
 Funkcionalno odvisnost predstavimo v notaciji A -> B. Atribut B je funkcionalno
odvisen od atributa A oziroma atribut A je determinanta atributa B.
 Funkcionalne odvisnosti niso komutativne.
 Vrste funkcionalnih odvisnosti:
 Delna funkcionalna odvisnost: atribut je odvisen le od dela ključa.
 Polna funkcionalna odvisnost: atribut je odvisen od celotnega ključa.
 Tranzitivna funkcionalna odvisnost: atribut je odvisen od ključa preko posrednega
atributa, ki ni ključ.
Postopek normalizacije
Kaj je normalizacija?
Vsebinsko gledano je normalizacija postopek,ki pomaga pri doseganje boljše kakovosti
načrta zbirke podatkov.
Tehnično gledano je normalizacija proces, ki vodi relacijsko shemo ZP skozi zaporedje
testov. Z vsakim testom preverimo, ali so izpolnjeni določeni pogoji. Za relacijsko shemo, ki
ustreza določenim pogojem pravimo, da je v določeni normalni formi. Sheme relacij, ki ne
zadoščajo pogojem, razdelimo na več manjših relacij tako, da dobljene relacije ustrezajo
predpisanim zahtevam.

Zbirke podatkov 1
 121

Formalni postopek normalizacije

Postopek normalizacije

Formalni postopek normalizacije poteka po korakih:

 izhodišče je nenormalizirana ZP,
 pretvorba v 1 NF,
 pretvorba v 2 NF,
 pretvorba v 3 NF,
 (po potrebi) pretvorba v BC NF in
 pretvorba v višje normalne forme.
Opomba: kratica NF pomeni 'normalna forma'.

Posledice normalizacije
Večina posledic izvedbe postopka normalizacije ZP je pozitivnih:
 zmanjša se redundanca (podvajanje) podatkov,
 v normalizirani zbirki manj pogosto prihaja do anomalij med podatki oz.
normalizirana ZP jih samodejno izloča,

Beležke

Zbirke podatkov 1
122

 postopek normalizacije proizvaja nadzorovane redundance, ki se uporabljajo pri

povezovanju tabel.
Včasih pa ima normalizirana ZP slabše performanse (odzivni časi so daljši) od
nenormalizirane. V tem primeru se izvaja postopek denormalizacije ZP. To pomeni, da ZP
vračamo iz višjih normalnih form v nižje.
Pri postopku normalizacije ZP načrtovalec mora poznati semantiko (pomen) dveh konceptov:
 pomen ključa relacije (primarni ključ, kandidat za ključ, sestavljeni ključ, tuji ključ) in
 pomen funkcionalnih odvisnosti.
Nenormalizirana forma
Tabela je nenormalizirana takrat, ko ima eno ali več skupin ponavljajočih se podatkov.
Da bi naredili nenormalizirano relacijo, preprosto transformiramo dobljene podatke (denimo z
obrazca) v tabelarični format (vrstice + stolpci).
Primer: DeloNaProjektih(ProjektID, ImeProjekta, (DelavecID, Priimek, Poklic, Vrednost_ure),
Opravljenih ur)
DeloNaProjektih
ProjektI ImeProjekt DelavecI Priime Poklic Vrednost_ur Opravljenih_u
D a D k e r
1 MIZU 1 Kos programe 2100 35
r
2 Volk DBA 3600 42
3 Senica Analitik 4100 42
4 Vrabec programe 2100 30
r
2 MINXS 2 Volk DBA 3600 32
4 Vrabec programe 2100 32
r

1NF - Prva normalna forma

Tabela je v prvi normalni formi,
 če so vsi ključni atributi definirani in
 če ne vsebuje ponavljajočih se skupin vrednosti atributov.
To pomeni, da načrtovalec mora določiti ključ in zagotoviti, da ni ponavljajočih se skupin
vrednosti atributov.

Zbirke podatkov 1
 123

V našem primeru je rezultat DeloNaProjektih(ProjektID, DelavecID, ImeProjekta, Priimek,

Poklic, Vrednost_ure, Opravljenih ur).
DeloNaProjektih
ProjektID ImeProjekta DelavecID Priimek Poklic Vrednost_ure Opravljenih_ur
1 MIZU 1 Kos programer 2100 35
1 MIZU 2 Volk DBA 3600 42
1 MIZU 3 Senica Analitik 4100 42
1 MIZU 4 Vrabec programer 2100 30
2 MINXS 2 Volk DBA 3600 32
2 MINXS 4 Vrabec programer 2100 32

2NF - Druga normalna forma

Drugo normalno formo naredimo na osnovi polne funkcionalne odvisnosti.
Relacija je v drugi normalni formi, če se nahaja v 1NF in je vsak ne-ključni atribut polno
funkcionalno odvisen od primarnega ključa (če ne obstaja nobena delna funkcionalna
odvisnost).
Postopek transformacije iz 1NF v 2NF:
 ugotovite primarni ključ relacije v 1NF,
 opredelite funkcionalne odvisnosti znotraj relacije,
 če obstaja atribut(i), ki je delno funkcionalno odvisen od primarnega ključa, ga
skupaj z njegovo determinanto prestavite v novo relacijo. Determinanta ostane tudi
v osnovni relaciji.

Primer transformacije iz 1NF v 2NF

Prva NF: Projekt(ProjektID, DelavecID, ImeProjekta, Priimek, Poklic, Vrednost_ure,
Opravljenih_ur)
Funkcionalne odvisnosti:
 ProjektID,DelavecID -> ImeProjekta // OK
 ProjektID -> ImeProjekta // delna funkcionalna odvisnost -> ime projekta in kopijo
determinante damo v novo tabelo, denimo Projekt
 ProjektID, DelavecID -> Priimek, Poklic, Vrednost_ure // OK

Beležke

Zbirke podatkov 1
124

 DelavecID -> Priimek, Poklic, Vrednost_ure // delna funkcionalna odvisnost ->

priimek, poklic delavca, vrednost ure in kopijo determinante damo v novo tabelo,
denimo Delavec
 ProjektID,DelavecID -> Opravljenih_ur // OK

Rezultat pretvorbe v 2NF:

 Projekt(ProjektID, ImeProjekta)
Funkcionalne odvisnosti: ProjektID -> ImeProjekta
 Delavec(DelavecID, Priimek, Poklic, Vrednost_ure)
Funkcionalne odvisnosti: DelavecID -> Priimek, Poklic, Vrednost_ure, Poklic -> Vrednost_ure
 OpravljenoDelo(ProjektID->Projekt, DelavecID->Delavec, Opravljenih_ur)
Funkcionalne odvisnosti: ProjektID,DelavecID -> Opravljenih_ur
3NF - Tretja normalna forma
3NF izhaja iz koncepta tranzitivne funkcionalne odvisnosti.
Relacija je v 3NF, če je v 1NF in 2NF in noben atribut, ki ni primarni ključ, ni tranzitivno
odvisen od primarnega ključa.
Postopek transformacije iz 2NF v 3NF:
 identificirajte primarni ključ relacije v 2NF,
 opredelite funkcionalne odvisnosti v relaciji,
 če obstaja atribut, ki je tranzitivno odvisen od primarnega ključa, ga skupaj s kopijo
njegove determinante prestavite v novo relacijo.

Primer transformacije iz 2NF v 3NF

 Projekt(ProjektID, ImeProjekta)
Funkcionalne odvisnosti: ProjektID->ImeProjekta // OK, ni tranzitivne odvisnosti
 Delavec(DelavecID, Priimek, Poklic, Vrednost_ure)
Funkcionalne odvisnosti: DelavecID -> Priimek, Poklic, Vrednost_ure
Poklic -> Vrednost_ure // tranzitivna odvisnost; atribut vrednost_ure in njegovo determinanto
prestavimo v novo relacijo
 OpravljenoDelo(ProjektID->Projekt, DelavecID->Delavec, Opravljenih_ur)
Funkcionalne odvisnosti: ProjektID,DelavecID -> Opravljenih_ur // OK

Rezultat pretvorbe v 3NF:

 Projekt(ProjektID, ImeProjekta)
Funkcionalne odvisnosti: ProjektID->ImeProjekta
 OpravljenoDelo(ProjektID->Projekt, DelavecID->Delavec, Opravljenih_ur)
Funkcionalne odvisnosti: ProjektID, DelavecID -> Opravljenih_ur
 Delavec(DelavecID, Priimek, Poklic->Delovno_mesto)
Funkcionalne odvisnosti: DelavecID -> Priimek, Poklic
 Delovno_mesto(Poklic, Vrednost_ure)

Zbirke podatkov 1
 125

Funkcionalne odvisnosti: Poklic -> Vrednost_ure

Normalizacija - vprašanja
Vsaka relacijska shema, ki je v prvi normalni formi, je tudi v drugi normalni formi.
DA

NE

Delna funkcionalna odvisnost pomeni, da je nek atribut funkcionalno odvisen le od

neke podmnožice atributov, ki sestavljajo ključ relacije.

enega od atributov, ki sestavljajo ključ relacije.

vseh atributov, ki sestavljajo ključ relacije.

dela vrednosti enega atrituba, ki je v ključu relacije.

enega ali več atributov, ki niso v ključu relacije.

Pri izvedbi postopka normalizacije ZP se število relacij

praviloma poveča.

praviloma zmanjša.

ostane enako, vendar se število ključev praviloma poveča.

ostane enako, vendar se število ključev praviloma zmanjša.

Beležke

Zbirke podatkov 1
126

Do delne funkcionalne odvisnosti lahko pride le, če

obstaja več kandidatov za ključ relacije.

je ključ relacije sestavljen iz več atributov.

relacija ima tudi tuje ključe.

obstaja determinanta, ki ni kandidat za ključ relacije.

V kateri normalni formi moramo odpraviti ponavljajoče se skupine vrednosti podatkov?

v 1NF.

v 2NF.

v 3 NF.

v BCNF.

Vsaka relacijska shema, ki je v BCNF je tudi v tretji normalni formi.

DA

NE

Kaj je glavni cilj postopka normalizacije ZP?

Hitrejše delovanje ZP.

Boljša zaščita integritete podatkov.

Prijaznejši uporabniški vmesnik.

Izboljšanje sistema dostopnih pravic uporabnikov.

Manjše število relacijskih shem.

Zbirke podatkov 1
 127

STRUKTURIRANI POVPRAŠEVALNI JEZIK (SQL)

SQL je najbolj razširjen računalniški jezik, ki omogoča kreiranje, spreminjanje, branje in
manipulacijo s podatki, shranjenimi v relacijski ZP. Širitev jezika gre v smeri podpore
objektno relacijskim zbirkam podatkov.
Jezik SQL je standardiziran (ANSI / ISO), vendar je upoštevanje standardov s strani
nekaterih proizvajalcev SUZP vprašljivo.
Zgodovina SQL in standardi
 1970 Edgar F. Codd objavi članek "A Relational Model of Data for Large Shared
Data Banks"
 70. leta – IBM San Jose raziskovalni center razvije "System R“; SQL je namenjen
manipulaciji in branju podatkov
 1978 – IBM razvija komercialne relacijske SUZP-je, ki temeljijo na SQL-u
(System/38; 1981. SQL/DS; 1983. DB2)SQL86 ali SQL 87(ANSI), leta 1987. tudi
ISO
 SQL89 (manjše spremembe)
 SQL92 ali SLQ 2 (temeljite spremembe)
 SQL:1999 ali SQL 3 (rekurzivne poizvedbe, sprožilci, nekatere objektne zmožnosti)
 SQL:2003 (XML podpora, okenske funkcije, …)
Namen SQL-a
Osnovni namen: izvedba specifičnih, omejenih nalog - izvajanje poizvedb
Značilnosti SQL-a:
 zasnovan je na množicah (ker izhaja iz relacijskega modela podatkov),
 deklarativnost (povemo KAJ in ne KAKO),
 funkcionalna preprostost, enostavnejši nabor ukazov (v primerjavi z Focus, SAS,
…).

Beležke

Zbirke podatkov 1
128

Smernice dopolnitev SQL-a:

 Uporaba stavkov SQL jezika znotraj nekega ‘pravega’ programskega jezika.
 Uporaba PL/SQL jezika.
Alternative SQL-u
 IBM Business System 12 (IBM BS12)
 Top's Query Language (IBM)
 Tutorial D (truly relational database query languag )
 Hibernate Query Language (HQL) - A Javansko orodje, ki uporablja modificirano
obliko SQL-a)
 Object Query Language (Object Data Management Group); primeri: The Enterprise
JavaBeans (EJB), Java Data Objects (JDO)
Glavne kategorije stavkov jezika SQL
 DDL (Data Definition Language)
► Omogočajo kreiranje in spreminjanje opisa podatkov.
 DML (Data Manipulation Language)
► Omogočajo dodajanje, brisanje in spreminjanje podatkov.
 DQL (Data Query Language)
► Omogočajo izvajanje poizvedb.
 DCL (Data Control Language)
► Omogočajo opredeljevanje in nadzor dostopa do podatkov.
 Stavki za administracijo (Data administration commands)
► Omogočajo sledenje in analizo izvajanja drugih stavkov SQL.
 Stavki za nadzor transakcij (Transactional control commands)
► Omogočajo sprožanje in preklic izvajanja transakcij.

SQL DDL (Data Description Language)

Pozor:
 Stavki SQL so odvisni od SUZP.
 Kljub standardom obstaja veliko različnih implementacij SQL DDL.
 Dovoljenja za izvedbo stavkov SQL DDL praviloma imata le upravitelj in lastnik ZP.
Osnovni stavki SQL DDL
Med osnovne stavke jezika SQL DDL uvrščamo stavke, ki omogočajo definiranje tabel in
indeksov.

Zbirke podatkov 1
 129

Stavki za definiranje tabel (opredelimo tabele, atribute, integritetne omejitve, tuje ključe, ...):
 Kreiranje tabel - CREATE TABLE
 Spreminjanje tabel - ALTER TABLE
 Brisanje tabel - DROP TABLE
Stavki za definiranje indeksov:
 Kreiranje sekundarnih indeksov - CREATE INDEX
 Brisanje primarnega / sekundarnih indeksov - DROP INDEX
Delo s tabelami
Stavek za kreiranje tabel CREATE TABLE
Sintaksa
CREATE TABLE ime_tabele (
atribut1 tip1 [integritetne_omejitve],
atribut2 tip2 [integritetne_omejitve],
...
Primary Key (atributx, atributy, ...),
Foreign Key (atributfk) References ime_starševske_tabele (atribut) On operacija1 akcija1 On
operacija2 akcija2
);
Najpogostejše integritetne omejitve so:
 NOT NULL,
 UNIQUE,
 CHECK pogoj,
 DEFAULT vrednost.
Pri opredeljevanju tujih ključev pod vrednost operacija1 vpišemo update, pod operacija2 pa
delete. V obeh primerih pod akcija vpišemo eno od vrednosti: no action | cascade | set null |
set default.
Kombinacija operacije in akcije pri opredelitvi tujih ključev določa tip referencialne integritete.
Ta kombinacija opredeli odziv SUZP v primeru bodisi brisanja ali posodabljanje vrednosti
starševskega zapisa.

Beležke

Zbirke podatkov 1
130

 Če je akcija 'no action', potem SUZP prepreči brisanje vseh zapisov starševske
tabele, v kolikor le ti imajo ustrezne zapise v otroški tabeli.
 Če je akcija 'cascade', potem SUZP hkrati z brisanjem zapisa starševske tabele
izbriše tudi vse pripadajoče zapise v otroški tabeli.
 Če je akcija 'set null', potem SUZP pri brisanju zapisa starševske tabele, v vseh
pripadajočih zapisih otroške tabele v vrednost zunanjega ključa vpiše vrednost
NULL.
 Če je akcija 'default', potem SUZP pri brisanju zapisa starševske tabele, v vseh
pripadajočih zapisih otroške tabele v vrednost zunanjega ključa vpiše privzeto
vrednost.

Možni podatkovni tipi za atribute so odvisni od SUZP. V nekaterih SUZP lahko kreiramo
domene ali uporabniško definirane tipe podatkov, ki pomagajo ohranjati konsistentnost
podatkovnega tipa znotraj zbirke podatkov.
Primer stavka SQL DDL za SUZP Firebird, ki naredi tabelo:
Praznik(PraznikID:N, ImePraznika:A20,Dan:N,Mesec:N, Opombao:A100)
Create table Praznik(
PraznikID integer NOT NULL,
ImePraznika varchar(20) NOT NULL,
Dan integer NOT NULL CHECK (dan >=1 and dan<=31),
Mesec integer NOT NULL CHECK (mesec >=1 and mesec<=12),
Opomba varchar(100),
Primary Key(PraznikID));

Primer stavka SQL DDL za SUZP Firebird, ki naredi tabelo Proslava:

Proslava(ProslavaID:A5, PraznikID→Praznik:N, Vsebina:A50, Opiso:A200, Cena:N)
Create table Proslava(
ProslavaID char(5) not null,
PraznikID integer not null References Praznik (PraznikID) on delete cascade on update
cascade,
Vsebina char(50) not null,
opis varchar(200),
cena float check (cena>=0),
primary key (ProslavaID,PraznikID));

Zbirke podatkov 1
 131

Prikaz narejenih table z isql (SUZP je Firebird)

Stavek za spreminjanje strukture tabel ALTER TABLE

Stavek ALTER TABLE se uporablja za:
 Dodajanje novih atributov v obstoječo tabelo
ALTER TABLE ime_tabele ADD atribut tip [integritetne omejitve];
 Brisanje atributov iz tabele
ALTER TABLE ime_tabele DROP atribut;
► Če je ta atribut uporabljen kot tuji ključ neke druge tabele, brisanje atributa NE
USPE
► Če izbrišemo atribut, izbrišemo tudi VSE vrednosti tega atributa v tabeli.
 Dodajanje tujih ključev
ALTER TABLE ime_tabele ADD FOREIGN KEY ime_kljuca REFERENCES
ime_starševske_tabele (ime_atributa) ON operacija1 akcija1 ON operacija2 akcija2;
Operacija1 = update, operacija2 = delete

Beležke

Zbirke podatkov 1
132

Akcija1 oz. akcija2 = no action | cascade | set default | set null

Primer stavka, ki v tabelo praznik doda atribut Opis, ki je sestavljen in 30 znakov in prikaz spremenjene strukture tabele Praznik.

Stavek za brisanje tabele DROP TABLE

Značilnosti stavka DROP TABLE:
 Zelo zanimiv stavek.
 Najbolje dela takrat, ko si to najmanj želimo.
 Neprevidna uporaba tega stavka empirično dokazuje pomen rednega arhiviranja
ZP.
 Po izvedbi stavka DROP TABLE sta izbrisana struktura in vsebina tabele.
 Sintaksa je preprosta in praviloma enovita za vse SUZP:
DROP TABLE ime_tabele;
Primer stavka, ki izbriše tabelo Proslava:
Drop Table Proslava;
Opomba: stavek DROP TABLE (praviloma) ne uspe, če je ta tabela starševska za neko
drugo tabelo (če je njen ključ uporabljen kot tuji ključ druge tabele). Kljub temu uporabljate ta
stavek skrajno pazljivo!
Delo z indeksi
Uporaba sekundarnih indeksov ima pozitivne in negativne posledice.

Pozitivne posledice
 Hitrejše iskanje podatkov (če je tabela indeksirana po atributu, ki je ključ za
iskanje).
 Hitrejši prikaz razvrščenih podatkov.

Zbirke podatkov 1
 133

Negativne posledice
 Večja poraba pomnilniškega prostora (diska, RAM-a).
 Počasnejša izvedba stavkov za dodajanje, brisanje in spreminjanje vsebine tabele.

Nasveti
 S številom sekundarnih indeksov ne pretiravajte.
 Tudi za sekundarne indekse naj velja pravilo, da so čim krajši.
 Le izjemoma uporabljajte sestavljene sekundarne indekse.
 Ne brišite primarnih indeksov (razen, če je to res nujno potrebno). Nekateri SUZP-ji
ne omogočajo brisanja primarnih indeksov, nekateri pa omogočajo ih hkrati
izbrišejo tudi vse sekundarne indekse.
 Pred morebitnim brisanjem ali spreminjanjem primarnih ključev obvezno naredite
arhivsko kopijo ZP.

Stavek za kreiranje sekundarnega indeksa - CREATE INDEX

Sintaksa stavka za kreiranje sekundarnega indeksa:
CREATE [int_omejitve] INDEX ime_indeksa ON ime_tabele (atribut1, atribut2, ..);
Int_omejitve: [UNIQUE] [ASC] | DESC]
Stavek naredi sekundarni indeks z imenom ime_indeksa, ki ga sestavljajo atributi atrubut1,
atribut2, ... Indeks je lahko razločevalen (če je podana integritetna omejitev UNIQUE).
Indeks je lahko urejen naraščajoče (ASC) ali padajoče (DESC). Privzeta nastavitev je ASC.
Opomba: integritetne omejitve podpirajo le nekateri SUZP.
Primer stavka, ki za tabelo Praznik naredi sekundarni indeks po_datumih:
CREATE INDEX po_datumih ON Praznik (mesec,dan);

Prikaz vseh indeksov ZP s tabelami Praznik in Proslava

Stavek za brisanje indeksa - DROP INDEX

Beležke

Zbirke podatkov 1
134

Sintaksa stavka za brisanje sekundarnega indeksa:

DROP INDEX ime_indeksa; ali
DROP INDEX ime_indeksa ON ime_tabele;
Primer stavka, ki za tabelo Proslava najprej naredi sekundarni indeks ‘poCeni', indeks je
urejen padajoče - od najdražjih proslav do najcenejših. Naslednji stavek pa izbriše
sekundarni indeks 'poCeni'.
Create DESCENDING Index poCeni ON Proslava (Cena);
Drop Index poCeni;
Opomba: večina SUZP zahteva razločevalna imena sekundarnih indeksov! Primer je narejen
za SUZP Firebird.

Brisanje primarnega ključa tabele?

SUZP sicer omogočajo tudi brisanje primarnega ključa tabele. Kljub temu je ta operacija
nezaželena in največkrat povzroča precej težav.
Sledita dva zgleda kreiranja tabele s primarnim ključem in takoj za tem brisanja primarnega
ključa. V prvem primeru težav ni, ker primarni ključ še ni bil uporabljen pri povezovanju z
drugimi tabelami ZP. Tovrstna situacija je v praksi prava redkost. V drugem primeru je
ponazorjena napaka pri brisanju primarnega ključa, ki je v praksi pogosta.

Prvi primer - brez težav

/* naredimo tabelo test, primarni ključ je id */
SQL> create table test (id integer not null, neki char(10), primary key (id));
/* prikaz strukture tabele test1 */
SQL> show table test;
ID INTEGER Not Null
NEKI CHAR(10) Nullable
CONSTRAINT INTEG_37:
Primary key (ID)
/* poizkus brisanja primarnega ključa tabele test uspe */
SQL> alter table test drop constraint integ_37;
SQL> show table test;
ID INTEGER Not Null
NEKI CHAR(10) Nullable
SQL>

Drugi primer - težave pri brisanju primarnega ključa

/* naredimo tabelo test1, primarni ključ je id */
SQL> create table test1 (id integer not null, neki char(10), primary key (id));
/* prikaz strukture tabele test1 */
SQL> show table test1;
Zbirke podatkov 1
 135

ID INTEGER Not Null

NEKI CHAR(10) Nullable
CONSTRAINT INTEG_39:
Primary key (ID)
/* naredimo tabelo test2, atribut id2 je tuji ključ tabele test2 in se sklicuje na primarni ključ
tabele test1 */
SQL> create table test2 (id integer not null, id2 integer not null references test1 (id) on delete
no action on update no action, primary key (id));
/* prikaz strukture tabele test2 */
SQL> show table test2;
ID INTEGER Not Null
ID2 INTEGER Not Null
CONSTRAINT INTEG_42:
Foreign key (ID2) References TEST1 (ID) On Update No Action On Delete No Action
CONSTRAINT INTEG_43:
Primary key (ID)
/* poiskus brisanja primarnega ključa tabele test1 ne uspe, ker je uporabljen v definiciji tujega
ključa tabele test2 */
SQL> alter table test1 drop constraint integ_39;

Statement failed, SQLCODE = -607

unsuccessful metadata update
-ERASE RDB$RELATION_CONSTRAINTS failed
-action cancelled by trigger (1) to preserve data integrity
-Cannot delete PRIMARY KEY being used in FOREIGN KEY definition.
SQL>

Beležke

Zbirke podatkov 1
136

SQL DCL (Data Control Language)

Namen stavkov SQL DCL jezika je preprečevanje nepooblaščenih dostopov do podatkov v
ZP.
Nasvet: sistem dodeljevanja pravic naj bo voden in nadzorovan iz enega centra. Denimo, da
je za to odgovoren skrbnik (admin) ZP.
SQL DCL stavki omogočajo:
 dodajanje in brisanje uporabnikov / skupin,
 spreminjanje podatkov o uporabnikih,
 dodajanje in odvzemanje uporabniških pravic,
 dodajanje in odvzemanje dostopnih pravic predmetom ZP (sprožilcem, shranjenim
proceduram, ...),
 pregledovanje uporabniških skupin in vseh dodeljenih pravic.
Pozor: tudi SQL DCL je močno odvisen od izbranega SUZP-ja!
Definiranje uporabnikov in uporabniških skupin
Definiranje uporabnikov
CREATE USER ime_uporabnika;

Definiranje skupin uporabnikov

CREATE GROUP ime_skupine; ali
CREATE ROLE ime_skupine;

Dodajanje uporabnikov v skupino

ALTER GROUP ime_skupine ADD USER ime_uporabnika; ali
GRANT ime_skupine TO ime_uporabnika;

Dodeljevanje pravic
GRANT pravica ON ime_tabele TO ime_uporabnika|ime_skupine; ali
GRANT pravica ON ime_tabele TO GROUP ime_skupine;

Zbirke podatkov 1
 137

Odvzemanje pravic
REVOKE pravica ON ime_tabele TO ime_uporabnika; ali
REVOKE pravica ON ime_tabele TO GROUP ime_skupine;

Primer PostgreSQL skripte za definiranje uporabniških pravic:

/* naredi skupino*/
Create group Informator;

/* kreira uporabnike */
Create user Skrbnik;
Create user Matej;
Create user Peter;

/* polni skupino */
Alter group Informator add user Matej;
Alter group Informator add user Peter;

/* dodeljuje pravice skupini */

Grant select on Drzava to group Informator;
Grant select on Praznik to group Informator;
...
Grant select on Drzava to Skrbnik;

/* dodeljuje pravice uporabnikom */

Grant update on Drzava to Skrbnik;
Grant delete on Drzava to Skrbnik;
...

Beležke

Zbirke podatkov 1
138

Primer podobne skripte za ZP Firebird:

/* kreiranje skupine */
Create Role "Informator";

/* dodajanje uporabnikov v skupino */

Grant "Informator" to "Matej";
Grant "Informator" to "Peter";

/* definiranje pravic skupine */

Grant select on "Drzava" to "Informator";
Grant select on "Praznik" to "Informator";
Grant select on "Proslava" to "Informator";
Grant select on "Ima" to "Informator";< /p>

Opomba: v ZP Firebird se uporabniška imena in gesla naredijo in spreminjajo s posebnim

programom gsec.

SQL DML (Data Manipulation Language)

Stavki jezika SQL DML omogočajo osnovno manipulacijo s podatki, shranjenimi v relacijski
zbirki podatkov. Teoretična izhodišče stavkov DML sta relacijska algebra in relacijski račun.
Osnovne stavke delimo na tiste, ki ne spremenijo stanja zbirke podatkov in na tiste, ki
spremenijo stanje zbirke podatkov.
Stavek, ki ne spremeni stanja zbirke podatkov
 SELECT
Stavek SELECT omogoča branje in filtriranje podatkov, različne načine povezovanja tabel in
združevanja zapisov.
Stavki, ki spremenijo stanje zbirke podatkov
Skupna značilnost teh stavkov je, da se uspešno izvedejo le, če bo tudi novo stanje ZP
legalno (če ne pride do kršitev integritetnih omejitev). Sicer SUZP zavrne izvedbo in vrne
ustrezno kodo napake.
 INSERT
Stavek INSERT omogoča dodajanje zapisa v eno tabelo in prepisovanje zapisov med
tabelami.
 UPDATE
Stavek UPDATE omogoča posodabljanje vrednosti enega ali več atributov pri enem ali več
zapisih tabele.
 DELETE
Stavek DELETE omogoča pogojno ali brezpogojno brisanje enega ali več zapisov ene
tabele.

Zbirke podatkov 1
 139

Poleg omenjenih stavkov jezik SQL omogoča uporabo osnovnih aritmetičnih operatorjev,
agregiranih funkcij in množice različnih funkcij za delo z nizi, datumi, števili, za pretvarjanje
med podatkovnimi tipi, ...
Noben ob stavkov SQL DML ne spremeni opisa tabel. Pri izvedbi stavkov DML SUZP
poskrbi za zaščito integritete podatkov. Če bi izvedba stavka poškodovala celovitost
podatkov, ga SUZP zavrne.
SELECT - osnovno branje
Sintaksa:
Če želimo, da stavek vrne vse atribute tabele, uporabimo zvezdico, sicer navedemo imena
atributov. V odgovoru se vrstice lahko tudi podvojene.
SELECT [*|atr1,atr2,...] FROM tabela;
Ta oblika stavka SELECT vrne relacijo (množico zapisov). Zato v odgovoru ni podvajanj
vrstic.
SELECT DISTINCT atr1,atr2,... FROM tabela;
Dodatno SQL ponuja možnost razvrščanja podatkov v odgovoru. Privzet vrstni red
razvrščanja je ASC (naraščajoče).
SELECT atr1,atr2,... FROM tabela ORDER BY atrx [ASC|DESC],atry [ASC|DESC],...;

Beležke

Zbirke podatkov 1
140

Primeri osnovnega branja podatkov

Osnovno branje podatkov s pogoji

Sintaksa:
SELECT [*|atr1,atr2,...] FROM tabela WHERE pogoj;
V pogoju lahko uporabljamo:
 primerjalne operatorje: =, <>, <, <=, >, >=
 logične operatorje: AND, OR, NOT
 operator LIKE v kombinaciji s % (SQL92) ali * (Microsoft Access); % (oz. *) je meta
znak, ki pomeni poljubno zaporedje znakov
 operator BETWEEN spodnja_meja AND zgornja_meja
 operator IN (množica elementov)
V odgovoru so zajeti izbrani atributi in le tiste vrstice tabele, ki ustrezajo pogoju.

Zbirke podatkov 1
 141

Primeri osnovnega branja podatkov s pogoji

Unija - unija dveh tabel

Sintaksa
SELECT atr1,atr2,... FROM tabela1 UNION SELECT atr1,atr2,... FROM tabela2;
Navedeni morajo biti isti atributi iz obeh tabel!

Beležke

Zbirke podatkov 1
142

Primer unije tabel G2A in G2B

Povezovanje dveh tabel s kartezičnim produktom

Prvi način povezovanja dveh tabel je t.i. kartezični produkt. Značilnosti kartezičnega
produkta:
 Kartezični produkt poveže vsako vrstico prve tabele z vsemi vrsticami druge tabele
in vrne vse atribute.
 Tabela z odgovorom tako vsebuje vse možne kombinacije n-teric prve in druge
relacije z vsemi atributi.
 Tabele z odgovori so izjemno velike, odgovor pa praviloma nima uporabne
vrednosti.
 Uporabi kartezičnega produkta se izogibamo.
Sintaksa:
SELECT * FROM tabela1, tabela2, ...;
Opomba: pod FROM zapišemo vse tabele, ki jih želimo povezati.

Zbirke podatkov 1
 143

Primer kartezičnega produkta tabel Dijak in Krožek

Notranje povezovanje tabel

Notranje povezovanje uporabljamo takrat, ko črpamo podatke iz 2 ali več tabel. Tabele so
povezane s pomočjo tujih ključev. Notranje povezovanje dveh tabel se lahko izvede na dva
načina.
 Prvi način je uporaba t.i. theta stika. V tem primeru v delu stavka Where napišemo
pogoj(e), s katerim(i) povežemo tabele s pomočjo skupnih atributov.
SELECT [*|tabela1.atr1,...] FROM tabela1, tabela2, ... WHERE pogoj;

Beležke

Zbirke podatkov 1
144

 Drugi način je uporaba naravnega stika oz. konstrukta INNER JOIN, pod ON pa
napišemo pogoj(e) za povezovanje tabel.
SELECT [*|tabela1.atr1,...] FROM tabela1 INNER JOIN tabela2 ON (tabela1.atributx =
tabela2.atributx);
Tabela z odgovorom ima vse kombinacije vrstic prve in druge tabele, ki ustrezajo danemu
pogoju.

Primer povezovanja dveh tabel, z uporabo konstrukta WHERE

Zbirke podatkov 1
 145

Primer povezovanja dveh tabel, z uporabo konstrukta INNER JOIN

Zunanje povezovanje tabel

Notranje povezovanje (INNER JOIN) poveže le tiste vrstice prve in druge tabele, ki ustrezajo
pogoju (pri katerih je vrednost skupnega atributa/ov enaka). Če želimo poleg vrstic, ki
ustrezajo pogoju dobiti tudi vse vrstice bodisi prve ali druge tabele ali pa obeh tabel, moramo
uporabiti zunanje povezovanje. Zunanje povezovanje omogoča povezovanje:
 vseh vrstic prve tabele z ustreznimi vrsticami druge tabele (LEFT OUTER JOIN) -
če za nek zapis prve tabele ni ustreznega v drugi tabeli, so vrednosti atributov
druge tabele NULL
 vseh vrstic druge tabele z ustreznimi vrsticami prve tabele (RIGHT OUTER JOIN) -
če za nek zapis druge tabele, v prvi ni ustreznega, so vrednosti atributov prve
tabele NULL

Beležke

Zbirke podatkov 1
146

 vseh vrstic prve in druge tabele (FULL OUTER JOIN) - pri zapisih, ki nimajo
ustreznega v prvi ali drugi tabeli so vrednosti atributov le-teh NULL
Sintaksa:
SELECT atributi FROM tabela1 LEFT | RIGHT | FULL [OUTER] JOIN tabela2 ON
pogoj;

Primer uporabe zunanjega povezovanja: izpišite seznam vseh dijakov, in šifre krožkov, ki jih obiskujejo

SQL - vgrajene funkcije

Vgrajene SQL funkcije so odvisne od implementacije SQL-a oziroma od konkretnega
SUZP. V nadaljevanju so razložene predvsem standardne funkcije, ki naj bi jih podpirali vsi
SUZP.
Osnove kategorije vgrajenih funkcij so:

1. funkcije za agregacijo podatkov

 MIN, MAX - vrne najmanjšo, največjo vrednost
 COUNT - prešteje pojavitve določene vrednosti
 SUM - vrne vsoto določenih vrednosti
 AVG - vrne povprečje določenih vrednosti

2. funkcije za delo z nizi znakov

 konkatenira (združi) nize znakov
 pretvori niz v male ali velike črke
 vrne podniz niza

Zbirke podatkov 1
 147

3. funkcije za konverzijo
 izvede pretvorbo vrednosti med podatkovnimi tipi

4. funkcije za delo z datumskimi podatki

 izločajo del datumske vrednosti (dan / mesec / leto)
 izvajajo seštevanje datumov, računajo razliko med datumi, ...
Agregirane funkcije
Agregirane funkcije lahko uporabljamo samostojno, ali v kombinaciji s konstruktom za
združevanje vrstic tabele.
 Če agregirano funkcijo uporabljamo samostojno, se le-ta izvede nad vsemi
vrsticami tabele.
Sintaksa:
SELECT AGR_FUNKCIJA(atribut) FROM tabela;
 Ko agregirano funkcijo uporabljamo z združevanjem, se pred izvedbo funkcije
vrstice tabele združijo glede na dani pogoj. Potem se agregirana funkcija izvede za
vsako skupino vrstic posebej.
SELECT AGR_FUNKCIJA(atribut) [,atrx] FROM tabela GROUP BY atrx;

Funkciji MIN in MAX

Sintaksa:
SELECT MIN(atribut) FROM tabela;
SELECT MAX(atribut) FROM tabla;
Opomba: funkciji MIN in MAX delata za znakovne, številske in datumske podatke.

Beležke

Zbirke podatkov 1
148

Funkcija COUNT
Funkcija COUNT prešteje, kolikokrat se vrednost atributa atributx pojavi v tabeli.
Sintaksa:
SELECT COUNT(atributx) FROM tabela;
Opomba: tudi funkcija COUNT dela za znakovne, številske in datumske podatke.

Primera izvedbe funkcije COUNT brez in z združevanjem zapisov

Funkciji SUM in AVG

Funkcija SUM izračuna vsoto vseh vrednosti atributa atributx v tabeli.
Sintaksa:
Zbirke podatkov 1
 149

SELECT SUM(atributx) FROM tabela;

Funkcija AVG izračuna povprečno vrednost atributa atributx v tabeli. Pri tem ne upošteva
vrstic z vrednostjo NULL. Sintaksa:
SELECT AVG(atributx) FROM tabela;
Obe funkciji se lahko uporabljata le za atribute numeričnega tipa (cela ali realna števila).

Primer izvedbe funkcije AVG brez združevanja zapisov in funkcije SUM z združevanjem zapisov

Beležke

Zbirke podatkov 1
150

Pogoji, ki se nanašajo na vrednosti funkcij za agregacijo podatkov

Stavek SELECT ima 2 tipa pogojev:
 pogoje, ki se nanašajo na vrednosti atributov - zapišemo jih v konstruktu WHERE
 pogoje, ki se nanašajo na vrednosti, ki jih vrnejo funkcije za agregacijo podatkov
- zapišemo jih v konstruktu HAVING

Razlika med WHERE in HAVING

 WHERE filtrira podatke, ki bodo agregirani in ne stolpec, ki ga dobimo kot rezultat
agregiranje funkcije.
 HAVING filtrira vrstice po izvedbi agregirane funkcije in se sklicuje ravno na
stolpec, ki je rezultat funkcije.
Primer: izpis kategorij knjig, ki imajo nadpovprečno ceno
SELECT Book.Type, AVG(Book.Price) AS PovprečjeodPrice
FROM Book
GROUP BY Book.Type
HAVING ((Avg(Book.Price))>(select avg(Book.price) From Book));
Funkcije za delo z nizi
Vse ostale funkcije SQL (razen funkcij za agregiranje podatkov) so različno implementirane v
različnih SUZP. V primerih so navedene le nekatere implementacije osnovnih funkcij za delo
z znaki).

Združevanje nizov znakov (konkatenacija)

 SQL92 - operator ||
 MS Access - operator &
 mySQL - funkcija CONCAT

Primer uporabe združevanja nizov znakov

Zbirke podatkov 1
 151

Pretvorba v male ali velike črke

 SQL92 - funkcija LOWER(atr) | UPPER(atr)
 MS Access - funkcija LCase(atr) | UCase(atr)
 mySQL - dela oboje: LOWER(atr) / LCase(atr) | UPPER(atr) / UCase(atr)

Primer uporabe pretvorbe nizov v male in velike črke

Vračanje podniza niza znakov

 SQL92 - funkcija SUBSTR (atribut FROM pozicija FOR dolžina)
 MS Access - Left(atr,dolžina) ali Right(atr,dolžina) ali Mid(atr,začetek,dolžina)

Primer uporabe vračanja podniza niza in konkatenacije nizov znakov

Beležke

Zbirke podatkov 1
152

Funkcije za delo z datumi

Te funkcije uporabljamo praviloma takrat, ko želimo iz datumskega ali časovnega podatka
izločiti posamezni del datuma oz. časa: dan, mesec, leto, uro, .... Nekateri SUZP imajo
implementirane še posebne oblike te funkcije, ki omogočajo tudi ugotavljanje četrtletja.
 SQL92 - funkcija EXTRACT (polje FROM atr); polje = Year | Month | Day | Hour | ...
 MS Access - DatePart(polje,atribut); polje = "yyyy" | "m" | "d" ali Day(atr),
Month(atr), Year(atr)

Primer izločanja meseca iz podatka tipa datum

Funkcije za pretvorbo
Funkcije za konverzijo izvedejo pretvorbo podatkov iz enega podatkovnega tipa v drugi.
 SQL92 - funkcija CAST (atr AS tip)
 MS Access - za konverzijo v en tip obstaja ena funkcijea: CBool(atr), CByte(atr),
CCur(atr), CDate(atr),CDbl(atr),CDec(atr),CInt(atr),CLng(atr),CStr(atr), ...

Primer uporabe funkcije za konvertiranje datumskega podatka v niz znakov in konkatenacije nizov znakov

Zbirke podatkov 1
 153

INSERT
S stavkom INSERT se tabelo doda ena ali več vrstic. Uporabljamo ga za:
 dodajanje novih zapisov
INSERT INTO ime_tabele (atr1,atr2,...) VALUES (vr1,vr2,...);
 prepisovanje vsebine ene tabele (ali dela atributov ene tabele) v drugo
INSERT INTO tabela1 (atr1,atr2,...) SELECT (atr1,atr2,...) FROM tabela2;
Primer stavka INSERT, ki v tabelo Dijak doda zapis "20030","Kovač","Mojca","G4A"
INSERT INTO Dijak (DijakID,Priimek,Ime,Razred) VALUES
("20030","Kovač","Mojca","G4A");
Primer stavka INSERT, ki vsebino tabele Dijak za dijake razreda G2A prepiše v tabelo G2A
INSERT INTO G2A (DijakID,Priimek,Ime,Razred,Rojen) SELECT
(DijakID,Priimek,Ime,Razred,Rojen) FROM Dijak WHERE Dijak.Razred=‘G2A';
Stavek INSERT ne uspe, če:
 pride do podvajanja primarnega ključa tabele,
 niso navedeni vsi zahtevani atributi,
 se tip atributa in vrednost ne ujemata,
 vpisujemo vrednost tujega ključa, ki v starševski tabeli ne obstaja,
 vrednost atributa že obstaja, atribut pa je opredeljen kot razločevalen (unique)
 ...
DELETE
Stavek DELETE izbriše eno ali več vrstic tabele. Uporabljamo ga za:
 brisanje vseh vrstic tabele
DELETE FROM ime_tabele;
 pogojno brisanje vrstic tabele
DELETE FROM ime_tabele WHERE pogoj;
Opomba: pogoj se lahko nanaša tudi na vrednosti atributov neke druge tabele. V tem
primeru sledi gnezdeni stavek SELECT.

Beležke

Zbirke podatkov 1
154

Primer stavka DELETE, ki izbriše vse vrstice tabele Obiskuje:

DELETE FROM Obiskuje;
Primer stavka DELETE, ki izbriše podatke o dijakih iz razreda G2A:
DELETE FROM Dijak WHERE Dijak.Razred='G2A';
Primer stavka DELETE, ki izbriše podatke o obiskih krožka PHP - brišemo zapise tabele
Obisk, pogoj pa se nanaša na tabelo Krožek.
DELETE FROM Obisk WHERE Obisk.KrozekID IN (SELECT Krozek.KrozekID
WHERE Krozek.ImeKrozka='PHP');
Stavek DELETE ne uspe, če:
 brišemo zapis starševske tabele in hkrati obstaja zapis v tabeli otrok, tip
referencialne integritete pa je nastavljen na ‘prohibit' oz 'no action'.
UPDATE
Stavek UPDATE posodobi vrednost enega ali več atributov tabele. Uporabljamo ga za:
 posodabljanje vrednosti atributa v vseh vrsticah tabele
UPDATE ime_tabele SET ime_atributa = nova_vrednost, ...;
 pogojno posodabljanje vrednosti atributa tabele
UPDATE ime_tabele SET ime_atributa = nova_vrednost, ... WHERE pogoj;
Opomba: pogoj se lahko nanaša tudi na vrednosti atributov neke druge tabele. V tem
primeru sledi gnezdeni stavek SELECT.
Primer stavka UPDATE, ki priimke dijakov prestavi v velike črke:
UPDATE Dijak SET Dijak.Priimek=UPPER(Dijak.Priimek);
Stavek UPDATE ne uspe, če:
 pride do podvajanja vrednosti primarnega ključa tabele,
 vrednost neopcijkih atributov nastavljamo na NULL,
 se tip atributa in vrednost ne ujemata,
 vpisujemo vrednost tujega ključa, ki v starševski tabeli ne obstaja,
 vrednost atributa že obstaja, atribut pa je opredeljen kot razločevalen (unique),
 posodabljamo zapis starševske tabele in hkrati obstaja zapis v tabeli otrok, tip
referncialne integritete pa je nastavljen na ‘prohibit' oz. 'no action'
 prihaja do kršitve katerekoli druge integritetne omejitve (CHECH, IN, ....).

Zbirke podatkov 1
 155

POIZVEDBE S PRIMER ELEMENTI (QBE)

Prava moč zbirke podatkov je v tem, da lahko vidimo samo tiste podatke, ki jih potrebujemo,
urejene tako, kot to želimo. To dosežemo s pomočjo poizvedb (povpraševanj, angl. query). S
poizvedbami dobimo želene odgovore iz podatkovne zbirke.
Rezultat poizvedbe pride iz ene ali iz več medsebojno povezanih tabel. Za enkrat se bomo
omejili na eno tabelo. Pod pojmom poizvedba bomo razumeli dvoje:
 sam postopek iskanja odgovorov v podatkovni zbirki,
 rezultat tega postopka, torej podatke, ki predstavljajo odgovor na naše vprašanje.
Rezultat poizvedbe je spet neka tabela, ki vsebuje iskane podatke. Te lahko nato
pregledujemo, analiziramo. Na njihovi podlagi lahko zgradimo obrazce, poročila, grafe, lahko
pa jih uporabimo v nadaljnji poizvedbi.
V tem poglavju se bomo seznanili s poizvedbami SUZP Access.
Kaj je poizvedba?
S poizvedbami zastavljamo vprašanja o podatkih, ki so shranjeni v tabelah. Poizvedbe
moramo sestaviti na ta način, da lahko Access nedvoumno v podatkovni zbirki poišče tiste
podatke, ki predstavljajo želeni odgovor.
Ko sprožimo poizvedbo, Access prikaže novo tabelo, ki vsebuje samo tiste zapise in samo
tista polja, ki smo jih v poizvedbi zahtevali. Ko rezultat poizvedbe zapremo, ga lahko spet
prikličemo samo tako, da znova sprožimo poizvedbo.
Čeprav se to zdi nesmiselna omejitev, pa nam vendarle zagotavlja določeno mero varnosti v
smislu pravilnosti rezultatov. Podatkovna tabela, iz katere so vzeti rezultati poizvedbe, se
lahko namreč ves čas spreminja. Rezultati poizvedbe lahko zelo hitro zastarijo, saj več ne
ustrezajo podatkom v tabeli, iz katere so bili vzeti. To še posebej velja, če uporabljamo
podatkovno zbirko v omrežju računalnikov. Tam lahko več uporabnikov omrežja vsa s
svojega računalnika dostopa do podatkovne tabele in spreminja njeno vsebino. Zato nima
smisla rezultatov poizvedbe shranjevati, bolje je zmeraj znova tvoriti nove.
Primer je rezervacija letalskih vozovnic. V neko turistično agencijo pride stranka, ki želi
rezervirati sedež na letalu. Uslužbenec na računalniku požene poizvedbo, ki iz podatkovne
zbirke poišče podatke o prostih mestih na tem letalu, nakar vpiše rezervacijo. Pomembno je,
da ima na razpolago povsem sveže podatke, saj poizvedba izpred ene minute morda ne
vsebuje več pravilnega stanja (lahko je v tej eni minuti nekdo nekje rezerviral prav ta sedež).
Pri uporabi poizvedb lahko izvajamo naslednje:

Beležke

Zbirke podatkov 1
156

 Izbor želenih polj (projekcija). V rezultat poizvedbe nam ni treba vključiti vseh polj
iz tabele, na kateri sloni poizvedba. Na primer, ogledamo si lahko samo imena in
telefonske številke naših strank, brez naslovov in drugih polj.
 Omejimo nabor zapisov (filter). Določimo pogoje, ki jim morajo zadostovati zapisi,
da bi bili vključeni v rezultat poizvedbe. Na primer, želimo videti podatke samo za
osebe, ki se pišejo Krajnc, so iz določenega kraja ipd.
 Razvrstimo zapise v rezultatu (sort). Na primer, lahko vidimo seznam naših
partnerjev v Avstriji urejen po abecednem redu, ali pa po naraščajočem obsegu
prometa.
 Uporabljamo lahko več tabel v eni poizvedbi. Pri tem se v začasni tabeli, ki je
rezultat poizvedbe, pojavijo le tista polja, ki jih želimo, prav tako pa podatki le iz
tistih zapisov v posameznih tabelah, ki ustrezajo omejitvam, ki jih postavimo.
 Izračunavamo vsote. Nad podatki v tabeli lahko izvajamo izračune. Na primer,
lahko izračunamo vsoto prodaje po osebah ali kakšen drug izračun.
 Spreminjamo podatke. Lahko ustvarimo poizvedbo, kjer na podlagi vpisanih
kriterijev dodajamo, brišemo ali popravljamo podatke.
 Tvorimo obrazce in poročila na podlagi rezultatov poizvedb. Več o obrazcih in
poročilih bomo izvedeli v naslednjih poglavjih. Če obrazec ali poročilo temelji na
poizvedbi, se vsakič, ko prikličemo katerega od teh dveh elementov samodejno
izvrši poizvedba.
 Uporabimo rezultate poizvedb v nadaljnjih poizvedbah. Ko sestavimo
poizvedbo, lahko na rezultat te poizvedbe navežemo naslednje poizvedbe. Včasih
bo ena poizvedba preveč kompleksna ali morda ne bo možno do rezultata priti v
enem koraku. V takem primeru si pomagamo s kakšno vmesno poizvedbo.
Zaganjamo seveda samo končni rezultat (poizvedbo).
 Na podlagi poizvedb lahko tvorimo grafikone in vrtilne tabele.

Uporaba poizvedb
Ustvarjanje nove poizvedbe
Tvoriti poizvedbo pomeni, da določimo pogoje, na podlagi katerih se iz neke tabele izberejo
podatki in se prenesejo v novo začasno tabelo.

Zbirke podatkov 1
 157

Postopek:
 Izberemo kartonček Poizvedbe (Queries) in gumb Nov (New).
V notranjosti okna se pojavi spisek vseh poizvedb, ki smo jih do sedaj ustvarili v okviru te
podatkovne zbirke. Povedali smo, da rezultatov poizvedbe ne moremo shraniti, da so le v
začasni tabeli. Lahko pa seveda shranimo definicijo same poizvedbe, in prav spisek teh
definicij se sedaj pojavi v spisku znotraj okna.
Odpre se novo okno s spiskom vseh tabel in poizvedb, ki so v tej zbirki podatkov. Med
tabelami in poizvedbami izbiramo s kartončki Tables (tabele), Queries (poizvedbe) in Oboje
(Both). Zraven seznama tabel ali poizvedb sta gumba Dodaj (Add) in Zapri (Close).

Kliknemo po tabeli ali poizvedbi, na podlagi katere želimo tvoriti poizvedbo, ter kliknemo
gumb Dodaj (Add).
Na ta način lahko izberemo več tabel ali poizvedb. Poizvedba namreč lahko temelji tudi na
več kot eni tabeli hkrati. Mi se bomo zaenkrat omejili na poizvedbe na eni tabeli.
Znajdemo se v oknu za določanje lastnosti poizvedbe.

Beležke

Zbirke podatkov 1
158

Na vrhu okna je okence, v katerem so navedena polja tabele, na katerih bo temeljila ta

poizvedba. Teh okenc je lahko več, če imamo opravka z več tabelami. Spodaj je mreža, v
kateri določamo lastnosti poizvedbe. Med zgornjim in spodnjim delom je ozek rob, ki ga
lahko z miško premaknemo gor ali dol, ter si tako napravimo več prostora za tabele, ali pa za
določanje lastnosti poizvedb.
Mrežo v spodnjem delu okna lahko razumemo kot neke vrste tabelo. Premikanje po tej tabeli
poteka tako, kot smo se že naučili.
Sedaj je potrebno dodati v mrežo vsa polja, ki se naj pojavijo v rezultatu poizvedbe.
Prva vrstica v mreži nosi naziv Polje (Field). V to vrstico dodamo vsa polja iz originalne
tabele, ki naj se pojavijo v rezultatu poizvedbe. V mrežo vpišemo le tista polja, ki naj se
pojavijo v rezultatu. Če imamo v tabeli na primer seznam poslovnih partnerjev z vsemi
podatki, želimo pa dobiti seznam, ki bo vseboval le njihova imena in telefonske številke, bi
dodali le polja Ime, Priimek in Telefon, ter s tem ustvarili projekcijo tabele.
Polje lahko dodamo v mrežo na več načinov.
Pregled rezultatov poizvedb
Spomnimo se, da smo imeli pri tabelah dva možna prikaza tabele: načrtovalni in podatkovni.
Ta dva prikaza imamo tudi pri poizvedbah. Do sedaj smo se ukvarjali z načrtovalnim
prikazom, saj smo določali lastnosti tabele, ki bo rezultat poizvedbe.
Preklop v podatkovni pregled pomeni, da Access izvrši preiskovanje tabele na podlagi pravil
in pogojev, ki smo jih postavili v načrtovalnem prikazu poizvedbe, in prikaže tabelo, ki
vsebuje rezultate.
Preklop med načrtovalnim in podatkovnim prikazom izvršimo enako kot smo to spoznali v
poglavju o tabelah.
Postopek:
 Pogled (View) ukaz Pogled podatkovnega lista (Datasheet View).
Prikaže se tabela v podatkovnem prikazu, kjer vidimo podatke. Tabela vsebuje samo tista
polja in samo tiste zapise, ki smo jih določili s pogoji v načrtovalnem načinu.
Tabela je po strukturi enaka kot tiste, ki smo jih spoznali v poglavju o tabelah. To je neke
vrste tabela, le da smo njeno strukturo določili posredno, preko poizvedbe.
Povedali smo že, da tabele, ki je rezultat poizvedbe, ne shranjujemo. Okno preprosto
zapremo, ko ga več ne potrebujemo. Če želimo rezultate poizvedbe ponovno videti,
preprosto ponovno zaženemo poizvedbo in dobimo najnovejše rezultate.

Zbirke podatkov 1
 159

Samo definicijo poizvedbe pa seveda shranimo, saj bomo poizvedbe z istimi karakteristikami
zelo verjetno še kdaj izvajali. Kako se to stori, bomo še spoznali.
Izbor med tem, ali želimo videti poizvedbo v podatkovnem ali načrtovalnem prikazu, lahko
opravimo, še preden tabelo odpremo.
Postopek:
 Kliknemo gumb Poizvedbe (Queries).
 Kliknemo po imenu poizvedbe, ki jo želimo odpreti.
 Če želimo vstopiti v načrtovalni prikaz, kliknemo Načrt (Design), če pa želimo
podatkovni prikaz, kliknemo Odpri (Open).
Opozorilo! Če v tabelo, ki je rezultat poizvedbe, vpisujemo ali v njej popravljamo podatke, se
spremembe odražajo tudi v originalni tabeli, ki je osnova za poizvedbo.
Če dodajamo zapise, se ti dodajo tudi v originalno tabelo. Vendar, če je število polj v
podatkovnem prikazu poizvedbe manjše od števila polj v originalni tabeli, bodo ostala
določena polja dodanih zapisov v originalni tabeli prazna.
Shranjevanje, odpiranje in tiskanje poizvedb
Shranjevanje in odpiranje poizvedb
Na disk shranjujemo definicijo poizvedbe, ne pa tudi rezultatov poizvedbe. Postopki za
odpiranje in shranjevanje poizvedb so analogni tistim, ki smo jih spoznali pri tabelah.

Tiskanje rezultata poizvedbe

Zapise, ki se pojavijo kot rezultat poizvedbe lahko natisnemo. Čeprav tiskanje same tabele,
ki je rezultat poizvedbe ne nudi toliko možnosti kot poročilo, pa je zelo hiter način za
pridobitev rezultatov na papirju.
Poizvedbe lahko tiskamo samo v podatkovnem prikazu.

Spreminjanje poizvedbe
Ko smo določili polja v načrtovalnem pogledu poizvedbe, jih lahko naknadno preurejamo,
brišemo ali dodajamo.

Določanje urejenosti zapisov (sortiranje)

Seveda pogosto želimo, da so zapisi v rezultatu poizvedbe urejeni po nekem vrstnem redu
(abecednem, številskem ali datumskem).
V primeru, da imamo v prikazu večje število polj, pa mnogokrat želimo podatke še dodatno
razvrstiti. Govorimo torej o večnivojskem razvrščanju.

Beležke

Zbirke podatkov 1
160

Najlažje si bomo predstavljali smisel večnivojskega razvrščanja na primeru klasičnega

telefonskega imenika v papirnati obliki. Kadar iščemo nekega naročnika, ga najdemo
relativno hitro samo po zaslugi reda razvrščanja: podatki so v najširšem smislu urejeni po
omrežnih skupinah, znotraj vsake omrežne skupine po abecednem redu krajev (z izjemo
glavnega kraja neke omrežne skupine, ki se nahaja na začetku le te) in šele znotraj vsakega
kraja so podatki razvrščeni po priimkih. Če obstaja več oseb z istim priimkom, so te nadalje
razvrščene po imenih in čisto nazadnje še po naslovih. Opravka imamo torej s 5-nivojskim
razvrščanjem.
V Accessu lahko uporabimo za razvrščanje poljubno mnogo nivojev oziroma toliko, kot je
polj. Seveda nastopi še vprašanje smiselnosti. Če sortiramo na prvem nivoju po npr. šifrah, ki
so unikatne za vsak zapis posebej, do ostalih nivojev razvrstitveni red sploh ne pride. Lahko
torej posplošeno rečemo, da višji kot je nivo sortiranja posameznega polja, tem manj
različnih podatkov naj nastopa v njem.
Oglejmo si primer!

Prikazovanje in skrivanje polj

Sedaj moramo še določiti, ali se bodo v poizvedbi pojavila res vsa polja, ki jih imamo v oknu
za določanje pogojev, ali pa le določena med njimi. Določena od polj smo morda uvrstili v
mrežo le zato, ker želimo na njega vezati kakšen pogoj, ne želimo pa, da bi se to polje
pojavilo v rezultatu. Katera polja bomo prikazali, določimo tako.

Premikanje polja
Premaknemo lahko eno ali več polj hkrati.

Vrivanje polja
Iz spiska polj izberemo polje, ki ga bomo vrinili. Povlečemo polje iz spiska v mrežo na tisto
mesto, kamor ga želimo postaviti.
Polje, ki je na mestu, kamor želimo vriniti novega, se bo umaknilo v desno, skupaj z njim pa
seveda tudi vsa polja, ki ležijo desno od njega.

Brisanje polja
Polje odstranimo iz načrta poizvedbe tako.

Določanje pogojev
Z dosedanjimi postopki smo omejili zgolj izbor polj, ki se naj pojavijo v rezultatu poizvedbe.
Na ta način je tabela, ki je rezultat poizvedbe le ožja, ni pa nič krajša, saj se v rezultatu
pojavijo vsi zapisi. Če smo v poizvedbe dodali vsa polja, bomo dobili kot rezultat originalno
tabelo, na kateri temelji poizvedba.
Sedaj se bomo naučili filtrirati ali omejevati zapise, ki se pojavljajo v rezultatu. Rezultanta
tabela bo na ta način krajša, saj se bodo pojavili le zapisi, ki ustrezajo določenim pogojem.
Postopek:
 Postavimo se v celico v vrstici z napisom Pogoji (Criteria) v stolpcu, ki pripada
polju, na katerega želimo vezati pogoj.
 Vpišemo pogoj.
Na primer, če želimo v rezultatu poizvedbe le vse tiste zapise, ki vsebujejo podatke o
Krajncih, bomo v vrstico Pogoji (Criteria) stolpca Priimek vpisali "Krajnc".

Zbirke podatkov 1
 161

 Postopek ponavljamo, dokler ne postavimo pogojev za vsa tista polja, za katera naj
veljajo omejitve.
Med omejitvami v posameznih stolpcih velja veznik logični IN (AND). To pomeni, da če
polje Priimek omejimo na "Krajnc", polje Ime pa na "Janez", bo Access v rezultat
poizvedbe vpisal samo tiste zapise, ki imajo v polju Ime vpisano "Janez" in hkrati v
polju Priimek vpisano "Krajnc". Ne bo našel na primer Igorja Krajnca, ker v njegovem
zapisu v polju ime ne piše "Janez". Iz podobnega razloga tudi ne bo vključil Janeza
Kovača.
Pogoj najpogosteje ni le preprosta beseda ali številka, temveč so pogoji običajno bolj
kompleksni. Access nam pri določanju pogojev omogoča veliko mero svobode. Oglejmo si
nekaj načinov za določanje pogojev:
 Vrednost v pogoju natanko ustreza iskani vrednosti. V tem primeru v celico pogoja
preprosto vpišemo vrednost, ki jo mora vsebovati polje v zapisu, da bo zapis
vključen v rezultat poizvedbe. Če v celico pogoja polja prodaja vpišemo 300, bo
Access v rezultat vključil vse zapise, ki imajo v tem polju vrednost 300, ne pa tudi
3000 ali 1300. Če bo v polju starost pisalo 25 in v polju Ime vrednost "Ignac", bo
Access našel vse Ignace, ki so stari 25 let.
 Vrednost v pogoju je vsebovana v iskani vrednosti. To pomeni, da želimo v
rezultatu na primer vse zapise, ki v nekem polju vsebujejo črko X. V tem primeru
uporabimo operator LIKE. Naš primer bi se lahko glasil LIKE "*X*". Pomeni: poišči
vse zapise, ki v tem in tem polju vsebujejo vrednost, ki se začne poljubno, nekje
znotraj vsebuje črko X, in se konča poljubno. Če bi v polju Država postavili pogoj
LIKE "B*", bi s tem dobili zapise, ki imajo v tem polju Belgija, Brazilija, Burundi ipd.
Vidimo, da se operator LIKE uporablja v povezavi z nadomestnimi operatorji.
Uporabimo lahko nadomestna operatorja zvezdico in vprašaj. Nadomestne
operatorje lahko uporabljamo pri poljih, ki vsebujejo tekst ali datum.
► operator “*”: pomeni karkoli, torej nič, en znak ali zaporedje poljubnih znakov.
► operator “?”: pomeni katerikoli, a obvezno en (1) znak. Npr.: m??a lahko vrne
rešitve, kot so miza, Miha, mama, ne pa tudi Metka, Mia.
 Iskana vrednost je večja, manjša ali enaka od vrednosti v pogoju. Recimo, da
želimo poiskati vse prodajalce, ki imajo prodajo strogo manjšo od 300 denarnih
enot. V tem primeru bi na primer v polje Prodaja vpisali vrednost <300. Na podoben
način lahko uporabljamo primerjalne operatorje:
< (strogo manjše)
<= (manjše ali enako, največ, kvečjemu)
> (strogo večje)
>= (večje ali enako, najmanj, vsaj)
Beležke

Zbirke podatkov 1
162

= (enako)
<> (različno)
 Iskana vrednost je med dvema vrednostma v pogoju. Želimo najti vse prodajalce, ki
so prodali med 100 in 300. V polje Prodaja bi vpisali izraz Between 100 And 300, in
je ekvivalenten izrazu >=100 And <= 300.
 Iskanje praznega polja. Želimo najti vse zapise, kjer manjka npr. datum rojstva. V
polje DatRoj bi kot pogoj vpisali Is nič (Is null).
Kompleksnejši pogoji v poizvedbah
Sestavljeni pogoji za eno polje
Do sedaj smo spoznali pogoje, ki omejujejo vrednost polja samo na en način. Lahko pa tudi
določimo pogoje, ki z več strani omejujejo vrednost polja, prav tako pa lahko en pogoj
vključuje več polj. Z uporabo sestavljenih pogojev lahko na primer najdemo vse artikle, ki
imajo cene višje od 50 EUR in hkrati nižje od 100 EUR, ali pa so naročeni po 1.10.2005 in
imajo ceno višjo od 75 EUR.
Sestavljeni pogoji so sestavljeni iz enostavnih pogojev, ki smo jih spoznali v poglavju o
enostavnih poizvedbah. Enostavni pogoji so povezani z operatorjema IN (AND) ter ALI (OR).
Operatorjev OR in AND ne smemo razumeti kar tako, pavšalno. Slovenski jezik ni nujno
primeren za natančno matematično izražanje, zato je treba zmeraj temeljito premisliti, kateri
operator bomo uporabili.

Operator AND
Operator AND uporabimo, če želimo določiti več omejitev za eno samo polje. Pogoj, ki je
vsebuje operator AND “uspe” samo v primeru, če neki vrednosti ustrezata oba pogoja, ki sta
med samo povezana z operatorjem AND.
Primer:
Če iščemo podatke o prodaji v prvi polovici leta 2006, bi v polje Datum_naročila vpisali pogoj:
>=1.1.06 And <=30.6.06
Torej ko uporabimo operator AND, prikažemo tiste zapise, ki ustrezajo vsem naštetim
pogojem HKRATI.

Zbirke podatkov 1
 163

Operator OR
Če mora podatek v polju ustrezati vsaj enemu od pogojev, uporabimo operator OR. Pogoj, ki
je vsebuje operator OR “uspe” že v primeru, če neki vrednosti ustreza vsaj eden od pogojev,
ki sta med seboj povezana z operatorjem OR.
Z uporabo operatorja OR, prikažemo tiste zapise, ki ustrezajo vsaj enemu od naštetih
pogojev.
Primer:
 Za izpis vseh oseb, ki so iz Ljubljane ali Maribora, bi v Kraj vpisali pogoj:
“Ljubljana” Or “Maribor”
Dobili bi vse Ljubljančane in Mariborčane. Vsaka od oseb je lahko jasno samo iz enega od
krajev, ker polje Kraj za neko osebo ne more hkrati vsebovati imen obeh mest.
 Če hočemo izpisati vse osebe, ki predstavljajo ekstreme v opravljenih delovnih
urah v nekem mesecu, bi v polje Št_ur vpisali pogoj:
<100 Or >200
Kot rezultat bi dobili vse osebe, katerih število opravljenih ur ne presega 100 ur, in še vse
tiste, ki imajo več kot 200 ur. To seveda ne more biti ista oseba, saj ima nekdo lahko samo
eno vrednost – take, ki pa bi ustrezala obema pogojema, pa ni. Uporaba operatorja And
namesto Or bi vedno povzročila prazen rezultat.
Paziti moramo na pravilno interpretacijo med naravnim jezikom in matematično logiko. Če
nam nekdo postavi zahtevo: "Poišči vse o Igorju in Gregorju", to ne pomeni, da bomo
uporabili operator AND (in), čeprav se v izrečeni zahtevi pojavi prav ta besedica. Pogoj "Igor"
And "Gregor" v polju Ime nima smisla, saj eno polje ne more hkrati vsebovati obeh vrednosti!

Operator NOT
Včasih potrebujemo izpis vseh podatkov razen enega. V takih primerih uporabimo operator
NOT, ki iz rezultata izvzame vrednost, ki sledi temu operatorju. Gre torej za čisto negacijo
izbranega pogoja, prioriteta operatorja NOT pa je višja od prioritet operatorjev AND ali OR.
 Potrebujemo podatke o osebah, ki niso iz Celja. V polje Kraj vpišemo pogoj:
Not “Celje”
 Če pa želimo dodatno izključiti iz zgornjega rezultata (torej poleg Celja) tudi vse kraj
Novo mesto, bi v polje Kraj vpisali enega od spodnjih pogojev:
Not “Celje” And Not “Novo mesto”
ali

Beležke

Zbirke podatkov 1
164

Not ( “Celje” Or “Novo mesto” )

Sestavljeni pogoji za več polj
Podobno kot za eno polje lahko določamo sestavljene pogoje, ki povezujejo dve ali več polj.
Morda želimo poiskati npr. podatke o vseh zaposlenih pravnikih, ki jim je ime Marko. Oba
pogoja morata biti povezana z operatorjem IN (AND).
Če pa želimo najti vse zaposlene po imenu Marko ali pa so po poklicu pravniki, bi uporabili
pogoj ali (or). V tem primeru bi našli tudi vse tiste zaposlene pravnike, ki jim ni ime Marko in
vse Marke, za katere ni nujno, da so pravniki. Skratka, izpustili bi samo vse tiste, ki jim niti ni
ime Marko, niti niso pravniki.
Ob določanju sestavljenih pogojev za več polj si zapomnimo naslednje: če iščemo zapise, ki
ustrezajo pogojema (ali več pogojem), povezanima z operatorjem in, vpišemo oba pogoja v
isto vrstico mreže Pogoji (Criteria). Če pa iščemo zapise, ki ustrezajo pogojema povezanima
z operatorjem ali, vpišemo pogoje v različne vrstice mreže.
Najlažje bomo to razumeli na primerih.
Primeri:
Iskanje zaposlenih z imenom Marko in poklicem PRA.

Primer za vse zaposlene po imenu Marko ali zaposlene pravnike.

Zbirke podatkov 1
 165

Oglejmo si še nekoliko kompleksnejši primer iz zbirke podatkov, ki vsebuje podatke o

poslovnih partnerjih: želimo dobiti seznam vseh po priimkih razvrščenih oseb, ki so rojene
pred letom 1965 oziroma (ali) imajo vsaj 15 let delovne dobe, v nobenem primeru pa ne živijo
v Celju (recimo zaradi morebitne tamkajšnje konkurence).

Beležke

Zbirke podatkov 1
166

Uporaba izračunljivih polj

Pri dodajanju polj v poizvedbo nismo omejeni zgolj na polja v tabelah ali poizvedbah, na
katerih temelji naša poizvedba. Ustvarimo lahko nova polja, ki izračunavajo nove podatke za
vsak zapis posebej. Seveda pa je treba povedati, da se podatki v takih poljih dejansko ne
shranjujejo, saj bi to bila potrata prostora in večja možnost neažurnosti podatkov. Vsakič, ko
prikažemo rezultat poizvedbe, se izračunljiva polja na novo preračunajo, tako da je njih
vsebina vedno sveža.
Izračunljivo polje ustvarimo v poljubnem praznem stolpcu v mreži poizvedbe in je sestavljeno
iz imena in izraza, kar zapišemo takole:
ImePolja: Izraz
pri čemer je ImePolja poljubno novo ime, Izraz pa matematično zapisan računski izraz, v
katerem se lahko sklicujemo tudi na polja iz tabele.
Pri sklicevanju na polja iz tabel uporabljamo oglate oklepaje!
Na primer v poizvedbi, ki vsebuje polji Cena enote in Količina, lahko ustvarimo polje po
imenu ZnesekDDV. Izraz, ki ga vpišemo v to polje se glasi:
ZnesekDDV: [Cena enote]*[Količina]*1,2
V izračunanih poljih lahko tudi kombiniramo vsebine dveh tekstovnih polj. Na primer, če
imamo zapisan naslov v dveh ločenih poljih Ulica in Hišna številka, lahko tako ustvarimo
novo polje Naslov. Presledek (obvezno v narekovajih) med obema poljema v izrazu je
pomemben, saj nam sicer združi oba niza tik za drugim:
Naslov: [Ulica] & “ “ & [Hišna številka]
Izračunljiva polja so lahko vsekakor izredno koristna lastnost poizvedb, saj nam zagotavljajo
ažurnost podatkov, ki so vsebina takih polj. Vsakič ko zaženemo poizvedbo, se ti izračuni
osvežijo. Same vrednosti rezultatov seveda niso shranjene, ker poizvedba že po definiciji
pomeni zgolj napotek za prikaz podatkov, ki se fizično nahajajo v tabeli.
Za izračunljiva polja lahko uporabljamo tako poljubne matematične operatorje kot tudi
funkcije, ki so na voljo v Accessu. Oglejmo si nekaj zanimivejših!
Funkcije
Access ima že vgrajeno obsežno zbirko raznovrstnih funkcij, ki nam omogočajo, da pridemo
do želenega rezultata. Zavedati pa se moramo nekaterih pravil:

Zbirke podatkov 1
 167

 Vsaka funkcija je sestavljena iz imena, oklepajev in argumentov. Argumenti so

parametri ali vhodni podatki funkcije, ki so potrebni za izvršitev njenega namena.
Vrsta in število argumentov se razlikuje za posamezne funkcije. Če je argumentov
več, jih medsebojno ločimo s podpičjem (;):
ImeFunkcije(argument_1; argument_2; … ; argument_n)
 Kot argument funkcije lahko nastopa tudi vrednost polja iz tabele ali celo neka
druga funkcija. Slednjemu pravimo gnezdenje funkcij. Seveda mora rezultat
vgnezdene funkcije ugovarjati vrsti zahtevanega argumenta.
Year([datum rojstva])  1956
Year(Date())  2007
 Rezultat neke funkcije je lahko besedilo (“Tekst“), število (13), datum (#17.5.00#) ali
logični sklep (TRUE ali FALSE).
V spodnji tabeli je naštetih nekaj uporabnejših funkcij z opisom in primerom.
Funkcija Opis Primer
Date() izpiše trenutni datum Date()  17.2.07
Year(datum) izpiše letnico vpisanega datuma Year(17.2.07)  2007
Month(datum) izpiše številko meseca vpisanega Month(17.2.07) 2
datuma
Day(datum) izpiše številko dneva vpisanega Day(17.2.07)  17
datuma
DateSerial(l; m; d) pretvori števila l (leto), m (mesec) DateSerial(2006; 11; 2)  2.11.06
in d (dan) v datumski zapis
Left(besedilo; n) izpiše prvih n znakov besedila Left(“Kovač”;2)  “Ko”
Right(besedilo; n) izpiše zadnjih n znakov besedila Right(“Kovač”;2)  “ač”
Mid(besedilo; m; n) izpiše od m-tega znaka besedila n Mid(“Kovač”;2;3)  “ova”
znakov
Ucase(besedilo) pretvori besedilo v velike črke Ucase(“Kovač”)  “KOVAČ”
Lcase(besedilo) pretvori besedilo v male črke Lcase(“Kovač”)  “kovač”
Len(besedilo) izračuna število znakov vpisanega Len(“Kovač”) 5
besedila
Val(besedilo) pretvori besedilo v število; če to ni Val(“13”)  13
mogoče, vrne 0 Val(“Kovač”) 0
Round(število;št.dec) zaokroži število na določeno Round(133,524;2)  133,52
število decimalnih mest

Beležke

Zbirke podatkov 1
168

Funkcija Opis Primer

Sqr(število) izračuna kvadratni koren števila Sqr(49) 7
Iif(pogoj; vrednost1; če pogoj drži, se izvrši/izpiše Iif(Date()>#15.11.99#; “rok pretekel”;
vrednost2) vrednost1, sicer vrednost2 “še je čas”)  “rok pret.”
Seveda je takih funkcij še veliko, čeprav se lahko s kombinacijo zgornjih reši marsikateri
problem. Oglejmo si nekaj pogostejših!

Poizvedba s parametrom
Access ponuja še eno zanimivost pri izdelavi poizvedb, in sicer poizvedbe s parametrom.
Zamislimo si primer, ko pogosto potrebujemo eno in isto strukturo poizvedbe, le da se
vrednost pogoja (kriterija) spreminja. Recimo, da želimo izpisovati osebne podatke o
zaposlenih, vendar enkrat iz Ljubljane, drugič iz Maribora, tretjič spet iz Ljubljane itn. Ena
možnost je, da vsakokrat popravimo vrednost pogoja v mreži poizvedbe, a obstaja lažja pot!
Namesto da bi v mreži poizvedbe vpisali konkretno vrednost pogoja, vpišimo na tem mestu v
oglatih oklepajih nek komentar (kot napotek), ki se bo pojavil, ko bomo zagnali poizvedbo.
Access bo ob tem zahteval, da vpišemo dejansko vrednost pogoja in izvršil poizvedbo.
 Ustvarimo poizvedbo in vstavimo ustrezna polja na mrežo.
 Postavimo se v vrstico Pogoji (Criteria) pod poljem, na katerega vežemo pogoj.
 V oglatih oklepajih vpišemo komentar (poljubno besedilo, ki pa ne sme biti enako
imenu polja iz tabele).

 Ko želimo videti rezultat poizvedbe, Access od nas zahteva vrednost parametra.

Komentar, ki smo ga predhodno vpisali v mrežo poizvedbe, se sedaj pojavi nad vnosnim poljem,
v katerega vpišemo dejansko vrednost pogoja.

Vpisana vrednost ima enak pomen, kot če bi jo predhodno vpisali v mrežo. Izboljšava je v
tem, da imamo ob ponovnem priklicu take poizvedbe možnost vnosa drugačne vrednosti
pogoja, pri tem pa nam ni treba posegati v konstrukcijo poizvedbe. Ob parametru lahko
vpisujemo operatorje, jih kombiniramo z ostalimi pogoji, uporabljamo v izračunljivih poljih.
Npr. vpišemo like [Vpiši kraj], lahko kot parameter vnesemo L* in dobimo vrnjene vrednosti.

Kalkulacije nad skupinami podatkov (grupiranje)

Pogosto želimo poiskati sumarne rezultate za podatke v tabeli. Kakšna je skupna vrednost
naročil v tem mesecu? Kakšna je povprečna cena vseh naših produktov? Kolikšni sta
največja in najmanjša delovna doba zaposlenih po posameznih poslovalnicah?

Zbirke podatkov 1
 169

S pomočjo poizvedb lahko izvajamo kalkulacije nad skupinami podatkov. V naslednji tabeli
so prikazane operacije, ter nad katerimi tipi podatkov jih lahko uporabljamo.
Če želimo poiskati oz. izračunati: uporabimo operacijo – veljavni
tipi podatkov:
vsoto vrednosti v polju SUM - Nm, ANm, Cr, DT, YN
povprečje vrednosti v polju AVG - Nm, ANm, Cr, DT, YN
najnižjo vrednost v polju MIN - Nm, ANm, Cr, DT, YN
najvišjo vrednost v polju MAX - Nm, ANm, Cr, DT, YN
število vrednosti v polju (ne šteje praznih celic) COUNT - Nm, ANm, Cr, DT, YN, Tx, Mm
standardno deviacijo v polju STDEV - Nm, ANm, Cr, DT, YN
varianco podatkov v polju VAR - Nm, ANm, Cr, DT, YN
vrednost v prvem zapisu tabele ali poizvedbe FIRST - Nm, ANm, Cr, DT, YN, Tx, Mm
vrednost v zadnjem zapisu tabele ali poizvedbe LAST - Nm, ANm, Cr, DT, YN, Tx, Mm
Legenda: Nm (Number), ANm (AutoNumber), Cr (Currency), DT (Date/Time), YN (Yes/No), Tx
(Text), Mm (Memo)

Izračunavanja nad vsemi zapisi v tabeli

Z uporabo kalkulacij v poizvedbah lahko poiščemo sumarne podatke za vse zapise v tabeli.
Na primer, lahko poiščemo število naših partnerjev, ki imajo sedež v ZDA, ali pa izračunamo
povprečno ceno vseh naših izdelkov.
Sumarne podatke za vse zapise v tabeli izračunamo tako.
 Ustvarimo poizvedbo in vpišemo ustrezna polja v mrežo.

 Kliknemo gumb v orodjarni, ali pa sprožimo ukaz Pogled|Skupaj

(VIEW|TOTALS).
V mreži se pojavi nova vrstica, z imenom Pogled|Skupaj (View|Total). V vseh
celicah v tej vrstici je vpisano "Združi po (Group By)".
 Pod vsakim poljem v vrstici Skupno (Total) določimo operacijo za izračun
sumarnih rezultatov (Vsota, Povprečje, Min,...)
Ker izračunavamo sumarne rezultate za vse zapise v tabeli, ne sme biti pod
nobenim poljem vpisano Združi po (Group By).

 Kliknemo gumb in si ogledamo rezultat.

V rezultatu poizvedbe Access posameznim stolpcem podeli ustrezna opisna
imena, kot na primer VsotaOdPlača, PovprečjeOdPlača.

Beležke

Zbirke podatkov 1
170

Izračunavanja nad skupinami zapisov

Pogosto želimo izvajati zgoraj omenjene kalkulacije nad skupinami zapisov, in ne nad vsemi
zapisi v tabeli. Na primer, izračunati želimo število izdelkov v vsaki kategoriji.
Ko tvorimo poizvedbe, določimo, na podlagi katerih polj se bo izvršilo grupiranje zapisov. To
polje ima v vrstici Skupno (Total) vpisano Združi po (Group By). Ostala polja pa imajo
vpisano ime operacije, ki naj se izvrši nad podatki v vsaki posamezni skupini.

 Kliknemo gumb ali sprožimo ukaz Pogled|Skupaj (View|Totals).

V mreži se pojavi vrstica Skupno (Totals), ki ima v vseh celicah vpisano Združi
po (Group By).
 Izberemo operacijo za sumarni izračun za polja, nad katerimi izračunavamo.
Vsakemu polju v mreži določimo funkcijo ali pa Združi po (Group By).

 Kliknemo gumb ter si ogledamo rezultat.

Sumarne operacije se bodo izvršile nad zapisi v vsaki skupini posebej.
Zavedati se moramo, da nas individualni podatki o posameznih zapisih ne zanimajo več,
zato v poizvedbe ne vključujemo polj (recimo priimkov), ki jim ne moremo določiti ene od
operacij ali združevanja! Smisel združevanja podatkov je le v skupinskih izračunih.

Poizvedbe s spremembo (akcijske poizvedbe)

Včasih želimo izvesti spremembe nad večjo količino podatkov v tabeli - spremembe, ki
delujejo nad vsemi zapisi v tabeli na podoben način. Na primer, želimo povečati cene naših
izdelkov za 10 odstotkov ali preračunati cene iz tolarjev v evre. Želimo se izogniti temu, da bi
izračunavali vsako novo ceno posebej in ročno popravljali podatke. Ker izvajamo enako
spremembo na vseh zapisih, lahko Access to spremembo izvrši sam. Pravila, kako naj jo
izvrši, pa določimo v poizvedbi s spremembo (action query). V poizvedbi s spremembo lahko
ustvarjamo nove tabele, spreminjamo ali brišemo podatke v obstoječih tabelah, lahko pa jih
tudi dodajamo iz neke druge tabele. V Access-u obstajajo štiri vrste poizvedb s spremembo:
 poizvedba s spremembo, ki spremeni (ažurira) podatke v skupini zapisov (Update
Query),
 poizvedba s spremembo, ki napravi novo tabelo iz obstoječe tabele ali njenega
dela (Make-Table Query),
 poizvedba s spremembo, ki dodaja skupine zapisov iz ene v drugo tabelo (Append
Query),
 poizvedba s spremembo, ki briše določene zapise iz tabele (Delete Query).
Varnost pri uporabi poizvedb s spremembo
Zelo je priporočljivo, da pri izdelavi poizvedb s spremembo uporabljamo naslednji štiri
stopenjski postopek. Kot že ime samo pove, poizvedbe s spremembo izvajajo spremembe
na tabeli. Če je ta sprememba na primer brisanje zapisov, je potrebna skrajna previdnost, da
pomotoma ne zbrišemo ali spremenimo napačnih podatkov. Izbrisani podatki so namreč
uničeni, dejanja ni mogoče razveljaviti.
 Najprej ustvarimo običajno poizvedbo.
Ta poizvedba naj bo ekvivalentna poizvedbi s spremembo, ki jo želimo izvesti. Na
primer, če želimo zbrisati vse izdelke, ki jih umikamo iz prodaje, napravimo

Zbirke podatkov 1
 171

najprej običajno poizvedbo, ki nam bo kot rezultat dalo spisek vseh teh izdelkov.
Spisek lahko preverimo in tako vnaprej zagotovimo, da se bodo izbrisali le pravi
zapisi.
 Pretvorimo običajno poizvedbo v poizvedbo s spremembo.
Postopek pretvorbe bomo spoznali kasneje.
 Poženemo poizvedbo.
 Preverimo spremembe, izvršene nad tabelo.
Ažuriranje tabel (Update Query)
S tovrstnimi poizvedbami s spremembo lahko izvršimo spremembe nad več zapisi naenkrat.
Na primer, lahko povečamo cene določenih izdelkov za 10%, ali pa povečamo plače za 5%
vsem delavcem na določenem delovnem mestu.
Podatke v tabelah lahko seveda popravljamo neposredno v tabelah ali s pomočjo obrazcev.
S poizvedbo s spremembo pa lahko spremenimo velike količine podatkov v enem koraku, ter
pri tem obenem zmanjšamo možnost napake.
 Ustvarimo novo poizvedbo, dodamo želena polja in določimo pogoje v poizvedbi.
 Ogledamo si rezultat poizvedbe.
V rezultatu morajo biti vsebovani le tisti zapisi, nad katerimi želimo izvršiti
spremembo. Če rezultat ne ustreza našim željam, popravimo poizvedbo.
 Preklopimo v načrtovalni prikaz poizvedbe.
 Sprožimo ukaz Poizvedba|Poizvedba Za Posodabljanje (Query|Update Query).
Naziv okna s poizvedbo se spremeni v Poizvedbo za posodabljanje (Update
Query). V mrežo se doda vrstica Posodobi na (Update To).
 V poljih, ki jim želimo popraviti vrednost, vpišemo v celico Posodobi na (Update
To) novo vrednost polj ali formulo, na podlagi katere se nova vrednost izračuna. Če
se sklicujemo na imena polj, jih obvezno izpišemo v oglatih oklepajih.
Na primer, če bi v polju Kraj želeli povsod namesto “NM” izpisati “Novo mesto”, bi
za to polje v mreži poizvedbe določili kriterij “NM”, v celico Posodobi na (Update
To) pa bi vpisali “Novo mesto”.
Če bi želeli povečati cene proizvoda za 10%, bi v celico Update To vpisali
formulo: [cena enote]*1,1
 Kliknemo gumb v orodjarni ali pa sprožimo ukaz Poizvedba|Zaženi
(Query|Run).

Beležke

Zbirke podatkov 1
172

Prikaže se pogovorno okno, ki nam sporoča število vrstic (zapisov), ki bodo

spremenjene.
 Če želimo končati poizvedbo in spremeniti zapise, kliknemo Da (Yes). V
nasprotnem primeru, če ne želimo sprememb, kliknemo Ne (No).
Ustvarjanje novih tabel iz obstoječih (Make – Table Query)
Poizvedba s spremembo za tvorbo novih tabel ustvari novo tabelo iz zapisov, ki so rezultat
poizvedbe. Tako kot v običajnih poizvedbah lahko določimo polja, ki se bodo pojavila v novi
tabeli. V bistvu se tabela, ki je rezultat poizvedbe tukaj zares shrani na disk in je na
razpolago kadarkoli kasneje, ne da bi bilo treba vsakič znova izvrševati poizvedbo. Na ta
način lahko pridobimo precej časa, ki se sicer potroši za izvrševanje poizvedbe, vendar pa
tvegamo, da morda podatki ne bodo najnovejši, ker nima povezave z izvorno tabelo.
Tako poizvedbo lahko tudi koristno uporabimo, če želimo na primer poslati sodelavcu tabelo
podatkov, v katerih so zbrani samo tisti zapisi, ki njega zanimajo, in ne vseh podatkov.
 Ustvarimo običajno poizvedbo.
Pri tem lahko uporabljamo postopke, ki smo se jih naučili v poglavju o
poizvedbah.
 Ogledamo si rezultat poizvedbe.
Ko so v rezultatu podatki, ki jih želimo zapisati v novo tabelo, preidemo na
naslednji korak.
 Preklopimo nazaj v načrtovalni prikaz poizvedbe.
 Sprožimo ukaz Poizvedba|Poizvedba Za Izdelavo Nove Tabele (Query|Make-
Table Query).
Pojavi se pogovorno okno z imenom Izdelava tabele (Make Table), kjer v polju
Ime tabele (Table Name) vpišemo ime nove tabele, v katero se naj zapiše
rezultat poizvedbe. Ime nove tabele ne sme biti enako imenu kakšne že
obstoječe tabele ali poizvedbe.
 Kliknemo V redu (Ok).
Simbol, ki označuje poizvedbe v glavnem oknu podatkovne zbirke, se spremeni
na ta način, da se k običajnemu simbolu doda znak klicaj (!). Okno s poizvedbo
dobi naziv Poizvedba za izdelavo tabele (Make-Table Query).

 Kliknemo gumb orodjarni ali pa sprožimo ukaz Poizvedba|Zaženi

(Query|Run).
 Če želimo končati poizvedbo in ustvariti novo tabelo, kliknemo Da (Yes). V
nasprotnem primeru, če nove tabele ne želimo, kliknemo Ne (No).
Če želimo preveriti rezultate poizvedbe, torej novo tabelo, jo odpremo po običajnem
postopku odpiranja tabel, ki smo ga že spoznali v poglavju o tabelah.
Dodajanje zapisov (Append Query)
Ta vrsta poizvedb s spremembo, ki ga omogoča Access, služi dodajanju zapisov iz ene
tabele v drugo na podlagi vpisanih kriterijev. Na primer, če ugotovimo, da bi radi del
podatkov določene tabele kopirali na dno neke druge tabele, ki se nahaja v isti ali pa v kakšni
drugi zbirki podatkov, bomo to storili s pomočjo tovrstne poizvedbe.
 Ustvarimo novo poizvedbo, v kateri uporabimo tabelo ali skupino tabel, od koder
bomo prenašali podatke. Dodamo želena polja in določimo pogoje poizvedbe.

Zbirke podatkov 1
 173

 Ogledamo si rezultat poizvedbe.

V rezultatu naj bodo vsebovani vsi tisti zapisi, katere želimo dodati k neki drugi
tabeli. Če rezultat ne ustreza našim željam, popravimo poizvedbo.
 Preklopimo v načrtovalni prikaz poizvedbe.
 Sprožimo ukaz Poizvedba| Poizvedba Za Dodajanje (Query|Append Query).
Pojavi se okno Dodaj (Append), v katerem izberemo že obstoječo tabelo, kateri
bomo dodali zapise, ki so rezultat naše poizvedbe.
 V mreži poizvedbe se pojavi nova vrstica z imenom Dodaj v (Append To). V tej
vrstici so za vsak stolpec izbrana ustrezna polja za ciljno tabelo.
Če je kakšno polje iz osnovne tabele istoimensko nekemu polju iz ciljne tabele,
bo Access sam pripisal tako polje v vrstico Dodaj v (Append To). Sicer pa
pazimo, da bomo podatke iz polj osnovne v ciljno tabelo pravilno pripisali.

 Kliknemo gumb v orodjarni ali pa sprožimo ukaz Poizvedba|Zaženi

(Query|Run).
Prikaže se pogovorno okno, ki nam sporoča število vrstic (zapisov), ki bodo
dodane v ciljno tabelo.
 Če želimo končati poizvedbo in dodati zapise, kliknemo Da (Yes). V nasprotnem
primeru, če ne želimo sprememb, kliknemo Ne (No).
Brisanje zapisov (Delete Query)
Če želimo iz tabele odstraniti določeno število zapisov, ki vsi zadostujejo nekemu skupnemu
pogoju, je hitreje uporabiti poizvedbe s spremembo, kot pa jih brisati enega po enega. Tako
lahko na primer z eno potezo zbrišemo vse izdelke, za katere ni nobenih naročil in jih zato
umikamo iz prodaje. Pri poizvedbi za brisanje zmeraj brišemo le cele zapise, ne moremo
brisati samo določenih polj.
V večini primerov lahko brišemo zapise le iz ene tabele. Iz več tabel naenkrat lahko brišemo
le takrat, ko so povezane na način "ena-proti-ena", kar pomeni, da se nek ključen podatek iz
ene tabele pojavi tudi v vseh ostalih samo enkrat. Poglejmo kako.
 Ustvarimo novo poizvedbo in vanj dodamo vse želene tabele. V glavnem bo to ena
sama tabela.
 V mrežo premaknemo polje z zvezdico iz tabele, v kateri bomo brisali zapise.
Vsaka tabela ima svoje polje z zvezdico. Tabela "prodaja" ima na primer polje
prodaja.*
 V mrežo dodamo vsa polja iz tabele, za katere bomo določili pogoje.

Beležke

Zbirke podatkov 1
174

 Določimo vse želene pogoje in si ogledamo rezultat poizvedbe.

Zbrisani bodo vsi zapisi, ki so uvrščeni v rezultat poizvedbe. Če nam rezultat ne
ustreza, tako dolgo popravljamo poizvedbo, da dobimo želeni rezultat.
 Preklopimo nazaj v načrtovalni način poizvedbe.
 Sprožimo ukaz Poizvedba|Poizvedba Za Brisanje (Query|Delete Query).
Okno s poizvedbo dobi naziv Poizvedba za brisanje (Delete Query). V mreži se
pojavi nova vrstica Brisanje (Delete). V polju z zvezdico se v celico vpiše Iz
(From), kar označuje tabelo, iz katere bomo brisali zapise. V ostalih poljih, ki smo
jih dodali zaradi določanja pogojev, piše Kjer (Where).
 Preverimo, če so oznake Iz (From) in Kraj (Where) na pravih mestih.

 Kliknemo gumb ali pa sprožimo ukaz Poizvedba|Zaženi (Query Run).

Prikaže se pogovorno okno, ki nam sporoča število vrstic (zapisov), ki bodo
brisani.
 Če želimo končati poizvedbe in brisati zapise, kliknemo Da (Yes). V nasprotnem
primeru, če ne želimo brisanja, kliknemo Ne (No).
Če želimo preveriti rezultate, preprosto odpremo tabelo, iz katere smo brisali, ter pogledamo,
če so brisani pravi zapisi.

Zbirke podatkov 1
 175

VIRI IN LITERATURA
Literatura
 dokumentacija podjetja B2 d.o.o.
Spletni viri
 E gradiva za računalništvo in informatiko, http://colos.fri.uni-lj.si/eri/, dostopno 5.
januar, 2014
 razni spletni viri
Večji del gradiva je bil razvit v sklopu Ministrstva za šolstvo in šport RS. Ta del je prosto
dostopen v skladu z licenco »Creative Commons«.
Odklonitev odgovornosti
Kljub pazljivi izbiri vsebine, avtor ter izdajatelj ne prevzemata nobene odgovornosti za
morebitne napake in pomanjkljivosti v vsebini ter ne odgovarjata za morebitno povzročeno
škodo, ki bi nastala na podlagi uporabe vsebine tega priročnika.

Zbirke podatkov 1