UNIT – II Relational Model

ER and EER diagrams: Components of ER model, Conventions, Converting ER diagrams

into tables, Relational Model: Basic concepts, Attributes and Domains, Codd’s rules.
Relational Integrity: Nulls, Entity, Referential integrities, Enterprise constraints, Views,
Schema diagram. Case Study: Student/ Timetable/ Reservation/ any data Management
System

Components of an ER Diagram
An ER Diagram consists of the following components:

1. Entity
2. Attributes
3. Relationship

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
de?ned 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:

1. 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.
2. 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.
3. 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:
1. 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

1. 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.

2. Binary Relationship: When two entity set participates in a relationship

is called a binary relationship.

It is further categorized into four types:

a) 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.
b) 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.
c) 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.
d) 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.

Table
The following is the outcome of a successful conversion:

Emp no Dept id since

Scheme : Works in ( Emp No , Dept id , since )

Relationship of higher degree

The degree of relationship can be defined as the number of occurrences in one entity
that is associated with the number of occurrences in another entity.

There is the three degree of relationship:

1. One-to-one (1:1)
2. One-to-many (1:M)
3. Many-to-many (M:N)

1. One-to-one
o In a one-to-one relationship, one occurrence of an entity relates to only one occurrence
in another entity.
o A one-to-one relationship rarely exists in practice.
o For example: if an employee is allocated a company car then that car can only be
driven by that employee.
o Therefore, employee and company car have a one-to-one relationship.

2. One-to-many
o In a one-to-many relationship, one occurrence in an entity relates to many occurrences
in another entity.
o For example: An employee works in one department, but a department has many
employees.
o Therefore, department and employee have a one-to-many relationship.

3. Many-to-many
o In a many-to-many relationship, many occurrences in an entity relate to many
occurrences in another entity.
o Same as a one-to-one relationship, the many-to-many relationship rarely exists in
practice.
o For example: At the same time, an employee can work on several projects, and a
project has a team of many employees.
o Therefore, employee and project have a many-to-many relationship.

OR
Generalization, Specialization and
Aggregation in ER Model

DBMS Generalization

Generalization is a bottom-up approach in which the common attributes of two

or more lower-level entities combines to form a new higher-level entity. In
generalization, the generalized entity of higher level can also combine with
entities of the lower-level to make further higher-level entity.
It is like a superclass and subclass system, but the only difference is that it uses
the bottom-up approach. It helps in reducing the schema size. It is always
applied to the group of entities and result in the formation of a single entity.

According to the below diagram, there are two entities,

namely teacher and student. The teacher entity contains attributes such
as teacher_id, name, and address and student entity include student_id,
name, and address. Both entities can be combined to create a higher-level
entity person. The address and name are common to both the entities. The
teacher entity has its attribute teacher_id, and the student has its attribute
student_id. The entities teacher and student are generalized further into the
person entity.
A lower-level entity is called a subclass, and the higher-level entity is called a
superclass. So, the person entity is the superclass of two
subclasses teacher and student.
DBMS Specialization

It is opposite or inverse of generalization. A specialization is a top-down

approach in which an entity of higher-level entity is broken down into two or
more entities of lower level. In specialization, a higher-level entity set may not
have any lower-level entity set. It is always applied to a single entity and results
in the formation of multiple new entities. It increases the size of schema due to
the increase in the number of entities.

In the below example, it can be seen that the employee is a high-level entity
which is divided into three sub-entities (Ram, Shyam, and Mohan). The sub-
entities are the names of the employees (relating to the high-level entity).
Therefore, splitting a high-level entity into a low-level entity is
called specialization.

DBMS Aggregation

Through the Entity-Relationship model, we cannot express a relationship set

with another relationship set. Thus we use the concept of aggregation to
express it. Aggregation is an abstraction in which the relationship between two
entities is treated as a higher-level entity. It allows you to indicate that a
relationship set participates in another relationship set.

Example:
The student and program are two entity set and related through a relationship
set write. Suppose, a student who writes any program must require a
programming language installed in their system. So, there will be another
relationship set requires. You need to connect the relationship
set requires with an entity set programming language and relationship
set write. But, we can connect only entity set to a relationship set.
One relationship set cannot be connected with another relationship set; for this,
we need aggregation. Here, the write (relationship set) will treat like a higher-
level entity and can be associated with a relationship set requires. So,
aggregation is needed when you express a relationship set with another
relationship set.

An ER diagram is not capable of representing relationship between an entity

and a relationship which may be required in some scenarios. In those cases,
a relationship with its corresponding entities is aggregated into a higher level
entity. Aggregation is an abstraction through which we can represent
relationships as higher level entity sets.

For Example, Employee working for a project may require some machinery.
So, REQUIRE relationship is needed between relationship WORKS_FOR and
entity MACHINERY. Using aggregation, WORKS_FOR relationship with its
entities EMPLOYEE and PROJECT is aggregated into single entity and
relationship REQUIRE is created between aggregated entity and
MACHINERY.
Views in DBMS
Views in SQL are considered as a virtual table. A view also contains rows and
columns. To create the view, we can select the fields from one or more tables present
in the database. A view can either have specific rows based on certain condition or
all the rows of a table.

A view is nothing more than a SQL statement that is stored in the database with an
associated name. A view is actually a composition of a table in the form of a
predefined SQL query.
A view can contain all rows of a table or select rows from a table. A view can be
created from one or many tables which depends on the written SQL query to create
a view.
Views, which are a type of virtual tables allow users to do the following −
• Structure data in a way that users or classes of users find natural or
intuitive.
• Restrict access to the data in such a way that a user can see and
(sometimes) modify exactly what they need and no more.
• Summarize data from various tables which can be used to generate
reports.
Creating Views
Database views are created using the CREATE VIEW statement. Views can be
created from a single table, multiple tables or another view.
To create a view, a user must have the appropriate system privilege according to the
specific implementation.
The basic CREATE VIEW syntax is as follows −
CREATE VIEW view_name AS
SELECT column1, column2.....
FROM table_name
WHERE [condition];

You can include multiple tables in your SELECT statement in a similar way as you use
them in a normal SQL SELECT query.

Following is an example to create a view from the CUSTOMERS table. This view
would be used to have customer name and age from the CUSTOMERS table.

SQL > CREATE VIEW CUSTOMERS_VIEW AS

SELECT name, age
FROM CUSTOMERS;
Now, you can query CUSTOMERS_VIEW in a similar way as you query an actual
table. Following is an example for the same.

SQL > SELECT * FROM CUSTOMERS_VIEW;

This would produce the following result.

The WITH CHECK OPTION

The WITH CHECK OPTION is a CREATE VIEW statement option. The purpose of the
WITH CHECK OPTION is to ensure that all UPDATE and INSERTs satisfy the
condition(s) in the view definition.
If they do not satisfy the condition(s), the UPDATE or INSERT returns an error.
The following code block has an example of creating same view CUSTOMERS_VIEW
with the WITH CHECK OPTION.

CREATE VIEW CUSTOMERS_VIEW AS

SELECT name, age
FROM CUSTOMERS
WHERE age IS NOT NULL
WITH CHECK OPTION;

The WITH CHECK OPTION in this case should deny the entry of any NULL values in
the view's AGE column, because the view is defined by data that does not have a
NULL value in the AGE column.
Updating a View
A view can be updated under certain conditions which are given below −
• The SELECT clause may not contain the keyword DISTINCT.
• The SELECT clause may not contain summary functions.
• The SELECT clause may not contain set functions.
• The SELECT clause may not contain set operators.
• The SELECT clause may not contain an ORDER BY clause.
• The FROM clause may not contain multiple tables.
• The WHERE clause may not contain subqueries.
• The query may not contain GROUP BY or HAVING.
• Calculated columns may not be updated.
• All NOT NULL columns from the base table must be included in the
view in order for the INSERT query to function.

So, if a view satisfies all the above-mentioned rules then you can update that view.
The following code block has an example to update the age of Ramesh.

SQL > UPDATE CUSTOMERS_VIEW

SET AGE = 35
WHERE name = 'Ramesh';

This would ultimately update the base table CUSTOMERS and the same would
reflect in the view itself. Now, try to query the base table and the SELECT statement
would produce the following result.
Inserting Rows into a View
Rows of data can be inserted into a view. The same rules that apply to the UPDATE
command also apply to the INSERT command.
Here, we cannot insert rows in the CUSTOMERS_VIEW because we have not
included all the NOT NULL columns in this view, otherwise you can insert rows in a
view in a similar way as you insert them in a table.

Deleting Rows into a View

Rows of data can be deleted from a view. The same rules that apply to the UPDATE
and INSERT commands apply to the DELETE command.
Following is an example to delete a record having AGE = 22.

SQL > DELETE FROM CUSTOMERS_VIEW

WHERE age = 22;

This would ultimately delete a row from the base table CUSTOMERS and the same
would reflect in the view itself. Now, try to query the base table and the SELECT
statement would produce the following result.

Dropping Views
Obviously, where you have a view, you need a way to drop the view if it is no longer
needed. The syntax is very simple and is given below −
DROP VIEW view_name;
Following is an example to drop the CUSTOMERS_VIEW from the CUSTOMERS
table.

DROP VIEW CUSTOMERS_VIEW;

More examples on Views
Student_Detail

STU_ID NAME ADDRESS

1 Stephan Delhi
2 Kathrin Noida
3 David Ghaziabad
4 Alina Gurugram

Student_Marks

STU_ID NAME MARKS AGE

1 Stephan 97 19
2 Kathrin 86 21
3 David 74 18
4 Alina 90 20
5 John 96 18
1. Creating view
A view can be created using the CREATE VIEW statement. We can create a view from
a single table or multiple tables.

Syntax:
1. CREATE VIEW view_name AS
2. SELECT column1, column2.....
3. FROM table_name
4. WHERE condition;

2. Creating View from a single table

In this example, we create a View named DetailsView from the table Student_Detail.

Query:
1. CREATE VIEW DetailsView AS
2. SELECT NAME, ADDRESS
3. FROM Student_Details
4. WHERE STU_ID < 4;

Just like table query, we can query the view to view the data.

1. SELECT * FROM DetailsView;

Output:

NAME ADDRESS
Stephan Delhi
Kathrin Noida
David Ghaziabad

3. Creating View from multiple tables

View from multiple tables can be created by simply include multiple tables in the
SELECT statement.

In the given example, a view is created named MarksView from two tables
Student_Detail and Student_Marks.

Query:

1. CREATE VIEW MarksView AS

2. SELECT Student_Detail.NAME, Student_Detail.ADDRESS, Student_Marks.MARKS
3. FROM Student_Detail, Student_Mark
4. WHERE Student_Detail.NAME = Student_Marks.NAME;

To display data of View MarksView:

1. SELECT * FROM MarksView;

NAME ADDRESS MARKS

Stephan Delhi 97
Kathrin Noida 86
David Ghaziabad 74
Alina Gurugram 90
Constraints in DBMS
Constraints enforce limits to the data or type of data that can be inserted/updated/deleted from
a table. The whole purpose of constraints is to maintain the data integrity during an
update/delete/insert into a table. In this tutorial we will learn several types of constraints that
can be created in RDBMS.

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.
 2. Entity integrity constraints
(Entity is further converted into table. So its constraints on table)

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.

3. Referential Integrity Constraints

o A referential integrity constraint is specified between two 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.
NOT NULL:
NOT NULL constraint makes sure that a column does not hold NULL value.
When we don’t provide value for a particular column while inserting a record
into a table, it takes NULL value by default. By specifying NULL constraint, we
can be sure that a particular column(s) cannot have NULL values.

Example:

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
STU_ADDRESS VARCHAR (235),
PRIMARY KEY (ROLL_NO));
UNIQUE:
UNIQUE Constraint enforces a column or set of columns to have unique
values. If a column has a unique constraint, it means that particular column
cannot have duplicate values in a table.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL UNIQUE,
STU_AGE INT NOT NULL,
STU_ADDRESS VARCHAR (35) UNIQUE,
PRIMARY KEY (ROLL_NO));

DEFAULT:
The DEFAULT constraint provides a default value to a column when there is
no value provided while inserting a record into a table.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
EXAM_FEE INT DEFAULT 10000,
STU_ADDRESS VARCHAR (35) ,
PRIMARY KEY (ROLL_NO)
);

CHECK:
This constraint is used for specifying range of values for a particular column
of a table. When this constraint is being set on a column, it ensures that the
specified column must have the value falling in the specified range.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL CHECK(ROLL_NO >1000) ,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
EXAM_FEE INT DEFAULT 10000,
STU_ADDRESS VARCHAR (35) ,
PRIMARY KEY (ROLL_NO));

In the above example we have set the check constraint on ROLL_NO column
of STUDENT table. Now, the ROLL_NO field must have the value greater than
1000.
Key constraints:
PRIMARY KEY and Foreign Keys

Foreign Key

-- Create a table
CREATE TABLE Department(DEPTNO,DNAME VARCHAR(30));

-- Insert some values

INSERT INTO Department(DEPTNO, DNAME) VALUES (10, 'IT');INSERT INTO
Department(DEPTNO, DNAME) VALUES (20, 'Civil');INSERT INTO
Department(DEPTNO, DNAME) VALUES (30, 'Mechanical');

-- Fetch some values

SELECT * FROM Department;

-- Create a table
CREATE TABLE Employee1(ENO INTEGER PRIMARY KEY, ENAME VARCHAR(20),
JOD VARCHAR(15),DEPTNO INTEGER references Department(DEPTNO) on
delete restrict);

-- Insert some values

INSERT INTO Employee1 (ENO , ENAME, JOD,DEPTNO) VALUES (1,
'Gunjal','Professor', 10);

INSERT INTO Employee1 (ENO , ENAME, JOD,DEPTNO) VALUES (2, 'Patil',

'Professor', 20);

INSERT INTO Employee1 (ENO , ENAME, JOD,DEPTNO) VALUES (3,

'Rahane','Professor', 30);
-- Fetch some values
SELECT * FROM Employee1;

Observations:

Case:1
Drop TABLE Department;
Gives output:
Error: FOREIGN KEY constraint failed

Drop TABLE Employee;

Gives output:
SQL query successfully executed.

Drop TABLE Department;

Gives output:
SQL query successfully executed.

Case:2
Perform following query removing delete restrictions
Drop TABLE Department;

References:
https://www.youtube.com/watch?v=V_zL94zyuYc
https://www.mycompiler.io/new/mysql
Database Schema

Schema diagram
The design of the database is called a schema. This tells us about the structural view of the
database. It gives us an overall description of the database. A database schema defines how
the data is organised using the schema diagram.

Example: Let us suppose we have three tables Employee, Department and Project. So, we
can represent the schema of these three tables using the schema diagram as follows. In
this schema diagram, Employee and Department are related and the Employee and Project
table are related.
There are three levels of the schema. The three levels of the database schema are defined
according to the three levels of data abstraction .
• View Schema
• Logical Schema
• Physical Schema
View Schema or External Schema
View Schema defines the design of the database at the view level of the data abstraction. It
defines how an end-user will interact with the database system. There are many view schema
for a database system. Each view schema defines the view of data for a particular group of
people. It shows only those data to a view group in which they are interested and hides the
remaining details from them.
Example : A website has different views depending upon the user's authorization. A college
website has a different view for students, faculty and dean. Similarly, a companies website
would have a different view for the employee, accountant and manager.

Logical Schema or Conceptual Schema

Logical Schema defines the design of the database at the conceptual level of the data
abstraction. At this level, we define the entities, attributes, constraints, relationships, etc. and
how their relationship would be logically implemented. The programmers and the DBA work
at this level and they do all these implementations.

External/Conceptual Mapping is done between the external schema and logical schema to
transform the request from an external schema to the conceptual schema. This mapping
relates the external schema with the logical schema.
Example: If we have to define an employee schema then it will have attributes like
Emlpoyee_id, Name, Age, Salary, Phone_no etc. So, the data types for these attributes would
be defined here. Also, if we have more than one table in our schema then how these tables
would be related is also defined here. Like if we have some more tables like department table
and project table then how these tables would be related is defined here.
Reduction/Converting ER Diagrams into Tables-
Following rules are used for converting an ER diagram into the tables-

Rule-01: For Strong Entity Set With Only Simple Attributes-

A strong entity set with only simple attributes will require only one table in relational
model.
• Attributes of the table will be the attributes of the entity set.
• The primary key of the table will be the key attribute of the entity set.

Example-

Roll_no Name Sex

Schema : Student ( Roll_no , Name , Sex )

Rule-02: For Strong Entity Set With Composite Attributes-

• A strong entity set with any number of composite attributes will require only one
table in relational model.
• While conversion, simple attributes of the composite attributes are taken into
account and not the composite attribute itself.

Example-

Roll_no First_name Last_name House_no Street City

Schema : Student ( Roll_no , First_name , Last_name , House_no , Street , City )

Rule-03: For Strong Entity Set With Multi Valued Attributes-

Roll_no City Roll_no Mobile_no

Rule-04: Translating Relationship Set into a Table-

Emp_no Dept_id since

Schema : Works in ( Emp_no , Dept_id , since )

NOTE-
If we consider the overall ER diagram, three tables will be required in relational model-
• One table for the entity set “Employee”
• One table for the entity set “Department”
• One table for the relationship set “Works in”
Sample Problem-

Solution-

Applying the rules that we have learnt, minimum 6 tables will be

required-
• Account (Ac_no , Balance , b_name)
• Branch (b_name , b_city , Assets)
• Loan (L_no , Amt , b_name)
• Borrower (C_name , L_no)
• Customer (C_name , C_street , C_city)
• Depositor (C_name , Ac_no)
Rule-05: For Binary Relationships With Cardinality Ratios-
The following four cases are possible-
Case-01: Binary relationship with cardinality ratio m:n
Case-02: Binary relationship with cardinality ratio 1:n
Case-03: Binary relationship with cardinality ratio m:1
Case-04: Binary relationship with cardinality ratio 1:1

Also read- Cardinality Ratios in DBMS

Case-01: For Binary Relationship With Cardinality Ratio m:n

Here, three tables will be required-

1. A ( a1 , a2 )
2. R ( a1 , b1 )
3. B ( b1 , b2 )

Case-02: For Binary Relationship With Cardinality Ratio 1:n

Here, two tables will be required-

1. A ( a1 , a2 )
2. BR ( a1 , b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set B and relationship set R.
Case-03: For Binary Relationship With Cardinality Ratio m:1

Here, two tables will be required-

1. AR ( a1 , a2 , b1 )
2. B ( b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set A and relationship set R.

Case-04: For Binary Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’

Way-01:
1. AR ( a1 , a2 , b1 )
2. B ( b1 , b2 )

Way-02:
1. A ( a1 , a2 )
2. BR ( a1 , b1 , b2 )
 Thumb Rules to Remember
While determining the minimum number of tables required for binary relationships
with given cardinality ratios, following thumb rules must be kept in mind-
• For binary relationship with cardinality ration m : n , separate and individual
tables will be drawn for each entity set and relationship.
• For binary relationship with cardinality ratio either m : 1 or 1 : n , always
remember “many side will consume the relationship” i.e. a combined table
will be drawn for many side entity set and relationship set.
• For binary relationship with cardinality ratio 1 : 1 , two tables will be required.
You can combine the relationship set with any one of the entity sets.

Rule-06: For Binary Relationship With Both Cardinality Constraints and Participation
Constraints-

• Cardinality constraints will be implemented as discussed in Rule-05.

• Because of the total participation constraint, foreign key acquires NOT
NULL constraint i.e. now foreign key can not be null.

Case-01: For Binary Relationship With Cardinality Constraint and Total Participation Constraint
From One Side-

Because cardinality ratio = 1 : n , so we will combine the entity set B and relationship set
R.
Then, two tables will be required-
1. A ( a1 , a2 )
2. BR ( a1 , b1 , b2 )
Because of total participation, foreign key a1 has acquired NOT NULL constraint, so it
can’t be null now.
Case-02: For Binary Relationship With Cardinality Constraint and Total Participation Constraint
From Both Sides-

If there is a key constraint from both the sides of an entity set with total participation,
then that binary relationship is represented using only single table.

Here, Only one table is required.

• ARB ( a1 , a2 , b1 , b2 )

Rule-07: For Binary Relationship With Weak Entity Set-

Weak entity set always appears in association with identifying relationship with total
participation constraint.

Here, two tables will be required-

1. A ( a1 , a2 )
2. BR ( a1 , b1 , b2 )
Codd’s Rule of DBMS

Database having certain constraints and tables, need not to be a relational database
system always. For perfect database management system, there are certain rules for
the database, popularly known as Codd’s 13 (0 to 12) rules. These rules were
proposed by Dr Edgar Frank Codd (EF Codd) in 1985 to define a perfect relational
database system. For a relational database to be a perfect, it has to follow its rules.
But, no RDBMS can follow or obey all its rules. Oracle database only obeys 8.5
rules out of 13.
A database management system that satisfies Codd’s rules is called a fully
relational database management system.

The Codd’s 13 rules (0 to 12) for the relational databases are as follows:
Rule 0: Foundation Rule
This rule defines that for a system to qualify as an RDBMS, it must be able to
manage the database entirely through the relational capabilities.

Rule 1: Information Rule

This rule defines that the data stored in the relational model is in the form of rows
and columns of tables.

Rule 2: Guaranteed Access Rule

This rule defines that every data should be logically accessible through the
combination of a table name, primary key, and name of the attribute or column.

Rule 3: Systematic Treatment of NULL values

In a relational database, NULL values represent the missed and inapplicable
information in a systematic way. A NULL value is a special value, which is neither
zero nor empty string. All the database systems support the NULL value concept.

Rule 4: Dynamic On-Line catalog based on the relational model

This rule defines that the structure of the database must support online relational
catalog that is accessible to authorized users using its regular query language.

Rule 5: Comprehensive Data sub-language Rule

This rule states that the database system should be accessible by language support
for data definition, data manipulation, and transaction management operation.

Rule 6: View Updating Rule

This rule states that all the views which are theoretically updated must be updated by
the system (i.e. practical).

Rule 7: High-level Insertion, Updation and Deletion

This rule states that the relational database model must support insert, delete, and
update operation on multiple rows.

Rule 8: Physical Data Independence

This rule states that the application program should remain unchanged whenever
any change occur either in access methods or storage representation.

Rule 9: Logical Data Independence

This rule states that any changes in the conceptual or logical schema of a table
should not enforce modification at application programs or External schema.

Rule 10: Integrity Independence

This rule states that a relational database system should support different constraints
on data for data integrity. All the database system should support primary key
constraint and foreign key constraint.

Rule 11: Distributed Independence

This rule implies that the user need not to be aware of whether a database is
distributed over multiple locations or not. The user can access the data without any
ambiguity from the different server.
Rule 12: Non-Subversion Rule
If the system provides a low-level interface, that interface cannot be used to subvert
or not be able to bypass integrity rule to change data. This can be achieved by some
encryption techniques.

Case Study: Data Management Systems

Example-1:: Hospital Management System
Example-2:: Bank Management System
Example-3:: Medical Shop Management System