Scribd
Upload
83 views

Logical Database Design and The Relational Model: Peter Kaaya

This document summarizes key concepts about logical database design and the relational model. It discusses how a relation is a table of values that can be thought of as a set of rows or columns. Each row represents a real-world entity or relationship. The document also explains how entities and relationships from an ER diagram are mapped to relations, attributes, and keys in the relational model. Integrity constraints like domain constraints and referential integrity are also summarized.

Uploaded by

Robinson Joshua
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
83 views

Logical Database Design and The Relational Model: Peter Kaaya

This document summarizes key concepts about logical database design and the relational model. It discusses how a relation is a table of values that can be thought of as a set of rows or columns. Each row represents a real-world entity or relationship. The document also explains how entities and relationships from an ER diagram are mapped to relations, attributes, and keys in the relational model. Integrity constraints like domain constraints and referential integrity are also summarized.

Uploaded by

Robinson Joshua
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

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

You might also like