BE1029521B1 - Een collaboratief gegevensbeheersysteem en werkwijze voor meerdere gebruikers - Google Patents

Abstract

Een collaboratief gegevensbeheersysteem voor meerdere gebruikers is voorzien. Het systeem omvat een relationele gegevensbank met een veelheid van gegevenspunten, een communicatie-interface ingericht om gebruikers toe te laten de relationele gegevensbank te raadplegen, en een versiecontrole-inrichting ingericht om opeenvolgende historische versies van elk gegevenspunt van de veelheid van gegevenspunten in de relationele gegevensbank bij te houden.

Description

Een collaboratief gegevensbeheersysteem en werkwijze voor meerdere gebruikers

DOMEIN VAN DE UITVINDING De uitvinding heeft betrekking op een collaboratief systeem en computer geïmplementeerde werkwijze voor gegevensbeheer voor meerdere gebruikers. De uitvinding heeft ook betrekking op het voorzien van een collaboratief systeem met gegevensbeheer voor meerdere gebruikers. Voorts heeft de uitvinding betrekking op een computerprogrammaproduct en een inrichting.

ACHTERGROND VAN DE UITVINDING Er bestaan diverse inhoudsbeheersystemen (IBS). Zulke systemen zijn typisch ingericht om de creatie en modificatie van digitale inhoud of gegevens te beheren. Een IBS zou bijvoorbeeld voor webinhoudsbeheer of bedrijfsinhoudsbeheer (BIB) gebruikt kunnen worden. Zulk bedrijfsinhoudsbeheer kan meerdere gebruikers in een collaboratieve omgeving ondersteunen door bijvoorbeeld documentbeheer, digitale middelenbeheer en recordbehoud te integreren.

Momenteel kunnen collaboratieve systemen platforms omvatten, zoals Sharepoint en Dropbox, om samenwerking mogelijk te maken. Op deze manier kunnen meerdere gebruikers gelijktijdig aan dezelfde bestanden werken. De gegevens worden typisch bewaard op een zeer gedistribueerde (gefragmenteerde) heterogene en ongestructureerde manier. Manueel updaten van gegevens die bewaard zijn over verschillende bronnen is zeer gevoelig voor fouten en onnauwkeurigheden. Daarbij is het niet altijd duidelijk welke gegevensbestanden de meest up-to-date informatie bevatten. Dit beperkt beduidend de transparantie van gegevensbeheer (bijv. fiscaal beheer, gegevensadministratie, etc.).

De nood aan samenwerking op afstand wordt steeds belangrijker. Deze systemen hebben echter vaak moeilijkheden met efficiënt gegevensbeheer voor meerdere gebruikers, vooral wanneer een groot aantal gebruikers en teams met meerdere gebruikers samenwerken. Dit heeft niet alleen een nadelig effect op de werkefficiëntie, maar kan ook het risico op fouten in gegevensbeheer beduidend vergroten. De nodige informatie of gegevens verzamelen kan veel tijd kosten. Er is een wens om vertragingen te beperken bij het bijeenbrengen van gegevens of informatie om te verouderde versies voorkomen die zouden kunnen resulteren in gegevensconflicten. Voorts kan gegevensonnauwkeurigheid leiden tot niet- naleving, wat dan weer kan resulteren in significante financiële kosten voor bedrijven.

Er is een nood om werkefficiëntie en nauwkeurigheid beduidend te verbeteren in collaboratieve gegevensbeheersystemen voor meerdere gebruikers.

SAMENVATTING VAN DE UITVINDING Het is een doel van de uitvinding om een werkwijze en een systeem te voorzien dat ten minste één van de bovengenoemde nadelen wegneemt.

Als aanvulling of alternatief is het een doel van de uitvinding om een verbeterd systeem en werkwijze te voorzien voor samenwerking voor meerdere gebruikers in gegevensbeheer.

Als aanvulling of alternatief is het een doel van de uitvinding om een collaboratief systeem met verbeterde efficiëntie in gegevensbeheer voor meerdere gebruikers te voorzien.

Als aanvulling of alternatief is het een doel van de uitvinding om een collaboratief systeem voor meerdere gebruikers met gereduceerd risico op fouten of conflicten in gegevensbeheer te voorzien.

Als aanvulling of alternatief is het een doel van de uitvinding om verbeterde samenwerking in gegevensbeheer op een relationele gegevensbank te voorzien.

Daartoe voorziet de uitvinding een collaboratief systeem voor gegevensbeheer voor meerdere gebruikers, het systeem omvattende: een relationele gegevensbank met een veelheid van gegevenspunten; een communicatie-interface ingericht om gebruikers toe te laten de relationele gegevensbank te raadplegen; en een versiecontrole-inrichting ingericht om opeenvolgende historische versies van elk gegevenspunt van de veelheid van gegevenspunten in de relationele gegevensbank bij te houden.

Het systeem kan een platform voorzien dat collaboratief gegevensbeheer voor een veelheid van gebruikers mogelijk maakt. De gebruikers kunnen bijvoorbeeld samenwerken in subgroepen of teams. Op voordelige wijze kan een meer efficiënt gegevensbeheer worden bereikt. De communicatie-interface kan ingericht zijn om een interactief collaboratief platform te voorzien, dat gegevensbeheer meer efficiënt en transparant maakt.

Volgens de uitvinding houdt de versiecontrole-inrichting historische versies bij van individuele gegevenspunten in de relationele gegevensbank, in plaats van versies van volledige gegevensverzamelingen (bijv. bestanden zoals tekstbestanden) bij te houden. Het is dus niet nodig een volledige verzameling van bestanden op te halen, zelfs al zou alleen een deelverzameling van gegevens vereist zijn. Wanneer een groot aantal wijzigingen gemaakt is aan de verzamelplaats, moeten frequente ophalingen gedaan worden om up-to-date te blijven met de mastertak, zelfs al zijn de meeste van deze wijzigingen niet relevant voor de gebruiker. Dit beïnvloedt de algemene prestatie van het systeem. Dit technische probleem is overwonnen door versiecontrole toe te passen op het niveau van gegevenspunten in de relationele gegevensbank. In een traditioneel versiecontrolesysteem wordt dit probleem opgelost door de verzamelplaats of het csv bestand op te splitsen in verschillende verzamelplaatsen en csv bestanden, respectievelijk. Dit is echter niet wenselijk bij relationele gegevensbanken.

Optioneel is elk gegevenspunt een enkele rij van een tabel in de relationele gegevensbank.

De versiegecontroleerde gegevens kunnen rijen in een gegevensbank zijn. De gegevens kunnen opgehaald worden van een gecentraliseerde gegevensbank door die gecentraliseerde gegevensbank te raadplegen. De gevraagde gegevens (vgl. resulterende van ophaalactie) hoeven niet de volledige gegevensverzameling te omvatten, in plaats daarvan kan enkel een deel van de gegevens die nodig zijn opgehaald worden van de gecentraliseerde gegevensbank. De gegevens hoeven niet lokaal te worden bewaard. In plaats daarvan kunnen de gegevens in een bepaalde weergave in een applicatie worden weergegeven, bijvoorbeeld een webapplicatie (vgl. cloud-applicatie), waarvoor enkel een kleine deelverzameling van de gegevens, die opnieuw opgehaald wordt nadat de weergave is geüpdatet of ververst, vereist is. Dit voorziet een zeer efficiënte versiecontrole.

Op voordelige wijze hoeft de data met betrekking tot versiecontrole niet bewaard te worden op de inrichting van de gebruiker, wat een groot veiligheidsrisico zou zijn wanneer het gevoelige gegevens bevat. Daarnaast is geen installatie van additionele software vereist, aangezien de gegevens niet bewaard worden aan de gebruikerskant.

Optioneel is de versiecontrole-inrichting een gecentraliseerde versiecontrole-inrichting. De gecentraliseerde versiecontrole-inrichting kan op efficiënte wijze wijzigingen bijhouden in de gegevens bewaard in de relationele gegevensbank.

Het gecentraliseerde versiecontrolesysteem kan significante voordelen voorzien. Gedecentraliseerde (gedistribueerde) versiecontrolesystemen vereisen een (gedecentraliseerde) lokale verzamelplaats waar wijzigingen verzameld worden vooraleer naar een centrale server gestuurd te worden. Volgens de uitvinding zijn de gebruikers niet vereist om een applicatie op hun lokale inrichting te downloaden en installeren om wijzigingen aan de gegevens aan te brengen vooraleer ze naar de server te sturen. Dus kan volgens de uitvinding een gecentraliseerde webapplicatie (bijv. cloud-gebaseerd) worden voorzien voor gebruikers om wijzigingen aan de gegevens aan te brengen, waarbij alle gemaakte wijzigingen direct naar de centrale server worden gestuurd.

Er zijn belangrijke nadelen geassocieerd met het gebruik van (gedecentraliseerde) lokale verzamelplaatsen voor gegevensbeheer. Bijvoorbeeld, gedecentraliseerde/gedistribueerde versiecontrole vereist dat alle gegevens bewaard worden in de lokale verzamelplaats, wat niet ideaal is voor zeer gevoelige fiscale bedrijfsgegevens. Daarentegen laat gecentraliseerde versiecontrole toe om op meer transparante wijze te beheren en op correcte wijze te controleren wie toegang krijgt tot welke gegevens. Daarnaast zijn applicaties typisch besturingssysteemafhankelijk en beduidend duurder om te ontwikkelen en onderhouden (updaten), wat ze meer gevoelig maakt voor bugs en fouten. Voorts hebben gebruikers vaak strikte voorschriften over welke applicaties ze toegelaten zijn te downloaden op hun bedrijfsinrichtingen, terwijl een webapplicatie of cloud- applicatie alleen een webbrowser vereist en geen administratierechten vereist om de applicatie te installeren.

De verschillende gebruikers of teams van gebruikers kunnen gemakkelijk toegang krijgen tot de meest recente gegevens met betrekking tot gegevensbeheer, ze bewerken en/of beoordelen, en gelijktijdig de historie van wijzigingen bijhouden. De versiecontrole-inrichting kan ingericht zijn om details te 5 voorzien over welke gegevens in de relationele gegevensbank gewijzigd zijn, wanneer de gegevens in de relationele gegevensbank gewijzigd zijn, door wie de gegevens in de relationele gegevensbank gewijzigd zijn en optioneel waarom de gegevens in de relationele gegevensbank gewijzigd zijn (vgl. opmerkingen). Dit kan significante voordelen bieden voor diverse applicaties, zoals bijvoorbeeld fiscaal projectbeheer, beheer van juridische organisatieschema’s (JOS), etc. aangezien het volledige zichtbaarheid van voorafgaande versies en aangebrachte wijzigingen verzekert en gebruikers of team van gebruikers toelaat om volledig te begrijpen waarom, hoe en wanneer bepaalde beslissingen gemaakt werden, i.e. de historische redenering achter het wijzigen van gegevens.

Het system kan beter gegevensnauwkeurigheid garanderen. Elke wijziging aangebracht aan de gegevens in de relationele gegevensbank is beoordeeld en goedgekeurd door de gebruiker(s) of team(s) van gebruikers verantwoordelijk voor het project. Deze beoordeling verzekert gegevenskwaliteit.

De communicatie-interface kan ingericht zijn om projectbeheer en samenwerkingsfuncties te voorzien die het mogelijk maken dat gebruikers of teamleden communiceren, opmerkingen geven, en bijdragen tot specifieke taken met toegang tot informatie in real-time.

Gekende versiegecontroleerde gegevenssystemen passen versiecontrole toe op ‘platte bestanden’, i.e. type gegevensbank die gegevens in een gewoon tekstformaat bewaart (bijv. broncode (vgl. Git)). In tegenstelling tot zulke systemen, implementeert het systeem volgens de uitvinding het concept van versiecontrole op relationele gegevensbanken. Het is niet mogelijk de technische backbone van Git versiecontrole toe te passen op gegevens in het algemeen, bijvoorbeeld op fiscaal-gerelateerde gegevens in een gegevensbank, aangezien Git focust op codebeheer. Code verschilt op significante manieren van gegevens. Een codebank is in feite een hiërarchie van bestanden en mappen die bestaan op een bestandssysteem. Wijzigingen worden gemodelleerd als de toevoeging of aftrekking van lijnen van tekst aan deze bestanden. Gegevensbanken, tabellen en rijen bieden niet dezelfde navigatie en adressering als bestandssystemen. De complexiteit kan niet gereduceerd worden tot dezelfde algemene eenheid als bestanden: een lijn van tekst. Gegeven dat een gegevensbank vele malen groter kan zijn dan zelfs de grootste codebank, zijn de fijnheid en granulariteit van verschillen een belangrijke prestatiebeperking op de applicatie van versiecontrole op gegevens.

Gekende systemen zoals SQL Source Control kunnen alleen werken op gegevensbank schemawijzigingen, niet op de eigenlijke gegevens bewaard in de tabellen. Daarnaast kunnen gekende systemen zoals Perforce Helix meerdere versiegecontroleerde projecten samenvoegen om een enkele bron van waarheid te creëren. Het voorziet geen versiecontrole voor een project op zichzelf. Voorts gebruikt het Git om de versies van het project, dat gedecentraliseerd/gedistribueerd is, te controleren en focust het op ontwikkeling (bijv. code, wireframes etc.), niet op gegevens in een relationele gegevensbank.

Optioneel is de versiecontrole-inrichting ingericht om de historische versies van elk gegevenspunt van de veelheid van gegevenspunten in bovengenoemde relationele gegevensbank te bewaren, waarbij metagegevens geassocieerd zijn met elke historische versie, de metagegevens omvattende minstens een gebruikersidentificatie, een tijdsvermelding, en een moederversie waaruit de historische versie was gecreëerd.

Optioneel zijn de historische versies van elk gegevenspunt van de veelheid van gegevenspunten bewaard in de relationele gegevensbank raadpleegbaar.

Op voordelige wijze kunnen de gegevenspunten raadpleegbaar blijven, zelfs in de context van de historie van de gegevenspunten bewaard in de relationele gegevensbank. Als een gebruiker bepaalde gegevenspunten in de gegevensbank wijzigt, dan kunnen de verschillende versies van de gegevenspunten (evolutie ervan) gemakkelijk opgespoord worden. De gebruikers kunnen de gecentraliseerde gegevensbank gemakkelijk raadplegen.

Optioneel is de versiecontrole-inrichting ingericht om parallelle workflows te ondersteunen met een veelheid van versietakken.

Een aftakkingsoperatie kan een gebruikersaftakking van een versietak omvatten, die de gebruiker toelaat wijzigingen aan te brengen zonder de originele tak aan te passen.

Eens een tak gecreëerd is, kunnen de gegevens aangepast worden. De commit operatie, bijv. geactiveerd door een commit bevel via de communicatie- interface, wordt gebruikt om wijzigingen aangebracht door de gebruiker aan de mastergegevens op te slaan en toe te passen.

Opdat de gegevens in de relationele gegevensbank van voldoende kwaliteit zouden zijn (i.e. om gelijktijdige documentatie mogelijk te maken), kunnen elk van de volgende commit metagegevens vastgelegd worden voor elke commit: auteur die de wijziging aanbracht, bericht dat de reden van de wijziging uitlegt, tijdsvermelding die aangeeft wanneer de wijziging plaatsvond en/of voorgaande versie(s) waarop de nieuwe versie zal volgen, die ‘commit referentie’ kan genoemd worden. Het zal gewaardeerd worden dat andere metagegevens ook toegevoegd kunnen worden.

Optioneel is de communicatie-interface ingericht om geïsoleerde testomgevingen te voorzien die dienen voor het aanbrengen van wijzigingen aan ten minste één gegevenspunt, waarbij elke geïsoleerde testomgeving geassocieerd is met een versietak.

Op voordelige wijze voorziet de uitvinding een collaboratieve omgeving waarin alle gegevenspunten van een bestaande structuur aanwezig kunnen zijn, en waar het gebruikers is toegelaten om aanpassingen te maken aan de bestaande structuur in een testomgeving. De versiecontrole-inrichting maakt het mogelijk om verschillende scenario’s van aanpassingen aan het gegevenspunt van de bestaande structuur in parallel op te bouwen, i.e. door de creatie van versieaftakkingen toe te laten. Wanneer over een bepaalde tak (i.e. bepaald scenario in de testomgeving) is overeenstemming is bereikt, kan die tak gecombineerd/samengevoegd worden met de mastertak. De master (i.e. enkele bron van waarheid) wordt geüpdatet met de wijzigingen aangebracht in het gekozen scenario. Op deze wijze is het de meerdere gebruikers toegelaten samen te werken aan complexe wijzigingen van de gegevenspunten in de structuur.

Optioneel is de versiecontrole-inrichting ingericht om gelijktijdige commits toe te laten op dezelfde tak. Wanneer een veelheid van gebruikers samenwerkt aan projecten in real-time, kunnen ze samen/gelijktijdig aan dezelfde tak werken. Het kan dus gebeuren dat persoon A een wijziging maakt op hetzelfde moment als persoon B aan dezelfde tak. In een gedecentralizeerd versiecontrolesysteem eindigt dit in een conflict.

Gelijktijdige wijzigingen kunnen in een van twee mogelijke uitkomsten eindigen. In een eerste potentiële uitkomst heeft gebruiker A (Va) iets sneller dan persoon B (Vb) een wijziging aan de huidige actieve versie (V1) aangebracht. Het systeem zal dit als een lineaire wijziging (i.e. V1 > Va > Vb) oppakken wat resulteert in dat zowel gebruiker A als B de versie van gebruiker B als de huidige actieve versie zullen hebben. In een tweede potentiële uitkomst heeft de gebruiker A een wijziging (Va) aangebracht op exact hetzelfde moment als persoon B (Vb) aan de huidige actieve versie (V1). De versiecontrole-inrichting van het collaboratief systeem is ingericht om dit te registreren als een vertakte wijziging (i.e. V1 > Va + V1 > Vb) met ofwel Va of Vb als de huidige actieve versie. Beide zulke uitkomsten zijn echter ongewenst. De versiecontrole-inrichting is ingericht om gelijktijdige wijzigingen te detecteren en een foutmelding te tonen aan de gebruiker die de laatste commit heeft geprobeerd. In sommige voorbeelden wordt dit uitgevoerd door vergrendelingstechnieken die het versiecontrolesysteem verhinderen om de latere versie in de gegevensbank door te zetten, bijv. pessimistisch en optimistisch vergrendelen. Voorts kan de communicatie-interface een gebruikersinterface implementeren om vergrendelingsfouten te behandelen. Zulke vergrendelingstechniek laat toe om conflicten effectief door de gecentraliseerde versiecontrole-inrichting te vermijden.

Historie binnen een tak kan bijgehouden worden door de versiecontrole- inrichting. Een zogenoemde ‘punt in de tijdshistorie’ implementatie kan worden ingezet om historie binnen een enkele tak op te sporen. De versiecontrole- _ inrichting kan ingericht zijn om recursief de pointer commit van een tak op te halen en recursief de gerelateerde referentie commit op te halen, totdat het einde van de historie of een bepaalde tijdsvermelding is bereikt. In sommige voorbeelden kunnen raadpleegtijden verbeterd worden door kolommen te indexeren.

Indien er een conflict is bij het samenvoegen van twee takken, dient het probleem onmiddellijk te worden opgelost. Het kan onhaalbaar zijn een tak te blokkeren voor elke gebruiker tot het probleem is opgelost. Daarom kan de versiecontrole-inrichting ingericht zijn om het conflict onmiddellijk aan te geven aan de gebruiker en de gebruiker de mogelijkheid te bieden een aanpassing te maken of de samenvoeging te annuleren.

Optioneel is de versiecontrole-inrichting ingericht om verschillen tussen versietakken te detecteren.

Optioneel is de versiecontrole-inrichting ingericht om verschillen tussen takken te detecteren gebaseerd op hashing. De hash van elke versie kan bewaard worden.

Optioneel is de versiecontrole-inrichting ingericht om een gegevensmodel te creëren om versies van commits naar het eigen model te verplaatsen. Op deze manier kan een efficiëntere opslag van de versies verkregen worden, en dus kan de vereiste opslagcapaciteit nodig voor de versiecontrole- inrichting gereduceerd worden.

Optioneel is de versiecontrole-inrichting ingericht om wijzigingen aan gegevenspunten in een of meer takken van hoger niveau te detecteren, en automatisch de wijzigingen aan de gegevenspunten in de een of meer takken van hoger niveau aan gegevenspunten in een of meer takken van lager niveau aan te brengen.

Een tak kan wijzigingen van de mastertak ophalen. Op voordelige wijze kunnen op deze manier potentiële conflicten vermeden worden wanneer de tak samengevoegd wordt met de mastertak in de toekomst. Inconsistentie van gegevens wordt effectief voorkomen door toe te laten dat gegevens in twee richtingen bewegen tussen de takken. Dit is met name erg interessant aangezien voor sommige applicaties de projecten een lange tijd kunnen duren (bijv. een tak kan open zijn vooraleer samengevoegd te worden voor langer dan 1 jaar).

Optioneel is de versiecontrole-inrichting ingericht om samenvoeging van versietakken toe te laten.

De versiecontrole-inrichting voorziet de gebruikers van de mogelijkheid om verschillende versies van gegevenspunten in de relationele gegevensbank af te takken en samen te voegen. Een samenvoegingsoperatie kan omvatten dat een gebruiker een versietak met een andere versietak samenvoegt, zodat alle wijzigingen nu ook op de laatstgenoemde tak aanwezig zijn.

De versiecontrole-inrichting kan ingericht zijn om alle uitgevoerde acties vast te leggen, en dan indien gewenst het gevolg van de acties samen te voegen met de gecentraliseerde relationele gegevensbank. Alle versies/takken kunnen onderhouden worden in dezelfde relationele gegevensbank. Op voordelige wijze voorziet dit de gebruikers van de mogelijkheid om niet alleen de huidige toestand te raadplegen, maar ook te bepalen hoe de huidige toestand is bekomen als een resultaat van wijzigingen aan gegevenspunten. De versiecontrole-inrichting voorziet inzichten met betrekking tot wijzigingen aan gegevenspunten en wat heeft geresulteerd in die wijzigingen, bijv. de bepaalde tak geassocieerd met een project met een specifieke naam. Additionele meta-informatie geassocieerd met wijzigingen aan gegevenspunten kan vastgelegd worden door de versiecontrole- inrichting.

De versiecontrole-inrichting kan ingericht zijn om een historieboom te creëren voor elk gegevenspunt, waarbij de historieboom een pad kan hebben dat genomen is om tot een bepaalde versie van het gegevenspunt te komen. De knooppunten van de historieboom en de referenties om de boom op te bouwen kunnen bewaard worden in de relationele gegevensbank. Labels kunnen geassocieerd worden met de knooppunten van de historieboom waar de historieboom aftakt. De gemeenschappelijke voorouder kan bepaald worden als twee takken samengevoegd moeten worden. De versiecontrole-inrichting kan bepalen welke gegevens gewijzigd zijn en of een automatische samenvoeging mogelijk is, i.e. of er een conflict is of niet.

Optioneel is de versiecontrole-inrichting ingericht om een geldigheidscheck uit te voeren wanneer een samenvoeging tussen versietakken wordt geïnitieerd, waarbij de versiecontrole-inrichting is ingericht om na te gaan of de transitie naar een samengevoegde tak toelaatbaar is.

De versiecontrole-inrichting kan ingericht zijn om conflictdetectie en - resolutie te voorzien. De versiecontrole-inrichting kan ingericht zijn om potentiële samenvoegingsconflicten te detecteren en acties uit te voeren om te proberen ze (automatisch) op te lossen. Als het gedetecteerde conflict niet automatisch oplosbaar is, is het mogelijk om manuele acties van de gebruiker te vragen via de communicatie-interface. Een terugdraaiende operatie kan omvatten dat een gebruiker een commit gemaakt in het verleden terugdraait. De voorafgaande wijzigingen kunnen dus ongedaan gemaakt worden.

Optioneel is de versiecontrole-inrichting ingericht om gebruikers toe te laten commits terug te draaien. Dit maakt het voor de gebruikers mogelijk om efficiënt naar voorafgaande toestanden of versies van de gegevenspunt(en) terug te keren. In sommige voorbeelden is de versiecontrole-inrichting ingericht om alleen nieuwe commits toe te voegen en nooit historische commits te verwijderen of aan te passen, zelfs in het geval van terugdraaiing. In andere woorden, de commits zijn onveranderlijk. In sommige voorbeelden bewaart de versiecontrole-inrichting geen wijzigingen, maar volledige versies.

In sommige voordelige voorbeelden is de versiecontrole-inrichting ingericht om terug te draaien naar een bepaald punt in de tijd. Deze oplossing creëert een nieuwe commit die refereert naar die specifieke versie in de tijd. Deze eenvoudigere manier van terugdraaien betekent echter dat het niet langer mogelijk is om een wijziging gemaakt door een specifieke commit terug te draaien en tegelijk de wijzigingen van latere commits bij te houden.

Optioneel is de versiecontrole-inrichting ingericht om, voor elk gegevenspunt, een historieboom te associëren omvattende historie-informatie met betrekking op een wijzigingspad dat is uitgevoerd om tot een laatste versie van het respectieve gegevenspunt te komen.

In sommige voordelige voorbeelden zijn wijzigingen bewaard naast volledige versies. Op voordelige wijze kan op deze manier meer flexibiliteit worden voorzien aan de gebruikers. Dit kan opslag van additionele gegevens vereisen, wat een nadelig effect op de prestatie van het systeem kan hebben. De versiecontrole- inrichting kan ingericht zijn om versies van wijzigingen te hercreëren. Hiertoe kunnen alle wijzigingsgebeurtenissen sequentieel uitgevoerd worden, om de gewenste versie te bekomen.

Optioneel is de versiecontrole-inrichting ingericht om, wanneer een eerste versietak wordt samengevoegd tot een tweede versietak, een gemeenschappelijke voorouder van de eerste en de tweede versietakken te identificeren, waarbij de gemeenschappelijke voorouder een laatst gemeenschappelijke versie is van de eerste versietak en de tweede versietak, waarbij de versiecontrole-inrichting is ingericht om op basis van de gemeenschappelijke voorouder te bepalen welke kolommen van het gegevenspunt gewijzigd zijn en of er samenvoegingsconflicten bestaan.

Optioneel omvat het identificeren van de gemeenschappelijke voorouder van een gegevenspunt in de eerste en tweede versietakken het recursief doorheen de versiehistorie van dat respectieve gegevenspunt gaan, beginnende van zowel de versie in de eerste als tweede tak totdat een gemeenschappelijk gedeelde versie is aangetroffen.

In het algemeen kan de gemeenschappelijke voorouder bepaald worden door recursief door de volledige historieboom te gaan, tot een punt is bereikt gemeenschappelijk aangetroffen bij de twee samen te voegen takken. Twee takken kunnen een veelheid van gemeenschappelijke voorouders hebben. De eerste gemeenschappelijke voorouder kan geselecteerd worden voor evaluatie.

Optioneel is de versiecontrole-inrichting ingericht om gemeenschappelijke voorouders op te sporen over alle versietakken.

Op deze manier kan de responsiviteit van het systeem worden verbeterd.

Optioneel is de veelheid van gegevenspunten herconfigureerbaar tot een geselecteerde voorafgaande historische versie door middel van de versiecontrole- inrichting, waarbij de versiecontrole-inrichting is ingericht om een terugdraaifunctie te voorzien, waarbij als reactie op een terugdraaiing, de versiecontrole-inrichting is ingericht om een terugdraaiovergang uit te voeren door ten minste één gegevenspunt van de veelheid van gegevenspunten te herstellen naar een voorafgaande versie van de historische versies van dat genoemde ten minste één gegevenspunt.

Zulke terugdraaifunctie kan door de gebruiker geactiveerd worden door middel van de communicatie-interface.

De versiecontrole-inrichting kan ingericht zijn om gebruikers toe te laten in staat te zijn de volledige commit historie van een record op een bepaalde tak op te vragen. In sommige voorbeelden is de volledige historie beperkt tot een voorgeselecteerde tijdsperiode, bijvoorbeeld tot 2 jaar, tot 5 jaar, tot 10 jaar, etc. De gebruiker kan in staat zijn om de volledige commit historieboom op te vragen, inclusief alle commits van elke tak voor een record, bijvoorbeeld tot een voorgeselecteerde tijdsperiode.

In sommige voorbeelden is de versiecontrole-inrichting ingericht om elke registratie in de relationele gegevensbank haar eigen versiecontrolerepresentatie te geven om clustering van deelverzamelingen van records die samen als een geheel gebruikt worden toe te laten. Deze clusteringsmethode kan het opslag-toegang trade-off probleem oplossen. De representatie van deze cluster kan gedefinieerd worden op de tak zelf. In sommige gevallen kunnen de niet-bijgehouden records van andere takken (vgl. nieuwe records) niet omvat zijn in deze representatie en kunnen daarom niet omvat zijn in wijzigingsdetectie en samenvoeging. In sommige voorbeelden is dit ‘niet- bijgehouden records’ probleem opgelost door ten minste één van: partieel aftakken per modeltype, partiële takken van gefilterde entiteiten, of door gebruikers manueel records te laten toevoegen tot de takclusterrepresentatie nadat de tak is gecreëerd.

In sommige voordelige voorbeelden is de versiecontrole-inrichting ingericht om de referentie commit informatie te splitsen van het huidige commit model, om een eigen model en een relatie tot zijn oudercommit te creëren. Op voordelige wijze is dit een schaalbare oplossing.

In sommige voordelige voorbeelden, kan de huidige referentie commit bewaard worden in een array formaat op het commit model. Dit heeft het voordeel dat geen apart model gecreëerd hoeft te worden.

Optioneel is de relationele gegevensbank een gecentraliseerde gegevensbank.

De versiecontrole-inrichting kan gecentraliseerd zijn zodat geen lokale kopieën nodig zijn. De acties uitgevoerd door de gebruiker met behulp van een gebruikersinterface van de communicatie-interface kan vastgelegd worden op de gecentraliseerde server. Op deze manier is het sturen van lokale bestanden naar de server niet nodig.

Optioneel is de relationele gegevensbank volledig gecentraliseerd en voorziet deze een enkele bron van waarheid (EBvW) die ingericht is om een consistente up-to-date weergave te voorzien op gegevens die beheerd worden. Een gecentraliseerde gegevensversiecontrole is voorzien op de relationele gegevensbank en verbetert de gegevensbeheerprojecten van verschillende teams ten minste deels gebruik makende van dezelfde gegevens in de relationele gegevensbank.

De gebruikers kunnen op eender welk moment een accurate weergave van de EBvW hebben. Een EBvW is de aanpak om alle gegevens in een enkele plaats te structureren en te bewaren, dit verzekert dat gegevenslocaties gelinkt zijn met de masterbron en dat elke propagatie van de masterbron niet gedupliceerd wordt elders in het systeem. Dankzij de EBvW kan het systeem altijd klaar zijn om audits mogelijk te maken, wat de transparantie van de gegevens verbetert.

In een relationele gegevensbankmodel, blijven gegevensstructuren (omvattende gegevenstabellen, indexen en weergaves) gescheiden van de fysieke opslag, wat beheerders toelaat de fysieke dataopslag te bewerken zonder de logische gegevensstructuur te beïnvloeden.

Versiecontrole kan vereisen om verschillende versies van gegevens te bewaren. Dit kan direct interfereren met unieke beperkingen (bijv. relationele integriteitsbeperkingen), i.e. een belangrijk principe van relationele gegevensbanken om gegevensintegriteit te onderhouden. Bijgevolg kunnen versies mogelijk niet in dezelfde gegevenstabel bewaard worden. Dit kan overkomen worden door de volledige versie op voordelige wijze op een pointer te bewaren (in plaats van enkel een referentie naar de versie).

Optioneel is de versiecontrole-inrichting ingericht om de partijen te isoleren door een aparte gegevensbank te gebruiken voor elke partij.

Optioneel is de versiecontrole-inrichting ingericht om alle gegevens van alle partijen bij te houden in een enkele gegevensbank en discriminatorsleutels toe te voegen aan alle tabellen zodat de versiecontrole-inrichting het kan filteren naar enkel eigen gegevens.

Optioneel is de versiecontrole-inrichting ingericht om het voor gebruikers mogelijk te maken een tak te verwijderen zonder de historie te beïnvloeden. Een onderscheid kan gemaakt worden tussen onveranderlijke en hulpbronnen die kunnen worden verwijderd. Op voordelige wijze reduceert dit het vereiste opslagvolume. Bijvoorbeeld, wanneer een gebruiker een tak creëert en aanpast, moet de gebruiker beslissen om ofwel de tak samen te voegen of niet. Het laatste geval kan zich voordoen aangezien sommige brainstorm sessies (vgl. testtakken) zuiver verkennend kunnen zijn en mogelijk niet in een wijziging aan de data resulteren. Door het voor gebruikers mogelijk te maken een tak te verwijderen zonder de historie te beïnvloeden, kan het voorkomen worden dat niet-operationele takken zich over de tijd ophopen.

De communicatie-interface of het communicatieplatform kan ingericht zijn om een interactieve omgeving te voorzien die is ingericht om samenwerking op afstand te faciliteren op gegevens door verschillende teams of partijen van gebruikers (bijv. managers, consultants, auditors, gegevensingenieurs, etc.). Op voordelige wijze is het systeem ingericht om versiecontrole te voorzien die het effectief mogelijk maakt om een consistent up-to-date en gedetailleerde weergave te hebben op de gegevens bewaard in de relationele gegevensbank, en om op efficiënte wijze een volledig record bij te houden van wijzigingen die aangebracht zijn aan de gegevens (wat gewijzigd is, wanneer, door wie en waarom).

Het collaboratief systeem kan cloud-gebaseerd zijn. Optioneel voorziet het collaboratief systeem een software as a service platform.

Optioneel is het systeem ingericht om bedrijfsinhoudsbeheer te voorzien.

Volgens een aspect, voorziet de uitvinding een werkwijze voor het voorzien van een collaboratief gegevensbeheerplatform voor meerdere gebruikers, de werkwijze omvattende: het voorzien van een relationele gegevensbank met een veelheid van gegevenspunten; het voorzien van een communicatie-interface om gebruikers toe te laten de relationele gegevensbank te raadplegen; en het voorzien van een versiecontrole-inrichting om opeenvolgende historische versies van elk gegevenspunt van de veelheid van gegevenspunten in de gecentraliseerde relationele gegevensbank bij te houden.

De werkwijze kan een interactief, collaboratief, cloud-gebaseerd softwareplatform voorzien dat het gegevensbeheer in een relationele gegevensbank faciliteert. Het verbeterde collaboratief platform maakt het mogelijk voor gebruikers om beduidend tijd te besparen in projectbeheer.

Volgens een aspect voorziet de uitvinding een computerprogramma, ingericht om de stappen van de werkwijze zoals hierbij beschreven uit te voeren wanneer uitgevoerd op een rekenstation.

Volgens een aspect voorziet de uitvinding een inrichting omvattende een rekenstation met een processor, gekoppeld aan een geheugen, bedienbaar om het rekenstation de werkwijze zoals hierbij beschreven te doen uitvoeren.

De communicatie-interface maakt het mogelijk om gegevens in het platform in te geven, aan te passen of te verwijderen, terwijl de versiecontrole- inrichting is ingericht om alle wijzigingen en de verschillende versies van de gegevens bij te houden.

Via de communicatie-interface kunnen de gebruikers de verschillende bijgehouden versies van de gegevens in de relationele gegevensbank raadplegen.

Optioneel laat de communicatie-interface visualisatie toe van de historische versies van gegevenspunten van de relationele gegevensbank.

Dit laat de gebruiker toe om terug te gaan naar voorafgaande versies van de gegevens.

Voorts kan de communicatie-interface ingericht zijn om gebruikers toe te laten metagegevens toe te voegen, bijvoorbeeld waarin het gemotiveerd of gerechtvaardigd kan worden waarom een wijziging aan een gegevenspunt of gegevensverzameling aangebracht is.

Op voordelige wijze kan als gevolg een gelijktijdige documentatie worden voorzien.

In sommige voorbeelden is de versiecontrole-inrichting ingericht om de historie op te halen en te voorzien in een tijdslijn representatie, bijvoorbeeld door middel van de communicatie-interface.

De historie kan voorgesteld worden door een boom van commits.

Commits kunnen takonafhankelijk zijn.

Het wordt ook ingebeeld dat commits gedeeld kunnen worden door takken.

Volgens een aspect voorziet de uitvinding een gebruik van het collaboratief gegevensbeheersysteem voor meerdere gebruikers.

Het gebruik van het systeem kan resulteren in significante kostenbesparingen.

Daarnaast kan de consistentie in de gegevens veel verbeterd worden.

Als gevolg kan het vertrouwen in rapportage ook verhogen.

Samenwerking met meerdere gebruikers kan betreffen samen te werken aan projecten met een doel en houdt de uitvoering in van een bepaald aantal acties op gegevens binnen een gegeven tijdspanne, bijvoorbeeld variërend van weken tot maanden.

Deze manier van werken wordt ondersteund door aftakken.

Het is de gebruikers toegelaten om verder nieuwe wijzigingen aan de tak te committen, terwijl andere collega’s de master kunnen aanpassen zonder dat de wijzigingen elkaar beïnvloeden.

Dagen of weken kunnen voorbijgaan terwijl het aan de gebruikers toegestaan is wijzigingen te maken, hun werk te beoordelen en te verfijnen.

Alle gegevens kunnen bewaard zijn op de gecentraliseerde relationele gegevensbank.

In plaats van elke wijziging individueel te registreren, kan de versiecontrole-inrichting ingericht zijn om alleen de wijzigingen te koppelen wanneer de gebruiker ze effectief ‘inzendft’. Deze inzending van een collectie van acties uitgevoerd op de gegevens is gekend als een commit. De commits kunnen voor onbepaalde tijd in de opslagplaats bijgehouden worden. Dus, wanneer andere gebruikers een update uitvoeren aan de opslagplaats, kan de laatst gecomitte versie ontvangen worden.

Het systeem en de werkwijze kunnen ingezet worden voor diverse applicaties waarin gegevensbeheer noodzakelijk is. Bijvoorbeeld, collaboratief, fiscaal beheer, collaboratieve gegevensadministratie, etc. Bijvoorbeeld, wanneer het systeem collaboratief fiscaal beheer voorziet, naast bedrijfsgegevens, kan het platform uitgerust zijn met de nieuwste internationale fiscale voorschriften.

Een voorbeeld waarvoor het systeem gebruikt kan worden is het beheer van juridische organisatieschema’s (JOS). Deze schema's tonen de eigendomsrelaties tussen juridische entiteiten in de bedrijfsfamilie, en bevatten kwantitatieve informatie (bijv. percentage van aandelenbezit van een dochteronderneming), kwalitatieve informatie (i.e. een vereiste rechtsvorm), of combinaties van beide (i.e. deducties gelinkt aan de hoeveelheid maatschappelijk aandelenkapitaal in geval van een liquidatie). Deze kunnen de basis zijn voor de meeste fiscaal-gerelateerde beslissingen binnen organisaties met meerdere entiteiten. Wegens een gebrek aan computer geïmplementeerde systemen worden JOGs typisch manueel gecreëerd in PowerPoint. De communicatie-interface of het platform volgens de uitvinding kan ingericht zijn om samenwerking op afstand te faciliteren, aldus wordt de transparantie over en nauwkeurigheid van alle fiscale bedrijfsgegevens verbeterd.

De gecentraliseerde relationele gegevensbank maakt verbeterd updaten van regels mogelijk, aangezien de regels automatisch geïmplementeerd kunnen worden en beschikbaar gemaakt worden voor de gebruikers van het collaboratief systeem. De gebruikers kunnen bijvoorbeeld bepaalde gebruikers (bijv. externe partij) uitnodigen om samen te werken aan projecten om, bijvoorbeeld, een externe partij gespecialiseerd in bepaalde regels voor een bepaalde zaak te vragen om relevante gegevens met betrekking op het project te beoordelen, en de huidige regels aan te passen wanneer nodig.

Bijvoorbeeld, de systeemgebruikers kunnen verkennende analyses uitvoeren gebaseerd op de EBvW en de door bijvoorbeeld een andere partij (bijv. externe partij) ingegeven regels en voorschriften. Voor het voorbeeld van fiscaal beheer, hebben deze verkennende analyses als doel om snel de impact van verschillende fiscaal strategische beslissingen te schatten, gebaseerd op een verzameling van ‘parameters’, bijv. welke financiële en regulerende gevolgen gelinkt zijn met het verwerven van entiteit X wanneer rekening gehouden wordt met de volgende parameters: verschillende landen (nationale fiscale regelgeving toepassen), financiering door verschillende soorten leningen, etc.

Het zal worden gewaardeerd dat versiehistorie geïnterpreteerd kan worden als elke wijziging die incrementeel vastgelegd is en dat gebruikers in staat zijn om terug te reizen doorheen de gegevens en, bijvoorbeeld, een voorafgaande versie van hun gegevens kunnen terugdraaien.

Het zal worden gewaardeerd dat aftakken geïnterpreteerd kan worden door een operatie waarin gebruikers een kopie van de huidige master gegevensverzameling kunnen creëren en deze gegevens kunnen beginnen wijzigen in een brainstorm’ (test)omgeving zonder andere gebruikers te beïnvloeden.

Het zal worden gewaardeerd dat samenvoeging geïnterpreteerd kan worden door een operatie waarin twee versies van de gegevenspunten gecreëerd worden. Wanneer twee van deze kopieën (of takken) uit elkaar gaan, kunnen de wijzigingen opnieuw samengevoegd worden tot de originele versie door meerdere algoritmes toe te passen om de wijzigingen aan het origineel aan te brengen.

De versiecontrole-inrichting kan ingericht zijn om wijzigingen te registreren in ‘gegevens’ in de relationele gegevensbank doorheen de tijd zodat de historie of historische versies gekoppeld kunnen worden, en zodat specifieke voorafgaande versies later in de tijd teruggeroepen kunnen worden. De versiecontrole-inrichting is specifiek ingericht om versiecontrole in een relationele gegevensbank te voorzien, bij voorkeur een gecentraliseerde relationele gegevensbank. Het gecentraliseerde systeem kan in een client-server relatie werken. De opslagplaats kan zich op één plaats bevinden en kan toegang voorzien voor een veelheid van clients. Alle wijzigingen, gebruikers, commits, aftakkingen, samenvoegingen en informatie worden gestuurd en ontvangen vanuit deze centrale opslagplaats.

Een commit operatie kan omvatten dat een gebruiker gegevens toevoegt, creëert, updatet, verwijdert door wijzigingen te committen. Een commit kan informatie met betrekking tot de gebruiker van de commit (vgl. auteur) omvatten, een commit bericht dat de reden aangeeft waarom de commit gemaakt is, een tijdsvermelding wanneer de commit is gemaakt, een referentie naar de vorige commit, en een indicatie of deze commit een samenvoegingscommit is of niet. De commits zelf kunnen nooit veranderd en/of verwijderd worden door eender welke gebruiker om de integriteit van de versiecontrole te garanderen.

Hoewel de belichamingen van de uitvinding computerapparatuur en processen uitgevoerd op computerapparatuur kunnen omvatten, omvat de uitvinding ook computerprogramma’s, met name computerprogramma’s op of in een drager, aangepast om de uitvinding in de praktijk te brengen. Het programma kan de vorm van bron- of objectcode aannemen of eender welke andere vorm geschikt voor gebruik in de implementatie van de processen volgens de uitvinding.

De drager kan eender welke entiteit of inrichting zijn die in staat is om het programma te dragen.

Optioneel betekent dat de opeenvolgend beschreven gebeurtenis of omstandigheid zich al dan niet kan voordoen, en dat de beschrijving gevallen omvat waar de genoemde gebeurtenis of omstandigheid zich voordoet en gevallen waar dit niet gebeurt.

Het zal gewaardeerd worden dat eender welk van de aspecten, functies en opties beschreven met het oog op het systeem gelijkwaardig van toepassing zijn op de werkwijze en het beschreven collaboratief platform, computerprogrammaproduct, en de inrichting. Het zal ook duidelijk zijn dat een of meer van de bovenstaande aspecten, functies en opties gecombineerd kunnen worden.

KORTE BESCHRIJVING VAN DE TEKENINGEN De uitvinding zal verder toegelicht worden op basis van voorbeeldige belichamingen die zijn voorgesteld in een tekening. De voorbeeldige belichamingen worden gegeven bij wijze van niet-limitatieve illustratie. Er wordt opgemerkt dat de tekeningen alleen schematische representaties zijn van belichamingen van de uitvinding die gegeven zijn bij wijze van niet-limiterend voorbeeld.

In de tekening: Fig. 1 toont een schematisch diagram van een belichaming van een systeem; Fig. 24, 2b toont een schematisch diagram van een voorbeeldige versiecontrole; Fig. 3 toont een schematisch diagram van een voorbeeldige versiecontrole; Fig. 4 toont een schematisch diagram van een voorbeeldig entiteit- relationeel diagram; en Fig. 5 toont een schematisch diagram van een voorbeeldige versiecontrole.

GEDETAILLEERDE BESCHRIJVING Fig. 1 toont een schematisch diagram van een belichaming van een collaboratief systeem 1 voor gegevensbeheer voor meerdere gebruikers. Het systeem 1 omvattende een relationele gegevensbank 3 met een veelheid van gegevenspunten. Voorts is het systeem 1 voorzien van een communicatie-interface 5 ingericht om gebruikers toe te laten de relationele gegevensbank 3 te raadplegen. De communicatie-interface 5 kan bijvoorbeeld een gebruikersinterface (GI) omvatten en/of een applicatie programmeerinterface (API). Het collaboratief systeem 1 omvat verder een versiecontrole-inrichting 7 ingericht om opeenvolgende historische versies bij te houden van elke gegevenspunt van de veelheid van gegevenspunten in de relationele gegevensbank 3.

Het versiegecontroleerde gegevensbeheersysteem verbetert op efficiënte wijze de samenwerking tussen meerdere gebruikers. Op voordelige wijze maakt het systeem 1 het mogelijk om beter duidelijk en volledig de wijzigingen aangebracht aan de gegevens bij te houden. Het is niet langer nodig om manueel gegevens te updaten die bewaard zijn over verschillende bronnen. Dus kunnen fouten en onnauwkeurigheden effectief gereduceerd worden.

Overigens kan het systeem 1 helpen een accurate en consistente, up-to- date weergave op de gegevens te garanderen. Op voordelige wijze maakt het systeem het mogelijk om automatisch essentiële en up-to-date informatie met betrekking op collaboratieve projecten te extraheren.

Enkele bron van waarheid (EBvW) refereert naar het bewaren van alle gegevens, configuratie en andere digitale middelen op een manier waarop iedereen toegang kan krijgen tot de meest up-to-date gegevens op een gemeenschappelijke locatie, overal en altijd.

Optioneel maakt de versiecontrole-inrichting 7 het mogelijk om naar een voorafgaande versie van de gegevens terug te draaien. Het systeem 1 voorziet een versiecontrole die gebruikers toelaat om af te takken, te committen, en samen te voegen toegepast op gegevensverzamelingen in de relationele gegevensbank 5. De aftakkingsfunctie maakt het mogelijk om meerdere gebruikers in parallel te laten werken aan projecten die gelinkt zijn met de mastergegevens (EBvW). Gegevensversiecontrole zal ook de tooling voorzien om voorafgaande versies van de gegevens opnieuw in te stellen, en zal het mogelijk maken om speciale testomgevingen op te zetten.

Het system 1 kan een versiegecontroleerd inhoudsbeheersysteem (IBS) zijn, wat werkefficiëntie en nauwkeurigheid beduidend verbetert. In plaats gebruik te maken van een gedecentraliseerde versiecontrolelaag, is het systeem ingericht om een gecentraliseerde versiecontrolearchitectuur op te richten.

De versiecontrole-inrichting kan ingericht zijn om gecentraliseerde versiecontrole op de relationele gegevensbank te voorzien. In plaats van versiecontrole toe te passen op zogenaamde ‘platte bestanden’, i.e. type van gegevensbank die gegevens in een gewoon tekstformaat bewaart, implementeert de huidige uitvinding het concept van versiecontrole op relationele gegevensbanken. Binnen platte bestanden zijn er geen structuren voor het indexeren of herkennen van relaties tussen records. Een relationele gegevensbank is daarentegen een collectie van informatie die gegevenspunten met gedefinieerde relaties ordent. Eén gegevenspunt veranderen zal veel andere gegevenspunten in de gegevensbank beïnvloeden. Het systeem maakt gebruik van een gecentraliseerde versiebeheerarchitectuur.

De versiecontrole-inrichting 7 kan ingericht zijn om aftakkingsoperaties te voorzien om gebruikers te voorzien van de mogelijkheid af te wijken van een versie en er een duplicaat aan toe te voegen zodat het onafhankelijk van de bronversie gewijzigd kan worden. De gebruikers zijn ook in staat om te committen, wat de toevoeging van een tijdsvermelding en referentie naar de vorige versie in elke commit omvat. Het systeem 1 kan wijzigingen aan grote gegevensvolumes behandelen, en de versiecontrole kan worden ingezet op collaboratieve wijze voor een groot aantal gebruikers. De versiecontrole-inrichting kan ingericht zijn om bijhouden te ondersteunen en historie van wijzigingen aan gegevens in de (gecentraliseerde) relationele gegevensbank te visualiseren, bijvoorbeeld door gebruik van de communicatie-interface. De communicatie-interface kan een applicatie programmeerinterface omvatten. Zulke interface kan ingericht zijn om oproepen of verzoeken die gemaakt kunnen worden te definiëren.

De versiecontrole-inrichting 7 kan ingericht zijn om meerdere takken te behandelen en om accurate en efficiënte samenvoeging van takken mogelijk te maken. Wijzigingen tussen takken kunnen automatisch gedetecteerd worden, en de versiecontrole-inrichting kan ingericht zijn om automatische ophaalverzoeken te behandelen om operationele takken te updaten. Historie van de gegevens over takken kan bijgehouden worden door de versiecontrole-inrichting. In sommige voorbeelden is de versiecontrole-inrichting ingericht om voorweergaves van samenvoegingen mogelijk te maken.

De applicatie programmeerinterface van de communicatie-interface kan ingericht zijn om het voor een (web)applicatie mogelijk te maken te communiceren met de versiecontrole-inrichting (vastleggen, aftakken, etc.).

Op voordelige wijze kan het collaboratief systeem speciale testomgevingen voorzien waarin testen uitgevoerd kunnen worden, bijv. brainstormomgeving om experimenten met de gegevens in de relationele gegevensbank uit te voeren. De versiecontrole-inrichting kan samenwerking en een EBvW mogelijk maken.

Een testomgeving kan collaboratieve brainstormsessies faciliteren. Testomgevingen kunnen beschouwd worden als een speciaal deel van het takmodel, ze kunnen aftakken van de master om schattingen gebaseerd op EBvW mogelijk te maken, maar zijn niet toegelaten samen te voegen met en de masterversie te beïnvloeden.

Fig. 2a toont een schematisch diagram van een voorbeeldige versiecontrole. Een nieuw record v1 kan ingevoegd worden, wat kan geregistreerd worden door de versiecontrole-inrichting als een commit. Het systeem kan het record v1 invoegen in de versietabel en kan een commit creëren omvattende metagegevens over de invoeging, bijvoorbeeld informatie met betrekking tot de auteur (vgl. gebruiker), bericht, en tijdsvermelding. De commit refereert naar de invoeging vl. Committen kan lineaire historie binnen een tak mogelijk maken. De gegevens kunnen door de gebruikers ingevoegd worden via de communicatie- interface.

Fig. 2b toont een schematisch diagram van een voorbeeldige versiecontrole. Het gegevenspunt bewaard in de relationele gegevensbank kan geüpdatet worden door een gebruiker. Als de gebruiker een record v1 wil updaten (dit zal resulteren in record v2), bewaart de versiecontrole-inrichting record v2 en creëert een commit met de relevante metagegevens (bijv. auteur, bericht, tijdsvermelding, voorgaande versie) en referentie naar record v2. Daarnaast refereert deze commit nu ook naar de vorige commit, zodat een lineaire commithistorie wordt opgebouwd. Door updates/invoegingen op deze manier te verwerken, is het mogelijk een lineaire historie bij te houden van hoe het record doorheen de tijd geëvolueerd is met preservatie van zijn context.

Fig. 3 toont een schematisch diagram van een voorbeeldige versiecontrole. Meerdere gebruikers kunnen gegevens wijzigen in de relationele gegevensbank door commit- en aftakkingsacties uit te voeren die kunnen leiden tot niet-lineaire historiebomen.

Meerdere gebruikers zijn toegelaten om te werken aan de gegevens op dezelfde relationele gegevensbank via de communicatie-interface. De gegevens kunnen dus gewijzigd worden door meerdere gebruikers. Bijvoorbeeld, meerdere gebruikers kunnen onafhankelijk willen werken (vgl. gelijktijdig) aan record v1 in het systeem. Wijzigingen gemaakt door een gebruiker zijn enkel van toepassing op die gebruiker, dit zal een eigen historiepad creëren. Dit wordt gerealiseerd door aftakking. Wanneer een gebruiker een tak creëert is het systeem ingericht om een pointer bl, b2 te creëren, die refereert naar de commit waar een bepaalde tak is in de historieboom. In het getoonde voorbeeld toont paneel A een situatie waar twee takken bl en b2 bestaan.

Wanneer een gebruiker op tak bl heeft gewerkt en een wijziging wil committen, wordt een nieuwe versie v3 ingevoegd samen met een commit en een referentie naar de vorige commit, maar nu wordt ook de pointer voor bl verplaatst langs de nieuw gecreëerde commit, zie paneel B. Merk op dat voor gebruikers op tak b2 niets wijzigt aangezien ze nog steeds bij versie v2 zijn.

Wanneer een van de gebruikers een wijziging aan de gegevens aanbrengt, zullen opnieuw twee versie bestaan, zie paneel C figuur. De twee versies zijn afgetakt van de tweede commit, en creëren elk een eigen historie pad. Als gevolg is de commithistorie niet langer lineair maar krijgt een boomstructuur. Op voordelige wijze laat deze functie toe gebruikers onafhankelijk te laten werken aan dezelfde relationele gegevensbank, bijvoorbeeld op dezelfde of op verschillende projecten, zonder nadelig te interfereren met andere projecten.

Wanneer meerdere gebruikers aan dezelfde gegevensverzameling werken kunnen gelijkaardige gegevenspunten bijna gelijktijdig gewijzigd (gecommit) worden en in conflicten resulteren, dat is, het versiecontrolesysteem identificeert een mismatch en kan niet bepalen welke de correcte en toonaangevende wijziging is. In dit geval kan het versiecontrolesysteem ingericht zijn om het verschil tussen de conflicterende versies te visualiseren, en een input van de gebruiker te vragen om een keuze te maken met betrekking tot welk gegevenspunt bijgehouden dient te worden. Om conflicten tijdens samenwerking aan dezelfde gegevensverzameling te minimaliseren, kan de versiecontrole- inrichting ingericht zijn om zo frequent als praktisch mogelijk de laatste updates van de verzamelplaats te krijgen. Dit kan uitgevoerd worden door middel van updates of ophaalverzoeken.

Wanneer het einde van een project nadert en de gebruiker akkoord is met het resultaat, kan de tak samengevoegd worden met de originele gegevens. Door de tak samen te voegen met de master, kan de versiecontroletool proberen om alle wijzigingen aangebracht binnen de tak naadloos te integreren (vgl. toepassen) met de originele mastergegevens. De versiecontrole-inrichting kan samenvoeging vereisen om te worden beoordeeld en goedgekeurd door de gebruiker verantwoordelijk voor het project, bijv. teamleider. De gebruiker kan toegewezen worden om samenvoegingsconflicten geïdentificeerd door de versiecontrole- inrichting van het systeem op te lossen.

Fig. 4 toont voorbeeldige schematische entiteit-relationele diagrammen (ERD). De figuur illustreert een voorbeeldige visuele representatie van de relaties van entiteitsverzamelingen bewaard in de relationele gegevensbank. Met name is de structuur (ontwerp, architectuur) van het gegevensmodel geïllustreerd. Een entiteitsverzameling is een collectie van gelijkaardige entiteiten, elke entiteit (gegevenscomponent) is gekarakteriseerd door attributen. Om versiecontrole te ondersteunen, zal het ERD verschillende tabellen omvatten (versie, pointer, commit, tak, referentie).

Het systeem kan gebruikt worden voor gegevensprojectbeheer voor verschillende applicaties. Bijvoorbeeld, de gegevens kunnen betrekking hebben op een volledige multinational bedrijfsstructuur (gegevenspunten rond bedrijf en gegevenspunten rond relaties tussen bedrijven, bijvoorbeeld omvattende o.a.

adressen van de geassocieerde bedrijven, omzet, directeuren die wijzigen, aandeelhouders die wijzigen, bedrijven die verdwijnen, bedrijven die samengevoegd zijn, andere wijzigingen in bedrijfsstructuur, etc.). Bijvoorbeeld, sommige multinational bedrijven kunnen duizenden geassocieerde bedrijven hebben over de wereld. De gegevens beheren kan samenwerking omvatten tussen een groot aantal gebruikers en teams. Het collaboratief systeem kan worden ingericht om gegevensbeheer bij meerdere gebruikers toe te laten. Bijvoorbeeld, wanneer een bedrijf verworven dient te worden door een ander bedrijf dan moet een integratie gebeuren die kan omvatten dat een groot aantal teams en gebruikers aan dezelfde gegevens werken. De nieuw verworven bedrijven moeten een plaats krijgen in de huidige structuur. Bijvoorbeeld, sommige bedrijven kunnen gesloten worden, bepaalde bedrijven kunnen samengevoegd worden, bepaalde bedrijven kunnen operationeel blijven, etc. Het collaboratief systeem volgens de uitvinding laat efficiënt gegevensbeheer toe. Het zal gewaardeerd worden dat diverse andere applicaties mogelijk zijn.

Fig. 5 toont een schematisch diagram van een voorbeeldige versiecontrole resulterend in niet-lineaire historie over takken.

De versiecontrole-inrichting kan in staat zijn een historie boomstructuur op te bouwen voor elk gegevenspunt in de relationele gegevensbank. Takken in de boomstructuur kunnen verder aftakken in sub-takken. De mastertak kan een eerste versie hebben (entiteit V1). In takontwikkeling, kan het gegevenspunt aangepast worden tot een tweede versie (entiteit V2). In de featuretak kan een andere wijziging zijn doorgevoerd resulterende in een derde versie (entiteit V3). De wijzigingen kunnen samengevoegd worden met de mastertak. In dit voorbeeld is de tweede versie alleen detecteerbaar via de derde versie op de featuretak. De derde versie heeft ouderidentificatie versie 2, wat op takontwikkeling met ouderidentificatie versie 1 is. Elk van de drie takken kan geassocieerd zijn met een rij in de relationele gegevensbank. De entiteit V1 kan een rij in de relationele gegevensbank zijn die een bepaalde versie heeft. In dit voorbeeld, kan de tweede versie gezien worden als een intermediaire versie waaraan verdere bewerkingen zijn gemaakt in de derde versie (i.e. derde versie is afgeleid van de tweede versie). De derde versie in de featuretak kan samengevoegd worden met de master. De versiecontrole-inrichting kan ingericht zijn om te bepalen of er conflicten zijn en wat gewijzigd is wanneer een samenvoegingsoperatie wordt uitgevoerd. Hiertoe kan een gemeenschappelijke voorouder tussen twee takken bepaald worden. In dit vereenvoudigd voorbeeld is de gemeenschappelijke voorouder entiteit V1.

Dit voorbeeld illustreert de complexiteit van het bijhouden van niet- lineaire historie over takken. Drie takken zijn getoond in dit voorbeeld namelijk een mastertak (EBvW), een ontwikkelingstak en een featuretak. In dit voorbeeld is een object in de gegevensbank (i.e. entiteit) gewijzigd. Een gebruiker X doelt erop om versie 3, v3, die op de featuretak is samen te voegen met de mastertak met een samenvoegingscommit. Om dit te doen, identificeert het versiecontrolesysteem de (eerste) gemeenschappelijke voorouder (i.e. v1). Deze versie is echter niet aanwezig op de featuretak, die in plaats daarvan v3 bevat.

De versiecontrole-inrichting kan ingericht zijn om gemeenschappelijke voorouders over takken op te sporen. In de gegeven figuur verwijst model_id naar version _id van de commit waarop de tak zit; de parent_id informeert waar de vorige versie vanuit begonnen is. In sommige voorbeelden kan, in plaats van de volledige versie historieboom te tonen, de versiecontrole-inrichting aangepast zijn om de lineaire historie te tonen vanaf de eerste gemeenschappelijke voorouder met de mastertak tot het bladknooppunt van de tak waarop informatie is bewaard op de pointer.

Merkle bomen kunnen ingezet worden om te identificeren waar een wijziging gemaakt is. Zulke Merkle bomen informeren echter niet wat er veranderd gewijzigd. Hiertoe kan de versiecontrole-inrichting ingericht zijn om de gemeenschappelijke voorouder te bepalen. Op voordelige wijze maakt de gemeenschappelijke voorouderdetectie het mogelijk om de laatste gemeenschappelijke versie van twee afgetakte versies te identificeren. Dit kan vereisen om terug te reizen in de takhistorie van verschillende takken (vgl. versies).

Elk gegevenspunt volgt de eigen historieboom, en het is dus al geweten welke gegevenspunten gewijzigd zijn wanneer twee takken vergeleken worden. Gebruik maken van hashes om wijzigingen te vergelijken kan echter nog steeds waardevol zijn aangezien bijvoorbeeld beide takken onafhankelijk dezelfde wijziging aan een gegevenspunt kunnen hebben aangebracht wat betekent dat dit gegevenspunt genegeerd mag worden als een potentieel conflict.

De versiecontrole-inrichting kan ingericht zijn om conflicten tussen takken te identificeren. Bijvoorbeeld, een conflict kan ontstaan als gevolg van geautomatiseerde ophaalverzoeken, waarbij de operationele tak is geüpdatet met informatie van master, of met wijzigingen aangebracht in parallelle takken.

Optioneel is de versiecontrole-inrichting ingericht om ‘voorweergaves van samenvoegingen’ mogelijk te maken. Op deze manier kunnen potentiële conflicten op voordelige wijze beter geïdentificeerd of voorkomen worden.

Naast het detecteren van wijzigingen en potentiële conflicten, kan de versiecontrole-inrichting ingericht zijn om de geïdentificeerde conflicten te verwerken en op te lossen. Dit kan op verschillende manieren uitgevoerd worden.

Optioneel is de versiecontrole-inrichting ingericht om een apart ‘conflict’ model te ontwikkelen dat het mogelijk maakt voor gebruikers om individuele conflicten op dezelfde gegevensbankrij stap per stap op te lossen. Wanneer de een of meerdere conflicten zijn opgelost kan de samenvoeging plaatsvinden.

Optioneel is de versiecontrole-inrichting ingericht om takken te vergrendelen wanneer een conflict ontstaat. In een gecentraliseerde versiecontrole kan het vergrendelen van een tak alle gebruikers beïnvloeden, wat ongewenst kan zijn. Op voordelige wijze maakt de versiecontrole-inrichting, in sommige voorbeelden, gebruiker-gebaseerde vergrendeling mogelijk in het gecentraliseerd, collaboratief systeem. Dit kan bijvoorbeeld gedaan worden door tijdelijke samenvoegingstakken te creëren.

Een applicatie programmeerinterface (API) kan voorzien worden die de gebruiker toelaat om het orchestratiemodel te ontwerpen, in te richten en aan te passen zonder de grafische gebruikersinterface (GG]) te gebruiken. In sommige voorbeelden, kan eender welke actie die genomen kan worden met de GGI uitgevoerd worden met de API, maar de API laat optioneel additionele gebruiker- gegenereerde logica toe. Voorts kan een API client, in sommige voorbeelden, voorzien zijn om de gebruiker toe te laten te interageren met de API. Als aanvulling of alternatief kan de gebruiker interageren met de API door middel van een programmeertaal, zoals bijvoorbeeld Python. Als aanvulling of alternatief kan de gebruiker interageren met de API via de terminal van zijn/haar computer door middel van een command line programma. Het zal gewaardeerd worden dat API bevelen samen geketend kunnen worden om een API script te vormen. Op deze manier kan de automatie en integratie van diverse servicefuncties mogelijk gemaakt worden. De API kan diverse voordelen bieden t.0.v. de GGI via programmatische toegang en automatie, wat creatie van complexe processen en workflows toelaat die niet uitvoerbaar of kostenefficiënt zouden zijn om te implementeren als een GGI functie. De API kan gebruikt worden om gebeurtenissen te genereren.

Hoewel de API veel voordelen heeft ten opzichte van andere interactiemodes, kan het meerdere voordelen ontbreken verleend met gebruik van de GGI. Bijvoorbeeld, de API is mogelijk niet toegankelijk voor gebruikers met ontoereikende programmeerexpertise. In sommige gevallen omvat de API functies niet aanwezig in de GGI, diegenen die enkel met de service interageren met de GGI zijn niet in staat om gebruik te maken van de geavanceerde functies. In sommige voordelige voorbeelden, kan de gebruiker een combinatie van een GUI en een programmeertaal gebruiken om te interageren met het orchestratiemodel voor de infrastructuur.

Het zal worden gewaardeerd dat de werkwijze computer geïmplementeerde stappen kan omvatten. Alle bovengenoemde stappen kunnen computer geïmplementeerde stappen zijn. Belichamingen kunnen computerapparatuur omvatten, waarbij processen uitgevoerd worden in computerapparatuur. De uitvinding omvat ook computerprogramma’s, met name computerprogramma’s op of in een drager, aangepast om de uitvinding in de praktijk te brengen. Het programma kan in de vorm van bron- of objectcode zijn of eender welke andere vorm geschikt voor gebruik in de implementatie van de processen volgens de uitvinding. De drager kan eender welke entiteit of inrichting zijn in staat om het programma te dragen. Bijvoorbeeld, de drager kan een opslagmedium omvatten, zoals een ROM, bijvoorbeeld een halfgeleider ROM of harde schijf. Voorts kan de drager een overdraagbare drager zijn zoals een elektrisch of optisch signaal dat overgebracht kan worden via elektrische of optische kabel of via radio of andere middelen, bijv. via het internet of de cloud. Het zal gewaardeerd worden dat gebruik van een ‘cloud’ kan omvatten om computationele/netwerk/opslag hulpbronnen te verwerven en betere computationele services (zoals gegevensbankservices) over het internet.

Sommige belichamingen kunnen, bijvoorbeeld, geïmplementeerd worden met gebruik van een machine of tastbaar computer-leesbaar medium of artikel dat een instructie of verzameling van instructies kan bewaren dat, als uitgevoerd door een machine, ervoor kan zorgen dat de machine een werkwijze en/of operaties uitvoert in overeenstemming met de belichamingen.

Diverse belichamingen kunnen geïmplementeerd worden met behulp van hardware elementen, software elementen, of een combinatie van beide. Voorbeelden van hardware elementen kunnen processoren, microprocessoren, circuits, applicatie-specifieke geïntegreerde circuits (ASICS), programmeerbare logica-inrichtingen (PLD), digitale signaal processoren, veld programmeerbare poort array (FPGA), logische poorten, registers, halfgeleider inrichting, microchips, chip verzamelingen, et cetera omvatten. Voorbeelden van software kunnen softwarecomponenten, programma’s, applicaties, computerprogramma’s, applicatieprogramma’s, systeemprogramma’s, machineprogramma's, besturingssysteemprogramma's, mobiele applicaties, middleware, firmware, software modules, routines, subroutines, functies, computer geïmplementeerde werkwijzes, procedures, software interfaces, applicatieprogramma interfaces (API), methodes, instructieverzamelingen, rekencode, computercode, et cetera omvatten.

Hierbij is de uitvinding beschreven met referentie naar specifieke voorbeelden van belichamingen van de uitvinding. Het zal echter duidelijk zijn dat diverse modificaties, variaties, alternatieven, en wijzigingen daarbij kunnen gemaakt worden, zonder af te wijken van de essentie van de uitvinding. Ter wille van de duidelijkheid en een gevatte beschrijving zijn functies hierbij beschreven als deel van dezelfde of aparte belichamingen, hoewel, alternatieve belichamingen hebbende combinaties van alle of sommige functies beschreven in deze aparte belichamingen zijn ook ingebeeld en begrepen te vallen onder het framework van de uitvinding zoals uiteengezet door de conclusies. De specificaties, figuren en voorbeelden dienen aldus gezien te worden in een illustratieve betekenis in plaats van in een restrictieve betekenis. De uitvinding is bedoeld om alle alternatieven, modificaties en variaties te omvatten die vallen binnen de geest en het toepassingsgebied van de bijgevoegde conclusies. Voorts zijn veel van de beschreven elementen functionele entiteiten die kunnen geïmplementeerd worden als discrete of gedistribueerde componenten of in conjunctie met andere componenten, in elke passende combinatie en locatie.

In de conclusies dient elk referentieteken geplaatst tussen haakjes niet te worden opgevat als limiterende de conclusie. Het woord ‘omvattende’ sluit geen aanwezigheid uit van andere functies of stappen dan degene vermeld in een conclusie. Voorts dient het woord ‘een’ niet te worden opgevat als limiterend tot ‘alleen één’, maar wordt in plaats daarvan gebruikt om ‘ten minste één’ te betekenen, en sluit geen veelheid uit. Het loutere feit dat bepaalde maatregelen in onderling verschillende conclusies zijn voorgedragen geeft aan dat een combinatie van deze stappen niet tot een voordeel gebruikt kunnen worden.

Claims (18)

Conclusies

1. Een collaboratief gegevensbeheersysteem voor meerdere gebruikers, het systeem omvattende: een relationele gegevensbank met een veelheid van gegevenspunten; een communicatie-interface ingericht om gebruikers toe te laten de relationele gegevensbank te raadplegen; en een versiecontrole-inrichting, ingericht om opeenvolgende historische versies van elke gegevenspunt van de veelheid van gegevenspunten in de relationele gegevensbank bij te houden.

2. Het collaboratief systeem volgens conclusie 1, waarbij de versiecontrole- inrichting is ingericht om historische versies van elk gegevenspunt van de veelheid van gegevenspunten in bovengenoemde relationele gegevensbank te bewaren, waarbij aan elke historische versie metagegevens geassocieerd zijn, de metagegevens omvattende ten minste een gebruikersidentificatie, een tijdsvermelding, en een moederversie waaruit de historische versie was gecreëerd.

3. Het collaboratief systeem volgens conclusie 1 of 2, waarbij de historische versies van elk gegevenspunt van de veelheid van gegevenspunten bewaard in de relationele gegevensbank raadpleegbaar zijn.

4. Het collaboratief systeem volgens een van de voorgaande conclusies, waarbij de versiecontrole-inrichting is ingericht om parallelle workflows met een veelheid van versietakken te ondersteunen.

5. Het collaboratief systeem volgens conclusie 4, waarbij de communicatie- interface is ingericht voor het voorzien van geïsoleerde testomgevingen voor het uitvoeren van wijzigingen aan ten minste één gegevenspunt, waarbij elke geïsoleerde testomgeving geassocieerd is met een versietak.

6. Het collaboratief systeem volgens conclusie 4 of 5, waarbij de versiecontrole- inrichting is ingericht om veranderingen tussen versietakken te detecteren.

7. Het collaboratief systeem volgens conclusie 5 of 6, waarbij de versiecontrole- inrichting is ingericht om wijzigingen aan gegevenspunten in een of meer takken van hoger niveau te detecteren, en automatisch de wijzigingen aan de gegevenspunten in de een of meer takken van hoger niveau aan gegevenspunten in een of meer takken van lager niveau aan te brengen.

8. Het collaboratief systeem volgens een van de voorgaande conclusies 4-7, waarbij de versiecontrole-inrichting is ingericht om samenvoeging van versietakken toe te laten.

9. Het collaboratief systeem volgens een van de voorgaande conclusies, waarbij de versiecontrole-inrichting is ingericht om een geldigheidscheck uit te voeren wanneer een samenvoeging van versietakken wordt geïnitieerd, waarbij de versiecontrole-inrichting is ingericht om na te gaan of de overgang naar een samengevoegde tak toelaatbaar is.

10. Het collaboratief systeem volgens een van de voorgaande conclusies, waarbij de versiecontrole-inrichting is ingericht om aan elk gegevenspunt een historieboom te associëren omvattende historie-informatie, met betrekking op een wijzigingspad dat is uitgevoerd om te komen tot een laatste versie van het respectieve gegevenspunt.

11. Het collaboratief systeem volgens een van de voorgaande conclusies 8-10, waarbij de versiecontrole-inrichting is ingericht om, wanneer een eerste versietak wordt samengevoegd tot een tweede versietak, een gemeenschappelijke voorouder van de eerste en de tweede versietakken te identificeren, waarbij de gemeenschappelijke voorouder een laatst gemeenschappelijke versie is van de eerste versietak en de tweede versietak, waarbij de versiecontrole-inrichting is ingericht om op basis van de gemeenschappelijke voorouder te bepalen welke kolommen van het gegevenspunt gewijzigd zijn en of er samenvoegingsconflicten aanwezig zijn.

12. Het collaboratief systeem volgens conclusie 11, waarbij het identificeren van de gemeenschappelijke voorouder van een gegevenspunt in de eerste en tweede versietakken omvat het recursief doorheen de versiehistorie van dat respectieve gegevenspunt gaan, beginnende van zowel de versie in de eerste als tweede tak totdat een gemeenschappelijk gedeelde versie is aangetroffen.

13. Het collaboratief systeem volgens conclusie 10 of 11, waarbij de versiecontrole-inrichting is ingericht om gemeenschappelijke voorouders op te sporen over alle versietakken.

14. Het collaboratief systeem volgens een van de voorgaande conclusies, waarbij de veelheid van gegevenspunten herconfigureerbaar is naar een geselecteerde voorafgaande historische versie door middel van de versiecontrole-inrichting, waarbij de versiecontrole-inrichting is ingericht om een terugdraaifunctie te voorzien, waarbij als reactie op een terugdraaiing de versiecontrole-inrichting is ingericht om een terugdraaiovergang uit te voeren door ten minste één gegevenspunt van de veelheid van gegevenspunten naar een voorafgaande versie van de historische versies van dat genoemde ten minste één gegevenspunt te herstellen.

15. Het collaboratief systeem volgens een van de voorgaande conclusies, waarbij de relationele gegevensbank een gecentraliseerde gegevensbank is.

16. Een werkwijze voor het voorzien van een collaboratief gegevensbeheerplatform voor meerdere gebruikers, de werkwijze omvattende: het voorzien van een relationele gegevensbank met een veelheid van gegevenspunten; het voorzien van een communicatie-interface om gebruikers toe te laten de relationele gegevensbank te raadplegen; en het voorzien van een versiecontrole-inrichting om opeenvolgende historische versies van elk gegevenspunt van de veelheid van gegevenspunten in de gecentraliseerde relationele gegevensbank bij te houden.

17. Een computerprogramma ingericht om de stappen van de werkwijze volgens conclusie 16 uit te voeren wanneer uitgevoerd op een rekenstation.

18. Een inrichting omvattende een rekenstation met een processor, gekoppeld aaneen geheugen, bedienbaar om het rekenstation de werkwijze volgens conclusie 16 te doen uitvoeren.