DM39-003 - Implementation Head Start

PPDM Training
PPDM Data Model

Implementation
Head Start
PPDM Version 3.9
January 2018
1 Copyright 2018, PPDM Association. All Rights Reserved

Copyright
Care has been taken to obtain copyright permission to reproduce this
material. Any information that will enable the PPDM Association to
obtain copyright clearance for any material not acknowledged would
gladly be received by:
The PPDM Association

Bankers Hall, PO Box 22155
Calgary, Alberta, Canada, T2P 4J5
Attn: PPDM Association Copyright
email: training@ppdm.org
© 2018, PPDM Association. All Rights Reserved.
These files are for the individual who participated in the course
and are not for distribution. No part of this material may be
reproduced or transmitted in any form or by any means,
electronic, mechanical, recording or otherwise, or by any
information storage and retrieval system without permission
from The PPDM Association.

Exercise
• Create an International, Multi-disciplinary,
Cross Functional, Multi-purpose Data Model
You have 2 years to do it

Learning Objectives
• Able to use the PPDM web site to get information

• Review and identify the key architectural principles of the PPDM
Data Model
• Identify and analyze some PPDM implementation Guidelines
• Describe the methods needed to extend the data model (i.e.
application-centric)

Using the PPDM Web
Site
• Roadmaps
• Data model diagrams
• On-line documentation
• Wiki documentation
• Forum support
• Data definition language

PPDM Roadmaps Business
Associates
BUSINESS ASSOCIATE
BA ADDRESS
• Each box represents a table in PPDM BA SERVICE ADDRESS
• Reference tables are not shown BA SERVICE
• Relationships are greatly simplified BA AUTHORITY
BA AUTHORITY COMP
• Connections (relationships) between modules
are not shown
BA CONSORTIUM SERVICE
BA CONTACT INFO
BA EMPLOYEE
BA ALIAS
BA ORGANIZATION
BA ORGANIZATION COMP
BA PERMIT
BA PREFERENCE
BA PREFERENCE LEVEL
BA XREF

PPDM Physical Model Diagrams
BUSINESS_ASSOCIATE
BA_ORGANIZATION BUSINESS_ASSOCIATE
BA_EMPLOYEE ACTIVE_IND
NIZATION_COMP BUSINESS_ASSOCIATE
BA_ABBREVIATION
BA_CATEGORY
ORGANIZATION_ID
BA_CODE
ORGANIZATION_SEQ_NO EMPLOYER_BA_ID
USINESS_ASSOCIATE BA_NAME
ACTIVE_IND EMPLOYEE_BA_ID
RGANIZATION_ID
ADDRESS_OBS_NO EMPLOYEE_OBS_NO
BA_SHORT_NAME BA_AUTHORITY_COMP
BA_TYPE
RGANIZATION_SEQ_NO
ADDRESS_SOURCE ACTIVE_IND
CREDIT_CHECK_DATE
BA_AUTHORITY
CTIVE_IND EFFECTIVE_DATE
AREA_ID
PPLICATION_ID CREDIT_CHECK_IND BUSINESS_ASSOCIATE
AREA_TYPE EXPIRY_DATE
REA_ID CREDIT_CHECK_SOURCE AUTHORITY_ID
CREATED_DATE POSITION BA E_BA _F K BUSINESS_ASSOCIATE
BA OC_BAO _F K2
REA_TYPE CREDIT_RATING COMPONENT_OBS_NO
DESCRIPTION PPDM_GUID BA E_BA _F K2 AUTHORITY_ID
ONSULT_ID CREDIT_RATING_SOURCE ACTIVE_IND
EFFECTIVE_DATE REMARK ACTIVE_IND
ONTEST_ID BA OC_BAO _F K CURRENT_STATUS AREA_ID
EXPIRY_DATE SOURCE AUTHORITY_LIMIT
ONTRACT_ID EFFECTIVE_DATE AREA_TYPE
MAIN_EMAIL_ADDRESS STATUS AUTHORITY_TYPE
ESCRIPTION EXPIRY_DATE AUTHORITY_TYPE
MAIN_FAX_NUM ROW_CHANGED_BY AUTHORIZED_BY
FFECTIVE_DATE FIRST_NAME CONSULT_ID
MAIN_PHONE_NUM ROW_CHANGED_DATE CURRENCY_CONVERSION
XPIRY_DATE LAST_NAME BA AUC_BA AU_F K
CONTEST_ID
MAIN_WEB_URL ROW_CREATED_BY CURRENCY_OUOM
ACILITY_ID MAIN_EMAIL_ADDRESS CONTRACT_ID
ORGANIZATION_NAME ROW_CREATED_DATE EFFECTIVE_DATE
ACILITY_TYPE MAIN_FAX_NUM EFFECTIVE_DATE
ORGANIZATION_TYPE ROW_QUALITY EXPIRY_DATE
ELD_ID MAIN_PHONE_NUM BA AU_B A_FK3
EXPIRY_DATE
PPDM_GUID PPDM_GUID
FORMATION_ITEM_ID MAIN_WEB_URL BA AU_B A_FK2 FACILITY_ID
REMARK BA O_BA _F K REMARK
FO_ITEM_TYPE MIDDLE_INITIAL FACILITY_TYPE
REMOVED_DATE BA AU_B A_FK REPRESENTED_BA_ID
TEREST_SET_ID PPDM_GUID FINANCE_ID
SOURCE SOURCE
TEREST_SET_SEQ_NO REMARK JURISDICTION
ROW_CHANGED_BY
AND_RIGHT_ID
ROW_CHANGED_BY BA_CONTACT_INFO SOURCE LAND_RIGHT_ID
ROW_CHANGED_DATE ROW_CHANGED_DATE
AND_RIGHT_TYPE ROW_CHANGED_BY LAND_RIGHT_TYPE
ROW_CREATED_BY BA O_BA CI _FK4
ROW_CREATED_BY
BLIGATION_ID ROW_CHANGED_DATE LAND_SALE_NUMBER
ROW_CREATED_DATE ROW_CREATED_DATE
BLIGATION_SEQ_NO
BA O_BA CI _FK3 BUSINESS_ASSOCIATE ROW_CREATED_BY PPDM_GUID
ROW_QUALITY ROW_QUALITY
RGANIZATION_ID2 BA O_BA CI _FK2
LOCATION_ID ROW_CREATED_DATE PROD_STRING_ID
RGANIZATION_SEQ_NO2 ACTIVE_IND ROW_QUALITY PROD_STRING_SOURCE
BA O_BA CI _FK
ALEO_SUMMARY_ID ADDRESS_OBS_NO PR_STR_FORM_OBS_NO

DEN_ID ADDRESS_SOURCE BA _BACI_F K2
REMARK
CONTACT_LOC_TYPE
BA O_B AA_FK
BA _BACI_F K4
DEN_SOURCE SEIS_SET_ID
DEN_TYPE EFFECTIVE_DATE BA _BACI_F K3 SEIS_SET_TYPE
OOL_ID EXPIRY_DATE
BA _BACI_F K
BA_PERMIT SF_TYPE
LOCATION_NAME
PDM_GUID BA_ADDRESS PPDM_GUID
BA CI _BA_F K
SOURCE
ROD_STRING_ID SPATIAL_DESCRIPTION_ID
REMARK BUSINESS_ASSOCIATE
ROD_STRING_SOURCE SPATIAL_OBS_NO
ROW_CHANGED_BY JURISDICTION
ROJECT_ID BUSINESS_ASSOCIATE SUPPORT_FACILITY_ID
ROW_CHANGED_DATE BA P_BA _F K
PERMIT_TYPE
R_STR_FORM_OBS_NO SOURCE UWI
ROW_CREATED_BY PERMIT_OBS_NO
EMARK ADDRESS_OBS_NO BA P_BA _F K2
ROW_CHANGED_BY
ROW_CREATED_DATE ACTIVE_IND
EIS_SET_ID ACTIVE_IND BA CI _BAA _FK ROW_CHANGED_DATE
ROW_QUALITY EFFECTIVE_DATE
EIS_SET_TYPE ADDRESSEE_TEXT BA A_BA CI _FK
ROW_CREATED_BY
EXPIRY_DATE
F_TYPE ADDRESS_TYPE ROW_CREATED_DATE
BA A_BA CI _FK3 PERMIT_NUM
OURCE CITY_ID ROW_QUALITY
BA A_BA CI _FK4 PPDM_GUID
OURCE_DOCUMENT COUNTRY REMARK
UPPORT_FACILITY_ID EFFECTIVE_DATE
BA A_BA CI _FK2
SOURCE
WI EMAIL_ADDRESS ROW_CHANGED_BY
OW_CHANGED_BY EXPIRY_DATE
BA A_BA _F K
ROW_CHANGED_DATE
OW_CHANGED_DATE FAX_NUM ROW_CREATED_BY
BA AUC_S D_FK
OW_CREATED_BY FIRST_ADDRESS_LINE ROW_CREATED_DATE
OW_CREATED_DATE OFFICE_TYPE
OW_QUALITY PHONE_NUM
POSTAL_ZIP_CODE
PPDM_GUID
BA_SERVICE RATE_SCHEDULE SPATIAL_DESCRIPTION
PROVINCE_STATE
REMARK
SECOND_ADDRESS_LINE RATE _BA_F K RATE_SCHEDULE_ID SPATIAL_DESCRIPTION_ID
BUSINESS_ASSOCIATE
SERVICE_QUALITY ACTIVE_IND SPATIAL_OBS_NO
BA_SERVICE_TYPE RATE _SD_FK
THIRD_ADDRESS_LINE CHANGE_NOTICE ACTIVE_IND

BA_SERVICE_SEQ_NO
WEB_URL CITY_ID CARTER_IND
ACTIVE_IND
WITHHOLDING_TAX_IND CONTRACT_ID CONGRESS_IND
EFFECTIVE_DATE
ROW_CHANGED_BY COUNTRY COORD_SYSTEM_ID
EXPIRY_DATE
ROW_CHANGED_DATE COUNTY DLS_IND
PPDM_GUID BA S_BA _F K
ROW_CREATED_BY DISTRICT EFFECTIVE_DATE
REMARK
ROW_CREATED_DATE EXPIRY_DATE
SERVICE_QUALITY
ROW_QUALITY
7
SOURCE
ROW_CHANGED_BY Copyright 2018, PPDM Association. All Rights Reserved
AA_FK
Reading the PPDM Data
Diagrams
In Previous
PPDM Version
New
Table
New
Reference
Table

Reading the PPDM Data Diagrams
Many
Child Table Parent PK part of the child PK Parent
Mandatory relationship, parent must exist
Table
Many
Child Table Parent PK not part of the child PK
Optional relationship, but if used, parent must exist Parent
Table
One
Child Table Parent PK part of the child PK Parent
Table
Although this relationship is used in
PPDM (super sub types), the diagram
tool does not support this notation
Many
Child Table Parent PK not part of the child PK Parent
Table
This relationship is possible, but NOT
used in PPDM. Only PK columns are
mandatory.
PPDM Online Tabs
Search
Documentation
Diagrams
Switch schema
Print options
Columns in subject Column detail
Subject list
Column list
Additional info

PPDM Online Documentation (Wiki): Table
Documentation

Data Model Key Relationships

Well Life Cycle Phase Model Use

Data Definition Language Components
• Mandatory Components
• Table and column definitions – file extension is .tab
• Constraints (primary, foreign, check) – file extension is .con
• Note that in PPDM 3.9, the use of constraints to the R_PPDM_ROW_QUALITY reference table
continues to be mandatory.

Data Definition Language Components
• Optional Components
• Table comments – file name ends with _tcm
• Column comments – file name ends with _ccm
• Table synonyms – file name ends with _syn
• UOM and OUOM constraints – file name ends with _uom
• Note that in PPDM 3.8, the use of constraints to the UNIT OF MEASURE
support module as not mandatory. This rule has been carried forward to
PPDM .9
• GUID extensions – file name ends with _guid
• Recommendation is to implement GUIDS
• Spatial extensions – created during implementation of the spatial
enabling methods (removed in PPDM 3.9)

Multiple Schema Layers
Make PPDM_GUID “Not Null”, add unique index
Add UOM and OUOM / ROW QUALITY Constraints
Table Synonyms
Table Comments Column Comments

Primary Foreign Check
Tables Columns
Keys Keys Constraints
PPDM Compliance measure

PPDM 3.9
Objectives:
PPDM 3.9 Best Practices for Implementation Tables
3000
Support more consistent and rigorous
implementations 2500
80000 2000
70000
1500
60000 Tables
1000
50000 Columns
Constraints 500
40000
30000 0
20000
10000
0
PPDM 18 PPDM PPDM PPDM PPDM PPDM PPDM PPDM PPDM PPDM
1.0 2.0 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

PPDM Model Design Objectives
• Main design focus is on business driven requirements

• How does the data represent the business?
• Based on business requirements collected by workgroups
• Not IT requirements!
• PPDM is not designed for a specific application
• Key objectives
• Keep the model as easy to understand as possible
• Some business knowledge is critical!
• Allow users to implement a subset of the data model
• Control the spaghetti effect
• Allow users to manage data as the business requires through the life cycle (all the detail)
• Support a few important business variations (not everyone has the same business
requirements)

Architectural Principles
1.1 Architectural Principles Overview
1.2 Architectural Principles Change Summary
1.3 Architectural Principles PPDM DDL Components
1.4 Architectural Principles Naming and Design Conventions
1.5 Architectural Principles Constraints in PPDM
1.6 Architectural Principles Design Issues
1.7 Architectural Principles Reference Tables
1.8 Architectural Principles Domains
1.9 Architectural Principles Units of Measure
1.10 Architectural Principles Coordinates
1.11 Architectural Principles Extensibility and Subsetting
1.12 Architectural Principles Meta Tables and Meta Data
1.13 Architectural Principles Discussion
1.14 Architectural Principles Target Deliverables
1.15 Additional Architectural Guidelines and Conventions
For full details, refer to the Architectural Principles

document on the PPDM Web site
PPDM Helps Make Data
Strategic Rather than
Tactical

Data and the Tech Hype Cycle
(after Gartner)
In most technology projects, data is the “red
headed step child” that tags along with the project
as far as is “in scope”.
Peak of
Inflated
Once a technology product is
Expectations
decommissioned, what happens to the data?
Plateau of
Productivity
Slope of
Trough of Enlightenment
Visibility
Disillusionment
Technology
Trigger
Maturity
Data ends up here

If Data and Information are Strategic Assets …
… Pinning your hopes for data

management on a software
Strategic project is unlikely to succeed!
Approach Tactical
Approach
Vision
Stakeholders
Long Term
Software management is
Corp Plan tactical!
Project plan
Executive
support
($)
Corporate Data Build a product
Corporate Stewardship is Strategic!

Resources
Maintain the
product
Corporate
execution
Decommission
Data the product
and data
survives
software

Data is a Strategic Asset
Can you think of any critical Can you think of any critical data or
process through the E&P lifecycle information that has been lost or
where data and information is not corrupted and become unavailable
created or used? to key stakeholders?
We need fundamental change to how we

think about data and information
Data management
objectives must both
Me support and supersede the
We
individual needs of each
stakeholder group or
process, to ensure that
data is stewarded for
others in support of the
corporate goal of data
management.

Match Strength to Strength
Data Management Strategy and Execution
Data as Executive Data Data Data Data

strategic ownership governance stewardship strategies management
initiative V or C level PPP Ownership Plan Execute
Harmonized data and

technology strategies
Technology Strategy and Execution
Identify Plan Execute

Corporate Identify Decommission
candidate technology technology
strategies opportunities technology
technology adoption adoption

Resolve Process and Communication Issues
Words mean different things Communication challenges
Integration
Long Learning Curves
Process are different
People are less portable
Many (aging) Software Integration challenges

applications Workflow Barriers
Rules are different Risk of non-compliance

Possibly out-dated Risk of liability

Horizontal and Vertical
Tables in PPDM

Horizontal and Vertical Tables
Horizontal Table Vertical Table

UWI KB Elev Rig Release UWI Value Type Value
…
UWI1 100 01/10/87 UWI1 KB Elev 100
UWI2 99 09/08/67 UWI1 Rig Release 01/10/87
UWI3 102 02/04/92 UWI1 Name ABC

…
UWI4 87 11/23/87 UWI2 KB Elev 87
UWI5 136 09/09/67 UWI2 Rig Release 09/08/67

Table Design - Horizontal
Behavior pre-designed for all values

in the database by modelers
- Units of measure
- Data type
- Precision
- Reference validation
Benefits
- Higher consistency
- More interoperability
Costs
- Harder to program
- Longer learning curve
- May need extensions

Table Design - Vertical
Behavior must be decided for

every kind of value possible,
usually by users.
- Units of measure
- Data type Control
Column
- Precision
- Reference validation
Benefits
- Works when value types are
unknown
- Easier to code
Costs
- Less Interoperable
- Lower data quality

The Cost of (Vertical) Abstraction
• Much more difficult to standardize

• Content becomes much more variable
• Semantics become a problem
• What happens when our definitions don’t agree?
• Reference tables drive model design
• Reference tables usually highest time and cost for model population projects
• You can’t avoid the work of modeling completely
• Abstraction drives final modeling down to implementation and users
• PPDM 3.9 adds functionality that can help, but it must be supported with code
• SQL constraints don’t support these tools
• See the PPDM Vertical table control

Horizontal – Vertical Pair
• Horizontal Volumes
• BOE
• CO2
PDEN_VOL_SUMMARY PDEN_VOLUME_OTHER
• Gas
#PDEN_SUBTYPE
• NGL #PDEN_SUBTYPE #PDEN_ID
• Nitrogen #PDEN_ID #PDEN_SOURCE
#PERIOD_ID #VOLUME_METHOD
• Oil #PDEN_SOURCE #ACTIVITY_TYPE
• Sulphur #VOLUME_METHOD #PERIOD_TYPE
#ACTIVITY_TYPE #PDEN_PERIOD_ID
• Water #AMENDMENT_SEQ_NO
#PERIOD_TYPE
#PRODUCT_TYPE
• Vertical Volumes #AMENDMENT_SEQ_NO
• By-products …….
…….
• Specific hydrocarbons
• Why?
• Units of measure standardization
down a column

Model Design Outcomes
Things that add value Things that may be challenges for implementation
• The model is well positioned to support expansion • More horizontal tables, fewer vertical
− Start with a small part, and grow as you need to tables
• Business users can understand the model (with help) • More tables are needed to store
information than in most historical
− It’s their data; they should understand it!
systems
• The model is very flexible and powerful
− This is a consequence of business
− $100 M of Business input! modeling
• Queries can be complicated

There are some legacy inconsistencies, often to
− Community sharing
support regional variations, but sometimes to support
commonly agreed performance issues (denormalizations). • It can be difficult to figure out where
information should be stored
• Members are committed to working through these over
time − Use the forums and the wiki

Tips and Hints
Use vertical tables with care. The flexibility of

the structure can also create problems with
data quality and consistency, data retrieval
and performance.
✓ The TYPE controlling columns govern the behavior

of vertical tables in PPDM 3.9
✓ Populate the TYPE column with great care - this is
the key for success
✓ Use the Vertical support tables in PPDM to help
manage the contents
✓ Add views based on TYPE

Celestial Emporium of Benevolent Knowledge
• Those that belong to the emperor
• Embalmed ones
• Those that are trained Super / Sub Types
• Suckling pigs
• Mermaids (or Sirens)
• Fabulous ones
• Stray dogs
• Those that are included in this classification
• Those that tremble as if they were mad
• Innumerable ones
• Those drawn with a very fine camel hair brush
• Et cetera
• Those that have just broken the flower vase
• Those that, at a distance, resemble flies

Kinds of Hierarchies
It is usually more natural to define AREAS

as a decomposition hierarchy.
In that sense, Canada is “a KIND OF”

Country, but “Part of” North America
We do not treat AREA as a super-sub type

set
Many legacy systems wander between

“kind of” and “part of” semantics, often
creating functional problems.

What is a PPDM Super / Sub Type?
PPDM uses super / sub types in cases where we need to capture detailed information about
specific kinds of objects, but want the referencing systems to be as simple as possible.

Sub Type is “a kind of” the Super Type
Some information is relevant for all canines (or vehicles), but some is specific to dogs
or wolves (or cars or airplanes)
Land Rights are an

example of “a Kind Of”

Sub type “Takes on the identity of …”
Each Production Entity (PDEN)

assumes the identity of an
object described elsewhere in
the model.
For details about the object, go

to the appropriate subject area.

Undetermined Number of “types”
• Where a complete list of the “kinds of” subtype
exist cannot be pre-defined, only the super type
is created.
• In some cases, the nature of the subtype may
not be important (yet). It will start life as a
super type and be converted to a super / sub
type when needed.
• The identify of the subtype is defined by the user,
using the second column in the PK. This column
is controlled by a reference table.
AREA FACILITY
# AREA_ID # FACILITY_ID Support
# AREA_TYPE # FACILITY_TYPE Facilities
converted to
Super / Sub
types

Design Rules
• The relationship between the super and sub type table is always 1:1 (the primary key in both tables
contain the same columns).
• A foreign key is created from the parent to the child (the super type must exist before a row in the sub
type can be created).
• One of the primary key components is an IDENTIFIER column, which must be identical in both parent
and child.
• An additional primary key column is created in both tables, is defined as varchar2(40), and is validated
by a check constraint. This column is named XXX_SUBTYPE in PPDM 3.9 (XXX_TYPE in PPDM 3.8)
• In the Super Type table, the Check Constraint requires the value of the XXX_SUBTYPE column to equal
the name of ANY of the sub type tables.
• In each Sub Type table, the Check Constraint requires the value of the XXX_SUBTYPE column name to
equal the name of the table the column is in. In all cases, this value must also exist in the check
constraint for the super type table.
• Relationships to other business modules in PPDM 3.9 should be modeled at the Super Type level.
• Relationships to detail tables in the subject areas should be modeled at the Super Type level or the Sub
type level, as appropriate.

Usage Best Practices
It is Critical to be sure that you

populate BOTH the super type table and
the sub type table when creating data.
If you do not, you may lose important
information or relationships.
Example
If you populate PDEN and PDEN_TYPE = 'PDEN_WELL', you must also put a row of
data into PDEN_WELL. The foreign key relationship to the well whose identity the
PDEN is assuming is in PDEN_WELL.

Table
Row
Tables and Columns
Naming conventions
Class words
Column
Domains
Column Types

Naming Conventions 1
• Name Length and Characters
• Tables 30 characters
• Columns 30 characters
• The total row length may not exceed 8060 bytes
(SQL Server)
• UPPER_CASE, numbers and ‘_’ only
• Separate components with “_”
WELL_PRESSURE_AOF
• Synonyms
• Each table assigned a SYNONYM #UWI
#SOURCE
• Used to name constraints
#PRESSURE_OBS_NO
• (i.e. SYNONYM_PK)
#AOF_OBS_NO
• Intended to reduce query collisions …….

• Components
• Subject area context
• General to specific MODIFIER3
SUBJECT MODIFIER1 MODIFIER2
(sub-
• Intuitive AREA (sub-area) (grouping)
grouping)
• Single parent cross reference
• %_XREF
WELL
• Multiple relationships between
subjects WELL PRESSURE
• Usage consistency
WELL PRESSURE AOF
• Domains
• Class words WELL PRESSURE AOF 4PT

AREAS
• Spelling
AREA
• Singular
• Present tense AREA_CONTAIN
• Consistent abbreviations and terms
• Unambiguous AREA_DESCRIPTION
• COMP, REC
• Multiple uses of a FK column (such as business Associate) AREA_ALIAS
• Avoid connectors 'A', 'AN', 'AND', 'OF', 'OR', 'THE'
• Avoid using terms in reserved words lists (use multi
AREA_XREF
component terms)
• Do not take vowels out of names in order to abbreviate AREA_HIERARCHY
• This is a new rule; some older tables violate it
• Deprecation AREA_HIER_DETAIL
• Tables to be deprecated are prefixed with Z_ for one release
• Do not use these tables for new implementations AREA_CLASS
• Convert old applications (have about 2 years notice)

Column Types
Simple content
Each column contains one type of information
Information is not usually concatenated
Identifiers
Could be implemented as natural or surrogate
Cost / benefit of both approaches
Column data types
Char (Oracle = varchar2)
Number (includes precision)
Numeric (no precision)
Date
Blob (used twice only)

Standard PPDM Columns
• ACTIVE IND
• EFFECTIVE DATE
• EXPIRY DATE
• PPDM GUID Use of a trigger to populate?
• SOURCE
• REMARK
• ROW CHANGED BY
• ROW CHANGED DATE
• ROW CREATED BY
• ROW CREATED DATE
• ROW EFFECTIVE DATE
• ROW EXPIRY DATE
• ROW QUALITY

Source
• Details about the source can be managed in R_SOURCE_ORIGIN.

• SOURCE column (with a constraint to R_SOURCE) is added to every table, unless
the work group determines that inherited versioning is to be used.
• The SOURCE of the parent table will always equal the source of the child table.

ROW CHANGED BY
• This should be added to every table in the data model.

• In many cases, this will be the system-assigned userID of the person who changed
the data, but business rules may dictate the use of other information.
• Many users populate this value by trigger on INSERT and on UPDATE.
• Others populate this value by trigger only on UPDATE (in this method, the column
value may be NULL, making certain types of query more difficult).
• An implementation must create a business rule about which method they will use
and enforce consistency throughout their systems.

ROW CHANGED DATE
• Should be added to every table in the data model.

• Usually the system date of the change.
• Many users populate this value by trigger on INSERT and on UPDATE.
• Others populate this value by trigger only on UPDATE (in this method, the column value
may be NULL, making certain types of query more difficult).
• An implementation must create a business rule about which method they will use and
enforce consistency throughout their systems.

ROW CREATED BY

• In many cases, this will be the system assigned userID of the person who
changed the data, but business rules may dictate the use of other information.
• Many users populate this value by trigger on INSERT.

ROW CREATED DATE
• Usually the system date that the data was added.
• Many users populate this value by trigger on INSERT.

REMARK
• Should be added to every table in the data model, unless there is a %_REMARK
subordinate table.
• This column should not be used to store “structured” data when a specific
column can’t be found.
• Used for narrative comments about the data, usually from the perspective of the
business (not IT)

EFFECTIVE DATE
• Indicates the date that this data first came into effect from a business perspective. It is
a business value, and should be derived from business information.
• In business transactions, this date may be before or after the date the data is added to
the database.
• For reference tables, this is often the date that a value is included for use (approved by
the business).
Note: This column is NOT intended to be used for information about the technical
implementation or management of the data in a table.
• If a system date is to be used, the system date should be based on the needs of the
business, rather than on dates that system transactions occur (even if those dates may
turn out to be the same date).
• A new column ROW_EFFECTIVE_DATE, is added to PPDM 3.9 for this purpose.

EXPIRY DATE

• Indicates the date that this data is no longer in effect. It is a business value, and
should be derived from business information.
• In business transactions, this date is often the date that the information becomes
obsolete, invalid or is replaced, such as the date that a contract expires, or a
reference value is not to be used any longer. Note that expiry dates may exist in the
future.
• Note: Please note that this column is NOT intended to be used for information about
the technical implementation or management of the data in a table.
• If a system date is to be used, the system date should be based on the needs of the
business, rather than on dates that system transactions occur (even if those dates
may turn out to be the same date).
• A new column ROW_EXPIRY_DATE, is added to PPDM 3.9 for this purpose.

ROW EXPIRY DATE
• The ROW EXPIRY DATE column is intended to be used for information about the
technical implementation or management of the data in a table.

ROW EFFECTIVE DATE
• ROW EFFECTIVE DATE column is intended to be used for information about the
technical implementation or management of the data in a table.

ACTIVE IND

• Indicates whether this row of data is currently valid.
• Setting this flag to N allows users to retain archival data but disallow its use in
current application. This is a “soft delete”.
• This column is implemented as varchar2(1).
• A check constraint is used to enforce the population as “Y”, “N”, or NULL

ROW QUALITY
• Indicates the quality of a row of data in a table.
• Information about every attribute in a row may be stored in other tables

in PPDM, including PPDM_AUDIT_HISTORY and
PPDM_QUALITY_CONTROL.

PPDM GUID
• Should be added to every table in support

of GUID practices.
• An optional set of DDL is provided that will
change the GUID columns to NOT NULL
and add unique indexes to each.
• Functionally, the PPDM_GUID column aids
in the creation of a Data Coordinate
Reference System

Sample Triggers
CREATE or REPLACE TRIGGER INS_AREA CREATE or REPLACE TRIGGER UPD_AREA
BEFORE INSERT ON AREA BEFORE UPDATE ON AREA
for each row
for each row
BEGIN
BEGIN if (:new.ppdm_guid is null) then
if (:new.ppdm_guid is null) then :new.ppdm_guid := sys_guid();
:new.ppdm_guid := sys_guid(); end if;
end if;
:new.row_changed_date := sysdate;
:new.row_changed_by := user;
:new.row_created_date := sysdate; END;
/
if (:new.row_created_by is null) then
:new.row_created_by := user;
end if;
END;
/

PPDM Domain Consistency
• Manage consistency for common kinds of information across model
• There are many
Depth number 15,5
Identifier varchar2 40
Type varchar2 40
Short name varchar2 30
Indicator (Y or N) varchar2 1
Seq_no number 8
Obs_no number 8
Latitude / Longitude number 14,9
Remark varchar2 2000

Class Word Consistency
• Used to classify the type of information
• Usually the last component of the name
ALIAS Alternate name

DATE Date
TEMP Temperature
IND Y / N flag
LAT Latitude
LONG Longitude
LONG_NAME Long names
NUM Character string
NO Number
Data Coordinate
Reference System
• Find any value in any table or system!

What is a GUID?
• Globally Unique Identifier What is unique in your system?

• Usually a hexadecimal number • RDBMS?
• 34 hex digits grouped into • Server?
chunks • Instance?
• 8-4-4-4-12 • Test v development v production
• 10^38 numbers available • Federated data stores
• Four basic kinds
• Randomly assigned
• Time based (watch out for time
zones)
• Hardware based (watch out for
privacy violations)
• Content based (hashed data)

Abstract References
• While abstract references are not

supported in native SQL language,
it is very handy to be able to find
or reference
1
2 3 4

Define Data Coordinates
This combination of values is unique!
• SYSTEM_ID
• TABLE_NAME
• COLUMN_NAME
• PPDM_GUID
Use Data Coordinates to uniquely identify any value in a

data model!
This concept is used extensively in parts of the data model

Using Data Coordinates
• Populate the data coordinates in any table where

they are used to provide a single mechanism to
indicate any specific
System
Table
Column
Row
• Once complete, you have identified a specific and

unique data value

Constraints
• Primary Keys
• Foreign Keys
• Check Constraints
• Arcs

Constraint Guidelines
Platform independent solutions

SQL 92 entry level
Enforceable using native DDL only

Limit need for triggers
Facilitate good data management
Facilitate query / retrieval

Things to be Aware of
• Keep in mind that because many tables are used in MANY relationships in PPDM, you
will need to configure your system to allow UPDATES, INSERTS and DELETES to
these tables over time.
• Some RDBMS have limitations on the number of times a table can be referenced in a
foreign key (some versions of SQL*Server limit this to 256).
• Some RDBMS have limitations on the number of FK that can be in a table (some
versions of SQL*Server limit this to 256).
• Some RDBMS may require you to have sufficiently large update or pool spaces to
allow updates to be committed.
• Although this will be easy at the start of your PPDM project, the problem will grow
as the number of times a value is referenced by other constraints increases.

Primary Key
WELL
An ordered group of columns in a table which Use surrogate components #UWI

…….
defines uniqueness for every new row of data in when necessary
the table
• In addition to
• May consist of one or more columns
natural key WELL_TEST
• All values must be known at insert time components #UWI

#SOURCE
Every table in PPDM has a primary key PK may not include #TEST_TYPE
#TEST_NUM
• Primary Key for WELL is UWI. • Dates …….
• Columns in the PK are mandatory • Measured Values

WELL_TEST_CUSHION
• Columns from Parent PK cascade down Primary key name
#UWI
Use natural keys unless • SYNONYM_PK #SOURCE
#TEST_TYPE
• No natural identifier exists #RUN_NUM
#TEST_NUM
• Concatenated key is unwieldy #CUSHION_OBS_NO
…….

Primary Keys Often Cascade

Foreign Key
• Foreign keys create relationships between tables WELL
• value in child table must be matched to the parent table #UWI

before new data may be inserted or updated …….
• Columns
• one or more
• mandatory or optional
• Examples
• subject hierarchy PROD_STRING
• reference tables (R_%) #UWI

#SOURCE
• Foreign key name #STRING_ID
…….
• SYN(CHILD)_SYN(PARENT)_FK
• If more than 1 FK exists
• SYN(CHILD)_SYN(PARENT)_FK1
• SYN(CHILD)_SYN(PARENT)_FK2 etc

Many to Many Relationships
Many to many relationships are common in our industry…
But databases can’t handle them this way

Many to Many Relationships
Intermediate breakout tables can be implemented in an RDBMS
Additional detail qualify or describing the relationship can be added

Special Foreign Keys
• Recursive PPDM 3.2
• A table contains a reference to itself
• Create problems for the “load of the rings”
• Query with “connect by” procedure
• Many have been eliminated from PPDM 3.8

Using %_XREF tables
Best Practice: use the first primary key to

indicate the parent that exists at a HIGHER
hierarchical level and the second to indicate
the parent that exists at a LOWER (or
CONTAINED) hierarchical level.
Best Practice: take great care in

designing the values to be used in the
XREF TYPE columns, as they will be
essential to your success.

Using %_XREF tables
• An XREF table provides you with an opportunity to capture indirect relationships in
addition to direct relationships. (Only direct relationships can be stored in a recursive
relationship.)
• The advantages of capturing indirect relationships are:
• You don’t need to use a connect by query to retrieve.
• Relationships are explicit.
• You can navigate from parent to grandchildren directly (without using CONNECT BY queries).
• The disadvantages of capturing indirect relationships are:

• Data relationships that are calculated using direct relationships can fall out of synch only with
indirect relationships that are stored explicitly (be careful how you manage this).
• They require more work to maintain.
• They involve more rows of data.

Using %_XREF Tables
XREF_TYPE
DATA STORE DATA STORE Direct and Indirect
XREF_ID Values are
ID ID2 Relationships
examples only
Warehouse 1 a Bay 1 Warehouse - Bay
Warehouse 1 b Bay 2 Warehouse - Bay
Best Practice: Some XREF tables have
Warehouse 1 c Unit A Warehouse - Unit
Warehouse 1 d Unit B Warehouse - Unit
the potential to become relatively large.
Warehouse - We recommend that data be pre-sorted
Warehouse 1 e Shelf 1 when possible so that data likely to be
Shelf
Warehouse - queried as groups are inserted
Warehouse 1 f Shelf 2 sequentially.
Shelf
Bay 1 g Unit A Bay - Unit
Bay 1 h Unit B Bay - Unit
XREF_TYPE
DATA STORE
DATA STORE ID XREF_ID Values are
ID2
examples only
Warehouse 1 a Bay 1 Warehouse - Bay
Direct Relationships
Warehouse 1 b Bay 2 Warehouse - Bay
Only Bay 1 c Unit A Bay - Unit
Bay 1 d Unit B Bay - Unit
Unit A e Shelf 1 Unit - Shelf
Unit A f Shelf 2 Unit - Shelf
Using Recursive Relationships
To load these tables with constraints enabled:

• The data must be sorted so that parents are loaded
(inserted) first, with all of the rest of the rows sorted
into sequential order after the parent. In other words,
you must insert data from the outermost (the
Warehouse) in (to the individual slots on the shelves).
• The data store at the top or first level may not be
contained by another data store
(CONTAINED_BY_DATA_STORE_ID must be NULL).
• As each parent is loaded, the row must be COMMITTED
so that it is available for reference by the
CONTAINED_BY_DATA_STORE_ID foreign key in
subsequent rows of data.

Populating Recursive Relationships
You can also choose to
populate the indirect
relationships, as we showed
DATA STORE ID CONTAINED BY DATA with the XREF tables.
STORE ID
How does your database
Warehouse 1 query these tables?
Bay 1 Warehouse 1
Bay 2 Warehouse 1
Unit A Bay 1
Unit A Bay 1
Unit B Bay 2 ...

Populating Recursive Relationships
• Experienced developers may recall these data structures as similar

to “N lists.” The relationships exist as a tree, with nodes or
branches. In order to query these structures, the query normally
identifies a row somewhere in the set of relationships and then
queries up or down the nodes along the path.
• These queries are not included in the ANSII SQL standard; each
relational database vendor has created a proprietary method for
querying these structures. Please consult your RDBMS vendor for
the most appropriate solution.
• Think of these queries as travelling up or down a pyramid.
• If you start at the top, and travel down the relationships, you can
discover all of the data stores that are contained by the
warehouse.
• If you start at the bottom, you can take a specific data store and
determine exactly which parent data stores contain it.

Reciprocating constraints
• Each table contains FK constraints from the other
• Denormalized constraints
• Removing these as supported by members
PPDM 3.2
This relationship is easier to
manage, and offers business
SEIS_LINE (or benefits!
SEIS_SEGMENT)
First Point
Last Point
SEIS_POINT

SOURCE and ROW QUALITY

• Require special load handling
• Insert followed by update

Indirect Relationships
If you are managing the values in

R_AREA_TYPE, use care to be sure you
manage both direct and indirect
relationships.
AREA has a FK to R_AREA_TYPE
LAND_AREA has a FK to AREA but

does not have a FK to R_AREA_TYPE

Multi Column PK and Data Validity
PK COLUMN AREA_ID AREA_TYPE
123 Canada Country
234 Astralia
456 Australia Country
Best Practice: Every time you populate a FK, take care to

populate ALL columns in the FK, or the constraint will not fire,
and referential integrity rules will not be enforced. This allows
corrupt data to enter your database!
Exception: In some tables (such as WELL_TEST_PRESSURE) you
may not have value to populate all columns, so a FK will not be
used, even though most of the columns will be populated.
Complex Foreign Keys
FK rules define how data is handled by a database
or application
Needs are defined by work groups
• in the BRD
• some can be enforced by the database
• others require intervention
Group discussion
• How many UWI Columns should exist in
WELL_TEST_PRESS_MEAS?
• Data Rule: Each well test pressure
measurement is created during a test on a
well, and the recorder must be installed on
the same well, during the same test and in
the same recording period.

Example - WELL_TEST_PRESS_MEAS
WELL_TEST • Every WELL_TEST must be

associated with a valid WELL.
WELL_TEST_PRESS_MEAS • Every WELL_TEST_PERIOD must be
# UWI
associated with a valid WELL_TEST.
# SOURCE
WELL_TEST_PERIOD • Every WELL_TEST_RECORDER must
# TEST_TYPE
# TEST_NUM be associated with a valid

# RUN_NUM
WELL_TEST.
# MEASUREMENT_OBS_NO
• Additionally, in order to be valid,
RECORDER_ID
PERIOD_TYPE
WELL_TEST_ the WELL_TEST_PRESS_MEAS
RECORDER
PERIOD_OBS_NO
values that are recorded must all
be associated to the same
WELL_TEST and the same WELL.

Multiple Constraints / Column
Columns are referenced in more than one constraint

• Unusual from pure data modeling aspect
• Compliant with Architectural Principles
• Protect the user from data corruption by preventing more than one UWI from being
referenced
UWI NOT NULL WELL_TEST_PERIOD

WELL_TEST_RECORDER
WELL_TEST

Multiple Columns / Constraint
• Components NULL, NOT NULL
• Part of the constraint is included in the Primary Key, therefore mandatory
• The rest of the constraint reflects the optionality of the relationship
UWI NOT NULL WELL_TEST_PERIOD

SOURCE NOT NULL WELL_TEST_PERIOD
TEST_TYPE NOT NULL WELL_TEST_PERIOD
TEST_NUM NOT NULL WELL_TEST_PERIOD
RUN_NUM NOT NULL WELL_TEST_PERIOD
PERIOD_TYPE WELL_TEST_PERIOD
PERIOD_OBS_NO WELL_TEST_PERIOD

PPDM is Denormalized – Beware!
DATA_ DATA_
• Three places for STORE_ID STORE CONTENT
STORE_
• Each meets specific user need
ID
• Primary location
PHYSICAL_
• PHYSICAL_ITEM_STORE ITEM
• populate other columns only if needed STORE_
ID
• use triggers and stored procedures to keep in
synch
PHYSICAL_
ITEM_
STORE
STORE_
ID

Denormalization Best Practices
Best Practice: Ideally, the fully normalized location for a data value should be
used. The denormalized column (located in a parent table) is added to support
legacy implementations and should not be used for new implementations.
Best Practice: When populating a denormalized column, do so via a trigger or

stored procedure deployed from the primary (normalized) data location. Never try
to keep these values synchronized manually; the “data trust” risks associated with
un-synched values is very high.

Component Tables
• Handle multiple FK relationships with a business
object
.
.
• Easier to query than many separate tables . .
. .
. .
• Component tables exist in both directions

• Populate one consistently
• Load the other with procedure Component
• Index with care!

Subject
• Views may be helpful Parent
WELL_COMPONENT
#UWI Detail Detail

#COMPONENT_OBS_NO
…….
Detail Detail

Component Tables
• Component tables in PPDM are created in order to allow implementers to create a relationship
between any two subject areas as needed. Each component table contains a primary key that is
derived from the parent table in a subject area (such as WELL or LAND_RIGHT). In this table, the
designer inserts the foreign key from the parent tables of each of the other major subject tables,
• A foreign key from a reference table that is used to describe the FUNCTION of each relationship.
Use this table to explain WHY you have created the relationship to the object.
• Query optimizers may have difficulty working with tables that have lots of foreign keys. This is
particularly true for COMPONENT tables.
• Component tables help users of a PPDM-based system to identify a business object (such as a
well) and to quickly identify all of the other business objects in other subject areas that are
related to that well (such as land rights, contracts, restrictions, documents or HSE incidents).
• Many users describe this as like finding meatball in a bowl of spaghetti and pulling on it to quickly
find everything else that is connected to it.

Component Table Complexity
Which should you use?

Check Constraints
• Check constraints are used when the data model workgroup knows what the allowable
values are at design time, and need to ensure that every use of that column is
consistent through the entire data model and for every use. This consistency is an
important strategy in PPDM’s intention to support interoperability between
implementations of the PPDM Data model.
• Check constraints are used to control the creation and behavior of super / sub type
table sets.
• The values are intentionally placed in the DDL, as they are not user controlled.
• Users should not change these values!

Using Check Constraints in Super / Sub Types
• The values used for the check constraints TYPE column must be exactly the same as the
names of each of the subtype tables.
• Every subtype (child) table name is included.
• The supertype (parent) table name is not included in the check constraint list.
• Values that are not the name of a subtype table may never be used.
• The names must be exactly the same as the name of the subtype table.
• The primary key of every table in the set must be at least 2 components:
• The first component identifies which of the subtype tables is used.
• Column name:
• In PPDM 3.8, this column is named %_TYPE and is the second part of the PK.
• In PPDM 3.9, this column is named %_SUBTYPE and is the first part of the PK.
• The second component of the Primary Key provides uniqueness.
• The value of the second component must be the same in the supertype and subtype tables.
• For every unique value in the Supertype table, that same value may be used in exactly one and only one
of the subtype tables.

Using Check Constraints in Super / Sub Types
• Check constraints are created to control the values that may be used.
• In the supertype (parent) table, the column may contain any of the subtype table names.
• In the subtype (child) table, the column may only contain the name of the table it is in. This
prevents users from using the wrong subtype table.
• In every super subtype table set, it is mandatory to populate both the super type and
the subtype tables.
• If a row is created in the supertype table, it must be related to a corresponding row in one
and only one of the subtype tables.
• If a row is created in the subtype table, it must be related to a corresponding row in the
supertype table.

Check Constraints
• Embedded in the Oracle DDL

• Managed by table owner - not end users
• Validate input data
• yes / no flags - %_IND (Y, N, NULL)
• refer to a PPDM table – LAND_RIGHT_TYPE (LAND_TITLE,
LAND_AGREEMENT, LAND_UNIT ...)
• Do not change the check constraint values!

PPDM Load of the Rings
• Maintain Data Integrity
• Objective: Load data into PPDM with all foreign and LOAD OF THE RINGS
not null constraints enabled
• Benefit: Improved data validation and verification
600
543
500
400
R_SOURCE R_PPDM_ROW_QUALITY
300
#SOURCE #ROW_QUALITY_ID
ROW_SOURCE ROW_QUALITY
ROW_QUALITY 200
SOURCE
100 69 78 83
57 65 66
41 40 48 45 39 38
18
2 4 1 1
0
RI 0
RI 2
RI 4
RI 6
RI 8
RI 0
RI 2
RI 4
RI 6
RI 8
RI 0
RI 2
RI 4
RI 6
RI 8
RI 0
RI 2
34
0
3
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
NG
RI
From the LOTR Spreadsheet
TABLE_NAME TABLE_RING_LEVEL
APPLICATION RING18
APPLICATION_COMPONENT RING24
1. Order by Table
APPLIC_ALIAS RING20
APPLIC_AREA RING20
APPLIC_ATTACH RING20
APPLIC_BA RING20
APPLIC_DESC RING20
APPLIC_REMARK RING20 TABLE_NAME COLUMN_NAME RING_LEVEL GROUP
AREA RING06 APPLICATION ACTIVE_IND RING00 INSERT
AREA_ALIAS RING10
APPLICATION APPLICATION_ID RING00 INSERT
AREA_COMPONENT RING24
APPLICATION APPLICATION_TYPE RING04 INSERT
AREA_CONTAIN RING08
AREA_DESCRIPTION RING18 APPLICATION CONTRACT_ID RING18 INSERT
BA_ADDRESS RING08 APPLICATION CURRENT_STATUS RING04 INSERT
BA_ALIAS RING10 APPLICATION DECISION RING04 INSERT
BA_AUTHORITY RING10
APPLICATION DECISION_DATE RING00 INSERT
BA_AUTHORITY_COMP RING24
BA_COMPONENT RING24
APPLICATION EFFECTIVE_DATE RING00 INSERT
BA_CONSORTIUM_SERVICE RING16 APPLICATION EXPIRY_DATE RING00 INSERT
BA_CONTACT_INFO
2. Order by Column
RING12 APPLICATION EXTENSION_ID RING18 INSERT
BA_CREW RING10 APPLICATION FEES_DESC RING00 INSERT
BA_CREW_MEMBER RING12
APPLICATION FEES_PAID_IND RING00 INSERT
BA_DESCRIPTION RING18
BA_EMPLOYEE RING06 APPLICATION PPDM_GUID RING00 INSERT
APPLICATION PREVIOUS_APPLICATION_ID RING19 UPDATE
APPLICATION RATE_SCHEDULE_ID RING16 INSERT
APPLICATION RECEIVED_DATE RING00 INSERT
APPLICATION REFERENCE_NUM RING00 INSERT

Populating Tables with Constraints
PPDM 3.2
• Do NOT disable constraints!
• INSERT rows in SEIS_LINE (except for first and last
point identifiers).
• INSERT rows in SEIS_POINT.
• Determine which points are first and last for each
line.
• UPDATE rows in SEIS_LINE (add first and last point
identifiers).
PPDM 3.8
1. INSERT into SEIS_SET
2. INSERT into SEIS_POINT
3. INSERT into SEIS_POINT_SUMMARY

R_SOURCE and R_PPDM_ROW_QUALITY
To load data into these tables, you should use the following sequence:
1. Determine and document in PPDM_RULE:

• How R_SOURCE will be used
• How R_PPDM_ROW_QUALITY will be used
2. INSERT into
• R_SOURCE (except for ROW_SOURCE and ROW_QUALITY)
• R_PPDM_ROW_QUALITY (except for SOURCE and
ROW_QUALITY)
• Commit
3. UPDATE
• R_SOURCE (ROW_SOURCE and ROW_QUALITY)
• UPDATE R_PPDM_ROW_QUALITY (SOURCE and
ROW_QUALITY)
• Commit.

Tips and Hints
Best practice is to NEVER disable constraints. Loading data with constraints

enabled can be tricky. Use the Load of the Rings to load data.
Don’t alter check constraints.
Use reciprocating values and denormalized columns ONLY if you need to improve
performance! Populate them by procedure from their “home” location.

Exclusive Arcs
• Exclusive arcs
This legacy issue
• One and only one of the FK can be populated
has been corrected
• table may contain a Foreign Key from any one of a set
of parent tables
• cannot be implemented in SQL
• managed in PPDM through Check Constraints. These
are used in all super-sub types.
Check
constraint in
PK

Non Exclusive Arcs
Non-exclusive arcs
• table may contain a Foreign Key from any of a
set of parent tables
• RDBMS require special procedures to manage
(triggers etc.)
• Each row of data populates only the FK
relationships that are appropriate
• In %_COMPONENT tables, populate only one
business object at a time, unless they are
connected by a logical “and” clause.

Arcs Architectural Principle
Architectural Principle
• Managed arcs are controlled with check
constraints
• All super – sub type sets
• Non-exclusive arcs are only allowed as
optional relationships
• E.g. component tables
• Un-managed arcs may not be part of the
Primary Key
• removed from 3.4

Tips and Hints
Arcs can be used to show some important business rules. Be careful

how you implement them.
ü COMPONENT tables – one FK per row unless they are connected by a
logical “AND” clause.
ü Sub types – populate super and subtype tables.
Unmanaged arcs are never part of the Primary Key of a table (since
PPDM 3.4)

Indexes
• Deliverables
• Guidelines

Index Deliverables
PPDM provides a starter set of indexes
• Primary Keys
• Foreign Keys
Many indexes for some tables

• Some are redundant at high levels
PPDM does not provide:

• Tuning indexes
• Indexes on non-Foreign Key columns

Index Recommendations
Understand the business needs:
• Typical queries
• Concurrent online updates
• Nightly batch updates
Add tuning indexes
• To non-FK columns
• Use bit map indexes for reference tables or small tables
Don’t index everything!
Reference tables benefit from Bitmap indexes (save space, faster)

Multiple
Occurrences
• Version Control
• Sequence Control

Version Control
Source version
Inherited version
Alias version

Source Version
Different versions of data may be received from different vendors
• Preferred data kept in main business table
• Vendor specific data kept in VERSION table
Source part of the primary key
WELL
R SOURCE
WELL
VERSION

What does “SOURCE” Mean?
Purchased
Service Data
Operator Regulator by
Company vendor
operator
What is the source of the data?
PPDM does not say –

implementation teams should
decide
• Document in RULES
• Follow consistently

Inherited Version
Source of parent is inherited by the

children
• All of the technical data for a core or WELL
log MUST come from the SAME source.

R SOURCE
• If you have a different source, you
must create a new WELL_CORE (or WELL CORE
other parent)
Widely used in the well model

WELL CORE WELL CORE WELL CORE
ANALYSIS DESCRIPTION SHIFT

Alias Version
A business entity may be known by many names,
codes or identifiers Can indicate the owner (BA) or application
• AREA_ALIAS that uses an alias.
• SEIS_ALIAS
• BA_ALIAS Very useful for integrating many applications
• WELL_ALIAS with PPDM
• LAND_ALIAS
SEIS SET
Names may change over time
Different applications may use different identifiers

• SAP
• Openworks, Geoframe …
Different BA’s may use different identifiers SEIS ALIAS
Alias tables have been harmonized

Sequence Control
• Chronological sequences
• Ordered sequences
• Observation sequences

Chronological Event Sequences
Need to track both current and history Physical Circ ID Date Who
Item
The version of the data is based on date
• Data Circulation ABC 1 94-03-08 J Doe
• Status
ABC 2 94-06-29 B Lind
Surrogate PK component
ABC 3 95-04-19 J Clarke
Date attribute BCD 1 94-03-13 J Doe

• optional
• not part of PK
• date, date/time
CDE 1 94-03-29 J Doe

Ordered Sequences
Defines an ordered sequence of events,
things or processes:
• Shot point acquisition (tape recorded
order)
• shot point spatial sequence
Survey Recorded
Station
Format number
sequence sequence
number number
• number 8
1 1 1
2 2 2
Class Word 3 3 3
• xxx_seq_no Seismic acquisition
4 4 (interpolated)
5 5 (interpolated)
sequence and spatial
sequence may not be
6 6 (interpolated)
the same
7 7 6
8 8 5
9 9 4

Observation Sequence
Each instance of the data is
determined through a separate
observation
• Well Core Analysis
Order is not significant, or can

be calculated Format
• Number 8
Class Word
• xxx_obs_no

Tips and Hints
Columns named %_SEQ_NO imply that data order is important.

• Re-start numbering at 1 for every new parent
• Sort the data into the correct order before loading
Columns named %_OBS_NO are simply surrogate identifiers.

• Re-start numbering at 1 for every new parent
• Use a trigger or procedure to increment the OBS_NO for every new row

Exercise
A sample set of tables has been
provided.
Use the PPDM Architectural Principles Companies

Addresses
PK ID
• Rename the tables and columns. PK Address id
Name
• If you need to create a new table or Address
Client_cust
Address
Moved in
Phone number Moved out
relationship, do so Reference number Ship bill
Credit limit USD Phone number
PO FK1 ID
What problems might you find when Stakeholder
Working Interest
these tables are integrated with other
systems?

PPDM
Vertical Tables

Vertical Tables Functions
Vertical tables store information in the form Property Type + Property Value.
Vertical tables are useful when

• A complete list of data attributes needed cannot be determined at design time
• The list of data attributes may change often, and rapid change response is needed
A vertical table must allow a wide variety of descriptive information (property values) to be
stored.
• Dates
• Currencies
• Measured values (with units of measure)
• Values selected from code lists
• Open text
• Value ranges (min and max)
• Combinations of values (a value and a narrative statement)

Vertical Tables in PPDM 3.8+
In each vertical table
• number values are stored in columns with NUMBER format
• date values are stored in columns with DATE format
• text values are stored in columns with VARCHAR(2) format.
Each vertical table is controlled by a reference table (property type table).
The property type table can be used to define rules about how each property type should
behave
• If the value to be entered is a date, which column should I use?
• How much precision for these measures?
• What unit of measure should a measured value be stored in?
• What reference table should be used to validate a reference code?

Vertical Table Example: WELL_EQUIPMENT_SPEC
EQUIPMENT_ID MAX_VALUE_UOM
Each column is tuned to a specific SPEC_SET_ID MIN_DATE
KIND of information. SPEC_TYPE MIN_VALUE

SPEC_ID MIN_VALUE_OUOM
ACTIVE_IND MIN_VALUE_UOM
AVERAGE_VALUE PPDM_GUID
How do I decide which column to use RATIO_NAME
AVERAGE_VALUE_OUOM
for each kind of value? AVERAGE_VALUE_UOM RATIO_VALUE_AVERAGE
COST RATIO_VALUE_MAXIMUM
CURRENCY_CONVERSION RATIO_VALUE_MINIMUM
CURRENCY_OUOM REFERENCE_VALUE
What precision and units should be REFERENCE_VALUE_OUOM
CURRENCY_UOM
used for each kind of value? DATE_FORMAT_DESC REFERENCE_VALUE_TYPE
EFFECTIVE_DATE REFERENCE_VALUE_UOM
REMARK
EQUIP_MAINT_ID
SOURCE
How can I be consistent so the table EXPIRY_DATE
SPEC_CODE
MAX_DATE
can be used by everyone? MAX_VALUE
SPEC_DESC
MAX_VALUE_OUOM
MAX_VALUE_UOM

Columns for Each Kind of Data

The Problem with Vertical Tables
Even with specific columns for each data type, you may:
• Use different units of measure for the same kind of information, forcing on the fly
conversions
• Use different precision for similar values, making them difficult to query
• Store similar values in different columns making queries complicated or uncertain
• Text values can be very inconsistent and hard to query
• Developers often like vertical tables because they are easy to code against
BUT
• The data content often becomes corrupted and hard to use!

Vertical Table Behavior Control
Vertical table EQUIPMENT_SPEC

- Manages information that
describes equipment
The color of my truck – the value should be text, and validated against R_COLOR
The seating capacity of my truck – the value should be a number with no decimal
places
The fuel capacity of my truck – the value should be a number with one decimal
place, stored in liters.

Vertical Table Behavior Control
The kinds of values that can be put into any

vertical table will be controlled by a
reference list. (Arch Princ)
We can add information to each value in the

controlling reference table, so we can
describe how it should be used.
R_EQUIP_SPEC_TYPE R_EQUIP_SPEC
COLOR RED
CREW CAPACITY 5
FUEL CAPACITY 100 liters

The Property Set Tables
Property sets are instructions about

which columns are to be used and how
they should be used.
If you use these columns, you can

ensure that vertical tables contain high
quality data

Introduction to Vertical Tables
EQUIPMENT_SPEC R_EQUIP_SPEC
EQUIPMENT_ID VARCHAR2 20 SPEC_TYPE
SPEC_ID VARCHAR2 20 ABBREVIATION
SPEC_TYPE VARCHAR2 20 ACTIVE_IND
EFFECTIVE_DATE
ACTIVE_IND VARCHAR2 1
EXPIRY_DATE
AVERAGE_VALUE NUMBER LONG_NAME
AVERAGE_VALUE_OUOM VARCHAR2 20 PPDM_GUID
AVERAGE_VALUE_UOM VARCHAR2 20 PROPERTY_SET_ID
COST NUMBER 12 2 REMARK
CURRENCY_CONVERSION NUMBER 10 5 SHORT_NAME
CURRENCY_OUOM VARCHAR2 20 SOURCE
ROW_CHANGED_BY
CURRENCY_UOM VARCHAR2 20
This is a vertical EFFECTIVE_DATE DATE
ROW_CHANGED_DATE
ROW_CREATED_BY
table.
EXPIRY_DATE DATE ROW_CREATED_DATE
MAX_DATE DATE ROW_QUALITY
MAX_VALUE NUMBER
MAX_VALUE_OUOM VARCHAR2 20
MAX_VALUE_UOM VARCHAR2 20
MIN_DATE DATE
MIN_VALUE NUMBER
MIN_VALUE_OUOM VARCHAR2 20
MIN_VALUE_UOM VARCHAR2 20 This table contains
PPDM_GUID VARCHAR2 38 valid property types. It
REFERENCE_VALUE
REFERENCE_VALUE_OUOM
NUMBER
VARCHAR2 20
controls the behavior in
REFERENCE_VALUE_TYPE VARCHAR2 20 the vertical table.
REFERENCE_VALUE_UOM VARCHAR2 20
REMARK VARCHAR2 2000
SOURCE VARCHAR2 20
SPEC_CODE VARCHAR2 20
SPEC_DESC VARCHAR2 1024
ROW_CHANGED_BY VARCHAR2 30
ROW_CHANGED_DATE DATE
ROW_CREATED_BY VARCHAR2 30
ROW_CREATED_DATE DATE
ROW_QUALITY VARCHAR2 20

Introduction to Vertical Table Control
Each reference
EQUIPMENT_ID
table that contains20 the list
VARCHAR2 SPEC_TYPE
of Property Types for a vertical20table
SPEC_ID VARCHAR2 ABBREVIATION
SPEC_TYPE
contains
VARCHAR2
ACTIVE_IND a foreign key
20
to PPDM
VARCHAR2 1
ACTIVE_IND
EFFECTIVE_DATE
1 PPDM_PROPERTY_SET
PROPERTY_SET_ID
EXPIRY_DATE
PROPERTY
AVERAGE_VALUE
AVERAGE_VALUE_OUOM
SET.
NUMBER
VARCHAR2 20
LONG_NAME ACTIVE_IND
EFFECTIVE_DATE
PPDM_GUID
AVERAGE_VALUE_UOM VARCHAR2 20 PROPERTY_SET_ID EXPIRY_DATE
COST NUMBER 2 12 REMARK PPDM_GUID
Property sets allow us to control how
CURRENCY_CONVERSION NUMBER 5 10 SHORT_NAME PROPERTY_SET_NAME
REMARK
each property should be treated in the
CURRENCY_OUOM VARCHAR2 20 SOURCE
ROW_CHANGED_BY SOURCE
CURRENCY_UOM VARCHAR2 20
database.
EFFECTIVE_DATE DATE
ROW_CHANGED_DATE
ROW_CREATED_BY
USE_TABLE_NAME
ROW_CHANGED_BY
This gives us very precise control over
EXPIRY_DATE DATE PPDM_PROPERTY_COLUMN
ROW_CREATED_DATE ROW_CHANGED_DATE
MAX_DATE DATE ROW_QUALITY ROW_CREATED_BY
how to manage vertical tables.
MAX_VALUE NUMBER ROW_CREATED_DATE
MAX_VALUE_OUOM VARCHAR2 20 PROPERTY_SET_ID ROW_QUALITY
MAX_VALUE_UOM VARCHAR2 20 PROPERTY_OBS_NO
MIN_DATE
MIN_VALUE
DATE
NUMBER
ACTIVE_IND
COLUMN_PRECISION
COLUMN_SCALE
2
COLUMN_SIZE
MIN_VALUE_UOM VARCHAR2 20 DATA_TYPE
PPDM_GUID VARCHAR2 38 DOMAIN
REFERENCE_VALUE NUMBER EFFECTIVE_DATE
REFERENCE_VALUE_OUOM VARCHAR2 20 EXPIRY_DATE
This table allows us to control exactly
REFERENCE_VALUE_TYPE VARCHAR2
20 how the vertical table will behave for every column that is used
PPDM_GUID
PREFERRED_CURRENCY_UOM
when a particular Property Type
REFERENCE_VALUE_UOM
REMARK
VARCHAR2
20
VARCHAR2
2000
is used. PREFERRED_UOM
REF_TABLE_NAME
SOURCE VARCHAR2 20 REMARK
Some properties are described with NUMBERIC values – use this table to list which columns in the
SPEC_CODE
SPEC_DESC
VARCHAR2
VARCHAR2
20
1024
SOURCE
USE_COLUMN_NAME
vertical table should be used, what precision you want to use (how many decimal places), what units
ROW_CHANGED_BY VARCHAR2 30 USE_TABLE_NAME
ROW_CHANGED_BY
ROW_CHANGED_DATE DATE
of measure to use and so on. 30
ROW_CREATED_BY VARCHAR2
ROW_CHANGED_DATE
ROW_CREATED_BY
ROW_CREATED_DATE DATE ROW_CREATED_DATE
ROW_QUALITY VARCHAR2 20 ROW_QUALITY
For code values that are derived from a reference table, you can say which reference table to
validate the entered value against.

PPDM PROPERTY COLUMN
PROPERTY_SET_ID
USE COLUMN NAME and USE PROPERTY_OBS_NO
TABLE NAME identify the name of ACTIVE_IND
the vertical table and the column of COLUMN_PRECISION
the vertical table that should be COLUMN_SCALE
used to store the value for a COLUMN_SIZE
property. DATA_TYPE
DOMAIN
For some kinds of property types, EFFECTIVE_DATE
more than one column may be EXPIRY_DATE
needed to describe the properties. PPDM_GUID
You can list as many columns as you
PREFERRED_UOM
need to, using one row in this table
REF_TABLE_NAME
for each property value you will
REMARK
store in the vertical table.
SOURCE
USE_COLUMN_NAME
USE_TABLE_NAME
ROW_CHANGED_BY
ROW_CHANGED_DATE
ROW_CREATED_BY
ROW_CREATED_DATE
ROW_QUALITY

PPDM PROPERTY COLUMN
The rest of this table allows you to create an PROPERTY_SET_ID

implicit data model for each column in PROPERTY_OBS_NO
the vertical table that will be used for each ACTIVE_IND
property type. COLUMN_PRECISION
COLUMN_SCALE
You use this table to characterize how to COLUMN_SIZE
describe each value in the reference table DATA_TYPE
(such as mass or color)
DOMAIN
EFFECTIVE_DATE
EXAMPLE 1: for values that describe the
EXPIRY_DATE
MASS of an object, you may want to store
values that are PPDM_GUID
DOMAIN = MASS PREFERRED_UOM
DATA TYPE = NUMBER REF_TABLE_NAME
COLUMN SIZE = 10 REMARK
COLUMN PRECISION = 2 SOURCE
PREFERRED UOM = kg USE_COLUMN_NAME
----------------------------------------- USE_TABLE_NAME
ROW_CHANGED_BY
EXAMPLE 2: to describe the COLOR of an ROW_CHANGED_DATE
object, you may want to use values listed in ROW_CREATED_BY
the table R_COLOR
ROW_CREATED_DATE
ROW_QUALITY
REF TABLE NAME = R COLOR

Example 1: EQUIPMENT SPEC SPEC TYPE = MASS
1 PROPERTY SET ID = 1
SPEC_TYPE VARCHAR2 20 ACTIVE_IND PPDM_PROPERTY_SET
ACTIVE_IND VARCHAR2 1 EFFECTIVE_DATE
AVERAGE_VALUE NUMBER EXPIRY_DATE PROPERTY_SET_ID
ACTIVE_IND
The mass of my AVERAGE_VALUE_OUOM
AVERAGE_VALUE_UOM
COST
VARCHAR2
VARCHAR2
NUMBER
20
20
12 2
LONG_NAME
PPDM_GUID
PROPERTY_SET_ID
EFFECTIVE_DATE
EXPIRY_DATE
big red truck CURRENCY_CONVERSION

CURRENCY_OUOM
NUMBER
VARCHAR2
10
20
5 REMARK
SHORT_NAME
PPDM_GUID
PROPERTY_SET_NAME
REMARK
CURRENCY_UOM VARCHAR2 20 SOURCE
EFFECTIVE_DATE DATE ROW_CHANGED_BY SOURCE
EXPIRY_DATE DATE ROW_CHANGED_DATE USE_TABLE_NAME
MAX_DATE DATE ROW_CREATED_BY ROW_CHANGED_BY
MAX_VALUE NUMBER ROW_CREATED_DATE ROW_CHANGED_DATE
MAX_VALUE_OUOM VARCHAR2 20 ROW_QUALITY ROW_CREATED_BY
MAX_VALUE_UOM VARCHAR2 20 ROW_CREATED_DATE
MIN_DATE
MIN_VALUE
MIN_VALUE_OUOM
DATE
NUMBER
VARCHAR2 20
ROW_QUALITY
2
MIN_VALUE_UOM VARCHAR2 20
PPDM_GUID VARCHAR2 38 PPDM_PROPERTY_COLUMN
REFERENCE_VALUE
NUMBER
VARCHAR2 20 PROPERTY_SET_ID
USE TABLE NAME =
PROPERTY_OBS_NO
REFERENCE_VALUE_TYPE
REFERENCE_VALUE_UOM
VARCHAR2
VARCHAR2
20
20 ACTIVE_IND EQUIPMENT_SPEC
REMARK VARCHAR2 2000 COLUMN_PRECISION
3
SOURCE VARCHAR2 20 COLUMN_SCALE
SPEC_CODE VARCHAR2 20 COLUMN_SIZE
4 SPEC_DESC
ROW_CHANGED_BY
ROW_CHANGED_DATE
VARCHAR2
VARCHAR2
DATE
1024
30
DATA_TYPE
DOMAIN
EFFECTIVE_DATE
ROW_CREATED_BY VARCHAR2 30 EXPIRY_DATE
ROW_CREATED_DATE DATE PPDM_GUID
ROW_QUALITY VARCHAR2 20 PREFERRED_CURRENCY_UOM
SPEC TYPE = MASS PREFERRED_UOM
REF_TABLE_NAME
USE TABLE NAME = EQUIPMENT_SPEC
REMARK
AVERAGE VALUE = 15000 This information controls SOURCE

USE_COLUMN_NAME
USE COLUMN NAME = AVERAGE VALUE
what you put into
USE_TABLE_NAME
AVERAGE VALUE UOM = kg

ROW_CHANGED_BY
ROW_CHANGED_DATE COLUMN PRECISION = 0
EQUIPMENT SPEC
ROW_CREATED_BY
ROW_CREATED_DATE
ROW_QUALITY COLUMN SIZE = 15
DOMAIN = MASS
139
PREFERRED UOM = kg
Copyright 2018, PPDM Association. All Rights Reserved
Example 2: EQUIPMENT SPECS 1 SPEC TYPE = INSIDE DIAMETER
PROPERTY SET ID = 2
SPEC_TYPE VARCHAR2 20 ACTIVE_IND PPDM_PROPERTY_SET
ACTIVE_IND VARCHAR2 1 EFFECTIVE_DATE
The inside AVERAGE_VALUE_OUOM

AVERAGE_VALUE_UOM
COST
VARCHAR2
VARCHAR2
NUMBER
20
20
12 2
LONG_NAME
PPDM_GUID
PROPERTY_SET_ID
ACTIVE_IND
EFFECTIVE_DATE
EXPIRY_DATE
2
CURRENCY_CONVERSION NUMBER 10 5 REMARK PPDM_GUID
diameter of CURRENCY_OUOM
CURRENCY_UOM
VARCHAR2
VARCHAR2
20
20
SHORT_NAME
SOURCE
PROPERTY_SET_NAME
REMARK
SOURCE
EFFECTIVE_DATE DATE ROW_CHANGED_BY
USE TABLE NAME =
my pipeline EXPIRY_DATE DATE ROW_CHANGED_DATE USE_TABLE_NAME
MAX_VALUE
MAX_VALUE_OUOM
NUMBER
VARCHAR2 20
ROW_CREATED_DATE
ROW_QUALITY
ROW_CHANGED_DATE
ROW_CREATED_BY
EQUIPMENT_SPEC
MIN_DATE DATE ROW_QUALITY
MIN_VALUE NUMBER
PPDM_GUID
REFERENCE_VALUE NOTE: In PPDM
VARCHAR2
NUMBER
VARCHAR2
38
20
PPDM_PROPERTY_COLUMN
PROPERTY_SET_ID
USE TABLE NAME = 3
PROPERTY
REFERENCE_VALUE_TYPE
REFERENCE_VALUE_UOM
VARCHAR2
VARCHAR2
20
20
PROPERTY_OBS_NO
ACTIVE_IND
EQUIPMENT_SPEC
SOURCE COLUMN there
VARCHAR2 20 COLUMN_SCALE
SPEC_CODE VARCHAR2 20 COLUMN_SIZE
USE COLUMN NAME = MIN VALUE
SPEC_DESC
ROW_CHANGED_BY are 2 rows
VARCHAR2
VARCHAR2
1024
30
DATA_TYPE
DOMAIN
COLUMN PRECISION = 2
4 ROW_CHANGED_DATE
ROW_CREATED_BY
ROW_CREATED_DATE
DATE
VARCHAR2
DATE
30
EFFECTIVE_DATE
EXPIRY_DATE
PPDM_GUID COLUMN SIZE = 8
ROW_QUALITY VARCHAR2 20 PREFERRED_CURRENCY_UOM
SPEC TYPE = INSIDE DIAMETER

PREFERRED_UOM
REF_TABLE_NAME DOMAIN = LENGTH
REMARK
PREFERRED UOM = m
MIN VALUE = 2.24 This information controls SOURCE
USE_COLUMN_NAME
USE_TABLE_NAME
what you put into ROW_CHANGED_BY

ROW_CHANGED_DATE USE COLUMN NAME = MAX VALUE
MIN VALUE UOM = m
EQUIPMENT SPEC
ROW_CREATED_BY
ROW_CREATED_DATE
ROW_QUALITY
MAX VALUE = 2.26 COLUMN SIZE = 8
DOMAIN = LENGTH
MAX VALUE UOM = m
140 PREFERRED UOM = m
Copyright 2018, PPDM Association. All Rights Reserved
Example 3: EQUIPMENT SPECS SPEC TYPE = COLOR
PROPERTY SET ID = 3
1
SPEC_ID VARCHAR2 20 ABBREVIATION PPDM_PROPERTY_SET
The color SPEC_TYPE
ACTIVE_IND
VARCHAR2
VARCHAR2
20
1
ACTIVE_IND
EFFECTIVE_DATE
ACTIVE_IND 2
of my big
AVERAGE_VALUE_OUOM VARCHAR2 20 LONG_NAME
AVERAGE_VALUE_UOM VARCHAR2 20 PPDM_GUID EFFECTIVE_DATE
COST NUMBER 12 2 PROPERTY_SET_ID EXPIRY_DATE
CURRENCY_CONVERSION NUMBER 10 5 REMARK PPDM_GUID
USE TABLE NAME =
red truck CURRENCY_OUOM
CURRENCY_UOM
EFFECTIVE_DATE
VARCHAR2
VARCHAR2
DATE
20
20
SHORT_NAME
SOURCE
ROW_CHANGED_BY
PROPERTY_SET_NAME
REMARK
SOURCE
EQUIPMENT_SPEC
EXPIRY_DATE DATE ROW_CHANGED_DATE USE_TABLE_NAME
MAX_VALUE NUMBER ROW_CREATED_DATE ROW_CHANGED_DATE
MAX_VALUE_OUOM VARCHAR2 20 ROW_QUALITY ROW_CREATED_BY
MIN_DATE DATE ROW_QUALITY
MIN_VALUE NUMBER
PPDM_GUID VARCHAR2 38 PPDM_PROPERTY_COLUMN
REFERENCE_VALUE NUMBER
REFERENCE_VALUE_OUOM VARCHAR2 20 PROPERTY_SET_ID
REFERENCE_VALUE_TYPE VARCHAR2 20 PROPERTY_OBS_NO
REFERENCE_VALUE_UOM VARCHAR2 20 ACTIVE_IND
SOURCE VARCHAR2 20 COLUMN_SCALE
SPEC_CODE
SPEC_DESC
VARCHAR2
VARCHAR2
20
1024
COLUMN_SIZE
DATA_TYPE 3
4 ROW_CHANGED_BY
ROW_CHANGED_DATE
ROW_CREATED_BY
VARCHAR2
DATE
VARCHAR2
30
30
DOMAIN
EFFECTIVE_DATE
EXPIRY_DATE
ROW_CREATED_DATE DATE PPDM_GUID
PREFERRED_CURRENCY_UOM USE TABLE NAME =
SPEC TYPE = COLOR ROW_QUALITY VARCHAR2 20
This information controls PREFERRED_UOM

REF_TABLE_NAME
REMARK
EQUIPMENT_SPEC
SPEC CODE = RED what you put into SOURCE
USE_COLUMN_NAME
USE COLUMN NAME = SPEC CODE
EQUIPMENT SPEC
USE_TABLE_NAME
ROW_CHANGED_BY
ROW_CHANGED_DATE
ROW_CREATED_BY
ROW_CREATED_DATE
REF TABLE NAME = R_COLOR
ROW_QUALITY

Example 4: WELL LOG CURVE INDEX TYPE = DEPTH
1
PROPERTY SET ID = 4
UWI
CURVE_ID
ACQUIRED_FOR_BA_ID
The INDEX for ACTIVE_IND

API_CODE_SYSTEM
API_CURVE_CLASS
API_CURVE_CODE
API_CURVE_MODIFIER
R INDEX TYPE
a log API_LOG_CODE
BASE_CURVE_IND
BYPASS_IND
INDEX_TYPE
ABBREVIATION 2
CASED_HOLE_IND
COMPOSITE_IND ACTIVE_IND PPDM_PROPERTY_SET
CURVE_OUOM EFFECTIVE_DATE
EXPIRY_DATE PROPERTY_SET_ID
CURVE_QUALITY ACTIVE_IND
DICTIONARY_ID
DICT_CURVE_ID
LONG_NAME
PPDM_GUID
PROPERTY_SET_ID
EFFECTIVE_DATE
EXPIRY_DATE
USE TABLE NAME = WELL LOG CURVE
EFFECTIVE_DATE PPDM_GUID
EXPIRY_DATE REMARK
SHORT_NAME PROPERTY_SET_NAME
EXPLICIT_INDEX_IND REMARK
FIRST_GOOD_VALUE SOURCE
ROW_CHANGED_BY SOURCE
FIRST_GOOD_VALUE_INDEX USE_TABLE_NAME
FRAME_ID ROW_CHANGED_DATE
ROW_CREATED_BY ROW_CHANGED_BY
GOOD_VALUE_TYPE ROW_CHANGED_DATE
ROW_CREATED_DATE
INDEX_CURVE_ID
INDEX_OUOM
INDEX_UOM
ROW_QUALITY ROW_CREATED_BY
ROW_CREATED_DATE
ROW_QUALITY
USE TABLE NAME = WELL LOG CURVE
JOB_ID
LAST_GOOD_VALUE
LAST_GOOD_VALUE_INDEX
LOG_TOOL_PASS_NO PPDM_PROPERTY_COLUMN USE COLUMN NAME = MIN INDEX
4 LOG_TOOL_TYPE
MAX_INDEX
MAX_VALUE
MAX_VALUE_INDEX
PROPERTY_SET_ID
PROPERTY_OBS_NO
ACTIVE_IND
MEAN_VALUE
COLUMN_PRECISION
PRIMARY INDEX TYPE = DEPTH

MEAN_VALUE_STD_DEV
MIN_INDEX
COLUMN_SCALE
COLUMN_SIZE
COLUMN SIZE = 15,2
This information controls
MIN_VALUE
DATA_TYPE
MIN_VALUE_INDEX
MULTIPLE_INDEX_IND
DOMAIN
EFFECTIVE_DATE
DATA TYPE = NUMBER
what you put into
MWD_IND
EXPIRY_DATE
MIN INDEX = 5123.25 NULL_COUNT
NULL_REPRESENTATION
PPDM_GUID
PPDM_GUID
DOMAIN = LENGTH
WELL_LOG_CURVE
PREFERRED_UOM
MIN INDEX UOM = m

PRIMARY_INDEX_TYPE
REMARK
REPORTED_MNEMONIC
REF_TABLE_NAME
REMARK
PREFERRED UOM = m
SOURCE
REPORTED_UNIT_MNEMONIC
USE_COLUMN_NAME
SOURCE
USE_TABLE_NAME
TRIP_OBS_NO
MAX INDEX = 10433.50

ROW_CHANGED_BY
USE COLUMN NAME = MAX INDEX
3
VALUE_COUNT
ROW_CHANGED_DATE
WELL_LOG_ID
ROW_CREATED_BY
WELL_LOG_JOB_SOURCE
WELL_LOG_SOURCE
ROW_CHANGED_BY
ROW_CREATED_DATE
ROW_QUALITY COLUMN PRECISION = 2
MIN INDEX UOM = m ROW_CHANGED_DATE
ROW_CREATED_BY
COLUMN SIZE = 15,2
ROW_CREATED_DATE
ROW_QUALITY
NOTE: In DATA TYPE = NUMBER
PPDM PROPERTY DOMAIN = LENGTH
COLUMN there are 2 PREFERRED UOM = m
142 rows Copyright 2018, PPDM Association. All Rights Reserved
Reference Lists in PPDM

Reference Values: 3 Key Functions

Reference Values
• Table names
• R_%
• Reference-like subjects (Areas, BA’s…)
• Decide what to use in PK values
• Natural values – names or other natural value can reduce joins
• GUID – uniqueness more likely
• Integers - may speed up query and retrieval
• Never force your users to memorize or refer to lists of codes!
• Create some business rules and deploy them consistently
• How, who, when, where…

Standard Reference Tables
Most Reference Tables are R_ followed by the column name
ex: WELL.CONFIDENTIAL_TYPE = R_CONFIDENTIAL_TYPE
• Should be populated before data loading.
• Check on-line documentation to confirm the existence and name of the reference table:
• Or in the meta model

select referenced_table_name,referenced_column_name
from ppdm_cons_column
where system_id = 'PPDM38'
and table_name = ‘WELL’ and column_name = ‘CONFIDENTIAL_TYPE’
and referenced_table_name is not null and referenced_column_name is not null;

Validity Checking
• All R_% values

• What happens if the value is not known at load time?
• What happens if the value is not relevant for this data?
• What happens if the value could not be found, despite an exhaustive search?
• What happens if the necessary value is not in the table?
• Who can add or change, what are rules?
• Valid data ranges

• upper and lower limits
• Regional limitations
• Legal limitations
• rule based (use PPDM_RULE)

Using the AUDIT and QC tables
• When you find NULL data, and that absence is important, use the tables
PPDM_AUDIT_HISTORY and PPDM_QUALITY_CONTROL to track what you did to
investigate the problem and why the value is NULL.
• Note: In order to use these tables, you must install the DDL scripts that create a
unique index and a NOT NULL constraint on PPDM_GUID in every table.

Validity Checking and QC
Use Data Coordinate

Reference System
PPDM_QUALITY_CONTROL
PPDM_AUDIT_HISTORY

PPDM_AUDIT_HISTORY (Provenance)
• Create a new row in PPDM_AUDIT_HISTORY
• using the system id for the data store in which you are working
• the table name in which the NULL data is found
• the column name that contains NULL data
• the PPDM_GUID of the row of data you are documenting (AUDIT_ROW_GUID)
• AUDIT_SEQ_NO (start at 1 for each system and table combination)
• Remember that in the SEQ_NO column, order is important; rows should be consecutive.
• Add information about the NULL VALUE.

• Use NULL_DESCRIPTION to explain why this value is NULL.
• Be sure to track the original and final values for the column. For example, if the original
source value is found to be incorrect, the original value is recorded and the new value shown
as INCORRECT.
• Use AUDIT_CREATED_BY_BA_ID to track who performed each step of the process.
• Use AUDIT_VERIFIED_BY_BA_ID to track who verified the work.
• Use RETENTION_TYPE to indicate how long this audit data should be retained.

PPDM_QUALITY_CONTROL (Research)
• Create a new row in PPDM_QUALTY_CONTROL, using the system id for the data store in
which you are working, the table name in which the NULL data is found and a
QC_SEQ_NO (start at 1 for each system and table combination).
• Remember that in the SEQ_NO column, order is important; rows should be consecutive.
• Identify the COLUMN_NAME that contains the NULL value.
• Identify the row of data in the table that contains the NULL value. (CURRENT_ROW_GUID)
• Add information describing the investigation processes.

• Use NULL_DESCRIPTION to explain why this value is NULL during this Quality Control (QC)
step.
• Use QC_TYPE and QC_STATUS to describe what was done to find the missing data. Note that
if you conducted several steps, you should create a row for every step, in order (using
QC_SEQ_NO).
• Use DONE_BY_BA_ID to track who performed each step of the process.
• Use CHECKED_BY_BA_ID to track who verified the work.
• Use RETENTION_TYPE to indicate how long this audit data should be retained.

Understanding “DUMMY” Data
• Users should not “dummy” data values that should convey business meaning in
order to satisfy a constraint or a procedure.
• Falsified or dummied data results in user mistrust, and can confuse or obscure the
results from legitimate queries.
• The PPDM Data Model avoids making columns mandatory unless it is certain that the
value can be determined and created on INSERT into the table.
• This guideline does not apply to values that are normally generated through system
procedures, such as Sequence Numbers, Observation Numbers, Primary Keys and so
on.

Understanding “NULL” Data
• The value may not be appropriate for the specific kind of data being loaded.
• For example, the table BUSINESS_ASSOCIATE can be used to describe people,
companies, regulatory agencies, consortiums, etc. Depending on which kind of business
associate you are describing, some columns will not be relevant. For example,
FIRST_NAME and LAST_NAME are not relevant to describing a company.
• In this case, it is useful to populate the column with a value such as NOT APPLICABLE.
• The value may not have been received yet, but is expected.
• As data is received from field operations, it is often necessary to populate data as it is
received, rather than waiting for a complete set of data.
• In this case, it is useful to populate the column with a value such as EXPECTED.
• Pitfall: Think about the time delays and processes that your organization uses in updating
incomplete information. Make sure that you will be able to add the missing information
when it is received, and that the updates can be propagated to your user communities.
Good governance procedures are important, as one does not want to present users with a
value such as EXPECTED long after operations are complete.

• The value may be UNOBTAINABLE.

• This can happen with legacy data, data received from partners, or from incomplete data
stores. In this case, the users should be made to understand that the value was sought,
but could not be obtained.
• Keep in mind that data searches can be time consuming, difficult and expensive. If effort
is expended to discover that a value cannot be determined, it is crucial that this
knowledge be preserved in order to forestall future similar fruitless endeavours.
• In the above situation, a value such as UNOBTAINABLE is useful. We recommend that the
data analyst also record what sources were investigated. The PPDM Data Management
subject area contains tables (including PPDM_QUALITY_CONTROL) that will help you
describe your data search in considerable depth.
• The value may be UNKNOWN, but no search has been conducted to determine
whether a value might be discovered with some effort.
• In this case, it is useful to indicate to future searchers that there could be value in doing
some research to discover the missing value. Use PPDM_QUALITY_CONTROL to record
the fact that no research was conducted.
• The data might be present in the original source or documentation, but be

determined to be INCORRECT during research or quality control processes.
• In this case, the original value should be removed from the data table, with the reasons
why it was deleted documented in PPDM_QUALITY_CONTROL.

Reference Alias Version
• In PPDM3.9 there is an ALIAS table for every R_% table
• Example: R_CONFIDENCE_TYPE with alias RA_CONFIDENCE_TYPE
RA_CONFIDENTIAL_TYPE
R_CONFIDENTIAL_TYPE
#CONFIDENTIAL_TYPE
#CONFIDENTIAL_TYPE
#ALIAS_ID
…….
…….

Reference Tables Should be Clean
RA_ table R_ table

Reference Tables
• Not all Reference tables are R_%

• Use online documentation or constraints to check
• Some tables have strong REFERENCE BEHAVIOR, but are not a simple list of values
• AREA
• BUSINESS ASSOCIATE
• CS_COORDINATE_SYSTEM
• FACILITY
• FIELD, POOL
• SUBSTANCE
• STRAT_UNIT
• ZONE

Dates
Tips and Tricks

Date Problems
• Date may be imprecise or unknown
• 1Q93, spring 1983 …..
• year only
• year and month
• Architectural Principles
• DATE should not be part of the PK
• Decide how to handle technical issues

• handling NULL dates during loads or queries
• search between dates

Date Solutions
• Imprecise Dates • Search between Dates
• VARCHAR2 (8) date description • Leave expiry data NULL and set
%_DATE_DESC ACTIVE_IND = ‘Y’
• YYYY – year precision • Set to high value (Dec 01, 4712)*
• YYYYMM – month precision • (Ensor and Stevenson, 1997)
• YYYYQQ – quarter precision
• YYYYMMDD – day precision
• Don’t synthesize false data
• Use DATE format (partially system • user trust affected
created values)
• Oracle 11 defaults YEAR to current
• Oracle 11 defaults MONTH to current • Base site rules on user needs
• Oracle 11 defaults DAY to 01 • loading
• query and retrieval
• future dates such as expiry date

Tips and Hints
Use the ACTIVE_IND to show what data is currently

active. Make sure this column is always accurately
populated by using a trigger on EXPIRY_DATE.
If the data has not expired, leave EXPIRY_DATE null.

Units of Measure
Tips and Tricks

Units of Measure Problems
• Scalability
• retrieval (‘all wells that penetrate to 1500 meters’)
• calculation (‘average seismic line length’)
• Multiple UOM received

• different countries, jurisdictions
• production volume depends on substance
• Volume regimes
• Volume measure based on temperature and pressure regimes
• Currencies
• Conversion rate varies over time
• Different banks use different conversion rates
• Different transactions use different conversion rates

Unit of Measure Architectural Principle
• Storing UOM
• Standard UOM for every column
• Meta model
• Original UOM for each row / column
• Subject tables
• Exceptions
• Values whose UOM cannot be standardized
• Example: Production volume UOM depends on the type of product
• Example: Vertical tables

UOM Example
WELL
UWI DRILL_TD DRILL_TD_OUOM
SMITH12F 1250 FEET
JONES44 1560 METERS
12345 1400 FEET
PPDM_COLUMN
TABLE_ COLUMN_ UOM_ COLUMN OUOM_ COLUMN DEFAULT
NAME NAME _ UOM_
SYMBOL
WELL UWI
WELL DRILL_TD DRILL_TD_OUOM M
WELL DRILL_TD_OUOM
WELL_CEMENT CEMENT_AMOUNTCEMENT_AMOUNT_UOM CEMENT_AMOUNT_OUOM

Tips and Hints
The PPDM Meta Model does not store data values - only information
about the structure of the data model.
The default Unit of Measure for a measured value is stored in the meta
model.
The original Unit of Measure is stored in the business table. This value is
only used to restore values back to the original (usually for regulatory
reporting).
Use the Meta Model to convert units from one system to another.

Currencies in PPDM
• Currency values should be stored as %_COST

• Currency domain (NUMBER 12,2).
• CURRENCY_OUOM is the currency in which the funds were originally received by the payee.
• CURRENCY_CONVERSION with each currency

• Currency conversion domain (NUMBER 10,5)
• “CURRENCY CONVERSION RATE: the rate applied to convert the currency to its original
monetary UOM from the stored UOM. This value is valid for this row in this table only. When
this value is multiplied by the STORED currency value, the original value of the transaction in
the original currency is obtained.”

Tips and Hints
Use the same stored currency unit of measure for

the entire implementation or at least regionally.
Be aware that different banks use different

exchange values for different transaction types.
Usually it’s best to use the conversion rate captured
in your financial system.

Coordinate Systems
Tips and Tricks
Details about spatial

systems are available
in other classes

Coordinate System Problems
• Scalability
• retrieval (‘all wells that fall within my area’)
• Bad or incomplete data

• original reference system unknown
• reference system was captured incorrectly
• conversions not done correctly
• Multiple sets of coordinates

• original, revised
• datum dependent

CS Architectural Principle
• Store geographic coordinates by default

• Latitude, longitude
• In some cases, other reference systems are allowed
• Local referenced systems are important for some business functions
• Preferred coordinates all referenced to same CS

• At least regionally, globally if practical
• Support multiple coordinate systems in %_VERSION table

• UTM, polyconic
• Other coordinate systems
• Store the preferred version in this table also

Spatial Information = GIS?
• Challenges
• Not all uses of spatial information are GIS related
• Should you embed spatial objects in a complex database? Agreement Agreement
• How can you include spatial objects in a SQL Query? 1 - 50% 2 - 50%
de
x c lu n e B
E Zo
l
• GIS does not handle sub-surface well Oi
• Depths ranges
• Zones
• Pools, reservoirs are not polygons
• Spatial locations version over time
• Historical
• Predictive
• Attribute information may be related to spatial information
• May need huge amounts of structured data that relates to the spatial information

Coordinate System Example
WELL_NODE
COORDINATE
NODE_ID LATITUDE LONGITUDE _SYSTEM_ID UWI
12345 45.3456 49.1584 NAD83 12345
23456 46.2347 56.3628 NAD83 SMITH12F
WELL_NODE_VERSION
COORDINATE
NODE_ID SRC OBS_NO UTM_X UTM_Y _SYSTEM_ID
12345 PPDM 1 200654 4956258 WGS83
12345 PPDM 2 200538 4956283 NAD27

Tips and Hints
NEVER store coordinate information without a Coordinate Reference. Don’t assume you
know what it is – check it out before you load!
Although you can store Transformation parameters in PPDM, the data model should not be
used for transformations. Use a valid geodetic program to convert between coordinate
systems
The Coordinate System Module stores lots of information that can be useful to you
✓ Datum and ellipsoid details
✓ Coordinate system transformations
✓ Mapping system transformations
✓ Acquisition method
✓ Alternate names or identifiers

Semantics

Understand the Semantics
• Value to be migrated = 1,000,000 2005 East Texas Production

• Are the units of measure stored or inferred?
• What are the semantics in the column name? #PK
• What are the semantics in the table name?
JAN OIL VOLUME (BBL)
• What other columns give meaning to this value?
FEB OIL VOLUME (BBL)
JAN GAS VOLUME (MCF)
FEB GAS VOLUME (MCF)
JAN GAS VOL BOE
FEB GAS VOL BOE

Understand the Semantics
• When you load into PPDM
• What other columns can you populate to fully describe the semantics?
• Try not to leave any information inferred if you can avoid it.
• Use ACTIVE_IND, dates, quality columns
2005 East Texas Production Just using the table and column names we
have a lot of information
#PK
JAN OIL VOLUME (BBL)
FEB OIL VOLUME (BBL) • AREA in column name
JAN GAS VOLUME (MCF) • DATES = 2005 plus column name
FEB GAS VOLUME (MCF) • UNITS in column name

JAN GAS VOL BOE • PRODUCT in column name
FEB GAS VOL BOE • CONVERSION factors a mystery

Extending PPDM
• Guidelines
• Recommendations

Extensibility Do’s
• Meet your business needs
• Add tables
• table name prefix AB_
• Add columns to the end of the table
• column name prefix AB_
• Add constraints when needed
• Apply Architectural Principles
• PPDM Change Management

Extensibility Don’ts
• Modify the Primary Key
• Mis-use columns and tables
• Avoid adding tables that duplicate PPDM tables
• Make PPDM null-able columns mandatory
• Conflict with other vendors
• Change data types or lengths on existing columns

Subsetting Do’s
• Remove tables you do not require

• Define a footprint
• Remove constraints to tables you have removed
• Ultimate goal is interoperability
• Readily exchange data between partners and regulatory agencies
• Plug and play applications

Subsetting Don’ts
• Remove a parent table for a structure in your footprint

• Remove or alter Primary key components
• Remove columns from PPDM tables
• Remove constraints to tables in your footprint
• Change the optionality of columns

Data Updates
• Change Optional Foreign Keys (FK)

• Child FK to NULL
WELL
• Parent to new value
CHANGE UWI
• Update child tables 2. UPDATE
WELL
WELL_
• Change Primary Key (PK) TEST
CHANGE UWI
• Drop and re-create child rows 3. RECREATE
CHANGE UWI CHILD
1. DROP CHILD WELL_
ROWS
ROWS TEST_
PERIOD
WELL_
TEST_
FLOW

Data Deletes
• Can define ON DELETE CASCADE in
DDL
• not discriminatory, will delete all DELETE
children WELL
• Manage procedurally
• Start delete at bottom level of children
WELL
• Delete parent last
• Understand the business rules for every
affected group of users DROP CHILD ROWS?
• It’s not always appropriate to delete the
children!
WELL_ PDEN_ LAND_
TEST WELL WELL
OK

Primary Keys
• Natural vs surrogate
• Integer vs character
• GUID vs random vs concatenated vs license plate…
• Should they cascade or not?
• In PPDM 3.9 Primary Keys are now VARCHAR2(40) from VARCHAR2(20)

Implement WIAW components
These
Don’t
requirements assume
Keep the
drive the PK Avoid
highly
the user
knows
RI
structure
structure in the #UWI
WELL_LEVEL_TYPE
destructive which
as simple
changes component
well subject area type is
as possible
created
No Distinguish
mandatory between Allow
hierarchy - completions components
relate only (n) and to be fully
components completions described
you know. (v)

RI has Created Some Complications
• PPDM GUID has been very well

accepted.
• Use of the PPDM Data Management

module is very strong.
• Can we carry these concepts into

some of the heavy RI / complicated
tables, such as the COMPONENT
tables?

Implementation Support
• Consistency
• Terminology
• Method of implementation
• Normalization vs denormalization
• Implementation assists
• API?
• More documentation?
• More rigor in compliance?

Tips and Hints
PPDM grows through the

Change Management Process.
People who use it have an influence on the model.
www.ppdm.org/forums/

QUESTIONS?
Visit: The PPDM Association

PPDM.org

DM39-003 - Implementation Head Start

Uploaded by

Copyright:

Available Formats

You might also like

DM39-003 - Implementation Head Start

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DM39-003 - Implementation Head Start

Uploaded by

Copyright:

Available Formats

PPDM Training

PPDM Data Model

1 Copyright 2018, PPDM Association. All Rights Reserved

The PPDM Association

© 2018, PPDM Association. All Rights Reserved.

2 Copyright 2018, PPDM Association. All Rights Reserved

You have 2 years to do it

3 Copyright 2018, PPDM Association. All Rights Reserved

• Able to use the PPDM web site to get information

4 Copyright 2018, PPDM Association. All Rights Reserved

• Data model diagrams

• Data definition language

5 Copyright 2018, PPDM Association. All Rights Reserved

• Reference tables are not shown BA SERVICE

• Relationships are greatly simplified BA AUTHORITY

6 Copyright 2018, PPDM Association. All Rights Reserved

ALEO_SUMMARY_ID ADDRESS_OBS_NO PR_STR_FORM_OBS_NO

THIRD_ADDRESS_LINE CHANGE_NOTICE ACTIVE_IND

8 Copyright 2018, PPDM Association. All Rights Reserved

Columns in subject Column detail

10 Copyright 2018, PPDM Association. All Rights Reserved

12 Copyright 2018, PPDM Association. All Rights Reserved

13 Copyright 2018, PPDM Association. All Rights Reserved

14 Copyright 2018, PPDM Association. All Rights Reserved

15 Copyright 2018, PPDM Association. All Rights Reserved

16 Copyright 2018, PPDM Association. All Rights Reserved

Make PPDM_GUID “Not Null”, add unique index

Add UOM and OUOM / ROW QUALITY Constraints

Table Comments Column Comments

PPDM Compliance measure

17 Copyright 2018, PPDM Association. All Rights Reserved

18 Copyright 2018, PPDM Association. All Rights Reserved

• Main design focus is on business driven requirements

19 Copyright 2018, PPDM Association. All Rights Reserved

For full details, refer to the Architectural Principles

21 Copyright 2018, PPDM Association. All Rights Reserved

22 Copyright 2018, PPDM Association. All Rights Reserved

… Pinning your hopes for data

Corporate Stewardship is Strategic!

23 Copyright 2018, PPDM Association. All Rights Reserved

We need fundamental change to how we

Me support and supersede the

24 Copyright 2018, PPDM Association. All Rights Reserved

Data Management Strategy and Execution

Data as Executive Data Data Data Data

Harmonized data and

Identify Plan Execute

25 Copyright 2018, PPDM Association. All Rights Reserved

Words mean different things Communication challenges

Many (aging) Software Integration challenges

Rules are different Risk of non-compliance

26 Copyright 2018, PPDM Association. All Rights Reserved

27 Copyright 2018, PPDM Association. All Rights Reserved

Horizontal Table Vertical Table

UWI2 99 09/08/67 UWI1 Rig Release 01/10/87

UWI3 102 02/04/92 UWI1 Name ABC

UWI5 136 09/09/67 UWI2 Rig Release 09/08/67

28 Copyright 2018, PPDM Association. All Rights Reserved