Datamodel voor mutatiebeheer

[DaCoTa]

Momenteel ben ik al even (paar dagen dus) aan het hoofdbreken over een datamodel voor mutatiebeheer. Wat bedoel ik met mutatiebeheer:

Er is een boom structuur van 6 parent-child (1:n) relaties. Via een applicaties zijn er twee soorten mutaties in te voeren: een is een mutatie op velden in een object. twee is een mutatie op een parent-child relatie (child aan andere parent koppelen). Normaal is dit geen probleem, maar de moeilijkheid waar ik tegenaanloop is het feit dat er over deze mutaties versiebeheer moet lopen. Een mutatie moet ingevoerd worden en kan (door een andere gebruiker) goedgekeurd danwel afgekeurd worden.

Al dit soort mutaties worden aan een releasemoment gekoppeld en op het moment van release worden alle goedgekeurde mutaties doorgevoerd om de nieuwe, bijgewerkte boomstructuur te exporteren naar externe systemen.

De mogelijkheden voor objectmutatie bestaan uit: een of meerdere velden moeten gewijzigd kunnen worden. Een object moet verwijderd kunnen worden (mits er geen children aanhangen), object moet ingevoerd kunnen worden.

De mogelijkheden voor relatiemutatie bestaan uit: relatie loskoppelen van parent, relatie verleggen naar andere parent.

Al deze bewerkingen moeten dus via een te accepteren of af te wijzen mutatie doorgevoerd worden.

Ik krijg het niet voor elkaar om een goed datamodel te verzinnen dat alle eisen omvat. De pogingen lopen uiteen van minder dan 10 tot bijna 30 entiteiten, maar bij alle varianten loop ik tegen problemen aan.

Datamodel poging 1:


parent, child: beginsituatie van entiteiten
parent_mutation, child_mutation: wijziging op velden van entiteiten

parent_child: geeft 1:n relatie aan. parent_id NULL is geen gekoppelde parent, mutation_id NULL is beginsituatie relatie. Bij mutatie_id != NULL is het een gewijzigde relatie

mutation: mutatieaanvraag gekoppeld aan release entiteit, kan goedgekeurd of afgekeurd worden
release: releasemoment entiteit.

Nadeel: Vrij complex, gezien er 5 van deze structuren in het uiteindelijke datamodel moeten. Veel controlelogica nodig om systeem consistent te houden.

Datamodel poging 2:

parent, child: begin en mutatiestand van entiteiten. Zelfreferentie is NULL bij origineel, verwijzing van mutatie naar origineel. Aangezien er twee typen mutaties zijn (veldmutaties en relatiemutatie), moeten deze uit elkaar gehouden worden door een vlag. Bij veldmutaties is de parent_id leeg, bij relatiemutaties zijn de velden leeg;

mutation: idem bij model 1
release: idem bij model 1

Voordeel: eenvoudig datamodel
Nadeel: redelijk wat niet gebruikte velden. Ook compexe logica nodig om systeem te controlleren.

edit:
Ik was nog niet klaar, drukte op verkeerde knopje...

Vraagstelling:
Ik hoop dat mijn probleem duidelijk is, maar ik heb ergens een gevoel dat ik in een verkeerde hoek loop te zoeken. Hebben andere mensen wellicht inzichten in deze problematiek?

[ Voor 7% gewijzigd door DaCoTa op 17-02-2005 13:04 ]

[Verwijderd]

Ik ben niet zo'n liefhebber van referenties naar records binnen dezelfde tabel, maar dat is meer een gevoelskwestie. Zelf zou ik de mutaties en het versiebeheer in een changes log bijhouden, en niet in de hoofdtabellen records gaan klonen wanneer er iets gewijzigd wordt.
Zoiets:

code:

id                     PK, auto-increment
table_name             parent table, child table, etc.
                       kan weg als een log per tabel wordt bijgehouden
record_id              PK van het gewijzigde record
date_modified          timestamp
user_modified
field_modified         als dat parent_id is, is 't een relatie-mutatie,
                       anders een object-mutatie
old_value
new_value
status                 pending / approved / rejected
date_audited           wanneer is de status van pending (default) naar
                       approved of rejected gegaan?
user_audited
release_id

[Verwijderd]

Wat ik zat te denken:

Je hebt:
- 1/n mutatie(s)
- 0/n koppeling(en)

object mutatie
- mutatieid
- date
- release_id

object koppeling
- koppelingid
- parent_mutatieid
- child_mutatieid

Is dat n idee?

[ Voor 8% gewijzigd door Verwijderd op 18-02-2005 11:28 ]

[Verwijderd]

Ik doe eventjes simpel, en ga zaken uit elkaar trekken in losse blokken.

Je hebt dus relaties, en op een relatie zit versiebeheer zodat je evt een rollback kunt doen van die relatie.

Kortom een tabel relations waarbij elk record een relation is.
columns: relationid, parentid, childid

Een tabel relationversions waarbij elk record een versie is van een relatie in de relations table
columns: versionid, relationid, datetimestamp, status

In de relations table houden we voor snelle lookup een lastversion bij van de relationversions. In de table relationversions hebben we een dattimestamp, en een status van de versie (draft, finished, etc.)

Dan hebben we versiebeheer op many to many relation mutaties geregeld.


Nu over naar de objecten

Een tabel object (daar slaan we het type object op):
columns: objectid, objectname

Een table properties (daar slaan we de properties/attributes van een object op):
columns: propertyid, objectid, propertyname

Een table instances (daar slaan we instanties op van een object)
columns: instanceid, label, objectid

Een table data (daar slaan we de content op als versie)
columns: dataid, instanceid, datetimestamp, propertyid, value

Dan hebben we ook versiebeheer op objecten geregeld. Je kunt voor performance redenen nog besluiten om de dataid van de laatst beschikbare versie, en de actieve versie in de instance table op te nemen. Maar dat kun je later nog bekijken als je het een en ander werkende hebt.

Dat zou het moeten zijn

[ Voor 9% gewijzigd door Verwijderd op 18-02-2005 11:29 ]