Ondanks dat we streven naar eenmalig registreren en meervoudig gebruik zullen we er vooralsnog mee moeten leven: kopietjes. D.w.z. kopieën van (delen van) bestaande databases. Kopiëren blijft nodig vanwege beperkingen van het netwerk, performance van verwerking, productieplanning, robuustheid of gewoon omdat een gekocht pakket alleen maar kan werken als de gegevens in de bij het pakket horende database zijn opgenomen.
Omdat kopietjes nodig zijn, wordt de software om te kopiëren op verschillende plaatsen op verscheidene manieren gemaakt. Allemaal door mensen met de beste bedoelingen, maar eigenlijk ook door de
verkeerde mensen. Degene die dit zouden moeten regelen zijn de DBMS, DWH en middleware vendors in combinatie met een XML-standaard.
Kopietjes
Vooraf: terminologie
Vóór dat ik uit de doeken doe hoe ik denk dat de vendors in deze behoefte kunnen voorzien even wat begrippen en bijbehorende terminologie. In de wereld van ICT hebben woorden vele betekenissen.
Als eerste even het onderscheid tussen (stukjes) data en gegevens. Het verschil is simpel: wat u hier voor u ziet is data, wat u zich daarbij voorstelt zijn gegevens.
De drie stukjes data: "Jan-Kees woont op Dorpstraat 1 Ons Dorp"
"Dorpstraat 1 Ons Dorp is het adres van Jan-Kees"
"Naam: Jan-Kees Adres: Dorpstraat 1 Ons Dorp
stellen hetzelfde voor. Er is dus maar sprake van één gegeven. Tenminste.. meestal vinden we van wel. Om het zeker te weten moeten we het uit- en afspreken. Binnen het werkingsgebied van de afspraken
geldt vervolgens dat we het gegeven op verschillende manieren kunnen representeren. Zeker voor computers is dit geen vanzelfsprekendheid. Dus als we willen dat die er mee om moeten kunnen gaan, dan moeten we het zeker (formeel) vastleggen.
XSD, Relationele DDL en Grammatica's kunnen we gebruiken om datastructuren mee te beschrijven. D.w.z. daar kunnen we datamodellen mee maken. Door daar equivalentierelaties op te definiëren kunnen we vervolgens de gegevens modelleren. Ik weet het. Dat is niet gebruikelijk, maar volgens mij wel beter. Trouwens, ORM (of FCO-IM) heeft een elegante manier gevonden om een groot gedeelte van deze equivalenties in één visuele taal te modelleren.
Een ander stukje data zou kunnen zijn: "'Dorpstraat 1 Ons Dorp' is een adres" Ook dat is de representant van een gegeven. En het gegeven in het eerste voorbeeld impliceert dit gegeven. Een manier om dat op te schrijven is:
""Jan-Kees woont op Dorpstraat 1 Ons Dorp" impliceert "'Dorpstraat 1 Ons Dorp' is een adres"" Deze regel is op zich ook weer een stukje data. Die regel hadden we ook op andere manieren kunnen beschrijven, net zoals gegevens. Het gegeven in het eerste voorbeeld ging over een persoon en een adres; deze regel gaat over twee gegevens. Ik hoop dat u het patroon ziet: regels zijn gewoon een bijzonder soort gegevens. Regels zijn gegevens over gegevens.
Gegevens zijn dus abstracties, die we op verschillende manieren kunnen representeren in data. Voordeel van computers is dat ze de data kunnen manipuleren zodat de resulterende data -mits op de goede manier gedaan- ook weer te interpreteren zijn als gegevens.
Noot. Sommige mensen noemen de dingen die ik gegevens noem feiten. Ik ben gewend aan het gebruik van het woord gegeven. Om zelf niet in verwarring te raken, gebruik ik even de terminologie waar ik mee vertrouwd ben. Ik vraag daarvoor begrip.
Kopiëren is een data aangelegenheid
Onder kopiëren versta ik dat data wordt gedupliceerd en eventueel wordt getransformeerd zonder verlies van gegevens. D.w.z. de oorspronkelijke data en de kopie-data zijn equivalent. Als ik de equivalentieregels goed en volledige heb gedefinieerd, dan kan ik de kopieersoftware dus controleren door te kijken of in alle gevallen transformatie gebeurt binnen de equivalentieklasse. Ok. Is geen makkie, maar daar hebben die mensen van de vendors voor gestudeerd, toch? Dat zouden ze moeten kunnen. Van een gemiddelde applicatieprogrammeur/-se, mogen we dat (helaas) nog niet verlangen.
Wat de vendors aan hun producten moeten toevoegen is dat je die equivalentierelaties moet kunnen toevoegen. Als we die regels dan ook nog op een slimme manier vastleggen, dan lijkt het me zelfs mogelijk dat de transformatie programmatuur (in veel van de nodige gevallen) gewoon gegenereerd kan worden. Zo, dat scheelt een hoop (applicatie)programmeerwerk!
Er is echter nog een hindernis te nemen: databases hebben de neiging om continu te veranderen, dus moet de kopie ook veranderen. Hoe doen we dat? Ik zie even drie mogelijke opties waar de leverancier je uit zou moeten laten kiezen:
Snapshot. In dit geval wordt op gezette tijden een kopie gemaakt van de gehele database. D.w.z. alle updates "even" tegenhouden en vervolgens een kopie maken.
Delta. In dit geval is er eerder al een kopie gemaakt: Oud. Oud wordt vergeleken met Huidig en de delta wordt naar de kopie-Oud gebracht. Daar wordt vervolgens een kopie-Huidig gemaakt. Wil je dit goed kunnen doen dan zul je echter wel een niet getransformeerde kopie-Oud nodig hebben om de delta te kunnen interpreteren. Meestal zie ik dat nu niet gebeuren.
Streaming ETL In dit geval worden de mutaties op de database gekopieerd en (na transformatie) doorgevoerd op de kopie-oud. De transformatie kan nodig zijn omdat de kopie geoptimaliseerd is op bevragen voor BI. Eventueel kunnen de transformaties van betekenis worden veranderd, in die zin dat een "update" op het origineel wordt omgezet naar een "insert" op de kopie, zodat de kopie wel volledige historie heeft, terwijl het origineel alleen de actuele gegevens heeft. Ook dat lijkt me te realiseren, zonder expliciete kennis van het domein, maar alleen op basis van formele technieken. Als voor de mutaties dan ook nog eens een fatsoenlijke XML-standaard kan worden afgesproken, dan kunnen we op die manier ook nog kopietjes maken over verschillende DBMS'sen....
Goed. Ik hoop dat u het heeft kunnen volgen. Ik hoop ook dat er onder de lezers ook vertegenwoordigers zijn van leveranciers. Ik zou willen zeggen: beste leveranciers, pak deze uitdaging op en verminder
de "kopieerlast" voor de applicatieprogrammeurs! Dan kunnen we ons vervolgens bezig houden met het creëren van een fatsoenlijke gegevensarchitectuur en wordt de vertaling naar de data-architectuur een stuk simpeler.
Comments (2)
Written by Ruud van Vliet on 21-10-2008 09:00
Jan, in mijn blog over gegevenskwaliteit kom ik juist tot de conclusie dat we moeten ophouden met kopiëren ... Waarom zo overtuigd dat kopiëren nódig is?
Als aanvulling de drie mogelijkheden: je mogelijkheden zijn sterk batch geörienteerd; daarnaast zou je door publish-subscribe of door caching (met een controle op wijziging) de wijzigingen kunnen propageren.
Hallo Ruud, In een sessie met een aantal cracks op dit gebied, zijn we tot de conclusie gekomen dat kopiëren toch nog wel nodig is voor bepaalde non-functional requirements: - kunnen variëren met de bezetting, productieplanning - robuustheid - performance - gebruik van standaard pakketten - .... Kopiëren is hier een - mogelijk niet DE - oplossing voor.
Verder, de eerste twee zijn inderdaad meer bulk (batch) georienteerd. De derde kan dat zijn, maar hoeft niet. Ook bij een publish-subscribe koppeling kun je (zou je kunnen) variëren met het moment waarop de wijzigingen worden gepropageerd: a) op het moment van wijzigen, de wijziging b) aan het eind van de dag, alle wijzigingen van die dag c) aan het eind van de week, alle wijzigingen van die week. Welke je kiest hangt af van: - gewenste actualiteit - kosten van een variant - bezetting van bron of doelsysteem (ivm planning resource verbruik) - ...
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
