Oracle Database Foundations

Database Foundations
3-1
More with Relationships
Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Road Map
You are here
Normalization Data Modeling

More with Tracking Data
and Business Terminology
Relationships Changes
Rules and Mapping
DFo 3-1
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. 3
Objectives
This lesson covers the following objectives:
• Identifying barred relationships
• Resolve M:M relationships
• Identify and illustrate nontransferable relationships
• Identify and draw supertype and subtype entities
• Identify hierarchical, recursive, and arc relationships
DFo 3-1
More with Relationships Copyright © 2019, Oracle and/or its affiliates. All rights reserved. 4
Identifying (Barred) Relationships
• What is the UID of the ACCOUNT entity?
ACCOUNT BANK
# Number # Number
• The UID requires both the ACCOUNT Number and the

relationship between BANK and ACCOUNT.
ACCOUNT BANK
# Number # Number
• The UID for the ACCOUNT entity is made up of ACCOUNT

Number as well as BANK Number – this is represented by
the bar on the relationship line.
DFo 3-1
Identifying Relationships with Multiple
Entities
• An entity can be uniquely identified through multiple
relationships.
WORK
ASSIGNMENT
Date Assigned
Duration
Position
EMPLOYEE PROJECT
# ID # Number
Name Title
• The UID for WORK ASSIGNMENT is EMPLOYEE ID and

PROJECT Number (represented using bars).
DFo 3-1
M:M Relationships
• Attributes describe only entities.
• If attributes describe a relationship, the relationship
must be resolved.
ORDER PRODUCT
include
# Number # ID
included in
* Date * Name
* Total ° Description
* Price
Where would you add the Quantity attribute?
DFo 3-1
Resolving M:M Relationships: Example 1
• Resolving a M:M relationship with a new intersection
entity and two 1:M barred relationships.
ORDER ORDER ITEM

# Number include * Quantity Intersection
° Date for Entity
° Total
includes
contained in
• UID of ORDER ITEM PRODUCT
is ORDER Number # ID
* Name
and PRODUCT ID ° Description
* Price
DFo 3-1
Intersection entity characteristics:
• The relationships from the intersection entity are always
mandatory.
• Intersection entities usually contain consumables like
quantity used and dates. They tend to be high-volume
and volatile entities.
• An intersection entity is identified by its two originating
relationships (identifying relationships).
DFo 3-1
Case Scenario: Resolving M:M Relationships
Matt, how would you resolve the
following M:M relationship between the
MEMBER and the BOOK entities?
Faculty
MEMBER BOOK
# ID # ID
* First Name take * Title
° Last Name ° Publisher ID
taken by * Author ID
* Street Address
° City
° State
° Zip
DFo 3-1
Case Scenario: Creating an Intersection
Entity
I would create an intersection entity with
identifying relationships to the originating entities.
BOOK TRN
* TRNS Date
for for
° TRNS Type
Matt
on on
MEMBER BOOK
# ID
# ID
* First Name
° Last Name * Title
* Street Address ° Publisher ID
° City * Author ID
° State
° Zip
DFo 3-1
Resolving M:M Relationships: Example 2
• The EMPLOYEE and JOB entities do not store the history
of an employee’s jobs.
EMPLOYEE JOB
# id # id
* first name * title
held
° last name ° minimum salary
° email held by ° maximum salary
* hire date
* salary
DFo 3-1
Resolving M:M Relationships Using
Intersection Entity with Barred Relationships
held for JOB HISTORY held for
° start date
° end date
hold held by
EMPLOYEE JOB
# id # id
* first name * title
° last name ° minimum salary
° email ° maximum salary
* hire date
* salary
DFo 3-1
Project Exercise 1
• DFo_3_1_1_Project
– Oracle Baseball League Store Database
– Resolving Many to Many Relationships
DFo 3-1
Non-Transferable Relationships
• Transferability is the ability of the relationship between
two instances of an entity to change over time.
• A non-transferable relationship cannot be moved
between instances of the entities it connects.
• A non-transferable relationship is represented by a
diamond on the relationship.
PERSON born in COUNTRY

birthplace of
DFo 3-1
Non-Transferable Relationships
• Non-transferable relationships can only be mandatory.
• For example, the birth country of a person is non-
transferable.
PERSON born in COUNTRY

birthplace of
DFo 3-1
Case Scenario
• A membership must be held Transferable or
by exactly one person. Non-transferable?
• The membership relationship

cannot be moved to another
person.
MEMBERSHIP held by PERSON

holds the
membership
DFo 3-1
Project Exercise 2
– Identify and Illustrate Non-Transferable Relationships
DFo 3-1
Supertype and Subtype Entities
• Supertype has a parent-child relationship with one or
more subtypes.
PK- SupertypeId
Supertype FK1- SubtypeAId
FK2- SubtypeBId
PK, FK1- Subtype A Subtype B PK,FK1-

SupertypeAId SupertypeBId
DFo 3-1
Supertype and Subtype Entities
• Subtype is a subgrouping of the entity in an entity type
which has attributes that are distinct from those in
other subgroupings.
PK- SupertypeId
Supertype FK1- SubtypeAId
FK2- SubtypeBId
PK, FK1- Subtype A Subtype B PK,FK1-

SupertypeAId SupertypeBId
DFo 3-1
Drawing a Subtype
• Each subtype is a specialization of a
INSURANCE
supertype and therefore must be id
enclosed within an entity.
HEALTH
• The common attributes and deductible
relationships for all subtypes must LIFE
be listed only in the supertype, but payout amount
they are inherited in every subtype. LIABILITY
value cap
OTHER
DFo 3-1
Drawing a Subtype
• A subtype can and would generally
INSURANCE
have attributes and relationships of its id
own.
HEALTH
• There can never be just one subtype; deductible
another subtype should be created to LIFE
contain the rest. payout amount
LIABILITY
value cap
OTHER
DFo 3-1
Characteristics of a Subtype
• A subtype:
– Inherits all attributes of the supertype.
– Inherits all relationships of the supertype.
– Usually has its own attributes or relationships.
– Is drawn within the supertype.
– Never exists alone.
– May have subtypes of its own.
– Has identical primary keys of the supertype and subtype.
DFo 3-1
Supertype and Subtype Entity: Example
Sharon wants to include types of room categories to be
reserved for the guests. For example:
• Standard
• Club
• Suite
She already has an entity named ROOM that holds room
details. This would be a supertype entity. The specific room
categories would inherit the properties of the supertype
entity, in addition to their own specific attributes. The specific
room category would be the subtype entity.
Standard Suite
Club
DFo 3-1
Generalization and Specialization
• Generalization is a bottom-up approach where two or
more lower level entities are combined to form a higher
level entity based on the common features.
VEHICLE
Bottom-Up
Approach
CAR TRUCK
DFo 3-1
Generalization and Specialization
• Specialization is a top-down approach where the higher
level entity is broken down into lower level entities.
EMPLOYEE
Top-
Down
Approach
CURRENT EX-EMPLOYEE
EMPLOYEE
DFo 3-1
Entity Subtype Rules
• Exhaustive:
– Every instance of a supertype is also an instance of one of the
subtypes.
– OTHER should be included as a subtype to categorize instances
that are not defined by one of the existing subtypes
– Example: An employee must be full time, part time, or other.
DFo 3-1
Entity Subtype Rules
• Mutually Exclusive:
– Every instance of the supertype is of one and only one subtype.
– Example: An employee cannot be both full time and part time.
DFo 3-1
Identifying Subtypes Correctly
• Is this subtype a kind of
supertype?
STAFF
• Have I covered all possible # id MANAGER
* first name * budget
cases? * last name * target
(exhaustive) * date of birth revenue
* salary
• Does each instance fit into
one and only one subtype? ORDER COOK
* training
(mutually exclusive) TAKER
* overtime
rate OTHER
DFo 3-1
Nested Subtypes Nested STAFF supertype
• You can nest HOTEL
subtypes. STAFF
MANAGER
# id
* budget
* first name
* target
* last name
revenue
* date of birth
* salary
COOK
* training
ORDER TAKER
* overtime rate OTHER
NON STAFF
# id
* first name * date of birth
* last name * salary
DFo 3-1
Project Exercise 3
– Identify and Draw Supertype and Subtype Entities
DFo 3-1
Modeling Hierarchical Data
COMPANY COMPANY
Represent hierarchical data as # ID
made up of
a set of 1:M relationships. made up of
within
within
DIVISION DIVISION
# Div ID
made up of made up of
within The UIDs for a set of within
DEPARTMENT hierarchical entities can be DEPARTMENT

propagated through multiple # Dept ID
made up of
within
barred relationships. made up of
within
TEAM TEAM
# Team ID
DFo 3-1
Recursive Relationships
• A recursive relationship is one where an entity instance
is related to another instance in the same entity.
Each EMPLOYEE may

EMPLOYEE
be managed by one
# ID
and only one
* First name EMPLOYEE
° Last name
Each EMPLOYEE may ° Manager ID managed by
be the manager of one * Job
or more EMPLOYEEs. ° Salary
the manager of
DFo 3-1
Recursive Relationships
• A recursive relationship is always modeled with a loop.
Each EMPLOYEE may

EMPLOYEE
be managed by one
# ID
and only one
* First name EMPLOYEE
° Last name
Each EMPLOYEE may ° Manager ID managed by
be the manager of one * Job
or more EMPLOYEEs. ° Salary
the manager of
DFo 3-1
Examining Recursive Relationships
Sample Instances:
ELEMENTARY washers, nuts, bolts, fan
PART blade, fan belt, radiator cap,
hoses, thermostat
Sample Instances: Sample Instances:

fan, radiator, SUBASSEMBLY ASSEMBLY cooling system,
ignition module, ignition system,
carburetor, fuel system, engine
automatic choke
PRODUCT
Sample Instances:
car, truck, cab, tractor
trailer rig
DFo 3-1
Generic Modeling
• Another way to model a Bill of Materials recursive
relationship is to create a generic COMPONENT entity.
• This would create a recursive M:M relationship
COMPONENT
# ID a part of
made up of
DFo 3-1
Resolving a M:M Recursive Relationship
• Resolve the M:M recursive relationship with an
intersection entity. COMPONENT
# ID
assembled by the detail part of
master for detail of
ASSEMBLY RULE
o Quantity
DFo 3-1
Arc Relationship
• An arc is an exclusive relationship group, which is
defined such that only one of the relationships can exist
for any instance of an entity.
• The arc drawn between two relationships connects
them and demonstrates mutual exclusivity.
• The relationship implies an "or" condition
• The arc indicates that any instance of that entity can
have only one valid relationship of the relationship in
the arc at any one time.
DFo 3-1
Characteristics of an Arc Relationship
– The relationships in an arc frequently have the same
relationship name.
– The relationships in an arc must be either all mandatory or all
optional and should have the same cardinality.
– An arc belongs to a single entity and must include only
relationships that originate from the entity.
– An entity may have multiple arcs, but a specific relationship can
participate only in a single arc.
– An arc relationship is represented as the arc-shaped line across
two or more relationship lines.
• Relationships included in the arc have a circle on the relationship arc line
DFo 3-1
Arc Relationships
• A supertype entity and its subtypes can be modeled as
an arc relationship.
• Example: An EMPLOYEE entity is either a CURRENT
EMPLOYEE or an EX-EMPLOYEE, but not both
(this could also be modeled as a supertype/subtype)
CURRENT
be
EMPLOYEE
EMPLOYEE be
be
EX-
be
EMPLOYEE
DFo 3-1
Case Scenario: Arc Relationship
Matt, can you create an entity that can

have an arc relationship?
Faculty
I can create a common entity called

MEMBERSHIP that would hold
membership details common to all
membership categories. Matt
DFo 3-1
Case Scenario: Creating a Common Entity
holds FACULTY
held by
MEMBERSHIP
held by
STUDENT
holds
DFo 3-1
Project Exercise 4
– Identify Hierarchical, Recursive and Arc Relationships
DFo 3-1
Summary
In this lesson, you should have learned how to:
• Identifying barred relationships
• Resolve M:M relationships
• Identify and illustrate nontransferable relationships
• Identify and draw supertype and subtype entities
• Identify hierarchical, recursive, and arc relationships
DFo 3-1

Oracle Database Foundations

Uploaded by

Document Information

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

Oracle Database Foundations

Uploaded by

Copyright:

Available Formats

Database Foundations

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Normalization Data Modeling

• The UID requires both the ACCOUNT Number and the

• The UID for the ACCOUNT entity is made up of ACCOUNT

• The UID for WORK ASSIGNMENT is EMPLOYEE ID and

Where would you add the Quantity attribute?

ORDER ORDER ITEM

PERSON born in COUNTRY

PERSON born in COUNTRY

• The membership relationship

MEMBERSHIP held by PERSON

PK, FK1- Subtype A Subtype B PK,FK1-

PK, FK1- Subtype A Subtype B PK,FK1-

• You can nest HOTEL

within The UIDs for a set of within

DEPARTMENT hierarchical entities can be DEPARTMENT

Each EMPLOYEE may

Each EMPLOYEE may

Sample Instances: Sample Instances:

assembled by the detail part of

master for detail of

Matt, can you create an entity that can

I can create a common entity called

You might also like