10.2. TDD alapú adatbázis fejlesztés

Az adatbázisok világban is nagy szerepe van a tesztelés orientált fejlesztésnek, vagyis a TDD (test driven development) módszertannak. A TDD módszertan alapelvei a következőkben foglalhatók össze:

10.2.1. Fokozatos adatmodellezés

A fokozatos modellezés szemlélete azt fejezi ki, hogy az adatbázis séma és védelmi, hatékonysági modelljét nem egy lépésben, a fejlesztés elején alakítjuk ki, hanem menetközben több fázison keresztül finomodik a modell. A tervezés első fázisában csak egy nagyvonalú terv áll rendelkezésre, amely tartalmazza a fő információ elemeket, de nem tér ki minden részletre. A projekt fejlődése során egyre finomabb kép alakul ki a követelményekről és a modellezett területről. Ezen finomítások fokozatosan épülnek be az adatbázis modellbe. A tervezés fontosabb lépései:

  1. induló, elsődleges követelmény modellezés

  2. követelmények pontosítása

  3. új modellelemek beolvasztása

  4. kódolás

  5. tesztelés

  6. vissza a 2. pontra

A fenti modell tehát egy folyamatos és fokozatos modell és program finomítást és közelítést tartalmaz, ahol a tevékenységek fontos eleme az ismétlődő, egyre átfogóbb tesztek lefuttatása.

10.1. ábra - A TDD alapú fejlesztés lépései

A TDD alapú fejlesztés lépései

10.2.2. Visszirányú adatmodellezés

A visszirányú, regressziós tesztek szerepe, hogy az adatbázis séma módosítása után meggyőződhessünk arról. hogy a korábban megvalósított funkciók továbbra is érvényesek, jól működnek. A biztonság és minőség orientált fejlesztés alapelve, hogy ezen teszteket minden változás után lefuttassuk, tehát a tesztelés tulajdonképpen a módosítás részévé válik. Ezen megközelítés egyik markáns képviselője az előtesztelő programozás (TFD, test first development), mely előírja, hogy a tesztek elkészítése legyen az első lépés a fejlesztésben, mivel úgyis addig kell módosítani a modellen, amíg a kapcsolódó tesztek le nem futnak. A TFD alapú fejlesztés főbb lépései:

  1. induló teszt előállítása a kívánt funkcióhoz

  2. a teszt futtatása; ha sikeres át lehet térni a következő funkcióra és így vissza az 1. pontra; ha nem sikerül továbblépés a 3. pontra

  3. a modell módosítása egy kisebb, kezelhető mértékben

  4. a teszt futtatása; ha sikeres át lehet térni a következő funkcióra és így vissza az 1. pontra; ha nem sikerül visszalépés a 3. pontra

Az TFD megközelítés előnye, hogy a tervező jobban átgondolja a célokat, mélyebben feltáródnak az igényelt változások jellegzetességei. Az elkészített tesztek jobban lokalizálódnak egy-egy problémakörre ezért alaposabban ellenőrzés hajtódik végre. Természetesen ennek velejárója, hogy nagyobb feladatok fog jelenteni a tesztek megírása és végrehajtása. További előnynek tekinthető az is, hogy a TFD megközelítésben a fejlesztő hamarabb lezárhatja az egyes modulok fejlesztését, hiszen hamarabb kap visszajelzést az elvégzett munka minőségéről.

10.2.3. Verzió követés biztosítása

A fokozatos adatbázis fejlesztés során előfordulhat, hogy egy adott módosítás nagyon sikertelennek bizonyul. Ekkor célszerűbb újra visszatérni ez előző érvényes, helyes állapothoz, mint foltozgatni a már megírt módosításokat. A korábbi állapotokhoz történő visszatérés egyfajta verziókövetést igényel, hiszen megőrizzük a korábbi fejlesztési állapotokat. Az adatbázis séma menedzsmentjének egyedi vonása, hogy több elemet is le kell fednie. A verziókezelésbe bevonandó elemek köre:

adatbázis objektumok (table, view, user,...) szerkezet leírása
védelmi beállítások
integritási beállítások
adatbázis kódok (tárolt eljárás, trigger,..)
adatbázis paraméterek

A fenti adatok két nagy forrásból szedhetők össze:

adatbázis metaadat táblák tartalma
külső konfigurációs állományok tartalma

A piacon léteznek gyári megoldások, mint például az SVCO rendszer az Oracle RDBMS-hez. Az SVCO rendszer egy teljesen PL/SQL kódban megírt verzió követő rendszer, amely az Oracle szerveren belül egy külön adatbázisban tárolja le a kijelölt adatbázis sémáiban bekövetkező változásokat. A verziókezelés természetesen történhet egyedi megoldással, az érintett leíró elemek másolásával és kimentésével. Az Oracle esetében többtucat metaadat nézeti tábla áll rendelkezésre DBA hatáskörben a séma adatok kiolvasására. Néhány fontosabb sémaleíró tábla:

  • DBA_TABLES: adatbázis táblák adatai

  • DBA_COLUMNS: adattábla mezők leírása

  • DBA_TAB_PRIVS: objektum jogok leírása

  • DBA_USERS: felhasználók adatai

  • DBA_CONSTRAINTS: megszorítások leírása

  • DBA_ROLES: szerepkörök adatai

  • DBA_PROCEDURES: tárolt eljárások adatai

  • DBA_SOURCE: tárolt eljárások kódjai

A fenti metaadat állományok tartalmának kinyerésére több mód is kínálkozik:

  • SELECT * FROM .. : tartalom közvetlen lekérdezése

  • COPY FROM forrás_db TO cél_db [CREATE | REPLACE] tábla USING lekérdezés : tábla átmásolása

  • trigger kötése a tartalom módosításához : CREATE TRIGGER AFTER UPDATE ON tábla FOR EACH ROW ..... A trigger törzsében lehet szerepeltetni a tartalom kiolvasását és másolását végző utasításokat..

  • IMPORT segédprogram futtatása a magadott táblákra

Az egyes adatbázis objektumok séma leírásakor hasznos információ a kapcsolódó jelentés magyarázat. Ehhez az Oracle-ben a

COMMENT ON objektum IS szöveg;                            
                        

SQL parancs használható. A fenti parancs segítségével a jelentést magyarázó szöveget adhatunk a sémához. A megadott leírás a

SELECT COMMENTS  FROM  USER_TAB_COMMENTS WHERE ...;
SELECT COMMENTS  FROM  USER_COL_COMMENTS WHERE ...;
                          

parancsokkal kérdezhetők le.

10.2.4. Adatbázis homokozók, munkakörnyezetek biztosítása

A hagyományos szotfver fejlesztéshez hasonlóan az adatbázisok esetében is több fázisból áll a fejlesztés, úgymint tervezés, kódolás, tesztelés és bevezetés. Ezen fázisok eltérő igényeket jelentenek az adatbázissal szemben, hiszen míg például a kódolás szakaszában még előfordulhatnak hibák (a hiba nélkül kódolás igen ritka jelenség), addig a bevezetésnél már nem szabadna hibákat tartalmaznia a rendszernek. A működő rendszernél a stabilitás a legfontosabb, a fejlesztő rendszernél pedig a rugalmasság. Ezen eltérő követelmények miatt célszerű az adatbázist is több példányban megvalósítani, az egyes munkacsoportoknak saját adatbázis környezetet biztosítani. Az ilyen egyedi igényeket kielégítő adatbázis példányokat nevezik homokozóknak (sandbox). Az adatbázis fejlesztésnél az alábbi homokozó példányokat szokás megkülönböztetni:

  • fejlesztői környezet (development sandbox):

  • projekt integrációs környezet (project integration sandbox):

  • demonstrációs környezet (demo sandbox):

  • bevezetési teszt környezet (pre-production test sandbox):

  • üzemi, éles környezet (production)

10.2. ábra - Adatbázis változatok, homokozók

Adatbázis változatok, homokozók

Az egyes példányok létrehozása történhet manuálisan, egyedi DBA parancsokkal is, A következőkben bemutatjuk az adatbázis másolás parancsait az Oracle DBMS példáján keresztül [Jeff Hunter, Sr. Database Administrator: http://www.idevelopment.info/data/Oracle/DBA_tips/Backup_and_Recovery/BandR_2.shtml]

  1. Az adatbázis aktuális állományainak számbavétele, majd másolása egy új helyre. Az állományokat az alábbi parancsokkal lehet felderíteni:

    select name from v$database;
    select name from v$datafile;

  2. Új inicializációs állomány készítése. Ehhez az INITx.ORA állományt kell átmásolni és új nevet adni. A inicializációs állományban az alábbi paramétereket kell aktualizálni:

    db_name
    control_files
    audit_file_dest
    background_dump_dest
    log_archive_dest
    core_dump_dest
    user_dump_dest

  3. Vezérlő állományok létrehozatala. ehhez a forrás control file tartalmat kell átmásolni. Ehhez az alábbi SQL parancsot kell kiadni:

    alter database backup controlfile to trace;

    Ezt követően az új vezérlő állományt előállító SQL parancssort kell létrehozni. A parancssor szerkezete:

    STARTUP NOMOUNT
    CREATE CONTROLFILE SET DATABASE "xxx" RESETLOGS NOARCHIVELOG
        MAXLOGFILES xx
        MAXLOGMEMBERS xx
        MAXDATAFILES xx
        MAXINSTANCES xx
        MAXLOGHISTORY xx
    LOGFILE
      GROUP 1 (
        '/u03/app/oradata/xxx/redo_g01a.log',
        '/u04/app/oradata/xxx/redo_g01b.log',
        '/u05/app/oradata/xxx/redo_g01c.log'
      ) SIZE 200K,
      GROUP 2 (
    ...
    ) SIZE 200K,
    DATAFILE
      '/u08/app/oradata/xxx/system01.dbf',
      '/u06/app/oradata/xxx/rbs01.dbf',
      '/u07/app/oradata/xxx/temp01.dbf',
      '/u10/app/oradata/xxx/userd01.dbf',
      '/u09/app/oradata/xxx/userx01.dbf';                                       
                                       

    Ezt követően lefuttatható DBA-ként az előbb elkészített parancssor.

  4. A most létrehozásra előkészített példány élesíthető, elindítható. A véglegesítés parancsai:

    alter database recover database until cancel using backup controlfile;
    alter database recover cancel;
    alter database open resetlogs;

A teljes adatbázis séma átmásolásra DBMS-be épített segédprogramok állnak rendelkezésre. Az Oracle esetében az EXPORT / IMPORT rutinokat lehet alkalmazni ezen célra. Mindkét parancsnál egy külön parancsállományba szokás összefoglalni a parancs paramétereket. A mentés és betöltés több különböző üzemmódban futhat le:

  • teljes adatbázis átvitele

  • kijelölt felhasználó adatait vagy egyéb módon kijelölt objektumokat érint csak a művelet

  • integritási elemek átvihetők vagy kihagyhatók

  • adattartalom átvitele vagy kihagyása (csak séma)

  • jogosultságai adatok átvitele vagy kihagyása

Egy minta parancsindítást ad meg a következő parancs:

 exp SYSTEM/password FULL=y FILE=dba.dmp LOG=dba.log CONSISTENT=y