Subject Approach to Database Design

In general, there are two ways to approach database design.

1. One is to focus on the subject matter with which the database is concerned, for example, how it will be organized and displayed;
2. the other is to focus on the application in which the database will be created and viewed.

In the subject approach to database design, all the tables in a database store data according to subject matter. A large company, for example, might have a database devoted to the sales department. Such a database might have tables devoted to customers, orders, discounts, and so forth. Other databases in the same company might be devoted to personnel, accounting and marketing. Just as each table in a database is devoted to one specific subject, in the subject approach multiple tables in a database relate to a single subject area. The subject approach to database design focuses on organizing data according to the specific subjects or topics that the data represents. This approach is also known as the entity-centered or data-centered approach. In the subject approach, the database is designed around the specific data entities that need to be stored, such as customers, products, orders, or employees. Each entity is defined by its attributes or properties, such as name, address, phone number, or email, which are stored in the corresponding fields or columns in the database.
The subject approach emphasizes the importance of data normalization, which is the process of organizing data in a way that minimizes redundancy and inconsistency. This involves breaking down data into smaller, more atomic pieces, and creating separate tables for related entities, such as customers and orders. By doing so, the subject approach can help ensure data integrity and improve data quality. The subject approach is commonly used in relational database design, where data is organized into tables and related through common attributes or keys. However, other database models, such as hierarchical or network databases, may also use the subject approach. The subject approach to database design emphasizes the importance of organizing data around the specific subjects or topics that the data represents, rather than around specific applications or processes. This can help ensure a more flexible and adaptable database design that can be easily modified or extended as needed.

The subject approach to database design is called a top-down design because it follows the four-step order which is outlined in the following series of images.

In the context of database design, "top-down design" refers to an approach where the overall structure and organization of the database is designed first, before the detailed specifications of individual tables and fields are determined. The top-down design approach begins with identifying the high-level requirements of the database, such as the entities, relationships, and data elements that need to be stored. This involves creating an entity-relationship (ER) diagram or a data model that represents the overall structure of the database. Once the high-level requirements have been established, the next step is to break down the database structure into smaller components. This involves identifying the different tables, fields, and data types that are needed to store the data. The top-down design approach is beneficial because it ensures that the overall structure and organization of the database are well-defined before the specific details are determined. This can help prevent errors and inconsistencies in the database design and make it easier to maintain and modify the database in the future.
However, the top-down design approach can be time-consuming and may not be suitable for all database design projects. In some cases, a bottom-up approach, where the individual tables and fields are designed first and then combined into a larger structure, may be more appropriate. Ultimately, the design approach should be tailored to the specific needs and requirements of the database project.

Everyone including

1. database designers,
2. application architects,
3. programmers,
4. database administrators, and
5. project managers

should ideally understand what makes a good database design. Even an application's key customers and users could benefit from understanding how databases work. Many IT professionals have learned what they know about databases through rumor, trial-and-error, and painful experience. Over the years, some develop an intuitive feel for what makes a good database design but they may still not understand the reasons why a design is good or bad, and they may leave behind a trail of rickety, poorly constructed programs built on shaky database foundations.
This book provides the tools you need to design a database. It explains how to determine what should go in a database and how a database should be organized to ensure data integrity and a reasonable level of performance. It explains techniques for designing a database that is strong enough to store data safely and consistently, flexible enough to allow the application to retrieve the data it needs quickly and reliably, and adaptable enough to accommodate a realistic amount of change. Even if you were designing a database for a small company, the subject approach would dictate that you create three small databases if you identified three distinct subject areas.

Before moving on to the next lesson, click the link below to check your understanding of the subject approach to database design.
Designing Subject Database
The next lesson introduces the application approach to database design.