|
Tags: Database | Oracle
| ||
| ||
2008: Gaan we eindelijk weer data modelleren?Door Ir. Toon Koppelaars, Managing Partner RuleGen B.V.Stel u komt als developer terecht in een bestaande applicatie omgeving waar aan verbouwd moet worden. Wat doet u om deze, voor u nieuwe, omgeving snel te leren kennen? Waar begint u?Ikzelf daal, na eerst wat high-level informatie te hebben verkregen over wat de applicatie behelst, al vrij snel af naar ‘de bodem’. En met de bodem bedoel ik het onderliggend database design. Het fundament waarop de hele applicatie steunt. Welke tabel structuren zijn er, met welke columns? Wat zijn de toegestane waarden in iedere column? Wat is de betekenis van één row (de combinatie van column values) in zo’n tabel? Wat is het nivo van de gegevens in de tabel, ofwel, wat zijn de keys? Ik ga ook op zoek naar ‘natural’ keys als de enige beschikbare key een system-generated nummer is. Doorgaans is zo’n tweede key te benoemen, echter vaak niet geïmplementeerd. Als er veel ‘nullable’ columns zijn [sic] probeer ik te achterhalen wanneer en waarom die columns wel of niet gevuld zijn? Feitelijk ben ik dan op zoek naar tuple constraints die dit beschrijven. Tuple constraints die als SQL check-clauses op de tabel gedeclareerd (hadden) kunnen worden. Vanzelfsprekend kunnen er ook tuplenivo verbanden tussen verschillende verplichte columns zijn. Zo ja, zijn dan ook deze geïmplementeerd als check-clauses? Een volgende stap is om de primaire verbanden tussen de tabel structuren in kaart te brengen. Ik praat dan natuurlijk over de foreign keys tussen de tabellen. Check clauses, keys, en foreign keys, zijn essentiele constraints die de semantiek van het database design beschrijven. Er zijn echter doorgaans vele overige data integriteit constraints die nader beschrijven hoe het database design een afspiegeling vormt van de ‘real world’, en daarmee de semantiek van het design verder completeren. Bijvoorbeeld, in een tabel met datum periodes mogen deze elkaar, op een bepaald nivo, niet overlappen. Of, de som van de bedragen over de orderregels mag niet meer dan 1000 zijn binnen één order geplaatst door een bepaald type klant. Etc. Deze overige constraints worden vaak business rules genoemd, maar zijn bekeken vanuit de theorie van relationele databases conceptueel niet anders dan de eerder genoemde checks, keys en foreign keys. Het notoire verschil is dat je voor deze rules zelf code moet schrijven: i.e. je kunt ze niet declaratief in het DBMS opvoeren zoals je dat met eerder genoemden wel kan. In de ideale omgeving kan je de semantiek van het database ontwerp, dus inclusief alle constraints (rules), in de documentatie vinden en bestuderen. En kost je dit een dag of zo, afhankelijk van de grootte van de omgeving natuurlijk. De praktijk leert echter dat je vaak achter de sqlplus prompt moet kruipen, de nodige informatie uit de data dictionary moet bevragen, adhoc queries op de aanwezige data moet uitvoeren, en/of veel moet overleggen met mensen die weten hoe het een en ander is uitgemodelleerd in het database design. Hopelijk zijn deze mensen nog aanwezig, want het andere alternatief is om in de code van de applicatie te gaan duiken, en middels reverse-engineering de nodige kennis boven water te halen. Het moge duidelijk zijn dat we nu niet meer over dagen, maar eerder over weken zo niet maanden praten. Deze ‘bodem’ kennis is onontbeerlijk om de vertaling van bijvoorbeeld een wijzigingsverzoek, komend vanuit de real world en beschreven in termen van die real world, correct te vertalen naar een aanpassing van bepaalde -op het database design- transactie en/of query uitvoerende business logic modules. Of misschien wel naar een aanpassing in dat database design zelf. Het vakgebied “databases ontwerpen” is het afgelopen decennium steeds meer naar de achtergrond verschoven. De trend om alles vanuit de middle tier te ontwerpen (vaak object georiënteerd) en te bouwen, is mijns inziens een niet onbelangrijke oorzaak hiervan. Zelfs de HIO’s en universitaire informatica opleidingen zijn met deze trend meegegaan. De theorie van relationele databases (en dus ook het ontwerpen ervan) is in veel curricula niet of nauwelijks meer aanwezig. Ik heb dit zelf de afgelopen maanden ondervonden in pogingen om een bepaald boek bij deze opleidingen onder de aandacht te brengen. Het is mijn overtuiging dat goed data modelleren, veel ellende -met name op het gebied van performance en onderhoudbaarheid- in de ICT branche kan voorkomen. Een goed uitgemodelleerd relationeel database design is het fundament van elk informatiesysteem. Laten we met z’n allen weer een beetje van de middle tier terugkeren naar de database tier. 2008: een nieuw jaar, met nieuwe data modellering kansen. Laat ze niet aan u voorbij gaan. | ||
| Lees meer over RuleGen | ||
| Ga terug naar We Love IT uitgave #1 - 2008 | ||
|
 |
|
