public static interface NAMES.RELVARNAMES
| Modifier and Type | Field and Description |
|---|---|
static 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>'. |
static 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>. |
static 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>. |
static NameIdentifier |
ATTRIBUTE_I |
static java.lang.String |
ATTRIBUTELENGTHCONSTRAINT
The ATTRIBUTELENGTHCONSTRAINT defines the "maximal allowed length" for the corresponding attribute.
Heading : MAXIMUMLENGTH(INT) ATTRIBUTENAME(NAME) Key {ATTRIBUTENAME} Predicate : Values for attribute <ATTRIBUTENAME> are allowed a maximal length of <MAXIMUMLENGTH> . |
static NameIdentifier |
ATTRIBUTELENGTHCONSTRAINT_I |
static java.lang.String |
ATTRIBUTEPHYSICALLENGTH
Deprecated.
- physical structure is handled in a completely different way as of version 1.5. The ATTRIBUTEPHYSICALLENGTH relvar is no longer relevant.
|
static 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>. |
static 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. |
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.
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>. |
static java.lang.String |
CLUSTEREDRECORDSPACE
The CLUSTEREDRECORDSPACE relvar lists all the storage spaces that are intended for storing data records using ordering-based physical location, without the usage of an additional, separate, tree index space.
Heading : FILENAME(NAME) STORAGESPACEID(INT) Key {FILENAME STORAGESPACEID} Predicate : "StorageSpace <STORAGESPACEID> of Dbms File <FILENAME> is used for storing data records using ordering-based physical location." |
static java.lang.String |
CLUSTEREDRECORDSPACELOCATTRS
The CLUSTEREDRECORDSPACELOCATTRS relvar lists the attribute names that determine the ordering in each
CLUSTEREDRECORDSPACE.Heading : FILENAME(NAME) STORAGESPACEID(INT) ORDINAL(INT) ATTRIBUTENAME(NAME) Key {FILENAME STORAGESPACEID ORDINAL} {FILENAME STORAGESPACEID ATTRIBUTENAME} Predicate : "Attribute <ATTRIBUTANAME> is component <ORDINAL> in the ordering key for Clustered Record Space <STORAGESPACEID> of Dbms File <FILENAME> ." |
static 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>. |
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.
Heading : CONSTRAINTMESSAGETEXT(STRING) ERRORCODE(LONG) Key {ERRORCODE} Predicate : The text to be displayed upon violations of the constraint with error code <ERRORCODE> is '<CONSTRAINTMESSAGETEXT>'. |
static java.lang.String |
CURRENTCONTEXT
Deprecated.
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.
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 NameIdentifier |
DATAACTIONREFERENCES_I |
static 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>'. |
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.
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>. |
static java.lang.String |
DATASPACE
Deprecated.
- has been superseded by the new recordspace types (
HASHEDRECORDSPACE or CLUSTEREDRECORDSPACE) |
static 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>. |
static java.lang.String |
GENERATEDOPERATOR
The GENERATEDOPERATOR relvar lists all the automatically generated operators that are available in the types&operators subsystem.
Heading : OPERATORINVOCATIONNAME(NAME) OPERANDSIGNATURE(RELATION ... |
static NameIdentifier |
GENERATEDOPERATOR_I |
static java.lang.String |
HASHEDRECORDSPACE
The HASHEDRECORDSPACE relvar lists all the storage spaces that are intended for storing data records using hash-based physical location, without the usage of an additional, separate, index space.
Heading : FILENAME(NAME) STORAGESPACEID(INT) GAPCOMPRESSIONTHRESHOLD(INT) MAXIMUMGAPS(INT) Key {FILENAME STORAGESPACEID} Predicate : "StorageSpace <STORAGESPACEID> of Dbms File <FILENAME> is used for storing data records using hash-based physical location. |
static java.lang.String |
HASHEDRECORDSPACEHASHMOD
The HASHEDRECORDSPACEHASHMOD relvar lists, for each
HashedRecordSpace, the hash modulo number. |
static java.lang.String |
HASHINGINDEXSPACE
Deprecated.
- indexing facilities have been superseded by the new types of recordspace
|
static java.lang.String |
INDEX
Deprecated.
- indexes have been superseded by the new record types, which are the equivalent of "covered indexes", i.e. index plus data record in one
|
static java.lang.String |
INDEXATTRIBUTE
The INDEXATTRIBUTE relvar lists the components that make up the indexer for a record type.
|
static java.lang.String |
INDEXCOMPONENT
Deprecated.
- Index components other than simple attribute references are no longer supported (they've never been very useful anyway)
|
static java.lang.String |
INDEXID
Deprecated.
- indexes and index ids have been superseded by hashedrecordtypes and clusteredrecordtypes, which are sort of "data record plus index in one".
|
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 NameIdentifier |
INTERVALTYPE_I |
static 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. |
static NameIdentifier |
JAVABACKEDTYPE_I |
static 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>. |
static 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>. |
static java.lang.String |
LUWDATETIME |
static java.lang.String |
MULTIHASHINGINDEXSPACE
Deprecated.
- the functionality has been superseded by the HashedRecordSpace relvar.
|
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.
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>. |
static java.lang.String |
NONSCALARATTRIBUTEATTRIBUTES
This relvar lists the attributes that are part of the heading of some other -nonscalar- attribute.
|
static NameIdentifier |
NONSCALARATTRIBUTEATTRIBUTES_I |
static java.lang.String |
OPERATOR
The OPERATOR relvar lists all the operators that are available in the types&operators subsystem.
Heading : OPERATORINVOCATIONNAME(NAME) OPERANDSIGNATURE(RELATION ... |
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 NameIdentifier |
POSSREP_I |
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 NameIdentifier |
POSSREPCOMPONENT_I |
static 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>. |
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.
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>. |
static NameIdentifier |
RECORDTYPE_I |
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.
Heading : RELVARNAME(NAME) RELVARPREDICATE(STRING) Key {RELVARNAME} Predicate : <RELVARNAME> is a relation variable whose predicate is '<RELVARPREDICATE>'. |
static 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>. |
static NameIdentifier |
RELVARATTRIBUTE_I |
static 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>. |
static NameIdentifier |
RELVARCARDINALITY_I |
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.
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. |
static java.lang.String |
STORAGESPACEEXTENTS
Deprecated.
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 NameIdentifier |
SYSTEMDEFINEDTYPE_I |
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
Deprecated.
- superseded by the new clusteredrecordspace facility, which combines the functionality of DATASPACE plus TREEINDEXes in one.
|
static 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>. |
static NameIdentifier |
TRIGGEREDDATAACTION_I |
static 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>. |
static java.lang.String |
TUPLECONSTRAINTATTRIBUTE
Deprecated.
deprecated
|
static java.lang.String |
TUPLEINDEX
Deprecated.
- indexes and everything related have been superseded by the new record types
|
static java.lang.String |
TYPEDIRECTLYREFERENCEDBY |
static java.lang.String |
TYPEPROPERTIES
Deprecated.
- the relvar is no longer in the catalog as of version 1.5
|
static java.lang.String |
TYPESPACECALCHINT
The TYPESPACECALCHINT relvar holds descriptive hints about physical encoding sizes needed by types, which are used in the SPACECALC facility
Heading : TYPENAME(NAME) TYPESIZEHINT(STRING) Key {TYPENAME} |
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.
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>'. |
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.
Heading : TYPENAME(NAME) COMPONENTNAME(NAME) COMPONENTTYPENAME(NAME) MAXIMUMLENGTH(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 <MAXIMUMLENGTH>. |
static 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>. |
static 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>. |
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.
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>. |
static 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. |
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.
Heading : USERID(NAME) ALGORITHM(NAME) CERTIFICATE(BITS) Key {USERID ALGORITHM} Predicate : User <USERID> can be authenticated using signing algorithm <ALGORITHM> and certfificate <CERTIFICATE>. |
static 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. |
static java.lang.String |
VIRTUALRELVAR
The VIRTUALRELVAR relvar inventorises the "virtual" relvars that constitute the database.
|
static NameIdentifier |
VIRTUALRELVAR_I |
static java.lang.String |
VIRTUALRELVARDEPENDENCYGRAPH |
static NameIdentifier |
VIRTUALRELVARDEPENDENCYGRAPH_I |
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.
|
static NameIdentifier |
VIRTUALRELVARREFERENCES_I |
static final java.lang.String ASSIGNMENTCONSTRAINT
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.
static final java.lang.String ASSIGNMENTCONSTRAINTCHECK
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.
static final java.lang.String ATTRIBUTE
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.
static final NameIdentifier ATTRIBUTE_I
static final java.lang.String ATTRIBUTELENGTHCONSTRAINT
The "length" refers to the result obtained by invoking the LENGTH() operator of the attribute's type, e.g., the number of tokens in a STRING value, or the number of point values in an INT interval. Thus the exact meaning of the notion of "logical length" depends on the particular type of the attribute (the semantics of the LENGTH() operator for the type).
static final NameIdentifier ATTRIBUTELENGTHCONSTRAINT_I
@Deprecated static final java.lang.String ATTRIBUTEPHYSICALLENGTH
static final java.lang.String ATTRIBUTEVALUEDISTRIBUTION
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.
static final java.lang.String CLIENT
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.
static final java.lang.String CLIENTCERTIFICATE
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.
static final java.lang.String CLUSTEREDRECORDSPACE
As with DataSpaces , this will mark the corresponding storagespace as being intended for storing data records. The difference with a DataSpace is that a separate, distinct index space is not needed.
static final java.lang.String CLUSTEREDRECORDSPACELOCATTRS
CLUSTEREDRECORDSPACE.static final java.lang.String CONSTRAINEDTYPE
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).
static final java.lang.String CONSTRAINTINVOLVESRELVAR
static final java.lang.String 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 :
@Deprecated static final java.lang.String CURRENTCONTEXT
static final java.lang.String CURRENTDATE
@Deprecated static final java.lang.String CURRENTUPDATE
static final java.lang.String CURRENTUSER
static final java.lang.String DATAACTIONREFERENCES
static final NameIdentifier DATAACTIONREFERENCES_I
static final java.lang.String DATABASECONSTRAINT
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.
static final java.lang.String DATABASECONSTRAINTCHECK
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.
@Deprecated static final java.lang.String DATASPACE
HASHEDRECORDSPACE or CLUSTEREDRECORDSPACE)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.
static final java.lang.String DBMSFILE
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.
static final java.lang.String GENERATEDOPERATOR
static final NameIdentifier GENERATEDOPERATOR_I
static final java.lang.String HASHEDRECORDSPACE
As with DataSpaces , this will mark the corresponding storagespace as being intended for storing data records. The difference with a DataSpace is that a separate, distinct index space is not needed.
Updating HashedRecordSpace tuples to finetune the gap handling is not -yet- supported.
static final java.lang.String HASHEDRECORDSPACEHASHMOD
HashedRecordSpace, the hash modulo number. The relvar is not user-updatable.@Deprecated static final java.lang.String HASHINGINDEXSPACE
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).
@Deprecated static final java.lang.String INDEX
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.
static final java.lang.String INDEXATTRIBUTE
Indexattribute tuples define the structure of an indexer. The 'relvarname' and 'recordtypename' attributes identify the record type, the 'ordinal' attribute identifies the position of the indexer component relative to the others, and the 'attributename' attribute defines the attribute that will be indexed for some tuple of the indexed relvar.
Any addition, deletion or update of an indexattribute to the indexer for an existing record type will entirely rebuild the record type's records.
@Deprecated static final java.lang.String INDEXCOMPONENT
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.
@Deprecated static final java.lang.String INDEXID
static final java.lang.String INTERVALTYPE
static final NameIdentifier INTERVALTYPE_I
static final java.lang.String JAVABACKEDTYPE
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.
static final NameIdentifier JAVABACKEDTYPE_I
static final java.lang.String KEY
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.
static final java.lang.String KEYATTRIBUTE
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.
static final java.lang.String LUWDATETIME
@Deprecated static final java.lang.String MULTIHASHINGINDEXSPACE
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.
static final java.lang.String NEWATTRIBUTEDEFAULTVALUE
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).
static final java.lang.String NONSCALARATTRIBUTEATTRIBUTES
If the type of an attribute is a nonscalar one (TUPLE or RELATION), then the contents of this relvar define the nonscalar type (heading) for that attribute. Each ATTRIBUTENAMEINHEADING value corresponding to the ATTRIBUTENAME defines an attribute that is part of the heading. The ATTRIBUTENAMEINHEADING value references another defined attribute, from which the type declaration can be inferred.
If an attribute is nonscalar but no tuples appear for that attribute in this catalog relvar, then the heading of that nonscalar attribute is of degree zero.
static final NameIdentifier NONSCALARATTRIBUTEATTRIBUTES_I
static final java.lang.String OPERATOR
static final java.lang.String POSSREP
static final NameIdentifier POSSREP_I
static final java.lang.String POSSREPCOMPONENT
static final NameIdentifier POSSREPCOMPONENT_I
static final java.lang.String RECORDATTRIBUTE
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.
static final java.lang.String RECORDTYPE
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.
static final java.lang.String RECORDTYPEID
static final java.lang.String RELVAR
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.
static final java.lang.String RELVARATTRIBUTE
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.
static final NameIdentifier RELVARATTRIBUTE_I
static final java.lang.String RELVARCARDINALITY
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.
static final java.lang.String RELVARCLUSTER
static final java.lang.String RELVARID
static final java.lang.String STORAGESPACE
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 some recordspace tuple (hashedrecordspace, clusteredrecordspace) 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.
@Deprecated static final java.lang.String STORAGESPACEEXTENTS
static final java.lang.String SYSTEMDEFINEDCLIENT
static final java.lang.String SYSTEMDEFINEDCONSTRAINT
static final java.lang.String SYSTEMDEFINEDDBMSFILE
static final java.lang.String SYSTEMDEFINEDRELVAR
static final java.lang.String SYSTEMDEFINEDTYPE
static final NameIdentifier SYSTEMDEFINEDTYPE_I
static final java.lang.String SYSTEMDEFINEDUSER
static final java.lang.String TABLE_DEE
static final java.lang.String TABLE_DUM
@Deprecated static final java.lang.String TRANSACTIONCONSTRAINT
@Deprecated static final java.lang.String TREEINDEXSPACE
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.
static final java.lang.String TRIGGEREDDATAACTION
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.
static final NameIdentifier TRIGGEREDDATAACTION_I
static final java.lang.String TUPLECONSTRAINT
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.
@Deprecated static final java.lang.String TUPLECONSTRAINTATTRIBUTE
@Deprecated static final java.lang.String TUPLEINDEX
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).
static final java.lang.String TYPEDIRECTLYREFERENCEDBY
@Deprecated static final java.lang.String TYPEPROPERTIES
static final java.lang.String TYPESPACECALCHINT
static final java.lang.String UDTORDERINGOPERATOR
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).
static final java.lang.String UDTPHYSICALPOSSREPCOMPONENT
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 MAXIMUMLENGTH 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.
static final java.lang.String UDTPOSSREP
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.
static final java.lang.String UDTPOSSREPCOMPONENT
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.
static final java.lang.String UDTPPCVALUESELECTOR
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.
static final java.lang.String USER
static final java.lang.String USERCERTIFICATE
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.
static final java.lang.String USERDEFINEDTYPE
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 :
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.
static final java.lang.String VIRTUALRELVAR
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.
static final java.lang.String VIRTUALRELVARDEPENDENCYGRAPH
static final java.lang.String VIRTUALRELVARDEPENDSONTYPE
static final java.lang.String VIRTUALRELVARREFERENCES
The referencedrelvarname attribute can identify a base relvar as well as a virtual one.
static final NameIdentifier VIRTUALRELVAR_I
static final NameIdentifier VIRTUALRELVARREFERENCES_I
static final NameIdentifier VIRTUALRELVARDEPENDENCYGRAPH_I
static final NameIdentifier RECORDTYPE_I
static final NameIdentifier RELVARCARDINALITY_I