Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) ABR 2( Adatbázisrendszerek 2) Előadás: Celko Joe tippjei Codd törvényei. Triggerek

Celko Joe programozási tippjei A lekérdezést kezdjük mindíg a SELECT utasítással és írjuk utána, mit szeretnénk látni az eredményben. Ezzel megvan a cél, és a felhasználónak is tudunk mutatni valamit Minden táblát, amelynek oszlopai a SELECT utasítás után szerepelnek, írjuk a FROM után A felesleges táblákat később eltávolíthatjuk. Minden a WHERE záradékban fog zajlani Egyedek helyett fogalmazzuk meg a problémát halmazokkal. Erre a legjobb példa a fák ábrázolása egymásba ágyazott halmazokkal, csúcsok és élek helyett

Celko Joe programozási tippjei Sokszor segít, ha felcseréljük a szavak sorrendjét a kérdésben. Ahelyett, hogy “szükségünk van minden sárga tengeralattjáróra” azt mondjuk, hogy “sárga a színe azon teneralattjáróknak, melyre szükségünk van ”. Néha a kérdés tagadása segít. Ahelyett, hogy “szükségünk van azokra az autókra, melyek teljesítik az összes feltételt”, mondhatjuk azt, hogy “nem kellenek azok az autók, amelyek legalább egy feltételnek nem felelnek meg”. Gyakran egyszerűbb megtalálni azt,amit nem akarunk, mint azt, amit akarunk. Ez a módszer akkor hasznos, amikor a NOT EXIST predikátumot használjuk. De figyelni kell a NULL értékekre és az ÜRES halmazokra

Celko Joe programozási tippjei Egymásba ágyazás segítségével sok mindent elvégezhetünk egyszerre. Különösen hasznos a CASE eszközök használata összesítő függvényekkel. Figyeljünk oda a logikai kifejezésekre. Az eljárásközpontú nyelvekben több lépcsőben is kiszűrhetjük a megfelelő adatokat. Az SQL-ben mindent egy kifejezésben kell leírni, ami nagyon bonyolult is lehet.

Celko Joe programozási tippjei Figyeljünk oda, hogy a NULL értékek az UNKNOW igazságértékeket eredményezzenek. Mindíg ellenőrizzük, hogy mi történik a lekérdezésben, ha valahol NULL fordul elő. Ne felekezzünk meg arról, hogy a táblák üresek is lehetnek. Próbáljunk olyan tesztadatokat létrehozni, amelyek lefedik az összes lehetséges esetet. Ezért jó egy döntési-tábla előkészítő program használata, ami biztosan megállapítja, hogy az adott kifejezés helyes és teljes-e.

Codd 12 szabálya Codd 12 szabálya egy tizenhárom szabályból álló készlet (zérótól tizenketőig számozva), amelyet Edgar F. Codd javasolt, a relációs adatbázis modell atyja, amely arra volt tervezve, hogy meghatározza milyen feltételeket kell teljesítsen egy adatbázis kezelő rendszer azért hogy relációs adatbázis kezelő rendszernek nevezhessék. Tréfásan “Codd tizenkét parancsolata”-nak is nevezik.

Codd ezen szabályok elkészítését arra is használta, hogy megkadályozza az ő adatbázis rendszerekről megalkotott álmainak felhígítását, amint a korai 1980-as adatbázis szállítók összekúszáltak hogy újracsomagolják a létező temékeiket relációs burokkal. A 12-es szabály volt kiváltképpen arra kitalálva hogy számbavegye az ilyen helyezkedéseket. A szabályok annyira szigorúak hogy az összes népszerű, úgynevezett “relációs” adatbázisredszerek elégtelen jegyet kapnak több feltétel esetében.

0. Szabály A rendszer minősítésének tartalmaznia kell mindhárom fogalmat: relációs, adatbázis és menedzsment rendszer. Hogy egy rendszer minősítése adatbázis kezelő rendszer legyen, a rendszer (kizárólag) relációs képességeket kihasználva menedzselnie kell az adatbázist. Kivétel: Használatunk ELJÁRÁSOKAT is

1. Szabály Az információs szabály Minden információ ábrázolása az adatbázisban csak egyféle képpen történik, mégpedig táblák sorai- és oszlopai találkozásánál levő értékekkel. Az SQL megfelel ennek a szabálynak

2. Szabály: A garantált hozzáférés szabálya Minden adat elérhető kell legyen. Ez a szabály alapvető az elsődleges kulcs újrafogalmazásában. Kimondja, hogy minden skalár egység az adatázisban logikailag megcímezhető kell legyen, megcímezvén a bennfoglaló táblát, a tartalmazó oszlop nevét és a tartalmazó sor elsődleges kulcsának az értékét. Nem kötelező, hogy egy táblán legyen bármilyen kulcsa.

3. Szabály: A null érték szisztematikus kezelése Az ABRnek meg kell engednie minden mezőnek, hogy null értékű legyen (vagy üres). Kifejezetten kell támogassa a “hiányzó és alkalmazhatatlan információ”-t, amelyik szisztematikus, külünbözik minden szabályos értéktől (például, “különbözik zérótól és minden más számtól”, szám értékek esetében), és független az adattípustól. Magába kell foglalja azt is, hogy egy ilyen reprezentációt szisztematikusan kell kezelnie az ABR-nek. Az SQL a NULL értéket használja mindkét esetre

4. Szabály: A relációs modellre épülő aktív online katalógus A rendszernek támogatnia kell egy online, közvetlen, relációs katalógust, amely elérhető a jogosult felhasználók számára egy lekérdező nyelv segítségével. A felhasználóknak elérhető kell legyen az adatbázis struktúrája (katalógusa) ugyanazon lekérdező nyelv használata segítségével, mint amivel elérik az adatbázis adatait. Az SQL támogatja ezen katalógus létezését

5. Szabály: Az átfogó nyelv szabálya A rendszernek biztosítania kell legalább egy relációs nyelvet, amelyik Lineáris szintaxissal rendelkezik Használható mind interaktív módon, mind pedig program-alkalmazáson keresztül Támogatja az adat-definíciós operációkat (beleértve a nézet definíciókat), adatmanipulációs operációkat (módosítás és visszakeresés), biztonsági- és integritási megszorításokat, és tranzakció-menedzsmenti operációkat (kezdet, elkövetés (commit) és visszaforgatás (rollback))

6. Szabály: A nézetfrissítési szabály Mindazon a nézetek, amelyek elméletileg frissíthetőek, azok frissíthetőek kell legyenek gyakorlatilag is. Az SQL gyenge ezen a téren, mert a nézettáblák frissítése nagyon nehéz probléma Csak a nagyon biztonságos esetek kerülnek bele

7. Szabály: Magasszintű beszúrás, módosítás és törlés A rendszer kell támogassa a készlet szintű beszúrás-, módosítás- és törlés operátorokat. Ez azt jelenti, hogy adathalmazt lehet visszakeresni egy relációs adatbázisból, amelyik több sort/táblát tartalmaznak. Ez a szabály kimondja, hogy beszúrás, módosítás és törlés operációk alkalmazhatók kell legyenek minden visszakereshető sorhalmazra, mintsem egy sorra egy táblából. Az SQL támogatja ezeket

8. Szabály: Fizikai adatfüggetlenség A fizikai síkon történő változások (hogyan tároljuk az adatokat, mint tömbben vagy csatolt listákban) ne legyen kihatással azon akalmazásokra, amelyek az adatstruktúrán alapulnak. Az SQL jobb a programozási nyelvek többségénél

9. Szabály: Logikai adat-függetlenség A logikai szintű változásoknak (táblák, oszlopok, sorok stb.) nem szabad hatással lennie struktúrán alapuló alkalmazásokra. Logikai adat – függetlenséget nehezebb megvalósítani, mint a fizikai adafüggetlenséget. Az SQL nagyon jó ezen a téren

10. Szabály: Épségi függetlenség Az épségi megszorítások alkalmazás – függetlenek kel legyenek és a katalógus kell tartalmazza őket. Lehetőséget kell biztosítani annak, hogy ezen megszorítások, amikor szükségszerű, változtathatóak legyenek, anélkül, hogy befolyásolná a létező alkalmazásokat.

11. Szabály: Az osztottság függetlensége Az adatbázis egyes részeinek különböző helyeken történő tárolása láthatatlan kell legyen az adatbázis felhasználójának. A létező alkalmazások tovább kell működjenek: Amikor egy osztott változata az ABR-nek első alkalommal bevezetésre kerül Amikor a létező osztott adat újraosztásra kerül a rendszeren belül. Ezen támogatások gyerekcipőben vannak. (NoSQL)

12. Szabály: Az alacsony szintű hozzáférés szabálya Ha a rendszer biztosít egy alacsony szintű kapcsolatot, ez a kapcsolat nem használható a rendszer aláásására, például, hogy áteresszen egy relációs biztonsági résen vagy megsértsen egy integritási megszorítást. Az SQL-92 jó ebből a szempontból

Triggerek (Rancz Tünde) A trigger egy táblára vonatkozó INSERT, UPDATE, DELETE utasítás vagy más aktualizálási művelet (LOGON, LOGOFF, CREATE, ALTER, DROP) végrehajtásának mellékhatásaként automatikusan végrehajtódó tárolt eljárás A felhasználó nem tudja befolyásolni, hogy a trigger működésbe lépjen-e, vagy sem, és így a trigger végrehajtásához EXECUTE jogra sincs szükség. A COMMIT, ROLLBACK és SAVEPOINT utasítások használata triggerekben, és a triggerekből meghívott tárolt eljárásokban tilos. Egy trigger működése más triggereket is elindíthat, sőt rekurzív is lehet. Korlátozzuk a triggert legfeljebb 60 sorra. Ha több műveletre is szükségünk van, helyezzük azokat egy tárolt eljárásba és hívjuk meg a triggerből a tárolt eljárást. Azokat az adatbázisokat, melyekben triggerek is implementálva vannak aktív adatbázisoknak nevezzük. Csak olyan műveletek elvégzésére használjuk, azaz a globális műveletekre, melyek minden felhasználó esetében szükségesek.

a művelet akár megakadályozhatja a kiváltó esemény megtörténtét vagy meg nem történtté teheti azt (pl. kitörölheti az épp felvitt sorokat); a trigger művelet része hivatkozhat a triggert kiváltó parancs által módosított sorok régi és új értékeire, végrehajthat új lekérdezéseket, változtathatja az adatbázist. végrehajthat adatdefiníciós parancsokat (új táblákat hozhat létre, megváltoztathatja a hozzáférési jogokat).

Mire használunk triggereket? Származtatott értékek Érvénytelen tranzakciók kiszűrése Bonyolult biztonsági ellenőrzés Referenciális integritás szerverek között Működési korlátozások biztosítása Naplózás Auditálás Replikáció Statisztika-gyűjtés Triggereket is azért találták ki, hogy az adatbázis konzisztens maradjon.

Triggerek az SQL-ben (Trigger – elsüt, kivált) Eddig az SQL 2 szabvány szerinti megszorításokat tanulmányoztuk. Egy új sor beszúrásánál megváltozhat az attribútum értéke és CHECK feltételt akkor ellenőrizzük amikor ez megtörténik. Ez már az SQL 3-ban van. A megszorítások megvalósítása magába foglalja az ellenőrzések kiváltását, elsütését.

Tiggerek és megszorítások (három különbség van köztük) A triggereket csak akkor ellenőrzi a rendszer ha valamilyen esemény bekövetkezik Először a feltételt vizsgálja meg, ha nem teljesül, semmi sem történik Ha a feltétel teljesül akkor a művelet végrehajtandó, ez a művelet megakadályozhatja a kiváltó esemény létrejöttét.

SQL 3 Triggerek: A művelet végrehajtható a kiváltó esemény előtt, után vagy helyette A művelet vonatkozhat a műveletet kiváltó esemény által törölt, beszúrt vagy módosított sorok régi vagy új értékeire is Ha az esemény modosítás akkor megadhatunk egy oszlopot vagy egy halmazt amelyre az esemény vonatkozik Egy WHEN zárójelben , megadhatunk egy feltételt is ami feltételezi a művelet vegrehajtását

Önálló megszorítások SQL 3-ban Ket bővítése van az SQL-2 hez képest: A programozó által megadott esemény váltja ki Egy sorra is hivatkozhat. Példa: A felhasználó gondoskodik a következőkről Összegyűjti az eseményeket ami a megszorítás ellenőrzését váltja ki. Viseli a kockázatot ha az adatbázis következetlen állapotba kerül.

CREATE TRIGGER NetBevetelTrigger AFTER UPDATE OF nettoBev ON Gyartasiranyito REFERENCING OLD AS RegiSor, NEW AS UjSor WHEN(RegiSor.nettoBev>UjSor.nettoBev) UPDATE Gyartasiranyito SET nettoBev=RegiSor.nettoBev WHERE azonosito=UjSor.azonosito FOR EACH ROW

Trigger szintaxis a MySQL-ben CREATE TABLE szamla (szamlaszam INT PRIMARY KEY, egyenleg DECIMAL(10,2)); CREATE TRIGGER ins_sum BEFORE INSERT ON szamla FOR EACH ROW SET @sum = @sum + NEW.egyenleg; SET @sum=0; INSERT INTO szamla VALUES(137,14.98),(141,1937.50),(97,-100.00); SELECT @sum AS ‘Összesen bevitt egyenleg'; Eredmény 1 oszlop, 1 sor, érték: 1852,48

Triggerek megszorításai (MySQL) A trigger nevek ugyanabban a névtérben léteznek, ami azt jelenti, hogy minden triggernek különböző neve kell legyen egy adatbázis sémán belül. Más – más sémában levő triggereknek lehet ugyanaz a nevük. Nem lehet 2 különböző nevű trigger, amelyik ugyanazon feltételek mellett ugyanazon táblára vonatkozzék, vagyis ugyanaz legyen az aktivációs ideje és ugyanazon esemény váltsa ki.

Create trigger (MySQL) [DEFINER = { user | CURRENT_USER }] TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW trigger_stmt A trigger egy megnevezett adatbázis objektum amelyik egy táblához kapcsolódik és aktiválódik (elsül) amikor egy egyéni esemény történik a táblával. A trigger egy táblához fog kapcsolódni, amelyik neve a tbl_name, és amelyik egy permanens táblát kell jelentsen. Nem lehet a triggert egy nézethez vagy egy IDEIGLENES (TEMPORARY) táblához kötni.

trigger_time megadja, hogy az esemény bekövetkezte Előtt (BEFORE), vagy Után (AFTER) legyen végrehajtva a trigger_stmt trigger_event lehet a következő: INSERT LOAD DATA REPLACE UPDATE DELETE

Többszörös utasítás esetén A trigger_stmt-t BEGIN és END közé kell tenni. CREATE TABLE test1(a1 INT); CREATE TABLE test2(a2 INT); CREATE TABLE test3(a3 INT NOT NULL AUTO_INCREMENT PRIMARY KEY); CREATE TABLE test4( a4 INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b4 INT DEFAULT 0); delimiter | CREATE TRIGGER testref BEFORE INSERT ON test1 FOR EACH ROW BEGIN INSERT INTO test2 SET a2 = NEW.a1; DELETE FROM test3 WHERE a3 = NEW.a1; UPDATE test4 SET b4 = b4 + 1 WHERE a4 = NEW.a1; END;| delimiter ;

INSERT INTO test3 (a3) VALUES (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL); INSERT INTO test4 (a4) VALUES (0), (0), (0), (0), (0), (0), (0), (0), (0), (0); INSERT INTO test1 VALUES (1), (3), (1), (7), (1), (8), (4), (4); Select * from test1 Select * from test2 a1=(1,3,1,7,1,8,4,4) a2=(1,3,1,7,1,8,4,4) Select * from test3 a3=(2,5,6,9,10) Select * from test4 a4=(1,2,3,4,5,6,7,8,9,10) b4=(3,0,1,2,0,0,1,1,0,0) A test3-ból kitörli az test1-ben levő értékeket, a test4-ben megszámolja, hogy melyik érték hányszor szerepel a test1-ben

Vonatkoztathatunk a táblában lévő oszlopokra (a tábla, amelyik a triggerrel van asszociálva), ha használjuk az OLD és a NEW álneveket. OLD.col_name vonatkozik egy létező sorra, mielőtt az módosult vagy törlődött volna.  NEW.col_name vonatkozik arra az oszlopára az új sornak amelyik be lesz szúrva vagy az oszlopára annak a sornak, amelyik már meg volt változtatva. Működő CREATE TRIGGER sdata_insert BEFORE INSERT ON ‘sometable’ FOR EACH ROW BEGIN SET NEW.guid = UUID(); END; Nem működő CREATE TRIGGER sdata_insert AFTER INSERT ON ‘sometable’ FOR EACH ROW BEGIN SET NEW.guid = UUID(); END;

Zölddel írva a számla általános adatait láthatjuk Pirossal a számlasorok attribútumai vannak Kékkel írva láthatóak a számlasorok.

Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Marosvásárhely összeg Ügyfelek számlaszám termékID Számlák számlája sorai darabszám Sorszám ÁFA Számlasorok mértékegység egységár Termékek Dátum terméke név határidő azonosító bank bszámla adószám bejegyzés

KISZAMLA.OSSZEG= , ahol N a számlán levő sorok száma.

INSERT trigger delimiter // CREATE TRIGGER sz_sor_insert AFTER INSERT ON szamlasor FOR EACH ROW BEGIN UPDATE kiszamla SET kiszamla.OSSZEG=kiszamla.OSSZEG+NEW.EGYSEGAR*NEW.MENNYISEG WHERE kiszamla.SZAMLASZAM=NEW.SZAMLASZAM; END;// delimiter ;

DELETE trigger delimiter // CREATE TRIGGER sz_sor_delete BEFORE DELETE ON szamlasor FOR EACH ROW BEGIN UPDATE kiszamla SET kiszamla.OSSZEG=kiszamla.OSSZEG-OLD.EGYSEGAR*OLD.MENNYISEG WHERE kiszamla.SZAMLASZAM=OLD.SZAMLASZAM; END;// delimiter ;

UPDATE trigger delimiter // CREATE TRIGGER sz_sor_update BEFORE UPDATE ON szamlasor FOR EACH ROW BEGIN UPDATE kiszamla SET kiszamla.OSSZEG=kiszamla.OSSZEG+NEW.EGYSEGAR*NEW.MENNYISEG-OLD.EGYSEGAR*OLD.MENNYISEG WHERE kiszamla.SZAMLASZAM=NEW.SZAMLASZAM; END;// delimiter ;

Bibliográfia Celko, Joe; SQL felsőfokon, Kiskapu, Budapest, 2002, xxiii, 19-21 oldal http://en.wikipedia.org/wiki/Codd's_12_rules http://dev.mysql.com/doc/refman/5.1/en/stored-programs-views.html