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
 After 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
|
