1. CMPT 355 Sept-Dec 2010 - w7d21 Example of Further Temporal Database Considerations Week 7, Day 2 based on last class

2. CMPT 355 Sept-Dec 2010 - w7d22 Derived Data (review) There are two classes of derived data –Static derived data is derived at some point in time and then remains constant –Dynamic derived data needs to change in synchronization with the data it is derived from With derived data –We might be loosing some data –that we might want sometime in the future.

3. CMPT 355 Sept-Dec 2010 - w7d23 Temporal Data (Review) Is based on a new type of data –A period is composed of two values beginning bound – “the least value in a period” ending bound – “the greatest value in a period” We need one record per period –Where a period is the time frame over which the data (other than the ending bound) does not change –Each record will contain all the application relevant attributes (from the single record) a beginning and an ending bound –which will be used as part of the primary key of the record beginningending Known b-date NOT 0000 Unknown, current period e-date NULL Known b-date NOT 0000 Known, a previous period e-date NOT NULL

4. CMPT 355 Sept-Dec 2010 - w7d24 A Still Better (preferred) Form Record order-class: –Class identification –Order date Record order-book: –Class identification –ISBN –Quantity –[order-book-price] Record book: –ISBN –b-date –e-date –Title –Author –Price To incorporate history: “total value of order” –can be derived from the book-price –for the order-date b-date becomes part of the book PK e-date isn’t needed in the key –as long as periods cannot overlap –(allowing it to have NULL values) However, it may still be useful to keep the order-book-price which is obviously redundant –(rather than hidden) this allows individual orders –to use special pricing on an order –which is different from the standard book-price.

5. CMPT 355 Sept-Dec 2010 - w7d25 Another Example Let’s Consider U*STAR The objective of U*STAR is –to allow students –to register in classes –at the University of Saskatchewan We need to consider what it should do –(rather than what it does) To do this requires some analysis as well as some design

6. CMPT 355 Sept-Dec 2010 - w7d26 The Starting Point From the University’s perspective we should start with: Classes (that have attributes:) –Class ID (the Primary Key) Department ID(there may be multiple ID’s / Department) Course number –Other stuff Class name Class description Class prerequisites –multiple (Class ID) (a recursive relationship)

7. CMPT 355 Sept-Dec 2010 - w7d27 Guess What? Students don’t actually register in classes, –they register in: Sections (that have attributes:) –Section ID (the Primary Key) Class ID Section code (not always a number as we know) Term (NOTE: this is temporal stuff already!) –School Year –Term ID –Other stuff Class enrollment limit Time & Place –Multiple (day, time, location) Professor

8. CMPT 355 Sept-Dec 2010 - w7d28 Guess What? But they don’t actually register in sections directly, –they register in class reference numbers: Sections (that have attributes:) –CRN(the Primary Key) –Other stuff Class ID Section code (not always a number as we know) Term (NOTE: this is temporal stuff already!) –School Year –Term ID Class enrollment limit Time & Place –Multiple (day, time, location) Professor

9. CMPT 355 Sept-Dec 2010 - w7d29 Now for the Important Stuff And I don’t mean professors –(profs don’t rate our example or in U*STAR) Students (that have attributes:) –Student ID (the Primary Key) –Other stuff Name Address Phone College Department Year of studies

10. CMPT 355 Sept-Dec 2010 - w7d210 How do students get into sections? We need to register them, which needs Registration (that have attributes:) –Student ID (part of the Primary Key) –CRN(part of the Primary Key) –Other stuff? Registration date(to track when this happened) Grade received(for completed classes) (should be used to check prerequisites (yah, right!))

11. CMPT 355 Sept-Dec 2010 - w7d211 Now lets look what we have Classes –Class ID –Class name –Class description –Class prerequisites Sections –CRN –Section ID –Class enrollment limit –Time & Place –Professor Students –Student ID –Name –Address & Phone –College & Department & Year-studies Registration –Student ID –CRN –Registration date –Grade received What changes do we care about? We need to inspect our data structure to determine all potential changes that lead to possible temporal issues

12. CMPT 355 Sept-Dec 2010 - w7d212 Considering Classes Classes –Class ID Department ID Course number –Class name –Class description –Class prerequisites Class –name, description, prerequisites may change We will want to know the real info for transcripts Thus we need to add a b-date and an e-date to classes –Class renumbering is a problem E.g. a few years ago 374 was renumbered to become 355 –and before that, 374 was numbered 441 This can easiest be handled by adding class equivalents to classes

13. CMPT 355 Sept-Dec 2010 - w7d213 Considering Class Equivalents ClassEquivalents –Class ID Department ID Course number –Equivalent Class ID Department ID Course number –b-date –e-date Class Equivalents –Class IDs could be recycled after a time Thus we need to add a b-date and an e-date to classEquivalents

14. CMPT 355 Sept-Dec 2010 - w7d214 Considering Sections Sections –CRN –Section ID Class ID Section code School year Term –Class enrollment limit –Time & Place –Professor Sections –are already somewhat temporal because they are based on a specific term in history –we don’t need to worry about changes to limits, locations, profs only the latest data –However we do need to be able to match up with the correct class record so we should add a start of term date as a non changeable, non key attribute

15. CMPT 355 Sept-Dec 2010 - w7d215 Considering Students Students –Student ID –Name –Address –Phone –College –Department –Year of studies Students –Everything except student number may change –Changes in name, college, department, year can be important to note Thus we need to add a b-date and an e-date to students –We probably don’t need to worry about changes to address or phone But that’s just a processing choice, and won’t effect our database structure

16. CMPT 355 Sept-Dec 2010 - w7d216 Considering Registrations Registration –Student ID –CRN –Registration date –Grade received Registration –what about a withdrawal date? We should add a withdrawal date to registrations –what about multiple registrations & withdrawals for a given section? If we don’t want to reuse pervious records and forget about this indecision This could produce multiple records with the same record key Unless we add registration date to the key of the record

17. CMPT 355 Sept-Dec 2010 - w7d217 Further Temporal Considerations In the cases of classes and students –we have real entities, whose changes in attributes are important to remember In the case of sections –we have a real entity whose changes in attributes is not important to remember In the case of registrations –we have an entity representing a relationship whose changes in attributes are important to remember

18. CMPT 355 Sept-Dec 2010 - w7d218 Further Temporal Considerations We always record real entities as records in a table –We use multiple records to record important to remember changes We don’t always record relationships as records in a table Often, relationships are based on –joins between tables of real entities –based on attributes in each of the tables However, to remember –the dates when changes in relationships occur –We must record the relationships in their own tables (just like where we need to record other attributes of a relationship) The table will include: –the primary keys of the two entities –beginning and ending dates for the relationship