Architectural Principles Overview
The PPDM Architectural Principles document contains the rules and guidelines that govern the development of the PPDM data model. Architectural Principles establish procedures for naming tables, columns and constraints. They also provide guidelines about how columns should be formatted, how reference tables should be used and how common subject areas, such as Geodetics or Units of Measure should be managed. A series of PPDM Reference Guides that provide detailed information about the use and population of the PPDM Modules supplement this document.
Contents |
Benefits
Architectural Principles are developed to ensure that disparate subject areas within PPDM have a consistent ‘look and feel’, and shared support modules, such as Geodetics or Units of Measure, are dealt with in a homogeneous fashion.
These benefits facilitate uptake and implementation of the model for users in resource-based industries, and enable individual users to understand and use the data in the model structure with a high degree of accuracy. They also provide a helpful framework for the development of new subject areas.
PPDM Architectural Principles and Open Standards
PPDM work groups or the Modeling Committee make recommendations for additions or enhancement to the Architectural Principles. These are reviewed by the Modeling Committee in light of the impact to the following areas:
- Adherence to open standards
- Impact on users of various data base platforms (Oracle, Sybase, Access etc.)
- Integration or modification required to existing model structures
- Effort needed for development or conversion of software by members
- Effort required for implementation or conversion of data models by members
- Effect on performance, usability and understand-ability of the model
- Cost to implement recommendation in the model
The PPDM Association is committed to the development of an open data model that is not dependent on any vendor or software product for implementation. SQL 92 ANSI standards provide the current foundation for the PPDM version 3.x Architectural Principles; this enables the Association to utilize open standards that are independent of any Data base vendor. However, since very few Data base vendors accommodate use of the entire SQL 92 standard, the Architectural Principles are limited to implementation of those standards available to the membership. In practice, the version 3.x Architectural Principles document supports Entry level SQL 92 compliance.
Future design of the data model is likely to require additional data base functionality. Current plans are to review and adopt additional capability as defined in SQL 92 and SQL3 standards as required. Incorporation of significantly changed or enhanced Architectural Principles represents a bench-mark for the PPDM Association in that they represent significant changes that are expected to provide substantial benefits for the membership.
Migration to new models, particularly when new methodologies are employed, can be difficult, time consuming and expensive for the membership. The frequency with which this is done will be minimized by the Association, with careful consideration to the impact among the members. Consequently, significantly changed Architectural Principles will be implemented as part of a new Architectural Release of the model (i.e. version 4.X).
Support and Business Modules in PPDM
PPDM consists of an integrated set of business modules that are designed based on the requirements of the work groups and support modules that are designed to enhance and support the information provided by the business modules.
Business modules are designed to manage the data storage requirements for specific disciplines in the resource industry. Wells, logs, seismic and contracts are good examples. A PPDM work group, through the PPDM modeling process, undertakes Business Module design. Major revisions usually occur when the work group is reconvened to enhance the scope of the model.
Support modules are designed to supplement the functions defined by the business modules, but are not in themselves resource disciplines. Modules related to units of measure, geodetic systems, business associates and projects are good examples of support modules. In contrast to the design methodology for business modules, the design of support these modules are the result of shared development by many work groups, and tend to evolve over time.
In some cases, a work group may be convened that converts a module from a simple support module into a full-scale business module in its own right.
