Хранилище данных - Data warehouse

Обзор хранилища данных

Базовая архитектура хранилища данных

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

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

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

Хранилище данных на основе ETL

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

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

IBM InfoSphere DataStage, Программное обеспечение Ab Initio, Informatica - PowerCenter некоторые из инструментов, которые широко используются для реализации ETL на базе хранилища данных.

Хранилище данных на основе ELT

ELT архитектура хранилища данных на основе

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

Преимущества

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

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

Универсальный

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

• Исходные системы, которые предоставляют данные на склад или рынок;
• Технологии и процессы интеграции данных, необходимые для подготовки данных к использованию;
• Различные архитектуры для хранения данных в хранилище данных организации или витринах данных;
• Различные инструменты и приложения для самых разных пользователей;
• Метаданные, качество данных и процессы управления должны быть на месте, чтобы хранилище или магазин соответствовали своим целям.

Что касается перечисленных выше исходных систем, Р. Келли Райнер заявляет: «Обычным источником данных в хранилищах данных являются оперативные базы данных компании, которые могут быть реляционными».^[7]

Что касается интеграции данных, Райнер заявляет: «Необходимо извлечь данные из исходных систем, преобразовать их и загрузить в витрину данных или хранилище».^[7]

Райнер обсуждает хранение данных в хранилище данных организации или витринах данных.^[7]

Метаданные - это данные о данных. «ИТ-персоналу нужна информация об источниках данных, именах баз данных, таблиц и столбцов, расписаниях обновления и показателях использования данных».^[7]

Сегодня самые успешные компании - это те, которые могут быстро и гибко реагировать на рыночные изменения и возможности. Ключом к такому ответу является эффективное и действенное использование данных и информации аналитиками и менеджерами.^[7] «Хранилище данных» - это хранилище исторических данных, организованное субъектами для поддержки лиц, принимающих решения в организации.^[7] Когда данные хранятся на витрине или хранилище данных, к ним можно получить доступ.

Связанные системы (витрина данных, OLAPS, OLTP, прогнозная аналитика)

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

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

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

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

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

История

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

Основные достижения в первые годы создания хранилищ данных:

• 1960-е - General Mills и Дартмутский колледж, в совместном исследовательском проекте разработать условия размеры и факты.^[11]
• 1970-е - ACNielsen а IRI предоставляет витрины данных для розничных продаж.^[11]
• 1970-е - Билл Инмон начинает определять и обсуждать термин «хранилище данных».^{[нужна цитата ]}
• 1975 – Сперри Юнивак вводит КАРТА (MAintain, Prepare и Produce Executive Reports), система управления базами данных и отчетности, которая включает в себя первую в мире 4GL. Это первая платформа, предназначенная для построения информационных центров (предшественник современных технологий хранилищ данных).
• 1983 – Терадата вводит DBC / 1012 компьютер базы данных, специально разработанный для поддержки принятия решений.^[12]
• 1984 – Метафора компьютерных систем, основан Дэвид Лиддл и Дон Массаро выпускает программно-аппаратный комплекс и графический интерфейс для бизнес-пользователей для создания системы управления базами данных и аналитики.
• 1985 - Sperry Corporation публикует статью (Мартин Джонс и Филип Ньюман) об информационных центрах, где они вводят термин хранилище данных MAPPER в контексте информационных центров.
• 1988 - Барри Девлин и Пол Мерфи публикуют статью «Архитектура бизнеса и информационная система», в которой вводят термин «хранилище бизнес-данных».^[13]
• 1990 - Компания Red Brick Systems основана Ральф Кимбалл, представляет Red Brick Warehouse, систему управления базами данных, специально предназначенную для хранения данных.
• 1991 - Prism Solutions, основанная Билл Инмон, представляет Prism Warehouse Manager, программное обеспечение для разработки хранилищ данных.
• 1992 – Билл Инмон издает книгу Создание хранилища данных.^[14]
• 1995 - Основание Data Warehousing Institute, коммерческой организации, продвигающей хранилище данных.
• 1996 – Ральф Кимбалл издает книгу Набор инструментов хранилища данных.^[15]
• 2000 – Дэн Линстедт выпускает в общественное достояние Моделирование хранилища данных задумана в 1990 году как альтернатива Инмону и Кимбаллу для обеспечения долгосрочного хранения данных, поступающих из нескольких операционных систем, с упором на отслеживание, аудит и устойчивость к изменениям модели исходных данных.
• 2012 – Билл Инмон разрабатывает и делает общедоступной технологию, известную как «устранение текстовой неоднозначности». Устранение неоднозначности текста применяет контекст к необработанному тексту и переформатирует исходный текст и контекст в стандартный формат базы данных. После того, как необработанный текст проходит через устранение текстовой неоднозначности, к нему можно легко и эффективно получить доступ и проанализировать с помощью стандартной технологии бизнес-аналитики. Устранение текстовой неоднозначности достигается за счет выполнения текстового ETL. Устранение текстовой неоднозначности полезно везде, где встречается необработанный текст, например, в документах, Hadoop, электронной почте и т. Д.

Хранение информации

Факты

Факт - это значение или измерение, которое представляет факт об управляемом объекте или системе.

Факты, представленные отчитывающейся организацией, считаются необработанными; например, в мобильной телефонной системе, если BTS (Базовая приемопередающая станция ) получает 1000 запросов на выделение канала трафика, выделяет для 820 и отклоняет оставшиеся, он сообщит о трех факты или измерения в систему управления:

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

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

Например, если в городе три BTS, то приведенные выше факты можно агрегировать от 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 Модель (третья нормальная форма) относится к подходу Билла Инмона, в котором утверждается, что хранилище данных следует моделировать с использованием модели E-R / нормализованной модели.

Размерный подход

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

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

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

К основным недостаткам размерного подхода можно отнести следующие:

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

Нормализованный подход

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

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

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

Методы проектирования

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

Дизайн снизу вверх

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

Нисходящий дизайн

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

Гибридный дизайн

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

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

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

Характеристики хранилища данных

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

Предметно-ориентированный

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

Интегрированный

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

Временной вариант

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

Нелетучие

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

Варианты хранилища данных

Агрегация

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

Архитектура хранилища данных

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

Против операционной системы

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

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

Эволюция использования в организации

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

Автономное оперативное хранилище данных

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

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

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

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

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

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

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

Рекомендации

дальнейшее чтение

• Давенпорт, Томас Х. и Харрис, Жанна Г. Конкуренция в области аналитики: новая наука о победе (2007) Пресса Гарвардской школы бизнеса. ISBN  978-1-4221-0332-6
• Ганчарский, Джо. Реализации хранилищ данных: исследование критических факторов реализации (2009) ВДМ Верлаг 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) Джон Уайли и сыновья, ISBN  978-81-265-0645-3