The Object Model

The EYEDB object model is inspired by the SmallTalk, LOOPS, ObjVlisp, Java and ODMG models.

The main three class abstractions are the class object which is the root class, the class class and the class instance as shown in Figure 2.

Generally speaking, the instantiation of a class X gives an instance of the class X.

Figure 2: Partial Native Object Model

An instance cannot be instantiated except the instances of the class class or its subclasses: the instantiation of an instance of the class class is an instance of the class instance (i.e. an instance of the class instance).

If new() denotes the instantiation method:

struct_class Person =
struct_class->new(name = "Person", ...)

Person is an instance of the class struct_class that can be instantiated:

struct john =
Person->new(name = "john", age = 32)

john is an instance of the class struct that cannot be instantiated

struct_class Employee =
struct_class->new(name = "Employee",
parent = Person, ...)

struct henry =
Employee->new(name = "henry",
salary = 10000)

Figure 3 shows this instantiation mechanisms.

Note that as the class class derives from the class object, an instance of the class class can be manipulated like any instance of the class object.

The native EYEDB object model is composed of 76 classes such as the class collection, the class method, the class constraint, the class index, the class image and so on.
EYEDB object model supports all standard built-in types: 16-bit, 32-bit and 64-bit integer, character, string, 64-bit float.

An instance can be transient or persistent:

• an instance is transient if its lifetime does not exceed the lifetime of the unit of execution in which it is manipulated.
• otherwise the instance is persistent.

A persistent instance can be object or literal:

• an object persistent instance has an unique identifier (i.e. an oid)
• a literal persistent instance has no identifier.

Figure 3: Applicative Object Model Example

Class Structure

A class is composed of a name, a parent class (except for the class object which is the root class), a set of attributes, a set of methods and a set of triggers:

• an attribute is composed of a type, an optionnal array modifier and is literal or object. For instance, using the EYEDB ODL language:

     attribute int32 age
  

  is a literal attribute of type int32 with no array modifier, while the following attribute:

     attribute Person *children[10]
  

  is a fixed-size array of object of type Person.

• a method is a unit of execution tied to a class.
  A method can be either a class method or an instance method.
• a trigger is a unit of execution tied to a class. Triggers are applied to instances of this class on a given event.
  For example, a trigger update_before tied to the class X means that before the update of any instance of the class X, the trigger will be called.
  A method or a trigger can be overloaded by the sub-classes.
  
  EYEDB supports the following trigger events: create_before, create_after, update_before, update_after, load_before, load_after, remove_before, remove_after.

Type Polymorphism

The two language bindings, C++ and Java, and EYEDB OQL supports type polymorphism: variables may be bound by instances of different types.
This is a direct consequence owing to the fact that any EYEDB class inherits from the class object,

The possibility of manipulating polymorphic objects is a major contribution of object orientation.

The Collection Type

A collection is composed of elements of the same type.
The elements can be either literal or object.

If the collection element type is the class object, then the collection can contain instances of any class, as all classes inherit from the class object.

The collection types supported by EYEDB are the set, the bag and the array:

• an instance of the class set is an unordered collection with no duplicates allowed,
• an instance of the class bag is an unordered collection that may contain duplicates,
• an instance of the class array instance is dynamically sized ordered collection.

The collection type is a major concept of the EYEDB object model.

Relationships

The EYEDB object model supports only binary relationships, i.e. relationships between two types.
A binary relationship may be one-to-one, one-to-many or many-to-many depending on the cardinality of the related types. Relationships are not named.

EYEDB maintains the referential integrity of relationships. This means that if an object that participates in a relationship is removed, then any traversal path to that object is also removed.
EYEDB supports object-valued attribute: this kind of attribute enables one object to reference another without expectation of referencial integrity. An object-valued attribute implements a unidirectionnal relationship: in this case, EYEDB does not guarantee the referential integrity. Note that such a unidirectionnal relationship is not called a relationship.

The example introduced in the section The Object Definition Language illustrates the use of relationships and object-valued attributes.

Constraints

EYEDB supports all standard constraints:

• the not null constraint on a attribute within a class X means that no instances of the class X can have this attribute value not assigned.
• the unique constraint on a attribute within a class X means that one cannot create an instance of the class X which has the same

  attribute value than an existing instance in the database.

• the cardinality constraint on an instance of the class collection means that the count of this collection must follow this cardinality constraint.