POSC Specifications Version 3.0 |
Epicentre Modeling Methodology |
These are the guiding concepts that are used to create an Epicentre model. These concepts are generally independent of the underlying modeling methodology used to create a model. That is, these concepts are equally valid whether the model is defined using UML, EXPRESS or SQL. In general, EXPRESS terms such as Entity and attribute will be used but each modeling methodology has an equivalent concept.
Armed with the architectural concepts discussed here, the reader should be in a better position to understand Epicentre and the capabilities it offers for handling the demands of E&P technical data management.
Entities are defined to represent classes of real world things with the same set of characteristics. The classes are determined by the underlying nature of the things we wish to describe.
By underlying nature we mean what it is, not what happens to it. For example, we can define an entity material, meaning a material is something composed of matter and has mass. Using a material in two different ways (what happens to it) doesn't make a new material. So, we record what happens to material as a separate concept to the material itself.
Following this analysis process, along with other architectural concepts discussed here, leads to a highly normalized model, where information need only be defined once.
The key to success in integrating the requirements of the various disciplines of E&P is through the use of a single coherent data model with an integrated architecture. Part of this integration is recognition that there are common threads in the data for each discipline. For example, all disciplines deal with activities, documents, contracts, coordinate systems, units of measure, etc. In Epicentre, each of these common concepts have been split out and modeled in a manner that supports the needs of all disciplines. The Epicentre data types provide another level of commonality by defining a limited set of complex data types that is used for all data. This allows seismic traces to be treated the same as well log traces.
The E&P industry is concerned with many real-world things whose state or values change over time, or about which there may be many opinions. The real-world things are individually identified. The data about these objects include characteristics that can be versioned.
The Epicentre logical model specifies that objects (e.g., a core or a well) and their invariant characteristics are not versioned, but most descriptive data (e.g., porosity, location) about each object may be versioned. The non-versioned characteristics of an object are defined as attributes of the object. The characteristics of an object that may change with time and about which there may be many opinions are modeled as properties, whose relationship to an object can be qualified by an activity (e.g., a location produced by the survey of 23 June 1984). An object can therefore have many versions of properties, each being distinguished by the activity that created them. All properties utilize a name prefix of "pty_".
The architectural principle of separating objects, properties and activities is applied throughout Epicentre. This gives Epicentre a different character from many data models currently in use. Thus, items one sees as simple attributes of entities in some data models appear in Epicentre as entities in their own right.
Epicentre supports a distinction between multiple opinions and multiple representations of the same opinion. An example might be the length of a piece of pipe which can be described by the text string "The pipe is 10 feet long" and by a quantity that specifies a numeric value of 10 and a unit of measure of "ft". The physical nature of these representations is very different but the information content is intended to be equivalent. In order to support the knowledge of this intent, Epicentre allows a property to be an alternative representation of another property.
Conversely, someone else may assert an independent opinion that the pipe is 10 feet long. Epicentre allows both opinions to be captured even if they are, by coincidence, identical opinions. Inspection of the data is required in order to determine if they are, in fact, identical.
Another fundamental part of the Epicentre architecture is the there may be many opinions as to the spatial nature of an object. In exploration and production, much of the information we record is composed of coordinates that describe an object's location relative to the earth. However, different situations may require a different view of that geometry. For example, a wellbore is commonly characterized by its one dimensional centerline but an engineer may need to view portions of it as a three dimensional volume or a two dimensional cross-section. Thus, Epicentre treats the spatial nature of an entity as separate versionable concept, similar to a property. Epicentre includes spatial primitives as part of its spatial model but it is recognized that many sites will choose to utilize modern spatial geometry engines to actually maintain the spatial data.
A final point about the Epicentre architecture concerns reference codes-something present in most data models. They define the valid values for certain attributes in the model. As a simple example, consider the hypothetical attribute "month", which would be a relationship to a reference entity named Month. Month would contain 12 instances - "January", "February", "March", etc. Trying to store a value of "Larch" for the "month" attribute would be rejected by the implementing DBMS as invalid because "Larch" is not a value in the corresponding reference entity, Month.
In Epicentre, all reference entities have names beginning with the prefix "ref_", and they may have multiple attributes. This lets us define valid combinations of values to further ensure the integrity of the data that will be accepted in an insert or update to the database.
From an administrative standpoint, there are three types of reference entities in Epicentre. "POSC Fixed" reference entities have values defined by POSC and cannot be added to at local sites. The Month reference entity in the referenced above would be an example of a "POSC Fixed" entity. "POSC Open" reference entities have values defined by POSC, but other values may be added by local site administrators. "Local" reference entities may be populated with different values at every site, and POSC does not deliver any standard instances for them.
For certain regular entities, POSC also provides standard instances. These entities, therefore, have partial reference behavior. An example of this type of data would be geodetic coordinate system data that can be quite complex. These entities will not be prefixed with "ref_".