© Pearson Education Limited, Chapter 9 Logical database design – Step 1 Transparencies

© Pearson Education Limited, Chapter 9 - Objectives What a design methodology is. Database design has two main phases: logical and physical design. Critical success factors in database design.

© Pearson Education Limited, Chapter 9 - Objectives About a methodology for logical and physical database design. The tasks in Step 1 of the database design methodology, which build an ER model. The documentation produced during Step 1 of database design, including Entity–Relationship (ER) diagrams and a data dictionary.

© Pearson Education Limited, Introduction to the database design methodology If the database is reasonably complex, a systematic approach is needed to design and build the database to ensure that it satisfies users’ requirements and achieves stated performance requirements. This systematic approach is called a database design methodology.

© Pearson Education Limited, What is a design methodology? A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design.

© Pearson Education Limited, Phases of database design Two main phases: logical and physical database design. Logical database design is the process of constructing a model of data used in an organization based on a specific data model, but independent of a particular DBMS and other physical considerations.

© Pearson Education Limited, Phases of database design Physical database design is the process of producing a description of the implementation of the database on secondary storage; it describes the base tables, file organizations, and indexes used to achieve efficient access to the data, and any associated integrity constraints and security restrictions.

© Pearson Education Limited, Critical success factors in database design  Work interactively with the users as much as possible.  Follow a structured methodology throughout the data modeling process.  Employ a data-driven approach.  Incorporate structural and integrity considerations into the data models.

© Pearson Education Limited, Critical success factors in database design  Use normalization and transaction validation techniques in the methodology.  Use diagrams to represent as much of the data models as possible.  Use a database design language (DBDL).

© Pearson Education Limited, Critical success factors in database design  Build a data dictionary to supplement the data model diagrams.  Be willing to repeat steps.

© Pearson Education Limited, Overview of the database design methodology

© Pearson Education Limited, Step 1 Create and check ER model Objective is to build an ER model of the data requirements of an organization (or part of an organization) to be supported by the database.

© Pearson Education Limited, Step 1 - Tasks  Step 1.1 Identify entities  Step 1.2 Identify relationships  Step 1.3 Identify and associate attributes with entities or relationships  Step 1.4 Determine attribute domains

© Pearson Education Limited, Step 1 - Tasks  Step 1.5 Determine candidate, primary, and alternate key attributes  Step 1.6 Specialize/Generalize entities (optional step)  Step 1.7 Check model for redundancy

© Pearson Education Limited, Step 1 - Tasks  Step 1.8 Check model supports user transactions  Step 1.9 Check model with users

© Pearson Education Limited, Step 1.1 Identify entities One method is to examine the users’ requirements specification for nouns or noun phrases Also look for major objects such as people, places, or concepts of interest, excluding those nouns that are merely qualities of other objects. Document entities

© Pearson Education Limited, StayHome entities BranchStaff VideoVideoForRent MemberRentalAgreement ActorDirector

© Pearson Education Limited, Extract from data dictionary for StayHome

© Pearson Education Limited, Step 1.2 Identify relationships  One method is to examine users’ requirements specification for verbs or verbal expressions.  Use entity–relationship (ER) modeling  Determine the multiplicity constraints of relationships  Check for fan and chasm traps  Document relationships

© Pearson Education Limited, First ER diagram of StayHome

© Pearson Education Limited, First draft of relationships for StayHome

© Pearson Education Limited, Multiplicity constraints for relationships

© Pearson Education Limited, Adding multiplicity constraints to ER diagram

© Pearson Education Limited, Extract from the data dictionary showing descriptions of relationships

© Pearson Education Limited, Step 1.3 Identify and associate attributes with entities or relationships  Attributes can be identified where noun or noun phrase is a property, quality, identifier, or characteristic of one of the entities or relationships previously found.  Document attributes

© Pearson Education Limited, Documenting attributes  attribute name and description;  data type and length;  any aliases that the attribute is known by;  whether the attribute must always be specified (in other words, whether the attribute allows or disallows nulls);

© Pearson Education Limited, Documenting attributes  whether the attribute is multi- valued;  whether the attribute is composite, and if so, which simple attributes make up the composite attribute;  whether the attribute is derived and, if so, how it should be computed;  default values for the attribute (if specified).

© Pearson Education Limited, Associate attributes with entities Branch (branchNo, address(composite street, city state, zipCode), telNo (multi-valued)) Staff (staffNo, name, position, salary) Video (catalogNo, title, category, dailyRental, price) Director (directorName) Actor (actorName) Member (memberNo, name (composite: fName, lName), address) RentalAgreement (rentalNo, dateOut, dateReturn) VideoForRent (videoNo, available)

© Pearson Education Limited, Extraction of data dictionary showing descriptions of attributes

© Pearson Education Limited, Step 1.4 Determine attribute domains A domain is a pool of values from which one or more attributes draw their values A domain specifies:  allowable set of values for the attribute;  size and format of the attribute. Document attribute domains

© Pearson Education Limited, Step 1.5 Determine candidate, primary, and alternate key attributes  Identifying candidate key(s) for an entity and then selecting one to be the primary key.  Candidate keys can never be null.  Remaining candidate keys are called alternate keys.  Document candidate, primary, and alternate keys

© Pearson Education Limited, Guidelines for choosing a primary key  Select the candidate key  the minimal set of attributes;  that is less likely to have its values changed;  that is less likely to lose uniqueness in the future;

© Pearson Education Limited, Guidelines for choosing a primary key  Select the candidate key  with fewest characters (for those with textual attribute(s));  with the smallest maximum value (for numerical attributes);  that is easiest to use from the users’ point of view.

© Pearson Education Limited, ER diagram showing primary keys

© Pearson Education Limited, Extract from data dictionary showing attributes with primary and alternate keys

© Pearson Education Limited, Step 1.6 Specialize/Generalize entities (optional step)  Objective is to identify superclass and subclass entities, where appropriate.  The modeling of superclasses and subclasses adds more information to the data model, but also adds more complexity as well.

© Pearson Education Limited, Step 1.7 Check model for redundancy Examine the ER model and if redundancy found, remove from model. The three activities in this step are: (1) re-examine one-to-one (1:1) relationships; (2) remove redundant relationships; (3) consider the time dimension when assessing redundancy.

© Pearson Education Limited, Remove redundant relationships

© Pearson Education Limited, Non-redundant relationships

© Pearson Education Limited, Step 1.8 Check model supports user transactions  ER model represents the data requirements of the organization  Objective is to check that ER model supports the required transactions. Two possible approaches: (1)Describing the transaction (2)Using transaction pathways

© Pearson Education Limited, Using pathways to check ER model supports user transactions

© Pearson Education Limited, Step 1.9 Check model with users Objective is to review the ER model with the user to ensure that the model is a ‘true’ representation of the data requirements of the organization (or the part of the organization) to be supported by the database.