IE 3425 Eng’g.

Database
Lecture 4 Examples
Topics: Bridge
(Composite) Table, CPK, Recursive Relationship, ERD,
Relational Schema, DB Design Goals, DB Design
Development Process

© Professor Zeid, Northeastern University

 Many to Many (M:N) Relationships in
Databases
 By definition, a many-to-many relationship is where more than
one record in a table is related to more than one record in
another table.
 A many-to-many relationship refers to a relationship between
tables in a database when a parent row in one table contains
several child rows in the second table, and vice versa.
 Many-to-many relationships are often tricky to represent.
 The many-to-many relationship is usually a mirror of the real-
life relationship between the objects the two tables represent.
 M:N Relationships
For a many to many relationship, consider the following points:
 It cannot be implemented “as is” in a relational model.
 It can be changed into two 1:M relationships.
 It can be implemented by breaking the relationship up to produce a
set of 1:M relationships.
 It involves the implementation of a composite table.
 The composite table must contain at least the primary keys of the
original tables.
 The linking table contains multiple occurrences of the foreign key
values.
 Additional attributes may be assigned as needed.
 It can avoid problems inherent in an M:N relationship by creating a
composite table or bridge table.
Bridge (Composite) Table
 Good DB design stores simple single-valued attributes in DB tables
 Bad DB design stores multi-valued attributes in DB tables
 If your first pass of a DB design uses multi-valued attributes, then
redesign to use single-valued attributes
 Multi-valued attributes are also associated with M:N relationships. So,
we always break up M:N relationship to multiple 1:M relationships
(usually)
 Using multi-valued attributes in tables indicates that you are jamming
too many things into one table
 See Example 1
 Example 1: Bridge (Composite) Table

employee
employee_id employee_last_na employee_first_na employee_degree
me me
100 Zeid Abe BS, MS, PhD

THINK: 1) What is the problem with this design?

2) What would be your solution?
 Example 1: Bridge (Composite) Table

employee
employee_id employee_last_na employee_first_na employee_degree
me me
100 Zeid Abe BS, MS, PhD

Problem: Multi-valued attribute in table (employee_degree)

Solution: 1) Add multiple degree fields – degree 1, degree 2, etc. NOT GOOD
2) Remove degree field column and expand design
 Example 1: Bridge (Composite) Table
New Design:
employee degree
employe employee_a employee_fir degree_id degree_name
e_id st_lname st_name
100 Zeid Abe
BS Bachelor
MS Master
PhD Doctoral
AS Associate
employee _ degree
Bridge table allows for
Bridge Table → employ degree degree_dat
ee_id _id e
additional data to be
always has CPK included
100 BS
consisting of 2 or Example – degree date
100 MS
more attributes attribute
100 PhD
Example 2: Bridge (Composite) Table
professor
professo professor_las professor_fir professor_co
r_id t_name st_name urses

1000 Newton Isaac 7205,7700,

6900,7900
1001 Einstein Albert 7205,7700,
6900,7900

In a university database, let us look at the professor and course tables.

Newton and Einstein both teach all the courses listed in the course table, i.e.,
course 7205 is taught by both Einstein and Newton. Newton and Einstein similarly
also teach the other 3 courses.
- How would you represent this relationship?
professor
Example 2: Redesign course
professo professor_las professor_fir course_id course_name
r_id t_name st_name 7205 Math 1

1000 Newton Isaac 7700 Math 2

6900 Advanced
1001 Einstein Albert Mathematics
7900 Doctoral
Dissertation

Bridge Table → professor_id course_id professor_course_classroom

1000 7205 Snell Eng 110
For multi-valued data in
1000 7700 Shillman 302
the professor_course
1000 6900 ISEC 100 attribute from the
1000 7900 … professor table, the
redesign involves creating
1001 7205 … a course table, and a
1001 7700 … bridge table for
6900 … professor_course
1001
1001 7900 …
CPK (Composite PK)
 You may need to combine 2 or more table attributes to
uniquely identify a row
 In such case, the table has CPK (Composite PK)
 Class discussion
 How often is CPK used in practice?
 What happens if you use a PK instead of CPK?
Recursive Relationship
 A relationship between two entities of a similar entity type is called
a recursive relationship
 Exists if an entity can be related to itself
 A recursive relationship could be 1:1, 1:M, M:N
 1:M recursive relationships are most common
 *We break up the multi-valued attribute as we did with the bridge table,
but without the need for a bridge table
 Examples
 Example 3: 1:1 recursive relationship
 Example 4: 1:M recursive relationship
 Example 5: M:N recursive relationship
Example 3: 1:1 Recursive Relationship
1 married
Marriage Relationship to
person
1

person
person_id person_last_name person_first_name person_spouse

100 Smith Abe 120

110 Clinton James

120 Brown Mary 100

 Class discussion
Example 4 : M:N Recursive Relationship
employee
employee_id employee_ln employee_f employee_ma M
ame name nage employee
100 N

110
120 100, 130
130

course
course_number course_name course_prerequisite M
course
MATH100 Math 1 N
MATH200 Math 2 MATH100
MATH300 Math 3 MATH200
MATH400 Math 4 MATH300, PHYS400
Class discussion
Example 5: 1:M Recursive Relationship M manage
s
employee
employee manager 1
employe employ employee_f employee_l manager employ manager_d manager_expert
e_id ee_id name name _id ee_id ate ise
100 1 1 120

110 2
3
120
130 1
M requires
prerequisite
course course
1
course_number course_name course_number prerequisite_course
MTH100
MTH200 MTH100
MTH200
MTH300 MTH200
MTH300
MTH400 MTH300
MTH400
MTH400 PHYS450
 Entity Relationship Diagram (ERD)
 We use ERD and relational schema as DB design and documentation tools
 An ERD uses symbols and documents the entity (table) relationships and
their types
 An entity relationship diagram (ERD) shows the relationships of entity
sets stored in a database.
 An entity in this context is an object, a component of data. An entity set
is a collection of similar entities. These entities can have attributes that
define its properties.
 ERD Symbols
• Visio, Lucid Entity (table) lower case
Chart, and
Draw.io are good
tools to draw
ERD symbols
Bridge (composite) table
• Powerpoint can lower case
also be used to Indicates M:N relationship
draw ERD
• Microsoft Word Relationship (activity)
is NOT a good Lowercase verb
tool for
drawing.
Optional Relationship

Lucid Chart: https://www.lucidchart.com/pages/

Draw.io: https://www.diagrams.net/
Both are free and web-based.
Connectivity and Cardinality
 In addition to its symbols, an ERD displays connectivity and cardinality of each
relationships
 Connectivity shows relationship type (1:1,1:M, M:N)
 Cardinality is the number of occurrences of an entity in the related entity
written as (x, y) where x and y are the min and max occurrences respectively
 Always read an ERD from the “1” side, not the “M” side
 Examples
 Example 6: detailed ERD example
 Example 7: typical ERD example
 Example 8: ERD using a bridge table
 Example 9: ERD for Recursive Relationship
 Connectivity
shows
Example 6: ERD relationship
type, i.e.,
1:1
Entity (table) lower case

Bridge (composite) table 1

lower case 1 is
employee (0,1) (1,1) seller
Indicates M:N relationship

Relationship (activity)
Lowercase verb
Cardinality is the # of
Optional Relationship occurrences of an entity
in the related entity
written as (x,y) where x is
the lower limit (min) and
y is the upper limit (max)
Class discussion
Example 7: ERD

connectivity

1 M
customer generate invoice
(1, N) (1, 1)

has cardinality

address Class discussion

 Example 8: ERD for Bridge Table

1 M employee_ M 1
employee (1,N)
has
(1,1) degree (1,1)
belongs
to (1,N)
degree

THINK: What do the connectivity and cardinality

values mean?
Class discussion
Example 9: ERD for Recursive Relationship

1 M
manager manage employee
(1, N) (1, 1)
1 (1, 1) (1, 1) 1

is
Relational Schema
 ERD has a problem; it shows only tables and their relationships, but no attributes or
keys
 Relational schema solved this problem; it shows the attributes of each table and their
PKs, CPKs, and/or FKs
 Relational schema complements ERD by showing more details
 sketch relational schema manually or create it in Access

 This url lists multiple free charting tools: https://www.holistics.io/blog/top-5-free-

database-diagram-design-tools/
 Use Lucidchart to create relationship schema diagram (there is free version):
https://www.lucidchart.com/
 Below is an example for lucidchart relationship schema diagram
 Examples
 Example 10: sketch relational schema manually
 Example 10: Sketching Relational
Schema
By Hand:
customer invoice

customer_id 1 invoice_num
ber
customer_firs M
customer_id
t_name
customer_las invoice_date
t_name
THINK: 1) What does the underline indicate?
2) How would you sketch relational schema for a
recursive relationship?
DB Design Goals
 DB design goals are
 Information
 Transaction speed
 Redundancy
 Maintainability
 Expandability
 These goals conflict with each other; do your best as a DB designer
DB Design/Development Process
 3 Steps
1. Study description and operations
2. Generate business rules; identify system, objects (tables) and attributes
in this step
3. Sketch ERD and relations schema