Eeldame, et seisund "Aktiivne" on koodiga 2. Tuleb luua CHECK kitsendus.
Ei tohi eksisteerida mitte ühtegi aktiivses seisundis tuba, millel pole ühtegi seotud kategooriat.
See kitsendus rakendub, kui muudetakse toa seisundit tabelis Tuba. See kitsendus ei keela aktiivsete tubade kategooriad ära kustutada.
Töövihiku projektis tuleneb see kitsendus sellest, et aktiivsete tubade vaatamine toimub kategooriate järgi. Kui aktiivne tuba pole üheski kategoorias, siis selle toa andmeid vaadata ei saa. Töövihiku projektis on see kitsendus väljendatud valvurtingimusena seisundidiagrammil oleval seisundi üleminekutel seisundisse "Aktiivne".
SQL näeb ka ette andmebaasiobjekti tüüpi üldine kitsendus (assertion). See on eraldisseisev nimega CHECK kitsendus, mis pole seotud otseselt ühegi tabeliga, kuid mille loogikaavaldises olev päring võib viidata andmebaasi erinevatele tabelitele. Tänapäeva turul olevad andmebaasisüsteemid paraku sellise andmebaasiobjekti loomist ei võimalda. Oracle foorumis tekitas sellist tüüpi objekti toe lisamine väga palju positiivset tagasisidet, kuid Oracle andmebaasisüsteemi pole seda tüüpi objekti tuge ikkagi lisatud.
MS Accessis saab luua lisakitsendusi tabeliga seotud CHECK kitsendustena. Erinevalt paljudest teistest andmebaasisüsteemidest (nt PostgreSQL, Oracle, MySQL), saab MS Accessis kasutada sellistes CHECK kitsendustes alampäringuid.
Üldised kitsendused ja tabeli CHECK kitsendustes alampäringute kasutamine võimaldavad jõustada keerukamaid reegleid
Tulles tagasi vastuse alguses oleva näite juurde, siis kui selle kitsenduse saaks jõustada üldise kitsendusena (assertion), siis keelaks see ka aktiivselt toalt kõikide kategooriate kustutamise. Praegune lahendus seda ei keela.
Võite küsida, milleks sellest rääkida, kui paljudes teistes andmebaasisüsteemides sellist kitsendust luua ei saa. Vastusena ütleksin, et siin on MS Access ajast ees, mitte ajast maas. Kui kitsendusi saab luua andmebaasi tasemel väikese koodi hulgaga ja möödahiilimist välistaval viisil, siis see lihtsustab märkimisväärselt andmebaasirakenduse loomist.
Nende teiste, kaasaegsemate ja võimekamate süsteemide puhul, tuleb kontrolle teha andmebaasis trigeritega, andmete registreerimiseks mõeldud andmebaasiserveris talletatud rutiinides, rakenduses või jätta üldse tegemata - kõigi selliste lahendusvariantidega on seotud omad suured probleemid ja raskused.
ALTER TABLE TubaADD CONSTRAINT chk_tuba_aktiivne_peab_olema_kategooriaga CHECK (NOT EXISTS (SELECT *FROM TubaWHERE toa_seisundi_liik_kood=2AND NOT EXISTS (SELECT *FROM Toa_kategooria_omamineWHERE Tuba.tuba_kood=Toa_kategooria_omamine.tuba_kood)));Ei tohi eksisteerida mitte ühtegi aktiivses seisundis tuba, millel pole ühtegi seotud kategooriat.
See kitsendus rakendub, kui muudetakse toa seisundit tabelis Tuba. See kitsendus ei keela aktiivsete tubade kategooriad ära kustutada.
Töövihiku projektis tuleneb see kitsendus sellest, et aktiivsete tubade vaatamine toimub kategooriate järgi. Kui aktiivne tuba pole üheski kategoorias, siis selle toa andmeid vaadata ei saa. Töövihiku projektis on see kitsendus väljendatud valvurtingimusena seisundidiagrammil oleval seisundi üleminekutel seisundisse "Aktiivne".
SQL näeb ka ette andmebaasiobjekti tüüpi üldine kitsendus (assertion). See on eraldisseisev nimega CHECK kitsendus, mis pole seotud otseselt ühegi tabeliga, kuid mille loogikaavaldises olev päring võib viidata andmebaasi erinevatele tabelitele. Tänapäeva turul olevad andmebaasisüsteemid paraku sellise andmebaasiobjekti loomist ei võimalda. Oracle foorumis tekitas sellist tüüpi objekti toe lisamine väga palju positiivset tagasisidet, kuid Oracle andmebaasisüsteemi pole seda tüüpi objekti tuge ikkagi lisatud.
MS Accessis saab luua lisakitsendusi tabeliga seotud CHECK kitsendustena. Erinevalt paljudest teistest andmebaasisüsteemidest (nt PostgreSQL, Oracle, MySQL), saab MS Accessis kasutada sellistes CHECK kitsendustes alampäringuid.
Üldised kitsendused ja tabeli CHECK kitsendustes alampäringute kasutamine võimaldavad jõustada keerukamaid reegleid
- ühes kohas,
- kaitstavatele andmetele lähedal (andmebaasis),
- kontrollist möödahiilimist vältival viisil,
- väikese koodi hulgaga.
Tulles tagasi vastuse alguses oleva näite juurde, siis kui selle kitsenduse saaks jõustada üldise kitsendusena (assertion), siis keelaks see ka aktiivselt toalt kõikide kategooriate kustutamise. Praegune lahendus seda ei keela.
Võite küsida, milleks sellest rääkida, kui paljudes teistes andmebaasisüsteemides sellist kitsendust luua ei saa. Vastusena ütleksin, et siin on MS Access ajast ees, mitte ajast maas. Kui kitsendusi saab luua andmebaasi tasemel väikese koodi hulgaga ja möödahiilimist välistaval viisil, siis see lihtsustab märkimisväärselt andmebaasirakenduse loomist.
Nende teiste, kaasaegsemate ja võimekamate süsteemide puhul, tuleb kontrolle teha andmebaasis trigeritega, andmete registreerimiseks mõeldud andmebaasiserveris talletatud rutiinides, rakenduses või jätta üldse tegemata - kõigi selliste lahendusvariantidega on seotud omad suured probleemid ja raskused.
Hinda postitust:
Keskmine hinne : Pole veel hinnanguid!