Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Основные характеристики Хранилища данных
Технология разработки и внедрения Хранилищ Данных Первым этапом разработки ХД является бизнес-анализ процессов и данных предприятия. Несмотря на широкое распространение CASE-технологии, в России к бизнес-анализу и проектированию данных на концептуальном уровне не всегда относятся достаточно серьезно. Однако разработка СППР на основе ХД без подробного анализа обречена на неудачу. Разработчикам необходимо понимать цели бизнеса, способы их достижения, возникающие при этом проблемы и методы их решения, ресурсы, необходимые для разработки ХД. Самым критичным из ресурсов является время. Разработка СППР, в которой не определены заранее кто, когда, зачем и как будет принимать решения, какое влияние то или иное решение оказывает на бизнес, какие решения отнести к оперативным, а какие к стратегическим и т.д., обречена на провал в конкурентной борьбе. Особое назначение модели предприятия – определение и формализация данных, необходимых в процессе принятия решения. Существуют два подхода к бизнес-анализу: 1. описание бизнес-процессов, протекающих на предприятии, которое моделируется набором взаимосвязанных функциональных элементов. Такой подход эффективен, если бизнес стабилен и внешние факторы не играют в нем решающей роли.
· позволяет гибко модифицировать бизнес-процессы, ставя их в зависимость от бизнес-событий; · интегрирует данные, которые при анализе бизнес-процессов остаются скрытыми в алгоритмах обработки данных; · объединяет управляющие и информационные потоки; · наглядно показывает, какая именно информация нужна при обработке бизнес-события и в каком виде она представляется. Т.е., бизнес-событие имеет более тесную связь с информационными и управляющими потоками, чем бизнес-процесс. Через анализ бизнес-событий необходимо перейти к анализу данных, используемых предприятием. Для этого нужна информация об используемых внешних данных и их источниках; о форматах данных, периодичности и форме их поступления; о внутренних информационных системах предприятия, их функциях и алгоритмах обработки данных, используемых при наступлении бизнес-событий. Особенность анализа данных при проектировании СППР на основе ИХ состоит в необходимости создания модели представления информации (состав и форма отображения данных), которая является организационно-функциональным ядром модели системы. При ее разработке последовательно рассматриваются: · распределение пользователей системы: географическое, организационное, функциональное; · доступ к данным: объем данных, необходимый для анализа, уровень агрегированности данных, источники данных (внешние или внутренние), описание информации, используемой совместно различными функциональными группами предприятия; · аналитические характеристики системы: измерения данных, основные отчеты, последовательность преобразования аналитической информации и т.д. При проектировании транзакционной системы обычно строго выдерживается последовательность процессов: бизнес-анализ, концептуальная модель данных, физическая модель данных, структура интерфейса и т.п. Возврат на предыдущий уровень считается отклонением от нормального хода выполнения проекта. В случае СППР на основе ХД нормальным считается итерационный, а иногда и параллельный, характер моделирования, при котором возврат на предыдущую стадию – обычное явление. Это связано с необходимостью выделения всех требуемых данных для произвольных запросов, для чего следует составить исчерпывающий перечень необходимых данных и построить схему их связей через бизнес-события. При этом из общего массива выделяется значимая информация и выясняется потребность в дополнительных источниках данных для принятия решений. Следующий шаг связан с решением в каком виде и на каких аппаратных и программных платформах размещать структуру данных СППР на основе ХД.
Витрины Данных Идея Витрины Данных (Data Mart) возникла сравнительно недавно, когда стало очевидно, что разработка корпоративного хранилища – долгий процесс. Это обусловлено как организационными, так и техническими причинами: · информационная структура реальной компании, как правило, очень сложна, и руководство зачастую плохо понимает суть происходящих в компании бизнес-процессов; · технология принятия решений ориентирована на существующие технические возможности; · может возникнуть необходимость в частичном изменении организационной структуры компании; · требуются значительные инвестиции до того, как проект начнет окупаться; · как правило, требуется значительная модификация существующей технической базы; · значительные затраты времени специалистами компании на освоение новых технологий и программных продуктов. Разработка и внедрение корпоративного хранилища требуют значительных усилий по анализу деятельности компании, и переориентации ее на новые технологии. Витрины Данных возникли в результате попыток смягчить трудности разработки и внедрения Хранилищ. Витрина Данных – специализированное хранилище, которое обслуживает одно из направлений деятельности компании (например: учет запасов или маркетинг). Происходящие здесь бизнес-процессы, во-первых, относительно изучены, а во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, занимающихся конкретной деятельностью невелико (рекомендуется, чтобы Витрина обслуживала не более 10-15 человек). Стоимость такого проекта значительно ниже стоимости разработки корпоративного Хранилища. Необходимо заметить, что разработка такого проекта способствует продвижению новой технологии и приводит к быстрой окупаемости затрат. Следовательно, необходимо запараллелить процессы разработки корпоративного Хранилища и разработку, и внедрение Витрин Данных. Витрины Данных дешевле и проще в построении и базируются на более дешевых серверах Microsoft Windows NT, а не мультипроцессорных UNIX-комплексах. Но рост числа Витрин вызывает сложность их взаимодействия, так как не удается сделать витрины полностью независимыми. Витрины Данных нацелены на специфические нужды определенной службы, занимающейся либо закупками, либо произведенными товарами, либо планированием. Преимущество Витрин данных, по сравнению с Хранилищем, состоит в возможности быстрого получения сведений для поддержки решений в нужном месте, не задействуя при этом информационную систему всей корпорации. В то же время витрины данных могут быть и частью хранилища. Из хранилищ данных информация «перетекает» в различные отделы, отфильтровываясь в соответствии с заданными настройками СППР. Витрины хранят обобщенную информацию, тогда как более подробные данные можно найти в Хранилище. Пользователи имеют доступ к подмножествам хранилищ (т.е. к витринам данных), что улучшает обработку отдельных запросов, а к хранилищам обращаются лишь в случае необходимости. Такая стратегия обеспечивает важное преимущество, – реализуется единый подход к корпоративным данным. В витрины данных направляются копии информации из единого хранилища, и сотрудники разных подразделений на свои вопросы не рискуют получить разные ответы. Одна из основных задач развития корпоративных Хранилищ/Витрин данных состоит в объединении корпоративных данных, рассеянных по системам обработки транзакций. Поэтому создавать анклавы данных из множества независимых витрин данных может оказаться выгоднее, чем строить единую корпоративную СППР. Сочетание взаимосвязанных хранилищ и витрин данных увеличивает производительность: в витрины данных в стиле OLAP (On-line Analytical Processing – оперативный анализ данных) помещаются заранее агрегированные данные из хранилища, что ускоряет обработку запроса, т.к. обрабатывается меньший объем данных, разбитых уже на категории. Это эффективно в том случае, если данные не подвержены частым изменениям. В противном случае придется часто проводить реорганизацию базы данных. Что целесообразнее применять: единое хранилище; самостоятельные витрины данных; витрины, связанные с хранилищем; витрины, соединенные с неким промежуточным программным обеспечением? На этот вопрос однозначного ответа нет, т.к. оптимальный вариант вытекает из требований бизнеса, интенсивности запросов, сетевой архитектуры и необходимости быстрой реакции. |
Последнее изменение этой страницы: 2017-03-17; Просмотров: 680; Нарушение авторского права страницы