Object attributes values are stored in individual database columns or in sets of database rows. Attributes that have a scalar value like string, integer, dates, etc., are stored in a single column. Attributes that have values comprising a list of entries, such as multi-reference or access permissions, are stored in sets of database rows – one row for each entry in the list.
The database tables containing the individual columns are called ‘main tables’, while the tables containing row sets are called ‘auxiliary tables’.
The name of the main tables are: the name of the object type where the attribute is first defined, with its first character converted to uppercase and all other characters converted to lowercase, prefixed by ‘s_’ and followed by ‘Table’. For example, ‘s_TestTable’ is the name of the table containing the scalar values of the attributes declared in the object type ‘test’. (Note that some database engines do not respect the case of the table and column names – notably Oracle converts them to all uppercase, so for Oracle the name of the table would be ‘S_TESTTABLE’). The names of main table columns are the name of the corresponding attribute prefixed by 's_'.
The names of the auxiliary tables are obtained by concatenating the name of the object type with the name of the attribute itself, prepending the same ‘s_’ prefix and adding different suffixes depending on the attribute type (‘XRef’, ‘List’ etc.). The structure of these tables depends on the type of the corresponding attribute – see the description of the individual attribute types for details.
In addition to the attributes’ columns, each main table has an ‘identifier’ column containing the unique numeric id of the object each row refers to. For example, the object type ‘test’ has an attribute ‘location’ and it descends from the root object type ‘object’ that has the attributes ‘id’ and ‘name’. The schema definition is:
<xs:complexType name="object">
<xs:attribute name="id" type="xs:ID" />
<xs:attribute name="name" type="tName" />
</xs:complexType>
<xs:element name="test">
<xs:complexType>
<xs:complexContent>
<xs:extension base="object">
<xs:attribute name="location" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
The database tables are:
create table s_ObjectTable (
. . .
s_id int ,
s_name nvarchar(80)
)
create table s_TestTable (
. . .
s_id int ,
s_location nvarchar(255)
)
Each object is stored in one row for each of the main tables containing its attributes.
A ‘test’ object will be stored as one row in s_ObjectTable – containing id and name, and one row in s_TestTable – repeating the same id and containing the location.
Note that if an object type has no scalar attribute of its own, there will be no corresponding main table, i.e., if the object type ‘test’ above had an access attribute instead of a string:
<xs:element name="test">
<xs:complexType>
<xs:complexContent>
<xs:extension base="object">
<xs:sequence>
<xs:element name="access" type="access" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
The database would NOT contain ‘s_TestTable’.
NOTES:
•The ‘s_id’ column is handled differently than all other attributes. It is defined as an identity column in s_ObjectTable, i.e., it automatically gets a new value when a row in inserted, and it is replicated – defined as a simple integer – in all the other main tables.
•Note that the name 'id' is defined in the schema, so it can be changed to anything else (as the name ‘ObjectTable’) – although it is recommended not to change it.
•The main table containing the root object type attributes, (usually called ‘object’ and so the name of the table is ‘s_ObjectTable’) contains some additional pre-defined columns: gn_ObjectTypeId and gn_MD5Key.
•gn_ObjectTypeId contains the unique database id of the type of each object. Object types and their id are stored in the system table gn_ObjectTypeTable.
•gn_MD5Key contains an MD5 hash of the key attributes of each object, and it is used to enforce object’s key uniqueness and to quickly find objects from the values of their key.