Computer Science 101 Web Access to Databases ER and Relational Models.

28
Computer Science 101 Web Access to Databases ER and Relational Models

Transcript of Computer Science 101 Web Access to Databases ER and Relational Models.

Computer Science 101Web Access to Databases

ER and Relational Models

Entity Relationship (ER) ModelConcepts

• A design tool

• Entity - Object or thing or concept - car, person, job

• Attribute - Property describing entity - name, salary

• Each entity can have a value for each of its attributes.

Types of Attributes

• Simple - atomic, non-divisible – this is what we use

• Derived – value not stored, but derived from other stored attributes - Age from birthdate

• Null – No value– Not applicable– Missing - exists– Not known - may or may not exist

• Key attribute - Value of this attribute uniquely identifies the entity - possibly composite – student id number,

social security number, apartment number with building number

ER-Diagram: Entities and Attributes

Entity Type Faculty

Attribute SSN

State

City

Street

Zip

Relationships

• Binary relationship on entity sets E1, E2 : Relates certain pairs from the two entity sets.

Students SectionsEnrolledIn

Faculty StudentsAdvises

Constraints on Relationship Types:Cardinality Ratios

• Cardinality ratio - specifies number of relationship instances that an entity may participate in.

• Possible ratios - 1:1, 1:N, M:N

• M and N can be thought of as "1 or more"

Cardinality ratios (cont.)

• A single faculty member would chair one department (at most).

• A single department would be chaired by one faculty member.

Faculty DepartmentsChairs1 1

Cardinality ratios (cont.)

Computers DepartmentsAssignedToN 1

• A single computer would be assigned to a single department.

• A single department could have multiple computers assigned to it.

Cardinality ratios (cont.)

Students SectionsEnrolledInM N

• A single student could be enrolled in multiple sections.

• A single section would have multiple students enrolled in it.

Cardinality ratios (cont.)

States CitiesCapitolOf1 1

Orders CustomersOrderedByN 1

Movies CustomersRecommendedFor

M N

ER Diagram for Department Database

SNum

Faculty

Name

Projects

SMajors

Major TypeCourses

Office

SSN

Rank

Sections

Sem

Time

Room

CNum

Title

Prerequisite

SectionOf

Teaches

Sponsors

Advises

Enrolled

HasHad

RequiredOf

WorkedOn

MajorsIn

Title Sem Type

NameClass

Id

Phone

Title

Abbrev

1

M

M

M

N

1

1N

N

N

1

N

N

N

M N

N

1

1

N

Our Class Database

• For the students in the class, I wanted:– Names (first and last names)– Major information including multiple majors,

department major is in, department chair (and information about the chair – phone, etc.)

– Primary faculty advisor (and information about the advisor – phone, etc.)

– Interests of various kinds and some information about the interest itself (category, maybe url, etc.)

Entity Types for Class Database -Students

Students

First NameLast Name Class Year

State

Zip

Birthdate

Student Id

CityTerm

Entity Types for Class Database -Faculty

Faculty

First NameLast Name Phone Email

Faculty Id

Entity Types for Class Database -Majors

Majors

NameDepartment Chair

Major Id

Entity Types for Class Database -Interests

Interests

NameCategory URL

InterestId

ER Diagram for Class Database -(Without attributes)

Interests

Students

Faculty

Majors

Has

M

N

AdvisedBy

N

1

MajorsInN

M

ChairedBy

1

N

Redundancy

• Redundancy in a database is when we have the same information stored multiple times.

• This is BAD because– Updates and deletions must take place on all

occurrences– For example, if my phone number is stored in

the records of all of my advisees, then a change of phone number is a real problem

Relational Model –Constraint Attributes

• Primary Key - special designated key – can not be null (underlined)

• Foreign Key - this is an attribute in one table that matches a primary key in another table. The requirement is that a value of this foreign key must match an existing primary key value in the other table.

Relational Model Constraints (cont.)

• Foreign Key example

Name Id ... AdvSSNSTUDENT

Name SSN ... DeptFACULTY

ER Relational: Step 1

• Create table R for each entity type. Have a column for each attribute. Choose a primary key.

• Class database – create tables:Students - StudentIDFaculty - FacultyIDMajors - MajorIDInterests - InterestID

ER Relational: Step 2

• Include in the Computers table, the primary key of Department as foreign key.

• Computers(SerNum,Make,…,DeptNum,…)

• For 1:N relation type: For entity on the N side, include a foreign key for the 1 related entity on the 1 side.

Computers DepartmentsAssignedTo

N 1

ER Relational: Step 2Class Database

• Students(StudentID,FirstName,…,AdvisorID,…)

• Include in the Student table, the primary key of the Advisor as foreign key.

Students FacultyAdvisedByN 1

ER Relational: Step 2Class Database

• Majors(MajorId, Name,…,ChairID,…)

• Include in the Major table, the primary key of the Chair as foreign key.

Majors FacultyChairedByN 1

ER Relational: Step 3

• For each M:N relation R, create table S with primary keys of the two entities as attributes.

• Examples– HasHad(ID,Cnum)– Prerequisite(CNum1,CNum2)– RequiredOf(Cnum,Abbrev)– EnrolledIn(ID,Snum,Cnum)

ER Relational: Step 3Class Database

• Leads to new table StudentMajor(StudentID, MajorID)

Students MajorsMajorsInM N

ER Relational: Step 3Class Database

• Leads to new table StudentInterest(StudentID, InterestID)

Students InterestsHasM N

Students(StudentID,FirstName, LastName, ClassYear,

City, State, Zip, BirthDate, AdvisorID, Term)

Faculty (FacultyID, FirstName, LastName, Phone, EMail)

Majors(MajorID, MajorName, Department, ChairID)

Interests(InterestID, InterestName, Category, URL)

StudentMajor(StudentID, MajorID)

StudentInterest(StudentID, InterestID)

Informal Relational Schema forthe Class Database