
- •Предисловие
- •1. Модели данных
- •1.1. Введение в базы данных
- •1.1. Структура интегрированного производственного комплекса
- •1.2. Трехуровневое представление интегрированной базы данных
- •1.3. Взаимодействия с бд
- •1.2. Концептуальное (семантическое) моделирование баз данных
- •1.1 1. Концептуальная модель бд в нотации п. Чена
- •1.13. Фрагмент концептуальной модели проектной организации (idef1x)
- •1.14. Фрагмент концептуальной модели в нотации Баркера
- •1.3. Логическое моделирование данных
- •1.15. Иерархическая модель данных
- •1.16. Организация иерархической модели
- •1.17. Иерархическая модель, поддерживаемая субд инес
- •1.18. Сетевая модель данных
- •1.19 . Организация сетевой модели
- •1.20. Таблица реляционной базы данных
- •1.21. Концептуальная модель тестовой базы данных
- •1.22. Физическая модель тестовой базы данных
- •2. Системы управления базами данных
- •2.1. Функции субд
- •2.1. Организация индексов
- •2 .2. Схема выполнения запроса
- •2.2. Унифицированный язык для работы с бд sql
- •2.3. Тенденции развития субд
- •3. Автоматизированные информационные системы
- •3.1. Сетевая обработка данных
- •3.1. Варианты организации взаимодействий в архитектуре “клиент-сервер”
- •3.2. Схема с централизованными данными
- •3.3. Иерархическая схема распределения данных
- •3.4. Схема с расщепленными данными
- •3.5. Схема с разделенными данными
- •3.6. Схема с реплицированными данными
- •3.2. Виды автоматизированных информационных систем
- •3.7. Структура документальной ипс
- •3.8. Варианты организации справочников в ипс
- •3.9. Функциональная диаграмма управления движением документов в edms-системе
- •3.10. Структура корпоративной информационной системы
- •3.11. Вариант упрощенного гиперкуба для анализа поставок деталей
- •3.12. Схема типа «звезда» аналитической витрины по поставкам деталей
- •3.13. Фрагмент сформированного отчета по поставкам деталей
- •3.3. МетодЫ анализа и проектирования информационных систем
- •3.14. Изображение блока
- •3 .15. Изображение дуги
- •3.16. Варианты объединения дуг
- •3.17. Функциональный блок и интерфейсные дуги
- •3.18. Декомпозиция диаграмм
- •3.28. Диаграммы потоков данных в нотации Yourdon / De Marco
- •3.29. Диаграммы потоков данных в нотации ssadm
- •3.30. Диаграммы потоков данных в нотации Gane/Sarson
- •3.31. Контекстная dfd- диаграмма
- •3.33. Ошибка, связанная с расщеплением потоков данных
- •3.34. Ошибка, связанная с использованием циклов
- •3.35. Ошибка, связанная активацией процессов входными сигналами
- •3.36. Пример диаграммы классов
- •3.37. Пример диаграммы объектов
- •3.38. Пример диаграммы компонентов
- •3 .39. Пример диаграммы развертывания
- •153003, Г. Иваново, ул. Рабфаковская, 34
3.10. Структура корпоративной информационной системы
Хранилище данных (data warehouse)
Центральное место в КИС занимает хранилище данных. Идею хранилища данных предложил Б. Инмон (Willian H. Inmon), определяя его как предметно-ориентированные интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные в целях поддержки корпоративного управления, призванные выступать в роли единого и единственного источника истины, обеспечивающие менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и поддержки принятия решений.
В основу концепции положена идея интеграции ранее разъединенных детализированных данных из транзакционных систем оперативной обработки данных (СОД/OLTP), а также из внешних источников в целях информационной поддержки управления. Характерными чертами хранилищ являются историчность хранимых данных, наличие метаданных и ориентация на аналитическую обработку накопленной информации.
Для организации ретроспективы сведений в хранилищах поддерживается два варианта истории.
Хронологический набор событий – событийная история, которая поддерживается с помощью характеристических сущностей, в каждой записи которых существует дата, связанная с конкретным событием. В большинстве случаев транзакционные системы регистрируют именно события – отгрузку товара, выпуск продукции и т.д.
Хронологический набор изменений сущности – история информационных объектов. В этом случае хранятся все состояния объекта с датой начала и датой конца (например, история регистрационных сведений юридического лица). Обычно история объектов поддерживается с помощью дополнительной сущности – архива, куда записываются все предыдущие состояния объекта.
Ключевым понятием в концепции хранилищ являются метаданные – это электронная документация о системных и бизнес-процессах. Метаданные необходимы в связи с тем, что огромные объемы информации в хранилище создают сложности при их обработке. Посредством метаданных организуется работа инструментов поддержки принятия решений, выполняется сопровождение АИС в процессе ее жизненного цикла. Метаданные делятся на системные (генерируются и используются СУБД), операционные (отвечают за процессы загрузки информации и обработку информации посредством заданной бизнес-логики), навигационные (поддерживают возможность нерегламентированных запросов), аналитические (обеспечивают многомерный анализ данных). Метаданные часто размещаются в репозитории, который позволяет совместно использовать метаданные различными инструментами и процессами при проектировании, установке, использовании, эксплуатации и администрировании хранилища данных.
Процесс создания хранилища данных начинается с функционального моделирования бизнес-процессов, имеющих место в корпорации. При этом используется методология структурного анализа (Structured Analysis and Design – SADT). Выполняется исследование существующих информационных потоков, включая ведомственную и статистическую отчетность, структуры баз данных систем оперативной обработки информации, общесистемные справочники. Выделяются основные бизнес-понятия и бизнес-события, имеющие место в предметной области.
Хранилище организуется в виде совокупности информационных объектов, каждый из которых на метауровне СУБД представлен рядом взаимосвязанных сущностей, а на уровне метаданных хранилища – соответствующими моделями анализа накопленной информации. Событийная информация и информация, связанная с фиксацией состояний объектов, представляются структурами типа «звезда» (см. ниже), ориентированными на последующую многомерную аналитическую обработку данных. Детализированная информация, соответствующая экземплярам основных бизнес-понятий, представляется в виде многоуровневых иерархических структур (ведомственных реестров) или автономных справочников.
Основу корпоративного хранилища составляет определенная совокупность звездообразных информационных объектов. При этом консолидация информации осуществляется на основе общесистемных справочников, играющих роль измерений в многомерных аналитических моделях. Доступ к некоторым измерениям, соответствующим базовым реестрам конкретного предметного приложения, осуществляется посредством навигационных моделей.
Создание хранилища данных из независимых источников данных – многоэтапный процесс, который предусматривает извлечение данных из каждого источника, преобразование их в соответствии со схемой хранилища, очистку, возможно, агрегацию, а затем загрузку в хранилище. Для этого применяются средства ETL (Extracting, Transformating and Loading), выполняющие перечисленную последовательность операций. К представителям средств ETL можно отнести SAS Institute Multiple Engine Architecture (MEA), Microsoft Data Transformation Services (DTS), Oracle Warehouse Builder и др.
Предусмотрено несколько вариантов загрузки информации в хранилище данных. В случае использования информации систем оперативной обработки данных применяются регламентированные сценарии загрузки насосов данных (pump). Возможна также загрузка на основе подготовленных форм в формате электронных таблиц Excel или XML-документов. В ряде случаев организуются специализированные клиентские места, согласованные с метауровнем хранилища данных.
Предпочтительной является трехуровневая структура КИС:
корпоративное хранилище данных;
витрины данных для соответствующих подразделений (множество тематических баз, содержащих информацию, относящуюся либо к конкретному подразделению организации, либо к отдельному аспекту ее деятельности);
рабочие места конечных пользователей, на которых установлен аналитический инструментарий.
Витрина данных (Data Mart) – это облегченный вариант корпоративного хранилища. Развитие КИС обычно начинается с создания согласованных витрин данных по отдельным аспектам деятельности корпорации.
С учетом сложности КИС и длительности их жизненного цикла используются специализированные средства автоматизированного проектирования информационных систем (CASE-средства). Так для ведения хранилищ данных могут быть использованы, в частности, системы SAS System (SAS Institute), ERWin (Logic Works), Designer/2000 (Oracle Corp), Power Designer (Powersoft Corp) и др.
Оперативная аналитическая обработка данных (OLAP)
Структура базы данных хранилища обычно разрабатывается таким образом, чтобы максимально облегчить анализ информации. Данные должно быть удобно «раскладывать» по разным направлениям (называемым измерениями). Например, сегодня пользователь хочет посмотреть сводку поставок деталей по поставщикам, чтобы сравнить их деятельность. Завтра этому же пользователю понадобится картина изменения объема поставок деталей по месяцам, чтобы проследить динамику поставок. Структура базы данных должна обеспечивать проведение подобных типов анализа, позволяя выделять данные, соответствующие заданному набору измерений.
В основе оперативной аналитической обработки данных лежит принцип организации информации в гиперкубическую модель. Простейший трехмерный куб данных по поставкам деталей для ранее рассмотренной тестовой базы данных приведен на рис. 3.11. Каждая его ячейка соответствует «факту» – например, объему поставки детали. Вдоль одной грани куба (одного измерения) располагаются месяцы, в течение которых выполнялись отражаемые кубом поставки. Второе измерение составляют виды деталей, а третье – соответствует поставщикам. В каждой ячейке содержится объем поставки для соответствующей комбинации значений по всем трем измерениям. Следует отметить, что при заполнении куба выполнена агрегация значений по поставкам каждого месяца из тестовой базы данных.