CHAPTER 3

THE RELATIONAL DATABASE MODEL

 Contents
2

 Logical view of data

 Table and their characteristics.
 Key
 Integrity Rules
 Data Dictionary and The System Catalog
 Relationship within Relational Database
 A Logical View of Data
3

 Relational model
 Enables programmer to view data logically rather
than physically

 Table
 Resembles a file from conceptual point of view
 Has advantages of structural and data
independence
 Easier to understand than its hierarchical and
network database predecessors
 Tables and Their Characteristics
4

 Table:
two-dimensional structure composed of rows and
columns

 Contains group of related entity occurrences = an

entity set
 Terms entity set and table are often used interchangeably
 Table also called a relation (Codd)

Table = Entity set = Relation

 Tables and Their Characteristics
5

1. A table is perceived as a two-dimensional structure composed of rows

and columns

2. Each table row (tuple) represents a single entity occurrence within the
entity set

3. Each table column represents an attribute, and each column has a

distinct name

4. Each row/column intersection represents a single data value

 Tables and Their Characteristics
6

5. All values in a column must conform to the same data format.

6. Each column has a specific range of values known as the attribute

domain

7. The order of the rows and columns is immaterial to the DBMS

8. Each table must have an attribute or a combination of attributes that

uniquely identify each row
Tables and Their Characteristics
Tables and Their Characteristics
 Keys
9

 Consists of one or more attributes that determine other

attributes
 Primary key (PK) is an attribute or a combination of attributes
that uniquely identifies any given entity (row)
 Key’s role is based on determination
 If you know the value of attribute A, you can look up (determine)
the value of attribute B
 The attribute B is functionally dependent on A if A determines B
 A determines B can be written as:
◼ A → B ; example: stuNum→stuName
◼ A→B,C,D ; example: StuNum→stuName, stuDOB, stuAddress
? Determinant ? dependent
 Dependencies
10

 Functional dependence: Value of one or more

attributes determines the value of one or more other
attributes
 Determinant: Attribute whose value determines another
 Dependent: Attribute whose value is determined by the
other attribute
 Full functional dependence: Entire collection of
attributes in the determinant is necessary for the
relationship
 Keys
11

 Composite key
 Composed of more than one attribute
 Key attribute
 Any attribute that is part of a key
 Superkey
 Any key that uniquely identifies each row. Example : stuNum,
stuNum+stuLname
 Candidate key
 A superkey without unnecessary attributes / minimal superkey
 Primary key is a superkey as well as a candidate key
 Example : stuNum+stuLname→ superkey but not
candidate key, because stuNum by itself is a candidate
key!
 Keys
12

 Secondary key
 Key used strictly for data retrieval purposes

 Foreign key (FK)

 An attribute whose values match primary key values in the
related table
 Keys
13

 Nulls
 No data entry
 Not permitted in primary key
 Should be avoided in other attributes
 Can represent
◼ An unknown attribute value
◼ A known, but missing, attribute value
◼ A “not applicable” condition
 Can create problems when functions such as COUNT,
AVERAGE, and SUM are used
 Can create logical problems when relational tables are
linked
Keys
 Keys
15

 Controlled redundancy
 Makes the relational database work

 Tables within the database share common attributes that

enable the tables to be linked together

 Multiple occurrences of values in a table are not

redundant when they are required to make the
relationship work

 Redundancy exists only when there is unnecessary

duplication of attribute values
 Keys
16

 Relational Schema
 A textual representation of the database tables

 Each table is listed by its name followed by the list of its

attributes in parentheses

 The primary key attribute(s) is (are) underlined

 Example:
VENDOR (VEND_CODE, VEND_CONTACT, VEND_AREACODE, VEND_PHONE)

PRODUCT(PROD_CODE, PROD_DESCRIPT, PROD_PRICE, PROD_ON_HAND, VEND_CODE)

Keys

 Relational Diagram
 Shows link between tables

 A primary key of one table (VENDOR) appears as the

foreign key in a related table (PRODUCT)
Keys
Integrity Rules

 Entity integrity
 Allprimary key unique and no part of a PK may
be null
 Referential integrity
 FK contains a value that refers to an existing valid
tuple (primary key) in another relation
 Entity Integrity

Referential Integrity
Integrity Rules
 Ways to Handle Nulls
22

 Flags: Special codes used to indicate the absence

of some value
 NOT NULL constraint - Placed on a column to ensure
that every row in the table has a value for that
column
 UNIQUE constraint - Restriction placed on a column to
ensure that no duplicate values exist for that column
 The Data Dictionary and System Catalog
23

 Data dictionary
 Provides detailed description of all tables found within the
user/designer-created database

 Contains (at least) all the attribute names and characteristics

for each table in the system

 Contains metadata—data about data

 Sometimes described as “the database designer’s database”

because it records the design decisions about tables and their
structures
A Sample Data Dictionary
 The Data Dictionary and System Catalog
25

 System catalog
 Contains metadata

 Detailed system data dictionary that describes all

objects within the database
◼ Table names, table’s creator, creation date,
number of columns in each table, data type
for each column, index filenames, index
creators, authorized users and access
privileges.
 Homonyms & Synonyms
 Homonyms  Synonyms
➢ Similar sounding words with ➢ Different names to
different meanings. describe the same
➢ Identical spelled words with attribute.
different meanings. ➢ In database – same
➢ In database – the use of the attribute occurs in different
same attribute name to label table with different names.
different attributes ➢ E.g: Auto and car→ same
➢ E.g :C_name in Customer meaning
table and C_name in
Consultant table.

26
 Relationships within the Relational
Database
27

 1:M relationship
 Relational modeling ideal
 Should be the norm in any relational database design

 1:1 relationship
 Should be rare in any relational database design

 M:N relationships
 Cannot be implemented as such in the relational model
 M:N relationships can be changed into two 1:M relationships
 The 1:M Relationship
28

 Relational database norm. Found in any database

environment
 Make sure that the primary key of the one is includes
as a foreign key in the table of the many.
The 1:M Relationship
The 1:M Relationship
The 1:M Relationship
 The 1:1 Relationship
32

 One entity can be related to only one other entity,

and vice versa
 Sometimes means that entity components were not
defined properly
 Could indicate that two entities actually belong in
the same table
 As rare as 1:1 relationships should be, certain
conditions absolutely require their use
The 1:1 Relationship
The 1:1 Relationship
 The M:N Relationship
35

 Can be implemented by breaking it up to produce a set of 1:M

relationships

 Can avoid problems inherent to M:N relationship by creating a

composite entity or bridge entity

 Composite entity table must contain at least the primary keys of

original tables

 Linking table contains multiple occurrences of the foreign key values

 Additional attributes may be assigned as needed

36
The M:N Relationship
 The M:N Relationship
38
 The M:N Relationship
39

Composite entity
40

Composite entity
 ERD for Tiny College
41
 Relational Diagram for Tiny College
42
 Data Redundancy Revisited
43

 Data redundancy leads to data anomalies

 Suchanomalies can destroy the effectiveness of the
database
 Foreign keys
 Control data redundancies by using common attributes
shared by tables
 Crucial to exercising data redundancy control

 Sometimes, data redundancy is necessary

 Data Redundancy Revisited
44
 Data Redundancy Revisited
45
 Indexes
46

 Arrangement used to logically access rows in a

table
 Index key
 Index’s reference point
 Points to data location identified by the key

 Unique index
 Index in which the index key can have only one pointer
value (row) associated with it
 Each index is associated with only one table
Indexes
48
Summary
 Tables are basic building blocks of a relational database
 Keys are central to the use of relational tables
 Keys define functional dependencies
 Superkey
 Candidate key
 Primary key
 Secondary key
 Foreign key
 Summary
49

 Each table row must have a primary key which

uniquely identifies all attributes

 Tables can be linked by common attributes. Thus, the

primary key of one table can appear as the foreign
key in another table to which it is linked

 Good design begins by identifying appropriate

entities and attributes and the relationships among the
entities. Those relationships (1:1, 1:M, and M:N) can be
represented using ERDs.
 Exercise
50

1.Briefly explain the terms listed below and DRAW example for
each:
i. primary key
ii. Foreign key
iii. Composite key

2. Based on the following business rules, create the Crow’s Foot

Entity Relationship Diagram (ERD)
 A medical doctor may treat many patients

 Some patients may be treated by more than one medical

doctor
 A patient may or may not have an insurance plan
51
52

Create ERD and relational diagram

 Exercise
53
 Exercise
54
 Answer the questions below based on the following relational schemas:
SCIENTIST(Sct_Id, Sct_Name, Sct_PhoneNo,Sct_Address)
EXPERIMENT(Exp_No, Exp_Name,Proj_Code)
PROJECT(Proj_Code, Proj_Name,Proj_StartDate)
SCIENTIST_EXPERIMENT(Sct_Id, Exp_No, Date,Time)
55
56