В отличии от РСУБД в объектных СУБД каждый объект обладает идентификатором, т.е. может быть индивидуально адресован и идентифицирован. Несколько различных коллекций могут иметь ссылки на один и тот же экземпляр и отдельная коллекця так же может содержать несколько ссылок на один и тот же экземпляр. Несмотря на данную особенность, коллекции можно рассматривать как отношения и выполнять над ними те же операции что и в РСУБД. В этом случае идентичность отдельных объектов будет потеряна, что представляет собой нежелательное явление, т.к. сетевые и объектные СУБД используются в задачах, для которых наличие идентифицируемости у экземпляров является желательным свойством. В связи с этим разработка механизма объектных запросов к сетевой СУБД, сохраняющих идентичность экземпляров, является очень интересной и актуальной научной проблемой.

Стандартная форма представления запроса в объектно-ориентированной СУБД может быть как текстовой - некоторый текстовый язык запросов, похожий на SQL или OQL либо некоторой структурой в памяти ЭВМ, декларативно описывающей запрос. Опыт эксплуатации СУБД показал, что запросы к БД пишут квалифицированные программисты, при этом зачастую, используюя автоматизированные построители запросов. Далее такие запросы либо встраиваются в приложение, либо выполняются напрямую СУБД. Так называемые adhoc запросы, набираемые пользователем БД в ручную в некоторой оболочке к БД нужны в основном для административных и отладочных целей. В приложениях они используются только в случае необходимости динамического синтеза запроса. В любом случае, в приложении с текстовым представлением запроса, ориентированным на человека всегда работает программная система. В ней содержиться запрос, она при необходимости привязыает параметры, либо модифицирует запрос, она инициирует его выполнение и обработку результатов. В процессе выполнения запроса СУБД разбирает запрос, строит план его выполнения, привязывает динамически изменяемые параметры и только потом выполняет. Мало того, что разбор языка запроса, ориентированного на обработку человеком занимает некоторое время, главное, что эта ситуация поощряет различные ошибки: ошибки в конвертации типов данных, потерю точности, инъективные атаки и т.д. В связи с этим видится более эффективным разработать декларативный язык запросов к ООСУБД ориентированным не на обработку человеком, а на обработку самой ООСУБД. Далее как надстройки, можно создать различные диалекты SQL, OQL или новых языков ОО запросов, которые будут компилироваться в некоторое промежуточное представление, ориентированное на оптимальную обработку в СУБД. Такое промежуточное представление языка запросов можно применять по аналогии с байт-кодом современных компиляторов, как стандартный протокол в клиент-серверных обменах СУБД<->приложение. Учитывая, что промежуточный язык декларативных запросов разрабатывается для ООСУБД естественно предположить, что наиболее оптимально будет построить его на основе объектной модели - множества экземпляров, связанных друг с другом ссылками в сетевую структуру.

При обработке запроса в широко известных РСУБД результат возвращается в виде отношения. В отличие от РСУБД в ООСУБД данные храняться не в виде отношений а в виде узлов, связанных в сеть. Естественно возвращать результат обработки ОО запроса так же в виде сети состоящей из экземпляров некоторых объектов связанных ссылоками (указателями) в некоторую сложную структуру.

В РСУБД результатом запроса всегда является отношение. Однако не всегда шапка отношения результата запроса совпадает с шапкой отношения, хранимой в БД в виде таблице. В ООСУБД также не обязательно классам, определенным в БД, совпадать с классами, определенными в результате выполнения запроса. В ООСУБД должны быть реализованы запросы, трансформирующие структуру объектов, хранимую в БД в некоторую другую структуру требуемую потребителю результата запроса. Будем различать запросы модифицирующие объектную модель (структуру) хранимую в БД и запросы при выполнении сохраняющие структуру БД.

Рассмотрим построение объектной модели запросов и результата запроса не осуществляющего преобразование структуры ООСУБД. При выполнении таких запросов требуется обеспечить сохранение индивидуальности экземпляров. Так если некоторый экземпляр, хранимый в БД как А преобразуется в результате запроса в А', то все другие экземпляры имевшие ссылки (указатели) на экземпляр А и попавшие в результат запроса должны сохранить эти указатели на экземпляр А' К сожалению в клиент-серверных технологиях с активным сервером сохранять ссылки на оригинальный экземпляр А в большинстве практических сценариев не представляется разумным. Это потребует создание на клиенте прокси-объекта А' замещающего объект А и наличие постоянного соединения клиента и сервера. Поэтому при выполнении ОО запросов будем передавать на клиент копии объектов (MarshalByValue) и восстанавливать между ними топологию соединений, аналогично топологии соединений, имеющей место между оригинальными экземплярами, хранимыми в сервере СУБД.

Экземпляры объектов, поддерживающие совместимый интерфейс по данным либо методам часто удобно возвращать клиенту в коллекциях. Запрос к объектной БД определяет коллекции, формируемые в результате его выполнения клиенту и условия отбора экземпляров в эти коллекции. Для коллекций, формируемых в результате выполнения запроса, введем ограничение: отдельный экземпляр не может входить в некоторую коллекцию более одного раза. Однако может сложиться ситуация, когда некоторый экземпляр поддерживает несколько интерфейсов, и исходя из бизнес логики клиенту необходимо его отобрать одновременно в разные коллекции. В этом случае такие коллекции будут содержать ссылки на один и тот же экземпляр. Т.е. один экземпляр может одновременно находиться в нескольких коллекциях.

В описываемой системе, при выполнении запросов, требующих соединения объектов, Декартово произведение не осуществляется. Каждый экземпляр входит в результат выполнения запроса только один раз. Однако экземпляры попавшие в соединение связываются друг с другом с помощью ссылок.

В качестве примера рассмотрим выполнения запроса, соединяющего коллекцию Городов и коллекцию Организаций. Пусть каждая Организация имеет ссылку на Город в котором она находится. При выполнении запроса формируется две коллекции Города и Организации. Несколько организаций могут находится в одном городе. Объект Город формируется в адресном пространстве клиента только один раз и размещается в коллекции Города. Все организации соединенные с некоторым городом связываются с этим городом путем размещения в поле Организация.Город указателя на соответсвующий Город действительным в адресном пространстве клиента. В результате клиенту передаются две коллекции, Города и Организации, содержащие только по одному экземпляру Города или Организации. Объектная связь один к одному (аналог половины связи один ко многим в РМД) осуществляется путем заполнения поля Организация.Город у всех организаций в коллекции Организации указателями на соответсвующие экземпляры в коллекции Города. После выполнения запроса клиент может работать со свойствами объектов выполняя разадресации указателей. Например для доступа к имени города некоторой организацци клиент использует доступ к полю Организация.Город.Имя

Сахават ЮсифовНадо возвращать три коллекции, Город,Организация, Город.Организация.
"Организация" ничего не знает о городе, ему это по фигу. Это внешний наблюдатель связывает Город с Организацией когда ему это надо.

В данном примере Город ничего не знает про Организации. Организация имеет указатель на Город в котором находится. Город не имеет коллекцию дочерних объектов-Организаций. Поэтому именно две.

В сценарии где Город будет иметь коллекцию Организаций Город.Организации, возвращаемых коллекций тоже будет две. В объекте Город вернется поле Город.Организации содержащее массив указателей на дочерние Организации. Можно будет какуюто Организацию разместить в нескольких Городах. Тогда и поле Организация.Города будет содержать массив указателей.

Сахават ЮсифовПилохо это.
Объекты сами по себе, а наблюдатели сами по себе. Объект может иметь ссылку на родителей, только если он унаследован.

Не понял почему плохо, и какие полезности дает декларируемое ограничение про родителей? Можете практический пример привести?

Сахават ЮсифовНу, представьте, что организация переехала в деревнью. Что будем делать?

Переехавшая организация изменит значение одного своего поля Организация.Город на указатель на деревню. Ну название будет "левым" - это уже вопрос к именованию полей и к проектировщику, не предусмотревшему такую возможность за ранее. Деревня может быть в другой коллекции деревень или может входить в коллекцию Городов, или и в коллекцию Городов и коллекцию Деревень - вопрос заполнения БД на уровне сервера. При выполнении запроса все связанные с экзмемплярами Организаций экземпляры соберуться в коллекцию Городов. Если у Города и Деревни интерфейсы по данным и по поведению совместимы - клиент обработает ситуацию совершенно прозрачно. Ни строчки кода ни в классах уровня сервера ни в клиенте менять не придется даже если такой переезд не был запланировал при начальном дизайне системы.

Интересно наблюдать поведение этой системы, когда в Организация.Город из этого примера поместить указатель на другую Организацию. В этом случае все отобранные экземпляры Организаций размещаются в коллекции Организаций, а так же все связанные с отобранными Организациями Организации (может быть те же самые, что уже находятся в коллекции Организаций на клиенте) размещаются в коллекции Города. Одна и та же Организация может оказаться как только в коллекции Организаций, только в коллекции Городов или в обоих коллекциях одновременно. Помним, что идентичность экземпляра сохраняется, копии объектов не создаются.

Сахават ЮсифовНет, это вопрос к Вам. Просто не надо вводить в "организация" поле "местоположение".
Это "Местоположение" должна включать "организацию" в виде "город","организация".
Не вижу необходимости в модальности "должна". Может если разработчику будет удобно. Причем удосбтв или религиозной чистоты такого дизайна мне не видно. Мало того, пример с Организация-Город надуман с целью объяснить реализованный на сеходня механизм выполнения декларативных объектных запросов в моей СУБД/БЗ. А вовсе не для того чтоб постулировать единственно правильный способ соединения Городов и Организаций )))