1. CSCI 3140 Module 2 – Conceptual Database Design Theodore Chiasson Dalhousie University

2. Database Design Methodology Design Methodology –A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design Conceptual database design –The process of constructing a model of the information used in an enterprise, independent of all physical considerations Logical database design –The process of constructing a model of the information used in an enterprise based on a specific data model, but independent of a particular DBMS and other physical considerations Physical database design –The process of producing a description of the implementation of the database on secondary storage; it describes the base relations, file organizations, and indexes used to achieve efficient access to the data, and any associated integrity constraints and security measures

3. Conceptual database design methodology Build a local conceptual data model for each view For each identified view within the enterprise: –Identify entity types –Identify relationship types –Identify and associate attributes with entity or relationship types –Determine attribute domains –Determine candidate and primary key attributes –Consider use of enhanced modeling concepts –Check model for redundancy –Validate local conceptual model against user transactions –Review local conceptual data model with user

4. Identify entity types Based on the requirements specification, identify the entity types for each view of the enterprise –End-users typically use nouns when describing entities –Often, an end-user will refer to someone by name rather than describe their position –The same word can mean different things in different sectors –Different views may use different words to describe the same entity

5. Identify relationship types For each view, identify the relationships among the entities –End-users typically use verbs when describing relationships –Model only those relationships that appear to be required based on the requirements specification –Most relationships are binary –Use ER diagrams –Determine the multiplicity constraints of relationship types –Check that each entity participates in at least one relationship –Document relationship types using meaningful names

6. Identify attributes For each entity type and relationship type, ask –What information are we required to store about ________? Note whether an identified attribute is simple or composite Note whether an attribute is single-valued or multi-valued Describe derived attributes For each identified attribute, document –Attribute name and description –Data type and length –Any aliases that the attribute is known by –Whether the attribute is composite, and, if so, the simple attributes that make up the composite attribute –Whether the attribute is multi-valued –Whether the attribute is derived and, if so, how it should be computed –Any default values for the attribute Identifying attributes will likely lead to a need to refine the identified entity types and relationship types

7. Identify attribute domains An attribute domain is a pool of values from which one or more attributes draw their values Record the attribute domain name and characteristics in the data dictionary Update the attribute descriptions to use the named attribute domain

8. Determine candidate and primary key attributes A candidate key is a minimal set of attributes of an entity that uniquely identifies each occurrence of that entity If more than one candidate key exists, one of them is chosen as the primary key and the remaining candidate keys are called alternate keys Record the identification of primary and alternate keys in the data dictionary Update the draft ER diagram to include the selected primary key for each entity

9. Consider use of enhanced modeling concepts Use generalization and specialization to identify class hierarchies of entities Use aggregation and composition to further define class hierarchy relationships Can help to clarify the relationships in an ER diagram

10. Check model for redundancy Examine 1:1 relationships –May be able to combine two entities into one Remove redundant relationships –Two different paths between two entities may indicate a redundant relationship exists

11. Validate local conceptual model against user transactions The local conceptual model represents a specific view of the enterprise Check the model to ensure that is supports the transactions required by the users of this view Check the model by describing how the model can be used to support each transaction, or by tracing the relationships and entities involved in supports each transaction directly on the ER diagram Transaction pathways (traces on the ER diagram) can help to identify areas of the model that are not used by any transactions

12. Review local conceptual model with user The conceptual data model includes the ER diagram and the supporting documentation that describes the model Review of the model with the user may identify anomalies in the model that have to be corrected, which may require repeating previous steps The entire process is repeated until the user is prepared to ‘sign off’ on the model as being a true representation of the part of the enterprise being modeled.