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

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

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

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

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

Содержание

  • 1 Хранилище данных на основе ETL
  • 2 Хранилище данных на основе ELT
  • 3 Преимущества
  • 4 Универсальный
  • 5 Связанные системы (витрина данных, OLAPS, OLTP, прогнозная аналитика)
  • 6 История
  • 7 Хранение информации
    • 7.1 Факты
    • 7.2 Размерный подход в сравнении с нормализованным подходом для хранения данных
      • 7.2.1 Размерный подход
      • 7.2.2 Нормализованный подход
  • 8 Методы проектирования
    • 8.1 Дизайн снизу вверх
    • 8.2 Дизайн сверху вниз
    • 8.3 Гибридный дизайн
  • 9 Характеристики хранилища данных
    • 9.1 Предметно-ориентированный
    • 9.2 Интегрированный
    • 9.3 Временной вариант
    • 9.4 Энергонезависимая
  • 10 Параметры хранилища данных
    • 10.1 Агрегация
  • 11 Архитектура хранилища данных
  • 12 Сравнение с операционной системой
  • 13 Эволюция использования в организации
  • 14 Ссылки
  • 15 Дополнительная литература

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

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

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

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

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

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

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

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

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

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

Общие

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

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

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

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

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

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

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

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

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

Разница между хранилищем данных и киоском данных
АтрибутХранилище данныхВитрина данных
Объем данныхв масштабе предприятияв масштабе всего отдела
Количество предметных областейнесколькоодиночных
Насколько сложно построитьсложнолегко
Сколько времени требуется для созданиябольшеменьше
Объем памятибольшеограничено

Типы витрин данных включают зависимые, независимые и гибридные витрины данных.

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

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

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

История

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

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

  • 1960-е годы - General Mills и Дартмутский колледж в совместном исследовательском проекте разработали термины, измерения и факты.
  • 1970-е годы - ACNielsen и IRI предоставляют витрины размерных данных для розничных продаж.
  • 1970-е годы - Билл Инмон начинает определять и обсуждать термин «данные» Warehouse.
  • 1975 - Sperry Univac представляет MAPPER (MAintain, Prepare и Produce Executive Reports), систему управления базами данных и отчетности, которая включает первую в мире систему 4GL. Это первая платформа, разработанная для создания информационных центров (предшественник современных технологий хранилищ данных).
  • 1983 - Teradata представляет компьютер с базами данных DBC / 1012, специально разработанный для поддержки принятия решений.
  • 1984 - Metaphor Computer Systems, основанная Дэвидом Лиддлом и Доном Массаро, выпускает аппаратный / программный пакет и графический интерфейс для бизнес-пользователей, чтобы создать система управления базами данных и аналитика.
  • 1985 - Sperry Corporation публикует статью (Мартин Джонс и Филип Ньюман) об информационных центрах, в которой они вводят термин хранилище данных MAPPER в контексте информационных центров.
  • 1988 - Барри Девлин и Пол Мерфи публикуют статью «Архитектура для бизнеса и информационной системы», в которой они вводят термин «хранилище бизнес-данных».
  • 1990 - Red Brick Systems, основанная Ральфом Кимбаллом, представляет Red Brick Warehouse, в частности систему управления базами данных для хранилищ данных.
  • 1991 - Prism Solutions, основанная Биллом Инмоном, представляет Prism Warehouse Manager, программное обеспечение для разработки хранилищ данных.
  • 1992 - Билл Инмон издает книгу Building the Data Warehouse.
  • 1995 - Основание Data Warehousing Institute, коммерческой организации, продвигающей хранилище данных.
  • 1996 - Ральф Кимбалл издает книгу The Data Warehouse Toolkit.
  • 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_success2_success_bts1 + tch_req_rets2 + tch_req_success2 + tch_req_success2_success_bts1 + tch_req_rets2_success>) подходы к хранению данных в хранилище данных - наиболее важными подходами являются размерный подход и нормализованный подход.

    Размерный подход относится к подходу Ральфа Кимбалла, в котором утверждается, что хранилище данных следует моделировать с использованием размерной модели / звездообразной схемы. Нормализованный подход, также называемый моделью 3NF (третья нормальная форма), относится к подходу Билла Инмона, в котором говорится, что хранилище данных следует моделировать с использованием модели E-R / нормализованной модели.

    Подход с измерениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Энергонезависимая

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

    Параметры хранилища данных

    Агрегация

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

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

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

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

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

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

    Развитие в использовании организации

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

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

    Re ferences

    Дополнительная литература

    • Дэвенпорт, Томас Х. и Харрис, Джин Г. Конкуренция в области аналитики: новая наука о победе (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
    • Linstedt, Graziano, Hultgren. Бизнес моделирования хранилищ данных, второе издание (2010) Дэн Линстедт, ISBN 978-1-4357-1914-9
    • Уильям Инмон. Создание хранилища данных (2005) John Wiley and Sons, ISBN 978-81-265-0645-3
Последняя правка сделана 2021-05-17 14:11:36
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте