Data Modeling Fundamentals

Data Modeling
Fundamentals
© Copyright 2022 by Peter Aiken Slide # 1
peter.aiken@anythingawesome.com +1.804.382.5957 Peter Aiken, PhD
Achieving common understanding
Peter Aiken, Ph.D.
• I've been doing this a long time
• My work is recognized as useful
• Associate Professor of IS (vcu.edu)
• Institute for Defense Analyses (ida.org)
• DAMA International (dama.org)
• MIT CDO Society (iscdo.org)
• Anything Awesome (anythingawesome.com)
• Experienced w/ 500+ data
management practices worldwide
• Multi-year immersions
– US DoD (DISA/Army/Marines/DLA)
– Nokia
– Deutsche Bank
– Wells Fargo
– Walmart
– HUD …
• 12 books and
dozens of articles
https://anythingawesome.com
+
• DAMA International President 2009-2013/2018/2020
• DAMA International Achievement Award 2001
(with Dr. E. F. "Ted" Codd
• DAMA International Community Award 2005

• What is data modeling good for?
– Precisely defining data
– Achieving simplification goals
– Focused points of agreement
– Increasing understanding–systems to humans
– Understanding, building & deploying stable business models/strategy
• Why model data?
– Why model anything?
– Data requires precise definitions/agreements/understandings
– Suboptimal data practices accumulate data debt
– Data modeling describes important details about data that must be perfect
– Should be considered from a primarily iterative development context
– Understand and document data organization
• How using data models effectively
– Leverages a standard communication form
– Reduces corrosive anomalies
– Keeps focus on motivation using purpose statements
– Captures and communicates vital business information
– Forward engineering (Goal=Development/Building)
– Reverse engineering (Goal=Understanding)
• Take Aways, References, Q&A
DataModeling
Fundamentals
Achievingcommonunderstanding
Program
Data
Data
Data
Information
Fact Meaning
Request
A model precisely defining 3 important concepts
© Copyright 2022 by Peter Aiken Slide #
[Built on definitions from Dan Appleton 1983]
Intelligence
Strategic Use
Data
Data
Data Data
4
“You can have data without information, but
you cannot have information without data”
— Daniel Keys Moran, Science Fiction Writer
1. Each FACT combines with one or more MEANINGS.
2. Each specific FACT and MEANING combination is referred to as a DATUM.
3. An INFORMATION is one or more DATA that are returned in response to a specific REQUEST
4. INFORMATION REUSE is enabled when one FACT is combined with more than one MEANING.
5. INTELLIGENCE is INFORMATION associated with its STRATEGIC USES.
6. DATA/INFORMATION must formally arranged into an ARCHITECTURE.
Wisdom & knowledge are
often used synonymously
Useful Data

Payroll Application
(3rd GL)
Payroll Data
(database)
R& D Applications
(researcher supported, no documentation)
R & D
Data
(raw) Mfg. Data
(home grown
database)
Mfg. Applications
(contractor supported)
Finance
Data
(indexed)
Finance Application
(3rd GL, batch
system, no source)
Marketing Application
(4rd GL, query facilities,
no reporting, very large)
Marketing Data
(external database)
Personnel App.
(20 years old,
un-normalized data)
Personnel Data
(database)
Typical System Evolution
Payroll Data
(database)
R & D
Data
(raw)
Mfg. Data
(home grown
database)
Finance
Data
(indexed)
Marketing Data
(external database)
Personnel Data
(database)
... Then Integrate
Organizational
Data

Application 4
Application 5
Application 6
Application 1
Application 2
Application 3
Payroll Data
(database)
R & D
Data
(raw)
Mfg. Data
(home grown
database)
Finance
Data
(indexed)
Marketing Data
(external database)
Personnel Data
(database)
... Then Re-architect
Organizational
Data
How many interfaces are required to solve this integration problem?
Application 4 Application 5 Application 6
RBC: 200 applications - 4900 batch interfaces
8
15 Interfaces
(N*(N-1))/2

The rapidly increasing cost of complexity
0
10000
20000
1 101 201
Number of Silos
Worst case number of interconnections
N
• 6 / 15
• 60 / 1,770
• 600 / 179,700
• 200 / 19,900
• 200 / 5,000
(actual)
10
Point to Point Integration

Spoke and Hub Integration
HUB
(Data model-based)
Data models …
• Capture and maintain formal (usually physical)
system data requirements
– An organized, purposeful structure regarded as a whole
and consisting of interrelated/interdependent elements
http://www.businessdictionary.com/definition/system.html#ixzz23T7LyAjJ
• Represent the lowest level of decomposition
available in systems
– People
– Processes
– Hardware
– Software
– Data
• Are by necessity, the most stable system
component over time
• Incorporate organizational business rules
– Can a project be owned by more than one department?
If it isn't correct at the data model representation, all other interpretations must be suspect
System
Data
Hardware
Processes
People Software Data

Minimize Interconnections
• As few HUBs as possible explicitly
balancing various aspects of risk
– Single point of failure
– Easier to steal
– Easier to manage
• A data model is at the heart of every HUB
– Only reliable means of conveying the enormous amount
of information required to run HUB for organizations
– Also, objective use of standards within and
across organizations
– Can always be inferred or determined objectively
• Data modeling is not considered a necessary IT skill
– Business and IT decision makers are
unknowledgeable about data decisions
– IT assigns responsibility for data to the business
– Confusion has reigned for decades
– Data debt has accumulated as a result
https://anythingawesome.com 13
Today's IT environment
Software App 1
(in cloud a)
Software App 2
(in cloud b)
Software App 3
(in cloud c)
Software App 4
(legacy on prem)
Software App 5
(legacy on prem)
Software App 6
(legacy on prem)
An organization's
data models map
between and across
software packages in
and out of the cloud

Understanding a data model
• Documented and articulated
as a digital blueprint of the
commonalities and
interconnections
among specific
entity and attribute
combinations
• Shared by systems and
humans
Definitions
• Data Modeling
– The process of discovering, analyzing, and
scoping data requirements, and then
– Representing and communicating the data
requirements in a precise form called a data model.
– Is used to design data structures that support the specifications
• Model
– A representation of something that exists or a pattern for something to be made
– A model can contain one or more diagrams
– Model diagrams using standard symbols that allow one to understand content
– Maps, org charts, and building blueprints are examples of models in used daily
• Data Model
– Analysis and design method used to define and analyze data requirements
– Integrated collection of specifications and related diagrams that represent data
requirements and design
– Employs standardized text/symbols to represent data attributes (grouped into
data elements) and the relationships among them
from The DAMA Guide to the Data Management Body of Knowledge V2 © 2013 by DAMA International

Stable (thus) Shareable Business & Data Models
• Represent stable
sharable data
– Data models are
required to share
data or information
about data
– Using mutually
understood
definitions
– Candidate enterprise
standard data
• Support stable
business models
– Data models are
skeleton of the
business
architecture
– They would form the
'bones' of a garden)
– Data organizations
have remained the
most stable business
architecture
component across
my 40+ year career
• Are required as a
condition of
deployment
– Cannot launch/
deploy without
something
– Many are not as
organizationally
useful as they could
be (representing
quantifiable
opportunity costs)
– Consider a basic
part of any system
documentation
– Often missing
https://en.wikipedia.org/wiki/Data_model#/media/File:3-4_Data_model_roles.svg
• Flexible, adaptable data structures
• Cleaner, less complex code
• Ensure strategy effectiveness measurement
• Build in future capabilities
• Form/assess merger and acquisitions strategies
– For example: it was a poor design choice to require an employee to be either as
salesperson or a manager (there is not structural support for managerial sales)
– This decision 'haunted' the organization until the system was replaced
Data Models Used to Support Strategy
Employee
Type
Employee
Sales
Person
Manager
Manager
Type
Staff
Manager
Line
Manager
Adapted from Clive Finkelstein Information Engineering Strategic Systems Development 1992

• Why model data?
DataModeling
Fundamentals
Program
Diagram from Ellen Gottesdiener www.ebgconsulting.com
draw
critique
test
dialog
select
decide
filter
summarize
design
rank
review cluster
generate evaluate
list
visible to participants
Structure
for
organizing
things
Framework for
decision making
Requires tools for problem solving and
decision making
Easy to review and validate
graphic
text
Prototype and mockup
Framework for understanding and design
20
What a model is

https://www.youtube.com/watch?v=JsIgubUjTck
• Represent expertise
• Store and formalize information
• Filter out extraneous detail
• Define an essential set of
information
• Help understand complex
system behavior
• Monitor/predict system
responses to changing
environmental conditions
• Communicate more effectively/
efficiently
➡ Novice/expert
➡ Business/technical
➡ Human/software
• Streamline documentation
• Monitor and predict system
responses to changing
conditions
• Gain information from the
process of developing and
interacting with the model
• Evaluate various scenarios or
other outcomes indicated by the
model
• Understand behaviors
• Illustrating patterns and
metapatterns
Illustrating
Model
Utility
Why Model?
• Would you build a house without an
architecture sketch?
• Model is the sketch of the system to be
built in a project.
• Would you like to have an estimate how
much your new house is going to cost?
• Your model gives you a very good idea of
how demanding the implementation work
is going to be!
• If you hired a set of constructors from all
over the world to build your house, would
you like them to have a common
language?
• Model is the common language for the
project team.
• Would you like to verify the proposals of
the construction team before the work gets
started?
• Models can be reviewed before thousands
of hours of implementation work will be
done.
• If it was a great house, would you like to
build something rather similar again, in
another place?
• It is possible to implement the system to
various platforms using the same model.
• Would you drill into a wall of your house
without a map of the plumbing and electric
lines?
• Models document the system built in a
project. This makes life easier for the
support and maintenance!
powerpivotpro.com

Data Models Exist (whether you like it or not)
deviantart.com
• All system have
data models
– Some are better
understood and
documented (and
therefore more
useful to the
organization) than
others
Doing a poor job with data
• Failure to understand data models of
proposed and existing software/services
– Locks in imperfections for the life of the application
– Restricts data investment benefits
– Decreases organizational data leverage
• Accounts for 20-40% of IT budgets
devoted to evolving
– Data migration (Changing the data location)
– Data conversion (Changing data form, state, or product)
– Data improving (Inspecting and manipulating, or re-keying
data to prepare it for subsequent use)
• Bad data models cause everything else to
– Take longer
– Cost more
– Deliver less
– Present greater risk (with thanks to Tom DeMarco)

Data Debt – Getting Back to Zero
• Data debt
– The time and effort it will
take to return your data to a
governed state from its
likely current state of
ungoverned.
• Getting back to zero
– Involves undoing existing stuff
– Likely new skills are required
• At zero-must start from scratch
– Typically requires annual proof of
value
• Now you need to get good at
both
– Almost all data challenges involve
interoperability
– Little guidance at optimizing data
management practices
– Very little at getting back to zero
You must address data debt
• Slows progress
• Decreases quality
• Increases costs
https://www.merkleinc.com/blog/are-you-buried-alive-data-debt
https://johnladley.com/a-bit-more-on-data-debt/
https://uk.nttdataservices.com/en/blog/2020/february/how-to-get-rid-of-your-data-debt

Running
Query
Optimized Query

Repeat 100s, thousands, millions of times ...
D E A T H
B Y A
T H O U S A N D
C U T S
w o r k i n g
w h i l e
b l e e d i n g
p r o f u s e l y

bleeding
unnecessarily
from a lot of
cuts
$$$cuts$$$
2020 American Airlines market value ~ $6b
AAdvantage valued between $19.5-$31.5b
2020 United market value ~ $9b
MileagePlus ~ $22b
https://www.forbes.com/sites/advisor/2020/07/15/how-airlines-make-billions-from-monetizing-frequent-flyer-programs/?sh=66da87a614e9

Data modeling
• The process of discovering, analyzing, and scoping data
requirements
– Understand what the data things are?
– What do they do?
– How do they interact?
• Representing/communicating requirements
in a precise form called a data model
– Maps of critical business assets
– Compose and contain metadata essential
to data consumers
– Function as a kind of sheet music language
– Metadata is essential to other business functions
(definitions for governance, lineage for analytics, etc.)
• The process is iterative and may include a
conceptual, logical, and physical model
process of discovering, analyzing, and scoping data requirements
• For organizational places
• These are called Attributes
– Attributes are characteristics of "things"
• For organizational places
persons
places
things
created
read
updated
deleted
archived
whose
information
needs to be

process of discovering, analyzing, and scoping data requirements
• An organization might decide to
characterize the parts of a THING as:
– Attributes: ID, description, status,
sex.to.be.assigned, reserve.reason
• Decisions to manage information
about each specific attribute has
direct consequences
– A decision to use the above data
attributes permits the organization to
determine if it has female THINGs are available to be reserved
• Characteristics can be shared
– All THINGs may have a status
– Many THINGs can be assigned to females
• Characteristics may be required to be unique
– ID permits identification every THING as distinct for every other THING
– Description is likely to be unique for each THING
THING
Thing.Id #
Thing.Description
Thing.Status
Thing.Sex.To.Be.Assigned
Thing.Reserve.Reason
Attributes arranged into an
entity named "thing" – the
attribute Thing.Id is the means
used to identify a unique
occurrence of thing
Data modeling
• The process of discovering, analyzing, and scoping data
requirements
• representing/communicating requirements
– Compose and contain metadata essential
to data consumers
(definitions for governance, lineage for analytics, etc.)

representing/communicating requirements in a precise form called a data model
• Q: What is an Attribute?
– A characteristic of an instance
in a collection of business things
about which we create, read,
update, and delete information
– In this example, the attribute
"club id" tells us much about
this data collection
• What does the existence
of this attribute tell us?
– Clubs need to be identified (#)
separately from one another
– Club-specific information is
likely maintained
– Some concept (organization)
exists above the 'club level'
– ...
Club
—————
Club ID #
…
Club
—————
Club ID #
…
Attribute Definition
• Attributes describe an entity
• Attribute values are characteristics of “instances of business things”
Club
—————
Club ID #
…
Club
—————
Club ID #
current promotion
Maximum period of obligation
number cancelled ytd
number of members
total units sold for club
…

• Entities organized into a poorly
designed model
• What is a Relationship?
– Natural associations between two
or more entities
Relationships specify entity connections
Club
—————
Club ID #
current promotion
Maximum period of obligation
number cancelled ytd
number of members
total units sold for club
…
ClubMember
—————
ClubMember ID #
Club member first name
Club member last name
Club member net worth
…
ClusterConnector
—————
ClubMember ID #
Club ID #
…
Families of Modeling Notation Variants
Information Engineering
! Most pick this

Eventually One or Many (optional)
Eventually One (optional)
Zero, or Many (optional)
One or Many (mandatory)
Exactly One (mandatory)
Possible Entity Relationship Cardinality Options
• Defines mandatory/optional relationships using minimum/
maximum occurrences from one entity to another
• Flaws in this example
– How does a patient occupy
more than one bed?
– What if a bed is moved?
– What is a room?
Ordinality and Cardinality Refine Relationships
A BED is placed
in one and only
one ROOM
A ROOM
contains zero
or more BEDS
A BED is occupied by
zero or one PATIENT
A PATIENT
occupies at least
one or more BEDS
PATIENT
Patient
Room
Bed

representing and communicating these in a precise form called a data model
Thing.Id #
Thing.Description
Thing.Status
Thing 1
Thing.Id #
…
Thing 2
Each THING 2 must be accompanied by a THING 1
Bed Room
Data Maps at the Entity Level ➜ Stored Facts
Bed Room
a BED is related to a ROOM
More precision:
many BEDS are related to many ROOMS
Bed Room
Better information:
many BEDS may be contained in each ROOM and each room may contain many beds
What if beds can
be moved?

Data modeling
• The process of discovering, analyzing, and
scoping data requirements
– Compose and contain metadata essential to data
consumers
(definitions for governance, lineage for analytics,
etc.)
!

!

!

!

46
Organizational Needs
become instantiated
and integrated into
Data Models
Informa(on)System)
Requirements
authorizes and
articulates
satisfy
specific
organizational
needs
The process is iterative
Data models are developed in
response to specific requirements

Data modeling
consumers
etc.)
ANSI-SPARC 3-Layer Schema
1. conceptual - Allows independent
customized user views:
– Each should be able to access the same
data, but have a different customized view of
the data.
2. logical - Hides the storage details
from users:
– Users should not have to deal with physical
database storage details. They should be
allowed to work with the data itself, without
concern for how it is physically stored.
3. physical - The database should be
able to change the database storage
structures without affecting the users’
views:
– Changes to the structure of an organization's
data will be required. The internal structure
of the database should be unaffected by
changes to the storage
For example, a changeover to a
new DBMS technology. The
database administrator should
be able to change the global
structure of the database
without affecting the users.

Data modeling
consumers
etc.)
Each data arrangement is a data structure
Data structure characteristics
• Grammar for data objects
– Grammar is the principles
or rules of an art, science,
or technique "a grammar
of the theater"
Constraints for data objects
• Uniqueness
• Order
– Hierarchical
– Relational
– Sequential
– Network
– Lake
– other
• Balance
• Optimality
http://www.nist.gov/dads/HTML/datastructur.html
"An organization of information, usually in
memory, for better algorithm efficiency, such
as queue, stack, linked list, heap, dictionary,
and tree, or conceptual unity, such as the
name and address of a person. It may include
redundant information, such as length of the
list or number of nodes in a subtree."
The fewer the better!

How are components expressed as data models?
• Details are
organized into
larger components
• Larger
components are
organized into data
models
• Data models are
organized into
architectures
A B
C D
A B
C D
A
D
C
B
Intricate
Dependencies
Purposefulness
How are data models expressed as architectures?
• Attributes are organized into entities/
objects
– Attributes are characteristics of "things"
– Entitles/objects are "things" whose
information is managed in support of strategy
– Example(s)
• Entities/objects are organized into models
– Combinations of attributes and entities are
structured to represent information requirements
– Poorly structured data, constrains organizational
information delivery capabilities
– Example(s)
• Models are organized into architectures
– When building new systems, architectures are
used to plan development
– More often, the business cannot make use of
them in support of strategy implementation
because the architectures are not understood
Intricate
Dependencies
Purposefulness
THING
Thing.Id #
Thing.Description
Thing.Status

Metadata
Management
53
Data
Management
Body
of
Knowledge
(DM
BoK
V2)
Practice
Areas
from The DAMA Guide to the Data Management Body of Knowledge 2E © 2017 by DAMA International
• Analysis
• Database Design
• Implementation
• Additional data
development
• Why model data?
DataModeling
Fundamentals
Program

Where are your
(data) blueprints?
There are correct ways to organize data
• Optimization can be done for:
– Flexibility
– Adaptability
– Retrievability
– Risk reduction
– ...
• Techniques include:
– Data integrity
– Smart codes bad/dumb codes good
– Architecture (table joins)
– ...

How Should it be Done? (Smart codes bad, dumb codes good)
• 804 → N zero N → long distance call signaling
– All telephone switching equipment (hardware) had to
be changed to not route calls to long distance if the
hardware 'saw' a zero in the middle of a 3 digit number
• Course listings
– "You can not add another
undergraduate business
computer course"
• A large organization has to
expand a primary master
data item by a number of digits
– Requires upwards of 100,000 changes to be managed
BUS360
Business
Computer
Courses
BUS361
BUS362
BUS363
BUS364
BUS365
BUS366
BUS367
BUS368
BUS369
BUS3??
https://www.youtube.com/watch?v=_f1gwAGfZs0&frags=pl%2Cwn
Table Handling
• A table is a collection of data items that have the
same description, such as account totals or monthly averages; it
consists of a table name and subordinate items called table
elements.
– Under representation of other database characteristics causes confusion and
introduces risk to organizational data capabilities
• In this example, the table consists of
Song, Album
• and length?
• No, iTunes uses
– Song Start Time
– Song Stop Time
• More flexible
and less risky
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/tasks/tptbl02.htm

(a hypothetical portion of the) iTunes Music database
• What information is lost if we delete record #1?
Record Purchaser ID Song Price
1 Purchaser #1 Cool Walk (Live) $1.99
2 Purchaser #1 Sushi (Live) $1.29
3 Purchaser #1 Love Ballade (Live) $0.99
4 Purchaser #2 A Salute to Bach (Medley) $0.99
Music database: Deletion Anomaly
• Question
– What information is lost if we delete record #1?
• Answer
– We loose the fact that "Purchaser #1" purchased "Cool Walk (Live)"
– We loose the fact that "Cool Walk (Live)" costs $0.99
• This is usually undesirable and unintended

Music database: Insertion Anomalies
• Question:
– Suppose we want to add new song "Cakewalk (Live)" and that it costs $1.29?
– This is fact #1
• Answer:
– Cannot enter it until some future purchaser buys a copy of the song - Fact #2
– We cannot insert a full row until we have an additional fact about that row
– This is usually undesirable and unintended
5 Purchaser #? Cakewalk (Live) $1.29
Fact #2
Fact #1
Music database: Update Anomalies
• Question:
– Suppose we want to change the price of "Cool Walk (Live)"
from $1.99 to $1.29?
• Answer:
– Change to data items such as Song requires examination of every single record
– Will not catch spelling errors - such as "Coolwalk (Live)"
– This is usually undesirable and unintended
5 Purchaser #3 Coolwalk (Live) $1.99

How Should it be Done? (In General)
• As much as possible,
store 1 fact per row
– Row 2 is a good example
as it shows both that
Purchaser #1 has
purchased Sushi (Live) and
that it costs $0.99
– These are two distinct facts and are correctly stored in two tables sharing a
formal relationship
– More remains codes
PURCHASES
Row Purchaser ID Song
1 Purchaser #1 Cool Walk (Live)
2 Purchaser #1 Sushi (Live)
3 Purchaser #1 Love Ballade (Live)
4 Purchaser #2 A Salute to Bach (Medley)
5 Purchaser #3 Coolwalk (Live)
6 Purchaser #3 A Salute to Bach (Medley)
ORIGINAL
Record Purchaser ID Song Pric
e
4 Purchaser #2 A Salute to Bach
(Medley)
$0.99
5 Purchaser #3 Coolwalk (Live) $1.99
PRICING
Record Song Price
1 Cool Walk (Live) $1.99
2 Sushi (Live) $0.99
3 Love Ballade (Live) $0.99
4 A Salute to Bach
(Medley)
$0.99
5 Coolwalk (Live) $1.99
Definition of Bed

Standard definitions might not provide sufficient context
BED
Something you sleep in
Purpose statement incorporates motivations
Entity: BED
Data Asset Type: Principal Data Entity
Purpose: This is a substructure within the Room
substructure of the Facility Location. It contains
information about beds within rooms.
Source: Maintenance Manual for File and Table
Data (Software Version 3.0, Release 3.1)
Attributes: Bed.Description
Bed.Status
Bed.Sex.To.Be.Assigned
Bed.Reserve.Reason
Associations: >0-+ Room
Status: Validated
Draft
Missing Bed.Transponder.Id?
A purpose statement describing
– Why the organization is maintaining information about this business concept;
– Sources of information about it;
– A partial list of the attributes or characteristics of the entity; and
– Associations with other data items (read as "One room contains zero or many beds.")

Data Representation is the Essence of Programming
• Mythical Man Month
– 9 parallel effort x 1 month each ≠ baby
• Fred Brooks Jr.'s observation
– Data representation is the essence of programming
– "Show me your flowchart and
conceal your tables, and
I shall continue to be mystified.
– Show me your tables, and
I won't usually need your flowchart;
it'll be obvious."
• Process
– Used to define, analyze, and understand data requirements
– Some purpose
• Constrained
– Needs to support specific business processes
– Corresponding information systems
• Intent
– Must be done to answer a specific question
• Variations
– Permit efficiencies
from The DAMA Guide to the Data Management
Body of Knowledge © 2009 by DAMA International
Primary
deliverables
become reference
material
Model Purpose Statement:
This model codifies the official
vocabulary to be used when
describing aspects of any of the
following organizational concepts:
– Subscriber
– Account
– Charge
– Bill
Data
Modeling
Example #1

Data Modeling Example #2
fuel
rent-rate
phone-rate
phone-call
rental
agreement
customer
auto
repair
history
phone-unit
Source: Chikofsky 1990
69
– fuel
– customer
– auto
– rental agreement
– rent-rate
– phone-call
– phone-rate
– phone-unit
– repair history
It is documentation shown
during the on-
boarding process
Interpretations:
1. Car rental company
2. Rental agreement is central
3. No direct connection between
customer and contract
4. Contract must have a
customer
5. Nothing structural prevents
autos from being rented to
multiple customers
6. Phone units are tied to rentals
Data Modeling Example #3
salesperson
name
commission
rate
invoice # amount date paid
customer
name
address
customer #
date
order #
price
quantity
order #
item #
quantity
on hand
description
supplier
item # cost
SALESPERSON
INVOICE
ORDER
CATALOG
LINE ITEM
70
• Sales commission-based pricing information
• Difficult to change a customer address
• Price not included in the catalog
• Easy to implement variable pricing - difficult to implement
standard pricing - is standard pricing implemented
• Sales person information is not directly tied to the order
• Do sales people sell things that are shipped quickly so they get
their commission quicker?
• Nothing prohibits a sales from having multiple
sales persons
• Multiple invoices are allowed for a single order
• Partial shipment is allowed
• Data base cannot tell what part of an order the
invoice pertains to
vocabulary and specific
operational rules to be used when
– salesperson
– invoice
– order
– line item
– catalog

describing disposition related organizational concepts:
– user
– admission
– discharge
– encounter
– facility
– provider
– diagnosis
71
Data Model #4: DISPOSITION
• At least one but possibly more system USERS enter the
DISPOSITION facts into the system.
• An ADMISSION is associated with one and only one
DISCHARGE.
• An ADMISSION is associated with zero or more
FACILITIES.
• An ADMISSION is associated with zero or more
PROVIDERS.
• An ADMISSION is associated with one or more
ENCOUNTERS.
• An ENCOUNTER may be recorded by a system USER.
• An ENCOUNTER may be associated with a PROVIDER.
• An ENCOUNTER may be associated with one or more
DIAGNOSES.
72
ADMISSION Contains information about patient admission
history related to one or more inpatient episodes
DIAGNOSIS Contains the International Disease Classification
(IDC) of code representation and/or description
of a patient's health related to an inpatient code
DISCHARGE A table of codes describing disposition types
available for an inpatient at a FACILITY
ENCOUNTER Tracking information related to inpatient
episodes
FACILITY File containing a list of all facilities in regional
health care system
PROVIDER Full name of a member of the FACILITY team
providing services to the patient
USER Any user with access to create, read, update,
and delete DISPOSITION data
episodes
health care system
episodes
health care system
Death must be a disposition code!
Data Model #4: DISPOSITION

Modeling Options
O-1 data implementation (e.g., by recreating descriptions of implemented file
layouts);
O-2 data designs (e.g., by recreating the logical system design layouts); or
O-3 information requirements (e.g., by recreating existing system specifications and
business rules).
O-4 data design assets by examining the existing data implementation (when
appropriate O-1 can facilitate O-4); and
O-5 system information requirements by reverse engineering the data design O-4.
(Note: if the data design doesn't exist O-4 must precede O-5.)
O-6 transforming as is data design assets, yielding improved to be data designs
that are based on reconstituted data design assets produced by O-2 or O-4
and (possibly O-1);
O-7 transforming as is system requirements into to be system requirements that are
based on reconstituted system requirements produced by O-3 or O-5 and
(possibly O-2);
O-8 redesigning to be data design assets using the to be system requirements
based on reconstituted system requirements produced by O-7; and
O-9 re-implementing system data based on data redesigns produced by O-6 or
O-8.
As Is Information
Requirements
Assets
As Is Data Design Assets As Is Data Implementation
Assets
Existing
New
Forward and Reverse Data Engineering
O2 Recreate
Data Design
Reverse Engineering
Forward engineering
O5 Reconstitute
Requirements
O9
Reimplement
Data
To Be Data
Implementation
Assets
O8
Redesign
Data
O4
Recon-
stitute
Data
Design
O3 Recreate
Requirements
O6
Redesign
Data
To Be
Design
Assets
O7 Re-
develop
Require-
ments
To Be
Requirements
Assets
O1 Recreate Data
Implementation
Metadata
74

As Is Requirements
Assets WHAT?
As Is Design Assets
HOW?
As Is Implementation
Assets AS BUILT
Forward Engineering
As Is Requirements
Assets WHAT?
As Is Design Assets
HOW?
Assets AS BUILT
Existing
Reverse Engineering
A structured technique aimed at recovering rigorous
knowledge of the existing system to leverage
enhancement efforts [Chikofsky & Cross 1990]

As Is Requirements
Assets WHAT?
As Is Design Assets
HOW?
Assets AS BUILT
Existing
New
Reengineering
Reverse Engineering
Forward engineering
Reimplement
To Be
Implementation
Assets
To Be
Design
Assets
To Be Requirements
Assets
• First, reverse engineering the existing system
to understand its strengths/weaknesses
• Next, use this information to inform the
design of the new system
Model Evolution (how not to do it but how it is always done)
As Is Information
Requirements
Assets
Assets
Existing
(AS-IS)
New
(TO-BE)
Reverse Engineering
Forward engineering
78

Model Evolution (better explanation)
As Is Information
Requirements
Assets
Assets
Existing
(AS-IS)
New
(TO-BE)
Reverse Engineering
Forward engineering
79
Other logical
as-is data
architecture
components
Technology
Dependent/
Physical
Technology
Independent/
Logical
Technology
Independent/
Logical
Technology
Dependent/
Physical
To-Be
• First, reverse engineering the existing system
to understand its strengths/weaknesses
• Next, use this information to inform the
design of the new system
Existing
(AS-IS)
New
(TO-BE)
Model Evolution
Conceptual Logical Physical
Validated
Not Validated
Every modeling change can be mapped
to a transformation in this framework!

Each cycle has an articulated purpose
Bed
Entity: BED
Purpose: This is a substructure within the room
substructure of the facility location. It
contains information about beds within rooms.
Attributes: Bed.Description
Bed.Status
Bed.Sex.To.Be.Assigned
Bed.Reserve.Reason
Associations: >0-+ Room
Status: Validated
Keep them focused on data model purpose
• The reason we are locked in this
room is to:
– Mission: Understand formal
relationship between soda and
customer
• Outcome: Walk out the door with a data model
this relationship
– Mission: Understand the
characteristics that differ between
our hospital beds
• Outcome: We will walk out the door when we
identify the top three characteristics required to
manage hospital beds.
– Mission: Could our systems handle the
following business rule tomorrow?
– "Is job-sharing permitted?"
• Outcomes: Confirm that it is possible to staff a
position with multiple employees effective
tomorrow
selects and pays for
given to
Soda
Customer
selects
can be filled by zero or 1
Employee Position
has exactly 1
How does our
perspective change:
the primary means of
tracking a patient

Don’t Tell Them That You Are Modeling!
Then make some
appropriate connections
between your objects
Just write some stuff down
Then arrange it
Data Modeling Process
1. Identify entities
2. Identify key for
each entity
3. Draw rough draft
of entity
relationship data
model
4. Identify data
attributes
5. Map data
attributes to
entities

Model evolution is good, at first ...
1. Identify entities
2. Identify key for
each entity
3. Draw rough draft
of entity
relationship data
model
4. Identify data
attributes
5. Map data
attributes to
entities
Relative use of time allocated to tasks during modeling
Preliminary Modeling Wrapup
Activity activities Cycles activities
Evidence Analysis
collection &
analysis Collection
Project
coordination
requirements Declining coordination requirements
Target
system
analysis Increasing amounts of target system analysis
Modeling Validation
cycle
focus Refinement

Source:http://dmreview.com/article_sub.cfm?articleID=1000941 used with permission
Meta Data Models
Data Modeling for Business Value
• Goal must be shared IT/business understanding
– No disagreements = insufficient communication
• Data sharing/exchange is automated and
dependent on successful engineering/architecture
– Requires a sound foundation of data modeling basics
(the essence) on which to build technologies
• Modeling characteristics evolve during the analysis
– Different model instances may be useful to different analytical problems
• Incorporate motivation (purpose statements) in all modeling
– Modeling is a problem defining as well as a problem solving activity
• Use of modeling is more important than selection of a specific
method
• Models are often living documents
• Models need to be available in an easily searchable manner
• Utility is paramount
– Adding color and diagramming objects customizes models and allows for a more
engaging and enjoyable user review process
Inspired by: Karen Lopez http://www.information-management.com/newsletters/enterprise_architecture_data_model_ERP_BI-10020246-1.html?pg=2

Event Pricing
• 20% off
directly from the
publisher
on select titles
• My Book Store @
http://anythingawesome.com
• Enter the code
"anythingawesome" at
the Technics bookstore
checkout where it says to
"Apply Coupon"
anythingawesome
[ Clicking any webinar title will link directly to the registration page ]
Upcoming Events
Data Stewards: Defining and Assigning
8 March 2022
Essential: Reference and
Master Data Management
12 April 2022
Key Elements of a Successful Data Governance
8 May 2022
Brought to you by:
Time: 19:00 UTC (2:00 PM NYC) | Presented by: Peter Aiken, PhD

Peter.Aiken@AnythingAwesome.com +1.804.382.5957
Thank You!
Book a call with Peter to discuss anything - https://anythingawesome.com/OfficeHours.html

Data Modeling Fundamentals

More Related Content

What's hot (20)

Similar to Data Modeling Fundamentals (20)

More from DATAVERSITY (20)

Recently uploaded (20)

Data Modeling Fundamentals