10.3. Adatbázis újratervezés folyamata

Az adatbázis újratervezés egyik fontos jellemzője, hogy az adatbázist párhuzamosan többen, több különböző alkalmazás is használhatja. Sajnos legtöbbször nem ismert az adatbázist felhasználó alkalmazások teljes köre. Ez nagy megkötöttséget jelent a fejlesztés során, hiszen ekkor nem szabad módosítani a meglévő interface felületek megjelenését. A korábban meglévő adatelemek és adatbázis objektumoknak meg kell maradniuk. Ebben az esetben a fejlesztés csak olyan lehet, amely bővíti és nem szűkiiti az elérhető funkciókört, azaz az alábbi elemekre vonatkozhat:

Mivel az adatbázis egy közösen használt erőforrás, melynek tartalma, szerkezete az élete alatt jelenősen megváltozhat, nagyon fontos, hogy ezen jövőbeli módosítási igényekre tekintettel legyünk a tervezés során. Ehhez minél magasabb szinten meg kell valósítani az adatbázis elérés modularitását, rétegződését. Az adatbázis kezelés világában az alábbi eszközöket lehet haszonnal alkalmazni a függetlenségi szint emelésére:

Az adatbázis újratervezés általános esetben magába foglalhatja azonban a korábbi sémaelemek módosítását is. Erre akkor lehet szükség, ha kiderül, hogy a korábbi tervezési elképzelés nem állja meg a helyét, korrekcióra van szükség. Ez lehet a tervező hibája, de lehet a követelmények változása miatti esemény is. Újratervezés esetén különös gonddal kell kezelni a korábbi funkciók zökkenőmentes átvitelét az új verzióba. Az adatbázis újratervezés szokásos elemei:

10.3.1. Séma elemek törlése

Ha az adatbázisban a változtatás célja korábban létező adatbázis elemek elvetése, akkor a módosítást több lépésen keresztül célszerű végigvinni. Az egyes lépések célja, hogy minél hamarabb észrevegyük az esetleges konfliktusokat és még időben, a nagyobb léptékű módosítás előtt feloldjuk az ellentmondásokat. Az adatelemek törlésekor emiatt az alábbi lépéseket célszerű végrehajtani:

  • Segédtábla létrehozatala az eredeti adatok megőrzésére:

        CREATE TABLE seged (...);
    

  • Az adatok átemelése a segédtáblába:

        INSRERT INTO seged SELECT * FROM ...;
    

  • Az érintett sémaelem törlés séma szintű előkészítése. Az objektum típusától függően különböző séma átalakításokra lehet szükség. Egy tábla törlésekor például sorra kell venni az alábbi elemeket:

    - rajta értelmezett VIEW-k
    - rajta értelmezett SYNONYM-ák
    - rajta értelmezett tárolt eljárások
    - rajta értelmezett TRIGGER-ek
    - oda vonatkozó hivatkozási megkötések

    Ezen objektumokat mind módosítani vagy törölni kell, mielőtt a hivatkozott objektumot módosítanánk.

  • Az érintett objektum törlése. Az objektum törlése esetén a törlés egyes esetekben több lépésben valósulhat meg. Az Oracle rendszer esetében például egy mező törlésekor lehetőség van logikai törlésre és fizikai törlésre. A logikai törlés esetében a DBMS csak használaton kívül helyezi a mezőt, a művelet parancsa

        ALTER TABLE tabla SET UNUSED mező;
    

    A fizikai törlés esetében ténylegesen megszűnik a kijelölt mező, az ide vonatkozó SQL parancs Oracle esetében:

        ALTER TABLE tabla DROP COLUMN mező;
    

  • A módosítás tesztelése. A hivatkozó és már módosított elemek (VIEW, TRIGGER, PROCEDURE,FOREIGN KEY..) működésének ellenőrzése.

10.3.2. Új sémaelem felvitele

A séma bővítéskor is szükség van a hivatkozó objektumok sorra vételére, hiszen előfordulhat, hogy a hivatkozó objektum nem használja ki a mezőszintű függetlenség adta lehetőségeket. Míg például egy

    SELECT m1,m2,.. FROM ..

alakú lekérdezés eredménye nem változik, ha új mezőt adunk a sémához, addig a

    SELECT * FROM ..

alakban kiadott műveletnél bővül a visszaadott mezők köre, tehát fel kell készülni annak fogadására. Ilyenkor az új mező neve konfliktusba kerülhet a kliens programokban használt változó nevekkel. Ezen ütközéseket kell ellenőrizni.

Ha számított mezőket hozunk be a sémába, akkor annak megvalósítására több lehetőség is kínálkozik:

  • Egyes DBMS rendszerek közvetlenül is támogatják a számított mező adattípus. Az MS SQL Server esetében az alábbi módon hozható létre származtatott mező:

      create table proba (a integer, b integer, c as a + b);
      insert into proba values (1,3);
      select * from proba; 
    

    A mintában a C mező lesz számított mező, itt az adattípus helyén a származtatási parancs szerepel a tábla definícióban. Adatok felvitelekor nem lehet ezen mezőknek értéket adni, de lekérdezéskor ott szerepel a mező értéke.

  • Ha a DBMS nem támogatja a számított mezőt közvetlenül, akkor a TRIGGER mechanizmus alkalmazható. Ilyenkor a mezőt mint normál mezőt hozzuk létre és a triggert a tábla DML műveleteihez kötjük. A trigger feladata, hogy a többi mező módosulása esetén frissítse a kijelölt számított mező tartalmát.

10.3.3. Védelmi tesztek

Az adatbázisban tárolt adatok védelmének biztosítása is az egyik alapvető adatbázis feladatok közé tartozik. Az relációs adatbáziskezők egyik jellemzője, hogy SQL parancsok alakjában kapja meg a végrehajtandó parancsot. Mivel az SQL nyelv teljes parancskészletet tartalmaz és egy sztringben több parancs is jöhet, a nem megfelelő SQL szöveg károkat okozhat. Emiatt igen fontos, hogy az elküldött szöveg pontosan megfeleljen az elvárt alaknak. Ha nem megfelelő az ellenőrzés, akkor kárt okozó parancsok kerülhetnek végrehajtásra. Ezt a veszélytípust nevezik SQL Injection támadásnak.

Az SQL Ijnjection esetében a kliens oldalon bevitt SQL alak olyan parancselemeket is tartalmaz, melyek nem kívánt hatással járnak. Ezt úgy érik el, hogy a felhasználótól kapott érték úgy tér el az elvárt alaktól, hogy egy veszélyt okozó parancsot vagy parancs részletet is magába foglal. Példaként vegyünk egy egyszerű nyilvántarrtó rendszert, ahol a felhasználótól lekérdezzük a keresett áru nevét. Ehhez a GUI tartalmaz egy anev mezőt. A mezőbe bevitt értéket egy SQL parancsban adjuk át, mint kulcsértéket:

   parancs = "SELECT * FROM termekek WHERE nev = '" 
   + anev.text +"'  ";

Ha a felhasználó az elvárt normál azonosító név helyett egy

   baba'  or   'a'='a'

értéket visz fel, akkor az elküldött parancssor a

   SELECT * FROM termekek WHERE nev = 'baba' or 'a'='a';   

lesz, amely minden terméket vissza fog adni. Még súlyosabb kár éri a rendszert, ha a bevitt parancs

    baba' ; delete from termekek where  'a'='a'

alakú, hiszen ekkor két egymást követő parancs kerül a szerver oldalon végrehajtásra, melyek alakjai

     SELECT * FROM termekek WHERE nev = 'baba';
     DELETE FROM termékek WHERE 'a'='a';

A fenti támadások ellen a beolvasott paraméterek alaposabb ellenőrzésével illetve a parancsok kétfázisú végrehajtásával lehet védekezni.

A védelmi tesztek esetében is több szinten futhat az ellenőrzés. A FirtsTechnologies ajánlása alapján az alábbi tesztek kerülnek végrehajtásra:

  • Külső, alkalmazás szintű tesztelés (például az SQL Injection támadás ellenőrzése)

  • Adatbázis audit: a beépített védelmi politika ellenőrzése, jogosultsági politika tesztelése

  • Adatbázis behatolás teszt, különböző segédeszközök révén kisérletek az adatbázis adatok elérésére

  • OS szintű audit, az operációs rendszer felőli védelmi elemek ellenőrzése

  • Adatfolyam elemzés: a szerver és a kliensek közötti adatfolyam ellenőrzése