P A G E 1

Data Modelling for the BusinessThe Critical Role of a Conceptual Data Model

C H R I S T O P H E R B R A D L E Y ( C D M P F E L L O W )

chris.bradley@dmadvisors.co.uk

P A G E 2

P / 3

Christopher BradleyI N F O R M AT I O N M A N A G E M E N T S T R AT E G I S T

Information Management, Life & Petrolhttp://infomanagementlifeandpetrol.blogspot.com

@InfoRacer

uk.linkedin.com/in/christophermichaelbradley/

+44 7973 184475 (mobile)

Chris.Bradley@DMAdvisors.co.uk

+44 1225 923000 (office)

P / 4

Christopher BradleyChris has 36 years of Information Management experience &

is a leading Independent Information Management strategy

advisor.

In the Information Management field, Chris works with

prominent organizations including HSBC, Celgene, GSK,

Pfizer, Icon, Quintiles, Total, Barclays, ANZ, GSK, Shell, BP,

Statoil, Riyad Bank & Aramco. He addresses challenges faced

by large organisations in the areas of Data Governance,

Master Data Management, Information Management

Strategy, Data Quality, Metadata Management and Business

Intelligence.

He is President of DAMA UK, DAMA- I DMBOK 2 author.

In April 2016 he became the inaugural CDMP Fellow, and

received the DAMA lifetime professional

achievement award.

He is an author & examiner for CDMP, a Fellow of the

Chartered Institute of Management Consulting (now IC) a

member of the MPO, and SME Director of the DM Board.

A recognised thought-leader in Information Management

Chris is the author of numerous papers, books, including

sections of DMBoK 2.0, a columnist, a frequent contributor

to industry publications and member of several IM

standards authorities.

He leads an experts channel on the influential

BeyeNETWORK, is a sought after speaker at major

international conferences, and is the co-author of “Data

Modelling For The Business – A Handbook for aligning

the business with IT using high-level data models”. He

also blogs frequently on Information Management (and

motorsport).

P / 5

Recent PresentationsDAMA Sydney: August 2016 Sydney; “Data Quality, The Impact of Dirty Data?”

DAMA Melbourne: August 2016 Melbourne; “Data Quality, Are You Feeling Lucky?”

DAMA Canberra: August 2016 Canberra; “Data Quality, Are You Feeling Lucky?”

Australian Computer Society (ACS): August 2016 Canberra; “Data Quality Matters For Machines Too”

MDM DG Europe: May 2016 London; “Data Governance by Stealth”

Webinar: May 2016; “Data Modelling is not JUST for DBMS design”

Enterprise Data World: April 2016 San Diego; “DAMA CDMP Workshop”

DAMA Webinar: April 2016; “Data Integration & Interoperability” Disciplines of the DAMA DMBoK”

DAMA Webinar: March 2016; “Document & Content Management” Disciplines of the DAMA DMBoK”

DAMA Webinar: February 2016; “Data Operations Management” Disciplines of the DAMA DMBoK”

Oil & Gas Data Management Conference: February 2016, London; “Developing An Information

Strategy To Align With In-Flight Business Programs”

DAMA Webinar: January 2016; “Data Governance” Disciplines of the DAMA DMBoK”

DAMA Webinar: December 2015; “Information Lifecycle Management” Disciplines of the DAMADMBoK”

DAMA Webinar: November 2015; “MetaData Management” Disciplines of the DAMA DMBoK”

Enterprise Data & BI Europe (IRM): November 2015, London; “Is the Data Asset really different?” & “CDMP Examination Preparation” & “Data Management Room 101”

DAMA Webinar: October 2015; “Data Risk & Security” Disciplines of the DAMA DMBoK”

DAMA Webinar: September 2015; “Data Warehousing & Business Intelligence” Disciplines of the DAMADMBoK”

DAMA Webinar: August 2015; “Data Quality Management” Disciplines of the DAMA DMBoK”

BCS & DAMA Seminar: June 2015; “Is the Data Asset really different?”

DAMA Webinar: June 2015; “Data Modelling” Disciplines of the DAMA DMBoK”

PRISME Pharmaceutical Congress: May 2015, Basel, CH; “Building & exploiting a Pharmaceutical Industry consensus data model”

MDM DG Europe (IRM): May 2015, London; “CDMP Examination Preparation” & “Data Governance By Stealth?, Can you ‘sell’ Data Governance if the stakeholders don’t get it?”

DAMA Webinar: April 2015; “Master & Reference Data Management” Disciplines of the DMBoK”

Enterprise Data World: April 2015, Washington DC USA; “Data Modelling For The Business” and “Evaluating Information Management Tools”

DAMA Webinar: February 2015; “An Introduction to the Information Disciplines of the DMBoK”

Dataversity Webinar: February 2015; “How to successfully introduce Master & Reference data management”

Petroleum Information Management Summit 2015: February 2015, Berlin DE, “How to succeed with MDM and Data Governance”

Enterprise Data & Business Intelligence 2014: (IRM), November 2014, London, UK “Data Modelling 101”

Enterprise Data World: (DataVersity), May 2014, Austin, Texas, “MDM Architectures & How to identify the right Subject

Area & tooling for your MDM strategy”

E&P Information Management Dubai: (DMBoard),17-19 March 2014, Dubai, UAE “Master Data Management

Fundamentals, Architectures & Identify the starting Data Subject Areas”

DAMA Australia: (DAMA-A),18-21 November 2013, Melbourne, Australia “DAMA DMBoK 2.0”,

“Information Management Fundamentals” 1 day workshop”

Data Management & Information Quality Europe: (IRM Conferences), 4-6 November 2013, London, UK; “Data Modelling Fundamentals” ½ day workshop: “Myths, Fairy Tales & The Single View” Seminar;

“Imaginative Innovation - A Look to the Future” DAMA Panel Discussion

IPL / Embarcadero series: June 2013, London, UK, “Implementing Effective Data Governance”

Riyadh Information Exchange: May 2013, Riyadh, Saudi Arabia; “Big Data – What’s the big fuss?”

Enterprise Data World: (Wilshire Conferences), May 2013, San Diego, USA, “Data and Process Blueprinting –A practical approach for rapidly optimising Information Assets”

Data Governance & MDM Europe: (IRM Conferences), April 2013, London, “Selecting the Optimum

Business approach for MDM success…. Case study with Statoil”

E&P Information Management: (SMI Conference), February 2013, London, “Case Study, Using Data Virtualisation for Real Time BI & Analytics”

E&P Data Governance: (DMBoard / DG Events), January 2013, Marrakech, Morocco, “Establishing a

successful Data Governance program”

Big Data 2: (Whitehall), December 2012, London, “The Pillars of successful knowledge management”

Financial Information Management Association (FIMA): (WBR), November 2012, London; “Data Strategy as a Business Enabler”

Data Modeling Zone: (Technics), November 2012, Baltimore USA; “Data Modelling for the business”

Data Management & Information Quality Europe: (IRM), November 2012, London; “All you need to know to prepare for DAMA CDMP professional certification”

ECIM Exploration & Production: September 2012, Haugesund, Norway:

“Enhancing communication through the use of industry standard models; case study in E&P using WITSML”

Preparing the Business for MDM success: Threadneedles Executive breakfast briefing series, July 2012,

London

Big Data – What’s the big fuss?: (Whitehall), Big Data & Analytics, June 2012, London,

Enterprise Data World International: (DAMA / Wilshire), May 2012, Atlanta GA,

“A Model Driven Data Governance Framework For MDM - Statoil Case Study”“When Two Worlds Collide – Data and Process Architecture Synergies” (rated best workshop in

conference); “Petrochemical Information Management utilising PPDM in an Enterprise Information

Architecture”

Data Governance & MDM Europe: (DAMA / IRM), April 2012, London, “A Model Driven Data Governance Framework For MDM - Statoil Case Study”

AAPG Exploration & Production Data Management: April 2012, Dead Sea Jordan; “A Process For

Introducing Data Governance into Large Enterprises”

PWC & Iron Mountain Corporate Information Management: March 2012, Madrid; “Information Management & Regulatory Compliance”

DAMA Scandinavia: March 2012, Stockholm,

“Reducing Complexity in Information Management” (rated best presentation in conference)

Ovum IT Governance & Planning: March 2012, London; “Data Governance – An Essential Part of IT Governance”

American Express Global Technology Conference: November 2011, UK,

“All An Enterprise Architect Needs To Know About Information Management”

FIMA Europe (Financial Information Management):, November 2011, London; “Confronting The Complexities Of Financial Regulation With A Customer Centric Approach; Applying a Master Data

Management And Data Governance Process In Clydesdale Bank “

Data Management & Information Quality Europe: (DAMA / IRM), November 2011, London, “Assessing & Improving Information Management Effectiveness – Cambridge University Press Case Study”; “Too Good

To Be True? – The Truth About Open Source BI”

ECIM Exploration & Production: September 12th 14th 2011, Haugesund, Norway: “The Role Of Data Virtualisation In Your EIM Strategy”

Enterprise Data World International: (DAMA / Wilshire), April 2011, Chicago IL; “How Do You Want Yours

Served? – The Role Of Data Virtualisation And Open Source BI”

Data Governance & MDM Europe: (DAMA / IRM), March 2011, London; “Clinical Information Data Governance”

P / 7

Recent PublicationsBook: “Data Modelling For The Business – A Handbook for aligning the business with IT using high-level data models”; Technics

Publishing; ISBN 978-0-9771400-7-7; http://www.amazon.com/Data-Modeling-Business-Handbook-High-Level

Book: “DAMA Data Management Body Of Knowledge 2.0” ; Technics Publishing; ISBN TBD

Article: Back to the future for Data management? September 2015

Article: Is the “Data Asset” really different? July 2015

Article: A visit to the vet & a BA flight reminded me about Data Governance; June 2015

White Paper: “Information is at the heart of ALL Architecture disciplines”,; March 2014

White Paper: “Are you ready for Big Data ?”, November 2013

Article: The Bookbinder, the Librarian & a Data Governance story ; July 2013

Article: Data Governance is about Hearts and Minds, not Technology January 2013

White Paper: “The fundamentals of Information Management”, January 2013

White Paper: “Knowledge Management – From justification to delivery”, December 2012

Article: “Chief INFORMATION Officer? Not really” Article, November 2012

White Paper: “Running a successful Knowledge Management Practice” November 2012

White Paper: “Big Data Projects are not one man shows” June 2012

Article: “IPL & Statoil’s innovative approach to Master Data Management in Statoil”, Oil IT Journal, May 2012

White Paper: “Data Modelling is NOT just for DBMS’s” April 2012

Article: “Data Governance in the Financial Services Sector” FSTech Magazine, April 2012

Article: “Data Governance, an essential component of IT Governance" March 2012

Article: “Leveraging a Model Driven approach to Master Data Management in Statoil”, Oil IT Journal, February 2012

Article: “How Data Virtualization Helps Data Integration Strategies” BeyeNETWORK (December 2011)

Article: “Approaches & Selection Criteria For organizations approaching data integration programmes” TechTarget (November 2011)

Article: Big Data – Same Problems? BeyeNETWORK and TechTarget. (July 2011)

Article “10 easy steps to evaluate Data Modelling tools” Information Management, (March 2010)

Article “How Do You Want Your Data Served?” Conspectus Magazine (February 2010)

Article “How do you want yours served (data that is)” (BeyeNETWORK January 2010)

Article “Seven deadly sins of data modelling” (BeyeNETWORK October 2009)

Article “Data Modelling is NOT just for DBMS’s” Part 1 BeyeNETWORK July 2009 and Part 2 BeyeNETWORK August 2009

Web Channel: BeyeNETWORK “Chris Bradley Expert Channel” Information Asset Management http://www.b-eye-network.co.uk/channels/1554/

Article: “Preventing a Data Disaster” February 2009, Database Marketing Magazine

Data Modelling Foundation

(1 day)

Introductory Intermediate Advanced / Deep Dive

Advanced Data Modelling(3 days)

Integrated Business Process, Data Requirements and Discovery(5 days)

DAMA-I CDMP Exam Cram & Certification

(3 days)

Level

Information Management For

The Business(½ and 1 day)

Multiple Levels of Training to meet your needs

Data Modelling Fundamentals(3 days)

The “client Way” Information Management Mentoring

Information Management Fundamentals(4 or 5 days)

Data Quality Management Implementation & Practice (1 and 2

day)

Data Warehouse & Business Intelligence Implementation & Practice (1 and 2

day)

Reference & Master Data Management Implementation & Practice (1 and 2

day)

Data Governance Implementation & Practice (1 and 2 day)

Data Integration Implementation & Practice (1 and 2 day)

Introduction to Information

Management (3 days)

MetaData Management Practitioner (1 day)

P A G E 9

AGENDA› What is a Conceptual Data Model

› Why is a Conceptual Data Model Important?

› Data Models and Information Management

› Aligning with Business Goals & Motivations

› Data Modeling Basics

P A G E 1 0

Who Are You? SurveyHOW WOULD YOU DESCRIBE YOUR ROLE?

Businessperson or Business Analyst

Business Intelligence Analyst or Developer

Data Architect, Data Modeler, or Data Analyst

DBA or Technical IT

A combination of the above

Other

P A G E 1 1

I am new to data modelling

I know a little about data modelling

I have a lot of experience with data modelling

Poll: How Familiar are you with Data

Modelling?

P A G E 1 2

What is a Conceptual Data Model?

P A G E 1 3

What is a

Conceptual Data Model?

› A Conceptual Data Model (CDM) uses simple graphical images to describe core concepts and principles of an organization and what they mean

› The main audience of a CDM is businesspeople

› A CDM is used to facilitate communication

› A CDM is used to facilitate integration between systems, processes, and organizations

› It needs to be high-level enough to be intuitive, but still capture the rules and definitions needed to create database systems

PRECISION

FLEXIBILITY

P A G E 1 4

THIS? THIS?

or

We all use Models to Gain Understanding

P A G E 1 5

We all use Models

Conceptual

P A G E 1 6

We all use Models

Logical

P A G E 1 7

We all use Models

Physical

P A G E 1 8

Customer

“A Picture is Worth a

Thousand Words”EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 1 9

“A Picture is Worth a

Thousand Words”

Product

Customer

Location

Order

Raw Material

Ingredient

Region

EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 2 0

“A Picture is Worth a

Thousand Words”EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 2 1

“A Picture is Worth a

Thousand Words”EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 2 2

Conceptual Data

Models apply to

Dimensional Data

Modelling as well.

“A Picture is Worth a

Thousand Words”EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 2 3

“A Picture is Worth a

Thousand Words”EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 2 4

“A Picture is Worth a Thousand

Words”EXAMPLES OF CONCEPTUAL DATA MODELS

P A G E 2 5

Is Notation Important?

› Many Notations can be used to express a high-

level data model

› The choice of notation depends on purpose

and audience

› For data-related initiatives, such as Master Data

Management (MDM) and Data Warehousing

(DW):

» ER modeling using IE (Information

Engineering) is our choice of notation

» It is important that your high-level model uses

a tool that can generate DDL, or can

import/export with a tool that can

» A repository-based solution helps with reuse

and standards for enterprise-wide initiatives

P A G E 2 6

Multiple Models – Multiple Purposes –

Multiple Audiences

Conceptual

Logical

Physical

Audience

Businessperson

3NF

Data Architect

DBA , Developer

Purpose

Communication & Definition of Business

Terms & Rules

Clarification & Detail of Business Rules & Data

Structures

Technical Implementation on a

Physical Database

Business Concepts

Data Entities

Physical Tables

Repository &Model-Driven

P A G E 2 7

Building Models Top Down vs. Bottom Up

›Models can be built

» Top-Down

» Bottom-Up

» Using a Hybrid Approach –

Middle Out

Conceptual

Logical

Physical

Repository &Model-Driven

P A G E 2 8

Step 1: Speak with the business representatives. Document the key business requirements and agree on high-level scope.

BRD

Step 2: Create detailed business requirement specification document with subscriber data requirement, business process and business rules

BRD

Step 3: Understand and document the business major attributes and definitions from business subject matter experts. Create logical data model.

Logical data model

Tables & foreign key constraints

Step 4: Verify the logical data model with the stakeholders and create physical data model

Step 5: Implement using the created physical model

Top-down Approach

P A G E 2 9

Step 5: Try to understand the business meanings of probable attributes and entities that may be candidates for logical data model

Step 4: Document the meanings of columns, and tables from IT subject matter experts

Step 3: Find out foreign key relationships between tables, from IT subject matter experts & verify findings

A near logical data model (accuracy unknown)

Tables & foreign key constraints

Step 2: Profile data by browsing and analyzing the data from tables. Scan through the ETL to find out hidden relationships & constraints.

Step 1: Reverse engineer the database schema that is already implemented.

Bottom-up Approach

P A G E 3 0

Create Different Models for Different

AudiencesBusiness -> Conceptual

P A G E 3 1

Create Different Models for Different

AudiencesTechnical -> Physical

P A G E 3 2

Database Script (DDL)

vs. Physical Data Model

product_id INTEGER NOT NULL,

product_name VARCHAR(50) NULL,

product_price NUMBER NULL);

ALTER TABLE PRODUCT

ADD ( PRIMARY KEY (product_id) ) ;

CREATE TABLE DEPARTMENT (

department_id INTEGER NOT NULL,

department_name VARCHAR(50) NULL);

ALTER TABLE DEPARTMENT

ADD ( PRIMARY KEY (department_id) ) ;

CREATE TABLE EMPLOYEE (employee_id

INTEGER NOT NULL,

department_id INTEGER NOT NULL,

employee_fname VARCHAR(50) NULL,

employee_lname VARCHAR(50) NULL,

employee_ssn CHAR(9) NULL);

ALTER TABLE EMPLOYEE

ADD ( PRIMARY KEY (employee_id) ) ;

CREATE TABLE CUSTOMER (

customer_id INTEGER NOT NULL,

customer_name VARCHAR(50) NULL,

customer_address VARCHAR(150) NULL,

customer_city VARCHAR(50) NULL,

customer_state CHAR(2) NULL,

customer_zip CHAR(9) NULL);

ALTER TABLE CUSTOMER

ADD ( PRIMARY KEY (customer_id) ) ;

CREATE TABLE ZORDER (

zorder_id INTEGER NOT NULL,

employee_id INTEGER NOT NULL,

customer_id INTEGER NOT NULL,

zorder_date DATE NULL);

ALTER TABLE ZORDER

ADD ( PRIMARY KEY (zorder_id) ) ;

“A picture is worth a thousand words”

P A G E 3 3

CONCEPTUAL LOGICAL PHYSICAL

Defines the scope, audience, context for

information

Defines key business concepts and their

definitions

Represents core business rules and data

relationships at a detailed level

Main purpose is for communication and

agreement of scope and context

Main purpose is for communication and

agreement of definitions and business logic

Provides enough detail for subsequent first

cut physical design

Relationships optional. If shown, represent

hierarchy.

Many-to-Many relationships OK Many-to-Many relationships resolved

Cardinality not shown Cardinality shown Cardinality shown

No attributes shown Attributes are optional. If shown, can be

composite attributes to convey business

meaning.

Attributes required and all attributes are

atomic. Primary and foreign keys defined.

Not normalized (Relational models) Not normalized (Relational models) Fully normalized (Relational models)

Subject names should represent high-level data

subjects or functional areas of the business

Concept names should use business

terminology

Entity names may be more abstract

Subjects link to 1-M HDMs Many concepts are supertypes, although

subtypes may be shown for clarity

Supertypes all broken out to include sub-

types

‘One pager’ Should be a ‘one pager’ May be larger than one page

Business-driven Cross-functional & more senior people

involved in HDM process with fewer IT.

Multiple smaller groups of specialists and IT

folks involved in LDM process.

Informal notation ‘Looser’ notation required – some format

construct needed, but ultimate goal is to be

understood by a business user

Formal notation required

< 20 objects < 100 objects > 100 objects

Comparing Conceptual, Logical & Physical

Models

P A G E 3 4

Roles Culture

3NF

DBAs, Data Architects and Executives are different creatures

DBA

• Cautious

• Analytical

• Structured

• Doesn’t like to talk

• “Just let me code!”

Data Architect/Data Modeler

• Analytical

• Structured

• Passionate

• “Big Picture” focused

• Likes to Talk

• “Let me tell you about my data model!”

Business Executive

• Results-Oriented

• “Big Picture” focused

• Little Time

• “How is this going to help me?”

• “I don’t care about your data model.”

• “I don’t have time.”

P A G E 3 5

Data Drives the Business

– Make sure it’s CorrectIn today’s information age, data drives key business

decisions.

Executives ask questions such as:

› How many customers do I have?

› What is total revenue by region for last fiscal year?

› Which products drove the most revenue this quarter?

Behind the answers to those questions lies a data

model:

› Documenting the source and structure of data

» What database(s) store customer information

» How are these databases structured to store customer

information

› Defining key business terms

» What is a product? e.g. Finished goods only? Raw

materials?

› Regulating business rules

» Can a customer have more than one account?

P A G E 3 6

Information in ContextThere’s more to data than meets the eye

I’d like a

report showing

all of our

customers

SUPPORT

ENGINEER

A person’s not a

customer if they

don’t have an

active maintenance

account.

SALES

A customer is

someone who

wants to buy

our product.

SYBASE

DB2ORACLE

SQL SERVER

MSSQL

AZURE

INFORMIX TERADA

TA

SAP

DBA

Which customer

database do you

want me to pull this

from? We have 25.

BUSINESS

EXECUTIVE

DATA

ARCHITECT

And, by the way, the

databases all store

customer information

in a different format.

“CUST_NM” on DB2,

“cust_last_nm” on

Oracle, etc. It’s a mess.

ACCOUNTING

A customer is

someone who

owns our product.

HUMAN

RESOURCES

My customers

are internal

employees.

P A G E 3 7

The Challenge

› You’ve been tasked to assist in the creation of a Data Warehouse

› Trying to obtain a single view of ‘customer’

› Technical and political challenges exist

» Numerous systems have been built already—different platforms and databases

» Parties cannot agree on a single definition

of what a ‘customer’ is

Solution:

Need to build a Conceptual Data Model

P A G E 3 8

Building a Conceptual Data Model

› Our challenge is to achieve a ‘single version of the truth’ for Customer information

› We have 6 different systems with customer information in them:

» 2 on Oracle

» 1 on DB2

» 1 using legacy IDMS

» 1 SAP system

» 1 using MS SQL Server

DB2

OracleOracle

IDMS

SQL Server

SAP

P A G E 3 9

Building a Conceptual Data Model

› We start with a very simple CDM, with

just one object on it, called

“Customer”.

› We use an data model and show

business definitions

Too Simple??

Customer

A person or organization that has purchased at least one of our products and has an active account.

P A G E 4 0

Too simple?

Our team thought so, so went ahead and focused on the

technical integration, including:

› Reverse engineering a physical model from each system

› Profiling the data to ensure data type consistency

› Creating ETL scripts

› Migrating the data into the data warehouse

› Building a reporting system off of the data

P A G E 4 1

Focusing on the Business

› This implementation went “perfectly”, with no errors

in the scripts, no data type inconsistencies, no

delays in schedule, etc.

› We built a complex BI reporting system to show our

upper management the results.

› We even sent out a welcome email to all of our

customers, giving them a 50% off coupon, and

thanking them for their support.

P A G E 4 2

Focusing on the Business

Until we showed the report to the business sponsor:

› We can’t have 2000 customers in this region! I know

we only have around 400!

› Why is Jones’ Tire on this list? They are still evaluating

our product! Sales was negotiating a 10% discount

with them, and you just sent them a 50% coupon!?!?

› You just spent all of that money in IT to build this

report with bad data???

P A G E 4 3

Back to the Drawing Board

After doing an extensive review of the six source systems, and talking with

the system owners we discovered that:

› The DB2 system was actually used by Sales to track their prospective “customers”

› These “customers” didn’t match our definition—they didn’t own a product of ours!!

Customer

A person or organization who does not

currently own any of your products and who is potentially interested in purchasing one or more of our products.

Customer

A person or organization that has

purchased at least one of our products and has an active account.

P A G E 4 4

Oops!

We were mixing current customers, with prospects (non-customers).

› We just sent a discount coupon to 1600 of the wrong people!

› We gave upper management a report showing the wrong figure for our total

number of customers!

› We are now significantly over budget to have to go back and fix this!!

We started over, this time with a Conceptual Data Model

P A G E 4 5

Achieving Consensus

We created a report of the various

definitions of customer…

And verified with the various stakeholders

that:

› There were 2 (and only 2 definitions) of

customer

› Sales was OK with calling their “customer”

a “prospect”

Customer

A person or organization who does not currently own any of your products and

who is potentially interested in purchasing one or more of our products.

Customer

A person or organization that has purchased at least one of our products and has an active account.

P A G E 4 6

Resolving Differences

Our new high-level data model

looked like this:

P A G E 4 7

Identify Model Stakeholders

Make sure ALL relevant

parties are involved in

the design process –

Get buy-in!

P A G E 4 8

Identify Model Purpose

› Key to success of any project is finding the right pain-point and solving it.

› Make sure your model focuses on a particular pain point, i.e. migrating an

application or understanding an area of the business

Existing Proposed

Business“Today, we have a poor customer list.”

“By next quarter, we want to identify a quality list of potential new customer prospects in the

Northeast region.”

Application“The legacy Account Management system is managed in DB2.”

“We need to migrate the legacy Account Management system to SQL Server, for finance reasons.”

P A G E 4 9

A CDM Facilitates Communication

Focus on your (business) audience

› Intuitive display

› Capture the business rules and definitions in your model

Simplicity does not mean lack of importance

› A simple model can express important concepts

› Ignoring the key business definitions can have negative affects

A model or tool is only part of the solution

› Communication is key

› Process and Best Practices are critical to achieve consensus and buy-in

A Conceptual Data Model Facilitates

Communication between Business and IT

P A G E 5 0

Communication is the Main Goal

of a Conceptual Data Model

› Wouldn’t it be helpful if we did this in daily life, too?

› i.e. “Let’s go on a family holiday!”

PERSON CONCEPT DEFINITION

Father VacationAn opportunity to take the time to achieve new goals

Mother Vacation Time to relax and read a book

Jane Vacation A chance to get outside and exercise

Bobby Vacation Time to be with friends

Donna Vacation More time to build data models

P A G E 5 1

Tactics for

Improving Communication

Start small

› Don’t try & boil the ocean

› Gain consensus – then drill into more detail & widen scope

Re purpose the models and data

› Mask detail

› Avoid Data Modeling geek language

Don’t become a methodology obsessive!

Go out of your way to engage with stakeholders

› Lunch & learn

› Webinars

P A G E 5 2

The basics of a good

workshop / interview

BEFORE

› Choose attendees carefully for a broad representation

› Reserve interviews for senior/time-limited stakeholders

› Do your homework! Research. Prepare questions

DURING

› Use the attendees’ own language, avoid jargon

› Use open questions, listen, and playback understanding

AFTERWARDS

› Photograph whiteboard / flipchart output

› Write up your notes ASAP, omit nothing yet

TOP DOWN FACT FINDING

P A G E 5 3

Collect: Gather the Nouns

Students enroll for a course by

submitting an application via our

web portal, providing their name,

date of birth, email, selected

course and card details.

TopTrainingCorp arranges for

distribution of the necessary

payment to the relevant

examination centre and

certification body. All our courses

are approved by the relevant

certification body.

Instructors deliver our courses over

3 days after which the student sits

2 examinations consisting of 40

multiple-choice questions.

What the business says… What the analyst hears…

Student blah blah course blah

blah application blah blah

name, email, selected course,

card details.

Blah blah payment blah blah

examination centre blah blah

blah certification body.

blah blah blah course blah blah

blah certification body. Instructor

blah blah blah course blah blah

blah student blah blah blah

examination blah blah question.

P A G E 5 4

Workshop Activity

INSURECo Description

INSURECo assists Customers manage their risk. In exchange for a constant stream of Premiums, INSURECo pays Customers a sum of money upon the occurrence of a predetermined event, such as a natural catastrophe, a car crash, or a doctor's visit.

INSURECo create value by pooling and redistributing various types of risk. It does this by collecting liabilities (i.e. premiums) from everyone that it insures and then paying them out to the few that actually need them. INSURECo can then effectively redistribute those liabilities to entities faced with some sort of event-driven crisis, where they will ostensibly need more cash than they currently have

on hand. As not everyone within the pool will actually suffer an event requiring the total use of all of their premiums, this pooling and redistribution function lowers the total cost of risk management for everyone in the pool.

INSURECo can generate profits in two ways:

• By charging enough premiums to cover the expected payouts that they will have to cover over the life of the policy

• By earning investment returns ("the float") using the collected premiums

INSURECo’s earnings ratio leans heavily towards investment returns. A large percentage of premiums are paid out which assists in attracting larger customer volumes and liabilities.

… KEY DATA THINGS?

Jeff has been an INSURECo customer since starting his

landscaping business in 2001. Insurance is extremely

important Jeff.

Jeff requires Commercial Liability coverage to protect

himself in case of damage done to a client's property.

Jeff also requires to have his equipment/tools insured.

This includes a number of vehicles that will be driven

for business on a commercial auto policy.

As Jeff is responsible for a number of staff it was

important for his commercial policy to include options

for covering specific items such as worker's

compensation.

Jeff – Business Owner / Contract Landscaper

I N S U R E C O C U S T O M E R P R O F I L E

P A G E 5 5

Workshop Activity

Organising the Terms

Break into small groups.

Using the INSURECo company description,

identify the “nouns” or “concepts” or

“things” that are important to the business.

Tip: It’s helpful to circle the key nouns in the text.

Create a Post It Note “Data Thing” for

each of the key terms that are important

for the business.

Time: 20 minutes

THINGS (CONCEPTS)

Customer

Concept #2

Concept #3 Etc.

P A G E 5 6

Workshop Activity

INSURECo Description…

INSURECo assists Customers manage their risk. In exchange for a constant stream of Premiums,

INSURECo pays Customers a sum of money upon the occurrence of a predetermined event, such as a

natural catastrophe, a car crash, or a doctor's visit.

INSURECo create value by pooling and redistributing various types of risk. It does this by collecting liabilities

(i.e. premiums) from everyone that it insures and then paying them out to the few that actually need

them. INSURECo can then effectively redistribute those liabilities to entities faced with some sort of event-

driven crisis, where they will ostensibly need more cash than they currently have on hand. As not everyone

within the pool will actually suffer an event requiring the total use of all of their premiums, this pooling and

redistribution function lowers the total cost of risk management for everyone in the pool.

INSURECo can generate profits in two ways:

• By charging enough premiums to cover the expected payouts that they will have to cover over the

life of the policy

• By earning investment returns ("the float") using the collected premiums

INSURECo’s earnings ratio leans heavily towards investment returns. A large percentage of premiums

are paid out which assists in attracting larger customer volumes and liabilities.

… KEY DATA THINGS?

P A G E 5 7

BreakLET’S TAKE 15 MINUTES FOR A BREAK!

P A G E 5 8

Data Modelling & Information Management

P A G E 5 9

DAMA DMBOK

Framework DATA

ARCHITECTUREMANAGEMENT

DATADEVELOPMENT

DATABASEOPERATIONS

MANAGEMENT

DATASECURITY

MANAGEMENT

REFERENCE & MASTER DATAMANAGEMENT

DATAQUALITY

MANAGEMENT

META DATAMANAGEMENT

DOCUMENT & CONTENT

MANAGEMENT

DATA WAREHOUSE & BUSINESS

INTELLIGENCE MANAGEMENT

DATA

GOVERNANCE

Knowledge Areas

P A G E 6 0

DATA

ARCHITECTURE

MANAGEMENT

DATA

DEVELOPMENT

DATABASE

OPERATIONS

MANAGEMENT

DATA SECURITY

MANAGEMENT

REFERENCE &

MASTER DATA

MANAGEMENT

DATA QUALITY

MANAGEMENT

META DATA

MANAGEMENT

DOCUMENT & CONTENT

MANAGEMENT

DATA

WAREHOUSE

& BUSINESS

INTELLIGENCE

MANAGEMENT

DATA GOVERNANCE

› Enterprise Data Modelling› Value Chain Analysis› Related Data Architecture

› External Codes› Internal Codes› Customer Data› Product Data› Dimension Management

› Acquisition› Recovery› Tuning› Retention› Purging

› Standards› Classifications› Administration› Authentication› Auditing

› Analysis› Data modelling› Database Design› Implementation

› Strategy› Organisation & Roles› Policies & Standards› Issues› Valuation

› Architecture› Implementation› Training & Support› Monitoring & Tuning

› Acquisition & Storage› Backup & Recovery› Content

Management› Retrieval› Retention

› Architecture› Integration› Control› Delivery

› Specification› Analysis› Measurement› Improvement

Where does

Data Modelling

fit?

P A G E 6 1

Data Modelling for Data Warehousing (DW)

and Business Intelligence (BI)

DATA WAREHOUSE BI REPORT:

CUSTOMERS BY REGION

DATA WAREHOUSING BI REPORTING

› What is the definition of customer?

› Where is the data stored?

› How is it structured?

› Who uses or owns the data?

Show me all

customers by

region

› What do I want to report on?

› How do I optimize the database

for these reports?

A Data Model is the

“Intelligence behind

Business Intelligence”

– Understand source and target data systems

– Define business rules

– Optimize data structures to align queries with reports

Data

Warehouse

P A G E 6 2

Scenario:

Who is our “Customer”?

Has this ever happened to you?

› You’ve had a particular credit card for 10 years,

and you regularly pay your full balance every

month.

› In addition to your monthly bill, you also receive a

separate letter asking you to “Sign up for our

credit card! Great Interest Rate!”

Why does this happen? Don’t they know that you

already own a card?

How could a data model help?

P A G E 6 3

Who is our “Customer”?

Look familiar?

P A G E 6 4

Data Modelling for

Application Development

› The majority of today’s applications are

data-driven

› A data model is a key part of the

application development lifecycle

› Reuse of common data objects helps

promote

› Increased efficiency – don’t “reinvent the

wheel”

› Better collaboration

› Increased quality and consistency

P A G E 6 5

Scenario:

Expense Tracking Application “Bug”

Acme corporation has an Expense Billing application for its

employees.

› For each business trip, employees were asked to specify

which department should be billed.

› This caused a problem for employees whose job role spanned

several departments.

A product manager, for example, needed to bill Development for business trips to manage product releases, but needed to bill Sales for business trips to support customers.

› With the existing database structure, this was impossible.

› When management asked for an estimate of what it would

cost to correct this, the expense was in the thousands of

euros.

How could a data model help?

P A G E 6 6

Expense Tracking Application “Bug”

› When the original database system was built, the

developer assumed that each employee works

for a single department.

› He structured the system in such a way that only

a single department name could be associated

with each employee.

› This could have been fixed with a simple data

model design.

P A G E 6 7

Expense Tracking Application “Bug”

Each employee can bill

expenses to multiple

departments

(Better implemented as: )

P A G E 6 8

Data Modelling for Metadata Management

Metadata is “Information in Context”

A Data Model helps Provide this Context

Customer Name Company City Year Purchased

Joe Smith Komputers R Us New York 1970

Mary Jones Big Bank Co London 1999

Proful Bishwal Little Bank Inc Mumbai 1998

Ming Lee My Favorite Store Beijing 2001

METADATA

DATA

Who is using the

data?

Who owns the

data?

Where is the

data stored?

When was it last

updated?

What are the business

definitions?

Why are we

tracking the data?

What is the structure and

format of the data?

METADATA

P A G E 6 9

Enterprise Architecture provides a high-level view of the people, processes,

applications, and data of an organization

Putting data in business context:

› How does data link to the rest of my organization?

› If I change data, what business processes are affected?

Data Modelling for Enterprise Architecture

P A G E 7 0

Data Modelling for

Database Management

› Know what data you have: Create a visual inventory of database systems

› Know what your data means: Communicate key business requirements between

business and IT stakeholders

› Support data consistency: Build consistent database structures with common

definitions

SYBASEORACLE

DB2TERA-DATA

SQL SERVER

MySQL

SQL SERVER

MySQL

SYBASE

DB2

ORACLE

TERA-DATA

P A G E 7 1

Data Modelling for

Master Data Management

Master Data Management strives to create a “single version of the truth”

for key business data: customer, product, etc.

Using a central data model helps define:

› Common business definitions

› Common data structures

› Data lineage between defined “version of the truth” and real-world

implementations

P A G E 7 2

MDM:

Plan Big – Implement Small

Business Initiative / Project 1

Some of MD area A

needed here

Some of MD area B needed here

Business Initiative / Project 2

More of MD area A

needed here

Some of MD area C needed here

More of MD area B needed here

Business Initiative / Project 3

More of MD area C

needed here

More of MD area B needed here

More of MD area A needed here

Business Initiative / Project 4

Lots of MD area D

needed here

More of MD area B needed here

More of MD area A needed here

Project4 later includes MD for area D

MDM program cannot deliver Data Subject Area D at this time for Project 4.

Project 4 gains exemption to add this MD later

IN THE CONTEXT OF THE BIG PICTURE VIA THE CONCEPTUAL DATA MODEL

IMPLEMENT MDM IN ALIGNMENT WITH BUSINESS INITIATIVES

P A G E 7 3

Data Modelling for Data Governance

› Data, like money, is a corporate asset, and needs to be managed accordingly.

› Like an auditing department for finance,

data governance provides the guidelines,

accountability and regulations around data management.

› A Data Model can help define:

» Who is accountable for data (e.g.

Data Steward)?

» Who is using data?

» What is the lineage and traceability

of data?

» What is the proper definition of key

business information?

» When was the data last updated?

P A G E 7 4

Data Modelling for

Data Lineage: e.g. SOX

Financial reporting &

auditing requirements

Near real time reporting

Accuracy of Financial statements

Effectivenessof internal

controls

INFORMATION

MANAGEMENT ESSENTIAL

DATA LINEAGE IMPLICATIONS

DATA GOVERNANCE

IMPLICATIONS

DATA QUALITY &

DEFINITIONS IMPLICATIONS

P A G E 7 5

Data Modelling for

Package / ERP systems

Data Requirements For Configuration & Fit For

Purpose Evaluation

Data Integration & Governance

Legacy Data Take On Master Data Integration

DATA MODEL

P A G E 7 6

Data Modelling For Packages / ERP Systems

Data lineage (particularly important with Data Lineage & SOX compliance issues)

Master Data alignment

For Data migration / take on

Identifying gaps

For requirements gathering ... But what if we’ve got to use package X?

CUSTOMER

ORDER

CUSTOMER

ORDER

VS

P A G E 7 7

Data Modelling for

Data Virtualisation

Virtual OperationalData Stores

Shareable Data Services

D A T A M O D E L

S Q LW E B

S E R V I C E SS T A R

VirtualData Marts

Relational Views

LEGACYMAINFRAMES

FILES RDBMSWEB

SERVICESPACKAGES

BI, MI AND

REPORTINGCUSTOM APPS

PORTALS &

DASHBOARDS

ENTERPRISE

SEARCH

P A G E 7 8

Data Modelling Spans

All Disciplines

Data is at the heart

of ALL architecture

disciplines

Data has to be

understood to be

managed

Different levels of

models for different

purposes

It’s NOT just for

DBMS design

Data models are not

(just) art

Professional

development:

certification &

trainingAll of the Architecture disciplines use the language

(and rules) of the data model

P A G E 7 9

Aligning with Business Motivation

P A G E 8 0

Validate and Refine

Business Goals

› A Goal is a statement about a state or condition of the enterprise to be brought about or sustained through appropriate Means.

› A Goal amplifies a Vision — that is, it indicates what must be satisfied on a continuing basis to effectively attain the Vision.

› A Goal should be narrow — focused enough that it can be quantified by Objectives.

› A Vision, in contrast, is too broad or grand for it to be specifically measured directly by Objectives.

However, determining whether a statement is a Vision or a Goal is often impossible without in depth knowledge of the context and intent of the business planners.

In light of the mission and vision and the influencer pressures, validate and refine the goals of the organisation

P A G E 8 1

Look for Levers

Derive a set of measurable levers of business value and growth by cascading down the drivers of income in your business.

› The levers are intended to be durable even as

business strategy shifts.

Value levers indicate which business dimensions need to be analysed for change projects.

› Business consultants use the matrix to understand

which business architecture dimensions have the

greatest impact on each lever, focusing attention on

those dimensions most relevant to the levers in focus.

Look for levers that can help you address the goals

P A G E 8 2

Improvement

Levers ExampleIncrease priceIncrease volumeImprove mix

Improve processReduce cost of inputsImprove warehouse utilisation

Increase productivityDecrease staffing

Optimize schedulingOptimize physical networkDecrease staffingUse alternative distribution

Lower Customer Service & Order Management Costs

Lower I/S costsLower Finance / Accounting costs

Lower HR costs

Improve capital planning/ investment process

Reduce inventoriesReduce A/R increase A/P

o Profit-driven marketing efforts:

• Target “best” customers• Offer “best” product mix• Improve pricing

management

• Proactive production planning for inventory management

• Most profitable capacity allocation/utilization

o Reduced sales management layers

o Focus on high-profit accounts

o Improved inventory flow visibility

• Lower transportation costs• Higher facilities utilization• Less “fire fighting”o Better carrier

evaluation/mgmt.

o Higher quality Customer Service

o Improved Supply Chain visibility

• Improved order fill rates• Significantly lower cost • More consistent service• Faster problem resolution

o Improved capital stewardship

• Increased capital productivity

• Reduced inventory investment

• Reduced receivables investment

o Automated PO requisitions

o Improved information for evaluating vendors

o Automation of some scheduling functions

o Single point of entry eliminates data re-entry and improves accuracy

o Faster data reconciliation o Automated billing

processeso Automated payroll

processes

o Moderately lower safety stock inventory

o Moderately improved A/R and A/P management

Increase revenues

Decreasecosts

Reduce selling costs

Reduce distribution

costs

Reduce administrative

costs

Increase gross profit

Decrease operating expenses

Capital deployment

Cost of capital

Increase net operating

profit after tax (NOPAT) (I/S)

Improve capital

allocation (B/S)

Enterprise Value Map

VALUE LEVERS

TRANSFORMATIONBENEFIT (Outcome)

AUTOMATION BENEFIT

P A G E 8 3

Goals, drivers and

levers are tightly integrated

The value map will help

identify enterprise aligned

business unit drivers and

leverage pointsExamples

• Revenue enhancement

• Margin enhancement• Operating efficiencies

• Working capital management

• Investment capital productivity

• Capital structure optimization

CORPORATE LEVEL-SPECIFIC

Examples

• Pricing strategy• Product assortment

• Departmental emphasis

• Product cost• Store operating costs • Corporate administrative

costs

• Operating cash reserves • Inventory management• Accounts payable

management

• Store base• Leases• Intangible assets• Distribution assets

BUSINESSUNIT-SPECIFIC

Examples

• Purchase frequency• Household penetration

• Transaction size

• Gross margin • Store operating expense

%• SG&A expense %• Distribution cost per case

• Days cash on hand• Inventory turns-store and

DC• Account payable cycle

• Store-level profitability• Debt/Equity ratio• Annual capital

investment

OPERATINGVALUE DRIVERS

Earning loyalty & trust

with customers &

community

Make our

Processes simpler

and faster

Empower the frontline to

Deliver Integrated

Financial Solutions

Deliver new

and relevant

products

Create a

performance

culture

REVENUE

COSTS

WORKING CAPITAL

FIXED CAPITAL

NOPLAT

INVESTED CAPITAL

EVM

Goals and Drivers help define value drivers and improvement levers

P A G E 8 4

› Your team has been brought on

board to help address some of the

information related stakeholder

concerns

› INSURECo’s CIO intuitively understands

some of these concerns are due to

poor management of data and

information across the organisation

› The CIO has engaged your team to

assist him to understand how he can

best get control of the situation and,

as a result, elevate a number of

stakeholder concerns

› The CIO is specifically interested in

understanding what information

management practices need to put

in place to avoid finding himself in this

position again in the future

Workshop Activity

Problem Briefing

P A G E 8 5

Example

DecompositionWhat are our corporate goals?

What are the priorities and battlegrounds given our corporate goals?

What IT assets and data do we need to support these capabilities?

How will our business model change over the next three to five years?

What are the key capabilities that will maximize value creation in the business?

How do we optimize our IT operating model to deliver the required business capabilities?

Earn all

Our customers’

business

Drive a strong

Customer culture

Enhanced branch

Capability and

Power in frontline

Transform

Service delivery

And processes

Customer

centricity

Front office

empowerment

Channel and

Product operational

excellence

Customer

Profile

management

Relationship

managementCustomer

analytics

Offer

design

Product

management

Integrated

Data store

Enterprise

Service bus

Channel

platforms

Product

platforms

Security

platforms

End-user

computing

Customer

analytics engine

Universal

customer master

Integrated sales &

Service front end

Internet platform

transformation

Core banking

transformation

Vision

Strategic agenda

Business objectives

Business capabilities

IT capabilities

IT investments

P A G E 8 6

Problem Briefing “Workflow is inadequate for

Product Development,

Underwriting and Legal &

Compliance”

“First contact resolution is an

important goal for Enquiries and Complaints”

“Rolling out new products to customers is

expensive and takes a long time. Product Releases should be a

BAU activity ”

“No correlation between claims and reinsurance

systems”

“Management Reporting is complex

and uses a lot of disparate systems

and spreadsheets to produce”

“We have key person

dependencies in a number of

teams”

“Errors are only picked up at policy anniversary”

“Knowledge, Document and

Content Management is

inadequate”

“50% of errors are

associated with either missing a process

step or sending paperwork to the

wrong place”

Are the strategic

programs aligned, or for that matter, are they the right

strategic programs?

Are we investing in the right areas

across the

enterprise?

Is my investment portfolio

balanced across my strategic and

tactical issues

Where can we take advantage

of synergies across the major

strategic programs?

There is a lot of activity going on out there, how do

I know we are doing the right

things?

INSURECo Stakeholder Concerns

P A G E 8 7

Workshop Activity

Describe the problem space using

Text-based & Visual models

› Think about “a day in the life” of INSURECo with specific focus

on the environment and problem space. List these as text

› Flip over the card and now draw a picture of the problem

› Post the picture on the wall and explain it to the class. Take

note of common elements

› Time: 20 minutes

› After descriptions, the group must reflect on the

similarities and differences and work towards a shared

understanding of the problem space

› Document this shared understanding on the flip chart

and post on the wall

INDEX CARD – FRONT AND BACK

P A G E 8 8

Data Modelling Basics

P A G E 8 9

Data Modelling does not

have to be Complicated!

If you can write a sentence, you can build a data model.

If you understand how your business works, you can build a data model.

Businesspeople should be involved in the development of data models, because only they understand the business needs

and rules.

Understanding data modelling basics will help the Business better communicate with IT

P A G E 9 0

What is an Entity?

Entity: A classification of the types of objects found in the real world --persons, places, things, concepts and events – of interest to the

enterprise. 1

1 DAMA Dictionary of Data Management

WHO? WHERE?

WHEN? HOW?WHY?

WHAT?

The “Who, What, Where, When, Why” of the Organization

P A G E 9 1

Entities are the “Nouns”

of the Organization

› Who? Employee, Customer, Student, Vendor

› What? Product, Service, Raw Material, Course

› Where? Location, Address, Country

› When? Fiscal Period, Year, Time, Semester

› Why? Transaction, Inquiry, Order, Claim, Credit, Debit

› How? Invoice, Contract, Agreement, Document

P A G E 9 2

Sample Entities

Product

Customer

Location

Order

Raw Material

Ingredient

Region

P A G E 9 3

Baker Cakes, Inc.

› Baker Cakes is a family-run business whose

main stakeholder is Bob Baker, the

owner/operator of Baker Cakes. Bob is in

charge of making most decisions, from

database design to icing color selection.

› In our example, we’re building a new

application for Baker Cakes, who is looking

to build a new application to manage their

data.

P A G E 9 4

What Entities are needed

for this Cake Company?

Exercise: List some entities that would be needed for Baker

Cakes, Inc. to manage their corporate data

— Customer

— Product

— Invoice

— Ingredient

— Raw Material

— Flavor

P A G E 9 5

Attributes An Attribute is a piece of information

about or a characteristic of an Entity.

Attributes

Entity

Employee • Employee Identifier

• Employee Last Name

• Employee First Name

• Employee Hire Date

• Employee Signed Employment Contract

• Employee Drivers License Photo

Entity

Attributes

P A G E 9 6

Relationships are the “Verbs”

of the Organization

Relationships define the data-centric Business Rules of an organization

› An employee can work for more than one department.

› A customer can have more than one account.

› Sales are reported monthly.

› A department can contain more than one employee.

— Relationships are the “verbs” in a sentence

• A department can contain more than one employee.

Defining Business Rules

— Relationships are the “lines” on a data model

ContainDepartment Employee

P A G E 9 7

ContainDepartment Employee

Cardinality = “How Many?”

‘Cardinality’ is the term used to describe the numeric relationships

between the entities on either end of the relationship line.

A department can contain more than one employee.

P A G E 9 8

Deciphering Cardinality

Think of how a child might answer the question “How many?”

› One = 1 finger

› More than one = several fingers

ContainDepartment Employee

P A G E 9 9

Optionality = Required

‘Optionality’ describes what may or must happen in a relationship.

A department may contain more than one employee.i.e. “zero, one, or many”

A department must contain more than one employee.i.e. “one, or many”

i.e. “Must” or “May”

ContainDepartment Employee

ContainDepartment Employee

P A G E 1 0 0

Data Modeling is Similar to Diagramming a

Sentence

1. Place boxes around the “nouns”, or entities.

2. Underline the verb

3. Circle the “how many” qualifier.

4. Look for optionality words (e.g. “may/must”)

A department may contain more than one employee.

ContainDepartment Employee

P A G E 1 0 1

Exercise:

Practice “Reading” the following

Relationships/Business Rules

› Each Employee may process one or many Transactions.

› Each Transaction must be processed by one Employee.

› Each Customer may place one or many Orders.

› Each Order must be placed by one Customer.

ProcessEmployee Transaction

PlaceCustomer Order

P A G E 1 0 2

Exercise:

Create a Data Model

from a Business Rule

Create a Data Model for the following business rule:

A customer may own more than one account.

Thought for this exercise:

Can an account have more than one customer associated with it?

If so, how would you show this?

P A G E 1 0 3

Exercise:

Create a Data Model

from a Business Rule

Create a Data Model for the following business rule:

A customer may own more than one account.

OwnCustomer Account

P A G E 1 0 4

What are Keys?

A Key is an attribute or group of attributes that uniquely identifies an Entity.

For example,

— A Customer is identified by a Customer ID

— A Student is identified by Last Name, First Name, and Date of Birth

P A G E 1 0 5

Candidate Keys

› What attributes might uniquely identify an entity? Let’s use Customer as an example.

› What might uniquely identify an individual customer?

Is Last Name + First Name enough?

— Could there be 2 customers named John Smith? Probably

Is Last Name + First Name + Date of Birth enough?

— Could there be 2 customers named John Smith born on 1 June, 1963? Less

Likely, but Possible

Is Last Name + First Name + Date of Birth + Address enough?

— Could there be 2 customers named John Smith born on 1 June, 1963 living at 1

Earl’s Court, London, UK? Even Less Likely. Possible, but how many attributes

do we want to use?

P A G E 1 0 6

Candidate Keys:

Natural vs. Surrogate

› The keys we just identified would be classified as natural keys.

› Natural keys are based on business rules

and logic that determine how an individual instance can be uniquely identified.

› As we’ve seen, natural keys can become unwieldy, requiring a number of attributes, which makes queries difficult.

— Surrogate keys are often used instead,

which are system-generated unique

identifiers. e.g. Customer ID, Product ID, etc.

— While surrogate keys are more efficient,

important business rules are lost when they

are used. It’s a balancing act.

P A G E 1 0 7

Alternate Keys

Alternate Keys can be defined to keep the business rules of a natural key, while still achieving the efficiency of a surrogate key.

In the example below:

› Student Number is the primary key (surrogate key)

› Student Last Name + Student First Name + Student Date Of Birth is the natural key

Alternate keys can be used to retrieve

information more quickly in a database (e.g.

index by last name + first name + date of birth).

Student

Student Number

Student First Name (AK1.2)Student Last Name (AK1.1)Student Date of Birth (AK1.3)

P A G E 1 0 8

Primary Keys

A Primary Key is an attribute or group of attributes that uniquely identifies an Entity.

A primary key is shown “above the line” in a data model.

Primary Key

Customer

Customer ID

Customer First Name Customer Last NameCustomer Date of Birth

P A G E 1 0 9

Supertypes and Subtypes

Supertypes and Subtypes are a

mechanism for grouping objects

with similar (but not identical)

characteristics.

For

example:

Individual

Customer ID (FK)

Customer First Name

Customer Last Name

Customer Gender

Customer Date of Birth

Corporation

Customer ID (FK)

Company Name

Corporate Logo

Customer

Customer ID

First Date of Purchase

Common Attributes

Supertype

Subtype

Unique Attributes Unique

Attributes

Subtype

P A G E 1 1 0

Dimensional Data Modelling

P A G E 1 1 1

Dimensional Data Modelling

› Relational data modeling describes

business rules around transactional

systems.

› Dimensional data modeling describes

structures for aggregation and

reporting, typically for business

intelligence.

P A G E 1 1 2

Data Warehousing and BI

› Typically a Data Warehouse is built for a Business Intelligence (BI) project

› Need to transform and summarize the relational tables from operational systems, to a

single warehouse summarized for reporting.

› “ETL” is the process of Extracting, Transforming, and Loading the Warehouse.

Data

WarehouseETL

RELATIONAL DIMENSIONAL

ERP SystemSales DB

Sales DB (2) Sales DB (3)

Accounting DB

P A G E 1 1 3

Dimensional Data Modeling

For BI, an easy way to think of a dimensional model is to ask yourself:

“What do I want to report by?” (Apologies to grammarians!), e.g.

› by month

› by region

› by quarter

› by product

The lines on a dimensional data model represent navigation paths,

not business rules.

P A G E 1 1 4

Sample Dimensional

Data Model “Star Schema”

In this case, we want to report

on Sales by Product, by

Month, by Sales Rep, and by

Region.

FACT TABLE

DIMENSION

DIMENSION

DIMENSION

DIMENSION

P A G E 1 1 5

Dimensional Data Modeling

FACTS

Contain the actual values to be

reported upon. e.g. Sales Figures

› Few attributes (with links/keys to

the dimensions)

› Many values

DIMENSIONS

Contain the details that describe

the central fact.

› Many attributes

› Few values

P A G E 1 1 6

Workshop:

Employee Salary Reporting

› You work in Human Resources and your company is

implementing a new employee salary and benefit reporting

system.

› IT asks you for your requirements. You can impress them by

sending them a well-formed dimensional model.

› Your report needs to show your company’s total salary

spending by region. You also want to know which managers

are paying their employees the most. And you’ll want to see

which roles in the organization make the most money.

› Create a conceptual data model for this reporting system.

Don’t worry about entering definitions for the concepts at this

point—just show the concepts that you need to report on and

report by. (Hint: this will be a three-sided star).

P A G E 1 1 7

Example:

Employee Salary Reporting

Your conceptual data model for

the new reporting system should

look something like this:

Sa la ry

Manage r

Reg ion

Ro le

P A G E 1 1 8

SUMMARY

› A data model can help increase

Communication with the business

owners and IT staff to and achieve

better results

› Starting with a robust data model helps

alleviate many of the data quality and

data-related errors commonly seen in

business today.

› Aligning with Business Motivation and

Drivers is key to success of any

initiative

› Data Modeling does not have to be

complicated and can be understood

by most businesspeople

› Data Modeling is at the core of most

Information Management challenges