1 The Entity-Relationship Model To Relational Model Summary of Conceptual Design • Conceptual design follows requirements analysis, – Yields a high-level description of data to be stored • ER model popular for conceptual design – Constructs are expressive, close to the way people think about their applications. – Note: There are many variations on ER model • Both graphically and conceptually • Basic constructs: entities, relationships, and attributes (of entities and relationships). • Some additional constructs: weak entities, ISA hierarchies, and aggregation. Summary of ER (Cont.) • Several kinds of integrity constraints: – key constraints – participation constraints – overlap/covering for ISA hierarchies. • Some foreign key constraints are also implicit in the definition of a relationship set. • Many other constraints (notably, functional dependencies) cannot be expressed. • Constraints play an important role in determining the best database design for an enterprise. Summary of ER (Cont.) • ER design is subjective. There are often many ways to model a given scenario! • Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include: – Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, aggregation. • Ensuring good database design: resulting relational schema should be analyzed and refined further. – Functional Dependency information and normalization techniques are especially useful. Review - Concepts Relational Model is made up of tables • A row of table = a relational instance/tuple • A column of table = an attribute • A table = a schema/relation • Cardinality = number of rows • Degree = number of columns Review - Example SID Name Major GPA 1234 John CS 2.8 5678 Mary EE 3.6 tuple/relational instance Attribute 4 Degree Cardinality = 2 A Schema / Relation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
The Entity-Relationship Model
To
Relational Model
Summary of Conceptual Design• Conceptual design follows requirements analysis,
– Yields a high-level description of data to be stored
• ER model popular for conceptual design
– Constructs are expressive, close to the way people think
about their applications.
– Note: There are many variations on ER model
• Both graphically and conceptually
• Basic constructs: entities, relationships, and attributes
(of entities and relationships).
• Some additional constructs: weak entities, ISA
hierarchies, and aggregation.
Summary of ER (Cont.)
• Several kinds of integrity constraints:
– key constraints
– participation constraints
– overlap/covering for ISA hierarchies.
• Some foreign key constraints are also implicit in the definition of a relationship set.
• Many other constraints (notably, functional dependencies) cannot be expressed.
• Constraints play an important role in determining the best database design for an enterprise.
Summary of ER (Cont.)
• ER design is subjective. There are often many ways to model a given scenario!
• Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include:
– Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, aggregation.
• Ensuring good database design: resulting relational schema should be analyzed and refined further.
– Functional Dependency information and normalization techniques are especially useful.
Review - Concepts
Relational Model is made up of tables
• A row of table = a relational instance/tuple
• A column of table = an attribute
• A table = a schema/relation
• Cardinality = number of rows
• Degree = number of columns
Review - Example
SID Name Major GPA
1234 John CS 2.8
5678 Mary EE 3.6
tuple/relational
instance
Attribute
4 Degree
Card
inality
= 2
A Schema / Relation
2
From ER Model to Relational
Model
So… how do we convert an ER diagram into a
table?? Simple!!
Basic Ideas:
Build a table for each entity set
Build a table for each relationship set if necessary (more
on this later)
Make a column in the table for each attribute in the entity
set
Indivisibility Rule and Ordering Rule
Primary Key
Example – Strong Entity Set
SID Name Major GPA
1234 John CS 2.8
5678 Mary EE 3.6
Student
SID Name
Major GPA
Advisor Professor
PSRN Name
Dept
PSRN Name Dept
9999 Smith Math
8888 Lee CS
• Design theory – Normalization through Functional
dependencies
• Only one concept: Relation – a two dimensional table
(different from „Relationships‟)
• Each tuple (row) of a relation represents an entity or a
relationship
• Schema of a relation: names of a relation and its attributes
– Students(sid: string, name: string, login: string, age:
integer, gpa: real).
• Though tuples and attributes are not ordered the default
order is as given by the schema of the relation
• Relational model requires each attribute be „atomic‟ (1NF)
• Relation is a „set‟ of tuples (unique, no order)
Relational Model ER to Relational Model
• General principles
– Entity set => a relation with same attributes
– Relationship => a relation whose attributes are
keys from participating entity sets + descriptive
attributes if any
• Special situations
– Weak entity sets
– Entity Hierarchies (ISA relationships)
– Merging relations
Reduction to Relation Schemas
o Primary keys allow entity sets and relationship
sets to be expressed uniformly as relation
schemas that represent the contents of the
database.
o A database which conforms to an E-R diagram
can be represented by a collection of
schemas.
o For each entity set and relationship set there is
a unique schema that is assigned the name of
the corresponding entity set or relationship set.
o Each schema has a number of columns
(generally corresponding to attributes), which
have unique names.
Representing Entity Sets as Schemas
• A strong entity set reduces to a schema with the same attributes.
• A weak entity set becomes a table that includes a column for the
primary key of the identifying strong entity set
payment =
( loan_number, payment_number, payment_date, payment_amount )
3
Creating Relations in SQL
• Creates the Students
relation. Observe that the
type (domain) of each field
is specified, and enforced by
the DBMS whenever tuples
are added or modified.
• As another example, the
Enrolled table holds
information about courses that
students take.
CREATE TABLE Students
(sid CHAR(20), name CHAR(30), login CHAR(20),
age INTEGER,gpa REAL)
CREATE TABLE Enrolled
(sid CHAR(20), cid CHAR(20), grade CHAR(2))
Logical DB Design: ER to
Relational
• Entity sets to tables:
CREATE TABLE Employees (psrn INTEGER,name CHAR(20),dept CHAR(12),PRIMARY KEY (ssn))Employees
psrnname
dept
Representing Relationship Sets as
Schemas
• A many-to-many relationship set is represented as a
schema with attributes for the primary keys of the two
participating entity sets, and any descriptive attributes
of the relationship set.
• Example: schema for relationship set borrower
borrower = (customer_id, loan_number )
Relationship Example
dob
dname
budgetdid
sincename
Works_In DepartmentsEmployees
psrn
16
Relationship Sets to Tables• In translating a relationship
set to a relation, attributes of
the relation must include:
– Keys for each
participating entity set
(as foreign keys).
– All descriptive attributes.
CREATE TABLE Works_In(psrn INTEGER,did INTEGER,since DATE,PRIMARY KEY (psrn, did),FOREIGN KEY (psrn)
REFERENCES Employees,FOREIGN KEY (did)
REFERENCES Departments)
Weak Entities
• A weak entity can be identified uniquely only by considering
the primary key of another (owner) entity.
– Owner entity set and weak entity set must participate in a one-to-
many relationship set (one owner, many weak entities).
– Weak entity set must have total participation in this identifying
relationship set.
dept
name
agepname
DependentsEmployees
psrn
Policy
cost
4
Translating Weak Entity Sets• Weak entity set and identifying relationship set are
translated into a single table.
– When the owner entity is deleted, all owned weak
entities must also be deleted.
CREATE TABLE Dep_Policy (pname CHAR(20),age INTEGER,cost REAL,psrn INTEGER NOT NULL,PRIMARY KEY (pname, ssn),FOREIGN KEY (psrn) REFERENCES Employees,
ON DELETE CASCADE)
Destroying and Altering
Relations
• Destroys the relation Students. The
schema information and the tuples are
deleted.
DROP TABLE Students
The schema of Students is altered by adding a new field; every tuple in the current instance is extended with a null value in the new field.
ALTER TABLE Students ADD COLUMN firstYear integer
Adding and Deleting Tuples
• Can insert a single tuple using:
INSERT INTO Students (sid, name, login, age, gpa)VALUES (53688, „Smith‟, „smith@ee‟, 18, 3.2)
Can delete all tuples satisfying some condition (e.g., name = Smith):
DELETE
FROM Students SWHERE S.name = „Smith‟
Powerful variants of these commands are available; more later!
Integrity Constraints (ICs)• IC: condition that must be true for any instance of
the database; e.g., domain constraints.
– ICs are specified when schema is defined.
– ICs are checked when relations are modified.
• A legal instance of a relation is one that satisfies
all specified ICs.
– DBMS should not allow illegal instances.
• If the DBMS checks ICs, stored data is more
faithful to real-world meaning.
– Avoids data entry errors, too!
Primary and Candidate Keys in SQL
• Possibly many candidate keys (specified using
UNIQUE), one of which is chosen as the primary
key.
CREATE TABLE Enrolled(sid CHAR(20)cid CHAR(20),grade CHAR(2),PRIMARY KEY (sid,cid) )
“For a given student and course, there is a single grade.” vs.“Students can take only one course, and receive a single grade for that course; further, no two students in a course receive the same grade.”
Used carelessly, an IC can prevent the storage of database instances that arise in practice!
CREATE TABLE Enrolled(sid CHAR(20)cid CHAR(20),grade CHAR(2),PRIMARY KEY (sid),UNIQUE (cid, grade) )
Foreign Keys in SQL
• Only students listed in the Students relation should
be allowed to enroll for courses.
CREATE TABLE Enrolled(sid CHAR(20), cid CHAR(20), grade CHAR(2),
PRIMARY KEY (sid,cid),FOREIGN KEY (sid) REFERENCES Students )
sid name login age gpa
53666 Jones jones@cs 18 3.4
53688 Smith smith@eecs 18 3.2
53650 Smith smith@math 19 3.8
sid cid grade
53666 Carnatic101 C
53666 Reggae203 B
53650 Topology112 A
53666 History105 B
EnrolledStudents
5
Enforcing Referential Integrity
• Consider Students and Enrolled; sid in Enrolled is a foreign key that references Students.
• What should be done if an Enrolled tuple with a non-existent student id is inserted? (Reject it!)
• What should be done if a Students tuple is deleted?
– Also delete all Enrolled tuples that refer to it.
– Disallow deletion of a Students tuple that is referred to.
– Set sid in Enrolled tuples that refer to it to a default sid.
– (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null, denoting `unknown’ or `inapplicable’.)
• Similar if primary key of Students tuple is updated.
Referential Integrity in SQL
• SQL/92 and SQL:1999
support all 4 options on
deletes and updates.
– Default is NO ACTION
(delete/update is
rejected)
– CASCADE (also delete
all tuples that refer to
deleted tuple)
– SET NULL / SET
DEFAULT (sets foreign
key value of referencing
tuple)
CREATE TABLE Enrolled(sid CHAR(20),cid CHAR(20),grade CHAR(2),PRIMARY KEY (sid,cid),FOREIGN KEY (sid)
REFERENCES StudentsON DELETE CASCADE
ON UPDATE SET DEFAULT )
Review: Key Constraints• Each dept has at
most one manager,
according to the
key constraint on
Manages.
Translation to relational model?
Many-to-Many1-to-1 1-to Many Many-to-1
dname
budgetdid
since
lot
name
ssn
ManagesEmployees Departments
Translating ER Diagrams with Key
Constraints
• Map relationship to a table:
– Note that did is the key now!
– Separate tables for Employees and Departments.
• Since each department has a unique manager, we could instead combine Manages and Departments.
CREATE TABLE Manages(ssn CHAR(11),did INTEGER,since DATE,PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees,FOREIGN KEY (did) REFERENCES Departments)
CREATE TABLE Dept_Mgr(did INTEGER,dname CHAR(20),budget REAL,ssn CHAR(11),since DATE,PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees)
Review: Participation Constraints• Does every department have a manager?
– If so, this is a participation constraint: the participation of
Departments in Manages is said to be total (vs. partial).
CREATE TABLE Dept_Mgr(did INTEGER,
dname CHAR(20),budget REAL,ssn CHAR(11) NOT NULL,since DATE,PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE NO ACTION)
Redundancy of Schemas Many-to-one and one-to-many relationship sets that are total on the
many-side can be represented by adding an extra attribute to the “many” side, containing the primary key of the “one” side
Example: Instead of creating a schema for relationship set account_branch, add an attribute branch_name to the schema arising from entity set account
6
Review: ISA Hierarchies
Contract_Emps
name
ssn
Employees
lot
hourly_wages
ISA
Hourly_Emps
contractid
hours_worked
If we declare A ISA B, every A entity is also considered to be a B entity.
• Overlap constraints: Can Joe be an Hourly_Emps as well
as a Contract_Emps entity? (Allowed/disallowed)
• Covering constraints: Does every Employees entity also
have to be an Hourly_Emps or a Contract_Emps entity?
(Yes/no)
Translating ISA Hierarchies to
Relations• General approach:
– 3 relations: Employees, Hourly_Emps and Contract_Emps.
• Hourly_Emps: Every employee is recorded in Employees. For hourly emps, extra info recorded in Hourly_Emps (hourly_wages, hours_worked, ssn); must delete Hourly_Emps tuple if referenced Employees tuple is deleted).
• Queries involving all employees easy, those involving just Hourly_Emps require a join to get some attributes.
• Alternative: Just Hourly_Emps and Contract_Emps.
– Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
– Each employee must be in one of these two subclasses.
Representing Class Hierarchy
• Two general approaches depending on
disjointness and completeness
– For non-disjoint and/or non-complete class hierarchy:
• create a table for each super class entity set
according to normal entity set translation method.
• Create a table for each subclass entity set with a
column for each of the attributes of that entity set
plus one for each attributes of the primary key of
the super class entity set
• This primary key from super class entity set is also
used as the primary key for this new table
Example
SSN SID Status Major GPA
1234 9999 Full CS 2.8
5678 8888 Part EE 3.6
Student
SID Status
Major GPA
SSN Name Gender
1234 Homer Male
5678 Marge Female
Person
Gender
SSN Name
ISA
Representing Class Hierarchy
• Two general approaches depending on
disjointness and completeness
– For disjoint AND complete mapping class hierarchy:
– DO NOT create a table for the super class entity set
– Create a table for each subclass entity set include all
attributes of that subclass entity set and attributes of
the superclass entity set
– Simple and Intuitive enough, need example?
Example
SSN Name SID Major GPA
1234 John 9999 CS 2.8
5678 Mary 8888 EE 3.6
StudentSID
Major GPA
SSN Name Dept
1234 Homer C.S.
5678 Marge Math
SJSU people
SSN Name
ISA
Faculty
Dept
Disjoint and
Complete mapping
No table created for
superclass entity set
7
Binary vs. Ternary Relationships• If each policy is
owned by just 1
employee, and
each dependent
is tied to the
covering policy,
first diagram is
inaccurate.
• What are the
additional
constraints in the
2nd diagram?
agepname
DependentsCovers
name
Employees
ssn lot
Policies
policyid cost
Beneficiary
agepname
Dependents
policyid cost
Policies
Purchaser
name
Employees
ssn lot
Bad design
Better design
Binary vs. Ternary Relationships
• The key constraints allow us to combine Purchaser with Policies and Beneficiary with Dependents.
• Participation constraints lead to NOT NULLconstraints.
CREATE TABLE Policies (policyid INTEGER,cost REAL,ssn CHAR(11) NOT NULL,PRIMARY KEY (policyid).FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)
CREATE TABLE Dependents (pname CHAR(20),age INTEGER,policyid INTEGER,PRIMARY KEY (pname, policyid).FOREIGN KEY (policyid) REFERENCES Policies,
ON DELETE CASCADE)
Representing Relationship SetN-ary Relationship
• Intuitively Simple
– Build a new table with as many columns as there are
attributes for the union of the primary keys of all
participating entity sets.
– Augment additional columns for descriptive attributes
of the relationship set (if necessary)
– The primary key of this table is the union of all
primary keys of entity sets that are on “many” side
– That is it, we are done.
Example – N-ary Relationship Set
P-Key1 P-Key2 P-Key3 A-Key D-Attribute
9999 8888 7777 6666 Yes
1234 5678 9012 3456 No
E-Set 1
P-Key1
Another Set
* Primary key of this table is P-Key1 + P-Key2 + P-Key3
D-Attribute
A relationship
A-Key
E-Set 2
P-Key2
E-Set 3
P-Key3
Representing Composite Attribute
• Relational Model Indivisibility Rule Applies
• One column for each component attribute
• NO column for the composite attribute itself
Professor
SSN Name
Address
SSN Name Street City
9999 Dr. Smith 50 1st St. Fake City
8888 Dr. Lee 1 B St. San Jose
Street City
Representing Multivalue Attribute
• For each multivalue attribute in an entity
set/relationship set
– Build a new relation schema with two columns
– One column for the primary keys of the entity
set/relationship set that has the multivalue attribute
– Another column for the multivalue attributes. Each
cell of this column holds only one value. So each
value is represented as an unique tuple
– Primary key for this schema is the union of all
attributes
8
Example – Multivalue attribute
SID Name Major GPA
1234 John CS 2.8
5678 Homer EE 3.6
Student
SID Name
Major GPA
Stud_SID Children
1234 Johnson
1234 Mary
5678 Bart
5678 Lisa
5678 Maggie
Children
The primary key for this
table is Student_SID +
Children, the union of all
attributes
Integrity Constraints (ICs)• IC: condition that must be true for any instance of
the database; e.g., domain constraints.
– ICs are specified when schema is defined.
– ICs are checked when relations are modified.
• A legal instance of a relation is one that satisfies
all specified ICs.
– DBMS should not allow illegal instances.
• If the DBMS checks ICs, stored data is more
faithful to real-world meaning.
– Avoids data entry errors, too!
Primary and Candidate Keys in SQL
• Possibly many candidate keys (specified using
UNIQUE), one of which is chosen as the primary
key.
CREATE TABLE Enrolled(sid CHAR(20)cid CHAR(20),grade CHAR(2),PRIMARY KEY (sid,cid) )
“For a given student and course, there is a single grade.” vs.“Students can take only one course, and receive a single grade for that course; further, no two students in a course receive the same grade.”
Used carelessly, an IC can prevent the storage of database instances that arise in practice!
CREATE TABLE Enrolled(sid CHAR(20)cid CHAR(20),grade CHAR(2),PRIMARY KEY (sid),UNIQUE (cid, grade) )
Foreign Keys in SQL
• Only students listed in the Students relation should
be allowed to enroll for courses.
CREATE TABLE Enrolled(sid CHAR(20), cid CHAR(20), grade CHAR(2),
PRIMARY KEY (sid,cid),FOREIGN KEY (sid) REFERENCES Students )
sid name login age gpa
53666 Jones jones@cs 18 3.4
53688 Smith smith@eecs 18 3.2
53650 Smith smith@math 19 3.8
sid cid grade
53666 Carnatic101 C
53666 Reggae203 B
53650 Topology112 A
53666 History105 B
EnrolledStudents
Enforcing Referential Integrity
• Consider Students and Enrolled; sid in Enrolled is a foreign key that references Students.
• What should be done if an Enrolled tuple with a non-existent student id is inserted? (Reject it!)
• What should be done if a Students tuple is deleted?
– Also delete all Enrolled tuples that refer to it.
– Disallow deletion of a Students tuple that is referred to.
– Set sid in Enrolled tuples that refer to it to a default sid.
– (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null, denoting `unknown’ or `inapplicable’.)
• Similar if primary key of Students tuple is updated.
Referential Integrity in SQL
• SQL/92 and SQL:1999
support all 4 options on
deletes and updates.
– Default is NO ACTION
(delete/update is
rejected)
– CASCADE (also delete
all tuples that refer to
deleted tuple)
– SET NULL / SET
DEFAULT (sets foreign
key value of referencing
tuple)
CREATE TABLE Enrolled(sid CHAR(20),cid CHAR(20),grade CHAR(2),PRIMARY KEY (sid,cid),FOREIGN KEY (sid)
REFERENCES StudentsON DELETE CASCADE
ON UPDATE SET DEFAULT )
9
Review: Key Constraints• Each dept has at
most one manager,
according to the
key constraint on
Manages.
Translation to relational model?
Many-to-Many1-to-1 1-to Many Many-to-1
dname
budgetdid
since
lot
name
ssn
ManagesEmployees Departments
Translating ER Diagrams with Key
Constraints
• Map relationship to a table:
– Note that did is the key now!
– Separate tables for Employees and Departments.
• Since each department has a unique manager, we could instead combine Manages and Departments.
CREATE TABLE Manages(ssn CHAR(11),did INTEGER,since DATE,PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees,FOREIGN KEY (did) REFERENCES Departments)
CREATE TABLE Dept_Mgr(did INTEGER,dname CHAR(20),budget REAL,ssn CHAR(11),since DATE,PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees)
Review: Participation Constraints• Does every department have a manager?
– If so, this is a participation constraint: the participation of
Departments in Manages is said to be total (vs. partial).
CREATE TABLE Dept_Mgr(did INTEGER,
dname CHAR(20),budget REAL,ssn CHAR(11) NOT NULL,since DATE,PRIMARY KEY (did),FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE NO ACTION)
Redundancy of Schemas Many-to-one and one-to-many relationship sets that are total on the
many-side can be represented by adding an extra attribute to the “many” side, containing the primary key of the “one” side
Example: Instead of creating a schema for relationship set account_branch, add an attribute branch_name to the schema arising from entity set account
Review: ISA Hierarchies
Contract_Emps
name
ssn
Employees
lot
hourly_wages
ISA
Hourly_Emps
contractid
hours_worked
If we declare A ISA B, every A entity is also considered to be a B entity.
• Overlap constraints: Can Joe be an Hourly_Emps as well
as a Contract_Emps entity? (Allowed/disallowed)
• Covering constraints: Does every Employees entity also
have to be an Hourly_Emps or a Contract_Emps entity?
(Yes/no)
Translating ISA Hierarchies to
Relations• General approach:
– 3 relations: Employees, Hourly_Emps and Contract_Emps.
• Hourly_Emps: Every employee is recorded in Employees. For hourly emps, extra info recorded in Hourly_Emps (hourly_wages, hours_worked, ssn); must delete Hourly_Emps tuple if referenced Employees tuple is deleted).
• Queries involving all employees easy, those involving just Hourly_Emps require a join to get some attributes.
• Alternative: Just Hourly_Emps and Contract_Emps.
– Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
– Each employee must be in one of these two subclasses.
10
Representing Class Hierarchy
• Two general approaches depending on
disjointness and completeness
– For non-disjoint and/or non-complete class hierarchy:
• create a table for each super class entity set
according to normal entity set translation method.
• Create a table for each subclass entity set with a
column for each of the attributes of that entity set
plus one for each attributes of the primary key of
the super class entity set
• This primary key from super class entity set is also
used as the primary key for this new table
Example
SSN SID Status Major GPA
1234 9999 Full CS 2.8
5678 8888 Part EE 3.6
Student
SID Status
Major GPA
SSN Name Gender
1234 Homer Male
5678 Marge Female
Person
Gender
SSN Name
ISA
Representing Class Hierarchy
• Two general approaches depending on
disjointness and completeness
– For disjoint AND complete mapping class hierarchy:
– DO NOT create a table for the super class entity set
– Create a table for each subclass entity set include all
attributes of that subclass entity set and attributes of
the superclass entity set
– Simple and Intuitive enough, need example?
Example
SSN Name SID Major GPA
1234 John 9999 CS 2.8
5678 Mary 8888 EE 3.6
StudentSID
Major GPA
SSN Name Dept
1234 Homer C.S.
5678 Marge Math
SJSU people
SSN Name
ISA
Faculty
Dept
Disjoint and
Complete mapping
No table created for
superclass entity set
Binary vs. Ternary Relationships• If each policy is
owned by just 1
employee, and
each dependent
is tied to the
covering policy,
first diagram is
inaccurate.
• What are the
additional
constraints in the
2nd diagram?
agepname
DependentsCovers
name
Employees
ssn lot
Policies
policyid cost
Beneficiary
agepname
Dependents
policyid cost
Policies
Purchaser
name
Employees
ssn lot
Bad design
Better design
Binary vs. Ternary Relationships
• The key constraints allow us to combine Purchaser with Policies and Beneficiary with Dependents.
• Participation constraints lead to NOT NULLconstraints.
CREATE TABLE Policies (policyid INTEGER,cost REAL,ssn CHAR(11) NOT NULL,PRIMARY KEY (policyid).FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)
CREATE TABLE Dependents (pname CHAR(20),age INTEGER,policyid INTEGER,PRIMARY KEY (pname, policyid).FOREIGN KEY (policyid) REFERENCES Policies,
ON DELETE CASCADE)
11
Representing Relationship SetUnary/Binary Relationship
• For one-to-one relationship w/out total participation
– Build a table with two columns, one column for each
participating entity set‟s primary key. Add successive
columns, one for each descriptive attributes of the
relationship set (if any).
• For one-to-one relationship with one entity set having
total participation
– Augment one extra column on the right side of the
table of the entity set with total participation, put in
there the primary key of the entity set without
complete participation as per to the relationship.
Example – One-to-One Relationship Set
SID Maj_ID Co S_Degree
9999 07 1234
8888 05 5678
Student
SID Name
Major GPA
ID Code
Majorstudy
* Primary key can be either SID or Maj_ID_Co
Degree
Example – One-to-One Relationship Set
SID Name Major GPA LP_S/N Hav_Cond
9999 Bart Economy -4.0 123-456 Own
8888 Lisa Physics 4.0 567-890 Loan
Student
SID Name
Major GPA
S/N #
LaptopHave
* Primary key can be either SID or LP_S/N
Condition
Brand
1:1
Relationship
Representing Relationship SetUnary/Binary Relationship
• For one-to-many relationship w/out total participation
– Same thing as one-to-one
• For one-to-many/many-to-one relationship with one entity set having total participation on “many” side
– Augment one extra column on the right side of the table of the entity set on the “many” side, put in there the primary key of the entity set on the “one” side as per to the relationship.
Example – Many-to-One Relationship Set
SID Name Major GPA Pro_SSN Ad_Sem
9999 Bart Economy -4.0 123-456 Fall 2006
8888 Lisa Physics 4.0 567-890 Fall 2005
Student
SID Name
Major GPA
SSN
Professor
* Primary key of this table is SID
Semester
Name
N:1
Relationship
Dept
Advisor
Representing Relationship SetUnary/Binary Relationship
• For many-to-many relationship
– Same thing as one-to-one relationship without
total participation.
– Primary key of this new schema is the union
of the foreign keys of both entity sets.
– No augmentation approach possible…
12
Representing Relationship SetN-ary Relationship
• Intuitively Simple
– Build a new table with as many columns as there are
attributes for the union of the primary keys of all
participating entity sets.
– Augment additional columns for descriptive attributes
of the relationship set (if necessary)
– The primary key of this table is the union of all
primary keys of entity sets that are on “many” side
– That is it, we are done.
Example – N-ary Relationship Set
P-Key1 P-Key2 P-Key3 A-Key D-Attribute
9999 8888 7777 6666 Yes
1234 5678 9012 3456 No
E-Set 1
P-Key1
Another Set
* Primary key of this table is P-Key1 + P-Key2 + P-Key3
D-Attribute
A relationship
A-Key
E-Set 2
P-Key2
E-Set 3
P-Key3
Composite Attributes
• Composite attributes are flattened out by
creating a separate attribute for each
component attribute
– Example: given entity set customer with composite
attribute name with component attributes first_name
and last_name the schema corresponding to the
entity set has two attributes
name_first_name and name_last_name
Representing Composite Attribute
• Relational Model Indivisibility Rule Applies
• One column for each component attribute
• NO column for the composite attribute itself
Professor
SSN Name
Address
SSN Name Street City
9999 Dr. Smith 50 1st St. Fake City
8888 Dr. Lee 1 B St. San Jose
Street City
Representing Multivalue Attribute
• For each multivalue attribute in an entity
set/relationship set
– Build a new relation schema with two columns
– One column for the primary keys of the entity
set/relationship set that has the multivalue attribute
– Another column for the multivalue attributes. Each
cell of this column holds only one value. So each
value is represented as an unique tuple
– Primary key for this schema is the union of all
attributes
Example – Multivalue attribute
SID Name Major GPA
1234 John CS 2.8
5678 Homer EE 3.6
Student
SID Name
Major GPA
Stud_SID Children
1234 Johnson
1234 Mary
5678 Bart
5678 Lisa
5678 Maggie
Children
The primary key for this
table is Student_SID +
Children, the union of all
attributes
13
Schemas Corresponding to Aggregation
For example, to represent aggregation manages between
relationship works_on and entity set manager, create a
schema
manages (employee_id, branch_name, title, manager_name)
Representing Aggregation
Student
Name
SID
Advisor Professor
SSN Name
Dept
Dept
Name
Code
member
SID Code
1234 04
5678 08
Primary Key of Advisor
Primary key of Dept
Related Documents
