UNIT-2

Relational Model

2.1 Components of ER model

An ER Diagram consists of the following components:

1. Entity

2. Attributes

3. Relationships
1. Entity

An entity may be an object, place, person, or an event which stores data in the database. In an
entity-relationship diagram, an entity is represented by a rectangle. Student, course, manager,
employee, patient, etc. are examples of an entity.

Entity type: An entity type is a collection or a set of entities having some common attributes. In a
database, each entity type is described by a name and list of attributes.

Entity set: It is a set (or collection) of entities of the same type which share the similar properties,
or attributes.
For example, the group of people who are lecturers in a university can be defined as an entity
set lecturer. Similarly, the entity set of students might represent the group of all students in the
university.

An entity can be characterized into two types:

Strong entity: This type of entity has a primary key attribute which uniquely identifies each
record in a table. In the ER diagram, a strong entity is usually represented by a single rectangle.

Weak entity: An entity does not have a primary key attribute and depends on another strong
entity via foreign key attribute. In the ER diagram, a weak entity is usually represented by a
double rectangle.
2. Attributes: An attribute in an Entity-Relationship Model describes the properties or
characteristics of an entity. It is represented by an oval or ellipse shape in the ER diagram. Every
oval shape represents one attribute and is directly connected to its entity which is in the rectangle
in shape.

For example, employee_id, employe_name, Gender, employee_age, Salary, and Mobile no. are
the attributes which define entity type Employee.

In the ER model, an attribute can be characterized into the following types:

Simple attribute: An attribute which contains an atomic value and cannot be divided further is
called a simple attribute. For example, Gender and Salary of a person. It is also represented by an
oval.
Key attribute: An attribute which can uniquely identify an entity in an entity set is called a key
attribute. It represents a primary key in the ER diagram. In an Entity-Relationship diagram, the
key attribute is denoted by an oval with an underlying line. For example, employee_id will be
unique for each employee.
Composite attribute:An attribute which is a combination of two or more simple attributes is
called a composite attribute. In an Entity-Relationship diagram, it is represented by an ellipse,
and that ellipse comprises of other ellipses.For example, the Name attribute of an employee
entity type consists of First name, Second name, and Last name.
Derived attribute: An attribute which can be derived from other attributes is called a derived
attribute. In an entity-relationship diagram, these attributes are represented by a dashed
oval shape. For example, employee_age is a derived attribute as it changes over time and can be
derived from another attribute DOB (Date of birth).

Multi-valued attribute: An attribute which contains more than one value for a given entity. For
example, an employee can have more than one mobile number and email address.
3. Relationship

A relationship in Entity-Relationship Model is used to describe the relation between two or more
entities. It is represented by a diamond shape in the ER diagram. For example, student study
in college, employee works in a department. Here, ‘study in’ and ‘works in’ are the relationships.

Degree of Relationship

A relationship where a number of different entity set participate is called as degree of a

relationship.

Degree of relationship can be categorized into the following types:

1. Unary Relationship

2. Binary Relationship

3. Ternary Relationship

4. n-ary Relationship

Unary Relationship: A relationship where a single entity set participates is called as a unary
relationship. For example, In a company, an employee manages or supervises another employee.

Binary Relationship: When two entity set participates in a relationship is called a binary
relationship.

It is further categorized into four types:

One-to-One Relationship: When one entity from an entity set A is associated with another entity
of entity set B and vice versa. Such type of relationship is called one to one relationship.

One-to-Many Relationship:When one entity from an entity set A is associated or linked with
multiple entities of entity set B, then it is called a one-to-many relationship.
Many-to-One Relationship: When more than one entities from an entity set A is associated with
one entity of entity set B, then it is called a many-to-one relationship.

Many-to-Many Relationship: When more than one entity from an entity set A is associated with
many entity of an entity set B. Such types of relationship are called a many-to-many relationship.

c) Ternary Relationship: When three entity set participates in a relationship, is called a ternary
relationship.
d) n-ary Relationship: When more than three entity set involves in a relationship is called an n-
ary relationship.

2.2 E-R Diagram Components/ Conventions

ER-Diagram is a pictorial representation of data which describes how the data is communicated
and related to one another. Any object, like entities, attributes of an entity, sets of relationship
and other attributes of relationship are characterized with the help of the ER diagram.

The Entity Relationship (ER) diagram components are as follows –

2.3 Conversion of ER Diagram into Table

Entity relationship diagram is the graphical representation of entities and relationships among
those entities in the database.

Example
Rule 1: Strong Entity with Simple Attributes
The Strong entity with simple attributes is represented by a single table in the relational model.

In this rule, simple attributes of an entity are taken as fields of the table. And, the key attribute is
specified as the primary key of the corresponding table.

Example:

In this example, a strong entity Employee in the ER diagram is represented by

the Employee table in the relational model. And, the five attributes of Employee entity selected
as the fields of the employee table. And, the Emp_ID acts as the primary key of the table.
Rule 2: Strong Entity with Composite Attributes
The Strong entity with Composite attributes is represented by a single table in the relational
model.

In this rule, the simple attributes of composite attributes are taken as columns of the relational
table, but the composite attributes are not taken as a column in the table. And, the key attribute is
specified as the primary key of the corresponding table.

Example:

In this example, a strong entity Employee in the ER diagram contains one composite attribute.

After conversion, a strong entity Employee is represented by the Employee table in the relational
model. And, the attributes of the Name ( composite attribute ) selected as the fields of the
employee table. And, the Emp_ID acts as the primary key of the table.
Rule 3: Strong Entity with Multi-valued Attributes
The Strong entity with multi-valued attributes is represented by two tables in the relational
model.

In this rule, one relational table contains the primary key and the multi-valued attributes of the
strong entity. And, the other relational table contains the primary key and other simple attributes.

Example:

In this example, the strong entity Employee contains three simple attributes and two multi-valued
attributes in the ER diagram.

After conversion, Employee entity is represented by the two tables in the relational model.

The attributes of the first table are Emp_ID and Email_ID. The attributes of another table
are Emp_ID, Name, and Age.
Rule 4: Convert Relationship Set into Relationship Table
The Relationship set in ER diagram is represented by only one table in the relational model.

In this rule, the key attributes of the participating entity set are taken as the attributes of the
relationship table in the relational model. And, if there is any attribute of relationship set in the
ER diagram, then that attribute is added as attributes of the relationship table.

Example:

In this example, two strong entities Employee and Department are related to each other with a
relationship Works-In.

After Conversion, the key attributes Emp_ID and Dept_ID of Employee and Department entity
will be the attributes of Works-In table in the relational model. And, the attribute (Works_From)
of Works-In relationship set is taken as the another field of relationship table.
2.4 Codd’s Rules

Every database has tables, and constraints cannot be referred to as a rational database system.
And if any database has only relational data model, it cannot be a Relational Database System
(RDBMS). So, some rules define a database to be the correct RDBMS. These rules were
developed by Dr. Edgar F. Codd (E.F. Codd) in 1985, who has vast research knowledge on the
Relational Model of database Systems. Codd presents his 13 rules for a database to test the
concept of DBMS against his relational model, and if a database follows the rule, it is called
a true relational database (RDBMS). These 13 rules are popular in RDBMS, known as Codd's 12
rules.
Rule 0: The Foundation Rule

The database must be in relational form. So that the system can handle the database through its
relational capabilities.

Rule 1: Information Rule

A database contains various information, and this information must be stored in each cell of a
table in the form of rows and columns.

Rule 2: Guaranteed Access Rule

Every single or precise data (atomic value) may be accessed logically from a relational database
using the combination of primary key value, table name, and column name.

Rule 3: Systematic Treatment of Null Values

This rule defines the systematic treatment of Null values in database records. The null value has
various meanings in the database, like missing the data, no value in a cell, inappropriate
information, unknown data and the primary key should not be null.

Rule 4: Active/Dynamic Online Catalog based on the relational model

It represents the entire logical structure of the descriptive database that must be stored online and
is known as a database dictionary. It authorizes users to access the database and implement a
similar query language to access the database.

Rule 5: Comprehensive Data SubLanguage Rule

The relational database supports various languages, and if we want to access the database, the
language must be the explicit, linear or well-defined syntax, character strings and supports the
comprehensive: data definition, view definition, data manipulation, integrity constraints, and
limit transaction management operations. If the database allows access to the data without any
language, it is considered a violation of the database.
Rule 6: View Updating Rule

All views table can be theoretically updated and must be practically updated by the database
systems.

Rule 7: Relational Level Operation (High-Level Insert, Update and delete) Rule

A database system should follow high-level relational operations such as insert, update, and
delete in each level or a single row. It also supports union, intersection and minus operation in
the database system.

Rule 8: Physical Data Independence Rule

All stored data in a database or an application must be physically independent to access the
database. Each data should not depend on other data or an application. If data is updated or the
physical structure of the database is changed, it will not show any effect on external applications
that are accessing the data from the database.

Rule 9: Logical Data Independence Rule

It is similar to physical data independence. It means, if any changes occurred to the logical level
(table structures), it should not affect the user's view (application). For example, suppose a table
either split into two tables, or two table joins to create a single table, these changes should not be
impacted on the user view application.

Rule 10: Integrity Independence Rule

A database must maintain integrity independence when inserting data into table's cells using the
SQL query language. All entered values should not be changed or rely on any external factor or
application to maintain integrity. It is also helpful in making the database-independent for each
front-end application.

Rule 11: Distribution Independence Rule

The distribution independence rule represents a database that must work properly, even if it is
stored in different locations and used by different end-users. Suppose a user accesses the
database through an application; in that case, they should not be aware that another user uses
particular data, and the data they always get is only located on one site. The end users can access
the database, and these access data should be independent for every user to perform the SQL
queries.

Rule 12: Non Subversion Rule

The non-submersion rule defines RDBMS as a SQL language to store and manipulate the data in
the database. If a system has a low-level or separate language other than SQL to access the
database system, it should not subvert or bypass integrity to transform data.

2.5 Relational Integrity: Nulls, Entity, Referential integrities, Enterprise constraints,

Views, Schema diagram

Integrity Constraints
o Integrity constraints are a set of rules. It is used to maintain the quality of information.
o Integrity constraints ensure that the data insertion, updating, and other processes have to
be performed in such a way that data integrity is not affected.
o Thus, integrity constraint is used to guard against accidental damage to the database.
Types of Integrity Constraint

1. Domain constraints
o Domain constraints can be defined as the definition of a valid set of values for an
attribute.
o The data type of domain includes string, character, integer, time, date, currency, etc. The
value of the attribute must be available in the corresponding domain.

Example:
2. Entity integrity constraints
o The entity integrity constraint states that primary key value can't be null.
o This is because the primary key value is used to identify individual rows in relation and if
the primary key has a null value, then we can't identify those rows.
o A table can contain a null value other than the primary key field.

Example:
3. Referential Integrity Constraints
o A referential integrity constraint is specified between two tables.
o Referential integrity refers to the relationship between tables.
o In the Referential integrity constraints, if a foreign key in Table 1 refers to the Primary
Key of Table 2, then every value of the Foreign Key in Table 1 must be null or be
available in Table 2.

Example:

4. Key constraints
o Keys are the entity set that is used to identify an entity within its entity set uniquely.
o An entity set can have multiple keys, but out of which one key will be the primary key. A
primary key can contain a unique and null value in the relational table.

Example:
Enterprise constraints

Sometimes referred to as semantic constraints - are additional rules specified by users or

database administrators and can be based on multiple tables. Here are some examples.

• A class can have a maximum of 30 students.

• A teacher can teach a maximum of four classes per semester.
• An employee cannot take part in more than five projects.
• The salary of an employee cannot exceed the salary of the employee's manager

Views

A view is a virtual or logical table that allows to view or manipulate parts of the tables.

To reduce REDUNDANT DATA to the minimum possible, Oracle allows the creation of an
object called a VIEW.

A View is mapped, to a SELECT sentence. The table on which the view is based is described in
the FROM clause of the SELECT statement.
Some Views are used only for looking at table data. Other Views can be used to Insert, Update
and Delete table data as well as View data
The reasons why views are created are:

• When Data security is required .

 • When Data redundancy is to be kept to the minimum while maintaining data security .

Types of views :

1. Read-only View :

• If a View is used to only look at table data and nothing else the View is called a Read-
Only View.
• Allows only SELECT operations.

2. Updateable View :

• A View that is used to look at table data as well as Insert, Update and Delete table data is
called an Updateable View.
• Allows SELECT as well as INSERT , UPDATE and DELETE operations.

Database Schema

A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are associated.
It formulates all the constraints that are to be applied on the data.

A database schema defines its entities and the relationship among them. It contains a descriptive
detail of the database, which can be depicted by means of schema diagrams. It’s the database
designers who design the schema to help programmers understand the database and make it
useful.
A database schema can be divided broadly into two categories −

• Physical Database Schema − This schema pertains to the actual storage of data and its
form of storage like files, indices, etc. It defines how the data will be stored in a
secondary storage.

• Logical Database Schema − This schema defines all the logical constraints that need to
be applied on the data stored. It defines tables, views, and integrity constraints.

Database Instance

Database schema is the skeleton of database. It is designed when the database doesn't exist at
all. Once the database is operational, it is very difficult to make any changes to it. A database
schema does not contain any data or information.

A database instance is a state of operational database with data at any given time. It contains a
snapshot of the database. Database instances tend to change with time. A DBMS ensures that its
every instance (state) is in a valid state, by diligently following all the validations, constraints,
and conditions that the database designers have imposed.