1. Introduction to Databases
Copyright by John Wiley and Sons, 2006
Introduction to Databases
Chapter 4:
Designing a Database

2. Designing Relational Tables
Copyright by John Wiley and Sons, 2006
Designing Relational Tables
Typical process for converting E-R diagrams to relational tables:
Each entity converts to table
For many-to-many relationships, each associative entity converts to table
Attributes become table columns
Ensure foreign keys appear in proper places in tables
To convert single entity, create table of same name with column for each attribute

3. Salesperson Entity and Table
Copyright by John Wiley and Sons, 2006
Salesperson Entity and Table

4. Converting Binary Relationships
Copyright by John Wiley and Sons, 2006
Converting Binary Relationships
Greater importance in selecting identifier and primary key
Identifier and primary key define foreign key that establishes relationships between tables
Often more than one way to represent entity relationships as relational tables

5. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship

6. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship

7. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship

8. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship
Converting one-to-one Salesperson/Office relationship
Options:
Convert relationship to single/combined table
Convert relationship to two tables

9. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship
Considerations:
Business environment considers Salesperson and Office as separate entities
Modality of zero at Salesperson entity in E-R diagram (office may have no one assigned)
Salesperson entity in E-R diagram has relationships with other entities

10. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship
Solution 1:
Combine two entities into one table

11. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship
Solution 2:
Two separate tables
Office Number as foreign key in Salesperson table

12. Example: Converting 1-1 Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Binary Relationship
Solution 3:
Two separate tables
Salesperson Number as foreign key in Office table

13. Example: Converting 1-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-M Binary Relationship

14. Example: Converting 1-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-M Binary Relationship
Each occurrence of Salesperson is related to zero or more occurrences of Customer
Unique identifier of entity on “one” side is placed as foreign key in entity of “many” side

15. Example: Converting 1-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-M Binary Relationship

16. Example: Converting M-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Binary Relationship

17. Example: Converting M-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Binary Relationship
Most relational DBMS systems do not directly support many-to-many relationships
Solution: Include associative entity to establish relationship
May use composite key as primary key in associative entity

18. Example: Converting M-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Binary Relationship

19. Example: Converting M-M Binary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Binary Relationship

20. Example: Converting 1-1 Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Unary Relationship

21. Example: Converting 1-1 Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-1 Unary Relationship
With:
Only one entity type involved, and
One-to-one relationship
Conversion requires only one table

22. Example: Converting 1-M Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-M Unary Relationship

23. Example: Converting 1-M Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting 1-M Unary Relationship

24. Example: Converting M-M Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Unary Relationship
Many-to-many unary relationship:
For example: one product can be constructed out of set or subset of other products
General rule in conversion:
Number of tables equal to number of entity types plus one more table for many-to-many relationship
M-M unary relationship - 2 tables
M-M binary relationship - 3 tables
M-M ternary relationship - 4 four tables

25. Example: Converting M-M Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Unary Relationship

26. Example: Converting M-M Unary Relationship
Copyright by John Wiley and Sons, 2006
Example: Converting M-M Unary Relationship

27. Example: Good Reading Bookstores
Copyright by John Wiley and Sons, 2006
Example: Good Reading Bookstores

28. Example: Good Reading Bookstores
Copyright by John Wiley and Sons, 2006
Example: Good Reading Bookstores

29. Example: Good Reading Bookstores
Copyright by John Wiley and Sons, 2006
Example: Good Reading Bookstores

30. Copyright by John Wiley and Sons, 2006
Normalizing Data
Data normalization: Methodology for organizing attributes into tables to eliminate redundancy among nonkey attributes
Goals:
Each resultant table describes single entity type or single many-to-many relationship
Foreign keys appear exactly where needed
Properly structured relational database

31. Normalization Techniques
Copyright by John Wiley and Sons, 2006
Normalization Techniques
Two types of input needed for data normalization process
List of all attributes to be incorporated in database, including intersection data attributes
List of functional dependencies: all defining associations between attributes
In functional dependencies, one attribute (determinate attribute) defines value of another attribute
Salesperson Number → Salesperson Name

32. Salesperson Entity Attributes
Copyright by John Wiley and Sons, 2006
Salesperson Entity Attributes

33. Salesperson Entity Functional Dependencies
Copyright by John Wiley and Sons, 2006
Salesperson Entity Functional Dependencies

34. Example: Defining Attributes and Functional Dependencies
Copyright by John Wiley and Sons, 2006
Example: Defining Attributes and Functional Dependencies
Quantity is defined by two combined attributes
Manager is defined independently by two attributes
Department Number and Salesperson Number
Salesperson Number also defines Department Number

35. Copyright by John Wiley and Sons, 2006
Normalizing Data
Normal forms: Rules for data normalization
Three main normal forms
First normal form
Second normal form
Third normal form
Normalization:
Uses normal forms to step through “decomposition process” that decomposes attributes into subgroups
In third normal form, group of tables is well-structured relational database with no data redundancy

36. Copyright by John Wiley and Sons, 2006
Normalizing Data
First normal form:
Eliminates multiple values
Second normal form:
Eliminates partial functional dependencies (data dependent on part of primary key)
Every nonkey attribute must be fully functionally dependent on entire key of table
Third normal form:
Eliminates transitive dependencies (one nonkey attribute is functionally dependent on another)
Nonkey attributes are not allowed to define other nonkey attributes

37. Example: Unnormalized Data
Copyright by John Wiley and Sons, 2006
Example: Unnormalized Data

38. Copyright by John Wiley and Sons, 2006
First Normal Form

39. Copyright by John Wiley and Sons, 2006
Second Normal Form

40. Copyright by John Wiley and Sons, 2006
Third Normal Form

41. Copyright by John Wiley and Sons, 2006
Denormalizing Data
Denormalizing may be needed when:
Normalization has been taken to extreme
Too many small tables creating more work and storage space
E.g. Using State table to be referenced instead of entering two-digit code)
More efficient data retrieval is needed:
Many queries requiring resource-intensive joining
In denormalizing, you join two or more tables into one less normalized table

42. Copyright by John Wiley and Sons, 2006
Summary
In converting E-R diagrams to relational tables, each entity typically converted into table, with attributes as table columns.
Considerations in conversion: Business needs, cardinalities, modalities, and defining foreign keys to establish relationships.
Normalization: Uses three main normal forms to step through “decomposing” attributes into subgroups that allow data redundancies to be eliminated.
Denormalizing may be needed in cases where storage space and speed of data retrieval are important factors.

43. Copyright by John Wiley and Sons, 2006
Key Terms
Composite key
Data integrity
Data normalization
Decomposition process
Defining association
Determinant attribute
Exception conditions
First normal form
Functional dependency
Joining
Non-loss decomposition
Normal forms
Null value
Partial functional dependency
Referential integrity
Relational integrity
Second normal form
Third normal form (3NF)
Transitive dependency

44. Copyright by John Wiley and Sons, 2006
Copyright Notice
Copyright 2008 John Wiley & Sons, Inc. All rights reserved. Reproduction or translation of this work beyond that permitted in section 117 of the 1976 United States Copyright Act without express permission of the copyright owner is unlawful. Requests for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the information herein.