Databanken Marc De Caluwé,

Transcriptie

1 Databanken Marc De Caluwé, Inhoudsopgave 1. INLEIDING GEGEVENS DATABASES DATABASES GEBRUIKEN: SQL GEGEVENSMODELLEN EEN VOORBEELD SAMENVATTING DATABASES ONTWERPEN GEGEVENSMODELLERING EN INFORMATIEANALYSE GEGEVENSMODELLERING BINNEN EEN PROJECT DE TAAL VAN GEGEVENSMODELLERING Probleemafbakening: de Universe of Discourse Object, kenmerk en domein Type en individu Feit Gegevensdefinitie en gegeven Gegeven en gegevensdrager Besluit: naamgeving is essentieel INFORMATIEANALYSE Vier vragen Beginnen HOE BEGINNEN? Beginnen met feiten Beginnen met teksten Beginnen met formulieren, lijsten of bestanden OPGAVEN SAMENVATTING TOP-DOWN ONTWERPEN ENTITY RELATIONSHIP DIAGRAM Soorten relaties Levenscyclus EEN ERD GAAT ENKEL OVER GEGEVENS ERD VOOR DISCUSSIE EN DOCUMENTATIE ATTRIBUTEN CASE TOOLS BETEKENISRELATIES IN EEN GEGEVENSMODEL Specialisatie en generalisatie Aggregatie of compositie Associatie ROLLEN VAN ENTITEITTYPEN BINNEN EEN MODEL TIJD IN EEN ERD ZELF EEN ERD TEKENEN OPGAVEN BOTTOM-UP ONTWERPEN FUNCTIONELE AFHANKELIJKHEID ROL VAN ATTRIBUTEN...36 Databanken 1

2 4.3. SLEUTELS Identificerende sleutel Kandidaatsleutel Vreemde sleutel Code of naam Sleutels en semantiek REDUNDANTIE INTEGRITEIT VAN GEGEVENS VAN ERD NAAR TABEL Eén op één relaties mappen Eén op één/nul relaties mappen Eén/nul op één/nul relaties mappen Eén op veel relaties mappen Veel op veel relaties mappen Parallelle relaties mappen Recursieve relaties mappen Specialisaties mappen NORMALISEREN Nulde normaalvorm (0NV) Eerste normaalvorm (1NV) Tweede normaalvorm (2NV) Derde normaalvorm (3NV) Boyce-Codd normaalvorm (BCNV) Terug naar het ERD model DENORMALISATIE OPGAVEN RELATIONELE DATABASES EN HUN EIGENSCHAPPEN VERZAMELINGEN RELATIES EN TUPLES RELATIONELE BEWERKINGEN RELATIONELE BEWERKINGEN IN SQL Unie, intersectie en verschil Selectie en projectie Product en join Andere bewerkingen VERDERE EISEN VOOR EEN DBMS Performance Transacties Transacties en geldigheidsregels Gelijktijdigheid Beveiliging Recovery DE DATA-DICTIONARY Metagegevens Metadata in uitgebreidere zin Metadefinitie en datamanipulatie OPGAVEN STRUCTURED QUERY LANGUAGE VRAAGTAAL DE MEEST EENVOUDIGE SELECT SYNTAX GEGEVENS UIT EEN TABEL: FILTERS Eenvoudige vergelijkingsoperatoren Meer geavanceerde operatoren Logische operatoren...69 Databanken 2

3 DISTINCT IN CONTAINING SORTEREN, RANGSCHIKKEN VAN GEGEVENS AGGREGAATSFUNCTIES EN GROEPERING De aggregaatsfuncties De GROUP BY clausule De HAVING clausule GEGEVENS UIT MEERDERE TABELLEN Traditionele JOIN Moderne JOIN OUTER JOIN FULL OUTER JOIN Aliassen Self joins VIEWS SUBQUERIES EN VERZAMELBEWERKINGEN ANY en ALL IN en NOT IN voor subqueries EXISTS Verzamelbewerkingen: UNION OPGAVEN SQL MANIPULATIETAAL HET INSERT COMMANDO INSERT rij per rij INSERT vanuit een query INSERT en automatische velden INSERT en defaults INSERT en triggers HET UPDATE COMMANDO De SET clausule Waardes switchen tussen twee velden UPDATE en triggers HET DELETE COMMANDO INSERT, UPDATE EN DELETE MET VIEWS OPGAVEN SQL DEFINITIETAAL HET CREATE COMMANDO Een tabel creëren Datatypes Additionele tabelinformatie Ander gebruik van CREATE HET ALTER COMMANDO Een tabel wijzigen Wanneer ALTER niet volstaat Ander gebruik van ALTER HET DROP COMMANDO OPGAVEN...97 REFERENTIES...98 Databanken 3

4 1. INLEIDING 1.1. GEGEVENS Een database heet in het Nederlands databank of gegevensbank: men slaat er blijkbaar gegevens in op. Wat zijn gegevens? Meestal wordt een onderscheid gemaakt tussen gegevens, kennis en informatie. Zonder bijkomende commentaar stelt de getallenreeks 12, 14, 15 enkel een verzameling gegevens voor. Indien we er aan toevoegen dat het hier gaat om de gemiddelde temperatuur van de maanden februari, maart en april, dan stelt deze reeks een hoeveelheid informatie voor. Of iets ja dan neen informatie wordt hangt dus ook af van de toehoorder. Voor iemand die geen enkel idee heeft wat het woord temperatuur betekent, is de geciteerde getallenreeks nog steeds geen informatie. Kennis is een bundeling van informatie in een bepaalde samenhang. In het dagelijkse taalgebruik worden de woorden gegevens en informatie in de praktijk nogal eens als synoniemen gebruikt. We leven tegenwoordig in een informatiemaatschappij. Deze term wijst erop dat mensen steeds meer met informatie werken in plaats van met hun handen. Een tweede betekenis is dat allerlei gegevens gemakkelijk en overvloedig beschikbaar zijn. Het probleem is: weten waar je moet zoeken. Documentatie en ontsluiting van kennis zijn daarmee van groot belang geworden. En het is dus ook erg belangrijk geworden om databases te kunnen ontwerpen, bouwen en gebruiken. Alle gegevens komen ergens vandaan. Ze worden in het leven geroepen door mensen of instanties die er belang bij hebben die gegevens te bezitten of te verhandelen. Gegevens ontstaan, bestaan en vergaan. Ze kennen een levenscyclus. Om te beginnen moet iemand op het idee komen iets als een gegeven te beschouwen. Vervolgens worden gegevens in de een of andere vorm onthouden. De gegevens dienen daartoe geformaliseerd te worden: worden ze opgeslagen als figuur, als tekst, als veld in een databank,...? Elk van deze weergave vormen heeft voor- en nadelen. Deze keuze hangt dan ook af van de vraag voor wie en met welk doel deze gegevens toegankelijk moeten zijn. Eenmaal geformaliseerd worden gegevens voor kortere of langere tijd bewaard. Hoe lang zal afhangen van het type gegevens. Worden gegevens voor langere tijd bewaard, dan verouderen ze, ze verliezen aan nauwkeurigheid. Gegevens bewaren die verouderd zijn kost tijd en geld: het is daarom van belang om bij het aanmaken van gegevens al te bepalen hoe lang ze moeten meegaan en wat er moet gedaan worden tegen het verouderen. Elk gegeven dat in een computer wordt opgeslagen kent een zogeheten datatype. Dat betekent dat het gegeven slechts waarden kan aannemen uit een bepaalde verzameling waarden, het domein genoemd. Klassieke datatypes voor databanken zijn rijen karakters, getallen, datum, geld, blob (binary large object). Nieuwere types zijn beeld, geluid, video. Het datatype documenteert de gegevens en geeft de mogelijkheid ze op kwaliteit te controleren. Zo zal een datum-type enkel en alleen een geldige datum aanvaarden als invoer. Naast datatype worden de gegevens in een database ook gedocumenteerd met een naam voor elk gegeven. Dit soort gegevens-over-de-gegevens worden metagegevens Databanken 4

5 genoemd. De metagegevens vormen samen de data-dictionary DATABASES Een database is in algemene zin een verzameling gegevens die bij elkaar horen. In engere zin wordt hieraan als voorwaarden toegevoegd dat de gegevens elektronisch dienen te zijn opgeslagen en dat ze als een geheel benaderd en beheerd moeten kunnen worden. De softwareproducten om databases mee te bouwen heten database-pakketten. De kern van een database-pakket is het database-management-systeem, afgekort DBMS. Daarnaast bevat zo'n pakket nog allerlei hulpprogramma's om het leven van de gebruikers te veraangenamen. Gelijksoortige gegevens worden in de database in één tabel gestopt. Een element uit zo'n tabel noemen we een record of rij. Indien de tabel bijvoorbeeld adressen bevat noemen we één adres van de tabel een record. Het gebruik van een database kan vergeleken worden met een verzameling kaartenbakken, maar uiteraard met veel flexibeler mogelijkheden van ontsluiting. Het is gemakkelijk gegevens te transporteren, een deel van de gegevens uit de database te lichten, en ze af te drukken of af te beelden. Een opdracht om gegevens uit een database op te vragen noemt men een query (verzoek). Een belangrijk voordeel van databanken is dat vele gebruikers tegelijk de gegevens in een database kunnen benaderen. De taak van een databank is een brug te slaan tussen drie dingen: de mensen die met de gegevens willen werken, de gegevens in hun correcte samenhang, en de computergeheugens waarop die gegevens zijn opgeslagen. In de architectuur van een database-pakket zijn deze drie niveaus terug te vinden: het gebruikersniveau omvat de hulpmiddelen die de toegang van de gebruikers tot de gegevens regelen. Het conceptueel niveau is de data-dictionary die onder meer het gegevensmodel bevat. Het derde niveau wordt fysiek niveau genoemd. Het omvat hulpmiddelen om de gegevens op te slaan in één of meer computergeheugens en om te zorgen dat ze snel te benaderen blijven. Bij een goed database-management-systeem zijn deze drie niveaus onafhankelijk van elkaar. Men noemt dit gegevensonafhankelijkheid en het betekent het volgende. Een database heeft altijd één enkel gegevensmodel. Is dit onafhankelijk van het gebruikersniveau, dan kunnen verschillende gebruikers een verschillend gedeelte van de database benaderen. Dat is vaak van belang als bijvoorbeeld een deel van de gegevens vertrouwelijk van aard is. Ook tussen gegevensmodel en opslagmedia is onafhankelijkheid gewenst. Die maakt het mogelijk dat gegevens uit een gegevensmodel verspreid worden opgeslagen in een willekeurig aantal computers. De database kan worden gedistribueerd over verschillende computers. Om databases te bouwen heeft men software nodig die te koop is onder de algemene naam database-pakket. De kern van zo'n pakket is het database-management-systeem. Er bestaan vele honderden database-pakketten. Vele daarvan zijn gespecialiseerd voor bepaalde soorten toepassingen, of draaien alleen op computers van een bepaalde leverancier. Enkele tientallen pakketten zijn voor allerlei toepassingen te gebruiken en draaien op veel van de meest gangbare computers. Op deze laatste pakketten gaan we hier iets verder in. Deze pakketten verschillen in vele opzichten maar ze hebben wel één iets gezamenlijk: het zijn allemaal relationele database-pakketten. Kort gezegd komt dat hierop neer dat de gegevens de vorm hebben van gekoppelde tabellen. De tabellen zitten zo in elkaar dat elke rij de gegevens van één ding bevat, en elke kolom gegevens van Databanken 5

6 eenzelfde type. Grofweg vallen er pakketten in drie maten te onderscheiden: De kleine pakketten, vaak kaartenbak-pakket genoemd, bedoeld voor slechts één gebruiker en doorgaans voor slechts één type gegevens (één of enkele tabellen). Bijvoorbeeld een adressenbestand. Voorbeelden: PC-file, Cardbox, Cardfile,... De middencategorie: pakketten die doorgaans klein begonnen zijn maar uitbreidingen hebben gekregen voor gebruik in netwerken en voor het koppelen van tabellen. Het database-management-systeem is vaak niet erg krachtig, de data-dictionary beperkt. Ze zijn goed om eenvoudige databases mee te bouwen, zonder dat veel voorkennis nodig is. Voorbeelden: Microsoft Access, Paradox, dbase,... De zwaardere pakketten die voor tientallen tot honderden gebruikers tegelijk geschikt zijn. Deze kennen meestal uitgebreide mogelijkheden. Hun data-dictionary kan op dezelfde manier worden benaderd als de gewone gegevens. Voor leken zijn deze pakketten vaak niet dadelijk te gebruiken en ze stellen dikwijls hogere eisen aan de hardware. Voorbeelden: Oracle, Informix, Sybase, Interbase/Firebird, mysql,... De pakketten uit de middencategorie worden vaak gebruikt om eenpersoons-databases te bouwen. Ze zijn als zodanig nauwelijks te vergelijken met de zwaardere databases omdat juist het gelijktijdig toegang bieden tot de gegevens aan vele gebruikers een database tot een belangrijke meerwaarde maakt voor een organisatie. Er zijn twee groepen mensen betrokken bij de bouw van een database: degenen die de database zullen gebruiken en degenen die hem bouwen. Dit zijn meestal niet dezelfde mensen, zeker niet bij grote databases in het bedrijfsleven. In een onderzoekssituatie kan het zijn dat een onderzoeker zijn eigen database ontwerpt en bouwt. Ook voor eenpersoons-databases op een PC geldt dit. Als een database eenmaal bestaat komen er andere rollen bij. Bij grote databases zijn er personen die speciaal belast zijn met het in werking houden van de database. Om specifiek de data-dictionary te bewaken, zodat de kwaliteit van de gegevens op niveau blijft, kan er een gegevensbeheerder zijn. Is de functie meer gericht op de opslagstructuren en het draaiend houden van de software, dan spreekt men van een database-administrator. Gezien vanuit een organisatie die met een database werkt, zijn er een aantal kwaliteitseisen te formuleren voor zo'n database. We moeten daarbij bedenken dat een database in een organisatie een deel is van een groter geheel. Om zo'n database heen draaien toepassingsprogramma's, bvb voor gegevensinvoer, en er zijn regels voor de omgang: welke personeelsleden moeten zorgen voor het toevoegen van gegevens, welke voor het uitdraaien van overzichten ten behoeve van klanten, en zo meer. Vanuit het perspectief van de gebruikers kunnen we volgende eisen onderkennen: Betrouwbaar: de gegevens moeten juist zijn, en up-to-date. Volledig: het moet niet nodig zijn om, behalve in de database, ook nog op andere plaatsen naar een gegeven te zoeken. Efficiënt: een gebruiker moet niet onnodig behoeven te wachten. Begrijpelijk: de gegevens moeten voldoen aan vooraf bepaalde eisen voor begrijpelijkheid. Voor bepaalde specialistische doeleinden kan het zijn dat gebruikers scholing nodig hebben, maar in het algemeen zullen ze zonder scholing in hun eigen taal met de gegevens en met de applicaties om moeten kunnen gaan. Vanuit het perspectief van ontwerpers en bouwers kunnen we volgende eisen onderkennen: Testbaar: dit punt geldt met name voor applicaties op een database. Ze moeten goed te debuggen zijn, ofwel moeten er hulpmiddelen zijn om de software te ontdoen van fouten. Databanken 6

7 Aanpasbaar: er kunnen altijd wijzigingen in gegevensstructuren en applicaties nodig zijn. Het mag niet onnodig moeilijk zijn deze wijzigingen aan te brengen. Vanuit het perspectief van de organisatie als geheel tenslotte: Apparatuur-onafhankelijk: organisaties kopen nieuwe computers, of reorganiseren zichzelf met de regelmaat van de klok. Databases moeten daartegen bestand zijn. Het database-management-systeem moet op allerlei hardware en onder allerlei besturingssystemen kunnen draaien. Organisatie-onafhankelijk: wanneer er fusies of samenwerkingsverbanden ontstaan worden dikwijls gegevens gedeeld tussen de betrokken organisaties. Het is dan handig wanneer gegevensdefinities overeenstemmen. In veel bedrijfstakken heeft men dan ook zogeheten referentie-informatiemodellen opgesteld. Deze modellen zijn standaardgegevensmodellen voor de desbetreffende bedrijfstak en kunnen door elke organisatie worden gebruikt als basis voor de gegevensmodellen achter hun eigen databases. Merk op dat de drie soorten eisen niet op hetzelfde moment gelden: voor een gebruiker moet de database vandaag goed werken, voor een ontwerper, bouwer of beheerder moet hij morgen nog goed werken, en voor de organisatie moet hij gedurende een aantal jaren goed werken DATABASES GEBRUIKEN: SQL U heeft inmiddels een idee van wat een database is en wat men ermee kan doen. Maar hoe geeft men nu opdrachten aan een database? Hoe voert een gebruiker gegevens in, hoe vraagt hij ze op, hoe onderhoudt een administrator de gegevensstructuur? Er bestaan daarvoor verschillende mogelijkheden. Vooral de eenvoudiger pakketten werken daarvoor dikwijls met keuzemenu's die een gebruiker zonder noemenswaardige voorkennis kan bedienen. Ook zijn er soms opdrachttalen die bij een bepaald pakket horen. Er is echter één taal die in vrijwel alle databasepakketten kan worden gebruikt en die we de wereldstandaard voor databasetalen kunnen noemen: SQL. SQL staat voor Structured Query Language. In het volgende hoofdstuk gaan we in op de belangrijkste SQL mogelijkheden. SQL is een gestandaardiseerde taal, maar elk pakket heeft zijn eigen dialect. Meestal ondersteunen deze dialecten de belangrijkste SQL standaardmogelijkheden, en bieden ze daarnaast een aantal specifieke mogelijkheden voor het desbetreffende pakket. Om u alvast een idee te geven van hoe SQL eruitziet, enkele voorbeelden: Om de tabel PERSOON met de velden NAAM en aan te maken in een database gebruiken we iets als: CREATE TABLE PERSOON (NAAM CHARACTER(30), CHARACTER(100)); Om in deze tabel één nieuw gegeven in te voeren gebruiken we iets als: INSERT INTO PERSOON (NAAM, ) VALUES ('Marc De Caluwé', 'marcdecaluwe@gmail.com'); Om de gegevens op te vragen die in de tabel PERSOON zitten: SELECT * FROM PERSOON; 1.4. GEGEVENSMODELLEN We hebben het tot nu toe gehad over gegevens, databases en SQL. Op één belangrijke vraag zijn we echter nog niet ingegaan: hoe komt men van een probleemsituatie tot een werkende database? Databanken 7

8 Een database van enige omvang is in de praktijk altijd een onderdeel van een groter geheel, dat men dikwijls informatiesysteem noemt. Hieronder worden niet alleen de software en de gegevensverzamelingen verstaan, maar ook de benodigde hardware, de mensen die met de database moeten werken en de procedures volgens dewelke die mensen werken. Het ontwikkelen van zo'n informatiesysteem gebeurt doorgaans in het kader van een project. Aan zo'n project werken twee groepen mensen samen: degenen die de software maken (ontwerpers of bouwers) en de gebruikers. Enkele activiteiten zijn in zo'n project altijd te herkennen: Start van het project. Allereerst wordt afgesproken wie deel uitmaakt van het projectteam en hoeveel tijd en geld ermee gemoeid zijn. Het projectteam bakent dan het probleem af in een projectplan, zodat men weet wat wel en niet onder het project valt. Analyse van het probleem door ontwerpers en gebruikers. Het resultaat is een serie modellen van bijvoorbeeld relevante gegevens en processen, en van de context van het probleem. Deze modellen vullen elkaar aan en vormen samen een 'kenmodel' van het probleem. Men weet nu hoe het probleem in elkaar zit. Het ontwerp van elk onderdeel van de software. Het resultaat is een serie ontwerpen, bijvoorbeeld datamodel, mens/computer-dialogen en algoritmen. Algoritmen leggen de besturingsstructuur vast, bijvoorbeeld van rekenprocessen. Dialogen leggen de mogelijkheden voor gebruikers vast. Bij een database is vooral de gegevensmodellering van belang, die het gegevensmodel of datamodel oplevert. Samengevat levert de ontwerpfase een 'maakmodel' op van de te bouwen software. Dat is te vergelijken met de maquette van een gebouw: toekomstige gebruikers kunnen aan het ontwerp zien hoe de software er uit komt te zien, en als de gebruikers het anders willen, kunnen de ontwerpen deze wensen nog verwerken in het ontwerp. De bouw van elk onderdeel van de software. Resultaat is: werkende databases en/of programmatuur. Komen er nu nog ontwerpfouten aan het licht, dan wordt wijzigen duur en tijdrovend. Afhankelijk van de gevolgde methode zullen deze activiteiten als stappen te herkennen zijn of samengevoegd worden. De laatste drie activiteiten kunnen ook een aantal malen cyclisch doorlopen worden. Documenten die uit analyse en ontwerp komen, worden gedurende het project gebruikt voor communicatie tussen de betrokkenen en als basis voor de bouw. Een gegevensmodel legt de hoofdstructuur van de gegevens vast: welke tabellen komen er en welke kolommen hebben ze? En hoe staan ze in verband met elkaar? Eenmaal een database gebouwd is en er blijkt dat er in de hoofdstructuur belangrijke fouten zitten, dan kost het gauw erg veel geld om deze nog recht te zetten. Een gegevensmodel doet twee dingen tegelijkertijd: beschrijven en begrenzen. Het is te vergelijken met een geheugen dat alleen bepaalde vooraf gedefinieerde typen kan onthouden. Net als bij elk ander geheugen, zoals dat van een mens, geldt: wat het gegevensmodel niet kan bevatten kan het ook niet onthouden. Het is dan ook belangrijk bij het ontwerp om na te gaan wat kan bestaan, niet wat zou moeten bestaan. Indien men volgens het laatste ontwerpt zou al gauw blijken dat het model niet in staat zal zijn de realiteit te bevatten EEN VOORBEELD We bekijken het voorbeeld van een headhunterbureau: het bemiddelt tussen Databanken 8

9 hooggekwalificeerde werkzoekenden en organisaties op zoek naar personeel. De werking ervan is als volgt: het bureau contracteert een aantal headhunters, ieder bekend binnen een bepaald circuit, die discreet in de gaten houden welke mensen er eventueel wel van job zouden willen veranderen. Organisaties met vacatures bellen het bureau, waarna dat de geschikte headhunters aan het werk zet. Wanneer personen gevonden worden brengt het bureau beide partijen met elkaar in contact. Het bureau krijgt hiervoor een vergoeding van de organisatie. Bij de start van het bedrijf is er niets geautomatiseerd. Het bureau houdt een lijst bij van headhunters en welke bedrijven binnen het circuit van de headhunter vallen. Deze lijst bevat naam en telefoonnummer van de headhunter plus voor elk bedrijf de naam, de branche en de jaaromzet. Elk bedrijf wordt door slechts één headhunter opgevolgd. Na enige tijd blijkt dat telefoonnummers nogal eens wijzigen, dat de bedrijven gevolgd door een headhunter ook nogal eens wijzigen, en dat bedrijven zelf soms verhuizen of fuseren. Een database dringt zich op. Een medewerker van het bureau maakt de volgende tabel aan: Naam Hans Koppens Lieve Desitter Louis Dewaele Telefoonnr Org1 Verre Reizen Devos Dankers Biocontruct Branche1 toerisme voeding bouw Omzet Org2 Fly away Graankorrel - Branche2 toerisme voeding - Omzet Org3 - Tafel dek je - Branche3 - voeding - Omzet Al tijdens de invoer van de tabel blijken er enkele bezwaren: vele headhunters volgen slechts één of twee organisaties, waardoor er veel witruimte in het bestand blijft. Na enige tijd komt echter een groter tekort aan het licht: een headhunter neemt er een vierde organisatie bij, maar de tabel voldoet daar niet voor. Bovendien groeit de tabel snel en wil men na enige tijd een overzicht van alle organisaties waarvoor het bureau over een headhunter beschikt. Het blijkt dat het erg moeilijk is dit te bekomen. Het bovenstaande bestand wordt vervangen door het volgende: Organisatie Branche Omzet Headhunter Telefoonnr Verre Reizen toerisme 300 Hans Koppens Devos Dankers voeding 1780 Lieve Desitter Bioconstruct bouw 460 Louis Dewaele Fly away toerisme 740 Hans Koppens Graankorrel voeding 540 Lieve Desitter Tafel dek je voeding 760 Lieve Desitter Met dit bestand zijn de gemelde problemen opgelost. Headhunters kunnen nu zoveel Databanken 9

10 organisaties volgen als ze willen, er is geen witruimte meer, en het is gemakkelijk een overzicht te krijgen van de organisaties waarmee gewerkt wordt. Na enige tijd blijkt echter dat ook dit bestand een aantal problemen kent: Headhuntergegevens worden op verschillende plaatsen bewaard. Dat heeft als belangrijk nadeel dat wanneer het telefoonnummer van een headhunter verandert, dat moet gewijzigd worden op verschillende plaatsen. Fouten zijn op deze manier praktisch onvermijdelijk. Wanneer een headhunter een bijkomende organisatie opvolgt, moeten zijn gegevens opnieuw ingevoerd worden. Het blijkt moeilijker een overzicht te krijgen van alle headhunters waarmee gewerkt wordt. Indien men headhunters wil opslaan die tijdelijk geen enkele organisatie volgen, moet men een lege organisatie invoeren, wat niet erg elegant is. De medewerker die dit tweede voorstel heeft gedaan, wordt geconfronteerd met deze tekortkomingen. Hij komt tot het besef dat er eigenlijk twee soorten gegevens zijn, die best afzonderlijke worden opgeslagen: headhunters en organisaties. Als dan bij elke organisatie wordt aangeduid door welke headhunter ze wordt gevolgd, zijn alle gemelde problemen opgelost. Hij komt tot het volgende voorstel: Headhunter Naam Telefoonnr 1 Hans Koppens Lieve Desitter Louis Dewaele Organisatie Branche Omzet Headhunter Verre Reizen toerisme Devos Dankers voeding Bioconstruct bouw Fly away toerisme Graankorrel voeding Tafel dek je voeding Na verloop van tijd blijkt dat deze structuur inderdaad alle problemen oplost. We zagen dat het niet goed is meermaals hetzelfde gegeven op te slaan. Dat wordt in deze structuur vermeden. Om daartoe te komen werd een extra veld ingevoerd: elke headhunter kreeg een nummer dat enkel en alleen wordt gebruikt als unieke verwijzing naar die headhunter. Er is geen enkele nood om deze verwijzing ooit te moeten wijzigen. De gegevens zelf van die headhunter, die wellicht wel gewijzigd dienen te worden, worden slecht éénmaal opgeslagen. Opgave: Wat gebeurt er indien het bureau van strategie verandert en toelaat dat een bedrijf door meer dan één headhunter wordt opgevolgd? Voldoen de tabellen nog steeds? Waarom wel of waarom niet? Indien niet, hoe kunnen we ze aanpassen dat ze terug voldoen? Databanken 10

11 1.6. SAMENVATTING We hebben kennis gemaakt met databases. Hoofdzaken daarbij waren: Een database is een verzameling met elkaar samenhangende, al of niet ware beweringen, opgeslagen op een computer en te benaderen via daartoe bestemde software. Er kunnen vele gebruikers tegelijk met dezelfde database werken. De software, het database-management-systeem, vertaalt tussen de gegevens en wat mensen met die gegevens willen doen enerzijds, en tussen gegevens en hoe ze in de computer zijn opgeslagen anderzijds. Daardoor kunnen verschillende gebruikers tot verschillende delen van de database toegang hebben, en kan de database over verschillende computers worden opgeslagen. Alle gegevens in een database kunnen met elkaar in verband gebracht worden. Er is een data-dictionary, een soort geautomatiseerd naslagwerk met een overzicht over alle gebruikers, gegevens en geheugens. We hebben ook nog gezien dat het ontwerpen en bouwen van een database een kwestie is van projectmatig groepswerk, en dat het ontwerpen van een gegevensmodel daarbij een centrale plaats inneemt. Voor het gebruiken en beheren van een database is SQL de wereldstandaardtaal DATABASES ONTWERPEN We gaan in de volgende hoofdstukken dieper in op het concreet ontwerpen van een database. In hoofdstuk 2 zien we hoe we de gegevensmodellering uitvoeren. Om hiertoe in staat te zijn is het nodig om een aantal begrippen nauwkeurig te hanteren. Vaak worden er termen voor gebruikt die in het dagelijks leven of in andere vakgebieden een andere betekenis dragen. We beginnen dan ook met uitleg over de taal van gegevensmodellering. Daarna volgt de theorie van de middelste twee stappen: analyse en ontwerp. We behandelen daaronder twee ontwerpstijlen: beginnend bij de grote lijnen (top-down) in hoofdstuk 3 of beginnend bij de details (bottom-up) in hoofdstuk 4. In hoofdstuk 5 gaan we dieper in op het begrip relationele database, en wat het verondersteld wordt te kunnen. De laatste drie hoofdstukken zijn gewijd aan het gebruik van SQL. Databanken 11

12 2. GEGEVENSMODELLERING EN INFORMATIEANALYSE We gaan in dit hoofdstuk dieper in op gegevensmodellering. Om hiertoe in staat te zijn is het nodig om een aantal begrippen nauwkeurig te hanteren. Vaak worden er termen voor gebruikt die in het dagelijks leven of in andere vakgebieden een andere betekenis dragen. We beginnen dan ook met uitleg over de taal van gegevensmodellering GEGEVENSMODELLERING BINNEN EEN PROJECT Zoals we reeds besproken hebben wordt een informatiseringsproject gestart met de probleemafbakening, daarna de analyse, dan het ontwerp en tenslotte de bouw. Zowel in de analyse- als in de ontwerpfase kunnen gegevensmodellen gemaakt worden. In een project van beperkte omvang, bijvoorbeeld wanneer iemand voor zichzelf een database opzet, zal men die twee fasen niet scheiden en in dat geval is er dan ook slechts één enkel gegevensmodel. Is er sprake van een `bestaande situatie' of zijn er bij het projecrt veel mensen betrokken, dan zullen er vaak een aantal gegevensmodellen na elkaar worden gemaakt. De eerste daarvan zijn dan meer bedoeld om de informatiebehoeften in kaart te brengen, de laatste om het uiteindelijke ontwerp weer te geven. Er zijn veel verschillende manieren om een informatiseringsproject in te richten. Men noemt ze wel System Development Methodologies (systeemontwikkelmethoden). Eén ervan is bijvoorbeeld SDM, waarvoor er inmiddels twee opvolgers zijn: IAD en LAD voor het evolutionair dan wel lineair ontwikkelen van informatiesystemen. IAD staat voor Iterative Application Development en LAD voor Linear Application Development. Over beide methodieken is een toegankelijk boek in het Nederlands voorhanden (zie Tolido, 1996 en Fokkinga et al. 1996). Wat ook de gekozen methode is, in alle gevallen is het zo dat meer aandacht voor het gegevensmodel in een vroeg stadium van de analyse, zichzelf steeds terugverdient in de loop van het project. Een zorgvuldig opgestelde, robuuste gegevensstructuur is een cruciale factor in de meeste systeemontwikkeltrajecten. Zelfs al gaat het over een kleiner persoonlijk project waarvoor geen veelzijdige systeemontwikkelmethode wordt gevolgd, dan nog blijft het gegevensmodelleren van erg groot belang DE TAAL VAN GEGEVENSMODELLERING Probleemafbakening: de Universe of Discourse Een project begint met de afbakening van het probleem. In plaats van het woord 'probleem' wordt hier vaak het begrip Universe of Discourse gebruikt. Het Universe of Discourse is datgene waarvan men afspreekt dat het binnen de afbakening van het probleem valt. Het is dus het onderwerp waarvoor een informatiesysteem gebouwd wordt. Het middel om een Universe of Discourse af te bakenen is overleg, vandaar de naam. In eerste instantie zijn gesprekken of vergaderingen nodig om vast te stellen wat voor project er ongeveer moet worden gestart, en wie de kosten op zich neemt. Vervolgens zullen workshops met de betrokken personen (ontwikkelaars, toekomstige gebruikers, hun bazen, specialisten in relevante vakgebieden) worden gehouden om de veranderingsbehoeften, informatiebehoeften en daarmee de gewenste afbakening nauwkeuriger te bepalen. Het resultaat van dit alles vormt een schriftelijke definitie van Databanken 12

13 eisen. De term Universe of Discourse legt er de nadruk op dat alle betrokkenen het eens dienen te worden over welke dingen er binnen het project vallen. Het Universe of Discourse is de basis voor de gegevensmodellering. Als een gegevensmodel een adequate afbeelding van het Universe of Discourse vormt, kan dit gegevensmodel ook vragen over dit Universe of Discourse correct beantwoorden die tijdens de ontwerpfase nog niet aan de orde waren. Voorts is een databaseontwerp in principe in allerlei typen software en op allerlei computers te bouwen. De investering in een goed doordacht gegevensmodel verdient zichzelf dus terug Object, kenmerk en domein Er zijn vele manieren om de werkelijkheid uit het Universe of Discourse te modelleren. Bij de meeste werkwijzen beschrijft men de waargenomen werkelijkheid als een verzameling dingen, objecten genoemd, waarover men iets wil vastleggen. Elk object heeft een aantal kenmerken: de gegevens die men over het object wil weten. Elk object behoort to een objectsoort of objecttype. De objectsoort is te definiëren door de kenmerken van de objecten van die soort op te schrijven. Objecten van die soort hebben voor elk van die kenmerken een waarde. In het voorbeeld van hoofdtsuk 1 zijn headhunter en organisatie twee objectsoorten. Headhunternaam en telefoonnummer zijn kenmerken van objectsoort headhunter; naam, branche en omzet zijn kenmerken van de objectsoort organisatie. 'Hans Koppens' is één waarde van het kenmerk headhunternaam. Om als object te worden weerhouden moet aan twee voorwaarden worden voldaan: Elke representatie van het object kan op een of andere manier uniek geidentificeerd worden. Er moet dus steeds een verschil kunnen gemaakt worden tussen de afzonderlijke representaties van het objecttype. Bijvoorbeeld bij het object headhunter doordat ze elk een uniek nummer hebben. Elke representatie van het objecttype speelt een belangrijke rol in het door ons te ontwerpen systeem. Het systeem kan zijn werk niet doen als de representaties van het objecttype niet geraadpleegd kunnen worden. In veel systemen zijn de objecttypen de voorstelling van materiële zaken in de reële wereld (headhunter, klant, factuur,...). Een object kan echter ook niet-stoffelijke zaken betreffen (planning, tijdschema,...). Bovendien kan dezelfde materiële werkelijkheid in het systeem als verschillende objecten te voorschijn komen. Zo kan dezelfde persoon bijvoorbeeld zowel werknemer zijn van een organisatie als klant van die organisatie. Deze structurering van de werkelijkheid in objecten en kenmerken keert terug in gegevensmodellen en in de opslagstructuur van gegevens. In het voorbeeld van hoofdstuk 1 bijvoorbeeld zouden we de objectsoorten in de database terugvinden als tabellen en de kenmerken van deze objectsoorten als kolomhoofden. De objecten zijn te vinden als rijen in de tabellen. In zo'n rij staat voor elk object voor elk kenmerk een waarde. Om een zo groot mogelijke duidelijkheid na te streven verdient het aanbeveling om bij de naamgeving van de tabellen en kolomhoofden zoveel mogelijk unieke namen te gebruiken. Zo zou het in het voorbeeld van hoofdstuk 1 wellicht beter geweest zijn om in de tabel headhunter de kolomnaam headhunternaam te gebruiken ipv kortweg naam. Een domein is de verzameling waarden die een kenmerk kan aannemen. Het kenmerk telefoonnummer bijvoorbeeld is gedefiniëerd op het domein {telefoonnummers}, dat dan alle mogelijke telefoonummers bevat. In de regel is het een goede gewoonte om kenmerken van verschillende objecten die op eenzelfde domein gedefiniëerd zijn, dezelfde naam te geven. In het voorbeeld van hoofdstuk 1 deden we dat bijvoorbeeld met Databanken 13

14 het unieke nummer dat we aan elke headhunter gaven. We gaven het daar de naam 'headhunter' maar hadden het wellicht beter een naam gegeven als 'ID' om verwarring met de tabelnaam 'headhunter' te vermijden. In dat geval ging het over een kenmerk dat de koppeling verzekert tussen de twee tabellen, en dringt eenzelfde naam zich ook vanuit dat oogpunt op. Maar ook voor kenmerken die niet aan elkaar gelinkt zijn maar wel op eenzelfde domein gedefiniëerd zijn verdient het aanbeveling eenzelfde naam, of minstens een naam met dezelfde stam te gebruiken Type en individu In de omgangstaal wordt zelden onderscheid gemaakt tussen type en individu. Bij gegevensmodellering is dat onderscheid echter wezenlijk. Bijvoorbeeld: een boom is een ding, de oude eik ook. Gaan we nauwkeuriger kijken, dan zien we dat de oude eik slechts één van de elementen is van de verzameling bomen, anders gezegd: een individu van type boom. In een gegevensbestand is een verzameling van elementen terug te vinden als een bestand van records. In een bestand van alle monumentale bomen in een gemeente zou één van die records 'de oude eik' kunnen betreffen. Exemplaar Soort Ligging Kaartcoördinaten de parkboom rode beuk stadspark E23 de huilbom treurwilg gracht D26 de oude eik zomereik stadspark E24 de nieuwe eik zomereik gemeentehuis A40 Bovenstaande tabel zouden we de naam 'boom' kunnen geven. Een ander bestand met dezelfde naam is ook denkbaar: Genus Species Nl-naam Max-hoogte Quercus robur zomereik 20 Fagus sylvatica beuk 25 Castanea sativa tamme kastanje 12 Bij nader toezien zouden we de tweede tabel echter beter de naam 'boomsoort' geven ipv 'boom'. De rijen in die tabel zijn immers geen individuele bomen maar boomsoorten. De moraal is dat een term zoals 'boom', die zowel een verzameling typen als een verzameling individuen kan aanduiden, geen goede naam is om in een gegevensmodel te gebruiken als naam voor een objecttype. Het is dus steeds van belang goed na te denken over de naamgeving om verwarring of misleiding zoveel mogelijk te vermijden. In onderstaande tabel worden de verschillende namen die in de verschillende stadia van een informatiseringsproject worden gebruikt nog eens samengevat. Universe of Discourse gegevensmodel Relationele meta-model database opslagstructuur object entiteittype relatie tabel bestand element entiteit tuple rij record kenmerk attribuut attribuut kolom veld waarde attribuutwaarde attribuutwaarde veldwaarde inhoud Databanken 14

15 Feit Een feit is de eenheid van gegevens in een gegevensmodel. De attribuutwaarden die uiteindelijk in een database worden opgeslagen, dienen om feiten over het Universe of Discourse vast te leggen. Een feit is, in deze betekenis, eigenlijk een bewering over het Universe of Discourse. Er zijn in een gegevensmodel verschillende soorten feiten. Gaan we terug naar ons voorbeeld van hoofdstuk 1 dan kunnen we daarover onder andere de volgende beweringen doen: 'Hans Koppens is een headhunter. Deze bewering duidt erop dat er een individu van type 'headhunter' bestaat. 'Hans Koppens heeft telefoonnummer '. Deze bewering kent aan een al bestaand individu van type 'headhunter' een waarde toe voor een van de kenmerken. 'Hans Koppens volgt Verre Reizen'. Deze bewering legt een verband tussen een individu van type 'headhunter' en een individu van type 'organisatie' Gegevensdefinitie en gegeven Nog een onderscheid dat van groot belang is bij het werken met gegevensmodellen is dat tussen de beschrijving van de gegevens in termen van objecttypen, kenmerken en dergelijke aan de ene kant, tegenover de waarden van de gegevens aan de andere kant. Korter geformuleerd: tussen gegevensdefinitie en gegevens. Laten we even teugkeren naar het voorbeeld van de monumentale bomen in een gemeente. 'Boom' was hier de naam van het bestand, dus een gegevensdefinitie. Maar 'boom' zou ook een veldwaarde kunnen zijn, dus een gegeven. Als we bijvoorbeeld in een plantkundig onderzoek een verzameling groeivormen definiëren, zou 'boom' een van de groeivormen kunnen zijn. In de computer zou men dan een bestand 'groeivorm' kunnen aantreffen, waarin één van de records de groeivorm 'boom' beschrijft. 'Boom' doet dan dienst als waarde van het kenmerk 'naam-groeivorm'. naam-groeivorm hoogte levensduur eenjarig kruid 0-3 m 1 jr overblijvend kruid 0-3 m 2-4 jr heester 0-3 m > 10 jr boom > 3 m > 10 jr Gegeven en gegevensdrager De verschijningsvorm van een gegeven, anders gezegd de gegevensdrager, kan bijvoorbeeld papier zijn, maar ook een diskette of een CD-ROM. Een gegeven dat altijd in een bepaalde verschijningsvorm optreedt, wordt nog wel eens met die verschijningsvorm vereenzelvigd of zelfs verward. Men zegt bijvoorbeeld: `Ik heb een bon gekregen' terwijl het niet om die bon gaat, maar om de gegevens: een overtreding en een bijbehorende boete. Misschien verdwijnen papieren bonnen ooit, maar overtredingen en boetes daarvoor zullen blijven. In een gegevensmodel gaat het om de betekenis van de gegevens, niet om de verschijningsvorm. Of ze op papier, diskette of een webpagina staan is dus niet van Databanken 15

16 belang. Zo is, om op het bomenvoorbeeld terug te komen, 'boom' een heel ander type object dan 'bomenlijst'. Een bomenlijst is immers niet meer dan een stapel papier. Het gebeurt maar heel zelden dat men een gegevensmodel van bomenlijsten, of - in het algemeen - van gegevensdragers, nodig heeft Besluit: naamgeving is essentieel Wat vooral belangrijk is om te onthouden is hoe wezenlijk een goede naamgeving van de objecten en kenmerken in een gegevensmodel is. Slechte namen duiden vaak op een onvolledig begrip van het Universe of Discourse bij de ontwerper en leiden bij andere projectleden tot misverstanden. Enkele tips bij het geven van namen zijn: Wees consequent in het hanteren van afkortingssystemen. Afkorten is tegenwoordig vaak niet meer nodig. Doe het alleen wanneer het nodig is. Baseer de naam van een attribuut op het domein van dat attribuut, tenzij dit zou leiden tot dubbele namen binnen een entiteittype. Ook dan nog is het goed om namen met dezelde stam te gebruiken. Stel dat we bijvoorbeeld een domein 'telefoonnummer' hebben. We willen bij het entiteittype 'persoon' een thuisnummer en een mobiel nummer opslaan. We kunnen dan de attribuutnamen 'thuistelefoonnummer' en 'mobieltelefoonnummer' gebruiken. Gebruik geen dubbelzinnige namen, zoals 'boom' wanneer 'boomsoort' wordt bedoeld. Het leidt bijna zeker tot verwarring bij een aantal van de projectleden. Gebruik telbare begrippen (bijvoorbeeld niet `flora' maar `plantensoort') voor de namen van entiteittypen. Geef entiteittypen niet dezelfde naam als hun attributen. Verwar de gegevensdrager niet met het gegeven zelf. Kies namen die de toekomstige gebruikers begrijpen. Ga dit met hen na. Dit punt, dat wel eens strijdig kan zijn met de andere punten, is het allerbelangrijkste INFORMATIEANALYSE Informatieanalyse en ontwerp worden soms gescheiden, soms verweven. Wat het beste is hangt van een groot aantal zaken af, waaronder de aard van het project en de gewoonten van de ontwerper. Hoe het ook zij, eerst moet de ontwerper in kaart brengen wat er allemaal aan gegevens nodig is, voordat de structuur van die gegevens duidelijk kan worden. Ditzelfde geldt voor de processen en de interfaces van een informatiesysteem. Het in kaart brengen noemen we 'informatieanalyse', het structureren 'ontwerp'. Analyse en ontwerp van de gegevens worden samen ook wel 'gegevensmodellering' genoemd. Een goede reden om de informatieanalyse niet te beschouwen als een aparte fase is de volgende. De informatieanalyse levert niet echt een eindproduct op. Pas na het ontwerp is er een afgebakend, duidelijk eindproduct, namelijk het genormaliseerde gegevensmodel met bijbehorende precieze data-dictionary. Omwille van de duidelijkheid zullen we in wat volgt de informatieanalyse en het ontwerp (zie daarvoor hoofdstukken 3 en 4) apart behandelen. Databanken 16

17 Vier vragen De informatieanalyse stelt vier vragen waarop een antwoord moet komen: Welke informatie zal de database moeten kunnen leveren? Dat is de vraag naar het eindproduct van de database, inclusief de kwaliteit daarvan. Hoe dikwijls, hoe snel, op welke plaatsen moeten die gegevens worden geleverd? Ook de vraag wie dat moet doen hoort hierbij. Welke gegevens moet de database bevatten om in de vastgestelde informatiebehoefte te kunnen voorzien? Dit is de vraag naar het basismateriaal, de feiten die in de database moeten worden vastgelegd. In veel gevallen zijn deze gelijk aan de gevraagde gegevens uit het vorige punt, maar dat is niet altijd zo. In onderzoeksdatabases of in beslissingsondersteunende systemen hebben gebruikers allerlei geaggregeerde overzichtsgegevens nodig. In Executive Information Systems (EIS), een type beslissingsondersteunend systeem voor managers, tapt het systeem gegevens af uit een database met elementaire feiten over de bedrijfsvoering die op de werkvloer worden verzameld, om er overzichtsstatistieken van te kunnen maken over productiviteit, verkoopcijfers en dergelijke. Welke gegevens zijn er beschikbaar? Dit is de vraag of, hoe en tegen welke kosten de benodigde basisgegevens te verkrijgen zijn. Het komt nogal eens voor dat de benodigde gegevens er domweg niet zijn, zodat men zijn doelen moet bijstellen of eerst iets moet bedenken om de gegevens te verzamelen. Bij onderzoeksprojecten is het bijvoorbeeld veel voorkomend dat relevante gegevens volledig ontbreken. Als er inderdaad gegevens nodig zijn die niet - of slechts tegen hoge kosten - kunnen worden verkregen, zal de projectleiding hierover moeten besluiten voordat de ontwerpers verder kunnen gaan. Hoe is het verband tussen de benodigde gegevens? Deze vraag luidt: Welke objecten met welke kenmerken vallen er te onderscheiden, en hoe hangen ze samen? Het antwoord is een eerste voorlopig gegevensmodel, en wel één dat dient als hulpmiddel in de discussie tussen ontwerper en probleemhebbers. Hierbij is het belangrijk te modelleren wat er zou kunnen gebeuren, niet wat er zou moeten gebeuren. Immers, alleen wat in het model is opgenomen, kan later door het informatiesysteem worden voortgebracht. Inwat volgt behandelen we deze vierde vraag omdat het veruit de lastigste is. Dit is immers de stap waarbij de ontwerper de vertaling moet maken van 'realiteit' naar 'data'. Het voornaamste doel van de informatieanalyse is om niets over het hoofd te zien. Het resulterende model is een kenmodel van het Universe of Discourse, nog geen maakmodel voor de database Beginnen Alle begin is moeilijk, zo is het ook bij het maken van een gegevensmodel. Er zijn twee strategieën mogelijk. Men kan beginnen met de grote lijnen: top-down werken. Of men kan ook andersom werken, beginnend bij de attributen waarvan men weet dat ze nodig zijn. Deze aanpak heet bottom-up. Beide methoden hebben hun voor- en nadelen. Bij de top-down aanpak ziet men het duidelijkst de grote lijn, hetgeen een logisch vervolg is op de afbakening van het Universe of Discourse. Bij bottom-up is de kans op slordigheidsfouten kleiner, maar deze aanpak leidt soms tot afdwalen van de oorspronkelijke vraag, en tot een grotere afstand tussen ontwerper en gebruiker. In de praktijk werkt een ontwerper meestal in eerste instantie top-down en wordt de bottom-up aanpak gebruikt om de puntjes op de i te zetten. Databanken 17

18 Een beginnend ontwerper, die van start gaat met een informatieanalyse, heeft het extra moeilijk. Hij mist de intuïtie en ervaring om een eerste grof model op te stellen; tegelijkertijd weet hij nog onvoldoende over de kenmerken die nodig zijn om bottom-up te kunnen werken. Er zijn dan drie mogelijkheden: beginnen bij feiten over het Universe of Discourse die men uit interviews heeft afgeleid, bij teksten erover, of bij formulieren en bestanden die al bekend zijn en waarvan de inhoud in de database terecht moet komen. De analyse maakt dus gebruik van interviews en tekstanalyses. In zowel mondelinge als schriftelijke communicatie spelen "zinnen" een hoofdrol. Hoe wordt nu de analyse van zo'n zin uitgevoerd? Stel dat de volgende zin relevant is in het te analyseren informatiegebied: "Docent Paul verzorgt de vakken Databases en Analyse". Over het onderwerp van de zin, docent Paul wordt een uitspraak gedaan, namelijk dat hij de vakken databases en analyse verzorgt. Een dergelijke uitspraak noemen we een predikaat. Dit predikaat bevat een werkwoordsvorm (verzorgt) en een lijdend voorwerp (databases en analyse). Als we specifieke waarden van onderwerp en lijdend voorwerp nu abstraheren komen we tot een uitspraak als: docenten verzorgen vakken. Hierin ontdekken we twee mogelijke entiteiten en een relatie HOE BEGINNEN? Voor de concrete analyse kan men vanaf verschillende elementen vertrekken. Een eerste mogelijkheid is te beginnen met feiten, die men uit interviews haalt. Een tweede mogelijkheid is te starten vanaf bestaande teksten. En een derde mogelijkheid tenslotte is te beginnen met formulieren, lijsten of bestanden. Het spreekt voor zich dat vaak een combinatie van bovenstaande de meest volledige informatie zal geven over het informatiegebied Beginnen met feiten Het zoeken naar feiten, in de database-technische betekenis van het woord, kan een goede start bieden. Een mogelijkheid om hier vorm aan te geven kan er in bestaan een lijst op te stellen met allerhande verschillende soorten feiten die de database zal moeten weten. Voor het voorbeeld van hoofdstuk 1 zouden dat bijvoorbeeld kunnen zijn (zie ook hoger): Hans Koppens heeft telefoonnummer Verre Reizen heeft een omzet van 300. Hans Koppens is een headhunter die Verre Reizen opvolgt. Uit elk van deze feiten kunnen kenmerken (eigenlijk kenmerktypes) of entiteittypen worden afgeleid. Elk zelfstandig naamwoord kan een entiteittype of een kenmerk worden. Elke naam of elk nummer kan een identificerend kenmerk worden van een bijbehorend entiteittype. Het samen in een zin voorkomen van zaken betekent dat ze in verband staan met elkaar: misschien is het één een kenmerk van het ander, of zijn het twee entiteittypen waartussen een verband bestaat. Werkt men top-down, dan zal men op zoek gaan naar entiteittypen. Werkt men bottomup, dan zoekt men naar kenmerken en blijkt pas later welke kenmerken samen in een entiteittype terechtkomen. Het verschil tussen entiteittype en kenmerk kent u al: een entiteittype is iets waarover men één of meer zaken wil weten, en die zaken die men over een entiteittype wil weten zijn de kenmerken. Of u iets ziet als entiteittype of als kenmerk Databanken 18

19 hangt dus af van wat u wilt weten. Laten we eens nagaan welke entiteittypen en kenmerken in het voorbeeld hierboven te herkennen zijn. Hans Koppens is de naam van een headhunter: we hebben dus een entiteittype 'headhunter' met kenmerk 'naam'. Een tweede kenmerk is 'telefoonnummer'. Een entiteittype 'telefoonnummer' lijkt niet zinvol: de vraag dringt zich dan meteen op 'waarvan?' Van die headhunter natuurlijk! Dat geeft aan dat het telefoonnummer op zichzelf in dit geval geen bestaansrecht heeft, maar een kenmerk is van 'headhunter'. Op dezelfde manier kunnen we een entiteittype 'organisatie' met kenmerken 'naam' en 'omzet' detecteren. In de derde zin worden twee dingen aan elkaar gekoppeld: een headhunter en een organisatie. Dit is een koppeling tussen een headhunter en een organisatie. Wanneer we op deze manier alle genoteerde feiten overlopen kunnen we tot een vrij volledig beeld komen van alle entiteittypes en kenmerken. Uiteraard zal het zo bekomen model nog veranderen. Het is wel meer een houvast omop te kunnen voortbouwen dan een doel op zich Beginnen met teksten Het kan voorkomen dat u niet ver genoeg komt met het verzamelen van feiten, of dat er geen gebruiker te vinden is die begrijpt wat u bedoelt wanneer u om `feiten' vraagt. Teksten kunnen dan een alternatief zijn. Vaak zijn er wel teksten voorhanden die het Universe of Discourse beschrijven. Ook kan men gewoon met gebruikers over het probleemgebied praten. Ook deze teksten en uitspraken bevatten feiten die gebruikt kunnen worden om entiteittypen en kenmerken te vinden. Wel is er dikwijls nog een vertaalslag nodig om een stuk tekst om te zetten naar database-feiten. Staat er bijvoorbeeld in een document 'dat men de beschikking heeft over een lijst met alle personeel van de onderneming' dan betekent dat niet dat er een entiteittype 'personeellijst' moet komen. Personeellijst is in dit geval niet meer dan de gegevensdrager voor entiteiten van type 'personeelslid'. Meestal is het een goed idee de teksten te herleiden tot een aantal eenvoudige predikaten: dit wordt decompositie genoemd Beginnen met formulieren, lijsten of bestanden Soms heeft de ontwerper aan het begin van een informatieanalyse al meer houvast, namelijk als er al formele gegevensstructuren bestaan die in de database moeten worden overgenomen. Het kan dat er lijsten met gegevens voorhanden zijn (bijvoorbeeld wekelijkse bestellijst), dat er bepaalde formulieren voorhanden zijn (orders),... Zulke formulieren of bestanden hebben meestal de structuur van één entiteittype met een aantal kenmerken, namelijk de velden in het formulier of bestand. Als er herhaalde regels in een lijst staan, hebben die meestal betrekking op een eigen entiteittype dat een veel-op-één verband heeft met het andere entiteittype. Een orderformulier bijvoorbeeld geeft aan dat er een entiteit van type 'order' bestaat, maar zal meestal ook een aantal lijnen bestelde artikelen bevatten, wat erop wijst dat er een entiteit van type 'bestelartikel' bestaat date een veel-op-één relatie heeft met 'order'. Een gevaar van deze aanpak is dat men verkeerde gegevensstructuren uit het verleden zou kunnen afleiden uit deze bestaande lijsten. Het moet dus altijd met een kritisch oog gebeuren. Databanken 19

20 2.5. OPGAVEN 1. Bekijk het voorbeeld in hoofdstuk 1. Hoeveel objectsoorten, objecten en kenmerkwaarden bevat deze database? Op hoeveel domeinen zijn de kenmerken uit het voorbeeld gedefiniëerd? 2. Het is meestal wenselijk om attributen die op hetzelfde domein zijn gedefiniëerd ook dezelfde naam te geven. Welk attribuut zou je in het voorbeeld van hoofdstuk 1 kunnen toevoegen waar je dat mee doet? En wat zou je doen indien je van de headhunters ook mobiel telefoonnummer en telefoon op het werk zou willen bijhouden, naast de telefoon thuis? 3. Bedenk een situatie waarin "auto" een verzameling typen is, één waarin het een verzameling individuen is, en één waarin het een waarde is van een kenmerk. Geef in alle drie de gevallen aan hoe men dit kan opslaan in een computer in termen van bestanden en records. 4. In een magazijn liggen duizenden artikelen opgeslagen. De artikelen zijn onderverdeeld in soorten en iedere soort heeft een nummer en een naam (bijvoorbeeld nummer met naam 'wasknijper'). Van iedere soort zijn er één of meerdere aanwezig in het magazijn. Welke objecten zie je hier met welke attributen? 5. Hieronder ziet u de naam van enkele tabellen met hun kolommen. Het gaat om de database voor de ledenadministratie van een sportclub. Het gegevensmodel erachter klopt, maar de namen zijn niet erg gelukkig gekozen. a) Welke tekortkomingen zie je? b) Welke problemen zullen die geven in het gebruik? ETIKETTEN (anr, str, hnr, pc, wp) LEDENLIJST (naam, voornaam, geboren, nr, teamnr, adres) TEAM (teamno, categorie, poule, naam-t, naam_c) CATAGO (code, max, min) 6. Hoe zou jij de naamgeving doen in bovenstaande model? 7. In een bedrijf is de dienst "werving personeel" verantwoordelijk voor het aanwerven van personeel. Hieronder volgt een beschrijving van wat ze doen. Herleid de tekst tot een aantal predikaten (decompositie). "Voor vacatures die vanuit het bedrijf worden aangemeld, moeten advertentieteksten worden opgesteld en deze moeten in geschikte kranten en tijdschriften worden geplaatst. Op grond van binnenkomende sollicitatiebrieven krijgt een aantal sollicitanten een uitnodiging voor een gesprek. Een klein deel wordt voor een tweede gesprek uitgenodigd. Psychologische tests worden indien nodig door erkende bureaus afgenomen en eventuele referenties worden nagetrokken. Hierna kan een kandidaat een aanbod worden gedaan. Als dat aanbod wordt geaccepteerd, kan de indiensttreding worden geregeld." Databanken 20