I.B.M. System/38 - RDBMS in mensentaal

Eén van de grootste verwezenlijkingen in de twintigste eeuw was ongetwijfeld de ontwikkeling van de IBM System/38. Het tijdperk van de automatisatie door middel van een computer werd ingeluid na de Tweede Wereldoorlog en gaf bijzonder veel stof tot nadenken. De ontdekking van de transistor en later ook de geïntegreerde schakeling zorgde ervoor dat de machines compacter en sneller werden. De System/38 was het product van een intense voorbereiding die niet alleen op technisch vlak werd gevoerd maar die ook een diepgaande theoretische hervorming van de bestaande concepten in de automatisatie met zich heeft meebracht.

Het sleutelwoord is "geïntegreerd"

System/38

De S/38 is een administratieve mini-computer die in 1978 voor het eerst werd voorgesteld door haar Amerikaanse constructeur de International Business Machines Corporation (IBM). Dit toestel is ontstaan uit het Future Systems Project, een ontwikkelingsproject dat IBM had opgezet in het begin van de jaren 70 en was bedoeld om de mainframetechnologie van de IBM/360 en -/370 te vervangen. In de loop der jaren werd de term mini-computer door IBM omgedoopt tot Midrange-computer.

Het belangrijkste verschil met de grote mainframe-mastodonten was dat de S/38 zou draaien onder een nieuw en geïntegreerd 48-bit besturingssysteem (Control Program Facility - CPF) waardoor de efficiëntie optimaal zou kunnen worden benut. Bovendien bevatte dit besturingssysteem ook een geavanceerde beveiligingstechnologie, die anno 2015 in een verbeterde versie, nog steeds gebruikt wordt door de nakomelingen van de S/38.

Relational Database Management System

Het meest typische kenmerk van de System/38 was het volledig in de CPF geïntegreerde RDBMS (Relational DataBase Management System) dat ervoor zorgde dat de database kon opgesplitst worden in bibliotheken en onmiddellijk in de programma's beschikbaar werd. Het maakte niet uit of de gegevens op schijf stonden of onmiddellijk in het werkgeheugen verbleven: het besturingssysteem zorgde voor de aanvoer van de nodige informatie. Het RDBMS op de S/38 werd DB2 genoemd.

Het RDBMS zorgt ervoor dat de software-ontwikkelaar geen ingewikkelde procedures moet aanspreken om de databases die hij nodig heeft, te kunnen gebruiken. Bovendien duidt het woord "relationeel" op het feit dat deze database zodanig te benaderen is dat verschillende bestanden of tabellen via gemeenschappelijke kenmerken met elkaar kunnen verbonden worden m.a.w. met elkaar in relatie staan.

De knappe koppen van IBM hebben hier bijzonder goed over nagedacht en er vooral in de beginjaren van het uitrollen van de S/38 uitgebreide lezingen en opleidingen over georganiseerd, waaraan ook de schrijver van dit artikel heeft deelgenomen. Het beginsel van het RDBMS ligt in het efficiënt normaliseren van de gegevensbanken en het opzetten van een geoliede database. Zonder een genormaliseerde database is het ontwikkelen van programma's en applicaties gedoemd tot mislukken.

Normalisatie

Het principe van normalisatie is heel eenvoudig: schrijf nooit twee keer hetzelfde.

Een computer wordt soms op een humoristische manier omschreven als een "geheelonthouder" en dat heeft uiteraard zijn redenen. Eenmaal men een bepaald gegeven heeft weggeschreven in een tabel of bestand van een relationele database (RDB) vermijdt men best van dit te herhalen in een andere tabel. De computer onthoudt immers wat er in zijn geheugen of op zijn externe gegevensdragers staat en men hoeft het hem dus geen tweede keer te zeggen.

Een eenvoudig voorbeeldje in dit verband kan wonderen verrichten en we verplaatsen ons hiervoor even in de leefwereld van de jaren tachtig van vorige eeuw.

Normalisatie in de bibliotheek

Stel, je gaat naar de bibliotheek om boeken te ontlenen. De rol van de computer wordt gespeeld door de bibliothecaris en deze van de externe gegevensdragers door de registers en lijsten die zijn medewerker invult en bijhoudt. De bibliothecaris laat bij het allereerste bezoek jouw naam, adres en andere persoonlijke gegevens opschrijven in een "ledenboek". Na het controleren van deze informatie krijg je een lidnummer toegekend. Dit nummer onthoud je door middel van de lidkaart, die door de assistent werd ingevuld en afgeleverd.

Naast jouw persoonlijke gegevens beschikt de bibliothecaris echter ook over een grote "inventaris" van alle boeken die in de bibliotheek aanwezig zijn. Deze lijst omvat naast een unieke boekencode ook de titel, de naam van de auteur, uitgeverij, jaartal en alle belangrijke informatie die nodig is en die enkel te maken heeft met het boek.

Dan ga je de boeken ontlenen die je die week graag zou lezen en vooraleer je ermee naar huis mag, moeten deze geregistreerd worden door de bibliothecaris of zijn assistent. Die noteert in een afzonderlijk "ontleen-register" enkel jouw lidnummer, de code van het boek en de datum waarop je het boek hebt ontleend. Het zou immers dom zijn om steeds jouw naam, adres, geboortedatum, telefoonnummer en andere persoonlijke gegevens, samen met de titel van het boek, de uitgeverij, de naam van de auteur én de datum van de ontlening opnieuw te noteren voor elk boek dat je die week gaat ontlenen.

Het lijkt evident en dat is ook zo, maar het is eigenlijk het basisprincipe van normalisatie: "Schrijf nooit twee keer hetzelfde".

Externe sleutel

Door het nummeren van de leden in het "ledenboek" en het toekennen van een unieke code aan de boeken in de "inventaris" creëert de bibliothecaris een unieke referentiecode die ervoor zorgt dat de gegevens in het "ontleenregister" tot een minimum beperkt blijven. Een dergelijk nummer of referentiecode wordt ook "externe sleutel" of "foreign key" genoemd. Het verwijst éénduidig naar gegevens in andere tabellen en zorgt ervoor dat je de informatie die erbij hoort snel kan opzoeken en gebruiken.
In een druk bezochte bibliotheek moet immers het registreren van alle ontleende en teruggebrachte boeken snel vooruit gaan om de leden niet te lang te laten wachten.

Het normaliseren of toekennen van unieke nummers of coderingen aan een set van gegevens kan zeer ver gaan. Het is aan de database-analist om te bepalen op welke manier de gegevensbank wordt opgebouwd en hoe de verschillende relaties worden gelegd. Zijn analytische manier van denken en werken is computer-onafhankelijk en kan op eender welke machine, waarop een degelijk RDBMS is geïnstalleerd, geïmplementeerd worden.

We onderscheiden twee belangrijke types van normaliseren:

1. vaste tabellen
2. variabele tabellen

Vaste tabellen

Het normaliseren van vaste tabellen bestaat erin een externe sleutel te kiezen voor een statische set van gegevens. Je bent het vast wel eens tegengekomen dat je bij het invullen van een vakje op een formulier of webpagina moet kiezen uit een lijst van mogelijkheden die verscholen zitten achter een zwart pijltje (de zogenaamde "drop-box"). Er wordt dan een lijst met mogelijke waarden getoond en hieruit selecteer je wat toepasselijk is. Elke mogelijke waarde is verbonden aan een onzichtbare code die als externe sleutel wordt gebruikt in een vaste of statische tabel. In de meeste gevallen bestaat de tabel enkel uit de externe sleutel en de waarde die erbij hoort. Het grote voordeel van deze tabellen is dat ze volledig in het werkgeheugen van de computer kunnen worden opgeladen zodat het veelvuldig raadplegen en ophalen van de bijbehorende gegevens zo goed als geen tijd in beslag neemt.

Variabele tabellen

Een variabele tabel is in vergelijking tot een statisch bestand meestal veel groter en niet geschikt om via een "drop-box" te worden afgebeeld. Het bevat verschillende data-elementen (zoals bijvoorbeeld naam, adres, postcode, telefoonnummer, omschrijving, enz.) die informatie bevatten over één gegeven. In tegenstelling tot een statische tabel kan het variabel bestand vele honderden tot duizenden gegevens bevatten zodat het onmogelijk wordt om al deze data onmiddellijk in het geheugen op te laden.
Door het kiezen van een goede externe sleutel kan het opzoeken van de informatie echter zeer snel gebeuren.

Volgorde

Echt revolutionair zou de S/38 niet zijn, mocht deze enkel gebaseerd zijn op een strikt genormaliseerde RDBMS. Een onontbeerlijke toegevoegde waarde bij deze methodiek ligt in de flexibele indexering van de ingegeven database gegevens. Het sorteren van gegevens zoals wij het nu kennen in allerlei object-gerichte toepassingen op pc's en dergelijke heeft zijn oorsprong in het concept van het RDBMS. Om dit aanschouwelijk te kunnen uitleggen, is het noodzakelijk een kleine maar technische en iets meer complexe rondleiding te volgen in het binnenste van de machine.

Fysisch bestand

Op de S/38 worden alle daadwerkelijke database gegevens door de CPF weggeschreven in fysische bestanden (physical files of PF's). Dit zijn bepaalde vrije plaatsen in het externe geheugen van de computer die de kunnen terug gevonden worden door een adres, dat enkel toegankelijk is voor het besturingssysteem. Het is de CPF zelf die bijhoudt op welke adressen hij zijn gegevens wegschrijft. Een adres is in feite een unieke binaire identificatiecode die een plaats aanduidt in de opslagmedia van de computer. Deze wordt op haar beurt bijgehouden in een afzonderlijke tabel die vervolgens gekoppeld wordt aan het fysische bestand.

Je bekomt op die manier eigenlijk twee bestanden:

• een bestand met de daadwerkelijke gegevens (voorafgegaan door het adres)
• een bestand met enkel de adressen van waar die daadwerkelijke gegevens staan weggeschreven

Het laatste bestand is dus uiterst belangrijk om de daadwerkelijke gegevens terug te kunnen vinden.
Je kan het vergelijken met een inhoudstabel waarin voor elke beschreven geheugenplaats het paginanummer is genoteerd. De CPF kan geen gegevens terug vinden zonder eerst deze inhoudstabel te raadplegen. Het heeft het grote voordeel dat de plaats van een gegeven snel en éénduidig kan worden teruggevonden. De tijd die de computer nodig heeft om het op te halen is onwaarschijnlijk klein geworden door de ontwikkeling en evolutie van de technologie.

Logisch bestand

De inhoudstabel die bij de PF hoort wordt volledig door de CPF gecontroleerd en bevat de adressen van de daadwerkelijke gegevens in de volgorde zoals ze werden weggeschreven. Nu is het mogelijk om aan te geven dat je de daadwerkelijke database gegevens in een andere volgorde wenst te benaderen dan deze van de inhoudstabel van de PF. Hiervoor kies je in het fysische bestand een of meerdere elementen uit en bepaal je de structuur en richting van sortering (stijgend of aflopend). De CPF zorgt er dan voor dat een nieuwe inhoudstabel wordt gecreëerd waarin de adressen van de daadwerkelijke gegevens staan opgesomd in de volgorde die overeenkomt met de volgorde die je gekozen hebt.

Praktijkvoorbeeld

De lijst met boeken die de bibliothecaris bezit bevat o.a. de titel van het boek, de auteur en de uitgeverij. Noch bij de aankoop van de boeken noch bij het inschrijven ervan in het "inventaris-register" werd rekening gehouden met enige alfabetische rangorde van het boek. Elke nieuwe aankoop wordt gewoon na de laatste inschrijving geregistreerd en zo wordt de lijst alsmaar langer.
Stel dat je het "inventaris-register" op een System/38 hebt overgebracht in exact dezelfde volgorde als waarin de boeken werden aangekocht en ingeschreven. Dan heb je dus een physical file gemaakt die automatisch "geïndexeerd" is op datum en tijdstip van inschrijving, zoals bij alle andere physical files.

Om nu een alternatieve indexering of volgorde te bekomen, geef je de CPF de opdracht om een nieuwe lijst met adressen van de daadwerkelijke gegevens zodanig op te stellen dat ze in alfabetische volgorde komen van "auteur" en per "auteur" in volgorde van "titel". Deze opdracht wordt gecodeerd en samengevat door de gegevensbeheerder in een "logisch bestand" (logical file of LF) ook wel "logisch zicht" (logical view) genoemd. De CPF leest de opdracht en maakt een nieuwe lijst aan met adressen, net zoals de basisindex van de PF, maar dan in volgorde van "auteur" en "titel". Een logical file bevat dus enkel een lijst van adressen, in de volgorde die door de opdrachtgever werd aangegeven.

Indien er een nieuw boek wordt toegevoegd aan het "inventaris-register" op de System/38 zal het volgende gebeuren:

1. de CPF zoekt naar een vrije plaats, onthoudt het adres en schrijft de nieuwe daadwerkelijke gegevens weg
2. het nieuwe adres wordt onderaan toegevoegd aan de basisindex van het fysisch bestand
3. CPF gaat na of er een alternatieve index (of logisch bestand) bestaat voor het fysisch bestand
4. voor elk gevonden logisch bestand hercreëert de CPF de lijst met adressen

Hoe meer logische zichten er op een fysisch bestand worden gecreëerd en hoe meer daadwerkelijke gegevens er in vervat zitten, hoe "langer" het duurt voor de CPF om alle indexen opnieuw aan te maken. Uiteraard bestaan er de nodige opties om het beheer van de logische bestanden zo efficiënt mogelijk te laten verlopen. De verschillende applicaties die worden ontwikkeld op de S/38 maken voornamelijk gebruik van logische bestanden uit het RDBMS. Door het ophalen van de daadwerkelijke gegevens op het adres dat in de logische tabel staat, kan de informatie aan de gebruiker aangeboden en indien nodig gewijzigd, gekopieerd of geschrapt worden.

Een efficiënt RDBMS is dus een superbelangrijke schakel geweest tijdens de ontwikkeling van de System/38.

Lees verder

• IBM midrange computers