Data Models

Some Questions about Data Models

What is a data model for?
Data model was simply an abstraction of the table and column
structure of a database that showed how the tables related to each
other.
(Today we would probably call this a physical data model.)
Then, logical data model was introduced, which would be described as
“fully normalized.”
However this type of data model would still be related to the contents
of a single database.
Cont…
There are various thoughts about what this type of model is but
typically it includes no or few attributes and might be described as
being about the things the data represents, rather than about the data
contained in it.
Initially these were all data models associated with a single application.
But what about integrating data across applications?

Some have said that enterprise data models are either impossible to
construct, or not worth it—or is it just that those who have said so do
not know how to do it?
Cont..
How do you judge whether an application’s data model is fit for
purpose? In many cases applications need to be configured; how does
this affect whether information requirements are being met, now, and
in the future?
Enterprise architecture.
What does this mean for data modeling?

What sorts of data models do you need in an enterprise architecture?

What other elements do they relate to? How does this affect change
management?

Data modeling is a challenging task. It is often seen as a black art that

some people seem to have a facility for.
Important Aspect to Understand in
Enterprise Data Model
• The purpose of data models in both developing an Enterprise
Architecture and supporting Information Quality
• Common problems in developing data models, learning how to
recognize them, and making improvements
• How to develop high quality data models, in particular conceptual,
integration, and enterprise data models
• How to achieve a consistent approach to data modeling
• How to establish a consistent view of the world
• Some generic data model templates that are reusable in many
applications and can be used to develop more specific templates
What Is a Data Model?
A data model defines the structure and intended meaning of data. However, it
should also be noted that a data model is restrictive rather than permissive.
Ex. old joke, about the differences between different European cultures. It goes
like this:

“What is the difference between the British, the Germans, and the Italians?”
“I don’t know, what is the difference?”
“Well, for the British it is allowed unless it is forbidden, for the Germans it is
forbidden unless it is allowed, and for the Italians it is allowed especially if it is
forbidden.”
What Is a Data Model?
Well data models are like the Germans. (Previous Example/ Joke)
It is forbidden unless it is allowed.

So if you have not provided the necessary entity types, relationship

types, and attributes, then the data cannot be held.
Why Do We Do Data Models?
• Things can go wrong with data modeling;
• We can forget why we are doing it or not know why in the first place.
• The results are damaging: resources are wasted and the reputation of
data models and those that create them is diminished.
So, what are data models about? In almost any enterprise, the answer
is that data models are about improving the quality of information used
in making decisions.
quality does not mean ever more accurate. Quality means fit for
purpose.
The properties of information critical to information
quality and those that are supported by data
models.
Approach to Data Modeling
The traditional normalization approach,

Ontological one, which rather than looking at and eliminating the

repeating groups in data, looks at what the data is about and uses that
as a structuring basis for data.
ENTITY RELATIONSHIP MODEL
• Although we probably all have a favorite graphical notation, in
practice, we are unlikely to be able to choose the notation we use.
Likely as not, it will be defined by an enterprise standard, or the
enterprise standard data modeling tool, so unless you are lucky
enough to be the one who sets that, you will have to be able to learn
to get on with what is in use.

• So I think it is good practice to be familiar with a variety of

notations, to help to remember that it is not the notation that is
important, but how it is used.
Graphical or Lexical
Data models do not have to be described graphically, or only
graphically.
To be computer interpretable there must be a text alternative.

This may be SQL, some other data definition language, or a data

modeling language like EXPRESS (ISO 10303-11) that has both a lexical
and graphical notation,.
An example EXPRESS data model showing
both graphical and lexical form.
• EXPRESS-G (see Figure 2-1)—and of course UML has XMI as an XML-
based notation
Graphical Notations: Complexity vs.
Understandability vs. Capability
When defining graphical notations, it is tempting to be overly elaborate
and to have graphical symbols for everything.
This is effectively the same as creating a secret code language, which
only the initiates can understand.
This is a bad idea when you are trying to communicate with an
audience.
A good graphical notation is one that makes good use of intuitive
symbols, where you can still remember what they mean after six
months without looking at a data model (which will be the case for
many of those to whom you present your data models).
An example data model in CDIF
notation.
An invalid data model in the Oracle-
Barker notation.
Principles for good notations.

• Simple
• Memorable
• Capable

If you have a choice, these are the characteristics you should be

considering.
Language and Notation Elements

In the end, any graphically based language consists of boxes and lines,
or more formally, nodes and links (some may prefer the terms vertex
and edge)
Rules and Constraints
Different data modeling languages allow different rules and constraints
to be defined.
For example, EXPRESS has a rather rich rules capability in its lexical
form.
However, most data modeling languages can only express cardinality
constraints.
Express-G: (EXPRESS-G Data Model)
Attributes and Relationships
for example, if you want to give an entity type called person an
attribute called name that is of type STRING, then you would construct
the model in Figure 2-6.
Reading Relationships and Cardinalities
Reading Relationships and
Cardinalities
Reading Relationships and
Cardinalities
Reading Relationships and
Cardinalities
SOME TYPES AND USES OF DATA MODELS

One of the things you often find people arguing about is what a data
model is, and what it is for. Here’s one of the secrets of analysis: when
you find people arguing passionately about something, try to discover
why they are both right. So it is with data models. Data models have
many purposes. These cause differences in both style and content,
which can cause confusion, surprise, and disagreement.
Physical Data Model
A physical data model represents the actual structure of a database—tables and
columns, or the messages sent between computer processes.
Here the entity types usually represent tables, and the relationship type lines
represent the foreign keys between tables. The data model’s structure will often
be tuned to the particular needs of the processes that operate on the data to
ensure adequate performance. It will typically include
• Restrictions on the data that can be held
• Denormalization to improve performance of specific queries
• Referential integrity rules to implement relationship types
• Rules and derived data that are relevant to the processes of the application(s)
the physical data model serves
Logical Data Model
There is a range of views on what a logical data model is.
A logical data model is a fully attributed data model that is fully normalized.
Fully attributed means that the entity types have all the attributes and
relationship types for all the data that is required by the application(s) it serves.
It may include
• Restrictions on the data that can be held
• Rules and derived data that are relevant to the processes of the application(s)
the logical data model serves The main difference , that many data models that
are described as logical actually have some level of denormalization in them,
particularly where change over time is involved
Conceptual Data Model

A conceptual data model is a model of the things in the business and the
relationships among them, rather than a model of the data about those things.
So in a conceptual data model, when you see an entity type called car, then you
should think about pieces of metal with engines, not records in databases.
As a result, conceptual data models usually have few, if any, attributes.
What would often be attributes may well be treated as entity types or relationship
types in their own right, and where information is considered, it is considered as
an object in its own right, rather than as being necessarily about something else.
A conceptual data model may still be sufficiently attributed to be fully
instantiable, though usually in a somewhat generic way.
Canonical Data Model
In the context of data models, a canonical data model means a data
model that is fully normalized and in which no derived data is held.
So a logical data model might or might not also be a canonical data
model.
Application Data Model
An application data model is (obviously) one that relates to a particular
application.
It may be any or all of the following data models: conceptual, logical,
physical, or canonical.
Business Requirements Data Model
The purpose of a business requirements data model is to capture and
reflect a statement of business requirements. For such a model, it is
important that the notation is simple and easily understood.
This data model will form a basis for further analysis, so it does not
need to capture all the detail.
It can also function as a useful framework for capturing business rules
as part of the definition of the entity types. So this type of data model
is essentially a simplified conceptual data model—perhaps without
cardinalities and without taking account of change over time, since
most users do not understand their implications.
A business requirements data model
for part of an order data model.
Integration Data Model
An integration data model integrates a number of separate
applications.
In order to do this, it needs to be instantiable. Its scope is usually either
all the data for the applications it integrates or any data that is shared
between at least two of these applications.
You can also use an integration data model to share data between
enterprises, for example, in the supply chain.
Enterprise Data Model
An enterprise data model is a type of integration model that covers all
(well, probably most in practice) of the data of an enterprise.
Your Enterprise Architecture may include enterprisewide data models
that are also conceptual, logical, or physical data models.
For most types of data model, it is fairly obvious when you need to
develop them. Enterprise data models, however, seem to be the
exception. There are many cases where enterprise data model projects
have been abandoned, or where the results have languished unused,
even when what was asked for has been delivered.
Business Information Model
Business information models are a type of application data model that
is used in data warehouses for reporting and slicing and dicing your
transaction data.
Instead of being normalized in their structure, these models are
arranged in terms of “facts” (transactions, typically), and the
“dimensions” (such as time, geography, or product lines) used to
specify reports.
Business Information Model
The simplest structure is a “star” pattern, with a fact or group of facts in
the middle, and dimensions radiating out from there. More complex
structures resemble “snowflakes.” There are some special rules that
apply to business information models;

for example, only hierarchical relationship types are allowed, otherwise

as you summarize up the relationships, your data may get counted
more than once. On the other hand, at different levels in the hierarchy,
you may use different relationship types for summarization.
Data Usage Model (Data Flow
Diagram)
A data usage model shows where data is created and used by which
processes.
Some examples of data usage models are CRUD (create, read, update,
delete) matrices and data flow diagrams.
It is these that show how the process and data models interact with
each other.
One of the challenges here is that the processes in a data usage model
may themselves be things about which we wish to hold information, so
you need to recognize that a process in such a model may also be
represented in an entity-relationship model.
A Venn diagram showing the
different types of data model.
Integration of Data and Data Models
Overview of the Model Integration Process: The model integration process takes a
number of application models and an integration model.
It ensures that all the concepts of the application models are represented in the
integration model, and it develops a mapping specification between the integration
model and each of the application models.
There are three possible cases for the integration process:
1. The integration model and the application models both exist before the integration
process starts.
2. The application models to be integrated exist before the integration process starts,
but the integration model does not.
3. The integration model exists before the integration process starts, but the
application model needs to be developed from some statement of requirements.
DATA MODELS AND ENTERPRISE
ARCHITECTURE
The Business Process Model
System Independent Processes A system independent process is a
process that achieves some business objective, defined in a manner
that is independent of any system that might be used to support the
process. The process creates or changes things that are either
information or physical objects.
System Interactions
A system interaction is a process that involves a person interacting with
a computer system, such as when he or she enters data. System
interactions are used to define the workflow of how the results of
business processes are recorded in computer systems.
Automated Processes
An automated process is a process that is carried out by a computer
system or some other means of automation. Automated processes are
used to document and define the processes performed by computer
systems.
Information Architecture
Key Performance Indicators (KPI)
A key performance indicator (KPI) is a measure of the performance of a
business process.
KPIs are used by the business to assess the businesses performance of
some process.
Information Architecture
• Enterprise Data Model
An enterprise data model is a data model independent of any
implementation, and at a canonical level (no derived data).
It is documented in the terms of the enterprise, rather than the terms
of the systems used.
Information Architecture
Physical Data Models
A physical data model is a data model of how some system stores data.
Where the true table structure is obscure, a data model of how the
system is perceived from human and automatic interfaces may also be
appropriate.
Information Architecture
Integration Architecture
An integration architecture consists of the interfaces between systems
and the data model of the interfaces.
An integration architecture is used to understand the impact of a
change in one system on the interfaces between systems and the
consequent changes to the interfaces and perhaps other systems.
Information Operations
Reference Data
Reference data (some call this master data) is data that is about the key
things in the business and the static data used to describe things such
as units of measure. Reference data is used to identify transactions, to
summarize and report transactions, and to index documents.
Information Operations
Transactions
Transactions represent the execution of an activity and the information
that describes it.
Transactions are used to record the business conducted by the
enterprise.
Information Operations
Reports
A report is a record of performance that may include summary or
calculated data. A report may be complex, such as a pivot table or cube
that can be used to slice and dice data. Reports are used to provide
information to the enterprise to support decision making processes and
enterprise improvement.
Information Operations
Interface Operations
• An interface operation is the movement of data from one system to
another using a defined interface.
End