Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

• 1. Реляционная модель данных
• 1.1 Реляционная модель данных. Основные определения
• 1.2 Операции над отношениями
• 2. Корпоративные информационные системы
• Список используемой литературы

1. Реляционная модель данных

1.1 Реляционная модель данных. Основные определения

В математических дисциплинах понятию «таблица» соответствует понятие «отношение» (relation). Таблица отражает объект реального мира - сущность, а каждая ее строка отражает конкретный экземпляр сущности. Каждый столбец имеет уникальное для таблицы имя. Строки не имеют имен, порядок их следования не определен, а количество логически не ограничено. Одним из основных преимуществ реляционной модели данных является однородность (каждая строка таблицы имеет один формат). Пользователь сам решает вопрос, обладают ли соответствующие сущности однородностью. Этим решается проблема пригодности модели.

Основные понятия:

* Отношение представляет собой двумерную таблицу, содержащую некоторые данные.

* Сущность - объект любой природы, данные о котором хранятся в БД. Атрибуты - свойства, характеризующие сущность (столбцы).

* Степень отношения - количество столбцов.

* Схема отношения - список имен атрибутов, например, СОТРУДНИК (№, ФИО, Год рождения, Должность, Кафедра).

* Домен - совокупность значений атрибутов отношения (тип данных).

* Кортеж - строка таблицы.

* Кардинальность (мощность) - количество строк в таблице.

* Первичный ключ - это атрибут, уникально идентифицирующий строки отношения. Первичный ключ из нескольких атрибутов называется составным. Первичный ключ не может быть полностью или частично пустым (иметь значение null). Ключи, которые можно использовать в качестве первичных, называются потенциальными или альтернативными ключами.

* Внешний ключ - это атрибут (атрибуты) одной таблицы, который может служить первичным ключом другой таблицы. Является ссылкой на первичный ключ другой таблицы.

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

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

Нормальная форма -- это своеобразный показатель уровня, или глубины, нормализации базы данных. Уровень нормализации базы данных соответствует нормальной форме, в которой она находится.

1.2 Операции над отношениями

Чтобы привести таблицу к первой нормальной форме (1НФ), нужно соблюсти два правила:

1. Атомарность или неделимость. Каждая колонка должна содержать одно неделимое значение.

2. Таблица не должна содержать повторяющихся колонок или групп данных.

Например, если таблица содержит в одном поле полный адрес человека (улица, город, почтовый код), не будет отвечать правилам 1НФ, поскольку будет содержать различные значения в одном столбце, что будет нарушением правила об атомарности. Или если бд содержит данные о фильмах и в ней есть столбцы актер1, актер2, актер3, также не будет отвечать правилам, поскольку будет иметь место повторению данных.

Начинать нормализацию следует с проверки структуры БД на совместимость с 1НФ. Все столбцы, которые не являются атомарными, должны быть разбиты на составляющие их столбцы. Если в таблице есть повторяющиеся столбцы, то им нужно выделить отдельную таблицу.

Чтобы привести таблицу к первой нормальной форме, следует:

* Найти все поля, которые содержат многосоставные части информации.

* Те данные, которые можно разбить на составные части, нужно выносить в отдельные поля.

* Вынести повторяющиеся данные в отдельную таблицу.

* Проверить, все ли таблицы подходят под условия первой нормальной формы.

Для приведения таблиц ко второй нормальной форме (2НФ), приводимые таблицы должны быть уже в 1НФ. Нормализация должна проходить по порядку.

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

Чтобы привести базу ко второй нормальной форме, надо:

* Определить все столбцы, которые не находятся в прямой зависимости от первичного ключа этой таблицы.

* Создать необходимые поля в таблицах users и forums, выделить из существующих полей или создать из новых первичные ключи.

* Для каждой таблицы нужен свой первичный ключ

* Создать внешние ключи и обозначаем их отношения между таблицами. Конечным шагом нормализации до 2НФ будет являться выделение внешних ключей для связи с ассоциированными таблицами. Первичный ключ одной таблицы должен быть внешним ключом в другой.

Подсказки:

Другой способ приведения схемы к 2НФ -- посмотреть на отношения между таблицами. Идеальный вариант -- создать все отношения вида один-к-многим. Отношения вида многие-к-многим нуждаются в реструктуризации.

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

База данных будет находиться в третьей нормальной форме, если она приведена ко второй нормальной форме и каждый не ключевой столбец независим друг от друга. Если следовать процессу нормализации правильно до этой точки, с приведением к 3НФ может и не возникнуть вопросов. Следует знать, что 3НФ нарушается, если изменив значение в одном столбце, потребуется изменение и в другом столбце.

Чтобы привести базу к третьей нормальной форме, надо:

* Определить, в каких полях каких таблиц имеется взаимозависимость, т.е. поля, которые зависят больше друг от друга, чем от ряда в целом.

* Создать соответствующие таблицы. Если есть проблемный столбец в шаге 1, создать раздельные таблицы для него.

* Создать или выделить первичные ключи. Каждая таблица должна иметь первичный ключ.

* Создать необходимые внешние ключи, которые образуют любое из отношений.

В четвертой нормальной форме дополнительное правило - необходимо исключать многозначные зависимости. Другими словами, все строки таблицы должны быть независимыми друг от друга. Наличие какой-то строки X, не должно означать, что строка Y тоже где-то есть в этой таблице.

2. Корпоративные информационные системы

реляционный модель данные система

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

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

2. Организация системы -- внутренняя упорядоченность, согласованность взаимодействия элементов системы, проявляющаяся, в частности, в ограничении разнообразия состояний элементов в рамках системы.

3. Структура системы -- состав, порядок и принципы взаимодействия элементов системы, определяющие основные свойства системы. Если отдельные элементы системы разнесены по разным уровням и внутренние связи между элементами организованы только от вышестоящих к нижестоящим уровням и наоборот, то говорят об иерархической структуре системы. Чисто иерархические структуры встречаются практически редко, поэтому, несколько расширяя это понятие, под иерархической структурой обычно понимают и такие структуры, где среди прочих связей иерархические связи имеют главенствующее значение.

4. Архитектура системы -- совокупность свойств системы, существенных для пользователя.

5. Целостность системы -- принципиальная несводимость свойств системы к сумме свойств отдельных ее элементов (эмерджентность свойств) и, в то же время, зависимость свойств каждого элемента от его места и функции внутри системы.

Информационная система -- взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели»

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение:

«Информационная система -- организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы»

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

* одиночные;

* групповые;

* корпоративные.

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

Корпоративной Информационной Системой может считаться система, автоматизирующая более 80 % подразделений предприятия.

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

Автоматизированная информационная система (АИС) представляет собой совокупность различных видов обеспечения, а также специалистов предназначена для автоматизации обработки учетно-аналитической информации. Виды обеспечения по составу, как правило, однородны для различных систем, что позволяет реализовать принцип совместимости систем в процессе их функционирования. В процессе изучения АИС как сложной системы необходимо выделять отдельные части и элементы и рассматривать особенности их использования на этапах создания и эксплуатации.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

* системы обработки транзакций;

* системы принятия решений;

* информационно-справочные системы;

* офисные информационные системы.

Список используемой литературы

1. Агальцов, В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник / В.П. Агальцов. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013.

2. Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2012.

3. Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. - СПб.: Питер, 2013.

4. Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ-Петербург, 2012.

5. Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2009.

6. Г.Н. Федорова. Информационные системы. - М.: Академия, 2013.

7. А.Е. Сатунина, Л.А. Сысоева. Управление проектом корпоративной информационной системы предприятия. - М.: Финансы и статистика, Инфра-М, 2009.

Размещено на Allbest.ru

...

Подобные документы

Сущность и характеристика типов моделей данных: иерархическая, сетевая и реляционная. Базовые понятия реляционной модели данных. Атрибуты, схема отношения базы данных. Условия целостности данных. Связи между таблицами. Общие представления о модели данных.

курсовая работа , добавлен 29.01.2011


Корпоративные информационные системы и базы данных, их использование для совершенствования и отлаживания ведения бизнеса. Классификация корпоративных информационных систем. Информационные системы класса OLTP. Оперативная аналитическая обработка.

курсовая работа , добавлен 19.01.2011


Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.

реферат , добавлен 20.12.2010


Понятие системы базы данных. Реляционная модель и ее характеристики. Целостность в реляционной модели. Реляционная алгебра. Вопросы проектирования БД. Нормальные формы отношений. Проектирование БД методом сущность-связь. ER-диаграммы. Язык SQL.

курс лекций , добавлен 03.10.2008


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

презентация , добавлен 14.10.2013


Базы данных и их использование в вычислительной технике. Особенности и основная конструктивная единица сетевой модели данных. Иерархическая модель, объекты предметной области. Реляционная модель, ее наглядность, представление данных в табличной форме.

реферат , добавлен 19.12.2011


Виды и функции системы управления базами данных Microsoft Access. Иерархическая, сетевая, реляционная модель описания баз данных. Основные понятия таблицы базы данных. Особенности создания объектов базы данных, основные формы. Доступ к Internet в Access.

контрольная работа , добавлен 08.01.2011


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

научная работа , добавлен 08.06.2010


Модели данных в управлении базами данных. Концептуальные модели данных. Роль баз данных в информационных системах. Реляционная модель данных. Определение предметной области. Построение модели базы данных для информационной системы "Домашние животные".

курсовая работа , добавлен 19.04.2011


Информационная модель в Access как некоторый упрощенный заменитель реального объекта или системы. Основные структуры, определяющие организацию данных и связей между ними; реляционная разновидность организации данных. Пример базы данных в налогообложении.

Архитектура БД

Схема КМД – это описание структуры модели данных с точки зрения администратора.

Схема ВМД – это описание внутренней или физической модели. Здесь хранится описание физического расположения данных на носителях. Схема хранит прямые указания на размещение данных в памяти (томах, дисках).

Схема КМД описывает структуру данных, записей и полей.

Все СУБД поддерживают три основных вида моделей данных:

1. Иерархическая модель. Она предполагает некоторую корневую запись. От корней идут ветви.

Не все объекты удобно описывать подобным образом. В иерархии нет связей и характерна большая избыточность информации.

2. Сетевая модель. Позволяет правильно отобразить все сложности взаимосвязей.

Модель удобна для представления связей с данными внешней среды, но менее удобна для описания в БД, что приводит к дополнительному труду пользователя по изучению навигации по связям.

3. Реляционная модель. В основе лежит математический термин Relation – отношение, а попросту – таблица. Например, прямоугольная двухмерная.

Реляционная структура данных была разработана в конце 60-х годов рядом исследо­вателей, из которых наиболее значимый вклад внес сотрудник фирмы IBM Эдгар Кодд. При реляционном подходе данные представляются в виде двумерных таблиц – наи­более естественном для человека. В то же время, для обработки данных Кодд предло­жил использовать аппарат теории множеств – объединение, пересечение, разность, де­картово произведение.

Тип данных – это понятие имеет такой же смысл, как и в языках программирования (т.е. тип данных определяет внутреннее представление в памяти компьютера и способ хранения экземпляра данных, а также множество значений, которые может принимать экземпляр данных и множество допустимых операций над данными). Все существующие современные базы данных поддерживают специальные тины данных, предназначенные для хранения данных целого типа, дробного с плавающей точкой, сим­волов и строк, календарных дат. У многих серверов баз данных реализованы и другие типы, например, у сервера Interbase имеется специальный тип данных для хранения круп­ных массивов бинарной информации (BLOB).

Домен – это потенциальное множество значений простого типа данных, он имеет сходство с подтипом данных в некоторых языках программирования. Домен определя­ется двумя элементами – типом данных и логическим выражением, которое применяется к данным. Если результат этого выражения равен значению «истина», то экземпляр дан­ных принадлежит домену.

Отношение – это двумерная таблица особого вида, состоящая из заголовка и тела.

Заголовок – это фиксированное множество атрибутов, каждый из которых опреде­лен на каком-то домене, причем между атрибутами и определяющими доменами суще­ствует взаимно однозначное соответствие.

Каждый из ат­рибутов определен на своем домене. Домен представляет собой тип данных «це­лый», а логическое условие - n>0. Заголовок является неизменным во времени, в от­личие от тела отношения. Тело отношения – это совокупность кортежей , каждый из которых представляет собой пару «атрибут - значение».

Мощностью отношения называется число его кортежей, а степенью отношения – число атрибутов.

Степень отношения является для данного отношения величиной постоянной, тогда как мощность отношения изменяется во времени. Мощность отношения еще называют кардинальным числом.

Приведенные выше понятия являются теоретическими и используются при разработ­ке языковых средств и программных систем реляционных СУБД. В повседневной работе вместо них используются их неформальные эквиваленты:

отношение – таблица;

атрибут- колонка или поле;

кортеж - запись или строка.

Таким образом, степень отношения – это число колонок в таблице, а кардинальное число - количество строк.

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

Ключ должен удовлетворять следующим требованиям:

· должен быть уникальным;

· должен быть минимальным, то есть удаление любого атрибута из ключа ведет к нарушению уникальности.

Как правило, число атрибутов в ключе меньше степени отношения, однако, в крайнем случае, ключ может содержать все атрибуты, так как комбинация всех атрибутов удов­летворяет условию уникальности. Обычно отношение имеет несколько ключей. Из всех ключей отношения (их еще называют «возможными ключами») один выбирается в ка­честве первичного ключа . При выборе первичного ключа предпочтение обычно отдается ключу с наименьшим числом атрибутов. Нецелесообразно также использовать ключи с длинными строковыми значениями.

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

Описанные в данной главе основные понятия не относятся к какой-либо конкретной реализации базы данных, а являются общими для них всех. Таким образом, эти понятия являются основой определенной общей модели, которая называется реляционной мо­делью данных.

Основатель реляционного подхода Дейт установил, что реляционная модель состо­ит из трех частей:

· структурной;

· манипуляционной;

· целостной.

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

В манипуляционной части фиксируются два базовых механизма манипулирования ре­ляционными базами - реляционная алгебра и реляционное исчисление.

Под целостной частью понимают некий механизм обеспечения не разрушаемости дан­ных. Целостная часть заключает в себе два основных требования целостности реляци­онных баз данных - целостность сущностей и целостность по ссылкам.

Требование целостности сущностей состоит в том, что любой кортеж любого от­ношения должен быть отличим от любого другого кортежа этого отношения, то есть другими словами, любое отношение должно обладать первичным ключом. Это требо­вание должно выполняться, если выполняются базовые свойства отношений.

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

1. Стандартные операции: – пересечение, – объединение, \ – разность, X – декартово произведение.

2. Специфические: проекция, ограничение, соединение, деление.

a. Объединение.

ШД ШМ ЕИ НР

R 1 (шифр детали, шифр материала, единицы измерения, норма расхода)

R 2 (ШД, ШМ, ЕИ, НР)

Необходимо найти

Предполагается присоединение множеств R 1 и R 2 . В этой операции степень сохраняется, а мощность результирующего множества

b. Пересечение.

Выделение совпадающих строк.

c. Разность.

Исключение из R 1 кортежей, совпадающих с R 2 .

d. Декартово произведение.

Здесь производится конкатенация кортежей.

Каждая строка одного множества конкатенирует с каждой строкой другого.

Даны два множества:

Декартово произведение имеет следующий вид:

В этом случае S-степень равна, а, т.е. получится 12 строк и 5 столбцов.

В статье описаны основные архитектуры хранилищ данных, рассмотрены некоторые общие принципы их построения. Подробно описаны способы представления иерархий в реляционной структуре данных.

Введение

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

Для менеджеров и аналитиков в свою очередь требовались системы, которые бы позволяли:

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

Ответом на возникшую потребность стало появление новой технологии организации баз данных – технологии хранилищ данных.

Определение и типовые архитектуры ХД

В основе концепции хранилища данных лежат две основные идеи - интеграция разъединенных детализированных данных (детализированных в том смысле, что они описывают некоторые конкретные факты, свойства, события и т.д.) в едином хранилище и разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа. Определение понятия "хранилище данных" первым дал Уильям Г. Инмон в своей монографии . В ней он определил хранилище данных как "предметно-ориентированную, интегрированную, содержащую исторические данные, не разрушаемую совокупность данных, предназначенную для поддержки принятия управленческих решений".

Концептуально модель хранилища данных можно представить в виде схемы , показанной на рисунке 1. Данные из различных источников помещаются в ХД, а описания этих данных в репозиторий метаданных. Конечный пользователь, используя различные инструменты (средства визуализации, построения отчетов, статистической обработки и т.д.) и содержимое репозитория, анализирует данные в хранилище. Результатом его деятельности является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то теоретически их выбор не должен влиять на его структуру и функции его поддержания в актуальном состоянии.

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

Виртуальное хранилище данных – это система, представляющая интерфейсы и методы доступа к регистрирующей системе, которые эмулируют работу с данными в этой системе, как с хранилищем данных. Виртуальное хранилище данных можно организовать, создав ряд представлений (view) в базе данных, либо применив специальные средства доступа, например продукты класса Desktop OLAP, к которым относится, например, BusinessObjects, Brio Enterprise и другие .

Главными достоинствами такого подхода являются:

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

	Производительности;
	Трансформации данных;
	Интеграции данных с другими источниками;
	Отсутствия истории;
	Чистоты данных;
	Зависимость от доступности основной БД;
	Зависимость от структуры основной БД.

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

Построение полноценного корпоративного хранилища данных обычно выполняется в трехуровневой архитектуре (следует отметить, что здесь под трехуровневой архитектурой понимается не структура "БД – Сервер приложений – клиент"). На первом уровне расположены разнообразные источники данных – внутренние регистрирующие системы, справочные системы, внешние источники (данные информационных агентств, макроэкономические показатели). Второй уровень содержит центральное хранилище данных, куда стекается информация от всех источников с первого уровня, и, возможно, оперативный склад данных (ОСД). Оперативный склад не содержит исторических данных и выполняет две основные функции. Во-первых, он является источником аналитической информации для оперативного управления и, во-вторых, здесь подготавливаются данные для последующей загрузки в центральное хранилище. Под подготовкой данных понимают их преобразование и осуществление определенных проверок. Наличие ОСД просто необходимо при различном регламенте поступления информации из источников. Третий уровень в описываемой архитектуре представляет собой набор предметно-ориентированных витрин данных, источником информации для которых является центральное хранилище данных. Именно с витринами данных и работает большинство конечных пользователей.

Проектирование структуры реляционного хранилища данных

ХД строятся на основе многомерной модели данных. Многомерная модель данных подразумевает выделение отдельных измерений (время, география, клиент, счет) и фактов (объем продаж, доход, количество товара), которые анализируются по выбранным измерениям. Многомерная модель данных физически может быть реализована как в многомерных СУБД, так и в реляционных. В последнем случае она выполняется по схеме "звезда" или "снежинка". Данные схемы предполагают выделение таблиц фактов и таблиц измерений. Каждая таблица фактов содержит детальные данные и внешние ключи на таблицы измерений. Теория построения многомерной модели данных и ее воплощение в реляционной структуре широко освещена как в зарубежной , так и в отечественной литературе .

К числу мало освещенных тем можно отнести проблему представления иерархий. В качестве примера измерения, широко применяющегося при анализе деятельности предприятия и имеющего иерархическую структуру, можно привести справочник статей затрат. Рассмотрим модель мест возникновения затрат (МВЗ), представленную на рис 2.

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

Parent ID 1 Предприятие 2 Управление 3 Инфраструктура 4 Производство 5 6 Сервисные услуги 7 Месторождение A 8 Месторождение B

Таблица 1.

Однако в простоте этого решения скрывается и основной его недостаток. К сожалению, стандартный SQL не поддерживает рекурсивные указатели, поэтому для представления деревьев в ХД используют другие методы.

Метод, предложенный Джо Селко (Joe Celko) , основан на теории множеств. В этом методе все узлы дерева проходятся в прямом порядке обхода и для каждого узла заполняются два значения - левая и правая границы, причем для каждого узла ветви дерева сначала заполняется левая граница и лишь затем правая - при движении обратно от потомков к родителям. Так в нашем примере нумерация узлов будет следующая:

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

select sum(fact_table.cost)
from fact_table, dimension_table D1, dimension_table D2
where fact_table.dimension_id = D2.id
and D2.left >= D1.left
and D2.right <= D1.right
and D1.name = "Инфраструктура"

Для простоты работы с таким справочником кроме полей left, right стоит добавить еще два поля: "Level" – уровень узла в дереве, "Is_leaf" – флаг, показывающий является ли узел листом в дереве или нет. Таким образом, мы получаем таблицу "dimension_table" (см. таблицу 2), которая позволяет хранить дерево любой глубины вложенности и размерности и позволяет выбирать потомков и родителей с помощью одного запроса.

1 Предприятие 2 Управление 3 Инфраструктура 4 Производство 5 6 Сервисные услуги 7 Месторождение A 8 Месторождение B

Таблица 2. Представление иерархий с помощью левой и правой границ

Другой способ, описанный Ральфом Кимбаллом , основан на введении вспомогательной таблицы ("helper-table"), через которую осуществляется связь таблицы фактов с таблицей измерения. Эта вспомогательная таблица отражает иерархическую структуру измерения и подчиняется следующему закону: вспомогательная таблица содержит весь набор пар "родитель-потомок", причем потомок может не быть непосредственным потомком родителя. Структура такой таблицы и ее содержимое показано в таблице 3.

Parent ID Child ID Distance 1 1 1 1 1 1 1 1 2 2 0 Y 3 3 0 N 3 5 1 N 3 6 1 N 4 4 0 N 4 7 1 N 4 8 1 N 5 5 0 Y 6 6 0 Y 7 7 0 Y 8 8 0 Y

Таблица 3. Структура и содержание вспомогательной таблицы.

Теперь связывая таблицу фактов (см. рис. 4) с идентификатором ребенка во вспомогательной таблице, а таблицу измерений с идентификатором родителя, мы можем вычислять сумму затрат для каждого МВЗ и всех его составляющих одним запросом, как и в предыдущем случае. При этом, добавляя ограничения на поля "Distance" и "Is Leaf", мы можем легко считать затраты для любого уровня в иерархии.

select sum(fact_table.cost)
from fact_table, dimension_table, helper_table
where fact_table.dimension_id = helper_table.child_id
and dimension_table.dimension_id = helper_table.parent_id
and dimension_table.name = "Инфраструктура"
and helper_table.distance = 1

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

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

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

Рассмотрим его более подробно (см. рис. 5). Таблица "dimension_actual" представляет собой таблицу измерений с первичным ключом dimension_id, содержащей корректные атрибуты измерения на сегодняшний день. С ней связана через внешний ключ dimension_id историческая таблица "dimension_history", в которой находится история изменения записей, определяемая датами начала/окончания действия записи (поля date_start, date_end). Актуальная на сегодняшний день запись также присутствует в ней с открытой датой окончания действия. Таблица фактов "fact_table" связана с таблицей измерений через вспомогательную таблицу "helper_table", которая отражает иерархическую структуру измерения.

Описанный подход позволяет: во-первых, хранить и работать с измерением как с несбалансированным деревом; во-вторых, быстро выполнять запросы, для которых не важна история изменения измерения (не участвует таблица, содержащая историю); в-третьих, позволяет отслеживать историю изменения измерения и, наконец, разделяет отражение истории и иерархии, что значительно упрощает сопровождение измерения.

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

Крайним случаем такого подхода является модель, которую условно можно назвать "показатель-значение". Суть ее состоит в том, что собирается большой набор показателей, характеризующих финансово-хозяйственную деятельность предприятия. Эти показатели могут быть как связанными между собой функционально, так и нет, могут отражать одни и те же величины, но с разной степенью детализации и т.д. При попытке представить такие данные в виде многомерной модели разработчик сталкивается со значительными проблемами и очень часто идет по пути создания не хранилища данных, а хранилища форм. Типичное хранилище форм строится на основе трех измерений – экономические показатели, время, отчетные формы; таблицы фактов – значения экономических показателей и вспомогательных таблиц, описывающих, как показатели и их значения расположены в отчетных формах. При анализе таких данных аналитик будет испытывать значительные трудности, связанные главным образом с тем, что показатели различных форм нельзя сравнивать между собой. Единственное, что ему остается – это отслеживание изменений показателей одной формы во времени.

Заключение

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

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

ЛИТЕРАТУРА

1.	Joerg Reinschmidt, Allison Francoise. Business Intelligence Certification Guide. IBM Red books;
2.	Inmon W. Building the Data Warehouse. – New York: John Willey & Sons, 1992;
3.	Спирли, Эрик. Корпоративные хранилища данных. Планирование, разработка, реализация. Том. 1: Пер. с англ. – М.: Издательский дом "Вильямс", 2001;
4.	Joe Celko. Trees in SQL: Intelligent Enterprise, October 20, 2000;
5.	Дональд Э. Кнут. Искусство программирования, том 1. Основные алгоритмы, 3-е изд.: – М. : Издательский дом "Вильямс", 2000.;
6.	Ralph Kimball. Help for Hierarchies: DBMS September 1998;
7.	Ralph Kimball. Slowly Changing Dimensions: DBMS April 1996;
8.	Статистический словарь: М. "Финансы и статистика", 1989;
9.	Дюк В, Самойленко А, Data mining: учебный курс. – СПб: Питер, 2001;
10.	Erhard Rahm, Hong Hai Do: Data Cleaning: Problems and Current Approaches. IEEE Data Engineering Bulletin 23(4): 3-13 (2000);
11.	Ralph Kimball: The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses. John Wiley 1996;
12.	Maria Sueli Almeida, Missao Ishikawa, Joerg Reinschmidt, Torsten Roeber, Getting Started with Data Warehouse and Business Intelligence. IBM Red books;
13.	Nigel Pendse, OLAP Architectures: The OLAP Report, http://www.olapreport.com/Architectures.htm#top.

5.1. Организация данных в корпоративных информационных системах.

Рассматривая КИС на самом упрощенном уровне можно сказать, что она содержит в себе корпоративную компьютерную (вычислительную) сеть и специализированный пакет прикладных программ (ППП) для решения задач предметной области. В свою очередь как ППП, так и компьютерная сеть предполагают в своей основе использование информационных данных о состоянии и развитии, контролируемых и управляемых ими систем. Исторически сложилось так, что КИС состоит из отдельных разветвленных подсистем отдельных предприятий, взаимосвязанных между собой и зачастую представляющих собой иерархическую систему. Естественно предположить, что подобные подсистемы имеют как собственные источники, так и собственные места хранения сопутствующих данных. Объединяясь в единую систему, возникают вопросы совместного корректного использования данных, территориально находящихся в различных местах их хранения. Следовательно, для успешного управления производственным объединением, оснащенным КИС, ему необходима надежная система сбора, хранения и обработки данных. Иными словами необходима единая информационная инфраструктура, удовлетворяющая стратегическим проектам BI (Business Intelligence) или интегрированная база для хранения и использования данных. Главной целью интеграции данных является получение единой и цельной картины состояния корпоративных бизнес - данных. Сама по себе интеграция представляет собой сложный процесс, в основе которого целесообразно выделить :

Технологии,

Продукты,

Приложения.

Методы – это подходы к интеграции данных.

Технологии – это процессы, реализующие те или иные методы интеграции данных.

Продукты – это коммерческие решения, поддерживающие ту или иную технологию интеграции данных.

Приложения – это готовые технические решения, поставляемые разработчиками в соответствии с пожеланиями клиентов – заказчиков.

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

5.2. Корпоративные базы данных и требования, предъявляемые к ним

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

· Простой и понятный пользователю ввод данных в базу,

· Хранение данных в виде, который не приведет к чрезмерному разрастанию данных,

· Доступность к общей информации сотрудников всех подразделений корпорации при обязательном условии разграничения прав доступа,

· Быстрое нахождение и выборка требуемой информации,

· Сортировку и фильтрацию необходимых данных,

· Группировку одноименных данных,

· Промежуточные и итоговые вычисления над полями,

· Преобразование и наглядность выводимых данных,

· Масштабируемость,

· Защищенность от случайных сбоев, безвозвратной потери данных и несанкционированного доступа.

Кроме того, при интеграции обособленных (распределенных) баз данных в единую корпоративную базу важно обеспечить возможность работы с базой таким образом, чтобы пользователь работал с ней так, как с нераспределенной.

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

· Консолидация,

· Федерализация,

· Распространение.

5.3. Характеристика интеграционных решений корпоративных баз данных

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

Применительно к корпорации при использовании этого метода данные копируются и собираются из первичных баз (БД – Slave) путем интеграции в единое место хранения (БД –Master). Как правило, таким местом хранения выбирается сервер центрального (головного) офиса (рис.5.1).

Рис.5.1. Метод консолидации данных

Данные в БД – Master используются для подготовки отчетности, проведения анализа, выработки и принятия решения, а также как источник данных для других филиалов корпорации.

Наиболее распространенными технологиями поддержки таких решений при консолидации являются технологии:

· Извлечение, преобразование и загрузка - ETL (Extract Transform Load);

· Управление содержанием корпорации - ECM (Enterprise Content Management).

Достоинствами метода консолидации являются:

1. Возможность осуществлять трансформацию (реструктуризацию, согласование, очистку и/или агрегирование) значительных объемов данных в процессе их передачи от первичных систем к конечным местам хранения за счет технологии ETL,

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

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

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

Наличие задержки времени между моментами обновления данных в первичных системах и в конечном месте хранения.

Такое отставание может составлять от нескольких секунд до нескольких часов или даже дней.

Федерализация. Под федерализацией обычно понимается объединение. Подобный термин часто используется в политике при обустройстве границ государства (например, ФРГ, РФ, США).

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

Рис.2. Метод федерализации данных

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

Поддержку федеративного подхода к интеграции данных обеспечивает технология Enterprise information integration (E I I), что в переводе означает – Интеграция корпоративной информации.

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

Основными достоинствами федеративного подхода являются:

· возможность доступа к текущим данным без создания дополнительной новой базы данных,

· целесообразность применения после приобретения или слияния компаний,

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

· использование при необходимости высокой автономии местных подразделений корпорации и гибкости централизованного контроля их деятельности,

· высокая степень полезности для крупных транснациональных корпораций.

К недостаткам подхода следует отнести:

· Снижение производительности из-за дополнительных затрат на доступ к многочисленным источникам данных,

· федерализация наиболее приемлема для извлечения небольших массивов данных,

· высокие требования к качеству первичных данных.

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

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

· Интеграция корпоративных приложений EAI – Enterprise Application Integration,

· Тиражирование корпоративных данных EDR – Enterprise Data Replication.

Обобщенная структура реализации метода распространения данных имеет вид рис.5.3.

Рис.5.3. Метод распространения данных

Отличительным признаком метода распространения данных является гарантированная доставка данных в систему назначения с минимальной задержкой, близкой к реальному режиму времени.

Сочетание в методе технологий интеграции (EAI) и тиражирования (EDR) дает множественные преимущества, в виде следующих достоинств:

· Высокая производительность,

· Возможность реструктуризации и очистки данных,

· Уравновешивание нагрузки за счет создания резервных копий и восстановления данных.

Гибридный подход. Реалии экономической деятельности таковы, что не существует двух одинаковых предприятий, тем более двух одинаковых корпораций. Данное обстоятельство накладывает свой отпечаток на процесс создания и наполнения КИС. Это всецело относится и к методам интеграции данных в базах. По этой причине многие КИС используют в своих приложениях интеграции данных так называемый гибридный подход, который одновременно включает несколько методов интеграции.Примерами такого подхода служат технологии, обеспечивающие согласованную картину информации о клиентах:

· Интеграция данных о клиентах в системахCDI – Customer Data Integration,

· Интеграция данных о клиентах в модуляхCRM – Customer Relations Management.

В частности, подход к реализации CDI может быть выполнен различными путями.

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

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

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

Более того, гибридный подход может быть расширен использованием метода распространения данных. Например, клиент, пользующийся услугами Интернет – магазина, во время обслуживания изменяет свои реквизиты. Эти изменения могут быть отправлены в консолидированную часть БД, а оттуда распространены во все первичные системы, содержащие данные о клиентах магазина.

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

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

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

5.4. Понятие и структурные решения хранилищ данных

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

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

В основе концепции хранилищ данных положены две основные идеи:

1. Интеграция разъединенных детализированных данных (описывающих конкретные факты, свойства, события и т.д.) в едином хранилище.

2. Разделение наборов данных и приложений, используемых для обработки и анализа.

Хранилище данных организуется в тех случаях, когда необходимо получить:

· Интеграцию текущих и исторических значений данных,

· Объединение данных из разрозненных источников,

· Создание надежной платформы данных для аналитических целей,

· Обеспечение однородности данных в организации,

· Облегчение внедрения корпоративных стандартов данных без изменения существующих операционных систем,

· Обеспечение широкой исторической картины и возможностей для анализа тенденций развития.

Исторически хранилища данных строились по одно- двух и трехуровневой схеме.

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

Достоинствами таких схем являются:

· Быстрая передача данных из оперативных систем в специализированную систему без промежуточных звеньев,

· Минимум затрат за счет использования единой платформы.

Недостатки:

· Узкий круг решаемых вопросов из-за единственного источника данных,

· Низкое качество данных ввиду отсутствия этапа очистки.

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

Достоинства:

· Используемые витрины проектируются для ответов на конкретный ряд вопросов,

· Имеется возможность оптимизировать данные в витринах, что способствует повышению производительности.

Недостатки:

· Сложность обеспечения непротиворечивости данных из-за многократного их повторения в витринах,

· Потенциальная сложность наполнения витрин при большом числе источников данных,

· В виду отсутствия консолидации данных на уровне корпорации нет единой картины бизнеса.

Эволюция развития привела к тому, что построение полноценного хранилища данных для современных корпоративных систем стало выполняться по трехуровневой архитектуре (см. рис.5.4).

На первом уровне расположены разнообразные регистрирующие системы, являющиеся источниками данных. Такими системами могут быть системы планирования ресурсов предприятия (ERP – Enterprise Resource Planning), справочные (оперативные) системы, внешние источники или системы, поставляющие данные от информационных агентств и др.

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

· Склад является источником аналитической информации, используемой для оперативного управления,

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

Третий уровень представляет собой совокупность предметно-ориентированных витрин данных.

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

Рис.5.4. Архитектура хранилища данных

Основными технологическими операциями подобным образом организованных хранилищ данных являются:

· Извлечение данных – это процесс переноса данных из неоднородных источников в оперативный склад,

· Преобразование данных – это модификация данных на основе специальных правил с последующей передачей их в центральное хранилище,

· Очистка данных – это исключение дублирования данных, поступающих от разных источников,

· Обновление данных – это распространение обновления данных на исходные данные базовых таблиц и производные данные, размещенные в хранилище.

Достоинства:

· Наполнение витрин упрощено ввиду использования единого источника очищенных данных,

· Витрины данных синхронизированы с корпоративной бизнес – картиной, что позволяет легко расширить центральное хранилище и добавить витрины данных,

· Гарантированная производительность.

Недостатки:

· Наличие избыточности данных, ведущее к росту требований к технологии хранения данных,

5. 5.Системы управления базами данных и технологии доступа к данным в КИС

Система управления базой данных (СУБД) – это комплекс языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных одним или многими пользователями .

В настоящее время наиболее широкое распространение получили СУБД, построенные на основе реляционной модели данных, описываемой строгим математическим аппаратом теории отношений.

Особенностью СУБД работающих в КИС является тот факт, что им приходится управлять базами данных, размещенными на носителях, распределенных в пространстве.

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

Основными технологическими решениями при многопользовательской работе с базами данных являются файл/серверные и клиент/серверные технологии. Взяв наиболее приемлемый вариант из этих технологий, клиент/сервер в КИС организуются специализированные системы обработки распределенных баз данных. При этом управление распределенными базами данных осуществляется таким образом, что данные распределяются не на логическом, а на физическом уровне и сама база данных рассматривается как единая "суперсхема". В распределенной базе данных функции администратора распределяются между администратором интегрированной базы данных и администраторами локальных баз данных. Администратор интегрированной базы данных следит за разграничением доступа разных пользователей к базе данных и обеспечивает целостность и сохранность данных, а также защиту данных от одновременной их корректировки несколькими пользователями. Разграничение доступа осуществляется в соответствии с правами, предоставляемыми отдельным пользователям в сетевой операционной системе.

Характерной особенностью созданных с помощью СУБД программ для работы с удаленными и распределенными корпоративными базами данных является использование открытого интерфейса доступа к данным – ODBC (Open Data Base Connectivity). Все функции по передаче данных возлагаются на интерфейс ODBC, который является связующим мостом между СУБД интегрированной базы и СУБД клиентских приложений. При этом СУБД клиента могут взаимодействовать не только со своими локальными базами, но и с данными, расположенными в интегрированной базе. Клиент имеет возможность посылать запросы на СУБД интегрированной базы, получать по ним данные и пересылать собственные обновленные данные.

Всё чаще IT-специалисты обращают своё внимание на решения по управлению данными, основанные на стандартных отраслевых моделях данных и шаблонах бизнес-решений. Готовые к загрузке комплексные модели физических данных и отчёты бизнес-аналитики для конкретных сфер деятельности позволяют унифицировать информационную составляющую деятельности предприятия и значительно ускорить выполнение бизнес-процессов. Шаблоны решений позволяют поставщикам услуг использовать возможности нестандартной информации, скрытой в существующих системах, сокращая тем самым сроки выполнения проектов, затраты и риски. Например, реальные проекты показывают, что модель данных и шаблоны бизнес-решений могут сократить объём трудозатрат на разработку на 50%.

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

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

Пример модели “ГИС для органов власти и местного самоуправления”.

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

Помочь в облегчении и оптимизации этого процесса, в переводе ИТ-подхода на современный уровень как раз и призваны отраслевые модели данных.

Отраслевые модели данных от компании Esri

Модели данных под платформу Esri ArcGIS представляют собой рабочие шаблоны для применения в ГИС-проектах и создания структур данных для разных прикладных областей. Формирование модели данных включает создание концептуального дизайна, логической и физической структуры, которые затем можно использовать для построения персональной или корпоративной базы геоданных. ArcGIS предоставляет инструменты для создания и управления схемой базы данных, а шаблоны модели данных используются для быстрого запуска ГИС-проекта по разным сферам применения и отраслям. Специалисты Esri вместе с сообществом пользователей потратили значительное количество времени на разработку ряда шаблонов, которые могут обеспечить возможность быстрого начала проектирования базы геоданных предприятия. Эти проекты описаны и задокументированы на веб-сайте support.esri.com/datamodels . Ниже, в порядке их упоминания на этом сайте, представлен смысловой перевод названий отраслевых моделей Esri:

• Адресный реестр
• Сельское хозяйство
• Метеорология
• Базовые пространственные данные
• Биоразнообразие
• Внутреннее пространство зданий
• Учет парниковых газов
• Ведение административных границ
• Вооружённые силы. Разведка
• Энергетика (включая новый протокол ArcGIS MultiSpeak)
• Экологические сооружения
• МЧС. Пожарная охрана
• Лесной кадастр
• Лесное хозяйство
• Геология
• ГИС национального уровня (e-gov)
• Подземные и сточные воды
• Здравоохранение
• Археология и охрана памятных мест
• Национальная безопасность
• Гидрология
• Международная гидрографическая организация (IHO). Формат S-57 для ENC
• Ирригация
• Земельный кадастр
• Муниципальное правительство
• Морская навигация
• Государственный кадастр
• Нефтегазовые структуры
• Трубопроводы
• Растровые хранилища
• Батиметрия, рельеф морского дна
• Телекоммуникации
• Транспорт
• Водопровод, канализация, ЖКХ

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

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

Специалисты Esri входят в экспертную группу независимых органов, которые рекомендуют к использованию различные отраслевые модели, например PODS (Pipeline Open Data Standards - открытый стандарт для нефтегазовой отрасли; в настоящее время имеется реализация PODS в качестве базы геоданных Esri PODS Esri Spatial 5.1.1) или база геоданных (БГД) из ArcGIS for Aviation, которая учитывает рекомендации ICAO и FAA, а также стандарт обмена навигационными данными AIXM 5.0. Кроме того, существуют рекомендованные модели, строго соответствующие существующим отраслевым стандартам, например S-57 и ArcGIS for Maritime (морские и прибрежные объекты), а также модели, созданные по результатам выполненных работ Esri Professional Services и являющиеся «де-факто» стандартами в соответствующей области. Например, GIS for the Nation и Local Government ("ГИС для органов государственной власти и местного самоуправления") оказали влияние на стандарты NSDI и INSPIRE, а Hydro и Groundwater (гидрология и грунтовые воды) активно используются в свободно доступном профессиональном пакете ArcHydro и коммерческих продуктах третьих фирм. Нужно отметить, что Esri поддерживает и стандарты "de-facto", например NHDI. Все предлагаемые модели данных документированы и готовы к использованию в IT-процессах предприятия. Сопроводительные материалы к моделям включают:

• UML-диаграммы связей сущностей;
• структуры данных, домены, справочники;
• готовые шаблоны баз геоданных в формате ArcGIS GDB;
• примеры данных и примеры приложений;
• примеры скриптов загрузки данных, примеры утилит анализа;
• справочники по предлагаемой структуре данных.

Компания Esri обобщает свой опыт построения отраслевых моделей в виде книг и локализует публикуемые материалы. Компанией Esri CIS локализованы и изданы следующие книги:

• Геопространственная сервис-ориентированная архитектура (СОА);
• Проектирование баз геоданных для транспорта;
• Корпоративные геоинформационные системы;
• ГИС: новая энергия электрических и газовых предприятий;
• Нефть и газ на цифровой карте;
• Моделирование нашего мира. Руководство Esri по проектированию базы геоданных;
• Думая о ГИС. Планирование ГИС: руководство для менеджеров;
• Географические информационные системы. Основы;
• ГИС для административно-хозяйственного управления;
• Веб-ГИС. Принципы и применение;
• Стратегии проектирования систем, 26-е издание;
• 68 выпусков журнала ArcReview с публикациями компаний и пользователей ГИС-систем;
• ... и множество других тематических заметок и публикаций.

Например, книга "Моделирование нашего мира… " (перевод) - это всестороннее руководство и справочник по моделированию данных в ГИС вообще, и по модели данных базы геоданных в частности. Книга показывает, как вырабатывать правильные решения по моделированию данных, решения, которые участвуют в каждом аспекте проекта ГИС: от проектирования базы данных и сбора данных до пространственного анализа и визуального представления. Подробно описывается, как спроектировать географическую БД, соответствующую проекту, настроить функциональность базы данных без программирования, управлять потоком работ в сложных проектах, моделировать разнообразные сетевые структуры, такие как речные, транспортные или электрические сети, внедрять данные космосъёмки в процесс географического анализа и отображения, а также создавать 3D-модели данных ГИС. Книга "Проектирование баз геоданных для транспорта " содержит методологические подходы, опробованные на большом количестве проектов и полностью соответствующие законодательным требованиям Европы и США, а также международным стандартам. А в книге "ГИС: новая энергия электрических и газовых предприятий " с использованием реальных примеров показаны преимущества, которые корпоративная ГИС может дать компании-поставщику энергии, включая такие аспекты как обслуживание клиентов, эксплуатация сетей и другие бизнес-процессы.

Некоторые из книг, переводных и оригинальных, изданных на русском языке компаниями Esri CIS и DATA+. В них затрагиваются как концептуальные вопросы, связанные с технологией ГИС, так и многие прикладные аспекты моделирования и развертывания ГИС разного масштаба и назначения.

Применение отраслевых моделей рассмотрим на примере модели данных BISDM (Building Interior Space Data Model, информационная модель внутреннего пространства здания) версии 3.0. BISDM является развитием более общей модели BIM (Building Information Model, информационная модель здания) и предназначена к использованию в задачах проектирования, строительства, эксплуатации и вывода из эксплуатации зданий и сооружений. Используется в ПО ГИС, позволяет эффективно обмениваться геоданными с другими платформами и взаимодействовать с ними. Относится к общей группе задач FM (управление инфраструктурой организации). Перечислим основные преимущества модели BISDM, применение которой позволяет:

• организовать обмен информацией в гетерогенной среде по единым правилам;
• получить «физическое» воплощение концепции BIM и рекомендуемых правил управление проектом строительства;
• поддерживать средствами ГИС единое хранилище на всем жизненном цикле здания (от проекта до вывода из эксплуатации);
• координировать работу различных специалистов в проекте;
• визуализировать заложенный календарный план и этапы строительства для всех участников;
• давать предварительную оценку стоимости и сроков возведения (4D- и 5D-данные);
• контролировать ход реализации проекта;
• обеспечить качественную эксплуатацию здания, включая обслуживание и ремонты;
• стать частью системы управления активами, включая функции анализа эффективности использования площадей (сдача в аренду, складские помещения, менеджмент сотрудников);
• проводить расчёт и осуществлять управление задачами энергоэффективности здания;
• моделировать перемещения людских потоков.

BISDM определяет правила работы с пространственными данными на уровне внутренних помещений в здании, в том числе предназначение и виды использования, проложенные коммуникации, установленное оборудование, учёт ремонтов и обслуживание, протоколирование инцидентов, взаимосвязи с другими активами компании. Модель помогает создавать единое хранилище географических и негеографических данных. Был использован опыт ведущих мировых компаний для выделения сущностей и моделирования на уровне БГД (базы геоданных) пространственных и логических взаимосвязей всех физических элементов, формирующих как само здание, так и его внутренние помещения. Следование принципам BISDM позволяет существенно упростить задачи интеграции с другими системами. На первом этапе это, как правило, интеграция с CAD. Затем, при эксплуатации здания, используется обмен данными с ERP и EAM-системами (SAP, TRIRIGA, Maximo и др.).

Визуализация структурных элементов BISDM средствами ArcGIS.

В случае использования BISDM заказчик/владелец объекта получает сквозной обмен информацией от идеи создания объекта до разработки полного проекта, контроль строительства с получением актуальной информации к моменту ввода объекта в эксплуатацию, контроль параметров во время эксплуатации, и даже при реконструкции или выводе объекта из эксплуатации. Следуя парадигме BISDM, ГИС и создаваемая с её помощью БГД становятся общим хранилищем данных для связанных систем. Часто в БГД оказываются данные, созданные и эксплуатируемые сторонними системами. Это нужно учитывать при проектировании архитектуры создаваемой системы.

На определённом этапе накопленная «критическая масса» информации позволяет перейти на новый качественный уровень. К примеру, по завершению этапа проектирования нового здания, в ГИС возможно автоматически визуализировать обзорные 3D-модели, составить перечень устанавливаемого оборудования, подсчитать километраж прокладываемых инженерных сетей, выполнить ряд поверок и даже дать предварительную финансовую оценку стоимости проекта.

Ещё раз отметим, что при совместном использовании BISDM и ArcGIS появляется возможность автоматического построения 3D-моделей по накопленным данным, поскольку БГД содержит полное описание объекта, включая z-координаты, принадлежность к этажу, виды соединений элементов, способы установки оборудования, материал, доступные пути перемещения персонала, функциональное назначение каждого элемента и т.д. и т.п. Нужно учесть, что после выполнения первоначального импорта всех проектных материалов в BISDM БГД возникает потребность дополнительного информационного наполнения для:

• простановки на обозначенных местах 3D-моделей объектов и оборудования;
• сбора сведений о стоимости материалов и порядка их укладки и монтажа;
• контроля проходимости по габаритам устанавливаемого нестандартного оборудования.

За счёт применения ArcGIS упрощается импорт дополнительных 3D-объектов и справочников из внешних источников, т.к. модуль ArcGIS Data Interoperability позволяет создавать процедуры по импорту подобных данных и корректному их размещению внутри модели. Поддерживаются все используемые в данной отрасли форматы, в том числе IFC, AutoCAD Revit, Bentlye Microstation.

Отраслевые модели данных от компании IBM

IBM предоставляет набор инструментов и моделей управления хранением данных для различных областей деятельности:

• IBM Banking and Financial Markets Data Warehouse (финансы)
• IBM Banking Data Warehouse
• IBM Banking Process and Service Models
• IBM Health Plan Data Model (здравоохранение)
• IBM Insurance Information Warehouse (страхование)
• IBM Insurance Process and Service Models
• IBM Retail Data Warehouse (розничная торговля)
• IBM Telecommunications Data Warehouse (телекоммуникации)
• InfoSphere Warehouse Pack:
  - for Customer Insight (для понимания клиентов)
  - for Market and Campaign Insight (для понимания компании и рынка)
  - for Supply Chain Insight (для понимания поставщиков).

Например, модель IBM Banking and Financial Markets Data Warehouse предназначена для решения специфических проблем банковской отрасли с точки зрения данных, а IBM Banking Process and Service Models - с точки зрения процессов и СОА (сервис-ориентированной архитектуры). Для телекоммуникационной отрасли представлены модели IBM Information FrameWork (IFW) и IBM Telecommunications Data Warehouse (TDW) . Они помогают существенно ускорить процесс создания аналитических систем, а также снизить риски, связанные с разработкой приложений бизнес-анализа, управлением корпоративными данными и организацией хранилищ данных с учётом специфики телекоммуникационной отрасли. Возможности IBM TDW охватывают весь спектр рынка телекоммуникационных услуг - от интернет-провайдеров и операторов кабельных сетей, предлагающих услуги проводной и беспроводной телефонии, передачи данных и мультимедийного контента, до транснациональных компаний, предоставляющих услуги телефонной, спутниковой, междугородней и международной связи, а также организации глобальных сетей. На сегодняшний день TDW используется крупными и мелкими поставщиками услуг проводной и беспроводной связи по всему миру.

Инструмент под названием InfoSphere Warehouse Pack for Customer Insight представляет собой структурированное и легко внедряемое бизнес-содержимое для всё большего числа бизнес-проектов и отраслей, среди которых банковское дело, страхование, финансы, программы медицинского страхования, телекоммуникации, розничная торговля и дистрибуция. Для бизнес-пользователей InfoSphere Warehouse Pack for Market and Campaign Insight помогает максимально повысить эффективность мероприятий по анализу рынка и маркетинговых кампаний благодаря пошаговому процессу разработки и учёта специфики бизнеса. С помощью InfoSphere Warehouse Pack for Supply Chain Insight организации имеют возможность получать текущую информацию по операциям цепочек поставок.

Позиция Esri внутри архитектуры решений IBM.

Особого внимания заслуживает подход IBM для электроэнергетических компаний и предприятий ЖКХ. Для того чтобы удовлетворить растущие запросы потребителей, энергоснабжающим предприятиям необходима более гибкая архитектура по сравнению с используемой сегодня, а также стандартная отраслевая объектная модель, что упростит свободный обмен информацией. Это повысит коммуникативные возможности энергетических компаний, обеспечивая взаимодействие в более экономичном режиме, и предоставит новым системам лучшую видимость всех необходимых ресурсов независимо от того, где они располагаются в пределах организации. Базой для такого подхода служит СОА (сервис-ориентированная архитектура), компонентная модель, устанавливающая соответствие между функциями подразделений и сервисами различных приложений, которые можно многократно использовать. «Службы» таких компонентов обмениваются данными посредством интерфейсов без жёсткой привязки, скрывая от пользователя всю сложность стоящих за ними систем. В таком режиме предприятия могут легко добавлять новые приложения независимо от поставщика программного обеспечения, операционной системы, языка программирования или иных внутренних характеристик ПО. На основе СОА реализуется концепция SAFE (Solution Architecture for Energy), она позволяет компании электроэнергетической отрасли получить основанное на стандартах целостное представление своей инфраструктуры.

Esri ArcGIS ® - признанная во всём мире программная платформа для геоинформационных систем (ГИС), обеспечивающая создание и управление цифровыми активами электроэнергетических, газотранспортных, распределительных, а также телекоммуникационных сетей. ArcGIS позволяет провести наиболее полную инвентаризацию компонентов электрической распределительной сети с учётом их пространственного расположения. ArcGIS существенно расширяет архитектуру IBM SAFE, предоставляя инструменты, приложения, рабочие процессы, аналитику и информационно-интеграционные возможности, необходимые для управления интеллектуальным энергопредприятием. ArcGIS в рамках IBM SAFE позволяет получать из различных источников информацию об объектах инфраструктуры, активах, клиентах и сотрудниках с точными данными об их местоположении, а также создавать, хранить и обрабатывать геопривязанную информацию об активах предприятия (опоры, трубопроводы, провода, трансформаторы, кабельная канализация и т.д.). ArcGIS внутри инфраструктуры SAFE позволяет динамически объединить основные бизнес-приложения, комбинируя данные из ГИС, SCADA и систем обслуживания клиентов с внешней информацией, например об интенсивности трафика, погодных условиях или спутниковыми снимками. Энергопредприятия используют такую комбинированную информацию для различных целей, от С.О.Р. (общей картины оперативной обстановки) до инспектирования объектов, технического обслуживания, анализа и планирования сетей.

Информационные компоненты энергоснабжающего предприятия можно смоделировать с помощью нескольких уровней, которые ранжируются от самого низкого - физического - до верхнего, наиболее сложного уровня логики бизнес-процессов. Эти уровни можно интегрировать, чтобы обеспечить соответствие типичным отраслевым требованиям, например, при автоматизированной регистрации измерений и управлении системой диспетчерского контроля и сбора данных (SCADA). Выстраивая архитектуру SAFE, энергоснабжающие компании делают значительные шаги в продвижении общеотраслевой открытой объектной модели под названием «Общая информационная модель для энергетических компаний» (Common Information Model (CIM) for Energy and Utilities). Эта модель обеспечивает необходимую базу для продвижения множества предприятий к сервис-ориентированной архитектуре, поскольку она поощряет использование открытых стандартов для структуризации данных и объектов. За счёт того, что все системы используют одни и те же объекты, путаница и неэластичность, связанные с различными реализациями одинаковых объектов, будут сокращены до минимума. Таким образом, определение объекта «клиент» и прочих важных бизнес-объектов будет унифицировано во всех системах энергоснабжающего предприятия. Теперь с помощью CIM поставщики и потребители услуг могут использовать общую структуру данных, облегчая вывод дорогостоящих компонентов бизнеса на аутсорсинг, так как CIM устанавливает общую базу, на которой можно построить обмен информацией.

Заключение

Комплексные отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход и рост эффективности.

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