Presentation is loading. Please wait.

Presentation is loading. Please wait.

Database Principles Database History. Database Principles A bit of Database History Early 1960s, data models were hierarchies (Hierarchical Data Model)

Similar presentations


Presentation on theme: "Database Principles Database History. Database Principles A bit of Database History Early 1960s, data models were hierarchies (Hierarchical Data Model)"— Presentation transcript:

1 Database Principles Database History

2 Database Principles A bit of Database History Early 1960s, data models were hierarchies (Hierarchical Data Model) Models data as stored in database (ie, not conceptual) Arrows represent record-to-record physical pointers Programming: Navigating via pointers up and down hierarchies. Department Project Employee Project Department Location: Track 2 Sector 7 2:7X Y Project X managed by Department Y Hard Disk Image

3 Database Principles Implementing the Employee  Project Link Why won’t this work? What makes this better? Can only answer the question: What Project does Employee Y work on? Can also answer the question: Who works on Project X?.

4 Database Principles A bit of Database History (cont) All programs compiled Only users: big operational clients like payroll. Very inflexible; must follow pointers Department Employee Project Question: What are the consequences of having some VP ask for a specific report on project participation “later today”? Question: If such questions become common, will the Hierarchical Data Model survive?

5 Database Principles [Prof X?] Exercise: Create a hierarchy for a University Course Registration Database using Course, Professor, Student, Section. Imagine how you would answer the query: Does Prof X teach Student Y? Professor Course Student Section For each section For each course [Student Y?] start here

6 Database Principles More History: Mid 60s, early 70s: Data Model became a Graph (Network Data Model) Still models data in database (ie, not conceptual) Arrows still physical, record-to-record pointers Could ask more complicated questions Course Student SectionProfessor advisor add an additional link that allows for maintaining advisor info still presents the issues that prevent the VP from getting his info in a timely fashion.

7 Database Principles Modern Era: Mid 70s: Edgar Codd, Relational Data Model Everything modeled as tables with columns No longer use pointers to relate different things Relatedness implemented with replicated columns CrsNum CrsName CrsDesc Course SecNum CrsNum Prof Section Name OffNum Professor StdNum SecNum CrsNum Grade StudentEnrollment StdNum StdName Student CPS440 Course.CrsNum = Section.CrsNum

8 Database Principles Now try our Query: Does Prof X teach Student Y? Student.StdName = Y? where Professor.Name = “X” AND Professor.Name = Section.Prof AND Section.SecNum = StudentEnrollment.SecNum AND Section.CrsNun = StudentEnrollment.CrsNum AND StudentEnrollment.StdNum = Student.StdNum CrsNum CrsName CrsDesc Course SecNum CrsNum Prof Section Name OffNum Professor StdNum SecNum CrsNum Grade StudentEnrollment StdNum StdName Student ?Y X

9 Database Principles The Network Guys said:

10 Database Principles Relational Data Model vs Older Models 1970s: Not fast but flexible; needed to prove itself Today: Fast and Flexible: Older models have all but disappeared (object-relational model, noSQL model) Lesson: Flexible wins every time Exercise: In the models, network and relational, assuming people names are unique, find out if any professor is also a student

11 Database Principles Network Model vs RDM Flexibility For each Course { For each Section { Get Professor.Name  $ProfName For each Course { For each Section { For each Student { Get Student.StdName  $StudName If ( $ProfName == $StudName ) Print “$ProfName is both professor and student” } Course Student SectionProfessor start here 1 Is a professor also a student?

12 Database Principles Relational Model Answer: CrsNum CrsName CrsDesc Course SecNum CrsNum Prof Section Name OffNum Professor StdNum SecNum CrsNum Grade StudentEnrollment StdNum StdName Student Find Professor ? where Professor.Name = Student.StdName totally ignores courses and sections

13 Database Principles 1976

14 Database Principles Modern Era But Even Better Peter Chen published his PhD thesis His position: RDM guys said, “No way, we don’t need it!” Chen’s paper became the most sited paper in the history of computing, so we know who won that argument. Relational Data Model is a model of data in the database; good for programmers. What we need is a conceptual model of the real world to help designers do their jobs of understanding people’s needs

15 Database Principles ER Homework, Part A: Find the citation for Chen’s original paper. What does Chen mean when he calls his model “unifying”? Alternatively, in what way is Chen’s model “unifying”? Note: It is not necessary to read the paper to answer this question. The answer comes from understanding Chen’s approach in the context of our previous class’ lecture.

16 Database Principles Before Chen:

17 Database Principles Chen’s Proposal: hopefully?

18 Database Principles Chen’s Idea: You can model the real world with two things he called entities and relationships Is that enough? Can we model anything we want with just two concepts? XY f What about Mathematics?

19 Database Principles ER Homework Part B: Explain how traditional program design techniques like flow charts and pseudo-code model both the “real world” and/or program structure. Explain how the modern program design technique Object-Oriented Design (OOD) models both the “real world” and/or program structure.


Download ppt "Database Principles Database History. Database Principles A bit of Database History Early 1960s, data models were hierarchies (Hierarchical Data Model)"

Similar presentations


Ads by Google