persistent class Customer
{
    //...
}

persistent class Order
{
    //...
}

persistent association CustomerOrders
{
    role Customer.Orserds;
    role Order.ParentCustomer;
}

Customer c = getCustomer(...);
int ordcnt = c.Orserds.Count;

Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов.

public interface ICustomerOrder
{
  ICustomer Customer { get;}
}

public interface ICustomer
{
  IEnumerable<IOrder> Orders();
}

public CustomerOrder: ICustomerOrder
{
  public ICustomer Customer { 
        get
        {
            return Engine.Select("ICustomer customer where customer.Orders.Contains(this)")[0];
        }
    }
}

public Customer: ICustomer
{
  public IEnumerable<IOrder> Orders()
    {
        return Engine.Select("IOrder order where Customer = this");
    }
}

IVehicleOwner:
{
  IEnumerable<Vehicle> Vehicles();
}

public ClassPersonToVehicleLink
{
  public IPerson Person {get; set;}
    public IVehicle Vehicle {get; set;}
}

select * from IPerson p where p.Age>27;

create view IPerson as
select ID, Age from Person1
union 
select ID, DateDiff(Year, GetDate(), Birthdate) from Person2

select * from Events e where e.Accepts(@me) and e.Begins between GetDate() and Tomorrow();

create procedure GetAcceptableEvents (@me Person)
as
  select ID from MovieSessions ms 
    inner join Movie m on ms.Movie = m.ID
      inner join MovieCategory с on m.Category = c.ID
      where c.MinAge<=@me.Age
            and ms.StartTime between GetDate() and Tomorrow()
union 
  select ID from PeepShow ps where @me.Gender = MALE and @me.Age>=21
            aand ps.StartTime between GetDate() and Tomorrow()
union
  ...

select * from Events e where e.Accepts(@me)

Связи не имеют имени. Вместо этого именуются навигационные пути (traversal paths) для каждого направления навигации, например профессор преподает (teaches) совокупность разделов курсов, инверсное направление определяется тем, что разделы курсов преподаются (is_taught_by) профессорами. Эти имена объявляются в определениях интерфейсов, соответствующих типам, участвующим в связи:

interface Professor { ...
teaches: Set<Section> inverse Section::is_taught_by
}

и

interface Section { ... is_taught_by: Professor inverse Professor::teaches
}

Для типа связи 1-n определены следующие операции:
— create(o1:Denotable_Object, s:Set<Denotable_Object>);
— delete ();
— add_one_to_one (o1:Denotable_Object, o2:Denotable_Object);
— remove_one_to_one (o1:Denotable_Object, o2:Denotable_Object);
— traverse (from:Denotable_Object) -> s: Set<Denotable_Object>.

interface Professor { teaches: Set< dual_ref< Section::is_taught_by > > };
interface Section { is_taught_by: dual_ref< Professor::teaches > };

Сейчас подумалось, что ООСУБД по выражению dual_ref< Professor::teaches > трудно будет понять, что в контейнере Set находятся ссылки. Ведь если нет специального типа "множество ссылок", а есть только контейнеры, то могут быть контейнеры контейнеров и др. И как во всем этом нужные ссылки искать? М-да...

#include <cxxcls/pobject.h>
#include <cxxcls/bilink.h>

class B; // mandatory forward declaration
class A: public PObject {
public:
   BiLink<B> toB; // attribute must be public
   BiLinkVstr<B> B_Vstr; // attribute must be public
   ...
};

class B: public PObject {
public:
   BiLink<A> toA; // attribute must be public
   BiLinkVstr<A> A_Vstr; // attribute must be public
   ...
};

static int dummy1 =
   BiLink_to_BiLink<A,B>::add(&A::toB,&B::toA);
static int dummy2 =
   BiLinkVstr_to_BiLinkVstr<A,B>::add(&A::B_Vstr,&B::A_Vstr);

S>Занятный поинт

// Один кортеж данных, снятых с одного измерительного устройства за один замер.
class    data_packet_t
    {
    protected:
        std::vector< float >    m_values;
    ...
    };

// Один одномоментный замер с нескольких устройств.
class    measure_t
    {
    protected:
        // Время проведения замера.
        date_time_t    m_when;
        // Список устройств, с которых были сняты замеры и
        // снятые значения.
        std::map< std::string, data_packet_t >    m_data;
    ...
    };
    
// Результаты замеров для одного устройства.
class    object_measurement_session_t
    {
    protected :
        std::list< measure_t >    m_data;
    ...
    };

class    surface_t
    {
    private :
        // Материал, из которого создана поверхность.
        material_t *    m_material;
        // Геометрическая форма поверхности.
        geometry_t    m_geometry;
        ...
    };

class    surface_t
    {
    public :
        // Запросить параметры для редактора (цвет, стиль линии, стиль заливки и т.д.)
        void
        properties( editor_properties_t & props ) const;
        
        // Изменить значение указанного параметра (цвета, стиля линии и т.д.)
        void
        change_properties(
            const editor_property_t & prop,
            editor_undo_redo_t & undo_redo );

        // Отобразить объект на чертеже (с учетом группировки, выделения и т.д.)
        void
        paint(
            editor_paint_device_t & device,
            editor_selection_t & selection ) const;
        ...
    };

class    surface_t
    {
    public :
        // Отобразить на указанном устройстве.
        void
        draw( paint_device_t & device ) const;
        ...
    };

V>ну и где мое высказывание противоречит твоему замечанию

Тогда ООП-хранилища и "покажут" этой реляционке, с ее суррогатными ключами и индексами.

S>Так вот, например, я загрузил операцию (или мне ее вернула какая-нибудь функция) и решил изменить у нее ссылку на документ. То есть переприсвоить операцию другому документу (пример, конечно неудачный, но...). Я же должен соответствующие изменения сделать и в коллекциях ссылок старого и нового документа. Т.е. все равно эти коллекции сначала придется подгрузить. Так что выделяй в отдельный объект или нет — без разницы.

Что-то я не очень понимаю в чем суть проблемы. Если по условиям задачи возможно, что в объекте "операция над документом" можно поменять ссылку на изменяемый документ (что само по себе странно), то можно организовать коллекцию ссылок таким образом, чтобы операции вставки/удаления были дешевыми. Например, вместо вектора ссылок использовать двусвязный список (каждый элемент содержит собственно ссылку + ссылки на предыдущий/следующий элементы списка) или map на основе B+ дерева.

Джентельмены.

Давайте забудем (и по крайней мере сделаем вид что отвлеклись от) все что здесь уже говорилось про объектные базы и Версант. Предлагаю более вообще не обсуждать теорию.

Простейшая формулировка как хранит данные и работает Версант (в отличие от реляционных баз):

1. Версант — это "якобы объектное хранилище". Методы объектов не выполняются и не хранятся. Хранятся только данные (структуры данных). Как в РСУБД. Буду нывать далее структурами данных Версант. Струры данных самые разнообразные — это и массивы, коллекции (вложенные коллекции), и указатели на другие объекты и пр. На эти коллекции маппируются вложенные коллекции классов (1-n). На указатели на объекты — ссылки n-m.

2. Версант (ядро) ничего не знает про Яву, с++, Smalltalk, whatever.
Средства доступа к Версанту на Яве "преобразуют" Ява объекты в структуры данных Версант. Средства доступа к Версанту на с++ "преобразуют" с++ объекты в структуры данных Версант. Предыдущие 2 предложения применимы к любым "обектным" языкам. Не буду их копировать.

3. Средства доступа.
1. Командная строка (аля sqlplus). Сама по себе не объектна. Соответственно, все запросы из командной строки возвращают структуры данных Версант. И тупо их печатают.
2. Средства доступа к Версанту на Яве.
2.1 Доступ по спецификации JDO. Это средство доступа ответственно за преобразование пришедших данных Версант в классы Ява. В соответствии со стандартом JDO, имеет свой собственный язык JDOQL. Это же средство ответственно за трансляцию JDOQL в запросы/вызовы процедур/чтоугодно нативное для Версант.
2.2 Доступ по АПИ Версант. Обеспечивает доступ непосредственно к структурам данных Версант. Запросы (по моему) на языке VQL. Имея этот доступ, можно реаливать любой мэппинг пришедших структур данных Версант на классы Ява.
2.3 Доступ по технологии Transparent Persistance. Просто вызывая функции Ява но изменению значения полей объектов, автоматически происходит преобразование данной системой доступа объектов в структуры данных Версант и их запись. Основной плюс — полное отсутствие обращений по обслуживанию сохранения объектов (поэтому и называется Transparent...)
2.4 Доступ по спецификации JDBC. Не знаю, не работал.

Единственное, что нельзя релизовать с точки зрения хранения структур в Яве — это с++ множественное наследование. Устраняется проблема путем либо интерфейсов, либо ручного маппинга.

Ессно, есть средства доступа для других объектных языков.

4. Средства ссылочной целостности — полные аналоги check constraints, foreign key, primary key. Есть хранимые процедуры и триггеры.

5. План запросов — есть хрень показывающая план запроса.

exec CreateSomeObject @param1, @param2

E>// Один кортеж данных, снятых с одного измерительного устройства за один замер.
E>class    data_packet_t
E>    {
E>    protected:
E>        std::vector< float >    m_values;
E>    ...
E>    };

E>// Один одномоментный замер с нескольких устройств.
E>class    measure_t
E>    {
E>    protected:
E>        // Время проведения замера.
E>        date_time_t    m_when;
E>        // Список устройств, с которых были сняты замеры и
E>        // снятые значения.
E>        std::map< std::string, data_packet_t >    m_data;
E>    ...
E>    };
    
E>// Результаты замеров для одного устройства.
E>class    object_measurement_session_t
E>    {
E>    protected :
E>        std::list< measure_t >    m_data;
E>    ...
E>    };
E>

E> Не понял сарказма.

E>А банковский клиент стало быть должен доверять коду, который он скачивает вместе с объектом с банковского сервера?

public static void TransferMoney(IAccount source, IAccount target, IAmout amount)
{
    try
    {
        target.Balance += amount; // здесь выполняется офигенно полиморфный код, благодаря которому мы 
      source.Balance -= amount; // можем безболезненно вводить новые типы счетов. Так выглядит ОО в ООСУБД.
    }
    catch(Exception ex)
    {
      // при попадании в обработчик состояние всех объектов автоматически откатывается к тому, которое 
        // было на момент try. Так выглядят транзакции в ООСУБД.
        Audit.Log("Failed to transfer {0} from {1} to {2}: {3}", amount, source, target, ex);
    }
}

S>exec CreateSomeObject @param1, @param2
S>

class    polygon_t
    {
    protected :
        std::list< point_t >    m_points;
    ...
    };

E>>// Один кортеж данных, снятых с одного измерительного устройства за один замер.
E>>class    data_packet_t
E>>    {
E>>    protected:
E>>        std::vector< float >    m_values;
E>>    ...
E>>    };

E>>// Один одномоментный замер с нескольких устройств.
E>>class    measure_t
E>>    {
E>>    protected:
E>>        // Время проведения замера.
E>>        date_time_t    m_when;
E>>        // Список устройств, с которых были сняты замеры и
E>>        // снятые значения.
E>>        std::map< std::string, data_packet_t >    m_data;
E>>    ...
E>>    };
    
E>>// Результаты замеров для одного устройства.
E>>class    object_measurement_session_t
E>>    {
E>>    protected :
E>>        std::list< measure_t >    m_data;
E>>    ...
E>>    };
E>>

E>> Не понял сарказма.

E>>А банковский клиент стало быть должен доверять коду, который он скачивает вместе с объектом с банковского сервера?

S>public static void TransferMoney(IAccount source, IAccount target, IAmout amount)
S>{
S>    try
S>    {
S>        target.Balance += amount; // здесь выполняется офигенно полиморфный код, благодаря которому мы 
S>      source.Balance -= amount; // можем безболезненно вводить новые типы счетов. Так выглядит ОО в ООСУБД.
S>    }
S>    catch(Exception ex)
S>    {
S>      // при попадании в обработчик состояние всех объектов автоматически откатывается к тому, которое 
S>        // было на момент try. Так выглядят транзакции в ООСУБД.
S>        Audit.Log("Failed to transfer {0} from {1} to {2}: {3}", amount, source, target, ex);
S>    }
S>}
S>

S>Нету

S> То, о чем ты говоришь, к системам управления базами данных отношения не имеет. Стабилизация объектных данных называется persistence, и для нее существует великое множество решений. Как правило, это банальная сериализация. Встроена практически во все ОО-системы, распространенные с девяностых годов и по наше время. MFC, VCL, Java и .Net поддерживают сохранение объектов. Причем и эволюция схемы решена везде (кроме как в Delphi).

class    surface_t
    {
    material_t *    m_material;
    geometry_t    m_geometry;
    };

class    surface_t
    {
    protected :
        material_t *    m_material;
        geometry_t    m_geometry;
        editor_t *    m_editor;
    public :
        ...
        // Запросить параметры для редактора (цвет, стиль линии, стиль заливки и т.д.)
        void
        properties( editor_properties_t & props ) const;
        
        // Изменить значение указанного параметра (цвета, стиля линии и т.д.)
        void
        change_properties(
                const editor_property_t & prop,
                editor_undo_redo_t & undo_redo );

        // Отобразить объект на чертеже (с учетом группировки, выделения и т.д.)
        void
        paint(
                editor_paint_device_t & device,
                editor_selection_t & selection ) const;
    };

class    surface_t
    {
    protected :
        material_t *    m_material;
        geometry_t    m_geometry;
        device_properties_t *    m_properties;
    public :
        ...
        // Отобразить на указанном устройстве.
        void
        draw( paint_device_t & device ) const;
        ...
    };

class    surface_data_t
    {
    material_t *    m_material;
    geometry_t    m_geometry;
    };

class    surface_t
    {
    surface_data_t    m_data;
    };

public static bool AcceptVisitor(Person visitor)
{
  return (visitor.Age > 21);
}

Schools schools=getAllSchools();
for(int x=0;x<coll.size();x++)
{
    Human h=coll.get(x);
    if (h.getAge()>27)
    {
       for (int y=0;y<schools.size();y++)
          if (schools.get(x).getStudents().hasObject(h))
           resultColl.add(h);
    }
}

C>Schools schools=getAllSchools();
C>for(int x=0;x<coll.size();x++)
C>{
C>    Human h=coll.get(x);
C>    if (h.getAge()>27)
C>    {
C>       for (int y=0;y<schools.size();y++)
C>          if (schools.get(x).getStudents().hasObject(h))
C>           resultColl.add(h);
C>    }
C>}
C>

public static bool Predicate(Human h)
{
    if (h.Age<=27)
        return false;
        
  foreach(School school in Schools)
    {
        if school.Students.Contains(h)
            return true;
    }
    return false;
}

public static bool Predicate(Human h)
{
    return (h.Age>27) && (AllStudents.Contains(h));
}

public static bool Predicate(StudentRecord studentRecord)
{
    return (student.Person.Age>27);
}
...

foreach(IStudent student in GlobalExtent.Select(Predicate))
{
    System.Console.Writeln(student);
}

public static bool Predicate(Human h)

{
    return (sin(h.Age)>0.2763) && (AllStudents.Contains(h));
}