GEGEVENSMANAGEMENT III béta 42

 

Brilbeer in de dierentuin van Wenen, de enige beer die van nature in Zuid Amerika voorkomt. Leeft vooral in vochtige bossen op de Andes.

GEGEVENSMANAGEMENT DEEL III Beta 43

De Communicatiebehoefte van een Bedrijf/Organisatie

De hele informatie-problematiek van een bedrijf of instelling kun je uitdrukken met drie vragen:

1: Wat voor zakelijke informatie wisselen mensen in en rond het bedrijf met elkaar uit?

Alles wat rond een bedrijf gebeurt is het gevolg van afspraken tussen mensen. Ook als een computer van het bedrijf constateert dat een voorraad onder een bepaalde limiet is gekomen, en een signaal stuurt naar de computer van de leverancier om bij te bestellen, dan is dat het gevolg van een contract tussen beide partijen. Als mechanisme is dit geen uitvinding uit het informatietijdperk, het waterleidingbedrijf doet dit al 175 jaar met een voor dit doel uitstekend signaleringssysteem: de waterleidingdruk.

2: Hoe realiseer je de acties waartoe een bedrijf zich daarbij verplicht.

Het gaat daarbij om welke “zaken van waarde” (geld, goederen, diensten) worden overgedragen aan een partij buiten het bedrijf. En ook het ontvangen van zaken van waarde die de andere partij in het kader van die afspreken levert.

Alle informatie die je daarbij naar derden stuurt valt onder (1). De informatie rond alle activiteiten die je intern voor die overdracht opstart valt ook onder (1). Het overdragen zelf heeft echter een juridisch en financieel aspect, en daarom ligt de grens tussen (1) en (2).

Het maakt in het geheel niet uit  of je bij bepaalde activiteiten computers of andere machines inschakelt. Het inschakelen van een computer is, in laatste instantie, ook het communiceren met een mens.

Indien die machine van iemand anders is, bijvoorbeeld een ATM (Automatic Transaction Machine: flappentap), dan heb je met die andere partij een afspraak hierover gemaakt. Gebruik maken van die machine is een uitvloeisel van die afspraak. De bediening van die machine is ook communicatie: via de ontwerper van het interface, en de verantwoordelijke voor de exploitatie van de ATM.

3: Wat voor middelen gebruik je om (1) en (2) te faciliteren.

De zakelijke informatie-uitwisseling en datgene wat je intern moet communiceren om de acties waartoe je je verplicht te realiseren, en het registreren van de tegenprestatie, vormt de communicatiebehoefte. De communicatiestructuur is het geheel aan middelen dat je gebruikt om de communicatie te faciliteren.

Als je alleen naar de effectiviteit en niet naar de efficiëntie kijkt, dan kun je (1) en (2) realiseren zonder informatiesystemen. Als iedereen naar iedereen brieven stuurt, en voor de acties die je moet realiseren ook pakjes bezorgd worden,  of medewerkers op pad worden gestuurd om  ergens activiteiten te gaan verrichten, dan kun je een effective oplossing voor (1) en (2) hebben. Dan verzorgt de Post de communicatiestructuur.

Een klant schrijft naar het bedrijf wat hij wenst. De directeur geeft deze brief aan de accountmanager die schrijft brieven naar de magazijnmeester en de chef monteur en zo voorts. Ooit deden we het zo, hoewel we natuurlijk vooral veel zaken mondeling regelden.

Terwille van de efficiëntie verzin je iets beters; dit gaat te langzaam en is te duur. Je verzint bijvoorbeeld een aanvraagformulier voor de klant. Dat kan de accountmanager aan de klant sturen, en het ingevulde exemplaar aan magazijnmeester en chef monteur. 

De prijs die je hiervoor betaalt is dat je de communicatie rond (1) en (2) in een keurslijf wringt. Je dwingt de klant de vrije tekst uit een brief om te zetten in rubrieken op een formulier; het worden gestructureerde gegevens.

Daarnaast ga je om tijd te winnen de formulieren niet per post, maar als fax of E-mail versturen. We onderscheiden daarmee twee soorten middelen:

3A: Logische middelen, zoals de onderkende rubrieken op formulieren om de communicatie te structureren, en

3B: Technische middelen: zoals een fax, E-mail. En ook databases, daarmee kun je tijd overbruggen, en ook een historie opbouwen. De rubrieken op de formulieren, worden gerealiseerd als de schermen van on-line transacties op de database.

Als je de communicatie ook nog regelt door databases met elkaar te verbinden; dan lijkt het geheel al veel op een Integraal Systeem zoals Telecom in 1980 voor ogen stond. 

Het onderscheid tussen 3A en 3B is essentieel omdat de logische middelen structuur geven aan hetgeen gecommuniceerd wordt. Terwijl de technische middelen los van de inhoud staan: een fax heeft geen boodschap aan de boodschap. Beide middelen gebruik je ter wille van de efficiëntie. Ze gaan vaak samen, maar hun effect is heel verschillend.

{Collega Chris bij GM had een achtergrond in elektrotechniek. Hij noemde met elkaar verbonden systemen waarbij 3B goed geregeld was, maar 3A niet, ‘galvanisch’ verbonden; dwz met een stroomdraad. Er kunnen wel degelijk bytes tussen beide systemen uitgewisseld worden; maar wat ze er mee kunnen?}

Met het doen structureren van de boodschap open je een venster op de inhoud van die boodschap. Je gaat bij een boodschap bijvoorbeeld onderscheid maken tussen delen waarin respectievelijk afzender, geadresseerde, en de feitelijke mededeling staan. En je zet de geadresseerde op de voorkant van een enveloppe, de afzender in een hoek op de achterzijde, en de mededeling op een vel papier in de enveloppe. Als je die structuurelementen onderkent kun je ze ook toepassen in een taal die je in het geheel niet kent. En je kan een automaat ook leren om afzender, geadresseerde en mededeling te onderscheiden.

De toegevoegde waarde van de structuur voor de betekenis, is voor de menselijke lezer die de gebruikte taal kent gering, en zal hem vaak ontgaan. 

Voor automatische verwerking is de structuur het begin van alles.

De taak van Gegevensmanagement

Gegevensmanagement beoogt structuren te creëren zodat de zender en de ontvanger van een boodschap over iets wat in het bedrijf gaande is, daarin dezelfde betekenis zullen onderkennen.

De behoefte daaraan is klein als zender en ontvanger tegelijkertijd achter dezelfde balie staan;  maar groot als ze op verschillende tijden achter verschillende balies staan.

Dit structureren doen we niet alleen met rubrieken, maar vooral met gestructureerd Nederlands. 

In Gm deel II, staat een beknopte introductie tot die methode. In dit deel III bouw ik daar op voort.

De prijs die je met een communicatiestructuur betaalt vergeleken met een informele informatievoorziening is onherroepelijk een verlies aan flexibiliteit. Vandaar dat we proberen die structuur af te leiden van de doelstellingen van het bedrijf; want die veranderen niet snel en dus hoef je niet vaak te wijzigen.

{In de 45 jaar dat ik Telecom min of meer gevolgd heb; springen er voor mij slechts twee grote veranderingen in de doelstellingen uit:

1. Op een gegeven moment is Telecom ‘content’ gaan leveren. En de nieuwe doelstelling  ‘leveren van content’ wordt ondersteund door de doelstelling ‘leveren van telecommunicatie’ en is daarmee hoger. 
2. Telecom was altijd al een bedrijf, maar onderdeel van de overheid. Er was daarmee steeds een doelstelling “maken van winst”. Vòòr  de verzelfstandiging was dat aspect voor het bedrijf zelf, niet van het hoogste belang. De winst ging naar de staat en die bepaalde hoeveel ruimte er op de rijksbegroting was voor het investeren in Telecom. Daarna is het gewicht van deze doelstelling sterk toegenomen, en dat was ook de bedoeling; Telecom moest zijn investeringen zelf uit de opbrengsten gaan financieren, en tegelijk aan de de behoefte van de markt gaan voldoen. Toen Telecom als onderdeel van KPN, naar de beurs ging werd dat gewicht nog veel groter.

Er is natuurlijk ondertussen heel veel gewijzigd, bijvoorbeeld in de techniek door de opkomst van Internet. Toch zijn er systemen die het heel lang hebben volgehouden.

Ze zullen tot het laatst toe bruikbaar zijn geweest. De systemen zijn vooral vervangen omdat ze technisch verouderd waren, en niemand er meer geld in wilde steken.}

De Modellencyclus voor het maken van een Gegevensmodel

Hoewel de basis van deze methode de verzamelingenleer en de formele logica is, gebeurt de vormgeving ervan met een gestructureerde versie van een natuurlijke taal; Nederlands in ons geval. 

De basis daarvan is gelegd in INFOMOD een taal en methode voor het specificeren van een informatiemodel van Philips. En in NIAM, Nijssens Informatie Analyse Methode van G.M.Nijssen. Hieraan is ook de naam van J.J.V.R Wintraecken verbonden. De betrokkenen bij beide methoden verwijzen naar elkaar. 

Ik maakte kennis met een verder doorontwikkelde methode, die inmiddels de Modellencyclus werd genoemd, en gegeven werd door Wim van der Sanden van het bedrijf Brainforce, een onderdeel van Volmac. Die verdere ontwikkeling was vooral gedaan door Van der Sanden, en J.J.van Griethuysen. 

Op een gegeven moment is een groot deel van de bemensing van Brainforce, weggegaan bij Volmac, en een eigen bedrijf begonnen onder de naam Panfox. Zij gaven cursussen in Informatiearchitectuur, en in dat kader ook wel in gegevensmanagement.

Het grote voordeel van het gebruik van gestructureerd Nederlands is, dat het laagdrempelig is, terwijl je door zorgvuldig te structureren, en het maken van figuren, de dubbelzinnigheid die in natuurlijke talen mogelijk is, kunt vermijden. 

Ik heb ook wel in internationaal verband gegevensmodellen in het Engels gemaakt, dat gaat natuurlijk net zo goed als in het Nederlands; wel hadden we er altijd en native speaker, bij nodig. Ook al spreek je als IT-er, redelijk Engels; in het kiezen van de juiste woorden in een definitie kies je af en toe een verkeerde term dat tot een onbegrijpelijk resultaat kan leiden.

Wat ik hieronder beschrijf is een versie van de Modellencyclus, die in het gebruik binnen Telecom weer verder ontwikkeld is.

Om het een en ander toe te lichten een globaal plaatje als introductie tot die methode. Daarna volgt een uitgewerkt, maar versimpeld, voorbeeld.

Gegevens worden gezien als een neerslag van feiten. 

In de buitenste ring staan de FEITEN. Die buitenste ring symboliseert wat ik in het voorafgaande het Universe Of Discourse heb genoemd. Dat is de professionele discussie tussen betrokkenen, gestuurd door gemeenschappelijke doelstellingen, over dat onderwerp. De feiten zijn de neerslag van die discussie. 

          

1. LINKS BOVEN  staat het Objectmodel waarmee  geregistreerd wordt waarover de feiten gaan.
2. RECHTS BOVEN in het Semantisch-model wordt vastgelegd wat we over die feiten willen weten
3. RECHTS ONDER: het Logisch datamodel legt vast hoe we datgene wat we over die feiten willen weten gaan registeren.
4. LINKS ONDER: het Fysieke datamodel legt dat wat we gaan registreren vast in een database notatie, hierbij kunnen om implementatie redenen nog bepaalde gegevens worden toegevoegd.

Bij gegevensmanagement houden we ons vooral bezig met de eerste twee aspecten. Het Logisch datamodel ontstaat in het project in samenwerking met de systeemontwerper en een database-specialist van de automatiseringsafdeling. Het  fysieke datamodel is het terrein van de database-specialisten.

Essentieel is dat het steeds over een type gaat. Bijvoorbeeld bij het maken van het objectmodel nemen we feiten over objecten waar. Vervolgens onderkennen we, gestuurd door de doelstellingen, typen. En we registreren de objecttypen! De stap van object naar objecttype gebeurt ‘vanzelf’ doordat de taal ons daartoe dwingt; we hebben geen woord voor “dat beestje met veren daar”, maar we hebben het over die vogel. Ook in de andere modellen hebben we het steeds over typen, of over een exemplaar van een type. (Voor exemplaren van een type, wordt wel de term ‘token’ gebruikt).

Voorbeeld: versimpeld Gegevensmodel van een Bibliotheek

Het primaire doel van een bibliotheek is het uitlenen van boeken. Het primaire doel van de registratie is het registreren daarvan. Het reserveren van boeken, en het inschrijven van nieuwe boeken en klanten zijn subdoelen. 

Er lopen in zo een typisch registratieve situatie eigenlijk twee processen parellel: Het primaire bedrijfsproces, het uitlenen van boeken aan klanten, en als afspiegeling daarvan een secundair registratief proces het maken van aantekeningen over dat uitlenen.

Beide processen lopen nagenoeg synchroon omdat er anders informatie over het primaire proces verloren gaat die geregistreerd had moeten worden.

In termen van “waarnemingen”, vinden in het registratieve proces waarnemingen plaats van het primaire proces; de bibliothecaris neemt daarin ook zijn eigen handelingen en beslissingen waar. 

In het domein vinden we:

• Als concrete zaken: KLANTEN, BOEKEN en AUTEURS.
• Als gebeurtenissen: UITLENING en RESERVERING. {eigenlijk zijn er nog twee voor het beëindigen van beiden}
• Er is één concept: omdat er van een boek meerdere exemplaren kunnen zijn hebben we naast BOEK ook SOORT-BOEK nodig.

Het Objectmodel

• KLANT: Een PERSOON die gerechtigd is bij de bibliotheek BOEKEN te lenen.          
• BOEK: Een aantal pagina’s op papier die , al dan niet in een band zijn samengevoegd en waarop een geschrift over enig onderwerp is vastgelegd. (opmerking: hier is duidelijk het boek in fysieke zin bedoeld. Dit zijn de objecten die je uitleent. Vaak voorzien van een automatisch leesbare identificerende code, om efficient uit te kunnen lenen)
• SOORT-BOEK: Een verzameling BOEKEN, die omdat ze allen dezelfde inhoud hebben, voor de KLANT bij het uitlenen verwisselbaar zijn. 
• AUTEUR: Een NATUURLIJK-PERSOON die één of meerdere SOORT-BOEKen  geschreven heeft.
• UITLENING: Een tijdelijke overdracht van een BOEK aan een KLANT
• RESERVERING: De kennisgeving van een KLANT dat hij zo spoedig mogelijk een UITLENING wil van een exemplaar van een SOORT-BOEK.
• NATUURLIJK-PERSOON: een mens
• NIET-NATUURLIJK-PERSOON: een rechtspersoon of een samenwerkingsverband dat zich als zelfstandige organisatie manifesteert.
• PERSOON: Een generalisatie van een natuurlijk- en een niet-natuurlijk-persoon. 

Voor het tekenen van het objectmodel maken we gebruik van Venn-diagrammen. Dit is een tekentechniek om verzamelingen en de relaties daartussen voor te stellen in het platte vlak.

Een verzameling wordt voorgesteld door een gesloten kromme in dat vlak, gewoonlijk een cirkel. De punten binnen de cirkel staan voor de elementen van de verzameling, de punten erbuiten behoren niet tot de verzameling. Overlappende verzamelingen worden voorgesteld door cirkels met een overlap.

Tekening objectmodel bibliotheek

Wij hebben het over objecttypen, dat zijn verzamelingen van objecten, en we kunnen die dus goed voorstellen met Venn-diagrammen. Wij gebruiken daarvoor afgeronde rechthoeken. 

Zie in het model PERSOON. Er wordt wat ruimte vrijgehouden voor de naam, maar in principe vullen de natuurlijk en de niet-natuurlijke-persoon de hele verzameling. 

In PERSOON zie je nog drie liggende afgeronde vierkanten: voor uitgeverij, klant en auteur. Dit zijn drie objecttypen die we in dit verband rollen noemen. 

Of een persoon natuurlijk of niet-natuurlijk is wordt bepaald door zijn aard, en is onveranderbaar. Een rol zit niet in de aard; het is een hoedanigheid die de persoon soms manifesteert.

Een Reservering is een samenstelling van drie objecttypen: de reservering zelf, soort-boek en klant. We noemen dit wel een aggregatie.

Een uitlening is ook een aggregatie. De gestippelde pijl van soort-boek naar boek, geeft aan dat boek een element is van soort-boek. 

Het Semantisch-model

Hierin wordt vastgelegd wat we over de objecten uit het objectmodel willen weten. Dat kan alleen maar als je de objecten individueel kent.  Dergelijke geïdentificeerde objecten hebben daarmee de status van entiteit verkregen. Of praktisch gesproken; ze komen in de database. 

Omdat het in de modellencyclus bijna altijd over typen gaat; hebben we het dus over entiteittypen.  

Dit lijken precies dezelfde zaken als de objecttypen; althans ze hebben dezelfde naam en definitie, waarom is er een verschil tussen het objecttype het gelijknamige entiteittype BOEK? Het antwoord luidt: er zijn héél erg veel meer objecten BOEK dan entiteiten BOEK; een entiteit is een object dat onderdeel is van de onderhavige registratie.

Semantisch-model van de biblotheek

Hier onder staat een opsomming van entiteittypen met hun beweringtypen. Door substitutie van entiteiten voor hun type in een beweringtype ontstaan beweringen.

De accolades rond {AUTEUR} bij SOORT-BOEK geven aan dat één soort-boek meerdere auteurs kan hebben.

KLANT:

• KLANT wordt aangeduid met klantnaam PERSOONSNAAM
• KLANT is geboren op datum DATUM
• KLANT is geregistreerd onder KLANTNUMMER
• KLANT woont op ADRES

BOEK

• BOEK wordt geïdentificeerd met code BOEK-CODE
• BOEK is exemplaar van SOORT-BOEK

SOORT-BOEK

• SOORT-BOEK wordt geïdentificeerd met nummer ISBN-NUMMER
• SOORT-BOEK is geschreven door {AUTEUR}
• SOORT-BOEK wordt aangeduid met TITEL

UITLENING

• UITLENING is gedaan aan KLANT
• UITLENING betreft boek BOEK
• UITLENING is gedaan op datum DATUM

RESERVERING

• RESERVERING is gemaakt voor KLANT
• RESERVERING betreft soort-boek SOORT-BOEK
• RESERVERING is gemaakt op datum DATUM

Tekening semantisch model bibliotheek

In de tekening worden entiteittypen voorgesteld door een ellips met hun naam erin. De entiteittypen zijn verbonden met een gebogen lijn als er een beweringtype is die ze verbindt.

De secundaire entiteittypen zijn als eindpunt duidelijk te onderscheiden. 

{Een secundaire entiteit is een waarde, en een secundair eniteittype is een lijstje met waarden. Bijvoorbeeld entiteittype KLEUR met waarden: rood, groen, blauw, …. . Maar ook het ISBN-nummer is een secundair entiteittype waarvan de waarden, de nummers, getallen van 13 cijfers zijn.}

AUTEUR is in dit domein secundair, maar je zou AUTEUR makkelijk tot primair kunnen verheffen. 

Je creëert daartoe twee beweringtypen voor AUTEUR.  

AUTEUR wordt aangeduid met auteursnaam PERSOONSNAAM

AUTEUR heeft geschreven {SOORT-BOEK} 

Met de behandeling van het objectmodel en het semantisch model hebben we het aspect ‘betekenis’ van wat we willen registreren van de feiten vast gelegd. Als het goed is heb je personeel van de opdrachtgever bij het ontwikkelen van deze modellen erbij betrokken en hebben zij, en hun bazen, er mee ingestemd. 

In het Logisch Datamodel gaan we vastleggen hoe we gegevenstypen  vorm gaan geven zodat de toekomstige gegevens betekenisvol vastgelegd en gepresenteerd kunnen worden. 

Logisch datamodel 

In het objectmodel hebben we de objecttypen gedefinieerd waarover de feiten gaan. In het semantisch model hebben we vastgelegd wat we over de feiten willen weten.  Daarmee is hebben we een structuur waarmee de betekenis van de toekomstige data van de database kan worden vastgelegd.

Bij de start van het ontwikkelen van het Logisch Datamodel (LDM), wordt de status van het project serieuzer; en wordt de rol van de automatiseerders groter. Het LDM gaat de view worden die zij op de database krijgen.De zoekpaden door de gegevens zijn voor hen van belang omdat ze nodig zijn voor de transacties die ze moeten gaan ontwikkelen. 

De rol van personeel van de opdrachtgever betrokken bij het project verschuift van materie-deskundigen naar dat van potentiële gebruikers. Blijf ze erbij betrekken. Leg uit wat je aan het doen bent en waarom. 

In het logisch datamodel wordt bepaald hoe we gaan registreren:

{Even abstract: de essentie van het relationele model voor databases, is het registreren van entiteiten in een tabel}

Ieder primair entiteittype P wordt een tabel, met zijn entiteiten als

regels in die tabel. Terwijl ieder secundaire entiteittype S dat in een beweringtype van de vorm P predikaat S voorkomt, een kolom van die tabel van P wordt.{secundaire entiteittypen zijn een verzameling van waarden, en hun entiteiten zijn die waarden}

Zo een kolom van P wordt in het LDM een attribuut-type genoemd. Denk boven de kolom de naam S eventueel met een toevoeging die past bij de rol in het beweringtype. Dit is de naam van het attribuut(type).

Als deze attibuutnaam in het onderstaande onderstreept is, dan is het een sleutel. Dat wil zeggen met de waarde; het attribuut, kan je de entiteit (de regel van de tabel waar het atribuut in staat) selecteren.

Voorbeeld voor KLANT 

de kop van zijn tabel:

klantnummer ; klantnaam; geboortedatum; adres. 

De geboortedatum is optioneel; de klant kan immers ook een niet-natuurlijk persoon zijn. Klantnummer is de sleutel van KLANT en daarom onderstreept. 

De hoofdstructuur van het LDM: een tekening

{Deze tekening is een communicatiemiddel. De tabellen zijn het middel waarmee dit gerealiseerd gaat worden}

De hoofdstructuur van het LDM wordt gevormd door de primaire entiteittypen. Dat zijn dus tabellen, maar in de tekening van de hoofdstructuur voorgesteld als vierkanten met van de naam van het primaire entiteittype erin; daarmee zijn de secundaire entiteittypen in de tekening niet zichtbaar want onderdeel van een vierkant geworden.

De primaire entiteittypen, vierkanten, zijn met elkaar verbonden met relaties afgeleid uit beweringtypen  van het semantisch model die ze met elkaar verbindt. Dit wordt voorgesteld door een rechte lijn, met tbv de layout, soms een rechte hoek erin. Aan beide zijden van een relatie staat een symbool voor de cardinaliteit van de relatie, zie linksonder in de tekening.

Voor iedere relatie die aan de zijde van het een vierkant een ‘harkje’ heeft; hetgeen wil zeggen dat dit vierkant meerdere keren in de relatie voor kan komen; krijgt de betreffende tabel een extra kolom bestemd voor sleutels van de andere kant van die relatie.

De relatie tussen KLANT en RESERVERING staat voor de reserveringen die een klant heeft uitstaan. Hij mag er meerdere doen, maar hoeft er geen gedaan te hebben. Maar een reservering hoort altijd bij één klant. 

In de tabel RESERVERING wordt dit gerealiseerd door een extra kolom waarin de sleutel van de klant, het klantnummer staat. Bij een klant kunnen zijn reserveringen worden opgezocht door in die kolom van RESERVERINGEN op zijn klantnummer te zoeken. 

Bij één RESERVERING hoort precies één soort-boek. Dat vereist een kolom in de tabel reservering met de isbn-nummers (sleutels) van de gereserveerde soort-boeken. Andersom hoeft een soort-boek niet gereserveerd te zijn.

Dit geeft de volgende kop boven de kolommen van de tabel van RESERVERING.

klantnummer ; isbn-nummer ; datum gereserveerd

Klantnummer en isbn-nummer vormen samen de sleutel van reservering.

Volgens onze methode begin je een opstart van het Logisch Datamodel door in de tekening van het Semantisch Model aan beide zijden van een boog voor een beweringtype dezelfde informatie te geven in de vorm  (0-1), (1-1), (0-n) of (1-n); waarin ‘n’ staat voor onbeperkt. 

Een UITLENING lijkt wel een beetje op een reservering; hij wordt op een bepaalde datum gedaan aan één klant; en betreft één boek. Een klant kan meerdere uitleningen hebben lopen, maar hoeft er geen te hebben. Een boek kan echter maar eenmaal uitgeleend zijn; of natuurlijk gewoon in de kast staan.

De kop van de tabel van UITLENING wordt:

boek-code ; klantnummer ; datum uitgeleend .

Een BOEK is altijd van één SOORT-BOEK. Dat vereist dus een extra kolom met isbn-nummers bij BOEK. Bij een (populair) SOORT-BOEK behoren vaak vele BOEKen, maar er kan een nieuw gepubliceerd SOORT-BOEK zijn waar de bibliotheek nog geen exemplaren van heeft.

Kop van de tabel van BOEK

boek-code ; isbn-nummer ; 

Het entiteittype AUTEUR is toch primair gemaakt. 

Wanneer je het aantal auteurs tot 1 beperkt `dan kan AUTEUR een secundair entiteittype zijn, en als een kolom bij SOORT-BOEK opgenomen. Maar meerdere auteurs bij één boek is natuurlijk geen zeldzaamheid. De bibliothecaris heeft op dit punt een aanpassing van het semantisch model geëist.  {onder de tekening van het semantisch model staat dit al uitgewerkt}.

Dat betekent daar o.a. toevoegen van het beweringtype “AUTEUR heeft geschreven {SOORT-BOEK}”.

Daarmee is er een meer op meer relatie tussen AUTEUR en SOORT-BOEK noodzakelijk. Dergelijke relaties worden gerealiseerd met wat in het spraakgebruik een relatie-entiteit wordt genoemd. Dat gedraagt zich als een primair entiteittype met twee (extra) kolommen: in dit geval één met het isbn-nummer van SOORT-BOEK en een met auteursnaam. En die tabel krijgt één regel voor iedere combinatie van een soort-boek en een auteur die (ook) aan het soort-boek geschreven heeft. Via deze tabel kan je van ieder SOORT-BOEK bij zijn auteurs komen, en van iedere AUTEUR bij zijn soort-boeken.

Kop boven SOORT-BOEK/AUTEUR

isbn-nummer ; auteursnaam.

{deze twee zijn samen de sleutel van soort-boek/auteur}

{Net als AUTEUR/SOORT-BOEK is ook RESERVERING een soort relatie-entiteit met behalve de primaire sleutel klantnummer+isbn-nummer ook een kolom voor de reserverings-datum.}

verbonden

Het entiteittype SOORT-BOEK heeft twee kolommen:

isbn-nummer ; titel.

{Ik denk dat het handig is om ook een kolom voor kastnummer op te nemen voor de locatie in de bibliotheek waar boeken van deze soort te vinden zijn}

Het entiteittype AUTEUR heeft een kolom, die meteen zijn sleutel is

auteursnaam .

{Een tabel wordt geschikt voor een relationele database geacht als deze aan de volgende voorwaarden voldoet:

Alle kolommen die geen sleutel zijn, zijn onafhankelijk van elkaar; maar zijn wel allen afhankelijk van de (volledige) sleutel.

In de literatuur heet dit dat de tabel in de derde Normaalvorm is.

Het doel is het vermijden van redundantie in de database; terwille van eenmalige invoer en vermijden van inconsistentie.

Uit de tekening van het LDM blijken er twee paden van SOORT-BOEK naar KLANT te lopen. Via de uitlening en via de reservering. Dat zou ook op redundantie kunnen wijzen. Dat is niet het geval want je komt langs beide wegen niet bij dezelfde klant uit.}

Het volgende model is het Fysieke Datamodel. Dat is het werk van de datebase-specialisten. Het LDM is input voor hen.

Het Fysieke Datamodel

In het Logisch Datamodel is vastgelegd hoe we de gegevens over de feiten die voor ons doel relevant zijn gaan registreren. In het Fysiek Datamodel wordt bepaald waarmee dat gebeurt.

Daarvoor hebben we twee belangrijke tools:

1) De Structured Query Language (SQL)

Dit is een universeel gangbare taal om databases mee te bevragen; maar je kan er ook databases mee bouwen.

2) Een Relationeel DataBase Management Systeem (RDBMS) dat geschikt is voor het platform waarop je de database wil installeren.

Eerst wordt het LDM "vertaald" in SQL. En worden er allerlei technisch of implementatie-gegevens toegevoegd: over gebruikers en hun bevoegdheden, over het netwerk en printers, gegevens over recovery door het DBMS, ... .

Er is een doorlopend onderzoek naar de te verwachten systeembelasting; want dat soort informatie is ook al nodig om te bepalen op wat voor systeem de database en de bijbehorende processen gaan draaien. 

Maar dit onderzoek wordt specifieker naarmate de implementatie dichterbij komt.

Met name van de meest kritische zoekpaden is van belang te weten hoe vaak ze gebuikt gaan worden. En van de grootste tabellen is de groeisnelheid van belang, evenals de te verwachten maximale grootte.

Een methode om de zoeksnelheid van het operationele systeem te verbeteren is het maken van een index van de sleutel van entiteiten die problemen geven en een slimme zoekstrategie te gebruiken op die sleutel.

Een uiterste middel is het denormaliseren van een entiteit. Als - onwaarschijnlijk - voorbeeld op het model van de Bibliotheek het volgende:

 Stel dat de bibliothecaris er een probleem mee heeft dat er veel oude reserveringen zijn omdat er geen boeken van een gereserveerde soort terugkomen. En hij wil de namen van de klanten die een boek van die soort te leen hebben, zodat hij ze kan vragen om het boek terug te brengen. 

Nu duurt het pad van reservering, naar soort-boek, naar boek, naar uitlening, naar klant, naar klantnaam hem te lang. Dan zou de volgende denormalisatie helpen: neem in het fysieke datamodel in uitlening de klantnaam redundant op en maak van boek en uitlening één tabel boekplus (ze hebben al dezelfde sleutel). Een complicatie is dat je na teruggave het uitlening-deel en  de klantnaam in boekplus moet leegmaken. 

De kwaliteit van gegevens

In mijn ervaring bij KPN was gegevensvervuiling een plaag voor de gebruikers van de automatisering. 

Het soms ondergeschikte belang van correct registreren

Stel dat de de Directeur van de bibliotheek verordonneert, dat een klant in totaal maximaal  7  boeken te leen mag hebben.

Dit zou gerealiseerd kunnen worden door de programmatuur rond het maken van een nieuwe uitlevering een foutmelding te laten geven bij nummer acht. 

Nu komt Koningin Máxima op een dag langs en vraagt om twee boeken voor een lezing over microkredieten die ze binnenkort wil geven. Bij het uitlenen blijkt echter dat Maxima van Oranje al zes boeken heeft. 

Dat wordt natuurlijk heel klantvriendelijk opgelost. Zij wordt door de bibliothecaris nogmaals ingeschreven als Maxima Zorreguieta en krijgt onder die naam de twee boeken.

Wat is het gevolg hervan? Iedereen is blij: de Koningin is blij met haar zes boeken, de bibliothecaris is trots op zijn verleende service aan deze voorname klant, en de directeur is blij omdat hij op zijn rapportage ziet dat het aantal prominente klanten verder is gestegen, en dat zijn opdracht tot het beperken van de uitleningen tot maximaal 7 per klant strikt wordt gevolgd. 

Alleen de gegevensmanager zal ontevreden zijn, wanneer hij ontdekt dat de kwaliteit van de klantgegevens verder is afgenomen.

Enkele opmerkingen:

• Beperkingen op een gegevensmodel die niet volgen uit de essentie van entiteiten, beweringen en doelstellingen maar om bedrijfsmatige redenen opgelegd worden kunnen gaan wringen.
• De kwaliteit van gegevens is bij transacties vaak het minste belang dat speelt. 
• Je kan een beperking zoals hier ook anders realiseren. Dan  geef je bij iedere uitlening boven de zeven programmatisch een waarschuwing aan de baliemedewerker dat de transactie niet toegestaan is, en dat hij daarvoor ter verantwoording kan worden geroepen. Dan kan deze in schrijnende gevallen een uitzondering maken.
• Je moet altijd proberen het proces voor de baliemedewerker zo in te richten dat het makkelijker is om het goed te doen, dan fout.  {Bij het invoeren van klanten in de CentraleKlantenRegistratie van KPN, moest je eerst zoeken of de klant al bekend was. Als dat niet het geval was, moest je deze als nieuwe klant invoeren. Bij een wachtrij voor de balie was daarom meteen invoeren als nieuwe klant aantrekkelijk; bij CKR was 20% van de nieuwe klanten een doublure}
• Je moet ernaar streven een situatie te bereiken dat een gemaakte fout terug kan worden gevoerd naar de baliemedewerker; hij moet er een belang bij hebben om het goed te doen.

Een stimuleringsbudget Kwaliteitsborging van Gegevens 

In de de periode 1992-'93 zijn er bij KPN twee grote conversies geweest: bij de invoering van de Regio's, en bij het invoeren van de bovengenoemde CKR. Vooral de laatste was niet bepaald vlekkeloos.

In het jaarplan voor de IT werd de kwaliteit van gegevens als probleem genoemd; als Hoofd GM werd mij gevraagd "er iets aan te doen". Tezamen me collega GerardF heb ik toen een projectvoorstel met de bovenstaande naam bedacht. We vroegen een budget van 10 miljoen gulden en het plan was om met dat budget de regio's te verleiden een degelijk onderzoek naar de kwaliteit van hun gegevens te doen, bij problemen de oorzaken op te sporen en te analyseren, en waar nodig processen aan te passen om de kwaliteit te borgen.

Kort voor 1992 was er bij KPN Total Quality Management geïntroduceerd, en daarmee hadden we de tools om dit te doen.

GerardF en ik schreven samen aan project-werkorder. Het werd overgenomen door ons management en we kregen de opdracht, en het budget.

GerardF werd projectleider. En is daar in het jaar 1993 mee bezig geweest; het budget is besteed en de kwaliteit is geborgd.

Het project werd niet verlengd in 1994. Mij is verteld dat de afdeling Control niet gecharmeerd was van dergelijke stimuleringsbudgetten; en dat dit behoorde tot de normale taak van een Regio.

Dat was natuurlijk jammer; want het probleem was nog lang niet opgelost. Maar we hadden wel ervaring met deze aanpak opgebouwd en beschreven, en die is later nog vaker toegepast.

De Klantidentificatie bij Telecom 
Een beetje chargerend kan je zeggen dat toen in 1971 bij KPN-Telecom de eerste brochure over een Telefonie Cliënten Informatie Systeem verscheen, de klantidentificatie een goede oplossing had - het telefoonnummer - waarbij een probleem werd gezocht:  

Er worden vijf belangrijke operationele bestanden genoemd: het orderbestand, het bestand dat de telefonisten gebruiken bij het beantwoorden van nummer 008 voor het opvragen van telefoonnummers, het bestand voor de verspreiding van telefoongidsen, en het technisch overzicht van het aansluitnet. 

Met ITCIS: Integraal Telecom Cliënten Informatie Systeem, was het probleem gevonden inclusief een ambitieuze oplossingsrichting. Bij een nieuwe aansluiting waren er namelijk meerdere bestanden die gemuteerd moesten worden. Men wilde met een computer bereiken dat met eenmalige invoer kon worden volstaan.

Na een twee jaar onderzoek en besluitvorming startte de ontwikkeling van ITCIS  met Incasso. Ondertussen was al lang duidelijk dat het telefoonnummer voor de Consumentenmarkt wel een goede klantidentificatie was; maar niet voor de Zakelijke Markt. Er hoorde bij het complexe onderwerp Incasso daarom een deelsysteem KlantenRegistratie KRS.  

Toen bleek ook Incasso een te groot onderwerp, en werd ITCIS teruggebracht tot Incasso voor de Zakelijke Markt; want dat was een echt probleem voor Telecom. Ook met die ingreep zou ITCIS flink vertragen.  

Daarmee was het geloof, in ITCIS in het bedrijf en vooral bij I&AT, de automatiseringsafdeling, verdwenen.  (ITCIS had de aansluiting met de snel opkomende relationele databases gemist)

Als onderdeel van ITCIS viel KRS onder de verantwoordelijkheid van de Incassoafdelingen; en dat was een goede zaak. Want die hadden als financiële instellingen een duidelijk belang bij een goede registratie. KRS bevatte alle NAW-gegevens van klanten.

Omdat inmiddels duidelijk was dat ITCIS de rol van het klantregistratie-systeem van Telecom niet zou krijgen; werd er buiten de ITCIS-omgeving,  de ontwikkeling van een Centrale KlantRegistratie (CKR) systeem gestart. 

CKR heeft het volgende simpele model.

Een Rechtssubject is een natuurlijk of niet-natuurlijk persoon die zelfstandig drager van rechten en plichten is. 

Vestiging bevat het ckr-nummer dat is het klantnummer. Bij niet-natuurlijke personen heeft het een naam, vaak omschrijving van bedrijf en afdeling. En eventueel een nummer van de kamer van koophandel.

Een verwijzing bevat een code voor het gekoppelde systeem. Dossiernummer, een code voor de rol, een het CKR-nummer.

De erkende rollen zijn contractant en gebruiker. Er zijn ook wel kantrollen die specifiek voor het gekoppelde systeem zijn.

Slecht Informatiebeleid 

{ Ik wil hier een casus beschrijven rond het tot stand komen, en implementeren van CKR. Ik ben er echter niet zeker van dat mijn "feiten" kloppen. Daarom poneer ik hier en nu een 'feitenrelaas' preciezer, met namen en zo, opgeschreven dan ik dat overwegen te publiceren. Dit in de hoop dat de proeflezers mij corrigeren op onjuistheden. Bij mijn twijfelfeiten plaats ik een "?"} 

Klantregistratie in ITCIS (KRS) 

Bij de opzet van ITCIS was KRS bedoeld om de Telecom-brede rol te vervullen die ITCIS later gekregen heeft. Maar niet als referentie-database met een klantnummer; maar als algemene klantendatabase. Dit was zelfs een belangrijk argument om met ITCIS te beginnen want Telecom had immers met de DB-008 alle klantgegevens al.

ITCIS had natuurlijk nooit kunnen functioneren zonder iets als CKR. Maar mijns inziens waren de Incasso-afdelingen wel een goede plaats voor de klantgegevens; ze hadden een groot belang bij de juistheid ervan. 

Ik denk dat de kwaliteit van de klantgegevens voor Incasso niet verbeterd, maar verslechterd zijn door CKR.