What is Data Modeling?

Data Modeling in software engineering is the process of simplifying the diagram or data model
of a software system by applying certain formal techniques. It involves expressing data and
information through text and symbols. The data model provides the blueprint for building a
new database or reengineering legacy applications.

In the light of the above, it is the first critical step in defining the structure of available data.
Data Modeling is the process of creating data models by which data associations and
constraints are described and eventually coded to reuse. It conceptually represents data with
diagrams, symbols, or text to visualize the interrelation.

Data Modeling thus helps to increase consistency in naming, rules, semantics, and security.
This, in turn, improves data analytics. The emphasis is on the need for availability and
organization of data, independent of the manner of its application.

Data Modeling Process

Data modeling is a process of creating a conceptual representation of data objects and their
relationships to one another. The process of data modeling typically involves several steps,
including requirements gathering, conceptual design, logical design, physical design, and
implementation. During each step of the process, data modelers work with stakeholders to
understand the data requirements, define the entities and attributes, establish the relationships
between the data objects, and create a model that accurately represents the data in a way that
can be used by application developers, database administrators, and other stakeholders.

Levels Of Data Abstraction

Data modeling typically involves several levels of abstraction, including:

• Conceptual level: The conceptual level involves defining the high-level entities and
relationships in the data model, often using diagrams or other visual representations.

• Logical level: The logical level involves defining the relationships and constraints
between the data objects in more detail, often using data modeling languages such
as SQL or ER diagrams.

• Physical level: The physical level involves defining the specific details of how the
data will be stored, including data types, indexes, and other technical details.

Data Modeling Examples

The best way to picture a data model is to think about a building plan of an architect. An
architectural building plan assists in putting up all subsequent conceptual models, and so does
a data model.

These data modeling examples will clarify how data models and the process of data modeling
highlights essential data and the way to arrange it.

1. ER (Entity-Relationship) Model

This model is based on the notion of real-world entities and relationships among them. It
creates an entity set, relationship set, general attributes, and constraints.

Here, an entity is a real-world object; for instance, an employee is an entity in an employee

database. An attribute is a property with value, and entity sets share attributes of identical value.
Finally, there is the relationship between entities.

2. Hierarchical Model

This data model arranges the data in the form of a tree with one root, to which other data is
connected. The hierarchy begins with the root and extends like a tree. This model effectively
explains several real-time relationships with a single one-to-many relationship between two
different kinds of data.

For example, one supermarket can have different departments and many aisles. Thus, the ‘root’
node supermarket will have two ‘child’ nodes of (1) Pantry, (2) Packaged Food.

3. Network Model

This database model enables many-to-many relationships among the connected nodes. The
data is arranged in a graph-like structure, and here ‘child’ nodes can have multiple ‘parent’
nodes. The parent nodes are known as owners, and the child nodes are called members.

4. Relational Model

This popular data model example arranges the data into tables. The tables have columns and
rows, each cataloging an attribute present in the entity. It makes relationships between data
points easy to identify.

For example, e-commerce websites can process purchases and track inventory using the
relational model.

5. Object-Oriented Database Model

This data model defines a database as an object collection, or recyclable software components,
with related methods and features.

For instance, architectural and engineering real-time systems used in 3D modeling use this data
modeling process.

6. Object-Relational Model

This model is a combination of an object-oriented database model and a relational database

model. Therefore, it blends the advanced functionalities of the object-oriented model with the
ease of the relational data model.
The data modeling process helps organizations to become more data-driven. This starts with
cleaning and modeling data. Let us look at how data modeling occurs at different levels.

Data Models in DBMS

• ••
A Data Model in Database Management System (DBMS) is the concept of tools that are
developed to summarize the description of the database. Data Models provide us with a
transparent picture of data which helps us in creating an actual database. It shows us from the
design of the data to its proper implementation of data.
Types of Relational Models
1. Conceptual Data Model
2. Representational Data Model
3. Physical Data Model
It is basically classified into 3 types:-

1. Conceptual Data Model

The conceptual data model describes the database at a very high level and is useful to
understand the needs or requirements of the database. It is this model, that is used in the
requirement-gathering process i.e. before the Database Designers start making a particular
database. One such popular model is the entity/relationship model (ER model). The E/R model
specializes in entities, relationships, and even attributes that are used by database designers. In
terms of this concept, a discussion can be made even with non-computer science(non-technical)
users and stakeholders, and their requirements can be understood.
Entity-Relationship Model( ER Model): It is a high-level data model which is used to define
the data and the relationships between them. It is basically a conceptual design of any database
which is easy to design the view of data.
Components of ER Model:
1. Entity: An entity is referred to as a real-world object. It can be a name, place,
object, class, etc. These are represented by a rectangle in an ER Diagram.
2. Attributes: An attribute can be defined as the description of the entity. These are
represented by Ellipse in an ER Diagram. It can be Age, Roll Number, or Marks for
a Student.
3. Relationship: Relationships are used to define relations among different entities.
Diamonds and Rhombus are used to show Relationships.
Characteristics of a conceptual data model
• Offers Organization-wide coverage of the business concepts.
 • This type of Data Models are designed and developed for a business audience.
• The conceptual model is developed independently of hardware specifications like
data storage capacity, location or software specifications like DBMS vendor and
technology. The focus is to represent data as a user will see it in the “real world.”
Conceptual data models known as Domain models create a common vocabulary for all
stakeholders by establishing basic concepts and scope
2. Representational Data Model
This type of data model is used to represent only the logical part of the database and does not
represent the physical structure of the database. The representational data model allows us to
focus primarily, on the design part of the database. A popular representational model is
a Relational model. The relational Model consists of Relational Algebra and Relational
Calculus. In the Relational Model, we basically use tables to represent our data and the
relationships between them. It is a theoretical concept whose practical implementation is done
in Physical Data Model.
The advantage of using a Representational data model is to provide a foundation to form the
base for the Physical model
3. Physical Data Model
The physical Data Model is used to practically implement Relational Data Model. Ultimately,
all data in a database is stored physically on a secondary storage device such as discs and tapes.
This is stored in the form of files, records, and certain other data structures. It has all the
information on the format in which the files are present and the structure of the databases, the
presence of external data structures, and their relation to each other. Here, we basically save
tables in memory so they can be accessed efficiently. In order to come up with a good physical
model, we have to work on the relational model in a better way. Structured Query Language
(SQL) is used to practically implement Relational Algebra.
This Data Model describes HOW the system will be implemented using a specific DBMS
system. This model is typically created by DBA and developers. The purpose is actual
implementation of the database.
Characteristics of a physical data model:
• The physical data model describes data need for a single project or application
though it maybe integrated with other physical data models based on project scope.
• Data Model contains relationships between tables that which addresses cardinality
and nullability of the relationships.
• Developed for a specific version of a DBMS, location, data storage or technology
to be used in the project.
• Columns should have exact datatypes, lengths assigned and default values.
• Primary and Foreign keys, views, indexes, access profiles, and authorizations, etc.
are defined
Some Other Data Models
1. Hierarchical Model
The hierarchical Model is one of the oldest models in the data model which was developed by
IBM, in the 1950s. In a hierarchical model, data are viewed as a collection of tables, or we can
say segments that form a hierarchical relation. In this, the data is organized into a tree-like
structure where each record consists of one parent record and many children. Even if the
segments are connected as a chain-like structure by logical associations, then the instant
structure can be a fan structure with multiple branches. We call the illogical associations as
directional associations.
2. Network Model
The Network Model was formalized by the Database Task group in the 1960s. This model is
the generalization of the hierarchical model. This model can consist of multiple parent
segments and these segments are grouped as levels but there exists a logical association
between the segments belonging to any level. Mostly, there exists a many-to-many logical
association between any of the two segments.
3. Object-Oriented Data Model
In the Object-Oriented Data Model, data and their relationships are contained in a single
structure which is referred to as an object in this data model. In this, real-world problems are
represented as objects with different attributes. All objects have multiple relationships between
them. Basically, it is a combination of Object Oriented programming and a Relational Database
Model.
4. Float Data Model
The float data model basically consists of a two-dimensional array of data models that do not
contain any duplicate elements in the array. This data model has one drawback it cannot store
a large amount of data that is the tables can not be of large size.
5. Context Data Model
The Context data model is simply a data model which consists of more than one data model.
For example, the Context data model consists of ER Model, Object-Oriented Data Model, etc.
This model allows users to do more than one thing which each individual data model can do.
6. Semi-Structured Data Model
Semi-Structured data models deal with the data in a flexible way. Some entities may have extra
attributes and some entities may have some missing attributes. Basically, you can represent
data here in a flexible way.
Advantages of Data Models
1. Data Models help us in representing data accurately.
2. It helps us in finding the missing data and also in minimizing Data Redundancy.
3. Data Model provides data security in a better way.
4. The data model should be detailed enough to be used for building the physical
database.
5. The information in the data model can be used for defining the relationship
between tables, primary and foreign keys, and stored procedures.
Disadvantages of Data Models
1. In the case of a vast database, sometimes it becomes difficult to understand the
data model.
2. You must have the proper knowledge of SQL to use physical models.
3. Even smaller change made in structure require modification in the entire
application.
4. There is no set data manipulation language in DBMS.
5. To develop Data model one should know physical data stored characteristics.
Conclusion
• Data modeling is the process of developing data model for the data to be stored in
a Database.
• Data Models ensure consistency in naming conventions, default values, semantics,
security while ensuring quality of the data.
• Data Model structure helps to define the relational tables, primary and foreign
keys and stored procedures.
• There are three types of conceptual, logical, and physical.
• The main aim of conceptual model is to establish the entities, their attributes, and
their relationships.
• Logical data model defines the structure of the data elements and set the
relationships between them.
 • A Physical Data Model describes the database specific implementation of the data
model.
• The main goal of a designing data model is to make certain that data objects
offered by the functional team are represented accurately.
• The biggest drawback is that even smaller change made in structure require
modification in the entire application.
• Reading this Data Modeling tutorial, you will learn from the basic concepts such
as What is Data Model? Introduction to different types of Data Model, advantages,
disadvantages, and data model example.

Common data modeling techniques and concepts

To better understand today's popular data modeling techniques, it's helpful to provide a quick
history lesson on how modeling has evolved. Among the seven data models described here, the
first four types were used in the early days of databases and are still options, followed by the
three models most widely used now.

1. Hierarchical data model

Data is stored in a tree-like structure with parent and child records that comprise a collection
of data fields. A parent can have one or more children, but a child record can have only one
parent. The hierarchical model is also composed of links, which are the connections between
records, and the types that specify the kind of data contained in the field. It originated in
mainframe databases in the 1960s.

2. Network data model

This model extended the hierarchical model by allowing a child record to have one or more
parents. A standard specification of the network model was adopted in 1969 by the Conference
on Data Systems Languages, a now-defunct group better known as CODASYL. As a result, it's
also referred to as the CODASYL model. The network technique is the precursor to a graph
data structure, with a data object represented inside a node and the relationship between two
nodes called an edge. Although popular on mainframes, it was largely replaced by relational
databases after they emerged in the late 1970s.

3. Relational data model

In this model, data is stored in tables and columns and the relationships between the data
elements in them are identified. It also incorporates database management features such as
constraints and triggers. The relational approach became the dominant data modeling technique
during the 1980s. The entity-relationship and dimensional data models, currently the most
prevalent techniques, are variations of the relational model but can also be used with non-
relational databases.

4. Object-oriented data model

This model combines aspects of object-oriented programming and the relational data model.
An object represents data and its relationships in a single structure, along with attributes that
specify the object's properties and methods that define its behavior. Objects may have multiple
relationships between them. The object-oriented model is also composed of the following:

• Classes, which are collections of similar objects with shared attributes and
behaviors.

• Inheritance, which enables a new class to inherit the attributes and behaviors of an
existing object.

It was created for use with object databases, which emerged in the late 1980s and early 1990s
as an alternative to relational software. But they didn't make a big dent in relational
technology's dominance.

5. Entity-relationship data model

This model has been widely adopted for relational databases in enterprise applications,
particularly for transaction processing. With minimal redundancy and well-defined
relationships, it's very efficient for data capture and update processes. The model consists of
the following:

• Entities that represent people, places, things, events or concepts on which data is
processed and stored as tables.

• Attributes, which are distinct characteristics or properties of an entity that are

maintained and stored as data in columns.

• Relationships, which define logical links between two entities that represent
business rules or constraints.
RICK SHERMAN, ATHENA IT SOLUTIONS
This is an entity-relationship data model created from Microsoft's AdventureWorks sample
database.

The model's design is characterized by the degree of normalization -- the level of redundancy
implemented, as identified by Edgar F. Codd, who created the relational model. The most
common forms are third normal form (3NF) and Boyce-Codd normal form, a slightly stronger
version also known as 3.5NF.

6. Dimensional data model

Like the entity-relationship model, the dimensional model includes attributes and relationships.
But it features two core components.

• Facts, which are measurements of an activity, such as a business transaction or an

event involving a person or devices. Facts are generally numeric, and fact tables are
normalized and contain little redundancy.

• Dimensions, which are tables that contain the business context of the facts to define
their who, what, where and why attributes. Dimensions are typically descriptive
instead of numeric.
RICK SHERMAN, ATHENA IT SOLUTIONS
This dimensional data model was built from Microsoft's AdventureWorks sample database.

The dimensional model has been widely adopted for BI and analytics applications. It's often
referred to as a star schema -- a fact surrounded by and connected to multiple other facts, though
that oversimplifies the model structure. Most dimensional models have many fact tables linked
to many dimensions that are referred to as conformed when shared by more than one fact table.

7. Graph data model

Graph data modeling has its roots in the network modeling technique. It's primarily used to
model complex relationships in graph databases, but it can also be used for other NoSQL
databases such as key-value and document types.

This is an example of a graph data model with

nodes connected by edges.

There are two fundamental elements in a graph data model.

• Nodes, which represent entities with a unique identity. Each instance of an entity is
a different node that's akin to a row in a table in the relational model.

• Edges, also known as links or relationships. They connect nodes and define how
the nodes are related. All nodes must have at least one edge connected to them.
Edges can be undirected, with a bidirectional relationship between nodes, or
directed, in which the relationship goes in a specified direction.

One of the more popular graph formats is the property graph model. In this model, the
properties of nodes or edges are represented by name-value pairs. Labels can also be used to
group nodes together for easier querying. Each node with the same label becomes a member
of the set, and nodes can be assigned as many labels as they fit.

Data modeling best practices

Best practices for data modeling include eight steps that can help an enterprise derive the
desired business value from its data.

Treat the data model as a blueprint and specification. Data models should be a useful guide
for the people who design the database schema and those who create, update, manage, govern
and analyze the data. Follow the progression from conceptual to logical to physical models if
a new data model is being created in a greenfield environment with no existing models or
physical schemas.

Gather both business and data requirements upfront. Get input from business stakeholders
to design conceptual and logical data models based on business needs. Also, collect data
requirements from business analysts and other subject matter experts to help derive more
detailed logical and physical models from the business requirements and higher-level models.
Data models need to evolve with the business and technology.

Develop models iteratively and incrementally. A data model may include hundreds or
thousands of entities and relationships. That would be extremely difficult to design all at once.
Don't try to boil the ocean. The best approach is to segment the model into the subject areas
identified in a conceptual data model and design those subject areas one by one. After doing
that, tackle the interconnections between them.

Use a data modeling tool to design and maintain the data models. Data modeling tools
provide visual models, data structure documentation, a data dictionary and the data definition
language code needed to create physical data models. They also can often interchange metadata
with database, data integration, BI, data catalog and data governance tools. And if there are no
data models on existing databases, leverage a tool's reverse-engineering functions to jump-start
the process.

Determine the level of granularity that's needed in data models. In general, maintain the
lowest level of data granularity -- in other words, the most detailed data that's captured. Only
aggregate data when necessary and only as a derivative data model, while still retaining the
lowest-grain data in the primary model.

Avoid extensive denormalization of databases. Denormalizing a database adds redundant

data to optimize query performance. But it assumes a specific relationship between entities that
may limit its usefulness for different analytics applications. As with aggregation, when
denormalization is used, it's best applied in a derivative data model -- for example, in a schema
for a BI application rather than in a data warehouse.

Use data models as a communication tool with business users. A 10,000-table entity-
relationship model can make anyone's head spin. But a data model, or a portion of one, focused
on a specific business process or data analysis offers the perfect opportunity to discuss and
verify the schema with business users. The assumption that business users can't grasp a data
model is a fatal mistake in modeling efforts.

Manage data models just like any other application code. Enterprise applications, data
integration processes and analytics applications all use data structures, whether they're
designed and documented or not. Rather than allow an unplanned "accidental architecture" to
develop and crush any chance of obtaining a solid ROI from their data, organizations need to
get serious about data modeling.