In a nutshell...
Database design refers to the way tables in a database
are constructed to store data.
NB: A database is not the same as an
application although the term is often used inter-changeably.
A database is used to store data whereas an application
describes the combination of a database and a
program (GUI).
The program, or GUI, sits on top of the database and allows
users to access the data. It's the combination of a database
and a GUI that accurately describes an application.
Tell me more...
When designing your new database, a good way to approach
it is to think about how an architect would come up with
a design for a new home.
A good architect makes sure that certain rooms face the
sun for most of the day. That the drainage takes water
away from the house and doesn't create a swimming pool
every time it rains. A good design makes sure when you
enter your house via the front door at night, you don't
have to walk across a dark hall to switch a light on.
A correctly designed database is very similar. It will
fulfill the requirements of your business perfectly. It
will allow you to store and access your data efficiently,
knowing the answers you get from your database are going
to be accurate. This will help you to make decisions that
will make your business work more efficiently.
Many people are always looking for ways to save money
by cutting corners but if there is one part you should
never cut back on, it's the design of your database. To
use the building analogy again, consider the implications
of trying to add a basement room or wine cellar - after
a property has been built!
Consider the following as you would the foundations and
structure of a new house:
• Does it provide all the rooms you are
going to need?
It's easy to name the big rooms but did you remember to
include an airing cupboard and the built in wardrobes?
Ok, they are not what a property agent would call a room
but nevertheless they are spaces that serve a function
and still need to be considered in the overall plan of
a home. Be careful when designing your database that you
don't miss import sections.
• Will I be able to navigate from room to
room easily?
You shouldn't have to walk through the bathroom to get
to the kitchen. Databases are the same. The relationship
between tables should be logical and practical and conform
to standard database design rules that make accessing
and using your data easy whilst preserving integrity and
efficiency.
• Is it possible to add new rooms at a later
date?
Many people have ideas of building another bedroom over
the garage, only to find when they start digging that
the garage footings are not suitable. What if your business
grows and you want to provide a new service or product?
Make sure that the design of your database can grow and
won't hold you back.
• What will the gas and electric cost?
Having a living room the size of a small swimming pool
may look great but is it cost effective to use? A badly
designed database can increase the time and cost it takes
to use and retrieve data.
• What will it cost to maintain?
A badly designed database will probably mean having to
regularly call the developers back to make changes, fix
and alter things.
Why a building analogy?
Simply because, just like a house, once it's built it's
very difficult to make changes to the structure. Don't
like the colour? No problem, just give it another lick
of paint. Simple. Want to add a basement for a photographic
studio? Although it's possible, it's probably easier to
buy a new home with one already there or knock it down
and start again.
A lot of the problems I come across from day-to-day
are the result of poorly designed databases. Like the
foundations in a house, if you get it right at the ground
level it will solidly support your business regardless
of what you put on top of it to access your data.
Anything else?
Remember that most users will access your data
through some sort of GUI but the GUI is separate from
the database. If your database has been designed correctly
you can always change the GUI at a later date if required.
Also keep in mind that you can test the integrity of a
database to see if it works as expected before you invest
too much time in your GUI. It's a relatively trivial matter
to enter raw data into the actual tables to see if it
'holds water'.
Back to the top:
|
