Hoe om te gaan met bidirectionele relaties?

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

2 reacties / 0 nieuw
Dick Beekman
Hoe om te gaan met bidirectionele relaties?

Het is mij niet helemaal helder hoe om te gaan met bidirectionele relaties.

Bijvoorbeeld:
Als mens kun je eenvoudig uit een bericht extraheren dat, wanneer Jan Klaasen met Katrein getrouwd is, Katrein ook wel met Jan Klaasen getrouwd moet zijn. Echter bij automatische verwerking leidt dit tot complexe business logica.

Voor mij is het in de StUF documentatie niet helder wat nu de voorgeschreven oplossing voor bovenstaande casus is:
1. oplossen via eenvoudig, transparant StUF-berichtenverkeer (zowel een wijzigingsbericht voor de Jan Klaassen als Katrein) of
2. via complexe, leveranciersafhankelijke businesslogica dat de bi-directionele relatie herkent.

Wie kan mij hierop antwoord geven?

Onderstaand de citaten uit de verschillende StUF-documenten:

In het document StUF voor applicaties StUF 02.04: EGEM Aanbeveling(versie 01) staat hierover in hoofstuk 5.1.1, punt 3 het volgende:

3. relatie-entiteittypen
Een relatie-entiteittype representeert een relatie, bijvoorbeeld tussen een persoon en een adres. Tussen
persoon en adres bestaan verschillende relaties, bijvoorbeeld PERSOON.verblijft op.ADRES3,
PERSOON.ontvangt post op.ADRES, en ADRES.heeft erop gevestigd.PERSOON. Een relatie-entiteittype
definieert een verband tussen het linker object en het rechter object uitgaande van het linker object (de
richting van de relatie is hier dus relevant). De relatie PERSOON.verblijft op.ADRES geeft de verblijfplaats
van een persoon (een eigenschap van een persoon) en de relatie ADRES.heeft erop gevestigd.PERSOON
geeft de personen die op een bepaald adres zijn gevestigd (eigenschappen van dat adres).
Voor elke onderkende relatie moet in het sectormodel een relatie-entiteittype worden gedefinieerd. In het
bovenstaande voorbeeld zijn er twee relaties tussen PERSOON en ADRES, en één tussen ADRES en
PERSOON. In totaal zijn dit dus drie relatie-entiteittypen.
Een relatie als een huwelijk tussen twee personen (PERSOON.is (was) gehuwd met.PERSOON) heeft zelf
weer eigenschappen als de datum huwelijkssluiting en het land huwelijkssluiting. Die zijn onderdeel van het
relatie-entiteittype.
Voor een relatie-entiteittype kunnen geen berichten worden gedefinieerd, omdat een relatie-entiteit
afhankelijk is van het object van waaruit de relatie ligt. Wanneer een huwelijk gedefinieerd is als een relatieentiteittype,
dan kunnen er dus voor een huwelijk geen berichten worden gedefinieerd. Indien dit bezwaarlijk
is, kan het huwelijk ook gedefinieerd worden als een fundamenteel entiteittype met twee relaties naar het
fundamentele entiteittype persoon. De beperking dat er voor een relatie-entiteittype geen berichten
gedefinieerd kunnen worden legt dus geen beperking op aan de functionaliteit van de gegevensuitwisseling. 

In hoofdstuk 5.1.7 punten 2&3 het volgende:

2. Het toevoegen of beëindigen van een relatie
Het toevoegen en verwijderen van alle relaties die direct gekoppeld zijn aan het fundamentele entiteittype in de
kop van het bericht kan via een kennisgevingbericht worden doorgegeven. Wanneer dit niet het geval is, dient
dit expliciet in het sectormodel te worden vermeld.
3. Een wijziging in de gegevens van relatie-entiteit
Een wijziging in de gegevens van een relatie-entiteit die direct gerelateerd is aan een fundamentele entiteit uit
de kop van het bericht kan via een kennisgevingbericht worden doorgegeven. Wanneer deze wijziging niet op
deze manier kan worden doorgegeven dient dit expliciet in het sectormodel te worden vermeld.

In hoofdstuk 6.2.3, laatste alinea:

Bij het wijzigen of corrigeren van een relatie mag in het sectormodel worden gespecificeerd dat als onderdeel van de
wijziging ook gegevens van het gerelateerde object mogen worden gewijzigd. Dit gebeurt bijvoorbeeld als bij een
huwelijk de naam van de echtgenoot wordt gewijzigd. Het huwelijk (PRSPRSHUW) blijft hetzelfde, maar de
gegevens van de gerelateerde persoon wijzigen. Een dergelijke wijziging in de gegevens van de partner mag alleen
worden doorgegeven als dit expliciet in het sectormodel is gedefinieerd. Zo niet, dan moet een wijziging in de
gerelateerde entiteit worden doorgegeven als een wijziging in het fundamentele entiteittype zelf. Bij het wijzigen of
corrigeren van gegevens in het gerelateerde object dient als verwerkingssoort ‘W’ te worden gespecificeerd en gelden
verder dezelfde regels als voor het wijzigen van een fundamentele entiteit met inachtneming van de beperkingen
gedefinieerd in het sectormodel.

En tot slot in het Sectormodel StUF-BG (02.04): Berichtdefinities op pagina 18 het volgende:

... Via een kennisgevingsbericht voor een persoon mogen geen wijzigingen in een gerelateerd persoon worden doorgegeven. Hiervoor moet een kennisgevingsbericht voor die gerelateerde persoon gebruikt worden.
...

Maarten van den...

Hallo Dick,
Een huwelijk is een zogenaamde reflexieve relatie, dat wil zeggen als Jan getrouwd is met Katrein, dan is ook Katrein getrouwd met Jan. Dit is geen StUF voorschrift maar volgt gewoon uit de definitie van het huwelijk in de werkelijkheid (niet in de GBA overigens, want daar worden akten geregistreerd en kan het voorkomen dat de akte wel bekend is bij Jan en niet bij Katrein, zodat in de GBA Jan wel getrouwd is met Katrein, maar Katrein niet met Jan).
StUF biedt de mogelijkheid om zowel in een bericht over Jan het huwelijk mee te geven als in een bericht over Katrein. Omdat het huwelijk reflexief is, zal bij de berichtverwerking nagegaan moeten worden of het huwelijk van Jan  met Katrein bij Jan niet al vastgelegd is als het huwelijk van Katrein met Jan bij Katrein. Zo ja, dan dient de toevoeging van het huwelijk bij Jan genegeerd te worden of te worden verwerkt als een wijziging op het huwelijk bij Katrein.
Bij het beantwoorden van vragen speellt precies hetzelfde. Als gevraagd naar de huwelijken van Jan, dan moet niet alleen gezocht worden naar de huwelijken die beginnen met Jan, maar ook naar de huwelijken waarbij Jan de partner is van een ander.
Het is aan de implementerende partijen om deze business logica in te bouwen.
Maarten