3. Features of data modeling
•
•
•
•
•
It lays the foundation for data governance and management.
It is neither the actual data nor the database that is to be
used in the system.
It represents the data entities, the relationship between
different data entities, and the business rules, policies, etc.
that govern the data and their activities.
It helps in standardization mainly in naming the entities,
setting default values, etc.
The normalization process ensures redundant data are
removed and the relationship and dependencies established
are as per business.
3
6. Types of data model
•
•
•
Conceptual Data Model: It gives a view of the business
significance of each data entity and not a technical detail of
data.
Logical Data Model: It gives a detailed description of each
data entity their attributes and the relationship between two
entities giving business purpose to each data.
Physical Data Model: It gives a technical view of the data i.e.
, the table name, column name, datatype, constraints,
indexes, primary key, etc.
6
7. Conceptual model(ER diagram)
•
•
•
•
•
•
•
•
Represents the business data as seen in the real world and as
understood by businesses.
easy understanding of the business data, concepts, and rules.
The contributors are generally Business stakeholders and Data
Architects.
The main three components or elements of the Conceptual Data
Model are
Entity
Attributes
Relationship
presents all the data entities referred to by the business and their
characteristics called attributes and the dependency or the
connection between entities called Relationships.
7
9. Some commonly used Relationship
notations:
One to one: Employee and his joining
details
One to many: Employee and his
workplace
One and only one: Employee and his
date of birth
Zero or one: Employee and his place
of demise
Zero or many: Employee and his
subordinates
9
10. Logical Data Model
•
•
•
•
extension of a conceptual model with more details.
It is prepared by a data architect with inputs from the
business.
Logical data models give a detailed structure of the data
elements and the data entity relationships in a system from
the business point of view.
It is independent of technology and technology changes do
not impact the model.
10
11. •
•
•
•
•
•
•
•
•
•
The logical model lays the foundation for the physical database
The data attributes represented typically are the data type and
their relationship with other entities.
all attributes of an entity need to be mentioned without any
omission.
The relationship is not generic as presented in the conceptual
data model
The relationship is presented more explicitly with details like,
Primary key
Foreign key
Parent-child dependent entity type
Non-identifying relation
The cardinality of the relationship.
11
13. Physical model
•
•
•
•
•
•
A physical data model is the layout of the actual database with all its
components and services.
This model depicts the actual database where the actual data is stored
and is accessed in the production environment when users use the
application.
This model is for developers and other users who desire to query the
actual data
It is based on technology and the choice that has been made for the
database and the version of the database i.e., ORACLE, SQL, etc.
It is an extension of the Logical model and has more details like table
names for the Entity. Column names are the attributes with more
specifications like their exact datatype, length, and precision.
In addition, it may also have derived data, i.e., data generated by a
process in the application that needs to be stored for future reference.
13
16. Hierarchical
•
•
•
•
•
•
•
•
earliest and can represent simple data models.
This model could handle one-to-many and one-to-one relations only.
It has a root or a parent node and then follows a tree-like structure
with other child nodes.
Only one parent is allowed for a child node, and a parent node can
have multiple child nodes.
The navigation path to a child node is always through a parent node,
so is slow and difficult.
If a parent is deleted, then all child nodes get deleted. It is very easy
and simple to understand.
Complex data models cannot be represented using this technique.
Data integrity is maintained in the parent-child relationship i.e., any
change in the Parent is reflected in the child entity.
16
18. Network model
•
•
•
•
•
•
This model was the next one to be evolved from the
hierarchical model.
Here, a child node could have multiple parent nodes.
This model could handle many-to-many relations in addition
to one-to-one and one-to-many.
Navigation is faster in this model, as there are multiple paths
to reach a child entity.
This model also gets very complex when data is large.
The data update is more complex than the hierarchical model.
18
20. Object-oriented
•
•
•
•
Object-oriented databases gained popularity with object-
oriented programming.
A real-world entity is represented as an object and the
object’s properties are the real-world entities’ attributes.
The model presents a view as a collection of objects.
Each object has its methods and features.
20
23. Relational
•
•
•
•
The relational Model is the most popular model.
In this model, the Entity information is represented as a
table.
All the attributes are represented as columns.
The relationship between entities is represented by
different standard notations.
23
25. Dimensional data modeling (DDM)
•
•
•
•
Technique that uses Dimensions and Facts to store the
data in a Data Warehouse efficiently.
Data structure or Process that helps access data from data
warehouse
Have specific structure and organize data to generate
effective reports
It optimizes the database for faster retrieval of the data
25
27. Process of Dimensional Data Modeling
27
Build the
Schema
Identify
the Facts
Identify
the
Dimensio
ns
Identify
the Grain
Identify
the
Business
Process
28. The business process
helps to identify the
appropriate Dimension and
Facts needed and maintain
the quality of data
28
Identify
the Grain
•
•
The process of identifying how much
normalization (lowest level of
information) can be achieved within the
data
It is the stage to decide the incoming
frequency of data (i.e.daily, weekly,
monthly, yearly), how much data we
want to store in the database (one day,
one month, one year, ten years), and
how much the storage will cost.
29. 29
Identify
the Facts
Identify
the
Dimensio
ns
Dimensions - Detailed
information about the
objects like date, store,
name, address, contacts,
etc.
Facts are the measures/
transactions linked with the
associated Dimensions (via
foreign keys). Usually, Facts
contain fewer columns and huge
rows. Eg: sales, daily ordered
quantity etc.
