Frissítve: 2021 október 6.
Miről szól ez a cikk?
Az adatbázis-kezeléssel kapcsolatos ismeretek megalapozásával rátérhetünk néhány olyan témára, amelyek egy kicsit magasabbról szemlélik vagy mélyebben érintik a megszerzett ismereteket, valamilyen szempontból kapcsolódnak azokhoz, kiegészítik vagy megkönnyíthetik a fogalmak és az összefüggések megértését. Emiatt a cikk fejezetei nem feltétlenül logikus sorrendben követik egymást és témájukban nem is feltétlen kapcsolódnak közvetlenül egymáshoz.
Tartalomjegyzék
1. Adatbányászat
Ahogy a számítógép létrejötte magával hozta a különféle szakmákat, úgymint a programozók, rendszertervezők, számítógép grafikusok, számítógéppel segített tervezéssel foglalkozók, honlapkészítők, modellezők, úgy az adatbázisok és adatbázis-kezelők létrejötte is új szakmák kialakulását eredményezte.
Ebben a fejezetben egy ilyen új szakmáról, az adatbányászatról lesz szó. Természetesen számos más adatbázis-kezeléssel kapcsolatos szakma létezik ma már (adatrögzítő, adatmodellező, adatbázis tervező, operátor, adatbázisgazda, programozó, webmester stb.), de ezt azért tartjuk érdemesnek külön kiemelni, mert új és nagy jövő előtt álló szakma.
A számítógépek, az internet, a webes szolgáltatások, az okoseszközök, a dolgok internete hétköznapivá válása, és az élet minden területére bevonulása miatt óriási mennyiségű és méretű adatbázisok keletkeztek világszerte. Ezzel párhuzamosan megkezdődött az egyes adatbázisok összekapcsolása is, gondoljunk az állami és céges nyilvántartó, egészségügyi, igazságügyi, katonai, kutatói, média, GPS térkép és az azokon alapuló, árukatalógus, leltár és más adatbázisokra! Az adatbázisokat nem csak a szervezeten belül, hanem a szervezetek, vállalatcsoportok, nemzetek, társulások, kontinensek között is összekötötték. Bárhogy is történt, az adatbázisok deklarált célú kezelése mellett a szakemberek rájöttek arra, hogy az óriási mennyiségű és méretű adathalmazokból további információk nyerhetők ki akár kutatási, akár vállalatirányítási céllal.
Az ezzel foglalkozók tehát összefüggéseket, új kinyerhető információkat keresnek különféle matematikai, statisztikai, vagy egyszerű adatbázis kezelő műveletek segítségével.
Ők az adatbányászok, akik adatbányászással foglalkoznak (data mining).
Az adatbányászat célja a nagy mennyiségű adatban rejlő információk félautomatikus feltárása különféle algoritmusok alkalmazásával.
Az adatbányászatnak több definíciója ismert és elfogadott. Magyarországon a leggyakrabban adatbányászat alatt újszerű, érvényes, nem triviális és vélhetően hasznos és magyarázható összefüggések keresését értik nagy adathalmazban.
Más megfogalmazásban az adatbányászat célja érdekes, értékes, értelmes összefüggések keresése nagy adathalmazokban.
Az adatbányászatnak tehát egyik eleme az adatbázis, a rendezett adathalmaz, másik eleme a mindware, vagyis az ész, a kutatás célját szolgáló algoritmusok, vagyis keresőelvek. A szakmának kiterjedt szakirodalma van, és igen becses emberi erőforrásnak számít az adatbányász.
2. Az adatbázis hitelessége
Egy adatbázis akkor használható, ha hiteles, vagyis a benne lévő adatok naprakészek és hibátlanok. Ezért mindig fontos, hogy az adatbázist rendszeresen aktualizálják, adatait frissítsék, vagyis karbantartsák.
A hibák több forrásból származhatnak: adódhatnak például elgépelésből, hiányosak lehetnek adatok, hiányozhatnak adatok, vagy lehetnek tévesek is, sőt, el is avulhatnak. Ezért mindig fontos az adatbázis rendszeres ellenőrzése, karbantartása.
Sokszor megtörténik, hogy az adatbázis létrehozását követően elfeledkeznek annak karbantartásáról, illetve úgy vélik, arra kár erőforrást szánni. Sajnos számos esetben halnak el jó kezdeményezések, munkakörök, mert az adatbázis tulajdonosa nem szán erőforrást adatbázisa hitelességének megőrzésére.
3. Redundancia az adatbázisban
A redundancia ismétlődést jelent. Az adatbázisok esetében olyan ismétlődő, több példányban meglévő adatot értünk alatta, amelynek tárolása nem lenne szükséges. Gondolhatjuk, hogy az ilyen adatok rögzítését, tárolását el kell kerülnünk. Például kerülendő, hogy egy telefontulajdonos vagy egy leltéri tárgy kétszer vagy többször szerepeljen egy táblában, két vagy több rekord is tartalmazza ugyanazon adatokat.
A redundancia tehát káros az adatbázisban, mert feleslegesen növeli az adatbázis méretét, valamint hibalehetőséget hordoz. Például, ha egy adatmódosításból kimarad a többi példány, vagy a több példány megléte meghamisítja a számszerű lekérdezések eredményeit, akkor az adatbázis többé nem tekinthető hitelesnek.
Az adatbázis adatmodelljének tervezésekor nagy hangsúlyt kell fordítanunk arra, hogy elkerüljük az ismétlődő adatok rögzítését. Egyszerű adatbázis készítésekor természetesen szándékosan kikerülhetjük ezt a szabályt, más esetben a megoldás több tábla és/vagy adatbázis készítése és közöttük a megfelelő kapcsolat, reláció kialakítása.
4. A közvetlen adatcsere lehetőségei egy adatbázis-kezelőben
Közvetett adatcserére jó példa a szabványos, kompatibilis adatállományok használata, vagy az exportálás és az importálás, amikor két alkalmazás között fájlok mentésével és megnyitásával cserélünk adatot. Közvetlen adatcserére akkor kerülhet sor, amikor az operációs rendszer és/vagy az alkalmazás beépített szolgáltatása teszi lehetővé két alkalmazás között az adatcserét.
Mivel a korábbi cikkek többször is említették ezen szolgáltatásokat, célszerűnek tartottuk röviden összefoglalni az ezekkel kapcsolatos alapismereteket.
- Az operációs rendszer vágólapja által biztosított adatcsere lehetősége, minősége függ az átadó, exportáló, illetve a befogadó, importáló alkalmazástól. Mindkét félnél előre programozott, meghatározott lehetőségek kell álljanak rendelkezésünkre, amelyek az alkalmazások jellegétől és a programozók szándékaitól függenek. Például, egy Word szövegszerkesztőből vágólapra másolt bekezdés formátumjegyei nem fognak megjelenni a Jegyzettömb alkalmazásba beillesztve, vagy egy Access lekérdezés átemelése Excel munkalapra is okozhat nehézségeket. A korlátokkal tehát a felhasználónak kell tisztában lennie a vágólap használatakor.
-
Az OLE (Object Linking and Embedding, magyarul objektum hivatkozás és beágyazás) szoftvertechnológiát a Microsoft fejlesztette ki és építette be elsőként alkalmazásaiba, hogy megkönnyítse a közvetlen adatcserét azok között. Lényege a programok között a megosztás (exportálás és importálás) feladatait ellátó szoftverkomponensek elérhetővé tétele a Windows rendszeren. Az OLE erre kétféle megoldást nyújt, ahogy arra a rövidítés is utal: a hivatkozást és a beágyazást.
A hivatkozás (linking) során a vágólapról beillesztett objektum továbbra is kapcsolódik a forráshoz, kapcsolata megmarad a forrással. Például egy Word dokumentum beágyazott Excel táblázat esetén nem csak maga a táblázat kerül be a dokumentumba, hanem rögzítésre kerül a forrás(fájl) neve és helye is. Így, ha módosul a forrás, akkor az átvezetésre kerül a beágyazott és linkelt táblázatban is.
A beágyazás (embedding) során a beágyazott objektumot létrehozó alkalmazás szoftverkomponensei azonosításra és rögzítésre kerülnek a befogadó alkalmazásban. Ennek következtében a forrásanyag a befogadó alkalmazáson belül válik szerkeszthetővé, nem kell külön megnyitni a forrásanyagot előállító alkalmazást és benne megnyitni a forrásfájlt.
Az előbbi példához visszatérve, ha a megnyitott Excel munkafüzet táblázatát beágyazzuk egy Word dokumentumba, akkor ezt a táblázatot a dokumentumban szerkeszthetjük úgy, hogy a Wordben megjelennek az Excel szolgáltatásai (menüszalagja). - A DDE (Dynamic Data Exchange, vagyis dinamikus adatcsere) feladata a futó alkalmazások közötti dinamikus adatcsere biztosítása. Szerepe hasonló az OLE-hez.
- Az ODBC (Open DataBase Connectivity, nyílt adatbázis elérés) egy nyílt, szabványos adatbázis hozzáférési módszer. A Microsoft által kifejlesztett ODBC célja, hogy lehetővé tegye bármely adatbázis elérését bármilyen programból, függetlenül attól, hogy az adatbázist milyen adatbázis-kezelő rendszer kezeli. Az ODBC tehát egy közbülső szoftverkomponens réteget alkot az adatbázis és az alkalmazás között. E réteg feladata az, hogy a lekérdezést kezdeményező alkalmazás kérését úgy alakítsa át, hogy azt az adatbázis-kezelő program megértse, fel tudja dolgozni, válaszolni tudjon rá. Ebből következik, hogy mind az alkalmazásnak, mind az adatbázis-kezelőnek ODBC-kompatibilisnek kell lennie. A programnak képesnek kell lennie az ODBC parancsokat kiadni, az adatbázis kezelőnek pedig tudni kell válaszolni ezekre.
5. Az adatbázis fájl és az adatbázis-kezelő kapcsolata
Az adatbázis-kezelő alkalmazások az adatbázist egy (vagy több) meghatározott belső elrendezésű fájlként mentik a háttértárra. A fájlok belső felépítése alkalmazásfüggő, ezért beszélhetünk adatbázis formátumokról. Az adatbázis-kezelő alkalmazás és az általa létrehozott adatbázis tehát szorosan összetartozik – az adatbázist csak az azt létrehozó alkalmazás tudja kezelni.
Ha egy adatbázis-kezelő el akart terjedni a piacon, akkor azt a mások által fejlesztett adatbázis-kezelő alkalmazások által kezelt adatbázis formátumok, fájlok kezelésére is fel kellett készíteni – hasonló ez az igyekezet ahhoz, amikor más irodai csomagok kezdték el kezelni a Microsoft Word dokumentumait vagy az Excel munkafüzeteit.
A különféle fájlformátumokkal kapcsolatos problémák elkerülése érdekében, valamint az egyes szoftvercégek piaci súlya és/vagy szabványosítási törekvéseinek következtében az évek alatt számos iparági és nyílt fájlformátum szabvány alakult ki. A szabványosítási törekvések a nyílt (cégektől független, szabványosított, előírt) formátumok bevezetését szorgalmazták, akárcsak a szövegszerkesztő vagy más típusú fájlok esetében. A piaci szereplők igyekeznek alkalmazkodni ehhez az elvhez, így a legelterjedtebb adatbázis-kezelő alkalmazások által bevezetett fájlformátumot a legtöbb alkalmazás képes kezelni.
6. Az adatbázisok osztályozása
Az adatbázisokat több szempont szerint csoportosíthatjuk, osztályozhatjuk. Vegyünk sorra néhányat!
-
Az adatbázis lehet logikai vagy fizikai.
A logikai adatbázis az, amit látunk. A „látható” adatbázist a lekérdezés, indexelés, szűrés, űrlap szolgáltatja. A mit és hogyan akarunk látni kérdésekre adja meg a választ.
A fizikai adatbázis az, ami fájlként a háttértárra kerül. Mint korábban említettük, az adatbázis fájl formátuma, felépítése alkalmazás-, illetve ma már többnyire szabványfüggő. - A logikai adatbázisokat szerkezetük, felépítési és működési sajátosságai alapján szokás tovább csoportosítani. A szerkezeti és működési leírásnak a legáltalánosabb alakját adatmodellnek (data model) nevezzük. Az adatmodell eltérései alapján beszélhetünk egyszerű (flat), relációs, objektumorientált, hálós, deduktív, illetve objektumrelációs, deduktív relációs, deduktív objektumorientált stb. adatbázisokról. A korszerű adatbázis-kezelőkben gyakran előfordul, hogy ugyanazt a fizikai adatbázist több, különböző logikai adatbázison keresztül is elérhetjük, így ugyanazt az adatot például relációs és objektumorientált technológiával is kezelhetjük.
-
A következő csoportosítási szempont az adatbázis strukturáltsága. E szerint megkülönböztetjük az azonos és a változó attribútumszámú adatbázisokat (változó számú mezővel rendelkező rekordok). A változó attribútumszámú adatbázisok létjogosultságát az indokolja, hogy alkalmazásukkal bizonyos információk jóval tömörebben és egyszerűbben tárolhatók és fejezhetők ki.
Például, ha egy telefonkönyvben egy személyhez több telefonszám tartozik, akkor a rögzített és a változó attribútumszámú adatbázisok az alábbi módon tárolnák az információt:
A rögzített attribútumszámú adatbázis minden új telefonszámhoz új rekordot tartalmaz, benne a tulajdonos azonosítójával és a következő telefonszámmal. Látható, hogy ez a megoldás redundáns adatokat tartalmaz és emiatt nagyobb méretű adatbázist eredményez. Az sem megoldás, ha a pl. minden rekord legalább annyi telefonszámot képes tárolni, amennyi a legtöbb telefonszámmal rendelkezőnek van, mert ebben az esetben ugyan megszűnik a redundancia, de az üres mezők növelni fogják az adatbázis méretét.
A változó attribútumszámú adatbázis esetén minden telefonszám tulajdonoshoz csak egy rekord tartozik, annyi mezővel, ahány telefonszáma van. Tehát a rekordok eltérő számú mezőből áll(hat)nak.
7. Az adatmodell definíciója és jellemzői
Az adatmodell a logikai adatbázis szerkezeti leírását foglalja magában, előírja az adatok típusát, kapcsolatát, a korlátozó feltételeket és az adatkezelő műveleteket is.
Az adatmodell szerkezeti és műveleti részből tevődik össze. Az adatmodell feladata, hogy a világban található dolgokról, individuumokról számítógéppel könnyen feldolgozható, formálisan leírható adatok tárolásához megfelelő szerkezetet, keretet adjon, illetve ezek lekérdezhetőségét, visszakeresését is biztosítani tudja.
Ahogy az előző fejezetben írtuk, az adatmodell szerkezete lehet egyszerű (flat), relációs, objektumorientált, hálós, deduktív, illetve objektumrelációs, deduktív relációs, deduktív objektumorientált stb. A mindennapokban egyszerű és relációs adatmodell alapján készült adatbázisokkal találkozunk.
Fontos megemlíteni, hogy az adatmodell műveletei kizárólag a logikai értelmű lekérdezésre koncentrálnak (indexelés, szűrés); a beszúrás, törlés, módosítás, illetve az információ háttértárról való betöltése, visszakeresése nem az adatmodell, hanem az adatbázis, ezen belül is a fizikai adatbázis feladata, illetve művelete.
Összetett feladatok megoldásához adatmodellező alkalmazásokat hoztak létre, amelyek segítségével a képernyőn, grafikusan vált lehetővé az adatmodell elkészítése. Ezen alkalmazások kimenete, végterméke a kívánalmaknak megfelelő logikai és fizikai adatbázis. Az adatmodellező alkalmazásoknak belső programozási nyelve is van, amellyel szövegesen is leírható, létrehozható, kezelhető az adatmodell. Így az adatmodellező alkalmazások alkalmasak bármilyen bonyolultságú adatmodell leképezésére.
8. A relációs adatmodell jellemzői
Ahogy említettük, a mindennapokban egyszerű és relációs adatmodellel bíró adatbázisokat kezelő alkalmazásokkal találkozunk. Ezért először érdemes összefoglalni a relációs adatmodell jellemzőit, majd a következő fejezetben összehasonlítani az egyszerű és a relációs adatmodellel rendelkező adatbázisokat.
A relációs adatmodellnél az attribútumok (mezőtulajdonságok) kapják a fő hangsúlyt, vagyis a tulajdonságokkal határozzuk meg az adatmodell szerkezetét. A relációs adatmodellben az egyedet egy tábla jelképezi, a tábla oszlopai a tulajdonságok, sorai pedig az egyed értékei. Ha az egyed leírására több táblára van szükség, akkor többet hozunk létre, és közöttük egy vagy több kapcsolatot, relációt definiálunk.
A relációs adatmodellben tehát az adatokat egymással logikai kapcsolatban álló táblákba rendszerezzük, közöttük lévő logikai kapcsolatot, relációt pedig definiált tulajdonságok teremtik meg.
A táblák oszlopainak és sorainak a következő feltételeknek kell megfelelniük:
- A táblákat a nevük egyértelműen azonosítja.
- Minden oszlopnak egyedi neve, azonosítója van.
- Minden sorban ugyanazok az oszlopok vannak, ugyanabban a sorrendben, tehát a tábla strukturáltság alapján azonos attribútumszámmal rendelkezik.
- Az oszlopokban található adatok meghatározott adattípusú értéket vehetnek fel.
- Az oszlopok soronként csak egy értéket vehetnek fel (elemi adat!).
A fenti definíciók a korábbi cikkekben olvasottak alapján remélhetőleg ismerősek.
9. Az egyszerű és a relációs adatbázis
Hasonlítsuk össze most már az egyszerű és a relációs adatmodellel rendelkező adatbázisokat!
Mint már többször említettük, a mindennapokban az egyszerű (flat) és a relációs (relational) adatmodellen alapuló adatbázisokkal és az azokat kezelni képes adatbázis-kezelő alkalmazásokkal szoktunk találkozni. A kommersz vásárlói igényeket kiszolgáló irodai programcsomagok részét képező adatbázis-kezelők, mint például a Microsoft Access is ilyen szoftver, míg az egyszerű adatmodellen alapuló igényeket sokszor lefedik az olyan táblázatkezelő alkalmazások, mint például a Microsoft Excel.
Az egyszerű adatmodellt igénylő adatbázisok tehát kezelhetők a Microsoft Excellel is. Ezt kihasználva sokaknak gyakorlata, hogy az adatmodellt az adatbázis-kezelőben hozzák létre, az adatokat viszont Excelben rögzítik, majd importálják a táblába.
Egy másik szempont: sokan csak addig dolgoznak egyszerű adatbázissal Excelben, amíg a munkalap sor- és oszloplimitjét vagy az Excel fizikai és teljesítménybeli korlátait el nem érik. No meg azért is, mert számos adatbázis művelet egyszerűbben elvégezhető Excelben, mint az Accessben.
Nos, nézzük hát, mik a legfontosabb jellemzőik az egyszerű és a relációs adatmodellű adatbázisoknak.
- Az egyszerű adatbázis egy táblából áll, általában rögzített attribútumszámú (korlátozott számú mező).
- A relációs adatbázis több táblából áll. A táblák ugyanazon vagy egymástól független egyedek különböző attribútumait tartalmazzák. A táblákat logikai kapcsolatot teremtő mezők, relációk kötik össze.
Nézzünk egy példát relációs adatbázisra, és olvasás közben alaposan rágjuk meg a leírtakat! Egy leltár adatbázis tartalmazhat egy táblát a leltári tételekről, és egy táblát a helyiségekről. Belátható, hogy ez egy hasznos adatmodell, mert ha egy táblánk lenne, akkor számos helyiségjellemző adata, például a helyiségek száma, többször is előfordulna a leltári tételek táblában, ez pedig redundanciát eredményez. Hogy ezt elkerülhessük, a helyiségek attribútumait célszerű külön táblában tárolni. A két tábla közötti logikai kapcsolatot, relációt egy-egy olyan mező teremtheti meg, amely a helyiségszámot tartalmazza – ezen mezők neve, adattípusa azonos. A reláció definiálását követően a leltári tételek táblában lévő helyiségszám mező valójában nem magát az adatot, hanem a helyiségek tábla megfelelő rekordjának helyiségszám mezőjére mutató hivatkozást tartalmazza. A leltári tételek rögzítésekor a helyiségszám mezőt egy olyan választéklistából töltjük ki, amely a helyiségek tábla helyiségszámait sorolja fel – ne feledjük, a helyiségek táblában minden helyiségnek csak egy rekordja van!
Ha egy adatbázisban több táblánk van, amelyek rekordjai között mezőkben tárolt logikai hivatkozások, relációk teremtik meg a kapcsolatot, akkor azt az adatbázist relációs adatbázisnak nevezzük.
Ma már minden adatbázis-kezelő kezeli a relációs adatbázisokat, ezért nevezik ezeket Relációs Adatbázis-Kezelő Rendszereknek (RABKR), angolul Relational Database Management System, rövidítve RDBMS szoftvereknek.
10. Ügyfél és kiszolgáló RDBMS-ek
Az egyszerűbb feladatok végzéséhez a Microsoft az Office irodai csomag részeként az Access adatbázis-kezelő szoftvert bocsátja a felhasználók rendelkezésére. Az Access alkalmazásával számos összetett feladat is megoldható, akár irodai, vállalati környezetben is. Az Accesshez hasonló szoftverekre a kevés számú felhasználó a jellemző. A piacon számos más ingyenes és fizetős, asztali vagy webböngészőn keresztül használható, ún. ügyféloldali adatbázis-kezelő alkalmazás kapható, amelyeknek közös jellemzőjük, hogy minden szoftverkomponensük az ügyfél, vagyis a felhasználó saját számítógépén fut.
Komoly feladatokra adatbázis kiszolgáló szoftvereket alkalmaznak, amelyek már igen erős hardverrel rendelkező kiszolgálókon és különféle informatikai eszközökkel megtámogatva működnek, többmilliós, milliárdos rekordszámmal. Ide sorolhatók például a webshopok, a vállalati ügyfélrendszerek, a számlázó alkalmazások, a mindenféle egyéb nyilvántartások (dolgozói, vevő, szállító, termék, áru stb.). Az adatbázis kiszolgálókra jellemző, hogy akár intranetes (házon belüli internetes technológiákra épülő helyi hálózatos, LAN), akár internetes környezetben lekérdezések ezreit, millióit képesek kiszolgálni másodpercenként. Az adatbázis és az azt kezelő szoftverkomponensek a nagyteljesítményű kiszolgálón helyezkednek el, a felhasználók pedig egy ún. ügyféloldali, kliens alkalmazással hálózaton keresztül érik el az adatbázist. Ez az ügyféloldali alkalmazás lehet egy böngészőprogram, egy szövegszerkesztő, egy táblázatkezelő, vagy akár egy ügyféloldali adatbázis-kezelő alkalmazás. Az elérés történhet közvetetten is például vágólap, OLE, ODBC vagy DDE segítségével.
Az ügyfélrendszereket egyszerű használni, a felhasználó a rendszer minden szolgáltatását azonnal és korlátozás nélkül elérheti és kezelheti. A kiszolgálóknál már jogosultságok vannak, jellemzően az adatbázis adminisztrátor és munkatársaik kezelik magát a kiszolgáló szoftvert, finomhangolják, ellenőrzik annak működését. A kiszolgálókon sok esetben nem is egy, hanem párhuzamosan több adatbázis szokott futni, ezeknek mind szokott lenni adminisztrátora, fejlesztője és karbantartója.
Meg kell említenünk egy köztes megoldást is, amikor az ügyfél számítógépén a háttérben fut a kiszolgáló. Nyilván kisebb teljesítményt nyújt, de kiszolgálói környezetet igénylő alkalmazásoknál, fejlesztéseknél hasznos ez a megoldás.
11. Az adatbázis tervezésének lépései
Nézzünk egy gyakorlati témát, az adatbázis tervezését! Amíg egyszerű dolgunk van, egyszerű Excel listával vagy Access adatbázissal kell dolgoznunk, a tervezéssel többnyire nem lesz gondunk. Komolyabb feladattal, relációs adatbázis kialakításának igényével szembesülve azonban jól jön majd az alábbi sorvezető.
-
Az adatbázis rendeltetésének meghatározása.
Az adatbázis-tervezés első lépése az, hogy meghatározzuk, mi az adatbázis rendeltetése és hogyan fogjuk használni. Tehát a cél és a felhasználás módjának tisztázása az első teendő. Ehhez beszélnünk kell a leendő felhasználókkal, be kell gyűjtenünk az adatok hagyományos használata közben alkalmazott lekérdezéseket, űrlapokat, tapasztalatokat, igényeket, munkameneteket. Meg kell fogalmaznunk, hogy az adatbázissal milyen munkafolyamatokat váltunk ki, kinek, mi lesz a feladata az adatbázissal való munka folyamán, hogyan változnak meg a korábban megszokott munkafolyamatok, és a legfontosabb: milyen előnyei származnak ebből a munkatársak és a vezetők számára.
Az adatbázis céljának meghatározása után az adatbázistól várt adatok listájának összeállítása következik. Ebből megállapítható, hogy milyen tényeket kell tárolni az adatbázisban, és hogy ezek milyen témakörökbe tartoznak. A tények (pl. vevők, szállítók adatai, eladásoknál rögzítendő adatok stb.) az adatbázis attribútumait (oszlopait, mezőit) határozzák meg, míg a tényekhez tartozó témakörök (pl. vevők, szállítók, eladások) a szükséges táblákkal állnak kapcsolatban. -
A mezők és tulajdonságaiknak meghatározása.
Minden mező lényegében attribútum egy adott témakörből. Például a vevőkről a következő attribútumokat kell tárolni: vállalat neve, címe, város, ország és telefonszám. Minden attribútumhoz külön mezőt kell létrehozni. A szükséges mezők meghatározásakor a következő tervezési elveket kell szem előtt tartani:
- Vegyünk fel minden szükséges adatot.
- Az adatokat a lehető legkisebb logikai egységekben tároljuk. Például a személyek nevét minimum két mezőre bontjuk (vezeték- és utónév). Ugyanígy járjunk el a megszólításokkal (Hölgy, Úr, Hajadon) a címekkel (dr., prof.), a beosztásokkal (igazgató, főosztályvezető, ügyintéző, elnök) és a rangfokozatokkal (ezredes, hadnagy, őrnagy) kapcsolatban.
- Ne hozzunk létre mezőket több elem listáját tartalmazó adatokhoz (pl. ÁFA értékek, eladható áruk, helyiségszámok, szobák), elkerülve a redundanciát. Ha ilyen adatokkal találkozunk, akkor azonnal relációs adatmodellre kell áttérnünk, és az ilyen listákat külön táblák fogják tartalmazni.
- Ne vegyünk fel származtatott vagy számított adatokat. Például ne hozzunk létre mezőt a bruttó árnak, ha tároljuk a nettó árat és az ÁFÁ-t.
- Ne hozzunk létre egymáshoz hasonló mezőket, hanem helyezzük azokat az adatokat külön táblába (pl. termékek listája).
A fő szempont tehát a lehető legtöbb önálló adat rögzítése a redundancia elkerülésével. -
A táblák meghatározása.
Ha kiderül, hogy relációs adatmodellben kell gondolkodnunk, akkor a következő lépés a táblák meghatározása. Minden egyes táblában csak egy adott témára vonatkozó adatok szerepeljenek. Az attribútumok listája általában megadja a szükséges táblákat is. Ez majdnem azonos a következő lépéssel, amelyben a mezőket osztjuk szét a táblák között, de itt és most még csak a szükséges táblákat határozzuk meg. -
A mezők szétosztása a táblák között.
A mezők táblákba sorolásakor a következő szempontokat érdemes szem előtt tartani:
- Egy mezőt csak egy táblába vegyünk fel.
- Ne vegyük fel a mezőt a táblába, ha ennek eredménye ugyanazon adat megjelenése lesz a tábla több rekordjában. Ha a táblában egy mező sok ismétlődő adatot tartalmaz, akkor ez a mező valószínűleg rossz táblába került.
Ha például egy Vevő Címét tartalmazó mezőt a Rendelések táblába vesszük fel, a Vevő Címe minden bizonnyal egynél több rekordban is elő fog fordulni, hiszen a Vevő egynél több rendelést fog feladni. Ha viszont a Vevők táblában helyezzük el a Vevő Címe mezőt, akkor abban csak egyszer fog megjelenni.
Ha minden adatot csak egyszer tárolunk, akkor csak egyetlen helyen kell frissíteni. Ez hatékonyabb eljárás, és így kizárjuk az adatok többszörös beírásának lehetőségét, elkerüljük a redundanciát és könnyebben tudjuk biztosítani az adatbázis hitelességét. -
Az elsődleges kulcsok meghatározása és a táblák logikai összekapcsolása, a relációk definiálása.
Két tábla összekapcsolásához mindkettő táblában lennie kell egy olyan mezőnek, amely egyedileg azonosítja a tábla összes rekordját. Ennek a mezőnek a neve elsődleges kulcs.
Ha kettőnél több táblánk van, vagy egynél több relációt kell létrehoznunk, akkor egymás után mindegyiket létre kell hoznunk a fenti eljárást ismételve.
Így előfordulhat, hogy egy tábla több másik táblához is kapcsolódik. Ebben az esetben értelemszerűen minden kapcsolathoz önálló mezőt kell létrehoznunk.
A kapcsolatokat az adatbázis készítése során fogjuk majd a programban megadni. -
Utolsó simítások.
A mezők, táblák, elsődleges kulcsok és kapcsolatok megtervezése után át kell néznünk a tervet, hogy nem maradt-e benne hiba. Könnyebb az adatbázis tervét most megváltoztatni, mint a táblák adatokkal való feltöltése után.
Ezt követően hozzuk létre a táblákat az adatbázis-kezelő alkalmazásban, határozzuk meg a táblák közötti kapcsolatokat, és írjunk a táblákba elegendő mintaadatot ahhoz, hogy ellenőrizhessük a tervet. Az adatbázis kapcsolatainak teszteléséhez nézzük meg, hogy lekérdezések készítésével a kívánt válaszokat kapjuk-e. Készítsük el az űrlapok és a jelentések vázlatos terveit, hogy lássuk, a várt adatok jelennek-e meg bennük. Ismét nézzük meg, nem maradtak-e felesleges adatismétlődések, és ha vannak ilyenek, akkor tervezzük újra az adatmodellt. -
Adatok bevitele és egyéb adatbázis-objektumok létrehozása.
Ha a tesztelést követően úgy gondoljuk, hogy a terv megfelel a célnak, hozzáfoghatunk a táblák éles adattal történő feltöltéséhez, egyben létrehozhatjuk az egyéb adatbázis-objektumokat, a tárolt indexeket, szűréseket, űrlapokat és jelentéseket.
12. A tesztelésről röviden
Az adatbázis (szoftver) tesztelés külön szakma, könyvtárnyi irodalommal, célszoftverekkel a mintaadatok létrehozásához, a teljesítmény méréséhez (pl. indexeléshez, keresésekhez, szűrésekhez), az adatbázis sokkolásához, hibatűrésének megállapításához, a tervezési hibák, redundanciák kiszűréséhez stb.
Egyszerű adatbázisok esetén ezekre nyilván nincs szükség, sem lehetőség, így marad a saját tesztadat összeállítás. A felhasználói, félprofi adatbázis-kezelés örök problémája ez, a megfelelő mennyiségű tesztadat előállítása.
Ehhez kitűnően alkalmas az Excel táblázatkezelő alkalmazás, amelyben számos (pl. véletlenszám generátor) függvény segítségével több tíz-százezer, milliónyi rekordot tudunk létrehozni. Ha rendszeres feladatunk tipikus, adott témakörbe vágó adatbázisok készítése, akár tanulás, akár tesztelés céljából, akkor érdemes saját minta adathalmazokat összegyűjteni (nevek, termékek, országok, címek, áruk stb.). A gyűjtést jelentősen megkönnyíti az internet – a webshopok árukészlete, a különféle tematikus listák könnyen megtalálhatók a keresők segítségével.
A mintaadatok készítésekor törekedjünk szélsőséges, hamis adatok rögzítésére is, amelyekkel tesztelni tudjuk a mezőtulajdonságokat.
13. Teljesítménybefolyásoló tényezők, a teljesítmény növelése
Mivel adatbázis-kezelés közben igen nagy mennyiségű és méretű adathalmazokkal találkozhatunk, nem hiábavaló röviden áttekinteni az adatbázisnak az adatbázis-kezelő rendszer teljesítményére kiható tényezőit. Természetesen ennek is könyvtárnyi irodalma van, szakemberek szentelik munkásságukat ezen témakörnek, így mi csak úgy szőrmentén érintjük a témát.
Mi lehet a teljesítménymutató egy adatbázis esetében? A válasz az, hogy az adatbázis mérete, adatmodellje, a redundancia hiánya és az adatok elérési, feldolgozási sebességét segítő tárolt objektumok megléte.
Az adatbázis-kezelő rendszer teljesítményére számos paraméter hat: a számítógép hardvere (CPU, memória, tárterület típusa és nagysága, hálózati sebesség), az adatbázis-kezelő rendszer képességei, valamint maga az adatbázis a teljesítményt befolyásoló tényezőivel.
A teljesítményre leginkább a nagyvállalati, hatalmas méretű, több milliónyi rekordot, illetve táblák, mezők, lekérdezések, űrlapok, kapcsolatok stb. százait tartalmazó relációs adatbázisoknál kell figyelnünk, ahol a hardver és a kiszolgáló szoftver teljesítménye a meghatározó. A magán és mikro-, KKV (kis- és középvállalati) felhasználás esetén azonban a jól megtervezettség szempontjai a leginkább teljesítménybefolyásoló tényezők.
Soroljuk fel tehát a legfontosabb szempontokat:
-
A beépített teljesítményanalizáló eszközök használata.
Az Access is tartalmaz több olyan szolgáltatást, amellyel adatbázisunkat, tábláinkat tudjuk elemeztetni. Ezek a szolgáltatások rávilágítanak a tervezési hibákra, a redundanciára, illetve tanácsokat adnak a teljesítmény növelésére. -
A hardver teljesítményének helyes megválasztása.
Belátható, hogy az adatbázisok kezelését jelentősen megkönnyíti egy nagy számítási teljesítménnyel bíró többmagos, többszálú, magas frekvencián működő processzort, sok gigabájtnyi RAM memóriát, gyors és nagykapacitású háttértárakat tartalmazó rendszer. Ezek ma már egy egyszerű irodai gépen is rendelkezésre állnak. Komoly igények esetén több processzor, és speciális, redundáns tömbbe szervezett (RAID) merev- illetve SSD-lemezek jönnek szóba. Az ilyen számítógépek például már egy komolyabb webáruházat is ki tudnak szolgálni több száz-ezer felhasználó egyidejű kiszolgálásával, hatalmas rekordszámú adatbázissal. -
Az adatbázis-kezelő rendszer kiválasztása.
Ügyféloldali alkalmazás esetén az asztali adatbázis-kezelő rendszerek a megfelelő választás, mint például az Access, míg komoly alkalmazás esetén a különféle adatbázis kiszolgáló szoftverek jelentik a következő lépcsőfokot, pl. a Microsoft SQL Server vagy a MySQL. -
A táblák, lekérdezések optimalizálása terén a következőkre ügyeljünk:
Tervezzünk redundáns adatok nélküli táblákat. A jól megtervezett adatbázis az adatok gyors visszakeresésének és frissítésének előfeltétele.
Válasszuk ki a mezők számára a legmegfelelőbb adattípusokat. Ezzel nemcsak lemezterületet takaríthatunk meg, hanem javíthatjuk az illesztési műveletek hatékonyságát is. Amikor definiálunk egy mezőt, a mezőben lévő adatokhoz a még alkalmas legkisebb méretű adattípust vagy mezőméretet válasszuk.
Készítsünk indexeket azokhoz a mezőkhöz, amelyek szerint rendezni fogunk, vagy amelyekhez feltételeket állítunk be. Látványosan növelhetjük a lekérdezések sebességét, ha előre indexeljük a mezőket. Ha mezők között kapcsolatot létesítünk, akkor minden olyan mezőt indexeljünk, amelyeket a lekérdezésben feltételek beállítására használunk. - Hozzunk létre tárolt indexeket és szűréseket minden lehetséges esetre gondolva. A mezők indexei mellett kombinált, több mezős sorba rendezések és összetett feltételeket tartalmazó szűrések, riportok előzetes tárolása esetén azokat az adatbázis-kezelő rendszer folyamatosan napra készen tartja, aktualizálja, így alkalmazásukkor csak a kész találatlistát kell megjeleníteni.
- A formázott megjelenítéshez készítsünk űrlapokat. Ha az eredményeket párbeszédablakos, űrlapos formában akarjuk, kell láttatni, esetleg számos számított mezőt is meg akarunk, kell jeleníteni, akkor készítsük el az összes űrlapot, rendeljük azokhoz a megfelelő lekérdezéseket, készítsük el a számított mezőket, és mentsük azokat is az adatbázisba. Az adatbázis-kezelő alkalmazás ezeket is a háttérben folyamatosan napra készen fogja tartani.
VÉGE.
Infopanel
Készült: 2019 szeptember 21.
Szint: kezdő, ECDL modul/tanmenet: Adatbázis-kezelés/S6/1.2
Kategória: Adatbázis-kezelés → Az adatbázis ismerete → Adatbázis elrendezése
![Frissítés: a PowerToys v0.68.x újdonságai [#205]](https://www.fiatluxefel.info/wp-content/uploads/2022/09/BejegyzesFaceTwitter-Microsoft-PowerToys-frissites-300x156.png)
![Frissítés: Office-téma automatikus igazítása a Windows témához [#65]](https://www.fiatluxefel.info/wp-content/uploads/2020/11/BejegyzesFaceTwitter_MSOffice36520162019frissites_2-300x157.png)
![Eljárt az idő a Microsoft Office 2010 felett [#49]](https://www.fiatluxefel.info/wp-content/uploads/2020/10/BejegyzesFaceTwitter_MSOffice2010frissites_1-300x157.png)
![Tipp: alkalmazások automatikus újraindítása bejelentkezés után [#52]](https://www.fiatluxefel.info/wp-content/uploads/2020/10/BejegyzesFaceTwitter_Tippekestrukkok_1-300x157.png)
![Frissítés: a Windows 10 20H2 újdonságai, 1. rész [#54]](https://www.fiatluxefel.info/wp-content/uploads/2020/10/BejegyzesFaceTwitter_MSWindows10frissites_1-300x157.png)
