Normaliseren.. Of niet?

We zijn gewend informatie te normaliseren, maar doen we dit niet te vaak, te diep?
Zijn er sowieso criteria's te stellen wanneer genormaliseerd moet worden?

Dit is een typisch voorbeeld van een applicatie waarbij de informatie van een bedrijfsobject Order over meerdere tabellen in de database is verspreid. Alleen het hoogste niveau van normalisatie is te zien, er zijn nog meer tabellen achter deze tabellen. Tezamen maken ze het object Order pas compleet.

Functioneel gezien zijn Orders hiërarchische objecten die zich lastig laat vangen in tabellen en relaties. Mensen en programma's werken bij voorkeur met complete objecten en moeten door het verschil in opslagstructuur continu vertaalslagen maken. Dus ondanks de voordelen die een relationele database heeft op het gebied van integriteit (zal ik in een later bericht iets over zeggen), transacties, bevraging, etcetera, hebben we er soms last van dat alle data in een relationele database is opgeslagen.

Bij het bouwen van ieder nieuw informatiesysteem wordt tegenwoordig de eis gesteld dat het product 'database onafhankelijk' moet zijn. Eigenlijk is dat vreemd. In dat geval bepaalt de kleinst-gemene-deler de uitgangspunten (ACID,  SQL-standaard, etc). Dit legt de oplossing meteen beperkingen op, terwijl veel databasesystemen juist eigen extra's aanbieden. Zolang deze niet gericht zijn op een vendor lock-in zou je daar gebruik van willen maken. In een exit-strategie wordt vooraf onderzocht wat het betekent om van de extra's afscheid te nemen, zodat er een onderbouwde keuze gemaakt kan worden in welke mate onderliggende systemen benut mag worden.

DEMO

In een eerder bericht 'Object hiërarchie in een database' is al een slag gemaakt naar het aanbrengen van object hiërarchie door middel van overerving van tabellen, een PostgreSQL extraatje. Oracle kent objectrelaties waar dit waarschijnlijk ook mee kan, maar koppelt dit al snel aan applicatieontwikkeling.

Dit bericht gaat echter het over een ander aspect, het vermijden van foreign-key relaties als gevolg van normalisatie.

Voor demo is gekozen om bedrijfsobjecten zo min mogelijk te normaliseren naar tabellen, met deze kanttekeningen:

• Objecttabellen bevatten nooit eigenschappen van andere objecten, er is géén overlap. Dit is een vorm van normalisatie, die echter niet in tabellen wordt doorgevoerd.
• Er kunnen technische redenen zijn om in bepaalde gevallen toch foreign-keys te gebruiken.

Een aantal overdenkingen bij de kanttekeningen:

• Relaties tussen (bedrijfs)objecten worden altijd on-the-fly afgeleid met gebruik van UUID ofwel guid objectidentificaties.
• De afleiding vind plaats in (updatable) views, of zelfs buiten de database, in applicaties.
• De eigenschappen (tabelkolommen) van objecten die gebonden zijn aan keuzelijsten bevatten geen (foreign-key) verwijzing naar een andere tabel, maar bevatten letterlijk de waarde van de keuze. Dit kost iets meer initiele databaseinrichting en opslagcapaciteit, maar alle data van een object is als één onlosmakelijk geheel zonder meer beschikbaar.
• Foreign-key relaties in relationele databases lopen traditioneel van parent naar child, al dan niet via tussentabellen. In DEMO worden relaties tussen objecten juist on-the-fly afgeleid van child naar parent. Dus geen optionele relatie tussen de objecten oppervlaktewaterlichaam en vaarweg (want een oppervlaktewaterlichaam moet geen informatie over vaarwegen bevatten, dat is een ander informatiedomein), maar juist een verplichte verwijzing (door het opnemen van UUIDs) van een vaarweg naar oppervlaktewaterlichamen.

Het is nog niet volledig in beeld wat de consequenties van deze aanpak zijn, maar het ziet er tot nu toe erg bruikbaar en zinvol uit.