POSC Specifications
Version 2.3
Relational Implementation Methodology

Architectural Principles

Introduction

There are many principles involved in producing a relational implementation a logical model. This section defines the general principles that were developed for this process, which is called the "projection" of the logical model.

Fundamental Principles

Representation of Logical Model Requirement

The physical schema must be capable of maintaining a faithful representation of the logical model concepts in their entirety. No operation should reduce or expand the semantics of the logical model.

DAE Compatibility Layer Requirement

The application of any projection operation should result in a physical schema on which a compatibility layer1 could be implemented such that it completely isolates applications from the underlying physical RDBMS. This means that applications written to a subset logical model and accessing data through a compatibility layer should be 100 percent portable to any physical implementation of the exact same logical subset.

To support the implementation of the POSC DAE on a relational projection of Epicentre, all logical model rules and the mapping of the relational schema to the logical model must be recorded as meta data in a manner consistent with that required by the Compatibility Layer DAEF being implemented2. In addition, the standard reference data that is valid for the subset of Epicentre being projected must be maintained in the data store.

Documentation

The physical model should be documented in a manner that preserves the logical documentation to the degree which is reasonable. Where appropriate, this should include links back to the logical documentation.

Consequences of Projecting

Potential Epicentre Computing Environment

To discuss the effects of projecting, it is necessary to understand the ways in which Epicentre will be implemented. Figure Potential Epicentre Computing Environment illustrates a potential computing environment that includes full and subset implementations of Epicentre. Four scenarios are depicted:

Potential Epicentre Computing Environment

Application Isolation/Portability 3

Applications that interface to an Epicentre subset through the compatibility layer should be totally isolated from the underlying physical implementation. For example, an application that runs on a particular logical subset implemented on an Oracle projection should work in an identical manner, without modification, on the exact same logical subset implemented on a Sybase projection (or a different Oracle projection).

Without creating multiple types of data access methods for each data access requirement, applications that interface an Epicentre subset using direct SQL calls, however, will generally only work on implementations that use the exact same DBMS and DDL4. An application written for a particular Oracle implementation will only work on that implementation, but not a different Oracle implementation or a Sybase implementation.

Application Interoperability 5

Applications written to either the compatibility layer or to direct SQL should be fully capable of interacting asynchronously through the same subset data store provided they all follow the rules of the logical subset model (see the POSC specification on Subsetting and Extension).

Data Portability 6

Transfer of data through the use of the compatibility layer and Epigramme files provides complete isolation from the underlying physical implementation, just as applications using the compatibility layer are isolated from the physical implementation.

However, it is physically possible to move data directly by means of database dump files between data stores using the same physical implementation when the receiving data store has no conflicting data. If there is an overlap of data, it may not be possible to make such a transfer because of duplicate keys, etc. Under such conditions, it is advisable to use a staged data store and move data into the receiving data store after resolving data conflicts.

It is not possible to move data directly between data stores implemented on different projections with simple DBMS import and export tools as some filtering and/or reformatting would be required.


1Note: A compatibility layer is an implementation of the POSC DAE specifications on a relational database management system. It is called a compatibility layer because it is compatible with both DAE and direct SQL access.

2Note: See the documentation titled Projection Tool Meta Data Model for information on the meta data structures utilized by POSC's sample implementation Projection Tool and Compatibility Layer.

3Note: In the context of projection operations, application isolation/portability refers to the ability to isolate an application from changes in the physical implementation of the underlying Epicentre subset.

4Note: It is possible for an application to be written with multiple types of data access methods for each data access requirement. Each method would be intended a specific set of DDL. If the application knew the DDL it was running against, it could use the appropriate method for that DDL. The practicality of this approach is questionable, depending on the application. In addition, the meta model holding the logical to physical mapping would be required to contain data about the various versions of subsets and their projections.

5Note: In the context of projection operations, application interoperability refers to the ability for different applications to physically interoperate asynchronously through the same data store.

6>Note: In the context of projection operations, data portability refers to the ability to directly move data without loss of information or change in meaning between different physical data stores.


© Copyright 1997-2001 POSC. All rights reserved.