Объектно-ориентированные базы данных: достижения и проблемы. Использование баз данных и информационных систем Отсутствие средств обеспечения запросов

06.04.2004 Сиха Багуи

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

Разработка систем объектно-ориентированных баз данных (так называемые технологии баз данных пятого поколения) началась в середине 80-х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех приложений обработки данных, которые характерны для систем реляционных баз данных (технология баз данных четвертого поколения). Попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование (computer aided design, CAD); автоматизированное производство (computer aided manufacturing, CAM); технология программирования; системы, основанные на знаниях, и мультимедийные системы, обнажили ограничения систем реляционных баз данных (РБД) . В условиях, когда появилось новое поколение приложений баз данных, возникли потребности, которые лучшим образом удовлетворялись при применении объектно-ориентированных баз данных (ООБД).

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

В настоящее время на рынке представлено свыше 25 систем ООБД. Среди них - система GemStone компании Servio, ONTOS компании Ontos, ObjectStore компании Object Design и многие другие . Кроме того, системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft, Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов появились еще во второй половине 80-х годов, и сегодня, по прошествии почти полутора десятилетий разработки они все еще не вступили в пору зрелости; в этом - одна из причин того, что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД. Среди современных ООБД почти нет полностью оперившихся систем, сопоставимых с современными системами реляционных баз данных. Обсудим основные достижения и проблемы, связанные с нынешним состоянием ООБД.

Модель ООБД

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

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

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

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

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

Достоинства модели ООБД

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

Определение пользовательских абстракций

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

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

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

Облегченное проектирование некоторых связей

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

Отсутствие потребности в определяемых пользователями ключах

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

Наличие предикатов сравнения

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

1. Равенство объектов на основе их идентичности. Два объекта, S1 и S2 равны, если они являются одним и тем же объектом (т.е. имеют один и тот же идентификатор объекта).
2. Равенство объектов на основе значений. Это можно определить в два захода - (a) два примитивных объекта равны, если имеют одно и то же значение; (b) два не примитивных объекта равны, если они имеют одинаковое число свойств, и для каждого свойства pi объекта S1 существует свойство pj объекта S2, равное ему по значению.
3. Равенство свойств на основе значений.
4. Равенство свойств на основе их идентичности.

Меньшая потребность в соединениях

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

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

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

Выигрыш в производительности

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

1. В ООБД значение атрибута объекта X, доменом которого является другой объект Y, - это идентификатор объекта Y. Следовательно, если приложение уже извлекло объект X и теперь хотело бы извлечь объект Y, то СУБД может извлечь объект Y, отыскав его идентификатор. Если этот идентификатор представляет собой физический адрес объекта, то данный объект может быть извлечен непосредственно; если же идентификатор является логическим адресом, то объект путем нахождения соответствующего элемента хэш-таблицы (в предположении, что в системе поддерживается хэш-таблица, отображающая идентификатор объекта в физический адрес). В РБД это могло бы не получиться так просто, поскольку в РБД не поддерживаются идентификаторы объектов.
2. Вторая особенность ООБД, обеспечивающая выигрыш в производительности, состоит в том, что в большинстве ООБД при загрузке объекта в память хранимые в этом объекте идентификаторы объектов преобразуются в указатели по памяти. Поскольку в РБД не хранятся идентификаторы объектов, в них невозможно сохранять указатели по памяти на другие кортежи. Отсутствие возможности навигации по объектам, содержащимся в памяти, является принципиальным свойством РБД, и вытекающее из этого снижение производительности не может быть компенсировано простым увеличением объема буферной памяти. Так что при выполнении приложений, которые предполагают многократную навигацию по загруженным в память связанным объектам, ООБД могут существенно превзойти РБД по производительности .
3. Кроме того, даже если ООБД не проиндексированы, может оказаться удобным выполнять произвольные запросы, соответствующие структуре объектов, путем последовательного сканирования, т.е. использовать ссылочные пути между объектами. Когда запрос формулируется в направлении, не поддерживаемом ссылками, этот запрос будет обрабатываться путем последовательного сканирования . Однако запросы, формулируемые на основании таких связей объектов, которые не моделируются напрямую с помощью ссылок, выполняются неэффективно.

Поддержка версий и длительных транзакций

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

Объектная алгебра

Объектная алгебра не столь подробно разработана и не является столь же зрелой, как реляционная алгебра. Но как бы то ни было, такая алгебра существует, и в ней определяются пять фундаментальных операций, сохраняющих объекты: union, difference, select, generate и map . На основе этих фундаментальных операций могут быть определены другие операции, например, intersection. Правила преобразований для логической оптимизации выражений объектной алгебры с сохранением эквивалентности выводятся в и . В то время как операции union, difference и map производят, главным образом, отображение «один к одному», операции select и generate производят отображение «один ко многим». Сохранение объектов означает, что алгебраические операции возвращают объекты, принадлежащие к ранее определенным классам базы данных, и не создают новых объектов. Оператор union возвращает объекты, содержащиеся во множестве P или во множестве Q, или в обоих множествах. Оператор difference возвращает набор объектов, принадлежащих множеству P, но не множеству Q. select возвращает подмножество введенного множества. generate генерирует объекты из тех, что принадлежат входному множеству. map возвращает множество объектов, образующихся в результате каждого применения последовательности методов .

Недостатки модели ООБД

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

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

Отсутствие интероперабельности между РБД и ООБД

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

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

Недостаточность средств для оптимизации запросов

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

1. Возможность определения пользователями новых типов и классов с помощью наследования и облегчает, и осложняет оптимизацию запросов. Примером, в котором эта возможность помогает оптимизации, может служить запрос, включающий пересечение множеств Employees («сотрудники») и Supervisors («инспекторы»). Если Employee является суперклассом класса Supervisor, то оптимизатор может исходить из того, что Supervisors является собственным подмножеством Employees и упростить процедуру пересечения множеств. Пример, в котором дополнительные типы данных ограничивают возможности оптимизации, может служить объединение множеств Students и Employees; суперклассом для обоих классов является класс Person. Если бы мы захотели найти всех инспекторов студентов и служащих, мы бы сначала произвели объединение, а применили бы supervisor() .
2. Запросы могут базироваться на операциях над коллекциями, но виды оптимизации, затрагивающие множества (или мультимножества, или списки и т.п.), нужно сочетать с оптимизацией над типами объектов, содержащихся в этих множествах. Объектно-ориентированный оптимизатор запросов должен быть в состоянии применять процедуры оптимизации, характерные для данных типов, а также процедуры оптимизации, учитывающие связи между объектами разных типов .
3. Сложность обработки запросов в ООБД усугубляется наличием сложных объектов, методов и инкапсуляции. Сложные объекты порождают путевые выражения, которые усложняют обработку запросов. Создание индексов для путевых выражений, особенно при наличии в выражениях произвольных методов, усложняет обработку запросов. Проблема еще более осложняется, если методы обладают побочными эффектами. Еще одна проблема, связанная с путевыми выражениями, состоит в том, что они навязывают порядок вызовов методов путевого выражения, и этот порядок может быть весьма неэффективным. Например, путевое выражение Orders.part.name лучше вычислять справа налево, если имеется много заказов (Orders) и мало деталей (Parts), но если деталей много, а заказов мало - выражение лучше вычислять слева направо. Кроме того, иногда путевые выражения более эффективно обрабатываются с использованием Join. Рассмотрим, например, запрос с путевым выражением s.comp.name, где s принадлежит множеству Students (студенты). Могло бы оказаться более эффективно (если число компаний, comp, невелико) сначала вычислить название (Name) для каждой компании (Company) и сохранить результат в кортеже. Тогда вычисление выражения от студента до названия компании включало бы соединение множества Students с множеством кортежей путем сопоставления свойства comp класса student со значением атрибута Company некоторого кортежа.
4. В языках запросов к ООБД поддерживается использование вложенных структур, которые опять-таки могут существенно усложнить процесс оптимизации, поскольку превращают его из локальной проблемы в проблему глобальную, поскольку требуется глобальное знание всего выражения запроса.
5. Когда объекты обладают идентифицируемостью, возникает вопрос, а что же понимается под равенством двух объектов . Этот вопрос переносится в язык, где операции сравнения по равенству используются в предикатах, и где необходимо принимать решение о создании новых объектов при выполнении запроса. Оптимизатор объектно-ориентированных моделей должен быть в состоянии решать проблемы, связанные с созданием новых объектов и с альтернативными определениями равенства.

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

Отсутствие стандартной алгебры запросов

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

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

Отсутствие средств обеспечения запросов

В большинстве ООБД не хватает средств обеспечения запросов . В тех же немногих системах, где имеются достаточные соответствующие средства, язык запросов не совместим с ANSI SQL. Среди этих средств обеспечения запросов нет вложенных подзапросов, запросов с множествами (union, intersection, difference), агрегатных функций и GROUP BY, соединения нескольких классов - возможностей, полностью поддерживаемых в РБД .

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

Отсутствие поддержки представлений

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

Проблемы с безопасностью

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

В некоторых системах ООБД пользователи должны явным образом устанавливать и снимать блокировки. Системы РБД автоматически устанавливают и снимают блокировки при обработке пользовательских запросов и операторов обновления.

Отсутствие поддержки динамических изменений определений классов

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

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

Ограниченная поддержка ограничений целостности

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

Ограниченные возможности настройки производительности

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

Недостаточная поддержка сложных объектов

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

Ограниченная интеграция с объектно-ориентированными системами программирования

Трудно переписывать объектно-ориентированные программы для управления стабильными данными. Здесь возникает ряд проблем: конфликты по именам; необходимость переделывать иерархии классов; склонность ООБД к перегрузке системных операций .

Ограниченный выигрыш в производительности

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

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

***

Из-за указанных слабостей ООБД не смогли оправдать возлагавшихся на них ожиданий: обеспечить все важные средства, желательные для целевых приложений. Применительно к большинству современных систем термин «ООБД» используется неправильно. Почти все современные ООБД - не столько системы баз данных, сколько системы стабильного хранения данных для некоторого объектно-ориентированного языка программирования . Так что, хотя объектно-ориентированная модель данных во многих отношениях богаче реляционной модели, объектно-ориентированная модель еще не вполне вступила в период зрелости. На сегодняшний день недостатков в системах ООБД явно больше, чем достоинств.

Литература

1. S. Abiteboul, A. Bonner, «Objects and views». ACM SIGMOD Int. Conf. On Management of Data, 1991.
2. M. Atkinson, et al., «Object-Oriented Database System Manifesto». Building an Object-Oriented Database System: The Story of O2. Morgan Kaufman, 1992.
3. F. Bancilhon, «Object oriented database systems». 7th ACM SIGART/SIGMOD Conf., 1988.
4. J. Banerjee, et al., «Data model issues for object oriented applications». ACM Trans. On Office Information Systems, Jan 1987.
5. J. Banerjee, W. Kim, K.C. Kim, «Queries in object oriented databases». IEEE Data Engineering Conf., Feb. 1988.
6. D. Beech, «Foundation for evolution and relational to object databases». Proc. Extended Data Base Technology, Mar. 1988.
7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, «Object-Oriented Query Languages: Notion and Issues». IEEE Transactions on Knowledge and Data Engineering, Mar. 1992.
8. A.W. Brown, Object-Oriented Databases, Applications in Software Engineering. New York: McGraw-Hill, 1991.
9. R.G.G. Cattell, Object Data Management, Object-Oriented and Extended Relational Database Systems. Addison-Wesley, 1991.
10. M. Cherniack, «Form(ers) over Function(s): KOLA Query Algebra». Technical Report, Brown University, Dec. 1995.
11. S. Cluet, et al., «Reloop, Algebra based query language for an object-oriented database system». 1st Int. Conf. On Deductive and Object Oriented Databases, Dec. 1989.
12. I.F. Cruz, DOODLE: Visual language for object-oriented databases. ACM SIGMOD Int. Conf. On Management of Data, 1992.
13. U. Dayal, «Queries and views in object-oriented data model». 2nd Int. Work. On Database Programming Languages, June 1989.
14. K.A. Dittrich, K.R. Dittrich, «Where Object-Oriented DBMSs Should Do Better: A Critique Based on Early Experiences». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
15. U. Erlingsson, «Object-Qriented Query Optimization», unpublished manuscript.
16. L. Fegaras, D. Maier, «Towards an Effective Calculus for Object Query Languages». ACM SIGMOD Int. Conf. on Management of Data, San Jose, California, May 1995.
17. L. Fegaras, D. Maier, T. Sheard, «Specifying Rule-based Query Optimizers in a Reflective Framework». 3rd Int. Conf. on Deductive and Object-Oriented Databases, Phoenix, Arizona, Dec. 1993.
18. S. Heiler, S. Zdonik, «Object Views: Extending the vision». 6th Int. Conf. On Data Engineering, 1990.
19. J.G. Hughes, Object-Oriented Databases. New York: Prentice-Hall, 1991.
20. S. Khoshafian, «Insight Into Object-Oriented Databases». Information and Software Technology, Apr. 1990.
21. S. Khoshafian, Object-Oriented Databases, New York: John Wiley & Sons, 1993.
22. S. Khoshafian, G. Copeland, «Object identity». 1st Int. Conf. On Object-Oriented Programming Systems, Languages, and Applications, Oct. 1986.
23. W. Kim, «Foundation for object-oriented databases». MCC Tech. Rep., N. ACA-ST-248-88, Aug. 1988.
24. W. Kim, Introduction to Object-Oriented Databases. MIT Press, 1991.
25. W. Kim, «Object-Oriented Database Systems: Promises, Reality, and Future». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
26. T.W. Leung, et al, «Aqua Data Model and Algebra». Technical Report CS-93-09, Brown University, Mar. 1993.
27. G. Mitchell, S.B. Zdonik, U. Dayal, «Object-Oriented Query Optimization - What?s the Problem?» Technical Report CS-91-41, Brown University, June 1991.
28. E.A. Rudensteiner, «Multiview: Methodology for supporting multiple views in object-oriented databases». 18th Int. Conf. On Very Large Databases, 1992.
29. M. Scholl, H. Schek, «Relational object model». 3rd Int. Conf. On Database Theory, LNCS, vol. 470, Springer Verlag, 1990.
30. P.G. Selinger, et al, «Access path selection in a relational database management system». ACM SIGMOD Int. Conf. On Management of Data, 1979.
31. M. Stefik, D.G. Bobrow, «Object-oriented programming: Themes and variations». The AI Mag., Jan. 1986.
32. M. Stonebraker, et al, «Third-Generation Data Base System Manifesto». Committee for Advanced DBMS Function, University of California, Berkeley, 1990.
33. D.D. Straube, M.T. Ozsu, «Queries and query processing in object-oriented database systems». ACM Transactions on Information Systems, Oct. 1990.
34. D.D. Straube, M.T. Ozsu, «Execution Plan Generation for Object-Oriented Data Model». 2nd Int. Conf. on Deductive and Object-Oriented Databases, Munich, Germany, Dec. 1991.
35. S.Y.W. Su, M. Guo, H. Lam, «Association Algebra: Mathematical Foundation for Object-Oriented Databases». IEEE Transactions on Knowledge and Data Engineering, Oct. 1993.
36. S.B. Zdonik, D. Maier, eds., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
37. S.B. Zdonik, P. Wegner, «Language and Methodology for Object-Oriented Database Environments». Hawaii Int. Conf. on System Sciences, Jan. 1986.

Сиха Багуи ([email protected]) - лектор факультета компьютерных наук университета Западной Флориды. Соавтор трех книг, посвященных базам данных: Learning SQL: A Step-by-Step Guide Using Oracle, Learning SQL: A Step-by-Step Guide Using Access (Addison Wesley) и Database Design Using Entity Relationship Diagrams (CRC Press).

Translated from «Achievements and Weaknesses of Object-Oriented Databases» by Sikha Bagui in Journal of Object Technology (JOT), vol. 2, no. 4, July-August 2003, pages 29-41. Translated into Russian for Otkrytye Systemy under special permission of the original publisher. Copyright JOT, 2003. Original article at http://www.jot.fm/issues/issue_2003_07/column2 .

От редактора перевода

ООБД - зрелость или упадок?

Сергей Кузнецов

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

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

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

Конечно же, в многочисленных источниках использовалась разная терминология, и в этом отношении их обзор обладает исключительной пестротой. Кроме того, многие из статей достаточно сложны с технической точки зрения, и их цитирование без обеспечения контекста только затрудняет понимание. Наиболее яркий пример - подраздел про разработку объектной алгебры. Первые три «фундаментальные» операции - union, difference, select - интуитивно понятны (хотя в действительности у авторов оригинальной статьи допускается не очень очевидный вариант выборки в форме полусоединения), но две последние - generate и map - являются сложно определяемыми и неочевидными операциями.

Хочу отметить еще одну странную особенность статьи Багуи. До 2001 года существовал международный консорциум Object Data Management Group, который опубликовал три версии предложений по стандартизации объектно-ориентированной модели данных; последняя версия - ODMG 3.0 была опубликована в 2000 году . Это единственный документ, в котором предлагается сравнительно согласованная терминология и, в некоторой степени, объектно-ориентированная модель данных. Жаль, что Багуи не пользуется этим материалом.

Заметим, что в журнале «СУБД» публиковались статья, посвященная первому варианту стандарта, ODMG-93 . Краткий обзор стандарта ODMG 3.0 можно найти в . Также можно рекомендовать перевод Манифеста систем объектно-ориентированных баз данных и очень симпатичный обзор технологии ООБД .

Литература

1. The Object Data Standard: ODMG 3.0. R.G.G. Cattel, D.K. Barry, eds., Morgan Kauffmann, 2000.
2. Л.А. Калиниченко, . // СУБД, № 1, 1996.
3. С.Д. Кузнецов. «Три манифеста баз данных: ретроспектива и перспективы». Доклад на конференции «Базы данных и информационные технологии XXI века», Москва, сентябрь 2003, http://www.citforum.ru/database/articles/manifests .
4. М. Аткинсон и др., // СУБД, № 4, 1995.
5. Арк Андреев, Дмитрий Березкин, Роман Самарев, . // Открытые системы, № 3, 2001.

Объектно-ориентированные базы данных: достижения и проблемы

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

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

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

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

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

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

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

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

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

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

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

Объекты и значения могут быть именованными. С именованием объекта или значения связана долговременность его хранения (persistency): любые именованные объекты или значения долговременны; любые объект или значение, входящие как часть в другой именованный объект или значение, долговременны.

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

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

В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.

Поддерживается предопределенный класс "Оbject", являющийся корнем решетки классов; любой другой класс является неявным наследником класса "Object" и наследует предопределенные методы ("is_same", "is_value_equal" и т.д.).

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

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

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

Стандартная ООМ описана в рекомендациях стандарта ODMG-93 (Object Database Management Group – группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

Структура ОО БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).

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

Пример логической структуры ОО БД библиотечного дела приведен на рис. 3.14. Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор .

Рис.3.14. Логическая структурабазы данныхбиблиотечного дела

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

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к ООМ БД.

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

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объекта типа КАТАЛОГ, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми – 00015.

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

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

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

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

Рис.3.15. Фрагмент базы данных с объектом-целью

Вновь обратимся к задаче Заказы, представленной в виде реляционной модели данных на рис. 3.8, и рассмотрим ее в терминах объектно-ориентированной базы данных. Всего в примере три класса: «Клиенты », «Заказы » и «Товары ». Объектами класса «Клиенты » являются конкретные клиенты; свойства класса - № клиента, Имя клиента Город, Статус и т.п. Методы класса – «Создать заказ », «Оплатить счет » и т.п. Метод – это некоторая операция, которую можно применить к объекту; метод – это то, что должен делать объект. Класс, соответствующий таблице «Сведения о заказе », не требуется. Данные таблицы могут быть частью класса «Заказы ». Наличие в классе «Клиенты » метода «Создать заказ » приводит к взаимодействию с объектами классов «Заказы » и «Товары ». При этом пользователю не надо знать об этом взаимодействии объектов. Пользователь лишь обращается к объекту «Заказы » и использует метод «Создать заказ ». Факт воздействия на другие базы данных может быть скрыт от пользователя. Если метод «Создать заказ », в свою очередь, обращается к методу «Проверить кредитоспособность клиента », то этот факт также может быть скрыт от пользователя. В реляционных базах данных для выполнения тех же функций требуется писать процедуры на языке Visual Basic for Application (VBA).

В 90-е годы существовали экспериментальные прототипы ОО систем управления базами данных. В настоящее время такие систем получили широкое распространение. В частности, к ним относятся следующие СУБД: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (научно-производственный центр «Интелтек Плюс»), а также Iris, Orion и Postgres.

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

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

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

Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.

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

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

Наиболее широкое применение объектно-ориентированные базы данных нашли в таких областях, как системы автоматизированного конструирования/производства (CAD/CAM), системы автоматизированной разработки программного обеспечения (CASE), системы управления составными документами, т.е. в областях не традиционных для баз данных. Примерами объектно-ориентированных СУБД являются – POET, Jasmine, Versant, Iris , Orion.

2.2.4.Реляционная модель данных

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

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

Рис.4. Таблица реляционной БД.

У каждого столбца есть свое имя. Например, в таблице «Товар на складе» (рис. 5.) имена полей такие: Идентификатор , Товар , Название группы , Группа , Единица измерения , Цена закупочная , Цена реализации , Наличие на складе .

Рис. 5. Таблица «Товар на Складе»

Все значения в одном столбце имеют один тип. Таким образом, поля – это различные характеристики (иногда говорят – атрибуты) объекта. Значения полей в одной строке относятся к одному объекту, а различные поля отличаются именами.

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

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

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

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

Рис.6. Пример использование внешнего ключа

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

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

Для работы с реляционными базами данных в настоящее время обычно используется язык структурированных запросов (Structured Query Language - SQL). Это язык, применяемый для создания, модификации и управления данными. Язык SQL не является алгоритмическим языком программирования. Это информационно-логический язык, он основывается на реляционной алгебре и подразделяется на три части:

· операторы определения данных;

· операторы манипуляции данными (Insert, Select, Update, Delete);

· операторы определения доступа к данным.

В 1986 году язык SQL был принят в качестве стандарта ANSI (Американский Национальный Институт Стандартов) языков реляционной базы данных. Сегодня данная база рассматривается в качестве стандарта для современных информационных систем.

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

Достоинствами реляционной модели являются:

Простота и доступность понимания конечным пользователем - единственной информационной конструкцией является таблица;

При проектировании реляционной БД применяются строгие правила, базирующие на математическом аппарате;

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

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

Недостатками реляционной модели являются:

Относительно низкая скорость доступа и большой объем внешней памяти;

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

Далеко не всегда предметную область можно представить в виде совокупности таблиц.

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

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

Автоматизированное проектирование;

Автоматизированное производство;

Автоматизированная разработка программного обеспечения;

Офисные информационные системы;

Мультимедиа системы;

Геоинформационные системы;

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

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

Построение ООМД исходит из предположения о том, что предметную область можно описать совокупностью объектов. Каждый объект представляет собой уникально идентифицируе­мую сущность, которая содержит атрибуты, описывающие состо­яние объектов «реального мира», и связанные с ними действия. Текущее состояние объекта описывается одним или несколькими атрибутами, которые могут быть простыми или сложными. Простой атрибут может иметь примитивный тип (например, целое число, строка и т. д.) и принимать литеральное значение. Состав­ной атрибут может содержать коллекции и/или ссылки. Ссылоч­ный атрибут представляет собой связь между объектами.

Ключевым свойством объекта является уникальность его Идентификации. Поэтому у каждого объекта в объектно-ориентированной системе должен быть свой идентификатор.

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

Все объекты являются инкапсулированными, т. е. пред­ставление или внутренняя структура объекта остаются скрыты­ми от пользователя. Вместо этого пользователю известно только, что данный объект может выполнять некоторые функции. Так, для объекта СКЛАД могут применяться такие методы как ПРИНЯТЬ_ТОВАР, ВЫДАТЬ_TOBAP и т. д. Преимущество инкап­суляции состоит в том, что она позволяет изменять внутреннее представление объектов, не переделывая приложений, в которых используются эти объекты. Иначе говоря, инкапсуляция подра­зумевает независимость данных.

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

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

В некоторых объектно-ориентированных системах класс также является объектом и обладает собственными атрибутами и методами, которые называются атрибутами класса и метода­ми класса.

Важными понятиями ООП служат иерархия классов и ие­рархия контейнеров .

Иерархия классов подразумевает под собой возможность наличия у каждого класса, называемого в таком случае супер­классом, своего подкласса. В качестве примера можно привести следующую цепочку: все программисты какого-либо предприя­тия являются его сотрудниками, следовательно, каждый про­граммист, который в рамках ООМД является объектом класса ПРОГРАММИСТЫ, он является также и сотрудником, кото­рый, в свою очередь, является объектом класса СОТРУДНИКИ. Таким образом, ПРОГРАММИСТЫ будут подклассом, СО­ТРУДНИКИ - суперклассом. Но программисты могут также де­литься на системных и прикладных. Следовательно, ПРОГРАМ­МИСТЫ будут суперклассом к подклассам СИС_ПРОГРАМ-МИСТЫ и ПРИКЛ_ПРОГРАММИСТЫ. Продолжая эту цепочку далее, мы получим иерархию классов, при которой каж­дый объект подкласса наследует экземпляры переменных и мето­ды соответствующего суперкласса.

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

Наследование экземпляров переменных называется струк­турным наследованием , наследование методов - поведенческим наследованием , а способность использовать один и тот же метод для разных классов или, скорее, применять разные методы с од­ним и тем же именем для разных классов называется полимор­физмом .

Объектно-ориентированной архитектуре присущ также и другой тип иерархии - иерархия контейнеров . Он состоит в том, что некоторые объекты могут концептуально содержаться внут­ри других. Так, объект класса ОТДЕЛ должен содержать общедо­ступную переменную НАЧАЛЬНИК, являющуюся ссылкой на соответствующий начальнику отдела объект класса СОТРУД­НИКИ, а также должен содержать ссылку на совокупность ссы­лок на объекты, соответствующие работающим в данном отделе сотрудникам.

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

Пользователь и объект взаимодействуют посредством со­общений. В ответ на каждое сообщение система выполняет соот­ветствующий метод.

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

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

В ООМД могут быть реализованы не только традиционные связи, но и связи, обусловленные наследованием.

Связь типа один-к-одному (1: 1) между объектами А и В реализуется путем добавления ссылочного атрибута на объект В в объект А и (для поддержания ссылочной целостности) ссылоч­ного атрибута на объект А в объект В.

Связь типа один-ко-многим (1: М) между объектами А и В реализуется путем добавления в объект А ссылочного атрибута на объект В и атрибута, содержащего набор ссылок на объект А, в объект В (например, в объект А добавляется ссылочный атрибут В{ОID2, OID3...}, и в экземпляры объекта В с OID2, OID3,... до­бавляется ссылочный атрибут А: OID1.

Связь типа многие-ко-многим (М: N) между объектами А и В реализуется путем добавления в каждый объект атрибута, со­держащего набор ссылок.

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

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

Рассмотрим, как реализуются в ООМД такие компоненты, как ограничения целостности и операции над данными.

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

Специфика ООМД диктуется и спецификой объекта. Она проявляется в необходимости группировки объектов в классы. Каждый объект входит в тот или иной класс в зависимости от за­дачи, причем один объект может принадлежать сразу нескольким классам (например, семейству ПРОГРАММИСТЫ и ВЫСОКОПЛАЧИВАЕМЫЕ). Другой спецификой объекта является то, что он может «перебегать» из одного класса (подкласса) в дру­гой. Так, СИСТЕМНЫЙ ПРОГРАММИСТ может стать со вре­менем ПРИКЛАДНЫМ. Таким образом, иерархия классов не является аналогом иерархической модели, как это могло пока­заться ранее, но требует от системы способности изменять распо­ложение каждого объекта внутри иерархии классов, например пе­ремещаться «вверх» или «вниз» внутри данной иерархии. Но воз­можен и более сложный процесс - система должна обеспечивать возможность объекта быть присоединенным (отсоединенным) к произвольной вершине иерархии в любой момент времени.

Важную роль в ООМД играют ограничения целостности связей. Чтобы связи в объектно-ориентированной МД могли рабо­тать, идентификаторы объектов по обе стороны связи должны соответствовать друг другу. Например, если имеется связь между СЛУЖАЩИМИ и их ДЕТЬМИ, то должна быть какая-то гаран­тия, что при вставке объекта, описывающего ребенка, в объект, ото­бражающий служащего, идентификатор последнего добавляется в соответствующий объект. Такой вид целостности связей, в чем-то аналогичный ссылочной целостности в реляционной модели дан­ных, устанавливается с помощью обратных связей. Чтобы гаранти­ровать целостность связей, проектировщику предоставляется спе­циальная синтаксическая конструкция, необходимая для задания места нахождения обратного идентификатора объекта. Обязан­ность задавать ограничения целостности связей (как и ссылочной целостности в реляционной БД) лежит на проектировщике.

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

Проблемами стандартизации технологии объектных БД за­нимается группа ODMG (Object Database Management Groop). Она разработала объектную модель (версия ODMG 2.0 была при­нята в сентябре 1997 г.), которая определяет стандартную модель для семантики объектов БД. Эта модель имеет большое значе­ние, поскольку определяет встроенную семантику, которую по­нимает и может реализовать объектно-ориентированная СУБД (ООСУБД). Структура библиотек и приложений, использую­щих эту семантику, должна быть переносимой среди различных ООСУБД, которые поддерживают данную объектную МД. Ос­новными компонентами архитектуры ODMG являются: объект­ная модель (ОМ), язык определения объектов (ODL), язык объ­ектных запросов (OQL), а также способность связывания с язы­ками C++, Java и Smalltalk.

Объектная модель данных в соответствии со стандартом ODMG 2.0 характеризуется следующими свойствами:

Базовыми конструктивными элементами являются объек­ты и литералы. Каждый объект имеет уникальный идентифика­тор. Литерал не имеет собственного идентификатора и не может существовать отдельно как объект. Литералы всегда встроены в объекты, и на них нельзя ссылаться индивидуально;

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

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

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

Определение базы данных хранится в схеме, записанной на языке определения объектов Object Definition Language (ODL). База данных хранит объекты, позволяя их совместно использо­вать различным пользователям и приложениям.

СУБД, базирующиеся на ООМД, называют объектно-ори­ентированными СУБД (ООСУБД). Эти СУБД относят к СУБД третьего поколения* (* Историю развития моделей хранения данных часто разбивают на три этапа (поколения): первое поколение (конец 1960 - начало 70-х го­дов) - иерархическая и сетевая модели; второе поколение (приблизительно 1970-1980-е годы) - реляционная модель; третье поколение (1980-е годы - начало 2000-х годов) - объектно-ориентированные модели.) .

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

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

Система должна обрабатывать большие объемы неструкту­рированных или имеющих сложную структуру данных;

Приложение будет осуществлять предсказуемый доступ к данным, поэтому навигационная природа объектно-ориентированных БД не будет являться существенным недостатком;

Потребность в незапланированных запросах ограничена;

Структура хранимых данных имеет иерархическую или сходную природу.

В настоящий момент на рынке ПО присутствует множест­во объектно-ориентирован-ных СУБД. В табл. 10.6 представлены некоторые из коммерческих систем данного класса.

Таблица 10.6

Современные коммерческие ООСУБД,

их фирмы-производители и области применения

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

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

Немалое значение для ООСУБД имеет возможность пере­мещения объектов из одной базы в другую.

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

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

Как видно из рис. 10.17, в структуре существуют различные классы, ориентированные на обработку документальной инфор­мации - TOdbText, TOdbDocument, TODBTextDocument и др. Каждый документ представлен отдельным объектом. Таким об­разом обеспечивается естественность хранения документов. Од­ной из важнейших операций является поиск документов по за­просу. Для большинства классов реализована возможность поис­ка объектов по значению определенного ключа. Для класса TOdbText реализована возможность формирования поискового запроса по фразе, записанной на естественном языке.

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

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

41. Особенности проектирования прикладной ИС. Фазы развития ИС. (Тема 11, стр. 100-103).

11.1.3. Особенности системного проектирования прикладной ИС

При построении (выборе, адаптации) информационной системы можно использовать две основные концепции, два основных подхода (третья концепция - их комбинация):

1. ориентация на проблемы, которые необходимо решать с помощью этой информационной системы, т.е. проблемно-ориентированный подход (или индуктивный подход);

2. ориентация на технологию, которая доступна (актуализируема) в данной системе, среде, т.е. технологически-ориентированный подход (или дедуктивный подход).

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

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

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

При этом обе концепции построения информационной системы зависят друг от друга: внедрение новых технологий изменяет решаемые проблемы, а изменение решаемых проблем - приводит к необходимости внедрения новых технологий; и то, и другое влияет на принимаемые решения.

Системное проектирование (разработка) и использование любой прикладной (корпоративной) информационной системы должно пройти следующий жизненный цикл информационной системы:

– предпроектный анализ (опыт создания других аналогичных систем, прототипов, отличия и особенности разрабатываемой системы и др.), анализ внешних проявлений системы;

– внутрисистемный анализ, внутренний анализ (анализ подсистем системы);

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

– определение критериев адекватности, эффективности и устойчивости (надежности);

– функциональное описание подсистем системы (описание моделей, алгоритмов функционирования подсистем);

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

– "сборка" и тестирование системы - реализация полноценных функциональных подсистем и критериев, оценка модели по сформулированным критериям;

– функционирование системы;

– определение целей дальнейшего развития системы и ее приложений;

– сопровождение системы - уточнение, модификация, расширение возможностей системы в режиме ее функционирования (с целью ее эволюционирования).

Эти этапы - основные для информационного реинжиниринга систем.

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

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

Функциональные связи - каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса;

Информационные связи - подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);

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

Общность структуры разных предприятий позволяет сформулировать некоторые единые принципы построения корпоративных информационных систем.

В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения:

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

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

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

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

Можно выделить следующие основные отличительные признаки проекта как объекта управления:

Изменчивость - целенаправленный перевод системы из существующего в некоторое

желаемое состояние, описываемое в терминах целей проекта;

Ограниченность конечной цели;

Ограниченность продолжительности;

Ограниченность бюджета;

Ограниченность требуемых ресурсов;

Новизна для предприятия, для которого реализуется проект;

Комплексность - наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;

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

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

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

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

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).

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

Можно выделить следующие фазы развития информационной системы:

Формирование концепции;

Разработка технического задания;

Проектирование;

Изготовление;

Ввод системы в эксплуатацию.

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

Концептуальная фаза

Формирование идеи, постановку целей;

Формирование ключевой команды проекта;

Изучение мотивации и требований заказчика и других участников;

Сбор исходных данных и анализ существующего состояния;

Определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;

Сравнительную оценку альтернатив;

Представление предложений, их экспертизу и утверждение.

Разработка технического предложения

Разработка основного содержания проекта, базовой структуры проекта;

Разработка и утверждение технического задания;

Планирование, декомпозиция базовой структурной модели проекта;

Составление сметы и бюджета проекта, определение потребности в ресурсах;

Разработка календарных планов и укрупненных графиков работ;

Подписание контракта с заказчиком;

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

Проектирование

На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:

Выполнение базовых проектных работ;

Разработка частных технических заданий;

Выполнение концептуального проектирования;

Составление технических спецификаций и инструкций;

Представление проектной разработки, экспертиза и утверждение.

Разработка

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

Выполнение работ по разработке программного обеспечения;

Выполнение подготовки к внедрению системы;

Контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

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

Комплексные испытания;

42. Концепция жизненного цикла ИС. (Тема 11, стр. 103-105).