Kordamisküsimused (Andmebaasid)

• NB! FK läheb "mitu" poolele kirja.

Mida kujutab endast klient / teenindaja arhitektuur?

Kui töötlusprotseduur tahab andmebaasiga vahetada informatsiooni, siis valmistatakse töötlusprotseduuris ette korraldus (tavaliselt SQL-keelne) ja need andmed, mis tuleb koos korraldusega serverisse saata. Korraldus saadetakse koos andmetega andmebaasi mootorisse ehk serverisse, mis töötleb korralduse ja salvestab andmed andmebaasi või teeb nende andmete alusel päringu andmebaasi.

Sama skeemi alusel saadetakse andmebaasi ka administreerimiskäsud (kasutajate lisamine, kasutajate õiguste muutmine, tabelite lisamine, seoste kirjeldamine jne)

NÄIDE:

Andmete lisamiseks andmebaasi saadetakse serverisse INSERT käsklus koos lisatavate andmetega. Andmebaasi mootor kontrollib lause ja vea korral tagastab veakoodi. Kui kontroll on edukas, siis üritab AB mootor lisada saadetud andmed andmebaasi sellesse tabelisse, mis oli INSERT käskluses. Kui see ei õnnestu, siis tagastatakse veakood. Kui õnnestus, siis tagastatakse veakood 0.

Ajalooline arhitektuur:

Teegis olid funktsioonid, mille kättesaamiseks pidid programmi kirjutama. Selle teegi pidid panema töötlusprotseduuri külge.

Kuidas jaotatakse andmebaasid struktuuri järgi? Näited, nimetused.

Struktuuri järgi klassifitseerimisel eristatakse andmebaase seoste lubatud struktuuri järgi.

Võrkstruktuuriga andmebaas- see, mida meie joonistame (tänapäeval enamik selle struktuuriga). Olemite vahel on lubatud teha ükskõik kui palju suhteid (kui palju ülesande poolt vajalikuks osutub). Piiranguks on andmebaasi mootori poolt seatud füüsilised piirid. Olemite vahel ei ole soovitatav teha üks-mitmele seoseid edasi-tagasi (soovitus teha need ainult ühes suunas), sest neid ei saa realiseerida.

Puu-kujuline andmebaas- igal olemil saab olla ülemusi ainult üks. Temast võib alamaid minna ükskõik kui palju

Kuidas jaotatakse andmebaasisüsteemid seoste moodustamise viisi järgi? (3.6)

Navigatsioonilised andmebaasid- iga tabeli kirje koosneb kahest osast: päisest ja andmeblokist. Päises on info kirje pikkuse, staatuse ja selle kirjega seotud teiste kirjete kohta. Andmeblokis on need andmed, mille salvestamiseks on andmebaas loodud. Päis on tehniline instrument, mida kasutajale kunagi ei näidata.

Kirje päises on iga seose jaoks üks aadressiväli, millesse kirjutatakse ülemuse-kirje aadress (viide ülemusele) või seotud kirjete ahela esimese või viimase kirje aadress seose tabelis.

Siin on ülemuse päises kirjas 1.alluva ja viimase alluva aadress. Alluvatel on lisaks neile kirjas ka ülemuse aadress ja edasi-tagasi viidad (viit eelmisele ja järgmisele kirjele ehk järgmise ahela aadress ja eelmise ahela aadress). Tänu sellele saab läbida kirjete ahelat nii edas- kui ka tagurpidi.

Relatsioonilised andmebaasid- valdav osa täna kasutatavaid andmebaasisüsteeme on relatsioonilised. Kahe tabeli sidumiseks peab neil olema sama semantikaga veerg. Kui kahes tabelis asuvatel kirjetel on sama väärtus, ongi kaks tabelit omavahel seotud. Üks-mitmele seosega tabelis "üks" poolel peab tabelis olev veerg olema unikaalse väärtusega, aga mitmeses otsas võib seeda väärtust esineda mitu korda. (nt auto ja omanik on üks-mitmele seos, kus kere number on unikaalne väärtus auto pool)

Mis on kontseptuaalne ERD ja mis andmeloogiline?

Kontseptuaalne ERD on ERD ilma tema sisemist struktuuri täpsustamata nimetatakse ka infoloogiliseks mudeliks. Tavaliselt alguses vaadtaksegi mudelit kontseptuaalsel tasemel (nagu ka meie tegime enda esimesi töid).

Andmeloogiline ERD- koostatakse pärast kontseptuaalset modelleerimist ehk projeteeritakse olemite sisemine struktuur, mis koosneb olemi omadustest (lisatakse atribuudid)

Mis on füüsiline modelleerimine?

Selle käigus saab andmemudelist andmebaasi skeem ehk skemaatiline kirjeldus, mille alusel saab luua andmebaasi. Selle käigus lisatakse andmeloogilisele andmemudelile järgmised kirjeldused:

• olemitele tabelite nimed

• olemitele seoste võtmete kirjeldused (primaar- ja välisvõtmed)

• olemitele indeksite kirjeldused

• olemite atribuutidele veergude nimed, mille järgi luuakse andmebaasi tabelite veerud

• olemite atribuutidele andmetüübid, pikkused ja NULL, NOT NULL piirangud

Mis on relatsioon ja relatsiooni järk?

Relatsioon- tabel/olem. Vektor, mis koosneb atribuutidest. Kogum ehk omavahel kokku seotud atribuutide kogum (NB! atribuudid peavad olema järjestatud). Kui paneme domeenid ritta ja anname neile semantilised nimetused, siis saame relatsiooni

R- relatsioon

A1, A2,...-järjestatud atribuudid. Igal atribuudil on relatsioonis kindel koht ja seda ei tohi muuta

dom(A1)- domeen, mis määrab atribuudi A

Relatsiooni järk- atribuutide arv relatsioonis

NÄIDE:

NB! Relatsioon viitab nii relatsiooni ilmingule kui ka skeemile.

Mis on relatsiooni ilming (pikem seletus), relatsiooni skeem ja relatsiooni jooksev staatus (6.3)?

Relatsiooni ilming- relatsiooni kirjelduse (ehk relatsiooni skeemi) alusel loodud kogum andmeid.

Relatsiooni ilmingut relatsiooni skeemil R tähistatakse r(R) ja see on kogum vektoreid:

Iga vektor on järjestatud kogum N-väärtuseid:

kus iga väärtus

on domeeni dom(Ai) element või on tegemist tühja väärtusega. Vektoris olevad väärtused on alati järjestatud samamoodi nagu on relatsiooni skeemis järjestatud atribuudid. Atribuut määrab temaga samas positsioonis oleva väärtuse semantika ja füüsilised parameetrid (domeeni).

Relatsiooni skeem- relatsiooni kirjeldus

Relatsiooni jooksev staatus- relatsiooni (tabeli/olemi) ilming mingil konkreetsel ajahetkel. See muutub siis, kui mõni relatsiooni vektor (ehk domeeni element) muutub, lisandub või kaob.

Relatsioon = relatsiooni skeem + relatsiooni ilming

Räägi erinevatest normaalkujudest NÄITED, domeen-võtme vs boyce-codd, neljas, viies

• Normaliseerimata kuju- andmemudeli vähemalt ühes olemis on korduvgrupid (nt on 1.kauba kood ja 2.kauba kood- tegelikult peaks olema kauba jaoks eraldi olem, mitte iga kauba jaoks eraldi atribuut). Seal on enam-vähem kõik anomaaliad olemas

• Esimene normaalkuju- kaotatakse korduvgrupid ära. Leidub olemeid, kus on transitiivne seos või jaotatud võti, aga korduvgruppe ei ole. Siin peab olema vähemalt kaks olemit (milles kummagi otsas ei tohi olla mulli ehk nulli võimalust, üks on alati).
• Liit-võti- Uue olemi primaarvõti saadakse seotud olemi (suhte "üks" poolel oleva olemi) primaarvõtme ja uues olemis kirjeldatava objekti võtme liitmise teel. Oluline on, et mõlemas tabelis oleks unikaalne primaarvõti. Objektide andmed tekivad ainult paariedna (arve ja klient, kaup ja müük)
• Transitiivne seos- kui a → b ja b → c, siis a → c (→ tähendab järeldub). Arvest järeldub klient. Primaarvõtmega on tugevalt seotud ainult arve, klient tegelikult ei ole. Olemis arve on ühest väljast koosnev primaarvõti, samas on aga andmeväljadega kirjeldatud kaks objekti (arve ja klient), millest ainult üks (arve) on tugevalt seotud primaarvõtmega. Teise objekti andmed pole aga võtmega üldse seotud.
• Jaotatud võti- osa andmetest on seotud võtmega kauba kood (kauba nimi, kauba hind, kauba ühik EHK kauba andmed), osa arve nr (kõik ülejäänud EHK müügi andmed). Tekivad tavaliselt esimesele normaalkujule ümberstruktureerimise tulemusena.



Anomaaliad: kadus ära vaid mälu raiskamise anomaalia

• Teine normaalkuju- kaotatakse jaotatud võti ära, aga transitiivne seos jääb alles. Tehakse uus olem KAUP ja tõstetakse kauba nimi, kauba hind ja kauba ühik sinna. Nüüd on uuel olemil eelmisesse olemisse suundumisel ka mull ehk on lubatud ka seos null (tähendab, et kõrvale tõstetud objekt võib eksisteerida ka iseseisvalt ehk antud näites KAUP)



Anomaaliad: alles on transitiivse seosega seotud anomaaliad ehk andmete lisamise, kustutamise, kirje uuendamise, info liiasuse ja andmete adekvaatsuse anomaalia

• Kolmas normaalkuju- kaotatakse transitiivne seos ära. Tavaliselt üle selle ei disainita. Sellel ei ole transaktsioonilisi anomaaliaid. Arve juurest viiakse kliendi andmed eraldi olemisse. Ka siin on uuest olemist KLIENT suundumisel eelmisesse olemisse mullike ehk null lubatud EHK olem KLIENT saab eksisteerida ka iseseisvalt



Anomaaliad: kõik seni kirjeldatud anomaaliad on kadunud. Küll aga esineb primaarvõtme uuendamise anomaalia (esines ka esimesel ja teisel normaalkujul). Kui uuendada mõnda primaarvõtit sellises olemis, kus ei ole päritud primaarvõti (üleval näites on päritud primaarvõti olemis MÜÜDAV_KAUP), siis iga primaarvõtme uuendamine tingib hulgaliselt uuendusi kõikides nendes kirjetes, kus antud primaarvõtme väärtust on kasutatud seostava paari tekitamiseks välisvõtmega. See tekitab andmebaasi serveri protsessori ressursi raiskamise ja andmete adekvaatsuse oht

• Domeen-võtme normaalkuju- tihti viiakse andmemudelid sellele kujule. Saame lahti primaarvõtme uuendamise anomaaliast. Asendame kõik primaarvõtmed tehniliste primaarvõtmetega (olemis MÜÜDAV KAUP ka nüüd üks primaarvõti)

Enam ei oma primaarvõtmete uuendamine mõtet, sest ID on tehniline andmeelement, mille ainuke tähendus on olla sama olemi piires unikaalne. Oluline on, et kui kirje kustutatakse, siis tema IDd ei anta uutele kirjetele, muidu tekib seose väära taastumise anomaalia (kui kustutada “üks” poolse otsa kirje, aga seose “mitu” poolel ei kustuta neid,siis uue sama IDga kirje lisamisel tekib viga).

• Boyce-Codd normaalkuju- transitiivne seos kaotatud, jaotatud võtmed alles (vastupidine II normaalkujule). Kui jaotatud võtmed ka ära kaotada, saame uuesti III normaalkjuju



Anomaaliad: peaagu samad nagu II normaalkuju puhul (siin põhjuseks jaotatud võti). Andmete lisamise, kustutamise, kirje uuendamise, info liiasuse ja andmete adekvaatsuse anomaalia

• Neljas normaalkuju- andmemudel on Boyce-Codd normaalkujul, millel on ainult ühes olemis jaotatud võti. See vähendab anomaaliate esinemist.

• Viies normaalkuju- andmemudel on IV normaalkujul ja selles puuduvad suhte projitseerumised (ühest olemist teisse saab liikuda mitut teed pidi)

Kirjelda erinevaid mudeleid (Joonised, lukustamine 1-kihiline).

Ühe-kihiline mudel- (sissejuhatav tekst- olid andmebaasid ja andmebaasikäsitlusprogramm, mis alguses asusid samas arvutis. Hiljem need lahutati- andmebaasid kolisid fail-serverisse ja töötlusprogrammid jäid tööjaamadesse- sellest midagi paremaks ei muutunud, lihtsalt füüsiline arhitektuur muutus, loogiline arhitektuur jäi samaks.)

Seal on üks tarkvaraline komponent (üks programm). Seega pole ka mingeid liideseid, mille kaudu teiste komponentidega informatsiooni vahetada. Igal andmebaasisüsteemil olid standardfunktsioonide teegid (andmete baasi kirjutamiseks, lugemiseks). Iga andmebaasi käsitlemise programm oli kogum kasutajaliidese ja arvutusprotseduuride jaoks spetsiaalselt kirjutatud programmi ja andmebaasisüsteemi funktsioonide teegi kogum

Andmebaas paiknes töötlus-programmiga ühes arvutis ja alguses sai seda kasutada üks kasutaja. Kui tekkis multi-tasking ja ajajaotus-süsteemid, siis said kasutada mitu kasutajat (ühes arvutis) AGA sellega tekkisid probleemid, sest keegi lisas midagi, keegi kustutas, keegi kirjutas üle jne. Probleemi lahendamiseks hakati andmeid lukustama, selleks kirjutati lukk kirje päisesse ja kui seda enam vaja polnud, siis kirjutati see tühja lukuga üle. Lukus oli kirjas protsess, mis selle lukku pani ja see sama protsess sai luku maha võtta. AGA seal oli üks probleem- kui protsess juhtus ära surema, siis ei saanudki neid lukke maha võtta ja see takistas teiste kasutajate tööd. Küll aga oli selle jaoks lahendus- olid spetsiaalsed programmid, mis käisid mingi konkreetse aja tagant ja otsisid neid surnud protsesse ja hävitati lukud.

Kahe-kihiline mudel- klient-serveri mudel. Kaheks kihiks on andmebaasi serveris asuv andmebaasi mootor ja kliendi arvutis olev rakendus, mis suhtlevad liidese kaudu (võivad, aga ei pea olema ühes arvutis). Andmebaasi käsitleva rakenduse ja andmebaasi vahel on programm (mida nimetatakse andmebaasi mootoriks), mis täidab rakenduse korraldusi ja vahendab rakendusele andmeid. Andmebaasi poole pöörduvaid rakendusi võib olla kuitahes palju (piiri seab serveri riistvara konfiguratsioon- protsessori kiirus, mälu maht, ketaste maht, ketaste kiirus jne). Andmebaasi mootor haldab tavaliselt korraga mitut andmebaasi.

Iga andmeside protsess algatatakse kliendi arvutis. Kui seal töötaval rakendusel on vaja mingit toimingut andmebaasi teha (kirjutada, lugeda), siis ta saadab korralduse andmebaasi mootorile, mis omakorda täidab korralduse ja salvestab andmed andmebaasi või teeb nende andmete alusel päringu andmebaasi.

Enam pole vaja lukke andmebaasi salvestada, sest andmebaasi mootor haldab kõiki lukke oma sisemiste meetoditega. Andmebaas jälgib, millises seisus on temaga ühendust võtnud rakendused ja vajaduse korral (kui rakendus ei tööta)hävitab kõik seotud lukud.

Andmebaasimootor koosneb kahest osast: see, mis teeb seda, mida paluti (TÄITUR) ja see osa, mis seostab tegevust sellega, kes seda palus ehk LIIDES. Klient ja server peavad tundma liidest samamoodi, et selle andmebaasi poole saaks pöörduda. Liidese ülesanne on vahendada liiklust. Oluline on, et andmebaasi mootoriga suhtlev rakendus tunneb ka seda liidest, mille kaudu andmebaasi mootorile korraldusi saata ja andmeid vastu võtta. Igal andmebaasisüsteemil on enda spetsiifiline liides (native link) ja andmebaasi poole pöördumiseks peab rakenduse koosseisus olema just see draiver, mille andmebaasi poole pöörduda soovitakse.

Kolme-kihiline mudel- kasutajaliides on viidud rakendusest eemale (rakendusest välja). Rakendus ise töötab andmebaasi mootoriga samamoodi nagu kahe-kihilises mudelis. Meil on kolm komponenti: andmebaasi mootor (tegeleb vahetu andmebaasi käsitlemisega), rakendus (juhib protsessi) ja kasutajaliides (selle kaudu suhtleb kasutaja rakendusega).

Rakendus pannakse tavaliselt tööle selleks loodud eraldi keskkonnas- aplikatsiooni serveris. Kasutaja peab pöörduma mingil URLil, kus registreerumisel käivitatakse aplikatsiooni serveris (rakenduses) tema jaoks protsess, mille kasutajaliides saadetakse tema sirvijasse. Kui kasutaja teeb läbi kasutajaliidese rakendusega tegevusi, siis rakendus vahetab kõik vajalikud andmed ja korraldused andmebaasi mootoriga.

Andmebaasi serveri ja rakenduse vahel toimub korralduste ja andmete liigutamine läbi mõne native linki. Rakenduse ja kasutajaliidese vaheliseks liideseks on kas HTTP, HTTPS, XML, SOAP või mõni muu standardiseeritud liides.

N-kihiline mudel- kihte võib olla rohkem kui 3, mis lisanduvad alati aplikatsiooni serveri ja kliendi vahele (muidu lõhuksime klient-serveri mudel ära). Nt on vahel veel koormuse jagur (vaatab, et aplikatsiooni serverid oleksid ühtlaselt koormatud, et tagada klientide parim teenindamine) või logistika server (teostab süsteemi sisemist logistikat ja aitab valida selle aplikatsiooni serveri, millel on see rakendus, mida klient vajab ehk ta on vahendaja, mis leiab kliendile õige rakenduse).

Komponent mudel (0-kihiline)- ei ole kihte. Kõik serverid paiknevad samal tasemel ja suhtlevad üksteisega läbi logistika serveri. Klient asub ka serveritega samal tasemel:

Tegelikult kõik serverid ühel tasemel, joonisel logistika server üleval lihtsalt ülevaatlikuse pärast. Selline arhitektuur sobib hästi väga keeruka ja dünaamilist laiendamist nõudva insosüsteemi loomiseks.

Nimeta erinevaid lukke (lukustusmeetodeid), mida saab andmebaasi panna

Lukustusmeetodid määravad luku tugevuse- kas kirjete kasutamise õigus on ainult ühel lukustajal või on ka teistel õigus andmeid lugeda.

ROLLBACK ja COMMIT eemaldavad iga luku.

• S-locks (shared locks)- seda saavad mitmed kasutajad korraga peale panna. Selle lukuga saavad kõik kirjeid lugeda, aga muuta ega kustutada ei saa keegi. Lukust vabastasid nii COMMIT kui ka ROLLBACK käsud

• X-locks (exclusive locks)- selle saab korraga peale panna üks kasutaja (see lukk saab eksisteerida vaid üksi). Sellisel juhul näeb lukustatud kirjeid/tabelit/lehekülge ainult lukustaja. Selle lukuga võib teoastada nii lisamise, kustutamise kui ka uuendamise käsklusi. Kui kirjet on muudetud või kustutatud, siis luku saab eemaldada ainult siis, kui võtta muudatused tagasi (ROLLBACK) või kinnitades muudatused (COMMIT). Kui tabelisse lisada uus kirje, siis jääb sellele kirjele, kuni ROLLBACK- või COMMIT-korralduse tegemiseni, X-lock tüüpi lukk.

• U-locks (update locks)- neid paigaldatakse siis, kui andmed loetakse baasist kindla sooviga neid uuendada või kustutada. U-lock võib koos eksisteerida s-lockiga. Selleks, et u-lockiga hakata muutma, tuleb ta teha x-lockiks, aga selleks peavad olema kõik s-lockid vabastatud ja siis u-lockid vabastatakse automaatselt ehk visatakse minema.

Lukkude vahelised seosed:

*)“S-lock” ja “U-lock” tüüpi lukud võivad koos eksisteerida. Kui andmete muutmiseks on vaja “U-lock” tüüpi lukk muuta “X-lock” tüüpi lukuks, siis kõik “S-lock” tüüpi lukud peavad eelnevalt olema vabastatud.

**)Kunagi ei õnnestu X-locki panna olemasoleva U-locki kõrvale. Õnnestub vaid paralleelselt eksisteeriva U-locki muutmine X-lock’ks. Sellisel juhul kõikide teiste protsesside U-lock’d vabastatakse.

Kui luku lisamine ei õnnestu oodatakse. Kas igavesti või mingi ajani. Võib tekkida TIME-OUT viga.

Too indeksitest näiteid PROBLEEMID

• Primaarindeks- fikseeritud pikkusega kirjete loend, millest igal on kaks veergu → esimeses võtme väärtus ja teises andmebaasi lehekülje aadress (fikseeritud suurusega blokk, kuhu iga tabeli puhul on salvestatud konkreetse tabeli kirje pikkusest sõltuv arv kirjeid), kus paikneb antud võtme väärtusele vastav kirje. Kui lehekülg on teada, siis loetakse korraga sisse ja otsitakse õige kirje üles järjestikotsinguga. Indeks vastab tabeli primaarvõtmele (indeksi võtme väärtus = tabeli primaarvõti). On hõre, järjestatud ja ühe-tasemeline. EHK kõigi andmetabeli kirjete võtmeväärtusi ei ole indeksis, indeksi kirjed on sorteeritud võtmeväärtuse kasvamise või kahanemise järjestuses ja indeksi kõik kirjed paiknevad samal tasemel st. ühtses jadas.



Otsimine → leitakse järjestikuste indeks-kirjete paar, mille vahele otsitava kirje võtme väärtus jääb. Võtme väärtust otsitakse kahendotsinguga.
Probleemid → indeksisse uute ridade lisamine ja sealt ridade kustutamine. Probleem tekib siis, kui lisatav kirje satub andmetabelis uue bloki esimeseks kirjeks, siis tuleb lisada kirje ka indeksisse vajalikule positsioonile kirjete järjestuses (vastavalt võtme väärtusele). See võib tingida vajaduse taha poole jäävaid kirjeid edasi nihutada, et teha uuele indeksi kirjele kohta. Kirje kustutamisel võib tekkida vajadus kas indeksi uuendamiseks (kui kustutatakse bloki esimene kirje – ankur-kirje) või indeksi rea kustutamiseks (kui kustutati viimane kirje plokist). Esimesel juhul tuleb uuendada ainult võtme väärtus. Teisel juhul peame me indeksist kustutama kirje ja “tõmbama kokku) taha poole jäävaid indeksi kirjeid.

• Kobarindeks- primaarindeksi väärtus ei ole andmetabelis unikaalne. Kobarindeksi kirjel on kaks veergu- võtme väärtuste veerg ja lehekülje alguse viida veerg. Kobarindeks on tihe, järjestatud ja ühe-tasemeline. EHK kõigi andmetabeli kirjete võtmeväärtused on indeksis olemas, indeksi kirjed on sorteeritud võtmeväärtuse kasvamise või kahanemise järjekorras ja indeksi kõik kirjed paiknevad samal tasemel st. ühtses jadas. Kobarindeksis leidub rida andmetabeli iga erineva kobarväärtuse kohta (indeksi kirje esimeses veerus) ja teine veerg viitab leheküljele, kus on esimene vastava võtmeväärtusega kirje:



Otsimine → otsitakse indeksist etteantud võtmeväärtuse järgi üles indeksi rida ja võetakse sealt lehekülje aadress. Siis pöördutakse aadressi järgi andmetabeli lehekülje poole ja loetakse sealt kirjeid järjest seni, kuni leitakse vastava võtmeväärtusega indekseeritud välja väärtus. Siis loetakse kirjeid seni, kuni indekseeritud välja väärtus ehk kobar-väärtus jääb samas etteantud otsingu võtmeväärtusega või kuni tabeli lõppemiseni EHK nt tahetakse leida kirjed, mille ameti ID on 2, siis võetakse indeksist selle lehekülg, milleks on antud näites 1 ja loetakse kirjeid seni, kuni saadakse kätte kõik ametid, mille ID on 2 ehk loetakse ka lehekülge nr 2. Nagu primaarindeksis, toimub siin ka otsimine kahendotsinguga.
Probleem → Ei ole efektiivne, sest uue rea lisamisel peab blokkidena hakkama andmeid liigutama. Võimalus on panna ühte plokki ühe võtmeväärtusega kirjed ja kui nad ära ei mahu, siis jätkuvad järgmises plokis. Siis tuleb lisada ka viit järgmisele lehele, mis muudab efektiivsemaks. Probleem tekib indeksi kirjete lisamisel. Kuna indeks on tihe st. kõik võtme väärtused on indeksis ja ka järjestatud, siis tuleb iga uue võtme väärtuse tekkimisel andmetabelisse teha indeksisse "auk", selleks et uus indeksi võtme väärtus panna järjestuses õigesse kohta.

• Sekundaarindeks- Kirjetes on kaks veergu (võtme väärtuste veerg ja lehekülje viida veerg) ja indeksi kirjed on järjestatud võtmeväärtuse järgi. Veergude väärtused on unikaalsed, aga kirjed ei ole sorteeritud selle väärtuse järgi. Tihe indeks, järjestatud ja ühe-tasemeline EHK kõigi andmetabeli kirjete võtmeväärtused on indeksis olemas, indeksi kirjed on sorteeritud võtmeväärtuse kasvamise või kahanemise järjekorras ja indeksi kõik kirjed paiknevad samal tasemel st. ühtses jadas.

Kuna veerg, mille järgi indeks on koostatud ei ole andmetabeli kirjete sorteerimise aluseks, siis ei nimetata seda võtmeks vaid lihtsalt indekseerimisväärtuseks ja tabeli veergu, milles indekseerimisväärtuseks on, indekseeritud veeruks.

Sekundaarindeksit kasutatakse paralleelselt primaarindeksiga siis, kui tabelis on kaks veergude komplekti, mille väärtused on unikaalsed. Neist ühest tehakse primaarindeks ja selle järgi sorteeritakse tabeli kirjed. Teisest unikaalsest veergude komplektist tehakse sekundaarindeks.

• Mitmetasemeline indeks- idee on vähendada indeksist otsimise sammude arvu (vähendada indeksi otsingu iga sammu järel läbi vaadatavate indeksi-kirjete hulka rohkem kui kaks korda) ehk kogu otsing koondub kiiremini.
Kahe-tasemeline indeks, mis on ehitatud primaarse indeksi põhimõttel:

Siin jagatakse ka indeks plokkideks(lehekülgedeks) ja ehitatakse sinna peale teine indeksi tase, mis on primaarne indeks esimese taseme indeksile. Leitud aadressi järgi on vaja lugeda puhvrisse sisse esimese taseme indeksi blokk ning lugeda sealt selle lehekülje aadress andmetabelis, kus asub kirje ja seejärel lugeda leitud aadressi järgi sisse andmetabeli lehekülg.

Siin näites on tegemist hõreda ja järjestatud mitme-tasemelise primaarindeksiga.

• Paiskindeks (hash index)- indeksi lugemiste arv on 1 kuni kolm/neli. Indeksil on alati kolm veergu: võtme väärtus, viit andmetabeli leheküljele ja viit kollisiooni ahela järgmisele kirjele. Indeksi väärtused (nende asukoht) indeksis arvutatakse valemi abil (asukoht tundub juhuslik, aga tegelikult ei ole). Indeks tehakse tema loomisel valmis tema maksimaalse võimaliku ridade arvuga (täidetakse tühjade ridadega). Kui indeksi ridade arvu on vaja muuta (tavaliselt suurendada) tuleb indeks luua uuesti, sedakorda siis juba suurema või väiksema ridade arvuga. Paisk-indeksi ridade arv peaks olema umbes 20% suurem, kui on seda maksimaalselt andmetabelisse lisatavate kirjete arv.
Võtme indeksist leidmiseks kuluv lugemiste arv ei sõltu indeksi ridade arvust vaid sellest, kui õigesti on arvutatud paisk-indeksi ridade arv; suurem ridade arv annab tavaliselt paremaid tulemusi.
OLULINE: paisk-indeksil on kolm veergu, paisk-indeksil on alati fikseeritud arv ridu ja paisk-indeksi ridade arv peaks olema ca 20% suurem, kui on maksimaalselt võimalik lisada kirjeid andmetabelisse, mille jaoks on see paisk-indeks loodud.
Iga paisk-indeksi tabeliga on seotud funktsioon x=f(y), kus y on võtme väärtus ja x on selle võtme väärtuse all kalkuleeritud rea number, kuhu võtme väärtus y koos lehekülje aadressiga kirjutatakse. Funktsiooni f nimetatakse paisk-funktsiooniks. Ja tegevust, kus paisk-funktsiooni järgi võtme väärtuse alusel arvutatakse indeksi kirje rea aadress, kuhu see võtme väärtus koos lehekülje viidaga kirjutatakse, nimetatakse paiskamiseks. Andku meie võtme väärtus "Kai Mai' funktsioonil f tulemuse 3. See tähendab seda, et võtme väärtus "Kai Mai' tuleb paigutada paisk-indeksi kolmandasse ritta:



Kui me nüüd tahame teada, kas mingi võtme väärtusega kirje on andmetabelis olemas peame me võtma sama funktsiooni, millega me "paiskasime" võtme väärtuse indeksisse, arvutama otsitavale reale indeksi rea numbri ja vaatama, kas indeksi selle rea peal on sellise väärtusega võtme väärtus.
Kui tahetakse kirjutada võtme väärtust sinna, kus juba on olemas mingi võtme väärtus, siis valitakse teisele võtmeväärtusele mingi teine vaba rida indeksi tabelis (siis viidatakse algse rea juures sinna reale, kuhu teine võtmeväärtus pandi).



Sellist ahelat, mis tekib indeksi nendest kirjetest, mida funktsioon määrab sama indeksi rea peale, nimetatakse kollisiooni ahelaks.
Kui paisk-indeksi kõik read on täidetud, siis ei saa andmetabelisse enam ühtegi kirjet lisada, kuna indeksisse ei õnnestu lisada enam ühtegi uut väärtust. Sellist situatsiooni ei tohi andmebaasis lasta tekkida. Juba siis kui selline "oht paistab kauguses" tuleb paisk-indeks hävitada ja luua see uuesti ja siis juba suurema ridade arvuga.
Probleem: Paisk-indeksi suurimaks miinuseks on see, et ta tuleb kohe alguses täies mahus valmis ehitada ja seepärast reserveerib see kohe (olenemata andmetabeli suurusest) täies mahus ketta ruumi. Seepärast kasutatakse neid harva. Teisest küljest vaadatuna ei ole üldse väga palju kohti kus neid kasutada tasuks.
Paisk-indeksid on tihedad (paisk-indeksis on andmetabeli kõigi unikaalsete võtmete väärtused), järjestamata (paisktabelis paiknevad võtmeväärtused “kaootiliselt segamini” ja mitme tasemelised (kujuneb dünaamiliselt läbi kollisiooni ahelate)

Märkmed

• CASE-süsteemi abil võrreldakse uut mudelit olemasoleva andmebaasi struktuurida ja genereeritakse SQL-keelsed andmebaasi andmestruktuuri muutmise laused

• Sama tabeli mitmest koopiast saab teha päringu, kui kirjutada FROM süntaksisse tabel mitu korda:

• Relatsioon- tabel

• Atribuut- veerg

• Domeen- veeru tüüp

• Relatsiooni skeem- tabeli kirjeldus

• Peatükkides 5.3-5.8 on toodud posti toomise ERD mudeli näide.

• Oracles NULL ei võrdu NULLiga

• INSERT lausega mitme rea lisamisel saada need ühe käsuga- koormab serverit vähem

• DELETE, UPDATE korralduse optimerimiseks kasutada indeksit

• SELECT. Sõltub WHERE tingimusest. Kasuta domeen-võtme normaalkuju. tabelite arv muudab päringu aeglasemaks, kasuta alam-SELECT lauseid. Indekseid ei tohi liiga palju oll. SELECT lause võib mitmeks tükiks jagada. FROM grupp lühemaks, kasuta (IN, NOT IN, EXISTS alampäringuid). WHERE enne JOINI. OUTER-join on aeglane, kasuta UNION-konstruktsiooni. Indekseeri kõik seosed.

• Andmete korral on piiratu ressursiks aeg, mille jooksul on vaja mingeid konkreetseid andmeid muuta või kasutada.

• Lukustamine- Andmebaasis ei ole nii, et ma avan faili ja siis ta läheb teistele lukku, vaid seal toimus alguses lukustamine kirje haaval. Nt ma tahan hakata tegema tehingut pangakontoga, aga kuna ma ei taha, et keegi teine samal ajal tehingut teeks, siis ma panen selle kirje teistele lukku

• Ajalooliselt haldas lukke andmebaasi juhtimissüsteem, klient-serveris haldab lukke server