Temporal modeling is a hot topic in data warehouse and BI environments. The data vault approach or anchor modeling are an attempt to make those environments more manageable. From the information modeling perspective however, these are mostly technical in nature. Though the information model could capture those technical requirements, it would be an information model with an implementation in mind, and not simply capture the business communication. We would be modeling the data warehouse implementation itself and not the way the business communicates about their data.

This is a follow up to the initial article to be found here.

Concrete example

In the initial article a philosocial issue was explained about moods and relationships of people. Though it explained some of the theoretical approach, it doesn't explain easy in real IT worlds. Therefor this article is created to also show how CaseTalk Modeler moved from annotations to actually supporting these aspects. Therefor we modeled a small domain regarding Customer, Order, Articles from a webshop.

We will express a few facts to illustrate the relevant topics.

transitional

The essence of data is that once it is viewed from different perspectives the actual data may be different. In this case we may merge the customer names from our backoffice sales applications into the customer database in the webshop. Even though the customer numbers are the same, the actual writing of the customer full name may differ. To allow this Full Name to conflict, we should build a provision. If communicated it may sound like:

"Customer 1 in our Backoffice is called John Doe."

"Customer 1 in our Website is called Johnny Doe."

This may not actually be part of the communication of our domain experts. We introduce it with the knowledge of the proces of merging data from different databases. This typically happens in Data Warehouse solutions and data migration projects. For the domain experts there's only one customer and one full name. Therefor we do not wish to convolute the communication. We simply need to make an annotation to our Customer Name that it is Transitional. Meaning it may behold conflicting data from different sources. That way the fact expressions can simply done in a single realm and one example:

"Customer 1 is called John Doe."

Historical data

Historical data is preserved to be able to allow reporting and analysis on data that used to be. Expressing this in natural language using fact expressions may very quickly become very complicated. So calling an article Freezer and then changing the name for it in the future starts and ends with a set of fact expressions. And as you can imagine in more complex expressions, nesting these intervals and interval variations will become very hard to formulate and validate.

"Article 999, starting at 1-1-2020, is named: Freezer."

"Article 999, starting at 1-1-2020 and ending on 31-12-2020, is named: Freezer."

"Article 999, starting at 1-1-2021, is named: Fridge."

For that reason, we simply choose an annotation in CaseTalk to provide support for history to be recorded in the generated artifacts and not convolute the information model. This way the expressions remain in a single point of time:

"Article 999 is named: Freezer."

This reasoning holds both true for the bookkeeping of historical data, as future data. Take for instance the article price, which may be temporarily lowered during the holidays. This would again complicate the fact expressions which now must include future time intervals to say anything about a price of an article. As before CaseTalk provides a simple annotation called: Valid Time.

Full time travel

Combining Transactional Time (history) and Valid Time (future) we may provide full time travel capabilities to the artifacts we wish to build. All this without complicated expressions, and without having to confront business users with complex models. CaseTalk annotates these requirements with a simple flag and visualized in diagrams with icons.

Localization

More and more companies are working international, and the data models need extensions to be multi-lingual, as our webshop. The article names are candidate for such muli-lingual features. Yet, to keep things simple and understandable and not overly complicate verbalizations, we add an annotation to the label types indicating that any value using this label type, must provide localization capabilities in the artifact. Compare the following two expressions:

"Article 999 is called: Freezer."

"Article 999 in language en-EN is called: Freezer."

Conclusion

Seemingly complicated issues, such as temporal, bitemporal and conflicting facts, stir up many long implementation discussions. Adding localizations may be a housekeeping issue in artifacts again. But addressing these business requirements, can be as easy as annotating your information model elements and let CaseTalk do the heavy lifting.

For some facts the time aspects are so ingrained in the business and our way of working, they remain verbalized. Take for instace the Order Date, for being so integral part of the communication, these should not be done differently. Annotating Temporal issues are in most cases part of the technical realm, with a business need. This is not the case for some such as our Order Date.

"Order 12 is made in 1-1-2021."

As usual modelers still need to think about the business domain. CaseTalk Annotations allow that thinking to go one step further.

Below you'll find an image illustrating the simple annotations in a CaseTalk Diagram: