Цель: Изучить объективные причины возникновения понятия хранилища данных. Дать определение хранилища данных. Изучить типовые архитектуры хранилищ данных: глобальное хранилище данных, централизованное хранилище данных, распределенное хранилище данных, киоски данных, взаимосвязанные киоски данных, независимые киоски данных.
Изучив материал настоящей лекции, вы будете знать:
и научитесь
Информационная технология складирования данных (data warehousing) родилась в недрах компании IBM и была окончательно сформулирована Б. Инмоном и Р. Кимбаллом в 90-х прошлого столетия, как метод решения информационно-аналитических задач в области принятия и поддержки решений. Возникнув на стыке технологии баз данных (БД), систем поддержки принятия решений (СППР - DSS) и компьютерного анализа данных, в дальнейшем концепция складирования данных претерпела эволюцию, поскольку оказалась эффективной для широкого круга приложений в бизнесе, управлении, науке и технологии.
В середине прошлого века пришли к пониманию того, что информация является производственным ресурсом организации, наряду с людскими ресурсами, средствами и предметами труда, финансами, природными ресурсами. Это нашло отражение в использовании технологии баз данных и информационных систем (ИС) обработки оперативных данных (OLTP систем, On-Line Trasactions Proccessing). Информация в форме данных сохранялась и обрабатывалась в базах данных, фиксируя результат выполнения бизнес-процессов организации в электронном виде. Таким образом, базы данных создавались для сопровождения основных бизнес-процессов организации: поставки, покупки, продажи, финансы и т.д.
Основным посылом разработки технологии складирования данных явилось осознание руководством организаций потребности в анализе накопленных электронных массивов данных. Во всем мире организации накапливают или уже накопили в процессе своей административно-хозяйственной деятельности большие объемы данных, в том числе и в электронном виде. Эти коллекции данных хранят в себе большие потенциальные возможности по извлечению новой, аналитической информации, на основе которой можно и необходимо строить стратегию организации, выявлять тенденции развития рынка, находить новые решения, обусловливающие успешное развитие в условиях конкурентной борьбы. Информационные системы, так называемые системы бизнес-аналитики, обрабатывают уже накопленную организацией информацию. Они обладают рядом особенностей, таких как предметная ориентация системы, интегрированность хранимых в ней данных, собираемых из различных источников, инвариантность этих данных во времени, относительно высокая стабильность данных, необходимость поиска компромисса в избыточности данных.
Хранилище данных (ХД - data warehouse) является местом складирования собираемых в системе данных и информационным источником для решения задач анализа данных и принятия решений. Как правило, объем информации в ХД является достаточно большим. Упрощенно можно сказать, что хранилище данных управляет данными, собранными как из операционных систем организации, так и из внешних источников данных, и которые длительный период времени хранятся в системе.
Одной из главных целей создания систем бизнес-аналитики является их ориентация на анализ накопленных данных, т.е. структуризация данных в ХД должна быть выполнена таким образом, чтобы данные эффективно использовались в аналитических приложениях (analytical applications).
Заметим, что задачи анализа накопленных данных решали и до создания систем бизнес-аналитики. В распоряжении аналитиков и сейчас имеется большой набор пакетов программ для сбора и анализа данных. Главным отличием использования систем бизнес-аналитики является структуризация, систематизация, классификация, фильтрация, и т. п. больших массивов электронной информации в виде удобном для анализа, визуализации результатов анализа и производства корпоративной отчетности.
Технологи баз данных (БД) как метод представления и накопления данных в электронном виде сформировалась к середине 60-х годов прошлого века в фирме IBM. В 1969 году была создана первая СУБД для управления и манипулирования данными как самостоятельными информационными объектами. В 1970 году была предложена реляционная модель данных для БД и на ее основе начали создаваться популярные ныне реляционные СУБД. В рамках реляционной модели с единых позиций были решены многие проблемы операционной (транзакционной) обработки данных.
С середины 80-х годов прошлого столетия стали интенсивно накапливаться электронные информационные массивы организаций, корпораций, научно-исследовательских учреждений. Так, в начале 90-х годов прошлого века только в области химических дисциплин было зарегистрировано более 7000 библиографических, фактографических и смешанных баз данных, ведущие мировые корпорации создали огромные электронные массивы конструкторской документации и документации по управлению производством. В это же время возникло четкое понимание, что сбор данных в электронном виде - не самоцель, накопленные информационные массивы могут быть полезны. Первыми осознали этот факт в области управления бизнесом и производством. В накопленных данных организации находится «информационный снимок» хронологии ее поведения на рынке. Анализ истории административно-хозяйственной деятельности организации позволил существенно увеличить эффективность ее управления, эффективно организовать взаимоотношения с клиентами, производство и сбыт.
Задачи анализа накопленных данных стали перелагаться на «плечи компьютера» и встраиваться в виде аналитических приложений в ИС с БД. Сейчас большинство исследователей сходятся к тому, что отправной точкой разработки концепции складирования данных явился ретроспективный (как иногда еще говорят, исторический) взгляд на данные, накопленные в организации, как в электроном, так и в ином виде.
Давайте рассмотрим, как управление анализом накопленных (и в этом смысле исторических) данных, и какие еще факторы привели к созданию систем-бизнес-аналитики.
Автоматизированная информационная система (ИС) с БД, будучи средством удовлетворения потребностей пользователей в информации как производственном ресурсе, работает с потоками информации, выраженными в потоках данных и операциях над ними. Как было указано выше, основной акцент на ранних стадиях эксплуатации ИС с БД строился на операционной подходе к работе с данными. ИС, грубо говоря, должна была быстро и адекватно «переварить» поток данных для решения поставленных перед ней задач с помощью унифицированного набора операций манипулирования данными.
Совместное действие этих операции в рамках ИС приводило к конфликтам в данных - потерям данных, ошибкам в обновлении и т.д. - так называемых аномалиях в данных. Предложив реляционную модель (которая является достаточно строгой математической, а, следовательно, приемлемо контролируемой) моделью, Е. Кодд в целом решил ряд проблем и задач операционной обработки данных. Создание реляционных СУБД позволило «достаточно грамотно» (с учетом уровня компетентности разработчика) строить системы операционной (или как их еще называют транзакционной) обработки данных - OLTP.
На практике, данные в операционных системах могут содержаться столь угодно долго, сколь в них имеется потребность. Несмотря на то, что производители жестких дисков постоянно увеличивают объемы этих дисков, хранить редко используемую информацию не имеет смысла по той простой причине, что производительность многих запросов с ростом объема данных начинает падать и совершенствование подсистем оптимизации запросов СУБД решает проблему ухудшения производительности запросов лишь отчасти. В целом с накоплением данных производительность обработки данных продолжает ухудшаться (эффект больших объемов).
Таким образом, одной из проблем при решении задач анализа данных, помимо других скрытых проблем, в рамках операционных систем данных является низкая производительность обработки запросов, которые готовят данные для последующего анализа. Такие запросы увеличивают нагрузку на процессоры ОС и в целом ухудшают обработку потока транзакций в БД, исходящих от систем операционной обработки данных.
Работа с архивом как чистой копией массива данных операционной системы обработки данных не решает проблему производительности. Отсюда простое практическое решение - разделить решение задач обработки транзакций и задач анализа данных. В реляционных СУБД производительность запроса может быть улучшена за счет модификации модели данных. Архивные информационные массивы можно наделить структурой, отличной от структуры данных в несущей БД операционной ИС. Разработку таких структур данных можно связать с решением задач ретроспективного анализа данных, наколенных в системе. Это допустимо, хотя бы потому, что в задачах анализа данных учитываются далеко не все функциональные зависимости, поддерживаемые в операционных БД. Поэтому структуру данных архивов стали проектировать под задачи анализа данных, неявно породив тем самым новый класс приложений.
Фундаментальные требования к разработке операционных систем обработки данных и систем анализа данных различны: операционным системам нужна производительность, в то время как системам анализа данных нужна гибкость и широкие возможности для получения результата. Это противоречие в целевой направленности двух классов систем обработки данных явилось одной из основных предпосылок разработки хранилищ данных
С этой точки зрения необходимо было пересмотреть ряд традиционных подходов к обработке данных и перестроить технологические процедуры. Поскольку перестройка технологических процедур является чрезвычайно затратным мероприятием, важно отметить те причины, которые явились дополнительными побудительными мотивами применения новой концепции на практике.
Системы, доставшиеся в наследство (legacy systems, система доставшаяся по наследству). Средства вычислительной техники (ВТ) быстро развиваются и, как следствие, изменяются операционно-технологические платформы. За годы эксплуатации в системах, доставшихся по наследству, накоплены огромные бизнес - знания, было зафиксировано значительное количество бизнес - правил. Этот огромный объем информации необходимо перенести на новые аппаратно-программные платформы или в приложения.
Персональный компьютер. Позволяет перенести данные из централизованного вычислительного центра на рабочий стол пользователя (в частности, бизнес-аналитика).
Эффективность аналитической работы в особенно крупных организациях стала расти.
Однако, вовлечение конечных пользователей для решения задач управления данными в условиях коллективного их использования не является выходом из создавшейся ситуации. Во-первых, это требует времени и усилий конечных пользователей (а, следовательно, денег). Во-вторых, у них есть основная работа - анализ данных, которая им интересна и за которую им платят жалованье. Вовлечение их в работу в сфере информационных технологий совершенно точно приведет к снижению эффективности их основной работы.
Также, широкое применение персональных компьютеров в анализе данных привело к другой проблеме. Отсутствие общих стандартов представления данных в организации, большая свобода в выборе представления данных конечным пользователем, сбрасывание со счетов требований коллективного использования данных приводит к анархии в работе с данными и, как следствие, появляется опасная тенденция несогласованности коллективно используемых данных, которая может сказываться на качестве принятия стратегических решений.
Системы поддержки и принятия решений и управленческие информационные системы. Интенсивное использование систем поддержки и принятия решений (СППР - DSS) и управленческих информационных систем (ИСР- EIS, информационная система руководителя). СППР обычно фокусируются на более детальном представлении информации и ориентированы больше на менеджеров среднего уровня. ИСР обеспечивают более высокий уровень консолидации и многоаспектного (многомерного представления) взгляда на данные, поскольку руководители высокого уровня нуждаются в большем многообразии представления тех же самых данных для детального анализа.
Эти два схожих и перекрывающихся по функциям класса систем являются одной из главных предпосылок для создания систем бизнес-аналитики, в которых данные организованы для принятия решений. Отметим некоторые признаки, обычно связываемые с системами этого класса:
Развитие технологий. Не следует забывать также о факторах, связанных с техническим прогрессом в области разработки аппаратного обеспечения ЭВМ и развитием компьютерных технологий в разработке программного обеспечения. Это обстоятельство привело к снижению цен на комплектующие с одновременным ростом их мощности, созданию дружественных интерфейсов для пользователей. Создание и распространение Интернет/Интранет привело к тому, что бизнес стал перемещаться в Интернет.
Структурные изменения в бизнесе. Значительное влияние на формирование систем бизнес-аналитики оказали фундаментальные изменения в организации бизнеса и изменения в его структуре в конце прошлого века. Появление ярко выраженной глобальной экономики изменило требования к информации и спрос на нее. Деятельность организации пересекла границы своей страны и тем самым стала транснациональной.
Изменение экономических условий побудили большие корпорации к объединению (консолидации) своих усилий. Появление таких механизмов, как реинжениринг бизнес процессов (business process reengineering) и перестраиваемость бизнеса (downsizing) вынудил руководителей переоценить практику ведения бизнеса. Пересмотр процедур ведения бизнеса и изменение в финансовых потоках сыграли важную роль в развитии систем бизнес аналитики.
Принятие в начале 21 века восемью странами Окинавской хартии глобального информационного общества фиксирует тенденцию создания экономик, основанных на знаниях.
Требования пользователей. Информационные технологии стали производственным ресурсом компаний - это первый результат таких требований. Электронная почта, Интернет, мобильный телефон и карманный ПК вовлечены в процесс управления. Это также требования, приходящие от руководителей организаций и компаний. Им нужен быстрый и качественный доступ к аналитической информации в любой момент времени и по любому виду каналов связи.
Как видно из выше сказанного, потребности бизнеса в новых экономических условиях, создание мощной программно-аппаратной платформы, распространение информационных технологий создали предпосылки рождения нового класса приложений - систем бизнес-аналитики ХД, как информационного носителя для таких систем (Рис. 1.1).
Рис. 1.1. Основные факторы, повлиявшие на разработки концепции хранилищ данных
Основная задача аналитика - подготовить фактический материал руководству организации для принятия управленческого решения с целью получения этой организаций большей прибыли. Например, руководство организации ставит перед аналитиком задачу - что нужно сделать, чтобы оптимизировать цепочку поставок. Что нужно для решения этой задачи аналитику? Знать, кто и что поставляет, какова надежность поставщиков, т.е. были ли срывы поставок и от каких поставщиков, какие поставщики есть на рынке и какова их надежность и т.д. Чтобы ответить на весь комплекс вопросов и подготовить соответствующие предложения аналитик использует как внутреннюю информацию, так и внешнюю информацию. Вопрос в том, как быстро он ее получит. С точки зрения информационного обеспечения это означает, что он не должен терять много времени для получения внутренней информации. Он должен получить ее как можно быстрее. Отсюда следует «простой» вопрос, как должны быть организованы данные в системе бизнес-аналитики, чтобы он времени на их получение не терял. Иначе она ему не нужна, хотя необходимая информации в организации в электронном виде есть (в операционных системах).
Давайте рассмотрим, как эту проблему можно решить.
Извлечение данных из операционных систем. К данным, сохраняемым для анализа, может быть обеспечен наиболее эффективный доступ только при условии выделения их из операционной (транзакционной) системы, т.е. данные из операционной системы должны быть вынесены в отдельную систему бизнес-аналитики. Хотя для ряда аналитических задач можно и не строить отдельное ХД, а решить их за счет применения средств многомерного анализа данных. В настоящее время ХД можно строить и на существующей OLTP системе, и над ней, и как самостоятельный объект. Это должно решаться руководителем ИТ - проекта в рамках выбора архитектуры ХД.
Необходимость интегрировать данные из нескольких OLTP систем. Системы бизнес-аналитики наиболее полезны, когда данные могут быть извлечены более чем из одной OLTP системы. Когда данные должны быть собраны от нескольких бизнес - приложений, естественно предположить, что это нужно сделать в месте отличном от места локализации исходных приложений. Еще до создания структурированных ХД, аналитики во многих случаях комбинировали данные, извлеченные из разных систем в одну крупноформатную таблицу или базу данных. ХД может очень эффективно воедино собрать данные от конкретных приложений, таких, как продажи, маркетинг, финансы, производство с учетом их накопления, т.е. сохранить временные ряды основных показателей бизнеса, так называемые исторические данные.
Заметим, что одним из свойств данных, собранных из различных приложений и используемых аналитиками является возможность делать перекрестные запросы к таким данным. Во многих ХД атрибут «Время» является естественным критерием для фильтрования данных. Аналитиков интересует поведение временных рядов данных, характеризующих процессы бизнеса.
Целью многих систем бизнес-аналитики является обзор деятельности типа «год за годом». Например, можно сравнивать продажи в течение первого квартала этого года с продажами в течение первого квартала предшествующих лет. Время в ХД - фундаментальный атрибут перекрестных запросов. Например, аналитик может попытаться оценить влияние новой компании маркетинга, проходящей в течение определенных периодов, рассматривая продажи в течение тех же самых периодов. Способность устанавливать и понимать корреляцию между деятельностью различных подразделений в организации часто приводится как один из самых главных аргументов о пользе систем бизнес аналитики. Такая система может служить не только как эффективная платформа, чтобы консолидировать данные из различных источников; но и может также собирать многократные версии данных из одного приложения.
Различия между транзакционной и аналитической обработкой данных. Одной из наиболее важных причин отделения данных для анализа от данных OLTP систем было потенциальное падение производительности обработки запросов при выполнении процессов анализа данных. Высокая производительность и небольшое время ответа - критические параметры OLTP систем. Потерю производительности и объем накладных затрат, связанных с обработкой предопределенных запросов обычно легко оценить. С другой стороны, запросы для анализа данных в ХД трудно предсказать, и, следовательно, для них сложно оценить время выполнения запроса.
OLTP системы разрабатываются для оптимального выполнения предопределенных запросов в режиме работы, близком к режиму реального времени. Для таких систем, обычно можно определить распределение нагрузки во времени, определить время пиковых нагрузок, оценить критические запросы и применить к ним процедуры оптимизации, поддерживаемые современными СУБД. Также относительно легко определить максимальное допустимое время ответа на определенный запрос в системе. Стоимость времени ответа такого запроса может быть оценена на основе стоимости выполнения операторов ввода-вывода, затрат на трафик по сети. Например, для системы обработки заказов можно задать число активных менеджеров по оформлению заказов и среднее число заказов в течение каждого часа работы.
Несмотря на то, что многие из запросов и отчетов в системе бизнес-аналитики предопределены, почти невозможно точно предсказать поведение показателей системы (время отклика, трафик сети и т.п.) при их выполнении. Процесс исследования данных в ХД происходит зачастую непредсказуемым путем. Руководители всех рангов умеют ставить неожиданные вопросы. В процессе анализа могут возникать не предопределенные (ad hoc) запросы, которые вызваны неожиданными результатами или непониманием конечным пользователем используемой модели данных. Далее, многие из процессов анализа имеют тенденцию принимать во внимание многие аспекты деятельности организации, в то время как OLTP системы хорошо сегментированы по видам деятельности. Пользователю может потребоваться более детальная информация, чем хранящаяся в итоговых таблицах. Это может привести к соединению двух или более огромных таблиц, что приведет к созданию временной таблицы объема равного произведению числа строк в каждой таблице, что резко снизит производительность системы.
Данные в системах складирования данных остаются неизменными. Другое ключевое свойство данных в системе бизнес аналитики состоит в том, что данные в ХД остаются неизменными. Это означает, что после того, как данные разместятся в ХД, они не могут быть изменены. Например, статус заказа не меняется, размер заказа не меняется, и т. д. Эта характеристика ХД имеет большое значение для отбора типов данных при размещении их в ХД, а также выбор момента времени, когда данные должны быть занесены в хранилище данных. Последнее свойство называется гранулированностью данных.
Рассмотрим, что означает для данных быть неизменяемыми. В OLTP системе объекты данных проходят через постоянные изменения своих атрибутов. Например, заказ может многократно изменять свой статус до того как будет оформлен. Или, когда изделие собирается на сборочной линии, к нему применяются множество технологических операций. Вообще говоря, данные из OLTP системы нужно загружать в ХД лишь тогда, когда обработка их в рамках бизнес процессов будет полностью завершена. Это может означать завершение заказа или цикла производства изделия. Как только заказ закончен и отправлен, он вряд ли поменяет свой статус. Или, как только изделие собрано и сдано на склад, оно, вряд ли, попадет на первую стадию сборочного цикла.
Другим хорошим примером может быть размещение в ХД снимка постоянно изменяющихся данных в определенные моменты времени. Модуль управления запасами в OLTP системе может изменять запас почти в каждой транзакции; невозможно занести все эти изменения в хранилище данных. Вы можете определить, что такой снимок состояния запаса следует вносить в хранилище данных каждую неделю или ежедневно, так, как это будет принято для анализа в конкретной организации. Данные такого снимка естественно неизменяемы.
После того, как данные занесены в хранилище данных, их модификация возможна в крайне редких случаях. Очень трудно (хотя такие попытки есть), поддерживать динамические данные в хранилище данных. Задача синхронизации часто изменяемых данных в OLTP системах и системах бизнес-аналитики еще далека от приемлемого решения. Здесь следует также упомянуть, что размещение динамично меняющихся данных в ХД в настоящее время является предметом интенсивных исследований. Например, разработка процедур поддержки в ХД медленно меняющихся таблиц измерений является задачей, которая уже находит свое решение на уровне ПО производителей решений в области ХД. А что делать, если номенклатура производимых изделий меняется в год на 30-40%?
Данные в хранилище данных хранятся значительно более длительное время, чем в OLTP системах. Данные в ХД хранятся значительно более длительное время, чем в OLTP системах Данные в большинстве OLTP систем архивируются сразу после того, как они становятся не активными. Например, заказ может стать неактивным после того, как он выполнен; банковский счет может стать неактивным после того, как он был закрыт за определенный период времени. Главная причина для архивирования неактивных данных - это производительность OLTP системы (зачем хранить данные, если к ним не обращаются). Большие объемы таких данных могут ухудшить производительность выполнения запросов в предположении, что обрабатываются только активные данные. Для обработки таких данных в СУБД предлагаются различные процедуры разбиения базовых таблиц на секции. С другой стороны, поскольку ХД предназначены, в частности, чтобы быть архивом для OLTP данных, данные в них хранятся в течение очень длительного периода.
Фактически, проект создания ХД данных может начинаться и без любого определенного плана архивирования данные из ХД. Стоимость сопровождения данных, после их загрузки в хранилище данных, невысока. Наибольшие затраты при создании ХД выпадают на трансформацию данных (data transfer) и их очистку (data scrubbing). Хранение данных в течение пяти и более лет типично для систем складирования данных. Поэтому процедурам архивизации данных из хранилища данных на стадиях их создания и эксплуатации в начале периода можно не уделять много времени. Особенно, если учесть снижение цен на аппаратные средства ЭВМ.
Иначе говоря, отделение данных OLTP систем от данных систем бизнес-аналитики является фундаментальным принципом для создания ХД. Сейчас бизнес невозможен без принятия обоснованных решений. Такие решения могут быть построены на основе всестороннего анализа результатов выполнения бизнес-процессов в организации и деятельности организации на рынке товаров и услуг. Время принятия решений в современных условиях и потоках информации сокращается. Роль создания и поддержки систем бизнес-аналитики на основе новых информационных технологий возрастает. ХД является одним из основных звеньев применения таких технологий.
Можно выделить следующие причины для разделения данных систем складирования данных и систем операционной обработки данных (Рис. 1.2):
Рис. 1.2. Основные причины разделения данных для анализа и оперативной обработки
Логическое преобразование данных OLTP систем и моделирование данных. Данные в ХД логически являются преобразованными, когда они перенесены в него из OLTP системы или другого внешнего источника. Проблемы, связанные с логическим преобразованием данных при переносе их в ХД могут потребовать значительного анализа и усилий проектировщиков. Архитектура системы складирования данных и модели ХД имеют огромное значение для успеха таких проектов. Ниже будут рассмотрены некоторые фундаментальные понятия реляционной теории БД, которые полностью не применимы к системам складирования данных. Даже притом, что большинство ХД развернуто на реляционных базах данных, некоторые основные принципы реляционных БД сознательно нарушаются при создании логической и физической модели ХД.
Модель данных ХД определяет его логическую и физическую структуру. В отличие от просто архивированных данных, в данном случае невозможно обойтись без процедур детального моделирования данных. Такое моделирование данных в ранних стадиях проекта ХД необходимо для создания эффективной системы, охватывающий данные всех бизнес процессов и процедур организации.
Процесс моделирования данных должен структурировать данные ХД в виде, независимом от реляционной модели данных системы поставляющей эти данные. Как будет показано ниже, модель ХД, вероятно, будет менее нормализована, чем модель OLTP системы - источника данных.
В OLTP системах данные по разным подсистемам могут значительно перекрываться. Например, информация относительно разрабатываемых изделий используется в различных формах во многих подсистемах OLTP системы. Система бизнес-аналитики должна объединить все такие данные в одной системе. Некоторые атрибуты объектов, которые являются существенными для OLTP системы, окажутся ненужными для ХД. Могут появиться новые атрибуты, так как сущность (entity) в ХД изменяет свое качество. Основное требование - все данные в ХД должны участвовать в процессе анализа.
Модель данных ХД должна быть расширена и структурирована таким образом, чтобы данные от различных приложений могли быть добавлены. Проект ХД в большинстве случаев не может включать данные от всех возможных бизнес-приложений организации. Обычно объем данных в ХД увеличивается по принципу инкремента: данные экстрагируются из OLTP систем, и добавляются в ХД определенными порциями. Начинают с сохранения особенно существенных данных, затем планомерным образом наращивают их объем, по мере необходимости.
Модель хранилища данных подстраивается под структуру бизнеса. Следующий важный момент состоит в том, что логическая модель ХД настраивается на структуру бизнеса (ориентирована на предметную область), а не на агрегацию логических моделей конкретных приложений. Сущности (объекты), поддерживаемые в ХД, аналогичны сущностям (объектам) бизнеса таким, как клиенты, продукция (товар), заказы, и дистрибуторы. В рамках конкретных подразделений организации может быть очень узкое представление об объектах бизнеса организации, например о клиентах. Так, группа обслуживания ссуд в банке может только знать о клиенте в контексте одной или нескольких выданных ссуд. Другое подразделение того же банка может знать о том же клиенте в контексте депозитного счета. Представление данных о клиенте в ХД намного превышает аналогичное представление конкретного подразделения банка. Клиент в ХД представляет клиента банка во всех его взаимоотношениях с банком. С точки зрения реляционной теории меняется базисный набор функциональных зависимостей, поддерживаемых в БД.
ХД следует строить на атрибутах сущностей бизнеса (предметно ориентировано), собирая данные об этих сущностях из различных источников. Структура данных любого отдельного источника данных, вероятно, будет неадекватна для ХД. На структуру данных конкретного приложения оказывают влияние такие факторы как:
Модель ХД не связана с ограничениями моделей данных источников. Для нее должна быть разработана модель, которая отражает структуру бизнеса организации, а не структуру бизнес - процесса. Такая расширенная модель данных должна быть понятна как аналитикам, так и менеджерам. Таким образом, проектировщик ХД должен выполнить настройку объектов ХД к структуре бизнес организации, с учетом ее бизнес-процессов и бизнес- процедур.
Преобразование информации, описывающей состояние объектов в OLTP системе. Следующий важный момент состоит в том, что перед размещением данных в ХД они должны быть преобразованы. Большинство данных из OLTP системы или иного внешнего источника не могут поддерживаться в ХД. Многие значения атрибутов объектов в OLTP системе очень динамичны и постоянно изменяются. Многие из этих атрибутов не загружаются в ХД, другие же атрибуты являются статичными во времени и загружаются в ХД. ХД вообще не должно содержать информации об объектах, которые являются динамическими и постоянно находятся в состоянии модификации.
Чтобы понять, что означает потеря информации, описывающей текущее состояние объекта, рассмотрим пример системы управления заказами, которая отслеживает состояния запасов при заполнении заказа. Сначала рассмотрим сущность «Заказ» в OLTP системе. Заказ может пройти множество различных статусов или состояний прежде, чем он будет выполнен и обретет статус завершенный. Статус заказа может указывать, он готов к заполнению, что заказ заполняется, возвращен обратно на доработку, готов к отгрузке и т.д. Конкретный заказ может пройти много состояний, которые отражаются в статусе заказа, и определяются бизнес-процессами, которые применились к нему. Практически невозможно перенести все атрибуты такого объекта в ХД. Система складирования данных вероятно должна содержать только один конечный снимок такого объекта как заказ. Таким образом, объект заказ должен быть преобразован для размещения в ХД. Тогда в ХД может быть собрана информация от многих объектах типа заказ и построен окончательный объект ХД - «Заказ».
Рассмотрим более сложный пример трансформации данных при управлении запасом товара в OLTP системе. Запас может изменяться в каждой транзакции. Количество конкретного товара на складе может быть уменьшено транзакцией подсистемы заполнения заказа, или это количество может быть увеличено при поступлении купленного товара. Если система обработки заказа выполняет десятки тысяч транзакций в день, то, вероятно, фактический уровень запаса в БД будет иметь много состояний и зафиксируется во многих снимках в течение этого дня. Невозможно зафиксировать все эти постоянные изменения в БД и перенести их в ХД. Отображение такого поведения объекта в системе источнике данных, по-прежнему, является одной из нерешенных задач в системах складирования данных. Есть ряд подходов к решению этой проблемы. Например, можно периодически фиксировать снимки уровня запаса в ХД.
Этот подход может быть применим к очень большой части данных в OLTP системах. В свою очередь такое решение повлечет за собой ряд задач, связанных с выбором периода времени, объема снимаемых данных и т.д. Таким образом, большая часть данных о состоянии объектов OLTP системе не может быть непосредственно перенесена в хранилище данных. Они должны быть преобразованы на логическом уровне.
Денормализация модели данных. Следующий момент в разработке реляционных ХД состоит в решении вопроса о том, насколько важно в ХД соблюдать принципы реляционной теории, а именно, разрешить денормализацию модели, в частности для увеличения производительности запросов.
Прежде, чем мы рассмотрим денормализацию модели данных в контексте ХД, давайте кратко вспомним основные моменты теории реляционных БД и процесса нормализации. Е.Ф. Кодд разработал реляционную теорию БД в конце 1960-ых, когда он работал в исследовательском центре IBM. Сегодня, большинство популярных платформ БД полностью следует этой модели. Реляционная модель БД - коллекция двухмерных таблиц, состоящих из рядов и колонок. В терминологии реляционной модели, эти таблицы, строки и колонки соответственно называются отношениями или сущностями, кортежами, атрибутами (attribute) и доменами (domain). Модель идентифицирует уникальные ключи (Key) для всех таблиц и описывает отношения между таблицами через значения атрибутов (ключей).
Нормализация (Normalization) является процессом моделирования реляционной БД, где отношения или таблицы разбиваются до тех пор, пока все атрибуты в отношении полностью не будут определяться его первичным ключом. Большинство проектировщиков пытаются достичь третьей нормальной формы (3НФ) на всех отношениях до того, как они будут денормализовываться по тем или иным причинам. Три последовательных этапа нормализации реляционных баз данных кратко описаны ниже:
Процесс нормализации приводит к разбиению исходного отношения на несколько независимых отношений. Каждому отношению в базе данных отвечает, по крайней мере, одна таблица. Несмотря на большую гибкость реляционной модели в представлении данных, она может быть более сложной и трудной для понимания. Кроме того, полностью нормализованная модель может быть очень неэффективной при ее реализации. Поэтому, проектировщики БД при преобразовании нормализованной логической модели в физическую модель допускают значительную денормализацию. Основное назначение денормализации состоит в ограничении межтабличных соединений в запросах.
Еще одной из причин денормализации модели ХД, является, также как и для операционных систем, производительность и простота. Каждый запрос в реляционных БД имеет свою стоимость выполнения (cost performance). Стоимость выполнения запросов очень высока в ХД из-за количества обрабатываемых данных в запросе (и межтабличных соединений, число которых растет пропорционально размерности модели). Соединение трех маленьких таблиц в OLTP системе могут иметь приемлемую стоимость выполнения запроса, но в системе складирования данных выполнение такого соединения может занять очень много времени.
Статичность взаимосвязей в исторических данных. Денормализация является важным процессом в моделирования ХД: взаимосвязь между атрибутами не изменяется для исторических данных. Например, в OLTP системах товар может быть частью другого товара группы «А» в этом месяце и частью товара группы «В» в следующем месяце. В нормализованной модели данных для отображения этого факта необходимо включить атрибут «Группа товаров» в отношение (сущность) «Товар», но не в отношение (сущность) «Заказ», которая формирует заказы на этот товар. В сущность «Заказ» включается только идентификатор товара. Реляционная теория будет требовать соединения между таблицами «Заказ» и «Товар» для определения группы товаров и других атрибутов этого продукта. Этот факт (функциональная зависимость) не имеет значения для ХД, поскольку сохраняемые данные относятся к уже выполненным заказам, т.е. принадлежность товара группе уже зафиксирована (фактически указанная функциональная зависимость не поддерживается). Даже если товар принадлежал различным группам в разное время, взаимосвязь между группой товаров и товаром каждого отдельного заказа статична. Таким образом, это не является денормализацией для ХД. В данном случае функциональная зависимость OLTP системы не используется в ХД.
Другим важным примером может выступать цена товара. Цены в OLTP системе могут изменяться постоянно. Некоторые изменения этих цен могут быть перенесены в ХД, как периодические снимки таблицы «Цена товара». В ХД история прайс-листа товара зафиксирована и уже привязана к заказам, т.е. не нужно динамически определять прайс-лист при обработке заказа, поскольку он уже был применен к сохраненному заказу. В реляционных БД проще поддерживать динамические взаимоотношения между сущностями бизнеса, в то время как ХД содержит взаимосвязи между сущностями предметной области в заданное время.
Физическое преобразование данных приложений источников. Важным моментом в системах бизнес-аналитики является физическое преобразование данных. Эти процедуры в ХД известны как процессы очистки данных («data scrubbing», «data staging» или «data purge»). Процесс очистки данных является наиболее интенсивным и трудоемким в любом проекте создания ХД. Физическое преобразование включает использование стандартных терминов предметной области ХД и стандартов данных. В течение процесса физического преобразования, данные находятся в некотором промежуточном файле до того, как будут занесены в ХД. Когда данные собираются из многих приложений, то их целостность может быть проверена в течение процесса формирования преобразованных данных до загрузки в ХД.
Термины и имена атрибутов сущностей, используемые в OLTP системах, в процессе преобразования данных для ХД преобразуются в универсальные, стандартные термины, принятые для данной сферы бизнеса. Приложения могут использовать сокращения или трудные для понимания термины по множеству различных причин. Программно-аппаратная платформа может ограничивать длину и формат имен, а бизнес-приложения могут использовать для разных предметных областей общие термины. В ХД необходимо использовать стандартные бизнес термины, которые понятны сами по себе большинству пользователей.
Идентификатор клиента (покупателя) в OLTP системе может быть назван как «Покуп.», «покуп_ид» или «покуп_но». Далее, различные приложения таких систем могут использовать различные имена (синонимы) при ссылке к одному и тому же атрибуту сущности. Разработчики ХД должны выбрать простой стандартный бизнес-термин, такой, как идентификатор клиента. Таким образом, имена атрибутов сущностей из подающих систем должны быть унифицированы для использования в ХД.
Различные подсистемы OLTP систем и внешних источников данных могут использовать различное определение доменов атрибутов на физическом уровне представления данных. Так атрибут типа идентификатор продукта может в одной системе иметь длину от 12 символов, а в другой 18 символов. С другой стороны ПО одних существующих систем может иметь ограничения на определение длин имен атрибутов и бедный набор типов для определения доменов, а в других такие ограничения могут отсутствовать и предоставляться широкий выбор типов атрибутов.
При определении атрибутов в физической модели ХД, необходимо использовать такие длины и типы данных в определении домена атрибута, которые позволили бы учесть как требования предметной области, так и возможности систем - источников данных. Определение стандартов доменов для ХД является одной из важных задач проектировщиков ХД. Правила преобразования доменов атрибутов систем - источников данных в домены атрибутов ХД следует фиксировать в метаданных ХД.
Все атрибуты в ХД должны согласованно использовать предопределенные значения. В различных приложениях могут быть приняты различные соглашения по предопределенным значениям атрибутов. К таким предопределенным значениям относятся значения по умолчанию, например, значения, заменяющие null-значения и т. п. Например, признак пола в различных системах может иметь различные значения: в одних это могут быть символьные значения "М" и "Ж", в других цифровые значения 0 и 1. Более неприятным примером, является случай, когда одно значение данных используется в приложении в нескольких целях, т.е. атрибут на самом деле представляет множественное значение. Например, когда в атрибуте тип метода измерения две первые цифры означают метод измерения, а две вторые метод физического контроля измерения. Такие различные значения перед загрузкой в ХД должны быть преобразованы к принятому в ХД предопределенному значению.
В некоторых системах - источниках данных могут отсутствовать значения (проблема пропущенных значений, «missing data») или преобразование для них не может быть выполнено («corrupt data» - данные, для которых преобразование не может быть выполнено). Важно, чтобы в процессе преобразования такие данные принимали в ХД значения, которые позволяли бы пользователям интерпретировать их правильно. Одним атрибутам может быть просто назначено разумное значение по умолчанию в случае отсутствия значения или конфликтов при преобразовании, значения других атрибутов может быть определено из значений других атрибутов. Например, пусть, в сущности «Заказ» значение атрибута единицы измерения товара пропущено. Это значение может быть получено из соответствующего атрибута сущности «Товар» этой системы - источника. Для некоторых атрибутов не существует подходящих значений по умолчанию в случае, когда их значения отсутствуют. Для таких пропущенных значений в ХД следует также определять значение по умолчанию, например, как null -значение.
Таким образом, в процессе преобразования данных разработчики ХД должны привести данные систем - источников к определенным стандартам, (Рис. 1.3) а именно:
Рис. 1.3. Стандарты физического представления данных
В Табл. 1.1 ниже приведены основные отличия использования данных в системах операционной обработки данных и системах анализа данных.
| Операционные системы обработки данных | Системы складирования данных | |
|---|---|---|
| Частота обновления данных | Режим реального времени | Периодически |
| Данные структурируются с целью | Обеспечения целостности данных | Обеспечения простоты выполнения запросов |
| Оптимизируются для обеспечения | Процесса выполнения транзакций | Процесса выполнения выборки данных |
Агрегация и суммирование конкретных данных. При создании системы бизнес-аналитики еще одним важным моментом является сбор и определение требований пользователей. Как правило, такие требования позволяют оценить число вопросов, на которые система должна давать ответы. Большинство вопросов носят аналитический характер. Аналитический характер вопроса подразумевает определенный уровень агрегации и суммирования данных перед получением конечного результата. Во многих современных системах бизнес-аналитики при их создании закладывается определенный набор предопределенных и автоматически генерируемых итоговых отчетов и справок. Например, руководителям организации необходимо знать картину продаж производимой продукции, что предполагает суммирование продаж, как в денежном, так и в товарном выражении за неделю, месяц, квартал, год. Подведение итогов деятельности организации в такой форме обычно делается по товарам, клиентам и каналам сбыта.
Агрегация и суммирование конкретных данных можно выполнять и средствами СУБД в OLTP системах. В реляционных ХД эти операции выполняются на таблицах, которые поддерживаются независимо от таблиц OLTP систем. С этой точки зрения ХД предоставляет более широкие возможности в построении итоговых отчетов и запросов.
Первой такой возможностью является использование широкого спектра бизнес-правил для агрегации детальных данных. Эти правила могут быть реализованы в виде набора фильтров, которые применяются к данным. Данные в ХД могут анализироваться в соответствие с этими правилами с различных точек зрения. Применение этих правил приводит к использованию в ХД большого числа многотабличных соединений, самой трудоемкой реляционной операции. Размещение и обработка детальных данных в ХД может быть выполнена более эффективно, чем в соответствующей OLTP системе.
Каждая точка зрения на детальные данные определяет аспект их анализа. Таким образом, детальные данные как бы становятся точками многомерного пространства, в котором оси определяются точкой зрения на данные. Такие оси называются измерениями. Проектировщику ХД данных необходимо определить предопределенные измерения детальных данных, размещаемых в ХД, для проведения многомерного анализа этих данных пользователями.
Например, для данных о продажах можно рассмотреть четыре точки зрения на их анализ: по товарам, по покупателям, по каналам сбыта, по регионам. Таким образом, будет получено четыре измерения для детальных данных о продажах. В рамках каждого измерения может быть введена иерархия. Регион может рассматриваться как страна, область район, населенный пункт. При проектировании ХД проектировщик должен учесть такие аспекты анализа и представления детальных данных.
После проведенного выше обсуждения причин и факторов, повлиявших на рождение понятия ХД, подведем итоги и дадим определения.
Концепция ХД была предложена в начале 90-х годов прошлого столетия как основа методологии организации данных в системах поддержки и принятия решений. Согласно классическому определению Б. Инмона, хранилище данных есть предметно-ориентированная, интегрированная, неизменяемая и поддерживающая хронологию электронная коллекция данных для обеспечения процесса принятия решений.
Предметная ориентированность. Информация в ХД организована в соответствии с основными аспектами деятельности предприятия (заказчики, продажи, склад и т.п.), т.е. бизнес - процессы. Это является принципиальным отличаем ХД от оперативной БД, где данные организованы в соответствии с процессами (выписка счетов, отгрузка товара и т.п.), т.е. бизнес - операции. Предметная организация данных в ХД способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Выражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных.
Интегрированность. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются (то есть вычисляются суммарные показатели) и загружаются в ХД. Такие интегрированные данные намного проще анализировать.
Привязка ко времени. Данные в хранилище всегда напрямую связаны с определенным периодом времени. Данные, выбранные их оперативных БД, накапливаются в хранилище в виде «исторических слоев», каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции в развитии бизнеса.
Неизменяемость. Попав в определенный «исторический слой» ХД, данные уже никогда не будут изменены. Это также отличает ХД от оперативной БД, в которой данные все время меняются, и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных также облегчает их анализ.
Концепция ХД оказалась пригодной для решения задач анализа данных не только в бизнесе, но и в науке и технологии. Следует отметить, что в определении соединены две различные функции:
Использование термина «поддержка и принятие решений» в качестве сферы применения ХД существенно сужает как определение, так и возможность применения концепции в других сферах. Если в определении в качестве области применения оставить лишь анализ и воспроизводство новых данных (как элемент обработки информации в научных, технологических и экологических системах), круг использования данной концепции может быть значительно расширен. Таким образом, можно дать и такое определение: ХД - есть организация и поддержка предметно-ориентированной, интегрированной, слабо изменяемой по внутренней структуре и поддерживающей хронологию электронной коллекции данных для обработки с целью извлечения новых данных или обобщения имеющихся.
Очень важен основной принцип действия ХД: единожды занесенные в ХД данные затем многократно извлекаются из него и используются для анализа. Отсюда вытекает одно из основных преимуществ использования этой технологии, - контроль информации, полученной из различных источников, предварительно согласованной и размещенной в ХД. Отметим, что отсюда следует и наиболее уязвимое место ХД, - корректность его данных, полученных из разных источников. Данные перед загрузкой должны быть либо «очищены от шума», либо обработаны методами нечеткой логики, допускающей наличие противоречивых фактов, чтобы противоречия в данных были по возможности устранены. Заметим также, что интеграция в определении ХД понимается не только как интеграция информации по всем источникам, но в смысле согласованного представления данных из разных источников по их типу, размерности и содержательному описанию.
С точки зрения применения концепции в бизнесе, производстве и технологиях следует придерживаться следующего определения: ХД - структурно расширяемая вычислительная среда, спроектированная для анализа неизменяемых во времени данных, логически и физически преобразованных из различных источников, соответствующая направлениям бизнеса, обновляемая и поддерживаемая длительный период времени, выраженная в простых бизнес-терминах и обобщенная (суммированная) для быстрого анализа.
На практике, для реализации ХД используются СУБД, поддерживающие определенную модель данных. Поэтому с точки зрения реализации хранилище данных следует считать базой данных специальной структуры.
Концепция ХД развивалась по мере расширения сферы применения. В начале, под ХД понимался набор предметно-ориентированных, интегрированных, не меняющихся во времени исторических данных, предназначенных для принятия решений руководством.
Потом, стало очевидным, что ХД данных обладают определенной внутренней структурой. Они содержат базовые данные, которые образуют единый источник для обработки данных во всех системах поддержки принятия решений (DSS). С помощью ХД данных можно выполнить согласование данных, не смотря на разногласие данных-источников. А элементарные данные, присутствующие в ХД, могут быть представлены в различной форме, отвечая не только известным требованиям, но еще и неизвестным.
ХД обычно имеют очень большой объем данных, поскольку в них содержатся исторические и детализированные данные, от нескольких терабайт и больше. По причине размера объемов данных, данные в ХД подразделяются на два класса: активно и неактивно используемые данные.
ХД содержат интегрированные данные. Они интегрированы на множестве уровней: на уровне ключа, атрибута, на описательном, структурном уровне и так далее. Общие данные и общая обработка данных консолидированы и являются единообразными для всех данных, которые обладают структурным сходством.
Несмотря на то, что указанные выше характеристики являются общими для всех ХД, в настоящее время довольно трудно типизировать и классифицировать всевозможные ХД. Можно предложить некоторую классификацию ХД в зависимости от характеристик предметной области, которые придают ХД индивидуальные особенности. Классификация архитектурных программно-аппаратных решений будет дана в следующей лекции.
Далее будут кратко описаны типы ХД по Б. Инмону. В основу его классификации положен отраслевой принцип применения ХД.
Финансовые хранилища данных. В большинстве случаев финансовые ХД организации строят в первую очередь. Создание финансового ХД - необходимый компонент финансовой инфраструктуры любой организации.
Финансовые данные всегда находятся в центре внимания руководства организации. Поэтому привлечь интерес к созданию такой информационной системы данных очень легко. Финансовая активность большинства организаций (но не всех) невелика, поэтому объемы финансовых данных не очень большие, скорость поступления данных также не велика. Финансовые данные хорошо структурированы. Поэтому имеющиеся программно-аппаратные средства позволяют создать и поддерживать компактные финансовые ХД. Финансы охватывают все аспекты функционирования организации и имеют один общий знаменатель - деньги. Финансовые данные по своей природе имеют структуру, на которую напрямую влияет повседневная практика обработки финансовой информации.
По этим причинам финансы становятся самой предпочтительной областью построения корпоративного ХД. Однако финансовые ХД имеют серьезные, присущие только этому типу, проблемы. Первая проблема заключается в следующем. Руководство организации ожидает, что сведения из финансовых ХД будут с точностью до одной копейки совпадать с данными существующей финансовой среды. Ожидание того, что информация в финансовом ХД должна точь-в-точь совпасть с цифрами из текущего финансового отчета, является глубоко ошибочным. Люди (то есть финансовые работники), которые так думают, просто не понимают, что, когда данные переходят из операционной среды в финансовое ХД, происходит их трансформация. А когда данные перетекают из мира приложений в реальный мир организации, их рассматривают в другом измерении. При такой трансформации происходит следующее:
Как видно, существует много причин, почему данные, находящиеся в ХД, отличаются от данных операционных систем. Финансовые работники думают иначе, и вот почему необходимо им разъяснять, что такое трансформация, и что означают различные измерения данных.
Хранилища данных в области страхования. ХД в области страхования за некоторыми небольшими исключениями похожи на другие. Первое исключение (характерное для западных компаний) заключается в том, что продолжительность существования имеющихся ХД очень велика. Такие ХД содержат данные, которые являются очень старыми (до начала XX века)
Второе отличие этих ХД определяется датами, которые хранятся в этом бизнесе. Среда страхования - по каким бы то ни было причинам - отличается наличием огромного числа дат, связанных с бизнесом, чем какой-либо другой вид деятельности. Так, в сфере розничной торговли имеется несколько важных дат: дата продажи, дата появления на складе, возможно, дата производства. В банковском деле существенна дата транзакции. В телекоммуникации - это дата телефонного звонка. В страховании же присутствуют даты всевозможных типов.
Наконец, третье отличие заключается в том, что эти ХД используют свой рабочий цикл деловой активности. Большинство организаций имеет весьма ограниченный и короткий экономический цикл. Так, в банках это обналичивание чека. В торговле - покупка изделия. В телефонной компании - звонок. В страховании им может быть заявка на страховое возмещение, которая может быть удовлетворена спустя пять лет. Или закрытие полиса может сопровождаться двухмесячной отсрочкой. В итоге скорость, с которой функционирует страхование, отличается от скорости, характерной для других отраслей.
Эта разница в скорости отражается в ХД, как в зеркале. В других ХД транзакции просто собираются и обрабатываются. В области страхования транзакция (transaction) может откладываться на неопределённый срок, а ее различные части могут отражаться в ХД, т.е. существенным является не только сама операция, но и ее состояния. Результатом этого является совершенно особый подход при проектировании и внедрении таких ХД.
Хранилища данных для управления персоналом. ХД для управления людскими ресурсами имеют весьма существенные отличия от других ХД. Первое отличие - число предметных областей. Такое ХД данных неизбежно имеет одну важную предметную область - это работник. Практически все остальное подчинено этой области или занимает второстепенное положение. Большинство же других ХД имеют несколько базовых предметных областей.
Основное отличие ХД данных для управления людскими ресурсами состоит в том, что они используют очень мало транзакций. Так, имеется дата, когда субъект становится работником. Дата, когда человек увольняется. Годовые прибавки и повышения. Но, кроме транзакций фонда заработной платы и прочих редких, сгенерированных работником, транзакций, в таком ХД практически больше ничего и нет. Сравните сферу управления людскими ресурсами с коммуникацией или банковской средой, и разница в числе транзакций станет очевидной.
Эта разница в числе транзакций является причиной возникновения определенной сложности, которая заключается в том, что в области управления человеческими ресурсами наблюдается тенденция к объединению операционной обработки людских ресурсов и обработки людских ресурсов для систем принятия решения в одну среду. В других же отраслях соблазн совершить такую архитектурную ошибку весьма невелик.
Примерами таких ХД в РФ является База данных "Научные кадры высшей квалификации".
Глобальные Хранилища данных. Глобальные Хранилища данных предназначены для глобального представления деятельности организации. Различают три типа таких ХД:
Особенность глобального ХД заключается в том, что на глобальном уровне зачастую очень мало общих измерений. Единственное общее измерение - это деньги. И интеграция бизнеса может быть достигнута только с его помощью. Другие же измерения могут иметь или не иметь смысл на глобальном уровне. Так, клиент, продукт, поставщик, транзакция - все эти классические предметные области могут, как присутствовать, так и отсутствовать в глобальной интегрированной сфере - глобальном ХД.
Помимо этого, глобальное ХД должно непрерывно реагировать на возможные изменения в бизнес - данных. В этом случае такие изменения, как правило, носят постоянный характер. Поэтому структура и технология, используемая для размещения и обслуживания глобального ХД, должна позволять поддерживать эти непрерывные перемены.
В западной Европе такая информация и не только такая содержится в CRIS.
Хранилища данных с возможностями обнаружения новых данных (Data Mining). ХД, поддерживающие технологию обнаружения новых данных (Data Mining) являются гибридом классических ХД. Они используются для выполнения мощной статистической обработки данных. Эти ХД являются:
Кроме того, для таких ХД характерна ориентация на какой-либо проект. Это означает, что, в отличие от всех других типов ХД, в большинстве случаев их перестают использовать сразу по завершении анализа, ради которого они создавались, если они не используются для постоянного мониторинга типа обнаружения так называемых слабых сигналов (грубо говоря, предсказание и определение прорывных технологий)
Еще одно важное отличие ХД с возможностями анализа заключается в том, что они очень часто включают внешние данные. Такие данные очень полезны с точки зрения прогнозирования изменений бизнес - данных, которые не так легко увидеть без их участия.
В настоящее время такие ХД попадают в область интересов «больших данных» и науке о данных.
Хранилища данных в области телекоммуникаций. Отличительная особенность этих ХД состоит в том, что они в значительной степени определяются данными, касающихся факта телефонных разговоров. Разумеется, в отрасли телекоммуникации присутствует множество других типов данных. Но ни одна другая область ХД не предопределяется в такой степени размером одной предметной области - деталями на уровне разговора.
Существуют несколько способов хранения подробностей на уровне телефонного разговора:
К сожалению, несмотря на разнообразие методов обработки, для данного ХД обработка может быть выполнена только над деталями на уровне разговора. А работа на итоговом или агрегированном уровне выполнима средствами технологии обнаружения новых данных применительно к интеллектуальной обработке естественного языка.
ХД - это логически интегрированный источник данных для систем принятия решений, информационных систем руководителей, систем анализа данных и систем обнаружения новых данных (Data Mining). ХД предназначено для информационной поддержки анализа данных, принятия решений, т.е. информационной поддержки деятельности, а не собственно поддержки каждодневных бизнес - процедур организации, и поэтому многие принципы технологии БД утрачивают в ХД свое значение.
ХД ориентируется на определенную предметную область и организуется так, чтобы решать конкретные задачи анализа и информационной поддержки деятельности организации. Данные различных источников агрегируются ХД, приобретая при этом статус неизменчивых. Для ХД характерно массовое добавление данных и фактическое отсутствие операций обновления. Процесс пополнения данных включает в себя сложные процедуры очистки данных: устранения несоответствия типов, размеров и других свойств данных.
Основные отличия различных типов ХД состоят в следующем:
Вне всяких сомнений, будут появляться и другие типы ХД, каждому из которых присущи свои отличительные особенности.
Технология ХД обеспечивает адекватную основу для информационной поддержки деятельности руководителей организаций в области принятия решений и дает преимущества в тех областях деятельности, которая связана с управлением и использованием долговременно хранимой информации, а именно:
Одной из главных целей разработки ХД является информационное обеспечение компьютерной поддержки принятия решений по всем или основным видам деятельности организации. Каждый вид деятельности организации является отдельной задачей, решение которой может быть, а может и не быть увязано с решением других задач в рамках организации. Вид деятельности организации или направление бизнеса совместно со спектром соответствующих ему бизнес - задач определяют предметную область ХД. Например, компания производит и продает оборудование, для добычи газа, а с другой стороны, та же компания имеет подразделения, которые занимаются производством услуг в области автоматизации предприятий, в том числе и газодобывающих. Источники прибыли в этих случаях различны. Это два направления бизнеса компании (две предметных области). Общими задачами анализа данных для этих направлений бизнеса являются прибыль и бюджет.
ХД - это сложная компьютерная система. Под архитектурой ХД понимают совокупность программно-аппаратных компонент, совокупность технологических и организационных решений, предпринимаемых для создания, разработки и функционирования ХД, т.е. выбор аппаратного и программного обеспечения, выбор способов взаимодействия программно-аппаратных компонент, выбор способа решения проектной задачи по разработке и созданию ХД. Как правило, архитектуру ХД составляют следующие компоненты:
Кроме этого, необходимы специальные программные средства проектирования хранилища, средства работы с репозитарием метаданных и собственно средства оперативной аналитики, или OLAP-средства.
Характер и масштаб решаемых задач анализа данных организации оказывает решающее значение на выбор архитектуры ХД и методы его проектирования. Разработчики должны помнить, что с одной стороны, ХД создается для решения конкретных, строго определенных задач анализа и воспроизводства новых данных, с другой, ХД должно обеспечивать корпоративную отчетность в рамках всей организации. Таким образом, определяющим моментом в построении ХД являются задачи обработки и анализа данных, производства и доставки отчетов.
Характер и масштаб решаемых задач анализа данных определяет и подходы к выбору архитектуры и проектированию ХД.
Желательно, чтобы выбор архитектуры ХД был сделан до начала его реализации, однако практике это не всегда следуют этому правилу. Задержка с выбором архитектуры ХД обычно приводит пересмотру проделанной работы в свете новых принятых решений и, как правило, к увеличению объема работы.
Выбор архитектуры ХД относится к сфере компетенции руководителя ИТ - проекта по созданию системы складирования данных. На такой выбор влияют несколько различных факторов: инфраструктура организации, производственная и информационная среда организации, управление и контроль, масштабы проекта, возможности аппаратно-технологического обеспечения, готовность персонала и имеющиеся ресурсы.
Выбор подхода к конкретной реализации ХД также лежит в области влияния руководителя ИТ - проекта. Правильный выбор архитектуры ХД обычно определяет успех конкретного проекта по созданию системы складирования данных.
Существует несколько факторов, влияющих на принятие решений о выборе способа реализации: время, отведенное на проект, возврат инвестиций, скорость ввода ХД в эксплуатацию, потребности пользователей, потенциальные угрозы по переделке, требования к ресурсам, необходимым в определенный момент времени, и выбранная архитектура ХД, совокупная стоимость владения ХД.
Разработчики ХД должны знать, какие возможные решения могут быть приняты по архитектуре ХД, и какой объем работ по проектированию ХД они повлекут. Выбор архитектуры будет определять, где ХД и/или киоски данных будут расположены, и как ими будут организационно - технологически управлять. Например, данные могут быть расположены в центральном офисе организации, т.е. будут поддерживаться централизованно. Данные могут быть распределены по офисам организации или располагаться в филиалах организации, и могут поддерживаться как централизованно, так и независимо друг от друга.
На Рис. 1.4 приведена типовая обобщенная концептуальная схема для архитектуры ХД. В конкретных решениях по архитектуре ХД, некоторые компоненты схемы могут отсутствовать.
Рис. 1.4. Типовая обобщенная концептуальная схема для архитектуры ХД
Компонентами типовой архитектуры ХД являются:
Типовыми архитектурами для систем бизнес-аналитики принято считать следующие:
Глобальное хранилище данных (Global data warehouse) или хранилище данных масштаба организации - это такое ХД, в котором будут поддерживаться все, или большая часть, данных организации. Это наиболее полное интегрированное ХД с высокой степенью интенсивности доступа к консолидированным данным и использованием его всеми подразделениями организации или руководством организации в рамках основных направлений деятельности организации. Таким образом, глобальное ХД проектируется и конструируется на основе потребностей аналитической информационной поддержки организации в целом. Его можно рассматривать как общий репозиторий для данных, обеспечивающих принятие решений.
Глобальное ХД необязательно должно быть реализовано физически как централизованное. Термин «глобальное» используется для отражения масштаба использования и доступа к данным в рамках всей организации. Физически, глобальное ХД может быть как централизованным, так и распределенным.
Централизованное глобальное ХД характерно для организаций, расположенных, территориально, в одном здании, и которое поддерживается отделом информационных систем организации. Распределенное глобальное ХД также может быть использовано в рамках организации в целом. Оно физически распределяется по подразделениям организации и также поддерживается отделом информационных систем.
Поддержка ХД отделом информационных систем вовсе не означает, что именно эта служба управляет ХД. Например, отдельные части распределенного ХД могут управляться в рамках подразделений или направлений бизнеса.
Управление ХД означает, кто решает:
Таким образом, для глобального ХД существуют два основных архитектурных решения, как показано на Рис. 1.5.
Рис. 1.5. Основные архитектурные решения для глобального ХД
Данные для ХД обычно извлекаются из OLTP систем организации, электронных документов организации и внешних источников данных. После их фильтрации, очистки и преобразования они помещаются в ХД. Затем пользователи получают доступ к этим данным в соответствии с правилами управления доступом к данным, принятыми в организации.
Преимуществом глобального ХД является предоставление конечным пользователям доступа к информации в масштабах предприятия, недостатком - высокие затраты на реализацию и время создания ХД.
Независимые киоски данных включают в себя автономные или независимые киоски данных (Stand-alone Data Marts), которые управляются рабочими группами, отделами или направлениями бизнеса, и разрабатываются исключительно для реализации аналитических потребностей последних. Вполне возможно, что при этом не существует никакой связи между ними. Например, данные для таких киосков данных могут генерироваться непосредственно в самих подразделениях организации. Данные могут извлекаться из OLTP систем, в частности при помощи информационных служб организации. Информационные службы могут поддерживать вычислительную среду для киосков данных, но не управляют информацией в них. Данные в киоски могут поступать и из глобального ХД.
Для организации независимых киосков данных требуется некоторые профессиональные и технические навыки. Как правило, для их создания выделяются ресурсы и персонал в рамках того подразделения, для которого они создаются. Такой тип реализации ХД оказывает минимальное влияние на информационные ресурсы организации и может быть выполнен очень быстро. В то же время, максимальная независимость и минимальная интеграция, а также отсутствие глобального представления о данных организации, могут стать ограничением такой архитектуры.
Киоски данных могут быть взаимозависимы или взаимосвязаны, так называемые связанные киоски данных. Такая архитектура ХД включает в себя совокупность киосков данных, которые управляются рабочими группами, отделами или направлениями бизнеса, но разрабатываются в рамках единой для организации схемы удовлетворения информационных и аналитических потребностей. Для взаимосвязанных киосков данных типична распределенная архитектура реализации. Несмотря на то, что отдельные киоски данных реализуются в рамках рабочих групп, подразделений и направлений бизнеса, они могут быть интегрированы, т.е. взаимосвязаны, для того чтобы обеспечить представления данных в рамках организации в целом. Фактически, на наиболее высоком уровне интеграции, они могут стать глобальным ХД. В такой архитектуре пользователи одних подразделений могут получать доступ к данным других подразделений в рамках своих полномочий.
Требования интеграции данных в рамках архитектуры взаимосвязанных киосков данных делают реализацию ХД более сложной по сравнению с независимыми киосками данных. Например, необходимо решить вопрос, кто будет управлять данными в киосках данных, и кто будет поддерживать вычислительную среду. Важным становится вопрос о том, что делать с данными, которые являются общими для нескольких киосков данных, а также как разработать схему разграничения доступа пользователей к киоскам данных в рамках всей организации.
Главным достоинством создания ХД такой архитектуры является более глобальное представление данных. Взаимосвязанные киоски данных могут управляться в рамках того подразделения, в котором они создаются.
Реализация такой архитектуры не выдвигает высоких требований к программно-аппаратному обеспечению, и стоимость ее может быть невысокой. Однако время реализации будет больше по сравнению с независимыми киосками данных. Возрастает также сложность и стоимость процедур проектирования.
В заключение следует отметить, что развитие программно-вычислительных средств позволяет создавать так называемые виртуальные ХД, которые создаются над OLTP системами, ХД с многоуровневой архитектурой и так называемые встроенные ХД, которые встраиваются в существующую систему обработки данных организации.
О подходах к общим тенденциям в типовых решениях ведущих производителей ПО в области ХД можно познакомиться в издании Проектирование хранилищ данных для систем бизнес - аналитики: Учебное пособие /В.Е. Туманов — М.: Интернет-Университет Информационных Технологий: БИНОМ. Лаборатория знаний, 2010. Существует хорошая серия публикаций про различные варианты архитектур ХД на сайте IBM Developer.
Концепция ХД была предложена в начале 90-х годов прошлого столетия как основа методологии организации данных в системах поддержки и принятия решений. Согласно классическому определению В. Инмона, хранилище данных есть предметно-ориентированная, интегрированная, неизменяемая и поддерживающая хронологию электронная коллекция данных для обеспечения процесса принятия решений.
Данные поступают в ХД из внешних источников. Методика построения ХД предполагает выполнение ряда процедур преобразования и очистки данных внешних источников.
Использование ХД предполагает использование иных, чем в операционных системах обработки данных, методов построения модели данных.
Таким образом, в ХД хранятся:
На практике, для реализации хранилища данных используются СУБД, поддерживающие определенную модель данных. Поэтому с точки зрения реализации хранилище данных следует считать базой данных специальной структуры.
Компонентами типовой архитектуры хранилища данных являются:
Отметим, что в последнее время возрастает практический интерес к использованию ХД при формировании информационной инфраструктуры организаций. Преимущества, которые получает организация от внедрения хранилищ данных:
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.