*Chapter 4Database Design I: The Entity-Relationship Model

*Database DesignGoal: specification of database schemaMethodology: Use E-R model to get a high-level graphical view of essential components of enterprise and how they are relatedConvert E-R diagram to DDLE-R Model: enterprise is viewed as a set ofEntitiesRelationships among entities

*EntitiesEntity: an object that is involved in the enterpriseEx: John, CSE305Entity Type: set of similar objectsEx: students, coursesAttribute: describes one aspect of an entity typeEx: name, maximum enrollment

*Entity TypeEntity type described by set of attributesPerson: Id, Name, Address, HobbiesDomain: possible values of an attributeValue can be a set (in contrast to relational model)(111111, John, 123 Main St, {stamps, coins})Key: minimum set of attributes that uniquely identifies an entity (candidate key)Entity Schema: entity type name, attributes (and associated domain), key constraints

*Entity Type (cont)Graphical Representation in E-R diagram:Set valued

*RelationshipsRelationship: relates two or more entitiesJohn majors in Computer ScienceRelationship Type: set of similar relationshipsStudent (entity type) related to Department (entity type) by MajorsIn (relationship type).Distinction: relation (relational model) - set of tuplesrelationship (E-R Model) describes relationship between entities of an enterpriseBoth entity types and relationship types (E-R model) may be represented as relations (in the relational model)

*Attributes and RolesAttribute of a relationship type describes the relationshipe.g., John majors in CS since 2000John and CS are related2000 describes relationship - value of SINCE attribute of MajorsIn relationship typeRole of a relationship type names one of the related entitiese.g., John is value of Student role, CS value of Department role of MajorsIn relationship type(John, CS; 2000) describes a relationship

*Relationship TypeDescribed by set of attributes and rolese.g., MajorsIn: Student, Department, SinceHere we have used as the role name (Student) the name of the entity type (Student) of the participant in the relationship, but ...

*RolesProblem: relationship can relate elements of same entity typee.g., ReportsTo relationship type relates two elements of Employee entity type: Bob reports to Mary since 2000 We do not have distinct names for the rolesIt is not clear who reports to whom

*Roles (cont)Solution: role name of relationship type need not be same as name of entity type from which participants are drawn ReportsTo has roles Subordinate and Supervisor and attribute SinceValues of Subordinate and Supervisor both drawn from entity type Employee

*Schema of a Relationship TypeRole names, Ri, and their corresponding entity sets. Roles must be single valued (number of roles = degree of relationship)Attribute names, Aj, and their corresponding domains. Attributes may be set valuedKey: Minimum set of roles and attributes that uniquely identify a relationship Relationship: ei is an entity, a value from Ris entity setaj is a set of attribute values with elements from domain of Aj

*Graphical RepresentationRoles are edges labeled with role names (omitted if role name = name of entity set). Most attributes have been omitted.

*Entity Type HierarchiesOne entity type might be subtype of anotherFreshman is a subtype of StudentA relationship exists between a Freshman entity and the corresponding Student entitye.g., Freshman John is related to Student JohnThis relationship is called IsAFreshman IsA StudentThe two entities related by IsA are always descriptions of the same real-world object

*IsAFreshmanSophmoreJuniorSeniorStudentIsARepresents 4relationship types

*Properties of IsAInheritance - Attributes of supertype apply to subtype.E.g., GPA attribute of Student applies to FreshmanSubtype inherits all attributes of supertype.Key of supertype is key of subtypeTransitivity - Hierarchy of IsAStudent is subtype of Person, Freshman is subtype of Student, so Freshman is also a subtype of Student

*Advantages of IsACan create a more concise and readable E-R diagramAttributes common to different entity sets need not be repeatedThey can be grouped in one place as attributes of supertypeAttributes of (sibling) subtypes can be different

*IsA Hierarchy - Example

*Constraints on Type HierarchiesMight have associated constraints:Covering constraint: Union of subtype entities is equal to set of supertype entitiesEmployee is either a secretary or a technician (or both)Disjointness constraint: Sets of subtype entities are disjoint from one anotherFreshman, Sophomore, Junior, Senior are disjoint set

*Single-role Key ConstraintIf, for a particular participant entity type, each entity participates in at most one relationship, corresponding role is a key of relationship typeE.g., Professor role is unique in WorksInRepresentation in E-R diagram: arrowWorksInProfessorDepartment

*Participation ConstraintIf every entity participates in at least one relationship, a participation constraint holds:A participation constraint of entity type E having role in relationship type R states that for e in E there is an r in R such that (r) = e.e.g., every professor works in at least one departmentWorksInProfessorDepartmentReprsentation in E-R

*Participation and Key ConstraintIf every entity participates in exactly one relationship, both a participation and a key constraint hold:e.g., every professor works in exactly one departmentWorksInProfessorDepartmentE-R representation: thick line

*An entity type corresponds to a relationRelations attributes = entity types attributes Problem: entity type can have set valued attributes, e.g., Person: Id, Name, Address, Hobbies Solution: Use several rows to represent a single entity(111111, John, 123 Main St, stamps)(111111, John, 123 Main St, coins)Problems with this solution:RedundancyKey of entity type (Id) not key of relationHence, the resulting relation must be further transformed (Chapter 6)Representation of Entity Types in the Relational Model

*Representation of Relationship Types in the Relational ModelTypically, a relationship becomes a relation in the relational modelAttributes of the corresponding relation areAttributes of relationship typeFor each role, the primary key of the entity type associated with that roleExample:

S2000Courses (CrsCode, SectNo, Enroll) Professor (Id, DeptId, Name) Teaching (CrsCode, SecNo, Id, RoomNo, TAs)TeachingS2000CoursesProfessorDeptIdNameRoomNoCrsCodeEnrollSectNoIdTAs

*Representation of Relationship Types in the Relational ModelCandidate key of corresponding table = candidate key of relationExcept when there are set valued attributesExample: Teaching (CrsCode, SectNo, Id, RoomNo, TAs)Key of relationship type = (CrsCode, SectNo)Key of relation = (CrsCode, SectNo, TAs) CrsCode SectNo Id RoomNo TAsCSE305 1 1234 Hum 22 JoeCSE305 1 1234 Hum 22 MarySet valued

*Representation in SQLEach role of relationship type produces a foreign key in corresponding relationForeign key references table corresponding to entity type from which role values are drawn

*Example 1WorksInProfessorDepartmentSinceStatusCREATE TABLE WorksIn ( Since DATE, -- attribute Status CHAR (10), -- attribute ProfId INTEGER, -- role (key of Professor) DeptId CHAR (4), -- role (key of Department) PRIMARY KEY (ProfId), -- since a professor works in at most one department FOREIGN KEY (ProfId) REFERENCES Professor (Id), FOREIGN KEY (DeptId) REFERENCES Department )

*Example 2SoldProjectPartDatePriceCREATE TABLE Sold ( Price INTEGER, -- attribute Date DATE, -- attribute ProjId INTEGER, -- role SupplierId INTEGER, -- role PartNumber INTEGER, -- role PRIMARY KEY (ProjId, SupplierId, PartNumber, Date), FOREIGN KEY (ProjId) REFERENCES Project, FOREIGN KEY (SupplierId) REFERENCES Supplier (Id), FOREIGN KEY (PartNumber) REFERENCES Part (Number) )Supplier

*Representation of Single Role Key Constraints in the Relational ModelRelational model representation: key of the relation corresponding to the entity type is key of the relation corresponding to the relationship typeId is primary key of Professor; ProfId is key of WorksIn. Professor 4100 does not participate in the relationship.Cannot use foreign key in Professor to refer to WorksIn since some professors may not work in any dept. (But ProfId is a foreign key in WorksIn that refers to Professor.)1123410032161123 CSE3216 AMSProfessorWorksInIdProfIdWorksInProfessorDepartmentKey

*Representing Type Hierarchies in the Relational ModelSupertypes and subtypes can be realized as separate relationsNeed a way of identifying subtype entity with its (unique) related supertype entityChoose a candidate key and make it an attribute of all entity types in hierarchy

*Type Hierarchies and the Relational Model Id attribs1 Id attribs2 Id attribs3 Id attribs4Id attribs0StudentFreshman Sophmore Junior Senior Translated by adding the primary key of supertype to all subtypes. Plus foreign key from subtypes to the supertype.FOREIGN KEY Id REFERENCES Student

in Freshman, Sophomore, Sunior, Senior

*Type Hierarchies and the Relational ModelRedundancy eliminated if IsA is not disjointFor individuals who are both employees and students, Name and DOB are stored only once

SSN Name DOB SSN Department Salary SSN GPA StartDate1234 Mary 1950 1234 Accounting 35000 1234 3.5 1997PersonEmployee Student

*Type Hierarchies and the Relational ModelOther representations are possible in special cases, such as when all subtypes are disjointSee in the book

*Representing Participation Constraints in the Relational ModelInclusion dependency: Every professor works in at least one dept.in the relational model: (easy)Professor (Id) references WorksIn (ProfId)in SQL: Simple case: If ProfId is a key in WorksIn (i.e., every professor works in exactly one department) then it is easy:FOREIGN KEY Id REFERENCES WorksIn (ProfId)General case ProfId is not a key in WorksIn, so cant use foreign key constraint (not so easy):CREATE ASSERTION ProfsInDepts CHECK ( NOT EXISTS ( SELECT * FROM Professor P WHERE NOT EXISTS ( SELECT * FROM WorksIn W WHERE P.Id = W.ProfId ) ) )WorksInProfessorDepartmentSelect those professors that do not work

*Representing Participation Constraint in the Relational ModelExample (cant use foreign key in Professor if ProfId is not a candidate key in WorksIn)1123410032161123 CSE1123 AMS4100 ECO3216 AMSProfessorWorksInIdProfIdProfId not acandidate key

*Representing Participation and Key Constraintin SQLIf both participation and key constraints apply, use foreign key constraint in entity table (but beware: if candidate key in entity table is not primary, presence of nulls violates participation constraint).CREATE TABLE Professor ( Id INTEGER, PRIMARY KEY (Id), -- Id cant be null FOREIGN KEY (Id) REFERENCES WorksIn (ProfId) --all professors participate )ProfessorWorksInDepartment

*Participation and Key Constraint in the Relational ModelExample:xxxxxx 1123yyyyyy 4100zzzzzzz 32161123 CSE4100 ECO3216 AMSProfessorIdProfIdWorksIn

*Participation and Key Constraint in Relational Model (again)Alternative solution if both key and participation constraints apply: merge the tables representing the entity and relationship setsSince there is a 1-1 and onto relationship between the rows of the entity set and the relationship sets, might as well put all the attributes in one table

*Participation and Key Constraint in Relational ModelExamplexxxxxxx 1123 CSEyyyyyyy 4100 ECOzzzzzzzz 3216 AMSProf_WorksInName Id DeptId

*Entity or Attribute?Sometimes information can be represented as either an entity or an attribute.StudentSemesterCourseTranscriptGradeStudentCourseTranscriptGradeSemesterAppropriate if Semester has attributes(next slide)

*Entity or Relationship?

*(Non-) Equivalence of DiagramsTransformations between binary and ternary relationships.SoldProjectPartSupplierDatePrice

ER exercise 1*Consider the design of the following database system for managing a conference X: a collection of papers are submitted to X, each of which has a unique paper IDs, a list of authors (names, affiliations, emails) in the order of contribution significance, title, abstract, and a PDF file for its content. The conference has a list of program committee (PC) members to review the papers. To ensure review quality, each paper is assigned to 3 PC members for review. To avoid overloading, each PC member is assigned with at most 5 papers, assuming that there are enough PC members. Each review report consists of a report ID, a description of review comment, a final recommendation (accept, reject), and the date the review report is submitted. A PC member can submit at most one review report for the paper that is assigned to him/her.

ER exercise 1 (cont)*Draw an E-R diagram for the above system. Use underlines, thick lines, and arrows to represent constraints. State your assumptions if necessary.Translate the previous E-R diagram for exercise1 into a relational model, i.e., a set of CREAT TABLE statements enforcing all stated constraints. In addition, write a CREATE ASSERTION statement to enforce that no PC member will be assigned to a paper of which she/he is a coauthor.

*ER Diagram

*SQL exerciseCreate table paper (paperid integer,title VARCHAR(50),abstract VARCHAR(250),pdf VARCHAR(100),primary key (paperid))

*SQL exerciseCreate table author(email VARCHAR(100),name VARCHAR(50),affiliation VARCHAR(100),primary key(email))

CREATE table write(paperid integer,email varchar(50),order integer,Primary key(paperid, email),foreign key paperid references paper,foreign key email references autor)

*

create table pcmember(email VARCHAR(50),name VARCHAR(20),primary key (email))*

create table review(reportid integer,sdate DATE,comment VARCHAR(250),recommendation CHAR(1),paperid integer,email VARCHAR(100),unique(paperid, email),foreign key paperid references paper,foreign key email references pcmember)

*

*CREATE Assertion 3pc CHECK NOT EXISTS( SELECT * FROM Papers P WHERE 3 ( SELECT COUNT(*) FROM Review R WHERE R.paperid = P.paperid ))

*CREATE ASSERTION atmostfivepapersCHECK NOT NOT EXISTS( SELECT * FROM pcmember P WHERE 5 < ( SELECT * FROM review R WHERE R.email = P.email ))

ER exercise 2Suppose you are asked to design a club database system based on the following information. Each student has a unique student id, a name, and an email; each club has a unique club id, a name, a contact telephone number, and has exactly one student as its president. Each student can serve as a president in at most one of the clubs, although he/she can be the members of several clubs. Clubs organize activities and students can participate in any of them. Each activity is described by a unique activity id, a place, a date, a time and those clubs that organize it. If an activity is organized by more than one club, different clubs might contribute different activity fees.*

Exercise 2 (cont)Draw an E-R diagram for the system, in particular, use arrows or thick lines to represent constraints appropriately. Write down your assumptions if necessary.Translate the above E-R diagram to a relational model, in particular, specify your primary key and foreign key constraints clearly.*

Reference solution*

CREATE TABLE Student ( studid CHAR(9), email VARCHAR(50), name VARCHAR(50) NOT NULL, PRIMARY KEY ( studid ), ) *

CREATE TABLE Club ( clubid INTEGER, telephone VARCHAR(15), name VARCHAR(50), president CHAR(9) NOT NULL, unique(president),PRIMARY KEY (clubid), FOREIGN KEY (president) REFERENCES Student(studid ) ) *

CREATE TABLE MemberOf ( clubid INTEGER, studid VARCHAR(50), PRIMARY KEY (clubid, studid ), FOREIGN KEY (clubid ) REFERENCES Club( clubid ), FOREIGN KEY (studid ) REFERENCES Student( studid ) ) *

*CREATE TABLE Activities ( actid INTEGER, actdt DATETIME, place VARCHAR(50), PRIMARY KEY (actid ) )

*CREATE TABLE Organize (actid INTEGER,clubid INTEGER,fee VARCHAR(50),PRIMARY KEY (actid, clubid ),FOREIGN KEY (actid ) REFERENCES Activities(actid ),FOREIGN KEY (clubid ) REFERENCES Club( clubid ))

*CREATE ASSERTION AtLeastOneOrganizer CHECK NOT EXISTS( SELECT * FROM Activities WHERE NOT EXISTS( SELECT * FROM Organize WHERE Organize.actid=Activities.actid ) )

Exercise 3Consider the design of a database for the management of grants. Each grant is identified by a unique grant ID, a title, the funding source of the grant, the period (starting data and ending date), and the amount of grant. Each grant might be participated by several professors and each professor might also participate in several grants. Each professor is identified by a unique SSN, name, and email address. In addition, several graduate students might be supported by a grant as GRAs, although each student can be supported by at most one grant. Each graduate student has exactly one professor as his/her advisor.

*

Exercise 3 (cont)*Draw an E-R diagram for the system, in particular, use arrows or thick lines to represent constraints appropriately. Write down your assumptions and justifications briefly and clearly.Translate the above E-R diagram into a relational model, i.e., write a set of CREATE TABLE statements. In particular, specify primary key, foreign key and other constraints whenever possible.

Reference solution*

create table grant(grantid integer, title varchar(50),source varchar(50),periodstart DATE,periodend DATE,amount integer,primary key(grantid))

*

Create table professor(ssn char(9),name VARCHAR(20),email varchar(20),primary key(ssn),unique(email))*

Create table participate(grantid integer,professorid char(9),primary key(grantid, professorid),foreign key grantid references grant,foreign key professorid references professor(ssn))*

Create student(studid integer,name varchar(50),status varchar(20),advisor char(9) NOT NULL,supportgrantid integer,primary key(studid),foreign key advisor references professor,Foreign key supportgrantid references grant(grantid))*

Exercise 4Consider the design of the following database system: each PhD student has exactly one a dissertation committee which consists of 4-5 faculty, and each committee is for exactly one student. Each student has an ordered list of advisors including the primary advisor followed by 0 or more secondary advisors. Each student has a unique studid, a name, and a major. Each committee has a unique committee id, and the date the committee is formed. Each faculty has a unique facid and a name. Each faculty can participate in multiple committees and be the advisors (either primary or secondary) of several students. *

Exercise 4 (cont)Draw an E-R diagram for the above system. Use underlines, thick lines, and arrows to represent constraints. State your assumptions if necessary.Translate your E-R diagram for problem 1 into a relational model, i.e., a set of CREAT TABLE/ASSERTION statements enforcing all stated constraints. In addition, write a CREATE ASSERTION statement to enforce that each committee consists of the primary advisor of the student and all other members of the committee cannot be the secondary advisors of the student.

*

Reference solution*

Reference solutionCREATE TABLE Advise (order VARCHAR(50),studid VARCHAR(50),facid VARCHAR(50),PRIMARY KEY ( studid, facid ),FOREIGN KEY ( studid ) REFERENCES Students ( studid ),FOREIGN KEY (facid ) REFERENCES Faculty ( facid ))

*

CREATE TABLE Student (studid VARCHAR(50) NOT NULL,name VARCHAR(50),major VARCHAR(50), since DATE,PRIMARY KEY ( studid ))

*

CREATE TABLE Participate (studid VARCHAR(50),facid VARCHAR(50),PRIMARY KEY (studid, facid ),FOREIGN KEY ( studid ) REFERENCES StudentFOREIGN KEY (facid ) REFERENCES Faculty ( facid ))*

*The primary advisor must be in the committee CREATE ASSERTIONCHECK NOT EXISTS( SELECT * from Student S WHERE ( SELECT facid // one primary advisor FROM Advise A WHERE A.facid = S.facid and A.order = 1 ) NOT IN ( // all my committee members select facid FROM Participate P WHERE P.stuid = S.studid ))

*Other co-advisors must be NOT in the committee CREATE ASSERTIONCHECK NOT EXISTS( SELECT * from Student S WHERE EXISTS( // some committee members are co-advisors SELECT A.facid FROM Advise A, Pariticpate P WHERE s.studid = A.stuid AND A.stuid = P.studid AND A.order 1 AND A.facid = P.facid)

*****************************************