CC BY
199
определять относительную эффективность вовлеченных средств в зависимости от числа интегрированных источников (ресурсов);
по заданной (требуемой) эффективности рассчитывать необходимое и достаточное количество элементов ресурсного комплекса;
по заданным величинам эффективностей и размерностям интегрируемых групп, составляющих планируемый ресурсный комплекс, определять эффективность интегрированного комплекса при любых алгебраических (структурных) преобразованиях над его составляющими, сводимых к четырем основным алгебраическим операциям, что позволяет оптимизировать количество вовлеченного ресурса любой природы при решении хозяйственных и социальных проблем.
УДК 681.3
ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ С ПОМОЩЬЮ CASE-СРЕДСТВ в НОТАЦИИ UML
Королев Евгений Николаевич, к.т.н., доцент, Воронежский государственный технический университет, Россия, Воронеж, korolev73@mail.ru Бескоровайная Мария Александровна, студент, Воронежский государственный технический университет, Россия, Воронеж, mariabeskor@gmail.ru Фиртыч Оксана Александровна, студент, Воронежский государственный технический университет, Россия, Воронеж, oxana. firtych@gmail. com
Введение
UML позволяет моделировать разные виды систем: чисто программные, чисто аппаратные, программно-аппаратные, смешанные, явно включающие деятельность людей и т. д. Но, помимо прочего, язык UML активно применяется для проектирования реляционных БД. Для этого используется небольшая часть языка (в основном диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных БД модельные возможности не слишком отличаются от возможностей ER-диаграмм [4].
UML изначально не предназначен для проектирования баз данных. И хоть для этих целей составлена не одна классическая нотация, в практике возникают задачи, для решения которых удобнее пользоваться одним продуктом для всех задач, начиная с этапов моделирования бизнес-процессов и заканчивая проектированием конкретных приложений. UML - это унифицированный язык моделирования, поэтому с его помощью можно представить в том числе и модели баз данных.
Реляционная модель данных в подавляющем большинстве случаев вполне достаточна для моделирования любых данных. Однако проектирование базы данных в терминах схемы отношений на практике может вызвать большие затруднения, т.к. в этой модели изначально не предусмотрены механизмы описания семантики предметной области. С этим связано появление семантических моделей данных, которые позволяют описать конкретную предметную область гораздо ближе к интуитивному пониманию и, в то же время, достаточно формальным образом.
Этап диаграммного моделирования обеспечивает следующие преимущества:
• на раннем этапе проектирования до привязки к конкретной РСУБД проектировщик может обнаружить и исправить логические огрехи проекта, руководствуясь наглядным графическим представлением концептуальной схемы;
• окончательный вид концептуальной схемы, полученной непосредственно перед переходом к формированию реляционной схемы, а может быть, и промежуточные версии концептуальной схемы должны стать часть документации целевой реляционной БД; наличие этой документации очень полезно для сопровождения и в особенности для изменения схемы БД в связи с изменившимися требованиями;
86
• при использовании CASE-средств концептуальное моделирование БД может стать частью всего процесса проектирования целевой информационной системы, что может способствовать правильной структуризации процесса, эффективности и повышению качества проекта в целом [2].
1. Концептуальная модель (описание предметной области)
Проектирование в UML начинается с создания диаграммы вариантов использования. Данная диаграмма представляет своего рода сценарий для дальнейшей работы системы. Каждый вариант использования может выражать одно из следующих воздействий:
• атомарная транзакция;
• применение системой элементов данных как внутри себя через включение, обновление, удаление, так и внешне через запросы;
• платформа для обоснования БД.
Для описания варианта использования применяется резюме, которое должно дать полное, но краткое описание сути рассматриваемого элемента диаграммы. Детали уточняются в описании, которое содержит подробное описание шагов, предпринимаемых поочередно актером и системой.
Если в варианте использования есть прямая ссылка на БД, то можно выразить шаг на языке доступа к БД. Для БД SQL это будет оператор SQL, для объектно-ориентированной БД - код C++ или команды OQL. При этом следует придавать SQL или OQL как можно более общий вид, работая только со стандартным языком.
В описании варианта использования должны быть описаны все расширения и условия, при которых они выполняются [1].
2. Реляционная модель (описание данных)
Класс в нотации UML и его типичная структура соответствуют правилам описания сущности и ее структуре в модели ER-диаграмм. Это объясняется тем, что все объектноориентированные нотации, которые лежали в основе создания UML, в свое время были разработаны на базе классических ER-диаграмм. Таким образом, дается следующее определение основной категории моделирования с помощью UML:
Класс - это описание набора объектов, разделяющий одни и те же атрибуты, операции, методы, отношения и семантику.
В UML классы объединяются в пакеты и подсистемы. Способ структурирования пакетов и подсистем является частью основного процесса объектно-ориентированной разработки системной архитектуры. При этом системная архитектура включает гораздо больше аспектов, чем требуется для проектирования БД. Необходимо представлять системную архитектуру и её интерфейс, как набор связанных между собой сущностей. В этом заключается основное отличие объектно-ориентированных методов от ER-моделирования. Необходимо рассматривать различные схемы подсистем и, следовательно, различные БД, даже если они создаются вместе в одной физической схеме. Сами БД становятся пакетами на некотором уровне, представляя общие данные, когда происходит детализация действительной структуры реализации системы.
В такой пакет можно встраивать несколько подсистем, при этом используя структуру данных повторно. Но при этом рекомендуется стремиться к минимизации числа пакетов, являющихся частью транзакции. Пакеты и подсистемы организуются на диаграмме классов самого высокого уровня, на которой нет единичных классов. А потом для каждого пакета детализуются составляющие его объекты и связи между ними.
Ошибочным является мнение, что объявление операций для классов при проектировании данных - излишне. Операции указываться должны. После при физической реализации системы можно будет отказаться от них, если не будет необходимости в создании хранимой на сервере процедуры обработки данных [1].
87
В UML предусмотрены абстрактные классы и операции, они характеризуются тем, что не имеют соответственно экземпляров и методов, и призваны выражать интерфейсы, для которых подклассы представляют переопределяющую операцию.
Несмотря на некоторые различия в терминологии ER- и UML-диаграмм, процессы преобразования диаграммы в реляционную БД в целом схожи. Но при использовании диаграммы классов следует обратить внимание на следующие моменты:
• предопределенные в классах операции должны соответствовать хранимым на сервере СУБД процедурам или же в среде СУБД должны поддерживаться функции, определяемые пользователем;
• наиболее эффективны ассоциации типа «один ко многим» или «многие ко многим». Ассоциации типа «один к одному» требуют дополнительной обработки, которая снижает эффективность;
• для технологии реляционных БД не используются ассоциации агрегации или композиции
• связи для определения реляционных таблиц следует всегда задавать двунаправленными.
• При использовании семантических диаграмм можно отметить следующие преимущества:
• при использовании наглядной концептуальной схемы (Use Case) проектировщику легче заметить и исправить логические недочеты системы;
• более полная документация за счет концептуальной схемы;
• легче вносить изменения, связанные с корректировкой требований к проекту;
• при использовании CASE-средств концептуальное моделирование БД может стать частью всего процесса проектирования целевой информационной системы, что должно способствовать правильной структуризации процесса, эффективности и повышению качества проекта в целом.
Язык UML принадлежит объектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутаннее) реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего чего угодно, то в этом языке содержится масса различных понятий, терминов и вариантов использования, избыточных с точки зрения проектирования реляционных БД. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ER-диаграммы, только с несколько другой нотацией и терминологией [4].
В практике встречаются случаи, когда удобнее использовать один инструмент разработки для всех этапов проектирования - в этом и заключается смысл CASE-средств. Для этих случаев как нельзя лучше подходит язык UML. Кроме того, возможность создания концептуальной схемы БД в среде проектирования приводит к снижению затрат на разработку. Обеспечение унифицированной полной документации и возможность исправить недочеты еще на этапе описания предметной области делают UML практически незаменимым при разработке информационных систем.
Литература
1. Мюллер, Роберт Дж. Базы данных и UML. Проектирование, - М.: Изд. «ЛОРИ», 2002.
2. Кузнецов С.Д. Концептуальное проектирование реляционных баз данных с использованием языка UML, - статья, 2003.
3. Рамбо Д., Буч Г. UML. Специальный справочник, - М.: Питер, 2002, - 656 с.
4. Электронный университет, курс «Введение в реляционные базы данных», автор: С.Д. Кузнецов, 10. Лекция: «Проектирование реляционных баз данных с использованием семантических моделей: диаграммы классов языка UML. - Электрон. дан. - Режим доступа: http://www.intuit.ru/department/database/rdbintro/10/
88
УДК 007:159.995
ПРЕДСТАВЛЕНИЕ ЗНАНИЙ В ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ БАЗЕ ДАННЫХ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ УПРАВЛЕНИЯ ФИРМОЙ1
Долятовский Валерий Анастасиевич, д.э.н., проф., заведующий кафедрой менеджмента, Ростовский государственный экономический университет, Россия, Ростов-на-Дону, dvaleri@inbox.ru Сергеенко Григорий Сергеевич, к.э.н., доцент, с.н.с., "Meridian Cons.", Чехия, Прага, grigor@mail.ru Долятовский Леонид Валерьевич, к.э.н., доцент кафедры менеджмента, Ростовский государственный экономический университет Россия, Ростов-на-Дону, ldleon@mail.ru
Гамалей Н.Ю. , аспирант, Ростовский государственный экономический университет, Россия, Ростов-
на-Дону, ngamaley@mail.ru
Ведение
Объектно-ориентированная база данных (ООБД) является важным блоком системы управления предприятием, и ее формирование должно соответствовать принципам объектноориентированного проектирования. Основным принципом построения ООБД является формализованное семантическое описание ситуаций и его отображение на действия (решения), сформулированные в форме менеджерских глаголов. Тем самым строится менеджерская грамматика адаптивного управления фирмой. Первой составляющей ООБД является словарь объектов (менеджерских существительных) и их атрибутов. Организация этого словаря представлена на рис. 1. По существу, он представляет собой классификационную таблицу, структура которой соответствует фреймовому представлению знаний и использует основное преимущество такого представления: фрейм, как структура описывает одну из единиц обработки, обладающую до некоторой степени независимостью, и может предоставлять средства, связывающие между собой эти структурные элементы.
Номер предметной области
Порядковый номер объекта в /-ой предметной области
Код Имя^объекта Атрибуты объекта
Код Имя атрибута
Прибыль Доход
Ай? Общиеиздержки
Принадлежность атрибута объектуП.
пЧ
г .
Lk+1
Порядковый номер атрибута
Рис. 1 Организация словаря менеджерских существительных
Если сравнивать фреймовую систему с традиционной программной системой, то можно сказать о снятии ограничений последовательного процесса обработки за счет того, что обрабатываемые единицы описываются в виде фреймов, которые не обязательно следуют один за другим. Этап конструирования словаря объектов и атрибутов отражает два первых этапа объектно-ориентированного проектирования. Второй составляющей ООБД является словарь менеджерских глаголов. Конструкция этого словаря включает код предметной области, наименование глагола и его содержательную структуру.
Структура словаря глаголов по наличию различных иерархических связей гораздо проще, чем словарь объектов и атрибутов. Однако по семантическому содержанию словарь
1 Статья рекомендована к опубликованию в журнале "Информационные технологии и вычислительные системы"
89
