Inleiding tot databases

Inleiding

In een klein bedrijf zijn de netwerkbeheerders of ontwikkelaars ook databasebeheerders, ook wel bekend onder de engelste term Database Administrator (DBA). In grotere bedrijven kunnen er tientallen DBA’s zijn die gespecialiseerd zijn in de vele verschillende aspecten, van ontwerp en architectuur tot onderhoud, ontwikkeling enzovoort. In welke IT-sector je ook werkt, je zult op een bepaald moment gegevens moeten opslaan, en het kan voor vrijwel iedereen geen kwaad iets te weten over databases en hoe ze werken.

Het doel van deze tutorial is die basisintroductie te geven. We leggen de basis uit van wat een database eigenlijk is, kijken naar de geschiedenis, begrijpen relationele databases, behandelen enkele basisconcepten van kolommen en rijen, behandelen andere soorten databases, maken ons vertrouwd met enkele aanvullende concepten en sluiten af met een kort overzicht van de belangrijkste commerciële systemen die momenteel op de markt zijn.

Behalve elementaire computervaardigheden zijn voor deze tutorial geen andere vereisten nodig.

Wat is een database?

Een database is over het algemeen een georganiseerde verzameling van gegevens. Meer in het bijzonder is een database een elektronisch systeem waarmee gegevens gemakkelijk kunnen worden geraadpleegd, bewerkt en bijgewerkt.

Met andere woorden, een database wordt door een organisatie gebruikt als een elektronisch middel om informatie op te slaan, te beheren en op te vragen. De database is een van de hoekstenen van de bedrijfs-IT, en haar vermogen om informatie op een gestructureerde en gecontroleerde manier te organiseren, te verwerken en te beheren is essentieel voor veel aspecten van de moderne bedrijfsefficiëntie.

Databases gaan echter veel verder dan alleen de opslag van gegevens. Zoals we later zullen zien, kunnen de inherente logica en efficiëntie waarmee gegevens worden opgeslagen en opgehaald een ongelooflijk krachtig bedrijfsinstrument zijn voor een organisatie. Dit geldt vooral wanneer databases goed worden gebruikt voor rapportage en business intelligence functies.

Het gebruik en het belang van databases in de wereld van vandaag

Dus welk soort bedrijf heeft een database nodig en kan profiteren van het gebruik ervan? Nou, het korte antwoord is: elk bedrijf of organisatie die een groot aantal klanten of producten moet beheren. Met “groot” bedoelen we meer dan een menselijk brein kan opslaan – veel meer.

Sceptici kunnen hier nog tegenin brengen dat er talloze kleine winkels zijn waarvan de eigenaren hun voorraad en winst/verlies bijhouden met behulp van het vertrouwde grootboek en de rekenmachine en daar prima mee uit de voeten kunnen. Dit is waar, maar het gebruik van een elektronische database kan zelfs voor zeer kleine bedrijven de moeite waard zijn. Een grootboek kan bijvoorbeeld geen simulatie uitvoeren om de winst te extrapoleren wanneer de winkel de prijs van pennen met 2 cent verhoogt. Een database kan dat wel. Het grootboek kan geen rapport opstellen met een lijst van nabestellingen voor alle artikelen om de ondernemer te laten zien welke artikelen in welke periode van het jaar moeten worden nabesteld. Een database kan dat ook. Een database kan de winkeleigenaar zelfs automatisch per e-mail of sms op de hoogte brengen.

Het grootste gebruik van databases blijft echter beperkt tot grote organisaties met honderdduizenden, miljoenen of tientallen miljoenen klanten en producten die een grote hoeveelheid individuele gegevens van hun klanten moeten opslaan. Een commerciële bank bijvoorbeeld heeft de persoonlijke gegevens nodig van al haar miljoenen klanten, zoals naam, geboortedatum, adres, nationaal verzekeringsnummer, enz. Elke klant genereert op zijn beurt een andere verzameling gegevens, afhankelijk van de producten waarvoor hij zich heeft ingeschreven, zoals rekeningtype, rekeningnummer, rekeningsaldo, hypotheekbedrag, kredietkaartlening, aflossingstermijn, enz. Een derde reeks gegevens heeft betrekking op de specifieke transacties van de klant, bv. tijdstip van de transactie, bedrag, saldo, bankkosten, nog af te lossen bedrag van de lening, enz.

Het is duidelijk dat één enkele klant in zeer korte tijd een enorme hoeveelheid gegevens kan genereren. Vermenigvuldig dit met miljoenen klanten en het wordt al snel duidelijk waarom efficiënte gegevensopslag en -ontsluiting niet alleen een goed idee is, maar absoluut noodzakelijk om te voorkomen dat databaseoperaties tot stilstand komen.

Maar wacht. Voor de komst van computers en deze nieuwerwetse databases, deden bedrijven het prima, toch? Natuurlijk. Maar als je nog steeds niet overtuigd bent van de kracht van databases vanwege hun vermogen om efficiëntie en transactiesnelheid te verhogen, bedenk dan dit: Jouw concurrenten zijn efficiënter en bieden betere service dan jij omdat zij databasesystemen gebruiken.

Commerciële banken zijn een uitstekend voorbeeld van het gebruik van databases in moderne bedrijven. Andere industrieën die sterk afhankelijk zijn van databases zijn verzekeringen, ziekenhuizen en gezondheidszorg, scholen en universiteiten, productie, telecommunicatie, en hotels en horeca.

Databases zijn inderdaad wat de term zegt – de basis of pool van (gerelateerde) gegevens waarop de datasystemen van een bedrijf moeten worden gebouwd. Het is niet overdreven te stellen dat zonder databases de computer op de werkplek weinig meer zou zijn dan een efficiëntere typemachine!

Geschiedenis van databases

Het is belangrijk om eerst te beseffen dat de georganiseerde, systematische methode voor het opslaan van gegevens zoals wij die kennen en gebruiken in databases, geen recente uitvinding is. Wat wel nieuw is, is de automatisering van deze methode sinds de jaren zestig. Merk op dat ook papieren dossiers, inclusief boekhoudkundige dossiers, (technisch) alle vormen van een database zijn. Dat wil zeggen dat een database niet per se geautomatiseerd hoeft te zijn. Informatisering heeft alleen een database management systeem (DBMS) opgeleverd, dat uiteraard ordes van grootte krachtiger, nauwkeuriger en capabeler is dan wat een eenvoudig grootboek of nietige menselijke hersenen kunnen doen. En hoewel wij gewoonlijk de term “database” gebruiken in verband met het DBMS, zijn de twee niet hetzelfde; alle duimen (DBMS) zijn vingers (databases), maar niet alle vingers zijn duimen.

De oude Egyptenaren gebruikten geavanceerde systemen om de graanoogsten bij te houden. De Bibliotheek van Alexandrië gebruikte een geavanceerde methode om grote aantallen boeken en rollen te beheren. Dit waren allemaal vroege voorbeelden van databases, hoewel hun mogelijkheden natuurlijk lachwekkend zouden zijn in vergelijking met de enorm krachtige geautomatiseerde DBMS’en van de 21e eeuw.

Maar zelfs toen, toen alle computertechnologie zich nog in het eencellige stadium bevond (in de jaren zestig), konden veel mensen zich voorstellen dat computers echt nuttig zouden zijn als ze een manier konden bieden om gegevens betrouwbaar op te slaan en op te vragen. De ontwikkeling van databases ging dan ook vrijwel gelijk op met de algemene ontwikkeling en groei van de computercapaciteit in die tijd. De computer werd een opslagapparaat. Naarmate de capaciteit van de harde schijf en de processorsnelheid toenamen, namen ook de opslagcapaciteit en het aantal functies van de hedendaagse databasestoe. Een belangrijke stap in het midden van de jaren zestig was de omschakeling van bandopslag naar willekeurig toegankelijk geheugen of harde schijven. Deze omschakeling maakte interactieve gegevenstoegang met meerdere bewerkingen mogelijk, in tegenstelling tot de voor tapes vereiste batchverwerking met één operator.

De eerste databasesystemen waren navigatief van aard. Dit betekent dat toepassingen gegevens verwerkten en lazen met behulp van pointers die in de gegevens zelf waren ingebed. De pointer leidde naar het volgende gegevenselement en kon dubbel worden gelinkt, zodat een link naar zowel het vorige als het volgende gegevenselement mogelijk was. Dit is vergelijkbaar met de manier waarop hyperlinks werken op een webpagina, waarbij de lezer van de huidige pagina naar een verwante webpagina wordt geleid. De twee belangrijkste gegevensmodellen in die tijd waren het hiërarchische model, belichaamd door IBM’s IMS-systeem, en het codasyl- of netwerkmodel. Maar al deze modellen werden achterhaald door de ontwikkeling van het relationele model door de briljante computerwetenschapper E.F. Codd, en verwezen naar interessante voetnoten in de geschiedenis.

E.F. Codd en het relationele model

Het relationele model was een radicale afwijking van het heersende hiërarchische model, omdat het gericht was op de mogelijkheid een database te doorzoeken op inhoud in plaats van een gekoppeld navigatiesysteem te volgen. Dit bood het grote voordeel dat databases konden groeien en steeds meer gegevens konden opslaan zonder dat de toepassingen die toegang hadden tot die gegevens moesten worden veranderd of herschreven. In wezen vond Codd in zijn eentje een manier om het skelet of de structuur van de database te scheiden van de in de database opgeslagen records. Dit model was zo elegant dat het vandaag de dag nog steeds de de facto standaard is voor databaseontwerp, waarbij dergelijke databases relationele databases worden genoemd. Er zijn enkele zeer belangrijke niet-relationele databases (vooral met de komst van Big Data en Web 2.0), maar het relationele model wordt nog steeds gebruikt voor het overgrote deel van het commerciële database-aanbod.

Tegenwoordig zou de naam E.F. Codd bij de meeste mensen een terloops “E.F. wie?” oproepen, zelfs bij velen in de IT-industrie. Zijn werk heeft echter rechtstreeks geleid tot de enorme voordelen en efficiëntie van relationele databases. Zijn bijdrage aan de wereld van computers is vergelijkbaar met die van Sir Isaac Newton aan de natuurkunde.

Codd bezocht het Oxford College en studeerde wiskunde en scheikunde. Tijdens de Tweede Wereldoorlog werkte hij als piloot bij de Royal Air Force voordat hij in 1948 naar de VS verhuisde om als wiskundig programmeur voor IBM te werken. Na een decennium in Canada keerde hij in 1963 terug naar de VS en promoveerde in 1965.

In 1970 publiceerde Codd voor IBM een paper over gegevensbeheer, getiteld “A Relational Model of Data for Large Shared Data Banks”. Het enorme bedrijf had echter zwaar geïnvesteerd in het hiërarchische model via zijn Information Management System (IMS), en de leidinggevenden van Big Blue waren niet geïnteresseerd in de ontwikkeling van een concurrent voor een van hun eigen lucratieve productlijnen. Met een sluwheid die academici of wetenschappers zelden vertonen, toonde Codd zijn model in het geheim aan geselecteerde IBM-klanten, die nauwelijks overtuigd hoefden te worden van de superioriteit ervan. De invloedrijke klanten oefenden op hun beurt druk uit op diezelfde IBM-managers om het model te ontwikkelen, en met tegenzin (en, zoals men zich kan voorstellen, met stille woede op Codd) stopten zij het model in IBM’s Future Systems-project, waarbij het systeem zelf bekend werd als System R.

De bazen wilden IMS echter nog steeds niet bedreigen en saboteerden het werk van Codd door het System R-project in handen te geven van ontwikkelaars die er niet mee vertrouwd waren. De ontwikkelaars gebruikten dus niet Codd’s eigen alfataal voor de ontwikkeling, maar een veel eenvoudigere taal genaamd SEQUEL. Dit bleek echter een geluk bij een ongeluk, want SEQUEL is veel gemakkelijker te begrijpen en te gebruiken. Om auteursrechtelijke redenen werd de naam veranderd in SQL en is nu zeer bekend bij database-ontwikkelaars en -beheerders als de taal bij uitstek voor het schrijven van database-queries.

Een slimme jonge zakenman die zijn eigen databasesysteem aan het ontwikkelen was, las over SQL op een conferentie in 1979. Hij zag de superioriteit ervan in en kopieerde de taal in een databaseproduct voor zijn eigen kleine bedrijf. De zakenman had eerder ook Codd’s werk over het relationele model gezien en was ervan overtuigd dat dit de weg was voor databasesystemen. Hij bouwde zijn eigen product erop, ook al weigerde IBM de code van System R met hem te delen. En bedenkt je dan; IBM was niet geïnteresseerd in het relationele model. Het kleine bedrijf werd behoorlijk groot; tegenwoordig staat het bekend als Oracle Corp. De zakenman heet Larry Ellison, en zijn overtuiging heeft hem tot één van de rijkste mensen ter wereld gemaakt. Hieruit blijkt hoezeer IBM het potentieel van Codd’s relationele model verkeerd heeft ingeschat. In feite is Oracle DB tegenwoordig de meest gebruikte relationele database voor bedrijven.

De relationele database (RDBMS)

Zoals we al hebben gezien, heeft het werk van E.F. Codd het relationele model van databases gevestigd als de duidelijk superieure methode van gegevensopslag. De elegantie van het relationele model bij het opslaan en manipuleren van gegevens is zo effectief geweest dat sinds het eind van de jaren zeventig geen van de vele troonpretendenten erin is geslaagd het omver te werpen.

Laten we eens goed kijken hoe het relationele model werkt. Een relationele database is in wezen een verzameling tabellen of, om de technische benaming te gebruiken, entiteiten (zie regels 0 en 1 in Codd’s 12 regels voor relationele databases). Elke tabel bestaat uit rijen (tuples) en kolommen (attributen). Er bestaan relaties tussen tabellen, gedefinieerd door het feit dat een bepaalde kolom in de ene tabel verwijst naar een kolom in een andere tabel.

Dit is de basisdefinitie van een relationele database. Maar zoals je straks zult zien, kan het veel ingewikkelder worden. Een van de basisconcepten van relationele databases is bijvoorbeeld dat van referentiële integriteit. Deze regel stelt dat relaties tussen tabellen altijd consistent moeten blijven. Met andere woorden, elk veld in een vreemde sleutel moet overeenkomen met de primaire sleutel waar de vreemde sleutel naar verwijst. Daarom moeten alle updates of verwijderingen van een veld met een primaire sleutel ook worden toegepast op al zijn vreemde sleutels, of niet plaatsvinden. Dezelfde beperking geldt voor foreign keys; alle updates (maar niet noodzakelijkerwijs verwijderingen) moeten ofwel ook worden toegepast op de corresponderende primaire sleutel of zijn niet toegestaan.

Het idee van referentiële integriteit wordt het best uitgelegd met een illustratie. Stel dat er in de database van een bank twee tabellen zijn: de tabel CUSTOMER_MASTER, waarin de basisgegevens van klanten/rekeninghouders worden opgeslagen, en de tabel ACCOUNTS_MASTER, waarin de basisgegevens van bankrekeningen worden opgeslagen. Om elke klant/rekeninghouder in de tabel CUSTOMER_MASTER uniek te identificeren, maken we een primaire-sleutelkolom genaamd CUSTOMER_ID.

Je ziet dat wij, om de klant te identificeren waartoe een bepaalde bankrekening behoort in de tabel ACCOUNTS_MASTER, moeten verwijzen naar een bestaande klant in de tabel CUSTOMER_MASTER. Dit betekent dat we ook een kolom CUSTOMER_ID moeten aanmaken in de tabel ACCOUNTS_MASTER. Dit wordt een foreign key genoemd. Deze kolom is bijzonder omdat de waarden die hij bevat geen nieuwe waarden zijn die je zomaar tevoorschijn kunt toveren. Ze moeten verwijzen naar identieke, bestaande waarden in de primaire-sleutelkolom van een andere tabel, in dit geval de kolom CUSTOMER_ID van de tabel CUSTOMER_MASTER.

Duidelijk tot nu toe? Goed. Nu betekent referentiële integriteit simpelweg dat je een CUSTOMER_ID waarde in CUSTOMER_MASTER niet kunt wijzigen zonder ook de corresponderende waarde in de ACCOUNTS_MASTER tabel te wijzigen. Als je de klant-ID van Andrew Smith wijzigt in CUSTOMER_MASTER, moet je die ook wijzigen in ACCOUNTS_MASTER. Dit is volkomen logisch als je erover nadenkt. Hoe kunnen we anders de rekeningen van Andrew Smith aan hem koppelen? Vergeet niet dat de tabel ACCOUNTS_MASTER geen informatie bevat over de rekeninghouders, behalve dat hun CUSTOMER_ID’s worden opgeslagen als foreign keys. Volgens dezelfde logica, als een klant-ID in de tabel Bankrekeningen mag bestaan zonder een corresponderend klant-ID in de tabel CUSTOMERS_MASTER, betekent dit meestal dat een bankrekening kan bestaan zonder rekeninghouder, wat natuurlijk nergens op slaat.

Als je deze gedachtengang wat verder volgt, moet u, als je een klant-ID in CUSTOMER_MASTER verwijdert, ook alle overeenkomstige vermeldingen in ACCOUNTS_MASTER verwijderen. Dit is gewoon de manifestatie van een schone vervolgactie in het echte leven: Als iemand geen klant meer is, moet je ook zijn bankrekeningen verwijderen.

De 12 regels van relationele databases

Toen het relationele model begin jaren tachtig in zwang kwam voor databaseontwerp, was Codd eerst verward en vervolgens geërgerd door de neiging van alle andere databaseverkopers om hun producten de relationele naam op te dringen, zelfs als die niet van toepassing was. Hij stelde een lijst van 12 regels op die hij gebruikte om te bepalen of een database “relationeel” kon worden genoemd. Zijn moeilijkheden met IBM bereikten in deze periode een hoogtepunt, en hij vertrok om zijn eigen adviesbureau te beginnen met een andere docent/consultant genaamd Chris Date.

Hieronder staan Codd’s 12 regels of, zoals sommigen ze noemen, 12 geboden. Eigenlijk zijn het er 13, maar ze zijn genummerd van 0 tot 12, vandaar de naam. We zullen ze meer in detail bekijken wanneer we de kenmerken van relationele databases bekijken, en er dan naar verwijzen zodat je Codd’s regels echt in hun context kunt begrijpen. In ruwe vorm hebben deze regels niet veel zin voor wie niet in een database werkt, maar goed, hier gaan we dan:

0. Basisregel
Een relationeel databasemanagementsysteem moet zijn opgeslagen gegevens beheren met alleen zijn relationele mogelijkheden.

1. Informatie regel
Alle informatie in de database moet op één en slechts één manier worden weergegeven – als waarden in een tabel.

2. Regel voor gegarandeerde toegang
Elk gegeven (atoomwaarde) is gegarandeerd logisch toegankelijk door toegang tot een combinatie van tabelnaam, primaire-sleutelwaarde en kolomnaam.

3. Systematische behandeling van nulwaarden
Nulwaarden (die verschillen van lege strings, spaties, nullen of andere getallen) worden ondersteund in het volledig relationele DBMS om ontbrekende informatie systematisch weer te geven, ongeacht het gegevenstype.

4. Dynamische online catalogus op basis van het relationele model.
De database beschrijving wordt op logisch niveau op dezelfde wijze gerepresenteerd als gewone gegevens, zodat bevoegde gebruikers dezelfde relationele taal kunnen gebruiken voor zoekopdrachten als voor gewone gegevens.

5. Uitgebreide sublanguage-regel voor gegevens
Een relationeel systeem kan meerdere talen en verschillende soorten eindgebruik ondersteunen. Er moet echter ten minste één taal zijn waarvan de verklaringen kunnen worden uitgedrukt als strings volgens een welomschreven syntaxis en waarvan het vermogen om al het volgende te ondersteunen traceerbaar is:

Definitie van gegevens
Definitie van weergaven
Gegevensmanipulatie (interactief en programmatisch)
Integriteitsbeperkingen
Autorisatie
Transactielimieten (starten, vastleggen en terugdraaien)

7. Regel voor het bijwerken van views
Alle views die theoretisch kunnen worden bijgewerkt, kunnen ook door het systeem worden bijgewerkt.

8. Invoegen, bijwerken en verwijderen op hoog niveau
De mogelijkheid om een basisrelatie of een afgeleide relatie als één operand te behandelen geldt niet alleen voor het opvragen van gegevens, maar ook voor het invoegen, bijwerken en verwijderen van gegevens.

8. Onafhankelijkheid van fysieke gegevens
Toepassingsprogramma’s en terminalactiviteiten blijven logisch onaangetast wanneer wijzigingen worden aangebracht in de geheugenrepresentatie of de toegangsmethoden.

9. Onafhankelijkheid van logische gegevens
Toepassingsprogramma’s en eindactiviteiten blijven logisch onaangetast wanneer wijzigingen in informatie van welke aard ook – en wijzigingen die in theorie degradatie mogelijk maken – in de basistabellen worden aangebracht.

10. Integriteitsonafhankelijkheid
Integriteitsbeperkingen die specifiek zijn voor een bepaalde relationele gegevensbank moeten kunnen worden gedefinieerd in de relationele gegevenssubtaal en worden opgeslagen in de catalogus, niet in de toepassingsprogramma’s.

11. Onafhankelijkheid van distributie
De sublanguage voor gegevensmanipulatie van een relationeel DBMS moet het mogelijk maken dat toepassingsprogramma’s en terminalactiviteiten logisch onaangetast blijven, ongeacht of de gegevens fysiek gecentraliseerd of gedistribueerd zijn.

12. Nonsubversion Rule
Als een relationeel systeem een taal op een lager niveau (één record per tijdseenheid) heeft of ondersteunt, kan die taal op een lager niveau niet worden gebruikt om de integriteitsregels of -beperkingen die in de relationele taal op een hoger niveau (meerdere records per tijdseenheid) zijn uitgedrukt, te ondermijnen of te omzeilen.

Elementaire databaseconcepten

In het volgende zullen we enkele belangrijke databaseconcepten en gegevensobjecten bekijken. Elke zichzelf respecterende databasebeheerder moet hiermee absoluut vertrouwd zijn. En ze zijn niet alleen theoretisch; vrijwel alle DBA’s hebben bijna dagelijks met deze concepten en objecten te maken. Ze zijn voor databasebeheer wat kennis van het menselijk lichaam is voor de geneeskunde.

We zullen elk concept hier slechts kort definiëren. Om de concepten beter te begrijpen, volg je de term links en bezoek je de sectie Gerelateerde termen om te begrijpen hoe elk concept verband houdt met en samenwerkt met andere concepten op het gebied van databasebeheer.

Tabellen

De tabel is de basiseenheid van gegevensopslag in een relationele database. Tabellen bestaan uit kolommen en rijen. De kolommen zijn de attributen of eigenschappen die we willen uitdrukken, terwijl de rijen de eigenlijke gegevens bevatten, met één (of geen) element per rij. Denk aan de lay-out van een spreadsheet; deze lijkt sterk op de logische organisatie van een relationele tabel.

Hieronder staat een eenvoudig voorbeeld van de tabellen in de database van een commerciële bank.

Relaties

Relaties zijn DE reden waarom relationele databases zo goed werken. Als je maar één concept over databases leert, dan is dit het wel. Zoals de naam al aangeeft, vormen relaties de kern van relationele databases.

In relationele databases bestaat een relatie tussen twee tabellen als een van de tabellen een foreign key heeft die verwijst naar de primary key van de andere tabel. (Binnenkort meer over foreign en primary keys).

In het onderstaande diagram zie je voorbeelden van relaties. Bijvoorbeeld, het veld (kolom) AccountTypeID in de tabel AccountTypes verwijst naar de kolom AccountTypeID in de tabel Klant.

Rij

Een rij, ook wel record genoemd, vertegenwoordigt een reeks gegevens over een bepaald item. Elk record in een tabel heeft precies dezelfde structuur, maar natuurlijk verschillende gegevens. Denk aan de rijen in een Excel-spreadsheet – het concept van rijen in een database is zeer vergelijkbaar. Elke rij in een tabel bestaat uit verschillende gegevensitems, met één (of nul) items voor elke kolom in de tabel. Rijen worden ook wel tuples genoemd, hoewel deze term niet erg gebruikelijk is.

Kolom

Een kolom is een specifieke reeks waarden in een tabel van hetzelfde type. Het definieert een bepaald attribuut van de tabel of gegevens. We kunnen bijvoorbeeld een kolom genaamd CUSTOMER_SURNAME aanmaken in een tabel. Dit is een voor zichzelf sprekende kolom die tot doel heeft achternamen van klanten op te slaan, één waarde voor elke rij. Nogmaals, denk aan de rijen in een Excel-spreadsheet en  hebt een vrij goed idee van hoe kolommen werken in een relationele tabel.

Primaire sleutel

Een primaire sleutel (ook wel bekend als primary key) is een speciale kolom of combinatie van kolommen die elke record (rij) in de tabel uniek identificeert. De primaire-sleutelkolom moet uniek zijn voor elke rij en mag geen nullen (niet-waarden) bevatten.

De primaire sleutel, samen met het nauw verwante concept van de vreemde sleutel, is de primaire methode om relaties te definiëren. Primaire sleutels kunnen ook bestaan uit een combinatie van kolommen. Zo is een kalendermaand voor veel bedrijven een financiële periode op korte termijn. Daarom kunt u, om een periode uniek te identificeren, de maandkolom en de jaarkolom combineren, bijvoorbeeld mei 2011, om een primaire sleutel te creëren die elke financiële periode uniek identificeert.

Vreemde sleutel

We kunnen het niet hebben over de yin van primaire sleutels zonder de yang van vreemde sleutels (foreign key) te vermelden. De twee gaan hand in hand. Een primaire sleutel definieert op unieke wijze een record, terwijl een vreemde sleutel wordt gebruikt om te verwijzen naar hetzelfde record in een andere tabel.

Stel, in de database van een commerciële bank is er een kolom CUSTOMER_ID als primaire sleutel in de tabel CUSTOMER_MASTER. Deze identificeert elke klant op unieke wijze. Laten we verder aannemen dat dezelfde tabel ook andere relevante klantinformatie bevat in andere kolommen, zoals CUSTOMER_NAME, FIRST NAME, SOCIAL NUMBER, CUSTOMER, CUSTOMER_COUNTRY, enz.

We hebben ook nog een andere tabel, LOANS_MASTER, waarin we de leningen opnemen die aan de klanten van dezelfde bank zijn verstrekt. In deze tabel hebben we nog slechts één kolom nodig om aan te geven welke klant een bepaalde lening heeft ontvangen. We kunnen deze kolom CUSTOMERID noemen, en hij verwijst naar de kolom CUSTOMER_ID in de tabel CUSTOMER_MASTER. We hoeven niet alle andere klantgegevens (naam, geslacht, nationaal verzekeringsnummer, enz.) op te slaan in de leningentabel. Dit is de elegantie van het relationele model.

SQL

Structured Query Language (SQL) is de gemeenschappelijke taal voor het beheren en manipuleren van gegevens in relationele databases. SQL kan worden gebruikt voor het bevragen, invoegen, bijwerken en wijzigen van gegevens. Alle grote relationele databases ondersteunen SQL, wat het leven van databasebeheerders (DBA’s) die databases op verschillende platforms moeten onderhouden, een stuk gemakkelijker maakt. Het beheersen van SQL is meestal een van de eerste dingen die een DBA aan het begin van zijn carrière moet leren. Merk op dat sommige mensen SQL als één woord uitspreken, in het Duits “Folge”.

Merk op dat de SQL-taal verschilt van SQL Server, een relationeel databaseplatform van Microsoft. Het gebruik van de algemene term SQL kan verwarrend zijn voor beginners.

De meeste commerciële RDBMS-platforms hebben hun eigen aangepaste SQL-implementaties, maar die zijn meestal volledig compatibel met standaard SQL.

Andere soorten databases

Databases vs. spreadsheets

“Excel slaat mijn gegevens ook op, en ik kan ze opvragen en bewerken met behulp van filters, ze koppelen aan andere bestanden en spreadsheets, en geavanceerde functies uitvoeren zoals VLOOKUP, PivotTable, enz. Dus waarom heb ik die mooie database nodig waar jullie het over hebben? Jullie IT-ers proberen me gewoon geld afhandig te maken. Nee, mijn Excel spreadsheets voldoen prima!”

Klinkt dat bekend? Misschien wel, als je ooit hebt gewerkt als database consultant voor kleine bedrijven. Op het eerste gezicht lijkt het alsof veel van de functies die databases bieden veel gemakkelijker (en goedkoper!) met spreadsheets kunnen worden bereikt. Spreadsheets hebben echter een aantal beperkingen die ze ongeschikt maken voor het beheer van bepaalde gegevens:

• Spreadsheets zijn over het algemeen niet geschikt voor toegang voor meerdere gebruikers. Als je in een bedrijf werkt waar gedeelde bestanden worden gebruikt, ben je waarschijnlijk wel eens de vervelende foutmelding “bestand is vergrendeld door een andere gebruiker” tegengekomen. Zelfs als een bepaald type spreadsheet enige multi-user functionaliteit heeft, is deze relatief beperkt. Databases daarentegen kunnen perfect omgaan met multi-user toegang, zelfs met een mix van lees- en schrijftoegang voor dezelfde gegevens.
• Spreadsheets bieden slechte gegevensvalidatie en -integriteit. Er is weinig dat voorkomt dat een van jouw gebruikers de gegevens in een Excel-bestand volledig verwijdert. Natuurlijk kun je wachtwoorden gebruiken voor spreadsheets, maar deze bieden slechts een zeer beperkt beveiligingsniveau en kunnen niet voorkomen dat iemand het hele bestand verwijdert. Databases kunnen een fijnmazige beveiliging bieden en gebruikers zelfs beschermen tegen hun eigen fouten. Een databasetoepassing kan bijvoorbeeld gemakkelijk zo worden ingesteld dat bij het aanmaken van een cliënt ook het nationale verzekeringsnummer moet worden ingevoerd.
• Query’s en rapporten zijn een functie waar spreadsheets niet goed in zijn. De mogelijkheid om queries uit te voeren op een record is uiterst nuttig. Toegegeven, spreadsheets bieden enkele rudimentaire mogelijkheden voor het genereren van rapporten via filters en grafieken, maar ze vergelijken met SQL-queries in databases, die meerdere tabellen kunnen verbinden en complexe bewerkingen kunnen uitvoeren, is als het vergelijken van de auto van Fred Flinstone met een gloednieuwe Mercedes S-Klasse, het toppunt van autotechniek.
• Computermiddelen worden overbelast door het verwerken van grote spreadsheets. Databases kunnen moeiteloos gegevens in de orde van grootte van miljoenen rijen, georganiseerd in honderden tabellen, opslaan en raadplegen, en dit alles op een eenvoudige server, zonder dat jij je zorgen hoeft te maken. Probeer het aantal rijen in jouw Excel-bestand te verhogen tot honderdduizenden rijen en kijk wat er gebeurt met de reactietijd van jouw computer.

Tabelberekeningen zijn veel eenvoudiger te maken en te onderhouden. Databases vereisen meer investeringen, zowel financieel als qua opleiding van medewerkers. De beloning daarvoor is echter een veel robuuster en veiliger systeem voor het opslaan en opvragen van gegevens.

Het moment waarop je zou moeten overstappen van spreadsheets naar een op een database gebaseerd systeem is wanneer je een of meer van de volgende vragen met “Ja” kunt beantwoorden:

• Worden de gegevens die in spreadsheets zijn opgeslagen op de lange termijn of regelmatig nodig, in tegenstelling tot eenmalige bewerkingen?
• Hebben meerdere personen toegang tot deze gegevens nodig?
• Moet je jezelf beschermen tegen invoerfouten?
• Moeten de gegevens beschermd worden tegen onopzettelijke wijzigingen?

Relationele databases

Zoals wij reeds hebben opgemerkt, zijn de redenen voor de dominantie van relationele databases eenvoud, robuustheid, flexibiliteit, prestaties, schaalbaarheid en compatibiliteit bij het beheer van algemene gegevens.

Maar om dit alles te kunnen bieden, moeten relationele databases intern ongelooflijk complex zijn. Zo kan een relatief eenvoudige SELECT-instructie honderden mogelijke query-uitvoeringspaden hebben die de optimizer tijdens runtime evalueert. Dit is allemaal verborgen voor ons als gebruikers, maar onder de motorkap bepaalt de RDBMS het “uitvoeringsplan” dat de query’s het best beantwoordt, met behulp van zaken als kostengebaseerde algoritmen.

Amerika’s best verkochte sedan in de jaren 2000 was de Toyota Camry, en het is niet moeilijk te begrijpen waarom. De Camry is niet de beste in veel van de categorieën die worden gebruikt om auto’s te beoordelen, zoals veiligheid, gasverbruik, volume van het interieur, betrouwbaarheid en diverse andere. Toch staat hij in elke categorie dichtbij de top, waardoor hij een algemene beoordeling krijgt die hem aan de top plaatst. Wat heeft een middelgrote sedan te maken met onze discussie over databases? Net als de Camry blinkt de relationele database niet uit in een van de kwaliteiten van een goede database, maar hij doet alle gebieden goed, dus wordt hij beschouwd als een standaardoplossing.

Met de komst van Web 2.0 en vooral van cloud-based computing is de behoefte aan web-enabled databases gegroeid om onvoorstelbaar grote hoeveelheden inhoud aan te bieden, op te slaan en te beheren. Inhoud zoals Facebook’s gebruikersprofielen en berichten voor miljoenen mensen over de hele wereld, Google’s miljarden zoekopdrachten en web crawls van andere sites, Dropbox’s miljoenen opgeslagen gebruikersdocumenten en bestanden, eBay’s miljoenen veilinglijsten enzovoort. Het modewoord voor dit gebied is meestal “Big Data”.

Bij al deze databases is het grootste probleem de schaalbaarheid. Naarmate meer en meer toepassingen worden ingevoerd in omgevingen met een enorme werklast (denk aan de vele webdiensten die tegenwoordig op het web beschikbaar zijn), kunnen hun schaalvereisten zeer snel veranderen en zeer groot worden. Relationele databases schalen goed, maar meestal alleen als het schalen op één server gebeurt. Wanneer de capaciteit van deze ene server is bereikt, moet de belasting over meerdere servers worden verdeeld, wat resulteert in wat gedistribueerd computergebruik wordt genoemd. Dit is het moment waarop de complexiteit van relationele databases botst met hun schaalbaarheid. Probeer op te schalen naar honderden of duizenden servers en de complexiteit wordt overweldigend. De kenmerken die RDBMS zo aantrekkelijk maken, zijn precies dezelfde als die welke hun geschiktheid als platform voor grote gedistribueerde systemen drastisch beperken.

Om clouddiensten levensvatbaar te maken, hebben leveranciers deze beperking moeten aanpakken, want een cloudplatform zonder snel schaalbare gegevensopslag is bijna nutteloos. Om klanten schaalbare opslag voor applicatiegegevens te kunnen bieden, hebben aanbieders een nieuw type databasesysteem moeten implementeren dat zich obsessief richt op schaalbaarheid – ten koste van de andere voordelen die relationele databases bieden. In het volgende zullen we deze nieuwe, niet-relationele databases nader bekijken.

Niet-relationale Datenbanken

Een van de grootste beperkingen van relationele databases is dat elk element slechts één attribuut kan bevatten. In het bankvoorbeeld dat we eerder hebben bekeken, moeten alle aspecten van de relatie tussen een klant en een bank als afzonderlijke rijelementen in aparte tabellen worden opgeslagen. De klantgegevens bevinden zich in één tabel, de rekeninggegevens in een andere, de kredietgegevens in nog een andere, de investeringen in weer een andere, enzovoort. Al deze tabellen zijn verbonden door relaties of primaire en externe sleutels.

Niet-relationele databases, met name de key-value stores of key-value-pairs van een database, verschillen fundamenteel van dit model. Met key-value-paren kun je meerdere gerelateerde elementen opslaan in één “rij” van gegevens in dezelfde tabel. We plaatsen het woord “rij” tussen aanhalingstekens omdat een rij hier niet precies hetzelfde is als een rij in een relationele tabel of spreadsheet, hoewel het nog steeds handig is om het zo te noemen voor vergelijkingsdoeleinden. In een niet-relationele tabel voor dezelfde bank zouden bijvoorbeeld alle gegevens van een klant, inclusief zijn account-, krediet- en investeringsgegevens, in één enkele record worden opgeslagen.

Dit lijkt een veel betere manier om gegevens op te slaan. Waarom gebruiken we dan nog steeds relationele databases in plaats van dit model? Welnu, het probleem met key-value stores is dat ze in tegenstelling tot relationele databases geen relaties tussen gegevenselementen kunnen afdwingen. In onze key-value database zouden bijvoorbeeld alle klantgegevens (naam, verzekeringsnummer, adres, rekeningnummer, kredietverwerkingsnummer, enz.) worden opgeslagen in één enkele record (in plaats van in meerdere tabellen, zoals in het relationele model). De klanttransacties (opnames, stortingen, terugbetalingen, bankkosten, enz.) worden ook in één record opgeslagen.

In het relationele model is er een ingebouwde en waterdichte manier om business logica op databaseniveau af te dwingen, bijvoorbeeld om ervoor te zorgen dat een opname op de juiste bankrekening wordt geboekt. In key-value stores ligt deze verantwoordelijkheid direct bij de applicatielogica. Veel mensen worden erg zenuwachtig als het gaat om het overlaten van deze cruciale verantwoordelijkheid aan de applicatie zelf, daarom zullen relationele databases op korte termijn niet verdwijnen.

Bij webgebaseerde databases staat echter de strikte handhaving van bedrijfsregels vaak onderaan de prioriteitenlijst. Bovenaan de lijst staat het vermogen om een groot aantal gebruikersverzoeken te verwerken, meestal alleen leesverzoeken. Op een website zoals de enorme online veiling eBay.com bijvoorbeeld bekijken de meeste gebruikers alleen de aangeboden items (ready only verzoeken). Slechts een klein deel van deze gebruikers brengt daadwerkelijk biedingen uit of reserveert

Databases versus datawarehouses

Een data warehouse is een speciaal type database dat geoptimaliseerd is voor queries, rapporten en analyses. De gegevens in een data warehouse zijn bijna altijd read-only en komen meestal uit de operationele database en andere systemen. De gegevens worden vervolgens op gezette tijden naar het pakhuis geüpload met behulp van extractie-, transformatie- en laadprocessen (ETL) om ze om te zetten in een vorm die geschikter is voor rapportage en diepere analyse. De exacte details van deze transformatie zijn complex, dus daar gaan we hier niet op in. Het belangrijkste voordeel van rapportage met datawarehouses boven transactionele bedrijfsdatabases is dat warehouses een veel betere en fijnere gegevensanalyse voor zakelijk gebruik mogelijk maken. Het gebruik van een data warehouse ontlast ook het transactiesysteem, dat voor grote bedrijven zeer belastend kan zijn, vooral aan het eind van het kwartaal of het eind van het jaar. Bovendien bewaren data warehouses een duidelijke en volledige geschiedenis van alle gegevens, terwijl het transactiesysteem die mogelijkheid niet biedt.

Een goed voorbeeld van het nut van data warehousing is de financiële dienstverlening. Banken gebruiken hun datawarehousing-mogelijkheden doorgaans voor diepgaande prognoses en planning. Ze gebruiken patronen en trendanalyses om vragen te beantwoorden als:

• Wat zijn de soorten klanten die de meeste kans maken op wanbetaling op leningen? Is er een correlatie tussen het inkomen van een klant, zijn aflossingsgedrag en zijn geldopnames en zijn vermogen om leningen terug te betalen?
• Wat is de beste tijd van het jaar om financiering te bieden aan bijvoorbeeld commerciële landbouwers? Hebben zij meestal financiële steun nodig vlak voor of vlak na het oogstseizoen of midden in de plantcyclus?
• Waarom zetten zoveel studenten hun rekening niet bij ons voort nadat ze zijn afgestudeerd en een baan hebben gevonden? Welke functies of voordelen hebben ze bij andere banken die wij niet bieden?
• Data warehouses zijn ook nuttig in andere sectoren, zoals analyse van verzekeringsfraude en het matchen van patronen, analyse van telefoongesprekken, agrarische weers- en klimaatvoorspellingen, en vele andere gebieden.
• Een goed voorbeeld van de kracht van analytics die datawarehouses bieden is het bekende verhaal van een groot retailbedrijf. Na analyse van de gegevens uit het datawarehouse merkten de winkelmanagers een opzienbarende trend op: de verkoop van luiers en babyvoeding in de late avonduren ging gepaard met een sterke toename van dranken, vooral bier in blik. Na wat hoofdbrekens en urenlang onderzoek naar deze late klanten kwam het antwoord eindelijk aan het licht. Het waren nieuwe ouders, vooral jonge vaders, die door hun vrouw of vriendin op pad werden gestuurd om luiers voor de baby te kopen, en de gestreste jonge vaders besloten dat ze evengoed een drankje konden nemen om zich te ontspannen. De winkel plaatste vervolgens beide soorten koopwaar dichter bij elkaar in het gangpad om nog meer van deze markt te veroveren, en verdrievoudigde de verkoop van alcoholische dranken na 21.00 uur.

Zoals je ziet, verschillen data warehouses van typische databases doordat ze worden gebruikt voor complexere gegevensanalyse. Dit onderscheidt ze van transactionele databases, die vooral bedoeld zijn om operationele systemen te ondersteunen en op kleine schaal dagelijkse rapporten te leveren. Datawarehousing moet soms ook nauw samenwerken met marktonderzoek en andere afdelingen.

Andere belangrijke databaseconcepten

We hebben de basis databaseconcepten besproken, maar dat zijn niet de enige. Er zijn ook andere belangrijke secundaire concepten en gegevensstructuren die het leren waard zijn. In dit deel zullen we deze kort bekijken.

Indices

Een index in een RDBMS is een gegevensstructuur die nauw samenwerkt met tabellen en kolommen om het ophalen van gegevens te versnellen. Hij werkt ongeveer zoals de index aan het begin van een boek. Met andere woorden, hij biedt een referentiepunt waarmee je snel de gewenste gegevens kunt vinden en openen zonder het hele boek (de database) te hoeven doorzoeken.

Schema

Een schema is de structuur achter de organisatie van gegevens. Het is een visueel overzicht van hoe de verschillende tabellen zich tot elkaar verhouden. Het wordt gebruikt om de onderliggende bedrijfsregels waarvoor de database is gemaakt in kaart te brengen en te implementeren.

De Oracle DB heeft een iets andere definitie van schema. Hier verwijst schema naar de verzameling databaseobjecten van een gebruiker. De naam van het schema en de gebruikersnaam zijn identiek maar hebben verschillende functies, d.w.z. een gebruiker kan worden verwijderd terwijl zijn verzameling objecten (schema) intact blijft in de database en zelfs opnieuw kan worden toegewezen aan een andere gebruiker.

Hieronder staat een voorbeeld van een eenvoudig databaseschema:

Normalisatie

Normalisatie is het proces van (re)organisatie van gegevens in een database zodat aan twee basisvereisten wordt voldaan: Er is geen data redundantie (alle gegevens worden slechts op één plaats opgeslagen), en de data afhankelijkheden zijn logisch (alle gerelateerde data elementen worden bij elkaar opgeslagen). In de database van een bank bijvoorbeeld moeten alle statische klantgegevens, zoals naam, adres en leeftijd, bij elkaar worden opgeslagen. Alle rekeninggegevens, zoals rekeninghouder, rekeningtype, rekeningfiliaal, enz. moeten ook samen worden opgeslagen; ze moeten ook afzonderlijk van de statische klantgegevens worden opgeslagen.

Normalisatie is om vele redenen belangrijk, maar vooral omdat databases hierdoor zo weinig mogelijk opslagruimte in beslag nemen, wat tot betere prestaties leidt. Er zijn verschillende incrementele vormen van normalisatie die behoorlijk complex kunnen worden.

Beperkingen

In de wereld van RDBMS betekent beperking precies hetzelfde als in de echte wereld. Een restriction is een beperking op het soort gegevens dat je in een bepaalde kolom kunt stoppen. Beperkingen worden altijd gedefinieerd voor kolommen. Een veel voorkomende beperking is de niet-nul beperking. Deze specificeert eenvoudig dat alle rijen in een tabel een waarde in de kolom moeten hebben die als niet-nul is gedefinieerd.

Transacties (commits en rollbacks)

Stel dat een bank zijn databasesystemen aan het bouwen is. Stel je voor dat het systeem crasht wanneer een overdracht bezig is. Grote problemen, toch? Dit is het basisidee van een transactie: alle elementen van een reeks wijzigingen moeten samen gebeuren. Bij een eenvoudige overboeking moet je, als je een rekening debiteert, een andere rekening crediteren.

In relationele databases wordt het opslaan van een transactie een commit genoemd, en het ongedaan maken van niet-opgeslagen wijzigingen een rollback. Dat is de basisdefinitie, maar het wordt ingewikkelder als je bedenkt dat databases meestal meerdere gebruikers tegelijk moeten bedienen. Wat gebeurt er als andere gebruikers dezelfde gegevens opvragen voordat de transacties zijn opgeslagen? Op welk moment zien de andere gebruikers de opgeslagen gegevens? Alle RDBMS’en moeten deze vragen bevredigend kunnen beantwoorden, en dat doen ze via de commit/rollback-functies.

Databases moeten ook fouttolerantie bieden, zelfs in het geval van een defecte harde schijf. Wanneer gegevens worden overgedragen, moet er honderd procent garantie zijn dat de gegevens daadwerkelijk worden opgeslagen. Relationele databases hebben geavanceerde methoden om dit te bereiken, zoals commits in twee fasen en het gebruik van logbestanden.

ACID

De term ACID verwijst hier niet naar psychedelische middelen die DBA’s beter laten werken. Het is eerder een acroniem dat vier zeer gewenste eigenschappen van een RDBMS beschrijft:

• Atomiciteit: dit verwijst naar het vermogen van een database om een transactie volledig te verwerken of volledig terug te draaien.
• Consistentie: De database moet ervoor zorgen dat alle gegevens die naar de database worden geschreven alle regels en beperkingen volgen die in de database zijn gespecificeerd.
• Isolatie: Transacties moeten veilig en onafhankelijk worden verwerkt zonder elkaar te storen.
• Duurzaamheid: De database moet ervoor zorgen dat alle vastgelegde transacties permanent worden opgeslagen en niet per ongeluk kunnen worden verwijderd, zelfs niet bij een crash van de database.
• Vergrendeling van databases

Zoals we al hebben gezien, maken databases het mogelijk dat meerdere gebruikers tegelijkertijd toegang hebben tot een record. Daarom rijst onvermijdelijk de vraag hoe om te gaan met situaties waarin twee of meer gebruikers dezelfde gegevens willen inzien of bijwerken. RDBMS’en lossen dit probleem op door het gebruik van locks.

Er zijn verschillende soorten sloten, bijvoorbeeld sloten op transactie- of gegevensniveau die alleen een enkel gegevensveld blokkeren; sloten op rijniveau die een hele record blokkeren, terwijl sloten op tabelniveau de toegang tot een hele tabel beperken. Zoals je ziet, is het laatste type lock bijzonder restrictief. Het wordt daarom alleen gebruikt als het absoluut noodzakelijk is, bijvoorbeeld wanneer tabelbrede gegevens worden geladen of tabelbrede back-ups worden uitgevoerd.

Overigens kunnen spreadsheets alleen sloten op tabelniveau gebruiken. Dit is een uitstekend voorbeeld van hun inferioriteit ten opzichte van databases. Als je in een kantooromgeving werkt, ben je waarschijnlijk wel eens de vervelende melding “file is locked by another user” tegengekomen bij het werken aan een gedeelde Excel-spreadsheet. Locks zijn een belangrijke manier om de ACID (Atomicity, Consistency, Isolation, Durability) eigenschappen van een RDBMS te implementeren.

Het meest voorkomende type lock is de data-level lock of transactie lock. Deze is gewoonlijk volledig onzichtbaar voor de gebruiker. Wanneer een gebruiker een bepaald gegevensitem bijwerkt (maar niet noodzakelijk vastlegt), wordt het vergrendeld zodat andere gebruikers er geen verdere wijzigingen in kunnen aanbrengen. De andere gebruiker kan echter nog steeds dezelfde gegevens lezen. Dit is een mooie eigenschap van RDBMS. Op dit moment zien de andere gebruikers alleen de “oude” waarde van het gegevensitem die bestond voordat de wijzigingen werden aangebracht. Zodra de hoofdgebruiker de wijziging vastlegt (opslaat), zien alle gebruikers die nu de gegevens opvragen de nieuwe, bijgewerkte waarde. Vergeet niet dat de term “nieuwe waarde” ook een verwijdering van de bestaande gegevens kan inhouden, in welk geval het veld nu een nulwaarde is.

Als de gebruiker in plaats daarvan de wijziging terugdraait, zien de andere gebruikers nog steeds dezelfde gegevens, maar kunnen nu ook het gegevensitem bijwerken.

Als een gebruiker een item probeert te wijzigen dat al door een eerste gebruiker is vergrendeld, krijgt de tweede gebruiker een foutmelding of stopt het systeem voor korte tijd, in afwachting dat de eerste gebruiker de wijziging bevestigt (opslaat) of ongedaan maakt (terugdraait).

Een merkwaardige situatie kan zich voordoen wanneer twee gebruikers elk een gegevensitem geblokkeerd hebben en vervolgens allebei proberen toegang te krijgen tot en een wijziging aan te brengen in datzelfde gegevensitem dat de andere gebruiker heeft. In dat geval bestaat de kans dat het item voor onbepaalde tijd wordt geblokkeerd terwijl de ene gebruiker wacht op de andere. Dit wordt een deadlock genoemd, en de meeste RDBMS’en hebben een methode om dit op te sporen en op te lossen. Het systeem selecteert meestal een willekeurige gebruiker en maakt zijn wijzigingen ongedaan, waardoor de door die gebruiker geblokkeerde gegevens worden vrijgegeven en de impasse wordt opgeheven.

Je kunt je voorstellen dat vergrendelen een dure activiteit is die database- en computerbronnen kost. Systemen die schrijf-intensieve databases hosten, moeten robuust genoeg zijn om de door locking verbruikte middelen, vooral de CPU, te ondersteunen. Toepassingen moeten ook worden ontworpen om gegevens zo weinig mogelijk te vergrendelen. Eén manier om dit te bereiken is het inbouwen van de mogelijkheid om gegevens te bewaren in de toepassing zelf. Zodra een gegevensitem uit de database is gelezen, moet de applicatie alle wijzigingen intern doorvoeren zonder eerst met de database te communiceren. Pas wanneer de gebruiker op “Opslaan” klikt, schrijft de toepassing het item snel terug naar de database. Dit minimaliseert de tijd dat een gegevenselement zich vanuit het oogpunt van de database in een wachtstand bevindt, d.w.z. “gewijzigd” maar nog niet “bevestigd” of “ongedaan gemaakt”.

Table-level locks zijn, zoals gezegd, zeer beperkend omdat ze een hele tabel vergrendelen. Hoewel ze zelden worden gebruikt, zijn ze van onschatbare waarde bij sommige operaties, zoals het in bulk uploaden van gegevens of het reorganiseren van gefragmenteerde gegevens voor een hele tabel. In dergelijke gevallen is het wenselijk ervoor te zorgen dat geen enkele andere gebruiker toegang heeft tot de tabel voor de duur van de operatie, en het slot moet onmiddellijk worden vrijgegeven wanneer de operatie is voltooid. Daarom worden deze sloten meestal alleen door DBA’s gebruikt voor deze speciale operaties. Table-level locks moeten meestal expliciet worden gespecificeerd; standaard gebruikt de RDBMS row-level of transaction-level locks.

Commerciële RDBMS-systemen

We hebben nu de meeste basisprincipes van relationele databases behandeld. Ze zijn het meest gebruikte type database op de markt en ook een van de belangrijkste soorten software, op gelijke voet met besturingssystemen, kantoorapplicaties en spelletjes.

Het zal je dan ook niet verbazen dat de grote, succesvolle RDBMS-leveranciers tot de titanen van de software-industrie behoren en niet alleen in de softwarewereld, maar ook in het nieuws en de cultuur een begrip zijn. Namen als Oracle en Microsoft zijn alomtegenwoordig en zeer vertrouwd, zelfs voor niet IT-professionals.
Veel RDBMS-leveranciers brengen zowel verwante als totaal verschillende producten op de markt. Wat ze echter allemaal gemeen hebben, is dat het RDBMS een van hun belangrijkste productlijnen is. Ze luisteren goed en doen moeite om feedback van de markt te verzamelen, wat niet altijd het geval is in de software-industrie.

Om redenen van bedrijfsstrategie werken veel van hun producten echter niet goed samen met het aanbod van concurrenten of met andere software. Microsofts SQL Server is bijvoorbeeld alleen beschikbaar voor het Windows-besturingssysteem, dat ook van Microsoft is. Er zijn klachten dat Oracle DB niet zo goed werkt met het Windows-besturingssysteem als met Linux, enz.

Een groeiende trend in de industrie is om het RDBMS te consolideren en te bundelen met andere software van dezelfde leverancier, bijvoorbeeld een besturingssysteem van voorkeur of andere aanvullende software zoals:

• Aanvullende databeveiligingsmodules, zoals Oracle DataGuard,
• Integratie met een ontwikkelingsplatform, zoals Microsoft’s .NET,
• All-in-one platforms die hardware en software combineren, zoals Oracle Exadata of Microsoft Trefis.

We zullen nu kort kijken naar enkele commerciële RDB-aanbiedingen en de bedrijven erachter:

Oracle

Oracle is een van de reuzen in de wereld van RDBMS. Opgericht in 1977 door de charismatische, avontuurlijke CEO Larry Ellison, is het bedrijf nu een miljardenreus in de wereld van commerciële databases dankzij zijn vlaggenschipproduct, Oracle DB. Oracle maakt ook een verbijsterende reeks andere producten, van middleware tot systemen voor enterprise resource planning en customer relationship management (CRM). Veel van deze producten werden niet zelf ontwikkeld, maar verworven door de overname van andere softwarebedrijven zoals PeopleSoft, Siebel Systems, Sun Microsystems en BEA Systems. Verschillende van deze producten zijn met wisselend succes geïntegreerd in het Fusion middleware product.

Oracle DB wordt veel gebruikt in databases op bedrijfsniveau. Het is beschikbaar in verschillende edities om aan verschillende eisen te voldoen. Oracle DB is volledig compatibel met de SQL-taal, hoewel het ook zijn eigen versie genaamd SQL*Plus onderhoudt. Oracle DB is de toonaangevende RDBMS met een marktaandeel van 48,8 procent van de RDBMS-markt (eind 2011).

Interessant is dat Oracle in 2009 Sun Microsystems overnam, de licentiehouder van MySQL, een van de belangrijkste concurrenten van Oracle DB. Hierdoor heeft Oracle twee RDBMS-aanbiedingen. Oracle DB en MySQL mogen elkaar echter niet hinderen, omdat ze in licht verschillende marktsegmenten opereren en licht verschillende behoeften dienen.

Microsoft

Microsoft is een andere grote jongen in de wereld van RDBMS-software met zijn SQL Server-product, hoewel het bedrijf beter bekend is om zijn universele Windows-besturingssysteem en Office-suite van kantoorprogramma’s.

SQL Server werd rond 1989 samen met Sybase-systemen ontwikkeld, maar de twee bedrijven gingen uit elkaar en ontwikkelden afzonderlijke producten. Microsoft behield de naam SQL Server en Sybase besloot zijn aanbod Adaptive Server Enterprise te noemen om verwarring met Microsofts SQL Server te voorkomen. Het RDBMS draait alleen op het Windows-besturingssysteem.

SQL Server gebruikt een eigen querytaal, T-SQL genaamd, die sterk lijkt op en compatibel is met standaard SQL. Het RDBMS heeft een marktaandeel van ongeveer 20 procent (eind 2011), maar ook dat is de laatste jaren toegenomen.

SQL Server en Oracle DB hebben veel dingen gemeen, van gegevensstructuren tot methoden voor transactieverwerking en databaseobjecten. Net als Oracle DB ondersteunt SQL Server geavanceerde ETL-bewerkingen (extract, transform, load) die helpen bij het overbrengen van gegevens naar datawarehouses. Beide bieden ook geavanceerde rapportagemogelijkheden.

Postgres

Postgres, ook bekend als PostgreSQL, is een open source relationele database die ook database-objecten kan ondersteunen. Het is geen eigendom van één persoon, maar wordt onderhouden door de PostgreSQL Global Development Group, een toegewijde groep vrijwilligers die beheerd en in dienst is van open source softwareontwikkelingsbedrijven zoals RedHat en EnterpriseDB.
Postgres is beschikbaar op Linux, Windows en macOS.

MySQL

MySQL is een ander open source RDBMS. Het is een volwaardig databasesysteem gesponsord door het Zweedse bedrijf MySQL AB, dat nu eigendom is van Oracle nadat het moederbedrijf Sun Microsystems in 2010 door Oracle werd gekocht.

MySQL is erg populair voor webgebaseerde back-end databases, afzonderlijk of als onderdeel van de Linux, Apache, MySQL, PHP (LAMP) stack die wordt gebruikt om webgerichte toepassingen te implementeren.

DB2

Net als SQL Server en Oracle DB is IBM’s DB2 een volledig objectgeoriënteerd RDBMS. Oorspronkelijk exclusief ontwikkeld voor IBM’s mainframes in de vroege jaren tachtig, werd het later geport naar andere platformen zoals Linux, Unix, Windows (LUW) en IBM’s eigen OS/2.

Het is een veelgebruikt commercieel RDBMS en heeft ook een kleine gratis versie voor ontwikkelaars, Express-C genaamd. In 2009 bracht IBM versie 9.7 van DB2 uit, die de functies van marktleider Oracle DB op de voet volgt. Dit heeft het bedrijf wat omzet opgeleverd, omdat het voor Oracle-savvy database-experts gemakkelijker wordt om met DB2 aan de slag te gaan.

Conclusie

Gefeliciteerd – dat jij bent zo ver gekomen!
We hebben letterlijk slechts een tipje van de sluier opgelicht. Veel mensen werken immers een hele carrière met databases; er valt veel te leren! Laten we samenvatten wat we hier hebben behandeld:

• In de meest algemene zin is een database een georganiseerde verzameling van gegevens. Als je het specifieker verwoord is een database een elektronisch systeem waarmee gegevens gemakkelijk kunnen worden geraadpleegd, bewerkt en bijgewerkt.
• Elk bedrijf of organisatie die een groot aantal klanten of producten moet bijhouden, kan baat hebben bij een database, waarbij grote organisaties het meest profiteren.
  De eerste databasesystemen hadden een navigatief karakter. Dit betekent dat toepassingen gegevens verwerkten en lazen met behulp van pointers die in de gegevens zelf waren opgenomen.
• De vroege hiërarchische en netwerkgegevensmodellen werden voorbijgestreefd door het relationele model van E.F. Codd.
  Het relationele model was een radicale afwijking van het heersende hiërarchische model, omdat het gericht was op de mogelijkheid een database te doorzoeken op inhoud in plaats van een gekoppeld navigatiesysteem te volgen.
• Er zijn enkele zeer belangrijke niet-relationele databases (vooral met de komst van Big Data en Web 2.0), maar het relationele model wordt nog steeds gebruikt voor het overgrote deel van het commerciële database-aanbod.
• Een relationele database is in wezen een verzameling tabellen of, om de technische benaming te gebruiken, entiteiten (zie regels 0 en 1 in Codd’s 12 regels voor relationele databases). Elke tabel bestaat uit rijen (tuples) en kolommen (attributen). Er bestaan relaties tussen tabellen, gedefinieerd door het feit dat een bepaalde kolom in de ene tabel verwijst naar een kolom in een andere tabel.
• Er zijn 13 “regels” die bepalen of een database “relationeel” kan worden genoemd.
• De tabel is de basiseenheid van gegevensopslag in een relationele database. Tabellen bestaan uit kolommen en rijen.
  Relaties zijn DE reden waarom relationele databases zo goed werken.
• In relationele databases bestaat een relatie tussen twee tabellen wanneer een van de tabellen een vreemde sleutel heeft die verwijst naar de primaire sleutel van de andere tabel.
  Een rij, ook wel record genoemd, vertegenwoordigt een reeks gegevens over een bepaald item. Elk record in een tabel heeft precies dezelfde structuur, maar natuurlijk verschillende gegevens.
• Een kolom is een specifieke reeks waarden in een tabel van hetzelfde type. Zij definieert een bepaald kenmerk van de tabel of de gegevens.
• Een primaire sleutel is een speciale kolom of combinatie van kolommen die elke record (rij) in de tabel uniek identificeert. De primaire-sleutelkolom moet voor elke rij uniek zijn en mag geen nullen (niet-waarden) bevatten.
• De primaire sleutel is, samen met het nauw verwante concept van de vreemde sleutel, de belangrijkste methode om relaties te definiëren. Een primaire sleutel definieert een record op unieke wijze, terwijl een vreemde sleutel wordt gebruikt om te verwijzen naar dezelfde record in een andere tabel.
• Structured Query Language (SQL) is de gemeenschappelijke taal voor het beheren en manipuleren van gegevens in relationele databases. SQL kan worden gebruikt om gegevens op te vragen, in te voegen, bij te werken en te wijzigen.
• Spreadsheets en databases hebben een aantal vergelijkbare mogelijkheden, maar spreadsheets hebben een aantal beperkingen die ze ongeschikt maken voor het beheer van sommige gegevenssituaties.
• Een van de belangrijkste beperkingen van relationele databases is dat elk element slechts één attribuut kan bevatten. Niet-relationele databases, met name de key-value stores of key-value paren van een database, wijken fundamenteel af van dit model. Met key-value paren kun je meerdere gerelateerde elementen opslaan in een “rij” gegevens in dezelfde tabel.
• Een data warehouse is een speciaal type database dat is geoptimaliseerd voor query’s, rapportage en analyse. Het belangrijkste voordeel van rapportage met data warehouses ten opzichte van enterprise transactionele databases is dat warehouses een veel betere en fijnere gegevensanalyse voor zakelijk gebruik mogelijk maken. Een index in een RDBMS is een gegevensstructuur die nauw samenwerkt met tabellen en kolommen om het ophalen van gegevens te versnellen.
• Een schema is de structuur achter de gegevensorganisatie. Het is een visueel overzicht van hoe verschillende tabellen zich tot elkaar verhouden.
• Normalisatie is het proces van het (her)organiseren van gegevens in een database zodat deze aan twee basisvereisten voldoen: Er is geen data redundantie (alle gegevens worden op slechts één plaats opgeslagen), en de data afhankelijkheden zijn logisch (alle gerelateerde data items worden bij elkaar opgeslagen). In de wereld van RDBMS betekent beperking precies hetzelfde als in de echte wereld. Een beperking is een beperking op het soort gegevens dat je in een bepaalde kolom kunt invoeren.
• In relationele databases wordt het opslaan van een transactie een commit genoemd, en het ongedaan maken van niet-opgeslagen wijzigingen een rollback.
• ACID is een acroniem voor Atomicity Consistency Isolation Durability, de vier zeer gewenste eigenschappen van een RDBMS.
• Oracle is een van de giganten in de wereld van RDBMS. Zijn paradepaardje is Oracle DB.
• Microsoft is een andere grote jongen in de wereld van RDBMS-software met zijn SQL Server-product, hoewel het bedrijf beter bekend is om zijn universele Windows-besturingssysteem en zijn Office-suite van productiviteitstools.
• Andere commerciële RDBMS-systemen zijn Postgres, MySQL en DB2.