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.