В современных условиях для сохранения конкурентоспособности компании вынуждены перестраивать свою работу очень часто - примерно раз в два года. Следовательно, каждые два года необходимо обновлять и корпоративную информационную систему. В традиционных технологиях жизненный цикл создания корпоративных систем составляет тоже примерно два года, то есть к моменту сдачи в эксплуатацию может оказаться, что такая система уже не нужна. ERwin – уникальное инструментальное средство, позволяющее в несколько раз уменьшить сроки создания или модернизации информационных систем.
Зачастую разработчики программного обеспечения сталкиваются с ситуацией, когда информационная система нужна “уже вчера”. В таких условиях эффективность инструментальных средств является критическим фактором, гарантирующим успешное окончание проекта по созданию корпоративных систем. Особенно важно обеспечить применение такого набора инструментов, который бы гарантировал поддержку всех стадий жизненного цикла разработки программного обеспечения – от анализа до внедрения. Линейка CASE-средств фирмы Computer Associates обеспечивает единый технологический процесс анализа, разработки и внедрения сложных информационных систем. В предыдущей статье автора (Мир ПК №5, стр. 42-47, 1999 г.) был рассмотрен инструмент анализа и реорганизации бизнес-процессов BPwin. С его помощью аналитик может проанализировать существующее положение дел, выявить и ликвидировать недостатки , построить идеальную функциональную модель деятельности предприятия. Такая модель может быть основой для построения корпоративной информационной системы, представляя собой спецификацию для проектирования корпоративной базы данных (далее БД) и создания кода клиентских частей. ERwin является инструментом, позволяющим логично продолжить разработку информационной системы в рамках единой технологической цепочки, позволяя создать тесно интегрированную с функциональной моделью модель данных, сгенерировать соответствующую структуру на любом из поддерживаемых им серверов БД (а таковых более двадцати) и автоматически сгенерировать код клиентского приложения на PowerBuilder или Visual Basic. ERwin поддерживает три нотации: IDEF1X, IE (Information Engineering) для моделирования баз данных и Dimensional для моделирования хранилищ данных.
Проектирование и генерирование баз данных
БД являются ядром современных
информационных систем, поэтому качественная модель данных напрямую определяет их будущую
функциональность и производительность.
ERwin имеет два уровня представления модели – логический и физический.
Логическая модель – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (на физическом – таблицы и колонки). Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Для создания логической модели ERwin имеет ряд инструментов, позволяющих при помощи простых манипуляций мышью быстро создавать довольно сложные модели. Удобная палитра инструментов дает возможность легко добавлять в модель сущности и атрибуты, определять различные типы связей между ними. Подробная информация по каждому объекту вводится посредством целого семейства редакторов, вызываемых из контекстных меню. На логическом уровне можно определить домены атрибутов (абстрактный тип атрибута, область значений и т.д.), на основе которого в дальнейшем будет сгенерирован конкретный тип соответствующей колонки.
ERwin обладает мощными презентационными возможностями, позволяющими представить модель данных на разных уровнях и в разной степени детализации:
Рис.1. Фрагмент логической модели на уровне атрибутов с отображением малых иконок. Видны инструменты создания модели – палитра инструментов ERwin Toolbox и палитра доменов Independent Attribute Browser.
Многие СУБД имеют ограничение на именование объектов, например, ограничение на длину имени таблицы, запрет использования специальных символов – пробел (это означает, что нельзя назвать таблицу предложением – только одним словом) или запрет на использование кириллицы и т.п. Кроме того, проектировщики баз данных нередко злоупотребляют “техническими” наименованиями типа “M45” или “CUSTOMER_12”, в результате структуру данных могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы – имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице “CUST_A12” может соответствовать сущность “Постоянный клиент”. Такое соответствие позволяет лучше документировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.
Физическая модель фактически является отображением системного каталога БД. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. ERwin поддерживает большинство ведущих наиболее популярных реляционных СУБД, а также настольные системы: Access, FoxPro, dBase, Clipper и Paradox. При смене СУБД ERwin автоматически преобразует одну физическую модель в другую. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL – скрипт , то есть набор команд на языке SQL (рис.2).
Рис.2. Фрагмент физической модели и SQL-скрипта для СУБД Oracle 8.
Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного католога или SQL – скрипту воссоздать физическую и логическую модели данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и, затем, сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных от одного сервера на другой. Например, можно перенести структуру данных с Oracle на Infornix (или наоборот) или перенести структуру dbf – файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент – серверной системе.
Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах и т.д. Для этого ERwin имеет целый набор соответствующих редакторов. На основе ключей, описанных на уровне логической модели (поддерживаются первичные, внешние, альтернативные ключи и инверсионные входы) ERwin генерирует индексы. Могут быть также сгенерированы индексы, заданные дополнительно на уровне физической модели. Для поддержки целостности БД задаются правила ссылочной целостности, а также триггеры и хранимые процедуры, которые представляют собой программный код на SQL и хранятся на сервере. Для создания триггеров и процедур ERwin имеет специальный набор инструментов - шаблоны и библиотеку макросов, содержащую наиболее часто используемые конструкции. Язык шаблонов универсален, но при генерации схемы БД триггеры и процедуры генерируются на языке выбранной СУБД. Кроме того, ERwin позволяет создавать физические объекты, специфические для каждой СУБД, например, для Oracle это могут быть табличные пространства, базы данных и сегменты отката.
После создания физической модели данных ERwin позволяет рассчитать приблизительный размер базы данных в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации информационной системы.
Проектирование хранилищ данных
Зачастую информационные системы масштаба предприятия или корпорации представляют собой довольно пеструю картину. Исторически складывается, что вследствие политики слияния или слабого управления филиалы компании и дочерние предприятия пользуются своими, несовместимыми с системой головной компании информационными системами. Например, если в головной компании может эксплуатироваться реляционная база данных (ORACLE, MS SQLServer, Informix и др), то в дочерней - другая реляционная СУБД, настольная БД на основе dbf –файлов или вовсе система, использующая в качестве источника текстовые файлы. Такие системы называются гетерогенными, и обработка информации в них может представлять серьезную проблему.
Одной из основных задач, решаемых в корпоративных информационных системах, является предоставление аналитической информации необходимой для менеджеров, принимающих решения. Для поддержки принятия решения необходим не один заранее подготовленный отчет, а серия разнообразных отчетов, причем менеджер не всегда представляет, какой именно отчет понадобится ему в следующие полчаса. Организовать выполнение таких отчетов в гетерогенной среде крайне сложно. Хотя существуют генераторы отчетов (например, Crystal Reports) и мониторы транзакций, способные объединить гетерогенные данные, необходимо понимать, что их работа во-первых, не сможет обеспечить выполнение отчетов в реальном масштабе времени (что необходимо для поддержки принятия решения – менеджер не может ждать час – данные нужны ему немедленно), а во-вторых, выполнение таких отчетов может замедлить текущую работу серверов баз данных.
Решением проблемы может быть размещение всех данных в единой специализированной базе данных, называемой хранилищем данных (Data Warehouse), рис.3 .
Рис.3. Пример гетерогенной информационной системы, включающей хранилище данных.
Хранилища данных представляют собой специализированные базы данных, предназначенные для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов. Хранилища данных позволяют разгрузить промышленные базы данных, и тем самым, позволяют пользователям более эффективно и быстро извлекать необходимую информацию. Они могут быть включены в общую корпоративную сеть, по которой в хранилище по заранее определенному расписанию, как правило, в период наименьшей загрузки сети и серверов сбрасывается накопленная за день или за неделю информация. Поскольку данные меняются редко, то к хранилищу данных не предъявляются жесткие требования, которые обычно предъявляются к реляционным базам данных - отсутствие аномалий при выполнении операций обновления или удаления и избыточности хранения информации. Зато предъявляются требования, необходимые для эффективного выполнения аналитических запросов.
1) Хотя реализовать хранилище данных можно на любом сервере БД, существуют специализированные сервера, специально предназначенные для поддержки хранилищ данных. ERwin поддерживает генерацию схемы БД для двух таких серверов – Teradata и Red Brick.
2) При проектировании хранилища необходимо создавать подробные спецификации для всех, в том числе самых разных типов источников данных. ERwin поддерживает на физическом уровне прямое и обратное проектирование объектов с самыми разными типами БД, поэтому является идеальным CASE-средством для работы с гетерогенными информационными системами.
3) Для эффективного проектирования хранилищ данных ERwin использует размерную (Dimensional) модель. Dimensional - методология проектирования, специально предназначенная для разработки хранилищ данных.
Моделирование объектов хранилищ сходно с моделированием связей и сущностей для реляционной модели, но отличается целями. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная (Dimensional) модель ориентирована в первую очередь на выполнение сложных запросов к БД.
В размерном моделировании принят стандарт модели, называемый схемой звезда (star schema), которая обеспечивает высокую скорость выполнения запроса посредством денормализации и разделения данных. Невозможно создать универсальную структуру данных, обеспечивающую высокую производительность при выполнении любого аналитического запроса. Поэтому схема звезда строится так, чтобы обеспечить наивысшую производительность при выполнении одного самого важного запроса, либо для группы похожих запросов. Схема звезда обычно содержит одну большую таблицу, называемую таблицей факта (fact table ), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенными c таблицей факта в виде звезды радиальными связями (рис.4).
Рис.4. Схема звезда.
Таблица факта является центральной таблицей в схеме звезда. Она может состоять из миллионов строк и содержать суммирующие или фактические данные, которые могут помочь ответить на требуемые вопросы. Она соединяет данные, которые хранились бы во многих таблицах традиционных реляционных баз данных. Таблицы размерности имеют меньшее количество строк, чем таблицы факта и содержат описательную информацию. Эти таблицы позволяют пользователю быстро переходить от таблицы факта к дополнительной информации. ERwin поддерживает использование вторичных таблиц размерности, называемых консольными (outrigger) таблицами, хотя они не требуются для схемы звезда.
Для каждой таблицы ERwin позволяет задать шесть типов правил манипулирования данными: обновление (Refresh), дополнение (Append), резервное копирование (Backup), восстановление (Recovery), архивирование (Archiving) и очистка (Purge). На основе этих правил в дальнейшем может быть сгенерирована спецификация на манипулирование данными хранилища.
При проектировании хранилища данных важно определить источник данных (для каждой колонки), метод, которым исходные данные извлекаются, преобразовываются и фильтруются прежде, чем они импортируются в хранилище данных. Хранилище данных может объединять информацию из текстовых файлов и многих баз данных, как реляционных (в том числе других БД), так и нереляционных в единую систему поддержки принятия решений. Чтобы поддерживать регулярные обновления и проверки качества данных, необходимо знать источник для каждой колонки в хранилище данных. Для документирования информации об источниках данных используется редактор Data Warehouse Source Editor . Поскольку ERwin может осуществить обратное проектирование из самых разнородных источников, имена таблиц и колонок источников данных могут быть импортированы как из баз данных , так и из других моделей ERwin. Для каждой колонки хранилища можно внести информацию об использовании источников, а так же дополнительную информацию о способах, режимах и периодичности переноса данных из источника в хранилище данных.
Интеграция
Как было указано выше, ERwin тесно интегрирован с инструментом построения функциональной модели BPwin’ом. Модель данных может быть связана с моделью процессов. Такая связь гарантирует завершенность анализа, гарантирует, что есть источник данных (Сущность) для всех потребностей данных (Работа). Связи объектов способствуют согласованности, корректности и завершенности анализа. Более того, на основе таких связей BPwin позволяет сгенерировать отчет, представляющий собой спецификацию на права доступа к данным.
Для получения качественных отчетов информация о модели данных может быть экспортирована из ERwin в специализированный генератор отчетов RPTwin, который входит в поставку как BPwin, так и ERwin. Функциональность RPTwin позволяет создавать не просто отчеты презентационного качества, что само по себе очень важно. Включение в RPTwin более сорока фукций позволяет производить сложную обработку данных, получая при этом результат, который невозможно получить средствами ERwin или BPwin.
ERwin интегрируется также с популярными средствами разработки клиентской части – Sybase PowerBuilder, Microsoft Visual Basic и Inprise Delphi, что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению. Для разных сред разработки реализована различная техника кодогенерации. Код для PowerBuilder генерируется непосредственно в среде ERwin, код для Visual Basic – с помощью add-in компонент и библиотек, подключаемых в проект Visual Basic. ERwin не поддерживает непосредственно кодогенерацию для Delphi. Код клиентского приложения для Delphi на основе модели данных ERwin можно сгенерировать с помощью MetaBASE – продукта фирмы gs-soft.
Создание современных информационных систем требует тесного взаимодействия всех участников проекта: менеджеров, бизнес и системных аналитиков, администраторов баз данных, разработчиков. Для организации совместной работы ERwin интегрирован с хранилищем моделей Computer Associates - системой Model Mart. Model Mart позволяет сохранять множество версий моделей (с последующим сравнением предыдущих и новых версий), осуществлять совместное моделирование с обеспечением разделения прав доступа и имеет встроенный механизм разрешения конфликтов, возникающих при многопользовательской работе. С его помощью можно сформировать библиотеки стандартных решений, включающие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости “сборки” больших систем.
В последние годы интенсивно развиваются объектно-ориентированные методы разработки информационных систем. В первой половине девяностых годов был предложен разработанный на основе наиболее популярных объектных методов - OMT (Rumbaudh), Booch и OOSE (Jacobsom) универсальный язык объектного проектирования – Unified Modeling Language, UML (The Unified Method, Draft Edition (0.8). Rational Software Corporation, October 1995). Наиболее известными CASE-средствами, поддерживающими язык UML, являются Paradigm Plus (Computer Associates ) и Rational Rose (Rational Software). ERwin не поддерживает UML, однако как в Paradigm Plus, так и в Rational Rose имеется возможность конвертации объектной модели в модель данных ERwin и обратно. Используя совместно с одной стороны ERwin, с другой - Paradigm Plus или Rational Rose, разработчики информационных систем имеют возможность генерировать как высокоэффективную клиентскую часть приложения на основе объектной модели, так и схему БД на любой из поддерживаемых в ERwin СУБД.
Описанные выше функциональные возможности, а также простота освоения и использования сделали ERwin его незаменимым инструментом для тысяч проектировщиков во всем мире.
ОБ АВТОРЕ
Сергей Маклаков – руководитель Учебно-консалтингового Центра Interface Ltd.
С ним можно связаться по тел. (095)135-5500, 135-2519, e-mail: mail@interface.ru
За дополнительной информацией обращайтесь в Interface Ltd.