Oracle Database Foundations

Database Foundations
3-2
Tracking Data Changes
Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Road Map
You are here
More with Normalization Data Modeling

Tracking Data Terminology
Relationships Changes and Business
Rules and Mapping
DFo 3-2
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. 3
Objectives
This lesson covers the following objective:
• Keep track of data that changes over time
DFo 3-2
Tracking Data Changes Copyright © 2019, Oracle and/or its affiliates. All rights reserved. 4
Model Data over Time: Accommodating
Historical Data
• Most businesses need to track some historical data to help
them find trends and patterns that can be the basis for
business innovations or process improvements.
• Every update of an attribute or transfer of a relationship
means loss of information. Often information is no longer
useful, but some systems must keep track of some or all of
the historical values of an attribute. In addition, some
systems are required to keep an audit trail of each
transaction.
• Validate any requirements for storing historical data with
the user, because storing unnecessary historical data can be
costly.
DFo 3-2
Model Data over Time: Accommodating
Historical Data
• Add entities and relationships to the model to
accommodate historical data.
– Is an audit trail required?
– Can attribute values change over time?
– Can relationships change over time?
– Do you need to query older data?
DFo 3-2
Model Data over Time: Tracking Attribute
Values
• Create additional entities to track the attributes' values
over time.
CONTRACT
# ID
* Description Use one entity if you track only the
* Status
* Effective Date current status of a contract.
CONTRACT contain STATUS Add an entity to store

# ID # Effective Date the status of a
* Description state of * Current Value
contract over time.
DFo 3-2
Model Data over Time: Accommodating a
Changing Relationship
• Add an entity to accommodate a relationship that may
change over time.
PERSON rent APARTMENT This does not allow

# ID # Code tracking of the date that
* Last Name rented by * Address
* First Name an apartment is rented.
DFo 3-2
Model Data over Time: Accommodating a
Changing Relationship
• Add an entity to accommodate a relationship that may
change over time.
Add an entity to
PERSON RENTAL
# ID
rent # Effective Date capture the rental
* Last Name
rented by
o Renewal Date relationship over
* First Name
time.
rented for
rented by
APARTMENT
# Code
* Address
DFo 3-2
Model Data over Time: Creating Intersection
Entities
• Resolving M:M relationships with an intersection entity
is frequently used to track information about a
relationship that changes over time.
hold JOB
EMPLOYEE
# ID
This does not store
# ID
* Last Name held by * Title the history of an
* First Name * Minimum Salary employee’s jobs.
* Email * Maximum Salary
* Hire Date
* Salary
DFo 3-2
Model Data over Time: Creating Intersection
Entities
• An intersection entity is frequently used to track
information about a relationship that changes over
time.
EMPLOYEE JOB
# ID # ID
* Last Name * Title
* First Name * Minimum Salary
* Email * Maximum Salary
* Hire Date
Resolve the M:M * Salary held by
relationship and store the hold

JOB HISTORY
historical information in * Start Date
the intersection entity. o End Date
held for held for
DFo 3-2
Model Data over Time: Logging Modified
Information
• Additional entities and attributes store modified
information.
makes PAYMENT
CUSTOMER
# ID # Date Paid
* Name # Amount
made by
* Address
contains
included for
This stores PAYMENT MODIFICATION

* Previous Amount
information about * Modified by
how a payment * Modification Date
changes over time.
DFo 3-2
Model Rental over Time: Scenario
• A jewelry store rents necklaces, bracelets, and the like
for special occasions, such as award ceremonies and
movie premieres.
• The store wants to track the rental history.
CUSTOMER JEWELERY DETAIL

rented # code
# id
* first name renting * description
* last name * rental rate
* insured value
DFo 3-2
• The ERD model tracks only the current renter.
• How would you revise the relationship to track the
history?

rented # code
# id
* first name renting * description
* last name * rental rate
* insured value
DFo 3-2
• Change the relationship between JEWELRY DETAIL and
CUSTOMER to M:M.

# id # code
rented
* first name * description
* last name renting * rental rate
* insured value
DFo 3-2
Resolve M:M
• Resolve M:M with the RENTAL CUSTOMER
RENTAL HISTORY for
HISTORY # id
intersection entity. # date on * first name
* date returned * last name
• What is the UID of
RENTAL HISTORY? for
• What piece of on
information is not JEWELERY DETAIL
being tracked? # code
* description
* rental rate
* insured value
DFo 3-2
Project Exercise
• DFo_3_2_Project
– Oracle Baseball League Store Database
– Keeping Track of Data that Changes over Time
DFo 3-2
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. 17
Summary
In this lesson, you should have learned how to:
• Keep track of data that changes over time.
DFo 3-2

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.

More with Normalization Data Modeling

CONTRACT contain STATUS Add an entity to store

PERSON rent APARTMENT This does not allow

relationship and store the hold

This stores PAYMENT MODIFICATION

CUSTOMER JEWELERY DETAIL

CUSTOMER JEWELERY DETAIL

CUSTOMER JEWELERY DETAIL

You might also like