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

Объектно-ориентированная модель данных является расширением положений объектно-ориентированного программирования (в то время как реляционная модель возникла на основе теории множеств, именно как модель данных). Группой управления Объектно-ориентированных БД разработан стандарт ODMG-93 (Object DataBase Management Group). Этот стандарт полностью еще не реализован.

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

В качестве примера рассмотрим БД «БИБЛИОТЕКА» (рис.4.4). Для каждого объекта определены свойства, их типы и значения. В БД:

«БИБЛИОТЕКА» – родитель (предок) для «АБОНЕМЕНТ», «КАТАЛОГ», «ВЫДАЧА»;

«КАТАЛОГ» – родитель для «КНИГА».

«КНИГА» – различные объекты могут иметь одного или разных родителей. Если один и тот же родитель (один автор), то инвентарные номера разные, но isbn, УДК, название и автор – одинаковы.

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

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором определено. Так, если в «КАТАЛОГ» добавлено свойство телефон автора книги, то получаются аналогично в «АБОНЕМЕНТ» и «КАТАЛОГ». Смысл свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование ,наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа «КНИГА», являющимся потомками «КАТАЛОГ», можно приписать свойства родителя isbn, УДК, название и автор.

Полиформизм означает способность одного и того же программного кода работать с разнотипными данными. Иными словами, он означает допустимость в объектах разных типов иметь методы – процедуры и функции – с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Для БД «БИБЛИОТЕКА» это означает, что объекты класса «КНИГА», имеющие разных родителей из класса «КАТАЛОГ» может иметь разный набор свойств, т.е. программы работы с объектом класса «КНИГА» может содержать полиморфный код. В классе у метода нет тела, т. е. не определено, какие конкретно действия он должен выполнить. Каждый подкласс выполняет нужные операции. Инкапсуляция скрывает детали реализации от всех объектов вне данной иерархии.

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

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

В 90-е годы были созданы прототипы действующих объектно-ориентированных БД. Это POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Тема 5

Реляционный подход при построении информационно-логической модели: основные понятия

Реляционная модель данных. Основные понятия

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

Основные теоретические идеи реляционной модели были изложены в работах по теории отношений американского логика Чарльза Содерса Пирса (1839-1914) и немецкого логика Эрнста Шредера (1841-1902), а также американского математика Эдгара Кодда.

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

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

Основные понятия реляционной модели даны в табл. 3.1.

Объектами реляционной модели в основном являются таблицы (отношения). Целостность данных обеспечивается внешними и первичными ключами (см. п. «Реляционная целостность данных»).

Операторы в реляционной модели – это набор инструкций, которые обеспечивают выборку и манипуляцию над данными.

Таблица 5.1. Элементы реляционной модели

Термин реляционной модели	Описание
База данных (БД)	Набор таблиц и других объектов, необходимых для абстрактного представления выбранной предметной области
Схема БД	Набор заголовков таблиц, взаимосвязанных друг с другом
Отношение	Таблица – совокупность объектов реального мира, которые характеризуются общими свойствами и характеристиками (поля таблицы)
Заголовок отношения	Заголовок таблицы – названия полей (столбцов) таблицы
Тело отношения	Тело таблицы – совокупность значений для всех объектов реального мира, которая представима в виде записей таблицы (строки таблицы)
Схема отношения	Строка заголовков столбцов таблицы («шапка» таблицы)
Атрибут отношения	Наименование столбца таблицы (поле таблицы)
Кортеж отношения	Строка таблицы (запись) – однозначное представление объекта реального мира, созданное с использованием значений полей таблицы
Домен	Множество допустимых значений атрибута
Значение атрибута	Значение поля в записи (кортеже)
Первичный ключ	Один или несколько (в случае составного ключа) атрибутов, которые единственным образом определяют значение кортежа (значение строки таблицы)
Внешний ключ	Атрибут таблицы, значения которого соответствуют значениям первичного ключа в другой связанной (родительской, первичной) таблице. Внешний ключ может состоять как из одного, так и из нескольких атрибутов (составной внешний ключ). Если число атрибутов внешнего ключа меньше, чем количество атрибутов соответствующего первичного ключа, то он называется усеченным (частичным) внешним ключом
Степень (арность) отношения	Количество столбцов таблицы
Мощность отношения	Количество строк (кортежей) таблицы
Экземпляр отношения	Множество записей (кортежей) для данной таблицы (отношения). С течением времени экземпляр может изменяться. Поскольку обычная БД в текущий момент времени работает только с одной версией отношения, то такой экземпляр отношения называется текущим
Тип данных	Тип значений элементов таблицы
Базовое отношение	Отношение, содержащие один или несколько столбцов, характеризующих свойства объекта, а также первичный ключ
Производное отношение	Не является базовым отношением, т.е. не характеризует свойства объекта и используется для обеспечения связей между другими таблицами, может не содержать первичного ключа. Если первичный ключ задан, то он состоит из внешних ключей, связанных с первичными ключами базового отношения
Связь	Устанавливает взаимосвязь между совпадающими значениями в ключевых полях – первичным ключом одной таблицы и внешним ключом другой
Связь «один-к-одному» (1:1)	При использовании этого вида связи запись в одной таблице может иметь не более одной связанной с нею записи в другой таблице. В обеих таблицах ключевые поля должны быть первичными. Используется для разделения таблиц с многочисленными полями или по требованию защиты данных
Связь «один-ко-многим» (1:M)	При использовании этого вида связи каждой записи одной таблицы может соответствовать несколько записей второй, но каждой записи второй таблицы соответствует лишь одна запись первой таблицы. В первой таблицы обязательно должен быть задан первичный ключ, во второй – внешний
Связь «многие-ко-многим» (N:M)	При данном типе связи одной записи в первой таблице может соответствовать несколько записей второй таблицы, но и одной записи второй таблицы может соответствовать несколько записей первой. Уникальность ключей для таких таблиц не требуется. В процессе проектирования схемы БД такие связи преобразуют. Для этого необходимо ввести вспомогательное отношение, позволяющее заменить связь «многие-ко-многим» на две связи типа «один-ко-многим»

Структура данных реляционной модели предполагает представление предметной области рассматриваемой задачи в виде набора взаимосвязанных отношений.

В каждой связи одно отношение может выступать как основное (базовое, родительское), а другое – в роли подчиненного (производного, дочернего). Для поддержания этих связей оба отношения должны содержать набор атрибутов, по которым они связаны: в основном отношении это – первичный ключ отношения (однозначно определяет кортеж основного отношения); в подчиненном отношении должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Здесь этот набор атрибутов уже является вторичным ключом или внешним ключом, т.е. определяет множество кортежей производного отношения., связанных с единственным кортежем основного отношения.

Множество взаимосвязанных друг с другом таблиц образуют схему БД .

Итак, отношение R представляет собой двумерную таблицу, содержащую некоторые данные.

Математически N -арное отношение R – это множество декартова произведения D 1 ×D 2 ×…×D n множеств (доменов) D 1 , D 2 ,…,D n (n ≥1), необязательно различных:

R D 1 ×D 2 ×…×D n ,

где D 1 ×D 2 ×…×D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена.

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

Свойства домена :

Домен имеет уникальное имя (в пределах БД),

Определен на некотором простом типе данных или на другом домене,

Может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для этого домена,

Несет определенную смысловую нагрузку.

Основное значение доменов состоит в том, что они ограничивают сравнения: нельзя сравнивать значения из различных доменов, даже если они имею одинаковый тип данных.

Атрибут отношения представляет собой пару вида

<Имя_атрибута: Имя_домена> (либо <A:D >).

Имена атрибутов в пределах отношения уникальны. Часто имена атрибутов совпадают с именами соответствующих доменов.

Отношение R, определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – фиксированное кол-во атрибутов отношения, описывающее декартово произведение доменов, на котором задано отношение:

(<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >).

Заголовок статичен: не меняется во время работы с БД, Если в отношении изменены, добавлены, удалены атрибуты, то получается уже другое отношение. Даже при сохраненном имени.

Тело отношения содержит множество кортежей отношения.

Каждый кортеж представляет собой множество пар вида:

<Имя_атрибута: Значение атрибута>:

R (<A 1:Val 1 >, <A 2:Val 2 >, …, <A n: Val n >).

Таких, что значение Val i атрибута A i принадлежит домену D i .

Тело отношения представляет собой набор кортежей, т. Е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может из­меняться во время работы с базой данных, т. К. кортежи с те­чением времени могут изменяться, добавляться и удаляться.

Отношение обычно записывается в виде:

R (<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >),

либо сокращенно: R (A 1 , A 2 , …, A n ) или R .

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

S R = (A 1 , A 2 , …, A n ), A i D i , i = 1,..., n .

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

Например, если домен содержит числовые данные, то для него допустимы все операции сравнения: θ == {=, <>,>=,<=,<,>}. Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он также имеет полное множество операций сравнения.

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

Таким образом, для эквивалентных отношений выполняются следующие условия:

Наличие одинакового количества атрибутов;

Наличие атрибутов с одинаковыми наименованиями;

Наличие в отношениях одинаковых строк с учетом того, что порядок атрибутов может различаться;

Отношения такого рода есть различные изображения одно­го и того же отношения.

Свойства отношений непосредственно следуют из приведен­ного ранее определения отношения. В этих свойствах в ос­новном и состоят различия между отношениями реляционной модели данных и простыми таблицами:

Уникальность имени отношения. Имя одного отношения должно отличаться от имен других отношений.

Уникальность кортежей. В отношении нет одинаковых кор­тежей. Действительно, тело отношения есть множество кор­тежей и, как всякое множество, не может содержать нераз­личимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки. Каждая ячейка отношения содержит только атомарное (неделимое) значение.

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

Неупорядоченность атрибутов. Атрибуты не упорядочены (слева направо).

Уникальность имени атрибута в пределах отношения. Ка­ждый атрибут имеет уникальное имя в пределах отноше­ния, значит, порядок атрибутов не имеет значения (для сравнения - столбцы в таблице упорядочены). Это свой­ство несколько отличает отношение от математического определения отношения. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.

Атомарность значений атрибутов. Все значения атрибутов атомарны. Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения, т. Е. с каждым трии­бутом связана какая-то область значений (отдельный эле­ментарный тип), значения атрибутов берутся из одного и того же домена. Схема и кортежи отношения - множест­ва, а не списки, поэтому порядок их представления не име­ет значения. Для сравнения - в ячейки таблицы можно поместить различную информацию: массивы, структуры, другие таблицы и т. Д.

Замечание:

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

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

(О предпосылках ОРСУБД)

Эпоха объектно-реляционных баз данных началась в декабре 1996 года, когда компания Informix выпустила объектно-реляционную систему управления базами данных (ОРСУБД) Informix Universal Server. Вслед за ней в 1997 г. на рынке появились ОРСУБД компаний Oracle (Oracle8) и IBM (DB2 Universal Database). До появления ОРСУБД ведущих компаний термин «объектно-реляционная СУБД» связывался с системами Postges-Illustra и UniSQL, разработанными под руководством Майкла Стоунбрейкера и Вона Кима соответственно.

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

В соответствии с подходом UniSQL, в ОРСУБД должны поддерживаться следующие возможности:

n-мерное объектно-ориентированное моделирование;

двухмерное реляционное моделирование;

наследование;

инкапсуляция;

постоянство существования объектов (object persistence);

композиция классов;

полиморфизм;

навигационный доступ к объектам;

реляционный доступ (соединения);

непроцедурный доступ через запросы;

интерфейсы для традиционных языков третьего поколения;

интерфейсы для объектных языков третьего поколения;

интерфейсы для языков четвертого поколения;

независимое от языков хранение данных;

независимость служб баз данных от файловых систем;

поддержка оперативных служб СУБД.

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

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

В этом документе постулировались три основных принципа систем следующего поколения:

помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов и правил;

СУБД третьего поколения должны включить в себя СУБД второго поколения;

СУБД третьего поколения должны быть открыты для других подсистем.

Эти принципы развивались в тринадцати технических предложениях, включающих обеспечение развитой системы типов с поддержкой наследования и инкапсуляции. Если внимательно посмотреть на стандарты SQL:1999 и SQL:2003, а также на возможности современных версий СУБД DB2 и Oracle, то можно увидеть отражение в них всех принципов и предложений Манифеста систем баз данных третьего поколения.

Достоинства:

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

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

Недостатки:

Обширные возмодности можно так же отнести и к недостаткам так как некоторые возможности в значительной степени противоречит учению Эвгара Кодда, в котором обосновывалась целесообразность независимости базы данных от приложений. Независимость базы данных от приложений часто выглядит очень привлекательной идеей, но для ее применения разумно отказаться от многих расширений SQL.

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

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

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

В расширенных объектно-реляционных базах данных объектно-ориентированный подход используется прежде всего при построении системы таблиц. Для этого разработана модификация языка 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) не связанные напрямую с событием (обычно "привязанные к форме") и вызываемые из других программ.

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь рассмотрим, как поддержка моделей данных реализована в реальных системах управления базами данных.

Обзор современных систем управления базами данных (СУБД)

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

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

Принципиально важное свойство СУБД заключается в том, что она по-зволяет различать и поддерживать два независимых взгляда на БД: "взгляд" пользователя, воплощаемый в "логическом" представлении данных, и "взгляд" системы – "физическое" представление (организация хранимых данных).

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

Классификация СУБД

По степени универсальности СУБД делят на два класса: СУБД общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).

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

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

• не достигается требуемого быстродействия обработки данных;
• необходима работа СУБД в условиях жёстких аппаратных ограничений;
• требуется поддержка специфических функций обработки данных.

СпСУБД предназначены для решения конкретной задачи, а приемлемые параметры этого решения достигаются следующим образом:

1. за счёт знания особенностей конкретной предметной области,
2. путём сокращения функциональной полноты системы.

Создание СпСУБД – дело весьма трудоёмкое, поэтому для того, чтобы выбрать этот путь, надо иметь действительно веские основания. В дальнейшем будут рассматриваться только СУБД общего назначения.

По методам организации хранения и обработки данных СУБД делят на централизованные и распределённые . Первые работают с БД, которая физически хранится в одном месте (на одном компьютере). Это не означает, что пользователь может работать с БД только за этим же компьютером: доступ может быть удалённым (в режиме клиент–сервер). Большинство централизованных СУБД перекладывает задачу организации удалённого доступа к данным на сетевое обеспечение, выполняя только свои стандартные функции, которые усложняются за счёт одновременности доступа многих пользователей к данным.

Информационная система, построенная по принципу клиент/сервер, состоит обычно из трех основных компонентов:

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

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

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

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

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

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

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

Основные преимущества клиент/сервер по сравнению с аналогичными информационными системами заключаются в следующем.

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

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

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

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

По модели данных различают иерархические, сетевые, реляционные, объектно-реляционные и объектно-ориентированные СУБД.

Для реляционных СУБД Э.Ф. Кодд предложил и обосновал 12 правил, которым должна удовлетворять реляционная СУБД данных (РСУБД).

Правила Кодда для реляционной СУБД (РСУБД)

1. Явное представление данных (The Information Rule). Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, храня-щиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.
2. Гарантированный доступ к данным (Guaranteed Access Rule). К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца.
3. Обработка неизвестных значений (Systematic Treatment of Null Values). Неизвестные значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных – как пустые строки.
4. Динамический каталог данных, основанный на реляционной модели (Dynamic On-Line Catalog Based on the Relational Model). Каталог (или словарь-справочник) данных должен сохраняться в форме реляционных таблиц, и РСУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.
5. Полнота подмножества языка (Comprehensive Data Sublanguage Rule). РСУБД должна поддерживать единственный язык, который позволяет выполнять все операции над данными: определение данных (DDL, Data Definition Language), манипулирование данными (DML, Data Manipulation Language), управление доступом пользователей к данным, управление транзакциями.
6. Поддержка обновляемых представлений (View Updating Rule). Представление (view) – это хранимый запрос к таблицам базы данных. (Подробнее о представлениях рассказано в ). Обновляемое представление должно поддерживать все операции манипулирования дан-ными, которые поддерживают реляционные таблицы: операции вставки, модификации и удаления данных.
7. Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete). Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке таблицы, но по отношению к любому множеству строк произвольной таблицы.
8. Физическая независимость данных (Physical Data Independence). Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютера, на котором находится БД. РСУБД должна предоставлять некоторую свободу модификации способов организации базы данных в среде хранения, не вызывая необходимости внесения изменений в логическое представление данных. Это позволяет оптимизировать среду хранения данных с целью повышения эффективности системы, не затрагивая созданных прикладных программ, работающих с БД.
9. Логическая независимость данных (Logical Data Independence). Это свойство позволяет сконструировать несколько различных логических взглядов (представлений) на одни и те же данные для разных групп пользователей. При этом пользовательское представление данных может сильно отличаться не только от физической структуры их хранения, но и от концептуальной (логической) схемы данных. Оно может синтезироваться динамически на основе хранимых объектов БД в процессе обработки запросов.
10. Независимость контроля целостности (Integrity Independence). Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных. Это реализуется с помощью ограничений целостности и механизма транзакций (см. разделы 5.2 и 6.1).
11. Независимость от распределённости (Distribution Independence). База данных может быть распределённой (может находиться на нескольких компьютерах), и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияние на приложения.
12. Согласование языковых уровней (Non-Subversion Rule). Не должно быть иного средства доступа к данным, отличного от стандартного языка для работы с данными. Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и целостности, которые поддерживаются языком более высокого уровня.

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

Предыстория

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

Влияние ORM

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

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

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

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

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

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

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

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

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

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

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