To understand the importance of the DAE featured in this month's lead it is necessary to dissect POSC's objectives in the field of interoperability. For applications to be able to "plug and play" into a foreign data model they would appear to need a complete understanding of the model's internal structure, then they can be tailored to access the data directly. The drawback of this approach is that this means that the application has to have an intimate knowledge of how the database is built, and that an application to database mapping must be hardwired for each new database encountered. A further problem arises when a new version of the database comes along, the application needs a re-write to be able to use the new-improved version of the database. Modern database designers use techniques that not only get around these problems, but also that allow for a better separation of the high level conceptual design of the database from the low level tables and rows of the physical implementation. This is the world of logical data models, of tiered database schema, of entity relational modeling and of the relational "projection".
Complexity
The essentials of these methods is that you first design your data model as the data really exists in the real world. Imbricated hierarchical relationships between objects are described as completely as is possible, so that a many wells belong to an oilfield, and many oilfields belong to a joint venture and many joint ventures belong to a company and so on. Simultaneously, many separate sets of wells will be owned by different joint ventures with different combinations of companies grouped together in the joint ventures. Companies may also enter and leave the JV's bringing a temporal element into the equation. If you think about how hard things can get with these simple high level objects, you get an idea of how complicated the resulting logical model will become once it has completely described fluid properties, well bores, logs and all the other entities that make up the real E&P world. The scope required of POSC's Epicentre data model can be imagined from a description of version 2.0 of the Epicentre Logical Data Model Version 2.0 which was "designed to serve the needs of a very broad variety of technical application programs from many different suppliers and meet the data management needs of all E&P companies throughout the world".
Logical?
The resulting "logical" data model defined by POSC has been defined in a specialized language called Express, which came from the building and construction industry and is used there to described parts and components, and the way they are assembled to produce sub-assemblies and finished products. The Express-defined logical model is complex in the extreme, and its manipulation is not for the faint hearted as PDM revealed in the Discovery story last August. The next step in modern database design is to fit the square peg of the logical model into the round hole of the relational database. A relational database needs everything to be described in two dimensional tables filled with data in rows and columns. The process of creating a relational projection - or a "physical" data model from the logical model is known as mapping, and is something of a black art. It is important to note that the creation of a physical implementation from a logical data model is non-unique. In other words, a single logical model such as Epicentre can be "projected" to many different relational "planes". relational plane
Commercial Epicentre
Thus GeoQuest has projected parts of Epicentre to parts of the GeoFrame physical implementation, IBM has done likewise with PetroBank and PECC/Petrosystems with PetroView. The poor application trying to access these different data models is back to the stage of a complete re-write for each environment. Interoperability nil!
POSC saw this problem way back down the road and while the previously mentioned "Epicentre" implementations are described as POSC compliant, they do not really do it the way POSC intended. The protection built into the complete POSC specification relies on the existence of an intermediate layer between the application calling the data and the database - the Data Access and Exchange Facility (DAEF). This software layer allows the application to see a consistent description of the data which is independent of the underlying data model. Better still, the DAEF is capable of peeking into the physical database, and reading information about how the data is really stored - the metadata - and then supplying this in the way the calling application requires it. Enter the Data Access and Exchange specification and LightSIP.
Click here to comment on this article
If your browser does not work with the MailTo button, send mail to pdm@the-data-room.com with PDM_V_2.0_199710_5 as the subject.
© Oil IT Journal - all rights reserved.