Fizikai adatbázis létrehozása
Az adatbázis modellje alapján szintén egyfajta leképezéssel jön létre a fizikai adatbázis. Gyakran az adatbázis-modellt nem tudjuk az eszközeinkkel egyszerű módon leképezni, ezért ilyenkor előfordulhat, hogy visszanyúlunk a tervezési fázishoz és módosítjuk az adatmodellt.
A logikai sémában meglévő egyedtípusok, relációk megfelelnek a fizikai adatbázis tábláinak.
Táblák létrehozása
A fizikai adatmodell az alkotó táblák halmaza, melyeket az adatbázis adminisztrátor az adatbáziskezelő rendszer programmal (SQL-ben a CREATE table paranccsal) hoz létre.
A táblákban lévő mezők típusánál a logikai sémában meglévő adattípusokat kell használni, de az egyes adatbázis-kezelőknek lehetnek a feladatra jól specifikált speciális adattípusai is. A legalkalmasabb típust érdemes megkeresni és megtalálni.
A táblák létrehozása után / közben meghatározzuk, hogy mely mezők lesznek kulcsok, mely mezők szerint érdemes indexeket létrehozni.
Indexek, kulcsok létrehozása
A kulcsok létrehozása során szinte mindig olyan plusz adat kerül az adatbázisba, amely a kulcs alapján az adatok elérését nagyságrendileg meggyorsítja. A sebesség a bináris keresés sebessége.
Olyan adatok esetén, amelyek nem kulcsok szintés célszerű indexeket létrehozni. Ezek az indexek általában hash táblákkal dolgoznak. A hash tábla olyan megoldás, amikor az elérendő adat értéke alapján a teljes adathalmazból kiválaszt egy algoritmus egy részadathalmazt. Ez a kiválasztás bináris keresési elven működik. A kiválasztott rész adathalmazban már lineáris a keresés.
Minden olyan kulcsot érdemes létrehozni, amely a későbbiekben lekérdezések sorrendjéül, keresések alapjául szolgálhat.
Kapcsolatok létrehozása
Ezután létrehozzuk az adatbázisban a kapcsolatokat, amennyiben az adatbázis támogatja az automatikus kapcsolat kezelést (Access, MS SQL, Postgres SQL, MySQL InnoDB adattáblákkal)
Alapadatok felvitele
Az adatbázisban vannak, lehetnek olyan táblák, amelykben lévő adatok a használat során nem változnak, esetleg csak bővülhetnek. ezeket a táblákat hívjuk alapadatoknak. (pl.kódtáblák).
Nézetek létrehozása (View)
A nézetek olyan lekérdezések, amelyek önálló névvel rendelkeznek és minden szempontból adattábláknak néznek ki. Az Accessben ezeket hívják lekérdezéseknek.
lekérdezések létrehozása
Egyes adatbáziskezelők a lekérdezéseket le tudják tárolni - Access - más rendszerek nem képesek önmagukban tárolni. Az adatbázis szempontjából a lekérdezések létrehozása tulajdonképpen már az adatbázist kezelő alkalmazás létrehozásával kapcsolódhat össze.
Jelentések (Riportok) megtervezése, létrehozása
A jelentések olyan lekérdezéseken alapuló felületek, amelyek csakis az adatok megjelenítésének céljából jönnek létre. Erre minden adatbázis-kezelőhöz speciális eszközöket célszerű használni, amelyek az ilyen feladatokat megkönnyítik.
Adatbeviteli ablakok (Űrlapok), lekérdezések megtervezése és létrehozása
Ezek az elemek már nem feltétlenül az adatbázis tervezéshez tartoznak, de ezek tartalmazzák a rendszer használatához szükséges felületet.
A fizikai adatbázis létrehozásának további elvei
Nagy adatbázisoknál lehet célszerű a fizikai megvalósításkor végiggondolni az alábbiakat:
- Szükséges-e tranzakciós adatbázis? Erre akkor van szükség, ha az adatbázis rekordjai sokszor változnak, tehát a lekérdezés tipikusan adatmódosító. A tranzakciós adatbázisok általában lassabbak, de kevésbé biztonságosak.
- Egy adatbázis tartalmazzon-e minden szükséges adatot? Ekkor megosztott adatbázisról beszélünk. Mi fogja az adatbázisok közötti kapcsolatot biztosítani? Milyen elven jöjjön létre a megosztás?
- Egy szerveren van-e a teljes adatbázis, vagy több szerveren? Ez utóbbi esetben gondoskodni kell a különböző szervereken lévő adatok szinkronizálásáról is.
Biztonsági mentés
Ami elromolhat el is romlik. Az adatbázisszerverek elromolhatnak. Ha megsérül az adatbázis, akkor azt célszerű az utolsó működő változtaból újraépíteni, tehát az adatbázisokat rendszeresen menteni kell. A mentés lehet napi, heti, havonkénti vagy alkalmai. A mentés sűrűségét az adatmódosítás gyakorisága határozza meg. Lehetőség szerint automatizálni kell a feladatot. A mentett adatbázisnak mindenképpen fizikailag más adathordozóra kell kerülnie, mint ahol az éles adatbázis van. A biztonság magasabb foka, ha a mentett adatbázis másik szerverre és még magasabb foka, ha a másik szerver másik épületben helyezkedik el, mint az éles adatbázis.
Szinkronizálás
A szinkronizálás azt jelenti, hogy egymástól függetlenül működő adatbázisokban tárolt adatokat időnként azonos állapotba hozzuk. A szinkronizálást akkor kell lelvégezni, amikor az adatbázisokat éppen nem használják mások. Tipikus problémákat tipikus modellek alapján oldják meg.
Master-Slave modell
A legegyszerűbb modell. Egy Master adatbázis van. Itt zajlik minden módosítási jellegű művelet. Minden más helyen csak lekérdezések lehetnek. A Módosítások átvitelét a Slave rendszerekre vagy a Master rendszer vagy a Slave rendszerek kezdeményezik, rendszeres időközönként.
A lekérdezések mindig azt az állapotot mutatják a Slave rendszereken, amelyek a legutolsó szinkronizáláskor létre-jöttek.
Két oldalú szinkronizálási modell
Ebben az esetben mind a két oldalon vannak módosítások.
- A módosított rekordok végső állapotát az adott rekordon végzett utolsó módosítás időpontja adja meg, tehát minden módosítás időbélyeghez kötött
- A beszúrt rekordok általában automatikusan vagy más módon kapnak kulcsértékeket. Ha két adatforrásban ugyanazt a kulcsérétéket kapja egy új rekord, akkor kulcsütközés jön létre. Ezt az ütközést gyakran automatikus mechanizmus nem tudja feloldani. Ekkor az alábbi esetek vannak:
- Az egyik szervernek prioritása van. - Az ilyen esetekben az azon felvitt új rekord a nyerő.
- Előnye az egyszerűség
- Hátránya, hogy a felvitt adatok egy része elveszik
- A két rendszer hibalistát generál és az adminisztrátorra bízza az ütközés feloldását.
- előnye, hogy adatok nem vesznek el.
- Hátránya, hogy nagy mennyiségű adat felvitele során az emberi beavatkozásra várás a hatékonyság rovására megy
- Automatikusan módosítja az egyik vagy mindkét kulcsértéket, a különbözőség érdekében.
- előnye a hatékonyság
- Hátránya az, hogy csak olyan kulcsnál lehet alkalmazni, ami algoritmikusan generálható.
- Tipikusan a számláló típusú kulcsmezőknél lehet.
Számláló típusú kulcsmezők automatikus szinkronizálása azon az elven működik, hogyha két külön adatforrában a kulcsértékek automatikusan növekednek kihagyás nélkül, akkor mind a két adatforrásban létezik maximális kulcs. Az utolsó szinkronizálás óta eltelt időszakban az előző maximális kulcs feletti értékek kerültek be az adatforrásokba. Az így létrejött eltérő adatforrások maximális kulcsértékeinek maximumánál eggyel nagyobb értéket fel lehet használni új kulcsérték létrehozására.
- Az egyik szervernek prioritása van. - Az ilyen esetekben az azon felvitt új rekord a nyerő.
Több oldalú szinkronizálás
Ha kettőnál több szerver van, akkor kineveznek egy Master szervert, és minden más szerver ezzel szinkronizál egyenrangú módon megadott időközönként periodikusan. Nem megoldható az, hogy minden szerver mindegyikkel szinkronizáljon. A Master szerver állapotát kell backupolni. Ha kiesik a Master szerver, akkor helyette ki kell nevezni egy másik szervert a meglévők közül. A szinkronizálás időpontját úgy célszerű meghatározni, hogy egy megadott perióduon belül minden szerverre sor kerüljön. A frissítés nem lehet túl sűrű, mert akkor a szerverek idejük jó részét frissítéssel töltik és nem lehet túl ritka sem, mert akkor az egyes frissítések túl sokáig tarthanak, márpedig addig a szerver nem használható másra.