UNIT III : Relational Database Design

RELATION

Roughly a table in a relational database is called a relation.

A relation consist of

1. Relational scheme

2. Relational instances.

ATRIBUTE

The name of each column in a database is used to interpret its meaning is called

attribute.

DOMAIN

Each attribute is defined over a set of values known as its domain.

TUPLE

A tuple is a row in a relation\table.

DEGREE/ARITY

The no. of attributes in the relation scheme is called its degree or arity.

CARDINALITY

No. of tuples present in a relation scheme is called cardinality of a relation.

KEY

A key is an attribute or a set of attribute in a relation that uniquely identifies a tuple in a

relation.

Types of keys:

1) SUPER KEY: A super key is an attribute or any set of attributes that uniquely

identifies a row in a relation.

2) COMPOSITE KEY: A composite key is a key that contains more than one attribute.

3) CANDIDATE KEY: A candidate key is an attribute or set of attribute that uniquely

identifies a row in a relation. In other words minimal super key is called candidate

key.

4) PRIMARY KEY: A primary key is a candidate key which can uniquely identify a

record or tuple. Each table can have only one primary key. The primary key should be

selected in the manner such that it is unique and not null. .

5) ALTERNATE KEY: The alternate keys of any table are those candidate keys which

are not selected as the primary key.

AK(Alternate Key)=CK(Candidate Key)-PK(Primary Key)

6) OVERLAPPING KEY: The keys having common attributes are called overlapping

key.

7) FOREIGN KEY: Foreign key is a referential key which must be a primary key of

another table. This way we can link two tables for retrieving the data jointly. we only

insert those values which are present in the base table. If we delete the base table

automatically the the foreign key and primary key relationship is broken.

Codd’s Rules in DBMS

After conducting considerable research on the Relational Model of DB systems, Dr Edgar F.
Codd devised his own set of principles that a DB must follow in order to be considered a true
relational DB. The Codd’s rules can be applied to any DB system that merely has relational
capabilities for managing stored data. This is a fundamental rule that serves as the foundation for
all other rules.

What are the Codd’s Rules in DBMS?

Rule 0: The Foundation Rule

Rule 1: The Information Rule

Rule 2: The Guaranteed Access Rule

Rule 3: The Systematic Treatment of Null Values

Rule 4: The Dynamic/Active Online Catalog on the basis of the Relational Model
Rule 5: The Comprehensive Data SubLanguage Rule

Rule 6: The View Updating Rule

Rule 7: The Relational Level Operation (or High-Level Insert, Delete, and Update) Rule

Rule 8: The Physical Data Independence Rule

Rule 9: The Logical Data Independence Rule

Rule 10: The Integrity Independence Rule

Rule 11: The Distribution Independence Rule

Rule 12: The Non-Subversion Rule

What are the Codd’s Rules in DBMS?

Constraints can’t be referred to as a system of relational DBs because every DB has tables. A DB
that solely contains a relational data model cannot be called a Relational DB Management
System or RDBMS. Some rules determine if a DB is the correct RDBMS. Dr Edgar F. Codd,
who has extensive knowledge on the DB system’s Relational Model, proposed these principles in
1985. Codd presents his 13 criteria for a DB to evaluate the concept of a DB Management
System (DBMS) against the relational model. A DB that follows the rule is referred to as a real
relational DB management system (RDBMS). Codd’s rules are a set of rules that are widely used
in relational DBs.

Rule 0: The Foundation Rule

The DB must be structured in a relational manner so that the system’s relational capabilities can
manage the DB.

Rule 1: The Information Rule

A DB comprises a variety of data, which must be recorded in the form of columns and rows in
each and every cell of a table.

Rule 2: The Guaranteed Access Rule

A relational DB’s primary key value, column name, and table name can be used to conceptually
retrieve any single or precise data (the atomic value).

Rule 3: The Systematic Treatment of Null Values

The treatment of Null values in DB records is defined by this rule. No value in a cell, missing
data, unsuitable information, unknown data, the primary key that should not be null, etc., are all
examples of null values in DBs.

Rule 4: The Dynamic/Active Online Catalog on the basis of the Relational Model

A DB dictionary is a logical representation of the whole logical structure of a descriptive DB that

needs to be stored online. It grants users access to the DB and uses a query language that is
comparable to that of the DB.

Rule 5: The Comprehensive Data SubLanguage Rule

The relational DB supports a variety of languages, and in order to access the DB, the language
has to be linear, explicit, or a well-defined syntax, character strings. It must support the
following operations:

 Data definition.

 View definition.

 Data manipulation (interactive and by program).

 Integrity constraints.

 Authorization.

 Transaction boundaries (begin, commit and rollback).

It is considered a DB violation if the DB permits access to the data and information without the
use of any language.

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:

Rule 6: The View Updating Rule

A view table can theoretically be updated, and DB systems must update them in practice.

Rule 7: The Relational Level Operation (or High-Level Insert, Delete, and Update) Rule

In each level or single row, a DB system should adhere to high-level relational operations (for
example, update, insert, and delete). The DB system also includes operations like intersection,
union, and minus.

Rule 8: The Physical Data Independence Rule

To access a DB or an application, all stored data must be independent physically. Each piece of
data should not be reliant on another piece of data or an application. External applications that
access data from the DB will have no effect if data is altered or the physical structure of a given
DB is modified.

Rule 9: The Logical Data Independence Rule

It’s similar to the independence of physical data. It indicates that any modifications made at the
logical level (or the table structures) should not have an impact on the user’s experience
(application). For example, if a table is split into two separate tables or into two table joins in
order to produce a single table, the application at the user view should not be affected.

Rule 10: The Integrity Independence Rule

When we are using SQL to put data into table cells, a DB must guarantee integrity independence.
All the entered values must not be changed, and the integrity of the data should not be reliant on
any external component or application. It’s also useful for making each front-end app DB-
independent.

Rule 11: The Distribution Independence Rule

This rule denotes that a DB must function properly even if it’s stored in multiple locations and
used by various end-users. Let’s say a person uses an application to access the DB. In such a
case, they must not be aware that another user is using the same data, and thus, the data they
always obtain is only available on one site. The DB can be accessed by end-users, and each
user’s access data must be independent in order for them to run SQL queries.

Rule 12: The Non-Subversion Rule

RDBMS is defined by this rule as a SQL language for storing and manipulating data in a DB. If a
system uses a low-level or different language to access the DB system other than SQL, it should
not bypass or subvert data integrity.

Relational Integrity Constraints

Relational Integrity Constraints are the set of rules that can be used to maintain the data integrity
during an insert, delete and update operations into a table. These constraints are checked in the
database before performing any operation such as insertion, deletion, and updation on the tables.
There are four main types of relational integrity constraints:

 Key Constraint

 Domain Constraint

 Entity Integrity Constraint

 Referential Integrity Constraint

1. Key Constraint

Every table or relation in a database should have at least one attribute or a set of attributes which
uniquely identifies a record. Those attributes or a set of attributes is called key.

For example, rollno in the table ‘Student’ is a key. Two students cannot have the same roll
number. So, a key has two features:

It cannot have two values.

It should be unique for all the tuples.

2. Domain Constraint

Domain constraints are the attribute level constraints. A domain is a collection of possible values
for an attribute in the database table. An attribute or a field in a table can accept only those
values which are inside the domain range.

For example, in the below table Student, the rollno attribute has an integer domain so that an
attribute or a field cannot accept values that are not integers,i.e., rollno cannot have values
like10.11, ‘first’, etc.
3. Entity Integrity Constraint

Entity constraint specifies that the value of the primary key cannot be NULL. Because, if the
primary key has a NULL value, you cannot identify those rows. A field other than the primary
key field in a relation can have a NULL value.

Example: In the below table, Student, suppose rollno is the primary key. Thus, from the
definition of Entity Integrity constraint, the value of rollno cannot be null as it uniquely identifies
each record in the table.

Table: Student

rollno Name City Age

101 Akhil Meerut 20

102 Chetan Delhi 22

103 Anubhav Ghaziabad 21

104 Rishabh Shivam 20

4. Referential Integrity Constraint

A referential integrity constraint is a specified relationship between two tables. It can be defined
as when one field of a relation in a database can take the values from another field in the same
table or another table. The relationship between the database tables is established by the foreign
key.

Example:

Consider two relations Student and Course where rollno is the primary key in the Student table
and foreign key in the Course table.

rollno Name City Age

101 Akhil Meerut 20

102 Chetan Delhi 22

103 Anubhav Ghaziabad 21

104 Rishabh Shivam 20

Table: Student

Course_id Course_name rollno

C1 MCA 101

C2 MBA 102

C3 MCA 103

C4 MCA 104