Nézetek, szereplők és tranzakciók

Egy többfelhasználós adatbázisban nem mindenkinek ugyanaz az információ kell. Egy műhelyfoglalkozásra jelentkező tanuló a címet, kezdési időt és szabad helyeket szeretné látni. A szervező ezenfelül a kapacitást, felelős elérhetőségét és belső költséget is kezeli. Az adatokat nem szükséges két egymástól független táblában megismételni: ugyanahhoz a logikai adathoz különböző nézetek rendelhetők.

A nézet kapcsolatot teremt a külső felhasználói kép és a teljes logikai séma között. A tervezésben ez egy felhasználói részséma, a megvalósításban például egy SQL CREATE VIEW utasítással létrehozott objektum. A nézet által biztosított információt az alaptáblák adataiból kell következetesen levezetni, nem kézzel fenntartott másolatból.

A hagyományos nézetnek van tárolt definíciója és egyéb metaadata, ezért nem teljesen hely nélküli objektum. Általában azonban nem tárolja önállóan az eredmény rekordjait. A materializált nézet eltérő fogalom: az eredmény fizikai tárolását és frissítését is kezelni kell. A további példák hagyományos nézetekről szólnak.

Egy nézet eredménye attól is függ, melyik tranzakciós pillanatképet látja a lekérdezés. Az „az alaptábla megváltozott, ezért a nézet is megváltozik” elv nem azt jelenti, hogy minden kapcsolat minden pillanatban ugyanazt a legújabb, még nem véglegesített állapotot olvassa. Az izoláció szabályai a nézet lekérdezésére is érvényesek.

A tanulói nézet a MUHELY tábla cím, kezdés és szabad_hely oszlopát mutatja. Az azonosító megtartható technikai célra, például jelentkezési hivatkozás létrehozásához. A belso_koltseg és felelos_email nem tartozik a tanulói információhoz. Ez az oszlopok kiválasztásának, relációs megfogalmazásban projekciónak egy példája.

A WHERE allapot = 'publikus' feltétel a tervezett, még nem közzétett foglalkozásokat kizárja. Ez sorszűrés. Az oszlop- és sorszűrés egymástól független döntés: az oszlopok elhagyása nem rejti el automatikusan a tervezet sorát, és a sor kiszűrése sem rejti el a többi sor belső költségét.

A nézet további lekérdezések FROM részében használható. A nézet neve mögött álló definíció egységesíti az ismétlődő szűrést, így az alkalmazás több pontja ugyanazt a szabályt használhatja. A SELECT nem garantál eredménysorrendet ORDER BY nélkül; a megjelenítési sorrendet a használó lekérdezésben is megadjuk.

Az explicit oszloplista jobban követhető, mint a SELECT *. Ha később az alaptáblát új belső attribútummal bővítjük, meg kell vizsgálni a nézetdefiníciót és a jogosultságokat. Összekapcsolást vagy összesítést tartalmazó nézet is készíthető, de ezek módosíthatósága már külön kérdés.

CREATE VIEW tanuloi_muhely AS
SELECT muhely_id, cim, kezdes, szabad_hely
FROM MUHELY
WHERE allapot = 'publikus';

SELECT cim, kezdes, szabad_hely
FROM tanuloi_muhely
ORDER BY kezdes, muhely_id;

A nézet önmagában nem akadályozza meg az alaptábla közvetlen elérését. Ha a tanulói szerepkör SELECT joggal rendelkezik a teljes MUHELY táblára, a nézetből elhagyott költséget is lekérdezheti az alaptáblából. Korlátozott hozzáféréshez a teljes jogosultsági láncot kell vizsgálni, nem csupán a tanulói képernyőt.

A felhasználókhoz szerepkörök rendelhetők, például tanulo, szervezo és adatbazis_admin. A szerepkörhöz kapcsolt jogosultságok megkönnyítik az egységes kezelést. A szükséges legkisebb jogosultság elve szerint a tanuló nem kap szervezői módosítási jogot, a szervező pedig nem feltétlenül kap jogot a teljes séma törlésére.

A nézet mögötti jogosultságok ellenőrzése adatbázis-kezelőtől és a nézet beállításaitól függ. Egyes megoldásokban a tulajdonos jogosultságával elérhető az alaptábla, más beállítás a használó jogosultságait követeli meg. A tényleges védelmet ezért próbafelhasználóval teszteljük. Sorbiztonsági szabályok és más védelmi eszközök is részt vehetnek a megoldásban.

Nem minden nézet írható. Egyszerű, egy alaptáblára épülő nézet sok rendszerben módosítható, összesítést vagy összetett kapcsolást tartalmazó nézet nem feltétlenül. Az írhatóság sem azonos az engedélyezettséggel: technikailag írható nézeten is kell módosítási jog. A tanulói nézetet ebben a példában csak olvasásra használjuk.

Az adatbázis-felügyelő, gyakran DBA, az erőforrások, hozzáférési jogosultságok és működési feltételek felügyeletével foglalkozik. Idetartozhat a mentési és helyreállítási eljárás, a teljesítményfigyelés és az üzemeltetési beállítások kezelése. A felügyelő nem feltétlenül maga találja ki az összes üzleti szabályt; ezeket a tervezőkkel és felhasználókkal egyezteti.

Az adatbázis-tervező összegyűjti a különböző csoportok információigényeit, kialakítja a fogalmi és logikai sémát, a kapcsolatokat és megszorításokat. A nézetek kialakításával a részsé­mákat a teljes rendszerhez kapcsolja. A fizikai hozzáférési döntésekben a felügyelővel és az alkalmazás fejlesztőivel is együttműködhet.

A végfelhasználók jelentős része előkészített műveleteket hajt végre: a szervező egy űrlapon létrehoz foglalkozást, a tanuló jelentkezik. Ehhez nem kell SQL-t írniuk. Más használók önálló elemzéseket, ad hoc lekérdezéseket és jelentéseket készítenek. Az eltérő tudásszint nem értékítélet: különböző feladatokat és hozzáférési igényeket jelent.

Ugyanaz a személy kisebb szervezetben több szerepet is betölthet, de a felelősségek akkor is különböznek. Egy tanári tartalomfeltöltő felület használója nem automatikusan adatbázis-felügyelő. A szerepek és jogok elkülönítése segít, hogy egy tartalmi hiba ne váljon a teljes rendszert érintő adminisztrációs hibává.

Az adatbázis-kezelő rendszer tervezői és fejlesztői a DBMS komponenseit készítik. Ilyen komponens lehet a lekérdezésfeldolgozó, optimalizáló, tároláskezelő és tranzakciókezelő. Ők azt a szoftvert fejlesztik, amelyre az adott iskola vagy vállalkozás adatbázisa épül, nem elsősorban az iskola tábláit definiálják.

Az eszközfejlesztők adatmodellező, adatbetöltő, tesztadat-előállító, migrációs vagy teljesítményelemző segédprogramokat készítenek. Egy diagramot rajzoló eszköz megkönnyítheti a tervezést, de a fogalmi modell szakmai helyességét önmagában nem garantálja. A tesztadat-generáló eszköznek a kulcsokra és megszorításokra is figyelnie kell.

Az operátorok és karbantartók biztosítják a napi működés infrastruktúráját: például a felügyeleti jelzések kezelését, rendszeres feladatok végrehajtását és a tárhely működési feltételeit. A feladatok szervezetenként eltérő neveken jelenhetnek meg. A felhőszolgáltatás bizonyos technikai feladatokat átvállalhat, de az üzleti séma, hozzáférési igény és helyreállítási követelmény attól még a használó szervezet kérdése.

Az alkalmazásfejlesztő további fontos összekötő szerep: az űrlapot, lekérdezési hívást és tranzakcióhatárokat az adatbázis szabályaival együtt tervezi meg. Egy képernyő működése nem igazolja automatikusan a többfelhasználós működés helyességét. Az egységes eljáráshoz a szereplőknek a hibakezelést és ütközéseket is egyeztetniük kell.

Egy jelentkezésnél nem elég csökkenteni a szabad helyet: a jelentkező rekordját is rögzíteni kell. Ha az első lépés megtörténik, a második pedig hibát jelez, a két adat ellentmondhat egymásnak. A tranzakció határainak kijelölése azt fejezi ki, hogy ezek a módosítások egy üzleti művelethez tartoznak.

A műveletsor elindul, ellenőrzi a feltételeket, módosítja az adatokat, majd siker esetén COMMIT zárja. Hiba vagy elutasított üzleti feltétel esetén ROLLBACK visszavonja a tranzakció módosításait. Az alkalmazásnak a sikertelen műveletre valóban visszavonási vagy megszakítási úton kell válaszolnia; a BEGIN leírása önmagában nem helyettesíti a hibakezelést.

Négy klasszikus tulajdonság az ACID: atomicitás, konzisztencia, izoláció és tartósság. Az atomicitás a teljes vagy semmi jelleg. A konzisztencia azt jelenti, hogy az érvényes állapotból az üzleti és adatbázis-szabályok szerinti érvényes állapotba jutunk; ehhez a helyes program és megszorítások is szükségesek. Az izoláció az egymás mellett végzett műveletek megfigyelhető kapcsolatát szabályozza. A tartósság a sikeresen véglegesített változások megőrzését jelenti a rendszer garanciái szerint.

A tranzakció nem mindig egyetlen SQL utasítás, és nem mindig egyezik egyetlen felhasználói kattintással. Egyetlen kattintás több adatbázis-műveletet és külső tevékenységet is indíthat. Az e-mail elküldése például nem válik automatikusan visszavonhatóvá attól, hogy az adatbázisban ROLLBACK történt. Az ilyen külső hatásokat külön, összehangolt eljárás szerint kezeljük.

Új mintapéldánkban két eszközraktár között hét készletelemet vezetünk át. Az A raktárban 20, B-ben 5 darab van. Sikeres átvezetés után A=13 és B=12, az összes darabszám továbbra is 25. Ha A csökkentése után B módosítása nem sikerül, A=13 és B=5 hibás, hiányzó készletet mutató állapot lenne.

Az alábbi pszeudokód nem egy konkrét SQL nyelvjárás futtatható tárolt eljárása. A vezérlési logikát mutatja: ellenőrizzük a mennyiséget és a két raktár létezését, megfelelően védjük a módosított sorokat, ellenőrizzük a forráskészletet, majd mindkét oldalt módosítjuk. Siker csak a COMMIT után jelenthető. Az alkalmazás és az adatbázis-kezelő hibakezelési együttműködése nélkül a pszeudokód nem teljes implementáció.

Az üzleti hiba például a nem létező raktár vagy az elégtelen készlet. Technikai hiba lehet kapcsolatvesztés, lemezhiba vagy ütközés miatti tranzakciómegszakítás. Az alkalmazásnak meg kell különböztetnie az elutasítást a bizonytalan kimeneteltől: ha a kapcsolat éppen a COMMIT válasza előtt szakad meg, nem feltétlenül tudjuk, sikerült-e a véglegesítés. Az újrapróbálkozáshoz azonosítható művelet és ellenőrzés szükséges, hogy ne vezessük át kétszer a készletet.

A ROLLBACK a saját tranzakció módosításait vonja vissza, nem az egész adatbázist állítja egy globális múltbeli pillanatra. Más felhasználó szabályosan véglegesített, független változásait nem töröljük el. Már sikeresen véglegesített üzleti művelet helyesbítéséhez általában új, kompenzáló tranzakciót indítunk; egy újonnan kiadott ROLLBACK nem időgép.

tranzakció indítása
ha mennyiség ≤ 0: visszavonás, elutasítás
forrás és cél szükséges sorainak védett elérése
ha forrás vagy cél hiányzik: visszavonás, elutasítás
ha forráskészlet < mennyiség: visszavonás, elutasítás
forráskészlet csökkentése
célkészlet növelése
ha bármely lépés hibás: ROLLBACK, hibajelzés
különben: COMMIT, sikerjelzés

Az adatbázisnak egy hiba után is el kell tudnia különíteni a sikeresen véglegesített és megszakadt műveleteket. A napló ezért tranzakcióazonosítókat, módosítási információkat és lezárási állapotokat rögzíthet. A konkrét rekordformátum adatbázis-kezelőnként eltér; az alábbi táblázat csak az elv megértésére szolgál.

Egy szemléltető napló tartalmazhatja a tranzakció azonosítóját, az érintett adatot és régi/új értéket. A valós rendszerek alkalmazhatnak fizikai vagy logikai naplórekordokat, több verziót és különböző visszaállítási eljárásokat. Nem helyes azt állítani, hogy minden rendszer szó szerint azonos régi/új értékű rekordot ír minden olvasásról.

A write-ahead logging elve szerint a helyreállításhoz szükséges naplóinformációt megfelelően tartóssá kell tenni a módosított adatlap tartós kiírása előtt. Ez lehetővé teszi, hogy az adatlapok kiírását és a tranzakció sikerének rögzítését összehangolt módon kezeljük. A pontos véglegesítési garanciát a rendszer és beállításai határozzák meg.

A tranzakciós napló nem helyettesíti a teljes mentési és helyreállítási tervet. Lehet szükség alapmentésre, naplóarchívumra és tényleges visszaállítási próbára is. A COMMIT, a naplózás és a mentés három kapcsolódó, de eltérő célú fogalom: üzleti lezárás, helyreállítási információ, illetve visszaállítható másolat és eljárás.

A Robotépítés foglalkozáson 18 szabad hely van. T1 négy, T2 hat helyet foglalna. Ha mindkét művelet 18-at olvas, T1 helyileg 14-et, T2 helyileg 12-t számol. Mindkét kivonás önmagában helyes. A teljes műveletsor viszont csak akkor helyes, ha a két foglalás után 18−4−6=8 hely marad.

Hibás egymásba fűzésben T1 beírja a 14-et, majd T2 a régi 18-ból számolt 12-t írja a közös adat helyére. A végső érték 12, így T1 négyhelyes foglalása elveszik a szabadhely-számításból. Ha két jelentkezési rekord közben ténylegesen létrejött, a foglalások és a szabad helyek már ellentmondanak egymásnak.

A jelenség nem csak valódi egyidejű processzorvégrehajtásnál fordulhat elő. Egyetlen processzor is felváltva hajthatja végre a két program részlépéseit. Ez a lépések egymásba fűzése. Az ütemezés azt írja le, milyen sorrendben szerepelnek a különböző tranzakciók olvasásai és írásai.

Az alábbi szemléltetés szándékosan a régi értékből számoló, külön olvasás–számolás–felülírás mintát mutatja. Nem azt állítja, hogy minden adatbázis-kezelő minden UPDATE-je így működik. A szabad_hely = szabad_hely − mennyiseg alakú, megfelelően ellenőrzött atomi adatbázis-módosítás és a konkurenciakezelés más viselkedést adhat. A konkrét megoldásnál a rendszer ütközési és izolációs szabályai számítanak.

A legegyszerűbb helyes megoldásban T1 elvégzi a teljes négyhelyes foglalást és véglegesít. T2 ezt követően már 14-et olvas, abból hatot levon és 8-at ír be. A fordított soros sorrend ugyanerre a készleteredményre vezet: előbb 12, aztán 8. A soros futtatás fogalmilag egyszerű, de minden tranzakció teljes elkülönítése szükségtelenül csökkentheti a rendszer áteresztőképességét.

A cél általában nem minden felhasználó leállítása, hanem az egymással konfliktusban álló műveletek megfelelő összehangolása. Sorzárolásnál a módosítani kívánt rekordot a tranzakció védheti; egy másik módosító várhat, majd az aktuális állapotból folytat. A zárolás pontos hatása és időtartama rendszerfüggő, és egy közönséges SELECT nem minden rendszerben ugyanazt a zárat veszi fel, mint egy védett módosító olvasás.

Optimista megoldásnál verziószámmal ellenőrizhetjük, hogy az olvasás óta változott-e a rekord. A módosítás például csak a korábban látott verzió mellett hajtható végre; nulla módosított sor ütközést jelezhet. Ekkor nem írunk vakon a régi állapotból, hanem a teljes üzleti műveletet megfelelően újraértékeljük. Sorosítható izolációnál a rendszer is elutasíthat konfliktusos tranzakciót, amelyet az alkalmazásnak szükség szerint újra kell futtatnia.

Az alábbi SQL-minta fogalmi megoldásként egyetlen feltételes UPDATE-ben csökkenti a helyet. Az alkalmazásnak ellenőriznie kell a módosított sorok számát: ha nem pontosan egy, a foglalás elutasítandó. A jelentkezési rekord létrehozása ugyanahhoz a tranzakcióhoz tartozik. Az izoláció, megszorítások és motor tranzakciós képessége együtt biztosítják a tényleges működést; egy helyesnek látszó kódsor nem helyettesíti a többkapcsolatos tesztet.

BEGIN;

UPDATE MUHELY
SET szabad_hely = szabad_hely - 4
WHERE muhely_id = 101
  AND szabad_hely >= 4;

-- Alkalmazás: pontosan 1 módosított sor?
-- Ha nem: ROLLBACK és elutasítás.
-- Ha igen: jelentkezési rekord rögzítése.
-- Ha az is sikeres: COMMIT.
-- Bármely hiba esetén: ROLLBACK.