еще раз об объектных и постреляционных базах данных
В современных условиях глобализации бизнеса, требующего резкого снижения затрат на выполнение производственных функций, мобильности персонала, возможности доступа к требуемой информации и работы с ней в любой точке мира, повышение эффективности инвестиций в информатизацию организаций и предприятий обеспечивается многими факторами, одним из которых является сокращение затрат на проектирование, разработку, реинжениринг, внедрение и управление информационными системами (ИС).
Анализ развития методов и инструментальных средств построения ИС и их влияние на продуктивность разработок показывает, что на протяжении 15-20 лет в этой области не наблюдалось качественных изменений. Качественный скачок возник лишь в последнее время при использовании в разработках CASE- технологий принципов объектно-ориентированного и постреляционного анализа, проектирования и программирования, объектно-ориентированных баз данных, принципов модульности, типизации и клонирования.
Центральное и важное место в ИС различного класса и назначения занимают базы данных, на которые возложены функции хранения, интеграции и консолидации информационных ресурсов организации. От эффективности и качества их построения во многом зависит эффективность разрабатываемых ИС. В настоящее время проводятся интенсивные работы по созданию и внедрению объектно-ориентированных баз данных (ООБД) и ИС на их основе. Популярность ООБД обуславливается рядом важных отличий и преимуществ, которые предоставляют ООБД в сравнение с традиционными (например, реляционными) БД. Отметим некоторые из них. ООБД обеспечивают инкапсуляцию логики и данных в одном объекте; поддерживают сложные типы данных и работу на более высоком уровне абстракции, что позволяет с одной стороны создавать сложные структуры данных, в т.ч. мультимедийные, а с другой - обеспечить простоту их сопровождения и развития.
Однако ООБД также имеют ряд недостатков и ограничений, среди которых в первую очередь следует отметить отсутствие развитых средств выборки и анализа данных и единой методологии проектирования ООБД.
Поэтому все чаще разработчики корпоративных ИС выбирают гибридные БД, которые поддерживают как реляционные, так и объектные механизмы работы с данными. Поскольку каждая отдельно взятая модель данных имеет как свои достоинства, так и недостатки, их совместное использование в рамках гибридной БД позволяет агрегировать преимущества, одновременно компенсируя недостатки каждой модели. Архитектуру гибридной (или постреляционной) СУБД можно сравнить с самолетом, состоящим из частей (моделей данных), которые по своей природе стремятся упасть на землю, но работая согласованно, преодолевают эту тенденцию.
Рассмотрим влияние типа выбранной БД на различных этапах жизненного цикла разработки ИС.
Начальным этапом проектирования ИС является этап моделирования предметных областей пользователей, системного анализа и структуризации информации. На данном этапе выявляются требования к структурам БД, разрабатываются спецификации информационных требований пользователей и бизнес- процессов, определяется состав хранимой в БД информации и ее структура. В результате решения задач данного этапа формируется модель предметной области и каноническая (концептуальная) структура БД, которая отражает наиболее характерные и устойчивые свойства и характеристики данных и взаимосвязей предметной области.
К основным проблемам, с которыми сталкиваются разработчики при проведении этапа моделирования, относятся сложность и трудоемкость данного процесса, невысокая достоверность анализа при большом числе элементов и связей, противоречивость и несогласованность требований пользователей, необходимость частого проведения реинжениринга бизнес-процессов обследуемой организации.
Обычно на этапе моделирования разработчики не задумываются о том, как построенная модель будет отражена в выбранной СУБД и стремятся построить модель, которые наиболее полно отражает закономерности предметных областей пользователей и свободна от различного рода конфликтов.
Существует несколько способов организации и проведения данного этапа. Среди них следует отметить:
- диаграммы декомпозиции процессов;
- потоковые диаграммы;
- IDEF-диаграммы (Integrated DEFinition, интегрированные диаграммы-описания);
- RADs-диаграммы (Role Activity Diagrams, диаграммы ролевых действий);
- стандартная системная документация;
- формализованные методы анализа и структуризации предметных областей пользователей, построения канонических структур БД; UML (Unified Modeling Language).
Каждый из представленных способов имеет свои достоинства и недостатки. Однако как показывает практика, объектно-ориентированная технология анализа и проектирования предоставляет разработчикам наиболее естественные и совершенные возможности для моделирования предметной области. Рассмотрим основные характеристики данного подхода.
В основе объектно-ориентированного подхода к моделированию предметных областей пользователей используется понятие объекта и свойств - инкапсуляция, наследование и полиморфизм:
1. Свойство инкапсуляцииозначает, что объекты наделяются некоторой структурой и обладают определенным набором операций, то есть поведением. Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь с использованием специальных методов, определяемых заданным набором операций.
2. Свойство наследованияобеспечивает возможность создавать из объектов новые объекты, которые наследуют структуру и поведение своих предшественников, добавляя к ним характеристики, отражающие их собственную индивидуальность.
3. Свойство полиморфизмаозначает, что различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, каким образом реализованы у них методы, реагирующие на сообщения.
В настоящее время существует достаточное количество инструментальных средств объектно-ориентированного анализа и моделирования, однако наиболее известным и популярным является продукт компании IBM CASE-система Rational Rose и входящих в ее состав язык моделирования UML (Unified Modeling Language).
На следующем этапе осуществляется проектирование логических структур БД. Как правило, при разработке логических структур используются эвристические методы проектирования с формальной оценкой качества принимаемых решений. Выделяются 3 группы критериев качества проекта логической структуры БД.
Критерии первой группы отражают требования поддержания и сохранения в логической структуре БД структурных и семантических свойств и особенностей данных и связей, зафиксированных в канонической структуре. Критерии первой группы связаны с ограничениями целостности, защиты БД от непротиворечивости при актуализации или избыточности представления данных.
Критерии второй группы связаны с вопросами производительности БД и характеризуют влияние логической структуры БД на временные параметры доступа и экономические показатели функционирования ИС. Существенную роль при оценке проекта по критериям данной группы играют количество обрабатываемых в единицу времени транзакций и запросов пользователей.
Критерии третьей группы отражают требования интерпретации запросов к БД возможно меньшим числом операторов языка манипулирования данными. Наиболее известными методами проектирования логических структур БД являются методы, основанные на формальном аппарате реляционной алгебры и функциональных зависимостях. При этом процесс проектирования логических структур БД сводится к следующей последовательности операций: - анализ предметной области и выделение базовых типов сущностей (как правило, для этого используется ER-диаграммы);
- нормализация типов сущностей и формирование логических записей;
- установление связей между записями.
Несмотря на формальную строгость данных методов, им присущи следующие недостатки. При построении сложных корпоративных ИС (КИС), использующих большое число информационных элементов, логические структуры БД для данных систем в виду многочисленных многозначных зависимостей между данными могут состоять из десятков и даже сотен таблиц, что делает такие БД плохо обозримыми и управляемыми. Более того, за счет разбиения объектов предметной области на плоские нормализованные отношения теряется семантика исследуемой предметной области, что усложняет сопровождение и модернизацию систем. Данные методы не позволяют также адекватно моделировать отдельные свойства данных. Для адекватного моделирования структур сложных данных пользователь должен иметь возможность определять свои типы данных, не ограничиваясь типами данных, предоставляемых определенной реляционной СУБД. Реляционная модель не позволяет также определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании данных со сложной структурой. Операции приходится задавать в конкретном приложении. Использование данных методов проектирования требует высокой квалификации проектировщиков.
ООБД обеспечивают более естественный переход от концептуальной структуры БД к логической. В отличие от реляционных БД в ООБД не происходит декомпозиции объектов, выделенных на этапе моделирования, на плоские нормализованные отношения. Объекты представляются в том же виде. ООБД определяют возможность создания и использования сложных типов данных (ADT). При этом не требуется модификации ядра ООБД и для создания нового типа необходимо унаследовать характеристики любого имеющегося типа, наиболее подходящего по своему поведению и состоянию, расширить недостающие операции и атрибуты и переопределить уже имеющиеся. Полученные объектно-ориентированные структуры обладают высокой степенью модульности, что позволяет вносить в них изменения наиболее простым и безболезненным способом. При этом изменения влияют на один класс (или связанную подсистему классов) и могут эффективно управляться и проверяться.
Рассмотрим этап разработки. Можно выделить следующие основные операции, которые встречаются в большинстве современных ИС:
1. Выборка и анализ данных.
2. Модификация данных (транзакции).
Что касается выборки данных, то здесь безусловным лидером по удобству и скорости работы является декларативный язык SQL. SQL - это наиболее простой в использовании язык, где запросы формулируются на "околочеловеческом" языке, а алгоритм поиска готовится сервером и может быть скорректирован разработчиком. Кроме того, SQL - это промышленный стандарт и он может быть эффективно использован в качестве интерфейса к другим информационным источникам. В данный момент ведутся работы по созданию языка OQL, правопреемника SQL для ООБД. Однако пока рано говорить об OQL как о промышленном стандарте и сравнивать его с SQL.
Что касается операций обновления данных. Все множество данных операций можно разделить на два класса - операции массовой загрузки данных и транзакционные данные.
По удобству повседневной модификации данных следует отметить ООБД, которые обеспечивают возможность ввода сложных данных без привязки их к разным таблицам, развитую проверку вводимых данных, двухступенчатую фиксацию и многое другое.
При определении лидера по массовой загрузке данных следуют вспомнить иерархические базы данных. Именно они обеспечивают наиболее быстрые механизмы загрузки большого объема данных, в том числе в режиме реального времени.
Таким образом, для разработки действительно эффективной ИС на разных этапах требуется совместное использование разных моделей данных. При этом в большинстве систем недопустимо дублирование и синхронизация информации в различных БД и СУБД, что повлечет существенные накладные расходы на разработку и сопровождение систем. Это обуславливает актуальность развития гибридных СУБД, которые поддерживают различные модели данных в рамках единого хранилища данных и обеспечивают механизмы для работы с данными как по объектно-ориентированному принципу, так и по реляционному и иерархическому.
Олег Сиротюк, InterSystems Corp.
Анализ развития методов и инструментальных средств построения ИС и их влияние на продуктивность разработок показывает, что на протяжении 15-20 лет в этой области не наблюдалось качественных изменений. Качественный скачок возник лишь в последнее время при использовании в разработках CASE- технологий принципов объектно-ориентированного и постреляционного анализа, проектирования и программирования, объектно-ориентированных баз данных, принципов модульности, типизации и клонирования.
Центральное и важное место в ИС различного класса и назначения занимают базы данных, на которые возложены функции хранения, интеграции и консолидации информационных ресурсов организации. От эффективности и качества их построения во многом зависит эффективность разрабатываемых ИС. В настоящее время проводятся интенсивные работы по созданию и внедрению объектно-ориентированных баз данных (ООБД) и ИС на их основе. Популярность ООБД обуславливается рядом важных отличий и преимуществ, которые предоставляют ООБД в сравнение с традиционными (например, реляционными) БД. Отметим некоторые из них. ООБД обеспечивают инкапсуляцию логики и данных в одном объекте; поддерживают сложные типы данных и работу на более высоком уровне абстракции, что позволяет с одной стороны создавать сложные структуры данных, в т.ч. мультимедийные, а с другой - обеспечить простоту их сопровождения и развития.
Однако ООБД также имеют ряд недостатков и ограничений, среди которых в первую очередь следует отметить отсутствие развитых средств выборки и анализа данных и единой методологии проектирования ООБД.
Поэтому все чаще разработчики корпоративных ИС выбирают гибридные БД, которые поддерживают как реляционные, так и объектные механизмы работы с данными. Поскольку каждая отдельно взятая модель данных имеет как свои достоинства, так и недостатки, их совместное использование в рамках гибридной БД позволяет агрегировать преимущества, одновременно компенсируя недостатки каждой модели. Архитектуру гибридной (или постреляционной) СУБД можно сравнить с самолетом, состоящим из частей (моделей данных), которые по своей природе стремятся упасть на землю, но работая согласованно, преодолевают эту тенденцию.
Рассмотрим влияние типа выбранной БД на различных этапах жизненного цикла разработки ИС.
Начальным этапом проектирования ИС является этап моделирования предметных областей пользователей, системного анализа и структуризации информации. На данном этапе выявляются требования к структурам БД, разрабатываются спецификации информационных требований пользователей и бизнес- процессов, определяется состав хранимой в БД информации и ее структура. В результате решения задач данного этапа формируется модель предметной области и каноническая (концептуальная) структура БД, которая отражает наиболее характерные и устойчивые свойства и характеристики данных и взаимосвязей предметной области.
К основным проблемам, с которыми сталкиваются разработчики при проведении этапа моделирования, относятся сложность и трудоемкость данного процесса, невысокая достоверность анализа при большом числе элементов и связей, противоречивость и несогласованность требований пользователей, необходимость частого проведения реинжениринга бизнес-процессов обследуемой организации.
Обычно на этапе моделирования разработчики не задумываются о том, как построенная модель будет отражена в выбранной СУБД и стремятся построить модель, которые наиболее полно отражает закономерности предметных областей пользователей и свободна от различного рода конфликтов.
Существует несколько способов организации и проведения данного этапа. Среди них следует отметить:
- диаграммы декомпозиции процессов;
- потоковые диаграммы;
- IDEF-диаграммы (Integrated DEFinition, интегрированные диаграммы-описания);
- RADs-диаграммы (Role Activity Diagrams, диаграммы ролевых действий);
- стандартная системная документация;
- формализованные методы анализа и структуризации предметных областей пользователей, построения канонических структур БД; UML (Unified Modeling Language).
Каждый из представленных способов имеет свои достоинства и недостатки. Однако как показывает практика, объектно-ориентированная технология анализа и проектирования предоставляет разработчикам наиболее естественные и совершенные возможности для моделирования предметной области. Рассмотрим основные характеристики данного подхода.
В основе объектно-ориентированного подхода к моделированию предметных областей пользователей используется понятие объекта и свойств - инкапсуляция, наследование и полиморфизм:
1. Свойство инкапсуляцииозначает, что объекты наделяются некоторой структурой и обладают определенным набором операций, то есть поведением. Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь с использованием специальных методов, определяемых заданным набором операций.
2. Свойство наследованияобеспечивает возможность создавать из объектов новые объекты, которые наследуют структуру и поведение своих предшественников, добавляя к ним характеристики, отражающие их собственную индивидуальность.
3. Свойство полиморфизмаозначает, что различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, каким образом реализованы у них методы, реагирующие на сообщения.
В настоящее время существует достаточное количество инструментальных средств объектно-ориентированного анализа и моделирования, однако наиболее известным и популярным является продукт компании IBM CASE-система Rational Rose и входящих в ее состав язык моделирования UML (Unified Modeling Language).
На следующем этапе осуществляется проектирование логических структур БД. Как правило, при разработке логических структур используются эвристические методы проектирования с формальной оценкой качества принимаемых решений. Выделяются 3 группы критериев качества проекта логической структуры БД.
Критерии первой группы отражают требования поддержания и сохранения в логической структуре БД структурных и семантических свойств и особенностей данных и связей, зафиксированных в канонической структуре. Критерии первой группы связаны с ограничениями целостности, защиты БД от непротиворечивости при актуализации или избыточности представления данных.
Критерии второй группы связаны с вопросами производительности БД и характеризуют влияние логической структуры БД на временные параметры доступа и экономические показатели функционирования ИС. Существенную роль при оценке проекта по критериям данной группы играют количество обрабатываемых в единицу времени транзакций и запросов пользователей.
Критерии третьей группы отражают требования интерпретации запросов к БД возможно меньшим числом операторов языка манипулирования данными. Наиболее известными методами проектирования логических структур БД являются методы, основанные на формальном аппарате реляционной алгебры и функциональных зависимостях. При этом процесс проектирования логических структур БД сводится к следующей последовательности операций: - анализ предметной области и выделение базовых типов сущностей (как правило, для этого используется ER-диаграммы);
- нормализация типов сущностей и формирование логических записей;
- установление связей между записями.
Несмотря на формальную строгость данных методов, им присущи следующие недостатки. При построении сложных корпоративных ИС (КИС), использующих большое число информационных элементов, логические структуры БД для данных систем в виду многочисленных многозначных зависимостей между данными могут состоять из десятков и даже сотен таблиц, что делает такие БД плохо обозримыми и управляемыми. Более того, за счет разбиения объектов предметной области на плоские нормализованные отношения теряется семантика исследуемой предметной области, что усложняет сопровождение и модернизацию систем. Данные методы не позволяют также адекватно моделировать отдельные свойства данных. Для адекватного моделирования структур сложных данных пользователь должен иметь возможность определять свои типы данных, не ограничиваясь типами данных, предоставляемых определенной реляционной СУБД. Реляционная модель не позволяет также определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании данных со сложной структурой. Операции приходится задавать в конкретном приложении. Использование данных методов проектирования требует высокой квалификации проектировщиков.
ООБД обеспечивают более естественный переход от концептуальной структуры БД к логической. В отличие от реляционных БД в ООБД не происходит декомпозиции объектов, выделенных на этапе моделирования, на плоские нормализованные отношения. Объекты представляются в том же виде. ООБД определяют возможность создания и использования сложных типов данных (ADT). При этом не требуется модификации ядра ООБД и для создания нового типа необходимо унаследовать характеристики любого имеющегося типа, наиболее подходящего по своему поведению и состоянию, расширить недостающие операции и атрибуты и переопределить уже имеющиеся. Полученные объектно-ориентированные структуры обладают высокой степенью модульности, что позволяет вносить в них изменения наиболее простым и безболезненным способом. При этом изменения влияют на один класс (или связанную подсистему классов) и могут эффективно управляться и проверяться.
Рассмотрим этап разработки. Можно выделить следующие основные операции, которые встречаются в большинстве современных ИС:
1. Выборка и анализ данных.
2. Модификация данных (транзакции).
Что касается выборки данных, то здесь безусловным лидером по удобству и скорости работы является декларативный язык SQL. SQL - это наиболее простой в использовании язык, где запросы формулируются на "околочеловеческом" языке, а алгоритм поиска готовится сервером и может быть скорректирован разработчиком. Кроме того, SQL - это промышленный стандарт и он может быть эффективно использован в качестве интерфейса к другим информационным источникам. В данный момент ведутся работы по созданию языка OQL, правопреемника SQL для ООБД. Однако пока рано говорить об OQL как о промышленном стандарте и сравнивать его с SQL.
Что касается операций обновления данных. Все множество данных операций можно разделить на два класса - операции массовой загрузки данных и транзакционные данные.
По удобству повседневной модификации данных следует отметить ООБД, которые обеспечивают возможность ввода сложных данных без привязки их к разным таблицам, развитую проверку вводимых данных, двухступенчатую фиксацию и многое другое.
При определении лидера по массовой загрузке данных следуют вспомнить иерархические базы данных. Именно они обеспечивают наиболее быстрые механизмы загрузки большого объема данных, в том числе в режиме реального времени.
Таким образом, для разработки действительно эффективной ИС на разных этапах требуется совместное использование разных моделей данных. При этом в большинстве систем недопустимо дублирование и синхронизация информации в различных БД и СУБД, что повлечет существенные накладные расходы на разработку и сопровождение систем. Это обуславливает актуальность развития гибридных СУБД, которые поддерживают различные модели данных в рамках единого хранилища данных и обеспечивают механизмы для работы с данными как по объектно-ориентированному принципу, так и по реляционному и иерархическому.
Олег Сиротюк, InterSystems Corp.
Сетевые решения. Статья была опубликована в номере 05 за 2005 год в рубрике технологии
