The Analysis phase -
The starting point of effective Database Design

The business (conceptual) model

This is the phase we enter after strategic requirements are in place: The scope of the system, key technical requirements, and the tools for each stage of development, etc. is decided. Economics are most likely also determined.

We may also (most likely) have a rudimentary (conceptual) information model, and we know about key functionality that is required.

The main purpose of the analysis phase is to bring all these pieces together to form a conceptual database model containing all entities with their attributes, domains and relationships, together with a complete function model with its hierarchy, as well as domain constraints (on attributes), business rules (constraints), and events that trigger functions.

The output of the analysis stage is a complete conceptual database model that will be carried over to the design phase of the development project, as a draft for a logical database model.

The one most important thing to remember in the analysis phase is: Our scope is to determine WHAT should be made, not HOW.

In many projects, I have overheard participants starting to talk about how a given function should behave: Colors, buttons, defaults etc. However, all of that belong to the design phase. You have to set your foot down on this, however excited the project participants are (and they will be, provided that you are running a constructive analysis phase):

The analysis phase is about the BUSINESS, not the SYSTEM. The system shall reflect the business, not the other way around, as sometimes unfortunately happens.

Actually, the analysis phase is an excellent time (and the right time) to learn the business in-depth. I do not insist that you know the business in detail. The business itself knows its business. Therefore, your chances of failure are high without business participation.

On the other hand, I have witnessed failure in projects where the business wanted to control the whole process alone, and just use 'hired hands' to execute their demands. A balance has to be established.

As with many other things in life, neither to little nor too much of a thing is a good thing.

'Good judgement is based on experience. Experience is based on bad judgements'.

The keynotes in this section are taken from my free eBook which you may download here: Entity Relationship Modeling - Principles'.

The following articles may contain examples from Entity Relationship Diagrams, and I will occasionally refer to violations of different Normal Forms.

For a detailed explanation of 1NF to 5NF, I refer to my eBook on Database Normalization.

• This keynote addresses the vital cooperation between the business and the analyst: The most vital component in the Analysis Phase team.
• Three elements vital to analysis progress: Not the whole project team; just some key elements.
• There are two factors that more than others can make your project fail: The first of them I have called Analysis Trap 1
• The second critical failure factor is Analysis Trap 2
• Do we look for a generic model, or do we do it on our own? Generic or Specific
• A few words about ethics here - you win in the long run... Analyst Ethics

Return from Analysis Phase to Database Design home