Kodulehed
[380] - Andmebaasid I (ITI0206) (kevad 2021)
pinned Kiirvalik Kõige olulisemate tegevuste kiirvalik
Üldist
Materjalid Materjalide kataloogid
Vaated Erinevad väljavõtted kataloogides olevatest materjalidest. Alternatiivsed juurdepääsuteed materjalidele.
Isiklik Info ainult Sulle - teised kasutajad seda ei näe
Abi Võimalus küsida õppejõult abi (nagu foorum, kus saab küsida küsimusi ja kommenteerida vastuseid)
Mitmesugust
Abi / Kasutajatugi / Andmebaasi kavandamise sisulised küsimused

Avalikud küsimused ja vastused:
Teemad:

                         
Anonüümne:
Kui Enterprise Architect (EA) ei luba töötada DDLenhace-ga ja mudeli disain tuleb teha DDL-ga, siis kuidas kontrollida millised parameetrid peavad olema kohustuslikud ja millised PK või FK ning millistel parameetritel peab olema vaikimisi väärtus?
Vastus: Atribuutide alusel tekkivate veergude kohustuslikkus

Atribuutide definitsiooni tabelis (jaotises 2.2.1 - peale olemi-suhte diagramme ja olemitüüpide definitsioone) peab iga atribuudi puhul kitsenduste osasse kirjutama, kui see on kohustuslik, st selle väärtus peab olema alati määratud - {Registreerimine on kohustuslik.} Lisaks tuleb Enterprise Architecti abil tehtud olemi-suhte diagrammides ära näidata, millised atribuudid on kohustuslikud (võimsustik (multiplicity) 1) ja millised mittekohustuslikud (võimsustik 0..1).

Kui teisendate kontseptuaalse andmemudeli SQL-andmebaasi disaini mudeliks, siis laias laastus vastab igale atribuudile eraldi tabeli veerg. Kui atribuut on kohustuslik, siis vastavale veerule tuleb deklareerida NOT NULL kitsendus. Kui atribuut ei ole kohustuslik, siis seda kitsendust ei ole. Kontseptuaalse andmemudeli mallis olevatest atribuutidest on mittekohustuslikud:

  • Isik.eesnimi
  • Isik.perenimi
  • Isik.elukoht
  • Amet.kirjeldus

Ülejäänud atribuudid on kohustuslikud (st vastavatel veergudel peab olema NOT NULL). Võimalik, et lisatud X atribuutide hulgas on ka mõni mittekohustuslik (nt kirjeldus või kommentaar), kuid see valik on juba Teie teha.

Seosetüüpide alusel tekkivate veergude kohustuslikkus

Mis puudutab välisvõtme veergude kohustuslikkust, siis see sõltub seosetüübi võimsustikest (multiplicity). Näide:

[Riik]-1-+isikukoodi riik-----------0..*-[Isik]

Iga isik on seotud täpselt ühe isikukoodi riigiga. Järelikult tabelisse Isik tekkival välisvõtme veerul riik_kood peab olema NOT NULL kitsendus.

[Riik]-0..1-+isikukoodi riik-----------0..*-[Isik]

Iga isik on seotud nulli või ühe isikukoodi riigiga. Järelikult tabelisse Isik tekkiv välisvõtme veerg riik_kood võib lubada NULLe.

Malli järgi projekti tehes peaks kõikidele välisvõtme veergudele deklareerima NOT NULL kitsenduse.

Vaikimisi väärtused

Vaikimisi väärtused on mugavusvahend, juhuks, kui paljudes/kõigis uutes ridades on ühesugune väärtus või ühesugusel viisil leitav väärtus. Vaikimisi väärtus ei ole kitsendus - sellest saab alati jõuga üle sõita. Malli järgi tehtavas projektis peaksid olema järgmised vaikimisi väärtused.

  • Välisvõtme veergudel, mis viitavad seisundiklassifikaatorite tabelitele (Isiku_seisundi_liik, Tootaja_seisundi_liik, Kliendi_seisundi_liik, X_seisundi_liik) - väärtus, mis näitab esimesena saadava seisundi koodi. Näiteks X korral on selleks seisundile "ootel" vastav kood, sest seisundidiagrammi alusel (vt jaotis 2.2.3) läheb iga X kõigepealt seisundisse "ootel". Need vaikimisi väärtused peavad olema tabelites Isik, Tootaja, Klient, X.
  • Isik.reg_aeg ja X.reg_aeg - avaldis, mille poole pöördumisel tagastatakse hetke kuupäev ja kellaaeg (näiteks MS Accessis Now()).
  • Klient.on_nous_tylitamisega - FALSE - tulenevalt vaikimisi andmekaitse põhimõttest.

Primaarvõtmed

Hästi kavandatud SQL-andmebaasi tabelis tuleb jõustada kõik kandidaatvõtmed - üks primaarvõtmena (PRIMARY KEY kitsendus) ülejäänud alternatiivvõtmetena (UNIQUE+NOT NULL kitsendus). Kontseptuaalses andmemudelis tuleb atribuutide definitsiooni kirja panna, kui mingi atribuut või atribuutide kombinatsioon on unikaalne identifikaator. Primaarvõti tuleb kas jõustada ühele nendest vastavate veergude alusel või defineerida surrogaatvõti. Surrogaatvõtme väärtused on süsteemi poolt genereeritud unikaalsed täisarvud, mida kasutatakse olemitele viitamiseks ainult tarkvarasüsteemi siseselt, mitte inimeste maailmas. Malli alusel tehtavas projektis on surrogaatvõti mõistlik ainult tabelis Isik - (isik_id). Ülejäänud tabelites saab valida sisulise võtme - näiteks tabelis Riik (riik_kood), tabelis X (X_kood) jne. Tabelites Klient ja Tootaja peaks primaarvõti (isik_id) kokku langema välisvõtmega, mis viitab tabelile Isik.

Välisvõtmed

Üks-mitmele seosetüübi korral tekib välisvõti mitu poolel olevasse tabelisse.

[Riik]-1-+isikukoodi riik-----------0..*-[Isik] - välisvõti on tabelis Isik.

Mitu-mitmele seosetüübi korral tekib vahetabel koos kahe välisvõtmega.




1.
Erki Eessaar:
2.
Erki Eessaar:
3.
Anonüümne:
4.
Anonüümne:
5.
Ajaloo säilitamine PostgreSQL andmebaasisüsteemis:
6.
Pull request'ide sarnase süsteemi loomine Postgres:
7.
Erki Eessaar:
8.
Erki Eessaar:
9.
Erki Eessaar:
10.
Erki Eessaar:
11.
Anonüümne:
12.
Erki Eessaar:
13.
Erki Eessaar:
14.
Erki Eessaar:
15.
Erki Eessaar:
16.
Erki Eessaar:
17.
Erki Eessaar:
18.
Erki Eessaar:
19.
Erki Eessaar:
20.
Erki Eessaar:
21.
Anonüümne:
22.
Erki Eessaar:
23.
Erki Eessaar:
24.
Erki Eessaar:
25.
Anonüümne:
26.
Erki Eessaar:
27.
Anonüümne:
28.
Erki Eessaar:
29.
Anonüümne:
30.
Erki Eessaar:
31.
Anonüümne:
32.
Anonüümne:
33.
Anonüümne:
34.
Erki Eessaar:
35.
Anonüümne:
36.
Eerik Sven Puudist: