Основы сетевых информационных технологий

• распределение пользователей системы: географическое, организационное, функциональное;
• доступ к данным: объем данных, необходимый для анализа, уровень агрегированности  данных,  источники данных (внешние или внутренние), описание информации, используемой совместно различными   функциональными группами предприятия;
• аналитические характеристики системы:  измерения данных, основные отчеты, последовательность преобразования аналитической информации и т.д.

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

3. Витрины Данных

       Идея  Витрины Данных (Data Mart) возникла сравнительно недавно, когда стало очевидно, что разработка корпоративного хранилища – долгий процесс. Это обусловлено как организационными, так и техническими причинами:

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

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

       Витрина Данных – специализированное хранилище,  которое обслуживает одно из направлений деятельности  компании (например: учет запасов или маркетинг). Происходящие здесь бизнес-процессы, во-первых, относительно изучены, а во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, занимающихся конкретной деятельностью невелико (рекомендуется, чтобы Витрина обслуживала не более 10-15 человек). Стоимость такого проекта значительно ниже стоимости разработки корпоративного Хранилища. Необходимо заметить, что разработка такого проекта  способствует продвижению новой технологии и приводит к быстрой окупаемости затрат. Следовательно, необходимо запараллелить процессы разработки корпоративного Хранилища и разработку, и внедрение Витрин Данных. 

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

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

Сочетание взаимосвязанных хранилищ и витрин данных увеличивает производительность: в витрины данных в стиле OLAP (On-line Analytical Processing – оперативный анализ данных) помещаются заранее агрегированные данные из хранилища, что ускоряет обработку запроса, т.к. обрабатывается меньший объем данных, разбитых уже на категории. Это эффективно в том случае, если данные не подвержены частым изменениям. В противном случае придется часто проводить реорганизацию базы данных.  Что целесообразнее применять: единое хранилище; самостоятельные витрины данных;  витрины, связанные с хранилищем; витрины, соединенные с неким промежуточным программным обеспечением? На этот вопрос однозначного ответа нет, т.к. оптимальный вариант вытекает из требований бизнеса, интенсивности запросов, сетевой архитектуры и необходимости быстрой реакции.

       Хранилище Метаданных (Репозиторий)

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

      Широко  известны Репозитории, входящие в состав популярных САSE-средств (Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA Research)), систем разработки приложений (Developer 2000 (Oracle), Power Builder (Sybase)), администрирования и поддержки информационных систем (Platinum, MSP). Все они, однако, решают частные задачи, работая с ограниченным набором метаданных, и предназначены, и основном, для облегчения труда профессионалов — проектировщиков, разработчиков и администраторов информационных систем.

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

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

•  анализ процессов возникновения, изменения  и использования метаданных;

• проектирование структуры хранения метаданных (например, в составе реляционной базы данных);

• организация  прав доступа к метаданным;

• блокировка и разрешение конфликтов при совместном использовании метаданных (что очень  часто возникает при изменении  общих бизнес-понятий в рампах структурного подразделения);

• разделение метаданных между Витринами Данных;

• согласование метаданных ХД с Репозиториями САSE-средств, применяемых при проектировании и разработке Хранилищ;

• реализации пользовательского интерфейса с  Репозиторием.

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

      Поскольку большинство СASE-средств использует различные форматы метаданных, поставщики систем управления метаданными выработали стандарт обмена MDIS, обеспечивающий возможность интеграции CASE-средств в СППР на основе ХД. К сожалению, не все предлагаемые сегодня на российском рынке продукты соответствуют этому стандарту, поэтому преобразование форматов метаданных представляют собой достаточно сложный процесс, упростить который призваны специализированные программные продукты, в том числе, например, средства фирмы Evolutionary Technologies International или Prism Solutions (Data Warehouse Directory).

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

Загрузка  Хранилища

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

При описании технологии заполнения Хранилища различают  три взаимосвязанные задачи:

• Сбор Данных (Data Acquisition),
• Очистка Данных (Data Cleansing) и
• Агрегирование Данных (Data Consolidation).

 

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

1. поддерживаются интерфейсы всех крупных производителей серверов баз данных (Oracle, Informix, ADABAS и т. д.);
2. практически всегда имеется ODBC-интерфейс;
3. можно извлекать данные из текстовых файлов в формате CSV (comma separated values) и из некоторых структурированных файлов, например файлов dBase.

 Набор  имеющихся интерфейсов — важнейшая  характеристика, которая часто позволяет  оценить, для каких задач проектировался  продукт. Так, если среди поддерживаемых интерфейсов имеются AS/400, 052/400, IMS, VSAM (как в популярном продукте PASSPORT фирмы Carleton), то он предназначен скорее для использования в системах, работающих на больших мэйнфреймах, чем в сети из ПК. Несколько иной набор интерфейсов предлагает, например, хорошо известный продукт InfoPump фирмы PLATINUM Technology, который обеспечивает поддержку LotusNotes, Microsoft Access, dBase и работу с текстовыми файлами. Крупные производители серверов либо имеют собственные средства сбора данных, либо устанавливают партнерские отношения с производителями таких средств и разрабатывают инструментарий промежуточного уровня для тиражирования «чужих» данных (таков, например, Replication Server фирмы Sybase).

 
 
 
 
 
 

  

 

 
 

                   

 

 
 
 
 
 

            Рис. 1.8. Склад данных с простой архитектурой клиент-сервер

 

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