Other Orthogonal

These are requirements of an implementation that arise outside the Relational Model.

Note: this has nothing to do with ‘object oriented’.

Prescriptions

These are features that an implementation must implement, support or allow.

OO Pre 1 – Compile time type checking

An implementation should check the usage of all types at compile time to avoid type errors that might otherwise occur during execution. Note: this implies type inference by the compiler.

OO Pre 2 – Type inheritance

If an implementation supports type inheritance then it must be in accordance with the Manifesto Inheritance Model (see preamble).

OO Pre 3 – Computational completeness

A language is considered computationally complete if entire applications can be written in it, and that in particular it does not depend on another language for defining new types and operators.

An implementation must be computationally complete, for at least some useful set of applications. Note: An implementation that is a data sub-language would not satisfy this requirement.

An implementation may co-exist with other languages, including being called by a host program and/or calling upon another language to implement user-defined operators and types where there is reason to do so.

OO Pre 4 – Explicit transaction support

Transactions begin with start transaction and end with commit or rollback. Commit means that the updates in that transaction are made permanent in the database. Rollback means that they are discarded and the database state is unaffected by the transaction. These are the transaction boundaries.

Implicit commit means that each statement is treated as if it were preceded by start transaction and followed by commit, that is, as if there were transaction boundaries around each statement.

An implementation must provide explicit support for start transaction and commit, and automatic rollback if a commit fails. It may also provide explicit support for rollback, and implicit commit.

OO Pre 5 – Nested transactions

A nested transaction is one that has boundaries that lie entirely within those of another transaction. Overlapped transactions are not allowed.

An implementation must support nested transactions, which must interact with the same database. A rollback of the outer transaction must cause a rollback of the inner, even if it has already performed a commit. The order in which operations are carried out is not specified.

OO Pre 6 – Aggregation operators

An aggregation operator is one that takes as its arguments an attribute value (or values) from each of the tuples in a relation and returns a single value.

If an implementation provides such an operator which is dyadic, specifies an identity value and is allowed to return any value of its type then it must return a result equivalent to the successive application of the operator to the identity value and each of the values in the tuple, regardless of order.

Note: the result for an empty relation will be the identity value. An implementation may provide other unspecified aggregation operators.

Proscriptions

These are features that an implementation must not provide, support or allow, and that arise outside the Relational Model.

OO Pro 1 – Relvars are not domains

A domain means a relational type.

An implementation must not use individual relvars as if they were relational types.

OO Pro 2 – No pointers

A pointer is a machine address or a physical representation for one.

An implementation must not allow any attribute of any database relvar to be of type pointer.

Note: whether pointer types are allowed for scalar variables, attributes of tuple types and attributes of application relvars is not specified.