Реляционные базы данных и объектно-ориентированные среды

Реляционные базы данных и объектно-ориентированные среды не могут похвастаться полной совместимостью. Они представляют собой два разных видения мира: в реляционных базах данных вы оперируете данными, а в объектно-ориентированных средах - поведением. Нельзя сказать, что одно из этих видений лучше другого: объектно-ориентированные системы обычно лучше подходят для сложных систем со сложным поведением, в которых данные вторичны, а также для систем, в которых данные структурированы иерархически (например, при работе с ведомостями). Реляционные базы данных отлично подходят для создания отчетов и систем, в которых используются динамические и неструктурированные связи между компонентами.

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

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

Реляционная модель

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

Реляционная модель

У объекта есть столбцы. У каждого столбца есть имя и тип. На рисунке выше у объекта LINEITEM есть столбцы LineItem_Id (основной ключ), Description, Price, Quantity, Product_Id и Order_Id (последние два столбца - внешние ключи, привязывающие объект LINEITEM к объектам ORDER и PRODUCT).

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

У каждого объекта есть один или несколько основных ключей. LineItem_Id - основной ключ объекта LINEITEM.

Особенности поддержки взаимосвязей зависят от разработчика базы данных. В данном примере продемонстрирована логическая модель с взаимосвязью между таблицами PRODUCT и LINEITEM. В физической модели взаимосвязи обычно реализованы в виде ссылок между внешними и основными ключами. Если один объект ссылается на другой, в нем будут столбцы с внешними ключами. В столбцах с внешними ключами хранятся данные, по которым можно установить взаимосвязь между записями данного объекта и записями взаимосвязанного объекта.

У взаимосвязей есть понятие множественности. Типичные примеры множественности - один к одному (1:1), один ко многим (1:m), многие к одному(m:1) и многие ко многим (m:n). В данном примере у LINEITEM взаимосвязь 1:1 с PRODUCT, а у PRODUCT взаимосвязь 0:m с LINEITEM.

Объектная модель

В объектной модели, помимо прочего, присутствуют классы (полное описание объектной модели можно найти в книге [UML01 ]). Классы задают структуру и поведение набора объектов, которые иногда называют экземплярами объектов. Структура задается в виде набора атрибутов (значений данных) и связей (связей между классами). На следующем рисунке показана простая диаграмма класса, на которой отмечены только атрибуты (данные) класса.

Объектная модель (диаграмма класса)

У атрибута Order есть атрибут number (номер заказа) и связь с одним или несколькими атрибутами Line. У каждого атрибута Line есть атрибут quantity (количество заказанных единиц товара).

Объектная модель поддерживает наследование. Класс может наследовать данные и поведение у другого класса (например, продукты SoftwareProduct и HardwareProduct могут наследовать атрибуты и методы у класса Product).

Среды хранения

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

Существует несколько стандартных интерфейсов (API) для работы с базами данных, например Microsoft Open Data Base Connectivity (ODBC). Все эти интерфейсы закрыты (взаимодействуют с конкретными реализациями СУБД). Интерфейсы API поддерживают язык управления данными (DML), применяемый приложениями для работы с реляционными базами данных. Для применения реляционных данных в объектно-ориентированных приложениях требуется преобразование этих данных в объектно-ориентированный формат. Для преобразования выборки данных в объекты приложения требуется довольно весомый программный код. Цель объектно-реляционной среды заключается в инкапсуляции физического хранилища данных и предоставлении функции преобразования данных в объектный формат.

Назначение среды хранения

Около 30% времени разработчики приложений тратят на организацию доступа к реляционным базам данных из объектно-ориентированных приложений. Если объектно-ориентированный интерфейс реализован неправильно, это время можно считать потерянным. Создание объектно-реляционной среды позволяет избежать таких потерь. Применение объектно-реляционной среды в приложениях позволяет сократить стоимость организации доступа к реляционным базам данных до менее чем 10% общей стоимости реализации. Важнейший компонент стоимости, который следует принимать во внимание при реализации, - обслуживание. Свыше 60% общей стоимости системы на протяжении ее жизненного цикла составляет обслуживание. Плохо реализованная объектно-реляционная система может стать настоящим кошмаром при обслуживании системы как с технической, так и с финансовой точек зрения.

Основные характеристики объектно-реляционной среды

• Производительность . Необходимо уделить пристальное внимание преобразованию объектов в данные и данных в объекты. В системах с интенсивной обработкой данных этот элемент зачастую представляет собой ахиллесову пяту всей системы доступа к данным.
• Технические решения . Типичный подход специалистов по объектным системам при работе с реляционными базами данных заключается в подгонке объектной модели под структуру базы данных или подгонке структуры реляционной базы данных под объектную модель для упрощения хранения объектов. Хотя зачастую требуется минимальная коррекция, эффективная система доступа минимизирует отрицательное влияние такой коррекции на эффективность как реляционной, так и объектной модели.
• Расширяемость . Система доступа к данным должна быть расширяемой на случай, если в будущем понадобится адаптировать ее к новым потребностям. Как правило, система доступа к данным без расширений должна поддерживать 65-85% требований приложения к хранению данных. Если система доступа не допускает расширения, реализация оставшихся 35-15% требований может стать очень сложной и дорогостоящей.
• Документация . Система доступа - это одновременно и закрытая система, и открытая среда. Интерфейсы закрытой системы должны быть четко определены, задокументированы и ясно описаны. Как указано выше, система доступа должна быть легко расширяемой. Для этого она должна быть снабжена подробной документацией. Необходимо определить множество классов, для которых предполагается создание подклассов. Необходимо задать характеристики всех соответствующих протоколов классов (например, public, private, protected, final, ...). Кроме того, для упрощения расширения системы в будущем рекомендуется открыть и задокументировать как можно больше ее компонентов.
• Поддержка общих объектно-реляционных преобразований . Система доступа должна поддерживать базовые объектно-реляционные преобразования без дополнительных расширений. Эти преобразования подробно обсуждаются в следующих разделах данного документа.
• Интерфейсы хранения : модель бизнеса для объектного приложения в объектно-ориентированной среде должна охватывать смысл предметной области. Разработчики должны оперировать объектами и обеспечивать взаимодействие между ними без необходимости задумываться над особенностями считывания и записи данных. В распоряжении разработчиков приложений должен быть хороший набор хранимых интерфейсов (сохранение, удаление, поиск данных).

Общие службы объектно-реляционной среды

В разработке объектно-реляционных приложений намечаются общие тенденции. Специалисты, неоднократно занимавшиеся интеграцией подобных систем, начинают понимать и выявлять определенные структуры и свойства удачных объектно-реляционных приложений. Эти структуры и свойства были формализованы в высокоуровневых спецификациях CORBA (которые относятся и к системам на основе COM/DCOM).

При разработке объектно-реляционных систем следует принять во внимание следующие спецификации служб CORBA:

В следующих разделах обсуждение объектно-реляционных служб структурировано по этим категориям. Настоятельно рекомендуется ознакомиться с соответствующими спецификациями CORBA.

Хранение

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

Ниже перечислены некоторые службы, предоставляемые системой хранения:

• Управление соединением с источником данных : объектно-реляционные приложения должны устанавливать соединение с физическим источником данных. Как правило, реляционные СУБД представляют собой комплекс из сервера и базы данных. Особенности управления соединениями зависят от разновидности СУБД, и среда должна быть достаточно гибкой для поддержки различных систем.
• Извлечение объектов : извлечение объектов из базы данных заключается в том, что данные считываются из базы данных и преобразуются в объекты. Данный процесс предполагает извлечение данных из структур базы данных, маршализацию данных в соответствующие классы и типы объектов и формирование необходимых атрибутов объектов.
• Сохранение объектов : процесс сохранения объектов обратен процессу их извлечения. Значения атрибутов извлекаются из объекта, затем создается структура базы данных со значениями атрибутов (строка SQL, хранимая процедура или особый вызов RPC), а затем полученная структура заносится в базу данных.
• Удаление объектов : объекты удаляются из системы, а соответствующие им данные - из базы данных. Для удаления объектов необходимо извлечь из них соответствующую информацию, создать запрос на удаление (это может быть строка SQL, хранимая процедура или особый вызов RPC), а затем передать запрос в базу данных. Учтите, что в некоторых языках (например, Smalltalk и Java) явное удаление не поддерживается. Вместо этого там применяется стратегия сбора мусора . В системах хранения, поддерживающих эти языки, должен быть предусмотрен альтернативный способ удаления данных из базы после того, как приложения перестают пользоваться ими. Один из распространенных способов заключается в учете количества ссылок на объект из других объектов. Как только количество ссылок падает до нуля, на этот объект больше не ссылаются другие объекты, и возможно , этот объект больше не нужен. В некоторых случаях можно удалять объекты с нулевым количеством ссылок, поскольку даже если на объект нет ссылок, он может использоваться. В любом случае нужна централизованная стратегия удаления объектов, действующая в масштабах всей базы данных.

Запрос

От системы хранения мало пользы в отсутствие механизма поиска и извлечения нужных объектов. Средства поиска применяются для нахождения объектов, удовлетворяющих определенным условиям. Стандартные операции поиска в объектно-реляционных средах - find и find unique. Операция find unique возвращает конкретный объект, а операция find - набор объектов, соответствующих заданным критериям.

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

Учтите, что существует потенциальный конфликт между механизмами запросов к базам данных и объектной парадигмой: механизмы запросов работают на основе значений атрибутов (столбцов) таблицы. Принцип инкапсуляции объектной модели не позволяет видеть значения атрибутов, так как они инкапсулированы за операциями класса. Инкапсуляция применяется для того, чтобы упростить изменение приложений - она дает возможность изменять внутреннюю структуру классов, не беспокоясь о зависимых классах постольку, поскольку не меняются внешние интерфейсы изменяемого класса. Механизм запросов зависит от внутренней реализации классов и таким образом нарушает инкапсуляцию. Задача среды заключается в том, чтобы сохранить независимость приложений от особенностей запросов и сохранить свободу изменения классов.

Транзакции

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

Помимо среды хранения, приложение должно уметь обрабатывать ошибки. Если транзакция будет прервана или завершится с ошибкой, система должна быть в состоянии вернуться в стабильное рабочее состояние, например путем считывания информации о предыдущем состоянии из базы данных. Поэтому среда хранения и среда обработки ошибок должны работать в тесном взаимодействии.

Параллелизм

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

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

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

Взаимосвязи

У объектов есть взаимосвязи с другими объектами. У объекта Order есть несколько объектов Line Item. У объекта Book есть много объектов Chapter. Объект Employee принадлежит ровно одному объекту Company. В реляционных системах взаимосвязи между объектами реализованы с помощью ссылок на основные и внешние ключи. В объектно-ориентированных системах такие взаимосвязи обычно явно заданы с помощью атрибутов. Если у объекта Order есть объекты LineItems, объект Order будет содержать атрибуты lineItems. Атрибут lineItems объекта Order может содержать произвольное количество объектов LineItem.

Аспекты взаимосвязей в объектно-реляционной среде тесно связаны с вопросами реализации хранения, транзакций и выполнения запросов. При сохранении и выборке объектов, выполнении транзакций и запросов необходимо учитывать следующие факторы:

• Нужно ли вместе с объектом извлекать из базы данных объекты, с которыми он связан? Простой ответ на этот вопрос - "да", но цена извлечения ненужных объектов может быть очень большой. В хорошей среде могут поддерживаться несколько стратегий на этот счет.
• Нужно ли при сохранении объекта заодно сохранять и связанные с ним объекты, которые также были изменены? Ответ на этот вопрос тоже зависит от контекста.

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

Переход к объектно-ориентированным моделям данных связан с процессом "перекачки" в них огромных объемов информации, которая в настоящее время хранится преимущественно в реляционных базах данных. Чтобы упростить этот процесс, сформировали объектно-реляционную модель данных, в которой выделяют две разновидности – гибридные и расширенные.

В гибридных объектно-реляционных базах данных объектно-ориентированный подход используется в создании интерфейса пользователя и алгоритма приложения. В го же время система таблиц формируется в рамках реляционной модели данных.

В расширенных объектно-реляционных базах данных объектно-ориентированный подход используется прежде всего при построении системы таблиц. Для этого разработана модификация языка SQL2, получившая название языка программирования SQL3.

Виды структур

"Промежуточной" моделью данных между реляционными и объектно-ориентированными базами данных является объектно-реляционная модель (ОРБД).

Ее появление вызвано двумя причинами.

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

Различают, как отмечалось ранее, две разновидности ОРБД – гибридные и расширенные.

• 1. В гибридных ОРБД интерфейс пользователя и алгоритм приложения выполнены с учетом объектно-ориентированного подхода, тогда как собственно БД является реляционной. Примерами могут служить СУБД Paradox и InterBase в рамках программного продукта Delphi. В каком-то смысле гибридной можно считать СУБД Access при использовании языка программирования Visual Basic for Application (VBA).
• 2. В расширенных (постреляционных) ОРБД предполагается объектно-ориентированное построение собственно базы данных путем использования известных и введения новых типов данных, связанных между собой. Эта связь чаще всего осуществляется созданием методов с помощью триггеров и хранимых процедур. В расширенной объектно-реляционной модели допускается, в отличие от реляционной модели данных, неатомарность данных в поле. В таких полях может располагаться другая таблица или массив. К подобным СУБД относятся Informix Universal Server, Oracle 8, UniSQL. В таких СУБД широко используется язык SQL3.

Заметим, что постреляционными называют БД, в которых частично проведена денормализация данных, при этом допускается нетомарность записей.

Рассмотрим более подробно обе разновидности.

Гибридные ОРБД

Эта разновидность ОРБД рассмотрена на примере программного продукта Delphi.

Приложение Delphi изначально предназначалось для автоматизации программирования (объектно-ориентированного программирования), поскольку позволяло резко поднять производительность труда программистов за счет использования готовых "кубиков-программ". Требовалось лишь должным образом соединить эти "кубики".

В дальнейшем выяснилось, что примененный в Delphi объектно-ориентированный подход может быть использован при проектировании баз данных. В рамках Delphi применение объектно-ориентированного проектирования (см. рис. 7.2) и программирования не вызывает затруднений в интерфейсе пользователя и алгоритме приложения. Покажем это.

При работе Delphi на экране монитора появляется "картинка" (рис. 8.1). Компоненты-классы разделены на группы, определяемые соответствующими закладками (страницами).

Форма Delphii, сама являясь объектом, служит "коллектором" для объектов. Как только компонент помещается в форму (и получает порядковый номер), он становится объектом.

Заметим, что компоненты TPanel, TBevel также являются контейнерами (в форме), используемыми для форматирования, дизайна (разделения объектов и их выравнивания). Другими "миниконтейнерами" служат компоненты DataModule и TQuickRep (отчет).

Рис. 8.1. Экран для работы с приложением Delphi

Для активного объекта в форме при построении программ в "Инспекторе объектов" могут использоваться свойства (страница "свойства") и события (закладка "события"), обычно запускающие программы-методы.

Все компоненты разделены на следующие основные группы: Standard, Additional, Dialogs, Win32, System, VCL, Internet, DataAccess, DataControl, QReport, Decision Cube, ActiveX. В процессе автоматизированного программирования чаще всего используют первые четыре страницы.

С позиций собственно баз знаний и баз данных следует обратить особое внимание на страницы DataAccess и DataControI. К ним примыкают страницы QReport, Decision Cube.

Состав компонентов некоторых закладок DataAccess и DataControI показан на рис 8.2. На рис. 8.3 и 8.4 показаны свойства и события компонента ТТаblе.

Рассмотрим описание программных возможностей Delphi.

Приложение Delphi может работать с тремя реляционными СУБД: dBase, Paradox – в локальном режиме (рис. 8.3); InterBase, который инсталлируется отдельно, – в режиме клиент-сервер.

Заметим, что СУБД InterBase возможно использовать в двух вариантах: локальном (сервер и клиент на одном компьютере, используется обычно в процессе отладки) и удаленном (сервер и клиент на разных компьютерах).

Рис. 8.2. Состав некоторых страниц компонента Delphi

Независимо от используемой СУБД интерфейс пользователя и алгоритм приложения строится с использованием объектно-ориентированного подхода. Подтвердим кратко это утверждение.

А. Речь первоначально пойдет о реализации собственно базы данных.

А1. Первоначально задается имя БД. С помощью этого имени осуществляется ссылка на БД. Однако при этом требуется указывать порой длинный путь (адрес) доступа, что неудобно при многократном обращении к БД. В силу этого чаще используется али- ас (синоним ) БД – имя, заменяющее длинный путь. Построение алиаса ведется с помощью Delphi-утилит BDE Administrator и SQL Explorer.

А2. Создание таблиц БД для СУБД Paradox (локальный режим) и InterBase (режим "клиент-сервер"), равно как и заполнение БД данными, специфично для каждого случая. Нетрудно видеть, что при создании собственно базы данных не используется объектно- ориентированный подход.

Б. Интерфейс. Для построения интерфейса нет четких формальных правил. Однако некоторые рекомендации могут быть сформулированы.

Интерфейс составляется с учетом пожеланий пользователя. Вид интерфейса зависит от инструментария, предоставляемого СУБД или программным приложением.

В качестве инструментов для интерфейса могут быть система форм (Form), система кнопок, система элементов управления (список, поле со списком и т. д.).

Рис. 8.3. Свойства компонента Table

Для Delphi исходным инструментом чаще является система форм, вызываемая из головного меню или с помощью системы элементов управления и меню в главной форме.

Б1. Формы Delphi.

Рис. 8.4. События компонента Table

Б1.1. Формы Delphi часто называют окнами. Окно называют модальным (М), если доступ к предыдущему открытому окну возможен только после закрытия М-окна. В противном случае окно называют немодальным.

Пусть имеются две формы – Form1 и Form2, при этом Form2 вызывается из Form1.

В случае немодального окна для формы Forml пишется программный модуль uniti

procedure TForml .Button 1 Click(Senser: Tobject);

Чтобы можно было работать со вторым окном (формой), в программе uniti (раздел implementation) добавляется ссылка на программный модуль unit2 (формы Form2)

Теперь из uniti можно запускать немодальное окно Form2.

Чтобы сделать Form2 модальным окном, следует установить ее свойство BorderStyle=bsDialog. При этом надо внести изменения в uniti: вместо Forml.Show написать Form2.ShowModal.

Б1.2. Вместо "ручного" создания многооконного интерфейса возможно использовать шаблоны, в которых выделяются два варианта:

• многодокументный интерфейс (Multiple Document Interface – М DI);
• однодокументный интерфейс (Simple Document Interface – SDI).

При использовании MDI дочерние окна не превышают по размерам родительское окно и могут располагаться мозаикой (Title) или каскадом (Cascade). В родительском окне содержится главное меню приложения. MDI организуется так же, как модальное окно, при этом свойство FormStyle=fsMDIFomi для родительского окна и FormStyle=fsMDIChild – для дочерних окон. При создании MDI возможно использование шаблона или построение MD1 с "нуля".

В последнем случае выбирается File/New головного меню Delphi и в диалоговом окне New Items на странице New выделяют значок Application, вводя по очереди родительское и дочерние окна.

В программный модуль unit главного окна включаются ссылки на все дочерние unit-модули:

В unit-программах дочерних окон должны быть ссылки на unit- программу главного окна:

Перед сворачиванием главного окна первоначально сворачиваются дочерние окна.

Лучше использовать шаблоны SOI (MDI). Для этого обращаются к головному меню Delphi (File/New), входят в диалоговое окно New Items и на вкладке (странице) Projects выбирают необходимый шаблон: SDI (одна форма и один программный модуль) или MDI (две формы и три модуля).

Б2. Последовательность операций работы пользователя может быть задана с помощью меню или системы кнопок.

Б2.1. Формирование меню достаточно просто и потому подробно здесь не рассматривается. Упорядочение элементов меню (фактически – объектов), написание программ для них не отличаются от "привязывания" программ к таким элементам управления, как кнопка, поле со списком и т. д. Заметим лишь, что есть две разновидности меню – главное (TMainMenu страницы Standard) и всплывающее меню (TPopuMenu), вызываемое нажатием правой кнопки мыши.

Б2.2 . Другой возможностью задания последовательности операций работы пользователя является использование системы кнопок (TButton, TBitBtn). В Delphi обычно используют меню, а кнопки чаще играют вспомогательную роль и используются, например, для закрытия форм, изменения доступа к элементам меню.

Свойствами меню, равно как и системы кнопок, наиболее часто используемыми, являются Enabled и Visible.

Б3 . Гибкость меню обеспечивается использованием элементов управления.

Б3.1 . Универсальные элементы управления размещены на страницах Standard, Additional, Dialog палитры компонент. К таким элементам относятся TLabel, TEdit, TMemo, TComboBox. TButton, TBitBtn.

Специфично использование TLabel. Свойство Caption применяют для задания заголовков таблиц БД, названий к таким компонентам, как TEdit, TMemo.

В свою очередь свойства Editl.Text и Memol.Line применяют для задания параметров (одно- и многострочных), например, в запросах. Пожалуй чаще всего перечисленные элементы управления используют свойства Enabled, Visible.

Б3.2 . Специализированными элементами управления, связанными непосредственно с БД, являются компоненты страницы DataControl. К ним следует отнести прежде всего DBGrid, DBEEdit, DBNavigator, DBMemo.

Компоненты DBEdit позволяют создать форму базы данных в столбец. Такие формы часто применяются при работе в СУБД Access для заполнения БД.

Б4 . Сообщение. Его можно сделать обычным, используя, например,

MessageDlg(Query1["Name"], mtlnformation, , О);

Однако предпочтительнее применить схему исключительной ситуации try ... except

Query1["Plan"]< Queryl ["Fakt"]

ShowMessage("Число вакансий меньше числа принимаемых. Измените правила или должности принимаемых");

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

В. Алгоритм приложения. Программы приложений могут быть написаны на одном или сочетании трех языков: интерфейсный SQL, вложенный SQL, Object Pascal (OP) .

B.l . Возможны три "цепочки" доступа (рис. 8.5):

TTable – TDataSource – TDBGrid (чаще используется в СУБД Paradox);

TQuery – TDataSource – TDBGrid (чаще применяются для СУБД InterBase);

TStoredProc – TDataSource – TDBGrid (ислользуют только для СУБД InterBase).

Рис. 8.5. Объектно-ориентированный интерфейс пользователя (приложение Delphi):

BDE – Borland Database Engine (ядро Delphi)

В этих "цепочках" компонент TDBGrid является визуальным, а остальные – невизуальны. Компоненты TTable, TQuery, TStoredProc обеспечивают непосредственный доступ к БД (по алиасу), тогда как компонента TDataSource играет роль "размножителя": к нему могут подключаться визуальные компоненты TDBNavigator, TDBText, TDBEdit, TDBMemo, TDBListBox, TDBComboBox и другие. Эти подключаемые компоненты (если "спрятать" компонент TDBGrid с помощью свойства Visible или, лучше, Enabled) могут образовывать "аналог" форм Access (для заполнения БД). Понятие "форма" в смысле Access в Delphi отсутствует.

Связи в "цепочках" устанавливаются в статическом режиме (построения доступа), либо в динамическом при выполнении программы.

"Цепочка" StoredProc специфична и используется только в режиме клиент-сервер, да и то редко.

В.2 . Наряду с перечисленными "цепочками" могут использоваться и "укороченные цепочки", составленные из невизуальных объектов, контейнером для которых служит модуль (объектов) DataModule.

Такой контейнер организуется через меню Delphi (File/ NewDataModule). Связь между компонентами TTable – TDataSource и TQuery – TDataSource устанавливается так же, как это делается в форме при использовании ее в качестве контейнера для рассмотренных ранее "цепочек".

DataModule сохраняется под каким-либо именем, и для него создается программный модуль unit, имя которого добавляется в тексты программных модулей других форм приложения (File/Use Unit). При ссылках на такой модуль (объектов) следует сначала указать его имя, например DataModulel.DataSourcel.

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

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

В3 . Вложенный SQL используется только в режиме клиент- сервер.

В4 . Интерфейсный SQL используется в локальном режиме и режиме клиент-сервер.

Заметим, что интерфейсный язык SQL достаточно гибок при работе с БД, однако в нем нет понятия циклов и переходов. Кроме того, в свойстве SQL компоненты TQuery (или свойстве любой компоненты, например Memo.Text, из которой заимствуется SQL-oпeратор) может быть записан и запущен только один оператор , после выполнения которого его следует удалить и ввести новый. Таким образом, для выполнения нескольких операторов их следует вводить по одному, для чего требуется непростое программное решение, или "встраивать" в операторы Object Pascal.

В силу сказанного сфера действия интерфейсного языка SQL ограничена. Его операторы в чистом виде чаще всего используют в единичных запросах как в локальном режиме, так и в режиме клиент-сервер.

В локальном режиме чаще используют язык Object Pascal, составляющими операторами которого могут быть SQL-операторы.

В5 . Основную роль в локальном режиме играет язык программирования Object Pascal. В режиме клиент-сервер он, совместно с интерфейсным языком SQL, используется в клиентской части.

Следует отметить, что в Object Pascal существуют две разновидности программ:

• 1) "привязанные" непосредственно к событиям;
• 2) не связанные напрямую с событием (обычно "привязанные к форме") и вызываемые из других программ.

Построение первых программ широко описано в литературе, тогда как о вторых практически не упоминается. Последние пишутся полностью вручную.

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

Таким образом, в гибридной ОРБД интерфейс пользователя и алгоритм приложения построены с использованием объектно-ориентированного подхода, а собственно база данных – реляционная.

ВЛАДИМИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Имени Александра Григорьевича и Николая Григорьевича Столетовых

КАФЕДРА БИЗНЕС-ИНФОРМАТИКИ И ЭКОНОМИКИ

РЕФЕРАТ

по дисциплине «Базы данных»

на тему: «Объектно-ориентированные модели данных»

Выполнила:

студентка 3-го курса

группы БИ-114

Фадеева А.А.

Принял:

ст. пр. Виноградов Д.В.

Владимир 2016

Введение. 3

Общая характеристика объектно-ориентированных моделей данных. 4

Объектно-реляционная модель данных. 5

Пространственная модель данных. 8

Список литературы.. 13

Введение

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

Данные модели связаны с развитием Интернет–технологий. В объектно-ориентированных моделях при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.

Общая характеристика объектно-ориентированных моделей данных

Один из основных подходов к построению БД – использование объектно-ориентированной модели данных (ООМД). Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).

При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:

· встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;

· расширение существующего языка работы с базами данных объектно-ориентированными функциями;

· создание объектно-ориентированных библиотек функций для работы с БД;

· создание нового языка и новой объектно-ориентированной модели данных.

К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.

Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных.

В 2000 г. рабочая группа ODMG (Object Database Management Group), образованная фирмами-производителями ООСУБД, выпустила очередной стандарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации заключается в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содержится текст стандарта.

Объектно-реляционная модель данных

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

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

Такой подход был популярен в конце 80-х гг. и воплотился в программных продуктах для автоматизации программирования (CASE), для автоматизации проектирования (CAD), в репозитариях (БД, предназначенных для хранения не пользовательских, а системных данных).

2. Внутренние реляционные механизмы СУБД управления данными расширяются объектно-ориентированными возможностями (расширенный реляционный подход).

Этот подход технологически более продвинутый и предпочитаемый в настоящее время большинством разработчиков реляционных СУБД. Он воплотился в 1996-1997 гг. в ряде объектно-реляционных серверов БД.

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

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

Основная идея объектно-реляционного подхода - это допущение использовать в качестве атрибутов не только простые, атомарные типы данных, но и составные, абстрактные типы данных, что противоречит классической концепции реляционных СУБД.

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

· классы объектов в объектно-реляционной БД соответствую таблицы

· объекты будут соответствовать отдельным записям в таблице

· в качестве первичного ключа для таблицы базового класса проще всего взять поле целочисленного типа. В таблицах - наследниках ему будет сопоставлено обычное целочисленное поле

· первичный ключ в таблице является идентификатором объекта

· каждый объект может собираться из записей нескольких таблиц базового класса и наследников

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

К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).

Сегодня практически все известные фирмы используют объектные технологии. IBM и Oracle доработали свои СУБД (DB2 и ORACLE8, соответственно, добавив объектную надстройку над реляционным ядром системы, т.е. преобразовали их в объектно-реляционные СУБД. Informix приобрела объектно-реляционную СУБД Illustra и встроила ее в свою СУБД, изменив ее название на универсальный сервер.

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

Предыстория

Я занимаюсь проектированием и разработкой баз данных уже порядка 6 лет. За это время у меня сложилось свое видение как лучше подходить к проектированию, как выбирать архитектуру системы, какие существуют особенности при нормализации и денормализации реляционных БД, как оптимизировать те или иные конструкции и запросы. В первый год работы я пришел к тому, что не хочу заниматься рутиной по написанию одних и тех же запросов. В результате я написал свой генератор хранимых процедур, который по структуре БД генерировал большинство рутинных запросов (если будет интересно, то могу написать статью на эту тему). Затем этот генератор эволюционировал из года в год, и, в итоге, я пришел к необходимости хранить объекты, как они есть, чтобы не заморачиваться переводом объектной модели в реляционную структуру. Т.е. фактически я пришел к генерации некой ORM надстройки. Конечно, Вы можете сказать, что уже создано достаточное количество качественных ORM надстроек и объектно-реляционных БД, которые можно успешно использовать (и я с Вами соглашусь, но с некоторыми оговорками). Но и это меня не устроило. И я решил пойти дальше.

Влияние ORM

По моему скромному мнению использование ORM надстроек только тормозит развитие ООБД. Постараюсь пояснить это достаточно спорное утверждение. Я не считаю, что ORM это зло, но и абсолютным добром она тоже не является. Технология ORM несомненно сыграла (да и сейчас играет) важную роль в развитии средств разработки, она показала, что программист на самом деле может и не заботиться о логике хранения данных. Однако здесь, как и везде есть свои «НО».

Использование ORM несомненно ускоряет разработку продукта, снижает трудозатраты и бла-бла-бла. Однако, любая ORM это некая прослойка, которая всегда будет работать медленнее, нежели прямая работа (я тут отнюдь не призываю перенести все вызовы SQL запросов в приложение – везде должна быть золотая середина). Наличие ORM позволяет разработчикам не особо задумываться о работе СУБД (и они-таки не задумываются в большистве своем), что влечет за собой, мягко говоря, не совсем оптимальную работу приложения под нагрузкой. Для оптимизации приходится лезть руками в прослойку и настраивать запросы так, чтобы они стали работать быстрее, приходится лезть в базу данных и перенастраивать индексы и таблицы. Таким образом, для оптимальной работы приложения необходимо приложить больше усилий, нежели когда ORM отсутствует. В итоге мы сокращаем затраты на разработку и ускоряем выпуск первой версии продукта, но усложняем процесс оптимизации.

Однако об оптимизации никто не думает в момент написания первой (а зачастую и второй, и третьей) версии продукта. Для большинства контор сейчас главным фактором является не качество, а скорость разработки. Оно и понятно: изначально заказчик хочет получить продукт как можно раньше, затратив минимум денег. И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п. Разработчик часто руководствуется восточной мудростью: А там уже либо ишак сдохнет, либо султан, либо сам Ходжа . Но, если никто не сдох, то вот тут-то разработчик и начинает искать узкие места, выдирает из ORM автоматически сгенерированные запросы, переписывает их руками, перестраивает индексы в таблицах БД и тратит на это и подобную оптимизацию еще уйму времени и сил.

Что-то меня понесло в сторону. Надеюсь, я достаточно понятно изложил свою позицию относительно ORM. Давайте вернемся к сравнению (или, если кому угодно - противостоянию) реляционных и объектно-ориентированных БД.

Реляционные БД vs ООБД

Не смотря на огромную популярность парадигмы ООП в программировании, в технологии разработки баз данных эта парадигма пока не особо популярна. И тому есть как объективные, так и субъективные причины.

• Популярность. Под реляционные базы создано множество замечательных продуктов, которые необходимо поддерживать и развивать. В эти продукты уже вложены большие деньги и заказчики готовы еще вкладывать деньги в их развитие. Напротив, с использованием ООБД разработано сравнительно мало серьезных коммерческих продуктов, существует мало мощных ООСУБД.
• Язык запросов и его стандартизация. Еще в далеком 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Для объектно-ориентированных баз данных пока стандарта языка запросов нет. Сейчас среди разработчиков даже нет единого мнения о том, что этот язык запросов должен делать, не говоря уже о том, как он это должен делать.
• Математический аппарат. Для реляционных БД в свое время Эдгар Кодд заложил фундамент математического аппарата реляционной алгебры. Этот мат. аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных, доказывает их оптимальность (либо из него видно, где надо оптимизировать). С другой стороны для ООБД нет такого аппарата, даже не смотря на то, что работы в этой области ведутся с 80-х годов. Таким образом, в ООБД пока нет строгих терминов, таких как декартово произведение, отношение и т.д.
• Проблема хранения данных и методов. В реляционных БД хранятся только голые данные. Что с ними будет делать приложение, зависит уже от приложения. В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта). Здесь так же нет единого мнения, как ООБД должна осуществлять хранение объектов и как разработчик должен эти объекты разрабатывать и проектировать. Здесь же возникает и проблема хранения иерархии объектов, хранение абстрактных классов и т.п.

Выводы и перспективы

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

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

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

12 мая 2010 в 14:04

Реляционные БД vs Объектно-ориентированные БД

• Разработка веб-сайтов

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

Предыстория

Я занимаюсь проектированием и разработкой баз данных уже порядка 6 лет. За это время у меня сложилось свое видение как лучше подходить к проектированию, как выбирать архитектуру системы, какие существуют особенности при нормализации и денормализации реляционных БД, как оптимизировать те или иные конструкции и запросы. В первый год работы я пришел к тому, что не хочу заниматься рутиной по написанию одних и тех же запросов. В результате я написал свой генератор хранимых процедур, который по структуре БД генерировал большинство рутинных запросов (если будет интересно, то могу написать статью на эту тему). Затем этот генератор эволюционировал из года в год, и, в итоге, я пришел к необходимости хранить объекты, как они есть, чтобы не заморачиваться переводом объектной модели в реляционную структуру. Т.е. фактически я пришел к генерации некой ORM надстройки. Конечно, Вы можете сказать, что уже создано достаточное количество качественных ORM надстроек и объектно-реляционных БД, которые можно успешно использовать (и я с Вами соглашусь, но с некоторыми оговорками). Но и это меня не устроило. И я решил пойти дальше.

Влияние ORM

По моему скромному мнению использование ORM надстроек только тормозит развитие ООБД. Постараюсь пояснить это достаточно спорное утверждение. Я не считаю, что ORM это зло, но и абсолютным добром она тоже не является. Технология ORM несомненно сыграла (да и сейчас играет) важную роль в развитии средств разработки, она показала, что программист на самом деле может и не заботиться о логике хранения данных. Однако здесь, как и везде есть свои «НО».

Использование ORM несомненно ускоряет разработку продукта, снижает трудозатраты и бла-бла-бла. Однако, любая ORM это некая прослойка, которая всегда будет работать медленнее, нежели прямая работа (я тут отнюдь не призываю перенести все вызовы SQL запросов в приложение – везде должна быть золотая середина). Наличие ORM позволяет разработчикам не особо задумываться о работе СУБД (и они-таки не задумываются в большистве своем), что влечет за собой, мягко говоря, не совсем оптимальную работу приложения под нагрузкой. Для оптимизации приходится лезть руками в прослойку и настраивать запросы так, чтобы они стали работать быстрее, приходится лезть в базу данных и перенастраивать индексы и таблицы. Таким образом, для оптимальной работы приложения необходимо приложить больше усилий, нежели когда ORM отсутствует. В итоге мы сокращаем затраты на разработку и ускоряем выпуск первой версии продукта, но усложняем процесс оптимизации.

Однако об оптимизации никто не думает в момент написания первой (а зачастую и второй, и третьей) версии продукта. Для большинства контор сейчас главным фактором является не качество, а скорость разработки. Оно и понятно: изначально заказчик хочет получить продукт как можно раньше, затратив минимум денег. И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п. Разработчик часто руководствуется восточной мудростью: А там уже либо ишак сдохнет, либо султан, либо сам Ходжа . Но, если никто не сдох, то вот тут-то разработчик и начинает искать узкие места, выдирает из ORM автоматически сгенерированные запросы, переписывает их руками, перестраивает индексы в таблицах БД и тратит на это и подобную оптимизацию еще уйму времени и сил.

Что-то меня понесло в сторону. Надеюсь, я достаточно понятно изложил свою позицию относительно ORM. Давайте вернемся к сравнению (или, если кому угодно - противостоянию) реляционных и объектно-ориентированных БД.

Реляционные БД vs ООБД

Не смотря на огромную популярность парадигмы ООП в программировании, в технологии разработки баз данных эта парадигма пока не особо популярна. И тому есть как объективные, так и субъективные причины.

• Популярность. Под реляционные базы создано множество замечательных продуктов, которые необходимо поддерживать и развивать. В эти продукты уже вложены большие деньги и заказчики готовы еще вкладывать деньги в их развитие. Напротив, с использованием ООБД разработано сравнительно мало серьезных коммерческих продуктов, существует мало мощных ООСУБД.
• Язык запросов и его стандартизация. Еще в далеком 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Для объектно-ориентированных баз данных пока стандарта языка запросов нет. Сейчас среди разработчиков даже нет единого мнения о том, что этот язык запросов должен делать, не говоря уже о том, как он это должен делать.
• Математический аппарат. Для реляционных БД в свое время Эдгар Кодд заложил фундамент математического аппарата реляционной алгебры. Этот мат. аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных, доказывает их оптимальность (либо из него видно, где надо оптимизировать). С другой стороны для ООБД нет такого аппарата, даже не смотря на то, что работы в этой области ведутся с 80-х годов. Таким образом, в ООБД пока нет строгих терминов, таких как декартово произведение, отношение и т.д.
• Проблема хранения данных и методов. В реляционных БД хранятся только голые данные. Что с ними будет делать приложение, зависит уже от приложения. В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта). Здесь так же нет единого мнения, как ООБД должна осуществлять хранение объектов и как разработчик должен эти объекты разрабатывать и проектировать. Здесь же возникает и проблема хранения иерархии объектов, хранение абстрактных классов и т.п.

Выводы и перспективы

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

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

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