Entity Relationship Modeling
Objectives:
• To illustrate how relationships between entities are defined and refined.
• To know how relationships are incorporated into the database design process.
• To describe how ERD components affect database design and implementation.
Introduction to Data Modeling
• Semantic data models attempt to capture the “meaning” of a database. Practically, they provide an approach for conceptual data modeling.
• Over the years there have been several different semantic data models that have been proposed.
• By far the most common is the entity-relationship data model, most often referred to as simply the E-R data model.
• The E-R model is often used as a form of communication between database designers and the end users during the developmental stages of a database.
• The E-R model contains an extensive set of modeling tools, some of which we will not be concerned with as our primary objective is to give you some insight into conceptual database design and not learning all of the ins and outs of the E-R model.
• Another conceptual modeling which is becoming more common is the Object Definition Language (ODL) which is an object-oriented approach to database design that is emerging as a standard for object-oriented database systems.
Database Design
• The database design process can be divided into six basic steps. Semantic data models are most relevant to only the first three of these steps.
1. Requirements Analysis: The first step in designing a database application is to understand what data is to be stored in the database, what applications must be built on top of it, and what operations are most frequent and subject to performance requirements. Often this is an informal process involving discussions with user groups and studying the current environment. Examining existing applications expected to be replaced or complemented by the database system.
2. Conceptual Database Design: The information gathered in the requirements analysis step is used to develop a high-level description of the data to be stored in the database, along with the constraints that are known to hold on this data. Creation of conceptual schema • Concise description of users’ data requirements • Uses high-level conceptual data model, e.g. Entity-relationship model – Data model operations used to specify user operations from functional analysis – Compatibility check and possible modification.
3. Logical Database Design: A DBMS must be selected to implement the database and to convert the conceptual database design into a database schema within the data model of the chosen DBMS. • Logical design / data model mapping – Uses implementation data model, e.g. relational data model – Conceptual schema transformed from high-level data model to implementation data model.
4. Schema Refinement: In this step the schemas developed in step 3 above are analyzed for potential problems. It is in this step that the database is normalized. Normalization of a database is based upon some elegant and powerful mathematical theory. We will discuss normalization later in the coming classes.
5. Physical Database Design: At this stage in the design of a database, potential workloads and access patterns are simulated to identify potential weaknesses in the conceptual database. This will often cause the creation of additional indices and/or clustering relations. In critical situations, the entire conceptual model will need restructuring.
• Physical design – Internal storage structures, access paths, file organization specified – Application programs designed and implemented.
6. Security Design: Different user groups are identified and their different roles are analyzed so that access patterns to the data can be defined.
• There is often a seventh step in this process with the last step being a tuning phase, during which the database is made operational (although it may be through a simulation) and further refinements are made as the system is “tweaked” to provide the expected environment.
• The illustration on the following page summarizes the main phases of database design.
No comments:
Post a Comment