I just recently stumbled upon the anchor model and are still in the process of reading up on it, so bear with me if this question is answered somewhere else.
Is it possible to branch a version of the full data set and work on it in isolation to the previously existing 'main branch'? This feature would be particularly helpful if one was to try some new dataset and test the consequences in a separate scenario without affecting other users who work on the 'main scenario'. Based on that, would it then be possible to create multiple of these branch points at any point in time, and from any branch? This functionality is also reminiscent in revision control systems, if that helps to explain it a bit more...
Any idea whether this can be achieved by the anchor model?
I am familiar with branching in versioning control systems, and this is not something that has been integrated in the tool. While I would love to see collaborative editing features and integrated version control, they're pretty far down in the priority list due to the sheer effort it would take to implement them.
That being said, I believe what you want still can be achieved by using a version control system in conjunction with the tool. Whenever you find suitable, you can select Generate -> XML from the menu, check in the generated XML code, and create a branch in your VCS. At any later point, this XML can be checked out and loaded back into the tool.
A bit of manual labor, but essentially you get what you want.
What I actually meant was not concurrent editing of the model, but concurrent changes of the records itself.
The way I understand it - and I might be wrong - is that the anchor model keeps track of temporal changes to data (and with data I mean the actual data in the database). With my questions, I was suggesting an additional dimension which would keep data changes separate by branches. Such a behaviour could be very useful for running scenarios on the dataset. It would also generalise the model to not only record temporal changes, but any kind of dimension of changes (time and version number is the only one I can think of though).
Does this make sense and is anything like this planned in future?
Aha, now I understand, and yes, this is planned to be implemented sometime after bitemporal support is finished. We're roughly looking at the autumn of 2012 for the addition of this feature.
It's called timeline annexing in Anchor Modeling and what it translates to in the implementation is an extension of the primary key in order to keep track of the annexes (your branches). Each annex can be seen as a timeline owner, through whose perspective data can be viewed. Data within an annex must be consistent, but two different annexes may contradict each other. Other words for this type of modeling are "multi-bitemporal" and "concurrent-temporal".
The need for this type of modeling also arise in data warehousing, when the information sources deliver bitemporal information. Then it is quite possible that two different sources disagree on some piece of information, but both views need to be stored.
Hi Max, It is still on our TODO-list, so it is planned but not yet implemented. None of our currently planned activities are sponsored, which means there are ways to move such functionality to the top of the queue ;)
I assume with the concurrent-reliance-temporal AM, it should be possible to implement a sort of versioning model. The positor is the 'branch' and de reliance is for tracking deletes?
If so we can store the AM in a repostory, that is in fact a crt-AM :-)
At a client I am maintaining a metadata repository where they have the need for branching. They have several teams working on the same models in the repository.
They use Oracle as repository database. Would be a nice case :-)