Történeti kitekintés
Adatkezelési módok
Az adatszerű ismeretkezelési módok fejlődése során három fő állapotot, fejlődési szintet különböztethetünk meg. Az első megoldás szerint az adatok tárolására használt fájl szerkezetét a kezelőprogramban definiáljuk, a kezelőprogram - tudván a fájl szerkezetét - annak megfelelően írja és/vagy olvassa azt. Ha eltérés van, akkor az adatok részben vagy teljesen összekeverednek.
Nézzünk egy Pascal példát:
type
Adat=record
Kulcs: LongInt;
Megnevezes: String[64];
Meret: Real;
end;
var
Egyadat : Adat;
adatfile: file of Adat;
Először definiálunk egy összetett adattípust, rekordfajtát, amelynek három mezője van. Az első mező neve Kulcs, típusa négy bájton ábrázolt, előjel nélküli egész szám. A második mező neve: Megnevezés, típusa szöveges és maximum 64 karakter hosszúságú lehet. (Ez 65 bájton tárolódik, a string típusú változó 0. bájtja tartalmazza a tényleges hosszúságot.) A harmadik mező neve Meret, típusa lebegőpontos, valós szám. A változódeklaráció két változót deklarál, egy Egyadat nevűt, melynek típusa a fent definiált Adat nevű típus, azaz az Egyadat nevű változóban ilyen hárommezős rekordokat lehet elhelyezni. A második változó egy fájlváltozó, egy olyan fájlra lehet vele hivatkozni, amely Adat típusú rekordok egymásutánjából áll.
Ennek hátránya, hogy minden egyes esetben, ha változtatni kell az adatfájl szerkezetét - mondjuk kiderül, hogy nem elegendő a max. 64 karakteres szöveg a megnevezés céljára - nemcsak a programokat kell módosítani - a fájl szerkezetének leírása minden, az adott típusú fájlt kezelő programban szerepel! - hanem külön programot kell írni abból a célból, hogy a már létező fájl szerkezetét módosítsa, az adatokat konvertálja. (A régi szerkezetű fájlból egyenként be kell olvasni a rekordokat, mezőnkénti értékadással át kell tenni a beolvasott értékeket az új szerkezetnek megfelelő típusú rekordba, majd azt ki kell írni egy, a fentihez hasonlóan, de az új szerkezetnek megfelelően definiált fájlba.)
Ha sok efféle feladatunk van, kézenfekvő az a gondolat, miszerint az adatfájlok szerkezetét nem az egyedi kezelőprogramokban kellene szerepeltetni, hanem magukban az adatfájlokban. Azaz csináljuk úgy, hogy minden adatfájl eleje tartalmaz egy fejlécet (header), amely valamilyen, de egységes módon megadja az utána következő adatok szerkezetét. Ekkor egy, általános használatú programmal tudjuk végezni az alapműveleteket (írás, olvasás, szerkezet módosítása) minden ilyen fájlon. Így jutunk el az állománykezelőkhöz (dBASE, Clipper, FoxPro és társaik. Ezen eszközök szerepét a pc-s világban nem szabad lebecsülni: a fejlődés fontos lépcsőfokát jelentik, és még manapság is lehet látni használatban egy-egy, rájuk alapított nyilvántartást.):
DBASE - File header structure (DBASE III)
Offset Size Description
00 byte dBASE vers num 03h=dBASE III w/o .DBT
83h=dBASE III w .DBT
01 byte year of last update
02 byte month of last update
03 byte day of last update
04 dword long int number of data records in file
08 word header structure length
10 word data record length
12 20 bytes version 1.0 reserved data space
32-n 32 bytes ea. field descriptors (see below)
n+1 byte 0dH field terminator.
dBASE III Field Descriptors (FD count varies):
Offset Size Description
00 11 bytes null terminated field name string
11 byte data type, Char/Num/Logical/Date/Memo
12 dword long int field data address, (set in me-
mory)
16 byte field length
17 byte number of decimal places
18 14 bytes version 1.00 reserved data area
Ez komoly előrelépés az absztrakció szintjén, de még mindig hiányérzetünk van. Ebben az esetben az egyes fájlok kezelése az általános és egységes, egy darab kezelőprogrammal történhet, hiszen a különféle tartalmú fájlok szerkezetét minden esetben maga a fájl eleje tartalmazza. Ha azonban ilyen módon próbálnánk meg a relációsra hasonlító adatnyilvántartást csinálni, avval szembesülünk, hogy a táblák közötti kapcsolatok kezelése, továbbá minden korlát, érvényesítés kezelése a programozó "jóindulatára" van bízva. Vagy megcsinálja jól, vagy itt-ott téveszt - ember ő is.
Az absztrakció harmadik szintje az igazi adatbáziskezelés. Annak felismerése, hogy nemcsak az egyes fájlokat kell szerkezetüktől függetlenül egységes programmal kezelni, hanem a táblákat megszemélyesítő fájlok összességét, mégpedig a kapcsolatokkal, korlátokkal, érvényesítésekkel stb. együtt, az előre elkészített definíciónak megfelelően. Sajnos máig nincs olyan adatbáziskezelő, amely maradéktalanul megfelelne ezen elvárásnak.
Az állománykezelés szükségképpen procedurális jellegű, azaz számos lényegi elem - az egyes adatfájlok írásán-olvasásán túl - a kezelőprogramokba beépítetten van jelen. Evvel szemben az igazi adatbáziskezelés definitív, azaz minden, az adatokkal és azok összefüggéseivel, szerkezetével kapcsolatos ismeretet az adatbázis definíciója kell tartalmazzon. Ez olyannyira fontos követelmény, hogy külön neve van: ezt mondja ki az ún. százszázalékos elv.
Lásd még (a teljesség igénye nélkül):
|
