II. RF KMF DokuWiki

Ez az oldal csak olvasható. Megtekintheted a forrását, de nem változtathatod meg. Ha úgy gondolod, hogy ez helytelen, kérdezd az Adminisztrátorokat!
====== 2. Adatmodellek ======
    
===2.1	Adatbázis-tervezés===
Az adatbázis tervezés az alkalmazás fejlesztésének egyik kulcskérdése. Nagyobb volumenű alkalmazásoknál általában igen sok adat kerül tárolásra, illetve feldolgozásra. Ezek összetett módon kapcsolódhatnak egymáshoz. Az adatbázisokat úgy kell megtervezni, hogy minimális legyen bennük a redundancia, teljesüljenek a különböző adatfüggetlenségek, stb. 

A tervezés maga egy kreatív folyamat. Mivel az alkalmazások nagyon különbözőek lehetnek, nincs olyan általános tervezési technika, ami mindig egy az egyben alkalmazható lenne. Egy jó terv elkészítéséhez megfelelő tapasztalat szükséges, amelyet gyakorlattal lehet megszerezni. Táblázatos formában foglaljuk össze egy alkalmazás tervezésének legfontosabb fázisait.

^Fázis neve^Fő tevékenységek^
|Információ igény meghatározása|Célok meghatározása, adatok, formátumok, algoritmusok kialakítása|
|Logikai adatbázis tervezés|Egyedek meghatározása, Egyedeket leíró tulajdonságok megadása, Egyedek közötti kapcsolatok feltérképezése,Adatredundancia minimalizálása|
|Fizikai adatbázis kialakítása|Az adatbázisok létrehozása számítógépen|

Az **információ igény** meghatározásának fázisában az egyik fő feladat az alkalmazás céljainak megállapítása.

 A célok szoros összefüggésben vannak a felhasználói igényekkel. Ezért a tervezésnek ebben a fázisában a felhasználókkal való szoros kapcsolattartás elengedhetetlen. Szükséges az is, hogy a tervező járatos legyen a rendszer felhasználóinak szakterületén. A tervezést általában nem a programozó végzi, hanem külön a tervezésben gyakorlott személyek, a **szervezők.**

 A szervező a tervezés során megismeri a pontos felhasználói igényeket. Különböző meglévő dokumentumok, jelentések gyakran hasznos forrásként szolgálhatnak ehhez.
Ebben a fázisban szükséges azt is meghatározni, hogy a rendelkezésre álló adatokat hogyan fogja a rendszer feldolgozni. Az eljárások, algoritmusok specifikációját is ekkor kell elvégezni. Meg kell határozni milyen módon, és formátumban kívánja a felhasználó megjeleníteni a feldolgozott adatokat. Ez befolyásolhatja az adatok tárolási formátumát is, amelyet ugyancsak specifikálni kell. Lényeges lehet annak meghatározása is, hogy az egyes adatok feldolgozása mekkora aktivitással történik majd. 

A **logikai tervezés** fázisában főképpen az adatokra és a közöttük lévő kapcsolatokra koncentrálunk. 
Ebben a lépésben kell részletezni a nyilvántartani kívánt adatok pontos listáját, meghatározni azok tárolási típusát és formátumát, figyelembe véve a számítógép lehetőségeit. Logikai összetartozásuk alapján az adatokat csoportosítani kell, majd meg kell határozni az egyes csoportok közötti összefüggéseket, kapcsolatokat. 

Viszonylag jobban elkülönül az előző két fázistól a **fizikai tervezés** szakasza.
 Ez tulajdonképpen az alkalmazás megvalósítását jelenti a logikai tervek alapján. A gyakorlatban a szervező egy tervdokumentációban rögzíti a rendszertervet, amelyben leírja az adatbázis pontos tervét, az adatok beviteli és megjelenítési formátumát, az algoritmusokat. Ennek alapján készíti el a programozó az adatbázis-rendszert.

A **prototípus** a rendszer első verziója, amely esetleg még nem teljes, illetve finomításra szorul. Alkalmas azonban arra, hogy felújítsa a kommunikációt a felhasználó és a programozó, illetve a szervező között, javítva ezzel a rendszer minőségét. Nem feltétlenül szükségszerű a teljes rendszerre vonatkozó prototípus megvalósítása.

===2.2	Adatmodellezés alapelemei===
Az egységes tervezés érdekében kidolgoztak modelleket, amelyeket adatmodelleknek nevezünk. Egy adatmodell alapvetően nem magukkal az adatokkal foglalkozik, hanem azok struktúrájával, a közöttük lévő összefüggésekkel, kapcsolatokkal. A legelterjedtebb adatmodellezési technikák közös jellemzője, hogy három alapelemből tevődnek össze. Ezek a következők:
  *	Egyed (egyedtípus)
  *	Tulajdonság (tulajdonságtípus)
  *	Kapcsolat (kapcsolattípus)

**Egyedek**

//Egyednek// nevezzük azokat a dolgokat, objektumokat, amelyek egymástól jól elkülöníthetők, melyekről adatokat tárolunk, és tulajdonságokkal jellemzünk. Egyedek lehetnek például a dolgozó, kifizetés, anyag, személy, stb. Ebben a formában az egyed, mint absztrakt fogalom szerepel. 

//Az egyed a konkrét dolgok absztrakciója.// 
Az absztrakt egyedek kapcsán alkalmazzuk az //egyedtípus// kifejezést. Foglalkozunk az egyedtípus konkrét előfordulásaival is. Ezeket nevezhetjük //egyedhalmaznak,// vagy //egyed előfordulásoknak.// 
Például a dolgozó egyedtípus egyedhalmaza az összes dolgozót magába foglaló halmaz, hasonlóan a kifizetés egyedhalmaza az összes kifizetés, ami megtörtént. 

**DOLGOZÓ**
^A dolgozó Törzsszáma^A dolgozó Neve^A dolgozó születési helye^A dolgozó születési ideje^
|T234578|Kiss István|Eger|1968.12.11.|
|T456734|Nagy József|Budapest|1972.01.30.|
|T429877|Kovács János|Szeged|1967.05.12.|

Az egyed előfordulások **rekordoknak** felelnek meg. A gyakorlatban az egyedtípust szokás //rekordtípusnak// is nevezni. (rekord- vagy struktúratípus).

**Attribútumok (tulajdonságok)**
Az adatmodellben olyan tulajdonságokat szokás alkalmazni, amelyek a rendszer szempontjából lényegesek. Például a bérszámfejtő rendszerben a dolgozó neve, fizetése lényeges tulajdonságok.

 Az egyed fogalmánál már megismert két szintet itt is alkalmazhatjuk. Maga az **attribútum (tulajdonság)** egy absztrakt fogalom, amelyet nevezhetünk //tulajdonságtípusnak//. Az egyes tulajdonságtípusok konkrét értékeit nevezzük //tulajdonságértékeknek.// Így például a szín tulajdonság konkrét értékei lehetnek a piros, zöld, kék, stb. Láthatjuk azt is, hogy a különböző tulajdonságok, egyes értékeivel, a tulajdonságokkal jellemzett egyed egy előfordulását, vagyis az egyedhalmaz egy elemét adhatjuk meg. 

**Kulcsok**
Fontos szerepe van azoknak a tulajdonságoknak, amelynek értékei a többi tulajdonság értékeit egyértelműen meghatározzák. Ez azt jelenti, hogy ha az ilyen tulajdonságok értékeit megadjuk, akkor az egyértelműen definiál egy előfordulást. 

Azokat a tulajdonságokat, amelyek egyértelműen meghatározzák az egyedtípus egy elemét, **kulcsnak** nevezzük. A kulcsok fontos szerepet töltenek be az adatmodell kialakításánál. A tervezés során meg kell adni, mely attribútumok fogják a kulcsokat alkotni. Egy egyednek több kulcsa is lehet, de mindég azt kell kiválasztani, amely a leginkább alkalmas az egyértelmű azonosításra (például, legkevesebb attribútumot tartalmaz). Ez az //elsődleges kulcs.//
Kulcsjellegű attribútumok mindig találhatók. Ha az valamilyen okból nem megfelelő, akkor bevezethetünk egy olyan attribútumot, amelynek az értékei sorszámok, kódszámok, speciális azonosítók, és akkor ez is betöltheti az elsődleges kulcs szerepét.

Az azonosítók, kódszámok szinte minden alkalmazásnál előfordulnak. A számítógép jellegéből adódóan ezek alkalmasak az előfordulások pontos meghatározására. Bizonyos esetekben a felhasználó számára nehézséget okozhat, hogy a kódnál már egy apró elírás is egész más eredményt szolgáltathat. Aki számítógéppel dolgozik, annak tudomásul kell venni a kódok használatát, és pontos munkára kell törekednie.

**Kapcsolatok**
Az adatmodell harmadik fontos elemét a kapcsolatok jelentik.** Kapcsolatnak** nevezzük az egyedek közötti összefüggést, viszonyt. Például a bérszámfejtő rendszerben a dolgozó és a kifizetés egyedek között létezik egy bizonyos kapcsolat, mely meghatározza, hogy az egyes dolgozókhoz mely kifizetések tartoznak. Lehet úgy is fogalmazni, hogy a kapcsolatok az egyedhalmazok elemei között alakíthatók ki.

A kapcsolatokat osztályozhatjuk aszerint, hogy egy-egy elemhez hány másik elem tartozik.
Ennek a kapcsolat számítógépes reprezentációja szempontjából van jelentősége. Sokkal egyszerűbb egy olyan kapcsolatot megvalósítani, ahol egy egyed előforduláshoz csak egyetlen másik egyed előfordulás tartozhat, mint ha több. Az előbbinél elegendő lehet egy mutató, míg az utóbbinál valamilyen összetett adatstruktúrára van szükség, például halmazra, vagy listára. Ezek alapján a kapcsolatokat három csoportba oszthatjuk:
  *	Egy-egy típusú
  *	Egy-sok típusú
  *	Sok-sok típusú

**Egy-egy kapcsolat** esetén az egyik egyed minden egyes előfordulásának a másik egyed pontosan egy előfordulása tartozik. Egy-egy típusú kapcsolat például a férfi és a nő egyedek között a házastárs kapcsolat. 

A következő csoportot az **egy-sok kapcsolatok** alkotják. Ezeknél az egyik egyed minden előfordulásához a másik egyed több előfordulása tartozhat. Például a bérszámfejtő rendszerben egy-sok kapcsolat van a dolgozók és a kifizetések között. A kapcsolat alapja az, hogy melyik dolgozóhoz mely kifizetések tartoznak. Világos, hogy egy dolgozóhoz több kifizetés tartozhat, viszont egy kifizetés mindenképpen csak egyetlen dolgozóhoz kapcsolódik.

A kapcsolatok legáltalánosabb formáját a **sok-sok kapcsolatok** jelentik. Sok-sok kapcsolat esetén mindkét egyed előfordulásaihoz a másik egyed több előfordulása tartozhat. Tegyük fel, hogy a dolgozói rendszerünkben azt is nyilvántartjuk, hogy melyik dolgozó milyen témákon dolgozik. Egy dolgozó több témában is tevékenykedhet és egy témán több dolgozó dolgozhat. Ebben az esetben sok-sok kapcsolatról van szó. Ezt a következő ábra szemlélteti.

Mint látható egy sok-sok kapcsolat több egy-sok kapcsolatokon alapszik. Ha bármelyik egyed szempontjából nézzük, akkor egy-sok kapcsolatot fedezhetünk fel. Ezért //minden sok-sok kapcsolat felbontható két egy-sok kapcsolatra.//
Az eddigiekben az úgynevezett bináris kapcsolatokról beszéltünk, amelyek két egyed között létesíthetők. 

**Egyed-kapcsolat diagrammok**
Az adatmodell grafikus leírására lehet az** egyed-kapcsolat diagrammal (ER=Entity Relationship diagramm)** használni.
 Az egyed-kapcsolat diagramm elemei az adatmodell már ismert összetevői. Az egyes elemek grafikus reprezentációja a következőképpen készíthető el. Az egyedeket téglalap segítségével adjuk meg, amelybe beleírjuk az egyed nevét. 
A tulajdonságokat hasonlóan ábrázoljuk, azzal a különbséggel, hogy itt téglalap helyett ellipszist használunk. 
A kapcsolat ábrázolására rombusz jelet használjuk. 

Az egyed-kapcsolat modellben lehetőség van több egyed közötti kapcsolat megadására is. Ez ugyanúgy történik, mint a két egyed közötti kapcsolat esetén, csak ilyenkor a kapcsolat jelét mindegyik egyeddel összekötjük. A gyakorlatban háromnál több egyed között csak nagyon ritkán alakítanak ki kapcsolatot.  

===2.3	Adatmodellek típusai===
Az előző részben említett adatmodell elemekből különböző struktúrák igénybevételével alakítjuk ki az adatmodellt. Az adatbázis-kezelés fejlődése során három fontos adatmodellt alakítottak ki. Ezek a következők:
  * Hierarchikus modell
  * Hálós modell
  * Relációs modell

A hierarchikus és a hálós adatmodelleket már csak történeti okból említjük. Ezért ezekről csak rövid összefoglalást adunk. Ma a leggyakrabban használt modellnek a relációs modell számít.

**Hierarchikus adatmodell**

A hierarchikus adatmodell azért kapta ezt az elnevezést, mert az alapelve az, hogy az egyedeket a köztük lévő kapcsolat alapján hierarchiába rendezi. A hierarchikus modell leginkább egy-egy és egy-sok jellegű kapcsolatok megvalósítására használható. A kapcsolat alapján a két egyedtípus között hierarchiát definiálunk. Fontos, hogy a hierarchiában alul lévő egyedtípusnak csak egyetlen őse lehet. A hierarchiában felül lévő egyedtípushoz több, a hierarchiában lentebb lévő egyedtípus kapcsolódhat.
 
Az első hierarchikus ABKR az IBM által 1968-ban kifejlesztett Information Management System (IMS) volt. Mára a relációs modell már teljesen kiszorította a hierarchikust.
A hierarchiák alkalmazását az adatbázis-kezelésben motiválta az, hogy a fastruktúrák jól ábrázolhatók szekvenciálisan. Közismert a fáknak az a reprezentációja, amelynél minden egyes csúcsponthoz a hozzátartozó részfák mutatóit a csúcspont mellett helyezzük el szekvenciálisan. A mutatók segítségével hatékonyan kereshetők a kapcsolódó rekordok.

**Hálós adatmodell**

A hálós adatmodellt tekinthetjük a hierarchikus modell kiterjesztésének. A különbség az, hogy míg a hierarchikus modell gráfja csak fa lehet, a hálósnál tetszőleges gráf előfordulhat. Ez azt jelenti, hogy egy egyedtípusnak több őse is lehet. A hálós adatmodellben a sok-sok kapcsolatok is kezelhetők, úgy hogy azokat két egy-sok kapcsolatra bontják fel. Magát a modellt, illetve a hozzá kapcsolódó adatbázis-kezelő nyelvet 1971-ben ismertette a //CODASYL DBTG (Conference on Data Systems and Languages  Data Base Task Group).// 
A hálós modellben a kapcsolatok leírására egy új típust vezettek be, ez a **halmaztípus (set type)**. A halmaztípusnak három jellemzőjét definiálták:

**Név, Tulajdonos (owner), Tag (member).**

A tulajdonos és a tag egyedtípusok, amelyek egyértékű és többértékű attribútumokat is tartalmazhatnak. A halmaztípus tulajdonképpen az //egy-sok kapcsolat// megvalósítására való. Megadása a szokásos grafikus formában történhet, azaz a két egyedtípust egy nyíllal kapcsoljuk össze.

Mivel a hálós modellben nincs olyan megkötés, hogy valamely egyedtípusnak feltétlenül egy másik felett kell állnia a hierarchiában, ezért a fenti felbontás nem sérti az adatmodell alapelvét. A halmaztípus megvalósítása ugyancsak jól ismert adatszerkezettel történhet. 

Minden //egyes rekord előfordulásnál// az adatok mellett egy //fejrészt// is képez az ABKR. Ebben a fejrészben történik a kapcsolatok megadása. A fejrészben különböző **mutatók** lehetnek. A leggyakrabban használt mutatófajták az alábbiak:

  * Első (first) – tulajdonostól mutat az első tagra
  * Következő (next) – tagtól mutat a következő tagra
  * Előző (prior) – tagtól mutat az előző tagra
  * Tulajdonos (owner) – tagtól mutat a tulajdonosra
II. RF KMF DokuWiki

Felhasználói eszközök

Eszközök a webhelyen

Eszközök az oldalon
