Alapfogalmak összefoglalása

Kezdjünk egy fontos kérdéssel: miért nem elég minden adatot egyetlen táblázatba írni? A kérdés megmutatja, milyen problémát kell az adatmodellezésnek megoldania. Egy adatbázisnak tényleges adatokat, az adatok típusát és kapcsolatát leíró metaadatokat, valamint az adatok kezelését lehetővé tevő rendszert kell együtt működtetnie.

Alapfogalom

„Miből áll egy adatbázis? Egy adott szakterületet jellemző adatokból, az adatok típusát és kapcsolatát leíró adatokból (metaadatokból) és az adatkezelő rendszerből.”

Egy oktatási portál tananyagai. Minden sorban a tananyag azonosítója, címe, nehézségi szintje, témakörkódja és a témakör neve szerepel. A „Matematika” és az „Adatbázis-kezelés” név több sorban is előfordul. A tananyagok önmagukban érthetők, de egy témakör nevét többször tároljuk.

A portál négy tananyaga egyetlen táblában.

Redundancia és három anomália

Redundancia az itt látható fölösleges ismétlődés: ugyanahhoz a témakör_kód értékhez újra és újra odaírjuk ugyanazt a témakörnevet. A kapcsolódáshoz használt kód több tananyagnál is szerepelhet; a fölöslegesen ismételt név okozza a problémát.

• Bővítési anomália: szeretnénk létrehozni a Szoftvertesztelés témakört, de még nincs hozzá tananyag. Az egyetlen TANANYAG táblában nem tudunk szabályosan témakört felvenni úgy, hogy hiányzik a tananyag azonosítója és címe.
• Törlési anomália: ha a két matematikai tananyagot levesszük a portálról, a sorokkal együtt a ma → Matematika kapcsolat is eltűnik. Pedig a témakört később új tartalommal folytatnánk.
• Módosítási anomália: ha a „Matematika” témakör neve „Matematikai alapok” lesz, két tananyag sorát kell átírni. Ha csak az egyiket változtatjuk meg, ugyanahhoz a kódhoz két név tartozik.

Megoldás: két összekapcsolt táblázat

A TANANYAG táblában megmarad a témakörkód, a hozzá tartozó nevet viszont a TÉMAKÖR tábla csak egyszer tárolja. Így új témakört vehetünk fel tananyag nélkül, eltávolíthatunk egy tananyagot a témakör törlése nélkül, és egy helyen nevezhetjük át a témakört. A látogatónak továbbra is megmutathatjuk a tananyag címét és témakörét együtt: az összekapcsolás (JOIN) a két tábla adataiból állítja elő ezt a nézetet.

Az adatbázis-tervezés hat lépése

1. Az adattárolási és adatfeldolgozási igények összegyűjtése: mit kell rögzíteni és milyen kérdésekre kell válaszolni?
2. Magas szintű, koncepcionális modell és a szükséges lekérdezési sémák kialakítása.
3. Az adatbázis-kezelő rendszer típusának kiválasztása, például relációs rendszeré.
4. A koncepcionális séma alapján alacsony szintű, logikai modell alkotása.
5. A tárolási szerkezetek, hozzáférési módok és tervezhető műveletek megtervezése a választott rendszerhez.
6. A szerkezet és az eljárások megvalósítása a konkrét DBMS-ben, majd az adatok betöltése.

A koncepcionális és a logikai tervezés kiemelten fontos. Előbb megértjük a szakterületet és annak szabályait, aztán döntünk a megvalósításról. Egy kis nyilvántartás is hordozhat olyan összefüggést, amelyet az első táblavázlat nem mutat meg.

Itt választjuk szét a tervet és a megvalósult adatállományt. Az adatmodell leírja, milyen adatok szerepelhetnek, hogyan kapcsolódnak és milyen szabályok érvényesek. Az adatbázisban már tényleges rekordok is vannak. A TANANYAG sorai változhatnak, miközben a modell – tananyagok, témakörök és a köztük lévő témakör_kód kapcsolat – ugyanaz marad.

Alapfogalom

„Az adatmodell olyan koncepciók gyűjteménye, amelyek egy adatbázis szerkezetét egyértelműen leírják. A szerkezet magában foglalja az adatok típusát, azok kapcsolatát és az adatokra vonatkozó korlátozó feltételeket.”

A meghatározás mindhárom részét alkalmazzuk: típus például a tananyag és a témakör, valamint az azonosító számszerű volta; kapcsolat az, hogy egy tananyag egy témakörkódra hivatkozik; korlátozó feltétel, hogy az anyag azonosítója egyedi legyen, a hivatkozott témakörkód pedig létezzen.

Alapfogalom

„Az adatmodell tartalmazza továbbá az adatkezelési alapműveleteket (adatbevitel, módosítás, törlés, lekérdezések) és a felhasználói igényeket kielégítő összetett műveleteket (tranzakciók) is.”

Az adatmodell a műveleteket is számításba veszi. Új lecke közzététele adatbevitel, a cím javítása módosítás, egy elavult lecke archiválása állapotváltoztatás. Több összetartozó lépés – például lecke áthelyezése új témakörbe és a művelet naplózása – tranzakcióként kezelhető.

Alapfogalom

„Mi az adatbázis? Lényegében egy megvalósított adatmodell, amely a valódi adatokon kívül tartalmazza az adatok típusait és kapcsolatait leíró, ún. metaadatokat is.”

Metaadat az adatról szóló adat: a TANANYAG tábla oszlopainak neve és típusa, az anyag_id egyediségét előíró szabály vagy a témakör_kód kapcsolat leírása. A „101” és az „SQL JOIN gyakorlás” már konkrét adat. A metaadatok alapján tudja a rendszer értelmezni és összekapcsolni a sorokat.

DBMS az adatbázis-kezelő rendszer angol rövidítése (Data Base Management System). A DBMS kezeli a tárolást, végrehajtja a lekérdezéseket és a leírt szabályok szerint működteti az adatbázist. Relációs adatbázis-kezelő például az Access és az Oracle; az SQL fontos lekérdező nyelv. A CREATE TABLE és SELECT a két művelettípus szemléltető példái.

Az adatbázis nem azonos a felhasználó előtt megjelenő űrlappal. A rendszer réteges felépítésű: a felhasználó az alkalmazói programmal lép kapcsolatba; az alkalmazás az adatbázis-kezelő rendszert veszi igénybe; a DBMS a tárolt adatok és a metaadatok alapján dolgozik, az operációs rendszer szolgáltatásaira támaszkodva.

Alapfogalom

„Az adatbázis-rendszer külső rétegét a felhasználóval kapcsolatot tartó, alkalmazói program képezi.”

Ha a tanuló az „SQL JOIN” kifejezésre keres, a portál lekérdezést kér a DBMS-től. A metaadatok segítenek értelmezni a cím mezőt és a témakörkapcsolatot; a rendszer a tárolt rekordok között megkeresi a találatokat. A felületnek ehhez nem kell ismernie a fájl fizikai helyét. A lekérdezésfeldolgozó és a tároltadat-kezelő komponens eltérő feladatot lát el.

Az előző ábra egy rendszer működési rétegeit mutatta. Most más kérdésre térünk át: milyen szinten írjuk le ugyanazt az adatbázist? A külső szint a felhasználónak látható rész, a koncepcionális a teljes rendszer közös terve, a belső a fizikai tárolás módja.

Alapfogalom

„Az adatmodell tehát a következő három szintre bontható: 1. külső szintekre, amelyek azt írják le, hogyan látják az egyes felhasználók az adatbázist 2. középső vagy koncepcionális szintre, amely a teljes adatbázis koncepcionális szerkezetét ábrázolja (a külső szintek összefésülésével kapjuk) 3. belső vagy fizikai szintre, amely az adatok fizikai elhelyezését és elérési módjait írja le.”

A koncepcionális leírásból logikai, implementációs modell is készülhet: a magas szintű, szakterületre összpontosító leírásból készülhet például relációs logikai séma. A logikai szint és a fizikai tárolás különválasztása különösen fontos. Nem ugyanaz a kérdés, hogy mely táblákra és kapcsolatokra van szükség, mint az, hogy egy index mely fájlszerkezetet használja.

Logikai és fizikai adatfüggetlenség

Logikai adatfüggetlenség: az alkalmazói programnak nem kell minden adattárolási szerkezeti változás után teljesen átíródnia; a rendszer a metaadatokat és a külső nézetekhez vezető leképzéseket használja. Ha új tananyagtípust vezetünk be, a szerkezetet egyetlen közös adatmodellben könnyebb módosítani, mint minden felhasználói nézethez külön tárolási kódot írni.

Alapfogalom

„Az adatszerkezet megváltoztatása (más rekordszerkezet) csak a metaadatokban jelent változást, nem kell a felhasználói programot átírni.”

Fizikai adatfüggetlenség: a tárolási és hozzáférési mód módosulhat anélkül, hogy a felhasználónak látható szerkezetet és a programokat át kellene alakítani. Ha egy gyakran keresett oszlophoz indexet hozunk létre, a keresés gyorsulhat, miközben ugyanazokat a tananyagokat és témaköröket kérdezhetjük le.

Alapfogalom

„A fizikai adatfüggetlenség azt jelenti, hogy az adattárolási szerkezetek és a hozzáférési módok változása nem vonja maga után a koncepcionális séma és az alkalmazói programok megváltozását.”

Nézet (view): a külső szint eszköze, amellyel az egyes felhasználói csoportok az adatbázis más-más részét láthatják. A tanulónak szánt lekérdezés csak a közzétett tananyagokat és saját eredményeit adja vissza, a tanár számára készített nézet a szerkesztés alatt álló leckéket és a csoport eredményeit is mutathatja. A hozzáférési jogosultságot külön kell érvényesíteni: önmagában egy oszlop elrejtése az űrlapon nem véd adatot.

Az űrlapkészítés, jelentéskészítés, varázslók, mentés és visszatöltés, valamint a grafikus felületek a DBMS körül elérhető szolgáltatások. Ezek a használatot könnyítik, és nem helyettesítik a helyes adatmodellt.

Most háromféle logikai adatmodellt hasonlítunk össze. A különbség az, hogyan ábrázoljuk és járjuk be az adatok közötti kapcsolatokat. Egy tananyagtár mappái a hierarchikus szerkezetet szemléltetik; az ugyanahhoz a több gyakorlógyűjteményhez tartozó feladatok a hálós kapcsolatokat. A TANANYAG–TÉMAKÖR táblapár a relációs modell példája.

Hierarchikus modell

Alapfogalom

„A hierarchikus modell az adatokat hierarchikus faszerkezetben ábrázolja, amelyben a különböző szinten levő csomópontok (rekordok) között hierarchikus, szülő-gyerek kapcsolat van.”

Képzeljünk el egy mappafát: a Tananyagok gyökér alatt Matematika és Adatbázis-kezelés, az utóbbi alatt SQL alapok és SQL gyakorlás található. A gyökértől a mappákon át jutunk el egy feladathoz. Minden csomópontnak egy szülője van; a rekordok akár fizikai mutatókkal is kapcsolódhatnak. Egy feladat több mappához rendelése ebben a szigorú faszerkezetben nehezebb.

Hálós modell

Alapfogalom

„A hálós modell az adatokat gyűrűsen kapcsolt rekordok hálózataként (SET) ábrázolja, ahol az ún. tulajdonos-rekordot (owner) mintegy körülveszik a tag-rekordok (member).”

A „GROUP BY feladatok” rekord egyszerre kapcsolódhat az „SQL gyakorlás” és a „Dolgozatra készülök” gyűjteményhez. A gyűjtemény tulajdonos-rekordja és a hozzá tartozó feladat tag-rekordja SET kapcsolatot alkot. A lekérdezés a kapcsolatok mentén navigál; a mutatók alapján különböző útvonalakon érhetjük el ugyanazt a feladatot.

Relációs modell

Alapfogalom

„A relációs modell lényegében táblázatok rendszere.”

A TANANYAG és TÉMAKÖR táblát közös témakör_kód érték kapcsolja össze, nincs szükség a rekordok közötti fizikai mutatóra. Ez logikai kapcsolat. A fejléc az oszlopok tulajdonságait írja le; a sorok konkrét adatokat tartalmaznak. Az anyag_id azonosít egy tananyagot, a témakör_kód pedig a másik táblára hivatkozik. Az elsődleges és idegen kulcs részletes tárgyalása a relációs modellezés következő témaköréhez tartozik.

Az adatmodellezés következő lépéséhez jutunk: igények → koncepcionális, ER vagy EER modell → választott logikai modell. A következő témakör az ER-modell fogalmait fejti ki. Ebben az első témakörben az a cél, hogy a modellezés szükségességét és a szintek közti különbséget biztosan értsd.

Előbb fogalmazz saját választ, majd nyisd meg az indoklást. Ezek a feladatok a tananyaghoz készült önellenőrzések.

A következő fejezet feldolgozásakor az ER-modellt már ezekre a fogalmakra építjük: különválasztott tények, szakterületi szabályok, kapcsolatok és koncepcionális terv.