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

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

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

Архитектура хранилища Кимболла основывается на пространственной организации баз данных (dimensional data bases) c так называемой архитектурой "звезда" как на стадии подготовки, так и презентации данных, в то время, как у Инмона в основе лежит нормализованный подход при работе с атомарными данными при котором атомарные данные организованы в реляционные базы и находятся в нормализованном Хранилище данных, при этом суммарные данные доступны для использования через специализированные Хранилища, средства data mining и OLAP и только витрины организованы с помощью пространственных моделей, как у Ральфа Кимболла.

На физическом уровне Хранилище данных Инмона - это физически целостный реально существующий объект, в то время как Хранилище Кимболла – это больше "виртуальный" объект дающий доступ к коллекции витрин данных, которые могут быть пространственно разобщенными.

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

Интерес большой организации, особенно с развитий филиальной структурой находится в области контроля  за согласованной управленческой информацией, необходимой для четкого понимания того, как функционирует бизнес.

В свою очередь компания SAP, после перехода на базу данных собственной разработки SAP HANA и BW4HANA, на корню меняет подход от жестко структурированного «многомерного» хранилища построенного с использованием стандартизированных объектов системы в пользу гибридного КХД, часть из которого может базироваться на индустриальных принципах проектирования информационных хранилищ.

   

Парадигма гибридного КХД позволяет применить один из подходов к стандартизации и унификации задачи получения единообразной управленческой отчетности, который заключается в тиражировании «сверху вниз» структуры отчетности и модели данных.

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

• Дочерние компании и филиалы могут работать на разном ПО;
• Одинаковое ПО в независимых «дочках» может иметь разную конфигурацию;
• В ПО могут отсутствовать средства формирования данных в требуемом формате и виде;
• Временные и материальные затраты при таком подходе могут быть несопоставимо велики т.к. потребуют переделки