Adatbázis-építés

 

Az adatokból felépített halmazok rendezése, kezelése nemcsak külön tudományág, hanem külön üzletággá is vált az informatikán belül. A piaci szereplők nagy száma, az alkalmazások sokfélesége arra enged következtetni, hogy épülő és bővülő szakmáról van szó, ami igaz is. A cégvezetők vállalati adataik kezelésére – legyen szó akár kereskedelmi, akár termelési folyamatokról – általában kész megoldások közül választanak, illetve vásárolnak, s azokat igazítják a vállalati specialitásokhoz. Vannak viszont, akik az alapoktól kezdve építik és bővítik adatkezelő rendszereiket, remélve, hogy az így kialakított adatbázis egységesebb, testreszabottabb és stabilabb lesz. Mindkét oldalon szép számmal fordulnak elő sikerek, de kudarcok is. Amiben a tanácsadók és a termékeiket kínáló szoftveresek egyetértenek: az alapkérdések és a felhasználási célterületek tisztázása nélkül a rendszer hamar használhatatlanná válik, vagy csak korlátozottan használható.

 

Gondolkodott-e már azon a Tisztelt Olvasó, hogy miért kell hosszú-hosszú ideig sorban állni az okmányirodákban vagy a gépkocsi átíratáskor, vagy azon, hogy miért van többéves lemaradásban némelyik földhivatal? És azon, hogy miért hárítják oly gyakran a számítógépekre a felelősséget? Vagy hogy miért kerül majd' minden informatikai projekt az előzetes tervek többszörösébe? Vagy azon, hogy a lelkes elindulás után miért omlik össze nagyon sok informatikai projekt? Pedig milyen gyors számítógépeink és okos programjaink vannak. Nincs itt valami ellentmondás?

Mintha a legtöbb informatikai nekibuzdulás (projekt) jelmondata ez lenne: "Jól megcsinálni soha nincs idő, de újracsinálni mindig van idő."

Cikkünkben ezekre az ellentmondásokra is igyekszünk rávilágítani, miközben bemutatjuk az adatbázis-építés útját, módját. A továbbiakban gyakran fogunk hivatkozni dr. Halassy Bélára, mert őt tartják az adatbázisok legnagyobb magyar szakértőjének.

Shannon, az információelmélet atyja megpróbálta formalizálni, matematikailag kezelhetővé tenni az "információ"-t. Azt mondta, hogy az információ bizonytalanságot szüntet meg, és értéke (jelentősége) annyi, amennyi bizonytalanságot megszüntet. Például ha valaki lottózik, és azt az "információ"-t hallja, hogy nem nyert semmit, az aligha lepi meg őt. Shannon szerint az információtartalom körülbelül 0,02 (98 százalék az esélye annak, hogy nem nyerünk semmit.) Ha viszont ötösünk lenne, amelynek valószínűsége 1 a 44 millióhoz, az alaposan meglepne bennünket. Tehát az információ értéke Shannon szerint az esemény bekövetkezési valószínűségével fordítottan arányos. Ez annyiban hasonlít a mi definíciónkhoz, hogy az "abszolúte" nagyobb valószínűség bennünk "relatíve" kisebb visszhangot kelt. Például szoktuk is mondani: ez engem egy cseppet sem lep meg, ez várható volt. Ennek ellenére ez a definíció sántít, mert az információ inkább minőségi, mint mennyiségi kategória, és mint ilyet igen nehéz szemléletesen számokba önteni.

Az adatbázisra máris tudunk egy definíciót adni: ismeretek rendezett halmaza. A hangsúly a rendezettségen van. Az adatbázisok két alapvető szinten szemlélhetők: fizikai, illetve fogalmi szinten. A két szint természetesen szoros kapcsolatban van egymással, amit mi sem jellemez jobban, hogy ugyanannak a valaminek mindkét szinten lehet definíciója.

ALAPDEFINÍCIÓK A köznapi értelmezéssel szemben az informatikusok az adat és az információ fogalmát nem egymás szinonimájaként használják. Adat: Értelmezhető, de nem értelmezett ismeret. Például egy halom szám valahol egy számítógép belsejében vagy egy darab papíron. Információ: Értelmezett adat. Ebből következik, hogy az adat objektív, az információ szubjektív, mindenkinek mást jelent, és az ember nélkül értelme sincs.

A fogalmi szint

Egyedek: a való világ egymástól megkülönböztethető objektumai.

Egyedtípus: az objektumok fogalmi tükörképe.

Egyed-előfordulás: az objektumok konkrét értékei.

Az objektumok tulajdonságokkal (attribútumokkal) rendelkeznek.

Tulajdonságtípus: a tulajdonságok fogalmi tükörképe.

Tulajdonság-előfordulás: egy-egy tulajdonság konkrét értéke.

Az egyedek között fennálló viszony a kapcsolat.

Kapcsolattípus: a fenti kapcsolat fogalmi tükörképe.

Kapcsolat-előfordulás: a kapcsolattípus konkrét megjelenése.

Két egyedtípus között akkor van kapcsolat, ha van közös tulajdonságtípusuk.

Kulcs: az a tulajdonságtípus, amely egyértelműen meghatározza a teljes előfordulást, mert minden előfordulásra eltérő értéket vesz fel.

Belátható, hogy több kulcs is létezhet egyszerre, hiszen több tulajdonságtípus is képes egyértelműen azonosítani ugyanazt az előfordulást.

Elsődleges kulcs, azonosító: a lehetséges kulcsok közül kiválasztott, kitüntetett tulajdonságtípus, "a" kulcs.

Egyszerű kulcs: egy tulajdonságtípus alkotja. Egyszerű azonosító például a személyi szám.

Összetett kulcs: ha egy tulajdonságtípus nem elegendő és több tulajdonságtípus szükséges egyszerre az azonosításhoz. Például a katonai behívókon a név, cím, születési év.

Minimális kulcs: amelynek egyetlen részhalmaza sem kulcs.

A matematikusok úgy mondják, hogy bijektív (kölcsönösen egyértelmű) leképezés képezhető az azonosítók és az előfordulások között.

Fontos: a kulcs egy szentség. Egy mindenek felett álló valami. Nem módosítjuk: vagy létrehozzuk, vagy töröljük. Egyszer kell jól kitalálni, és ha csak lehet, nem szabad eltérni tőle soha többé. Követelmények a kulccsal szemben (azon túl, hogy egyértelműnek kell lennie):

• Kényelmi okok és a hibázási lehetőségek csökkentése végett a lehető legrövidebb legyen. Törekedni kell arra, hogy a kulcs minimális kulcs legyen. A relációs adatbázisokban (lásd a következőkben) más nem is lehet, csak minimális kulcs.
• Bővíthető legyen: ha már van 930 vevőnk, akkor nem elegendő 3 jegyű vevőkód. Általában 50 százalék tartalékot szokás hagyni a lehető legnagyobb várható mennyiség felett.
• Az összetettebb azonosítókba (például bankszámlaszám, adószám) ellenőrző számot szokás tenni (például az utolsó számjegy nem hordoz adattartalmat, csupán az előző számjegyek összegének 7-tel osztásakor keletkező maradék).
• Nincs szabály arra, hogy a kulcs tartalmazzon-e betűket, számokat, esetleg mindkettőt. Talán a számok egyértelműbbek. Nincs ékezet-, kisbetű-nagybetű, y-z probléma. Vannak szoftverek, amelyek a csak számokból álló azonosítókat másképpen kezelik, mint a betűket is tartalmazókat. Így ha ilyen rendszerben vegyes azonosítót alkalmazunk, előfordulhat, hogy intervallumkeresésnél kimaradnak bizonyos tételek. Amennyiben az illető szoftverben nincs külön táblázat a karakterek sorrendjére, akkor a program az ASCII kódsorrend alapján fog rendezni. Ebben az "e" és "é", "a" és "á" karakterek nem egymás után következnek.

Leíró tulajdonságtípus: ami nem elsődleges kulcs.

Adatmodell: az adatok szervezésének logikai képe.

Napjainkig három alapvető adatmodelltípus alakult ki, amelyek történeti és fejlettségi sorrendben a következők: a hierarchikus, a hálós és a relációs. Hogy melyiküket mi jellemzi, azt a következőkben taglaljuk.

Az adatbázis pontos definíciója ezek után: egyed, tulajdonság és kapcsolat előfordulások adatmodell szerint szervezett együttese (dr. Halassy Béla).

A NYELVTUDÁS NYILVÁNTARTÁSA A következő példa is dr. Halassy Bélától származik. Tegyük fel, hogy az a feladatunk, hogy készítsünk egy nyilvántartást arról, hogy a cégünknél ki milyen nyelven tud beszélni. Na már most mit tesz az, aki nem foglalkozott adatbázis-tervezéssel? Készít egy személyi törzset. Egy rekord a következőképpen nézne ki: valamilyen azonosító, név, cím, munkahely stb. Azután kiegészíti a beszélt nyelvek felsorolásával. Ez arra nagyon jó, hogy megadja, hogy az illető milyen nyelven beszél. És mit teszünk, ha beesik egy vendég Bergengóciából, és meg akarjuk tudni, hogy ki beszél bergengócul? Szekvenciálisan keresve megtaláljuk az állományunkban. A keresést persze annyiszor el kell indítanunk, ahány mezőben nyelvazonosítók lehetnek, mert a bergengóc nyelvet hol az első helyre, hol a második helyre stb. tettük. Igazándiból azt sem tudjuk, hogy mikor kell abbahagynunk a keresést, mert nem tudjuk, hogy mennyi a beszélt nyelvek maximális száma. Hallottam olyan perverz alakokról, akik 10-15 nyelven is beszélnek. Íme egy nagy gondossággal, sok energiával és pénzzel létrehozott adatbázis, aminek semmi értelme. Ha viszont a nyelvekre készítünk azonosítókat, és a neveket ezek mellé írjuk fel, sokkal célravezetőbb adatbázist kapunk: gombnyomásra megkapjuk, hogy kiket lehet felkérni tolmácsolásra.

Definíciók a fizikai szinten

Mező: egybetartozó karaktersorból álló adat, amely értelemvesztés nélkül tovább már nem bontható, viszont önállóan is használható: mozgatható, csatolható, egymáshoz rendelhető.

A mezőnévnek a fogalmi szinten a tulajdonságtípus, a mezőtartalomnak a tulajdonság-előfordulás felel meg.

Rekord: mezők egy csoportja, amelyeket a valóság leírásához egymáshoz rendeltünk.

Két rekord akkor és csak akkor rendelhető egyértelműen egymáshoz, ha az egyik rekordban a másik rekord azonosítója megtalálható.

Fájl: Azonos szerkezetű rekordok egy közös névvel illetett gyűjteménye.

Manapság sokan, fellengzősen már egyetlen fájlt is adatbázisnak neveznek. A hagyományoknál maradva:

Adatbázis (fizikai szinten): legalább kettő, egymással jól definiált kapcsolatban levő fájl.

Törzsállomány: a valóság valamely objektumát viszonylag állandó módon jellemző rekordok gyűjteménye egy fájlban. Ilyen például egy személyi nyilvántartás. Az ember neve aránylag ritkán változik, bár néha megtörténhet. A címe esetleg gyakrabban, de a születési helye és ideje egyáltalán nem szokott változni. Ezeknek az adatoknak helyük van egy ilyen törzsállományban. De az életkort, gyermekeknél pedig a testmagasságot értelmetlen itt tárolni.

Adatbank: Strukturált szöveges (nem rekord szervezésű) állományok visszakeresésre alkalmas elrendezése.

Napjainkra egyre csökken a távolság a hagyományos adatfájl és az adatbank között (ha úgy vesszük, egy törzsállomány sem más, mint egy végletekig strukturált szövegfájl). A keresés eszközei sem állnak messze egymástól: egy szövegállományban kulcsszavak alapján történő, a strukturáltság fokától függően szekvenciális vagy indexes összefüggés-keresést nevezzük adatbányászatnak.

Adatbázismodellek

Az előző fejezetben az adatbázis pontos definíciója miatt említettük az adatmodelltípusokat. Részletezésükhöz szükséges még az adatkapcsolatokról is néhány szót szólni. Az adatkapcsolatok lehetnek egy-egy (1-1), egy-sok (1-N), sok-sok (N-M) típusúak. Az első eset a kulcs-előfordulás kapcsolat. A második anya-gyerek jellegű: egy anyának több gyereke lehet, de egy gyereknek csak egy anyja van. A harmadik esetre példa a szerzők és könyvek kapcsolata.

Hierarchikus adatmodell: Történetileg a legelső és ma már leginkább túlhaladott típus. A hierarchikus adatmodellt az 1-N típusú adatkapcsolatok jellemzik. A struktúrája fa gráf. Hátránya, hogy N-M típusú kapcsolatokat nem tud kezelni, továbbá az adatok elérése csak felülről lefelé lehetséges, a hierarchiának megfelelően.

Hálós adatmodell: A hálós adatbázisban az egyes elemek egyenrangúak, így a visszalépésre is lehetőség van, de a kapcsolatok itt is előre definiáltak. Struktúrája (nem feltétlenül fa) gráf. Képes kezelni az N-M típusú kapcsolatokat is.

Relációs adatmodell: A relációs adatbázisban az adatok közötti kapcsolatok (az úgynevezett relációk) nem előre definiáltak, így bármikor tetszés szerint felépíthetők és lebonthatók. A relációs adatbázist kezelő eszközök az adatokat táblákban (tulajdonképpen táblázatokban) tárolják, amelyeket akár fájloknak is felfoghatnánk. A bennük levő sorok pedig speciális rekordok. Az oszlopok attribútumok, amelyek tulajdonságtípusok, és fizikai szinten a mezőnévhez hasonlítanak.

Adatbázishibák

Egy adatbázisterv számtalan ok miatt lehet hibás. Az egyik leglényegesebb ok a redundancia. Ekkor az adatbázisban ugyanazon tulajdonságérték többször, több helyen is előfordul. Ez lehet homonima, amikor a többszöröződés "csak" látszólagos, ugyanis ugyanazon név alatt eltérő tartalom van. Lehet továbbá szinonima, ami rejtett redundancia, mert eltérő nevek alatt azonos tartalom lapul.

Maga az adatbázis (a tervezés hibáin túl) a következők miatt lehet hibás:

• Inkonzisztencia. Konzisztens egy adatbázis, ha ellentmondásmentes (önmagával).
• Integritásprobléma. Integritás alatt az adatbázis teljességét értjük. Ha az adatbázis a valóságtól eltérő adatokat tartalmaz, akkor az integritása sérült. (De ettől még lehet konzisztens.) Idesoroljuk azokat a problémákat is, amikor a belső láncolás, adatkapcsolatok stb. sérültek. Például egy cím nem létező adatra mutat.

Hibajavítás

A redundancia az adatbázisokban elvi hiba, amelynek kiküszöbölése több ok miatt fontos. A kisebbik probléma az, hogy felesleges munkát okoz a többszörös bevitel, fogyasztja a tárhelyet a többszörös tárolás. A nagyobbik probléma az, hogy olyan még nem volt és nem is lesz, hogy két külön kezelt, eredetileg azonos tartalmú adathalmaz sokáig egyforma legyen. Csak idő kérdése, hogy "elmásszanak" egymástól. "Tudják, amióta két órám van, sohasem tudom, hogy mennyi a pontos idő."

Szerencsére a redundancia kiküszöbölésére van eszköz: a normalizálás. Arra való, hogy kiküszöbölje a tervből a redundanciákat és csökkentse az adatbázishibák előfordulásának lehetőségét: halmazelméleti matematikai módszerekkel átformálható vele az adatbázisterv.

Az adatbázisoknak öt normalizált szintje lehetséges, plusz a nulladik, a kiindulási normalizálatlan állapot. Ezen a szinten van az adatbázis, ha tartalmaz olyan tulajdonságot, amelyik az azonosítójától funkcionálisan független. (Funkcionális függőség: ha egy vagy több tulajdonságtípusból bizonyos tulajdonságtípusok egyértelműen következnek.)

A fentiek azt sugallják, hogy aki nem ismeri a normalizálás módszerét, az nem is képes tisztességes adatbázist tervezni. Ez szerencsére nincs így. Az átláthatóbb feladatoknál a kicsit is gyakorlott, "józan paraszti ésszel megáldott" ember általában rögtön a harmadik normálformában fogalmazza meg a feladatot anélkül, hogy tudna bármit is a normalizálásról. Ez általában elegendő is. Tehát nem kell lemondani arról, hogy nyilvántartást készítsünk otthon a videókazettáinkról csak azért, mert nem ismerjük a normalizálás módszerét. Egy jó tanács: készítsünk törzsállományt mindenre, amire csak lehet. Akkor már nem lehet nagy baj.

Az előbb említett nyelvtudás-nyilvántartó adatbázis nulladik normálformában van, mert az azonosítótól (mondjuk törzsszámtól) független tulajdonságokat tartalmaz (nyelvtudás), mert ugyanahhoz az azonosítóhoz több különböző nyelvtudás tartozhat. Ha csak azért készítettünk adatbázist, hogy tolmácsot találjunk a beeső vendégek mellé, akkor a problémafelvetés mögé rögtönzött megoldás is megfelelő. De megjegyezzük, hogy még ez is nulladik normálformájú! Továbbá felveti az adatláncolás problémáját, ami már a programozástechnika körébe tartozik. Ugyanis nem tudjuk előre, hogy hány nevet kell majd az egyes nyelvek mögé írni. Adatláncolás használata nélkül két lehetőségünk van: ha mindegyikhez lefoglalunk anynyi helyet, ahányan csak dolgoznak a cégnél, akkor pazaroljuk a tárhelyet. Ha kevesebbet foglalunk le, soha nem alhatunk nyugodtan amiatt, hogy mikor nőjük ki az adatbázisunkat egy nyelvtanfolyamkampány után.

Ha viszont igényesebb nyilvántartásra törekszünk, mert például a nyelvtudás (vagy a vizsga, ami sokszor nem ugyanaz) szintjét is folyamatosan tudni akarjuk, vagy nem akarunk az adatláncolással bíbelődni, akkor a törzsállomány tanácsot alkalmazzuk:

1. Készítünk egy személyi törzsállományt.
2. Készítünk egy nyelvi törzsállományt.
3. Készítünk egy állományt, amelyben egymáshoz rendeljük a nyelveket és a személyeket, összetett kulccsal: nyelv(kód)+törzsszám. Így nyelv(kód)-ra keresve megkapjuk a potenciális tolmácsokat, nem is beszélve az egyéb járulékos adatok tárolási lehetőségeiről (tudásszint, vizsga dátuma, típusa stb.) Mellesleg a személyi törzsállomány önmagában is sok mindenre jó (lakcím, telefonszám-keresés stb.).

Műveletek az adatbázisokban

Egy-egy adatbázison négy alapvető műveletet lehet és kell tudni végrehajtani: új felvitel; módosítás; törlés; listázás (keresés, megjelenítés, kigyűjtés).

Mindegyik művelet lényeges algoritmusa a keresés. Új felvitelnél például meg kell tudnunk mondani, hogy van-e már ilyen azonosító a rendszerben. Ha van, nem szabad megengedni a felvitelt. (Azt mondják, a számítógépek idejük legnagyobb részét sorba rendezéssel és kereséssel töltik.) A keresés lényege: egy általunk ismert tulajdonságtípushoz (vagy azok csoportjához) keressük az előfordulás többi jellemzőjét. Ez alapjában véve kétféleképpen végezhető:

• Ha ismerjük az azonosítót, akkor szerencsénk van, és kereshetünk index alapján. Az index tulajdonképpen egy tartalomjegyzék.
• Ha csak leíró adatot ismerünk, akkor nincs más hátra, mint szekvenciálisan keresni: egyenként mindet megnézzük.

A kettő közül nyilván az index alapján való keresés a gyorsabb, de nem elsősorban azért, mert a tartalomjegyzék rövidebb, mint a könyv. A lényegesebb ok az, hogy az indexállományban az azonosítók szerepelnek, mégpedig sorba rendezve, és rajtuk kívül csak egy hivatkozás szerepel: a teljes rekord fizikai címe. A lényeg: az indexállományban binárisan tudunk keresni. Hogy az mi? Ahogyan a matematikus oroszlánt fog. Megfelezi a sivatagot, amelyik felében van az oroszlán, azt a felét is megfelezi stb. Lássunk egy példát. Sorba raktuk a magyar kártyánkat, bár néhány lap hiányzik. Egy lap csak most került elő, és keressük a helyét. Szekvenciális kereséssel átlag 16 vizsgálat után találjuk meg a helyét. Binárisan keresve először megfelezzük a paklit, megnézzük, ott mi van. Ha a lapunk ennél nagyobb, akkor a nagyobb lapokat tartalmazó felet is megfelezzük stb. Így maximálisan log2(32) = 5 összehasonlítás után megtaláljuk a keresett helyet. 16 vagy 5 az majdnem mindegy. Viszont 1000 lapnál ez a számpár 500:10, 10 000-nél 5000:14.

A szekvenciális keresés igazán a számítógépeknek való feladat. A megadott és keresendő adatot vagy annak esetleg csak egy töredékét, az úgynevezett maszkot a számítógép rápróbálja egyenként az összes adatra, és amelyikre passzol, azt számunkra valamilyen módon megjeleníti.

A következő ábrázolástechnikát Bachman-diagramnak nevezik, és rendkívül egyszerű, egyben szemléletes eszköz az adatbázisok és azok kapcsolatainak bemutatására. Többféle konvenció létezik a használatára. Az alábbi megvalósítás előnye az, hogy nehezebb eltéveszteni, mert azonosító azonosítóra mutat. Tegyük fel, hogy egy kis boltunk van, több raktárral. Több árut kínálunk, ezek több raktárban is lehetnek egyidejűleg. Az adatmodell a következő:

 

A cikktörzsállomány azonosítója a cikkszám, a raktárak törzsállományáé a raktárkód. A készletadatok egy származtatott állomány, ahol az azonosító összetett kulcs: a cikkszám és a raktárkód együttesen adja meg a készletet. Ez az állomány hivatkozik a cikktörzsre és a raktárak törzsére az ottani azonosítókon keresztül. A cikktörzs tartalmazza az áruk leíró adatait, pl. megnevezés, minőség, mértékegység stb. A raktárak törzse jóval kevesebb adatot tartalmaz: megnevezés, cím (elhelyezkedés), esetleg tárolókapacitás. A készletadatok lekérdezésénél a következő kérdésekre tudunk így válaszolni:

• egy cikkszám készlete egy raktárban,
• egy cikkszám készlete az összes raktárban,
• egy raktár készlete összesen,
• minden készlet összesen.

A raktártörzsbe az aktuális készlet mellé feljegyezhetjük az illető áru pontos helyét (polcsor, polcszám). (A raktármozgásokat most ne keverjük bele a példába, mert az messzire vezetne.)

Az adatbázisokat kezelő szoftverek csoportosítása nyilván igazodik az adatmodelltípusokhoz. Ez elvileg igaz, gyakorlatilag azonban sok, csupán hálós adatkezelő szoftverre mondja a készítője, hogy relációs, mert az jobban hangzik.

NYELVHIERARCHIA Érdekes, hogy az emberi nyelv vagy maga az ember nem adatbázis szervezésű. Vagy magasabb szinten szervezett, mint holmi adatbázis. Valószínűleg így van, mert különben nem lenne képes normalizált adatbázisokat létrehozni. Chomsky úr, aki egyszerre volt nyelvész és matematikus, hierarchizálta a nyelveket (így hívják: Chomsky-féle nyelvhierarchia). Bebizonyította, hogy a természetes nyelvek sohasem lesznek teljes mértékben formalizálhatók. (Pl.: "Láttam az oroszlánt mentében.") Ezért kell létrehozni a programnyelveket, amelyek elsődleges célja, hogy egyértelműek legyenek. A természetes nyelven íródott adatbázisokat (jobban mondva adatbankokat) a bennük levő homonimák és szinonimák miatt sohasem tudjuk majd például a relációs adatbázisok elméletének kristálytiszta matematikai eszközeivel kezelni. Mindig is lesz "favágó módszer", a "balról jobbra egyesével". De talán jobb is így. Miért is ölnénk ki a nyelvekből a sokszor oly jóleső kétértelmű célzásokat (homonima), vagy a beszédünket változatossá tevő szinonimákat?

Adatbázisok használat közben

Az adatbázis (és egyéb) szoftverekkel kapcsolatban meghatározhatjuk, hogy mi a rendeltetésük és még mire alkalmasak.

A szoftver kiválasztásának legfontosabb szempontja, hogy mire akarjuk használni. Az Excel nagyon jó eszköz adatok kezelésére, de nem adatbázis-kezelő. Az Access viszont már az. A mai RDBMS-ek (relációs adatbázis-kezelő rendszerek), a negyedik generációs programnyelvek (4GL) és az úgynevezett "varázslók" (wizard) igen alkalmasak arra, hogy nagyon gyorsan, kis ráfordítással jó rendszereket vagy nagy sületlenségeket készítsünk. Szinte sugallják, hogy "Te csak ne törődj semmivel, ne gondolkozz, majd én megoldok mindent". Ne dőljünk be nekik! Ezek nagyon jó eszközök, de csak értő kezekben.

Az előző fejezetben azt taglaltuk, hogy feltétlenül kerülni kell a redundáns adattárolást. Sajnos a való élet ezt az elméleti tételt (is) keresztülhúzza. Ennek két oka van. Az első a már említett Shannon úr egyik híres tétele, mely szerint az adat biztonsága csak egyetlen módon növelhető: redundanciával. Többször le kell tárolnunk, meg kell ismételnünk a továbbítást stb.

A második ok egy kicsit bonyolultabb. A számítógépek világában két alapvető "erőforrás" létezik: a tárhely és az idő. Ezek hellyel-közzel egymásba konvertálhatók. Valamikor a kis és nagy számítógépeket ez különböztette meg egymástól: a kis gép használatakor a tárhely kicsi volt, de sokáig futhatott a program. A nagy gépeknél nagy volt a tárhely, de egy-egy felhasználóra kevés idő jutott. Ma már nehéz eldönteni, hogy mi a kicsi és mi a nagy számítógép. De a két erőforrás egymásba konvertálhatósága ma is igaz. Ha kevés hely van, akkor inkább mindig kiszámolom, de ha az idő fontosabb, akkor inkább mindig letárolom.

Vegyük például a raktárkészleteket. Tanácsos-e például minden raktármozgás mellé letárolni az aktuális készletet? Elvileg felesleges, mert a raktármozgások újra lejátszásával az aktuális készlet mindig előállítható (a lejátszás ideje erősen függ attól, hogy mikor volt az idők kezdete). De ha letárolom, akkor sokkal gyorsabban tudok arra a kérdésre válaszolni, hogy mennyi volt a készlet 27 nappal ezelőtt. Nem is beszélve arról, hogy ha valami hiba történt menet közben, mennyivel egyszerűbb a hibát kideríteni.

Konklúzió: lehet duplán tárolni, de mindig biztosítani kell a kényszerkapcsolatot. Vagyis a rendszerbe beépített módon kell gondoskodni az adategyezőségről.

VEVŐKÓD Egy vállalatnál a cikkszámba beletették a vevőkódot. Ez első körben a fentiek ismeretében badarságnak tűnik. Részletesebben megvizsgálva azonban érdekes dolgok derülnek ki. A cikkszám egyik karaktere azonosítja a vevőt. Erre azért volt szükség (szólt a magyarázat), mert ez a vevő olyan speciális technológiával előállított terméket kért, amilyet (eddig) senki más. Tehát itt tulajdonképpen nem a vevőt azonosították, hanem a technológiát, ami még éppenséggel belefér a cikkszám-azonosító definíciójába. A baj csak akkor kezdődött, amikor a következő vevőre való hivatkozást is beletették egy egyébként szabványos termék azonosítójába. Arra a kérdésre, hogy mi lesz akkor, ha tíz vevőnél több lesz, vagy arra, hogy mit tesznek akkor, ha két különböző vevő azonos terméket kér, nemigen tudtak válaszolni.

Adatbázisok az interneten

Az internet ma már mindenki előtt ismert. Olyan, mint a rádió-, vagy tv-adók rendszere a föld kerekén. Naponta jelennek meg újak, jószerével azt sugároznak, amit akarnak, és aki böngészik, "szörföl", azt és annyi ideig nézi, amenynyi ideig akarja. A hasonlat annyiban sántít, hogy az internet honlapjai statikusabbak, mint egy film az HBO-n, és jobbára csak szaporodik a tartalmuk, s lassabban cserélődik. Találunk hasznos és haszontalan, sőt káros, érdekes és érdektelen honlapokat.

Az intranet egy vállalat, cég, intézmény internete befelé, azaz internetes eszközökkel, stílusban készült számítógépes faliújság az alkalmazottak számára.

Az extranetet pedig mintegy kifordított intranetként szemlélhetjük: a vállalat a számára fontos, kiváltságos helyzetben levő partnerei előtt megnyitja az intranetjét.

A fenti netek nagyon alkalmasak arra, hogy rosszul definiált, rosszul strukturálható, leírás jellegű adatokat (is) hozzáférhetővé tegyenek (természetesen csak a kiválasztottaknak, de ez már az adatvédelem tárgyköre).

Ezek az adatbázisok három nagy csoportra oszthatók:

• Az egyik a klasszikus adatbázistípus, amelyről az előző fejezet szólt. Ilyen például egy nyilvános könyvtár katalógusa. Ebben kereshetünk szerző, cím, tárgyszó, kiadó stb. alapján. Ezek az előző fejezet szavait használva tulajdonságtípusok. Vagy például egy internetes telefonkönyv. Itt, ha tudunk egy azonosítót (például a telefonszám azonosítóként működik), akkor megkönnyítjük a számítógép dolgát. De a keresés módszere kifelé nem látszik. Mindössze annyi, hogy az indexes keresés általában gyorsabb.
• A második a leíró jellegű adatbázis, amelyet az előző fejezetben adatbanknak hívtunk. (Maga az internet is leginkább ehhez hasonlítható.) Ezek jobbára szövegszerű állományok, amelyekben kereshetünk kulcsszavakat, de itt már ügyelnünk kell. Ugyanis a keresőprogram a keresőfogalom formájára keres, nem ismeri fel a homonimákat és nem keresi ki az összes szinonimát.
• A harmadik az előző kettő keveréke. Ilyenek az apróhirdetések, a menetrendek, az álláshirdetések stb. Egyaránt magukon viselik mindkét előző típus jegyeit. A kezelésük eszközei is ugyanígy vegyesek.

Fontos: az adatbázis nem a fizikailag együtt tárolt adatok halmaza, amelyből a közöttük lévő kapcsolatok (vagy azok lehetőségeinek) hiánya miatt érdemi információ nem nyerhető. "Egy rakás tégla még nem bazilika."

LASSÚ GÉP Örök panasz a felhasználók részéről, hogy "lassú a gép". Persze. Mindenkinek kevés a fizetése és gyenge az autója. Viszont egy rossz rendezési algoritmussal a világ leggyorsabb gépe is elvérzik. Találkoztunk egy magát termelésirányítási programnak nevező szoftverrel, amelynek egy olyan lépése, amelyet naponta kellett volna futtatni, két hétig (!) futott. Megvizsgálva közelebbről a programot kiderült, hogy egy rendezésről van szó, amely a lehető legprimitívebb, úgynevezett buborék algoritmust használta. (Ennek lényege, hogy a kisebb elemek páronkénti összehasonlítás után felfelé szállnak a láncban, mint a buborék.) Átírva egy hatékonyabb rendezésre, a program egy-két perc alatt lefutott. Tekintsük Bahvalov szép példáját arra, hogy a többet ésszel, mint erővel elv mennyire érvényesül az informatikában is. Tegyük fel, az a feladatunk, hogy egy százszor százas determináns értékét kell kiszámítanunk. Talán emlékszik a T. olvasó a definíció szerinti kifejtésre: az egyes elemek adjungált aldeterminánsaikkal vett szorzatainak összege. A lényeg, hogy ehhez 100x100! (száz faktoriális) nagyságrendű műveletet kell elvégeznünk (100! = 1x2x3x....99x100). De így csak a bolond fog neki, helyette a sor-oszlop eliminációk módszerét használjuk. (Addig vonogatunk ki egymásból sorokat és oszlopokat, amíg csak a főátlóban maradnak elemek.) Ez sem egyszerű, de akár még kézzel is belátható időn belül elvégezhető. Most tekintsük a 100! műveletet. Ez egyáltalán nem kevés: 100!=10157,9.... Tegyük fel, hogy olyan számítógépünk van, amelyiknek egy tárolóegysége mindössze 1 atomnyi méretű (amely hordozni képes a 0 vagy 1 adatot), és az átviteli sebessége a fény sebességével egyenlő. Legyen jó nagy a számítógépünk: használjuk fel hozzá a Naprendszer minden atomját. Pillanatnyilag ennél nagyobb és gyorsabb gépet nehéz elképzelni. Nos, ennek a szuper számítógépnek a százszor százas determináns definíció szerinti kifejtéséhez a világegyetem várható élettartama sem lenne elegendő idő.

A hardver

Az alábbiakban a hardverről szólunk, pontosabban arról, hogy az mennyire nem fontos. "Nem a technika teszi az informatikát" (dr. Halassy Béla). Ez vonatkozik a szoftverre és a hardverre egyaránt. Manapság különösen igaz ez, hiszen minden adatbázis-kezelő rendszer hardver- és operációsrendszer-függetlenségre törekszik.

Tudomásul kell venni, hogy a számítógép nem mindenható. Gondolkodni sohasem fog helyettünk, legfeljebb egyre ügyesebben imitálja. Az egyik megmosolyogtató példa, amikor a számítógépre bízták, hogy állapítsa meg, az órák közül melyik a legpontosabb. A nyertes a nem működő óra lett. Igen, mert az naponta kétszer pontos.

A másik ilyen példa egy informatikai tárgyú dolgozatból származik. A szövegszerkesztő program helyesírás-ellenőrzője a token-ring hálózattopológia nevet kijavította tökén-ringre.

A hardver csak egy eszköz, és az a jó, ha nem vesszük észre, hogy létezik. Ahogyan Antoine de Saint-Exupéry fogalmazta meg egyik regényében (igaz, "csak" a repülőgépekkel kapcsolatban): "Nem akkor érjük el a tökéletességet, amikor már nem lesz mit hozzátenni, hanem ha már nem lesz mit elvenni belőle."

Adatbázis-építés

Építsünk fel egy adatbázist, majd használjuk. Kísérjük figyelemmel a folyamatot a legelső lépésektől. A most következő példa egy termelésirányítási rendszer sémáját követi, azon belül is az úgynevezett műszaki adatbázist építjük fel.

Adatbázis-kezelés konyhanyelven: ebédet főzünk. Tegyük fel, hogy egy nagyon egyszerű vendéglőt üzemeltetünk. Mindössze háromféle ételt kínálunk: krumplilevest, rántott szeletet és rósejbnit.

Először megegyezünk a mértékegységekben.

Mértékegység	Kód
Tányér	01
Darab	02
Gramm	03
Kilogramm	04
Liter	05

A cikktörzs a mértékegységtörzsre hivatkozik. Építsük fel a cikktörzset:

Cikkszám
Cikktörzs
Mértékegységkód

Mértékegységkód
Mértékegységtörzs

Cikkszám	Megnevezés	Mértékegységkód
Alapanyagok:
001	víz	05
002	fűszerek	03
003	só	03
004	olaj	05
005	liszt	03
006	tojás	02
007	burgonya	04
008	prézli	03
009	zöldség	03
010	hús	04

Félkész termékek:
301	rántás	03
302	panírozott hús	02
303	tisztított burgonya	04
304	előkészített belevalók	03

Késztermékek:
501	burgonyaleves	01
502	rántott szelet	02
503	sült burgonya	03

A cikkszám az anyagféleségek azonosítója. A könnyebb eligazodás kedvéért a cikkszámunk háromjegyű, bár lehetne ugyanúgy kétjegyű, mint a mértékegységkód. Csak minket zavarna, a számítógépet nem. Még egy konvenció: a cikkszámunkat "beszélővé" tettük azzal, hogy az első karaktere elárulja, hogy alapanyagról, félkész termékről stb. van-e szó.

Késztermék: Olyan anyagfajta, amely valamennyi megmunkálási folyamaton átment az adott műszaki dokumentáció szerint.

Félkész termék: Olyan közbülső termék, amelyen már valamilyen saját technológiai folyamat befejeződött. Önálló cikkszámmal rendelkezik.

Termék: Félkész és késztermék gyűjtőneve.

Alapanyag: Olyan vásárolt anyag, amely beépül a termékekbe, megadva azok lényeges tulajdonságait és azoknak meghatározó elemét alkotja.

Rezsianyag: Olyan anyag, amelynek felhasználására a gyártóegység üzemelésének fenntartása érdekében kerül sor, de a termékbe való beépülése nem jellemző.

Megjegyzendő, hogy léteznek anyagféleségek, amelyek rezsianyagok és alapanyagok is lehetnek.

Anyag: Alapanyag és rezsianyag gyűjtőneve.

Cikktörzs: Anyagok és termékek jellemző paramétereinek gyűjteménye. Azonosító a cikkszám.

Költséghely: A termelőegység azon önállóan kezelt egysége, amelynek felmerült költségeit, gazdálkodását külön figyeljük.

Konstrukció: A termékek műszaki adatait, felépítését, szerkezetét meghatározó dokumentáció.

Darabjegyzék: Adatállomány, amely megmutatja, hogy bármely termék egységnyi mennyiségének előállításához a konstrukció szerint milyen és mennyi alapanyag, illetve félkész termék szükséges.

Műveleti terv: Adatállomány, amely megmutatja, hogy az adott termék milyen technológiai műveletek során, mely berendezések igénybevételével készül, illetve egységnyi mennyiségének előállításához az adott berendezésen mennyi idő, mekkora létszám és mennyi közvetlen bér használható fel előírás szerint.

Vegyük fel a költséghelytörzset. Ez igen egyszerű lesz:

Ktgh. kód	Megnevezés
eb	ebédlő
ko	konyha
el	előkészítő
ra	raktár

A következő lépés a darabjegyzék felépítése. A darabjegyzék viszonya az eddigi állományainkhoz:

Szülőcikkszám		Gyerekcikkszám
Darabjegyzék
Cikkszám	Cikkszám		Ktgh. kód

Cikkszám

Cikktörzs

Mértékegységkód

Mértékegységkód		Költséghelykód
Mértékegységtörzs		Költséghelytörzs

Ugyanez a számítógép nyelvén:

Szülő- cikk- szám	Gyerek- cikksz.	Nettó  beépülő  menny.	Hulladék- százalék	Ktgh. kód
501	303	0,1	0,0	ko
501	301	0,01	5,0	ko
501	304	100,0	0,0	ko
501	003	5,0	0,0	ko
501	001	0,5	0,0	ko
303	007	1,2	20,0	el
301	004	0,05	0,01	ko
301	005	0,30	0,01	ko
304	009	1,1	20,0	el
304	002	0,1	0,0	ko
502	302	1,0	0,0	ko
502	004	0,06	10,0	ko
302	010	0,2	0,0	ko
302	008	20,0	10,0	ko
302	005	10,0	10,0	ko
302	003	5,0	0,0	ko
302	006	1,0	10,0	ko
503	303	0,25	5,0	ko

A nettó beépülő mennyiség mindig a közvetlen szülőcikkszám egységnyi mennyiségére vonatkozik és nem a legfelső szintű késztermékére.

Bár a 303-007 cikkszámpáros az eredeti fa gráfban kétszer is szerepel, a számítógépben nem kell kétszer tárolnunk.

A darabjegyzékben, mint látható, a szülő-gyerek cikkszám összetett kulcs az azonosító.

A selejtszázalék és a hulladékszázalék két teljesen különböző fogalom. A különbség közöttük ugyanaz, mint az odaégett rántotta és a tojáshéj között. A selejtszázalék a szülőcikkre jellemző statisztikai adat, amely azt mondja meg, hogy körülbelül hány százalék szokott rosszul sikerülni. Így ennek a cikktörzsben van a helye. A hulladékszázalék a technológiai folyamat következménye, egy adott szülő-gyerek cikkszám párosra jellemző adat így a darabjegyzékbe kerül.

A darabjegyzék a legfontosabb a műszaki adatbázisban. Segítségével értékes információkhoz juthatunk, például egy menü bruttó anyagszükségletéhez.

Egészítsük ki tehát a cikktörzsünket selejtszázalék adattal (csak a termékeknek van ilyen):

Cikkszám	Selejtszázalék
501	0,1
502	0,1
503	1,0
301	1,0
302	0,0
303	0,0
304	0,0

Megjegyezzük, hogy a termelésprogramozásban a nettó és a bruttó szükségletet két eltérő értelemben használják: az egyik a most említett, amikor a nettó a ténylegesen a termékbe épülő, a bruttó a felhasználásra kerülő mennyiség. Beszerezni a bruttót kell, vámvisszatérítés viszont csak a nettóra jár.

Másik értelmezés: a gyártáshoz felhasználandó mennyiség a bruttó, a raktáron nem levő, tehát beszerzendő mennyiség a nettó. Mi az első értelmezésnél maradunk.

Esetünkben ez a következő:

Cikk- szám	Meg- nevezés	Mérték- egységkód	Bruttó mennyiség
001	víz	05	0,5005
002	fűszerek	03	10,01
003	só	03	0,5005
004	olaj	05	0,0666
005	liszt	03	11,0142
006	tojás	02	0,2628
007	burgonya	04	0,7724
008	prézli	03	22,022
009	zöldség	03	132,132
010	hús	04	0,2002

A menet közben előálló termékek mennyiségei:

Cikk- szám	Meg- nevezés	Mérték- egységkód	Bruttó mennyiség
301	rántás	03	0,0105
302	panírozott hús	02	1,001
303	tisztított burgonya	04	0,5364
304	előkészített belevalók	03	100,1
501	burgonyaleves	01	1,0
502	rántott szelet	02	1,0
503	sült burgonya	03	300,0

Ha áraink is lennének az alapanyagokra, akkor egy kis szorzással már meg is kapnánk az önköltség talán legfontosabb összetevőjét, az anyagköltséget. De az árral, az árképzéssel (csúszó átlagár, standard ár, FIFO stb.) most nem foglalkozunk, mert túlságosan messzire vezetne. Annyit azért meg kell említeni: annak ellenére, hogy (sajnos) egy dinamikusan változó mennyiség, mégis érdemes a pillanatnyi aktuális árat visszatenni a cikktörzsbe, csupán a gyors hozzáférhetőség érdekében – még ha ez némiképp ellentmond is annak, amit az elején a törzsállományokról állítottunk.

Hozzuk létre a gépcsoporttörzsünket (sokan homogén gépcsoport, munkahelycsoport, munkahely néven ismerik). Egy munkahelyen többféle művelet végezhető, és egy költséghelyhez több munkahely tartozik.

Munkahely- csoportkód (Mhcsk)	Megnevezés	Költség- helykód
01	Gázfőző 1.	ko
02	Gázfőző 2.	ko
03	Asztal	ko
04	Asztal	el

Most építsük fel a műveleti tervet, a műszaki adatbázis második legfontosabb állományát (lásd külön táblázat!).

Az átfidő az átfutási idő, azaz amennyit a termék ezen a munkahelyen ebben a műveletben eltölt. A midráf a munkaidő-ráfordítás, azaz amennyi munkaidőt kell itt ráfordítani. Szemléletes tartalommal tudjuk megtölteni e két fogalmat: midráf/átfidő = létszámigény.

A bértényező tulajdonképpen egy nettó, lecsupaszított órabér. Úgy is hívják: nettó norma szerinti bér. A bértényező x midráf = bérigény. A géptényező a gép "órabére", az energiafelhasználásból, karbantartásigényből viszszaszámolt, becsült érték. A géptényező x átfidő, továbbá a bérigény az anyagköltség utáni legfontosabb önköltség összetevő (hárman együtt általában ki is teszik az önköltség jó 90 százalékát).

Szeretnénk egy ellentmondásra felhívni a figyelmet. Látszólag feleslegesen tettük bele a darabjegyzékbe a költséghelyet, ugyanis a cikkszámon keresztül a műveleti tervből ez kiolvasható. Ez egyike azon redundanciáknak, amelyeket felszokás vállalni.

Ezzel a struktúrával a következő információkhoz juthatunk:

• Önköltség (jó közelítéssel). Ezt hívják előkalkulációnak.
• Egy menü anyagszükséglete, ez a beszerzés számára információ.
• Egy menü elkészítéséhez szükséges normaidő.
• A munkahelyek (és emberek) leterheltsége, kapacitáskihasználtsága (ha viszünk fel kapacitásadatokat a munkahelyekhez).
• Éves gyártási terv alapján létszámigény.

Folytathatnánk az adatbázis felépítését vevő, és szállítótörzzsel. Ekkor a vevők és a termékcikkszámok egymáshoz rendelésével kialakítható a rendelésállomány, amely mindössze ennyi: ki, mit, mennyit, mikorra, mennyiért rendelt. Ebből már beszerzési terv, sőt ütemezés is készíthető. De nem folytatjuk. "Gyorsan, pontosan és olcsón dolgozunk. Ön ebből bármelyik kettőt választhatja."

Műveleti terv
Cikkszám	Mhcsk	Művelet	Átfidő	Midráf	Géptényező	Bértényező
301	01	rántáskészítés	0,15	0,15	200	150
302	03	panírozás	0,1	0,1	10	140
303	04	hámozás	0,2	0,4	10	100
304	03	előkészítés	0,2	0,2	10	150
501	02	főzés	1,0	0,3	250	160
502	02	sütés	0,5	0,5	250	150
503	02	sütés	0,5	0,4	250	150