2. Adatszervezés, adatelérés, adatbáziskezelı rendszerek

2. Adatszervezés, adatelérés, adatbáziskezelı rendszerek

2.1. Bevezetés 2.2. Adatszervezés: elemi adatok, összetett adatszerkezetek 2.3. Tárolási szerkezetek 2.4. A háttértárakon, valamint az adatforgalomban alkalmazott adategységek 2.5. Tartalom szerinti adatelérés 2.6. Adatbáziskezelı rendszerek 2.7. Adatbázistervezés – adatmodellezés

44

INFORMATIKUS SZAKMAI ISMERETEK

2.1 Bevezetés

Ez a fejezet alapvetı adatszervezési ismeretekkel kezdıdik (2.2. alfejezet). Ezekbe beletartozik a különféle típusú elemi adatok számítógépi ábrázolási módja, de a bonyolultabb problémákat jellemzı összetett adatszerkezetek típusai is. A 2.3. alfejezet az összetett adatszerkezetek reprezentálására alkalmas tárolási szerkezetek fıbb típusait mutatja be függetlenül azok fizikai megvalósításaitól. A 2.4. alfejezet a háttértárakon, valamint a háttértárak és központi memória közötti adatforgalomban alkalmazott fizikai és logikai adategységeket ismerteti. Az adatszerkezeteket, az adattárolást, valamint az ezekkel összefüggı adategységeket tárgyaló részeket követıen a 2.5. alfejezet az adatok tartalom szerinti elérési módjaival, konkrétabban a tartalom szerinti elérést meggyorsító megoldásokkal foglalkozik különös tekintettel a relációs adatbázisoknál nélkülözhetetlen indextáblákra, valamint a többdimenziós adatbázisokra jellemzı inverz táblákra. A 2.2-2.5. alfejezetek egyebek mellett az adatbázisok szerkezeti felépítésének megértését, lényegében az adatbáziskoncepciókat tárgyaló 2.6. alfejezetet készítik elı. Ez az alfejezet az adatbázisoknak nem csak felépítés (technológia), hanem az alkalmazási cél szerinti típusait is megkülönbözteti, így részletesen foglakozik az OLTP rendszerek adatbázisai és az adattárházak közötti különbségekkel. A 2.4. alfejezet az OLTP rendszereket kiszolgáló relációs adatbázisokra koncentrálva részletesen bemutatja az adatbázistervezés részét képezı adatmodellezés elveit, fogalmait és módszereit (normalizálási szabályait).

ADATSZERVEZÉS, ADATELÉRÉS, ADATBÁZISKEZELİ RENDSZEREK

45

2.2 Adatszervezés: elemi adatok, összetett adatszerkezetek 2.2.1 Adatábrázolás a számítógépeken – Elemi adattípusok Digitális adatábrázolás Az 1.2.1. szakaszban már szerepelt, hogy az adat egyszerő vagy összetett jel, az utóbbi legegyszerőbb változata pedig a jelsorozat. Technikailag (mechanikai, optikai, elektromágneses vagy elektronikus eszközzel) a legegyszerőbben megvalósítható jelkészlet egy kétállapotú kapcsoló kétféle állapotából áll. A digitális adatábrázolásban alkalmazott kétállapotú kapcsolók neve: bit. A digitális számítógépek operatív memóriájában vagy a digitális adathordozókon minden adat bitek sorozataként ábrázolódik. Az elemi adattárolási egységként itt bevezett bit nem azonos az 1.2.3 szakaszban az információmennyiség mértékegységeként bevezetett bittel, de a két fogalom között szoros kapcsolat van: egy n bitnyi információmennyiséggel rendelkezı adat tárolásához legalább n bit (elemi tárolási egység) szükséges.

A bit két állapotának egyike tekinthetı 0-nak, a másika 1-nek. A kettes (bináris) számrendszerben éppen elegendı ezt a két számjegyet használni, továbbá ebben a számrendszerben az alapvetı aritmetikai mőveleteket (összeadás, szorzás) nagyon egyszerő szabályok szerint lehet elvégezni. Ez az oka annak, hogy a számítógépes számábrázolásban egyeduralkodó szerephez jutott a kettes számrendszer. Ráadásul a számítógépben (de a háttértárakon is) nemcsak a számszerő adat, hanem mindenféle adat (szöveg, kép, hang) valamilyen szabályok szerint számként kódolódik, azaz végeredményben bináris számmal ábrázolódik. A legkisebb címezhetı adategység, a bájt (byte) A számítógép operatív memóriájában az egyes tárolási egységek (és azzal a bennük tárolt adatok) véletlenszerően (közvetlenül) elérhetık, a címük (a memóriaegység sorszáma) alapján: Pl. a 100. memóriaegységben tárolt adat olvasásához nem kell végigmenni az elızı 99 egységen, és így bármely memóriaegység az elhelyezkedésétıl függetlenül azonos idı alatt érhetı el. A legkisebb ilyen címezhetı egység általában a 8 bitbıl álló bájt (byte). Adattípus A számítógéptıl függetlenül is megkülönböztetik az adatok megjelenésének (ábrázolásának, kódolásának) többféle típusát, például a számokat, a szövegeket, a képeket, stb. Az adatok ilyen fajtáiból vonatkoztatható el az adattípus fogalma. Adattípus Az adattípus adatábrázolási (kódolási) módot, értékkészletet, az adott módon ábrázolt adatokon értelmezett mőveletek készletét és az egyes mőveletek végrehajtási módját együttesen meghatározó kategória. Az 1.2.1. szakaszban értelmezett specifikált adat számítógépi reprezentációjának meghatározása magában foglalja az adattípus megválasztását. – Itt azért a „magában foglalja az adattípus megválasztását” kifejezést használtuk az „azonos az adattípus megválasztásával” helyett, mert egy adattípus megvalósítása még függhet a számítógép vagy a használt szoftver (operációs rendszer, adatbáziskezelı) típusától is.

46

INFORMATIKUS SZAKMAI ISMERETEK A különbözı adattípusok mindegyike összetartozó bájtok sorozataként ábrázolható.

Arra, hogy az adattípus meghatározza az elvégezhetı mőveleteket egyszerő példa, hogy a numerikus típusú (számszerő) adatokon lehet aritmetikai mőveleteket végezni, míg a szöveg típusú adatokon általában nem. Vannak azonban olyan mőveletek is, amelyek sokféle adattípuson elvégezhetık, mégpedig az összehasonlítás (A=B, A
2.612.314,21 1.112.000,21

Összesen:

3.724.314,43

1+1 ≠ 3: Decimálisból bináris számmá konvertálás és kerekítések miatti hiba.

A 2. megoldás esetében nem jelentkezik az elıbbiekben említett eltérés a papíron és a számítógépben elvégzett mőveletek között, ezért a pénzügyi rendszerekben az ilyen belsı ábrázolási móddal rendelkezı numerikus adattípust célszerő a pénzösszegek adattípusává választani. 2.2.2 Összetett adatszerkezetek A strukturált megközelítési mód (lásd a 3. fejezetben) felfedezése volt az az elv, hogy a programok, programfunkciók szerkezetének optimálisan a feldolgozandó adatszerkezetet kell követni. (Ez a feladattól függıen lehet az input vagy az output adatszerkezet vagy a kettı burkolója vagy a kettı közötti közvetítı szerkezet.) Az elvet fejlettebb formában a korszerőbb objektumorientált módszertanok is megtartották. (A továbbfejlesztett elv úgy szól, hogy a


47

programfunkciókat valamilyen gazda adatszerkezet köré kell szervezni.) A programozási feladatot lényegesen megkönnyíti, ha a programozók valamilyen elıre adott megoldási sémákat követhetnek, fıleg ha a sémák száma nem túl magas. Ilyen szempontból szerencse, hogy bár az adatoknak végtelen sokféle összetétele (kompozíciója) lehetséges, a lényeges tulajdonságok tekintetében az összetett adatszerkezetek mindössze néhány típusba sorolhatók, következésképpen a programozási feladatok is tipizálhatók. – E szakasz az összetett (absztrakt) adatszerkezetek fı típusait tekinti át.

2.1. ábra: Néhány összetett adatszerkezet: tömb, szekvencia, fa, háló

A 2.1. ábrán az összetett struktúrák elemeit csomópontok, a közvetlen kapcsolataikat pedig nyilak képviselik. Ezzel összhangban egy fa vagy egy háló elemei helyett ezek csomópontjairól lehet beszélni. Halmaz (asszociatív „szerkezet”, tömb) Az összetett adatok közül a legegyszerőbb „szerkezet” a halmaz. Halmaz A halmaz – mint összetett adat – elemi adatok olyan együttese, amelyek között azon felül, hogy bele tartoznak az adott együttesbe, semmilyen kapcsolatot nem feltételezünk.

48


A [Mérey-1979] forrás ezt nevezi asszociatív szerkezetnek és tömbnek is. – Valójában a programnyelvekben alkalmazott tömbfogalom inkább a 2.3. alfejezetben vektor néven bevezetett tárolási szerkezetnek felel meg. Szekvencia – sor és verem Ha egy útvonal egymást követı szakaszait vagy egy gyártási folyamat szigorúan egymást követı mőveleteit vagy ügyfelek érkezési sorrendben való kiszolgálását akarjuk modellezni, akkor az útvonalszakaszok vagy az ügyfelek sorrendje már lényegi, tartalmi jelentéssel bír. Az említett jelenségek modellezésére alkalmas struktúra a szekvenciális adatszerkezetek egyike a sor (nem tévesztendı össze a papírlapra írt szövegek tagolásával kapott sorral). Szekvencia: A szekvenciális adatszerkezetet (röviden szekvenciát) a következı jellemzık definiálják: 1. A szerkezet bármely A eleméhez – kivéve az egyetlen elsı elemet – létezik pontosan egy olyan – tıle különbözı – B elem, amely közvetlenül megelızi A-t (másképpen, amelyet az A közvetlenül követi). Az elsı elemet éppen az definiálja, hogy nem létezik azt közvetlenül megelızı elem a szerkezetben. 2. A szerkezet bármely A eleméhez – kivéve az egyetlen utolsó elemet – létezik pontosan egy olyan – tıle különbözı – B elem, amely közvetlenül követi A-t (másképpen, amelyet az A közvetlenül megelızi). Az utolsó elemet éppen az definiálja, hogy nem létezik azt közvetlenül követı elem a szerkezetben. A szekvencia szemléletesen elemek lineárisan kiterített sorozata (lásd a 2.1. ábrán). A sor (egy és kétvégő) és a verem speciális szekvenciák, amelyek az új elem hozzáadása és egy elem elvétele mőveletekben különböznek egymástól. Sor (egyvégő): A sor (másképpen egyvégő sor) olyan szekvencia, amelybe új elemet elhelyezni csak a végére (az utolsó elem után) lehet, és amelybıl elvenni (törölni) a mindenkori elsı elemet lehet. A sor tehát egy FIFO (first in first out) szerkezet – összhangban az ügyfelek érkezési sorrendben való kiszolgálásának példájával. Kétvégő sor: A kétvégő sor olyan szekvencia, amelybe új elemet elhelyezni vagy belıle elemet elvenni (törölni) mindkét végén lehet. Verem: A verem olyan szekvencia, amelybe új elemet elhelyezni és belıle elvenni csak ugyanazon végén lehet. A verem tehát egy LIFO (last in first out) szerkezet. – A veremre közismert példa az öltözködés-vetkızés: amit utoljára veszünk fel, azt lehet elsıként levetni (ha a trükkös megoldásokat nem számítjuk). Hierarchia vagy fastruktúra Hierarchia, más szóval fastruktúrával például egy hagyományos szervezet felépítése a különbözı szintő szervezeti egységekbıl vagy a fıkönyvi számlák kapcsolatai a számlarendben.


49

Hierarchia (fastruktúra): A hierarchiát – másképpen a fát (fastruktúrát) – a következı jellemzık definiálják: 1. A fa bármely A eleméhez – kivéve az egyetlen gyökér elemet – létezik pontosan egy olyan – tıle különbözı – B elem, amely közvetlenül megelızi A-t (másképpen, amelyet az A közvetlenül követi). A gyökér elemet éppen az definiálja, hogy nem létezik azt közvetlenül megelızı elem a fában. 2. A (szekvenciával ellentétben a) fa egyes A elemeihez esetleg több olyan – tıle különbözı – B elem is létezhet, amely közvetlenül követi A-t (másképpen, amelyet az A közvetlenül megelızi). A fa azon elemeit, amelyekhez nincs közvetlenül rákövetkezı elem, levélszintő elemeknek hívjuk. Nevezetes fák a rendezıfák, mert ezeket gyakran alkalmazzák a tartalom szerinti (kulcs szerinti) véletlenszerő keresés meggyorsítására, amikor a keresett elemet különösen nagy sokaságban kell megtalálni (lásd indextáblák). A fa tipikus mőveletei: • Egy új B elem hozzáadása a fához, megadva, hogy melyik az az A elem, amelyet a B közvetlenül követ. • A fa egy részfájának a levágása. • A fa egy ágának bejárása a gyökérbıl kiindulva és mindig valamely közvetlenül követı elem irányában lépve. • A fa egy ágának bejárása adott levélszintő elemtıl a gyökérig. • A fa (vagy egy részfája) hierarchikus bejárása. A fa definíciójából következik, hogy minden elemére (csomópontjára) értelmezhetı a szintszáma és a fokszáma. A szintszám az elemtıl – mindig a közvetlenül megelızı elem felé haladva – a gyökérig vezetı útvonal hossza (a gyökér szintszáma 0). A fokszám az elemet a fában közvetlenül követı elemek száma. Egy fa bármely két A, B elemét összeköti egy A=E1, E2, …, En=B lánc, amelyben Ei+1 az Ei-t vagy közvetlenül követı vagy közvetlenül megelızı elem (ez az alternatív feltétel a különbözı i-kre eltérı módon teljesülhet). Az is igaz, hogy a fa bármely két A, B eleméhez pontosan egy olyan összekötı lánc létezik, amely a fa bármely elemét legfeljebb egy alkalommal tartalmazza. Háló Hálót alkotnak például a településeket összekötı útvonalak, de hálóval modellezhetı egy építkezés tevékenységeinek a technológiai sorrend szerinti kapcsolatrendszere is. Általában minden komplexebb folyamat (így egy könyvvizsgálati folyamat is) vagy egy összetettebb viszonyrendszer hálóra képezhetı le. Háló A háló egy összefüggı gráf; másképpen szólva olyan struktúra, 1. amelynek bármely két – nem feltétlenül különbözı – A, B elemére adott, hogy közöttük fennáll-e egy meghatározott A-K-B kapcsolat, és 2. amelynek bármely két A, B elemét összeköti legalább egy A=E1, E2, …, En=B (n>=2) lánc, melyben minden Ei, Ei+1 párra vagy az Ei-K-Ei+1, vagy az Ei+1-K-Ei kapcsolat fennáll. A háló (a gráf) éleit olyan – nem feltétlenül különbözı elemekbıl álló – A, B elempárok alkotják, amely elemek között fennáll az A-K-B kapcsolat.

50


Az értelmezésbıl következik, hogy a háló akár egy A-K-A hurkot is tartalmazhat; továbbá a háló két A, B elemét akár több lánc is összekötheti. A háló fenti értelmezése nyitva hagyja azt a kérdést, hogy a K kapcsolat szimmetrikus-e vagy sem; a szimmetrikus kapcsolaton azt értve, hogy az A-K-B kapcsolat azonos a B-K-A kapcsolattal. Irányított háló: Az irányított háló olyan összefüggı gráf, amelynek éleit meghatározó K kapcsolat nem szimmetrikus, és benne az A-K-B kapcsolat fennállásából nem feltétlenül következik a B-K-A kapcsolat fennállása is. Az irányított háló éleit meghatározó K kapcsolat tekinthetı a szekvenciában vagy a fában értelmezett „közvetlenül követi / megelızi” kapcsolatnak is, de azzal a különbséggel, hogy az irányított hálóban lehet olyan elem, amelyet több különbözı elem követ közvetlenül, és olyan elem is, amelyet több különbözı elem elız meg közvetlenül. Az irányított háló tartalmazhat körutat (hurkot) is, aminek a legegyszerőbb esete az önmagával (visszamutató) kapcsolatban álló elem. Irányítás nélküli háló: Az irányítás nélküli háló olyan összefüggı gráf, amelynek éleit meghatározó K kapcsolat szimmetrikus. Az irányítás nélküli háló elemei közötti kapcsolat nem értelmezhetı „közvetlenül megelızi / követi” kapcsolatként. Ugyanakkor egy Φ irányítás nélküli háló mindig egyértelmően helyettesíthetı egy olyan Ψ irányított hálóval, amelyben pontosan azok az elemek vannak jelen, mint a Φ-ben; továbbá a Φ minden A–B szimmetrikus kapcsolatának megfelel a Ψ-ben a nem szimmetrikus A→B és B→A kapcsolatpár, és a Ψ-ben csak ezek a kapcsolatok állnak fenn. 2.2.3 Ellenırzı kérdések a 2.2. alfejezethez 1. Az adat(mezı) milyen jellemzıit határozza meg az adattípus? 2. Milyen adattípust alkalmazna pénzmozgás vagy számlaegyenleg értékének tárolására? 3. Milyen adattípust alkalmazna a fıkönyvi számlaszám értékének tárolására? 4. Jellemezze a halmaz és a szekvencia adatszerkezeteket! 5. Milyen változatait ismeri a szekvenciának, és ezek miben különböznek? 6. Jellemezze a fa és a háló adatszerkezeteket! 7. Miért könnyíti meg a programozási munkát az a tény, hogy az adatok végtelen sokféle összetétele (kompozíciója) ellenére a lényeges tulajdonságok tekintetében az összetett adatszerkezetek mindössze néhány típusba sorolhatók?


51

2.3 Tárolási szerkezetek Az elıbbi szakaszban tárgyalt összetett adatszerkezetek a memóriában tárolási szerkezetekre képezhetık le. A tárolási szerkezetek elemei címmel rendelkezı és a címük alapján közvetlenül elérhetı tárolóhelyek. Ez a szakasz háromféle tárolószerkezetet ismertet, a vektort, a listát és a multilistát. Ezek kombinálásával persze további tárolási szerkezeteket is kaphatunk. 2.3.1 Vektor A számítógép számára a vektor a legkönnyebben kezelhetı tárolószerkezet, mivel a központi memória maga is egy vektor. Vektor: A vektor azonos mérető tárolóegységekbıl áll, amelyek a memóriában összefüggıen egymás után helyezkednek el (lásd a 2.2. ábrán). A vektor elemei logikailag a sorszámukkal, fizikailag a memóriabeli címükkel hivatkozhatók. A definícióból következik, bármelyik vektorelem címe egyszerően kiszámítható az elsı elem címébıl, az elemek (bájtokban adott) méretébıl és a hivatkozott elem sorszámából. 1. vektorelem (cime: C)

2. vektorelem (címe = C + vektorelem hossza)

3. vektorelem (címe = C + 2* vektorelem hossza)

…

2.2. ábra: Vektor tárolási szerkezet

Mind a halmaz (tömb), mind a szekvencia tárolható vektorban, de csak akkor, ha az adatszerkezet elemeinek maximális száma elıre ismert, és az elemek azonos méretőek. Ha a BEVÉTEL[1..20] 20 elemő tömböt vektorral valósítják meg, akkor egy tömbelem indexe egyértelmően megfelel az azt tároló vektorelem sorszámának, azaz a szomszédos indexő tömbelemek a memóriában szomszédos tárolóegységekben tárolódnak. Ilyenkor bármelyik tömbelem közvetlenül elérhetı, mert az indexébıl kiszámítható a tárolási címe. – Ennek ellenére a tömb adatszerkezet és a vektor tárolási szerkezet nem keverendık össze. A tömbelemek indexével csak akkor azonos a tárolóhelyük sorszáma, ha a tömböt éppen vektorral reprezentálják. (Egyes szakkönyvek éppen fordítva, az adatszerkezetet nevezik vektornak, és a tárolási szerkezetet tömbnek, de az a lényeg, hogy különbséget tesznek közöttük.) Ha egy szekvenciát vektorban tárolnak, akkor a szekvencia elemeinek szomszédosságát az elemeknek a vektor szomszédos sorszámú tárolóegységeire való leképezésével lehet kifejezni. 2.3.2 Lista Amikor halmaz (tömb) vagy a szekvencia mérete dinamikusan változhat, vagy az elemei különbözı méretőek lehetnek, a lista az alkalmasabb reprezentáció.

52

INFORMATIKUS SZAKMAI ISMERETEK Lista

A lista tárolóegységek szekvenciája. A lista elemei – az egyes tárolóegységek – az érdemi adatokon felül egy mutatót is tárolnak. Ez a mutató a szekvenciában közvetlenül következı listaelem címe (lásd a 2.3. ábrán). A mutató alkalmazásából következik, hogy a lista elemei a memóriában szétszórtan helyezkedhetnek el, ezek szekvenciája a tárolóegységeknek nem a fizikai, hanem egy logikai sorrendjét definiálja: Az egyes elemeknek a listán belüli sorszáma és a memórián belüli címe között nincs semmi összefüggés. 1. listaelem

2. listaelem

3. (utolsó) listaelem

adat

adat

adat

mutató = 2. listaelem címe

mutató = 3. listaelem címe

mutató = nullmutató

2.3. ábra: Lista tárolási szerkezet

A listának több elınyös és hátrányos tulajdonsága állapítható meg a vektorhoz képest. Az elınyei: • Egy lista különbözı típusú és mérető adatokat tároló listaelemekbıl épülhet fel. • A lista rugalmasan bıvíthetı, mivel egy új listaelem bármely szabad területre elhelyezhetı a memóriában, függetlenül attól, hogy az új elemet a logikai sorrend szerint a lista végére vagy a lista belsejébe (két másik elem közé) kell-e illeszteni. • Hasonlóan a listából bármely elem egyszerően törölhetı. • A lista elemei könnyen átrendezhetık az eredetitıl különbözı szekvenciába. A lista utóbbi három elınye a vektorral szemben azért áll fenn, mert akár a szerkezet bıvítése, akár egyes elemek törlése, akár az elemek szekvenciájának módosítása a vektor esetében általában a vektor egészének vagy nagyon sok elemének fizikai mozgatásával, átmásolásával jár. Például egy új elemmel való bıvítés esetén az egész listát át kell másolni a memóriában egy olyan szabad területre, ahol az új elemével együtt is összefüggı tartományt alkothat. A lista hátrányos tulajdonsága: A lista adott eleme nem érhetı el közvetlenül, hanem csak az elsı elembıl kiinduló és a mutatók láncolatán haladó kereséssel. Ennél fogva egy listaelem átlagos elérési ideje nagyobb, mint egy vektorelemé. A lista különösen alkalmas a következı tulajdonságú adatszerkezetek tárolására: • változó mérető adatelemeket tartalmazó halmazok és szekvenciák; • szélsıségesen változó elemszámú halmazok és szekvenciák; • az elemek sorrendjét dinamikusan változtató szekvenciák. A szélsıségesen változó elemszámú tömbre példa lehet, amikor egy személyi nyilvántartásból egy adott településen lakók neveit akarjuk kigyőjteni (az adott település alkalmanként más – egyszer egy kis falu, máskor egy nagy város). Tehát a NÉV[ ] tömb ténylegesen szükséges mérete csak akkor derül ki, amikor már megtörtént a nevek kiválogatása a nyilvántartásból. A NÉV[ ] tömb egy listával így valósítható meg: 1. listaelem adata = NÉV[1], 2. listaelem adata = NÉV[2], …. A listának különféle speciális változatai lehetnek: • A ciklikus listában az utolsó elem a legelsı elemre (a lista belépési pontjára) mutat.

ADATSZERVEZÉS, ADATELÉRÉS, ADATBÁZISKEZELİ RENDSZEREK • •

53

A kétirányú lista elemeiben két mutató is van, az egyiken a közvetlenül következı, a másikon a közvetlenül megelızı elem felé lehet haladni. Az ilyen listának általában két belépési pontja is van. Az n-es lista elemeiben n számú mutató van, és eszerint minden listaelemhez legfeljebb n számú listaelem kapcsolódhat közvetlenül. Az ilyen tárolószerkezetben speciális (korlátozott elágazásszámú) fa vagy háló tárolható. Például a bináris fa, amelynek minden eleméhez legfeljebb két rákövetkezı elem lehet (egy baloldali és egy jobboldali), kettes (kettıs) listában tárolható, amelynek elemei két mutatót tartalmaznak: a balmutatót és a jobbmutatót. – Ha az n-es lista fát reprezentál, akkor általában egyetlen belépési pontot elegendı nyilvántartani: a gyökér elemet; ha hálót reprezentál, akkor az összes eleme belépési pont.

2.3.3 Multilista Amikor egy fára vagy egy hálóra semmilyen megszorítás nem ismert akkor a memóriában ezen adatszerkezetek leghatékonyabb tárolási reprezentációja a multilista. – A „leghatékonyabb” jelzı arra utal, hogy a legáltalánosabb esetre is léteznek más tárolási reprezentációk, de azokkal a szokásos hálómőveletek (pl. két csomópont közötti útvonal keresése) nagyobb ráfordítással (lényegesen nagyobb futási idıben) hajthatók végre. Multilista: A multilista egy-egy eleme vagy egy csomópontot, vagy egy „közvetlenül követi” kapcsolatot képvisel; és a következı részekbıl épül fel: a jelzı, az adat, és a kapcsolat mutatója. 1. A jelzı azt jelzi, hogy a multilista adott eleme csomópontot (c) vagy kapcsolatot (k) képvisel-e. 2. Az adat a csomópont esetén annak jellemzıit tartalmazhatja (a példában egyetlen jellemzıt a csomópont nevét írjuk ide). Kapcsolat esetén – legyen az az X csomópont kapcsolata – az X csomópontot az adott kapcsolatban közvetlenül követı csomópont mutatója. (Itt minden mutató alatt a multilista valamely elemének mutatóját kell érteni. Tehát egy csomópont mutatója pontosabban a csomópontot képviselı listaelem mutatóját jelenti, hasonlóan egy kapcsolat mutatója pontosabban a kapcsolatot képviselı listaelem mutatóját.) 3. A kapcsolat mutatója egy csomópont esetén a csomópont egyik (valamilyen rendezettségben elsı) „közvetlenül követi” kapcsolatának mutatója; de üres (null) értéket tartalmaz, ha a csomóponthoz nem tartozik egyetlen azt közvetlenül követı csomópont sem. Kapcsolat esetén – legyen az az X csomópont kapcsolata – ez a rész az X csomópont egy (valamilyen rendezettségben) következı kapcsolatának a mutatója. A multilista definíciója úgy is elıadható, hogy nem használjuk a jelzı mezıt. Ebben a megfogalmazásban a multilistának kétféle – különbözı módon felépülı – eleme van: a csomópont és a kapcsolat. A csomópont szerkezete az adat mezıbıl és az elsı kapcsolat mutatója mezıbıl épül fel. A kapcsolat szerkezete pedig a kapcsolódó csomópont mutatója mezıbıl és a következı kapcsolat mutatója mezıbıl áll. Példaként a 2.4. táblázattal szemléltetjük a 2.1. ábra irányított hálóját ábrázoló multilistát. (Irányítás nélküli háló helyett az azt helyettesítı irányított hálót lehet hasonlóan ábrázolni.) Ebben a 7 csomópontot és a 11 kapcsolatot összesen 18 listaelem képviseli. Az egyszerőség kedvéért a listaelemek mutatóját a listaelemek sorszámával vettük azonosnak. A 2.5. ábrán a mutatók szerinti navigáció is látható.

54

INFORMATIKUS SZAKMAI ISMERETEK Sorszám (a listaelem mutatója)

Jelzı (c: csomópont, k: kapcsolat)

Adat (itt a csomópont esetén annak neve; kapcsolat esetén a kapcsolódó csomópont mutatója)

Kapcsolat mutatója

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

c c k c k k c c k k k k k c k c k k

A B 4 C 7 8 D E 8 4 4 8 14 F 7 G 14 16

3 9 5 10 6 null 11 17 null null 12 13 null 15 null null 18 null

2.4. táblázat: A 2.1. ábra irányított hálóját ábrázoló multilista

7 c

D

k

4

k

8

k 14 14 c

4 c

C

k

4

1 c

A

k

4

8 c

k

7

k

2 c

E

k 14

k

7

k 16

16 c

8

B

k

F

G

8

2.5. ábra: Mutatók szerinti navigáció a multilistával reprezentált hálóban

Megjegyzés: A legáltalánosabb (irányított) hálóknak még két további reprezentációját említjük meg: • A legegyszerőbb, de a legkevésbé hatékony reprezentáció a mátrix. Ebben egy irányított él kiindulási végpontját a mátrix valamely sora, érkezési végpontját pedig valamely oszlopa képviseli, magának az élnek pedig az említett sor és oszlop metszetében álló mátrixelem felel meg. • A hálók elég jó reprezentációja a relációs adatbázisok kapcsolótáblája (lásd a 2.6.2. szakaszban a 2.15. ábrát). Ez hatékonyságban csak annyival rosszabb a multilistánál, amennyivel a tartalom szerinti keresés lassúbb a cím szerinti keresésnél.


55

2.3.4 Ellenırzı kérdések a 2.3. alfejezethez 1. Jellemezze a vektort és a listát az elınyök és a hátrányok tekintetében! 2. Milyen tárolási szerkezettel (szerkezetekkel) reprezentálható a számítógép memóriájában a halmaz? 3. Milyen tárolási szerkezettel (szerkezetekkel) reprezentálható a számítógép memóriájában a szekvencia? 4. Milyen tárolási szerkezettel (szerkezetekkel) reprezentálható a számítógép memóriájában a hierarchia? 5. Milyen tárolási szerkezettel (szerkezetekkel) reprezentálható a számítógép memóriájában a háló?

56


2.4 A háttértárakon, valamint az adatforgalomban alkalmazott adategységek 2.4.1 Fizikai adategységek Az adatokat tartósan nem a számítógép operatív memóriájában, hanem külsı tárolókon tárolják: az intenzíven használt adatokat bármikor elérhetı on-line háttértárakon, az archív adatokat pedig off-line tárakon. Az ilyen tárolókon elhelyezett adatok szervezésének, nyilvántartásának, kezelésének fizikai egységei a (fizikai) fájl és a blokk (fizikai rekord). – Itt a fizikai adategység kifejezés az operációs rendszer1 input/output mőveletekért felelıs magja által látott adategységek (másképpen: az alkalmazáslogikától független adategységek) rövidebb megnevezése. A számítástechnikában a fájl (file) tágabban egyrészt adatnyilvántartási egység, másrészt valamilyen belsı szerkezettel bíró egység. E két minıségbıl a fizikai fálj fogalma csak az elıbbit ragadja meg. Fizikai fájl A fizikai fájl a külsı tárolókon elhelyezett összefüggı adatok nyilvántartásának az operációs rendszer által kezelt alapegysége. A fenti értelmezés két lényeges eleme, hogy (1) a fizikai fájl az adatnyilvántartás alapegysége és (2) az operációs rendszer által kezelt alapegység. Tudni kell, hogy a háttértárak tartalomjegyzéke fájlokat leíró bejegyzéseket tartalmaz, és az (1) bıvebben azt jelenti, hogy a számítógép számára minden külsı adat csak valamely (külön azonosító névvel rendelkezı) fájl részeként létezhet (illetve csak így érhetı el). A (2) pedig azt fejezi ki, hogy a fizikai fájl olyan adategység, amelyet az operációs rendszer (input/output mőveletekért felelıs magja) lát, tehát közömbös az a szerkezete, amelyet csak az adott fájltípus feldolgozására (értelmezésére) szolgáló programok láthatnak. – Amikor tehát arról beszélünk, hogy a fájloknak a tartalmuk, illetve a szerkezetük szerint különféle típusai lehetnek (programfájlok, strukturált adatfájlok, kép-, hang-, szöveg- és más speciális fájlok), akkor már nem a fizikai fájlról, hanem a következı szakaszban sorra kerülı logikai fájlról van szó. (A fájl típusára általában utal a fájl nevének kiterjesztése.) Blokk (fizikai rekord) Bár az operációs rendszer szintjén a külsı adatok nyilvántartásának alapegysége a fájl, de egy adott fájlt az operációs rendszer általában nem egészben írja vagy olvassa, hanem meghatározott mérető részegységekben, ezek a blokkok.

1

Az operációs rendszer olyan alapszoftver, amely nélkül a számítógép érdemben mőködésképtelen. Olyan programok összessége, amelyeknek feladata: a központi egység, a háttértárak és a perifériák együttmőködését megszervezni; hálózatban a számítógépek közötti kapcsolatfelvételt és a kommunikációt megszervezni; a felhasználói programok fejlesztıinek munkáját megkönnyíteni, a változatos típusú hardverkomponensekkel szemben a szoftverek hordozhatóságát lehetıvé tenni; több program (vagy több felhasználó) egyidejő és biztonságos kiszolgálásáról gondoskodni (köztük az erıforrásokat elosztani, az egyes programok és felhasználói környezetek integritását megırizni, egymástól is megvédeni); a felhasználók részére kényelmes kezelıfelületet adni.


57

Blokk (fizikai rekord) A blokk (vagy fizikai rekord) operációs rendszer számára a külsı tárolókon elhelyezett adatok írásának, olvasásának, fizikai elérésének alapegysége. A fájl blokkokra tagolásának semmi köze ahhoz, hogy a fájl milyen jelentéső adatokat tartalmaz, azokra hogyan tagolódik. Egy fájl egész számú azonos mérető blokkból áll. Közvetlen eléréső tárolókon egy fájl blokkjai tetszıleges sorrendben pozícionálhatók. 2.4.2 Logikai adategységek – Strukturált adatok Itt a logikai adategység kifejezés olyan adategységekre utal, amelyek az operációs rendszer számára nem léteznek, csak a speciális alkalmazások látják (és képesek értelmezni) ıket. A logikai adategységek közül is ebben a szakaszban olyan típusúakkal foglalkozunk, amelyeket struk-turált adatoknak szokás nevezni, bár a strukturált jelzı is magyarázatra szorul (lásd itt alább). Mezı, rekord (logikai rekord), (egyszerő) strukturált adatfájl Valamilyen értelemben minden fájl strukturált, amennyiben az azt létrehozó vagy használó alkalmazás számára a fájl szerkezete, a fájl különféle részei felismerhetık, kezelhetık; azonban a jelen szakaszban értelmezett (egyszerő) strukturált adatfájl szerkezete speciális megszorításoknak tesz eleget: formailag és tartalmilag is meghatározott mezıkbıl, illetve rekordokból épül fel. Mezı: A mezı egy specifikált adat számítógépi reprezentációja, amelynek adott az adattípusa, továbbá formailag az elıre adott mérete által vagy valamilyen elhatároló jelek által meghatározott. A fenti értelmezésbe formai tekintetben mind a fix hosszúságú, mind a változó mérető mezı belefér. Az utóbbi aktuális méretét például határoló jelek jelezhetik. A definícióban hivatkozott specifikált adat (lásd az 1.2.1. szakaszban) fogalomból következik, hogy a mezı tervezési szinten valamilyen kategóriára értelmezhetı tulajdonságot képvisel; egy konkrét mezı pedig e tulajdonságnak a kategóriába tartozó konkrét objektumra vonatkozó konkrét értékét tartalmazza. Rekord (logikai rekord): A rekord (a logikai rekord) formai és tartalmi tekintetben meghatározott struktúra. Formai tekintetben a rekord adott mezık adott szekvenciája. Tartalmi tekintetben a rekordot alkotó mezık egyazon kategóriára (jelenségtípusra, egyedtípusra, objektumtípusra) értelmezett specifikált adatok, és egy konkrét rekord mezıi az adott kategória egy konkrét objektumát (példányát) jellemzı értékeket tartalmaznak. A fenti értelmezésbe formai tekintetben mind a fix hosszúságú, mind a változó mérető rekord belefér. Tervezési szinten a rekordból csak a kategória, az egyes mezık által reprezentált tulajdonság és a mezık szekvenciája adottak. Ezzel a tervezés nem konkrét rekordot, hanem rekordtípust határoz meg.

58

INFORMATIKUS SZAKMAI ISMERETEK Egyszerő strukturált adatfájl:

Az egyszerő strukturált adatfájl formai és tartalmi tekintetben meghatározott struktúra: formai tekintetben rekordok adott halmaza vagy szekvenciája, tartalmi meghatározottsága pedig a rekordok tartalmi meghatározottságából következik. Egy fájl esetlegesen többféle típusú rekordot is tartalmazhat. Az a lényeg, hogy mindegyik típus elıre definiált, és a fájlt értelmezı alkalmazások számára felismerhetı. A fentiekkel összhangban, de némileg tömörebben úgy is lehet fogalmazni, hogy az (egyszerő) strukturált adatfájl olyan szerkezet, amely önálló jelentéssel bíró rekordokból épül fel, a rekord pedig önálló jelentéssel bíró mezıkbıl tevıdik össze. 2.4.3 „Nem strukturált” komplex adatok – Multimédia adatok A számítógép technikai fejlıdése lehetıvé tette és az informatika társadalmi elterjedése pedig igényelte, hogy ne csak számokat és betőket tudjunk adatként kezelni, hanem úgynevezett nem strukturált, komplex adatok is tárolhatók, illetve kezelhetık legyenek a számítógépen. Elıször csak a szöveges adatok formázott megjelenítése iránti igény jelentkezett, de innen már csak rövid lépés volt a multimédia adatok, azaz képek, hangok, videó számítógépen való tárolása és kezelése. A multimédia adatok kezelése során három alapvetı problémát kell megoldani: • digitalizálás; • tárolás, tömörítés; • megjelenítés (reprodukálás). A digitalizálás során a valamilyen külsı (sokszor analóg) adathordozón (papíron, filmen, magnó-, vagy videokazettán) létezı adatokat bitek sorozatára kell átalakítani, azért, hogy egyáltalán számítógépen tárolható legyen. A multimédia adatok kezelésének legkritikusabb része az adatok memória-, illetve tárigénye. A tárigény észszerő korlátok között tartása és a még elfogadható adatátviteli idı érdekében szükség van az adatok tömörítésére. Az ilyen adatok gépi értelmezése, a megjelenítés (megszólaltatás) során a digitalizált adatbemenet alapján az eredeti hatást (látványt, hangzást stb.) kell produkálni. A multimédia adatokat kezelı szoftvereknek az értelmezés (reprodukálás) mellett fontos funkciója lehet még a digitalizált adatok manipulálása, továbbszerkesztése, módosítása is. 2.4.4 Ellenırzı kérdések a 2.4. alfejezethez 1. Az operációs rendszer szempontjából mi a külsı tárakban elhelyezett adatok nyilvántartásának alapegysége? 2. Az operációs rendszer szempontjából mi a külsı tárakban elhelyezett adatok fizikai kezelésének (írásának, olvasásának, fizikai elérésének) alapegysége? 3. Mi a kapcsolat a specifikált adat és a mezı között? 4. Mi a különbség a blokk és a rekord között? 5. Mit értenek egyszerő strukturált adatfájl alatt? 6. Milyen alapvetı problémák megoldását jelenti a multimédia adatok kezelése?


59

2.5 Tartalom szerinti adatelérés Ebben az alfejezetben az (egyszerő) strukturált fájl rekordjainak tartalom szerinti keresésérıl, elérésérıl lesz szó. Az itt ismertetett módszerek komoly szerepet játszanak a következı alfejezetbe tárgyalt adatbázisok mőködésében. 2.5.1 Tartalom szerinti adatelérés A 2.2.1. szakaszban már szó volt róla, hogy az on-line háttértárakon tárolt adatok a tárolási címük szerint közvetlenül (véletlenszerően) elérhetıek. Azonban az adatfeldolgozási mőveletekben általában nem egy adott címő rekordot kell elérni, hanem például adott nevő vagy adott lakcímő személy(ek) adatait tartalmazó rekord(oka)t keresünk. Tartalom (kulcs) szerinti keresés / elérés: Ha egy egyszerő strukturált adatfájlban egy nyilvántartási rekordot valamely mezıjének vagy mezıinek tartalma alapján kell megtalálni, akkor ezt tartalom szerinti keresésnek / elérésnek, a keresett értéket (értékegyüttest) pedig keresıkulcsnak nevezzük. A tartalom szerinti elérés csak úgy közelíthetı a közvetlen eléréshez, ha a keresıkulcsból valamilyen módon következtetni lehet a keresett rekord(ok) tárolási címére. Azonban a legegyszerőbb soros (angolul heap) fájlok szervezettsége erre nem ad lehetıséget. Soros elérés: Soros elérésrıl beszélünk az olyan fájlok esetében, amelyek szervezettsége nem tartalmaz semmilyen lehetıséget egy [tartalom (keresıkulcs) → tárolási cím] következtetésre, azaz a tárolási címnek a keresıkulcsból való származtatására. A soros elérés esetén a fájlt az elsı rekordtól kezdve addig kell olvasni, amíg a keresett tartalmú (kulcsú) rekordhoz nem érünk. Magát, a különösebb szerkezet nélküli fájlt is szokás soros (angolul heap) fájlnak nevezni. Direkt (random) elérés Direkt vagy random elérésrıl beszélünk, ha a rekordoknak az egyszerően strukturált fájlba beírásakor, illetve a fájlból visszakeresésekor alkalmaznak egy olyan függvényeljárást (leképezı eljárást), amely a keresıkulcsból tárolási címet állít elı. A megoldás elınye, hogy a keresés meggyorsítása nem igényel járulékos adatokat. Ugyanakkor ez az eljárás csak egyféle kulcs (csak egy szempont) szerinti keresés megkönnyítésére alkalmas; ez a kulcs pedig célszerően a rekordot egyedileg azonosító tartalom, az elsıdleges kulcs szokott lenni. Megjegyzés: A leképezési eljárást hash eljárásnak, az ilyen eljárással szervezett fájlokat (adattáblákat) pedig hash fájloknak (hash tábláknak) is nevezik. Azonos fájlban többféle szempont (többféle kulcs) szerinti keresés meggyorsítására alkalmas az indexszekvenciális elérés.

60

INFORMATIKUS SZAKMAI ISMERETEK Indexszekvenciális elérés

Indexszekvenciális elérésrıl beszélünk, ha az egyszerő strukturált fájlban a rekord kulcs (tartalom szerinti) elérését olyan külön képzett indextábla (indexfájl) segíti, amely éppen azt tartja nyilván, hogy melyik kulcsérték, melyik címen (mely címeken) tárolt rekord(ok)ban található. A relációs adatbázisokban (lásd a 2.6.2. szakaszban) a leggyakrabban ez a megoldás használatos az elsıdleges kulcs, az idegen kulcs vagy bármilyen keresıkulcs szerinti keresés meggyorsítására, ezért a következı szakaszban kicsit bıvebben is lesz róla szó. – Ugyanott megismerhetı az indexszekvenciális elérés egy, az inverztáblákra épülı speciális változata is. Ez a többdimenziós adatbázisokban (2.6.2. szakasz) számít kedvelt megoldásnak. 2.5.2 Az indexszekvenciális elérés mőködése Minden olyan mezıre (vagy több mezıbıl összetett adatra), amely a fájl rekordjainak keresésénél kulcsként számításba jöhet. külön-külön indextáblát építenek fel. Ha például egy személy fájl esetében gyakori a név szerinti keresés, akkor a név mezıre fel kell építeni egy indextáblát. Egyszintő indextábla A legprimitívebb megoldást, az egyszintő indextáblát csak azért mutatjuk be, hogy egy elsı közelítéső képet adjunk a probléma lényegérıl, és elıkészítsük a gyakorlatban is használatos, de bonyolultabb többszintő indextábla megértését. Az egyszintő indextáblát egy olyan külön fájlként lehet elképzelni, amely kétmezıs rekordokból áll (2.6. ábra). Az egyik mezı tartalmazza a keresı kulcsot (példánkban a nevet), a másik pedig az indexet, ami az adott névhez tartozó rekordnak a sorszáma a személy fájlban. A rekordok fix hosszúságúak, így minden rekord címe kiszámítható a sorszámából. Ezen felül az indextábla rendezett a keresı kulcs (a név) szerint, és pont azért gyorsíthatja meg egy adott névhez tartozó személyrekord elérését, mert a rendezett táblában alkalmazható a bináris keresés.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Indextábla a személy fájlhoz Kulcs (itt a név) Index Asztalos Éva 9 Barna Károly 7 Bodor Judit 10 Dénes János 4 Erdei Tamás 6 Gazdag Teréz 3 Kiss József 1 Kiss József 11 Tóth Elemér 2 Varga Tamás 8 Vincze Andor 5

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Személy fájl Név Kiss József Tóth Elemér Gazdag Teréz Dénes János Vincze Andor Erdei Tamás Barna Károly Varga Tamás Asztalos Éva Bodor Judit Kiss József

Többi adat

2.6. ábra: Egyszerő indextábla alkalmazása

Bináris keresés Tegyük fel, hogy a 2.6. ábra szerinti indextábla segítségével kell megkeresni a Varga Tamást leíró személyrekordot. A bináris keresés az indextábla középsı bejegyzésével indul, ez most a 6. bejegyzés, melyben a kulcs ’Gazdag Teréz’. Mivel a karakterláncokra vonatkozó


61

összehasonlítási szabály szerint ’Gazdag Teréz’ < ’Varga Tamás’, ezért biztos, hogy a keresést a továbbiakban már csak 7-11. bejegyzésekben érdemes folytatni. Ezek közül megint a középsıt vesszük, amely a 9. bejegyzés, melyben a kulcs ’Tóth Elemér’ < ’Varga Tamás’. Így a további keresés már a 10-11. bejegyzésekre szőkül. Közülük a 10. bejegyzést tekintve „középsınek”, a harmadik lépésben megtaláljuk a ’Varga Tamás’ kulcsot. A kulcs mellett álló 8as index pedig azt mutatja, hogy Varga Tamás adatait a személy fájlban a 8. rekord tartalmazza. – Vegyük észre, hogy a bináris keresés minden lépésében a felére csökken az indextábla azon bejegyzéseinek a száma, amelyeket még vizsgálni érdemes. Ez azt jelenti, hogy például 1 millió bejegyzés esetén is legfeljebb 20 lépésben megtalálható a keresett kulcs, vagy megállapítható, hogy az adott kulcshoz nem létezik rekord. Soros keresés esetén ezzel szemben ugyanilyen céllal átlagosan fél millió lépésre van szükség. Az olvasóban esetleg felmerül a kérdés, hogy miért nem a személy fájlt rendezik úgy a név (a kulcs) szerint, mint az indextáblát. Szokták ezt is tenni, de ez csak egy kulcsra lehetséges; tehát ha más kulcs szerint is szeretnének keresni, arra már mindenképpen külön indextáblát kell készíteni. A gyakorlatban tisztán a 2.6. ábra szerinti indexelés nem hatékony, mert ha a kulcsok száma elég nagy, akkor egy ilyen indextáblába nagyon sokáig tart egy újabb kulcsot beszúrni úgy, hogy a tábla a kulcsok szerint továbbra is rendezett maradjon. Ezért az indextáblát vagy hash módon szervezik (azaz az indexrekordokból építenek random fájlt), vagy többszintő indexelést alkalmaznak. Itt az utóbbi tárgyalásával folytatjuk. Többszintő indextábla A többszintő indextáblák lényegében rendezıfát reprezentálnak (a fa összetett adatszerkezet leírását lásd a 2.2.2. szakaszban). A rendezıfa azért tudja meggyorsítani a keresést, mert benne a szükséges elemi elérések száma nem a kulcsok számával hanem csak a fa szintjeinek a számával arányosan növekszik. Az ilyen indextáblában az indexrekordok (bejegyzések) összefüggı blokkokat alkotnak. Ez a blokk a 2.3.1-ben tárgyalt vektornak felel meg. Egy blokkon belül a kulcsok mindig növı sorrendben rendezettek, és az is igaz, hogy a blokkon belül a keresés sorosan történik. A rendezıfa minden csomópontjából legfeljebb annyi ág indulhat ki, ahány indexrekord fér egy indexblokkba. A 2.7. ábrán az indextábla blokkonként legfeljebb négy indexrekordot tartalmaz, tehát a fa minden csomópontjából legfeljebb négy ág indulhat ki. Az indexblokkok között van egy kitüntetett: az indextábla belépési pontja, a gyökérblokk, ez a példában történetesen a 8. blokk. A 0 típusú blokkok alap-indexbejegyzéseket (rekordokat), az 1 típusú blokkok magasabb szintő indexrekordokat tartalmaznak. Az alap-indexrekordokban a mutató a kulcshoz tartozó adatsor adattáblabeli sorszámát adja meg. A magasabb szintő indexrekordokban a kulcs melletti mutató annak az (alacsonyabb szintő) indexblokknak a sorszáma, amelyben az adott kulcs a legnagyobb értékő. A 2.8. ábra magyarázza, hogyan kell elképzelni az indexblokkok alkotta fastruktúrát; illetve a gyökérblokkból indulva, hogyan lehet megtalálni egy adott kulcsú adatsorra mutató indexrekordot. Például az ’LC’ kulcsú sor sorszáma az indextáblából így kereshetı ki: A 8-as blokkban (a gyökérblokkban) az 1. indexrekord az ’LC’ <= ’SE’ egyenlıtlenség fennállása és mutató=3 miatt jelzi, hogy a keresést a 3-as blokkban kell folytatni. További lépések: A 3-as blokkban a 3. indexrekord: ’LC’ <= ’NK’ és mutató=2. A 2-es blokkban (ez már alapindexblokk) a 3. indexrekord: kulcs=’LC’ és mutató=15, tehát a keresett adattáblasor száma: 15. – A 2.8. ábra rendezıfája 3 szintő, ezért benne a 16 kulcs bármelyike legfeljebb 3 lépésben megtalálható. Általában n kulcs esetén a csomópontonként legfeljebb k ágat megengedı fában a szintek száma (felülrıl) logkn-hez közelít. Ez annál jobb közelítés, minél kiegyensúlyo-

62


zottabb a rendezıfa. A kiegyensúlyozást az indextábla idıszakonkénti újraszervezésével érik el. A kiegyensúlyozott rendezıfákat az angol balanced tree kifejezés után röviden btree néven emlegetik.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

Adatfájl Kulcs Adat FA KF AD NK EP SE BI PF DS TV JE QI FA HA LC RI

Többszintő indextábla (4 indexrekord / indexblokk) Blokk Indexrekord1 Indexrekord2 Indexrekord3 típusa Kulcs Mutató Kulcs Mutató Kulcs Mutató 0 AD 3 BI 7 DS 9 0 JE 11 KF 2 LC 15 1 EP 1 HA 4 NK 2 0 FA 1 FA 13 HA 14 0 PF 8 QI 12 RI 16 0 TV 10 1 TV 6 1 SE 3 TV 7

1. 2. 3. 4. 5. 6. 7. 8.

Indexrekord4 Kulcs Mutató EP 5 NK 4 SE 5 SE

6

gyökérblokk A 0 típusú blokkok alap-indexbejegyzéseket (rekordokat), az 1 típusú blokkok magasabb szintő indexrekordokat tartalmaznak. Az alap-indexrekordokban a mutató a kulcshoz tartozó adatsor adattáblabeli sorszámát adja meg. A magasabb szintő indexrekordokban a kulcs melletti mutató annak az (alacsonyabb szintő) indexblokknak a sorszáma, amelyben az adott kulcs a legnagyobb értékő. 2.7. ábra: Többszintő indexelés

1.

0

8.

1

SE

3

2

SE

5

3.

1

EP

1

HA

4

NK

AD

3

BI

7

DS

9

EP

5

4.

0

FA

1

FA 13 HA 14

2.

0

JE 5.

TV

7

7.

1

TV

6.

0

TV 10

6

11 KF

2

LC 15 NK

4

0

8

QI

16 SE

PF

12

RI

6

2.8. ábra: Többszintő indextábla mint rendezıfa

Most nézzük, mi történik, ha az eddig mutatott indextáblába beszúrjuk az ’LP’ kulcsot! A 2.8. ábrán látszik, hogy az új ’LP’ kulcsnak a 2-es alapindexblokkban lenne a helye, a rendezettség szerint az ’LC’ és az ’NK’ kulcsok között, de a 2-es blokk már betelt. Ekkor a 2es blokk „osztódik”, pontosabban: a rendszer lefoglal egy újabb blokkot, a 9-est, és a 2-es blokk felsı fele (amely az ’LC’ és az ’NK’ kulcsú indexrekordokból áll) abba vivıdik át (a 2es blokkban az eredeti helyük kiürül). – E mőveletek azonban a 3-as magasabb szintő indexblokk tartalmára is hatással bírnak, mert abban az [NK; 2] tartalmú indexrekord hamis lett, hiszen a 2-es blokkban a legnagyobb kulcs már nem az ’NK’, hanem a ’KF’; azon felül az új (9-es) blokkot is be kell kapcsolni a fába, és az ’NK’ most már ebben lesz a legnagyobb kulcs.

63


Lényegében az eddigi [NK; 2] tartalmú indexrekord helyett két (magasabb szintő) indexrekordot kell létrehozni: egy [KF; 2] és egy [NK; 9] tartalmút. A rendezettség szerint mindkettınek a 3-as blokkban lenne helye, de az lehetetlen, mert a 3-as blokk már betelt. Így a 3-as blokk is „osztódik”: a rendszer megint lefoglal egy újabb blokkot (a 10-est), amelybe átvivıdik a 3-as blokk felsı fele, és az [NK; 2] tartalmú indexrekord már a 10-es blokkban cserélıdik le a [KF; 2] és a [NK; 9] tartalmú indexrekordokra. – Még ezzel sincs vége, mert esetünkben az alsóbb szinteken történt változások hatása eléri a 8-as blokkot is. Abban az [SE; 3] tartalmú (magasabb szintő) indexrekord vált hamissá, mert a 3-as blokkban a legnagyobb kulcs már nem az ’SE’, hanem a ’HA’; azon felül a legújabb (10-es) blokkot is be kell kapcsolni a fába, és az ’SE’ immár ebben lesz a legnagyobb kulcs. Tehát az eddigi [SE; 3] tartalmú indexrekord helyett két (magasabb szintő) indexrekordot kell létrehozni: egy [HA; 3] és egy [SE; 10] tartalmút, azaz a gyökérblokkban az eddigi két rekord helyett három lesz kitöltve. Esetünkben a gyökér még nem telt be, ezért további lépésekre már nincs szükség. – A végeredményt a 2.9. ábra mutatja. 8.

3.

1

EP

1

HA

1

0

AD

3

BI

7

DS

4.

0

FA

1

FA 13 HA 14

2.

9

0

3

SE 10 TV

7

4 10.

1.

HA

EP

JE 9.

1

KF

2

NK

9

SE

7.

1

TV

6

6.

0

TV 10

16 SE

6

5

5

11 KF 0

2

LC 15 LP 5.

0

PF

17 NK

4

8

12

QI

RI

2.9. ábra: Többszintő indextábla az ’LP’ kulcs beszúrása után

Ha már a gyökérblokk is betelt, a következı új gyökérszintő indexrekord már csak úgy helyezhetı el, ha a gyökérblokk is „osztódik”, egyben az eddigi gyökérblokk gyökér minısége megszőnik. Részleteiben: a rendszer két új blokkot foglal le; az egyiket (legyen ez az m. blokk) arra a célra, hogy abba viszi át a gyökérblokk felsı felében lévı indexrekordokat; a másikat pedig arra a célra, hogy ez legyen az új gyökérblokk. Ez utóbbiban két (magasabb szintő) indexrekord lesz: az elsı a korábbi gyökérblokkra mutat, a második pedig a fentebb említett m. rekordra. Vegyük észre, hogy amikor a gyökérblokk osztódik, akkor az indextábla emelkedik egy újabb szinttel. Fordítva is igaz: az indextábla szintjeinek száma pontosan akkor növekszik eggyel, amikor a gyökérblokknak (is) osztódni kell.

64


Inverztábla A többdimenziós adatbázisokban kedvelt megoldás az inverztábla, amelynek tárgyalására azért az indexszekvenciális eléréssel közös szakaszban kerül sor, mert felfogható az indextáblák egy speciális változatának is. Ugyanakkor látni fogjuk, hogy az inverztábla mind az alkalmazási területében, mind a megoldásának részleteiben elég sok különbséget mutat az idáig tárgyalt indextáblákhoz képest, és az inverztáblára magára is többféle megoldás létezik. Ez az oka annak, hogy az inverztáblát a szakmában gyakran a tartalom szerinti adatelérés egy önálló kategóriájának tekintik. Inverztáblát olyan tulajdonságra (adatmezıkre) érdemes készíteni, amely az adatfájl rekordjainak (vagy adattábla sorainak) nem azonosító, hanem osztályozó ismérve. – Éppen ilyen tulajdonságok a többdimenziós adatbázisok dimenzióadatai (lásd a 2.6.2. szakaszban). Példa osztályozó ismérvre: A cikk (cikkód) nem azonosítója az eladástételeknek, mert azonos cikkbıl folyamatosan újabb és újabb tételeket adhat el a cég, tehát azonos cikk több eladástételt jellemezhet, másképpen az eladástételek egy osztályát különíti el. (Ha ez a cég arra kíváncsi, hogy egy adott idıszakban történt eladásokkal adott cikkbıl milyen árbevételt realizált, akkor azt az eladástételek megfelelı cikkhez – és idıszakhoz – tartozó osztályából kell összesíteni.) Ha az eladástételeket jellemzı cikkódra (normál) indextáblát hozunk létre, akkor abba egy cikkód-érték annyiszor kerül be keresıkulcsként, ahány eladástétel hivatkozza ezt a cikkód-értéket. Ugyanúgy, ahogy a 2.7. ábrán az ’FA’ kulcs két (alapszintő) indexrekordban is szerepel (a 4-es blokkban), mert az adatfájl két rekordjában (az 1. és a 13. rekordjában) is ’FA’ a kulcs értéke. Ezzel szemben az inverztáblát úgy kell elképzelni, hogy abba egy kulcsérték (cikkód) csak egyszer kerül be, és mellette nem egyetlen mutatóérték áll, hanem (a legprimitívebb változatban) egy vektor, amely (A) az adott cikkre vonatkozó eladástételek (adatfájlbeli) mutatóival van töltve, vagy (B) egy bittérképet tartalmaz. (A 2.10. ábra mindkét változatot mutatja.) A bittérkép egy bitje az adatfájl egy rekordját képviseli, azaz a bittérkép annyi bitbıl áll, ahány rekordja van az adatfájlnak. Adott kulcsértékhez tartozó bittérképben a k. biten pontosan akkor áll 1-es, ha e kulcsérték jellemzi az adatfájl k. rekordját.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Adatfájl (v. tábla) Kulcs Adat NK EP NK NK SE EP EP HA SE EP EP NK EP

A) Inverztábla mutatóvektorral Kulcs Mutatók vektora EP 2 6 7 10 11 HA 8 NK 1 3 4 12 SE 5 9

B) Inverztábla bittérképpel Kulcs EP 0 1 0 0 0 HA 0 0 0 0 0 NK 1 0 1 1 0 SE 0 0 0 0 1 1.

2.

3.

4.

5.

Bittérkép 1 1 0 0 0 1 0 0 0 0 0 0

0 0 0 1

6.

9.

7.

8.

2.10. ábra: Inverztábla a legprimitívebb változatokban

13

1 0 0 0

1 0 0 0

0 0 1 0

1 0 0 0

10. 11. 12. 13.


65

Azonban az inverztáblának a 2.10. ábrán mutatott mindkét megoldása tökéletesítésre szorul 1. Új kulcsokkal ugyanolyan nehezen bıvíthetı, mint az egyszerő indextábla. – Erre az lehet a megoldás, hogy a kulcsokat nem egyetlen rendezett vektorban tároljuk, hanem egy rendezıfában, mint a többszintő indextábla esetében, de most az alap-indexrekordokban a kulcs mellett a Mutató mezıben a kulcshoz tartozó mutatóvektor vagy bittérkép címe állhat. 2. A mutatóvektor változó hosszúságú: az egyik kulcshoz csak egy mutató, a másikhoz pedig akár több millió is tartozhat, másrészt az egyes vektorok hossza is dinamikusan bıvülhet. E körülmény miatt, vektor helyett tárolhatjuk inkább listában az egy kulcshoz tartozó mutatókat (lásd a 2.3.1-2.3.2. szakaszokat). – Azonban az optimum lehet valamilyen köztes megoldás: olyan fix hosszúságú vektorokat alkalmazunk, amelyekbıl a kulcsok egy elıre adott hányadához elegendı egyet felvenni, mert a kulcshoz tartozó mutatók mind elférnek benne. Azon kulcsok esetében, amelyekhez több mutató tartozik, mint amennyi az ilyen vektorban elfér, több vektorból listát építünk. 3. A bittérkép mérete ugyan minden kulcsnál egyforma, de ez is dinamikusan bıvülhet, hiszen ha az eredeti adatfájl bıvül valamennyi rekorddal, akkor a bittérképnek is bıvülni kell ugyanannyi bittel. – Itt is élhetünk azzal a megoldással, hogy elıre adott bitszámú (tehát fix hosszúságú) bitvektort használunk, és ha a bittérkép hossza meghaladja egy ilyen vektor hosszát, akkor több vektort főzünk egy listába. – Nagyon nagy mérető bittérképre ugyanolyan tömörítı eljárás is alkalmazható, mint a fájlokra. Ez a megoldás azonban további következményekkel jár: (a) a tömörített bittérkép már nem lesz azonos hosszúságú a különbözı kulcsok mellett, (b) a kulcshoz tartozó rekordok elérési ideje növekszik a tömörített bittérkép „kicsomagolásának” idejével. 2.5.3 Ellenırzı kérdések a 2.5. alfejezethez 1. Milyen fajtáit ismeri a tartalom szerinti adatelérésnek / keresésnek? 2. Hogyan oldható meg az adatrekordok több szempontú keresésének meggyorsítása? 3. Hogyan mőködik a bináris keresés? 4. A gyakorlatban miért nem alkalmazható az indextábla? 5. A többszintő indextábla milyen összetett adatszerkezetet alkot? 6. A többszintő indextábla egy indexblokkja milyen tárolási szerkezetet alkot? 7. A többszintő indextábla miért tudja meggyorsítani a keresést? 8. A többszintő indextábla mennyivel "tud többet" az egyszintő indextáblánál? 9. Hogyan történik a többszintő indextábla kiegyensúlyozása? 10. Elsıdleges kulcsra érdemes-e inverztáblát felépíteni? 11. Készítsen egy soros eléréső mintafájlt, és valamelyik mezıjére építsen fel egy inverztáblát!

66


2.6 Adatbáziskezelı rendszerek 2.6.1 Az adatbázis fogalma Az egyik, szinte minden üzleti alkalmazásban jelen lévı IT megoldás az adatbázis, az integrált vállalatirányítási rendszerek legtöbb elınye éppen a szervezeti szinten közös adatbázison alapul. Adatbázis Az adatbázis adatok olyan rendszere, amelynek használatán több felhasználó, a szervezet több egysége vagy több alkalmazás osztozik, benne a különbözı jelenségekre vonatkozó ismeretek egymással alkotott természetes összefüggéseik szerint szervezettek, és amely független az ıt feldolgozó programoktól. [Halassy-1994] Az adatok természetes összefüggéseik szerinti szervezettsége közelebbrıl azt jelenti, hogy az adatbázis nem pusztán az adatokat, hanem azoknak a – szakterületi, üzleti szabályokat kifejezı – kapcsolatait is tartalmazza. Az adatbázis struktúrája e kapcsolatok reprezentálására szervezett, és az adatbáziskezelı támogatja az adatoknak a kapcsolatok mentén haladó kényelmes és gyors elérését. Papír (dosszié)

Adatbázis

Elérhetıség

Az adat csak másolás útján érhetı el egyidejőleg több helyen.

Az adat másolás nélkül minden illetékes számára egyidejőleg azonnal elérhetı.

Idıszerőség

Amikor az adat elévült, újabb dokumentumot kell készíteni az adat aktuálisan érvényes értékével, amelynek a másolatait szintén szét kell küldeni az érdekelteknek.

Az adatot azonnal módosíthatja, aki a változásról tudomást szerez (és a módosításra jogosult). A változás minden illetékes érdekelt számára azonnal látható lesz.

Felhasználás módja, lehetısége

A papírdokumentáció a párhuzamosan végezhetı feladatokat is soros végrehajtásra kényszeríti. Az ügyviteli vagy tervezési folyamat részvevıje csak akkor foghat hozzá a maga feladatának elvégzéséhez, amikor a dosszié hozzá érkezett. Emiatt a folyamat átfutási ideje hosszabb lesz.

Az adatbázissal támogatott tervezési vagy ügyviteli folyamat részvevıi mind elejétıl fogva látják a döntéseikhez szükséges forrásadatokat. Az egymástól független szempontok szerinti döntések párhuzamosan meghozhatók. Esetleg egymással összefüggı döntések esetében is hatékony lehet a párhuzamos 2 munkavégzés.

A papíron rögzített adat passzív, mert emberi közremőködés nélkül nem indítja el a szükséges reakciót.

Az adatbázis olyan szabályokat (eljárásokat) is tárolhat, amelyek kitüntetett adatváltozások esetén automatikusan kezde3 ményeznek valamilyen tranzakciót.

2.11. táblázat: A papíron, illetve adatbázisban történı adattárolás összehasonlítása

2

Pl. ha a gyártmánytervezı változtatott a termék tervén, a gyártástervezı azt idıben látja, és a saját munkájából több lépés helyett csak egyet kell megismételni ahhoz, hogy a gyártástechnológiát a gyártmány tervéhez igazítsa. Adatbázis alkalmazása esetén az is kivihetı, hogy adatbázisszabállyal automatizáljuk egy döntés változtatása következményeinek átvezetését a tıle függı más döntéseken. 3 Pl. az adatbázisban tárolható olyan szabály, hogy a készlet adott szint alá süllyedése esetén a rendszer automatikusan küldjön valamilyen e-business csatornán rendelést a szállítónak.


67

Az adatbázis programfüggetlensége részben szintén annak a következménye, hogy az adatbázis az adatok kapcsolatait is tartalmazza, tehát a kapcsolatok realizálása nem igényel külön felhasználói programot. Az adatbázis és a programok közötti (kölcsönös) függetlenséget megalapozó további körülmények: • Az adatbázis az adatszótárában tartalmazza saját definícióját (az adatbázissémát), minek következtében az adatstruktúrákat nem kell a programokban leírni. • Minden adatbázis-szolgáltatást végsı soron az adatbáziskezelı (szerver) végez. A programokban csak a kívánságokat kell megfogalmazni. Az adatbáziskezelı nyelvén (ez a manapság elterjedt relációs és objektumrelációs adatbázisoknál történetesen az SQL) kiadott parancsokkal felhasználói program nélkül is hozzáférhetı az adatbázis. Az adatbázis lényegéhez tartozik a konkurens felhasználás: az adatokat akár egyidejőleg is több (arra jogosult) felhasználó lekérdezheti vagy aktualizálhatja. Az adatbázis kihasználhatóságát növeli, ha a felhasználók különbözı helyszíneken tartózkodhatnak, sıt akár mozgásban is lehetnek. A konkurens használatot az adatbáziskezelı rendszer, a bárhonnan és bármikor való elérést a hálózati infrastruktúra (kiterjedtebben az Internet a vezeték nélküli – wireless – adatátviteli technikákkal kombinálva) és a mobil eszközök (laptop, PDA) teszik lehetıvé. A 2.11. táblázat áttekint néhány olyan jellemzıt, amelyben az adatbázisban tárolt adatok lényegesen különböznek a papíron (dossziéban) tárolt adatoktól. Ilyenek az elérhetıség, az idıszerőség, a felhasználás módja és lehetısége. 2.6.2 Az adatbázis szerkezete – Adatbáziskoncepciók Az elıbbi szakaszban adott definíció az adatbázis egyik lényegi sajátosságaként jelölte meg, hogy benne az ismeretek (adatok) a természetes összefüggéseik szerint szervezettek. Ez közelebbrıl azt jelenti, hogy az adatbázis olyan szerkezettel bír, amely képes kifejezni az adatoknak – pontosabban az adatokkal leírt jelenségeknek, egyedeknek, objektumoknak – az alkalmazási terület által definiált viszonyait, kapcsolatait. A kapcsolatoknak valamilyen szerkezetre való leképezésére többféle koncepció született. Ezek: • Hierarchikus-hálós modell (a CODASYL bizottság DBTG munkacsoportja4 által kidolgozott koncepció [CODASYL-1971]) Alapegysége a rekordtípus. A rekordtípusok kapcsolatait tárolási mutatókkal fejezik ki (másképpen szólva: az adatelérést a tárolási mutatókkal navigálják). • Relációs modell [Codd-1971]: Alapegysége a kétdimenziós táblázat. A táblázatok kapcsolatainak kezelését tartalmi szinten, idegen kulcsok használatával oldja meg. • Objektumorientált modell: Az objektumorientált technológiának az adatbázisokra való alkalmazása. Alapegységei az objektumok, amelyek nemcsak adatokat és adatkapcsolatokat, hanem ezeken értelmezett mőveleteket is reprezentálnak. – A kapcsolatok kezelésében a hierarchikus-hálós modellel rokon, mert a kapcsolatokat ez is tárolási mutatókkal fejezi ki. • Többdimenziós modell: Az on-line elemzı alkalmazások (On-Line Analytical Processing – OLAP rendszerek) többdimenziós adatnézetének megvalósítására optimalizált modell. Alapegysége a többdimenziós elemi adatkocka (adatcella). A gazdasági szervezetekben a végrehajtást és részben a középvezetést támogató tranzakciókezelı feldolgozások korábban a hierarchikus-hálós adatbázisokra, késıbb pedig a relá4

CONFERENCE ON DATA SYSTEM LANGUAGES DATA BASE TASK GROUP

68


ciós adatbázisokra épültek, jelenleg pedig jellemzıen az utóbbiak objektumrelációs változataira. A vezetıket – különösen a stratégiai vezetést – kiszolgáló üzleti intelligencia alkalmazások és azok OLAP (on-line elemzı) eszköztára általában egy speciális adatbázis, az adattárház felett dolgozik, és ennek szerkezete optimálisan a többdimenziós modellt követi. Az adatokkal leírandó egyedek közötti hierarchikus kapcsolat bemutatására az alábbi keretezett részben adott problémát, az elıbbiekben felsorolt adatbázismegoldások közül az elsı kettı szemléltetésére pedig a probléma kétféle megoldását használjuk fel. Tekintsük egy értékesítési rendszer által definiált azon kapcsolatot, hogy egy rendelés egy jól meghatározott vevıtıl érkezik. Megmutatjuk, hogy ezt a kapcsolatot hogyan fejezi ki a hierarchikushálós, illetve a relációs koncepció szerint szervezett adatbázis. Mindkét megoldásnál szerepet fog játszani az a tény, hogy a vevık és a rendelések kapcsolata egy nem szimmetrikus egy-a-többhöz viszony: Egy adott vevıtıl több rendelés érkezhet, de egy adott rendelés feladója határozottan csak egy vevı lehet. (Ilyen aszimmetria miatt a „többes oldali” rendelést az „egyes oldali” vevı alárendeltjének, illetve az utóbbit az elıbbi fölérendeltjének tekintik.)

Hierarchikus-hálós modell (a CODASYL javaslat szerinti adatbázisszerkezet) Az 1970-es évek elejétıl megjelenı hierarchikus-hálós adatbáziskezelık neve arra utal, hogy ezekkel hierarchikus és hálós adatkapcsolatokat lehet ábrázolni. (Ugyanakkor ez az elnevezés nem a lényeget ragadta meg, mert mint látni fogjuk, erre a relációs adatbázisok is képesek.) Ezen adatbázisok igazi megkülönböztetı sajátossága az volt, hogy a CODASYL javaslat szerinti (vagy ahhoz közeli) megoldást alkalmaztak. Ezért a hierarchikus-hálós modellt gyakran a CODASYL koncepció szinonímájaként emlegetik. A CODASYL koncepciót annak részletes elméleti tárgyalása helyett az imént bekeretezetten adott példa CODASYL javaslat szerint szervezett megoldásának bemutatásával világítjuk meg: Lesz egy vevı rekordtípus és egy rendelés rekordtípus. Mind a két rekordszerkezet az érdemi (a vevıt, illetve a rendelést leíró) adatok mezıin felül tárolási mutatókat tartalmazó mezıkkel is kiegészül. Ezek a vevıt és a hozzátartozó rendeléseket egy ún. setbe kötik össze. A vevı és a rendelései közötti kapcsolat aszimmetriájával összhangban, a setben a vevıt tulajdonosnak, a rendeléseit pedig tagoknak nevezik. Azonos settípus kifejezésére többféle mutatót is használnak, annak megfelelıen, hogy általában többféle irányú navigációt kell támogatni. Így a példánk szerinti vevı–rendelés setben hol arra lehet szükség, hogy adott vevı rendeléseit megtaláljuk; hol arra, hogy egy rendeléstıl kiindulva elérjük az azt feladó vevı adatait is. A vevı → rendelés irányú navigáció céljából olyan m1 mutatót alkalmaznak – mind a vevı, mind a rendelés rekordokban –, amely a vevıt és a rendeléseit egy listába (lásd a 2.3.2. szakaszban) főzi fel; a lista belépési pontja a vevı (a tulajdonos): az ı m1 mutatója a vevı elsı rendelésére mutat. A rendelés → vevı irányú navigációt pedig a rendelés rekordban elhelyezett olyan m2 mutató segíti, amely mindig a vevıre (a tulajdonosra) mutat. A vevı és a rendelés kapcsolatának aszimmetriája az m1 és m2 mutatók eltérı mőködésében nyilvánul meg. Az említetteken felül további mutatókat is használhatnak, ha például azonos vevı rendeléseinek többféle rendezésben történı bejárhatóságát akarják biztosítani. (Lásd a 2.12. és a 2.13. ábrákat!)

ADATSZERVEZÉS, ADATELÉRÉS, ADATBÁZISKEZELİ RENDSZEREK cím rendelés adatai m1 mutató

m2 mutató

230 rendelés1

289

170

289 rendelés2

308

170

308 rendelés3

351

170

351 rendelés4

null

170

cím vevı adatai

69

m1 mutató

170

230

2.12. ábra: Példa a kapcsolatok tárolási mutatókkal való kifejezésére

vevõ

rendelés1

rendelés4

rendelés2

rendelés3

m1: a vevõ --> rendelés navigációt segítõ mutató m2: a rendelés --> vevõ navigációt segítõ mutató (ilyen csak a rendelés rekordban van)

2.13. ábra: A tárolási mutatókkal megvalósított kétféle navigáció egy setben

Relációs modell Az 1970-es évek elejétıl megjelenı hierarchikus-hálós adatbáziskezelık mind a CODASYL javaslat szerinti (vagy ahhoz közeli) megoldást alkalmaztak. Bár a relációs modell gondolata némileg elıbb született, mint a CODASYL javaslat, a relációs adatbázisok alkalmazása csak az 1980-as évek közepétıl kezdett tömegesen elterjedni, hogy azután szinte teljesen kiszorítsa a hierarchikus-hálós adatbázisokat. Az alfejezet bevezetıjében bekeretezetten adott példa megoldása a relációs modell szerint a következı: Lesz egy vevı táblázat és egy rendelés táblázat. (A táblázat a matematikai reláció fogalom megfelelıje, innen a relációs adatbázis neve.) – Eddig nem nagyon tértünk el

70


az elızı megoldástól, mert a vevı-táblázat sorai megfelelnek a vevı-rekordoknak, a rendeléstáblázat sorai pedig a rendelés-rekordoknak. A táblázatok oszlopai pedig kijelölik a rekordok mezıit. – A vevı-táblázatban kell lenni egy olyan oszlopnak, amelyben álló értékek mindegyike a sorában álló vevıt azonosítja, pl.: vevıkód. Ezt másképpen a vevı elsıdleges kulcsának nevezik. Ugyanakkor a vevıkód a rendelés-táblázat oszlopaként is megjelenik, ott már mint idegen kulcs, és soronként azt hivatott jelezni, hogy az adott sorban leírt rendelést melyik vevı adta fel. (Az a tény, hogy a vevı fölérendeltje a rendelésnek, éppen abban nyilvánul meg, hogy a vevı azonosítója jelenik meg a rendelés táblában idegen kulcsként, nem pedig a rendelés azonosítója a vevı táblában.) A vevı → rendelés irányú navigáció most logikailag azt jelenti, hogy a rendelés táblában az adott vevıkódot idegen kulcsként tartalmazó rendeléssorokat keresik meg. A rendelés → vevı irányú navigáció pedig logikailag úgy történik, hogy a rendelés sorból kiolvassák a vevıkódot, majd megkeresik az azzal azonosított sort a vevı táblában. (Lásd a 2.12. ábrát!) A „logikailag” módhatározó azonban mindkét esetben lényeges, mert itt nem cím szerinti, hanem tartalom szerinti elérésrıl van szó. A 2.5.1. szakaszban láttuk, hogy a tartalom szerinti elérés csak akkor hatékony, ha a tartalomból valamilyen módon származtatható az azt tároló rekord (itt táblázatsor) címe. Ennek érdekében mindkét adattábla fölé külön-külön indextáblát (lásd a 2.5.2. szakaszban) építenek fel a vevıkód kulcsra. A vevı → rendelés irányú navigációt a rendeléstábla fölé, a rendelés → vevı irányú navigációt pedig vevı tábla fölé felépített indextábla segíti. Rendelés tábla rendelés adatai 2005-ös vevı 1. rendelése 2005-ös vevı 2. rendelése 2005-ös vevı 3. rendelése 2005-ös vevı 4. rendelése 3910-es vevı 1. rendelése 3910-es vevı 2. rendelése

…

Vevı tábla vevıkód

vevıkód

(idegen kulcs)

(kulcs)

2005 2005 2005 2005 3910 3910 …

2005 3910 …

vevı adatai 2005-ös vevı adatai 3910-es vevı adatai

…

A kapcsolat mentén történı navigáció még két indextáblát is igényel a vevıkód kulcsra: egyet a rendelés tábla fölé, egyet a vevı tábla fölé.

2.14. ábra: Kapcsolat megvalósítása idegen kulccsal a relációs modellben

Megjegyzés: Az adatok visszakeresésekor a tárolási mutatók mentén történı navigáció általában lényegesen gyorsabb az idegen kulcsokat használó navigációnál. Ez a tény mindaddig a hierarchikus-hálós adatbáziskezelık elterjedésének kedvezett, amíg az igen magas ár/teljesítmény hányados és az ebbıl adódóan magas gépidıköltség minden más tényezıt háttérbe szorított. Amint az olcsóbb kategóriákban is megjelentek a nagyobb teljesítményő számítógépek, nem volt akadálya annak, hogy a relációs adatbáziskezelık is megfelelı hatékonysággal mőködtethetık legyenek. Ezt követıen az utóbbiak azért tudták kiszorítani az elıbbieket, mert a relációs adatbázisok kevésbé érzékenyek a tárolási szerkezet esetleges meghibásodására (pl. a tárolási mutatók láncolatának sérülése, megszakadása náluk elı sem fordulhat); továbbá rugalmasabbak az adatbázis szerkezetének módosítása, bıvítése tekintetében; valamint a relációs adatbázis újraszervezése mind azonos környezetben, mind új környezetben (hordozhatóság) könnyebben megoldható. Különösen a nyitottság, az alkalmazások hordozhatósága tekintetében az is fontos tényezı volt, hogy a különbözı gyártóktól származó relációs adatbáziskezelık már a kezdetektıl mind közös parancsnyelvet használtak, az SQL-t (lásd a 3. fejezetben).


71

Eddig beláttuk, hogy a relációs adatbázis ugyanúgy alkalmas a hierarchia ábrázolására, mint a hierarchikus-hálós adatbázis (2.14. ábra szerinti példa). A 2.15. ábra bizonyítja, hogy hálós szerkezet is ábrázolható relációs adatbázisban. CSOMÓPONT Csomópontkód

IRÁNYÍTOTT ÉL Csomópontnév

A B C D E F G

…

Kezdetecsomópontkód A A A B C D D D E E F

Végecsomópontkód C D E E C C E F F G D

…

2.15. ábra: A 2.1. ábra szerinti háló ábrázolása relációs adatbázisban két táblával

A 2.1. ábra szerinti háló két táblával, a CSOMÓPONT és az IRÁNYÍTOTT ÉL táblákkal reprezentálható. Az utóbbi tipikus kapcsolótábla, mert kétszeresen is alárendeltje az elıbbinek; más szóval: a CSOMÓPONT kétszeresen fölérendeltje az IRÁNYÍTOTT ÉL-nek, egyszer a kezdete-csomópont szerepben, egyszer pedig a vége-csomópont szerepben. Ennek megfelelıen az IRÁNYÍTOTT ÉL táblázat kétszer tartalmazza a CSOMÓPONT elsıdleges kulcsát, a Csomópontkódot idegen kulcsként: egyszer Kezdete-csomópontkód szerepnévvel, egyszer pedig Vége-csomópontkód szerepnévvel. – Megjegyezzük, hogy a hálós szerkezetek általánosabb esetei olyan kapcsolótáblával oldhatók meg, amely különbözı fölérendelt táblák közös alárendeltje. Objektumorientált modell Ez az objektumorientált technológiának az adatbázisokra való alkalmazása. Alapegységei az objektumok, amelyek nemcsak adatokat és adatkapcsolatokat, hanem ezeken értelmezett mőveleteket is reprezentálnak. Ez a modell elvben nagyon elınyös lenne a nagymérető, komplex objektumok, a képek, hangok, videófelvételek (egy szóval multimédia adatok) vagy a mőszaki tervek grafikus objektumai kezelésére; továbbá azért is, mert jól illeszkedik a ma általánosan használt objektumorientált fejlesztési technológiához. Mégsem terjedt el, mert az egyszerő strukturált adatok esetében – amelyek még mindig a nyilvántartások zömét teszik ki – drága megoldásnak számít, másrészt egységesen elfogadott szabvány hiányában az ilyen adatbázisra épülı rendszerek nem hordozhatók. Ezért helyettük az ú.n. objektumrelációs hibrid adatbázisokat használnak. A tisztán objektumorientált modell a kapcsolatok kezelésében a hierarchikus-hálós modellel rokon, ugyanis a komplexebb adatszerkezetek kezelésében a mőveleti sebesség megint kritikussá vált, így ezeknél ismét a gyorsabb elérést lehetıvé tevı, tárolási mutatókon alapuló navigációt alkalmazzák. – Ezzel szemben az objektumrelációs adatbázisok egyszerően a korábbi relációs adatbázisok új változatai, amelyek az összetett objektumok kezelését azzal könnyítik meg, hogy eltakarják az egy-egy objektum szerkezetét realizáló bonyolult táblakapcsolatokat: ezen kapcsolatok automatikus kezelését az objektumrelációs adatbáziskezelı rendszer magára vállalja.

72


Többdimenziós modell A többdimenziós modell egy olyan absztrakt tér, amelyben az osztályozó szerepet betöltı adatok (dimenzióadatok) segítségével meghatározható bármely osztály elemei (egyedei) egymás közelében helyezkednek el. Az egy osztályba tartozó elemek egymáshoz közeliségének az a jelentısége, hogy ezen elemeket nem a teljes térben kell keresni, mert azok a térnek csupán egy kisebb (a dimenzióadatokkal egyértelmően kijelölt) részét (hipersíkját, szeletét, hasábját) teszik ki. Ha valakit egy adott termék forgalmának alakulása érdekel havonkénti bontásban, akkor ı ebben a virtuális térben az adott terméket érintı összes ügyletet egy tömbben fogja látni, amelyen belül egy-egy hónap ügyletei szintén egy-egy kisebb tömbben helyezkednek el. Ha egy másik elemzıt a termék forgalma településenkénti bontásban érdekel, akkor számára viszont az egy településen történt ügyletek látszanak egy tömbben. A többdimenziós modell elnevezése onnan van, hogy az általa nyújtott (és az iménti példákban bemutatott) látszat analóg a geometriai tér következı tulajdonságaival: Ha a 3-dimenziós tér azon pontjait keressük, melyeknek z-koordinátája egy adott érték, azok mind egy (a z-tengelyre merıleges) síkba simulnak; azok a pontok pedig, melyeknek a z-koordinátája mondjuk az [1; 2] intervallumba esik (1<=z<=2), a tér egy (a z-tengelyre merıleges) szeletébe esnek (2.16. ábra). Ha egyidejőleg az y dimenzióra is adunk hasonló feltételt, akkor azzal az elıbbi térszeletbıl vagy síkból metszünk ki ismét olyan hasábot, síkszeletet vagy egyenest, amelyen túl már felesleges olyan pontot keresni, amely kielégítené a keresı feltételeket. A többdimenziós modellt eredetileg nem mint adatbázis-koncepciót, hanem mint az OLAP alkalmazások számára optimális adatnézetet találták ki. Az erre vonatkozó követelmény-rendszert Codd [4] fogalmazta meg 1993-ban. (Az OLAP elnevezést is ı használta elıször.) A modell alapvetı fogalmai: a dimenzió(adat), a tényadat, az adatkocka, az adatcella (másképpen elemi adatkocka).

2.16. ábra: Térszelet a 3-dimenziós térben – Szemléltetı kép a többdimenziós adatmodellhez

Dimenzió vagy dimenzióadat: Az elemzésekben osztályozó szerepet betöltı, egyben aggregálási szempontot képviselı tényezıket / tulajdonságokat (pl. termék, szállító, vevı, hely, idı, …) nevezik dimenzióadatoknak, rövidebben dimenzióknak.


73

Tényadat: Az elemzett jelenségeket (például gazdasági eseményeket) jellemzı olyan tulajdonságokat, amelyek nem számítanak a dimenzióadatok közé, de azokkal a jelenségek leírásában összekapcsolódnak, nevezik tényadatoknak. Ha például az értékesítéstételeket a következı tulajdonságok (adatok) jellemzik: 1. az (eladott) cikk (azonosítója), 2. a vevı (azonosítója), 3. a vevı címe (település azonosítója), 4. az értékesítés idıpontja, 5. eladási ár, 6. eladott mennyiség, akkor ezek közül az elı négy tulajdonság lehet dimenzióadat, az utolsó kettı pedig tényadat. Ha egy értékesítéstételben a C cikkbıl adtak el a V vevınek a T településre szóló szállítási címmel az I idıpontban az E egységáron M mennyiséget, akkor az értékesítéstétel, a dimenzióadatoknak a C-V-T-I értéknégyesét a tényadatoknak az E-M értékpárjával kapcsolja össze. Adatkocka: N-dimenziós adatkockának nevezik a dimenziók értékkészleteinek Descartes-szorzatát, szemléletesebben az n-dimenziós absztrakt térnek olyan rácspontok által kitöltött részét, amely pontok i. koordinátája az i. dimenzióadat értékkészletébıl veszi értékét. Adatcella vagy elemi adatkocka: N-dimenziós adatcellának, más kifejezéssel elemi adatkockának nevezik az n-dimenziós adatkocka rácspontjait. Tehát egy n-dimenziós adatcellát a különbözı dimenziókból vett n számú érték együttese határozza meg, ezek az értékek az adatcella koordinátái. – Nem minden adatcella képvisel megfigyelt tényt (megfigyelt jelenséget, bekövetkezett eseményt), ha mégis, akkor az adatcella a dimenzióadatokon felül tényadatokat is reprezentál. Így az értékesítéstételeket négydimenziós térrel modellezı fenti példánkban az olyan adatcellák, amelyek egy megtörtént értékesítést írnak le, a négy (C-V-T-I) dimenzióadatból és a két tényadatból (E-M) álló értékhatost reprezentálnak. – Általában egy n-dimenziós adatcella m+n adat együttesével jellemezhetı jelenséget képes reprezentálni, ahol m a jelenség tényadatainak száma, n pedig a jelenség dimenzióadatainak száma. A többdimenziós modellnek léteznek a relációs modellre alapozott megvalósításai is, azaz olyan relációs adatbázisok, amelyekben az OLAP számára kedvezı sémát alakítanak ki. Az „igazi”5 többdimenziós adatbázisok azonban már fizikai szervezettségükben is különböznek a relációs adatbázisoktól: • a kapcsolatok kezelésében a hierarchikus-hálós modellhez nyúlnak vissza, mert a kapcsolatokat tárolási mutatókkal fejezik ki; • a mutatókkal azonban nemcsak egyszerő hierarchikus kapcsolatokat írnak le, hanem olyan inverz táblákat építenek fel, melyekkel bármely dimenzióadat szerinti keresés, osztályozás hatékonyan végrehajtható. Így speciálisan a szeletelés mővelete – azaz bármely dimenzióadat adott értékével jellemzett adatcellák (elemi adatkockák) halmazának elıállítása – rövid idı alatt lehetséges.

5

A macskakörmöket az indokolja, hogy a legvalódibb többdimenziós adatbázist csak többdimenziós térben lehetne megépíteni, de a többdimenziós tér nem fizikai realitás, hanem csak bizonyos összefüggések megvilágítását szolgáló interpretáció.

74


2.6.3

OLTP rendszerek adatbázisai és az adattárház

Az adatbázisokat kezdetben kizárólag az on-line tranzakciókezelı (OLTP) feldolgozások használták, illetve a máig legelterjedtebb relációs adatbázisok is az OLTP feldolgozásokhoz nyújtanak optimális megoldást. Ezért az adatbázisnak van egy olyan szőkebb értelmezése, amely csak az OLTP (vagy ERP) alkalmazások adatbázisát takarja. Az ilyen adatbázisok dominánsan karbantartó mőveletek tárgyát képezik, tehát az adatbázis szerkezetét ezekre kell optimalizálni. A karbantartó mőveletek hatékonysága szempontjából a többszörös adattárolás – azaz a redundancia (lásd az 1.2.4. szakaszban) – hátrányos, mivel többszörös adatkarbantartást is igényel. Következésképpen az OLTP alkalmazások adatbázisának szerkezete csak minimális redundanciát tartalmazhat. (A 2.7. alfejezetben tárgyalt adatmodellezés pont az ilyen szempontú tervezésre van kihegyezve.) Az üzleti intelligencia alkalmazásokra jellemzı OLAP feldolgozások számára az OLTP adatbázisoktól eltérı szerkezető adatbázist használnak, amelyet inkább adattárháznak neveznek. Az adattárház használatában a lekérdezı mőveletek dominálnak, ezek hatékonysága pedig gyakran a redundancia növelésével javítható. Tehát esetükben az elfogadható válaszidıhöz szükséges mértékre fokozott redundanciát tartalmazó szerkezet számít optimálisnak. Adattárház Az adattárház az adatokat lekérdezési, elemzési mőveletekre optimalizált szerkezetben tároló adatbázis, amely a kiszolgált vezetési szintek igényeinek megfelelıen aggregált adatokat is tartalmaz; továbbá különbözı forrásokból nem tranzakciónként, hanem adott periódusonként és az adatértékek történetiségének megırzésével frissítıdik. Az adattárház sajátosságai bıvebben kifejtve: • Az adattárház, lévén egy speciális adatbázis, maga is rendelkezik adatszótárral, amely az adattárház szerkezetét, a benne tárolt adatok jellemzıit, dimenzióit és kapcsolatait leíró metaadatokat tartalmazza. • A lekérdezési, elemzési mőveletekre optimalizált szerkezet az OLAP által preferált többdimenziós (multidimenziós) modell megvalósítását jelenti, amelyrıl a 2.6.2. szakaszban már volt szó. • Az aggregált adat valamilyen egyedekbıl álló halmazra értelmezhetı olyan tulajdonság, amelynek értéke a halmazba tartozó egyedek mindegyikére értelmezhetı tulajdonság (vagy tulajdonságok) egyedenkénti értékeibıl származtatással állítható elı. A leggyakoribb származtatási mőveletek: az összegzés, a megszámlálás, az átlagolás, a minimális vagy a maximális érték kiválasztása. (Aggregált adat például azon árak súlyozott átlaga, amelyeken adott cég részvényei adott tızsdén adott napon gazdát cseréltek.) Az aggregált adatok letárolása lényegesen csökkenti az ilyen adatokra vonatkozó lekérdezések válaszidejét. • Annak, hogy az adattárház tartalma nem tranzakciónként, hanem periódusonként frissítıdik, elınyös következménye, hogy az adattárház jelentısen ritkábban van kitéve aktualizálási mőveleteknek, mint az OLTP adatbázisok. A periódusok hossza adatforrásonként vagy témakörönként változhat. Ha egy témában a rövid távú változások elemzése a cél, akkor annak alapadatait rövidebb periódussal kell frissíteni. Ha a frissítési periódus hossza meghaladja a szokásos napi munkaidıt, akkor a frissítés olyan idıpontra idızíthetı, amikor senkit nem zavar az elemzések futtatásában. • Az adattárház az adatértékek történetiségének megırzésével frissítıdik, azaz a frissítés nem a korábbi idıpontokat jellemzı adatértékek felülírását, hanem (azok megır-


•

•

75

zése mellett) a késıbb keletkezett adatok hozzátöltését jelenti. Ez a megoldás elengedhetetlen feltétele az idısorelemzéseknek (trendelemzéseknek). Az adattárház adatai részben a szervezet OLTP adatbázisából (adatbázisaiból), részben külsı forrásból származnak. Ehhez szükség van az adatok betöltését, konvertálását, tisztítását végzı funkciókra. – A konvertálás a forrásadatoknak az adatszótárban adott formátumra alakítását (formai egységesítését) és adott szerkezetbe illesztését jelenti. Az adattisztításon az inkonzisztencia (adathiányok, ellentmondások) felderítését, kiszőrését; az adatok értelmezésbeli egységesítését kell érteni. Az egységesítés egy egyszerőbb példája a különbözı mértékegységekben (speciálisan pénzösszeg esetén különbözı pénznemekben) kifejezett értékek közös mértékegységre (adott pénznemre) átszámítása. Ahhoz hasonlóan, ahogy a közös használatú OLTP adatbázis esetében különbözı nézetek alakíthatók ki, amelyek az egyes felhasználói szerepek által elérhetı / kezelhetı adatok körét határozzák meg, a központi adattárház esetében az ú.n. adatpiacok reprezentálják a különbözı vezetési szintek vagy funkcionális területek igényei szerint kialakított adattartalmat és elérési szerkezeteket.

Az OLTP rendszer adatbázisa és az adattárház közötti lényeges különbségeket a 2.17. táblázat foglalja össze. OLTP adatbázis

Adattárház

Domináns mőveletek

Egy-egy tranzakcióban szerepet kapott adatokat érintı, karbantartó (aktualizáló) mőveletek: beszúrás, módosítás, törlés.

Nagy adathalmazokat érintı, bonyolult lekérdezések. Egyedek (objektumok, események) bizonyos ismérvek szerinti csoportosítása, hierarchiába sorolása, valamint adott csoportosítás vagy hierarchia szerinti elérése.

Optimumcélkitőzés

A karbantartó mőveletek hatékonysáA lekérdezések hatékonyságának gának javítása: elfogadható tranzakció- javítása: elfogadható válaszidı. feldolgozási idı.

Optimális szerkezet

Minimális redundancia.

Elfogadható válaszidıhöz szükséges mértékre fokozott redundancia.

Modell

Relációs adatmodell – normalizált.

Többdimenziós adatmodell

Adatbázistechnológia

Relációs adatbázis

Két változat: 1. Relációs adatbázis csillagszerkezetet mutató táblakapcsolatokkal. 2. Többdimenziós adatbázis.

2.17. táblázat: Az OLTP rendszer adatbázisa és az adattárház összehasonlítása

A kétdimenziós táblázat és az n-dimenziós adatkocka nem fizikai reprezentációk, hanem magyarázó elvi interpretációk! Pont az a lényegük, hogy a felhasználók elıl a megvalósítás bonyolult részleteit eltakarják egy olyan felületi képpel, amelynek elemei közvetlenül megfeleltethetık a felhasználó szakterületét jellemzı fogalmaknak.

A 2.17 táblázatban olvasható állítások és az ugyanott elıfordult fogalmak némelyike magyarázatra szorul. Ilyen például: • Egyedtípus, egyed (azaz entitás): Az adatmodellezés alapfogalmai, ezeket a 2.7.2. szakasz ismerteti, de magyarázhatók az 1.2.1. szakaszban bevezetett specifikált adat fogalmából kiindulva is, mint az ottani kategória és objektum megfelelıi.

76

INFORMATIKUS SZAKMAI ISMERETEK • •

•

Tulajdonság, tulajdonság értéke: Ezek is az adatmodellezés alapfogalmai, és mint olyanokat, ezeket is a 2.7.2. szakasz ismerteti, de magyarázhatók a specifikált adat fogalmából kiindulva is, mint az ottani tulajdonság és érték megfelelıi. Minimális redundancia: Az adatok többszörös tárolásának minimalizálása. – A karbantartó mőveletek tárgyát képezı adatok esetében a többszörös tárolás hátrányos, mert többszörös adatkarbantartást igényel. A redundancia teljes megszüntetésérıl nem lehet beszélni, mert már az idegen kulcs is annak számít, viszont a kapcsolatok kifejezése céljából nélkülözhetetlen. A normalizált adatmodellrıl a 2.7. alfejezetben tudhatunk meg többet, de az a lényege, hogy az idegen kulcsok alkalmazásán felüli redundanciát nem enged meg. Azonban ez a megszorítás csak a modellre vonatkozik; mert a modellnek a relációs adatbázisban való megvalósítása során ezt a redundanciát még növeli az indextáblák felépítése (és letárolása) az adatbázisban. Elfogadható válaszidıhöz szükséges mértékre fokozott redundancia: A válaszidı az adatszerkezet tekintetében a redundancia fokozásával csökkenthetı. Az aggregált adatok letárolása, az idegen kulcsok, indextáblák, mutatók alkalmazása, mind a redundancia olyan megnyilvánulásai, amelyek a válaszidıt javítják.

2.6.4 Ellenırzı kérdések a 2.6. alfejezethez 1. Adja meg az adatbázis fogalmát meghatározó fıbb tulajdonságokat! 2. Közelebbrıl mit jelent az az állítás, hogy az adatbázisban a különbözı jelenségekre vonatkozó ismeretek egymással alkotott természetes összefüggéseik szerint szervezettek? 3. Min alapszik az adatbázis programfüggetlensége? 4. Mit jelent az adatbázis adatszótára? 5. Hasonlítsa össze a papíron és az adatbázisban tárolt adatokat elérhetıség, idıszerőség, valamint a felhasználás módja és lehetısége tekintetében! 6. Adatbázisszerkezet kialakítására milyen különbözı koncepciók (modellek) születtek? 7. Alapvetıen miben különbözik a hierarchikus-hálós adatbázis és a relációs adatbázis (szerkezeti megoldás, elıny, hátrány)? 8. Milyen okok játszottak közre a relációs adatbázisok elterjedésében? 9. Hogyan ábrázolható az irányított háló a relációs adatbázisban? 10. Mit jelentenek a többdimenziós modell dimenzióadatai? 11. A többdimenziós modell miben hasonlít a geometriai térhez? 12. Mit reprezentál a többdimenziós elemi adatkockája? 13. Hasonlítsa össze az OLTP adatbázis és az adattárházat aktualizálás, jellemzı mőveletek, optimum-célkitőzés, szerkezet, alkalmazható adatbázistechnológia szempontjából!


77

2.7 Adatbázistervezés – adatmodellezés 2.7.1 Az adatmodellezés tartalma és szintjei Az üzleti alkalmazások (szoftverrendszerek) mind valamilyen adatbázisra épülnek. Ezért az ilyen rendszerek tervezése magában foglalja az adatbázis szerkezetének (pontosabban az adatbázis tartalmát képezı adatszerkezeteknek) a megtervezését is. Ezt a fejlesztıi feladatot hívják másképpen adatmodellezésnek. Adatmodellezés Az adatmodellezés speciális adatszerkezetek – mégpedig az adatbázisban tárolt adatszerkezetek – tervezését jelenti. Azonban az adatmodellezésnek az a változata, amelyrıl itt szó lesz a fenti értelmezéshez képest további két megszorítással él: • Az OLTP rendszerek számára optimális – minimális redundanciájú (= normalizált) – adatszerkezet kialakítását célozzuk meg. • Relációs adatbázist feltételezünk, mivel az OLTP rendszerek alatt az ilyen típusú adatbázisok a legelterjedtebbek. – Ez közelebbrıl azt jelenti, hogy a megcélzott modellben a kapcsolatokat idegen kulccsal képviseltetjük (lásd a 2.6.2. szakaszban). Ugyanakkor meg kell jegyezni, hogy a normalizált modell a fogalmi tisztaságánál fogva jó kiindulási alapot képez az OLAP rendszerek adatbázisának tervezéséhez is. Az adatbázisok módszeres tervezése általában három – egymást követı – szintre tagoltan történik: • Idıben a fogalmi szintő adatmodell (más névvel a szakterületi adatmodell) megszerkesztése az elsı feladat. Ez a modell kizárólag az alkalmazási területet jellemzı összefüggéseket tükrözi, egyéb informatikai megvalósítási szempontok iránt, a használható eszközök korlátai iránt közömbös, így tökéletesen hordozható. • A következı lépés a logikai tervezés, amely már a hatékonysági, biztonsági szempontokat és a szervezeti korlátokat is figyelembe veszi. • Végül a fizikai tervezés a logikai tervet a megvalósító eszköz, a konkrét adatbáziskezelı rendszer korlátaihoz igazítja. A továbbiakban csak a fogalmi (szakterületi) szintő adatmodellezés elveire szorítkozunk. 2.7.2 Az adatmodellezés alapfogalmai A fogalmi / szakterületi adatmodell megszerkesztése során feltárják az alkalmazási terület (szakterület) azon jelenségeit, egyedeit (tárgyakat, személyeket, eseményeket stb.), amelyekre vonatkozóan a tervezett adatbázisban adatokat szeretnének nyilvántartani. Meghatározzák, hogy a szakterületi igények szerint az egyedek leírására milyen tulajdonságokat (adatfogalmakat) kell nyilvántartani; továbbá kiderítik azokat a (szakterületi / üzleti) szabályokat, amelyekbıl a tulajdonságok közötti valamilyen függések, egyedek közötti kapcsolatok, a tulajdonságok értékeire vagy a kapcsolatokra vonatkozó valamilyen korlátok / megszorítások következnek. Az elmondottakkal összhangban az adatmodellezés olyan alapfogalmakat használ, mint

78

INFORMATIKUS SZAKMAI ISMERETEK • • •

az egyed (entitás), a tulajdonság (attribútum) és a kapcsolat.

Egyed, tulajdonság, kapcsolat Egyed (entitás) minden olyan tárgy, jelenség, esemény (cikk, vevı, szállító, rendelés stb.), amelyrıl valamilyen jellemzı adatokat nyilván kell tartani a rendszerünkben. Tulajdonságok (attribútumok) alatt éppen a nyilvántartott jellemzıket (név, ár, szín, idıpont stb.) értjük. A kapcsolatok az egyedek közötti viszonyok. A tervezı persze nem konkrét egyedekkel (szállítókkal, számlákkal) és nem konkrét adatértékekkel foglalkozik, hanem csak ezek típusaival: nem a konkrét egyedeket különkülön, hanem azok közös szerkezetét kell megterveznie. Ezért meg kell különböztetni a fentebb bevezetett fogalmak elıfordulásszintő és típusszintő értelmezését. Így beszélünk konkrét egyedelıfordulásról (pl. egy konkrét szállítói számla) és egyedtípusról. Az egyedtípus egyrészt valamilyen – azonos típusú – egyedelıfordulások halmazát (pl. a számla egyedtípus a számlák halmaza), másrészt a típusba tartozó elıfordulások közös szerkezeti sémáját képviselı kategória. Hasonlóan meg kell különböztetni a konkrét tulajdonságértéket (pl. zöld) a tulajdonságtípustól (pl. szín). Ezen felül egy tulajdonságtípussal foglalkozhatunk magában mint értékhalmazzal, másrészt pedig mint valamely egyedtípus jellemzıjével. A tulajdonság értékhalmazát (értéktartományát) doménnek (vagy doméjnnek – eredetileg domain) nevezik, az egyedtípushoz rendelt tulajdonságot pedig attribútumnak. Példa doménre és attribútumra: Amikor egy vállalkozás kidolgozza számlarendjét, azon belül a számlatükröt, azzal meghatározza a fıkönyvi számlaszám lehetséges értékeinek halmazát, azaz a fıkönyvi számlaszám domént. Amikor egy bizonylat kontírozásakor elıálló könyvelési tételben feltüntetik az arra vonatkozó fıkönyvi számlaszámot, akkor azt mint a könyvelési tétel egyedtípus attribútumát használják.

Megjegyzés: Az itt bevezetett fogalmak közvetlen megfelelıi az 1.2.1. szakaszban értelmezetett specifikált adat dimenzióinak. Az egyedtípus megfelel az ottani kategóriának, az egyed pedig a kategória egy példányának (azaz az ottani objektumnak); az itteni tulajdonság(típus) pedig azonos az ottani tulajdonsággal, és a tulajdonság értéke azonos az ottani érték dimenzióval. – Például a gépkocsi egyedtípus a gépkocsik kategóriája, e kategória egy egyede egy konkrét gépkocsi, a gépkocsi egyik tulajdonsága a színe, ennek egyik értéke pedig a kék. Könyvelési tétel egyedtípus: A következı táblázat egy gépi beruházás számlájáról készült négy könyvelési tételt mutat. A bizonylatszám értéke éppen azért azonos a tételekben, mert mindet azonos bizonylat kontírozása eredményezte. Hasonlóan a tételekben a Követel számlaszám azért azonosan 449, mert mindegyikben a Beruházási szállítók fıkönyvi számla "követel". A táblázat sorai a könyvelési tétel egyed elıfordulásai, oszlopai ugyanezen egyedtípus attribútumai. Az egyedtípus Tartozik számlaszám és Követel számlaszám attribútumainak a doménje azonos: a fıkönyvi számlaszám domén. Számlatétel azonosító 1111 1112 1113 1114

Könyvelés Bizonylatdátum kód

Tartozik Követel Forgalom- Megjegyzések: szlaszám szlaszám érték

19970908 19970908 19970908 19970908

16 4661 16 4661

2222 2222 2222 2222

449 449 449 449

8000000 2000000 1000000 120000

A gép számlázott ára A gép árára 25 %-al felszámított ÁFA Számlázott szállítási költség A szállítási költség 12 %-os ÁFA-ja

2.18. táblázat: Könyvelési tételek táblája


79

Különbözı egyedelıfordulások éppen attól azonos típusúak (azért tartoznak egy egyedtípusba), mert mindegyiket a tulajdonságtípusok (attribútumok) azonos együttese jellemzi. Az azonos egyedtípusba tartozó elıfordulások közös szerkezete, azaz az egyedtípus szerkezete nem más, mint a jellemzı attribútumok felsorolása és közülük az azonosító attribútum kijelölése. Az azonosító attribútum (másképpen elsıdleges kulcs) az egyedtípus olyan tulajdonsága, amely a1) az egyed minden elıfordulására értelmezhetı (mindegyikhez tartozik valamilyen értéke); a2) értékei és az egyed elıfordulásai között kölcsönösen egyértelmő megfelelés áll fenn; a3) stabil, azaz valamely egyedelıforduláshoz tartozó értéke az elıfordulás élettartama alatt nem változik; a4) minimális, azaz nincs olyan része, amely szintén teljesítené az a1)–a3) feltételeket. 1. megjegyzés: Az a2) feltétel teljesülésébıl logikailag az a1) teljesülése is következik, azaz elméletben elegendı lett volna az a2)-a4) feltételeket kikötni. Azonban a gyakorlat azt bizonyítja, hogy az a1)-re mégis célszerő külön ráirányítani a figyelmet. Példa erre az 1996. évi XX. Törvény 1. sz. melléklete (lásd a következı keretezett szöveget). 1. számú melléklet az 1996. évi XX. Törvényhez: Az adózó polgár adóazonosító jelének képzési szabályai 1. Az adóazonosító jel tízjegyő szám. 2. Az adóazonosító számot az alábbiak szerint kell képezni: a) az 1. számjegy konstans 8-as szám, mely az adóalany magánszemély voltára utal, b) a 2-6. számjegyek a személy születési idıpontja és az 1867. január 1. között eltelt napok száma, c) a 7-9. számjegyek az azonos napon születettek megkülönböztetésére szolgáló véletlenszerően képzett sorszám, d) a 10. számjegy az 1-9. számjegyek felhasználásával matematikai módszerekkel képzett ellenırzı szám. 3. Az adóazonosító jel 10. számjegyét úgy kell képezni, hogy a 2. a)-c) pontok szerint képzett 9 számjegy mindegyikét szorozni kell azzal a sorszámmal, ahányadik helyet foglalja el az azonosítón belül. (Elsı számjegy szorozva eggyel, második számjegy szorozva kettıvel és így tovább.) Az így kapott szorzatok összegét el kell osztani 11-gyel, és az osztás maradéka a 10. számjeggyel lesz egyenlı. A 2. c) pont szerinti születési sorszám nem adható ki, ha a 11-gyel való osztás maradéka egyenlı tízzel. *** A szerzı kommentárja: Ha valóban a fentebb elıírt módon osztaná az APEH rendszere az adóazonosító jelet, akkor abból nem jutna minden magyar állampolgárnak: Az idézett törvényszövegbıl kitőnik, hogy az adóazonosító jel 7-9 pozícióin álló véletlenszámnak kellene megkülönböztetni az egy napon születetteket. Erre a 000-999 tartományba esı értékhalmaz elvben elegendı is lenne, mivel naponta 1000-nél jóval kevesebb magyar állampolgár születik. A jogászok azonban nem számoltak azzal a számelméleti ténnyel, hogy a születési dátum által egyértelmően meghatározott 2-6. pozíción bizonyos dátumok esetén olyan érték is adódhat, amely mellett a 000-999 tartományból a szabály 3. pontja miatt annyira sok nem osztható ki, hogy végül kevesebb kiosztható marad, mint amennyien a szóban forgó dátummal adott napon születnek. A hibát az APEH adóalany-nyilvántartó rendszerét fejlesztı cég programozója vette észre, és ı talált ki egy olyan kivételszabályt, amely a kritikus dátumok esetén a 2-6. pozíciók értékét a nem a 2.b) szabály szerint képezi, viszont garantálja, hogy minden magyar állampolgárnak osztható adóazonosító jel. Az egy másik történet, hogy a jogalkotók (immár 12 éve fittyet hányva azokra a bosszúságokra, amiket ezzel egyes állampolgároknak okoznak), azóta sem javították ki az általuk elkövetett hibát, azaz nem egészítették ki a törvény szövegét a programozó által kitalált kivételszabállyal. Ami jó hír: a problémát megoldó programozó ellen sem indítottak eljárást törvényszegésért. Egyelıre.

80


2. megjegyzés: Az a4) nem feltétlenül azt jelenti, hogy az azonosító attribútum a lehetı legrövidebb. Lehetséges, hogy két különbözı módon konstruált azonosítójelölt közül a hoszszabb minimális, a rövidebb viszont nem az. 6

Példa nem valódi azonosítóra: Magyarországon az adószámmal rendelkezı adóalanyok esetén az adószám tekinthetı-e az ilyen adóalanyok azonosítójának? – A megoldás: Nem. A tizenegy pozíciós adószám így épül fel: 1–8. pozíció: törzsszám, 9. pozíció: ÁFA-kód 10–11. pozíció: illetékes igazgatóság kódja. Az ÁFA-kód azt mutatja, hogy az adóalany (az ÁFA tv. 49.§-ban meghatározott feltételek teljesülése mellett) az aktuális adóévben az alanyi ÁFA-adómentességet választotta-e vagy sem. Az ÁFA tv. 51.§ szerint az adóalany az alanyi adómentességet az adóév végéig választja, azt követıen ismét élhet választási jogával. Az illetékes igazgatóság kódja szintén változik, amikor az adóalany székhelyét vagy az illetékességet meghatározó telephelyét olyan címre helyezi át, amely szerint a korábbitól különbözı adóigazgatóság illetékes (Art. 50.§) Az APEH nyilvántartásában az ilyen adóalanyok esetében csak a törzsszám változatlan, következésképpen a törzsszámnak magában pontosan meg kell határozni az adóalanyt. Végeredményben tehát az adószám nem stabil és nem is minimális. Az igazi azonosító a törzsszám. Ehhez az adószámban csak azért kapcsoltak hozzá más jellemzıket, hogy abból az adóalany ÁFA-mentessége és az illetékességi hovatartozása anélkül látható legyen, hogy a törzsszám felhasználásával ezeket az adóalanyi törzsadattárból lekérdeznék.

A kapcsolat egyedek közötti viszony. Pontosabban egy kapcsolatelıfordulás konkrét egyedelıfordulások viszonya, a kapcsolattípus pedig az azonos tartalmú viszonyt kifejezı kapcsolatelıfordulások halmazaként áll elı. A kapcsolatokat az alkalmazási terület összefüggései (üzleti, szakterületi szabályok) definiálják. (Pl. az a tény, hogy a számlát egy szállító állította ki, egy-fajta kapcsolatot definiál a számla és a szállító egyedek között.) A kapcsolatok fontos jellemzıi: • a foka és • az, hogy kötelezı vagy csak lehetséges (opcionális), • valamint hogy stabil vagy instabil a benne részvevı egyedtípusokra nézve. Az egyedek közötti kapcsolatok ábrázolása az adatmodellezésben egyed-kapcsolatdiagramokon (angolul: Entity Relationship Diagram – ERD) történik. Ilyen diagramot mutat a 2.18. ábra. A következı bekezdések példaként az ezen ábrán látható kapcsolatokat elemzik. Az ERD diagramon a dobozok az egyedtípusokat, az összekötı vonalak pedig a kapcsolatokat képviselik. A szállító és a számla közötti kapcsolat egy-a-többhöz (1:n) fokú, mert egy szállító több számlát állíthat ki, megfordítva egy számla határozottan egy szállítótól érkezhet. Az 1:n fokú kapcsolatokat másképpen hierarchikus kapcsolatnak is nevezik. Benne az 1-es oldalon álló egyedtípust fölérendeltnek, az n-es oldalon állót pedig alárendeltnek mondják. Az V.2. ábrán a kapcsolóvonal az alárendelt egyednél „tyúklábban” végzıdik. A szállító és a vevı közötti kapcsolat több-a-többhöz (m:n) fokú, mert azonos szállító több vevınek is szállíthat, illetve azonos vevı több szállítótól is rendelhet. Mindezt a 2.19. ábrán az jelzi, hogy a kapcsolóvonal mindkét végén „tyúkláb” látható. Egy-az-egyhez (1:1) fokú kapcsolatban állhat a szállítólevél a számlával, ha a szállító minden szállítmányt külön számláz, és egy szállítmányról egy számlát állít ki. A szállító (mint a számla kiállítója) és a kiállított számla közötti kapcsolat a számla egyedtípusra nézve kötelezı, mert minden számlához kell lenni azt kiállító szállítónak; viszont a szállító egyedtípusra nézve opcionális, mert lehet olyan szállítója a cégnek, akitıl még nem érkezett számla. A 2.19. ábrán a kapcsolat opcionális végét karika jelöli. Ugyanez a kapcsolat 6

Az adószám nem keverendı össze a megelızı példában szerepelt adóazonosító jellel!


81

a számla egyedtípusra nézve stabil is, mert az a tény, hogy egy számlát X szállító állította ki, akármennyi idı elteltével is tény marad. A munkaadó szervezetek és az alkalmazottak közötti kapcsolat viszont értelemszerően instabil mindkét egyedtípusra nézve. A 2.19. ábrán a kapcsolat stabil végét rövid keresztezı vonal jelöli. SZÁLLÍTÓ

kiállítja

SZÁMLA

felettes alárendelt

SZÁLLÍTÓ

szállít-vesz

VEVÕ

SZÁLLÍTÓLEVÉL

szállítmányról

SZÁMLA

SZERVEZETI EGYSÉG

BIZONYLAT

FÕKÖNYVI SZÁMLA

INGATLAN forrás TÁRGYI ESZKÖZ

MÛSZAKI BERENDEZÉS

fõtípus és altípusai

JÁRMÛ

tartozik követel

SZINTETIKUS KÖNYV. TÉTEL

2.19. ábra: Néhány kapcsolat ERD-je

A hierarchikus kapcsolatok kitüntetett szerepet játszanak az adatmodellezésben. Az m:n fokú kapcsolatok mindig visszavezethetık hierarchikus kapcsolatokra. Az 1:1 fokú kapcsolatok egy része megszüntethetı a kapcsolódó egyedtípusok egy egyedtípusba aggregálásával, más része pedig egy-szerően az 1:n fokú kapcsolat speciális esetének tekinthetı. Az elsı csoportba a stabil, a második csoportba az instabil 1:1 fokú kapcsolatok tartoznak. Az 1:1 fokú kapcsolatok leggyakoribb esete a fıtípus-altípus kapcsolat. Ilyen kapcsolatot alkot a tárgyi eszköz egyedtípus az ingatlan egyedtípussal. Egy ingatlan azonos egy tárgyi eszközzel. A tárgyi eszköz egyedtípus elıforduláshalmaza részhalmazként tartalmazza az ingatlan egyedtípus elıforduláshalmazát. Ezért a tárgyi eszköz képezi az általánosítást: a fıtípust; az ingatlan képezi a specializációt: az altípust. Hasonló kapcsolat áll fenn a tárgyi eszköz és a mőszaki berendezés, illetve a tárgyi eszköz és a jármő egyedtípusok között. A tárgyi eszköz három kapcsolatát reprezentáló kapcsolóvonalakat ívelt vonal metszi. Ez jelöli azt, hogy e kapcsolatok egymást kizáróak, azaz egy konkrét tárgyi eszköz nem lehet egyszerre ingatlan is, meg jármő is. Elıfordulhat az is, hogy egy egyedtípus önmagával alkot valamilyen kapcsolatot. Ezt visszamutató kapcsolatnak nevezik, de használatos még rá a rekurzív kapcsolat vagy a homogén kapcsolat megnevezés is. Ilyen kapcsolat pl. egy szervezet egységei közötti alárendeltségi viszony (X osztály alárendeltje az Y fıosztálynak, az utóbbi meg alárendeltje egy Z igazgatóságnak). Ebben a viszonyban a szervezet egyedtípus önmagával alkot 1:n fokú kapcsolatot. Természetesen az "önmagával" határozó csak típusszinten igaz, ebben az esetben elıfordulásszinten nem. Az adatbázisok definíció szerinti jellemzıje, hogy nemcsak az adatokat, hanem azok kapcsolatait is tárolják (kifejezik). A különbözı típusú adatbázisok ez eltérı módon valósítják

82


meg. Mint azt a 2.6.2. szakaszban láttuk, tipikusan a relációs adatbázisok sajátja a következı megoldás, hogy a hierarchikus kapcsolatot idegen kulccsal fejezik ki: Mivel egy hierarchikus kapcsolatban alárendelt egyedelıfordulás legfeljebb egy fölérendelt elıforduláshoz tartozhat, az alárendelt egyedtípus szerkezetébe beilleszthetı a fölérendelt egyedtípus azonosítója (elsıdleges kulcsa), amely minden alárendelt elıfordulásnál a fölérendelt elıfordulás azonosítójának (elsıdleges kulcsának) értékét veszi fel. Emlékeztetünk rá: a fölérendelt egyed elsıdleges kulcsát, ha az alárendelt egyed szerkezetében megjelenik, ott idegen kulcsnak nevezzük. Ilyen idegen kulcsok a 2.18. táblázat szerinti könyvelési tétel egyedtípus szerkezetében a „Bizonylatkód”, a „Tartozik számlaszám” és a „Követel számlaszám” attribútumok. Történetesen a „Bizonylatkód” a könyvelési tételnek azon bizonylattal való kapcsolatát mutatja, amelyik a tétel forrása volt. A „Tartozik számlaszám” és a „Követel számlaszám” pedig mint fıkönyvi számlaszámok a fıkönyvi számla egyedtípusból vett idegen kulcsok, bennük a (szintetikus) könyvelési tételnek a fıkönyvi számla egyedtípussal alkotott két különbözı tartalmú kapcsolata fejezıdik ki. (Lásd még a 2.19. ábrát!) A 2.19. ábrán a BIZONYLAT és a SZINTETIKUS KÖNYVELÉSI TÉTEL egyedek kapcsolatának jelölésében van egy hiba, amely egyszerő könyvelési ismeretek birtokában észrevehetı. – Felismerte-e már az olvasó?7

Az adatbázistervezés során a kapcsolatokhoz (pontosabban azok végeihez) ún. hivatkozásteljességi (hivatkozásintegritási) szabályok rendelhetık. Ezekkel a szabályokkal elıírhatók, hogy meghatározott helyzetekben az adatbáziskezelı rendszernek milyen mőveleteket kell visszautasítani, illetve milyen mőveleteket kell külön kérés nélkül is automatikusan végrehajtani annak érdekében, hogy az adatbázis tartalma konzisztens maradjon. – Az adatbázis konzisztens, ha ellentmondásmentes és hivatkozásteljes. A hivatkozásteljesség azt jelenti, hogy ha egy adatsor hivatkozik egy másik adatsorra (például a rendelés-adatsor egy vevıadatsorra), akkor a hivatkozott adatsornak (példánk esetében vevı-adatsornak) is jelen kell lenni az adatbázisban. 2.7.3 Az egyedtípusok szerkezetének kialakítása – Normalizálás Ebben a szakaszban az egyedtípusok szerkezetének kialakítására vonatkozó olyan szabályokkal foglalkozunk, amelyek a következı feltételezések mellett optimális modellre vezetnek: 1. feltételezés: Az adatmodell valamilyen relációs adatbázissal lesz megvalósítva. Ez közelebbrıl azt jelenti, hogy az adatmodell egyedtípusaiból táblázatok lesznek; ami azonban az adatmodellezési szempontjából lényegesebb: a relációs adatbáziskoncepciónak megfelelıen az egyedtípusok közötti hierarchikus kapcsolatokat idegen kulcsokkal fejezzük ki. 2. feltételezés: Az adatbázis egy végrehajtást támogató – on-line tranzakciókezelı (OLTP) – rendszert fog kiszolgálni (lásd a 2.6.3. szakaszban), azaz dominánsan karbantartási / aktualizálási (létrehozási, módosítási, törlési) mőveleteknek lesz kitéve, az adatmodellt ennek megfelelıen kell optimalizálni. Tehát kerülnünk kell az adatok többszörös tárolását, mert abból a többszörös aktualizálás igénye következne, az pedig lerontja az aktualizálási mőveletek hatékonyságát.

7

A modell jelölése szerint a kapcsolat a SZINTETIKUS KÖNYVELÉSI TÉTEL egyedre nézve opcionális, de ez a valóságban nem igaz, mert nem létezhet könyvelési tétel forrásbizonylat nélkül.


83

E két feltételezésbıl két modellezési követelmény adódik. Az egyedtípusok szerkezetét úgy határozzuk meg, hogy m1) bennük idegen kulcsok képviseljék az egyedtípusok közötti hierarchikus kapcsolatokat, azaz egy kapcsolatban alárendelt egyedtípus szerkezetében jelenjen meg idegen kulcsként az ugyanazon kapcsolatban fölérendelt egyedtípus elsıdleges kulcsa; m2) az adatmodell minimalizálja az ismételt adattárolásból eredı redundanciát, konkrétabban: a kapcsolatok kifejezéséhez szükséges idegen kulcsokon felüli redundanciát ne tartalmazzon. Megjegyzés: Ha történetesen a 2. feltételezéssel ellenkezıleg egy (felsı)vezetıi információrendszer adatbázisát (adattárházát) terveznénk, akkor az adatbázismőveletek hatékonysága javításának célkitőzése az m2) követelmény érvényesítését nem indokolná. Ugyanis azokban a rendszerekben a lekérdezés a domináns mővelet, és a lekérdezések hatékonysága éppen a redundancia növelésével javítható. – Azonban a redundanciát minimalizáló modellnek van egy másik haszna is, nevezetesen javítja a modellezık (az adatbázistervezık) tisztánlátását. Ugyanis a minimálisat meghaladó redundanciát tartalmazó modell nehezebben elemezhetı, mert benne több, különbözı jelentéső dolog egyetlen fogalomba olvad össze. Márpedig, ha különbözı dolgok nem jelennek meg önálló fogalomként, nem jelenhetnek meg azok kapcsolatai sem, miáltal teljesen lehetetlenné válik ezen kapcsolatok elemzése is. Ezért a vezetıi információs rendszerek adatbázisának tervezésénél is gyakori megoldás, hogy elıbb elvégzik a modellezést az itt leírtak szerint, tehát az m2) követelmény érvényesítésével; majd az így kapott modellt utóbb „elrontják” a lekérdezéseket javító redundancia hozzáadásával. Normalizálás Az m2) szerinti – minimális redundanciájú – egyedszerkezetek kialakítására szolgáló eljárást normalizálásnak nevezik. Ez az eljárás nagymértékben épít a tulajdonságtípusok között értelmezett funkcionális függés fogalomra (lásd alább). A normalizálásnak két változata van: • Az egyik a lebontás (dekompozíció) módszere, amelynél már adottak valamilyen egyedszerkezetek, amelyek azonban esetleg a minimálisnál több redundanciát tartalmaznak, azaz sértenek valamilyen megszorító (tiltó) szabályokat, az ú.n. normálforma-szabályokat. Ilyenkor a normalizálás domináns mozzanata az, hogy az adott egyedtípusokat felbontják olyan egyedtípusokra, amelyek együttesen már megfelelı normálformájú modellt alkotnak. (Mellékesen megjelenhet az egyesítés mozzanata is, amikor a lebontással kapott egyedtípusok között két vagy több egyedtípusról felismerik, hogy azok tulajdonképpen azonosak, és azokból – a szerkezetük egyesítésével – egy egyedtípust alkotnak.) • A másik változat a szintézis (vagy szintetikus modellezés), amelynél nincsenek elıre adott egyedtípusok, csak a tulajdonságok közötti funkcionális függések ismertek, és ezekbıl egy konstrukciós szabály segítségével eleve normalizált egyedszerkezeteket raknak össze. Funkcionális függés Az adatmodellezésben egy – adott A és B tulajdonságtípusok közötti – viszonyt funkcionális függésnek nevezzük, ha az adott viszonyban az A bármely értékéhez legfeljebb egy érték tartozik a B-bıl. Az ilyen funkcionális függés jele: A→ →B, és szokás úgy is mondani, hogy az A-tól funkcionálisan függ B, vagy az A funkcionálisan meghatározza B-t.

84


Megjegyzés: Ha nem csupán érintılegesen tárgyalnánk az adatmodellezést, a fogalmi tisztaság érdekében meg kellett volna különböztetni az doménekre értelmezett funkcionális függést az attribútumokra értelmezett funkcionális függéstıl, mivel a kettı némileg másképpen viselkedik.

A tulajdonságtípusok függéseit a modellezett alkalmazási területen (adott szervezetnél) érvényes viszonyok definiálják. Pl. az a tény, hogy egy adóazonosító jelhez egy állandó lakcím érték tartozik, egy adóazonosító jel → állandó lakcím funkcionális függést definiál. Látszik, hogy ez a függésfogalom nem szimmetrikus, fordított irányban nem feltétlenül áll fenn: azonos címen több adóalany is lakhat. Ha a függés szimmetrikusan teljesül, akkor kölcsönös függésrıl beszélünk (jelölése: A ↔ B). Például fennáll az adóazonosító jel ↔ tajszám kölcsönös függés (legalábbis doménszinten). Ha a függésben a meghatározó tulajdonság nem minden értékéhez tartozik érték a meghatározott tulajdonságból (a „legfeljebb egy” zérussal teljesül), akkor opcionális (más szóval gyenge) függésrıl beszélünk. Így opcionális például a tárgyi eszköz azonosító → helyrajzi szám függés, mert pl. a jármővekhez értelemszerően nem tartozik helyrajzi szám. Ha a meghatározó tulajdonság (több egyszerő tulajdonságból) összetett, akkor összetett függésrıl beszélünk. Ilyen összetett függés például a követ-kezı: adóazonosító jel + adóév → éves szja összege. Vegyük észre, hogy a funkcionális függés a definíciójából adódóan eleget tesz a következı két szabálynak: • Tranzitivitás: ha A→B és B→C, akkor A→C. • Projektivitás: mindig teljesül, hogy A+B→A, illetve A+B→B. (Például a vezetéknév + utónév → vezetéknév, illetve vezetéknév + utónév → utónév). Meg kell különböztetnünk a közvetlen és a közvetett funkcionális függéseket. Közvetlen, illetve közvetett funkcionális függés Egy modell keretein belül az A→ →B funkcionális függés közvetlen, ha a modellben nincs olyan C tulajdonság, amellyel egyidejőleg az A→C és a C→B függések úgy is fennállnak, hogy az A→C nem azonos az A↔C kölcsönös függéssel, és a C→B függés nem projekció (azaz a C nem azonos egy B+X vagy egy X+B összetett tulajdonsággal. – Minden más esetben – egy modell keretein belül – az A→ →B funkcionális függés közvetettnek számít. Ezen a ponton már minden szükséges fogalom rendelkezésre ahhoz, hogy megfogalmazzuk a korábban m2)-vel jelölt követelmény teljesítését célzó normálforma-szabályokat. Az adatmodellezés elmélete több ilyen szabályt fogalmazott meg, nevezetesen az elsı (1NF), a második (2NF), a harmadik normálforma (3NF), azután a Boyce-Codd normálforma8 (BCNF), legutoljára pedig a negyedik (4NF) és az ötödik normálforma (5NF) szabályokat. A gyakorlat azt mutatja, hogy a felsoroltak közül elegendı az 1NF és a BCNF szabályokat ismerni, amelyek a következık: 1NF:

Az egyedtípus minden attribútumának funkcionálisan függnie kell az egyedtípus azonosítójától (elsıdleges kulcsától).

BCNF: Az egyedtípus minden attribútumának közvetlenül függnie kell az egyedtípus azonosítójától (elsıdleges kulcsától).

8

Ez a normálforma Boyce-ról és Coddról, a relációs adatanalízist megalapozó két matematikusról kapta nevét.


85

A fenti követelményeket kielégítı egyedtípusokat 1NF, illetve BCNF egyed-típusoknak is nevezik. Vegyük észre, hogy a BCNF teljesülésébıl logikailag az 1NF is következik, azaz elvben elegendı lett volna a BCNF szabályt kimondani. Azonban a gyakorlatban egyszerőbb a normalizálás végrehajtása, ha azt két lépésben tesszük meg: elıbb 1NF-re hozzuk a modellt, majd ezt alakítjuk át BCNF-re. Ennek két oka van: (1) Egy 1NF modellben sokkal könnyebb megállapítani az egyes egyedszerkezeteken belüli funkcionális függések közvetlen, illetve közvetett voltát. (2) Egy E egyedtípusról az 1NF-re hozás olyan egyedtípusokat bont le, amelyek az E alárendeltjei lesznek; ezzel szemben egy 1NF-ben lévı E egyedtípusról a BCNF-re hozás olyan egyedtípusokat bont le, amelyek az E fölérendeltjei lesznek. A rend kedvéért a 2.20. ábra összefoglalja a dekompozíciós adatmodellezés normálforma fokozatait a közöttük lévı viszonyt is mutatva. (Az olvasó a részleges és a tranzitív függésre a 2.23. ábra kapcsán kap magyarázatot.) Minden tulajdonság funkcionálisan függ az elsıdleges kulcstól. 1NF 1NF + Nem tartalmaz részleges függést. 2NF 2NF + Nem tartalmaz tranzitív függést. 3NF BCNF Minden tulajdonság közvetlenül függ az elsıdleges kulcstól. 1NF + Nem tartalmaz olyan többértékő függést, amelyben 4NF

a meghatározó tulajdonság különbözik az elsıdleges kulcstól. 1NF + Nem tartalmaz olyan join-függést, amelyben a kapcsoló tulajdonság különbözik az elsıdleges kulcstól. 2.20. ábra: A dekompozíciós adatmodellezés normálformái

5NF

Eredetileg a normalizálás kettınél több lépésben végrehajtott eljárás volt: az 1NF-re hozás után elıször a közvetett függések különbözı – könnyebben felismerhetı – fajtáit küszöbölték ki a vizsgált egyedtípus szerkezetébıl. Így kapták a második, illetve harmadik normálformát. Volt idı, amikor úgy gondolták, hogy a 3NF jelenti a tökéletességet (még ma is írnak olyan „szakkönyveket”, amelyek ezt állítják), azonban amikor világossá vált, hogy a közvetett függéseknek további olyan változatai is lehetnek, amelyeket a 3NF nem küszöböl ki, az összes közvetett függést kizáróként definiálták a BCNF normálformát. Ma már a hagyományokhoz ragaszkodáson kívül semmi nem indokolja, hogy a normalizálás 2NF és 3NF lépéseivel külön is foglalkozzunk. – A 4NF és az 5NF normálformákról csak annyit jegyzünk meg, hogy ezek már nem a funkcionális függésen, hanem a többértékő függésen, illetve a joinfüggésen alapuló kritériummal különíthetık el. Ezekrıl itt részletesebben nem lesz szó, mert a gyakorlati jelentıségük nagyon csekély; ugyanis minden olyan BCNF egyedtípus, amely az elsıdleges kulcson (annak komponensein) kívül más attribútumot is tartalmaz, automatikusan az 5NF-et is teljesíti. (Tehát csak az ú.n. csupakulcs BCNF egyedtípusokról derülhet ki, hogy esetlegesen az nem 5NF.)

Míg az 1NF és a BCNF szabályok inkább tiltásokat fogalmaztak meg, a szintetikus modellezés konstrukciós szabálya (KSz) pozitívan arról szól, hogy milyen egyedtípusoknak kell lenni a modellben: KSz: Ha fennáll az A → B közvetlen függés akkor kell létezni (pontosan egy) olyan E egyedtípusnak, amelynek a szerkezete tartalmazza az A és B attribútumokat, és az elsıdleges kulcsa az A tulajdonság vagy egy olyan C tulajdonság, amelyre fennáll a mindkét irányban kötelezı A ↔ C kölcsönös függés. A fenti szabály némileg bonyolultnak tőnik a közbejött C tulajdonság miatt, ezért egy egyszerősítı magyarázat is jár hozzá: A mindkét irányban kötelezı A ↔ C kölcsönös függés fennállása esetén a C→B funkcionális függés is fennáll, és az is közvetlen. Ezért kell lenni egy olyan egyedtípusnak, amelynek a szerkezetében az emlegetett A, B, C tulajdonságok mindegyike jelen van, továbbá az A és a C tulajdonságok bármelyike egyenértékően választható elsıdleges kulcsnak. Tehát nem mondható ki, hogy biztosan az A lesz az elsıdleges kulcs, mert elıfordulhat, hogy a modellezı inkább a C mellett dönt.

86


2.7.4 Normalizálás lebontással Itt bemutatjuk a lebontási szabályokat alkalmazó normalizálást. Példa 1NF-re átalakításra: A 2.21. táblázat az ALKALMAZOTT egyedtípus reprezentációja, benne a Törzsszám képezi az egyedtípus azonosítóját. A táblázatban csupán a Név és a Munkakör függnek funkcionálisan a Törzsszámtól, mert ezekre igaz, hogy csak egy érték tartozik belılük a Törzsszám bármely értékéhez. Ezért olyan átalakítást fogunk végezni, hogy az ALKALMAZOTT szerkezete 1NF legyen, de ne vesszen el az az információ, hogy melyik járandóságtétel mely alkalmazotthoz tartozik. Átalakítás 1NF-re: A Törzsszámtól nem függı attribútumokat egy másik táblázatba (egyedtípusba) választjuk le, így az ALKALMAZOTT (2.22. táblázat) mellett kapunk még egy JÁRANDÓSÁGTÉTEL egyedtípust is (2.23. táblázat). A Törzsszám az utóbbinak is attribútuma, éppen ezáltal ırzıdik meg az az információ, hogy melyik járandóságtétel melyik alkalmazotté. Az eredeti ALKALMAZOTT tábla három sorából a JÁRANDÓSÁGTÉTEL táblában nyolc sor keletkezett, ezért az utóbbi azonosítójául már nem a Törzsszám, hanem a Törzsszám+Kifiz.dátum+Jogcímkód összetett attribútum választható. (Ez arra az esetre is példa, amikor az idegen kulcs beépül az elsıdleges kulcsba.) ALKALMAZOTT (még nem 1NF) TörzsKifiz. JogcímNév szám dátum kód 1111 AAAA 97.01.05 21 97.01.05 26 97.01.10 27 97.01.10 34 1112 BBBBB 97.01.05 21 97.01.05 34 1113 CCCCC 97.01.05 44 97.02.03 44 ... ... ... ...

Járandóság SzJA SzJA kategória összege kód neve Alapbér 50000 01 Bérjövedelem Prémium 25000 01 Bérjövedelem Külszolg. Térítés 25000 03 Külszolgálati térítés Táppénz 4000 01 Bérjövedelem Alapbér 45000 01 Bérjövedelem Táppénz 25000 01 Bérjövedelem Szerzıi jogdíj 120000 11 Szellemi alkotás jöved. Szerzıi jogdíj 10000 11 Szellemi alkotás jöved. ... ... ... ... Járandóság neve

Munkakör UUUU

UUUU GGGG ...

2.21. táblázat: Normalizálatlan ALKALMAZOTT egyedtípus ALKALMAZOTT TörzsNév szám 1111 AAAA 1112 BBBBB 1113 CCCCC ... ...

Munkakör UUUU UUUU GGGG ...

Vegyük észre, hogy az 1NF-re átalakítás (felbontás) fogalmi szinten a következık miatt hasznos:  Miután a felbontás leválasztotta az önálló JÁRANDÓSÁGTÉTEL egyedtípust, vizsgálhatókká válnak annak más egyedtípusokkal alkotott kapcsolatai is (teljesség), továbbá az ALKALMAZOTT értelmezése is tisztább lett (egyértelmőség).  Könnyebben felismerhetıkké és így elvégezhetıkké válnak a BCNF eléréséhez szükséges átalakítások.

2.22. táblázat: Normalizált ALKALMAZOTT egyedtípus JÁRANDÓSÁGTÉTEL TörzsKifiz. szám dátum 1111 97.01.05 1111 97.01.05 1111 97.01.10 1111 97.01.10 1112 97.01.05 1112 97.01.05 1113 97.01.05 1113 97.02.03 ... ...

Jogcím-kód 21 26 27 34 21 34 44 44 ...

Járandóság neve Alapbér Prémium Külszolg. térítés Táppénz Alapbér Táppénz Szerzıi jogdíj Szerzıi jogdíj ...

Járandóság összege 50000 25000 25000 4000 45000 25000 120000 10000 ...

SzJA kód 01 01 03 01 01 01 11 11 ...

SzJA kategória neve Bérjövedelem Bérjövedelem Külszolgálati térítés Bérjövedelem Bérjövedelem Bérjövedelem Szellemi alkotás jöved. Szellemi alkotás jöved. ...

2.23. táblázat: A leválasztott JÁRANDÓSÁGTÉTEL egyedtípus


87

Az elıbbi példa megoldásában kapott JÁRANDÓSÁGTÉTEL szerkezete nem elégíti ki a BCNF követelményt, mert több közvetett függést tartalmaz. A 2.24. ábra függési diagramjáról az alábbi közvetett függések olvashatók le: Törzsszám+Kifiz.dátum+Jogcímkód → Jogcímkód → Járandóság neve közvetett

Törzsszám+Kifiz.dátum+Jogcímkód → Jogcímkód → SzJA kód közvetett

Jogcímkód → SzJA kód → SzJA kategória neve közvetett

A történeti hőség kedvéért, valamint a 2.20. ábra egyes részeinek utólagos magyarázatául megemlítjük, hogy a 2.23. táblázattal reprezentált JÁRANDÓSÁGTÉTEL egyedtípus szerkezetében, illetve a 2.24. függési diagramon a közvetett funkcionális függések két olyan típusával ismerkedhetünk meg, amelyeket az adatmodellezés elmélete a legkorábban felismert, és sokáig csak ezek kiküszöbölését tartotta fontosnak. Ezek a részleges függés és a tranzitív függés. A részleges függés az A→B→C közvetett függés olyan esete, amelynél a B komponense az A-nak, a C viszont nem komponense sem az A-nak, sem a B-nek. A tranzitív függés az A→B→C közvetett függés olyan esete, amelynél semelyik attribútum sem komponense a másik kettı valamelyikének. A fentebb felsorolt három konkrét közvetett funkcionális föggés közül az elsı kettı a részleges függést, az utolsó pedig a tranzitív függést példázza. Annak bizonyítására, hogy ezeken felül más típusú közvetett függések is léteznek, megemlítjük a kulcstörı függést. A kulcstörı függés az A→B→C közvetett függés olyan esete, amikor a B attribútum nem komponense az A-nak, a C viszont igen. Példa kulcstörı függésre: Ilyen függést tartalmaz egy olyan TRANZAKCIÓ egyedtípus szerkezete, amelyben az azonosító Számlatulajdonos+Mozgásszám, és fennállnak benne a következı közvetett függések: Számlatulajdonos+Mozgásszám → Számlaszám → Számlatulajdonos.

Törzsszám

Járandóság összege

Kifizetés dátum

Járandóság neve

Jogcímkód

SzJA kód

SzJA kategória neve

2.24. ábra: A JÁRANDÓSÁGTÉTEL attribútumainak függési diagramja

A normalizálás folytatása: Az elızı példában kapott JÁRANDÓSÁGTÉTEL egyedtípus szerkezetében (új egyedtípusokba) leválasztással megszüntetjük a közvetett függéseket. Ezt úgy tesszük, hogy közben nem veszik el az az információ, hogy melyik járandóságtétel milyen jogcímő, és hogy az egyes jogcímek mely SzJA kategóriába tartoznak! Segítségül felhasználjuk a 2.24. ábrát és a KSz konstrukciós szabályt. Az elızı példában és az itteni lépésben együttesen végrehajtott normalizálással kapott összes egyedtípus kapcsolatait a 2.26. ábra mutatja.

88


JÁRANDÓSÁGTÉTEL(új) Törzsszám Kifiz.dátum Jogcímkód 1111 97.01.05 21 1111 97.01.05 26 1111 97.01.10 27 1111 97.01.10 34 1112 97.01.05 21 1112 97.01.05 34 1113 97.01.05 44 1113 97.02.03 44 ... ... ...

Járandóság összege 50000 25000 25000 4000 45000 25000 120000 10000 ...

Kulcs: Törzsszám + Kifiz.dátum + Jogcímkód

JOGCÍM Jogcímkód Járandóság neve SzJA kód 21 Alapbér 01 26 Prémium 01 27 Külszolg. térítés 03 34 Táppénz 01 44 Szerzıi jogdíj 11 … … … Kulcs: Jogcímkód SZJA KATEGÓRIA SzJA kód SzJA kategória neve 01 Bérjövedelem 03 Külszolgálati térítés 11 Szellemi alkotás jövedelme … … Kulcs: SzJA kód

2.25. ábra: A JÁRANDÓSÁGTÉTEL egyedtípus lebontásával kapott BCNF egyedtípusok

SZJA KATEGÓRIA

ALKALMAZOTT

JOGCÍM

JÁRANDÓSÁGTÉTEL

2.26. ábra: A normalizálással kapott egyedtípusok kapcsolatai

A JÁRANDÓSÁGTÉTEL felbontása (BCNF-re hozása) kapcsán meg tudjuk mutatni, hogy a közvetett függések kiküszöbölésének elve nem egy öncélú szabály, az alkalmazásának jól megfogható gyakorlati hasznossági indoka van. A 2.25. ábra szerinti felbontás a következı haszonnal jár: h1) Miután a JOGCÍM egyedtípust és az SZJA KATEGÓRIA egyedtípust leválasztottuk a JÁRANDÓSÁGTÉTEL egyedtípusról, egy konkrét jogcímet vagy SzJA kategóriát, anélkül is nyilvántarthatunk, hogy létezne reá vonatkozó konkrét járandóságtétel. h2) Az eredeti JÁRANDÓSÁGTÉTEL táblából valamely konkrét jogcímre (vagy SzJAkategóriára) vonatkozó utolsó járandóságtételt is törölve, elveszik a nyilvántartásból az adott jogcím (vagy SzJA-kategória is). A felbontás után ezek a gondok megszőnnek. h3) Az eredeti JÁRANDÓSÁGTÉTEL táblában a járandóság (jogcímének) nevét vagy az SzJA kategória nevét sok helyen kell nyilvántartani, így egy esetleges változtatáskor többszörösen kell aktualizálni is. A felbontás után ezeket csak egy helyen kell módosítani.


89

h4) A JOGCÍM és az SZJA KATEGÓRIA egyedtípusok más egyedtípusokkal is alkothatnak kapcsolatokat, ezek azonban a felbontás elıtt nem fedezhetık fel és nem vizsgálhatók, mert még a kapcsolódó egyedtípusok sem léteznek önállóan, csak a JÁRANDÓSÁGTÉTEL-be rejtve. A h1)h3) tények éppen annak a megnyilvánulásai, hogy a normalizálás az aktualizálási mőveletekre (nyilvántartásba vételre, törlésre, módosításra) tekintettel optimalizálja a modellt. A h4) pedig azt példázza, hogy a normalizálás elısegíti a tisztánlátást, könnyebben ellenırizhetıvé teszi a modell egyértelmőségét és teljességét. 2.7.5 Normalizálás szintézissel A következı keretezett rész egy olyan adatmodellezési feladatot mutat, amelyet a normalizálás szintetikus változatával vagyis a közvetett függésekbıl kiinduló konstrukciós szabály (KSz) alkalmazásával lehet megoldani. Egy normalizálási feladat kiinduló állapota a szintézis alkalmazása esetén: Az alábbi függések egyidejőleg állnak fenn. A függések és bennük szereplı tulajdonságtípusok felhasználásával kell kialakítani a normalizált (BCNF) adatmodellt. 1. Számlasorszám + Tételsorszám Mértékegység 14. VT-szám VTSZ megnevezés 2. Számlasorszám + Tételsorszám Mennyiség 15. Árazonosító Termékkód 3. Számlasorszám + Tételsorszám Tételérték 16. Árazonosító Egységár 4. Számlasorszám + Tételsorszám Partnernév 17. Árazonosító VTSZ megnevezés 5. VTszám + Érvényesség kezdete ÁFA mérték 18. Partnerkód Partnernév 6. Termékkód VT-szám 19. Számlasorszám Partnerkód 7. Számlasorszám + Tételsorszám Termékkód 20. Termékkód VTSZmegnevezés 8. Számlasorszám Teljesítés dátuma 21. Számlasorszám Fizetési mód 9. Számlasorszám Fizetési határidı 22. Termékkód Terméknév 10. Számlasorszám + Tételsorszám + Szövegsorszám Terméknév 11. Számlasorszám + Tételsorszám + Szövegsorszám Tételszöveg 12. Számlasorszám + Tételsorszám VTSZ megnevezés 13. Számlasorszám + Tételsorszám + Szövegsorszám Fizetési határidı

Számolni kell azzal, hogy az adott függések között esetleg közvetettek is vannak, ezeket a KSz alkalmazása elıtt ki kell szőrni. A közvetett függéseket azon függések között kell keresni, amelyekben a függı tulajdonság más függésekben is függı szerepben fordul elı. A közös függı tulajdonságok miatt példánkban az alábbi függésekre vetül a közvetettség gyanújának árnyéka: 4. Számlasorszám + Tételsorszám Partnernév 18. Partnerkód Partnernév 7. Számlasorszám + Tételsorszám Termékkód 15. Árazonosító Termékkód 9. Számlasorszám Fizetési határidı 13. Számlasorszám + Tételsorszám + Szövegsorszám Fizetési határidı 10. Számlasorszám + Tételsorszám + Szövegsorszám Terméknév 22. Termékkód Terméknév 12. Számlasorszám + Tételsorszám VTSZ megnevezés 14. VT-szám VTSZ megnevezés 17. Árazonosító VTSZ megnevezés 20. Termékkód VTSZmegnevezés A fenti felsorolás az eredeti sorrendtıl azért tért el, hogy a közös függı tulajdonságot tartalmazó függések egymás mellé kerüljenek.

90


Azonban nem minden „gyanús” függés közvetett, mert egyazon függı T tulajdonság olyan okból is megjelenhet több függésben, hogy ez a T elsıdleges kulcsa egy egyedtípusnak, amely pedig közös fölérendeltje több más egyedtípusnak. Tehát a „gyanús” függések közvetettségét további elemzéssel kell bizonyítani. A „gyanús” függések közül csak a következıkrıl bizonyítható, hogy valóban közvetettek. 4. Számlasorszám + Tételsorszám Partnernév 10. Számlasorszám + Tételsorszám + Szövegsorszám Terméknév 12. Számlasorszám + Tételsorszám VTSZ megnevezés 13. Számlasorszám + Tételsorszám + Szövegsorszám Fizetési határidı 17. Árazonosító VTSZ megnevezés 20. Termékkód VTSZmegnevezés A fenti függések közül csak 4-re és a 13-ra mutatjuk meg a közvetettség bizonyítását, a többinél ezt az olvasóra bízzuk. 4. bizonyítása: A funkcionális függések projektív tulajdonságából, a 19. függésbıl, valamint a 18. függésbıl kapjuk: Számlasorszám + Tételsorszám Számlasorszám Partnerkód Partnernév 13. bizonyítása: A funkcionális függések projektív tulajdonságából és a 9. függésbıl kapjuk: Számlasorszám+Tételsorszám+SzövegsorszámSzámlasorszámFizetési határidı

A közvetett függések kiejtése után a maradék függéseket felhasználva és a KSz-t alkalmazva módszeresen kialakíthatók az eleve BCNF szerkezető egyedtípusok. A megmaradt (közvetlen) függésekbıl a következı egyedtípusok adódnak: SZÁMLATÉTEL (Számlasorszám + Tételsorszám, Mértékegység, Mennyiség, Tételérték, Termékkód) ÁFAMÉRTÉK (VTszám + Érvényesség kezdete, ÁFA mérték) TERMÉK (Termékkód, VTszám, Terméknév) SZÁMLAFEJ(Számlasorszám, Teljesítés dátuma, Fizetési határidı, Partnerkód, Fizetési mód) TÉTELSZÖVEG (Számlasorszám + Tételsorszám + Szövegsorszám, Tételszöveg) VTSZ (VTszám, VTSZmegnevezés) TERMÉKÁR (Árazonosító, Termékkód, Egységár) PARTNER (Partnerkód, Partnernév)

2.7.6 Ellenırzı kérdések a 2.7. alfejezethez 1. Mit értenek adatmodellezés alatt? 2. Mi a különbség a fogalmi, a logikai és a fizikai adatmodellek között? 3. Milyen viszonyban állnak a specifikált adat értelmezésének bizonyos komponensei az adatmodellezés egyedtípus és egyed fogalmaival? 4. Mit értenek az egyedtípus (entitás) szerkezetén? 5. Mit mutat az ERD diagram? 6. Milyen kritériumokat kell teljesíteni az egyedtípus azonosító tulajdonságának (elsıdleges kulcsának)? 7. Az adatmodellezés milyen tulajdonságait vizsgálja a kapcsolattípusoknak? 8. Mondjon példát: (1) hierarchikus kapcsolatra; (2) több-a-többhöz fokú kapcsolatra; (3) fıtípus-altípus kapcsolatra; (4) visszamutató kapcsolatra; (5) többszörös kapcsolatra! 9. Mit értenek idegen kulcson? 10. Mit értenek hivatkozásintegritási szabályok alatt? 11. Milyen célt szolgál a normalizálás?

ADATSZERVEZÉS, ADATELÉRÉS, ADATBÁZISKEZELİ RENDSZEREK 12. Mondjon példát funkcionális függésre! 13. Miben áll a funkcionális függés tranzitív és projektív tulajdonsága? 14. Egy egyedtípus szerkezete mikor áll az elsı normálformában (1NF)? 15. Mit jelent az, hogy egy egyedtípus szerkezete teljesíti a BCNF szabályt? 18. Hogyan szól a szintetikus (adat)modellezés konstrukciós szabálya? 19. Mit mutat a függési diagram? 20. Mondjon példát kulcstörı függésre!

91

92


FELHASZNÁLT ÉS AJÁNLOTT IRODALOM A 2. FEJEZETHEZ [CODASYL-1971] CODASYL DATA BASE TASK GROUP: April 1971 Report. ACM, 1971. [Codd-1971] CODD, E. F.: Further normalization of the data base relational model. Courant Computer science Symposium 6, „Data base systems”. 1971. [Codd-1993] CODD, E. F.(és Tsai): Providing OLAP (On-line Analytical Processing) to UserAnalysts: An IT Mandate. ARBOR SOFTWARE, 1993. [Halassy-1978] HALASSY BÉLA: Adatbázisok kezelésének alapvetı kérdései. SZÁMOK, 1978. [Halassy-1994] HALASSY BÉLA: Az adatbázis-tervezés alapjai és titkai. IDG Magyarországi Lapkiadó Kft., 1994. [Mérey-1979] MÉREY A.: Adatszerkezetek. SZÁMOK, 1979. [Quittner-1993] QUITTNER PÁL.: Adatbáziskezelés a gyakorlatban. Akadémiai Kiadó, 1993.

2. Adatszervezés, adatelérés, adatbáziskezelı rendszerek

Recommend Documents