In de expertgroep informatiemodellen december jongstleden is besloten alternatieve sleutels op te nemen in de informatiemodellen naast de unieke aanduiding van een objecttype.
- Een alternatieve sleutel is een combinatie van attributen (en relaties) waarmee een voorkomen van een objecttype geïdentificeerd kan worden. Denk bijvoorbeeld aan de combinatie achternaam, voornaam, voorletters en woonplaats voor een ingeschreven natuurlijk persoon of de combinatie geboortedatum, geslacht en geboorteplaats.
- De unieke aanduiding is een combinatie van attributen en relaties waarmee een voorkomen van een objecttype uniek is te identificeren. Bijvoorbeeld de unieke aanduiding BSN voor een ingeschreven natuurlijk persoon
De alternatieve sleutels 'vervangen' hiermee de kerngegevens in StUF in de zin dat er nu een of meer combinaties van een set van gegevens worden gedefinieerd waarmee een voorkomen kan worden geïdentificeerd.
Per koppelvlak kan scherper worden gedefinieerd welke alternatieve sleutels er kunnen zijn. Die zijn niet verplicht maar kunnen worden gebruikt ter controle. Ze zijn als set dus wel identificerend, maar niet verplicht om te gebruiken.
De bedoeling is deze alternatieve sleutels op te nemen in de eerstvolgende nieuwe versie van RSGB (?4.0?), RGBZ en imZTC. Tenzij er sterke argumenten zijn om dit in de huidige bevroren versies van de referentie informatiemodellen op te nemen.
Voorlopig is als uitgangspunt gehanteerd dat de kerngegevens zoals deze nu zijn gedefinieerd de basis vormen voor de specificatie van alternatieve sleutels. Als tijdens de analyse blijkt dat een andere set van gegevens gewenst is, zal dit expliciet aangegeven worden. Gevraagd wordt aan de expertgroep StUF wat de implicaties voor StUF t.a.v. kerngegevens zijn als we in de informatiemodellen alternatieve sleutels opnemen. En of zij met voorgestelde planning eens zijn.
Een goede zaak om alternatieve sleutels te gebruiken ipv kerngegevens. Maar zijn alternatieve sleutels uniek zoals het begrip alternate key? Ik hoop nl van wel maar in de voorbeelden die gebruikt worden is dat nl niet het geval.
De voorbeelden zijn fictief. Maar een alternatieve sleutel is niet uniek maar de gekozen combinatie van gegevens zal bij benadering bijvoorbeeld voor 98% een ingeschreven natuurlijk persoon kunnen identificeren.
Een alternatieve sleutel is niet voor niets een sleutel, dus één eigenschap/gegeven of een combinatie van gegevens die een object uniek identificeert. Voor 100% zeker dus, net als een primaire sleutel.
Een alternatieve sleutel is niet voor niets een sleutel, dus één eigenschap/gegeven of een combinatie van gegevens die een object uniek identificeert. Voor 100% zeker dus, net als een primaire sleutel.
Ik ben het met Rindert eens, anders moeten we het geen alternatieve sleutel noemen. In database termen heeft dat de betekenis van alternatieve functionele sleutel, dus uniek.
Hmmm is de term alternatieve sleutel dan wel de juiste keuze? Is het misschien beter om het zoeksleutel te noemen? Want de kerngegevens zoals ze bedoeld zijn / waren in StUF hebben betrekking op een combinatie van gegevens die niet uniek hoeven te zijn. Een zoeksleutel bestaat dan uit één of meerdere attributen en / of relaties waarmee gezocht kan worden naar een object i.p.v. de unieke aanduiding . De zoeksleutel is mogelijk niet uniek identificerend maar m.b.v. de zoeksleutel is er een gerede kans dat het object gevonden wordt.
De (voormalige) "kerngegevens" hebben naar mijn mening twee verschillende doelstellingen:
1. Identificatie van het object indien een unieke sleutel (bv BSN) niet voorhanden is.
2. Verificatie van het object indien een unieke sleutel (bv BAG-ID) wel voorhanden is.
De tweede doelstelling is van belang indien een typefout in de unieke sleutel kan leiden tot het gebruik van het verkeerde object. De kans daarop bij een BSN is daarop erg klein, maar bij een BAG-ID erg groot.
Wellicht dat we dus kunnen spreken over "identificerende en validerende" gegevens.