Forside
CV
Nøgletalsdatabasen
   Funktionalitet
   Historie
   Teknik
   Statistik
   Visioner
Blanketsystemet
Kontakt
Links
Log ind

Historie

Indledning

Nøgletalsdatabasen blev født i 1989 som en tegnbaseret Oracle/VMS applikation, har været vejen forbi PL/1, SAS, og er nu atter en ren Oracle/web applikation. I alle årene har Oracle været anvendt som database, men brugergrænsefladen har levet et spændende liv.

Forms 3.0 og PRO*PL/1 userexit

Nøgletalsdatabasen blev udviklet som et af de første Oracle/VMS systemer i ministeriet i sql*forms 2.3 omkring 89/90 og meget hurtigt omlagt til forms 3.0. Jeg forsøgte at anvende forms også til præsentation af opslag af nøgletal, men skærmbilledet og triggerne blev hurtigt for stort og umuligt at vedligeholde. Derfor blev opslag og præsentation af nøgletal i stedet for implementeret som en PRO*PL/1 userexit. Det var før C blev ministeriets officielle programmeringssprog i forbindelse med Oracle systemer. Systemet fungerede udmærket, men var svært at lære pga. de mange funktionstaster i Oracle forms og de mange specialtaster i præsentationsprogrammet. Afgrænsningen af opslag tog typisk omkring 2 minutter og var en relativ kompliceret proces. Præsentationen derimod var hurtig og fleksibel, men selvfølgelig kompliceret at vedligeholde pga. userexit. Som en meget brugt funktion blev der implementeret overførsel af nøgletal til fritstående 20/20 regneark.

NDB-server

Pga. problemer med antal cursors i Oracle og som et forsøg på forbedring af performans ved opslag af nøgletal, blev der implementeret en PRO*C server proces der vha. proces kommunikation slog nøgletal op. Dette flyttede selve opslaget af nøgletal ud af userexit til præsentation af opslag. Desuden blev der implementeret lagerfunktion i server-processen, således at allerede opslåede nøgletal blev gemt i det interne lager i server-processen. Dette betød dels en bedre performans ved gentagne opslag af de samme nøgletal og dels en reduktion af det samlede antal åbne cursors, idet det nu var ndb-server processen, der slog nøgletal op i stedet for de enkelte klient-processer.

Overførsel til lotus 123

Som første lille skridt i forbindelse med overgang til pc'ere blev overførslen til 20/20 omlagt til mail af 20/20 regneark til lotus notes. I memoet kunne regnearket åbnes/frakobles som et lotus 123 regneark. Dette fungerede udmærket, bortset fra problemerne med mail af regneark fra Allin1 til lotus notes. Overførselstiden kunne variere fra 30 minutter til flere dage …

SAS/Frame, SCL og objekt orienteret programmering

I midten af 1990'erne blev brugergrænsefladen ændret til en SAS/Frame applikation, med en SAS client/server forbindelse til VMS, hvor selve opslag af nøgletal skete.

Resultatet af første SAS-version var en applikation, der var meget hurtigere og mere brugervenlig end den oprindelige forms 3.0 applikation, men også en applikation hvor det meste af koden var samlet i hovedskærmbilledet. Dvs. valg af database, opdeling, drill/swap, valg af værdier i de forskellige dimensioner samt opslag af nøgletal. Skærmbilledet blev for stort til, at det kunne oversættes i debug mode, og umuligt at vedligeholde. Derfor blev applikationen nu omprogrammeret ved brug af objekt orienterede programmeringsteknikker. Stadigvæk med den samme Oracle database som i forms 3.0 versionen. Meget af applikationens kode var nu flyttet ud i de enkelte objekter, og applikationen var blevet meget lettere at vedligeholde.

Og mht. lotus 123 regneark brugte jeg DDE kommunikation, og tiden for overførsel til 123 var nu nede på 15 sekunder.

Fra SAS client/server imod ODBC

Ovenstående applikation benyttede sig af SAS client/server. Opslag tog under lav belastning omkring 15 sekunder for opslag og præsentation af nøgletal. Ved opslag under belastede forhold eller ved opslag af større datamængder kunne svartiden nå helt op på 30-60 sekunder. Stadigvæk bedre end forms 3.0 applikationen, men ikke særligt tilfredsstillende.

Det næste skidt var at få direkte forbindelse til Oracle og dermed undgå den lange vej via SAS client/server og PL/1-server proces til Oracle. Jeg omlagde selve opslag af nøgletal til ODBC og nåede ned på omkring 4-5 sekunder for opslag og præsentation.

SAS/Frame, OO-programmering og ODBC

På trods af anvendelse af OO-programmering i SAS/NDB var applikationen stadig svær at vedligeholde, og især administrationssiden af nøgletalsdatabasen var tung. Disse erfaringer, sammen med ønsket om at anvende ODBC i stedet for SAS client/server til forbedring af performans, samt et ønske fra Steffen Jensen fra Økonomiafdelingen om at kunne demonstrere nøgletalsdatabasen på en bærbar pc i Moskva, satte gang i næste omprogrammering.

Databasen blev totalt redesignet. Samtidig blev chancen brugt til at gøre nøgletalsdatabasen til et decentralt og generelt system, hvor det ikke på forhold var hardkodet, hvordan og til hvad den lokale nøgletalsdatabase skulle bruges i afdelingerne. Databasen er nu åben for indlæggelse af egne nøgletal, kodesystemer, forspalter og opdelinger. Bruger context blev gemt i Oracle tabeller. Antal sql operationer blev minimeret, da der nu var ODBC, der var flaskehalsen. Antal og størrelse på selects blev minimeret, og hentede data blev lagret i interne SCL-lister (pointerkæder). Resultatet var svartid på omkring 2-3 sekunder ved opslag/præsentation af mindre opslag, samt 0-1 sekunder ved drill/swap transaktioner.

Ndb på WWW

I ministeriets edb kontor havde jeg allerede lavet et par Oracle web applikationer. Der blev anvendt PL/SQL web toolkit. Dvs. man anvender pl/sql til at udskrive html kode dynamisk. Dels et case genereret system (Oracle designer) og dels et meta-data baseret indberetningssystem (blanketsystemet). Det meta-data baserede system viste sig at være det mest fleksible og letteste system at bruge og blev til Undervisningsministeriets nuværende indberetningsystem.

Det var derfor oplagt at forsøge at anvende PL/SQL web toolkit som brugergrænseflade til nøgletalsdatabasen, bl.a. fordi alle data allerede lå i Oracle, og databasen var meta-data baseret.

Resultatet er den databasen I ser i dag. Her gemmes bruger context i databasen, og hvert klik og valg i web grænsefladen bliver til et kald af en stored pl/sql pakke, der så generer det næste html skærmbillede osv. osv. Databasen har i dag 150.000 unikke brugere om året, og applikationen er blevet tunet for hurtige svartider og mange samtidige brugere. Context deles på tværs af brugerne, så skrivninger til databasen minimeres. Stort set al skrivning sker, når første bruger åbner en gemt præsentation. For det meste er svartider nede på ca. 1 sek.

 
-    Jan-Roslind.dk    -