Хранилища данных: шаг за шагом

Брайан Моран,
SQL Server Magazine ONLINE, #01/2000

Как избежать распространенных, но тем не менее серьезных катастроф с хранилищами данных

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

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

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

Рисунок 1. Типовые потоки информации 1 - Оперативная система обработки транзакций 2 - Базы данных 3 - Запрос 4 - Данные 5 - Информация 6 - Отчет 7 - Составитель отчетов 8 - Потребитель информации

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

Рисунок 2. Самостоятельный анализ данных. 1 - Оперативная система обработки транзакций 2 - Базы данных 3 - Витрина данных OLAP 4 - Время 5 - Товар 6 - Территория 7 - Потребитель информации

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

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

Редко возникает необходимость разрабатывать развернутый план создания хранилища данных с нуля. Отличным помощником может стать книга Ральфа Кимбала, Лоры Ривс Мэри Росс и Уоррена Торнтуэйта "Инструментарий для полного жизненного цикла хранилищ данных: советы экспертов по проектированию, разработке и развертыванию хранилищ данных" (The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses), выпущенная издательством John Wiley & Sons в 1998 году. В этой книге разрабатывается образец проект хранилища данных, что позволяет проследить все этапы жизненного цикла хранилища, включая проектирование, разработку и внедрение. План проекта включает и кадровые вопросы, связанные с формированием команды. Приводимые сведения помогут читателям понять, какие технологические и производственные роли необходимы на каждом этапе построения и использования хранилища.

Представляет интерес и статья "10 причин неудач проектов построения хранилищ данных", подготовленная сотрудниками Института хранилищ данных. Ее можно найти в сети Web по адресу http://www.dw-institute.com/mistakes/dw-consultant.html. Если читатель никогда не строил хранилищ данных, то можно поучиться на чужих ошибках, перечисленных в данном документе. Убедитесь в том, что разработанные вами план проекта и методология не содержат указанных 10 ошибок. Это убережет вас от наиболее распространенных, но губительных для хранилищ данных катастроф.

Статья Джо Людке "Медленно меняющиеся размерности" вернет на землю тех, кто решил, что построить хранилище данных - не более чем просто установить службы OLAP и высветить на экране Мастер поворота таблицы (PivotTable Wizard) в Excel 2000. Как и в случае любого другого технологического решения, несложные задачи в хранилищах данных решаются легко. Более сложные задачи требуют более изощренных моделей и решений. Серьезные проблемы возникают тогда, когда деловая информация в хранилище данных со временем претерпевает изменения, и необходимо отслеживать различные уровни исторических данных. Читатель убедится, что решать проблему прослеживания динамики медленно изменяющихся данных в многомерной модели значительно труднее, чем решать аналогичную задачу в оперативных системах обработки транзакций (OLTP). Медленно меняющиеся размерности - это общепринятый термин, применяемый для описания проблемы изменчивых данных. Этим вопросам посвящены десятки книг разной глубины и широты охвата, в том числе и упоминавшаяся выше The Data Warehouse Lifecycle Toolkit. Несомненный интерес представляет и посвященная технологическим аспектам статья "Управление медленно меняющимися размерностями с помощью служб OLAP, входящих в состав SQL Server" (Managing Slowly Changing Dimensions Using Microsoft SQL Server OLAP Services). ЕЕ можно найти по адресу http://www.microsoft.com/sql/productinfo/dimensions.htm.

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

Об авторе:

Брайан Моран является президентом группы пользователей SQL Server в регионе Capital Area. Работает руководителем подразделения решений с использованием баз данных в компании CIBER Solutions. Сертифицирован корпорацией Microsoft в качестве преподавателя по Windows NT и SQL Server. Обладает сертификатами MCSE, MCSD и MVP.