SRFGC Madhugiri III Bcom(CS) DBMS

Chapter 2: Data Models

Data model Definition:

Data model is a collection of concepts that can be used to describe the structure of a database

Classification of Data models

 High-level or conceptual data models : provide concepts that are close to the way many users
perceive Data. It uses the concepts such as
Entity: Represents a real word object, such as student, employee, Book.
Attribute: Represents some properties of entity, such as student name, id, marks.
Relationship: Represents an association between two or more entities such as relationship between
Book and Author.

 low-level or physical data models : provide concepts that describe the details of how data is stored
on the computer storage media.

 representational (or implementation) or record based data model : Representational data

 models represent data by using record structures.

2) Object based data model

In the object-based data model, the database is organized in real-world objects of several types.
A number of fields or attributes are defined in each object. The two most popular object -based
data models are:

(i) Object oriented model

The object-oriented model is based on a collection of objects. An object contains values stored
in instances variable within the object. An object contains bodies of code that operate on the
object.

Advantages of object oriented data model

 It represents relationships explicitly supporting both navigated and associative access to

information.
 Object-oriented database systems are not suited for all applications.
 It is difficult to maintain when organizational information changes.

(ii) ER (Entity Relational model)

Pavan kumar R,(SRFGC Madhugiri) Page 1

 SRFGC Madhugiri III Bcom(CS) DBMS

The entity relational data model based on the perception of the real world that consist of a
collection of basics objects and relationships between them. It is an object-based logical model.
It is also high-level data model.

Representation/ Record Based model

There are 3 types of record based models. They are

1. Relational database model

2. Hierarchical database model
3. Network database model

Relational database model

 This model was developed by E. F CODD in 1960’s.

 In this model all the data is represented (or) organized in the form of two-dimensional format
that is table.
 Table is a combination of unnamed rows and Named columns (or) is a collection of records.
 Rows are also called as tuples or records.
 Columns are also called as fields or attributes.

ADVANTAGES:

 Compared to network and hierarchical models creation of relation will be easy.

 In this model changes in the structure do not affect the data access.
 It is a very powerful and flexible model for every user.

DISADVANTAGES:

 In this we hide the implementation complexity and data storage details from the users.
 Using this model we cannot implement reference concept.
 It is poorly designed database system means every user can implement the model.

Pavan kumar R,(SRFGC Madhugiri) Page 2

 SRFGC Madhugiri III Bcom(CS) DBMS

Hierarchical database model

 In this model data will be represent in the form of inverted tree like structure.
 This structure allows representing information using parent-child relationship.
 Each parent can have many children. But each child has only one parent. Hence, this relationship
is called as one to many relationships

This model is used to describe the data and maintain the logical and view level.

At the top of the hierarchy, there is one entity, which is called the root.

ADVANTAGES:

 In this model DBMS provides lot of security.

 There is always link between the parent and child.
 Proper ordering of a tree result is easier and faster.

DISADVANTAGES:

 Although it is a simple to design but complex to implement.

 If you make any changes in the database structure then you must make changes in the entire
application in the DBMS.
 This model suffers from the insert, delete and update anomalies .

Network database model

Pavan kumar R,(SRFGC Madhugiri) Page 3

 SRFGC Madhugiri III Bcom(CS) DBMS

 It is a flexible of representing objects and their relationships.

 In this data can be representing in the form of relationship through the pointers.
 This model allows each record have multiple parent and child records, hence this is referred as
many to many relationship.
 It is as same as the hierarchical model but need not necessary to use a downward tree like
structure to represent the data.

In the network model, the entities are organized in a graph, in which some entities can be accessed
through several paths as shown in figure below.

ADVANTAGES:

 Data must be tree like structure because of we are using the pointers.
 Data manipulation can be done easily.
 It is possible to represent many to many relationship

DISADVANTAGES:

 It is very complex to implement the pointer concept.

 It is very difficult to make the structural changes in the database.

Basic concept of E-R Model

A logical representation of the data for an organization or for a business area is called E-R Model. It
is also called has Entity-Relationship Model.
Entity-Relationship Diagram

A graphical representation of entity-relationship model.Also called E-R diagram or just ERD.

ER Model: Basic Concepts

Entity relationship model defines the conceptual view of database. It works around real world entity and
Pavan kumar R,(SRFGC Madhugiri) Page 4
 SRFGC Madhugiri III Bcom(CS) DBMS

association among them. At view level, ER model is considered well for designing databases.
Entity

An entity is an object that exists and which is distinguishable from other objects. An entity can be a
person, a place, an object, an event, or a concept about which an organization wishes to maintain data.
For example, in a school database, student, teachers, class and course offered can be considered as
entities. All entities have some attributes or properties that give them their identity.
An entity set is a collection of similar types of entities. Entity set may contain entities with attribute
sharing similar values. For example, Students set may contain all the student of a school; likewise
Teachers set may contain all the teachers of school from all faculties. Entities sets need not to be
disjoint.

ATTRIBUTE
An attribute is a property that describes an entity. All attributes have values. For example, a
student entity may have name, class, age as attributes. There exists a domain or range of values
that can be assigned to attributes. For example, a student's name cannot be a numeric value. It
has to be alphabetic. A student's age cannot be negative, etc.
Types of attributes:
Simple attribute:

Simple attributes are atomic values, which cannot be divided further. For example, student's
phone-number is an atomic value of 10 digits.
Composite attribute:

Composite attributes are made of more than one simple attribute. For example, a
student's name may have Firstname and Lastname.
Derived attribute:

Derived attributes are attributes, which do not exist physical in the database, but there values
are derived from other attributes presented in the database.
For another example, Age can be derived from DOB.
Stored attribute:

An attribute whose value cannot be derived from the values of other attributes is
called a stored attribute.
For example, DOB
Single-valued attribute:
Pavan kumar R,(SRFGC Madhugiri) Page 5
 SRFGC Madhugiri III Bcom(CS) DBMS

Single valued attributes contain on single value. For

example: SocialSecurityNumber.
Multi-value attribute:
Multi-value attribute may contain more than one values.
For example, a person can have more than one phone numbers, EmailId etc.

Entity-set and Keys

Key is an attribute or collection of attributes that uniquely identifies an entity among entity set.
For example, RegNo of a student makes her/him identifiable among students.

Super Key: Set of attributes (one or more) that collectively identifies anentity in an entity
set.
Candidate Key: Minimal super key is called candidate key that is, superskeys for which no
proper subset are a superkey. An entity set may have more than one candidate key.

Primary Key: This is one of the candidate key chosen by the databasedesigner to
uniquely identify the entity set.

Relationship

The association among entities is called relationship. For example, employee entity has relation
works_at with department.

Another example is for student who enrolls in some course. Here, Works_at and Enrolls are called
relationship.
Keys

Superkey: an attribute or set of attributes that uniquely identifies an entity. Composite key: a key
requiring more than one attribute.
Candidate key: a superkey such that no proper subset of its attributes is also asuperkey (minimal
superkey – has no unnecessary attributes)

Primary key:the candidate key chosen to be used for identifying entities andaccessing records.
Unless otherwise noted "key" means "primary key" Alternate key:a candidate key not used for
primary key

Secondary key:attribute or set of attributes commonly used for accessing records,but not necessarily
unique
FOREIGN KEY

Pavan kumar R,(SRFGC Madhugiri) Page 6

 SRFGC Madhugiri III Bcom(CS) DBMS

term used in relational databases (but not in the E-R model) for anattribute that is the primary key
of another table and is used to establish a relationship with that table where it appears as an
attribute also.
So a foreign key value occurs in the table and again in the other table.

NOTATIONS/Symbols used in E-R diagrams

Entity: an entity can be any object, place person or class.

In E-R diagram entity is represented using rectangles.

For example Student is an entity.

Strong Entities are independently from other entity types.They always

possess one or more attributes that

Pavan kumar R,(SRFGC Madhugiri) Page 7

 SRFGC Madhugiri III Bcom(CS) DBMS

uniquely(primary key) distinguish each occurrence of the entity. For example

Student is an entity

Weak Entities depend on another entity.

Weak entity doesn’t have key attribute of their own.
Double rectangle represents weak entity.

Relationship
A relationship describes relations between entities.
Relationship is represented using diamonds.
Attributes:

An attributes describes a property or characteristic of an entity. An attribute is

represented using eclipse.
For example regno, name, course can be the attribute of student entity.

Key Attribute
Key attribute represents the main characteristic of an entity.

It is used to represent Primary key. Ellipse with underlying lines represent key
attribute.
Composite Attribute

An attributes can be sub divided. These attributes are known as composite attribute.

Multivalued Attribute
Multivalued attributes are those that are capable of
taking on more than one value. It is represented by double Ellipse.

Derived Attribute
Derived attributes are attributes whose value can be
calculated from related attribute values. They are represented by dotted ellipse.

Pavan kumar R,(SRFGC Madhugiri) Page 8

 SRFGC Madhugiri III Bcom(CS) DBMS

Example of E-R diagram

Mapping cardinalities (or) types of relationships between entity sets

Express the number of entities to which another entity can be associated via a relationship set.
On the other hand, it is the cardinality of relationship that defines the number of instances of one
entity as it relates to the number of instances of the other entity.
Based on the different combinations between two entities we can have either
-to- One
- to- Many
- to- One
-to- Many

Pavan kumar R,(SRFGC Madhugiri) Page 9

 SRFGC Madhugiri III Bcom(CS) DBMS

One to One Relationship:

One instance of one entity can be associates with one instance of another entity.
Ex: one man can marry with one woman.
This can be represented in the form of both set and E-R notation

One to Many Relationships:

One instance of one entity can be associates with many instances of another entity.
Ex: one teacher can teach many students at a time.
This can be represented in the form of both set and E-R notation.

Many to One Relationship:

Many instances of one entity can be associates with one instance of another entity.
Ex: many students can learn one course at a time.
This can be represented in the form of both set and E-R notation.

STUDENTS ENROLL COURSE

S
Pavan kumar R,(SRFGC Madhugiri) Page 10
 SRFGC Madhugiri III Bcom(CS) DBMS

Many to Many Relationships:

Many instances of one entity can be associates many instances of another entity.
Ex: many teachers can teach many students at a time.

Degree of relationship
It is process of counting number of participating entities in an E-R diagram.
There are 3 types of degree. They are

-Array relationship degree.

Binary relationship degree:

If there are two entities involved in relationship then it is referred to as binary relationship.
This type of degree is most common type of degree used in E-R diagram.

Pavan kumar R,(SRFGC Madhugiri) Page 11

 SRFGC Madhugiri III Bcom(CS) DBMS

Ternary relationship degree:

If there are three entities involved then it is called as ternary relationship.

N-Array relationship degree:

If there are more than 3 entities participated in E- R diagram is called as N-array relationship degree

Data Abstraction
The process of hiding the irrelevant data or things from the users. It reduces the complexity and increases
efficiency.

There are 3 main aspects of abstraction. They are

Pavan kumar R,(SRFGC Madhugiri) Page 12

 SRFGC Madhugiri III Bcom(CS) DBMS

Example of Generalization.
(a) Two entity types CAR and TRUCK.
(b) Generalizing CAR and TRUCK into VEHICLE.

Pavan kumar R,(SRFGC Madhugiri) Page 13

 SRFGC Madhugiri III Bcom(CS) DBMS

Pavan kumar R,(SRFGC Madhugiri) Page 14

 SRFGC Madhugiri III Bcom(CS) DBMS

In the above figure “offer” is a relationship between center and course entities and acts as an entity for
“enquires” relationship. Hence offer is called as associative entity because it acts as both relationship and
entity.
CODD’S RULE

Codd's 12 rules are a set of thirteen rules (numbered zero to twelve) proposed by Edgar F. Codd, a pioneer of
the relational model for databases, designed to define what is required from a database management system in
order for it to be considered relational, i.e., a relational database management system RDBMS

• Rule 0: The system must qualify as relational, as a database, and as a management system. For a system to
qualify as a relational database management system (RDBMS), that system must use its
relationalfacilities (exclusively) to manage the database.

• Rule 1: The information rule:

All information in the database is to be represented in one and only one way, namely by values in column
positions within rows of tables.

Rule 2: The guaranteed access rule :

All data must be accessible. This rule is essentially a restatement of the fundamental requirement for
primary keys. It says that every individual scalar value in the database must be logically addressable by
specifying the name of the containing table, the name of the containing column and the primary key value of
the containing row.

• Rule 3: Systematic treatment of null values :

Pavan kumar R,(SRFGC Madhugiri) Page 15

 SRFGC Madhugiri III Bcom(CS) DBMS

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of
"missing information and inapplicable information" that is systematic, distinct
from all regular values (for example, "distinct from zero or any other number", in the case of numeric values),
and independent of data type. It is also implied that such representations must be manipulated
by the DBMS in a systematic way.

• Rule 4: Active online catalog based on the relational model:

The system must support an online, inline, relational catalog that is accessible to authorized users by
means of their regular query language. That is, users must be able to access the database’s structure (catalog)
using the same query language that they use to access the database's data.

• Rule 5: The comprehensive data sublanguage rule :

The system must support at least one relational language that
• Has a linear syntax
• Can be used both interactively and within application programs,
• Supports data definition operations (including view definitions), data manipulation operations (update as well
as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and
rollback).

Rule 6: The view updating rule:

All views that are theoretically updatable must be updatable by the system.

• Rule 7: High-level insert, update, and delete:

The system must support set-at-a-time insert, update, and delete operators. This means that data can be
retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This
rule states that insert, update, and delete operations should be supported for any retrievable set rather than just
for a single row in a single table.

• Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a
change to an application based on the structure.

• Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application
based on the structure. Logical data independence is more difficult to achieve than physical data independence.

• Rule 10: Integrity independence:

Integrity constraints must be specified separately from application programs and stored in the catalog. It must
be possible to change such constraints as and when appropriate without unnecessarily affecting existing
applications.

• Rule 11: Distribution independence:

The distribution of portions of the database to various locations should be invisible to users of the database.
Existing applications should continue to operate successfully:
• when a distributed version of the DBMS is first introduced; and
• when existing distributed data are redistributed around the system.

• Rule 12: The nonsubversion rule :

If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the
system, for example, bypassing a relational security or integrity constraint.

Pavan kumar R,(SRFGC Madhugiri) Page 16

 SRFGC Madhugiri III Bcom(CS) DBMS

Pavan kumar R,(SRFGC Madhugiri) Page 17

 SRFGC Madhugiri III Bcom(CS) DBMS

Pavan kumar R,(SRFGC Madhugiri) Page 18

 SRFGC Madhugiri III Bcom(CS) DBMS

Pavan kumar R,(SRFGC Madhugiri) Page 19

 SRFGC Madhugiri III Bcom(CS) DBMS

Pavan kumar R,(SRFGC Madhugiri) Page 20

UCST 2018-19 CS&E

ER Diagram for Company Database

Physical Data Models

Physical data model represent the model where it describes how data are
stored in computer memory, how they are scattered and ordered in the memory,
and how they would be retrieved from memory. Basically physical data model
represents the data at data layer or internal layer. It represents each table, their
columns and specifications, constraints like primary key, foreign key etc. It
basically represents how each tables are built and related to each other in DB.

21
UCST 2018-19 CS&E

Above diagram shows how physical data model is designed. It is

represented as UML diagram along with table and its columns. Primary key is
represented at the top. The relationship between the tables is represented by
interconnected arrows from table to table. Above STUDENT table is related to
CLASS and SUBJECT is related to CLASS. The above diagram depicts CLASS as
the parent table and it has 2 child tables – STUDENT and SUBJECT.

In short we can say a physical data model has

 Tables and its specifications – table names and their columns. Columns are
represented along with their datatypes and size. In addition primary key of
each table is shown at the top of the column list.
 Foreign keys are used to represent the relationship between the tables.
Mapping between the tables are represented using arrows between them.
 Physical data model can have denormalized structure based on the user
requirement. The tables might not be in normalized forms.
Physical data model is dependent on the RDBMS i.e.; it varies based on the
RDBMS used. This means datatype notation varies depending on the RDBMS. For
example, we have different datatypes in SQL server and oracle server. In addition,
the representation of physical data model diagram may be different, though it
contains same information as described above – some may represent primary key
and foreign keys separately at the end of the column list. This data model depends
on the user / designer how he specifies the diagram and the RDBMS servers.
Below diagram shows different ways of representing a table.

22
UCST 2018-19 CS&E

Hence object based data model is based on the real requirement from the user,
whereas record based data model is based on the actual relationships and data in
DB. The Physical data model is based on the table structure in the DB.

23