attribute control

dries

Hi,

I'm impressed with the online tool and the solid scientific basis.

Excellent work! And thanks for sharing this selflessly with the rest of the world.

Regarding "recording time" which i read in "Three concepts of time in Anchor models", which is a feature i would like to use and maybe even expand on as in accessroles/workflows for attributes based on value change:

could you provide any example or point in a direction to do this (with the online tool)? That is implement recording time with a reference to the entity that made the change.

I might be missing the obvious but it would be nice to hear an expert.

Thanks!

Roenbaeck

In current (mono-temporal) Anchor Modeling we push the "recording time" down to metadata. The tool will not generate a metadata model for you, it will have to be modeled as well. Ideally, your metadata model is also an anchor model. The connection between your data model and your metadata model is through the metadata identifier found on every row in every table.

For example, say you have a source system 'A' that on the 20th of August 2001 delivered the information: "The price of product 42 is 10 euro in effect through all of 2001, and after that 12 euro". Your data would be <#42, 10, [2001-01-01, 2001-12-31]>, <#42, 10, [2002-01-01, ~]> and your metadata is <'A', 2001-08-20> before storing it in an anchor model. Now, when inserted into the data model and metadata model, you get:

Price attribute

(PR_ID*, PR_PRI_Product_Price, PR_PRI_ChangedAt*, PR_PRI_Metadata)

<#42, 10, 2001-01-01, #555>

<#42, 12, 2002-01-01, #555>

Metadata anchor

(MD_ID*)

<#555>

Source system attribute

(MD_ID*, MD_SRC_Metadata_SourceSystem)

<#555, 'A'>

Recording time attribute

(MD_ID*, MD_REC_Metadata_RecordingTime)

<#555, 2001-08-20>

The connection between the models is on PR_PRI_Metadata = MD_ID. Primary keys indicated by *.

I hope that clarifies how we use recording time in mono-temporal AM. Note that I am working on a bi-temporal extension, in which recording time if lifted from the metadata model to the data model. I expect it to be ready by the end of the year.

dries

Hi,

Thanks for your response.

I'm still a bit confused regarding two things:

1)I was under the impression the metadata int column in the attribute table is used as some kind of version column?

2)If there is to be a foreign key to an anchor (the metadata model) do we have to add it to the attribute table by hand in the generated sql?

Roenbaeck

1) The metadata column is just for storing metadata about the row. It cannot be used for versioning since it is not part of the key. The historization column(s) is what is used for versioning. In mono-temporal AM, which the tools currently generates, there is only one such column, meaning you can only historize over changes, and not errors.

2) Since we cannot know what your metadata model looks like (including table names) we are unable to automatically declare a foreign key between the metadata model and the data model. Perhaps we should add this an option in the tool, so that you can enter the name of your base metadata table (preferably an anchor) and it will generate the FK? Note that it would have to be in place before the data model is created though.

dries

Haha i feel a bit silly. After reading your response everything fell immediately into place.

Mentioning versioning for the reasons you stated is even more embarrassing.

Anyway it all makes sense now. Thanks.

The option of setting an anchor as metadata would be a nice feature to have since i think i would be using it as soon as it would be available;)