Như đã giới thiệu trong chương 5 trong hình 5-1, một khi giai đoạn thiết kế hợp lý của một dự án hoàn thành, đó là thời gian để chuyển sang thiết kế vật lý. Các thành viên khác của một nhóm dự án điển hình sẽ xác định phần cứng và phần mềm hệ thống cần thiết cho hệ thống ứng dụng. | This page intentionally left blank. CHAPTER X V3 Physical Database Design As introduced in Chapter 5 in Figure 5-1 once the logical design phase of a project is complete it is time to move on to physical design. Other members of a typical project team will define the hardware and system software required for the application system. We will focus on the database designer s physical design work which is transforming the logical database design into one or more physical database designs. In situations where an application system is being developed for internal use it is normal to have only one physical database design for each logical design. However if the organization is a software vendor for example the application system must run on all the various platform and RDBMS versions that the vendor s customers use and that requires multiple physical designs. The sections that follow cover each of the major steps involved in physical database design. Copyright 2004 by The McGraw-Hill Companies. Click here for terms of use. Databases Demystified Designing Tables The first step in physical database design is to map the normalized relations shown in the logical design to tables. The importance of this step should be obvious because tables are the primary unit of storage in relational databases. However if adequate work was put into the logical design then translation to a physical design is that much easier. As you work through this chapter keep in mind that Chapter 2 contains an introduction to each component in the physical database model and Chapter 4 contains the SQL syntax for the DML commands required to create the various physical database components tables constraints indexes views and so on . Briefly the process goes as follows 1. Each normalized relation becomes a table. A common exception to this is when super types and subtypes are involved a situation we will look at in more detail in the next section. 2. Each attribute within the normalized relation becomes a .
