By Pete Tuff, Senior Consultant.

The PPDM data model has been developed by the Professional Petroleum Data Management Association to standardise diverse petroleum data.  Our consultants are currently implementing a migration of data from version 3.7 of the PPDM model to version 3.8, using our Transformation Manager software.

Here are the details of how we tackled two of the changes required when moving data from PPDM 3.7 to 3.8.

Change 1:  WELL_XREF

Background
Wells and Well Bores are stored in the WELL table in 3.7 and 3.8.  In 3.7, a Well is identified by having a blank parent UWI, as it is the parent.  Well Bores are identified by having a parent UWI (which references the UWI of the Well in the same table).

Change
In 3.8, the means of distinguishing the Wells and Well Bores have changed. The parent UWI has been removed and the well_level_type column introduced. This signifies whether or not the row is a Well or a Well Bore. The WELL_ XREF table is now used to link the Well Bores to the Well. So, for each linked Well Bore, WELL_XREF will store the UWI of the Well and the UWI of the Well Bore.

Solution
Using Transformation Manager, our consultants set the well_level_type to Well for all rows that did not have parent UWI.  Likewise, any rows that had an existing parent_uwi were set to Well Bore. For all Well Bores, the consultants added an entry to WELL_XREF containing the parent UWI and the Well Bore UWI.

Outcome

The 3.7 Well and Well Bore identification method was successfully migrated to the new 3.8 well_level_type classification method.  In addition, 3.7 Well and Well Bore relationships were used to populate the new 3.8 WELL_XREF table. This retained critical Well and Well Bore relationship data.

 

Change 2: Geopolitical information

Background
In PPDM 3.7, the location of a Well is stored in the country, county and province_state columns of the WELL table.  The values also exist in the respective reference tables: R_COUNTRY, R_COUNTY and R_PROVINCE_STATE and must match, due to a foreign key constraint.

Change

The R_COUNTRY, R_COUNTY and R_PROVINCE_STATE tables have been replaced with AREA, AREA_CONTAIN, AREA_COMPONENT and AREA_ALIAS tables.

Solution
Our consultants decided not to populate the R_COUNTRY, R_COUNTY and R_PROVINCE_STATE tables and the country, county and province_state columns of the WELL table.  Instead, they populated the AREA_COMPONENT table, with UWI matching that of the Well. This denotes the type of area, which then references AREA table. The AREA table then had references to all the tables that record additional geopolitical information e.g. alias_full_name and alias_short_name. These were populated by Transformation Manager during the migration.

Outcome
Transformation Manager successfully migrated the existing PPDM 3.7 Country, County and Province State data to the new AREA tables of PPDM 3.8.  This avoided the use of the now US-centric and deprecated R_COUNTRY, R_COUNTY and R_PROVINCE_STATE tables.

Further reading

    Did you like this article? Get our new articles in your inbox with our occasional email newsletter.

    We will never share your details with anyone else, except that your data will be processed securely by EmailOctopus (https://emailoctopus.com/) in a third country, and you can unsubscribe with one click at any time. Our privacy policy: https://www.etlsolutions.com/privacy-policy/.

    data migration planning guide