A rendszer katalógusa

A műhelyfoglalkozás címét, kezdési időpontját és létszámát az alkalmazás adataként tároljuk. Más természetű állítás, hogy a kezdési időpont mezője időbélyeg típusú, vagy hogy a műhelyazonosító elsődleges kulcs. Az első a szervezett foglalkozásról mond valamit, a második az azt leíró adatszerkezetről. Ezt a különbséget használjuk az adat és a metaadat megkülönböztetésére.

Az adatbázis-kezelőnek nem elég a rekordok tartalmát ismernie: tudnia kell, melyik táblában milyen oszlopok vannak, hogyan értelmezze az értékeket, melyik kulcs azonosít egy sort, és milyen kapcsolatok vagy ellenőrzések érvényesek. Az ehhez szükséges leírásokat a rendszerkatalógusban kezeli. Emiatt az adatbázis önmagáról is hordoz strukturált információt.

A katalógus logikai szinten elképzelhető egy kisebb adatbázisként az adatbázison belül. A benne tárolt leírások között ugyanúgy lehetnek kulcsok és kapcsolatok, mint egy felhasználói adatmodellben. A tényleges megvalósítás azonban rendszerfüggő: egyes információkat rendszertáblák, másokat nézetek vagy belső adatszerkezetek tesznek elérhetővé.

A katalógus nem azonos az összes üzleti adat másolatával, és nem azonos a tranzakciós naplóval sem. A katalógus elsődlegesen azt mondja meg, hogyan épül fel és milyen szabályokkal használható az adatbázis. A napló a műveletek helyreállításához szükséges információkat kezeli; a biztonsági mentés pedig külön helyreállítási célú másolat.

Egy CREATE TABLE utasítás új táblát definiál. A rendszernek rögzítenie kell a táblanévhez tartozó oszlopokat, azok típusát, a kulcsokat és a megadott megszorításokat. Később a SELECT, INSERT vagy UPDATE feldolgozásakor már ezekhez a leírásokhoz fordul: ezek alapján ellenőrzi, létezik-e a hivatkozott objektum, és összeegyeztethető-e a művelet a szerkezettel.

Ha a SELECT cim FROM MUHELY lekérdezést írjuk, a rendszer ellenőrzi a MUHELY tábla és a cim oszlop létezését. Egy hibás nevű oszlopra hivatkozás már a lekérdezés értelmezésénél elutasítható. Az eredmény típusának megállapításához ugyancsak az oszlopok leírásaira van szükség; nem kell minden tárolt értéket megvizsgálni ahhoz, hogy a rendszer tudja az oszlop deklarált típusát.

A megszorításokat ellenőrző részek a kulcsok és hivatkozások leírását használják. A lekérdezés-optimalizáló az elérhető indexek és egyéb tervezési információk alapján mérlegelhet végrehajtási lehetőségeket. Az index létezése még nem jelenti, hogy minden lekérdezés használni fogja: a döntés a feltételektől, a becsült költségektől és a rendszer működésétől is függ.

A felhasználó számára egy grafikus adatbázis-kezelő gyakran éppen a katalógus lekérdezésével állítja elő a táblalistát, a mezők listáját vagy a kapcsolati nézetet. A fejlesztő dokumentáció készítéséhez, a rendszergazda jogosultságok ellenőrzéséhez, a tervező pedig a megvalósult modell összevetéséhez használhatja ezeket az adatokat.

Egy iskolai műhelyprogramban nyilvántartjuk a foglalkozásokat, a helyszíneket és az oktatókat. Minden műhelyhez pontosan egy helyszín és pontosan egy felelős oktató tartozik. Egy helyszín több műhelynek is otthont adhat, és egy oktató több műhelyért is felelhet. Olyan helyszín vagy oktató is szerepelhet a nyilvántartásban, amelyhez még nem rendeltünk műhelyt.

A MUHELY tábla hat oszlopot tartalmaz: muhely_id, cim, helyszin_id, oktato_id, kezdes és max_letszam. A HELYSZIN három oszlopa helyszin_id, nev és ferohely. Az OKTATO három oszlopa oktato_id, nev és email. A táblák azonosítói egész számok; a nevek és címek szövegek, a kezdés időbélyeg. A két MUHELY-beli hivatkozó oszlop kötelező.

A nev attribútum két külön táblában is megjelenik. Ez nem névütközés a modellen belül: HELYSZIN.nev és OKTATO.nev két külön oszlop. Ugyanígy a helyszin_id név egyszer azonosító, máskor hivatkozó mező. A katalógusnak ezért az oszlopot a táblájával együtt kell azonosítania; az oszlopnév önmagában nem elég.

A példában azonosítók alapján hivatkozunk, a címekre és nevekre pedig külön indexet is tervezünk. Ezek az indexek nem teszik kötelezően egyedivé a címet vagy a nevet. Két oktatónak lehet azonos neve, két műhelynek pedig azonos címe. A logikai kulcsot az azonosító adja, az index a keresést segíti.

A következő hat táblát oktatási célú, egyszerűsített katalógusként használjuk. A RELACIO a táblákat, az ATTRIBUTUM a táblák oszlopait, a KULCS a kulcsokat, az IDEGEN_KULCS a hivatkozási célokat, az INDEX az indexeket, az INDEX_TAG pedig az indexekben részt vevő oszlopokat írja le. Ezek nem egy konkrét adatbázis-kezelő belső rendszertábláinak nevei.

A felhasználói tábla a katalógusban egy leíró sorral jelenik meg. A MUHELY hat oszlopa hat ATTRIBUTUM-sorhoz vezet. Ha ugyanarra a táblára több indexet hozunk létre, több INDEX-sor lesz. Az egyes szerkezetek külön tárolása segít elkerülni, hogy egyetlen sorba változó hosszúságú oszlop- vagy indexlistákat zsúfoljunk.

Az egyszerűség kedvéért egyetlen névtérben dolgozunk, és az indexneveket ebben egyedinek tekintjük. Valós rendszerekben az adatbázis, a séma vagy egy belső objektumazonosító is része lehet az azonosításnak. Ezért a táblanév egyedisége nem minden helyzetben feltételezhető az egész kiszolgálóra kiterjedően.

A modell a példa egyoszlopos elsődleges és idegen kulcsaira épül. A kulcsjel mezőben 1 jelöli az elsődleges kulcs oszlopát, 0 a kulcshoz nem tartozó oszlopot, −1 és −2 pedig a két idegen kulcs oszlopát. Ez helyi tanítási jelölés, nem SQL-szabvány. Több kulcsban részt vevő oszlopok és összetett hivatkozások általános kezeléséhez külön kulcstagsági relációra lenne szükség.

A RELACIO táblában a három alkalmazástáblához három sor tartozik. A név mellett feltüntetjük az oszlopok számát: a HELYSZIN és az OKTATO esetében 3, a MUHELY esetében 6. Ez nem a rekordok száma. Egy hat oszlopos táblának nulla vagy sok ezer sora is lehet, miközben az oszlopok száma változatlan marad.

Az ATTRIBUTUM táblában a három tábla összesen tizenkét oszlopáról tárolunk egy-egy sort. A táblanév és az attribútumnév együtt azonosítja a leírást. Az összetett kulcs magyarázata kézzelfogható: a nev oszlop két helyen szerepel, de a HELYSZIN–nev és OKTATO–nev pár egyértelműen különbözik.

Az adattípus nem egy aktuális rekordból kikövetkeztetett tulajdonság, hanem a szerkezetben deklarált előírás. A VARCHAR(80) szöveges mezőt jelöl, a TIMESTAMP időpontot. A példában külön oszlopban jelezzük a kötelezőséget is. A típus önmagában nem mondja meg, lehet-e hiányzó érték, és nem helyettesíti az olyan üzleti szabályt, hogy a maximális létszámnak pozitívnak kell lennie.

Az oszlopszám ellenőrizhető az ATTRIBUTUM sorainak táblánkénti megszámlálásával. Ilyen ellenőrzéskor a katalógus belső összhangját vizsgáljuk. Egy teljes katalógus a sorrendet, az alapértelmezett értéket, további megszorításokat és más oszloptulajdonságokat is tárolhatja; a bemutatott részlet ezeknek csak egy áttekinthető kivonata.

A KULCS táblában külön sor szerepel mindhárom elsődleges kulcshoz és a MUHELY két idegen kulcsához. Az azonosításhoz a reláció neve és a helyi kulcsjel együtt szükséges. A HELYSZIN,1 és az OKTATO,1 nem azonos kulcs: a kód ugyanaz, a tábla különbözik. A kulcstípus leírja a szerepet, az ATTRIBUTUM-sorok pedig megmutatják a példában részt vevő oszlopot.

A hivatkozás célját nem szabad pusztán az azonos nevű oszlopokból kitalálni. A MUHELY.helyszin_id azért utal a HELYSZIN.helyszin_id mezőre, mert ezt a definíció előírja. Más nevű oszlopok között is lehet idegen kulcs, azonos nevű oszlopok között pedig nem feltétlenül van kapcsolat. A katalógusban ezért a célrelációt és a célattribútumot kifejezetten megadjuk.

Az IDEGEN_KULCS két sora a MUHELY,−1 és MUHELY,−2 helyi kulcsazonosítókhoz tartozik. Az első a helyszínek, a második az oktatók elsődleges kulcsára hivatkozik. A hivatkozott oszlop leírásának létezése önmagában még nem elég: az adatmodellben annak megfelelő egyediségét is biztosítani kell. A példában ezt mindkét céloldali elsődleges kulcs teljesíti.

A kötelező hivatkozó mező és az idegen kulcs együtt azt jelenti, hogy minden MUHELY sorhoz meg kell adni egy létező helyszínt és egy létező oktatót. A céloldalon azonban nem következik, hogy minden helyszínhez vagy oktatóhoz már tartozik műhely. Az egy-több kapcsolat minimumai ezért eltérnek: a műhely oldalán egy, a helyszín és az oktató oldalán nulla vagy több kapcsolódó műhely lehet.

A kulcs logikai előírás, az index hozzáférési szerkezet. A példában a három elsődleges kulcsot támogató indexek mellett a MUHELY.cim, MUHELY.helyszin_id és OKTATO.nev oszlopokon szerepel külön keresési index. A cím- és névindex nem egyedi: ismétlődő értékek is lehetnek bennük. A logikai kulcs és a fizikai megvalósítás szerepét akkor is külön kell megérteni, ha a rendszer ezek között kapcsolatot tart fenn.

Az INDEX tábla megadja az index nevét, a hozzá tartozó táblát és a példában betöltött szerepét. A támogatási szerep elnevezése nem állítás a tárolt rekordok fizikai sorrendjéről. Az elsődleges kulcsot támogató index nem minden rendszerben jelenti azt, hogy a tábla teljes adatterülete az adott kulcs szerint fizikailag rendezett.

Az INDEX_TAG táblában külön sor jelöli az index minden oszlopát és annak pozícióját. A jelenlegi hat index mind egyoszlopos, ezért mindegyiknél 1 a pozíció. Egy későbbi, (helyszin_id, kezdes) összetett indexhez két tagsági sor kellene: az első pozícióban helyszin_id, a másodikban kezdes. A sorrend érdemi információ, nem felcserélhető felsorolás.

A külön tagsági tábla előnye, hogy egy oszlop nulla, egy vagy több indexben is szerepelhet. A MUHELY.oktato_id például idegen kulcs, de itt nincs rajta külön index. Az, hogy egy oszlop nincs indexelve, nem teszi érvénytelenné a hivatkozását. Az indexelés megválasztása az ellenőrzési és keresési költségeket befolyásolhatja, de nem pótolja az idegen kulcs deklarációját.

Először a RELACIO sorokból összeírjuk a táblákat. Ezután táblánként kiválogatjuk az ATTRIBUTUM sorokat, és felsoroljuk a mezőket a típusukkal és kötelezőségükkel együtt. Már ezen a ponton ellenőrizhető, hogy a felismert oszlopok száma egyezik-e a RELACIO oszlopszám mezőjével. A MUHELY-nél hat, a másik két táblánál három oszlopot kell kapnunk.

A KULCS és az ATTRIBUTUM leírásából megjelöljük az elsődleges kulcsokat. Az IDEGEN_KULCS sorait ezután felhasználjuk a hivatkozási élek felrajzolásához. A cél megállapításakor együtt vizsgáljuk a helyi kulcsazonosítót, a hivatkozó oszlopot, a célrelációt és a célattribútumot. E lépésekkel megkapjuk a megvalósított relációs séma alapvető szerkezetét.

Az indexeket külön rétegként tüntetjük fel. Az indexjelzés hasznos a megvalósítás áttekintéséhez, de egy tisztán fogalmi ER-modellben általában nem a hozzáférési szerkezeteket ábrázoljuk. A visszaállított séma tehát segíthet egy ER-ábra készítésében, de az eredeti fogalmi modell és az üzleti követelmények minden részlete nem vezethető le automatikusan a táblákból.

A kapcsolatokból például megállapítható a műhely kötelező helyszíne és oktatója. Nem derül ki viszont ebből a kivonatból, engedélyezett-e két műhely időbeli átfedése azonos helyszínen, vagy hogy a max_letszam nem haladhatja-e meg a helyszín férőhelyét. Ezek külön üzleti szabályok, amelyekhez további megszorítás, alkalmazáslogika vagy dokumentáció kell.

Többfelhasználós rendszerben nem elég a táblákat és oszlopokat nyilvántartani: azt is ismerni kell, ki és milyen műveleteket végezhet rajtuk. A tulajdonos, a szerepkörök és az objektumszintű engedélyek ugyancsak metaadatok. A tanulói szerepkör például olvashat egy nyilvános műhelynézetet, az ügyintéző pedig a megfelelő táblában módosíthatja a foglalkozások adatait.

A tábla tulajdonosa és a rajta olvasási jogot kapó felhasználó nem azonos fogalom. Az engedélyezett műveletet is külön kell megadni: a SELECT jogból nem következik UPDATE vagy DELETE jog. A konkrét jogosultságvizsgálat szerepköröktől, örökléstől, nézetektől és rendszerfüggő szabályoktól is függhet; egy egyszerű jogosultságlista ezeknek csak részlete.

Elosztott adatbázisban az adatok több helyen lehetnek elérhetők. A rendszernek ismernie kell a részek vagy másolatok elhelyezését, és a szükséges működési információkat. Elképzelhető például, hogy a műhelyek egy része a szombathelyi, másik része a körmendi intézményhez tartozik, a központi jelentéskészítés pedig mindkét hely adatait használja.

Az elhelyezési leírás nem garantálja önmagában a másolatok naprakészségét. A konzisztencia biztosításához megfelelő működési protokollok és ellenőrzések is szükségesek. A katalógus a rendszer döntéseihez szükséges leírásokat adja; a tényleges szinkronizálást az adatbázis-kezelő és a kapcsolódó szolgáltatások végzik.

A rendszerkatalógus adatainak szabályos változtatását az adatbázis-kezelő által támogatott utasításokkal végezzük. Egy tábla vagy index létrehozásakor a rendszer a hozzá tartozó metaadatokat is kezeli. A belső rendszertáblák kézi átírását nem használjuk a tanulási példában: az eltérő szerkezeti leírások hibás vagy működésképtelen adatbázishoz vezethetnek.

Egy katalóguskivonat átvizsgálásánál először a hivatkozások célját keressük. Minden ATTRIBUTUM sor létező relációhoz tartozzon; minden INDEX_TAG sor létező indexet és az adott táblához tartozó oszlopot jelöljön. Az idegen kulcs céltáblája és céloszlopa létezzen, és a cél legyen megfelelően egyedi. A megszorítás értelmezéséhez a mezők típusának összeegyeztethetőségét is ellenőrizni kell.

A valódi adatbázis-kezelők egy része szabványosabb metaadatnézeteket is biztosít az INFORMATION_SCHEMA névtérben. Ezek nem feltétlenül tartalmaznak minden rendszerfüggő részletet. Az elérhető oszlopok és a látható objektumok a használt rendszertől, verziótól és jogosultságoktól is függhetnek. A következő SQL szemléltető lekérdezés, nem a fenti oktatási katalógustáblákon fut.

A grafikus sémanézet ugyanúgy metaadatokat jelenít meg, mint egy ilyen lekérdezés. Ha a táblák felrajzolása hiányos, meg kell vizsgálni a lekérdezés szűrését, a hozzáférési jogokat és azt, hogy a nézet milyen objektumtípusokat mutat. Egy üres lista nem minden esetben bizonyítja, hogy az adatbázisban semmilyen objektum nincs.

SELECT table_schema, table_name, column_name,
       data_type, is_nullable, ordinal_position
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'muhely'
ORDER BY ordinal_position;