Hello Fahd,
This is a pretty open ended question, but let me give you some suggestions
that will touch on several related topics. I will assume you have a good
theoretical background in database design but not a lot of practical
experience in deploying database products.
1. A few of the more critical aspects I have found in data base design
are the amount of data you expect to manage as well as the complexity and
rate of operations (e.g., query, updates) expected. You can get a partial
answer to this from the interviews, but not a complete one.
For example, a data base on disk will be limited by the rate of disk
transfers. To do an accurate model of system performance, you should do
some tests with a similar sized data base and query rate to determine if
the proposed equipment can do the job. A quick test shouldn't take more
than a day or so for an initial estimate. You can also continue to check
performance as the system goes together to help prevent surprises.
2. The methods you use to descibe the database (e.g., an entity relationship
diagram) is not likely to be understood by the customer or the people you
interviewed (if they are different). Part of the job is to put the design
into words that your customer can understand.
I have found that a combination of illustrations, text, and a demonstration
of a prototype (could be on paper) is necessary to get across how the
database will work and how people will interact with it.
3. You didn't say if the database is relational or object oriented. I'll
answer for a relational database, but similar steps can be applied for
an object oriented database. For a relational database, normalization of
the data is a typical step to create tables without redundant information.
In general, putting the data in normal form is a step you should perform
with care. Mistakes at this point can cause a lot of rework later in
your database development or after deployment.
4. You need to address what you do when "something goes wrong". Problems
in a real system arise when incorrect (or unreasonable) data is entered,
an operation is aborted by the user, or you find you left out something
and must revise the database design (and get missing data entered for all
the records you already have).
This is an area that can make or break a system. Consider a data entry
person (say a purchaser entering data on a web form) doesn't have an
answer for a field you consider "required". If they get frustrated and
leave the web site - the company may have lost a sale. You need to set
up some user oriented testing with a prototype and use that knowledge t
improve the system.
In this answer, I've touched on a few of the key areas to look at
in designing a database and building a system that will use it.
Some places on line that may have some additional reference material
include:
"Your First Database"
http://hotwired.lycos.com/webmonkey/99/13/index1a.html
A general guide to issues you address in an initial database design.
Introduction to Data Modelling
http://www.utexas.edu/cc/database/datamodeling/index.html
A good review of the relevant material for relational databases.
The Alertbox: Current Issues in Web Usability
http://www.useit.com/alertbox/
A series of articles focusing on how users work with web pages, what
works well and what doesn't (in case your data entry and display
is via web pages).
I hope this has been helpful to you. Don't hesitate to ask for
more information.
--Manaic |
