Kodulehed
[387] - Andmebaasid II (ITI0207) (sügis 2024)
Esiletöstetud Kiirvalik
Lisainfo Kõige olulisemate tegevuste kiirvalik. Failide saatmiseks valige Vastamine alt sobiv ülesanne.
Üldist
Materjalid
LisainfoMaterjalide kataloogid.
Värvilised mummud tähistavad hinnangulist kataloogide lugemise vajadust. Roheline - suurim, kollane - keskmine, punane või mummuta - väikseim
Isiklik
Lisainfo Info ainult Sulle - teised kasutajad seda ei näe
Abi
Lisainfo Võimalus küsida õppejõult abi (nagu foorum, kus saab küsida küsimusi ja kommenteerida vastuseid)
Mitmesugust
Abi / Kasutajatugi / Andmebaasi kavandamine

Avalikud küsimused ja vastused:

Küsimuste teemade nimekiri

Anonüümne:
Kas uuendatavate vaadete (vaated, mille kaudu andmebaasisüsteem põhimõtteliselt lubaks INSERT/UPDATE lauseid käivitada) puhul on ikka vaja WITH CHECK OPTION kitsendust kasutada?
Vastus:

Jah on.

Näiteks, kui juhataja rollis kasutaja näeb sellise vaate

CREATE VIEW kinnitamata_tellimuste_vaade AS
SELECT tellimuse_kood, tellimuse_seisundi_liik_kood
FROM Tellimus
WHERE
tellimuse_seisundi_liik_kood=2;

kaudu kinnitamata tellimusi ja tal on vaate suhtes muutmisõigus, siis saaks ta ilma selle kitsenduseta käivitada lause:

UPDATE kinnitamata_tellimuste_vaade SET tellimuse_seisundi_kood=3 WHERE tellimuse_kood='XX';

Selle tulemusena kaob tellimus XX kinnitamata tellimuste nimekirjast ära.

Miks ma leian, et selline vaade vajab WITH CHECK OPTION kitsendust, mis keelab põhimõtteliselt sellise muudatuse tegemise (sõltumata kasutaja muutmisõigusest vaate suhtes)?

See on põhimõtte küsimus. Süsteemi õpitavuse, kasutamise efektiivsuse, meeldejäävuse ja arusaadavuse seisukohalt on oluline, et süsteemi osade käitumine on ootuspärane, järjekindel ja võimalikult väheste eranditega - kokkuvõtlikult järgiks ortogonaalse disaini printsiipi. Olen ortogonaalse disaini printsiibist kirjutanud "Andmebaasid I" materjalides. Tarkvarakeel, mis on kavandatud ortogonaalse disaini printsiipi arvestades:

  • pakub suhteliselt väikese hulga keelekonstruktsioone
  • koos terviklike ja järjekindlate reeglitega nende konstruktsioonide kombineerimise kohta
  • ning iga konstruktsioonide kombinatsioon on legaalne ja sisulist tähendust omav.

SQL on näide keelest, mis paraku paljudes kohtades RIKUB ortogonaalse disaini printsiibi põhimõtteid ning nagu on näha käesolevast näitest, siis võimaldab ka luua süsteeme, mis omakorda seda printsiipi rikuvad.

Baastabel, virtuaalne tabel e vaade, kitsendus, UPDATE ja INSERT operatsioon kuuluvad SQLi põhiliste konstruktsioonide hulka. Ortogonaalse disaini printsiibi mõtte kohaselt:

  • INSERT ja UPDATE operatsioonid toimivad ühtemoodi nii baastabelitel kui virtuaalsetel tabelitel (seega, näiteks, kuna UPDATE lause baastabelist ridu ei kustuta, siis ei tee see seda ka virtuaalsete tabelite korral).
  • Kitsendusi jõustatakse ühtemoodi nii baastabelitel kui virtuaalsetel tabelitel, st ei lubata nendes teha muudatusi, mis lähevad vastuollu neile defineeritud kitsendustega. Virtuaalse tabeli alampäringus olev piirang (predikaat) on selle tabeli kitsendus, mis ütleb, millistele tingimustele vastavad read selles tabelis sisalduvad.

Tulles tagasi jutu alguses olnud näite juurde, siis siin tuleks lisaks vaatele teha funktsioon, mille sisuks on etteantud koodiga tellimuse kinnitamine. Kasutajale antakse õigus käivitada funktsiooni, kuid ei anta UPDATE õigust vaate suhtes. Seega vaade on praktikas kasutusel andmete lugemiseks ning funktsioon selleks, et seisundit muuta. Funktsioon muudab andmeid otse baastabelis Tellimus. Sellise lahenduse põhjenduseks on SQLi suured piirangud uuendatavatele vaadetele (mis on kõigele lisaks erinevates andmebaasisüsteemides erinevad). Seetõttu on otstarbekas vaadete uuendamise võimalust (andmete muutmine vaate kaudu) praktikas mitte kasutada. Põhimõtte pärast peaks sellisel vaatel minu arvates aga siiski olema WITH CHECK OPTION kitsendus.

Hinda vastust:

Keskmine hinne : Pole veel hinnanguid!