UnIt II

Classification of Data Model

Data Models provide us with a transparent picture of data which helps us in creating an actual
database.

Types of Relational Models

1. Conceptual Data Model
2. Representational Data Model
3. Physical Data Model
Note refer unit I Notes

Data Modeling using ER Model

It is the most used graphical representation of the conceptual design of a database. The Entity
Relationship Model is a model for identifying entities (like student, car or company) to be
represented in the database and representation of how those entities are related.

Why Use ER Diagrams In DBMS?

 ER diagrams represent the E-R model in a database, making them easy to convert into
relations (tables).
 ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.
 ER diagrams require no technical knowledge of the underlying DBMS used.
 It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model

Rectangles: Rectangles represent Entities in the ER Model.
Ellipses: Ellipses represent Attributes in the ER Model.
Diamond: Diamonds represent Relationships among Entities.
Lines: Lines represent attributes to entities and entity sets with other relationship types.
Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
Double Rectangle: Double Rectangle represents a Weak Entity.

Components of ER Diagram
What is Entity?
An Entity may be an object with a physical existence – a particular person, car, house, or
employee – or it may be an object with a conceptual existence – a company, a job, or a
university course.
What is Entity Set?
An Entity is an object of Entity Type and a set of all entities is called an entity set. For
Example, E1 is an entity having Entity Type Student and the set of all students is called Entity
Set. In ER diagram, Entity Type is represented as:

Entity Set

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram
because entity is row and column in the relation and ER Diagram is graphical representation of
data.
Types of Entity
There are two types of entity:
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on
other Entity in the Schema. It has a primary key, that helps in identifying it uniquely, and it is
represented by a rectangle. These are called Strong Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But
some entity type exists for which key attributes can’t be defined. These are called Weak Entity
types .
For Example, A company may store the information of dependents (Parents, Children,
Spouse) of an Employee. But the dependents can’t exist without the employee. So Dependent
will be a Weak Entity Type and Employee will be Identifying Entity type for Dependent,
which means it is Strong Entity Type .
A weak entity type is represented by a Double Rectangle. The participation of weak entity
types is always total. The relationship between the weak entity type and its identifying strong
entity type is called identifying relationship and it is represented by a double diamond.

Strong Entity and Weak Entity

What is Attributes?
Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB,
Age, Address, and Mobile_No are the attributes that define entity type Student. In ER diagram,
the attribute is represented by an oval.

Attribute

Types of Attributes
1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute.
For example, Roll_No will be unique for each student. In ER diagram, the key attribute is
represented by an oval with underlying lines.
 Key Attribute

2. Composite Attribute
An attribute composed of many other attributes is called a composite attribute. For example,
the Address attribute of the student Entity type consists of Street, City, State, and Country. In
ER diagram, the composite attribute is represented by an oval comprising of ovals.

Composite Attribute

3. Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example, Phone_No (can
be more than one for a given student). In ER diagram, a multivalued attribute is represented by
a double oval.
 Multivalued Attribute

4. Derived Attribute
An attribute that can be derived from other attributes of the entity type is known as a derived
attribute. e.g.; Age (can be derived from DOB). In ER diagram, the derived attribute is
represented by a dashed oval.

Derived Attribute

The Complete Entity Type Student with its Attributes can be represented as:
 Entity and Attributes

Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example, ‘Enrolled
in’ is a relationship type that exists between entity type Student and Course

Entity-Relationship Set

A set of relationships of the same type is known as a relationship set. The following
relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.

Relationship Set
Degree of a Relationship Set
The number of different entity sets participating in a relationship set is called the degree of a
relationship set.
1. Unary Relationship: When there is only ONE entity set participating in a relation, the
relationship is called a unary relationship. For example, one person is married to only one
person.

Unary Relationship

2. Binary Relationship: When there are TWO entities set participating in a relationship, the
relationship is called a binary relationship. For example, a Student is enrolled in a Course.

Binary Relationship

3. Ternary Relationship: When there are three entity sets participating in a relationship, the
relationship is called a ternary relationship.
4. N-ary Relationship: When there are n entities set participating in a relationship, the
relationship is called an n-ary relationship.

What is Cardinality?
The number of times an entity of an entity set participates in a relationship set is known
as cardinality . Cardinality can be of different types:
1. One-to-One: When each entity in each entity set can take part only once in the relationship,
the cardinality is one-to-one. Let us assume that a male can marry one female and a female can
marry one male.

one to one cardinality

Using Sets, it can be represented as:

Set Representation of One-to-One

2. One-to-Many: In one-to-many mapping as well where each entity can be related to more
than one entity and the total number of tables that can be used in this is 2. Let us assume that
one surgeon department can accommodate many doctors.

one to many cardinality

Using sets, one-to-many cardinality can be represented as:

Set Representation of One-to-Many

3. Many-to-One: When entities in one entity set can take part only once in the relationship set
and entities in other entity sets can take part more than once in the relationship set, cardinality
is many to one. Let us assume that a student can take only one course but one course can be
taken by many students.
 many to one cardinality

Using Sets, it can be represented as:

Set Representation of Many-to-One

In this case, each student is taking only 1 course but 1 course has been taken by many students.

4. Many-to-Many: When entities in all entity sets can take part more than once in the
relationship cardinality is many to many.
.
 many to many cardinality

Using Sets, it can be represented as:

 Many-to-Many Set Representation

In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3, and
S4. So it is many-to-many relationships.

Enhanced Relational Model

Enhanced ERDs are high-level models that represent the requirements and complexities of
complex databases.

EER includes the following concepts.

 Subclasses and Superclasses
 Specialization and Generalization
 Category or Union type
 Attribute and relationship inheritance

Superclass and Subclass

A superclass is a high-level entity that can be further segmented into subclasses or subsets. It
is also referred to as a Parent class. A subclass can be referred to as a child or derived class.
Example: Science is a Super class which has subclasses like Physics, Chemistry, Biology.

Generalization and Specialization

Specialized classes are often called subclass while a generalized class is called a superclass

Example:
This example instance of “sub-class” relationships. Here we have four sets of employees:
Secretary, Technician, and Engineer. The employee is a super-class of the rest three sets of
individual sub-class is a subset of Employee set.
Union
Set of Library Members is UNION of Faculty, Student, and Staff. A union relationship
indicates either type; for example, a library member is either Faculty or Staff or Student.
Attribute Inheritance:

EER model allows attributes to be inherited from a superclass to its subclasses. This means
that attributes defined in the superclass are automatically inherited by all its subclasses

Functional Dependencies

A functional dependency occurs when one attribute uniquely determines another attribute
within a relation If attribute A functionally determines attribute B we write this as the A→B.

Types of Functional Dependencies in DBMS

1. Trivial functional dependency
2. Non-Trivial functional dependency
3. Multivalued functional dependency
4. Transitive functional dependency
1. Trivial Functional Dependency
In Trivial Functional Dependency, a dependent is always a subset of the determinant. i.e. If X
→ Y and Y is the subset of X, then it is called trivial functional dependency.
Symbolically: A→B is trivial functional dependency if B is a subset of A.
The following dependencies are also trivial: A→A & B→B
Example 1 :
 ABC -> AB
 ABC -> A
 ABC -> ABC
Example 2:
roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, {roll_no, name} → name is a trivial functional dependency, since the dependent name is
a subset of determinant set {roll_no, name}. Similarly, roll_no → roll_no is also an example of
trivial functional dependency.
2. Non-trivial Functional Dependency
In Non-trivial functional dependency, the dependent is strictly not a subset of the
determinant. i.e. If X → Y and Y is not a subset of X, then it is called Non-trivial functional
dependency.
Example 1 :
 Id -> Name
 Name -> DOB
Example 2:
roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, roll_no → name is a non-trivial functional dependency, since the dependent name is not
a subset of determinant roll_no. Similarly, {roll_no, name} → age is also a non-trivial
functional dependency, since age is not a subset of {roll_no, name}
3. Semi Non Trivial Functional Dependencies
A semi non-trivial functional dependency occurs when part of the dependent attribute (right-
hand side) is included in the determinant (left-hand side), but not all of it. This is a middle
ground between trivial and non-trivial functional dependencies. X -> Y is called semi non-
trivial when X intersect Y is not NULL.
Example:
Consider the following table:
Student_ID Course_ID Course_Name

101 CSE101 Computer Science

102 CSE102 Data Structures

103 CSE101 Computer Science

Functional Dependency:
{StudentID,CourseID}→CourseID
This is semi non-trivial because:
 Part of the dependent attribute (Course_ID) is already included in the determinant
({Student_ID, Course_ID}).
 However, the dependency is not completely trivial because {StudentID}→CourseID is not
implied directly.
4. Multivalued Functional Dependency
In Multivalued functional dependency, entities of the dependent set are not dependent on each
other. i.e. If a → {b, c} and there exists no functional dependency between b and c, then it is
called a multivalued functional dependency.
Example:
bike_model manuf_year color

tu1001 2007 Black

tu1001 2007 Red

tu2012 2008 Black

tu2012 2008 Red

tu2222 2009 Black

tu2222 2009 Red

In this table:
 X: bike_model
 Y: color
 Z: manuf_year
For each bike model (bike_model):
1. There is a group of colors (color) and a group of manufacturing years (manuf_year).
2. The colors do not depend on the manufacturing year, and the manufacturing year does not
depend on the colors. They are independent.
3. The sets of color and manuf_year are linked only to bike_model.
That’s what makes it a multivalued dependency.
In this case these two columns are said to be multivalued dependent on bike_model. These
dependencies can be represented like this:
.
5. Transitive Functional Dependency
In transitive functional dependency, dependent is indirectly dependent on determinant. i.e. If a
→ b & b → c, then according to axiom of transitivity, a → c. This is a transitive functional
dependency.
Example:
enrol_no name dept building_no

42 abc CO 4

43 pqr EC 2

44 xyz IT 1

45 abc EC 2

Here, enrol_no → dept and dept → building_no. Hence, according to the axiom of transitivity,
enrol_no → building_no is a valid functional dependency. This is an indirect functional
dependency, hence called Transitive functional dependency.

6. Fully Functional Dependency

In full functional dependency an attribute or a set of attributes uniquely determines another
attribute or set of attributes. If a relation R has attributes X, Y, Z with the dependencies X->Y
and X->Z which states that those dependencies are fully functional.

7. Partial Functional Dependency

In partial functional dependency a non key attribute depends on a part of the composite key,
rather than the whole key. If a relation R has attributes X, Y, Z where X and Y are the
composite key and Z is non key attribute. Then X->Z is a partial functional dependency in
RBDMS.

Relational Data Model

The relational model represents how data is stored in Relational Databases. A relational
database consists of a collection of tables each of which is assigned a unique name. Consider a
relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE,
and AGE shown in the table.
 Attribute: Attributes are the properties that define an entity. e.g. ROLL_NO, NAME,
ADDRESS.
 Relation Schema: A relation schema defines the structure of the relation and represents the
name of the relation with its attributes. e.g. STUDENT (ROLL_NO, NAME, ADDRESS,
PHONE, and AGE) is the 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 a tuple.
 Relation Instance: The set of tuples of a relation at a particular instance of time is called
a relation instance. It can change whenever there is an insertion, deletion or update in the
database.
 Degree: The number of attributes in the relation is known as the 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: The column represents the set of values for a particular attribute. The column
ROLL_NO is extracted from the relation STUDENT.
 NULL Values: The value which is not known or unavailable is called a NULL value.
Relational Constraints
These are the restrictions or sets of rules imposed on the database contents. It validates the
quality of the database.
4 types
 Domain constraints
 Key constraints or Uniqueness Constraints
 Entity Integrity constraints
 Referential integrity constraints

Domain Constraints
 Every domain must contain atomic values(smallest indivisible units) which means
composite and multi-valued attributes are not allowed.
Example:
EID Name Phone

01 Bikash Dutta 123456789

234456678

Explanation: In the above relation, Name is a composite attribute and Phone is a multi-values
attribute, so it is violating domain constraint.
2. Key Constraints or Uniqueness Constraints
 These are called uniqueness constraints since it ensures that every tuple in the relation
should be unique.
Example:
EID Name Phone

01 Bikash 6000000009

02 Paul 9000090009

01 Tuhin 9234567892

Explanation: In the above table, EID is the primary key, and the first and the last tuple have
the same value in EID ie 01, so it is violating the key constraint.
3. Entity Integrity Constraints
 Entity Integrity constraints say that no primary key can take a NULL value, since using
the primary key we identify each tuple uniquely in a relation.
Example:
EID Name Phone

01 Bikash 9000900099

02 Paul 600000009

NULL Sony 9234567892

Explanation: In the above relation, EID is made the primary key, and the primary key can’t
take NULL values but in the third tuple, the primary key is null, so it is violating Entity
Integrity constraints.
4. Referential Integrity Constraints
 The Referential integrity constraint is specified between two relations or tables and used to
maintain the consistency among the tuples in two relations
 Example:

EID Name DNO

01 Divine 12

02 Dino 22

04 Vivian 14

DNO Place

12 Jaipur

13 Mumbai

14 Delhi

 Explanation: In the above tables, the DNO of Table 1 is the foreign key, and DNO in
Table 2 is the primary key. DNO = 22 in the foreign key of Table 1 is not allowed
because DNO = 22 is not defined in the primary key of table 2. Therefore, Referential
integrity constraints are violated here.
Normalization
Normalization is a systematic approach to organize data in a database to eliminate redundancy,
avoid anomalies and ensure data consistency.
 Types of Normal Forms
First Normal Form (1NF): This is the most basic level of normalization. In 1NF, each
table cell should contain only a single value, and each column should have a unique name.
The first normal form helps to eliminate duplicate data and simplify queries.
Second Normal Form (2NF): 2NF eliminates redundant data by requiring that each non-
key attribute be dependent on the primary key. This means that each column should be
directly related to the primary key, and not to other columns.
Third Normal Form (3NF): 3NF builds on 2NF by requiring that all non-key attributes
are independent of each other. This means that each column should be directly related to
the primary key, and not to any other columns in the same table.
Boyce-Codd Normal Form (BCNF): BCNF is a stricter form of 3NF that ensures that
each determinant in a table is a candidate key. In other words, BCNF ensures that each
non-key attribute is dependent only on the candidate key.
Fourth Normal Form (4NF): 4NF is a further refinement of BCNF that ensures that a
table does not contain any multi-valued dependencies.
Fifth Normal Form (5NF): 5NF is the highest level of normalization and involves
decomposing a table into smaller tables to remove data redundancy and improve data
integrity.

The ODBMS which is an abbreviation for object-oriented database management system is

the data model in which data is stored in form of objects, which are instances of classes.

1. Object Structure:
The structure of an object refers to the properties that an object is made up of.
These properties of an object are referred to as an attribute. Thus, an object is a
real-world entity with certain attributes that makes up the object structure.
2. Object Classes:
An object which is a real-world entity is an instance of a class. Hence first we
need to define a class and then the objects are made which differ in the values
they store but share the same class definition
3. An OODBMS also supports inheritance in an extensive manner as in a database
there may be many classes with similar methods, variables and messages
4. The concept of encapsulation that is the data or information hiding is also
supported by an object-oriented data model