Lecture 4:
Logical database design and
the relational model
Peter kaaya
Reference books
• Connoly:- Dr Thomas , Begg. () Database systems: a practical
approach to design, implementation and management. 3rd Ed.
• Elmasn R.N avath () Fundamentals of database systems
Relational model concepts
• A relation is a mathematical concept based on idea of
sets.
• Its strength comes from the formal foundation
provided by the theory of relation
• The model was proposed by Dr. E.F Codd
Relation
• A table of values
• It may be thought of as a set of rows.
• A relation may alternatively be thought as a set of columns
• Each row represent a fact which corresponds to real world
entity/relationship
Cont..
• A relation may be defined as a schema
• Schema of a relation: R: (A1,A2,A3,---An)
• E.g. customer (cust_id, cust_name, address, phone);
• A customer entity is a relation defined over four attributes each of
which has a domain/set of valid values
CUSTOMER
Cust_id
Cust_name
Address
phone
• To convert it into a corresponding relation, write the entity name
instead of R write CUSTOMER
• i.e CUSTOMER (cust_id, cust_name, address,phone); cust_id (PK)
A relation
• Is a named, two dimensional table of data
• A table consists of rows and columns
• Row (Record) and column (attribute/field)
Cont…
INFORMA TERMS FORMAL TERMS
TABLE RELATION
COLUMN ATTRIBUTE/DOMAIN
ROW TUPLE/RECORD
VALUES IN A COLUMN DOMAIN
TABLE DEFINITION SCHEMA OF A RELATION
POPULATED TABLE EXTENSION (when you enter actual values)
ATRIBUTES
S_name SSN HOME_PHONE ADDRESS OFFICE_PHN AGE GPA
Pamela 201-001-235 2568974
TUPLES
Moprocco Nil 2548796
halima Nil 2501565
• To create a relational schema then:
STUDENT (s_name, SSN,Home_Phone, address, Office_phn, Age, GPA);
PROPERTIES OF A GOOD RELATION
a) Must have a unique name
b) Every attribute value must be atomic (not multivalued, not
composite)
c) Every row must be unique (cant have 2 rows with exactly same
values for all their fields)
d) Attributes (Columns) in a table must have a unique name e.g. no
two customer IDs
e) The order of the rows/columns must be irrelevant i.e.
R(a1,a2,a3,a4….an)= R(a1,an,a3,a2,…a4)
Correspondence with ER Model
• i.e transforming from ER diagram into ER Model
• Relations/tables corresponds with entity types and with many to
many relationships
• Rows corresponds with entity instances and with many to many
relationship instances
• Columns corresponds with attributes
• The word RELATION (in a relation table) is NOT the same as the word
RELATIONSHIP (in ER Model)
Key fields
• PRIMARY KEY: Refers to an attribute (any key) which uniquely identify
your table
• E.g STUDENT (Reg_No, std_name, gender)
• FOREIGN KEY: an identifier that enables a dependent relation (on
many side of a relation) to refer to its parent relation (on the side of a
relation)
• Keys can be simple (a dingle field) or composite (more than )
• In foreign key, we have to establish a link between a table COURSE
and a table STUDENT
• We take a primary key from one relation to another
• E.g. taking reg_no to be a primary key
STUDENT (reg_no, st_name, gender)
COURSE (c_code, c_name, reg_no)
• Keys usually are used as indexes to speed up user responses
Schema for four relations
CUSTOMER
Cust_id Cust_name Cust_address Gender city
ORDER
Order_id Order_date Cust_id
ORDER_LINE
Order_id Prod_id quantity
PRODUCT
Prod_id Prod_desc Prod_finish Prod_price Prod_line
INTEGRITY CONSTRAINTS
• Domain constraint
• Allowed values for an attribute
• E.g. Domain for AGE can be only numbers
• i.e domain_numbers (0-999)
• Domain:- 3 digits
• Entity Integrity
• Means that NO primary key should remain EMPTY/NULL without any input
ie. The primary key field must have data
• NB :Zero is an input and make sure that no value has been entered
• PK must not be null because it is the one that uniquely identifies that row
ACTION ASSERTION
• Refers to a statement of a constraint / control on the actions of the
organization
• Business rule constraint:: MUST/MAY
• Concerned mainly on business rules by looking if its optional
/mandatory. If its optional its constraint may be MAY
REFERNTIAL INTEGRITY
• Mainly concerned about foreign keys.
• Its rule states that : any foreign key value must match a primary key
value in a relation of one side i.e. foreign key must be migrating to
the many side
• E.g. DELETE rule
• Restricts. Don’t allow delete of PARENT side if related row exists
For example:
CUSTOMER
Cust_id Cust_name Cust_address Gender city
ORDER
Order_id Order_date Cust_id
ORDER_LINE
Order_id Prod_id quantity
PRODUCT
Prod_id Prod_desc Prod_finish Prod_price Prod_line
DELETE Rules:
• Don’t allow delete of parents side if related row exists
CASCADE:
• Automatically delete dependent side rows that correspond with the
parent side row to be deleted
SET TO NULL
• Set the foreign key in the dependent side to NULL if deleted from
parent side table .i.e. NOT allowed for weak tables
MAPPING REGULAR ENTITIES TO RELATIONS
1. SIMPLE ATTRIBUTES
• ER attributes map directly onto the relation e.g. name, age, sex, gender etc
E.g. convert a simple entity into a relation CUSTOMER
Cust_id
Cust_name
Address
phone
Customer relation
CUSTOMER
Cust_id, cust_name, address, phone
2. COMPOSITE ATTRIBUTES
Use only their simple , component attributes
CUSTOMER
e.g. P_O_box, city, House_no, postal_code etc
Cust_id
i.e an attribute containing some more attributes within it
Cust_name
e.g. name:- middle_name, sir_name, tour_name Address
use only their simple component attributes (street,city,state)
phone
Relation with address detailed
CUSTOMER
Cust_id Cust_name street City state phone
• We did not put customer address because of its atomicity (single
attribute should be single because no multiple attributes are needed
in a single attribute at a time
3. MULTIVALUED ATTRIBUTES
• Becomes a separate relation with a foreign key taken from the
superior entity. e.g. CUSTOMER
Cust_id
Cust_name
Address
Skills (multivalued attribute)
CUSTOMER
Cust_id Cust_name street City state phone
CUSTOMER_SKILLS
Cust_id skill
STRONG ENTITIES
• Exist independently of other types of entities
• Has its own unique identifier
• Identifier is underlined by a single line
WEAK ENTITIES
• Dependent on a strong entity (identifying owner) cant exist on its own
• Doesn’t have a unique identifier (only a particular identifier)
• Partial identifier underlined with a double line
• Entity box has double line
• Primary key can depend on its own without relationship with other
dependent entity/ies
EMPLOYEE DEPARTMENT
Emp_name dept_name
(f_name,m_name,l_na
Emp_id me)
dob
MAPPING WEAK ENTITIES
• Becomes a separate relation with a foreign key from a superior entity.
• Primary key is composed of:-
Relations Dependent
EMPLOYEE DEPARTMENT
Emp_id, Emp_name dept_name
(f_name,m_name,l_name)
Mapping binary relationships
• One-to-many primary key on one side becomes a foreign key on the-
many side . It always navigate to the many side
• Many-to-many: Creates a relation with the primary keys of two
entities and its primary key
• One-to- one: Primary key on mandatory side becomes a foreign key to
many-side
• Relationship between teacher and course
Mapping the relationship
CUSTOMER
Cust_id Cust_name street City state zipcode
ORDER
order_id order_name Cust_id
MANY TO MANY RELATIONSHIP
EN
D
OF
TO
DA
YS
L EC
T UR
E
