Tie Attributes

Anonymous

Background: I'm working on a course evaluation system, where users provide feedback about courses they've taken via evaluation forms. The forms and their questions are designed by the school staff and need to be mutable (add/modify/delete questions). Additionally, some questions are re-used on different forms. As a thought exercise, I'm trying to model this system's data using Anchor Modelling.

Problem: I have two anchors, Form and Question, with a tie between them. The tie itself, however, needs a number indicating the Question's position on the form (remember different Forms can have the same Question, but it might be the first question one one form and the last question on another). My intuition was to add the question number as a tie attribute, but I don't see any way of doing this in the modeller. Is it possible to add an attribute to a tie, or is there a better way of modelling what I'm trying to do? I considered making the relationship into an anchor, but that seemed a misuse of the technique.

Thank you

Roenbaeck

I would suggest that you make the tie knotted. Select "Add knot" from the context menu, or press 'k' when the tie is selected. You will then get what looks like an attribute directly on the tie.

On a side note, the two following two models can be used to store exactly the same information:

1. Tie(Form,Question) - Knot(Ordinal)

2. Tie(Form,Question) - Anchor(Tie Attributes) - Attribute(Ordinal) - Knot(Ordinal)

Anonymous

Thanks for the response. I finished reading the paper; let me run this by you to make sure my understanding is correct:

In my application, Questions can be deleted and re-added to Forms so I need to store an additional field "Deleted" with the (Question, Form) relationship. My intuition was to add another knot on the existing historized (Question, Form) tie, but the paper recommends against this since there is already a knot whose role is not part of the identifier. This makes sense, as you can't distinguish if the update was to "Deleted" or "Ordinal". Therefore I should create a separate historized, knotted tie for the "Deleted".

Roenbaeck

In mono-temporal Anchor Modeling (which is what is available now) you have three choices:

1. If the need to distinguish what was updated is rare, you could opt for having both knots on the same tie. You can still retrieve latest values, or values as they were at some point in time exactly as before. However, once you need to know what had changed, you will need to inspect previous rows and compare values. The tie will also not be in 6NF, and for these reasons we recommend against this solution, but it is not forbidden.

2. Make a separate historized knotted tie for "Deleted". This is a purer solution, but gives you extra maintenance, since you now have two ties with a dependency. If Questions can be assigned to Forms without having an Ordinal set, this is also a better solution. The idea is to give Deleted and Ordinal their own separate timelines over which they are historized.

3. Make a tie of three anchors, Question, Form, Assignment. On the Assignment anchor you can then put two knotted historized attributes, Ordinal and Deleted. There will be as many instances in the Assignment anchor as there are instances of the relationship between Question and Form. This way Ordinal and Deleted again have their own separated timelines. This solution has the advantage of being easily extendable if more attributes of the relationship are needed.

I would opt for solution 3, since it is the easiest to maintain.

In bi-temporal Anchor Modeling, when it is ready, deletes are handled transparently, and need not be modeled explicitly as part of the domain. However, I would still use mono-temporal Anchor Modeling if there are relatively few things that are deletable in my domain, since bi-temporality comes with a price both in performance and maintenance.