Computer Science 101 Web Access to Databases ER and Relational Models

Entity Relationship (ER) Model Concepts 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 E 1, E 2 : Relates certain pairs from the two entity sets. StudentsSections EnrolledIn FacultyStudents Advises

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. FacultyDepartments Chairs 1 1

Cardinality ratios (cont.) ComputersDepartments AssignedTo N1 A single computer would be assigned to a single department. A single department could have multiple computers assigned to it.

Cardinality ratios (cont.) StudentsSections EnrolledIn MN A single student could be enrolled in multiple sections. A single section would have multiple students enrolled in it.

Cardinality ratios (cont.) StatesCities CapitolOf 1 1 OrdersCustomers OrderedBy N1 MoviesCustomers RecommendedFor M N

ER Diagram for Department Database SNum Faculty Name Projects SMajors Major TypeCourses Office SSN Rank Sections Sem TimeRoomCNumTitle Prerequisite SectionOf Teaches Sponsors Advises Enrolled HasHad RequiredOf WorkedOn MajorsIn Title Sem TypeName Class Id Phone Title Abbrev 1 M M M N 1 1 N N N 1 N N N MN 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 Name Last Name Class Year State Zip Birthdate Student Id City Term

Entity Types for Class Database - Faculty Faculty First Name Last Name Phone Faculty Id

Entity Types for Class Database - Majors Majors Name Department Chair Major Id

Entity Types for Class Database - Interests Interests Name Category URL InterestId

ER Diagram for Class Database - (Without attributes) Interests Students Faculty Majors Has M N AdvisedBy N 1 MajorsIn N 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 NameId...AdvSSN STUDENT NameSSN...Dept FACULTY

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 - StudentID Faculty - FacultyID Majors - MajorID Interests - 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. ComputersDepartments AssignedTo N1

ER  Relational: Step 2 Class Database Students(StudentID,FirstName,…,AdvisorID,… ) Include in the Student table, the primary key of the Advisor as foreign key. StudentsFaculty AdvisedBy N1

ER  Relational: Step 2 Class Database Majors(MajorId, Name,…,ChairID,…) Include in the Major table, the primary key of the Chair as foreign key. MajorsFaculty ChairedBy N1

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 3 Class Database Leads to new table StudentMajor(StudentID, MajorID) StudentsMajors MajorsIn MN

ER  Relational: Step 3 Class Database Leads to new table StudentInterest(StudentID, InterestID) StudentsInterests Has MN

Students(StudentID,FirstName, LastName, ClassYear, City, State, Zip, BirthDate, AdvisorID, Term) Faculty (FacultyID, FirstName, LastName, Phone, ) Majors(MajorID, MajorName, Department, ChairID) Interests(InterestID, InterestName, Category, URL) StudentMajor(StudentID, MajorID) StudentInterest(StudentID, InterestID) Informal Relational Schema for the Class Database