Chapter 5 Flashcards
What is the purpose of Physical Database design?
To translate the logical description of data into the technical specifications for storing and retrieving data.
What is the goal of Physical Database Design?
To create a design for storing data that will provide adequate performance and ensure database integrity, security, and recoverability.
Physical Design Process visualized
What are the regulations and standards that impact physical design decisions?
- Sarbanes-Oxley Act (SOX) - Protect investors by improving accuracy and reliability
- Committee of Sponsoring Organizations (COSO) of the Treadway Commission
- IT Infrastructure Library (ITIL)
- Control Objectives for Information and Related Technology (COBIT)
What is a field?
Smallest unit of application data recognized by system software
What do you have to consider when designing a field?
- Choose data type
- Coding, compression, encryption
- Control data intregrity
Different Data Types, Picture
What is a default value?
An assumed value if no explicit value
What is range control?
The allowable value limitations (constraints or validation rules)
What is null value control?
Allowing or prohibiting empty fields
What is referential integrity?
Range control (and null value allowances) for foreign-key to primary-key match-ups
How do you handle missing data?
- Substitue an estimate of the missing value (e.g., using a formula)
- Construct a report listing missing values
- In programs, ignore missing data unless the value is significant (sensitivity testing)
*Triggers can be used to perform these operations*
What is denormalization?
Transforming normalized relations into non-normalized physical record specifications
What are the benefits of denormalization?
- Can improve performance (speed) by reducing number of table lookups (i.e. reduce number of necessar join queries)
What are the costs of denormalizations, due to data duplication?
- Wasted storage space
- Data integrity/consistency threats
What are the common denormalization opportunities?
- One-to-one relationships
- Many-to-many relationship with non-key attributes (associative entity)
- Reference data (1:N relationship where 1-side has data not used in any other relationship)
One-to-one denormalization example
Many-to-Many denorm example
Reference data denorm example
What are some risks associated with denormalization?
- Increase chance of errors and inconsistencies
- Reintroduce anomalies
- Fore reprogramming when business rules change
What other methods can be used to improve the performance of joins?
- Organization of tables in the database (file organization and clustering)
- Proper query design and optimization