Database Principles

Database History

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 managedby Department Y

Hard Disk Image

Database Principles

Implementing the Employee Project Link

• Why won’t this work?

• What makes this better?

Proj_1

Emp_1Emp_1Emp_3 Emp_n

Proj_1

Emp_1Emp_1Emp_3 Emp_n

multi-list

Can only answer the question:What Project does Employee Y work on?

Can also answer the question:Who works on Project X?

.

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 theconsequences of having some VP ask for a specific reporton project participation “latertoday”?

Question: If such questionsbecome common, will theHierarchical Data Modelsurvive?

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

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 linkthat allows for maintainingadvisor info

still presents the issuesthat prevent the VP fromgetting his info in a timelyfashion.

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 CPS440

Course.CrsNum = Section.CrsNum

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

Database Principles

The Network Guys said:

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

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?

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 coursesand sections

Database Principles

1976

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

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.

Database Principles

Before Chen:

database

Real WorldRelational Data Model

Employee

Department

Project

DeptProject

EmployeeDept

Not easy tounderstand

mapping

Database Principles

Chen’s Proposal:

Straight-forwardMapping

Straight-forwardMapping

database

Real World

Chen’s Proposal

Relational Data Model

hopefully?

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?

X Y

fWhat about Mathematics?

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.