DATA MODEL
Data Model gives us an idea that how the final system will
look like after its complete implementation. It defines the
data elements and the relationships between the data
elements. Data Models are used to show how data is stored,
connected, accessed and updated in the database
management system.
As per your application's requirement, you can use a database model
to define your database.
The database model sets the rule, relationships, constraints, etc. to
define how data is stored in the database.
Types:
1. Hierarchical database
A hierarchical database is a set of tables arranged in the form of a
parent-child relationship. Each set of parents can have a relationship
with any number of children. But every child can have a relationship
with only one set of parents.
A hierarchical database model is a one-to-many relationship. You
can think of it as an upside-down tree with the root at the top. To
access data from the database, the whole tree has to be traversed
starting from the root downwards.
Early computers had limited resources; hierarchical databases (like IBM IMS)
were efficient and used less memory/processing.
Example:
Drawbacks:
While the hierarchical model is suitable for simple structures, it only
supports one-to-many relationships. This means each “child” can
only have one “parent.” If, for example, the database contains the
names of both parents and their children working for a company, you
can’t describe the fact that both parents of each child worked for that
company.
It needs sequential searching, which means the database
management system has to run through the entire model from top to
bottom until the required information is found. This makes queries
very slow.
2. Network data model:
The Network Model is an extension of the Hierarchical model.
In this model, data is organized more like a graph, and allowed to have more than one
parent node.
In the network database model, data is more related as more relationships are established
in this database model.
Also, as the data is more related, hence accessing the data is also easier and fast.
This database model uses many-to-many data relationships.
This was the most widely used database model before Relational Model was
introduced.
The implementation of the Network model is complex, and it's very difficult to maintain
it.
Why we use the Network DBMS model:
1. Many-to-many relationships allowed
o Unlike hierarchical (which is strictly parent–child), the network model allows
records to have multiple parents and multiple children.
o Example: A student can enroll in many courses, and a course can have many
students.
2. Faster navigation than relational joins
o Data is linked using pointers (called set types).
o If the application is known in advance (fixed queries), navigating these pointers is
much faster than performing relational joins.
3. Reduced redundancy
o Since multiple records can be shared, you don’t need to duplicate data in different
trees (as in hierarchical DBMS).
4. Better than hierarchical for complex relationships
o Hierarchical forces you into a single tree → not realistic for real-world cases like
supply chain, banking, or student-course systems.
o Network model represents these complex relationships more naturally.
Drawbacks:
The Network model is difficult to modify also.
3. Entity-relationship Model
In this database model, relationships are created by dividing objects of
interest into entities and their characteristics into attributes.
Different entities are related using relationships.
ER Models are defined to represent the relationships in pictorial form to
make it easier for different stakeholders to understand.
This model is good to design a database, which can then be turned into
tables in a relational model .
Elements of the ER Model
Entities: Real-world objects are referred to as entities. It could
be a class, name, location, or item. In an ER Diagram, these are
shown by a rectangle.
Attributes: An entity's description is referred to as an attribute.
In an ER Diagram, these are represented by an ellipse. For a
student, it could be their age, roll number, or marks.
Relationship: Relationships are what establish the connections
between various entities
Advantages of the ER Model
1. It is easy to understand and design.
2. Using the ER model we can represent data structures easily.
3. As the ER model cannot be directly implemented into a database
model, it is just a step toward designing the relational database model.
Disadvantages of ER Model
No industry standard for notation: There is no
industry standard for developing an ER model. So one
developer might use notations which are not
understood by other developers.
Hidden information: Some information might be lost
or hidden in the ER model. As it is a high-level view so
there are chances that some details of information
might be hidden.
4. Relational Database Model
A relational database arranges info in the form of single or
multiple tables.
Properties :
A single entry in a table is called a Tuple or Record or Row.
A tuple in a table represents a set of related data.
Each record can be broken down into several smaller parts of
data known as Attributes. The above Employee table
consist of four attributes, ID, Name, Age and Salary.
In this model, data is organized in two-dimensional tables and the
relationship is maintained by storing a common field.
The basic structure of data in the relational model is tables. All the
information related to a particular type is stored in rows of that table.
Hence, tables are also known as relations in the relational model.
You can design tables, normalize them to reduce data redundancy,
and use Structured Query language or SQL to access data from the
tables.
Some of the most popular databases are based on this database
model. For example, Oracle, MySQL, etc.
Advantages of a relational database are:
Data access isn’t affected by the changes in the database
structure.
It is easier to maintain security as compared to other models.
You can use relational databases with little or no training.
Database entries can be modified without specifying the entire
body.
