In de StUF-standaard staat dat het gebruik van kerngegevens "verplicht" is. Zie onderstaand citaat.
In bijgevoegd bericht mis ik o.a. het kerngegeven "Burgerservicenummer". Voldoet dit bericht nu wel of niet aan de standaard?
3.1.3 Identificatie: kerngegevens en systeemsleutels
Een steeds terugkerend probleem bij de uitwisseling van gegevens is om vast te stellen op welk object in de werkelijk¬heid de gegevens betrekking hebben. Geslachtsnaam, voorletters en adres zijn niet altijd voldoende om een persoon te identificeren. Denk aan twee gezinsleden met dezelfde voorletters die op hetzelfde adres wonen. Problemen met onvolledige gegevens (niet alle voorletters zijn meegestuurd) of onjuiste gegevens (een tikfout in de geslachtsnaam, de voorletter van de roepnaam in plaats van de officiële voornaam, of een foutief adres) laten we dan nog buiten beschou¬wing.
Om problemen met de identificatie te vermijden kent StUF het begrip kerngegevens. Dit is een deelverzameling van de attributen en relaties van een entiteittype aan de hand waarvan een object kan worden geïdentificeerd. Bij personen kan bijvoorbeeld voor de volgende set identificerende gegevens gekozen worden:
- Burgerservicenummer
- A-nummer
- Naamgegevens (Geslachtsnaam, voorvoegsel en voorletters)
- Verblijfsadres
- Geboortedatum
- Geslacht
Bij een aantal berichtsoorten zal in de volgende hoofdstukken het al dan niet verplicht zijn van de kerngegevens gespecificeerd worden. In het sectormodel dienen voor elk entiteittype met uitzondering van een superentiteittype de verzameling kerngegevens gedefinieerd te worden. Als bij een relatie entiteittype geen kerngegevens zijn gespecificeerd, dan mag ervan uitgegaan worden dat het fundamentele entiteittype vanwaaruit de relatie ligt en de gerelateerde de kerngegevens zijn. Er wordt geen gereserveerd element gedefinieerd voor de kerngegevens, omdat dit leidt tot inflexibiliteit bij het definiëren van de berichten in een sectormodel.
Gebruik in kennisgeving
De tabellen 5.3 en 5.5 met hun legenda specificeren dat kerngegevens in kennisgevingen verplicht zijn tenzij de sleutelOntvangend in een entiteit zit.
Het bijgaande bericht bevat een waarde voor sleutelOntvangend. Als sleutelOntvangend gevuld is, dan zijn de kerngegevens niet meer verplicht. Dit bericht is dus valid (voor wat betreft het niet aanwezig zijn van alle kerngegevens).
Met vriendelijke groet,
Maarten
Dag Maarten,
Hoe ga je in een dergelijk geval om met het synchroniseren van betreffend gegeven in een gegevensmagazijn conform RSGB, dat de BSN als sleutel heeft en de leverancierspecifieke sleutels niet opslaat?
Met vriendelijke groet,
Dick Beekman
Dit betekent dus dat er twee smaken zijn:
Wanneer partijen met elkaar koppelen moet de afnemer dus altijd de aanbieder volgen, deze dicteert welke variant gebruikt wordt. Waanneer de afnemer dan ook met verschillende aanbieders moet aansluiten moeten wellicht alle smaken onstreunt worden.
Dit leidt er toe dat het implmenteren van de StUF standaard niet altijd eenduidig is, het koppelen vereenvoudigd en tijd bespaart.
Met vriendelijk groet, Niek Palm
Als ik de StUF 02.04 spec lees dan lijkt dat document mij vrij duidelijk: de kerngegevens zijn verplicht in een kennisgeving, tenzij de sleutelOntvangend is opgenomen.
In weerwil van de praktijk lijkt het mij verstandig dat een zendende applicatie niet gedwongen wordt de sleutel van het ontvangende systeem te onthouden; het mogelijk maken van een best mogelijke performance bij het verwerken van het bericht door het ontvangende systeem is een nobel streven, maar mag m.i. niet maatgevend zijn voor het zendende systeem. Temeer en zendend systeem meerdere afnemers kan hebben en de last dan onevenredig groot wordt.
Ik wil daarom voorstellen hiervan een RFC te maken zodat bij een nieuwere versie van StUF (van StUF 02 en StUF 03) de sleutelOntvangend optioneel is en blijft en dat in een kennisgeving de kerngegevens altijd verplicht zijn, ook als de sleutelOntvangendis opgenomen in een kennisgeving. Daarmee wordt bereikt dat voor de zendende systemen de eisen duidelijk zijn en dat een ontvangend systeem een optie voor een betere performance heeft terwijl ook voor dat systeem duidelijk is dat altijd de kerngegevens beschikbaar zijn.
Hallo,
Ten aanzien van de laatste vraag van Dick (Hoe ga je in een dergelijk geval om met het synchroniseren van betreffend gegeven in een gegevensmagazijn conform RSGB, dat de BSN als sleutel heeft en de leverancierspecifieke sleutels niet opslaat?) zal gelden dat:
1. het zendende systeem "weet"dat het afnemende magazijn het BSN als sleutel gebruikt en het BSN als sleutelOntvangend opneemt
of
2. het zendende systeem niet "weet"dat het afnemende magazijn het BSN als sleutel gebruikt en dus geen sleutelOntvangend opneemt maar wel de kerngegevens met daarin (onder andere) een gevuld BSN.
Ik ben daarom van mening dat een RFC (zoals door Han voorgesteld) niet vereist is omdat de StUF specificatie dit nu reeds mogelijk maakt.
Groeten, John