Ch01 Relational Model &

Codd Rules
 Relational Model
• A relational database is a collection of relation.
• A relation resembles a “Table” or a “Flatfile” of records.
• Each row in such a table represents a collection of such related data
values
RollNo Name Date_of_Registration

01 ABC 10-02-2013

03 XYZ 10-02-2014

02 SSSS 10-02-2015

Each row is called as tuple and each column is called as attribute of a relation.
Relational Model
• Attribute : Attribute is the name of a column in a table. The attributes
are rollno,name etc. The no. of attributes of a relation is called as
arity (or degree or order of relation).
• No two attributes have a same name.
• Domain : Domain (D) is the set of values of the same data type.
Domain of the attribute is defined as set of allowable values for the
attribute.
• Domain is a set having “homogeneous” members and it is
conceptually similar to the data type concept in programming
language.
Relational Model
• According to the set of values, domain is classified into four
categories
• 1. Simple 2. Application Independent
• 3. Application dependent 4. Composite.
• A domain (D) is said to be simple if all its elements are non-decomposable.
• Application Independent or Atomic domain is the general set of integers, real
numbers or character strings.
• Application dependent domain is having the values permitted in the
database.
• Composite can be specified as a set consisting of non-atomic values.
• Relation: Relations is a collection of homogeneous tuples.
• A relation with n attributes is a subset of Cartesian product of domains of
those attributes.
• e.g. Domain of RollNo(01,02,03)
• Domain of Name(ABC,XYZ,SS)
• Relation Student is subset of Cartesian product of domains of all these
attributes.
• Properties of Relation:
• The relation has a name that is distinct from all other relation names
• Each cell of the relation contain exactly one atomic(not divided) single value.
• Each attribute has a distinct name
• The values of an attribute are no duplicate tuples.
• The order of attributes has no significance
• The order of tuples has no significance
Intension and Extension of Relation
• The structure of relation together with a specification of the domains
and any other restrictions on possible values, is called its intension,
which is usually fixed unless the meaning of the relation is changed to
include additional attributes.
• The tuples are called the extension of the relation which changes
over time.
• Degree of relation: This is defined as no. of attributes it contains.
• Cardinality: The cardinality of relation is the number of tuples it
contains which is also extensions of the relation , which is determine
at a particular instance.
• Relation Schema: It defines the set of attributes of that relation. It is
Denoted by R(A1,A2…An) is made up of relation name R and a list of
attributes A1,A2,…An. Each A1 is the name played in some domain D
in schema R. The domain A1 is denoted by dom(A1)
• Relational Database: A collection of normalized relations with distinct
relation names is called as relational database.
• Integrity Rules: Integrity rules are the constraints or restrictions that apply to
all instances of the database. There are 3 integrity rules

• Entity Integrity Rule : In the base relation, no attribute of a primary key can be NULL
• Referential Integrity Rule : If a foreign key exists in a relation, either the foreign key
value must match a candidate key value of some tuple in its home relation or the
foreign key value must be wholly NULL.

• Semantic Integrity Constraints: Constraints on the values of attributes of attribute. e.g.

The salary of employee will not more than his/her manager.
Relational Model
• The relational model (RM) for database management is an approach to
managing data using a structure and language consistent with first-order
predicate logic (using Relational Algebra) first described in 1969 by English
computer scientist Edgar F. Codd, where all data is represented in terms
of tuples, grouped into relations.
• A database organized in terms of the relational model is a relational
database.
Example of Relation
Basic Structure
• Formally, given sets D1, D2, …. Dn a relation r is a subset of
D1 x D2 x … x Dn
Thus, a relation is a set of n-tuples (a1, a2, …, an) where each ai ∈ Di
• Example: If
• customer_name = {Jones, Smith, Curry, Lindsay, …} /* Set of all
customer names */
• customer_street = {Main, North, Park, …} /* set of all street names*/
• customer_city = {Harrison, Rye, Pittsfield, …} /* set of all city names */
Then r = { (Jones, Main, Harrison),
(Smith, North, Rye),
(Curry, North, Rye),
(Lindsay, Park, Pittsfield) }
is a relation over
customer_name x customer_street x customer_city
Attribute Types
• Each attribute of a relation has a name
• The set of allowed values for each attribute is called the domain of
the attribute
• Attribute values are (normally) required to be atomic; that is,
indivisible
• E.g. the value of an attribute can be an account number,
but cannot be a set of account numbers
• Domain is said to be atomic if all its members are atomic
• The special value null is a member of every domain
• The null value causes complications in the definition of many
operations
• We shall ignore the effect of null values in our main presentation and consider
their effect later
Relation Instance
• The current values (relation instance) of a relation are specified by a
table
• An element t of r is a tuple, represented by a row in a table

attributes
(or columns)
customer_name customer_street customer_city

Jones Main Harrison

Smith North Rye tuples
Curry North Rye (or rows)
Lindsay Park Pittsfield

customer
Relations are Unordered
● Order of tuples is irrelevant (tuples may be stored in an arbitrary order)
● Example: account relation with unordered tuples
The customer Relation
The depositor Relation
 Keys
• Let K ⊆ R
• K is a superkey of R if values for K are sufficient to identify a unique tuple
of each possible relation r(R)
• by “possible r ” we mean a relation r that could exist in the enterprise we are
modeling.
• Example: {customer_name, customer_street} and
{customer_name}
are both superkeys of Customer, if no two customers can possibly have the same
name
• In real life, an attribute such as customer_id would be used instead of customer_name to
uniquely identify customers, but we omit it to keep our examples small, and instead assume
customer names are unique.
 Keys
• K is a candidate key if K is minimal
Example: {customer_name} is a candidate key for Customer, since it is a
superkey and no subset of it is a superkey.
• Primary key: a candidate key chosen as the principal means of
identifying tuples within a relation
• Should choose an attribute whose value never, or very rarely, changes.
• E.g. email address is unique, but may change
 Foreign Keys
• A relation schema may have an attribute that corresponds to the primary
key of another relation. The attribute is called a foreign key.
• E.g. customer_name and account_number attributes of depositor are foreign keys to
customer and account respectively.
• Only values occurring in the primary key attribute of the referenced relation may
occur in the foreign key attribute of the referencing relation.
• Schema diagram
Codd’s Rules
• Dr. Edgar Frank Codd was a computer scientist working with IBM. He
invented Relational Model for Database Management.
• Codd define 13 rules (0 to 12) and said if DBMS system meets these
rules, it can be called as RDBMS.
• These rules can be applied on a database system that is capable of
managing, storing, and retrieving data from database using its relational
capabilities.
Codd’s Rules
• Rule 0: The Foundation rule: For any system that is advertised as, or claimed
to be, a relational database management system, that system must be able
to manage databases entirely through its relational capabilities.
Codd’s Rules
• Rule 1: The information rule: All information in a relational database is
represented explicitly at the logical level and in exactly one way — by
values in tables.
• Database is logically interpreted in the form of set or related table
• Order of columns in the table doesn’t matter
• Every column in the table must be atomic.
• All the non-key values of the table must be derivable only by Primary key –i.e.
functional dependency.
• Each table showing functional dependency is called normal table- relation hence
Name is given Relational Database Management system.

Roll_No Name Address Phone

1 Ram Pune 56788900
2 Ramesh Mumbai 0220345789
Codd’s Rules
• Rule 2: The guaranteed access rule : Each and every data (atomic value) in
a relational data base is guaranteed to be logically accessible by resorting to
a combination of table name, primary key value and column name.
• Every single data element(value) is accessible logically with combination of
table-name, primary-key, and attribute-name(column-name).
• Data access should not need to use “Pointer “ to access the data.

Roll_No Name Address Phone

1 Ram Pune 56788900
2 Ramesh Mumbai 0220345789

• To access this we must use the combination of [table-name,primary-key(row),

columns-name[roll_no]]
Codd’s Rules
• Rule 3: Systematic treatment of null values : Null values (distinct from the
empty character string or a string of blank characters and distinct from zero
or any other number) are supported in fully relational DBMS for
representing missing information and inapplicable information in a
systematic way, independent of data type.
• NULL can be interpreted as
• Data is missing
• Data is not known, or data is not applicable
• No value
• Should be handled consistently-Not Zero or blank
• Primary- key must be set to “NOT NULL”
• Null values can be handled with NVL type functions
Codd’s Rules
• Rule 4: Dynamic online catalog based on the relational model: The data
base description is represented at the logical level in the same way as
ordinary data, so that authorized users can apply the same relational
language to its interrogation as they apply to the regular data.
• The structure of description of entire database must be stored in an online catalog,
known as data dictionary, which can accessed by authorized users.
• Catalog to be governed by same rules as rest of database.
• The same query language to be used on catalog as on the application database.
• Metadata must be correct and up-to-date
• Metadata is used by the system for execution of SQL statement in Query Parsing,
Query Planning, Fetch/Execute
Codd’s Rules
• Rule 5: The comprehensive data sublanguage rule : A relational system
may support several languages and various modes of terminal use (for
example, the fill-in-the-blanks mode). However, there must be at least one
language whose statements are expressible, per some well-defined syntax,
as character strings and that is comprehensive in supporting all of the
following items:
• Data definition.
• View definition.
• Data manipulation (interactive and by program).
• Integrity constraints.
• Authorization.
• Transaction boundaries (begin, commit and rollback).
Codd’s Rules
• Rule 6: The view updating rule: All views that are theoretically updatable
are also updatable by the system.
• View is temporary table derived from base table/tables. If we are doing any
modification in the view , the changes must be reflected in the base table also
Codd’s Rules
• Rule 7: High-level insert, update, and delete: The capability of handling a
base relation or a derived relation as a single operand applies not only to
the retrieval of data but also to the insertion, update and deletion of data.
• Must support “Set operations on rows and not restrict operations on one single row
at a time.
• Must support relational algebra
• Relational Algebra includes : Selection, Projection, Cartesian Product,Join, Union etc
Codd’s Rules
• Rule 8: Physical Data Independence : Application programs and terminal
activities remain logically unimpaired whenever any changes are made in
either storage representations or access methods.
• Physical storage of data should be independent of applications.
• Changes in physical storage must not impact access methods.
• Physical data independence deals with hiding the details of the storage structure
from user application.
• A change in internal schema, such as using different file organization or storage
structure, storage devices, should be possible without changing the conceptual /
external schemas.
Codd’s Rules
▪ Rule 9: Logical Data Independence : Application programs and terminal
activities remain logically unimpaired when information-preserving changes
of any kind that theoretically permit unimpairment are made to the base
tables.
▪ Changes to the logical level must not require a change to an application
based on the structure.
• Function of application and ad hoc queries should be independent of
• Changes in relationship among tables.
• Changes in the structure of tables
• Changes in rows and columns
• No database recreation be required to effect the above changes.
• Practical implementation of this rule is extremely difficult.
Codd’s Rules
▪ Rule 10: Data Integrity Independence : Integrity constraints specific to a
particular relational data base must be definable in the relational data
sublanguage and storable in the catalog, not in the application programs.
▪ Data integrity is the function DBMS
▪ Database must apply integrity rules by query language and they must be
independent of front end application
▪ Database constraints must be definable as objects should be stored as
metadata.
▪ Data integrity takes in 3 forms:
▪ Entity integrity- Primary Key, Unique key
▪ Referential Integrity –Foreign key
▪ Domain Integrity- Check, Not Null, Default Value
Codd’s Rules
▪ Rule 11: Distribution Independence : A relational DBMS has distribution
independence.
▪ This rule is foundation of distributed databases.
▪ Distributed database divides the database and splinters (divide in to parts)
runs on multiple network servers.
▪ Users access the data transparently i.e. without actually knowing about
from where the data is provided.
▪ Distributed database are expected to provide seamless transaction using
2PC/3PC
▪ Existing application should continue to operate without requiring any
change scheme of distribution changes.
Codd’s Rules
▪ Rule 12: The nonsubversion rule : If a relational system has a low-level
(single-record-at-a-time) language, that low level cannot be used to subvert
or bypass the integrity rules and constraints expressed in the higher level
relational language (multiple-records-at-a-time).
▪ The system should not allow to circumvent data integrity as well as security even at
lower level of access .
▪ There cannot be different path allowed to reach to the data and its manipulation
which may bypass the validation rule for the data and jeopardize(put in risk).