Functionele sleutels of surrogate keys ? Een tijd lang waren de gegenereerde sleutels wet voor een datawarehouse. Argumenten waren dat functionele sleutels in de geschiedenis herbruikt konden worden of dat functionele sleutels slechts sleutel zijn in één operationeel systeem terwijl het datawarehouse gevoed kan worden uit verschillende operationele systemen voor hetzelfde soort gegeven, de zelfde entiteit. Maar nu realtime datawarehouses en simultane ontsluiting van realtime en klassieke datawarehouses gevraagd wordt moet de koppeling toch weer op de functionele sleutel, want de gegenereerde sleutel is in een realtime datawarehouse of een ODS nog niet bekend!
Ook met de groeiende populariteit van masterdata management steekt die discussie opnieuw de kop op. Gegeneerde sleutels mogen niet voor masterdata ! Wat zijn er overigens veel ICT-ers die niet weten wat masterdata zijn, maar dat terzijde…. Databasebeheerders houden van gegenereerde betekenisloze sleutels en griezelen van identifiers met versleutelde informatie zoals FRI003 waarbij FRI staat voor Friesland of een geboortedatum in een rijbewijs en dergelijke. We zijn het in ieder geval eens over het feit dat een gegeneerde sleutel alleen voor intern database gebruik is. Of ? Het gironummer is ooit ontstaan als betekenisloze gegenereerde sleutel. Het was gewoon een nummer waaronder de overeenkomst werd vastgelegd tussen een klant en de Post Cheque en Girodienst. Op een gironummer zit ook geen 11-proef. Toch is het nu wel DE unieke sleutel geworden van een belangrijke entiteit en foreign key in vele, vele documenten !
In de traditionele vorm van datawarehousing, waar het datawarehouse periodiek/batchgewijs wordt ververst en voornamelijk strategische decision support activiteiten worden uitgevoerd, is het toepassen van gegenereerde sleutels geen ongebruikelijke keuze.Karien stelt echter terecht dat het datawarehouse tegenwoordig niet meer uitsluitend wordt gebruikt ten behoeve van de ‘backoffice analyses’, maar dat dit platform meer en meer ingezet wordt bij operationele beslissingsondersteuning. Hiermee is de rol van het datawarehouse binnen de organisatie drastisch gewijzigd van een ‘laatste schakel in de data-keten’ naar een ‘actieve component’ in de informatieverzorging. Het datawarehouse wordt geïntegreerd in de primaire processen van de organisatie.De traditionele discrepantie die met betrekking tot de referentiedata historisch bestaat tussen de operationele systemen enerzijds (logischesleutels) en Object_IDentifiers / gegenereerde sleutels anderzijds, is terug toe voeren op zowel het tijdhistorische karakter van het datawarehouse (opvangen hergebruik sleutels in operationele systemen) en anderzijds de data-integrerende functie van het datawarehouse (homoniemen in sleutels vanuit disparate systemen). Tel hierbij op de uitdaging om sleutels met verschillende domeinen, die binnen het datawarehouse ‘gestapeld’ worden tot één concept te integreren en een gegenereerde sleutel ligt al snel voor de hand.Het is overigens een misvatting te stellen dat alle datawarehouses per definitie op basis van gegenereerde sleutels zouden moeten worden ontworpen. Binnen één datawarehouse kan per subjectarea (deelmodel: een groep gerelateerde entiteiten welke tezamen een logisch beeld op een voor de organisatie belangrijk dataconcept geven) een keuze gemaakt worden met betrekking tot de sleuteldefinitie. Zo is het denkbaar de datawarehouse sleutel van de ‘contracten’ entiteit binnen een (financiële omgeving) datawarehouse op basis van (onder meer) de logische sleutel ofwel het contractnummer/rekeningnummer vast te stellen. Dit eenvoudigweg om de massieve hoeveelheden financiële transacties welke met de contracten geassocieerd zijn en periodiek geladen worden op efficiënte wijze te kunnen verwerken. Zeker bij zeer actieve toepassingen (denk aan fraudedetectie) is het denkbaar dat transacties worden geanalyseerd met betrekking tot contracten waarvan de sleutel binnen het datawarehouse nog niet opgenomen is, eenvoudigweg omdat de ontsluiting tussen transacties en contracten niet per se synchroon hoeft te geschieden. Voor andere subject-area’s binnen hetzelfde model, bijvoorbeeld de transacties/events zélf, zou vervolgens gekozen kunnen worden om gegenereerde sleutels toe te passen.De kern van de oplossing op langere termijn is, zoals al door Karien aangestipt, gelegen in een gedegen Master Data Management oplossing. Master Data Management refereert aan de wijze waarop geschoonde, accurate en consistente referentiegegevens (klanten, producten, locaties, etc) worden beheerd, wordt gerefereerd en wordt gesynchroniseerd over de organisatie, en uiteraard beschikbaar wordt gesteld aan gebruikers/applicaties indien nodig.De éénduidige, organisatiebrede vastlegging (en distributie!) van alle referentiedata faciliteert de samensmelting van de momentane inzichten vanuit de operationele systemen en de historische inzichten vanuit het datawarehouse.Hoewel Master Data Management een operationele omgeving is, wil ik hier een lans breken om de repository van master data management te integreren met het datawarehouse platform. Als het datawarehouse de rol van ‘single version of the truth’ vervult, en niet alleen strategisch maar ook operationeel ingezet wordt, dan is een andere plaats welhaast ondenkbaar!Het datawarehouse, als gastheer van de Master Data Management infrastructuur, zou in zo’n geval op gelijkaardige wijze als de ‘overige operationele systemen en processen’ putten uit dezelfde, consistente collectie referentiedata. Hiermee wordt de ultieme integratie tussen de strategische ondersteuningsfuncties enerzijds en de tactische/operationele beslissingsondersteuning anderzijds geborgd, en een structureel alternatief voor gegenereerde sleutels geboden.Pieter Willigsenior consultant NCR Teradata
De teneur van deze stelling is dat het suggereert dat het òf-òf is. Het lijkt mij de bedoeling om naast de gegenereerde, betekenisloze sleutel ook de logische, business sleutel bij te houden. Dit is zelfs een must omdat er anders informatie verloren gaat en dat is juist niet de insteek van een datawarehouse. Wat mij betreft is de toevoeging van een surrogaat sleutel puur een handeling vanuit een noodzaak. Doordat er historie wordt bijgehouden krijg je meerdere versies van één logische entiteit. Doordat data vanuit verschillende bronnen samengevoegd wordt en elke bron zijn eigen sleutels of combinatie van sleutels gebruikt moet je iets anders. Door deze zaken volstaat de logische sleutel niet meer als uniek identificerend gegeven. Verder is het vaak ook technisch interessant om surrogaatsleutels te gebruiken. Overweging hierbij is dat je mogelijk liever een index maakt op een integer-veld dan op een gekke lange string die toevallig identificerend is in het operationele systeem. Het een sluit het ander echter niet uit. Door een extra join te leggen kun je vaak de logische sleutel bij de surrogaat sleutel vinden. Als je weet hoe de structuur van het data warehouse in elkaar zit, is dit veelal simpel. Maar het is nu eenmaal de directe keerzijde van het gebruik van gegenereerde sleutels; je kunt pas betekenis voor de business afleiden nadat je een extra join hebt gedaan. Als laatste wil ik opmerken dat het een misvatting is dat Master Data geen gebruik zou maken van surrogaat sleutels. Vaak wil je ook de ontwikkeling van Master Data in de tijd bijhouden, op z’n minst voor tracing doeleinden. Dit kun je natuurlijk in het data warehouse zelf doen en niet in de Master Data database, maar dat is slechts een kwestie van definitie: waar eindigt de master data en waar begint de data in het data warehouse. Vaak is er bij de gebruikers die de master data beheren een tijdsafhankelijke behoefte. Bijvoorbeeld, nu valt een vestiging nog onder regio A, maar vanaf 1 januari valt deze onder regio B. Door de beheerders deze mogelijkheid te geven, geef je hen meer handvatten om de master data te managen. Wanneer die mogelijkheid er niet is, moet de beheerder wachten tot 1 januari om de nieuwe referentie in te voeren omdat nu nog de huidige referentie van kracht is. Echter, 1 januari is net een vakantiedag en vaak is de beheerder er misschien pas een paar dagen later, waardoor een korte periode foute referenties gebruikt worden. Dan is er weer een correctieve actie nodig om dit recht te trekken. Erik-Jan KoningBI&DWH achitectKadenzaEnterprise Intelligence Specialist
Surrogate keys zijn een soms noodzakelijk kwaad. De noodzaak wordt in het algemeen ingegeven door optimalisatie van modellen voor performance. Bijvoorbeeld in het geval van slowly changing dimensions kan een key door de toevoeging van de benodigde timestamps erg lang worden. Dit heeft rechtstreeks impact op query performance en storage requirements. Als we streng de wetten van relationeel modelleren volgen, dan zijn surrogate keys overbodig. Hieruit kunnen we concluderen dat het puur om fysieke constructies gaat die geen enkele logische betekenis hebben. Als we deze redenering volgen dan kunnen we de noodzaak voor surrogate keys opheffen door ervoor te zorgen dat brede sleutels en complexe joins geen beletsel meer vormen.Zijn er wellicht nog andere redenen te bedenken voor het genereren van sleutels? In dat kader is het gironummer een interessant voorbeeld. Als we een rekening zien als overeenkomst tussen twee partijen, dan voldoet in eerste instantie een sleutel met daarin de identifiers van de twee partijen. Die hoeft echter niet uniek te zijn, er kan meer dan één overeenkomst bestaan. Daartoe kunnen we een contracttype en eventuele timestamps voor geldigheid aan de sleutel toevoegen. Nog steeds kan iemand dan twee girorekeningen tegelijkertijd hebben, dus we komen er niet onderuit om iets als een volgnummer aan de sleutel toe te voegen. Hier is dus een echte noodzaak voor een (gedeeltelijk) gegenereerde sleutel. In dit geval slaan we twee vliegen in een klap als we de volgende regel introduceren: indien een sleutel gegenereerde delen bevat is het raadzaam om de gehele sleutel te genereren. Alle overige onderdelen van de sleutel worden dan alleen foreign key en geen onderdeel meer van de primary key.Wat betreft complexe joins en brede sleutels zijn er in moderne databases gelukkig uitstekende voorzieningen, zoals bijvoorbeeld star joins, multidimensional clustering en compression. Verder kunnen autonoom onderhouden caching- en aggregatie-tabellen de fysieke barrières verlagen die een directe implementatie van een logisch model in de weg staan, zeker als ze geïntegreerd zijn in de optimizer. Daarmee wordt het bovendien mogelijk om complexe koppelingen tussen diverse systemen met een minimale belasting van de bronnen af te handelen, wat voor Master Data Management onontbeerlijk is. We zijn tegenwoordig in staat om een logisch model virtueel ter beschikking te stellen op één centraal te benaderen plaats. Van hieruit worden alle koppelingen en transformaties, maar ook security en optimalisatie geregeld: Information On Demand!Damiaan ZwieteringSenior Technical SalesIBM Software GroupInformation Management
De techniek, de database en tools, dwingt niet tot het maken van een keuze tussen functionele- of gegenereerde sleutels. Uniciteit kan op beide soorten sleutels met constraints worden afgedwongen (primaire -en uniciteitsconstraints), indices kunnen uitstekend overweg met beide soorten sleutels en indien sprake is van onnodig veel opslagruimte dan kan een tabel in een DWH prima gecomprimeerd worden opgeslagen, dit scheelt al gauw de helft aan schijfruimte en verbeterd de snelheid van zoekopdrachten. Voor real-time data warehousing is het essentieel om een transactie voldoende snel kunnen verwerken voordat een volgende arriveert. Dit dwingt veelal leidt veelal tot systeemontwerpen waarbij zaken als historie en ontdubbeling achterwege zijn gelaten. In een dergelijk datamodel hebben gegenereerde sleutels weinig nut. In praktijk is er echter vaker sprake van ‘near-real time’ data warehousing omdat ervoor gekozen wordt om zo min mogelijk concessies te doen aan data kwaliteit en analytische mogelijkheden. Hier zien we wel degelijk de gegenereerde sleutels terug om de eerder genoemde redenen. Vanuit technisch oogpunt zijn beide soorten sleutels mogelijk. Maar als iets kan is het dan ook de optimale oplossing? Waarom zouden we niet de voordelen van gegenereerde sleutels combineren met die van functionele? Ze kunnen vanuit technisch oogpunt prima naast elkaar bestaan en een optimale oplossing creeren.Wat is dan toch de vloek van de gegenereerde sleutel? Dat gegenereerde sleutels ooit de buitenwereld hebben betreden zoals het gironummer? Dat laatste is inderdaad niet handig, immers mensen en gegenereerde sleutels zijn geen optimale combinatie in een gegevensverwerkend proces; typefouten worden snel gemaakt, maar niet ontdekt omdat een betekenisloos nummer niet door de gebruiker wordt onthouden en verder ook geen controles(elf-proef) of informatie ter controle heeft. Een goede functionele sleutel, voor gebruik buiten het systeem, is ook gegenereerd maar dan met oog voor het gebruik in een gegevensverwerkend proces. Dit oog voor gegevensverwerkende processen is aanwezig in het geval van Master Data Management en uit zich in aandacht voor techniek, processen, procedures en services. Vanuit de integratie van bronnen onstaat de behoefte aan een algemene interne sleutel. Indien deze sleutel voor communicatie met andere partijen of systemen wordt gebruikt (en dit ligt voor de hand) dan gelden hiervoor analoog aan de vorige paragraafextra eisen.Cees van TilburgTechnical ArchitectOracle
Welke Master Data problemen komen er volgens jullie voor wanneer er sprake is van gedistribueerde datawarehousing? Dus dat wij niet meer over één centrale datawarehouse pratten maar over een koppeling van meerdere.B. OukrineBI & Data managementAccenture