С1990-х годов широко используются две традиционные методологии проектирования хранилищ данных: Атомарное проектирование хранилища данных сверху вниз  Билла Инмона и Многомерное моделирование хранилища данных снизу вверх Ральфа Кимбалла. Эти методологии использовались в течение последних 20 лет для создания информационных хранилищ данных для организаций, которые стремятся использовать свои данные для корпоративной выгоды. В этой статье мы сравним и сопоставим эти две методологии.

Атомарное проектирование хранилища Билла Инмона

Атомарный подход Билла  Билла Инмона является стратегическим по своей сути и стремится захватить все данные предприятия в 3-й нормальной форме и хранить все эти атомарные данные в хранилище данных. Инмон определяет хранилище данных как предметно-ориентированный, неизменчивый, поддерживающий хронологию и интегрированный источник данных. Давайте разложим каждый из этих свойств хранилища данных Инмона:

1. Предметно-ориентированность - хранилище организовано таким образом, чтобы данные, связанные с предметной областью, были связаны друг с другом.
2. Неизменчивость - после ввода данные никогда не обновляются и не удаляются, а сохраняются для будущих потребностей в отчетности.
3. Поддержка хронологии - из-за неизменчивого характера данных и необходимости создания отчетов, основанных на времени, после ввода данных на склад они не могут быть изменены, - должны быть добавлены новые записи, чтобы отражать изменения данных во времени.
4. Интегрированность - данные поступают от  всех информационных систем предприятия и организованы последовательным и унифицированным образом.

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

У этой модели есть несколько преимуществ. Во-первых, все корпоративные данные полностью документированы. Этот процесс дает организации полное представление о своих процессах, продуктах / услугах, клиентах, поставщиках и т. Д. Такая  документация неоценима для организации, поскольку в большинстве случаев до этого момента каждая система запускалась изолированно.Теперь организация действительно может определять различные процессы, продукты или партии, с которыми они взаимодействуют на постоянной основе.

Во-вторых, данные эффективно хранятся в 3-й нормальной форме в одном репозитории. Эта методология хранения облегчает поиск и хранение данных из транзакционных систем, уже определенных в  3-й нормальной форме.

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

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

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

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

Многомерное моделирование хранилища данных Ральфа Кимбалла

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

Витрины данных Кимбалла состоят из исходных данных, преобразованных из 3-й нормальной формы в многомерную модель. Эта модель состоит из фактов и измерений. Факты вычисляют меры по объектам в определенный момент времени. Измерения - это контейнеры для уточняющих элементов объектов, по которым сгруппированы меры.

Основное преимущество подхода Кимбалла и использование многомерного моделирования - это скорость, с которой бизнес-пользователь может извлечь выгоду из массива данных и гибкость, которую предлагает это моделирование. Витрины данных обычно могут быть определены, спроектированы и поставлены менее чем за 120 дней и в большинстве случаев менее чем за 90 дней после доступности данных. Затем эта модель также позволяет легко развернуть факты или измерения, чтобы добавить новые меры или дополнительную информацию, описывающую добавляемый объект. Наконец, этот метод моделирования требует предварительной обработки и хранения данных таким образом, что агрегирование данных фактов может быть легко разрезано и разбито по размерным столбцам бизнес-пользователями, практически без помощи ИТ. Такое сочетание скорости, гибкости, масштабируемости и прозрачности необходимо в быстро меняющейся бизнес-среде.

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

Что же выбрать?

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

No Comments