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

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

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

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

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

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

Хранилище данных на основе ETL [ править ]

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

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

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

Хранилище данных на основе ELT [ править ]

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

Преимущества [ править ]

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

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

Generic [ править ]

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

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

Что касается перечисленных выше исходных систем, Р. Келли Райнер заявляет: «Обычным источником данных в хранилищах данных являются оперативные базы данных компании, которые могут быть реляционными базами данных». ^[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 - Sperry Univac представляет MAPPER (MAintain, Prepare, and Produce Executive Reports), систему управления базами данных и отчетности, которая включает первый в мире 4GL . Это первая платформа, предназначенная для построения информационных центров (предшественник современных технологий хранилищ данных).
• 1983 - Teradata представляет компьютер базы данных DBC / 1012, специально разработанный для поддержки принятия решений. ^[12]
• 1984 - Компания Metaphor Computer Systems , основанная Дэвидом Лиддлом и Доном Массаро, выпускает программно-аппаратный комплекс и графический интерфейс для бизнес-пользователей для создания системы управления базами данных и аналитики.
• 1985 - Sperry Corporation публикует статью (Мартин Джонс и Филип Ньюман) об информационных центрах, в которой они вводят термин «хранилище данных MAPPER» в контексте информационных центров.
• 1988 - Барри Девлин и Пол Мерфи публикуют статью «Архитектура для бизнеса и информационная система», в которой вводят термин «хранилище бизнес-данных». ^[13]
• 1990 - Компания Red Brick Systems, основанная Ральфом Кимбаллом , представляет Red Brick Warehouse, систему управления базами данных, специально предназначенную для хранения данных.
• 1991 - Компания Prism Solutions, основанная Биллом Инмоном , представляет Prism Warehouse Manager, программное обеспечение для разработки хранилища данных.
• 1992 - Билл Инмон издает книгу « Построение хранилища данных» . ^[14]
• 1995 - Основание института хранилищ данных, коммерческой организации, продвигающей хранение данных.
• 1996 - Ральф Кимбалл издает книгу The Data Warehouse Toolkit . ^[15]
• 2000 - Дэн Линстедт публикует модель хранилища данных , задуманную в 1990 году в качестве альтернативы Инмону и Кимбаллу для обеспечения долгосрочного хранения данных, поступающих из нескольких операционных систем, с упором на отслеживание, аудит и устойчивость к изменениям исходной модели данных.
• 2008 - Билл Инмон , вместе с Дереком Штраусом и Дженией Нойшлосс, публикует «DW 2.0: Архитектура для следующего поколения хранилищ данных», объясняя свой нисходящий подход к хранению данных и вводя термин «хранилище данных 2.0».
• 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 (третья нормальная форма), относится к подходу Билла Инмона, в котором утверждается, что хранилище данных следует моделировать с использованием модели ER / нормализованной модели. ^[16]

Размерный подход [ править ]

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

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

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

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

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

Нормализованный подход [ править ]

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

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

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

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

Дизайн снизу вверх [ править ]

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

Дизайн сверху вниз [ править ]

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

Гибридный дизайн [ править ]

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

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

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

Характеристики хранилища данных [ править ]

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

Предметно-ориентированный [ править ]

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

Интегрированный [ править ]

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

Вариант времени [ править ]

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

Энергонезависимая [ править ]

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

Параметры хранилища данных [ править ]

Агрегация [ править ]

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

Архитектура хранилища данных [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Дэвенпорт, Томас Х. и Харрис, Жанна Г. Конкуренция в области аналитики: новая наука о победе (2007) Harvard Business School Press. 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) Джон Вили и сыновья, ISBN 978-81-265-0645-3