Diederick de Vries. qbe4or. Automatisch genereren van dynamische Query-By-Example-forms voor Object-Relationele databases

Transcriptie

1 Diederick de Vries qbe4or Automatisch genereren van dynamische Query-By-Example-forms voor Object-Relationele databases afstudeerscriptie informatiekunde begeleiders: dr. H. Klein en drs. H.W.A.E. Kuipers Groningen,

2

3 Inhoudsopgave Inhoudsopgave Voorwoord...iii 1. Inleiding Inleiding Probleemstelling Hoofdvraag Doelstelling Samenvatting Verder onderzoek Vergelijkbare systemen Het belang van een gebruiksvriendelijke zoekinterface Het uitgebreide zoekveld Query-By-Templates Vijfde-generatietalen Query-by-Example Het systeem Voor- en nadelen Recente closed-source toepassingen Conclusie Het object-relationele model OR versus traditioneel-relationeel Situation-based OR Complexiteit Active-flags en start- en eind-data Termen Conclusie De database Het model Relaties Conclusie Het bevragen van een ORDB in SQL Een tabel opvragen De objecten van een type en zijn subtypen Toegepaste attributen van een bekend object en zijn supertypen Niet-geldende data Nut en bruikbaarheid van MySQL-variabelen bij OR Het opbouwen van de tabel Associaties van een bekend object i

4 qbe4or 6.8 Conclusie qbe4or Het systeem Het algoritme voor de interface De navigatieboom De QBE-tabel De filters Conclusie Conclusies Algemene conclusies Problemen en oplossingen Gehaalde en niet-gehaalde doelstellingen Bibliografie Bijlagen SQL: de DDL-statements van het datamodel PHP: genereren van een HTML-tabel met objecten, hun attributen en QBE-invoervelden PHP: de navigatieboom PHP: Functiebibliotheek voor de navigatieboom PHP: functies voor hierarchie uit de functiebibliotheek voor MySQL-gebruik PHP: functies voor het tonen van de tabel ii

5 qbe4or Voorwoord Bij een van de eerste afspraken die ik met mijn afstudeerbegeleider had, vroeg hij mij waarom ik wilde afstuderen. Het toeval wilde dat ik daar daadwerkelijk over had nagedacht. Alfa-informatica is niet de eerste studie die ik geprobeerd heb. Sociale geografie, hoofdvak viool aan het conservatorium en geschiedenis gingen eraan vooraf. De studie is wel de eerste die ik heb afgemaakt, en dat vervult mij uiteraard met een zekere mate van voldoening. Maar onzeker als ik lange tijd was over of ik dit keer wel de juiste keuze had gemaakt, heb ik halvewege de studie al een stage gedaan, en niet, zoals te doen gebruikelijk, pas na afloop. Die stage overtuigde mij ervan dat ik softwareontwikkeling leuk vond en dat ik dus zou moeten afstuderen. Nu ik deze afstudeerscriptie af heb, besef ik dat het een van de laatste zal zijn die aan de Rijksuniversiteit Groningen geproduceerd zullen worden. Vanaf dit jaar heten ze namelijk in toenemende mate master-thesis. Voor die term had ik ook kunnen kiezen, maar dat deed ik niet. Als beloning voor die behoudendheid krijg ik twee titels, zowel de Nederlandse als de Europese. En dat is ook wat mijn afstudeerbegeleider bedoelde met zijn vraag. Want tegelijk met de overgang naar dit Europese titulatuursysteem kwam ook de mogelijkheid om na slechts drie jaar de studie af te breken en toch met een titel, die van bachelor, de arbeidsmarkt op te gaan. Bedanken wil ik in de eerste plaats mijn al genoemde begeleider, drs. Edwin Kuipers, voor zijn raad en zijn geduld voor mij, in wat voor hem drukke tijden moeten zijn geweest. Ook Dr. Henny Klein, mijn tweede lezer, die mij vooral in de onderzoeksfase hielp bij het zoekwerk en die, zoals ik af en toe aan de log van mijn webserver kon zien, de pieken en dalen van mijn vorderingen gadesloeg. Ook Dr. Alessandro Allodi, mijn stagebegeider, wil ik bedanken omdat hij mij geleerd heeft wat OR is. Ook moet ik mijn vriendin Klazina Botke bedanken, onder andere voor de door haar ontwikkelde alfa-informatica-implementatie van het kunstgeschiedenis-annotatiesysteem. iii

6

7 1. Inleiding 1. Inleiding 1.1 Inleiding In het najaar van 2001 deed ik een stage bij de Nederlandse Aardolie Maatschappij (N.A.M.) te Assen, onder leiding van voormalig alfa-informatica stafmedewerker dr. Allesandro Allodi. Onderwerp van deze stage was het object-relationele datamodel (ORDB). Dit zeer krachtige model werd binnen de N.A.M. naar mijn mening onvoldoende uitgebuit. Door de complexiteit van het model is er een grote mate van deskundigheid nodig om queries te formuleren. Deze deskundigheid was bij de meeste gebruikers van de database niet aanwezig. Dit resulteerde bij de N.A.M. in een gebruik van de database die beperkt bleef tot een aantal vooraf door Allodi zelf geformuleerde queries, in een web-gebaseerde interface. Een systeem dat de gebruikers in staat stelde zelf queries te formuleren bestond niet. Om een database volledig te benutten is het echter nodig om deze mogelijkheid wel te bieden. 1.2 Probleemstelling Databases worden bevraagd met behulp van formele talen, meestal Structured Query Language (SQL). Het aanleren van deze, of andere formele talen, is voor gebruikers van een database niet mogelijk, aangezien zij daar de tijd en de expertise voor missen. Het is daarom voor normaal gebruik van elke database noodzakelijk een systeem te ontwikkelen waarin een gebruiker om informatie kan vragen zonder daarbij kennis te hoeven hebben van formele vraagtalen. Het object-reationele datamodel is bovendien dermate complex, dat het bevragen van een database die volgens dat model is opgezet, een bovengemiddeld gedegen kennis van SQL vereist. Beide feiten samen maken een gebruikersvriendelijke interface noodzakelijk voor het werken met een ORDB, voor iedereen behalve degene die zeer goed bekend is met het datamodel. Het is dus noodzakelijk een interface te ontwikkelen waarin de gebruiker zonder gebruik van een formele taal, en zonder te maken te hebben met de stuctuur van het datamodel, queries kan formuleren. Dit kan met behulp van een formulier. De in een dergelijk systeem opgestelde query moet vervolgens door dat systeem worden omgezet in een SQL-query, waarmee de database bevraagd wordt. De hierdoor verkregen resultaten moeten daarna aan de gebruiker worden getoond, opnieuw zonder dat hij daarbij te maken krijgt met de structuur van het datamodel. Er zijn verschillende interfacetypen die hiervoor in aanmerking kunnen komen. 1. Het uitgebreide enkele zoekveld, zoals bekend van geavanceerde zoekmachines als Google, Altavista en Yahoo. Het geven van een zoekopdracht gebeurt hier door het simpleweg invullen van een enkele zoekterm of een booleaanse expressie. Deze expressie wordt vergeleken met de in de database aanwezige gegevens, en treffers worden na afloop getoond. Deze methode is zeer ruw, aangezien op geen manier kan worden aangegeven wat de betekenis is van de expressie in de gezochte documenten. Het resultaat is bekend bij elke intensieve internetgebruiker: veel treffers waartussen weinig bruikbaars zit. 2. Query By Example (QBE) is een querytechniek die al bestaat sinds de jaren '70. Hierbij krijgt de gebruiker een formulier te zien waarin een blanco record wordt getoond. Hij kan hierin conditities aangeven waarin de gezochte records dienen te voldoen. Dit is eenvoudiger in het gebruik dan SQL. QBE refers to a method of forming queries in which the database program displays a blank record with a space for each field. You can then enter conditions for each field that you want to be included in the query (...). 5

8 qbe4or QBE systems are considered easier to learn than formal query languages. 1 The philosphy of QBE is to require the user to know very little in order to get started and to minimize the number of concepts that he subsequently has to learn in order to understand and use the whole language Vijfde-generatietalen zoals Microsoft English Query 3 en Esperanr 4 maken, op verschillende manieren, gebruik van natuurlijke taal als Engels om de gebruiker queries te laten formuleren. Een ingevoerde volzin wordt vertaald naar SQL om de gezochte gegevens uit de database te halen. Echter: de praktische toepasbaarheid van natuurlijke taal-interfaces vereist dat niet alleen zinnen worden geaccepteerd die voldoen aan alle regels van het systeem. Een gebruiker (...) zal vroeger of later uitingen produceren die bij de ontwikkeling van het systeem niet voorzien zijn Query by Templates (QBT) in een type QBE dat de daadwerkelijke layout van in de database aanwezige documenten neemt, waarin op bepaalde plaatsen zoekcriteria kunnen worden ingevuld, bijvoorbeeld op de plaats waar de auteur, titel of ondertitel staan. Alle aan de criteria beantwoordende documenten zullen tot de treffers behoren. 6 Voorwaarde hiervoor is dat de database gevuld is met tekstdocumenten die dezelfde layout hebben. Query-formulieren hebben ook een nadeel: for each and every query a separate fill-out form needs to be made. 7 Dit nadeel is te omzeilen door het opbouwen van het formulier door het systeem te laten doen. De vraag welke van de genoemde interfacemethoden het meest geschikt is voor het oplossen van het gestelde probleem is een onderzoek op zich, waarop ik mij niet wil richten. Voor mijn onderzoek gebruik ik QBE omdat dit zoals gezegd robuust en gebruikersvriendelijk is, en niet te specifiek in de eisen aan de gezochte gegevens, zoals QBT. Wel zal ik in hoofdstuk twee verder ingaan op de hier behandelde systemen om te kijken wat daaruit van nut kan zijn voor qbe4or. 1.3 Hoofdvraag Het bovenstaande leidt mij tot de hoofdvraag van mijn onderzoek: Is het mogelijk om een zoekinterface te ontwikkelen die gegevens uit een object-relationele database weet te halen, volgens het Query-By-Example (QBE) interface-model? Hieruit moeten de volgende termen worden gedefinieerd: 1. zoekinterface: een aan een gebruiker gepresenteerd scherm waarin hij een zoekopdracht kan specificeren die hem een door een onderliggend database-systeem opgebouwd antwoord zal opleveren. 2. object-relationele database (ORDB): een systeem waarin gegevens opgeslagen liggen, gestructureerd volgens een principe waarbij de object-georiënteerde databaseprincipes worden gerealiseerd binnen een relationele engine. 3. Query-By-Example (QBE): een zoekinterface-model dat de gebruiker aan de hand van een database een voorbeeld-query aanbiedt waaruit hij zijn eigen query kan samenstellen Deelvragen Om de hoofdvraag te kunnen beantwoorden moeten onderstaande vragen worden beantwoordt: 1 Webopedia, lemma query-by-example 2 Zloof, `Query-by-Example: a data base language', Microsoft TechNet, Developing with English Query. 4 Speedware Esperant: Enterprise-wide, multi-database Query and Reporting keeps your business on target 5 Bouma, Computationele Taalkunde en Taaltechnologie, 10 6 Sengupta en Dillon: `Query By Templates: A Generalized Approach for Visual Query Formulation for Text Dominated Databases' 7 Gree, de, Generating Web Query Interfaces Based on Conceptual Schemas, 58 6

9 1. Aan welke eisen moet een dergelijk systeem minimaal voldoen? 1. Inleiding 2. Bestaat er al een systeem dat aan de genoemde specificaties voldoet en kan dit worden hergebruikt? 3. Welke problemen zijn anderen tegengekomen bij het ontwikkelen van een dergelijk systeem? 1.4 Doelstelling Om de hoofdvraag te beantwoorden dient te worden vastgesteld onder welke omstandigheden geconcludeerd kan worden dat deze mogelijkheid bestaat. Het systeem moet een QBE-interface presenteren aan de gebruiker, waarmee deze zijn query kan formuleren. Vervolgens moet deze query worden vertaald naar SQL en worden doorgegeven aan de SQL-engine. De aldus verkregen gegevens moeten in de vorm van een tabel aan de gebruiker worden gepresenteerd. De volgende punten zijn minimale functionaliteit: 1. zoeken naar in de database aanwezige gegevens; 2. negeren ongeldige data: in een ORDB is data al dan niet geldig, hetzij doordat een record is gemarkeerd als ongeldig in een specifiek veld, hetzij doordat de tijd waarin de data geldig is, aangegeven in twee datumvelden, is verlopen. Voor meer informatie hierover verwijs is u naar hoofdstuk twee; 3. overerving: in een ORDB is het mogelijk een domein te specificeren waarin de daarin aanwezige objecten elkaars eigenschappen overnemen 8. Dit heet overerving. Voor meer informatie hierover verwijs ik u naar hoofdstuk twee. Wanneer het systeem deze eigenschappen heeft kan de hoofdvraag bevestigend worden beantwoord. Bij de ontwikkeling verwacht ik twee technische moeilijkheden tegen te komen: 1. het automatische onderzoek naar de zogenaamde metadata, de gegevens in de database die slechts de structuur beschrijven waarmee de daadwerkelijke gegevens zijn vastgelegd, volgens welke de QBEinterface moet worden opgesteld; 2. de vertaling: de object-georiënteerde aard van de database maakt dat SQL-queries veel complexer zijn dan bij een traditionele relationele database. Om een voorbeeld te geven: bij een traditioneel-relationele database hoeft er, om de schrijver van een boek op te zoeken, alleen te worden gezocht naar het boek, op basis van bijvoorbeeld de titel, of een andere bekende eigenschap. Daarna is ook de schrijver bekend. Bij een object-georiënteerde database zal moeten worden vastgesteld dat er twee objecttypen zijn, namelijk `boek' en `schrijver', waarvan de instanties, `dit specifieke boek' en `deze specifieke schrijver', een relatie met elkaar hebben. Deze heet bijvoorbeeld `is geschreven door' voor de ene richting en `heeft geschreven' voor de andere richting. Ook heeft het objecttype `boek' eigenschappen: het boek zal moeten worden geïdentificeerd via de eigenschap `titel' `Nice-to-haves' Het zou wenselijk zijn daaraan de volgende zaken toe te voegen: 1. zoeken naar meta-gegevens; 2. naar keuze doorzoeken inactieve data; 3. caching; 4. door de gebruiker aanpasbare interface. Deze punten zijn echter van minder belang voor het afstudeeronderzoek zelf. Bij de N.A.M. werden de verschillende informatiesystemen via webpagina's op het lokale intranet aan de verschillende afdelingen en hun medewerkers aangeboden. Deze manier heeft daar aangetoond goed te werken. Daarom ligt het voor de hand om de interface als webpagina te ontwikkelen. Op die manier kan het 8 Fussell, Foundations of Relatuinal Mapping, 13 7

10 qbe4or eenvoudig via HTTP door iedereen worden geraadpleegd. Om het systeem te kunnen testen zal er een ORDB nodig zijn. Als engine daarvoor wil ik MySQL gebruiken, een goed presterende, wijd verbreide open-source database 9. De nieuwste stabiele versie is alpha. Die versie zal ik gebruiken. De taal ik gebruik om het systeem te maken is PHP. Deze embedded scripttaal bezit genoeg functionaliteit op het gebied van de communicatie met MySQL om het systeem in te kunnen ontwikkelen 10. Momenteel bevindt versie 5 zich nog in het bèta-stadium 11, dus ik gebruik versie 4. Deze maakt gebruik van de Zend engine versie 1, waarin object-georiënteerd programmeren nog niet volledig ondersteund wordt 12. qbe4or zal ik dus volledig functioneel programmeren. Voor het beantwoorden van de hoofdvraag heeft dit geen concequenties. Zoals aangegeven draait het onderzoek voornamelijk om de vraag in hoeverre het mogelijk is een dergelijk systeem te bouwen. Aangezien het systeem daarom niet meer dan een prototype van een reëel systeem hoeft te worden is het niet wenselijk om de database te vullen met relevante data als documenten of andere media. Dit is voor het onderzoek niet relevant en maakt de zaak nodeloos ingewikkeld. Ik wil daarom de testdatabase populeren met de hemellichamen uit ons zonnestelsel. Dit is een complex geheel van sterren, planeten, zonnen, asteroïden, kometen, nevels en kunstmatige structuren met vele onderlinge relaties en gemeenschappelijke eigenschappen, wat het ideaal maakt om in een ORDB te beschrijven. Een voorbeeld van wat het uiteindelijke systeem zou moeten opleveren is het volgende. Meestal weet degene die de zoekopdracht geeft een bepaalde eigenschap van datgene waar hij naar zoekt. Bij een boek is dat bijvoorbeeld een titel of een auteur. In een ORDB kunnen beide zowel objecten zijn als attributen. In een traditioneel systeem bestaat dat onderscheid niet. De gebruiker zal een menu zien waaruit hij een schrijver kan kiezen en een waarmee hij uit boektitels kan kiezen. Maakt hij gebruik van het eerste, dan zal hij een lijst krijgen van alles wat bij die schrijver hoort, oftewel alle boeken, in het tweede geval alles wat bij die boektitel hoort, oftewel wie eraan geschreven hebben, hoeveel het kost, enzovoort. In het geval van het zonnestelsel zoekt de gebruiker bijvoorbeeld naar alle rotsplaneten, of alle met een atmosfeer waarin argon voorkomt. Het systeem moet dezelfde menu's aanbieden, en dezelfde resultaten geven. Met een menu moet gekozen kunnen worden uit de beschikbare objecten, met een ander uit de gebruikte attributen. Uit hoe meer menu's een keuze wordt gemaakt, hoe groter de precisie van de zoekopdracht wordt. Een zoekopdracht waarbij eigenschappen zijn opgegeven, moet een lijst opleveren waarbij deze eigenschappen overeenkomen met de opgegeven waarden, of die in de database nu als objecten, als attributen, of als associaties zijn gedefinieerd. 1.5 Samenvatting Het gegeven dat databases moeten worden bevraagd met behulp van formele talen, gecombineerd met de grote ingewikkeldheid van het object-relationele datamodel, maakt dat een gebruikersvriendelijke zoekinterface noodzakelijk is voor een optimaal gebruik van ORDBs. In deze scriptie wil ik onderzoeken of het mogelijk is een QBE-interface te ontwikkelen voor dat type database. Deze interface moet de gebruiker een formulier presenteren dat is opgebouwd aan de hand van de aanwezige database en de mogelijkheid geven een query te formuleren, zonder dat hij kennis heeft van formele vraagtalen of het gebruikte datamodel. 1.6 Verder onderzoek Wanneer de eerder in dit hoofdstuk gedefinieerde hoofdvraag positief kan worden beantwoord, kan het onderzoek nog worden voorgezet. De voor dit onderzoek gebruikte testdatabase is vrij klein en relatief weinig 9 Een uitgebreide vergelijking van de prestaties van deze versie met andere databases is te vinden op 10 Converse en Park, PHP Bible. 2nd edition, Het laatste nieuws over ontwikkelingen op dit gebied is te vinden op 12 Voor een genuanceerde discussie over het gebruik van object-georiënteerde programmeertechnieken in scripttalen in het algemeen en PHP 4 in het bijzonder verwijs ik u graag naar Converse en Park, `PHP Bible. 2nd edition', resp. pagina 526 en

11 1. Inleiding complex. Zo onbreken mogelijkheden tot het specificeren van attributen van attributen en associaties tussen attributen. In theorie kunnen dit soort verbanden tot in het oneindige worden doorgezet. Het is de moeite waard om te kijken in hoeverre qbe4or valt aan te passen voor nog complexere databases. Te verwachten valt echter dat een daaruit voortvloeiende uitbreiding van de QBE-fucntionaliteit ten koste zal gaan van het eenvoud en het comfort van de zoekinterface. De twee niet gehaalde punten in paragraaf zijn de door de gebruiker aanpasbare interface en het naar keuze kunnen zoeken op inactieve gegevens. Dit zijn eenvoudige en voor het onderzoek irrelevante zaken waarvoor verder onderzoek niet nodig is. 9

12

13 2. Vergelijkbare systemen 2. Vergelijkbare systemen 2.1 Het belang van een gebruiksvriendelijke zoekinterface Sinds het verschijnen van het oorspronkelijke artikel over QBE door M.M. Zloof in het IBM Systems Journal in 1977 zijn er talloze zoekinterfaces ontwikkeld in wetenschappelijke en commerciële projecten. `Along with the explosive growth of the Internet, ad hoc query and reporting tools are perhaps the most significant new development in computing of this decade [de jaren '90]. (...) Unfortunately, most of the development effort (...) has been devoted to giving us better report writers, embedded graphics and fancier graphing options. (...) For example, we still lack a reasonable method of creating complex data filters (SQL WHERE clauses) in most of the popular tools.' 13 `In corporate settings, the more information users have to sort through, the longer it takes to find the specific documents they need and the more productivity drops. In the e-commerce environment, if customers cannot find the products they want to buy with their first couple of queries, they will jump from site to site until they come across one where they can.' 14 `Ease of use and user-friendliness often determine whether the database is used. A program will not be used if it is intimidating, is too difficult, or requires too much effort. (...) An effective user interface should not require extensive training to be used easily.' 15 Het is van groot belang dat met behulpt van een een zoekinterface eenvoudig en snel de gewenste resultaten verkregen kunnen worden, of het nu gaat om een publiekelijk toegankelijke database met een web-interface, of een database die in een bedrijfsomgeving geraadpleegd wordt. In beide gevallen betekent het slecht presteren van de interface het verlies van geld, ongeacht de kwaliteit of inhoud van de onderliggende database. Men wil niet alleen zaken kunnen vinden, men wil dat bovendien snel en eenvoudig kunnen doen. `However, this ease of use may require a loss of power and flexibility.' 16 Om het bedieningsgemak van een interface eenvoudig te houden moeten de opdrachten die de gebruiker kan geven beperkt in aantal en complexiteit zijn. Het risico dat men hierbij loopt is dat dit ten koste gaat van de functionaliteit van het het systeem. Aangezien alle bekende publiek toegankelijke algemene zoeksites op het Internet in eerste instantie niet meer aanbieden dan een enkel invoerveld voor enkele zoektermen, zullen de meeste mensen gewend zijn aan dit type zoeken. Deze interfaces leveren niets anders op dan vaak grote lijsten met resutaten. Het blijkt mogelijk de verhouding tussen recall en precision te verbeteren met behulp van methoden als syntactic phrase indexing 17, vectorruimtemodellen 18 of andere statistische methoden 19. Echter: `Most simple search engines trade of precision (...) for recall (...). This is because it is much easier to return exhaustive lists of documents than it is to effectively rank results in terms of relevancy. Faced with this, users often abandon simple searches altogether.' Dorsey, `Ad Hoc Query Tools: Do They Really Support Ad Hoc Querying?' 14 Verity Search: The Advantages of Advanced Informattion Retrieval, 3 15 `Technical Architecture Framework for Information Management (TAFIM)' 16 `Technical Architecture Framework for Information Management (TAFIM)' 17 Pohlman en Kraaij, `The Effect of Syntactic Phrase Indexing on Retrieval Performance for Dutch Texts', 5 18 Joachims, `Text Categorization with Support Vector Machines: Learning with Many Relevant Features', Hull, `Using Statistical Testing in the Evaluation of Retrieval Experiments', Verity Search, 3. 11

14 qbe4or 2.2 Het uitgebreide zoekveld De meest eenvoudige zoekinterface is een enkel veld waarin de gebruiker een term kan invullen die vervolgens wordt vergeleken met de in de database aanwezige gegevens. Komt deze ergens voor dan kan het betreffende object worden vermeld in de resultaatset. Een stap geavanceerder is het mogelijk om deze zoekterm te specificeren met booleaanse of reguliere expressies. Hiermee wordt het mogelijk om in plaats van enkele woorden vaste series of variaties daarvan als zoekterm te gebruiken, andere strings uit te sluiten en naar combinaties ervan te laten zoeken. Op deze manier ontstaat er een veel genuanceerder en krachtiger query waarmee het aantal nuttige treffers kan worden vergroot ten opzichte van het totale aantal treffers. Dit gegeven staat bekend als de recall/precision-verhouding. 21. QBE maakt eveneens gebruik van eenvoudige booleaanse expressies voor het evalueren van gegevens 22. De verschillende velden waaruit deze interface bestaat accepteren als invoer elk apart een dergelijke expressie. Ook voor qbe4or heeft dit zeker nut. De kracht van een filter kan hierdoor sterk vergroot worden. 2.3 Query-By-Templates In het voor databases met alleen tekstdocumenten ontwikkelde Query-by-Templates (QBT) wordt de daadwerkelijke lay-out van de in de database aanwezige documenten genomen als model voor de zoekschermen, de zogenaamde template. Daardoor kan een gebruiker die op titels zoekt zijn zoektermen op de plaats kwijt waar in een echt document de titel zou staan, de zogenaamde regions, of regio's in het Nederlands. Dit heeft gebleken zeer intuitief te werken. Het concept is echter alleen bruikbaar voor tekstdatabases 23. In ieder geval zal het type en aantal attributen van elk object in de database gelijk moeten zijn. Aangezien, zoals in hoofdstuk vier duidelijk zal worden, dit bij OO- en ORDBs niet het geval is komen deze voor een interfacetype als QBT niet in aanmerking, Toch zit er in QBT een voor qbe4or bruikbaar idee. Zoals in hoofdstuk zeven zal blijken moet er in qbe4or een manier aan de gebruiker worden geboden om zich vrijelijk te kunnen bewegen tussen diverse queryinterfaceschermen, die ontstaan vanwege de grote aantallen mogelijke attributen van alle objecttypen samen. QBT kampt met een vergelijkbaar probleem en heeft daar een voor qbe4or bruikbare oplossing voor. QBT bestaat in drie vormen 24 : 1. Flat templates: waarin QBT werkt zoals hierboven beschreven. Alle regio's worden weergegeven in een eenvoudige twee-dimensionale template die exact de layout vaneen typisch document uit de database weergeeft. 2. Nested templates: waarin de regio's zijn opgedeeld in subregio's. Een strofe uit een gedicht bijvoorbeeld kan zo als geheel worden behandeld, waarbij de gebruiker kan zoeken op het voorkomen van zijn zoekterm in de gehele strofe, of per regel apart. In het laatste geval kan hij zoeken naar deze zoekterm in bijvoorbeeld specifiek een bepaalde regel, of naar combinaties van zoektermen in verschillende specifiek aangegeven regels. 3. Structured templates: waarin de gebruiker als het ware kan inzoomen op een regio om deze in meerdere subregio's te verdelen, of uitzoomen om het aantal subregio's weer te verkleinen. Als een document opdeelbaar blijkt in teveel regio's en subregio's, is het vaak niet langer wenselijk om die alle tegelijk weer te geven. De gebruiker krijgt een boomstructuur te zien waarmee hij tussen verschillende niveaus van detaillering van het queryscherm kan navigeren. 21 Su, `The relevance of recall and precision in user evaluation' 22 Zloof, `Query-by-Example', Sengupta en Dillon, `Query By Templates: A Generalized Approach for Visual Query Formulation for Text Dominated Databases ', 1 24 Sengupta en Dillon, `Query By Templates', 5 12

15 2. Vergelijkbare systemen Afbeelding 1. Een QBT queryscherm met navigatieboom Een dergelijke boom is voor qbe4or eveneens goed in te zetten. Hierdoor kan de gebruiker tussen de diverse objecttypen 25 navigeren waarbij het aantal de attributen zal verkleinen naarmate er meer op een object wordt ingezoomd. 2.4 Vijfde-generatietalen Microsoft English Query en Esperant zijn voorbeelden van commerieel ontwikkelde querytalen van wat bij Microsoft zelf de vijfde generatie wordt genoemd 26. Deze talen staan zeer dicht bij de gebruiker, in de zin dat zij de queries in natuurlijk Engels laten stellen. Het is daarna aan het systeem om op basis daarvan een SQLquery te formuleren. Op deze manier proberen zij een extreem hoge gebruiksriendelijkheid te creëeren. Microsoft English Query, een onderdeel van SQL Server 7.0, laat de gebruiker zijn zin helemaal zelf formuleren in een daarvoor bestemd invoerveld. `A lot of people are excited about the English Query capability of SQL Server 7.0. The promise is great, but I'm a bit of a skeptic when it comes to querying. It takes a power user to make queries, because the user needs some understanding of the underlying data structures.' 27 Daarmee lijkt het gebruik van de interface beperkt tot de beheerders van een database, mensen van wie verwacht kan worden dat ze SQL machtig zijn en een dergelijke interface niet nodig hebben. English Query gaat evenwel zelfs nog een stap verder, door de interface te voorzien van een spraakherkenningsmechanisme. 28 Momenteel kan daarbij slechts een beperkt domein aan woorden en zinsconstructies gebruikt worden. Dat betekent dat de gebruiker vooraf moet weten welke dat zijn. Mijns inziens gaat daarmee al een deel van de beoogde gebruiksvriendelijkheid verloren, aangezien hiervoor toch weer een leerproces of handleiding nodig is. Echter: `This type of grammar could be an interim step between context-free and dictation grammar-based applications.' 29 Esperant van Software AG werkt anders. `It doesn't try to accept natural language as input. Instead, it uses a point and click interface (...). The difference is that ESPERANT shows the query in English as it is created using a more or less traditional method.' 30 Op deze manier slaagt het systeem er bovendien in de gebruiker te verhinderen incorrecte queries te formuleren. `Once a field is selected, only fields that make logical sense are displayed for further result.' 31`Esperant (...) is best known for its ability to prevent users from building SQL 25 Voor een uitleg over OR-terminologie verwijs ik u graag naar hoofdstuk vier. 26 Microsoft TechNet, Developing with English Query 27 Campbell, `SQL Server The Developer's Product' 28 Hess, `Using Speech Recognition with Microsoft English Query' 29 Hess, `Using Speech Recognition with Microsoft English Query' 30 Dorsey, `Ad Hoc Query Tools: Do They Really Support Ad Hoc Querying?' 31 Dorsey, `Ad Hoc Query Tools' 13

16 qbe4or queries that return incorrect or invalid results, even though the SQL syntax may not generate an error.' 32 `Few query tools let end users construct complex queries with the ease found in Software AG's Esperant. (...) However, Esperant will be a stronger tool if future versions catch up with the analytical prowess found in other products (...).' 33 Het is in natuurlijke taal goed mogelijk om QBE-filters te formuleren, de technische problemen die daarbij komen kijken daargelaten. In plaats van een constructie als `= 4' zou men in het Engels `is 4' kunnen gebruiken. Bij complexere filters, die de equivalent van booleaanse expressies met AND, OR of XOR zouden moeten vormen, eventueel met nesting, worden volzinnen echter snel te lang om op een duidelijke manier in een invoerveld te kunnen worden weergegeven dat niet breder is dan een enkele kolom uit de voorbeeldtabel die de interface vormt. Het gebruik van natuurlijke taal als invoermethode is daarvoor geen oplossing, aangezien in QBE de filters in de resultaattabel eveneens moeten worden weergegeven. 32 Frank, `Esperant 3.0.' 33 Frank, `Esperant 3.0.' 14

17 3. Query-by-Example 3. Query-by-Example 3.1 Het systeem QBE is `a high level data base management language that provides the user with a convienient and unified interrface to query, update, define, and control a data base.' 34 Het probleem zoals geformuleerd in hoofdstuk een is beperkt tot het bevragen van de database. De complexiteit van ORDBs maakt dat deze in de praktijk alleen door, of met tussenkomst van, deskundigen beheerd en bevraagd worden. Dat was althans mijn ervaring bij de N.A.M. Dit onderzoek en het daaruit voortkomende systeem is daarom beperkt tot het querygedeelte van de functionaliteit van QBE, aangezien dat een oplossing voor het gestelde probleem is. `Two basic concepts are fundamental to Query-By-Example. Programming is done within two-dimensional skeleton tables. This is accomplished by filling in the appropriate table spaces with an example of the solution.' 35 Onderstaande afbeelding toont een dergelijke voorbeeldtabel. Onder de kolomnaamvelden kan in elke kolom een voorbeeld van de gezochte gegevens worden ingevoerd. Deze voorbeelden werken als filters voor de te retourneren gegevens, doordat al deze gegevens daarmee overeen moeten komen. Afbeelding 2. Voorbeeldtabel `When the user performs an operation against the data base, he fills in an example of a solution to that operation in skeleton tables that can be associated with actual tables in the data base.' 36 De hier genoemde voorbeeldtabellen hebben dezelfde kolommen en kolomtitels als de daadwerkelijke tabellen in de database, en wanneer de gebruiker zijn query in deze voorbeeldtabel formuleert, `he perceives that behind this query skeleton there is a real table (...) that contains the actual data. In other words, (...) he mimics the operation of scanning tables manually.' 37 Het tweede principe luidt dat er onderscheid wordt gemaakt tussen constante en voorbeeld-elementen. Een voorbeeldelement is een door de gebruiker ingevoerd element dat als filter dient. `The P stands for print, which indicates the desired output. ROD, which is an example element (variable) is 34 Zloof, `Query-by-Example', Zloof, `Query-by-Example', Zloof, `Query-by-Example', Zloof, `Query-by-Example',

18 qbe4or underlined, and represents an example of a possible anwer.' 38 Variabele elementen zijn variabelen die in combinatie met commando's gebruikt worden. Deze elementen zijn voor qbe4or niet van belang, voornamelijk omdat het commando altijd P voor `print' zou zijn. Voor de QBE-commando's die het sorteren van de tabellen regelen zijn tegenwoordig betere oplossingen, zoals een klik op de kolomtitel om de tabel op die kolom oplopend te sorteren, en nog een klik om die sortering om te draaien. Deze methode is beter omdat hij eenvoudiger is en bovendien toegepast kan worden nadat de query al is uitgevoerd, wat het systeem flexibeler maakt. De beschreven manier van filters aanbrengen is bijzonder krachtig, en tegelijkertijd eenvoudig te bedienen. Als er bijvoorbeeld in een lijst met objecten, waarvan de kleur bekend is, naar alle groene objecten gezocht wordt, dan vult de gebruiker in de kolom onder `kleur' het woord `groen' in. Is bovendien de vorm bekend, en wil de gebruiker alle ronde groene objecten, dan kan hij dat op dezelfde wijze in de daarvoor bestemde kolom aangeven. Ter vergelijking zou de equivalente SQL-query er in de meest eenvoudig mogelijke versie als volgt uit kunnen zien: select * from objecten where kleur='groen' and vorm='rond' Nu is dit nog een vrij eenvoudige query, maar zoals duidelijk zal worden in hoofdstuk zes kan bij objectrelationele databases de lengte en complexiteit van de query snel toenemen, terwijl de QBE-filters waarmee qbe4or die queries genereert niet veel ingewikkelder worden dat wat hier beschreven is. QBE onderscheidt meerdere soorten queries 39, waarmee sorteren, zoeken op onderdelen van strings, vergelijkingen en bewerkingen van getallen, eenvoudige booleaanse bewerkingen, joins en het groeperen van tabellen en gegevens mogelijk is. Een aanzienlijk deel van deze functionaliteit is ook van toepassing op ORDBs. In hoofdstuk zeven wordt uitgelegd hoe dit in qbe4or verwerkt is. Wanneer een op papier gedrukte tabel handmatig wordt doorzocht is de gebruiker op zoek naar een of meerdere objecten waarvan hij eigenschappen, bijvoorbeeld de naam, onthoudt. Het zoeken bestaat uit het overslaan, of negeren, van alles wat daaraan niet beantwoord. Het specificeren van voorwaarden is dus gelijk aan het beperken van de te vinden gegevens. Als de gebruiker niet naar iets specifiek op zoek is, houdt dit in dat hij geen voorwaarden heeft bedacht. Het niet specificeren van eigenschappen in qbe4or moet dus de volledige tabel retourneren, terwijl alles dat in de voorbeeldtabellen wordt ingevuld, een specificatie van zoekvoorwaarden, oftewel een beperking van het zoekresultaat is, en daarmee een formulering van een query. 3.2 Voor- en nadelen `The results of various psychological studies of the language show that it requires less than three hours of instruction for nonprogrammers to acquire the skill to make fairly complicated queries. Such queries would otherwise require the user to know first order predicate calculus.' 40 `(...) formbased query mechanisms, such as QBE, have been shown to enhance the user's ability to locate information within traditional database systems' 41. QBE is eenvoudig in het gebruik. Mensen hoeven geen progammeur te zijn om er queries mee te formuleren die redelijk ingewikkeld zijn. Dit betekent dat QBE een oplossing voor het in hoofdstuk een gestelde probleem kan zijn, indien het aan te passen valt voor ORDBs. Christopher Staff zet in zijn `Overview of approaches to Multimedia Information Retrieval' een aantal voordelen en nadelen van QBE tegenover elkaar 42. De door hem gevonden voordelen zijn de mogelijkheid voor patroonherkenning en -vergelijking, de ondersteuning van zoeken op basis van overeenkomsten, de mogelijkheid tot het classificeren van documenten, de mogelijkheid tot het trainen van het systeem voor automatische herkenning van die classificaties in nieuw materiaal en het afwezig zijn van de noodzaak tot het markeren van tekst. Staff benadert het concept vanuit een multimedia-perspectief; de laatste drie voordelen 38 Zloof, `Query-by-Example', Zloof, `Query-by-Example', Zloof, `Query-by-Example', Sawyer en Sommerville, `A User Interface Framework for an Object-Oriented Database System', Staff, `Overview of approaches to Multimedia Information Retrieval', 6 16

19 3. Query-by-Example zijn speciaal van toepassing op zijn eigen situatie en voor qbe4or niet van belang. De eerste twee echter vormen precies het door Zloof beoogde voordeel wat QBE zo gebruiksvriendelijk maakt: `Various studies have been conducted which investigated the relative merits of performing queries via forms and by query languages. These concluded that users of forms were less likely to make errors, formulated queries more quickly, and were able to do so with more confidence than those using query language.' 43 De nadelen die hij noemt zijn het gebrek aan expressie, gebrek aan eenvoud bij het aangeven van uitzonderingen, dat de gebruiker de vorm van het document moet kennen en dat het niet mogelijk is te zoeken aan de hand van tekstuele beschrijvingen. De eerste twee nadelen zijn onverminderd van kracht op objectrelationele systemen, maar wegen in dit geval niet op tegen de voordelen, zoals bleek uit de door Sawyer en Somerville genoemde studies. De overige twee nadelen gaan niet op voor object-relationele systemen, aangezien samenstelling en tekstuele beschrijvingen niet fundamenteel anders in de database opgeslagen zijn dan andere gegevens, waardoor ook daarop gezocht kan worden. 3.3 Recente closed-source toepassingen Sinds de oorspronkelijke ontwikkeling aan het einde van de jaren '70 wordt het concept van QBE in talloze closed-source projecten gebruikt. Afbeelding 3 44 is een voorbeeld van een QBE-query uit Borland Paradox 4 voor Microsoft Windows 3.x uit de eerste helft van de jaren '90. Het toont nauwkeurig de layout van een QBE-interface zoals door Zloof beschreven in Afbeelding 3. QBE in Borlands Paradox voor Windows De afbeelding hieronder is recenter, en afkomstig uit Microsoft Office Ook hierbij is het concept van de voorbeeldtabel, waarin de voorwaarden worden aangegeven waaraan de in die kolom te verschijnen informatie aan moet voldoen, volledig gehandhaafd. 43 Sawyer en Sommerville, `A User Interface Framework for an Object-Oriented Database System', Common Software Overview 45 Carroll, `How to do Most Queries in the Microsoft Access 2000 variant of SQL' 17

20 qbe4or Afbeelding 4. QBE in Micrsoft Office 2000 voor Windows Een zoektocht naar QBE op het internet levert letterlijk duizenden voorbeelden op zoals de twee hierboven. QBE wordt in zijn oorspronkelijke vorm toegepast in applicaties en op websites voor het gemakkelijk doorzoeken van interfaces. Een enkele keer wordt er, zoals in afbeelding 3, gekozen voor ee andere layout 46 : Afbeelding 5. Een MySQL-beheerapplicatie in Java Hoewel het er heel anders uitziet, blijkt bij een iets nadere beschouwing dat het concept volledig overeind is gebleven, hoewel negentig graden tegen de klok in gedraaid. De kolommen zijn nu rijen geworden. De kolomnamen staan onder elkaar, de operator kan uit een menu gekozen worden en de voorwaarde wordt in een veld rechts ingevuld. Na een muisklik op de knop `Execute query' zal er ongetwijfeld een resultaatset worden getoond die aan de aldus geformuleerde query voldoet. Als deze resultaatset de vorm van een tabel heeft waarvan de kolomnamen, zoals te verwachten valt, bovenaan verschijnen in plaats van aan de linkerkant, dan zal de zoekinterface qua layout niet meer de vorm van een voorbeeldtabel hebben gehad, zoals Zloof voorstelt. Hierdoor zal m.i. de intuïtiviteit van het systeem verminderen. Andere voorbeelden van een verandering van de interface die ik op het internet heb gevonden, zoals het opdelen ervan in verschillende tabbladen, vensters of pagina's, hebben eveneens het effect van verminderd comfort. 46 Customer Service Call Center Helpdesk software: QBE 18