DB2 zoals we het kennen, startte in 1970 met twee verschillende innovaties. In juni van dat jaar publiceerde E.F. Codd de eerste omschrijving van het relationele databasemodel in ‘A relational model of data for large shared data banks’. Dit zou het databasemodel worden waarop alle belangrijke commerciële DBMS’en zijn gebaseerd. Slechts een paar maanden eerder schetsten twee IBM-ingenieurs, Frank Soltis en Dean Zimmerman, de basis van een machinearchitectuur gebaseerd op ‘single-level addressability’. In de zomer van 1971 borduurden Soltis en zijn collega’s Bains en Hoffman voort op dit idee en voltooiden zij de initiële architectuur voor een systeemontwikkelproject dat zij de codenaam ‘Pacific’ gaven.

door Paul Conte

In oktober 1978 kondigde IBM de resultaten van het Pacific-project aan: de System/38. Performanceproblemen leidden tot vertragingen en het was niet eerder dan juli 1980 dat de S/38 werd verscheept. Het was toen het eerste commerciële systeem dat een geïntegreerde database leverde met relationele mogelijkheden.

SQL en DB2
Ondertussen ontwikkelde een groep IBM’ers, los van het Pacific-project, een prototype relationele DBMS genaamd System R. Als onderdeel van dit project bedachten zij Structured English Query Language (SEQUEL) als een taal voor het definiëren en manipuleren van databaseobjecten – voornamelijk tabellen en views. De naam werd uiteindelijk veranderd in Structured Query Language (SQL).

In 1982 gaf IBM de eerste versie van DB2 vrij, dat ondersteuning voor SQL bevatte, als een optioneel DBMS-product dat draaide op IBM’s mainframesystemen.

S/38-databasemijlpalen
De originele S/38-database had geen naam, en het was pas veel later – nadat IBM de S/38 van naam veranderde in AS/400 en de ondersteuning voor SQL aankondigde – dat IBM de geïntegreerde DBMS aanduidde als ‘DB2’.

Jarenlang volgde de geïntegreerde database van de S/38 tevens een andere weg dan ander werk van IBM’s divisies op relationele systemen. In de objecthiërarchie van de S/38-architectuur was het overkoepelende objecttype een file – een abstracte bron of doel voor gegevens. File-objecten waren verder onderverdeeld als device files en database files. Database files waren blijvende opslagplaatsen met een tabelachtige structuur. Ze waren gecategoriseerd als physical files, die actuele gegevens bevatten, en logical files, die een tabelachtig perspectief weergaven van de onderliggende gegevens in een of meer physical files.

Hoewel de ‘file’-terminologie van de S/38 anders was dan de ‘table’- en ‘view’-terminologie die de standaard zou worden in relationele DBMS’en, was de S/38-benadering zo goed uitgedacht dat het perfect diende als de fundering van IBM’s introductie van SQL, jaren nadat de S/38 voor het eerst werd ontworpen.

IBM kon compiler- en DBMS-integratie leveren omdat het de enige aanbieder was van deze faciliteiten op de S/38. Deze integratie was niet aan de orde voor de brede reeks aan programmeertalen en relationele DBMS’en die beschikbaar waren – en nog steeds zijn – op andere platformen. Daarom missen de meest moderne talen het integratieniveau en de eenvoud van databaseprogrammeren dat de S/38 (en System i) te bieden heeft. Ontwikkelaars, met name die gebruikmaken van SQL, vertrouwen het meest op ontwikkeltools voor het genereren van de noodzakelijke code om routines op te roepen uit databibliotheken als JDBC en ODBC.

Vele jaren zouden verstrijken voordat DB2 en SQL eindelijk naar de AS/400 zouden komen, en tijdens die jaren werden er andere belangrijke features toegevoegd aan de S/38-database. In release 8.0 van Control Program Facility (CPF) werd bijvoorbeeld het Open Query File (OpnQryF)-commando geïntroduceerd. Dit complexe commando zorgt ervoor dat een programmeur een brede reeks aan selectie-, formatteer-, join-, groepeer- en orderverrichtingen kan specificeren op het moment dat een programma wordt uitgevoerd. Parameterwaarden van het OpnQryF-commando waren veelal strings die door een CL- of HLL-programma geconstrueerd konden worden en vervolgens werden geleverd als het OpnQryF-commando werd uitgevoerd. Dit commando zorgde voor een enorme impuls in de flexibiliteit die applicaties aan de eindgebruiker konden aanbieden.

De AS/400 en SQL – eindelijk!
Terwijl de rest van de commerciële computerwereld zich verplaatste richting relationele DBMS’en (bijvoorbeeld IBM’s eigen mainframe DB2, Oracle, Informix en Ingress), bleef de S/38 in zijn eigen comfortabele en beschermde wereld. Het belangrijkste ding in de hoofden van S/38-ontwikkelgroepen was destijds niet of IBM wel of niet de S/38-database zou voorzien van een SQL-interface, maar of IBM de S/38 überhaupt zou laten leven.

Toen, na zeer veel speculatie, op 21 juni 1988, lanceerde IBM de AS/400, ook wel bekend als ‘Silver Lake’, ook wel bekend als de volgende release van de S/38-architectuur, inclusief de originele geïntegreerde database. Dit was tijdens IBM’s System Application Architecture (SAA)-tijdperk, en IBM beloofde SQL in de volgende release.

De eerste release van SQL/400 kwam er in november 1988. Hoewel het een welkome toevoeging was, was SQL/400 totaal niet in vorm om de rol van werkpaard over te nemen voor de productie van AS/400-applicaties. De eerste versie ondersteunde zelfs geen SQL-subqueries – een cruciale SQL-feature. En het was zeer traag. Pas in V1R3 van OS/400 in 1990 voegde IBM subqueries toe, en zelfs toen was SQL nog steeds minder dan versies op IBM’s andere platforms. Zelfs basiskenmerken als ‘date column type’ en ‘null support’ waren afwezig. Deze features arriveerden in 1992 met V2R1M1, samen met de ondersteuning voor gedistribueerde databases via IBM’s Distributed Relational Database Architecture (DRDA)-protocol.

Een nieuwe naam: DB2/400
Toen V3R1 in augustus 1994 werd geleverd, werd de AS/400-database eindelijk geadopteerd in de IBM-databasefamilie en kreeg het een naam: Database 2 for AS/400, ofwel DB2/400. De release liet tevens zien dat IBM SQL op de AS/400 serieus begin te nemen. De release bevatte onder andere referentiële integriteit, stored procedures en triggers (maar alleen geschreven in een HLL). Een nieuwe query optimizer werd tevens geïntroduceerd als onderdeel van een algehele impuls voor SQL-performance.

Met de introductie van zowel de RISC-gebaseerde AS/400’s als V3R6 in 1995 verbeterde IBM tevens SQL/400 met een call-level interface (CLI). Maar het grote nieuws was dat DB2/400 symmetric multiprocessing (SMP) zou ondersteunen voor het besturen van meerdere processors in n-weg machines. Dit parallelle verwerkingsvermogen bood DB2/400 een voet tussen de deur naar op zwaar werk berekende online transaction processing (OLTP)- en OLAP-applicaties.

V4R2 leverde in 1998 SQL’s Stored Procedure Language (SPL) voor het schrijven van SQL stored procedures en triggers, het controleren van constraints, en beveiliging op kolomniveau. IBM pakte de draad van DB2-ontwikkeling op door later dat jaar te volgen met V4R3. Hoewel deze release aliassen en subselects toevoegde, concentreerde het zich hoofdzakelijk op performance, met inbegrip van de toevoeging van gecodeerde vectorindexen (EVI’s).

Het ontstaan van een Universal Database
Door de toevoeging van een reeks aan nieuwe eigenschappen in V4R3 in 1999, verhief IBM eindelijk de AS/400-database naar de topposities van haar DBMS-producten, en veranderde Big Blue het van naam in DB2 Universal Database for AS/400, of afgekort UDB/400. Deze release breidde het aantal ondersteunde datasoorten uit ter ondersteuning van character en binary large objects (CLOB’s en BLOB’s) en datalinks, referenties naar bestanden die buiten de relationele database zelf zijn opgeslagen.

In 2000 bracht V4R5 een verbetering van de beheersbaarheid van UDB/400 door de uitbreiding van Operations Navigator in V4R4 voort te zetten. Het mooiste item was de Visual Explain-tool voor het analyseren van het toegangsplan van een query. De nieuwe ‘run anywhere’-taal Java werd toegevoegd aan de lijst van talen waarin stored procedures geschreven konden worden.

De volgende release, V5R1, ondersteunde SQL-triggers geschreven in SPL. De DB2 Extender- en DB2 Text Extender-leden van IBM’s DB2 UDB-familie kwamen beschikbaar voor de iSeries (de nieuwe naam voor de AS/400).

Klaar voor de toekomst
IBM voerde een van de grootste veranderingen sinds jaren door in SQL/400 toen het in 2002 in V5R2 een nieuwe query optimizer introduceerde: de SQL Query Engine (SQE). SQE is een compleet nieuwe technologie voor snellere afhandeling van SQL-statements. Het zal uiteindelijk de voorgaande optimizer, nu bekend als de ‘Classic Query Engine’ (CQE), verdrijven. In deze eerste release handelde SQE alleen een subset van SQL-statements af, maar de komst van het product gaven twee dingen aan: dat IBM het concurrentievermogen van de iSeries op het gebied van commerciële DBMS bleef verbeteren, en dat RLA niet langer voordeel zou halen uit vele technologische ontwikkelingen.

Samen met een nieuwe naam voor het systeem – System i5 – kwam V5R3 in 2004 voorbij met zowel een uitbreiding van de SQL-queries voor de SQE als met het verbeteren van de SQE-performance. Deze release voegde except en intersect joins toe, functies voor data-encryptie, en materialized query tables; slechts een paar druppels uit de continue stroom aan nieuwe databasefeatures.

Nu, na een database-evolutie van drie decennia, komen we bij V5R4, die afgelopen jaar werd vrijgegeven. Met mogelijkheden waar geen enkele S/38-ontwikkelaar ooit over had durven dromen, die nu beschikbaar zijn op de S/38 – ik bedoel de System i. De laatste release biedt recursive joins en self referencing views. We hebben zelfs ‘instead of triggers’ gekregen, die, samen met andere dingen, alle features bieden van die updateable join file die ons een goede twintig jaar geleden werd beloofd!

En wie had zich toen ooit kunnen bedenken dat we ooit een volledige SQL-precompiler-ondersteuning zouden zien voor een free-format versie van RPG?.

Paul Conte is technisch redacteur voor System iNEWS en directeur van PCES in Eugene, Oregon (VS). U kunt Paul bereiken via pconte@picante-soft.com.