Operational Querying

Hoe belangrijk is operationele data binnen een informatieomgeving? Wat is het verschil tussen lokale data en centrale data? Wat is het belang van decentralisatie en standaardisatie? Belangrijke vragen die in dit artikel aan bod komen.

Dataverkeer

Elke onderneming heeft onherroepelijk een bepaalde hoeveelheid data, waarvan de aard afwijkt in functie van de afdeling. We kunnen dus in zekere mate stellen dat de diversiteit van de data afhankelijk is van het aantal afdelingen. De data vindt haar weg naar de database via diverse wegen. Meestal is dit via een manuele invoer binnen schermtoepassingen, in andere gevallen kan dit verwezenlijkt worden door batchprocedures of via het opladen van externe bestandsgegevens. Waar de informatie fysisch opgeslagen wordt is in casus informatieverwerving van minder belang, zolang ze maar toegankelijk is. Het extrageren van data na de invoer veroorzaakt een gegevensstroom in de tegenovergestelde richting. We kunnen bijgevolg het dataverkeer in twee types opsplitsen, het inkomende dataverkeer -of input- en het uitgaande dataverkeer -of output. Beide definities moeten geïnterpreteerd worden vanuit het standpunt van de server en niet vanuit dat van de gebruiker. Data verwerken in een productieomgeving heet Online Transaction Processing (OLTP). Dit betekent zoveel als het live verwerken van data en omvat zowel de inputrichting als de outputrichting van de gegevensstroom. Er bestaan in de literatuur heel wat definities voor het begrip OLTP. Het belangrijkste kenmerk doorheen alle definities is het transactionele aspect, een aspect dat enkel thuishoort in een operationele omgeving. Een OLTP transactie zal zich dus steeds toespitsen op de verwerking van zogenaamde productiedata. Een dergelijk systeem rijmt in de meeste gevallen met het beheren van een relationele database of DBMS (Data Base Management System), een gestandaardiseerde structuur die transactionele OLTP processen in goede banen leidt. Het omvat het geheel van inkomende en uitgaande communicatie en is overkoepeld met een geïsoleerde securitylaag die de integriteit van de data in stand moet houden. Een moderne DBMS, zoals Oracle of SQL Server, voorziet tevens in diverse methodes voor efficiënt databeheer en performance tuning. We kunnen dus stellen dat de DBMS een solide laag vormt tussen de fysische data en de bronnen die geleid hebben tot de creatie ervan.

Lokale data

Wat vaak vergeten wordt is dat er binnen elke onderneming een grote hoeveelheid data aanwezig is die niet centraal beschikbaar is. Ze bevindt zich op de harde schijven van de desktop computers of in het beste geval op een of andere drive van het filesysteem binnen het netwerk. De lokale aard van dergelijke data neemt niets weg van de belangrijkheid ervan, zeker vanuit het standpunt van de persoon die de informatie beheert. Er zijn ettelijke redenen voor het decentraal bewaren van data, maar de voornaamste is wel het feit dat de business vaak veel sneller evolueert dan de ICT-ontwikkeling binnen de onderneming. Het beheren van lokale data omzeilt in zekere zin de nood aan directe programmatie, een proces dat vaak gepaard gaat met belangrijke vertragingen. Hoewel er geen twijfel bestaat dat het centraal beheren van data in theorie de enige efficiënte methode is, toch zal er altijd een behoefte blijven bestaan aan het in stand houden van lokale data. Het businessaspect van de onderneming heeft nu eenmaal voorrang op het technische aspect.

Externe data

Niet alle gegevens vinden hun oorsprong binnen de onderneming. Het is niet ondenkbaar dat er externe bestanden aangeleverd worden door andere partijen. Zo kan een aankoopafdeling bijvoorbeeld de artikelgegevens en –prijzen van een grote leverancier opladen binnen de centrale ERP-applicatie. Een ander voorbeeld kunnen we zoeken in de CRM omgeving, waar vaak heel grote adresbestanden aangekocht worden voor mailingdoeleinden. Tegenwoordig beschikt men tevens over de mogelijkheid om allerhande informatie te downloaden van het Internet. Een praktisch voorbeeld is de verwerving van geografische gegevens van landen waarmee men zaken doet. Die informatie kan meestal verkregen worden bij de overheid van de bewuste landen en toegankelijk gemaakt worden via een internettoegang. Misschien wil men bij het aanmaken van een nieuwe klant wel even controleren of de opgegeven straat wel bestaat binnen het stratenplan van zijn land? Of misschien wil men de structuur van zijn telefoonnummer gaan checken in functie van de telefoonzones van dat land? In dergelijke situaties zijn die gegevens onmisbaar. Het formaat van de externe data kan in een dergelijke mate afwijken van het DBMS formaat, dat er heel wat programmeerwerk aan te pas komt om het inladen mogelijk te maken. Vandaar dat de klassieke tekst- of spreadsheetgerichte verwerkingen meer en meer vervangen worden door standaardformaten. Zo is het XML-formaat, wat staat voor eXtensible Markup Language, de laatste jaren uitgegroeid tot een van de meest gebruikte formaten voor wat betreft het aanleveren en opladen van externe data. XML is gebaseerd op een vaste hiërarchische structuur van zogenaamde tags, die rekening houdt met diverse gestandaardiseerde ISO-formaten of character sets. Hoewel de initiële ontwikkeling van XML zich vooral toespitste op een Internet-gerelateerd gebruik, biedt de unieke aard ervan heel wat ruimte voor andere aanwendingen. Het principe van standaardisatie maakt een uitgebreide vorm van multi-platform communicatie mogelijk en zorgt er tevens voor dat datatransfers heel wat eenvoudiger kunnen verlopen. Ook Oracle was niet blind voor deze evolutie en integreerde binnen zijn DBMS diverse XML-functionaliteiten. Zo is het tegenwoordig perfect mogelijk om een volledig XML document in zijn geheel binnen een veld van een tabel op te slaan, zoals dit bijvoorbeeld ook al mogelijk was voor grafische bestanden (het zogenaamde LOB-principe). Deze distantiëring van het filesysteem brengt heel wat extra mogelijkheden met zich mee naar verdere verwerking, archivering en back-up toe. In vergelijking met de stroeve structuur van de klassieke tekstbestanden kan de soepele aard van XML bij informatieverwerking dus een grote meerwaarde betekenen. Figuur 1 vat nog even samen hoe het inkomende dataverkeer zijn weg kan vinden binnen de operationele omgeving en hoe de bekomen informatie fysisch gestructureerd kan worden.

Query & analyse

Door de fysische verspreiding van de data en de diversiteit van de aard wordt het een helse opdracht om binnen een operationele omgeving met betrouwbare informatie naar voor te komen. Vandaar dat data extractie op een OLTP systeem beter beperkt blijft tot een aanwending voor strikt operationele doeleinden. Als voorbeeld kunnen we een boekhouder aanhalen die dagelijks een overzicht bekomt van de openstaande facturen. Dit is een vorm van informatie die tevens van belang kan zijn voor een financiële auditor, wanneer die bijvoorbeeld het betalingsgedrag van de klanten onderzoekt. De informatie is echter te beperkt om een definitief oordeel te kunnen vellen daar belangrijke factoren, zoals de financiële toestand van de klant of de marktsituatie van de branche waarbinnen de klant opereert, ontbreken. De auditor dient deze extra informatie te zoeken via andere informatiebronnen, die vermoedelijk structureel zullen afwijken van de lijst van de boekhouder. Vandaar dat een operationele omgeving helemaal niet geschikt is voor analytische rapportering. Elke poging om dit toch enigszins te simuleren verwatert meestal in tijdsverlies en data-inconsistentie.Stel nu dat de data toch zodanig gestructureerd is dat er enige analytische mogelijkheden zijn, dan blijft er nog steeds de kwestie van performantie en bezetheid van het systeem. Input en output dienen zoveel mogelijk van elkaar gescheiden te worden. Aangezien beide op hetzelfde systeem plaatsgrijpen, zal er in bepaalde gevallen een vertraging optreden, zeker wanneer de input en de output toegang zullen zoeken tot dezelfde databasetabellen. Naar output toe zijn wachttijden vervelend, maar niet onoverkomelijk. De input mag echter geen belemmeringen ondervinden, want daar ligt net de basis van het bestaan van de data. Zonder de input kan er geen extractie bestaan. Ze primeert dan ook boven de output. De data extractie op een operationeel systeem dient zich dus zoveel mogelijk te beperken tot het consulteren van specifieke informatie die bedoeld is voor de courante werking van de onderneming. Ze dient zoveel mogelijk te bestaan uit queries die op basis van een unieke sleutel - of primary key- de data kunnen ophalen. Het opvragen van informatie over langere periodes of vanuit diverse perspectieven is te vermijden omdat de structuur van een operationele omgeving hiervoor nu eenmaal niet geschikt is.

Data-extractie

In de praktijk bestaan er diverse mogelijkheden om operationele data te extraheren. De meest voorkomende en meest rudimentaire vorm is het opvragen van een beperkt aantal records vanuit de schermtoepassingen waar de initiële input plaats vond. Dergelijke extracties zullen vanzelfsprekend zelden of nooit performantieproblemen met zich meebrengen. Ze verstrekken echter ook heel weinig globale informatie en hebben dus enkel een heel specifiek nut. Een algemenere vorm van data extractie is de rapportering, een term die al enkele keren aan bod kwam en die we hier dienen te interpreteren in de meest ruime zin van het woord. Elk overzicht van data, in om het even welke vorm, dat bekomen wordt buiten de normale schermtoepassing om, kan gecategoriseerd worden als zijnde een rapport. Hoewel een rapport een globalere aard heeft dan een schermopvraging, is het toch aangewezen om de hoeveelheid data die met rapportering gepaard gaat enigszins te beperken. Met operationele rapporteringtools als bijvoorbeeld Oracle Reports kunnen heel complexe zaken gerealiseerd worden, zaken die af en toe zelfs heel nauw aansluiten met de functies van analytische rapporteringtools. Het functionele nut van beide ligt echter heel ver uit elkaar. Zo is het niet aangewezen om in een operationeel rapport de mogelijkheid te voorzien om dynamisch een bepaalde selectieperiode op te geven, bijvoorbeeld bij een extractie van factuurgegevens op basis van de factuurdatum. Op deze wijze wordt de poort geopend naar mogelijke performantieproblemen. De gebruiker definieert steeds de parameters in functie van de eigen behoefte en kan hierbij - weliswaar volledig onbewust- voor belangrijke technische belemmeringen zorgen.

Decentralisatie

Wanneer de behoefte aan informatie het operationele overstijgt en de eerder aangehaalde principes inzake performantie en datakwaliteit niet langer kunnen gegarandeerd worden, dient de data gedecentraliseerd te worden. Ze dient met andere woorden losgekoppeld te worden van de operationele omgeving. Het decentraliseren van data is in de eerste plaats een technische aangelegenheid en zal dus vooral berusten in diverse systeemtechnische handelingen. Deze fysische afscheiding blijft niettemin volledig afhankelijk van de gebruikersdoeleinden en kan dan ook pas echt ingepland en uitgevoerd worden na de analyse van de functionele behoeften. Nog voor deze behoeften in detail gekend zijn kan men al stellen dat er nood zal zijn aan een aparte server. Het is onbegonnen werk om een informatieomgeving te creëren op dezelfde machine als deze waarop de OLTP database zich bevindt. Dit neigt tot enige overweging wanneer de hoeveelheid data zodanig beperkt is dat een gemeenschappelijke omgeving geen performantieproblemen met zich kan meebrengen. Maar zelfs in die situatie is een fysische scheiding aangewezen, aangezien de rapporteringomgeving voor wat betreft data extractie in zeker mate als een cluster kan beschouwd worden van het OLTP systeem. Vanzelfsprekend hangt alles af van de budgettaire mogelijkheden die gepaard gaan met deze operatie. Alvorens een analyse kan gemaakt worden van de data-afscheiding dienen beide systemen dezelfde taal te spreken. Er dient met andere woorden een uniformisering te gebeuren van de gebruikte gegevens. Al te vaak wordt een dergelijke uniformiteit geïmplementeerd bij het afzonderen van de data, los van de transactionele omgeving. Toch is het veel verstandiger om deze oefening reeds te maken op het OLTP systeem, zelfs voor er enige sprake is van data-afscheiding.

Standaardisatie

Het is geen uitzondering dat de data van een onderneming in de loop der jaren vervuild is geraakt door de parallelle werking van de business processen. Elk aspect van de business bevindt zich als het ware op een eiland en heeft zijn eigen specifieke manier van coderen, een manier die trouwens algemeen gekend is en geaccepteerd wordt door de medewerkers van de respectievelijke business processen. Meestal ligt de oorzaak van deze vervorming bij de historische groei van de onderneming. Zoals aangehaald hebben functionele businessuitbreidingen steeds voorrang op technische interventies en bij het opstarten van een bedrijf denkt men in de eerste plaats aan het stockeren van de data en maakt men zich nog weinig zorgen over de eventuele data extracties die zullen volgen. In functie van de evolutie van de onderneming ontstaat op een gegeven ogenblik de behoefte aan een uniforme manier van coderen. Business processen raken meer en meer met elkaar verbonden, zelfs indien de betrokken afdelingen losse segmenten blijven vertegenwoordigen. In een dergelijke situatie berust de oplossing in de ontwikkeling van een centrale toepassing die de gebruikte codes gaat stroomlijnen. Wanneer een afdeling bijvoorbeeld een specifieke code hanteert voor een bepaald product, dan dient een andere afdeling perfect te weten over welk product het gaat. Pas dan kan een globaal beeld geschept worden en kan de bedrijfssituatie geëvalueerd worden over de business units heen. Bij grote ondernemingen die een aanzienlijke levensduur achter de rug hebben ligt het vanzelfsprekend allemaal niet zo eenvoudig. De “verkeerde” codes die men in de loop der jaren meesleurt doorheen de diverse applicaties, kunnen niet zomaar omgevormd worden naar een centrale codificatie. Er dienen impactanalyses te gebeuren op elk niveau van elke toepassing, er dienen conversies ingepland te worden, kortom een dergelijke operatie vraagt een zorgvuldige voorbereiding en tijd. En daar knelt vaak het schoentje: men kan onvoldoende tijd of budget vrijmaken voor een inspanning die vaak als “onderhoud” omschreven wordt. Niet iedereen staat te springen om af te stappen van de gekende werkomgeving. Gebruikers zijn perfect gelukkig met de situatie, vinden blindelings hun weg doorheen “hun” codes en staan dan ook vaak sceptisch tegenover wijzigingen. Dit is vaak ook het geval bij een redesign van de codering in functie van de bouw van een informatieomgeving. De mensen die de input van gegevens verzorgen zijn heel zelden dezelfde mensen als zij die de geëxtraheerde cijfers gaan analyseren. Aan de invoer van een centraal codebeheer gaat dus zeker een niet te onderschatten psychologische oorlogsvoering vooraf. Een ding is zeker: een informatieomgeving kan pas tot haar volle recht komen wanneer ze gevoed wordt door gestandaardiseerde informatie.