Как многие из вас Warren Thornthwaite и я работали с пререлизами Microsoft SQL Server 2005. Мы также добавляли последние штрихи в нашу новую книгу - The Microsoft Data Warehouse Toolkit ( Wiley, December 2005). Одна из задач, с которой мы столкнулись во время создания книги и во время консультирования наших клиентов, использующих SQL сервер, это стоит ли реализовывать ваше хранилище данных на платформе Microsoft на реляционной СУБД, на Analysis Services или на обоих? Ответ - в большинстве случаев на обоих.

Поскольку в течение многих лет создавались реляционные хранилища данных, очевидно, что это возможно. Microsoft добавил интересную функциональность в многомерную СУБД Analysis Services 2005, что по крайней мере в теории, делает возможным создать многомерную базу данных непосредственно из транзакционной системы, минуя реляционное хранилище данных. Но действительно ли это хорошая идея?

Прежде чем ответить на это вопрос, я собираюсь привести аргументы, что в любом случае архитектура хранилища данных на платформе Microsoft должна включать Analysis Services. Для успешного выполнения нерегламентированных запросов, даже к упрошенной многомерной модели, вам необходим пользовательский слой, который упрощает навигацию, выполняет сложные вычисления, управляет выбором агрегатов и осуществляет контроль разграничения прав доступа. Многие годы при этом использовались реляционные технологии, такие как view и клиентские инструменты для генерации запросов. Многомерная СУБД, такая как Analysis Services, предоставляет привлекательную альтернативу благодаря следующим возможностям:

  • Пользовательский слой метаданных
  • Сложная аналитика, сохраненная в базе данных
  • Более мощный аналитический язык MDX по сравнению с SQL
  • Производительность запросов
  • Управление агрегатами
  • Развитая модель безопасности
  • Серверная архитектура, что важно для масштабируемости, производительности и единству метаданных для всех клиентских инструментов

Хотя Analysis Services стал популярным компонентом SQL Server 2000, все еще были препятствия для использования Analysis Services:

  • Масштабируемость
  • Избыточность данных
  • Изменение существующих пользовательских приложений

На наш взгляд, только третье препятствие является наиболее часто встречающимся. Беспокойства о машстабируемости и дублирования данных были эффективно разрешены с выходом SQL Server 2005 и не должны препятствовать подавляющему большинству внедрений получать реальные преимущества от хранилища данных и системы поддержки принятия решений построенных на базе Analysis Services.

Если я убедил Вас, что Analysis Services является важной частью архитектуры вашего хранилища данных на платформе Microsoft, вашим следующим вопросом может быть: зачем нужно хранить многомерные данные в реляционной СУБД? От вас этого не требуется: Microsoft предоставляет несколько механизмов для загрузки данных в кубы Analysis Services непосредственно из немногомерных источников данных. Зачем пускаться в затраты и трудности создания реляционной системы в дополнение к Analysis Services? Вот почему:

  • Согласование измерений и фактов. В гипотетическом, простом примере Вы могли бы согласовать данные по ходу загрузки в Analysis Services. В реальной жизни, Вам необходимо модифицировать и удалять некоторые данные в процессе ETL, и Вы на самом деле захотите делать это в реляционной базе данных.
  • Восстановление после сбоев. Инструменты и знания для организации восстановления реляционной СУБД лучше, чем для Analysis Services, хотя средства управления были значительно улучшены в новой версии.
  • Комфорт. Администраторы и продвинутые пользователи хорошо знакомы с SQL и реляционными СУБД и могут яростно сопротивляться устранению реляционного слоя.
  • Гибкость запросов. Если Вы хотите модифицировать базу данных Analysis Services, то обычно необходимо повторно развернуть и наполнить значительную часть базы данных.
  • Будущая гибкость. Идея устранения реляционного хранилища данных и заполнения базы данных Analysis Services непосредственно из транзакционной системы может выглядеть элегантной. Однако, если Вы выберете эту архитектуру, Вы поплывете на корабле Microsoft с невозвращаемым билетом.

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

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Joy Mundy
Перевод на русский язык: Андрей Прохоров
Оригинальный документ располагается здесь


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: