чтению. Этот метод заключается в использовании предложения SET TRANSACTION READ ONLY. Но просматривать данные таким образом можно лишь в течение относительно короткого промежутка времени (его длительность ограничена размером сегментов отката).

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

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

Многие ООТ-системы хранят данные только за короткий промежуток времени (или вообще не хранят исторические данные). В силу этого они вряд ли будут полезны для анализа тенденций.

Поскольку данные большей частью используются приложениями, созданными специалистами по информационным технологиям, они часто содержат закодированные значения и непонятные имена. Кроме того, эти данные могут включают таблицы, которые не имеют реальной ценности для бизнеса, а созданы для реализации какого-то проектного решения. Все это делает данные трудными для понимания конечными пользователями. За деревьями они не могут увидеть леса, а если и увидят этот лес, то без конвертирования он никакого смысла для них не имеет. Этот недостаток в некоторой степени можно устранить с помошью представлений. Однако длины имен представления и столбцов в представлении ограничены 30-ю символами, и это часто не позволяет понятно описать назначение тех или иных данных. Например, столбец AUTO ACK YN таблицы в представлении можно назвать SEND AUTO-MATIC ACKNOWLEDGEMENT, но хороший пользовательский инструмент для запросов должен поддерживать более информативные имена, а иногда и имена с пробелами.

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

Если необходимо выполнять нерегламентированные запросы к живым данным, то, вероятно, потребуется назначить для этого определенное время суток, не критичное для деятельности предприятия. Ведь нельзя

on 4

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

Хранилища данных не возникли за один день, а развились из систем поддержки принятия решений (СТТПР - DSS) и информационных систем руководителей (ИСР - EIS). Эти системы традиционно работали с данными, которые были идентичны данным в той операционной системе, где сопровождались эти данные; такие системы обращались либо к живым данным, либо к их последней неизменяемой копии. Хранилища данных не обязательно берут непосредственные копии рабочих данных из ООТ-систем. Их таблицы строятся на рабочих данных, но, как правило, включают только те детали, которые касаются процесса принятия решений. Принадлежащие вашей организации данные, конечно, представляют интерес, но если их объединить с общими данными о рынке, в том числе о ваших конкурентах, то такая информация приобретает совершенно новое значение. Источниками данных для хранилища могут являться маркетинговые агентства, а также различного рода сервисные системы, например система агентства Рейтер.

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

Проблемы проектирования

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

данных. Эти требования обусловлены следующими свойствами хранилищ данных:

Хранилища данных, как правило, представляют собой большие (часто очень большие) базы данных.

От них требуется высокая скорость обработки данных.

Физическое расположение данных должно выполнятся так, чтобы обеспечивать оптимальное выполнение запросов.

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

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

Такие традиционные методы, как нормализация данных, основаны в первую очередь на том, чтобы избежать избыточности данных, а также сбалансировать требования к выполнению запросов и требования к выполнению DML-операций. Как мы видели в главе 3, в процессе нормализации порождается большое число таблиц. Однако большое число маленьких таблиц, как правило, является полной противоположностью тому, что лучше всего обслуживает хранилище данных. По этой причине для хранилищ данных неприменимы некоторые ключевые принципы традиционного реляционного проектирования. Даже моделирование сущностей не совсем подходит для хранилищ данных, и это породило метод, известный как многомерное моделирование, который позволяет получать базы данных, более удобные для перемещения и запросов. Многомерное моделирование мы рассмотрим позже, а пока просто введем понятие таблицы фактов. Это таблица, которая предназначена для хранения всех фактов, представляющих интерес для хранилища, например перемещения запасов, продажи товаров и т.д.

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