Mire való a szöveges adatbázis?

Az IIF-Hírek legújabb számában olvastuk, hogy az IIF Program Iroda a központi gépén működő ISIS adatbázis-kezelő rendszerét a gyorsabb, könnyebben kezelhető BRS/SEARCH  szöveges adatbázis-kezelővel váltja fel. Ez indokolja a BRS/SEARCH részletesebb bemutatását. (A szerk.)

Elnézést kell kérnem mindazoktól az olvasóimtól, akik a fenti kérdésre már ismerik a választ, de számos bemutató tapasztalata szerint Magyarországon a szöveges adatbázisok még nem terjedtek el, és ezért nem felesleges a kérdéssel foglalkoznunk.Adatbázison általában az adattárolásnak olyan formáját értjük, amiből a betöltött adatokat tetszőleges sorrendben és az igényeinknek megfelelő csoportosításban nyerhetjük vissza. Úgy gondolunk rájuk, mint az agyunk kiterjesztéseire, amelyekben olyan lexikális jellegű információkat tárolhatunk, amelyekkel felesleges lenne az agyunkat terhelni. Az adatok az adatbázisba rendszerezve kerülnek be, és ezért a köztük való eligazodás gyors.
A továbbiakban hagyományos adatbázisnak fogjuk nevezni azokat a közismert (IDMS, dBASE, DataCore, BTRieve, Oracle stb. alapú) adatbázisokat, amelyeket ma már széles körben használnak. A legismertebb ilyen alkalmazások:könyvtári katalógus,

  • raktári nyilvántartás,
  • orvosi betegnyilvántartás,
  • légitársaságok helynyilvántartása,
  • folyószámla-nyilvántartás, stb.

A hagyományos adatbázisokat azért említjük, mert könnyebb megvilágítani a szöveges adatbázisok használatát, ha van mihez hasonlítani őket.
A hagyományos adatbázisok néhány – a továbbiak szempontjából fontos – jellemzőjét soroljuk fel a következőkben:
A tárolt adatok struktúráltak, szerkezettel rendelkeznek. Ez azt jelenti, hogy egy-egy adat általában több, jól meghatározott rész adatból (mezőből) tevődik össze. Könyvtári katalógusban ilyenek lehetnek a könyv szerzőjének neve, a könyv címe, a példányszám, a méret, a könyv helye a polcokon stb. Raktári nyilvántartás esetén az áru megnevezése, cikkszáma, egységára, a raktárban tárolt mennyisége, méretei stb. Orvosi betegnyilvántartásban a beteg neve, címe, születési adatai, foglalkozása, betegségei, testméretei stb. A mezők együttesét rekordnak szokás nevezni.
Az adatok egy része gyorsan változhat, például a raktári nyilvántartásban ilyen a raktárkészlet, és ezért nagyon fontos az adatok gyors módosíthatósága.
A mezők általában rögzített (korlátozott) hosszúságúak. A neveket 20-40 betűben, a számokat 112 számjegyben szokták korlátozni.
A mezők közül bizonyosakat kiválasztunk, és az adatbázisban csak ezeknek a kiválasztott mezőknek (kulcsoknak) az alapján lehet az adatokat megtalálni. A kulcsokat már az adatbázisok tervezésekor meg kell határozni. Könyveket például sokkal inkább a címük alapján keresünk elő, semmint a méretük alapján, ezért egy könyvtári katalógusban a cím az kulcs, de a méret általában nem.
A keresés ezekben az adatbázisokban nem cél, hanem csak segédtevékenység. Ezek az adatbázisok általában egy-egy alkalmazás hátterében működnek, és a felhasználó nem is kerül közvetlen kapcsolatba az adatbázissal, sokszor nem is nagyon tud róla. Ő csak elad egy árut, kiad egy könyvet kölcsönzésre, megméri egy beteg vérnyomását, stb. Az ezzel kapcsolatos adminisztrációt (a megfelelő rekordok előkeresését, módosítását, visszaírását) a felhasználói rendszer végzi el. A felhasználó csak kérdésekre válaszol, adatokat ír be, és a kész végeredményt kapja vissza.
A kiinduló adatok rögzítése speciális karbantartó programok segítségével történik, ami még a nagyon jó támogatást nyújtó rendszerek esetén is legalább a beviteli képernyők egyedi megtervezését igényli. Nagyon fontos a precíz rögzítés, mert a hibásan rögzített adatokat a későbbiek során soha sem fogjuk megtalálni.
Sokszor szükség lehet azonban struktúrálatlan, vagy csak kevéssé struktúráit adatok tárolására is azzal az igénnyel, hogy majd hatékonyan el tudjunk igazodni közöttük. Ritkán, vagy egyáltalán nem változó adatokról van szó, mint például:

  • hírek, újságcikkek,
  • tudományos cikkek,
  • irodai levelezés,
  • irattárak és iratraktárak,
  • karbantartó szolgáltatások hibabejelentései,
  • múzeumok, képtárak tárgyleírásai,
  • rendőrségi nyomozati anyagok,
  • törvénytárak,
  • egyéb szöveges információk.

Ezek a dokumentumok igen laza szerkezetűek, ha egyáltalán rendelkeznek jól elkülöníthető részekkel. Cikk esetében ilyen lehet a szerző neve és maga a szöveg, a szöveget esetleg érdemes bekezdésekre osztani. Irodai levelezésben érdemes kiemelni a levél származását, tárgyát, címzettjét és szövegét, de ezeknek a részeknek a hossza, különösen a szövegé csak nagyon nehezen korlátozható ésszerűen.
Azt sem tudjuk előre, hogy minek az alapján akarunk majd egy-egy dokumentumot – ez a szöveges adatbázisok szokásos szóhasználata, ami a hagyományos adatbázisok rekord fogalmának felel meg – előkeresni a későbbiek során. Lehet, hogy csak egy szóra, vagy csak egy szótöredékre emlékezünk belőle, esetleg bizonyos szavak együttes előfordulására stb. A dokumentumokat valamilyen szövegszerkesztő (text editor, vagy word processor) program segítségével hozzuk létre (rögzítjük). Az adatok pontos rögzítésére nem kell olyan nagy hangsúlyt fektetni, mint a hagyományos adatbázisok esetén, a kissé hibás rögzítés még nem zárja ki annak lehetőségét, hogy a keresett dokumentumot a későbbiek során megtaláljuk.
Ilyen dokumentumok tárolására készülnek a szöveges adatbázis-kezelő rendszerek. A szöveges adatbázisban bármelyik szóra, vagy szótöredékre kereshetünk, pontosabban szólva az adatbázis tervezésekor éppen azokat a szavakat (névelők, kötőszavak, stb.) kell meghatároznunk, amelyeket ki akarunk zárni a keresésből, hogy az adatbázist ne terheljük túl olyan felesleges adatokkal, amelyekre sohasem fogunk keresni. A keresés eredménye általában nem egyetlen dokumentum, hanem egy találati halmaz, amely azokból a dokumentumokból áll, amelyek az igényeinket kielégítik, és egy statisztika, ami azt mondja meg, hogy ez a halmaz hányelemű. Ha ez a szám túl nagy, akkor általában nem akarjuk megnézni az összes ilyen dokumentumot, hanem folytatva a keresést leszűkítjük a találati halmazt egy ésszerű és már végignézhető méretűre. A megtalált dokumentumokat aztán további feldolgozásnak vethetjük alá, elolvashatjuk, kinyomtathatjuk, részleteket ragadhatunk ki belőlük stb., de a fő cél a keresés, a konkrét információ megtalálása. A felhasználó tisztában van azzal, hogy egy adatbázissal áll szemben, és magára az információra van szüksége.
Külön is kiemeljük az alkalmazások fenti felsorolásából az iratraktárakat. Régi gyakorlat, hogy a hivatalos levelezéseket, iratokat egy bizonyos meghatározott ideig (pl. 5 év) nem szabad megsemmisíteni, hanem tárolni kell. Ezeket az iratokat a gyakorlatban szinte soha senki nem kereste többet elő, mert még ha szükség lett volna is rájuk, az előkeresés annyi időt vett volna igénybe, hogy inkább újra írták, újra fogalmazták őket. Ma, amikor a szöveges információk nagy része elektronikusan kerül rögzítésre, kézenfekvő ezeket elektronikus irattárakban “raktározni”. Különösen alkalmasak erre a szöveges adatbázisok, hiszen az így tárolt információ nem holt anyag, hanem könnyen lehet tájékozódni benne. A tárolás automatizálható, a szövegeket nem kell semmiféle “utókezelés”-nek alávetni ahhoz, hogy az adatbázisba betöltsük. Az adatbázisba való bekerülésük időpontját is automatikusan feljegyezhetjük, megkönnyítve ezzel a selejtezést.

Mire nem való a szöveges adatbázis?

Ezt a kérdést nem kívánjuk túlságosan részletezni, csak a két leggyakoribb félreértést szeretnénk eloszlatni.

  • A szöveges adatbázisok nem alkalmasak gyorsan és gyakran változó adatok tárolására.
  • A szöveges adatbázisokban tárolt numerikus adatokkal nehézkes dolog számításokat végezni.

A szöveges adatbázis-kezelésben használt terminológia

A korábbiakban már találkoztunk a szöveges adatbáziskezelés egyik legfontosabb fogalmával, a dokumentummal. Ez, mint már említettük, a hagyományos adatbázisok rekord fogalmának feleltethető meg. A dokumentumnak nem kell struktúrával, szerkezettel rendelkeznie, de ha mégis rendelkezik ilyennel, akkor ezt megőrizve az adatbázisban, megkönnyíthetjük az adatok közötti tájékozódást. Minél többet tudunk egy dokumentumról, annál hamarabb találjuk meg az adatbázisban.
Egy dokumentum különbözd paragrafusokból állhat. A paragrafus a hagyományos adatbázisok mező fogalmára emlékeztet leginkább, de a paragrafusok is további részekből – mondatokból – állhatnak. A mondatok építőkövei pedig a szavak.
A szerkezet szerepe a keresésben azért fontos, mert segítségével a keresési lehetőségek nagy gazdagságát biztosíthatjuk, és csökkenthetjük egy-egy konkrét dokumentum előkeresésének az idejét.
Az előzőkben már említettük a keresés fogalmát. Úgy gondoljuk, hogy maga a fogalom nem szorul további magyarázatra, de azt, hogy ezt miként hajtjuk végre szöveges adatbázisok esetén, talán nem árt részletezni. A kereséseket az adatbázis-kezelő speciális nyelvén kell megfogalmazni, de a beszélt nyelvre ezeket átültetve ilyen és ehhez hasonló utasításokat adunk a rendszernek:
“Keresd elő azokat a dokumentumokat, amelyek ezeket és ezeket a szavakat ilyen és ilyen környezetben tartalmazzák!”
A keresés eredménye egy úgynevezett találati halmaz és egy találati statisztika. A statisztika számszerű információ arról, hogy a keresésben megfogalmazott feltételeknek hány dokumentum felel meg az adatbázisban, illetve mennyi a konkrét találatok száma. Találatnak nevezzük a keresett szavak tényleges előfordulását. A találati halmaz pedig a megtalált dokumentumokból áll.
Azt mondjuk, hogy egy keresés egy másik keresésnek szűkítése, hogyha csak annak a találati halmazára korlátozódik. Tehát nem a teljes adatbázisban keresünk tovább, hanem csak egy előző keresés találati halmazában.

Egy konkrét szöveges adatbázis-kezelő rendszer, a BRS/SEARCH

A következőkben egy korszerű, és Magyarországon újnak számító szöveges adatbázis-kezelő rendszerrel, a szöveges adatbázis-kezelők világában BRS/Search néven elterjedt szoftverrel ismerkedünk meg röviden.
A rendszer a BRS Software Products angol-amerikai érdekeltségű cég terméke, magyarországi terjesztője pedig az MTA SZTAKI ASZI. A forgalmazással 1991 nyara óta foglalkozunk. A terjesztés mellett a felhasználói igényeknek megfelelően kisebb-nagyobb fejlesztéseket is végzünk. Ezek elsősorban a rendszer magyarítását, szövegszerkesztő programok illesztését, adatbázisok kialakítását, más – korábban már feltöltött – adatbázisok adatainak konvertálását és betöltését, speciális igények kielégítését, új megoldások keresését célozzák.
A szoftvert C nyelven írták, ezért gyakorlatilag bármilyen számítógépen és bármilyen operációs rendszer alatt elérhető.
Nézzük meg, hogy a BRS/Search milyen sajátosságokkal rendelkezik! Ezt fogjuk most röviden áttekinteni.

Dokumentumok létrehozása, betöltése, tárolása

A dokumentumokat a BRS/Search számára gyakorlatilag tetszőleges szövegszerkesztő programmal hozhatjuk létre. Számos szövegszerkesztő illesztése már megtörtént, de egy új illesztése is csak ritkán jelent a rutin feladatokon túlmenő problémákat. Említettük, hogy a dokumentumoknak nem kell struktúrával rendelkezniük, de ha rendelkeznek ilyennel, az előnyt jelent a keresések szempontjából. Ha a dokumentumaink szerkezetéből származó előnyöket ki szeretnénk használni, akkor a szerkezetet a BRS/Search számára felismerhetővé kell tennünk. Ezt úgy tehetjük meg, hogy a paragrafusok elejére úgynevezett input címkéket – az adatbázis definiálásakor meghatározott speciális és máshol elő nem forduló karaktersorozatokat – helyezünk el.
A BRS/Search képes arra, hogy tárolja az egyes szövegszerkesztők speciális formázó, tipografikus információit is olyan módon, hogy azok a keresést nem befolyásolják. Csak akkor válnak láthatóvá, ha azt a felhasználó kifejezetten kéri, de az adatbázisból a dokumentummal együtt ezek is tökéletesen visszanyerhetők.
A dokumentumok betöltése alapvetően off-line módon, egy speciális program segítségével történik. Ez viszonylag időigényes művelet, hiszen minden egyes szót fel kell venni a szótárba. Ilyenkor épül fel az adatbázis, és ekkor alakul ki az a bonyolult fájl-struktúra, ami aztán lehetővé teszi azt a lenyűgözően gyors keresést, ami a BRS/Search sajátja.
Tárolásra kerül maga a szöveg az eredeti formájában, és készül hozzá egy szótár, amelybe nemcsak a szavak kerülnek be, hanem az összes előfordulásuk helye is (mely dokumentumok mely paragrafusaiban, azon belül mely mondatok hányadik szava). A szöveg tárolása tömörítve történik, amivel jelentős hely takarítható meg, másrészt viszont az így tárolt szöveg illetéktelenek számára gyakorlatilag olvashatatlan a szokásos szerviz programok (DITTO, PCTOOLS, PCSHELL stb.) segítségével.
A dokumentumok méretét tulajdonképpen csak az adatbázis számára rendelkezésre álló lemezterület korlátozza.

Keresések, keresési stratégiák

Röviden áttekintjük azt, hogy milyen lehetőségeket nyújt a BRS/Search a tárolt dokumentumok előkeresésére. Megjegyezzük, hogy ezek a lehetőségek eléggé szokásosak hasonló célú szoftverek esetén, a BRS/Search rendszert elsősorban a keresések végrehajtásának gyorsasága tünteti ki ezek közül.
A keresések alapja az egyes szavak keresése. Egy-egy konkrét szót megadva, megkapjuk az azok előfordulásához tartozó információkat (találati statisztikákat és a találati halmazt). Nemcsak teljes szót kereshetünk, hanem kereshetünk szótőt (jobbról csonkolt szót), és amennyiben az adatbázishoz felépítjük az úgynevezett fordított indexet, akkor szóvégződést (balról csonkolt szót) is, sőt a csonkolás állhat a szó közepén is. Dzsóker karakterek használata segíti a bonyolultabb keresések megfogalmazását.
Kereshetjük több szó együttes előfordulását vagy a felsorolt szavak bármelyikének az előfordulását. Együttes előfordulás esetén azt is előírhatjuk, hogy a szavak legfeljebb milyen távolságra lehetnek egymástól, vagy hogy ugyanabban a paragrafusban vagy ugyanabban a mondatban kell szerepelniük, sorrendjük kötött vagy közömbös. A szokásos logikai kifejezésekhez hasonlóan bonyolult (zárójeles) kereséseket is használhatunk.
Mód van numerikus keresésekre is. Ha a dokumentumok numerikus adatokat is tartalmaznak, és ezt az adatbázis definiálásakor megmondjuk, akkor kereshetünk megadott konkrét numerikus értékekre, illetve egy megadott értéknél kisebb, nagyobb stb. értékekre is egy tetszőleges szövegrészen belül.
A kereséseket korlátozhatjuk bizonyos paragrafusokra, ha a keresett szavaknak csak bizonyos paragrafusokban való előfordulásaira vagyunk kíváncsiak. Itt látszik az előnye annak, ha a dokumentumoknak struktúrája van (paragrafusokra tagolható).
Az egymás utáni kereséseket a rendszer automatikusan sorszámmal látja el. A sorszámok segítségével lehetőség nyílik korábbi keresésekre való visszahivatkozásra, korábbi keresések megismétlésére, kibővítésére, leszűkítésére anélkül, hogy azokat újra teljes részletességgel meg kellene adni. Ha előre tudjuk, hogy egy idő után a kereséseink egymás szűkítései, akkor ezt megmondhatjuk a rendszernek és ezzel a visszahivatkozást is megtakaríthatjuk.
Belenézhetünk a szótárba is. Megadva egy szót, kiírathatjuk a szótárnak azt a részét, amelyik a megadott szó után következik. Kiírathatjuk egy szó környezetét (néhány megelőző, illetve következő szó), vagy egy megadott szótővel kezdődő, illetve végződő összes szót.
A gyakran használt kereséseket és kereséssorozatokat megőrizhetjük lemezre mentve, és később tetszés szerint aktivizálhatjuk anélkül, hogy újra pontosan megadnánk őket.

A dokumentumok megtekintése, kiíratása

Amikor a találati halmazunkat már ésszerűen kicsi méretűre sikerült lecsökkentenünk, akkor általában megtekintjük a kiválasztott dokumentumokat. Vagy azért, mert valóban a tartalmuk érdekel bennünket, vagy azért, mert már nincs más mód a keresett dokumentumok kiválasztására. Szükség lehet a megtalált dokumentumok kinyomtatására is.
Nem biztos azonban, hogy valóban a teljes találati halmazra vagy a teljes dokumentumra van szükségünk. Akkor viszont a felesleges információ miért foglaljon helyet a képernyőn, vagy miért fogyasszuk vele a papírt, ha a dokumentumot kinyomtatjuk? Ez a kényelmetlenség elkerülhető mindkét esetben.
A képernyőn való megjelenítésnek nagy gazdagságát kínálja a BRS/Search. Lehetőségünk van a találati halmazból válogatni (sorszám alapján, első néhány, utolsó néhány stb.), rendezhetjük a dokumentumokat megjelenítés előtt bizonyos paragrafusaik alapján, de lehetőségünk van egy dokumentumon belül is csak a tényleges találatokat (a keresett szavakat és az előfordulások szűkebb szövegkörnyezetét) megtekinteni. A találatok a képernyőn kiemelten (más színnel, vagy fényesebben) is megjeleníthetőek. Korlátozhatjuk a kiírást paragrafusokra is.
A dokumentumok megjelenítésének legtágabb lehetőségeit mind képernyő, mind pedig nyomtató esetén az úgynevezett formátum leíró nyelv biztosítja. Ennek segítségével előre definiálhatunk formátumokat, és a kiírás pillanatában választhatunk belőlük a konkrét igényünknek megfelelően. A kiírásra kerülő dokumentumot átrendezhetjük, kivághatunk belőle részleteket, kiegészíthetjük stb.
A nyomtatásra szánt dokumentumokat lemezre is írhatjuk.

Felhasználói felületek

A BRS/Search bizonyos felhasználói felületeket (interface) készen szállít minden rendszerhez, de lehetőséget ad a felhasználóknak is további ilyen felületek írására, a minél több komfortot biztosító alkalmazások készítéséhez. Ezek segítségével speciális feladatok esetén eltakarhatjuk a felhasználó elől magát az adatbázis-kezelő rendszert, és a saját fogalmaival, saját eszközeivel dolgozva élvezheti a szöveges adatbázis előnyeit.
A készen szállított felhasználói felületek közül elsőként említjük az úgynevezett natív módú felületet. Ez a legáltalánosabb és éppen ezért a legkevésbé kényelmes, viszont ennek segítségével a rendszer minden szolgáltatása elérhető. A tapasztalatok azt mutatják, hogy minden kényelmetlensége ellenére a felhasználók könnyen és szívesen tanulják meg. A nyelve tulajdonképpen a logikai operátorok nyelve, ami ma már széles körben ismert, és az emberek nem idegenkednek tőle.
Új felhasználói felületek írására két eszközt ad a BRS/Search. Az egyik könnyebben tanulható (dBase szerű, de annál egyszerűbb) programozási nyelv az MNS. Ezen menüket írhatunk a képernyőt soros módon használva a BRS/Search “meghajtására”. A másik eszköz egy C nyelvű rutingyűjtemény, amelynek a segítségével a C nyelvet ismerők szinte tetszőleges felhasználói felületeket gyárthatnak.
Mintegy példaként az eszközök bemutatására, készen szállítanak egy MNS-ben írott (Search Mate) és egy ablakos technikát alkalmazó C nyelven írott felhasználói felületet (BrsViews). Jellemzőjük, hogy általános felhasználásra készültek, kényelmesebbek a natív módú felületnél, de nem érhető el rajtuk keresztül minden szolgáltatás. Használatukat “help” is támogatja.

BRS/Search magyar nyelven

A BRS/Search nagy mértékben támogatja a termék nemzeti változatainak létrehozását. Most ezeket soroljuk fel röviden.
A rendszer üzeneteit külön fájlok tartalmazzák, így ezek össze vannak gyűjtve egy helyen, viszonylag könnyű a lefordításuk.
Definiálni lehet a szövegekben használt karakterkészletet. Nemcsak magukat a karaktereket, hanem azok sorrendjét és a kisbetű-nagybetű párokat is megadhatjuk, így a rendezés a nemzeti abc-k sorrendjében történik.
Maguk a natív módú felhasználói felület parancsai is nemzeti nyelvűre cserélhetők, bár ez nem szokásos.
Egyéb szolgáltatások
Itt kívánjuk felsorolni azokat a kiegészítő szolgáltatásokat, amelyekkel a BRS/Search tovább szélesíti a szöveges adatbáziskezelő nyújtotta lehetőségeket, vagy növeli a kényelmet.
A natív módú felhasználói felület parancsainak felhasználásával paraméterezhető eljárásokat írhatunk, amelyeket lemez fájlokban tárolva bármikor végrehajthatunk. A gyakran megismételendő parancssorozatokat ilyen módon nem  kell mindig újra beírni.
Bizonyos funkciókat a klaviatúra egyes billentyűire programozhatunk, meggyorsítva ezzel végrehajtásukat.
Külön említést érdemel a tezaurusz. Ebben fogalmak kapcsolatait tárolhatjuk (szűkebb, tágabb, rokon fogalom, szinonima, rövidítés stb.), és egy-egy fogalommal együtt azok kiválasztott kapcsolatait is kereshetjük. Tetszőlegesen sok tezauruszunk lehet. Azt, hogy éppen melyiket kívánjuk használni, elegendő a keresést megelőzően kijelölni.
Adatbázisok konkatenálásával több adatbázis együttesét egyetlen adatbázisként kezelhetjük. A konkatenáláshoz nem szükséges az, hogy a részek felépítése megegyező legyen.

A BRS/Search és az ISIS

Nem kívánjuk összehasonlítani a BRS/Search rendszert más, hasonló célú szoftverekkel, pusztán az ISIS-szel teszünk kivételt, mert számos igény jelentkezett már eddig is adatbázisok átkonvertálására ISIS-ből. Mindenekelőtt hangsúlyozni szeretnénk, hogy a CDS/ISIS-rál van szó.
Az ISIS fejlesztése gyakorlatilag megszűnt, ezzel szemben a BRS/Search ma is fejlesztés alatt áll, és nagyjából évente új változat kerül a piacra. Ezek az új változatok nemcsak a korábban kiderített esetleges hibák javításait tartalmazzák, hanem az összegyűjtött felhasználói igények minél teljesebb kielégítését is.
Az ISIS-ben a dokumentumok mérete erősen korlátozott (8000 karakter), míg a BRS/Search-ben gyakorlatilag nincsenek korlátok, akár egy teljes kötet regény is lehet egyetlen dokumentum. (Pl.. Márai S.: Egy polgár vallomásai).
Míg a BRS/Search gyakorlatilag teljesen magyarítható (tetszőleges nyelven hozhatunk létre adatbázisokat, definiálhatjuk a karakterek rendezési sorrendjét, a felhasználói felületek üzeneteit lefordíthatjuk), addig ISIS alatt hozzáférhető ugyan egy magyar nyelvű felhasználói felület, de a karakterek rendezési sorrendje nem írható elő.
A tezaurusz funkciók és a tárolt kereső eljárások végrehajtása ISIS alatt csak teljes képernyős (full-screen) terminálról kezdeményezhető, míg a BRS/Search ugyanezt sormódú és teljes képernyős terminálok esetén egyaránt támogatja.
A BRS/Search-nek fejlettebb a formátum leíró nyelve, amellyel rugalmasabban alakítható a dokumentumok megjelentetése. Rövidebbek az egy-egy dokumentum előkereséséhez szükséges keresési idők. Fejlettebbek a numerikus funkciók. Felhasználónként eltérő terminál és nyomtató típus definiálható a karakterek változatlan megjelentetésével. Az ISIS-nek nincsen programozható felhasználói felülete, míg a BRS/Search-nek kettő is van. A BRS/Search felhasználói csoportonként eltérő privilégiumok (hozzáférési jogok) megadását teszi lehetővé, és módot ad a dokumentum szintű titkosításra.
Mindezek az előnyök indokolttá teszik az adatbázisok átállítását ISIS-ből BRS/Search-re.