|
SOA или ООСУБД?
Главная /
Архив номеров / 2018 / Выпуск №05 (78) / SOA или ООСУБД?
Рубрика:
Корпоративные системы
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Анна Бучнева, Финансовый университет при Правительстве РФ
SOA или ООСУБД?
 Что выбрать для интеграции корпоративных информационных систем?
Функционирование бизнеса сегодня сильно зависит от того, как он автоматизирован. Применение компьютерных информационных систем обуславливает переход на процессно-ориентированный подход управления бизнес-процессами. И вследствие этого ERP-системы являются необходимым условием для достижения конкурентных преимуществ на рынке.
Но опираться только на применение интегрированных систем управления недостаточно для того, чтобы преуспеть. Все большую роль в достижении конкурентного преимущества в сфере информационных технологий играет не столько способ эффективного управления внутренними операциями, сколько поиск путей оптимального сотрудничества с контрагентами.
Интеграция корпоративных информационных систем на базе технологии SOA
Сегодня в сфере информационных технологий наблюдается тенденция перехода от одноплатформенных приложений к приложениям, состоящим из набора сервисов, построенных на основе сервисно-ориентированной архитектуры (SOA). Этот переход опирается на современные интеграционные технологии и заключается в принципе в том, что данные должны совместно использоваться и новыми системами, и системами от других производителей, как внутренних, так и внешних для организации.
SOA (сервисно-ориентированная архитектура) является обобщением лучших практик создания программно-информационных систем. Кроме того, SOA-приложения обеспечивают совершенно другой уровень информационной поддержки бизнеса, гибкого реагирования на происходящие в бизнесе изменения. Потребности бизнеса постоянно растут, и все реже одной информационной системе удается удовлетворить их хотя бы наполовину. Поэтому применение SOA обеспечивает создание информационной среды, в которой могут взаимодействовать самые разные системы.
Одним из обязательных условий для внедрения и построения системы на основе сервисно-ориентированной архитектуры является наличие единого хранилища сервисов, обмена сообщениями, единого формата сообщений и использование разрешенных протоколов доступа.
Применение процессно-ориентированного подхода при организации бизнеса является эффективным способом проектирования программного обеспечения. При помощи непрерывного совершенствования верно описанных бизнес-процессов компании имеют возможность повысить качество работы, добиться снижения издержек или поддержания их на том же уровне в условиях максимизации прибыли.
В соответствии с этим понятно, что для качественного описания бизнес-процессов необходима модель, которая будет содержать различные фрагменты, созданные в разных нотациях и нуждающихся в непрерывной синхронизации. Необходимо связать в единую цепочку различные компьютерные системы и людей. Эту проблему позволяют решить BPM-системы. Для таких систем важным фактором является возможность интегрирования с различными информационными системами.
Для решения данной проблемы можно использовать стандарт BPMN (Business Process Model and Notation), в котором описана нотация, дающая возможность построения моделей очень сложных бизнес-процессов таким образом, чтобы они были понятны человеку. Язык BPMN является полностью исполняемым, позволяющим осуществлять создание моделей бизнес- процессов, которые в дальнейшем будут реализовываться на базе автоматизированных систем управления процессами.
При применении стандарта BPMN удается достичь использования разных программных продуктов, необходимых для разработки модели и для ее исполнения. Необходимым при этом условием является поддержка используемым программным обеспечением стандарта BPMN.
Подходы к проектированию реляционных баз данных
Функционирование предприятия невозможно без использования баз данных. Наиболее широкое распространение на данный момент получили реляционные базы данных. В целом реляционная база данных представляет собой набор таблиц (сущностей). Они в свою очередь состоят из атрибутов (столбцов) и кортежей (строк). Между собой таблицы связаны отношениями (связями), отсюда и название «реляционные». Структуризация данных внутри базы, разбиение на более мелкие сущности, оптимизация таблиц называется нормализацией базы данных.
При создании базы данных необходимо, чтобы она достаточно полно и верно отражала существующую предметную область. Для этого производится проектирование базы данных с построением модели, релевантной предметной области.
| При применении стандарта BPMN удается достичь использования разных программных продуктов, необходимых для разработки модели и для ее исполнения |
Информационная модель предприятия строится исходя из разных методик. Одна из них – использование функциональной модели, главной целью которой является создание структуры базы данных, полностью соответствующей функциям предприятия. Для начала строится функциональная модель предприятия в нотации IDEF0 на основе всех процессов предприятия. Затем названия всех стрелок заносятся в пул – список потенциальных сущностей. Только в данном случае информационная модель будет адекватна выполняемым функциям. После этого происходит преобразование полученной функциональной модели в модель IDEF1X.
IDEF1X – методология сущность – связь, которая применяется для построения логической и физической модели реляционных баз данных. Все имеющиеся данные распределяются по сущностям (таблицам), между которыми устанавливаются связи. Сущностью является объект, содержащий несколько однотипных, но не одинаковых элементов. Связи между ними обеспечивают объединение всех сущностей и единство смоделированной предметной области.
После первоначального разбиения на сущности можно произвести декомпозицию, то есть разбиение крупных сущностей на меньшие. В данном случае декомпозиция называется нормализацией. Каждая отдельная нормальная форма заключает в себе требования к модели базы данных, и, если она им удовлетворяет, говорится, что база данных находится в этой нормальной форме.
Нормализация необходима для избавления от некоторых типов избыточности, устранения аномалий, которые могут возникнуть при удалении или обновлении, а также для упрощения применения ограничений целостности. Всего существует пять (вместе с НФ Бойса-Кодда – шесть) нормальных форм, но, как правило, не применяется более трех, так как чрезмерная детализация приводит к избыточности. Каждая последующая нормальная форма содержит в себе и предыдущую. При выявлении несоответствия отношения нормальной форме проводится декомпозиция и атрибуты, не удовлетворяющие требованиям нормальной формы, выносятся в отдельную таблицу.
Процесс проектирования СУБД по методологии сущность – связь разделяют на логическое проектирование и физическое проектирование.
На этапе логического проектирования модель, представленная в виде схемы сущность – связь (ER-диаграммы), преобразуется в логическую схему. Эта схема является основой следующего этапа – физического проектирования. Этот этап заключается в сопоставлении логической структуры и физической среды хранения. Здесь решается вопрос размещения хранимых данных в памяти и выбора эффективных методов доступа к различным компонентам базы данных.
В целях автоматизации баз данных с учетом выбранной СУБД разработаны программные средства САПР – системы автоматизированного проектирования. Наиболее известные из них это CASE-системы (computer aided software engineering) от компании Rational (Rose) и от компании Computer Associative (BPwin (создание функциональной модели), ERwin). CASE-системы поддерживают фактически все этапы жизненного цикла программного обеспечения.
Программное средство ERwin осуществляет проектирование логической и физической моделей базы данных. ERwin осуществляет прямое проектирование и обратное проектирование, то есть создает СУБД по модели и может создать модель по коду СУБД. Данная процедура называется «реинжиниринг». При этом существующая БД в виде кода автоматически представляется в виде модели на физическом и/или логическом уровнях. Это позволяет добавить сущности в модель, изменить связи, а затем провести повторное прямое проектирование.
| Одним из способов устранения недостатков реляционных баз данных является построение объектно-ориентированных баз данных |
Еще одним подходом к проектированию баз данных является создание хранилищ данных (Data Warehouse). И если в предыдущем подходе основными методами были детализация и нормализация, то при проектировании хранилищ данных, наоборот, проводится денормализация данных. То есть проводятся сбор данных из разных сущностей или таблиц и их объединение в один большой многомерный массив данных. С помощью хранилищ данных можно объединить любое количество разнородных получаемых данных и проводить оперативный анализ и управление.
Хранилища данных эффективны, так как в результате нормализации данных в реляционных СУБД создается слишком много таблиц. Поэтому выполнение сложных запросов приводит к запросам данных из очень многих таблиц и в разы увеличивает время отклика. Проектирование хранилища данных создает денормализованную структуру данных (допускаются и избыточность данных, и возможность возникновения аномалий), ориентированную в первую очередь на высокую производительность при выполнении сложных аналитических запросов. Нормализация же сделает модель хранилища излишне сложной, затрудняет ее понимание и ухудшает эффективность выполнения запроса.
Проектирование хранилищ данных также можно реализовать в инструментах ERwin. ERwin позволяет создать многомерное хранилище данных, проведя денормализацию существующей модели данных. Можно обеспечить обновление хранилища данных, установив источник данных, методы, которыми исходные данные извлекаются, преобразовываются и фильтруются, прежде чем они будут импортированы в хранилище данных. Данные можно импортировать из других моделей ERwin, из SQL-скриптов и т.д.
Подходы к проектированию ООСУБД
Но реляционные не единственные, хотя и самые распространенные базы данных. Реляционные БД имеют такие недостатки, как сложность структуры, вызванная процессом нормализации, низкая производительность во время поиска по ключу, ограниченный набор типов данных и так далее. Одним из способов устранения недостатков реляционных баз данных является построение объектно-ориентированных баз данных.
В объектно-ориентированных базах данных информация представлена в виде объектов, как, например, в объектно-ориентированных языках программирования. Каждый объект имеет свои атрибуты, свою структуру и поведение. Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Как и в языках ООП, возможно осуществление наследования одних классов другими. Также некоторые объекты могут стать атрибутами объектов других классов. Возможно переопределение атрибутов в классах с помощью перегрузок.
Важным преимуществом объектно-ориентированной структуры является отсутствие разрыва между структурой базы данных и поведенческим аспектом объектов. Объектно-ориентированная модель состоит из независимых друг от друга модулей, таким образом, можно использовать один хороший класс в самых разных базах данных. Возможность наследования вносит в программу логическую структуру, связывая классы между собой по принципу «от общего к частному».
Основными компонентами ООСУБД являются объект и литерал. Объект – это конкретный экземпляр сущности, а литерал – это конкретное значение. У объектов, как и в реляционной базе данных, есть атрибуты и связи с другими объектами. У всех объектов и литералов есть свои типы или домены.
| В Caché одновременно реализуются все три подхода для одной и той же базы данных. Разработчик может получать доступ через любой из трех видов отображения модели |
Моделирование ООСУБД, как и моделирование реляционной СУБД, принято разделять на несколько этапов: концептуальное проектирование, логическое моделирование и физическое моделирование. ООСУБД позволяют облегчить переход от одного этапа к другому благодаря структуре классы – объекты, наследованию, агрегированию объектов и т.д.
Еще одно немаловажное свойство – это постоянство существования объектов, таких как некие документы, модели сетей и т.д. В объектно-ориентированных СУБД технология объектов охватывает и концептуальную, и логическую стадии создания продукта. Представление ООБД на уровне модели данных подразделяется на структурную и поведенческую части. Первая представляет данные и их домены, вторая – функциональную составляющую, то есть функции, методы и исключения.
Структурная часть, в свою очередь, подразделяется на уровень данных и уровень схемы. Первый представляет собственно данные и соотношения между ними, второй – «искусственные» сущности, непосредственно в данные не заложенные, такие как классы, типы, роли и отношения.
Инструменты для моделирования ООСУБД
Одним из инструментов для моделирования ООСУБД является Rational Rose XDE (eXtended Development Environment) – это расширенная среда разработки программного обеспечения.
Содержит набор UML-моделирования (Unified Modeling Language). UML является языком графического описания для объектного моделирования при разработке программного обеспечения, моделирования бизнес-процессов и т.д.
Использование UML намного упрощает сложный процесс проектирования программного обеспечения. Rational Rose обеспечивает прямой и обратный инжиниринг (от модели к коду и от кода к модели).
На основе Rational Rose был разработан Rational Software Architect – среда для разработки и моделирования, которая также использует UML. Rational Software Architect поддерживает преобразование модели UML в код Java, C#, C++, SQL и т.д. и обеспечивает возможность обратного преобразования, от кода к модели. Кроме того, с его помощью можно всячески сравнивать, объединять и разъединять модели и их части.
Пример создания модели данных в Cache
InterSystems Caché – это современная система управления базами данных и среда для быстрой разработки приложений. Caché предоставляет несколько парадигм доступа к одним и тем же данным. Его можно использовать и как реляционную СУБД, и как объектно-ориентированную СУБД. То есть данная система объединяет два рассмотренных выше подхода к проектированию баз данных.
Но в основе Caché лежит не реляционная и не объектная, а более простая модель, состоящая из атомарных элементов – глобалов (глобальных переменных). Глобалы – это некие разреженные массивы без строго определенной структуры. Они не имеют схемы, допускают динамическое добавление столбцов, используют разреженное хранение значений столбцов. На уровне глобалов можно использовать при желании блокировки, транзакции, делать распределенное хранение и партиционирование. Жертвуя некоторой неточностью в определении, можно считать глобалы структурой, схожей с ассоциативным массивом в PHP или HashMap в Java.
На Caché работают огромные сложные базы данных в требовательных бизнес-отраслях. Также Caché доминирует в индустрии здравоохранения США и интенсивно используется в финансовой сфере.
В Caché реализована концепция Единой архитектуры данных. В данной архитектуре одна и та же предметная область предстает перед нами в трех разных моделях данных: в иерархической, реляционной и объектной. Вследствие этого к одним и тем же данным есть три способа доступа: прямой, реляционный и объектный.
В прямом способе доступа к данным данные хранятся в иерархической модели данных в виде глобалов. Это обеспечивает гибкость модели данных. Данные получаются напрямую – по ключу. Иерархия обеспечивается индексами: к каждому конкретному индексу привязываются его потомки. При отсутствии строгой структуры глобалов можно добавлять разные данные об объектах, то есть отсутствуют строгие ограничения, но можно установить обязательные и необязательные атрибуты, например, для однозначной идентификации глобалов.
В реляционной модели данных данные хранятся в виде сущностей и связей. И при создании иерархии глобалов система автоматически создает аналогичную реляционную модель, преобразовывая данные в таблицы и атрибуты, определяя ключи, связи и т.д.
В объектно-ориентированном отображении данных модель данных представляется в виде структуры, состоящей из объектов.
В Caché одновременно реализуются все три подхода для одной и той же базы данных. И разработчик может получать доступ через любой из трех видов отображения модели. Все данные в Caché хранятся в многомерных массивах. При этом каждое отображение одновременно соответствует одной и той же предметной области и одним и тем же данным из многомерного массива о ней, но в то же время представляет в разных отображениях, полностью соответствующих требованиям той или иной модели баз данных.
Такая структура повышает производительность в разы. В случае если проводить SQL-процедуру недостаточно производительно, то Caché переписывает код SQL на языке серверной бизнес-логики Caché ObjectScript (COS) и использует более оптимальные NoSQL-структуры данных.
Таким образом, с помощью этих двух разных подходов можно обеспечить интеграцию информационных систем.
Процессно-ориентированный подход при организации бизнеса является эффективным способом проектирования программного обеспечения, а сервисно-ориентированная технология обеспечивает интеграцию различных информационных систем, увеличивая гибкость информационной структуры предприятия и эффективность бизнеса.
Второй подход – проектирование постреляционных баз данных. Создание модели данных не только в реляционной нотации, но и в объектной и иерархической (рассмотренные на примере использования InterSystems Caché) обеспечивает многоплановость структуры данных, несколько видов представлений данных, снятие ограничений, накладываемых реляционной структурой.
- Информационные системы и технологии. Монография. /Под редакцией проф. Ю.Ф. Тельнова. – Издательство «Юнити», 2012. – С. 74-82.
- Медведев А.В. Ресурсное обеспечение в процессе разработки и реализации программ социально-экономического развития. //«Научное обозрение», № 4, 2014 г. – С.279-283.
- http://www.intersystems.com/ru/our-products/cache/cache-overview.
В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
_cover.jpg)
_cover.jpg)
_cover.jpg)
_cover.jpg)
