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:
- Is it correct?
- What business rules does it represent?
- What business rules does it enforce?
- Where did the element "Line Number" come from?
- Who invented it?
- What is it used for?
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:
- Where are they?
- What are they?
- Where do they come from?
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.