36

Федеральное агентство по образованию

Новосибирский государственный университет экономики и управления

ЛАБОРАТОРНЫЙ ПРАКТИКУМ ПО ДИСЦИПЛИНЕ

«Базы данных»

Лабораторная работа N 15

«Хранилища и магазины данных. Технология OLAP»

Новосибирск 2007

1. Введение

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

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

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

1. Хранилища и магазины данных

Хранилище данных — это централизованный "склад" различных типов данных, собираемых со всего предприятия. Данные классифицируются по темам и по времени и организованы таким об­разом, чтобы их можно было легко проанализировать. Например, в хранилище данных может со­держаться информация о клиентах и об объемах продаж клиентам на протяжении последних пяти лет. Эти данные можно получить из нескольких отдельных систем управления предприятием. Но делать запросы в подобные системы с целью обнаружения тенденции - достаточно сложная задача. Создание хранилища данных — это процесс сбора, объединения, хранения и обслуживания информации, на основе ана­лиза которой руководитель может принимать важные решения.

Хранилище данных имеет сле­дующие характерные особенности:

• представляет собой "универсальный магазин", в котором содержится объединенная ин­формация, собранная со всего предприятия;

• поддерживает процессы принятия решений на основе имеющейся информации;

• заранее рассчитывает промежуточные и окончательные итоговые значения, что позволяет сократить время анализа информации;

• позволяет получить временные "срезы", помогающие в проведении бизнес-анализа;

• регулярно создает дампы информации и загружает их из оперативных источников.

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

Системы поддержки решений (Decision Support Systems — DSS) — это приложения, обеспечи­вающие проведение анализа данных, которые находятся в хранилище. С их помощью руководи­тель может узнать тенденции развития бизнеса и решить, каким группам продуктов нужно отдать предпочтение в ближайшее время и с какими клиентами работать. Системы поддержки решений наряду с хранилищами данных дают следующие преимущества:

• помогают руководителям преобразовать "голые" данные в осмысленную информацию;

• позволяют обнаружить главные тенденции развития бизнеса;

• помогают предвидеть события и действовать в их ожидании;

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

Системы интерактивной аналитической обработки (Online Analytical Processing-OLAP) - это своеобразный тип приложения для поддержки принятия решений. Они позволяют пользовате­лю запрашивать данные и просматривать их из различных перспектив. OLAP-приложения предос­тавляют следующие возможности:

• Консервация видов данных (обычные отчеты).

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

• Универсальные отчеты, получаемые с помощью специальных запросов.

• Прогнозирование, анализ типа "что если", предсказание результатов.

С помощью инструментов DSS или OLAP конкретную информацию можно получить, задавая следующие типичные вопросы:

• Какая группа клиентов делает заказы по каталогам и ждет до последней минуты, чтобы ку­пить подарки к Рождеству (Новому году)?

• Сколько клиентов (в процентном отношении) позвонили в течение первых нескольких ме­сяцев после создания специальной телефонной службы?

• Какая группа клиентов обеспечивает 80% дохода фирмы? Учитывается ли эта группа кли­ентов при подготовке очередной рекламной кампании?

• Сколько раз конкретный клиент посетил электронный магазин на Web-узле, прежде чем сделал покупку?

• Где именно большинство пользователей покидают этот Web-сайт?

и т.д.

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

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

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

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

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

Таблица 1.

Сравнение СУБД и хранилища данных

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

На рис. 1 показана основная структура хранилища данных.

Рис.1 Среда, в которой функционирует хранилище данных

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

• СУБД предприятия. Это OLTP-системы, которые повседневно используются в организа­ции. Они могут быть рассредоточены по предприятию и предоставлять специальные воз­можности различным отделам.

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

• Метаданные. Так называются данные, которые содержатся в хранилище, Это те данные, которые были взяты из первоначального источника, а затем преобразованы и загружены в хранилище.

• Хранилище данных. В это понятие входит аппаратное обеспечение сервера и базы дан­ных, на которых строится хранилище данных. Оно может представлять собой одно цен­тральное хранилище данных или несколько специализированных магазинов данных.

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

Магазин данных (Data Mart) — это "склад" данных, собранных из СУБД или других источников, который предназначен для использования конкретным отделом или группой. По сравнению с хранилищем магазин данных - это нечто менее общее и более специализированное. Назначение магазина данных - удовлетворить потребности конкретно­го отдела в плане анализа, содержания, представления данных и простоты в использовании. Инфор­мация в магазине данных сохраняется в привычном для пользователей формате.

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

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

• быстрая окупаемость;

• простота доступа;

• оптимизация запросов.

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

Рис.2. Магазины данных и хранилище данных

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

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

Хранилище данных — это централизованное объединение данных. Магазины данных можно создать на основе хранилища данных, хранилище данных также можно создать на основе несколь­ких специализированных магазинов. Назначение магазина данных — простота доступа и ориента­ция на конкретный отдел предприятия. В целом, можно сказать, что хранилище данных - это стратегическая цель, которая часто достигается не полностью; а магазин данных - это тактиче­ская цель, направленная на удовлетворение текущих потребностей. В табл. 2 приведены основ­ные различия между хранилищем и магазином данных.

Таблица 2.

Основные различия между хранилищем и магазином данных

Хранилище данных	Магазин данных
Использование всем предприятием	Использование конкретным отделом или подразделением
Сложный, долгий и трудоемкий процесс реализации	Простая и быстрая реализация
Большой объем информации	Небольшой объем информации; данные специализированы
Разрабатывается на основе данных, которые имеются в наличии в настоящий момент	Разрабатывается на основе данных, необходимых пользователю

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

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

Главный вопрос, который возникает при разработке "склада" данных любого типа, — как пре­вратить "голые" данные в информацию, в которой вы нуждаетесь. Этот процесс называется пре­образованием данных. Очень редко данные в том виде, в каком они существуют в OLTP-системах, можно непосредственно использовать для принятия решений. Как правило, из необъятного моря информации нужно выбрать только самое необходимое. Может оказаться, что только 10 столбцов таблицы базы данных, в которой содержится примерно 50 столбцов, необходимы для соответст­вующего бизнес-анализа.

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

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

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

В хранилище данных можно объединить отдельные части каждой СУБД в одной общей табли­це клиентов. Например, из СУБД финансового отдела можно взять счета клиентов, из СУБД отдела сервиса - информацию о заключенных ими сервисных договорах, из СУБД отдела марке­тинга - адреса и телефоны клиентов, а затем объединить все это в единое целое.

Но если в двух СУБД используются различные типы данных для одного и того же номера сче­та, то ситуация в корне меняется. Счет 000125 в СУБД 1 может соответствовать счету 125 в СУБД 2. В таком случае необходимо решить, какой из двух форматов является оптимальным, и придерживаться его; именно в этом формате будут сохраняться данные в хранилище.

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

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

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

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

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

Каких правил нужно придерживаться при выборке данных? Будут ли выбираться все данные или только новые и модифицированные? В идеале, в хранилище данных загружается только новая информация. Но иногда это не так просто, как кажется. Если в СУБД не используется какая-либо форма журнала транзакций (как в SQL Server), для определения изменений, произошедших со времени последнего обновления, могут потребоваться значительные усилия. Информацию, каким-либо образом связанную со временем (заказы, заявки, накладные), можно выбрать с помощью простых запросов с указанием даты. А вот найти изменения в статичной информации (о клиентах, поставщиках, товарах и т.д.) гораздо сложнее. Для этой цели можно создать некоторую процедуру проверки или просто обновить все статичные таблицы. Здесь придется выбирать между созда­нием эффективных программ для работы с хранилищем данных и скоростью его реализации.

Выборка данных может включать в себя процедуры, работающие с существующими источни­ками данных, например триггеры или работы, выполняемые по расписанию, Примером может служить пакетная работа для СУБД отдела продаж, которая экспортирует все новые заказы това­ров, сделанные в последнее время, в файл дампа, из которого информация загружается в хранили­ще данных. В таком сценарии выборка и загрузка данных- это два отдельных процесса. Но су­ществует и альтернативный метод, когда инициализация источника получения данных, обновле­ние, выборка и загрузка выполняются одновременно. Это можно осуществить с помощью службы преобразования данных (DTS) SQL Server 7.0. Например, пакет DTS, периодически выполняемый по расписанию, может импортировать все новые заказы, попадающие в заданный временной диа­пазон. Когда хранилище данных будет создано, основная часть его работы будет заключаться в периодическом использовании программ обновления информации.

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

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

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

Один из важнейших вопросов, стоящих перед разработчиком хранилища данных – какой подход выбрать: двигаться сверху вниз, создавая структуру для всего предприятия, а затем разделять её на отдельные потоки, или, наоборот, двигаться снизу вверх, начав с создания специализированных магазинов данных, информация из которых будет затем объединяться в единое целое?

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

Чтобы получить оптимальные результаты в далекой перспективе, следует выбрать метод "сверху вниз". Трудностей, связанных с этим подходом, можно избежать, если сразу определить все стан­дарты и требования, предъявляемые к данным. Тогда все трудности, связанные с затратами време­ни и денег, будет гораздо легче преодолеть.

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

В традиционной модели связей между элементами (ER - entity relationship) используется нор­мализованный подход к планированию базы данных. Нормализация позволяет удалить из структу­ры лишние элементы, чтобы оптимизировать объем сохраняемой информации. Для хранилища данных вопросы объема сохраняемых данных не так критичны; гораздо важнее обеспечить про­стоту доступа к информации со стороны пользователя. Поэтому некоторая степень избыточности информации обычно считается приемлемой. Для разработки структуры хранилища данных более приемлемым является подход, при котором используется пространственное моделирование. Сюда входит разработка структуры, при которой общая работа предприятия делится на логические со­бытия или факты и применяется набор соответствующих измерений.

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

Рис.3. Пример звездообразной структуры

Ниже приведен распространенный запрос к описанной выше структуре. В ответ на этот запрос выдаются сведения о клиентах, которые приобрели некоторый товар в октябре 1996 года:

SELECT c.customer_ID, name, address, sum(qty sold)

FROM sales s, time t, product p, customer с

WHERE month=10 AND year=1996 AND upc_code=8989764 AND

s.time id = t.time id AND

s.customer_id = c.customer_id AND

s.product_id = p.product_id

GROUP BY c.customer_id ORDER BY c.customer_id

Центральная таблица фактов (fact table) обычно состоит из событий бизнеса, которые связаны со временем, например банковских транзакций, продаж, заказов, возвратов, отгрузки и посещения Web-узлов. Как правило, такие таблицы содержат внешние ключи к размерным таблицам и набор числовых значений. Информация, сохраняемая в таблицах фактов, обычно статична (т.е. не меня­ется), поскольку речь идет о том, что уже произошло (т.е. стало историей). Самый распространен­ный пример таблицы фактов в звездной структуре — это таблица продаж.

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

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

Существует несколько вариантов классической звездообразной структуры. Иногда к размер­ным таблицам применяется нормализация, при которой они связываются друг с другом. В резуль­тате получается структура, которая называется "снежинкой" (рис. 4).

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

Рис.4. Пример структуры "снежинка " со связями

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

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

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

• Расписание загрузок. Как часто нужно загружать информацию из исходных СУБД? Когда нужно выполнять эту загрузку?

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

• Настройка параметров запросов. Обслуживание хранилища данных может предусматри­вать предоставление пользователям фиксированных запросов или сокращение времени от­вета путем изменения индекса или структуры таблиц базы данных.

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

Ге­терогенные запросы позволяют объединять результирующие наборы из нескольких источников данных OLE DB или ODBC. Кроме того, существуют службы преобразования данных (DTS), склад (Repository) для хранения метаданных, OLAP-срелства для принятия решений (Decision Support Services) и Microsoft English Query (выполнение запросов на английском языке). Основу службы интерактивной аналитической обработки Microsoft SQL Server (Microsoft SQL Server Online Analytical Processing - OLAP) составляет специальное ядро базы данных, разрабо­танное фирмой Microsoft для SQL Server 7.0.

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