1. Database Design
Sections 8 & 12 Modeling Historical Data, conditional nontranferability, time-related constraints

2. Modeling Over Time
Any relationship that changes through time needs special consideration.
An attribute such as status may change over time.
Examples of time sensitive attributes are: rental status, fee payment, country name, or price
Modeling data that changes over time can be a tricky subject. In this course, we will cover this subject twice -- here and again in Section 9. There are several implications to a model that incorporates the time element, so we are spreading out the material.
In this lesson, we will discuss the factors that influence the decision to model historical data, create a new entity to track it, and define a UID for such an entity.
A pharmaceutical company may want to track complaints filed about their drugs. This could help them detect problems early and issue recalls if necessary. Or they may want to conduct a study that follows patients on a new drug for an extended period of time. This could help scientific research and lead to further improvements in their products.
A commercial processing plan may want to keep a record of rejected units per batch, which machine it came from or the farm that was the source of the cows or products. If there is a pattern over time, it could suggest ways to improve the processing methods to minimize waste and reduce costs.

3. Change and Time Every update means loss of information.
Time in your model makes the model more complex.
There are often complex join conditions.
Users can work in advance.
Point out that in the real world, most data changes over time, but the business may not need to track all of it.
They need to validate requirements for storing historical data with the user. Storing unnecessary historical data can be costly. It takes up space

4. Entity DAY or Attribute Date
PURCHASE
DAY
#date on
for
Single attribute entity without M:1 relationships is usually replaced by attribute
PURCHASE
* date
Example: billable hours to different customers

5. DAY #date * public holiday indicator
Entity DAY
TASK ASSIGNMENT
*duration in hours
TASK
#id
DAY #date * public holiday indicator
EMPLOYEE
#name
first day of
starts on
for of in
with

6. Modeling Change ASSIGNMENT #start date o end date EMPLOYEE #id
COUNTRY #name of
for in as
Like a substitute teacher

7. Even a Country has a life cycle
Modeling Change
COUNTRY #name
#start time
*end time
EMPLOYEE
#id of in
life cycle attributes as
for
ASSIGNMENT
#start date
o end date
Even a Country has a life cycle

8. *description *rental rate
Example 8.1.6
JEWELRY PIECE
#code
*description *rental rate
*insured value
MOVIE STAR
#id
* first name
* last name
rented by
renting
Ask students how the store would know when the jewelry piece was rented? How would they know when it was returned? This will help the students realize that we really need a M:M relationship between JEWELRY PIECE and MOVIE STAR. They may try to put "date rented on" in JEWELRY PIECE, but this will be problematic because it can be rented out on different dates by different MOVIE STARs. Neither does the date rented belong in MOVIE STAR because different JEWELRY PIECEs may be rented out by the same MOVIE STAR but on different dates.

9. Possible Solution 8.1.7
Ask the class if drawing barred relationships makes an adequate UID for the RENTAL HISTORY entity.
Answer: No, because although RENTAL HISTORY tracks the date of the rental as well, the UID will not allow a MOVIE STAR to rent a JEWELRY piece again.

10. 8.1.8
To explore this further, you can play the “moving UID" game. Draw the model on the board, but this time, just have a UID bar between RENTAL HISTORY and MOVIE STAR, but keep date as part of the UID.
Ask the class: What does this model say?  
Answer: It says that a MOVIE STAR can rent only one JEWELRY PIECE on a given day. What if she/he wanted to rent more? Data example: If (give a movie star or celebrity that the class will recognize) wanted to rent both the Princess necklace and the Maharajah bracelet on 14-Jun, she could not, because MOVIE STAR identifier and date rented have to be unique.
Now, revise the model. This time, draw barred relationships from RENTAL HISTORY to JEWELRY PIECE and to MOVIE STAR.
Ask the class: Now what does the model say?
Answer: Two different MOVIE STARs could rent the same JEWELRY PIECE on the same DAY! That would not work at all.
Data example: (Movie Star 1 and Movie Star 2 -- name people that the class will recognize) want to rent the Winston diamond earrings on 26-Mar. The combination of MOVIE STAR identifier, JEWELRY PIECE code, and date rented are unique for each instance, so the model would allow this. However, we know that, in reality, this cannot happen.
Revise the model again. This time, just have a barred relationship between RENTAL HISTORY and JEWELRY PIECE, but keep the date as part of the UID.
Answer: It says that a JEWELRY PIECE can be rented only once on the same date. This is what we want.
Data example: Movie Star 1 wants to rent the Princess necklace on 05-May. Movie Star 2 can rent it on 12-May. The combination of JEWELRY PIECE code and date rented is unique.
Tell the class that this stresses the importance of defining the right UID -- it has implications for how the business can operate!

11. Review
Assessment:
(1) The UID of SHIFT ASSIGNMENT is a combination of STAFF id, SHIFT code, and SHIFT ASSIGNMENT date. This is represented by the barred relationships to STAFF and SHIFT, and the # before date.
(2) Using just the barred relationships, without the date as part of the UID, an employee could never work the same shift again.  
(3) Creating a barred relationship between SHIFT ASSIGNMENT and STAFF, and including the date in the UID, would mean that an employee could not work more than one shift on a given date.
(4) Creating a barred relationship between SHIFT ASSIGNMENT and SHIFT, and including the date in the UID, would mean that only one employee could work on particular shift on a given date.

12. Entity DAY vs. Attribute Date
Example
Why can’t you just add the attribute for high temperature and low temperature to the PURCHASE entity?
This is a good opportunity for a review of concepts learned previously. Ask the class: Why can’t we just add the attributes for high temperature and low temperature to the PURCHASE entity?
Answer: Because those attributes depend on the attribute date, which is not part of the UID of PURCHASE. Remember the rule of Third Normal Form -- attributes can’t have attributes of their own.

13. Examples When there is an interest in a particular day not a date.
Is it a holiday?
Is it a work day or weekend?
Is it leap year?
Month end?

14. Modeling time
Be aware of constraints that can result from the time dimension. Here is an example:
Consider a school fair that features several booths. The manager signs up volunteers to work different shifts at different booths. Some volunteers can work for several hours; others can work fewer hours depending on their free time. The schedule has to be determined in advance, so that the manager knows which times are not covered by any volunteers.
Normalization
The rule of Third Normal Form states that no non-UID attribute can be dependent on another non-UID attribute.
Third Normal Form prohibits transitive dependencies. A transitive dependency exists when any attribute in an entity is dependent on any other non-UID attribute in that entity.

15. What are some other rules?
Review
What are some other rules?
Mention that although the time-related constraints seem obvious in real life, they must be enforced by programming logic in the database. Therefore, they must be documented.
Can transfer shift if and only if the shift has not started!
Other rules:
No one may work more than 8 hours – This is a Procedural Rule
Procedural rules: Must be enforced through a program.
Another Procedural rule – No shift may overlap.
Structural Rule use the Diamond (non-transferable) Refer to example above.
example: every pilot has one and only one plane to fly.

16. Example 10.1.8 (1) Why must start time be part of the UID?
Answer: Because other exams can be scheduled in the same classroom on the same day, just not the same time.
(2) Other time-related constraints:
- Assignment periods may not overlap. (On a given date, the start time of an assignment for an exam may not be between the start time and end time of another exam for the same classroom. The end time of an assignment for an exam may not be between the start time and end time of another exam for the same classroom.)
- You cannot move the assignment of an exam from one classroom to another unless the start date and time of the assignment is still in the future (conditional nontransferability).
- Start date and time of an assignment may be updated to a later time, if that date and time is still in the future.
- Start date and time of an assignment may be updated to an earlier time, if that date and time are still in the future.

17. Modeling change: Price
When do we need to track price?
Determine best price for item
Sale price vs. original price
Grade change
Value of home
Asking price vs. sale price
Stock, bond, or investment
Others
May want to track “price-in-time”
For example price of car at time,

18. Review
Stock prices usually take a sharp dive or rise during times of crises or right before an announcement by the Federal Reserve. These as some things to take into consideration when deciding when to buy or sell.
If fuel prices look as though they are on an upward trend, you may lean toward a more fuel-efficient car or a hybrid model. If you have an opportunity to “lock in” to a monthly heating rate with your energy company, you may want to do so.
A contractor of a five-year bridge-construction project has to plan how much materials (cement, steel, equipment, etc.) to buy. If the price of cement is on the rise, the contractor may want to stockpile a lot of it.

19. Price with time Price may fluctuate with time Examples:
Value of Gold or Silver
Real Estate
Value of currency

20. Price = Priced Produce = Historical Price
Price with Time
PRODUCT
#id
*name
have
Price = Priced Produce = Historical Price
for
PRICE
#start date
*price is $
o end date
Do you really need an end date? It depends. If the various periods of a product price are contiguous, then you don’t need an end date.
Don’t need end date if there is always a price, therefore there can be a gap. If so then the new state date is the end date of previous price.
You can derive the end date from the start date of the next price associated with the item. However, if the products are not always available, as in the seasonal fruit and vegetable market, then you need an end date.

21. 10.2.9
Note that you cannot model the “between relationship.” It needs to be documented and implemented with additional code in the system.
You may also want to point out that PURCHASE HEADER may also contain other attributes or relationships to the CUSTOMER and the EMPLOYEE who processes the transaction. For simplicity’s sake, we don’t include them here.

22.
When a student’s grade is changed, we need to record information on the teacher who changed the grade and the reason for the change.
Start with the ENROLLMENT entity, which is the resolution of the M:M between STUDENT and CLASS.

23. Solution 10.2.13 STUDENT CLASS ENROLLMENT #date *grade
GRADE CHANGE *old grade *changed by #date changed o reason for change
Student / Class M:M Enrollment is the intersection entity
Things are left out for simplicity.