Architectural Principles Versioning
Versioning occurs when multiple copies of an entity attribute need to be stored in order to reflect different values of the data. There are four types of versioning:
Contents |
Source Versioning
Data values may differ among different information sources. The preferred version is stored in the primary table and other versions are in an auxiliary table.
Example:
- WELL and WELL_VERSION
Guidelines
- A main table, which contains the ‘preferred’ values for the object is created. It does not contain a SOURCE reference. (i.e. WELL)
- A version table is created to track all versions of data for the object.
- The version table should be named XXX_VERSION, where XXX is the object this is a version of.
- SOURCE is part of the Primary Key for the VERSION table. (i.e. WELL_VERSION)
Inherited Versioning
The values in child tables are referenced to the source version of the parent table; a different source is not explicitly defined in the child tables.
Example:
- WELL_CORE and its children
Guidelines
- SOURCE is part of the Primary Key, and is carried down to child tables from the table at the ‘top’ of the family of tables.
- Child tables inherit the Primary key of the parent.
- A new and different SOURCE may not be defined for child tables in the family of tables.
Example: For the WELL_TEST set of tables, SOURCE is part of the PK for WELL_TEST - additional sources cannot be defined for its subordinate tables.
Chronological Versioning
Information about an object, such as its status, may vary in time, but the historical information is required for auditing, legal or other purposes.
Example:
- WELL and WELL_STATUS
Guidelines
- Current value is retained in the host table for queries.
- Complete set of values is stored in a new table.
- DATE should not be part of the Primary Key for the version table. Use an OBS NO column for the Primary Key component in the versioned table.
Example: Well status history is kept in the WELL_STATUS table, with the most current status kept in the WELL table.
Alias Versioning
Identification of an object, such as a well or a seismic line, may vary.
Example: SEIS_LINE and SEIS_LINE_ALIAS
Guidelines
- Maintain the preferred version of the name, which is normally used for reporting and retrieval, in the object table.
- Other versions are kept in a separate table, which should be named XXX_ALIAS, where XXX is the name of the object this is an alias for.
- R_SOURCE is used as a foreign key (often part of the Primary key) in the _ALIAS table to indicate what the source of the alias was.
- In some cases, dates when the alias was created, and the REASON the alias exists are important pieces of information.
Go to
- Architectural Principles NULL Data
- Architectural Principles Dates
- Architectural Principles Versioning
- Architectural Principles Vertical Tables
- Architectural Principles Sequence Control
- Architectural Principles Economics and Financial
- Architectural Principles Column Precision
- Architectural Principles Column Field Type
- Architectural Principles Standardized Columns
- Architectural Principles SQL View Definitions
- Architectural Principles Other SQL Definitions
