Масштабируемость аналитических систем

Как это сделано в Microsoft SQL Server 2000 Analysis Services. Часть 2.

Процессинг

Под процессингом куба имеется в виду расчет агрегатов и наполнение структуры куба агрегатами и детальными данными. Как мы уже знаем, в случае ROLAP агрегаты будут храниться в таблицах или представлениях реляционного источника. В случае HOLAP или MOLAP агрегаты помещаются в специальную многомерную структуру. Перенос в многомерную структуру детальных данных происходит только в том случае, если выбран формат хранения MOLAP, что несколько увеличивает время процессинга, но впоследствии позволяет повысить скорость обработки аналитических запросов. Процессинг добавляет в куб изменения, произошедшие в транзакционных источниках. Процессинг выполняется в определенные моменты времени по команде администратора либо по расписанию. Задача процессинга входит в список стандартных заданий DTS, кроме того, ее можно выполнить программным путем при помощи DSO.

В зависимости от ситуации для куба можно выбирать один из трех вариантов процессинга. Первый вариант — дифференциальный процессинг (incremental update) — соответствует ситуации штатной работы, когда куб пополняется изменениями, наработанными транзакционным приложением, скажем, за последний день, и на основе этих изменений досчитываются кумулятивные агрегаты. Это наиболее быстрый вариант процессинга. В этом случае Analysis Services создает временный раздел по условию фильтра, установленного администратором (например, Время = Текущий день), обрабатывает его, а затем добавляет к основному разделу куба (если куб состоит из нескольких разделов, то раздел-назначение необходимо оговорить особо). Второй вариант - обновление куба (refresh data) - применяется, когда в транзакционных источниках изменились данные, уже перемещенные в куб (например, если задним числом была сделана проводка, филиалы прислали корректировки и т. д.) В этом случае существующий куб очищается, данные в него перезагружаются и агрегаты пересчитываются заново. Наконец, третий вариант - полный процессинг (full processing) - представляет собой предыдущий вариант плюс пересчет всей структуры агрегатов (а не только их значений). Он используется при создании нового куба, а также в случае изменения его структуры, например при удалении или добавлении новых измерений. Это наиболее длительный вариант процессинга. Использование нескольких разделов позволяет гибко настроить процедуру процессинга. Одной из типичных ситуаций, например, может быть разбиение куба на разделы, соответствующие периодам времени T1, T2, T3, где T1 - относительно небольшой актуальный период, за который, как правило, происходят изменения (этот раздел будет обрабатываться во время каждого процессинга); T2 - изменения допускаются, но происходят относительно редко, он будет обрабатываться только в случае этих изменений; T3 - архивные данные. Скажем, T1 - текущий год, T2 - прошлый, и T3 - вся остальная история предприятия. Процессинг T2 скорее всего потребуется в начальный период текущего года, когда раздел T1 еще не очень велик, и длительность его процессинга незначительна. Следует иметь в виду, что при произвольном изменении условия фильтра раздела может потребоваться повторная обработка всего куба.

Процессинг измерений бывает двух видов: Incremental Update и Rebuild Dimension Structure. В первом случае источник измерения прочитывается заново, определяются (по Member Key) новые члены, которые добавляются в измерение. Второй способ, как следует из названия, заново перестраивает структуру измерения и применяется в случае добавления/удаления уровней и других изменений в иерархии, например при переподчинении членов между родителями. Для появившихся в SQL Server 2000 медленно меняющихся измерений (см. ниже) перечень ситуаций, требующих перестройки структуры, значительно ослаблен. Перестройка структуры измерения влечет за собой полный процессинг всех кубов, что не позволяет работать с данными кубами в течение этого времени. Сказанное до сих пор относилось к так называемым общим измерениям, которые существуют как не зависимые от куба сущности и могут входить в несколько кубов в пределах одной базы данных. Частные измерения - это измерения, которые незаметны вне того куба, где они были определены. Для частных измерений Incremental Update соответствует Refresh Data куба, а Rebuild Structure - Full Processing.

Во время процессинга запросы к транзакционным данным генерируются автоматически с использованием стандартного синтаксиса SQL. Длительность процессинга, таким образом, складывается из двух этапов: времени выполнения запроса на чтение операционным источником и обработки полученных результатов собственно в Analysis Services. Для исследования эффективности первого этапа можно оценить время выполнения запроса, который формируют Analysis Services (см. View Trace Line), встроенными средствами СУБД, используемой в транзакционном приложении. Например, в случае SQL Server для этого можно воспользоваться утилитой SQL Profiler. Отредактировать текст формируемого запроса невозможно. Как уже отмечалось, в качестве реляционных ресурсов для Analysis Services допускается широкий спектр OLE DB- и ODBC-источников, поэтому отсутствие возможности влиять на запрос является своего рода платой за универсальность. Можно порекомендовать, например, создать в операционном источнике представление, в определение которого заложить все необходимые предикаты, параметры оптимизатора и проч. Дополнительная настройка может быть проведена с помощью корректировки свойств OLE DB-соединения в определении источника данных многомерной БД. Оптимизация структуры куба (Cube Editor -> Tools -> Optimize Structure) позволяет выявить и устранить лишние связи между таблицами. Например, Analysis Services идентифицирует члены измерения внутри уровня по Member Key Column. Как правило, в этом качестве выступает первичный ключ таблицы измерения. Если по этому же ключу таблица измерения связана отношением «один ко многим» с таблицей фактов, система предложит использовать внешний ключ таблицы фактов, что позволит сэкономить на довольно дорогом операторе join. В целом для типа и размера Member Key справедливы те же рекомендации, что и для индексного ключа. Чем короче ключ, тем меньше места требуется на его хранение и тем быстрее выполняется операция сравнения. Целочисленные ключи практически всегда выигрывают по сравнению со строковыми. На втором этапе в SQL Server 7.0 для каждого раздела выделялись два параллельных потока: Reader и Proces-sing/Aggregation. Первый добавлял результаты запроса в буфер опережающего чтения, второй - вычислял агрегаты и переносил (MOLAP) детальные данные в многомерную структуру, периодически (в целях экономии памяти) сбрасывая результаты на диск во временный каталог OLAP сегментами по 64 Кбайт. Таким образом, использование более чем двухпроцессорных конфигураций в предыдущей версии не давало выигры-ша в скорости процессинга раздела.

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

OLAP реального времени

Классический OLAP предполагает отражение изменений, произошедших в транзакционных источниках, не непрерывно, а в определенные моменты времени. Частота синхронизации куба может колебаться в самых широких пределах в зависимости от природы приложения, скорости обновления и объемов данных. В ситуациях крайне динамично развивающихся бизнес-процессов, когда значительная часть данных в хранилище устаревает очень быстро, а аналитик должен работать не с исторической, а с постоянно обновляемой информацией (например, биржевые торги), такой подход неприемлем. Требуется сразу по мере поступления даже одиночной транзакции отражать ее в кубе и пересчитывать с ее учетом агрегаты. Приложения подобного рода относятся к области OLAP реального времени (real-time OLAP).

В SQL Server 7.0 основным способом поддержки OLAP-приложений реального времени было создание над таблицей фактов в реляционном хранилище ROLAP-раздела без каких бы то ни было агрегатов. Для этого в Design Storage Wizard необходимо среди параметров Aggregation options выбрать Until I click Stop и нажать Next. Кроме того, кэш не должен содержать устаревших данных, для чего его необходимо очищать всякий раз, когда происходит обновление таблицы фактов. Это можно сделать следующим образом. В DTS-пакете перед фиксацией транзакции, пополняющей хранилище, ставим команду dsoCube.Process processSuspend, что блокирует поступающие к кубу запросы от пользователей, ставя их в очередь на время, указанное в HKLMSOFTWAREMicrosoftOLAP ServerOlap Manager InfoSuspendTimeout (в мс). После этого производим подтверждение (commit) транзакции в реляционном хранилище и восстанавливаем работу куба командой dsoCube.Process processResume, которая попутно очищает серверный кэш. Такое решение повышало актуальность отражения изменений в кубе, но одновременно приводило к существенному возрастанию времени выполнения аналитических запросов, поскольку мы видим здесь сочетание сразу трех факторов, негативных с точки зрения быстродействия: ROLAP, отсутствие агрегатов и регулярная чистка кэша.

Появившаяся в SQL Server 2000 поддержка ROLAP-измерений и индексированных (материализованных) представлений (indexed views) позволяет реализовать систему OLAP реального времени ценой меньших усилий с точки зрения администрирования. Если форматом хранения раздела куба является ROLAP, Analysis Services по умолчанию пытаются создать индексированное представление для хранения агрегатов данного раздела. В отличие от классических, индексированные представления (см.[9]) содержат не только определение запроса, но и его результаты, которые обновляются всякий раз, когда происходят изменения в исходных данных. С этой точки зрения индексированные представления ведут себя подобно обычным индексам, что позволяет поддерживать содержащиеся в них агрегаты в постоянно актуальном состоянии. Специально выделенный поток (listener thread) служит средством коммуникации, с помощью которого аналитический сервер получает от реляционного источника данные об изменениях, произошедших в таблицах, соответствующих ROLAP-разделам и ROLAP-измерениям, и автоматически обрабатывает их в фоновом режиме, очищая серверный кэш. Включение оповещений достигается установкой свойства Enable Real-Time Update при создании ROLAP-раздела или ROLAP-измерения. Использование OLAP реального времени налагает определенные ограничения, так как в качестве реляционного источника при этом должен использоваться только SQL Server 2000 (иначе не будет работать механизм оповещений), причем, очевидно, Enterprise Edition (должны присутствовать индексированные представления). Аналитический сервер также должен быть построен на основе SQL Server 2000 Enterprise Edition, так как функциональность ROLAP-измерений включена только в эту версию, как отмечалось выше. ROLAP-разделы, построенные на основе индексированных представлений, не могут включать меры с агрегатными функциями min(), max(), должны основываться на таблицах (не на представлениях), источником меры должно быть поле типа not null и т. д.

Платой за реальное время остаются потери в скорости выполнения OLAP-запросов. SQL Server 2000 позволяет их снизить, допуская непустое множество агрегатов за счет поддержки индексированных представлений. Кроме того, гибкая архитектура куба предполагает дальнейшую оптимизацию. Например, можно разбить куб на два раздела: меньший, ROLAP, соответствующий ситуации реального времени, основанный на данных, скажем, текущего месяца, и MOLAP-раздел, содержащий всю остальную историческую информацию. Несколько модифицированный вариант этой идеи состоит в том, чтобы создавать не разделы, а отдельные кубы для текущих и архивных данных и строить объединяющий их виртуальный куб, с которым и будут работать конечные пользователи.

Изменяющиеся измерения

Так же как и факты (меры), члены измерений со временем могут меняться: в номенклатуру сбыта добавляются новые продукты, сотрудники переходят в другие подразделения и т. д. Темп таких изменений существенно ниже, чем у фактов (в противном случае следует задуматься о перепроектировании хранилища), поэтому их еще называют медленно меняющимися измерениями (slowly changing dimensions). В литературе (см. [10]) выделяют три типа медленно меняющихся измерений. Их программная реализация средствами SQL Server разбирается в статье [11]. Мы же поговорим о новом свойстве измерений, появившемся в SQL Server 2000, которое позволяет снизить затраты на процессинг при внесении изменений.

В случае регулярного измерения внутренний ключ члена измерения содержит ссылки на его родителей вышележащих уровней, что напоминает полное имя файла с указанием пути, представленное в виде сжатого набора битов. Отсюда вытекает, что мы можем свободно добавлять в измерение новые члены, для этого достаточно Incremental Update, в то время как перемещение члена между родителями или по уровням вызывает необходимость Rebuild Dimension Structure с последующей полной обработкой всех кубов, в которые оно входит, и другими малоприятными для оперативной работы следствиями. Использование изменяющихся измерений позволяет избежать этих отрицательных факторов и по-прежнему обходиться дифференциальным процессингом. Тем не менее очевидно, что структура агрегатов измерения после такого рода изменения станет недействительной, поэтому все агрегаты изменяющегося измерения между самым верхним и самым нижним уровнем иерархии помечаются как «мягкие» (soft) агрегаты. Когда Analysis Services обнаруживают изменения в иерархии, «мягкие» агрегаты всех кубов, ее использующих, удаляются и рассчитываются заново в фоновом режиме. Ключевым преимуществом здесь является то, что кубы не блокируются в монопольном режиме, и пользователи могут с ними работать в течение всего процесса пересчета. Недостаток же состоит в том, что, если пользовательскому запросу требуется еще не пересчитанный агрегат, он будет рассчитываться на основе детальных данных, что приведет к снижению производительности некоторых аналитических запросов на время фонового пересчета. Кроме того, администраторы должны иметь в виду, что изменяющееся измерение нельзя использовать для «нарезания» куба на разделы, должны браться срезы по обычным измерениям. Это очевидно: поскольку раздел содержит данные для определенного подмножества членов, перемещение члена внутри целого дерева может привести к тому, что он будет относиться к другому разделу и структура куба станет недействительной. Incremental Update не отражает удаления записей в таблице измерения. Удаленные члены остаются видны в иерархии, поэтому добавление новой записи с ключом удаленной записи во время обработки куба приведет к ошибке member keys not unique (если свойство уникальности ключей было выставлено в True). Следовательно, как обычные, так и изменяющиеся измерения требуют полной повторной обработки в случае удаления членов. Превращение обычного измерения в изменяющееся производится при помощи свойства Changing. Кроме того, по определению, изменяющимися всегда являются виртуальные и ROLAP-измерения, а также измерения типа «родитель-потомок».

Измерения с возможностью прямой записи (writeback dimensions) позволяют вносить и распространять изменения в обратном порядке: из OLAP в операционный источник. Для таких измерений допускается модификация их членов: добавление, удаление, редактирование, передвижение по иерархии, изменение пользовательских свойств и т. д. непосредственно на стороне OLAP. Эта функция появилась в SQL Server 2000, и она несколько отличается от поддержки прямой записи в куб (write-enabled cubes), существующей с предыдущей версии. При модификации куба изменения накапливаются в специально создаваемой промежуточной таблице, сами значения ячеек не изменяются и в транзакционную базу данных не попадают. Результат пользовательского запроса к ячейке складывается из величины хранящегося в ней факта, скорректированного на сумму накопленных для нее модификаций, содержащихся в writeback-таблице. Таблица затем может быть преобразована в самостоятельный раздел (и тогда сделанные изменения фактически войдут в состав куба) либо аннулирована (ситуация запросов типа «что если»). В отличие от записи в куб, прямая запись в измерение является действительно «прямой» в том смысле, что сделанные изменения не складываются в промежуточный буфер, а распространяются непосредственно в транзакционную базу данных (разумеется, при наличии на эту операцию соответствующих прав у учетной записи, под которой работает MSSQLSer-verOLAPService). Прямая запись возможна только в SQL Server 2000 Enterprise Edition, причем только в случае измерений типа «родитель-потомок», которые, как уже отмечалось, всегда являются изменяющимися. Для этого используется свойство Write-enabled. После того как измерение стало доступным для прямой записи, необходимо повторно обработать все кубы, в которые оно входит. Для кубов, распределенных по нескольким серверам, прямая запись в измерение не поддерживается.

Виртуальные и зависимые измерения

Элементарным реляционным представлением регулярного (количество уровней одинаково по каждой ветви) измерения может служить таблица, где каждому уровню соответствует свое поле. Представим себе, что существует поле, которое в рамках бизнес-логики данного приложения «не дотягивает» до того, чтобы претендовать на звание отдельного уровня ни в одной из иерархий, но значения которого нам впоследствии могут понадобиться для анализа. Например, по измерению «Магазины» мы создали иерархию «География», чтобы проанализировать продажи в зависимости от местоположения. Поле «Площадь торгового зала» в эту иерархию не вписывается, тем не менее, возможно, будет интересно узнать, как влияет размер торговой площади на объем продаж. В таком случае проще всего создать на одном из уровней (вероятно, детальном) иерархии «География» пользовательское свойство (member property), в котором и хранить данные о площади магазина. Возникает вопрос: что делать, если продажи захочется проанализировать в разрезе «География - Площадь зала»? Эти сущности хранятся в одном измерении, следовательно, их нельзя разнести по разным осям. Можно, например, создать новое измерение, каждый член которого равен пользовательскому свойству другого. Итак, перед нами элементарный пример виртуального измерения. Как следует из названия, члены виртуального измерения не хранятся на диске, а вычисляются всякий раз по мере необходимости на основе уже имеющейся информации. Несмотря на то что поддержка виртуальных измерений существовала и в предыдущей версии, она была связана с многочисленными ограничениями. Число членов было ограничено 759, виртуальное измерение не могло содержать более одного уровня (за исключением уровня All), не могло содержать пользовательских свойств, не могло быть частным, преобразовываться в обычное и т. д. В SQL Server 2000 все эти ограничения сняты. Кроме того, виртуальные измерения теперь могут ссылаться напрямую на поле в реляционной таблице без необходимости создания специального пользовательского свойства. Вообще, в Analysis Services сняты или ослаблены многие ограничения, существовавшие раньше, что значительно расширяет степень масштабируемости. Максимальная размерность куба увеличена вдвое и составляет теперь 128, максимальное количество членов измерения благодаря поддержке ROLAP-измерений теоретически неограниченно и т. д. Одним из немногих оставшихся жестких ограничений является количество дочерних членов: каждый член измерения не может иметь более 64 000 «детей». Это ограничение преодолевается путем создания промежуточного уровня и присвоения его свойству Grouping = Automatic. Сервер сам определит необходимые узлы этого уровня, автоматически объединяя члены нижележащего уровня в группы (member groups) и упорядочивая их в соответствии со свойством Order By. Администратор может затем скрыть этот промежуточный уровень (свойство Visible), если считает, что аналитику удобно работать с узлом, из которого выходит несколько десятков тысяч ветвей. Поскольку автоматическое группирование работает надо всем уровнем в целом, нецелесообразно применять эту методику для разбалансированных структур, например, когда каждый родитель имеет 5-10 «детей», а какой-нибудь пресловутый «Прочее» - десятки тысяч. Хотя, по-видимому, в этом случае вызывает сомнение правильность построения измерения. Для ROLAP-измерений Member groups не поддерживаются.

Вычисление виртуального измерения на лету увеличивает время выполнения многомерных запросов с его участием. Так что если соображения производительности превалируют, виртуальное измерение имеет смысл «девиртуализовать», превратив в обычное. Однако в этом случае бывшее виртуальное измерение и то измерение, от которого оно зависит, будут рассматриваться Analysis Services как независимые сущности, что влечет за собой создание заведомо пустых ячеек. Например, если измерение «Пол» получено из пользовательского свойства измерения «Клиент», половина их декартова произведения — абсолютно невозможные ситуации, так как каждый клиент имеет не более одного пола. Чтобы отсечь пустоты и сэкономить место на диске, измерение «Пол» следует отметить как зависимое (dependent) от измерения «Клиент». Для этого используется свойство Depends on Dimension. Структура агрегатов зависимого измерения также обусловлена измерением, от которого оно зависит. Все виртуальные измерения, по определению, являются зависимыми, хотя агрегаты для них не считаются.

Неаддитивные агрегаты.

Мера типа DISTINCT COUNT

Основные агрегатные функции мер носят, в основном, кумулятивный характер. К ним относятся аддитивные меры, мультипликативные меры (при желании их можно прологарифмировать и превратить в аддитивные), агрегаты MIN(), MAX() и т. п. Они хороши тем, что по ним легко производить свертку, следовательно, можно очень быстро получать результаты rollup() для членов верхних уровней иерархии, выводить недостающие агрегаты на основе известных, пересчитывать имеющиеся при дифференциальном обновлении - выигрыш в производительности достигается для различных ситуаций. Кроме того, эти меры изотропны: по всем измерениям свертка происходит одинаковым образом. Тем не менее для решения ряда задач необходимы агрегаты иной природы. Допустим, у нас имеется нефтеперерабатывающее предприятие, на котором учет отгрузок ведется нарастающим итогом с начала месяца. Мы можем суммировать объемы ГСМ по продуктам (например, общее количество бензина складывается из Аи-76, 92, 95, 98, ...), заводам и т. д., но не по дням, поскольку общая отгрузка за месяц, очевидно, равна значению за последний день месяца, а не сумме всех его дней. В то же время для высших уровней того же измерения аддитивность может восстанавливаться. Например, для квартала учет уже может вестись не нарастающим итогом по месяцам, а, как обычно, складываться из месяцев. Меры, аддитивность которых в силу их анизотропии по некоторым измерениям нарушается (хотя бы для одного уровня, как в нашем случае), называются полуаддитивными (semiadditive measures). Некоторые примеры реализации полуаддитивности на основе вычисляемых мер (calculated members) SQL Server разбираются в [12]. В SQL Server 2000 Analysis Services появилась возможность назначать для каждого уровня измерения свою формулу свертки в виде оператора MDX (свойство Custom Rollup Formula). Так, в предыдущем примере можно было бы написать для уровня «Месяц»: [Время].CurrentMember.LastChild.

Типичной иллюстрацией неаддитивной меры может служить обширный класс задач, обычно связанных с изучением спроса или анализа потребительской корзины. Допустим, администратор proxy-сервера обнаружил за день из своей локальной сети 500 посещений различных внешних сайтов. Для определения самого популярного среди них требуется отфильтровать повторные хождения на данный сайт одного и того же сотрудника, так как его предпочтения уже известны. В отличие от обычного COUNT мера DISTINCT COUNT неаддитивна. Действительно, 100 уникальных заходов на технологические сайты, 200 на новостные и 300 на развлекательные не означает, что у вас работает 600 сотрудников, так как каждый сотрудник в течение дня мог посещать сайты разных категорий. В предыдущей версии для такого подсчета можно было использовать вычисляемую меру с MDX-выражением типа

Count( Filter (Descendants( 
[Сотрудники].CurrentMember, [Сотрудники]
.[Имя]), ([Посещения],[Веб-сайты].
[Категория сайта].[Новостные]) > 0)).

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

Вообще, раз уж мы говорим о способах наращивания масштабируемости, следует напомнить простую истину. Как и в случае реляционных SQL-приложений, некорректно построенные запросы способны «похоронить» производительность даже при блестяще продуманной архитектуре. Если у вас установлены Analysis Services, откройте модельную базу данных Foodmart 2000 и попытайтесь получить список всех городов Калифорнии, жители которых совершали покупки в Беверли-Хиллз в рамках программы Big Time Savings. Очевидный путь решения

Filter(Crossjoin([Store].
[Beverly Hills].Children, [Customers].
[CA].Children), NOT IsEmpty
([Pro-motions].[Big Time Savings]))

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

NonEmptyCrossJoin: SE-LECT 
NonEmptyCrossJoin([Store].
[Beverly Hills].Children, [Customers].
[CA].Children, {[Promotions].
[Big Time Savings]},2) 
ON COLUMNS FROM Sales WHERE 
[Measures].[Unit Sales].

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

В SQL Server 2000 появилась новая агрегатная функция Distinct Count, которую можно использовать в мерах. Как и в предыдущих примерах, эта мера используется для того, чтобы определить для каждого члена измерения, сколько различных листовых членов другого измерения имеют в таблице фактов соответствующие записи. Т. е. если один и тот же член (идентифицируется по внешнему ключу таблицы фактов) встречается несколько раз, он считается лишь единожды. Этот способ по простоте и скорости работы гораздо предпочтительнее вычисляемой меры. Источниками меры такого типа служат только численные поля или даты. Мера Distinct Count (в отличие от Count) не может основываться на строковых типах, uniqueidentifier и др. В регулярном кубе может быть только одна мера типа Distinct Count, при этом его измерения не должны содержать пользовательских формул свертки. Для виртуальных кубов таких ограничений нет. Кроме того, поскольку наличие неаддитивной меры значительно ограничивает возможности предварительной агрегации куба, с точки зрения производительности лучше распределить аддитивные и неаддитивные меры по разным кубам, используя их объединение в виде виртуального куба как единое представление, с точки зрения конечного пользователя.

Заключение

Рассмотренные в статье проблемы носят, в основном, технологический характер. Вполне очевидно, что хранилища данных, как и любая другая технология, привнося неоспоримые преимущества, тем не менее дают их не задаром (см. [14]), что особенно ярко проявляется при внедрении на крупных предприятиях. Качество конкретного программного продукта, построенного в соответствии с теорией OLAP, определяется его умением сохранить эти преимущества, по возможности, сглаживая трудности внедрения и предоставляя эффективные инструменты для решения задач. В этом плане довольно поздний приход Microsoft на рынок OLAP-продуктов имеет, как ни странно, свои достоинства - по крайней мере, была возможность воплотить самые свежие теоретические разработки в этой области, изучив опыт других и не повторяя их ошибок. По мере того как с каждой версией возрастают быстродействие и надежность SQL Server, все более заурядным явлением становится использование Analysis Services в качестве центра аналитической обработки данных масштаба корпорации. На сегодня MS SQL Server 2000 - это масштабируемая и комплексная основа для решений Business Intelli-gence, базирующаяся на открытых стандартах и гибко настраиваемой архитектуре хранения; это лидирующие позиции по производительности обработки и объемам хранилищ; это встроенная поддержка XML и интеграция с производителями других реляционных и многомерных БД; наконец, это многочисленные готовые решения независимых поставщиков, включая широкий набор клиентских средств анализа.

(Окончание.)

Алексей Шуленин - системный инженер отдела бизнес-приложений российского представительства Microsoft. Имеет сертификаты MCSE, MCDBA, MSS, MCSD. С ним можно связаться по адресу: rusdev@microsoft.com.

Ссылки и библиография