Хранилище данных

В вычислительной технике хранилище данных ( DW или DWH ), также известное как хранилище данных предприятия ( EDW ), представляет собой систему, используемую для отчетности и анализа данных , и является основным компонентом бизнес-аналитики . ^[1] Хранилища данных представляют собой центральные репозитории данных, интегрированных из разрозненных источников. Они хранят текущие и исторические данные, организованные таким образом, чтобы было легко создавать отчеты, запрашивать и получать информацию из данных. ^[2] В отличие от баз данных , они предназначены для использования аналитиками и менеджерами для принятия организационных решений. ^[3]

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

Двумя основными подходами к построению системы хранилища данных являются извлечение, преобразование, загрузка (ETL) и извлечение, загрузка, преобразование (ELT).

Среда для хранилищ и витрин данных включает в себя следующее:

• Исходные системы данных (часто это операционные базы данных компании, такие как реляционные базы данных ^[3] );
• Технология интеграции данных и процессы для извлечения данных из исходных систем, их преобразования и загрузки в хранилище данных или витрину данных; ^[3]
• Архитектуры для хранения данных в хранилищах или на витринах;
• Инструменты и приложения для разных пользователей;
• Метаданные, качество данных и процессы управления. Метаданные включают источники данных (базы данных, таблицы и имена столбцов), графики обновления и меры использования данных. ^[3]

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

Хранилища данных оптимизированы для аналитических шаблонов доступа, которые обычно включают выбор определенных полей, а не всех полей, как это принято в операционных базах данных. Из-за этих различий в доступе операционные базы данных (в широком смысле, OLTP) выигрывают от использования системы управления базами данных, ориентированной на строки (СУБД), тогда как аналитические базы данных (в широком смысле, OLAP) выигрывают от использования СУБД, ориентированной на столбцы . Операционные системы поддерживают снимок бизнеса, в то время как хранилища поддерживают исторические данные через процессы ETL, которые периодически переносят данные из операционных систем в хранилище.

Онлайн-аналитическая обработка (OLAP) характеризуется низкой скоростью транзакций и сложными запросами, включающими агрегации. Время отклика является эффективным показателем производительности систем OLAP. Приложения OLAP широко используются для интеллектуального анализа данных . Базы данных OLAP хранят агрегированные исторические данные в многомерных схемах (обычно звездообразных схемах ). Системы OLAP обычно имеют задержку данных в несколько часов, в то время как задержка витрин данных ближе к одному дню. Подход OLAP используется для анализа многомерных данных из нескольких источников и точек зрения. Три основные операции в OLAP — это свертывание (консолидация), детализация и нарезка.

Онлайн-обработка транзакций (OLTP) характеризуется большим количеством коротких онлайн-транзакций (INSERT, UPDATE, DELETE). Системы OLTP делают упор на быструю обработку запросов и поддержание целостности данных в средах с множественным доступом. Для систем OLTP производительность — это количество транзакций в секунду. Базы данных OLTP содержат подробные и актуальные данные. Схемой, используемой для хранения транзакционных баз данных, является модель сущностей (обычно 3NF ). ^{[ необходима цитата ]} Нормализация является нормой для методов моделирования данных в этой системе.

Предиктивная аналитика занимается поиском и количественной оценкой скрытых закономерностей в данных с использованием сложных математических моделей и прогнозированием будущих результатов. Напротив, OLAP фокусируется на анализе исторических данных и является реактивной. Предиктивные системы также используются для управления взаимоотношениями с клиентами (CRM).

Витрина данных — это простое хранилище данных, ориентированное на одну тему или функциональную область. Поэтому оно черпает данные из ограниченного числа источников, таких как продажи, финансы или маркетинг. Витрины данных часто создаются и контролируются одним отделом в организации. Источниками могут быть внутренние операционные системы, центральное хранилище данных или внешние данные. ^[4] Как и в случае со складами, хранимые данные обычно не нормализуются.

Типы витрин данных включают зависимые , независимые и гибридные витрины данных. ^{[ необходимо разъяснение ]}

Типичное хранилище данных на основе извлечения, преобразования, загрузки (ETL) использует уровни подготовки , интеграции данных и доступа для размещения своих ключевых функций. Уровень подготовки или база данных подготовки хранит необработанные данные, извлеченные из каждой из разнородных систем исходных данных. Уровень интеграции интегрирует разнородные наборы данных путем преобразования данных из уровня подготовки, часто сохраняя эти преобразованные данные в базе данных оперативного хранилища данных (ODS). Затем интегрированные данные перемещаются в еще одну базу данных, часто называемую базой данных хранилища данных, где данные организованы в иерархические группы, часто называемые измерениями, а также в факты и агрегированные факты. Комбинацию фактов и измерений иногда называют схемой звезды . Уровень доступа помогает пользователям извлекать данные. ^[5]

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

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

Хранилище данных поддерживает копию информации из исходных систем транзакций. Эта архитектурная сложность обеспечивает возможность:

• Интеграция данных из нескольких источников в единую базу данных и модель данных. Большее объединение данных в единую базу данных, чтобы можно было использовать единый механизм запросов для представления данных в оперативном хранилище данных .
• Смягчить проблему конфликтов блокировок на уровне изоляции в системах обработки транзакций , вызванную длительными аналитическими запросами в базах данных обработки транзакций.
• Сохраняйте историю данных , даже если исходные системы транзакций этого не делают.
• Интеграция данных из нескольких исходных систем, что позволяет получить центральное представление по всему предприятию. Это преимущество всегда ценно, но особенно ценно, когда организация растет за счет слияния.
• Улучшайте качество данных , предоставляя согласованные коды и описания, отмечая или даже исправляя неверные данные.
• Последовательно представляйте информацию об организации.
• Обеспечить единую общую модель данных для всех интересующих данных независимо от источника данных.
• Реструктурируйте данные так, чтобы они были понятны бизнес-пользователям.
• Реструктурируйте данные таким образом, чтобы они обеспечивали отличную производительность запросов, даже для сложных аналитических запросов, не влияя на операционные системы .
• Повысить ценность операционных бизнес-приложений, в частности систем управления взаимоотношениями с клиентами (CRM).
• Упростите написание запросов для поддержки принятия решений.
• Организуйте и устраняйте неоднозначность повторяющихся данных.

Концепция хранилищ данных восходит к концу 1980-х годов ^[7] , когда исследователи IBM Барри Девлин и Пол Мерфи разработали «хранилище бизнес-данных». По сути, концепция хранилищ данных была призвана предоставить архитектурную модель для потока данных из операционных систем в среды поддержки принятия решений . Концепция пыталась решить различные проблемы, связанные с этим потоком, в основном связанные с высокими затратами. При отсутствии архитектуры хранилищ данных требовалось огромное количество избыточности для поддержки нескольких сред поддержки принятия решений. В крупных корпорациях было типично, что несколько сред поддержки принятия решений работали независимо. Хотя каждая среда обслуживала разных пользователей, им часто требовалась большая часть одних и тех же хранимых данных. Процесс сбора, очистки и интеграции данных из различных источников, как правило, из давно существующих операционных систем (обычно называемых унаследованными системами ), как правило, частично реплицировался для каждой среды. Более того, операционные системы часто пересматривались по мере появления новых требований к поддержке принятия решений. Часто новые требования требовали сбора, очистки и интеграции новых данных из « киосков данных », которые были специально разработаны для быстрого доступа пользователей.

Кроме того, с публикацией книги The IRM Imperative (Wiley & Sons, 1991) Джеймса М. Керра, идея управления и присвоения долларовой стоимости ресурсам данных организации, а затем представления этой стоимости в качестве актива в балансе стала популярной. В книге Керр описал способ заполнения предметных баз данных данными, полученными из систем, управляемых транзакциями, для создания области хранения, где сводные данные могли бы быть дополнительно использованы для информирования руководителей о принятии решений. Эта концепция способствовала дальнейшему размышлению о том, как хранилище данных может быть разработано и управляемо на практике в рамках любого предприятия.

Ключевые события первых лет развития хранилищ данных:

• 1960-е годы – General Mills и Дартмутский колледж в совместном исследовательском проекте разрабатывают термины «измерения» и «факты» . ^[8]
• 1970-е годы – ACNielsen и IRI предоставляют пространственные витрины данных для розничных продаж. ^[8]
• 1970-е годы – Билл Инмон начинает определять и обсуждать термин «хранилище данных». ^{[9] [10] [11]}
• 1975 – Sperry Univac представляет MAPPER (MAintain, Prepare, and Produce Executive Reports), систему управления базами данных и отчетности, которая включает в себя первый в мире 4GL . Это первая платформа, разработанная для создания информационных центров (предшественник современной технологии хранилищ данных).
• 1983 – Teradata представляет компьютер базы данных DBC/1012, специально разработанный для поддержки принятия решений. ^[12]
• 1984 – Компания Metaphor Computer Systems , основанная Дэвидом Лиддлом и Доном Массаро, выпускает аппаратно-программный пакет и графический интерфейс для бизнес-пользователей, позволяющий создавать системы управления базами данных и аналитики.
• 1988 – Барри Девлин и Пол Мерфи публикуют статью «Архитектура для бизнес-информационной системы», в которой они вводят термин «хранилище бизнес-данных». ^[13]
• 1990 – Компания Red Brick Systems, основанная Ральфом Кимбаллом , представляет Red Brick Warehouse, систему управления базами данных, специально предназначенную для хранения данных.
• 1991 г. – Джеймс М. Керр пишет книгу «Императив IRM», в которой предлагается отражать ресурсы данных в балансе как актив, что способствует росту коммерческого интереса к созданию хранилищ данных.
• 1991 – Компания Prism Solutions, основанная Биллом Инмоном , представляет Prism Warehouse Manager, программное обеспечение для разработки хранилища данных.
• 1992 – Билл Инмон публикует книгу «Создание хранилища данных» . ^[14]
• 1995 г. – Основан Институт хранилищ данных, коммерческая организация, продвигающая хранилища данных.
• 1996 – Ральф Кимбалл публикует книгу «Инструментарий хранилища данных» . ^[15]
• 1998 – Фокусное моделирование реализовано как ансамблевый (гибридный) подход к моделированию хранилища данных, одним из главных инициаторов которого является Патрик Лагер. ^{[16] [17]}
• 2000 г. – Дэн Линстедт публикует в открытом доступе модель хранилища данных , задуманную в 1990 г. как альтернатива модели Инмона и Кимбалла для обеспечения долгосрочного исторического хранения данных, поступающих из нескольких операционных систем, с упором на отслеживание, аудит и устойчивость к изменению исходной модели данных.
• 2008 г. – Билл Инмон совместно с Дереком Штрауссом и Дженией Нойшлосс публикует книгу «DW 2.0: Архитектура для следующего поколения хранилищ данных», в которой объясняет свой подход к хранению данных «сверху вниз» и вводит термин «хранилище данных 2.0».
• 2008 – Моделирование якорей было формализовано в статье, представленной на Международной конференции по концептуальному моделированию, и получило награду за лучшую статью ^[18]
• 2012 – Билл Инмон разрабатывает и делает общедоступной технологию, известную как «текстовое разрешение неоднозначности». Текстовое разрешение неоднозначности применяет контекст к сырому тексту и переформатирует сырой текст и контекст в стандартный формат базы данных. После того, как сырой текст прошел через текстовое разрешение неоднозначности, к нему можно легко и эффективно получить доступ и проанализировать с помощью стандартной технологии бизнес-аналитики. Текстовое разрешение неоднозначности достигается посредством выполнения текстового ETL. Текстовое разрешение неоднозначности полезно везде, где находится сырой текст, например, в документах, Hadoop, электронной почте и т. д.
• 2013 г. – выпущен Data Vault 2.0 ^{[19] [20],} в который были внесены некоторые незначительные изменения в метод моделирования, а также была реализована интеграция с передовыми методами из других методологий, архитектур и реализаций, включая принципы Agile и CMMI.

Факт — это значение или измерение в управляемой системе.

Необработанные факты — это те, которые сообщает субъект, предоставляющий отчет. Например, в системе мобильной телефонной связи, если базовая приемопередающая станция (BTS) получает 1000 запросов на выделение канала трафика, выделяет 820 и отклоняет остальные, она может сообщить системе управления три факта:

• tch_req_total = 1000
• tch_req_success = 820
• tch_req_fail = 180

Необработанные факты агрегируются на более высоких уровнях в различных измерениях для извлечения информации, более релевантной для сервиса или бизнеса. Это называется агрегированными фактами или резюме.

Например, если в городе три BTS, то приведенные выше факты можно объединить на уровне города в сетевом измерении. Например:

• tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
• avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3

Два самых важных подхода к хранению данных в хранилище — размерный и нормализованный. Размерный подход использует схему «звезда» , предложенную Ральфом Кимбаллом . Нормализованный подход, также называемый третьей нормальной формой (3NF), представляет собой нормализованную модель сущностей-отношений, предложенную Биллом Инмоном. ^[21]

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

Этот размерный подход упрощает понимание данных и ускоряет их извлечение. ^[15] Размерные структуры просты для понимания бизнес-пользователями, поскольку структура разделена на измерения/факты и контекст/измерения. Факты связаны с бизнес-процессами организации и операционной системой, а измерения являются контекстом о них (Kimball, Ralph 2008). Еще одним преимуществом является то, что размерная модель не включает в себя реляционную базу данных каждый раз. Таким образом, этот тип метода моделирования очень полезен для запросов конечных пользователей в хранилище данных.

Модель фактов и измерений можно также понимать как куб данных , ^[22] где измерения — это категориальные координаты в многомерном кубе, факт — это значение, соответствующее координатам.

Основными недостатками размерного подхода являются:

1. Сложно поддерживать целостность фактов и измерений, загружая хранилище данных данными из разных операционных систем.
2. Если организация меняет способ ведения бизнеса, изменить структуру склада будет сложно.

В нормализованном подходе данные в хранилище хранятся в соответствии с, в некоторой степени, правилами нормализации базы данных . Нормализованные реляционные таблицы базы данных группируются в предметные области (например, клиенты, продукты и финансы). При использовании на крупных предприятиях результатом являются десятки таблиц, связанных сетью соединений. (Kimball, Ralph 2008).

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

Как нормализованные, так и размерные модели могут быть представлены в диаграммах сущности-связи, поскольку обе содержат соединенные реляционные таблицы. Разница между ними заключается в степени нормализации. Эти подходы не являются взаимоисключающими, и существуют другие подходы. Размерные подходы могут включать нормализацию данных в определенной степени (Kimball, Ralph 2008).

В Information-Driven Business [ ^23] Роберт Хиллард сравнивает два подхода, основанных на информационных потребностях бизнес-задачи. Он приходит к выводу, что нормализованные модели содержат гораздо больше информации, чем их размерные эквиваленты (даже когда в обеих моделях используются одни и те же поля), но за счет удобства использования. Методика измеряет количество информации с точки зрения информационной энтропии и удобства использования с точки зрения меры преобразования данных Small Worlds. ^[24]

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

В подходе снизу вверх витрины данных сначала создаются для предоставления возможностей отчетности и анализа для определенных бизнес-процессов . Затем эти витрины данных могут быть интегрированы для создания комплексного хранилища данных. Архитектура шины хранилища данных в первую очередь представляет собой реализацию «шины», набора согласованных измерений и согласованных фактов, которые являются измерениями, которые совместно используются (определенным образом) между фактами в двух или более витринах данных. ^[25]

Подход сверху вниз разработан с использованием нормализованной модели корпоративных данных . «Атомарные» данные , то есть данные с наивысшим уровнем детализации, хранятся в хранилище данных. Из хранилища данных создаются витрины размерных данных, содержащие данные, необходимые для конкретных бизнес-процессов или конкретных отделов. ^[26]

Хранилища данных часто напоминают архитектуру концентратора и спиц . Устаревшие системы, питающие хранилище, часто включают управление взаимоотношениями с клиентами и планирование ресурсов предприятия , генерируя большие объемы данных. Для консолидации этих различных моделей данных и облегчения процесса извлечения , преобразования и загрузки хранилища данных часто используют операционное хранилище данных , информация из которого анализируется в фактическое хранилище данных. Чтобы уменьшить избыточность данных, более крупные системы часто хранят данные в нормализованном виде. Затем на основе хранилища данных можно построить витрины данных для конкретных отчетов.

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

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

Существуют основные характеристики, определяющие данные в хранилище данных, в том числе предметная ориентация, интеграция данных, изменчивость во времени, энергонезависимость данных и гранулярность данных.

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

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

В то время как операционные системы отражают текущие значения, поскольку они поддерживают ежедневные операции, данные хранилища данных представляют собой длительный временной горизонт (до 10 лет), что означает, что они хранят в основном исторические данные. Они в основном предназначены для добычи данных и прогнозирования. (Например, если пользователь ищет модель покупок определенного клиента, пользователю необходимо просмотреть данные о текущих и прошлых покупках.) ^[27]

Данные в хранилище данных доступны только для чтения, что означает, что их нельзя обновлять, создавать или удалять (если только нет нормативного или законодательного обязательства делать это). ^[28]

В процессе хранилища данных данные могут быть агрегированы в витринах данных на разных уровнях абстракции. Пользователь может начать просматривать общее количество единиц продажи продукта во всем регионе. Затем пользователь смотрит на штаты в этом регионе. Наконец, он может изучить отдельные магазины в определенном штате. Поэтому, как правило, анализ начинается с более высокого уровня и переходит к более низким уровням детализации. ^[27]

При виртуализации данных используемые данные остаются в своих исходных местах, и устанавливается доступ в режиме реального времени, позволяющий проводить аналитику по нескольким источникам, создавая виртуальное хранилище данных. Это может помочь в решении некоторых технических трудностей, таких как проблемы совместимости при объединении данных с различных платформ, снижая риск ошибок, вызванных неверными данными, и гарантируя, что используются самые новые данные. Кроме того, избегание создания новой базы данных, содержащей персональную информацию, может облегчить соблюдение правил конфиденциальности. Однако при виртуализации данных подключение ко всем необходимым источникам данных должно быть рабочим, поскольку локальной копии данных нет, что является одним из главных недостатков подхода. ^[29]

Различные методы, используемые для построения/организации хранилища данных, указанного организацией, многочисленны. Используемое оборудование, созданное программное обеспечение и ресурсы данных, специально требуемые для правильной работы хранилища данных, являются основными компонентами архитектуры хранилища данных. Все хранилища данных имеют несколько фаз, в которых требования организации изменяются и настраиваются. ^[30]

Эти термины относятся к уровню сложности хранилища данных:

Офлайн-хранилище оперативных данных

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

Офлайн хранилище данных

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

Своевременное хранилище данных

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

Интегрированное хранилище данных

Эти хранилища данных собирают данные из разных областей бизнеса, чтобы пользователи могли искать необходимую им информацию в других системах. ^[31]

Найдите информацию о хранилище данных в Викисловаре, бесплатном словаре.

• Список программного обеспечения для бизнес-аналитики
• Озеро данных  — система или хранилище данных, хранящихся в естественном/сыром формате.
• Data Mesh  – Распределенная архитектура для управления данными

• Дэвенпорт, Томас Х. и Харрис, Джин Г. Конкуренция в аналитике: новая наука побеждать (2007) Издательство Гарвардской школы бизнеса. ISBN 978-1-4221-0332-6 
• Ганчарски, Джо. Реализации хранилищ данных: исследование критических факторов реализации (2009) VDM Verlag ISBN 3-639-18589-7 ISBN 978-3-639-18589-8   
• Кимбалл, Ральф и Росс, Марджи. Набор инструментов для хранилища данных, третье издание (2013) Wiley, ISBN 978-1-118-53080-1 
• Линстедт, Грациано, Хультгрен. Бизнес моделирования хранилищ данных, второе издание (2010 г.) Дэн Линстедт, ISBN 978-1-4357-1914-9 
• Уильям Инмон. Создание хранилища данных (2005) John Wiley and Sons, ISBN 978-81-265-0645-3