You are on page 1of 16

CSCE 2501

Fundamentals of Database Systems


Part 4. Relational Data Model

Assoc. Prof. Mona Farouk


Dept. of Computer Science & Engineering, AUC
Dept. Of Computer Engineering, CUFE
CSCE 2501 - Fall 2021

Outline

▪ Relational Data Model

▪ Relational Data Structure

▪ ERD → Relational Model

▪ Relational Integrity Constraints

▪ Primary Keys & Foreign Keys


CSCE 2501 - Fall 2021

Relational Data Model


▪ Relational Data Model was first introduced by Codd in 1970

▪ RDM is based on a very simple and uniform data structure - the relation
▪ The relation resembles a table or a simple file

▪ The database is represented as a collection of relations

▪ Each relation contains a collection of tuples (rows in a table)


▪ A tuple is a collection of related data values representing an entity

▪ Each relation has a set of attributes (column name) describing the entity type the
relation represents.

▪ Relation degree is the number of attributes

▪ The domain of an attribute is all the possible values that a given entity can draw its
actual value for the target attribute from
▪ Each domain has a data type which defines the types of the values in the domain for the attribute
CSCE 2501 - Fall 2021

Relational Data Structure


Names Genders Numbers Dates
National IDs
________________
__________
__________
________________
________________
_________
_________
_________
______
______
______
______
______
______
Domains
__________ ________________
_________ ______ ______
__________ ________________

Primary Key Employee


National_ID Name Gender Salary Birthdate Attributes

1860213213563 Ahmed Alaa M 5000 13/11/1986


Relation
2884235634235 Yara Magdy F 7000 10/03/1984 Tuples

1832212456345 Mohamed Nagy M 6500 14/6/1985

Degree

Primary Key
The unique identifier for the relation / table. It can be either a single attribute
or a
collection of attributes that are unique for each entity / row in the table
CSCE 2501 - Fall 2021

Properties of Relations

▪ There are no duplicate tuples


▪ The relation / table can be viewed mathematically as a set - no repetitive elements
▪ An important corollary → even if there is no unique single attribute, the collection of all attribute
values are unique for each tuple (following from the no duplicate property) → There is always a
primary key

▪ Tuples in a relation are unordered


▪ Following from the mathematical representation as a set
▪ There is no positional ordering / referencing possible. e.g. there is no such thing as the “5 th” tuple
of the “next” tuple

▪ Attributes in a relation are unordered


▪ The schema describing the set of attributes for a given relation can also be viewed as a
mathematical set - unique and unordered

▪ Attribute values are all atomic


▪ All relations must be normalized - there are no composite or multi-valued attributes. Every
attribute should be represented to accept single, atomic values
CSCE 2501 - Fall 2021

ERD → Relational Model : Entities


Entities are converted directly into relations / tables with the same set of attributes

Name Number

Project Location Project (Name, Number, Location)

Middle Last
First

Name National ID

Gender
Employee Employee (National_ID, FirstName, MiddleName, LastName,
Address
Gender, Address, Salary, Birthdate)
Salary
Birthdate Composite attributes are split into their individual components
CSCE 2501 - Fall 2021

ERD → Relational Model : Entities

Multivalued attributes are split into a separate relation / entity with a primary key
consisting of the attribute itself and the primary key of the main entity
Name Number
Department (Name, Number)
Department Location DepartmentLocation(Number, Location)

Weak entities are represented as either a composite attribute in the owning relation or as
a separate relation with the primary key copied from the owning relation

Gender Birthdate
Dependent Dependent (National_ID, Name, Birthdate, Relationship,
Name
Gender)
Relationship
CSCE 2501 - Fall 2021

ERD → Relational Model: Relationships


Relationships are converted also into relations / tables with attributes composed of the
primary keys of the associated entities and the attributes of the relationship itself
Hours

M N
Employee Works on Project

EmployeeProjects (National_ID, P_Number, HoursCount)

One-to-many relationships can be represented by including the primary key of the one
relation into the attributes of the many relation → Foreign Key
1 N
Department Controls Project

Project ( Number, Name, Location, Dept_Number)

Foreign Key
CSCE 2501 - Fall 2021

ERD → Relational Model: Relationships


One-to-one relationships can be represented by including the primary key of any of the
relations into the attributes of the other relation
1 1
Employee Manages Department

Employee (National_ID, FirstName, MiddleName, LastName,


Gender, Address, Salary, Birthdate,
Dept_Number)

Foreign Key

OR

Department (Name, Number, Manager_National_ID)

Foreign Key
CSCE 2501 - Fall 2021

Relational Integrity Constraints

▪ Integrity constraints ensure that all the data stored in the database is accurate and
consistent

▪ Specific Integrity Constraints


▪ Applies to specific database to enforce the business logic / data requirement
▪ e.g. A student can be registered to a minimum of 3 courses and a maximum of 7 courses

▪ General Integrity Constraints


▪ These are constraints that apply to all relational databases in any RDBMS
▪ There are two types of general Integrity Constraints:
▪ Entity Integrity Constraint → Primary Key
▪ Referential Integrity Constraint → Foreign Key
CSCE 2501 - Fall 2021

Primary Key

▪ Candidate Keys are the set of single attributes (or sets of attributes) K that can
uniquely identify every tuple in a given relation

▪ Properties of Candidate Keys


▪ Uniqueness: No two tuples in the target relation has the same value of K
▪ Minimality: If K consists of multiple attributes, then no single attribute from K can be removed
without violating the uniqueness constraint
e.g. K= (National_ID, Gender) cannot be considered a candidate key for the Employee relation as
the Gender attribute can be removed and the uniqueness will still be preserved

▪ Primary Key is chosen among the set of available candidate keys


▪ If there is only a single candidate key, then it is the Primary key for the relation

▪ Primary key provides the basic mechanism for identifying a specific tuple in a
relation
CSCE 2501 - Fall 2021

Entity Integrity Constraint

No component of the primary key of any base relation is allowed to have a Null
value

▪ Following from the fact that the primary key is used to identify tuples in a relation, if
the primary key is allowed to have null values, the corresponding tuples are
unidentifiable
CSCE 2501 - Fall 2021

Foreign Keys

▪ Foreign Key is an attribute (or set of attributes) that are added to the relational
model to represent a relationship between two relations
▪ The values of the foreign key in a given relation are required to match the values of the primary
key of the associated relation in the represented relationship

▪ Properties of Foreign Keys


▪ Each value of foreign keys can be wholly (if composite) null or wholly non-null
▪ There exists a base relation with a primary key PK such that each non-null value of the foreign
key is identical to the value of PK of some tuple in the base relation
▪ The two relations might not be different (e.g. Employee has supervisor_national_id as a foreign
key referencing the primary key national_id of the same relation)
▪ The foregin key and the corresponding primary key must be defined on the same domain
▪ Foreign keys can accept nulls in partial relationships (e.g. no supervisor for the CEO)
CSCE 2501 - Fall 2021

Referential Integrity Constraint

No unmatched foreign key values are allowed in a database

▪ For non-null foreign key values, there should always be a matching value in the
primary key values in the target relation
▪ No tuple should reference another tuple that doesn’t exist in the target relation
CSCE 2501 - Fall 2021

Case Study: Company X Database - ERD


StartDate
Middle Name
First Last Manages Number
1 1

Name National ID
Department
Gender N 1
Works for
Employee Locations
Address # Employees
1
Salary Hours
N Controls
1 M
Birthdate 1
supervise
Owns Works on N
N Name Number
N

Gender Birthdate Location


Project
Dependent
Name Relationship
CSCE 2501 - Fall 2021

Case Study: Company X Database - Relational Model


PK

Employee (National_ID, FName, MName, LName, Gender, Address, Salary, Birthdate,


Supervisor_National_ID, Dept_No)
FK (Employee) FK (Department)

PK
Department (Dept_No, Dept_Name, Manager_National_ID, Manager_Start_Date)
FK (Employee)
PK PK
DepartmentLocations (Dept_No, Location) Project (P_No, P_Name, Location, Dept_No)
FK (Department) FK (Department)
PK PK
WorksOn (National_ID, P_No, Hours) Dependent (National_ID, Name, Gender, BDate, Relationship)
FK (Employee) FK (Project) FK (Employee)

You might also like