Beste leden StUF Expertgroep en andere geïnteresseerden,
In de bijlage van deze post heb ik een notitie ('vertaalscenario's rollen van een betrokkene in zkn0320.pdf') opgenomen waarin drie scenario’s worden geschetst voor het modelleren van de rollen van een betrokkene in StUF-ZKN 3.20:
Scenario 1: Opsplitsen van rollen in aparte relatie-entiteiten.
Scenario 2: Eén generieke relatie voor alle rollen.
Scenario 3: Hybride aanpak.
Vooralsnog heeft scenario 3 (Hybride aanpak) zoals voorgesteld in de laatste bijeenkomst van de expertgroep mijn persoonlijke voorkeur. Daarna scenario 2 (Eén generieke relatie voor alle rollen). Scenario 1 lijkt een show-stopper te zijn omdat je daarmee een belangrijk type vragen niet kunt stellen.
Indien je het niet eens bent met scenario 3, dien dan uiterlijk voor 2 september via dit forum je bezwaar in. Geef dan aan welk ander scenario je voorkeur heeft en waarom.
Ik hoop in de bijeenkomst van 16 september een definitief besluit te kunnen nemen over dit onderwerp.
Mvg,
Henri Korver
Alvorens een keuze te maken, heb ik nog een vraag: waarom is in scenario 3 gesteld "De attribuutsoorten ‘Rolomschrijving’, ‘Rolomschrijving generiek’ en ‘Roltoelichting’ worden niet overgenomen in de relatie-entiteit ZAKBTR.". Die zijn toch juist relevant om alsnog onderscheid te kunnen maken tussen de resultaten die je ontvangt? Of is het idee dat je dat dan weer via de individuele relaties achterhaalt? Ik zie het voordeel van deze beperking even niet...
Sid, Het idee is om een manier te hebben om te zoeken naar een bepaalde betrokkene onafhankelijk van welke rol deze heeft vervuld. Het vullen van 'Rolomschrijving generiek' zou dat te niet doen. Er is dus wel een voordeel als je bij deze manier van zoeken geen waarde bij 'Rolomschrijving generiek' invult. De vraag is echter meer of het onmogelijk maken van het invullen van 'Rolomschrijving generiek' een voordeel oplevert.
Je reactie lezend concludeer ik dat dit niet het geval is het weglaten van 'Rolomschrijving generiek' zou jou juist een manier ontnemen om een eerdere zoekopdracht op basis van het resultaat te verfijnen.
Beste Sid en Robert,
dank voor jullie reacties. Hieruit maak ik op dat de strekking van scenario 3 nog niet helemaal goed is overgekomen. Daarom heb ik de notitie aangepast (zie bijlage) en vooral geprobeerd om scenario 3 beter onder de woorden te brengen. Onder andere heb ik in scenario 3 de relatie(-entiteittype) ZAKBTR omgedoopt naar ZAKBTRBTR. In scenario 2 komt er namelijk ook een relatie ZAKBTR voor die een hele andere semantiek heeft. Bijv. ZAKBTR beschikt wel over de attribuutsoorten ‘Rolomschrijving’ generiek’, ‘Rolomschrijving’ en ‘Roltoelichting’ en ZAKBTRBTR juist niet en wel om deze twee redenen:
Als we in ZAKBTRBTR wel het attribuutsoort ‘Rolomschrijving generiek’ zouden opnemen dan kun je op twee verschillende manieren dezelfde soort vragen stellen. Dat lijkt me onwenselijk en niet goed voor de interoperabiliteit.
Scenario 3 (voorheen: Hybride aanpak) heeft nu in mijn ogen een betere titel gekregen: “Scenario 1 uitgebreid met één extra relatie”.
Mvg,
Henri Korver
Bijlage
bijgaand ook de notitie met renvooi zodat je de wijzigingen kunt zien die ik heb aangebracht
Bijlage
Is er bij de uitwerking rekening gehouden met de mogelijke modellering binnen zakenmagazijnen? Als een magazijn elke relatie als een afzonderlijke tabel heeft geimplementeerd, zal het niet zo eenvoudig zijn om deze nieuwe relatie bevraging in een query op te vangen.
Ook vraag ik me af of het toch niet handig is om de rol op te kunnen geven. Als ik van persoon X alleen maar wil weten waar deze behandelaar of beslisser is, dan kan ik dat niet kwijt
Als je scenario 3 bedoelt dan vergt het inderdaad extra inspanning om een extra relatie te implementeren. Dat staat ook expliciet vermeld in de nadelen van scenario 3.
Je tweede en laatste vraag begrijp ik niet helemaal. Kun je die vraag iets preciezer formuleren?