A Final Thought

   

---

Database Design Based on the Database Software

An RDBMS does not provide a basis or procedure or even a reason for designing a database in a particular fashionit only provides the tools that you need to implement a design. In contrast, a formal database-design method provides both the principles and rationale necessary to define a database properly and effectively.

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. This is an unwise approach that you should avoid 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 relationship 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 aspects 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 inaccurate 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. By doing so, you're more likely to design a sound structure because you'll be focused on the organization's information requirements. Once your design is complete, you can then clearly determine how you should implement the database (single- user application, client/server, Web-based, and so on) and which RDBMS you should use to facilitate the implementation.

---

Top