Vissza az előzőleg látogatott oldalra (nem elérhető funkció)Vissza a tananyag kezdőlapjára (P)Ugrás a tananyag előző oldalára (E)Ugrás a tananyag következő oldalára (nem elérhető funkció)Fogalom megjelenítés (nem elérhető funkció)Fogalmak listája (nem elérhető funkció)Oldal nyomtatása (nem elérhető funkció)Oldaltérkép megtekintése (D)Keresés az oldalon (nem elérhető funkció)Súgó megtekintése (S)

WEB 2-es eszközök a társadalmi és marketingkutatások szolgálatában / Kutatási adatbázisok tervezése és tervezési eszközei

Tanulási útmutató

Összefoglalás

A leckében megismerkedünk az adatbázisokkal kapcsolatos néhány alapfogalommal.

Követelmény

Az Olvasó legyen tisztában az adatbázisokkal kapcsolatos alapfogalmakkal.

Kutatási adatbázisok tervezése és eszközei

Az előző fejezetekben azt vizsgáltuk meg, hogy hogyan tudunk más adataira rátalálni és azokat feldolgozni. Néztük ezt az online keresőszolgáltatások segítségével, és úgy is, hogy saját keresőmotort állítottunk ennek szolgálatába. Ebben a fejezetben annak az alapjaival ismerkedünk meg, hogy mit tegyünk, ha saját magunk szeretnénk az adatokat valamilyen strukturált formában eltárolni. A következő leírásnak azonban nem az a célja, hogy az adatbázisok tervezésének minden csínja-bínjával, matematikai alapokon megismertessük az olvasót, hanem elsősorban az, hogy egy informatikával, adattárolással napi szinten nem foglalkozó szakember meg tudja fogalmazni saját kutatói adatbázisa kialakításához szükséges igényeit, legyen rátekintése a lehetőségeire, ismerje az ide tartozó gyakoribb fogalmakat, és alapvető szinten ugyan, de a fejlesztést-tervezést végző informatikai kollégával megértsék egymás szókincsét.

A következőkben végignézzük az egyes lehetőségeket adatok tárolására kezdve az egyszerűbb, triviálisabb megoldásoktól a bonyolultabbakig. A fejezet végén pedig részletesebben szólunk az adatbázisokról és azok tervezéséhez szükséges fogalmakról.

Feljegyzések szöveges állományba, dokumentumba

A legegyszerűbb megoldás az, ha az eltárolandó információt szöveges állományokban vagy dokumentumokban tároljuk. A feljegyzendő adatokat külön sorokba írjuk, vagy egyéb módon választjuk el egymástól, pl. vízszintes vonallal. Annak érdekében, hogy az információ forrása visszakereshető legyen, minden feljegyzéshez eltárolhatjuk annak forrását (hivatkozás könyvre, cikkre, URL-re), valamint a feljegyzés dátumát is.

Ez a megközelítés az egyszerűbb és rövid távú feladatokra megfelelő, azonban több hátránnyal bír:

Összességében elmondható, hogy sokkal inkább anyaggyűjtésre, jegyzetelésre, vázlatírásra használható ez a módszer.

Vissza a tartalomjegyzékhez

Feljegyző szoftverek

Bár az előző megoldás nagyon egyszerűnek tűnik, mégis manapság újra virágkorukat élik az ezekhez kapcsolódó szoftverek. Ennek egyik oka, hogy a mai világban rengeteg információ éri az embereket, a fontosabbak megjegyzésére megfelelő eszközre van szükség. A másik ok, hogy ezek az információk általában az interneten keresztül érnek el hozzánk, ezért a számítógépet célszerű ezek tárolására használni. A harmadik dolog, amit ezek a szoftverek biztosítanak, hogy jegyzeteinket bárhol elérhessük, ezért általában felhőszolgáltatásként nyújtják a jegyzetelési lehetőséget, és a feljegyzési folyamatot is igyekszik segíteni, gyakran előforduló mechanizmusokat automatizálni. Ez utóbbiak közé tartozik, hogy egy jegyzet írásakor automatikusan feljegyzik annak dátumát, és forrását, sőt lehetőséget adnak további címkék írására is. Mivel manapság sokféle eszközt használva találkozhatunk feljegyzendő adattal, így ezek a feljegyző szoftverek sokféle eszközön és csatornán keresztül érhetők el. Így megjelennek asztali programként, webes kliensként, natív alkalmazásként telefonon, böngészőbe épülő kiegészítőként, stb. A csoportosítás általában kétszintű: a jegyzetek füzetekbe csoportosíthatjuk. Egyszerűbbé válik a visszakeresés is, ugyanis a jegyzeteinket automatikusan beindexelik, így lehetőség van teljes szövegű keresésre, de finomíthatjuk a keresést azáltal, hogy meghatározzuk, hogy mely füzetekben keressen, vagy csak a címszavak között, vagy csak bizonyos dátumig. Általában valamilyen szinten csoportos munkavégzést is támogatnak egyes jegyzetfüzetek közös szerkesztése által.

Manapság két ilyen szoftver nagyon elterjedt erre a célra. Az Evernote programcsalád szinte minden platformon megtalálható (natív asztali alkalmazástól a böngészőn és mobiltelefonokon keresztül a legújabb Windows 8-as alkalmazásig). Felépítése egyszerű: jegyzetfüzetek vannak (notebook) és azokban jegyzetek (note). Egy jegyzet bármi lehet: szöveg, hivatkozás, kép, hang, videó. A visszakeresés gyors, sokféleképpen szűkíthető. Az Evernote a képeken megjelenő szövegeket is felismeri, és azokban is keres. Közös munkavégzés egy jegyzetfüzetben csak fizetős szolgáltatásként érhető el az írás időpontjában.

A másik népszerű program a Springpad. Alapvetően weben keresztül érhető el, de léteznek hozzá böngésző kiegészítők, és használható okostelefonokon is natív alkalmazás formájában. Itt is jegyzetfüzetek vannak és azokban jegyzetek, de a Springpad a jegyzeteket különböző tartalomtípusokba sorolja, és próbálja az azokhoz kapcsolódó folyamatokat automatizálni. Itt az egyszerű szöveges jegyzettömb mellett felvihetünk képeket, recepteket, filmeket, könyveket, és még sok egyebet. Mindegyiknél az adott tartalomtípushoz kapcsolódó szolgáltatások érhetők el. Pl. egy mozi felvitelénél automatikusan felveszi a hivatkozást a megfelelő IMDB bejegyzésre, vagy a Rottentomatoes kritikagyűjtő oldalra. Megadható egyszerűen egy link is, és a Springpad automatikusan megpróbálja a link mögötti tartalmakat felismerni. Annyiban tud többet, mint az Evernote, hogy itt egy jegyzet több jegyzetfüzetbe is tartozhat. Lehetőség van egy jegyzetfüzet közös szerkesztésére több felhasználó között.

Ezek az eszközök alapvetően továbbra is a kutatás anyaggyűjtési fázisát segítik elő a folyamat automatizálása és a felhőben való tárolás által. A hozzájuk kapcsolódó munkafolyamat alapvetően az, hogy vagy az asztali vagy webes klienst használva veszünk fel jegyzeteket, vagy az internetet böngészve a böngésző kiegészítőt használva mentjük el azokat.

Megoldást azonban továbbra sem nyújtanak az adatok közötti összefüggések jelölésére, az információk mögött álló adat szerkezetének megadására, így a strukturált keresésre sem.

Vissza a tartalomjegyzékhez

Táblázatkezelő szoftverek

Ha fontos számunkra az adat szerkezete, akkor első megoldásként a táblázatkezelő programokhoz nyúlhatunk. A táblázatban minden egyes oszlopában más és más jellegű adatot tárolhatunk, így szerkezetet adva a tárolandó információnak. A táblázatkezelő szoftverek a táblázatainkat egy-egy munkalapon tárolják, az egyes munkalapok munkafüzetekbe vannak szervezve. Az adatok jellegét különböző típusokkal jelölhetjük. Megjelenik a szöveges, szám, dátum, pénznem, stb. típus. Az egyes mezők, oszlopok, sőt munkafüzetek között kapcsolatokat jelölhetünk ki.

A táblázatkezelő szoftverek azonban nem elsősorban a szofisztikált adatstruktúrákra vannak kihegyezve, hanem az adatok táblázatos megadásán túl az azokból származtatott adatok kiszámolása az erősségük. A munkafüzetek közötti kapcsolat is elsősorban ezen keresztül valósul meg.

A táblázat mint strukturált forma már sok esetben elegendő közepes bonyolultságú feladatok adatainak nyilvántartására és elemzésére. Táblázatkezelést sokan tanulnak az általános és középiskolákban, így az ehhez tartozó kompetencia is általában megvan. Nagy hátránya azonban, hogy a bennük megadott adatok általában redundánsak, az egyes munkalapok közötti kapcsolat pedig nem biztosítható és garantálható. Alapesetben itt sincs megoldva a közös munka végzés, anyaggyűjtés, és a bárhonnan elérhetőség. Ez utóbbira megoldást nyújtanak a felhőalapú táblázatkezelő szoftverek, mint pl. a Google Docs táblázatkezelője, ahol lehetőség van több embernek egyidejűleg dolgozni ugyanazon a táblázaton.

Vissza a tartalomjegyzékhez

Adatfájlok

A táblázatkezelők táblázatai átvezetnek bennünket az adatfájlokhoz. Úgy, ahogy egy táblázatban összefoglaltuk a táblázat mögött álló objektum adatait, úgy az adatfájlok egy objektum a feldolgozás szempontjából jellemző adataival való leírására szolgálnak. Az objektum bármi lehet: egy személy, esemény, tárgy, fogalom, stb. Az adatfájl legegyszerűbben táblázatként képzelhető el, csak a táblázat adatai egy speciális szerkezetű fájlba vannak mentve a megfelelő módon.

Az adatfájlok már hidat építenek az adatok strukturált tárolása és a köztük lévő kapcsolatok jelzésére is. Egy bonyolultabb feladat során első lépésként meg kell határoznunk a szükséges adatok körét és szerkezetét, és ennek megfelelően létrehozunk egy vagy több adatfájlt (táblázatot), és ezek kezelésére megfelelő programokat írhatunk. Ez utóbbi lépést azonban ki is hagyhatjuk, hiszen az idők során kiderült, hogy az adatok kezelésében, nyilvántartásában és feldolgozásában használt fogalmak általánosíthatók, így kialakultak olyan programrendszerek, amelyek az adatfájlok egymástól független kezelésére használhatók. Ezeket nevezik fájlkezelő rendszereknek.

A fájlkezelő rendszerek annyiban könnyítik meg az adatkezelést és feldolgozást, hogy a fájlszerkezetek kialakítását, a rekordok kezelését nem kell külön, bonyolult módon leprogramozni, hanem ezeket magas szintű műveleteket nyújtva maga a fájlkezelő végzi el. Ezek a rendszerek azonban nem adnak megnyugtató választ az adatkezelés minden problémájára, így például nem tudják biztosítani adataink integritását, az adatok más csoportosításban történő megjelenítését, stb., azaz adataink komplex kezelését. Ez utóbbi azt jelenti, hogy az adatokat nemcsak mint adatfájlokat tároljuk, hanem adatként tároljuk azok szerkezetét is, valamint a köztük lévő kapcsolatokat. Az adatoknak ezt a fajta tárolási módját hívjuk adatbázisnak.

Gyakorlati szempontból az adatfájlok egy-egy táblázat gyors és hatékony kezelését teszik lehetővé, azonban nem alkalmasak táblázatok közötti kapcsolatok megfelelő kezelésére. Manapság az adatfájlokat nem is igazán használják, helyettük egyre inkább az adatbázisokat alkalmazzák.

Forrás: Simon András: Alkalmazások fejlesztése Accessben.

Vissza a tartalomjegyzékhez

Adatbázisok és adatbázis-kezelők

Adatbázisokat akkor érdemes használni tehát, ha a feladat adatszükséglete kellően komplex. Ez alatt egyrészt az adatok szerkezetét értjük, azaz több objektum leírására van szükség, ezek között a megfelelő kapcsolatok jelzését és integritását is biztosítani kell, másrészt az adatok mennyisége túlságosan nagy ahhoz, hogy egyszerű táblázatkezelővel dolgozzuk fel őket.

A legelterjedtebb adatbázis típus a relációs adatmodellre épülő adatbázis. A relációs adatmodell arra az elgondolásra épül, hogy a felhasználók az adataikat legszemléletesebben táblázatokban tudják elképzelni. A táblázatoknak ebben a modellben a relációk felelnek meg, az egyes relációk között pedig különböző típusú kapcsolatok tehetők.

Az adatbázis kialakítását alapos tervezőmunkának kell megelőznie. Az adatbázis-tervezés egy folyamat, mely több lépésből tevődik össze. Először meghatározzuk az adatbázisban tárolandó adatok körét, azok egymás közötti kapcsolatait (fogalmi séma). Ezután következik maga a rendszertervezés, melynek eredménye az adatbázis logikai modellje. Végül fizikai szinten képezzük le a logikai adatbázis modellt az alkalmazott szoftver és hardver függvényében, ez a megvalósítás.

Az adatbázis tervezésénél ügyelnünk kell arra, hogy ugyanazt az információt ne tároljuk egyszerre több helyen. A többszörös tárolás, vagy más néven redundancia amellett, hogy növeli a tárolandó terület méretét, különböző anomáliákhoz vezethet, bonyolítja az adatbázis frissítését és karbantartását, és végül az adatbázis inkonzisztenciáját okozhatja. Egy adatbázis akkor inkonzisztens, ha egymásnak ellentmondó tényeket tartalmaz. A logikai tervezés fő célja tehát a redundanciák megszüntetése. Ezt a folyamatot hívják normalizálásnak. Ehhez pár szabály betartása szükséges, az egyes szabályok biztosítják az adatbázis bizonyos fokú normalizáltságát, az egyes normálformákat.

A normálformák megértéséhez nézzünk egy példát. Egy akkumulátor szerviz bizonyos napokon különböző gyártóktól különböző típusú akkumulátorokat rendel. A rendeléseket az alábbi táblázatban (relációban) tartják nyilván.

Dátum

Gyártó

Gyártó ország

Gyártó URL

Akkumulátorok

2012.11.05

Bosch

német

www.bosch.com

BoschAkku1, 77Ah, 780A, 10db

BoschAkku2, 74Ah, 720A, 20db

BoschAkku3, 70Ah, 680A, 30db

Banner

osztrák

www.banner.com

BannerAkku1. 68Ah, 680A, 10db

BannerAkku2, 60Ah, 600A, 20db

BannerAkku3, 50Ah, 420A, 30db

2012.11.14

Bosch

német

www.bosch.com

BoschAkku1, 77Ah, 780A, 20db

BoschAkku2, 74Ah, 720A, 30db

Banner

osztrák

www.banner.com

BannerAkku1. 68Ah, 680A, 10db

BannerAkku3, 50Ah, 420A, 5db

Az adatbázisbeli reláció sorokból és oszlopokból áll. Az oszlopok elég egyértelműek, de egyelőre nehéz lenne megmondani, hogy a fenti táblázatban mi tartozik egy sorba, és azt a sort mi azonosítja. A táblázat jelenlegi megadása azt sejteti, hogy egy sort egy dátum jelöl ki, és ez is azonosítja. Ebben az esetben azonban egy dátumhoz több gyártót is tárolunk, és ráadásul minden gyártóhoz több típust is. Célszerű lenne ezt a többszörös összetettséget elkerülni és egyelőre egy sorba az adott időpontban az adott gyártótól rendelt termékeket tárolni, ahogy a következő táblázat mutatja:

Dátum

Gyártó

Gyártó ország

Gyártó URL

Akkumulátorok

2012.11.05

Bosch

német

www.bosch.com

BoschAkku1, 77Ah, 780A, 10db

BoschAkku2, 74Ah, 720A, 20db

BoschAkku3, 70Ah, 680A, 30db

2012.11.05

Banner

osztrák

www.banner.com

BannerAkku1. 68Ah, 680A, 10db

BannerAkku2, 60Ah, 600A, 20db

BannerAkku3, 50Ah, 420A, 30db

2012.11.14

Bosch

német

www.bosch.com

BoschAkku1, 77Ah, 780A, 20db

BoschAkku2, 74Ah, 720A, 30db

2012.11.14

Banner

osztrák

www.banner.com

BannerAkku1. 68Ah, 680A, 10db

BannerAkku3, 50Ah, 420A, 5db

Ebben a táblázatban egy sort egyértelműen a dátum és a gyártó együttesen azonosít, ezért őket azonosítónak nevezzük. Ez a reláció már teljesíti a relációs adatmodellel szemben megfogalmazott követelményeket:

Ha egy reláció ezeknek eleget tesz, akkor azt mondjuk, hogy a reláció nulladik normálformában (0NF) van. Ebben azonban az adatok még a tárolás és karbantartás szempontjából elég kedvezőtlen formában lehetnek. A fenti táblázatban például az akkumulátorok oszlop összetett adatokat tartalmaz, amelyek kezelése, keresése nehézkes. Ugyanakkor elvi probléma is adódik velük: több tulajdonságot próbáltunk meg egy mezőbe szorítani. Szüntessük meg ezt a többértékűséget, és minden tulajdonságot egyszerű típusokkal írjunk le.

Dátum

Gyártó

Gyártó ország

Gyártó URL

Típus

Kapacitás

Indítóáram

Db

2012.11.05

Bosch

német

www.bosch.com

BoschAkku1

77

780

10

2012.11.05

Bosch

német

www.bosch.com

BoschAkku2

74

720

20

2012.11.05

Bosch

német

www.bosch.com

BoschAkku3

70

680

30

2012.11.05

Banner

osztrák

www.banner.com

BannerAkku1

68

680

10

2012.11.05

Banner

osztrák

www.banner.com

BannerAkku2

60

600

20

2012.11.05

Banner

osztrák

www.banner.com

BannerAkku3

50

420

30

2012.11.14

Bosch

német

www.bosch.com

BoschAkku1

77

780

20

2012.11.14

Bosch

német

www.bosch.com

BoschAkku2

74

720

30

2012.11.14

Banner

osztrák

www.banner.com

BannerAkku1

68

680

10

2012.11.14

Banner

osztrák

www.banner.com

BannerAkku3

50

420

5

Ha egy 0NF reláció nem tartalmaz többértékű tulajdonságot, akkor a reláció első normálformában van (1NF). A fenti példában az azonosító továbbra is összetett, de most egy sort a dátum és az akkumulátor típusa együttesen határoz meg. Az így kialakult táblázat azonban még mindig nem kedvező szerkezetű, mert:

Azt láthatjuk, hogy az összetett azonosítónak egy része (típus) önmagában is meghatároz bizonyos adatokat a táblázatban (kapacitás, indítóáram, gyártó, gyártó ország, gyártó url). Szüntessük meg ezt a jellegű összefüggést! Kétféleképpen tehetjük meg ezt. Felvehetünk egy új oszlopot rendelésazonosító néven, ami minden sorra egyedi. Ekkor ez lesz az azonosító és megszűnik az a probléma, hogy az összetett azonosító egyik része önmagában meghatároz értékeket, hiszen nem lesz összetett az azonosító. Ezzel azonban csak elodázzuk a fenti problémák nagy részét. Másik lehetőségként az merül fel, hogy az összetett azonosító egyik tagjától függő részeket egy másik táblázatba emeljük ki.

Dátum

Típus

Db

2012.11.05

BoschAkku1

10

2012.11.05

BoschAkku2

20

2012.11.05

BoschAkku3

30

2012.11.05

BannerAkku1

10

2012.11.05

BannerAkku2

20

2012.11.05

BannerAkku3

30

2012.11.14

BoschAkku1

20

2012.11.14

BoschAkku2

30

2012.11.14

BannerAkku1

10

2012.11.14

BannerAkku3

5

Típus

Kapacitás

Indítóáram

Gyártó

Gyártó ország

Gyártó URL

BoschAkku1

77

780

Bosch

német

www.bosch.com

BoschAkku2

74

720

Bosch

német

www.bosch.com

BoschAkku3

70

680

Bosch

német

www.bosch.com

BannerAkku1

68

680

Banner

osztrák

www.banner.com

BannerAkku2

60

600

Banner

osztrák

www.banner.com

BannerAkku3

50

420

Banner

osztrák

www.banner.com

Ezzel megszűnik az, hogy az összetett azonosító egyik részétől függnének csak bizonyos oszlopok értékei, így a relációnk második normálformába került (2NF). Látható, hogy az új relációban a típus az azonosító. Észrevehetjük azt is, hogy e második táblázatban továbbra is két tulajdonságot, az akkumulátor típusát és a gyártó tulajdonságait próbáljuk egyszerre leírni, így a fent leírt aggályok egy része még mindig fennáll: a táblázat redundáns és az összekapcsolódó adatok miatt karbantartása nehézkes, beviteli és törlési anomáliát okozhat. A táblázatot vizsgálva megállapíthatjuk, hogy vannak olyan nem azonosító oszlopok a táblázatban (gyártó), amely meghatároz más oszlopokat (ország, url). Szüntessük meg ezt a függőséget is azáltal, hogy a függő részeket külön táblába emeljük.

Típus

Kapacitás

Indítóáram

Gyártó

BoschAkku1

77

780

Bosch

BoschAkku2

74

720

Bosch

BoschAkku3

70

680

Bosch

BannerAkku1

68

680

Banner

BannerAkku2

60

600

Banner

BannerAkku3

50

420

Banner

Gyártó

Gyártó ország

Gyártó URL

Bosch

német

www.bosch.com

Banner

osztrák

www.banner.com

Ezáltal a relációink harmadik normálformába (3NF) kerültek. Gyakorlatilag a harmadik normálformában lévő adatbázis redundancia mentesnek tekinthető. Az esetek többségében elegendő a normalizálást harmadik normálformára elvégezni.

A fenti táblázatokban az azonosítók két helyen is szövegek. A típust leíró táblázatba egy új sort felvíve könnyen előfordulhat, hogy a felhasználó elgépeli pl. a gyártó nevét, Bosch helyett Bosh-t ír. Bár mi tudjuk, hogy mihez kapcsolódhat, de a gép nem ismeri fel a hasonlóságot, így adatbázisunk inkonzisztenssé válik. Éppen ezért szöveges típusú azonosító helyett számokkal szoktuk a táblázatok sorát azonosítani, és ezeken keresztül hivatkozunk a másik táblára. Így a végleges akkumulátor rendelési adatbázis a következő lehet:

Rend. Azon

Dátum

Akku azon

Db

1

2012.11.05

1

10

2

2012.11.05

2

20

3

2012.11.05

3

30

4

2012.11.05

4

10

5

2012.11.05

5

20

6

2012.11.05

6

30

7

2012.11.14

1

20

8

2012.11.14

2

30

9

2012.11.14

4

10

10

2012.11.14

6

5

Akku azon

Akkumulátorok

Kapacitás

Indítóáram

Gyártó azon

1

BoschAkku1

77

780

1

2

BoschAkku2

74

720

1

3

BoschAkku3

70

680

1

4

BannerAkku1

68

680

2

5

BannerAkku2

60

600

2

6

BannerAkku3

50

420

2

Gyártó azon

Gyártó

Gyártó ország

Gyártó URL

1

Bosch

német

www.bosch.com

2

Banner

osztrák

www.banner.com

Forrás

Vissza a tartalomjegyzékhez

Új Széchenyi terv
A projekt az Európai Unió támogatásával, az Európai Szociális Alap társfinanszirozásával valósul meg.

A Társadalominformatika: moduláris tananyagok, interdiszciplináris tartalom- és tudásmenedzsment rendszerek fejlesztése az Európai Unió támogatásával, az Európai Szociális Alap társfinanszírozásával, az ELTE TÁMOP 4.1.2.A/1-11/1-2011-0056 projekt keretében valósult meg.
A tananyag elkészítéséhez az ELTESCORM keretrendszert használtuk.