DBMS Data Models

Data Model is the modelling of the data description, data semantics, and
consistency constraints of the data. It provides the conceptual tools for describing
the design of a database at each level of data abstraction. Therefore, there are
following four data models used for understanding the structure of the database.

Relational Data Model: This type of model designs the data in the form of rows
and columns within a table. Thus, a relational model uses tables for
representing data and in-between relationships. Tables are also called relations.
This model was initially described by Edgar F. Codd, in 1969. The relational
data model is the widely used model which is primarily used by commercial data
processing applications.

Entity-Relationship Data Model: An ER model is the logical representation of

data as objects and relationships among them. These objects are known as
entities, and relationship is an association among these entities. This model was
designed by Peter Chen and published in 1976 papers. It was widely used in
database designing. A set of attributes describe the entities. For example,
student_name, student_id describes the 'student' entity. A set of the same type of
entities is known as an 'Entity set', and the set of the same type of relationships is
known as 'relationship set'.

Object-based Data Model: An extension of the ER model with notions of

functions, encapsulation, and object identity, as well. This model supports a rich
type system that includes structured and collection types. Thus, in 1980s, various
database systems following the object-oriented approach were developed. Here,
the objects are nothing but the data carrying its properties.

1|Page
Semi-structured Data Model: This type of data model is different from the other
three data models (explained above). The semi-structured data model allows the
data specifications at places where the individual data items of the same type
may have different attributes sets. The Extensible Markup Language, also known
as XML, is widely used for representing the semi
structured data. Although XML was initially designed for including the markup
information to the text document, it gains importance because of its application in
the exchange of data.

RDBMS (Relational Database Management System)

• RDBMS stands for Relational Database Management System. All modern
DBMS like SQL, MS SQL Server, IBM DB2, ORACLE, My SQL, and
Microsoft Access are based on RDBMS.
• It’s also known as Relational Data Model. It is called Relational Database
Management System (RDBMS) because it is based on the relational model
introduced by E.F. Codd.

How it Works

• Data is represented in terms of tuples (rows) in RDBMS. • A relational

database is the most commonly used database. It contains several tables, and
each table has its primary key.
• Due to a collection of an organized set of tables, data can be accessed easily
in RDBMS.

Various Terminologies of RDBMS

2|Page
What is Table/Relation?
Everything in a relational database is stored in the form of relations. The RDBMS
database uses tables to store data. A table is a collection of related data entries
and contains rows and columns to store data. Each table represents some real-
world objects such as person, place, or event about which information is collected.
The organized collection of data into a relational table is known as the logical
view of the database.

Properties of a Relation

o Each relation has a unique name by which it is identified in the database. o

Relation does not contain duplicate tuples.
o The tuples of a relation have no specific order.
o All attributes in a relation are atomic, i.e., each cell of a relation contains
exactly one value.

A table is the simplest example of data stored in RDBMS.

Let's see the example of the student table.

ID Name AGE COURSE

1 Ajeet 24 B.Tech

2 aryan 20 C.A

3 Mahesh 21 BCA

4 Ratan 22 MCA

5 Vimal 26 BSC

What is a Row or Record?

A row of a table is also called a record or tuple. It contains the specific information
of each entry in the table. It is a horizontal entity in the table. For example, the
above table contains 5 records.

3|Page
Properties of a Row

o No two tuples are identical to each other in all their entries.

o All tuples of the relation have the same format and the same number of
entries.
o The order of the tuple is irrelevant. They are identified by their content, not
by their position.

Let's see one record/row in the table.

ID Name AGE COURSE

1 Ajeet 24 B.Tech

What is a Column/Attribute?
A column is a vertical entity in the table which contains all information associated
with a specific field in a table. For example, "name" is a column in the above table
which contains all information about a student's name.

Properties of an Attribute

o Every attribute of a relation must have a name.

o Null values are permitted for the attributes.
o Default values can be specified for an attribute automatically inserted if no
other value is specified for an attribute.
o Attributes that uniquely identify each tuple of a relation are the primary
key.
Name

Ajeet

Aryan

Mahesh

4|Page
 Ratan

Vimal

What is Data Item/Cells?

The smallest unit of data in the table is the individual data item. It is stored at
the intersection of tuples and attributes.

Properties of Data Items

o Data items are atomic.

o The data items for an attribute should be drawn from the same domain.

In the below example, the data item in the student table consists of Ajeet, 24 and
Btech, etc.
ID Name AGE COURSE

1 Ajeet 24 B.Tech

Degree
The total number of attributes that comprise a relation is known as the degree of
the table. For example, the student table has 4 attributes, and its degree is 4.
ID Name AGE COURSE

1 Ajeet 24 B.Tech

2 aryan 20 C.A

3 Mahesh 21 BCA

4 Ratan 22 MCA

5 Vimal 26 BSC

5|Page
Cardinality
The total number of tuples at any one time in a relation is known as the table's
cardinality. The relation whose cardinality is 0 is called an empty table.

For example, the student table has 5 rows, and its cardinality is 5.
ID Name AGE COURSE

1 Ajeet 24 B.Tech

2 aryan 20 C.A

3 Mahesh 21 BCA

4 Ratan 22 MCA

5 Vimal 26 BSC

Domain
The domain refers to the possible values each attribute can contain. It can be
specified using standard data types such as integers, floating numbers, etc. For
example, an attribute entitled Marital_Status may be limited to married or
unmarried values.

NULL Values

The NULL value of the table specifies that the field has been left blank during
record creation. It is different from the value filled with zero or a field that
contains space.

6|Page
Difference between DBMS and RDBMS
Although DBMS and RDBMS both are used to store information in physical
database but there are some remarkable differences between them.
No. DBMS RDBMS

1) DBMS applications store data as RDBMS applications store data in a

file. tabular form.

2) In DBMS, data is generally In RDBMS, the tables have an identifier

stored in either a hierarchical called primary key and the data values are
form or a navigational form. stored in the form of tables.

3) Normalization is not present in Normalization is present in RDBMS.

DBMS.

4) DBMS does not apply any RDBMS defines the integrity constraint
security with regards to data for the purpose of ACID (Atomocity,
manipulation. Consistency, Isolation and Durability)
property.

5) DBMS uses file system to store in RDBMS, data values are stored in the
data, so there will be no relation form of tables, so a relationship between
between the tables. these data values will be stored in the
form of a table as well.

6) DBMS has to provide some RDBMS system supports a tabular

uniform methods to access the structure of the data and a relationship
stored information. between them to access the stored
information.

7) DBMS does not support RDBMS supports distributed database.

distributed database.

7|Page
 8) DBMS is meant to be for small RDBMS is designed to handle large
organization and deal with small amount of data. It supports multiple
data. It supports single user. users.

9) Examples of DBMS are: file Example of RDBMS are: mysql,

systems, xml etc. postgre, sql server, oracle etc.

After observing the differences between DBMS and RDBMS, you can say that
RDBMS is an extension of DBMS. There are many software products in the
market today who are compatible for both DBMS and RDBMS. This means,
today, a RDBMS application is DBMS application and vice-versa.

Data Model Schema and Instance

• The data which is stored in the database at a particular moment of time is

called an instance of the database.
• The overall design of a database is called schema.

• A database schema is the skeleton structure of the database. It represents

the logical view of the entire database.
• A schema contains schema objects like table, foreign key, primary key,
views, columns, data types, stored procedure, etc.
• A database schema can be represented by using the visual diagram. That

diagram shows the database objects and relationship with each other. • A
database schema is designed by the database designers to help
programmers whose software will interact with the database. The process of
database creation is called data modelling.

8|Page
Types of Schemas

The schema is pictorially represented as the following Figure. The different types
of schemas are as follows:
Physical Schema: It is a database design at the physical level. It is hidden below the
logical schema and can be changed easily without affecting the application
programs.
Logical Schema: It is a database design at the logical level. Programmers
construct applications using logical schema.
External: It is schema at view level. It is the highest level of a schema which
defines the views for end users.

• Generally, the Database Management System (DBMS) assists one physical

schema, one logical schema and several sub or external schemas.
• Database schema refers to the format and layout of the database in which
the data will be stored.
• It is the one thing that remains the same throughout unless otherwise
modified.
• It defines the structure of what type of data and how it will be stored.

9|Page
 Data Independence

• Data independence can be explained using the three-schema architecture. •

Data independence refers characteristic of being able to modify the schema
at one level of the database system without altering the schema at the next
higher level.

There are two types of data independence. These are:

Logical Data Independence

• Logical data independence refers characteristic of being able to change the

conceptual schema without having to change the external schema. • Logical

data independence is used to separate the external level from the conceptual
view.
• If we do any changes in the conceptual view of the data, then the user view
of the data would not be affected.
• Logical data independence occurs at the user interface level.

Fig: Data Independence

10 | P a g e
Physical Data Independence

• Physical data independence can be defined as the capacity to change the

internal schema without having to change the conceptual schema. • If we do

any changes in the storage size of the database system server, then the
Conceptual structure of the database will not be affected. • Physical data
independence is used to separate conceptual levels from the internal levels.
• Physical data independence occurs at the logical interface level.

DBMS Keys

• Keys play an important role in the relational database.

• It is used to uniquely identify any record or row of data from the table. It
is also used to establish and identify relationships between tables.

For example, ID is used as a key in the Student table because it is unique for
each student. In the PERSON table, passport_number, license_number, SSN
are keys since they are unique for each person.

Types of DBMS Keys

11 | P a g e
Primary Key

• It is the first key 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.

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.

12 | P a g e
Super Key

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

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.

13 | P a g e
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.

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. • In other

words, the total number of the alternate keys is the total number of
candidate keys minus the primary key.
• The alternate key may or may not exist. If there is only one candidate key
in a relation, it does not have an alternate key.

For example, employee relation has two attributes, Employee_Id and PAN_No,
that act as candidate keys. In this relation, Employee_Id is chosen as the primary
key, so the other candidate key, PAN_No, acts as the Alternate key.
14 | P a g e
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.

For example, in employee relations, we assume that an employee may be assigned

multiple roles, and an employee may work on multiple projects simultaneously.
So, the primary key will be composed of all three attributes, namely Emp_ID,
Emp_role, and Proj_ID in combination. So these attributes act as a composite key
since the primary key comprises more than one attribute.

Artificial Key
The key created using arbitrarily assigned data are known as artificial keys.
These keys are created when a primary key is large and complex and has no
relationship with many other relations. The data values of the artificial keys are
usually numbered in a serial order.
15 | P a g e
For example, the primary key, which is composed of Emp_ID, Emp_role, and
Proj_ID, is large in employee relations. So, it would be better to add a new
virtual attribute to identify each tuple in the relation uniquely.

Relational Integrity Constraints

• Relational Integrity constraints in DBMS are referred to conditions which

must be present for a valid relation.
• Relational Integrity constraints are a set of rules. It is used to maintain the
quality of information.
• Integrity constraints ensure that the data insertion, updating, and other
processes have to be performed in such a way that data integrity is not
affected.
• Thus, integrity constraint is used to guard against accidental damage to the
database.

Types of Integrity Constraint

16 | P a g e
Domain Integrity Constraints

• Domain constraints can be defined as the definition of a valid set of values

for an attribute.
• The data type of domain includes string, character, integer, time, date,
currency, etc. The value of the attribute must be available in the
corresponding domain.

For Example

Entity Integrity Constraints

• The entity integrity constraint states that primary key value can't be null.

• This is because the primary key value is used to identify individual rows in
relation and if the primary key has a null value, then we can't identify
those rows.
• A table can contain a null value other than the primary key field.

For Example

17 | P a g e
Referential Integrity Constraints

• A referential integrity constraint is specified between two tables. • In the

Referential integrity constraints, if a foreign key in Table 1 refers to the
Primary Key of Table 2, then every value of the Foreign Key in Table 1
must be null or be available in Table 2.

For Example

Key Constraints
• Keys are the entity set that is used to identify an entity within its entity set
uniquely.
• An entity set can have multiple keys, but out of which one key will be the
primary key. A primary key can contain a unique value in the relational table.

For Example

18 | P a g e
 Operations in Relational Model
Four basic operations are generally performed on relational database model.
These are: Insert, update, delete and select.
• Insert is used to insert data into the relation

• Delete is used to delete tuples from the table.

• Update allows to change the values of some attributes in existing tuples. •

Select allows you to choose a specific range of data.

Whenever one of these operations are applied, integrity constraints specified

on the relational database schema must never be violated.

Insert Operation
The insert operation gives values of the attribute for a new tuple which should
be inserted into a relation.

Update Operation
You can see that in the below-given relation table CustomerName= ‘Apple’ is
updated from Inactive to Active.

Delete Operation
To specify deletion, a condition on the attributes of the relation selects the
tuple to be deleted.

19 | P a g e
In the above-given example, CustomerName= “Apple” is deleted from the table.
The Delete operation could violate referential integrity if the tuple which is
deleted is referenced by foreign keys from other tuples in the same database.

Select Operation

In the above-given example, CustomerName=”Amazon” is selected.

Best Practices for Creating a Relational Model

• Data need to be represented as a collection of relations

• Each relation should be depicted clearly in the table

• Rows should contain data about instances of an entity

• Columns must contain data about attributes of the entity

• Cells of the table should hold a single value

• Each column should be given a unique name

• No two rows can be identical

• The values of an attribute should be from the same domain

Advantages of Relational Database Model
• Simplicity: A Relational data model in DBMS is simpler than the hierarchical
and network model.
• Structural Independence: The relational database is only concerned with data
and not with a structure. This can improve the performance of the model.
• Easy to use: The Relational model in DBMS is easy as tables consisting of

rows and columns are quite natural and simple to understand • Query
capability: It makes possible for a high-level query language like SQL to avoid
complex database navigation.
20 | P a g e
 • Data independence: The Structure of Relational database can be changed
without having to change any application.
• Scalable: Regarding a number of records, or rows, and the number of fields, a
database should be enlarged to enhance its usability.

Disadvantages of Relational Model

• Few relational databases have limits on field lengths which can’t be

exceeded.
• Relational databases can sometimes become complex as the amount of data
grows, and the relations between pieces of data become more complicated.
• Complex relational database systems may lead to isolated databases
where the information cannot be shared from one system to another.

21 | P a g e