Advanced Data Base Management System

An Introduction to Relational
Databases
CHAPTER 3
 The Relational Model-
Introduction
 Proposed by Edgar. F. Codd(1923-2003) in the early
seventies.
 Most of the modern DBMS are relational.
 Simple and elegant model with a mathematical basis.
 Led to the development of a theory of data
dependencies and database design.
 Relational algebra operations –crucial role in query
optimization and execution.
 Laid the foundation for the development of
 Tuple relational calculus and then
 Database standard SQL
 Relational Model Basic
The relational model gives us a single way
to represent data: as a two-dimensional
table called a relation.
 Attributes
 Schemas
 Tuples
 Domains
Relational Databases: Terminology
 The Relational Model
 Relational system based on Relational Model of
data
 Structural
 Data is perceived by users as tables, ONLY tables
 Integrity
 Data subject to specific integrity requirements
 Manipulation
 Operators derive tables from other tables
• Select
• Project
• Join
 Properties of Relational Model
 No Duplicate Tuples – A relation cannot contain two or
more tuples which have the same values for all the
attributes. i.e., In any relation, every row is unique.
 Tuples are unordered – The order of rows in a relation is
immaterial.
 Attributes are unordered – The order of columns in a relation is
immaterial.
 Attribute Values are Atomic – Each tuple contains exactly one
value for each attribute.
 It may be noted that many of the properties of relations
follow the fact that the body of a relation is a
mathematical set.
 Relation Scheme
 Consists of relation name, and a set of attributes or field
names or column names. Each attribute has an
associated domain.
Example:
student ( studentName : string,
rollNumber :string,
phoneNumber : integer,
yearOfAdmission : integer,
branchOfStudy : string )

 Domain–set of atomic(or indivisible) values –data type

 Schema versus Instance
 DB instances change continuously
(e.g., movies are added, deleted, changed,…)
 The schema is stable
(attributes change almost never)
 A Relational DB instance is the set of tuples that are
‘now’ in the DB
 When designing the DB only the schema is important
(=the structure of the data/DB)
 We only imagine typical instances to help us with the
design
 Intentional level: schema
 Extensional level: instances
 The Relational Model –
Logical/Physical
 Data is perceived by the user as tables
 DBMS can store the data on disk in other
formats
 Sequential files, indexes, pointer chains, hashing
 The Information Principle: Information
represented by rows and columns, only
 Tables are joined logically based on user
understood column values
 The Relational Model –
Integrity
 Every table has a “primary key”
 Column whose value implies values in the other
columns
 Some tables have a “foreign key”
 References primary key of another table
 Used to maintain links between tables
 Column whose value implies values in columns in
another table
 Keys for a Relation
 Key: A set of attributes K, whose values uniquely identify a
tuple in any instance. And none of the proper subsets of K
has this property. Example: {rollNumber} is a key for
student relation.
 A relation can have more than one key.
 Each of the keys is called a candidate key
Example: book (isbnNo, authorName, title, publisher, year)
(Assumption : books have only one author )
Keys: {isbnNo}, {authorName, title}
 Superkey: A set of attributes that contains any key as a
subset.
 Primary Key: One of the candidate keys chosen for
indexing purposes ( More details later…)
 Relations and Relvars
 A relation is inherently a specific set of values
 A relation variable, or relvar, is the structure into
which values are set
 Relvars can have different values at different
times
 Relations vs. Types
 Relational model includes an open-ended set of
types i.e. users can define their own types
 A type can be regarded as the set of all its
possible instances
 e.g. Emp# as a type is the set of all possible
employee numbers
 Types and their Predicates
 Every relation – that is to say – every relation
value – is divided into two – head and body
 Head has name and type for the column
 Body has rows that conform to the head
 e.g. Emp# is the name of the column, and could
also be its type, if we have defined such a type;
otherwise the type could be NUM
 Types and their Predicates
 For any relation, the head denotes a predicate
 A predicate is a truth-valued function that can
take parameters
 A true proposition is obtained from the predicate
by instantiating it (sending in arguments in place
of the parameters)
 For any relation, each row of the body denotes a
true proposition
 Types and their Predicates
 Predicate example:
 Employee EMP# is named ENAME, works in
department DEPT#, and earns salary SALARY
 EMP#, ENAME, DEPT#, and SALARY are
parameters as well as table column headings
 True proposition example:
 Employee E1 is named Lopez, works in department
D1, and earns salary 40k
 E1, Lopez, D1, and 40k are arguments as well as
table atomic values
 Relational Model Operators
Select
 Extracts specified rows from a table
Project
 Extracts specified columns from a table
Join
 Combines two tables into one
 Example

The departments-and-employees Database

 Select, Project and Join

Example of Select, Project and Join

 Optimization
 Relational operators are set operators
 Relational languages are less procedural than
procedural languages
 Relational languages function at a higher level of
abstraction than do procedural languages
 Relational Database Management
implementations require an optimizer
 Optimizer handles the “how” after the user
specifies the “what result”
 Base Relvars and Views
 Base relvars
 Created in SQL via CREATE TABLE
 Views can be derived from base relvars
 Created in SQL via CREATE VIEW
 View relvars are stored in the catalog
 View values do not exist separately
 View values are whatever populates the base
relation at the time the user queries the view
 The user perceives the view as a real relation
 Transactions
 A transaction is a logical unit of work
 May encompass one or many operations
 SQL uses BEGIN TRANSACTION, COMMIT, and
ROLLBACK to support transactions
 Transactions are atomic, durable, isolated, and
serializable
 More detail on this in later chapters
 Database: Case Example
Ord_Aug Ord_Items Ord # Item # Qty

Ord # OrdDate Cust# 101 HW1 100

101 HW3 50
101 02-08-94 002
101 SW1 150
102 11-08-94 003
102 HW2 10
103 21-08-94 003
103 HW3 50
104 28-08-94 002 104 HW2 25
105 30-08-94 005 104 HW3 100

105 SW1 100

Customers
Cust# CustName Address Items
Item # Descr Price
101
HW1 Power Supply 4000
102 HW2 101-Keyboard 2000
HW3 Mouse 800
103
SW1 MS-DOS 6.0 5000
104 SW2 MS-Word 6.0 8000
 Term Meaning Eg. from the given Case Example
Relation A table Ord_Aug, Customers, Items etc.
A row from Customers relation is a Customer
Tuple A row or a record in a relation.
tuple.
A field or a column in a
Attribute Ord_Date, Item#, CustName etc.
relation.
Cardinality of a The number of tuples in a
Cardinality of Ord_Items relation is 8
relation relation.
Degree of a The number of attributes in a
Degree of Customers relation is 3.
relation relation.
Domain of an The set of all values that can Domain of Qty in Ord_Items is the set of all values
attribute be taken by the attribute. which can represent quantity of an ordered item.
Primary Key of Customers relation is Cust#.
An attribute or a combination of
Primary Key of a
attributes that uniquely defines
relation Ord# and Item# combination forms the primary
each tuple in a relation.
Key of Ord_Items
An attribute or a combination of Cust# in Ord_Aug relation is a foreign key creating
attributes in one relation R1 reference from Ord_Aug to Customers. This is
which indicates the relationship required to indicate the relationship between
of R1 with another relation R2. Orders in Ord_Aug and Customers.
Foreign Key
The foreign key attributes in R1 Ord# and Item# in Ord_Items are foreign keys
must contain values matching creating references from Ord_Items to Ord_Aug
with those of the values in R2 and Items respectively.
Logical Database Design

26
 E-R Design (Revision)
 Data modeling –
Technique for organizing and documenting a
system’s data. Sometimes called database
modeling.

 Entity relationship diagram (ERD) –

Data model utilizing several notations to depict
data in terms of the entities and relationships
described by that data.

27
Sample Entity Relationship Diagram

28
 Data Modeling Concepts: Entity
 Entity – a class of persons, places, objects, events, or
concepts about which we need to capture and store
data.
 Entity instance – a single occurrence of an entity.

entity Student ID Last Name First Name

2144 Arnold Betty
3122 Taylor John
3843 Simmons Lisa
9844 Macy Bill
instances 2837 Leath Heather
2293 Wrench Tim 29
 Data Modeling Concepts
 Attribute – a descriptive property or
characteristic of an entity. Synonyms include
element, property, and field.

 Data type – a property of an attribute that

identifies what type of data can be stored in that
attribute.

30
 Data Modeling Concepts: Data Type
 Data type – a property of an attribute that identifies what
type of data can be stored in that attribute.

Representative Logical Data Types for Attributes

Data Type Logical Business Meaning
NUMBER Any number, real or integer.
TEXT A string of characters, inclusive of numbers. When numbers are included in a TEXT
attribute, it means that we do not expect to perform arithmetic or comparisons with
those numbers.
MEMO Same as TEXT but of an indeterminate size. Some business systems require the
ability to attach potentially lengthy notes to a give database record.
DATE Any date in any format.
TIME Any time in any format.
YES/NO An attribute that can assume only one of these two values.
VALUE SET A finite set of values. In most cases, a coding scheme would be established (e.g.,
FR=Freshman, SO=Sophomore, JR=Junior, SR=Senior).
31
IMAGE Any picture or image.
 Data Modeling Concepts: Domains
 Domain – a property of an attribute that defines
what values an attribute can legitimately take on.
Representative Logical Domains for Logical Data Types
Data Type Domain Examples
NUMBER For integers, specify the range. {10-99}
For real numbers, specify the range and precision. {1.000-799.999}
TEXT Maximum size of attribute. Actual values usually infinite; Text(30)
however, users may specify certain narrative restrictions.
DATE Variation on the MMDDYYYY format. MMDDYYYY
MMYYYY
TIME For AM/PM times: HHMMT HHMMT
For military (24-hour times): HHMM HHMM
YES/NO {YES, NO} {YES, NO} {ON, OFF}
VALUE SET {value#1, value#2,…value#n} {M=Male
{table of codes and meanings} F=Female} 32
 Default Value
 Default value – the value that will be recorded if
a value is not specified by the user.

Permissible Default Values for Attributes

Default Value Interpretation Examples
A legal value from For an instance of the attribute, if the user does not specify 0
the domain a value, then use this value. 1.00
NONE or NULL For an instance of the attribute, if the user does not specify NONE
a value, then leave it blank. NULL
Required or NOT For an instance of the attribute, require that the user enter REQUIRED
NULL a legal value from the domain. (This is used when no value NOT NULL
in the domain is common enough to be a default but some
value must be entered.)
33
 Data Modeling Concepts: Identification
 Key – an attribute, or a group of attributes, that
assumes a unique value for each entity
instance. It is sometimes called an identifier.

 Like, Roll no of student can be a Key

 Foreign key – a primary key of an entity that is used
in another entity to identify instances of a relationship

34
 Data Modeling Concepts: Relationships

 Relationship – a natural business association that

exists between one or more entities.

35
 Data Modeling Concepts: Cardinality

 Cardinality – the minimum and maximum number of

occurrences of one entity that may be related to a
single occurrence of the other entity.
(Because all relationships are bidirectional, cardinality
must be defined in both directions for every
relationship.)

36
Cardinality Notations

37
 Data Modeling Concepts: Degree
 Relationships may exist between
more than two entities and are called

N-ary relationships.
 The example ERD depicts a ternary
relationship.

Associative
Entity

38
 How to make ER Diagram
1.) Use rectangles representing entity sets.
2.) Use ellipses representing attributes
3.) Use ellipses representing attributes.
4.) Use diamonds representing relationship sets.
5.) Use lines linking attributes to entity sets and
entity sets to relationship sets.

39
40
Logical database design
and the relational model

41
 Objectives of logical design...

 Translate the conceptual design into a logical

database design that can be implemented on a
chosen DBMS
 Input: conceptual model (ERD)
 Output: relational schema, normalized
relations
 Resulting database must meet user needs for:
 Data sharing
 Ease of access
 Flexibility

42
 Relational database components
Data structure
 Data organized into tables
Data manipulation
 Add, delete, modify, and retrieve using SQL
Data integrity
 Maintained using business rules

43
 Some rules...
Every table has a unique name.
Attributes in tables have unique names.
Every row is unique.
The order of the columns is irrelevant.
The order of the rows is irrelevant.

44
 The key...

 Relational modeling uses primary keys and

foreign keys to maintain relationships
 Primary keys are typically the unique
identifier noted on the conceptual model
 Foreign keys are the primary key of another
entity to which an entity has a relationship
 Composite keys are primary keys that are
made of more than one attribute
 Weak entities
 Associative entities

45
 Constraints

 Domain constraints
 Allowable values for an attribute as defined
in the domain
 Entity integrity constraints
 No primary key attribute may be null
 Operational constraints
 Business rules
 Referential integrity constraints

46
 Referential integrity constraint

 Maintains consistency among rows of two

entities
 matching of primary and foreign keys

47
 Transforming ER diagrams
into relations
 Mapping entities to relations

48
Looks like this using relational
schema notation

49
 Transforming E-R diagrams into
relations
Mapping weak entities
 Weak Entity is an entity that cannot be
uniquely identified by its attributes alone;
therefore, it must use a foreign key in
conjunction with its attributes to create a
primary key.

50
Example of mapping a weak entity

51
Looks like this using relational
schema notation

52
 Transforming E-R diagrams into
relations
 Mapping binary relationships
 One-to-many - primary key on the one side
becomes a foreign key on the many side
 Many-to-many - create a new relation with the
primary keys of the two entities as its primary key
 One-to-one - primary key on the mandatory side
becomes a foreign key on the optional side

53
Example of mapping a 1:M
relationship

54
Looks like this using relational
schema notation

55
Example of mapping an M:M
relationship

56
Looks like this using relational
schema notation

57
Mapping a binary 1:1 relationship

58
Looks like this using relational
schema notation

59
 Transforming E-R diagrams into
relations
Mapping associative entities
 Identifier not assigned
• Default primary key for the association
relation is the primary keys of the two
entities
 Identifier assigned
• It is natural and familiar to end-users
• Default identifier may not be unique

60
Mapping an associative entity
with an identifier

61
Looks like this using relational
schema notation

62
 For example...

Emp_Num
Emp_Num

EMPLOYEE
EMPLOYEE
Emp-Name Supervises
Emp-Name Supervises

Emp_Address
Emp_Address

63
 Would look like...

references

Emp_Num Emp_Name Emp_Address Boss_Num

64
Mapping a ternary relationship

65
Looks like this using relational
schema notation

66
 Transforming E-R diagrams into
relations
Mapping Supertype/subtype relationships
 Create a separate relation for the
supertype and each of the subtypes
 Assign common attributes to supertype
 Assign primary key and unique
attributes to each subtype
 Assign an attribute of the supertype to
act as subtype discriminator

67
Mapping Supertype/subtype
relationships

68
Would look like this...

69
Tutorial-1
ER Diagram
 Exercise #1
 Draw an ER diagram for the following application
from the manufacturing industry:
1. Each supplier has a unique name.
2. More than one supplier can be located in the same city.
3. Each part has a unique part number.
4. Each part has a colour.
5. A supplier can supply more than one part.
6. A part can be supplied by more than one supplier.
7. A supplier can supply a ¯xed quantity of each part.
Solution-1
 Exercise #2
 Construct an E-R diagram for a car-insurance
company whose customers own one or more cars
each. Each car has associated with it zero to any
number of recorded accidents.
Solution
 Exercise #3
 Construct an E-R diagram for a hospital with a set
of patients and a set of medical doctors. Associate
with each patient a log of the various tests and
examinations conducted.
Solution
 Exercise 4
 Create a E-R diagram of the Motor Vehicle Branch administers
driving tests and issues driver's licenses. Any person who wants a
driver's license must first take a learner's exam at any Motor Vehicle
Branch in the province. If he/she fails the exam, he can take the
exam again any time after a week of the failed exam date, at any
branch. If he passes the exam, he is issued a license (type =
learner's) with a unique license number. A learner's license may
contain a single restriction on it. The person may take his driver's
exam at any branch any time before the learner's license expiry
date (which is usually set at six months after the license issue date).
If he passes the exam, the branch issues him a driver's license. A
driver's license must also record if the driver has completed driver's
education, for insurance purposes.
 Solution
Steps to follow:
1.Find out the entities in the spec.
2. Find out the relationships among the entities.
3. Figure out attributes of the entities and (if any) of the
relationships.
4. Figure out constraints between entities and
relationships.
5. check to see if you don't miss anything in spec.
 Home Work
 Imagine that you are a consultant called into the o±ce of a new Nepalese startup
called Movies4All. This company admires the success of the Internet Movie
Database (IMDb) in collecting and publishing movie-related information via the
web and thinks that it can set up its own database to rival the IMDb. The
payback to Movies4All, they hope, will be advertising revenue once thousands of
people-per-day start to visit their site looking for movie information/trivia/etc.
Putting aside your scepticism of this kind of business model, you ask them
precisely what content and functionality they want in their on-line database. They
suggest that looking at the IMDb (http://www.imdb.com/) would be a good start. If
you press them further, they'll tell you that Movies4All should maintain the
following kinds of information:
1. movies: title, cast, crew, story-line, genre, studio, year made/released
2. actors: biographical, photos, films they appeared in, ...
3. crew: occupation (director, cameraman,...), biographical, films, ...
4. studios: contact information, historical information (e.g. heads), ...
5. awards: given to movies or people who work in/on them
6. movie jobs: information about what people like "gaffers" actually do
7. session times: for movies being screened in cinemas all over the world
 Contd…
 All information in the system should be accessible (readable) to anyone on the
Internet. However, Movies4All staff are the only ones who are allowed to update
the database. They also want to provide for registered users of the system, who
can rate movies and post movie reviews. Registered users are also allowed to
provide new information to the Movies4All staff, who will check its validity and
then incorporate it into the site. Some ideas on the functionality that the system
should provide:
1. Movies4All staff and registered users have a username and password for
login authentication
2. Movies4All staff can add, update and (infrequently) delete any information in
the database
3. registered users can rate movies, post reviews, and post suggested changes
to Movies4All staff
4. anyone can search for movies, actors, crew, ... via keyword
5. an advanced search facility allows search by individual aspects of
movies/actors/crew/studios
6. every reference to a person/movie/studio is a hyperlink to a page giving the
details.
 Well-structured relations
 Well-structured relations contain minimal
redundancy and allow insertion, modification, and
deletion without errors or inconsistencies
 Redundancies in a table (such as more than one
entry for each EMPLOYEE) may result in errors
and inconsistencies (anomalies) when the table is
updated
 Anomalies are errors or inconsistencies resulting
from redundancy
 Insertion anomaly
 Deletion anomaly
 Modification anomaly
82
 Data normalization
 Normalization is a formal process for deciding
which attributes should be grouped together in
a relation
 Objective: to validate and improve a logical
design so that it satisfies certain constraints
that avoid unnecessary duplication of data
 Definition: the process of decomposing
relations with anomalies to produce smaller,
well-structured relations

83
 Normalization
 Data normalization also may improve data consistency
and simplify future extension of the logical data model.
 The formal classifications used for describing a
relational database's level of normalization are called
normal forms
 Normal Forms is abbreviated as NF
 What Happens without
Normalization
 A non-normalized database can suffer from data
anomalies:
 A non-normalized database may store data representing a
particular referent in multiple locations. An update to such
data in some but not all of those locations results in an
update anomaly, yielding inconsistent data. A normalized
database prevents such an anomaly by storing such data
(i.e. data other than primary keys) in only one location.
 What Happens without
Normalization
 A non-normalized database may have inappropriate
dependencies, i.e. relationships between data with no
functional dependencies. Adding data to such a database
may require first adding the unrelated dependency. A
normalized database prevents such insertion anomalies
by ensuring that database relations mirror functional
dependencies.

 Similarly, such dependencies in non-normalized databases

can hinder deletion. That is, deleting data from such
databases may require deleting data from the inappropriate
dependency. A normalized database prevents such deletion
anomalies by ensuring that all records are uniquely
identifiable and contain no extraneous information.
 Normalization: 1NF, 2NF, 3NF
 First normal form (1NF) – entity whose attributes
have no more than one value for a single instance of
that entity.
 Second normal form (2NF) – entity whose
nonprimary-key attributes are dependent on the full
primary key.
 Third normal form (3NF) – entity whose nonprimary-
key attributes are not dependent on any other non-
primary key attributes.

87
Steps in normalization

88
 Functional dependencies and keys
 Functional dependency: the value of one
attribute (the determinant) determines the value
of another attribute
 A -> B, for every valid instance of A, that value
of A uniquely determines the value of B
 Candidate key: an attribute or combination of
attributes that uniquely identifies an instance
 Uniqueness: each non-key field is functionally
dependent on every candidate key
 Non-redundancy

89
 First normal form
No multi-valued attributes.
Every attribute value is atomic.

90
 Table 1

Title Author1 Author ISBN Subject Pages Publisher

2
Database Abraham Henry 0072958863 MySQL, 1168 McGraw-Hill
System Silberschatz F. Korth Computers
Concepts

Operating Abraham Henry 0471694665 Computers 944 McGraw-Hill

System Silberschatz F. Korth
Concepts
 Table 1 problems

 This table is not very efficient with storage.

 This design does not protect data integrity.

 Third, this table does not scale well .

 First Normal Form
 In our Table 1, we have two violations of First
Normal Form:
 First, we have more than one author field,
 Second, our subject field contains more than
one piece of information. With more than one
value in a single field, it would be very difficult to
search for all books on a given subject.
 First Normal Table

 Table 2

Title Author ISBN Subject Pages Publisher

Database System Abraham 0072958863 MySQL 1168 McGraw-Hill

Concepts Silberschatz
Database System Henry F. Korth 0072958863 Computers 1168 McGraw-Hill
Concepts

Operating System Henry F. Korth 0471694665 Computers 944 McGraw-Hill

Concepts

Operating System Abraham 0471694665 Computers 944 McGraw-Hill

Concepts Silberschatz
 We now have two rows for a single book. Additionally, we
would be violating the Second Normal Form.

 A better solution to our problem would be to separate the

data into separate tables- an Author table and a Subject
table to store our information, removing that information
from the Book table:
 Second normal form
 1NF and every non-key attribute is fully
functionally dependent on the primary key.
 Every non-key attribute must be defined by the
entire key, not by only part of the key.
 No partial functional dependencies.

96
 Subject Table
Subject_ID Subject
Author Table
1 MySQL
Author_ID Last Name First Name
2 Computers
1 Silberschatz Abraham

2 Korth Henry
Book Table

ISBN Title Pages Publisher

0072958863 Database System 1168 McGraw-Hill

Concepts

0471694665 Operating System 944 McGraw-Hill

Concepts
Each table has a primary key, used for
joining tables together when querying the
data. A primary key value must be unique
with in the table (no two books can have
the same ISBN number), and a primary
key is also an index, which speeds up data
retrieval based on the primary key.
Now to define relationships between the
tables
 Relationships

Book_Author Table
Book_Subject Table
ISBN Author_ID

0072958863 1 ISBN Subject_ID

0072958863 2 0072958863 1

0471694665 1 0072958863 2

0471694665 2 0471694665 2
 2NF Table
Publisher Table

Publisher_ID Publisher Name

1 McGraw-Hill

Book Table
ISBN Title Pages Publisher_ID

0072958863 Database System 1168 1

Concepts

0471694665 Operating System 944 1

Concepts
 Second Normal Form
 As the First Normal Form deals with redundancy
of data across a horizontal row, Second Normal
Form (or 2NF) deals with redundancy of data in
vertical columns.
 As stated earlier, the normal forms are
progressive, so to achieve Second Normal
Form, the tables must already be in First Normal
Form.
 The Book Table will be used for the 2NF
example
 2NF
 Here we have a one-to-many relationship
between the book table and the publisher. A
book has only one publisher, and a publisher will
publish many books. When we have a one-to-
many relationship, we place a foreign key in the
Book Table, pointing to the primary key of the
Publisher Table.
 The other requirement for Second Normal Form
is that you cannot have any data in a table with
a composite key that does not relate to all
portions of the composite key.
 Third Normal Form
Third normal form (3NF) requires that
there are no functional dependencies of
non-key attributes on something other
than a candidate key.
A table is in 3NF if all of the non-primary
key attributes are mutually independent
There should not be transitive
dependencies
 Boyce-Codd Normal Form

BCNF requires that the table is 3NF and

only determinants are the candidate
keys
 Third normal form
2NF and no transitive dependencies
(functional dependency between non-key
attributes.)

105
Relation with Transitive Dependency

106
Transitive dependency in SALES
relation

107
Removing a transitive
dependency

108
Relations in 3NF

109