Database Designers
In large database design projects, we can distinguish between two types of designer:
logical database designers and physical database designers. The logical database designer
is concerned with identifying the data (that is, the entities and attributes), the relationships
between the data, and the constraints on the data that is to be stored in the database.
The logical database designer must have a thorough and complete understanding of the
organization’s data and any constraints on this data (the constraints are sometimes called
business rules). These constraints describe the main characteristics of the data as viewed
by the organization. Examples of constraints for DreamHome are:
n a member of staff cannot manage more than 100 properties for rent or sale at the same
time;
n a member of staff cannot handle the sale or rent of his or her own property;
n a solicitor cannot act for both the buyer and seller of a property.
To be effective, the logical database designer must involve all prospective database users
in the development of the data model, and this involvement should begin as early in the
process as possible. In this book, we split the work of the logical database designer into
two stages:
n conceptual database design, which is independent of implementation details such as the
target DBMS, application programs, programming languages, or any other physical
considerations;
n logical database design, which targets a specific data model, such as relational, network,
hierarchical, or object-oriented.
The physical database designer decides how the logical database design is to be physically
realized. This involves:
n mapping the logical database design into a set of tables and integrity constraints;
n selecting specific storage structures and access methods for the data to achieve good
performance;
n designing any security measures required on the data.
Many parts of physical database design are highly dependent on the target DBMS, and
there may be more than one way of implementing a mechanism. Consequently, the
physical database designer must be fully aware of the functionality of the target DBMS
and must understand the advantages and disadvantages of each alternative for a particular
implementation. The physical database designer must be capable of selecting a suitable
storage strategy that takes account of usage. Whereas conceptual and logical database
design are concerned with the what, physical database design is concerned with the how.
It requires different skills, which are often found in different people. We present a methodology
for conceptual database design in Chapter 15, for logical database design in Chapter
16, and for physical database design in Chapters 17 and 18.
In large database design projects, we can distinguish between two types of designer:
logical database designers and physical database designers. The logical database designer
is concerned with identifying the data (that is, the entities and attributes), the relationships
between the data, and the constraints on the data that is to be stored in the database.
The logical database designer must have a thorough and complete understanding of the
organization’s data and any constraints on this data (the constraints are sometimes called
business rules). These constraints describe the main characteristics of the data as viewed
by the organization. Examples of constraints for DreamHome are:
n a member of staff cannot manage more than 100 properties for rent or sale at the same
time;
n a member of staff cannot handle the sale or rent of his or her own property;
n a solicitor cannot act for both the buyer and seller of a property.
To be effective, the logical database designer must involve all prospective database users
in the development of the data model, and this involvement should begin as early in the
process as possible. In this book, we split the work of the logical database designer into
two stages:
n conceptual database design, which is independent of implementation details such as the
target DBMS, application programs, programming languages, or any other physical
considerations;
n logical database design, which targets a specific data model, such as relational, network,
hierarchical, or object-oriented.
The physical database designer decides how the logical database design is to be physically
realized. This involves:
n mapping the logical database design into a set of tables and integrity constraints;
n selecting specific storage structures and access methods for the data to achieve good
performance;
n designing any security measures required on the data.
Many parts of physical database design are highly dependent on the target DBMS, and
there may be more than one way of implementing a mechanism. Consequently, the
physical database designer must be fully aware of the functionality of the target DBMS
and must understand the advantages and disadvantages of each alternative for a particular
implementation. The physical database designer must be capable of selecting a suitable
storage strategy that takes account of usage. Whereas conceptual and logical database
design are concerned with the what, physical database design is concerned with the how.
It requires different skills, which are often found in different people. We present a methodology
for conceptual database design in Chapter 15, for logical database design in Chapter
16, and for physical database design in Chapters 17 and 18.
No comments: