2013-03-24 2 views
-1

Я планирую реализовать Inmon тип решения Dataware для малого и среднего бизнеса. Решение Datawarehouse будет иметь 3-й стандартный репозиторий формы и набор витрин данных. Данные будут поступать из «онлайн» источников данных (OLTP) в хранилище хранилища данных и в витрины данных. Я считаю, что я хорошо разбираюсь в теории. Я прочитал несколько книг («Наставник хранилища данных» Laberge, книги Кимбалла и Инмона). У меня есть вопросы относительно реальных решений и лучших практик.Может ли приложение напрямую обращаться к хранилищу datawarehouse; или они должны всегда получать доступ к данным через витрины данных?

Вопросы:

  1. Является ли это хорошая идея, чтобы иметь приложения (системы и т.д.) отчетности выполнения запросов в отношении репозитория хранилища данных (я имею в виду центральное хранилище данных 3NF), или они должны всегда получать доступ к данным через витрины данных?
  2. Существует ли стандартное соглашение об именах для объектов репозитория данных и объектов данных (схемы, таблицы, поля и т. Д.)?
  3. Можете ли вы указать мне примеры реальных схем схемы данных? Я уже рассмотрел MSSQL AdventureWorksDW.

Буду признателен за любые отзывы. Благодарю.

ответ

1

1) Это зависит от ситуации. Не должно быть никаких причин, чтобы иметь размерные витрины данных вообще, если 3NF выполняет. Витрины данных обычно существуют для агрегации &. Который всегда ставит вопрос «почему есть слой 3NF, если все запросы происходят в картотеках данных в любом случае?»

2) Используйте свои лучшие практики, которые определила ваша компания. В промышленности есть всевозможные стандарты, используйте то, что у вас уже есть.

3) Хранилища данных реального времени Inmon-style практически исключительно существуют в очень крупных компаниях, которые могут позволить себе огромное время и политическую волю для создания огромного словаря данных и «фабрики корпоративной информации», которую определяет Inmon, или очень небольших компаний у которых только очень мало исходных систем для чтения данных. Если вы не интегрируете в систему, поскольку она появится в сети, в будущем будут проблемы, когда вы обнаружите, что ваша модель 3NF не подходит для бизнеса точно. Карточки данных Kimball могут быть построены, начиная с одной области бизнеса и постепенно расширяться с течением времени, чтобы включать других, вместо того, чтобы делать все впереди.

+0

Спасибо за ваш ответ. Btw. Я задал 3 очень специфических вопроса, касающихся одной и той же темы: «реальная реализация DW». Я до сих пор не знаю, почему тема была закрыта. Не все вопросы могут быть завернуты в 5 слов. –

Смежные вопросы