|
The Database Design Alalysis - Business perspective
The Database Design Analysis phase - Where it all starts.
The business perspective
The analysis phase of our database design website 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 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 business model containing all entities with
their attributes, domains and relations, 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
will be carried over to the design phase of the development
project.
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 stop this at once: 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.
Destination: Desktop For GoogleFirst we had the original Google search that evolved into the leader in its class. In fact, it became so popular that the word "google" .....
'Good judgments are based on experience. Experience is based on
bad judgments'.
The importance of a professional Database analysis team.
The complexity and degree of computer involvement in the
business is constantly growing. No wonder; each 18th month, we
can buy hardware with twice the performance at the same price.
We are therefore able to put more demands on our software, until
we reach some limit. However, it only takes another 18 months;
then we can buy new hardware without these limits... and so on.
There is also a good reason for it: We may very well rely on a
standard system for our accounting or payroll routines, we can
use market standards in word processing and spreadsheets, and so
Linux SecretsThe first thing that you will notice about Linux Red Hat (using the Gnome Interface) is that it looks a lot like ..... on. What separates a high-performing business from a failure is
the way the CUSTOMER is reached for, and how he is treated. That
is customer marketing and customer care. The customer is always
the business. If you do not have customers, you do not have a
business.
If such a business exists,however, please let me know.
Such systems, systems that give the business an advance compared
to its competitors, we may call strategic systems. If two
businesses buy the same strategic system from the shelf, then
they do not gain any system advantage towards each other. On the
other hand, the business that is fastest to respond, and
deliver, and at the same time is competitive, will definitely
have an advantage. In a world with rising competition and
globalization, this will grow more and more important. Good news
for the software industry and the analysis team...
In the analysis stage, we need an analysis team of both business
experiences as well as experienced system analysts. In addition,
we need tools that can help us seeing the overall picture, as
well as helping us further forward.
Top business experience is required in the analysis team in
order to get in-depth understanding of the business itself.
Remember: Our model, at this stage in development, must reflect
the business, not some constraints given by any tool or personal
preferences. This happens all too often and usually with
not-to-good results.
In the analysis team, the system analysts must have an expert
level knowledge of business modeling. By business modeling, I
mean exactly that. I do not mean expert knowledge of f.i. Entity
Relationship modeling without relating it to the real world.
However good a person may be educated, nothing beats the
experience earned from several similar tasks at the equivalent
level of complexity. How does one gain experience then?
Participate under a tutor. I would never hire a consultant
without experience and trust her to understand the complexity of
my business, all by herself.
I will not go into detail as to the total project staff is
composed. This will depend on many outside factors, such as
degree of participation from each party, size of the project,
formal requirements (public sector tends to require at higher
level of project staffing, partly due to rigorous documentation
requirements), etc. What we focus on is the tightly performing
party that determines the final business model: The experts on
the business together with the system analysts, preferably more
than one in this phase.
Due to the increasing complexity that tends to be taken into
systems development, I cannot imagine a development project of
any noticeable size that should not use a development tool as
support for the analysis team as well as for each stage other of
development. I regard the tool(s) chosen as an integral part of
the team. In many cases, the tool is also the communicator
between the business and the analyst. I have often started a
project by going through the way we communicate with each other.
In my experience, the business soon finds Entity Relationship
diagrams familiar, if not as familiar as to the system analysts.
However, they are a means of communication that work. The same
may be said for function diagrams, or function hierarchies. They
are even easier to understand for a non-system person.
That is why the eBook on Entity Relationship Modeling
Principles is in the writing, and soon will be published on
this site as a free eBook, which you are free to use in your
ongoing or upcoming projects.
As for choice of modeling tool, I give no concrete
recommendations: I have used Oracle Designer (formerly Oracle
CASE*Method) for the last 15 years, and I have found it to be a
powerful and rich system, which delivers in many more areas than
I have needed to use it for. I am probably a little biased here.
However, a toolset should include reusable objects: The results
from the analysis phase should be the basis for generating
tables and all other database objects for use in the design
phase, as well as functions should be used for generating
candidate modules. Furthermore, the database objects and
candidate modules should be used to generate the DDL (Data
Definition Language) scripts for physically building all the
elements of the database, as well as the candidate modules
should be used to generate running program modules. Not that I
expect a system to be 100% generated far from it. However,
with such functionality you could show a prototype, which
illustrated the resulting, needed functionality, but without the
last finishing touch or the most advanced business constraints
built into it.
For more visualization of this article, visit
http://www.databasedesign-resource.com
About the author:
The author has spent the last 15 years as a system analyst in
manufacturing, government, private corporations and
broadcasting, performing database analysis and design, based on
Oracle Designer and Developer tools.
|