Concepts of Database Management, Fifth Edition Chapter 6: Database Design 2: Design Methodology

2 Concepts of Database Management, 5t h Edition Objectives u Discuss the general process and goals of database design u Define user views and explain their function u Define database design language and use it to document database designs u Create an entity-relationship diagram to visually represent a database design u Present a methodology for database design at the information level and view examples illustrating this methodology

3 Concepts of Database Management, 5t h Edition Objectives u Explain the physical-level design process u Discuss top-down and bottom-up approaches to database design and examine the advantages and disadvantages of both methods u Use a survey form to obtain information from users prior to beginning the database design process u Review existing documents to obtain information prior to beginning the database design

4 Concepts of Database Management, 5t h Edition Objectives u Discuss special issues related to implementing one-to-one relationships and many-to-many relationships involving more than two entities u Discuss entity subtypes and their relationships to nulls u Learn how to avoid potential problems when merging third normal form relations u Examine the entity-relationship model for representing and designing databases

5 Concepts of Database Management, 5t h Edition Database Design u Information-level Design – building a database that satisfies the organization’s requirements as cleanly as possible u Physical-level design – designers transform the information-level design into a design for the specific DBMS used by the organization u User Views – requirements necessary to support a particular user’s operations u Cumulative design – supports all user views encountered so far in the design process

6 Concepts of Database Management, 5t h Edition Information-Level Design Methodology u Information-level Design Methodology l Represent user view as collection of tables l Normalize these tables l Identify all keys l Merge the result into design

7 Concepts of Database Management, 5t h Edition Represent User View as Collection of Tables Step 1: Determine entities involved and create separate table for each type Step 2: Determine primary key for each table Step 3: Determine properties for each entities Step 4: Determine relationships among entities

8 Concepts of Database Management, 5t h Edition Types of Relationships u One-to-Many Relationships – created by including the primary key of the “one” table as a foreign key in the “many” table u Many-to-Many Relationships – created with a new table whose primary key is the combination of the primary keys of the original tables u One-to-One Relationship – created with a single relationship from one record in a table to a single record in another table

9 Concepts of Database Management, 5t h Edition Normalize the Tables u Represent all keys l Primary, alternate, secondary, foreign u Database Design Language (DBDL) l Mechanism for representing tables and keys DBDL Example Figure 6.1

10 Concepts of Database Management, 5t h Edition Types of Primary Keys u Three types of primary keys used in database design 1. Natural key (logical key or intelligent key) – consists of a column that uniquely identifies an entity 2. Artificial key – column created for an entity to serve solely as the primary key; visible to users 3. Surrogate key (synthetic key) – system-generated primary key usually hidden from users

11 Concepts of Database Management, 5t h Edition DBDL Notation u Table name followed by columns in parentheses l Primary key column(s) underlined u AK identifies alternate keys u SK identifies secondary keys u FK identifies foreign keys

12 Concepts of Database Management, 5t h Edition Entity-Relationship Diagrams u Diagram that visually represents database structure l Rectangle represents each entity in the E-R diagram u Primary key for each entity appears above the line in the rectangle for each entry

13 Concepts of Database Management, 5t h Edition Entity-Relationship Diagrams u Other columns that comprise each entity appear below the line within each rectangle u The letters AK, SK, and FK appear in parentheses following the alternate key, secondary key, and foreign key respectively u For each foreign key, there is a line leading from the rectangle that corresponds to the table being identified to the rectangle that corresponds to the table containing the foreign key

14 Concepts of Database Management, 5t h Edition Figure 6.2: Entity-Relationship Diagrams

15 Concepts of Database Management, 5t h Edition Merge the Result into the Design u As soon as Steps 1 through 3 for a given user view have been completed, the results can be merged into the cumulative design l If the working view is the first user view, the cumulative design will be identical to the design for the first user l Otherwise, all the tables for this user with those that are currently in the cumulative design

16 Concepts of Database Management, 5t h Edition Merge the Result into the Design (con’t) u Next, you combine tables that have the same primary key to form a new table l New table has the same primary key as those tables you have combined l New table also contains all the columns from both tables l In the case of duplicate columns, you remove all but one copy of the column

17 Concepts of Database Management, 5t h Edition Figure 6.4: User View Examples View #1: Sales Rep View Rep (RepNum, LastName, FirstName, Street, City, State, Zip, Commission, Rate)

18 Concepts of Database Management, 5t h Edition View #2: Customer View Figure 6.5: User View Examples

19 Concepts of Database Management, 5t h Edition Entities u Independent entity - an entity that does not require a relationship to another entity for identification u Dependent entity - an entity that does require a relationship to another entity for identification

20 Concepts of Database Management, 5t h Edition Physical-Level Design u Undertaken after information-level design completion u Most DBMSs support primary, candidate, secondary, and foreign keys u DB programmers must include logic to ensure the uniqueness of primary keys and enforce other conditions

21 Concepts of Database Management, 5t h Edition Top-Down vs. Bottom-Up u Bottom-up l Design starts at low level l Specific user requirements drive design process u Top-down l Begins with general database that models overall enterprise l Refines the model until design is achieved

22 Concepts of Database Management, 5t h Edition Survey Form u Used to collect information from users u Must contain particular elements l Entity information l Attribute information l Relationships l Functional dependencies l Processing information

23 Concepts of Database Management, 5t h Edition Existing Documents u Aid in collecting user requirements u Collect information similar to that collected with survey forms l Entity information l Attribute information l Relationships l Functional dependencies l Processing information

24 Concepts of Database Management, 5t h Edition Figure 6.14: Example Invoice

25 Concepts of Database Management, 5t h Edition Figure 6.15: List of Possible Attributes

26 Concepts of Database Management, 5t h Edition Figure 6.16: Tentative List of Functional Dependencies

27 Concepts of Database Management, 5t h Edition Figure 6.17: Revised List of Functional Dependencies

28 Concepts of Database Management, 5t h Edition Figure 6.18: Tentative List of Entities

29 Concepts of Database Management, 5t h Edition Figure 6.19: Expanded List of Entities

30 Concepts of Database Management, 5t h Edition One-to-One Relationship Considerations u Implementing a one-to-one relationship by simply including the primary key of each table as a foreign key in the other table l A problem is that there is no guarantee that the information will match

31 Concepts of Database Management, 5t h Edition One-to-One Relationship Considerations (con’t) u One possible solution is to create a single table l Although workable, two features are not particularly attractive: 1. Combines columns of two different entities into a single table 2. If possible for one entity to exist without the other

32 Concepts of Database Management, 5t h Edition One-to-One Relationship Considerations (con’t) u Better solution l Create two separate tables for customers and sales reps and to include the primary key of one of them as a foreign key in the other l This foreign key would also be designated as an alternate key

33 Concepts of Database Management, 5t h Edition Figure 6.20: 1:1 Relationship Considerations Include primary key of each table as foreign key in the other

34 Concepts of Database Management, 5t h Edition Figure 6.21: 1:1 Relationship Considerations Implementation when information does not match

35 Concepts of Database Management, 5t h Edition Figure 6.22: 1:1 Relationship Considerations Implemented in a single table

36 Concepts of Database Management, 5t h Edition Figure 6.23: 1:1 Relationship Considerations 1:1 relationship implemented by including primary key of one table as foreign key (and alternative key) in the other

37 Concepts of Database Management, 5t h Edition Many-to-Many Relationship Considerations u Complex issues arise when more than two entities are related in a many-to-many relationship u Many-to-many-to-many relationship – involves multiple entities u Crucial issue in making the determination between a single many-to-many-to-many relationship and two (or three) many-to-many relationships is the independence

38 Concepts of Database Management, 5t h Edition Figure 6.24: M:M Relationship Considerations Sample Sales Data

39 Concepts of Database Management, 5t h Edition Figure 6.25: M:M Relationship Considerations Result obtained by splitting Sales table into three tables

40 Concepts of Database Management, 5t h Edition Figure 6.26: M:M Relationship Considerations Result obtained by joining three tables--2 rows are in error. Must be converted to 4NF

41 Concepts of Database Management, 5t h Edition Nulls u Null - a special value u Null - actually represents the absence of a value in a field u Nulls - used when a value is either unknown or inapplicable

42 Concepts of Database Management, 5t h Edition Nulls are absence of values Figure 6.27: Table Split To Avoid Nulls

43 Concepts of Database Management, 5t h Edition Figure 6.28: Sample DBDL

44 Concepts of Database Management, 5t h Edition Entity Subtypes u Entity subtype – table that is a subtype of another table u Incomplete category – records that do not fall into the subtype u Complete categories – all records fall into the categories

45 Concepts of Database Management, 5t h Edition Figure 6.29: Entity Subtypes

46 Concepts of Database Management, 5t h Edition Figure 6.32: Two Entity Subtypes— Incomplete Categories

47 Concepts of Database Management, 5t h Edition Figure 6.33: Two Entity Subtypes— Complete Categories

48 Concepts of Database Management, 5t h Edition Avoiding Problems with 3NF When Merging Tables u When combining third normal form tables, the result need not be in third normal form u To avoid the problem of creating a table that is not in third normal form, be cautious when representing user views u If you always attempt to determine whether determinants exist and include them in the tables, the problem is often avoided

49 Concepts of Database Management, 5t h Edition Entity-Relationship Model u An approach to representing data in a database u Entities are drawn as rectangles u Relationships are drawn as diamonds with lines connecting the entities involved in relationships

50 Concepts of Database Management, 5t h Edition Figure 6.34: One-to-many relationship

51 Concepts of Database Management, 5t h Edition Figure 6.35: Many-to-Many Relationship

52 Concepts of Database Management, 5t h Edition Figure 6.36: Many-to-Many Relationship

53 Concepts of Database Management, 5t h Edition Figure 6.37: One-to-Many Relationship

54 Concepts of Database Management, 5t h Edition Figure 6.38: Many-to- Many Relationship with Attributes

55 Concepts of Database Management, 5t h Edition Composite Entity u Composite entity - an entity that exists to implement a many-to-many relationship l Essentially both an entity and a relationship l Represented in an E-R diagram by a diamond within a rectangle

56 Concepts of Database Management, 5t h Edition Figure 6.39: Composite Entity

57 Concepts of Database Management, 5t h Edition Figure 6.40: Complete E-R Diagram

58 Concepts of Database Management, 5t h Edition E-R Diagram with an Existence Dependency and Weak Entity u Existence dependency - when the existence of one entity depends on the existence of another related entity u Indicate an existence dependency by placing an “E” in the relationship diamond u Weak entity - an entity that depends on another entity for its own existence u A double rectangle encloses a weak entity

59 Concepts of Database Management, 5t h Edition Figure 6.41: E-R Diagram with an Existence Dependency and Weak Entity

60 Concepts of Database Management, 5t h Edition Cardinality u Cardinality - the number of items that must be included in a relationship u An entity in a relationship with minimum cardinality of zero plays an optional role in the relationship u An entity with a minimum cardinality of one plays a mandatory role in the relationship

61 Concepts of Database Management, 5t h Edition Figure 6.43: E-R Diagram that Represents Cardinality

62 Concepts of Database Management, 5t h Edition Summary u Database design is a two-part process of determining an appropriate database structure to satisfy a given set of requirements u A user view is the set of necessary requirements to support a particular user’s operations u A database design is represented in a language called Database Design Language (DBDL) u Designs can be represented pictorially using entity-relationship (E-R) diagrams

63 Concepts of Database Management, 5t h Edition Summary u Advantages to both top-down and bottom-up approaches u Survey form is useful for documenting the information gathered for database design process u One-to-One and One-to-Many relationships require attention to primary keys u Entity-relationship (E-R) model is a method of representing the structure of a database using an E-R diagram