Mint már említettük, az adatbázisok készítésénél és használatánál modellekben kell gondolkodnunk. Az egyes DBMS-ekhez saját modellek tartoznak, melyeken keresztül valósítható meg a felhasználó vagy tervezõ és az adatbázis kapcsolata. Az adatok tárolásának leírására szolgáló modelleket nevezik adatmodelleknek. A következõkben az adatmodell fogalmát részletesebben fogjuk elemzni.

Nézzük, mint is tudunk már az adatmodellekrõl. Az elõzõ rész alapján megállapíthatjuk, hogy az adatmodell

Ha tehát mi magunk kívánnánk egy saját adatmodellt létrehozni, aminek egyébként semmi akadálya sincs (az irodalomban is számtalan különbözõ adatmodell változat lelhetõ fel), akkor mindenek elõtt egy olyan eszközrendszert, jelölésrendszert kellene létrehoznunk, melyek elemeit a modellezett valóság különbözõ elemeihez hozzárendelve, leírható vele a problématerület minden lényeges eleme. Az egyes adatmodellek lényegileg az alábbi szempontokban térhetnek el egymástól:

Elméletileg a megoldások elképesztõen széles skáláját lehetne létrehozni a különbözõ elemek változtatásával. Példaként vehetünk egy olyan modellt, melyben a valóság résztvevõ elemeit lerajzoljuk. Ez a megoldás ugyan mindenki számára igen könnyen érthetõ jelölésrendszert ad, azonban könnyen látható e javaslat hátrányai is: a jelölésrendszer csak szûk problémakörre alkalmazható, a valóság egyes elemei nem fejezhetõk ki vele, s nehézséget okozna a számítógépes értelmezés is. Az értelmes és hasznos adatmodellek köre tehát sokkal szûkebb az elméletileg létrehozható modellek körénél, de még így is számtalan modellváltozat él a gyakorlatban.

A különbözõ adatmodellek megjelenésével együtt felmerült az igény e fogalom pontosabb jelentésének tisztázására is. Szükség van tehát egy egységes értelmezésre, mely irányt mutat a késõbbi adatmodellek kidolgozására, s mely alapján megitélhetõk az egyes változatok jósága is.

Az adatmodell pontos fogalmának meghatározása az 1980-as évek elején jelent meg az irodalomban. Pontosabban, a nagyobb nyilvánosság számára 1981-re jelent meg Codd cikke, melyben elsõként adja meg az adatmodell egzaktabb értelmezését. Ezen megközelítést aktualizálva, mi a következõkben adjuk meg az adatmodell jelentését.

Az adatmodell olyan matematikai formalizmus, mely a valóság adatorientált leírására alkalmas. Az adatmodellnek a valóság teljes értékû megadásához az alábbi három komponenset kell tartalmaznia:

E hármas tagolódás az adatmodellek lényeges jellemzõje, s a gyakorlati DBMS adatmodellek leírásaiban, utasításaiban is jól megfigyelhetõk e komponensek jelenléte. E komponensek jelentésének bemutatására vegyünk egy egyszerûsített példát. Egy bankkártya kezelõ információs rendszert kiválasztva, az adatbázis leírására szolgáló adatmodell esetén, a felhasznált adatmodellnek

A modell egyes komponenseit igen különbözõ módon és formában meg lehet valósítani. Tekintsük át ezért a következõkben, milyen szempontokat lehet figyelembe venni egy adatmodell értékelésénél, mikor tekinthetünk egy adatmodell jónak. E szempontokat egy listában fogjuk össze.

A teljesség kedvéért megemlítjük, hogy az adatmodell megadott értelmezése mellett egyéb megközelítések is léteznek. E megközelítések jellemzõje, hogy sokkal tágabban veszik az adatmodellek körét. Egy ilyen értelmezés olvasható például Halassy könyében, mely szerint az

Mint látható ezen megközelítés két ponton tér el lényegesen az elõzõ definíciótól:

Most nem térünk ki, hogy mit is értsünk pontosab egyed, tulajdonság alatt, hiszen ezeken fogalmakra egy külön fejezetet fogunk szentelni az ER modellek keretében. A most megadott definícióról mindesetre megállapítható, hogy igen szoros kapcsolatban egy létezõ adatmodellel, az ER modellel. Ugyanis a gyakorlatban adatmodellnek tekintett rendszerek döntõ része nem tesz eleget az általunk megadott kritériumoknak. Ugyis mondhatjuk, hogy a mi definíciónk egy szigurú, szûkebb értelemben vett adatmodellt jelölt ki.

A lazább, tágabb értelmeben vett értelmezés szerint az adatmodelleknek nem szükségszerû része a mûveleti és integritási rész. Így a tágabb értelmû adatmodellek körébe vehetõ fel egy sor olyan modell is, melyek a tervezés elõsegítése céljából, a valóság struktúrális vetületének a leképzésére szorítkoznak. A következõ fejezetben, a szemantikai adatmodellek között részletsebben is meg foguk ismerkedni néhány ilyan szûkebb értelemben vett adatmodellel.

Az adatmodell definicóját azonban nemcsak szûkítési céllal lehet módosítani. Codd értelmezésében az adatmodellhez a fenti három komponens mellett hozzátartozik még egy negyedik, úgynevezett értelmezési, interpretációs rész is, amely megadja, hogy mi a jelentése az egyes modellelemeknek. Eszerint a jelentés nélkül létrehozott modell nem használható pragmatikus célokra.

E felfogás jogosságát vitatja Gilula, aki szerint különbséget kell tenni információs és adatmodell között. E két fogalom viszonya hasonló az információelméletben szereplõ jelentés és jelhordozó fogalmak közötti különbséghez. Az egyikhez tartozik értelmezés, jelentés, míg a másik egy formális leírást takar.

Gilula értelemzése szerint csak az információs modellhez szükséges jelentést, interpretációt csatolni. Az adatmodell ezzel szemben egy formális leírást jelent, így nem szükséges hozzá interpretációt is kötni. Ez az érvelés azon a tényen alapszik, hogy egy adatbázisban szerkezetét akkor is fel tudom tárni, ha nem ismerem az egyes szerkezeti elemek jelentését, s akkor is tudunk adatokat lekérdezni és az integritási szabályok által meghatározott kereteken belül felvinni és módosítani, ha nem vagyunk tisztában az adatok, az értékek jelentésével.

A szemantika szó magyarul egy jelsorozat jelentésnek fordítható. Az szemantikai adatmodell (SDM) kifejezés nem egy, önálló modellt jelöl, hanem egy modellcsaládot, melybe több különálló modell is beletartozik. Ami közös ezekben a modellekben, hogy mindegyik a felhasználóhoz közelálló, jelentésgazdag, szemantikai eszközkészlettel, modellel írja le a modellezett valóságot. A szemantikai adatmodellek célja a valóság leírását a számítógépnél megszokott egyszínû, szintaktikai kezelés, leírás helyett szemantikailag gazdagabbá tenni.

Itt például gondolhatunk arra, hogy milyen hasznos lenne, ha a DBMS tudná, hogy nincs értelme mondjuk a kocsi súlyát a gyártási évével összehasonlítani, habár szintaktikailag mindkettô azonos, hiszen egy numerikus értékkel adható meg mindkettõ. A szemantikai modellek célja olyan leírást nyujtani, amelyben sokkal sokrétûbben megadhatók a valóságban fennálló viszonyok.

Mint már említettük, az SDM modelleknek ma még elsôdlegesen csak a tervezés során van szerepe, mivel még nem készültek SDM modellen alapuló DBMS implementációk. Ha közvetlen megvalósításuk nincs is, de igen erôs hatást fejtettek ki az egyes SDM tervezetek az adatbázismodellek kutatásában, melyekbôl a jövô DBMS modelljei fejlôdhetnek ki. Ezt jól példázza az objektum orientált adatmodellek elterjedése, mely nem is olyan régen mégcsak SDM formájában létezett, mint tervezési segédeszköz, mára azonban már DBMS modellé nõtte ki magát.

Az SDM modellek igen különböznek eszközkészletükben, ábrázolási módjukban, de sok közös vonás is felfedezhetô bennük. Közös a modellek célja, és a legfontosabb irányelvek, melyek e célok elérését irányozzák elô.

A valós világ tudatos modellezésének kérdése az emberiség igen régi problémája. Ismereteink szerint, már az antik görög kulturában, fõleg Arisztotelész nevéhez kapcsolódóan, megjelent az a mai is élõ világszemlélet, mely szerint a világ több egymástól elkülöníthetõ egységbõl áll, melyek között különbözõ struktúrális, asszociációs kapcsolatok állhatnak fönn. Magunkon is megfigyelhetjük, hogy amikor egy problémakört modellezünk, leírunk, a valóságot valamiképpen lebontjuk több, egymástól jól elkülöníthetõ, önálló léttel bíró egységekre, melyeket objektumoknak is nevezhetünk. A modellezés során önálló fogalmakat használunk az egyes objektumok azonosítására. Az egyes objektumok között különbözõ asszociácókat fedezhetünk fel, melyek utalhatnak tartósabb, mélyebb, struktúrális kapcsolatokra, de lehetnek ideiglenes jellegû kapcsolatok is.

Egy iskolai osztály modellezésénél önálló egységként megjelenõ fogalmak lesznek többek között a diák, a név, az életkor, a lakcím, az iskolai pad, stb. Az egyes objektumok közötti tartósabb kapcsolatkora lehet példa a diák és a név, a diák és a lakcím (feltéve, hogy minden diáknak kell lennie nevének, lakcímének), míg a diákok közötti baráti viszony egy lazább kapcsolatot reprezentál a modellen belül.

Az SDM modellek célja a bennünk megjelenõ valóság modell minnél hûbb és teljesebb leírása, mely során a számítástechnikai realizálhatóság hatékonysága csak másodlagos szerepet játszik. Az SDM modellekben megvalósuló legfontosabb törekvések a következô pontokban foglalhatók össze:

A SDM modellekben a fogalmak két nagy csoportját különböztethetjük meg, hiszen az SDM is, mint minden más adatmodell, tartalmazhat statikus, struktúra leíró elemeket, és a mûveletek leírására alkalmas dinamikus elemeket.

A statikus elemek leggyakoribb képviselôi:

A dinamikus elemek leggyakoribb képviselôi:

A fenti felsorolás megadja a SDM modellek legfontosabb komponenseit. Ez a felsorolást azonban semmiképpen sem szabad egy szigurú szabályként értelmezni, hiszen nagyon sokféle SDM modell létezik, melyek egymástól mind kifejezõképességben, mind formalizmusban eltérhetnek. Így több olyan modell is létezik, melyek a felsorolt elemekenek csak egy részét, néha csak egy töredékét tartalmazzák. Így a fenti felsorolás inkább egy összesítésnek tekinthetõ, mely lefedi az egyes SDM modelleket.

Nyilvánvalóan felmerül a kérdés, ha a fenti komponensek együttese biztosítja a legjobb megoldást, miért léteznek még egyéb, egyszerûbb SDM modellek is. Erre a kérdésre a válaszunk az, hogy e szempontok fontossága nem egycsapásra vált ismerté a köztudatban, hanem egy hosszabb folyamat eredményeként alakult ki. Elõbb egyszerûbb modellek jöttek létre, melyek folyamatosan búvültek újabb és újabb elemekkel. Másrészt azt is be kell valanni, hogy habár azt mondtuk, hogy az SDM esetén nem elsõdleges a DBMS megvalósíthatóság hatékonysága, azonban teljesen nem vethetõ el ez a szempont sem. Így olyan SDM modellek elterjedése valószínû, melyek jól igazodnak a létezõ DBMS kezelõ nyelvhez. Így például hiába tudunk az SDM modellben mûveleti integritási feltételeket megadni, ha az alkalmazott DBSM ezt a szolgáltatást nem tudja nyujtani. A gyakorlatiasság igénye tehát az egyszerûbb SDM modelleket is életben tartja.

Zárójelben megjegyezzük, hogy ez a gyakorlatiasság hosszabb távon azzal járthat, hogy egy szintaktikailag erõsebb DBMS installálása után újra kell tervezni (reengineering) az addigi alakalmazás modelljét, hogy kihasználjuk az új rendszer elõnyeit.

A következõkben áttekintjük a gyakorlatban legfontosabb SDM modelleket, melyeket tehát majd az adatbázisok tervezése során fogunk felhasználni. Elõbb az egyszerûbb, a relációs DBMS-ekhez közel álló E/R adatmodellt vesszük, majd a fejletteb objektum orientált irányba haladunk tovább.

E/R adatmodell

A kidolgozott számtalan SDM modell közül elsôként a legegyszerûbb, gyakorlatban igen elterjedt módszert, az E/R modellt vesszük át. Az E/R modell, vagy rövidítés nélkül az egyed-kapcsolat (Entity Relationship)

modell az SDM modellek legismertebb képviselôje. Az E/R modell alapjai 1976-ban jelentek meg, Chen publikációja nyomán. Az E/R modell igen szoros kapcsolatban áll a korábban kidolgozott relációs adatmodellel, habár indulásként önálló adatmodelleként kívánták bevezetni, ma már, számos kiegészítés és javítás után, mint a relációs modellezés bevezetõjeként alkalmazzák. Elõnyei közé tartozik az egyszerûség és a szoros kapcsolat, a könnyû konvertálhatóság a relációs modell felé.

Az E/R modell, mint az a neve részben mutatja, három alapelemen nyugszik: az egyedek (entity), az egyedek közötti kapcsolatok(relation) és az egyedek tuéajdonságok (attributes) fogalmain. az E/R modell kizárólag a valóság struktúrális leírásán alapszik, megengedve bizonyos egyszerûbb integritási feltéleket is. E egyszerûség miatt , korábban vita bontakozott ki, hogy menyiben tekinthetõ egyáltalán adatmodellnek az E/R rendszer. Codd, a relációs modell atyja, így jellemzete a modellt:

'I wouldn't call the E/R stuff s model because a data model must do more then support data base design,... the E/R model is narrow and shallow. It has no real susbtance and lacks precision and rigor.'

Vagyis Codd értelmezésében az E/R modell csak az adattervezést támogatja, nem biztosít megfelelõ precizitást, ezért nem tekinthetõ adatmodellnek. Mi azonban már kissé tágabban értelmezzük az adatmodell fogalmát, hasonlóan Date-hez, aki szerint

'E/R model is indeed a data model, but one that is essentially just a thin layer on top of the basic relational model.'

Mint látni fogjuk, az E/R modellel egy egyszerû és elterjedt modellezési segédeszközt fogunk megismerni. Az E/R alapfogalmak pontosabb megismeréséhez induljunk ki a modellezett világból. Hogyan írnánk le mondjuk egy egyetem szerkezetét? Azt mondhatnánk, hogy az egyetemen vannak hallgatók, tanárok, tantárgyak, órák. Minden hallgatót meg tudunk különböztetni egymástól, hasonlóan a tanárokhoz, tantárgyakhoz vagy órákhoz. Mindegyik a világ egy önálló darabja, szereplôje, korábbi szóhasználattal élve objektuma. Az E/R terminológiában a modellezett világ azon szereplôit, melyel önálló léttel bírnak és melyekrõl több különbözõ információt tartunk nyilván, egyedeknek nevezik. Így egyednek tekinthetõ pl. a hallgató, melyrõl nyilvántartjuk többek között a nevét, a korát, az érdemjegyeit, stb.

Az egyedek között vannak hasonló szerkezetûek, és vannak egymástól igen különbözô felépítésûek. A hasonló felépítésû egyedek pl. hallgatók alkotnak egy egyedtípust. Ilyen egyedtípus a hallgatók, a tanárok, a tantárgyak típusa is. Ekkor minden egyedtípus több egyedelôfordulást ölel át, ahol egy egyedelôfordulás egy konkrét egyedet, egy konkrét hallgatót, vagy egy konkrét tanárt jelöl.

A valóságban jól meg tudjuk különböztetni az egyik hallgatót a másiktól, az egyik tantárgyat a másiktól. Hogyan tesszük ezt? Úgy hogy az egyik hallgató barna hajú, a másik fekete hajú, vagy az egyik hallgatót Nagy Gabriellának hívják, a másikat pedig Varga Tibornak. Tehát mindegyik hallgató rendelkezik egy sor tulajdonsággal, melyek más-más értékeket vehetnek fel az egyes hallgatóknál. A tulajdonságok az egyedhez kapcsolódó leíró szerepet betöltõ értékeket jelölnek. Az egyedelôfordulásokat is az egyed tulajdonságai alapján azonosíthatjuk be. Az egyes egyedtípusok pedig elsôdlegesen a típushoz tartozó tulajdonságok körében térnek el egymástól. Hiszen más adatokat tartunk nyilván egy tanárról, mint egy tantárgyról. Az egyedtípus lényeges jellemzôje tehát a hozzá tartozó tulajdonságok köre.

Az egyedelôfordulások és az egyedtípusok azonban nem izolált, elszigetelt szereplôi a modellezett világnak, az egyedek kapcsolatban állnak más egyedekkel, egy összetettebb struktúrát hozva létre. A példánknál maradva egy hallgató több tantárgyhoz is kötôdik, egy tanár is kapcsolódhat több tantárgyhoz. Tehát a modellben az egyedek mellett a kapcsolataiknak is szerepelni kell. Az egyedek között különbözô bonyolultságú kapcsolatok állhatnak fel, s a modell akkor jó, ha alkalmas a kapcsolatok árnyalt kifejezésére.

Az E/R modell a valóság hûbb leképézésére az egyszerû egyed és kapcsolat elemek mellett megkülönböztet több változatát mind az egyedeknek, mind a kapcsolatoknak. E változatok között lényeges jelentésbeli és viselkedési különbségek vannak, s ezen kívül egészen másféle relációs modellbeli elemekre képzõdnek le.

Az E/R modell egyik lényeges tulajdonsága, hogy egy grafikus jelölésrendszert alkalmaz. A grafika, a szöveges leírástól eltérõen sokkal kifejezõbb és lényegretörõbb a emberek számára, így kiválóan alkalmas a fontosabb fogalmak és kapcsolatok kiemelésére. A ma használatos E/R modell teljes elemkészletének részletes leírását és grafikai szimbólumaikat a következôkben adhatjuk meg:

- Egyed:

egy a külvilág többi részétôl egyértelmûen megkülönböztethetô dolog

altípusai:

- normál egyed: rendelkezik olyan tulajdonságcsoporttal, mely egyértelmûen azonosítja az egyedet. Egy autó például normál egyed, hiszen mind a rendszáma, mind a gyártási száma egyedi azonosítóként szolgálhat. Jele egy téglalap, melynek belsejében az egyedtipus azonosító neve áll:

 

 

 

- gyenge egyed: nincs azonosító tulajdonságrendszere, így más egyedhez fûzôdô kapcsolata szükséges az azonosításához. Elõfordulhat példásul, hogy egy személynek nem tudjuk az azonosító adatait, csak egy nevét és azt hogy egy másik azonosított személynek valamilyen rokona. Így az illetõ egyértelmû kijelöléséhez szükség van a másik ismert személy megadására is. A gyenge egyed grafikus jele a duppla kerettel rajzolt téglalap, középen az azonosító névvel:

 

- Tulajdonság

az egyed egy meghatározott jellemzôje

altípusai

- Kapcsolat

az egyedek között fennálló viszonyt hordozza.

altípusai

Az E/R modell használatára tekintsük a következô ábrát, mely egy képzeletbeli üzemi konyha nyilvántartásának egy részletét ábrázolja.

A minta modellben három egyed van, az étel, nyersanyag és szállító. Mindhárom erõs egyed, mivel vannak kulcs tulajdonságaik. A tulajdonságok, a rendelés tulajdonságot kivéve egyszerû, elemi értékkel rendelkezõ tulajdonságok. A rendelés pedig egy összetett, többértékû tulajdonságként szerepel a modellben. Egy ételre tehát több rendelés is vonatkozhat, s minden rendelésnél a dátumot és a mennyiséget kell megadni. Az összár tulajdonság a többitõl eltérõen származtatott tulajdonság, hiszen a készlet és ear, azaz egységár tulajdonságokból, azok szorzataként megadható az értéke. A nyersanyag és a szállító között 1:N, míg az étel és nyersanyag között N:M tipusú a kapcsolat. A benne jelzésû kapcsolatnál látható, hogy tulajdonságot nemcsak egyedekhez, hanem kapcsolatokhoz is rendelhetünk az E/R modell keretein belül.

Az adatbázis létrehozása során elsõ lépésként rendszerint az E/R modell segítségével hozzák létre a problémakör adatstruktúrájának szemantikai leírását. Mint minden összetett rendszert, az E/R leírást is több különbözõ úton haladva hozhatjuk létre. Itt is célszerû azonban azt a bevált módszert alkalmazni, hogy elõbb a fontosabb, lényegesebb elemeket határozzuk meg, majd ezekre alapozva késõbb finomítjuk, kibõvítjük a modellt egyéb kevésbé fontos elemekkel.

Az E/R modell esetén a központi szerepet az egyedek játszák, hiszen köréjük csoportosulva léteznek a tulajdonságok és a kapcsolatok is, azaz egyedek nélkül sem tulajdonság, sem kapcsolat nem létezik. Ezért a tervezés során célszerû elsõként a problématerületen megjelenõ egyedeket számba venni, nevet és jelentést adva nekik.

Az egyedek felrajzolása után sorra vehetjük az egyedek között fennálló kapcsolatokat, kijelölve a kapcsolatok jellegét is. Az egyedek és a kapcsolatok együtt alkotják az E/R modell gerincét, vázát. Alapvetõen e váz határozza meg a késõbbiekben létrehozandó DBMS adatmodell struktúráját is.

Az egyedek és kapcsolatok megadása után sorba vehetjük, hogy milyen információkra van szükség az egyes egyedekre és kapcsolatokra vonatkozóan. A tulajdonságok kijelölésénél ügyeljünk arra, hogy milyen értékeket vehetnek fel, megkülönböztetve a többértékû és összetett és származtatott tulajdonságokat.

A tervezés elõbbiekben megadott lépéseit, azaz a

nem egy szigorú szekvencia mentén hajtódik végre, hiszen a bonyolultabb rendszerek esetén sokszor csak a késõbbi lépésekben derülnek ki olyan módosítási igények, melyek korábbi lépések eredményeire vonatkoznak, azaz az E/R modell tervezése esetén is, hasonlóan a szoftver termékek általános tervezési metódikájához, ciklikus, ismétlõdõ tevékenységek mentén haladunk elõre.

Az E/R modellezés egyik sajátsága mutatkozik meg abban a tapasztalatban, hogy amikor egy hallgatói csoportnak maximálisnak vélt részletezetettséggel kijelölünk egy adott modellezendõ problémakört, sohasem lesznek az önállóan elkészült modellek egyformák. A jó, elfogadott modellek sem lesznek egyformák, vagyis egy problémakörre több, egymástól valamelyest eltérõ megoldás is létezik. Nézzük meg, mibõl is fakadhatnak ezek a különbségek, a Codd által is kifogásolt hiánya a precizitásnak.

Az E/R modell egyik jellemzõje, hogy az emberközlei fogalmakkal dolgozik, azaz egy tulajdonság megadása egyetlen emberi fogalommal történik, mint például név, cím. Az emberi fogalmakhoz viszont, mint közismert, igen gyakran bizonyatlan, pontatlan értelmezések és jelentések társulnak. Vegyük pélsául a cím fogalmát. A cím önmagában nagyon sokmindent jelenthet, pl. egy azonosító nevet vagy egy lakcímet. Ezenkívül a lakcím értelmezésére is több különbözõ megoldás kínálkozhat, hiszen ha akarjuk belevesszük az országkódot, az irányítószámot, s ha akarjuk kihagyhatjuk õket. Hasonló problémával találjuk magunkat szemben a név mezõ esetén is. Talán még felsorolni és szép munka lenne, hogy hányféleképpen lehet megadni egy nevet, igen érdekes kérdés, például hogy hol helyezkedjenek el a címek és rangok a néven belül. Egy másik gyakori félreértési forrásra mutat rá a videokölcsönzõ példánál elõforduló eset. Az elkészült modellben mindenki szerepelteti a kölcsönzés fogalmat. De a kölcsönzés fogalom mást-mást jelent az egyes modellekben, ugyanis valaki a kölcsönzés alatt az éppen élõ kölcsönzéseket veszi, míg mások a már valaha megtörtént kölcsönzéseket értik a megjeleölés alatt. e kéféle megközelítés pedig egészen másféle kezelési módot kíván a tervezés késõbbi fázisaiban.

A kialakult modell szempontjából a bizonyatlanság másik forrása, hogy a tulajdonságok szerkezetét mennyire részletesen vegyük. A lakcím példájánál maradva a kérdés az, hogy egy egyszerû lakcím mezõt, vagy egy összetett lakcím mezõt szerepeltessük, amely az irányítószám, város, ország, utca, házszám mezõkra bomlik fel. Mi adhat itt útmutatást? Tanácsként azt javasolhatjuk, hogy abban az esetben, ha a feldolgozás során szükség van a részadatokra, mint önálló adatokra, akkor célszerû felbontani a tulajdonságot elemeire. Így például, ha szükség van az emberek város szerinti statisztikájára, akkor célszerû kiemelni a város tagok a lakcím tulajdonságból. Ha viszont semmi szükség sincs a részletek önálló elérésére, akkor feleslegesnek látszik a felbontás, habár ezzel szemantikai hibát nem okozhatunk.

A tervezõnek a modellezés során számos esetben egy fogalom ábrázolására is több lehetõsége is van. Természetesen az egyes változatok nem teljesen egyenértékûek, de mindegyiknek lehet létjogosultsága. Elsõként nézzük azt az esetet, amikor egy fogalom egyed és tulajdonság is lehet. Ehhez vegyük az ügyosztály fogalmát példaként. Egy vállalati struktúra modellezésénél szerepelni kell a dolgozoók, projektek mellett az egyes ügyosztályoknak is, tehát az ügyosztálynak, mint egyednek kell megjelennie, mint az a következõ modellréászlet is mutatja:

Ha viszont, mondjuk a vállalat egy önállóan mûködõ könyvtári rendszerét modellezük, melyekben szintén nyilvántartjuk a dolgozókat az adataikkal együtt, akkor a dolgozó munkahelye, az ügyosztály tulajdonságként is szerepelhet. Az ügyosztály tulajdonságot akár összetett tulajdonságként is szereplethetjük:

Mindkét modell elfogadható. Miért volt tehát ez egyik esetben egyed a másikban tulajdonság ugyanaz a fogalom. Az elsõ esetben az ügyosztály úgy szerepel, mint önálló egysége a problémakörnek, amely önállóan, a többi egyedtõl függetlenül létezik. A másik esetben az ügyosztály nem létezik önállóan, csak a dolgozókhoz kötõdve, a dolgozóhoz kapcsolódva, annak egyik jellemzõjeként él. Ezért ebben az esetben nem egyed, csak tulajdonság. A kétféle megközelítés tehát a fontosság, az önállóság tekintetében tér el egymástól.

A foglamak ábrázolási lehetõségeit vizsgálva olyan esetek is elõfordulhatnak, amikor a fogalmat egyedként és kapcsolatként is ábrázolhatjuk. Vegyük példaként a házasság fogalmát. Egy polgármesteri, anyakönyvi hivatalban a nyilvántartás kiterjed a házasságkötésekre is. Ekkor a modellben a házasság, mint önálló léttel bíró fogalmo, mint egyed szereplhet, melyen önálló kérdéseket, mûveleteket végezhetünk el, pl. lekérdezhetjük, hogy mennyi házasságot kötöttek az elmúlt negyedévben. A elkészült modell egy részletét mutatja a következõ ábra:

Ha viszont pl. egy adónyilvántartási adatbázist dolgozunk ki, akkor nem a házasság, mint önálló egyed a lényeges, hanem csak az általa megvalósuló kapcsolat, hogy kik tartoznak egy családba. Ezért ebben az esetben a házasság, mint kapcsolat jelenik meg az adófizetõ polgárok között:

Itt a házasság fogalomból azért lett kapcsolat, mert nem a fogalom közvetlen elõfordulásai, hanem az általa kijelölt kapcsolatok játszanak szerepet a modellben.

A harmadik döntési helyzet, amikor egy fogalomról el kell dönteni, hogy tulajdonság vagy kapcsolat legyen. Vegyük példaként az autó-ember tulajdonosi viszonyt. Ekkor lehet úgy is gondolkodni, hogy a tulajdonosi viszonyt úgy is nyilván lehet tartani, hogy az autóhoz (pl. annak forgalmi igazolásába) bejegyezzük a tulajdonos azonosítóját. Így a tulajdonosi viszonyt egy tulajdonságon keresztül tartjuk nyilván:

A másik megoldás, hogy a tulajdonlást egy kapcsolaton keresztül ábrázoljuk:

E megoldás azt emeli ki, hogy kapcsolatban áll a két egyed egymással. Az irodalomban ezt a megoldást javasolja, az elõzõ változattal szemben, hiszen ez szamantikailag helyesebb és többet mond. Alapszabályként elfogadhatjuk, hogy csak azon fogalmakat vegyük tulajdonságként, melyek csak az egyedhez kapcsolódnak, az egyed elválaszthatatlan része, mely akkor is megvan, ha az egyed önmagában létezne. Az elsõ megoldás ennek az elvnek nem tesz eleget, hiszen a tulaj mezõ csak akkor kell az autóhoz, ha vannak tulajdonosok. Ha az autó csak önmagában létezne, akkor nem lenne szükség tulajdonos jellemzõre sem.

Nem követendõ az a furcsa megoldás sem, amellyel szintén lehet találkozni a megoldások között, s mely ötvözi az elsõ kettõ változatot, azaz mind a kapcsolat mind a tulajdonság megadás szerepel:

Ezzel nemcsak felesleges tulajdonságot vittünk fel, hanem redundáns adatokat is megadtunk a modellben, ami zavarólag hat a tervezés késõbbi fázisaiban a DBMS modell kialakításánál is.

A fenti példákból látható, hogy az E/R modell értelmezése nem túl szigorú, számos esetben többféle változat is létezek a valóság modellezésére. Ezek a változatok egymástól bizonyos hangsúly eltolódásban különböznek, melyekre érdemes odafigyelni a tervezés során.

Az objektum orientált szemlélet elterjedésével egyre nõtt az igény az olyan SDM modellek felé, melyek már tartalmaznak bizonyos eszközöket a fejlettebb modell elemek leírására is. Az E/R modell ezirányú közvetlen továbbfejlesztésének eredményeként jöttek létre az EE/R modellek, amelyek az Extended E/R, azaz kibõvített E/R modell elnevezést viselik.

Az EE/R modelleknek több különbözõ változatai vannak, melyek formalizmusban és elemkészletben különböznek egymástól. Mi most a Lawrence Berkeley Laboratory által kidolgozott EE/R modellt mutatjuk be. A modell leírását egy 1994-ben megjelent cikk alapján adjuk meg. A megadott modellhez hasonló elemeket tartalmaznak a többi kiterjesztések is.

A kiterjesztések alapvetõ eleme az osztályok és az osztályok közötti öröklési kapcsolatok figyelembe vétele. Az EE/R modell két új elemet tartalmaz az E/R modellel összevetve, mindkettõ az egyedek közötti kapcsolatokra vonatkozik. Az egyik elem a tartalmazási kapcsolat, a másik új elem a specializációs kapcsolat.

A tartalmazási kapcsolat két egyedtipus között azt jelképezi, hogy az egyik egyed minden elõfordulása tartalmazza a másik egyed elõfordulásait. Például minden autónak van motorja, így a modellben az autó és a motor egyedek között egy tartalmazási reláció lesz. A tartalmazási reláció nem szimmetrikus, hiszen abból hogy az autó tartalmazza a motort, jön hogy a motor nem tartalmazhatja az autót. Így az EE/R modellben a tartalmazási relációt egy asszimmetrikus szimbólummal, egy nyíllal reprezentálják, amely a tartalmazó egyedbõl mutat a tartalmazott egyedbe. A nyil mellé odaírják a HAS szimbólumot, mivel a nyíl másféle szerepben is elõfordulhat még. Az alábbi ábrában az A egyed tartalmazza a B egyedet:

A másik bõvítés a specializáció. Egy B egyed akkor specializációja az A egyednek, ha B úgy is viselkedik, mint A, azaz A minden tulajdonsága megvan B-ben is és A elõfordulásai közé beletartoznak B elõfordulásai is. Egy autó például specializációja a jármûveknek, hiszen a jármûvek minden tulajdonsága (sebesség, tömeg, stb) megvan az autónál is, és amikor a jármûv elõfordulásokat kell felsorolni, belevesszük az autó elõfordulásokat is. A specializáció is asszimmetrikus kapcsolat, ezért ezt is egy nyíllal jelöli az EE/R modell, de most a nyíl mellé egy IS_A azonosító feliratot tesz. Az ábrán a B egyed az A egyed specializációjaként szerepel:

Mivel a specializáció megadásával azt is megadjuk, hogy A minden tulajdonsága egyben B-nek is tulajdonsága, ezért B-nél már nem tüntetjük fel az A-tól örökölt tulajdonságokat. Az elõzõ példában a B egyedet az Y tulajdonság mellet az X tulajdonság is jellemzi.

Az említett E/R alapú modellek mellett számos egyéb megközelítésû modellek is kialakultak. Ezek közül érdemes legalább a nevüket megemlíteni a funkcionális adatmodelleknek. A funkcionális adatmodell megjelölés arra utal, hogy a modellben a kapcsolatok függvényszerû formalizmussal adhatók meg. E modellek jellemzõi, hogy a fogalmakat, objektumokat nem bontják szét egyedkre és tulajdonságokra. Mindkettõ egy közös objektumként viselkedik. A kapcsolatok pedig ezen objektumok közötti leképzésnek tekinthetõ. Az autó példát véve, e megközelítés szerint, mint az autó, mint a rendszám egy-egy objektum. Azt a tényt, hogy minden autónak van egy rendszáma, a modellben egy függvénnyel adjuk meg, amely az autó objektum elemeit képzei le a rendszám objektumokra, azaz minden autó objektumhoz hozzárendel egy rendszám értéket. A többértékû tulajdonságok leképzésére e modellekben a többértékû függvényeket alkalmazzák.

Az 1970-es évek közepén kialakult funkcionális modellek egy módosított, kibõvített változtatának tekinthetõ az 1987-ben megjelentetett IFO adatmodell. E modell Abiteboul és Hull nevéhez fûzõdik. Ugyan e modell kisebb jelentõséggel bír napjaink gyakorlatában, de számos olyan eleme van, amely továbbél az újabb adatmodellekben is. Mi e modellnek csak informális, intuitív részét vesszük át, a legfontosabb modellelemek bemutatására szorítkozva.

Az IFO modell is egy grafikus jelölésrendszert alkalmaz. A problémakör leírására szolgáló, elkészített modellt sémának nevezik. Az IFO séma egy irányított gráffal reprezentálható, melyben az egyes csomópontok az objektumokat, míg az irányított élek a kapcsolatokat jelölik ki.

A objektumok ábrázolásánál háromféle objektumtipust kkülönböztet meg az IFO modell. Az elsõ csoportba tartoznak az elemi (printable) objektumok, melyek kiíratható, képernyõn megjeleníthetõ értékkel rendelkeznek. Ilyen elemi objektumnak tekinthetõ pl. a név vagy életkor, hiszen a név objektum egy sztringet, a kor objektum egy számot tartalmaz, melyek a képernyõre kiírathatók.

Az objektumok második csoportjába az absztrakt objektumok tartoznak. Az absztrakt objektumok olyan objektumokat jelölnek ki, melyek mögött nem egy elemi érték áll. Az ember, vagy autó egy ilyen absztrakt objektum, hiszen mindkettõ nem egy elemi értékkel reprezentálható, hanem a hozzá kapcsolódó egyéb értékek rendszerével.

A harmadik csoportba a származtatott objektumok tartoznak. Ezek olyan objektumok, melyek más rendszerint absztrakt objektumokból származnak specializáció utján. Az IFO modellben a származtatott objektumok fõ funkciója ugyanazon objektumnak több különbözõ szerepben való megjelenését biztosítani. Az autó-ember tulajdonosi rendszert az IFO modellben úgy ábrázolnánk, hogy az autó és ember absztrakt objektumok mellett létezik egy tulajdonos objektum is, amely az ember objektumból származtatható le. Az autó objektum e tulajdonos egyeddel állna kapcsolatban a tulajdonos viszony nyilvántartására.

A IFO formalizmusban az elemi objektumokat téglalappal, az absztrakt objektumokat rombusszal és a származtatott objektumokat ellipszissel jelölik:

A komplex értékstruktúrák ábrázolására két speciális konstruktor operátort taratlmaz az IFO modell: az aggregáció és a csoportképzés. Az aggregáció több különbözõ tiposú objektum együttesét jelenti. A keletkezett struktúra egy rekordnak feleltethetõ meg, mely több mezõt is tartalmazhat. A lakcím például az irányítószám, város, utca, házszám objektumok együtteséne, azaz aggregációjának tekinthetõ. Az aggregáció jelölésére egy körbe rajzolt + jel használható, melybõl élek mutatnak az aggregációba bevont objektumokra:

A csoportképzés ezzel szemben azt a mûveletet jelenti, amikor egy másik objektum több elõfordulását fogjuk össze. Ez a konstruktor a Pascal tömb fogalmához köthetõ. Mivel egy embernek több szakképzettsége is lehet ezért az emberhez nem egy szakképzettség elõfordulás, hanem szakképzettségek csoportja köthetõ. A csoportképzés grafikus szimbóluma a körbe írt csillag jel, melybõl él mutat a többszörözött alapobjektumra:

Az objektumok közötti asszociációs kapcsolatok ábrázolására szolgálnak az irányított nyilak, melyek jelentése és funkciója hasonló a funkcionális adatmodellnél említettel:

Az ábrán az A objektumból indul ki nyíl a B objektum felé. Ez azt jelenti, hogy minden A-beli objektumelõforduláshoz rendelhetõ B-beli objektum elõfordulás. Az E/R terminológia esetén e nyil vagy tulajdonságként, vagy egyedek közötti kapcsolatként jelenne meg. Az IFO modellben minden asszociációs kapcsolat kap egy azonosító nevet, melyet az ábrán a c betû szimbolizál.

Egy adott objektum struktúráját és asszociációs kapcsolatrendszerét leíró gráf részletet fregmentnek nevezik. A fregment elnevezés arra utal, hogy az így elõálló gráfrészlet a séma egy önálló, logikailag összekapcsolódó részletét jelenti. Az irányítottságnak köszönhetõen a fregmentek egy hierarchikus struktúrát alkotnak.

Az IFO modellbõl sem maradhatnak ki az objektumokhoz kapcsolódó specializációs operátorok. Az egyféle ISA kapcsolat helyett itt kétféle módon is megadhatók az öröklés: specializációval és általánosítással. Az specializáció egy létezõ objektumhoz különbözõ szerepköröket rendel. Ha az A objektum a B objektum specializációja, akkor B minden kapcsolata érvényes A-ra is, és a B-re való hivatkozás magába foglalja az A objektumokat is. A specializáció jele egy duppla vonalú nyíl, mely itt abba az objektumba mutat, amely általánosabb:

Az ábrán az A objektum lesz a B specializációja.

Az általánosítás azt jelenti, hogy több különbözõ objektumokból alkotunk azokat átfogó új objektumot. Így például az autó és a vonat általánosításával létrehozható egy jármû objektum. Az általánosítás, mely mintegy inverze a specializációnak, során az új objektum felfelé örökli az alap objektumok közös tulajdonságait. Az általánosítás grafikus jele egy vastagított élû nyíl az alapobjektumokból az újonnan létrehozott objektumba:

Az ábrán az A objektum jön létre az X és Y objektumok általánosításaiként.

Az IFO modell elemeinek együttes bemutatására vegyük az alábbi sémát, az IFO modellen alapuló SNAP nyelv mintapéldája alapján. Az ábrán egy utazási iroda nyilvántartási rendszerének részlete látható.

Az modellben szerepel egy személy absztrakt objektum, amelyhez egy név asszociálható, azaz minden személynek van neve a modellben. A személynek kétféle specializációját is láthatjuk, egyik a tárista, a másik az alkalmazott. A túrista annyiban gazdagabb a személynél, hogy hozzá már egy kategória objektum is kapcsolható tulajdonságként. Az alkalmazotthoz pedig nyelvek egy csoportja köthetõ, megadva hogy milyen nyelveket beszél az illetõ. Minden nyelvhez, mint elemi objektumhoz asszociálható egy szint, a beszédkészség szintje. Ezen hozzárendelés segítségével minden alkalmazotthoz megadható a beszélt nyelvek köre a hozzá tartozó készségszinttel együtt.

Az út objektumhoz három más objektum köthetõ tulajdonságként. Egyrészt az út azonosító id száma, másrészt az idegenvezetõ és a résztvevõk egy csoportja. Minden résztvevõ egyben egy túrista is, ezért a résztvevõ a tárista egy specializációjaként van feltüntetve. Mivel minden idegenvezetõ egyben alkalmazott is, ezért õ is mint az alkalmazott specializációja van megadva. Ez útóbbit úgy is mondhatnánk, hogy az alkalmazott a modellben idegenvezetõ szerepben is fellép.

Az elõzõekben ismertetett SDM modellek után áttérünk a DBMS adatmodellek tárgyalására. Mint már említettük e modellek lényeges jellemzõje, hogy létezõ DBMS rendszerek futnak mögöttük, ebbõl következõen e modellek figyelembe veszik a megvalósítás lehetõségeit, hatékonysági problémáit. A várakozásnak megfelelõen e modellek sokkal alacsonyabb absztrakciós szinten állnak, sokkal közelebb vannak a fizikai megvalósításhoz.

Különösen igaz ez a most bemutatandó hierarchikus adatmodellre. Ezt a modell a legelsõ adatmodellként tartjuk számon, mely a hatvanas évek közepén alakult ki. Ugyan még ma is futnak elvétve hierarchikus modellen alapuló alkalmazások, de jelentõsége mára már igen kicsi. Ennek megfelelõen, mi sem fogunk részletesen foglalkozni vele, inkább csak bepillantást kívánunk adni pár oldal erejéig a legelsõ DBMS adatmodell felépítésébe mûködésébe. Az igazi súlypont majd a relációs modellre fog esni, de e kis kitérõ révén talán mégjobban sikerül majd értékelni a relációs modell által nyújtott szolgáltatásokat, s sikerül jobban megérteni az adatbáziskezelés területén folyó fejlõdést is.

A hierarchikus modell a valóságban elõforduló hierarchikus szerkezetek leképzésére szolgál. A gyakorlati életben a társadalmi, vagy ipari rendszerek, de sokszor a természeti rendszerek is hierarchikus felépítést mutatnak. Egy vállalat például felbontható több üzemre, egy üzem felbontható több részlegre, s egy részleg felbontható több egységre, vagy munkacsoportra. A technológiai folyamatoknál egy gyártmány több technológiai folyamatból áll elô, s minden folyamat felbontható lépésekre.

A hierarchia olyan adatszerkezet, amikor az egyedelôfordulások egy fastruktúrát alkotnak, az egyedelôfordulások különbözô szinteken helyezkednek el, s egy egyedelôforduláshoz, mint szülôhöz több gyermekelôfordulás kapcsolódik, ahol a gyerekek a szülô alatt helyezkednek el. A fa élei a szülôket és a gyerekeket kötik össze. A fában egy szülônek több gyereke is lehet, de egy gyereknek csak egy szülôje lehet.

A hierarchikus modell egyik jellegzetessége, hogy nincs elméleti indíttatása. Ez a modell a különbözô és egymástól viszonylag független gyakorlati alkalmazások során fejlôdött ki fokozatosan. Elterjedését a sikeres és úttörô szerepû alkalmazások mint pl. IMS, segítették elô. A gyakorlatiasabb szemléletmódja egyszerûbb kezelô felülettel párosul, de egyszerûsége késôbb hátrányát növelte, ugyanis nem tudott a megnövekedett igényekhez alkalmazkodni, s így végképp kiszorult a DBMS piacán folytatott versenybôl.

A hierarchikus modellben az adatokat hierarchikus fákban tárolják. A modell két alapelembôl építhetô fel:

A PCR angolul a szülô-gyerek kapcsolatot (Parent Child Relation) jelent. Egy PCR séma egy szülõ rekord típusból és egy gyerek rekord típusból áll. Egy szülô egyedelôforduláshoz több gyermek egyedelôfordulás is tartozhat, pl. egy embernek több autója is lehet. Ezért a szülô és a gyermek egyedtípusok között 1:N típusú kapcsolat áll fenn.

A hierarchikus modellben tehát a hagyományos programozási nyelvekhez hasonlóan az adatok rekordokba rendezve helyezkednek el. Így minden adathoz léeteznie kell õt tároló rekordtipusnak, amelyben õ mint mezõ szerepel. A rekordon belül az egyes mezõk csak elemi értéket tárolhatnak. Tehát a hierarchikus modell nem alkalmas közvetlenül a többértékû vagy összetett tulajdonságok, az aggregációk és csoportképzés megvalósítására.

A másik építõ elem a PCR kapcsolat. A hierarchia felépítéséhez fel kell tárni a rekordtipusok közötti kapcsolatokat. A hierarchikus modell egyedül az 1:N kapcsolattipust tudja megvalósítani, ezért a többi kapcsolattipusnál a tervezõ hárul a feladat, hogy valamilyen formában bele tudja préselni az elképzelését a hierrachikus séma adta keretekbe.

A modellbõl ennek megfelelõen minden specializációs vagy általánosítási kapcsolatot leíró eszközrendszer is hiányzik. Ez nem is csoda, hiszen, amikor e modellt kidolgozták, még nem született meg az objektumorientáltság hatékony szemlélete.

A hierarchikus modell tehát igen szerény eszköztárat bocsát rendelkezésre a valóság leírására. Ami a szemantikai kifejezõerõt gyöngítette, az hatékonyságot viszont fokozta. A modell alkalmas volt az akkori korlátozotabb hardware lehetõségek mellett is a megfelelõ adatkezelési gyorsaság biztosítására. A gyakorlati alkalmazhatóság igénye viszont elsõdleges szempont a DBMS modellek megitélésénél.

Visszatérve a hierarchia struktúrához, elmondható, hogy az egyes egyedtípusok közötti kapcsolatok több szinten keresztül is lenyúlhatnak, tehát egy gyermekegyed szerepelhet szülôegyedként egy harmadik egyedre vonatkozó relációban. Így több egymásba kapcsolódó PCR sémát kapunk. Egy közös gyökér PCR sémából kiinduló hierarchiát neveznek hierarchia sémának. A hierarchia séma tehát a rekordtípusok és PCR típusok együttese. A hierarchia séma szemléletesen egy fával reprezentálható.

Mivel a modellezett világ sokszor bonyolultabb annál, hogy egyetlen hierarchikus fával le tudnánk írni, ezért megengedett, hogy több fát is használjunk. A hierarchikus adatbázis séma több hierarchia séma összességébôl áll elô. A vállalat példánál maradva, külön hierarchikus sémát készíthetünk a technológiai folyamatokra, a szervezeti felépítésre, a raktározásra, számlázásra.

A modell szemléletesebb leírására rendelkezésre áll egy grafikus jelölés rendszer, a hierarchikus diagramm. A diagrammal ábrázolhatjuk a fák szerkezetét, ez lesz a séma diagramm, illetve az egyes fa elôfordulásokat is, melyet elôfordulási diagrammnak neveznek.

A hierarchikus diagrammok az egyedeket és a tulajdonságaikat nem elkülönülten ábrázolják, mint ahogy azt az ER modellben megszoktuk, hiszen ott külön grafikai szimbólum volt az egyed és a tulajdonság jelzésére. Ebben a leírásban egyetlen egy téglalap foglalja össze az egyed azonosítóját, és tulajdonságainak összességét. A következõ ábra egy vállalati struktúrát mutat be.

A megadott példában az ügyosztály egyedtípus helyezkedik el a hierarchia gyökerében, s alatta vannak az alkalmazottak és a projektek. Ez az alárendeltség azt jelenti, hogy egy ügyosztályhoz több alkalamzott és több projekt is kapcsolódhat. Az sémából az is kiolvasható, hogy az ügyosztályt egy id azonosító, egy megnevezés és egy cím adat ír le. A másik két rekordtipus szerkezete is megállapítható az ábra alapján.

Az ábrában egyes mezõk nevei aláhúzottan jelennek. E kiemelés mutatja, hogy az adott mezõ kulcsszerepet tölt be a többi mezõ között. A kulcsmezõ, hasonlóan a kulcs tulajdonsághoz, arra szolgál, hogy értékével egyértelmûen kijelölje a rekordelõfordulást.

A hierarchia sémák szerkezetét összefoglalhatjuk néhány pontban, melyek a hierarchia séma egy-egy jellemzõ oldalát emelik ki:

A fenti formálisabb leírás lehetôséget ad a szerkezet automatizált ellenôrzésére. A megkötések, mint szerkezeti integritási feltételek is értelmezhetôk, a szerkezet felépítése során mindvégig érvényben kell maradniuk.

A hierarchikus modell fô elônye, az egyszerûség nemcsak a modellezésben, a koncepcionális szinten jelentkezik, hanem a fizikai, belsô szinten is. A hierarchikus sémához tartozó elõfordulási fákat ugyanis egyszerû eszközökkel és egyszerû struktúrákban is könnyen tárolhatjuk. Mindez különösen akkor volt fontos, amikor még nem álltak rendelkezésre a gyorsabb közvetlen direkt szervezést megvalósító lemeztárolók, s csak a szalagos adattárolással együttjáró kötöttségekhez kellett alkalmazkodni. A hierarchikus elôfordulási fa a szekvenciális szervezésben is hatékonyan letárolható, az elõfordulási fa ugyanis linearizálható. A fák bejárására több különbözô módszerek léteznek, s mindegyik bejárás végül is linearizálja a fát, minden csomóponthoz egy bejárási sorszámot rendelve, mely sorszám megfeleltethetô a csomópont szalagon elfoglalt pozíciójának. A fa pl. bejárható az elsõként baloldal utána jobboldal elven, amikor egy adott részfánál elôbb a gyökér, majd a gyermekek részfái következnek balról jobbra haladva. Ennél a bejárásnál egy csomópont

leszármazottai mind az elem után helyezkednek el. A kiíratás megvalósítható

pl. az alábbi algoritmussal:

kiir(cs) {

output (cs);

for (i=1; i<cs.gyerekszam; i++) {

kiir(cs.gyerek[i]);

}

}

A visszaolvasásnál az eredeti elôfordulási fa egyértelmû helyreállítást úgy érik el, hogy minden rekordtípushoz rendelnek egy típusjelzést és ezt is letároljuk az állományban. Ezáltal követni tudjuk, hogy a hierarchia mely szintjén járunk, s megtudjuk határozni a testvéreket is. A típusjelzésnek azonban elegendô csak a fizika nézetben szerepelnie, s nem kell külön típusjelzô tulajdonságot hozzáfûzni az egyes egyedtípusokhoz a koncepcionális modellen belül. Ez egyben jó példának tekinthetô az egyes nézetek tartalmi különbségének szemléltetésérte is.

Ugyan a linearizálás, a szekvenciális tárolási mód egyszerû, és hatékony a teljes hierarchia visszaállításánál, de ez a hatékonyság eltûnik, ha a mûveleteknek csak egy részfát kell visszaadniuk, illetve ha a fa olyan nagy hogy nem fér be a memóriába, s sokszor a fa különbözô szeleteiért visszanyúlni a szalaghoz. A hierarchia másik hátránya, hogy alapvetôen csak egyféle keresési irányt támogat, a fentrõl lefelé irányt. Egy adott elem ôseinek, elérési útvonalának a meghatározásához az egész fát át kell olvasni, ha csak az adott elem pozíciója ismert. E visszafelé keresés megkönnyítésére bizonyos módosításokat, bôvítéseket kell végrehajtani az alapmodellen. Ennek egyik változata lehet, hogy pointereket építünk be az egyedelôfordulásokba, melyek a szülô felé mutatnak. Mindez már mutatja, hogy a hierarchikus modellnek vannak bizony hiányosságai.

Az elôbb említett hatékonysági problémák mellett az más modellezési nehézségek is fellépnek a hierarchikus modell használatakor, mint pl az:

A felvázolt hierarchikus modell ugyan jól simul a valóságban elôforduló hierarchikus szerkezetekhez, de a hierarchikus szerkezetek mellett gyakran találkozhatunk ettôl bonyolultabb rendszerekkel is, melyek már nem simulnak a hierarchikus fa felépítéshez. Gondoljunk csak a színészek és színdarabok kapcsolatára, ha ezt mondjuk egy évadra vonatkozóan vizsgáljuk. Egy színész több színdarabban is játszhat, s egy színdarabban több színész is szerepelhet. Ez már nem egy hierarchikus kapcsolat. Hogyan lehet tehát a nem 1:M kapcsolatokat, az N:M típusú relációt megvalósítani ?

Az elmondottakból következik, hogy közvetlen reprezentáció nem lehetséges. Egy kerülôutat jelent, ha feloldjuk azt a megkötést, hogy egy gyermekelôfordulásnak csak egy szülôelôfordulása lehet. Pontosabban feltesszük, hogy egy gyermekelôfordulás többször is szerepelhet egy PCR kapcsolatban. A séma tehát egy 1:N kapcsolatot sugallna, s csak az elôfordulási fa mutatná, hogy itt valójában N:M kapcsolatról van szó.

A vázolt problémák tehát rekord elõfordulás duplikálással megoldható . A rekord duplikálás viszont számos újabb problémát hoz magával. Ezek között az egyik legszignifikánsabb a redundancia kérdése. A felesleges redundancia ugyanis felesleges helyfoglalást okoz, nehezebb az adatkezelés, hiszen gondoskodni kell a módosítások konzisztens, minden példányon történô végrehajtásáról.

A nehézségek elkerülésére egy új koncepciót vezettek be a HDBMS-eknél, mellyel elkerülhetôk a felesleges redundanciák, mégis látszólag megmarad a többszörös rekordelôfordulás.

A kapcsolatok tárolására a közvetlen fizika elhelyezkedés helyett bevezetjük a pointer használatát, s a pointer segítségével kötjük össze a gyereket a szülõvel. Tehát nem kell a rekordot még egyszer elhelyezni a szülô mögé, hogy jelezzük a kapcsolatot, azaz nem fogjuk fizikailag megsokszorozni az egyedelôfordulást. A kapcsolatot egy pointer jelzi, melynek technikai okok miatt a gyerekbôl kell kiindulni a szülô felé. A szülôbôl ugyanis meghatározatlan számú pointer indulhatna ki a gyerekek felé, míg a gyerekbôl csak egy pointer indul ki. S egy rögzített méretû struktúrát egyszerûbb implementálni, mint egy dinamikusat, fôleg a régi, hagyományos programozási környezetben.

A pointerek átmutathatnak más hierarchia elõfordulási fában elhelyezkedô rekordokra is. A pointerek tehát összeköthetik az egyes elôfordulási fákat. Azon rekord típusokat, melyek ilyen pointert tartalmaznak, virtuális rekord típusnak nevezik (VR). A pointerek révén megvalósított PCR-t nevezik virtuális gyerek-szülõ-kapcsolatuk (VPCR). A VPCR is egy 1:N kapcsolatot valósít meg, de nem fizikai pozícionálással, hanem a pointerek felhasználásával.

Az ábrában a B és a C rekordtipusok fizikailag, pozició alapján kapcsolódnak az A rekordtipushoz, mint ahogy az E is kapcsolódik a D-hez. A C tipus azonban pointeren keresztül, VPCR révénkapcsolódik a másik fa gyökerhez a D rekordtipushoz. Ekkor mind A és mind D egy-egy elõfordulásához a C elõfordulások egy halmaza köthetõ.

Nézzük, hogyan alkalmazhatók a VPCR-ek az N:M típusú kapcsolatok letárolására. Ekkor a VCR, virtuális gyerek rekord, gyerekegyed szerepét tölti be. A kapcsolathoz tehát két hierarchia séma kellett, melyek gyökérben a két kapcsolódó egyedtípus áll. A fenti séma megvalósulásakor egy A elõforduláshoz több VCR elõfordulás is csatlakozik, s mindegyik egy B elõfordulásra mutat.

Az elõfordulás alapján egy B elõfordulásra több VCR rekordelõfordulás is mutathat. Az N:M kapcsolat tárolására tehát létre kellett hozni egy virtuális egyedtípust, egy kapcsoló egyedtípust, mely egyrészt fizikailag kapcsolódott az egyikegyedhez, míg másrészt pointeren keresztül kapcsolódott a másik egyedhez, tehát mindkettônek a gyereke egyidejûleg. Az egyiknek fizikai gyereke, a másiknak virtuális gyereke.

A VPCR szerkezettel megszûntethetõk a fajlagos redundanciák, viszont az eddigi pozíciókban leképzett kapcsolat mellett új kapcsolat-nyilvántartás módszer jelent meg. Ebben VCR egy segédszerepet tölt be, jelentése nem egy önálló objektum kapcsolható, hanem a kapcsolathoz magához. Ha e kapcsolatnak vannak egyedi tulajdonságai is ( pl. a szerep szerepelhet a színész és színdarab vonatkozásban ilyen, a kapcsolatra magára jellemzô tulajdonságként), akkor ezen adatok a VCR-hez kapcsolható, a pointerekkel együtt tárolhatók. Ezen adatokat nevezik intersection adatoknak.

Az elõzõ ábrán két hierarchia fát láthatunk. Az egyik a szervezeti egységekre, a másik a projektekre vonatkozik. Az adatbázis sémában a következô kapcsolatok tárolódnak:

A kapcsolatokból a projekt:dolgozó egy N:M típusú kapcsolat, a többi 1:M típusú kapcsolatként értelmezett. A projekt:dolgozó kapcsolat egy segéd rekordtipus alkalmazásával oldható meg, amely fizikailag a dolgozó alatt van, de logikailag, pointerekkel a projekthez is kapcsolódik.

A hierarchikus modellhez számos integráció feltétel kapcsolódik, melyeket eleve beépítettek a modellbe. Az elôzôekben már felsoroltuk ezen integritási feltételeket. Ezeket nem a felhasználónak kell definiálnia, eleve be vannak építve a hierarchikus modellbe. A hierarchikus modellek viszont nem támogatják új egyedi integritási feltételek definiálását , tehát csak a beépített integritási feltételek kapcsolódnak az adatbázishoz. Ha az alkalmazás ezenfelüli, egyedre vagy kapcsolatra szóló integritási feltételt tartalmaz, hogy pl. egy színész maximum 5 színdarabban játszat, akkor minden ilyen jellegû egyedi megkötést a kezelõ programban kell megvalósítani, s nem lehet az adatmodellben letárolni. Ahány alkalmazói program érinti ezt a megkötést, annyi helyen kell ügyelni a betartására. A legfontosabb beépített integritási feltételek a következôkben foglalhatók össze:

A következõkben az adatmodell jobb megértésére egy minta kezdõ nyelvet mutatunk be, mely nem egy konkrét HDBMS nyelve, ez egy példanyelv, mely a létezõ HDBMS nyelvek leglényegesebb elemeit emelik ki. A nyelv egy beágyazott használatra épül.

Adatdefiníciós utasítás (HDDL)

A HDDL rövidítés a hierarchikus adat definiáló nyelv (hierarchical data definition language) rövidítése. A DDL nyelvek célja az adatbázisban tárolandó struktúrák leírása. A DDL nyelv segítségével lehet az adatbázisban létrehozni az adatstruktúrákat. A DDL emellett a létezõ struktúra elemek módosítására és megszüntetésére is tartalmaz utasításokat. A hierarchikus modell definiálandó elemei a következôk:

A nyelvet egy példán keresztül mutatjuk be. A példában egy minta grafikus sémához készítjük el a DDL utasítássorozatot. A mintapélda egy vállalati struktúra részletét mutatja:

A séma megadásához elõbb a keret, a sémát kell léátrehozni:

Eztkövetõen ki kell jelölni, milyen hierarchi-fákat fog tartalmazni a séma, megadva az egyes hierarchiák azonosító nevét is:

A hierarchiák kijelölése után következhet a hierarchiák részletes szerkezetének leírása. Ehhez ki kell jelölni a hierarchában elõforduló rekordtipusokat, s definiálni kell az egyes rekordtipusok szerkezetét is. A rekordtipusok struktúrájának és az egymáshoz való kapcsolódásuknak a leírása egyazon nyelvi szerkezetben, a rekordot definiáló részben történik. A rekord definiálásakor ugyanis nemcsak a hozzá tartozó mezõket, hanem a szülõrekordtipust is meg kell adni. A hierarchia csúcsán álló rekordtipusoknál a szülõ helyett a hozzá tartozó hierarchiát adjuk meg. A soronközvetkezõ uatsításokban rendre az alkalmazott, osztály, projekt és a segédrekord szerepét betöltõ osztalkal rekordtipusok definícióját láthatjuk.

Ezzel teljes egészében ismerté vált a DBMS számára is a létrehozandó struktúra.

Összefoglalva, a HDDL nyelvben a következõ kulcsszavak fordultak elõ az alábbi jelentést hordozva:

A fenti utasításkészlet elegendô egy egyszerû hierarchikus adatbázismodell megadására. A minta is érzékelteti a modell viszonylag merev szerkezetét. Szembetûnhet például, hogy az adatbázis megadásánál rögtön fel kell sorolnunk az oda tartozó hierarchiákat, tehát elôre ismernünk kell az adatbázis szerkezetét. Egy rugalmasabb modelltôl elvárnánk, hogy széttagoltan, izoláltan lehessen definiálni a hierarchiasémákat.

Az utasítások másik nagy csoportja az adatkezdõ utasítások ( HDML ) köre. A HDML a hierarchikus adatkezelõ nyelv (hierarchical data manipulation language) rövidítése. A DML nyelv azon utasításokat fogja össze, melyek az adatbázisban letárolt adatok lekérdezését, módosítását, bõvítését és kitörését teszik lehetõvé.

A hierarchikus modellek a rekordorientált mûveleteket támogatják, ezért a kezelô nyelve is a rekordonkénti feldolgozásra épül. Mivel a mûveletek rekordszinten hajtódnak végre, a feldolgozásnál lényeges szerepet játszik, hogy hol tart a feldolgozás, mi lesz a következõ feldolgozási rekord. Ezért a rendszer nyilván tartja az aktuálási rekord pozíciót. Mivel a modellben a hierarchikus sémák és a rekordtípusok is viszonylag önálló szerepet töltenek ezért a következõ szinteken végzik a kurrens rekord nyilvántartását az adatbázison belül:

A HDML parancsok jellegének szemléltetésére a következõ parancsokat emeljük ki:

Az egyes parancsok részletesebb szintaktikája megmutatja a mûveletek jellegét, mûködési elveit is.

A fenti mûveleteket értelmezéséhez figyelembe kell venni, hogy a DML és a DDL utasítások egy gazdanyelve beágyazva használhatók. A gazdanyelv és az adatbázis adatkapcsolata a program munkaterületén keresztül valósul meg. A programban olyan rekordváltozókat kell definiálni, melyek azonosító nevei megegyeznek az egyedtípusok neveivel. Ez a programváltozó mindig a kurrens adatbázis rekord értékét tartalmazza minden egyedtípusnál. Így egy GET után ebben a változóban találhatjuk meg az adatbázisrekord értékét is. A beszúrásnál és módosításnál az új értékeket egy másik, de ugyanilyen szerkezetû programrekordból veszi a rendszer. Az utasítások, mint látható rekordorientáltak, s ennek szemléltetésére álljon itt egy példa az összes 10000 Ft-ot keresô alkalmazotti egyedelôfordulás kiíratására:

A példában a C nyelvet választottuk gazdanyelvként. A HDBMS kulcsszó jelzi, hogy az adott sor egy DDL vagy DML utasítást tartalmaz (laza csatolás). A DBMS és az alkalmazás közötti kapcsolat egyik lényeges, eddig nem említett elemét is megfigyelhetjük itt. Lényeges ugyanis, hogy az alkalmazás értesüljön a kiadott utasítások végrehajtásának sikerességérôl, hiszen ennek függvényében adódnak a következô lépések. A hibakezelés egy foglalt változón, a DB_STATUS-on keresztül valósul meg, értéke jelzi, hogy sikeres volt a végrehajtás vagy sem. A rekordorientáltság miatt a teljes elôforduláshalmazra vonatkozó utasításokat ciklus szervezéssel oldhattuk meg.

Mint korábban említettük, az adatbázisok tervezésébek általános menete alapján az adatmodellt elõbb SDM, majd DBMS adatmodellben fogalmazzuk meg, s az adatbázis fizikai létrehozásához ez utóbbi alapján létrehozzuk a megfelelõ DDL utasításokat, melyeket a DBMS már megért és végre is hajt. A ma használt SDM modellek között az E/R modellnek van a legnagyobb jelentõsége, azért erre vonatkozólag követjük nyomon az átalakítás lépéseit, feltételezve egy E/R SDM modellt és a hierarchikus DBSM modellt.

A két modell struktúrális elemeit összevetve, bizonyos párhuzamot lehet vonni a két modell között, mely alapján felállítható egy általános konverziós szabály. Mindkét modellben fellelhetõ egy olyan struktúra elem, amely az elemi értékek együttesét jelenti. Az E/R modellben az egyed, míg a hierarchikus modellben a rekord jelenti ezt a szerkezti elemet. Ez alapján fõ konverziós irányelvként e két egység egymásnak való megfeleltetését lehet megadni.

Maga az átalakítást nehezíti, hogy a tulajdonságok viszont nem minden esetben feleltethetõk meg mezõnek. Ennek oka, hogy a hierarchikus modell csak az elemi értékû mezõket támogatja. Ezért az összetett vagy többértékû mezõket csak közvetve, nem egyszerû mezõként lehet tárolni. Az összetett mezõ esetén megoldás lehet, ha az összetett mezõ helyett rögtön a komponenseit adjuk meg mezõknek. A többértékû mezõk esetén a megoldás az, hogy a tulajdonságot egy új rekordként tároljuk, amely PCR révén kapcsolódik az E/R modellbeli egyedhez tartozó rekordhoz.

A kapcsolatok átalakítása sem problémamentes. Az 1:N kapcsolatokat ugyan közvetlenül lehet ábrázolni PCR és VPCR segítségével, de az 1:1 és N:M kapcsolatok esetén már kerülõutakra van szükség. Az 1:1 tipusú kapcsolatokat ábrázolásánál az ad segítséget, hogy az 1:1 kapcsolat tulajdonképpen egy speciális 1:N kapcsolatként is felfogható. Így ábrázolása PCR vagy VPCR segítségével történik. Az N:M kapcsolat esetén, mint már korábban említettük, egy segédrekord bevezetése ad megoldást, amely célja a kapcsolat reprezentálása. E segédrekord minden elõfordulása egy kapcsolat elõfordulást reprezentál. A segédrekord PCR útján kapcsolódik az egyik rekordhoz mint szülõhöz és VPCR útján a másik rekordhoz, mint másik szülõhöz.

A konverzió menetének durva szabályait a következõkben foglalhatjuk össze:

Az átalakítás szemléltetésére vegyünk egy egyszerû példát. Az E/R séma legyen egy video kölcsönzõ modellje.

A modellben a téma többértékûnek lett feltüntetve és a kölcsönzésnél az eddigi valamennyi kölcsönzést nyilvántratjuk, ezért lesz a kapcsolat N:M kellegû. A megfelelõ hierarchikus sémát a következõ ábra mutatja be.

A sémában két külön fa létezik, a két fõ egyedre vonatkozólag. A téma rekord a többértékûseg, míg a kölcsönözte rekord az N:M kapcsolat miatt került be a rendszerbe.