Chapter - 2: Entity Relationship

Model
2.1 Introduction
As we already discussed in previous chapter, data models are broadly classified into 2 categories:
object based data models and relation based data models. The object based model can be defined
as a tool for describing data, data relationships and data constraints. The record based model
describes the database structures and access techniques of a DBMS.

Out of the various object data models, the most widely use one is the Entity-Relationship (E-R)
Model. It has gained acceptance as an ideal data model for database design. In this chapter, we
will discuss the concepts of E-R model. But, initially we discuss on structure of RDMS.

2.2 Concept of RDMS

Now a day’s relational data model is being used as the primary data model for commercial data
processing applications. It was introduced by E.F.Codd in 1970 and it changed permanently the
way people viewed database. At that time hierarchical and network data models were popular for
database system, which are based on physical pointers, or disk addresses to relate records in
different files. Moreover, they were highly vulnerable to changes in the physical environment.
Extensive data conversion and movement was required if new disk drive was added or a field
was added in the database design.

The relational model is based on logical relationships between data and allows user to be totally
uncovered with or even unaware of the physical structure of the data. In addition, Codd proposed
two logically based data manipulation languages, Relational Algebra and Relational Calculus,
which we will discuss in later chapter.

A relational database represents all data in the database as simple two-dimensional tables called
relations that are the logical equivalent of files. Each row (record) of a relational table, called
tuple, represents a data Entity with columns of the table representing attributes (fields) and total
number of attributes of a relation is called degree or arity of a relation. The allowable values for
these attributes are called the domain, indicating that values can be placed in each of the
columns of the relational table. Each row in a relational table must have a unique primary key
and typically, it has some secondary keys, these secondary keys correspond with primary keys in
the other tables, i.e. relate all the tables.

2.2.1 Properties of Relational Table

1. Values are atomic.

This property implies that columns in a relational table are not repeating group or arrays.
Hence, attributes those having multiple values are not allowed.
 2. Column values are of the same kind.
In relational terms this means that all values in a column come from the same
domain. For example, Ename column contains only the name of the employee. It
never contains other information such as address and DOB, etc.
3. Each row is unique.
This property ensures that no two rows in a relational table are identical.
4. Each column has a unique name.
This property states that the column name of each column should be unique.
5. The sequence of columns is insignificant.
This property states that the ordering of the column in the relational table has no meaning
columns can be retrieved in any order and in various sequences.
6. The sequence of columns is insignificant.
This property states that the column name of each column should be unique.

2.2.2 Codd’s Rule for RDBMS

E.F.Codd is an IBM researcher who first developed the relational data model in 1970. In 1985,
Codd published a list of 12 rules that define an ideal relational database and has provided
guidelines for the design of all relational database systems.

Rule 1: The Information Rule

This rule simply requires that all data should be presented in table form. This is the basis of
relational model.
Rule 2: Guaranteed Access Rule
All data should be accessible without ambiguity. This can be accomplished through a
combination of the table name, primary key and column name.
Rule 3: Systematic Treatment of Null Values
The RDBMS must support the null values to represent missing information. They must be
distinct from zero or spaces. They must be independent of data values.
Rule 4: Dynamic Online Catalog based on the Relational Model
System catalog is a collection of tables that the (system) DBMS maintain for its own use. These
tables hold the description of the structure of the database. These tables are created, owned and
maintained by the DBMS.
Rule 5: Comprehensive Data Sublanguage Rule
The database must support at least one clearly defined language that includes functionality for
data definitions, data manipulation, data integrity and database transaction control. All
commercial relational databases use forms of SQL as their supported comprehensive language.
Rule 6: View Updating Rule
Data can be presented in different logical combinations called views. Each view should support
the same full range of data manipulation that has direct access to a table available.

Rule 7: High Level Insert, Update and Delete

Data can be retrieved from a relational database in sets constructed of data from multiple rows
and/or multiple tables. This rule states that insert, update, and delete operations should be
supported for any retrievable set rather than just for a single row in a single table.
Rule 8: Physical Data Independence
The user is isolated from the physical method of storing and retrieving information from the
database. Changes can be made to the underlying architecture without affecting how the user
accesses it.
Rule 9: Logical Data Independence
How data is viewed should not be changed when the logical structure (table’s structure) of the
database changes. This rule is particularly difficult to satisfy.
Rule 10: Integrity Independence
The database language (like SQL) should support constraints on user input that maintain
database integrity. No component of a primary key can have a null value. If a foreign key is
defined in one table, any value in it must exist as primary key to another table.
Rule 11: Distribution Independence
Database must allow manipulation of distribution data located in other computer system.
Rule 12: Non-subversion Rule
There should be no way to modify the database structure other than through the multiple row
database language (SQL) most databases today support administrative tools that allow some
direct manipulation of the data structure.

2.2.3 Difference between DBMS and RDBMS

DBMS RDBMS
1. In DBMS, relationships between two tables 1. In RDBMS, relationships between two
are maintained programmatically. tables or files can be specified at the time
of table creation.
2. DBMS does not support client/server 2. Most of the RDBMS supports client/server
architecture. architecture.
3. DBMS does not support distributed 3. Most of the RDBMS supports distributed
databases. databases.
4. In DBMS, there is no tight security of 4. In RDBMS, there are multiple level of
data. security:
(a) Logging in at O/S level
(b) Command level
(c) Object level.
5. Each table is given an extension in 5. Many tables are grouped in one database in
DBMS. RDBMS.
6. DBMS satisfy less than 7 to 8 rules of 6. RDBMS usually satisfy more than 7 to 8
E.F.Codd. rules of E.F.Codd.

2.3 Structure of RDBMS

The relational model structures the logical view of data around two mathematical constructs:
domains and data types, and relations. The name relational comes from “relation” as known and
widely used in mathematics, although in database theory, the definition of relation is slightly
extended. A domain is simply a set of values, together with its associated operators. A relational
database consists of a collection of tables, each having unique name. A row in a table represents
a relationship among a set of values. Thus, a table represents a collection of relationships.

2.3.1 Basic Structure