2. 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
4. 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
8. 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
• 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
• Solution 1:
– Combine two entities into one table
11. 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
• Solution 3:
– Two separate tables
– Salesperson Number as foreign key in Office
table
14. 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
17. 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
21. Example: Converting 1-1 Unary Relationship
• With:
– Only one entity type involved, and
– One-to-one relationship
• Conversion requires only one table
24. 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
30. 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
• Two types of input needed for data
normalization process
1. List of all attributes to be incorporated in database,
including intersection data attributes
2. 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
34. 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. 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. 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
41. 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. 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. 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