Adatbázis szerver élesben hogy működik?

Felteszem, azzal már valamilyen szinten képben vagy, hogy miről szól maga a programozás. A mi világunk működéséről készítünk egy modellt, ami azt jelenti, hogy a programunk a mi világunkban megtalálható entitásokon (élőlényeken, tárgyakon, jelenségeken, fogalmakon) alapul. Minden entitásnak megvannak a maga tulajdonságai és viselkedései. Ezeknek az entitásoknak a program futásának idejében állapota lesz - ez azt jelenti, hogy az adott entitás tulajdonságainak egy adott időpillanatban milyen értékei vannak.

Több módszer is létezik arra, hogy ezt az állapotot elmentsük - elmenthetjük fájlba, elmenthetjük adatbázisba, stb.

Adatbázis-kezelő rendszereknek ma már sok fajtája létezik, de a hagyományos RDBMS (relációs adatbázis-kezelő rendszer) esetében ez úgy néz ki, hogy a rendszer ad egy absztrakt eszközt, amellyel leírhatod azt, hogy az entitásaid milyen tulajdonságokkal rendelkeznek. Ha már ismered az OOP-t, ott ezt az absztrakt eszközt osztálynak (class) hívjuk (feltéve, hogy osztályelvű OOP-ról beszélünk, mint a PHP), az RDBMS-ben pedig táblának (table). Míg az entitás egy példányát OOP-ben objektumnak vagy példánynak hívtuk (object/instance), RDBMS esetében ez lesz a rekord (record). Még egy dolog maradt ki, mégpedig az, hogy a tábláink nyilván nem csak úgy lógnak a levegőben, hanem egy adatbázishoz (sémához [schema]) tartoznak, amely egyfajta névtér szerepét tölti be, ha már ragaszkodunk a programozásban megszokott fogalmakhoz (és a konyhanyelven mondott definíciókhoz).

Vegyünk például egy iskolai e-napló rendszert. Az iskolába járnak diákok, a diákok tanulnak bizonyos tantárgyakat, amelyeken érdemjegyeket szerezhetnek. Tehát 4 entitásunk van a programunk miniatűr világában: napló, diák, tantárgy, az érdemjegyet pedig kezeljük egy összetett fogalomként "bejegyzés" néven, hogy lehessen hozzá plusz információkat fűzni. (Van még egyébként a tanár és további sok más entitás is egy igazi rendszerben, de ne bonyolítsuk.)

Tehát ha mondjuk MySQL/MariaDB adatbázisban szeretnéd ezeket az adatokat tárolni, akkor felcsapjuk a MySQL Workbench programot és nekiesünk az adatbázisunk megtervezésének, azaz csinálunk egy részletes EER diagramot. Egyelőre legyen elég annyi, hogy mind a 4 entitásunkhoz létrehozunk egy-egy táblát, és leírjuk benne, hogy az adott entitásnak milyen tulajdonságai vannak.

Napló: A napló tábla megmondja, hogy egy adott diák egy adott tantárgyához milyen bejegyzések tartoznak.

- diák_azonosító

- tantárgy_azonosító

- bejegyzés_azonosító

- törölve van-e (igen/nem)

- létrehozás ideje

- törlés ideje

- törlés oka

Diák: A tanuló adatai

- azonosító

- vezetéknév

- középső név

- keresztnév

- nem (fiú/lány/egyéb)

- születési idő

- születési hely

- létrehozási idő

- utolsó módosítás ideje

...

Tantárgy: A tantárgy adatai

- azonosító

- tantárgy neve

Bejegyzés:

- azonosító

- érdemjegy

- megjegyzés

(Nyilván most sokaknak nyílik a bicska a zsebében, hogy mekkora sz_r egy adatbázis ez, de na... a megértés a lényeg, nem pedig a való életbeli hasznossága.)

Azért "relációs" adatbázis-kezelő rendszer, mert azon túl, hogy leírod benne az entitásaidat, arra is lehetőséget ad, hogy leírd, hogy ezek az entitások milyen kapcsolatban és számosságban állnak egymással. A későbbiekben pedig lehetőséged lesz olyan lekérdezéseket írni, ahol ezek a kapcsolatok fogják szolgáltatni az adatgyűjtés alapját - például megkérdezheted az RDBMS-től, hogy melyek azok a diákok, akik X tantárgyból bukásra állnak, így a rendszer a szülőknek például küldhet értesítést, hogy baj van a gyermekük tanulmányi eredményeivel.

Ezt a relációt úgy hoztuk létre, hogy az entitásaink valamely tulajdonságai alapján egyértelműen beazonosíthatók - ezt a tulajdonságot, vagy tulajdonságok összességét hívjuk elsődleges kulcsnak (primary key). Ilyen például a diákigazolványszám, személyi azonosítószám. A "Bejegyzés" tábla esetében viszont bajban lennénk, mert se az érdemjegy, se a megjegyzés, se a kettejük kombinációja nem teszi egyértelműen lehetővé egy adott bejegyzés azonosítását - ilyenkor megteheted azt, hogy egy plusz tulajdonságot, mint "azonosító", hozzáteszel, és vagy a te programod, vagy az RDBMS generál hozzá egy egyedi értéket.

A reláció másik oldalán pedig az idegen kulcs (foreign key) áll. Ez azt jelenti, hogy a tábla egy rekordja egy másik tábla valamely rekordjára hivatkozik. Ezt az idegen kulcsot figyelheted meg a Napló táblában: a diák_azonosító mondja meg, hogy az adott naplóbejegyzés mely diákhoz tartozik, a tantárgy_azonosító mondja meg, hogy mely tantárgyhoz, a bejegyzés_azonosító pedig azt, hogy hol találhatóak a naplóbejegyzés további részletei.

Az, hogy milyen módon hivatkozhatnak egymásra a táblák, azt a számossággal adjuk meg (ez egyébként befolyásolja azt is, hogyan alakítjuk ki a tábláinkat):

1:1 - egy adott entitás az első táblában hivatkozik egy entitásra a másik táblában (erre látsz példát a Napló táblában, mert egy bejegyzés egy diákhoz, egy tantárgyhoz tartozik)

1:N - egy adott entitás az első táblában több entitásra is hivatkozik egy másik táblában (ilyen eset lenne az osztály-diák viszony, mivel egy osztályba több diák is járhat)

N:M - ez az 1:N számosság, de a visszafelé irányba is működik (például a tanár-diák viszony, ahol egy tanár több diákot tanít, de egy diák is több tanártól tanul)

Miután mindezt az információt dokumentáltuk az EER diagramban, az eszközzel, amivel ezt megcsináltuk (MySQL Workbench például) generáltathatunk vele egy SQL scriptet, amely tartalmazni fog minden olyan utasítást, amely a tábla létrehozásához szükséges. Ezt az SQL scriptet kell lefuttatni az adatbázis-szerveren, és lám, kész van az adatbázis. Már "csak" annyi a dolgunk, hogy a programunk tudjon kapcsolódni az adatbázis-szerverhez, és az általa kezelt entitásokat eltárolja benne.

Előfordulhat, hogy ahogy az alkalmazásunk fejlődik, szükségessé válik az adatbázis változása is. Ezeket fogjuk ún. migrációkban végigvezetni. Egy migráció azokat a különbségeket tartalmazza, amely mentén az új séma (aka. adatbázis) változott az előző állapothoz képest. Ebben a tekintetben, amikor az előző SQL scriptet lefuttattad, az is egy migrációs lépés volt, csak azzal a különbséggel, hogy ott a különbséget a semmi és az adatbázisod első állapota között vettük. De amikor a következő változásra szükség lesz, ott az adatbázisban már értékes adatokat tárolunk, amit jó lenne nem kidobni a kukába. Tehát a migrációs scriptünk valójában nem csak az adatbázisunk kinézetének változásait tartalmazza, hanem azt is, hogy a meglévő adatokat hogyan kell átszabni a megváltoztatott állapothoz. De ez már egy másik történet.