Lepingprojekteerimise (design by contract) kohaselt kirjeldatakse tarkvaraelement kasutades eeltingimusi, järeltingimusi ja invariante. Kui on täidetud kõik eeltingimused, siis saab operatsioon saavutada järeltingimused. Invariandid on tingimused, mis peavad olema alati täidetud. Andmebaasioperatsioone saab kirjeldada lepingu formaadis. Andmebaasioperatsioonid saab realiseerida andmebaasiserveris talletatud rutiinidena. Invariandid saab realiseerida andmebaasis loodud kitsendustena. Rutiini väljakutsuja vastutab eeltingimuste täidetuse tagamise eest ning kui need on täidetud, siis saab väljakutsuja oodata rutiinilt järeltingimuste saavutamist. Oluline on tagada, et järeltingimused saavutatakse vaid siis, kui kõik eeltingimused on täidetud. Rutiin võib, kuid ei pruugi, kontrollida selleks eeltingimuste täidetust. Rutiinis teostatavate kontrollide puhul tuleks vältida dubleerimist, et mitte minna vastuollu "ära korda ennast" printsiibiga. Andmebaasis loodud rutiinide puhul tuleb arvestada, et andmebaasis loodud deklaratiivsed kitsendused ja trigerid moodustavad keskkonna, milles andmebaasis toimuvad operatsioonid saavad õnnestuda vaid siis, kui teatud eeltingimused on täidetud. Nende eeltingimuste jõustamine toimub väljapool rutiini ja nende eeltingimuste täidetuse kontrolli ei peaks rutiinis kordama.
Näide
Andmebaasis on tabelid
Kaup saab olla kas seisundis koodiga 1, 2 või 3.
OP 1 Aktiveeri kaup (p_kaup_kood)
Eeltingimused
a) Seisund koodiga 1 on registreeritud
b) Seisund koodiga 2 on registreeritud
c) Kaup koodiga (p_kaup_kood) on seisundis koodiga 1
d) Seisund koodiga 2 on aktiivne
Järeltingimused
a) Kaup koodiga (p_kaup_kood) on seisundis koodiga 2
Eeldame, et NOT NULL kitsendused ja välistvõtmed on andmebaasis deklareeritud ja andmebaasisüsteemi poolt jõustatud ja nendele vastavaid kontrolle rutiin ei vaja. Kui andmebaasis EI OLE eelnimetatud trigereid, siis peaks kauba aktiveerimise funktsioonis olema lause.
Deklaratiivsed kitsendused (NOT NULL, FOREIGN KEY, PRIMARY KEY, UNIQUE, CHECK) jõustavad piirangu andmebaasi väärtusele - mis andmed tohivad andmebaasi olla.
Eelpool mainitud kaks trigerit jõustavad piirangud andmebaasi väärtuse muudatusele - mis andmemuudatused tohivad andmebaasis toimuda.
Deklaratiivsed kitsendused ja trigerid rakenduvad sõltumata sellest, kas andmeid muudetakse läbi rutiinide või tehakse seda otse tabelites. Need jõustavad reeglid, mis peavad olema alati täidetud e lepingprojekteerimise mõttes on tegemist invariantidega. Hüpotees: Kui leida ja jõustada andmebaasis kõik andmebaasioperatsioonide invariandid, siis pole andmebaasioperatsioonides vaja kontrollida ühegi eeltingimuse täidetust.
Näide
Andmebaasis on tabelid
Kauba_seisundi_liik (kauba_seisundi_liik_kood, nimetus, on_aktiivne)Primaarvõti (kauba_seisundi_liik_kood)Kaup (kauba_kood, kauba_seisundi_liik_kood)Primaarvõti (kauba_kood)Välisvõti (kauba_seisundi_liik_kood) Viitab Kauba_seisundi_liik (kauba_seisundi_liik_kood)Kaup saab olla kas seisundis koodiga 1, 2 või 3.
OP 1 Aktiveeri kaup (p_kaup_kood)
Eeltingimused
a) Seisund koodiga 1 on registreeritud
b) Seisund koodiga 2 on registreeritud
c) Kaup koodiga (p_kaup_kood) on seisundis koodiga 1
d) Seisund koodiga 2 on aktiivne
Järeltingimused
a) Kaup koodiga (p_kaup_kood) on seisundis koodiga 2
- Tabelis Kaup veerule kauba_seisundi_liik_kood loodud NOT NULL kitsendus tagab, et kaubal peab olema alati seisund.
- Tabelis Kaup veerule kauba_seisundi_liik_kood loodud välisvõtme kitsendus tagab, et kaubal saab enne muutmist olla seisund koodiga 1 ja peale muutmist seisund koodiga 2 ainult siis, kui seisundid koodidega 1 ja 2 on registreeritud seisundite tabelis.
- Kui andmebaasis ON triger, mis kontrollib, et kaup saab minna seisundisse koodiga 2 seisundist koodiga 1, kuid mitte seisundist koodiga 3, siis see tagab eeltingimuse c) kontrolli.
- Kui andmebaasis ON triger, mis kontrollib, et kaup saab minna ainult seisundisse, mis on aktiivne, siis see tagab eeltingimuse d) kontrolli.
UPDATE Kaup
SET kauba_seisundi_liik_kood=2
WHERE kauba_kood=p_kaup_kood;Eeldame, et NOT NULL kitsendused ja välistvõtmed on andmebaasis deklareeritud ja andmebaasisüsteemi poolt jõustatud ja nendele vastavaid kontrolle rutiin ei vaja. Kui andmebaasis EI OLE eelnimetatud trigereid, siis peaks kauba aktiveerimise funktsioonis olema lause.
UPDATE Kaup
SET kauba_seisundi_liik_kood=2
WHERE kauba_kood=p_kaup_kood
AND kauba_seisundi_liik_kood=1 --kontrollitakse, et kaup oli enne muutmist seisundis 1
AND EXISTS (SELECT *
FROM Kauba_seisundi_liik
WHERE kauba_seisundi_liik_kood=2
AND on_aktiivne=TRUE FOR UPDATE) /*kontrollitakse, et seisund koodiga 2 on aktiivne
FOR UPDATE tagab, et keegi ei saa samal ajal seisundit mitteaktiivseks muuta*/;
Deklaratiivsed kitsendused (NOT NULL, FOREIGN KEY, PRIMARY KEY, UNIQUE, CHECK) jõustavad piirangu andmebaasi väärtusele - mis andmed tohivad andmebaasi olla.
Eelpool mainitud kaks trigerit jõustavad piirangud andmebaasi väärtuse muudatusele - mis andmemuudatused tohivad andmebaasis toimuda.
Deklaratiivsed kitsendused ja trigerid rakenduvad sõltumata sellest, kas andmeid muudetakse läbi rutiinide või tehakse seda otse tabelites. Need jõustavad reeglid, mis peavad olema alati täidetud e lepingprojekteerimise mõttes on tegemist invariantidega. Hüpotees: Kui leida ja jõustada andmebaasis kõik andmebaasioperatsioonide invariandid, siis pole andmebaasioperatsioonides vaja kontrollida ühegi eeltingimuse täidetust.
Hinda postitust:
Keskmine hinne : Pole veel hinnanguid!