be.SIRAPRISE.client
Interface NAMES.RELVARNAMES

Enclosing interface:

NAMES

public static interface NAMES.RELVARNAMES

The RELVARNAMES interface defines the names of all system-defined relvars used in SIRA_PRISE

Author:

Erwin Smout

Field Summary

static java.lang.String	ASSIGNMENTCONSTRAINT The ASSIGNMENTCONSTRAINT relvar lists all declared assignment constraints.
static java.lang.String	ASSIGNMENTCONSTRAINTCHECK The ASSIGNMENTCONSTRAINTCHECK relvar lists all the update operation types that are to cause the check of an assignment constraint.
static java.lang.String	ATTRIBUTE The ATTRIBUTE relvar inventorises the "business elements" that the databases will be built with.
static java.lang.String	ATTRIBUTELOGICALLENGTH The ATTRIBUTELOGICALLENGTH defines the "logical length" for attributes that are declared to be of a variable-length type.
static java.lang.String	ATTRIBUTEPHYSICALLENGTH The ATTRIBUTEPHYSICALLENGTH relvar records the needed encoding length in bytes for each defined attribute.
static java.lang.String	ATTRIBUTEVALUEDISTRIBUTION The ATTRIBUTEVALUEDISTRIBUTION relvars records the collected relvar attribute value distribution statistics.
static java.lang.String	CLIENT The CLIENT relvar lists all the registered clients that can authenticate themselves to the system.
static java.lang.String	CLIENTCERTIFICATE This relvar records the certificates that can be used for authenticating the clients who wish to make a connection to the SIRA_PRISE server.
static java.lang.String	CONSTRAINEDTYPE The CONSTRAINEDTYPE relvar records the names of the "constrained" types that are made available to the server.
static java.lang.String	CONSTRAINTINVOLVESRELVAR
static java.lang.String	CONSTRAINTMESSAGETEXT The CONSTRAINTMESSAGETEXT relvar records the error message texts for the constraints defined for the database.
static java.lang.String	CURRENTCONTEXT Deprecated.
static java.lang.String	CURRENTDATE The CURRENTDATE relation is a singleton relation with a single attribute of type DATE named CURRENTDATE.
static java.lang.String	CURRENTUPDATE Deprecated.
static java.lang.String	CURRENTUSER The CURRENTUSER relation is a singleton relation with a single attribute of type NAME named CURRENTUSER.
static java.lang.String	DATAACTIONREFERENCES This relvar lists the direct references to other relvars made by the expression defining a triggered data action.
static java.lang.String	DATABASECONSTRAINT The DATABASECONSTRAINT relvar lists all the declared database constraints on the database's relvars.
static java.lang.String	DATABASECONSTRAINTCHECK The DATABASECONSTRAINTCHECK relvar lists, for each databaseconstraint, all the update events that require a check of the concernec database constraint.
static java.lang.String	DATASPACE The DATASPACE relvar lists all the storage spaces that are intended for storing data records.
static java.lang.String	DBMSFILE The DBMSFILE relvar lists all the physical files in which data is recorded by the engine.
static java.lang.String	HASHINGINDEXSPACE The HASHINGINDEXSPACE relvar lists all the storage spaces that are intended for storing hash indexes.
static java.lang.String	INDEX The INDEX relvar lists all the defined indexes of the system.
static java.lang.String	INDEXATTRIBUTE The IndexAttribute relvar records which attributes are referenced in which indexcomponent.
static java.lang.String	INDEXCOMPONENT The INDEXCOMPONENT relvar lists the components that make up an index.
static java.lang.String	INDEXID This relvar lists the internal identification number for every defined index.
static java.lang.String	INTERVALTYPE The IntervalType relvar lists the names of the intervaltypes known to SIRA_PRISE, and the name of the base type to which they correspond.
static java.lang.String	JAVABACKEDTYPE The JavaBackedType relvar records the names of the java-backed types that are made available to the server.
static java.lang.String	KEY The KEY relvar inventorises all the declared keys of the database.
static java.lang.String	KEYATTRIBUTE The KEYATTRIBUTE relvar lists all the attributes that participate in a key declared on a relvar.
static java.lang.String	MULTIHASHINGINDEXSPACE The MULTIHASHINGINDEXSPACE relvar lists all the storage spaces that are intended for storing multiple hashing indexes.
static java.lang.String	NEWATTRIBUTEDEFAULTVALUE The NEWATTRIBUTEDEFAULTVALUE relvar defines the value to be assumed by newly added attributes in a relvar, in the case when that relvar already holds some tuples.
static java.lang.String	POSSREP The POSSREP relvar lists the names of the possible representations for every JAVABACKEDTYPE and every INTERVALTYPE added to the SIRA_PRISE catalog.
static java.lang.String	POSSREPCOMPONENT The POSSREPCOMPONENT relvar lists the names of the components (and their component types) of the possible representations listed in the POSSREP relvar.
static java.lang.String	RECORDATTRIBUTE The RECORDATTRIBUTE relvar lists all the attributes that are recorded in a RECORDTYPE.
static java.lang.String	RECORDTYPE The RECORDTYPE relvar records all the physical record types that are defined at the physical database design level, for recording the current relvar values.
static java.lang.String	RECORDTYPEID The RECORDTDYPEID relvars list the internal identification number for every defined record type.
static java.lang.String	RELVAR The RELVAR relvar inventorises the "base" relvars that constitute the database.
static java.lang.String	RELVARATTRIBUTE The RELVARATTRIBUTE relvar inventorises the headings of the "base" relvars that constitute the database.
static java.lang.String	RELVARCARDINALITY This relvar lists the tuple count statistic for each relvar for which statistics have been collected (or provided).
static java.lang.String	RELVARCLUSTER
static java.lang.String	RELVARID The RELVARID relvar lists the internal identification number for every defined base relvar.
static java.lang.String	STORAGESPACE The STORAGESPACE relvar lists the various storage spaces that the engine's physical files are made up of.
static java.lang.String	STORAGESPACEEXTENTS Deprecated.
static java.lang.String	SYSTEMDEFINEDCLIENT This relvar lists the system-provided clients that can successfully connect to the server.
static java.lang.String	SYSTEMDEFINEDCONSTRAINT This relvar lists the system-defined constraints.
static java.lang.String	SYSTEMDEFINEDDBMSFILE
static java.lang.String	SYSTEMDEFINEDRELVAR This relvar lists the system-defined relvars.
static java.lang.String	SYSTEMDEFINEDTYPE The SystemDefinedType relvar lists which types are system-defined, preventing their deletion from the catalog.
static java.lang.String	SYSTEMDEFINEDUSER This relvar lists system-provided users that can succesfully start a transaction.
static java.lang.String	TABLE_DEE TABLE_DEE is a system-defined virtual relvar, defined as the relation literal RELATION(HEADING()BODY(TUPLE())).
static java.lang.String	TABLE_DUM TABLE_DUM is a system-defined virtual relvar, defined as the relation literal RELATION(HEADING()BODY()).
static java.lang.String	TRANSACTIONCONSTRAINT Deprecated. - Support for Transaction Constraints has been removed as of version 1.4.
static java.lang.String	TREEINDEXSPACE The TREEINDEXSPACE relvar lists all the storage spaces that are intended for storing tree indexes.
static java.lang.String	TRIGGEREDDATAACTION The TRIGGEREDDATAACTION relvar lists all the triggered data actions defined to the system.
static java.lang.String	TUPLECONSTRAINT The TUPLECONSTRAINT relvar lists all the declared tuple constraints on the database's relvars.
static java.lang.String	TUPLECONSTRAINTATTRIBUTE Deprecated.
static java.lang.String	TUPLEINDEX The TUPLEINDEX relvar lists all the Tuple Indexes defined in the system.
static java.lang.String	TYPEDIRECTLYREFERENCEDBY
static java.lang.String	TYPEPROPERTIES The TYPEPROPERTIES relvar lists some properties of each type defined to SIRA_PRISE.
static java.lang.String	UDTORDERINGOPERATOR The UDTORDERINGOPERATOR relvar records the details of an ordering operator defined for a user-defined type that is made available to the server.
static java.lang.String	UDTPHYSICALPOSSREPCOMPONENT The UDTPHYSICALPOSSREPCOMPONENT relvar records the details of the physical possrep for each user-defined type that is made available to the server.
static java.lang.String	UDTPOSSREP The UDTPOSSREP relvar declares the existence of additional, non-physical possreps for some user-defined type.
static java.lang.String	UDTPOSSREPCOMPONENT The UDTPOSSREPCOMPONENT relvar declares the components that make up an additional, non-physical possreps for some user-defined type.
static java.lang.String	UDTPPCVALUESELECTOR The UDTPPCVALUESELECTOR relvar declares the formulae for computing the values for the physical possrep components, given a set of non-physical possrep component values.
static java.lang.String	USER This relvar records the identifications of the users of the database managed by the engine.
static java.lang.String	USERCERTIFICATE This relvar records the certificates that can be used for authenticating the identity of a user who wishes to start a transaction.
static java.lang.String	USERDEFINEDTYPE The UserDefinedType relvar records the names of the user-defined types that are made available to the server.
static java.lang.String	VIRTUALRELVAR The VIRTUALRELVAR relvar inventorises the "virtual" relvars that constitute the database.
static java.lang.String	VIRTUALRELVARDEPENDENCYGRAPH
static java.lang.String	VIRTUALRELVARDEPENDSONTYPE
static java.lang.String	VIRTUALRELVARREFERENCES This relvar lists the direct references to other relvars made by the expression defining a virtual relvar.

Field Detail

ASSIGNMENTCONSTRAINT

static final java.lang.String ASSIGNMENTCONSTRAINT

The ASSIGNMENTCONSTRAINT relvar lists all declared assignment constraints.
Heading : CONSTRAINTLABEL(STRING) SP_EXPRESSION(STRING) ERRORCODE(LONG)
Key {ERRORCODE}
Predicate : Update statements are constrained by expression ISEMPTY(<SP_EXPRESSION>), which enforces the business rule '<CONSTRAINTLABEL>'. The generated error code when the constraint is violated is <ERRORCODE>.

The constraintlabel, sp_expression and errorcode have the same meaning as with database constraints. Meaning in particular that sp_expression defines a relational expression that must evaluate to the empty relation for the constraint to be satisfied.

Specifying when exactly an assignment constraint is to be checked, is done by manipulating the ASSIGNMENTCONSTRAINTCHECK relvar.

See Also:

Constant Field Values

ASSIGNMENTCONSTRAINTCHECK

static final java.lang.String ASSIGNMENTCONSTRAINTCHECK

The ASSIGNMENTCONSTRAINTCHECK relvar lists all the update operation types that are to cause the check of an assignment constraint.
Heading : ERRORCODE(LONG) RELVARNAME(NAME) OPERATIONTYPE(INT)
Predicate : The assignment constraint with error code <ERRORCODE> is to be checked upon operations of type <OPERATIONTYPE> on relation variable <RELVARNAME>.

AssignmentConstraintCheck tuples determine for which update operations the Assignment Constraint identified by the errorcode attribute is to be checked.

The relvarname attribute names a relvar for which the Assignment Constraint identified by the errorcode attribute is to be checked (when some update operation is carried out to that relvar), the operationtype attribute identifies whether the constraint will be checked if the assignment carried out is an insertion (operationtype = 2) or a deletion (operationtype = 1). Since an 'update-type-assignment' (i.e. an UPDATE statement was issued rather than ADD, ASSERT, DELETE or UNASSERT) comprises both a deletion and an insertion, this implies that Assignment Constraints will always be checked for UPDATE statements, regardless of the operationtype listed, thus : operationtype 2 means the assignment constraint will be checked for ADD, ASSERT and UPDATE statements issued to the relvar, and operationtype 1 means the assignment constraint will be checked for DELETE, UNASSERT and UPDATE statements issued to the relvar.

See Also:

Constant Field Values

ATTRIBUTE

static final java.lang.String ATTRIBUTE

The ATTRIBUTE relvar inventorises the "business elements" that the databases will be built with.
Heading : TYPENAME(NAME) ATTRIBUTENAME(NAME)
Key {ATTRIBUTENAME}
Predicate : Attribute <ATTRIBUTENAME> is an attribute of Type <TYPENAME>.

If the declared type of an attribute is a variable-length one, then it is also required to register a logical length for this attribute.

It is obviously not possible to delete an attribute as long as that attribute participates in any relvar. Updates to attributes (changing their declared type) are subject to the condition that there is no recorded relvar in which the changed attribute participates.

See Also:

Constant Field Values

ATTRIBUTELOGICALLENGTH

static final java.lang.String ATTRIBUTELOGICALLENGTH

The ATTRIBUTELOGICALLENGTH defines the "logical length" for attributes that are declared to be of a variable-length type.
Heading : LOGICALLENGTH(INT) ATTRIBUTENAME(NAME)
Key {ATTRIBUTENAME}
Predicate : Attribute <ATTRIBUTENAME> has a logical length of <LOGICALLENGTH> positions.

The "logical length" refers to, e.g., the number of allowable tokens in an attribute of type String. The exact meaning of the notion of "logical length" depends on the particular type of the attribute. E.g. the "logical length" of the RELATION type refers to the number of tuples in the relation body. Please note that the notion of "logical length" has no direct connection with the resulting length in bytes of the physical encoding of a value of the type. One might e.g. conceive some variable-length numeric (integer) data type, where the "logical length" defines the maximum number of digits of which a valid value of the type can consist. The type implementation might nevertheless still choose to use the same encoding length (say, e.g., 8 bytes), regardless of the logical length of the attribute. SIRA_PRISE does assume, however, that there is a positive correlation between "logical length" and physical encoding length : it assumes that the physical number of bytes needed to encode a value v1 shall never be less than the number of bytes needed to encode a value v2, if the "logical length" of v1 exceeds the "logical length" of v2. The actual physical encoding lengths for all attributes are maintained automatically by SIRA_PRISE in the ATTRIBUTEPHYSICALLENGTH relvar.

The logical length of an attribute must be within the bounds defined for the corresponding variable-length type, which are recorded in the TYPEPROPERTIES relvar.

Deleting a logical length is possible only if the attribute itself is also deleted within the same MA, or it the attribute is updated to be of a fixed-length type within the same MA. Updating the logical length of an attribute is subject to the same conditions as updates to attributes : if there is any recorded relvar in which this attribute participates, then the update is rejected.

See Also:

Constant Field Values

ATTRIBUTEPHYSICALLENGTH

static final java.lang.String ATTRIBUTEPHYSICALLENGTH

The ATTRIBUTEPHYSICALLENGTH relvar records the needed encoding length in bytes for each defined attribute. Its role is to prevent the user from defining records (or indexes) that are larger than can fit within the page size of the storage space they are recorded in.
Heading : PHYSICALLENGTH(INT) ATTRIBUTENAME(NAME)
Key {ATTRIBUTENAME}

See Also:

Constant Field Values

ATTRIBUTEVALUEDISTRIBUTION

static final java.lang.String ATTRIBUTEVALUEDISTRIBUTION

The ATTRIBUTEVALUEDISTRIBUTION relvars records the collected relvar attribute value distribution statistics.
Heading : RELVARNAME(NAME) ATTRIBUTENAME(NAME) VALUECOUNT(LONG) FREQUENCY(FLOAT) STDDEV(FLOAT)
Key {RELVARNAME ATTRIBUTENAME}
Predicate : The distinct values count of attribute <ATTRIBUTENAME> in relvar <RELVARNAME> is <VALUECOUNT>, the average frequency is <FREQUENCY> with a standard deviation of <STDDEV>.

AttributeValueDistributions are used by SIRA_PRISE when making estimates about the cost of various possible evaluation strategies for a relational expression. In particular, these statistics are useful for determining whether and to what extent a restriction involving an equality test on some attribute implies a reduction factor in the cardinality of the result.

In principle, users should never update this relvar directly, because the contents of this relvar are also updated as a result of executing a STATISTICS command, but even so the possibility to update this relvar directly remains open.

The meaning of the attributes of the ATTRIBUTEVALUEDISTRIBUTION relvar is as follows :

RELVARNAME	The name of the relvar this statistic is about.
ATTRIBUTENAME	The name of the attribute this statistic is about.
VALUECOUNT	The number of distinct values that appear in the relvar named in this tuple for the attribute named in this tuple.
FREQUENCY	The average number of times a single value appears in the named relvar for the named attribute.
STDDEV	The standard deviation measured on the series of appearance counts from which the FREQUENCY attribute value was derived. STDDEV values that are relatively small, compared to the FREQUENCY value, indicate an "even" distribution of values across the relvar's tuples. Relatively large STDDEV values indicate that certain specific values appear significantly more in this attribute than certain other values.

These statistics are used by SIRA_PRISE when access paths must be decided to evaluate some relational expression. Note that the measured relvar cardinality must always be equal to the valuecount of any attribute in that relvar, multiplied by the average frequency of that same attribute for that same relvar.

See Also:

Constant Field Values

CLIENT

static final java.lang.String CLIENT

The CLIENT relvar lists all the registered clients that can authenticate themselves to the system.
Heading : CLIENTID(NAME) TRUSTAUTHENTICATION(BOOLEAN)
Key {CLIENTID}
Predicate : Client <CLIENTID> is a client for whom it is <TRUSTAUTHENTICATION> that this client's user authentications can be trusted.

This relvar records the identities of the clients that can successfully connect to the SIRA_PRISE server. The TRUSTAUTHENTICATION field indicates whether a user authentication by the client described by the tuple, will be trusted by SIRA_PRISE.

See Also:

Constant Field Values

CLIENTCERTIFICATE

static final java.lang.String CLIENTCERTIFICATE

This relvar records the certificates that can be used for authenticating the clients who wish to make a connection to the SIRA_PRISE server.
Heading : CLIENTID(NAME) ALGORITHM(NAME) CERTIFICATE(BITS)
Key {CLIENTID ALGORITHM}
Predicate : Client <CLIENTID> is a certified client holding certificate <CERTIFICATE> to be used with signing algorithm <ALGORITHM>.

The ALGORITHM attribute identifies a signing algorithm that can be used by the client the tuple describes, and the CERTIFICATE attribute records the X.509 certificate that must be used by SIRA_PRISE to authenticate the named client using the named algorithm.

See Also:

Constant Field Values

CONSTRAINEDTYPE

static final java.lang.String CONSTRAINEDTYPE

The CONSTRAINEDTYPE relvar records the names of the "constrained" types that are made available to the server.
Heading : TYPENAME(NAME) BASETYPE(NAME) SP_EXPRESSION(STRING)
Key {TYPENAME}
Predicate : Type <TYPENAME> is type <BASETYPE>, constrained by expression <SP_EXPRESSION>.

Constrained types consist of a set of values which is a subset (and presumably, a proper subset) of some other known type, where that subset can be defined using some boolean expression (the constrained type's "type predicate") in which the only allowable variable is of the "other known type".

Constrained types can be used as a type for attribute declarations, but they cannot be used (yet) as a type in possrep component declarations. If a constrained type's base type is ordered (and some interval type will thus automatically have been created for that base type), then adding this constrained type will not automatically cause the creation of an intervaltype corresponding to the new (constrained) type.

The sp_expression attribute defines the boolean expression that will test, for any value of the base type, whether that value is also a value of the constrained type. References to the value being tested must be specified using the syntax 'PARAMETER(V(...))', with the name of the base type replacing the ellipses. E.g. to specify the set of integers [1000-9999] as a constrained type, the following expression would be needed : AND(GT(PARAMETER(V(INT)),INT(999)),GT(INT(10000),PARAMETER(V(INT))))

Deleting constrained types is obviously subject to the restrictions that it cannot be currently in use, and updating constrained types is subject to the condition that there are no attributes of this type, or of any type that depends on this type, that appear in recorded relvars (i.e. in a relvar that has a recordtype associated with it).

See Also:

Constant Field Values

CONSTRAINTINVOLVESRELVAR

static final java.lang.String CONSTRAINTINVOLVESRELVAR

See Also:

Constant Field Values

CONSTRAINTMESSAGETEXT

static final java.lang.String CONSTRAINTMESSAGETEXT

The CONSTRAINTMESSAGETEXT relvar records the error message texts for the constraints defined for the database.
Heading : CONSTRAINTMESSAGETEXT(STRING) ERRORCODE(LONG)
Key {ERRORCODE}
Predicate : The text to be displayed upon violations of the constraint with error code <ERRORCODE> is '<CONSTRAINTMESSAGETEXT>'.

The text to be returned to the SIRA_PRISE client when the constraint with the specified errorcode is violated, can optionally be added to the SIRA_PRISE system this way. If such a text is returned to a client, it is first inspected for the presence of paragraph marks (§, Unicode 00A7) surrounding an attribute name. All such constructs in the message text are replaced with the actual value of that particular attribute in the tuple that causes the constraint violation. Please note that this is merely a textual facility. No checks whatsoever are made to verify that any name between paragraph marks is indeed an attribute of the corresponding constraint expression (database and/or assignment constraints) or relvar (tuple constraints).

In the case of constraint message texts corresponding to a key constraint, these §-surrounded attribute names can be either of :

• An attribute name of the relvar the key is defined on
• A non-key attribute of that same relvar, prefixed with a double underscore. The values for these 'additional' attributes come from the second tuple, that shares its key value with the first one, thus effectively constituting a key violation.

See Also:

Constant Field Values

CURRENTCONTEXT

static final java.lang.String CURRENTCONTEXT

Deprecated.

See Also:

Constant Field Values

CURRENTDATE

static final java.lang.String CURRENTDATE

The CURRENTDATE relation is a singleton relation with a single attribute of type DATE named CURRENTDATE. The value of that attribute is, predictably, the current system date (of the machine on which the JVM is running in which the server operates).

See Also:

Constant Field Values

CURRENTUPDATE

static final java.lang.String CURRENTUPDATE

Deprecated.

See Also:

Constant Field Values

CURRENTUSER

static final java.lang.String CURRENTUSER

The CURRENTUSER relation is a singleton relation with a single attribute of type NAME named CURRENTUSER. The value of that attribute is, predictably, the ID of the user owning the transaction that issued the update (this is the userID field that was provided to the server when the transaction was started). If the transaction is an anonymous one (the user ID provided when the transaction was started is the zero-length string), then this relvar will be empty.

See Also:

Constant Field Values

DATAACTIONREFERENCES

static final java.lang.String DATAACTIONREFERENCES

This relvar lists the direct references to other relvars made by the expression defining a triggered data action.

See Also:

Constant Field Values

DATABASECONSTRAINT

static final java.lang.String DATABASECONSTRAINT

The DATABASECONSTRAINT relvar lists all the declared database constraints on the database's relvars.
Heading : CONSTRAINTLABEL(STRING) SP_EXPRESSION(STRING) ERRORCODE(LONG)
Key {ERRORCODE}
Predicate : The database is constrained by expression ISEMPTY(<SP_EXPRESSION>), which enforces the business rule '<CONSTRAINTLABEL>'. The generated error code when the constraint is violated is <ERRORCODE>.

All database constraints must be defined in this way (except for relvar keys and tuple constraints of course). Errorcode is the unique number identifying the constraint within the entire SIRA_PRISE system.

Constraintlabel is a textual description of the condition that the constraint enforces, e.g. "Each relvar must have at least one key.".

The sp_expression attribute defines a relational expression that must be empty for the database value to be valid. E.g. SEMIMINUS(KEY,PROJECT(RELVAR,(RELVARNAME))) defines that there cannot be tuples in the key relvar with a relvarname attribute value that does not appear in any relvar tuple.

Adding a new database constraint will be rejected if the current database value is such that the new constraint is violated.

When deleting a databaseconstraint for which a CONSTRAINTMESSAGETEXT has previously been added, that constraintmessagetext must be deleted within the same MA, or the delete will fail.

For all defined database constraints, the catalog also records information about when to check this constraint.

See Also:

Constant Field Values

DATABASECONSTRAINTCHECK

static final java.lang.String DATABASECONSTRAINTCHECK

The DATABASECONSTRAINTCHECK relvar lists, for each databaseconstraint, all the update events that require a check of the concernec database constraint.
Heading : RELVARNAME(NAME) OPERATIONTYPE(INT) ERRORCODE(LONG)
Predicate : The database constraint with error code <ERRORCODE> is to be checked upon operations of type <OPERATIONTYPE> on relation variable <RELVARNAME>.

This relvar lists, for each database constraint, which kinds of update to which relvars can potentially cause a violation of that database constraint (and must therefore be checked when such an update occurs to a listed relvar).

The OPERATIONTYPE attribute indicates whether the check is for an INSERT (operationtype=2) to the named relvar, or for a DELETE (operationtype=1) to it. UPDATE operations always involve both a DELETE and an INSERT.

See Also:

Constant Field Values

DATASPACE

static final java.lang.String DATASPACE

The DATASPACE relvar lists all the storage spaces that are intended for storing data records.
Heading : FILENAME(NAME) STORAGESPACEID(INT) GAPCOMPRESSIONTHRESHOLD(INT) MAXIMUMGAPS(INT)
Key {FILENAME STORAGESPACEID}
Predicate : StorageSpace <STORAGESPACEID> of File <FILENAME> stores tuple records. Pages contain at most <MAXIMUMGAPS> gaps. Compression attempted at <GAPCOMPRESSIONTHRESHOLD> gaps.

Adding a dataspace tuple to the catalog will mark a newly appended storagespace as being intended for recording data records.

The gap compression threshold and the maximum gapcount define the way in which SIRA_PRISE will cope with 'gaps' that may appear on a data page if and when tuples, and thus the corresponding records, are removed from some relvar.

Changing an existing dataspace definition to improve the gap handling is not -yet- supported.

See Also:

Constant Field Values

DBMSFILE

static final java.lang.String DBMSFILE

The DBMSFILE relvar lists all the physical files in which data is recorded by the engine.
Heading : FILENAME(FILENAME) PAGESIZE(INT)
Key {FILENAME}
Predicate : <FILENAME> is a dbms file with pagesize <PAGESIZE>.

Adding a DBMSFILE tuple will also create the file in the appropriate directory in the server's file system. The pagesize attribute must have a value of at least 4096 and not exceeding 65536.

Note that adding a DBMSFILE does nothing but declare the existence of the physical file, and create that file in the file system with only a file header. In order to actually record anything in this file, storagespaces must be appended to it. Please note that, allthough the side-effect of physical file creation is recoverable (SIRA_PRISE removes the newly created file as part of its rollback procedure - file deletion is also recoverable in a similar way), it is nevertheless still a good idea to reduce the possibility of rollbacks to an absolute minimum by issuing these commands only as a single-assignment, i.e. not as part of an MA.

Deleting a dbms file will also remove the file from server's file system. Nevertheless, it may occasionally occur that the delete fails because some internal components of the system still have this file in use. In that case, do the delete immediately after SIRA_PRISE has been restarted.

Updating the name of a file is supported, and the update will also be reflected in the file system. Updating the page size is also possible, but note that this operation involves a complete reformatting of the file, during which period NONE of the file's information will be accessible to the SIRA_PRISE users. Use only with care.

See Also:

Constant Field Values

HASHINGINDEXSPACE

static final java.lang.String HASHINGINDEXSPACE

The HASHINGINDEXSPACE relvar lists all the storage spaces that are intended for storing hash indexes.
Heading : FILENAME(NAME) STORAGESPACEID(INT)
Predicate : StorageSpace <STORAGESPACEID> of File <FILENAME> is used for storing hash indexes.

HASHINGINDEXSPACE tuples mark the corresponding storagespace as being intended for recording tree indexes. Hashing indexes will maintain a list of computed checksums for the tuples (of the relvar whose tuple records are) indexed, according to the precise definition of the index (its list of index components) and the relevant type implementations (which are responsible for creating the appropriate bit pattern of each value to be recorded).

See Also:

Constant Field Values

INDEX

static final java.lang.String INDEX

The INDEX relvar lists all the defined indexes of the system.
Heading : FILENAME(FILENAME) STORAGESPACEID(INT) RELVARNAME(NAME) RECORDTYPENAME(NAME) INDEXNAME(NAME)
Key {RELVARNAME INDEXNAME}
Predicate : The index with name <INDEXNAME> physically indexes type <RECORDTYPENAME> records of relation variable <RELVARNAME>. The index is physically stored in indexspace <STORAGESPACEID> of dbms file <FILENAME>.

An INDEX tuple will cause an index of the specified name to be recorded on the (records of the) specified recordtype. This index will be recorded in the storagespace identified by filename and storagespaceid, which must be an indexspace (either tree- or (multi)hashing-). The type of index space will determine the type of index.

Note that an INDEX tuple merely declares the existence of the index. No attributes will actually be indexed by this declaration. The "value" that is indexed for each (record for a) relvar tuple if no index components are added, will resemble the empty tuple. Such an index will thus effectively constitute just a simple sequential list of tuple-id's (and cause the predictable performance characteristics on large relvars). It is thus certainly advisable to define the components of this index within the same MA, if the relvar already has recorded tuples.

Deleting an index will also automatically delete all the indexcomponents for this index. If the index is recorded in a single-index storage space (a TreeIndexSpace or a HashingIndexSpace), then the indexspace in which the index is recorded will become available for recording some other index.

Changing existing index declarations is not (yet) supported. Modifying index definitions can always be achieved by first defining a new index (according to the new characteristics), and then deleting the old one.

See Also:

Constant Field Values

INDEXATTRIBUTE

static final java.lang.String INDEXATTRIBUTE

The IndexAttribute relvar records which attributes are referenced in which indexcomponent. Its purpose is to prevent renames of attributes that would render a valid existing expression (in this case an expression that defines the value of an index component) invalid (because of illegal attribute references).

See Also:

Constant Field Values

INDEXCOMPONENT

static final java.lang.String INDEXCOMPONENT

The INDEXCOMPONENT relvar lists the components that make up an index.
Heading : RELVARNAME(NAME) ORDINAL(INT) INDEXNAME(NAME) SP_EXPRESSION(STRING)
Key {RELVARNAME INDEXNAME ORDINAL}
Predicate : Component <ORDINAL> of index <INDEXNAME> on relvar <RELVARNAME> is the expression <SP_EXPRESSION>.

Indexcomponent tuples define the structure of an index. The 'relvarname' and 'indexname' attributes identify the index, the 'ordinal' attribute identifies the position of the index component relative to the others, and the 'sp_expression' attribute defines the expression for computing the value that will be indexed for some tuple of the indexed relvar. This expression is not limited to attribute references exclusively. E.g. if a relvar has an interval-typed attribute V, then it is possible to have an index on THE_BEGIN(V). However, there is currently little point in doing this, since SIRA_PRISE is not yet smart enough to actually use such indexes for purposes of query optimisation (RESTRICT(R,EQ(THE_BEGIN(V),...))).

Any addition, deletion or update of an indexcomponent to an existing index will entirely rebuild the index.

See Also:

Constant Field Values

INDEXID

static final java.lang.String INDEXID

This relvar lists the internal identification number for every defined index. Please observe that it is unadvisable to use these values anywhere. In a recovery scenario using rollforwards, these relvars are guaranteed not to hold the same ID values as the ones they had when the original updates occurred.

See Also:

Constant Field Values

INTERVALTYPE

static final java.lang.String INTERVALTYPE

The IntervalType relvar lists the names of the intervaltypes known to SIRA_PRISE, and the name of the base type to which they correspond.

See Also:

Constant Field Values

JAVABACKEDTYPE

static final java.lang.String JAVABACKEDTYPE

The JavaBackedType relvar records the names of the java-backed types that are made available to the server.
Heading : TYPENAME(NAME)
Predicate : Type <TYPENAME> is a DBMS supported type backed by a java implementation.

When adding a tuple to this relvar, the availability of the corresponding type implementation class is checked. Some properties of the type will be drawn from the implementation class, and recorded in the TYPEPROPERTIES relvar. Entries will also be recorded for the type's possreps and its components in the POSSREP and POSSREPCOMPONENT relvars. And if an (implementation for) an ordering operator for this type can be found, then an entry is also registered for the corresponding interval type in the INTERVALTYPE relvar.

It is impossible to remove a type as long as there are any references to the type, directly or indirectly. Direct references may be : an attribute that is declared to be of that type, a constrained type that is declared to be a specialization of this type, or a possrep component in some type that is declared to be of this type. Any existing indirect references to the type will obviously also prohibit the deletion of that type. The system-defined types can never be deleted, either.

As far as the catalog is concerned, there is nothing to UPDATE about JavaBackedTypes. It is however conceivable to replace an existing implementation class with a new version. In such cases, it is your responsibility to assure complete backward compatibility between new and old versions. Failing to meet this condition cannot be detected by SIRA_PRISE, and it may disrupt the operation of the server and render your databases corrupt.

See Also:

Constant Field Values

KEY

static final java.lang.String KEY

The KEY relvar inventorises all the declared keys of the database.
Heading : RELVARNAME(NAME) ERRORCODE(LONG)
Key {ERRORCODE}
Predicate : Relation variable <RELVARNAME> has a key with error code <ERRORCODE>.

Please note that adding a KEY tuple to the catalog only has the effect of defining an empty (i.e. attributeless) key, meaning the relvar will be allowed to contain at most one single tuple. Defining a key's attributes is done by adding KEYATTRIBUTE tuples.

Relvars for which no KEY is defined, will be assumed to be all-key ones, i.e. there is a single key to the relvar consisting of all its attributes, or iow, the only uniqueness constraint that applies to such a relvar is the one that derives naturally from having to contain a relation.

See Also:

Constant Field Values

KEYATTRIBUTE

static final java.lang.String KEYATTRIBUTE

The KEYATTRIBUTE relvar lists all the attributes that participate in a key declared on a relvar.
Heading : ERRORCODE(LONG) ATTRIBUTENAME(NAME)
Predicate : Attribute <ATTRIBUTENAME> is part of the key with error code <ERRORCODE>.

If a key attribute is deleted, a check is done to ensure that the current value of the relvar that this impacted key is declared on, satisfies the new, stricter, constraint.

See Also:

Constant Field Values

MULTIHASHINGINDEXSPACE

static final java.lang.String MULTIHASHINGINDEXSPACE

The MULTIHASHINGINDEXSPACE relvar lists all the storage spaces that are intended for storing multiple hashing indexes.
Heading : FILENAME(NAME) STORAGESPACEID(INT) GAPCOMPRESSIONTHRESHOLD(INT) MAXIMUMGAPS(INT)
Key {FILENAME STORAGESPACEID}
Predicate : StorageSpace <STORAGESPACEID> of File <FILENAME> is used for storing multiple hashing indexes. Pages contain at most <MAXIMUMGAPS> gaps. Compression attempted at <GAPCOMPRESSIONTHRESHOLD> gaps.

As with HashingIndexSpaces, this will mark the corresponding storagespace as being intended for recording hashing indexes. The difference with a HashingIndexSpace is that a HashingIndexSpace can contain only one single index, whereas MultiHashingIndexSpaces can contain more than one. As with DataSpaces, the management of gaps that appear on the page in the event of removal of some index entry, is based on the values provided for the gap compression threshold and the maximum number of allowable gaps.

Updating multihashingindexspace tuples to finetune the gap handling is not -yet- supported.

See Also:

Constant Field Values

NEWATTRIBUTEDEFAULTVALUE

static final java.lang.String NEWATTRIBUTEDEFAULTVALUE

The NEWATTRIBUTEDEFAULTVALUE relvar defines the value to be assumed by newly added attributes in a relvar, in the case when that relvar already holds some tuples.
Heading : RELVARNAME(NAME) SP_EXPRESSION(STRING) ATTRIBUTENAME(NAME)
Key {RELVARNAME ATTRIBUTENAME}
Predicate : The value for attribute <ATTRIBUTENAME> in records of relation variable <RELVARNAME> is defined by the expression <SP_EXPRESSION>.

NewAttributeDefaultValues are used by SIRA_PRISE when an attribute is added to a relvar that already has recorded tuples. The record(s) that is(are) extended with the additional attribute, will record the given value for the new attribute in every tuple record. The given value must be a valid textual representation of a value of the type of the new attribute. It is not yet possible to enter an expression that refers to other attributes in the tuple or to other relvars in the database. That is, the SP_EXPRESSION attribute can only hold expressions that are literals.

Deleting NewAttributeDefaultValues can be done immediately after the addition of the relvar attribute has been carried out successfully (but not within the same MA, obviously). This is not necessary, but it will be impossible to remove the attribute from the relvar as long as the NewAttributeDefaultValue is still present in the catalog.

Updates to NewAttributeDefaultValues are not supported (it would be pretty pointless to do so since the information it contains is not used any more, anywhere).

See Also:

Constant Field Values

POSSREP

static final java.lang.String POSSREP

The POSSREP relvar lists the names of the possible representations for every JAVABACKEDTYPE and every INTERVALTYPE added to the SIRA_PRISE catalog. Note that these are obtained from the type's implementation class. Constrained types always inherit the entire set of possreps defined for their supertype, and user-defined types have their own set of relvars for specifying the possreps.

See Also:

Constant Field Values

POSSREPCOMPONENT

static final java.lang.String POSSREPCOMPONENT

The POSSREPCOMPONENT relvar lists the names of the components (and their component types) of the possible representations listed in the POSSREP relvar.

See Also:

Constant Field Values

RECORDATTRIBUTE

static final java.lang.String RECORDATTRIBUTE

The RECORDATTRIBUTE relvar lists all the attributes that are recorded in a RECORDTYPE.
Heading : RELVARNAME(NAME) RECORDTYPENAME(NAME) ATTRIBUTENAME(NAME) ORDINAL(INT)
Key {RELVARNAME RECORDTYPENAME ATTRIBUTENAME} and {RELVARNAME RECORDTYPENAME ORDINAL}
Predicate : Attribute <ATTRIBUTENAME> is attribute number <ORDINAL> in the type <RECORDTYPENAME> records of relation variable <RELVARNAME>.

A RecordAttribute tuple determines the ordinal position of the (encoding of the) value of the named attribute in the records (of the named Record Type) for some tuple of the named relvar. Ordinal positions are not required to form a set of strictly consecutive numbers. They just determine the physical position of an encoding of a value in a record, in the sense that the ordering of the attribute's value encodings is the same as the ordering of the corresponding ordinal numbers. So it is possible to define recordattributes with ordinal numbers that are a multiple of (e.g) 10, so that later on, attributes can easily be added "in the middle of a record" (if there is a good reason to do this).

When deleting recordattribute tuples, existing records of this record type will be reformatted so that they no longer contain values for the attribute being removed. If there are no other recordtypes left for this relvar in which the concerned attribute appears, then the recordings of the attribute values are moved to resource files directly in the server's file system.

Updates to recordattributes (e.g. to change an ordinal position and reformat the records) are not (yet) supported.

See Also:

Constant Field Values

RECORDTYPE

static final java.lang.String RECORDTYPE

The RECORDTYPE relvar records all the physical record types that are defined at the physical database design level, for recording the current relvar values.
Heading : FILENAME(FILENAME) STORAGESPACEID(INT) RELVARNAME(NAME) RECORDTYPENAME(NAME) INDEXNAME(NAME)
Key {RELVARNAME RECORDTYPENAME} and {RELVARNAME INDEXNAME}
Predicate : The record type <RECORDTYPENAME> is for recording tuples of relvar <RELVARNAME>, and its records are stored in data space <STORAGESPACEID> in dbms file <FILENAME>. Its locator index is named <INDEXNAME>.

Adding a RecordType tuple will cause a new recordtype to be associated with the named relvar. Records of this type will be recorded in the storagespace identified by filename/storagespaceid, which must be a dataspace. The physical location of the records within that dataspace will be determined by the index whose name is given in the indexname attribute, and which must identify a hashing index.

Since the physical location of this new record type's records cannot be managed unless a hashing index exists for this recordtype, it is required to add an INDEX tuple defining this hashing index within the same MA as well (with the same indexname value as the one in the new recordtdype tuple), or the add will fail.

Note that adding the RecordType has no other effect than just declaring its existence, i.e. no actual attributes of the relvar are made part of this recordtype by this declaration, and the RecordType itself remains "empty". It is likely that RECORDATTRIBUTE tuples need also be added within the same MA to specify which attributes of the relvar are to appear in this recordtype. This can be done in two distinct steps, but this will cause two distinct "conversion" operations to be performed for the record type : one when the recordtype is defined to write an "empty" record for each tuple of the relvar, and a second one when the record attributes are added to convert the "empty" records to records containing some attribute values.

More than one recordtype can be associated with a relvar, in which case more than one record will exist (possibly at different physical locations in the same dataspace, or in different dataspaces of the same file, or in different files) for each single tuple of that relvar. In any case, one single record type does not necessarily hold all of the relvar's attributes. If an attribute participates in a relvar, but not in any record of that relvar, then the values for this attribute in that relvar's tuples are recorded directly in the server's file system, rather than in records within dataspaces within dbms files. In the case where more than one recordtype is associated with a relvar, it is required that a TUPLEINDEX be defined on each record type of that relvar.

As long as a relvar has a nonempty value, removing its last RecordType is prohibited. Nor can recordtype data be removed as long as there are still indexes on this recordtype. Index definitions on this record type must therefore be removed either before this delete, or at the very latest within the same MA. The locator index (this is the index named in the recordtype tuple) can (and must) only be deleted in the same MA that deletes the record type.

Obviously, removing a recordtype associated with some relvar, will also require removing the RecordAttribute tuples for this recordtype.

Changing existing recordtype data is not (yet) supported. Nor is "simulating" such an update by issuing a delete and a "compensating" add within the same MA. Any change that is needed in recordtype definitions can always be performed by first adding a new recordtype that reflects the desired properties, and then afterwards deleting the old one.

See Also:

Constant Field Values

RECORDTYPEID

static final java.lang.String RECORDTYPEID

The RECORDTDYPEID relvars list the internal identification number for every defined record type. Please observe that it is unadvisable to use these values anywhere in your applications. In a recovery scenario using rollforwards, these relvars are guaranteed not to hold the same ID values as the ones they had when the original updates occurred.

See Also:

Constant Field Values

RELVAR

static final java.lang.String RELVAR

The RELVAR relvar inventorises the "base" relvars that constitute the database.
Heading : RELVARNAME(NAME) RELVARPREDICATE(STRING)
Key {RELVARNAME}
Predicate : <RELVARNAME> is a relation variable whose predicate is '<RELVARPREDICATE>'.

RELVAR tuples hold the name that a relvar will be known under to SIRA_PRISE (and to the user of course), and the predicate that documents the relvar's intended meaning. Defining the heading (the relation type) of the relvar is done by manipulating the RELVARATTRIBUTE relvar.

There is a little text substitution feature in the relvarpredicate attribute. Some functions within SIRA_PRISE are capable of replacing every occurrence within the predicate of an attributename surrounded by paragraph marks (§, Unicode 00A7), by an actual value for that attribute coming from some tuple of the involved relvar. E.g. the predicate of the catalog relvar named 'RELVAR' is "§Relvarname§ is a Relation variable whose predicate is "§Relvarpredicate§".", and some functions within SIRA_PRISE would use that information to generate, e.g., the sentence "RELVAR is a Relation variable whose predicate is "§Relvarname§ is a Relation variable whose predicate is "§Relvarpredicate§".".". Please note that this is merely a textual facility. No checks whatsoever are made to verify that any name between paragraph marks is indeed an attribute of the relvar, or that all attributes of the relvar must be mentioned in the predicate this way.

It is not possible to delete a relvar as long as there are still physical recording data (i.e. RecordType tuples) for this relvar, or as long as it is still involved in any databaseconstraint, assignment constraint, triggered data action expression or virtual relvar expression. Updating a relvar name (which amounts to deleting the old relvar and adding a completely different one) is subject to the same condition.

Whenever a new base relvar is defined, it is also automatically assigned an internal ID.

See Also:

Constant Field Values

RELVARATTRIBUTE

static final java.lang.String RELVARATTRIBUTE

The RELVARATTRIBUTE relvar inventorises the headings of the "base" relvars that constitute the database.
Heading : RELVARNAME(NAME) ATTRIBUTENAME(NAME)
Predicate : Attribute <ATTRIBUTENAME> is an attribute of relation variable <RELVARNAME>.

One relvarattribute tuple represents one attribute in a relvar's heading. The declaration of the type corresponding to the attribute name is done at the Attribute level, not at the relvarattribute level. The type of an attribute in a base relvar must be scalar.

It is not possible to delete a relvarattribute as long as that attribute still participates in any key on this relvar, or is referenced in any tuple constraint on this relvar, any triggered data action or any assignment constraint involving this relvar, or any virtual relvar involving this relvar.

Adding attributes to a relvar for which there are already recorded tuples, obviously requires that the new attribute be assigned a value in each tuple that already appears. This situation requires that a NEWATTRIBUTEDEFAULTVALUE tuple also be added to the catalog within the same MA (if such a tuple was not already present). It may also be desirable to include this new relvar attribute immediately in one of the relvar's existing record types. This can be achieved by adding a RECORDATTRIBUTE tuple within the same MA that adds the relvarattribute tuple.

See Also:

Constant Field Values

RELVARCARDINALITY

static final java.lang.String RELVARCARDINALITY

This relvar lists the tuple count statistic for each relvar for which statistics have been collected (or provided).
Heading : RELVARNAME(NAME) CARDINALITY(LONG)
Key {RELVARNAME}
Predicate : The last measured cardinality of relvar <RELVARNAME> is <CARDINALITY>.

This relvar records the tuple count in a relvar after successfull execution of a STATISTICS command. The information is used to make cardinality estimates when SIRA_PRISE needs to decide on an evaluation strategy for some relational expression. As with the attribute value distribution statistics, users shouldn't need to update this relvar directly, but they can do so if they see a good reason for it. That is, it is possible to provide (estimates of) statistics about the content of new relvars even before SIRA_PRISE's own statistics collection mechanism has been invoked for such a relvar.

See Also:

Constant Field Values

RELVARCLUSTER

static final java.lang.String RELVARCLUSTER

See Also:

Constant Field Values

RELVARID

static final java.lang.String RELVARID

The RELVARID relvar lists the internal identification number for every defined base relvar. Please observe that it is unadvisable to use these values anywhere at the application level. In a recovery scenario using rollforwards, these relvars are guaranteed not to hold the same ID values as the ones they had when the original updates occurred.

See Also:

Constant Field Values

STORAGESPACE

static final java.lang.String STORAGESPACE

The STORAGESPACE relvar lists the various storage spaces that the engine's physical files are made up of.
Heading : FILENAME(NAME) STORAGESPACEID(INT) PAGECOUNT(INT) EXTENTSCOUNT(INT)
Key {FILENAME STORAGESPACEID}
Predicate : StorageSpace <{2}> of Dbms File <{1}> has <{0}> pages and is extensible with up to <{3}> extents.

Adding a storagespace tuple to the catalog will append a storagespace to the specified file, and initialize/format it with the specified number of pages (the size of which is defined at the dbms file level). Computing an adequate number of pages, given an expected data volume for a relvar, can be done using the space calculations functions in the supplied web client package.

Since the pages are immediately initialized/formatted, and the format of the system information on those pages will depend on the particular purpose that the storagespace serves, it must also be known what 'kind' of storagespace this will be. It is therefore necessary to also add either a dataspace or some indexspace tuple (multihashingindexspace, hashingindexspace, treeindexspace) within the same MA.

Deleting storage spaces is supported, but note that this operation involves a complete reorganization of the entire dbms file the storage space appears in, during which period NONE of the information contained in the ENTIRE dbms file will be accessible for the users. Use only with care.

Updating storagespace tuples (e.g. for extending the number of pages) is not supported. If you expect a need to be able to extend the number of pages in some storage space after it has initially been defined with some "smallish" number, your best option is to define StorageSpaceExtents, by providing a nonzero EXTENTSCOUNT. The EXTENTSCOUNT attribute defines the number of times that SIRA_PRISE will attempt to double the storage capacity of the storage space. So an EXTENTSCOUNT value of 4 will allow a storage space to grow to 16 (2^4) times the original size. A zero value will prohibit the storage space from "growing". Also note that SIRA_PRISE will always "top off" the requested extents count such that the total number of pages in an "extended" storage space will never exceed the value of 2^31 (2147483648). This means that for a storage space of, say, 1000 pages, the actual number of extent attempts will never exceed 21, even if the EXTENTSCOUNT attribute value for this storage space shows a higher value (1000 * 2^21 = 2097152000, which cannot be doubled anymore without exceeding 2^31). Please observe, however, that this feature is only intended as an "escape route" for sudden unexpected changes in volumes, and not as a replacement for careful capacity planning. Effectively allowing a storage space to grow to thousands of times its original size can reasonably be expected to be "rewarded" with significant performance degradation.

See Also:

Constant Field Values

STORAGESPACEEXTENTS

static final java.lang.String STORAGESPACEEXTENTS

Deprecated.

See Also:

Constant Field Values

SYSTEMDEFINEDCLIENT

static final java.lang.String SYSTEMDEFINEDCLIENT

This relvar lists the system-provided clients that can successfully connect to the server.

See Also:

Constant Field Values

SYSTEMDEFINEDCONSTRAINT

static final java.lang.String SYSTEMDEFINEDCONSTRAINT

This relvar lists the system-defined constraints. This relvar is used to prevent the user from modifying these constraints, and is itself non-updatable.

See Also:

Constant Field Values

SYSTEMDEFINEDDBMSFILE

static final java.lang.String SYSTEMDEFINEDDBMSFILE

See Also:

Constant Field Values

SYSTEMDEFINEDRELVAR

static final java.lang.String SYSTEMDEFINEDRELVAR

This relvar lists the system-defined relvars. This relvar is used to prevent the user from modifying these relvars, and is itself non-updatable.

See Also:

Constant Field Values

SYSTEMDEFINEDTYPE

static final java.lang.String SYSTEMDEFINEDTYPE

The SystemDefinedType relvar lists which types are system-defined, preventing their deletion from the catalog.

See Also:

Constant Field Values

SYSTEMDEFINEDUSER

static final java.lang.String SYSTEMDEFINEDUSER

This relvar lists system-provided users that can succesfully start a transaction.

See Also:

Constant Field Values

TABLE_DEE

static final java.lang.String TABLE_DEE

TABLE_DEE is a system-defined virtual relvar, defined as the relation literal RELATION(HEADING()BODY(TUPLE())).

See Also:

Constant Field Values

TABLE_DUM

static final java.lang.String TABLE_DUM

TABLE_DUM is a system-defined virtual relvar, defined as the relation literal RELATION(HEADING()BODY()).

See Also:

Constant Field Values

TRANSACTIONCONSTRAINT

static final java.lang.String TRANSACTIONCONSTRAINT

Deprecated. - Support for Transaction Constraints has been removed as of version 1.4.

See Also:

Constant Field Values

TREEINDEXSPACE

static final java.lang.String TREEINDEXSPACE

The TREEINDEXSPACE relvar lists all the storage spaces that are intended for storing tree indexes.
Heading : FILENAME(NAME) STORAGESPACEID(INT)
Predicate : StorageSpace <STORAGESPACEID> of File <FILENAME> is used for storing tree indexes.

TREEINDEXSPACE tuples mark the corresponding storagespace as being intended for recording tree indexes. Treeindexes will maintain some inorder sequence of the tuples (of the relvar whose tuple records are) indexed, according to the precise definition of the index (its list of index components) and the relevant comparison operators.

See Also:

Constant Field Values

TRIGGEREDDATAACTION

static final java.lang.String TRIGGEREDDATAACTION

The TRIGGEREDDATAACTION relvar lists all the triggered data actions defined to the system.
Heading : DATAACTIONNAME(NAME) RELVARNAME(NAME) OPERATIONTYPE(INT) TARGETRELVARNAME(NAME) TRIGGEREDOPERATIONTYPE(INT) ISDISTINCT(BOOLEAN) BYPASSASSGCONSTRAINTS(BOOLEAN) SP_EXPRESSION(STRING)
Key {DATAACTIONNAME} and {RELVARNAME OPERATIONTYPE TARGETRELVARNAME TRIGGEREDOPERATIONTYPE ISDISTINCT BYPASSASSGCONSTRAINTS}
Predicate : Update operations of type <OPERATIONTYPE> on relvar <RELVARNAME> trigger an update operation of type <TRIGGEREDOPERATIONTYPE> (distinct: <ISDISTINCT>, bypass assignment constraints: <BYPASSASSGCONSTRAINTS>) on relvar <TARGETRELVARNAME> using expression <SP_EXPRESSION>. The action is named <DATAACTIONNAME>.

TriggeredDataAction tuples define which triggered data actions SIRA_PRISE will undertake as a consequence of some assignment carried out to some relvar. The 'dataactionname' attribute assigns a name to the data trigger. The 'relvarname' and 'operationtype' attributes identify the relvar and the assignment type that will 'fire' the trigger. The values for the operationtype attribute are as for AssignmentConstraintChecks : 1 for DELETE/UNASSERT/UPDATE, and 2 for ADD/ASSERT/UPDATE.

The 'targetrelvarname'and 'triggeredoperationtype' attributes identify the target relvar for the trigger and the assignment type that will be carried out against the named target relvar. The values for the operationtype attribute are as for AssignmentConstraintChecks : 1 for DELETE/UNASSERT, and 2 for ADD/ASSERT. The value of the 'isdistinct' attribute determines whether the assignment carried out against the named target relvar is the 'distinct' (ADD/DELETE) version or the 'nondistinct' (ASSERT/UNASSERT) version of the assignment. It is not possible to trigger an UPDATE statement directly. This must be achieved through triggering both the appropriate insertion and deletion for the target relvar.

By setting the 'bypassassgconstraints' to true, it becomes possible to issue, from within a triggered data action, updates that would otherwise be prohibited as a consequence of some assignment constraint on that target relvar. This feature may make SIRA_PRISE's triggered data actions an appropriate means for storing derived, "redundant" data inside the dbms, and this under control of the dbms, so that the application doesn't need to worry about synchronizing the derived data with each update (and making it even impossible for the application to corrupt the derived data).

The 'sp_expression' attribute defines the expression to compute the relation value that will be inserted into/deleted from the target relvar. It must therefore denote a relational expression of the same relation type as the target relvar. Typically, this expression will contain invocations of INSERTS(relvarname) or DELETES(relvarname), or even both. Note however that this is by no means required.

Triggered data actions can be recursive, i.e. a trigger fired by an update to some relvar can have that same relvar as its target, and such recursion can also be caused "indirectly". There is a builtin limit on the number of rounds that SIRA_PRISE will run recursively when determining the triggered data actions to carry out. This limit should be high enough for all practical purposes, meaning that if you run into a "probable infinite recursion" error message, it is indeed very likely that you have set up the triggered data actions in such a way that without the limited number of rounds, they would indeed run forever. Please observe that while the recursion feature is supported and available, we strongly recommend that you try and avoid such designs in which they are necessary.

When dealing with recursive triggered data actions, one thing must be noted about the result returned for invocations of INSERTS(...) and DELETES(...). In the first recursive round, these operators return the insertions and deletions as they are implied by the assignment statement as issued by the user. In the second recursive round, invocations of these operators refer to the set of assignments that was the RESULT of the first recursive round. In the third recursive round, invocations of these operators refer to the set of assignments that was the RESULT of the second recursive round, etc. etc.

For all defined triggered data actions, the system maintains a record of which relvar references are included in its defining expressions.

See Also:

Constant Field Values

TUPLECONSTRAINT

static final java.lang.String TUPLECONSTRAINT

The TUPLECONSTRAINT relvar lists all the declared tuple constraints on the database's relvars.
Heading : RELVARNAME(NAME) SP_EXPRESSION(STRING) ERRORCODE(LONG)
Key {ERRORCODE}
Predicate : Relvar <RELVARNAME> is subject to tuple constraint <SP_EXPRESSION>. The error number generated when it is violated is <ERRORCODE>.

Constraints on the values of the tuples that can be added to a given relvar can be defined in this way. Errorcode is the unique number identifying the constraint within the entire SIRA_PRISE system.

Adding a new tuple constraint will be rejected if any of the tuples currently present in the concerned relvar, violate this new constraint. Note that this also applies to UPDATEs applied to tupleconstraints, since any UPDATE is always equivalent to a DELETE plus an INSERT.

The sp_expression attribute defines a boolean expression that must be true for a tuple to be allowable to the constrained relvar. The evaluation scope for this expression is strictly limited to the single tuple being added to the relvar, i.e. the only allowable variables in this expression are references to attributes of the tuple. E.g. GT(ERRORCODE,LONG(4999)) defines that the errorcode attribute in any tuple must have a value of 5000 or more. Note that a tuple constraint TCEXP on relvar R is therefore always equivalent to the databaseconstraint RESTRICT(R,NOT(TCEXP)).

Observe that tuple constraints are applied to the tuples as they will actually appear in the database after the assignment. Due to SIRA_PRISE's "autopacking" feature for relvars/tuples with interval-typed attributes, the tuple checked is thus not necessarily equal to the tuple presented for insertion by the user. Consecutive insertion of, say, interval-values BEGIN(1)END(7) and BEGIN(7)END(14) will cause the database to contain a single tuple BEGIN(1)END(14), and such a tuple would be found in violation of, say, a constraint specifying that "no tuple can be "longer than 7"", even if the individual tuples presented for insertion are themselves not in violation of such a constraint.

When deleting a tupleconstraint for which a CONSTRAINTMESSAGETEXT appears in the database, that constraintmessagetext must be deleted within the same MA, or the delete will fail.

See Also:

Constant Field Values

TUPLECONSTRAINTATTRIBUTE

static final java.lang.String TUPLECONSTRAINTATTRIBUTE

Deprecated.

See Also:

Constant Field Values

TUPLEINDEX

static final java.lang.String TUPLEINDEX

The TUPLEINDEX relvar lists all the Tuple Indexes defined in the system. Tuple Indexes are used for linking together the records of distinct record types that are defined for one and the same relvar.
Heading : INDEXNAME(NAME) RELVARNAME(NAME) RECORDTYPENAME(NAME)
Key {RELVARNAME, RECORDTYPENAME}
Predicate : The index <INDEXNAME> is a tuple index on the type <RECORDTYPENAME> records of relation variable <RELVARNAME>.

A TUPLEINDEX tuple will designate the named index to become a "tuple" index for all tuples of the named relvar. This index is required to be a hashing index (meaning the index must be stored in either a hashingindexspace or a multihashingindexspace). Since a tupleindex is, like the name says, an index much like any other, the corresponding index tuple must also be added within the same MA.

Tuple indexes are special in the sense that the component that is indexed is the internal tuple ID of any tuple. No other components are allowed to be part of a tuple index, and the index thus has no user-visible components.

Deleting TupleIndex tuples will end the designation of the named index as a tupleindex, but will not delete the index itself. The index itself continues to exist, but will be rebuilt to reflect its new structure having "no components at all" (a tupleindex does have a component, the internal tupleid, even if that component is never made visible to the user).

See Also:

Constant Field Values

TYPEDIRECTLYREFERENCEDBY

static final java.lang.String TYPEDIRECTLYREFERENCEDBY

See Also:

Constant Field Values

TYPEPROPERTIES

static final java.lang.String TYPEPROPERTIES

The TYPEPROPERTIES relvar lists some properties of each type defined to SIRA_PRISE. As with possreps, this information is obtained from the type's implementation class at the time the type is added to the catalog.

See Also:

Constant Field Values

UDTORDERINGOPERATOR

static final java.lang.String UDTORDERINGOPERATOR

The UDTORDERINGOPERATOR relvar records the details of an ordering operator defined for a user-defined type that is made available to the server.
Heading : TYPENAME(NAME) SP_EXPRESSION(STRING)
Key {TYPENAME}
Predicate : The user-defined type <TYPENAME> has an ordering operator which is defined by the expression '<SP_EXPRESSION>'.

Tuples in this relvar define the expression that determines the ordering of the values of a user-defined type.

If no tuple appears for a type in this relvar, then that user-defined type will be unordered, and no corresponding intervaltype will be automatically created by SIRA_PRISE. If a tuple does appear, then the user-defined type in question is an ordered one, and an intervaltype will automatically be available.

The sp_expression attribute must contain a valid expression whose only allowed variables are the two arguments of the implied GT() operator. In the expression, these must be denoted as PARAMETER(V1(...)) and PARAMETER(V2(...)) , respectively (with the ellipsis replaced by the typename of this type). References to the values of possrep components of any of these two arguments can be made via an invocation of the appropriate THE_ operator (e.g. THE_X(PARAMETER(V1(...)))).

Changing the ordering operator expression is considered as a change to the type and is subject to the condition that no attribute of this type, or of any type that depends on this type, can already exist in a recorded relvar (because that opens up the possibility that a treeindex was already built using the former definition of the ordering - which might be a different one than the ordering defined by the modified version of the ordering operator expression).

See Also:

Constant Field Values

UDTPHYSICALPOSSREPCOMPONENT

static final java.lang.String UDTPHYSICALPOSSREPCOMPONENT

The UDTPHYSICALPOSSREPCOMPONENT relvar records the details of the physical possrep for each user-defined type that is made available to the server.
Heading : TYPENAME(NAME) COMPONENTNAME(NAME) COMPONENTTYPENAME(NAME) LOGICALLENGTH(INT) ORDINAL(INT)
Key {TYPENAME COMPONENTNAME} and {TYPENAME ORDINAL}
Predicate : The physical possRep of type <TYPENAME> has a component of type <COMPONENTTYPENAME> named <COMPONENTNAME>, of logical length <LOGICALLENGTH>. The ordinal position in the physical representation of the values is <ORDINAL>.

Tuples in this relvar define the components that make up the physical possrep for a user-defined type. Thus, the bit pattern of the encoding for any value of the user-defined type is determined. That bit pattern consists of the bit patterns of the encodings of the respective physical possrep component values, all concatenated together in the order specified by the ORDINAL attribute.

The componenttypename attribute names the type of the component, which can be any type, including intervaltypes or constrained types. Components that are themselves of a user-defined type are not -yet- supported.

The logicallength attribute defines the maximum logical length for the values of the component, in the case when the component type is a variable-length one. In that case, the space reserved for the bit encoding of the value of this component will correspond to and be determined by this maximal length. If the component type is a fixed-length one, then the LOGICALLENGTH attribute value will be disregarded and can have any value.

Observe that it is possible for a user-defined type to have no physical possrep components at all ! In that case, the type is a singleton type (and the byte length of its physical encoding is zero).

Adding, deleting or modifying any physical possrep component of a user-defined type is considered as a change to this type and is subject to the condition there cannot yet be any attribute of this type, or of any type whose definition depends on this type, in a recorded relvar. A relvar is recorded if at least one RecordType tuple exists in the catalog for that relvar.

See Also:

Constant Field Values

UDTPOSSREP

static final java.lang.String UDTPOSSREP

The UDTPOSSREP relvar declares the existence of additional, non-physical possreps for some user-defined type.
Heading : TYPENAME(NAME) POSSREPNAME(NAME)
Predicate : <POSSREPNAME> is the name of a possible representation for values of user-defined type <TYPENAME>.

Tuples in this relvar define the non-physical possreps that exist for a user-defined type. Non-physical possreps give rise to the existence of additional value selector operators for the user-defined type (one for each non-physical possrep), and to additional THE_ operators for the user-defined type (one per component of the non-physical possrep).

The addition of a non-physical possrep must be accompanied by the addition of UDTPPCVALUESELECTOR tuples, to allow the system to determine the physical encodings for values of this type selected through a value selector deriving from a non-physical possrep.

See Also:

Constant Field Values

UDTPOSSREPCOMPONENT

static final java.lang.String UDTPOSSREPCOMPONENT

The UDTPOSSREPCOMPONENT relvar declares the components that make up an additional, non-physical possreps for some user-defined type.
Heading : TYPENAME(NAME) POSSREPNAME(NAME) COMPONENTNAME(NAME) SP_EXPRESSION(STRING)
Key {TYPENAME COMPONENTNAME}
Predicate : PossRep <POSSREPNAME> of user-defined type <TYPENAME> has a component named <COMPONENTNAME> whose value is computed by the expression <SP_EXPRESSION>.

Tuples in this relvar define the components that together constitute a non-physical possrep for a user-defined type. As is the case with java-implementation-backed types, component names must be unique for a type across all different possreps (including the physical possrep of this user-defined type).

The sp_expression attribute defines the formula for computing the value that should be the result of an invocation of the THE_ operator corresponding to this possrep component. The only allowable variables in this expression are the component names defined for the physical possrep of this type.

See Also:

Constant Field Values

UDTPPCVALUESELECTOR

static final java.lang.String UDTPPCVALUESELECTOR

The UDTPPCVALUESELECTOR relvar declares the formulae for computing the values for the physical possrep components, given a set of non-physical possrep component values.
Heading : TYPENAME(NAME) POSSREPNAME(NAME) COMPONENTNAME(NAME) SP_EXPRESSION(STRING)
Key {TYPENAME COMPONENTNAME POSSREPNAME}
Predicate : Component <COMPONENTNAME> of the physical possrep of user-defined type <TYPENAME> is computed by the expression <SP_EXPRESSION>, when computing from representations in possrep <POSSREPNAME>.

Tuples in this relvar define the formula for computing the value of a component of the physical possrep of a user-defined type, when a value selector of that type is invoked that corresponds to a non-physical possrep.

The typename attribute names the concerned user-defined type. The possrepname attribute names the non-physical possrep to which' value selector invocations this physical possrep component value selector corresponds. The componentname attribute names the component of the physical possrep component which' value will be computed using the given expression.

The sp_expression attribute defines the formula for computing the value that should be used as the physical possrep component value when determining the bit pattern encoding for the value that should be returned as a result of a value selector invocation corresponding to the non-physical possrep named in the tuple. It must be a valid expression whose only allowable variables are the names of the possrep components of the non-physical possrep for which this physical possrep component value selector is defined. The return type of the expression must obviously match the concerned physical possrep's component's type.

It is at all times required that for each non-physical possrep and for each physical possrep component of a type there exists a UDTPPCValueSelector tuple. Or in other words, the projection of this relvar on its key should at all times be equal to the join of the UDTPossrep and the UDTPhysicalPossrepComponent relvars.

See Also:

Constant Field Values

USER

static final java.lang.String USER

This relvar records the identifications of the users of the database managed by the engine.
Heading : USERID(NAME)
Predicate : <USERID> is a registered user of the system.

See Also:

Constant Field Values

USERCERTIFICATE

static final java.lang.String USERCERTIFICATE

This relvar records the certificates that can be used for authenticating the identity of a user who wishes to start a transaction.
Heading : USERID(NAME) ALGORITHM(NAME) CERTIFICATE(BITS)
Key {USERID ALGORITHM}
Predicate : User <USERID> can be authenticated using signing algorithm <ALGORITHM> and certfificate <CERTIFICATE>.

The ALGORITHM attribute names a signing algorithm this user might use to authenticate himself, and the CERTIFICATE attribute records the X.509 certificate, pertaining to this user, that is to be used when this user authenticates himself using the named algorithm.

See Also:

Constant Field Values

USERDEFINEDTYPE

static final java.lang.String USERDEFINEDTYPE

The UserDefinedType relvar records the names of the user-defined types that are made available to the server.
Heading : TYPENAME(NAME)POSSREPNAME(NAME)SP_EXPRESSION(STRING)
Key {TYPENAME}
Predicate : Type <TYPENAME> is a user-defined type. The possrep defining the encoding of values of this type is <POSSREPNAME>. The possrep constraint expression is <SP_EXPRESSION>.

The typename attribute obviously gives the type a name, which cannot be allowed to coincide with the name of any existing java-implemented or constrained type. As with java-backed types, type names ending with 'interval' are not permitted.

The possrepname attribute names the possrep that acts as the physical possrep for this type (i.e. the possrep whose components will determine the bit encoding of any values of this type. The "structure" (i.e. the components, their types, and their physical ordering) will have to be specified in the UDTPhysicalPossrepComponent relvar).

The SP_EXPRESSION attribute defines the possrep constraint expression. A "blank" possrep constraint expression (zero-length string or all-blanks) acts as if the literal BOOLEAN(TRUE) were specified. A non-blank expression, must :

• be a valid expression that returns a boolean,
• in which the only "variable references" are the names of the components of the physical possrep. Note therefore that setting this expression when adding the type, requires that all the physical possrep components are also declared within the same MA. An example of a valid possrep constraint expression would be 'GT(X,Y)' where X and Y are the possrep components denoting the X and Y coordinates of a value of type POINT. Another example of a valid possrep constraint expression would be 'BOOLEAN(FALSE)', allthough such expressions render the type pretty useless.

An ordering operator for this type can be defined by adding a tuple to the UDTORDERINGOPERATOR relvar.

Additional possreps "beyond" the physical possrep can be defined by adding tuples to the UDTPOSSREP, UDTPOSSREPCOMPONENT and UDTPPCVALUESELECTOR relvars.

See Also:

Constant Field Values

VIRTUALRELVAR

static final java.lang.String VIRTUALRELVAR

The VIRTUALRELVAR relvar inventorises the "virtual" relvars that constitute the database. Virtual relvars are read-only views on the base relvars. Their definition consists of their view-defining expression.
Heading : RELVARNAME(NAME) SP_EXPRESSION(STRING)
Key {RELVARNAME}
Predicate : <RELVARNAME> is the name of a virtual relvar that represents the current value of the expression <SP_EXPRESSION>

Virtual relvars can be used in exactly the same way as any "regular" relvar, except they can't be updated (meaning, virtual relvars can only be referenced in expressions, but cannot appear as the target in an assignment). References to virtual relvars evaluate to the value of their defining expression.

When a virtual relvar is defined, SIRA_PRISE also records which other relvars are referenced by the expression defining the virtual relvar (i.e. the dependencies on the definitions of other relvars), and which value selector expressions are used in the expression (i.e. the virtual relvars' dependencies on types).

The expression defining a virtual relvar can reference other virtual relvars. It is, however, not possible to define or modify a virtual relvar in such a way that any virtual relvar would directly or implicitly reference itself. Whenever any change is made to the definition of any relvar (whether base or virtual), all the virtual relvars that reference this modified relvar either directly or implicitly, are marked "invalid". Virtual relvars that have been marked "invalid" will be recompiled the first moment they are referenced. This means in particular that if some change to some relvar R renders the expression defining some other virtual relvar V invalid, then this will not be taken as a reason to reject the change to R. The problem will only be noticed the first time a user requests to evaluate some reference to V.

See Also:

Constant Field Values

VIRTUALRELVARDEPENDSONTYPE

static final java.lang.String VIRTUALRELVARDEPENDSONTYPE

See Also:

Constant Field Values

VIRTUALRELVARREFERENCES

static final java.lang.String VIRTUALRELVARREFERENCES

This relvar lists the direct references to other relvars made by the expression defining a virtual relvar. For finding all references, including the implicit ones, apply the TCLOSE operator to this relvar. Heading : RELVARNAME(NAME) REFERENCEDRELVARNAME(NAME)

The referencedrelvarname attribute can identify a base relvar as well as a virtual one.

See Also:

Constant Field Values

VIRTUALRELVARDEPENDENCYGRAPH

static final java.lang.String VIRTUALRELVARDEPENDENCYGRAPH

See Also:

Constant Field Values