The Database Design Resource Center



Analysis team | Analysis progress | Trap 1 | Trap 2 | Generic or specific | Analyst ethics


The Analysis phase -
The starting point of effective Database Design

The business (conceptual) model


The analysis phase of your database design deals with the early stage of a business system lifecycle.

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

Entity Relationship ModelingAfter this analysis phase discussion, at the end we WILL have some fun with Entity Relationship modeling - Just click on The Universe!

Return to Database Design home


Exclusive interviews with:
Steven Feuerstein, PLSQL expert
Donald Burleson, Top IT consultant


Free eBook

Subscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:


What visitors say...

"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.

I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."

Mike, USA

Read more Testimonials



Database Normalization eBook:


Database Normalization eBook




Copyright © www.databasedesign-resource.com /
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: www.databasedesign-resource.com does not warrant any company, product, service or any content contained herein.

Return to top

Copyright acknowledgement note:

The name Oracle is a trademark of Oracle Corporation.
The names MS Access/MS SQL Server are trademarks of Microsoft Corporation.
Any other names used on this website may be trademarks of their respective owners, which I fully respect.