IT 5433 LM4 Physical Design

Learning Objectives: Describe the physical database design process Explain how attributes transpose from the logical to physical model Describe the different types of file organizations Describe the different types of indexing Describe the pros and cons denomalization

Physical Design Database Process Physical database design translates the logical data model into a set of SQL statements that define the database. For relational database systems, it is relatively easy to translate from a logical data model into a physical database. database-design

Physical Design Database Process Entities to Tables Relationships to Foreign Keys Attributes to Columns Primary Unique Identifiers to the Primary Key Unique Identifiers to Unique Keys 4/physical.htm

How Attributes Transpose from the Logical to Physical Model During the physical design process, you convert the data gathered during the logical design phase into a description of the physical database, including tables and constraints. Physical design decisions, such as the type of index or partitioning have a large impact on query performance. 4/physical.htm

How Attributes Transpose from the Logical to Physical Model Logical Design Compared with Physical Design ysical.htm

File Organization Types: Sequential Indexed Hashed physical/file_organisation.htm#Organising

File Organization Sequential - Records are organised sequentially according to primary key value in an ordered sequential file. It is easy to locate and read from the file in order of key value Indexed - The index file contains key value(s) that can be matched with key values in one or more records. The index also contains the disk address of the record. Hashed - In hashed file organisation the address of each record is determined using a hashing algorithm. physical/file_organisation.htm#Organising

Indexing Indexes are optional structures associated with tables or clusters. In addition to the classical B-tree indexes, bitmap indexes are very common in data warehousing environments. Bitmap indexes are optimized index structures for set-oriented operations. Indexes are just like tables in that you can partition them, although the partitioning strategy is not dependent upon the table structure. Partitioning indexes makes it easier to manage the data warehouse during refresh and improves query performance ysical.htm#i

Pros and Cons of Denormalization Denormalized databases fair well under heavy read-load and when the application is read intensive. This is because of the following reasons: The data is present in the same table so there is no need for any joins, hence the selects are very fast. A single table with all the required data allows much more efficient index usage. If the columns are indexed properly, then results can be filtered and sorted by utilizing the same index. While in the case of a normalized table, since the data would be spread out in different tables, this would not be possible. denormalization-which-is-the-better-technique/

Pros and Cons of Denormalization Because the data is duplicated, the updates and inserts become complex and costly. Having said that neither one of the approach can be entirely neglected, because a real world application is going to have both read-loads and write-loads. denormalization-which-is-the-better-technique/

Links: sical.htm sical.htm design design denormalization-which-is-the-better-technique/ denormalization-which-is-the-better-technique/ htm#i htm#i al/file_organisation.htm#Organising al/file_organisation.htm#Organising