Kényszerek

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. névvel: A rendszám oszlop kényszerének adtam nevet. Érdemes nevet adni a kényszernek, mert így a hibaüzenetből rögtön tudjuk mit szegtünk meg. pl.: rendszam_kotelezonév nélkül: A típus oszlop kényszerének nem adtam nevet. A rendszer ilyenkor automatikusan generál a kényszernek nevet. A hibaüzenetből ilyenkor nem derül ki egyértelműen mit szegtünk meg. pl.: SYS_C0001

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:előadáshttps://www.db.bme.hu/sites/default/files/kenyszerek.pdf

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 teljesítmény oszlopba 100 és 600 közötti számota luxus oszlopba I és N betűket

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.

PRIMARY KEYnem sorokra, hanem a tábla minden értékére együttesen vonatkozikcsak egy lehet belőlelehet egyoszlopos vagy többoszloposa táblában nem lehet két olyan sor, aminek azonos az elsődleges kulcsaelsődleges kulcs oszlopban nem lehet NULL érték (Oracle esetében)

Á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.

Á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.

UNIQUE keya tábla azon kulcsa, amely nem elsődleges kulcstetszőleges számú lehet a táblában (az is lehet hogy nincs)Oracle-szabvány szerint lehet NULL (a PRIMARY KEY-vel ellentétben)A NULL értékkel nem szegjük meg az egyediséget, mert a NULL ismeretlen érték.szintaxisa a PRIMARY KEY-hez nagyon hasonló

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.

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.

FOREIGN KEYA 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

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.

A feladat ugyanaz mint az előbb, csak most táblakényszerként adtuk meg az idegen kulcsot.

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.

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 adatmodell logikai struktúra és az azon értelmezett műveletek összessége.

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ért deklaratív, mert a tábla létrehozásakor/módosításakor deklaráljukazért adatintegritási szabály, mert nem engedi, hogy helytelen adat legyen az adatbázisban.

A constraint nem lekérdezés során keletkezik, hanem korábban, az adatmodell megtervezésekor

Kényszer megadása a tábla definiálásakor.

Kényszer hozzáadása egy meglévő táblához.Szintaxisa:alter table  tábla_neveadd constraint  kényszer_neveForrás: http://www.dba-oracle.com/t_alter_table_add_constraint_syntax_example.htm

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é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.

Amikor egy táblát eldobunk, akkor a constraint-jei is eldobódnak.Szintaxisa:drop table táblanév;Forrás:előadáshttps://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_9003.htm

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á

Autós példa: Az autók táblát sikerül eldobni, mer arra semmi se hivatkozik

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

Más rendszerek csak a tranzakció végén ellenőriznek. Itt bevihetünk először detail és csak utána master adatot.

Ellenőrzésük egyszerű, mert a beszúrandó sor értékeit ellenőrzi a rendszer.

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.

Az idegen kulcsok ellenőrzése szintén rendszerfüggő. Valahol ilyenkor is kötelező az index máshol csak ajánlott.

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