2. Who am I?
— More than more than 15 years of experience in the areas of
data management, metadata management, and enterprise
architecture.
− Currently VP of Product Marketing for CA’s data modeling
solutions.
− Brand Strategy and Product Management roles at Computer
Associates and Embarcadero Technologies
− Senior consultant for PLATINUM technology’s information
management consulting division in both the U.S. and Europe.
− Worked with dozens of Fortune 500 companies worldwide in the
U.S., Europe, Asia, and Africa and speaks regularly at industry
conferences.
− Co-author of several books including:
• Data Modeling for the Business
• Data Modeling Made Simple with CA ERwin Data Modeler r8
4. Who Are You? Survey
—How would you describe your role?
A. Data Architect, Data Modeler, or Analyst
B. Businessperson or Business Analyst
C. DBA or Technical IT
D. A combination of the above
E. Other
5. Are you Using CA ERwin? Survey
—Are you using CA ERwin currently?
A. Yes!
B. No.
C. I’m not sure
6. What Version of ERwin? Survey
—What version of ERwin are you using?
A. 8.x
B. 7.x
C. 4.x
D. 3.x or earlier
E. I’m not using ERwin, which is very sad.
11. Information in Context
There’s more to data than meets the eye
A customer is
I’d like a report someone who
wants to buy
showing all of A customer is our product.
someone who A person’s not a
our customers owns our customer if they don’t
product. have an active
maintenance account.
Sales
Business My customers
Executive Accounting are internal
employees.
Which customer Support
database do you Engineer
want me to pull
this from? We
have 25. HR
And, by the way, the
Sybase
databases all store
Oracle customer information in a
DB2 DBA different format. “CUST_NM”
on DB2, “cust_last_nm” on
Informix Oracle, etc. It’s a mess.
SQL Teradata
Server
Data
MS SAP
Architect
SQL
Azure
12. The CA ERwin Solution
Visualize the Power of Your Data
On-Premise or in the Cloud
13. CA ERwin Data Modeler
Know what data you have: Create a visual inventory of source and target systems –
Reverse Engineering
Know what your data means: Communicate key business requirements between
business and IT stakeholders
Ensure that your data is consistent: Build consistent database structures - Forward
Engineering
CA ERwin® Data Modeler
DB2 Oracle
MySQL Sybase
Oracle SQL
Server
SQL
Sybase Teradata
Server DB2
SQL SQL MySQL
Teradata
Azure Azure
15. CA ERwin® Data Modeling
At the Center of Your Data Management Initiatives
Cloud or SaaS BI +
Data Management
Master Data Management Business Intelligence +
(MDM) Data Warehousing
Data Data Governance
Management
ERP
Integration Application Developme
Data Quality
18. The Challenge
—You’ve been tasked to assist in the creation of a Business
Intelligence (BI) project
—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 High-Level Data Model
19. What is a High-Level Data Model?
—A high-level data model (HDM) uses simple graphical images to
describe core concepts and principles of an organization and what
they mean
—The main audience of a HDM is businesspeople
—An HDM is used to facilitate communication
—It needs to be high-level enough to be intuitive, but still capture
the rules and definitions needed to create database systems.
20. “A Picture is Worth a Thousand Words”
Examples of High-Level Data Models
21. “A Picture is Worth a Thousand Words”
Examples of High-Level Data Models
Product Location
Customer Region
Order
Raw
Material
Ingredient
22. “A Picture is Worth a Thousand Words”
Examples of High-Level Data Models
23. “A Picture is Worth a Thousand Words”
Examples of High-Level Data Models
24. “A Picture is Worth a Thousand Words”
Examples of High-Level Data Models
25. “A Picture is Worth a Thousand Words”
Examples of High-Level Data Models
27. Levels of Data Models
—Models can be built
− Top-Down
− Bottom-Up
− Using a Hybrid Approach
28. How is this Different from a Logical Model?
VHDM HDM LDM
Defines the scope, audience, context for Defines key business concepts and their Represents core business rules and data
information definitions relationships at a detailed level
Main purpose is for communication and Main purpose is for communication and Provides enough detail for subsequent
agreement of scope and context agreement of definitions and business first cut physical design
logic
Relationships optional. If shown, Many-to-Many relationships OK Many-to-Many relationships resolved
represent hierarchy.
Cardinality not shown Cardinality shown Cardinality shown
No attributes shown Attributes are optional. If shown, can be Attributes required and all attributes are
composite attributes to convey business atomic. Primary and foreign keys
meaning. defined.
Not normalized (Relational models) Not normalized (Relational models) Fully normalized (Relational models)
Subject names should represent high- Concept names should use business Entity names may be more abstract
level data subjects or functional areas of terminology
the business
Subjects link to 1-M HDMs Many concepts are supertypes, although Supertypes all broken out to include sub-
subtypes may be shown for clarity types
‘One pager’ Should be a ‘one pager’ May be larger than one page
Business-driven Cross-functional & more senior people Multiple smaller groups of specialists
involved in HDM process with fewer IT. and IT folks involved in LDM process.
Informal notation ‘Looser’ notation required – some format Formal notation required
construct needed, but ultimate goal is to
be understood by a business user
< 20 objects < 100 objects > 100 objects
29. Building a High-Level Data Model
—Let’s go back to our challenge, to achieve a ‘single version of the
truth’ for Customer information
—We have 5 different systems with customer information in them:
− 2 on Oracle
− 1 on DB2
− 1 SAP system
− 1 using MS SQL Server
Oracle
DB2 Oracle
SQL SAP
Server
30. Building a High-Level Data Model
—We start with a very simple HDM, with just one object on it, called
“Customer”.
—We use an ER Model and show business definitions
Too Simple??
31. Too simple?
—Our team thought so, so went ahead and focused on the technical
integration, including:
− Reverse engineering a physical model from each system
− Creating ETL scripts
− Migrating the data into a single hub
− Building a reporting system off of the data
32. 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.
33. 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 Global Bank Company 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???
34. 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!!
35. 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 High-Level Data Model
36. 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”
40. A HDM Facilitates Communication
—A High-Level Data Model Facilitates Communication between
Business and IT
− 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
41. Communication is the Main Goal
of a High-Level Data Model
—Wouldn’t it be helpful if we did this in daily life, too?
—i.e. “Let’s go on a family vacation!”
Person Concept Definition
Father Vacation An 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
42. Some Creative Ways to Facilitate Conversations with
Stakeholders
— Food!
− “Lunch and Learn”
− Bring candy to meetings
— Force?
− “No bathroom breaks until we reach consensus!”
— Active Listening
− Understand why there is disagreement (e.g. “Ingredient” vs. Raw Material)
— Fit into their schedule
− Webinars
− The “5 minute rule” for business execs – small, bite-sized models or questions.
— Publish in an easily-accessible, intuitive format
− Web-based publishing
− Spreadsheet-style reporting
43. 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 an Account can “By next quarter, an
only be owned by one Account can be owned by
Customer.” more than one Customer.”
Application “In the legacy Account “When we migrate to
Management system, we SAP/R3, Account Holder
call the customer an will be represented as
Account Holder.” Object.”
44. Managing the Technical Infrastructure
Why do you need a modeling tool, and not a drawing tool?
—Recall that we had multiple data sources on a variety of platforms:
− 2 on Oracle
− 1 on DB2
− 1 SAP system
− 1 using MS SQL Server
—How can CA ERwin help manage this?
Oracle
DB2 Oracle
SQL SAP
Server
45. Creating a Data Inventory
— “Design Once, Reuse Many Times” across heterogeneous platforms
— Design layers allow you to have a single high-level/logical model pointing to
numerous physical model platforms.
Oracle
DB2
SQL Server
46. Design Layers Create both Business
and Technical Designs
Business Data DBA
Sponsor Architect
Physical Data
Model
Logical Data Model
(Oracle)
(Business Area 1)
Conceptual Data Physical Data
Model Model
(SQL Server)
Logical Data Model
(Business Area 2)
Physical Data
Model
(DB2)
47. A Data Model can be your Filter
—A Data Model can add:
− Focus – by Subject Area, by Platform, etc.
− Visualization – Different Views for Different Audiences
− Translation – to different DMBS AND to non DBMS formats such as UML, BI tools,
Excel, XML, etc, etc.
Data Model
Oracle
Oracle
DB2 Developers Business
Sponsors
ETC! ETC!
DB2
SQL 3NF
Server IDMS
SAP
Data Architects DBAs
52. Managing the Data Inventory with
a Central Repository
— A Central Model Store provides a single repository to store all of your data
model assets
— A collaborative environment for multiple modeling teams.
— Metadata storage for: multiple models, multiple dbms platforms, multiple tools,
multiple audiences
Multiple Multiple Multiple Tools Multiple
Models DBMSs Audiences
Oracle
Teradata
BI Tools
DB2
SQL Developers Business
Server Spreadsheets ETL Tools Sponsors
Single Definition of 3NF
“Customer”
Central Model Store Data Architects DBAs
53. Understanding ERP Systems with
CA ERwin Saphir Option
Important metadata is found beyond traditional databases.
ERP Systems also contain critical information about customers, employees, etc.
SAP, Oracle, JD Edwards, etc.
These ERP systems are difficult to manage with a traditional “reverse
engineering” process using a data modeling tool
There are thousands of tables
When we reverse engineer them, we get unintuitive technical names
54. Understanding ERP Systems with
CA ERwin Saphir Option
Using the CA ERwin Saphir Option, we can easily group tables by
subject area, and can translate table and column names into
intuitive, English versions.
And can more easily integrate ERP data models into our enterprise
data architecture.
55. CA ERwin Data Model Validator
CA ERwin Data Model Validator checks models for consistency & accuracy
with a “teach me” facility to learn from errors
Great for new modelers and team members.
Helps with governance of modeling projects.
56. What’s New in the CA ERwin Product Family
CA ERwin Data Modeling r8.2
57. CA ERwin Data Modeling r8.2
Three New Offerings
CA ERwin® Web Portal CA ERwin® Data CA ERwin® Data
Model for Microsoft Modeler r8.2
SQL Azure
Visualize Information Managing Data – Collaboration
from the Web – for All Both On-Premise + in Facilitated
Audiences the Cloud
58. Data Management – Moving to the Cloud
Many customers are nervous moving their data to the Cloud.
Concerns include:
Security/Privacy
Learning curve for new technologies
Integration with other data mgt. systems or applications
A data model can help allay these fears
Assurance that your data is managed securely—using a data model as your roadmap. You
decide what data stays on premise and what moves to the Cloud. Once in the Cloud,
understand and manage the data stored off-premises.
Use Existing Skills: Customers can use the same familiar data modeling paradigm for Cloud-
based data as for their on-premises data using CA ERwin Data Modeler.
Visualize both on-premises (Oracle, Sybase, SQL Server, DB2, etc.) and Cloud-based
databases (MS SQL Azure) from a single data modeling environment
59. CA ERwin Data Modeler for Microsoft SQL Azure
A Data Model is your Roadmap to the Cloud
A Data Model is your “roadmap” for:
What data to move to the Cloud, and what to keep on-premise
Defining data structures (physical model) and business requirements (logical model) for Cloud
databases
Off-Premise doesn’t mean Out of your Control
CA ERwin Data Modeler for Microsoft SQL Azure
Manage data structures in the Cloud on the MS SQL Azure platform
Visualize both on-premise (Oracle, Sybase, SQL Server, DB2, etc.) and Cloud-based databases (MS
SQL Azure) from a single data modeling environment
Oracle
DB2
MS
SQL SQL Azure
Server Sybase
MySQL Teradata
60. CA ERwin Web Portal
Sharing Information with All Audiences
— While some users need a — Many more can access &
desktop tool to build and understand information via
analyze data models, a web-based interface.
Data Database Data Modeler Business
Architect Administrator Analyst
(DBA)
Developer
Business User /
Steward
Data Data Modeler BI Analyst
Architect
DBA MDM Analyst
60
61. CA ERwin Web Portal
Web-Based Search, Impact Analysis, Reporting
The CA ERwin Web Portal makes it easy to share metadata
(information in context) with both Business and Technical users
Internet-Style Keyword Search
Diagram Visualization
Graphical Impact Analysis
Reporting
Interfaces for Business vs. Technical Users
Easy to roll-out to multiple users (no local install)
CA ERwin
Web Portal
66. Active Model Templates
Creating Enterprise Standards
— Ability to Reuse and Synchronize Enterprise Model Objects
with other models across the Organization.
Enterprise Model Objects
Project 1
Synchronize
Project 2
66 February 8, 2012
67. Active Model Templates
— Ability to define “Enterprise” objects for Reuse
− Share individual model objects, not just models
• tables, entities, domains, etc.
− Wizard-driven
− Synchronize with other model objects
• Automatically on model load
• Or manually, user-driven through Wizard
— First phase in “Data Dictionary” style model sharing
− Next Step is Repository (Mart)-based sharing in r9
67 February 8, 2012
