- Topics Covered in This Chapter
- Why Should You Be Concerned with Database Design?
- The Importance of Theory
- The Advantage of Learning a Good Design Methodology
- Objectives of Good Design
- Benefits of Good Design
- Database-Design Methods
- Normalization
- Summary
- Review Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Why Should You Be Concerned with Database Design?
Some of you who work with relational database management system (RDBMS) application programs may wonder why you should be concerned with database design. After all, most programs come with sample databases that you can copy and modify to suit your own needs, and you can even borrow tables from the sample databases and use them in other databases that you’ve created. Some programs also provide tools that will guide you through the process of defining and creating tables. However, these tools don’t actually help you design a database—they merely help you create the physical tables that you will include in the database.
What you must understand is that it’s better for you to use these tools after you’ve created the logical database structure. RDBMS programs provide the design tools and the sample databases to help minimize the time it takes you to implement the database structure physically. Theoretically, reducing implementation time gives you more time to focus on creating and building end-user applications.
Yet the primary reason you should be concerned with database design is that it is crucial to the consistency, integrity, and accuracy of the data in a database. If you design a database improperly, it will be difficult for you to retrieve certain types of information, and you’ll run the risk that your searches will produce inaccurate information. Inaccurate information is probably the most detrimental result of improper database design—it can adversely affect your organization’s bottom line. In fact, if your database affects the manner in which your business performs its daily operations, or if it’s going to influence the future direction of your business, you must be concerned with database design.
Let’s look at this from a different perspective for a moment: Think about how you would go about having a custom home built. What’s the first thing you’re going to do? Certainly you’re not going to hire a contractor immediately and let him build your home however he wants. Surely you will first engage an architect to design your new home and then hire a contractor to build it. The architect will explore your needs and express them as a set of blueprints, recording decisions about size and shape and requirements for various systems (structural, mechanical, electrical). Next, the contractor will procure the labor and materials, including the listed systems, and then assemble them according to the drawings and specifications.
Now let’s return to our database perspective and think of the logical database design as the architectural blueprints and the physical database implementation as the completed home. The logical database design describes the size, shape, and necessary systems for your database, and it addresses the informational and operational needs of your business. You then build the physical implementation of the logical database design using your RDBMS program. After you’ve created your tables, set up table relationships, and established the appropriate levels of data integrity, your database is complete. Now you’re ready to design and create applications that allow you and your users to interact easily with the data stored in the database, and you can be confident that these applications will provide you with timely and, above all, accurate information upon which you can make sound business decisions.
Although you can implement a poor design in an RDBMS, implementing a good design is far more to your advantage because it will yield accurate information, store data more efficiently and effectively, and be easier for you to manage and maintain.