You are here: Visual LANSA Logical Modeler > 1. Introduction to Data Modeling > 1.2 Conceptual versus Implementation Modeling > 1.2.5 Thinking about Dates

1.2.5 Thinking about Dates

In C-Think mode, you would define a date using three separate entities: Year, Month and Day. Year in the parent of Month. Month is the parent of Day. Hence the Day is identified by parent keys from Year, Month and its own identifying attribute for Day (YY MM DD).

Now several relationships may exist between an entity called Order and the entity called a Day. For instance, an Order has a "Date Order Placed" and "Delivery Date". However, what often happens is that the I-Think part of the Architect's brain takes over and consequently:

The idea of the model is that it conceptually represents what information is being used within the model. If a user chooses not to have database files representing the entities Year, Month and Day, the decision should be made at the time the logical model is being implemented as a database (I-Think time). Making the decision in advance (during the modeling) may lead to problems.

Consider the 3 entity C-Think form of the model. What will happen once a Century entity is defined? Century is the parent of Year. Now the Day entity is identified by CC YY MM DD attributes. The change will ripple through the whole model and Date Order Placed and Delivery Date will use the CCYYMMDD form, but not if they were added directly as elements to the Order entity.

This is one of the most powerful features of data modeling - to make a major change to the structure of the model and have the effects automatically "cascaded" or "rippled" through all other affected relationships.

So, an I-Thinker will critically examine the entity Order and find that it includes the following attributes:

This may horrify the I-Thinker, who will think:

What the Architect should think (using C-Think) is that:

When they come to the implementation phase, they will probably find that other facilities exist to very easily and consistently map the dates into one virtual field for processing on screens and reports. In the long term, they will probably find that the choice to implement the 8 separate fields in the resulting database pays off.