UNIT

2
Dr Edgar F. Codd, after his extensive research on the Relational Model of database systems, came up with
twelve rules of his own, which according to him, a database must obey in order to be regarded as a true
relational database.
Rule 1: Information Rule
The data stored in a database, may it be user data or metadata, must be a value of some table cell.
Everything in a database must be stored in a table format.
Rule 2: Guaranteed Access Rule
Every single data element (value) is guaranteed to be accessible logically with a combination of table-
name, primary-key (row value), and attribute-name (column value). No other means, such as pointers,
can be used to access data.
Rule 3: Systematic Treatment of NULL Values
The NULL values in a database must be given a systematic and uniform treatment. This is a very
important rule because a NULL can be interpreted as one the following − data is missing, data is not
known, or data is not applicable.
Rule 4: Active Online Catalog
The structure description of the entire database must be stored in an online catalog, known as data
dictionary, which can be accessed by authorized users. Users can use the same query language to access
the catalog which they use to access the database itself.
Rule 5: Comprehensive Data Sub-Language Rule
A database can only be accessed using a language having linear syntax that supports data definition, data
manipulation, and transaction management operations. This language can be used directly or by means of
some application. If the database allows access to data without any help of this language, then it is
considered as a violation.
Rule 6: View Updating Rule
Any view that can be defined using combination of base tables, and theoretically updatable, must also be
capable of being updated by the RDBMS.
Rule 7: High-Level Insert, Update, and Delete Rule
A database must support high-level insertion, updation, and deletion. This must not be limited to a single
row, that is, it must also support union, intersection and minus operations to yield sets of data records.
Rule 8: Physical Data Independence
The data stored in a database must be independent of the applications that access the database. Any
change in the physical structure of a database must not have any impact on how the data is being
accessed by external applications.
Rule 9: Logical Data Independence
The logical data in a database must be independent of its user’s view (application). Any change in logical
data must not affect the applications using it. For example, if two tables are merged or one is split into two
different tables, there should be no impact or change on the user application. This is one of the most
difficult rule to apply.
 Rule 10: Integrity Independence
A database must be independent of the application that uses it. All its integrity constraints can be
independently modified without the need of any change in the application. This rule makes a database
independent of the front-end application and its interface.
Rule 11: Distribution Independence
The end-user must not be able to see that the data is distributed over various locations. Users should
always get the impression that the data is located at one site only. This rule has been regarded as the
foundation of distributed database systems.
Rule 12: Non-Subversion Rule
If the RDBMS supports facilities allowing application programs to operate on a table a row at a time ,
then an application program using this type of database access is prevented from bypassing entity-
integrity or referential integrity constraints that may be defined for the database.

Entity :
• An entity is an object of concern used to represent the things in the real world, e.g., car, table, book, etc.
• An entity need not be a physical entity, it can also represent a concept in real world, e.g., project, loan,
etc.
• It represents a class of things, not any one instance, e.g., ‘STUDENT’ entity has instances of ‘Ramesh’
and ‘Mohan’.
Entity Set or Entity Type: A collection of a similar kind of entities is called an Entity Set or entity
type.
Ex. For the COLLEGE database described earlier objects of concern are Students, Faculty, Course and
departments. The collections of all the students entities form a entity set STUDENT. Similarly collection
of all the courses form an entity set COURSE.
Entity sets need not be disjoint. For example – an entity may be part of the entity set STUDENT, the
entity set FACULTY, and the entity set PERSON.

Attribute: An attribute is a property used to describe the specific feature of the entity. So to
describe an entity entirely, a set of attributes is used. For example, a student entity may be described by
the student’s name, age, address, course, etc.
An entity will have a value for each of its attributes. For example for a particular student the following
values can be assigned:
RollNo: 1234
Name: rajeev
Age: 18
Address: B-4, Mayapuri, Delhi.
Course: BCA
Each simple attribute of an entity type contains a possible set of values that can be attached to it. This is
called the domain of an attribute. An attribute cannot contain a value outside this domain.
EXAMPLE- for PERSON entity PERSON_ID has a specific domain, integer values say from 1 to 100
 Types of attributes
Attributes attached to an entity can be of various types.
1) Simple: The attribute that cannot be further divided into smaller parts and represents the basic
meaning is called a simple attribute. For example: The ‘First name’, ‘Last name’, age attributes of a
person entity represent a simple attribute.
2) Composite: Attributes that can be further divided into smaller units and each individual unit
contains a specific meaning. For example:-The NAME attribute of an employee entity can be sub-divided
into First name, Last name and Middle name.
3) Single valued: Attributes having a single value for a particular entity. For Example, Age is a
single valued attribute of a student entity.
4) Multivalued: Attributes that have more than one values for a particular entity is called a
multivalued attribute. Different entities may have different number of values for these kind of
attributes. For multivalued attributes we must also specify the minimum and maximum number of
vales that can be attached. For Example phone number for a person entity is a multivalued
attribute.
5) Stored: Attributes that are directly stored in the data base. For example, ‘Birth date’ attribute of
a person.
6) Derived: Attributes that are not stored directly but can be derived from stored attributes are
called derived attributes. For Example, The years of services of a ‘person’ entity can be
determined from the current date and the date of joining of the person. Similarly, total salary of a
‘person’ can be calculated from ‘basic salary’ attribute of a ‘person’.
7) Key attribute: The key attribute is an attribute that uniquely identifies an entity in the entity set.
For example, emp_code can be the key attribute for the entity set employee.
•
Relationship:
A relationship can be defined as:
➢ a connection or set of associations, or
➢ a rule for communication among entities:
Example: In college the database, the association between student and course entity, i.e., “Student opts
course” is an example of a relationship.

Relationship sets A relationship set is a set of relationships of the same type. For example, consider the
relationship between two entity sets student and course. Collection of all the instances of relationship opts
forms a relationship set called relationship type.

Degree The degree of a relationship type is the number of participating entity types. The
relationship between two entities is called binary relationship. A relationship among three entities is
called ternary relationship. Similarly relationship among n entities is called n-ry relationship.

Relationship Cardinality
Cardinality specifies the number of instances of an entity associated with another entity participating in a
relationship. Based on the cardinality binary relationship can be further classified into the following
categories:
1) One-to-one: An entity in A is associated with at most one entity in B, and an entity in B is associated
with at most one entity in A.
Example: Relationship between college and principal One college can have at the most one principal and
one principal can be assigned to only one college.
Similarly we can define the relationship between university and Vice Chancellor.

2) One-to-many: An entity in A is associated with any number of entities in B.

An entity in B is associated with at the most one entity in A.
Example: Relationship between department and faculty. One department can appoint any number of
faculty members but a faculty member is assigned to only one department.

3) Many-to-one: An entity in A is associated with at most one entity in B. An

entity in B is associated with any number in A.
Example : Relationship between course and instructor. An instructor can teach various courses but a
course can be taught only by one instructor.
 4) Many-to-many: Entities in A and B are associated with any number of entities
from each other.
 Example: Taught by Relationship between course and faculty. One faculty member can be
assigned to teach many courses and one course may be taught by many faculty members.

Keys for the Relations

1) Super Key: A super key is an attribute or set of attributes used to identify the records
uniquely in a relation.
For Example, in the Relation PERSON described earlier PERSON_ID is a super key
since PERSON_ID is unique for each person. Similarly (PERSON_ID, AGE) and
(PERSON_ID, NAME) are also super keys of the relation PERSON since their
combination is also unique for each record.

2) Candidate key: Super keys of a relation can contain extra attributes. Candidate
keys are minimal super key, i.e. such a key contains no extraneous attribute. An
attribute is called extraneous if even after removing it from the key, makes the
remaining attributes still has the properties of a key. The following properties must be
satisfied by the candidate keys:
➢ A candidate key must be unique.
➢ A candidate key’s value must exist. It cannot be null. (This is also
called entity integrity rule)
➢ A candidate key is a minimal set of attributes.
➢ The value of a candidate key must be stable. Its value cannot change
outside the control of the system.

3) Primary Key: A relation can have more than one candidate keys and one of them
can be chosen as primary key.
For example, in the relation PERSON the two possible candidate keys are PERSONID
and NAME (assuming unique names in the table). PERSON-ID may be chosen as the
primary key.
4) Composite Key: In many cases as we design a database, we will have tables that will
use more than one column as part of the primary key. These are called composite keys. A
composite key is a group of fields that are combined together to uniquely identify a
record.
5) Foreign Key: In a relation, the column whose data values correspond to the values
of a key column in another relation is called a foreign key. The foreign key in a
relation may be the primary key of another relation.
6) Unique Key: A unique key is a set of one or more attribute that can be used to
uniquely identify the records in table. Unique key is similar to primary key but
unique key field can
contain a “Null” value but primary key doesn’t allow “Null” value. Other difference is
that primary key field contain a clustered index and unique field contain a non-clustered
index.
 WEAK ENTITY: Entity types that do not contain any key attribute, and hence cannot be
identified independently, are called weak entity types. A weak entity can be identified uniquely
only by considering some of its attributes in conjunction with the primary key attributes of another
entity, which is called the identifying owner entity. Generally a partial key is attached to a weak
entity type that is used for unique identification of weak entities related to a particular owner entity
type. The following restrictions must hold:
➢ The owner entity set and the weak entity set must participate in one to many
relationship set. This r0elationship set is called the identifying relationship set of the
weak entity set.
➢ The weak entity set must have total participation in the identifying relationship.

EXAMPLE: Consider the entity type dependent related to employee entity, which is used to keep
track of the dependents of each employee. The attributes of dependents are: name, birth date, sex
and relationship. Each employee entity is said to own the dependent entities that are related to it.
However, please note that the ‘dependent’ entity does not exist of its own, it is dependent on the
Employee entity. In other words we can say that in case an employee leaves the organization all
dependents related to him/her also leave along with. Thus, the ‘dependent’ entity has no
significance without the entity ‘employee’. Thus, it is a weak entity.
Enhanced E-R and object modeling:
Although, the basic features of E-R diagrams are sufficient to design many database situations.
However, with more complex relations and advanced database applications, it is required to move
to enhanced features of E-R models. The three such features are:
➢ Generalization
➢ Specializations, and
➢ Aggregation

Generalization and Specializations:

Example 21: A bank has an account entity set. The accounts of the bank can be of two
types:
❖ Savings account
❖ Current account
The statement as above represents a specialization / generalization hierarchy. It can be
shown as:
Aggregation is a process in which a single entity alone is not able to make sense in a relationship so the
relationship of two entities acts as one entity.