11 Types of Data Models in DBMS with Examples

A data model in DBMS is a set of concepts and rules that are used to describe and organize the data in a database. It defines the structure, relationships, and constraints of the data, and provides a way to access and manipulate the data. Different data models are used to represent different types of data and relationships, and each has its own set of advantages and disadvantages.

Here are 11 types of data models in DBMS with examples:

1. Relational Model
2. Flat Data Model
3. Entity-Relationship Model
4. Network Model
5. Hierarchical Model
6. Object-oriented Data Model
7. Object Relation Model
8. Record Based Model
9. Semi-structured Model
10. Associative Model
11. Context Data Model

Relational Model

The relational model is a data model that represents data as a collection of tables, with each table consisting of rows and columns. It is the most widely used data model in DBMS and is the foundation of RDBMS (Relational Database Management System).

In a relational model, each table, also known as a relation, represents a specific entity, such as a customer or an order. Each row in the table represents an instance of that entity and each column represents an attribute or property of that entity.

For example, a simple relational model for a retail store can have the following tables:

1. Customers: (columns for customer ID, name, address, and phone number)
2. Products (columns for product ID, name, description, and price)
3. Orders: (columns for order ID, customer ID, and order date)
4. Order_items: (columns for order ID, product ID, and quantity)

The tables are related to each other through the use of keys, for example the customer ID in the orders table is a foreign key that references the primary key of the customers table, and the product ID in the order_items table is a foreign key that references the primary key of the products table.

This simple example shows how a relational model organizes data into tables and uses keys to establish relationships between them. The relational model allows for data to be retrieved, updated and deleted in a simple and consistent way, also it allows for complex queries and joins of multiple tables to retrieve data.

Diagram representation of the example:

diagram, showing the relationships between the tables:

+------------+      +--------------+      +-----------------+
|  Customers |<-----|   Orders     |------|  Order_Items    |
+------------+      +--------------+      +-----------------+
| customer ID|      | order ID     |      | order ID        |
| name       |      | customer ID  |------| product ID      |
| address    |      | order date   |      | quantity        |
| phone      |      |              |      |                 |
+------------+      +--------------+      +-----------------+
                                                                       
+------------+
|  Products  |
+------------+
| product ID |
| name       |
| description|
| price      |
+------------+

Flat Data Model

A flat data model, also known as a flat file model, is a type of data model that stores data in a single table or file, with no nested or related structures. Each record in the file represents an instance of an entity or concept, and each field within the record represents an attribute or property of that entity or concept.

A flat data model is a simple and basic way to store data, and it is suitable for small and simple databases where the relationships between the data are not complex.

For example, a simple flat data model for a retail store can include a single file with the following fields:

1. Order ID
2. Customer name
3. Customer address
4. Customer phone number
5. Product name
6. Product description
7. Product price
8. Order date
9. Quantity

a model diagram for the retail store example:

+-------------------+
|       Order       |
+-------------------+
| - Order ID        |
| - Customer name   |
| - Customer address|
| - Customer phone  |
| - Product name    |
| - Product desc.   |
| - Product price   |
| - Order date      |
| - Quantity        |
+-------------------+

In this example, each record in the file represents an order, and each field within the record represents an attribute of the order, such as the customer name, product name, and quantity. There are no explicit relationships between the records, and it’s difficult to extract meaningful insights from the data.

It’s important to note that flat data model is not widely used in modern DBMS, and it’s not recommended for large or complex databases because it lacks the ability to handle relationships between the data and it’s not efficient for data retrieval and manipulation.

Entity-Relationship Model

The entity-relationship (ER) model is a data model that describes the relationships between entities in a database. It is used to represent the structure and constraints of a database in a conceptual way, independent of any specific DBMS or data model. The ER model is often used during the early stages of database design to define the requirements and constraints of a database and to communicate them to stakeholders.

In the ER model, entities are represented as rectangles and relationships are represented as diamond shapes. Entities are objects or concepts that have a distinct identity and properties, such as a customer or a product. Relationships are the associations between entities, such as a customer placing an order.

For example, a simple ER model for a retail store with the following entities:

1. Customer
2. Product
3. Order

and the following relationships:

1. A customer places one or more orders
2. An order is placed by one customer
3. An order contains one or more products
4. A product is contained in one or more orders

Here’s the ER diagram for the retail store example:

+-----------------+          +-----------------+
|    Customer     |          |     Product     |
+-----------------+          +-----------------+
| - customer_id   |          | - product_id    |
| - customer_name |          | - product_name  |
+-----------------+          +-----------------+
    |   1                             |
    |                                 |
    |   *                             |
+-----------------+                   |
|      Order      |                   |
+-----------------+                   |
| - order_id      |                   |
| - order_date    |                   |
+-----------------+                   |
    |   1                            *|
    | Customer                        |
    |                                 |
    |                                 |
    |                                 |
    |   *                            1|
    | Order                           |
    |                                 |
    |                                 |

In this example, the ER model shows how the customer, product, and order entities are related to each other. The model also shows the cardinality of the relationships, that is, the number of instances of one entity that can be associated with a single instance of another entity.

The ER model is used to design and understand the structure of a database, it’s used as a blueprint for the physical database design and it’s also used to communicate the requirements of the database to the stakeholders.

Network Model

The network model is a type of data model that represents data as a collection of records and relationships. It is similar to the hierarchical model in that it represents data as a tree-like structure, with each record having a parent-child relationship with one or more other records. However, the network model allows for many-to-many relationships, whereas the hierarchical model only allows for one-to-many relationships.

In the network model, records are represented as nodes and relationships are represented as links between nodes. Each node has a unique identifier, also called a record number, and can have multiple links to other nodes. The relationships are defined by link types and link sets, which specify the type of relationship and the number of links between nodes.

For example, a simple network model for a retail store might include the following records:

1. Customers: with fields for customer ID, name, address, and phone number.
2. Products: with fields for product ID, name, description, and price.
3. Orders: with fields for order ID, customer ID, and order date.

In this example, the records are related to each other through the use of links, for example, the customer ID in the orders record is a link to the customers record, and the product ID in the orders record is a link to the products record.

Here is an example of a simple network model:

   +-------------+         +-------------+         +-------------+
   |  Node 1     |---------|  Node 2     |---------|  Node 3     |
   +-------------+         +-------------+         +-------------+
   |             |         |             |         |             |
   +-------------+         +-------------+         +-------------+

In this diagram, nodes represent entities in the network, and the lines connecting the nodes represent the relationships between them. In this simple example, Node 1 is connected to Node 2 and Node 2 is connected to Node 3. This type of diagram can be used to represent network models with many nodes and relationships between them.

The network model is mainly used in legacy systems and is not as popular as the relational model, it has some advantages over the hierarchical model, such as more flexibility in defining relationships and it allows for many-to-many relationships. However, it’s more complex than the relational model and it’s not as efficient for data retrieval and manipulation.

Hierarchical Data Model

A hierarchical data model is a way of organizing data in a tree-like structure, where each record is a parent or child of one or more other records. This structure is similar to an organizational chart, where each record is a parent of one or more child records, and each child record is a parent of one or more child records.

In a hierarchical data model, each record has a unique identifier, also called a primary key, and one or more fields that store the data for that record. The relationships between records are defined by pointers, which are fields that contain the primary key of the parent or child record.

For example, a simple hierarchical data model for a retail store might include the following records:

1. Customers: with fields for customer ID, name, address, and phone number.
2. Products: with fields for product ID, name, description, and price.
3. Orders: with fields for order ID, customer ID, product ID, and order date.

In this example, the customer ID and product ID fields in the orders record are pointers to the customer and product records, respectively, linking them together and showing the relationship.

See another examples of hierarchical model.

    +----------------+
    |   Division     |
    +----------------+
             |
             |
    +----------------+
    |   Department   |
    +----------------+
             |
             |
    +----------------+
    |   Employee     |
    +----------------+

In this diagram, the Division is at the highest level, and is related to many Departments. Each Department is related to many Employees. The diagram shows the hierarchical relationships between the entities in the data model, with the Division being at the top and Employees at the bottom. The lines connecting the entities represent the relationships between them, showing that a Division can have multiple Departments, and a Department can have multiple Employees.

Hierarchical data models were widely used in the past, but they have been largely replaced by other types of data models, such as the relational model, because they have some limitations like one-to-many relationships and they are not flexible for the data retrieval and manipulation. They are also not efficient for large and complex databases.

Object Oriented Data Model

The object-oriented data model (OODM) is a data model that represents data as objects, which are instances of classes. Classes are templates that define the properties and methods of the objects, and objects are instances of those classes with specific values for those properties.

In an object-oriented data model, each object has a unique identity, a set of properties (or attributes), and a set of methods (or behaviors). Objects also have a class, which is a template that defines the properties and methods of the object. Classes can also be organized into a class hierarchy, where a class can inherit properties and methods from a parent class.

For example, a simple object-oriented data model for a retail store might include the following classes:

1. Customer: with properties for customer ID, name, address, and phone number, and methods for placing an order and viewing their order history.
2. Product: with properties for product ID, name, description, and price, and methods for viewing product details and checking availability.
3. Order: with properties for order ID, customer ID, product ID, and order date, and methods for viewing order details and calculating the total cost.

In this example, the Customer, Product, and Order classes define the properties and methods of the objects of those classes, and the relationships between the objects are represented through properties such as the customer ID in the Order class pointing to a specific customer object and the product ID in the Order class pointing to a specific product object.

See another example of an object-oriented data model in diagram form:

      +---------------+
      |   Employee    |
      +---------------+
      | - employee ID |
      | - name        |
      | - address     |
      | - phone       |
      +---------------+
             |
             |
      +---------------+
      |   Department  |
      +---------------+
      | - department ID|
      | - name         |
      | - location     |
      +---------------+
             |
             |
      +---------------+
      |   Company     |
      +---------------+
      | - company ID  |
      | - name        |
      | - location    |
      +---------------+

In this diagram, each object represents a data entity, with its attributes represented by the fields within the object. The lines connecting the objects represent the relationships between them, showing that an Employee belongs to a Department, and a Department belongs to a Company. This type of diagram is useful in representing complex data structures and relationships in an object-oriented software system.

The object-oriented data model is widely used in object-oriented programming languages and in applications that handle complex and dynamic data, such as video games, virtual reality, and simulations. This model allows for the encapsulation of data and behavior, inheritance and polymorphism which are the key features of object-oriented programming. Additionally, it’s a powerful model for data manipulation, but it’s not well suited for handling large amounts of data.

Object Relational Model

The Object-Relational Model (ORM) is a data model that combines the features of the object-oriented data model and the relational data model. ORM is a way to work with relational databases using an object-oriented programming language, like Java or C#.

In an ORM, data is represented using classes and objects, like in an object-oriented data model, but the data is stored in a relational database. The ORM provides an abstraction layer between the object-oriented code and the relational database, allowing developers to work with the data as if it were in-memory objects, rather than dealing with the complexities of SQL and database schemas.

For example, a simple ORM for a retail store might include the following classes:

1. Customer: with properties for customer ID, name, address, and phone number, and methods for placing an order and viewing their order history.
2. Product: with properties for product ID, name, description, and price, and methods for viewing product details and checking availability.
3. Order: with properties for order ID, customer ID, product ID, and order date, and methods for viewing order details and calculating the total cost.

In this example, the ORM maps the object properties to columns in the relational database table, and the object methods to SQL operations. The ORM also handles the translation between the object-oriented data and the relational data, allowing developers to work with the data in a more natural way, while still maintaining the advantages of the relational data model like data integrity, consistency, and scalability.

ORM is widely used in modern web and mobile application development, as it allows developers to work with databases using their preferred programming languages and it simplify the database access and management. But, it can also cause performance issues if it’s not implemented correctly.

See this example of an object-relation data model in diagrammatic form:

      +---------------+    +---------------+
      |   Employee    |    |    Address    |
      +---------------+    +---------------+
      | - employee ID |    | - address ID  |
      | - name        |    | - street      |
      | - address     |----| - city        |
      | - phone       |    | - state       |
      +---------------+    | - zip code    |
             |            +---------------+
             |
      +---------------+    +---------------+
      |   Department  |    |   Order       |
      +---------------+    +---------------+
      | - department ID|   | - order ID    |
      | - name         |   | - customer ID |
      | - location     |   | - order date  |
      +---------------+    +---------------+
             |
             |
      +---------------+
      |   Company     |
      +---------------+
      | - company ID  |
      | - name        |
      | - location    |
      +---------------+

In this diagram, the Employee, Address, and Order objects are shown in a separate box from the Department and Company objects. This represents the fact that they are related to the other entities through relationships, but are stored in separate tables in a relational database. The lines connecting the objects represent the relationships between them, showing that an Employee has an Address, an Order is related to a Customer, and a Department belongs to a Company. The object-relational data model is useful in representing the relationship between objects in a software system and the corresponding data stored in a relational database.

Record Based Model

A Record-Based Model is a data model that represents data as a collection of records, where each record is a collection of fields. Each field has a unique name and a specific data type, and each record has a unique identifier, also known as a primary key.

In a Record-Based Model, the data is stored in a flat file, which is a file that contains all the records of the database, with no hierarchical or relational structure. The records are stored in a specific order, typically in the order they were added to the database.

For example, a simple Record-Based Model for a retail store might include the following fields:

1. Customer: with fields for customer ID, name, address, and phone number.
2. Product: with fields for product ID, name, description, and price.
3. Order: with fields for order ID, customer ID, product ID, and order date.

In this example, the records for each table are stored in a flat file, with no relationships between the records. The Record-Based Model is simple and easy to implement, but it has several limitations like limited data integrity, no relationship management and it’s not suitable for large and complex databases. It’s not used much in the industry but it’s still used in some specific cases like embedded systems and small databases where there is a need to store data in a simple and compact format.

See the example of a record-based data model in diagram:

      +---------------+
      |   Customer    |
      +---------------+
      | - customer ID |
      | - name        |
      | - address     |
      | - phone       |
      +---------------+

      +---------------+
      |   Product     |
      +---------------+
      | - product ID  |
      | - name        |
      | - description |
      | - price       |
      +---------------+

      +---------------+
      |   Order       |
      +---------------+
      | - order ID    |
      | - customer ID |
      | - order date  |
      +---------------+

In this diagram, each box represents a record type in a database table, and the columns within each box represent the fields or attributes of the record. The relationships between the tables can be inferred based on the connections between the fields in each table. For example, the “customer ID” field in the “Order” table is related to the “customer ID” field in the “Customer” table, as they both represent the same entity. This simple, flat structure of the record-based data model makes it easy to understand and implement, but it can become more complex as the data requirements grow.

Semi-Structured Model

A Semi-structured Data Model is a data model that allows for the storage and management of data that has some inherent structure, but also allows for the presence of unstructured or semi-structured data. In this kind of data model, the data can be of any type, and it can be organized in a variety of ways, as opposed to the strict structure of traditional data models like relational or hierarchical models.

For example, an example of semi-structured data is an XML document. XML is a markup language that allows for the creation of custom tags, which can be used to specify the structure of the data. However, the data within the tags can be of any type, and the structure of the tags does not have to be the same for every document.

Another example of semi-structured data is JSON (JavaScript Object Notation) data. JSON is a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate. JSON data also contains key-value pairs, but the keys can be any string and the values can be of any data type.

A semi-structured data model can be useful in situations where the data has some inherent structure, but also contains unstructured or semi-structured data. For example, in social media platforms like Twitter, the data is semi-structured because the tweets have some structure (e.g. text, hashtags, mentions, etc.) but users can use any text format to express themselves.

Semi-structured data models are becoming increasingly popular in big data and NoSQL databases as they allow for the storage and management of large amounts of data in a flexible and scalable way. They are also very useful in applications where the data structure is not well known or is subject to change.

Associative Model

An Associative Data Model, also known as the Object-Associative Data Model, is a data model that combines the features of the object-oriented data model and the relational data model. It is a hybrid data model that allows the representation of data in the form of objects and relationships between those objects, similar to the Entity-Relationship model.

In the Associative Data Model, data is represented using classes and objects, like in an object-oriented data model, but the relationships between the objects are represented using associations, which are similar to the relationships in a relational data model. The associations are defined by the developer and can be one-to-one, one-to-many, or many-to-many.

For example, a simple Associative Data Model for a retail store might include the following classes:

1. Customer: with properties for customer ID, name, address, and phone number, and associations to the orders they have placed.
2. Product: with properties for product ID, name, description, and price, and associations to the orders in which it appears.
3. Order: with properties for order ID, customer ID, product ID, and order date, and associations to the customer and product objects.

In this example, the Associative Data Model allows developers to work with the data in a more natural way, as they can navigate the associations between the objects rather than dealing with the complexities of SQL and database schemas. It allows for a more intuitive representation of data and relationships, but it’s not as widely used as other models like RDBMS.

See the example of associative data model in diagram form:

             +---------------+
             |   Customer    |
             +---------------+
             | - customer ID |
             | - name        |
             | - address     |
             | - phone       |
             +---------------+
                      |
                      |
                      |
                      v
             +---------------+
             |   Product     |
             +---------------+
             | - product ID  |
             | - name        |
             | - description |
             | - price       |
             +---------------+
                      |
                      |
                      |
                      v
             +---------------+
             |   Order       |
             +---------------+
             | - order ID    |
             | - customer ID |
             | - order date  |
             +---------------+
                      |
                      |
                      |
                      v
             +---------------+
             | Order_items   |
             +---------------+
             | - order ID    |
             | - product ID  |
             | - quantity    |
             +---------------+

In this diagram, the entities are represented by boxes, and the relationships between them are represented by arrows. For example, the “Customer” and “Order” entities are related by a one-to-many relationship, as a single customer can have multiple orders. The “Order” and “Order_items” entities are also related by a one-to-many relationship, as a single order can have multiple items. The associative data model is more flexible and powerful than the record-based model, as it can handle more complex relationships between entities. However, it can also be more difficult to implement and understand, especially for larger and more complex data models.

Context Data Model

A Context Data Model is a data model that captures the context in which data is created, stored, and used. The context includes information about the data itself, as well as information about the environment in which the data is generated, stored, and used.

In a Context Data Model, data is represented as a set of entities, where each entity is a collection of attributes. The attributes of an entity describe the properties of the data, such as its type, format, and size. The context of the data is also represented as attributes of the entity, such as the time and location of data creation, the user who created it, and the applications and systems that use it.

For example, a simple Context Data Model for a retail store might include the following entities:

1. Product: with attributes for product ID, name, description, price, and category.
2. Order: with attributes for order ID, customer ID, product ID, and order date.
3. Customer: with attributes for customer ID, name, address, phone number, and email.

In this example, the Context Data Model captures the data itself and the context in which it is created, stored, and used. It allows for more accurate and efficient management of the data by providing additional information about the data that can be used to improve data quality, security, and accessibility.

The Context Data Model is still not widely used, it’s more of a theoretical concept that could be used in specific scenarios where understanding and capturing the context of the data is crucial. It’s one of the newer data models that is still being researched and developed.

Further Reading

• Hashing in DBMS
• Functional Dependency in DBMS
• Referential Integrity in DBMS
• Difference between DBMS and RDBMS
• ACID Properties DBMS (Atomicity, Consistency, Isolation, Durability)