You are here: Visual LANSA Logical Modeler > 1. Introduction to Data Modeling > 1.2 Conceptual versus Implementation Modeling > 1.2.6 C-Think Considerations

1.2.6 C-Think Considerations

The Classic Order Model

By using C-Think, you can often look at the way things are done (or have always been done) in a completely new way. Sometimes this method confirms the correctness of your existing approach.

For example, consider a classical order entry model.  An Order entity is the parent of an Order Line entity where the Order Line entity is identified by a parent Order Number and Order Line Number attributes. This implementation can probably be made to work. However, ask yourself:

Using C-Think, we may produce a different model for the order model. Perhaps the Order and Product entities are the parents of Ordered Product. An Order Line is not really required. In this type of model, the  Ordered Product entity does not have an identifier of its own as it can be identified by its two parent keys, Order Number and Product Number. There is no need for an Order Line Number.

Product Code Example

In many databases, you will encounter an attribute called a "Product Number". This attribute is often the identifying attribute of the an entity called Product. However, at some time later, you hear mention of Product Groups and Product Classes that are part of this Product Number identifying attribute. Ask yourself:

You may soon discovered that these groups and classes are actually the embedded digits within the Product Number. (Consider how telephone numbers are really combinations of different groups of digits that have different meanings.)

A C-Thinker would never leave Product entity identified by such a Product Number. The Product Group and Product Class become entities with relationships to the Product entity so that the identifying attribute to Product has the proper parent keys.