Informatika | Adatbázisok » SZTE Hampel György - Adatbázisok

Szegedi Tudományegyetem Szegedi Élelmiszeripari Főiskolai Kar Adatbázisok (második, javított változat) Összeállította: Hampel György főiskolai adjunktus 2003. Tartalomjegyzék 1. 2. 3. 4. Az adatbázis-kezelés alapfogalmai . 4 1.1 Áttekintés . 4 1.2 Adat és információ. 5 1.3 Adatbázis . 6 1.4 Az adattárolás struktúrája. 7 1.5 Adatbázis-kezelő rendszer . 12 1.6 Alkalmazói segédprogramok . 15 1.7 Adatbázisrendszer. 19 1.8 Információs rendszerek . 24 Adatmodellek. 27 2.1 Hierarchikus adatmodell. 30 2.2 Hálós adatmodell. 32 2.3 Objektum-orientált adatmodell . 33 2.4 Egyed-kapcsolat adatmodell . 34 2.5 Relációs adatmodell . 39 2.6 Egyed-kapcsolat modellből relációs adatmodell. 45 A relációk normál alakjai. 49 3.1 Normalizálás . 49 3.2 Funkcionális és többértékű függőség . 50 3.21 Funkcionális függőség . 50 3.22 Többértékű függőség . 52 3.3 Első normál forma (1NF) . 53 3.4

Második normál forma (2NF). 55 3.5 Harmadik normál forma (3NF). 56 3.6 Negyedik normál forma (4NF) . 57 3.7 Ötödik normál forma (5NF). 58 3.8 A normalizálás eredménye. 59 Műveletek, relációs algebra. 60 4.1 Átnevezés . 61 4.2 Szelekció (Korlátozás). 61 4.3 Projekció (vetület). 62 adatbázisok.doc -2- 2003.0909 5. 6. 7. 8. 4.4 Keresztszorzat. 63 4.5 Unió (Halmazegyesítés) . 64 4.6 Metszet. 64 4.7 Különbség . 65 4.8 Összekapcsolás . 66 4.9 Osztás . 67 4.10 Kiterjesztés. 68 4.11 Csoportosítás . 68 Az adatbázis-tervezés lépései. 70 5.1 1. fázis Az igények összegyűjtése, elemzése, a feladat specifikációja 70 5.2 2. fázis A koncepcionális terv elkészítése 71 5.3 3. fázis Az adatbázis-kezelő rendszer kiválasztása 73 5.4 4. fázis Adatbázis-kezelő rendszertől függő leképezés 73 5.5 5. fázis Fizikai tervezés 74 5.6 6. fázis Megvalósítás 75 A dBase-típusú

adatbázis-kezelők . 77 6.1 Adatbázis-kezelés FoxPro-ban. 79 6.2 A FoxPro programozása . 82 Az SQL lekérdező nyelv . 94 7.1 Adatbázis-kezelés Access-ben.102 7.2 Az Access programozása.108 Nagy adatbázisok .128 8.1 Adattárházak .129 8.2 Üzleti intelligencia rendszerek .132 Felhasznált és ajánlott irodalom .135 adatbázisok.doc -3- 2003.0909 1. Az adatbázis-kezelés alapfogalmai 1.1 Áttekintés A számítástechnika fejlődésének egyik jellemzője, hogy egyre több felhasználó egyre több, számítógépen tárolt adatot használ fel. Az egyre növekvő információmennyiség egyre szélesebb körben válik elérhetővé. Mivel a folyamat teljes joggal mérhető a könyvnyomtatás jelentőségéhez, ezért szokás elektronikus Gutenberg forradalomnak is nevezni. Az elektronikus Gutenberg forradalom legfontosabb jellemzője, hogy - egyre nagyobb információmennyiség - egyre szélesebb tömegek számára - egyre demokratikusabban válik

elérhetővé - a számítógép használatával. Környezetünk leírásához meg kell azt figyelnünk, adatokat kell gyűjtenünk az objektumairól, összegeznünk kell azok tulajdonságait, és meg kell figyelnünk a köztük levő kapcsolatokat. Ezek után juthatunk a rendelkezésre álló, tárolt adatokból új ismeretekhez, információhoz Az adatoknak egy jól strukturált halmazát adatbázisnak nevezzük, amelyből a későbbiekben információt tudunk majd nyerni Az információnyerés céljából olyan szoftvereket használunk, amelyek lehetővé teszik az adatbázisok kezelését (lekérdezését, módosítását, törlését, karbantartását); ezeket együtt adatbázis-kezelő rendszernek nevezünk. Az olyan rendszereket, amelyek a hardveren tárolt adatokból szoftverek és egyéb alkalmazói programok segítségével lehetővé teszik a felhasználó számára az információ nyerését, információs rendszereknek nevezzük. Az adatbázis-kezelő rendszerek nem

hirtelen, minden előzmény nélkül jelentek meg a piacon és a köztudatban. A számítógépeket kezdetben a tárak kis kapacitása miatt elsősorban numerikus számítások elvégzésére használták, majd később a technológia fejlődésével egyre nagyobb mennyiségű információ tárolására váltak alkalmassá. Megjelentek a kimondottan a nagymennyiségű adatok hatékony kezelésére készült rendszerek is. Az első szekvenciális fájlok még az 1940-es évek végén jelentek meg. Az első nem adatbázisok.doc -4- 2003.0909 szekvenciális hozzáférést biztosító fájlrendszert 1959-ben fejlesztették ki. Az 1960-as években olyan programozási nyelvek jelentek meg, mint a Fortran, Basic, PLI, és volt egy, mely kimondottan adatkezelés-orientált céllal jött létre, a Cobol. A 60-as évek elején dolgozták ki a hálós adatmodell alapjait, majd nem sokkal rá megjelent a hierarchikus adatmodell is. Az első hálózatos, konkurens hozzáférést biztosító

adatbank 1965-ben jelent meg Az adatbázis-kezelő rendszerek is jelentős fejlődésen mentek keresztül azóta; jelentősen megváltozott használati módjuk és az általuk támogatott adatmodell jellege. Az induló időszak hierarchikus, majd hálós adatmodelljei után az 1970-es években indult el hódító útjára a ma már legelterjedtebb adatbázis-kezelő típus, a relációs adatbázis-kezelés. Az 1980-as években a relációs adatbázis-kezelők SQL kezelő felülete is szabvánnyá vált. Még ma is teret hódítanak új elvek az adatbázis-kezelés területén, mint az objektum orientáltság vagy a logikai programozás, valamint a hálózatok elterjedésével az osztott adatbázis-kezelők szerepe is egyre nő. 1.2 Adat és információ 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éklehető, felfogható és megérthető) személytelen,

objektív, feldolgozótól független ismeret. Az adat az információ hordozója, vagyis a tények, fogalmak, feldolgozásra alkalmas reprezentációja Az információ, mint szubjektív fogalom, szorosan kötődik hordozó közegéhez. Az információ az adatnak valamilyen megjelenése; új ismeretté értelmezett adat. Az információ mindig személyes, az adatot fogadó belső énjéhez, szubjektumához kötődő lényeg (Halassy). Az információt jelsorozathoz kapcsolódó új jelentésnek, hasznos közlésnek tekinthetjük Egyik fontos eleme az újdonság Esetünkben az adat a számítógépben tárolt jelsorozatot jelenti, melyből a feldolgozás során nyerhetünk információt. Az adat a számítógépben információ nélküli jelsorozatként tárolódik Az információ feldolgozására készített számítógépes programok az adatokat különadatbázisok.doc -5- 2003.0909 böző strukturáltságban tárolják. Az adatok lehetnek lazább szerkezetben, és szigorúbb,

finomabb struktúrában tárolva Ennek megfelelően beszélhetünk: szövegszerű rendszerekről és adatszerű, finoman strukturált rendszerekről. - A szövegszerű tárolásnál a dokumentumok, könyvek, cikkek alkotják a legkisebb elérési egységet. A dokumentum belső struktúra nélkül, ömlesztve tartalmazza az információt - Az adatszerű tárolásnál sokkal kisebb adatelemek, egyedek tulajdonságai is elérhetők és kezelhetők. 1.3 Adatbázis A fogalom definícióját az adatbázisokhoz rendelhető legfontosabb tulajdonságok megadásával írhatjuk le. Az adatbázisra vonatkozóan nincs egy egységesen elfogadott definíció, úgymond mindenki szabadon értelmezheti, hogy mit érez fontosnak az adatbázis fogalmára. Az adatbázis néhány ismert definíciója: - Az adatbank rekordok összessége. - Általában és szigorúan véve olyan adatállomány, amely egy adatbázis-kezelő rendszerrel hozható létre és érhető el. - Adatbázis összetartozó

és kapcsolódó adatok rendszere. (Elmasri Navathe) - Adatbázisokon voltaképpen adatoknak kapcsolataikkal együtt való ábrázolását, tárolását értjük. (Horváth Katalin - Dr Szelezsán János) - Az adatbázis véges számú egyed-előfordulásnak, azok egyenként is véges számú tulajdonságértékének és kapcsolat-előfordulásainak az adatmodell szerint szervezett együttese. (Dr Halassy Béla) - Az adatbázis a felhasználók által rugalmasan kezelhető adatok rendszere. (C.J Date) - Az adatbázis összetartozó adatok azon rendszere, mely megosztott több felhasználó között, és az elérést egy központi vezérlő program szabályozza. A felhasználónak nem kell ismernie az adatok fizikai tárolási mechanizmusát. (J G. Hughes) - Egy olyan integrált adatszerkezet, mely több különböző objektum előfordulási adatait adatmodell szerint szervezetten, perzisztens módon tárolja olyan segédinformációkkal, ún. metaadatakkal együtt, melyek a

hatékonyság, integri- adatbázisok.doc -6- 2003.0909 tásőrzés, adatvédelem biztosítását szolgálják. Adatbázisnak nevezzük a káros és felesleges redundancia nélkül közösen tárolt, egymással kapcsolatban lévő adatok halmazát, amelynek alapvető célja egy vagy több alkalmazás optimális kiszolgálása. Az adatokat az azokat kezelő programoktól függetlenül tároljuk, így az adatokat és az azokat használó programokat is megváltoztathatjuk anélkül, hogy a másikat módosítanánk. Az adatbázisok legfontosabb jellemzője: valamilyen fokú redundancia, továbbá hogy állandóan növekszenek, változnak. Az adatbázis egy megvalósított adatmodell, amely a valódi adatokon kívül tartalmazza az adatok típusait és kapcsolatait leíró ún. metaadatokat is Ehhez szükséges egy adatszerkezet-leíró nyelv (Data Definition Language, DDL), valamint egy fizikai szerkezetet megvalósító nyelv (Storage Description Language, SDL). Az

adatbázis-rendszer fontos része a tárolt adatok különböző szempontok szerinti visszakeresését végző nyelv (Data Manipulation Language, DML) is Az adatleíró és adatkezelő nyelvet magába foglaló adatbázis-kezelő rendszer (Database Management System, DBMS) teszi lehetővé, hogy egy jól megtervezett adatbázist használni tudjunk. 1.4 Az adattárolás struktúrája Az adatkezelő rendszereknél a permanens adatok állnak az adatkezelés központjában, tehát azok az adatok, melyekre hosszú ideig, az alkalmazásból történő kilépés után is szükség van. A permanens adatok tárolására a háttértárolók szolgálnak, ahol az adatok fájlokba szervezetten helyezkednek el. A nagy adatmennyiségből eredően minden pillanatban az adatoknak csak egy töredéke fér el fizikailag a központi memóriában. Ha a fájlon belüli tárolás kérdését vizsgáljuk, akkor meg kell ismerni a lehetséges fájlszervezési módszereket és azok hatékonyságait az olyan

alapvető műveleteknél, mint az adatelemek megkeresése, lekérdezése; adatelemek bővítése, módosítása, törlése; segédinformációk tárolása. A leggyakoribb művelet a lekérdezés, célszerű ezért olyan fizikai tárolási struktúrát választani, amely a hatékony lekérdezést segíti. - Adathordozói szint. A hatékonyságnövelési lehetőségek keresését már az adathordozó szintjén el kell kezdeni, hiszen az adatelem beolvasása a címé- adatbázisok.doc -7- 2003.0909 nek ismeretében három fő lépésből áll, melyek különböző időszükséglet rendelhető: fejmozgatás (a fejet a lemez megfelelő sávjára, cilinderére kell mozgatni), fejkiválasztás (lemezcsomag esetén a megfelelő lemez kijelölése), forgatás (az adott sávon belül a megfelelő szektor, blokk mozgatása a fej alá). E három elemből a fejmozgatás igényli a legtöbb időt, de ez lényegesen függ attól, hogy hol helyezkedik a sáv, mi volt az előzőleg felkeresett

sáv. Minden sávváltás időszükséglettel jár, mégpedig minél nagyobb volt a távolság, annál több idő szükséges. Ebből két fontos megállapítás is vonható le: az egymásután, együtt olvasott adatokat célszerű ugyanazon, vagy szomszédos sávokra elhelyezni, valamint egy adatelemnek, más programok véletlenszerű sávpozícióit feltételezve, az optimális elhelyezkedése a középső sávokban található. Amennyiben van befolyásunk az adatelemek elhelyezésére, akkor a fentiek figyelembe vételével kell dönteni. - Fizikai fájlszerkezet. A következő lépcsőfok a megfelelő fájlszervezés kiválasztása A fájlokon belül az adatok blokkokban tárolódnak, ahol egy blokk egy adatátviteli egységnek fogható fel, azaz egy írás vagy olvasás művelete minimum egy blokk adatmennyiséget mozgat az adathordozó és a központi egység között. A fájlhoz tartozó és egymás után következő blokkok nyilvántartására is több különböző módszer

létezik: a blokkok láncolása (minden blokkban van egy mutató a következő blokkra; az első blokk címének ismeretében sorban felkereshető az összes többi blokk); blokk címlista (minden fájlhoz létezik egy lista, amely a hozzá tartozó blokkok címeit tartalmazza; ez a lista lehet egyszerű, összefüggő, de lehet bonyolultabb felépítésű is). - Logikai fájlszerkezet. A blokkok a fájlok fizikai szerkezetét mutatják, de emellett a fájl egy belső logikai struktúrával is rendelkezik A logikai fájlszerkezet lehet stream jellegű vagy rekord jellegű. A stream fájltípusnál a fájl egy belső struktúra nélküli byte vagy karakter sorozatból áll. A karaktersorozatot a felhasználó program értelmezi saját igénye szerint Ugyanazt a fájlt a különböző programok másképp értelmezhetik. A rekord jellegű típusnál feltesszük, hogy a fájl felbontható logikai részelemekre, úgynevezett rekordokra. A rekord egy logikailag összetartozó adatelemek,

mezők összessége. A rekord és a blokk viszonya alapján beszélhetünk spanned rekordokról, ha egy rekord több blokkra is kiterjedhet, és unspanned rekordokról, ha egy rekord csak egy adatbázisok.doc -8- 2003.0909 blokkhoz tartozhat. A rekord jellegű állományokban a rekordok lehetnek fix hosszúságúak, vagy változó hosszúságúak. - Adatelemek elérése. Ha az adatelemek gyors elérését kívánjuk elérni, akkor a belső struktúra nélküli stream fájlkezelés nem megfelelő, hiszen ebben az esetben csak a fájl soros átolvasásával találhatjuk meg a keresett elemet, ami azt jelenti, hogy egy elem meg találásához átlagosan a fájl felét át kell olvasni. A rekordjellegű megközelítés esetében is megvalósítható ez a számunkra nem előnyös felépítés, ugyanis a rekordjellegű fájl szerkezeteknek az alábbi típusai ismertek: soros elérés, szekvenciális elérés, indexelt elérés, random és hashing elérés. Az elérési, szervezési

módok közötti különbség megértéséhez szükségünk van egy újabb fogalom, a rekordkulcs megismerésére. A rekord az egyed több tulajdonságát tartalmazhatja E tulajdonságok között vannak olyanok, melyek több egyednél is ugyanazt az értéket vehetik fel. Vannak azonban olyan mezők, azaz az egyed olyan tulajdonságai, melyeknek egyedieknek kell lenniük. Az ilyen tulajdonságot, vagy tulajdonságcsoportot, mely egyedisége révén alkalmas az egyed, azaz a rekord egyértelmű azonosítására, rekordkulcsnak, vagy röviden kulcsnak nevezzük Az adatelemek keresésénél kiemelt fontosságúak lesznek azok az esetek, amikor a keresés a kulcsra vonatkozik, mivel ez a rekordok egy természetes keresési módját jelenti. Ez alapján az egyes fájlszervezési módok az alábbiakban foglalhatók össze: - Soros elérés. A rekordok a fájlban tetszőleges sorrendben (például a felvitel sorrendjében) helyezkednek el, azaz nincs kapcsolat a rekord kulcsértéke és a

rekord fájlon belüli pozíciója között. Egy adott kulcsértékű rekord bárhol elhelyezkedhet a fájlban, kereséskor a fájl minden rekordját át kell nézni egymás után a fájl elejétől kezdve, amíg meg nem találjuk a keresett rekordot Ez átlagosan a fájlban tárolt rekordok felének átnézését igényli, ezért az egyedi keresések szempontjából nem tekinthető hatékony módszernek. Amennyiben minden fájlhozzáférésnél szükség van az összes rekordra, akkor ez a fájlszervezés lesz a leghatékonyabb. - Szekvenciális elérés. A rekordok a fájlban a kulcsértékeik alapján sorba rendezve helyezkednek el (pontosabban a rekordok a fájlban a kulcsértékeik nö- adatbázisok.doc -9- 2003.0909 vekvő, vagy csökkenő sorrendjében érhetők el). A szekvencia előnye, hogy nem szükséges a teljes fájlt végignézni adott kulcsértékű rekord keresésekor, mivel a sorrendbe rendezés miatt egy adott kulcstól jobbra csak tőle nagyobb (növekvő

rendezést feltételezve) kulcsértékű elemek helyezkedhetnek el. Ez a sorrendbe rendezés megvalósítható fizikai szekvenciával vagy logikai, láncolt szekvenciával. A fizikai szekvenciánál a rekordok fizikai helye megfelel a sorrendben elfoglalt helyének Ezáltal gyors lesz az egymást követő rekordok elérése, de egy új rekord beszúrása esetén át kell rendezni a rekordokat a fájlon belül. Gyakran változó fájl esetén nem javasolt ez a módszer A logikai szekvencia esetén a rekordok a bevitelük sorrendjében helyezkednek el fizikailag a fájlban, és a sorrendbe rendezettséget mutatók segítségével valósítják meg, azaz minden rekord tartalmaz egy mutatót a sorrendben őt követő rekordra. Így beszúráskor csak a mutatókat kell átrendezni, a rekordok fizikai pozíciója ugyanaz marad. Mivel mind a két esetben továbbra is a fájl elejéről kiindulva, az egymást követő elemek ellenőrzésével lehet keresni, ez a módszer sem hatékony. -

Indexelt struktúra. A keresés meggyorsítható, ha nem kell minden, a keresett rekordot megelőző rekordot fizikailag is átolvasni. Valójában a keresett rekordot megelőző rekordokból csak azok kulcsértékei fontosak számunkra, a rekord többi mezője lényegtelen Mivel rendszerint a kulcsmező nagysága csak egy töredéke a teljes rekord méretének, ezért ezeket a redukált adatokat sokkal gyorsabban át lehetne olvasni, sőt egy minőségi javulást hozna, ha az átolvasandó sor elhelyezhető lenne a memóriában, ugyanis ekkor az egymás utáni elem beolvasások helyett egy sokkal gyorsabb keresési módszer, a bináris keresés is alkalmazható lenne. Mindennek megvalósítása az index szerkezet, mely egy külön listában tartalmazza a rekordok kulcsait és az elérésükhöz szükséges mutatókat A legegyszerűbb indexszerkezet egy indexlista, mely az összes rekord kulcsát tartalmazza egy listában, ahol a kulcsértékek rendezetten helyezkednek el. Nagy

fájlméreteknél az indexlista is olyan hosszú lehet, hogy már nem fér egyszerre a memóriába, a lista kezelhetővé tételére új megoldásokat kerestek. Ennek egyik módszere az indexszekvenciális fájlszerkezet, melyben a rekordok fizikailag is rendezetten helyezkednek el a fájlban, mint a szekvenciális adatbázisok.doc - 10 - 2003.0909 állományoknál, így az indexlistának nem szükséges minden elemet tartalmaznia, csak bizonyos jelző rekordokat, mondjuk minden k-adik elemet. Így rekord keresését a fájlban a hozzá legközelebb eső, tőle kisebb kulcsértékű jelzőrekordtól kell csak kezdeni. Az állományban történő szekvenciális keresés sem tarthat sokáig, hiszen maximum k rekordot kell egymás után átnézni. A másik lehetséges, elterjedt módszer a többszintű, hierarchikus indexstruktúra bevezetése, melyben a felül elhelyezkedő listából nem közvetlenül a rekordokra, hanem újabb indexlistákra történik hivatkozás. A módszerrel

minden rekordot közel azonos idő alatt érhetünk el, azaz az indexszerkezet kiegyensúlyozottnak mondható. Ez az indexelési módszer tekinthető az egyik leghatékonyabb módszernek. Az indexelés feladatát még annyi bonyolíthatja, hogy esetleg több mező szerint kívánunk indexelni, vagy éppen nem kulcs mező szerint kívánjuk az indexelést elvégezni a lekérdezések jellegét figyelembe véve. Ha egy mezőnél egy érték több rekordban is előfordul, akkor nem szokás minden ilyen értéket külön felvenni az indexlistába, hanem csak egyet, az első előfordulást, s a többi rekord ebből a rekordból kiinduló láncolt listán keresztül érhető el. - Hashing. A rekord pozícióját közvetlenül a rekord kulcsértékéből határozzák meg, tehát csak egy blokkolvasásra van szükség a rekord eléréséhez. Sajnos azonban nem mindig igaz, hogy egy blokkolvasás elég, ez csak ideális esetben valósul meg. A hash elérési módszer alapelve, hogy a kulcs

értékéből valamilyen egyszerűbb eljárással, a h() hash függvénnyel meghatároznak egy pozíciót. Numerikus kulcsok esetén a „h(x)=x mod n” egy szokásos hash függvény, ahol „x” a kulcs érték és „n” hash tábla rekeszeinek a darabszáma A h(x) megadja, hogy mely rekeszbe tegyük le az x kulcsú elemet. Mivel a hatékony kezelhetőség végett a lehetséges pozíciók darabszáma lényegesen kisebb a lehetséges kulcs értékek darabszámánál, így szükségszerűen több kulcsérték is ugyanazon címre fog leképződni. Egy címhez rendelt tárterületet szokás bucket-nak is nevezni, mely lemez esetében rendszerint egy blokknak felel meg. Ha több rekord kerül egy címre, mint amennyi egy bucketban elfér, akkor lép fel a túlcsordulás jelensége, amikor is egy újabb blokkot, területet kell a címhez hozzákötni. Tehát egy címhez több különálló terület is tartozhat, melyeket láncolással kötnek össze. Ebben az esetben a rekord

kereséséhez adatbázisok.doc - 11 - 2003.0909 több blokkot is át kell nézni, amely lényegesen csökkenti a hash elérési módszer hatékonyságát. A túlcsordulás mellett a hash módszer másik hátránya, hogy csak nagyon körülményesen lehet vele megvalósítani a rekordok kulcs szerint rendezett listájának előállítását, hiszen a hash módszer az egymást követő rekordokat tetszőlegesen szétszórhatja a címtartományon a kiválasztott hash függvénytől függően. A jó hash függvény a túlcsordulást rekordok egyenletes elosztásával tudja kivédeni. Mivel a rekordokhoz rendelt címek eloszlása nagyban függ a kulcsértékek eloszlásától, a túlcsordulás soha sem védhető ki teljesen. 1.5 Adatbázis-kezelő rendszer Az adatbázis olyan adathalmaz, amely több, különböző felépítésű, egymással kölcsönös kapcsolatban lévő rekordok gyűjteménye. Az adatbázisok elvileg tetszőleges méretűek lehetnek: az adatok száma a

nullától, az üres adatbázistól a végtelen értékig terjedhet. Az elméletileg végtelen kapacitást a gyakorlatban a rendelkezésre álló hely, vagy a belső tárolási struktúra korlátozza. Az adatok és kapcsolataik egy adatmodell strukturált szabályainak megfelelően jeleníthetők meg, és az adatmodellhez tartozó parancsokkal feldolgozhatók. Az adatmodell strukturális szabályai és a feldolgozó nyelv együttesen alkotják az adatkezelési technikát Az adatkezelési technikának a megvalósítását egy speciális technika biztosítja, amelyet adatbázis-kezelő rendszernek (Database Management System, DBMS) nevezzük. Mint az adatbázisra, a DBMS-re is több meghatározást találhatunk: - Az adatbázis-kezelő rendszer az a program, mely az adatbázishoz történő mindennemű hozzáférés kezelésére szolgál. - Az adatbázis-kezelő rendszer az a programrendszer, melynek feladata az adatbázishoz történő hozzáférések biztosítása és az adatbázis

belső karbantartási funkcióinak végrehajtása. - Az adatbázis-kezelő rendszer egy szoftver, amely biztosítja az adatbázisban tárolt adatok létrehozását, kezelését, valamint leírja és kezeli az adatok közötti komplex kapcsolatokat. Az adatbázis-kezelő rendszernek támogatnia kell valamilyen adatmodellt, hogy a valóságot le tudja képezni egy számunkra megfogható objektumra Két részből épül fel Van egy jelölésrendszere, hogy va- adatbázisok.doc - 12 - 2003.0909 lamilyen formában a valóságot ábrázolni tudjuk és tartozik hozzá egy művelethalmaz, amely lehetővé teszi, hogy az előbbieket kezelni tudjuk. Adatbázis-kezelő rendszert alapvetően kétféleképpen lehet létrehozni. Az egyik módszer, hogy valamilyen programozási nyelvben írják meg a rendszert. A másik módszer pedig, hogy egy már meglévő rendszerben fejlesztik ki az új rendszert. Az adatbázis-kezelő rendszer részei: - Kapcsolattartó: ez teszi lehetővé, hogy más

alkalmazások kapcsolatba tudjanak lépni az adatbázissal. - Feladat átkonvertáló: elemzi, értékeli az adatbázis kezelő rendszer nyelvén kapott utasításokat, és ha végrehajthatóak, meghatározza a végrehajtás várható leghatékonyabb módját. - Elérés meghatározó: az objektumok elérésére meghatározott módszert átfordítja az operációs rendszer számára érthető parancsokká. Az adatokhoz való hozzáférés nem egy egyszerű írási vagy olvasási műveletet, hiszen az adatbázis-kezelő rendszernek gondoskodnia kell az integritási, hatékonysági és védelmi feltételek megőrzéséről. Az adatbázis-kezelő rendszer emiatt egy bonyolult programrendszernek tekinthető, mely sok funkcióját, összetettségét tekintve leginkább az operációs rendszerekhez hasonlítható Az integritási, hatékonysági és védelmi feltételek ellenőrzését és betartatását az adatbázis-kezelő rendszer a háttérben végzi el, mintegy a felhasználó

közvetlen parancsa, tudta nélkül Mindez azért történik így, hogy a felhasználó véletlenül, vagy szándékosan se tudja elrontani az adatbázist. Az adatbázis-kezelő rendszer több programból álló szoftvertermék, melynek biztosítania kell az: - egy megfelelő módon leírt adatfeldolgozás végrehajtását (adatbázis létrehozása, módosítása, törlése), - az adatbázis következetességét (csak valós adatokat tároljunk), - az adatok közti komplex kapcsolatok kezelését és ábrázolását, - az adatbázis valamennyi adatának elérését, - az adatok védelmét, titkosítását, - a hozzáférési jogok kezelését, adatbázisok.doc - 13 - 2003.0909 - az adatfüggetlenséget, - a redundancia-mentességet és annak ellenőrzését, - az adatbázis integritásának karbantartását, - a helyreállíthatóságot, - többfelhasználós rendszerekben az egyidejű hozzáférést, - osztott adatbázisokban az adatok szétosztását,

megtalálását, valamint - az adatforgalom optimalizálását. Az adatbázis-kezelő rendszereknek a feladatok végrehajtásában fontos eszköz az adat-program függetlenség megvalósítása. Ennek hiánya esetén egy programnak az általa kezelt teljes adatállomány-szerkezetet le kell írnia. Ha az adat leírásában következik be változás, akkor a programot is módosítani kell. Adatbázisok esetében az adat-program függetlenség megvalósulása miatt az adatleírás módosítását csak egy helyen, egyszer kell végrehajtani, és csak azokat a programokat kell módosítania, amelyek ezt a megváltozott mezőt kezelik. Fontos az adatbázis integritása is. Ezen az adatbázis olyan állapotát értjük, amikor az adatbázisban lévő valamennyi adat értéke helyes olyan értelemben, hogy az értékek - adott pontossági és időbeli korlátok között - a valós világ állapotát tükrözik, valamint eleget tesznek a kölcsönös megfeleltetés (konzisztencia)

szabályainak. Az adatbázis integritásának karbantartása magában foglalja az integritás ellenőrzését és valamennyi, észlelhető hiba kijavítását. Az adatbázis létrehozását és a benne tárolt adatokhoz való hozzáférést biztosító nyelvet adatbázis-nyelvnek nevezzük. Egy adatbázis-nyelv egy vagy több adatleíró nyelvet és egy vagy több adatkezelő nyelvet tartalmaz. A különböző adatbázisnyelvek aszerint is megkülönböztethetők, hogy - létező programozási nyelv kiterjesztéseként tervezték-e (befogadó nyelv), - bármely programozási nyelvtől függetlenül használhatók (szabadon álló nyelv), - mindkét módon használhatók. Az adatleíró nyelv használatával kapjuk meg az adatszótárat. Egy adatszótárnak a legalább következő információkat kell tartalmaznia: - az adat neve, - az adat típusa (szöveges, numerikus, dátum, logikai, stb.), adatbázisok.doc - 14 - 2003.0909 - az adat hossza. Ezen kívül az

adatszótár még a következő információkat is tartalmazhatja: - az adat szerkesztési képe, formátuma, - az adat értékkészlete, tartománya, - ellenőrző adatok más fájlokban, - hozzáférési jelszavak, - sor- és oszlopkijelölés az adat képernyőn történő megjelenítéséhez, - az adat promptja adatrögzítéskor, - az adat fejléce formázott lista készítésekor. 1.6 Alkalmazói segédprogramok A DMBS-t a felhasználó nem közvetlenül, hanem segédprogramokon keresztül, azok futtatásával éri el. A segédprogramok a DBMS-en keresztül érik el az adatbázisban tárolt adatokat. A szoftvertermékeket a felhasználói csoport alapján célszerű egymástól elkülöníteni Ehhez felhasználók hármas tagolása ajánlott, úgymint: - rendszermenedzser és operátor, - alkalmazás- és adatbázisfejlesztő-programozók, - végfelhasználók. A rendszermenedzser és operátor felhasználók segédprogramjai A csoport számára készültek

azok a segédprogramok, melyekkel az egész adatbázis működését érintő tevékenységek végezhetők el. Az ide sorolható legfontosabb programok: - Adatbázis adminisztrátor monitor. Ezzel a segédprogrammal az adminisztrátori jogkörrel felruházott személy elvégezheti többek között az adatbázis indítását, leállítását, az adatbázis alapparamétereinek beállítását, az adatmentések elvégzését, DBMS hatékonyság és a felhasználói tevékenységek figyelését - Loader. Külső szöveges vagy szekvenciális állományokban tárolt adatoknak az adatbázisba történő gyors betöltésére szolgál. Az adatátvitel során szűrőfeltételek adhatók meg és adatkonverziók is elvégezhetők Az elvégzett műveletek naplózhatók Ez a segédprogram a különböző platformokon futó adatbázisok közötti adatcserére is használható adatbázisok.doc - 15 - 2003.0909 - Backup (Export, Import). Az adatbázis adatainak lementésére és

visszatöltésére szolgál Bizonyos rendszereknél két külön program valósítja meg ezt a funkciót, az Export segédprogram végzi az adatok kimentését, míg az Import programmal lehet a lementett adatokat visszatölteni. A backup rendszer az adatok adathordozó sérüléséből vagy egyéb okokból eredő elvesztésének megelőzése mellett a DBMS rendszer különböző verziószámú változatai közötti adatkonverzióhoz is felhasználható. A legtöbb DBMS-nél lehetőség van a szelektív mentésre, ahol a szelekció mind az adatok jellegére, mind az adatok aktualitására vonatkozhat. Az alkalmazás- és adatbázisfejlesztő-programozó felhasználók segédprogramjai Az ebbe a körbe tartozó programok széles területet ölelnek fel, az interaktív eszközöktől kezdve a hagyományos programozási segédeszközökig. A szoftverfejlesztés rohamosan fejlődő területe egyre újabb módszereket, technikákat fejleszt ki, és az adatbázis- és alkalmazásfejlesztő

rendszerek is követik és alkalmazzák ezen új eszközöket. Ez a gyors, hatékonyságnövelő fejlődés magával hozza a fejlesztő rendszerek gyakori változását is, így a programozóknak is folyamatosan újabb és újabb módszereket kell megtanulniuk. Bár a fejlesztő eszközök megjelenésükben, kezelésükben gyakran módosulnak, jellegük, céljuk azonos marad, ezért behatárolható azon feladatok köre, melyek alapvető fontosságúak a fejlesztéshez. A legfontosabb segédeszközök: - Interaktív kezelőfelület. Parancsorientált, vagy grafikus felületet biztosít a felhasználónak. A kiadott utasítások rögtön végrehajtódnak és csak az eredmény kiírása után adható meg a következő utasítás - Űrlapkészítő. Ez a modul nemcsak az űrlapok megtervezésére szolgál, hanem egy alkalmazásgenerátort rejt magában Mivel az adatbázis-kezelő rendszerek űrlapokon keresztül jelenítik meg az adatokat, ezért nevezik ezt a komponenst

űrlapkészítőnek is. A formai megjelenés mellett itt lehet megadni az adatszerkezetet és a vezérlési algoritmust is. - Jelentéskészítő. Mivel az adatoknak a képernyőn, űrlapokban történő megjelenítése mellett, gyakran szükség van a nyomtatott listákra is, ezért külön adatbázisok.doc - 16 - 2003.0909 komponens szolgál a nyomtatási listák gyors elkészítésére. A fejlesztő rendszer a jelentés (és az űrlap) formátumának meghatározásánál felhasználja az adatbázisban tárolt metaadatokat is. - Menükészítő. Egy összetett alkalmazás több elemi részfunkcióból épül fel, ahol az egyes részfunkciókhoz egy-egy űrlapot lehet megfeleltetni, ezért a részfunkciókat az áttekinthetőség és gyors elérhetőség érdekében célszerű menühierarchiába szervezni. A menükészítő alkalmazása esetén elegendő a menüszerkezet hierarchiáját egy egyszerű nyelvvel leírni, a hozzá tartozó kód ezután már automatikusan fog

generálódni. - Program interfész. Mivel az űrlap és jelentéskészítő komponensek egy tipikus alkalmazás felépítését követik, ezekhez igazítottak, ezért nagyon nehéz nem tipikus, speciális követelményekhez igazodó alkalmazások elkészítése ezekkel az eszközökkel. A hagyományos programozási nyelvek sokkal nagyobb rugalmasságot biztosítanak ebben a tekintetben, ezek hátránya viszont, hogy a rendszerkönyvtáraik nem biztosítnak DBMS szintű adatkezelést. E probléma megoldására szolgálnak a DBMS-ek programinterfészei, melyek egy-egy programozási nyelvhez tartozó függvény- és eljáráskönyvtárban és előfordítókban testesülnek meg. Segítségükkel a normál program forrásszövegébe beszúrhatók a kapcsolódó DBMS adatkezelő utasításai is, így a programból elérhetővé válnak az adatbázisban tárolt adatok - CASE eszközök. Az adatbázis megtervezéséhez nagyszámú feltételt és körülményt kell figyelembe venni Az

elemzés eredményét egy olyan adatmodellben kell tárolni, mely közvetlenül felhasználható az adatbázis létrehozásához A nagy adatmennyiség mellett, egy ebből fakadó másik problémát jelent, hogy a tervezés rendszerint nem egy ember munkája, hanem csapatmunka. Emiatt különös gondot kell fordítani a dokumentációk szabványosságára, a feladatok kiosztására. A CASE eszközök jelentős segítséget nyújtanak a tervezésben, a csoportmunka összehangolásában A CASE komponens eredménye legtöbb esetben közvetlenül felhasználható az űrlapok, jelentések és menük generálásához. adatbázisok.doc - 17 - 2003.0909 A végfelhasználók segédprogramjai A felhasználók számára elkészült alkalmazói programok nagy része egyedi megrendelésre készül, a fent említett fejlesztői eszközök segítségével. Vannak azonban olyan gyakrabban igényelt szolgáltatások, alkalmazások, melyeket a szoftvergyártó cégek árusítanak. Ezek az

alkalmazások igen széles területet ölelnek fel a banki, pénzügyi, gyártásirányítási rendszerektől kezdve a különböző szakértői rendszerekig. A teljesség igénye nélkül, néhány segédprogram ismertetése: - Dokumentum nyilvántartó rendszer. Különböző szöveges dokumentumokban tárolt információk karbantartására, visszakeresésére szolgál, ahol a keresést kulcsszavak megadásával lehet könnyíteni A dokumentumok adatbázisokban és normál állományokban is tarthatók A rendszer alkalmas a dokumentumok és a strukturált adatok kombinálására is, továbbá összekapcsolható különböző fejlesztőrendszerekkel Fejlettebb változatok hipertext és multimédia lehetőségeket is biztosítanak. - Irodai program. Ez egy hivatali, ügyviteli programcsomag, amely magában foglal többek között szövegszerkesztőt, levelezőrendszert, elektronikus naplót, egy kis személyi kalkulátort. A rendszer egy vállalat több egységét köti össze a

helyi hálózaton keresztül. - Interaktív adatlekérdező. Programozói, adatbázis-kezelői ismeretekkel nem rendelkező felhasználók részére biztosít könnyen kezelhető felületet az adatbázis felé. Táblázatos formában, menü- vagy egérvezérelten kezelhető program, mellyel gyorsan végrehajthatók a lekérdezések, adatmódosítások, adatfelvitelek A rendszer egyszerűbb jelentések elkészítésére is alkalmas - Adat vizualizáció. Az adatbázisban tárolt adatok grafikus táblázatokban jeleníthetők meg, emellett lehetőséget nyújt képek, rajzok elkészítésére, tárolására is A korszerűbb változatokkal multimédia alkalmazások is futtathatók A grafikus felületen monitor funkciókat biztosítanak, így grafikusan követhető nyomon az adatok változása. - Vállalati nyilvántartó rendszer. A termék több, önállóan is használható részfunkciót foglal magába, melyek közül a legismertebbek a számlázó rendszer, adatbázisok.doc -

18 - 2003.0909 a könyvelési rendszer, a pénzügyi és személyzeti rendszer, a rendelések és a raktárak nyilvántartása. - Termeléstervező rendszer. A rendszer az erőforrások és kapacitások nyilvántartása mellett az erőforrások kiosztásának megtervezésére is lehetőséget ad. A várható piaci igények előrejelzésével és elemzésével meghatározható a termelés ütemezése. - Gyártásütemező és vezérlő rendszer. A költségtényezők és a technológiai megkötöttségek, a kiválasztott ütemezési módszer alapján optimalizálható a gyártás és felmérhetők a gyártási rendszer esetleges gyenge pontjai. - Vezetői információs rendszer. A vállalat felsőszintű vezetése számára biztosítja a szükséges összesített adatokat, lehetőséget adva a statisztikai kiértékelésekre A rendszer felhasználható döntéshozatali segédeszközként is Ezt a felsorolást még sokáig lehetne folytatni további alkalmazási területekkel,

de már ebből is látható, hogy az adatbázisok fő alkalmazásává a vállalati nyilvántartási és termelésirányítási rendszerek, valamint az államigazgatási nyilvántartó rendszerek váltak. 1.7 Adatbázisrendszer Az adatbázis-kezelő, az adatbázis-kezelő rendszer, valamint alkalmazói és segédprogramok együttesét adatbázisrendszernek (Database System, DBS) nevezzük. A DBS használatának előnyei a következők: - Az egyedtulajdonságok, kapcsolatok és metaadatok egységes tárolási rendszere. Az adatbázis nem egy speciális alkalmazói programhoz készült, hanem tetszőlegesen sokfajta alkalmazói program is futhat rajta, több alkalmazói program adatait is összefogja. Ezért szokás az adatbázisban tárolt adatokat integrált adatoknak is nevezni - Adatfüggetlenség. Az adatfüggetlenség kérdése az egyik legfontosabb jellemzője az adatkezelés fejlődésének (A ötvenes évek elején megírt progra- adatbázisok.doc - 19 - 2003.0909

mok egyik jellemzője volt, hogy a programkód teljes mértékben tükrözte az adatok tárolásának szerkezetét, hiszen a program szinte közvetlenül elérhette az adatokat. Ha megváltozott a fizikai struktúra, akkor át kellett írni a programot is) A fizikai adatfüggetlenség azt jelenti, hogy a fizikai adatszerkezet, az elérési mód megváltoztatható anélkül, hogy a programot is módosítani kellene. Az adatfüggetlenség másik típusát logikai adatfüggetlenségnek nevezzük. Ez alatt azt értjük, hogy a letárolt logikai adatmodell maga is bővíthető, illetve bizonyos mértékben módosítható, hogy az alkalmazói programokat módosítani kellene. Ha tehát egy objektumtípushoz egy újabb tulajdonságot kívánunk hozzáadni, nem kell egyetlen egy meglévő alkalmazói programot sem módosítani. - Nagyobb adatabsztrakció. Az adatbázis-kezelésnél az adatok a felhasználó szemszögéből tekintve adatmodellben tárolódnak, ezért a felhasználónak nem

kell törődnie a fizikai tárolás részleteivel, s egy magasabb absztrakciós szinten értelmezheti az adatrendszert. A részletek rejtve maradnak a felhasználó és a programfejlesztő előtt is. - Adatmegosztás, párhuzamos hozzáférés. A rendszer felkészült az integrált adatokhoz történő osztott hozzáférések kezelésére. Az adatmegosztás révén a helyigény is csökkenthető, és így mindenki a legaktuálisabb adatokhoz férhet hozzá. - Ellenőrzött redundancia. Mivel több alkalmazás is ugyanazt az adatbázist használja, ezért a felhasznált adatok is egy helyen, egy kézben összpontosulnak. A hagyományos fájlkezelésnél, ha több alkalmazásnak is szüksége volt egy adatra, akkor az adatot több fájlban is tárolták. Ez a redundancia számos hátránnyal járt, a felesleges helyfoglalástól kezdve a konzisztencia megőrzésének problémájáig. - Hozzáférési jogosultságellenőrzés, adatvédelem. A DBS az operációs rendszerekhez

hasonlóan nyilvántartja a jogosult felhasználókat. Nyilvántartja az azonosító nevet, a jelszót, a felhasználó tulajdonában lévő adatokat, az engedélyezett műveleteket. Az adatvesztés okozta károk minimalizálására adatbázisok.doc - 20 - 2003.0909 mind statikus mind dinamikus védelem használható. A statikus védelem egyik eszköze a mentés, a dinamikus védelemhez pedig a naplózás tartozik. - Optimalizált fizikai adatszerkezetek. A DBS-ben implementálták mindazokat a hatékony adatstruktúrák kezelésére alkalmas algoritmusokat, melyekkel jelentősen javítható a műveletek hatékonysága, gyorsasága. - Integritási feltételek érvényesítése. A DBS keretén belül magában az adatbázisban tárolhatjuk az adatok között fennálló integritási szabályok formájában Az adatbázis módosításakor automatikusan ellenőrzi a rendszer, hogy nem sérül-e valamelyik integritási szabály. Ha megsérülne, akkor nem hajlandó elfogadni a

változtatást - Szabványosság, hatékonyság, rugalmasság. A szabványos adatmodellek és kezelő felületek használatával az elkészült rendszer jobban érthetővé válik mások számára is, ezáltal a későbbi fejlesztés és módosítás is könnyebbé válik. Számos fejlesztő eszköz áll rendelkezésre, jelentősen megnövelve a fejlesztés hatékonyságát A szükséges változtatások gyorsabban végrehajthatók, nagyobb rugalmasságot biztosítva a rendszernek Az adatbázisrendszer elvi felépítése Az adatbázis leírásakor az adatbázisrendszerek három szintjét különböztethetjük meg: a külső, a koncepcionális és a fizikai szintet. Az egyes szintek az adatbázisrendszer, mint egység, különböző megvilágításainak, megközelítéséinek felelnek meg. A szinteket ezért szokás nézeteknek (view) is nevezni - Külső szint. A külső szint foglalja magában azt, amit a felhasználó az adatbázisból lát, amit a felhasználó adatbázis alatt

gondol, ami az ő számára az adatbázist jelenti. Mivel egy adatbázisrendszerhez több alkalmazó, felhasználó is kapcsolódhat, ezért több nézetet is tartalmazhat Ezek a nézetek rendszerint különbözőek, hiszen a felhasználók a teljes adatbázis más-más részletét látják csak Például más adatokat kezel és más adatokhoz férhet hozzá a teljes vállalati adminisztrációs rendszeren belül egy pénzügyi vagy egy személyzeti adminisztrátor. Mivel az adatrendszer más elemeivel ők soha nem kerülnek kapcsolatba, ezért számukra ezek az adatok jelentik a teljes adatbázist, ők úgy látják, hogy az adatbázis csak azokat az adatokat tartalmazza, adatbázisok.doc - 21 - 2003.0909 melyekkel kapcsolatba kerülnek. Az egyes nézetek különbözősége nem zárja ki azt a lehetőséget, hogy egyes nézeteknek közös elemei is legyenek. - Koncepcionális szint. Ugyan sok, különböző külső nézet létezik, de ezek mindegyike ugyanannak az

adatbázisnak a különböző részleteit tartalmazza. Ezért értelmezhető az a látásmód is, mely a teljes adatbázist tartalmazza. Ilyen nézettel kell rendelkeznie a rendszeradminisztrátornak, vagy az adatbázis-tervezőnek. Ez a közösségi nézet a koncepcionális szinten helyezkedik el A közösségi nézetből viszont csak egy van, s az összes külső nézet ennek egy szeletét jelenti. - Belső, fizikai szint. A felhasználó a külső nézetében a modellezett valóság egyedeit, egyedkapcsolatait látja. Még az adatbázis-tervező is a DBMS által támogatott adatmodellben, tehát egy absztraktabb leírásban gondolkodik. Az adatbázis viszont fizikailag is létezik, valamilyen fizikai adatstruktúrában letárolva az adathordozón. A kiválasztatott adatstruktúra is lényeges szerepet játszik az adatbázis hatékonyságánál, s az adatbázis adminisztrátor éppen egyik feladata a megfelelő fizikai struktúra kialakítása, hangolása. Tehát létezik egy, a

fizikai tárolási szerkezethez közel álló nézet is, melyet adattárolási nézetnek neveznek, és ez a belső szinten helyezkedik el. Az egyes szinteken a nézetek megadása különböző adatmodellek segítségével történik. Ennek során meg szokták különböztetni magát a nézetet – vagyis azon adatokat, amit látunk – az adatok tárolási struktúrájától, az adatszerkezettől Az adatszerkezet leírását sémának nevezik Az adatbázis tervezésekor elsőként a sémákat kell létrehozni, s ez a váz töltődik fel a használat során adatokkal. A séma alapján felépülő konkrét adatrendszert séma megvalósulásnak, adat-előfordulásnak nevezik Leíró nyelvek A sémák megadására valamilyen sémaleíró nyelvet, modellt kell használni. A séma az adatmodellnek és a leírásnak további számítógépes feldolgozásra is alkalmas tartalmi és formai megfogalmazása. Vagyis: az adatleíró nyelv a séma megfogalmazására szolgáló nyelv Egy

adatbázishoz egy séma tartozik, mely pontosan meghatározza az adatszerkezetet, a tárolási struktúrát, valamint az egyes adatelemek között fennálló logikai kapcsolatokat. Az alsémák mutatják meg, hogy az egyes adatbázisok.doc - 22 - 2003.0909 alkalmazói programok az adatbázist hogyan látják. Egy adatbázis sémához akárhány alséma illeszthető. Más-más alsémákban lehet az adatoknak a típusa, neve, csoportosítása Mivel a séma csak váz, melyet majd adatokkal kell feltölteni, szükség van olyan eszközre is, mely biztosítja, hogy a felhasználó az adatbázison műveleteket végezhessen. A műveletek vonatkozhatnak az adatbázis adataira előállítására, módosítására, lekérdezésére. Az ilyen adatkezelési utasítások végrehajtására szolgáló kifejezések alkotják az adatkezelő nyelvet (Data Manipulation Language, DML). Az adatkezelő nyelv által az adatbázis megnyitható, zárható, kulcs vagy cím alapján kereshetünk benne,

beolvashatunk, beszúrhatunk, törölhetünk, módosíthatunk. Számos adatbázis-kezelő rendszer nem tartalmaz procedurális nyelvet, hanem csak egy adatkezelő, adatdefiníciós résznyelvet, melyet egy hagyományos programozási nyelvvel együtt lehetett az alkalmazások elkészítésére felhasználni. A hagyományos programozási nyelvet nevezték gazda (host) nyelvnek, s ebbe kellett beültetni az adatkezelő és adatdefiníciós utasításokat. Szintek kapcsolódása A szintek sémáinak és nézeteinek különbözőségéből következik, hogy az egyes szintek kapcsolódásánál leképezést, illesztést kell végezni. Az egyes szintek között intenzív kapcsolat áll fenn, hiszen amikor egy alkalmazás, egy felhasználó kiad egy utasítást, akkor azt a saját külső sémájában fogalmazza meg. Egy időben több ilyen utasítás keletkezhet, melyek mindegyike más-más külső sémát használhat. A műveletek összehangolására, vezérlésére minden utasítást le

kell fordítani a koncepcionális szint sémájára. A fizikai szintű műveletek elvégzéséhez ismerni kell az adatok fizikai sémáját is, tehát szükség van a koncepcionális és a fizikai séma közötti leképzésre is. A fizikai művelet elvégzése után az eredmény visszajuttatásához ugyanígy el kell végezni a leképzéseket, csak fordított irányban. A leképzések, melyek megnövelik a műveletek végrehajtási idejét, legfontosabb célja a függetlenség biztosítása. (A felhasználó, az alkalmazásfejlesztő függetlenítheti magát a többi alkalmazástól, a koncepcionális tervezés pedig függetlenítheti magát a fizikai, belső megvalósulástól). A leképzések elvégzése a DBMS feladata, hiszen az egyes alkalmazói programoknak nem kell ismerniük a teljes adatbázist, a koncepcionális sémát. adatbázisok.doc - 23 - 2003.0909 Felhasználók A DBS-en belül az alkalmazói és a segédprogramok állnak legközelebb a felhasználóhoz: a

felhasználó ezzel a komponenssel kommunikál. A kiadott utasítások értelmezése után az adatkezelésre vonatkozó lépéseket a program a DBMS felé továbbítja A DBMS elvégzi a megfelelő adatbázis módosításokat, vagy adatbázis olvasási műveleteket és az eredményt továbbítja az alkalmazói program felé. A segédprogramok között kiemelt helyen szerepelnek a felhasználók egy bizonyos kiemelt csoportjának készült programok. Az ő feladatuk az adatbázis menedzselése, melyhez kiemelt jogosultságokkal rendelkeznek. Az adatbázis-menedzseléshez tartozó funkciók elvégzésére alkalmas segédprogramok megfelelő módon védettek a jogosulatlan hozzáférés ellen. Ezen jogokkal felruházott felhasználókat nevezik adatbázis adminisztrátoroknak (Database Administrator, DBA). Az adminisztrátorok mellett dolgoznak az operátorok, akiknek a feladata a rutinszerű rendszertevékenységek elvégzése (mentések, rendszerindítások vagy zárások). A

felhasználóknak egy tágabb csoportja az alkalmazásfejlesztők köre. A fejlesztőknek ismerniük kell az adatbázis adatmodelljét, a metaadatok megadásának módját, az alkalmazói programok fejlesztésének lehetőségeit stb. A fejlesztők egyik csoportja az adatbázis tervezésével foglalkozik, míg a másik csoportjának a felhasználói programok írása, tesztelése a feladata. A felhasználók legnépesebb csoportja az alkalmazók köre, akik az elkészült alkalmazásokat használják. Számukra az adatbázis azon adatokat jelenti, amelyekkel az alkalmazások során találkoznak, az adatbázis, a DBMS létezéséről, és annak belső működéséről semmilyen ismerettel sem kell rendelkezniük. 1.8 Információs rendszerek Az elkészített és alkalmazott számítógépes programrendszereknek egyre növekvő adatmennyiséggel kell megbirkózniuk. A hétköznapjainkban is egyre gyakrabban találkozhatunk a számítógépes információs rendszerek alkalmazásával

Számítógépes információs rendszer fut az üzemekben, gyárakban a termelés irányítására, a pénzügyi, személyzeti, raktári és anyaggazdálkodási feladatok elvégzésére. Ahhoz, hogy megbízhatóan és hatékonyan működjön, egy információs rendszerek több követelménynek kell megfelelnie: adatbázisok.doc - 24 - 2003.0909 - Nagymennyiségű adat hatékony kezelése. A felhasználónak elfogadható időn belül kell választ kapnia a kérdéseire, a kiadott utasítások végrehajtásának sem szabad sokáig tartaniuk. A hatékonyság tehát egyrészt időbeli hatékonyságot jelent, másrészt az adatok helyszükségleteinek sem szabad feleslegesen megnőniük, kerülni kell a felesleges redundanciát, azaz egyazon adatelem többszöri, felesleges megismétlését. (A redundancia teljes megszűnése nem mindig kívánatos az időbeli hatékonyság, vagy az adatbiztonság miatt). - Konkurens hozzáférés támogatása. A nyilvántartó és információs

rendszerek természetes használati módja, hogy egyidejűleg több felhasználó is használja, dolgozik vele Ez a lehetőség különös elővigyázatosságot igényel, hiszen nem kellő összehangolás esetén a párhuzamos változtatások, műveletek, torz eredményeket szülhetnek, egymás hatásait kiolthatják, vagy elferdíthetik Nyilván kell tartani az elvégzett műveleteket, és gondoskodni kell a műveletek szabályozott sorrendben történő végrehajtásáról - Integritásőrzés. A modellezett, programba leképezett valóság mindig rendelkezik belső törvényszerűségekkel (ilyen szabály lehet például, hogy minden embernek van személyi száma, vagy hogy az ember életkora nem lehet negatív). A letárolt adatok helyessége, integritása alatt azt értjük, hogy az adatok minden megadott belső szabálynak megfelelnek. Az integritás megőrzéséhez a rendszernek nyilván kell tartania a szabályokat, majd minden művelet alkalmával ellenőriznie kell, hogy a

kapott adathalmaz megfelel-e a letárolt szabályoknak. Mindezt olyan hatékonysággal kell végeznie, hogy a végrehajtási idő még az elviselhetőség határán belül maradjon. - Védelem. Ha a felhasználó rábízza magát és összes adatát a számítógépes rendszerre – vagyis a legtöbb adat csak ott tárolódik – akkor a tárolt adatok elvesztése szinte pótolhatatlan veszteséget okozhat. Ezért a rendszernek fel kell készülnie a lehetséges veszélyekre, mint például az adathordozó sérülése, az operációs rendszer vagy a program összeomlására. A felhasználóra leselkedő másik veszélytípus, az adatok illetéktelen személyekhez történő kerülése A rendszernek ezért szabályoznia és ellenőriznie kell a hozzáféréseket, különbséget kell tennie az egyes felhasználók között az elvégezhető művele- adatbázisok.doc - 25 - 2003.0909 tek tekintetében. Ehhez nyilvántartást kell vezetni a jogosult felhasználókról, azok

jogairól és minden műveleti igény kiadásakor ellenőrizni kell, hogy elvégezhető-e a művelet. Egyik megoldás lehet a monitoring, melynek során a rendszer ellenőrzi és naplózza erőforrás-hozzáféréseket. A hozzáférési védelem másik módszere a titkosítás - Hatékony programfejlesztés. A rendszer kifejlesztési idejének lerövidítésére több oldalról is jelentkező nyomás hat. A szoftverpiacon a rövidebb határidő előnyhöz juttathatja a versengőket, hiszen a felhasználó minél előbb szeretné kihasználni a rendszer által nyújtott előnyöket. Másrészről a gyorsaság bizonyos értelemben alapkövetelmény is, hiszen a rendszer mindig a valóság egy modelljének felel meg, s a modellezett valóság elég gyakran változik, például megváltoznak a szabályozók, a törvények. Egyik felhasználó sem kíván olyan rendszert megrendelni, amely használhatatlan lesz mire elkészül. Ezek a rendszerek túl drágák ahhoz hogy minden kisebb

változtatás után a felhasználó egy újabb rendszert rendeljen meg, ezért elég rugalmasnak kell lennie a kisebb változtatások elvégzésére. A rugalmasság és a gyorsaság igényei hatékony fejlesztő eszközök használatát teszik szükségessé a programfejlesztés során. Fejlesztés alatt a szabványos eszközök használata megkönnyíti az alkalmazások új platformra történő átültetését, és a fejlesztők egymás közötti kommunikációját, továbbá a fejlesztő rendszer elsajátítását is hatékonyabbá teszi. adatbázisok.doc - 26 - 2003.0909 2. Adatmodellek A különböző modellek alapvető szerepet játszanak a környező világ megértésében, leképzésében és alakításában. A modellek teszik lehetővé a lényeg kiemelését és szemléltetését. A modell fogalma alatt rendszerint két különböző dolgot szokás érteni: - olyan rendszert, amely a valóság egy vizsgált szeletével struktúrában vagy viselkedésben megegyezik,

vagy hasonló jelleget mutat és célja a vizsgálatán keresztül a valóság állapotára, viselkedésére vonatkozó következtetések levonása, illetve - a modell kifejezéssel jelöljük azon eszközrendszert is, amellyel az előző értelemben vett modell leírható, megadható. A modell tehát egyrészt egy jelölésrendszert, másrészt egy elkészült leírást jelölhet. Már eddig is igen sokféle és változatos modellekkel találkozhattunk. A programokat is egyfajta modellnek tekinthetjük, hiszen a vizsgált valóságot írják le a programozási nyelvek utasításainak, kifejezéseinek a segítségével. Amikor valamilyen alkalmazást készítünk, több lépcsőn keresztül modellezzük a feladatot: először egy áttekintő leírást készítünk, melyben közérthetően, az emberi fogalmakhoz közel állóan vázoljuk fel a megoldást, majd ez alapján elkészítjük a programozási nyelv segítségével megadott leírást. Az adatbázis-kezelés területén a

modellezésnek még nagyobb a szerepe, mint a hagyományos programfejlesztési eszközöknél. A hagyományos alkalmazások egyfajta problématerületre készülnek, behatárolt funkciókkal és adatelemekkel (egy szövegszerkesztő például nem alkalmas víruskeresésre). Ezt úgy is kifejezhetjük, hogy az alkalmazásba beleégetődött a problématerület modellje. A modell megváltoztatásához az alkalmazás egyes részeit újra kellene írni Az adatbázis-kezelő rendszerek ezzel szemben nemcsak egy problématerülethez készültek, hanem általános célúak. Az adatbázis-kezelő rendszernek a modellezett területtől függetlenül biztosítania kell az adatbázisban tárolt adatok hatékony kezelését. Ezért az adatbázis-kezelőkbe nem lehet egyetlen egy fix modellt beégetni, hanem nagyon sokféle különböző modell kezelésére alkalmasnak kell lennie Ez csak úgy oldható meg, ha a DBMS is rendelkezik egy felülettel, amelyen keresztül megadadatbázisok.doc - 27 -

2003.0909 ható, hogy milyen legyen az aktuálisan tárolandó adatrendszer struktúrája, modellje. Tehát a DBMS-ekhez mindig csatlakozik egy leíró nyelv, egy modell. Azokat a modelleket, amelyek az adatok struktúrájának leírására szolgálnak, adatmodelleknek nevezik. Az adatmodellek központi szerepet játszanak az adatbázis-kezelésben, hiszen ezen keresztül adhatjuk meg a megvalósítandó rendszer leírását az adatbázis-kezelőnek Ahhoz, hogy használni tudjuk az adatbázis-kezelőt, ismernünk kell a hozzá tartozó adatmodellt. Az adatbázis-kezelés fejlődésével újabb és újabb adatmodellek jöttek létre. Néhány, amit ismertetni fogunk: hierarchikus, hálós, relációs, objektum-orientált. A DBMS-ek egyik fő jellemzője, hogy mely adatmodellhez kapcsolódnak. (Például a relációs DBMS a relációs adatmodellen nyugszik). Az adatmodell egy jelölésrendszeren alapszik, ezért nem igényli feltétlenül egy DBMS létét, vagyis léteznek olyan

adatmodellek, melyekhez nem létezik DBMS; ilyen például az egyed-kapcsolat modell Az adatmodellezés tehát az adatállományok tervezésének korszerű módszere. Az adatmodellezéssel az a cél, hogy egy információs rendszer adatait és az adatok között fennálló kapcsolatokat következetesen ábrázolva, elősegítsük a számítógépes információ-feldolgozást. Az adathalmaz és az adathalmaz elemei között fennálló kapcsolatok strukturált leírását adatmodellnek nevezzük. Egy kielégítő modellnek az alábbi feltételeket kell teljesítenie: - átfogónak kell lennie, azaz minden lehetséges adatot és minden lehetséges kapcsolatot tudnia kell ábrázolni és kezelni, - le kell tudnia írni a valóság általános, lényeges és tartós összefüggéseit, - redundancia-mentesnek kell lennie, azaz minden adatot lehetőleg csak egyszer tartalmazzon, - következetesnek kell lennie, - és az alkalmazott hardverrel és szoftverrel összhangban levőnek kell

lennie. Az adatmodell nemcsak felsorolása az adatokat tartalmazó mezőknek, hanem az adatok jelentését is tartalmazza. Így az adatmodellben - világosan megkülönböztethetők az ábrázolt dolgok és a dolgok tulajdonságai, - pontosan meghatározott, hogy melyek az ábrázolandó dolgok azon tulajdon- adatbázisok.doc - 28 - 2003.0909 ságai, amelyekkel a dolgok egyértelműen azonosíthatók, - valamint az adatmodell expliciten definiálja az ábrázolt dolgok közötti kapcsolatokat. A valós világhoz képest az adatmodellek tartalmaznak bizonyos megszorításokat és egyszerűsítéseket, sőt még a modellező személyétől függő vonásokat is. Az adatmodell kialakításakor el kell dönteni, hogy mik legyenek a modellben az ábrázolandó információelemek, és ki kell választania a dolgok között fennálló lényeges kapcsolatok közül azokat, amelyeket be akarunk a modellbe építeni. Egy adatmodell a következő elemeket tartalmazza: - Egyedek a

valóság olyan dolgai, amelyek más dolgoktól megkülönböztethetők, azaz az egyed a valós világban létező, fogalmi vagy fizikai léttel rendelkező dolog, amelyet tulajdonságokkal akarunk leírni – például dolgozó, tanuló, lakos, vásárló stb. Ugyanaz a dolog többféle egyednek is tekinthető – egy személy például lehet dolgozó és vásárló. A képviselt konkrét elemek halmazát egyedhalmaznak nevezzük Például a vásárló, mint egyedhalmaz az öszszes vevőt tartalmazza) - Tulajdonságnak nevezzük a valóság dolgainak azon jellemzőit, amelyekkel az egyedeket leírjuk. Például dolgozónál tulajdonság a név, munkahely, beosztás, stb A név értékei lehetnek: Kovács, Szabó stb Az egyedek a tulajdonságértékeikkel azonosíthatók - Kapcsolatnak nevezzük az egyedek közötti viszonyok fogalmi tükörképeit. Objektumok közötti viszony lehet például az, hogy a tanuló az iskola tanulója. Ennek egy konkrét előfordulása, ha Szabó

János a József Attila általános iskola tanulója. Az adatmodellek a következő három szintre bonthatók: - Külső szint. Azt írja le, hogy hogyan látják a felhasználók az adatbázist - Belső, fizikai szint. Az adatok fizikai elhelyezését és fizikai elérési módját írja le. - Koncepcionális szint Azt írja le, hogy logikailag egységbe vonva, hogyan néz ki ténylegesen az adatbázis: hogyan néznének ki az adatok, ha mindenki adatbázisok.doc - 29 - 2003.0909 mindent láthatna belőlük. Az adatmodell az adatok logikai tárolási formátumát határozza meg. Egy olyan vázat ad, melybe az adatokat bele lehet tölteni. Az adatmodell megadása eszerint egy szerkezetleírást jelent, amit meg kell még toldani annyival, hogy az adatrendszer ismerete nem csak az adatszerkezet ismeretét, hanem az adatok kezelési módjának az ismeretét is magában foglalja. Ezért az adatmodellbe a statikus szerkezet leírás mellett a dinamikus, az adatokon

értelmezett műveleteket is beleértik. Az adatmodell megadásánál mind a szerkezet, mind a műveletek megadása logikai szinten, s nem fizikai szinten történik, ezért az adatmodell egy elvontabb absztraktabb, formálisabb leírást jelent. Összegezve tehát az adatmodell egy olyan matematikai formalizmus, mely az adatok és az adatokon értelmezett műveletek leírására szolgál Több adatmodell is létezik, de ezekből négy terjedt el a gyakorlati életben: a hierarchikus, a hálós, a relációs és az objektum orientált adatmodellek. Ezek közül a relációs adatmodell a legnépszerűbb, a hierarchikus és a hálós modell már a múlté, míg az objektum orientált modell várhatóan a jövőben válik csak igazán piacéretté. 2.1 Hierarchikus adatmodell A hierarchikus adatmodell az adatokat egy hierarchikus faszerkezetben tárolja. A fa mindegyik csomópontja egy rekordtípusnak felel meg és a rekordok között szülőgyerek kapcsolat van. A hierarchikus modell

alapja, hogy a gyakorlati életben a szervezetek vagy éppen a struktúrák nagyon gyakran hierarchikus felépítésűek (gondoljunk csak a vállalati hierarchiára vagy egy gyártmány alkatrészeinek hierarchiájára) Emiatt természetesnek tűnik, hogy a modellezés megkönnyítésére a valóságban leggyakrabban használt, hierarchikus modellt hozzuk létre. Ez a modell a gyakorlati alkalmazások során fejlődött ki, ezért nincs olyan elméleti megalapozottsága, mint a későbbi adatmodelleknek. A bonyolultabb kapcsolatok ábrázolása csak kerülőutakon lehetséges A modell előnye, hogy a hierarchikus szerkezet egyszerűen leírható és tárolása a mágnesszalagos tárolási formához is jól illeszkedik A hierarchikus adatmodellnél a két fontos alapfogalommal találkozunk: - Rekord: egy egyedhez tartozó mezők értékeinek összességét tartalmazza. Az azonos típusú rekordok csoportját rekordtípusnak nevezzük, melynek azonosí- adatbázisok.doc - 30 -

2003.0909 tó nevet kell adni. A rekord szerkezetét a benne lévő mezők határozzák meg - Szülő-gyerek kapcsolat: két rekordtípus között fennálló ún. 1:N kapcsolat Az 1-oldal rekordtípusát szülő-, míg az N-oldal rekordtípusát gyerek rekordtípusnak nevezzük. A modell tulajdonságai: - egyetlen rekordtípus, a gyökér, nem vehet részt gyerekként szülő-gyerek kapcsolatban, - minden rekordtípus – a gyökér kivételével – gyerekként pontosan egy szülőgyerek kapcsolatban vehet részt, - bármely rekordtípus szülőként tetszőleges számú kapcsolatban vehet részt, - ha egy rekordtípus szülőként több kapcsolatban is részt vesz, a gyerek rekordtípusai balról jobbra rendezettek. Számos esetben kerülhetünk olyan helyzetbe, amikor két rekord között N:M kapcsolat áll fenn. Ugyan ezt is le lehet írni 1:N kapcsolatok segítségével, de a megoldás körülményes és az adatok felesleges ismétléséhez vezet. Az egyszerűsítés

érdekében, az N:M kapcsolatok leírásának megkönnyítésére vezették be a virtuális rekordtípust Ez olyan rekordtípus, amelynek valamennyi rekordja tartalmaz egy mutatót, ami egy másik szinten lévő rekordtípusra mutat A mutatót tartalmazó rekordtípust virtuális gyereknek, amire mutat, virtuális szülőnek nevezzük A mutató által létrehozott kapcsolat virtuális szülő-gyerek kapcsolat A klasszikus hierarchikus adatbázis-kezelésben a következő kötelező integritási szabályokat kell betartani: - A gyökér kivételével egyetlen rekord előfordulás sem létezhet a hozzá tartozó szülőrekord nélkül. Ebből következik, hogy: - gyerekrekordokat csak szülőrekordokhoz kapcsolva szúrhatunk be, - a gyerekrekordot a szülőrekordtól függetlenül törölhetjük, - szülőrekord törlésekor automatikusan törlődnek a hozzá kapcsolódó gyerekrekordok is, - ha egy gyerekrekordnak kettő, vagy több ugyanolyan típusú szülőrekordja van, a

gyerekrekordot meg kell többszörözni, hogy minden szülőhöz különkülön tartozzon, - ha a gyerekrekordnak egynél több különböző típusú szülőrekordja van, akkor adatbázisok.doc - 31 - 2003.0909 ezek közül csak az egyik igazi, a többi csak virtuális szülő lehet. Ábrázolás Bachman diagrammal A modell szerkezete egy faszerkezet. A rekordtípusnak egy téglalapot feleltetünk meg, a rekordtípus nevét a téglalap felső részébe, a mezőneveket pedig az alsó részbe írjuk. A kapcsolatot összekötő nyíllal ábrázoljuk CÉG név, cím, igazgató DOLGOZÓ szem.szám, név, kor OSZTÁLY szoba, név 2-1. ábra Adatmodellek – hierarchikus adatmodell ábrázolása 2.2 Hálós adatmodell A hálós adatmodell a hierarchikus modell továbbfejlesztése, mely jobban illeszkedik a bonyolultabb kapcsolatok ábrázolásához. Ebben a modellben az egyedek között tetszőleges kapcsolatrendszer, egy kapcsolatháló alakítható ki. Az adatszerkezet

leírása – mivel a háló tetszőlegesen nagy lehet – nem egy adategységgel, hanem több kisebb, hierarchikus felépítésű adategységgel történik. A modell alapvető szerkezeti elemei a rekord (record) és a halmaz (set). Rekordokban tároljuk az egymással szoros kapcsolatban lévő adatokat Valamilyen szempont szerint összetartozó rekordok egy rekordtípusba tartoznak. Minden rekordtípusnak van egy azonosító neve, a rekord adatelemeit pedig nevükkel és típusukkal jellemezzük. A halmaztípus két rekordtípus közötti kapcsolatot ír le. Ábrázoláskor a SET típust nyíllal jelöljük. Három alapeleme van: a SET típus azonosítója, a tulajdonos rekordtípus és egy tag rekordtípus A hálós modell minden halmazában van egy megkülönböztetett elem, ami a tulajdonosrekord, a rekordok rendezettek, a rekordok rendezettsége pedig az adott mezők értékén alapul, vagy a rendszer belső ügye a rendezési szempont. adatbázisok.doc - 32 - 2003.0909

Könyvelés Tóth Károly Dolgozó SET Kovács József Kiss Elemér 2-2. ábra Adatmodellek – hálós adatmodell ábrázolása 2.3 Objektum-orientált adatmodell Az objektum-orientált programozás terjedése az elmúlt évtizedben új adatmodell- és adatbázis-koncepcióhoz vezetett. Az objektum-orientált fogalom azt jelenti, hogy a valós világ objektumait modellező programot az adatszerkezetet és a hozzá tartozó műveletet egységbe foglaló alkotóelemekből, ún. objektumokból építjük fel Az objektumok zártsága nagyobb adat- és műveletbiztonságot jelent a hagyományos programozással szemben. A hagyományos programok esetében az adatok és a műveletek kapcsolata laza, így nagyobb az esély arra, hogy egy nem megfelelő program módosítja valamelyik adatot, illetve nem a megfelelő adatot módosítja. A zártságból következően az objektumorientált modell nem más, mint egy adat- és műveletmodell Az azonos adatstruktúrájú és viselkedésű

objektumokat osztályba soroljuk Egy bizonyos osztályba tartozó adott objektum esetén az objektum előfordulásáról, vagy objektumról beszélünk. Az osztályt téglalappal jelöljük A téglalapon belül az osztály azonosítóját és tulajdonságait, valamint a műveleteket vonallal választjuk el. Az objektumok fontos tulajdonsága az öröklés. Az öröklő objektum a szülő objektum valamennyi tulajdonságát hordozza, viselkedését átveszi. Ezen kívül új, speciális tulajdonságokkal és viselkedéssel is rendelkezhet adatbázisok.doc - 33 - 2003.0909 Az objektum-orientált adatmodell minden igényt kielégítő ábrázolásmódja még nem született meg, aminek oka az objektum-orientált nyelvek különbözősége, és állandó fejlődése. BEOSZTOTT VEZETŐ szem. szám név irányít dolgozik 2-3. ábra Adatmodellek – objektum-orientált adatmodell ábrázolása 2.4 Egyed-kapcsolat adatmodell Az egyed-kapcsolat (Entity Relationship, ER) modellt,

mint a relációs modellezés bevezetőjeként alkalmazzák. Előnyei közé tartozik az egyszerűség és a szoros kapcsolat, a könnyű konvertálhatóság a relációs modell felé Az ER-modell, mint ahogy azt a neve mutatja, három alapelemen nyugszik: - az egyedek, - az egyedek közötti kapcsolatok és - az egyedek tulajdonsági fogalmain. Az ER-modell kizárólag a valóság strukturális leírásán alapszik, megengedve bizonyos egyszerűbb integritási feltételeket is. Ezen egyszerűség miatt, korábban vita bontakozott ki, hogy menyiben tekinthető egyáltalán adatmodellnek az ER rendszer. Egyesek szerint ez a modell csak az adattervezést támogatja, nem biztosít megfelelő precizitást, ezért nem is tekinthető adatmodellnek. Az ER fogalomrendszerében a modellezett világ azon szereplőit, amelyek önálló léttel bírnak és melyekről több különböző adatot tartunk nyilván, egyedeknek nevezik. Az egyedek között vannak hasonló szerkezetűek, és vannak

egymástól igen különböző felépítésűek. A hasonló felépítésű egyedek alkotnak egy egyedtípust Minden egyedtípus több egyed előfordulást ölel át, ahol egy egyed előfordulás egy konkrét egyedet jelöl. Az egyedeket az azokat jellemző tulajdonságokkal írjuk le. Tehát minden egyed rendelkezik egy sor tulajdonsággal, melyek más-más értékeket vehetnek fel. Az egyes egyedtípusok elsődlegesen a típushoz tartozó tulajdonságok körében téradatbázisok.doc - 34 - 2003.0909 nek el egymástól. Az egyedtípus lényeges jellemzője tehát a hozzá tartozó tulajdonságok köre Az egyed előfordulások és az egyedtípusok nem izolált, elszigetelt szereplői a modellezett világnak. Az egyedek kapcsolatban állnak más egyedekkel, egy összetettebb struktúrát hozva létre. Tehát a modellben az egyedek mellett a kapcsolataiknak is szerepelni kell. Az egyedek között különböző bonyolultságú kapcsolatok állhatnak fenn és a modell akkor jó, ha

alkalmas a kapcsolatok árnyalt kifejezésére. Az ER-modell elemkészlete A modell a valóság hűbb leképezésére az egyszerű egyed és kapcsolat elemek mellett megkülönbözteti több változatát mind az egyedeknek, mind a kapcsolatoknak. E változatok között lényeges jelentésbeli és viselkedési különbségek vannak, s ezen kívül egészen másféle relációs modellbeli elemekre képződnek le. Az ER-modell egyik lényeges tulajdonsága, hogy egy grafikus jelölésrendszert alkalmaz. A grafika, a szöveges leírástól eltérően sokkal kifejezőbb, lényegre törőbb az emberek számára, így kiválóan alkalmas a fontosabb fogalmak és kapcsolatok megjelenítésére. Egyed: Egy, a külvilág többi részétől egyértelműen megkülönböztethető dolog. - Normál egyed: olyan tulajdonságcsoporttal rendelkezik, mely egyértelműen azonosítja az egyedet (például embernél a személyi szám, autónál a rendszám). Jele egy téglalap, melynek belsejében az

egyedtípus azonosító neve áll. Ember 2-4. ábra Adatmodellek – egyed jelölése - Gyenge egyed: nincs azonosító tulajdonságrendszere, így más egyedhez fűződő kapcsolata szükséges az azonosításához. (Ha az autóknak csak a típusát tudjuk, akkor ahhoz, hogy a sok azonos típusú autóból ki tudjuk választani a megfelelőt, szükségünk van egy másik egyed – például a tulajdonos – adatainak megadására is.) Jele a dupla kerettel rajzolt téglalap, középen az azonosító névvel adatbázisok.doc - 35 - 2003.0909 Autó 2-5. ábra Adatmodellek – gyenge egyed jelölése Tulajdonság: Az egyed egy meghatározott jellemzője. - Egyszerű tulajdonság: egy elemi értékkel leírható tulajdonságot ad meg. Az ember kora például egyszerű tulajdonság, hiszen egy skalár szám elegendő a megadásához. A hobbi már nem egyszerű tulajdonság, hiszen több értékeket is felvehet egyidejűleg, hiszen egy embernek egyszerre több hobbija is lehet. A

tulajdonságok ellipszisben adjuk meg, az ellipszis közepébe írva a tulajdonság azonosító nevét. A tulajdonság önmagában nem állhat, ezért mindig meg kell adni, hogy mely egyedhez, vagy kapcsolathoz kötődik. A kapcsolódást egy vonallal jelöljük, amely a megfelelő tulajdonságot és az egyedet köti öszsze. Ember kor 2-6. ábra Adatmodellek – egyszerű tulajdonság jelölése - Összetett tulajdonság: olyan tulajdonság, amely több elemi tulajdonság együttesére bontható. Ilyen tulajdonság lehet például a cím, amely felbontható az irányítószám, település, utca, házszám elemi adatok együttesére. Az öszszetett tulajdonságot is ellipszissel jelöljük, melyhez hozzákötjük az illeszkedő elemi tulajdonságok szimbólumait. irányítószám Ember település cím utca házszám 2-7. ábra Adatmodellek – összetett tulajdonság jelölése - Kulcs tulajdonság: az egyed egyértelmű azonosítására szolgáló tulajdonság. Az ember

egyed esetén például a személyi szám töltheti be ezt a szerepet. A adatbázisok.doc - 36 - 2003.0909 kulcstulajdonságot úgy jelöljük ki, hogy a tulajdonság azonosító nevét aláhúzzuk egy folytonos vonallal. Ember személyi szám 2-8. ábra Adatmodellek – kulcs tulajdonság jelölése - Többértékű tulajdonság: olyan tulajdonság, amely nem csak egy elemi értéket, hanem több elemi értéket, értékek egy tömbjét vehet fel. Így például az ember egyed iskolai végzettség tulajdonságának leírására több elemi értéket is meg lehet adni, hiszen többféle végzettsége is lehet valakinek. A többértékű tulajdonságot egy dupla keretű ellipszissel jelöljük. Ember végzettség 2-9. ábra Adatmodellek – többértékű tulajdonság jelölése - Leszármaztatott tulajdonság: olyan tulajdonság, melynek értéke más tulajdonságokból vezethető le, származtatható. Így például az autó egyed esetén a bruttó ár kiszámolható a

nettó árból és az ÁFA kulcs mértékéből. A leszármaztatott tulajdonság jele egy szaggatott vonallal határolt ellipszis Azt nem jelöljük, hogy mely más tulajdonságokból és mi módon származtatható az érték Bruttó ár Autó ÁFA Nettó ár 2-10. ábra Adatmodellek – leszármaztatott tulajdonság jelölése Kapcsolat: az egyedek között fennálló viszonyt hordozza. - 1:1 kapcsolat: a kapcsolatban mindkét egyedtípus előfordulásai csak egyetlenegy előforduláshoz rendelődnek a másik egyedtípusból. Például egy férfi adatbázisok.doc - 37 - 2003.0909 csak egy nőnek lehet a férje és egy nő is csak egy férfinak lehet a felesége . A kapcsolatot egy rombusszal jelöljük, melybe beírjuk kapcsolatot leíró azonosító nevet. A négyszög átellenes csúcsaiból egy-egy nyilat húzunk, melyek a kapcsolódó egyedekhez vezetnek. Férfi Nő házas 2-11. ábra Adatmodellek – 1:1 kapcsolat jelölése - 1:N kapcsolat: abban különbözik az

1:N kapcsolattípustól, hogy az egyik, egyedtípus előfordulásai több előfordulással tarthatnak kapcsolatot a másikból, de a másik előfordulás továbbra is csak egy előforduláshoz kapcsolódhat. Például egy autónak csak egy tulajdonosa lehet, egy ember viszont több autót is birtokolhat. A 1:N kapcsolat ábrázolásánál azon egyedbe, melyből több is kapcsolódhat a másik egyedhez, egy kettősnyíl vezet. Ember Autó birtokol 2-12. ábra Adatmodellek – 1:N kapcsolat jelölése - N:M kapcsolat: olyan kapcsolattípus, melyben mindkét egyedtípus előfordulásai több előfordulással is tarthatják a kapcsolatot a másik egyedtípusból. Például egy oktató több tantárgyat is taníthat és egy tárgy oktatásában több oktató vehet részt. A kapcsolat ábrázolásánál mindkét kapcsolódó egyedbe kettősnyíl mutat. Oktató tanít Tantárgy 2-13. ábra Adatmodellek – N:M kapcsolat jelölése - N-ed fokú kapcsolat: a kapcsolatban nemcsak

kettő, hanem ennél több egyed vesz részt. Ilyen kapcsolatra példa a vásárlás kapcsolat, melyben a vá- adatbázisok.doc - 38 - 2003.0909 sárló, az eladó és az árú kapcsolódik össze, hiszen a vevő, bizonyos terméke(ke)t vásárol egy adott eladótól. Az n-ed fokú kapcsolatot úgy ábrázoljuk, hogy a rombuszból több nyíl fut ki. vásárló vesz eladó áru 2-14. ábra Adatmodellek – N-ed fokú kapcsolat jelölése - Totális kapcsolat: egy egyed totálisan vesz részt a kapcsolatban, ha minden egyed előfordulása részt vesz egy kapcsolat előfordulásban, azaz nincs olyan egyed előfordulás, mely nem kapcsolódna egy másik egyedtípus valamely előfordulásához. Azok az egyedek, amelyek nem totálisan vesznek részt a kapcsolatban, parciális kapcsolatot alkotnak Például abban az esetben, ha minden autónak van tulajdonosa, akkor az autó totális kapcsolatban van ez emberrel a tulajdonosi kapcsolatban Az ember viszont csak parciálisan vesz

részt a tulajdonosi kapcsolatban, mivel lehetnek olyan emberek, akiknek nincs autójuk. 2.5 Relációs adatmodell A relációs adatmodell napjaink legelterjedtebb adatmodellje; a modellel egyszerű, könnyen megtanulható leírási módot sikerült megvalósítani. Egyszerűségének következtében a felhasználók körében gyorsan népszerűvé vált és a személyi számítógépek piacán sok implementációja született Az elméleti megalapozottság a kutatók, szakemberek szimpátiáját is kiváltotta, így ez a modell számos új fejlesztés alapját képezi. Az adatmodell fontos előnye az egyszerűség mellett a modell rugalmassága A relációs modell előnyei, főbb jellemzői az alábbiakban foglalható össze: - Egy egyszerű és könnyen megérthető strukturális részt tartalmaz. A strukturális rész egyszerűsége a közérthetőség mellett az alkalmazhatóságot is növeli, hiszen az egyszerűbb formulák általánosabban fordulnak elő a kü-

adatbázisok.doc - 39 - 2003.0909 lönböző adatforrásokban. - A modellhez olyan műveleti rész csatlakozik, amely a programozási nyelveknél egyszerűbb kezelői felületet biztosít, annak érdekében, hogy minél általánosabban, minél szélesebb körben lehessen használni. - Az adatmodell integritási részében egyszerű, közérthető és ezzel együtt hatékony feltételeket definiál. Az integritási feltételek előnye, hogy deklaratív megadásukkal a szabályok magában az adatbázisban kerülnek letárolásra, és a relációs adatbázis-kezelő automatikusan ellenőrizni fogja e szabályok betartását, illetve csak olyan tevékenységeket fog megengedni, amelyek nem sértik a megadott integritási előírásokat. - Egyszerű tervezési metodika; az adatbázis tervezése jól definiált, egyértelmű elméleti alapokon nyugszik. A tervezés elméleti alapjai az úgynevezett normalizálási szabályokon alapulnak, amely a relációs modell strukturális

lehetőségeit és a modellezendő fogalmak közötti függőségi kapcsolatokat veszi figyelembe. A normalizálás segítségével egy hatékony, áttekinthető adatmodellt kapunk - Nagyfokú logikai függetlenség. A relációs modell elrejti a felhasználók elől a megvalósítás részleteit. A felhasználó nyugodtan használhatja a hozzá közel álló fogalmakat, a rendszer egy belső optimalizáló komponens segítségével ki fogja választani a leghatékonyabb fizikai megvalósítást. - A relációs modell tiszta elméleti alapokon nyugszik. A halmazelméletre és a matematikai logikára alapozva a relációs modell az első, mélyebb elméletre támaszkodó adatmodell. Ennek fő előnye, hogy a modell megbízhatóbb és kiszámíthatóbb lesz, és könnyebb a modell tulajdonságainak a vizsgálata is A megbízhatóság garantálja, hogy nem fogják kellemetlen események, váratlan hibák megzavarni az adatmodellen alapuló adatbázis-kezelők működését. -

Egységesség. Az adatbázisban mind a normál, mind a struktúrát leíró metaadatok tárolása ugyanazon módon és formalizmussal történik és ugyanazon utasításokkal valósítható meg. adatbázisok.doc - 40 - 2003.0909 Egyedhalmazok ábrázolása A relációs modellben az adatokat kétdimenziós táblában tároljuk és a kívánt adatokat relációs műveletek segítségével kereshetjük vissza. Ábrázoláskor az egyedhalmaz lesz a táblázat neve A táblának minden sorában azonos számú oszlop található. A táblázat első sora a reláció fejrésze. Itt találhatók az egyértelmű oszlopnevek (a reláció attribútumai, tulajdonságai), melyek az oszlopokban lévő adatok jelentését adják meg A táblázat fejrésztől különböző oszlopait mezőnek neveznik. Egy-egy oszlopban lévő adatok csak ugyanannak az értékhalmaznak az elemei lehetnek. Az oszlopok száma a táblázat fokszáma A táblázat sorai a relációk sorai, más néven tuple-k, vagy

rekordok. Az oszlopok és a sorok sorrendjét felcserélhetjük, ez a relációt nem, csak megjelenését változtatja meg. EMBER név Kovács Szabó Kiss Tóth város Szeged Budapest Szolnok Szeged foglalkozás kor órás 45 tanár 50 rendőr 47 tűzoltó 30 2-15. ábra Adatmodellek – relációs modell táblája A modell fontos fogalma a kulcs. Az elsődleges kulcs a táblázat sorainak egyértelmű megkülönböztetésére, azonosítására használható A kulcs nem veheti fel kétszer ugyanazt az értéket egy táblán belül. Elemi kulcsról beszélünk akkor, ha a reláció valamelyik eleme (a táblázat valamelyik attribútuma, oszlopa) alkalmas a rekordok (sorok) egyértelmű megkülönböztetésére. Ha egynél több attribútum szükséges egy rekord megtalálásához, összetett elsődleges kulcsról beszélünk. Ha egy relációt több attribútum is egyértelműen meghatároz, akkor szabadon választhatjuk meg, hogy melyik legyen az elsődleges kulcs, a többit

alternatív kulcsnak nevezzük. Az elsődleges kulcsot a többi tulajdonságtól aláhúzással különböztetjük meg. A kulcs kiválasztásánál ügyelnünk kell arra, hogy a kulcsban szereplő attribútumok száma a lehető legkevesebb legyen. adatbázisok.doc - 41 - 2003.0909 AUTÓ rendszám ARC-125 TOP-942 POK-810 SAM-357 típus Opel Trabant Lada Opel szín fehér zöld piros fehér kor 2 28 17 1 2-16. ábra Adatmodellek – elsődleges kulcs Egy táblából a táblával logikai kapcsolatban lévő másik tábla egy meghatározott sorára az idegen kulcs segítségével tudunk hivatkozni. Az idegen kulcsnak megfelelő érték abban a táblában, amelyiknek rekordjára hivatkozunk, elsődleges kulcs. EMBER sorszám 1 2 3 4 AUTÓ rendszám ARC-125 TOP-942 POK-810 SAM-357 név Kovács Szabó Kiss Tóth város Szeged Budapest Szolnok Szeged kor 45 50 47 30 típus Opel Trabant Lada Opel szín fehér zöld piros fehér kor 2 28 17 1 rendszám TOP-942 POK-810 ARC-125

SAM-357 2-17. ábra Adatmodellek – idegen kulcs Kapcsolatok ábrázolása A relációs adatmodellben a kapcsolatokat is táblázatok segítségével ábrázoljuk. A legegyszerűbb esetben, 1:1 kapcsolat esetén eljárhatunk úgy – ahogyan azt az előbbi ábra is mutatta –, hogy az egyik táblát kiegészítjük a logikailag hozzá kapcsolódó másik tábla elsődleges kulcsa felhasználásával. A kapcsolatra a tulajdonság neve utal Más esetekben, 1:N, N:M kapcsolatoknál új táblát kell létrehoznunk. A kapcsolat táblába oszlopai a két összekapcsolt tábla elsődleges kulcsai lesznek. adatbázisok.doc - 42 - 2003.0909 EMBER sorszám 1 2 3 4 név Kovács Szabó Kiss Tóth város Szeged Budapest Szolnok Szeged kor 45 50 47 30 szín fehér zöld piros fehér kor 2 28 17 1 BIRTOKOL sorszám rendszám 1 TOP-942 2 POK-810 3 ARC-125 4 SAM-357 AUTÓ rendszám ARC-125 TOP-942 POK-810 SAM-357 típus Opel Trabant Lada Opel 2-18. ábra Adatmodellek – táblák

összekapcsolása kapcsolat tábla alkalmazásával Abban az esetben, ha csak a táblázat nevét és a tulajdonságokat adjuk meg, az adatok nem, relációs sémáról beszélünk. Jelölése: relációnév (attribútumok felsorolása), például Autó (rendszám, típus, szín, kor) A relációs modell egy vagy több relációs sémát tartalmazhat A relációs sémákból álló halmazt relációs adatbázissémának, vagy röviden adatbázissémának nevezzük Integritási kényszerek A relációs modellhez kapcsolódnak olyan fogalmak is, amely nem közvetlenül az adatszerkezetre hanem az adatbázis integritására vonatkoznak. Az integritási szabályok célja az adatbázis előfordulások lehetséges, megengedett körének behatárolása Az integritási szabályok tehát az adatbázisban lévő adat előfordulásokra adnak megszorításokat. Az integritási szabályokat csoportosíthatjuk aszerint, hogy milyen szinten fogalmazzák meg a megkötéseket. Eszerint

megkülönböztetünk a kulcsokra, mezőkre és értékekre vonatkozó megszorításokat: - Az elsődleges kulcsnak egyedi értékkel kell rendelkeznie, vagyis a táblának nem lehet két olyan sora, amelyben az elsődleges kulcs értékei megegyeznek. Az elsődleges kulcsot alkotó tulajdonság nem lehet üres, null érték - Az idegen kulcs értéke vagy a hivatkozott tábla elsődleges kulcsának va- adatbázisok.doc - 43 - 2003.0909 lamelyik értéke, vagy null érték lehet. - Egyes attribútumok meghatározott értékkészlettel rendelkeznek, például dátumhoz nem írhatunk be szöveget, vagy egyes tulajdonságok csak meghatározott értékeket vehetnek fel. A relációs adatstruktúra helyességének vizsgálata A modell által biztosított elemekkel, egyazon problémakörre, számos egymástól lényegesen eltérő modell készíthető. Ezek a modellek nem lesznek egyformán hatékonya, egyes elkészült modellek tartalmazhatnak bizonyos hibákat, amelyek a

működés hatékonyságát csökkenthetik Rosszul felépített struktúra esetén könnyen előfordulhat, hogy egy adatot – feleslegesen – több helyen is tárolunk. Ez nagyobb kezelendő adatmennyiséget jelent, hiszen ugyanaz az információ sokszorozva foglal helyet A rossz adatmodell tehát redundanciához vezethet A redundancia mellett számos egyéb műveleti nehézséget is okozhatnak a modell hiányosságai. A nem megfelelő relációs modellből eredő problémákat szokás anomáliáknak is nevezni - Beszúrási anomáliáról beszélünk, ha egy rekord felvitelekor, felesleges, már letárolt információkat is újra fel kell vinni. - Módosítási anomáliáról van szó, ha egy információegység módosításához több helyen is módosításra van szükség az adatbázisban. Ez nem csak többletmunkát jelent, de megnöveli az inkonzisztens állapot valószínűségét is, ha valahol elmaradna a módosítás. - Törlési anomáliáról akkor beszélünk, amikor

egy információelem megszűnésekor más, hozzá nem tartozó információk is elvesznek. A felsorolt anomáliák általában abból származnak, hogy nem az igazán összetartozó adatokat veszünk be egy relációba. Hogy mely mezők tartoznak egy relációba, az a mezők közötti összetartozási viszony, a mezők közötti függőségek határozzák meg, ami már a következő fejezet témája. adatbázisok.doc - 44 - 2003.0909 2.6 Egyed-kapcsolat modellből relációs adatmodell Az adatbázis tervezés egyik fontos lépése a logikai adatmodell adatbázismodellbe történő konvertálása. A konverzió során az ER modell elemeit relációs modellelemekkel kell megvalósítanunk Az átalakítás nehézsége abban rejlik, hogy egyrészt bizonyos ER fogalmaknak nincs meg a relációs modellbeli megfelelője, másrészt míg az ER modell szemantika orientált, addig a relációs modellben már más, hatékonysági, integritásőrzési szempontok is érvényesülnek. Az ER

modell elemeinek leképezése Egy reláció egy egyedtípusnak felel meg. A relációs adatmodell egy relációja tehát egy egyedtípus előfordulásait fogja tartalmazni. A reláció neve megegyezik az egyedtípus azonosító nevével A reláció szerkezet is az ER modellből származik A reláció több mezőből épül fel, ahogy az egyedtípus is a tulajdonságokból áll össze. Tehát az első szabály az, hogy az egyedekből készítsünk relációkat, s a hozzá kapcsolódó tulajdonságok legyenek a reláció attribútumai, mezői. EMBER név város kor név Ember város kor 2-19. ábra Adatmodellek – egyed konvertálása A tulajdonság – mező megfeleltetés azonban nem minden esetben alkalmazható, hiszen a mező a relációs modellben csak atomi értéket hordozhat, tehát nem lehet összetett adatérték. Hasonló nehézségekbe ütközünk a kapcsolatok leírásánál is: a relációs modell a kulcs és az idegen kulcs segítségével tárolja a kapcsolatokat.

Mivel az idegen kulcs csak egy értéket tárol, egy rekord-előforduláshoz csak egyetlen egyed előfordulás köthető a kapcsolódó egyedtípusból. Következésképpen az N:M kapcsolatok tárolásánál oda kell figyelni adatbázisok.doc - 45 - 2003.0909 Egyed konvertálása - Normál egyed. Mivel van kulcstulajdonsága, ezért a tulajdonságok alkothatják a reláció mezőit, nincs szükség kiegészítő mezőkre. - Gyenge egyed. Ezen egyedtípus tulajdonságai között nincs olyan, mely egyértelműen azonosíthatná az előfordulásokat, ezért a tulajdonságok önmagukban nem elegendőek a relációhoz, hiszen a relációs modellben minden relációnak léteznie kell kulcs értékének A gyenge egyedet egy másik, normál egyedhez fűződő kapcsolata azonosít. Tulajdonságok konvertálása Egy tulajdonság a reláció egy mezőjének feleltethető meg. - Egyszerű tulajdonság. mivel az egyszerű tulajdonság egy elemi értéket vesz fel, ezért

megfeleltethető egy mezőnek. A mező neve megegyezik a tulajdonság azonosító nevével - Kulcs tulajdonság: mint az egyszerű tulajdonság, de aláhúzással jelöljük ki a kulcs mezőt, vagy mezőcsoportot. - Összetett tulajdonság. A relációs modell mező szerkezete csak atomi értékeket tárolhat, és nem bontható fel további részekre Ebből következően az összetett tulajdonság nem tárolható egy mezőben. Az összetett tulajdonság leképzésére a legegyszerűbb mód, ha felbontjuk az összetett tulajdonságot alkotó elemeire, a felbontást addig végezve, amíg egyszerű tulajdonságokat nem kapunk és ezeket a mezőket vesszük be a relációba. - Többértékű tulajdonság. Többértékű mezők közvetlenül nem tárolhatók a relációban Az összetett tulajdonságok ábrázolásának szokásos módszere, hogy létrehozunk egy újabb relációt, melybe a tulajdonságértékeket tároljuk le. Mivel így több relációba szétkerülnek az egyedtípus

tulajdonságai, külön kell gondoskodnunk, hogy az összetartozó értékeket nyilvántartsuk, ezért ebbe az újonnan létrehozott relációba is bele kell tenni az egyedtípus kulcsmezőjét, amelynek szerepe, hogy kijelölje melyik egyed-előforduláshoz tartoznak az egyes tulajdonságérték előfordulások. adatbázisok.doc - 46 - 2003.0909 - Leszármaztatott tulajdonság. A tulajdonságot normál mezőként be kell hozni a relációba, majd az integritási feltételekkel lehet kijelölni, hogy ez a mező nem közvetlen értékeket tartalmaz, hanem más mezőkből származtatott értékeket. A séma grafikus megjelenítésénél normál mezőként ábrázoljuk a származtatott mezőt is Kapcsolatok - 1:1 kapcsolat. Az egyik rekordot kibővítjük egy új mezővel, mely a kapcsolókulcs szerepét fogja játszani Az így megvalósított kapcsolatnak azonban van egy kis szépséghibája, nevezetesen: semmi sem akadályozza meg, hogy a kapcsoló kulcsot tartalmazó

relációban több rekord előfordulás is ugyanazt az értéket tartalmazza. Ennek megvalósulása egy 1:N kapcsolatot eredményezne Ezt úgy lehetne megelőzni, hogy nem engedjük meg, hogy egy kapcsolókulcs érték többször is előforduljon Ezt úgy érhetjük el, hogy a mezőkhöz rendelünk egy érték egyediséget megszabó feltételt is, így ennek megadása után már nem fordulhat elő ugyanaz a kapcsoló kulcs érték kétszer. - 1:N kapcsolat. Az egyik egyedet kibővítjük egy új mezővel, mely a kapcsolókulcs szerepét fogja játszani A két egyed közül abba kerül beépítésre a kapcsolókulcs, amelyik a másik egyednek maximum egy előfordulásával kapcsolódik Mivel itt egy kapcsolókulcs érték több rekord-előfordulásban is szerepelhet egy reláción belül, ezért – ellentétben az 1:1 kapcsolattal – itt nincs szükség külön integritási feltétel definiálására - N:M kapcsolat. Mindkét, a kapcsolatban előforduló egyedtípus

előfordulásai több másik egyedtípusbeli előforduláshoz is kapcsolódhatnak, ezért minkét kapcsolókulcsnak több értéket kellene felvennie, ami nem megengedett. Így egyik sem tárolható a relációban mezőként. A probléma megoldására létre kell hoznunk egy új relációt, egy kapcsoló relációt, melynek minden rekord előfordulása egy konkrét kapcsolatot reprezentál. Ezen új reláció kulcsának a kapcsolatot kell azonosítania, s erre a két kapcsolódó egyed előfordulás kulcsainak együttesét szokták használni A kapcsoló reláció kulcsa tehát magában foglalja a két kapcsolókulcsot is. Ez a megoldás lehetővé teszi, hogy a kapcsoló relációba mezőként bevegyük azokat a tulajdonságokat is, melyek ma- adatbázisok.doc - 47 - 2003.0909 gát a kapcsolatot jellemzik, s nem csak a kapcsolódó egyedeket. - N-ed fokú kapcsolat. A magasabb fokú kapcsolatok leírására be kell bevezetnünk egy kapcsoló relációt, melynek minden rekord

előfordulása egy konkrét kapcsolatot reprezentál Ezen új reláció kulcsának a kapcsolatot kell azonosítania, s erre a kapcsolódó egyed előfordulások kulcsainak együttesét szokták használni. A kapcsoló reláció kulcsa tehát magában foglalja az n darab kapcsolókulcsot is - Totális kapcsolat. A kapcsolat totális voltának tárolása egyszerű, ha minden egyed előfordulás csak egy kapcsolat előfordulásban szerepel, tehát amikor az egyedhez tartozó reláció tartalmazza a kapcsolatra vonatkozó kapcsolókulcsot. Ekkor a kapcsolat totális jellege azt mondja ki, hogy egyetlen egy előfordulásban sem lehet a kapcsolókulcs értéke üres (null) Ha azonban azon egyed kapcsolata totális, mely több másik egyed-előfordulással is kapcsolatban áll, akkor a feltétel úgy szólna, hogy az adott reláció minden kulcsértékének elő kell fordulnia a másik relációban szereplő kapcsolókulcs értékek között. Ez már egy összetettebb integritási

feltétel, melyet csak bonyolult úton valósíthatunk meg. adatbázisok.doc - 48 - 2003.0909 3. A relációk normál alakjai 3.1 Normalizálás Egy adatbázis megtervezésekor először összegyűjtjük azokat az adatokat, amelyekre szükségünk lesz. Ebből az adathalmazból, valamint az adatokon végzendő műveleti igényekből kiindulva meghatározott lépések sorozatán át jutunk el egyfajta rendet tükröző relációs adatmodellhez. A helyes modell megtervezésére irányuló irányelveket, ennek módszertanát az irodalom normalizálás néven ismeri. A normalizálás során induláskor egyetlen táblázatot alakítunk ki, melyben elhelyezzük a szükséges tulajdonságokat Ezután feltárjuk a táblázat belső szerkezetét, a tulajdonságok közötti összefüggéseket, függőségi viszonyokat; lényegében azt vizsgáljuk meg, hogy a feltárt függőségek eleget teszneke az ún. normál formáknak nevezett követelményeknek A normál formákat megsértő

függőségeket megszüntetjük úgy, hogy a táblázatot meghatározott szabályok szerint további táblázatokra bontjuk. A kapott új táblázatok normálformáknak való megfelelésének ellenőrzését is elvégezzük és, ha szükséges, azokat is további táblázatokra bontjuk. A normalizálás tehát lényegében táblázat szétbontó relációs műveletek sorozata, melynek eredményeképpen egymással kapcsolatban álló, az eredetinél kisebb tárolási igényű relációkat kapunk; egy tervezési metodika, amely segítséget nyújt a logikailag áttekinthetőbb, (törlési, módosítási, beszúrási) anomáliáktól mentes relációs sémák és adatbázis sémák kialakításában. A tervezési irányelveket követelmények formájában adják meg, méghozzá több, egymásra épülő követelmény alakjában. A szakirodalom öt (néha hat) normál formát különít el. E normál formák egymásra épülése azt jelenti, hogy egyes normál formák megkövetelik más

normál formák teljesülését. A normál formák egyre szigorodó követelményrendszert reprezentálnak, illetve egyre szigorodó feltételrendszert jelentenek A tervezés során a legmagasabb normál forma elérése a cél: egy olyan redundanciamentes reláció rendszer, relációs adatbázis, melyben csak a reláció kulcsra vonatkozó tényeket tárolunk. Az első három normál forma a funkcionális függőségekben taadatbázisokdoc - 49 - 2003.0909 lálható redundanciák, míg a negyedik és ötödik a többértékű függőségekből adódó redundanciák megszüntetésére koncentrál. A normalizálás lépéseinek megismeréséhez először át kell tekintenünk, hogy mit értünk funkcionális és többértékű függőség alatt. 3.2 Funkcionális és többértékű függőség A függőség fogalmának segítségével a táblázatok belső szerkezetét tárhatjuk fel. A funkcionális és többértékű függőség a táblák oszlopai között lévő

összefüggéseket írja le. 3.21 Funkcionális függőség Adatok között akkor áll fenn funkcionális kapcsolat, ha egy vagy több adat konkrét értékéből más adatok egyértelműen következnek. Így például a személyi szám és a név között funkcionális kapcsolat van, mivel minden embernek különböző a személyi száma. Jelölése: személyi szám név vagy diagrammal: személyi szám név 3-1. ábra Relációk normál alakja – funkcionális függőségi diagram A funkcionális függőség bal oldalán áll a függőség meghatározója. A jobb oldalon levő egy, csak egy értéket határoz meg a funkcionális függőség. Nem áll fenn funkcionális függőség abban az esetben, ha a meghatározó egy értékét több attribútum értékkel hozhatjuk kapcsolatba. Például a név végzettség állítás nem igaz, mert több személynek lehet azonos neve, akiknek különböző a végzettségük. Az adatok közötti funkcionális függőségek az adatok

természetéből következnek, nekünk „csak” annyi a dolgunk, hogy felismerjük ezeket a törvényszerűségeket. A tervezés során fontos, hogy ezeket a kapcsolatokat pontosan felismerjük és figyelembe vegyük. A funkcionális függőség jobb oldalán több attribútum is állhat. Például a személyi szám név, születési év funkcionális függőség azt fejezi ki, hogy a szeméadatbázisok.doc - 50 - 2003.0909 lyi számból következik az illető neve és születési éve, mivel minden embernek más és más a személyi száma, és minden embernek van egy neve és valamikor született. Diagrammal ábrázolva: név személyi szám születési év 3-2. ábra Relációk normál alakja – funkcionális függőség több meghatározott értékkel. Elképzelhető olyan eset is, amikor két attribútum kölcsönösen függ egymástól. Tipikusan ez a helyzet a házastársak esetén férj személyi száma feleség személyi száma, illetve feleség személyi száma

férj személyi száma. Ebben az esetben mindkét funkcionális kapcsolat igaz, amit a férj személyi száma ↔ feleség személyi száma jelöléssel fejezhetünk ki. A funkcionális függőség bal oldalán is megjelenhet több attribútum. Ilyen esetben ezek együttesen határozzák meg a jobb oldalon szereplő attribútum értékét. Például adatokat mérünk különböző időpontokban és helyszíneken úgy, hogy egy helyszínen akár többször is végzünk mérést. Ebben az esetben a következő funkcionális függőség áll fenn: időpont, helyszín mérési adatok Diagrammal: időpont mérési adatok helyszín 3-3. ábra Relációk normál alakja – funkcionális függőség összetett meghatározóval A funkcionális függőségek egy speciális esete a teljes funkcionális függőség. Erről akkor beszélhetünk, ha a meghatározó oldalon nincsen felesleges attribútum. Például a személyi szám, cím név funkcionális függőség nem teljes funkcionális

függőadatbázisokdoc - 51 - 2003.0909 ség, mivel a személyi szám már egyértelműen meghatározza az emberünk nevét, ehhez nincs szükség a címére is. A funkcionális függőség bevezetésével a relációkat a következő – matematikai jelölésekre épülő – módon is felírhatjuk: - az általános formája: relációnév=({attribútumok},{funkcionális függőségek listája}) - konkrét példával: dolgozó=({személyi szám,név,cím },{személyi számnév}) 3.22 Többértékű függőség Az adatok között fennálló kapcsolatok közül nem mindegyik fejezhető ki a funkcionális függőség segítségével. A többértékű függőség azt jelenti, hogy a meghatározó tulajdonság egyes adatértékeihez a meghatározott tulajdonság egy-egy értékhalmaza tartozik. Például minden oktató taníthat több tantárgyat, illetve ugyanazt a tárgyat több oktató is taníthatja. Ez esetben egyik irányban sincs egyértelmű függőség; ez egy

többértékű függőség, az egyik attribútumhoz egy másik attribútum csoportja, halmaza kapcsolódik A többértékű függőség ábrázolására a dupla nyilat használjuk: oktató tantárgy. A funkcionális függőséghez hasonlóan, a többértékű függőség esetén is előfordulhat, hogy egy attribútum értékéből egynél több további attribútum értéke következik. Az előző példánál maradva: oktató tantárgy, tantárgy kódja oktató tantárgy 3-4. ábra Relációk normál alakja – többértékű függőség diagram A funkcionális és a többértékű függőség között kapcsolat áll fent. Sokszor ugyanazt a függőségi kapcsolatot kifejezhetjük funkcionális és többértékű függőséggel is. Például egy egyetemen különböző szakok léteznek, a szakokon különféle tárgyakat tanítanak. Szeretnénk nyilvántartani szakonként az oktatott órák számát Ezt leírhatjuk funkcionális függőség segítségével: szak azonosító,

tantárgy azonosító óraszám Többértékű függőséggel is kifejezhetjük az adatok kapcsolatát A szak azonosító tantárgy azonosító, óraszám azt fejezi ki, hogy minden szakon a tantárgyak adatbázisok.doc - 52 - 2003.0909 egy csoportját oktatták bizonyos óraszámban. A funkcionális függőségeket mindig előnyben kell részesíteni a többértékű függőséggel szemben. Általános szabály, hogy először az összes funkcionális függőséget írjuk fel, majd csak a hiányzó kapcsolatok leírására használjunk többértékű függőséget 3.3 Első normál forma (1NF) Egy reláció első normál formában van, ha minden attribútuma egyszerű nem összetett adat (minden mezője atomi értéket hordoz), valamint ha minden mezője funkcionálisan függ a kulcsmező csoporttól. Vagyis a függőségi rendszerben léteznie kell egy kulcsnak, s minden más mezőnek ettől kell függenie. Az alábbi táblázatok nem felelnek meg az 1NF feltételeinek,

mert nem egyforma az oszlopok száma, vagy többértékű attribútumuk van, vagy azonos sorai vannak. Név Kis Árpád Hobbi olvasás úszás Nagy Géza tenisz sakk Tóth Erika tánc kung-fu sütés-főzés név Kiss Benedek Kovács Gábor Kovács Gábor cím Budapest Szeged Szeged végzettség főiskola egyetem egyetem 3-5. ábra Relációk normál alakja – 1NF-nek nem megfelelő táblázatok Egy táblázat 1NF-ben van, ha: - minden sora különböző, - az oszlopok száma és sorrendje minden sorban azonos, - minden oszlop csak egy attribútum értéket vesz fel, továbbá - minden sorhoz tartozik egy egyedi kulcs, amitől az összes többi attribútum funkcionálisan függ. adatbázisok.doc - 53 - 2003.0909 Név Kis Árpád Kis Árpád Nagy Géza Nagy Géza Tóth Erika Tóth Erika Tóth Erika Személyi szám 17204124168 12711071125 14908013514 név Kiss Benedek Kovács Gábor Kovács Gábor cím Budapest Szeged Szeged Hobbi olvasás úszás tenisz sakk tánc

kung-fu sütés-főzés végzettség főiskola egyetem egyetem 3-6. ábra Relációk normál alakja – táblázatok módosítása 1NF előírásainak megfelelően. Példa: Egy egyetemi nyilvántartásban szerepel a tanuló azonosítója (tanazon), neve (tannév), lakcíme (cím), szakja (szak), a kar azonosítója (karazon) és neve (karnév), a kari vezető neve (karvez), és a tantárgyak (tantárgy). Foglaljuk össze az adatokat egyetlen táblában: tanazon tannév 812 Szabó Ákos tancím Szeged szak tanár karazon karnév karvez tantárgy 12 tanárképző Kovács matematika biológia kémia 512 Sándor Sándor Szeged filozófia 10 bölcsész Tóth filozófia magyar történelem 912 Vár Anikó Budapest tanár 12 tanárképző Kovács angol magyar matematika 3-7. ábra Relációk normál alakja – táblázat normalizálás előtt Ha átalakítjuk a táblát 1NF-nek megfelelően, a következő táblázatot kapjuk: tanazon 812 812 812 512 512 512 912 912 912 tannév Szabó

Ákos Szabó Ákos Szabó Ákos Sándor Sándor Sándor Sándor Sándor Sándor Vár Anikó Vár Anikó Vár Anikó tancím Szeged Szeged Szeged Szeged Szeged Szeged Budapest Budapest Budapest szak karazon karnév karvez tantárgy tanár 12 tanárképző Kovács matematika tanár 12 tanárképző Kovács biológia tanár 12 tanárképző Kovács kémia filozófia 10 bölcsész Tóth filozófia filozófia 10 bölcsész Tóth magyar filozófia 10 bölcsész Tóth történelem tanár 12 tanárképző Kovács angol tanár 12 tanárképző Kovács magyar tanár 12 tanárképző Kovács matematika 3-8. ábra Relációk normál alakja – táblázat 1NF-ben adatbázisok.doc - 54 - 2003.0909 Kérdés, hogy mi legyen a kulcs, melyek azok az attribútumok amelyek egyértelműen azonosítanak egy sort? A tanazon önmagában nem elegendő a rekordok azonosítására. Szükség van a szak és a tantárgy mezőkre is a sorok egyértelmű azonosításához 3.4 Második normál forma (2NF)

Második normál formában van a reláció, ha az első normál formát teljesíti és ezen felül minden nem kulcs mező a teljes kulcstól függ, de nem függ a kulcs bármely valódi részhalmazától. Ezzel azt fejezzük ki, hogy a kulcs központi szerepet játszik a relációban, minden mezőnek a teljes kulcstól, s nem annak egy részétől kell függnie. A reláció 2NF-ben van, ha: - 1NF-ben van és - a nem kulcs attribútumok funkcionálisan teljesen függnek az elsődleges kulcstól. Példa: Az 1NF-jú táblázatból olyan táblázatokat kell létrehoznunk, amelyekben a kulcs minimális. Nézzük meg a függőségeket: tanazon tannév, tancím, szak karazon, karnév, karvez tantárgy Szemléletesebben ábrázolva: tannév, tancím tanazon karazon szak karnév tantárgy karvez 3-9. ábra Relációk normál alakja – mezők közötti funkcionális függőségek ábrázolása. A rajz alapján következik, hogy a táblázatunkat célszerű három részre felbontani:

adatbázisok.doc - 55 - 2003.0909 tanazon 812 512 912 Kar szak tanár filozófia tannév Szabó Ákos Sándor Sándor Vár Anikó tancím Szeged Szeged Budapest karazon karnév 12 tanárképző 10 bölcsész karvez Kovács Tóth Ki-hova-mit tanazon 812 812 812 512 512 512 912 912 912 szak tanár tanár tanár filozófia filozófia filozófia tanár tanár tanár tantárgy matematika biológia kémia filozófia magyar történelem angol magyar matematika 3-10. ábra Relációk normál alakja – táblázatok 2NF-ben Észrevehetjük, hogy ebben a lépésben megjelennek az idegen kulcsok is. A Tanuló relációban a tazon elsődleges kulcs, mert ez határozza meg a többi tulajdonságot. A Ki-hova-mit relációban elsődleges kulcs a tazon, szak és tantárgy attribútumok kombinációja, mivel ez határoz meg egy adott sort. Idegen kulcsok a tanazon és a szak mezők, mert a másik két táblára ezek segítségével hivatkozunk. A Kar relációban az elsődleges kulcs a

szak, vagy a karazon. 3.5 Harmadik normál forma (3NF) Harmadik normál formában van a reláció, ha teljesíti a második normál formát és ezenkívül igaz, hogy nem áll fenn tranzitív függőség, azaz nem áll fenn az egyik nem kulcs mezőből egy másik nem kulcs mezőbe irányuló függőség. Ilyen estben ugyanis a kulcs a köztes mezőn keresztül, tranzitíven határozza meg a másik mező értékét. A köztes mező a másik mezőnél egyfajta kulcs szerepet játszik. A reláció 3NF-ben van, ha: - 2NF-ben van, - funkcionális függés csak az elsődleges kulcsból indul ki, a közvetett (tranzitív) függéseket megszüntetjük. Példa: A Kar nevű táblánkban vannak olyan mezők, amelyek közvetve is függnek az elsődleges kulcstól, így a szak meghatározza a kar azonosítóját, a kar azonosítója a kar nevét és a kar vezetőjét. Így még mindig maradtak rendellenességek a táblázatunkban, amit meg kellene szüntetni Ha az egyik kar indít egy új

szakot, akkor ismét be kell vinnünk a kar nevét, és vezetőjét feleslegesen. Célszerű tehát a Kar nevű táb- adatbázisok.doc - 56 - 2003.0909 lánkat két újabb táblára bontani megszüntetve ezzel a közvetett függőségeket: Tanuló tanazon 812 512 912 tannév Szabó Ákos Sándor Sándor Vár Anikó Kar karazon karnév 12 tanárképző 10 bölcsész Szak szak tanár filozófia Ki-hova-mit tanazon 812 812 812 512 512 512 912 912 912 tancím Szeged Szeged Budapest karvez Kovács Tóth szak tanár tanár tanár filozófia filozófia filozófia tanár tanár tanár tantárgy matematika biológia kémia filozófia magyar történelem angol magyar matematika karazon 12 10 3-11. ábra Relációk normál alakja – táblázatok 3NF-ben 3.6 Negyedik normál forma (4NF) A harmadik normál formáig mindenféleképpen érdemes normalizálni a relációkat. Legtöbbször elegendő is az első három normál formának megfelelő relációk alkalmazása.

Előfordulhatnak azonban olyan esetek is, amikor még ezután is maradnak anomáliák és feleslegesen tárolt adatok. A negyedik és ötödik normálforma a többértékű függőségekből adódó redundancia kiszűrését szolgálja Egy reláció negyedik normál formában van, ha egy XY többértékű függőséget tartalmazó relációban csak az X és Y-ban megtalálható attribútumokat tartalmazza. Vagyis a reláció 4NF-ben van, ha: - 3NF-ben van, - legfeljebb egy többértékű függés van benne. Példa: Oktatók különböző tantárgyakat tanítanak különböző szakokon. Egy tárgyat több szakon is oktatnak és egy szakon több tantárgyat is tanulnak. Egy oktató is többféle tárgyat taníthat, illetve ugyanazt a tárgyat több oktató is taníthatja. Felveszszük az adatokat, majd átalakítjuk úgy, hogy a 3NF-nak is megfeleljen Az így kapott táblában az azonosíthatóság érdekében kulcsnak a három oszlop kombinációját kell vennünk

(oktató+tantárgy+szak). Mégis észrevehetjük, hogy sok ismétlődés van a táblázatunkban. A felesleges tárolási igényt további szétbontással csökkenthetjük Az adatbázisok.doc - 57 - 2003.0909 így kapott új táblázatainknak továbbra is összetett elsődleges kulcsai vannak: a kimit-oktat relációban oktató+tantárgy, a ki-hol-oktat relációban pedig oktató+szak. Az oktató mindkét táblában idegen kulcs, így ezzel hivatkozhatunk a másik táblára. A kiindulási pontból tehát, ahol a táblázatunkban a mezők között több többértékű függés volt (oktató és tantárgy, valamint oktató és szak között), eljutottunk oda, hogy kaptunk két olyan táblázatot, amelyben már csak egy-egy többértékű függés található. Oktatás oktató tantárgy szak Szabó Elek fizika informatika matematika fizika műszaki Tóth Erika kémia biológia tanár Oktatás oktató Szabó Elek Szabó Elek Szabó Elek Szabó Elek Szabó Elek Szabó Elek Tóth Erika

Tóth Erika tantárgy fizika fizika fizika matematika matematika matematika kémia kémia szak informatika fizika műszaki informatika fizika műszaki biológia tanár Ki-mit-oktat tantárgy oktató Szabó Elek fizika Szabó Elek matematika Tóth Erika kémia ki-hol-oktat oktató Szabó Elek Szabó Elek Szabó Elek Tóth Erika Tóth Erika szak informatika fizika műszaki biológia tanár 3-12. ábra Relációk normál alakja – táblázat átalakítása 4NF-ra 3.7 Ötödik normál forma (5NF) Az ötödik normál forma esetén még tovább bonthatjuk a relációkat a redundancia megszüntetése érdekében. Ugyanakkor mivel ez már csak nagyobb tároló terület felhasználásával lehetséges, ezért általában az adatbázis tervezője dönt arról, hogy az ötödik normál formát és a nagyobb adatbázist vagy a redundanciát és a komplikáltabb frissítési, módosítási algoritmusokat választja. adatbázisok.doc - 58 - 2003.0909 Példa: A Ki-mit-oktat és a

Ki-hol oktat mellé felvesszük a hol-mit-oktatnak relációt is: Ki-mit-oktat tantárgy oktató Szabó Elek fizika Szabó Elek matematika Tóth Erika kémia ki-hol-oktat oktató Szabó Elek Szabó Elek Szabó Elek Tóth Erika Tóth Erika hol-mit-oktatnak tantárgy szak fizika informatika fizika fizika fizika műszaki matematika informatika matematika fizika matematika műszaki kémia biológia kémia tanár szak informatika fizika műszaki biológia tanár 3-13. ábra Relációk normál alakja – 5NF 3.8 A normalizálás eredménye A normalizálás eredményeképpen olyan függőségi rendszert kaptunk, amely tiszta és egyértelmű. Minden táblánál léteznie kell egy függőségi centrumnak, a kulcsnak, és minden más mezőhöz léteznie kell függőségi kapcsolatnak a kulcsból. Ezeken a függőségeken kívül a relációséma nem tartalmazhat más függőségeket Az elkészült, normalizált modell már mentes kell legyen azon alapvető tervezési hibáktól, melyek

anomáliákat okoznak. Ezzel sikerülhet egy a szemantikai tartalmat is a lehetőségek szerint megőrző és a hatékonysági szempontokat is figyelembe vevő relációs adatmodellt alkotni, melyet felhasználhatunk az adatbázis megvalósításához. Azt is meg kell azonban jegyeznünk, hogy bizonyos műveletek hatékonyabb végrehajtása érdekében egyes esetekben le kell mondanunk a tisztaságról, áttekinthetőségről, és össze kell vonnunk olyan adatokat is egy relációba, amelyeknek a normalizálás elmélete szerint külön relációkban kellene helyet foglalniuk. adatbázisok.doc - 59 - 2003.0909 4. Műveletek, relációs algebra A relációs modell felépítésében annak strukturális és integritási komponensei vesznek részt, e komponensekből áll össze a relációs adatstruktúra. Az itt megadott szabályok határozzák meg, hogy hogyan nézhet ki egy adott adatbázis Ezek a komponensek az adatbázis bármely időpontbeli állapotaira vonatkoznak, időtől

függetlenek, ezért statikus elemeknek nevezzük őket. Az adatbázisok azonban nem holt, befagyott rendszerek, struktúrák. Az adatbázis értelme, hogy használják azt. A felhasználás során a felhasználók lekérdezhetik, vagy módosíthatják az adatbázis tartalmát. Az adatbázis akkor lesz tehát élő, ha csatlakozik hozzá egy olyan funkciócsoport is, amely lehetővé teszi az adatbázisban tárolt adatok lekérdezését és módosítását. Ezeket a komponenseket – mivel az adatbázis változásaihoz, megváltoztatásához kapcsolódnak – dinamikus komponenseknek nevezzük. A relációs adatmodell műveleti része ezeket a dinamikus adatkezelő és adatlekérdező lehetőségeket foglalja magába A relációkból elméletileg igen sokféleképpen, többféle mechanizmussal lehet adatokat kiolvasni. Az itt ismertetésre kerülő műveletcsoportot összefoglalóan relációs algebrának nevezik. A relációs algebra az alapja a ma már szabványként elfogadott és

leginkább elterjed adatlekérdező relációs parancsnyelvnek, az SQL-nek is. A relációs adatmodell műveleti része a relációkon alapul, vagyis minden művelet a relációkon értelmezett, bemenő operandusai csak relációk lehetnek. A relációs algebra egyszerű, de hatékony módszereket ad a kezünkbe ahhoz, hogy a meglévő relációkból új relációkat hozzunk létre. A relációs műveletek csoportjai: - hagyományos halmazműveletek – például az egyesítés, metszet, és különbség, - műveletek, amelyek a reláció bizonyos részeit elhagyják – például a kiválasztás, vetítés, - műveletek, amelyek két reláció sorait kombinálják – például a keresztszorzat és az összekapcsolás, - egy művelet, ami nem befolyásolja a reláció sorait, de módosítja a reláció sé- adatbázisok.doc - 60 - 2003.0909 máját, vagyis az attribútumok és a reláció nevét – ez az átnevezés. E műveletek nem elegendőek a relációkon

elvégzendő összes számításhoz, ugyanis nagyon korlátozott lehetőséget biztosítanak, mégis jelentős részét tartalmazzák azoknak a műveleteknek, amelyeket az adatbázisokkal tenni akarunk. A műveletek egyik része adatkezelésre (felvitel, módosítás, törlés), a másik része pedig adatlekérdezésre (adatok különböző szempontok szerinti megjelenítésére) használható. Tekintsük át a relációs algebra körébe tartozó műveleteket: - átnevezés (egyoperandusú), - metszet (kétoperandusú), - szelekció (egyoperandusú), - különbség (kétoperandusú), - projekció (egyoperandusú), - osztás (kétoperandusú), - összekapcsolás (kétoperandusú), - kiterjesztés, - keresztszorzat (kétoperandusú), - csoportosítás. - unió (kétoperandusú), 4.1 Átnevezés A relációs algebra talán legegyszerűbb művelete. A művelet: RENAME(oszlop1,oszlop2) Végrehajtás után az oszlop1 nevű oszlop neve oszlop2 lesz. Példa: Az

Oktatás táblázatban tartjuk nyilván a tanárok nevét és beosztását. Az eredeti relációnk: Oktatás(tanárnév,beosztás) Mivel nem csak tanárok oktatnak, módosítjuk az oszlop nevét: RENAME(tanárnév,oktatónév) Az átnevezés eredménye: Oktatás(oktatónév,beosztás) 4.2 Szelekció (Korlátozás) A relációnak azokat a sorait kapjuk eredményül, amelyek megfelelnek egy adott feltételnek. A művelet: RESTRICT relációnév WHERE feltétel Összetett feltételt is megadhatunk az AND (és) OR (vagy) NOT (nem) logikai kifejezések és a > = < relációjelek használatával. Példa: Az alábbi táblából kiválogatjuk a fehér színű Opel típusú autók adatait: adatbázisok.doc - 61 - 2003.0909 FehérOpel = RESTRICT Autó WHERE szín=”fehér” AND típus=”Opel”. Eredményül egyetlen sort kapunk. Autó rendszám ATC-812 RSA-101 LAK-941 típus Opel Opel Suzuki FehérOpel rendszám típus ATC-812 Opel szín fehér kék fehér ár 3 000 000 2

800 000 1 900 000 szín fehér ár 3 000 000 4-1. ábra Relációs algebra – szelekció 4.3 Projekció (vetület) A projekció a táblázat leszűkítését jelenti bizonyos oszlopaira. Akkor használjuk, ha csak bizonyos oszlopok tartalmára vagyunk kíváncsiak. A művelet: relációnév PROJECT(oszlop1,oszlop2oszlopn) Példa: Csak az autók típusára vagyunk kíváncsiak: AutóTípus = Autó PROJECT(típus) Autó rendszám ATC-812 RSA-101 LAK-941 típus Opel Opel Suzuki szín fehér kék fehér ár 3 000 000 2 800 000 1 900 000 AutóTípus típus Opel Opel Suzuki 4-2. ábra Relációs algebra – projekció Mint ebben az esetben is, néha előfordulhat, hogy kapott új táblában két, vagy több rekord is meg fog egyezni, márpedig az elméleti relációs adatmodellben ilyen nem lehetséges. A gyakorlatban azonban az adatbázis-kezelő rendszerek minden előfor- adatbázisok.doc - 62 - 2003.0909 dulást meghagynak az eredménytáblában, mivel a többszöri

előfordulás is információt nyújthat az adatbázis felhasználójának. Az adatbázis-kezelők általában külön beállítási lehetőséget biztosítanak a többszörösen előforduló rekordok kiszűrésére 4.4 Keresztszorzat Két reláció keresztszorzatát úgy kapjuk meg, hogy az első reláció minden sorához hozzáírjuk a második reláció minden sorát. A műveletet abban az esetben, ha a két táblában van két azonos nevű oszlop, nem végezhetjük el. Ilyenkor az egyik oszlopot először át kell nevezni. Ezt a műveletet ritkán alkalmazzuk, mert nagyon ritkán van értelme, ezen kívül két nagyobb méretű tábla keresztszorzata egy hatalmas tárigényű, kezelhetetlen méretű táblázatot eredményezhet. A művelet: relációnév1 TIMES relációnév2 Példa: Három fiú és három lány tanul táncolni. A táncórán minden lány bármelyik fiúval táncolhat, és fordítva. Az összes lehetséges kombinációt így állíthatjuk elő: párok = lányok

TIMES fiúk Lányok l név Krisztina Ágnes Anikó l magas 180 165 172 Párok l név Krisztina Krisztina Krisztina Ágnes Ágnes Ágnes Anikó Anikó Anikó l magas 180 180 180 165 165 165 172 172 172 Fiúk f név Ákos Balázs Ferenc f név Ákos Balázs Ferenc Ákos Balázs Ferenc Ákos Balázs Ferenc f magas 178 182 165 f magas 178 182 165 178 182 165 178 182 165 4-3. ábra Relációs algebra – keresztszorzat adatbázisok.doc - 63 - 2003.0909 4.5 Unió (Halmazegyesítés) A halmazegyesítés kétoperandusú művelet. Mindkét táblának ugyanolyan szerkezetűnek kell lennie, hiszen az eredményreláció mindkét reláció rekord előfordulásait, azok összes sorát tartalmazza. Az eredményreláció struktúrája megegyezik a bemenő relációk struktúrájával Azok a sorok amelyek mindkét táblában szerepelnek, az új táblában csak egyszer fognak megjelenni. A művelet: relációnév1 UNION relációnév2 Példa: A „nyugati”, valamint „keleti”

gépkocsik adatait tartalmazó táblából elkészítjük azt a táblát, ami valamennyi autó adatait tartalmazza: ÚjAutó = Autó1 UNION Autó2 Autó1 rendszám ATC-812 RSA-101 LAK-941 típus Opel Opel Suzuki szín fehér kék fehér ár 3 000 000 2 800 000 1 900 000 Autó2 rendszám ROC-512 ALU-019 SPA-310 típus Lada Trabant Skoda szín piros zöld fehér ár ÚjAutó rendszám ATC-812 RSA-101 LAK-941 ROC-512 ALU-019 SPA-310 típus Opel Opel Suzuki Lada Trabant Skoda szín fehér kék fehér piros zöld fehér ár 3 000 000 2 800 000 1 900 000 500 000 30 000 1 500 000 500 000 30 000 1 500 000 4-4. ábra Relációs algebra – unió 4.6 Metszet A metszet két relációban mindkét helyen előforduló rekord előfordulásokat adja viszsza az eredménytáblában. A művelet csak abban az esetben hajtható végre, ha a két reláció szerkezete megegyezik. A művelet: adatbázisok.doc - 64 - 2003.0909 relációnév1 INTERSECTION relációnév2 Példa: Egy új

táblába tesszük azokat az autókat, amelyek mindkét régi táblában szerepelnek: KözösAutó = Autó1 INTERSECTION Autó2 Autó1 rendszám ATC-812 ALU-019 LAK-941 típus Opel Trabant Suzuki szín fehér zöld fehér ár 3 000 000 30 000 1 900 000 Autó2 rendszám ROC-512 ALU-019 SPA-310 típus Lada Trabant Skoda szín piros zöld fehér ár szín zöld ár KözösAutó rendszám típus ALU-019 Trabant 500 000 30 000 1 500 000 30 000 4-5. ábra Relációs algebra – metszet 4.7 Különbség A különbség kétoperandusú művelet, és csak akkor hajtható végre, ha a táblázatok oszlopai megegyeznek. A művelet az elsőként vett relációban megtalálható, de a másodikban nem szereplő rekord előfordulásokat adja vissza az eredménytáblában. A különbség művelete nem szimmetrikus, azaz az eredmény függ az operandusok megadási sorrendjétől. A művelet: relációnév1 EXCEPTION relációnév2 Példa: Az Opel autótípust már külön táblában

tároljuk, ezért nincs szükség arra, hogy az összesített táblában is szerepeljenek az adatai: NemOpel = Autó EXCEPTION Opel adatbázisok.doc - 65 - 2003.0909 Autó rendszám ATC-812 RSA-101 LAK-941 ROC-512 ALU-019 SPA-310 típus Opel Opel Suzuki Lada Trabant Skoda szín fehér kék fehér piros zöld fehér ár 3 000 000 2 800 000 1 900 000 500 000 30 000 1 500 000 Opel rendszám típus ATC-812 Opel RSA-101 Opel szín fehér kék ár 3 000 000 2 800 000 NemOpel rendszám LAK-941 ROC-512 ALU-019 SPA-310 szín fehér piros zöld fehér ár 1 900 000 500 000 30 000 1 500 000 típus Suzuki Lada Trabant Skoda 4-6. ábra Relációs algebra – különbség 4.8 Összekapcsolás Az összekapcsolás, egyesítés művelete szintén két relációból állít elő egy eredmény relációt. Akkor használjuk, ha egynél több táblázatból kell összeszedni az adatokat, vagyis összerakjuk azt, amit normalizálással szétszedtünk. Az eredmény egy olyan reláció

lesz, amelyben az egyik reláció soraihoz hozzáírjuk a másik reláció minden olyan sorát, amelyben a megadott közös mezők (join mezők) értéke azonos. Az új táblázat oszlopainak száma a két kiinduló táblázat oszlopainak összege mínusz a közös oszlopok száma. A közös oszlop csak egyszer szerepel A művelet: relációnév1 JOIN relációnév2(join mező) Példa: Az autók és tulajdonosaik adatait két táblában tároljuk. Létrehozunk egy olyan táblát, ami a tulajdonos adatai mellett az autójának adatait is tartalmazza: Tulajdonos = Autó JOIN Ember(rendszám) adatbázisok.doc - 66 - 2003.0909 Autó rendszám ATC-812 RSA-101 LAK-941 Ember név Kovács Nagy Kiss típus Opel Opel Suzuki Tulajdonos típus Opel Opel Suzuki rendszám ATC-812 RSA-101 LAK-941 rendszám RSA-101 LAK-941 ATC-812 név Kiss Kovács Nagy 4-7. ábra Relációs algebra – összekapcsolás Az összekapcsolás összetett művelet. Végrehajthattuk volna három másik

művelet felhasználásával is: Először képezzük a két reláció keresztszorzatát: keresztszorzat = Autó TIMES Ember Kiválogatjuk azokat a sorokat, amelyekben a közös mezők azonosak: válogat = RESTRICT keresztszorzat WHERE (Autó.rendszám=Emberrendszám) Végül elhagyjuk a feleslegesen kétszer szereplő kapcsolómezők közül az egyiket, azaz vetületet képezünk: tulajdonos = válogat PROJECT (típus, autó.rendszám, név) 4.9 Osztás Az osztás a gyakorlatban igen ritkán használt és kevés adatbázis-kezelő rendszerben megvalósított kétoperandusú művelet, mivel végrehajtása igen időigényes, s gyakorlati haszna sem jelentős. Egy R1 és R2 reláció hányadosa egy olyan reláció, melyben R1 mindazon rekordjainak projekciói tartoznak, melyek szorzata az R2-vel, legnagyobb részhalmazát alkotják az R1-nek. Példa: Az Autó táblából kiválogatjuk a Rendszám táblában lévő rendszámokhoz tartozó autók típusait: adatbázisok.doc - 67 -

2003.0909 Autó rendszám ATC-812 RSA-101 LAK-941 ROC-512 ALU-019 SPA-310 Rendszám rendszám ATC-812 LAK-941 ALU-019 típus Opel Opel Suzuki Lada Trabant Skoda Típus típus Opel Suzuki Trabant 4-8. ábra Relációs algebra – osztás Hasonlóan az összekapcsoláshoz, ez is egy összetett művelet, amit a következőképpen írhatunk le: Szelektáljuk az Autó táblát a Rendszám táblában megadott értékek szerint és végezzünk projekciót a Rendszámban nem szereplő mezőkre. A szelekciót a Rendszám tábla minden rekordjára el kell végezni, így annyi eredménytáblát kapunk, ahány sorból áll az osztó táblázat. Ezután venni kell az eredménytáblák metszetét, ami egyben az osztás eredményét tartalmazó tábla lesz. 4.10 Kiterjesztés A művelet létrehozásának indíttatása az volt, hogy egyes lekérdezéseknél nem mindig csak a mezőértékekre, hanem az azokból képzett valamilyen kifejezések értékeire is kíváncsiak vagyunk. Példa: A

táblázatban tárolt adatok mellett szükségünk van a nettó árra is: Autó rendszám ATC-812 RSA-101 LAK-941 ROC-512 ALU-019 SPA-310 típus Opel Opel Suzuki Lada Trabant Skoda szín fehér kék fehér piros zöld fehér ár 3 000 000 2 800 000 1 900 000 500 000 30 000 1 500 000 ár*0,8 2 400 000 2 240 000 1 520 000 400 000 24 000 1 200 000 4-9. ábra Relációs algebra – kiterjesztés 4.11 Csoportosítás Bizonyos esetekben nem magára a konkrét rekord-előfordulásokra vagyunk kívánadatbázisok.doc - 68 - 2003.0909 csiak, hanem a rekord-előfordulások valamilyen összesítő adataira. A statisztikai adatok sokszor elegendő információt nyújtanak és jobban is kezelhetők, mint a részletes adatlisták. Gyakran alkalmazott összesítések: - count – az előfordulások darabszáma, - sum – előfordulások valamely mezőjének összege, - max – előfordulások valamely mezőjének maximuma, - min – előfordulások valamely mezőjének minimuma, -

avg – előfordulások valamely mezőjének átlaga. Példa: Az alábbi táblából összeszámoljuk, hogy hány darab autónk van, és mennyi az autók átlagára: Autó rendszám ATC-812 RSA-101 LAK-941 ROC-512 ALU-019 SPA-310 típus Opel Opel Suzuki Lada Trabant Skoda szín fehér kék fehér piros zöld fehér ár 3 000 000 2 800 000 1 900 000 500 000 30 000 1 500 000 COUNT(tipus) 6 AVG(ár) 1 621 667 4-10. ábra Relációs algebra – csoportosítás adatbázisok.doc - 69 - 2003.0909 5. Az adatbázis-tervezés lépései Az adatbázisrendszerek tervezésékor abból a tényből kell kiindulni, hogy az adatbázisrendszer is egy számítógépen futó program, egy szoftvertermék, ezért az általános szoftverfejlesztési irányelvek itt is érvényesek. A szoftverfejlesztés általános metodikája mellett természetesen az adatbázisrendszerek sajátosságait is figyelembe kell venni. Egy adatbázis létrehozását mindig az adatbázis tervezés előzi meg. Gondosan

fel kell mérni az igényeket és meg kell fogalmazni a problémákat. Egy adatbázist manapság néhány hónap alatt fejlesztenek ki Ennek körülbelül 70-75%-a a tervezésre, 10-15%-a a programozásra, a maradék pedig a tesztelésre fordított idő. Alapos tervezés nélkül a rendszer átláthatatlan lesz és utólagos módosítás már nagyon körülményes Nézzük tehát a tervezés lépéseit: 1. fázis Az igények összegyűjtése, elemzése 2. fázis Koncepcionális terv elkészítése 3. fázis Adatbázis-kezelő rendszer kiválasztása 4. fázis Adatbázis-kezelő rendszertől függő leképezés 5. fázis Fizikai tervezés 6. fázis Megvalósítás 5.1 1 fázis Az igények összegyűjtése, elemzése, a feladat specifikációja A folyamat során nagyon gondosan, átgondoltan fel kell deríteni a fő alkalmazási területeket, tanulmányozni kell az adott területtel rokon, már meglévő alkalmazásokat és azok dokumentációit. Meg kell vizsgálni a jelenlegi

megvalósításokat (még a nem számítógépes megoldásokat is), valamint a körülményeket. A felhasználói igények, elvárások összegyűjtése érdekében célszerű a későbbi felhasználókkal is elbeszélgetni. Az adatok, információk összegyűjtése után olyan specifikációt kell készíteni, mely tartalmazza a felhasználói igényeket kielégítő tárolandó adatokat, valamint a feldolgozási műveleteket, tranzakciókat, lekérdezéseket. adatbázisok.doc - 70 - 2003.0909 Példa: Egy kiskereskedelmi üzlet tulajdonosában megfogalmazódik az az ötlet, hogy vezethetne szállítóiról, azok legfontosabb adatairól valamiféle nyilvántartást. Megkeres egy hozzáértő szakembert, aki rábeszéli egy adatbázis-kezelő rendszer megvásárlására és vállalja a program kifejlesztését A szakember kérdéseket tesz fel a kiskereskedő igényeivel kapcsolatban: pontosan milyen adatokat szeretne nyilvántartani, milyen információt szeretne leszűrni a

tárolt adatokból, hogyan szeretné az információt megjeleníteni. A többszöri beszélgetés ereménye lehet: kellene tárolni a szállító nevét, címét, adószámát, a szállított áru megnevezését, árát, mennyiségét, minőségét, a nyújtott fizetési feltételeket, szállítási határidőket stb; a rendszer képes legyen olyan kérdésekre választ adni, mint például kik azok a szállítók, akik a legolcsóbban, legjobb fizetési feltételekkel, leggyorsabban szállítanak bizonyos árukat. Ezek után a szakember utánanéz, hogy milyen, már létező szoftvertermékek kaphatók a piacon, ezek esetleg mennyiben felelnek meg a kiskereskedő elvárásainak. Mi olcsóbb: egy meglévő rendszert megvásárolni, ami esetleg nem teljesen fedi a felhasználó igényeit, vagy egy új rendszert fejleszteni. Amennyiben megéri új programot írni, a szükséges adatokat csoportosítani kell öszszetartozásuk alapján, meg kell határozni a kulcsokat és a kapcsolatokat.

Csak néhány egyedtípus ehhez a példához: ÁRU(cikkszám,megnevezés,mennyiségi egység) SZÁLLÍTÓ(adószám,megnevezés,cím), SZÁLLÍT(kód,adószám,cikkszám,dátum,minőség,mennyiség,ár,fiz.határidő) 5.2 2. fázis A koncepcionális terv elkészítése A terv készítésének folyamán kell a magas szintű modellt kialakítani. A modell segítségével meg kell fogalmazni az előre tervezhető lekérdezéseket és tranzakciókat A terv előnyei: - közérthető formában mutatja az adatbázis szerkezetét, az adatcsoportokat és azok kapcsolatait, valamint a korátozásokat, - olyan terv, leírás, amit az adatbázis-kezelő rendszer kiválasztásával, vagy a belső séma módosítása esetén nem kell megváltoztatni, - nélkülözhetetlen abból a szempontból is, hogy mind a felhasználóknak, mind pedig a programozóknak újabb ötleteket ad, adatbázisok.doc - 71 - 2003.0909 - mivel könnyen megérthető, segíti a felhasználó és a programozó

közötti párbeszédet. A koncepcionális terv elkészítéséhez leggyakrabban az egyed-kapcsolat modellt használják, mivel kifejezők (az adattípusok mellett a kapcsolatok típusait is ábrázolják), egyszerűek (laikusok is viszonylag könnyen megérthetik), kevés fogalmat használnak (így rövid idő alatt megtanulható), szemléletes ábrákat használnak és egyértelműek, szinte nem lehet félreérteni azokat. Amennyiben hasonló igények fogalmazódnak meg adatra vagy tranzakcióra vonatkozóan, az igényeket össze kell fésülni. E feladat során a legnehezebb feladat az eltérések és egyezőségek megtalálása. (Például a Dolgozó és Alkalmazott egyed jelentheti ugyanazt, de Dolgozó és Vezető már nem.) Példa: A kiskereskedelmi üzlet példájánál maradva, megrajzoljuk az egyed-kapcsolat modellt. Ha nem csak egy felhasználónk lesz, többféle igény is felmerülhet, ezért több nézetet hozunk létre, majd ezeket módosítjuk, megszüntetjük az

esetleges ellentmondásokat, végül integráljuk. A nézetek integrálása eredményezi a teljes koncepcionális modellt mennyegys megnevezés cikkszám áru mennyiség kód minőség adószám szállít dátum cikkszám ár határidő szállító település adószám megnevezés utca 5-1. ábra Adatbázis-tervezés – koncepcionális modell kialakítása adatbázisok.doc - 72 - 2003.0909 5.3 3. fázis Az adatbázis-kezelő rendszer kiválasztása Az adatbázis-kezelő rendszer kiválasztásában igen sok tényező játszhat szerepet, mint például: - a feladat természete (hierarchikus 1:N kapcsolat esetén választhatunk hierarchikus modellen alapuló rendszert, egyéb esetben hálós, vagy relációs modellen alapuló rendszert célszerű választani), - gazdaságossági megfontolások (a hardver és szoftver költségei, betanítási és karbantartási stb. költségek), - a rendszer szolgáltatásai, felhasználóbarát felület. Egyszerűbb,

pontosan tervezhető feladatok elvégzésére nem kell feltétlenül adatbázis-kezelő rendszert használni. Néha előnyösebb lehet egy házi fejlesztésű program, mint egy bonyolult és költséges rendszer. Akkor érdemes adatbázis-kezelő rendszert használni, ha: - több program is használja ugyanazt az adatbázist, - az adatok gyorsan szaporodnak, módosulnak, - nagy az adatbázis, - a különböző adattípusok között bonyolult kapcsolatrendszer áll fent és - az adatellenőrzésre, az adatbiztonságra nagy az igény. Példa: A kiskereskedő PC-t fog használni, melyhez elsősorban relációs adatbáziskezelő programokat találhatunk a piacon. Ha a gépen a grafikus felületű Windows operációs rendszer fut, ezzel kompatibilis adatbázis-kezelő rendszert kell választanunk. 5.4 4. fázis Adatbázis-kezelő rendszertől függő leképezés A leképezés lényegében a logikai adatmodelltől függő szabályok alkalmazása (lásd: Egyed-kapcsolat

modellből relációs modell). A folyamat automatizálható az ún. CASE (Computer Aided Software Engineering Tools) programok segítségével. Ezek az eszközök az ER-modellből kiindulva a kiválasztot adatbázis-kezelő rendszer adatleíró nyelvén leírják az adatbázis szerkezetét. Ebben a fázisban történik a lekérdezések megtervezése is, relációs műveletek so- adatbázisok.doc - 73 - 2003.0909 rozatával. A lekérdezések leírásához használhatunk relációs algebrát, vagy használhatunk – későbbi fejezetben áttekintett – ún SQL-szerű utasításokat is Példa: A kiskereskedés ER-modelljéből relációs adatmodellt készítünk. (Az alábbi ábra a modell egy kis részét mutatja.) Néhány lekérdezés a modellből: Kik a szegedi szállítók? Ki szállított tízezer forintnál nagyobb összegű árut? stb. áru cikkszám, megnevezés, mennyegys szállít kód, adószám, cikkszám szállító adószám, megnevezés, település 5-2. ábra

Adatbázis-tervezés – ER-modell leképezése 5.5 5. fázis Fizikai tervezés Itt kell dönteni a tárolási szerkezetről és a hozzáférési módokról, melybe az adatbázis-kezelő rendszeren kívül az operációs rendszer is beleszólhat. Relációs adatmodell használata esetén a fizikai tervesben fontos szerepet játszik az indexelés. Döntő fontosságú lehet a lekérdező és aktualizáló – vagyis a beszúró, törlő és módosító – műveletek gyakorisága és egymáshoz való viszonya. Az indexelésnél azt is figyelembe kell venni, hogy az adatok elérésének gyorsítása mellett ez többlet helyfoglalással jár. Példa: Ha már pontosan tudjuk, hogy melyik adatbázis-kezelő rendszert fogjuk használni (a 3. fázisban már eldöntöttük), akkor foglalkozhatunk a kérdéssel, nevezetesen – amennyiben FoxPro-t vagy Access-t használunk –, hogy hogyan történjen az indexelés? Mit érdemes indexelni? Az elsődleges kulcs indexelésébe nem szólhatunk

bele, de megvizsgálhatjuk, hogy lesznek-e olyan lekérdezéseink, amikor nem az elsődleges kulcs szerint kell rendezni. Lesz, ha például az árukat megnevezés szerinti sorrendben szeretnénk megjeleníteni, a megnevezés pedig nem elsődleges kulcs. adatbázisok.doc - 74 - 2003.0909 5.6 6. fázis Megvalósítás Az adatleíró nyelven írt sémák alapján létrejön az adatbázis szerkezete (metaadatok) és az üres fájlok. Az így kapott adatbázist feltölthetjük adatokkal A programozók megírják a tranzakciók kódjait, vagy a felhasználói programokat, melyek használhatják az adatbázis-kezelő nyelv parancsait (ez általában az SQL). Korszerű rendszerek felhasználóbarát grafikus felülete lehetővé teszi, hogy komolyabb programozási ismeretek nélkül hozzunk létre kódokat. Néhány szolgáltatás, amit a mai rendszerek biztosítanak: - összetartozó adatcsoportok adatainak bevitelére alkalmas űrlapok létrehozása, - 1:N és N:M kapcsolatok

adatainak megjelenítésére alkalmas lekérdezések létrehozása, - menük, gombok és egyéb objektumok létrehozása kódok bevitelére, rekordokkal kapcsolatos műveletek végzésére, - adatbevitel ellenőrzése, - jelentések sémáinak elkészítése. Valódi adatok felvitele előtt célszerű a rendszert mintaadatokkal kipróbálni, hogy ne túl későn derüljenek ki az esetleges hibák. Ezt már csak azért is célszerű megtenni, mert még ekkor is előfordulhat, hogy mind a felhasználó, mind a programozó olyan újabb lehetőségeket fedez fel, amire eddig nem is gondolt. A rendszer megvalósítása után használat közben felmerülhetnek problémák, amiket orvosolni kell. Egyéb módosítási igények is jelentkezhetnek – részben új felhasználói kívánságok, részben a változó külső körülmények következtében –, amelyeket utólag szintén be kell építeni. Példa: A szállítói nyilvántartás adatbázisát a programozó elkészíti.

Létrehozza a táblákat, eldönti, hogy a tábla egyes oszlopai milyen típusúak legyenek (szöveg, szám, dátum stb.), létrehozza a táblák közötti kapcsolatokat Elkészíti a leggyakoribb lekérdezések és űrlapok sémáját és készít egy menüt, amivel ezeket elő lehet hívni A felhasználó ezek után töltheti fel adataival az adatbázist. adatbázisok.doc - 75 - 2003.0909 5-3. ábra Adatbázis-tervezés – megvalósítás relációs adatbázis-kezelőben, tábla létrehozása 5-4. ábra Adatbázis-tervezés – megvalósítás relációs adatbázis-kezelőben, lekérdezés létrehozása. adatbázisok.doc - 76 - 2003.0909 6. A dBase-típusú adatbázis-kezelők Személyi számítógépeken először a dBase, FoxBase, FoxPro és a Clipper relációs adatbázis-kezelők terjedtek el. Bár a programokat különböző szoftverfejlesztő cégek készítették, mégis egy közös alapnyelvre épülnek, és éppen ezért szokás ezeket a fejlesztő

eszközöket dBase-típusú adatbázis-kezelőknek nevezni. Ebben a fejezetben a dBase programozási nyelv alapjaival ismerkedünk meg, amihez a Visual FoxPro-t fogjuk felhasználni. Mielőtt nekiesnénk a FoxPro-nak, néhány dologgal nem árt tisztában lennünk: - A leggyakoribb feladatok menüből elérhetők, így még azok is tudnak adatbázisokat létrehozni, módosítani, akik nem rendelkeznek programozási gyakorlattal. A menü változik attól függően, hogy éppen milyen állományokkal dolgozunk. Táblázat módosítása esetén például a menü kiegészül adatkezelő funkciókkal. - Az utasításokat a Command (parancs) nevű ablakba kell beírni. Az ENTER leütése után a begépelt utasítás azonnal végrehajtódik. A végrehajtás eredményét, vagy az esetleges hibaüzenet a háttérben, a képernyőn láthatjuk Az utasítások egy része az első négy karakterrel rövidíthető (például MODIFY STRUCUTE helyett elegendő a MODI STRU). A kis- és nagybetűk

között nem tesz különbséget a rendszer. - Az adatmanipuláló utasítások egy részének hatóköre kiterjed az adattábla összes rekordjára, míg másik részük csak arra a rekordra vonatkozik, amelyiken a rekordmutató áll. Az utasítások hatókörét módosíthatjuk: FOR feltétel – utasítás végrehajtása azokon a rekordokon, amelyekre a feltétel teljesül, összetett feltételt is megadhatunk az .AND, OR, NOT logikai kifejezésekkel WHILE feltétel – az utasítás végrehajtása a rekordokon, amíg a feltétel teljesül, összetett feltételt is megadhatunk. NEXT n – utasítás végrehajtása a következő n rekordon, REST – utasítás végrehajtása a rekordmutatótól a fájl végéig. ALL – utasítás végrehajtása az összes rekordon. adatbázisok.doc - 77 - 2003.0909 Az utasítások mellett számos függvény is rendelkezésünkre áll. - A forrásprogramokat bármilyen szövegszerkesztővel elkészíthetjük, a lényeg, hogy ne használjunk

formázást; egyszerű szövegként, PRG kiterjesztéssel kell a programokat menteni. - DBase-ben minden táblázatot külön munkaterületen tárolunk. Összesen tíz munkaterület áll rendelkezésünkre, amelyekre számokkal (0-9), vagy betűkkel (A-J) hivatkozhatunk. Régi változatokban egy adatbázisban csak egy táblázat lehet. (A Visual FoxPro-ban ez már nem így van!) - A táblázatokat tartalmazó fájlok kiterjesztése DBF. Az adatok logikai rendezését tartalmazó indexfájlok kiterjesztése lehet IDX, CDX, vagy NDX A fordítás előtti forrásprogramot tartalmazó állomány kiterjesztése PRG Fejlettebb rendszerek esetén ezeken kívül még más típusú állományokkal is találkozhatunk, például: MNX – menü, LBX – címke, FMT – formátum, FRM – jelentés. - A táblázatokban a mezők (oszlopok) elnevezésénél az angol ábécé betűit és számokat használjunk! Az adatok bevitelénél természetesen már használhatunk magyar ékezetes betűket

is. - A mezőknek nevükön kívül van típusa és szélessége: karakteres (character), legfeljebb 254 karakter, szám (numeric, meg kell adni a tizedesvessző – illetve tizedespont – előtti és utáni karakterek számát is), dátum (date, nem lehet a szélességét módosítani, az elválasztójelekkel együtt 8 karakter) – nem minden rendszert készítettek fel az évezredváltás kezelésére, logikai (logical, igaz/hamis, true/false, 0/1, a szélességét nem lehet módosítani), memó (memo, szélességén nem lehet változtatni; ebben a mezőben csak hivatkozunk egy különálló fájlra, amiben a mező tartalmát tároljuk). A felsoroltakon kívül rendszertől függően más típusokkal is találkozhatunk. - A sorokat rekordoknak nevezzük. A rekordmutató mindig az aktuális rekordon, vagy a fájl végén áll adatbázisok.doc - 78 - 2003.0909 - A táblákba bevitt adatokat nem kell elmenteni. A mentésről az adatbáziskezelő gondoskodik a háttérben

(Ez csak az adattáblákra igaz, minden más esetben nekünk kell gondoskodnunk a fájlok elmentéséről!) 6.1 Adatbázis-kezelés FoxPro-ban Tábla megnyitása és bezárása: Fájl menü, Open menüpont. A megjelenő ablakban megkeressük azt a DBF kiterjesztésű fájl, amit be kívánunk tölteni Kapcsoljuk be az Exclusive kapcsolót is! Ha tudjuk, hogy hol és milyen néven található az adatbázisunk, a parancsablakban adjuk ki a USE táblanév EXCLUSIVE utasítást. A USE utasítást önmagában is használhatjuk; ezzel bezárhatjuk az éppen aktuális adatbázist. 6-1. ábra FoxPro – tábla megnyitása A FoxPro adatbázis-kezelő rendszer hálózatban is képes működni. Ebből következően alapesetben egyszerre többen is használhatnák ugyanazt az adatbázist Ilyenkor azonban egyes műveletek – például az adatbázis törlése vagy struktúrájának módosítása nem engedélyezett. Ha teljes jogkörrel szeretnénk az adatbázisokat kezelni, akkor kizárólagos

(exkluzív) hozzáféréshez kell biztosítanunk magunknak. adatbázisok.doc - 79 - 2003.0909 Táblák létrehozása és struktúra megadása: Fájl menü, New menüpont, majd a New ablakban a Table opciót kell választani. A New file gombra kattintva meg kell adnunk a létrehozandó tábla nevét. Ezek után jutunk ahhoz az ablakhoz, ahol felépíthetjük az adattáblánk struktúráját. Az OK gombra kattintva létrejön az üres adatbázis. A CREATE fájlnév utasítás kiadásával szintén a struktúra-felépítő ablakba jutunk. 6-2. ábra FoxPro – új tábla létrehozása Táblák feltöltése adatokkal: Az adatainkat beírhatjuk a tábla létrehozásakor. A struktúra megadását követően a FoxPro megkérdezi, hogy fel akarunk-e vinni adatokat (Input data records now?). Ha itt igennel (Yes) válaszolunk, megnyílik a táblát tartalmazó ablak, és itt begépelhetjük az adatokat. adatbázisok.doc - 80 - 2003.0909 6-3. ábra FoxPro – adatbevitel (APPEND)

Az adattábla adatokkal való feltöltésére az APPEND parancsot használjuk. Csak megnyitott táblát tudunk feltölteni. Megjelenítés, módosítás, törlés: Betöltött adattábla megjelenítéséhez, vagy módosításához kiadhatjuk az APPEND parancsot (ebben az esetben új rekordokat is hozzáadhatunk a táblához), illetve a BROWSE parancsot. A módosítani kívánt rekordra rá kell állni, az új értéket be kell gépelni. 6-4. ábra FoxPro – módosítás (BROWSE) Rekordok törléséhez a BROWSE utasítás kiadása után a törölni kívánt sorokat ki kell jelölni. Ehhez a sor bal oldalán található kis téglalapra kell kattintani Ha meggondoljuk magunkat és mégsem akarunk törölni, a törlésre kijelölést ismét a téglalapra kattintva tudjuk megszüntetni A törlésre kijelölt rekordok táblából való végleges eltávolításához a Table menü adatbázisok.doc - 81 - 2003.0909 Remove Deleted Records menüpontjára kell kattintani, vagy a PACK

utasítást kell kiadni. Az adattábla teljes tartalmának törlésére a ZAP parancs használható. 6.2 A FoxPro programozása A FoxPro-ban az utasításokat egyenként is kiadhatjuk a Command ablakban, vagy egy egyszerű szövegfájlba összefogva, programként is lefuttathatjuk azokat. A MODIFY COMMAND fájlnév utasítással nyithatunk olyan ablakot, ahol programot írhatunk. A forrásprogramot a Fájl menü Save menüpontjával menthetjük 6-5. ábra FoxPro – forrásprogram írása ablakban és a Command ablak Kész programokat a Program menü Do menüpontjával vagy a DO programnév utasítás kiadásával tudunk futtatni. 6-6. ábra FoxPro – forrásprogram futtatása adatbázisok.doc - 82 - 2003.0909 A Foxpro programozásának alapjait, az adatbáziskezeléshez nélkülözhetetlen dBase utasításokat feladatokon keresztül mutatjuk be. 1. feladat: adattábla létrehozása Alkalmazott utasítások magyarázata: SET DEFAULT TO mappanév – az alapértelmezés

szerinti mappa megadása; minden, amit létrehozunk, ebbe a mappába kerül; csak létező mappanevet adhatunk meg. CREATE táblanév - tábla létrehozása és struktúrájának kialakítása. Hozzuk létre a C meghajtó egy már létező mappájában az EMBER nevű, valamint egy AUTO nevű adattáblát a következő mezőkkel: AUTO: EMBER: Mezőnév Típus Méret Mezőnév Típus Méret Szemszam Szám 11,0 Rendszam Szöveg 7 Nev Szöveg 30 Tipus Szöveg 10 Cím Szöveg 30 Szin Szöveg 10 Fizetes Szám 6,0 Ar Szám 10 Szuldat Dátum Kor Szám 3 Dolgozik Logikai A megoldás: SET DEFAULT TO c:foxgyak (vagy bármilyen más, létező! könyvtár) CREATE ember Stuktúra elkészítése. CREATE auto Stuktúra elkészítése. 2. feladat: adattábla megnyitása, bezárása Alkalmazott utasítások magyarázata: SELECT munkaterület – a megadott munkaterület aktiválása; alapértelmezés szerint az első munkaterületen dolgozunk. USE táblanév IN

munkaterület ALIAS alisnév INDEX indexfájl EXCLUSIVE – adatbázisok.doc - 83 - 2003.0909 megnyit egy táblát a megadott munkaterületen. A munkaterületnek becenevet (aliasnév) is adhatunk. Ha logikai rendezést is hajtottunk végre a táblában, az így keletkezett indexfájlt is megnyithatjuk. Ha a USE utasítást önmagában, paraméterek nélkül használjuk, azzal bezárjuk az aktuális munkaterületen lévő adattáblát. CLOSE ALL vagy CLOSE DATABASES – bezárja az összes adatbázist, illetve egyes adatbázishoz tartozó fájlokat is. Az első munkaterület lesz aktív Nyissuk meg az előbb létrehozott EMBER nevű táblát az első munkaterületen! Megoldás: USE ember IN 1 ALIAS ember EXCLUSIVE vagy SELECT 1 USE ember ALIAS ember EXCLUSIVE Zárjuk be az első „ember” munkaterületen lévő adattáblánkat! Megoldás: SELECT ember USE vagy SELECT ember CLOSE ALL/DATABASES 3. feladat: adattábla feltöltése, módosítása Alkalmazott utasítások

magyarázata: APPEND – új rekordok hozzáadása a táblához. BROWSE [FIELDS mezőlista] – a tábla mezőinek megjelenítése és módosítása táblázatos formában. Megadhatjuk a megjelenítendő mezők listáját is Ha nem adunk meg semmit, a tábla összes mezőjét láthatjuk. SET DATE formátum – a dátumformátum módosítása; ha nem kívánunk kísérletezni azzal, hogy most éppen hogy van beállítva, célszerű a magyar dátumformának megfelelő ANSI beállítást használni. Nyissuk meg az EMBER táblát az első, az AUTO táblát pedig a második munkaterületen és töltsük fel a következő adatokkal: (Az EMBER táblában a adatbázisok.doc - 84 - 2003.0909 helyesírási hiba szándékos!) Szem.szám EMBER: Név Cím Fizetés Születés Dolgozik 17912154115 Kovács szeged 55 000 1979.1215 Igen 28112011212 Nagy Budapest 75 000 1981.1201 Nem 17501123124 Tóth Szeged 105 000 1975.0112 Nem 17704273412 Szabó Győr 155 000 1977.0427

Igen 27603304871 Kovács Debrecen 55 000 1976.0330 Igen Ár Kor AUTO: Rendszám Típus Szín DPA-812 Lada Piros AFA-314 Skoda UIA-912 500 000 17 Fehér 1 500 000 3 Opel Kék 2 100 000 2 CGA-719 Trabant Zöld 50 000 30 DOZ-219 Mercedes Fekete 4 500 000 2 50 000 30 1 800 000 1 BAX-111 BIE-512 Zöld Suzuki Fehér Megoldás: SET DATE ANSI USE ember IN 1 ALIAS ember EXCLUSIVE USE auto IN 2 ALIAS auto EXCLUSIVE SELECT ember APPEND Beírjuk az emberek adatait. SELECT auto APPEND Beírjuk az autók adatait. Kovács címét elrontottuk, javítsuk ki! (szeged -> Szeged) Megoldás: BROWSE Megkeressük a módosítandó adatot és kijavítuk. adatbázisok.doc - 85 - 2003.0909 4. feladat: adattábla szerkezetének, tartalmának másolása, módosítása Alkalmazott utasítások magyarázata: COPY STRUCTURE TO táblanév – új, üres adattábla létrehozása az aktuális adattábla szerkezetével (kapunk egy üres dbf kiterjesztésű fájlt). COPY

TO táblanév [FIELDS mezőlista hatókör] – adattábla tartalmának átmásolása új adatbázisba. MODIFY STRUCTURE – az aktuális tábla szerkezetének megváltoztatása. Vigyázzunk arra, hogy adatot tartalmazó mező módosítása adatvesztéssel járhat. Készítsünk biztonsági másolatot az elkészített és megnyitott adattáblák struktúrájáról EMBIZT és AUBIZT néven! Megoldás: USE ember IN 1 ALIAS ember EXCLUSIVE SELECT ember COPY STRUCTURE TO embizt USE auto IN 2 ALIAS auto EXCLUSIVE SELECT auto COPY STRUCTURE TO aubizt Egészítsük ki az emberek adatait a tulajdonukban lévő autók rendszámával! Szem.szám Név Cím Fizetés Születés Dolgozik Rendszám 17912154115 Kovács szeged 55 000 1979.1215 Igen DOZ-219 28112011212 Nagy Budapest 75 000 1981.1201 Nem UIA-912 17501123124 Tóth Szeged 105 000 1975.0112 Nem DPA-812 17704273412 Szabó Győr 155 000 1977.0427 Igen BIE-512 55 000 1976.0330 Igen AFA-314 27603304871 Kovács Debrecen A

megoldás: USE ember IN 1 ALIAS ember EXCLUSIVE SELECT ember MODIFY STRUCTURE Az EMBER táblában az új mező neve Rendszam, típusa Szöveg, mérete 7. BROWSE adatbázisok.doc - 86 - 2003.0909 A Rendszám mezőbe beírjuk az adatokat. Helyezzük el az EMBIZT2 táblába azoknak az adatait, akiknek a fizetése meghaladja a százezer forintot! Megoldás: USE ember IN 1 ALIAS ember EXCLUSIVE SELECT ember COPY TO embizt2 FOR fizetes>100000 5. feladat: adatok fizikai és logikai rendezése Alkalmazott utasítások magyarázata: SORT TO táblanév ON mezőnév [ASCENDING/DESCENDING] – a mezőnév alapján fizikailag rendezett tábla létrehozása növekvő (ascending), vagy csökkenő (descending) sorrendben. Ha egy adatbázisra nagyon sokszor van szükségünk egy adott szempont szerint rendezve, akkor célszerű e szempont szerint fizikai rendezést végezni. Ha nagyméretű a táblánk, sokáig tarthat a rendezés, ráadásul a tábla minden módosítása után el kellene

végezni, éppen ezért nem gyakori művelet. INDEX ON mezőnév TO fájlnév [ASCENDING/DESCENDING] – a tábla mezőnév vagy mezőnevek szerinti logikai rendezése. Egyes programváltozatokban a rendezés csak növekvő sorrendben lehetséges. Az eredeti tábla változatlan marad, de mellette létrejön a logikai rendezést tartalmazó fájl. SET ORDER TO indexsorszám – több megnyitott indexfájl közül kijelöli a vezérfájlt. Az adattábla e szerint lesz logikailag rendezve. REINDEX – az aktív indexfájlok újraszervezése. A műveletet akkor kell végrehajtani, ha egy adattáblát az idexfájlok nélkül nyitunk meg és így módosítjuk. Az indexállományt legközelebbi betöltésekor frissíteni kell, különben a logikai rendezés eredménye hibás lehet. Az áttekinthetőség kedvéért rendezzük az adatokat az EMBERNEV táblába név szerint! Nyissuk meg ezt az új táblát a harmadik munkaterületen és nézzük meg! Ha mindent rendben találunk, zárjuk be!

adatbázisok.doc - 87 - 2003.0909 Megoldás: USE ember in 1 ALIAS ember EXCLUSIVE SELECT ember SORT TO embernev ON nev USE embernev IN 3 EXCLUSIVE SELECT 3 BROWSE USE Térjünk vissza az első munkaterületre! Végezzünk logikai rendezést személyi szám, fizetés és születési dátum szerint is! Az AUTO táblát indexeljük rendszám szerint! Zárjunk be minden adattáblát! Megoldás: USE ember in 1 ALIAS ember EXCLUSIVE SELECT ember INDEX ON szemszam TO emszam INDEX ON fizetes TO emfiz INDEX ON szuldat TO emszul SELECT auto INDEX ON rendszam TO aurend CLOSE ALL Nyissuk meg az EMBER adattáblát az első munkaterületen és töltsük be a táblához az összes indexállományt! A személyi szám szerinti rendezés legyen elsődleges! Nyissuk meg a második munkaterületen az AUTO táblát az idexfájllal együtt! Frissítsük az összes indexállományt! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam, emfiz, emszul EXCLUSIVE SET ORDER TO 1 USE auto IN 2 ALIAS auto INDEX

aurend EXCLUSIVE REINDEX adatbázisok.doc - 88 - 2003.0909 6. feladat: Mozgás a táblában, listázás Alkalmazott utasítások magyarázata: ? kifejezés – kifejezés megjelenítése a képernyőn STORE kifejezés TO változó – értékadás változónak változó = kifejezés – értékadás változónak LIST mezőnév hatókörmódosító [TO PRINTER/FILE fájlnév] – adattábla kilistázása, hatóköre alapértelmezés szerint az összes rekordra kiterjed. Ha nem adunk meg mezőneveket, valamennyi mezőt kilistázza. A rekordmutató a fájl végére (EOF()) áll. DISPLAY mezőnév hatókörmódosító [TO PRINTER/FILE fájlnév] – aktuális rekord kilistázása, hatóköre alapértelmezés szerint arra a rekordra terjed ki, amelyiken a rekordmutató áll. Ha nem adunk meg mezőneveket, valamennyi mezőt kilistázza. A rekordmutató a következő rekordra áll RECNO() – az aktuális rekord fizikai sorszáma, ahol a rekordmutató áll. GO TOP, GO BOTTOM – a

rekordmutató áthelyezése a tábla elejére, végére. SKIP n – rekordmutató mozgatása a következő (n pozitív), vagy előző (n negatív) rekordra. Ha az adattáblához indexfájlt is használunk, a rekordmutató a logikai rendezést követi. Tároljunk két számot A és B változóban és végezzünk velük matematikai műveleteket! Adjuk össze:F+I+A+I+É+I. Megoldás: STORE 8 TO A B=5 ? ”A+b=”,a+b,”A-B=”,a-b,”A*B=”,ab,”A/B=”,a/b ? ”F”+ ”I”+ ”A”+ ”I”+ ”É”+ ”I” Listázzuk ki az emberek adatait először személyi szám, majd fizetés és végül születési idő szerint rendezett sorrendben is! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam, emfiz, emszul EXCLUSIVE SELECT ember adatbázisok.doc - 89 - 2003.0909 SET ORDER TO 1 LIST vagy DISPLAY ALL SET ORDER TO 2 LIST vagy DISPLAY ALL SET ORDER TO 3 LIST vagy DISPLAY ALL Listázzuk ki a fizetés szerint rendezett tábla harmadik elemének összes mezőjét, valamint az első

három személy nevét és lakhelyét! Megoldás: USE ember IN 1 ALIAS ember INDEX emfiz EXCLUSIVE SELECT ember GO TOP SKIP 2 DISPLAY GO TOP DISPLAY nev,cim NEXT 3 Nézzük meg, hogy a személyi szám szerint rendezett EMBER táblában az első rekord fizikailag hanyadik! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam EXCLUSIVE SELECT ember GO TOP ? RECNO() 7. feladat: szűrők Alkalmazott utasítások magyarázata: SET FILTER TO [feltétel] – szűrő beállítása. Az utasítások csak a szűrőfeltételnek megfelelő rekordon fognak végrehajtódni. Ha nem adunk meg feltételt, azzal kikapcsoljuk a szűrőt. Logikai kifejezések: .AND és, OR vagy, NOT tagadás, T igaz, F hamis adatbázisok.doc - 90 - 2003.0909 Listázzuk ki (a) azoknak a személyeknek a nevét, akik Budapesten laknak, (b) szegedi és budapesti lakosok nevét és fizetését, (c) a szegedi Tóth összes adatát! Megoldás: (a) USE ember EXCLUSIVE SET FILTER TO cim=”Budapest” LIST nev SET FILTER TO

vagy: (a) USE ember EXCLUSIVE DISPLAY nev FOR cim=”Budapest” (b) USE ember EXCLUSIVE LIST nev, fizetes FOR cim=”Szeged” .OR cim=”Budapest” (c) USE ember EXCLUSIVE LIST FOR nev=”Tóth ” .AND cim=”Szeged” 8. feladat: adatok törlése Alkalmazott utasítások magyarázata: EMPTY(kifejezés) – függvény, azt vizsgálja, hogy egy kifejezés üres-e. Eredménye igaz (.T), vagy hamis (F) DELETE hatókör – rekord kijelölése törlésre. Ha nem adunk meg hatókört, az aktuális rekordot törli. Visszavonása a RECALL hatókör paranccsal történhet PACK – a törlésre kijelölt rekordok törlése. A törölt rekordok nem állíthatók helyre ZAP – az adattábla valamennyi adatának törlése. Az így törölt adatok nem állíthatók helyre. Töröljük az összes Trabantot az AUTÓ táblából! Van egy hibás sorunk, ahol nem adtunk meg típust (üres a típus mező). Ezt is töröljük! Megoldás: USE auto EXCLUSIVE DELETE FOR tipus=”Trabant” DELETE

FOR EMPTY(tipus)=.T PACK adatbázisok.doc - 91 - 2003.0909 Nyissuk meg a 4. feladatban létrehozott embizt2 táblát és töröljük teljes tartalmát! Zárjuk be a fájlt! Megoldás: USE embizt2 EXCLUSIVE ZAP USE 9. feladat: táblák összekapcsolása Alkalmazott utasítások magyarázata: SET RELATION TO kulcskifejezés INTO táblanév – két adattáblát kapcsol össze a kulcskifejezés alapján. A kapcsolt fájlnak indexelve kell lennie A SET RELATION TO utasíttás törli a kapcsolatot. Kapcsoljuk össze az EMBER és az AUTO táblát a rendszám alapján! Az EMBER az első, az AUTO a második munkaterületen lesz, mindkettőhöz töltsük be a rendszám szerinti rendezést! Listázzuk ki (a) képernyőre, (b) fájlba az emberek nevét és a tulajdonukban lévő autók rendszámát és típusát! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam EXCLUSIVE USE auto IN 2 ALIAS auto INDEX aurend EXCLUSIVE SELECT ember SET RELATION TO rendszam INTO auto (a) LIST nev,

rendszam, auto->tipus (b) LIST nev, rendszam, auto->tipus TO FILE tulaj.txt Listázzuk ki (a) a budapestiek autóját, (b) azokat a szegedieket, akiknek fekete autójuk van! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam EXCLUSIVE USE auto IN 2 ALIAS auto INDEX aurend EXCLUSIVE SELECT ember SET RELATION TO rendszam INTO auto adatbázisok.doc - 92 - 2003.0909 (a) LIST auto->tipus FOR cim=”Budapest” (b) LIST nev FOR cim=”Szeged” .AND auto->szin=”Fekete” Számoljuk ki a debreceni és győri autók nettó árát! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam EXCLUSIVE USE auto IN 2 ALIAS auto INDEX aurend EXCLUSIVE SELECT ember SET RELATION TO rendszam INTO auto LIST auto->ar*0.8 FOR cim=”Debrecen” OR cím=”Győr” 10. feladat: összesítés Alkalmazott utasítások magyarázata: CALCULATE kifejezés hatókör – összegzés eredményének megjelenítése. A következő kifejezéseket használhatjuk: AVG (átlag), SUM (összeg), CNT

(darab), MAX, MIN, NPV (jelenérték), STD (szórás), VAR (variancia). Az utasítást nem minden dBase rendszer támogatja. Számoljuk össze, hogy hány „Kovács” van az adatbázisban, összesen és átlagosan mennyit ér az autójuk! Megoldás: USE ember IN 1 ALIAS ember INDEX emszam EXCLUSIVE USE auto IN 2 ALIAS auto INDEX aurend EXCLUSIVE SELECT ember SET RELATION TO rendszam INTO auto CALCULATE CNT() FOR nev=”Kovács” CALCULATE SUM(auto->ar) FOR nev=”Kovács” CALCULATE AVG(auto->ar) FOR nev=”Kovács” adatbázisok.doc - 93 - 2003.0909 7. Az SQL lekérdező nyelv Az SQL (Structured Query Language) egy strukturált lekérdező nyelv, melyet az IBM dolgozott ki DB2 relációs adatbázis-kezelőjéhez. Az SQL ma már a relációs adatbázis-kezelők szabványosított nyelve. A nyelvnek több dialektusa, bővítése is kialakult. Az SQL nem tartalmaz algoritmus szerkezeteket (elágazást, ciklust stb.), tehát nem algoritmikus nyelv. Az SQL halmaz

orientált nyelv, mely a relációkon dolgozik A halmaz orientáltság azt jelenti, hogy nem kell definiálni a művelet végrehajtásának lépéseit, hanem a feladat nem eljárásszerű megfogalmazását kell megadni, melyek a reláció, vagy relációk kiválasztott sorain hajtódnak végre. A művelet végrehajtásához szükséges optimális megoldás megtalálása a nyelvi processzor feladata, nem a programozóé; például annak az eldöntése, hogy egy adott lekérdezésben alkalmazhatók-e indexek, vagy építsen-e fel új indexet, a nyelvi processzor feladata. Az SQL nem rekurzív nyelv. Az SQL nyelvnek két felhasználási lehetősége létezik: - Önálló SQL. Az SQL nyelv önálló felhasználása esetén csak a nyelv utasításai állnak rendelkezésünkre Ennek alkalmazására főként akkor kerülhet sor, ha nincs megfelelő alkalmazás az adott feladat elvégzésére. - Beágyazott SQL. A beágyazott SQL esetén egy harmadik generációs algoritmikus nyelvbe (C,

PL/SQL, Pascal FORTRAN stb) ágyazva alkalmazzuk az SQL nyelv elemeit. Ebben az esetben az algoritmikus feladatokat a harmadik generációs nyelvre, az adatbázissal kapcsolatos műveleteket pedig az SQL-re bízhatjuk. Az SQL nyelvek legfontosabb jellemzői: - Adatbázis-elemek. Az SQL az következő adatbázis-elemeket kezeli: Táblázat. Koncepcionális és fizikai szinten definiált, a háttértárolón tárolt, adatokat tartalmazó táblázat Nézet. Fizikai szinten nem létező virtuális táblázat, melynek adatai az alaptáblában tárolt adatok A nézet adatainak lekérdezésekor az adatbázis-kezelő rendszer a táblázatokból állítja elő a nézet adatait tartalmazó eredménytáblá- adatbázisok.doc - 94 - 2003.0909 zatot. Ha az alaptáblázat adatai megváltoznak, a változás a nézetben is megjelenik A nézetben végezhetünk az alaptábla adatait megváltoztató műveleteket is Szinonima. A táblázathoz és a nézetekhez másodlagos nevet (aliasnév,

becenév) is rendelhetünk Az utasításokban az eredeti nevek helyett ezeket a szinonimákat is használhatjuk. Ha rövid szinonimákat használunk, azzal kényelmesebbé válik a munkánk Index. Logikai rendezéshez használható, bár az SQL az adatok valamilyen szempontú rendezéséhez nem igényli az indexelést. Indexet csak táblázathoz lehet létrehozni, nézethez nem. Katalógus. Az adatszótár szerepét betöltő táblázatok, melyeket az adatbáziskezelő rendszer hoz létre és kezel A felhasználók ezt a táblázatot ugyan az SQL nyelv segítségével lekérdezhetik, de módosítása többnyire nem lehetséges. - Jelkészlet. Általában igaz, hogy mindig a befogadó operációs rendszerre jellemző karakterkészletet alkalmazzák az SQL-változatok Jelkészletét a kis- és nagybetűk, számok, műveleti jelek, írásjelek, elválasztó jelek, egyes különleges jelek (például $ % & # ^ @) alkotják. - Szintaktikai elemek. Az SQL a többi programozási

nyelvhez hasonlóan alapegységekből épül fel, melyeket elválasztó jelek határolnak Az alapegységek fajtái: kulcsszavak, azonosítók, műveleti jelek, literálok (számszerű, dátumjellegű, szöveges konstansok). A kulcsszavakban az SQL nem tesz különbséget a kis-, és nagybetűk között. - Utasítások szerkezete. Az utasítások követik a beszélt nyelvek logikáját Ha részeiket összeolvassuk, értelmes felszólító mondatokat kapunk angol nyelven. Az SQL utasítások valamilyen igével kezdődnek, ezzel jelezve a felszólító módot. Az utasítások záradékokra tagolódnak A záradékok az utasítás tárgyát és a végrehajtás feltételeit, körülményeit írják le Minden záradékot jellemző kulcsszó vezet be A záradékokban szerepelhetnek kifejezések, hivatkozások az adatbázis objektumaira, továbbá feltételek - Adattípusok. Az SQL alapvetően ötféle adattípust ismer: a számszerű, szö- adatbázisok.doc - 95 - 2003.0909 veges,

dátumjellegű, bináris vagy logikai, valamint a nyers, szerkezet nélküli típust. - Utasítások fajtái. Az SQL három alapvető utasításfajtát különböztet meg: adatdefiníciós, adatkezelési, valamint adatbiztonsági utasításokat. A különböző megvalósítások kiegészítik ezt a tárolásra, az adatmentésre, visszatöltésre és a működés körülményeire vonatkozó utasításokkal. - Kifejezések és műveletek. A nyelvben találunk numerikus, karakteres, dátum és idő, bináris és logikai műveleteket. Numerikus műveletek: - a négy számtani alapművelet, - számtani relációk, - számtani függvény (kerekítés, átlag, stb.), - halmazfüggvények, oszlopfüggvények amelyek nem egy-egy mezőre, hanem mindig egy adott valódi vagy származtatott oszlop összes mezőjére vonatkoznak egyszerre, - egyéb matematikai függvények (logaritmus, hatványozás, szögfüggvények stb.) Karakteres műveletek: - minta szerinti keresés, -

összefűzés, - csonkítás, - részlet kiemelése, - feltöltés. Műveletek dátumokkal és időpontokkal: - átalakítás dátummegadások és dátumformátumok között, - részletek kiemelése (pl. nap, hónap sorszámát dátumból), - összehasonlítás, - intervallumképzés, - dátumok és intervallumok összeadása, kivonása. Bináris és logikai műveletek: - negáció, komplemens képzése, - logikai ÉS, - logikai VAGY. adatbázisok.doc - 96 - 2003.0909 Adattípustól függetlenül értelmezhetők az összehasonlítás operátorai. Ide tartoznak az =, !=, <>, <, <=, >, >=, !>, !< valamint a LIKE kulcsszó A felsorolt operátorokat kombinálhatjuk a NOT (logikai tagadás) kulcsszóval vagy az egyenértékű ! jellel. Az alábbiakban példák segítségével bemutatjuk néhány SQL utasítás használatát. A konkrét programváltozatokban egyes utasításoknak egyéb záradékai, paraméterei is lehetnek. 1. feladat:

adatdefiníciós utasítások A létrehozó utasítások a CREATE (létrehoz), a módosító utasítások az ALTER (módosít), a törlő utasítások pedig a DROP (elvet) igével kezdődnek. CREATE TABLE táblanév (oszlopnév1 típus, oszlopnévn típus); – új tábla létrehozása, szerkezetének felépítése. CREATE INDEX indexnév ON táblanév (oszlopnév1 ASC/DESC,oszlopnévn ASC/DESC); - adott táblázathoz az index felépítése egy, vagy több oszlop alapján. CREATE SYNONYM szinonimanév FOR táblanév; - a kijelölt táblázathoz állandó jelleggel másodlagos név definiálása. CREATE VIEW nézetnév (oszlopnév1,,oszlopnévn); - nézet definiálása az alaptáblából magadott oszlopokkal. ALTER TABLE táblanév ADD/ALTER (oszlopnév adattípus); – új oszlop hozzáadása/meglévő oszlop típusának módosítása. DROP TABLE / INDEX / SYNONYM / VIEW táblanév / indexnév / szinonimanév / nézetnév; – táblázat adatainak és szerkezetének, az index, a

szinonima, a nézet törlése. (a) Hozzunk létre az alábbi szerkezetű táblázatot: EMBER: Mezőnév Típus Szemszam Szöveg Nev Szöveg (b) Módosítsuk a SZEMSZAM mező típusát szám típusúra! (c) Adjunk új mezőket a táblázatunkhoz: adatbázisok.doc - 97 - 2003.0909 Mezőnév Típus Fizetes Szám Rendsz Szöveg Dolgozik Logikai (d) Készítsünk indexet a szemszam kulcsmezőből SZEMREND néven! (e) Legyen a táblánk másodlagos neve DOLGOZO! (f) Töröljük az indexet! (g) Hozzuk létre az AUTO táblát az alábbi mezőkkel: AUTO: Mezőnév Típus Rendszam Szöveg Tipus Szöveg Szin Szöveg Ar Szám Kor Szám Megoldás: (a) CREATE TABLE ember (szemszam CHARACTER, nev CHARACTER); (b) ALTER TABLE ember ALTER (szemszam INTEGER); (c) ALTER TABLE ember ADD (fizetes INTEGER, rendsz CHARACTER, dolgozik LOGICAL); (d) CREATE INDEX szemrend ON ember (szemszam ASC); (e) CREATE SYNONYM dolgozo FOR ember; (f) DROP INDEX szemrend;

(g) CREATE TABLE auto (rendszam CHARACTER, tipus CHARACTER, szin CHARACTER, adatbázisok.doc - 98 - 2003.0909 ar INTEGER, kor INTEGER); 2. feladat: adatkezelő utasítások INSERT INTO táblanév / nézetnév / másodnév VALUES érték-lista); - új sorok bevitele a megadott táblába. UPDATE táblanév / nézetnév /másodnév SET mezőnév1=kifejezés1, , mezőnévn=kifejezésn WHERE feltétel; - táblák adott feltételnek megfelelő adatainak módosítása. DELETE FROM táblanév / nézetnév /másodnév WHERE feltétel; - táblák adott feltételnek megfelelő adatainak törlése. SELECT */mezőnév1, , mezőnévn FROM táblanév / nézetnév / másodnév WHERE [NOT] feltétel AND/OR [NOT] feltétel . GROUP BY mezőnév1, , mezőnévn HAVING [NOT] feltétel AND/OR [NOT] feltétel . ORDER BY mezőnév1 ASC/DESC, , mezőnévn ASC/DESC; - lekérdezés megvalósítása, a táblázat adott feltételeknek megfelelő megjelenítése A záradékok közül a SELECT és a FROM

kötelező, a többi opcionális. A SELECT utáni * szimbólum az összes mezőt jelenti. Ha csak egyes mezőket szeretnénk megjeleníteni, akkor a mezőket egyenként fel kell sorolni A FROM után meg kell adni, hogy mely táblázatból, vagy táblázatokból jelenjenek meg az adatok. A WHERE után kell megadni azt a feltételt, vagy feltételeket, amelynek, amelyeknek megfelelő rekordok a lekérdezés eredményeként meg fognak jelenni. A GROUP BY záradékkal a táblázat sorait valamelyik mező adatértékei alapján csoportosíthatjuk. A HAVING BY záradékot kell használnunk, ha a GROUP BY záradékban előírt csoportosítás nyomán keletkező csoportok közül nem mindet szeretnénk megjeleníteni. Az ORDER BY után kell megadni azokat a mezőket, amely alapján a megjelenő eredményeket rendszerezzük (ASC: növekvő, DESC: csökkenő). adatbázisok.doc - 99 - 2003.0909 (a) Vigyük be az adatbázisba az alábbi adatokat: Szemszám Név Fizetés Dolgozik Rendsz

17912154115 Kovács 45 000 Igen DOZ-219 28112011212 Nagy 75 000 Igen UIA-912 17501123124 Tóth 105 000 Nem DPA-812 17704273412 Szabó 155 000 Igen BIE-512 27603304871 Kovács 55 000 Igen AFA-314 Rendszám Típus Szín Ár AFA-314 Skoda Fehér 1 500 000 3 UIA-912 Opel Kék 2 100 000 2 DOZ-219 Mercedes Fekete 4 500 000 2 BIE-512 Suzuki 1 800 000 1 Fehér Kor (b) Kovács fizetését felemelték a kötelező minimumra. (c) Töröljük ki azokat, akik nem dolgoznak! (d) Jelenítsük meg azoknak az embereknek az adatait személyi szám szerint csökkenő sorrendben, akiknek a fizetése százezer forint alatt van! (e) Kérdezzük le fehér színű autók tulajdonosainak nevét és autójuknak típusát! Megoldás: (a) INSERT INTO ember VALUES( 17912154115, ’Kovács’, 45000, 1, ’DOZ-219’, 28112011212, ’Nagy’, 75000, 1, ’UIA-912’, 17501123124, ’Tóth’, 105000, 0, ’DPA-812’, 17704273412, ’Szabó’, 155000, 1,

’BIE-512’, 27603304871, ’Kovács’, 55000, 1, ’AFA-314’); INSERT INTO auto VALUES( ’AFA-314’, adatbázisok.doc ’Skoda’, ’Fehér’, 1500000, 3, ’UIA-912’, ’Opel’, ’Kék’, 2100000, 2, ’DOZ-219’, ’Mercedes’, ’Fekete’, 4500000, 2, ’BIE-512’, ’Suzuki’, ’Fehér’, 1800000, 1); - 100 - 2003.0909 (b) UPDATE ember SET fizetes=50000 WHERE nev=’Kovács’ AND fizetes < 50000; (c) DELETE FROM ember WHERE dolgozik=0; (d) SELECT * FROM ember WHERE fizetes<100000 ORDER BY szemszam DESC; (e) SELECT nev, tipus FROM ember, auto WHERE rendsz=rendszam AND szin=’Fehér’; 3. feladat: adat-felügyeleti utasítások CONNECT TO adatbázisnév USER felhasználónév; - az adatbázishoz való hozzáférés szabályozása. Az utasítással a felhasználó számára elérhetővé válik egy adatbázis (azonosító és jelszó begépelése után) SET CONNECTION adatbázisnév; - kapcsolódás az

adatbázishoz. DISCONNECT adatbázisnév; - kapcsolat megszüntetése. GRANT adatbázisjog TO public / felhasználói nevek listája; - felhasználói jogok adása az adatbázisra vonatkozóan. Adatbázisjogok: CONNECT (kapcsolódás az adatbázishoz és a négy adatkezelési művelet – adatbevitel, módosítás, törlés, lekérdezés – használata), RESOURCE (adatbázis kezelési joga, adatbáziselemek létrehozásának és megszűntetésének joga), DBA (bármilyen adatbázissal kapcsolatos művelet végzésének joga) GRANT műveleti jog ON adatbáziselem neve TO public / felhasználói nevek listája; - műveleti jogok adása a felhasználók számára. Adatbáziselemekre vonatkozó jog: ALTER (táblázat szerkezete megváltoztatásának joga) DELETE (sorok törlésének joga), INDEX (idexelés joga), INSERT (új sorok bevitelének joga), SELECT (lekérdezés joga), UPDATE (adatmódosítás joga), REFERENCES (hivatkozási jog), ALL (az összes felsorolt jog). (a)

Engedélyezzük a SZALLITOK adatbázishoz való hozzáférést a HALLGATO nevű felhasználónak! Kapcsolódjunk az adatbázishoz! (b) Mindenki számára engedélyezzünk adatkezelési műveleteket a SZALLITOK adatbázisok.doc - 101 - 2003.0909 adatbázisban! (c) Szüntessük meg a kapcsolatot a SZALLITOK adatbázissal! Megoldás: (a) CONNECT TO szállítók USER hallgato; SET CONNECTION szallitok; (b) GRANT CONNECT TO PUBLIC; (c) DISCONNECT szallitok; 7.1 Adatbázis-kezelés Access-ben Az Access relációs adatbázis-kezelő rendszer az adatok kezelését interaktívan és programnyelvi szinten is lehetővé teszi. Az SQL-felület használata mind interaktív módban, mind pedig programokba építve lehetséges. Az Access egyúttal egy CASE eszköz is, vagyis támogatja a számítógéppel segített alkalmazásfejlesztést. Az alkalmazás által elvégzendő műveletek egy részéből nem programmodulok, hanem makrók építhetők fel, és interaktívan lehet ezek

végrehajtását szabályozni. A program lehetővé teszi a menüszerkesztést, a többfelhasználós kezeléssel kapcsolatos zárolások, adatvédelmi jogok beállítását is. Az Access adatbázis-kezelő rendszer eszközeivel komplett, menüvezérelt, adatvédelemmel ellátott alkalmazást lehet készíteni. Az Access adatbázis a következő objektumokból épül fel: - Táblázatok: a relációs modell adatokat tartalmazó alaptáblázatai. - Lekérdezések: nézetek, virtuális táblázatok, adataik valójában az alaptáblázatok adatai különböző szempontok szerint csoportosítva. - Űrlapok: vezérlőelemeket tartalmazó képernyőterv az adatok képernyős megjelenítésére. - Jelentések: vezérlőelemeket tartalmazó nyomtatási terv az adatok nyomtatott megjelenítésére. - Makrók: előre definiált műveletek együttese. A makrók segítségével gyakran ismétlődő feladatokat hajthatunk végre. - Modulok: az adatbázis-kezelő rendszer programozási

nyelvének utasításaiból felépített függvényeket, eljárásokat tartalmazó programegységek. A jegyzetben az első négy objektumról lesz szó. adatbázisok.doc - 102 - 2003.0909 Adatbázis megnyitása Adatbázist (kiterjesztése MDB) a Windowsban szokásos módon nyithatunk meg. Bármelyik fájlkezelőben a fájlra duplán kattintva elindul az Access és benne megnyílik a kiválasztott adatbázis. A programon belül a Fájl menü Megnyitás menüpontjára kattintva tudunk a gépen lévő adatbázisok közül választani. Adatbázis és táblák létrehozása, szerkezet módosítása Egy teljes adatbázis elkészítéséhez segítségül hívhatjuk az adatbázis-varázslókat (Fájl menü, Új menüpont, Általános sablonok). Érdemes kipróbálni, mert az előre elkészített sablonokból számos ötletet meríthetünk. Ha varázslót használunk az adatbázisunk megtervezéséhez, az Access által előre meghatározott lépések szerint építhetjük fel

adatbázisunkat; anélkül, hogy bármit is tudnánk annak belső szerkezetéről. Csupán annyi lesz a dolgunk, hogy a kész adatbázisba – amelyben menüpontok és nyomógombok segítségével tudunk mozogni – beírjuk az adatokat. Az adatok különböző szempontok szerinti megjelenítéséhez szintén elegendő lesz egy-egy menüpont kiválasztása vagy egy-két gombnyomás. 7-1. ábra Access – adatbázis varázsló sablonok Ha már kellő gyakorlatra tettünk szert, létrehozhatunk teljesen üres adatbázist is (Fájl menü, Új menüpont, majd kattintás az Üres adatbázisra). Ebben az esetben minden adatbázisok.doc - 103 - 2003.0909 táblát, azok szerkezetét, a táblák között fennálló kapcsolatokat, a különböző nézeteket, űrlapokat, jelentéseket nekünk kell elkészítenünk. El kell neveznünk az adatbázisunkat Ezután kapunk egy ablakot (lásd az alábbi ábra); itt kattintsunk a Táblák létrehozása Tervező nézetben feliratra 7-2. ábra

Access – tábla létrehozása, 1 lépés Meg kell adnunk a táblában szereplő oszlopok (mezők) nevét és a mezők adattípusát. A típust – az adattípus mezőjének jobb sarkába kattintva – listából választhatjuk Kulcsmező megadáshoz kattintsunk rá jobb egérgombbal a kívánt mezőre és a megjelenő menüben válasszuk az Elsődleges kulcs menüpontot. A mező neve mellett megjelenik egy kulcs. Az Access nem teszi kötelezővé kulcsmező megadását Ha nem adunk meg kulcsot, mentéskor a program rákérdez, hogy akarunk-e egyet létrehozni. Ha igennel válaszolunk, létrejön egy számláló típusú kulcsmező A számláló típusú mezőket nem módosíthatjuk, azt a program automatikusan tölti ki az adatbevitel sorrendjében, ezzel biztosítja, hogy a kulcsmezőben ne legyen két egyforma érték. A mezőkre a típusukon kívül egyéb beállításokat is megadhatunk: mezőméret, tizedeshelyek, érvényességi szabály stb. adatbázisok.doc - 104 -

2003.0909 7-3. ábra Access – tábla létrehozása, 2 lépés A mezőnevek felvétele után el kell mentenünk a táblát a Fájl menü Mentés menüpontjával. A mentés során nevet kell adni a táblának A tervező nézetből a tábla szerkezeti ablakának bezárásával tudunk kilépni. (Ha úgy zárjuk be az ablakot, hogy még nem mentettünk, a program felkínálja a mentést. A többi objektum – lekérdezés, űrlap stb. mentése ugyanígy történik) 7-4. ábra Access – tábla létrehozása, 3 lépés Létező tábla szerkezetének módosításához jelöljük ki a táblát, majd kattintsunk az ablak Tervezés feliratú gombjára. A módosítás menete megegyezik az új tábla létrehozásának menetével A táblákat (és valamennyi később ismertetett objektumot a Windows-ban szokásos módon másolhatjuk, átnevezhetjük, vagy törölhetjük. Ezeket a funkciókat a táblán adatbázisok.doc - 105 - 2003.0909 (és a többi objektumon) a jobb egérgombbal

kattintva vagy a Szerkesztés menüből érhetjük el. Táblák megjelenítése, feltöltése, módosítása és törlése Egy tábla tartalmának megjelenítéséhez kattintsunk rá duplán. Látni fogjuk a táblából azt, ami egy képernyőn elfér, a további részek megtekintéséhez használjuk a görgetősávokat. Az adatokon végzett módosításokat nem kell elmenteni, arról az Access automatikusan gondoskodik! Az adatokat sorfolytonosan tudjuk bevinni. A kötelezően kitöltendő mezőket – például a kulcsmezőt – nem hagyhatjuk üresen Ügyeljünk arra, hogy a kulcsmezőben nem fordulhat elő kétszer ugyanaz az érték! Logikai típusú mezőnél a 9 (pipa) jelentése: igaz vagy 1, ha nincs pipa: hamis vagy 0. (A két állapot között a SZÓKÖZ billentyű vagy az egérkattintás vált.) Ha valamilyen adat nem fér ki, az oszlopok szélességét az oszlop szélének húzásával tudjuk változtatni (Ebben az esetben változik a szerkezet, tehát menteni kell!)

Legközelebbi megtekintéskor az adatok a kulcsmező szerint rendezve jelennek meg. Más mező szerinti rendezéshez jelöljük ki a mezőt, majd a Rekordok menü Rendezés menüpontjában válasszuk a csökkenő, vagy növekvő sorrendet. Módosításához rá kell állni a kívánt adatra és egyszerűen felül lehet írni, vagy ki lehet javítani. 7-5. ábra Access – tábla megjelenítése, feltöltése és módosítása Sor törléséhez jelöljük ki a sort, majd nyomjuk le a DEL billentyűt. Az Access megkérdezni, hogy biztosan törölni szeretnénk-e a rekordokat. Ha igennel válaszolunk, a kijelölt sor véglegesen törlődik az adatbázisból adatbázisok.doc - 106 - 2003.0909 Adatvédelem Az Access adatvédelmi szolgáltatásait az Eszközök menü Adatvédelem menüpontja alatt találjuk meg. Beállíthatunk adatbázisjelszót: 7-6. ábra Access – adatbázisjelszó beállítása Legközelebb az adatbázisunkat csak e jelszó ismeretében nyithatjuk meg.

Beállíthatjuk az egyes felhasználók, illetve felhasználói csoportok hozzáférési jogait: 7-7. ábra Access – felhasználói és csoportengedélyek beállítása adatbázisok.doc - 107 - 2003.0909 7.2 Az Access programozása Lekérdezések Az adatbázis-kezelő Lekérdezés objektuma segítségével nézeteket készíthetünk az alap adattáblákhoz. A lekérdezés létrehozásához használjuk a Tervező nézetet, mellyel könnyen és gyorsan tudunk nézeteket definiálni. A programnak ebben a részében akár SQL-ben is dolgozhatunk A nézeteket megnyitni a nevére dupla kattintással lehet, módosításokat végezni pedig úgy tudunk, hogy a Tervezés gombra kattintunk. 1. feladat: Táblakészítés, adatbevitel Készítsük el az alábbi három táblát! Mindhárom táblából készítsünk másolatot EMBER2, AUTÓ2, VEZET2 néven. EMBER Szemszám Név Cím Fizetés Születés Dolgozik 17912154115 Kovács Szeged 55 000 1979.1215 Igen 28112011212 Nagy

Budapest 75 000 1981.1201 Nem 17501123124 Tóth Szeged 105 000 1975.0112 Nem 17704273412 Szabó Győr 155 000 1977.0427 Igen 27603304871 Kovács Debrecen 55 000 1976.0330 Igen 21901129124 Sós 40 000 1919.0112 Nem Szeged AUTÓ Rendszám Típus Szín DPA-812 Lada Piros AFA-314 Skoda UIA-912 Ár Kor Ütközött 500 000 17 Igen Fehér 1 500 000 3 Nem Opel Kék 2 100 000 2 Nem CGA-719 Trabant Zöld 50 000 30 Igen DOZ-219 Mercedes Fekete 4 500 000 2 Igen BIE-512 Suzuki 1 800 000 1 Nem adatbázisok.doc Fehér - 108 - 2003.0909 VEZET Szemszám Rendszám 27603304871 DOZ-219 17704273412 BIE-512 17501123124 DPA-812 28112011212 UIA-912 17912154115 AFA-314 Megoldás: 7-8. ábra Access – EMBER tábla szerkezete és feltöltése 7-9. ábra Access – AUTÓ tábla szerkezete és feltöltése adatbázisok.doc - 109 - 2003.0909 7-10. ábra Access – VEZET tábla szerkezete és feltöltése 2. feladat: Választó lekérdezés A

Lekérdezés ablak két részből áll. A felső részben látjuk azokat a táblákat, amikkel dolgozunk, az alsó részben pedig a megjelenítendő mezőket és a megjelenítés feltételeit. Ha a felső részben duplán kattintunk a kiválasztott mezőre, akkor az az alsó részben a megjelenítendő mezők között fog megjelenni. A feltételeket a megfelelő mezőkre kattintva tudjuk módosítani. Készítsünk egy olyan lekérdezést, ami tartalmazza (a) az emberek valamennyi adatát EMBERMIND néven, (b) az autók típusát és korát TIPUSKOR néven, (c) az autótulajdonosok nevét, autójuk típusát és rendszámát név szerint rendezett sorrendben, NÉVTIPREND néven, (d) a szegedi autók átlagárát SZEGAUT néven, (e) az autók típusát és nettó árát NETTOÁR néven! Megoldás: Kattintsunk a Lekérdezések létrehozása tervező nézetben feliratra, majd (a) adjuk hozzá a lekérdezéshez az EMBER táblát. Kattintsunk duplán a *-ra (csillagra), így a tábla

valamennyi mezőjének adata meg fog jelenni. Ha tervező nézetből átváltunk SQL nézetbe (Nézet menü, SQL menüpont) láthatjuk az utasítás SQL megfelelőjét is. Ez a nézet teljesen megegyezik azzal, amit az EMBER alaptábla megnyitása esetén kapnánk, továbbá az adatok ugyanúgy rendezhetők, szűrhetők, módosíthatók, vagy törölhetők. Az itt végzett adatmódosítások megjelennek az alaptáblában is adatbázisok.doc - 110 - 2003.0909 Tervező nézetben: SQL nézetben: SELECT Ember.* FROM Ember; 7-11. ábra Access – választó lekérdezés (a). 7-12. ábra Access – választó lekérdezés (a) megnyitása (b) adjuk hozzá a lekérdezéshez az AUTÓ táblát. Kattintsunk duplán a Típus és a Kor mezőkre. Tervező nézetben: SQL nézetben: SELECT autó.típus, autókor FROM autó; 7-13. ábra Access – választó lekérdezés (b) adatbázisok.doc - 111 - 2003.0909 (c) adjuk hozzá a lekérdezéshez az EMBER, VEZET és AUTÓ táblát is.

Az EMBER és az AUTÓ tábla között a VEZET jelenti a kapcsolatot; ebben tároljuk azt, hogy kinek milyen autója van1. Az Access automatikusan összeköti a táblákban azokat a mezőket, amelyekkel – a program szerint – a két tábla összekapcsolható. Mi is hozhatunk létre kapcsolatokat: megfogjuk a kívánt mezőt és áthúzzuk a másik tábla azon mezőjére amivel kapcsolatot akarunk létrehozni. Jelen esetben az EMBER nevű tábla SZEMSZÁM mezőjét a VEZET tábla SZEMSZÁM mezőjéhez, és a VEZET tábla RENDSZÁM mezőjét az AUTÓ tábla RENDSZÁM mezőjéhez kapcsoljuk. Az összekötő mezőknek nem kell azonos nevűeknek lenniük, a típusuknak viszont meg kell egyezniük! A kapcsolatokat úgy törölhetjük, hogy kijelöljük, majd lenyomjuk a DEL billentyűt Háromféle kapcsolatot tudunk létrehozni; választani úgy tudunk, ha a kapcsolatot jelző vonalra duplán kattintunk: - csak olyan sorok jelenjenek meg, amelyeknél az illesztett mezők mindkét

irányban megegyeznek (vagyis azok az emberek, akiknek nincs autójuk, valamint azok az autók, amelyeknek nincs tulajdonosuk, nem jelennek meg), - jelenjen meg az első tábla (amihez illesztünk) minden rekordja és a második (illesztett) tábla azon rekordjai, ahol az illesztett mezők azonosak (vagyis jelenjen meg az összes ember adata és azon autók adatai, amelyeknek van tulajdonosa), - jelenjen meg a második (illesztett) tábla minden adata és az első tábla (amihez illesztünk) olyan adatai, ahol az illesztett mezők azonosak (vagyis jelenjen meg az összes autó adata és azoknak az embereknek az adatai, akik autótulajdonosok). Kattintsunk duplán a NÉV, RENDSZÁM és TÍPUS mezőkre, majd a NÉV oszlopában a Rendezés mezejére kattintva állítsunk be növekvő rendezési sorrendet. 1 Jelen példában 1:1 kapcsolatot feltételezünk. Vajon hogyan változik a modell 1:N kapcsolat esetén, ha egy embernek több autó lehet a birtokában? adatbázisok.doc -

112 - 2003.0909 7-14. ábra Access – választó lekérdezés, illesztési tulajdonságok Tervező nézetben: 7-15. ábra Access – választó lekérdezés (c) SQL nézetben: SELECT Ember.név, vezetrendszám, autótípus FROM (Ember INNER JOIN vezet ON Ember.szemszám = vezetszemszám) INNER JOIN autó ON vezet.rendszám = autórendszám ORDER BY Ember.név; (d) adjuk hozzá a lekérdezéshez az EMBER, VEZET és AUTÓ táblákat és hozzuk létre a kapcsolatokat úgy, mint előbb. A CÍM és ÁR mezőkre lesz szükségünk Csak a szegediek címére vagyunk kíváncsiak, a CÍM alá a feltétel mezőbe írjuk adatbázisok.doc - 113 - 2003.0909 be a „Szeged”-et. A mezőt nem kell megjeleníteni, kapcsoljuk ki a megjelenítését Mivel nem az egyes árakra vagyunk kíváncsiak, hanem csak egy összesítésre, a Nézet menü Összesítés menüpontjára kattintsunk rá. Kapunk egy új sort, melyben a GROUP BY felirat látható. Az ÁR oszlopában lévő Összesítés

mezőben lévő GROUP BY-ra kattintva megkapjuk az összesítő függvények listáját, melyek közül most válasszuk ki az átlagot (AVG). Tervező nézetben: 7-16. ábra Access – választó lekérdezés (d) SQL nézetben: SELECT Avg(autó.ár) AS AvgOfár FROM (Ember INNER JOIN vezet ON Ember.szemszám = vezetszemszám) INNER JOIN autó ON vezet.rendszám = autórendszám GROUP BY Ember.cím HAVING (((Ember.cím)="Szeged")); (e) adjuk hozzá a lekérdezéshez az AUTO táblát és kattintsunk duplán a TÍPUS mezőre. A következő oszlopban az ár 0,8-szeresét kell kiszámolnunk: [ár]*0,8. Ha mezőkkel műveleteket végzünk, a mező nevét szögletes zárójelbe kell tenni. adatbázisok.doc - 114 - 2003.0909 Tervező nézetben: SQL nézetben: SELECT autó.típus, [ár]*0.8 AS Kif1 FROM autó; 7-17. ábra Access – választó lekérdezés (e) 3. feladat: Táblakészítő lekérdezés Készítsünk az autótulajdonosok nevét, autójuk típusát és

rendszámát név szerint rendezett sorrendben tartalmazó új táblát ÚJTÁBLA néven! MEGOLDÁS: A táblakészítő lekérdezés annyiban különbözik csak a választó lekérdezéstől, hogy az eredményt nem a képernyőn jeleníti meg a program, hanem új táblába menti. Készítésekor ugyanúgy kell eljárni, mintha választó lekérdezést hoznánk létre, majd a Lekérdezések menü Táblakészítő lekérdezés menüpontját kell választani. Az új tábla nevét meg kell adni! Ez az új tábla akkor jön létre, amikor legközelebb megnyitjuk a lekérdezést. Tervező nézet: 7-18. ábra Access – táblakészítő lekérdezés adatbázisok.doc - 115 - 2003.0909 SQL nézet: SELECT Ember.név, vezetrendszám, autótípus INTO ÚJTÁBLA FROM (Ember INNER JOIN vezet ON Ember.szemszám = vezetszemszám) INNER JOIN autó ON vezet.rendszám = autórendszám ORDER BY Ember.név; 4. feladat: Törlő lekérdezés Töröljük ki a Trabant és a Mercedes típusú gépkocsik

adatait az AUTO2 táblából! (A lekérdezés neve: TÖRÖL.) Megoldás: Csak az AUTO2 táblára van szükségünk a lekérdezés létrehozásához. A Lekérdezés menüben a Törlő lekérdezést kell kiválasztani A Típus mezőre kattintsunk kétszer, majd a Feltétel mezőbe írjuk be a két típust egymás alá! Ügyeljünk arra, hogy nem logikai ÉS, hanem logikai VAGY kapcsolatot kell használnunk! Az adatok a lekérdezés megnyitásakor – jóváhagyás után – törlődnek az AUTO2 táblából. Tervező nézet: SQL nézet: DELETE autó2.típus FROM autó2 WHERE (((autó2.típus)="Trabant")) OR (((autó2.típus)="Mercedes")); 7-19. ábra Access – törlő lekérdezés adatbázisok.doc - 116 - 2003.0909 5. feladat: Frissítő lekérdezés Készítsünk EMELÉS néven olyan frissítő lekérdezést, ami 10%-kal megemeli a tízezer és negyvenezer forint fizetéssel rendelkező szegediek és a budapestiek fizetését! Megoldás: Az EMBER táblát

adjuk hozzá a lekérdezéshez, majd válasszuk a Lekérdezés menü Frissítő lekérdezés menüpontját. A CÍM és a FIZETÉS mezőkre lesz szükségünk A CÍM a feltétel megadásához kell: „Szeged” vagy „Budapest”, ez egy logikai VAGY kapcsolat. A fizetés alsó és felső határa között logikai ÉS kapcsolat áll fent: >40000 AND <70000. A feltételeknek megfelelő fizetéseket módosítjuk plusz 10%-kal, tehát a fizetés módosítása: [fizetés]*1,1. A lekérdezés minden egyes megnyitásakor a feltételeknek megfelelő rekordok fizetés mezője 10%-kal emelkedik Tervező nézet: SQL nézet: UPDATE Ember SET Ember.fizetés = [fizetés]*1.1 WHERE (((Ember.cím)="Szeged") AND ((Ember.fizetés)>40000 AND (Ember.fizetés)<70000)) OR (((Ember.cím)="Budapest")); 7-20. ábra Access – frissítő lekérdezés 6. feladat: Hozzáfűző lekérdezés A lekérdezés segítségével egy táblához hozzáadhatjuk egy másik, ugyanolyan

szerkezetű tábla adatait. A hozzáfűzendő tábla kulcsértékei nem egyezhetnek meg az eredeti tábla kulcsértékeivel. adatbázisok.doc - 117 - 2003.0909 Készítsünk másolatot AUTÓ3 néven az AUTÓ2 tábláról, majd az AUTÓ3-ban első kivételével módosítsuk az összes rendszámot! Az AUTÓ3-hoz ezek után fűzzük hozzá az AUTÓ2-t! (A lekérdezés neve: HOZZÁFŰZ.) Megoldás: Készítsük el a másolatokat, majd válasszuk ki az AUTO2 táblát, és annak valamenynyi mezőjét. A Lekérdezés menüben kattintsunk a Hozzáfűző lekérdezés menüpontra Itt meg kell adnunk, hogy melyik táblához fűzünk hozzá; válasszuk az AUTÓ3-at Ha lefuttatjuk a lekérdezést, kapunk egy figyelmeztetést, mely szerint az Access nem tudta az összes rekordot hozzáfűzni a táblához, aminek oka, hogy a két táblában vannak azonos kulcsértékkel rendelkező sorok. Tervező nézet: SQL nézet: INSERT INTO auto3 SELECT autó2.* FROM autó2; 7-21. ábra Access –

hozzáfűző lekérdezés Űrlapok 7. feladat: Űrlapvarázsló Készítsünk űrlapot az autótulajdonosok nevének, az autó rendszámának, valamint típusának megjelenítésére! Megoldás: Az űrlapokat az alaptáblák és a nézetek képernyőn való megjelenítésére használhatadatbázisok.doc - 118 - 2003.0909 juk. Kattintsunk az Űrlapok gombra Választhatunk az Űrlap tervezése és az Űrlap létrehozása varázsló segítségével lehetőségek között. Ez utóbbi többnyire elegendő szolgáltatást biztosít az átlagfelhasználó számára, válasszuk mi is ezt a lehetőséget Első lépés: ki kell választanunk az adattáblát, vagy választó lekérdezést, amit meg akarunk jeleníteni. Válasszuk most a korábban elkészített NÉVTIPREND választó lekérdezésünket (lásd 2(c) feladat) és annak összes mezőjét. A következő lépésben választjuk ki az űrlap szerkezetét. Esetünkben legyen Oszlopos, de próbaképpen a többit is meg lehet tekinteni

A harmadik lépésben különböző stílusok közül választhatunk; legyen: Nemzetközi. Az utolsó lépésben nevet kell adni az űrlapunknak (NÉVTIPREND) és el kell döntenünk, hogy megnézzük a végeredményt, vagy saját elképzeléseinknek megfelelően tovább módosítjuk azt. 7-22. ábra Access – űrlapkészítés, 1 lépés adatbázisok.doc - 119 - 2003.0909 7-23. ábra Access – űrlapkészítés, 2 lépés 7-24. ábra Access – űrlapkészítés, 3 lépés adatbázisok.doc - 120 - 2003.0909 7-25. ábra Access – űrlapkészítés, 4 lépés Abban az esetben, ha úgy döntünk, hogy még szeretnénk módosítani az űrlapon, válasszuk az Űrlap tervének módosítása pontot. (Ha az űrlap varázsló helyett az Űrlap tervezése pontot választjuk, ugyanebbe az űrlapszerkesztő ablakba jutunk) A megnyíló űrlapszerkesztő ablakban az űrlap teste szabásához az alábbi eszközkészletek állnak rendelkezésre: felirat, beviteli mező,

vezérlőelem csoport, váltógomb, választókapcsoló, jelölőnézet, kombi panel, listapanel, parancsgomb, kép, kötetlen objektumkeret, kötött objektumkeret, oldaltörés, karton vezérlőelem, segédűrlap/segédjelentés, vonal, téglalap, további vezérlők. Ezek ismertetése meghaladja ezen jegyzet kereteit, ezért ismertetésüktől eltekintünk. adatbázisok.doc - 121 - 2003.0909 7-26. ábra Access – űrlap módosítása Az űrlapot megtekinthetjük, ha a nevére kétszer rákattintunk. 7-27. ábra Access – elkészült űrlap Jelentések 8. feladat: Jelentésvarázsló Készítsünk az autótulajdonos nevét, az autó rendszámát és típusát tartalmazó jelentést! Megoldás: Itt is használhatunk tervező nézetet: Jelentés létrehozása tervező nézetben; vagy varázslót: Jelentés létrehozása varázsló segítségével. Kattintsunk ez utóbbira Az első lépésben meg kell adnunk annak a táblának, vagy lekérdezésnek a nevét, amiből a

jelentés készül. Válasszuk a NÉVTIPREND lekérdezést (lásd a 2(c) feladatot) és annak összes mezőjét adatbázisok.doc - 122 - 2003.0909 7-28. ábra Access – jelentéskészítés, 1 lépés A következő lépésben ún. csoportszintet adhatunk meg Itt állíthatjuk be, hogy az adataink valamilyen szempont szerint csoportonként legyenek összegezve, átlagolva stb. Jelen feladatban itt nem kell beállítanunk semmit 7-29. ábra Access – jelentéskészítés, 2 lépés adatbázisok.doc - 123 - 2003.0909 A harmadik lépésben rendezési szempontokat adhatunk meg: milyen mezők alapján és hogyan legyenek rendezve a kinyomtatandó adataink. Állítsunk be név szerinti elsődleges, típus szerinti másodlagos és rendszám szerinti harmadlagos rendezést. 7-30. ábra Access – jelentéskészítés, 3 lépés A negyedik lépésben kell megadnunk a jelentés szerkezetét és tájolását. Állítsunk be táblázatos szerkezetet és álló lapot.

adatbázisok.doc - 124 - 2003.0909 7-31. ábra Access – jelentéskészítés, 4 lépés Az ötödik lépésben határozhatjuk meg jelentésünk stílusát. Válasszunk tetszés szerint 7-32. ábra Access – jelentéskészítés, 5 lépés Végül nevet kell adnunk a jelentésünknek (NÉVTIPREND) és választhatunk: megnézzük az eredményt, vagy még módosítunk rajta. Ha a módosítás mellett döntünk, kattintsunk a Jelentésterv módosítása opcióra. adatbázisok.doc - 125 - 2003.0909 7-33. ábra Access – jelentéskészítés, 6 lépés A jelentés módosítására ugyanazok az eszközök állnak rendelkezésünkre, mint az űrlaptervezés esetén. 7-34. ábra Access – jelentésterv módosítása A jelentés nyomtatási képét megtekinthetjük, ha nevére duplán kattintunk. adatbázisok.doc - 126 - 2003.0909 7-35. ábra Access – jelentés nyomtatási képe adatbázisok.doc - 127 - 2003.0909 8. Nagy adatbázisok Az informatika

nélkülözhetetlen egy korszerű és sikeres vállalat működésében: a vállalat valamennyi működési területét átszövi, kezdve a mindennapi operatív működéstől egészen a stratégiai célok meghozataláig. Az operatív, mindennapi működést támogató – általában relációs adatbázis-kezelő – rendszerek csupán legfeljebb néhányszáz megabájtnyi adattal dolgoznak és gyakran frissülnek. Ezen rendszerek kezelését a beosztottak végzik A vezetők számára készülő (stratégiai) döntéshozatalt támogató rendszereknek ezzel szemben több száz gigabájt, esetleg terrabájt mennyiségű – ritkábban frissített – adatot kell kezelniük, általában csak lekérdezniük. E vezetői információs rendszerek ma már nem képzelhetők el rendszerezett, megbízható minőségű és gyorsan elérhető adatok nélkül. A vezetői döntés-támogató rendszerek az alaprendszerekből táplálkozó, gyors, többdimenziós összesítésre képes, elemzést,

tervezést, ellenőrzést programozás nélkül támogató, fejlett megoldások. Fontos jellemzőjük, hogy válaszolni tudnak a „Mi lenne ha?” típusú kérdésekre A rendszerek interaktív jelentéseket, grafikonokat és összefoglalókat készítenek ismert alkalmazásokon keresztül (mint amilyen például egy Excel táblázat, vagy diagram) A döntéstámogató rendszerek legfontosabb jellemzői: - Működési algoritmusában az egyszerű adatolvasás és adatírások helyett az adatok analitikus, statisztikus elemzése dominál; vagyis a normál adatkezelő utasítások mellett rendelkeznie kell adatelemző komponensekkel is. - A legfontosabb cél az adatok mögött húzódó trendek felderítése, vagyis az események változási irányát, a változás jellegét kell meghatározni. - Csak olvassák a letárolt adatokat, és nem tartalmaznak adatmódosítási elemeket. A döntéshozáshoz csak a meglévő információkat kell felderíteni (A rendszer a döntés

meghozatalát segíti, magát a döntést már nem a rendszer fogja meghozni.) adatbázisok.doc - 128 - 2003.0909 - A megfelelő minőségű, megbízható előrejelzéshez kellő adatmennyiség szükséges. Csekély múltbeli adatokból nem lehet pontos elemzést, trendszámítást végezni, emiatt a rendszerek igénylik a nagy adatmennyiséget. - A döntéstámogató rendszerekben nagyobb szerep jut az időbeliségnek, vagyis annak, hogy egy adatelem, mely időpontbeli aktuális állapotnak felel meg. A hagyományos rendszerekben az időnek nem volt ilyen nagy jelentősége, hiszen minden adat az éppen aktuális időpontra vonatkozott. Ebben az esetben viszont szükségszerű minden adatelemet egy időértékkel is összekapcsolni, ha időbeli trendek figyelését is megkívánjuk a rendszertől. - A rendszereknek felhasználóbarát kezelő felülettel kell rendelkezniük, hogy a számítástechnikában kevésbé járatos vezetők is alkalmazni tudják. A kezelő

felületnek a lekérdezések terén megfelelő rugalmasságot kell mutatnia, hiszen a döntések meghozatalánál az a jó, ha problémát sok oldalról, többféle megközelítésben lehet megvizsgálni, s ehhez a tárolt adatokból többféle szempont szerinti lekérdezésekre is szükség lehet. A vezetői döntéstámogató és információs rendszer létrehozása az informatikai rendszer kiépítésének befejező lépése. Csak akkor érdemes vele foglalkozni, ha az adatbázisokat létrehoztuk és a feldolgozói programokat már beüzemeltük Természetesen az informatikai fejlesztéseket taglaló tervekben ezt az igényt is szerepeltetni kell: nem szerencsés, ha utólag illesztjük az igények közé a vezetői információs rendszert. 8.1 Adattárházak A bonyolultabb döntéstámogató rendszerek meghatározott feltételrendszer alapján emelik ki az adatokat a vállalati adatbázisokból és azokat adattárházban tárolják. Az adattárházak megfelelő struktúrában,

elemzéshez előkészítve, történeti rálátással gyűjtik össze a vállalatok életében felmerülő külső és belső adatokat, amelyek bekerülésük után már nem változnak. Tulajdonképpen az adattárházak is adatbázisok, de sokkal fejlettebb a feltöltési, karbantartási és lekérdezést végző eszközökkel, módszerekkel. Az adattárházakban a különböző adatforrásokból nyert adatokat olyan struktúrában kell elhelyezni, hogy a bennük tárolt információk igény szerint, változatos formában legyenek lekérdezhetők, tegyék lehetővé a múlttal való öszadatbázisokdoc - 129 - 2003.0909 szehasonlítást és különböző előrejelzési lehetőségeket is biztosítsanak. Az adattárházak fogalmának kialakulása az 1970-es évek végére tehető. Erre az időszakra már megjelentek az első nagy információs rendszerek, melyek elsődlegesen a napi működési rendszer igényeit szolgálták ki. E rendszerekre felépített döntéstámogató

alkalmazások súlyos hiányossága egyrészt a műveleti sebesség lassúsága, másrészt pedig az volt, hogy szétdarabolt adatszigetekből állt fel a rendszer. Ez utóbbi annak volt köszönhető, hogy minden nagyobb területnek megvolt a saját adatbázisa; a döntéstámogató rendszernek ezen adatbázisokból kellett összeszednie az elemzésre kerülő adatokat. A hiányosságok leküzdésére jelent meg az új döntéstámogatásra orientált adatkezelő rendszer, az adattárház. Világméretű elterjedése annak köszönhető, hogy segítségével megalapozott és gyors döntések hozhatók A felhasználók elemezni tudják a különböző események hatását és a tevékenységükkel kapcsolatos trendeket. Ennek eredményeként a felhasználók idejüket hasznosan, az adatok megkeresése, összegyűjtése, rendezése helyett a fontos információk analizálásával, elemzésével és a szükséges intézkedések megtételével tölthetik. Az adattárház rendszer egy

témaorientált, integrált, időben változó adatrendszernek tekinthető, melynek elsődleges célja a stratégiai döntések támogatása. Az adattárházban tárolt adatrendszer több helyről származó, integrált adatokat tartalmazhat Vagyis az adattárház egy gyűjtőhely, amelybe számtalan forrásból származó adatelemek kerülhetnek bele. Az adattárházak nem csak az adatelemeket, hanem az azok között fennálló kapcsolatokat is tárolják. Az adattárház megoldások a hagyományos, gyenge hatékonyságú információs folyamatot gyökeresen átalakítják az alábbi elvek szerint: - a különböző forrásokból származó adatok rendszeres időközönként leválogatásra és betöltésre kerülnek egy központi adatbázisba, - az alapadatok az üzleti elemzési szempontoknak megfelelően feldolgozásra kerülnek, - az adatok egy helyen, az üzleti gondolkodásnak megfelelő új struktúrában kerülnek eltárolásra, adatbázisok.doc - 130 - 2003.0909 -

az adatok on-line elérhetővé válnak a vezetők és elemzők számára, - az elemzéshez szükséges funkciókat standard elemző eszközök vagy egyedi alkalmazások biztosítják. Az adattárházakon működő lekérdező, döntéstámogató, elemző eszközök képességei eltérnek egy hagyományos operatív vállalatirányítási rendszer képességeitől. Itt kell megemlíteni az OLAP technika (Online Analytical Processing) fogalmát. Ez többdimenziós alapú adatbázis alkalmazás Az információkat a dimenziók (például idő, értékesítési csatorna, földrajzi elhelyezkedés, beszállítói csoportok, alkalmazott technológiák stb.) mentén több irányból teszi hozzáférhetővé, elemezhetővé Az adattárházak egy másik felhasználása az adatbányászat. Ez olyan számítástechnikai és statisztikai módszerekből valamint algoritmusokból álló eszközrendszer, amelynek segítségével az általunk fel nem ismert összefüggésekre is fényt

deríthetünk. Elsősorban a marketing, illetve a kereskedelem területén alkalmazzák, de ma már a termelésben és a logisztikában is hasznát veszik. Egy adattárház kialakítása komoly beruházást igényel és kidolgozott módszertant kíván. Létrehozása több hónapos, gyakran több éves kemény munkát követel Az adattárházak megvásárláskor üresek, de beépített vagy csatolható eszközökkel az üzleti cél alapján feltölthetőek. Az adattárház rendszerek különböző adat kivonó és tisztító eszközöket, valamint betöltő és frissítő segédprogramokat használnak az adattárház feltöltésére. - Tisztítás. Az integrált adatrendszer kialakításánál fontos, hogy csak megbízható információk kerüljenek be a rendszerbe Azonban mivel a nagy mennyiségű adat többszörös forrásból jön össze, nagyon valószínű, hogy az adatokban hibák és anomáliák vannak Ezért az adatok beolvasásánál az adatok helyességének az

ellenőrzésére is törekedni kell, mely folyamatot szokás az adatok tisztításának is nevezni. A tisztítás során a megfelelő segédprogram segítségével lehetőség van bizonyos értékhibák feltárására. A fejlettebb ellenőrzési rendszerek nemcsak a statikus hibákat veszik észre, hanem alkalmasak nem definiált szabályok feltárására is A szabálytól eltérő, gyanúsnak tartott értékek esetén egy figyelmeztető üzenetet küldenek a felhasználónak - Töltés. Miután kinyertük, megtisztítottuk és átalakítottuk az adatokat, be kell töltenünk azokat az adattárházba. További előfeldolgozások lehetnek még adatbázisok.doc - 131 - 2003.0909 szükségesek: integritási feltételek ellenőrzése; rendezés; összegzés, csoportosítás és egyéb számítások, hogy felépítsük az adattárházban tárolt leszármaztatott táblákat; az indexek és egyéb elérési útvonalak építése, stb. Az adattárház feltöltésén kívül a

betöltő segédprogramnak meg kell engednie, hogy a rendszer adminisztrátor felügyelhesse az állapotot, törölhesse, felfüggeszthesse és újra kezdhesse a betöltést, illetve hiba után az adatintegritás elvesztése nélkül újraindíthassa azt. - Frissítés. Egy adattárház frissítése abból áll, hogy továbbítani kell a forrásadatokon végzett módosításokat, hogy a rendszer megfelelően módosítsa az adattárházban tárolt bázisadatokat és leszármazott adatokat. Az adattárházakat általában periódikusan frissítik (például naponta vagy hetente) Ez függ a felhasználók szükségleteitől, az adattárház forgalmától és különböző forrásokra különböző lehet. 8.2 Üzleti intelligencia rendszerek Az üzletmenet során hatalmas mennyiségű adat halmozódik fel minden nap: megrendelés-, raktár-, könyvelési-, kereskedelmi- és ügyfél információk, illetve további adattömegek külső forrásokból. Az üzleti adatok mennyisége

exponenciálisan, minden 2-3 évente duplájára növekszik A szervezetek számára tehát létkérdés, hogy költséghatékonyan és gyorsan hozzáférjenek az üzleti információkhoz. Az integrált vállalatirányítási információs rendszerek által szolgáltatott jelentések, listák képesek a vezetők számára információkat szolgáltatni, de bonyolult döntések előkészítésére és mélyebb elemzésekre már nem mindig alkalmasak. E probléma megoldását jelenthetik az üzleti intelligencia rendszerek. Ezek technológiák és termékek széles választékát nyújtják, hogy ellássák a felhasználókat az összes információval, amelyre szükségük van, hogy meg tudják hozni a taktikai és stratégiai döntéseket Ezek a rendszerek jelentik a vállalatirányítási információs rendszerek integrációjának legmagasabb szintjét Adattárházakon alapulnak; a különböző területekről összegyűjtik, integrálják és speciális sémákban tárolják a

maximális részletezettségig visszakereshető adatokat, valamennyi adatot (külső belső, konkurens, piac, gazdasági, politikai környezet stb.), ami a vállalat működése során felmerül, ill amelyre a vállalat működése során szükség lehet. Így az üzleti intelligencia rendszer válaszolni tud valamennyi olyan kérdésre, ami a vállalat irányítása során felmerül. adatbázisok.doc - 132 - 2003.0909 Az üzleti intelligencia több, mint adatok és technológiák kombinációja: az információ tudássá transzformálásáról szól, a megfelelő adat eléréséről, a benne rejlő lehetőségek felfedezésétről és értékeinek megosztásáról. A legfejlettebb informatikai technológiákat hasznosító üzleti intelligencia rendszerek lehetővé teszik, hogy a felhasználók hozzájussanak a stratégiai és taktikai kérdések eldöntéséhez elengedhetetlenül szükséges információkhoz a megfelelő időben, a megfelelő helyen és a nekik megfelelő

módon. Új, divatos lehetőségek az üzleti intelligenciában: - Stratégiai döntéstámogató rendszer. Az üzleti tevékenységeket nemcsak pénzügyi oldalról, hanem az ügyfelek, belső működési folyamatok és az emberi erőforrás oldaláról is mérhetővé kell tenni. A pénzügyi célok teljesülését elégedett, visszatérő vevőkkel lehet kielégíteni. A vevőt a vállalati anyagi, irányítási és értékfolyamatok révén szolgálják ki A folyamatok pedig a szervezetben dolgozó emberre épülnek A rendszer ezeken a területeken előre meghatározott mutatók, mérőszámok alakulását vizsgálja Egyszerűen mérhető, szakmailag még kezelhető számú (15-25) mutatót kell definiálni. A cél a több dimenzióban történő gondolkodás. A stratégiai döntéstámogató rendszer az üzleti stratégia szervezeti lebontására is megoldást kínál, így minden szervezeti egység a vállalatival összhangban lévő, saját stratégiát alakíthat ki. Az alsó

szintek megismerhetik saját munkájuk hatását a vállalat működésére Az adatok a cég ügyviteli, műszaki elemző rendszereiből, de akár adattárházból is származhatnak. - Ügyfélkapcsolatok kezelése. Az igazi kereskedő egyik legfontosabb célja az ügyfél vagy vevő lehető legteljesebb megismerése, és ezeknek az ismereteknek a kihasználása újabb és újabb eladások érdekében. A marketing a vállalkozások nagy részénél még mindig termékközpontú Nem az ügyfelekre figyelnek, hanem a rövid távú eladási adatokra A közeljövő sikeres cégeinek figyelembe kell venniük az ügyfelek egyedi igényeit, meg kell próbálniuk személyre szabott árut és szolgáltatást nyújtani, valamint hosszú távú, stabil ügyfélkapcsolatot kiépíteni. Az ügyfélkapcsolati rendszerek a következő területeken nyújtanak segítséget: kapcsolattartás (vevők, ügyfelek elérhetősége), értékesítési és marketing akciók tervezése, értékesítési

folyamat követése, aján- adatbázisok.doc - 133 - 2003.0909 lat és rendelés nyilvántartás, értékesítési csatornák kezelése, telefonos vevőszolgálat, szerviz és lízing szerződések kezelése, dokumentumkezelés, döntéstámogatás különböző elemzések, statisztikák segítségével, telemarketing, ügyfélkapcsolat gondozása. - Ellátási, beszállítói lánc kezelése. Ezek a rendszerek együttműködést feltételeznek a lánc tagjai – azaz a beszállítók – között, racionalizálva a logisztikai rendszert. A résztvevők önállóságukat megőrizve egyesítik erőforrásaikat Az alábbi területeken adnak megoldást: vevői igények felmérése, készletek beszerzése, gyártási folyamatok tervezése, rendeléskövetés, késztermék elosztás, piackutatás és terméktervezés. Az üzleti intelligencia alkalmazása fegyelmet kényszerít a vállalatokra, megköveteli a mutatók és az üzleti fogalmak cégen belüli azonos értelmezését.

Nehezen integrálhatóak a szervezeti egységek vezetőinek egyéni „sziget-megoldásai” Előnyös, ha az adatokat egy megbízható információkat nyújtó integrált vállalatirányítási információs rendszerből vesszük. Egy piackutató cég előrejelzése szerint a vezetői információs és döntéstámogatási rendszerek piacán 2002-re az operatív rendszerek és döntéstámogató rendszerek jelenlegi 70-30%-os aránya 30-70%-osra változik. A drasztikus változást azzal indokolják, hogy a hangsúly a döntéstámogatási munkát segítő információk gyors elérésére helyeződik adatbázisok.doc - 134 - 2003.0909 Felhasznált és ajánlott irodalom 1. Czenky Márta: Adatmodellezés SQL és Access alkalmazás Computerbooks Budapest. 2001 2. Grupi, Kristen et al: Microsoft Office XP lépésről lépésre Szak Kiadó 2001 3. Hetyei József: Vállalatirányítási információs rendszerek Magyarországon Computerbooks. Budapest 1999 4. Katona Endre: Bevezetés

az Informatikába Novadat Budapest 1996 5. Dr Kovács Tivadar et al: Mit kell tudni a PC-ről? Computerbooks Budapest 2000. 6. Tímár Lajos et al: Építsünk könnyen és lassan adatmodellt! Veszprémi Egyetemi Kiadó. Veszprém 1997 7. Ulman, Jeffrey D – Widom, Jenifer: Adatbázis-rendszerek Panem-Prentice-Hall Budapest. 1998 Egyéb forrás: 1. Nagy Attila: Az adatbáziskezelés alapjai http://www.kfkihu/~cheminfo/hun/eloado/adatb/ (20020930) 2. Kovács László: Adatbázis rendszerek II Adattárházak http://www-db.iituni-miskolchu/new/ (20020930) 3. Michelberger Pál: Vállalati információs rendszerek jövője http://193.224141245/UjsagInfo/10/Michelbergerhtm (20020930) 4. Dr Siki Zoltán: Adatbáziskezelés és szervezés http://www.brody-ajkasulinethu/ no/sl/al/abk/abkez/adatbhtm (20020930) 5. Surajit Chaudhuri, Umeshwar Dayal: Az adattárház (data warehousing) és az OLAP technológia áttekintése. http://evilkiiifhu/~stefan/jdbc/dombi/ (2002.0930) 6. Microsoft Visual

FoxPro súgója 7. Microsoft Access súgója adatbázisok.doc - 135 - 2003.0909