|
Tags: Database | Oracle
| ||
| ||
Generiek data modellerenNaar alle waarschijnlijkheid heeft u het ook wel eens gedaan: een generiek database ontwerp bedacht. Een klassiek voorbeeld van een generiek database ontwerp, is de consolidatie van codelijsten in één tabel. Dit voorbeeld zal u allen niet onbekend voorkomen. In elk database ontwerp komen we attribute tegen wiens waarden uit een van te voren vastgestelde lijst van waarden dienen te komen (een “codelijst”). In plaats van dat we voor elke codelijst één aparte tabel maken, met een zinvolle naam en met attributen code en omschrijving, consolideren we ze allemaal in één, zeg CODELIJST, tabel met attributen soort_code, code en omschrijving. Het voor de hand liggende voordeel van dit ontwerp is dat we slechts één onderhoudsfunctie (scherm) hoeven te ontwikkelen om alle codelijsten te kunnen beheren. Echter er kleven ook enkele nadelen aan dit ontwerp. Deze zitten met name in de hoek van constraints en queries. Om een voorbeeld te geven: stel er is een column KLEUR in tabel PRODUCT die naar de Kleur codelijst refereert. Deze data constraint is als volgt middels een assertion te specificeren.
PRODUCT en CODELIJST tabellenNatuurlijk zullen we voor de implementatie van deze assertion diverse triggers moeten maken op de PRODUCT en CODELIJST tabellen. Hadden we echter voor een normaal database ontwerp gekozen (eentje met een aparte KLEUR tabel) dan was dit eenvoudiger. Wat in het generieke ontwerp een complexe assertion was, is nu een eenvoudige declaratieve foreign key constraint geworden. Bovendien zijn we in staat om ook met dit normale ontwerp een generieke onderhoudsfunctie voor codelijsten te ontwikkelen. Hiervoor moeten we slechts een view (en enkele instead-of triggers) maken die de diverse specifieke codelijsten representeert als één generieke codelijst.  Instead-of insert/update/delete triggersEn als we de waarde van code_soort verwerken in de betreffende tabel naam, dan zijn de nog benodigde instead-of insert/update/delete triggers op deze view generiek opzetbaar. Een tweede typisch geval van generiek database ontwerpen is het fenomeen van dynamische attributen. In plaats van dat attributen bij in een tabel gedefinieerd worden, zijn ze uitgemodelleerd in een ATTRIBUTE_VALUE tabel. Zo kan deze tabel gebruikt worden om bijvoorbeeld enkele employee attributen dynamisch in op te slaan. Stel we gebruiken deze tabel om attributen salaris, hobby en job van een employee in op te slaan. Voor een overzicht op alle attributen van de employees is dan onderstaande view nodig. Ervaren SQL tunersDe ervaren SQL tuners onder u zullen direct een aantal issues zien die deze view tekst heeft. Een ATTRIBUTE_VALUE (achtige) tabel wordt vaak geïntroduceerd om wederom user interface generiek op te kunnen zetten. In combinatie met een ATTRIBUTE tabel met daarin de te registreren dynamische attributen per tabel, zijn we in staat om at runtime invulformulieren te genereren. Verzuimd wordt om in te zien dat in het normale alternatief, met alle attributen in de EMP tabel zelf, dit ook mogelijk is door gebruik te maken van de data dictionary van het RDBMS (user_tab_columns in dit geval). Tevens wordt vergeten dat bepaalde constraints in dit generieke ontwerp wederom bijzonder complex worden. Constraints zoals “managers verdienen meer dan 8000” die in een normaal ontwerp als CHECK-clause (eenvoudige tupel constraint) geïmplementeerd kunnen worden, zijn nu ineens complexe tabel constraints.Waar leg je de semantiek van de data vastWaar het om gaat bij generiek datamodelleren is, waar leg je de semantiek van de data vast? Doe je dat in het database ontwerp zelf, of in “erboven” liggende lagen (de business logic + user interface layers). Generieke database ontwerpen zijn inherent moeilijk om te begrijpen: je hebt de semantiek die hard-wired in de bovenliggende lagen zit nodig om de betekenis van de data te begrijpen. En vaak moet je naar de inhoud van tabellen kijken om ze te doorgronden. Deze ontwerpen geven additionele complexiteit op het gebied van data constraints en queries. Het werk van de optimizer zal moeilijker worden en queries zullen meer resources nodig hebben. Omdat bij een semantiek-loze onderlaag de bovenliggende lagen complexer zullen zijn, zullen deze ook complexer om aan te passen zijn. U moet bereid zijn al deze gevolgen te begrijpen en accepteren, alvorens u een generiek database ontwerp maakt. Trouwens, de laatste hype in datawarehouse/BI land (de “Data Vault” architecture) is wat mij betreft ook weer een prachtig voorbeeld van generiek datamodelleren. Ir. Toon Koppelaars Managing partner RuleGen BV | ||
| Lees meer over RuleGen | ||
| Ga terug naar We Love IT uitgave #4 - 2008 | ||
|
 |
|
