Independent of technology and organization.It is best to separate the search for business requirements from the concerns over designing an optimized structure. Later in design, the logical model will be optimized, and, if necessary, denormalized. Normalization does not require that the model be reduced below the level necessary to satisfy the query and reporting needs of the user. This runs contrary to what lots of people say, but remember, normalization does not presuppose the granularity of the data. A logical model should be normalized (to at least third normal form). The level of detail is the most detailed grain that the analytical environment will require. The atomic data in a DW is comprised of analytical data. It should be only as atomic as the queries and usage of the data dictates. It should satisfy these queries effectively, although it may not necessarily satisfy all types of queries efficiently. Any query that can be asked should be capable of being satisfied by this model. It is generally advisable to retain as detailed a grain as possible to ensure the flexibility and power of the DW. The DW establishes the granularity of the data. Next we explain these points is slightly more detail. Should also contain any external data that is essential to the business.Should be independent of technology, implementation and organizational constraints.Should fully satisfy user requirements.Should be atomic to the appropriate level.The key characteristics of this model are that it: Any team that does not know the business has no business building the logical data model. There is no substitute for business knowledge. This step is obviously the crucial starting point. If views are used up-front, it may even be transparent to the application teams and business users.Īnalysis Phase – Develop a Logical Data Model Aggressive compromising is an iterative process. Sometime aggressive compromises are done so that the effect of them can be properly tested. Steps 4 and 5 are iteratively performed so that the database can be tested before going into production.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). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |