RDBMS UNIT 2 NOTES

Discuss ER Diagram.
ER Diagram stands for Entity Relationship Diagram. It displays the relationship of entity sets stored in a
database. In other words, ER diagrams help to explain the logical structure of databases. ER diagrams
are created based on three basic concepts: entities, attributes and relationships. ER Diagrams contain
following symbols:

Rectangle: Represents Entity sets.

Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set

Figure – ER Diagram Symbol

Figure – ER Diagram Example

1
Discuss Entity Relationship Model.
Or
Discuss ER Model.
 An Entity–relationship model (ER model) describes the structure of a database with the help of a
diagram, which is known as Entity Relationship Diagram (ER Diagram).
 An ER model is a design or blueprint of a database that can later be implemented as a database.

As shown in the above diagram, an ER diagram has three main components:

1. Entity
2. Attribute
3. Relationship

1. Entity
An entity is an object or component of data. An entity is represented as rectangle in an ER diagram.
For example: In the following ER diagram we have two entities Student and College and these two
entities have many to one relationship as many students study in a single college.

2
Weak Entity:

An entity that cannot be uniquely identified by its own attributes and relies on the relationship with other
entity is called weak entity. The weak entity is represented by a double rectangle. For example – a bank
account cannot be uniquely identified without knowing the bank to which the account belongs, so bank
account is a weak entity Example : Below Figure.

Weak Entity Sets

 An entity set that does not have a primary key is referred to as a weak entity set. It is represented
by a double rectangle symbol.
 In a weak entity set, it is a combination of primary key and partial key of the strong entity set.
The relationship between one strong and a weak entity set shown by using the double diamond
symbol.

2. Attribute
An attribute describes the property of an entity. An attribute is represented as Oval in an ER diagram.

There are four types of attributes:

1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute

1. Key attribute:
A key attribute can uniquely identify an entity from an entity set. For example, student roll number can
uniquely identify a student from a set of students. Key attribute is represented by oval same as other
attributes however the text of key attribute is underlined

3
 Figure – Key Attribute

2. Composite attribute:

An attribute that is a combination of other attributes is known as composite attribute. For example, In
student entity, the student address is a composite attribute as an address is composed of other attributes
such as pin code, state, country.

4
3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is represented with double
ovals in an ER Diagram. For example – A person can have more than one phone numbers so the phone
number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is dynamic and derived from another attribute. It is represented by
dashed oval in an ER Diagram. For example – Person age is a derived attribute as it changes over time
and can be derived from another attribute (Date of birth).

Figure - E-R diagram with Multivalued and Derived attributes

3. Relationship
A relationship is represented by diamond shape in ER diagram, it shows the relationship among entities.
There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of another entity then it is called
one to one relationship. For example, a person has only one passport and a passport is given to one
person.

5
2. One to Many Relationship

When a single instance of an entity is associated with more than one instances of another entity then it is
called one to many relationship. For example – a customer can place many orders but a order cannot be
placed by many customers.

3. Many to One Relationship

When more than one instances of an entity is associated with a single instance of another entity then it is
called many to one relationship. For example – many students can study in a single college but a student
cannot study in many colleges at the same time.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one instances of another entity
then it is called many to many relationship. For example, a can be assigned to many projects and a
project can be assigned to many students.

Relationship Set

A relationship set is a mathematical relation among n ≥ 2 entities, each taken from entity sets.

6
Degree of a Relationship Set

Degree of a Relationship Set Refers to number of entity sets that participate in a relationship set.
Relationship sets that involve two entity sets are binary (or degree two). Generally, most relationship sets
in a database system are binary. Relationships between more than two entity sets are rare. Most
relationships are binary.

Discuss ER Design Issues

1. Choosing Entity Set vs Attributes

 Here we will discuss how choosing an entity set vs an attribute can change the whole ER design
semantics. To understand this lets take an example, let’s say we have an entity set Student with
attributes such as student-name and student-id. Now we can say that the student-id itself can be
an entity with the attributes like student-class and student-section.
 Now if we compare the two cases we discussed above, in the first case we can say that the student
can have only one student id, however in the second case when we chose student id as an entity
it implied that a student can have more than one student id.
 So, Choice mainly depends on the structure of the enterprise being modeled, and on the semantics
associated with the attribute in question.

2. Choosing Entity Set vs. Relationship Sets

It is hard to decide that an object can be best represented by an entity set or relationship set. To
comprehend and decide the perfect choice between these two (entity vs relationship), the user needs to
understand whether the entity would need a new relationship if a requirement arise in future, if this is the
case then it is better to choose entity set rather than relationship set. So Possible guideline is to designate
a relationship set to describe an action that occurs between entities.

3. Choosing Binary vs n-ary Relationship Sets

In most cases, the relationships described in an ER diagrams are binary. The n-ary relationships are those
where entity sets are more than two, if the entity sets are only two, their relationship can be termed as
binary relationship. The n-ary relationships can make ER design complex, however the good news is that
we can convert and represent any n-ary relationship using multiple binary relationships.

7
Describe Mapping Constraints

Mapping constraints defines how many entities can be related to another entity to a relationship. It is very
much useful for identifying relationships that are involved with more than one relationship

Mapping constraints can be explained in terms of mapping cardinality:

o These are as follows:

1. One to one (1:1)

2. One to many (1:M)

3. Many to one (M:1)

4. Many to many (M:M)

1.One-to-one

In one-to-one mapping, an entity in E1 is associated with at most one entity in E2, and an entity in E2 is
associated with at most one entity in E1.

2. One-to-many

In one-to-many mapping, an entity in E1 is associated with any number of entities in E2, and an entity in
E2 is associated with at most one entity in E1.

8
3. Many-to-one

In one-to-many mapping, an entity in E1 is associated with at most one entity in E2, and an entity in E2 is
associated with any number of entities in E1.

4. Many-to-many

In many-to-many mapping, an entity in E1 is associated with any number of entities in E2, and an entity in
E2 is associated with any number of entities in E1.

Why we need a Key?

Keys help you to identify any row of data in a table. In a real-world application, a table could contain
thousands of records. Moreover, the records could be duplicated. Keys in RDBMS ensure that you can
uniquely identify a table record despite these challenges.
Allows you to establish a relationship between and identify the relation between tables
Help you to enforce identity and integrity in the relationship.

Types of Keys:
 Candidate key
 Super Key
 Primary key
 Foreign key
 Alternate key
 Composite key

9
Candidate key
 A candidate key is an attribute or set of attributes that can uniquely identify a tuple.
 Except for the primary key, the remaining attributes are considered a candidate key. The candidate
keys are as strong as the primary key.
 For example: In the EMPLOYEE table, id is best suited for the primary key. The rest of the
attributes, like SSN, Passport_Number, License_Number, etc., are considered a candidate key.

Figure : Candidate Key

Super Key
Super key is an attribute set that can uniquely identify a tuple. A super key is a superset of a candidate
key.

Figure – Super Key

10
For example: In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME), the name of two
employees can be the same, but their EMPLYEE_ID can't be the same. Hence, this combination can also
be a key. The super key would be EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME), etc.

Primary key

Primary key is used to identify one and only one instance of an entity uniquely. An entity can contain
multiple keys, as we saw in the PERSON table. The key which is most suitable from those lists becomes
a primary key.

In the EMPLOYEE table, ID can be the primary key since it is unique for each employee. In the
EMPLOYEE table, we can even select License_Number and Passport_Number as primary keys since
they are also unique. For each entity, the primary key selection is based on requirements and developers.

Foreign key

 Foreign keys are the column of the table used to point to the primary key of another table.
 Every employee works in a specific department in a company, and employee and department are
two different entities. So we can't store the department's information in the employee table. That's
why we link these two tables through the primary key of one table.
 We add the primary key of the DEPARTMENT table, Department_Id, as a new attribute in the
EMPLOYEE table.

In the EMPLOYEE table, Department_Id is the foreign key, and both the tables are related.

11
Alternate key

There may be one or more attributes or a combination of attributes that uniquely identify each tuple in a
relation. These attributes or combinations of the attributes are called the candidate keys. One key is chosen
as the primary key from these candidate keys, and the remaining candidate key, if it exists, is termed the
alternate key.

Composite key

Whenever a primary key consists of more than one attribute, it is known as a composite key. This key is
also known as Concatenated Key.

12
Discuss Extended E-R Features.

Basic E-R model is good for many uses. The Following extensions are usefull to E-R model for more
advanced modeling.

Three new concepts were added to the existing ER Model, they were:

1. Generalization
2. Specialization
3. Aggregration

1. Generalization

 Generalization is a bottom-up approach in which two lower level entities combine to form a higher
level entity.
 In generalization, the higher level entity can also combine with other lower level entities to make
further higher level entity.
 It's more like Superclass and Subclass system, but the only difference is the approach, which is
bottom-up. Hence, entities are combined to form a more generalised entity, in other words, sub-
classes are combined to form a super-class.

For example, Saving and Current account types entities can be generalised and an entity with
name Account can be created, which covers both.

13
2. Specialization
 Specialization is opposite to Generalization.
 It is a top-down approach in which one higher level entity can be broken down into two lower level
entity. In specialization, a higher level entity may not have any lower-level entity sets, it's
possible.

3. Aggregration
Aggregration is a process when relation between two entities is treated as a single entity.

In the diagram above, the relationship between Center and Course together, is acting as an Entity, which
is in relationship with another entity Visitor. Now in real world, if a Visitor or a Student visits a Coaching
Center, he/she will never enquire about the center only or just about the course, rather he/she will ask
enquire about both.

14
4. Inheritance
 Usually, entity-sets inherit from one superclass.
 Entity-sets form a hierarchy.
 Attributes of higher-level entity-sets are inherited by lower-level entity-sets.
 Relationships involving higher-level entity-sets are also inherited by lower-level entity-sets
 Can also inherit from multiple superclasses.

Discuss RDBMS.

 RDBMS stands for Relational DataBase Management Systems.

 It is basically a program that allows us to create, delete, and update a relational database.
 Relational Database is a database system that stores and retrieves data in a tabular format
organized in the form of rows and columns.
 It is a smaller subset of DBMS which was designed by E.F Codd in the 1970s. The major DBMS
like SQL, My-SQL, ORACLE are all based on the principles of relational DBMS
 Relational DBMS owes its foundation to the fact that the values of each table are related to others.
It has the capability to handle larger magnitudes of data and simulate queries easily.
 Relational Database Management Systems maintains data integrity by simulating the following
features:
Entity Integrity: No two records of the database table can be completely duplicate.
 Referential Integrity: Only the rows of those tables can be deleted which are not used by other
tables. Otherwise, it may lead to data inconsistency.
 User-defined Integrity: Rules defined by the users based on confidentiality and access.
 Domain integrity: The columns of the database tables are enclosed within some structured limits,
based on default values, type of data or ranges.

Characteristics of RDBMS
 Data must be stored in tabular form in DB file, that is, it should be organized in the form of rows and
columns.
 Each row of table is called record/tuple . Collection of such records is known as the cardinality of the
table
 Each column of the table is called an attribute/field. Collection of such columns is called the arity of
the table.
 No two records of the DB table can be same. Data duplicity is therefore avoided by using a candidate
key. Candidate Key is a minimum set of attributes required to identify each record uniquely.
 Tables are related to each other with the help for foreign keys.

15
 Database tables also allow NULL values, that is if the values of any of the element of the table are not
filled or are missing, it becomes a NULL value, which is not equivalent to zero. (NOTE: Primary key
cannot have a NULL value).

Example:
The following table STUDENT consists of three columns Roll Number, Name, Section and four records of
students 1, 2, 3 and 4 respectively. The records can’t be completely same, the Roll Number acts as a
candidate key which separates records.

Roll number Name Section

1 Ishita A
2 Yash B
3 Ishita A
4 Mallika C

Advantages
 Easy to manage: Each table can be independently manipulated without affecting others.
 Security: It is more secure consisting of multiple levels of security. Access of data shared
can be limited.
 Flexible: Updating of data can be done at a single point without making amendments at
multiple files. Databases can easily be extended to incorporate more records, thus
providing greater scalability. Also, facilitates easy application of SQL queries.
 Users: RDBMS supports client-side architecture storing multiple users together.
 Facilitates storage and retrieval of large amount of data.
 Easy Data Handling:
 Data fetching is faster because of relational architecture.
 Data redundancy or duplicity is avoided due to keys, indexes, and normalization
principles.
 Data consistency is ensured because RDBMS is based on ACID properties for
data transactions(Atomicity Consistency Isolation Durability).
 Fault Tolerance: Replication of databases provides simultaneous access and helps the
system recover in case of disasters, such as power failures or sudden shutdowns

16
Disadvantages
 High Cost and Extensive Hardware and Software Support: Huge costs and setups are
required to make these systems functional.
 Scalability: In case of addition of more data, servers along with additional power, and
memory are required.
 Complexity: Voluminous data creates complexity in understanding of relations and may
lower down the performance.
 Structured Limits: The fields or columns of a relational database system is enclosed within
various limits, which may lead to loss of data

Discuss about RELATIONAL MODEL CONCEPTS

Relational Model represents how data is stored in Relational Databases. A relational

database stores data in the form of relations (tables). Consider a relation STUDENT with
attributes ROLL_NO, NAME, ADDRESS, PHONE and AGE shown in Table 1.

STUDENT

ROLL_NO NAME ADDRESS PHONE AGE

1 RAM DELHI 9455123451 18

2 RAMESH GURGAON 9652431543 18

3 SUJIT ROHTAK 9156253131 20

4 SURESH DELHI 9256253131 18

17
 Attribute: Attributes are the properties that define a relation.
e.g.; ROLL_NO, NAME

 Relation Schema: A relation schema represents name of the relation with its
attributes. e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE and AGE) is
relation schema for STUDENT. If a schema has more than 1 relation, it is called
Relational Schema.

 Tuple: Each row in the relation is known as tuple. The above relation contains 4
tuples, one of which is shown as:

1 RAM DELHI 9455123451 18

 Relation Instance: The set of tuples of a relation at a particular instance of time is

called as relation instance. Table 1 shows the relation instance of STUDENT at a
particular time. It can change whenever there is insertion, deletion or updation in the
database.

 Degree: The number of attributes in the relation is known as degree of the relation.
The STUDENT relation defined above has degree 5.

 Cardinality: The number of tuples in a relation is known as cardinality.

The STUDENT relation defined above has cardinality 4.

 Column: Column represents the set of values for a particular attribute. The
column ROLL_NO is extracted from relation STUDENT.

ROLL_NO

18
 NULL Values: The value which is not known or unavailable is called NULL value. It
is represented by blank space. e.g.; PHONE of STUDENT having ROLL_NO 4 is
NULL.
Constraints in Relational Model

While designing Relational Model, we define some conditions which must hold for data
present in database are called Constraints. These constraints are checked before
performing any operation (insertion, deletion and updation) in database. If there is a
violation in any of constrains, operation will fail.

Domain Constraints: These are attribute level constraints. An attribute can only take
values which lie inside the domain range. e.g,; If a constrains AGE>0 is applied on
STUDENT relation, inserting negative value of AGE will result in failure.

Key Integrity: Every relation in the database should have atleast one set of attributes
which defines a tuple uniquely. Those set of attributes is called key. e.g.; ROLL_NO in
STUDENT is a key. No two students can have same roll number. So a key has two
properties:

 It should be unique for all tuples.

 It can’t have NULL values.

Referential Integrity: When one attribute of a relation can only take values from other
attribute of same relation or any other relation, it is called referential integrity. Let us
suppose we have 2 relations

19
STUDENT

ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE

1 RAM DELHI 9455123451 18 CS

2 RAMESH GURGAON 9652431543 18 CS

3 SUJIT ROHTAK 9156253131 20 ECE

4 SURESH DELHI 18 IT

BRANCH

BRANCH_CODE BRANCH_NAME

CS COMPUTER SCIENCE

IT INFORMATION TECHNOLOGY

ECE ELECTRONICS AND COMMUNICATION ENGINEERING

CV CIVIL ENGINEERING

20
BRANCH_CODE of STUDENT can only take the values which are present in
BRANCH_CODE of BRANCH which is called referential integrity constraint. The
relation which is referencing to other relation is called REFERENCING RELATION
(STUDENT in this case) and the relation to which other relations refer is called
REFERENCED RELATION (BRANCH in this case).

DISCUSS INTEGRITY RULES

Relational database integrity rules are very important to good database design.

Many (but by no means all) RDBMS enforce integrity rules automatically.

Those rules are:

1- ENTITY INTEGRITY

2- REFERENTIAL INTEGRITY

1- ENTITY INTEGRITY

All primary key entries are unique,

Primary Key cannot have NULL value

Each row will have a unique identity,

Foreign key values can properly reference primary key values,

<Student>

Student_ID Student_Awards Student_Awards

Above <Student> TABLE, you can see primary key is Student_ID.

an STUDENT_ID cannot be null in an STUDENT table and No duplication is Student_ID.

21
Referential Integrity

A value that appears in one relation for a given set of attributes also appears for a certain
set of attributes in another relation. This condition is called referential integrity.

Example for referential integrity:

Table A
DeptID DeptName DeptManager
F-1001 Financial Nathan
S-2012 Software Martin
H-0001 HR Jason

Table B
EmpNo DeptID EmpName
1001 F-1001 Tommy
1002 S-2012 Will
1003 H-0001 Jonathan

In Table A, Primary Key is DeptID and in Table B DeptID is the Foreign Key to refer the
Employee Department.

The definition of the course table has a declaration “foreign key (dept name) references
department”.

22