Dates
When you consider implementing the conceptual model for a date as four different entities (Century, Year, Month, Day), your implementation thinking will likely consider concatenating this information into a single date element. In many circumstances, a single date field is sufficient as the conceptual structure of the date is not required.
In I-Think mode, you should consider the "performance budget" of your organization. You must also consider the integrity of the conceptual model. Try to ensure that physical implementation changes do not affect the fundamental integrity of the conceptual model.
You may find that as you make I-Think changes, the C-Think part of your brain actually starts making comments such as:
If this starts to happen, you have become a real dual role C-Thinker and are on the way to evolving into a New World C-Thinker.
Some classical I-Think implementation changes include:
These types of changes can be made for performance reasons or implementation reasons based on the software language used.
Tables
Some additional I-Think implementation changes might include:
Consider the sales history of a company. Historical information is based on the product sold and the period in which it is sold. Rather than implement the database with 12 records for each month's product sales in one year, an array structure can be substituted. Now a product has one record for each year with 12 sales months in each record.
In a model you may also have a very large number of entities which are basically used as "constants" or tables for validating data. Data such as city, state, country, company, or warehouse might be grouped together as a single table when implementing the database.
These types of changes should be based on a sound understanding of the current and future needs of the business and not solely on technical implementation.
I-Thinking for Existing Models
When working with an existing application database which does not have a logical model, you may choose to use an I-Think approach to create a model which represents the physical database. This approach is used assuming that you are not going to change the database structure of the existing application, but you want to build from it.
Modeling the physical database will quickly provide a definition of the entities and attributes you will need for creating your new model. Because you will not be altering the existing database, there is little benefit to develop a conceptual model which does not reflect the already implemented database. Your C-Think focus will be on the new entities, attributes, and relationships for the new applications you are designing.
