De Universele Informatiekunde

Prof. dr. ir. J. Nerbonne 1 juni 2001 afstudeerscriptie

Manfred J. Schürhoff

De Universele Informatiekunde een analysetoepassing op een relatiebeheersysteem

Inhoudsopgave 1 2

Inleiding....................................................................................................................4 Relatiebeheer management en het relationele model .............................................5

2.1 2.2 3

Relatiebeheer management en het relatiebeheersysteem ............................5 Een relationeel systeem...................................................................................8

De Universele Informatiekunde ............................................................................10

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Informatiekunde............................................................................................10 Afspraken over communicatie en informatie .............................................10 Waarom Universele Informatiekunde?.......................................................12 Uitgangspunten en werkwijzen....................................................................12 Voorbeelden verzamelen ..............................................................................14 Het verwoorden van de informatie..............................................................15 Klassificatie en kwalificatie: de structuur van de feiten vaststellen.........17

3.8

Diagrammisatie .............................................................................................22

3.9

Beperkingsregels ...........................................................................................32

3.7.1 3.7.2

Klassificatie.............................................................................................18 Kwalificatie.............................................................................................19

3.8.1 3.8.2 3.8.3 3.8.4 3.8.5 3.8.6

FeitType diagrammiseren........................................................................25 BegripType diagrammiseren...................................................................25 NaamType diagrammiseren ....................................................................27 Controle van de diagrammisatie..............................................................28 Een volledig IGD-voorbeeld...................................................................29 NaamType preciseren..............................................................................31

3.9.1 3.9.2 3.9.3

UniciteitsRegel........................................................................................33 VerplichteRolRegel.................................................................................37 Overige BeperkingsRegels......................................................................40

3.10 FeitTypen als BegripTypen..........................................................................41 3.11 Redundantie verwijderen.............................................................................42 3.11.1 3.11.2

Redundantie in de InformatieGrammatica..............................................43 Redundantie in de InformatieBank .........................................................44

3.12 Het relationele model ....................................................................................45 3.12.1 3.12.2 3.12.3

Groeperen................................................................................................45 Lexicaliseren ...........................................................................................48 Omzetten naar relationele notatiewijze...................................................50

4

Casus.......................................................................................................................52

4.1 4.2 4.3 4.4 4.5 4.6

Introductie .....................................................................................................52 De huidige situatie.........................................................................................52 Stap 1: Voorbeelden verzamelen .................................................................56 Stap 2 & 3: Verwoorden & Klassificatie en Kwalificatie..........................63 Stap 4: Diagrammisatie ................................................................................73 Stap 5: Beperkingsregels toevoegen ............................................................78

4.7 4.8

Stap 6: FeitTypen als BegripTypen.............................................................84 Stap 7: Redundantie verwijderen................................................................84

4.9

Stap 8: Omzetting naar relationeel model ..................................................88

4.6.1 4.6.2 4.6.3

4.8.1 4.8.2

UniciteitsRegel opstellen ........................................................................78 VerplichteRolRegels opstellen................................................................83 Overige BeperkingsRegels opstellen ......................................................83

Redundantie in de InformatieGrammatica..............................................85 Redundantie in de InformatieBank .........................................................86

4.9.1 Stap 1: Groeperen....................................................................................88 Stap 2: Lexicaliseren...............................................................................................93 4.9.2 Stap 3: Omzetten naar relationele notatiewijze.......................................96 5 Conclusie ................................................................................................................99 Figuren .........................................................................................................................101 Bibliografie...................................................................................................................104

1 Inleiding

Relaties zijn onmisbaar voor het succes en de continuïteit van een organisatie. Door snelle en eenvoudige toegang tot complete klanten prospectgegevens kunnen meer en betere contacten onderhouden worden. Het is daarom van belang om klantgegevens upto-date te houden. Om dit te kunnen bereiken, is er een optimaal relatiebeheersysteem nodig. Maar wat houdt relatiebeheer nu precies in? In hoofdstuk 2 ga ik dieper in op deze vraag. In paragraaf 2.1 geef ik een algemene beschrijving over Relatiebeheer Management (RM), ook wel CRM (Customer Relationship Management) genoemd, en relatiebeheersystemen. Voor een goed relatiebeheersysteem moet de structuur van zo’n systeem relationeel opgebouwd zijn. In paragraaf 2.2 geef ik aan wat het nut van een relationeel relatiebeheersysteem is. Alvorens aan de bouw van een nieuw systeem te beginnen, dient er mijns inziens een goede analyse van de gegevens plaats te vinden. Ongeacht de gebruikte analysemethode zou dit moeten leiden tot een optimaal systeem. Het waarom en het nut van een goede analyse voorafgaande aan de bouw van een systeem is wat ik in deze scriptie wil onderzoeken. Ik heb gekozen voor de informatieanalysemethode van de Universele Informatiekunde (UI), waarbij de analyse plaatsvindt op grond van in natuurlijke taal verwoorde feiten. Deze methode, ontwikkeld door professor G.M. Nijssen, is ook wel bekend onder de naam NIAM (Natural Language Information Analysis Method). Het voordeel van bovengenoemde methode is dat ze voor een ieder goed te begrijpen is, zowel voor de analist als voor de gebruiker van een systeem. Daarnaast is de methode toepasbaar in alle situaties waarin informatie uitgewisseld wordt die in taal te beschrijven is. Ze is dus niet gekoppeld aan bepaalde vakgebieden of toepassingen, wat bij veel andere analysemethoden wel het geval is. In hoofdstuk 3 behandel ik de theorie van de UI. Hierbij heb ik voornamelijk gebruik gemaakt van het boek Informatie in model, over gegevens, feiten en afspraken van J. Eggink, E.J. Leenstra en G.M. Nijssen. De voorbeelden en figuren in dit hoofdstuk zijn dan ook ontleend aan dit boek. In paragrafen 3.1 tot en met3.4 geef ik een algemene inleiding over UI. In paragrafen 3.5 tot en met 3.12 beschrijf ik het stappenplan van de analysemethode om tot een uiteindelijk relationeel model te komen. In hoofdstuk 4 zal ik de in hoofdstuk 3 behandelde theorie over de Universele Informatiekunde toepassen op een praktijkgerichte situatie: de omzetting van een bestaand relatiebeheersysteem bij Nedercom Eduware naar een nieuw relatiebeheersysteem. Vervolgens geef ik in hoofdstuk 5 een conclusie.

4

2 Relatiebeheer management en het relationele model 2.1 Relatiebeheer management en het relatiebeheersysteem

Relatiebeheer Management (RM) is een zakelijke methodologie die zich richt op het werven van nieuwe en het behouden van bestaande klanten (zie The Woodburngroup 2000). Hierbij moet men relatiegegevens van deze (potentiële) klanten verzamelen. Onder een relatie verstaan we een onderneming of instelling. Van elke relatie moeten basisgegevens vastgelegd worden die aangevuld kunnen worden met contactpersoongegevens, adresgegevens en communicatiegegevens, bijvoorbeeld (zie InterAct Bedrijfsautomatisering 1999): • Naamgegevens: zoekcode, naam, zoeknaam. • Contactpersoongegevens: aanhef, titulatuur, naam, voorletters, tussenvoegsels. • Adresgegevens: bezoekadres, postadres, privéadres. • Communicatiegegevens : telefoonnummer werk en privé, faxnummer, mobiele telefoonnummer, e-mailadres, Internetadres. Een sterk groeiende concurrentie op de markt is één van de voornaamste redenen waarom bedrijven overwegen RM toe te passen. Met de komst van het Internet hebben klanten toegang tot meer bedrijven, producten en prijsinformatie dan ooit. Ze kunnen altijd op een gemakkelijke manier de producten en prijzen vergelijken met die van de concurrenten. Uit onderzoek blijkt (zie The Woodburngroup 2000) dat klanten een hechte band met bepaalde bedrijven willen ontwikkelen en dat ze daarvoor wel wat meer willen betalen op voorwaarde dat een bedrijf goede producten en goede service levert. Met behulp van RM kan een organisatie meedingen in de bovengenoemde concurrentiestrijd. Het hoofddoel van RM is het beter leren kennen en begrijpen van de klant, waardoor er een één-op-één relatie met hem ontstaat die gebaseerd is op zijn behoeften en wensen. Na verloop van tijd zal de klantenbinding groter worden, waardoor de concurrentie af zal nemen. Naast deze concurrentiestrijd geeft Koehen nog een aantal andere redenen om RM toe te passen: 1. Het verkrijgen van een beter inzicht van de interne marketing- en verkoopkosten. 2. Calamiteiten (klachten) voorkomen. 3. Als hulpmiddel dienen in de communicatie. 4. Klantprofielen vastleggen. Uit bovenstaande blijkt dat relaties onmisbaar zijn voor het succes en de continuïteit van een organisatie. Door snelle en eenvoudige toegang tot complete klanten 5

Hoofdstuk 2

Relatiebeheer management en het relationele model

prospectgegevens kunnen meer en betere contacten onderhouden worden. Het is daarom van belang om klantgegevens up-to-date te houden. Hiervoor is een optimaal relatiebeheersysteem nodig. E-mailmarketing kan een belangrijke bijdrage leveren tot het opbouwen van de bovengenoemde één-op-één-relatie met de klant. E-mail is in combinatie met een klantendatabase één van de weinige middelen die op Internet beschikbaar zijn om mensen actief te benaderen. Daarnaast biedt e-mail een groot aantal voordelen (zie RapidSugar): • Snelle bezorging. • Hoge penetratiegraad: 32% van de Nederlanders heeft zakelijk of privé toegang tot Internet. Dit maakt e-mail tot een zeer geschikte drager van bijvoorbeeld een commerciële boodschap. • Lage kosten. • Mogelijkheid tot gepersonaliseerde e-mails: responspercentages nemen door personalisatie over het algemeen fors toe. • Meetbaarheid van resultaat: het klikgedrag van de ontvanger kan vastgelegd worden, waardoor conclusies getrokken kunnen worden uit de leesintensiteit van de mail en het resulterende koopgedrag. • Informelere communicatiemogelijkheden. Er zijn tal van mogelijkheden waarop bezoekers naar een website van een bedrijf toegetrokken kunnen worden. Het gebruik van e-mail en banners zijn de meest gebruikte methoden. In onderstaande figuur van RapidSugar worden een aantal on line middelen met elkaar vergeleken.

Which traffic-driving techniques do you use today and how effective are they?

Ranked by popularity

89% 77% 55% 45% 34% 34% 32% 32% 30% 30% 23% 17% 17%

Banners E-mail to customers Buttons Public relations Magazines Sponsorships Newspapers Radio Direct mail Television E-mail to opt-in lists Outdoor Affiliate programs

Ranked by effectiveness Affiliate programs E-mail to customers Public relations Television Outdoor E-mail to opt-in lists Direct mail Magazines Radio Sponsorships Buttons Banners Newspapers

4.3 4.3 4.1 4.0 3.7 3.5 3.4 3.4 3.4 3.3 3.2 2.8 2.6

Percents represent share of 47 marketing managers interviewed, multiple responses accepted. Effectiveness ratings represent average scores based on a sacle of 1 (poor) to 5 (great). Source: Forrester Research, Inc.

Figuur 2-1: Hoe trekken bedrijven bezoekers naar hun site en hoe effectief zijn die methoden?

6

Hoofdstuk 2


Uit Figuur 2-1 kunnen we opmaken dat de meest populaire methoden het minst effectief zijn en dat de meest effectieve methoden het minst populair zijn. Hierbij zal het prijskaartje dat aan de methoden verbonden is een rol spelen. Banners en buttons zijn immers een goedkope manier van reclame maken. Affiliatiesprogramma’s en televisie daarentegen niet. E-mail voor klantenbinding kan zich in verschillende vormen voordoen. De meest gebruikte verschijningsvorm, welke tevens nauw samenhangt met CRM, is de zogenaamde Customer Relationship E-mail (CRE): bezoekers van een website worden uitgenodigd om hun e-mailadres achter te laten om op de hoogte te worden gehouden van nieuwe ontwikkelingen en zo nu en dan een aanbieding te ontvangen. Deze vorm van mailen wordt ook wel opt-in-marketing genoemd. Het sleutelwoord bij acquisitie is dus toestemming. Zonder toestemming kan er niet gemaild worden. Dit zou onder de categorie spamming vallen, wat een hoge irritatiegraad bij de ontvanger opwekt en mogelijk verlies van (potentiële) klanten. Naast de opt-in-mogelijkheid, moet er ook een opt-out-mogelijkheid zijn: de bezoeker van de site moet de mogelijkheid hebben zichzelf van de mailinglijst te kunnen halen, zodat hij geen e-mailings meer ontvangt. Uit bovenstaande blijkt wel dat als kern van een effectief (marketing-)beleid relatiebeheer meer is dan het registreren van naam, adres en telefoonnummer. Een aantal vragen waarmee rekening dient te worden gehouden bij de ontwikkeling van een relatiebeheersysteem zijn: 1. Waaraan moet zo’n systeem voldoen? 2. Hoe verwerk je bestaande gegevens in zo’n systeem? 3. Wat is een doelmatige manier om zo’n systeem te automatiseren? 4. Hoe bouw je zo’n systeem, zodat het makkelijk te onderhouden/te gebruiken is? Het doel van zo’n systeem is optimaal relatiebeheer. Hiertoe dient een informatiesysteem o.a. de volgende onderdelen te bevatten (zie Ultimate Software B.V.): Informatieverwerving: 1. Registratie van prospects en vaste relaties. 2. Registratie van contactpersonen. 3. Registratie van verkoopgesprekken/notities. 4. Historische data per relatie. Verwerkingsmogelijkheden: 5. Mailingmogelijkheden. 6. Import vanuit externe bestanden. 7. Export naar externe bestanden. 8. Internetondersteuning.

7

Hoofdstuk 2


2.2 Een relationeel systeem

Om een optimaal relatiebeheer te bereiken, dient de structuur van zo’n relatiebeheersysteem relationeel opgebouwd te zijn. Wat houdt dit precies in? Het relationele model is een wiskundige theorie – geïntroduceerd in 1970 door E.F. Codd – die uit een aantal begrippen en definities bestaat (zie Lans, van der 1996: 3-7). Dit model vormt de theoretische basis voor databasetabellen. Het model bestaat uit een klein aantal eenvoudige concepten voor het registreren van gegevens in een database, samen met een aantal operatoren om de gegevens te bewerken. Al deze concepten en operatoren zijn voornamelijk ontleend aan de verzamelingenleer en de predikatenlogica. Er is bijna geen administratie meer denkbaar die niet op de één of andere manier gebruik maakt van een bestand met informatie over relaties. Vrijwel elke organisatie houdt op meerdere plaatsen dit soort administraties bij en heeft dan ook in meer of mindere mate te maken met problemen rond het beheer en gebruik van hun relatiegegevens. Deze problemen worden met name veroorzaakt door de volgende ontwikkelingen (zie Walvis Software): • Relaties worden steeds dynamischer: relaties zijn niet alleen personen, maar ook organisaties, afdelingen of organisatiestructuren met zowel een vast als tijdelijk karakter. En al deze relaties hebben onderling weer tal van relaties. • Adresgegevens worden complexer: adresgegevens zijn allang niet meer beperkt tot één straatnaam, huisnummer en woonplaats. Ook factuuradres, woonadres, vestigingsadres, postadres en vele vormen van elektronische adressen (fax, GSM, E-mail, Internet) komen voor. • Steeds meer gegevens over een relatie: zowel bij de overheid, het bedrijfsleven als in de non-profit sector bestaat de behoefte om steeds meer gegevens over relaties vast te leggen en vrij te kunnen benaderen. Het gaat hier om zeer uiteenlopende behoeften, soms afhankelijk van de relatiecategorie. In de meeste gevallen beschikt een bedrijf dus wel over klantgegevens, maar deze gegevens zijn niet altijd even efficiënt opgeslagen en/of toegankelijk en gestructureerd, bijvoorbeeld: alle data wordt opgeslagen in één platte tabel; er wordt geen onderverdeling tussen verschillende soorten data in aparte tabellen gemaakt. Bij veel gegevens zal het geheel zeer onoverzichtelijk worden en hoe groter de database wordt, hoe trager. In het ergste geval bestaat er helemaal geen informatiesysteem. Redenen te meer dus om een relationeel relatiebeheersysteem op te zetten. Waarom een relationeel model? Een relationeel model biedt o.a. de volgende voordelen: 1. Beschikking over de meest actuele gegevens. 2. Efficiënte en flexibele indeling en beheer van gegevens: i.p.v. verschillende databasebestanden met daarin dezelfde gegevens op te slaan, is het beter om gegevens slechts eenmaal in kleinere bestanden op te slaan. Gegevens hoeven dan 8

Hoofdstuk 2


ook maar op één plaats gewijzigd te worden, waardoor de nauwkeurigheid van de gegevens toeneemt. 3. Besparing schijfruimte; gegevens worden immers maar op één plaats opgeslagen. Voordat aan het bouwen van zo’n systeem begonnen wordt, dient er mijns inziens eerst een grondige analyse van de gegevens plaats te vinden. De Universele Informatiekunde (UI) is hiervoor een uitstekend gereedschap. UI is een precisie van wiskunde en logica, maar tegelijk de begrijpelijkheid van “gewone” taal. In het volgende hoofdstuk besteed ik uitgebreid aandacht aan deze informatieanalysemethode.

9

3 De Universele Informatiekunde 3.1 Informatiekunde

Als we het over informatiekunde hebben, hebben we het over informatie en uitwisseling van informatie. Om te kunnen functioneren, moeten organisaties en individuen communiceren. Dit houdt in dat ze berichten of boodschappen kunnen opstellen en verzenden en kunnen ontvangen en interpreteren. Met andere woorden: ze kunnen informatie uitwisselen. In organisaties worden voorschriften bedacht en hulpmiddelen gebruikt om het uitwisselen van informatie mogelijk te maken. Dit toont de zogenaamde informatiebehoefteaan (zie Eggink 1995: 1). Informatiekunde houdt zich ondere andere bezig met de rol van informatie bij deze bedrijfsvoering en met het creëren van een bepaalde opzet van de informatieverzorging bij deze informatiebehoefte. Om berichten uit te kunnen wisselen, moet er een verzameling van afspraken zijn met betrekking tot de inhoud en de vorm van de berichten. Om deze afspraken te leren kennen, is er een informatieanalyse nodig.

3.2 Afspraken over communicatie en informatie

Zoals reeds gezegd houdt de informatiekunde zich bezig met het creëren van een bepaalde opzet van de informatieverzorging. Hieronder verstaan we het geheel van mensen, afspraken en middelen met als doel informatie-uitwisseling mogelijk te maken (zie Eggink 1995: 6). We kunnen onderscheid maken tussen menselijke en machinale berichtenuitwisselaars. Een mens kan heel efficiënt zijn in zijn communicatie, maar menselijke communicatie heeft ook zijn zwakke punten: het is niet altijd perfect en dat kan tot misverstanden en fouten leiden. Eggink noemt een aantal merkwaardige kenmerken van menselijke berichtenuitwisselaars (p. 6): 1. Ze kunnen non-verbaal communiceren. 2. Ze kunnen met taal en beeld communiceren. 3. Ze hebben aan een half woord genoeg en ze kunnen tussen de regels door lezen. 4. Ze kunnen met dezelfde woorden andere dingen bedoelen. 5. Ze kunnen met verschillende woorden dezelfde dingen bedoelen. 6. Ze kunnen met een hele hoop woorden nog niets zeggen. 7. Niet iedereen kan met iedereen ‘praten’. Als we bij het uitwisselen van berichten gebruik willen maken van middelen zoals de computer, lopen we hier dus tegen problemen aan. Immers, een computer beschikt (nog) niet over het vermogen om tussen de regels door te kunnen lezen of met intonatie van de menselijke stem om te gaan. Met een bericht als 10

Hoofdstuk 3

De Universele Informatiekunde

“Ik verwacht morgen een telefoontje van de firma Nedercom over die vertraagde order.”

kan de menselijke ontvanger prima mee uit de voeten, maar de machinale ontvanger heeft preciezere informatie nodig om hier iets mee te kunnen, bijvoorbeeld: “Op 7 november 2000 zal de firma Nedercom telefonisch contact opnemen over de order TP.007, die geleverd had moeten worden op 25 oktober 2000.”

Hieruit blijkt dus dat bij het inzetten van computers bij informatie-uitwisseling het noodzakelijk is duidelijke (bindende) afspraken wat betreft de communicatie te maken. In de communicatie speelt de gebruikte taal een grote rol. Hier doet zich met name het probleem voor dat niet iedereen met iedereen kan praten, door bijvoorbeeld het gebruik van verschillende moeder- of natuurlijke talen. In zulke gevallen wordt er vaak gebruik gemaakt van gebarentaal of er wordt een kunstmatige taal gecreëerd. Het komt ook veel voor dat verzamelingen van mensen een eigen jargon gaan ontwikkelen. In een jargon worden vaak niet alleen typische woorden gebruikt, maar worden vaak ook (veel) woorden door symbolen en tekeningen vervangen. Voor het gebruik van ‘plaatjes’ zijn afspraken gemaakt die uit schema- of tekenvoorschriften bestaan. Een voorbeeld van zo’n jargon waarbij gebruik wordt gemaakt van plaatjes is een InformatieGrammaticaDiagram (IGD): deze worden toegepast in de Universele Informatiekunde en zullen in dit hoofdstuk en het volgende hoofdstuk nog aan bod komen. Voornaam

Landnaam NTF1: <…>

N

Persoon

Land

BTF1: De persoon

UR25

R1

R25

FT12 R36

FTF1: Er is een persoon . FTF1: houdt het meest van . Barend Frits Johan Klaas

N

FTF2: heeft als favoriet. Barend Amerika Klaas Frankrijk Nederland Frits Amerika Johan

BTF1: Het land R4 FTF1: Er is een land . Nederland Amerika Frankrijk

Figuur 3-1: Jargon – een Informatie Grammatica Diagram [Bron: Eggink 1995: 8]

Met een jargon zoals hierboven weergegeven, kan men precies communiceren met als doel het voorkomen van misverstanden en fouten. Bij het analyseren en/of ontwerpen van berichten komt het er op neer dat we de afspraken over de inhoud en de vorm van de berichten analyseren. Nadere uitleg over de gebruikte termen en afkortingen in het bovenstaande IGD worden gaandeweg in dit hoofdstuk behandeld. 11

Hoofdstuk 3


3.3 Waarom Universele Informatiekunde?

Veel informatieanalysemethoden zijn gericht op de informatica en/of informatiekunde en zijn verbonden aan een bepaalde programmeeromgeving, waardoor ze niet algemeen toepasbaar zijn. Daarnaast leveren deze methoden veelal resultaten op die niet alleen kunnen verschillen als meerdere mensen gevraagd wordt dezelfde situatie te beschrijven, maar ook als eenzelfde persoon enkele weken later dezelfde situatie nog eens voor zijn neus krijgt. Dit mag natuurlijk niet voorkomen als precisie belangrijk is. Een aantal voordelen van de UI zijn (zie Eggink 1995: 11): 1. De methode is toepasbaar in alle situaties waarin informatie uitgewisseld wordt die in taal te beschrijven is. Ze is dus niet gekoppeld aan bepaalde vakgebieden of toepassingen en ze mag dan ook universeel genoemd worden. 2. De UI doet geen beroep op intuïtie, creativiteit of ervaring, maar op vaardigheid in het werken met een ondubbelzinnig voorschrift. 3. Doordat er wordt gewerkt met een ondubbelzinnig voorschrift, zijn de resultaten van de activiteit informatieanalyse reproduceerbaar: gegeven dezelfde situatie, dan leidt het voorschrift tot gelijke beschrijvingen van die situatie, ook als de analyse door verschillende personen wordt uitgevoerd.

3.4 Uitgangspunten en werkwijzen

Communicatie kan op verschillende manieren plaatsvinden (zie Eggink 1995: 12), bijvoorbeeld mondeling, schriftelijk, door middel van gebaren of signalen. Als de zender van een bericht en de ontvanger ervan elkaar begrijpen, dan is communicatie zinvol. Met andere woorden: de inhoud van het bericht moet bij beide partijen bekend zijn. Bij de communicatie door middel van Internet wordt bijvoorbeeld vaak gebruik gemaakt van zogenaamde smileys, zoals :-). Dit bericht bestaat uit een combinatie van tekens en (een afspraak over) de betekenis ervan. De basis voor begrip is de koppeling tussen teken en betekenis. We spreken van informatie als er sprake is van zo’n koppeling. Informatie kan ook gezien worden als een gegeven dat voorzien is van een context. “Het is 40°C” is bijvoorbeeld een gegeven, maar nog geen informatie. Het wordt pas informatie als we het gegeven in een context zetten, bijvoorbeeld: “Het is buiten 40°C.”, betekent dat het erg warm is, maar als we zeggen: “De koffie is 40°C.”, dan kunnen we hieruit opmaken dat deze behoorlijk afgekoeld is. Met behulp van een computer kunnen zulke gegevens opgeslagen worden. Na een bewerking (bijvoorbeeld door middel van instructies in de vorm van een computerprogramma) kan er uit de opgeslagen gegevens efficiënt informatie worden onttrokken. In de alledaagse communicatie wordt er vaak informatie uitgewisseld waarvan het afsprakenpatroon bekend wordt verondersteld. We zien dit ook bij het gebruik van jargon. In situaties waarin niet alle betrokenen de afspraken kennen die worden gehanteerd 12

Hoofdstuk 3


in de communicatie, moeten we zo volledig mogelijk zijn. Dit kunnen we doen door de gedaante of de verschijningsvorm waarin de informatie zich voordoet, om te zetten naar zinnen in de natuurlijke taal. We noemen dit het verwoorden van de informatie. Het nadeel van zinnen uit de natuurlijke taal is dat ze vaak dubbelzinnig zijn. Soms is er zelfs geen enkele betekenis aan te verbinden. Om misverstanden in de communicatie te voorkomen, is het daarom van belang een beperking op te leggen tot een bepaald soort zinnen uit de natuurlijke taal, de zogenaamde elementaire zinnen. Een elementaire zin is de kleinst mogelijke ondubbelzinnige zin die er te maken valt. Elke samengestelde zin uit de natuurlijke taal kan worden omgezet naar elementaire zinnen. Bij vaktaal of jargon doet zich ook nog eens het probleem voor dat het voor buitenstaanders vaak moeilijk te begrijpen is. Een informatieanalist moet in staat zijn vast te stellen wat de informatieinhoud van een bericht is. De moeilijkheid die zich hierbij voordoet is dat enerzijds het bericht dat door de gebruikers verwoord wordt in een jargon plaatsvindt dat de informatieanalist niet kent en anderzijds kennen de gebruikers het jargon van de informatieanalist niet. Één van de belangrijkste uitgangspunten van de UI is daarom ook dat de communicatie tussen de gebruiker en de informatieanalist zich voltrekt in het jargon van de gebruiker. De informatieanalist maakt zich het jargon van de gebruiker eigen door het verzamelen van voorbeelden en door het bericht door de gebruiker in natuurlijke zinnen om te laten zetten. De informatieanalist legt deze natuurlijke zinnen vervolgens vast in elementaire zinnen. Zijn eigen vakjargon houdt hij voor zichzelf. Vragen gericht op het vaststellen van het afsprakenpatroon dat wordt gehanteerd door de gebruiker, worden dus gesteld in het jargon van de gebruiker, door het uitwisselen van concrete voorbeelden van berichten. Een ander uitgangspunt van de UI is dat elk voorschrift dat wordt gebruikt moet leiden tot ondubbelzinnige, reproduceerbare resultaten. Dat wil zeggen dat er een voorschrift moet zijn waarmee elk voorbeeld van een bericht bewerkt moet kunnen worden, zodat de resultaten van de analyse onafhankelijk zijn van degene die de analyse uitvoert. Daarnaast moet gelden dat als het voorschrift door dezelfde persoon herhaald wordt uitgevoerd op hetzelfde voorbeeld, het resultaat gelijk blijft. Volgens Eggink (1995: 21) ziet de werkwijze van UI er als volg uit: 1. De communicatie verloopt op basis van voorbeelden van representatieve berichten die behoren tot het jargon van de gebruiker. 2. Om communicatiemisverstanden te voorkomen, moeten de voorbeelden worden omgezet naar elementaire zinnen. 3. De elementaire zinnen worden geanalyseerd en leiden tot nieuwe voorbeelden die met de gebruiker worden doorgenomen. 4. De analyse van de voorbeelden wordt vastgelegd in elementaire zinnen: het informatiemodel. 13

Hoofdstuk 3


5. De werkwijze verloopt volledig volgens voorschrift, omdat reproduceerbare modellen vereist zijn. 6. De modellen zijn niet computerafhankelijk; ook zonder computer kan het zinvol zijn de modellen te maken. 7. De modellen zijn om te zetten naar verschillende omgevingen; ze zijn niet programmeertaalafhankelijk.

3.5 Voorbeelden verzamelen

De eerste stap in de werkwijze van de UI is het verzamelen van concrete voorbeelden (zie Eggink 1995: 23-30). Dat wil zeggen het verzamelen van ingevulde voorbeelden van formulieren, lijsten, overzichten en welke vorm van vastlegging dan ook die gebruikt wordt binnen een organisatie, om zo alle relevante feiten binnen het informatiesysteem in kaart te kunnen brengen. Dit bereikt men door interviews te houden met alle betrokken personen in de organisatie. Alleen de relevante informatie wordt in samenspraak met de gebruiker omgezet naar elementaire zinnen. Na afloop van een interview moeten de voorbeelden geanalyseerd worden. Aan de ene kant gaat het hier om een analyse van de elementaire zinnen (zie 3.7 Klassificatie en kwalificatie: de structuur van de feiten vaststellen). Aan de andere kant gaat het er om of er voldoende voorbeelden verzameld zijn. In eerste instantie moet er eerst een beschrijving van de huidige situatie binnen een organisatie gemaakt worden. Met andere woorden: men moet eerst beschrijven hoe bepaalde processen binnen een bedrijf worden uitgevoerd alvorens men met het inrichten van een nieuw systeem begint. Als de huidige situatie in kaart gebracht is, kan er worden gekeken welke veranderingen eventueel in die situatie gewenst zijn. Indien er geen voorbeelden voorhanden zijn, wat het geval kan zijn bij een nieuw bedrijf of bij een nieuwe toepassing, moet er uitgegaan worden van een reeds bestaande situatie die vrijwel altijd wel aanwezig is. Voor de nieuwe onderdelen dient de informatieanalist de gebruikers te vragen hoe ze zouden moeten werken. Het gaat in dit geval over concrete zaken als een formulier, een product of een dienst en daar kan iedereen zich wel iets bij voorstellen. Zo moet elke nieuwe situatie hoe dan ook verwoord worden (zie Steenis 1996: 33). Waarom zijn voorbeelden nu zo nuttig? Binnen de UI hebben voorbeelden de functie van verkenning en communicatiemiddel. Door het gebruik van concrete voorbeelden uit de dagelijkse praktijk van de gebruiker, worden abstracte discussies vermeden. Het voordeel hiervan is een grote mate van precisie en het voorkomen van misverstanden. De informatieanalist wil het afsprakenpatroon achter de communicatie in kaart brengen. Voorbeelden geven dit patroon weer en door het verwoorden van deze voorbeelden in zinnen van de natuurlijke taal, kan het afspraakpatroon zichtbaar worden gemaakt. 14

Hoofdstuk 3


In deze eerste stap van de analyse moet een grote mate van details worden doorgenomen; er worden weinig details geabstraheerd. Dit heeft volgens Eggink (1995: 30) tot voordeel dat: 1. De gebruiker niet hoeft te communiceren door middel van de abstracte begrippen uit het jargon van de informatieanalist. 2. Er geen communicatie in termen van abstracties plaatsvindt, zodat misverstanden tussen gebruiker en analist, maar ook tussen analisten onderling, voorkomen kunnen worden. Dit levert tevens een aanzienlijke tijdwinst op. 3. Fouten in een vroeg stadium van de analyse ondervangen kunnen worden, zodat deze niet pas bij de implementatie op de computer of bij het testen of de applicatie goed werkt, ontdekt worden. Dit heeft als voordeel dat de herstelkosten van een gemaakte fout laag zijn.

3.6 Het verwoorden van de informatie

De tweede stap in de UI is het verwoorden van de informatie (zie Eggink 1995: 33-41). Na het verzamelen van alle relevante voorbeelden, kan de informatie op de verschillende voorbeelddocumenten verwoord worden. Het verwoorden wordt gedaan door de bekende gebruiker, de persoon die exact weet welke informatie wordt weergegeven met de betreffende voorbeelddocumenten. Na de verwoording is de informatieanalist ook op de hoogte van de informatieinhoud van de verschillende voorbeelden. Zo leert de informatieanalist het jargon van de gebruiker kennen.

Klantnummer: 53533 Regelnr.:

1 2

Artikel:

63653 75342

Volgnummer: 371 Artikelomschrijving:

Broodblik Stapelglas

Aankoopdatum: 22-07-00

ƒ ƒ

Artikelprijs:

20,45 1,50

Aantal:

5 12

Totaalbedrag:

Tijdstip: 14:33 Subtotaal:

ƒ ƒ

102,25 18,00

ƒ

120,25

Figuur 3-2: Het verwoorden van de feiten betrekking hebbend op aankoopdatum en tijdstip van uitschrijven van een aankoopbon [Bron: Eggink 1995: 34]

De informatieanalist moet consequent alle feiten die de gebruiker verwoordt, arceren op het voorbeelddocument, zodat hij aan het einde kan controleren of alle verschillende feiten van het betreffende voorbeeld verwoord zijn (zie voorbeelddocument in Figuur 3-2). Verder dient er rekening gehouden te worden met de volgende punten: 15

Hoofdstuk 3


1. Er moeten concrete feiten worden verwoord, geen algemeenheden of conclusies. Een verwoording van een feit van de aankoopbon (zie Figuur 3-2) als: “Dit betreft een aankoopbon en wel de bon met nummer 371 uitgeschreven op 22 juli om 14:33.”

kan beter als volgt verwoord worden:

“De bon 371 van de horecaondernemer 53533 is opgesteld op 22-07-00 en is uitgeschreven om 14:33.”

2. De gebruiker moet zich precies houden aan de informatie op het voorbeelddocument. Dus niet ’22 juli’, maar ’22-07-00’ en niet ‘bon met nummer’, maar ‘bon met volgnummer’. 3. De zinnen uit de verwoording moeten onafhankelijk van elkaar zijn. Dat houdt in dat zinnen volledig te begrijpen moeten zijn zonder dat daar andere zinnen voor nodig zijn. Aan de volgende verwoording van een feit van de aankoopbon (zie Figuur 3-2) mankeert nog het één en ander: “Op regel 1 staat dat er 5 broodblikken met artikelnummer 63653 zijn verkocht à 20,45.”

Stel dat er meerdere bonnen verwoord worden. Dan is het niet bekend welke regel precies bedoeld wordt. Daarnaast zou het voor kunnen komen dat er meerdere bonnen met volgnummer 371 zijn, bijvoorbeeld als de bonnen per klant worden genummerd. De onderstaande verwoording houdt hier wel rekening mee: “Op regel 1 van de bon met volgnummer 371 van horecaondernemer 53533 staat dat er 5 broodblikken met artikelnummer 63653 zijn verkocht à 20,45.”

4. De verwoording moet zoveel mogelijk in elementaire zinnen gedaan worden. Deze zinnen kunnen niet verder worden opgesplitst zonder daarbij informatie te verliezen. Er moet altijd geprobeerd worden een zin zo ver mogelijk op te splitsen, zonder dat er informatie verloren gaat en de onafhankelijkheid van de zin in gevaar komt. Een verwoording als: “De bon 371 van de horecaondernemer 53533 is opgesteld op 22-07-00 en is uitgeschreven om 14:33.”

kan als volgt opgesplitst worden in elementaire zinnen:

1) “De bon 371 van de horecaondernemer 53533 is opgesteld op 22-07-00.” 2) “De bon 371 van de horecaondernemer 53533 is uitgeschreven om 14:33.”

Bij het verwoorden van de informatie dient gezorgd te worden voor een representatieve populatie van de feiten. Dit kan verkregen worden door de gebruiker een instantie van hetzelfde feit van een ander voorbeelddocument te laten verwoorden. Aan de hand van het voorbeelddocument in Figuur 3-3 kan de volgende verwoording gedaan worden: “De bon 182 van de horecaondernemer 80142 is opgesteld op 12-10-00 en is uitgeschreven om 11:34.”

en vervolgens kan dit feit weer opgesplitst worden in twee elementaire zinnen:

16

Hoofdstuk 3


1) “De bon 182 van de horecaondernemer 80142 is opgesteld op 12-10-00.” 2) “De bon 182 van de horecaondernemer 80142 is uitgeschreven om 11:34.”

Op soortgelijke wijze worden vervolgens alle verschillende typen feiten die voorkomen op het voorbeelddocument verwoord. Dit valt aan het eind van deze analysestap te controleren door na te gaan of alle soort informatie minstens één keer op het voorbeeld gearceerd is.


1 2

Artikel:

40986 75342


Fileermes Stapelglas


ƒ ƒ

Artikelprijs:

45,95 1,50

Aantal:

1 5

Totaalbedrag:


ƒ ƒ

45,95 7,50

ƒ

53,45

Figuur 3-3: Het verwoorden van een tweede instantie van hetzelfde feit (aankoopdatum en tijdstip van uitschrijven van een aankoopbon) van een ander voorbeelddocument [Bron: Eggink 1995: 40]

3.7 Klassificatie en kwalificatie: de structuur van de feiten vaststellen

Na het verwoorden van een representatief aantal feiten, kan de derde stap van de UI plaatsvinden: het vaststellen van de structuur van de feiten (zie Eggink 1995: 45-60). Dit houdt in dat de zinnen die ontstaan zijn als resultaat van het verwoorden van de feiten op verschillende voorbeelddocumenten, onderzocht worden. Hierbij worden de zinnen opgesplitst in vaste en variabele delen. Voor elk variabel deel moet dan, door middel van de zogenaamde wat- en hoe-vraag, vastgesteld worden waar het naar verwijst. Dit achterhalen van de structuur van de feiten is een recursief proces, waarbij telkens de wat of hoe-vraag kan worden gesteld. Deze derde analysestap in de UI is in feite een tussenstap met als doel te komen tot een diagram waarin de structuur van de feiten op een overzichtelijke wijze weergegeven wordt. De structuur van de feiten is een belangrijk element in het goed doorzien van de relevante informatie van een onderwerp.

17

Hoofdstuk 3


Met behulp van Figuur 3-2 en Figuur 3-3 zal ik hieronder een uitwerking geven van deze analysestap, waarbij ik gebruik maak van de volgende verwoording (bestaande uit 2 feiten): 1) 2)

Het artikel 63653 heeft als prijs het bedrag van ƒ 20,45. “ “ 75342 “ “ “ “ “ “ ƒ 1,50.

3.7.1 Klassificatie

De eerste stap in deze deelanalyse is het klassificeren van de feiten. Dit klassificeren valt te vergelijken met zinsontleding: we bepalen welke zinsdelen vast zijn en welke delen variabel zijn. Hierbij splitsen we de zin op in een naamwoordelijk zinsdeel (NWD) en een werkwoordelijk zinsdeel (WWD). Door verschillende instanties van hetzelfde feit te noteren met behulp van aanhalingstekens, hebben we tijdens het verwoorden van de feiten een deel van de klassificatie al uitgevoerd. De aanhalingstekens representeren de vaste delen. De variabele delen in deze zinnen zijn de zogenaamde individuele namen (IN), dus: 63653, 20,45, 75342, 1,50, 371, 53533, 22-05-94, 182, 80142 en 12-10-94. Deze individuele namen verwijzen naar een begrip: 63653 en 75342 verwijzen naar een artikel 20,45 en 1,50 verwijzen naar een bedrag 371 en 182 verwijzen naar een volgnummer van een bon 53533 en 80142 verwijzen naar een horecaondernemer 22-07-00 en 12-10-00 verwijzen naar een datum Met behulp van de wat- en de hoe-vraag kunnen we het naamwoordelijk en het werkwoordelijk deel van de zin bepalen. Om er achter te komen naar welk begrip een individuele naam verwijst, kunnen we de wat-vraag stellen: “Wat stelt deze individuele naam voor?”. Bijvoorbeeld: “Wat stelt 75342 voor?”, waarop het antwoord luidt: “Een specifiek artikel.”. Daarnaast kunnen we met de hoe-vraag ook nog achterhalen hoe een begrip aangeduid of geïdentificeerd wordt, bijvoorbeeld: “Hoe duiden we een specifiek artikel aan?”, waarop het antwoord luidt: “Met een artikelnummer.”. Als er vaste zinsdelen in de te onderzoeken zinnen staan die een antwoord zijn op de wat- of hoevraag, dan vormen deze delen één geheel met de individuele naam. Het naamwoordelijk deel wordt gevormd door de constante delen die één geheel vormen met de individuele naam, inclusief de individuele naam. Iedere zin moet minimaal één naamwoordelijk deel bevatten. De rest van de zinsdelen vormen het werkwoordelijk deel dat in grote mate de betekenis van de zin bepaalt, waarbij de naamwoordelijke delen de context bepalen waarin die betekenis tot zijn recht komt. Als we dit toepassen op de twee feiten, krijgen we de volgende klassificatie: 1) 2)

NWD Het artikel 63653 “ “ 75342

WWD heeft als prijs “ “ “

NWD het bedrag van ƒ 20,45. “ “ “ ƒ 1,50.

18

Hoofdstuk 3


3.7.2 Kwalificatie

De tweede stap in deze deelanalyse is het kwalificeren van de naamwoordelijke delen: het vervangen ervan door de antwoorden op de wat- en hoe-vraag: “Wat stelt de individuele naam voor?”. Als we dit toepassen op de twee feiten, krijgen we: 1.1) 1.2) 2.1) 2.2)

“Wat “Wat “Wat “Wat

stelt stelt stelt stelt

de de de de

individuele individuele individuele individuele

naam naam naam naam

63653 voor?” 20,45 voor?” 75342 voor?” 1,50 voor?”

De individuele namen 63653 en 75342 stellen specifieke artikelen voor en de individuele namen 20,45 en 1,50 stellen specifieke bedragen voor. Een verzameling van alle mogelijke individuele namen noemen we een BegripType. Zo noemen we de verzameling van alle mogelijke specifieke artikelen en alle mogelijke specifieke bedragen bijvoorbeeld het BegripType Artikel respectievelijk het BegripType Bedrag. Met bovenstaande twee antwoorden kunnen we een sjabloon maken, waarmee we een aantal creaties kunnen creëren die bepaalde kenmerken gemeenschappelijk en andere verschillend hebben. Het doel van zo’n sjabloon is dat men met behulp van de individuele namen de zinnen kan regenereren zoals de gebruiker ze wil hebben. Met behulp van de antwoorden op de wat-vraag, kunnen we het sjabloon FeitTypeFormulering (FTF) (een eigen formulering van de feitregel) opstellen. Dit doen we door in het naamwoordelijk zinsdeel het antwoord op de wat-vraag tussen visgraathaken te zetten. Deze visgraathaken geven de invulplaatsen aan. We kunnen deze methode toepassen op de twee feiten (we noemen het FeitType bijvoorbeeld Artikelprijs): 1) 2)

NWD Het artikel 63653 “ “ 75342

WWD heeft als prijs “ “ “

NWD het bedrag van ƒ 20,45. “ “ “ ƒ 1,50.

Vervanging van naamwoordelijke delen door antwoord op wat-vraag. FTF1:

heeft

als

prijs

.

Hiermee hebben we de gewenste zin echter nog niet precies kunnen genereren. Daarvoor moeten we weten hoe de elementen van een BegripType geïdentificeerd worden. Dit kan met behulp van de hoe-vraag: “Hoe wordt een individueel element van een BegripType geïdentificeerd?”. Als we dit toepassen op de twee feiten, krijgen we: 1)

2)

“Hoe wordt een individueel element van het BegripType Artikel geïdentificeerd?” “Hoe wordt een individueel element van het BegripType Bedrag geïdentificeerd?”

Het antwoord op deze vragen luidt: 1.1) 1.2) 2.1) 2.2)

63653 duidt een artikel aan. ƒ 20,45 duidt een bedrag aan. 75342 duidt een artikel aan. ƒ 1,50 duidt een bedrag aan.

19

Hoofdstuk 3


Een specifiek artikel wordt dus aangeduid door een artikelnummer en een specifiek bedrag wordt aangeduid door een getal. De zinnen 1.1, 1.2, 2.1 en 2.2 zijn zogenaamde DoopFeiten. Een DoopFeit is een overeenkomst waarin een afspraak gemaakt wordt, bijvoorbeeld: vanaf nu duidt 63653 dit specifieke artikel aan en vanaf nu duidt 75342 dat specifieke artikel aan. DoopFeiten zijn weer te gebruiken in andere FeitTypen. Voor bovenstaande DoopFeiten kan weer een nieuw sjabloon FeitTypeFormulering opgesteld worden. Na klassificatie en kwalificatie krijgen we dan het volgende: 1.1) 2.1)

NWD 63653 75342

WWD duidt een artikel aan. “ “ “ “

Vervanging van het naamwoordelijke deel door het antwoord op de hoe-vraag. FTF2: duidt een artikel aan.

Hetzelfde kunnen we dan doen voor het BegripType Bedrag: 1.2) 2.2)

NWD WWD ƒ 20,45 duidt een bedrag aan. ƒ 1,50 “ “ “ “ Vervanging van naamwoordelijke deel door antwoord op hoe-vraag.

FTF3: duidt een bedrag aan.

Bij een BegripType hoort een zogenaamde BegripTypeFormulering (BTF). FTF2 en FTF3 worden in het hoofdsjabloon FTF1 niet in de vorm van een feit, maar in zijn zelfstandigheid of nominalisatie gebruikt. Hierdoor verkrijgen we de volgende BegripTypeFormuleringen: BTF1: Het artikel BTF2: Het bedrag van ƒ

Bij de invulplaats in FTF2 en BTF1 en in FTF3 en BTF2 worden dezelfde individuele namen ingevuld. Het invullen van FTF2 en FTF3 levert een zin op. Het invullen van BTF1 en BTF2 levert slechts een onderdeel van een zin op, namelijk de zelfstandigheid. Deze zelfstandigheid wordt in een andere zin gebruikt waarin wel een werkwoord aanwezig is: FTF1: heeft als prijs .

Invulplaats in FTF1 vervangen we door BTF1: Het artikel en invulplaats in FTF1 vervangen we door BTF2: Het bedrag van ƒ . BTF1 hoort bij FTF2 en BTF2 hoort bij FTF3. 20

Hoofdstuk 3


Het vervangen van de naamwoordelijke delen op de wat- en hoe-vraag stopt, als een individuele naam naar zichzelf verwijst. Bij de klassificatie van “1.1) 63653 duidt een artikel aan.”, is ‘duidt een artikel aan’ toegewezen aan het werkwoordelijke deel. Op de wat-vraag kunnen we nu niet meer antwoorden dat 63653 naar een artikel verwijst; 63653 verwijst namelijk naar zichzelf. Dat betekent dat we aan het einde van de vervanging voor de invulplaats in FTF1 zijn gekomen. Indien een individuele naam naar zichzelf verwijst, noemen we de verzameling van zulke individuele namen een NaamType. De invulplaatsen in de BegripTypeFormuleringen worden dan opgevuld door elementen uit de NaamTypen. Zo worden de invulplaatsen in BTF1 en BTF2 opgevuld door elementen uit het NaamType Artikelnummer respectievelijk het NaamType Getal. Voor elk NaamType wordt een NaamTypeFormulering (NTF) opgesteld: NTF1: <…> NTF2: <…>

Dimensie ƒ

De drie puntjes binnen de visgraathaken geven aan dat er niet verder gesubstitueert hoeft te worden. Optioneel kan er voor of na de visgraathaken een stukje tekst volgen; zo wordt met “Dimensie ƒ” aangegeven dat we voor een getal het florijnteken zetten. Dit hele proces van substituering kunnen we schematisch als volgt weergeven: FTF1: heeft als prijs . substitueer door BTF1 FTF1a: Het artikel heeft als prijs . substitueer door NTF1 FTF1b: Het artikel <...> heeft als prijs . substitueer door BTF2 FTF1c: Het artikel <...> heeft als prijs het bedrag van . substitueer door NTF2 FTF1d: Het artikel <...> heeft als prijs het bedrag van ƒ <...>.

Figuur 3-4: Substituering van de invulplaatsen in de FeitTypeFormulering (behorende bij het FeitType Artikelprijs) door Begrip- en NaamTypeFormuleringen [Bron: Eggink 1995: 51]

In FTF1 (de FeitTypeFormulering van het FeitType Artikelprijs) staan twee variabelen. Het is de bedoeling om deze weg te werken middels substituering. We beginnen met de eerste variabele. Als nominalisatie van FTF1 verkrijgen we BTF1. De daaruit voortkomende FeitTypeFormulering FTF1a bevat nog steeds de variabele 21

Hoofdstuk 3


Artikelnummer, dus moeten we die invulplaats verder substitueren. Als we nu de watvraag stellen, dan kunnen we niet meer antwoorden dat 63653 naar een artikel verwijst; 63653 verwijst naar zichzelf. Dit heeft tot gevolg dat Artikelnummer vervangen wordt door NTF1, resulterend in FTF1b. Hieruit kunnen we opmaken dat het vervangingsproces voor de variabele Artikel afgerond is. Dezelfde procedure kunnen we nu volgen voor de variabele Bedrag. Uit het klassificatie- en kwalificatieproces kunnen we opmaken dat het vaststellen van de structuur van de feiten een recursief proces is, waarbij we telkens de wat- en hoevraag stellen. Het blijkt dat de structuur van de feiten een belangrijk element in het goed doorzien van de relevante informatie van een onderwerp is. Verder blijkt dat het vaststellen van de structuur van de feiten een tussenstap is met als doel te komen tot een diagram waarin de structuur van de feiten op een overzichtelijke wijze weergegeven wordt. Het diagrammiseren is het onderwerp van de volgende paragraaf.

3.8 Diagrammisatie

Het voordeel van zinnen uit de natuurlijke taal is dat ze zowel voor de gebruiker als voor de informatieanalist goed te begrijpen zijn, wat de communicatie tussen beide bevordert. Het nadeel is echter dat bij een groot aantal zinnen het overzicht en het inzicht in het verband tussen de zinnen snel verloren gaat. Om dit te voorkomen, maken we gebruik van een diagramtaal, de reeds genoemde InformaticaGrammaticaDiagrammen (IGD) (zie Eggink 1995: 65-75). Met behulp van deze diagrammen kan dan een snellere communicatie plaatsvinden. Een IGD levert een grammaticale verzameling feiten op waarin de FeitTypen ontleend aan een concreet voorbeeld goed te onderscheiden zijn. De oorspronkelijke feiten, zoals 371 en 182 voor het volgnummer van een bon of 53533 en 80142 voor de aanduiding van een horecaondernemer, vormen de representatieve populatie van het diagram. Na het verwoorden en het vaststellen van de structuur van alle feiten van de in Figuur 3-2 en Figuur 3-3 weergegeven voorbeelddocumenten ontstaat er een InformatieGrammatica (IG). De twee feiten die in paragraaf 3.7 als voorbeeld genomen zijn, vormen hier een onderdeel van. Met behulp van de volledige IG (zie Figuur 3-5), zal ik de diagrammatisatiestap toelichten. FeitType : FTF1 :

FT1 is opgesteld op .

BegripType : FTF1 : BTF1 :

Bon Er is een bon van . De bon van


Horecaondernemer Er is een horecaondernemer . De horecaondernemer

NaamType : NTF1 :

Klantnummer <...>

NaamType : NTF1 :

Volgnummer <...>

22

Hoofdstuk 3 BegripType : FTF1 : BTF1 :

De Universele Informatiekunde Datum Er is een datum .

NaamType : NTF1 :

Datumaanduiding <...>

FeitType : FTF1 :

FT2 is uitgeschreven om <Tijdstip>.


Tijdstip Er is een tijdstip <Tijdsaanduiding>. <Tijdsaanduiding>

NaamType : NTF1 :

Tijdsaanduiding <...>

FeitType : FTF1 :

FT3 staat op .

BegripType : FTF1 : BTF1 : NaamType : NTF1 : BegripType : FTF1 : BTF1 :

Artikel duidt een artikel aan. Het artikel Artikelnummer <...> Bonregel Er staat een bonregel op . De bonregel van

NaamType : NTF1 :

Regelnummer <...>

FeitType : FTF1 :

Artikelomschrijving is bekend onder .

NaamType : NTF1 :

Omschrijving De omschrijving <...>

FeitType : FTF1 :

Artikelprijs heeft als prijs .


Bedrag ƒ duidt een bedrag aan. Het bedrag van ƒ

NaamType : NTF1 :

Getal <...>

FeitType : FTF1 :

FT4 bestaat uit artikelen.


Aantal Er is een aantal van .

FeitType : FTF1 :

Subtotaal heeft als subtotaal.

FeitType : FTF1 :

Totaalbedrag komt in het totaal neer op .

Figuur 3-5: InformatieGrammatica [Bron: Eggink 1995: 59-60]

23

Hoofdstuk 3


De bovenstaande IG geeft aan welke feiten in de informatiebank komen. Om de zinnen op een overzichtelijke wijze weer te kunnen geven, zonder het inzicht in het verband tussen de zinnen en zinstypen te verliezen, kan deze IG volledig gelijkwaardig worden weergegeven door middel van een IGD. Bij zo’n IGD wordt gebruik gemaakt van onderstaande conventies. Een voorbeeld van de verschillende diagramconventies is te vinden in Figuur 3-14 op pagina 30.

DIAGRAMCONVENTIES VAN DE IGD-TAAL Een rechthoek duidt een invulplaats (een Rol) aan, die deel uitmaakt van een FeitType met één Rol (unair FeitType). Twee aaneengesloten rechthoeken duiden een FeitType met twee Rollen (binair FeitType) aan. FeitTypen met meerdere Rollen zijn ook mogelijk (ternair, quaternair, etc.).

Een feittypesymbool binnen een ovaal duidt een FeitType aan dat verzelfstandigd of genominaliseerd is tot een BegripType.

Een BegripType dat via een lijntje met een rechthoek verbonden is, verbeeldt dat elk individueel begrip van dat BegripType de betreffende Rol in een zin kan vervullen. Een gesloten cirkel die via een lijntje met een rechthoek verbonden is, duidt een BegripType aan waarvan elk individueel begrip de betreffende Rol in een zin vervult. Een gestippelde cirkel duidt een NaamType aan. Een NaamType dat via een lijntje met een rechthoek verbonden is, duidt aan dat elke individuele naam van dat NaamType in een zinvoorbeeld de betreffende Rol vervult.

Figuur 3-6: Diagramconventies van de IGD-taal [Bron: Eggink 1995: 65]

In veel opzichten kan de UI vergeleken worden met het KL-ONE (“Knowledge Language One”) representatiesysteem van R.J. Brachman. Dit is een representatiesysteem “dat gebruik maakt van diagramconcepten die gestructureerde omschrijvingen, klassificaties en gevolgtrekkingen representeert” (zie Brachman 1991: 1) en veelal toegepast wordt in het vakgebied van de kunstmatige intelligentie. Het is de bedoeling om alle definities van de Feit-, Begrip- en NaamTypen van de InformatieGrammatica uit Figuur 3-5 in een IGD te verwerken. Voor het uiteindelijke resultaat van het diagrammiseren maakt het niet uit met welke definitie begonnen wordt. 24

Hoofdstuk 3


Aan de hand van een aantal definities uit Figuur 3-5 zal ik in paragrafen 3.8.1, 3.8.2 en 3.8.3 de diagrammisatie van respectievelijk een FeitType, een BegripType en een NaamType nader toelichten. In paragraaf 3.8.4 volgt een beschrijving hoe het diagram na volledige diagrammisatie van de FeitTypen gecontroleerd kan worden. In paragraaf 3.8.5 wordt een volledig voorbeeld van een IGD weergegeven.

3.8.1 FeitType diagrammiseren

Als we naar FeitType FT1 in Figuur 3-5 kijken, zien we dat er twee invulplaatsen zijn: en . Deze invulplaatsen worden ook wel Rollen genoemd. We hebben hier dus te maken met een binair FeitType. Iedere Rol binnen het diagram krijgt een unieke naam, bijvoorbeeld R3 voor de Rol en R4 voor de Rol . De naam van het FeitType wordt rechtsboven het FeitType cursief afgedrukt en de FeitTypeFormulering (FTF1: is opgesteld op .) wordt onder het FeitType geplaatst. Als een FeitType meerdere FeitTypeFormuleringen bevat, dan worden deze allemaal onder elkaar onder het FeitType geplaatst. Onder de rollen worden vervolgens representatieve verzamelingen van de feiten gezet die verkregen zijn door middel van de klassificatie en kwalificatie van het FeitType. Als we deze regels toepassen op FeitType FT1, verkrijgen we het volgende: FT1 R3

R4

FTF1: is opgesteld op . 371 53533 22-07-00 182 80142 12-10-00

Figuur 3-7: Diagrammisatie van een FeitType [Bron: Eggink 1995: 67]

N.B. Onder de Rol R3 staan steeds twee individuele namen, omdat een bon uniek aangeduid wordt door de combinatie van een klanten volgnummer van de bon.

3.8.2 BegripType diagrammiseren

Rollen in een FeitType worden gespeeld door een Begrip- of NaamType. In deze paragraaf worden alleen de BegripTypen behandeld. De invulplaats in de FeitTypeFormulering van FTF1 uit het FeitType FT1 verwijst naar het BegripType Bon en de invulplaats verwijst naar het BegripType Datum. Één van de Rollen uit het FeitType FT1 moet dus door het BegripType Bon gespeeld worden, de andere moet gespeeld worden door het BegripType Datum. Uit Figuur 3-7 kunnen we opmaken dat Rol R3 door het BegripType Bon en Rol R4 door het BegripType Datum gespeeld wordt, immers: onder Rol R3 staan de instanties van het BegripType Bon en onder Rol R4 staan de instanties van het BegripType Datum. Als we naar het BegripType Bon in Figuur 3-5 kijken, zien we dat er weer twee invulplaatsen zijn: en . We hebben hier dus te maken met twee Rollen (een binair BegripType), die ook ieder weer een unieke naam krijgen, bijvoorbeeld R1 voor de Rol en R2 voor de Rol 25

Hoofdstuk 3


. De naam van het BegripType wordt boven het BegripType afgedrukt. Verder wordt boven het BeripType de BegripTypeFormulering gezet en onder het BegripType komt de bijbehorende FeitTypeFormulering te staan. Onder de rollen worden vervolgens representatieve verzamelingen van de feiten gezet die de individuele begrippen van het BegripType representeren. Het BegripType Datum bestaat slechts uit één invulplaats: . In dit geval krijgen we maar één Rol (een unair BegripType), waarbij we dezelfde procedure kunnen opvolgen als bij het BegripType Bon: de Rol krijgt de unieke naam R6, de BegripTypenaam Datum en de BegripTypeFormulering worden aan de bovenkant van het BegripType vermeld, de FeitTypeFormulering komt aan de onderkant en onder de rol wordt de representatieve verzameling feiten weergegeven. De Rollen R1 en R2 uit het BegripType Bon en Rol R6 uit het BegripType Datum moeten ook weer gespeeld worden door een Begrip- of NaamType. De enige Rol die nog gespeeld wordt door een BegripType is R2; de overige Rollen worden gespeeld door NaamTypen (zie 3.8.3 NaamType diagrammiseren). In de verschillende formuleringen voor het BegripType Bon wordt door de term verwezen naar het BegripType Horecaondernemer. De Rol R2 wordt dus door het BegripType Horecaondernemer gespeeld. Dit is een unair BegripType, omdat deze slechts de invulplaats heeft. Ook hier volgen we weer de procedure voor het diagrammiseren van een BegripType: de Rol krijgt de unieke naam R5, de BegripTypenaam Horecaondernemer en de BegripTypeFormulering worden aan de bovenkant van het BegripType vermeld, de FeitTypeFormulering komt aan de onderkant en onder de rol wordt de representatieve verzameling feiten weergegeven. We hebben nu alle BegripTypen die onder het FeitType FT1 vallen, gehad. We kunnen deze BegripTypen met behulp van bovenstaande regels als volgt diagrammiseren: Horecaondernemer BTF1: De horecaondernemer

Datum BTF1:

R5

R6

FTF1: Er is een horecaondernemer .

FTF1: Er is een datum .

53533 80142

22-07-00 12-10-00

Bon BTF1: De bon van R1

FTF1: Er is een bon van . 371 182

FT1

R2

53533 80142

R3

R4

FTF1: is opgesteld op . 371 182

53533 22-07-00 80142 12-10-00

Figuur 3-8: Diagrammisatie van BegripTypen [Bron: Eggink 1995: 71]

N.B. Een BegripType wordt door middel van een lijn verbonden aan de Rol van het FeitType waar deze bij hoort.

26

Hoofdstuk 3


3.8.3 NaamType diagrammiseren

Na het diagrammiseren van de BegripTypen, moeten tot slot de NaamTypen nog aan het IGD toegevoegd worden. Uit de InformatieGrammatica van Figuur 3-5 blijkt dat het FeitType FT1 drie NaamTypen bevat, die elk een BegripType spelen: 1. Klantnummer: in de verschillende formuleringen van het BegripType Horecaondernemer verwijst de term naar het NaamType Klantnummer. Het NaamType Klantnummer speelt dus de Rol R5 van het BegripType Horecaondernemer. 2. Volgnummer: in de verschillende formuleringen van het BegripType Bon verwijst de term naar het NaamType Volgnummer. Het NaamType Volgnummer speelt dus de Rol R1 uit het BegripType Bon. 3. Datumaanduiding: in de verschillende formuleringen van het BegripType Datum verwijst de term naar het NaamType Datumaanduiding. Het NaamType Datumaanduiding speelt dus de Rol R6 uit het BegripType Datum. De drie bovenstaande NaamTypen fungeren als een soort container die de individuele namen van het type Klantnummer, Volgnummer en Datumaanduiding bevatten. Zo bevat Klantnummer onder andere de individuele namen ‘53533’ en ‘80142’. Een volledig IGD van FeitType FT1 waaraan de NaamTypen zijn toegevoegd, resulteert in Figuur 3-9: Volgnummer NTF1: <…>

Klantnummer NTF1: <…>

Datumaanduiding NTF1: <…>

Horecaondernemer BTF1: De horecaondernemer

ddmm-jj

Datum BTF1:

R5

R6

FTF1: Er is een horecaondernemer .

FTF1: Er is een datum .

53533 80142

22-07-00 12-10-00

Bon BTF1: De bon van R1


FT1

R2

53533 80142

R3

R4

FTF1: is opgesteld op . 371 182

53533 22-07-00 80142 12-10-00

Figuur 3-9: Diagrammisatie van NaamTypen [Bron: Eggink 1995: 71]

N.B. Een NaamType wordt door middel van een lijn verbonden aan de Rol van het BegripType waar deze bij hoort. In het NaamType Datumaanduiding is de dimensie van de datumaanduiding weergegeven in eenheden van dagen, maanden en jaren. Zo kunnen ook eenheden van bedragen (ƒ), temperaturen (°C), etc. 27

Hoofdstuk 3


aangegeven worden. Op die manier hoeven deze eenheden niet meer voor iedere individuele naam van een NaamType herhaald te worden.

3.8.4 Controle van de diagrammisatie

Nu het IGD voor FeitType FT1 volledig is, kan er een controle plaatsvinden of het diagram daadwerkelijk klopt. Dit gebeurt door de oorspronkelijke feiten op te stellen met behulp van het diagram. We nemen hiervoor de FeitTypeFormulering FTF1 van het FeitType FT1 ( is opgesteld op .), waarbij we de BegripTypeFormuleringen substitueren van de BegripTypen Bon en Datum. Dit wordt weergegeven in Figuur 3-10. BTF1: De bon van

BTF1:

FTF1: is opgesteld op . 371 53533 22-07-00 substitueer door BegripTypeFormuleringen van BegripTypen Bon en Datum FTF1: De bon van is opgesteld op . 371 53533 22-07-00

Figuur 3-10: Controle IGD – Substituering BegripTypen [Bron: Eggink 1995: 71]

Vervolgens moeten we de Naam- en BegripTypeFormuleringen van Volgnummer, Horecaondernemer en Datumaanduiding substitueren. Dit wordt weergegeven in Figuur 3-11. NTF1: <...>

BTF1: De horecaondernemer

NTF1: <...>

FTF1: De bon van is opgesteld op . 371 53533 22-07-00 substitueer door BegripTypeFormuleringen van BegripType Horecaondernemer en door NaamTypeFormuleringen van NaamTypen Volgnummer en Datumaanduiding FTF1: De bon <...> van de horecaondernemer is opgesteld op <...>. 371 53533 22-07-00

Figuur 3-11: Controle IGD – Substituering Begrip- en NaamTypen [Bron: Eggink 1995: 72]

In de onderste FeitTypeFormulering FTF1 van Figuur 3-11 hoeft alleen nog maar de NaamTypeFormulering van het NaamType Klantnummer te worden gesubstitueerd. Dit resulteert in Figuur 3-12. NTF1: <...>

FTF1: De bon <...> van de horecaondernemer is opgesteld op <...>. 371 53533 22-07-00 substitueer door NaamTypeFormulering van NaamType Klantnummer FTF1: De bon <...> van de horecaondernemer <...> is opgesteld op <...>. 371 53533 22-07-00

Figuur 3-12: Controle IGD – Substituering NaamType [Bron: Eggink 1995: 72]

28

Hoofdstuk 3


De laatste FeitTypeFormulering FTF1 van Figuur 3-12 bevat slechts NaamTypen. Op de plaats van de puntjes kunnen nu de individuele namen ingevuld worden. Op deze manier verkrijgen we het oorspronkelijke feit weer (zie Figuur 3-13). FTF1: De bon <...> van de horecaondernemer <...> is opgesteld op <...>. 371 53533 22-07-00

De bon 371 van de horecaondernemer 53533 is opgesteld op 22-07-00.

Figuur 3-13: Controle IGD – Opstellen van het oorspronkelijke feit [Bron: Eggink 1995: 72]

3.8.5 Een volledig IGD-voorbeeld

In de vorige paragrafen is alleen het FeitType FT1 gediagrammiseerd. Figuur 3-14 geeft het complete IGD van de InformatieGrammatica uit Figuur 3-5 weer. Bij het verder diagrammiseren kan het geval zich voordoen dat er verwijzingen zijn naar Begrip- en/of NaamTypen die reeds uitgewerkt zijn bij het diagrammiseren van FeitType FT1. Deze Begrip- en/of FeitTypen hoeven dan niet opnieuw uitgewerkt te worden; er hoeft slechts een lijn getrokken te worden naar het reeds bestaande Begrip- en/of NaamType. In Figuur 3-14 is een verkorte notatiewijze voor de unaire BegripTypen gehanteerd. Als we naar het unaire BegripType Horecaondernemer kijken, zien we dat er in dit geval alleen feiten over horecaondernemers waarvoor aankoopbonnen bestaan, vastgelegd worden. Met andere woorden: alle klantnummers van horecaondernemers komen voor onder de Rol R2. Dit houdt in dat de Rol R2 onderhevig is aan een zogenaamde VerplichteRolRegel, wat aangegeven wordt door VRR1 in Figuur 3-15. VRR1 geeft aan dat alle begrippen van het type Horecaondernemer voorkomen onder de Rol R2. De FeitTypeFormulering FTF1 behorende bij het BegripType Horecaondernemer, waarmee aangegeven kan worden dat begrippen van het type Horecaondernemer bestaan, is nu overbodig. Doordat de begrippen ‘53533’ en ‘80142’ de Rol R2 populeren, is het bekend dat ze bestaan en kan het begrip Horecaondernemer verkort worden weergegeven. Een bon wordt uniek aangeduid door een combinatie van een klanten volgnummer. Daarom worden deze waarden onder de rollen R3, R5 en R7 in Figuur 3-14 samengenomen. Zo is 371 bijvoorbeeld een volgnummer waarmee meerdere bonnen van verschillende klanten kunnen worden aangeduid, bijvoorbeeld: 371 voor klant met klantnummer 53533 en 371 voor een klant met klantnummer 80142.

29

Hoofdstuk 3

De Universele Informatiekunde Horecaondernemer (Klantnummer)

Volgnummer NTF1: <…>

Datum (Datumaanduiding)

FT1 R3

FTF1: is opgesteld op .

BTF1: De horecaondernemer <...> Bon

371 182

53533 22-07-00 80142 12-10-00

BTF1: De bon van R1

R5

HH:MM

R6

FTF1: is uitgeschreven op .

FTF1: Er is een bon van .

371 182

53533 80142

53533 80142

14:33 11:34

Regelnummer R7

BTF1: <...> Bedrag (Getal)

Totaalbedrag

NTF1: <…>

BTF1: <...> Tijdstip (Tijdsaanduiding)

FT2

R2

371 182

ddmm-jj

R4

ƒ...

R8

FTF1: komt in totaal neer op . 371 182

53533 80142

BTF1: Het bedrag van <...>

120,25 68,45

Bonregel BTF1: De bonregel van R9

Subtotaal

R10

R19

FTF1: Er staat een bonregel van . 371 371 182 182 182

53533 53533 80142 80142 80142

1 2 1 2 3

R11 53533 53533 80142 80142 80142

1 2 1 2 3

BTF1: <...>

63653 75342 40986 75342 12845

20,45 1,50 45,95 3,00 Omschrijving

Artikelomschrijving

R14

1 2 1 2 3

R18

63653 75342 40986 12845

Artikel (Artikelnummer)

R15

FTF1: staat op . 53533 53533 80142 80142 80142

102,25 18,00 45,95 7,50 15,00

FTF1: heeft als prijs .

FTF3

371 371 182 182 182

1 2 1 2 3

R17

5 12 1 5 5

R13

53533 53533 80142 80142 80142

Artikelprijs

R12

FTF1: bestaat uit artikelen. 371 371 182 182 182

371 371 182 182 182

Aantal (Getal)

FTF4

R20

FTF1: heeft als subtotaal.

R16

FTF1: is bekend onder .

BTF1: <...>

63653 75342 40986 12845

Broodblik Stapelglas Fileermes Dessertbord

NTF1: de omschrijving <…>

Figuur 3-14: Een volledig IGD-voorbeeld [Bron: Eggink 1995: 73] Horecaondernemer Klantnummer NTF1: <…>

BTF1: De horecaondernemer VRR1

•

R5

R2

FTF1: Er is een horecaondernemer . 53533 80142

53533 80142

verkorte notatie

Horecaondernemer (Klantnummer) R2 BTF1: De horecaondernemer <…>

53533 80142

Figuur 3-15: Verkorte notatie van een unair BegripType [Bron: Eggink 1995: 74]

30

Hoofdstuk 3


Naast de verkorte weergave van de unaire BegripTypen zijn ook de Begrip- en FeitTypeFormuleringen verkort weergegeven. In plaats van de namen van de Begrip- en NaamTypen tussen visgraathaken te zetten, worden nu de namen van de Rollen die door de Begrip- en NaamTypen gespeeld worden tussen visgraathaken gezet. Deze aanpassing wordt mogelijk gemaakt door het feit dat een Rol hooguit door één Begripof NaamType mag worden gespeeld.

3.8.6 NaamType preciseren

In paragraaf 3.8.3 zagen we dat we eenheden aan de individuele namen van een NaamType toe kunnen kennen. Daarnaast is het mogelijk om voor NaamTypen vast te leggen tot welk SchaalType de individuele namen behoren. Dit heeft als voordeel dat het dan precies duidelijk is welke operaties (is gelijk aan, is niet gelijk aan, is kleiner dan, is groter dan, aftrekken, optellen en delen) voor een bepaald SchaalType toegestaan zijn. Alle waarden die een individuele naam kan aannemen, vormen de schaal waartoe de individuele naam behoort. Er zijn vier SchaalTypen: de nominale schaal, de ordinale schaal, de interval schaal en de ratio schaal. Deze worden met behulp van de volgende zinnen hieronder nader toegelicht:

FT1: De militair met registratienummer 69.02.22.054 kreeg in het jaar 1988 de rang soldaat. FT2: De militair met registratienummer 69.02.22.054 heet Janssen. FT3: De militair met registratienummer 69.02.22.054 heeft 3 rangen doorlopen.

De individuele namen in bovenstaande zinnen zijn schuingedrukt. Uit de zinnen kunnen we opmaken dat we te maken hebben met vijf NaamTypen: Registratienummer, Jaartal, Rang, Naam en Aantal (Getal). We spreken van een nominale schaal als individuele namen van NaamTypen van elkaar te onderscheiden zijn zonder dat aan deze individuele namen een betekenis qua volgorde en hoeveelheid toegekend kan worden. De individuele namen van zulke NaamTypen kunnen slechts met elkaar vergeleken worden, waarbij alleen de operatoren = en ≠ van toepassing zijn. In een IGD wordt de nominale schaal aangegeven door middel van een hoofdletter N in het NaamType. De individuele namen uit de NaamTypen Registratienummer en Naam behoren tot deze categorie. Naam

NTF1: <…>

N

Bij een ordinale schaal kunnen de individuele namen van NaamTypen ook van elkaar onderscheiden worden, maar daarnaast is het ook mogelijk om aan deze individuele namen een betekenis qua volgorde toe te kennen. Hierbij kan gebruik gemaakt worden van de operatoren =, ≠, < en >. In een IGD wordt de ordinale schaal aangegeven door middel van een hoofdletter O in het Rang

NTF1: <…>

O

31

Hoofdstuk 3


NaamType. De individuele namen uit het NaamType Rang behoren tot deze categorie (immers: een korporaal is hoger dan een soldaat). We spreken van een interval schaal als naast het maken van onderscheid en het toekennen van betekenis qua volgorde aan de individuele namen van een NaamType ook aftrekken en optellen van toepassing zijn. Op de individuele namen van de interval schaal kunnen de operatoren =, ≠, <, >, - en + dus toegepast worden. In een IGD wordt de interval schaal aangegeven door middel van een hoofdletter I in het NaamType. De individuele namen uit het NaamType Jaartal behoren tot deze categorie (immers: jaartallen kunnen van elkaar afgetrokken en bij elkaar opgeteld worden). Jaartal

NTF1: <…>

I

Bij een ratio schaal zijn gehele getallen van elkaar te onderscheiden en er kan een betekenis qua volgorde aan gehele getallen toegekend worden. De gehele getallen worden hierbij vastgelegd in gehele getallen zelf. Daarnaast beschikt het NaamType GeheelGetal over een absoluut nulpunt, immers een aantal van 0 betekent ook daadwerkelijk 0 (dit in tegenstelling tot het jaartal 0). De volgende operatoren zijn van toepassing op de individuele namen van de ratio schaal: =, ≠, <, >, -, + en /. Rang

NTF1: <…>

R

3.9 Beperkingsregels

In de voorgaande paragrafen is beschreven hoe een IGD tot stand komt. Een IGD geeft de structuur van de zinnen weer die in een bepaald toepassingsgebied worden uitgesproken of relevant zijn voor een kennisgebied. Het IGD zoals weergegeven in Figuur 3-14 is echter nog niet compleet: er is nog niet voldoende aangegeven hoe de populatie van zinnen beperkt moet worden tot een zinvolle populatie. Niet alle combinaties van zinnen zijn immers altijd even zinvol. Met andere woorden: niet elke combinatie van individuele namen op de invulplaatsen in de zinnen is zinvol. Daarom moeten deze combinaties beperkt worden met behulp van BeperkingsRegels, welke aangeven aan welke beperkingen de populaties binnen zinnen onderhevig zijn. BeperkingsRegels kunnen op twee manieren opgesteld worden (zie Eggink 1995: 81): 1. Ze kunnen worden afgeleid uit toegestane en niet toegestane voorbeelden in de gebruikersnotatie. Bij een niet toegestaan voorbeeld kan de vraag “Wat is niet goed of niet toegestaan in dit voorbeeld.” gesteld worden. Met andere woorden: “Welke beperking wordt hier overtreden?”. 2. Ze kunnen ook worden afgeleid uit het bevolkte IGD. Bij een IGD met een representatieve populatie kan de vraag “Welke BeperkingsRegels kunnen uit deze representatieve populatie afgeleid worden?”, gesteld worden. Eggink noemt een achttal BeperkingsRegels. De twee meest voorkomende Beperkingsregels (de UniciteitsRegel en de VerplichteRolRegel) zal ik in paragrafen

32

Hoofdstuk 3


3.9.1 en 3.9.2 uitgebreid toelichten. De overige 6 licht ik kort toe in paragraaf 3.9.3. Zie voor diagrammatische voorbeelden bij deze BeperkingsRegels Eggink: 96-103.

3.9.1 UniciteitsRegel

Met de UniciteitsRegel (UR) kan de beperking opgelegd worden dat sommige individuele namen in zinnen niet dubbel mogen voorkomen in een IGD. Een UR wordt in een IGD weergegeven met een pijl boven de rol of combinatie van rollen waarop de UR van toepassing is. Deze pijl geeft dan aan dat de waarden onder die rol of combinatie van rollen hooguit één keer mogen voorkomen. De eerste manier waarop de UniciteitsRegels bepaald kunen worden, is door middel van het creëren van niet toegestane voorbeelden:


1

(1)

Volgnummer: 371

Artikel:

Artikelomschrijving:

63653

Broodblik

(2)


ƒ

Artikelprijs:

1,50

(4)

Aantal:

5

Totaalbedrag:


1

Artikel:

63653

(1)


Broodblik

(2)


ƒ

Artikelprijs:

1,50

(4)

Aantal:

12

Totaalbedrag:

(3)


ƒ

7,50

ƒ

7,50

(3)


ƒ

18,00

ƒ

18,00

Figuur 3-16: Een voorbeeld van een niet toegestaan voorbeeld ter bepaling van de URs [Bron: Eggink 1995: 83]

Uit bovenstaande figuur kunnen we opmaken dat het niet mogelijk is dat er twee bonnen zijn van de horecaondernemer 53533 met hetzelfde volgnummer 371. Dit wordt aangegeven met het kruis gevolgd door een 1. Daarnaast is het ook niet mogelijk dat op een aankoopbon van een horecaondernemer meerdere aankoopdata, tijdstippen en totaalbedragen kunnen worden genoteerd. Dit wordt op de voorbeelden weergegeven 33

Hoofdstuk 3


door kruisen met de nummers 2 t/m 4. Nummers 1 t/m 4 leiden tot de volgende combinaties met niet toegestane zinnen: 1) Er is een bon 371 van horecaondernemer 53533. “ “ “ “ 371 “ “ 53533. 2) De bon 371 van horecaondernemer 53533 is opgesteld op 22-07-00. “ “ 371 “ “ 53533 “ “ “ 29-07-00. 3) De bon 371 van horecaondernemer 53533 is uitgeschreven om 14:33. “ “ 371 “ “ 53533 “ “ “ 13:45. 4) De bon 371 van horecaondernemer 53533 komt in totaal neer op 7,50. “ “ 371 “ “ 53533 “ “ “ “ “ 18,00.

Met behulp van deze niet toegestane zinnen, kunnen we de UniciteitsRegels aanbrengen, wat resulteert in Figuur 3-17. Volgnummer NTF1: <…>

Horecaondernemer (Klantnummer) N

N

BTF1: De horecaondernemer <...> Bon BTF1: De bon van UR1_2 R1 371 371

R3

53533 53533

FT1 R4


(2)

371 371

53533 22-07-00 53533 29-07-00 UR5

R2

FTF1: Er is een bon van .

(1)

UR3

R5

FT2 R6


(3)

371 371

53533 53533 UR7 R7

14:33 13:45 Totaalbedrag R8

FTF1: komt in totaal neer op .

(4)

371 371

53533 53533

7,50 18,00


I

ddmm-jj

BTF1: <...> Tijdstip (Tijdsaanduiding)

I HH:MM BTF1: <...> Bedrag (Getal)

R ƒ... BTF1: Het bedrag van <...>

Figuur 3-17: Voorbeeld van een IGD met URs afgeleid met behulp van een niet toegestaan voorbeeld [Bron: Eggink 1995: 84]

Met UR1_2 voor het BegripType Bon wordt aangegeven dat voor elke horecaondernemer maar eenmaal een bon met volgnummer 371 mag worden uitgeschreven. Als er alleen een UR boven de Rol R1 zou komen, dan mag er maar één bon zijn met volgnummer 371 verdeeld over alle horecaondernemers. Als er alleen een UR over de Rol R2 zou staan, dan zou een horecaondernemer maar één keer inkopen kunnen doen bij de firma Hogros. Met UR3 wordt in het FeitType FT1 afgedwongen dat de bon 371 van horecaondernemer 53533 hooguit op één datum kan zijn uitgeschreven. Bij Rol R4 34

Hoofdstuk 3


ontbreekt een UR, omdat er meerdere aankoopbonnen kunnen zijn (ook van eenzelfde horecaondernemer) die op één datum kunnen worden uitgeschreven. Voor UR5 en UR7 geldt een soorgelijke beredenering. Een tweede manier om de UniciteitsRegels te bepalen is aan de hand van een IGD met een significante bevolking. Aan de hand van de significante populatie in Figuur 3-18 kunnen de volgende UniciteitsRegels afgeleid worden (het resultaat hiervan wordt ook weergegeven in Figuur 3-18): 1. Onder de Rol R17 komen geen dubbele waarden voor. Dit resulteert in een UniciteitsRegel UR17 over de Rol R17. 2. Onder de Rol R15 komen geen dubbele waarden voor. Dit resulteert in een UniciteitsRegel UR15 over de Rol R15. 3. Onder de Rol R18 komt meer dan eenmaal de waarde ‘1,50’ voor. Boven deze Rol mag dus geen UniciteitsRegel komen. 4. Onder de Rol R16 komt de waarde ‘Stapelglas’ meer dan eenmaal voor. Boven deze Rol mag dus ook geen UniciteitsRegel komen. geen UR Bedrag (Getal)

UR17

Artikelprijs

R17

R

R18

ƒ...


(1)

75342 12345 83653

1,50 1,50 3,00


(3)

geen UR Artikel (Artikelnummer)

UR15

N BTF1: <...>

Artikelomschrijving

R15

N

R16

FTF1: is bekend onder . Stapelglas 75342 12345 Wijnglas Stapelglas 83653

(2)

Omschrijving


(4)

Figuur 3-18: Voorbeeld van een IGD met URs afgeleid met behulp van een IGD met een significante populatie [Bron: Eggink 1995: 86]

Bij het achterhalen van UniciteitsRegels dient op een gestructureerde manier te werk gegaan te worden. Bij beide manieren van het afleiden van UniciteitsRegels gaat het er om er achter te komen wat representatief is. Dit kan via een procedure waarbij alle mogelijk combinaties van zinnen bedacht worden, waarbij uitgegaan wordt van een toegestane zin waarin vervolgens diagonaalsgewijs de waarden aangepast worden. Hieronder volgt een voorbeeld. Gesteld de FeitTypeFormulering FTF1 van het FeitType Artikelprijs uit Figuur 3-18: 1)

heeft als prijs . 75342 “ “ “ 1,50.

35

Hoofdstuk 3


Om te achterhalen wat representatief is, moeten er nieuwe zinnen bedacht worden. Vervolgens moet er gecontroleerd worden of deze nieuwe zinnen te combineren zijn met de eerste zin. Zo ja, dan komt er geen UniciteitsRegel boven de Rol, anders wel. 2) 3)

heeft als prijs . 75342 “ “ “ 2,50. (UR boven ?) 12345 “ “ “ 1,50. (UR boven ?)

Het antwoord op de tweede zin is uiteraard ‘nee’ (beide zinnen zijn niet te combineren). Één artikel kan immers niet twee prijzen hebben. Er komt dus een UR boven de Rol R17. Daarentegen is het best mogelijk dat een ander artikel ook als prijs de waarde ‘1,50’ heeft, dus komt er geen UR boven de Rol R18. Als het antwoord op beide zinnen 2 en 3 ‘nee’ zou zijn, dan had er een UR over de combinatie van de Rollen R17 en R18 moeten staan. Ter controle kopiëren we de eerste zin en controleren we of deze kopie samen met de eerste zin uitgesproken kan worden: 4)

heeft als prijs . 75342 “ “ “ 1,50. (UR boven en ?)

Het antwoord op de vierde zin is ‘ja’ (één artikel met een bepaalde prijs kan immers op meerdere bonnen voorkomen), dus er komt geen UR over de combinatie van de Rollen R17 en R18. Onderstaande figuur geeft nog eens een duidelijk beeld van deze procedure. We gaan hierbij uit van een toegestane zin, waarin vervolgens diagonaalsgewijs de waarden aangepast worden (aangegeven door de diagonale streep). 1) 2) 3) 4)

Artikel 75342 75342 12345 75342

Prijs ƒ 1,50 ƒ 2,50 ƒ 1,50 ƒ 1,50

Figuur 3-19: Vuistregel om alle mogelijke combinaties van zinnen te bedenken [Bron: Eggink 1995: 88]

Als er geen UniciteitsRegel gevonden kan worden, hebben we te maken met een feit dat één of meer Rollen mist. Dit kan zich voordoen als de combinatie van waarden bij een FeitType dubbel mag voorkomen. Uit de waarden kan dan niet afgeleid worden om welk feit het gaat. Er zijn dan waarden van meer Rollen nodig om het betreffende feit te identificeren. Hieruit kunnen we opmaken dat voor een elementair FeitType geldt dat er 36

Hoofdstuk 3


op zijn minst één UniciteitsRegel moet staan boven de combinatie van alle (n) Rollen van het FeitType. Bij een ternair FeitType moet een UniciteitsRegel altijd boven twee of drie Rollen staan en nooit boven één Rol. We hebben hier te maken met de (N-1)regel: een UniciteitsRegel moet minimaal over alle (N) rollen van een FeitType min 1 staan. Als er in een ternair FeitType wel een UniciteitsRegel boven één van de drie Rollen staat, hebben we te maken met een samengesteld FeitType; het FeitType kan dan opgesplitst worden zonder daarbij informatie te verliezen. In Figuur 3-23 zijn alle UniciteitsRegels in het IGD voor aankoopbonnen van de firma Hogros verwerkt.

3.9.2 VerplichteRolRegel

Voor het weergeven van de beperking dat sommige feiten moeten worden vastgelegd, bestaat in de UI een diagrammatische notatiewijze in de vorm van een stip die wordt aangeduid met de term VerplichteRolRegel (VRR). Zo’n VRR geldt voor een Rol die gespeeld wordt door het BegripType, waarvan alle begrippen moeten deelnemen aan een feit van het FeitType waar die Rol deel van uitmaakt. De eerste manier waarop de VerplichteRolRegels bepaald kunnen worden, is door middel van het creëren van niet toegestane voorbeelden:


1

Artikel:

63653


Broodblik

(1) Aankoopdatum: _____ ƒ

Artikelprijs:

1,50

(2) Tijdstip: _____

Aantal:

5

Totaalbedrag:

Subtotaal:

ƒ

7,50

ƒ

(3)

Figuur 3-20: Een voorbeeld van een niet toegestaan voorbeeld ter bepaling van de VRRs [Bron: Eggink 1995: 92]

Uit bovenstaande figuur kunnen we opmaken dat het niet mogelijk is dat op een aankoopbon de aankoopdatum [ (1)], het tijdstip [ (2)] en het totaalbedrag [ (3)] ontbreken, met andere woorden: VRR3:

∀x∃y Pxy

(elk artikel heeft een prijs)

VRR5:

∀x∃y Dxy

(elk artikel heeft een datum)

VRR7:

∀x∃y Txy

(elk artikel heeft een totaalbedrag)

Met behulp van dit niet toegestane voorbeeld, kunnen de VerplichteRolRegels (VRR3, VRR5 en VRR7) aangebracht worden, wat resulteert in Figuur 3-21. 37

Hoofdstuk 3



Horecaondernemer (Klantnummer) N

N

BTF1: De horecaondernemer <...>

UR3

VRR3

•

R3 371

BTF1: De bon van UR1_2

•

BTF1: <...>

(1)

Tijdstip (Tijdsaanduiding)

I

R6


53533

371

53533

UR7

VRR7

•

(2)

BTF1: <...>

R

R8

FTF1: komt in totaal neer op . 371

HH:MM

Bedrag (Getal)

Totaalbedrag

R7 53533

dd-

mm-jj

FT2

R5

FTF1: Er is een bon van . 371

53533 UR5

VRR5 R2

I

R4


Bon

R1


FT1

(3)

ƒ... BTF1: Het bedrag van <...>

Figuur 3-21: Voorbeeld van een IGD met VRRs afgeleid met behulp van een niet toegestaan voorbeeld [Bron: Eggink 1995: 93]

Een tweede manier om de VerplichteRolRegels te bepalen is aan de hand van een IGD met een significante bevolking. Aan de hand van de significante populatie in Figuur 3-22 kunnen de volgende VerplichteRolRegels afgeleid worden (het resultaat hiervan wordt ook weergegeven in Figuur 3-22): 1. Onder de Rol R17 komen dezelfde waarden voor als onder de Rol R100. Met andere woorden: van alle artikelen wordt een prijs vastgelegd (∀x∃y Pxy). Dit resulteert in een VerplichteRolRegel VRR17 voor de Rol R17. 2. Onder de Rol R15 komen dezelfde waarden voor als onder de Rol R100. Met andere woorden: voor alle artikelen wordt een omschrijving vastgelegd (∀x∃y Oxy). Dit resulteert in een VerplichteRolRegel VRR15 voor de Rol R15. VRR17

•

Artikelnummer NTF1: <…>

UR17 R17

Bedrag (Getal) Artikelprijs

R

R18

ƒ ...


N

(1)

75342 12345 83653


1,50 1,50 3,00

Artikelnummer BTF1: Het artikel R100 FTF1: Er is een artikel . 75342 12345 83653

VRR15

•

UR15 R15

Artikelomschrijving R16

FTF1: is bekend onder .

(2)

75342 12345 83653

Stapelglas Wijnglas Stapelglas

Omschrijving N


Figuur 3-22: Voorbeeld van een IGD met VRRs afgeleid met behulp van een IGD met een significante populatie [Bron: Eggink 1995: 94]

38

Hoofdstuk 3


In deze paragraaf is duidelijk geworden dat we moeten controleren op het bestaan van VerplichteRolRegels bij elk BegripType dat één of meerdere Rollen speelt. We kunnen deze VerplichteRolRegels onderzoeken door na te gaan of elk begrip van een BegripType bij de onderzochte Rol moet worden ingevuld. In Figuur 3-23 zijn alle VerplichteRolRegels, UniciteitsRegels en AfleidingsRegels verwerkt. Aan de laatstgenoemde soort regel wordt in paragraaf 3.11.2 Redundantie in de InformatieBank, meer aandacht besteed. Horecaondernemer (Klantnummer)


N

UR3

N

VRR3

•

BTF1: De horecaondernemer <...>

R3 371 182

BTF1: De bon van UR1_2 VRR5

•

R2

R5

371 182

53533 80142

I HH:MM

R6

53533 80142 UR7

Regelnummer NTF1: <…>

Tijdstip (Tijdsaanduiding)

FT2



BTF1: <...>

53533 22-07-00 80142 12-10-00 UR5

VRR9

R1

I ddmm-jj

R4


Bon

•


FT1

VRR7

•

N

BTF1: <...>

14:33 11:34

R7

R

R8

ƒ...

FTF1: komt in totaal neer op . 371 182

Bedrag (Getal)

Totaalbedrag* Subtotaal

53533 80142


120,25 68,45

Bonregel BTF1: De bonregel van UR9_10 R9

UR19 VRR19

•

R10

R19

FTF1: Er is een bonregel van . 371 371 182 182 182

53533 53533 80142 80142 80142

1 2 1 2 3

UR11

VRR11

•

FTF4

R11

FTF1: bestaat uit artikelen. 371 371 182 182 182

53533 53533 80142 80142 80142

1 2 1 2 3

5 12 1 5 5

UR13

VRR13

•

VRR17

BTF1: <...>

R14 1 2 1 2 3

•

63653 75342 40986 75342 12845

N BTF1: <...>

53533 53533 80142 80142 80142 UR17 R17

1 2 1 2 3

120,25 18,00 45,95 7,50 15,00 Artikelprijs R18

FTF1: heeft als prijs . 63653 75342 40986 12845

Artikel (Artikelnummer)

FTF1: staat op . 53533 53533 80142 80142 80142

371 371 182 182 182

Aantal (Getal)

FTF3

R13 371 371 182 182 182

FTF1: heeft als subtotaal.

R

R12

Subtotaal * FT3, FT4, Artikelprijs R20

VRR15

•

UR15 R15

20,45 1,50 45,95 3,00 Artikelomschrijving R16

FTF1: is bekend onder . 63653 75342 40986 12845

Broodblik Stapelglas Fileermes Dessertbord

Omschrijving N


Figuur 3-23: Een volledig IGD met UniciteitsRegels, VerplichteRolRegels en AfleidingsRegels [Bron: Eggink 1995: 95]

39

Hoofdstuk 3


3.9.3 Overige BeperkingsRegels DeelVerzamelingsRegel (DVR) Hiermee wordt aangegeven dat de populatie onder een Rol of combinatie van Rollen een deelverzameling is van de populatie onder een andere Rol of andere combinatie van Rollen, bijvoorbeeld: voor een sportdag moet men zich inschrijven voor de sporten waaraan men wil deelnemen. Iemand kan pas een medaille behalen voor een sport, wanneer hij zich daarvoor ingeschreven heeft. GelijkheidsRegel (GR) Hiermee wordt aangegeven dat de populatie onder een Rol of combinatie van Rollen gelijk moet zijn aan de populatie onder een andere Rol of andere combinatie van Rollen, bijvoorbeeld: op een school bestaan verschillende vakken uit een theoretisch en een praktisch deel. Beide delen moeten door de leerlingen behaald worden. UitsluitingsRegel (USR) Hiermee wordt aangegeven dat de populatie onder een Rol of combinatie van Rollen de populatie onder een andere Rol of andere combinatie van Rollen uit moet sluiten, zodat tegenstrijdigheden (tegenstrijdige feiten) voorkomen worden. Een leerling die bijvoorbeeld een hekel aan een vak heeft, kan dat vak tegelijkertijd niet leuk vinden. AantallenRegel (AR) Hiermee wordt aangegeven dat de populatie onder een Rol of combinatie van Rollen moet voldoen aan de gedefinieerde waarde die in de AantallenRegel is vermeld. WaardenRegel (WR) Om te voorkomen dat feiten worden vastgelegd die niet van belang zijn, kunnen WaardenRegels geïntroduceerd worden. Zo zou er voor een NaamType Taalnaam een WaardenRegel WR1 geïntroduceert kunnen worden die een reeks toegestane individuele namen specificeert, zodat met een BegripType Taal alleen de talen ‘Frans’, ‘Duits’, ‘Engels’ en ‘Spaans’ vastgelegd kunnen worden. AlgemeneBeperkingsRegel (ABR) Met deze regel kunnen beperkingen opgelegd worden die niet kunnen worden afgedwongen met de reeds besproken BeperkingsRegels. Voor een ABR bestaat niet een specifiek, maar een algemeen diagrammatisch symbool. In een IGD wordt van een ABR aangegeven op welke Rollen hij drukt. Aan de vorm valt echter niet op te maken met welk soort BeperkingsRegel men te maken heeft. De inhoud wordt daarom in een formele tekst vastgelegd. Stel: een groenteboer verkoopt zijn broccoli voor de halve prijs, mits zijn klanten daar dan ook tomaten bij kopen. ABR1: Een klant die broccoli koopt, moet ook tomaten kopen. 40

Hoofdstuk 3


3.10 FeitTypen als BegripTypen

In de natuurlijke taal maken mensen veel gebruik van zinnen in hun nominale vorm in andere zinnen. Een voorbeeld van zo’n zin is: “De bon 371 van de horecaondernemer 53533 is opgesteld op 22-05-94.”, waarbij “de bon 371 van de horeca-ondernemer 53533” de zelfstandige vorm is van de zin “Er is een bon 371 van de horeca-ondernemer 53533.” In de meeste gevallen ligt zo’n zelfstandige vorm van zinnen voor de hand, maar dit is niet altijd het geval. Stel: een doktor houdt op een formulier naast de persoonsgegevens de verschillende bezoeken van zijn patiënten bij. Bij elk bezoek (datum) noteert hij een aantal opmerkingen. Gesteld de volgende verwoording voor een patiënt met patiëntnummer P0105: 1) Bij patiënt P0105 is op 02-09-00 een pols van 80 slagen p/m 2) “ “ P0105 “ “ 09-09-00 “ “ “ 75 “ “ gemeten. “ 3) Bij patiënt P0105 is op 02-09-00 een diastole van 100 opgenomen. 4) “ “ P0105 “ “ 09-09-00 “ “ “ 80 “

Op het eerste gezicht lijkt de bovenstaande verwoording correct. Na het achterhalen van de structuur van de feiten, zou het volgende IGD opgesteld kunnen worden: Aantal slagen p/m (Getal)

UR1_2 R1

Polsslag R2

R3

FTF1: Bij is op een pols van gemeten. P0105 P0105

2-9-00 9-9-00

80 75

R BTF1: <...>

Patiënt Datum (Patiëntnummer)(Datumaanduiding)

I

ddmm-jj

R

BTF1: <...>

BTF1: De patiënt <...>

Aantal mm Hg (Getal)

UR4_5 R4

Bloeddruk R5

R6

FTF1: Bij is op een diastole van opgenomen. P0105 P0105

2-9-00 9-9-00

100 88

R BTF1: <...>

Figuur 3-24: FeitTypen als BegripTypen 1 [Bron: Eggink 1995: 110]

Uit Figuur 3-24 blijkt dat zowel het FeitType Polsslag als Bloeddruk betrekking hebben op de combinatie van de BegripTypen Patiënt en Datum. Deze BegripTypen vormen samen een nieuw BegripType Onderzoek. Immers, de informatie die de doktor op het formulier van een patiënt bijhoudt, zijn eigenlijk resultaten van een onderzoek. Aan bovenstaande verwoording zouden dan de volgende twee feiten toegevoegd kunnen worden: 41

Hoofdstuk 3


5) De patiënt P0105 is op 02-09-00 onderzocht. 6) “ “ P0105 “ “ 09-09-00 “

Met behulp van de feiten 5 en 6 in hun zelfstandige vorm, kunnen we feiten 1 t/m 4 ook als volgt verwoorden: 1) Tijdens het onderzoek van patiënt P0105 op 02-09-00 is een pols 2) “ “ “ “ “ P0105 “ 09-09-00 “ “ “ van 80 slagen p/m gemeten. “ 75 “ “ “ 3) Tijdens het onderzoek van patiënt P0105 op 02-09-00 is een 4) “ “ “ “ “ P0105 “ 09-09-00 “ “ diastole van 100 opgenomen. “ “ 88 “

“

Uit deze nieuwe verwoording ontstaat een nieuw IGD. Dit IGD (zie Figuur 3-25) laat precies dezelfde zinnen toe als die uit Figuur 3-24, alleen wordt in Figuur 3-25 het BegripType Onderzoek expliciet vermeld. Uit bovenstaande kunnen we concluderen dat we uit FeitTypen die uit 3 of meer Rollen bestaan, BegripTypen kunnen definiëren die niet expliciet vermeld worden. Patiënt (Patiëntnummer)


UR3

I

ddmm-jj

R

R3

BTF1: <...>

BTF1: De patiënt <...>

Aantal slagen p/m (Getal) Polsslag R4

FTF1: Tijdens is een pols van gemeten. P0105 2-9-00 P0105 9-9-00

80 75

R BTF1: <...>

Onderzoek BTF1: Het onderzoek van op UR1_2 R1

R2

VRR3_5

•

FTF1: is op onderzocht. P0105 P0105

UR5 R5

Aantal mm Hg (Getal) Bloeddruk R6

FTF1: Tijdens is een diastole van opgenomen.

2-9-00 9-9-00

P0105 2-9-00 P0105 9-9-00

100 88

R BTF1: <...>

Figuur 3-25: FeitTypen als BegripTypen 2 [Bron: Eggink 1995: 111]

N.B. Met de VerplichteRolRegel VRR3_5 wordt aangegeven dat als er iets van een onderzoek bekend is, dan dient ook de polsslag of de bloeddruk of beide bekend te zijn.

3.11 Redundantie verwijderen

In paragrafen 3.6 t/m 3.10 is een duidelijk en precies stappenplan beschreven aan de hand waarvan een IGD met BeperkingsRegels voor een bepaald domein of onderwerp kan worden opgesteld. Dit stappenplan sluit enige vorm van overtolligheid echter niet uit. Een gebruiker kan bepaalde voorbeelden immers niet goed verwoord hebben. Sommige vormen van redundantie kunnen echter gewenst zijn, zoals de aanwezigheid

42

Hoofdstuk 3


van afleidbare FeitTypen. In de volgende subparagrafen worden twee vormen van redundantie beschreven.

3.11.1 Redundantie in de InformatieGrammatica

Overtolligheid in de InformatieGrammatica heeft betrekking op de diagrammatische weergave van een IGD (zie Eggink 1995: 115-120). Zo kunnen er zich bijvoorbeeld dubbele NaamTypen, BegripTypen en Rollen in een IGD bevinden. Deze overtolligheid kunnen we door middel van respectievelijk NaamType-samentrekking, BegripTypesamentrekking en Rol-samentrekking verhelpen. Deze termen worden hieronder aan de hand van een voorbeeld toegelicht. 1. NaamType-samentrekking Stel dat een IGD twee NaamTypen Naam bevat. Bij het ene NaamType hoort een populatie met hondennamen, bij het andere NaamType hoort een populatie met persoonsnamen. Is deze informatie nu redundant? Dat hangt af van hoe de individuele namen van deze NaamTypen worden gebruikt. Hierbij kan de vraag gesteld worden: “Vertegenwoordigen deze NaamTypen individuele namen die tot een verschillend type behoren of behoren ze tot hetzelfde type?” Er moet dus bij de gebruiker nagegaan worden of deze ooit geïnteresseerd is in de vraag: “Welke honden hebben dezelfde naam als hun eigenaar?”, met andere woorden: “Wil de gebruiker ooit de naam van een hond vergelijken met die van zijn eigenaar?”. Als dat volgens de gebruiker wel eens voor zou kunnen komen, dan kunnen de twee NaamTypen samengetrokken worden tot één NaamType Naam, anders moeten de NaamTypen hernoemd worden tot bijvoorbeeld het NaamType Voornaam (voor de eigenaar) en Hondennaam (voor de hond). 2. BegripType-samentrekking Gesteld dat een IGD de twee BegripTypen Geboortedatum en Overlijdensdatum bevat die allebei aan het NaamType Datumaanduiding gekoppeld zijn en geïdentificeerd worden door een individuele naam van het type dd-mm-jj. Kunnen de BegripTypen Geboortedatum en Overlijdensdatum dan samengetrokken worden? Hierbij dient de volgende vraag gesteld te worden: “Is het mogelijk dat de datum 06-09-00 zowel een geboorte- als een overlijdensdatum aanduidt?”. Zo ja, dan kunnen de twee BegripTypen samengetrokken worden. Kan dit niet, dan moeten de BegripTypen afzonderlijk blijven bestaan. Bij het samentrekken van BegripTypen dient men er op te letten dat de FeitTypeFormuleringen van de betrokken FeitTypen, indien nodig, worden aangepast, om betekenisvolle formuleringen voor de feiten van de FeitTypen te krijgen. 43

Hoofdstuk 3


3. Rol-samentrekking Soms komt het voor dat een gebruiker voor verschillende feiten van hetzelfde type totaal verschillende formuleringen gebruikt, bijvoorbeeld: 1) De persoon Frits houdt het meest van het land Nederland. 2) “ “ Johan “ “ “ “ “ “ Amerika. 3) De persoon Barend heeft het land Amerika als favoriet. 4) “ “ Klaas “ “ “ Frankrijk “ “

Indien zulke formuleringen niet tijdig ontdekt worden, ontstaat er in de InformatieGrammatica redundantie die vervolgens inconsistenties kunnen veroorzaken. Als bovenstaande feiten in een IGD gezet worden, zal blijken dat er sprake is van twee FeitTypen (FT1 met FTF1: ‘ houdt van ’ en FT2 met FTF1: ‘ heeft als favoriet’) tussen dezelfde BegripTypen Persoon en Land. Er moet dus bij de gebruiker nagegaan worden of de werkwoorddelen ‘houdt het meest van’ en ‘heeft als favoriet’ dezelfde betekenis of functie hebben door de bovenstaande feiten te verwisselen: 1) De persoon Frits heeft het land Nederland als favoriet. 2) “ “ Johan “ “ “ Amerika “ “ 3) De persoon Barend houdt het meest van het land Amerika. 4) “ “ Klaas “ “ “ “ “ “ Frankrijk.

Als de gebruiker aangeeft dat dit beide hetzelfde betekent, kunnen de rollen samengetrokken worden (FeitTypen 1 en 2 worden dan samengetrokken tot FeitType 12). Bij het samentrekken worden beide FeitTypeFormuleringen onder het FeitType FT12 geplaatst (FTF1: ‘ houdt van ’ en FTF2: ‘ heeft als favoriet’) om zo geen enkele informatie te verliezen.

3.11.2 Redundantie in de InformatieBank

Overtolligheid in de InformatieBank heeft betrekking op de populatie van een IGD. Deze populatie kan afleidbare feiten tot gevolg hebben. Deze vorm van redundantie hoeft echter niet verholpen te worden, maar ze moet wel in het IGD aangegeven worden. Het ‘merken’ van een FeitType FT2 in een IGD als afleidbaar, geschiedt door achter de FeitTypenaam FT2 een asteriks (*) te zetten, gevolgd door de FeitTypenaam waaruit het FeitType FT2 afleidbaar is. FT2 * FT1 geeft bijvoorbeeld aan dat FT2 afleidbaar is uit FT1. Het IGD in Figuur 3-23 (zie pagina 39) bevat ook een tweetal afleidbare feiten. Dit valt ook op te maken uit Figuur 3-3 (zie pagina 17): de feiten betreffende het Subtotaal en het Totaalbedrag op de voorbeeldbon zijn af te leiden uit andere feiten in het IGD. Het 44

Hoofdstuk 3


FeitType Subtotaal is afleidbaar uit de FeitTypen FT3, FT4 en Artikelprijs. Voor dit FeitType kan de volgende afleidingsregel worden vastgelegd: Haal uit de FeitTypen FT3 en Artikelprijs het op de bonregel vermelde artikel en de bijbehorende prijs. Vermenigvuldig deze prijs vervolgens met het aantal artikelen dat voor dezelfde bonregel vastgelegd is in het FeitType FT4.

Het FeitType Totaalbedrag is vervolgens afleidbaar uit het FeitType Subtotaal, waarbij de volgende afleidingsregel kan worden vastgelegd: Tel van alle bonregels uit het FeitType, die behoren tot dezelfde bon, de subtotalen op.

De notatiewijze van de AfleidingsRegels voor de FeitTypen Subtotaal en Totaalbedrag zijn reeds weergegeven in Figuur 3-23 (zie pagina 39).

3.12 Het relationele model

In dit hoofdstuk is nauwkeurig omschreven hoe het stappenplan van de informatieanalyse, aan de hand van de Universele Informatiekunde, van een bepaald domein of onderwerp opgesteld wordt. Het uit dit proces verkregen IGD, met zijn BeperkingsRegels en verwijderde redundantie, kan omgezet worden naar een model dat in een relationele databaseomgeving optimaal gebruikt kan worden. Het informatiesysteem kan dan ondersteund worden met behulp van relationele databasemanagement software (RDBMS), software die gebaseerd is op de gedachte dat informatie weer te geven is in de vorm van tabellen. Het is echter niet mogelijk om een IGD in één keer om te zetten in een relationele notatie. Bij de omzetting wordt namelijk gebruik gemaakt van een transformatievoorschrift voor het relationele model dat uit een drietal stappen bestaat. Deze stappen worden aan de hand van het in Figuur 3-23 weergegeven IGD in onderstaande subparagrafen nader beschreven.

3.12.1 Groeperen

De eerste stap bij de omzetting van een IGD in een relationele notatiewijze is het groeperen van het IGD (zie Eggink 1995: 126-128). Hieronder verstaan we dat de binaire FeitTypen in een IGD, waarbij de Rol gespeeld door een BegripType onderhevig is aan een korte UniciteitsRegel, worden gegroepeerd rond het BegripType dat de betreffende Rol speelt. Elk BegripType waarin de verschillende FeitTypen worden gegroepeerd, vormt later in het overeenkomstige relationele tabelschema een tabel. In Figuur 3-26 wordt nogmaals het IGD weergegeven dat we reeds gezien hebben in Figuur 3-23. In onderstaand IGD zijn echter de verzamelingen van FeitTypen gearceerd (om de groepen 45

Hoofdstuk 3


aan te geven) en zijn de Feit-, Begrip- en NaamTypeFormuleringen weggelaten, omdat deze niet in het relationele model weergegeven worden. Horecaondernemer (Klantnummer)

Volgnummer N

UR3

N

VRR3

•

R3 371

FT1

53533 22-07-00

UR5

VRR9

VRR5

•

R1

R2

371

53533

•

R5 371

I ddmm-jj

R4

Bon UR1_2


53533

FT2

Tijdstip (Tijdsaanduiding) I HH:MM

R6 14:33

Regelnummer UR7

N

VRR7

•

R7 371

53533

Bedrag (Getal)

Totaalbedrag* Subtotaal

R

R8

ƒ...

120,25

Bonregel UR9_10 R9 371 371

UR19

•

53533 53533

R11 371 371

53533 1 53533 2

•

R13 371 371

53533 1 53533 2

R19 371 53533 1 371 53533 2

1 2

FTF4

Aantal (Getal) VRR17 R

R12 5 12

UR13

VRR13

•

R10

UR11

VRR11

VRR19

•

Artikel (Artikelnummer) FTF3

R14 63653 75342

N

VRR15

•

UR17

Subtotaal * FT3, FT4, Artikelprijs R20 120,25 18,00

Artikelprijs

R17

R18

63653 75342

20,45 1,50

UR15 R15 63653 75342

Artikelomschrijving

Omschrijving

R16

N


Figuur 3-26: De groepen in een IGD [Bron: Eggink 1995: 127]

Uit bovenstaande figuur kunnen we de volgende groeperingen opmaken: 1. FT1, FT2 en Totaalbedrag worden gegroepeerd rond het BegripType Bon. 2. FT4, FT3 en Subtotaal worden rond het BegripType Bonregel gegroepeerd. 3. Artikelprijs en Artikelomschrijving worden rond het BegripType Artikel gegroepeerd. Het bovenstaande IGD kan nu omgezet worden naar een gegroepeerd IGD, waarbij de overeenkomstig gearceerde FeitTypen opgenomen worden in het BegripType dat de rol speelt die onderhevig is aan de korte UniciteitsRegel.

46

Hoofdstuk 3

De Universele Informatiekunde Horecaondernemer Datum (Datumaanduiding) (Klantnummer)

Volgnummer N

Tijdstip (Tijdsaanduiding) I HH:MM

I ddmm-jj

N

Bon

Bedrag (Getal)

UR1_2 R1

•

VRR9 371

R2

R4

53533

22-07-00

NL

R6

NL

14:33

R8

NL

R ƒ...

120,25

Aantal Regelnummer (Getal) N

R

Bonregel UR9_10 R9 371 371

R10

53533 53533

R12 NL

1 2

5 12

Artikelnummer

Omschrijving

N

N

R14 NL 63653 75342

R20 NL 120,25 18,00

Artikel UR100 R100 63653 75342

R16 NL Broodblik Stapelglas

R18 NL 20,45 1,50

Figuur 3-27: Stap 1 van de omzetting van een IGD naar een relationeel model – groeperen [Bron: Eggink 1995: 128]

Welke bewerkingen moeten nu worden uitgevoerd bij het groeperen van een IGD? Als we Figuur 3-26 en Figuur 3-27 met elkaar vergelijken, kunnen we het volgende stellen: 1. De Rollen R4, R6 en R8 worden opgenomen in het BegripType Bon, waarbij dit BegripType in het oorspronkelijke IGD respectievelijk de Rollen R3, R5 en R7 spelen die onderhevig zijn aan een korte UniciteitsRegel. Een soortgelijke bewerking vindt plaats bij de BegripTypen Bonregel en Artikel: de Rollen R12, R14 en R20 worden opgenomen in het BegripType Bonregel (waarbij dit BegripType in het oorspronkelijke IGD respectievelijk de Rollen R11, R13 en R19 spelen die onderhevig zijn aan een korte UniciteitsRegel) en de Rollen R16 en R18 worden opgenomen in het BegripType Artikel (waarbij dit BegripType in het oorspronkelijke IGD respectievelijk de Rollen R15 en R17 spelen die onderhevig zijn aan een korte UniciteitsRegel). 2. De Rollen R3, R5 en R7 die onderhevig zijn aan respectievelijk de korte UniciteitsRegels UR3, UR5 en UR7, worden na het opnemen van de Rollen R4, 47

Hoofdstuk 3


R6 en R8 in het BegripType Bon gecombineerd met R1 en R2. Een soortgelijke bewerking vindt plaats bij de BegripTypen Bonregel en Artikel: de Rollen R11, R13 en R19 die onderhevig zijn aan respectievelijk de korte UniciteitsRegels UR11, UR13 en UR19, worden na het opnemen van de Rollen R12, R14 en R20 in het BegripType Bonregel gecombineerd met de Rollen R9 en R10 en de Rollen R15 en R17 die onderhevig zijn aan respectievelijk de korte UniciteitsRegels UR15 en UR17, worden na het opnemen van de Rollen R16 en R18 in het BegripType Bonregel gecombineerd met de Rol R100. 3. De Rollen R4, R6 en R8 krijgen in het gegroepeerde IGD de specificatie niet leeg (NL). Dat wil zeggen dat in het relationele tabelschema voor elke aankoopbon een datum, een tijdstip en een totaalbedrag bekend moet zijn. Deze NL-specificaties op de Rollen R4, R6 en R8 is het gevolg van de VerplichteRolRegels VRR3, VRR5 en VRR7 in het oorspronkelijke IGD. Een soortgelijke bewerking vindt plaats bij de BegripTypen Bonregel en Artikel: de Rollen R12, R14 en R20 krijgen de aanduiding NL als gevolg van de VerplichteRolRegels VRR11, VRR13 en VRR19 in het oorspronkelijke diagram, immers: op elke bonregel moet het aantal artikelen, het artikelnummer en het subtotaal vermeld staan. De Rollen R16 en R18 krijgen ook de aanduiding NL als gevolg van de VerplichteRolRegels VRR15 en VRR17 in het oorspronkelijke diagram, omdat van elk artikel een omschrijving en een prijs bekend moet zijn.

3.12.2 Lexicaliseren

De tweede stap bij de omzetting van een IGD in een relationele notatiewijze is het lexicaliseren van het gegroepeerde IGD (zie Eggink 1995: 128-131). Hieronder verstaan we het aanpassen van de BegripTypen die Rollen spelen in het reeds gegroepeerde IGD. Het eindresultaat van lexicalisering is dat alle Rollen uit het IGD gespeeld worden door een NaamType. Zo’n NaamType wordt daarom ook wel lexicaal objecttype genoemd. De Rollen die in aanmerking komen voor lexicalisering zijn reeds gemarkeerd in het gegroepeerde IGD van Figuur 3-27; dit zijn de Rollen R2, R4, R6, R8, R9, R12, R14, R20 en R18. Bij het lexicaliseren van Rollen kan onderscheid gemaakt worden tussen twee situaties: 1. De te lexicaliseren Rol wordt in het oorspronkelijke IGD gespeeld door een unair BegripType. 2. De te lexicaliseren Rol wordt in het oorspronkelijke IGD gespeeld door een BegripType dat uit twee of meer Rollen bestaat. Het gelexicaliseerde IGD wordt weergegeven in Figuur 3-28. Aan de hand van dit IGD worden bovenstaande situaties nader toegelicht.

48

Hoofdstuk 3

De Universele Informatiekunde Datumaanduiding

Tijdsaanduiding

I ddmm-jj

I HH:MM

Bon Getal

UR1_2 R1

R2

R4

371

53533

22-07-00

NL

R6 14:33

Volgnummer

Klantnummer

Regelnummer

Getal

N

N

N

R

= GR1

R8

NL

R

NL

ƒ...

120,25

Bonregel UR9_10 R9.1 371 371

R9.2

R10 1 2

53533 53533

R12 NL 5 12

R14 NL 63653 75342 ⊇

Artikelnummer

Omschrijving

N

N

R20 NL 120,25 18,00

DVR1

Artikel UR100 R100 63653 75342

R16 NL Broodblik Stapelglas

R18 NL 20,45 1,50

Figuur 3-28: Stap 2 van de omzetting van een IGD naar een relationeel model – lexicaliseren [Bron: Eggink 1995: 129]

1. Rol wordt gespeeld door unair BegripType De Rol R14 wordt in het oorspronkelijke IGD gespeeld door het unaire BegripType Artikel. Op deze Rol worden de volgende bewerkingen uitgevoerd: 1. Het unaire BegripType Artikel waardoor de Rol R14 in het oorspronkelijke IGD gespeeld werd, wordt veranderd in het NaamType Artikelnummer. Een artikel wordt immers geïdentificeerd door een artikelnummer, wat blijkt uit de UniciteitsRegel UR100 in het BegripType Artikel. 2. Er ontstaat een DeelVerzamelingsRegel DVR1 van de Rol R14 naar de Rol R100, welke aangeeft dat van elk artikel op een bonregel minstens de prijs en de omschrijving genoteerd moet zijn van het BegripType Artikel. Er ontstaat echter niet bij elke lexicalisering van een Rol een DeelVerzamelingsRegel. Rol R12 wordt bijvoorbeeld in het oorspronkelijke IGD gespeeld door het unaire BegripType Aantal (aangeduid door een getal). Na lexicalisering wordt Rol R12 dus gespeeld door het NaamType Getal, waarbij het BegripType Aantal verwijderd is, 49

Hoofdstuk 3


omdat van een aantal geen andere feiten worden genoteerd, zoals dat bij een artikel wel het geval is. 2. Rol wordt gespeeld door een BegripType bestaande uit twee of meer Rollen De Rol R9 wordt in het oorspronkelijke IGD gespeeld door het binaire BegripType Bon. Op deze Rol worden de volgende bewerkingen uitgevoerd: 1. De Rol R9 wordt opgesplitst in de Rollen R9.1 en R9.2, omdat de Rol R9 in het oorspronkelijk IGD gespeeld wordt door het binaire BegripType Bon. Hieruit kunnen we opmaken dat als een Rol gespeeld wordt door een BegripType bestaande uit twee of meer Rollen, dan moet het aantal Rollen van dat BegripType min één worden toegevoegd. 2. De Rollen R9.1 en R9.2 worden vervolgens gelexicaliseerd, waardoor ze respectievelijk gespeeld worden door de NaamTypen Volgnummer en Klantnummer. Hieruit volgt dat een bonregel wordt geïdentificeerd door de combinatie van een klantnummer, een volgnummer en een regelnummer. 3. Er ontstaat een GelijkheidsRegel tussen de combinatie van de Rollen R1 en R2 en de combinatie van de Rollen R9.1 en R9.2. Op elke bon moeten immers bonregels staan en bonregels kunnen niet zonder bon bestaan.

3.12.3 Omzetten naar relationele notatiewijze

De derde en laatste stap van het transformatievoorschrift is de omzetting van het gelexicaliseerde IGD naar de relationele notatiewijze (zie Eggink 1995: 132-133). Het resultaat van het relationele tabelschema wordt weergegeven in Figuur 3-29. BON SL1 Volgnummer

Klantnummer

Datumaanduiding

371

53533

22-07-00

14:33

DV3 ⊆

NL

Tijdsaanduiding

NL

Totaal

NL

120,25

⊇ DV2

BONREGEL SL2 Volgnummer

Klantnummer

Regelnummer

Aantal

371 371

53533 53533

1 2

5 12

⊇

ARTIKEL SL3

NL

Artikelnummer 63653 75342

NL

Subtotaal 102,25 18,00

DV1

Artikelnummer

Omschrijving

63653 75342


NL

Artikelprijs

NL

20,45 1,50

Figuur 3-29: Stap 3 van de omzetting van een IGD naar een relationeel model – omzetten naar relationele notatiewijze [Bron: Eggink 1995: 132]

Bij de omzetting van het gelexicaliseerde IGD naar het relationele model vinden de volgende bewerkingen plaats:

50

NL

Hoofdstuk 3


1. De BegripTypeNamen worden omgezet naar een tabel met dezelfde naam. Zo worden de BegripTypen Bon, Bonregel en Artikel omgezet naar de tabellen Bon, Bonregel en Artikel. 2. De Rollen uit de verschillende BegripTypen worden omgezet naar kolommen, die de naam krijgen van het NaamType dat de desbetreffende Rol speelt in het gelexicaliseerde IGD. Om kolommen betekenisvolle namen te geven, mogen de namen van de NaamTypen aangepast worden (bijvoorbeeld: Artikelprijs in plaats van Getal). 3. De UniciteitsRegels worden omgezet naar sleutels. Zo worden de URs UR1_2, UR9_10 en UR100 respectievelijk omgezet naar de sleutels SL1, SL2 en SL3. In bovenstaande voorbeeld is slechts sprake van primaire sleutels, omdat elke tabel maar over één sleutel beschikt. Indien een tabel over meerdere sleutels beschikt, dan zijn dat allemaal kandidaat-sleutels, waarvan er één aangewezen dient te worden als primaire sleutel. 4. De DeelVerzamelingsRegel DVR1 en de GelijkheidsRegels GR1 worden respectievelijk omgezet naar de verwijzingen DV1, DV2 en DV3. DV1 en DV3 zijn de refererende sleutels: een artikelnummer uit de tabel Bonregel refereert aan een artikel uit de tabel Artikel en de kolom Artikelnummer in de tabel Artikel vormt de primaire sleutel. Het relationele tabelschema in Figuur 3-29 geeft dezelfde informatie weer als het IGD in Figuur 3-26, alleen in relationele notatievorm. Beide vormen zijn semantisch equivalent aan elkaar, alleen is bij de relationele notatiewijze de FeitTypeFormulering verloren gegaan. Met deze laatste stap is het relationele model compleet. Nu resteert nog de implementatie in een RDBMS. In het volgende hoofdstuk zal ik de in dit hoofdstuk behandelde theorie over de Universele Informatiekunde toepassen op een praktijkgerichte situatie.

51

4 Casus

De in hoofdstuk 3 beschreven Universele Informatiekunde zal ik in dit hoofdstuk toepassen op een praktijkgerichte situatie binnen het bedrijf Nedercom Eduware. Hieruit zal moeten blijken wat het nut van de analysemethode is alvorens aan een systeem beginnen te bouwen.

4.1 Introductie

Nedercom Eduware is een bedrijf dat opgericht is in het NIVO-tijdperk (1986 – 1989) (Nieuwe Informatietechnologie in het Voortgezet Onderwijs). Scholen kregen in die periode een lokaal met 12 computers van de overheid. Door Nedercom werden er lesideeën ontwikkeld bij de toen standaard aan scholen geleverde software PCTYPE voor tekstverwerken en PCFILE voor databasebeheer. In de periode 1990 – 1993 werd voor de Noordelijke Hogeschool Leeuwarden, fac. Onderwijs prototypische software ontwikkeld voor Spelling, Samenvatten en Formuleren voor gebruik in het kader van TST: Taal- en Studievaardigheidstrainingen met als doel een verbetering van de aansluiting havo – hbo. Van deze programmatuur werden daarna varianten afgeleid voor gebruik in mbo en voortgezet onderwijs: niveau 1 voor kmbo en 1e fase vo, niveau 2 voor mbo en 2e fase vo en niveau 3 is voor tertiair onderwijs. Voor Wolters-Noordhoff werd in 1992 ontwikkeld en in 1997 herzien speciale software voor Grammatica en Spelling bij de methode Nieuw Nederlands voor de basisvorming. Daarnaast levert Nedercom ook een elektronisch toetsprogramma ToetsPro. Sinds 2000 heeft Nedercom ook programma’s op de markt gebracht voor grammatica Duits (Der-Die-Das: niveau 1, Deutsch-Einfach: niveau 2-3. Momenteel zijn er nog een tweetal programma’s in ontwikkeling: Basiscursus Spelling (basisonderwijs, groep 7-8) en Mind the gap: English Grammar.

4.2 De huidige situatie

In de loop der jaren is er een klantenbestand van zo’n 1.250 scholen opgebouwd. Dit wordt sinds 1996 bijgehouden in het programma Davi-adres, waarbij een splitsing gemaakt is in twee adressenbestanden: 1. Nieuw Nederlands: ca. 397 adressen; bevat alle adressen van scholen die de software bij de methode Nieuw Nederlands van Wolters-Noordhoff gebruiken. Nedercom heeft bij deze methode software ontwikkeld. 2. Nedercom: ca. 843 adressen; bevat alle adressen van scholen die de software van Nedercom gebruiken. Beide bestanden hebben vrijwel dezelfde structuur. Hieronder volgt een overzicht van de structuur van deze bestanden. 52

Hoofdstuk 4

Casus

Nedercom-adressen

Veldnamen Davi NAAM ADRESSERNG AANHEF ROEPNAAM VOORLETTRS TAV TITEL ACHTERNAAM POSTADRES POSTCODE PLAATS LAND BZKADRES BZKPSTCODE BZKPLAATS EMAIL_PERS URL_PERS EMAIL_ADR URL_ADR MEMO_ADR BRFAANHEF FUNCTIE GEB_DATUM GESLACHT

PERSCAT ADRESCAT TEL1_ADR TEL2_ADR TEL3_ADR TEL1_PERS TEL2_PERS MEMO_PERS BEDRIJF SPELLING FORMULEREN SAMENVATTEN TOETSPRO NN WN GEBRUIK DUITS GRAMMATICA

Veldnamen voluit Adresnaam Adressering Persoonsaanhef Roepnaam Voorletters Tav Titel Achternaam Postadres Postcode Plaats Land Bezoekadres Bezoekpostcode Bezoekplaats Email adres Internet pagina Email adres Internet pagina Memo AUTOMATISCH Functie Geboortedatum GEBASEERD op Man/Vrouw Persoonscategorie Adrescategorie Telefoon 1 (= werk) Telefoon 2 (= privé) Telefoon 3 (= fax) Telefoon 1 (= werk) Telefoon 2 (= privé) Memo Bedrijf Spelling Formuleren Samenvatten ToetsPro Nieuw Nederlands Wolters-Noordhoff Gebruik Duits Grammatica

= Addressenlijst = Overbodig in adressenlijst

Nieuw Nederlands adressen

Veldnamen Davi NAAM ADRESSERNG AANHEF ROEPNAAM VOORLETTRS TAV TITEL ACHTERNAAM POSTADRES POSTCODE PLAATS LAND BZKADRES BZKPSTCODE BZKPLAATS EMAIL_PERS URL_PERS EMAIL_ADR URL_ADR MEMO_ADR BRFAANHEF FUNCTIE GEB_DATUM GESLACHT

PERSCAT ADRESCAT TEL1_ADR TEL2_ADR TEL3_ADR TEL1_PERS TEL2_PERS MEMO_PERS BEDRIJF DEMO GEBRUIK VERSIE PROEF SPELLING FORMULEREN SAMENVATTEN TOETSPRO GRAMMATICA NIEUW NEDERLANDS

Veldnamen voluit Adresnaam Adressering Persoonsaanhef Roepnaam Voorletters Tav Titel Achternaam Postadres Postcode Plaats Land Bezoekadres Bezoekpostcode Bezoekplaats Email adres Internet pagina Email adres Internet pagina Memo AUTOMATISCH Functie Geboortedatum GEBASEERD op Man/Vrouw Persoonscategorie Adrescategorie Telefoon 1 (= werk) Telefoon 2 (= privé) Telefoon 3 (= fax) Telefoon 1 (= werk) Telefoon 2 (= privé) Memo Bedrijf Demo Gebruik Versie Proef Spelling Formuleren Samenvatten ToetsPro Grammatica Nieuw Nederlands

= Personenlijst = Overbodig in personenlijst

Figuur 4-1: Structuur adressenbestanden Nedercom en Nieuw Nederlands

Uit bovenstaande overzicht kunnen we opmaken dat er een onderscheid is tussen een adressenlijst en een personenlijst. Een combinatie van een school en sector mag maar één keer in de adressenlijst voorkomen. Onder die combinatie school – sector kunnen vervolgens weer een aantal personen vallen. Daarnaast zien we dat een aantal velden in 53

Hoofdstuk 4

Casus

de database overbodig zijn. Dit zijn velden die nooit gebruikt worden en dus in de analyse buiten beschouwing gelaten kunnen worden. Als we dit toepassen op de huidige bestanden, krijgen we de volgende structuur.

Nedercom adressenbestand

Naam

Adresserng

TAV

Postadres

Postcode

Plaats

Land

Bzkadres

Bzkpstcode

Bzkplaats

Email_Adr

URL_Adr

Memo_Adr

Adrescat

Tel1_Adr

Tel2_Adr

Tel3_Adr

Spelling

Formuleren

Lezen

ToetsPro

NN

WN

Demo

Gebruik

Voorhoede

Basisgramm

Adresnaam

Postadres

Postcode

Plaats

Functie

Aanhef

Voorlettrs

Achternaam

Roepnaam

Email_Pers

Tel1_Pers

Tel2_Pers

Memo_Pers

Figuur 4-2: Structuur Nedercom-adressenbestand

54

Hoofdstuk 4

Casus

Nieuw Nederlands adressenbestand

Naam

Adresserng

TAV

Postadres

Postcode

Plaats

Land

Bzkadres

Bzkpstcode

Bzkplaats

Email_Adr

URL_Adr

Memo_Adr

Adrescat

Tel1_Adr

Tel2_Adr

Tel3_Adr

Demo

Gebruik

Versie

Proef

Adresnaam

Postadres

Postcode

Plaats

Functie

Aanhef

Voorlettrs

Achternaam

Roepnaam

Email_Pers

Tel1_Pers

Tel2_Pers

Memo_Pers

Figuur 4-3: Structuur Nieuw Nederlands adressenbestand

Uit Figuur 4-2 en Figuur 4-3 kunnen we opmaken dat Davi de volgende relaties tussen de adressen- en personenlijst hanteert: Adressenlijst

Personenlijst

Naam Adressering Postadres Postcode Plaats

Adresnaam Aanhef + Voorletters + Achternaam Postadres Postcode Plaats

55

Hoofdstuk 4

Casus

Omdat de structuur van beide bestanden vrijwel gelijk is, kunnen de twee samengevoegd worden. Middels een speciaal veld kan dan aangegeven worden of het adres tot de categorie Nedercom of Nieuw Nederlands behoort, zodat er makkelijk een selectie gemaakt kan worden. Waarom moet er nu een ander systeem komen? Het programma Davi-Adres heeft een aantal beperkingen: 1. Er is een beperkt aantal extra velden door de gebruiker toe te voegen: slechts 10 in de adressenlijst en 10 in de personenlijst. 2. Zoals reeds eerder vermeld hanteert Davi standaard een overbodig aantal velden, zoals geslacht, geboortedatum, bedrijf. 3. Er kan wel een e-mailadres ingevuld worden (slechts één per persoon/adres; scheiding door een puntkomma kan niet), maar er zijn geen mailingmogelijkheden binnen Davi. 4. Een record kan niet gekopieerd worden. 5. Gegevens kunnen niet in de lijstweergave veranderd worden. De voornaamste redenen voor het omzetten van de adresbestanden van Davi naar een ander systeem zijn het gebrek aan mailingmogelijkheden en de onoverzichtelijkheid en inconsistentie van opslag van gegevens binnen Davi. Voor ieder adres wordt nu binnen Davi in een memo-veld bijgehouden wat een school aan programma’s gebruikt (wat, wanneer en welke versie). Deze gegevens worden door stagiaires ingevoerd. Het nadeel hiervan is dat de gegevens niet consequent ingevoerd worden. De één doet het weer anders dan de ander. Er moet dus zoveel mogelijk structuur in de database komen, zodat gegevens zoveel mogelijk op één wijze ingevoerd kunnen worden. Dit kan onder andere bereikt worden door middel van invoerlijsten, checkboxes en validatie van gegevenss. Daarnaast moet de database toegankelijk zijn voor iedere gebruiker. Davi-Adres biedt op dit gebied te weinig mogelijkheden. FileMaker Pro is hiervoor een ideaal programma. FileMaker is een volledig relationele databaseomgeving en is zeer intuïtief in gebruik. Voordat er met het omzetten van het systeem begonnen wordt, dient eerst de analyse van de gegevens in de huidige database plaats te vinden. De laatste stap is de implementatie van het geheel.

4.3 Stap 1: Voorbeelden verzamelen

De eerste stap is het verzamelen van voorbeelden. Ik heb hierbij voorbeelden genomen uit het programma Davi-Adres. Aan de hand van deze voorbeelden zal alleen de relevante informatie omgezet worden naar elementaire zinnen.

56

Hoofdstuk 4

Casus

Figuur 4-4: Voorbeelddocument 1 – Postadresgegevens 1

Figuur 4-5: Voorbeelddocument 2 – Postadresgegevens 2

57

Hoofdstuk 4

Casus

Figuur 4-6: Voorbeelddocument 3 – Bezoekadresgegevens 1

Figuur 4-7: Voorbeelddocument 4 – Bezoekadresgegevens 2

58

Hoofdstuk 4

Casus

Figuur 4-8: Voorbeelddocument 5 – Extra gegevens/memoveld behorende bij adres 1

Figuur 4-9: Voorbeelddocument 6 – Extra gegevens/memoveld behorende bij adres 2

59

Hoofdstuk 4

Casus

Figuur 4-10: Voorbeelddocument 7 – Persoonsgegevens 1


60

Hoofdstuk 4

Casus



61

Hoofdstuk 4

Casus

Figuur 4-14: Voorbeelddocument 11 – Extra gegevens/memoveld behorende bij persoon 1

Figuur 4-15: Voorbeelddocument 12 – Extra gegevens/memoveld behorende bij persoon 2

Op bovenstaande voorbeelden is enige toelichting noodzakelijk. In Figuur 4-1 is reeds aangegeven dat een aantal velden overbodig zijn. Zo zijn de velden titel, man/vrouw, geboortedatum, persoonscategorie en een persoonlijke internetpagina (zie Figuur 4-10 t/m Figuur 4-13) niet interessant voor de adressendatabase voor Nedercom. Bovendien is uit de aanhef dhr. of mevr. op te maken of we te maken hebben met een man of vrouw. Deze overbodige velden zijn rood gearceerd op de voorbeelden. Daarnaast maakt Davi-Adres geen gebruik van één enkel uniek identificatieveld. In Figuur 4-2 en Figuur 4-3 hebben we reeds kunnen zien dat Davi de relatie tussen de adressenlijst en personenlijst legt middels de velden naam, postadres, postcode en plaats. Het nadeel van deze methode is dat alle gegevens in deze velden in iedere database opgenomen moeten worden om een link te kunnen leggen. Daarom is besloten om voor iedere klant een uniek klantnummer en voor iedere persoon een uniek persoonsnummer te hanteren. Dit is op de voorbeelden aangegeven door een blauwe arcering. Met behulp van slechts een klanten persoonsnummer kan dan een relatie gelegd worden tussen verschillende databases. 62

Hoofdstuk 4

Casus

Nu alle relevante voorbeelden verzameld zijn, kan de informatie op de verschillende voorbeelddocumenten verwoord worden. Dit is het onderwerp van de volgende paragraaf.

4.4 Stap 2 & 3: Verwoorden & Klassificatie en Kwalificatie Hieronder volgt de verwoording van de voorbeelden. 1) 2)

NWD De klant 0187 “ 0292

WWD vertegenwoordigt “

NWD de school ROC Oost Nederland. “ Centrum Vakopleiding.

3) 4)


WWD hoort bij “

5) 6)


WWD heeft als hoofdcontactpersoon “

7) 8)


WWD is gevestigd op “

9) 10)


WWD heeft “

11) 12)


WWD heeft “

13) 14)


WWD is gevestigd in “

de plaats “

15) 16)


WWD is gevestigd op “

NWD het bezoekadres Buurserstraat. “ Wolfskuilseweg.

17) 18)


WWD heeft “

NWD het bezoekadresnummer 250. “ 279.

19) 20)


WWD heeft “

NWD de bezoekpostcode “

21) 22)



NWD de bezoekplaats “

23) 24)



het land “

25) 26)


WWD heeft als e-mail “

27) 28)


WWD heeft als internetsite “

29) 30)


WWD valt onder “

31) 32)


WWD is zakelijk telefonisch bereikbaar onder “

33) 34)


WWD is privé telefonisch bereikbaar onder “

NWD de afdeling Economie. “ -. NWD de persoon Dhr. H.J.C. Stuart. “ Mevr. B. Schoonbeek.

NWD het postadres Buurserstraat. “ Postbus.

NWD het post(bus)adresnummer “

250. 40199.

NWD de postcode 7544 RG. “ 6504 AD. NWD Enschede. Nijmegen.

7544 RG. 6542 AA.

Enschede. Nijmegen.

NWD Nederland. Nederland.

NWD het zakelijke e-mailadres [email protected]. “ -.

het internetadres “

NWD http://www.roc-on.nl. -.

NWD de adrescategorie mbo. “ mbo.

het nummer “

NWD 053 – 850 41 00. 024 - 377 32 22.

NWD het nummer -. -.

63

Hoofdstuk 4

Casus

35) 36)


37) 38)

WWD De gegevens voor “

NWD de klant 0187 “ 0292

WWD zijn voor het laatst gewijzigd op “

39) 40)

WWD De gegevens voor “


WWD zijn “

41) 42)


43) 44)

WWD Bij

WWD is per fax bereikbaar onder “

WWD heeft “


NWD een demo van

WWD zijn “

het nummer “

NWD wel niet

-. FO.

NWD opmerkingen. “

-

NWD De factuur LZ98.006 “ SP00.002 “ TP01.007 “ SP97.045

WWD hoort bij “ “ “

49) 50) 51) 52) 53)

NWD De factuur LZ98.006 “ SP00.002 “ TP01.007 “ SP97.045 “ SP97.045

WWD bestaat uit een bestelling voor “ “ “ “

54) 55) 56) 57) 58)

NWD Het programma “ “ “ “

LZ2 SP2 TPDE SP1 SP2

59) 60) 61) 62) 63)



64) 65) 66) 67) 68)



69) 70) 71) 72) 73)

WWD Bij “ “ “ “

NWD het programma “ “ “ “

74) 75) 76) 77)

WWD Bij “ “ “

NWD de klant 0187 0187 0292 0292

78) 79) 80) 81)

NWD De contactpersoon “ “ “

0696 0795 0041 0737

82) 83) 84) 85)


0696 0795 0041 0737


NWD 9-5-2001. 12-4-2001.

WWD gemarkeerd. “

45) 46) 47) 48)

86) 87) 88) 89)

NWD 053 - 850 41 10. -.

NWD de klant 0187. “ 0187. “ 0187. “ 0292. NWD het programma “ “ “ “

LZ2. SP2. TPDE. SP1. SP2.

WWD behorende bij “ “ “ “

NWD de factuur LZ98.006 “ SP00.002 “ TP01.007 “ SP97.045 “ SP97.045

WWD is geschikt voor “ “ “ “

1 1 1 1 1

WWD behorende bij “ “ “


WWD is geschikt voor “ “ “ “

NWD 60 netwerkgebruikers. 60 “ 32 “ 12 “ 12 “



WWD is van “ “ “ “


LZ2 SP2 TPDE SP1 SP2 WWD hoort “ “ “

0696 0795 0041 0737

NWD de factuur LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

NWD een contactpersoon “ “ “

WWD heeft “ “ “ WWD heeft “ “ “ WWD heeft “ “ “

NWD de aanhef “ “ “

NWD netwerk. “ “ “ “

NWD het type -. “ Wup. “ -. “ V. “ V. WWD zijn “ “ “ “

NWD - opmerkingen. “ “ “ “

0696. 0795. 0041. 0737.

Dhr. Dhr. Mevr. Mevr.

NWD de roepnaam -. Harrie. Mirjam. -. NWD de voorletters “ “ “

R. H.J.C. M. B.

64

Hoofdstuk 4

Casus

90) 91) 92) 93)


0696 0795 0041 0737

WWD heeft “ “ “

NWD de achternaam Roelvink. “ Stuart. “ Baks. “ Schoonbeek.

94) 95) 96) 97)


0696 0795 0041 0737


NWD het tussenvoegsel “ “ “

98) 99) 100) 101)


0696 0795 0041 0737


NWD als persoonsaanhef Dhr. R. Roelvink. “ Dhr. H.J.C. Stuart. “ Mevr. M. Baks. “ Mevr. B. Schoonbeek.

102) 103) 104) 105)


0696 0795 0041 0737


NWD de functie van systeembeheer. “ doc. Duits. “ doc. Nederlands. “ doc. Nederlands.

106) 107) 108) 109)


0696 0795 0041 0737

WWD heeft als e-mail “ “ “

110) 111) 112) 113)


0696 0795 0041 0737

WWD is zakelijk telefonisch bereikbaar onder “ “ “

114) 115) 116) 117)


0696 0795 0041 0737

WWD is privé telefonisch bereikbaar onder “ “ “

118) 119) 120) 121)

WWD De gegevens voor “ “ “

NWD de contactpersoon 0696 0795 0041 0737

WWD zijn voor het laatst gewijzigd op “ “ “

122) 123) 124) 125)

WWD De gegevens voor “ “ “

NWD de contactpersoon “ “ “

WWD zijn “ “ “

126) 127) 128) 129)

WWD Bij “ “ “

NWD de contactpersoon “ “ “

0696 0795 0041 0737

WWD zijn “ “ “

0696 0795 0041 0737

-. -. -. -.

NWD een persoonlijk e-mailadres [email protected]. “ [email protected]. “ -. “ -.

NWD niet wel niet niet

NWD het nummer 053 – 850 41 70. -. -. -.

NWD het nummer -. -. -. -. NWD 1-2-2001. 8-5-2001. 2-2-2001. 2-2-2001.

WWD gemarkeerd. “ “ “

NWD - opmerkingen. “ “ “

Door het stellen van de wat- en de hoe-vraag voor de verschillende verwoorde feiten bij de voorbeelden, ben ik gekomen tot een klassificatie, zoals deze bij elk van de bovenstaande feiten is aangegeven met behulp van NWD (naamwoordelijk deel) en WWD (werkwoordelijk deel). Een overzicht van de stelling van de wat- en de hoe-vraag volgt hieronder. Het was voldoende om tot een klassificatie te komen door slechts voor elk type feit een wat- en hoe vraag te stellen. De nummers in onderstaand overzicht verwijzen dan ook naar de nummers van bovenstaande feiten. 1.1) 1.2)

Wat stelt de individuele naam 0187 voor? Hoe duiden we een specifieke klant aan?

Een specifieke klant. Met een klantnummer.

2.1) 2.2)

Wat stelt de individuele naam ROC Oost Nederland voor? Hoe duiden we een specifieke school aan?

Een specifieke school. Met een naam.

3.1) 3.2)

Wat stelt de individuele naam Economie voor? Hoe duiden we een specifieke afdeling aan?

Een specifieke afdeling. Met een naam.

65

Hoofdstuk 4 stelt de individuele naam Dhr. H.J.C. Stuart voor? duiden we een specifieke hoofdcontactpersoon aan? stelt de individuele naam Buurserstraat voor? duiden we een specifiek postadres aan?

Casus

5.1) 5.2) 7.1) 7.2)

Wat Hoe Wat Hoe

Een Met Een Met

specifieke hoofdcontactpersoon. een naam. specifiek postadres. een naam.

9.1) 9.2)

Wat stelt de individuele naam 250 voor? Hoe duiden we een specifiek post(bus)adresnummer aan?

Een specifiek post(bus)adresnummer. Met een nummer.

11.1) 11.2)

Wat stelt de individuele naam 7544 RG voor? Hoe duiden we een specifieke postcode aan?

Een specifieke postcode. Met een postcodeaanduiding.

13.1) 13.2)

Wat stelt de individuele naam Enschede voor? Hoe duiden we een specifieke plaats aan?

Een specifieke plaats. Met een naam.

15.1) 15.2)

Wat stelt de individuele naam Buurserstraat voor? Hoe duiden we een specifiek bezoekadres aan?

Een specifiek bezoekadres. Met een naam.

17.1) 17.2)

Wat stelt de individuele naam 250 voor? Hoe duiden we een specifiek bezoekadresnummer aan?

Een specifiek bezoekadresnummer. Met een nummer.

19.1) 19.2)

Wat stelt de individuele naam 7544 RG voor? Hoe duiden we een specifieke bezoekpostcode aan?

Een specifieke bezoekpostcode. Met een postcodeaanduiding.

21.1) 21.2)

Wat stelt de individuele naam Enschede voor? Hoe duiden we een specifieke bezoekplaats aan?

Een specifieke bezoekplaats. Met een naam.

23.1) 23.2)

Wat stelt de individuele naam Nederland voor? Hoe duiden we een specifiek land aan?

Een specifiek land. Met een naam.

25.1) 25.2)

Wat stelt de individuele naam [email protected] voor? Hoe duiden we een specifiek e-mailadres aan?

Een specifiek e-mailadres. Met een e-mailadresaanduiding.

27.1) 27.2)

Wat stelt de individuele naam http://www.roc-on.nl voor? Hoe duiden we een specifiek Internetadres aan?

Een specifiek Internetadres. Met een Internetadresaanduiding.

29.1) 29.2)

Wat stelt de individuele naam mbo voor? Hoe duiden we een specifieke adrescategorie aan?

Een specifieke adrescategorie. Met een adrescategorieaanduiding.

31.1) 31.2)

Wat stelt de individuele naam 053 – 850 41 00 voor? Hoe duiden we een specifiek zakelijk tefoonnummer aan?

Een specifiek zakelijk telefoonnummer. Met een nummer.

33.1) 33.2)

Wat stelt de individuele naam - voor? Hoe duiden we een specifiek privé telefoonnummer aan?

Een specifiek privé telefoonnummer. Met een nummer.

35.1) 35.2)

Wat stelt de individuele naam 053 – 850 41 10 voor? Hoe duiden we een specifiek faxnummer aan?

Een specifiek faxnummer. Met een nummer.

37.1) 37.2)

Wat stelt de individuele naam 9-5-2001 voor? Hoe duiden we een specifieke wijzigingsdatum aan?

Een specifieke wijzigingsdatum. Met een datumaanduiding.

39.1) 39.2)

Wat stelt de individuele naam wel voor? Hoe duiden we een markering aan?

Een markering. Met een markeringsaanduiding.

41.1) 41.2)

Wat stelt de individuele naam FO voor? Hoe duiden we een specifieke demo aan?

Een specifieke demo. Met een democode.

43.1) 43.2)

Wat stelt de individuele naam - voor? Hoe duiden we een specifieke opmerking aan?

Een specifieke opmerking. Met een opmerkingsaanduiding.

45.1) 45.2)

Wat stelt de individuele naam LZ98.006 voor? Hoe duiden we een specifieke factuur aan?

Een specifieke factuur. Met een nummer.

49.1) 49.2)

Wat stelt de individuele naam LZ2 voor? Hoe duiden we een specifieke programma aan?

Een specifiek programma. Met een programmacode.

54.1) 54.2)

Wat stelt de individuele naam 1 voor? Hoe duiden we een specifiek aantal netwerken aan?

Een specifiek aantal netwerken. Met een getal.

59.1) 59.2)

Wat stelt de individuele naam 60 voor? Hoe duiden we een specifiek aantal netwerkgebruikers aan?

Een specifiek aantal netwerkgebruikers. Met een getal.

64.1) 64.2)

Wat stelt de individuele naam Windows update voor? Hoe duiden we een specifiek type aan?

Een specifiek programmaype. Met een programmatypepeaanduiding.

69.1) 69.2)



74.1) 74.2)

Wat stelt de individuele naam 0696 voor? Hoe duiden we een specifieke contactpersoon aan?

Een specifieke contactpersoon. Met een persoonsnummer.

78.1) 78.2)

Wat stelt de individuele naam Dhr. voor? Hoe duiden we een specifieke aanhef aan?

Een specifieke aanhef. Met een aanhefaanduiding.

66

Hoofdstuk 4

Casus

82.1) 82.2)

Wat stelt de individuele naam Harrie voor? Hoe duiden we een specifieke roepnaam aan?

Een specifieke roepnaam. Met een naam.

86.1) 86.2)

Wat stelt de individuele naam H.J.C. voor? Hoe duiden we specifieke voorletters aan?

Specifieke voorletters. Met een voorletteraanduiding.

90.1) 90.2)

Wat stelt de individuele naam Roelvink voor? Hoe duiden we een specifieke achternaam aan?

Een specifieke achternaam. Met een naam.

94.1) 94.2)

Wat stelt de individuele naam - voor? Hoe duiden we een specifiek tussenvoegsel aan?

Een specifiek tussenvoegsel. Met een tussenvoegselaanduiding.

98.1) 98.2)

Wat stelt de individuele naam Dhr. R. Roelvink voor? Hoe duiden we een specifiek persoonsaanhef aan?

Een specifieke persoonsaanhef. Met een persoonsaanhefaanduiding.

102.1) 102.2)

Wat stelt de individuele naam systeembeheer voor? Hoe duiden we een specifieke functie aan?

Een specifieke functie. Met een functieaanduiding.

106.1) 106.2)

Wat stelt de individuele naam [email protected] voor? Hoe duiden we een specifiek e-mailadres aan?

Een specifiek e-mailadres. Met een e-mailadresaanduiding.

110.1) 110.2)

Wat stelt de individuele naam 053 – 850 41 70 voor? Hoe duiden we een specifiek zakelijk telefoonnummer aan?

Een specifiek zakelijk telefoonnummer. Met een nummer.

114.1) 114.2)

Wat stelt de individuele naam - voor? Hoe duiden we een specifiek privé telefoonnummer aan?

Een specifiek privé telefoonnummer. Met een nummer.

118.1) 118.2)

Wat stelt de individuele naam 1-2-2001 voor? Hoe duiden we een specifieke wijzigingsdatum aan?

Een specifieke wijzigingsdatum. Met een datumaanduiding.

122.1) 122.2)

Wat stelt de individuele naam niet voor? Hoe duiden we een markering aan?

Een markering. Met een markeringsaanduiding.

126.1) 126.2)



Na bovenstaande klassificatie kan de kwalificatie van de naamwoordelijke delen plaatsvinden. Hierbij worden de naamwoordelijke delen vervangen door de antwoorden op de wat- en hoe-vraag, bijvoorbeeld: 1.1) 1.2) 2.1) 2.2)

Wat Wat Wat Wat

stelt stelt stelt stelt

de de de de

individuele individuele individuele individuele

naam naam naam naam

0187 voor? ROC Oost Nederland voor? 0292 voor? Centrum Vakopleiding voor?

De individuele namen 0287 en 0292 stellen specifieke klanten voor en de individuele namen ROC Oost Nederland en Centrum Vakopleiding stellen specifieke scholen voor. De verzameling van alle mogelijke individuele namen van het type 1.1 en 2.1 vormen het BegripType Klant en de verzameling van alle mogelijke individuele namen van het type 1.2 en 2.2 vormen het BegripType School. Met behulp van de antwoorden op de wat-vraag, kunnen we vervolgens het sjabloon FeitTypeFormulering opstellen (zie 3.7.2 Kwalificatie, pagina 19): 1) 2)


WWD vertegenwoordigt “

NWD de school ROC Oost Nederland. “ Centrum Vakopleiding.

Vervanging van naamwoordelijke delen door antwoord op wat-vraag. FTF1:

vertegenwoordigt

<School>.

Met behulp van de hoe-vraag bepalen we nader hoe de elementen van een BegripType geïdentificeerd worden: 67

Hoofdstuk 4

1) 2)

Casus

Hoe wordt een individueel element van het BegripType Klant geïdentificeerd? Hoe wordt een individueel element van het BegripType School geïdentificeerd?

Waarop het antwoord luidt: 1.1) 1.2) 2.1) 2.2)

0187 duidt een klant aan. ROC Oost Nederland duidt een school aan. 0292 duidt een klant aan. Centrum Vakopleiding duidt een school aan.

Een specifieke klant wordt dus aangeduid door middel van een klantnummer en een specifieke school wordt aangeduid door een naam. Aan de hand van deze Doopfeiten (zie 3.7.2 Kwalificatie, pagina 20) kunnen weer twee nieuwe sjablonen FeitTypeFormulering opgesteld worden: 1.1) 2.1)

NWD 0187 0292

WWD duidt een klant aan. “

Vervanging van het naamwoordelijke deel door het antwoord op de hoe-vraag. FTF2: duidt een klant aan.

2.1) 2.2)

NWD ROC Oost Nederland Centrum Vakopleiding

WWD duidt een school aan. “

Vervanging van het naamwoordelijke deel door het antwoord op de hoe-vraag. FTF3: duidt een school aan.

Uit FTF2 en FTF3 kunnen we vervolgens de volgende twee BegripTypeFormuleringen afleiden (zie 3.7.2 Kwalificatie, pagina 20): BTF1: De klant BTF2: De school

Een verdere substitutie van de naamwoordelijke delen op de wat- en hoe-vraag is nu niet meer mogelijk. De individuele namen 0187 en ROC Oost Nederland in respectievelijk de klassificaties “0187 duidt een klant aan.” en “ROC Oost Nederland duidt een school aan.” verwijzen naar zichzelf. We hebben hier dus te maken met twee soorten NaamTypen, namelijk het NaamType Klantnummer en het NaamType Naam 68

Hoofdstuk 4

Casus

(zie 3.7.2 Kwalificatie, pagina 21). We verkrijgen vervolgens de volgende NaamTypeFormuleringen: NTF1: <…> NTF2: <…>

Schematisch kan de bovenstaande substituering van de eerste twee feiten als volgt weergegeven worden: FTF1: vertegenwoordigt <School>. substitueer door BTF1 FTF1a: De klant vertegenwoordigt <School>. substitueer door NTF1 FTF1b: De klant <...> vertegenwoordigt <School>. substitueer door BTF2 FTF1c: De klant <...> vertegenwoordigt de school . substitueer door NTF2 FTF1d: De klant <...> vertegenwoordigt <...>.

Figuur 4-16: Substituering van de invulplaatsen in de FeitTypeFormulering (behorende bij het FeitType FT1) door Begrip- en NaamTypeFormuleringen

Als we dezelfde methode toepassen op alle overige feiten krijgen we de volgende InformatieGrammatica: FeitType FTF1

: :

FT1 vertegenwoordigt <School>

BegripType FTF1 BTF1

: : :

Klant Er is een klant . De klant

NaamType NTF1

: :

Klantnummer <…>


: : :

School Er is een school . De school

NaamType NTF1

: :

Naam <…>

FeitType FTF1

: :

FT2 hoort bij .


: : :

Afdeling Er is een afdeling . De afdeling

FeitType FTF1

: :

FT3 heeft als hoofdcontactpersoon .


: : :

Hoofdcontactpersoon Er is een hoofdcontactpersoon . De hoofdcontactpersoon

69

Hoofdstuk 4

Casus

FeitType FTF1

: :

FT4 is gevestigd op .


: : :

Postadres Er is een postadres . Het postadres

FeitType FTF1

: :

FT5 heeft .


: : :

Post(bus)adresnummer Er is een post(bus)adresnummer . Het post(bus)adresnummer

NaamType NTF1

: :

Nummer <…>

FeitType FTF1

: :

FT6 heeft .


: : :

Postcode Er is een postcode . De postcode

NaamType NTF1

: :

Postcodeaanduiding <…>

FeitType FTF1

: :

FT7 is gevestigd in .


: : :

Plaats Er is een plaats . De plaats

FeitType FTF1

: :

FT8 is gevestigd op .


: : :

Bezoekadres Er is een bezoekadres . Het bezoekadres

FeitType FTF1

: :

FT9 heeft .


: : :

Bezoekadresnummer Er is een bezoekadresnummer . Het bezoekadresnummer

FeitType FTF1

: :

FT10 heeft .


: : :

Bezoekpostcode Er is een bezoekpostcode . De bezoekpostcode

FeitType FTF1

: :



: : :

Bezoekplaats Er is een bezoekplaats . De plaats

FeitType FTF1

: :



: : :

Land Er is een land . Het land

FeitType FTF1

: :

FT13 heeft als e-mail <E-mailadres>.


: : :

E-mailadres Er is een e-mailadres <E-mailadresaanduiding>. Het e-mailadres <E-mailadresaanduiding>

NaamType NTF1

: :

E-mailadresaanduiding <…>

FeitType FTF1

: :

FT14 heeft als Internetsite .


: : :

Internetadres Er is een Internetadres . Het Internetadres

70

Hoofdstuk 4

Casus

NaamType NTF1

: :

Internetadresaanduiding <…>

FeitType FTF1

: :

FT15 valt onder .


: : :

Adrescategorie Er is een adrescategorie . De adrescategorie

NaamType NTF1

: :

Adrescategorieaanduiding <…>

FeitType FTF1

: :

FT16 is zakelijk telefonisch bereikbaar onder .

FeitType FTF1

: :

FT17 is privé telefonisch bereikbaar onder .

FeitType FTF1

: :

FT18 is per fax bereikbaar onder .

FeitType FTF1

: :

FT19 De gegevens voor zijn voor het laatst gewijzigd op <Wijzigingsdatum>.


: : :

Wijzigingsdatum Er is een wijzigingsdatum .

NaamType NTF1

: :

Datumaanduiding <…>

FeitType FTF1

: :

FT20 De gegevens voor zijn <Markering> gemarkeerd.


: : :

Markering Er is een markering <Markeringsaanduidingaanduiding>. <Markeringsaanduiding>

NaamType NTF1

: :

Markeringsaanduiding <…>

FeitType FTF1

: :

FT21 heeft .


: : :

Demo Er is een demo van . De demo van

NaamType NTF1

: :

Democode <…>

FeitType FTF1

: :

FT22 Bij zijn .


: : :

Opmerkingen Er zijn opmerkingen . opmerkingen

NaamType NTF1

: :

Opmerkingsaanduiding <…>

FeitType FTF1

: :

FT23 hoort bij .


: : :

Factuur Er is een factuur . De factuur

NaamType NTF1

: :

Factuurnummer <…>

FeitType FTF1

: :

FT24 bestaat uit een bestelling voor .


: : :

Programma Er is een programma . Het programma

NaamType NTF1

: :

Programmacode <…>

FeitType FTF1

: :

FT25 behorende bij is geschikt voor .

71

Hoofdstuk 4

Casus


: : :

Aantal Netwerken Er is een aantal netwerken . netwerk(en)

NaamType NTF1

: :

Getal <…>

FeitType FTF1

: :

FT26 behorende bij is geschikt voor .


: : :

Aantal Netwerkgebruikers Er is een aantal netwerkgebruikers . netwerkgebruiker(s)

FeitType FTF1

: :

FT27 behorende bij is van .


: : :

Programmatype Er is een type . Het type <programmatypeaanduiding>

NaamType NTF1

: :

Programmatypeaanduiding <…>

FeitType FTF1

: :

FT28 Bij behorende bij zijn .

FeitType FTF1

: :

FT29 Bij hoort .


: : :

Contactpersoon Er is een contactpersoon . De contactpersoon

NaamType NTF1

: :

Persoonsnummer <…>

FeitType FTF1

: :

FT30 heeft .


: : :

Aanhef Er is een aanhef . De aanhef

NaamType NTF1

: :

Aanhefaanduiding <…>

FeitType FTF1

: :

FT31 heeft .


: : :

Roepnaam Er is een roepnaam . De roepnaam

FeitType FTF1

: :

FT32 heeft .


: : :

Voorletters Er zijn voorletters . De voorletters

NaamType NTF1

: :

Voorletteraanduiding <…>

FeitType FTF1

: :

FT33 heeft .


: : :

Achternaam Er is een achternaam . De achternaam

FeitType FTF1

: :

FT34 heeft .


: : :

Tussenvoegsel Er is een tussenvoegsel . Het tussenvoegsel

NaamType NTF1

: :

Tussenvoegselaanduiding <…>

FeitType FTF1

: :

FT35 heeft .

72

Hoofdstuk 4

Casus


: : :

Persoonsaanhef Er is een persoonsaanhef . De persoonsaanhef

NaamType NTF1

: :

Persoonsaanhefaanduiding <…>

FeitType FTF1

: :

FT36 heeft .


: : :

Functie Er is een functie . De functie

NaamType NTF1

: :

Functieaanduiding <…>

FeitType FTF1

: :

FT37 heeft als e-mail <E-mailadres>.

FeitType FTF1

: :

FT38 is zakelijk telefonisch bereikbaar onder .

FeitType FTF1

: :

FT39 is privé telefonisch bereikbaar onder .

FeitType FTF1

: :

FT40 De gegevens voor zijn voor het laatst gewijzigd op <Wijzigingsdatum>.

FeitType FTF1

: :

FT41 De gegevens voor zijn <Markering> gemarkeerd.

FeitType FTF1

: :

FT42 Bij zijn .

Figuur 4-17: InformatieGrammatica voor klantenbestand Nedercom Eduware

De bovenstaande InformatieGrammatica bevat duidelijke elementaire zinnen uit de natuurlijke taal en is zowel voor de gebruiker als voor de informatieanalist goed te begrijpen. Maar zoals reeds vermeld in paragraaf 3.8 Diagrammisatiekan bij een groot aantal zinnen het overzicht en het verband tussen de zinnen snel verloren gaan. Dat is ook het geval bij de bovenstaande InformatieGrammatica met 42 FeitTypen. Om de zinnen toch op een overzichtelijke wijze weer te kunnen geven, zonder het inzicht in het verband tussen de zinstypen te verlizen, moet er een volgende stap plaatsvinden, namelijk de omzetting van de InformatieGrammatica naar een InformatieGrammaticaDiagram (IGD). Dit is het onderwerp van de volgende paragraaf.

4.5 Stap 4: Diagrammisatie

Met behulp van de InformatieGrammatica in Figuur 4-17 kan er nu een IGD opgezet worden. Ik zal de behandelde theorie in paragrafen 3.8.1, 3.8.2 en 3.8.3 hieronder toepassen op het eerste FeitType FT1 in Figuur 4-17. FeitType FT1 in Figuur 4-17 bevat twee invulplaatsen (lees: rollen): en <School>. We hebben hier dus te maken met een binair FeitType. We geven vervolgens elke rol een unieke naam: R1 voor en R2 voor <School>. We kunnen FeitType FT1 als volgt diagrammiseren:

73

Hoofdstuk 4

Casus FT1 R1

R2

FTF1: vertegenwoordigt <School>. 0187 0292

ROC Oost Nederland Centrum Vakopleiding

Figuur 4-18: Diagrammisatie van FeitType FT1

Alle twee de Rollen worden gespeeld door een BegripType. De invulplaats in de FeitTypeFormulering van FTF1 uit het FeitType FT1 verwijst naar het BegripType Klant en de in invulplaats <School> verwijst naar het BegripType School. Rol R1 wordt dus gespeeld door het BegripType Klant en de Rol R2 wordt gespeeld door het BegripType School. Beide BegripTypen bestaan slechts uit één invulplaats. We hebben hier dus te maken met twee unaire BegripTypen (zie 3.8.2 BegripType diagrammiseren, pagina 26). Het BegripType Klant heeft als Rol en het BegripType School heeft als Rol. Ook hier krijgt iedere Rol weer een unieke naam: R3 voor en R4 voor . Er zijn niet meer BegripTypen die onder het FeitType FT1 vallen. We kunnen de BegripTypen nu als volgt diagrammiseren: Klant

School

BTF1: De klant

BTF1: De school

R3

R4

FTF1: Er is een klant .

FTF1: Er is een school .

0187 0292


FT1 R1

R2



Figuur 4-19: Diagrammisatie van BegripTypen behorende bij FeitType FT1

Nu rest alleen nog de diagrammisatie van de NaamTypen behorende bij FeitType FT1 (zie 3.8.3 NaamType diagrammiseren, pagina 27). Uit de InformatieGrammatica van Figuur 4-17 kunnen we opmaken dat FeitType FT1 twee NaamTypen bevat, namelijk het NaamType Klantnummer dat de Rol R3 speelt en het NaamType Naam dat de Rol R4 speelt. We kunnen deze NaamTypen als volgt diagrammiseren (wat resulteert in een volledig IGD van FeitType FT1):

74

Hoofdstuk 4

Casus

Klantnummer

Naam

NTF1: <…>

NTF1: <…>

Klant

School

BTF1: De klant

BTF1: De school

R3

R4

FTF1: Er is een klant .

FTF1: Er is een school .

0187 0292

ROC Oost Nederland Centrum Vakopleiding FT1 R1

R2



Figuur 4-20: Diagrammisatie van NaamTypen behorende bij FeitType FT1

Omdat we in FeitType FT1 alleen te maken hebben met twee unaire BegripTypen Klant en School die elk specifieke gegevens vastleggen, kunnen ze op een verkorte manier weergegeven worden: Klant (Klantnummer)

School (Naam)

FT1 R1

R2

FTF1: vertegenwoordigt <School>. BTF1: De klant <…>

0187 0292


BTF1: De school <…>

Figuur 4-21: Verkorte notatie van de unaire BegripTypen behorende bij FeitType FT1

Het IGD voor FeitType FT1 kan vervolgens in een aantal stappen gecontroleerd worden op correctheid. Stap 1: BegripTypeFormuleringen van de BegripTypen Klant en School substitueren aan de hand van FeitTypeFormulering FTF1 van het FeitType FT1 ( vertegenwoordigt <School>.). BTF1: De klant

BTF1: De school

FTF1: vertegenwoordigt <School>. 0187 ROC Oost Nederland substitueer door BegripTypeFormuleringen van BegripTypen Klant en School FTF1: De klant vertegenwoordigt de school . 0187 ROC Oost Nederland

Figuur 4-22: Controle IGD – Substituering BegripTypen

75

Hoofdstuk 4

Casus

Stap 2: NaamTypeFormuleringen van Klantnummer en Naam substitueren. NTF1: <...>

NTF1: <...>

FTF1: De klant vertegenwoordigt de school . 0187 ROC Oost Nederland substitueer door NaamTypeFormuleringen van NaamTypen Klantnummer en Naam

FTF1: De klant <...> vertegenwoordigt de school <...>. 0187 ROC Oost Nederland

Figuur 4-23: Controle IGD – Substituering NaamTypen

Stap 3: Het oorspronkelijke feit opstellen door op de puntjes van de NaamTypeFormuleringen de individuele namen in te vullen.

FTF1: De klant <...> vertegenwoordigt de school <...>. 0187 ROC Oost Nederland

De klant 0187 vertegenwoordigt de school ROC Oost Nederland.

Figuur 4-24: Controle IGD – Opstellen van het oorspronkelijke feit

Als we dezelfde methode toepassen op alle overige FeitTypen krijgen we het InformatieGrammaticaDiagram zoals is weergegeven in Figuur 4-25. In dit diagram zijn tevens de NaamTypePreciseringen (zie 3.8.6 NaamType preciseren, pagina 31) en BeperkingsRegels (zie 3.9 Beperkingsregels, pagina 32) opgenomen.

76

Hoofdstuk 4

Casus

UR1 VRR1 Klant • (Klantnummer)

R1

UR31_32

School (Naam)

FT1

N

R2

N

R4

FTF1: hoort bij .

UR5 VRR5

•

BTF1: De afdeling <…>

Economie -

0187 0292

Hoofdcontactpersoon (Naam)

FT3

R5

R6

Dhr. H.J.C. Stuart Mevr. B. Schoonbeek

0187 0292 UR7 VRR7

•

•

R9

R10

0187 0292

•

R12

•

0187 0292

•

R13

Bezoekadres (Naam)

R16

N

FTF1: is gevestigd op . 0187 0292

VRR17

•

R18

N

FTF1: heeft . 0187 0292

250 279

UR19 VRR19

•

FT10

R19

UR21

•

BTF1: Het bezoekadresnummer <…> Bezoekpostcode (Postcodeaanduiding)

R20

VRR23

•

FT12

R23

DVR2

R24

N

FTF1: is gevestigd in . 0187 Nederland 0292 Nederland FT13

UR25_26 R25

E-mailadres (E-mailadresaanduiding)

R26

N

FTF1: heeft als e-mail .

BTF1: Het e-mail0187 [email protected] adres <…> 0292 Internetadres FT14 (Internetadresaanduiding) UR27_28 R27

R28

⊇

UR29 VRR29

•

R29

R30

FTF1: valt onder . 0187 0292

mbo mbo UR77_78

R78

FT37

R77

O

WR1

BTF1: De adrescategorie <…>

Aantal Netwerken (Getal)

R52

Aantal Netwerkgebruikers (Getal)

R54

FT27

R55

R57

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045


Wup V V

VRR69

•

R58


-

0696 0795 0041 0737

Voorletters (Voorletteraanduiding) N

R70

N

FT34

R71

0696 0795 0041 0737

•

-

R73

Tussenvoegsel (Tussenvoegselaanduiding)

R72

N BTF1: Het tussenvoegsel <…>

Persoonsaanhef (Persoonsaanhefaanduiding)

UR73 VRR73

BTF1: De achternaam <…>

Roelvink Stuart Baks Schoonbeek

FTF1: heeft .

FT35 R74

N

FTF1: heeft .

BTF1: De persoonsDhr. R. Roelvink aanhef <…> Dhr. H.J.C. Stuart Mevr. M. Baks Mevr. B. Schoonbeek

0696 0795 0041 0737

WR5 N

Functie FT36 (Functieaanduiding)

UR75_76 R76

N

FTF1: heeft .

Opmerkingen (Opmerkingsaanduiding)

0696 0795 0041 0737

systeembeheer doc. Duits doc. Nederlands doc. Nederlands

BTF1: De functie <…>

N UR87_88

BTF1: <…>

R87

FT42

R88

FTF1: Bij zijn .

FTF1: heeft als e-mail . [email protected] [email protected] -

BTF1: De roepnaam <…>

R68

R69

R75

FTF1: Bij behorende bij zijn . LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

FT32

UR71

BTF1: <…> netwerkgebruiker(s)

FT28 R60

N

Harrie Mirjam -

0696 0795 0041 0737

DVR4 R59

R66

FTF1: heeft .

BTF1: Het type <…>

UR58_59_60

Roepnaam (Naam)

FTF1: heeft . BTF1: De voorletters 0696 R. <…> 0795 H.J.C. 0041 M. Achternaam 0737 B. (Naam) UR69 FT33

R

Programmatype (Pogrammatypeaanduiding)

BTF1: De aanhef <…>

FT31

UR67

FT26

FTF1: behorende bij is van .

⊇

0696 0795 0041 0737

BTF1: Het programma <…>

FT25 R51

UR55_56_57 R56


R67

DVR3

FTF1: heeft als Internetsite . 0187 0292


R49

N

FTF1: heeft .

N

FTF1: behorende bij is geschikt voor . LZ98.006 LZ2 60 SP00.002 SP2 60 TP01.007 TPDE 32 SP97.045 SP1 12 SP97.045 SP2 12

N

BTF1: Het Internetadres <…> http://www.roc-on.nl Adrescategorie (Adrescategorieaanduiding) FT15

FT24

UR52_53_54 R53

BTF1: Het land <…>

Programma (Programmacode)

FTF1: behorende bij R is geschikt voor . LZ98.006 LZ2 1 BTF1: <…> netwerk(en) SP2 SP00.002 1 TPDE TP01.007 1 GR SP97.045 SP1 1 SP97.045 SP2 1 GR1 ⊇

R64

R65

UR49_50_51

Aanhef (Aanhefaanduiding)

FT30

UR65

WR4

R50

BTF1: De bezoekplaats <…> Land (Naam)

0187 0187 0187 0292

R48

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

DVR1

N

FTF1: is gevestigd in . 0187 Enschede 0292 Nijmegen

0696 0795 0041 0737

R46

R47

0696 0795 0041 0737

R63

N

BTF1: De contactpersoon <…>

FTF1: heeft .

FTF1: bestaat uit een bestelling voor .

Bezoekplaats (Naam)

R22

UR23

•

UR47_48

•

⊇

BTF1: De bezoekpostcode <…>

FT11

R21

VRR63 FT23

LZ98.006 SP00.002 TP01.007 SP97.045

VRR47

N

FTF1: heeft . 7544 RG 0187 6542 AA 0292

VRR21

Factuur (Factuurnummer)

•

UR63

-

R45

VRR62

R62

0187 0187 0292 0292

FTF1: hoort bij .

N Bezoekadresnummer (Nummer) BTF1: De factuur <…>

FT9

R17

•

BTF1: Het bezoekadres <…>

Buurserstraat Wolfkuilseweg

UR17

VRR45

Contactpersoon (Persoonsnummer)

FT29

FTF1: Bij hoort .

R44

0187 0292

0696 0795 0041 0737

R61 BTF1: De demo van <…>

FT22

UR45

FT8

R15

FO UR43_44

R43

•

N

FTF1: heeft . 0187 0292

VRR85

UR61_62

WR3

R42

FT41

R85

niet wel niet niet

Demo (Democode)

FT21

UR41_42 R41

UR85

FTF1: De gegevens voor zijn gemarkeerd.

BTF1: <…>

wel niet

•

0696 0795 0041 0737

R86

N

BTF1: De plaats <…>

Enschede Nijmegen

UR15

•

0187 0292

1-2-2001 8-5-2001 2-2-2001 2-2-2001

BTF1: <…>

R40

VRR83

R83

FTF1: De gegevens voor zijn voor het laatst gewijzigd op .

WR2


FT40

UR83 R84

Markering (Markeringsaanduiding)

FT20

R39

N

FTF1: is gevestigd in .

VRR15

•

0696 0795 0041 0737

FTF1: heeft .

R14

0187 0292

VRR39

Plaats (Naam)

FT7

9-5-2001 12-4-2001

UR39

BTF1: De postcode <…>

7544 RG 6504 AD

UR13 VRR13

0187 0292

N

FTF1: heeft .

-

I d-mjjjj

R38

FT39 R81

FTF1: is privé telefonisch bereikbaar onder .

Wijzigingsdatum (Datumaanduiding)

FT19

R37

Postcode (Postcodeaanduiding)

FT6

R11

053 – 850 41 10 -

UR37

BTF1: Het post(bus)adresnummer <…>

250 40199

UR11 VRR11

0187 0292

N

FTF1: heeft .

R82

R36


N

FTF1: is gevestigd op . BTF1: Het postadres <…> 0187 Buurserstraat 0292 Postbus Post(bus)adresnummer (Nummer) UR9 FT5 VRR9

R35

VRR37

Postadres (Naam)

R8

UR81_82

R34

FTF1: is privé telefonisch bereikbaar onder . 0187 0292 FT18 UR35_36

BTF1: De hoofdcontactpersoon <…>

FT4

R7

053 – 850 41 70 0696 0795 0041 0737

FT17

UR33_34 R33

R79

FTF1: is zakelijk telefonisch bereikbaar onder .

053 – 850 41 00 024 – 377 32 22

0187 0292

FT38

R80

N

FTF1: is per fax bereikbaar onder .

N

FTF1: heeft als hoofdcontactpersoon .

UR79_80

Nummer

R32

FTF1: is zakelijk telefonisch NTF1: <…> bereikbaar onder .

FTF1: vertegenwoordigt . BTF1: De school <…> N ROC Oost Nederland 0187 Centrum Vakopleiding 0292 Afdeling BTF1: De klant (Naam) UR3 <…> FT2 R3

FT16

R31

Figuur 4-25: IGD relatiebeheer Nedercom Eduware

0696 0795 0041 0737

-

77

Hoofdstuk 4

Casus

Uit Figuur 4-25 kunnen we opmaken dat de meeste individuele namen van de meeste NaamTypen tot de nominale schaal behoren (zie 3.8.6 NaamType preciseren, pagina 31). De individuele namen van het NaamType Adrescategorieaanduiding behoren tot de ordinale schaal, omdat we een betekenis qua volgorde aan ze kunnen toekennen: een mbo-school is hoger in niveau dan een vbo-school. De individuele namen van het NaamType Datumaanduiding behoren tot de interval schaal, immers: datums kun je bij elkaar optellen en van elkaar aftrekken. Tot slot behoren de individuele namen van het NaamType Getal tot de ratio schaal (zie 3.8.6 NaamType preciseren, pagina 32).

4.6 Stap 5: Beperkingsregels toevoegen

De vijfde stap van de UI is het toevoegen van BeperkingsRegels aan het IGD (zie 3.9 Beperkingsregels). In het IGD van Figuur 4-25 heb ik deze BeperkingsRegels reeds opgenomen. Hieronder volgt een toelichting op de toepassing van deze regels.

4.6.1 UniciteitsRegel opstellen

De volgende UniciteitsRegels (URs) (bij binaire Rollen) zijn denkbaar: R1

R2

A B

C C

R3

R4 G H

R6

R7

R8

R9

R10

R11

I J

K K L

M N N

O P Q

R S S

T U V

Figuur 4-26: Voorbeelden van UniciteitsRegels (bij binaire Rollen)

In het de eerste twee gevallen gelden URs over de Rollen R1 en R4. Onder deze Rollen mogen geen dubbele waarden voorkomen. Onder de Rollen R2 en R3 mogen echter wel dubbele waarden voorkomen. In het derde geval geldt dat onder geen van de Rollen R5 en R6 dubbele waarden voor mogen komen. In het vierde geval geldt een UR boven de combinatie van de Rollen R7 en R8, waarmee aangegeven wordt dat de combinatie van waarden niet dubbel voor mag komen. Tot slot wordt in het vijfde geval aangegeven dat UniciteitsRegels elkaar ook kunnen overlappen. Met behulp van Figuur 4-26 geef ik in het onderstaande schema voor elk van de feiten uit het InformatieGrammaticaDiagram van Figuur 4-25 aan aan welke URs voldaan moet worden. De eerst genoemde zin bij elk FeitType is de oorspronkelijke zin. De daarop volgende zinnen zijn nieuw bedachte zinnen om te controleren of ze in combinatie met de oorspronkelijke zin uitgesproken kunnen worden. Een achter de zin geeft aan dat hij niet toegestaan is, een achter de zin geeft aan dat hij wel toegestaan is.

78

Hoofdstuk 4 FT1 1) 2) 3)

0187 0187 0202

Casus

vertegenwoordigt “ “ “

ad. 2) ad. 3)

. ROC Oost Nederland. Clusius College. ROC Oost Nederland.

Een klant kan slechts één school vertegenwoordigen. De klant met klantnummer 0187 vertegenwoordigt de school ROC Oost Nederland en kan dus niet tegelijkertijd de school Clusius College vertegenwoordigen. Een andere klant kan best een school met dezelfde naam vertegenwoordigen als een andere klant. Zo zijn er bijvoorbeeld verschillende AOC’s in Nederland (die onder de afdeling vbo-groen vallen).

Dit levert een UR op boven de Rol R1. Voor FT2 geldt dezelfde redenering als voor FT1. Dit levert dus een UR op boven de Rol R3. FT3 1) 2) 3)

0187 0187 0202

heeft als hoofdcontactpersoon “ “ “

ad. 2)

ad. 3)

. Dhr. H.J.C. Stuart. Dhr. K. Kuipers. Dhr. H.J.C. Stuart.

Bij één klant hoort slechts één hoofdcontactpersoon. De klant met klantnummer 0187 heeft Dhr. H.J.C. Stuart als hoofdcontactpersoon, dus Dhr. K. Kuipers kan dan niet de hoofdcontactpersoon voor klant 0187 zijn. Het is daarentegen wel mogelijk dat bij een andere klant Dhr. H.J.C. Stuart ook als hoofdcontactpersoon fungeert. Het kan een andere persoon zijn met dezelfde naam of het is dezelfde persoon die aan verschillende scholen werkzaam is en als hoofdpersoon fungeert.

Dit levert een UR op boven de Rol R5. FT4 1) 2) 3)

0187 0187 0202 ad. 2) ad. 3)

is gevestigd op “ “ “ Een klant kan het postadres Een klant kan andere school plaats staat,

. Buurserstraat. Pastoorweg. Buurserstraat. slechts op één postadres gevestigd zijn. De klant met klantnummer 0187 is gevestigd op Buurserstraat en kan dus niet tegelijkertijd gevestigd zijn op het postadres Pastoorweg. wel op eenzelfde postadres gevestigd zijn als een andere klant, bijvoorbeeld als het een betreft die in dezelfde straat staat of als het een school betreft die in een andere maar dezelfde straatnaam heeft.


0187 0187 0202 ad. 2) ad. 3)

heeft “ “ “

. 250. 40199. 250.

Een klant kan slechts één post(bus)adresnummer hebben. De klant met klantnummer 0187 heeft het post(bus)adresnummer 250 en kan dus niet tegelijkertijd het post(bus)adresnummer 40199 hebben. Een klant kan wel hetzelfde post(bus)adresnummer hebben als een andere klant.


0187 0187 0202 ad. 2) ad. 3)

heeft “ “ “

. 7544 RG. 8915 KK. 7544 RG.

Een klant kan slechts op één postcode hebben. De klant met klantnummer 0187 heeft de postcode 7544 RG en kan dus niet tegelijkertijd de postcode 8915 KK hebben. Een klant kan wel dezelfde postcode hebben als een andere klant, bijvoorbeeld als twee afdelingen van een school gevestigd zijn op hetzelfde adres of als twee klanten naast elkaar gevestigd zijn, dan hebben ze ook dezelfde postcode.


0187 0187 0202 ad. 2) ad. 3)

is gevestigd in “ “ “

. Enschede. Leeuwarden. Enschede.

Een klant kan slechts in één plaats gevestigd zijn. De klant met klantnummer 0187 is gevestigd in Enschede en kan dus niet tegelijkertijd gevestigd zijn in Leeuwarden. Een andere klant kan uiteraard wel gevestigd zijn in een andere plaats.

Dit levert een UR op boven de Rol R31. Voor FT8, FT9, FT10 en FT11 geldt dezelfde redenering als voor respectievelijk FT4, FT5, FT6 en FT7. Dit levert dus de volgende URs op: •

UR boven Rol R15.

•

UR boven Rol R17.

•

UR boven Rol R19.

•

UR boven Rol R21.

Voor FT12 geldt een soortgelijke redenering als voor FT7 en FT10. Dit levert dus een UR op boven de Rol R23.

79

Hoofdstuk 4 FT13 1) 2) 3) 4)

0187 0187 0202 0187 ad. 2) ad. 3) ad. 4)

Casus

heeft als e-mail “ “ “ “

. [email protected]. [email protected]. [email protected]. [email protected].

Een klant kan meerdere e-mailadressen hebben. Een klant kan ook een e-mailadres hebben dat gelijk is aan het e-mailadres van een andere klant, bijvoorbeeld als het om een algemeen e-mailadres gaat van een school dat meerdere afdelingen heeft. Voor een klant kan maar slechts één keer een specifiek e-mailadres opgenomen worden.

Dit levert een UR op boven de combinatie van de Rollen R25 en R26. Voor FT14 geldt een soortgelijke redenering als voor FT13. Dit levert een UR op boven de combinatie van de Rollen R27 en R28.

FT15 1) 2) 3)

0187 0187 0202 ad. 2) ad. 3)

valt onder “ “ “

. mbo. hbo. mbo.

Een klant kan slechts onder één adrescategorie vallen. De klant met klantnummer 0187 valt onder de adrescategorie mbo en kan dus niet tegelijkertijd onder de adrescategorie hbo vallen. Een andere klant kan uiteraard wel onder een andere adrescategorie vallen.

Dit levert een UR op boven de Rol R29. FT16 1) 2) 3) 4)

0187 0187 0202 0187 ad. 2) ad. 3)

ad. 4)

is zakelijk telefonisch bereikbaar onder “ “ “ “

. 053 – 850 053 – 850 053 – 850 053 – 850

41 41 41 41

00. 05. 00. 00.

Een klant kan bereikbaar zijn onder meerdere zakelijke telefoonnummers. Een klant kan ook een zakelijk telefoonnummer hebben dat gelijk is aan het zakelijke telefoonnummer van een andere klant, bijvoorbeeld als het om een algemeen telefoonnummer gaat van een school dat meerdere afdelingen heeft. Voor een klant kan maar slechts één keer een specifiek zakelijk telefoonnummer opgenomen worden.

Dit levert een UR op boven de combinatie van de Rollen R31 en R32. Voor FT17 en FT18 geldt een soortgelijke redenering als voor FT16. Dit levert de volgende URs op: •

UR boven de combinatie van de Rollen R33 en R34.

•


FT19 1) 2) 3)

De gegevens voor “ “ “ ad. 2)

ad. 3)

0187 0187 0202

zijn voor het laatst gewijzigd op “ “ “

. 9-5-2001. 12-4-2001. 9-5-2001.

De gegevens voor een klant kunnen slechts één wijzigingsdatum hebben. De gegevens voor de klant met klantnummer 0187 zijn voor het laatst gewijzigd op 9-5-2001 en kunnen dus niet tegelijkertijd gewijzigd zijn op 12-4-2001. De gegevens voor een andere klant kunnen uiteraard wel op een andere datum gewijzigd zijn.

Dit levert een UR op boven de Rol R337. Voor FT20 geldt een soortgelijke redenering als voor FT19. Dit levert een UR op boven de Rol R39. FT21 1) 2) 3) 4)

0292 0292 0202 0292 ad. 2) ad. 3) ad. 4)

heeft “ “ “ “

. FO. SP. FO. FO.

Een klant kan een demo van verschillende programma’s hebben. Een klant kan dezelfde demo van een programma hebben als een andere klant. Voor een klant kan maar slechts één keer een specifieke demo van een programma opgenomen worden.

Dit levert een UR op boven de combinatie van de Rollen R41 en R42. FT22 1) 2) 3) 4)

0187 0187 0202 0187 ad. 2) ad. 3) ad. 4)

heeft “ “ “ “

. -. offerte 15/8/98. -. -.

Bij een klant kunnen verschillende opmerkingen horen. Bij een andere klant kunnen uiteraard ook opmerkingen zijn. Een specifieke opmerking kan maar één keer bij een klant vermeld worden.

Dit levert een UR op boven de combinatie van de Rollen R43 en R44.

80

Hoofdstuk 4 FT23 1) 2) 3)

SP00.002 SP00.002 SP01.009 ad. 2)

Casus hoort bij “ “ “

. 0187. 0202. 0187.

Een factuur hoort slechts bij één klant. De factuur met factuurnummer SP00.002 hoort bij de klant met klantnummer 0187 en kan dus niet tegelijkertijd bij de klant met klantnummer 0202 horen. Een klant kan meerdere facturen hebben.

ad. 3)

Dit levert een UR op boven de Rol R45. FT24 1) 2) 3) 4)

SP00.002 SP00.002 SP01.009 SP00.002 ad. 2) ad. 3) ad. 4)

bestaat uit een bestelling voor “ “ “ “

. SP2. SP1. SP2. SP2.

Een factuur kan uit een bestelling voor meerdere programma’s bestaan. Er kunnen meer facturen zijn met een bestelling voor een bepaald soort programma. Op een factuur kan maar slechts één keer een bestelling voor een specifiek soort programma opgenomen zijn.

Dit levert een UR op boven de combinatie van de Rollen R47 en R48. FT25 1) 2) 3) 4) 5)

SP2 SP2 SP2 SP1 SP2 ad. 2) ad. 3)

ad. 4) ad. 5)

behorende bij “ “ “ “ “

SP00.002 SP01.009 SP00.002 SP00.002 SP00.002

is geschikt voor “ “ “ “ “

. 1. 1. 2. 1. 1.

Meerdere facturen kunnen een bestelling voor een bepaald soort programma dat geschikt is voor 1 netwerk bevatten. Een bestelling voor een specifiek bepaald soort programma behorende bij een factuur kan maar uit één aantal netwerk(en) bestaan. Het programma Spelling 2 behorende bij de factuur SP00.002 is geschikt voor 1 netwerk en kan dus niet tegelijkertijd geschikt zijn voor 2 netwerken. Op een factuur kunnen bestellingen voor meerdere soorten programma’s opgenomen zijn. Op een factuur kan maar één keer één bepaald soort programma dat geschikt is voor een aantal netwerk(en) opgenomen worden. Op de factuur SP00.002 is een programma Spelling 2 opgenomen dat geschikt is voor 1 netwerk. Dit kan niet twee keer vermeld worden.

Dit levert een UR op boven de combinatie van de Rollen R49, R50 en R51. Voor FT26 geldt een soortgelijke redenering als voor FT25. Dit levert een UR op boven de combinatie van de Rollen R52, R53 en R54. FT27 1) 2) 3) 4) 5)

SP2 SP2 SP2 SP1 SP2 ad. 2) ad. 3)

ad. 4) ad. 5)


SP00.002 SP01.009 SP00.002 SP00.002 SP00.002

is van “ “ “ “ “

. Wup. Wup. V. Wup. Wup.

Meerdere facturen kunnen uit een bestelling voor een bepaald soort programma bestaan dat van het type Windows update is. Er kunnen meerdere types voor een specifiek bepaald soort programma vastgelegd worden behorende bij een bepaalde factuur. Het programma Spelling 2 behorende bij de factuur SP00.002 is van het type Windows update, maar kan daarnaast ook van het type Volledige versie zijn. Op een factuur kunnen bestellingen voor meerdere soorten programma’s van een bepaald type opgenomen zijn. Op een factuur kan maar één keer één bepaald soort programma van een specifiek type opgenomen worden. Op de factuur SP00.002 is een programma Spelling 2 opgenomen van het type Windows update. Dit kan niet twee keer vermeld worden.

Dit levert een UR op boven de combinatie van de Rollen R55, R56 en R57. FT28 1) 2) 3) 4) 5)

SP2 SP2 SP2 SP1 SP2 ad. 2) ad. 3) ad. 4) ad. 5)


SP00.002 SP01.009 SP00.002 SP00.002 SP00.002

is van “ “ “ “ “

. -. -. vervanging basisinstallatie. -. -.

Bij iedere factuur met een bestelling voor een bepaald soort programma kan een opmerking opgenomen zijn. Bij een bepaald programma behorende bij een bepaalde factuur kunnen meerdere opmerkingen horen. Op een factuur kunnen bestellingen voor meerdere soorten programma’s, voorzien van een aantal opmerkingen, opgenomen zijn. Op een factuur kan maar één keer één bepaald soort programma voorzien van een specifieke opmerking opgenomen worden. Op de factuur SP00.002 is een programma Spelling 2 zonder opmerkingen opgenomen. Dit kan niet twee keer vermeld worden.

Dit levert een UR op boven de combinatie van de Rollen R58, R59 en R60.

81

Hoofdstuk 4 FT29 1) 2) 3) 4)

Bij “ “ “ “

Casus

0187 0187 0202 0187

ad. 2) ad. 3) ad. 4)

hoort “ “ “ “

. 0696. 0795. 0696. 0696.

Bij een klant kunnen verschillende contactpersonen horen. Bij een klant kan een contactpersoon horen die ook bij een andere klant hoort, bijvoorbeeld als de contactpersoon werkzaam is aan twee scholen. Een contactpersoon kan maar één keer voorkomen bij een klant.

Dit levert een UR op boven de combinatie van de Rollen R61 en R62. FT30 1) 2) 3)

0696 0696 0799 ad. 2) ad. 3)

heeft “ “ “

. Dhr. Mevr. Dhr.

Een contactpersoon heeft maar één aanhef. Voor een andere contactpersoon kan uiteraard een andere aanhef gelden.

Dit levert een UR op boven de Rol R63. Voor FT31, FT32, FT33, FT34 en FT35 geldt een soortgelijke redenering als voor FT30. Dit levert de volgende URs op: •

UR boven de Rol R65.

•


•


•


•


FT36 1) 2) 3) 4)

0696 0696 0799 0696 ad. 2) ad. 3) ad. 4)

heeft “ “ “ “

. systeembeheer. ict-coördinatie. systeembeheer. systeembeheer.

Een contactpersoon kan meerdere functies hebben. De functie systeembeheerder kan uiteraard van toepassing zijn op meerdere contactpersonen. Een specifieke functie kan maar één keer voor een contactpersoon aangegeven worden.

Dit levert een UR op boven de combinatie van de Rollen R75 en R76. Voor FT37 geldt een soortgelijke redenering als voor FT13. Dit levert dus een UR op boven de combinatie van de Rollen R77 en R78. Voor FT38 en FT39 geldt een soortgelijke redenering als voor FT16 en FT17. Dit levert de volgende URs op: •


•


Voor FT40 en FT41 geldt een soortgelijke redenering als voor FT19. Dit levert de volgende URs op: •


•


Voor FT42 geldt een soortgelijke redenering als voor FT22. Dit levert een UR op boven de combinatie van de Rollen R87 en R88.

Samengevat krijgen we dus de volgende UniciteitsRegels in het IGD van Figuur 4-25: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

UR1 UR3 UR5 UR7 UR9 UR11 UR13 UR15 UR17 UR19 UR21

11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

UR23 UR25_26 UR27_28 UR32_33 UR29 UR31_32 UR33_34 UR35_36 UR37 UR39 UR41_42

21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.

UR43_44 UR45 UR47_48 UR49_50_51 UR52_53_54 UR55_56_57 UR58_59_60 UR61_62 UR63 UR65 UR67

31. UR69 32. UR71 33. UR73 34. UR75_76 35. UR77_78 36. UR79_80 37. UR81_82 38. UR83 39. UR85 40. UR87_88 82

Hoofdstuk 4

Casus

4.6.2 VerplichteRolRegels opstellen

In de verwoordingen, de InformatieGrammatica van Figuur 4-17 en het IGD van Figuur 4-25 komt het teken “-“ vaak voor. Dit duidt een zogenaamde NULL-waarde aan en betekent dat de desbetreffende waarde onbekend of niet aanwezig is. Dit betekent dus dat er voor de bijbehorende Rol geen VerplichteRolRegel geldt, immers: als er geen individuele namen voor de Rol beschikbaar zijn, moet deze leeg blijven en kan er dus geen verplichte waarde ingevuld worden. Als gekeken wordt naar de individuele namen onder de Rollen in het IGD van Figuur 4-25 zou op het eerste gezicht voor een aantal Rollen een VerplichteRolRegel gelden. Na nader onderzoek aan de hand van extra voorbeelden (die hier, vanwege de ruimte die ze innemen, niet opgenomen zijn) blijkt dit toch niet het geval te zijn, bijvoorbeeld bij FT36: niet voor iedere contactpersoon hoeft een functie vastgelegd te worden; het komt voor dat voor een contactpersoon de functie (nog) niet bekend is. Hetzelfde geldt voor FT25 en FT26: niet voor elk programma behorende bij een factuur wordt het aantal netwerken respectievelijk het aantal netwerkgebruikers vastgelegd. De individuele namen onder de Rollen vormen dus niet een geheel representatieve verzameling van de feiten. Om te voorkomen dat het IGD over verschillende pagina’s verspreid wordt, heb ik niet alle mogelijke feiten onder de Rollen opgenomen. Ik geef hieronder aan welke VerplichteRolRegels van toepassing zijn in het IGD van Figuur 4-25: VRR1:

Bij iedere

klant

hoort een

school.

∀x ∃y Sxy

VRR5:

“

“

“

hoofdcontactpersoon.

∀x ∃y Hxy

VRR7:

“

“

“

postadres.

∀x ∃y Pxy

VRR9:

“

“

“

post(bus)adresnummer.

∀x ∃y Pxy

VRR11:

“

“

“

postcode.

∀x ∃y Pxy

VRR13:

“

“

“

plaats.

∀x ∃y Pxy

VRR15:

“

“

“

bezoekadres.

∀x ∃y Bxy

VRR17:

“

“

“

bezoekadresnummer.

∀x ∃y Bxy

VRR19:

“

“

“

bezoekpostcode.

∀x ∃y Bxy

VRR21:

“

“

“

bezoekplaats.

∀x ∃y Bxy

VRR23:

“

“

“

land.

∀x ∃y Lxy

VRR29:

“

“

“

adrescategorie.

∀x ∃y Axy

VRR37:

“

“

“

wijzigingsdatum.

∀x ∃y Wxy

VRR39:

“

“

“

markering.

∀x ∃y Mxy

VRR45:

Bij iedere

factuur

hoort een

klant.

∀x ∃y Kxy

VRR47:

Voor iedere

“

is er een

programma.

∀x ∃y Pxy

VRR62:

Bij iedere

contactpersoon

hoort een

klant.

∀x ∃y Kxy

VRR63:

Voor iedere

“

is er een

aanhef.

∀x ∃y Axy

VRR69:

“

“

“

achternaam.

∀x ∃y Axy

VRR73:

“

“

“

persoonsaanhef.

∀x ∃y Pxy

VRR83:

“

“

“

wijzigingsdatum.

∀x ∃y Wxy

VRR85:

“

“

“

markering.

∀x ∃y Mxy

De meest voorkomende regels zijn nu aan bod geweest. Nu kan er gekeken worden of er nog overige BeperkingsRegels (zie 3.9.3 Overige BeperkingsRegels) op het IGD van toepassing zijn.

4.6.3 Overige BeperkingsRegels opstellen DeelVerzamelingsRegel (DVR) De volgende DVRs zijn van toepassing: 83

Hoofdstuk 4

DVR1:

DVR2:

DVR3:

DVR4:

Casus

Als er voor een programma behorende bij een factuur een aantal netwerken vastgelegd wordt, dan moet het programma behorende bij de factuur voorkomen in FT24. Met andere woorden: voor elke zin is de populatie onder de combinatie van de Rollen R49 en R50 slechts toegestaan als de overeenkomstige combinatie voorkomt onder de combinatie van de Rollen R47 en R48. Als er voor een programma behorende bij een factuur een aantal netwerkgebruikers vastgelegd wordt, dan moet het programma behorende bij de factuur voorkomen in FT24. Met andere woorden: voor elke zin is de populatie onder de combinatie van de Rollen R52 en R53 slechts toegestaan als de overeenkomstige combinatie voorkomt onder de combinatie van de Rollen R47 en R48. Als er voor een programma behorende bij een factuur een type vastgelegd wordt, dan moet het programma behorende bij de factuur voorkomen in FT24. Met andere woorden: voor elke zin is de populatie onder de combinatie van de Rollen R55 en R56 slechts toegestaan als de overeenkomstige combinatie voorkomt onder de combinatie van de Rollen R47 en R48. Als er voor een programma behorende bij een factuur een opmerking vastgelegd wordt, dan moet het programma behorende bij de factuur voorkomen in FT24. Met andere woorden: voor elke zin is de populatie onder de combinatie van de Rollen R58 en R59 slechts toegestaan als de overeenkomstige combinatie voorkomt onder de combinatie van de Rollen R47 en R48.

GelijkheidsRegel (GR) De volgende GelijkheidsRegel is van toepassing: GR1:

Als er voor een programma behorende bij een factuur een aantal netwerken vastgelegd wordt, dan moet er voor dat programma behorende bij de factuur ook een aantal netwerkgebruikers vastgelegd worden. Met andere woorden: de populatie onder de combinatie van de Rollen R52 en R53 moeten gelijk zijn aan de combinatie onder de Rollen R49 en R50.

WaardenRegel (WR) Er zijn een aantal WaardenRegels van toepassing op het IGD van Figuur 4-25. Vanwege de ruimte heb ik alleen het nummer van de WaardenRegels (WR1, WR2, etc.) in het diagram opgenomen. De bijbehorende waarden worden hieronder opgesomd. WR1: WR2: WR3: WR4:

WR5: WR6: WR7:

[avo, bkh, hbo, mbo, particulier, v/avo, v/hbo, v/mbo, vcd, vce, vcn] [wel, niet] [SP, FO, LZ, NN, GR, DE, DDD, MG, TP, WN] [SP1, SP2, SP3, FO1, FO2, FO3, LZ1, LZ2, LZ3, 12VBO, 1VM, 2VM, 1HV, 2HV, GR, DE, DDD, MG, TPSP1, TPSP2, TPSP3, TPFO1, TPFO2, TPFO3, TP12VBO, TP1VM, TP2VM, TP1HV, TP2HV, TPGR, TPDE, TPDDD, TPMG, WN4, WN5, WN6, WN7] [Wup, V, T, SA, P, S, Onbeperkt] [Dhr., Mevr., Dhr./Mevr.] [doc. Duits, doc. Engels, doc. Nederlands, ict-coördinatie, systeembeheer]

4.7 Stap 6: FeitTypen als BegripTypen

De volgende stap in het analyseproces is het achterhalen van FeitTypen die omgezet kunnen worden naar BegripTypen (zie 3.10 FeitTypen als BegripTypen). Het IGD van Figuur 4-25 bevat geen FeitTypen die betrekking hebben op een combinatie van twee of meer BegripTypen, dus er zijn geen FeitTypen die omgezet hoeven te worden naar BegripTypen.

4.8 Stap 7: Redundantie verwijderen

Voordat het IGD omgezet kan worden naar een relationeel model, moet er eerst nog gekeken worden of er nog enige vorm van overtolligheid in de InformatieGrammatica of in de InformatieBank voorkomt (zie 3.11 Redundantie verwijderen).

84

Hoofdstuk 4

Casus

4.8.1 Redundantie in de InformatieGrammatica

Eerst moet er gekeken worden of er zich dubbele NaamTypen, BegripTypen of Rollen in het IGD bevinden. Eventuele wijzigingen worden weergegeven in het herziene IGD van Figuur 4-27 (zie pagina 87). 1. NaamType-samentrekking Bij de verwoording van de feiten is al aangegeven dat de telefoonnummers en faxnummers allemaal tot hetzelfde type behoren, namelijk tot het type Nummer. In het IGD van Figuur 4-25 is het enige gediagrammiseerde NaamType Nummer dat verbonden is met de Rollen R32, R34, R36, R80 en R82 reeds samengetrokken tot één NaamType. Daarnaast valt op te merken dat het NaamType Naam vaak voorkomt. Dit zijn echter allemaal individuele namen die tot een verschillend type behoren. Het is daarom beter om aan de afzonderlijke NaamTypen verschillende namen te geven: Schoolnaam, Afdelingsnaam, Persoonsnaam, Adresnaam (na BegripTypesamentrekking van de BegripTypen Postadres en Bezoekadres), Plaatsnaam (na BegripType-samentrekking van de BegripTypen Plaats en Bezoekplaats), Landnaam, Roepnaamaanduiding en Achternaamaanduiding. 2. BegripType-samentrekking Als we goed naar het IGD van Figuur 4-25 kijken, zien we dat een aantal BegripTypen (E-mailadres, Wijzigingsdatum en Markeringsaanduiding) reeds samengetrokken zijn. Er zijn echter nog een aantal BegripTypen die samengetrokken kunnen worden. Daartoe kan onderstaand procedure toegepast worden. Uiteraard zijn bij het samentrekken van onderstaande BegripTypen de FeitTypeFormuleringen van de betrokken FeitTypen in het herziene IGD waar nodig aangepast om betekenisvolle formuleringen voor de feiten van de FeitTypen te krijgen (zie Figuur 4-27, pagina 87). a. Postadres en Bezoekadres Is het mogelijk dat het adres Buurserstraat zowel een postadres als een bezoekadres aanduidt? De klant 0187 heeft het postadres Buurserstraat. De klant 0187 heeft het bezoekadres Buurserstraat.

Dit is best mogelijk, dus betekent het dat de BegripTypen Postadres en Bezoekadres samengetrokken kunnen worden tot één BegripType Adres. b. Post(bus)adresnummer en Bezoekadresnummer Is het mogelijk dat het adresnummer 250 zowel een post(bus)adresnummer als een bezoekadresnummer aanduidt? 85

Hoofdstuk 4

Casus

De klant 0187 heeft het post(bus)adresnummer 250. De klant 0187 heeft het bezoekadresnummer 250.

Dit is best mogelijk, dus betekent het dat de BegripTypen Post(bus)adresnummer en Bezoekadresnummer samengetrokken kunnen worden tot één BegripType Adresnummer. c. Plaats en Bezoekplaats Is het mogelijk dat de plaats Enschede zowel een plaats als een bezoekplaats aanduidt? De klant 0187 is gevestigd in de plaats Enschede. De klant 0187 is gevestigd in de bezoekplaats Enschede.

Dit is best mogelijk, dus betekent het dat de BegripTypen Plaats en Bezoekplaats samengetrokken kunnen worden tot één BegripType Plaats. d. Postcode en Bezoekpostcode Is het mogelijk dat de postcode 7544 RG zowel een postcode als een bezoekpostcode aanduidt? De klant 0187 heeft de postcode 7544 RG. De klant 0187 heeft de bezoekpostcode 7544 RG.

Dit is best mogelijk, dus betekent het dat de BegripTypen Postcode en Bezoekpostcode samengetrokken kunnen worden tot één BegripType Postcode. 3. Rol-samentrekking Het IGD van Figuur 4-25 bevat geen verschillende formuleringen voor verschillende feiten van hetzelfde type. Er hoeft dus geen Rol-samentrekking plaats te vinden.

4.8.2 Redundantie in de InformatieBank

Zoals reeds vermeld in paragraaf 3.11.2 Redundantie in de InformatieBank, hoeft deze overtolligheid niet verholpen te worden, maar moet ze wel in het IGD aangegeven worden. Het IGD van Figuur 4-25 bevat één afleidbaar feit, namelijk FT35 * FT30, FT32, FT34, FT33: een persoonsaanhef bestaat altijd uit de combinatie van aanhef, voorletters, tussenvoegsel (indien aanwezig) en achternaam. Deze afleidingsregel wordt hieronder weergegeven in het herziene IGD in Figuur 4-27. 86

Hoofdstuk 4

Casus


R1

UR31_32

School (Schoolnaam)

FT1

N

R2

FTF1: hoort bij .

UR5 VRR5

•


FT3

R5

R6

0187 0292 UR7

•

•

0187 0292

Buurserstraat Postbus

UR15

•

R15

VRR39

•

BTF1: Het adres <…>

•

R10

0187 0292

250 40199

N

UR17 VRR17

•

FT9

R17

0187 0292

BTF1: Het adresnummer <…>

R18

0187 0292

250 279

UR11 VRR11

•

VRR45

•

FT6

R11

R12

7544 RG 6504 AD

0187 0292 UR19 VRR19

•

N

N

FT10

R19

BTF1: De postcode <…>

R20

BTF1: De factuur <…>

•

Plaats (Plaatsnaam)

Enschede Nijmegen

UR21

•

FT11

R21

BTF1: De plaats <…>

UR23

•

FT12

R23

N

FTF1: is gevestigd in . 0187 Nederland 0292 Nederland

R25

FT13

BTF1: Het land <…>


R26

N

BTF1: Het e-mail0187 [email protected] adres <…> 0292 Internetadres FT14 (Internetadresaanduiding) UR27_28 R28

⊇

UR29 VRR29

•

R29

R30

O

FTF1: valt onder . 0187 0292

BTF1: De adrescategorie <…>

mbo mbo UR77_78

R78

WR1

FT37

R77


R52


R54

UR55_56_57 R56

FT27

R55

R57

⊇


Wup V V

VRR69

•

R58


-

0696 0795 0041 0737

N

0696 0795 0041 0737

R73


R72

-

UR73

•

BTF1: De achternaam <…>

FT34

R71

N BTF1: Het tussenvoegsel <…>


FT35 * FT30,FT32, FT34, R74 FT33

N

FTF1: heeft .

BTF1: De persoonsDhr. R. Roelvink aanhef <…> Dhr. H.J.C. Stuart Mevr. M. Baks Mevr. B. Schoonbeek

0696 0795 0041 0737

WR5 N


UR75_76 R76

N

FTF1: heeft .


0696 0795 0041 0737


BTF1: De functie <…>

N UR87_88

BTF1: <…>

FTF1: heeft als e-mail . [email protected] [email protected] -

R70


R75

R60

N

FTF1: heeft .

VRR73 Programmatype (Pogrammatypeaanduiding)

Voorletters (Voorletteraanduiding)

R68

UR71

BTF1: <…> netwerkgebruiker(s)

FT28

FTF1: Bij behorende bij zijn . LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

FT32

R69

0696 0795 0041 0737

DVR4 R59

Harrie Mirjam -

FTF1: heeft .

BTF1: Het type <…>

UR58_59_60

N BTF1: De roepnaam <…>

FTF1: heeft . BTF1: De voorletters 0696 R. <…> 0795 H.J.C. 0041 M. Achternaam 0737 B. (Achternaamaanduiding) UR69 FT33

R

FTF1: behorende bij is van . LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

R66

UR67

FT26

DVR3

FTF1: heeft als Internetsite . 0187 0292

FT25 R51

FTF1: behorende bij is geschikt voor . LZ98.006 LZ2 60 SP00.002 SP2 60 TP01.007 TPDE 32 SP97.045 SP1 12 SP97.045 SP2 12

N

BTF1: Het Internetadres <…> http://www.roc-on.nl Adrescategorie (Adrescategorieaanduiding) FT15

BTF1: Het programma <…>

BTF1: De aanhef <…>

Roepnaam (Roepnaamaanduiding)

FT31

R67

UR52_53_54 R53

FTF1: heeft als e-mail .

R27

⊇


0696 0795 0041 0737

N


R49

N

FTF1: heeft .

FTF1: behorende bij R is geschikt voor . LZ2 LZ98.006 1 BTF1: <…> netwerk(en) SP2 SP00.002 1 TPDE TP01.007 1 GR SP1 SP97.045 1 SP2 SP97.045 1 GR1 DVR2

R24

UR25_26

Land (Landnaam)

R64

R65 Programma (Programmacode)

FT24

UR49_50_51 R50

R22

FTF1: is gevestigd in . 0187 Enschede Nijmegen 0292

VRR23

⊇

DVR1 N


FT30

UR65

R48

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

FT7

FTF1: is gevestigd in .

VRR21

0187 0187 0187 0292

FTF1: bestaat uit een bestelling voor .

R14

0187 0292

0696 0795 0041 0737

R46

R47

0696 0795 0041 0737

R63

N

BTF1: De contactpersoon <…>

FTF1: heeft .

WR4

•

UR13 R13

•

UR47_48

VRR47

FTF1: heeft . 7544 RG 0187 6542 AA 0292

VRR13

VRR63 FT23

LZ98.006 SP00.002 TP01.007 SP97.045

•

UR63

FTF1: hoort bij .

Factuur (Factuurnummer)


FTF1: heeft .

VRR62

R62

0187 0187 0292 0292

-

R45


FT29

FTF1: Bij hoort .

FT22

UR45

0696 0795 0041 0737

R61 BTF1: De demo van <…>

R44

0187 0292

•

UR61_62

WR3

FTF1: heeft .

FTF1: heeft .

VRR85

N

FO UR43_44

R43

FT41

R85

niet wel niet niet

Demo (Democode)

FTF1: heeft .

Adresnummer (Nummer)

FTF1: heeft .

UR85


BTF1: <…>

R42

•

0696 0795 0041 0737

R86

N

FT21

UR41_42

1-2-2001 8-5-2001 2-2-2001 2-2-2001

WR2

wel niet

VRR83

R83


BTF1: <…>

R40

R41

R84


FT20

0187 0292

FT5

R9

9-5-2001 12-4-2001

R39


UR9

R38

FT40

UR83

I d-mjjjj


FTF1: is gevestigd op .

VRR9

R37

UR39

R16

0187 0292

FT19

0187 0292

N

FT8

0696 0795 0041 0737

-



Adres (Adresnaam)

FTF1: is gevestigd op .

VRR15

UR37 VRR37

R8

053 – 850 41 10 -

FT39 R81

FTF1: is privé telefonisch bereikbaar onder .

R36

0187 0292

BTF1: De hoofdcontactpersoon <…>

FT4

R7

UR81_82 R82

FTF1: is per fax bereikbaar onder .

N


053 – 850 41 70 0696 0795 0041 0737

R34

R35

R79

FTF1: is zakelijk telefonisch bereikbaar onder .

FTF1: is privé telefonisch bereikbaar onder . 0187 0292 FT18 UR35_36

BTF1: De afdeling <…>

FTF1: heeft als hoofdcontactpersoon .

VRR7

R33

Economie -

0187 0292

N

FT17

UR33_34

FT38

R80

053 – 850 41 00 024 – 377 32 22

0187 0292

N

R4

UR79_80

Nummer

R32

FTF1: is zakelijk telefonisch NTF1: <…> bereikbaar onder .

FTF1: vertegenwoordigt . BTF1: De school <…> N ROC Oost Nederland 0187 Centrum Vakopleiding 0292 Afdeling BTF1: De klant (Afdelingsnaam) UR3 FT2 <…> R3

FT16

R31

Figuur 4-27: Herziene IGD na redundantieverwijdering

R87

FT42

R88

FTF1: Bij zijn . 0696 0795 0041 0737

-

87

Hoofdstuk 4

Casus

4.9 Stap 8: Omzetting naar relationeel model

Aan de hand van de eerste zeven stappen is het analyseproces voltooid. Nu resteert alleen nog de omzetting van het NIAM-schema naar een relationeel model. Zoals in paragraaf 3.12 Het relationele model beschreven is, gebeurt dit in een drietal stappen. Het omzettingsproces naar een relationeel model voorkomt dubbele opslag in een database en kan vergeleken worden met het normalisatieproces zoals dat beschreven wordt door Boonstra e.a. (1992: 92-97). Hieronder zal ik de drie omzetstappen toepassen op het NIAM-schema van Figuur 4-27.

4.9.1 Stap 1: Groeperen

Rond een BegripType A worden gegroepeerd: alle binaire FeitTypen waarbij een rol gespeeld wordt door het BegripType A en waarbij die Rol onderhevig is aan een korte UniciteitsRegel (een UniciteitsRegel over één Rol). FeitTypen met één Rol, twee Rollen met een langere UniciteitsRegel of drie Rollen of meer worden niet gegroepeerd. Zulke FeitTypen vormen aparte tabellen. Voor het groeperen van binaire FeitTypen kunnen we onderstaand schema hanteren.

NIAM-Schema (IGD) Relationele model UR

A

FT1

UR

A UR

A A

UR

UR

UR

UR

•

A A

FT3

VRR

A

FT2

UR

UR

UR

UR

VRR

•

FT4

FT5

•

FT6

FT7

Functie (Functiecode)

A

VRR

VRR

•

B

FT1 groeperen bij A.

B

FT2 groeperen bij B.

B

FT3 wordt zelfstandige tabel.

B

FT4 groeperen bij A.

B

FT5 groeperen bij B.

B

FT6 groeperen bij A of B (kiezen).

B

FT7 groeperen bij A of B (kiezen).

B

FT8 groeperen bij B. In eerste instantie groeperen op UR; VRR doet er hier niet toe.

Functie (Functienaam)

UR VRR

•

FT8

Figuur 4-28: Groepering van binaire FeitTypen

88

Hoofdstuk 4

Casus


R1

N

R3

Economie -

UR5

•

R6

0187 0292

VRR7

•

R8 Buurserstraat Postbus

VRR37

•

UR15

•

R15

VRR39

•

R39


250 40199

R41

N

R17

R18

0187 0292 UR11 VRR11

•

R11

FT10

R19

•

UR45 VRR45 • Factuur (Factuurnummer)

N

•

UR63 VRR63


7544 RG 6504 AD

UR19 VRR19

-

R12

0187 0292

R20

0187 0292

N

7544 RG 6542 AA

FT23

R45

R46

LZ98.006 SP00.002 TP01.007 SP97.045

0187 0187 0187 0292

UR13

•

FT7

R13

•

0187 0292

N UR21 VRR21

•

0187 0292

⊇

R22

DVR1

Enschede Nijmegen

UR23 VRR23

•

R24

R25 0187 0292

FT13

DVR2

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Internet (Internetadresaanduiding)

R28

R29

R30

R78 [email protected] [email protected] -

R77 0696 0795 0041 0737

GR


60 60 32 12 12

WR1

R55 LZ2 SP2 TPDE SP1 SP2

R57

Programmatype (Pogrammatypeaanduiding) WR5

Wup V V

R59 LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045


R60 -

R73

R75 0696 0795 0041 0737

N


N

Dhr. R. Roelvink Dhr. H.J.C. Stuart Mevr. M. Baks Mevr. B. Schoonbeek

0696 0795 0041 0737


N

FT35 * FT30,FT32, FT34, R74 FT33

UR75_76

FT28


R72 -

N

DVR4

N

FT34

UR73

FT27

UR58_59_60

R70

0696 0795 0041 0737

R

Achternaam (Achternaamaanduiding)


R71


R54

R69

UR71

FT26

N

FT33

0696 0795 0041 0737

•

R56

⊇

FT37

UR77_78

•

R


R68 R. H.J.C. M. B.

UR69 VRR69

1 1 1 1 1

UR55_56_57

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Adrescategorie (Adrescategorieaanduiding) O

mbo mbo


DVR3

http://www.roc-on.nl -

0187 0292

FT25 R51

N

FT32

R67


R52

R66

0696 0795 0041 0737

VRR73 ⊇

N

FT15

R49

Roepnaam (Roepnaamaanduiding)

Harrie Mirjam -

UR67

UR52_53_54 R53

N

FT14

UR29

•


R26

UR27_28

0187 0292


GR1 ⊇

[email protected] -

R27

VRR29

N

Nederland Nederland

UR25_26

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Land (Landnaam)

FT12

R23 0187 0292

N

UR49_50_51 R50

N

FT31

0696 0795 0041 0737

FT11

R21

R64 Dhr. Dhr. Mevr. Mevr.

R65 Programma (Programmacode)

R48

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Plaats (Plaatsnaam)

Enschede Nijmegen

R47

R63

UR65

WR4

VRR47

R14

N


FT30

0696 0795 0041 0737

FT24

UR47_48

VRR13

•

0696 0795 0041 0737

R44

0187 0292

FT6

FT22

VRR62

R62

0187 0187 0292 0292


FT29

UR61_62 R61

FO

R43

•

N

UR43_44

250 279

VRR85

R85 0696 0795 0041 0737

WR3

R42

0187 0292

FT9

FT41

Demo (Democode)

FT21

UR41_42

R86 niet wel niet niet

wel niet

R10

UR17

•

N

•

0696 0795 0041 0737

UR85

WR2

R40

VRR83

R83


FT20

0187 0292

FT5

R9 0187 0292

VRR17

9-5-2001 12-4-2001

UR39


UR9

•

R38

R84 1-2-2001 8-5-2001 2-2-2001 2-2-2001

I d-mjjjj

R16

0187 0292

VRR9

R37

FT40

UR83 Wijzigingsdatum (Datumaanduiding)

FT19

0187 0292

FT8

0696 0795 0041 0737

053 – 850 41 10 -

UR37

Adres (Adresnaam)

-

FT18

FT39 R81

R36

0187 0292

N VRR15

-

FT4

R7 0187 0292

UR81_82 R82

R35


UR7

FT17

UR35_36

N

R79

053 – 850 41 70 0696 0795 0041 0737

R34

0187 0292


FT3

R5

R33

FT38

R80

N

053 – 850 41 00 024 – 377 32 22

UR33_34

N

R4

0187 0292

VRR5

Afdeling (Afdelingsnaam)

FT2

UR79_80

Nummer

R32

0187 0292


UR3

FT16

R31

N

R2

0187 0292

UR31_32

School (Schoolnaam)

FT1


R76

N


UR87_88 R87 0696 0795 0041 0737

FT42

R88 -

Figuur 4-29: De groepen in het IGD relatiebeheer Nedercom

89

Hoofdstuk 4

Casus

Aan de hand van het in Figuur 4-28 gegeven schema, kunnen er een drietal groepen onderscheiden worden in het IGD van Figuur 4-27. Deze drie groepen worden met behulp van markeringen weergegeven in Figuur 4-29 (zie hierboven). De gele markering geeft aan dat het FeitTypen betreft die niet gegroepeerd moeten worden. Dit worden zelfstandige tabellen. Samengevat krijgen we de volgende drie groepen: 1. FT1, FT2, FT3, FT4, FT5, FT6, FT7, FT8, FT9, FT10, FT11, FT12, FT15, FT19 en FT20 worden gegroepeerd rond het BegripType Klant. 2. FT30, FT31, FT32, FT33, FT34, FT35, FT40 en FT41 worden gegroepeerd rond het BegripType Contactpersoon. 3. FT23 wordt gegroepeerd rond het BegripType Factuur. De FeitTypen FT13, FT14, FT16, FT17, FT18, FT21, FT22, FT24, FT25, FT26, FT27, FT28, FT29, FT36, FT37, FT38, FT39 en FT42 worden dus niet gegroepeerd, omdat het hier FeitTypen betreft met drie Rollen of FeitTypen zonder korte UniciteitsRegel. Aan de hand van de in paragraaf 3.12.1 besproken bewerkingen die uitgevoerd moeten worden bij het groeperen van een IGD, ben ik tot gekomen tot het in Figuur 4-30 weergegeven gegroepeerde model (zie pagina 92). De arceringen in Figuur 4-30 komen overeen met de gearceerde groepen in Figuur 4-29. De volgende bewerkingen zijn uitgevoerd: 1. De binaire FeitTypen in het IGD van Figuur 4-29, waarbij de Rollen die gespeeld worden door BegripTypen die onderhevig zijn aan een korte UniciteitsRegel, zijn gegroepeerd rond het BegripType dat de betreffende Rol speelt: a. De Rollen R2, R4, R6, R8, R10, R12, R14, R16, R18, R20, R22, R24, R30, R38 en R40 zijn opgenomen rond het BegripType Klant, waarbij dit BegripType in het oorspronkelijke IGD respectievelijk de Rollen R1, R3, R5, R7, R9, R11, R13, R15, R17, R19, R21, R23, R29, R37 en R39 spelen die onderhevig zijn aan een korte UniciteitsRegel. b. De Rollen R64, R66, R68, R70, R72, R74, R83 en R85 zijn opgenomen rond het BegripType Contactpersoon, waarbij dit BegripType in het oorspronkelijke IGD respectievelijk de Rollen R63, R65, R67, R69, R71, R73, R82 en R84 spelen die onderhevig zijn aan een korte UniciteitsRegel. c. De Rol R46 is opgenomen rond het BegripType Factuur, waarbij dit BegripType in het oorspronkelijke IGD de Rol R45 speelt die onderhevig is aan een korte UniciteitsRegel. 2. De FeitTypen met twee Rollen met een langere UniciteitsRegel of drie Rollen vormen aparte tabellen. 3. Na opname van de Rollen die gespeeld worden door de Rollen met de korte UniciteitsRegel in de verschillende BegripTypen, worden de betreffende Rollen met de korte UniciteitsRegel met de bijbehorende BegripTypen gecombineerd: 90

Hoofdstuk 4

Casus

a. De Rollen R1, R3, R5, R7, R9, R11, R13, R15, R17, R19, R21, R23, R29, R37 en R39 die onderhevig zijn aan respectievelijk UR1, UR3, UR5, UR7, UR9, UR11, UR13, UR15, UR17, UR19, UR21, UR23, UR29, UR37 en UR39, worden na het opnemen van de Rollen R2, R4, R6, R8, R10, R12, R14, R16, R18, R20, R22, R24, R30, R38 en R40 in het BegripType Klant gecombineerd met de Rol R100. b. De Rollen R63, R65, R67, R69, R71, R73, R82 en R84 die onderhevig zijn aan respectievelijk UR63, UR65, UR67, UR69, UR71, UR73, UR82 en UR84, worden na het opnemen van de Rollen R64, R66, R68, R70, R72, R74, R83 en R85 in het BegripType Contactpersoon gecombineerd met de Rol R101. c. De Rol R45 die onderhevig is aan UR45, wordt na het opnemen van de Rol R46 in het BegripType Factuur gecombineerd met de Rol R102. 4. Als gevolg van de VerplichteRolRegels in het oorspronkelijke IGD krijgen de volgende Rollen de specificatie niet leeg (NL): a. R2, R6, R8, R10, R12, R14, R16, R18, R20, R22, R24, R30, R38 en R40 als gevolg van VRR1, VRR5, VRR7, VRR9, VRR11, VRR13, VRR15, VRR17, VRR19, VRR21, VRR23, VRR29, VRR37 en VRR39. Dit houdt in dat in het relationele tabelschema voor elke klant een school, hoofdcontactpersoon, postadres, post(bus)adresnummer, bezoekadres, bezoekadresnummer, postcode, bezoekpostcode, plaats, bezoekplaats, land, adrescategorie, wijzigingsdatum en markering bekend moet zijn. b. R64, R70, R74, R84 en R86 als gevolg van VRR63, VRR69, VRR73, VRR83 en VRR85. Dit houdt in dat in het relationele tabelschema voor elke contactpersoon een aanhef, achternaam, persoonsaanhef, wijzigingsdatum en markering bekend moet zijn. c. R46 als gevolg van VRR47. Dit houdt in dat in het relationele tabelschema voor elke factuur een klant bekend moet zijn. 5. De FeitTypen die een zelfstandige tabel vormen, geschikte namen gegeven: FT13 FT14 FT16 FT17 FT18 FT21 FT22 FT24 FT25

E-mailadres Klant Internetadres Zakelijk Adrestelefoonnummer Privé Adrestelefoonnummer Zakelijk Faxnummer Demo Opmerkingen Klant Programma Aantal Netwerken

FT26 FT27 FT28 FT29 FT36 FT37 FT38 FT39 FT42

Aantal Netwerkgebruikers Programmatype Opmerkingen Factuur Contactpersoonnummers Functie Emailadres Contactpersoon Zakelijk Persoonstelefoonnummer Privé Persoonstelefoonnummer Opmerkingen Contactpersoon

91

Hoofdstuk 4

Casus

School (Schoolnaam)

Hoofdcontactpersoon (Persoonsnaam)


Plaats (Plaatsnaam)

N

N

N

N


Klantnummer

Adres (Adresnaam)

N

N


O Land (Landnaam)


N


Adrescategorie (Adrescategorieaanduiding)

I d-mjjjj

N

N

N

Klant UR100 R2

R100

NL

R4

R6

ROC Oost Economie Nederland Centrum Vakopleiding

0187 0292

R8

NL

R10 NL

NL

Dhr. H.J.C. Buurserstraat 250 Stuart Postbus 40199 Mevr. B. Schoonbeek

R12

R14 NL

NL

7544 RG

Enschede

6504 AD

Nijmegen

R16 NL

R18 NL

Buurserstraat

R20 NL

R22 NL

R24 NL

R30 NL

R38 NL

R40 NL

250

7544 RG

Enschede

Nederland

mbo

9-5-2001

wel

Wolfskuilseweg 279

6542 AA

Nijmegen

Nederland

mbo

12-4-2001

niet

E-mailadres (E-mailadresaanduiding) N

E-mailadres Klant UR25_26 R25

R26

0187 0292

[email protected] Opmerkingen Klant

Internetadres (Internetadresaanduiding)

UR43_44 R44

R43 N

Internetadres

0187 0292 Zakelijk Adrestelefoonnummer

UR27_28 R28

0187 0292


Contactpersoonnummers

R31

R61 NL

053 – 850 41 00 024 – 377 32 22

Zakelijk Persoonstelefoonnummer

R62

R79

0696 0795 0041 0739

0696 0795 0041 0739

R34

R35

0187 0292

-

0187 0292

R80 053 – 850 41 70 -

UR41_42 R36

053 – 850 41 10 -

Opmerkingen Contactpersoon

UR81_82

R41

R42

0187 0292

FO

Demo (Democode) N

E-mailadres Contactpersoon

UR87_88

Functie

UR77_78

R81

R82

R87

R88

0696 0795 0041 0739

-

0696 0795 0041 0739

-




N

N

N

-

Demo

UR35_36

R33

Privé Persoonstelefoonnummer

UR79_80

Faxnummer

UR33_34

N

R32

0187 0292

UR58_59

0187 0187 0292 0292

Nummer

UR31_32

R27

Privé Adrestelefoonnummer

R77 0696 0795 0041 0739

UR75_76 R78

R75

[email protected] [email protected] -

R76 systeembeheer doc. Duits doc. Nederlands doc. Nederlands

0696 0795 0041 0739

Functie (Functieaanduiding) N

Opmerkingen (Opmerkingsaanduiding) N

Roepnaam Achternaam (Roepnaamaanduiding) (Achternaamaanduiding)

Persoonsnummer

N

N


N

N

Contactpersoon UR101 UR101 R64 NL

R101


0696 0795 0041 0739

R66

R68

R70 NL

Harrie Mirjam -

R. H.J.C. M. B.


R72 -

R74 NL

R84 NL


Opmerkingen Factuur

R86 NL

1-2-2001 8-5-2001 2-2-2001 2-2-2001

UR58_59_60

niet wel niet niet


Programma (Programmacode) N Factuurnummer


N

N

Factuur

Programma

UR102 R102

LZ98.006 SP00.002 TP01.007 SP97.045

Aantal Netwerken

UR47_48 R46 NL

0187 0187 0187 0292

R47 LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045


R60

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

-

Programmatype (Programmatypeaanduiding)


N

N

Aantal Netwerkgebruikers

UR49_50_51 R48 NL

R59

Programmatype

UR52_53_54

UR55_56_57

R49

R50

R51

R52

R53

R54

R55

R56

R57


LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

1 1 1 1 1


LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

60 60 32 12 12


LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Wup V V

Figuur 4-30: Gegroepeerd model van IGD relatiebeheer Nedercom

92

Hoofdstuk 4

Casus

Stap 2: Lexicaliseren

De tweede stap bij de omzetting van een IGD naar een relationeel model is het lexicaliseren van het gegroepeerde IGD. Zoals reeds vermeld in 3.12.2 betekent dit dat alle BegripTypen aangepast worden, zodanig dat alle Rollen gespeeld worden door een NaamType, waarbij alle BegripTypen uit het diagram verwijderd worden. De Rollen die in aanmerking komen voor lexicalisering zijn reeds in het gegroepeerde IGD van Figuur 4-30 gemarkeerd (vet- en schuingedrukt): dit zijn vrijwel alle Rollen, omdat ze allemaal gespeeld worden door BegripTypen. Bij het lexicaliseren hoeft slechts rekening gehouden te worden met één van de twee situaties, zoals beschreven in paragraaf 3.12.2 Lexicaliseren (zie pagina 48), namelijk met de eerste situatie; het oorspronkelijke IGD bevat slechts unaire BegripTypen. De Rollen R100, R32, R34, R36, R80, R82, R101 en R102 worden reeds gespeeld door NaamTypen. De volgende bewerkingen worden uitgevoerd om te komen tot een gelexicaliseerd model: 1. De unaire BegripTypen worden veranderd in NaamTypen: a. Uit UR100 kunnen we opmaken dat een klant geïdentificeerd wordt door een klantnummer. Het unaire BegripType Klant waardoor de Rollen R25, R27, R31, R33, R35, R41, R46 en R61 in het oorspronkelijke IGD gespeeld werd, wordt daarom veranderd in het NaamType Klantnummer waarnaar ieder van bovengenoemde Rollen nu verwijst. b. Uit UR101 kunnen we opmaken dat een contactpersoon geïdentificeerd wordt door een persoonsnummer. Het unaire BegripType Contactpersoon waardoor de Rollen R75, R78, R79, R81 en R87 in het oorspronkelijke IGD gespeeld werd, wordt daarom veranderd in het NaamType Persoonsnummer waarnaar ieder van bovengenoemde Rollen nu verwijst.\ c. Uit UR102 kunnen we opmaken dat een factuur geïdentificeerd wordt door een factuurnummer. Het unaire BegripType Factuur waardoor de Rollen R47, R50, R53, R56 en R59 in het oorspronkelijke IGD gespeeld werd, wordt daarom veranderd in het NaamType Factuurnummer waarnaar ieder van bovengenoemde Rollen nu verwijst. d. Verder worden de volgende unaire BegripTypen omgezet naar NaamTypen: BegripType School Afdeling Hoofdcontactpersoon Adres Adresnummer Postcode Plaats

NaamType Schoolnaam Afdelingsnaam Persoonsnaam Adresnaam Nummer Postcodeaanduiding Plaatsnaam

93

Hoofdstuk 4 Land Adrescategorie Wijzigingsdatum Markering E-mailadres Internetadres Demo Opmerkingen Functie Aanhef Roepnaam Voorletters Achternaam Tussenvoegsel Persoonsaanhef Programma Aantal Netwerken Aantal Netwerkgebruikers ProgrammaType

Casus Landnaam Adrescategorieaanduiding Datumaanduiding Markeringsaanduiding E-mailadresaanduiding Internetadresaanduiding Democode Opmerkingsaanduiding Functieaanduiding Aanhefaanduiding Roepnaamaanduiding Voorletteraanduiding Achternaamaanduiding Tussenvoegselaanduiding Persoonshefaanduiding Programmacode Getal Getal Programmatypeaanduiding

2. In het gelexicaliseerde model onstaan de volgende DeelVerzamelingsRegels: a. R25, R27, R31, R33, R35, R41, R43, R46 en R61 zijn allemaal deelverzamelingen van R100, wat dus resulteert in respectievelijk DVR1, DVR2, DVR3, DVR4, DVR5, DVR6, DVR7, DVR8 en DVR9. b. R62, R75, R77, R79, R81 en R87 zijn allemaal deelverzamelingen van R101, wat dus resulteert in respectievelijk DVR10, DVR11, DVR12, DVR13, DVR14 en DVR15. c. R47, R50, R53, R56 en R59 zijn allemaal deelverzamelingen van R102, wat dus resulteert in respectievelijk DVR16, DVR17, DVR18, DVR19 en DVR20. d. R49, R52, R55 en R58 zijn allemaal deelverzamelingen van R48, wat dus resulteert in respectievelijk DVR21, DVR22, DVR23 en DVR24.

94

Hoofdstuk 4

Casus

School (Schoolnaam)

Hoofdcontactpersoon (Persoonsnaam)


Plaats (Plaatsnaam)

N

N

N

N

Klantnummer


Adres (Adresnaam)

N

N


O Land (Landnaam)


N


Adrescategorie (Adrescategorieaanduiding)

I d-mjjjj

N

N

N

Klant UR100 R100

R2

R4

NL

R6

ROC Oost Economie Nederland Centrum Vakopleiding

0187 0292

R8

NL

R10 NL

NL

R12

Dhr. H.J.C. Buurserstraat 250 Stuart Postbus 40199 Mevr. B. Schoonbeek

R14 NL

NL

7544 RG

Enschede

6504 AD

Nijmegen

R16 NL

R18 NL

Buurserstraat

R20 NL

R22 NL

R24 NL

R30 NL

R38 NL

R40 NL

250

7544 RG

Enschede

Nederland

mbo

9-5-2001

wel

Wolfskuilseweg 279

6542 AA

Nijmegen

Nederland

mbo

12-4-2001

niet

E-mailadresaanduiding DVR1 ⊆

N

E-mailadres Klant UR25_26 R25

R26 [email protected] -

0187 0292

⊆

DVR7 Opmerkingen Klant UR43_44

Internetadresaanduiding

UR27_28 R27

R28

R31


0187 0292

⊆

DVR9

Contactpersoonnummers

Zakelijk Persoonstelefoonnummer

UR61_62 R62

R79

0696 0795 0041 0739

0696 0795 0041 0739

R81

053 – 850 41 70 -

0696 0795 0041 0739

-

0187 0292

UR41_42 R36

053 – 850 41 10 -


R82

R87

-

0696 0795 0041 0739

R42

0187 0292

FO

Demo (Democode) N

Functie

UR77_78 R88

DVR15

R41


UR87_88

DVR14

⊆

⊆

0187 0292

UR81_82 R80

DVR13

R35

Privé Persoonstelefoonnummer

UR79_80

⊇

R61 NL 0187 0187 0292 0292

053 – 850 41 00 024 – 377 32 22

R34

R77

-

-

Demo

UR35_36

R33

R44

0187 0292

Faxnummer

UR33_34

N

R32

0187 0292

Privé Adrestelefoonnummer

Nummer

UR31_32

DVR6

UR72_73 R78

R75

[email protected] 0696 [email protected] 0795 0041 0739 DVR12

0696 0795 0041 0739

DVR11

R76 systeembeheer doc. Duits doc. Nederlands doc. Nederlands

⊇

Zakelijk Adrestelefoonnummer

DVR5

⊇

Internetadres

DVR4

⊆

DVR3

⊇

N

⊇

DVR2

⊆

⊆

R43

Functieaanduiding Aanhefaanduiding

Voorletteraanduiding

Tussenvoegselaanduiding

N

N

N

N

Opmerkingsaanduiding N

Achternaamaanduiding

Roepnaamaanduiding

Persoonsnummer

N

N

Persoonsaanhefaanduiding

N

N

Contactpersoon UR101

⊆

Opmerkingen Factuur

R101

R64 NL Dhr. Dhr. Mevr. Mevr.

0696 0795 0041 0739

DVR8 ⊇

R66

R68

R70 NL

Harrie Mirjam -

R. H.J.C. M. B.

R72 -


R74 NL


Programmacode

DVR21

Programma

R46 NL

0187 0187 0187 0292

R47 LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Aantal Netwerken

⊇

UR47_48 R48 NL LZ2 SP2 TPDE SP1 SP2


R50

R51


LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

1 1 1 1 1

DVR22

-

Programmatypeaanduiding

DVR19 4 ⊇

⊆

N

Programmatype

UR52_53_54

R49

R60

⊇

Aantal Netwerkgebruikers

UR49_50_51

R59 LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

DVR20

N DVR18

⊆

⊆

DVR17

⊇

Factuur UR102

UR58_59_60 R58

niet wel niet niet

Getal

N

N

LZ98.006 SP00.002 TP01.007 SP97.045

1-2-2001 8-5-2001 2-2-2001 2-2-2001

Getal

Factuurnummer

DVR16

R86 NL

⊇ DVR24

N

R102

R84 NL

UR55_56_57

R52

R53

R54


LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

60 60 32 12 12

DVR23 ⊇

DVR10

R55

R56

R57


LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Wup V V

Figuur 4-31: Gelexicaliseerd model van IGD relatiebeheer Nedercom

95

Hoofdstuk 4

Casus

4.9.2 Stap 3: Omzetten naar relationele notatiewijze

De laatste stap is tot slot de omzetting van het gelexicaliseerde model naar een relationeel model. De BegripTypen vormen hierbij de tabellen, de NaamTypen worden de kolommen, de UniciteitsRegels vormen de (primaire en alternatieve) sleutels en de DeelVerzamelingsRegels vormen de refererende sleutels. De volgende bewerkingen vinden plaats bij de omzetting van het gelexicaliseerde model naar een relationeel model: 1. De BegripTypeNamen en de reeds benoemde FeitTypen die een zelfstandige tabel vormen worden omgezet naar een tabel met dezelfde naam. Dit levert de volgende tabellen op: 1. 2. 3. 4. 5. 6. 7. 8. 9.

10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

Klant E-mailadres Klant Internetadres Zakelijk Adrestelefoonnummer Privé Adrestelefoonnummer Faxnummer Demo Opmerkingen Klant Contactpersoon Contactpersoonnummers Functie E-mailadres Contactpersoon Zakelijk Persoonstelefoonnummer Privé Persoonstelefoonnummer Opmerkingen Contactpersoon Factuur Programma Aantal Netwerken Aantal Netwerkgebruikers Programmatype Opermerkingen Factuur

2. De Rollen uit de verschillende BegripTypen worden omgezet naar kolommen die de naam krijgen van het NaamType dat de desbetreffende Rol speelt in het gelexicaliseerde model. Sommige kolommen krijgen een andere naam, zodat de betekenis duidelijk is, bijvoorbeeld Aantal Netwerken in plaats van Getal en Zakelijk Adrestelefoonnummer in plaats van Nummer. In het gelexicaliseerde model wordt zowel de Rol R8 als de Rol R16 gespeeld door het BegripType Adres, wordt zowel de Rol R10 als R18 gespeeld door het BegripType Adresnummer, wordt zowel de Rol R12 als de Rol R20 gespeeld door het BegripType Postcodeaanduiding en wordt zowel de Rol R14 als de Rol R22 gespeeld door het BegripType Plaatsnaam. Uit het oorspronkelijke IGD van Figuur 4-27 kunnen we opmaken dat het hier respectievelijk een Postadres, Post(bus)adresnummer, Bezoekadres, Bezoekadresnummer, Postcode, Bezoekpostcode, Plaatsnaam en Bezoekplaatsnaam betreft. De kolommen krijgen daarom ook deze namen toegewezen. 96

Hoofdstuk 4

Casus

Daarnaast krijgen een aantal kolommen een iets andere naam dan die van het NaamType omdat de betekenis daardoor duidelijker wordt, bijvoorbeeld Wijzigingsdatum in plaats van Datumaanduiding en Persoonsaanhef in plaats van Persoonsaanhefaanduiding. 3. De UniciteitsRegels worden omgezet naar sleutels: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

UR100 UR25_26 UR27_28 UR31_32 UR33_34 UR35_36 UR41_42 UR43_44 UR61_62 UR75_76 UR77_78 UR79_80 UR81_82 UR87_88 UR101 UR102 UR47_48 UR49_50_51 UR52_53_54 UR55_56_57 UR58_59_60

SL1 Sl2 SL3 Sl4 SL5 SL6 SL7 SL8 SL9 SL10 SL11 SL12 SL13 SL14 SL15 SL16 SL17 SL18 SL19 SL20 SL21

4. De DeelVerzamelingsRegels worden omgezet naar refererende sleutels. Zo wordt DVR2 omgezet naar DV2: een klantnummer uit de tabel Internetadres refereert aan een klant uit de tabel Klant en de kolom Klantnummer in de tabel Klant vormt de primaire sleutel. Een soortgelijke redenering geldt voor de overige DeelVerzamelingsRegels.

97

Hoofdstuk 4

Casus

KLANT SL1 Schoolnaam

Afdelingsnaam

NL


Bezoekadresnummer

NL

⊆

DV1

DV5

Plaatsnaam

NL

7544 RG 6504 AD

Adrescategorie

NL

Nederland Nederland

Wijzigingsdatum

NL

mbo mbo

Klantnummer

0187 0292


0187 0292

DV6

DEMO

NL

wel niet

DV4

PRIVÉ ADRESTELEFOONNUMMER

SL4

Internetadres

NL


Markering

NL

9-5-2001 12-4-2001

DV3

Klantnummer

Bezoekadresnaam

NL

Enschede Nijmegen

ZAKELIJK ADRESTELEFOONNUMMER

⊆

⊆

⊆

Landnaam

DV2

[email protected] -

Postcode

NL

250 40199

SL3

FAXNUMMER

SL5

Zakelijk Adrestelnr

Klantnummer

Privé Adrestelnr

0187 0292

-

053 – 850 41 00 024 – 377 32 22

DV7

OPMERKINGEN KLANT

SL6

⊆

NL

INTERNETADRES

E-mailadres Klant

0187 0292

Post(bus)adresnummer

NL

Buurserstraat Postbus

Enschede Nijmegen

SL2 Klantnummer

Postadresnaam

Bezoekplaatsnaam

NL

7544 RG 6542 AA

E-MAILADRES KLANT

NL


Bezoekpostcode

250 279

⊆

Persoonsnaam

NL

Economie -

⊆

0187 0292

⊆

Klantnummer

SL7

SL8

Klantnummer

Faxnummer

Klantnummer

Democode

Klantnummer

Opmerkingen Klant

0187 0292

053 – 850 41 00 024 – 377 32 22

0187 0292

FO

0187 0292

-

DV9

CONTACTPERSOON SL9 Aanhef

Voornaam

Voorletters

Harrie Mirjam -

R. H.J.C. M. B.

⊆

DV10

CONTACTPERSOONNUMMERS

Achternaam

DV11

NL

Markering

1-2-2001 8-5-2001 2-2-2001 2-2-2001

DV12

SL12

Persoonsnummer

Functie

Persoonsnummer


0696 0795 0041 0739


0696 0795 0041 0739

[email protected] [email protected] -

0187 0187 0292 0292

DV13

ZAKELIJK PERSOONSTELEFOONNUMMER

NL

niet wel niet niet

E-MAILADRES CONTACTPERSOON

⊆

⊆

NL

Wijzigingsdatum

NL


SL11

Klantnummer

0696 0795 0041 0739

DV14

PRIVÉ PERSOONSTELEFOONNUMMER

SL13

DV15

OPMERKINGEN CONTACTPERSOON

SL14

SL15

Zakelijk Perstelnummer

Persoonsnummer

Privé Perstelnummer

Persoonsnummer


0696 0795 0041 0739

053 – 850 41 70 -

0696 0795 0041 0739

053 – 850 41 70 -

0696 0795 0041 0739

-

FACTUUR

DV16

PROGRAMMA

NL

Factuurnummer LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

0187 0187 0292 0292

⊆

DV22

NL


⊆

DV18

SL18

Programmacode

DV21 ⊇

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045

Programmacode LZ2 SP2 TPDE SP1 SP2

Aantal Netwerken

LZ98.006 SP00.002 TP01.007 SP97.045 SP97.045


1 1 1 1 1

DV23

DV20

Aantal Netwerkgebruikers 1 1 1 1 1



DV24

OPMERKINGEN FACTUUR

SL20

SL19 Factuurnummer

Programmacode

DV19

PROGRAMMATYPE

AANTAL NETWERKGEBRUIKERS

Factuurnummer

⊆

LZ98.006 SP00.002 TP01.007 SP97.045

SL17 Klantnummer

⊆

SL16 Factuurnummer

DV17

AANTAL NETWERKEN

⊆

⊆

DV8

⊆

Persoonsnummer

⊆

⊆

Persoonsaanhef

-

FUNCTIE

SL10 Persoonsnummer

Tussenvoegsel

NL


⊆

⊆

NL


0696 0795 0041 0739

⊆

Persoonsnummer

SL21 Programmatype Wup V V



Opmerkingen Factuur Wup V V

Figuur 4-32: Relationele notatiewijze relatiebeheer Nedercom

98

5 Conclusie

Met het in Figuur 4-32 weergegeven relationele model is de analyse, volgens de Universele Informatiekunde, van het relatiebeheer van Nedercom Eduware afgerond. Met behulp van dit model kan er een nieuw systeem ontwikkeld worden en kan het huidige systeem naar het nieuwe systeem geconverteerd worden. Vanwege de verschillende structuren tussen het oude en het nieuwe systeem, vergt het converteren nog tal van werkzaamheden die buiten de beschouwing van deze scriptie vallen. Ik heb in deze scriptie de nadruk gelegd op een analysemethode die plaats dient te vinden voorafgaande aan de bouw van een nieuw systeem. De analyse van een nieuw systeem en de implementatie ervan zijn nauw met elkaar verbonden, maar ze vormen wel beide een op zichzelfstaande bezigheid: de informatieanalist maakt een analyse (van de huidige situatie), de ontwikkelaar/programmeur implementeert datgene wat de informatieanalist geanalyseerd heeft. In hoofdstuk 2 van deze scriptie heb ik een korte inleiding gegeven over relatiebeheer en relatiebeheer management en heb ik aangegeven waarom het nuttig is om een relatiebeheersysteem in de vorm van een relationeel model te ontwikkelen. Ik heb geprobeerd duidelijk te maken waarom een goede analyse voorafgaande aan de implementatie belangrijk is. Hierbij heb ik de analysemethode van de Universele Informatiekunde toegepast op een praktijkgerichte situatie, namelijk op het relatiebeheer bij het bedrijf Nedercom Eduware. Deze Universele Informatiekunde wordt uitgebreid beschreven in hoofdstuk 3, waarbij ik voornamelijk gebruik gemaakt heb van het boek Informatie in model, over gegevens, feiten en afspraken van J. Eggink, E.J. Leenstra en G.M. Nijssen. De voorbeelden en figuren in dit hoofdstuk zijn dan ook ontleend aan dit boek. Gaandeweg dit hoofdstuk wordt al te meer duidlijk wat het nut van deze analysemethode is. Één van de vele voordelen is dat ze niet gekoppeld is aan bepaalde vakgebieden of toepassingen. Daarnaast vindt de analyse plaats op grond van in natuurlijke taal verwoorde feiten. Dit maakt zowel het leven van de gebruiker/geïnterviewde als van de informatieanalist een stuk aangenamer: de gebruiker kent het jargon dat binnen zijn bedrijf gebruikt wordt. De informatieanalist kan dus in de taal van de gebruiker communiceren. Verder doet de UI een beroep op de vaardigheid van de informatieanalist om te werken met ondubbelzinnig voorschrift. Via de stapsgewijze processen die de UI biedt, zou dit uiteindelijk moeten leiden tot een relationeel model zonder ondubbelzinnigheden, met andere woorden: een model met (zo min mogelijk) redundantie. Het voordeel van deze ondubbelzinnige werkwijze is dat de resultaten van de informatieanalyse reproduceerbaar zijn: gegeven dezelfde situatie, leidt het voorschrift tot gelijke beschrijvingen van die situatie, ook als de analyse door verschillende personen uitgevoerd zou worden. 99

Hoofdstuk 5

Conclusie

Het analyseproces voorafgaande aan de bouw van een systeem is een tijdrovende zaak, maar werpt wel zijn vruchten af. Ik heb een onderdeel van de relatiegegevens van Nedercom zonder voorafgaande analyse geïmplementeerd in een FileMaker database (zie bijlage). Het betreft hier personen die zich aanmelden voor demo’s, updates, etc. via het Internet. Zonder voorafgaande analyse heeft men nogal snel de neiging om alles in één database te gooien. Gaandeweg de implementie komen er steeds meer gegevens, velden en dergelijk bij die voor het grootste gedeelte tijdens een analyse van te voren vastgelegd hadden kunnen worden. Uiteindelijk leidt dit tot een opeenhoping van zaken die in strijd zijn met het relationele model, waaronder inconsistentie en dubbele gegevens. In hoofdstuk 4 heb ik daarom de in hoofdstuk 3 beschreven theorie van de UI toegepast op een bestaand relatiebeheersysteem bij Nedercom. Via het stappenplan van de UI heb ik alle relevante gegevens van het bestaande relatiebeheersysteem weten vast te leggen en weer te geven in een relationeel model. In de eerste twee paragrafen van hoofdstuk 4 heb ik een korte inleiding gegeven en de huidige situatie bij Nedercom geschetst. Vervolgens heb ik in paragraaf 4.3 relevante voorbeelden van het bestaande systeem verzameld. Aan de hand van deze voorbeelden heb ik in paragraaf 4.4 de tweede en derde stap van de analysemethode uitgewerkt: het verwoorden, klassificeren en kwalificeren van de feiten. Om de in paragraaf 4.4 verwoorde feiten op een overzichtelijk manier weer te geven, zonder dat daarbij het inzicht in het verband tussen de zinnen en de zinstypen te verliezen, heb ik in paragraaf 4.5 een diagrammatische weergave gegeven (de vierde stap van de analysemethode). Daarna heb ik de BeperkingsRegels toegevoegd, gekeken of er FeitTypen waren die omgezet konden worden naar BegripTypen en eventuele redundantie verwijderd (respectievelijk stappen 5, 6 en 7 van de analysemethode). Tot slot heb ik de laatste stap van de analysemethode, het omzettingsproces van het verkregen InformatieGrammaticaDiagram zonder redundantie, beschreven in paragraaf 4.9. Dit heeft een helder en gestructureerd relationeel model opgeleverd dat gebruikt kan worden bij de implementatie van het nieuwe systeem.

100

Hoofdstuk 5

Conclusie

Figuren

FIGUUR 2-1: HOE TREKKEN BEDRIJVEN BEZOEKERS NAAR HUN SITE EN HOE EFFECTIEF ZIJN DIE METHODEN?.....................................................................................6 FIGUUR 3-1: JARGON – EEN INFORMATIE GRAMMATICA DIAGRAM [BRON: EGGINK 1995: 8] ............................................................................11 FIGUUR 3-2: HET VERWOORDEN VAN DE FEITEN BETREKKING HEBBEND OP

AANKOOPDATUM EN TIJDSTIP VAN UITSCHRIJVEN VAN EEN AANKOOPBON [BRON: EGGINK 1995: 34] ..........................................................................15 FIGUUR 3-3: HET VERWOORDEN VAN EEN TWEEDE INSTANTIE VAN HETZELFDE FEIT (AANKOOPDATUM EN TIJDSTIP VAN UITSCHRIJVEN VAN EEN AANKOOPBON) VAN EEN ANDER VOORBEELDDOCUMENT [BRON: EGGINK 1995: 40] ..........................................................................17 FIGUUR 3-4: SUBSTITUERING VAN DE INVULPLAATSEN IN DE FEITTYPEFORMULERING (BEHORENDE BIJ HET FEITTYPE ARTIKELPRIJS) DOOR BEGRIP- EN NAAMTYPEFORMULERINGEN [BRON: EGGINK 1995: 51] ...........................21 FIGUUR 3-5: INFORMATIEGRAMMATICA [BRON: EGGINK 1995: 59-60] ..........................23 FIGUUR 3-6: DIAGRAMCONVENTIES VAN DE IGD-TAAL [BRON: EGGINK 1995: 65]........24 FIGUUR 3-7: DIAGRAMMISATIE VAN EEN FEITTYPE [BRON: EGGINK 1995: 67] ..............25 FIGUUR 3-8: DIAGRAMMISATIE VAN BEGRIPTYPEN [BRON: EGGINK 1995: 71] ..............26 FIGUUR 3-9: DIAGRAMMISATIE VAN NAAMTYPEN [BRON: EGGINK 1995: 71]................27 FIGUUR 3-10: CONTROLE IGD – SUBSTITUERING BEGRIPTYPEN [BRON: EGGINK 1995: 71] ........................................................................28 FIGUUR 3-11: CONTROLE IGD – SUBSTITUERING BEGRIP- EN NAAMTYPEN [BRON: EGGINK 1995: 72] ........................................................................28 FIGUUR 3-12: CONTROLE IGD – SUBSTITUERING NAAMTYPE [BRON: EGGINK 1995: 72] ........................................................................28 FIGUUR 3-13: CONTROLE IGD – OPSTELLEN VAN HET OORSPRONKELIJKE FEIT [BRON: EGGINK 1995: 72] ........................................................................29 FIGUUR 3-14: EEN VOLLEDIG IGD-VOORBEELD [BRON: EGGINK 1995: 73]....................30 FIGUUR 3-15: VERKORTE NOTATIE VAN EEN UNAIR BEGRIPTYPE [BRON: EGGINK 1995: 74] ........................................................................30 FIGUUR 3-16: EEN VOORBEELD VAN EEN NIET TOEGESTAAN VOORBEELD TER BEPALING VAN DE URS [BRON: EGGINK 1995: 83]...................................33 FIGUUR 3-17: VOORBEELD VAN EEN IGD MET URS AFGELEID MET BEHULP VAN EEN NIET TOEGESTAAN VOORBEELD [BRON: EGGINK 1995: 84]................34 FIGUUR 3-18: VOORBEELD VAN EEN IGD MET URS AFGELEID MET BEHULP VAN EEN IGD MET EEN SIGNIFICANTE POPULATIE [BRON: EGGINK 1995: 86] ........................................................................35 FIGUUR 3-19: VUISTREGEL OM ALLE MOGELIJKE COMBINATIES VAN ZINNEN TE BEDENKEN [BRON: EGGINK 1995: 88] ......................................................36

101

Hoofdstuk 5

Conclusie

FIGUUR 3-20: EEN VOORBEELD VAN EEN NIET TOEGESTAAN VOORBEELD TER BEPALING VAN DE VRRS [BRON: EGGINK 1995: 92] ................................37 FIGUUR 3-21: VOORBEELD VAN EEN IGD MET VRRS AFGELEID MET BEHULP VAN EEN NIET TOEGESTAAN VOORBEELD [BRON: EGGINK 1995: 93]................38 FIGUUR 3-22: VOORBEELD VAN EEN IGD MET VRRS AFGELEID MET BEHULP VAN EEN IGD MET EEN SIGNIFICANTE POPULATIE [BRON: EGGINK 1995: 94] ........................................................................38 FIGUUR 3-23: EEN VOLLEDIG IGD MET UNICITEITSREGELS, VERPLICHTEROLREGELS EN AFLEIDINGSREGELS [BRON: EGGINK 1995: 95]...................................39 FIGUUR 3-24: FEITTYPEN ALS BEGRIPTYPEN 1 [BRON: EGGINK 1995: 110]...................41 FIGUUR 3-25: FEITTYPEN ALS BEGRIPTYPEN 2 [BRON: EGGINK 1995: 111]...................42 FIGUUR 3-26: DE GROEPEN IN EEN IGD [BRON: EGGINK 1995: 127] ..............................46 FIGUUR 3-27: STAP 1 VAN DE OMZETTING VAN EEN IGD NAAR EEN RELATIONEEL MODEL – GROEPEREN [BRON: EGGINK 1995: 128]....................................47 FIGUUR 3-28: STAP 2 VAN DE OMZETTING VAN EEN IGD NAAR EEN RELATIONEEL MODEL – LEXICALISEREN [BRON: EGGINK 1995: 129]...............................49 FIGUUR 3-29: STAP 3 VAN DE OMZETTING VAN EEN IGD NAAR EEN RELATIONEEL MODEL – OMZETTEN NAAR RELATIONELE NOTATIEWIJZE [BRON: EGGINK 1995: 132] .......................................................................50 FIGUUR 4-1: STRUCTUUR ADRESSENBESTANDEN NEDERCOM EN NIEUW NEDERLANDS .............................................................................................53 FIGUUR 4-2: STRUCTUUR NEDERCOM-ADRESSENBESTAND .............................................54 FIGUUR 4-3: STRUCTUUR NIEUW NEDERLANDS ADRESSENBESTAND ...............................55 FIGUUR 4-4: VOORBEELDDOCUMENT 1 – POSTADRESGEGEVENS 1..................................57 FIGUUR 4-5: VOORBEELDDOCUMENT 2 – POSTADRESGEGEVENS 2..................................57 FIGUUR 4-6: VOORBEELDDOCUMENT 3 – BEZOEKADRESGEGEVENS 1.............................58 FIGUUR 4-7: VOORBEELDDOCUMENT 4 – BEZOEKADRESGEGEVENS 2.............................58 FIGUUR 4-8: VOORBEELDDOCUMENT 5 – EXTRA GEGEVENS/MEMOVELD BEHORENDE BIJ ADRES 1 .................................................................................................59 FIGUUR 4-9: VOORBEELDDOCUMENT 6 – EXTRA GEGEVENS/MEMOVELD BEHORENDE BIJ ADRES 2 .................................................................................................59 FIGUUR 4-10: VOORBEELDDOCUMENT 7 – PERSOONSGEGEVENS 1..................................60 FIGUUR 4-11: VOORBEELDDOCUMENT 8 – PERSOONSGEGEVENS 2..................................60 FIGUUR 4-12: VOORBEELDDOCUMENT 9 – PERSOONSGEGEVENS 3..................................61 FIGUUR 4-13: VOORBEELDDOCUMENT 10 – PERSOONSGEGEVENS 4................................61 FIGUUR 4-14: VOORBEELDDOCUMENT 11 – EXTRA GEGEVENS/MEMOVELD BEH ORENDE BIJ PERSOON 1........................................................................62 FIGUUR 4-15: VOORBEELDDOCUMENT 12 – EXTRA GEGEVENS/MEMOVELD BEHORENDE BIJ PERSOON 2........................................................................62 FIGUUR 4-16: SUBSTITUERING VAN DE INVULPLAATSEN IN DE FEITTYPEFORMULERING (BEHORENDE BIJ HET FEITTYPE FT1) DOOR BEGRIP- EN NAAMTYPEFORMULERINGEN....................................................................69 102

Hoofdstuk 5

Conclusie

FIGUUR 4-17: INFORMATIEGRAMMATICA VOOR KLANTENBESTAND NEDERCOM EDUWARE..................................................................................................73 FIGUUR 4-18: DIAGRAMMISATIE VAN FEITTYPE FT1 ......................................................74 FIGUUR 4-19: DIAGRAMMISATIE VAN BEGRIPTYPEN BEHORENDE BIJ FEITTYPE FT1......74 FIGUUR 4-20: DIAGRAMMISATIE VAN NAAMTYPEN BEHORENDE BIJ FEITTYPE FT1 .......75 FIGUUR 4-21: VERKORTE NOTATIE VAN DE UNAIRE BEGRIPTYPEN BEHORENDE BIJ FEITTYPE FT1............................................................................................75 FIGUUR 4-22: CONTROLE IGD – SUBSTITUERING BEGRIPTYPEN ....................................75 FIGUUR 4-23: CONTROLE IGD – SUBSTITUERING NAAMTYPEN ......................................76 FIGUUR 4-24: CONTROLE IGD – OPSTELLEN VAN HET OORSPRONKELIJKE FEIT ..............76 FIGUUR 4-25: IGD RELATIEBEHEER NEDERCOM EDUWARE ............................................77 FIGUUR 4-26: VOORBEELDEN VAN UNICITEITSREGELS (BIJ BINAIRE ROLLEN)................78 FIGUUR 4-27: HERZIENE IGD NA REDUNDANTIEVERWIJDERING ......................................87 FIGUUR 4-28: GROEPERING VAN BINAIRE FEITTYPEN......................................................88 FIGUUR 4-29: DE GROEPEN IN HET IGD RELATIEBEHEER NEDERCOM .............................89 FIGUUR 4-30: GEGROEPEERD MODEL VAN IGD RELATIEBEHEER NEDERCOM .................92 FIGUUR 4-31: GELEXICALISEERD MODEL VAN IGD RELATIEBEHEER NEDERCOM............95 FIGUUR 4-32: RELATIONELE NOTATIEWIJZE RELATIEBEHEER NEDERCOM .......................98

103

Hoofdstuk 5

Conclusie

Bibliografie

Boonstra, O., Breure, L., Doorn, P.: Historische informatiekunde, Inleiding tot het gebruik van de computer bij historische studies, Verloren, Hilversum, 1992. Brachman, R.J., McGuinness, D.L., Patel-Schneider, P.F., e.a., Living with CLASSIC: When and How to Use a KL-ONE - Like Language, Morgan Kaufmann Publishers, San Mateo, CA, 1991, pp. 401 – 456. Brown, H., Hilton Brown’s Published Articles, van http://www.jedi.apana.org.au/~hiltonb/ARTICLES/SECOND.HTM Eggink, J., Leenstra, E.J., Nijssen, G.M.: Informatie in model, over gegevens, feiten en afspraken, PNA Publishing bv, Beutenaken, 1995. InterAct Bedrijfsautomatisering: AFAS voor Windows Relatiebeheer - Relatiegegevens, 1999, van: http://www.interact.be/Solutions/AFASrel.htm. Koenhen Consult:Waarom relatiebeheer? , van: http://www.koenhen.nl/waarom.html. Lans, R.F., van der: Het SQL Leerboek, Academic Service, Schoonhoven, maart 1996. RapidSugar: E-mailmarketing Crash Course, van: http://www.rapidsugar.nl. Steenis, H., van: Universele Informatiekunde werkt met natuurlijke taal, in: Computable, 10 mei ‘96, nr.19: p.33, van: http://www.computable.nl/artikels/archief6/d19ms6nr.htm. The Woodburn Group 2000, Inc: Customer Relationship Management - What is it?, van: http://www.woodburn.com/matrix/CRMWhatIs.htm. Ultimate Software B.V.: Productinformatie: XAL Relatiebeheer (Sirmis) , van: http://www.ultimatesoftware.nl/relatiebeheer.htm. Walvis Software: WALVIS Relatie Server (WRS), standaardtoepassingen – relatiebeheer, van: http://www.walvis.nl/toepassingen/relatiebeheer/ 4cindex01.htm.

104

De Universele Informatiekunde

Recommend Documents