によって Szerencse András 7年前.
165
A kényszerek egyszerű előírások, szabályok az adatbázisban található adatokra nézve, melyek elősegítik a konzisztencia fenntartását az adatbázis-szerver szintjén. Sőt, a kényszerek ismeretében az Oracle képes a lekérdezéseket is jobban optimalizálni.
Ilyen szabály lehet például egy mező (attribútum) adatainak szintaktikai ellenőrzése (pl. személyi igazolvány szám: két betű, hat szám formátumú (régi, füzet formájú) vagy fordított sorrendben (új, kártya formájú) legyen), de több adat összefüggését is ellenőrizhetjük (az adatok közötti hivatkozások helyességének fenntartása érdekében).
A kényszerek tehát igen hasznosak tudnak lenni, ugyanakkor – tapasztalat szerint – egy rendszer módosítása során sok gondot is tudnak okozni.
Források:
https://www.db.bme.hu/sites/default/files/kenyszerek.pdf
http://docs.oracle.com/cd/B19306_01/server.102/b14200/clauses002.htm
A többfelhasználós működés a tranzakciókezelést különösen bonyolulttá teszi.
A legnagyobb kihívás a több felhasználó által egy időben végrehajtott módosítások ellenőrzése jelenti. A FOREIGN KEY megszorítást a különböző adatbázis kezelő rendszerek más-más módon biztosítják. Egyes rendszereknél ilyenkor is kötelező az index (a külső kulcson) még másoknál csak ajánlott.
Kényszerek biztosítása:
forrás: http://users.iit.uni-miskolc.hu/~kovacs/db2/ora7.html
Az idegen kulcsok ellenőrzése szintén rendszerfüggő.
Valahol ilyenkor is kötelező az index máshol csak ajánlott.
Ellenőrzésük általában egyedi indexek segítségével történik. Az indexek a kényszer létrehozásakor maguktól létrejönnek.
Ellenőrzésük egyszerű, mert a beszúrandó sor értékeit ellenőrzi a rendszer.
Más rendszerek csak a tranzakció végén ellenőriznek.
Itt bevihetünk először detail és csak utána master adatot.
Bizonyos rendszerek a kényszereket rögtön a DML utasítás végén ellenőrzik. Ha megpróbálnánk megszegni a kényszert hibaüzenetet kapnánk
Amikor egy táblát eldobunk, akkor a constraint-jei is eldobódnak.
Szintaxisa:
drop table táblanév;
Forrás:
előadás
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_9003.htm
Autós példa: Az autók táblát sikerül eldobni, mer arra semmi se hivatkozik
Olyan táblát, amire mutat idegen kulcs nem lehet kitörölni.
Először a hivatkozót kell eldobni és csak utána lehet a hivatkozottat.
Autós példa: A szin táblát addig nem tudjuk eldobni, amíg az autok tábla hivatkozik rá
Kényszereket ki-be kapcsolhatunk.
Autós példa: Az autok tábla kényszereit előre definiáltuk. Ha az autok táblát előbb akarjuk feltölteni, mint a szinek táblát, akkor ideiglenesen kikapcsolhatjuk az idegen kulcs kényszert. Majd ha végeztünk az adatfeltöltéssel visszakapcsolhatjuk a kényszert.
Meglévő kényszer eldobása.
Ahhoz, hogy kényszert el tudjunk dobni tudni kell a nevét.
ALTER TABLE departments
DROP CONSTRAINT pk_dept CASCADE;
Forrás: https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#SQLRF01001
Kényszer hozzáadása egy meglévő táblához.
Szintaxisa:
alter table
tábla_neve
add constraint
kényszer_neve
Forrás: http://www.dba-oracle.com/t_alter_table_add_constraint_syntax_example.htm
Kényszer megadása a tábla definiálásakor.
A constraint nem lekérdezés során keletkezik, hanem korábban, az adatmodell megtervezésekor
A kényszerekkel jellemezhetjük/korlátozhatjuk adatbázisunk tartalmát. A kényszerekkel ellentétes műveletek nem hajtódnak végre.
A kényszereket deklaratív adatintegritási szabályoknak is nevezzük.
Az adatmodell logikai struktúra és az azon értelmezett műveletek összessége.
Szükségünk lehet olyan értékkorlátozásra, amit nem tudunk kényszerekkel megadni. Bonyolultabb megszorításokat programkóddal lehet létrehozni pl. adatbázis triggerekkel
Az SQL szabvány nem definiálja elég szigorúan ezért az egyes adatbáziskezelő-rendszerek lehetőségekben/szintaktikailag eltérhetnek egymástól.
FOREIGN KEY
A FOREIGN típusú kényszer a legérdekesebb és legbonyolultabb kényszer az Oracle repertoárjában. Idegen kulcsot jelöl, tehát az adott táblában bizonyos mezők – egy másik tábla bizonyos mezői alapján – hivatkoznak a másik tábla rekordjaira. A hivatkozott táblát általában szülő, a hivatkozó táblát gyermek táblának szokták hívni. Az idegen kulcshoz tartozó kényszert a gyermek táblában definiáljuk.
Forrás:
https://www.db.bme.hu/sites/default/files/kenyszerek.pdf
A feladat ugyanaz mint az előbb, csak most táblakényszerként adtuk meg az idegen kulcsot.
Azt szeretnénk, hogy az autó színét csak a szinek táblában szereplő értékek közül lehessen bevinni az adatbázisba.
Amikor a kényszert oszlopszinten definiáljuk nem kell a FOREIGN KEY kulcsszó, inline eseteben a REFERENCES is elég.
A kényszernek ezúttal sem adtunk nevet.
A külső kulcsot egyszerűbb így, vagyis oszlopkényszerként megadni.
Előfordulhat még csak táblanévre mutató oszlopkényszer.
Ez azt jelenti, hogy elég lett volna csak a hivatkozott tábla nevét megadni. Ekkor a rendszer magától a tábla elsődleges kulcsát fogja venni idegen kulcsnak.
UNIQUE key
Ugyanaz történt, mint az előbb, csak most táblaszinten adtam meg a kényszert. A szintaktika nagyon hasonló az előző példához, de lényeges különbség, hogy out-of-line esetben a UNIQUE szó után meg még adni a vonatkozó oszlop nevét.
Szeretnénk a rendszám oszlopot is egyedivé tenni.
Mivel a rendszám az autók egyedi azonosítója, ezért azt szeretnénk, hogy a rendszer ne engedjen bevinni azonos rendszámokat.
A kényszert oszlopszinten definiáltuk és rendszam_egyedi-nek neveztük el.
PRIMARY KEY
Állítsuk be az autok tábla elsődleges kulcsának az autoID-t!
Most az elsődleges kulcs kényszert a tábladefiníció részeként out-of-line adtam meg. A constarintet autok_autoID_pk-nak neveztem el.
Ebben az esetben érdemes lett volna inkább oszlopkényszerként megadni.
Állítsuk be az autok tábla elsődleges kulcsának az autoID-t! Számozódjon automatikusan ha mást nem adunk meg neki!
Az autok tábla elődleges kulcsát az autoID-re állítottuk be és az oszlopdefiníció részeként hoztuk létre. Mivel nem adtunk neki nevet, ezért a rendszer automatikusan nevezi el.
A CHECK feltétel a tábla egy-egy sorára vonatkozik és minden sorra külön-külön igaz. A NOT NULL tekinthető a CHECK speciális esetének.
CHECK típusú kényszer esetében a Check Condition mezőt kell kitölteni. Ide egy logikai kifejezést adhatunk meg, hasonlóan mint a lekérdezések WHERE clause-ban. A rendszer rekordok felvételénél és módosításánál ellenőrzi, hogy ez a feltétel igaz-e, és ha nem, a kényszer sérül, a végrehajtást a rendszer megtagadja.
Forrás:
Ebben a példában azt szeretnénk, hogy csak 100 és 600 lóerő teljesítményű autót lehessen felvinni az adatbázisba.
Ez teljesen ugyanazt jelenti, mint amikor inline adtuk meg.
Ezúttal nevet is adtunk a kényszernek (loero_korlat)
Ebben az esetben logikusabb lett volna inkább oszlopkényszerként megadni.
Ebben a példában azt szeretnénk, hogy csak 100 és 600 lóerő teljesítményű autót lehessen felvinni az adatbázisba. A luxus autókat csak a felső vezetés használhatja, ezért ezt is tároljuk. Csak I illetve N betűket lehessen írni ebbe az oszlopba!
A kényszernek nem adtam nevet, ilyenkor a CONSTRAINT szót nem írjuk ki.
A CHECK feltételekben szereplő logikai kifejezéseknek minden sorra igaznak kell lenni. Az adatbáziskezelő-rendszer ennek megfelelő adatot enged bevinni:
A NOT NULL kényszer a tábla egy oszlopára vonatkozó szabály, amely nem engedi, hogy az oszlopban NULL érték tárolódjon.
Alapszintaxis:
expression IS NOT NULL
A példában azt szeretnénk, hogy adatbevitelkor az autók nevét és típusát kötelező legyen megadni.
Kényszereket megadhatunk névvel és név nélkül.
