In een voorgaand bericht zijn de objecten Grondwatermonitoringsput en Monitoringsbuis uitgewerkt als fictieve basisregistratieobjecten, en opgenomen in het datamodel van DEMO.
DEMO is via een tweetal ETL scripts gevuld met ca. 1.000 grondwatermonitoringsputten met 1.475 bijbehorende monitoringsbuizen waarvan de informatie vrij beschikbaar te vinden is op internet, en die gelegen zijn in de provincies Friesland en Noord Brabant. Alle objecten zijn ingelezen als ware het eigen objecten.
Als basisregistratieobject bevat een peilbuis maar een zeer beperkte set gegevens. De organisatie houdt echter veel meer gegevens bij, voor een deel voor de hele organisatie (de kern- of procesoverstijgende gegevens) en voor een deel specifiek voor afgebakende processen zoals Monitoren en/of In stand houden. In dit experiment wordt het proces In stand houden (beheer en onderhoud) betrokken. Belangrijk onderdeel van dit proces is Asset Management conform ISO 55000.
In bovenstaande plaat is de basisregistratie BRO en de kernregistratie DEMO gepositioneerd in het deel Asset Portfolio. De Asset lifecycle is wordt meestal ondersteund door een doelgericht informatiesysteem dat vaak wordt aangeduid als onderhoudsbeheersysteem (OBS).
Het OBS gaat uiteraard over het beheer en onderhoud van peilbuizen, en maakt daarbij gebruik van peilbuis stamgegevens.
Stamgegeven : Omschrijving of ander indicatief gegeven met een geringe wijzigingsfrequentie, zulks in tegenstelling tot muterende gegevens.
Deze gegevens ontstaan in het OBS of deze gegevens komen uit andere systemen en worden in het OBS overgetypt. Voor het experiment is een fictief client-server gebaseerd OBS ingericht dat gegevens bevat van 1475 peilbuizen. De ID's van de peilbuizen komen overeen met de ID's van de monitoringsbuizen uit de BRO. Op basis van dit attribuut zijn beide registraties te koppelen.
Nu komt de organisatie met de wens om basis- en kernregistraties in het OBS te integreren met onderhoudsdata. Dat is een flinke wijziging, het betekent dat de stamdata peilbuizen in het OBS voortaan bestaat uit de optelsom van:
- BRO basisregistratiegegevens: globale kenmerken peilbuis, locatie, eigenaar, functie
- DEMO kernregistratiegegevens: organisatiespecifieke eigenschappen
- OBS: procesgegevens onderhoud
De impasse die hier ontstaat is te doorbreken door samen vooraf goed na te denken over een concept architectuur. Uiteraard mist de input van de leverancier omdat het OBS in dit experiment een fictief systeem is, maar stel dat er uit een overleg toch een bruikbaar model is ontstaan dat in archimate taal is uitgewerkt met behulp van een archimate tool. Uit het model kunnen diverse architectuur schema's (views) samengesteld worden die gebruikt worden voor verdere detaillering en besluitvorming in het verandertraject. Hieronder het eerste architectuurproduct, een algemeen overzicht.
De uitgangspunten van het model zijn de principes van de organisatie:
1. beheer bij de bron,
2. eenmalige opslag - meervoudig gebruik,
3. eenduidig eigenaarschap en -beheer
en de constraint van de leverancier:
4. het huidige datamodel OBS kan niet worden aangepast.
Hier volgt een korte toelichting op de plaat:
Op de technieklaag (de groene elementen) is te zien dat het databaseplatform van DEMO en OBS van elkaar verschillen. Dit is een belangrijk gegeven.
Op de proceslaag (de gele elementen) is te zien dat het OBS gebruikt wordt door het proces In stand houden.
Het proces databeheer kent de bijzondere rol bronhouderschap. Dat betekent dat de organisatie kennelijk de (mede-) regisseur/producent is van de basisregistratie BRO. Uiteraard alleen voor de eigen peilbuizen.
De meeste complexiteit zit in de applicatielaag (de blauwe elementen).
In het OBS bestaat een dataobject stamdata peilbuis in de vorm van een fysieke databasetabel. In dezelfde databaseomgeving (MSSQL ) wordt een nieuw dataobject kerndata peilbuis(OBS) geintroduceerd, dat het dataobject stamdata peilbuis voor een belangrijk deel overlapt. De overlappende databaseattributen hebben identieke namen en datatypes.
In DEMO is een vergelijkbaar dataobject kerndata peilbuis(KR), dat wil zeggen dat attribuut namen en -datatypes gelijk zijn getrokken met kerndata peilbuis(OBS), maar dat het uiteraard wel in een andere databaseomgeving is geimplementeerd (PostgreSQL).
Deze twee kerndata dataobjecten worden gebruikt om een brug te slaan tussen DEMO en het OBS. Het proces databeheer is daarbij verantwoordelijk voor de inrichting en het beheer van het dataobject kerndata peilbuis(KR). Het proces In stand houden heeft geen inhoudelijke kennis van basis- en kernregistraties en zal met databeheer een overeenkomst aangaan (SLA) ten aanzien van het beheer en de beschikbaarheid van kerndata peilbuis(KR). Dit wordt mogelijk de kern van het succes. Ieder staat voor eigen taken en verantwoordelijkheden, de scheiding is helder.
De uitwerking van kerndata peilbuis(KR) door databeheer leidt tot een databaseview die voor de geautomatiseerde koppeling beschikbaar wordt gesteld (SLA). Nogmaals, het is een werkend, doch fictief voorbeeld.
CREATE OR REPLACE VIEW geostore.zoo8zh8d AS
SELECT
a.guid AS _PRFGUID,
c.name::character varying(24) AS _MBBHRDESCR,
d.gemeentena::character varying(50) AS _PRFMBGEMEENTE,
b.naam::character varying(36) AS _PRFMBCODE,
b.functie::character varying(25) AS _MBDLDESCR,
a.buisnummer::numeric(3) AS _PRFMBGFILTERNUMMER,
a.buistype::character varying(50) AS _PRFBSTYP,
a.status::character varying(20) AS _MBSTSDESCR,
a.lengte::numeric(6,3) AS _PRFMBGDIEPTEBUIS,
a.bovenkant::numeric(6,3) AS _PRFMBGBKPEILBUIS,
a.filtermateriaal::character varying(50) AS _MBGMDESCR,
a.filterdiameter::numeric(6,3) AS _PRFMBGDIAMETERFILTER,
a.filterbovenkant::numeric(6,3) AS _PRFMBGBKFILTER,
a.filteronderkant::numeric(6,3) AS _PRFMBGOKFILTER,
(((e.gemeente::text || e.sectie::text) || e.nummer))::character varying(15) AS _PRFMBGPERCEEL,
st_x(st_transform(b.geometrie, 4326)) AS _PRFGEOCODEX,
st_y(st_transform(b.geometrie, 4326)) AS _PRFGEOCODEY
FROM monitoringsbuis a
LEFT JOIN grondwatermonitoringsput b ON a.grondwatermonitoringsput = b.guid AND b.naamruimte::character varying(15) = ((( SELECT kvstore.value
FROM kvstore
WHERE kvstore.key::text = 'nsKvK'::text))::character varying(15))
LEFT JOIN bgt.administrativeunit c ON st_within(b.geometrie, c.geom) = true
LEFT JOIN dkk.gemeente d ON st_within(b.geometrie, d.geom) = true
LEFT JOIN dkk.perceel e ON st_within(b.geometrie, e.the_geom) = true;
Wat valt op?
- dat monitoringsbuis is kennelijk het centrale object in OBS is, aangevuld met wat data van grondwatermonitoringsput (naam, functie en ligging) en wat locatiegegevens (gemeente, kadastraal perceel, lokale overheid).
- Er wordt nu gefilterd op eigendom peilbuizen (eigenaarschap = KvK nummer van de organisatie), uiteraard zijn op basis van de naamruimte ook andere afspraken te maken (zie eerdere berichten).
- Veel attributen in PostgreSQL zijn ruim gedimensioneerd, bijvoorbeeld als datatype text. MSSQL databases (en daarmee ook OBS) zijn in dimensionering veel restrictiever en zien liever datatypes als character varying(xx).
- OBS kent geen geometrie attribuut, wel numerieke x en y kolommen. Deze kolommen bevatten bovendien LON/LAT waarden die gebruikt worden in navigatiesystemen (om met een TOMTOM naar een peilbuis toe te kunnen rijden). DEMO gebruikt een ander coordinatensysteem, zodat een conversie noodzakelijk is.
De runtime voor het opvragen van alle 1475 peilbuizen in deze view is ca. 1 sec.
In volgende berichten worden drie koppelscenario's uitgewerkt, een ETL koppeling (1) en een realtime linked-server koppeling (2) waarbij de werking en inrichting van het OBS niet wordt aangepast, en een koppeling op basis van services (3), waarbij het OBS ingrijpender wordt aangepast.
In volgende berichten worden drie koppelscenario's uitgewerkt, een ETL koppeling (1) en een realtime linked-server koppeling (2) waarbij de werking en inrichting van het OBS niet wordt aangepast, en een koppeling op basis van services (3), waarbij het OBS ingrijpender wordt aangepast.
Geen opmerkingen:
Een reactie posten