Совет №44
Не полагайтесь слишком сильно на метаданные вашего инструмента для доступа к данным

Материал опубликован с разрешения компании Ralph Kimball Associates
Авторы оригинала: Bob Becker (все статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.

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

Сегодняшние инструменты класса business intelligence предоставляют сильный набор метаданных для поддержки широкого спектра возможностей, такие как замена меток, предопределённые расчёты и навигация по агрегатам. Это полезные функции для вашего бизнес-сообщества. Но мы должны взвешенно использовать функции, которые предоставляют нам инструменты. Слишком часто команды разработчиков выбирают короткие пути и полагаются на метаданные инструментов доступа к данным для решения задач, которые лучше решаются с помощью наших многомерных моделей. Конечный результат – это бизнес-правила, которые становятся встроенными в метаданные инструмента, а не в наши схемы данных. Мы также наблюдаем случаи, когда команды разработчиков используют метаданные инструментов для предоставления справочников кодов и описания индикаторов в неверном стремлении к сокращению своих схем данных.

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

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

Вы можете думать «Хорошо, тогда мы заставим всех пользователей получать доступ к данным через поддерживаемый нами инструмент». Однако этот подход неизбежно провалится. Есть ряд причин, почему кто-то может захотеть получить доступ к данным каким-то другим способом в обход поддерживаемого инструмента и, соответственно, в обход бизнес-правил, поддерживаемых его метаданными. Эти сценарии могут отсутствовать в вашей организации в момент, когда вы разрабатываете вашу схему, но, будьте уверены, что какой-либо из них точно всплывёт на вашем веку:

• Специалист IT (может быть, вы сами) может выбрать доступ через SQL, выполняемый прямо поверх хранилища данных, для того, чтобы ответить на сложный вопрос, или выполнить аудит данных.
• Ваша организация может разрабатывать аналитические приложения, основанные на запросах SQL к хранилищу данных, разработанных своими силами.
• Инструменты статистического моделирования и/или инструменты data mining могут иметь необходимость в прямом доступе к данным хранилища.
• Продвинутый пользователь, вооружённый Microsoft Access (или другим неподдерживаемым инструментом), может получить доступ к хранилищу данных.
• Может возникнуть необходимость в дополнении хранилища данных многомерными «кубами», наполняемыми непосредственно из хранилища данных.
• Ваша организация может выбрать другой инструмент для конечных пользователей на замену существующему.

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

• Предыдущий совет
• Следующий совет
• Другие советы

По этой теме можно также почитать:

• Статьи из раздела Управление метаданными хранилища данных

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

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.