некоторые из них, возможно, дополнить или отбросить. Этот процесс часто называют очисткой данных (data scrubbing).

Загрузочная ; секция

Пользователь Пользователь, создвющиО

OLAP-приложения нерегламентированные запросы

Данные

Данные

Денные

Техническая поддержка

Данные

Хранилище данн1.1х

Пользователь, создающий нврвглвмвнтированные запросы

Пользователь OLAP-приложения

Рис. 13 J Типичная ко/фигурация хранилища данных

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

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

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

Многомерные и пространственные модели

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

В версии 7.3 Oracle успешно реализовала ряд расширений своей реляционной базы данных с тем, чтобы при использовании Oracle Spatial Data Option система непосредственно поддерживала пространственные запросы. К сожалению, многие сотрудники Oracle (включая даже некоторых специалистов по маркетингу!), кажется, не могут разобраться в различиях между многомерной поддержкой (обращением к данным по нескольким внешним ключам) и пространственной поддержкой (обращением к данным по координатам). В этой главе рассматривается проблема многомерных данных; данные, конечно, могут иметь и пространственные свойства, но это уже другая тема.

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

SELECT welled, latitude, longitude, total barreles produced FROM oil wells WHERE latitude BETWEEN :latl AND :lat2 AND longitude BETWEEN :longl AND :long2;

Единственный эффективный путь решения этой задачи состоит в следующем. Необходимо разделить двумерное пространство на некоторое (больщое) число блоков, имеющих размер, например, 500 на 500 метров. Для каждой нефтяной скважины придется хранить данные о блоке, в котором она расположена. Условие запроса можно преобразовать в список уточняющих блоков, который будет служить основой индексного доступа. Каждая нефтяная скважина, находящаяся в уточняющем блоке, проверяется на предмет того, располагается ли она в пространстве, описанном в условии запроса. (Эта схема изображена на рис. 13.2.)

Рис. 13.2. Переход от двух измерений к одному Условие

WHERE X BETWEEN 3.8 AND 5.3 AND BETWEEN 2.2 AND 5.3;

теперь станет таким;

WHERE block IN {10,11,12,17,18,19,24,25,26,31,32,33) AND X BETWEEN 3.8 AND 5.3 AND у BETWEEN 2.2 AND 5.3;

К сожалению, список уточняющих блоков для некоторых запросов может быть очень длинным, поэтому в Oracle Spatial Data Option используется иерархический подход. Oracle Spatial Data Option - умная щтуковина, и вам почти наверняка придется ее купить, если вы столкнулись с проблемой пространственных данных. (Но к теме нащей главы это не относится).

Что отличает хранилище данных?

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

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