2. Füüsiline disain

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Sisukord
Teema 12. Andmebaasi füüsiline disain
1.Eesmärgid.......................................................................................................2
2.Füüsiline disain...............................................................................................2
2.1Loogilise andmemudel konkreetse andmebaasisüsteemi jaoks tõlkimine
........................................................................................................................3
2.1.1Tabelite disain.....................................................................................4
2.1.2Tuletatud väärtuste esitamise disain..................................................5
2.1.3Kitsenduste (piirangute) täpsustamine ja lisamine.............................6
2.1.3.1Välisvõtmetega seotud kompenseerivad tegevused...................8
2.1.3.2CHECK kitsendused..................................................................11
2.2Füüsilise esitusviisi disain.......................................................................14
2.2.1Transaktsioonanalüüs......................................................................15
2.2.2Salvestusruumi disain.......................................................................16
2.2.2.1Andmete paigutus failides..........................................................16
2.2.2.2Failide paigutuse valimine.........................................................17
2.2.2.3Plokis lubatud vaba ruumi hulga valimine.................................17
2.2.2.4Andmebaasi suuruste hindamine..............................................18
2.2.3Indeksite valimine.............................................................................18
2.2.3.1Indeksite loomine tabeli veerule või veergudele........................19
2.2.3.2Indeksi kustutamine...................................................................20
2.2.3.3Automaatne indeksi loomine......................................................20
2.2.3.4Indeksi kasutamine....................................................................20
2.2.3.5Indeksite klassifikatsioon...........................................................21
2.2.3.6Indeksi sisemise ülesehituse viisid............................................22
2.2.3.7Lihtne tihe indeks.......................................................................23
2.2.3.8Lihtne hõre indeks......................................................................24
2.2.3.9B-puu indeks..............................................................................24
2.2.3.10Soovitused B-puu indeksi kasutamiseks.................................27
2.2.3.11B-puu indeksi täiendamine......................................................31
2.2.3.12Kahendpuu...............................................................................32
2.2.3.13Räsiväärtustel põhinev indeks.................................................33
2.2.3.14Indeksi struktuuri järgi organiseeritud tabelid..........................33
2.2.3.15Joini indeks..............................................................................36
2.2.3.16Bitmap-indeks..........................................................................37
2.2.3.17Bitmap join indeks....................................................................39
2.2.3.18Tabeli läbiskaneerimine vs. indeksi kasutamine.....................40
2.2.3.19Indekseerimise rusikareeglid...................................................41
2.2.3.20Indeksi kasutamine andmebaasisüsteemi poolt......................42
2.3Klassifikaatorite tabelid...........................................................................43
2.4Vaadete disain.........................................................................................45
2.5Julgeolekumehhanismide disain.............................................................45
3.Mõisted..........................................................................................................45
4.Kasutatud materjalid.....................................................................................46
Joonised
Joonis 1Tühjade stringide keelamine MS Accessi tabeli veerus.....................11
1

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Joonis 2Veateade MS Accessis, mis kuvatakse, kui lisada tühi string veergu,
kus see pole lubatud........................................................................................11
Joonis 3Lihtne tihe indeks...............................................................................23
Joonis 4Lihtne hõre indeks..............................................................................24
Joonis 5B-puu indeksi ülesehituse põhimõte..................................................25
Joonis 6Indeksipuu tasakaalustamine.............................................................25
Joonis 7B-puu indeksi näide............................................................................27
Joonis 8Kahendpuu näide...............................................................................32
Joonis 9Räsiväärtustel põhinev indeks...........................................................33
Joonis 10Klasterdatud indeks MS SQL Serveri näitel.....................................35
Joonis 11Joini indeks.......................................................................................36
1. Eesmärgid
1. Anda ülevaade SQL-andmebaaside füüsilisest disainist.
2. Anda ülevaade indeksitest.
2. Füüsiline disain
Disainietapi ülesandeks on analüüsi etapis väljatoodud nõuetele vastavate
tehniliste lahenduste väljatöötamine.
Eristatakse loogilist ja füüsilist disaini. Loogilisest disainist oli juttu teemas nr.
10.
Füüsiline disain optimeerib / häälestab loogilise disaini lahendusi
konkreetsete “füüsiliste” keskkondade jaoks. Füüsiliseks keskkonnaks on ka
andmebaasisüsteem. Erinevate andmebaasisüsteemide pakutav
funktsionaalsus erineb detailides üksteisest küllaltki palju.
Sisend.
• Loogilise disaini dokumentatsioon.
• Teadmised kasutatava andmebaasisüsteemi ja rakenduse ehitamise
vahendite kohta.
Connolly ja Begg (2001) poolt esitatud metoodika põhjal on andmebaasi
füüsilise disaini sammud järgnevad.
1. Loogilise andmemudel konkreetse andmebaasisüsteemi (näiteks Oracle,
Microsoft SQL, PostgreSQL, MySQL jne.) jaoks tõlkimine.
- Tabelite disain.
• Tabelite ja kitsenduste nimede täpsustamine.
• Tabelite, veergude ning kitsenduste nimede täpsustamine vastavalt
valitud andmebaasisüsteemi võimalustele.
• Veergude tüüpide täpsustamine vastavalt valitud
andmebaasisüsteemi võimalustele.
- Tuletatud andmete disain.
- Kitsenduste täpsustamine ja lisamine lisaks veergude tüüpide
määramisele. Veeru tüübi määramine on samuti kitsenduse
2

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
deklareerimine, sest veeru tüüp määrab ära lubatud väärtused selles
veerus – need peavad kuuluma veeru tüübiga määratud väärtuste
hulka.
- Disainitaseme abitabelite leidmine.
2. Füüsilise esitusviisi disainimine.
- Transaktsioonide analüüs ja disain.
- Failide sisemise organisatsiooni ja paigutuse valimine.
- Indeksite valimine.
- Tabelite sektsioonideks jagamise (partitioning) projekteerimine.
- Tabelite andmete sisemisel tasemel ühendamise otsustamine.
- Kettamahu vajaduste hindamine.
3. Vaadete e. virtuaalsete tabelite disainimine.
4. Andmebaasisüsteemi poolt pakutavate lisavõimaluste analüüs ja
kasutuselevõtt.
- Arvujada generaatorid.
- Salvestatud protseduurid.
- Trigerid.
- Paketid.
5. Julgeolekumehhanismide disainimine.
6. Kontrollitud liiasuse sissetoomine (denormaliseerimine).
Denormaliseerimine tähendab (mõnede) tabelite normaliseerituse astme
vähendamist pragmaatilistel kaalutlustel. et parandada mõne päringu
töökiirust. Kui üks mure (päring on liiga aeglane) saab ehk lahenduse, siis
tekivad tänu denormaliseerimisele kohe uued mured (mõni teine päring või
andmemuudatus muutub aeglasemaks, tekib andmete liiasus, andmete
võivad tekkida vastuolud). Andmete denormaliseerimise vajadused
selgitatakse välja transaktsioonianalüüsi käigus. Transaktsioonanalüüsi
käigus selguvad erinevate andmebaasioperatsioonide täitmissagedused ja
täitmisajad.
Andmebaasi projekteerimine eeldab ka andmebaasi kasutavate/uuendavate
rakenduste projekteerimist (disaini).
Registri tüüpi rakenduse füüsiline disain sisaldab.
• Kasutajaliideste füüsiline projekteerimine.
• Andmebaasioperatsioonide füüsiline projekteerimine. Operatsioonide
füüsiline projekteerimine toimub tavaliselt SQL keele ning viimast
laiendava protseduurse keele (näiteks PL/SQL, Java,..) vahenditega.
2.1 Loogilise andmemudel konkreetse andmebaasisüsteemi
jaoks tõlkimine
Disainer peab teadma andmebaasisüsteemi omadusi, mille jaoks disain
tehakse. SQL-andmebaasisüsteemi puhul tuleb uurida järgnevat.
• Kuidas saab tabeleid luua? Kas tabeli loomisel saab määrata ka andmete
salvestamist juhtivate parameetrite väärtuseid (nt. et tabelis sisalduvad
andmed on ühes andmefailis, järjestikku ja sorteeritud jne.)?
• Kas süsteemis saab kirjeldada primaarvõtmeid, välisvõtmeid,
alternatiivvõtmeid?
3

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Kas saab määrata veergude kohustuslikkust? Kas unikaalses veerus võib
olla null, üks või rohkem NULLi?
• Kas saab kirjeldada domeeni objekte (vt. teema nr. 5)?
• Kas saab kirjeldada üldise kitsenduse (assertion) objekte (vt. teema nr. 5)?
• Kas saab kirjeldada täiendavaid ridade terviklikkuse reegleid (CHECK
kitsendus)?
Loogilise disaini käigus loodud andmemudel peab olema stabiilsem (aja
jooksul vähem muudatusi nõudev) kui füüsiline andmemudel. See tähendab,
et aja jooksul arenevad andmebaasisüsteemid edasi ning võtavad kasutusele
uusi võimalusi, mida tuleb füüsilise disaini juures arvesse võtta. Samas jääb
andmebaasi struktuur samaks, või muutub vähe.
2.1.1 Tabelite disain
Võimalikud variandid.
• CASE vahendi kasutamisel luuakse vahendiga andmebaasi struktuuri
füüsilise disaini täpsusega kirjeldus ja genereeritakse sellest SQL laused.
Rational Rose CASE vahendis genereeritakse kontseptuaalsest
andmemudelist tegelikult füüsilise disaini täpsusega andmemudel.
Andmemudeli genereerimisel tuleb valida andmebaasisüsteem. Vastavalt
valitud andmebaasisüsteemile saab füüsilise disaini mudeli kirjeldamisel
kasutada selle andmebaasisüsteemi poolt pakutavate tüüpide kirjeldusi.
• Kui CASE vahendit ei ole, siis tuleb SQL laused luua käsitsi.
SQL keeles kuuluvad tabelite loomise laused andmekirjelduskeelde (Data
Definition Language), mis on SQL keele alamkeel.
Tabelite loomise lausete käivitamiseks pakuvad andmebaasisüsteemid
mitmeid võimalusi. Serveri andmebaasisüsteemide koosseisu kuulub
tavaliselt käsurea programm, kus on võimalik käivitada SQL lauseid.
PostgreSQLis kannab selline programm nime plsql ja Oracle's SQL*Plus.
Selline programm võib ka võimaldada SQL lausete lugemist tekstifailist ja
nende käivitamist. Lisaks sellele on serveri andmebaasisüsteemide jaoks
olemas eraldi administreerimisprogramme (nad võivad kuuluda
andmebaasisüsteemiga ühte komplekti või olla ka eraldi juurde hangitavad),
mis võimaldavad andmebaasiga töötamist kasutades graafilist kasutajaliidest.
PostgreSQL andmebaasisüsteemi kasutaja võib eraldi alla-laadida programmi
PgAdmin, mis pakub graafilist kasutajaliidest andmebaasi haldamiseks.
Programm phpPgAdmin on veebipõhine programm, mis lubab teha samu
tegevusi kui PgAdmin.
Oracle andmebaasisüsteemiga tuleb kaasa programm nimega Database
Manager. Lisaks pakuvad paljud tarkvarafirmad oma programme Oracle
andmebaasiga töötamiseks.
4

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
MS Accessis (2007) saab tabeleid luua kasutades graafilist disainerit, või
käivitades ükshaaval tabelite loomise lauseid. Sisse-ehitatud võimalust mitme
tabeli loomise lause korraga loomiseks ei ole.
Erinevates andmebaasisüsteemides on lubatud andmebaasiobjekti
identifikaatori maksimaalne pikkus erinev!
• SQL standard määrab identifikaatori maksimaalseks pikkuseks 128 märki.
• MS Accessis on identifikaatori maksimaalne pikkus 64 märki.
• PostgreSQLis on identifikaatori maksimaalne pikkus vaikimisi kuni 63
märki, aga seda saab muuta NAMEDATALEN parameetri väärtuse
muutmise abil.
• Oracles on identifikaatori maksimaalne pikkus üldjuhul 30 märki. Kui
soovida anda kitsendustele sisukaid nimesid, siis 30 märki võib olla liiga
vähe.
Näide: Andmebaasisüsteemis MS Access (2000) ei saa CREATE TABLE
lauses määrata DEFAULT väärtust. Seda saab teha graafilise kasutajaliidese
(Table Designer) abil. Samuti ei saa CREATE ja ALTER TABLE lausetes
määrata CHECK kitsendust ja välisvõtmega seotud kompenseerivaid
tegevusi. Kuid tabeli disainivaates graafilise kasutajaliidese kaudu saab
tabeliga siduda valideerimisreegleid (ingl. k. validation rule) ja määrata
välisvõtmega seotud kompenseeriva tegevuse tüübiks CASCADE.
MS Access (2003) andmebaasisüsteemis saab eelmainitud tegevusi teha ka
SQL lausete abil, kuid selleks peab andmebaasi kasutaja märkima: Tools=>
Options=> Tables/Queries=> SQL Server Compatible Syntax (ANSI 92).
MS Access (2007) andmebaasisüsteemis saab eelmainitud tegevusi teha ka
SQL lausete abil, kuid selleks peab andmebaasi kasutaja märkima: Office
Button => Access Options => Object Designers => Query design => SQL
Server Compatible Syntax (ANSI 92).
MS Access (2010) andmebaasisüsteemis saab eelmainitud tegevusi samuti
teha ka SQL lausete abil, kuid selleks peab andmebaasi kasutaja märkima:
File => Options => Object Designers => Query design => SQL Server
Compatible Syntax (ANSI 92).
2.1.2 Tuletatud väärtuste esitamise disain
Näide: Tellimus koosneb tellimuse ridadest. Iga tellimuse rida on seotud
kaubaga millel on hind. Tellimuse real määratakse kauba kogus ja
arvutatakse rea summa. Tellimuse kui tervikule kehtib juurdehindlusi
(käibemaks, transpordikulu) ja allahindlusi (soodustused). Kui kogu see info
on andmebaasis olemas, siis saaks tellimuse summa vajadusel päringuga
arvutada. Kas hoida tellimuse summat ka eraldi veerus tabelis Tellimus?
Vastandlikud kaalutlused.
Tuletatud väärtuse kasutamine.
• Tuletatud väärtuste hoidmiseks kulub andmebaasis lisaruumi.
5

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Tuleb tagada, et andmebaasi ei satuks vastandlikku informatsiooni –
näiteks registreeritud tellimuse summa ei lange kokku andmebaasis
olevate andmete põhjal arvutatud tellimuse summaga. Antud näite korral
on valikud.
• Keelata kinnitatud tellimuste ridade muutmine, uute ridade lisamine,
ridade kustutamine. Samuti tuleb keelata tellimuse summa käsitsi
muutmine.
• Kirjutada programm, mis tellimuse ridade muutmisel arvutab ümber
tellimuse summa. Andmetes tehtud muudatuste tulemusel tuleb väärtus
ümber arvutada ja muudatus andmebaasi kanda, mis suurendab
andmete muutmise transaktsioonid töö pikkust. NB! (kui lubate tellimusi
muuta, siis tuleks kindlasti salvestada andmed selle kohta, kes ja
milliseid muudatusi on teinud).
Tuletatud väärtuse mittekasutamine.
• Väärtus tuleb arvutada iga kord uuesti, kui seda küsitakse ja see võtab
aega.
• Andmebaasi disaini juures tuleb mõelda sellele, et ka tulevikus oleks
päringutega võimalik taastada tuletatud väärtus sellisena nagu see oli
andmete tekkimise hetkel. Punkti alguses toodud näide – kui tabelis Kaup
on veerg hind ja kauba hinna muutudes kirjutatakse see hind üle, siis
edaspidistes päringutes ei saa enam seda hinda kasutada, et minevikus
tehtud tellimuse summat arvutada. Seega tuleb muuta andmebaasi disaini
ja hoida andmebaasis ka hindade ajalugu.
Kulkarni (2003) kohaselt kirjeldab SQL:2003 võimaluse luua genereeritud
veerge.
Näide:
CREATE TABLE Tootaja (
tootaja_kood INTEGER,
palk DECIMAL(7,2),
boonus DECIMAL(7,2),
kogutulu GENERATED ALWAYS AS (palk + boonus)
);
Kogutulu väärtus arvutatakse alati, kui lisada tabelisse uus rida.
2.1.3 Kitsenduste (piirangute) täpsustamine ja lisamine
Andmebaasisüsteem kontrollib andmetega seotud kitsenduste täidetust.
Kitsendused on vajalikud eelkõige selleks, et garanteerida andmete täielikkus
andmebaasi tasemel, s.t. vältida vigaste andmete sattumist andmebaasi.
Kitsendused garanteerivad andmete täielikkuse ka siis, kui andmeid ei lisata
ekraanivormist, vaid muul moel otse andmebaasi (garanteerib andmete
täielikkuse programmikoodi väliselt).
Kitsenduste liigid on järgmised.
• Tühjade väljade lubamine / mittelubamine (kohustuslikud/
mittekohustuslikud veerud).
• Primaarvõtmed.
6

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Unikaalsuse nõue.
• Välisvõtmed.
• Arendaja poolt kirjutatud kontrollkitsendused.
Vajalik on surrogaatvõtmete väärtuste genereerimine serveris
(andmebaasisüsteemi poolt), sest see garanteerib võtmeväärtuste
genereerimise ka andmete otse andmebaasi sisestamisel ja vähendab võrgu
koormust.
Järgnev näide illustreerib väidet, et ühe andmebaasisüsteemi kasutamisel
omandatud teadmised ei pruugi olla 100% rakenduvad mõne teise
andmebaasisüsteemi juures. NULLide kasutamine kitsendustes erinevates
andmebaasisüsteemides (Gutuluzan & Pelzer, 2003). Võrreldavad
andmebaasisüsteemid.
• IBM DB2 Universal Database 7.2
• IBM Informix Dynamic Server 9.3
• Ingres II 2.5
• InterBase 6.0
• Microsoft SQL Server 2000
• MySQL 3.23
• Oracle 9i
• Sybase ASE 12.5
Automaatselt
NOT
NULL?
NOT NULL
kitsenduse
kustutamine
on võimalik?
Mitu NULLi
on lubatud
unikaalsuse
kitsendusega
veerus?
Kas NOT
NULL
kitsendus on
vajalik veeru
taseme
primaarvõtme
kitsenduse
juures?
ANSI ei jah mitu ei ei
SQL
IBM DB2 ei ei üks jah jah
Informix ei jah üks ei ei
Ingres ei ei null jah jah
InterBase ei ei null jah jah
MS SQL jah jah üks ei ei
Server
MySQL ei jah mitu ei jah
Oracle ei jah mitu ei ei
Sybase jah jah üks ei jah
Kas NOT
NULL
kitsendus on
vajalik tabeli
taseme
primaarvõtme
kitsenduse
juures?
• Automaatselt NOT NULL.
- jah, kui veerg on vaikimisi kohustuslik
- ei, kui veerg on vaikimisi mittekohustuslik
• NOT NULL kitsenduse kustutamine.
- jah, kui saab kustutada veeruga seotud NOT NULL kitsendust (pole
kooskõlas SQL standardiga)
- ei, kui ei saa kustutada veeruga seotud NOT NULL kitsendust
• Mitu NULLi on lubatud unikaalsuse kitsendusega veerus.
7

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
- null, kui unikaalsuse kitsendusega veerule vastavates ridade väljades
peab alati väärtus olema
- üks, kui unikaalsuse kitsendusega veerule vastavate ridade väljade
seas tohib olla maksimaalselt üks väli, kus väärtust ei ole.
- mitu, kui unikaalsuse kitsendusega veerule vastavate ridade väljade
seas tohib olla mitu välja, kus väärtust ei ole.
• Kas NOT NULL on vajalik veeru taseme primaarvõtme kitsenduse juures.
- jah, kui on nõutud "CREATE TABLE T1 (veerg1 INTEGER NOT NULL
PRIMARY KEY)
- ei, kui piisab "CREATE TABLE T1 (veerg1 INTEGER PRIMARY KEY)
(kooskõlas SQL standardiga)
• Kas NOT NULL on vajalik tabeli taseme primaarvõtme kitsenduse juures.
- jah, kui on nõutud CREATE TABLE T1 (veerg1 INTEGER NOT NULL,
CONSTRAINT T1 PRIMARY KEY)
- ei, kui piisab CREATE TABLE T1 (veerg1 INTEGER, CONSTRAINT
T1 PRIMARY KEY) (kooskõlas SQL standardiga)
2.1.3.1 Välisvõtmetega seotud kompenseerivad tegevused
Siin on mõeldud välisvõtmetega seotud tabelites sooritatavaid tegevusi ridade
muutmisel, kustutamisel ühes seotud tabelitest. See tähendab, kas:
1. Kustutatakse (muudetakse sõltuva tabeli välisvõtme veerus olevat
väärtust) vastavad read sõltuvast tabelist, kui kustutatakse (muudetakse
andmeid peremeestabeli primaarvõtme veerus) peremeestabeli rida
(DELETE / UPDATE CASCADE).
2. Keelatakse peremeestabeli rea kustutamine (peremeestabeli
primaarvõtme veerus andmete muutmine) seni, kuni eksisteerib seotud
ridu sõltuvas tabelis (DELETE / UPDATE NO ACTION või RESTRICT).
3. Lisaks eespool toodud variantidele võidakse veel kustutada väärtused
sõltuva tabeli vastavatest välisvõtme väljadest (või anda neile mingi muu
väärtus), kui peremeestabeli vastav rida kustutatakse (või muudetakse
väärtust primaarvõtme veerus).
Nimetatud variantide vahel valiku tegemisel võib lähtuda järgmistest
printsiipidest:
• Primaarvõtme veergudes andmete muutmise puhul lähtuda
1. variandist 2, kui primaarvõtme veerg on genereeritud puhtalt ridade
unikaalsuse tagamiseks ning ei oma kasutaja jaoks mingit sisulist
tähendust ja seega puudub ka vajadus väärtuste muutmiseks neis
veergudes,
2. variandist 1, kui primaarvõtme veerg omab kasutaja jaoks sisulist
tähendust.
• Ridade kustutamisel kasutada nii variandis 1 kui ka 2 toodud printsiipe.
Igal konkreetsel juhul lähtutakse variandi valikul:.
1. Analüüsi käigus formuleeritud soovitustest.
2. Andmete kokkukuuluvuse loogikast (vt. järgnevaid näiteid).
Näited:
• Tugeva olemi andmete kustutamisel kustutatakse sellega seotud nõrkade
olemite andmed (vt. teema 6). Nt. Tellimus koosneb Tellimuse ridadest.
8

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Iga Tellimuse rida on seotud ühe kindla Tellimusega. Tellimuse
kustutamisel kustutatakse ka sellega seotud Tellimuse read, sest nad ei
oma iseseisvana mõtet.
• Kui kaks tugevat (teistest olemitest sõltumatut) olemit on omavahel
seotud, siis ühe olemi andmete kustutamine ei tohi tingida teise olemi
andmete kustutamise:
• Tänavate tabelist tänava kustutamine keelatakse aga seniks, kuni
eksisteerib isikuid, firmasid jms., mis selle tänavaga seotud on.
• Klassifikaatorite andmeid sisaldavas tabelis keelatakse ridade
kustutamine, kui seotud tabelis leidub ridu.
Järgnevalt on välja toodud võrdlev tabel, mis näitab erinevate
andmebaasisüsteemide poolt toetatavaid kompenseerivaid tegevusi.
MS Access 2007 Oracle 11g PostgreSQL 9.0
ON UPDATE NO
ACTION (vaikimisi)
ON UPDATE CASCADE
ON UPDATE SET NULL
ON DELETE NO
ACTION (vaikimisi)
ON DELETE CASCADE
ON DELETE SET NULL
ON UPDATE NO
ACTION (vaikimisi)
ON DELETE NO
ACTION (vaikimisi)
ON DELETE CASCADE
ON DELETE SET NULL
ON UPDATE NO
ACTION (vaikimisi)
ON UPDATE RESTRICT
ON UPDATE CASCADE
ON UPDATE SET NULL
ON UPDATE SET
DEFAULT
ON DELETE NO
ACTION (vaikimisi)
ON DELETE RESTRICT
ON DELETE CASCADE
ON DELETE SET NULL
ON DELETE SET
DEFAULT
Siin välja pakutud kolmes andmebaasisüsteemis vastab vaid PostgreSQL
kompenseerivate tegevuste osas SQL standardile.
Näide: Juhul, kui andmebaasisüsteem ei toeta kõiki välisvõtmega seotud
lisakitsendusi (nt. MS SQL Server 7.0 ei võimaldanud kaskaadset
kustutamist), võib probleemi lahendada kasutades trigereid.
Tabeliga Oppejoud on seotud triger, mis käivitud juhul kui tabelist Oppejoud
mõni rida kustutatakse. Selle peale kustutatakse seotud read tabelis Aine.
CREATE TRIGGER D_OPPEJOUD ON dbo.OPPEJOUD
FOR DELETE
AS
DELETE AINE FROM deleted, AINE WHERE deleted.oppejoud_id =
AINE.looja
9

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
DELETE AINE FROM deleted, AINE WHERE deleted.oppejoud_id =
AINE.kinnitaja;
Nagu näete on trigeri kirjutamine töömahukam ja tülikam (erinevates
andmebaasisüsteemides on erinev trigeri kehandis oleva protseduuri
kirjutamiseks mõeldud keel) võrreldes selle kompenseeriva tegevuse
deklareerimisega välisvõtme kitsenduse loomisel.
Näide. MS Accessis on Text, Memo ja Hüperlink andmetüübiga veergude
väärtustamiseks võimalik kasutada ka nullpikkusega stringi e. tühja stringi
(ingl. k. zero lenght string). See võimaldab tähistada väärtuse puudumist
kahel erineval viisil (ja selle kaudu eristada põhjuseid, miks väärtus puudub):
• NULL,
• nullpikkusega string.
Näiteks NULL tähistab olukorda, kus ei teata seda, kas väärtus on olemas või
mitte. Kui väärtuse puudumine on kindlalt teada, kasutatakse nullpikkusega
stringi.
MS Accessis saab tabeli disainivaates määrata, kas lubada mingis veerus
NULLe ja nullpikkusega stringe. Veerul on omadused.
• Required – kas välja täitmine on kohustuslik? (yes – on kohustuslik; no
– ei ole kohustuslik). Kohustuslik veerg ei tohi sisaldada NULLe,
mittekohustuslik tohib.
• Allow Zero Length – kas lubada nullpikkusega stringe (yes – lubada; no
– mitte lubada);
Väärtuse puudumise kindlakstegemiseks tuleb kasutada IS NULL predikaati.
Nullpikkusega stringi otsimiseks tuleb WHERE klauslis kasutada literaali ''
(kaks järjestikus ülakoma mille vahel ei tohi olla tühikut).
Seega, kui kontseptuaalses andmemudelis on mingi atribuudi
spetsifikatsioonis öeldud, et selle väärtus ei tohi olla tühi string, siis vastava
veeru spetsifitseerimisel MS Accessi andmebaasis tuleb määrata Allow Zero
Length=no.
10

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Joonis 1Tühjade stringide keelamine MS Accessi tabeli veerus.
INSERT INTO Amet (ameti_kood, nimetus) VALUES (99,'');
Lisamine ebaõnnestus, sest nimetus ei tohi olla tühi string.
Joonis 2Veateade MS Accessis, mis kuvatakse, kui lisada tühi string
veergu, kus see pole lubatud.
2.1.3.2 CHECK kitsendused
Tabeli rida lükatakse andmebaasisüsteemi poolt tagasi, kui see annab
CHECK kitsenduse täidetuse kontrollil tulemuseks VALE (FALSE). Kui
kitsenduse kontrolli tulemuseks on ÕIGE (TRUE) või MÄÄRAMATA
(UNKNOWN), siis rida ei lükata tagasi.
Kitsenduste kontrolli tulemus on UNKNOWN, kui jätta kontrollitavatele
veergudele vastavad väärtused määramata.
CREATE TABLE Test(id INTEGER,
a INTEGER,
CONSTRAINT pk_test PRIMARY KEY(id),
CONSTRAINT chk_test_a CHECK(a>2));
11

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
--Lisamine õnnestub
INSERT INTO test (id, a) VALUES (1, NULL);
--sest NULL>2 => UNKNOWN
INSERT INTO test (id, a) VALUES (2, 3);
-- sest 3>2 => TRUE
--Lisamine ebaõnnestub
INSERT INTO test (id, a) VALUES (3, 1);
-- sest 1>2 => FALSE
Näited:
ALTER TABLE Leping ADD (
CONSTRAINT chk_lepingu_rida_perioodi_paeva
CHECK (
(tyyp=1 AND tasumise_periood BETWEEN 1 AND 5) OR
(tyyp=2 AND tasumise_periood BETWEEN 1 AND 15))
);
Lepingul võib olla kuni 100 rida:
ALTER TABLE Lepingu_rida ADD (
CONSTRAINT chk_lepingu_rida_ridade_arv
CHECK (NOT EXISTS (SELECT lepingu_nr
FROM Lepingu_rida
GROUP BY lepingu_nr
HAVING COUNT(*)>100))
)
);
Kaare lahendamine kitsenduse abil – kommentaar võib olla seotud kauba või
teenusega, aga mitte mõlemaga korraga.
ALTER TABLE Lepingu_rida ADD CONSTRAINT chk_lepingu_rida_kaar
CHECK ((kaup IS NULL AND teenus IS NOT NULL) OR
(kaup IS NOT NULL AND teenus IS NULL));
ALTER TABLE Table_1 ADD CONSTRAINT constraint_1
CHECK (column_1>(SELECT Max(column_2) AS maks FROM Table_2));
CHECK kitsendus ei tohi olla mitte-deterministlik, st. anda samade andmete
kontrollimisel erinevatel aegadel erineva tulemuse.
Järgnev kitsendus on illegaalne (mittelubatud):
ALTER TABLE Leping ADD CONSTRAINT chk_solmimise_kp
CHECK(solmimise_kp=CURRENT_DATE);
Paljud andmebaasisüsteemid (nt. Oracle, PostgreSQL) ei luba CHECK
kitsendustes kasutada alampäringuid. Sellisel juhul saab CHECK kitsendusi
12

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
kasutada vaid selliste kitsenduste jõustamiseks, mille kontrollimiseks on vaja
teada ainult andmeid lisatavas/muudetavas reas (näiteks
kinnitamise_aeg>=#01/01/2000# või kinnitamise_aeg>=loomise_aeg). Kui
tabeli T rea r kitsendusele vastamise kontrollimiseks on vaja lugeda teisi T
ridu või teiste tabelite ridu, siis tuleb kitsendus jõustada trigerite abil (vt.
teema 13).
Kitsendusi saab kirjeldada ka domeeni objektides:
CREATE DOMAIN d_eesti_isikukood AS CHAR(11) NOT NULL
CONSTRAINT Isikukood_koosneb_11_numbrist CHECK(VALUE ~
'^([[:digit:]]{11})$')
CONSTRAINT Esimene_number_peab_olema_vahemikus_3_ja_6
CHECK(VALUE ~ '^([3-6]{1}.*)$')
CONSTRAINT Neljas_number_peab_olema_0_voi_1 CHECK(VALUE ~ '^(.
{3}[0-1]{1}.*)$')
CONSTRAINT Kuues_number_peab_olema_vahemikus_0_ja_3
CHECK(VALUE ~ '^(.{5}[0-3]{1}.*)$');
CREATE TABLE Isik
(isikukood d_isikukood,
...
);
Kitsendusi saab kirjeldada ka assertion objektides:
CREATE ASSERTION assertion_1
CHECK ((SELECT Avg(column_1) FROM Table_1)>(SELECT
Avg(column_2) FROM Table_2));
Assertion objekti kirjeldatav kitsendus peab hõlmama üks või rohkem tabelit.
CREATE ASSERTION assertion_1
CHECK ((SELECT Avg(column_3) FROM Table_3)>40);
Paljudes andmebaasisüsteemides selliseid objekte luua ei saa.
Näide: Kuidas vältida tühja stringi kasutamist PostgreSQL (9.0) veeru
väärtustamisel?
CREATE TABLE Amet (ameti_kood SMALLINT NOT NULL,
nimetus VARCHAR(50) NOT NULL,
CONSTRAINT pk_amet PRIMARY KEY (ameti_kood),
CONSTRAINT chk_nimetus CHECK (nimetus!=''));
INSERT INTO Amet (ameti_kood, nimetus) VALUES (99,'');
ERROR: new row for relation "amet" violates check constraint "chk_nimetus"
Näide: Andmebaasisüsteemis MS Access (2000) ei saa kasutada CHECK
kitsendusi. Graafilise kasutajaliidese (Tabel Designer) abil saab tabeli ja
13

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
veergudega seostada valideerimisreegleid (Validation Rules ja Validation
Text). Tabeli tasemel defineeritud valideerimisreegel võimaldab kontrollimisel
kasutada kõiki tabeli veerge (nt. kontrollida, kas alguse aeg on varasem kui
lõpu aeg). Keerukamaid andmete kontrolli reegleid tuleb realiseerida VBA-s
kirjutatud sündmusprotseduuride abil.
MS Access (2003) võimaldab luua SQL lausete abil CHECK kitsendusi (kui on
määratud Tools=> Options=> Tables/Queries=> SQL Server Compatible
Syntax (ANSI 92)). MS Access (2007) võimaldab luua SQL lausete abil
CHECK kitsendusi (kui on määratud Office Button => Access Options =>
Object Designers => Query design => SQL Server Compatible Syntax (ANSI
92)). Kuid huvitava puudusena, ei saa tabeleid, millele on selline kitsendus
loodud läbi graafilise kasutajaliidese ära kustutada.
Näide: Andmebaasisüsteemides PostgreSQL, Oracle ei saa CHECK
kitsenduses kasutada alampäringuid. See ei võimalda keerukamaid kitsendusi
CHECK kitsenduste abil jõustada. Küll aga saab CHECK kitsenduses
kasutada alampäringut andmebaasisüsteemis MS Access (2007).
Näide andmebaasisüsteemis MS Access (2007). Defineerin kitsenduse, et
tabelis Kaibemaks tohib olla maksimaalselt üks rida.
CREATE TABLE Kaibemaks(suurus SMALLINT PRIMARY KEY);
ALTER TABLE Kaibemaks ADD CONSTRAINT chk_kaibemaksu_max_1
CHECK((SELECT Count(*) AS arv FROM Kaibemaks)

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
2.2.1 Transaktsioonanalüüs
Selleks, et leida andmebaasi osad, mis võivad põhjustada probleeme
töökiiruses tuleb leida:
• Transaktsioonid, mis käivituvad sageli ja millel on töökiirusele suur
mõju.
• Transaktsioonid, mis on organisatsiooni toimimiseks hädavajalikud.
• Ajaperioodid päeva/nädala jooksul, millal andmebaasi kõige rohkem
kasutatakse (ingl. k. peak load)
80/20 reegel – 20% kasutajate transaktsioonidest)annavad 80% andmebaasi
kasutamise mahust.
Selleks, et leida tabelite kasutamine transaktsioonide poolt, koostatakse
CRUD maatriksi (Transaktsioonide / tabelite risttabel).
CRUD maatriksi alusel leitakse tabelid, mida kasutavad kõige rohkem
transaktsioone. Neid tabeleid kasutavaid transaktsioone uuritakse lähemalt.
Transaktsiooni analüüsimise käigus leitakse järgmine informatsioon.
• Tabeli kasutamise tüüp (andmete lisamine, muutmine, kustutamine,
lugemine)
• Kasutatavad tabelid ja veerud. Veergudes, milles andmeid
muudetakse võib olla kasulik indeksi kasutamisest loobuda.
• SQL lause WHERE klausli tingimustes määratud veerud
(indekseerimise kandidaadid).
• Veerud, mis osalevad SQL lausetes tabelite ühendamisel
(indekseerimise kandidaadid).
• Veerud, mida kasutatakse SQL lausetes sorteerimisel (indekseerimise
kandidaadid).
• Veerud, mida kasutatakse SQL lausetes grupeerimisel (indekseerimise
kandidaadid).
• Transaktsiooni keskmine päevase töötamise sagedus.
• Transaktsiooni poolt keskmiselt kasutatav ridade hulk.
• Transaktsiooni maksimaalse kasutamise ajaperiood ja sagedus.
• Transaktsiooni poolt maksimaalselt kasutatav ridade hulk.
• Nõudmised transaktsiooni töökiirusele (nt. peab kestma alla 1 sekundi).
Näiteid transaktsioonanalüüsi põhjal tehtavatest järeldustest.
• Päringu tingimustes sageli kasutatavatele veergudele, kus on palju
unikaalseid väärtuseid, tuleks luua B-puu tüüpi indeks. Indeks tuleb luua
vaid juhul, kui sellist indeksit ei ole eelnevalt loodud.
• Tabelitele, milles ridade arv on väike või mida sageli muudetakse, ei ole
mõtet täiendavalt indekseerida.
• Tabelid, mida kasutatakse sageli päringus koos, võiks Oracles võimalusel
koondada ühte kobrasse (klastrisse).
15

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
2.2.2 Salvestusruumi disain
2.2.2.1 Andmete paigutus failides
Failide organiseerimine on andmete füüsiline korrastamine plokkideks
püsisalvestusega andmekandjal. Tuleb valida optimaalne failide
organisatsioon. Sageli ei võimalda andmebaasisüsteem seda disaineril
määrata. Sellisel juhul jääb see samm vahele.
Andmeid hoitakse ühes või mitmes failis. Fail sisaldab üks või rohkem kirjet,
millest igaühes on üks või rohkem välja. Sisemisel tasemel võib fail sisaldada
mitut füüsilist kirjet (lehekülge e. plokki), millest igaüks sisaldab ühte või
rohkemat loogilist kirjet (ühe tabeli üks rida). Andmefailis sisaldab iga plokk
tüüpiliselt andmeid ühest tabelist. Lisaks on andmefaili alguses info selle
kohta milliste tabelite andmed on millistes plokkides. See kiirendab andmete
otsimist, sest nt. päringu
SELECT * FROM Aine;
täitmiseks pole vaja enam üle vaadata kõigi tabeliplokke vaid ainult selliseid,
mis sisaldavad tabeli Aine andmeid. Andmete lugemine/kirjutamine
kõvakettale toimub plokkide kaupa
• Andmefail võib olla sorteerimata (ingl. k. heap file). Plokid kirjutatakse täis
andmete laekumise järjekorras ja mingit sisulist järjestust tabeliplokkidesse
kirjutatud andmed ei oma.
Eelised:
• Lisamine kiire. Väärtused lisatakse faili lõppu (lõpus olevatesse
plokkidesse).
Puudused:
• Konkreetse rea otsimine aeglane. Fail/failid tuleb jadamisi läbi käia
ning lugeda mällu kõik failis sisalduvad plokid.
• Kustutamine aeglane, sest kustutatavat rida sisaldav plokk tuleb
jadamisi otsinguga üles otsida.
• Kustutamise tulemusel jäävad plokkidesse tühjad kohad, mida ei
taaskasutata. Sellega seoses väheneb töökiirus. Andmebaasisüsteem
peab perioodiliselt selliseid faile ümber-organiseerima.
• Andmefail võib olla sorteeritud mingi väärtuse (ingl. k. ordering key) järgi.
Eelised:
• Konkreetse rea otsimine kiire. Saab rakendada kahendotsingut (ingl. k.
binary search).
Puudused:
• Andmete lisamine/muutmine on aeglane, sest järjekorda tuleb hoida.
Andmete otsimiseks tabelist on andmebaasisüsteemil kaks põhilist
strateegiat:
• Tabeli läbiskaneerimine (tabeli plokkide lugemine ja läbivaatamine) ilma
indeksit kasutamata.
• Vaadatakse läbi kõik plokid (ingl. k. full table scan)
16

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Vaadatakse läbi osa plokke – võimalik nt. siis kui tabeli andmed on
plokkides sorteeritud.
• Indeksi kasutamine vajalike ridu sisaldavate tabeli plokkide leidmiseks (ingl.
k. index scan).
Rea loogiline aadress = tabeli nimi + kandidaatvõtme hõlmatud veergude
nimed + kandidaatvõtme väärtus
Korteeži loogiline aadress = relvari nimi + kandidaatvõtme hõlmatud
atribuutide nimed + kandidaatvõtme väärtus
Rea füüsiline aadress = faili identifikaator + ploki identifikaator + rea
positsioon plokis
Rea loogilist aadressi kasutab rea ülesleidmiseks andmebaasi kasutaja. Rea
füüsilist aadressi kasutab rea ülesleidmiseks andmebaasisüsteem.
2.2.2.2 Failide paigutuse valimine
Juhul kui andmebaas asub arvutis, milles on mitu kõvaketast, siis tuleb
mõelda ka faile paigutamisele. Järgnevaid soovitusi esitab Rationali
unifitseeritud protsessi kirjeldus.
• Paigutada üheaegselt kasutatavad andmed erinevatele kõvaketastele, et
jagada ketaste vahel töökoormust ning võimaldada andmete paralleelset
lugemist.
• Paigutada indeksid ja andmefailid erinevatele kõvaketastele, et jagada
töökoormust ning võimaldada andmete paralleelset lugemist.
• Keerukate päringute puhul tasuks kaaluda päringu poolt kasutatavate
andmete paigutamist mitmele erinevale kõvakettale. See tähendab, et
tabeliplokid on jaotatud erinevate kõvaketaste vahel ja nende poole
pöördumine saab toimuda paralleelselt.
Parima failide paigutuse leidmine on korduslik ja eksperimentaalne protsess.
Kuidas määrata, millise tabeli andmed on millises failis? Mõned
andmebaasisüsteemid (nt. Oracle, PostgreSQL) võimaldavad luua
tabeliruume (sisemise taseme objektid), mis seovad ära tabelid ja
andmefailid. Tabeliruumi loomisel saab määrata sellega seotud failid ja tabeli
loomisel saab määrata selle mingisse tabeliruumi.
Seega tabeliruumide kasutamine võimaldab määrata failid, kuhu tabeli
andmed salvestada ja seega ka kaudselt määrata, millisele kõvakettale ühe
või teise tabeli andmed salvestada. Tabeliruumi objekt ei ole SQL standardi
poolt kirjeldatud.
2.2.2.3 Plokis lubatud vaba ruumi hulga valimine
Andmefail koosneb plokkides e. lehekülgedest. Mida tihedamalt on plokk
andmetega täidetud, seda vähem on plokis vaba ruumi. See võib osutuda
probleemiks, kui plokis olevaid andmeid sageli muudetakse, sest muudatus ei
pruugi enam plokki ära mahtuda ja muudetud rea või selle osa tuleb kirjutada
17

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
teise plokki. See aga omakorda põhjustab tabeli andmete hajumist erinevatele
plokkidele üle kogu kõvaketta. Loomulikult väheneb sellega seoses ka tabeli
andmete lugemise kiirus.
Teisest küljest on tihedalt täis pakitud plokkide puhul (kus on vähe vaba
ruumi) vaja andmete salvestamiseks vähem plokke ja sellega hoitakse kokku
salvestusruumi. Samuti käib andmete otsimine kiiremini, sest
andmebaasisüsteem peab lugema kõvakettalt vähem plokke.
Rational Unified Processi kirjeldus soovitab tabelid ja indeksid jaotada
vastavalt sellele, kui sageli muutuvad nendes olevad andmed:
• väga sageli muudetavad,
• suhteliselt sageli muudetavad,
• harva muudetavad.
• Väga sageli muudetavate tabelite ja indeksite andmed peaksid olema
plokkides, kus on vaba ruumi 30%.
• Suhteliselt sageli muudetavate tabelite ja indeksite andmed peaksid olema
plokkides, kus on vaba ruumi 15%.
• Harva muudetavate tabelite ja indeksite andmed peaksid olema plokkides,
kus on vaba ruumi 5%.
2.2.2.4 Andmebaasi suuruste hindamine
Andmebaasi suuruse hindamise aluseks on iga tabeli kohta leitav kirjete arv.
Rationali unifitseeritud protsessi kirjeldus märgib, et tabeli suuruse
arvutamiseks saab kasutada valemit:
tabeli suurus = (fikseeritud täiendav suurus tabeli kohta) + (tabeli
ridade arv * (keskmine rea suurus/keskmine andmete tihedus))
Suuruse mõõtühikuks võivad nt. olla baidid.
Andmebaasi suuruse hinnang aitab määrata vajalikku kõvaketta/kõvaketaste
suurust.
2.2.3 Indeksite valimine
Indeks on andmebaasiobjekt, mis sisaldab indekseeritava(te) veeru
(veergude) väärtust ning viidet (e. aadressi) neid väärtuseid sisaldavate
ridade asukohale (ROWID). ROWID on tabeli rea füüsiline aadress. Selle
struktuur on erinevates andmebaasisüsteemides erinev kuid see võiks
sisaldada andmefaili identifikaatorit, tabeliploki identifikaatorit ja
identifikaatorit, mis näitab rea positsiooni plokis.
Indeksite eesmärgiks on kiirendada andmete otsimist ja sorteerimist, juhul kui
otsimine toimub mingi kriteeriumi järgi.
18

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Temast võib mõelda, kui analoogiast raamatu lõpus oleva indeksiga. Indeksit
võidakse hoida eraldi failis (ingl. k. index file). Indeksid sisaldavad viiteid
tabelite ridadele, mida hoitakse andmefailis (ingl. k. data file).
Indekseid ei kirjeldata SQL standardis, kuid praktiliselt igas
andmebaasisüsteemis on nad olemas. Tüüpilise B-puu indeksi loomiseks
mõeldud lause on erinevates andmebaasisüsteemides vaata et sarnasemgi,
kui mitmed SQL standardis kirjeldatud lausendid.
Füüsilise disaini käigus tuleb määrata, kas indeksite lisamine suurendab
süsteemi töökiirust. Kõigepealt tuleb koostada nimekiri veergudest, mida võiks
indekseerida ja seejärel eemaldada sealt veerud, mille indekseerimine
muudab andmete muutmise liiga aeglaseks.
Päringu täitmisel on alternatiiviks indeksi kasutamisele täielik tabeli
läbikäimine (ingl. k. full table scan). See tähendab, et kui otsitakse tabelist
mingile tingimusele vastavaid ridu, siis tuleb vaadata ükshaaval läbi kõik selle
tabeli ridu sisaldavad plokid.
Indeksi kasutamise üle mingi andmebaasi operatsiooni täitmisel otsustab
andmebaasisüsteem.
2.2.3.1 Indeksite loomine tabeli veerule või veergudele
Indeksid mingite veergude jaoks luuakse kas automaatselt
andmebaasisüsteemi poolt või andmebaasi programmeerija või
administraatori poolt CREATE INDEX lausega.
Indekseeritakse baastabelite veerge.
SQL standard ei täpsusta CREATE INDEX käsu struktuuri, kuid see on
enamikus andmebaasisüsteemides olemas.
CREATE [UNIQUE] INDEX index_name
ON table (column [, ]…);
Näiteks:
CREATE INDEX index_pnimi
ON tootaja (pnimi);
Indeksit ei saa luua virtuaalsele tabelile e. vaatele. See tähendab, et indeksit
ei saa siduda vaate objektiga. Erandiks on materialiseeritud vaated, mis on
tegelikult vaate e. päringu põhjal loodud baastabelid ja millele võib luua
indekseid.
Nii ei saa:
CREATE VIEW hinded AS
SELECT pnimi, enimi, hinne FROM tudeng,oppim
WHERE tudeng.tkood=oppim.tudkood;
19

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
CREATE INDEX pn_ind ON hinded (pnimi);
SELECT * FROM hinded ORDER BY pnimi;
Vaate põhjal päringut tehes konstrueerib päringu täitmise programm vaate ja
päringu põhjal uue SQL lause, mis täidetakse vaate aluseks olevatel tabelitel
ja selle täitmiseks võidakse kasutada indekseid.
2.2.3.2 Indeksi kustutamine
DROP INDEX index;
2.2.3.3 Automaatne indeksi loomine
Andmebaasisüsteem võib kasutada indekseid, et kiirendada kitsenduste
täidetuse kontrolli.
Kui tabeli loomisel või muutmisel defineerida tabelile primaarvõti (PRIMARY
KEY kitsendus) või lisada mõnele veerule lihtsalt unikaalsuse nõue (UNIQUE
kitsendus), siis peaaegu kõik andmebaasisüsteemid loovad nendele
veergudele automaatselt indeksi.
Tänu indeksi olemasolule saab andmebaasisüsteem indekseeritud veergu
väärtuse lisamisel või väärtuse muutmisel kiiresti kontrollida, kas unikaalsuse
nõue on peale seda täidetud.
NB! Unikaalsuse kitsendus != Indeks
Unikaalsuse kitsenduse loomine ei pea tingimata tähendama indeksi loomist
(st. indeksi loomine võib olla otstarbekas, aga andmebaasisüsteem ei pea
seda looma, kui see kasutab mingit efektiivsemat meetodit unikaalsuse
kitsenduse täidetuse kontrolliks).
Mõned andmebaasisüsteemid (aga mitte enamik) nagu Informix, Ingres ja
InterBase loovad automaatselt indeksid ka välisvõtmetele.
Enamik andmebaasisüsteeme ei kontrolli indeksi loomisel, kas indekseeritava
veeru põhjal pole juba indeksit loodud. Niimoodi võivad tekkida kattuvad ja
seega liigsed indeksid. See on halb sest sellised indeksid:
- raiskavad salvestusruumi;
- aeglustavad andmete muutmiseks mõeldud lausete täitmist;
- ajavad päringu optimeerimise programmi segadusse, kuna sellel
on valida mitme samaväärse indeksit kasutava täitmisplaani
vahel.
2.2.3.4 Indeksi kasutamine
Andmebaasisüsteeme otsustab ise, millal kasutada andmete otsimiseks
indeksit ja millal mitte. Selleks peavad andmebaasisüsteemile teada olema
20

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
statistilised väärtused, mis iseloomustavad tabelites olevaid andmeid (nt. kui
palju on tabelis ridu, kui palju on veerus erinevaid väärtuseid, milline on nende
jaotus). Regulaarse statistika värskendamise tagamine, on üks andmebaasi
administraatori põhiülesannetest.
Indeksite kasutamise reeglid on järgmised:
• Andmebaasisüsteem kaalub indeksi kasutamist, kui päringus on WHEREklausel
ja selles klauslis on märgitud see indekseeritud veerg. Kui veerul
on indeks ei tähenda see, et andmebaasisüsteem seda tingimata kasutab.
Andmebaasisüsteem otsustab indeksi kasutamise SQL lause füüsilise
täitmisplaani koostamise käigus, võttes arvesse andmebaasis olevate
andmete kohta kogutud statistika.
• Funktsioonil mitte-põhinevat indeksit ei kasutata, kui WHERE-klauslis
toodud veerg on osa mingist funktsioonist või avaldisest (ingl. k.
expression). Näiteks:
SELECT *
FROM tootaja
WHERE UPPER(pnimi) = ‘KASK’;
SELECT *
FROM Laud
WHERE pikkus-1 >100;
Lahenduseks oleks kasutada funktsioonil põhinevat indeksit. Funktsioonil
põhineva indeksi korral arvutatakse indeksisse paigutatavad väärtused
tabelisse pandavatele väärtustele rakendatava funktsiooni tulemusena.
CREATE INDEX fidx_tootaja_pnimi ON Tootaja (Upper(pnimi));
Funktsioonil põhinevat indeksit saab nt. luua nii andmebaasisüsteemis
PostgreSQL kui ka Oracle.
2.2.3.5 Indeksite klassifikatsioon
Indekseid võib klassifitseerida mitmel erineval viisil. Üks indeks võib kuuluda
korraga mitmesse klassi. Järgnevalt on toodud näiteid võimalikest liigitustest:
Osalevate veergude arv
• Lihtindeks – indeksisse on võetud väärtused ühest veerust.
• Liitindeks – mitu veergu võib olla ühe indeksiga indekseeritud kas siis
otsimise kiiruse või ridade unikaalsuse kindlustamise eesmärgil.
Osalevate tabelite arv
• Üks tabel (tüüpiline olukord).
• Mitu tabelit (vt. joini indeks).
Veeru tüüp, millele on loodud
21

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Primaarne indeks – primaarvõtmes osalevate veergude põhjal. Tabelile
saab olla loodud maksimaalselt üks primaarne indeks.
• Sekundaarne indeks – primaarvõtmes mitteosalevate veergude põhjal.
Tabelile võib olla loodud mitu sekundaarset indeksit.
Indekseeritud veerus olevate väärtuste unikaalsus
• Unikaalne indeks (primaarvõtme või unikaalsuse kitsendusega hõlmatud
veergudele)
• Mitteunikaalne indeks (primaarvõtme või unikaalsuse kitsenduse poolt
mitte hõlmatud veergudele)
Indeksis olevate väärtuste leidmine
• Väärtus otse veerust.
• Väärtus veerust. Enne indeksisse lisamist on väärtusele rakendatud
süsteemi poolt pakkimisalgoritmi.
• Funktsioonil põhinev indeks. Funktsiooni argumendiks on väärtus
veerule vastavast rea väljast. Indeks luuakse funktsiooni tagastatava
väärtuse põhjal.
Funktsioonil põhinevat indeksit saab luua nt. Oracle ja PostgreSQL
andmebaasisüsteemides. Näiteks järgneva päringu:
SELECT *
FROM Tudeng
WHERE Upper(perenimi)='TAMM';
puhul, ei kasuta andmebaasisüsteem veerule perenimi loodud indeksit, mis
on loodud käsuga:
CREATE INDEX tudeng_perenimi_idx ON Tudeng(perenimi);
Selleks, et otsinguks kasutada indeksit tuleb luua funktsioonil põhinev indeks:
CREATE INDEX tudeng_upper_perenimi_idx ON Tudeng(Upper(perenimi));
Indeksi tihedus
• Tihe indeks – Iga indekseeritud tabeli rea kohta on indeksis üks rida.
• Hõre indeks – Indeksis on vähem ridu, kui indekseeritud tabelis.
2.2.3.6 Indeksi sisemise ülesehituse viisid
Järgnevalt vaadeldakse mõningaid erinevaid indeksi ülesehituse viise:
• Lihtne tihe indeks
• Lihtne hõre indeks
• B-puu indeks
• Kahendpuu indeks
• Räsiväärtustel põhinev indeks
22

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Bitmap indeks
• Bitmap-join indeks
• Indeksi järgi organiseeritud tabel
2.2.3.7 Lihtne tihe indeks
Kõige lihtsam indeksi vorm koosneb spetsiaalsest failist, kus hoitakse
sorteerituna kõiki indekseeritud veerus/veergudes olevaid väärtuseid ning
viiteid vastavata tabeli ridade tegelikule asukohale kõvakettal. Nagu tabeli
andmeid sisaldav fail koosneb tabeliplokkidest nii koosneb indeksi andmeid
sisaldav fail indeksiplokkidest.
Olgu näiteks tabel Isik, kus veerule perenimi on loodud indeks:
Indeksiplokk
Aav
Avi
Aamer
Brown
Bush
Hunt
...
...
...
Aav
Avi
Aamer
Aamer
Brown
Brown
Brown
Brown
Bush
Bush
Tabeliplokk
Joonis 3Lihtne tihe indeks.
Kui teha päring, millega otsitakse isikut, kelle perenimi on Aamer, siis peab
andmebaasisüsteem lugema indeksifaili (mis on eeldatavalt andmefailist palju
väiksem).
Andmebaasisüsteem peab leidma indeksist kirje, mis sisaldab väärtust
"Aamer". Kuna indeks on sorteeritud, saab kasutada kahendotsingut.
Indeksist leiab see vastavate kirjete aadressid andmefailides.
23

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
2.2.3.8 Lihtne hõre indeks
Andmed on failides indekseeritud veeru väärtuste järgi sorteeritud. Andmefail
on jaotatud plokkideks. Indeksipuu lehtedeks on viited plokkidele. Näiteks on
andmefail sorteeritud isiku perenime järgi.
Indeksiplokk
Indeks
Aav
Brown
Hunt
...
...
...
Aav
...
...
...
Brown
...
...
...
Tabeliplokk
Hunt
...
...
...
...
Joonis 4Lihtne hõre indeks.
SELECT *
FROM Isik
WHERE perenimi='Aav';
Kui otsitakse tudengit perenimega "Aav", siis indeksi alusel leitakse, et selle
isiku andmed peavad olema tabeliplokis nr. 1 (kuna plokis nr. 2 on juba isikud,
kelle perenimed on alates perenimest 'Brown'). See plokk loetakse mällu ja
mällu loetud plokis toimub otsimine juba kiiresti.
2.2.3.9 B-puu indeks
Tavaliselt on indeksi struktuurina kasutusel B-puu struktuur. B-puu indeksi
(ingl. k. balanced tree) struktuur on tasakaalustatud puustruktuur (hierarhiline
struktuur).
Seega – B-puu tähendab "tasakaalustatud puu" (ingl. k. balanced tree) mitte
kahendpuu (ingl. k. binary tree). Kahendpuu on B-puu erandjuhtum.
24

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
TABELiplokid
Juur
KING
Leht
BLAKE
JAMES
MILLER
TURNER
ADAMS
ALLEN
BLAKE
CLARK
FORD
JAMES
JONES
KING
MARTIN
MILLER
SCOTT
SMITH
TURNER
WARD
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
ROWID
Joonis 5B-puu indeksi ülesehituse põhimõte.
SMITH
ALLEN
WARD
JONES
MARTIN
BLAKE
CLARK
SCOTT
KING
TURNER
ADAMS
JAMES
FORD
MILLER
B-puu indeks koosneb indeksiplokkidest, mis on organiseeritud
tasakaalustatud puu põhimõttel. Puu koosneb sõlmede (tippude) hierarhiast.
Igal sõlmel (v.a. juur) on üks vanem sõlm ja null või rohkem järglassõlme.
Leheks nimetatakse sellist sõlme, millel pole ühtegi järglast. Puu sügavus on
maksimaalne tee pikkus juureks olevast sõlmest leheks olevasse sõlme.
Tasakaalustatud puus on juureks olevast sõlmest ühesuguse pikkusega tee
kõigisse lehtedeks olevatesse sõlmedesse.
Tasakaalustatud puu
perenimega isikuid)
Tasakaalustamata puu
(kui lisatud palju
A-tähega algava
Blake
Adams
Johnson Blake Appelby
King Johnson Archer
King King King
Miller
Turner
Miller
Turner
Joonis 6Indeksipuu tasakaalustamine.
Iga B-puu indeksiplokk sisaldab endas:
• Võtmeväärtusi (indekseeritava veeru väärtusi). See võtmeväärtus on
enamasti täpne koopia indekseeritava veeru väärtustest või arvutatakse
25

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
selle põhjal. Seega – kuna nt. primaarvõtmele luuakse indeks
automaatselt, siis mida suurem on primaarvõti, seda suuremaks kujuneb
ka indeks. Mõnikord kasutatakse pakkimisalgoritme, et vähendada
võtmeväärtuse suurust. Nt. väärtus, mis salvestatakse indeksiplokki, võib
endast kujutada arvväärtust, mis arvutatakse lähtuvalt vastavast veeru
väärtusest.
• Viiteid teistele indeksiplokkidele.
• Kõige madalama taseme indeksiplokid sisaldavad veeru väärtusi ja viita
vastavaid andmeid sisaldavate asukohale andmebaasis (tabeli plokkides).
B-puu indeksi plokkides on indeksi kirjed võtmeväärtuse järgi sorteeritud.
Samuti sisaldavad need plokid viiteid eelmisele ja järgmisele
indeksiplokile, mis võimaldab käia indeks läbi kasvavas või kahanevas
järjekorras ja kasutada ">", "

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Joonis 7B-puu indeksi näide.
Kui soovitakse lugeda väärtuseid mitteindekseeritud veergudest tuleb neid
leitud aadressi alusel lugeda teisest ketta piirkonnast (võrreldes sellega, kust
loeti indeksi andmeid). See põhjustab palju kõvaketta mittejärjestikusi I/O
operatsioone. Kui tabelid ja B-puu indeks on mahukad võib juhtuda, et
andmeid tuleb lugeda isegi teiselt kõvakettalt. Hüpped teistesse ketta
piirkondadesse ja sellest tulenev ajakulu ongi põhjuseks, miks B-puu indeksid
sobivad paremini selliste SQL päringute jaoks, mis toovad välja vähe ridu.
2.2.3.10 Soovitused B-puu indeksi kasutamiseks
Indekseerimine on üks võtetest, mille abil on võimalik oluliselt tõsta
andmetega opereerimise kiirust. Indekseerimise pealt maksimaalse efekti
saavutamiseks tuleb indekseeritavaid veerge valida teatavate kriteeriumite
alusel:
27

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• Tabel on suur ning tüüpilised päringud toovad välja vaid väikese osa
tabeli ridade koguarvust. Tüüpiliselt tõstab B-puu indeks oluliselt
päringutele vastamise kiirust juhul, kui päringud indekseeritud veeru
põhjal toovad välja kuni 4 % tabeli ridade koguarvust.
• Indekseerida tuleks kõik veerud, milles peavad olema unikaalsed
väärtused või milles olevad väärtused on suhteliselt unikaalsed (vähe on
korduvaid väärtusi). See tähendab, et indekseeritava veeru selektiivsus
peab olema suur.
veeru selektiivsus (protsentides) =(veerus olevate erinevate väärtuste
arv)*100 / (kõigi veerus olevate väärtuste arv)
• Indekseerida kõik primaarvõtmete poolt hõlmatud veerud ning veerud
millele on loodud unikaalsuse kitsendus. Tegelikult loovad paljud
andmebaasisüsteemid (nt. Oracle) taoliste veergude jaoks indeksid
automaatselt, kuid iga DBMSi puhul tuleb see üle kontrollida. Selliste
veergude indekseerimise põhjus on toodud eelmises punktis – need
veerud on kõige selektiivsemad, s.t. neis korduvad väärtused puuduvad.
• Veeru V indekseerimist võib põhjendatult kaaluda, kui veerus V on küll
palju korduvaid väärtusi, kuid tüüpilised päringud kasutavad (WHERE
tingimuses) just neid väärtusi, mille esinemissagedus on teiste väärtuste
omast väiksem. Statistika tabeli veerus olevate väärtuste jaotuse kohta
annab andmebaasisüsteemile aluse otsustada, milliste päringute puhul
kasutada indeksit ja milliste puhul mitte. Kui võimalik, võiks taolise veeru
korral luua tingimusliku indeksi – indeks luuakse vaid teatud
(vähemesinevate) väärtuste kohta veerus V.
• Veeru V indekseerimist võib põhjendatult kaaluda, kui veerg sisaldab palju
määramatusi (NULL), kuid päringus küsitakse tavaliselt ridu, milles antud
veerus on väärtus olemas. Indeksites enamasti NULLe ei salvestata ja
seetõttu päring:
SELECT *
FROM Tabel1
WHERE veerg1 IS NULL;
indeksit ei kasuta, kuigi see on veerule veerg1 loodud.
• Indekseerida veerud, mida kasutatakse sageli kitsendustes (SELECT
lause WHERE klauslis) või tabelite ühendamisel (tüüpiliselt samuti
päringutega seoses). Indeksit kasutav päring saab väga kiiresti vastata
EXISTS() või NOT EXISTS() kasutatavatele päringutele, kui päring
tehakse ainult indekseeritud veergude põhjal. Sellisel juhul saab päringule
vastata juba indeksi põhjal ja baastabelist ei pea üldse andmeid lugema.
Indeks sisaldab vähemalt üks kord väärtust, kui selline väärtus leidub ka
baastabeli indekseeritud veerus.
• Indeksi kasutamine annab eriti hea tulemuse, kui päringule saab vastata
ainult indeksit kasutades ilma, et andmebaasisüsteem peaks pöörduma
andmefailide poole.
28

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
SELECT klient, AVG(summa) AS keskm
FROM Arve
GROUP BY klient
Kui indekseerida nii veerud klient kui ka summa, siis saab tulemuse välja
arvutada vaid indeksi põhjal, ilma andmefaili poole pöördumata.
B-puu indeksi indeksiplokkides on indeksi kirjed võtmeväärtuse järgi
sorteeritud. Andmebaasisüsteem saab seda ära kasutada, kui BETWEEN
predikaati, ORDER BY või GROUP BY klauslit, UNION või DISTINCT
operatsiooni (kasutavad sisemisel tasemel sorteerimist) sisaldava päringu
täitmiseks kasutatakse indeksit.
• Indekseid ja B-puud tuleb uuendada, kui lisatakse uus rida, kustutatakse
rida või muudetakse indekseeritud veeru väärtust. Pragmaatiline käitumine
– kui kohe pärast tabeli loomist on vaja sisestada suur hulk ridu (tabeli
maht kasvab üle 5%) ja ei ole vaja sellest tabelist midagi otsida, siis luua
kõigepealt tabel, siis sisestada read ja lõpuks luua indeksid.
Peale selle võtavad indeksid kettaruumi – mida pikem on indekseeritav väli ja
mida erinevamad on selle välja väärtused, seda rohkem ruumi võtab indeks.
Seega tuleks pragmaatilistel põhjustel näiteks primaarvõtme veeru (veergude)
puhul hoolikalt kaaluda väljapikkusi, sest primaarvõtmele luuakse enamasti
indeks automaatselt.
Indeksid võtavad ka ruumi muutmälus, sest indeksi kasutamisel loeb
andmebaasisüsteem indeksiplokke muutmällu.
Mida suurem on tabel, seda rohkem on indeksist kasu, kuid seda suuremad
on ka indeksi ülalpidamise kulud – ajakulu uuendamisel ja indeksi all olev
kettaruum. Lighstone et al. (2007) märgib, et tüüpiliselt kulub andmebaasis
10% kuni 20% salvestusruumist indeksite andmete salvestamiseks. Kui see
suurus on üle 25%, siis tuleks andmebaasis olevad indeksid põhjalikult
ülevaadata ning üleliigsed indeksid eemaldada.
Indekseerimise mõju andmete muutmisele ja kustutamisele on kahetine.
Üheltpoolt saab indeksi abil muudetavad ja kustutavad read kiiremini üles
leida. Teisalt tingivad muudatused indekseeritud veerule vastavates väljades
või ridade lisamine/kustutamine ka indeksi ümberkorraldamise vajaduse, mis
omakorda võtab aega.
Seepärast on soovitav:
• mõelda veergude indekseerimisele eelkõige tabelites, kus muutmised on
küllalt harvad võrreldes päringutega,
• mitte indekseerida tabelites veerge, milles olevaid andmeid tuleb sageli
muuta.
Suhteliselt kõige rohkem kasu on indeksitest selliste tabelite puhul, mis on
suured, mida uuendatakse harva ja millest otsitakse sageli andmeid.
29

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Olenevalt andmebaasisüsteemist käsitletakse NULLe erinevalt. Olgu tabel
Tudeng. Veerg perenimi on mittekohustuslik. Sellele luuakse indeks.
Tavaliselt NULLe ei indekseerita ja seega järgnevad päringud ei kasuta
perenime veerule loodud indeksit:
SELECT *
FROM Tudeng
WHERE pnimi IS NULL;
SELECT Count(*) AS arv FROM Tudeng;
Viimase päringu puhul on indekseeritud ridade arv väiksem kui tegelikult
tabelis olevate ridade arv ja seetõttu pole andmebaasisüsteemil mõtet indeksit
kasutada vaid toimub tabeli läbiskaneerimine.
Sellistele veergudele, mida kasutatakse koos ühes ja samas WHEREklauslis,
on mõtet luua ühine, liitindeks e. mitmekomponendiline (mitut
veergu hõlmav) indeks. Millal liitindeksit kasutada?
• Veerge kasutatakse sageli üheskoos päringu WHERE klauslis ning selle
alamtingimused on seotud AND operatsiooniga.
SELECT *
FROM Isik
WHERE eesnimi='Jaan' AND perenimi='Mets';
• Veergude kombinatsioon annab oluliselt parema selektiivsuse (või koguni
garanteerib unikaalse väärtuse) kui iga veerg eraldi.
• Tüüpilised päringud kasutavad päringu tingimuses ühte ja sama veergude
komplekti vaadeldavast tabelist. Sellise veergude komplekti koondamisel
indeksisse saavutatakse, et päringud saavad vastused kätte otse
indeksist, ilma tabeli poole pöördumata.
Liitindeksite kasutamisel on oluline komponendiks olevate veergude järjestus
indeksi loomise lauses. Oletame, et meil on tabel ja indeks:
t(a, b, c, d, e) Primaarvõti(e);
CREATE INDEX t_idx ON t(a, b, c);
Loodud indeksit kasutatakse näiteks järgmiste päringute täitmisel:
SELECT * FROM t WHERE a=:a;
SELECT * FROM t WHERE a=:a AND b=:b;
SELECT * FROM t WHERE a=:a AND b=:b AND c=:c;
Päring, mille tingimuses ei ole kõige esimest liitindeksisse kuuluvat veergu
(antud juhul a), sellist liitindeksit ei kasuta.
SELECT * FROM t WHERE b=:b;
30

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Liitindeks tuleks koostada nii, et esimeses veerus on kõige rohkem erinevaid
väärtuseid ja esimest veergu kasutatakse kõige sagedamini päringutes.
(Mõnikord muidugi need tingimused ei ühti). Tabelile võib vajadusel luua ka
mitu liitindeksit.
Tabelile võib luua mitu B-puu indeksit. Maksimaalne arv sõltub konkreetsest
andmebaasisüsteemist. Soovitus on, et tabelite puhul kus on andmete
muutmisi ja päringuid enam-vähem võrdselt võiks olla kuni 5 B-puu indeksit.
Kui tabelite põhjal tehakse palju päringuid ja vähe muudatusi (analüüsi- ja
otsustus-süsteemid), siis võiks tabelil olla kuni 12 indeksit. Kui tabelis on
muudatusi rohkem kui päringuid, siis peaks indeksite arv olema väiksem
kui 5.
2.2.3.11 B-puu indeksi täiendamine
Indeks võib andmete tabelisse lisamise/muutmise käigus fragmenteeruda.
B-puu indeksi fragmenteerumise tunnused on järgmised.
• Indeksipuu lehtedes pole võtmeväärtused enam järjekorras.
• Indeksipuu lehtede täituvus on erinev.
• Indeksipuu on tasakaalust väljas – tee pikkus igast puu lehest puu-juureni
ei ole ühesugune.
Sellised probleemid tekivad praktikas peale seda, kui lisada/muuta vähemalt
5% tabelis olevatest andmetest. Peale seda oleks aeg indeks
reorganiseerida. Selleks on kaks võimalust.
• Kasutada andmebaasisüsteemis ette nähtud indeksi
ümber-organiseerimise lauset (erinevates andmebaasisüsteemides on
need erinevad). SQL standard sellist lauset ei kirjelda. Näiteks:
ALTER INDEX index REBUILD;
• Kustutada indeks ja luua see uuesti. See võtab üldjuhul
ümberorganiseerimisest rohkem aega.
Tabelisse T suure hulga ridade lisamisel on töökiiruse huvides mõistlik
kustutada kõik T-ga seotud sekundaarsed indeksid, lisada read ja seejärel
luua uuesti eelnevalt kustutatud indeksid. Kokkuvõttes võtab andmete
lisamine ja korrastatud indeksite saavutamine niimoodi kõige vähem aega.
31

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
2.2.3.12 Kahendpuu
Kahendpuu (binary-tree) on puu, mille igal sõlmel on null kuni kaks alluvat.
Tegemist on B-puu struktuuri erijuhtumiga. Igas indeksipuu sõlmes on kaks
viidet. Üks viide viitab sõlmele, mis viitab väärtustele, mis on antud sõlme
väärtusest väiksemad ning teine viitab sõlmele, mis viitab väärtustele, mis on
antud sõlme väärtusest suuremad.
Kõige kõrgema taseme indeksiplokis (puu juures) asub selline väärtus, millest
suuremaid ja väiksemaid väärtusi on võrdselt 50%. Kõige esimene plokk
jagab väärtuste hulga kaheks alamhulgaks. Puu juureks olev plokk sisaldab
viiteid kahele järgmisele plokile, mis omakorda sisaldavad järgmisi viiteid,
jagades selliste viidetega tekkivaid väärtuste alamhulki järjest väiksemaks,
kuni viimasel tasemel jõutakse rea aadressideni.
21
10 22
5 14 19 30
17
Joonis 8Kahendpuu näide.
Jõudmaks sõlmeni, mis sisaldab väärtust "17" tuleb käia läbi tee
21=>22=>19=>17. Viimasena loetav sõlm, mis on ka puu leheks, sisaldab
omakorda viidet ridade asukohale, mille indekseeritud veerule vastavas väljas
oli väärtus 17.
Veergude väärtused paigutatakse indeksiplokkidesse selliselt, et säiliks
indeksiplokkide puu tasakaal – st. tuleb tagada, et kui indeksiplokk sisaldab
endas kahte viidet alam-indeksiplokkidele, siis kummaski alamharus oleks
võrdne arv kirjeid (veeru väärtusi.).
See tähendab, et ridade lisamisel ja eemaldamisel tabelist tuleb indeksid
andmebaasisüsteemi poolt uuesti arvutada ja indeksipuu struktuuri vastavalt
saadud indeksi väärtustele muuta, et vältida indeksipuu tasakaalust välja
viimist. Kui indeksipuu struktuuri ridade lisamisel mitte muuta, läheks
indeksipuu tasakaalust välja näiteks siis, kui alfabeedi lõputähtedega nimesid
lisataks rohkem kui algustähtedega algavaid nimesid.
32

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Indeksi arvutamise järjekord rea lisamisel või eemaldamisel – leitakse
indeksisse lisatav väärtus.
Indeksipuu organiseeritakse arvestusega, et indeksipuu juurplokist otsima
hakates oleks ja sealt kummagi alam-indeksiploki lugemise vajaduse
tõenäosus 0,5.
2.2.3.13 Räsiväärtustel põhinev indeks
Räsiväärtustel põhineva indeksi (hash index) loomisel arvutatakse
indekseeritud veergudele vastavates ridade väljades olevate väärtuste põhjal
välja rea füüsilise aadressi asukoht indeksis.
Rea füüsilise aadressi asukoha arvutamiseks rakendatakse tabelis olevale
väärtustele spetsiaalset funktsiooni – hash e. räsifunktsiooni. Indeks
sisaldab räsifunktsiooni väärtuseid ja viiteid rea tegelikule asukohale (rea
füüsilist aadressi).
Probleemid tekivad, kui rea füüsilise aadressi asukoha leidmise järel selgub,
et antud asukohas juba asub mõni aadress. Tekivad kokkupõrked. Kui tekib
kokkupõrge, siis tuleb üks kokkupõrkes osalenud aadress paigutada ülevoolu
piirkonda – see on spetsiaalne piirkond indeksis, kuhu paigutatakse üks
kokkupõrkes osalenud aadressidest.
väärtus väärtus väärtus
Rida, mis lisatakse tabelisse.
Määrab rea
aadressi
asukoha
indeksis
Räsifunktsioon f(x)
Räsil põhinev indeks
räsifunktsiooni väärtus
räsifunktsiooni väärtus
räsifunktsiooni väärtus
aadress
aadress
aadress
Andmefail – rea
tegelik asukoht
rida 1
rida 2
rida 3
Joonis 9Räsiväärtustel põhinev indeks.
2.2.3.14 Indeksi struktuuri järgi organiseeritud tabelid
Indeksi struktuuri järgi organiseeritud tabelis on kõik tabeli andmed paigutatud
B-puu indeksile vastavasse salvestusstruktuuri, kusjuures puu on
organiseeritud mõnes tabeli veerus (klastri võtmes) olevate väärtuste järgi.
33

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
See tähendab, et füüsiliselt on tabelisse kuuluvad andmed klastri võtme järgi
sorteeritud.
Oracles nimetatakse sellise idee järgi loodud tabelit index-organized table.
Oracles saab klastri võtmeks olla vaid primaarvõti Microsoft SQL Serveris
kasutab analoogilist ideed klasterdatud indeks.
(vt. http://www.sql-server-performance.com/clustered_indexes.asp ). Microsoft
SQL Serveris võib, kuid ei pruugi, olla klastri võtmeks primaarvõti.
Puu lehtedeks on tegelikud tabeliplokid. Sellest tulenevalt:
1. Andmete puustruktuurist otsimisele järgnev andmete lugemine ei põhjusta
uute plokkide lugemist, sest B-puu lehed ongi tegelikud tabeliplokid.
2. Kuna puu lehtedeks on tegelikud tabeliplokid, on tabeli read kettal
füüsiliselt järjestatud võtme väärtuste järjekorras. See suurendab I/O
(sisend/väljund) operatsioonide kiirust kui võtmevälja põhjal otsitakse ja
loetakse tabelist suur hulk füüsiliselt üksteisele järgnevaid ridu.
Loomulikult saab iga tabeli kohta olla ainult üks taoline B-puu struktuur.
MS SQL Serveris soovitatakse klastri võti valida järgmiste kandidaatide seast.
• Välisvõtme veerud. Sellest on kasu tabelite ühendamisel, sest sama
välisvõtme väärtusega read on füüsiliselt kõrvuti ning ühendamise
operatsiooni läbiviimine läheb seetõttu kiiremini.
• Veerud, mille põhjal tehakse sageli otsing, mis hõlmab väärtuste vahemiku
otsimist. Näide:
SELECT *
FROM Isik
WHERE perenimi BETWEEN 'Aas' AND 'Berendson';
Kui perenime järgi tehtavad päringud on olulised, neid tehakse sageli ja nad
toovad välja suure hulga ridu, tuleks kaaluda tabeli organiseerimist B-puu
struktuuri perenimede järgi.
• Veergudele, mida kasutatakse sageli ORDER BY või GROUP BY klauslis.
Andmete lisamine või klastri võtme veergudes andmete muutmine on
aeglane, sest rida tuleb paigutada failis järjekorras õigesse kohta. Kui klastri
võtmel on monotoonselt (n, n+1, n+2 jne) kasvav väärtus, siis satuvad
korraga lisatavad read andmefailis ühte plokki ja see tekitab kuuma punkti
(ingl. k. hot-spots), kus lisamise koormus on suurem kui mujal.
34

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Joonis 10Klasterdatud indeks MS SQL Serveri näitel.
35

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
2.2.3.15 Joini indeks
Gulutzan (2003) andmetel võimaldavad mitmed andmebaasisüsteemid luua
indeksi üle mitme tabeli .
Indeks
Tabel1
Indeks
Tabel2
A
Rida 1.1
B
Rida 2.1
B
Rida 1.2
C
Rida 2.2
C
Rida 1.3
F
Rida 2.3
A
B
B
C
C
F
Joini indeks
Rida 1.1
Rida 1.2
Rida 1.3
Rida 2.1
Rida 2.2
Rida 2.3
Joonis 11Joini indeks.
Kui luua joini indeks korraga ühe tabeli primaarvõtmele ja teise tabeli
välisvõtmele, siis on lihtne teha ühendamist kasutavaid päringuid:
SELECT *
FROM Tabel1, Tabel2
WHERE Tabel1.veerg1=Tabel2.veerg1
Päringu täitmise programm peab käima läbi indeksi ja iga võtmeväärtuse
korral kontrollima, kas ka järgnev võtmeväärtus on sama. Kui jah, siis see
tähendab et vastava võtmeväärtusega rida tuleb tulemusse tuua.
Sellise indeksi kasutamine aeglustaks päringut, mis toimub vaid ühe tabeli
põhjal. Siinkohale rõhutame, et andmebaasisüsteemi asi on otsustada, kas ja
millises olukorras indeksit kasutada. Seega heatasemeline
andmebaasisüsteem ei kasuta indeksit päringu q täitmiseks, kui selle
kasutamine võiks q täitmist aeglustada võrreldes indeksi mittekasutamisega.
Selleks, et andmebaasisüsteem saaks langetada õige otsuse indeksi
kasutamise/mittekasutamise kohta, peab süsteemi käsutuses olema
võimalikult täpne andmebaasi statistika.
36

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
2.2.3.16 Bitmap-indeks
Mõningates andmebaasisüsteemides (nt. Oracle) saab kasutada bitmap
indekseid. Oletame, et tabelis T on n rida ja tabelis T on veerg V. Veerule V
loodud bitmap indeks on kogum bitivektoreid, pikkusega n. Iga veerus V oleva
ühe võimaliku väärtuse kohta sisaldub bitmap indeksis üks bitivektor (Garcia-
Molina & Ullman 2000). Järgnevalt kirjeldatakse bitmap indeksit näite varal.
Arve
arve_nr arve_kuupäev tasumise_viis summa ostja_tüüp
1 01.04.2002 sularahas 1000 eraisik
2 01.04.2002 ülekandega 2000 firma
3 05.04.2002 ülekandega 5000 firma
4 08.04.2002 arvega 3000 eraisik
5 10.04.2002 ülekandega 1500 eraisik
6 12.04.2002 arvega 2200 firma
Siin on 1, sest tabelis Arve on
esimeses reas veerus tasumise_viis
väärtus "sularahas".
Bitivektor
tasumise_viis=
'sularahas'
tasumise_viis=
'ülekandega'
tasumise_viis=
'arvega'
1 0 0
0 1 0
0 1 0
0 0 1
0 1 0
0 0 1
Iga sisend (bitt) bitivektoris vastab ühele tabeli reale. Biti väärtus sõltub
väärtusest tabeli veerus.
Kriteeriumid Bitmap-indeksi kasutamiseks.
• Erinevalt B-puu indeksitest on bitmap indeksid on kasulikud selliste
veergude puhul, kus on vähe võimalikke väärtuseid. Kõige parema efekti
annavad nad veergude puhul kus:
(unikaalsete väärtuste arv veerus/ ridade arv veerus)*100

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
• B-puu indeksi andmemaht võib kujuneda suuremaks kui indekseeritava
tabeli andmemaht. Samas on bitmap indeksi andmemaht väga palju
väiksem indekseeritava tabeli andmemahust.
• Vähemalt Oracle andmebaasisüsteemis on bitmap indeksit ebasobiv
kasutada andmebaasides, kus toimuvad sagedased ja paralleelsed
andmete muutmise transaktsioonid. Seda põhjusel, et bitmap indeksi
täiendamine rea muutmise järel põhjustab suure hulga tabeli ridade
lukustumise.
• Eelnevast punktist tulenevalt kasutataks bitmap indekseid andmeaitades
(ingl. k. data warehouse).
• Bitmap indeksid on kõige efektiivsemad päringute puhul, mis sisaldavad
mitmeid tingimusi WHERE klauslis. Read, mis vastavad mõnele, kuid mitte
kõigile tingimustele filtreeritakse välja juba enne tabeli poole pöördumist.
SELECT *
FROM Arve
WHERE (tasumise_viis='sularahas' OR tasumise_viis='ülekandega') AND
(ostja_tüüp='eraisik');
(tasumise_viis='sularahas' ) OR (tasumise_viis= 'ülekandega' AND
ostja_tüüp='eraisik')
tasumise_viis=
'sularahas'
tasumise_viis=
'ülekandega'
ostja_tüüp=
'eraisik'
1 0 1
0 1 0
0 1 0
0 0 1
0 1 1
0 0 0
AND ja OR operatsioonide läbiviimine toimub biti kaupa. Tulemuseks on
bitivektor, mida saab kasutada järgmistes AND või OR operatsioonides.
tasumise_viis= tasumise_viis= 'ülekandega'
'sularahas' AND ostja_tüüp='eraisik'
1 0
0 0
0 0
0 0
0 1
0 0
Kollasega on tähistatud päringu tulemuseks olevaid ridu tähistavad bitid.
tasumise_viis='sularahas' OR (tasumise_viis= 'ülekandega' AND
ostja_tüüp='eraisik')
1
0
0
0
1
0
38

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Kollasega on tähistatud päringu lõpptulemusena leitavad read.
arve_nr arve_kuupäev tasumise_viis summa ostja_tüüp
1 01.04.2002 sularahas 1000 eraisik
2 01.04.2002 ülekandega 2000 firma
3 05.04.2002 ülekandega 5000 firma
4 08.04.2002 arvega 3000 eraisik
5 10.04.2002 ülekandega 1500 eraisik
6 12.04.2002 arvega 2200 firma
Joonis 10. Bitmap indeksi kasutamine
Bitmap indeksit on kõige parem kasutada suure andmemahuga (kuna
indeksi andmemaht kujuneb väikeseks) ja harva muudetavates tabelites.
On olemas meetodeid, kuidas Bitmap indeksi suurust vähendada. Selliste
meetodite alusel loodud indekseid nimetakse pakitud bitmap indeksiteks. Nad
kõik lähtuvad ideest, et bitivektoris on rohkem 0-e kui 1-sid ja 0-d võiks
kuidagi kodeerida, et neid poleks vaja kõiki eraldi säilitada. Selle teema kohta
võib lugeda (Garcia-Molina & Ullman, 2000, lk. 227-229).
2.2.3.17 Bitmap join indeks
Bitmap indeks luuakse päringus ühendatavatele tabelitele. See aitab päringu
täitmise programmil rakendada ühendatavatele tabelitele enne ühendamist
piiranguid ja vähendada seega ühendamise operatsioonis osalevaid ridu.
Auto
auto_id tootja auto_nr
1 Volvo 863AEH
2 Mercedes 121PPT
3 Scania 602OOH
4 Volvo 452EPT
5 Saab 789AAK
Omamine
omanik auto algus lõpp
1 1 01.01.2000 22.08.2002
1 2 12.02.1999
2 1 23.08.2002
3 4 14.02.2001
3 5 15.05.1997 16.05.2002
CREATE BITMAP INDEX auto_omamine_bjix
ON Omamine(auto.mark)
FROM Auto, Omamine
WHERE Auto.auto_id=Omamine.auto
LOCAL NOLOGGING;
Näide indeksi struktuuri kohta:
39

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
omanik Volvo Mercedes Scania Saab
omamise rida 1 1 0 0 0
omamise rida 2 0 1 0 0
omamise rida 3 1 0 0 0
omamise rida 4 1 0 0 0
omamise rida 5 0 0 0 1
Selline indeks aitab näiteks kiirendada päringut:
SELECT A.tootja, O.algus, O.lopp
FROM Auto A, Omamine O
WHERE A.auto_nr=O.auto AND A.tootja='Volvo';
2.2.3.18 Tabeli läbiskaneerimine vs. indeksi kasutamine
Andmete otsimiseks võib andmebaasisüsteem kasutada järgnevaid
meetodeid (ingl. k. access method).
• Tabeli läbiskaneerimine (tabeli plokkide lugemine ilma indeksit
kasutamata). Andmebaasisüsteem peab igast loetud plokist otsima
tingimustele vastavaid ridu. Mida suurem on tabel, seda rohkem kulub
tabeli läbiskaneerimiseks aega. Võimalikud strateegiad:
1. Vaadatakse läbi kõik plokid (ingl. k. full table scan)
2. Vaadatakse läbi osa plokke – võimalik nt. Siis, kui tabeli andmed on
plokkides sorteeritud ja otsing toimub veeru järgi, mille alusel
sorteerimine on toimunud.
• Indeksi kasutamine. Indeksi kasutamisel on võimalikud variandid.
1. Andmebaasisüsteem loeb indeksit. Indeksist leitud ridade füüsiliste
aadresside alusel loeb andmebaasisüsteem tabelite plokke.
2. Andmebaasisüsteemil piisab vajalike andmete leidmiseks
(päringule vastuse saamiseks) ainult indeksi lugemisest.
SELECT *
FROM Aine
WHERE aine_kood>'IDU3381';
Andros (2002 lk. 39) märgib, et tavaliselt arvatakse nagu oleks tabeli
läbiskaneerimine aeglane ja ebaefektiivne võrreldes indeksi kasutamisega.
Indeksi kasutamine ei ole alati kasulik. Andmebaasisüsteem peab
oskama valida, millal indeksit kasutada ja millal mitte.
Andmebaasisüsteemil oleks indeksi lugemise asemel mõistlik kasutada
tabeli läbiskaneerimist kui küsitakse andmeid ka sellistest veergudest,
mis indeksisse ei kuulu ja on täidetud üks järgmistest tingimustest.
• Tabel on suur. Päring leiab suure hulga tabelis olevaid ridu
(erinevatel andmetel vähemalt 35% või vähemalt 50% ridadest).
• Tabel on suhteliselt väike (nt. 100 rida või vähem, ja mõned
veerud).
40

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Indeksi kasutamisel otsitakse kõigepealt rea aadress indeksipuust. Seejärel
tuleb lugeda rida mingist tabeliplokist. Tabeliplokkides paiknevad read
enamasti juhuslikus järjekorras. Indeksi abil andmete otsimisel võib
andmebaasisüsteem lugeda ühte tabeli plokki mitu korda. Kui otsitakse
piisavalt suurt hulka ridu, siis on tabeli läbiskaneerimine kiirem kui otsing
indeksi põhjal.
Kui tabel on nii väike, et mahub ühe tabeliplokki, siis kiirem on lugeda kohe
see tabeliplokk, selle asemel et lugeda kõigepealt indeksit ja siis ikkagi see
sama tabeliplokk.
Mõelge, kas kasutaksite raamatu indeksit, kui Teie ülesandeks oleks kogu
raamat läbi lugeda või kui raamat oleks ainult mõni lehekülg paks.
2.2.3.19 Indekseerimise rusikareeglid
Lighstone et al. (2007) loetleb indekseerimise rusikareeglid (reeglid, mille
rakendamine annab enamasti hea tulemuse).
1. Indekseeri kõik primaarvõtmed (seda teeb enamik
andmebaasisüsteeme automaatselt) ja enamik välisvõtmetest.
2. Veerud, millele sageli viidatakse SQL lause WHERE klauslis, on
potentsiaalselt head indekseerimise kandidaadid.
3. B-puu indeksit saab andmebaasisüsteem kasutada nii päringute puhul,
kus rea otsing toimub ühe kindla väärtuse järgi (näide: isik_id=34222)
kui ka päringute puhul, kus ridu otsitakse mingi väärtuste vahemiku
alusel (näide: isik_id BETWEEN 432432 AND 432499).
4. Igal tabelil võiks olla üks klasterdatud indeks, mille alusel on tabeli read
andmebaasi sisemisel tasemel sorteeritud.
5. Väldi kattuvaid indekseid – indeksid, milles on üks või rohkem ühine
veerg. Sellised indeksid tekitavad andmebaasisüsteemile segadust ja
süsteem ei pruugi koostada tänu sellele lausele kõige paremat
võimalikku täitmisplaani. Üks põhjus, miks andmebaasis võidakse luua
kattuvaid indekseid on see, et uue indeksi loomisel ei arvestata
andmebaasis automaatselt loodud indeksitega.
6. Lindeks ei ole tasuta lõuna – lisa indeks vaid siis, kui seda on hädasti
vaja.
7. Töökiiruse huvides võib aja möödudes liitindeksisse veerge juurde
lisada, sealt veerge eemaldada – vastavalt hetkel kõige olulisematest
päringutest tulenevatele nõudmistele. Mida rohkem veergusid on
hõlmatud liitindeksi I poolt, seda vähem on I-st kasu päringu korral, mis
ei kasuta täpselt I poolt hõlmatavaid veerge.
8. Ole veeru indekseerimisega väga ettevaatlik, kui selles veerus
muudetakse sageli andmeid. Andmete muutmine tingib vajaduse
muuta ka indeksit ja see on suhteliselt aeganõudev protsess.
41

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
9. Indeks ei ole midagi sellist, mida saab luua ja siis unustada.
Andmebaasi administraator peab regulaarselt indeksit jälgima ja
hooldama. Kui indeks hakkab töökiirust kahjustama, siis tuleb see
eemaldada.
10.Väldi B-puu indekseid veergudel, kus on palju ühesuguseid väärtuseid.
11.Indeksid, mille alusel saab vastata päringule ilma tabeli plokke
lugemata (ingl. k. covering index), on kasulikud, kuid praktikas
kasutatakse neid liiga palju. See võib halvendada päringute töökiirust.
12.Bitmap indeksid on kasulikud suurte andmehulkadega (terabaidid,
petabaidid) andmebaasides, eriti andmeaitades.
2.2.3.20 Indeksi kasutamine andmebaasisüsteemi poolt
Andmebaasisüsteemi üks moodul on optimeerija, mille ülesandeks on valida
välja kiireim viis andmekäitluskeele lause täitmiseks. Optimeerimise moodul
peab ka valima, kas ja milliseid indekseid lause täitmiseks kasutatakse.
Optimeerimise moodul koostab päringu täitmisplaani (ingl. k. Query Execution
Plan). Andmebaasisüsteemi üheks võimalikuks funktsionaalsuseks on
analüüsimine, miks mingi päring töötab aeglaselt ja kuidas seda võib
kiirendada.
Näide: Andmebaasisüsteemis PostgreSQL on võimalik kasutada SQL käsku
EXPLAIN, mis näitab päringu füüsilist täitmisplaani (vt. teema 11). EXPLAIN
käsku saab kasutada erinevate päringute täitmisaja hindamiseks. Süntaks:
EXPLAIN [ VERBOSE ] query
See käsk näitab PostgreSQLi poolt genereeritavat lause täitmisplaani.
Täitmisplaan kirjeldab sisemise taseme operatsioonid ning nende täitmise
järjekorra, mida andmebaasisüsteem peab läbi viima välisel või
kontseptuaalsel tasemel esitatud lause täitmiseks. Näiteks juhul, kui
ühendatakse kokku mitu tabelit, näidatakse millise algoritmi alusel ridu
ühendatakse (võimalike algoritmide näited on nested loop join, hash join,
merge join).
Näide:
EXPLAIN SELECT * FROM Emp NATURAL JOIN Dept;
QUERY PLAN
--------------------------------------------------------------------
Hash Join (cost=18.00..42.25 rows=570 width=198)
Hash Cond: ("outer".deptno = "inner".deptno)
-> Seq Scan on emp (cost=0.00..15.70 rows=570 width=108)
-> Hash (cost=16.40..16.40 rows=640 width=92)
-> Seq Scan on dept (cost=0.00..16.40 rows=640 width=92)
(5 rows)
Andmebaasisüsteem koostab mitu võimalikku täitmisplaani ja arvutab
andmebaasi statistikat kasutades välja iga plaani maksumuse – hinnangu
42

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
lause täitmise kiirusele. Seejärel valib andmebaasisüsteem plaanide hulgast
kõige madalama maksumusega plaani. Selle plaani alusel täidab
andmebaasisüsteem kasutaja poolt esitatud lause.
Plaani maksumuse arvutamisel ei arvestata sellega, kui palju kulub aega
serveril olevate ridade saatmiseks kliendile. See aga võib olla koht, kus tekib
üsna suur ajakulu.
Näide: Andmebaasisüsteemis MS Access (2007) saab kasutada vahendit
Perfomance Analyzer.
Näide: Andmebaasisüsteemis MS Access (2007).
• Primaarvõtme alusel luuakse automaatselt indeks.
• Täiendava unikaalsuse kitsenduse UNIQUE alusel luuakse
automaatselt indeks.
2.3 Klassifikaatorite tabelid
Näited.
- Kliendi liik
- Kliendi seisundi liik
- Amet
- Riik
- Keel
- Kauba liik
Klassifikaatorite tabelis hoitavad andmed kirjeldavad mingis teises – tavaliselt
palju suuremas – tabelis olevaid andmeid. Taoliste tabelite kasutamine aitab
kontrollida kasutajate poolset andmete sisestust. Näiteks kasutaja saab
registreerida tabelis Klient olevasse välisvõtme veergu ainult sellise kliendi
liigi koodi, mis leidub tabelis Kliendi_liik.
Klassifikaatorite tabelites olevad andmed tuleb andmebaasis registreerida
enne andmebaasi kasutuselevõttu lõppkasutajate poolt. Ilma nende
andmeteta ei saa lõppkasutajad andmebaasi kasutada.
Juba kontseptuaalse andmebaasi projekteerimise käigus võib
kontseptuaalses andmemudelis esitada vastavad olemitüübid. Loogilise
disaini käigus tuleb kõik leitud tabelite veerud üle vaadata. Kui mingi veeru
jaoks on teada võimalike väärtuste hulk, siis tuleks selle põhjal luua just
taoline klassifikaatori tabel.
Kliendi_liik(kliendi_liigi_kood, nimetus, kirjeldus)
Primaarvõti (kliendi_liigi_kood)
Alternatiivvõti(nimetus);
Klient (klient_id, eesnimi, perenimi, kliendi_liig_kood)
Primaarvõti(klient_id)
Välisvõti (kliendi_liigi_kood) Viitab Kliendi_liik(kliendi_liigi_kood);
43

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Klassifikaatorite tabelites hoitavad andmed muutuvad harva ja tuleks
dokumenteerida juba andmebaasi projekteerimise käigus (nt. loogilise disaini
faasis). Sellistes tabelites olevate andmete väljapakkumine on konkreetse
allorganisatsiooni ülesanne, kuid nende kinnitamine ja sisestamine peaks
olema andmete administraatori ja juhtkonna otsustada.
Seega ei peaks klassifikaatorite koodid (nt. kliendi liigi kood) olema
surrogaatvõtmed. Selliste koodide väärtused dokumenteeritakse ja
sisestatakse andmebaasi volitatud kasutajate poolt (st. koodi väärtust ei
genereeri süsteem).
Miks on kasulik, et andmebaasi kasutajad saavad ise klassifikaatorite koode
sisestada.
Näide: Kui on kindlalt teada, et kood 2 tähistab püsiklienti, siis saab
püsiklientide andmete leidmiseks teha päringu:
SELECT * FROM Klient WHERE kliendi_liigi_kood=2;
selle asemel et teha päring:
SELECT Klient.* FROM Klient INNER JOIN Kliendi_liik ON
Klient.kliendi_liigi_kood=Kliendi_liik.kliendi_liigi_kood WHERE
Kliendi_liik.nimetus='Püsiklient';
Näide: Kui on teada, et enamik registreeritavaid kliente on "tavalised" kliendid,
keda tähistav kood on 1, siis saab deklareerida tabelis Klient veerule
kliendi_liigi_kood vaikimisi väärtuse 1.
ALTER TABLE Klient ALTER COLUMN kliendi_liigi_kood SET DEFAULT 1;
Samuti tuleb läbi mõelda klassifikaatori koodidele vastavate veergude tüübid.
Näiteks tabelis Kliendi_liik on veerg kliendi_liigi_kood. Milline võiks olla selle
veeru tüüp? Mõttesse tulevad täisarvutüübid INTEGER ja SMALLINT. Milline
nendest tüüpidest valida?
Tüüpi INTEGER kuuluvad täisarvud vahemikus -2147483648 kuni
+2147483647.
Tüüpi SMALLINT kuuluvad täisarvud vahemikus 32768 kuni +32767.
Andmebaasi disainer peaks mõtlema, milline on pikas perspektiivis erinevate
kliendi koodide hulk. Kui see hulk jääb alla 32767, siis tuleks tüübiks valida
SMALLINT.
Sageli pole klassifikaatorite koodid üldse täisarvu tüüpi. Näiteks
rahvusvaheline riikide klassifikaator (ISO 3166 Codes (Countries))
http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
näeb ette, et iga riigi kohta kahetähelise koodi, kolmetähelise koodi ja kolmest
numbrist koosneva koodi. Eesti puhul on need koodid vastavalt "EE", "EST",
44

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
233. Seega, kui hakkate looma tabelit Riik, siis pole mingit mõtet lisada sinna
veergu a'la riik_id, kus on kasutaja väljamõeldud täisarvud. Selle asemel peab
tabelis Riik primaarvõtme veeruks olema veerg, kus on rahvusvaheliselt
väljatöötatud ja tunnustatud koodid.
Füüsiline disain: Kuna klassifikaatorite tabeleid kasutatakse sageli päringutes
tuleks nad kõvaketaste massiivi kasutamise korral paigutada kiirele ja
vähekasutatavale kõvakettale. Kuna sellistes tabelites muutuvad andmed
harva, siis võivad tabeli andmed peaaegu vastava plokki täita (plokki võib jätta
5% vaba ruumi). Kuna sellised tabelid on suhteliselt väikesed, siis indeksite
lisamine neile ei anna tavaliselt erilist kasu. Enamasti hoitakse sageli
kasutatavaid ja väikeseid tabeleid andmebaasisüsteemi poolt mälupuhvris,
kus nende poole pöördumine on väga kiire. Tuleks kontrollida, et
andmebaasisüsteemi mälupuhver on kõigi taoliste tabelite hoidmiseks
piisavalt suur.
2.4 Vaadete disain
Nõudmiste kogumise ja analüüsi käigus leitud vaadete realiseerimine,
kasutades konkreetse andmebaasisüsteemi võimalusi (vt. teema 5).
Jällegi pakuvad erinevad andmebaasisüsteemid erinevaid võimalusi.
• Vaateid ei saa üldse kasutada (ja selline andmebaasisüsteem reklaamib
ennast relatsioonilisena – naerukoht :-) ).
• Vaateid saab luua, kuid läbi vaadete ei saa ilma täiendavat koodi
kirjutamata muuta andmeid baastabelites. Sellise andmebaasisüsteemi
näiteks on PostgreSQL, kus vaate kaudu andmete muutmise
võimaldamiseks tuleb luua reeglid (CREATE RULE käsuga).
• Vaateid saab luua. Läbi vaadete saab muuta andmeid baastabelites
lähtuvalt SQL:1992 standardis kirjeldatud nõudmistest (andmeid ei saa
baastabelites muuta kui vaate alampäring sisaldab ühendamise
operatsiooni).
• Vaateid saab luua. Läbi vaadete saab muuta andmeid baastabelites
lähtuvalt SQL:2008 standardis kirjeldatud nõudmistest (andmeid ei saab
baastabelites muuta ka läbi ühendamise operaatori poole pöördumist
sisaldavate vaadete).
2.5 Julgeolekumehhanismide disain
Nõudmiste kogumise käigus leitud julgeolekule esitatavate nõudmiste
realiseerimine, kasutades konkreetse andmebaasisüsteemi võimalusi
(vt. teema 6).
3. Mõisted
Eesti keeles
Füüsiline disain
Inglise keeles
Physical design
45

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
Eesti keeles
Transaktsioonanalüüs
Sorteerimata fail
Sorteeritud fail
Sorteeritud andmefail, millele on
defineeritud primaarne indeks
Füüsiline kirje
Tabeliruum
Indeks
Primaarne indeks
Sekundaarne
Teisene indeks
Unikaalne indeks
Liitindeks
Mitmekomponendiline indeks
B-puu
Tasakaalustatud puu
Kahendpuu
Bitmap indeks
Bitmap-joini indeks
Klasterdatud indeks
Klastri võti
Päringu täitmisplaan
Hõe indeks
Tihe indeks
Klassifikaatori tüüpi tabel
Inglise keeles
Transaction analysis
Ordered (sequential) file
Unordered (heap) file
Indexed sequential file
Physical record
Block
Page
Tablespace
Index
Primary index
Secondary index
Unique index
Concatenated index
Compound index
Composite index
Multicolumn index
B-tree
Balanced tree
Binary tree
Bitmap index
Bitmap join index
Clustered index
Cluster key
Query execution plan
Sparse index
Dense indeks
Reference table
4. Kasutatud materjalid
1. Andros, G., 2002. An Analysis and Methodology of Pl/SQL Program
Tuning. Master’s Thesis. Tallinn Technical Univesity, Institute of
Informatics. 93 p.
2. Connolly, T.M. & Begg, C.E., 2001. Database systems. A Practical
Approach to Design, Implementation and Management. Third Edition.
Pearson Education. 1236 p.
3. Garcia-Molina, H. & Ullman, J. D., 2000. Database System
Implementation. Prentice-Hall. 653 p.
4. Gulutzan, P. & Pelzer, T., 2003. SQL Performance Tuning. Addison-
Wesley. 495 p.
5. Harrison, G., 2000. Oracle SQL High-Performance Tuning. Second
Edition. Prentice Hall. 630 p.
6. Index Organized Tables (IOT). Oracle-Base. [WWW]
http://www.oracle-base.com/articles/8i/IndexOrganizedTables.php
(11.05.2004)
7. Kulkarni, K., 2003. Overview of SQL:2003. 2003-11-06. [WWW]
46

TTÜ: Andmebaasi füüsiline disain (2012)
© Erki Eessaar
http://www.wiscorp.com/sql/SQL2003Features.pdf (24.12.2004)
8. Kyte, T., 2001. Expert one-on-one Oracle. Wrox Press Ltd. 1297 p.
9. Lighstone, S., Teorey, T. & Nadeau, T., 2007. Physical database design.
The databse professional's guide to exploiting indexes, views, storage,
and more. Morgan Kaufmann Publishers. 427 p.
10.Oracle 8i Data Warehousing Guide Release (8.1.6)
11.Oracle9i Data Warehousing Guide Release 2 (9.2) Part Number A96520-
01. 6. Indexes.
12.Pöial, J. Kahendpuu, kuhi, AVL-puu, B-puu, jt. [WWW]
http://www.itcollege.ee/~jpoial/algoritmid/puustruktuurid.html (15.05.2005)
13.Rational Unified Process 2002 05.01.01
47