Theoretische vraag over datamodel: data afsplitsen of niet?

[Verwijderd]

Hoi,

Ondanks de grote lap tekst is, is de vraag erg eenvoudig. Ik hoop dat jullie zin hebben om het even door te nemen.

Stel je voor dat je een applicatie aan het maken bent voor een helpdesk. De database moet onder andere klanten, incidenten en 'contactmomenten' opslaan. Een klant kan meerdere incidenten hebben (1 op veel relatie). Een incident bestaat uit 1 of meer contactmomenten (1 op veel relatie). Mijn vraag gaat over de contactmomententabel en meer specifiek het communicatietype-veld.

contactmomenten

contactmoment_id (PK)
incident_id (FK) (koppeling aan incident)
datum
tijd
omschrijving (omschrijving van het contactmoment)
richting (inkomend of uitgaand)
communicatietype ('email', 'brief', 'fax', 'telefoon', etc)

Het communicatietype-veld geeft aan hoe er gecommuniceerd is. Dat kan bijvoorbeeld zijn via e-mail, per brief, per fax, per telefoon of in een live gesprek.

Het 'probleem' waar ik mee zit is dat ik in de applicatie alle mogelijke communicatietypes in een HTML dropdownmenu wil tonen aan de gebruiker. De gebruiker (helpdesker) kan een incident registeren en daarbij uit het dropdownlijstje selecteren hoe er gecommuniceerd is. Punt is dat ik met bovenstaande tabel nooit met zekerheid alle communicatietypes kan selecteren. Immers, alle communicatietypes moeten al in de tabel zitten voordat ik ze kan selecteren! Heb ik een compleet lege database, dan heb ik dus geen communicatietypes in mijn dropdownmenuutje.

De oplossing ligt voor de hand: het afsplitsen van communicatietypes. Ik zou dan zoiets maken.

contactmomenten

contactmoment_id (PK)
incident_id (FK)
datum
tijd
omschrijving
richting (inkomend of uitgaand)
communicatietype (FK)

communicatietypes
com_type_id (PK) (refereert aan communicatietype-veld)
omschrijving (e-mail, fax, telefoon, etc, etc)

Nu kan ik vanuit mijn applicatie een query sturen die alle records in de communicatietypestabel pakt en daar kan ik mijn dropdownmenu mee vullen. Ik kan de mogelijke communicatietypes dus van te voren invoeren.

Nu de hamvraag: hoe omschrijf je deze handeling volgens de databasetheorie? In feite splits ik nu een 1 op 1 relatie af, toch? Elk record uit de contactmomententabel is gekoppeld aan 1 record in de communicatietypestabel. En is dat wel de bedoeling als je je database strikt volgens de regels normaliseert? Ik vraag dit omdat ik dit modelletje gebruik als voorbeeld in een uitleg aan medestudenten...

[Verwijderd]

Hmmmm. De relatie tussen communicatietypes en contactmomenten is volgens mij ook een 1 op veel relatie. Elke rij in de communicatietypestabel correspondeert met 0, 1 of meer rijen in de contactmomententabel....

Het zou niet de eerste keer zijn dat ik 2 minuten na het uitgebreid opschrijven van het probleem het antwoord zelf zie

[djluc]

Haha, je hebt gelijk. Gewoon in een aparte tabel plaatsen. Sowieso handig omdat je dan simpel bijvoorbeeld kosten aan de communicatiemethoden kunt hangen.

[RobIII]

djluc schreef op vrijdag 02 februari 2007 @ 14:17:
Sowieso handig omdat je dan simpel bijvoorbeeld kosten aan de communicatiemethoden kunt hangen.

Totdat je kosten halverwege het jaar wijzigen en je dus of alle oude kosten wijzigt (en dus de historische data niet meer klopt) of een extra communicatietype moet aanmaken (telefoon en 'telefoon nieuw' ) met andere kosten

Natuurlijk heb je gelijk, ik zeg dit enkel om maar aan te geven dat een afgesplitste tabel niet altijd voordelen heeft; kosten zou ik in dit geval weer bij de communicatie zélf zetten, met een waarde die komt uit communicatietype

[djluc]

Je kan ook een versie-tabel ontwerp gebruiken, dan heb je van de geschetste problemen totaal geen last...

Tevens kan je dan mooi de prijswijzigingen er uit halen zonder enige problemen.

[Verwijderd]

Hehe, bedankt allemaal. Ik merk dat ik weer een redelijk d'oh gehalte heb weten te bereiken met mijn vraag. Ik kan in elk geval weer verder Kosten laat ik even buiten beschouwing overigens. Het moet een eenvoudig voorbeeld blijven.

[CubicQ]

RobIII schreef op vrijdag 02 februari 2007 @ 14:22:
[...]

Totdat je kosten halverwege het jaar wijzigen en je dus of alle oude kosten wijzigt (en dus de historische data niet meer klopt) of een extra communicatietype moet aanmaken (telefoon en 'telefoon nieuw' ) met andere kosten

Natuurlijk heb je gelijk, ik zeg dit enkel om maar aan te geven dat een afgesplitste tabel niet altijd voordelen heeft; kosten zou ik in dit geval weer bij de communicatie zélf zetten, met een waarde die komt uit communicatietype

Ik niet. De kosten horen bij een communicatietype, niet bij de communicatie zelf. En wanneer de kosten in de tijd kunnen verschillen dan maak je van de kosten tijdsafhankelijk door ze in een tijdsafhankelijke attributieve tabel van communicatietype te zetten.

Dan heb je je gegevens genormaliseerd, en kloppen je historische gegevens gewoon.