Database Systems

Chapter 2: Database Design

session 2:
Relational Data Model

1
 Outline

1 Relational Data model

2 ER to Relational Mapping

2
 Relational Database
q Basic structure:
§ A relational database consists of a collection of tables,
each of which is assigned a unique name.
§ Tables are also known as Relation.
§ The columns in a relation are known as attributes. The
order of attributes is insignificant
§  A tuple is a row of a relation. They are also called the
records.
• Each tuple is unique.
• The order of tuples is insignificant
§  Tables are related to each other through some shared
attributes.

3
 Relational Database
§ The set of allowed values for each attribute is
called the domain of the attribute
§ Attribute values are (normally) required to be
atomic; that is, indivisible
§  A null value is a special value that signifies
that the value is unknown or does not exist.
§ The null value causes complications in the
definition of many operations

4
 Relational Database
q Example: Student Relation

5
 Relational Database
q Example: Instructor Relation attributes
(or columns)

tuples
(or rows)

6
 Relation Scheme
q It is a named of a relation defined by a set of attributes
and their corresponding domains.
q Common convention:
§ RelationName (attribute1, attribute2,….,attribute_n)
§ The primary key is underlined.
q Example:
§ Instructor (ID, name, dept_name, salary)
§ Branch(branchNo, street, city, postcode)

7
 Relation Schema
q  Characteristics of relation scheme

8
 Relational Database Schema
q  It is a sets of relation schema.
q Example: the relational database schema for
COMPANY = {EMPLOYEE, DEPARTMENT, DEPENDENT, PROJECT}

9
 Relational Database Schema
q The relation schema normally represented as
follows:
EMPLOYEE (SSN, FNAME, LNAME, MINIT, BDATE, ADDRESS, SEX, SALARY,
SUPERSSN,DNO)
DEPARTMENT (DNUM, DNAME, MGRSSN, MGRSTTDATE)
q Relation instance
§ Is a tuple at a specific moment of time
§ Eg: Branch (BranchNo, Street, City, PostalCode )
The relation instance for branch is:
ü (B005, 55 Jln Dobi, Johor Bahru, 80100)
ü (B006, 55 Jalan Perai, Johor Bahru, 80000)
§ The relation instance change when tuple is updated,
deleted or inserted.

10
 Relation Keys
q Refers to the important attribute in an entity.
q Determine the uniqueness of an row in given table.
q Identifiers for each rows.
q An attribute or more than one attributes can be
declared as keys depending on situations.
q Types of keys:
§ Superkey
§ Candidate Key
§ Alternative key
§ Primary Key
§ Foreign key

11
 Superkey
q Superkey is a an attribute, or set of attributes which
can uniquely identify a tuple in a relation.
Example: Student( StudentId, firstName, lastName, courseId)






The super key can be any of the following:
ü StudentId
ü StudentId, lastName
ü StudentId, firstName, lastName
12
 Candidate Key
q  A candidate key is a minimal superkey. A superkey
that does not contain a subset of attributes that is
itself a superkey. This means you cannot remove any
fields from candidate key, else it will not be able to
uniquely identify the rows.
q There can be more than one candidate key in a table
q When a key consists of more then one attribute it is
known as the composite key
q Example: The candidate key for Student relation can
be any of the following:
ü StudentId
ü StudentId, lastName
13
 Alternative Key
q An alternate key is any candidate key that is not
primary key.
q Alternate keys are sometimes referred as
secondary keys
q The secondary key is defined as a key that is used
strictly for data retrieval purposes

14
 Primary key
q  A primary key is one of the candidate keys selected
to uniquely identify a tuple in a relation.
q Which one?
§ Primary keys must be chosen with care. Ex: name, SSN, ID,
…
§ The primary key should be chosen such that its attribute
values are never, or are very rarely, changed. Ex: address,
mobile,…
q Each table must have primary key.
q Cannot be NULL value to maintain Entity Integrity.
q Example: for Student relation
§ StudentId can be chosen to be the primary key
15
 Foreign Key
q A foreign key is an attribute (or a set of attributes)
whose values match the primary key values in
related relation.
§ Referencing relation
§ Referenced relation
q Example Course(courseId, courseName)
Student(StudentId, firstName, lastName, courseId)

• The attribute courseId is the primary key of Course

• The attribute courseId in Student relation is a foreign key
• Student relation is called referencing relation of the foreign key
constraint.
• Course relation is called the referenced relation
16
 Foreign Key
q Example

17
 Foreign Key
q Another Example
§ Branch (branchNo, street, city, postCode)
§ Staff (staffNo, fName, lName, position, sex, DOB, salary,
branchNo)
§ Staff has a Foreign Key is branchNo references Branch (branchNo)

18
 Relation Keys
Group discussion

19
 Integrity rules
q To have a good design, a database must have
integrity rules.
q Constraint or restriction that apply to all instances
of the database.
q Integrity rules consists of
§  Entity Integrity
§ Referential Integrity

20
 Entity Integrity
q Requirement
§ All Primary Key entries are unique, and no part of a primary
key may be NULL.
q Purpose
§ Each row will have a unique identity, and foreign key values
can properly reference primary key values
q Example
§ In the Employee table, EmpNo is the primary key, it can not
have a duplicate number (All employees are UNIQUELY
identified by their EmpNo number). And it can not be NULL.
§ The OrderDetail has a composite primary key OrderNo and
ProductNo so to insert a new row both values must be
known.
21
 Entity Integrity
q  Other integrity rules that can be enforced in the
relational model are the NOT NULL and UNIQUE
constraints.
§ The NOT NULL constraint can be placed on a column to
ensure that every row in the table has a value for that
column.
§ The UNIQUE constraint is a restriction placed on a column to
ensure that no duplicate values exist for that column

22
 Referential Integrity
q  Requirement
§  Every non-null foreign key value must reference an existing
primary key value in the referenced relation. Or
§  The foreign key value can be null.
q Purpose
§ Makes it possible for an attribute NOT to have a
corresponding value, but will be impossible to have an invalid
entry.
§ The enforcement of the referential integrity rules makes it
impossible to delete a row in one table whose primary keys
has mandatory matching foreign key values on another table.

23
 Referential Integrity
q  Example: Branch and Staff Relation.

24
 Referential Integrity
q  Example: Branch and Staff Relation.
§  It is not possible to create a staff record in Staff Relation with
branchNo B025, unless there is already record for branch
B025 in Branch relation.
§  However, we should be able to create new staff
record with NULL branch number to allow the situation
where a new member staff has joined the company but
has not yet assigned to a particular Branch.

25
 Relationships within the
Relational Database
q The 1:M relationship is the relational modeling
ideal. Therefore, this relationship type should be the
norm in any relational database design.
q The 1:1 relationship should be rare in any relational
database design.
q M:N relationships cannot be implemented as such
in the relational model. Later in this section, you will
see how any M:N relationship can be changed into
two 1:M relationships.


26
 1-M Relationship
q Example: The ERM’s 1:M relationship between COURSE
and CLASS
§ Each COURSE can have many CLASSes, but each CLASS
references only one COURSE

27
 1-M Relationship
q The implemented 1:M relationship between PAINTER and
PAINTING in relational database

28
 1-1 Relationship
q Example: The ERM’s 1:1 relationship between
PROFESSOR and DEPARTMENT
§ one department chair—a professor—can chair only one
department, and one department can have only one
department chair.

29
 1-1 Relationship
q  The implemented 1:1 relationship between
PROFESSOR and DEPARTMENT in relational database

30
 M-N relationship
q  The ERM’s M:N relationship between STUDENT and
CLASS
§ Each CLASS can have many STUDENTs, and each
STUDENT can take many CLASSes.

31
 M-N relationship
q  The ERM’s M:N relationship between STUDENT and
CLASS
§ Each CLASS can have many STUDENTs, and each
STUDENT can take many CLASSes.

q In relational database, many-to-many (M:N) relationship

can easily be implemented by creating a composite entity
(also referred to as a bridge entity or an associative entity).
32
 M-N relationship
q  The composite entity structure includes—as foreign
keys—at least the primary keys of the tables that are
to be linked.
§ The database designer has two main options when
defining a composite table’s primary key:
• use the combination of those foreign keys or
• create a new primary key
q The composite entity is called a linking table when
implementing a composite entity in relational
database.


33
 M-N relationship
q Converting the M:N relationship into two 1:M relationships

34
 Relationships within the
Relational Database
q The relational diagram for the Ch03_TinyCollege
database

35
 ER Model to Relational
mapping
q Mapping ERM (Entity Relationship Model) to Relation
§ Step 1: Mapping of Regular Entity Types
§ Step 2: Mapping of Weak Entity Types
§ Step 3: Mapping of Binary 1:1 Relationship Types
§ Step 4: Mapping of Binary 1:N Relationship Types
§ Step 5: Mapping of Binary M:N Relationship Types
§ Step 6: Mapping Unary Relationship Types
§ Step 7: Mapping of Multivalued attributes
§ Step 8: Mapping of n-ary Relationship Types
§ Step 9: Mapping Supertype/Subtype Relationships

36
 Step 1: Mapping strong/regular
Entity
§ For each strong/regular entity, create a relation that
includes all the simple attributes
§  Primary key of the entity becomes the primary key of
the relation.
§  Exclude multivalued attribute from the mapping
relation.
§  Example:




⇒ Employee(EmployeeID, FirstName, LastName, Gender)
Note: Phone is a multivalued attribute.

 Step 1: Mapping strong/regular
Entity
§ When a regular entity type has a composite attribute,
only the simple components of the composite
attribute are included in the new relation as its
attributes
§  Example:


⇒ Employee(EmployeeID, FirstName, LastName,
House_Number, Street, City, PostalCode)


 Step 2: Mapping of Weak Entity
§ Create separate relation and include all simple
attributes
§ The primary key of the relation is the combination of all
the primary key attributes from the owner and the
partial key of the weak entity, if any

=> Dependent(EmployeeID, DependentID, Name, DOB,

Gender, Relationship)
Employee(EmployeeID, FirstName, LastName, Gender)

 Step 3: Mapping Binary 1:1
relationship
q Step 3: Mapping Binary 1:1 relationship
Before tackling a 1:1 relationship, we need to know
its optionality.
There are three possibilities the relationship can be:
1. mandatory at both ends
2. mandatory at one end and optional at the other
3. optional at both ends
 Step 3: Mapping Binary 1:1
relationship
1. Mandatory at both ends
q Combine two entity into one when the
relationship is mandatory at both ends.
§  The choice of which entity type subsumes the other depends on which is
the most important entity type (more attributes, better key, semantic
nature of them).
§  The key of the subsumed entity type becomes a normal attribute
q When not to combine a 1:1 mandatory
relationship:
§  the two entity types represent different entities in the ‘real world’.
§  the entities participate in very different relationships with other entities.
§  efficiency considerations when fast responses are required or different
patterns of updating occur to the two different entity types
=> The primary key of one entity type comes the foreign key in the other.

 Step 3: Mapping Binary 1:1
relationship
q Example: Two entity types; employee and contract.
§ Each member of employee must have one contract and each contract must
have one member of employee associated with it.
§ It is therefore a mandatory relations at both ends.

 Step 3: Mapping Binary 1:1
relationship
3 options to mapping:
§ Combine two entity into one.
Employee(EmployeeID, FirstName, LastName, Gender, ContractID,
StartDate, StartEnd, Position, Salary)
q or kept apart and a foreign key used
Employee(EmployeeID, FirstName, LastName, Gender, ContractID)
Contract(ContractID, StartDate, StartEnd, Position, Salary)
q or
Employee(EmployeeID, FirstName, LastName, Gender)
Contract(ContractID, StartDate, StartEnd, Position, Salary,
EmployeeID)
 Step 3: Mapping Binary 1:1
relationship
2. Mandatory at one end and optional at the other
§ Take the primary key from the ‘mandatory end’ and add it to
the ‘optional end’ as a foreign key.
§ The entity type of the optional end may be subsumed into the
mandatory end as in the previous example.
§ It is better NOT to subsume the mandatory end into the optional
end as this will create null entries.
§ Given entity types A and B, where A, B is in a relationship where
the A end it optional, the result would be:
A (primary key,attribute,...,foreign key to B)
B (primary key,attribute,...)

 Step 3: Mapping Binary 1:1
relationship
2. Mandatory at one end and optional at the other
§ Example: Contract is optional (each employee may have at most
one contract)

=> Employee(EmployeeID, FirstName, LastName, Gender)
=> Contract(ContractID, StartDate, StartEnd, Position, Salary,
EmployeeID)
 Step 3: Mapping Binary 1:1
relationship
2. Optional at both ends
q Use a foreign key approach.
q Example: Each staff member may lease up to one car, Each car
may be leased by at most one member of staff

=>Can not combine two entity into one.

Employee(EmployeeID, FirstName, LastName, Gender)
Car(RegID, Model, Year, Colour, EmployeeID)
 Step 4: Mapping Binary 1:M
relationship
q The primary key on the ‘one side’ of the relationship is added to
the ‘many side’ as a foreign key.
q Example:

=> Department(DepartmentID, DempartmentName, Phone)

=> Employee(EmployeeID, FirstName, LastName, Gender,
DepartmentID)
 Step 4: Mapping Binary 1:M
relationship
q Parallel relationships occur when there are two or more
relationships between two entity types
q Example:

q In order to distinguish between the two roles we can give

the foreign keys different names.
=>Employee(EmployeeID, FirstName, LastName, Gender,
DepartmentID)
=>Department(DepartmentID, DepartmentName,
ManagerID)
 Step 5: Mapping Binary M:N
relationship
q Create a new relation containing the primary keys of both
participating entity types and descriptive attribute (if any)
q These primary keys form a composite primary key of the new
relation.

=> WorksOn(EmployeeID, ProjectID, Hours)

 Step 6: Mapping Unary
relationship
q Unary relationships (or recursive relationships) is
one in which a relationship can exist between
occurrences of the same entity set.
q Example:

1-1 relationship 1-M relationship M-N relationship

 Step 6: Mapping Unary
relationship
q Mapping the 1:1 unary relationship “EMPLOYEE is
married to EMPLOYEE”
=> Employee( EmpNum, Emp_Lname, Emp_Fname,
Emp_Spouse)
q Implementation

=>The foreign key is the primary key of the same table,

but is given a different name.
 Step 6: Mapping Unary
relationship
q Mapping the 1:M unary relationship “EMPLOYEE
manages EMPLOYEE”
=> Employee( Emp_Code, Emp_Lname, Emp_Manager)
q Implementation

=>The foreign key is the primary key of the same table,

but is given a different name.
 Step 6: Mapping Unary
relationship
q Mapping the M-N unary relationship “COURSE requires
COURSE”
=> Course( Crs_code, Dept_code, Crs_Description, Crs_credit)
=> PreReq( Crs_code, Pre_Take)

 Step 7: Mapping Multivalued
Attributes
q Create a new relation R for each multivalued attribute
q Add primary key of the original entity to the new
relation R as a foreign key.
q The primary key of R is the combination of R and the
original entity. If the multivalued attribute is
composite, we include its simple components.

=> Phone(EmployeeID, PhoneNumber, type)
=>Employee(EmployeeID, FirstName, LastName,
Gender)
 Step 7: Mapping Multivalued
Attributes
q  Another example: In ER model

q In the relation shema:

=>Skill(SkillCode, Skill Title, Skill Type)
=>Possesses(EmployeeID, SkillCode)
=>Employee(EmployeeID, EmployeeName)
 Step 8: Mapping n-ary Relationship
types
q Mapping Ternary (and n-ary) relationship type:
§ One relation for each entity and one for the associative
entity
§ Associative entity has foreign keys to each entity in the
relationship
 Step 8: Mapping n-nary
Relationship types
q Example

q In relational schema

=>Vendor( VendorID,…)
=>Warehouse(WareHouseID,…)
=>Part(PartID,…)
=>Supply(VendorID, WareHouseID, PartID, shippingMode,
UnitCode)
 Step 8: Mapping n-nary
Relationship types
q Another example:

q In relational schema

 Mapping Supertype/Subtype
Relationships
q One relation for supertype and for each subtype
q Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
q Subtype attributes go into each subtype; primary
key of supertype relation also becomes primary key
of subtype relation
q 1:1 relationship established between supertype and
each subtype, with supertype as primary table

59
 Mapping Supertype/Subtype
Relationships
q Example

q Mapping

60
61