Data Models

A data model in a Database Management System (DBMS) is an abstract

representation of the structure, relationships, and constraints of the data that will
be stored in a database. It provides a way to define how data is organized,
accessed, and manipulated.
There are different types of data models, and each one has a specific approach
to structuring the data
 Hierarchical Model
 Network Model
 Entity Relationship Model
 Relational Model
 Object Oriented Data Model
 Flat Data Model
 Semi Structures Data Model
 Associative Data Model
 Context Data Model

Hierarchical Model
The Hierarchical Model was the first database management system model. This
concept uses a hierarchical tree structure to organise the data. The hierarchy
begins at the root, which contains root data, and then grows into a tree as child
nodes are added to the parent node. This model accurately depicts several real-
world relationships such as food recipes, website sitemaps, and so on.
Example
The following diagram depicts the relationship between the shoes available on a
shopping website:
Features of a Hierarchical Model
1. Parent-Child Relationship
A parent node exists for each child node. However, a parent node might have
several child nodes. It is not permitted to have more than one parent.
2. One-to-many Relationship
The data is organised in a tree-like form, with the datatypes having a one-to-
many relationship. There can only be one path from any node to its parent. For
example, in the preceding example, there is only one way to get to the node
‘sneakers’, which is through the ‘men’s shoes’ node.
3. Deletion Problem
When a parent node is removed, the child node is removed as well.
4. Pointers
Pointers are used to connect the parent and child nodes and to traverse and
navigate between the stored data. The ‘shoes’ node in the above example points
to the two additional nodes, ‘women’s shoes’ and ‘men’s shoes.’
Pros of Hierarchical Model
 A tree-like structure is incredibly straightforward and quick to navigate.
 Any modification to the parent node is reflected automatically in the child
node, ensuring data integrity.
Cons of Hierarchical Model
 Relationships that are complex are not supported.
 Because it only supports one parent per child node, if we have a complex
relationship in which a child node needs to have two parents, we won’t be
able to describe it using this model.
 When a parent node is removed, the child node is removed as well.
Network Model
The hierarchical model is extended in the network model. Prior to the relational
model, it was the most popular model. To increase database performance and
standards, the network model was devised to express complicated data
relationships more effectively than hierarchical models. It has entities that are
grouped in a graphical format, and some of the entities can be reached by many
paths.
Example
We can observe that the node student has two parents, CSE Department and
Library, in the example below. In the hierarchical model, this was previously
impossible.

Features of a Network Model

1. Multiple Paths
There may be several paths to the same record due to the increased number of
relationships. It allows for quick and easy data access.
2. The Ability to Merge More Relationships
Data is more connected in this model since there are more relationships. This
paradigm can handle many-to-many as well as one-to-one relationships.
3. Circular Linked List
The circular linked list is used to perform operations on the network model. The
present position is kept up to date with the help of a software, and it navigates
through the records based on the relationship.
Pros of Network Model
 In comparison to the hierarchical model, data can be retrieved faster. This
is because the data in the network model is more related, and there may
be more than one path to a given node. As a result, the data can be
accessed in a variety of ways.
 Data integrity is present since there is a parent-child relationship. Any
changes to the parent record are mirrored in the child record.
Cons of Network Model
 As the number of relationships to be managed grows, the system may get
increasingly complicated. To operate with the model, a user must have a
thorough understanding of it.
 Any alteration, such as an update, deletion, or insertion, is extremely
difficult.
Entity Relationship Model
A high-level data model diagram is the entity-relationship model or ER Model.
We depict the real-world problem in visual form in this model to make it easier
for stakeholders to comprehend. The developers can also quickly grasp the
system by simply looking at the ER Diagram.
Features of an Entity-Relationship Model
1. Graphical Representation for Better Understanding – It is really
straightforward and easy to comprehend, so developers can use it to interact
with stakeholders.
2. Database Design – This approach is extensively used in database design and
aids database designers in the creation of databases.
3. ER Diagram – The ER diagram is a visual representation of the model.
Components of an ER Diagram
The ER diagram is a visual representation of an ER Model. The three
components of an ER diagram are as follows:
1. Entities
An entity is a real-life concept. It could be a person, a location, or even an idea.
A school management system, for example, has entities such as teachers,
students, courses, buildings, departments, and so on.
2. Attributes
An attribute is a real-world property that exists in an entity. For example, the
entity teacher has properties such as teacher salary, id, age, and so on.
3. Relationship
The relationship between two traits describes how they are linked. A teacher, for
example, works for a department.
Example
The entities in the figure above are Teacher and Department. Teacher_id,
Teacher_Name, Age, Salary, and Mobile Number are the characteristics of the
Teacher object. Dept_name and Dept_id are the attributes of the Department
entity. The relationship is used to connect the two entities, and each teacher is
assigned to a department.
Pros of Entity-Relationship Model
1. Simple – The ER Model is simple to construct conceptually. We can easily
construct the ER Diagram for the model if we know the relationship between
the entities and the attributes.
2. Effective communication tool – Database designers frequently employ this
model to communicate their thoughts.
3. Easy conversion to any model – This model translates neatly to the
relational model, and it is simple to transform the ER model into a table. This
model can be transformed into a network model, a hierarchical model, and so
forth.
Cons of Entity-Relationship Model
1. No industry standard for notation – When it comes to creating an ER
model, there is no industry standard. As a result, one developer may utilise
notations that are unfamiliar to other developers.
2. Hidden information – In the ER model, certain information may be lost or
hidden. Because it is a high-level view, there is a potential that some
information specifics will be buried.
Relational Model
The relational model represents DB in the form of a collection of various
relations. This relation refers to a table of various values. And every row present
in the table happens to denote some real-world entities or relationships. The
names of tables and columns help us interpret the meaning of the values present
in every row of the table. This data gets represented in the form of a set of
various relations. Thus, in the relational model, basically, this data is stored in
the form of tables. However, this data’s physical storage is independent of its
logical organisation.
Popular Relational Database Management Systems:
 IBM – DB2 and Informix Dynamic Server
 Oracle – Oracle and RDB
 Microsoft – SQL Server and Access
Properties of a Relational Model
The relational databases consist of the following properties:
 Every row is unique
 All of the values present in a column hold the same data type
 Values are atomic
 The columns sequence is not significant
 The rows sequence is not significant
 The name of every column is unique
Illustration of the Relational Model
A relational model represents how we can store data in Relational Databases.
Here, a relational database stores information in the form of relations or tables.
Now, let us consider a relation EMPLOYEE with attributes ID_NO, NAME,
ADDRESS, ROLL_NO, and AGE shown in this table:
EMPLOYEE

ID_NO NAME ADDRESS ROLL_NO AGE

C1 RIYA DELHI 15 20

C2 SUNITA GURGAON 16 22

C3 ASHWANI ROHTAK 12 18

C4 PREETI DELHI 25

Important Terminologies
Here are some Relational Model concepts in DBMS:
 Attribute: It refers to every column present in a table. The attributes refer
to the properties that help us define a relation. E.g., Employee_ID,
Student_Rollno, SECTION, NAME, etc.
 Tuple – It is a single row of a table that consists of a single record. The
relation above consists of four tuples, one of which is like:

C1 RIYA DELHI 15 20

 Tables – In the case of the relational model, all relations are saved in the
table format, and it is stored along with the entities. A table consists of
two properties: columns and rows. While rows represent records, the
columns represent attributes.
 Degree: It refers to the total number of attributes that are there in the
relation. The EMPLOYEE relation defined here has degree 5.
 Relation Schema: It represents the relation’s name along with its
attributes. E.g., EMPLOYEE (ID_NO, NAME, ADDRESS, ROLL_NO,
AGE) is the relation schema for EMPLOYEE. If a schema has more than
1 relation, then it is known as Relational Schema.
 Column: It represents the set of values for a certain attribute. The column
ID_NO is extracted from the relation EMPLOYEE.
 Cardinality: It refers to the total number of rows present in the given
table. The EMPLOYEE relation defined here has cardinality 4.
 Relation instance – It refers to a finite set of tuples present in the RDBMS
system. A relation instance never has duplicate tuples.
  Attribute domain – Every attribute has some predefined value and scope,
which is known as the attribute domain.
 Relation key – Each and every row consists of a single or multiple
attributes. It is known as a relation key.
 NULL Values: The value that is NOT known or the value that is
unavailable is known as a NULL value. This null value is represented by
the blank spaces. E.g., the MOBILE of the EMPLOYEE having ID_NO 4
is NULL.
Constraints in Relational Model
While we design a Relational Model, we have to define some conditions that
must hold for the data present in a database. These are known as constraints.
One has to check these constraints before performing any operation (like
insertion, updating and deletion) in the database. If there occurs any kind of a
violation in any of the constraints, the operation will ultimately fail.
Domain Constraints
The domain constraints are like attribute level constraints. Now an attribute is
only capable of taking values that lie inside the domain range. For example, if a
constraint ID_NO>0 is applied on the EMPLOYEE relation, inserting some
negative value of ID_NO will result in failure.
Key Integrity
Each and every relation present in the database should have at least one set of
attributes that uniquely defines a tuple. Those sets of attributes are known as
keys. For example, ID_NO in EMPLOYEE is a key. Now, remember that no
two students would be capable of having the very same ID number. Thus, a key
primarily consists of these two properties:
 It has to be unique for all the available tuples.
 It can not consist of any NULL values.
Referential Integrity
Whenever one of the attributes of a relation is capable of only taking values
from another attribute of the same relation or other relations, it is termed
referential integrity.
Now, let us have the following two relations:
LEARNER
 ID_NO NAME ADDRESS ROLL_NO AGE CODE_OF_BRANCH

C1 RIYA DELHI 15 20 CS

C2 SUNITA GURGAON 16 22 CS

C3 ASHWANI ROHTAK 12 18 ECE

C4 PREETI DELHI 18 25 IT

SUBJECT

SUBJECT_NAME SUBJECT_CODE

COMPUTER SCIENCE CS

INFORMATION TECHNOLOGY IT

ELECTRONICS AND COMMUNICATION ENGINEERING ECE

CIVIL ENGINEERING CV

The SUBJECT_CODE of LEARNER can only take the values that are present
in the SUBJECT_CODE of SUBJECT, which is known as referential integrity
constraint. Thus, the relation that is referencing to the other relation is known as
REFERENCING RELATION (LEARNER in this case), while that relation to
which the other relations refer is known as REFERENCED RELATION
(SUBJECT in this case).

Object Oriented Data Model

The OODM is a better representation of real-world challenges. Both the data
and the relationship are contained into a single structure that’s known as an
object in this model. We can now store audios, pictures, videos, and other types
of data in databases, which was previously impossible with the relational
approach (Although you can store video and audio in relational DB, it is
generally advised not to store them in the relational DB).
Examples
Here is an example of this model:

The Employee and Department are the two objects in the example above. Each
object’s data and the relationships are there in a single unit. Here, the
attributes of the employee, such as Name and Job_title, as well as the methods
that will be performed by that object, are all kept in a single object. The two
objects are linked by a common attribute, i.e., Department_id, as well as
communication between them will be accomplished by this common id.
Components of an Object-Oriented Data Model
• An object is a representation of a physical entity. In general, an object can be
thought of as the entity of an ER model. A single instance of an entity is
represented by an object. Several of the components in this list define the
semantic content of the object.
• An object’s attributes are described by attributes. For example, the properties
Social Security Number, Name, and Date of Birth are all present in a PERSON
object.
• Classes are groups of objects with similar features. A class is a group of
objects that have similar structure (attributes) and behaviour (methods). A class
is similar to the entity set in the ER model in general. A class, on the other hand,
differs from an entity set. It has a collection of procedures called methods. The
method of a class depicts a real-world activity like finding a PERSON’s name,
updating a PERSON’s name, printing a PERSON’s address, and many more. In
other words, in classical programming languages, the methods are equivalent to
procedures. Methods define the behaviour of an object in OO terms.
• A class hierarchy is used to organise classes. The class hierarchy in some ways
resembles an upside-down tree with only one parent for each class. The
CUSTOMER and EMPLOYEE classes, for example, have the same parent
PERSON class. (Notice how this is comparable with the hierarchical data
model).
• Inheritance refers to an object’s capacity to inherit the characteristics and
methods of those classes that are above it in the class hierarchy. For instance,
two classes can be built as subclasses of the PERSON class: CUSTOMER and
EMPLOYEE. EMPLOYEE and CUSTOMER will inherit all properties and
methods from PERSON in this situation.
Flat Data Model
A flat data model is one in which all of the data is kept in the same plane. It’s a
standard data model that’s been introduced first and foremost, but it’s not really
scientific.
In the flat database model, each data element is represented by a single two-
dimensional array, with columns having similar types of values and components
in the row having relational values.
The database is represented in this model as a single table with fields (columns)
and tuples (rows). This database management system (DBMS) data model is a
slow and inefficient procedure.
A flat database refers to a simple DB system in which each database has to be
represented as a single table, with all records saved as single rows of data
separated by tabs or commas. A simple text file is typically used to store and
physically display the table.
Flat databases are not appropriate for most software applications that need the
representation and storage of complex business interactions due to their
constraints. However, some application developers continue to use flat files to
save money and time when connecting a relational database.
Flat databases, or flat-file databases, are another name for them.
Example
There are two columns entitled name and password, for example, that can be
used by any given security system. As a result, each row is utilised to record
various accounts and passwords. In the flat model, no two entries are the same.
The table format is used to store the database in the flat model. Because it is
hard to manage such a vast collection of entries in the case of a flat database
model, this database model has the problem of being unable to store big chunks
of data in the 2D array.
Semi Structures Data Model
This model is a DB (database) model in which the data and the schema are not
separated, and the amount of structure employed is determined by the goal or
the purpose.
Semi-structured data refers to the structured data that doesn’t adhere to the
tabular structure of the data models that are associated with relational DBs or
any other types of data tables. It includes tags or any other markers in order to
segregate semantic pieces and enforce hierarchies of fields and records within
the data. As a result, it’s known as a self-descriptive structure.
Despite being grouped close to one other, entities of the same class in semi-
structured data may have diverse characteristics, and the order of the attributes
is irrelevant.
Because full-length texts, documents, and DB are no longer the sole types of
data, semi-structured data has become more common since the internet’s
inception. Semi-structured data is ubiquitous in object-oriented DBs, and many
applications require a means or a medium for information transmission.
Example
A common example of this type of data model is web-based data sources in
which the data and the schema of the website are indistinguishable. Some
entities may be missing attributes, while another one may have an extra attribute
in this model. This approach allows for data storage flexibility. It also allows the
qualities to be more flexible. Any value that we store in any attribute can be
either an atomic value or a collection of data.
Emails, HTML, web pages, etc., are a few more examples of this type of data
model.
Pros of Semi-Structured Data Model in DBMS
The following are some of the benefits of this model:
 It can be used to represent data from some data sources that aren’t bound
by a schema.
 It offers a versatile format for data sharing between various DBs.
 Viewing structured data as semi-structured can be beneficial for browsing
purposes.
 It is simple to alter the schema.
 It’s possible that the data transfer format is portable.
Cons of Semi-Structured Data Model in DBMS
The main disadvantage of using a semi-structured data model is that queries
cannot be performed as quickly as they can in a more limited structure, such as
the relational model. In a semi-structured DB, records are typically stored with
unique IDs referenced with pointers to their disc location. It makes navigational
or path-based queries very efficient, but it is inefficient for searching multiple
records (as is common in SQL) because it must seek around the disc following
pointers.
One standard for expressing semi-structured data is the Object Exchange Model
(OEM), while another is XML.
Associative Data Model
A model in which the data is separated into two sections is known as an
associative data model. Everything that has its own existence is referred to as an
entity, and the relationships between these entities are referred to as
associations. Items and links are two types of data that are separated into two
components.
1. Item: The name and identifier are included in each item (some numeric
value).
2. Links: The identifier, source, verb, and subject are all included in the links.
Examples
Assume we receive the following statement: “Starting from 30 May 2020,
London will host the World Cup.”
Two links must be saved in this information:
London is hosting the world cup this year.
 The source is ‘the world cup,’ the verb is ‘is being,’ and the destination is
‘London.’
 …Starting from 30 May 2020: The verb is ‘from,’ and the target is ’30
May 2020.’ The source is the preceding link.
Uses of Associative Data Model in DBMS
There are two structures in the associative database: a collection of objects and
a set of links that are used to connect them. The entries in the item structure
must have a unique indicator, a type, and a name. In addition to indicators for
the associated source, object, subject, and verb, entries in the links structure
must have a unique indication.
Pros of Associative Data Model in DBMS
The storage room is efficient with the associative model structure since there is
no need to set aside existing space for data that is not yet available. This differs
from the structure of a relational model. In the relational model, missing data in
any given row is represented by a single null byte. In addition, some relational
databases reserve the maximum amount of space in each row for a specific
column.
When considering maintenance or network resources, the associative database
creates an obvious storage of custom data and information for each user or other
demands. When diverse types of data need to be stored, the associative model
performs better than the relational approach.
Cons of Associative Data Model in DBMS
There is no record in the associative model. When putting together all of the
present data in a complicated arrangement, the data store must be revisited
several times. This could be a drawback. According to certain calculations, an
associative database would require four times the number of data reads as a
relational database.
Adding links to the database has a direct impact on all changes and deletions to
the associative model. However, it’s important to remember that a deleted
association isn’t actually destroyed. Rather, it refers to a statement that has since
been removed. Also, when an entity is renamed, it is linked to its new name
rather than being renamed.

Context Data Model

Context data models are extremely versatile since they combine multiple data
models. It is a set of data models that includes relational, network, semi-
structured, and object-oriented models. As a result of the database model’s
flexible design, it may be used to complete a variety of activities. As a result,
support for various sorts of users has been provided, which may differ
depending on how users interact in the database.
By effectively handling relevant data, the context data model ushered in a
revolution in the industries.
The context model is a mash-up of numerous data models that we’ve covered in
earlier articles. A context model, for example, can be a mix of network models,
ER models, and other types of models. This data model enables you to do a
variety of things that you won’t be able to do if you use only one data model.