1 2 5 Thinking about Dates

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 elements "Date Order Placed" and "Delivery Date" are placed directly into the entity Order.

The user understands what a date is in elemental form, but decides that they do not want to have three database files defined to represent the entities Year, Month and Day.

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:

Century Order Placed Delivery Century

Year Order Placed Delivery Year

Month Order PlacedDelivery Month

Day Order PlacedDelivery Day

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

There's going to be 8 separate fields here. I don't want all those extra fields in the database.

Those 8 fields are going to increase the effort in my order processing programs. I'll be forever sub-stringing them together and apart again so that they come up as one field on screen panels and reports.

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

This is a good model. It represents how the data is structured and the rules for the data.

As an I-Thinker, I'm not too crazy about all these data fields, but I'll cross that bridge when I come to it.

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.