Andmebaasid I - eksamiküsimused (3)

Eksamil küsitavad mõisted
1. Andmebaas (teema 1)
2. Andmebaasisüsteem (teema 1, 10)
3. Relatsiooniline muutuja (relvar), relatsioon (teema 2)
4. Kandidaatvõti, supervõti ( primary key) (teema 2)
5. Primaar- ja alternatiivvõti (teema 2)
6. Välisvõti (teema 2)
7. Viidete terviklikkuse reegel (teema 2)
8. Andmetüüp (teema 2 ja 5)
9. Kitsendused ja nende võimalik realiseerimine SQL-andmebaasides (teema 2 ja 5)
10. Nimetage relatsioonialgebra operatsioone (teema 3)
11. Virtuaalne relatsioon e. vaade (teema 5)
12. Pädevusala (teema 7)
13. Funktsionaalne allsüsteem (teema 7)
14. Register (teema 7)
15. Kuidas on omavahel seotud pädevusalad, funktsionaalsed allsüsteemid ja registrid ? (teema 7)
16. Kontseptuaalne andmebaasi disain . Eesmärk, sisendid , tulemused.(teema 7)
17. Kontseptuaalne andmemudel (teema 7)
18. Mida näitavad andmebaasi operatsioonide lepingud ja milleks neid kasutada? (teema 7)
19. Nimetage teisendusreegleid, mille põhjal saab kontseptuaalsest andmemudelist tuletada esialgse loogilise disaini andmemudeli. (teema 10)
20. Loogiline andmebaasi disain. Eesmärk, sisendid, tulemused. (teema 10)
21. Normaliseerimine (teema 9)
22. Esimene normaalkuju (teema 9)
23. Kolmas normaalkuju ja Boyce/Coddi normaalkuju (teema 9)
24. Ortogonaalse disaini printsiip (teema 9)
25. Füüsiline andmebaasi disain. Eesmärk, sisendid, tulemused. (teema 12)
26. Indeks (teema 12)
27. Andmebaasiserveris talletatud rutiinid (teema 13)
28. Triger (teema 13)
29. Kuidas saada surrogaatvõtme veergu unikaalseid väärtuseid? (teema 13)
30. Denormaliseerimine (teema 14)

1. Andmebaas (teema 1)

• Andmebaas on korrastatud andmete kogum.
  
• Andmebaasis on andmed organiseeritud (korrastatud) mingi struktuuri (kirjeldab nende andmete omadusi ja neile andmetele vastavate olemite vahelisi seoseid ) järgi.
  
• Andmebaas on osa infosüsteemist.
  

• Andmebaas on loodud kasutajate infovajaduste rahuldamiseks.
  
• Andmebaasi kasutavad rakendused ning nende kaudu lõppkasutajad.
  
• Andmebaas esitab mingi objektsüsteemi (reaalse süsteemi, probleemvaldkonna, subjekti) seisundit .
  
• Andmebaas sisaldab peale andmete endi ka nende andmete kirjeldust (metaandmeid).
  
• Andmebaasis ei tohi olla omavahel vastuolus olevaid fakte.
  
• Andmebaasis võib olla kontrollitud andmete liiasus.
  
  • Andmebaasis on andmete liiasus siis ja ainult siis, kui sama väite saab tuletada sellest kahel või rohkemal erineval viisil.
    
  • Hästi disainitud andmebaasis on andmete liiasust võimalikult vähe ja kogu olemasolev andmete liiasus on kontrollitud. Kontrollitud andmete liiasus tähendab, et andmebaasi kasutaja on liiasusest teadlik ja andmebaasisüsteem tagab muudatuste ülekandmise kaudu, et selle liiasuse tõttu ei satu andmebaasi kunagi vastuolulisi andmeid.
    
• Andmebaas on loometöö tulemus ning selle loomine ja haldamine nõuab psüühilist pingutust.
  
• Andmebaasi kogutud andmed on selle omaniku jaoks oluline vara, mille turvalisuse eest ta peab hoolitsema.
  
• Andmebaasi peetakse kaasajal enamasti infotehnoloogiliste vahenditega, kasutades spetsiaalset tarkvara – andmebaasisüsteem.
  
• Andmebaaside liigitus
  
  • Lühimälu: operatiivandmete andmebaasid .
    
    • Suhtelisel lühiajalise perspektiiviga otsuste langetamiseks
      
    • Detailsed ja enamasti aktuaalsed andmed
      
    • Kasutavad onlain-tehingutöötluse süsteemid
      
    • Tüüpilised operatsioonid on üksikute faktide lugemine, lisamine, muutmine, kustutamine.
      
  • Pikaajaline mälu: andmeaidad ja andmevakad.
    
    • Andmete integreerimiseks, analüüsimiseks ning strateegiliste otsuste langetamiseks
      
    • Aktuaalsed ning ajaloolised andmed
      
    • Detailsed ja koondandmed
      
    • Kasutavad onlain-analüüsi süsteemid (nõustussüsteemid)
      
    • Tüüpilised operatsioonid on keerukad päringud, millele vastamiseks peab süsteem lugema suure hulga andmeid ning suure hulga andmete korraga andmebaasi lisamine.
      
  • Paiknemise järgi
    
    • Mittehajus andmebaas, mis on loodud kasutades ühte andmebaasisüsteemi ja mis paikneb ühes arvutivõrgu sõlmes.
      
    • Hajus andmebaas, mille alamosade loomiseks võib olla kasutatud erinevaid andmebaasisüsteeme ja mille alamosad võivad paikneda jagatult erinevates arvutivõrgu sõlmedes.
      

2. Andmebaasisüsteem (teema 1, 10)

• Andmebaasihaldur (andmebaasisüsteem) on riistvaral ja tarkvaral põhinev süsteem andmebaaside defineerimiseks, loomiseks, manipuleerimiseks, juhtimiseks , haldamiseks ja kasutamiseks.
  
• Andmebaasisüsteem on tarkvarasüsteem, mis võimaldab kasutajatel andmebaasi luua, kasutada, uuendada , hooldada ning sellele juurdepääsu kontrollida.
  
• Andmebaasisüsteemide liigitus
  
  • Andmete kasutajale esitamise viis (andmemudel).
    
    • Hierarhiline - andmed esitatakse hierarhiatena
      
      • XML
        
    • Võrkstruktuur - andmed esitatakse kogumitena, mis sisaldavad peremees - ja alluvkirjeid
      
    • Relatsiooniline - andmed esitatakse relatsiooniliste muutujate väärtustena
      
      • SQL:1992
        
    • Objektorienteeritud - andmed esitatakse klassidesse kuuluvate objektidena
      
    • Objekt-relatsiooniline - lisab SQL mudelile teatud objektorienteeritud programmeerimisest tulenevaid erisusi
      
      • SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
        
    • Mitmemõõtmeline - andmed esitatakse mitmemõõtmeliselt, hüperkuupidena
      
    • Trans-relatsiooniline - mudel, mille alusel võib näiteks organiseerida relatsioonilise andmebaasi andmete sisemisel tasemel salvestamise
      
  • Võimsus ja kasutajate arv.
    
    • Töölaua andmebaasisüsteem - on mõeldud samaaegseks kasutamiseks ühe kasutaja või äärmisel juhul väikese kasutajate grupi poolt (nt MS Access).
      
    • Üleminekusüsteem - jäävad omadustelt kuhugi töölaua ja serveri süsteemide vahele (nt Oracle XE). On mõeldud vaheetapina üleminekul töölaua andmebaasisüsteemilt serveri andmebaasisüsteemile.
      
    • Serveri andmebaasisüsteem - selles loodud andmebaasi kasutavad korraga paljud kasutajad (nt Oracle Enterprise Edition , MySQL ). Sellist andmebaasisüsteemi kasutatakse arhitektuuri korral kus klient ja server on erinevates arvutites
      
    • Manusandmebaasisüsteem - andmebaasisüsteem, mida kasutatakse mõne eraldiseisva rakenduse lahutamatu osana (nt SQLite). Andmebaasisüsteem tuleb juba rakendusega kaasa (on üks selle osa) ja on kasutaja eest varjatud.
      
  • Lähtekoodi avalikkus .
    
    • Avaliku lähtekoodiga – huvilised saavad lähtekoodi lugeda ja muuta
      
    • Salajase lähtekoodiga
      
  • Muutmälu kasutamine.
    
    • Töö ajal osa andmeid kõvakettal, osa muutmälus – tavaline praktika tänapäeva andmebaasisüsteemides
      
    • Töö ajal kõik andmed muutmälus – andmetele kiirem ligipääs
      

3. Relatsiooniline muutuja (relvar), relatsioon (teema 2)

• Relatsiooniline andmebaas on nime omav relatsiooniliste muutujate (relvaride) kogum.
  
• Relvarid on relatsioonilises andmebaasis järjestamata.
  
• Igal relvaril on relatsioonilise andmebaasi piires unikaalne nimi
  
  • st viitamine nime, mitte järjekorranumbri, alusel.
    
• Iga relvar (relatsiooniline muutuja) on mingit relatsiooni tüüpi.
  
• Igal ajahetkel on relvaril üks väärtus.
  
• Iga relatsiooni tüüpi väärtust nimetatakse relatsiooniks.
  
• Kuna relvar on relatsiooni tüüpi, siis iga selle väärtus on relatsioon.
  
• Relatsioon koosneb päisest ja kehandist, kusjuures relatsiooni päis vastab selle tüübi päisele.
  
  • Päis esitab üldistatud väite e. predikaadi reaalse maailma kohta.
    
  • Predikaat on tõeväärtusfunktsioon – kõigi parameetrite asendamisel väärtustega saadakse väide, mis on kas tõene või väär.
    
  • Kehand koosneb korteežidest.
    
  • Iga korteež esitab tõese väite reaalse maailma kohta.
    
  • See väide saadakse päise poolt esitatud predikaadis parameetrite asendamisel väärtustega.
    

Relatsiooniline mudeli terminid:
Relatsiooniline andmemudel kui abstraktne programmeerimiskeel näeb ette relatsiooniliste muutujate kasutamise.

4. Kandidaatvõti, supervõti (primary key) (teema 2)

• Relvari R supervõti on R atribuutide hulk K, mille korral mistahes R lubatud väärtuseks olev relatsioon ei sisalda kunagi kahte erinevat korteeži, kus on sama K-le vastav väärtus. (lisades kandidaatvõtme väärtuse päringu piiranguks , ei saa kunagi vastuseks mitut korteezhi)
  
• Supervõtmes võib leiduda atribuute, mida saab eemaldada ja võti säilitab unikaalsuse.
  

<<

• Relvari R kandidaatvõti (ka võtmekandidaat) on R supervõti, mille ükski pärisalamhulk ei ole R supervõti.
  

<

• Igas relvaris peab olema vähemalt üks kandidaatvõti!
  
• Iga korteež on üheselt leitav relvari nime ja kandidaatvõtme väärtuse järgi.
  

Kandidaatvõti (ka võtmekandidaat) (ingl. k. candidate key) on supervõti, mille alamhulk ei ole korrektne supervõti. See tähendab, et kandidaatvõtmest ei saa enam ühtegi atribuuti eemaldada, ilma et ta kaotaks unikaalsuse. Relatsioonil võib olla mitu kandidaatvõtit. Kandidaatvõtme omadused on:

• unikaalsus - iga kandidaatvõtme väärtus identifitseerib üheselt ühe relatsiooni kirje ehk korteeži. Kandidaatvõtme väärtusest võib mõelda kui korteeži aadressist, mille alusel on võimalik korteež relatsioonist leida.
  
• täielikkus - kandidaatvõtmest ei saa eemaldada atribuute, ilma et ta kaotaks unikaalsuse omaduse.
  

Supervõti (ingl. k. superkey) on atribuut või atribuutide kombinatsioon, mis identifitseerib unikaalselt relatsioonis olevaid kirjeid. Supervõti võib sisaldada atribuute, mida pole unikaalsuse tagamiseks vajalikud, st. et temast võib atribuute eemaldada ja ta tagab ikkagi unikaalsuse.

5. Primaar- ja alternatiivvõti (teema 2)

• Tavaline praktika on valida üks kandidaatvõti primaarvõtmeks (esmasvõtmeks).
  
  • Valik, milline võti on "võrdsematest võrdsem", on sageli kunstlik.
    
  • Igas relvaris saab olla maksimaalselt üks primaarvõti.
    
• Primaarvõtmeks mitte valitud kandidaatvõtmeid nimetatakse alternatiivvõtmeteks.
  

Primaarvõti (ka esmasvõti) (ingl. k. primary key) on kandidaatvõti, mis on valitud relatsiooni kirjeid unikaalselt identifitseerima. Primaarvõti on võti, mis üheselt identifitseerib ühe kirje. Valiku kriteeriumid:

• atribuudi domeen (peaks olema võimalikult lühike väärtus)
  
• atribuutide arv (peaks olema võimalikult vähe atribuute)
  
• tulevane unikaalsuse tõenäosus (peaks sisaldama unikaalseid väärtuseid nii praegu kui ka tulevikus).
  

6. Välisvõti (teema 2)

• Välisvõtme väärtused loovad seose relatsioonides olevate korteežide vahel.
  
• Iga korteeži a korral relatsioonis Auto peab leiduma täpselt üks korteež m relatsioonis Mark nii, et a.mark_id=m.mark_id.
  
• Relvaris Auto on välisvõ.
  
• Mark.mark_id ja Auto.mark_id peavad olema samade või ühilduvate andmetüüpidega.
  
< peab olema relvaris Mark kandidaatvõti.

• Tavaliselt kasutatakse seose loomiseks primaarvõtit.
  

• Teise relvari (tabeli) primaarvõtme väärtustele vastavad väärtused, mille kaudu saab relvarid omavahel siduda.
  

Välisvõti (ingl. k. foreign key) - Seose loomiseks kahe relatsiooni vahele "tõmmatakse" ühe relatsiooni ühe (või ka mitme) atribuudi andmed teise relatsiooni salvestamiseks. Ühelt poolt peab suhte loomisel osalema unikaalne võti (mõni kandidaatvõtetest). Enamasti on selleks unikaalseks võtmeks primaarvõti. Selle tulemusel on kahes erinevas relatsiooni ühesuguse sisuga atribuudid , mis loovad suhte nende relatsioonide vahel. Seotud relatsiooni tekkinud atribuuti (atribuute) nimetatakse välisvõtmeks. Relatsioonis võib olla üks või mitu välisvõtit. Relatsioonis võib välisvõti ka puududa .

7. Viidete terviklikkuse reegel (teema 2)

Kui relatsioonis eksisteerib välisvõti, siis iga välisvõtme väärtus peab vastama mõnele seotud relatsioonis sisalduvale kandidaatvõtme väärtusele.
Teiste sõnadega ei tohi andmebaasis olla ühtegi välisvõtme väärtust millele ei leidu vastavat kandidaatvõtme väärtust. Näiteks kui relatsioonilisel muutujal Mark on eelneval joonisel näidatud väärtus, siis üheski relatsiooni Auto korteežis ei tohi olla atribuudi mark_id väärtus 6, sest sellise koodiga automargi andmeid ei leidu relatsioonis Mark.
Andmebaasisüsteem peab tagama, et kõik andmebaasis registreeritud andmed rahuldaksid viidete terviklikkuse reeglit.

8. Andmetüüp (teema 2 ja 5)

Andmetüüp e. tüüp e. domeen

• Tüüp on nime omav väärtuste hulk.
  
• Tüüpide näiteid.
  
  • Täisarvu tüüp
    
    • 1 – literaal, esitab ühte täisarvu tüüpi kuuluvat väärtust
      
  • Kuupäeva tüüp
    
  • Ringjoone tüüp
    
  • Röntgenipildi tüüp
    
  • Sõrmejälje tüüp
    
  • Relatsiooni tüüp
    
• Tüüpide liigitus
  
  • Liigitus looja järgi.
    
    • Süsteemi-defineeritud tüüp
      
    • Kasutaja-defineeritud tüüp
      
      • kasutaja on andmebaasi arendaja , mitte lõppkasutaja
        
  • Liigitus struktuuri järgi.
    
    • Skalaarne tüüp – puuduvad kasutajale nähtavad komponendid
      
    • Mitteskalaarne tüüp – kasutajale nähtavad komponendid – atribuudid
      
      • Relatsiooni tüüp
        
      • Korteeži tüüp
        
• Kohustuslik skalaarne tüüp
  
  • Ainus skalaarne andmetüüp, mille olemasolu relatsiooniline mudel nõuab, on tõeväärtustüüp BOOLEAN, kuhu kuuluvad väärtused TRUE ja FALSE .
    
  • BOOLEAN peab olema süsteemi-defineeritud tüüp.
    
  • Kui võrrelda kahte sama tüüpi väärtust, on tulemuseks tõeväärtustüüpi kuuluv väärtus.
    
    • 1=1 => TRUE
      
    • 1=2 => FALSE
      
• Tüüpide nimed
  
  • Tüübil võib olla mitu alternatiivset nime.
    
  • Näited
    
    • CHARACTER, CHAR
      
    • INTEGER, INT
      

9. Kitsendused ja nende võimalik realiseerimine SQL-andmebaasides (teema 2 ja 5)

• Andmebaasis saab deklareerida kitsendusi andmetele.
  
• Andmebaasisüsteem peab tagama, et kõik andmebaasis hoitavad andmed ja toimuvad andmemuudatused vastaksid andmebaasis deklareeritud kitsendustele.
  
• Mistahes andmemuudatus, mis viib andmebaasis olevad andmed mistahes andmebaasis deklareeritud kitsendusega vastuollu, lükatakse andmebaasisüsteemi poolt tagasi.
  
• Kitsenduste liigid relatsioonilises andmebaasis
  
  • Tüübi e. domeeni kitsendus .
    
    • Piirab mingisse skalaarsesse tüüpi kuuluvaid väärtuseid.
      
    • Näide: skalaarse tüübi KAAL_T komponendi suurus võimalikud väärtused on vahemikus 0.0–10000.0 (vahemiku otspunktid kaasa arvatud).
      
  • Kitsendused relatsioonilistele muutujatele (relvaridele).
    
    • Piirab mingite relvaride võimalikke väärtuseid.
      
    • Kitsendused relvaride väärtustele
      
      • Atribuudi kitsendus.
        
        • Relvari Elusolend atribuut kaal on tüüpi KAAL_T.
          
      • Relvari kitsendus (seotud täpselt ühe relvariga).
        
        • Kandidaatvõtme kitsendus.
          
        • Välisvõtme kitsendus (kui välisvõti viitab sama relvari kandidaatvõtmele).
          
        • Etenduse alguse aeg peab olema väiksem kui lõpu aeg (relvar Etendus, milles atribuudid alguse_aeg ja lopu_aeg).
          
      • Andmebaasi kitsendus (seotud kahe või rohkema relvariga).
        
        • Välisvõtme kitsendus (kui välisvõti viitab mõne teise relvari kandidaatvõtmele).
          
          • välisvõtmete juures mainitud kompenseeriva tegevuse võimaluse võib kasutusele võtta ka teiste kitsenduste korral
            
        • Vangide arv peab olema väiksem kui kasutuskõlblike kongide arv (relvarid Vang ja Kong ).
          
    • Kitsendused relvaride väärtuste muutumistele
      
      • Relvari ülemineku kitsendus (seotud täpselt ühe relvariga).
        
        • Relvari Isik atribuut vanuse_hinnang.
          
        • Kitsendus: Isiku vanuse hinnang saab muutuda "Noor"=>"Keskealine", aga mitte vastupidi.
          
      • Andmebaasi ülemineku kitsendus (seotud kahe või rohkema relvariga).
        
        • Kaks relvari – Klient ja Töötaja, mille abil registreeritakse isikute andmeid.
          
        • Kitsendus: Andmebaasis registreeritud isikute koguarv ei tohi andmemuudatuse tulemusena väheneda.
          
• Kitsenduste allikad
  
  • Olemi terviklikkuse reegel
    
  • Viidete terviklikkuse reegel
    
  • Ärireeglid
    
    • Olemi piirangud
      
    • Suhte piirangud
      
    • Järeldusreeglid
      
    • Arvutusreeglid
      

10. Nimetage relatsioonialgebra operatsioone (teema 3)

• Relatsioonialgebra on relatsioonide kui operandidega teostatavate operatsioonide kogum.
  
• Iga operatsiooni tulemus on samuti relatsioon, mis peab vastama kõigile relatsioonilt nõutavatele omadustele.
  
  • Ei tohi olla korduvaid korteeže
    
  • Ei tohi olla mitu samanimelist atribuuti
    
• Hulgateoreetilised operatsioonid.
  
  • Hulgateoreetiline summa - Relatsioonidele r ja s rakendatud hulgateoreetilise summa leidmise operatsioon r U s annab tulemuseks relatsiooni, mille moodustavad kõik kas relatsiooni r, relatsiooni s või mõlemasse kuuluvad korteežid.
    
  • Lõige
    
  • Hulgateoreetiline vahe
    
  • Hulkade ristkorrutis e. otsekorrutis e. Descartesi korrutis
    
• Spetsiaaloperatsioonid.
  
  • Piirang
    
  • Projektsioon
    
  • Ühendamine
    
  • Jagamine
    

11. Virtuaalne relatsioon e. vaade (teema 5)

• Virtuaalne relvar e. vaade (ingl. k. view) – väärtus leitakse kasutaja poolt vaate poole pöördumise hetkel
  
• Vaade e. virtuaalne relatsioon on ühe või mitme baasrelatsioonile rakendatud relatsioonilise operatsiooni tulemus, mille tulemuseks on samuti relatsioon. Selle relatsiooni kirjed pole andmebaasi salvestatud vaid vaate abil kasutaja jaoks dünaamiliselt konstrueeritud.
  

12. Pädevusala (teema 7) (ehk rolli vastutuspiirkond)

• Leitakse süsteemi organisatsioonilise tükelduse tulemusena. Pädevusalade leidmine tähendab süsteemi organisatsioonilist tükeldamist.
  
• Pädevusala on ühe organisatsiooniga seotud rolli vastutuspiirkond. Iga pädevusala vastab mõnele organisatsiooni struktuuriüksusele, ametikohale või infosüsteemi kasutaja rollile.
  
• Igal pädevusalal on funktsioonid (ülesanded), mida see peab täitma ja infovajadused (nõuded andmetele), mida see peab kasutama.
  
• Mitu isikut võivad omada sama pädevusala ja üks isik võib omada mitut pädevusala.
  
• Iga pädevusala kirjeldatakse koostöös selle pädevusala esindajatega (konkreetse isikutega kes hakkaksid seda süsteemi kasutama). Pädevusala esindajad saavad ise osaleda mudelite koostamisel.
  
• Koostatud mudelid on aluseks funktsionaalsete allsüsteemide ja registrite projekteerimisele.
  

Ülikooli IS pädevusala näited:

• Üliõpilane
  
• Õppejõud
  
• Instituudi direktor
  
• Dekanaadi juhataja
  
• Dekanaadi sekretär
  

13. Funktsionaalne allsüsteem (teema 7)

• Leitakse süsteemi funktsioonikeskse tükelduse tulemusena. Funktsionaalsete allsüsteemide leidmine tähendab süsteemi funktsioonikeskset tükeldamist
  
• Funktsionaalne allsüsteem vastab ühele infosüsteemi põhifunktsioonile.
  
• Levinud (aga mitte ainuõige) meetod on leida funktsionaalsed allsüsteemid põhiolemitüüpide (põhiobjektide) kaudu.
  
  • Funktsionaalne allsüsteem tegeleb ühele põhiolemitüübile ja sellega seotud olemitüüpidele vastavate andmete registreerimise, muutmise ja kustutamisega.
    
• Funktsionaalsete allsüsteemide kirjeldustest arenevad süsteemiarenduse käigus välja kasutajaliideste ja rakendustarkvara moodulid, mis aitavad pädevusalade esindajatel oma ülesandeid täita.
  

Ülikooli IS funktsionaalsete allsüsteemide näiteid:
Sisulised
Tugisüsteemid

• Üliõpilaste arvestus
  
• Õppeainete arvestus
  
• Õppekavade arvestus
  
• Õpingukavade arvestus
  
• Õppetulemuste arvestus
  
• Tunniplaanide arvestus
  
• Vastuvõtuaegade arvestus
  

• Töötajate arvestus
  
• Ruumide ja ehitiste arvestus
  
• Dokumentide arvestus
  
• Lepingute arvestus
  
• Klassifikaatorite arvestus
  

14. Register (teema 7)

• Leitakse süsteemi andmekeskse tükelduse tulemusena. Andmekogude ehk registrite leidmine tähendab süsteemi andmekeskset tükeldamist.
  
• Registriks nimetame loogilist andmebaasi,
  
  • milles hoitakse ühele iseseisvat elutsüklit omavale põhiolemitüübile vastavaid andmeid
    
  • ning realiseeritakse selle olemitüübiga seotud elementaarsed registreerimise ja päringu teenused.
    

Ülikooli IS registrite näiteid:
Sisulised
Tugisüsteemid

• Üliõpilaste register
  
• Õppeainete register
  
• Õppekavade register
  
• Õpingukavade register
  
• Õppetulemuste register
  
• Tunniplaani register
  
• Vastuvõtuaegade register
  

• Töötajate register
  
• Ruumide ja ehitiste register
  
• Dokumentide register
  
• Lepingute register
  
• Klassifikaatorite register
  

Register ja selle pakutavad teenused:
Näide: Õpingukavade register

• Andmete lugemise teenus: konkreetse õpingukava andmete leidmine
  
• Andmete muutmise teenus: õpingukava esitamine
  

Andmebaasi kapseldamine

• Registrite pakutavad teenused moodustavad andmebaasi avaliku liidese ning võimaldavad andmebaasis olevate andmete kapseldamist.
  
• Andmebaasis olevaid andmeid lugeda või muuta soovivad programmid kasutavad andmebaasi selle liidese kaudu.
  
• Programmid ei pea teadma andmebaasi siseehitust.
  
• Need teenused on andmebaasioperatsioonid ja neid kirjeldatakse lepingu formaadis .
  

Andmebaasi kapseldamise eesmärgid

• Kui andmebaasi struktuuris teha muudatusi, siis juhul kui liidese avalikku nägu pole vaja muuta, ei ole vaja ümber kirjutada andmebaasi kasutavaid programme .
  
• Võimaldab realiseerida ühe kihi mitmekihilises andmete kaitse mehhanismis .
  
• Vähendab potentsiaalselt võrguliiklust, kuna mitme andmestruktuuri poole pöördumise asemel üks avaliku teenuse poole pöördumine.
  

Registrite modelleerimine

• Ülikooli infosüsteemi põhiolemitüüpideks on muuhulgas üliõpilane ja töötaja.
  
• Nende andmed on üliõpilaste registris ja töötajate registris.
  
• Nende registrite modelleerimisel saab kasutada Party (Osapool) mustrit.
  
  • Kiirendab modelleerimise protsessi.
    
  • Parandab tulemuse kvaliteeti.
    

15. Kuidas on omavahel seotud pädevusalad, funktsionaalsed allsüsteemid ja registrid? (teema 7)

Pädevusala esindaja kasutab ühe või mitme funktsionaalse allsüsteemi teenuseid.

• Funktsionaalne allsüsteem kasutab ühe või mitme registri teenuseid.
  
  • Teenindab (haldab andmeid st. loeb/lisab/muudab/ kustutab andmeid) enamasti ühte registrit .
    
  • Loeb (kasutab) andmeid enamasti mitmest registrist.
    
• Pädevusala esindaja kasutab läbi funktsionaalse allsüsteemi registrites olevaid andmeid.
  

16. Kontseptuaalne andmebaasi disain. Eesmärk, sisendid, tulemused.(teema 7)

Eesmärk.

• Kirjeldatakse kasutaja nõuded selle kohta, milliseid andmeid soovitakse andmebaasis hoida.
  

Millal luuakse ?

• Alustatakse strateegilise analüüsi käigus ja lõpetatakse detailanalüüsi käigus.
  
  • Terve süsteemiarendus koosneb järgmistest järjestikulistest etappidest:
    

Kontseptuaalne andmebaasi disain käib vaid esimese kahe etapi käigus.
Sisend on kasutajate nõuded admetele, mida soovitakse säilitada ja organiseerida.
Tulemused.

• Koostatakse organisatsiooni kontseptuaalne andmemudel, mis on täiesti vaba kõigist realiseerimisega seotud kaalutlustest. Kontseptuaalses andmemudelis ei pöörata tähelepanu ühelegi realiseerimisega seotud asjaolule, nagu andmemudel, kasutatav andmebaasisüsteem, kasutatav riistvara platvorm , kasutatava arvutivõrgu ülesehitus, töökiiruse küsimused jne.
  
• Selle põhjal saab luua andmebaasi tehnilise kirjelduse erinevate keskkondade jaoks.
  

17. Kontseptuaalne andmemudel (teema 7)

Kontseptuaalne andmemudel on mittetehniline mudel, mis kirjeldab süsteemi baasandmeid. Ta kirjeldab nõudeid andmebaasile, aga mitte andmebaasi tehnilist realisatsiooni.
Kontseptuaalse andmemudeli võimalikku struktuuri kirjeldab järgmine valem:
Kontseptuaalne andmemudel = andmebaasi kontseptuaalset struktuuri esitavad diagrammid + diagrammide elementide tekstilised spetsifikatsioonid ( semantika kirjeldus) + andmetega seotud kitsenduste spetsifikatsioonid.

• Võib dokumenteerida kasutades
  
  • olemi-suhte diagrammid, olemitüüpide,
    
  • atribuutide ja seosetüüpide definitsioonid .
    
• Olemi-suhte diagramme võib luua kasutades UML klassidiagramme
  
  • kasutades alamosa UML klassidiagrammide notatsioonist
    
• Üks võimalik alternatiiv oleks dokumenteerimine ORM ( Object -Role Modeling ) mudelite abil ( http://www.orm.net ).
  

Andmemudelite tüübid:
Mõisted:

• Olem (olemieksemplar, ilming) on reaalse maailma füüsiliselt eksisteeriv või abstraktne asi (objekt).
  
• Olemitüüp (olemiklass) on reaalses maailmas esinevate objektide üldistus.
  
• Atribuut on nimeline olemi omadus.
  
• Suhe e. seos on tunnetatud ühendus olemite vahel.
  
• Seosetüüp e. suhtetüüp on olemite vahel olevate seoste üldistus.
  

Kontseptuaalse andmemudeli koostamisel pakuvad huvi ainult sellised olemitüübid, seosetüübid ja atribuudid, millele vastavaid andmeid tuleb hoida andmebaasis.
UMLis joonistatud olemi-suhte diagrammi näide:

18. Mida näitavad andmebaasi operatsioonide lepingud ja milleks neid kasutada? (teema 7)

• Kirjeldavad registri poolt funktsionaalsetele allsüsteemidele pakutavaid teenuseid.
  
• Näitavad lepingu vormis, millised muudatused on operatsiooni tulemusena andmebaasis toimunud. Ei tule kirjeldada muutusi väljaspool andmebaasi – nt. muudatus kasutajaliideses. Tuleb kirjeldada ainult seda, mis andmebaasis operatsiooni tulemusel muutus. Seda mis jäi samaks ei ole vaja kirja panna!
  
  • Operatsiooni kirjelduses vaadeldakse süsteemi kui musta kasti ning ei selgitata kuidas operatsiooni läbi viia (selle otsustamine on disaini ülesanne). Kasutamine väldib kasutusjuhtude infoga ülekoormamist.
    
• Tuleks teha mitte kõigile operatsioonidele, vaid kõige olulisematele /keerukamatele.
  
• Nende alusel saab hiljem koostada andmebaasiserveris talletatud rutiinid.
  

• Kirjeldus lepingu vormis – pannakse kirja eeltingimused ja järeltingimused.
  
  • Metafoor: teatri lava kardina langetamine/tõstmine
    
  • Eeltingimused kirjeldavad, millised andmed peavad olema registreeritud.
    
  • Järeltingimustes näidatakse.
    
    • Andmeobjektide loomine ja kustutamine
      
    • Atribuutide väärtuste muutumine
      
    • Seoste tekkimine ja katkemine
      

Operatsiooni leping andmete muutmisoperatsiooni kohta:
Andmebaasioperatsioonide lepingute kontrollimine:

• Andmebaasioperatsioonide identifikaatorid peavad olema lisatud kasutusjuhu laiendatud formaadis tekstikirjeldusse
  
• Lepingu järeltingimuses peab olema näidatud ka seoste tekkimine/kadumine
  
• Lepingu järeltingimustes ei tule kirjeldada muutusi väljaspool andmebaasi – nt. muudatus kasutajaliideses või väljaspool arvutisüsteemi
  
• Andmebaasioperatsioonide lepingute järeltingimustes tuleb kirjeldada ainult seda, mis operatsiooni tulemusel andmebaasis muutus.
  
• Seda, mis jäi samaks, ei ole vaja kirja panna!
  

19. Nimetage teisendusreegleid, mille põhjal saab kontseptuaalsest andmemudelist tuletada esialgse loogilise disaini andmemudeli. (teema 10)

Analüüsilt disainile:

• Loogilise andmebaasiskeemi esialgse versiooni saab genereerida kontseptuaalsest andmemudelist, kasutades teisendusreegleid.
  
• Teisendusreeglid sõltuvad:
  
  • millist meetodit kasutades on kontseptuaalne andmemudel koostatud (ERD, ORM, ...),
    
    • Väga levinud meetodiks on kasutada kontseptuaalse andmebaasi disaini tulemuste esitamiseks olemi-suhte diagramme.
      
  • millisel andmemudelil põhineb loodav andmebaas.
    

Loogilise andmebaasi disaini teisendusreegleid:
Võtme soovitavad omadused:

• Tuttavlikkus – kasutaja jaoks omab võtme väärtust tähendust
  
• Lihtsus – väärtus on andmemahu mõttes võimalikult väike / koosneb võimalikult vähestest komponentidest
  
• Stabiilsus – väärtus muutub aja jooksul võimalikult harva või ei muutu üldse
  
• Väärtus ei sisalda kodeeritud informatsiooni (nagu isikukood sisaldab infot soo ja sünni aja kohta).
  

Võtmete liigitus:

• Surrogaatvõti – võtme väärtus on unikaalne arvuline väärtus, mida kasutatakse olemi identifitseerimiseks ainult andmebaasis (enamasti süsteemi-genereeritud).
  
  • Lihtsad ja stabiilsed
    
• Sisulise tähendusega võti – võtme väärtus omab kasutajale tähendust ka väljaspool andmebaasi. Nt isikukood.
  
  • Konkreetses reas olev võtme väärtus võib andmebaasi eluea jooksul muutuda.
    
• "Intelligentne" võti – Eelmise erijuht. Võtme väärtusesse on kodeeritud informatsiooni (nt. isikukood).
  

Soovitusi võtmete valikuks :

• Igas tabelis tuleks deklareerida võti (võtmed).
  
• Kui võimalik, kasuta sisulise tähendusega võtit.
  
• Kui mitu lihtvõtmest kandidaatvõtit, vali neist primaarvõtmeks väikseim (andmemahult) ja stabiilseim.
  
• Eelista lihtvõtmeid ja võta vajadusel kasutusele surrogaatvõti.
  
• Ära unusta lisamast unikaalsuse ja kohustuslikkuse kitsendust kõigi alternatiivvõtmete alusel.
  
• Ära mõtle ise välja uusi "intelligentseid" võtmeid.
  

Loogilise andmebaasi disaini teisendusreegleid:
Vt näited Loeng 2 lk 17 - 19.

20. Loogiline andmebaasi disain. Eesmärk, sisendid, tulemused. (teema 10)

Loogiline disain vs füüsiline disain:

• Loogiline disain tegeleb konkreetsest realisatsiooni- ja rakenduskeskkonnast sõltumatute, järelikult nende keskkondade jaoks spetsiaalselt optimeerimata lahenduste loomisega .
  

• Füüsiline disain optimeerib / häälestab loogilise disaini lahendusi konkreetsete “füüsiliste” keskkondade jaoks, st. konkreetsete riist- ja tarkvara produktide jaoks.
  

Andmebaasi projekteerimise sammud:
Loogilise andmebaasi disaini eesmärk:

• Töötada välja andmebaasi struktuur pidades silmas konkreetset andmemudelit (nt. SQL aluseks olev andmemudel), kuid mitte pöörates tähelepanu kasutatavale andmebaasisüsteemile.
  

Loogilise andmebaasi disaini sisendid:

• Kontseptuaalne andmemudel.
  
• Andmebaasioperatsioonide lepingud.
  

Loogilise andmebaasi disaini protsess:

• Valitakse andmemudel (nt. SQL aluseks olev andmemudel).
  
• Esialgne andmebaasiskeem leitakse kontseptuaalse andmemudeli põhjal, kasutades teisendusreegleid.
  
• Andmebaasiskeemi kontrollitakse ja täpsustatakse:
  
  • täiendav normaliseerimine,
    
  • ortogonaalse andmebaasi disaini printsiibi täidetuse kontroll.
    
• Andmebaasioperatsioonide loogiline projekteerimine .
  

Loogilise andmebaasi disaini tulemus:

• Loogilise andmebaasiskeemi kirjeldus.
  
• Andmebaasioperatsioonide täiendatud lepingud (nt. SQL-andmebaasi puhul viidatakse tabelitele ja veergudele).
  

Andmebaasi kasutava rakenduse loogiline disain:

• Sisend.
  
  • Kasutusjuhtude kirjeldused.
    
  • Andmebaasioperatsioonide lepingud.
    
• Tulemus ( eeldusel , et ei loo rakendust objektorienteeritud programmeerimiskeeles).
  
  • Reaalsete kasutusjuhtude (real use case , concrete use case) kirjeldused (mõne kõige olulisema ja keerulisema kasutusjuhu kohta).
    
  • Kasutajaliidese illustratsioonid.
    
  • Transaktsioonide spetsifikatsioonid.
    

Transaktsioon e. tehing:

• Üldiselt.
  
  • Infovahetuse ja sellega seotud toimingute jada (näiteks andmebaasi värskendamine), mida käsitletakse ühe tervikuna .
    

Nt ühet kontolt teisele ülekande tegemine - mitu operatsiooni.

• SQL-andmebaasis.
  
  • Järjestatud hulk (üks või rohkem) SQL lauseid :
    
    • mis täidetakse ühes või mitmes andmebaasis ja
      
    • mis moodustavad ühe loogilise terviku.
      
  • Seega: kas kõigi lausete täitmine õnnestub või ükski lause ei mõjuta üht SQL skeemi ja SQL-andmebaasis olevaid andmeid.
    

Transaktsioonide spetsifikatsioonis näidatakse:

• millised andmebaasioperatsioonid moodustavad ühe transaktsiooni,
  
• milline sündmus põhjustab transaktsiooni käivitumise.
  

21. Normaliseerimine (teema 9)

Normaliseerimine on protsess, mille igal sammul kontrollitakse normaliseeritava relvari vastavust mingile reeglite hulgale. Kui relvar ei vasta reeglitele, tuleb see dekomponeerida (jagada, lagundada, tükeldada) välisvõtmete kaudu seotud relvarideks, millest igaüks vastab nimetatud reeglitele. Iga normaliseerimise sammu tulemusel viiakse relvarid uuele, kõrgemale normaalkujule . Iga relvari saab viia kuuendale normaalkujule. Üldjuhul on soovitav viia relvarid viienda normaalkujuni.
Relatsioonilistes andmebaasides peavad relvarid olema viidud vähemalt esimesele normaalkujule.
Normaliseerimise eesmärgid:

• vähendada andmete liiasust ja selle tulemusena vähendada andmete muutmise anomaaliaid ning muuta andmebaasis olevad andmed kasutajale arusaadavamaks.
  
• parandada loogiliselt ebakorrektset disaini (täiendava normaliseerimise tulemusena saab andmebaasis registreerida tõeseid väiteid, mida seal ilma täiendava normaliseerimiseta ei olnud võimalik registreerida)
  
• muuta andmebaasi struktuur kergemini mõistetavamaks ja paremini "reaalset maailma" peegeldavaks
  
• Samuti on täiendava normaliseerimise tulemusena tekkivates relvarides lihtsam mõningate kitsenduste jõustamine.
  

Milline on hea relatsioonilise andmebaasi disain?

• Meetodid hea disaini tulemuse saamiseks ja disaini headuse hindamiseks:
  
  • täiendav normaliseerimine,
    
  • ortogonaalse andmebaasi disaini printsiip.
    

• Kui leiduvad täpsed ja formaliseeritud meetodid, siis saab hea disainini jõudmise ja disaini headuse kontrolli automatiseerida.
  
• Hästi disainitud andmebaasis on:
  
  • andmete liiasust võimalikult vähe,
    
  • kogu olemasolev andmete liiasus on kontrollitud.
    
• Kontrollitud andmete liiasus tähendab:
  
  • andmebaasi kasutaja on liiasusest teadlik,
    
  • andmebaasisüsteem tagab muudatuste ülekandmise kaudu, et selle liiasuse tõttu ei satu andmebaasi kunagi vastuolulisi andmeid.
    
    • Muudatuste ülekanne on andmebaasisüsteemi, mitte kasutaja ülesanne.
      

Andmebaasi liiasus:

• Andmebaasis on andmete liiasus siis ja ainult siis, kui sama väite saab tuletada sellest kahel või rohkemal erineval viisil.
  
• Andmete liiasus tekitab andmete muutmise anomaaliaid.
  
• Täiendava normaliseerimise ja ortogonaalse disaini printsiibi rakendamise abil ei ole võimalik andmete liiasust täielikult elimineerida – ja seda pole ka sageli vaja.
  

Mõistetest:

• Kasutan relatsioonilise mudeli mõisteid (relvar, relatsioon, atribuut, korteež).
  
  • relvar – relatsiooniline muutuja.
    
• Tutvustatavad disaini headuse kontrolli ja parandamise meetodid on rakendatavad ka SQL-andmebaaside korral.
  
• Tehke mõttes asendus:
  
  • relvar – tabel,
    
  • relatsioon – tabel,
    
  • atribuut – veerg ,
    
  • korteež – rida.
    

Normaalkujud:

• Relvar on mingil normaalkujul, kui see rahuldab kõiki selle normaalkujuga seotud tingimusi.
  
• Relvar, mis on normaalkujul N on ka kõigil madalamatel normaalkujudel.
  
• See ei pruugi olla kõrgematel normaalkujudel N+1, N+2 jne.
  

Normaliseerimata andmed:

22. Esimene normaalkuju (teema 9)

• Relvar on normaliseeritud e. esimesel normaalkujul, kui selle iga legaalse väärtuse igas korteežis on iga atribuudi kohta täpselt üks väärtus, mis on selle atribuudi tüüpi.
  
• Relvar on alati normaliseeritud (esimesel normaalkujul) – muidu see poleks relvar.
  
• Kõrgematele normaalkujudele viimine tähendab täiendavat normaliseerimist.
  

Tabel on normaliseeritud ehk esimesel normaalkujul, kui see esitab otseselt ja täpselt relvari (st. selle puhul kehtivad kõik relvari omadused).
Esimese normaalkuju reeglid:

• Korduvaid veerge ei tohi olla.
  
• Iga andmeväli sisaldab ainult ühte väärtust.
  
• Iga rida ja veerg on tavaline (ei ole peidetud komponente nt: rea ID, timestamp).
  

Esimene normaalkuju – andmete muutmise anomaaliad :

• Fakti lisamine eeldab teiste sõltumatute faktide olemasolu.
  

• Fakti muutmine tingib muutuse mitmes korteežis.
  
• Fakti kustutamine tingib sõltumatute faktide kustutamise ja seega andmete kaotsimineku.
  

23. Kolmas normaalkuju ja Boyce/Coddi normaalkuju (teema 9)

• Definitsioon eeldab, et relvaris on üks kandidaatvõti, mis on valitud primaarvõtmeks.
  
• Relvar on kolmandal normaalkujul kui:
  
  • see on teisel normaalkujul ja
    
  • mitte ükski primaarvõtmesse mitte kuuluv atribuut pole ülekanduvate sõltuvuste kaudu seotud primaarvõtmega. Nt vanus, mis sõltub sünniajast, seda ei ole siin.
    

Kolmandale normaalkujule viimine – sõltuvuste analüüs:
Boyce/Coddi normaalkuju vajadus:

• Kolmanda normaalkuju definitsioon ei käsitle olukorda, kui:
  
  • relatsioonilises muutujas on vähemalt kaks kandidaatvõtit ja
    
  • need kandidaatvõtmed on liitvõtmed ja
    
  • need liitvõtmed on kattuvad (see tähendab, et neil on vähemalt üks ühine atribuut).
    
• Sellest tulenevalt uus "tugevam" normaalkuju – Boyce/Coddi normaalkuju.
  

Boyce/Coddi normaalkuju:

• Relvar on Boyce/Coddi normaalkujul siis ja ainult siis, kui iga selles oleva mittetriviaalse, täieliku funktsionaalse sõltuvuse determinant on kandidaatvõti.
  
• Väga mitteformaalselt öeldes: Relvar on Boyce/Coddi normaalkujul siis ja ainult siis, kui selle iga atribuut sõltub iga kandidaatvõtme korral täielikult kandidaatvõtmest, kogu kandidaatvõtmest ja ainult kandidaatvõtmest.
  

Boyce/Coddi normaalkujule viimine – sõltuvuste analüüs:

24. Ortogonaalse disaini printsiip (teema 9)

• Täiendav normaliseerimine tegeleb andmete liiasusega ühe relvari piires.
  
• Ortogonaalse andmebaasi disaini printsiip (autorid C. J. Date , D. McGoveran) kirjeldab, kuidas vältida andmete liiasust üle erinevate relvaride.
  

Võimalik andmebaasi disain:

• Kõik töötajad saavad palka.
  
  • Relvar Töötaja.
    
• Mõned töötajad saavad fikseeritud suurusega lisatasusid.
  
  • Relvar Lisatasu .
    

Näite disaini probleemid:

• Eraldi võttes on need relvarid kõrge astmeni normaliseeritud.
  
• Kuid sellise struktuuriga andmebaasis on andmete liiasus.
  
  • Töötajate eesnimed on osaks erinevate relvaride väärtustest.
    
• Nendel relvaridel on kattuv tähendus – tähendus on määratud kitsendustega.
  

Parendatud disaini näide:
Ortogonaalse disaini printsiibi põhimõte:

• Andmebaasis ei tohiks olla kattuva tähendusega relvare.
  
• Andmebaasisüsteemi jaoks määravad relvari tähenduse selle relvariga seotud kitsendused.
  

Lõpetuseks:

• Kui andmebaasi disain läheb ortogonaalse disaini printsiibiga vastuollu, siis see ei tähenda tingimata, et tegemist on andmete liiasusega.
  
• Normaliseerimist ja ortogonaalse disaini printsiipi rakendades ei ole võimalik andmete liiasust täielikult kaotada.
  
• On palju andmebaasi disaini probleeme, mida täiendav normaliseerimine ja ortogonaalse andmebaasi disaini printsiip ei aita lahendada.
  

25. Füüsiline andmebaasi disain. Eesmärk, sisendid, tulemused. (teema 12)

Eesmärk:
Disainietapi ülesandeks on analüüsi etapis väljatoodud nõuetele vastavate tehniliste lahenduste väljatöötamine.
Eristatakse loogilist ja füüsilist disaini.
Füüsiline disain optimeerib / häälestab loogilise disaini lahendusikonkreetsete “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.

• Andmebaasi füüsilise disaini käigus toimub andmebaasi kavandamine konkreetset riist- ja tarkvara platvormi (sealhulgas andmebaasisüsteemi) silmas pidades.
  
• Antud kursuses on juttu SQL-andmebaaside füüsilisest disainist .
  
  • Erinevate andmebaasisüsteemide pakutav funktsionaalsus erineb detailides üksteisest küllaltki palju.
    

Andmebaasisüsteem (ka andmebaasihaldur)

• Andmebaasisüsteem on tarkvarasüsteem, mis kontrollib kogu juurdepääsu ühele või mitmele andmebaasile.
  
• Andmebaasisüsteem != andmebaas
  

Mõned nõuded andmebaasisüsteemile

• Andmebaasisüsteem võimaldab kasutada andmebaasikeelt
  
• Andmebaasikeel põhineb mingil andmemudelil
  
• Andmebaasikeele alamkeeled
  
  • Andmekirjelduskeel (DDL)
    
  • Andmekäitluskeel (DML)
    
  • Andmekontrolli keel (mõnikord loetakse andmekirjelduskeele osaks) (DCL)
    
• Transaktsioonide e. tehingute läbiviimise võimalus
  
  • Omadused: atomaarsus, terviklikkus , isoleeritus, kestvus
    
• Andmete mitme kasutaja poolt üheaegse kasutamise võimalus
  
• Andmetele juurdepääsu võimaldamine ainult selleks volitatud kasutajatele
  
• Andmete varundamise/taastamise võimaldamine
  
• Süsteemikataloog
  

Andmebaasisüsteemi kolmekihiline arhitektuur :

• Erinevates andmebaasi tasemetes on erinevat tüüpi objektid, mida andmebaasisüsteem peab võimaldama kasutada.
  
  • Väline tase – andmebaasi kasutajate jaoks mõeldud vaated andmetele (virtuaalsed tabelid ja nendega seotud kitsendused).
    
  • Kontseptuaalne tase – andmebaasi struktuuri ja käitumise kirjeldus (baastabelid, baastabelitega seotud kitsendused, operaatorid ).
    
  • Sisemine tase – andmete füüsilise salvestamise (failid, indeksid) ja operatsioonide realiseerimise küsimused.
    

Loogiline vs. füüsiline sõltumatus
Loogiline andmete sõltumatus – andmebaasi kontseptuaalses skeemis tehtud muudatus ei mõjuta seda kuidas paistavad kasutajatele andmebaasi välised skeemid.
Füüsiline andmete sõltumatus – andmebaasi sisemises skeemis tehtud muudatus ei mõjuta seda kuidas paistab kasutajatele andmebaasi kontseptuaalne skeem.
Relatsiooniline mudel ja kolmekihiline arhitektuur

• Relatsioonilise mudeli poolt ettenähtud objektid kuuluvad:
  
  • välisesse tasemesse
    
    • virtuaalsed relvarid
      
  • kontseptuaalsesse tasemesse
    
    • baasrelvarid, operaatorid
      
• Sisemise taseme struktuurid peavad võimaldama kasutada kõiki relatsioonilises mudelis ette nähtud kontseptuaalse ja välise taseme elemente
  
  • Relatsiooniline mudel ei kirjuta ette, millised peaksid olema sisemise taseme struktuurid
    

Füüsiline andmebaasi disain

• Sisend.
  
  • Loogilise disaini dokumentatsioon.
    
  • Teadmised kasutatava andmebaasisüsteemi ja rakenduse ehitamise vahendite kohta.
    
• Tulemus.
  
  • Andmebaasi kavand konkreetset andmebaasisüsteemi silmas pidades.
    

Andmebaasi andmete füüsiline salvestamine

• Andmebaasi andmed salvestatakse ühte võimitmesse andmefaili.
  
• Andmefail != Tabel.
  
• Andmefail koosneb plokkidest.
  
• Plokil on fikseeritud suurus (nt. 8 KB).
  
  • Sõltuvalt süsteemist võib saada seda suurust andmebaasi loomisel määrata.
    
• Plokil on päis ja sisu osa.
  
  • Päises andmed ploki kohta – näiteks plokki kasutavate transaktsioonide kohta.
    
  • Sisu osas paiknevad tabeli ridade andmed.
    
• Andmete lugemine/kirjutamine kõvakettale toimub plokkide kaupa.
  
• Rea loogiline aadress = tabeli nimi + kandidaatvõtme hõlmatud veergude nimed + kandidaatvõtme väärtus
  
• Rea füüsiline aadress = faili identifikaator + ploki identifikaator + rea positsioon plokis
  

26. Indeks (teema 12)

• Indeks on andmebaasi sisemisse skeemi kuuluv objekt, mille eesmärgiks on kiirendada andmebaasis olevate andmete leidmist .
  
• SQL standard indeksi objekti ei kirjelda.
  
• Ka indeksis on andmed ja salvestatakse (andme) failis .
  

Indeksi loomine ja kasutamine

• Andmebaasisüsteem võib indeksi luua automaatselt (primaarvõtme, unikaalsuse kitsenduse korral).
  
• Indeksi võib luua ka andmebaasi programmeerija või administraator.
  
• Andmebaasisüsteem otsustab, kas ja millal indeksit andmete otsmisel kasutada (SQL lause täitmisplaani koostamise käigus)
  

Indeksite klassifikatsioon

• Osalevate veergude arv
  
  • Lihtindeks – üks veerg
    
  • Liitindeks – rohkem kui üks veerg
    
• Osalevate tabelite arv
  
  • Üks või mitu
    
• Osaleva veeru tüüp
  
  • Primaarne indeks – primaarvõtmes osalevate veergude põhjal
    
  • Sekundaarne indeks – primaarvõtmes mitteosalevate veergude põhjal
    
• Indekseeritud veerus olevate väärtuste unikaalsus
  
  • Unikaalne indeks (primaarvõtme või unikaalsuse kitsendusega hõlmatud veergudele)
    
  • Mitteunikaalne indeks
    
• 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.
    
• Tihedus
  
  • Tihe – üks indeksi kirje iga tabeli rea kohta
    
  • Hõre – üks indeksi kirje mitme tabeli rea kohta
    
• Sisemise ülesehituse viis
  
  • Tasakaalustatud-puu (B-puu) indeks
    
  • Bitmap indeks
    
  • Räsiväärtustel põhinev indeks
    

Indeksi kasutamise üldpõhimõtted

• Indeksid võtavad kõvakettal ruumi.
  
• Indeksid võimaldavad mõningaid päringuid kiiremini täita.
  
• Andmebaasisüsteem otsustab, millal indeksit kasutada. Selleks peab ta teadma statistikat tabelite veergudes olevate andmete kohta.
  
• Mida suurem on tabel, seda rohkem on indeksist kasu, kuid seda suuremad on ka indeksi ülalpidamise kulud.
  

Indeks ja andmete muutmine

• Eelised.
  
  • Indeks aitab muudetavaid /kustutatavaid andmeid kiiremini üles leida.
    
• Puudused.
  
  • Ridade lisamisel, kustutamisel või indeksiga hõlmatud veerule vastavates väljades andmete muutmisel tuleb indeks ümberkorraldada.
    
• 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.
  

Tabeli läbiskaneerimine vs. indeksi kasutamine

• Tabeli läbiskaneerimine tähendab tabeli plokkide lugemist ilma indeksi poole pöördumata.
  
• Indeksi kasutamine ei ole alati parim viis andmete otsimiseks!
  
• Andmebaasisüsteem peaks eelistama tabeli läbiskaneerimist kui:
  
• tabel on väga väike – indeksi lugemine ei vähenda oluliselt loetavate plokkide arvu,
  
  • tabel on suur ja päring tagastab suure hulga tabeli ridadest – indeksi lugemise tõttu loetakse ühte ja sama plokki korduvalt.
    

27. Andmebaasiserveris talletatud rutiinid (teema 13)

• Protseduurides ja funktsioonides saab kasutada SQL käske ja struktuursest programmeerimisest tuntud võimalusi.
  
  • Muutujad.
    
  • Tingimuslause.
    
  • Tsükkel.
    
  • Eranditöötlus.
    
  • Päringu tulemuseks olevate ridade ükshaaval töötlemine.
    
• Protseduuril on null või rohkem sisendparameetrit ja see tagastab null või rohkem väärtust. Nt andmete muutmine.
  
• Funktsioonil on null või rohkem sisendparameetrit ja see tagastab täpselt ühe väärtuse.
  
• Rutiinide kirjutamiseks mõeldud keelte näiteid.
  
  • Oracle: PL/SQL, Java
    
  • PostgreSQL: PL/pgSQL
    
  • MS SQL Server: Transact-SQL
    
  • MySQL (alates 5.0): keel, mis vastab SQL standardile
    

Andmebaasiserveris talletatud rutiinide eelised

• Väheneb võrgu koormus.
  
• Käivitamisel jääb kompileeritud kood mällu.
  
• Muudatusi tuleb teha ühes kohas.
  
• Andmebaasisüsteem jälgib andmebaasiobjektide vahelisi sõltuvusi.
  
• Kasutajale saab anda õiguse käivitada rutiine , aga mitte pöörduda otse tabelite poole.
  

Andmebaasiserveris talletatud rutiinide puudused

• Erinevates andmebaasisüsteemides on rutiinide loomiseks erinevad keeled.
  
• Uue andmebaasisüsteemi kasutuselevõtul tuleb rutiinid uuesti kodeerida.
  

Mille alusel rutiinid koostada?

• Rutiin vastab ühele või mitmele andmebaasioperatsioonile.
  
• Loomise aluseks andmebaasioperatsioonide lepingud.
  

28. Triger (teema 13)

• Triger on andmebaasiobjekt, mis võimaldab andmebaasis toimunud sündmuse tulemusel, juhul kui on täidetud tingimused, käivitada tegevused ( trigeri protseduuri).
  
• Trigeri protseduuri käivitavaks sündmuseks võib olla andmebaasis toimunud andmemuudatus.
  
• Trigeri protseduur võib olla kogum SQL DML (andmekäitluskeele) ja DDL (andmekirjelduskeele) lauseid või andmebaasiserveris talletatud rutiin.
  

Käivitav sündmus SQL standardi järgi

• Trigeri kehandis kirjeldatud tegevuste käivitumise põhjustavad andmete muudatused.
  
  • Ridade lisamine tabelisse (INSERT lause).
    
  • Ridade värskendamine tabelis ( UPDATE lause).
    
    • Saab ka määrata, et triger käivitub andmete muutmisel mingites kindlates veergudes.
      
  • Ridade kustutamine tabelist ( DELETE lause).
    
• Saab määrata, kas trigeri kehandis kirjeldatud tegevused peab täitma enne ( BEFORE ) või pärast (AFTER) muudatust .
  

• Andmemuudatuse täitmine SQL standardi järgi on täitmise järjekord.
  
  • BEFORE trigerid
    
  • SQL andmemuudatuse lause
    
  • Andmemuudatuse kitsendustele vastavuse kontroll
    
  • AFTER trigerid
    
  • Kui mitu BEFORE /AFTER trigerit, siis trigerid täidetakse vanuse järjekorras (leitakse loomise aja järgi) alates vanimast
    
• Trigeri tegevuste ebaõnnestumine põhjustab ka trigeri käivitunud lause täitmise ebaõnnestumise.
  
• Kui see lause sisaldub suuremas transaktsioonis, siis tühistab andmebaasisüsteem terve transaktsiooni käigus tehtud muudatused.
  
  • Võimaldab trigeri abil jõustada kitsendusi – trigeri protseduuris toimub andmete kontroll ning kui avastatakse viga, siis tekitatakse kunstlikult erandolukord.
    

Trigeri kasutamise võimalused

• Andmetega seotud reeglite kontroll
  
• Tuletatud väärtuste arvutamine
  
• Ridade väljade algväärtustamine, kui algväärtus sõltub mingi tingimuse täidetusest
  
• Turvalisuse tagamine
  
• Andmemuudatuste logimine
  
• Vaadete kaudu baastabelites olevate andmete muutmise võimaldamine (INSTEAD OF triger)
  

Deklaratiivsete kitsenduste eelised trigerite ees

• Süsteem valib ise kuidas kontrollida.
  
• Ei pea looma trigereid kõikvõimalikele andmebaasi sündmustele, mis võivad põhjustada kitsendusele mittevastavate andmete andmebaasi sattumist.
  
• Kitsenduse täidetuse kontroll saab toimuda transaktsiooni lõpus.
  
• Kitsenduse loomisel kontrollitakse andmebaasis olevate andmete vastavust sellele.
  

29. Kuidas saada surrogaatvõtme veergu unikaalseid väärtuseid? (teema 13)

Tabelitesse ridade lisamisel osutuvad tihti vajalikuks unikaalsed väärtused, mida saaks lisada uutesse ridadesse, et eristada neid väärtuse poolest teistest ridadest. Andmebaasisüsteem võiks selliseid väärtuseid genereerida.
Tüüpiliselt võimaldab andmebaasisüsteem genereerida täisarve. Selliselt genereeritud arvude tüüpiliseks kasutuskohaks on surrogaatvõtmete väärtused.
Andmebaasisüsteemi poolt genereeritud täisarvud võivad olla:
· Unikaalsed arvud, mis moodustavad monotoonselt kasvava või kahaneva jada. Iga arv erineb eelmisest mingi sammu võrra.
· Juhuslikud arvud

30. Denormaliseerimine (teema 14)

• Loogilise disaini lõpuks võiksid baasrelvarid / baastabelid olla viidud viiendale normaalkujule.
  
• Denormaliseerimine toimub füüsilise disaini käigus.
  
• Denormaliseerimine tähendab vähemalt ühe andmebaasis oleva baasrelvari / baastabeli normaliseerituse astme vähendamist. Denormaliseerimise tulemusel dubleeritakse veerge või ühendatakse tabeleid, et andmete otsimisel oleks vaja viia läbi vähem tabelite ühendamise operatsioone.
  
• Eesmärgiks on suurendada päringute täitmise kiirust.
  
• Lähtutakse eeldusest, et andmebaasisüsteemilt nõuab ühendamise operatsiooni läbi viimine palju vaeva (andmebaasisüsteem peab viima läbi palju I/O (sisend/väljund) operatsioone ja selle kasutamine mõjub andmebaasist andmete otsimiseks mõeldud lausete töökiirusele halvasti.
  

Sobilikud denormaliseerimise kandidaadid

• Tabelid, mida kasutatakse sageli päringutes ja milles andmete muutmised toimuvad harva.
  
• Seetõttu kasutatakse rohkem andmeaitades ja andmevakkades kui operatiivandmete andmebaasides.
  
• Üheksa korda mõõda, üks kord lõika!
  

Denormaliseerimise probleemid

• Pole selge, millal tuleb denormaliseerimine lõpetada.
  
• Tulevad tagasi andmete muutmise anomaaliad, mille pärast normaliseerimine ette võeti.
  
  • Andmete muutmiseks kuluv aeg võib suureneda
    
  • Tuleb tagada andmete kontrollitud liiasus
    
  • Andmemaht suureneb
    
• Andmebaasi kontseptuaalne skeem muutub kasutaja jaoks ebaselgemaks.
  
• Kitsenduste jõustamine muutub keerulisemaks.
  
• Mõnede päringute kirjutamine võib muutuda keerukamaks – nõuavad keerukamat süntaksi.
  
• Denormaliseerimine võib suurendada ka päringule vastuse saamise aega.
  
  • Võib näiteks juhtuda, kui tabeli veergude hulk läheb nii suureks, et üks rida ei mahu ära ühte plokki ja andmebaasisüsteem peab seetõttu vastuse leidmiseks lugema rohkem plokke.
    

Parem lahendus

• Parem lahendus oleks, kui
  
  • andmebaasisüsteemid lubaksid baastabeleid ühendada sisemisel (plokkide ja failide) tasemel,
    
  • kuid kontseptuaalsel tasemel jääksid baastabelid lahku.