Az adatbázis tervezésének fő lépései

2.1. Koncepcionális tervezés

Az adatbázis tervezése három szakaszban történik:

1. koncepcionális tervezés;
2. logikai tervezés;
3. fizikai tervezés.

A koncepciótervezési szakasz célja egy koncepcionális adatmodell létrehozása a felhasználóknak a témakörrel kapcsolatos elképzelései alapján. Ennek eléréséhez egy sor egymást követő eljárást kell végrehajtani. Példa egy entitás (koncepcionális) sémára:

1. Az entitások meghatározása és dokumentációjuk. Az entitások azonosításához olyan objektumokat határoznak meg, amelyek másoktól függetlenül léteznek. Az ilyen objektumok entitások. Minden entitás egy értelmes nevet kap, amelyet a felhasználók megérthetnek. Az entitások nevei és leírásai bekerülnek az adatszótárba. Ha lehetséges, az egyes entitások példányainak várható száma be van állítva.

2. Az entitások közötti kapcsolatok és azok dokumentációja meghatározása. Csak azok az entitások közötti kapcsolatok vannak meghatározva, amelyek szükségesek az adatbázis-tervezési követelmények teljesítéséhez. Mindegyik típusa be van állítva. Az entitások tagsági osztálya kiderül. A hivatkozásokhoz értelmes neveket rendelnek, amelyeket igék fejeznek ki. Az adatszótárba bekerül az egyes kapcsolatok részletes leírása, megjelölve annak típusát és a kapcsolatban részt vevő entitások hovatartozási osztályát.

3. A tantárgyi terület ER-modelljének elkészítése. Az ER diagramok az entitások és a köztük lévő kapcsolatok ábrázolására szolgálnak. Ezek alapján létrejön a modellezett témakör egyetlen vizuális képe - a témakör ER-modellje.

4. Az attribútumok meghatározása és dokumentálása. A létrehozott ER-modell entitásait leíró összes attribútum megjelenik. Minden attribútum egy értelmes nevet kap, amelyet a felhasználók megérthetnek. A következő információkat tárolja az adatszótár minden egyes attribútumhoz:

• attribútum neve és leírása;
• az értékek típusa és dimenziója;
• az attribútum alapértelmezett értéke (ha van);
• lehet-e az attribútum NULL értéke;
• hogy az attribútum összetett-e, és ha igen, milyen egyszerű attribútumokból áll. Például az „Ügyfél teljes neve” attribútum állhat egyszerű „Vezetéknév”, „Keresztnév”, „Apanév” attribútumokból, vagy lehet egyszerű, és egyetlen értékeket tartalmazhat, például „Szidorszkij Jevgenyij Mihajlovics”. Ha a felhasználónak nem kell hozzáférnie a „Név” egyes elemeihez, akkor az attribútum egyszerűként jelenik meg;
• az attribútum kiszámítása megtörténik-e, és ha igen, hogyan számítják ki az értékeit.

5. Az attribútumértékek meghatározása és azok dokumentációja. Az ER-modellben részt vevő entitás minden attribútuma esetén érvényes értékeket határoznak meg, és nevet rendelnek hozzá. Például a "Számla típusa" attribútum csak a "betét", "aktuális", "igény szerint", "kártyaszámla" értékekkel rendelkezhet. Az attribútumokhoz kapcsolódó adatszótári bejegyzések az attribútumértékkészletek nevével frissülnek.

6. Az entitások elsődleges kulcsainak meghatározása és azok dokumentációja. Ezt a lépést az elsődleges kulcs meghatározása vezérli – mint egy entitás attribútuma vagy attribútumkészlete, amely lehetővé teszi példányainak egyedi azonosítását. Az elsődleges kulcsinformációk az adatszótárba kerülnek.

7. A koncepcionális adatmodell megbeszélése a végfelhasználókkal. A koncepcionális adatmodellt egy ER-modell képviseli, amelyhez a kidolgozott adatmodell leírását is tartalmazó kísérő dokumentáció tartalmazza. Ha tartományi inkonzisztenciákat találunk, akkor addig módosítjuk a modellt, amíg a felhasználók meg nem erősítik, hogy az általuk javasolt modell megfelelően tükrözi személyes nézeteiket.

2.2 Logikai tervezés

A logikai tervezési szakasz célja, hogy a kiválasztott adatmodellre épülő koncepcionális modellt olyan logikai modellré alakítsuk, amely független az adatbázis fizikai megvalósításához később felhasznált DBMS tulajdonságaitól. Ennek eléréséhez a következő eljárásokat kell végrehajtani.

Példa egy logikai adatbázissémára.

1. Adatmodell kiválasztása. Leggyakrabban a relációs adatmodellt választják az adatok táblázatos megjelenítésének egyértelműsége és a velük való munka kényelmessége miatt.

2. Táblázatok készletének meghatározása az ER modell alapján és dokumentálása. Az ER-modell minden entitásához létrejön egy táblázat. Az entitás neve a tábla neve. A táblák közötti kapcsolatok az elsődleges és az idegen kulcsok mechanizmusán keresztül jönnek létre. A táblák szerkezete és a közöttük kialakult kapcsolatok dokumentálva vannak.

3. A táblázatok normalizálása. A normalizálás megfelelő végrehajtásához a tervezőnek mélyen meg kell értenie az adatok szemantikáját és használati mintáit. Ennél a lépésnél ellenőrzi az előző lépésben készített táblák szerkezetének helyességét a normalizálási eljárás alkalmazásával. Ez abból áll, hogy minden asztalt legalább a 3. NF-be kell vinni. A normalizálás eredményeként egy nagyon rugalmas adatbázis-kialakítást kapunk, amely megkönnyíti a szükséges bővítmények elkészítését.

4. A logikai adatmodell ellenőrzése a felhasználók által biztosított összes tranzakció végrehajtásának lehetőségére. A tranzakció olyan műveletek összessége, amelyeket egy egyedi felhasználó vagy alkalmazásprogram hajt végre az adatbázis tartalmának megváltoztatása érdekében. Tehát a BANK projektben egy tranzakcióra példa lehet egy adott ügyfél számláinak kezelési jogának átruházása egy másik ügyfélre. Ebben az esetben egyszerre több módosítást kell végrehajtani az adatbázisban. Ha egy számítógép összeomlik egy tranzakció során, az adatbázis inkonzisztens állapotba kerül, mert néhány változtatást már végrehajtottak, mások pedig nem. Ezért minden részleges módosítást vissza kell vonni, hogy az adatbázis visszaálljon a korábbi konzisztens állapotába.

A tranzakciók listáját a témakör felhasználói tevékenységei határozzák meg. Az ER-modell, az adatszótár, valamint az elsődleges és az idegen kulcsok között kialakított kapcsolatok segítségével minden szükséges adatelérési műveletet manuálisan megkísérelnek végrehajtani. Ha bármelyik kézi művelet meghiúsul, akkor a lefordított logikai adatmodell nem megfelelő, és hibákat tartalmaz, amelyeket ki kell küszöbölni. Talán egy entitás, kapcsolat vagy attribútum modelljének hiányosságaihoz kapcsolódnak.

5. Adatintegritás támogatási követelmények meghatározása és dokumentálása. Ezek a követelmények olyan korlátozások, amelyek megakadályozzák, hogy ütköző adatok kerüljenek az adatbázisba. Ennél a lépésnél az adatintegritási kérdéseket a megvalósítás konkrét szempontjaitól függetlenül tárgyaljuk. A következő típusú korlátozásokat kell figyelembe venni:

• szükséges adatok. Annak megállapítása, hogy vannak-e olyan attribútumok, amelyeknek nem lehet NULL értéke;
• az attribútumértékekre vonatkozó korlátozások. Az attribútumok érvényes értékei meg vannak határozva;
• entitás integritása. Ez akkor érhető el, ha az entitás elsődleges kulcsa nem tartalmaz NULL értékeket;
• referenciális integritás. Magától értetődik, hogy az idegen kulcs értékének jelen kell lennie a szülőentitás táblázatsorának egyik elsődleges kulcsában;
• az üzletszabályzat által előírt korlátozásokat. Például a BANK projekt esetében olyan szabály fogadható el, amely megtiltja az ügyfélnek, hogy mondjuk háromnál több számlát kezeljen.

Az összes megállapított adatintegritási megszorításra vonatkozó információ az adatszótárban található.

6. A logikai adatmodell végleges változatának elkészítése és megbeszélés a felhasználókkal. Ez a lépés előkészíti az ER-modell végső verzióját, amely a logikai adatmodellt reprezentálja. Magát a modellt és a frissített dokumentációt, beleértve az adatszótárt és a relációs táblahivatkozási sémát, áttekintésre és elemzésre mutatják be a felhasználók számára, akiknek biztosítaniuk kell, hogy az pontosan reprezentálja a témakört.

2.3. Fizikai tervezés

A fizikai tervezési szakasz célja a számítógép külső memóriájában található adatbázis konkrét megvalósításának leírása. Ez az adattárolás szerkezetének és az adatbázis-adatokhoz való hozzáférés hatékony módszereinek leírása. A logikai tervezésben választ adnak arra a kérdésre, hogy mit kell tenni, a fizikai tervezésben pedig kiválasztják a módját, hogyan kell csinálni. A fizikai tervezési eljárások a következők.

1. Adatbázistáblák tervezése a kiválasztott DBMS segítségével. Egy relációs DBMS van kiválasztva a gépi adathordozón tárolt adatbázis létrehozásához. A táblázatok tervezésére szolgáló funkcionalitása alaposan tanulmányozott. Ezután megtörténik a táblák tervezése és kapcsolati sémájuk a DBMS környezetben. Az elkészített adatbázis projektet a kísérő dokumentáció ismerteti.

2. Üzleti szabályok megvalósítása a kiválasztott DBMS környezetében. A táblázatokban szereplő információk frissítését üzleti szabályok korlátozhatják. A megvalósítás módja a választott DBMS-től függ. Egyes rendszerek a témakör követelményeinek megvalósítására több funkciót, mások kevesebbet kínálnak. Egyes rendszerekben egyáltalán nincs támogatás az üzleti szabályok megvalósításához. Ebben az esetben az alkalmazásokat a korlátaik megvalósítására fejlesztik.

A tartományi üzleti szabályok megvalósításával kapcsolatos valamennyi döntés részletes leírása a mellékelt dokumentációban található.

3. Az adatbázis fizikai szervezetének megtervezése. Ez a lépés kiválasztja a legjobb fájlszervezést a táblákhoz. Azonosítják a tervezett adatbázisban végrehajtandó tranzakciókat, és kiemelik közülük a legfontosabbakat. Elemezzük a tranzakciós átviteli sebességet - az adott időintervallumban feldolgozható tranzakciók számát és a válaszidőt - egy tranzakció végrehajtásához szükséges időtartamot. Arra törekednek, hogy növeljék a tranzakciós átviteli sebességet és csökkentsék a válaszidőt.

Ezen mutatók alapján döntések születnek az adatbázis teljesítményének optimalizálására oly módon, hogy táblákban indexeket határoznak meg, amelyek felgyorsítják az adatok kiválasztását az adatbázisból, vagy csökkentik a tábla normalizálási szintjére vonatkozó követelményeket. A létrehozott adatbázis befogadásához szükséges lemezterület becsült értéke. Törekedj arra, hogy minimalizáld.

A fenti kérdésekben hozott döntéseket dokumentálják.

4. Adatbázis-védelmi stratégia kidolgozása. Az adatbázis értékes vállalati erőforrás, amelynek védelmére nagy figyelmet fordítanak. Ehhez a tervezőknek teljes és világos ismeretekkel kell rendelkezniük a kiválasztott DBMS által biztosított összes védelemről.

5. Az adatbázis működési monitorozásának megszervezése és annak beállítása. Az adatbázis fizikai projektjének elkészítése után megszervezzük annak működésének folyamatos nyomon követését. A kapott információ az adatbázis teljesítményszintjéről az adatbázis hangolására szolgál. Ehhez a kiválasztott DBMS eszközei is be vannak vonva.

A működő adatbázis módosítására vonatkozó döntéseket meg kell fontolni és alaposan mérlegelni kell.