(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Пакет Sybase PowerDesigner. Объектно-реляционное моделирование.

Николай Птицын, МГТУ им. Н. Э. Баумана, каф. ИУ5

Вступление

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

  • Репозиторий является средством организации совместной работы разработчиков и обеспечивает хранение версий проекта, синхронизацию обновлений, контроль целостности;
  • Визуальные инструменты проектирования и анализа обеспечивает работу с диаграммами UML (модель приложения), ER (модель данных), DFD (модель потоков данных) и пр.
  • Прямой инжиниринг предполагает генерацию модели более низкого уровня или генерацию программного кода из рассматриваемой модели;
  • Обратный инжиниринг обеспечивает соответственно обратное преобразование из модели или программного кода в рассматриваемую модель более высокого уровня (например, из физической в концептуальную);
  • Среда быстрой разработки приложений (RAD), включающая оболочку и компилятор языка 4GL, генераторы программных кодов, мастера и пр.;
  • Система документирования;
  • Средства тестирования.

Американская компания Sybase, наряду с Oracle, Rational Software и рядом других, предлагает интегрированные инструменты, решающие перечисленные задачи. Продукт Sybase PowerDesigner является средством моделирования, проектирования, документирования и управления проектом. Пакет Enterprise Application Studio (включает Application Server , PowerBuilder и PowerJ ) дополнят PowerDesigner и содержит RAD-инструменты для разработки распределенных клиент-серверных приложений. Разумеется, PowerDesigner успешно взаимодействует с СУБД и средствами разработки приложений других производителей.

В этом обзоре мы рассмотрим объектно-реляционную методологию, реализованную в CASE-пакете Sybase PowerDesigner. Более подробно остановимся на модели "сущность-связь", так как, по мнению автора, компонент проектирования баз данных в PowerBuilder заслуживает особого внимания и может быть использован независимо от всего остального (не менее успешно, чем ERwin - популярный продукт Computer Associates ).

Объектно-реляционная парадигма

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

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

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

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

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

рис. 1 Преобразование ООМ в РМ

Сопоставим каждому классу ООМ реляционное отношение (таблицу) следующего вида:

  • Первичный ключ генерируется базой данной и становится уникальным идентификатором сохраняемого объекта;
  • Каждый атрибут класса ставиться в соотношение колонке таблицы:
    • Если атрибут класса - скаляр, то атрибут реляционного отношения представляет собой внешний ключ таблицы, описывающей класс этого атрибута. Простые атрибуты (char, int, double и т.д) могут сохраняться в таблице класса сразу вместо внешнего ключа;
    • Если атрибут класса - вектор (массив элементов), то имеем неатомарный атрибут отношения, что в явном виде не поддерживается реляционной моделью. Такая многозначная связь между атрибутом отношения и записями таблицы класса этого атрибута может быть установлена с помощью дополнительной таблицы, соответствующей "массиву элементов данного класса".
  • Наследование в явном виде не поддерживается в реляционной модели, но может быть реализовано следующим способами:
    • Атрибуты таблицы, соответствующей базовому классу (в частности, абстрактному), могут переноситься физически в таблицы наследующих классов. Как правило, эти мигрирующие атрибуты отмечаются разработчиком сразу в концептуальной модели. Объекту финального класса будет соответствовать одна запись в таблице наследующего класса. Базовая таблица вообще не включается в окончательную структуру базы данных.
    • Между базовой и наследующей таблицами может быть установлена связь 1:1. В этом случае наследуемые атрибуты хранятся в таблице, соответствующей базовому классу, а дополнительные - в таблице наследующего класса. Объекту финального класса соответствует пара записей (или большее число, в зависимости от глубины иерархии) в базовой и наследующей таблицах. Реализация механизма наследования в PowerDesigner описана ниже в разделе Модель данных PowerDesigner.

Возвращаясь к примеру из банковской сфере, поясним это преобразование. Пусть имеется абстрактный класс Базовый счет ( General Account ), который наследуется двумя другими: Карточный Счет ( Card Account ) и Сберегательный Счет ( Saving Account ). Класс Держатель ( Holder ) связан отношением Держатель счета ( Account Holder ) со структурой Базовый счет (и следовательно с двумя дочерними классами), а так же со структурой Адрес ( Address ) отношением Адрес Держателя ( Holder Address ) типа 1:М. На рис. 2 представлена диаграмма классов и связей между ними в нотации UML.

рис. 2 Диаграмма классов Держатель и Счета

Здесь в свойствах связи Держатель Счета ( Account Holder ) и Адрес Держателя ( Holder Address ) был определен класс Holder как контейнер для классов Account и Address . В результате в атрибутах Holder появились массивы ссылок accounts и addresses . Скелет класса, который выдает кодогенератор на основе модели UML имеет следующие вид (рис. 3).

рис. 3 Генерируемый код класса Holder на языке Java

С учетом того, что все классы объектов должны "запоминаться" в базе данных, преобразуем эту ООМ в реляционную модель физического уровня. Как видно на рис. 4 ассоциативные (association/composition, в терминологии RUP - aggregation) и наследственные (generalization) связи ООМ заменяются на реляционные отношения между таблицами, устанавливаемые с помощью внешних ключей (<fk>).

рис. 4 Диаграмма "сущность связь" Держатель и Счета

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

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

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

В индустрии распространенны два подхода к реализации ОРМ:

  1. Проектировщик строит ООМ и разрабатывает приложение, не заботясь о том, каким образом объекты буду "запоминаться" в базе данных. Дополнительное программное обеспечение (например, Sun JavaBlend, [7]) берет на себя прозрачное преобразование:
    1. классов в реляционное отношение и обратно (в процессе проектирования);
    2. объектов в записи таблиц и обратно (в процессе работы приложения);
  2. Состыковка объектно-ориентированной и реляционной моделей на этапе концептуального проектирования. Например, такая идеология заложена в продукте Sun EJB (Enterprise Java Beans). Забота о синхронизации структуры классов и соответствующей структуры таблиц лежит на плечах разработчика (или на его CASE-инструментах).

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

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

рис. 5 Уровни проектирования объектно-реляционного ПО

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

  1. Концептуальный уровень (включает ООМ и концептуальную модель данных (CDM);
  2. Физический уровень (привязывается к прикладному средству разработки);
  3. Уровень программного кода (исходные тексты на языке программирования);
  4. Уровень выполняемого кода (готовое приложение)

Архитектура PowerDesigner

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

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

  1. Объектно-ориентированная модель (OOM, в нотации UML),

  2. включающая диаграммы классов, сценариев и прецедентов;
  3. Концептуальная модель данных (CDM, в нотациях IE или Merise);
  4. Физическая модель данных (PDM в нотациях реляционной БД, CODASYL или IE).

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

Дополнительными компонентами PowerDesigner являются:

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

Благодаря модульной архитектуре PowerDesigner (рис. 6) могут быть выбраны различные комплектации продукта [5].

рис. 6 Архитектура PowerDesigner

Методология проектирования

В PowerDesigner реализованы концепции итерационного и структурного проектирования информационной системы:

  1. Итерационный подход предполагает разработку программного обеспечения по спиральной модели [ 1]. Каждой "виток" спирали включает часть или все этапы проекта (анализ, проектирование, разработка, тестирование, внедрение и сопровождение) и соответствует шагу к "улучшению" программного продукта - наращивание функциональных возможностей, исправление ошибок и т.д. На каждом шаге, модификация проекта может проводиться:
    1. на различных уровнях (в программном коде, OOM, CDM, PDM, …);
    2. одновременно в нескольких местах (при параллельной разработке);
При этом для обеспечения целостности всего проекта требуется:
    1. согласовать и протоколировать изменения с помощью репозитория (repository);
    2. обновлять связанные модели путем прямого/обратного инжиниринга (forward/reverse engineering) и разрешать конфликты (функции merge/compare/check models, ).
  1. Сущность структурного подхода [1] заключается в декомпозиции всего приложения на компоненты по функциональным или другим критериям. Каждый компонент в свою очередь разбивается на меньшие, и так далее до выделения бизнес-логики в методах класса. Например, структурирование приложения обеспечивается с помощью иерархического представления ООМ (вложенные диаграммы UML).

рис. 7 Средства итерационного проектирования для PDM

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

рис. 8 Схема возможных преобразований моделей
 

Исходные данные Средство разработки Описание этапа проектирования и результат
1 Требования к структуре приложения и функциональным возможностям; способы применения и пользователи PowerDesigner / модуль ООМ Проектирование концептуальной модели приложения в нотации UML - диаграмм прецедентов (use-CASE), сценариев (sequence или scenario), классов (class) и пр.

Результат: диаграмма ООМ.

2 Данные о предметной области проектируемого приложения PowerDesigner / модуль CDM Проектирование концептуальной модели данных в нотации IE: определение сущностей и установка связей между ними.

Результат: диаграмма CDM.

3 Концептуальная модель данных (CDM) PowerDesigner / модуль PDM Прямой инжиниринг CDM в физическую модель данных (PDM) и доработка последней (адаптация к выбранной СУБД, оптимизация).

Результат: диаграмма PDM.

4 Физическую модель данных (PDM) PowerDesigner / модуль PDM, СУБД Генерация сценариев DDL и передача их на СУБД (через ODBC или текстовый файл с запросами SQL).

Результат: модель данных в конкретной СУБД.

5 ОО и физическая модели данных (ООМ и PDM) PowerDesigner / модуль ООМ Объединение (merge) моделей, преобразование структур данных PDM в классы ООМ, обновление CDM (при необходимости).

Результат: дополненная диаграмма ООМ.

6 Объектно-ориентированная модель ООМ PowerDesigner / модуль ООМ Прямой инжиниринг ООМ в исходные тексты выбранного средства разработки приложения.

Результат: Шаблоны или готовый код на Java, PowerBuilder, C++, VB или другом языке программирования.

7 Исходные тексты из п 6. выбранное средство разработки (Sybase PowerBuilder,
PowerJ, Sun TDK, Microsoft VC++)
Доработка приложения с помощью средств RAD или "обычного" программирования (разработка пользовательского интерфейса, функции ввода/вывода и пр.)

Результат: дополненный программный код и готовое исполняемое приложение (на данном витке итерации)

8 Исходные тексты из п. 7 PowerDesigner / модули ООМ, CDM, PDM Обратный инжиниринг обновленных классов в диаграммы UML модели ООМ и обновление CDM, PDM, структуры БД (при необходимости)

Результат: обновленные модели ООМ, CDM, PDM.

9 Переход на следующий "виток развития" приложения - п. 1.

 
 
 

Модель данных PowerDesigner

В пакете используется двухуровневая модель данных:

  1. Концептуальная модель данных (CDM) представляет собой формализованное представление общей структуры данных информационной системы без привязки к конкретной реализации на базе СУБД. Модель строиться в виде графической схемы, называемой диаграммой "сущность-связь". Как правило, при работе на концептуальном уровне системных аналитик создает абстрактную схему данных; выделяет сущности из предметной области; устанавливает связи между ними; задает бизнес-правила работы с данными. Для построения концептуальной модели в PowerDesigner используется нотации IE (Information Engineering) и Merise.
  2. Физическая модель данных (PDM) соответствует реализации концептуальной модели на конкретной платформе (СУБД). Работая на физическом уровне, администратор БД или программист задает типы данных; проводит денормализацию; создает индексы и триггера на SQL-диалекте выбранной СУБД. Физическая модель имеет однозначное отображение в DDL-скрипт (набор инструкций на SQL). Графическая интерпретация модели может быть представлена в нотациях Relational (стрелка связи указывает на первичной ключ родительской таблицы), CODASYL (стрелка указывает на внешний ключ дочерней таблицы) и IE (аналогично CDM).

Как уже было отмечено выше, двухуровневая модель данных с возможностью прямого и обратного инжиниринга, а так же слияния моделей (merge) позволяет вести итерационную разработку структуры данных. К примеру, системный аналитик формирует концептуальную модель (CDM), которая преобразуется в физическую (PDM). Последняя дорабатывается программистом, отлаживается на СУБД. Затем проводится обратный инжиниринг для обновления CDM. Системный аналитик продолжает доработку модели на следующей итерации…

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

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

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

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

PowerDesigner поддерживает одинарное наследование двух типов:

  1. Обычное наследование, когда одной записи базовой сущности могут соответствовать наборы атрибутов всех дочерних сущностей (рис. 9);
  2. Исключающие наследование (mutually exclusive children), когда только одна дочерняя запись связана с записью базовой сущности (рис. 10).

рис. 9 Обычное наследование (а-CDM, б-PDM)

рис. 10 Исключающие наследование (а-CDM, б-PDM)

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

Настройка параметров наследования в PowerDesigner производится на концептуальном уровне (рис. 11).

рис. 11 Диалог настройки наследования
 

Заключение

Завершая обзор, отметим сильные и слабые стороны объектно-реляционной модели.

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

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

Среди недостатков модели можно выделить следующие:

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

  • (В частности, невозможно использовать объектно-ориентированный язык запросов).

Впрочем, перечисленные недостатки часто не актуальны для реальных приложений.

Ссылки по теме


 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 06.03.2001 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
DevExpress / ASP.NET Subscription
NauDoc Enterprise 10 рабочих мест
SAP Crystal Reports 2008 INTL WIN NUL License
Allround Automation PL/SQL Developer - Annual Service Contract - Single user
IBM DOMINO ENTERPRISE CLIENT ACCESS LICENSE AUTHORIZED USER ANNUAL SW SUBSCRIPTION & SUPPORT RENEWAL
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Компьютерная библиотека: книги, статьи, полезные ссылки
Windows и Office: новости и советы
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100