A TextLib hírlevélnek a honlapon olvashatóval azonos szövegű nyomtatott változata a szoftvertámogatási díjat fizető könyvtárak számára készül.
Mellékletek:
Megismételjük a legfontosabb tudnivalókat:
2000. szeptemberétől rendszeres és díjtalan TextLib tanfolyamokat tartunk a szoftvertámogatást szerződéses keretben igénybe vevő könyvtárak számára. Szeptember 18-án kezdődött a sorozatot, és az év végéig hónaponként folytatódott. 2001-ben kéthónapos ritmusra álltunk át, amit azután tartani szeretnénk mindaddig, amíg igény van a képzésre.
Ötféle tematikát képzeltünk el:
Az általános programhasználatról szóló tanfolyam alapozza meg az összes többit, kezdő TextLibeseknek azon túljutva érdemes egyet vagy többet kiválasztani a speciális témájúak közül. Természetesen nem szabunk feltételeket, az általános ismeretek megszerzésének gyakori és megfelelő módja a hosszúidejű munka is. Leszögezzük azonban, hogy a könyvtárosi és a rendszergazda tanfolyamok az általános programhasználattal nem foglalkoznak, hanem kiindulópontnak tekintik.
Időpontok és témák:
| Időpont | Téma | Létszám | Betelt |
| 2001. május 7. | Rendszergazda ismeretek | 11 | Nem |
| 2001. július 2. | Általános programhasználat | 6 | Nem |
| 2001. szeptember | Állománygyarapítás | 8 | Nem |
A tanfolyamok időtartama 30 óra, 4 napon át reggel 9.30-tól délután 17.30-ig, rövid ebédszünettel. Jelentkezéseket levélben, telefonon és e-mailben várunk.
A tanfolyamok helyszíne a Fővárosi Szabó Ervin Könyvtár Zenei Gyűjteményének épületében (1088 Bp. Ötpacsirta u. 4.), az alagsori oktatóterem. Az Ötpacsirta utcai ház a FSzEK központjának egyik épülete, a Kálvin tértől (metró) egy percnyi gyalogútra van, a főépülettől balra, a mellékutca (Reviczky u.) másik oldalán. Az alagsorba az udvarból vezet le pár lépcső, lifttel nem lehet odajutni. Reméljük könnyű megtalálni!
Bármilyen jelenség vagy hiba leggyakrabban három helyen gyökerezik:
A TL_VESZ.CFG és a HM_VESZ.CFG olyan fegyver, amellyel az import lefolyását szinte tetszőlegesen befolyásolhatjuk, a beállítások végtelen lehetősége pedig garantálja, hogy a betöltendő rekordok és a fogadó adatbázis egy hibátlan egységet alkothasson. Egy tényező mégis gátat szabhat törekvésünknek, az pedig a csereállomány, az importálandó rekordok állományának minősége.
Amennyiben a betöltendő szöveg hiányos vagy hibás, akkor az gyakran már az import végén kiderül, és elkerülhetetlenül nyoma marad az adatbázisban is. A betöltés befejeződésekor gyakran léthatunk az alábbi szöveghez hasonlót a képernyőn vagy a .LOG szöveg végén:
!! Fel nem oldott hivatkozás:113 !! (Rendszer megj. alapján kereshető)
A figyelmeztetés oka, hogy a program 113 esetben kapcsolatot épített volna ki két rekord között, de a párok egyik tagját nem találta meg a betöltött szövegben. Tehát pl. egy többkötetes könyvnek vagy a közös adata vagy valamelyik kötete hiányzik, pedig a hivatkozás szerint léteznie kell. A hiányzó rekordokat az import üresen létrehozza, és a rendszer megjegyzés mezőbe beírja a hibát:
#HM:üres maradt #!üres maradt
Az első a HunMarc, a második a TextLib rekordok hibájának következménye. A jelenség megszüntetéséhez az exportba kell beleavatkozni, amit a HunMarc állományoknál általában nem tudunk megtenni. Tegyünk egy kis kitérőt a probléma részleteinek áttekintésére!
A kiindulópont a rekordok kapcsolata. A TextLib adatbázisban rengeteg féle rekord tud egymással kapcsolatba kerülni, mindazok, amelyek bevitelekor a mezőbe beszúrással kell folytatni a munkát: közös és kötet, kötet és példány, kötet és szerző, kötet és sorozat, testület és névváltozata, olvasó és kategóriája, szóval akár százával sorolhatnánk. A HunMarcban ez a dolog sokkal egyszerűbb, csak közös és kötet, kötet és analitika valamint közös és/vagy kötet és sorozat kapcsolat létezik. A kapcsolatok lehetséges számától függetlenül akkor működhet jól az import program, ha az összekapcsolandó rekordok mindegyike megvan vagy a csereállományban vagy a fogadó adatbázisban. A feltétel teljesülését az export garantálhatja, ha minden összekapcsolni kívánt rekordot elhelyez a csreállományban. Látható tehát, hogy a TextLib export-import műveletében a kulcs a mi kezünkben van.
Más a helyzet a HunMarc rekordokkal, a csereáálományt készen kapjuk (vesszük), megváltoztathatatlan tartalommal. Ezekben a fájlokban háromféle olyan hiba szokott előfordulni, ami a kapcsolatok felépülésének elmaradásához vezet:
A HunMarcban egy külön jel fejezi ki a bibliográfiai szintet, hogy a rekord
sorozat, közös adat, kötet vagy analitika. Hibás a jelölés, ha pl. egy sorozat
rekordot kötetként ábrázolnak a csereállományban. Az import kínjában a kötet és
sorozata kapcsolat helyett egymástól független kötetet és közös adatot hoz
létre, és készít egy üres sorozat rekordot is - hiszen a hivatkozás szerint erre
szükség van -, ami üresen is marad, mert a téves szint jelölés miatt a rekord
nem található meg.
Elemi feltétel, hogy a hivatkozás helyén és a hivatkozott rekordban az azonosító pontosan ugyanaz a karaktersorozat legyen. Ha ez nincs így, akkor az import program képtelen megtalálni egy pár egymáshoz tartozó tagjait. A legutóbb vizsgált HunMarc állományban pl. a hivatkozás helyén a
787 0 $w 796630szöveg, a hivatkozottban pedig
001 000000796630szerepelt azonosítóként. Az emberi szem jól érzékeli a szándékot, de a programnak ez sajnos kevés.
Az OSZK rekordszolgáltatása a forrás adatbázis változásait tartalmazza. Így könnyen előfordulhat a csereállományban egy olyan közös rekord, amelyik 6 kötetre hivatkozik, és azok közül csak egyetlen kötet van meg, az éppen most új. A közös azért szerepel, mert megváltozott, belekerült egy hivatkozás a 6. kötetre, a kötet pedig új. Hiányzik viszont a csereállományból öt kötet, amelyek a korábbi importok során már bekerülhettek a fogadó adatbázisba. Nincs is semmi baj a régi előfizetőknél, csak azoknál, akik mostanában próbálnak bekapcsolódni.
A vásárolt, kapott, szerzett, stb. csereállomány minőségéről nem egyszerű meggyőződni. Segíthet a HUNDIR.EXE nevű program, ami HunMarc rekordokat olvasmányos formára alakít, és abban a szabvány ismerői már könnyen eligazodnak. Még könnyebb meglátni a hibát a fogadó adatbázisban. Egyrészt a rendszer megjegyzés mezőbe íródó szöveg alapján kereshetők az üresen maradt rekordok, másrészt a hivatkozás helyén a mezőben három kérdőjel látszik.
Eddig az importot befolyásolhatatlanul meghatározó elemről, a csereállományról esett csak szó, ideje rátérni a címben ígért témára. A TL_VESZ.CFG és a HM_VESZ.CFG egyszerű szövegállomány, leggyakoribb helye a \TEXTLIB\EXE könyvtár, feladata a TextLib valamint a HunMarc formátumú csereállományok betöltésének vezérlése. Ez a vezérlés nagyon sok mindent jelent, nézzük először röviden:
Az import végeredményét a vezérló állomány tartalmának módosításával szélsőséges határok között változtathatjuk. A betöltendő állomány és a fogadó adatbázis tartalmának ismeretében sem mindig egyszerű feladat olyan .CFG-t készíteni, amelyik éppen az elvárt végeredményhez vezet. Közismert hiba a rekordok indokolatlan többszöröződése vagy eltűnése, és az összetartozó rekordok elszakadása vagy a nem összetartozók összekapcsolódása.
Rengeteg rossz .CFG van forgalomban, és azok közül több is az InfoKertől származik. Ezek speciális célokra jók lehetnek, de sok helyzetben biztosan adatbázis hibákat okoznak. Két szabályt feltétlenül be kell tartani az importáláskor:
Induljunk tiszta lappal, készítsünk egy TL_VESZ.CFG állományt az elejétől kezdve! Szükségünk van egy egyszerű szövegszerkesztőre, mint amilyen pl. az EDIT a DOS-ban, a Jegyzettömb vagy a WordPad a Windowsban. Sok formai szabályt be kell tartanunk, az érdemi részek rögzített készletből választható kulcsszavak, amelyekben egyetlen "helyesírási" hiba sem lehet. Ha az import program nem képes értelmezni a szövegünket, akkor kiírja az elsőként talált hibás sor számát, és leáll.
A .CFG állományban elhelyezhetünk saját magunk számára megjegyzéseket, az erre a célra szánt sorokat kezdjük # karakterrel. A legelső nem megjegyzés sor tartalma kötelező:
TextLib Import leiro file - InfoKer 1995
Az ezt követő sorok miatt térjünk vissza a vezérlés részleteihez!
A karakterkonverzió módja
A csereállomány egy szöveg, amely a kibocsátó szándéka szerinti kódkiosztásban ábrázolja a karaktereket. Főként a diakritikus jellel írt betűknél számít a kódkiosztás ismerete, ez ugyanis a feltétele annak, hogy a betöltés után az eredetivel azonos betűkép jelenjen meg a TextLibben. Az import program többféle konverzióra képes, elbánik a csereállománnyal ha az CWI, MNBCD vagy OSZK1 kódolású. (A TextLib export eredménye mindig CWI kód, a HunMarc rekordoké pedig MNBCD - egy módosított 852-es - vagy OSZK1 lehet. E kettő között könnyű különbséget tenni: az OSZK1 a diakritikus jeleket külön karakterhelyen ábrázolja, így minden ékezetes betű kétkarakteres, és olvashatatlan.)
Mivel nincsenek a szövegeknek olyan ismérvei, amelyek alapján a program teljes biztonsággal azonosíthatná a kódolást, nekünk kell megadni a TL_VESZ.CFG vagy HM_VESZ.CFG állományban a karakterkonverzió módját a 2. sorban (a három közül természetesen csak egyet):
Kodkeszlet:CWI Kodkeszlet:MNBCD Kodkeszlet:OSZK1
A betöltés célja
Az importot vezérlő szövegben (általában TL_VESZ.CFG vagy HM_VESZ.CFG) háromféleképpen rendelkezhetünk a betöltés céljáról:
A betöltés célját meghatározó sorként a következők egyike használható a .CFG-ben:
Cel:T Cel:B Cel:M
Mindhárom esetben fontos alapelv, hogy az érkező és a már bent levő rekordok azonosságát vizsgálni kell, ezt pedig az import program természetesen meg is teszi. Az összehasonlítás eredményétől függ a művelet, a változatokat a következő táblázat foglalja össze:
| Törlés | Bevitel | Módosítás | |
| A művelet, ha azonosak | törlés | -semmi- | módosítás |
| A művelet, ha különbözők | -semmi- | bevitel | bevitel |
Látható, hogy az importot alapvetően befolyásolni képes a megjelölt cél, az esetek túlnyomó részében mégsem nehéz a választás, hiszen a módosítás a leggyakoribb feladat. A program alapértelmezett működésmódja is ez, a cél megadásának hiányában módosítást végez.
A speciális jelek sorsa
Ezek a speciális jelek valóban nagyon speciálisak, kizárólag HunMarc állományokban fordulnak elő. Azokban a könyvtári rendszerekben, amelyek a TextLibbel ellentétben képtelenek szabványos katalóguscédula nyomtatására, a program hiányosságát gyakran a nyomtatáshoz szükséges jelek mezőbe rögzítésével szüntetik meg. Így kerül a szabályosan leírt adat mögé a " /", a " :", a " ;", stb. Ezeket - mivel teljesen fölöslegesek - az import program levágja, ha akarjuk. Erre szolgál a
Teljesmezo:I Teljesmezo:N
bejegyzések egyike a .CFG következő sorában. "I" jelenti, hogy szükségünk van a teljes, csonkítatlan mezőre, meg kívánjuk tartani a speciális jeleket is, "N" pedig azt, hogy nem. Nem követünk el hibát, ha a
Teljesmezo:N
sort mindig beírjuk a .CFG-be, TextLib importnál fölösleges, de nem zavar, HunMarc betöltésnél pedig vág, ha van mit.
Eddig négy érdemi sora van a tervezett .CFG-nek, valahogy így:
TextLib Import leiro file - InfoKer 1995 Kodkeszlet:CWI Cel:M Teljesmezo:NHa ebben valamit elrontunk, hibaüzenetet kapunk a betöltés elindításakor, és a program le is áll. A felsorolás hibaüzenetei mind a .CFG bevezetőjében elkövetett betűhibákra mutatnak:
!! 1.HIBA (313): Rossz leíró file / c:\textlib\exe\tl_vesz.cfg (1. sor) !! !! 1.HIBA (318): Rossz 'Kodkeszlet:' sor / CVI (2. sor) !! !! 1.HIBA (319): Rossz 'Cel:' sor / N (3. sor) !! !! 1.HIBA (344): rossz 'Teljesmezo:' sor / M (4. sor) !! !! 1.HIBA (314): Rossz sor / Tejesmezo:N (7. sor) !!Az eddigiekben a művelet egészét befolyásoló, általános érvényú szabályokat írtunk le. A továbbiakban már figyelembe kell vennünk a csereállomány és a fogadó adatbázis tartalmát, hogy akár mezőnként rendelkezhessünk a bekerülés módjáról. Induljunk ismét egy picit messzebbről!
A betöltendő adatfájlok és rekordtípusok
A TextLibbel dolgozók sok hasonlóságot találnak az eltérő célokra szolgáló űrlapok között. Rokonai egymásnak a különböző dokumentumtípusok beviteli formátumai a képernyőn, és még az eltérő bibliográfiai szinthez tartozók is gyakran hasonlítanak egymásra. A könyv kötet beviteli ablak rengeteg mezője visszaköszön egy másik dokumentumtípusnál, pl. a térkép részegységnél és annak egy másik bibliográfiai szintjénél, a térképek közös adatánál is. A hasonlóság oka az, hogy ezek az űrlapok bár sokfélék, de egyetlen közös logikai szerkezeten alapulnak, amit a TextLib rekordtípusnak nevez. Ugyanabba a rekordtípusba tartoznak tehát az azonos adategyüttessel leírható rekordok, mint pl. a sokféle dokumentumtípusé, a különböző osztályozásoké vagy tárgyszavaké, stb. (Természetesen nem kötelező minden űrlapon szerepelni a rekordtípus összes mezőjének. Pl. a kötetnek van közös adata és példánya, ellenben a közösnek nincs. Van viszont kötete, ami a kötetnek nincs, és sorolhatjuk százával a példákat.)
Ha tudjuk, hogy egy kitöltött űrlap tartalmából a TextLib adatbázisában rekord lesz, akkor érthetővé válik egy újabb fogalom, az adatfájl. Ez nem más, mint a rekordok tárolási helye. Az eltérő tárolási hely alapján tud a program különbséget tenni az azonos rekordtípushoz tartozó, tehát egymáshoz nagyon hasonló felépítésű adategyüttesek között. Az eddigiekből nem következik, de természetesen igaz, hogy nem kötelező több adatfájl rekordjainak logikai felépítését összevonnni egy rekordtípusba. Pl. az ALKOTO rekordtipusba kizárólag az azonos nevű, tehát szintén ALKOTO adatfájl rekordjai tartoznak.
Az adatcsere programok ismerik a két fogalmat, így nekünk is ismernünk kell, ha e fontos képességet ki akarjuk használni. Az export és import műveletében a program válogatni tud kiküldéskor és betöltéskor is a rekordok között. Ehhez jó kiindulópont a rekordtípus vagy az adatfájl. Szabadon dönthetünk, hogy mivel foglalkozzon és mivel ne az adatcsere. Elhatározásunkat a .CFG-ben írjuk le a következőhöz hasonló módon:
&r DOKUMENTUM &d DOK &d KOTET &d AUDIOKOTET
A bevezető "&" karakter kötelező, mögötte az "r" rekordtípust, a "d" pedig adatfájlt jelent. Amennyiben a .CFG tartalmaz "&r" vagy "&d" kezdetű sort, akkor azt az utána megnevezett adatfájlra vagy rekordtípusra vonatkozó parancsnak tekinti, miszerint törődni kell vele. Megfordítva: az export sem és az import sem figyel azokra a rekordokra, amelyek a felsorolt adatdfájlok vagy rekordtípusok között nem szerepelnek, hanem azokat egyszerűen kihagyja a műveletből.
A fenti példák sorai kizárólag az írásmódot tekintve helyesek, semmiképpen sem következhetnek a valóságban közvetlenül egymás után. Bármelyik sor csak lényeges kiegészítésekkel együtt válik értelmessé, természetesen azokról is lesz szó a későbbiekben.
Az első sor szerint minden olyan adategyüttessel van tennivalója az adatcserének, amelyik a dokumentum rekordtípusba tartozik. Márpedig ebből elég sok van:
Amennyiben a közös kezelés nem felel meg - és hogy miben, arról az összehasonlítás szempontjainál lesz szó - akkor minden egyes adatfájl rekordjairól külön rendelkezhetünk, ahogy ezt a példa 2-4. sora mutatja. A program ésszerűen kezeli a kivételeket: ha adatfájlra érvényes leírást készítünk, akkor a program a szerint jár el. Így a példában a DOK (könyv közös adat), KOTET (könyv kötet) és az AUDIOKOTET (audiovizuális kötet) adatfájl rekordjait másképp kezelheti, mint az egyéb DOKUMENTUM rekordtípusba tartozó rekordokat. Amennyiben pedig az első sort elhagyjuk, akkor az összes DOKUMENTUM rekordtípusba tartozó adategyüttes közül csak a DOK, a KOTET és az AUDIOKOTET rekordokat veszi tekintetbe az adatcsere.
Fontos tudni, hogy TextLib rekordok importjához a rekordokba beépült, almezőnek nevezett szerkezeti elemek leírását is el kell készíteni. A legfontosabb ilyenek az alábbiak:
&r CIMADAT &r PARHCADAT &r ETO_ALM &r KOZREMUKODO &r KIADAS &r NYOMTATAS &r SOROZATLEIRAS &r MELLEKLET
A rekordtípusok és adatfájlok ismeretében aprólékosan szabályozhatjuk az export-import műveletébe bevonandó rekordok körét. A rekordtípus általában a nagyobb bugyor, az adatfájl pedig a kisebb. A .CFG-ben használható nevek az adatbázisszerkezet leírásából (DBSTRUCT.EXE) választhatók.
Végezetül egy példa arra, hogy egy adatfájl és egy rekordtípus neve lehet azonos is. Az első sor rekordtípust jelent, így a .CFG tetszőleges dokumentumtípus példányára vonatkozik. A 2. sor a PELDANY (könyv példány) adatfájl rekordjairól rendelkezik, a 3. (AUDIOPELDANY) az audiovizuális dokumentumok, a 4. (IDOPELDANY) pedig az időszaki kiadványok példányairól.
&r PELDANY &d PELDANY &d AUDIOPELDANY &d IDOPELDANY
Az összehasonlítás szempontjai
Ahogy az import program egymás után dolgozza fel a rekordokat, mindegyikről döntést kell hoznia, mi történjen vele. Korábban részletezett két tényező, az import célja és az adatfájlról és/vagy rekordtípusról leírt rendelkezés alapjában befolyásolja a történést. Most azonban újabb szemponthoz érkeztünk.
A fogadó adatbázis tartalmának is meghatározó a szerepe. Az importtól a célként megjelölt viselkedést várjuk el, a kijelölt rekordokat törölje vagy módosítsa, és csak akkor vigyen be újként valamit, ha az még nincs meg a mi adatbázisunkban. A helyes viselkedéshez a fogadó adatbázisban keresni kell az érkezővel azonos reköordo(ka)t, és a találat ténye továbbá az import célja együtt határozza meg a további tennivalókat. A kereséshez pedig előre kiválasztott mezőket használ a program, és azok tartalmának összehasonlítása után dönt az egyezőségről.
Az összehasonlítás szempontjainak meghatározásánál tehát a cél az egyértelműség: mutatkozzon két rekord azonosnak, ha valóban az, és lássék különbözőnek, ami különbözik. Nem akarhatjuk, hogy újkent bekerüljön az adatbázisunkba az, ami már ott is megvan, es persze azt sem, hogy az érkező rekord átírjon egy meglevőt, holott semmi közük egymáshoz. Mint kiderül majd, ez egy csöppet sem egyszerű feladat. Követhetünk el hibát mindkét irányban, és készítünk is .CFG-t, ami ezt bemutatja.
A vezérlő állományban aprólékosan szabályozhatjuk, hogy mit vizsgáljon az import program, amikor két rekordot összehasonlít. Szinte tetszőleges mezőket jelölhetünk ki, azoknak a tartalmát veti egybe a program páronként az érkező és már meglévő rekordokban. Az erre vonatkozó utasítást az "Azonosito" szóval kell kötelezően kezdeni, és ahogy a következő példa is mutatja, mindig az adatfájl és/vagy a rekordtípus megjelölésével együtt érvényes.
&r PELDANY Azonosito:VONALKOD
A nagyon egyszerű leírás szerint a PELDANY rekordtípus rekordjainak - azaz bármelyik dokumentumtípus példányainak - kereséséhez és összehasonlításához egy mezőt használ az import, az [Azonosító] (VONALKOD) nevűt. Biztonságosan elegendő ez, hiszen a TextLibben a példányok [Azonosító] mezője kötelező és egyedi. Minden olyan adatfájl vagy rekordtípus esetében elintézhetjük ilyen egyszerűen az azonosítást, amelyben létezik egy egyértelmű azonosító. Ilyen pl. a többféle osztályozás és tárgyszó, sokféle rendszerelem (jog, keresőkérdés, rendezési formátum, nyomtatási formátum, stb.), stb.
Haladjunk összetettebb esetek felé, már csak azért is, mert a példányok importja ritka feladat. A következő példa rögtön az import program egy jellegzetességére is rámutat, ami sajnos gyakran adatbázis hibához vezet.
&r FOLDRAJZ Azonosito:MEGNEVEZES
Ránézésre ez sem bonyolult, mégis érdemes foglalkozni ezzel a több .CFG-ben is előforduló hibás sorral, ami a rekordok többször tárgyalt sokszorozódásához vezet (Lásd a 4. hírlevelet, "A besorolási adatok egységesítése" címnél is!). A hiba kiindulópontja az a tény, hogy a földrajz rekordokban a [Megnevezés] mező nem egyedi, vagyis a rendszer megengedi több azonos nevű földrajzi hely bevitelét. Nyilvánvalóan helyes 3 db "Veszprém" léte egy adatbázisban, ha az egyiknél a [Típus] mező üres, a másiknál "megye", a harmadiknál pedig "vármegye" értékű.
Amikor azonban egy importálandó rekordban a földrajzi név "Veszprém", akkor a program a fogadó adatbázisban három azonos nevűt fog találni, ha a fenti útmutatásnak megfelelően keres. Megoldhatatlan helyzetbe kerülünk, és kétféle döntést hozhatunk:
A két rossz választás közül a program a második mellett dönt, mert megvan az esélye annak, hogy a rekordok valóban különböznek, csak az összehasonlítás rossz. Ha belegondolunk, ez így is van. Javításként egészítsük ki az azonosító mezők sorát!
&r FOLDRAJZ Azonosito:MEGNEVEZES TIPUS
Ettől az összehasonlítás egyértelművé válik, mert az érkező rekord azzal azonos a három "Veszprém" közül, amelyikkel a [Típus] mezője is az. És csak akkor keletkezik a negyedik "Veszprém", ha a [Típus] más. Az elmondottakból következik, de a biztonság kedvéért szögezzük le: az azonosítőként megnevezett mezők mindegyikének páronkénti egyezése feltétele két rekord azonosságának, megengedve bármelyik - de semmiképpen nem az összes - kitöltetlenségét is. Részletezve: azonos két földrajz rekord, ha
A harmadik változat - a [Típus] mindkettőben kitöltött és azonos, a [Megnevezés] viszont kitöltetlen - elfogadható lenne, ha a [Típus] indexelt mező lenne, azaz lehetne az értéke alapján keresni, a 4. változat pedig értelmetlen, mert ha mindkét mező kitöltetlen, akkor nincs is mit keresni a vizsgálathoz a fogadó adatbázisban.
Sajnos pusztán a .CFG módosításával nem lehet megszüntetni a rekordok korábban elkezdődött sokszorozódását. Ha már van kettő, a típusában is azonos földrajz rekord, akkor az érkező harmadiknál az előbb leírttal azonos eldönthetetlen helyzet áll elő, és folytatódik sokszorozódás. Hogy ne így legyen, a .CFG átírása előtt az adatbázist kell módosítanunk, meg kell szüntetni az azonos rekordokat. Ennek módszere a 4. hírlevélben "A besorolási adatok egységesítése" címnél olvasható.
Láthatjuk tehát, hogy egy mégoly jellemzőnek hitt mező sem elegendő egymagában az azonosításhoz. Találnunk kell mindenképpen kiegészítő(ke)t, hogy a sokszorozódás hibáját eleve kizárjuk.
A TextLibben előforduló rekordok túlnyomó többségének egyszerű megtalálni az azonosítás céljára megfelelő mezőit. A kevés kivétel között legfontosabb a sokféle dokumentumtípus. Az ok egyszerű: nincs a dokumentumoknak egyetlen igazán jellemző mezője, hanem több együttesen alkot egy kifejező egységet. Az ISBN és az ISSN a szabályt erősítő kivétel, már ha egyáltalán van a dokumentumnak. Így a dokumentumok azonosítása a legnehezebb feladat, eddig nem használt fegyverek bevetése nélkül nem is lehetne megoldani. Nézzük!
&r DOKUMENTUM Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM
Az első, ami feltűnik, a két azonosító sor. Ez megengedett dolog, sőt, a maximum akár négy is lehet. Az egymást követő sorok egymással "vagy" kapcsolatban állnak, ha tehát az import program az első alapján nem talál az érkezővel azonos rekordot a fogadó adatbázisban, akkor továbblép, és megpróbál a második alapján keresgélni, és így tovább. Bármelyik feltételcsoport igaznak bizonyul, a továbbiak vizsgálata elmarad. Nem nyilvánvaló, de logikus következtetés adódik a "vagy" kapcsolatból: ha több azonosító sort készítünk, akkor azokat nagyjából egyforma szigorú szempontrendszer alapján kell felépítenünk.
A második új elem a példában a "/" jel. Az import programot ez arra utasítja, hogy csak az előtte felsorolt mezők alapján hajtsa végre a keresést. Az így megtalált rekordokat azután természetesen a többi mező szerint is összehasonlítja az érkezővel, tehát a jel használata az azonosítás végeredményét nem befolyásolja. Abban az esetben mégis nagyon célszerű a használata, amikor be akarunk vonni a szempontok közé olyan mezőket, amelyek bár fontosak az azonosság megítélésében, de rengeteg rekordban egyformák. Ilyen pl. a dokumentumok [Megjelenési éve] (MEGJEVE). A "/" jel elé írva a mező bekerül a keresés szempontjai közé, és mivel sokezernyi megfelelés várható, sokáig tart. Gyorsabban fut a program, ha a jel mögé írjuk az ilyeneket.
A "/" jel ürügyén ismét egy kis kitérőt célszerű tenni. A TextLib adatbázis-szerkezetének ismeretében rögtön szembetűnik valami: az első azonosító sor egyetlen jel előtti mezője, a DOK ([Közös adatai]) nem indexelt, nem lehet tehát kereséshez felhasználni. A TL_VESZ.EXE program kerülő úton mégis képes egy ilyen - nem ismételhető kapcsolódó - mezőből kiindulva megtalálni az összehasonlítandókat. De csak a TL_VESZ.EXE, a HM_VESZ.EXE nem, HunMarc rekordok betöltésekor a .CFG fenti sora hatástalan marad.
Mindegyik azonosító sorba legfeljebb 8 mezőnevet írhatunk, és azok között indexeltnek vagy kapcsolódónak is szerepelni kell. Annak híján ugyanis a TextLib képtelen lenne keresni, és akkor nem lenne mit mivel összehasonlítani. Észre is veszi a program ezt a hibát, ahogy az imént említett néhány más szabály megszegését is:
!! 1.HIBA (320): Rossz mező / REZSJELZES (11. sor) !! !! 1.HIBA (330): Túl sok azonosító mező (max 8) / (9. sor) !! !! 1.HIBA (331): Túl sok 'Azonosito:' sor (max 4) / (14. sor) !! !! 1.HIBA (332): Nem adott meg indexelt mezőt / (11. sor) !! !! 1.HIBA (334): Másodszori definíció / (20. sor) !!
Térjünk vissza a dokumentumok azonosításának problémájához! Elsőként érdemes megfontolni, hogy tudunk-e a típus tagjaira - azaz mindenféle dokumentumra - egyaránt érvényes leírást készíteni. Ez semmiképpen sem végleges döntés, mert ahogy korábban már szó volt róla, bármikor szerkeszthetünk saját feltétel listát bármelyik adatfájlra külön is. A fenti példa egy jó mintája a közös leírásnak, ami rögtön megoldja a dokumentumtípusokon belüli bibliográfiai szint kezelését is. Bár a két sorban ugyanazok a mezőnevek olvashatók, a céljuk és a működésük eltér egymástól.
Az elsőben egyetlen mező a [Közös adatai] (DOK) után azonnal a "/" jel következik, eszerint tehát ez a keresés kizárólag a közös adattal rendelkező dokumentumokra, azaz a többkötetesek köteteire vonatkozik. Amennyiben az érkező kötetnek azonos a közös adata egy fogadó adatbázisbelivel, akkor a [Kötetjelzés], a [Megjelenés éve], a [Főcím], a [Párh. címadatok], a [Címadatok], az [Alcím, egyéb címadat] és a [Szerzők] mező összehasonlítása után eldöl, hogy új vagy már meglevő kötet érkezett-e. Kihasználtuk a megengedett nyolc mezőnevet, ennyi alapján biztonságosan azonosítható két dokumentum, még akkor is, ha több üres mező is van a felsorolásban.
A második sorban az azonosítás vezérelemei a címek, ez a felsorolás tehát főként a közös adatokhoz és az egykötetesekhez való. Nem csökkentjük a mezők számát, mert veszélyes lenne. Bár ezt a sort nem a többkötetesek kötetei számára terveztük, mégis meg kell felelnie azoknak is, hiszen az első azonosító sor nemleges válasza után mindenképpen a második következik a kötetek számára is. Képzeljünk el egy kötetet, amelyik az első sorban már a közös adatok vizsgálatakor nem felel meg, mert az - mármint a közös rekord - nincs benne a fogadó adatbázisban. Amennyiben a második sorból abban a hiszemben húznánk ki a szempontok közül a közös adatokat (DOK) és a kötetjelzést (RESZJELZES), hogy a köteteket már elintéztük az elsőben, akkor furcsa kellemetlenségek történhetnének. Az érkező rekord ugyanis felülírhatna egy sok adatában azonos, de másik közöshöz tartozó kötetet, vagy - ismét csak a sokféle adat azonosságát feltételezve - a saját közös adatának kötetévé tehetné a fogadó adatbázis valamelyik egykötetesét. A kitűzött célt, a mindenféle dokumentumtípus többféle bibliográfiai szintjéhez tartozó dokumentumának összehasonlíthatóságát a két sor együtt valósítja meg,
Látszólag biztonságosabbá teszi az összehasonlítást, ha minél több mezőt használunk szempontként. Látnunk kell azonban a hosszú felsorolásából keletkező veszélyt is. Ez pedig a különböző adatbázisok eltérő adattartalmából fakad. Már egyetlen plusz kitöltött mező is megbuktathatja az azonosságot: pl. a fogadó adatbázis rekordjában van címadat, az érkezőben pedig megjegyzésben vannak a gyűjtemény darabjai, és oda az egyezés.
Bizony jó lenne a dokumentumok összehasonlításához egyetlen egyértelmű azonosítót hsználni! Valahogy így:
&r DOKUMENTUM Azonosito: ISBN Azonosito: ISSN
Egyszerű és nagyszerű minden olyan esetben, amikor biztosan van az érkező dokumentumoknak ISBN-je. Mert amelyiknek nincs, az mindenképpen új rekordnak fog bizonyulni, ha nincs több azonosító sor. Márpedig az 1976. előttieknek nincs, meg az újaknak is hibás néha, van tehát bizonytalanság ezzel is. Egészítsük ki!
&r DOKUMENTUM Azonosito:ISBN FOCIM
Ezzel mindent elrontottunk. Most már elegendő két ISBN nélküli dokumentum főcímének egyezősége a teljes azonossághoz, márpedig ez nagyon puha feltétel. Egyértelmű azonosító mellé ne írjunk más feltételt! Illetve... Ha muszáj megtenni, használjuk a "/" jelet. Akkor ugyanis csak az ISBN-ek létének és azonosságának kiderülte után foglalkozik a program a főcímmel.
&r DOKUMENTUM Azonosito:ISBN / FOCIM
Az eddigiek összegzéseként készítsünk egy nem biztosan, de nagy valószínűséggel jól használható mintát TextLib adatbázisból származó csereállomány dokumentumainak összehasonlításához.
&r DOKUMENTUM Azonosito:ISBN Azonosito:ISSN Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM
A HunMarc formátumú rekordok esetében kétségbeejtőnek tűnik a helyzet, ha hiányzik az ISBN és az ISSN is. A 3. sor hatástalan, és a 4. is az egy többkötetes cím nélküli kötetének betöltésekor.
Van azonban egy mostanáig eltitkolt fontos szabály az összehasonlításban, ami felülbírálja az eddig leírtakat: egy rekord önmagával minden körülmények között azonos. Egy forrásként használt adatbázisból - lehet az a szomszéd könyvtár vagy az Országos Széchényi Könyvtár rendszeres szolgáltatása - többször is megkaphatjuk ugyanazt a rekordot, hiszen minden jelentős változtatás után újra kiküldi a szolgáltató. Az adatbázis azonosító és a rekordazonosító együttesen egyértelműen azonosítja a rekordot, és az import program a .CFG-ben tett rendelkezéstől függetlenül az érkező rekordot azonosnak tekinti saját maga korábbi változatával.
Márpedig a HunMarc állományokban a közös-kötet kapcsolatot éppen az adatbázis azonosítóval ábrázolják, így ezek betöltésére is általában megfelel a fenti minta. Elméletileg előfordulhat, és hibához is vezet, ha egy adatszegény kötetet - pl. csak a kötetjelzés és a közös adat ismert - úgy importálunk, hogy ugyanaz már saját adatbevitelből eredően megvan az adatbázisunkban. Ilyenkor számíthatunk a kötet megduplázódására.
Tekintsük át, érdemes-e adatfájlonként külön azonosító szakaszt készíteni a .CFG-ben a sokféle dokumentumtípus számára. Egy esetben nyilvánvalóan igen. Akkor, ha az import műveletében szűrni is akarjuk az érkező rekordokat. Pl. kizárólag audiovizuális dokumentumok betöltéséhez hagyjuk el a
&r DOKUMENTUM Azonosito:...
szakaszt, ellenben soroljuk fel a megcélzott adatfájlokat:
&d AUDIODOK Azonosito:... &d AUDIOKOTET Azonosito:... &d AUDIOANAL Azonosito:...
Mivel csak az audiovizuális dokumentumok importjához talál leírást a program a .CFG-ben, minden mást kihagy, valóban szűrőként viselkedik tehát ez a pár sor.
Egy másik lehetséges oka az adatfájlonkénti leírásnak az egyszerűsítés lehetne. Talán könnyebb áttekinthető szabályokat alkotni, ha nem akarunk annyi mindent egy csapásra megoldani. Az audiovizuális közös adatokra (AUDIODOK) a dokumentumoknál megismert egyik sor kis átalakítással elegendőnek látszik. Nyugodtan kihagyhatjuk a DOK [Közös adatai] és a RESZJELZES [Kötetjelzés] mezőt, mert ilyenek a közös rekordban nincsenek. Helyettük vonjuk be a KOZREMUKODO [Közreműködők] mezőt:
&d AUDIODOK Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO KOZREMUKODO MEGJEVE ALCIM
Az audiovizuális részegységgel már nem könnyű elbánni. Próbáljuk a fentről ollózott másik sort használni!
&d AUDIOKOTET Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO
Jó ez a többkötetesek köteteihez, de nem jó a magányos kötetekhez. Kellene legalább még egy sor, és akkor ugyanott vagyunk, mint a rekordtípus egészét szabályozó leírás készítésekor voltunk. Leszögezhetjük tehát, hogy adatfájlonként elkülönülő szabályrendszert kizárólag szűrés céljára indokolt felállítani.
Foglaljuk össze az érkező és bent levő rekordok összehasonlításának lényegét!
A vizsgálat legelső mozzanata, hogy a betöltő program az érkező rekord importazonosítója alapján keres. A .CFG szabályrendszere akkor lép működésbe, ha ez a keresés eredménytelen marad.
A .CFG-ben négy sorban adhatunk meg azonosító mezőket, mindegyikben nyolcat. A program egymás után dolgozza fel a sorokat, amíg meg nem állapítja a rekordok azonosságát. Új lesz az érkező rekord, ha egyik sor alapján sem állapítható meg egyezés, vagy ha több azonos is van a fogadó adatbázisban. Az azonosság feltétele a felsorolt mezők mindegyikének páronként egyező tartalma. Igaz az egyezés, ha a mezők azonos tartalommal kitöltöttek vagy ha üresek. Az összehasonlításba bevonni kívánt rekordok keresésénél az üres mezők természetesen figyelmen kívül maradnak. Az azonosító mezők felsorolását a "/" jellel kettéválaszthatjuk. A program csak a jel előtti mezőket használja kereséshez, így a keresést felgyorsíthatjuk és/vagy egyértelműsíthetjük.
Még egyszerűbben: két rekord azonos, ha egyetlen rekord két adatbázisban előforduló két változata, vagy ha az összehasonlításra kijelölt mezőinek a tartalma azonos.
Az összehasonlítás szempontjainak kidolgozásában az elvi megfontolások mellett gyakorlati segítséget is kaphatunk. Jó lenne meggyőződni az azonosítás megbízhatóságáról, miközben a rekordok ezrei ömlenek be a fogadó adatbázisba, de erre sajnos nincs mód. A betöltés befejeztével azonban az egyesített adatbázis tartalmán kívül a folyamat mozzanatait leíró TL_VESZ.LOG vagy HM_VESZ.LOG nevű szövegállomány is fontos információkkal szolgál. (Lásd a 7. hírlevélben !) Ennek a szövegállománynak a tartalmát a .CFG-be írt kiegészítéssel kibővíthetjük az összehasonlítás pontosságának könnyebb megítélése céljából. A vezérlő utasítás alakja a következő:
&r DOKUMENTUM Azonosito:... Hasonlo:...
A "Hasonlo:" kezdetű sor az újdonság. Felépítése az azonosító sorokkal csaknem megegyezik, a különbség, hogy kizárólag indexelt mezőket - legfeljebb nyolcat - adhatunk meg a hasonlóság felderítésének céljára. A megadott szempontok alapján a fogadó adatbázisnak az érkezőhöz hasonló rekordjairól listát kapunk a .LOG állományban. E lista alapján dönthetünk arról, hogy enyhíteni vagy szigorítani érdemes az azonosítás feltételeit. A hasonló rekordok gyűjtése természetesen nem befoéyásolja a fő célt, az érkező és bent levő rekordok összehasonlítását. Pl. a dokumentumok importját vezérlő szövegrészt az alábbi módon egészíthetjük ki:
&r DOKUMENTUM Azonosito:ISBN Azonosito:ISSN Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM Hasonlo:ISBN Hasonlo:FOCIM CIMADAT PARHCADAT SZERZO
A hasonlóságot felderítő soroknak csak akkor van értelme, ha az eredményét fel is használjuk az egyesített adatbázis tartalmának ellenőrzésében. Ha nem, akkor a program futásának lassításán kívül semmi más következménye nincs, nyugodtan kitörölhetjük a .CFG beli összes előfordulását.
Az adatbázisba kerülés módja
Túljutva az összehasonlítás bonyodalmain a program tennivalója két ágra bomlik:
Az új rekord bevitele egyszerű feladatnak látszik, kerüljön be az adatbázisunkba úgy, ahogy van. Az importot vezérlő leírásban egy paranccsal még ezt az átvételt is finomítani tudjuk, a rekord tetszőleges mezőit kizárva a műveletből.
Több megfontolást érdemel az azonos rekordok esete, az esetleges módosítás. Az összehasonlításra kiválasztott azonosító mezőket az import program páronként egyező tartalmúnak találta az érkező és egy már meglevő rekordban, ezek alapján született a döntés. De mi van, mi legyen a többi mezővel? Lehet az érkező és a bent levő rekordnak is plusz tartalma a másikhoz képest. Nézzünk egy egyszerű példát:
Bent levő Érkező
FOCIM: A magyar nemzet megszületése FOCIM: A magyar nemzet megszületése
SZERZ_KOZL: Kristó Gyula SZERZ_KOZL: Kristó Gyula
KIADAS: KIADAS:
1.XMEGJ_HELYEK: Budapest 1.XMEGJ_HELYEK: Budapest
KIADOK: Kossuth KIADOK: Kossuth
NYOMTATAS:
1.XMEGJ_HELYEK: Budapest
KIADOK: Kossuth
2.XMEGJ_HELYEK: Szekszárd
KIADOK: Szekszárdi Ny.
MEGJEVE: 1998 MEGJEVE: 1998
OLDALSZAM: 210, [3] p. OLDALSZAM: 210, [3] p.
MERET: 20 cm MERET: 20 cm
ISBN: 963-09-3990-8 ISBN: 963-09-3990-8
KOTES: fűzött KOTES: fűzött
AR_TERJFELT: 990,- Ft AR_TERJFELT: 990,- Ft
BIBL_MEGJEGYZES: Bibliogr.: p. 207-
[211]. és a lábjegyzetekben
SZERZO: SZERZO: Kristó Gyula
1.NEV: Kristó Gyula
EVEK: 1939
NYELV: magyar NYELV: magyar
ETO_ALM: ETO_ALM:
1.ETOSTRING: 943.9"08/12" 1.ETOSTRING: 943.9".../12"
FO: Magyarország története
TARGYIDO: "08/12"
2.ETOSTRING: 316.356.4(=945.11) 2.ETOSTRING: 316.356.4(=945.11)
FO: nemzet / szociológia
ETNIKAI: magyarok
SZAKJELZET: 943.9
CUTTER: K 95
PELDANY:
1.VONALKOD: 001000062185N
2.VONALKOD: 001000051089O
ETO2_ALM:
1.ETOSTRING: 9(439)"08/12"
FO: történelem
FOLDRAJZ: Magyarország
TARGYIDO: 0800/1299
2.ETOSTRING: 307(439)"08/12"
FO: társadalmi tudat
FOLDRAJZ: Magyarország
TARGYIDO: 0800/1299
3.ETOSTRING: 309(439)"08/12"
FO: társadalomtörténet
FOLDRAJZ: Magyarország
TARGYIDO: 0800/1299
A két rekord azonosító mezője (ISBN) megegyezik, de másutt vannak eltérések, és azok kezelésére a program ötféleképpen képes:
A mezők kijelölése
Az előbb felsorolt parancsok önmagukban használhatatlanok, csak a rekord egy vagy több mezőjének megnevezésével együtt érvényesek. Vagyis szinte tetszőleges részletességgel megadhatjuk, hogy az érkező rekord mezőit átvenni kell-e illetve eldobni, vagy a meglevőket kitölteni, módosítani illetve vegyíteni az újakkal. Ezek után a dokumentum rekordtípus importját vezérlő leírás immár teljessé válik:
&r DOKUMENTUM Azonosito:ISBN Azonosito:ISSN Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM Kitolt:/MIND /RENDSZER Vegyit:ETO_ALM Eldob:KIVONAT
A kiegészítő rész három sora közül természetesen az 1. a kulcs, a másik kettő csak finomítás, kiegészítés. Azonnal fűzzünk néhány megjegyzést is az újdonságokhoz:
Kitolt:/MIND /RENDSZERparancs a dokumentum összes mezőjéről rendelkezik már, de a
Vegyit:ETO_ALM Eldob:KIVONATparancs az [ETO] (ETO_ALM) és az [Ismertetés/kivonat] (KIVONAT) mezőre új szabályt határoz meg, és az érvényesül a betöltéskor.
Eldob:PELDANYsor következtében a bekerülő dokumetumok [Példányai] mezője természetesen kiürül, de ez a tény nem befolyásolja a példány rekordok importját. Azt a .CFG-ben a példányokra vonatkozó rendelkezés szabályozza. A következő minta használata után betöltődnek a példányok is, de hiányozni fog a kapcsolat a dokumentummal, ami nem lehet cél.
&r DOKUMENTUM Azonosito:ISBN Azonosito:ISSN Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM Kitolt:/MIND /RENDSZER Vegyit:ETO_ALM Eldob:PELDANY &r PELDANY Azonosito:VONALKOD Kitolt:/MIND /RENDSZERKapcsolódó mezőket tehát általában nem érdemes az "Eldob" parancs mögött felsorolni, a kapcsolt rekordra vonatkozó rendelkezés - a példában a "&r PELDANY" kezdetű szövegrész - szándékos kihagyása oldja meg jól a feladatot.
Végül nézzünk egy gyakorlatban is használható .CFG állományt dokumentumok betöltéséhez. A vezérlő állomány egyaránt alkalmas TextLib és HunMarc rekordok importjára (Lásd a "DOK /" kezdetű sorra vonatkozó korábbi megjegyzést is!), mindenféle dokumentumtípushoz és segédrekordokhoz.
# # Dokumentumok es kapcsolataik betoltesehez # TextLib Import leiro file - InfoKer 1995 Kodkeszlet:CWI Cel:M Teljezmezo:N &r DOKUMENTUM Azonosito:ISBN Azonosito:ISSN Azonosito:DOK / RESZJELZES MEGJEVE FOCIM PARHCADAT CIMADAT ALCIM SZERZO Azonosito:FOCIM CIMADAT PARHCADAT / SZERZO MEGJEVE DOK RESZJELZES ALCIM Kitolt:/MIND /RENDSZER Vegyit:BIBL_MEGJEGYZES PELDANY &r PELDANY Azonosito:VONALKOD Kitolt:/MIND /RENDSZER &r IDOSZAM Azonosito:KOTETE / SZAMOZAS KELTEZES MEGJEVE EVFOLYAM Kitolt:/MIND /RENDSZER &r CIMADAT Kitolt:/MIND /RENDSZER &r PARHCADAT Kitolt:/MIND /RENDSZER &r ALKOTO Azonosito:NEV NEVKIEG EVEK Hasonlo:NEV Kitolt:/MIND /RENDSZER &r TESTULET Azonosito:NEV IDOSZAK SORSZAM SZEKHELY Hasonlo:NEV Kitolt:/MIND /RENDSZER &r ETO_ALM Kitolt:/MIND /RENDSZER &r ETO2_ALM Kitolt:/MIND /RENDSZER &r SPEC_OSZT Azonosito:KOD Kitolt:/MIND /RENDSZER &r TEZAURUSZ Azonosito: KULCS Hasonlo: KULCS Kitolt:/MIND /RENDSZER &r FOLDRAJZ Azonosito:MEGNEVEZES TIPUS Kitolt:/MIND /RENDSZER &r KOZREMUKODO Kitolt:/MIND /RENDSZER &r KIADAS Kitolt:/MIND /RENDSZER &r SOROZATLEIRAS Kitolt:/MIND /RENDSZER &r SOROZAT Azonosito:FOCIM PARHCADAT ISSN Kitolt:/MIND /RENDSZER &r MELLEKLET Kitolt:/MIND /RENDSZER &r MU Azonosito:EGYSCIM SZERZO KELETKEZESIIDO Kitolt:/MIND /RENDSZER &r PARH_SZAMOZAS Kitolt:/MIND /RENDSZER
Bemelegítésként foglalkozzunk egy nagyon egyszerű statisztika definiálásával: állapítsuk meg az olvasók egy kijelölt csoportjáról, hogy mely városokból érkeznek a könyvtárunkba, és hogy sorai is legyenek a táblázatnak, végezzük az összegzést olvasói kategóriánként.
Az oszlopok és sorok definiálását rendszergazdaként kell végezni a [Rendszer / rendszerelemek Bevitele / Statisztikai szempont] illetve a [... / statisztika Bontás] pontban. A "Statisztika szempont" beviteli ablakban, majd abból továbblépve a következőket töltsük ki:
A "Statisztika bontás" beviteli ablakban, majd abból továbblépve a következőket töltsük ki:
Eddig tartott a feladat a rendszergazda számára, készen vannak a statisztika elkészítéséhez szükséges szempontok. Használatukhoz kiindulópont a mindenki menüjében megtalálható [Egyéb / sTatisztika] pont. Ennek kiválasztása előtt egy találati halmazba gyűjtsük össze a feldolgozásra kijelölt olvasó rekordokat.
A "Statisztika" ablakban az összegzéshez a következő mezőket kell kitölteni:
Vissza: Hírlevelek TextLib honlap InfoKer honlap