Physical Database Design

Physical Database Design

Consisting of columns and rows where each column contains a specific attribute and each row features a certain value for the corresponding attribute, Databases allows a computer program to quickly select and handle the necessary pieces of information. It also receives all application requests and translates them into the complex operations required to fulfill those requests. Hence having many advantages, one of its benefits would be substantial time savings, databases saves time. Using database, the user can retrieve any record that may take as usual several minutes of digging in a manual paper-based system; it can be done with just a few clicks in a computerized database.

Physical database Design discusses the concept of how physical structures of databases affect performance, including specific examples, guidelines, and best and worst practices for a variety of Database management systems and configurations. Using that it can easily give the user lots of different ways to look at the data. Finding a record can take just a minute or two as opposed to hand-collating data records or sorting and to resort into a spreadsheet. Independence from applications programs giving the user to link different sources of information together so you can see important things about your business you might never have noticed before. And lastly conflicting requirement can be handled. Conflicting requirements are a sign of big trouble. You couldn't possibly satisfy doing two at the same time. So database allows getting the users to choose what goes in, and they get to change their minds making it more easily distinguished. During physical design, you transform the entities into tables, the instances into rows, and the attributes into columns. 

Physical design is where you translate the expected schemas into actual database structures. At this time, you have to map the entities to Tables, Relationships to Foreign Keys, Attributes to Columns, Primary Unique Identifiers to the Primary Key, Unique Identifiers to Unique Keys.

After completing the logical design of your database, you now move to the physical design. You and your colleagues need to make many decisions that affect the physical design. 

For example; 

How to translate database entities into physical tables?

What attributes to use for columns of the physical tables? 

Which columns of the tables to define as keys? 

What indexes to define on the tables?

What views to define on the tables? 

How to denormalize the tables? 

How to resolve many-to-many relationships?

What designs can take advantage of hash access? 

What are user expectations for response time? 

What are the security requirements for the data and the system? 

What are the hardware platform limitations? 

What is the anticipated data volume? 

How much data will be stored in approximately?

 This classical approach of the physical database design is strongly serial with many interdependencies between the sub-steps.


Researcher : Daryll Hannah Padilla