Database Reference
In-Depth Information
Many people unwittingly fall into the trap of designing a database based solely on the
RDBMS software they will use for its implementation. In many cases, they do so because
they are already somewhat familiar and skilled with a particular RDBMS or their company
or organization is already using a particular RDMBS. This is an unwise approach that you
should avoid (as much as possible) for several reasons.
•
You're likely to make design decisions based on your perceptions of what your
RDBMS can or can't do.
For example, you may decide not to impose a degree of
participation for a given relationship because you believe the RDBMS does not
provide you with the means to do so.
•
You'll inadvertently let the RDBMS dictate the design of the database as opposed
to driving the design strictly from the organization's information requirements.
This usually occurs when you discover that your RDBMS provides only limited
support for certain aspects of the database, such as field specifications and rela-
tionship characteristics.
•
Your design will be constrained by your knowledge of the RDBMS.
For example,
you may decide not to implement relationship characteristics simply because you
don't know how to do so.
•
Your design will be constrained by how skilled you are with your RDBMS.
Your
skill level affects how efficiently and effectively you can implement various as-
pects of the database, such as field specifications and business rules.
•
Using this approach to design a database commonly results in improper structural
design, insufficient data integrity, and problems with inconsistent data and inac-
curate information.
Defining a database within an RDBMS can be deceptively
easy. You may create a database that works, but you're very likely to have a poor
design without knowing it.
•
In the end, the RDBMS that you know and love so well may not be suitable for
your organization's database requirements
.
You should always design the logical structure of your database without regard to any
RDBMS. Bydoingso,you'remore likely todesign asoundstructure because you'll befo-
cused on the organization's information requirements. Once your design is complete, you
can then clearly determine how you should implement the database (single-user applica-
tion, client/server, web-based, and so on) and which RDBMS you should use to facilitate
the implementation.
