Objectivity/DB Object Database Terminology
Objectivity/DB Object Database Terminology: Since Objectivity/DB is an object-oriented data management system, we will introduce a few new terms to those familiar with other data management systems. These are:
| Federation | An Objectivity/DB federation can be thought of in the same way other data management systems use “database”. Objectivity/DB ’s federation is a collection of one or more Objectivity/DB databases. | ||||||||
| Object | An Objectivity/DB object is similar to the data portion of an
object as used by programming languages. Each object
is an instance of a defined class and consists of member
variables and relationships, as defined in an Objectivity/DB
schema. Objectivity/DB is not an “active” data management system in that it does not store the member functions. Functions are upplied by code written in one of our language bindings (e. g. C+, Java, Smalltalk). The objects can also be modified using an Objectivity/DB programming interface called Active Schema. An Objectivity/DB object is also similar to a “record” in other data management systems and object members can be thought of as the record’s columns. On the other hand, an object is more flexible than the traditional concept of a record. For example, an object can have embedded members of other classes and variablelength arrays. |
||||||||
| OID | An OID is an object identifier. Each object has a unique
64-bit OID made up of four 16-bit fields. These four fields
represent the object’s database, container, page and slot,
which are described below. The OID of an object is assigned when the object is first persisted and remains the same for the life of the object, even if the object is modified. This allows objects to contain references to other objects by using these OIDs. Like pointers or references in object-oriented languages (and unlike people), both the referring object and the referenced object can change without affecting the relation ship between them. For example, a Message object can be associated with a Person object. Either object can be renamed or otherwise modified without changing the OID(s) or pointers between them. |
||||||||
| Page | An Objectivity/DB page is a group of objects stored physi
cally together on disk. A page is the unit of transfer from
the federation to the application. The page size is definable
by the creator of the federation and is usually matched to
the page size of the operating system. The objects on a page can be of different types. For example, a Person object can have its Message objects grouped on the same page. Consequently, fetching a Person object can also fetch their associated Messages with a single disk read. The page of an object’s OID refers to which page in a given container the object is located. The slot of an object’s OID refers to where in the page the object is stored. Both the page and slot values are “logical”, not “physical”. There is a slot map on each page that allows Objectivity/DB to move an object on a page without changing the object’s OID. |
||||||||
| Container | A container is a group of pages of objects. It is very analo
gous to directories in a file system. An application developer
can place an object in a particular container when the object
is first persisted in the same way a user can put a file in
a particular folder or subdirectory when the file is first saved. An Objectivity/DB container can contain a single object or many thousands. These objects can be of mixed types and sizes. Each container stores a page map that allows Objectivity/DB to move pages within a container without changing any object’s OID. |
||||||||
| Database | An Objectivity/DB database is a group of containers. Each
database is also a separate file. A special database file
called the “system database” contains the catalog of
database IDs with their file locations. Consequently, database files can be moved and copied through Objectivity/DB commands with similar speeds as basic move and copy operating system commands without changing or otherwise affecting object OIDs. |
||||||||
| Persistent-capable | A class is defined as persistent capable if it has Objectivity/DB methods that allow it to be written to the federation. This usually means that the class was derived from Objectivity/DB ’s ooObj class. | ||||||||
| Persistent | An object that is stored in the federation is considered persistent. | ||||||||
| Transient | An object that is in an application’s memory, but not stored in the federation is considered transient. | ||||||||
| Reference | Objects in Objectivity/DB can have references to other
objects. These references are stored in an object simply
using the OIDs of the other objects. A reference or array of references can be defined in the schema of a class, just as one would declare a pointer in a transient class. A reference or array of references can then be populated with values, just as pointers in transient classes can be assigned values. |
||||||||
| Relationships | Also known as associations, these are Objectivity/DB
structures of references that have special meaning to the
Objectivity/DB kernel. Relationships can have different cardinalities (one-to-one, one-tomany, many-to-one or many-to-many). Relationships can have properties that Objectivity/DB will maintain, such as bi-directionality, delete propagation and others. |
||||||||
| ACID Properties | The ACID properties of transactions are not specific to
Objectivity/DB ; they are expectations described in ISO/IEC
10026-1:1992 Section 4 for the behavior that all transac
tions should provide.
|