Informatica is het verwerken van informatie. Het beheer van gegevens is dus vaak het eigenlijke doel van een informaticasysteem en is de bestandsorganisatie minstens zo belangrijk dan de eigenlijke programmatuur. Met gegevens bedoelen we hier informatie die voor kortere of langere tijd wordt opgeslagen en die onontbeerlijk is voor de werking van de organisatie/onderneming/…

Een database (of gegevensbank) is een gestructureerde verzameling elektronische gegevens (of data) die door één of meerdere gebruikers (of users) gelijktijdig kunnen gemanipuleerd worden. De enorme hoeveelheden gegevens van banken worden beheerd in ultramoderne databases.

De database zelf, dat zijn dus de geordende gegevens. Maar gegevens zijn pas waardevol als er iets mee gedaan wordt. Het is de taak van een database management system (DBMS) om gegevens op te vragen, aan te passen, enzovoort.

Het DBMS moet er bovendien over waken dat de integriteit van de database behouden blijft. "Waken over integriteit" betekent bijvoorbeeld dat het juiste telefoonnummer bij de juiste persoon blijft horen, dat er geen personen zonder adres in het systeem geplaatst worden,...

Maar het DBMS doet veel meer dan alleen waken over integriteit. Zonder DBMS is het onmogelijk gegevens in een database onder andere te bekijken, te wijzigen, te verwijderen... Alleen het DBMS weet waar en hoe de gegevens in de database verwerkt moeten worden.

Een DBMS zal uiteraard nooit uit zichzelf de gegevens in een database opzoeken, wijzigen of verwijderen. Om dit te doen is steeds een specifieke opdracht van de gebruiker nodig. Bijvoorbeeld: "Verander het telefoonnummer van Jan Claessens van (02) 568 95 65 in (03) 574 23 84".

Dit soort instructie wordt echter niet in een natuurlijke taal gegeven. De meeste DBMS beschikken over een eigen taal voor instructies. Die taal heeft een specifieke "syntax", een stel regels om instructies te ontleden in hun bestanddelen. Deze regels gelijken een beetje op de regels die wij hanteren wanneer we Nederlands spreken. "Ga op die bank zitten" is een verstaanbare opdracht. We kunnen zeggen wat de taak is van elk woordje in deze Nederlandse zin. "Bank daar zitten ga op" is geen geldige zin. We kunnen als mensen nog wel raden naar de betekenis van deze zin, maar hij volgt de regels van de taal niet. Een machine zou het dan ook veel moeilijker hebben om er iets van te maken.

De regels van de talen waarmee men opdrachten kan geven aan een DBMS zijn dus veel strikter dan de regels voor het Nederlands: ze laten geen ruimte voor fouten. Een komma verkeerd volstaat om de opdracht onverstaanbaar en dus onuitvoerbaar te maken.

Voorbeeld 1

Een klassiek voorbeeld daarvan is een lijst met de namen en adressen. Die lijst kan er als volgt uitzien:

In bovenstaand voorbeeld is de eerste rij de aanduiding van de kolommen (veldnamen).

Bovenstaand voorbeeld bevat dus vijf rijen (records) die telkens bepaalde waarden bevatten, hier gaat het over de "Naam", "Voornaam", "Adres", "Postcode", "Gemeente", "Telefoon" en "Verdieping".

Voorbeeld 2

Een bedrijf in de productiesector zal onder andere volgende gegevens willen bijhouden, nl.:

• Personeelsgegevens

• De zgn. productiegegevens. Hierbij kunnen we denken aan bv. de productsamenstelling

• De gegevens betreffende de noodzakelijke bestellingen

• De gegevens van de bestaande klanten

• De gegevens van de leveranciers

• De gegevens m.b.t. de goederen die nog in stock zijn en/of de goederen die besteld moeten worden

In dit geval is het best om voor elk bullet point een aparte tabel te voorzien. Groepjes gegevens die sterk aan elkaar gelinkt zijn (bijvoorbeeld "voornaam werknemer" en "familienaam werknemer" komen in dezelfde tabel). Groepjes gegevens die losser gelinkt zijn komen in verschillende tabellen. Er zijn nog andere redenen om verschillende tabellen te gebruiken. Die komen later.

Voorbeeld 3

Een bank houdt per rekening van een bepaalde klant geen box bij met daarin het geld van een klant. Het bedrag op de rekening van die klant is een cijfer dat wordt bijgehouden in een database. Er zou bijvoorbeeld een tabel Rekeningen kunnen zijn, die je je zo kan voorstellen:

Daarnaast heeft de bank nog allerlei informatie, bijvoorbeeld over hypotheken,... Die zullen vermoedelijk in andere tabellen staan. De volledige verzameling tabellen vormt de database van de bank.

De "relationele" database is waarschijnlijk de meestgebruikte soort database. Dit type database is uitgewerkt in de jaren 1970 en steunt op de wiskundige verzamelingenleer.

Zonder deze wiskundige fundering in veel detail te behandelen: het basisidee is dat "interessante gehelen" van informatie in verzamelingen van één soort data worden opgedeeld. Tussen deze verzamelingen bestaan verbanden.

Onderstaande figuur illustreert dit. Op deze figuur zijn de interessante gehelen personen en boeken. Deze twee verzamelingen bestaan los van elkaar, maar er is een verband: sommige personen hebben sommige boeken gelezen.

Er kunnen veel verbanden zijn. We kunnen bijvoorbeeld een tweede verband hebben dat uitdrukt dat een bepaalde persoon een bepaald boek heeft geschreven:

Om dit in een elektronisch systeem voor te stellen, maken we geen tekeningen, maar gebruiken we tabellen. We doen dit zowel voor de "interessante gehelen" (dus de elementen van de verzamelingen) als voor de verbanden tussen elementen van deze verzamelingen.

Voor de eerste tekening zou een tabelvoorstelling van de verzamelingen er zo kunnen uitzien:

Ook het verband zou kunnen worden uitgedrukt met een tabel. Hoe dat precies werkt is voor iets verder, maar een vereenvoudiging die een goed beeld geeft is als volgt:

Zowat alle DBMS'en voor relationele databases spreken (ongeveer) dezelfde taal: de "Structured Query Language" of SQL. Deze taal is ook gebaseerd op de relationele algebra's en ze maakt dat je vrij snel kan leren werken met één relationele database als je al met een andere relationele database overweg kan. Elk DBMS spreekt wel een eigen "dialect" van SQL, dus je kan niet verwachten dat code voor bijvoorbeeld PostgreSQL (een type relationele database) letterlijk kan worden uitgevoerd in SQLite (een ander type relationele database). Maar normaal moet je er niet veel aan aanpassen.

Typisch voor relationele databases is dat je op voorhand moet vastleggen wat de structuur van je database is: welke tabellen er zijn en wat voor gegevens hier in mogen worden geplaatst. Deze structuur noemen we het "schema". Als je nieuwe gegevens wil bijhouden die niet passen binnen de structuur, moet je eerst de structuur aanpassen. Dit is niet bij alle soorten databanken zo. Andere types databanken hebben soms een heel losse structuur. Dit geeft hen soms meer flexibiliteit, maar zorgt er soms ook voor dat ze minder kunnen waken over de integriteit van hun gegevens.

De basiswoordenschat van relationele databanken is als volgt:

• entiteittypes: de verzamelingen van interessante gehelen waarover we informatie bijhouden. Op de figuur onderaan is dit bijvoorbeeld de hele verzameling met personen of de hele verzameling met boeken.

• entiteiten: de elementen van de verzameling. Elke persoon in de linkse verzameling, bijvoorbeeld William Shakespeare, is een entiteit. Elke persoon en elk boek is een entiteit.

• relatietypes: een soort verband tussen verzamelingen. Op de figuur is "heeft gelezen" een relatietype.

• relaties: een concreet verband tussen entiteiten. Op de figuur is bv. "Michiel heeft The Tempest gelezen" een relatie.

• tabellen: de structuur waarin een volledig entiteittype of een relatietype wordt opgeslagen. Deze tabel heeft steeds een naam, of tabelnaam.

• records: een tabel bestaat uit rijen of records. Eén record bevat alle gegevens van de rij en stelt dus één entiteit voor.

• kolommen (of "velden"): iedere kolom omvat één aanduiding van een gegeven binnen een tabel. Iedere kolom heeft een unieke naam.

Ter herinnering, de verzameling met personen stelden we zo voor:

Om een beter overzicht van het databaseschema te krijgen, maken we vaak gebruik van een diagram. Dit wordt een entity-relationship diagram (of "ERD") genoemd. Dit lijkt wat op de verzamelingennotatie die we eerder zagen, maar werkt op een ander niveau.

Neem volgend voorbeeld:

Dit zegt volgende zaken:

Exhalation is het lievelingsboek van Vincent
The Tempest is het lievelingsboek van Michiel
Never Let Me Go is het lievelingsboek van Esther

In het algemeen kunnen we dus stellen: personen hebben een lievelingsboek. Als we verder vastleggen dat personen altijd exact één lievelingsboek hebben, kunnen we dit grafisch uitdrukken als volgt:

Hier staat niets over Vincent, Esther of Michiel. Maar er staat dat er een relatietype is dat personen en boeken verbindt. De exacte betekenis van de getallen, de icoontjes en de stippellijn laten we voor iets later, maar onthoud alvast dat de rechthoeken de entiteiten voorstellen (met hun kolommen) en de ruiten relaties.

Let op: er zijn veel stijlen van notatie voor het entity-relationship diagram. Wij hebben dit met MySQL Workbench getekend door eerst volgende knop te gebruiken:

Daarna hebben we de plusknop gebruikt en op "Add diagram" geklikt.

Ten slotte hebben we via de menuknop "Model" gekozen voor "Object Notation" → "Workbench (Simplified)" en voor "Relationship Notation" → "Classic". Dit is ook de afspraak die we zullen hanteren voor de rest van de cursus.

Als je een ERD tegenkomt op het internet, ga dan eerst na welke notatie gebruikt is. Anders kan je niet weten wat het ERD precies voorstelt.