Database Design ch7-2

1
Database Design
7-2
Hierarchies and Recursive Relationships
Copyright © 2020, Oracle and/or its affiliates. All rights reserved.
2
Objectives
• This lesson covers the following objectives:
−Define and give an example of a hierarchical relationship
−Identify the UIDs in a hierarchical model
−Define and give an example of a recursive relationship
−Represent a recursive relationship in an ERD given a scenario
−Construct a model using both recursion and hierarchies to
express the same conceptual meaning
DDS7L2
Hierarchies and Recursive Relationships Copyright © 2020, Oracle and/or its affiliates. All rights reserved. 3
3
Purpose
• Often, roles are organized by hierarchy -- at work
(manager, crew chief, front-counter clerk, food
preparers), or in school (headmaster or principal,
assistant headmaster or assistant principal, teachers,
staff)
• Hierarchical data is very common
• Understanding it will help you model:
−Business organizational charts
−Building structures
−Family trees
−and many other hierarchies found in the real world
DDS7L2
4
Relationships in an Organizational Chart
• An Organization's reporting hierarchy can be
represented by this organizational chart
President
Director
Manager
Entry Level Employee
DDS7L2
Other hierarchical structures include: government, military, biology (species, genus ….).
5
Relationships in an Organizational Chart
• An organizational chart can be President
represented by this data model the
manager
• We create an entity for each level, of reporting to
with a relationship to the next level Director
• What are the UIDs for each entity? the
manager
of
reporting to
Manager
the
manager
of reporting to
Entry-Level
Employees
DDS7L2
The UIDs would probably be an employee ID or number for each entity.
6
Another Relationship Example BUILDING
• Notice the barred relationships # id

* Name
* Address
• Here you have a case of the
cascading UIDs:
−the UID of FLOOR is the combination FLOOR
# Number
of FLOOR number and the BUILDING id
−the UID of SUITE is the combination of
SUITE number and the FLOOR number
and the BUILDING id SUITE
# Number
−the UID of ROOM is the combination o Tenant
of ROOM id and SUITE number and
FLOOR number and the BUILDING id
ROOM
# id
DDS7L2
This may be convenient in the sense that the UID of a ROOM will also tell you the SUITE and FLOOR and
BUILDING that it’s in.
However, this makes for a rather long UID. Unique independent, artificial codes may be more practical.
Also, if the hierarchical structure changes often, use artificial identifiers. (If we were to add a level called
APARTMENT in between FLOOR and SUITE, think of how that would affect the UIDs of all SUITEs and
ROOMs!)
7
Hierarchy Versus Recursive Relationship
PRESIDENT
• Both of these # Badge number
* Name
models represent all * Salary
* Car plan
employees EMPLOYEE
• The one on the left DIRECTOR
# Badge number
# Badge number
* Name
is a hierarchical * Name
* Salary
* Job
* Salary
structure * Bonus plan
o Budget
o Bonus plan
• The one on the MANAGER o Car plan managed
# Badge number by
right uses a recursive * Name
relationship * Salary
* Budget
the
manager
ENTRY-LEVEL EMPLOYEE of
# Badge number
* Name
* Salary
DDS7L2
Hierarchical relationship: A series of relationships that reflect entities organized into successive levels.
Recursive relationship: A relationship between an entity and itself.
The mandatory attributes specific to an entity (bonus plan, car plan, and budget) become optional in the
recursive model.
This recursive relationship is fully optional, otherwise, the hierarchy would not have a top or bottom.
For example: “Who manages the president?” No one! One instance of the entity does not have a
manager. Entry-Level Employees do not manage anyone, hence, the relationship must be fully optional
in the recursive model.
8
PRESIDENT
• A relationship # Badge number
* Name
cannot be both * Salary
* Car plan
hierarchical and EMPLOYEE
recursive at the DIRECTOR
# Badge number
# Badge number
* Name
same time * Name * Job
* Salary
* Salary
• Which one do you * Bonus plan
o Budget
think is better? MANAGER
o Bonus plan
o Car plan managed
# Badge number by
* Name
* Salary
* Budget
the
manager
ENTRY-LEVEL EMPLOYEE of
# Badge number
* Name
* Salary
DDS7L2
Hierarchical relationship: A series of relationships that reflect entities organized into successive levels.
Recursive relationship: A relationship between an entity and itself.
The mandatory attributes specific to an entity (bonus plan, car plan, and budget) become optional in the
recursive model.
This recursive relationship is fully optional, otherwise, the hierarchy would not have a top or bottom.
For example: “Who manages the president?” No one! One instance of the entity does not have a
manager. Entry-Level Employees do not manage anyone, hence, the relationship must be fully optional
in the recursive model.
9
• Hierarchical:
−Hierarchical structures are more explicit and are easier for
most people to understand because they are very similar to
an organizational chart
−Each entity can have its own mandatory attributes and
relationships, if the business requires this (instead of all
optional attributes and relationships, as you would have in a
recursive) PRESIDENT
−In this way, your data model truly
reflects the business rules DIRECTOR
MANAGER
ENTRY-LEVEL EMPLOYEE
DDS7L2
10
• Recursive:
−Recursive relationships tend to be simpler because you are
using only one entity
−Your diagram will be less “busy”
−However, they are less specific – you cannot have mandatory
attributes or relationships unless they are mandatory in all
instances of the entity
managed by
EMPLOYEE
the manager
of
DDS7L2
Another thing to consider when modeling these types of relationships is how often the structure
changes. If it changes often, then a recursive relationship is easier to maintain. If it is fairly fixed, then
you may consider the more explicit hierarchy.
11
Drawing Convention
• The ERD convention to show a recursive relationship is
drawn as a loop, also known as a “pig’s ear”
EMPLOYEE
# Badge number
* First name
* Job
o Salary
o Budget
o Bonus plan
o Car plan
managed by
Loop (or pigs ear)

the manager of
DDS7L2
Each EMPLOYEE may be the manager of one or more EMPLOYEES.

Each EMPLOYEE may be managed by one and only one EMPLOYEE
12
Automobile Manufacturing Business Scenario
• For an automobile manufacturing organization,
consider all elementary parts, subassemblies,
assemblies, and products as instances of an entity
called COMPONENT
• The model can be created as a simple recursive
relationship
COMPONENT
a part of # id
* name
made up of
DDS7L2
13
Automobile Manufacturing Business Scenario
• Model Bill of Materials data as a many-to-many
recursive relationship:
−Each COMPONENT may be a part of one or more
COMPONENTS
−Each COMPONENT may be made up of one or more
COMPONENTS
COMPONENT
a part of # id
* name
made up of
DDS7L2
14
Terminology
• Key terms used in this lesson included:
−Hierarchal relationship
−Recursive relationship
DDS7L2
15
Summary
• In this lesson, you should have learned how to:
−Define and give an example of a hierarchical relationship
−Identify the UIDs in a hierarchical model
−Define and give an example of a recursive relationship
−Represent a recursive relationship in an ERD given a scenario
−Construct a model using both recursion and hierarchies to
express the same conceptual meaning
DDS7L2
16
17

Database Design ch7-2

Uploaded by

Document Information

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

Database Design ch7-2

Uploaded by

Copyright:

Available Formats

1

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

Entry Level Employee

The UIDs would probably be an employee ID or number for each entity.

• Notice the barred relationships # id

Loop (or pigs ear)

Each EMPLOYEE may be the manager of one or more EMPLOYEES.

You might also like