The physical database design is then converted to a physical structure by generating or writing the DDL and installing the database.Apply technical optimizations to the model, such as indices, referential integrity or partitioning.Apply aggressive compromises to the model, such as adding redundant data.Apply safe compromises to the model, such as splitting a table or combining two tables.The outcome from this is a physical database design. The logical model is then transformed into a second-cut physical model by iteratively applying three levels of optimizations or compromises.

The logical model is transformed into a first-cut physical model by applying several simple modifications, such as splitting a large table or combining entities in a 1:1 relationship.Business requirements are gathered and represented in a logical data model, which will completely represent the business data requirements and will be non-redundant.The business authorization to proceed is received.Here are the major steps in the transformation of the model: Let us start with an overview of the overall process for creating logical and physical data models. This chapter describes a process that is generic enough to be used as a guide for different projects. The overall process is pragmatic (e.g., that it addresses issues of query, report and load performance).The process has integrity (i.e., that it accounts for all the necessary steps and feedback loops), and.The data model has integrity (e.g., that business rules have been honored),.By following these procedures, one can ensured that: The following procedures can be successfully used to transform a Logical Analytical Data Model into a physical database, such as a data warehouse or a data mart. The purpose of this article is to define the process for converting a logical data model to a physical data model, especially in a warehouse environment.īefore discussing the specific methods for optimizing a data warehouse data model, let us first review the overall process for developing a logical data model and eventually building it as a physical, optimized database.

Publisher’s Note: This article is being published in Association with DebTech’s Meta-Data and Data Modeling Summit in February 2006 in Orlando, Florida.

Product vs logical keys