Informatika | Adatbázisok » Kovács Nándor - Az adatbázis-tervezés alapfogalmai

Kovács Nándor AZ ADATBÁZISTERVEZÉS ALAPFOGALMAI ÉS ALAPJAI Jegyzet az adatbázis-kezelés tantárgyhoz Gimnázium, Mûszaki Szakközépiskola és kollégiuma Újszász 1997 Tartalomjegyzék Az adat és információ.3 Az adatbázis .5 ÁLLOMÁNY, ADATBANK, ADATBÁZIS .5 EGYED, -ELÕFORDULÁS, -ELÕFORDULÁSHALMAZ .5 TULAJDONSÁG, -ÉRTÉK, -ÉRTÉKHALMAZ .6 AZ EGYED ÉS A TULAJDONSÁG RELATIVITÁSA.6 AZ AZONOSÍTÁS PROBLÉMÁJA.6 KAPCSOLAT, -ELÕFORDULÁS, -HALMAZ.7 AZ ADATBÁZIS.8 NÉHÁNY FONTOS MEGJEGYZÉS .9 Az adatbázis három szintje . 10 A TERVEZÕI VAKSÁG.10 AZ ADATBÁZIS FOGALMI ÉS LOGIKAI SZERKEZETE .10 AZ ADATBÁZIS FIZIKAI SZERKEZETE .11 A FIZIKAI ADATSZERKEZET ELNEVEZÉSEI .12 ÖSSZEFOGLALÁS .13 AZ ADATMODELL-DIAGRAM .13 Alapvetõ szerkezetek. 15 AZ ADATMODELL HÁROM TÉNYEZÕJE .15 A TULAJDONSÁGOK SZEREPEI .15 HIERARCHIKUS INHOMOGÉN VAGY EGY-TÖBB KAPCSOLATOK .16 HÁLÓS VAGY TÖBB-TÖBB EGYEDVISZONYOK.18 A KÖLCSÖNÖS VAGY 1:1 VISZONY .19 HOMOGÉN

SZERKEZETEK.20 A visszamutató egyedviszony (beosztottak, fõnökök) . 20 A családfa- és házastárs-viszony. 21 A házastárs-viszony. 22 ADATBÁZISKEZELÉS.23 AZ ADATBÁZIS LÉNYEGE.24 Az adatbázis-tervezés problémái . 25 AZ ADATBÁZIS-MENEDZSELÉS .25 Hány az adatbázis?. 25 Az alkalmazási adatszabványok. 26 Fejlesztési adatszabványok. 26 Fejlesztési eljárásszabványok . 27 Menedzselési szabványok. 28 Szervezeti feltételek . 28 AZ ADATBÁZIS-TERVEZÉS FÕBB LÉPÉSEI .29 Általános problémák . 29 A tervezés fõbb lépései . 29 TIPIKUS ADATMODELL HIBÁK .30 Nyílt logikai átfedés . 30 Látszólagos logikai átfedés. 31 Rejtett logikai átfedés . 31 A logikai átfedés hiánya . 31 Fizikai átfedés. 31 Ízelítõ az SQL nyelvbõl . 33 Egy példa az ACCESS adatbázis-kezelõvel. 34 ALAPFOGALMAK .34 Hivatkozási integritás. 34 Kaszkádolt törlés és frissítés . 35 Illesztések . 35 GYAKORLATI PÉLDA ADATBÁZIS TERVRE.36 Az egyedek kiválasztása. 36

Kapcsolatok . 37 Az egyedek tulajdonságértékei (mezõk). 38 Felhasznált és ajánlott irodalom . 39 -2- Az adat és információ Ha a világ dolgairól ismereteket szerzünk annak több momentuma van: Észlelés (Az ismereteket mindig valamilyen anyagi közeg hordozza ekkor pusztán ennek megjelenését észleljük, függetlenül attól, hogy mi annak az értelme.) Érzékelés (Az ismeret mindig valamilyen formát ölt. Ezt érzékeljük Ennek feltétele, hogy ez a dolog olyan legyen, amit az ember képes érzékelni.) Felfogás (A tényeket felfoghatóan, mindenki által ismert jelekkel kell közölni. Különben a benne lévõ ismeret rejtve marad a befogadó elõl.) Megértés (Ez az a momentum, amikor a felfogott ismeret értelmet ölt abban, akihez eljut. Mindez akkor teljesülhet, ha a közlés, ízléses és megfelel az adott nyelv szabályainak.) Ha leírjunk egy szót: „Józsi”, akkor azt észleljük, érzékeljük, felfogjuk és megértjük. Aki olvassa,

egybõl azt gondolja hogy ez egy keresztnév annak ellenére, hogy mi, akik ezt leírtuk semmi ilyet nem állítottunk. Az történt, hogy az ismeretet fogadó a jelsor láttán elvégzett egy gondolkodási mûveletet. Az ismeretet kapjuk, annak értelme bennünk születik aszerint, hogyan értelmezzük. Rendelkeznünk kell annak a kultúrának a mûveltségével, ami szerint ennek van valamilyen jelentése. Jelen esetben tudnunk kell azt, hogy az embereknek neve szokott lenni, a Józsi fiú név, és a legtöbb esetben ezt keresztnévként használják. E háttértudás birtokában voltunk képesek felfogni ezt a szöveget. Egy ismeret létezése és annak értelmezése két különbözõ dolog. Eszerint beszélünk adatról és információról Az adat értelmezhetõ (észlelhetõ, érzékelhetõ, felfogható és megérthetõ) ismeret. (Halassy 1994, 8) Az információ új ismeretté értelmezett adat. (Halassy 1994, 9) Az információ nem azonos az adattal, hanem annak valamilyen

jelentése. A dolog azért nem egy egyszerû, mert mindennek legalább annyi jelentése van, ahányan azt értelmezik. Az adat személytelen, objektív ismeret. Az információ mindig személyes, az adatot fogadó belsõ énjéhez, szubjektumához kötõdõ lényeg. Azért fontos látnunk ezen dolgok természetét, mert ha egy gondolatot célba akarunk juttatni, nem mindegy, milyen formába önjük. Következzen most egy igen szellemes idézet, ami nagyszerûen megvilágítja az emberi kommunikáció tökéletlenségét és alapproblémáit: „Ha Jancsi és Lajos beszélget, akkor a diskurzusnak valójában hat résztvevõje van. Jancsi, ahogyan õ magát látja. Jancsi, ahogyan õt Lajos látja Jancsi, amilyen valóságban Lajosra ugyanez a három szemlélet vonatkozik. A kommunikáció emiatt a többszörösség miatt veszik el. Jancsi valamit mond, amin Lajos teljesen mást ért Sõt, két dolgot ért Mert más az, amit Lajos úgy fog fel, mint a valódi Lajos és más az, amit

Lajos úgy ért meg, mint ahogyan magát elképzeli. Persze mielõtt Lajos bármit is hallana, Jancsi ugyanilyen zavarban van saját magával A feleség a férjének esik, miközben nem is vele, hanem valami egészen mással van baja. A disputa végén már egyikük sem érti, hogy egyáltalán mirõl is volt szó. A drága nej kijelent valamit úgy, hogy ahogyan az saját magából fakad. Nem figyel arra, hogy közben mindez a férjére teljesen másként hat, mert ura máshonnan szemléli õt, mint õ saját magát. a hölgy azt sem veszi észre, hogy valójában nem azt mondja, amire gondol, mivel nem ismeri önmagát és kifejezési eszközei is szûkösek. Hasonló a helyzet a gyerekekkel. A szülõ beképzeli magának, hogy azt teszi, ami a kölyöknek jó. A picur mindezt másként látja: számára az õs arra való, hogy kiszolgálja az õ idényeit Ha két emberi lény nem tud kommunikálni, akkor vajon mi a helyzet a szervezetek, a csoportok és az egész társadalom

szintjén ? -3- Az emberiség még nem jutott el arra a fokra, hogy megoldja az üzenetek kódolásának, küldésének, fogadásának és dekódolásának elsõdleges problémáját.” (Ismeretlen szerzõ 1920 körül) Ezek a gondolatok ma is érvényesek, hiszen hozzátartoznak a kommunikáció természetéhez. (Arról van szó, hogy az ember tudatos gondolkodási szintje teljesen egyedi és zárt. A kultúra lényegében nem más, mint egyfajta kísérlet arra, hogy valamilyen közös nyelvet találjanak az emberek egymás megszólításához, egyszerûbben fogalmazva képesek legyenek valami dolog közös szemlélése láttán körülbelül ugyanarra gondolni. Nem azt állítjuk azonban hogy ez a zártság baj, sõt ettõl válik mindenki egyéniséggé, és csak így születhetnek új felfedezések, értékek. Csupán az ebbõl a helyzetbõl származó nehézségekre kívánjuk felhívni a figyelmet azért, hogy minél jobb megoldások születhessenek. Egy felismert

probléma, már hordozza annak megoldását. Egy elodázott probléma megakadályozza annak megoldását) Nem lehet jó informatikus abból, aki az adatokra öncélúan, mint a számítógépben tárolt adatokra gondol és nem törõdik azzal, miként lesz abból mások által fogadható üzenet. A kommunikáció nehéz dolog. Az emberek nagytöbbsége összetéveszti a kommunikációt az informálással. Akkor kommunikálunk, ha odafigyelünk egymásra azzal az igyekezettel, hogy a másik megérthesse amit mondani akarunk. Informálunk akkor, ha egyáltalán nem törõdünk azzal, hogy a másik ezt fel tudja-e fogni, vagy sem. Ma igen kevés ember képes a kommunikációra és képtelen elmondani azt, hogy mit is akar tulajdonképpen. Az adatbázis-kezelés arra tesz kísérletet, hogy tényeket rögzítõ adatokat tárol adatbázisokban, és megpróbálja azokat onnan olyan formában elõszedni, hogy abból embertársaink információhoz juthassanak. -4- Az adatbázis Ebben a

részben megpróbáljuk tisztázni mit is értünk adatbázis alatt, illetve megvilágítjuk az ezzel kapcsolatos fogalmak jelentését. ÁLLOMÁNY, ADATBANK, ADATBÁZIS Az ismeretkezelés fajtái: Az egyik lehetõség az, ha olyan módon kezeljük adatainkat, hogy azokat különbözõ állományokban tároljuk és a köztük lévõ kapcsolatot valamilyen program segítségével hozzuk létre. Ezeket állománykezelõknek nevezzük Ilyenek a Dbase-, Clipper-szerû rendszerek Az ismeretkezelés másik módja, ha adatainkat szöveges módon tároljuk, szöveges állományokat hozunk létre. Ez az ismeretek szöveg- és nem adatszerû megfogalmazása Ezeket az eszközöket szövegkezelõknek nevezzük. Magát az ilyen rendszert adatbankoknak hívjuk Az ismeretkezelés harmadik módja az adatbázis-kezelés. Ennek pontos megfogalmazása és kifejtése e fejezet végén található. EGYED, -ELÕFORDULÁS, -ELÕFORDULÁSHALMAZ A cél az, hogy a dolgokat a rájuk jellemzõ ismeretek

alapján leírjuk. Ezt úgy tesszük, hogy kigondoljuk mi minden jellemzõ arra a dologra és ezeket rögzítjük. Még mielõtt belemennénk ennek részleteibe, fontos, hogy megismerkedjünk néhány alapfogalommal. Azt a dolgot-izét-valamit, amit ismeretekkel akarunk leírni, egyednek nevezzük (Halassy 1994, 26) Nézzünk egy állítást: Józsi Szolnok megyébõl jött. Józsi egy diák és õróla mondunk valamit De hasonlóképpen Ferirõl is megtudhatjuk ugyanezt a Feri Pest megyébõl jött. állításból Itt két dolog keveredik. Egyrészt az, hogy konkrét személyekrõl van szó, másrészt viszont az, hogy az elõbb említett két személy diák, tehát ezért õket mint konkrét dolgokat egy elvont, úgynevezett absztrakt osztályba sorolhatjuk, nevezetesen mindketten diákok. Így tehát azt is mondhatjuk, hogy õk a Diákok-nak nevezett egyed tagjai. A konkrét egyedeket egyed-elõfordulásoknak hívjuk. Egy egyed minden idõpillanatban az elõfordulások adott

halmazával az elõforduláshalmazzal rendelkezik Józsi a Diákok egyedben egy egyed-elõfordulás (mivel egy konkrét egyed), a Diákok egyedben felsorolt összes diákok halmaza pedig a Diákok egyed elõforduláshalmaza. -5- TULAJDONSÁG, -ÉRTÉK, -ÉRTÉKHALMAZ Abban az állításban, hogy: Józsi Szolnokon lakik. Józsiról tudunk meg valamit, tehát leírjuk vele. Azt a dolgot-izét-valamit, amivel leírjuk a bennünket érdeklõ jelenséget, tulajdonságnak nevezzük. (Halassy 1994, 28) Az elõzõ állításban szereplõ Szolnokon szó egy város. És azt mondjuk, hogy a Diákok egyed leírásához használjuk a Lakhely tulajdonságot, ugyanis minden diákunkról szeretnénk megtudni, hogy hol lakik. A Lakhely egy tulajdonság, a Szolnok, pedig ennek a tulajdonságnak egy elõfodulása. Az egyik diákhoz tartozó várost a Lakhely tulajdonság tulajdonság-értéknek (vagy -elõfordulásnak), az összes diáknál felsorolt városokat pedig a Lakhely tulajdonság

tulajdonság-értékhalmazának (vagy -elõforduláshalmazának) nevezzük. Általánosan meghatározva: Egy tulajdonság konkrét értékét tulajdonság-értéknek, és egy tulajdonság egy adott idõpillanatban elõforduló összes értékét tulajdonság-értékhalmaznak nevezzük. AZ EGYED ÉS A TULAJDONSÁG RELATIVITÁSA Az egyed és a tulajdonság relatív fogalmak. Arról van szó, hogy egy dolog egyed is, meg tulajdonság is lehet egyszerre. Például a Józsi Szolnok megyébõl jött állításban a Diákok egyedben szereplõ megye annak Megye tulajdonsága. De ha meggondoljuk, a Megyéket mint egyedeket is kezelhetjük külön, hiszen azoknak is vannak fontos tulajdonságaik, amiket felesleges mindig felemlegetni, ha valamelyik diákunknál rögzítjük az adott megyét. Természetesen ez nem vezet ahhoz a káoszhoz, hogy minden egyedünk minden tulajdonságát külön is egyednek kéne tekintenünk. Mi döntünk arról (és késõbb meglátjuk hogyan) hogy az egyedben

szereplõ tulajdonságok közül melyiket célszerû külön egyedként is kezelni. AZ AZONOSÍTÁS PROBLÉMÁJA Tegyük fel, hogy diákjaink fontos adatait egy táblázatban rögzítjük és egy sor egy diáknak felel meg. Mindezt persze úgy is mondhatjuk, hogy a Diákok egyed tartalmazza diákjaink tulajdonság elõfordulásait. A probléma a következõ Vajon hogyan lehetne azonosítani diákjainkat, ha valamelyikük adatait akarnánk e táblázatból megkapni? A deszkriptív (leíró) azonosítás módszere • Elsõ ötletünk az, hogy azonosítsuk õket a nevük szerint. Hamar rájövünk azonban, hogy nem ez a legjobb megoldás, mert mi van, hogyha két diákunknak is ugyanaz a neve. Az ötletet finomíthatjuk úgy, hogy nem egy, hanem két tulajdonságot, a Nevet és az AnyjaNeve tulajdonságot együtt. A deszkriptív azonosítás során tehát azt az elvet követjük, hogy addig bõvítjük a nem egyedi sajátosságokat, amíg együtt már egyértelmûen azonosítják azt a

kérdéses dolgot. Ezt a megoldást összetett azonosítónak -6- nevezzük. Be kell látnunk azonban, hogy nem ez a legtökéletesebb megoldás, bár sokszor ezt is alkalmazhatjuk. A nominális (név szerinti) azonosítás • Ilyen esetben az egyednek egy olyan tulajdonságát kell megkeresnünk, ami egyedi. Például a személyi igazolványszám, vagy a személyi szám Ezekkel is van néha probléma. A személyi szám például alkotmányellenes, a személyi igazolványszám pedig kényelmetlen akkor, ha idõnként megváltozik. A mesterséges azonosítás • Ebben az esetben azt tehetjük, hogy mi adunk neki azonosítót. Mondjuk egy számot. Csak arra kell vigyázni, hogy ne legyen belõle két azonos Ez a megoldás elsõ látásra nehézkesnek tûnik. Tudnunk kell azonban, hogy a korszerû adatbáziskezelõk rendelkeznek az úgynevezett számláló típusú tulajdonsággal, és ha ezt felvesszük az egyedbe azonosítónak, akkor a rendszer automatikusan gondoskodik errõl a

problémáról úgy, hogyha felveszünk egy új tanulót (az eredeti példánknál maradva), akkor ennek az értéke automatikusan eggyel nagyobb lesz. Sõt a rendszer semmilyen körülmények között nem engedi ennek az értékét utólag megváltoztatni. Azon sem kell aggódnunk, hogy az azonosítás miatt meg kéne jegyeznünk ezt a számot, mert a program ügyes megoldásokkal biztosítja, hogy ezt a számot úgy használjuk, hogy észre se vegyük. Véleményünk szerint ez a megoldás tekinthetõ a legtökéletesebbnek. Egyrészt mert rendkívül helytakarékos másrészt nagyon stabil foglamazzuk meg általánosan tehát, hogy mit tekintünk azonosítónak, amit elsõdleges kulcsnak is neveznek. Az egyed azon tulajdonságát vagy tulajdonság-kombinációját, amely minden egyed-elõfodulásra eltérõ értéket vesz fel, az egyed azonosítójának, más néven elsõdleges kulcsának nevezzük. KAPCSOLAT, -ELÕFORDULÁS, -HALMAZ Vegyük elõ megint a diákok adatainak

rögzítése példát és nézzük az alábbi mondatokat, melyek a Diákok egyed elõfordulásai és tulajdonképpen három tulajdonságot rögzítenek. Név, Osztály, Osztályfõnök: Jenõ az 1a-ba jár és osztályfõnöke a Nagytudású Hugó. Béla a 2a-ba jár és osztályfõnöke a Bölcs Benõ. Feri az 1a-ba jár és osztályfõnöke a Nagytudású Hugó. és így tovább. Ezt a sorozatost szemlélve célszerûbb lenne A Diákok egyed mellett bevezetni az Osztályok egyedet annak érdekében, hogy ne kelljen állandóan ismételgetni az osztályfõnökök neveit. Ilyenformán ugyanez így néz ki: A Diákok egyed: Jenõ az 1a-ba jár. Béla a 2a-ba jár. Feri az 1a-ba jár. és így tovább. Az Osztály egyed: Az 1a osztályfõnöke Nagytudású Hugó. A 2a osztályfõnöke Bölcs Benõ. Vegyük észre hogy a két egyed között kapcsolat áll fenn. Mégpedig az osztály tulajdonságon keresztül ezt úgy értjük, hogyha az Osztály egyed mondatait olvasgatjuk és meg

akarnánk -7- tudni ki az egyes tanulók osztályfõnöke, akkor megnézzük melyik osztályba jár, majd az Osztályok egyedben kikeressük ezt a a konkrét osztályt, ahol megtudhatjuk az illetõ tanár nevét. Nézzük mindezt általánosan: Az egyedek között lévõ összefüggéseket kapcsolatoknak hívjuk. Ezek közül egyet kapcsolat-elõfordulásnak nevezünk, illetve ezek összessége a kapcsolat-halmaz. A gyakorlatban az, hogy milyen egyedeket alkalmazunk és azok között milyen kapcsolatokat hozunk létre nem magától értetõdõ és igen nehéz feladat. Lényegében ez jelenti az adatbázis tervezésének a lényegét és nehézségét. AZ ADATBÁZIS Elsõ körben az adatbázis a bennünket érdeklõ különbözõ féle jelenségek ismereteinek szervezett együttese. Itt most elsõsorban azt szeretnénk érzékeltetni, hogy az adatbázis sem adatbank, sem az állományok szervezetlen együttese. A probléma a következõ Hogyan lehetne az alábbi szöveges típusú

állításokat a számítógép által feldolgozhatóan megfogalmazni: Pista Szolnok megyébõl jött, az 1a-ba jár és az osztályfõnöke Nagy Béla. Feri Pest megyébõl jött, az 1a-ba jár és az osztályfõnöke Nagy Béla. Sári Pest megyébõl jött, az 2a-ba jár és az osztályfõnöke Kis Ágota. Józsi Szolnok megyébõl jött, az 1a-ba jár és az osztályfõnöke Nagy Béla. Juci Szolnok megyébõl jött, az 2a-ba jár és az osztályfõnöke Kis Ágota. E fenti megfogalmazás az adatbanki, szöveges megoldás. Ennek állományi megoldása egy táblázat, ami elsõ látásra szervezettnek tûnik: Név Pista Feri Sári Józsi Juci Megye Szolnok Pest Pest Szolnok Pest Osztály 1a 1a 2a 1a 2a Osztályfõnök Nagy Béla Nagy Béla Kis Ágota Nagy Béla Kis Ágota Ha elgondolkozunk ezen az elrendezésen, akkor feltûnik, hogy többször van felírva az osztályfõnök, ismétlõdik a megye. Az, hogy többször elõfordulnak ezek az adatok és feleslegesen foglalják a

helyet, még nem is lenne akkora probléma. De mi van, ha például megváltozik az osztályfõnök. Akkor annyiszor ki kell javítani, ahányszor szerepel Mi van, ha igényünk támad arra, hogy megyék további adatait is rögzítsük, mint azok területét, lélekszámát, stb. Vegyük fel ezeket a tulajdonságokat is oszlopként és annyiszor ismételjük meg, ahányszor az adott megye szerepel? Mi van akkor, ha rájövünk, hogy a Szolnok megyét valójában Jász-Nagykun-Szolnok megyének nevezik. Javítsuk ki mindenhol? Hogyan lehetne ezekre az elsõ látásra csupán kényelmetlenségi problémákra valamilyen megoldást találni? Nézzük az alábbi elrendezést, amiben ezt az egy táblát három különbözõ táblára bontottuk úgy, hogy három egyedet alkottunk? Diákok, Osztályok, Megyék. (Hogy miért pont ezt a hármat? Erre nem tudunk pontos magyarázatot vagy algoritmust mondani, bár erre is vannak különféle eljárások. De egy biztos, az alábbi megoldás

megoldja az elõbb említett problémákat.) -8- DIÁKOK Név Pista Feri Sári Józsi Juci MegyeAz 1 2 2 1 2 OsztályAz 1 1 3 0 3 MEGYÉK MegyeAz 1 2 3 Megye Szolnok Pest Heves OSZTÁLYOK OsztályAz Osztáyl 1 1a 2 1b 3 2a 4 2b Osztályfõnök Nagy Béla Erõs Egon Kis Ágota Fehér Jenõ E megoldásban szám azonosítókat használtunk a megyék és az osztályok esetében (MegyeAz és OsztályAz). Az egyedek közötti kapcsolatok: DIÁKOK – MEGYÉK a MegyeAz-on keresztül DIÁKOK – OSZTÁLYOK az OsztályAz-on keresztül. Bár a fent felvetett problémák mindegyikét kiküszöböli ez a három táblázat, mégis idegenkedhetünk ettõl a megoldástól, hiszen az adatok kapcsolatokon keresztüli keresgélése nehézkesnek tûnik. Az is, de csak addig, amíg nekünk kell megcsinálni De nyugodjunk meg, a korszerû adatbázis–kezelõk azért azok amik, mert ezt automatikusan megoldják. Ezt és az ilyen fajta megoldásokat nevezzük adatbázis módú adatkezelésnek,

ahol 1. megalkotjuk az egyedeket a hozzájuk tartozó tulajdonságaikkal 2. megadjuk a közöttük lévõ kapcsolatokat 3 a többit az adatbázis-kezelõ rendszerre bízhatjuk. Az elõbb leírt adatbázis módú ismeretkezelésnél megkülönböztethetjük az adatbázis elvi felépítését, amit adatmodellnek hívunk, és magát az adatbázist, amit ez alapján szerint szervezünk meg és töltjük fel konkrét adatokkal. Mindez általánosan fogalmazva: Az adatmodell az egyedek és tulajdonságaik valamint a köztük lévõ kapcsolatok szervezett együttese. Az adatbázis az egyed-elõfordulások, azok tulajdonság-értékeinek és kapcsolatelõfordulásainak az adatmodell szerint szervezett együttese. NÉHÁNY FONTOS MEGJEGYZÉS A terminológia zûrzavara • Ha az olvasó türelmesen végigbogarászta az eddig leírtakat, bizonyára vakarja a fejét – fõleg ha már foglalkozott valamilyen szinten az adatbázis-kezeléssel –, vajon mik ezek az új fogalmak hogy egyed,

tulajdonság, elõfordulás stb. Mért nem jó az hogy adattábla, mezõ, rekord, stb. ahogy azt a különbözõ szakkönyvekben már megszoktunk Megnyugtatjuk a kedves olvasót, hogy itt nem a szakkifejezések újra kitalálásáról van szó, vagy valamilyen felsõbbrendû tudományoskodásról, hanem arról, hogy mint azt késõbb látni fogjuk, az adatbázis tervezésének három szintje van. Az fogalmi, logikai, és a fizikai Ennek megfelelõen az eddig tárgyalt a fogalmakat az elvi szinten használjuk, az adattábla, mezõ, rekord stb. pedig a logikai és a fizikai szinten használatosak Már most felhívjuk a kedves olvasó figyelmét arra, hogy igen lényeges dolog az adatbázis tervezése során e három szint megkülönböztetése! Olyannyira, hogyha ez nem így lenne, nem vettük volna azt a fáradságot hogy e jegyzetet megírjuk. Ugyanis az adatbázis tervezés egyik lényege, hogy szétválasszuk és megfelelõen kezeljük e három szintet. Most akkor „hány” az

adatbázis? • Vajon amikor a fent említett módon az elõbb ismertetett adatbázis módú szemlélettel megalkotjuk rendszerünket, hány ilyen adatbázist kell létrehoznunk? Ezt majd késõbb majd részletesen is kifejtjük, de egy adott vállalat, intézmény dolog leírására mindig egy adatbázist kell megalkotnunk. -9- Az adatbázis három szintje A TERVEZÕI VAKSÁG A számítástechnikai tervezõk és rajtuk keresztül a felhasználók is eszközorientáltak, ami azt jelenti, hogy az éppen a rendelkezésükre álló adatbázis-kezelõ által támogatott adatszerkezetekben gondolkodnak. Ez azért baj, mert ha áttérnek egy másik rendszerre, többnyire kezdhetnek mindent elölrõl. Ez a fejezet arról szól, hogy van az adatbázisnak egy eszközfüggetlen szemlélete. Az adatbáziskutatók rájöttek arra, hogy az adatbázisok szerkezetét több síkon kell vizsgálni. Eszerint megkülönböztetjük az adatbázis fogalmi, logikai és fizikai szintjét, ami nem azt

jelenti, mintha szét kéne darabolnunk három részre az adatbázist, hanem azt, hogy az adatbázis szerkezetét három lépésben kell kialakítani úgy, hogy mindhárom lépésnél másra kell figyelnünk. AZ ADATBÁZIS FOGALMI ÉS LOGIKAI SZERKEZETE Sajnos általában igaz az a tény, hogy a tervezõk többsége olyan adatszerkezeteket szokott kitalálni, amelyek az általuk az adott pillanatban fontosnak vélt adatok rögzítését, kezelését és lekérdezését biztosítja. Ennek talán három fõ oka van: Az egyik, hogy teljesen természetes az a gyakorlat, hogy az adatbázis szerkezetét nap-mint nap a változó igények szerint állandóan át kell alakítani és minden utólagos változtatás hibákat vihet be a rendszerbe. A másik az, hogy a tervezõket legtöbbször szinte megoldhatatlan feladat elé állítják azzal, hogy minden azonnal és tegnapra kéne, így sokszor egyszerûen nincs idõ kidogozni a megfelelõ megoldás részleteit és csak a pillanatnyi

elõnyökre fognak koncentrálni. A harmadik eset a lustaság, a pillanatnyi elõny elõtérbe helyezése. Egyszerûen tisztában kell lennünk azzal, hogyha egy adatbázis rosszul van megtervezve, akkor ezek egyre több fejtörést fognak okozni a fejlesztõnek, hogyan mûködtesse az újabb és újabb igényeknek megfelelõen, mígnem egyszer eljut oda, hogy inkább újra kéne tervezni az egészet. Mégis hogyan lehet elkerülni ezeket a problémákat? A válasz a következõ: Az adatbázis tervezését és módosítását mindig a megfelelõ szinten kell kezdeni illetve átalakítani. Az adatbázis tervezéshez alapvetõen két hozzáállás létezik: Azok, akik az állománykezelõ típusú rendszerekhez szoktak (dBASE, Clipper) rekordképekben gondolkodnak és furmányos algoritmusokon, hogy azok segítségével adataikat kezelni tudják. Jóval kevesebbet – legrosszabb esetben semmit – törõdnek az adatbázis átfogó szemléletû tervezésével. Azok, akik már

találkoztak igazi adatbázis-kezelõvel, azok elõször eltöprengenek a jelenségek valódi összefüggésein. Vannak a Diákok, a Megyék, az Osztályok stb Ezek mind a valós jelenségeket tükrözõ dolgok. Egymástól eltérõ lényegek, tehát külön egyedként kell kezelni õket Ezért ezeket külön táblában kell megjeleníteni és meg kell köztük teremteni a kapcsolatokat. Az ilyen tervezõk nem csak azért gondolkodnak így, mert valaki azt mondta nekik hogy így a helyes. A korszerû adatbázis-kezelõk egyszerûen kikényszerítik ezt a gondolkodásmódot, ugyanis a -10- rosszul tervezett adatbázisokkal semmit nem képesek kezdeni. Most fogalmazzuk meg általánosan, mit is jelent az adatbázis fogalmi szintje: Fogalminak nevezzük a jelenségeket, azok sajátosságait és viszonyait a valóságnak megfelelõen és természetes fogalmakban tükrözõ adatszerkezetet. (Halassy 1994, 45) (Ez a megfogalmazás most még igencsak lóg a levegõben. Akkor válik majd

világossá, ha megismerkedünk a fogalmi tervezés eszközeivel.) Nézzük meg, hogy mi minden befolyásolhatja még döntésünket arról, hogy végül is milyen legyen az adatbázis szerkezete: A technikai tényezõ • Sokszor sajnos alkalmazkodni kell annak az adabázis-kezelõnek a lehetõségeihez, amivel dolgozunk és ezért nincs lehetõségünk arra, hogy a valóságot legjobban tükrözõ adatmodell jöjjön létre. A hozzáférés • A gyakorlatban elõfordulnak különleges igények. Például a személyes adatok titkossága, ami lehet hogy megköveteli a titkosság érdekében a jó szerkezet módosítását a felmerült igények szerint. Hatékonysági • Vannak olyan gyakorlati helyzetek, hogy inkább amellett döntünk, hogy a nyilvánvalóan több egyedre bontható többtáblás szerkezet helyett az egytáblásat választjuk, mert ez az adott szituációban hatékonyabbak. (Ezt a szerkezetet jobban támogatja az adatbázis-kezelõnk, a felhasználó speciálisan

csak egy dologra kíváncsi és ehhez megfelelõ a szerkezet, stb.) Ha áttekintjük az eddig elmondottakat, akkor most már megfogalmazhatjuk azt, mit is értünk az adatbázis logikai szerkezetének: A technikai, hozzáférési és hatékonysági követelményeknek ill. korlátoknak megfelelõen meghatározott tartalmi adatszerkezetet nevezzük az adatbázis logikai szerkezetének. Vagyis arról van szó, hogy van az adatbázisnak egy, a valóságot elvileg hûen követõ felépítése (az adatbázis elvi szintje), illetve van egy gyakorlati, a körülményeknek jól megfelelõ változata, amit végül is használni fogunk (az adatbázis logikai szintje). Ha a tervezõ kizárólag csak a logikai szinten gondolja át hogy mit akar, akkor a körülmények állandó változása miatti folyamatos változtatásokkal szemben az adatbázis tervezését állandóan elölrõl kell kezdenie, mert minduntalan foltozgatásos káoszba keveredik a kizárólag gyakorlati szinten vizsgált

megoldása. Azonban semmi akadálya nincs annak, hogy az elvi terv egy az egyben követi a fogalmi adatbázistervet. Mi magunk ezt tartjuk a legjobb megközelítésnek Vannak ma már olyan adatbázis-kezelõk, amik e két tervezési szintet együtt segítik átlátni. (Itt az MS ACCESS adatbázis-kezelõ kapcsolattervezõ ablakára gondolunk, ahol egyszerre látszik az adatbázis elvi terve és annak logikai szerkezete.) AZ ADATBÁZIS FIZIKAI SZERKEZETE Van egy mondás, miszerint az ördög a részletekben van. Ez így igaz, és az adatbázis akkor jó, ha annak a fizikai megvalósítása is a valósághoz igazodik. Nézzük, melyek azok a részletproblémák, ami itt felmerülnek: -11- Validálás vagy érvényesítés • A bevitt adatok csak valósak lehetnek. Ha dátumot viszünk be, akkor annak szerkezete, értéke, csak helyes lehet. A fejlett adatbázis-kezelõk – Ellentétben az állománykezelõkkel – mára adatbázis szintjén kezelik ezt a problémát, Magában az

adatstruktúrában megadhatjuk, hogy egy bevitt értéket ilyen szemmel ellenõrizzen és ha nem jó, akkor arra figyelmeztesse a felhasználót, és rossz értéket ne engedjen felvinni (maszkok). Az adatábrázolás • Adatábrázolásnak azt nevezzük, amikor megadjuk egy adat típusát és méretét. Amikor az adatbázis kutatók elgondolkodtak azon, miképpen osztályozzák a világ jelenségeit leíró adatokat, rájöttek, hogy azok természetük szerint különbözõ csoportokba sorolhatók. Eszerint vannak szöveges, képi, logikai, szám stb típusok Célszerû ezeket külön kezelni, mert mindegyikre külön értelmezhetünk mûveleteket. (Például mást jelent két számot és két szót, vagy egy dátumot és egy számot összeadni.) Másrészt pedig a kezelõk gyorsabban és hatékonyabban tudják ezeket a típusokat külön, mint egyformán kezelni. Az adatok elrendezése, tárolási módja • Az állománykezelõknél központi kérdés, míg az

adatbázis-kezelõknél szinte közömbös, hogy az adatokat mi módon tárolja és kezeli a rendszer. Az adatbázis kezelõk az adatbázist, mint egészet mûködtetik és ezt a szemléletet kényszerítik és várják el a fejlesztõktõl. Vannak olyan adatbázis-kezelõk, amik az egész adatbázist egy állományban tárolják. Minél korszerûbb egy adatbázis-kezelõ, annál kevesebbet kell törõdnie a felhasználónak azzal, hogy adatai milyen adatállományban és vannak és azoknak mi a szerkezete. Ez a kezelõ belsõ ügye, és ettõl az, ami Fizikai adatszerkezetnek nevezzük az ismeretek tárolón való elhelyezésének, hozzáférésének és ábrázolásának tudatosan meghatározott rendjét. (Halassy 1994, 49) Fizikai szint tehát az, amikor megadjuk a táblák mezõinek típusát, méretét, azok ellenõrzési határait (validálás), módját, a bevitelt segítõ maszkokat (hogy pl. csak számot lehessen bevinni). Annál korszerûbb egy adatbázis kezelõ, minél

inkább az adatbázis részeként tudjuk ezeket a dolgokat kezelni, és minél kevesebbet kell ez ügyben programokat írni. A FIZIKAI ADATSZERKEZET ELNEVEZÉSEI Mint azt már említettük más fogalmakat használunk az adatbázis elvi logikai és mást annak logikai és fizikai szintjén. Az adattábla, tábla vagy adatállomány • Ez az egyednek megfelelõ fogalom. Amikor adatbázist tervezünk, azt képzeljük, hogy a rendszer az adatokat táblázatos formában kezeli és táblázatokban kell gondolkodnunk. Mezõ, oszlop • Ez fogalom a tulajdonságnak felel meg. Egy adott tulajdonság nevét mezõ névnek vagy mezõnek, a tulajdonság-elõfordulást pedig a mezõ-értékének nevezzük. A mezõt oszlopnak is nevezik néha. Fõleg a táblázatkezelõk, szövegkezelõk és az adatbázis-kezelõk kapcsolatában. Rekord, sor • Ez a fogalom az egyed-elõfordulás megfelelõje. Rekordnak nevezzük az adattábla egy sorába írt adatokat, amik kizárólag csak egy egyedre

vonatkoznak. A táblázatkezelõk, szövegkezelõk és adatbázis-kezelõk kapcsolatában a sor elnevezés is helytálló. -12- ÖSSZEFOGLALÁS Amikor adatbázist tervezünk, akkor nem egy, hanem három tervet kell készítenünk, Egy elvi, logikai és egy fizikai tervet. A fejlesztés idõrendben is ezt jelenti Elõször megalkotjuk a fogalmi tervet, majd nem átalakítjuk, hanem leképezzük ebbõl a logikai szintet. Ha átalakítással és nem leképezéssel valósul meg a logikai szint, akkor nincsen értelme az elvi szintek, hiszen ezzel átalakítjuk és mást csinálunk mint amit kigondoltunk. Ez nem azt jelenti hogy nem változtathatunk a terven, de ha az adatbázis különbözõ szintjei nincsenek összhangban, akkor mindez értelmetlen. Modern adatbázis-kezelõk ezt a tervezési szemléletet nem csak támogatják, hanem ki is kényszerítik. Ha az elvi, logikai és fizikai szerkezet egyetlen tervben egyesül, akkor igen nehéz a változtatások végig vitele (az

áttekinthetetlenségrõl nem is beszélve), és legtöbbször a fejlesztõ az újratervezésbe vagy káoszba bonyolódik. Az helyes szemlélet segítségével fizikai adatfüggetlenséget érhetünk el: Fizikai adatfüggetlenségrõl beszélünk akkor, ha az adatok elhelyezési, hozzáférési és adatábrázolási módjában bekövetkezõ változásakor nincs szükség a programok módosítására. Szerintünk akkor jó egy adatbázis, minél jobban megközelíti a fizikai adatfüggetlenséget. Sokan most azt gondolhatják, hogy ez csak egy idea. Az igazság azonban az, hogy egy jól kialakított adatbázis magában hordozza a fizikai adatfüggetlenséget. AZ ADATMODELL-DIAGRAM Amikor az elvi szinten tervezzük meg az adatbázist, akkor annak szerkezete meglehetõsen bonyolult is lehet. Az áttekinthetõség érdekében tehát olyan jelölési rendszert kellett kidolgozni, ami kizárólag a lényegre koncentrál és áttekinthetõ. Ez az adatmodell-diagram, amiket kitalálójáról

Bachman diagramnak is neveznek. Az eredeti megoldás szerint a téglalap három részre van osztva: a közepén az egyed neve, a tetején annak azonosító tulajdonságának a neve (elsõdleges kulcsa), az aljára pedig a két egyed között kapcsolatteremtõ tulajdonság neve van felírva. A két egyedet összekötõ vonal a köztük lévõ kapcsolatot jelképezi. Az alján lévõ varjúláb pedig ebben az esetben azt érzékelteti, hogy egy megyéhez több diák is tartozhat. A diák egyed felõli oldalon pedig azért nincs varjúláb, mert egy diákhoz csak egy megye tartozhat. (A késõbbiekben nagyon alaposan tárgyaljuk ezeket a problémákat amikor az inhomogén és homogén adatszerkezeteket tárgyaljuk. Itt csak érintõlegesen vázoljuk a elvi tervezés eszközrendszerét) Az ábrán a Diákok és a Megyék egyed közötti kapcsolat Bachman diagramja látható. -13- A Diákok és a Megyék egyedek közötti kapcsolat Bachman diagramjának eredeti formája A Diákok és

a Megyék egyedek közötti kapcsolat Bachman diagramjának ACCESS reprezentációja A Bachman diagramnak vannak más formái is. Mi a késõbbiekben nem ezt, hanem az MS ACCESS által használt kapcsolattervezõjét és jelölésrendszerét használjuk. (Meg kell jegyeznünk azonban, hogy ebben a megoldásban az elvi és a logikai szint összemosódik amit azért nem tartunk problémának, mert nézetünk szerint az adatbázis akkor jó, ha a logikai szint az elvi terv leképezése. Ebben a megoldásban azt sem tartjuk majd zavarónak, hogy az egyedeknek nem csak az azonosítója és kapcsoló tulajdonsága, hanem a többi is látható.) Az ábra jobb oldali részén az elõbbi mintapélda látható. -14- Alapvetõ szerkezetek AZ ADATMODELL HÁROM TÉNYEZÕJE Az adatmodellnek három tényezõje van: egyed, tulajdonság, kapcsolat. (Mint emlékszünk rá, az adatmodell egyedekbõl áll (pl. Diákok, Megyék), amik között kapcsolatok vannak (pl Diákok-Megyék kapcsolat) és az

egyedeknek tulajdonságaik vannak (pl. A diákok egyednél a Név, DiákAz, stb. tulajdonságok)) Ezek az adatmodellben egyenrangú lényegek Egyik sem fontosabb a másiknál. Az egyed tulajdonságait az egyed belsõ szerkezetének nevezzük. Az egyed kapcsolatait pedig az egyed külsõ szerkezetének hívjuk. A TULAJDONSÁGOK SZEREPEI Egy tulajdonságnak az egyeden belüli feladatát a tulajdonság szerepének nevezzük. A tulajdonságok három féle szerepe lehet: Azonosító, vagy elsõdleges kulcs • Amikor az adott tulajdonság egyértelmûen azonosítja az egyed elõfordulást. (Lásd Az azonosítás problémája alfejezetet) Az egyed számára az adatbázis elvi szintjén csak egy azonosítója lehet. Leíró • Az egyednek azon a tulajdonságait, melyek az egyed elõfordulásaira nézve nem egyediek, más szóval nem tudják azonosítani az egyed elõfordulásokat, leíró szerepûek. Egy egyednek a legtöbb tulajdonsága ilyen. Az egyednek tetszõleges számú leíró

tulajdonsága lehet, és ezek sorrendje teljesen közömbös, csak a rend kedvéért érdemes õket csoportosítani. Kapcsoló vagy idegen kulcs • Az olyan tulajdonságot, ami az egyik egyedben azonosító, a másikban leíró jellegû, vagy e két egyed közti kapcsolatot biztosítja, kapcsoló szerepû. Az ilyen tulajdonságot idegen kulcsnak is nevezzük. Az egyedben annyi kapcsoló szerepû tulajdonság van, ahány egyedhez kapcsolódik. DIÁKOK Név Pista Feri Sári Józsi Juci MegyeAz 1 2 2 1 2 OsztályAz 1 1 3 1 3 MEGYÉK MegyeAz 1 2 3 Megye Szolnok Pest Heves OSZTÁLYOK OsztályAz Osztáyl 1 1a 2 1b 3 2a 4 2b Osztályfõnök Nagy Béla Erõs Egon Kis Ágota Fehér Jenõ Az fenti példában A DIÁKOK egyednek nincs azonosítója, de benne a Név leíró, a MegyeAz és az OsztályAz kapcsoló szerepû tulajdonságok. A MEGYÉK egyedben a MegyeAz azonosító, a Megye pedig leíró szerepû tulajdonságok. -15- A tulajdonságok szerepei nem azonos fontosságúak. Az

azonosítók nem csak azonosítják az egyed-elõfordulásokat, hanem az egyedek közötti kapcsolatteremtés eszközei. Mivel a tulajdonságok szerepe attól is függ melyik egyedben vannak és ez dönti el fontosságukat is ezért meg kell különböztetnünk azok relatív és abszolút szerepét. Elõször általánosan: A tulajdonságnak az egyeden belül ellátott funkcióját relatív szerepnek , legfontosabb relatív feladatát pedig abszolút szerepnek nevezzük. (Halassy 1994, 75) A fenti definícióban két fogalmat kell alaposabban tisztázni. A relatív (viszonylagos) szó azt jelenti, hogy egy tulajdonság feladata attól függ, melyik egyedben van. A másik pedig az, hogy egy tulajdonságnál elõfordulhat, hogy a relatív és abszolút szerepe ugyanaz. Nézzünk néhány példát: A MEGYE egyed Megye tulajdonsága, mivel leíró jellegû és sehol máshol nem fordul elõ az abszolút és relatív szerepe is leíró. A MEGYE egyed MegyeAz tulajdonságnak két relatív

szerepe van: a MEGYE egyedben azonosító, a DIÁKOK egyedben kapcsoló. De legfontosabb szerepe az, hogy azonosító, tehát az abszolút szerepe azonosító. Miután bevezettük ezeket a fogalmakat az adatmodellre vonatkozóan a következõ megállapítást tehetjük: Két egyed akkor és csak akkor áll kapcsolatban egymással, ha az egyik kapcsoló szerepû tulajdonságaként tartalmazza a másik azonosító szerepû tulajdonságát. (Halassy 1994, 76) E megállapítás magától értetõdõ, hiszen egy egyed kizárólag csak az azonosítóján keresztül kapcsolódhat egy másik táblához, különben onnan nézve nem lehetne egyértelmûen kiválasztani melyik elõfordulásáról van szó. És a másik oldalról pedig mi mással kapcsolnánk egy táblát a másikhoz, ha nem tartalmazná annak azonosítóját. Az azonosító szerepû tulajdonsággal kapcsolatban ma a következõ általános nézetek terjedtek el, ami általános ajánlásként kell elfogadnunk az adatmodell

szintjén: 1. Minden egyednek kell, hogy legyen azonosítója 2. Az azonosító értéke egyetlen egyed-elõfordulásban sem lehet üres/ismeretlen 3. Minden egyednek csak egy azonosító tulajdonsága lehet 4. Ugyanaz a tulajdonság csak egyetlen egyednek lehet az azonosítója (Halassy 1994, 74) A fent felsorolt nézetek közül nem mindegyiket szoktuk és nem mindegyiket kell betartanunk az adatbázis logikai szintjén. Ezek kizárólag csak a fogalmi szintû adatmodellezés megkötései. Az elsõ kettõ azt mondja ki, hogy minden egyed-elõfordulást meg kell tudni különböztetni. A hármas, négyes pedig az egyedek és az azonosítók közötti kölcsönös és egyértelmû megfeleltetését rögzíti. A fenti szigorú megkötések azt szolgálják, hogy az adatbázis elvi szinten megfogalmazott modelljében kizárjuk a többszörösséget (felesleges ismétlõdést) és a következetlenséget, ne keveredjünk ellentmondásba. HIERARCHIKUS INHOMOGÉN VAGY EGY-TÖBB KAPCSOLATOK

Tekintsük a DIÁKOK és a MEGYÉK egyedeket, melyek között a MegyeAz tulajdonság teremti meg a kapcsolatot. Az alábbi ábrán egy konkrét példán láthatjuk, hogyan tárolnánk diákjaink adatai között azt, hogy mely megyébõl jöttek. Most válasszunk ki a DIÁKOK tábla egy konkrét rekordját (teljesen mindegy melyiket), mondjuk Pistát, és innen nézzünk át a másik -16- táblára, majd kérdezzük meg a következõt: Vajon Pista hány megyébõl jöhetett? Válaszunk az, hogy Pista csak egy megyébõl jöhetett, mert olyan nincs, hogy egy diák egyszerre több megyébõl jött. Most válasszuk a MEGYÉK táblát és ott is konkrét (teljesen mindegy melyik) rekordot, mondjuk Pest megyét, és nézünk át a másik táblára azza a kérdéssel: Vajon Pest megyébõl hány diák jöhet? Válaszunk az, hogy Pest megyébõl több diák jöhet. Elnézést kérünk az olvasótól ezért a bárgyúnak tûnõ kérdezgetéstõl, de lényegében ezzel a módszerrel lehet

megállapítani két egyed közötti kapcsolatról, annak típusát. DIÁKOK DiákAz 1 2 3 4 5 Név Pista Feri Sári Józsi Juci MEGYÉK MegyeAz 1 2 3 MegyeAz 1 1 2 1 2 Megye Szolnok Pest Heves Két egyed közötti kapcsolatban, ha az egyik egyed 1 elõfordulásához a másik egyed több, N elõfordulása tartozhat, akkor az ilyen kapcsolatokat 1:N, vagy egy-több kapcsolatnak nevezzük. Azt az egyedet, amelyben a kapcsolatot teremtõ tulajdonság azonosító szerepû, azt fölérendeltnek, amelyben kapcsoló szerepû, alárendeltnek nevezzük. Az ilyen kapcsolatra gyakran használják a birtoklás jelzõt is. Az ilyen kapcsolatokat azért nevezik inhomogénnek, mert két egymástól különbözõ fajta egyed viszonyáról van szó (A DIÁKOK és a MEGYÉK különbözõ dolgok.) A hierarchikus megnevezés szerintünk pusztán csak formai jelzõ, tartalmilag semmilyen birtoklásról nincs szó. Inkább az elrendezés asszimetriájára utal: az egy oldal felsõbbsége uralja a több

oldal alárendeltségét képbõl származik. Az opcionalitás • Az ilyen viszonyokat szemlélve felvetõdik a következõ kérdés mindkét oldalról szemlélve (felülrõl és alulról): Vajon kötelezõ-e a kapcsolat? Példánkban: Vajon minden megyébõl jött diák (egy oldalról vagy felülrõl)? Nem. Vajon minden diák jött valamilyen megyébõl (több oldalról vagy alulról)? Igen. Látjuk tehát, hogy az egy oldalról vagy felülrõl nézve a kapcsolat opcionális (nem kötelezõ), lehet olyan megye, melyhez nem tartozik diák. Viszont alulról nézve kötelezõ, vagyis nincs olyan diák, melyhez ne tartozna megye A DIÁKOK és a MEGYÉK egyedek közötti egy-több kapcsolat, ahol az egy oldalon az 1, az N oldalon ∞ jel áll. -17- HÁLÓS VAGY TÖBB-TÖBB EGYEDVISZONYOK Tekintsük a következõ feladatot: Rögzíteni szeretnénk, hogy diákjaink közül ki mit sportol. Elsõ gondolatunk az lehet, hogy próbálkozzunk meg azzal a nyilvánvaló ötlettel, hogy legyen

egy DIÁKOK és SPORTOK egyed, ahol a DIÁKOK egyedben tároljuk le a SPORTÁGAK azonosítóját ugyanúgy mint a megyéknél. A dolog addig mûködik is (azzal együtt, hogy van, aki nem is sportol), amíg ki nem derül, hogy Feri nem csak focizik, de pingpongozik is. Most ugyanis egy helyre két dolgot kéne írnunk egyszerre. Tehetnénk azt is, hogy a DIÁKOK egyednél bevezetnénk több oszlopot is a sportágak tárolására, de mennyit. Induljunk el abba az irányba, hogy alkalmazzunk még egy táblát ami a kettõt összeköti az alábbi módon: DIÁKOK DiákAz 1 2 3 4 5 Név Pista Feri Sári Józsi Juci SPORTOLÁS DiákAz 2 2 3 SportAz 1 2 1 Egyesület UTE FTC Dózsa SPORTOK SportAz 1 2 3 4 5 Sportnév Foci Pinpong Tenisz Kézilabda Horgász Láttuk tehát, – miközben a feladatot megoldottuk – hogy egy diákhoz több sport és egy sportághoz több diák is tartozhat. Ha két egyed közötti kapcsolatban az egyik egyed 1 elõfordulásához több, a másik egyed 1

elõfordulásához szintén több elõfordulás tartozhat az egyik egyedbõl, akkor azt mondjuk, hogy közöttük N:M vagy több-több viszony áll fenn. Az ilyen viszonyokat az összefonódások szövevényessége miatt hálós viszonyoknak is nevezzük. Az ilyen viszonyokat közvetlenül semmilyen adatbázis-kezelõ nem támogatja Ilyenkor mint láttuk, még egy egyed bevezetésével hidaljuk át a problémát. Ha nagyon alaposan megfigyeljük a mintapéldánkat, akkor észrevehetjük, hogy a DIÁKOK – SPORTOLÁS egyedek között 1:N és a SPORTOK – SPORTOLÁS egyedek között szintén 1:N kapcsolat áll fenn. Általánosan is igaz: Ha két egyed között N:M viszony áll fenn, akkor azt egy harmadik egyed közbeiktatásával oldhatjuk meg, aminek bevezetésével két 1:N viszony alakul ki. Még egy fontos dologra szeretnénk felhívni a figyelmet a mintapélda kapcsán. Amikor közbeiktattuk a SPORTOLÁS egyedet, akkor felvettük az Egyesület leíró szerepû tulajdonságot is,

holott erre lényegében nem is lett volna szükség. Azt akarjuk ezzel mondani, hogy az N:M viszonyt megvalósító közbeiktatott egyed esetén – ha annak van értelme – a kapcsolatokat létrehozó tulajdonságok mellé akárhány leíró tulajdonságot felvehetünk. Figyeljük meg, hogy a SPORTOLÁS egyedben a DiákAz és a SportAz együtt azonosítók, amit összetett kulcsnak is nevezzünk. Az ilyen összetettséget a + jellel szokás jelölni, és eszerint az elõzõ mondat így hangzik: A SPORTOLÁS egyedben a DiákAz+SportAz az azonosítója. -18- Lássuk, hogy mindez elvi szinten hogyan néz ki: Az N:M viszonyt megvalósító megoldás A KÖLCSÖNÖS VAGY 1:1 VISZONY Ez a viszony meglehetõsen ritka. Ez jönne létre a DIÁKOK és a IGAZOLVÁNYSZÁMOK egyedek között akkor, ha az a furcsa ötletünk támadna, hogy az igazolványszámot ne a DIÁKOK egyed egyik leíró mezõjeként, hanem külön egyedben tároljuk. Ez a viszony azért ritka, mert használatakor a

két egyed minden probléma nélkül összevonható. Mégis szokták használni akkor, hogyha valamilyen ideiglenes feladat merül fel. Például az idén pingpongversenyt rendezünk, és a résztvevõ diákok eredményeit rögzíteni kívánjuk. Célszerû létrehozni egy FUTÓK egyedet, amiben a résztvevõk pontszámait rögzíthetjük, mintha a DIÁKOK egyedhez hozzávettünk volna egy FutásEredmény leíró mezõt. Egyrészt azért, mert ezt a versenyt csak idén rendezzük meg, és ennek végeztével le is törölhetjük majd a táblát. Kár tehát bolygatni a DIÁKOK táblát. Másrészt ebben ez esetben nem minden diák vesz részt, így ha felvennénk erre a célra egy leíró mezõt a DIÁKOK egyedben, akkor sok üres hely keletkezne. Például: DIÁKOK DiákAz 1 2 3 4 5 FUTÓK Név Pista Feri Sári Józsi Juci DiákAz 2 3 4 -19- FutásEredmény 10 15 20 Elvi szinten pedig: Az egy-egy visztonyt megvalósító elvi terv HOMOGÉN SZERKEZETEK Az elõzõ

alfejezetekben az inhomogén szerkezetekrõl volt szó. Ezekben két letérõ egyedtípus kapcsolatáról volt szó. Vannak azonban olyan viszonyok, melyekben egy egyed elõfordulásai önmagukkal vannak kapcsolatban lássunk ezekre néhány tipikus példát. A visszamutató egyedviszony (beosztottak, fõnökök) Képzeljük el, hogy rögzíteni szeretnénk valahogy vállaltunknál, hogy kinek ki a fõnöke. Ebben az esetben tipikusan ugyanazon dolgok kapcsolatáról van szó, tehát a viszony homogén. Egy megoldás lehet az, amit az alábbi ábra mutat. Egyazon egyedben (SZEMÉLY) a Nevek tulajdonság mellé felvesszük a Fõnökök tulajdonságot. SZEMÉLY Személynév Feri Józsi Laci Pista Ottó Fõnöknév Pista Pista Ottó Ottó Peti Ha ezt a megoldást alkalmazzuk, akkor az úgynevezett visszamutató viszonyt valósítjuk meg. A megoldás végül is elfogadható, de van vele néhány probléma: Mi van ha Pista kilép Az, hogy mindenhol ahol szerepel, ki kell törölni és

helyébe írni az új fõnököt. Persze mindez lehetséges, csak az a baj, hogy ezt a fajta viszonyt az adatbázis-kezelõk nem támogatják, ami azt jelenti, hogy ezt a problémát csak program szinten lehet megvalósítani. A problémát megoldhatjuk két tábla segítségével, amik között többszörös egy több kapcsolat van. Vegyünk fel egy HIERARCHIA egyedet, amiben lényegében ugyanez a személy-személy összerendelés van azzal a különbséggel, hogy nem a nevek, hanem a személyek azonosítói kerülnek egymással párba és ezekkel van kapcsolatban az átalakított SZEMÉLY egyed: SZEMÉLYEK SzemélyNév SzemélyAz 1 Feri HIERARCHIA FõnökAz BeosztottAz 4 1 -20- 2 3 4 5 Józsi Laci Pista Ottó 4 5 5 24 2 3 4 5 Kérdezhetnénk, hogy vajon ez most miért jobb? Még egy tábla, rengeteg ismétlõdés, plusz bevitel. Mielõtt válaszolnánk, nézzük meg ennek a megoldásnak az elvi nézetét: A fõnök-beosztott viszonyt megvalósító homogén szerkezet két

darab egy-több viszony megvalósításával. Nézzük, mitõl szimpatikus ez a megoldás: 1. Mivel az adatbázis-kezelõk elsõdlegesen az egy-több viszonyokat támogatják, ezért ez illeszkedik a logikájukba. Ez ezért jó, mert ha kilép egy személy, akkor az adatbázis-kezelõ a kapcsolat miatt automatikusan megszünteti a fõnökbeosztott kapcsolatot. 2 Ez a szerkezet általánosabb kapcsolatok megvalósítására ad lehetõséget, mint az elõzõ ötlet, ugyanis megengedi az egy beosztott több fõnök viszonyt is, amit az nem. A családfa- és házastárs-viszony Tekintsük a következõ feladatot: Vállalatunknál elhatároztuk, hogy minden berendezésünket, amit gyártunk, leltárba veszünk az utolsó csavarig és létrehozunk egy olyan nyilvántartást, aminek célja válaszolni arra a két kérdésre: Vajon egy berendezés (gép) milyen alkatrészekbõl épül fel (felépülés)? Vajon egy adott alkatrész mely berendezésekbe épül be (beépülés)? Ha elkezdünk a

problémán gondolkodni, akkor számba vehetjük hogy mondjuk egy autónak vannak fõ szerelvényei, szerelvényei, melyek viszont alkatrészekbõl állnak. Ez végül is akárhány szintû kapcsolódás lehet. (Ez is homogén kapcsolat, hiszen alkatrészek viszonyulnak alkatrészekhez.) Legyen egy olyan táblánk, amiben egyszerûen leltár szerûen összeírjuk hogy egyáltalán mi minden gép, szerelvény, alkatrész szerû dolog van nálunk, és ez legyen az ALKATRÉSZEK egyed. Fontos, hogy ide minden bekerüljön Például egy autó esetén maga az autó is, ne csak a motor, dugattyú, stb. Konstruáljunk egy másik egyedet (FELÉPÜLÉS), amiben majd mindig két dolog összefüggését fogjuk egymás mellé felvenni, éspedig a MiAz (Mi Azonosító) oszlopba felírunk egy autót és mellé a MibõlAz (Mibõl Azonosító) oszlopba azt, hogy az mely szerelvénybõl áll és ezt addig folytatjuk, amíg az autó összes szerelvénye felsorolásra nem került. Ezután vesszük a fõ

szerelvényeket és így tovább addig, amíg minden olyan dolgot fel nem soroltunk, ami valamibõl áll. Az oszthatatlan alkatrészeket (pl csavar) nem vesszük fel a MiAz oszlopba, hiszen azok nem épülnek fel semmi más alkatrészbõl, de már biztosan beépültek valahova. Ha mégsem, akkor nem részei semmilyen gépnek vagy szerelvénynek. Nézzük konkrétan: ALKATRÉSZEK AlkatrészAz AlkatrészNév 1 Autó 2 Motor 3 Karosszéria 4 Alváz 5 Dugattyú 6 Gyertya FELÉPÜLÉS MiAz 1 1 1 2 2 -21- MibõlAz 2 2 2 5 6 Darab 1 1 1 4 4 A fenti kapcsolatrendszert nevezik családfa-, vagy homogén hálós-szerkezetnek. Az ALKATRÉSZEK egyedet az AlkatrészAz tulajdonság kapcsolja a FELÉPÜLÉS egyedhez a MiAz és a MibõlAz tulajdonságokon keresztül. A Darab tulajdonság megmondja, hogy az adott alkatrész-alkatrész viszonyban a beépülõ alkatrészek mennyisége mennyi. A fenti példába részletben az autó három fõ szerelvénybõl áll: motor, karosszéria, alváz. A

motor felépítése: 4 db. dugattyú és 4 db gyertya, stb Mindez lekövethetõ az azonosítók segítségével Ezt a szerkezetet családfa viszonynak is nevezik. Ha a FELÉPÜLÉS egyed MiAz oszlopán lépkedek végig, akkor arra kapok választ mi, mibõl épül fel (felépülés), ha pedig a MibõlAz oszlopán, akkor arra kapok választ, mi, mibe épül bele (beépülés). Így hát ez a megvalósítás alkalmas a kitûzött kérdések megválaszolására, sõt azt is megválaszolja, mogy mely alkatrészbõl hány darab van. Nézzük elvi nézetben is: A családfa szerkezet elvi megvalósítása A házastárs-viszony Érdekes probléma a házastársi viszonyok ábrázolása is. Az a feladat, hogy rögzítsük, ki kivel van házastársi viszonyban. Mi sem egyszerûbb, a meglévõ SZEMÉLY egyedünkhöz, melyben már megvannak a nevek, csapjunk hozzá még egy tulajdonságot, ami legyen a Házastársnév, és ide írjuk be a megfelelõ neveket: SZEMÉLY Személynév Feri Józsi Manci

Juci Ottó Házastársnév Manci Juci Feri Józsi Panni Ebben a megoldásban két alapvetõ hiba van: A párok kétszer szerepelnek (pl. Feri-Manci, Manci-Feri) és ha valakit ki kell törölni, akkor a párjánál is ki kell venni. Ez komoly kezelési gondokat jelent. Ennél messze jobb megoldás: SZEMÉLY SzemélyAz 1 2 3 4 5 Személynév Feri Józsi Manci Juci Ottó HÁZASTÁRS Férjkód Feleségkód 1 2 2 4 5 23 Mikor 1997 1998 1996 Ez vajon mitõl jobb? Attól, hogy nincs felesleges ismétlõdés, a kapcsolatokat tartalmazó HÁZASTÁRS egyedben azt is feljegyezhetjük, hogy ki mikor kötött házasságot, ennek következtében az elváltakat és újraházasodásokat is kezelni tudjuk, ami messze általánosabb megoldást tesz lehetõvé. Az is elõny, hogy a kapcsolatok sokkal tisztábban kezelhetõk Ha valaki kikerül a listáról, akkor világosan vissza lehet keresni, hogy melyik kapcsolatot kell megszüntetni. De ami ennél is fontosabb, hogy a feladatot a már az

elõbbi két példában -22- megismert kettõs egy-több kapcsolattal oldottuk meg, amit az adatbázis-kezelõk közvetlenül támogatnak. Elvi szinten: A házastárs viszonyt megvalósító adatmodell Összefoglalva megállapíthatjuk, hogy a homogén szerkezetek mindegyike megoldható a családfa szerkezettel. De más problémák is felmerülnek ezek kitöltése kapcsán Ez a szerepnevek problémája. Például házastársi viszonynál valamilyen módon meg kell akadályozni, hogy a férjkódhoz ne kerülhessen nõ. Ennek egy megoldása lehet, hogy a SZEMÉLY egyedben rögzítjük a felvitt személy nemét és a Férjkódba csak férfiak, a Feleségkódba csak nõk kerülhetnek. Ebben a példában a szerepnév a SZEMÉLY egyedbe felvett Neme tulajdonság. ADATBÁZISKEZELÉS Az adatkezelés • Adatkezelés az, amikor az adatokat bevisszük, módosítjuk, töröljük, képernyõn megjelenítjük, egy listán láthatóvá tesszük, rendezzük, szûrjük, másoljuk, mentjük stb.

Az ilyen mûveletek során nem születik új ismeret abban az értelemben, hogy csak a már meglévõ adatainkkal kezdünk valamit (megmutatjuk, tesszük-vesszük, stb.) Általánosan fogalmazva: Adatkezelési mûveletnek nevezzük azokat az adatokon végrehajtott (számítógépes) tevékenységeket, amelyek során új ismeret nem születik. (Halassy 1994, 117) Természeten egy felhasználónak új ismeretet jelenthet egy lista, hiszen azért kérdezi le mert kíváncsi rá, de az új ismeretet itt nem ebben az értelemben használjuk. Az új ismeret itt nem az, ha a meglévõ adatainkat valamilyen célszerû formában megmutatjuk, hanem ha a meglévõ adataink felhasználásával valamilyen új adat keletkezik (összeadjuk, megszámoljuk, szorzunk, osztunk stb.) Az adatfeldolgozás • Adatfeldolgozásnak azt nevezzük, ha a meglévõ adatainkkal olyasmit csinálunk, amibõl új adat, új ismeret keletkezik. Ez legtöbbször valamilyen egyszerû matematikai mûvelet: osztás,

összeadás, stb. Általánosan: Adatfeldolgozási mûveletnek hívjuk azokat az adatokon végrehajtott (számítógépes) tevékenységeket, amelyek során új ismeret születik. (Halassy 1994, 118) Az adatkezelés és az adatfeldolgozás között az a viszony, hogy adatkezelés elképzelhetõ adatfeldolgozás nélkül, de ez fordítva nem igaz. Arról van szó, hogy hiába akarnánk kiszámolni mennyi az ÁFA, ha nincsen letárolva a Nettó érték. Vannak olyan adatbázisok, ahol adatfeldolgozás egyáltalán nincs. Ezek a lexikon jellegû adatbázisok: szótárak, telefonkönyvek stb. Mindezek után a legfontosabb következtetésünk az kell legyen, hogy ha egy adatbázis jól szerkesztett, akkor abból bármi elõkereshetõ és kiszámolható, de ha ez nem így van, akkor -23- bármilyen feldolgozási képességekkel is rendelkezik, elképzeléseinket nem tudjuk megvalósítani. Az adatbázison alapuló információs rendszerekben az adatkezelésen van a hangsúly. A

származtatott adatok • Származtatott adatnak nevezzük az olyan adatokat, amik az alapadatokból kiszámolhatók. Ha lehet, mindig kerüljük azt, hogy a származtatott adatokat az adatbázisunkban tároljunk. Ez több szempontból is helytelen: ha valamit ki kell számolni, bízzuk a gépre. Bõven elég, ha ezek a származtatott adatok a listán jelennek meg Minek helyet pazarolni olyan adatnak, ami úgyis kiszámolható. A korszerû adatbázis-kezelõk fejlett adatfeldolgozási képességei szinte teljesen feleslegessé teszik a származtatott adatok tárolását. AZ ADATBÁZIS LÉNYEGE Az IPO szemlélet. • Az adatbázisok elõtti korszakban a fejlesztõk és a felhasználók az adatok számítógépes feldolgozását úgy képzelték el, hogy van bemenet (Input), a feldolgozás (Processing) és annak van egy eredménye a kimenet (Output). Ez – az ún IPO nézet – ma már elavult, sõt kifejezetten káros szemlélet. Ez azért van így, mert az adatokat kizárólag a

felhasználó szemszögébõl kezelik egy adott speciális feladatra. Az ilyen szemléletû rendszerek a bevitt adatokból akarnak közvetlenül eredményt nyerni és nem tárolnak hozzá szükséges más adatokat, így a géppel dolgozókat felesleges munkára kényszerítik, akiknek állandóan adatokat kell bevinni ahhoz, hogy valami kijöjjön a gépbõl ahelyett, hogy a gép azt letárolná és ezek után adná az eredményt. Az adatbázis szemlélet • A vezetõknek, fejlesztõknek, felhasználóknak tudomásul kellene venniük, hogy az adatok feldolgozásának van egy optimális lánca. Ez az adatok természetes, saját belsõ összefüggésein alapul. Nevezetesen azon, hogy mi mire épül, mi mi után következik szigorú rendben, ahhoz, hogy jó eredmény születhessék. Az adatbázis mindig egy alapadatbázist jelent, ahol minden, ami kell, rögzítve van úgy, hogy egyik ismeret a másiknak az alapja. Az adatbázis szemlélet a következõt mondja: Nem

bemenet-feldolgozás-kimenet, hanem korai bemenet és késleltetett kimenet. (Az adatbázis szemlélet olyan, mint az a bölcs, aki egy élet tapasztalatán megszerzett a tudás birtokában dönt, az IPO szemlélet pedig az a kapkodó ifjonc, aki nem mérlegel, a pillanatnyi benyomás alapján hozza meg döntéseit, mert nincsen birtokában a tudás és tapasztalat.) A korai bemenet azt jelenti, hogy minden adat tárolva van használható szerkezetben, és csak ezután, dolgozzuk fel azokat. Így a késleltetett kimenet eredményeként válnak hasznossá, segítik döntéseinket. Az adatbázis legfontosabb lényege a következõ: Az információs rendszereknek nem az adatfeldolgozás, hanem a gondosan meghatározott adatbázis szerkezeten alapuló adatkezelés a motorja. (Halassy 1994, 126) Tehát a számítógépet nem számoló, adatfeldolgozó szerkezetnek kell elképzelni, hanem az ismereteket adatbázis-szerû módon tároló, elsõsorban adatkezelési feladatokat ellátó

gépként. -24- Az adatbázis-tervezés problémái AZ ADATBÁZIS-MENEDZSELÉS Hány az adatbázis? Tekintsünk egy vállalatot, ahol ezt a szót teljesen általánosan minden olyan szervezetre értjük, ahol egyáltalán szükség lehet adatbázis-kezelésre. Amikor arról kezdenek beszélni, hogy valamilyen módon kezdjünk hozzá a feladat megvalósításához, általában több adatbázist emlegetnek. Például azt mondják hogy van a pénzügyi adatbázis, a munkaügyi adatbázis, a termelési adatbázis, a marketing adatbázis. Ilyenformán tehát egy vállalaton belül az adatbázis szót többes számban használják. Ez a hibák leges-legalapvetõbb gyökere A vezetõknek, felhasználóknak, fejlesztõknek meg kell érteniük a legalapvetõbb informatikai szabályt: Egy vállalaton belül adatbázis csak egy van! Egyszerûen arról van szó, hogyha egy igazgató, vagy bárki át akarja látni vállalata mûködését, és igényt tart arra, hogy kapott adatai a valós

helyzetet és összefüggéseket tükrözzék, akkor fel kell ismerni azt a nyilvánvaló dolgot, hogy: minden ismeret minden ismerettel összefügg! Mert egy vállalat részei mûködtetik az egész vállalatot és ezek bizony nem függetlenek egymástól még akkor sem, ha az ott dolgozók ezt nem veszik észre. A dolgokat bizony megfelelõ távlatból kell szemlélni ahhoz, hogy át tudjuk látni a rendszer teljes mûködését. Az, hogy egy vállalatnál az adatbázist többes számban emlegetik és használják, több oka is van: 1. A résszemléleti vakság: ami annyit jelent, hogy nem ismerik fel, hogy a részek hatnak az egészre és minden mindennel összefügg. 2. A már megvalósított adatbázisok önfenntartó állapota: ez egyszerûen azt jelenti, hogy az egyes részegységek fõnökei egymástól függetlenül kifejlesztették saját adatbázisaikat, amik között az égvilágon semmilyen kapcsolat nincs és nem is hozható létre, és bár felismerték, hogy egy csomó

adatot feleslegesen fel kell vinni, végig kell száguldozni valakinek az egész vállalaton ahhoz, ha valamit meg akarunk tudni, és ráadásul még nem is abban a formában kapjuk meg ami nekünk szükséges, hiszen azt még akkor ezekrõl a listákról majd össze kell szerkesztenünk. Arról nem is beszélve, hogy ez egyes részlegek másként értelmezik ezt vagy azt a statisztikai mutatót. Szóval hiába ismerték fel ezt a tökéletes káoszt, azt mondják: ha már ennyit pénzt belefektettünk rendszerint kifejlesztésébe, egyenlõre mûködtetnünk kell, mert nincsen anyagi forrásunk arra, hogy az egészet kezdjük elölrõl. 3. A nem megfelelõ fejlesztõeszközök kiválasztása: Az is elõfordul, hogy nem e legmegfelelõbb rendszert választjuk ki, és ennek képességei kényszerítik ránk a hibás szemléletet. Az, hogyha egy vállalatnál egy adatbázis helyett több van, az informatikailag pont akkora káosz, mintha valaki úgy akarna autót gyártani, hogy

elkészíti a különféle részegységeket anélkül, hogy törõdne azzal, vajon ezek mi módon fognak összeilleszkedni. -25- Az alkalmazási adatszabványok Abban az esetben, ha nem ismerték fel az egy adatbázis elvet, vagy egy vállalat olyan, hogy az adatok bevitele fizikailag más és más helyen történik, akkor ha nem vezetünk be ún. adatszabványokat, egy idõ múlva általános káosz lép életbe. A dolgozók egy részének az lesz a feladata, hogy ebben kiismerje magát ahelyett, hogy a dolgát végezné. Az adatszabványoknak számos fajtája van, ami közül a legfontosabbakat ismertetjük az alábbiakban. Azonosító-szabványok • Mint már azt megismertük, az azonosítók egyik feladata, hogy pontosan rátaláljunk egy egyed elõfordulásra, illetve a különbözõ egyedek közötti kapcsolat megteremthetõ legyen. Egy vállalaton belül szigorúan meg kell határozni, hogy a mozgó számlák, ügyiratok stb. azonosítása mindenhol egységes legyen Ha

erre nincsenek nemzetközi, országos szabványok, akkor egy belsõ jelölésrendszert kell kidolgozni. Kódszabványok • Itt olyan jellegû szabványosításról van szó, hogy ha mondjuk valamely mennyiség értéke 240, akkor azt mindenhol centiméterben értelmezzék. Vagy ha a munkaköröknek kódjaik vannak, akkor azok ugyanazok legyenek a munkaügyön, mint a pénzügyön. Írásszabványok • Abban az esetben, ha egy dolog rögzítése során nem határozzuk el annak egységes bevitelét, akkor például számlázáskor gyakran elõfordul, hogy egy cég neve többszörösen belekerül az azt tároló törzsadatokba és késõbb fogalmunk sincsen arról, hogy ez most ugyanaz a cég-e, és melyik a helyes neve. Nem is beszélve arról hogy a lekérdezés során a gép természetesen külön cégként fogja kezelni. Az adatszabványok alkalmazásának alapvetõ problémái • Az adatszabványok megalkotása egy dolog. Azt érvényesíttetni kell Elõször is ha kidolgoztuk,

akkor megfelelõ formában ki kell hirdetni. Ellenõrizni kell, hogy következetesen alkalmazzák-e, illetve meg kell vizsgálni, hogy vittek-e fel hibás adatokat, és azokat mi módon kéne kijavítani. A dolgok általában itt szoktak megbukni. ezt a sziszifuszi ellenõrzési és javítgatási munkát senki sem vállalja szívesen. Pedig ha ez a lépés kimarad, akkor semmit nem érnek az adatszabványok Fejlesztési adatszabványok A legáltalánosabb az, hogy a felhasználó leül a fejlesztõvel, elmondja hogy mit akar, és annak örül, ha az gyorsan felfogja a feladatot és hamar békén hagyja, nekiáll a feladatának. Nézzük, mire kell itt vigyázni. Legfõképpen arra, hogy ne hagyjuk, hogy a fejlesztõ más által nem érthetõ és zavaros magánszabványokat dolgozzon ki az adatbázis megvalósításánál. Arról van szó, hogy van olyan fejlesztõ, aki mániákusan ragaszkodik ahhoz a rögeszméhez, hogy egy mezõ nevében a tábla nevét is meg kell jeleníteni. És

mondjuk egy DOLGOZÓ nevû egyedben ugyanaz a dolog, mondjuk a név azonosítója D NévAz, a FIZETÉSIJEGYZÉK egyedben F NévAz és így tovább. Programozónk nagy munkát fektet ennek megvalósítására és azt hiszi, hogy ezzel áltáthatóbbá tette az adatbázist. A másik fejlesztõ idegenkedik az ilyen megkülönböztetésektõl, õ annyira liberális, hogy neki minden dátum jellegû adat, ha egyszer fordul elõ egy egyedben nemes egyszerûséggel Dátum. Annak ellenére hogy az egyik helyen születési dátum, a másik helyen pedig a számlázás kelte, stb. Sõt van olyan fejlesztõ, aki különbözõ korszakaiban más és más nézeteket vall errõl, ne adj isten egyik nap ezt, a másik nap azt. Ez elõbb felsorolt példák mind hibásak A helyes megoldás az, ha egy tulajdonság ami ugyanazt fejezi ki ez egyik egyedben mint a másiban, akkor azt ugyanazzal a névvel kell jelölni. Például a LakCím egy másik táblában is ugyanazt a LakCímet jelentse. -26- Ennek

a káosznak a megszüntetésére ún. meta szabványokat kell kidolgozni, és ezen elnevezések megkonstruálását nem a fejlesztõre, hanem egy közös megállapodásban elõre rögzíteni kell. Ugyanígy elõ kell írni, hogy a listák mit tartalmazzanak és milyen formátumúak legyenek. A tulajdonság nevek konstruálásakor a következõ alapszabályokat érdemes betartani (Sajnos a régebbi állomány- és adatbázis-kezelõk korlátozzák a tulajdonságnevek méretét, formáját, de a korszerû rendszereknél ez nem probléma): 1. A tulajdonságnév legyen egyszerre tömör, de ha lehet, tökéletesen fejezze ki azt, amit leír. Ez a két dolog ellentmond egymásnak, ezért meg kell találni az ésszerû kompromisszumot. Például ha egy számla keltezésének dátumáról van szó, akkor kimondottan rossz a Dátum szó, annak ellenére hogy dátum. Sokkal célszerûbb, ha kiírjuk: SzámlaKelte 2. Használjunk rövid, összetett szavakat, amiket írjunk egybe úgy, hogy a

kezdõbetûk nagyok legyenek. (Figyeljük meg, hogy a SzámlaKelte, SZÁMLAKELTE, számlakelte szavak közül az elsõ a legkönnyebben felfogható. Ennek oka, hogy a dinamikus betûképek foghatók fel leggyorsabban és a kevésbé fárasztók. A tipográfiában a dinamikának kiemelõ szerepe van. Nem véletlen, hogy a mondatok – amik gondolati egységek – nagybetûvel kezdõdnek és írásjellel záródnak.) Az egybe írás azért fontos, hogy használat során még véletlenül se tévesszük össze ezeket megjegyzésekkel, illetve programozás-technikailag jóval könnyebb kezelni az összefüggõ szavakat. 3. Döntsük el az összetett szavak sorrendjét, szerkezetét, formáját, és azt következetesen alkalmazzuk. Például ne forduljon elõ, hogy a diákok azonosítója az adatbázisban DiáAz, DiákAzonosító, AzDiákok stb. különbözõ formákat vesz fel, holott ugyanazt fejezi ki. 4. Ugyanazt a lényeget kifejezõ tulajdonságot ugyanolyan névvel lássuk el A rossz

tulajdonságnevek kapkodást, bizonytalankodást tükröznek, és növelik a káoszt. átgondolatlanságot, következetlenséget, Fejlesztési eljárásszabványok A legtöbb fejlesztõ nekiesik a munkának, egy szuszra megcsinálja, és minden nyom nélkül igyekszik elfelejteni az egészet. Ebbõl a módszerbõl a következõ problémák keletkeznek: Visszakereshetetlen, hogy mit akart a megrendelõ és mit a fejlesztõ, így elõbb vagy utóbb mindkettõjük energiáit lekötõ vitákba és emlékek kutatgatásába bonyolódnak. A hibajavítást mindig meg fogja elõzni egy viszonylag hosszadalmas elemzési folyamat, amivel a fejlesztõnek elõbb azt kell újra kitalálni, hogy mit és hogyan csinált, és teljesen bizonytalan, hogy ha valamit megváltoztat, az vajon nem ront el valami mást. A dokumentálatlan és terv nélküli rendszerek átvehetetlenek és a felhasználók ezáltal ki lesznek szolgáltatva a fejlesztõ személyének. Akármilyen hihetetlen, de sokkal hamarabb

készen van valami, he elõbb tudjuk, hogy mit akarunk csinálni és azt nem közben találjuk ki. -27- A munkafolyamatokat ilyen szemmel vizsgálva hamar rájöttek, hogy ki kell dolgozni, sõt szabványosítani (SSADM) kell különféle hatékony és megfelelõ fejlesztõi módszereket. Ezek támogatására projekt tervezõ szoftverek is születtek. Menedzselési szabványok Az adatbázisok mûködtetése során rengeteg változtatást kell végrehajtani. Nem járunk el jól, ha ebbe a folyamatba kizárólag csak a fejlesztõk látnak bele. Pontosan ki kell dolgozni, hogy ki, milyen formában mit tegyen. A megrendelõnek át kell látni a változtatásokat, azt dokumentálni kell, és szigorúan meg kell vizsgálni, hogy ezek nem okoznak e más problémákat. Szervezeti feltételek Az adat erõforrás, értéke annak a munkának az értékével egyenlõ, amivel azokat meg lehet szerezni, amihez hozzáadódik az általa termelt haszon és pótlásának összes költsége. Ma

már egyre többen látják, hogy az adatokra is kell vigyázni, õrizni, karbantartani stb. ugyanúgy, mint valamely tárgyi dolgot, ami ezt igényli. Egy vállalatnál meg kell teremteni ennek a szervezeti feltételeit, vagyis külön foglalkoztatni kell olyan embereket, akiknek ez a dolguk. (A felhasználók általában minderre legtöbbször nagy adatvesztési katasztrófák, vagy elviselhetetlen káosz bekövetkezte után szoktak rájönni annak ellenére, hogy erre a fejlesztõk figyelmeztetik õket.) Nézzünk néhány célszerû funkciót és az ezekhez tartozó feladatköröket Adatgazda, vagy adatadminisztrátor • Alapvetõ feladatai: 1. Ismeri az adatbázis szerkezetét. 2 Tisztában van az adatszabványokkal és annak betartását folyamatosan ellenõrzi 3. Tudja, hogy a felhasználók az adatokat milyen eszközökön érik el és ügyel arra, hogy ezek ne okozhassák azok sérülését. 4 Ismeri a bizonylatok formáját és a bevitel módját, így kezelni tudja az

ezekkel kapcsolatos problémákat, változtatási javaslatokat. 5 Összehangolja a felhasználók és a fejlesztõk igényeit és feladatait. Szabványcsoport • Õk foglalkoznak azzal, hogy a vállalaton belüli szabványokat kidolgozzák, azok érvényesülését figyelemmel kísérjék. Minõségellenõrzési rendszereket, szabványokat dolgoznak ki, és ezeket megfelelõen illesztik a rendszerbe úgy, hogy azok hatékonyan érvényesülhessenek. Adott esetben tesztelési feladatokat is ellátnak Adatbázis- vagy rendszergazda • A rendszergazda felelõs az adatbázis fizikai épségéért, annak integritását ellenõrzõ programok rendszeres lefuttatásáért. Õ állítja be a felhasználók hozzáférési jogait. Megoldja a kisebb nagyobb egyszeri igényeket Új gépek, újabb operációs rendszer cseréjénél az átmentést bonyolítja. Õ felelõs azért, hogy az adatok megfelelõ módon archiválva legyenek mindennemû katasztrófa utáni újraindításhoz. Rendszeres

vírusellenõrzést végez. Mindezek a funkciók akkor érvényesülnek, ha az ezeket betöltõ szakemberek megfelelõ hatalmat is kapnak a kezükbe ezek érvényesítésére. Nagyon fontos, hogy egy vállalatnál létezzen egy belsõ mûködtetési szabályzat, amiben konkréten rögzítésre kerülnek a rendszabályok, hatáskörök, szankciók. Ezek biztosíthatják azt a technológiai fegyelmet, ami nélkül az adatok nem lesznek biztonságban. -28- AZ ADATBÁZIS-TERVEZÉS FÕBB LÉPÉSEI Ebben a fejezetben azt vizsgáljuk, hogy az adatbázis tervezésében résztvevõ szereplõk (fejlesztõ, felhasználó, fõnök) felismerje saját szerepét és tennivalóit annak érdekében, hogy az ismeretbõl információ születhessen az adatbázisban rögzített adatokból. Általános problémák A helyes arány • Ha egy adatbázist jól akarunk elkészíteni, akkor abban 60%-os szerepet kell hogy játsszon az adatmodell megtervezése (az adatbázis elvi szintje), 30% az adatok

valósághû tárolásának kezelése, 10% pedig az egyéb problémák megoldása. Ez fontossági és nem idõbeli elosztást jelent természetesen, hiszen egy fejlesztési vagy tesztelési szakasz rendkívül idõigényes procedúra. Szerepvakságok • Az adatbázis megszületésének folyamatában résztvevõk (fejlesztõ, felhasználó, fõnök) hibát követnek el akkor – és ezzel megakadályozzák, vagy megnehezítik az adatbázis megszületését –, ha nem ismerik fel, vagy nincsenek tisztában saját szerepükkel. Az ilyesmit azért nevezzük szerepvakságnak, mert a különbözõ poszton lévõ emberek sokszor félreértelmezik, vagy nem tudják, vagy mást képzelnek arról, mi is a dolguk tulajdonképpen. Ez azért vakság, mert az ember önmagát olyannak látja, amilyennek saját szerepét elképzeli. És vakság azért, mert egy feladat megoldásában résztvevõ, különbözõ feladatkörû emberek rendkívül nehezen képesek belelátni a másik problémáiba.

Nézzük ezeket: A fejlesztõ szintvaksággal küzd, hiszen õneki végül is egy mûködõ valami lerakása, és nem egy adatmodell létrehozása. Mégis meg kell birkózni a azzal a ténnyel, hogy jó adatmodell nélkül nem lesz képes elkészíteni azt, ami a dolga. A felhasználó a nézetvakság állapotában él, ugyanis számára az a fontos, hogy milyen adatokat fog rögzíteni, és ha megnyom egy gombot, milyen listát kap. Ennek két káros következménye van: a fejlesztõvel szembeni maximalitás, ami figyelmen kívül hagyja a technikai eszközök korlátait, és szûk célokat kiszolgáló torz adatbázisok születnek. A vezetõ szerepvakságban szenved. Általában azt hiszi, hogy feladata véget ér olyasmikkel, hogy beosztottjait utasította egy feladat végrehajtására, vállalatának elõnyös szerzõdést köt, vagy elveszik az eszközök kiválasztásának, a feladat kitûzésének vagy megvalósításának részleteiben. Nagy hibát követ el azonban, ha nem

dolgozza, vagy nem dolgoztatja ki a pontos feladatköröket, szabványokat, minõségellenõrzési rendszert, mûködési szabályzatot. Mit lehet tenni az ilyen tudathasadásos állapot felszámolásáért? Meg kell magyarázni, hogy kezdetben van az ismeret, amibõl adatok lesznek, amik egy adatbázisban kapnak helyet, melybõl megszülethet az információ. Abban az esetben, ha kizárólag saját rész szerepeinkkel törõdünk és nem azon munkálkodunk hogy ez az adatbázis jó legyen, akkor az informatikai káosz állapotába jutunk. Tisztában vagyunk avval, hogy a szerepvakságok gyökere nem csupán ennek az ismereteknek a hiánya, sõt leginkább az emberi butaság, hozzánemértés, tapasztalatlanság, gyakorlatlanság. Ennek ellenére törekedni kell ezek elhárítására és ügyesen a jó irányba kell terelni a folyamatokat. A tervezés fõbb lépései Az alapfogalmak tisztázása, az egyedek elkülönítése • Elõször tisztázni kell azt, hogy milyen alapfogalmak

azok, amik adatait fel kívánjuk dolgozni. Ezek a fõ lényegek lesznek majd azok az egyedek, amik adatbázisunk alapvetõ szerkezetét kapcsolataikkal együtt megadják. ezeknek olyan nevet kell adni, amik kifejezõek, lényegretörõek. Azt is tisztázni kell, hogy az -29- egyedek elõfordulásaikban milyen értékeket tulajdonságokból mit hogyan kell kiszámítani. vehetnek fel, az ott szereplõ fõbb A fogalmak rögzítése, egyeztetés, ábrázolás rögzítése • Az így felmerült fogalmakat, számítási módokat írásban, táblázatos és mondatszerû módon rögzítjük, majd széles körûen egyeztetjük. A visszajelzések alapján ezeket korrigáljuk és finomítjuk elnevezéseinket Pontosítjuk, hogy milyen adatot mi módon kell ábrázolni, rögzíteni, mi azok értéktartománya, várható hossza, stb. Rögzítjük milyen kódokat és azonosítókat kell használunk Az adatmodell megalkotása • Az addigi ismereteink alapján megalkotjuk az adatmodellt

(az adatbázis elvi szintje), amiben fel kell ismernünk az adatszerkezeteket és eszerint kell létrehozni a közöttük lévõ kapcsolatokat. Ezt le kell képeznünk az adatbázis logikai tervére, ami lényegében a táblák létrehozását és kapcsolataik megalkotását jelenti. A terv átgondolása a leendõ listák alapján • Gyûjtsük össze milyen listákra van szükségünk, és nézzük meg, hogy adatbázisunk ezeket ki tudja-e szolgálni tartalmi és formai tekintetben. Korrigáljuk az elvi és ábrázolási hibákat. Nagyon fontos megérteni, hogy ne a listák szerkezete, igényei határozzák meg, hogy milyen legyen az adatmodell. Egy fogalmilag helyes adatmodellbõl induljunk ki, és ezután nézzük meg azt, hogy az képes lesz-e így kiszolgálni az igényeket. Ha fordítva gondolkodunk, akkor a felhasználó szerepvakságát kielégítõ torz adatbázis születik, ami nem tükrözi helyesen a valóságot. Részletes validálási terv • Az egyeztetett és

kidolgozott logikai terv alapján pontosan meghatározzuk az adatok beviteli maszkjait és validálási tervét, hogy a bevitel során ne kerülhessenek rossz adatok. A rendszer megvalósítása, teszt adatok • Az adatbázis terv alapján megalkotjuk a rendszer beviteleit, lekérdezéseit és ûrlapjait. Az adatbázist feltöltjük teszt adatokkal, és alaposan kipróbáljuk. Minta nyomtatványokat készítünk és azokat egyeztetjük a felhasználóval A felmerülõ hibákat korrigáljuk. TIPIKUS ADATMODELL HIBÁK Nyílt logikai átfedés Ha egy tulajdonságot, mondjuk LakCím több egyedbe is felveszünk és mindegyikben ugyanazt jelenti, akkor ezt az adatot többször fel kell vinnünk. Ez a nyílt logikai átfedés Ez egyrészt a helyet foglalja, másrészt karbantartási problémákkal is jár. Ha az egyik helyen ki kell javítani, akkor a többinél is át kell vezetni. Ezen problémák miatt kerüljük ezt a megoldást, bár használata nem jelent elvi hibát. Azt kell jól

meggondolnunk, hogy utólag sok problémát okoz Nem beszélünk nyílt logikai átfedésrõl akkor, hogy ha két vagy több egyedben ugyanolyan nevû tulajdonság létezik, de az egyikben azonosító szerepû, a többiben pedig kapcsoló. Tipikus példája ennek, a DiákAz, amely a diákokat azonosító szám, ami a DIÁKOK egyedben elsõdleges kulcs, a többi egyedben, ahol megjelenik kapcsoló szerepû. Ha jól belegondolunk az azonosítók használata segítségével küszöbölhetjük ki a nyílt logikai átfedés által okozott karbantartási hibákat. Ennél a példánál maradva a diákok neve csak egyszer szerepel, és ha megváltozik, akkor ez minden listán megváltozik. A nyílt logikai átfedés mivel adatismétlõdéssel jár, redundanciát jelent. -30- Látszólagos logikai átfedés Ha egy tulajdonság, mondjuk LakCím több egyedben is szerepel, de mindegyikben más lakcímet jelent (például a DIÁKOK egyedben a diákok, a TANÁROK egyedben a tanárok

lakcímét), akkor látszólagos logikai átfedésrõl beszélünk. Itt a problémát az egyértelmûség megsértése okozza. Elsõ látásra ez nem jelent problémát, de nagyon gyakran kerülhetünk abba a helyzetbe, hogy ezek a tulajdonságok egyszerre kezelendõk. Például az elõzõ példánál maradva mi van, ha egy listán egyszerre kell szerepeltetni a diákok és osztályfõnökük lakcímét. Nem az a probléma, hogy a rendszer ne tudná kezelni az eltérõ tábla azonos mezõit, hanem inkább arról, hogy bizonyos esetekben az ilyen kavarodások végzetes galibákat okozhatnak. Az adatmodellbõl mindenképpen ki kell küszöbölnünk a látszólagos logikai átfedéseket. Ennek egyszerûen az a módja, hogy a tulajdonságok neveit kifejezõbben adjuk meg. Például: DiákokLakCíme és TanárokLakCíme. Ez a megoldás nem azt jelenti, hogy DIÁKOK vagy a TANÁROK egyedben minden tulajdonság mellé mániákusan oda kéne írni a Diákok vagy Tanárok elõtagot, hanem

csakis és kizárólag az ismétlõdõ és összekeverhetõ tulajdonságoknál kell mindezeket jól meggondolni. A látszólagos logikai átfedést, mivel összetéveszthetõségrõl van szó, homonímának is nevezhetjük. Rejtett logikai átfedés Ha egy tulajdonság két egyedben ugyanazt fejezi ki, de más névvel illetjük, pl. a DIÁKOK egyedben a DiákAz diák azonosító a SPORTOLÁS egyedben DiákAzonosító néven kapcsoló szerepkörben található, akkor rejtett logikai átfedésrõl beszélünk. A rejtett logikai hibák nagymértékben megnehezítik az adatmodell áttekintését, áttekinthetetlenséget és káoszt okoz. ezek a fajta hibák általában a következetlen fogalomalkotás hibájából származnak és leginkább azért, mert nem szoktunk emlékezni vagy véletlenül eltévesztjük, hogy ugyanazt a dolgot a másik helyen hogyan is hívtuk pontosan. Kis figyelemmel, plusz egyeztetéssel mindez elkerülhetõ. Az adatmodellbõl mindenképpen ki kell küszöbölni

a rejtett logikai átfedéseket. Különösen azért, mert ezek nyílt logikai átfedések feltárására is rámutatnak. Ha az elõzõ példát tekintjük, akkor annak kiküszöbölése nem nyílt logikai átfedést hoz a felszínre. A rejtett logikai átfedés nem a nyílt logikai átfedés speciális esete. A nyílt logikai átfedés két azonos dolog más névvel való létezését jelenti, ezért szinonímának is nevezzük. A logikai átfedés hiánya Abban az esetben ha két egyed nem kapcsolható – bár erre szükség lenne –, mert nem hoztunk létre az ehhez szükséges kapcsoló mezõket, akkor a logikai átfedés hiányáról beszélünk. A kapcsolatok hiánya visszakereshetõségi problémákat okoz és késõbb rendkívül sok fejtörést okozhat ezek kiküszöbölése. Egy adatmodellben elképzelhetetlen, hogy kapcsolati hiányosságok legyenek az egymással összefüggõ egyedek között! A kapcsolat megvalósításának hiányát idegen szóval inkonnektivitásnak

nevezik. Fizikai átfedés Errõl a problémáról akkor beszélünk, ha egy egyedben vannak olyan tulajdonságok, vagy tulajdonság, aminek elõfordulásaiban ezek többször megismétlõdnek. Azért illetjük ezt a -31- jelenséget a fizikai szóval, mert a konkrét adatok ismétlõdését akarjuk ezzel érzékeltetni. Például ha valaki a DIÁKOK egyedben szerepelteti az Osztály és OsztáFõnök tulajdonságokat, akkor sok diák bevitelekor elõfordul, hogy ugyanazt kell beírni, hiszen ugyanabba az osztályba többen járnak. Természetesen egy kapcsoló szerepû tulajdonság értékeinek ismétlõdése nem tekinthetõ fizikai átfedésnek. Egy fogalmi adatmodell nem lehet olyan szerkezetû, ami fizikai átfedést okoz. -32- Ízelítõ az SQL nyelvbõl Az IBM cég az 1970-es évek közepén kísérletet tett egy strukturált lekérdezõ nyelv (Structured Query Language) kifejlesztésére, ami olyan jól sikerült, hogy mára ez már szabvánnyá vált: ANSI SQL. Ez a

nyelv könnyen elsajátítható, hiszen rendkívül kevés alapszót tartalmaz, és azok szerkezete nagyon hasonlít az élõ nyelvi mondatokhoz. Az SQL-nek ma nagyon sok változata van, de szinte minden komolyabb adatbázis-kezelõ használja, vagy lehetõséget nyújt használatára azon túl, hogy saját programnyelvvel rendelkezik. Az alábbiakban egy SQL kulcsszó (utasítás) részletes leírása segítségével érzékeltetjük-e nyelv mûködését a teljesség igénye nélkül. A SELECT kulcsszó arra szolgál, hogy egy vagy több táblából valamilyen feltétel vagy feltételeknek megfelelõ rekordok adott mezõit emeljük ki. A parancs általános alakja: SELECT [DISTINCT|ALL]{*|<érték>[,<érték>.]} FROM <táblahivatkozás> [,<táblahivatkozás>.] [WHERE <keresési feltétel>] [GROUP BY mezõ [COLLATE egybevetés][,mezõ [COLLATE egybevetés].] [HAVING <keresési feltétel>] [UNION <választási kifejezés>] [ORDER BY <sorrend

lista>] DISTINCT, ALL záradék: A SELECT-et mindig egy oszloplistának kell követnie: {*|<érték>[,<érték>.]} ahol ha csillagot adunk meg akkor az összes, egyébként a megadott mezõk fognak szerepelni az eredmény táblában. A DISTINC használatakor csak azok a rekordok kerülnek az eredmény táblába, amelyeknél az oszlop listának megfelelõ értékek megegyeznek. ALL esetén pedig az összes FROM záradék: Itt adjuk meg, hogy mely táblákból vegye az oszlopokat. WHERE záradék: Itt adjuk meg azt a logikai kifejezést, ami a megfelelõ rekordokat szûri ki. Ezen kívül itt szerepelhet további SELECT is akkor, ha egy másik adattáblából is szükséges információ a feltételrendszerhez, illetve a kapcsolatokat is itt kell megadnunk. -33- Egy példa az ACCESS adatbázis-kezelõvel ALAPFOGALMAK Hivatkozási integritás Amikor egy korszerû adatbázis-kezelõben a táblák között létrehozzuk a kapcsolatokat, akkor ezek nem pusztán a

kapcsolatok lehetõségét hordozzák, hanem ezek segítségével azt is megoldhatjuk, hogy a rendszer ne engedjen olyan adatot rögzíteni, ami helytelen. Példaként ha a DIÁKOK és a MEGYÉK egyedek közötti kapcsolatban hiba lenne a diákok táblába olyan megyét tárolni, ami még nincsen a megyék között, vagy az is helytelen lenne, hogy ha megengedne olyan megyét törölni, amely megyébõl már jött diák. Arról van szó tehát, hogyha létrehozunk egy kapcsolatot, akkor utasíthatjuk az adatbázis-kezelõt arra, hogy figyelje az ott lévõ értékeket, azt, hogy ezek a kapcsolatok érvényesek-e és nem enged olyan adatot törölni, ami következtében a kapcsolat megsérülne. Amikor ez így van, akkor azt mondjuk, hogy a hivatkozási integritás van érvényben. Az MS ACCESS adatbázis-kezelõben a hivatkozási integritást a következõ feltételek mellett lehet érvényesíteni két tábla között: Az egy oldalon álló ún. elsõdleges tábla (pl a DIÁKOK –

MEGYÉK kapcsolatában a Megyék tábla) kapcsolatban szereplõ mezõjének (pl. MegyeAz) elsõdleges kulcsnak kell lennie. A kapcsolt mezõknek azonos típusúaknak kell lenniük. Kivétel ez alól, hogyha az azonosító Számláló típusú, akkor a másik táblában szereplõ kapcsoló mezõnek Hosszú egésznek kell lennie, amely mezõk szerkezetileg azonos típusúak. Ha a kapcsolatban lévõ táblák csatoltak, akkor egyrészt ACCESS tábláknak kell lenniük és nem tartozhatnának más adatbázishoz. Ha már érvényesítettük a hivatkozási integritás két tábla között, akkor: Az elsõdleges táblában (pl. a DIÁKOK – MEGYÉK kapcsolatában a Megyék tábla) tetszõlegesen vehetünk fel új adatokat (pl. új megyéket), de a kapcsolt táblába (pl Diákok) csak olyan megye kerülhet, ami már az elsõdleges táblában már szerepel. Ellenkezõ esetben a hivatkozási integritást sértenénk meg. Nem lehet az elsõdleges tábla rekordját törölni akkor, ha egy

kapcsolt táblában a megfelelõ rekordok léteznek. Pl pl a DIÁKOK – MEGYÉK kapcsolatában a Megyék táblából nem törölhetünk olyan megyét, amelybõl már jöttek tanulók. A hivatkozási integritást 1:N és 1:1 kapcsolatok létrehozásánál érvényesíthetjük, amit a kapcsolat szerkesztõ ablakban lehet létrehozni úgy, hogy az 1 oldalon lévõ elsõdleges kulcsról indulva a lenyomott egeret áthúzzuk a másik tábla megfelelõ mezõjére és annak gombját -34- elengedjük. ezután megjelenik a kapcsolatszerkesztõ párbeszédablak, melyben a megfelelõ beállítást kell eszközölni. Kaszkádolt törlés és frissítés Az olyan kapcsolatoknál, ahol a hivatkozási integritás érvényesítését adtuk meg, beállíthatjuk azt is, hogy ha az elsõdleges táblából törlünk egy rekordot, akkor a másodlagos táblából törlõdjenek mindazon sorok, amik a két táblában közösek voltak. Ezt kaszkádolt törlésnek nevezzük. Ez a lehetõség nem õrzi,

hanem sebészi módon érvényesíti a hivatkozási integritást Vajon mikor van ilyenre szükség? Pl. gondoljunk arra, hogyha az OSZTÁLYOK – DIÁKOK 1:N kapcsolatban jövõre elmennek a negyedikesek, akkor úgy a legegyszerûbb az õ törlésük, hogy ha beállítjuk a kaszkádolt törlést, és ha kitörlünk egy osztályt az Osztályok táblából, akkor a Diákok táblából törlõdnek mindazon diákok, akik ugyanezen osztályba jártak. Hasonló dolgot biztosít a kaszkádotl frissítés lehetõsége, miszerint ha egy kapcsolatban az elsõdleges tábla kapcsolatban szereplõ mezõjének értékét megváltoztatjuk, akkor az össze olyan érték erre az új értékre változik, amely a másodlagos táblában szerepel. Igen jól jön ez akkor, hogyha pl. az OSZTÁLYOK – DIÁKOK kapcsolatában a kapcsolatot létrehozó mezõk konkrétan az osztály nevek (és nem kódok), és a minisztérium rendeletére a NAT szellemében az évfolyamok számozása megváltozik, akkor elég

az értékeket az Osztályok táblában átírni, és ezek mindenütt módosulnak a Diákok táblában. Illesztések Ha többtáblás lekérdezéseket hozunk létre, akkor a táblákat illesztenünk kell egymáshoz. Ezt az illesztést legtöbbször a rendszer automatikusan elvégzi helyettünk. Egyrészt illesztés jön létre akkor, ha már a kapcsolattervezõben létrehoztunk a táblák között kapcsolatot, másrészt ha azonos nevû és típusú mezõk kerülnek két táblában a lekérdezés létrehozásakor egymás mellé. Az MS ACCESS háromféle illesztés típust ismer: Szoros, laza és önillesztés Szoros illesztés • Ha két tábla szoros illesztéssel kapcsolódik egymáshoz, akkor azok a rekordok kerülnek egy közös táblába eredményképpen, amelyekben a kapcsolódó mezõk értékei azonosak. Laza illesztés • Két táblát tekintve beszélhetünk bal és jobb oldali laza illesztésrõl, melyek lényege ugyanaz, csak egyszer balról, másszor jobbról kiindulva.

A két táblából keletkezõ eredménytábla olyan, hogy az egyik tábla minden rekordját tartalmazza, míg a másikból csak azokat, melyek kapcsoló mezõ értékei azonosak az egyik tábla megfelelõ értékeivel. Ha az elõbbi mondatban szereplõ egyik tábla a kapcsolatszerkesztõben a baloldali akkor bal-, ha jobboldali akkor jobboldali laza illesztésrõl beszélünk. Például ha egymás mellé tesszük a DIÁKOK – MEGYÉK táblákat és köztük jobboldali laza illesztést hozunk létre, akkor az eredmény táblában minden megye megjelenik annak ellenére, hogy lesznek olyanok, melyekhez nem tarozik diák. Baloldali laza illesztés esetén pedig egy esetleges hivatkozási integritás hiányában elõálló hibás kitöltés esetén kiszûrhetjük azokat a diákokat, akikhez olyan megyéket írtunk be, amik nem léteznek a megye táblában, ugyanis ebben a listában minden diák megjelenik. Még azok is, melyekhez a megye táblából nem tartozik megye Önillesztés •

Önillesztésnek nevezzük az olyan lekérdezést, amelyben ugyanaz a tábla kétszer szerepel és önmagával van illesztve két azonos típusú és lényegû mezõ által. Ennek megvalósítása lehet szoros és laza illesztés. Ezeket speciállis homogén kapcsolatok lekérdezésénél alkalmazzuk. -35- Szoros illesztés: az olyan rekordok, melyek mindkét táblában azonos MegyeAz értéket tartalmaznak. Baloldali laza illesztés: A Diákok tábla minden rekordja, és a Megye táblából azok, melyeknél azonosak a MegyeAz értékei. (Kideríthetjük, hogy mely helyre írtunk nem létezõ megyét a Diákok táblába.) Jobboldali laza illesztés: A megyék tábla minden rekordja, és a Diákokból azok, melyeknél a MegyeAz értéke szerepel a Megyék táblában. (Kideríthetjük, hogy mely megyékbõl nem jött diák.) GYAKORLATI PÉLDA ADATBÁZIS TERVRE Tervezzünk megy egy olyan adatbázist, ami a diákok adatait rögzíti abból a célból, hogy a legfontosabb

statisztikai kérdésre választ tudjunk kapni ami egy iskolában felmerül. (Megjegyezzük, hogy ez a példa meglehetõsen korlátolt a példa mivolta miatt, hiszen nem kezeli a diákok jegyeit csak az átlagokat, a tanárokat egyáltalán nem kezeli, nem foglalkozik az órarend problémájával, stb. Ennek ellenére azért tekinthetjük mégis jónak, mert ezek tekintetében anélkül bõvíthetõ hogy szét kéne verni az eddigi struktúrát, tehát megfelelõen nyitott.) Az egyedek kiválasztása Az egyedek kiválasztásánál lényegében három gondolat vezet: 1. Tartalmukból következõen külön egyednek kell lennie: OSZTÁLYOK, DIÁKOK, TANÁROK 2. A lekérdezhetõség és a késõbbi bõvíthetõség miatt: SPORTOK, TEREM, SZAKOK, POSZTOK 3. A kapcsolatok miatt létrejövõ járulékos egyedek, melyek ezen túl fontos adatokat is tárolnak: A diák-sport több-több kapcsolat miatt: SPORTOLÁS, a diákok-posztok homogén adatszerkezet miatt: a FELÉPÍTÉS. (Meg kell

jegyeznünk, hogy például a sportolásnál bevezethettünk volna még két egyedet: EGYESÜLET, SZINT (milyen szinten sportol). Addig azonban, amíg ezeket nem kívánjuk lekérdezni, mert ezeket az adatokat nem tartjuk nagyon fontosnak, megfelelõnek gondolhatjuk ezt a megoldást, bár kényelmetlen a bevitelnél az, hogy például állandóan be kell írnunk: Újszászi SE ahelyett, hogy külön tárolnánk ezeket a szavakat. Ez a megoldás azért teszi nehézzé – és néha szinte lehetetlenné – a lekérdezést, mert ha egykét szót rosszul, vagy a szinonímájával írtunk be, akkor a listákon ugyanannak a dolognak külön csoportjai keletkezhetnek. Ha bizonytalanok vagyunk abban, hogy egy adat tárolásakor bevezessünk-e új egyedet, akkor döntsön az, hogy akarunk-e ilyen szempontú lekérdezést, -36- vagy nem. Ha utólag mégis jó lett volna, akkor struktúramódosítással, táblakészítõ és módosító lekérdezésekkel könnyedén kialakíthatjuk a

kívánt egyedet és azonosítós csatolását.) Kapcsolatok A minta adatbázis kapcsolatai és mezõi Amikor azon gondolkozunk, milyen egyedekre van szükség, ezzel szinte párhuzamosan látni kell, hogy azok között milyen kapcsolatnak kell lennie. Az esetek 90 % százalékában ezek a tanult sémákkal megoldhatók. Itt sem merült fel komolyabb probléma Mint látjuk a leggyakoribb az egy-több, majd a több-több kapcsolat, de gyakori a homogén adatszerkezet is. A kapcsolatok létrehozásakor szinte mindig a hivatkozási integritást érvényesítsük, mert ez biztosítja az adatbázis tartalmi egységét, illetve használjuk ki ennek egyéb lehetõségeit is. Példánkban gondolnunk kell arra, mi lesz egy következõ tanévben. Egyrészt ki kell törölnünk az összes eltávozó tanulót, másrészt az osztályok lépnek egyet felfelé, valamint új osztályok jönnek. E három probléma közül az elsõt kiválóan megoldhatjuk azzal , hogy az OSZTÁLYDIÁKOK,

DIÁKOK-FELÉPÍTÉS és DIÁKOK-SPORTOLÁS kapcsolatoknál kaszkádolt törlést állítunk be, ugyanis elég kitörölni az osztályok táblából egy osztályt, és ezzel minden olyan tanuló automatikusan el fog tûnni, amelyik ehhez tartozott minden olyan helyrõl, amihez köze volt (Diákok, Szervezetek, Sportolás táblákból). Vigyázzunk azonban, hogy ez egy igen veszélyes lehetõség is egyben! Ezért helyes lehet az a megoldás, hogy a kaszkádolt törlést csak akkor érvényesítjük amikor új évet nyitunk, és e mûvelet után újra letiltjuk. Az átállásnak a másik két problémája könnyedén megoldódik azzal, hogy az osztályokat egyszerûen át kell nevezni az Osztályok táblában, valamint új elsõ osztályokat veszünk fel. Ezen adatbázis legbonyolultabb kapcsolata a diákszervezetek felépítését megvalósító homogén adatszerkezet, amit az alkatrész problémához hasonlóan oldhatunk meg. Ennél a megoldásnál a könnyû kezelhetõség miatt

néhány trükköt alkalmaztunk. Például a posztok táblában bevezettünk egy Szervezet nevû logikai mezõt, amiben azt regisztráljuk, hogy egy poszt mos szervezetet, vagy beosztást takar-e. Például az újságíró poszt, de a Diákújság az már szervezet. (Mint tudjuk, ennél a megoldásnál mind a beosztások, mind a szervezetek neveinek együtt kell szerepelniük!) Ezzel megkönnyíthetjük ezen dolgok bevitelét. A másik probléma a listákon való sorrend, nevezetesen hogy azok ne a névsor, hanem a szervezet hierarchiájának megfelelõek legyenek. Ezért miközben a szervezeteket visszük fel, egy Hierarchia nevû numerikus mezõbe beírunk egy számot, ami megmondja ki a fõnök, alfõnök, stb. Minél kisebb ez a szám, annál nagyobb valakinek a rangja Nagy kérdés, hogy lehetne-e a -37- posztokhoz közvetlenül hierarchiát rendelni, mert kényelmesebb, sõt automatikussá válna a dolog. A problémán töprengve azonban a rugalmasság miatt inkább ezen

megoldás mellett döntöttünk, ugyanis ha mondjuk a posztok közé beveszünk olyan szervezetfüggetlen szavakat mint: tag, vezetõ, tanácsadó stb. akkor ezek a különbözõ szervezetekben nem biztos hogy azonos hierarchiával fognak rendelkezni. Fontos alapszabály, hogy egy adatbázis rugalmassága sokkal fontosabb mint a bevitel kényelme, mert az egyben a jóságát, használhatóságát is jelenti. És ne feledjük, bármennyire elegáns egy ötlet, el kell tûnõdni azon, vajon nem szûkíti-e le a lehetõségeinket! Kezdõ tervezõk gyakran esnek abba a hibába, hogy nincs erejük zseniális – vagy annak vélt – ötleteiket alapos végiggondolására annak minden következményével, és ha látják is azok hibáit, inkább ragaszkodnak hozzá. Ennek leggyakrabban az utólagos problémák miatti keserves kínlódás a következménye. A profik tudják, hogy nem az ötleteinket, hanem a feladatot kell megvalósítani! Az egyedek tulajdonságértékei (mezõk) Annyi

mezõre van szükség, amellyel az adott egyedet megfelelõen le tudjuk írni. Foglaljunk össze néhány alapszabályt, amit ha automatikusan betartunk, akkor nagyon rossz nem jöhet ki a dologból: Az az igazán jó mezõ, ami nincs • Felesleges, vagy feleslegesen ismétlõdõ adatot ne tároljunk. Például felesleges adat minden számított mezõ Ilyen lenne az osztályok táblában mondjuk az OszályÁtlag, ugyanis ezt a lekérdezések úgyis ki fogják számolni és szó sincs arról, hogy ezt nekünk kéne kiszámolni, s ami még rosszabb, feleslegesen tárolni. A Diákok tábla Átlag mezõje igaz hogy számított adat, de a példa egyszerûsége miatt bemenõ adatnak tekintjük (a feladat kitûzésekor egyszerûen úgy döntöttünk, hogy a naplót nem kívánjuk kezelni). Minden táblának legyen azonosítója (elsõdleges kulcs) • Még akkor is ha ezt nem tartjuk szükségesnek. Legfõképpen mert bármikor szükségessé válhat, és utólag nehéz belebütykölni Ez az

azonosító célszerûen számláló legyen és innentõl kezdve a rendszer automatikusan el fogja intézni. A mezõ neve • 1. A mezõ fejezze ki azt, amit leír 2 A mezõ neveket írjuk egybe és kezdjük a résszavakat nagybetûvel. (Ez a programozásnál és a megkülönböztetésnél igen fontos) 3 Az azonosító mezõk kezdõdjenek az Az szócskával és ugyanazok legyenek kapcsolómezõ szerepükben is a másik táblá(k)ban. A példában benne hagytunk néhány apró hibát: pl A diákok táblában a Név helyett célszerûbb a DiákNév, az Osztály táblában az OtályAz helyett (sajnálatos elírás) az OsztályAz lenne a helyes. Ezen hibák természetesen utólag is javíthatók, de akkor már nagyon nehezen, ha készen vannak a lekérdezések és jelentések, mert mindenhol át kell vezetni õket. A mezõ típusa • A mezõ típusát mindig a leírandó tulajdonsághoz kell igazítani. Karakteres adatnál ne pazaroljunk, de szûkösködjünk. Vannak olyan tipikus szám

jellegû adatok, amiket mégis karakteresre kell választanunk: telefonszám, személyi szám, irányítószám. A dátum jellegû adatokat ne tároljuk karakteres formában. Numerikus adatoknál feltétlenül döntsük el, hogy azon belül milyen legyen. Pénz jellegû adatnál válasszuk a neki megfelelõ Pénz típust Maszkok, megjelenési forma, validálás • Az igazán korszerû – mint az Access – adatbáziskezelõknél ezeket a dolgokat is az adatok szintjén tudjuk definiálni. A munka elején ez sziszifuszi munkának tûni, de ha itt kihagyjuk, akkor ezt többszörösen el kell végeznünk utólag. Mezõmagyarázat • Annak érdekében, hogy késõbb fel tudjuk idézni azt, hogy mely mezõt mi okból vezettük be, szokjunk rá, hogy leírjuk annak jelentését. -38- Felhasznált és ajánlott irodalom Halassy Béla: Az adatbázis-tervezés alapjai és titkai. Budapest, 1994, IDG Magyarországi Lapkiadó Kft Dr. Kovács Tivadar: Adatkezelés az MS ACCESS 20

alkalmazásával Budapest, 1996, ComputerBooks -39-