Независимо от того, используете ли вы в качестве хранилища данных реляционный склад данных или размещаете данные непосредственно в компоненте Analysis Services (SSAS) Microsoft SQL Server, в первую очередь вы думаете о доставке данных бизнес-пользователям, то есть о заключительном звене в цепочке программ решения бизнес-аналитики. Если вы используете компонент SSAS из Microsoft SQL Server, то большую часть работы по подготовке данных к доставке можно выполнять с его помощью. Можно вычислить тенденции, например, итоги для данных по продажам, средние стоимости для заказов через определенный период времени или узнать, в каких регионах страны определенные категории товаров продаются лучше, чем в других. Именно в этих ситуациях вы сможете в полной мере оценить эффективность функций SSAS, которые помогут вам извлечь максимум полезной информации из ваших данных.
Разработка методологии вычислений, хранения и доставки данных на этом уровне не менее важны, чем разработка самой базы данных и хранилища данных. Несмотря на то, что эта фаза является естественным продолжением концепции хранилища данных, ее следует разрабатывать как отдельный фрагмент системы. Именно поэтому вам придется создать и вести документацию, описывающую, почему и как работает этот процесс; при этом вы должны иметь возможность вернуться к процессу и масштабировать его по мере роста предприятия.
КОМПОНЕНТ SQL SERVER "СЛУЖБЫ ANALYSIS SERVICES"
За последние несколько лет компонент SSAS претерпел значительные изменения и превратился в одну из самых надежных платформ анализа данных корпоративного уровня. В версиях SQL Server 2005 и SQL Server 2008 мы наблюдаем небывалый рост функциональности и масштабируемости платформы; при этом программный продукт сохраняет свое основное преимущество - он позволяет без лишних сложностей создать новый проект. Благодаря этому многие разработчики выбирают SSAS в качестве основы для создания решений бизнес-аналитики, ведь данный программный продукт делает возможной быструю разработку и развертывание решений для хранения данных. Большая часть этих функциональных возможностей заложена в семантической бизнес-модели SSAS, которая определяет бизнес-сущности, логику, расчеты и показатели (ее фирменное название в Microsoft - Unified Dimensional Model, UDM (универсальная пространственная модель)). Работу любой реализации SSAS обеспечивает либо значительное количество ETL-процессов, загружающих данные из разных других источников непосредственно в куб SSAS, либо реляционное хранилище данных, которое служит серверной стороной куба. UDM-модель обеспечивает централизованное хранение данных и предоставляет единый источник для всех данных, имеющих отношение к решению бизнес-аналитики. Это помогает разработчикам создать некоторый уровень абстракции, позволяющий скрыть описанные серверные процессы от клиентской стороны и механизмов доставки данных.
ОБЩАЯ СХЕМА
Когда дело доходит до реального проектирования и создания хранилища данных, в отрасли обычно используют два принципа - принцип Кимболла или принцип Инмона. Понимание этих двух принципов поможет вам при проектировании будущих проектов.
Коротко: Ральф Кимболл в своей работе под названием "The Data Warehouse Lifecycle Toolkit" (Набор инструментов для всего жизненного цикла хранилищ данных) идентифицировал и дал определение проблеме "сопряжения труб разного диаметра" (stovepipe). Во многих корпорациях часто случается, что каждая независимая система, или витрина данных, идентифицирует и хранит данные своим уникальным образом, что напоминает набор труб разного диаметра. Получение данных из этих различных систем и объединение их в систему поддержки решений может быть чрезвычайно сложным делом. Чтобы смягчить ситуацию, Кимболл рекомендует использовать методологию сходных измерений. Согласно этой методологии, все используемые измерения, например, данные по продажам, должны иметь одинаковые атрибуты и агрегаты во всех витринах данных в пределах корпорации. Таким образом, хранилище данных может создаваться из витрин данных во всей корпорации. Главная мысль здесь в том, что хранилище данных содержит все размерные базы данных для упрощения анализа, при этом пользователи могут просто непосредственно запрашивать хранилище при любых потребностях в информации.
Рисунок 1. Пример: куб в Microsoft Visual Studio.
Рисунок 2. Группа показателей "Итоги по продажам" в Visual Studio.
Билл Инмон в своей работе Corporate Information Factory (Корпоративная фабрика информации) рекомендует более универсальный безразмерный формат. Витрины данных могут содержать совершенно неоднородную информацию, и пользователи непосредственно запрашивают эти разнородные источники, а не хранилище данных.
Как правило, вы не обязаны выбирать между этими двумя принципами: их понимание поможет вам создавать каждый проект в соответствии с потребностями пользователей и различными переменными среды.
Продумав создание витрины/хранилища данных на высоком уровне, вы должны перейти к реальному созданию проекта. Для наших целей мы воспользуемся учебным проектом, который поставляется с SQL Server 2008 - это хранилище данных AdventureWorksDW. В частности, мы будем рассматривать учебный проект Visual Studio, созданный для хранилища данных. Благодаря этому вы сможете изучать материал вместе с нами, и одновременно получить общие навыки исследования других проектов. Компания Adventure Works, которая упоминается в учебных материалах по Microsoft SQL Server - это воображаемая компания, занимающаяся продажей велосипедов. Информация о продажах и сотрудниках хранится в реляционном хранилище данных, а соответствующий куб служб Analysis Services отображает эти данные для пользователей либо непосредственно из реляционной базы данных, либо через хранилище данных. Все описанные учебные материалы можно загрузить с Web-сайта www.codeplex.com.
КУБЫ
Раньше в этой серии статей мы уже давали общее описание концепции кубов. Однако важно понять принципиальные основы кубов и различные структуры данных, которые они используют. Если вы поймете, как устроены кубы, то вам будет гораздо проще научиться их использовать.
Куб - это фундамент многомерной базы данных. Как правило, куб имеет 2 или более измерений и фактические данные. Измерения используются для описания фактических данных. Обычные измерения - это время, географические данные и информация о продукте. Мы применяем эти измерения к нашим фактическим данным, например, к продажам, чтобы понять значение этих данных. Например, мы применяем временное измерение к данным по продажам, чтобы выяснить, сколько продаж было сделано конкретным сотрудником в каждом месяце года. Мы можем изменить временное измерение, чтобы изучить те же данные о продажах за квартал, или сравнить данные в годовом исчислении. Эти измерения основаны на общей концепции измерений в любом хранилище данных (не только для служб Analysis Services). Однако не во всех аспектах. В SSAS измерения имеют иерархии . Каждое измерение имеет атрибуты, которые связаны с другими измерениями отношениями предок-потомок, другими словами, измерения образуют иерархии. Классическим примером иерархии является измерение Geography, имеющее атрибуты Country-State-City-Zip Code (Страна-штат-город-зип-код). Эти атрибуты формируют отношение иерархии с другими атрибутами.
На рисунке 1 показан куб AdventureWorks в Visual Studio. В центральной панели мы видим факты (они обозначены желтым цветом) и измерения (они обозначены синим цветом). Справа расположена панель обозревателя решений Solution Explorer, слева мы видим еще две панели: Dimensions (Измерения) и Measures (Меры).
Рисунок 3. Диалоговое окно "Edit Measure" в Visual Studio.
Кроме измерений и фактов, кубы служб Analysis Services содержат объекты, которые называются measures (меры). По сути, меры - это особые измерения куба, которые представляют собой количественные сущности, используемые для анализа. Обычно меры являются частью групп мер ( measure group), которые используются для того, чтобы сделать более удобными для чтения некоторые инструменты навигации и проектирования в кубе.
Меры можно представить как набор столбцов данных, к которому может применяться (или не применяться) пользовательское выражение (вычисление). Например, просматривая проект AdventureWorks в Visual Studio, мы видим в кубе Adventure Works группу мер "Sales Summary" (рисунок 2).
В группе мер можно увидеть каждую меру. Если дважды щелкнуть мышью на первой мере в списке "Order Quantity", откроется диалоговое окно "Edit Measure", показанное на рисунке 3.
В данном случае мы видим, что для столбца OrderQuantity из таблицы Sales Summary Facts подведен итог (в раскрывающемся списке Usage). Это означает, что данная мера просто представляет собой сумму всех значений из столбца OrderQuantity или, логически, сумму по всем заказам. Еще две структуры в кубе, о которых следует иметь представление - это members (члены) и cells (ячейки). Каждая иерархия измерений содержит одно или более включений этого значения в базовой таблице измерений. Например, на рисунке 4 показано измерение Geography и члены "Australia" и "Canada", которые, в свою очередь, имеют члены на каждом более низком уровне иерархии.
Ячейки (cells) - это сущности, из которых мы извлекаем данные. Как и ячейки в таблице (хотя и более сложные по строению), они представляют собой пересечение осей данных. В отличие от таблицы, значения которой часто являются пересечением двух осей, X и Y, ячейка в кубе представляет собой пересечение трех осей: X, Y и Z. В данном случае X, Y и Z являются пересечениями измерений. Кроме того, каждый уровень иерархии в измерении пересекается с другими уровнями иерархии в других измерениях. Именно наличие нескольких уровней пересечений между измерениями на уровнях в их иерархиях делает куб таким эффективным.
Для любого данного проекта куб может содержать множество измерений (учебный проект содержит 21 измерение - это относительно простой куб). Проектируя хранилища данных и кубы, не стесняйтесь, включайте все необходимые измерения для всех фактов. Не пугайтесь количества измерений, не забудьте только проанализировать каждое потенциальное измерение и проверить, является ли оно значимым для пользовательских задач.