INFO-SHEET # 5 Applied Associations of Data

Applied
Associations of
Data
Bulacan Date Developed:

BSIS / ACT January 2021
Polytechnic Page 1 of 14
Date Revised:
DBS - 213 College
Database System Developed by:
(Access) Document No. Minerva V. Magbitang Revision # 01
Rosemarie S. Guirre
Database Systems
List of Modules
No. MODULE
MODULE TITLE
CODE
1. Introduction to Database Management Systems DBS 213 - 1
2 The Use of DBMS and the Database DBS 213 -2
3 Nature of Data DBS 213 -3
4 Overview to MS Access DBS 213 -4
5 Applied associations of data DBS 213 -5
6 Data Models DBS 213 -6

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
MODULE CONTENT
COURSE TITLE: Database Systems (Access)
MODULE TITLE: Applied associations of data
NOMINAL DURATION: __10___ HRS (NO. of Hours per topic)
SPECIFIC LEARNING OBJECTIVES:

At the end of this module, you MUST be able to:
 Data associations
TOPIC: (SUB TOPIC)

1. Types of Association
2. Reverse Association
3. Recursive Association
ASSESSMENT METHOD/S:
Quiz, Oral Recitation, Peer Learning
REFERENCES:
S. (2020a, June 7). What is an ER Diagram? Entity Relationship Diagram

(ERD). SQL Database Tutorials. https://sqldatabasetutorials.com/sql-db/er-
diagram/
S. (2020b, June 8). Database Relationship Types. SQL Database Tutorials.

https://sqldatabasetutorials.com/sql-db/database-relationship-types/
What Is an Association?/ (n.d.). Oracle. Retrieved March 22, 2021, from

https://docs.oracle.com/cd/A97335_02/apps.102/bc4j/developing_bc_project
s/bc_awhatisanassoc.htm
Recursive Relationships. (n.d.). Erwin. Retrieved March 24, 2021, from

https://erwin.com/bookshelf/public_html/2020R1/Content/User%20Guides/
erwin%20Help/Recursive_Relationships.html

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
Information Sheet
Learning Objectives:
After reading this INFORMATION SHEET, YOU MUST be able to:
1. Familiarized and discussed MS Access in creating a database.
What Is an Association?
An association defines a relationship between two entity objects based on
common attributes. The relationship can be one-to-one or one-to-many; you can
use two one-to-many associations to implement a many-to-many relationship.
The association allows entity objects to access the data of other entity objects
through a persistent reference.
Associations act independently from referential integrity constraints

Although the same type of relationship can also exist at the table level through
a foreign-key relationship or object REF, an entity object only needs an
association to access the data of another entity object. You can create
associations regardless of whether the database has the corresponding
referential integrity constraints.
Database Relationships: The Basics
https://sqldatabasetutorials.com/wp-content/uploads/2020/06/Database-Relationships-1-768x432.png
Purpose of the Database Relationships

Being able to identify the relationships between entities makes it easier to
understand the connections between different pieces of data.
Database relationships help you see how different parts of a database system
affect each other.
For example, the entities STUDENT and COURSE are related to each other.
To accurately model the business, the relationships between entities are as
important as the entities themselves.
Question: What is the relationship between student and library book?

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
Answer: A student checks out a book.
If you received a fine for a book checked out by another student, you would
certainly protest because the student who checked out the book (this is the
relationship) should also be responsible for any associated fines. This
emphasizes the importance of clarifying relationships, especially in a business
Relationships in Families
A relationship is the way in which two or more people or things are connected.
Family relationships categorize relationships between people, for example,
mother, father, aunt, and cousin.
The name of the relationship tells us how the family members are connected.
Relationships in Data Models

Relationships:
 Represent something of significance or importance to the business
 Show how entities are related to each other
 Exist only between entities (or one entity and itself)
 Are bi-directional
 Are named at both ends
 Have optionality
 Have cardinality
What is Optionality in a Relationship?
 Relationships are either mandatory or optional.
 Consider the two entities EMPLOYEE and JOB.
 Based on what you know about instances of the entities, you can
determine optionality by answering two questions:
 Must every employee have a job?
o In other words, is this a mandatory or optional relationship for an
employee?
 Must every job be assigned to an employee?
o In other words, is this a mandatory or optional relationship for a
job?
The answer to these questions may vary from one organization to another,
depending on the business rules, but generally, if you are an employee, you
would have a job.
It is possible however that there will be jobs in the organization that is currently
not filled or are obsolete, so will not be held by any employees.

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
What is Cardinality in a Relationship?
 Cardinality measures the quantity of something.
 In a relationship, it determines the degree to which one entity is related to
another by answering the question, “How many?”
For example:
 How many jobs can one employee hold? One job only? Or more than one
job?
 How many employees can hold one specific job? One employee only? Or
more than one employee?
Note: The cardinality of a relationship only answers whether the number is
singular or plural; it does not answer with a specific plural number.
Again, different organizations may have different business rules that
define this relationship.
In general, however, each employee will hold one job, and each job may be held
by zero or more employees.
Optionality and Cardinality

Examples:
 Each EMPLOYEE must hold one and only one JOB

 Each JOB may be held by one or more EMPLOYEEs
 Each PRODUCT must be classified by one and only one PRODUCT TYPE
 Each PRODUCT TYPE may classify one or more PRODUCTs
Optionality: Must or may?
Cardinality: How many?
It is often necessary to add a small “s” to the end of the second entity name to
make the sentence more readable.
What Are Database Relationships

 Each SEAT may be sold to one or more PASSENGERs
 Each PASSENGER may purchase one SEAT
 SEAT is sold to a PASSENGER (or PASSENGERs — hence, overbooking)
 PASSENGER purchases or books a SEAT

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
Have you ever been scheduled for an airplane flight and heard the check-
in desk attendant ask if anyone wanted to give up their seat because the
plane was overbooked? Why does an airline sell one seat to two people? Is
every seat sold to more than one person? Why does it happen sometimes
and not all the time? Is it normal for a person to buy more than one seat
for themself on a plane? Is it possible that some seats will not be sold to a
passenger?
The answer to these questions will depend on the business rules for the
organization you are modeling
Business Scenario 1
 What are the relationships in the following business scenario?
 “In our restaurant, a customer walks up to the counter and places their
order. A customer can order for him or herself only, or for him/herself and
others. For example, a mother orders for herself and her children.
 We consider the mother to be the customer who owns the order and is
responsible for payment. Over a period of time, a customer can place as
many orders as he wants.”
 CUSTOMER places ORDERs: optionality and cardinality
 Optionality = Must or may?
 Each ORDER must be placed by one (and only one) CUSTOMER.
 Each CUSTOMER must place one or more ORDERs.
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/Business-Scenario-1-Relationships.png
Business Scenario 2
 A relationship can join one entity to itself.
 Examine the following scenario:
o “We need to keep track of our employees and their managers. Every
employee has one manager, including the managing director who
manages him/herself. Each manager can manage several
employees.”.
o Since managers are also employees, both are listed in the same
entity: EMPLOYEE.

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
Entity Relationship Diagram
It is possible that more than one relationship can exist between entities.
Example: different relationships exist between person and class (attend, teach,
write). Well, this article is all about constructing ER Diagram components that
represent entities, relationships, and attributes.
Shared Convention – ER Diagram

It is efficient to communicate information in a way that can be easily understood
by many people.
ER diagramming is like that — you may say or write things differently because
of the way you speak, your accent, and so on, but everyone draws ER diagrams
according to the same conventions.
Another example is International Sign Language – it is another way for people to
communicate without even talking out loud!
HR System: EMPLOYEEs, JOBs, and DEPARTMENTs

 “We need to store data about each of our company’s employees. We need
to track each employee’s first name, last name, hire date, and salary. For
each employee on commission, we also need to track his/her potential
commission.”
 “Each employee is allocated a unique employee number.”
 “Our company is divided into departments. Each employee reports to a
department – for example, accounting, sales, or development.”

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
https://sqldatabasetutorials.com/wp-
content/uploads/2020/04/HR-System.png
“We need to know the department

responsible for each employee. Each
department has a unique number.”
“All employees hold a job, and we keep
track of the job title, max and min salary
for each job. Every job has a unique job
id.”
ER Drawing Conventions
 Entities are represented by softboxes.
 Entity names go in the softboxes.
 Entity names are always singular and written with all capital letters.
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/ER-Drawing-Conventions.png
Drawing Conventions
 Attributes are listed under the entity names.
 Mandatory attributes are marked with an asterisk: “*”
 Optional attributes are marked with a circle: “o”
 Unique identifiers are marked with a hash sign: “#”
 Relationships are lines that connect entities.
 These lines are either solid or dashed.
 These lines terminate in either a “single toe” or a “crow’s foot” at the end
of each entity.
 You will learn the specific details about relationship lines in the next
lesson.
Date Revised:
DBS - 213 College
Rosemarie S. Guirre
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/Drawing-Conventions.png
Any attribute that is part of the UID is always mandatory.
It is convention to draw it with only the “#” symbol before the name. The “*” is
not required because it is implied by the Unique Identifier constraint
Database Relationship Types

One-to-Many (1:M) Relationships
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/One-to-Many-1-M-Relationships.png
 The various types of 1:M relationships are most common in an ER Model.

 You have seen several examples already.

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/One-to-Many-1-M-Relationships-1.png
”Many” can mean one-or-more or zero-or-more, depending on the optionality.
Mandatory at both ends: This type of relationship typically models entities that
cannot exist without each other. This usually represents an ideal situation—we
cannot have ORDER ITEMs without ORDERs.
Mandatory on the one side, optional on the many side: This is rarely used. You
will see it only when the relationship expresses that an entity instance exists
only when it is a nonempty set, and where the elements of the set can exist
independently. A MUSICIAN may be part of one BAND. A BAND is of no interest
if it is empty. How can you have a BAND without MUSICIANs?
Many-to-Many (M:M) Relationships
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/Many-to-Many-M-M-Relationships.png
 The various types of M:M relationships are common, particularly in a first

version of an ER model.
 In later stages of the modeling process, all M:M relationships will be
resolved, and disappear
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/Many-to-Many-M-M-Relationships-1.png

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
One-to-One Relationships For Roles
https://sqldatabasetutorials.com/wp-content/uploads/2020/04/One-to-One-Relationships-For-Roles.png
 Usually you will find just a few of the various types of 1:1 relationships in
every ER model.
 Mandatory at one end of the 1:1 relationship commonly occurs when
roles are modeled.
Alternatively, TEACHER and STUDENT could have been modeled as subtypes

of PERSON, unless a PERSON can be both a TEACHER and a STUDENT at the
same time.
One-to-One Relationships For Processes

1:1 relationships (of all three variations) also occur when some of the entities
represent various stages in a process.

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
Redundant Relationships
 A redundant relationship can be derived from another relationship in the
model.
 In this example, you can derive the relationship from PERSON to
COUNTRY from the other two relationships (COUNTRY to TOWN, TOWN
to PERSON), so you should remove the direct relationship from
COUNTRY to PERSON.
 However, be careful of concluding that a relationship is redundant based

on the structure alone.
 Read the relationships to check.
 The ERD shown here does not reflect a redundant relationship.
The relationship on the right tells us the country

of a PERSONs birth, and the relationship on the
left tells us the TOWN and COUNTRY that a
person currently lives in. It is possible that
someone could be living in a different COUNTRY
from where they were born.

Date Revised:
DBS - 213 College
Rosemarie S. Guirre
Recursive association
A recursive relationship is a non-identifying relationship between two entities
or tables that represents the fact that one company can own another company.
In this type of relationship, the parent entity or table and the child entity or
table are the same. You can create these two types of recursive relationships:
Hierarchical Recursive (single-table recursion). In this type of relationship, a

parent entity or table can have any number of children, but a child can only
have one parent.
Network Recursive (double-table recursion). In this type of relationship, a
parent entity or table can have any number of children, and a child can have
any number of parents.
In network recursion, an entity or table has a many-to-many relationship with
itself. When a many-to-many network recursion problem exists, you can clarify
the situation by creating an intermediate entity or table and converting the
many-to-many relationship into two one-to-many relationships. In both types
of recursive relationships, you must assign rolenames to migrating foreign keys
to capture the meaning of the recursive relationship.
A recursive relationship must be a non-identifying relationship for these

reasons:
In an identifying relationship, the primary key of the parent would become a

subset of the primary key of the child.
The key attributes or columns could not have a NULL value.
The entity or table would be a parent of itself. The migrated key would
perpetually migrate.

Date Revised:
DBS - 213 College
Rosemarie S. Guirre

INFO-SHEET # 5 Applied Associations of Data

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

INFO-SHEET # 5 Applied Associations of Data

Uploaded by

Copyright:

Available Formats

Applied

Bulacan Date Developed:

1. Introduction to Database Management Systems DBS 213 - 1

2 The Use of DBMS and the Database DBS 213 -2

3 Nature of Data DBS 213 -3

4 Overview to MS Access DBS 213 -4

5 Applied associations of data DBS 213 -5

6 Data Models DBS 213 -6

Bulacan Date Developed:

COURSE TITLE: Database Systems (Access)

MODULE TITLE: Applied associations of data

NOMINAL DURATION: __10___ HRS (NO. of Hours per topic)

SPECIFIC LEARNING OBJECTIVES:

TOPIC: (SUB TOPIC)

S. (2020a, June 7). What is an ER Diagram? Entity Relationship Diagram

S. (2020b, June 8). Database Relationship Types. SQL Database Tutorials.

What Is an Association?/ (n.d.). Oracle. Retrieved March 22, 2021, from

Recursive Relationships. (n.d.). Erwin. Retrieved March 24, 2021, from

Bulacan Date Developed:

Associations act independently from referential integrity constraints

Database Relationships: The Basics

Purpose of the Database Relationships

Bulacan Date Developed:

Relationships in Data Models

Bulacan Date Developed:

Optionality and Cardinality

 Each EMPLOYEE must hold one and only one JOB

What Are Database Relationships

Bulacan Date Developed:

Bulacan Date Developed:

Shared Convention – ER Diagram

HR System: EMPLOYEEs, JOBs, and DEPARTMENTs

Bulacan Date Developed:

“We need to know the department

Database Relationship Types

 The various types of 1:M relationships are most common in an ER Model.

Bulacan Date Developed:

”Many” can mean one-or-more or zero-or-more, depending on the optionality.

Many-to-Many (M:M) Relationships

 The various types of M:M relationships are common, particularly in a first

Bulacan Date Developed:

Alternatively, TEACHER and STUDENT could have been modeled as subtypes

One-to-One Relationships For Processes

Bulacan Date Developed:

 However, be careful of concluding that a relationship is redundant based

The relationship on the right tells us the country

Bulacan Date Developed:

Hierarchical Recursive (single-table recursion). In this type of relationship, a

A recursive relationship must be a non-identifying relationship for these

In an identifying relationship, the primary key of the parent would become a

Bulacan Date Developed:

You might also like

NOMINAL DURATION: 10_ HRS (NO. of Hours per topic)