Databanken Marc De Caluwé,

Maat: px
Weergave met pagina beginnen:

Download "Databanken Marc De Caluwé, 2005-2009"

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é', 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

Relationele databanken

Relationele databanken Relationele databanken De meeste databanken zijn relationeel. Gegevens in tabellen. Relationele model stoelt op de verzamelingenleer (leer der relaties). Relatie betekent hier tabel. Grote kracht van deze

Nadere informatie

Databases en SQL Foundation (DBSQLF.NL)

Databases en SQL Foundation (DBSQLF.NL) Databases en SQL Foundation (DBSQLF.NL) EXIN Hét exameninstituut voor ICT ers Janssoenborch - Hoog Catharijne Godebaldkwartier 365 3511 DT Utrecht Postbus 19147 3501 DC Utrecht Nederland T +31 30 234 48

Nadere informatie

SQL is opgebouwd rond een basisinstructie waaraan één of meerdere componenten worden toegevoegd.

SQL is opgebouwd rond een basisinstructie waaraan één of meerdere componenten worden toegevoegd. BASISINSTRUCTIES SQL SQL : Structured Query Language is een taal gericht op het ondervragen van een relationele database en die aan veel klassieke databasemanagementsystemen kan worden gekoppeld. SQL is

Nadere informatie

Les S-01: De basisbeginselen van SQL

Les S-01: De basisbeginselen van SQL Les S-01: De basisbeginselen van SQL 1.0 Relationele databases en SQL Een database is een bestand waarin gegevens worden opgeslagen in de vorm van tabellen. Zo kan een huisarts met behulp van een database

Nadere informatie

Inhoud. Voorwoord Belangrijkste kenmerken van dit boek De opzet van dit boek Over de auteur Woord van dank

Inhoud. Voorwoord Belangrijkste kenmerken van dit boek De opzet van dit boek Over de auteur Woord van dank v Voorwoord Belangrijkste kenmerken van dit boek De opzet van dit boek Over de auteur Woord van dank 1 Introductie: data en informatie 1.0 Wat leer je in dit hoofdstuk? 1.1 Verschil tussen gegevens en

Nadere informatie

Databases - Inleiding

Databases - Inleiding Databases Databases - Inleiding Een database is een verzameling van een aantal gegevens over een bepaald onderwerp: een ledenbestand van een vereniging, een forum, login gegevens. In een database worden

Nadere informatie

PROGRAMMA 2011-2012. Vak: informatica..

PROGRAMMA 2011-2012. Vak: informatica.. Vak: informatica.. Laag: Havo-. PROGRAMMA 2011-2012 week leerstof dagen toets overig 34-26.08 zomervakantie Bespreking PTA-404 Deze week: uitreiking van de Praktische Opdracht Programmeren Herhaling theorie

Nadere informatie

1. Databanken. Wat is een databank? Verschillende opslagmethodes

1. Databanken. Wat is een databank? Verschillende opslagmethodes 1. Databanken Wat is een databank? Verschillende opslagmethodes Tekst bestanden Spreadsheet Relationele gegevensbanken Relationeel model De gestandaardiseerde opvraagtaal SQL Beheer van een mysql databank

Nadere informatie

Hoofdstuk: 1 Principes van databases

Hoofdstuk: 1 Principes van databases DBSQLF Databases en SQL Hoofdstuk: 1 Principes van databases aant Css: 4 732 blz 9 1.1 Doel ve database - om op het juiste moment op de juiste plaats de juiste gegevens beschikbaar te hebben richten we

Nadere informatie

Als er besloten is een database op te stellen dient men een analyse van de informatiegegevens te volbrengen.

Als er besloten is een database op te stellen dient men een analyse van de informatiegegevens te volbrengen. Normaliseren Een van de voornaamste rollen in een informatie systeem is het bewaren van gegevens en liefst over een lange tijd. Meestal doen we dat door middel van een gegevensbank of databank. Deze gestructureerde,

Nadere informatie

SQL manipulatietaal. We kunnen er data mee toevoegen, wijzigen en verwijderen uit een database.

SQL manipulatietaal. We kunnen er data mee toevoegen, wijzigen en verwijderen uit een database. SQL manipulatietaal We kunnen er data mee toevoegen, wijzigen en verwijderen uit een database. Basiscommando's: INSERT : toevoegen van gegevens DELETE : verwijderen van gegevens UPDATE : wijzigen van gegevens

Nadere informatie

1. Inleiding... 2 1.1. Inleiding SQL... 3 1.1.1. Inleiding... 3 1.1.2. Database, databaseserver en databasetaal... 4 1.1.3. Het relationele model...

1. Inleiding... 2 1.1. Inleiding SQL... 3 1.1.1. Inleiding... 3 1.1.2. Database, databaseserver en databasetaal... 4 1.1.3. Het relationele model... 1. Inleiding... 2 1.1. Inleiding SQL... 3 1.1.1. Inleiding... 3 1.1.2. Database, databaseserver en databasetaal... 4 1.1.3. Het relationele model... 4 1.1.4. Wat is SQL?... 6 1.1.5. Verschillende categorieên

Nadere informatie

Sparse columns in SQL server 2008

Sparse columns in SQL server 2008 Sparse columns in SQL server 2008 Object persistentie eenvoudig gemaakt Bert Dingemans, e-mail : info@dla-os.nl www : http:// 1 Content SPARSE COLUMNS IN SQL SERVER 2008... 1 OBJECT PERSISTENTIE EENVOUDIG

Nadere informatie

SQL & Datamodelleren

SQL & Datamodelleren SQL & Datamodelleren HVA-CMD-V1-datamodelleren Algemene handleiding bij het lesprogramma 2012-2013 Inhoud Inhoud... 2 Inleiding... 3 Leerdoelen:... 3 Plaats in het leerplan:... 3 Werkwijze:... 3 Lesstof:...

Nadere informatie

Workshop 3x. Normaliseren. Normaliseren. Hiëarchische database ODBMS. Relationele database. Workshop 14 oktober 2010. A. Snippe ICT Lyceum 1

Workshop 3x. Normaliseren. Normaliseren. Hiëarchische database ODBMS. Relationele database. Workshop 14 oktober 2010. A. Snippe ICT Lyceum 1 Workshop 3x Analytisch vermogen Huiswerk Lestijden 10:00 12:30 Pauze 10:15 10:30 Deze les: Hiëarchische database Relationele database ODBMS Normaliseer stappen Hiëarchische database Elk record in een database

Nadere informatie

Top-down ontwerpen. Concentreren op de hoofdzaak zonder rekening te houden met allerlei details.

Top-down ontwerpen. Concentreren op de hoofdzaak zonder rekening te houden met allerlei details. Top-down ontwerpen Concentreren op de hoofdzaak zonder rekening te houden met allerlei details. Dus: de belangrijkste entiteittypes en hun onderlinge structuur proberen te vinden. De relaties in tekst

Nadere informatie

SQL Aantekeningen 3. Maarten de Rijke mdr@science.uva.nl. 22 mei 2003

SQL Aantekeningen 3. Maarten de Rijke mdr@science.uva.nl. 22 mei 2003 SQL Aantekeningen 3 Maarten de Rijke mdr@science.uva.nl 22 mei 2003 Samenvatting In deze aflevering: het selecteren van tuples, operaties op strings, en aggregatie functies. Verder kijken we naar iets

Nadere informatie

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER Het belang van Data Modellering Studiedag Informatiemanagement Politeia, 22 februari 2013, Gent Open data en de cloud: een revolutie in de informatiehuishouding van de overheid Training Data Modellering

Nadere informatie

DATAMODEL SQL. Middelbare School. Versie 1.0 Datum 30 oktober 2010 Auteur Mark Nuyens, studentnummer: 500625333 Groep TDI 1

DATAMODEL SQL. Middelbare School. Versie 1.0 Datum 30 oktober 2010 Auteur Mark Nuyens, studentnummer: 500625333 Groep TDI 1 DATAMODEL SQL Middelbare School Versie 1.0 Datum 30 oktober 2010 Auteur Mark Nuyens, studentnummer: 500625333 Groep TDI 1 INHOUDSOPGAVE 1. Informatiedomein 3 1.1 Informatiedomein 3 1.2 Toepassingen 3 2.

Nadere informatie

PROGRAMMA 2011-2012. Vak: Informatica..

PROGRAMMA 2011-2012. Vak: Informatica.. Vak: Informatica.. Laag: vwo-. PROGRAMMA 2011-2012 week leerstof dagen toets overig 34-26.08 zomervakantie Bespreking PTA-404 1. Deze week: uitreiking van de Praktische Opdracht Programmeren Herhaling

Nadere informatie

Inleiding... 3. 1 Databases en Data Base Management Systems... 3. 2 Tabellen... 3. 3 Wat is SQL?... 5

Inleiding... 3. 1 Databases en Data Base Management Systems... 3. 2 Tabellen... 3. 3 Wat is SQL?... 5 1 Inhoudsopgave. Inleiding.... 3 1 Databases en Data Base Management Systems.... 3 2 Tabellen.... 3 3 Wat is SQL?... 5 4 Gegevens opvragen (deel 1).... 5 4.1 Boolean operatoren.... 7 4.2 IN en BETWEEN

Nadere informatie

Objecttype Reactie Actie EGEM

Objecttype Reactie Actie EGEM 1 Overzicht ontvangen commentaar op het Referentiemodel Gemeentelijke Basisgegeven Zaken v0.9 (Herkomst van de reacties is bij EGEM bekend) 1 2.2 / 13 Besluit Een twijfelgeval is nog BESLUIT, goed beschouwd

Nadere informatie

Informatieobjecten zijn systematisch beschreven

Informatieobjecten zijn systematisch beschreven AP17 Informatieobjecten zijn systematisch beschreven Statement De aan de dienst gerelateerde informatieobjecten zijn systematisch beschreven en op passende wijze gemodelleerd. Afgeleid van BP2 (vindbaar)

Nadere informatie

Waarom Access. In de onderstaande afbeelding ziet u een begin van de lijst met cliëntgegevens van de diëtiste.

Waarom Access. In de onderstaande afbeelding ziet u een begin van de lijst met cliëntgegevens van de diëtiste. Waarom Access Voor velen is het verschijnsel van de relationele database een brug te ver. Voor het opslaan en analyseren van gegevens neemt men zijn toevlucht tot Excel. Excel heeft inderdaad een uitgebreid

Nadere informatie

DBMS. DataBase Management System. Op dit moment gebruiken bijna alle DBMS'en het relationele model. Deze worden RDBMS'en genoemd.

DBMS. DataBase Management System. Op dit moment gebruiken bijna alle DBMS'en het relationele model. Deze worden RDBMS'en genoemd. SQL Inleiding relationele databases DBMS DataBase Management System!hiërarchische databases.!netwerk databases.!relationele databases.!semantische databases.!object oriënted databases. Relationele databases

Nadere informatie

9 Werken met meer tabellen (zie ook query s)

9 Werken met meer tabellen (zie ook query s) 9 Werken met meer tabellen (zie ook query s) 9.1 Inleiding werkwijze je moet begrijpen waarom in de praktijk een databank meestal opgebouwd wordt met verschillende tabellen die aan elkaar gekoppeld worden.

Nadere informatie

1 Download de database 'bieren.mdb' en bewaar het bestand in c:\werkmap van je computer.

1 Download de database 'bieren.mdb' en bewaar het bestand in c:\werkmap van je computer. DataBase Management & Databasetechnologie We gaan nu aan de slag met het databasemanagementprogramma Access. Zo'n set programma's waarmee je databases kunt maken, beheren en bevragen noemt men ook wel

Nadere informatie

Databank - Basis 1. Inhoud. Computervaardigheden en Programmatie. Hoofdstuk 4 Databank - Basis. Terminologie. Navigeren door een Venster

Databank - Basis 1. Inhoud. Computervaardigheden en Programmatie. Hoofdstuk 4 Databank - Basis. Terminologie. Navigeren door een Venster 4. 4. Inhoud rste BAC Toegepaste Biologische Wetenschappen Hoofdstuk 4 Databank Terminologie, Navigeren, Importeren Tabellen Records/Velden manipuleren Queries (Vragen) [Ook in SQL] sorteren filter volgens

Nadere informatie

Ontwerp een datamodel

Ontwerp een datamodel SQL IAM-TDI-V2-SQL, handleiding datamodel Ontwerp een datamodel Fons van Kesteren, okt 2008, HvA IAM IAM-V2-TDI-SQL 1 Doelstelling... 3 Het ontwerpproces... 4 Afbakening van het informatiedomein... 5 Entiteiten,

Nadere informatie

Praktijkinstructie Geautomatiseerde informatievoorziening - beheer 3 (CIN02.3/CREBO:50170)

Praktijkinstructie Geautomatiseerde informatievoorziening - beheer 3 (CIN02.3/CREBO:50170) instructie Geautomatiseerde informatievoorziening - beheer 3 (CIN02.3/CREBO:50170) pi.cin02.3.v2 ECABO, 1 september 2003 Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd, overgenomen,

Nadere informatie

Les 2 Eenvoudige queries

Les 2 Eenvoudige queries Les 2 Eenvoudige queries XAMP Apache server ( http ) mysql server PHP myadmin IAM SQL oefeningen Database phpmyadmin Import : sql_producten.sql, sql_winkel.sql, sql_festival.sql SAMS SQL in 10 minuten

Nadere informatie

MODULEBESCHRIJVING Databases DBS1

MODULEBESCHRIJVING Databases DBS1 MODULEBESCHRIJVING Databases DBS1 Samensteller(s): Richard van den Ham Datum: 30-08-2012 Versie: 1.0 Module: Databases Identificatie Progresscode: DBS1 Semester: 1 Omvang: 140 SBUs/ 5 ECTS-punten Lestijd:

Nadere informatie

Opleiding SQL / Systeemanalyse IBK ERD. Hogeschool Rotterdam

Opleiding SQL / Systeemanalyse IBK ERD. Hogeschool Rotterdam Opleiding SQL / Systeemanalyse IBK ERD Hogeschool Rotterdam ERD ERD = Entity Relationship diagram is een model of diagram voor het inzichtelijk te maken van een conceptueel datamodel. Het is een visuele

Nadere informatie

Op de werkbalk staan drie knoppen, die van links naar rechts staan voor de drie genoemde stappen.

Op de werkbalk staan drie knoppen, die van links naar rechts staan voor de drie genoemde stappen. pagina 1 van 9 Een informatiemodel vertalen naar een database Het ontwerpen van een database met behulp van het casetool gaat in drie stappen: 1. Controle Eerst voert het casetool een controle uit. Er

Nadere informatie

TECHNISCHE UNIVERSITEIT EINDHOVEN. Faculteit Wiskunde en Informatica

TECHNISCHE UNIVERSITEIT EINDHOVEN. Faculteit Wiskunde en Informatica TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica Extra Tentamen Databases 1, 2M400, 8 oktober 2003. Alle uitwerkingen van de opgaven moeten worden ingevuld in de daarvoor bestemde vrije

Nadere informatie

SQL / Systeemanalyse

SQL / Systeemanalyse SQL / Systeemanalyse Wie ben ik Hans de Wit 44 jaar HBO BI in deeltijd gedaan Sinds 2008 werkzaam met BI / DWH med.hro.nl/wihan SQL De gegevens in een database vormen de grondstof voor informatie De informatie

Nadere informatie

Tools voor canonieke datamodellering Bert Dingemans

Tools voor canonieke datamodellering Bert Dingemans Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze

Nadere informatie

SQL datadefinitietaal

SQL datadefinitietaal SQL datadefinitietaal We kunnen er het schema van de database mee bepalen: metadata toevoegen, wijzigen en verwijderen uit een database. Basiscommando's: CREATE : toevoegen van metagegevens DROP : verwijderen

Nadere informatie

NHibernate als ORM oplossing

NHibernate als ORM oplossing NHibernate als ORM oplossing Weg met de SQL Queries Wat is ORM? ORM staat in dit geval voor Object Relational Mapping, niet te verwarren met Object Role Modeling. ORM vertaalt een objectmodel naar een

Nadere informatie

Project plan. Erwin Hannaart Sander Tegelaar 61849 62407

Project plan. Erwin Hannaart Sander Tegelaar 61849 62407 Project plan Erwin Hannaart Sander Tegelaar 61849 62407 I4C2 I4C1 1 Inhoudsopgave Doel en doelgroep van het project... 3 Beschrijving van het project... 4 Benodigde materialen... 5 Te verwachten resultaten,

Nadere informatie

Module 1 Programmeren

Module 1 Programmeren Module 1 Programmeren Programmeertalen 13 1.1 Inleiding 13 1.2 Programmeertalen in historisch perspectief 13 1.2.1 Machinecode 13 1.2.2 Assembleertalen (assembly) 14 1.2.3 Hogere programmeertalen 15 1.2.4

Nadere informatie

SQL: query taal met. woorden. ISO SQL: Structured Query Language. de SQL basis query structuur. voorbeeld: doel: intuitieve query taal

SQL: query taal met. woorden. ISO SQL: Structured Query Language. de SQL basis query structuur. voorbeeld: doel: intuitieve query taal SQL: query taal met woorden ISO SQL: Structured Query Language Prof. dr. Paul De Bra Gebaseerd op: Database System Concepts, 5th Ed. doel: intuitieve query taal gebruikt Engelse woorden: select, from,

Nadere informatie

Het omzetten van een ER-diagram naar SQL

Het omzetten van een ER-diagram naar SQL Het omzetten van een ER-diagram naar SQL Huub de Beer Eindhoven, 4 juni 2011 Omzetting ER-diagram naar SQL in twee stappen 1: ER-Diagram relationeel model Onderwerp van hoofdstuk 3 Entiteittype relatie,

Nadere informatie

ISO SQL: Structured Query Language

ISO SQL: Structured Query Language ISO SQL: Structured Query Language Prof. dr. Paul De Bra Gebaseerd op: Database System Concepts, 5th Ed. SQL: query taal met woorden doel: intuitieve query taal gebruikt Engelse woorden: select, from,

Nadere informatie

Thinking of development

Thinking of development Thinking of development Databases Arjan Scherpenisse HKU / Miraclethings Agenda voor vandaag Opdracht tussenstand State diagram / Observer pattern Bret Victor Databases 2/42 Opdracht tussenstand Slides

Nadere informatie

Semantiek (met de BAG als voorbeeld) Dienstverlening in verbinding Wetgeving in verbinding 12 maart 2014 Marco Brattinga (marco.brattinga@ordina.

Semantiek (met de BAG als voorbeeld) Dienstverlening in verbinding Wetgeving in verbinding 12 maart 2014 Marco Brattinga (marco.brattinga@ordina. 1 Semantiek (met de BAG als voorbeeld) Dienstverlening in verbinding Wetgeving in verbinding 12 maart 2014 Marco Brattinga (marco.brattinga@ordina.nl) DIT is geen nummeraanduiding Meerdere werkelijkheden

Nadere informatie

SQL Plan Management in Oracle11g Harald van Breederode

SQL Plan Management in Oracle11g Harald van Breederode SQL Plan Management in Oracle11g Harald van Breederode Sinds de introductie van de Cost Based Optimizer (CBO) in Oracle7 hebben zowel database beheerders als database ontwikkelaars de wens om deze optimizer

Nadere informatie

MVO-Control Panel. Instrumenten voor integraal MVO-management. Intern MVO-management. Verbetering van motivatie, performance en integriteit

MVO-Control Panel. Instrumenten voor integraal MVO-management. Intern MVO-management. Verbetering van motivatie, performance en integriteit MVO-Control Panel Instrumenten voor integraal MVO-management Intern MVO-management Verbetering van motivatie, performance en integriteit Inhoudsopgave Inleiding...3 1 Regels, codes en integrale verantwoordelijkheid...4

Nadere informatie

INHOUD. Presentatie ICT werkervaring (voornamelijk) Gericht op databasetoepassingen. Sprekers. Allard van Amerongen Ing. Stefan Boekel 05-02-2008

INHOUD. Presentatie ICT werkervaring (voornamelijk) Gericht op databasetoepassingen. Sprekers. Allard van Amerongen Ing. Stefan Boekel 05-02-2008 INHOUD Presentatie ICT werkervaring (voornamelijk) Gericht op databasetoepassingen Sprekers Datum : : Allard van Amerongen Ing. Stefan Boekel 05-02-2008 INTRODUCTIE WIE BEN IK? Verleden/heden WAT DOE IK?

Nadere informatie

voorbeeldexamen I-Tracks Databases and SQL Foundation Voorbeeldexamen DBSQLF Uitgave juni 2006

voorbeeldexamen I-Tracks Databases and SQL Foundation Voorbeeldexamen DBSQLF Uitgave juni 2006 voorbeeldexamen Databases and SQL Foundation (DBSQLF) I-Tracks Databases and SQL Foundation Voorbeeldexamen DBSQLF Uitgave juni 2006 inhoud 3 inleiding 4 voorbeeldexamen 21 antwoordindicatie 44 beoordeling

Nadere informatie

Business Intelligence. Toepassing BI Database en Datawarehouse BI proces BI Organisatie Implementatie BI

Business Intelligence. Toepassing BI Database en Datawarehouse BI proces BI Organisatie Implementatie BI Business Intelligence Toepassing BI Database en Datawarehouse BI proces BI Organisatie Implementatie BI Toepassing BI (Operationele) sturing Financieel (BBSC) Performance NIET voor ondersteuning proces

Nadere informatie

DMD-2011 Introductie. Introductie. Opzet van de cursus. Werkwijze per week. Datamodelleren en databases 2011. Twee hoorcolleges in totaal

DMD-2011 Introductie. Introductie. Opzet van de cursus. Werkwijze per week. Datamodelleren en databases 2011. Twee hoorcolleges in totaal Datamodelleren en databases 2011 Introductie Leen Breure 1/33 Opzet van de cursus Twee hoorcolleges in totaal week 1 en week 8 (14 juni) Wekelijks practicum: ca. 2 * 1 uur 1 uur: ontwikkeling van eigen

Nadere informatie

Technische nota AbiFire5 Rapporten maken via ODBC

Technische nota AbiFire5 Rapporten maken via ODBC Technische nota AbiFire5 Rapporten maken via ODBC Laatste revisie: 29 juli 2009 Inhoudsopgave Inleiding... 2 1 Installatie ODBC driver... 2 2 Systeeminstellingen in AbiFire5... 3 2.1 Aanmaken extern profiel...

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

Structured Query Language (SQL)

Structured Query Language (SQL) Structured Query Language (SQL) Huub de Beer Eindhoven, 4 juni 2011 Database: in essentie 0 of meer tabellen elke tabel nul of meer kolommen (of velden) elke tabel nul of meer unieke rijen elke query werkt

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Privacy Verklaring versie 01-10-2015

Privacy Verklaring versie 01-10-2015 Privacy Verklaring versie 01-10-2015 1. Algemene bepalingen inzake gegevensverwerking 1.1. Met gegevensverwerking wordt het verzamelen, vastleggen, arrangeren, bewaren, wijzigen, openbaar maken, overleggen,

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Les S-02: Meer geavanceerde SQL-instructies

Les S-02: Meer geavanceerde SQL-instructies Les S-02: Meer geavanceerde SQL-instructies 2.0 Overzicht les 1: De basisvorm van een SQL query ziet er als volgt uit: (DISTINCT) selecteer de velden uit de tabel waar de volgende voorwaarde geldt ; Bij

Nadere informatie

Toets informatica V5 module VIII hfst 1, 2 en 3 februari 2011

Toets informatica V5 module VIII hfst 1, 2 en 3 februari 2011 1) Hieronder staan twee beweringen: I. Het conceptueel model wordt neergelegd in het functioneel-ontwerprapport. II. Tijdens de informatieplanning worden de bedrijfsprocessen in kaart gebracht. 2) Hieronder

Nadere informatie

Informatie Systeem Ontwikkeling ISO 2R290

Informatie Systeem Ontwikkeling ISO 2R290 Informatie Systeem Ontwikkeling ISO 2R290 docent: Prof. dr. Paul De Bra Gebaseerd op: Database System Concepts, 5th Ed. doel van dit vak kennis van en inzicht in basisbegrippen over informatiesystemen

Nadere informatie

Powerpoint presentatie College 5 Gilbert van Lierop & Farshad Salamat

Powerpoint presentatie College 5 Gilbert van Lierop & Farshad Salamat Powerpoint presentatie College 5 Gilbert van Lierop & Farshad Salamat Wat is een database? Een verzameling van georganiseerde data Een database bestaat uit applicaties, SQL en het DBMS Watis eendbms? EenDBMS

Nadere informatie

Procesmanagement. Waarom processen beschrijven. Algra Consult

Procesmanagement. Waarom processen beschrijven. Algra Consult Procesmanagement Waarom processen beschrijven Algra Consult Datum: 22 oktober 2009 Inhoudsopgave 1. INLEIDING... 3 2. WAAROM PROCESMANAGEMENT?... 3 3. WAAROM PROCESSEN BESCHRIJVEN?... 3 4. PROCESASPECTEN...

Nadere informatie

Les 11 : Basis SQL (deel2).

Les 11 : Basis SQL (deel2). Les 11 : Basis SQL (deel2). Wat is SQL? SQL gaan we gebruiken voor het raadplegen van de database. We gaan gegevens invoegen in de database, selecteren, aanpassen en verwijderen van de database. Om dit

Nadere informatie

Praktijkinstructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131)

Praktijkinstructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131) instructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131) pi.cin08.4.v2 ECABO, 1 september 2003 Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd, overgenomen, opgeslagen

Nadere informatie

EUROPEES COMPUTER RIJBEWIJS / INTERNATIONAAL COMPUTER RIJBEWIJS ADVANCED DATABASE

EUROPEES COMPUTER RIJBEWIJS / INTERNATIONAAL COMPUTER RIJBEWIJS ADVANCED DATABASE EUROPEES COMPUTER RIJBEWIJS / INTERNATIONAAL COMPUTER RIJBEWIJS ADVANCED DATABASE The European Computer Driving Licence Foundation Ltd. Portview House Thorncastle Street Dublin 4 Ierland Tel: + 353 1 630

Nadere informatie

BIJLAGE BIJ DE HANDLEIDING NAVISION INCADEA DOSSIERBEHEER SALES REVIEW & TOOLS

BIJLAGE BIJ DE HANDLEIDING NAVISION INCADEA DOSSIERBEHEER SALES REVIEW & TOOLS Copyright BMW GROUP Belux / Revisie 0 BIJLAGE BIJ DE HANDLEIDING NAVISION INCADEA DOSSIERBEHEER SALES REVIEW & TOOLS Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel

Nadere informatie

Gebruikers Handleiding

Gebruikers Handleiding Gebruikers Handleiding (De SQL module) Versie 2.14 Pagina 2 van 14 Versie 2.14 Inhoudsopgave NGP SQL...5 Het Menu... 6 De instellingen... 7 De database informatie... 9 Het Script... 10 Pagina 3 van 14

Nadere informatie

Koppeling met een database

Koppeling met een database PHP en MySQL Koppeling met een database 11.1 Inleiding In PHP is het eenvoudig om een koppeling te maken met een database. Een database kan diverse gegevens bewaren die met PHP aangeroepen en/of bewerkt

Nadere informatie

1. * Database worden vaak gebruikt in Client-Server architectuur.

1. * Database worden vaak gebruikt in Client-Server architectuur. Naam Studentnummer Klas Herkansing [ ] ja, nee [ ], zoja uit welk jaar? kernbegrippen relationele database Minimaal drie van de vijf vragen goed beantwoorden. 1. * Database worden vaak gebruikt in Client-Server

Nadere informatie

Systeemontwikkeling, Hoofdstuk 4, Tabellen maken in MS Access 2010

Systeemontwikkeling, Hoofdstuk 4, Tabellen maken in MS Access 2010 4 Tabellen maken in MS Access In dit hoofdstuk starten we met de bouw van ons informatiesysteem met de belangrijkste bouwstenen: de tabellen. 4.1 Starten met MS Access Als je het programma Microsoft Access

Nadere informatie

www.dubbelklik.nu Handleiding Access 2010

www.dubbelklik.nu Handleiding Access 2010 www.dubbelklik.nu Handleiding Access 2010 Deze handleiding is onderdeel van Dubbelklik, een lesmethode Technologie, ICT/ Loopbaanoriëntatie en Intersectoraal Alle rechten voorbehouden. Niets uit deze uitgave

Nadere informatie

EMBEDDED SQL. Inleiding. Queries en update-opdrachten. Embedden en hostvariabelen

EMBEDDED SQL. Inleiding. Queries en update-opdrachten. Embedden en hostvariabelen Inleiding In het boek Databases & SQL wordt beschreven hoe opdrachten in de programmeertaal SQL gebruikt worden om de inhoud van een relationele database te raadplegen en te bewerken. SQL wordt daarbij

Nadere informatie

Projecten Applicatie Ontwikkeling

Projecten Applicatie Ontwikkeling Projecten Applicatie Ontwikkeling Standaarden Normaliseren ROC Flevoland Werner Pauchli Versie 1.0 Almere, 15 januari 2004 Inhoudsopgave Inhoudsopgave Inhoudsopgave 3 1. Documentbeheer 4 2. Inleiding

Nadere informatie

Databases (INFODB) 24 januari 2007

Databases (INFODB) 24 januari 2007 Departement Informatica en Informatiekunde, Faculteit Bètawetenschappen, UU. In elektronische vorm beschikbaar gemaakt door de TBC van A Eskwadraat. Het college INFODB werd in 2006/2007 gegeven door Dhr.

Nadere informatie

het bank voorbeeld ISO Datamodelleren modelleren met het E-R R model een database ontwerpen verzamelingen van relaties (verbanden)

het bank voorbeeld ISO Datamodelleren modelleren met het E-R R model een database ontwerpen verzamelingen van relaties (verbanden) het bank voorbeeld ISO Datamodelleren Prof. dr. Paul De Bra waarom zijn er drie tabellen om klanten en rekeningen voor te stellen? customer (customer_name, customer_street, customer_city) account (account_number,

Nadere informatie

KnowMan Een Case-Based Reasoning Tool

KnowMan Een Case-Based Reasoning Tool KnowMan Een Case-Based Reasoning Tool Software Review L.A. Plugge Onlangs kreeg ik ter evaluatie het softwarepakket KnowMan van de firma Intellix toegestuurd. KnowMan is een case-based reasoning tool,

Nadere informatie

Rapporten. Labels en Rapporten in Atlantis 1. Atlantis heeft twee manieren om output te genereren: 1. labels 2. rapporten (reports)

Rapporten. Labels en Rapporten in Atlantis 1. Atlantis heeft twee manieren om output te genereren: 1. labels 2. rapporten (reports) Labels en Rapporten in Atlantis 1 Atlantis heeft twee manieren om output te genereren: 1. labels 2. rapporten (reports) Rapporten Een rapport is eigenlijk altijd een tekst bestand, die vorm wordt gegeven

Nadere informatie

Trainingsomschrijving ACCESS 97 / 2000 / 2003NL

Trainingsomschrijving ACCESS 97 / 2000 / 2003NL Module 1 Inleiding Module 2 Ontwerpen van tabellen Module 3 Relationele databases en queries Module 4 Formulieren en rapporten Module 5 Geav. formulieren en rapporten Module 6 Macro s en menu s Module

Nadere informatie

Registratie Data Verslaglegging

Registratie Data Verslaglegging Sjablonen Websupport Registratie Data Verslaglegging Websites Inrichtingen Video solutions Rapportages Consultancy Imports Helpdesk Exports Full Service Dashboards Registratie Koppelen en controleren De

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Checklist basisontwerp SDM II

Checklist basisontwerp SDM II Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance

Nadere informatie

Les 10 : Aanmaken van een database (deel2).

Les 10 : Aanmaken van een database (deel2). Les 10 : Aanmaken van een database (deel2). Wat is een database? Een centrale opslagruimte voor gegevens. Alle informatie wordt centraal opgeslagen en kan door iedereen geraadpleegd worden. Voordelen van

Nadere informatie

hoofdstuk 9 referentiële integriteit waarborgen overige constraints 9.1 Referentiële integriteit relationele databases 9.1

hoofdstuk 9 referentiële integriteit waarborgen overige constraints 9.1 Referentiële integriteit relationele databases 9.1 relationele databases 9.1 hoofdstuk 9 referentiële integriteit waarborgen overige constraints 9.1 Referentiële integriteit Als voorbeeld nemen we een eenvoudige database, bestaande uit twee tabellen. De

Nadere informatie

Deel 2: Endnote bibliografische software gebruiken als databasemanager en editor

Deel 2: Endnote bibliografische software gebruiken als databasemanager en editor Deel 2: Endnote bibliografische software gebruiken als databasemanager en editor Versie feb. 2015 pag. 38 Endnote output: 1. Organiseer je database 2. Doorzoek de referenties in je database 3. Publiceren,

Nadere informatie

B3Partners. Beheerhandleiding Datastorelinker 4.2. Gewijzigd: 28 maart 2014. B3Partners BV Bedrijvenpark Lage Weide Zonnebaan 12c 3542 EC Utrecht

B3Partners. Beheerhandleiding Datastorelinker 4.2. Gewijzigd: 28 maart 2014. B3Partners BV Bedrijvenpark Lage Weide Zonnebaan 12c 3542 EC Utrecht Beheerhandleiding Datastorelinker 4.2 Gewijzigd: 28 maart 2014 B3Partners B3Partners BV Bedrijvenpark Lage Weide Zonnebaan 12c 3542 EC Utrecht T 030 214 2081 F 030 2411297 E info@b3partners.nl I www.b3partners.nl

Nadere informatie

Handleiding TWYSK Risicotool. Online webapplicatie voor het vastleggen en beheren van risico-informatie

Handleiding TWYSK Risicotool. Online webapplicatie voor het vastleggen en beheren van risico-informatie Handleiding TWYSK Risicotool Online webapplicatie voor het vastleggen en beheren van risico-informatie Handleiding Twysk risicotool De Twysk risicotool is in opdracht van Twynstra Gudde ontwikkeld als

Nadere informatie

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

Nadere informatie

Keteininformatiemodellering op basis van UML

Keteininformatiemodellering op basis van UML Keteininformatiemodellering op basis van UML Richtlijnen en voorbeelden versie 0.1 Bert Dingemans Keteininformatiemodellering op basis van UML... 1 Richtlijnen en voorbeelden... 1 Inleiding... 2 Documenten...

Nadere informatie

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient 9 Samenvatting Software heeft vooruitgang in veel vakgebieden mogelijk gemaakt en heeft een toenemend invloed op ons leven en de samenleving in zijn geheel. Software wordt gebruikt in computers, communicatienetwerken,

Nadere informatie

Project PiggyBank 2014

Project PiggyBank 2014 Project PiggyBank 2014 Auteur Laatst gewijzigd Licentie Webadres Bert Bredewold 23 April 2014 CC Naamsvermelding 3.0 Nederland licentie http://maken.wikiwijs.nl/50661 Dit lesmateriaal is gemaakt met Wikiwijsleermiddelenplein.

Nadere informatie

Uitleg algemene structuur WTell

Uitleg algemene structuur WTell Uitleg algemene structuur WTell Brondocument C:\WebServer\Handleiding\WTellAlgemeen\WTellStructuurGlobaal.odt Versiebeheer Versie Datum Uitleg 1.0v 21-09-11 1e versie met uitleg globale structuur WTell

Nadere informatie

SQL & Relationele datamodellen in interactieve media

SQL & Relationele datamodellen in interactieve media SQL & Relationele datamodellen in interactieve media HVA-CMD-V1-datamodelleren oefeningen deel 1: SQL 2012-2013 Inhoud Inhoud... 2 Selecties uit een enkelvoudige datatabel... 3 Selecties uit een meerdere

Nadere informatie

Application interface. service. Application function / interaction

Application interface. service. Application function / interaction Les 5 Het belangrijkste structurele concept in de applicatielaag is de applicatiecomponent. Dit concept wordt gebruikt om elke structurele entiteit in de applicatielaag te modelleren: softwarecomponenten

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

4orange Connect. 4orange, 2015. Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl

4orange Connect. 4orange, 2015. Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 4orange Connect 4orange, 2015 Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 2 Inhoud Inhoud... 2 1. Achtergrond... 3 2) Browsen... 4 3) Scheduler... 4 4) Frequenties en kruistabellen... 4 5)

Nadere informatie

We moeten de accommodaties selecteren die 3 sterren hebben, en in land met ID 10 zitten.

We moeten de accommodaties selecteren die 3 sterren hebben, en in land met ID 10 zitten. MySQL talk Trage website? Het optimaliseren van een bestaande website die een MySQL database heeft is niet altijd even makkelijk. Het probleem kan namelijk op veel verschillende plekken zitten: de database

Nadere informatie

Dataconversie met Oracle Spatial

Dataconversie met Oracle Spatial Realworld klantendag 19 september 2013 Voorstellen 1 2 Computer Science & Engineering (TU/e) 3 Realworld Systems 4 Datamigraties Alliander Stedin Agenda 1 Architectuur Inleiding Ontwerp migratie 2 Rapportage

Nadere informatie

Bewaren van digitale informatie: hoe kom je tot een goede beslissing?

Bewaren van digitale informatie: hoe kom je tot een goede beslissing? Bewaren van digitale informatie: hoe kom je tot een goede beslissing? Hans Hofman Nationaal Archief Netherlands NCDD Planets dag Den Haag, 14 december 2009 Overzicht Wat is het probleem? Wat is er nodig?

Nadere informatie

Excellerend Kwartaaltip 2015-4

Excellerend Kwartaaltip 2015-4 Draaitabellen IV Excellerend Heemraadweg 21 2741 NC Waddinxveen 06 5115 97 46 richard@excellerend.nl BTW: NL0021459225 BANK: NL72ABNA0536825491 KVK: 24389967 Draaitabel over meerdere tabbladen In de vorige

Nadere informatie