Курс «Хранилища данных»


Оглавление (нажмите, чтобы открыть):

Проектирование хранилищ больших объемов данных

Осень 2020

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

— Умение доказать необходимость внедрения ХД
— Умение выбрать между подходами к построению ХД по Кимбаллу и Инмону
— Знание основных подходов к проектированию БД (OLAP, Data Vault, Anchor modeling) и умение сделать обоснованный выбор между ними
— Умение проектировать потоки данных с помощью code-driven средств
— Базовые навыки работы с MPP системами и Hadoop
— Навык выбора СУБД, модели данных и ETL-инструмента адекватно задаче

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

Курс Реализация хранилища данных SQL (Код: 20767)

Этот пятидневный курс под руководством инструктора дает студентам знания и навыки для предоставления базы данных Microsoft SQL Server. Курс охватывает предоставление SQL Server как локально, так и в Azure, а также установку из новой и миграцию из существующей установки.

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

  • Базовые знания операционной системы Microsoft Windows и ее основных функций.
  • Знание реляционных баз данных.
  • Некоторый опыт проектирования баз данных.

Модуль 1: Введение в хранилище данных

Этот модуль описывает концепции хранилища данных и рассмотрение архитектуры.

  • Обзор хранилищ данных
  • Соображения по поводу решения для хранилища данных

Лабораторная работа: изучение решения для хранилища данных

  • Изучение источников данных
  • Изучение процесса ETL
  • Изучение хранилища данных

После завершения этого модуля вы сможете:

  • Описывать ключевые элементы решения для хранилищ данных
  • Описывать ключевые аспекты решения для хранилища данных

Модуль 2: Планирование инфраструктуры хранилища данных

Этот модуль описывает основные аппаратные соображения для построения хранилища данных.

  • Соображения относительно инфраструктуры хранилища данных.
  • Планирование оборудования хранилища данных.

Лабораторная работа: планирование инфраструктуры хранилища данных

  • Планирование оборудования хранилища данных

После завершения этого модуля вы сможете:

  • Описывать основные аппаратные соображения для построения хранилища данных
  • Объяснять, как использовать эталонные архитектуры и устройства хранилища данных для создания хранилища данных

Модуль 3: Проектирование и реализация хранилища данных

Этот модуль описывает, как вы приступаете к разработке и реализации схемы для хранилища данных.

  • Обзор дизайна хранилища данных
  • Разработка таблиц измерений
  • Разработка таблиц фактов
  • Физический дизайн для хранилища данных

Лабораторная работа: реализация схемы хранилища данных

  • Реализация звездной схемы
  • Реализация схемы снежинки
  • Реализация таблицы измерения времени

После завершения этого модуля вы сможете:

  • Реализовывать логический дизайн для хранилища данных
  • Реализовывать физический дизайн хранилища данных

Модуль 4: Индексы Columnstore

Этот модуль представляет Columnstore Indexes.

  • Введение в индексы Columnstore
  • Создание индексов Columnstore
  • Работа с индексами Columnstore

Лабораторная работа: использование индексов Columnstore

  • Создайте индекс Columnstore в таблице FactProductInventory
  • Создайте индекс Columnstore в таблице FactInternetSales
  • Создать оптимизированную для памяти таблицу Columnstore

После завершения этого модуля вы сможете:

  • Создавать индексы Columnstore
  • Работать с индексами Columnstore

Модуль 5: Реализация хранилища данных SQL Azure

В этом модуле описаны хранилища данных SQL Azure и способы их реализации.

  • Преимущества хранилища данных SQL Azure
  • Реализация хранилища данных SQL Azure
  • Разработка хранилища данных SQL Azure
  • Миграция в хранилище данных Azure SQ
  • Копирование данных с помощью фабрики данных Azure

Лабораторная работа: реализация хранилища данных SQL Azure

  • Создайте базу данных хранилища данных Azure SQL
  • Миграция в базу данных хранилища данных SQL Azure
  • Скопируйте данные с помощью фабрики данных Azure.

После завершения этого модуля вы сможете:

  • Описывать преимущества хранилища данных SQL Azure
  • Реализовывать хранилище данных SQL Azure
  • Описывать рекомендации по разработке хранилища данных SQL Azure
  • Планировать миграции в хранилище данных SQL Azure

Модуль 6: Создание решения ETL

В конце этого модуля вы сможете реализовать поток данных в пакете служб SSIS.

  • Введение в ETL с SSIS
  • Изучение исходных данных
  • Реализация потока данных

Лабораторная работа: реализация потока данных в пакете служб SSIS

  • Изучение исходных данных
  • Передача данных с помощью задачи строки данных
  • Использование компонентов преобразования в строке данных

После завершения этого модуля вы сможете:

  • Описывать ETL с помощью SSIS
  • Исследовать исходные данные
  • Реализовывать поток данных

Модуль 7: Реализация потока управления в пакете служб SSIS

Этот модуль описывает реализацию потока управления в пакете служб SSIS.

  • Введение в поток управления
  • Создание динамических пакетов
  • Использование контейнеров
  • Управление согласованностью.

Лабораторная работа: реализация потока управления в пакете служб SSIS

  • Использование задач и приоритетов в потоке управления
  • Использование переменных и параметров
  • Использование контейнеров

Лабораторная работа: использование транзакций и контрольных точек

  • Использование транзакций
  • Использование контрольных точек

После завершения этого модуля вы сможете:

  • Описывать поток управления
  • Создавать динамические пакеты
  • Использовать контейнеры

Модуль 8. Отладка и устранение неполадок пакетов служб SSIS

Этот модуль описывает, как отлаживать и устранять неполадки пакетов служб SSIS.

  • Отладка пакета служб SSIS
  • Регистрация событий пакета служб SSIS
  • Обработка ошибок в пакете служб SSIS

Лабораторная работа: отладка и устранение неполадок пакета служб SSIS

  • Отладка пакета служб SSIS
  • Регистрация выполнения пакета служб SSIS
  • Реализация обработчика событий
  • Обработка ошибок в потоке данных

После завершения этого модуля вы сможете:

  • Отлаживать пакета служб SSIS
  • Журналировать событий пакета служб SSIS
  • Обрабатывать ошибки в пакете служб SSIS

Модуль 9: Внедрение решения для извлечения данных

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

  • Введение в инкрементный ETL
  • Извлечение модифицированных данных
  • Загрузка измененных данных
  • Временные таблицы

Лабораторная работа: извлечение измененных данных

  • Использование столбца datetime для постепенного извлечения данных
  • Использование сбора данных изменений
  • Использование задачи управления CDC
  • Использование отслеживания изменений

Лабораторная работа: загрузка хранилища данных

  • Загрузка данных из таблиц вывода CDC
  • Использование преобразования поиска для вставки или обновления данных измерений
  • Реализация медленно меняющегося измерения
  • Использование оператора слияния

После завершения этого модуля вы сможете:

  • Описывать инкрементный ETL
  • Извлекать измененные данные
  • Загружать измененные данные.
  • Описывать временные таблицы

Модуль 10: обеспечение качества данных

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

  • Введение в качество данных
  • Использование служб качества данных для очистки данных
  • Использование служб качества данных для сопоставления данных

Лаборатория: очистка данных

  • Создание базы знаний DQS
  • Использование проекта DQS для очистки данных
  • Использование DQS в пакете служб SSIS

Лабораторная работа: дедупликация данных

  • Создание соответствующей политики
  • Использование проекта DS для сопоставления данных

После завершения этого модуля вы сможете:

  • Описывать данные качества услуг
  • Очищать данные с помощью услуг качества данных
  • Сопоставлять данные, используя службы качества данных
  • Устранять дубликаты данных, используя службы качества данных

Модуль 11: Использование сервисов основных данных

Этот модуль описывает, как реализовать службы основных данных для обеспечения целостности данных в источнике.

  • Введение в службы основных данных
  • Реализация модели сервисов основных данных
  • Иерархии и коллекции
  • Создание центра основных данных

Лабораторная работа: внедрение сервисов основных данных

  • Создание модели сервисов основных данных
  • Использование надстройки служб основных данных для Excel
  • Обеспечение соблюдения бизнес-правил
  • Загрузка данных в модель
  • Использование данных сервисов основных данных

После завершения этого модуля вы сможете:

  • Описывать ключевые концепции службы основных данных
  • Реализовывать модель службы основных данных
  • Управлять основными данными
  • Создать центр основных данных

Модуль 12. Расширение служб интеграции с SQL Server (SSIS)

Этот модуль описывает, как расширить SSIS с помощью пользовательских сценариев и компонентов.

  • Использование сценариев в SSIS
  • Использование пользовательских компонентов в SSIS

Лабораторная работа: использование скриптов

  • Использование задачи скрипта

После завершения этого модуля вы сможете:

  • Использовать пользовательские компоненты в SSIS
  • Использовать сценарии в SSIS

Модуль 13: Развертывание и настройка пакетов служб SSIS

Этот модуль описывает, как развернуть и настроить пакеты служб SSIS.

  • Обзор развертывания служб SSIS
  • Развертывание проектов служб SSIS
  • Планирование выполнения пакета служб SSIS

Лабораторная работа: развертывание и настройка пакетов служб SSIS

  • Создание каталога служб SSIS
  • Развертывание проекта SSIS
  • Создание сред для решения служб SSIS
  • Запуск пакета служб SSIS в студии управления SQL-сервером
  • Планирование пакетов служб SSIS с помощью агента сервера SQL

После завершения этого модуля вы сможете:

  • Описывать развертывание служб SSIS
  • Развертывать пакеты служб SSIS
  • Планировать выполнение пакетов служб SSIS

Модуль 14: Использование данных в хранилище данных

Этот модуль описывает, как отлаживать и устранять неполадки пакетов служб SSIS.

  • Введение в бизнес-аналитику
  • Введение в анализ данных
  • Введение в отчетность
  • Анализ данных с помощью хранилища данных SQL Azure

Лабораторная работа: использование хранилища данных

  • Изучение отчетов службы отчетов
  • Изучение книги PowerPivot
  • Изучение отчета Power View

После завершения этого модуля вы сможете:

  • Описывать на высоком уровне бизнес-аналитики
  • Показывать понимание отчетности
  • Показывать понимание анализа данных
  • Анализировать данные с помощью хранилища данных Azure SQL

Учебный курс Хранилища данных Лекция 1 Понятия о

Презентация про хранилища данных.ppt

Учебный курс Хранилища данных Лекция 1 Понятия о хранилищах Лекции читает Кандидат технических наук, доцент Перминов Геннадий Иванович

Хранилище – компонент BI Хранилище данных Средства конечного пользователя Инфраструктура Инструменты извлечения, преобразования и очистки данных Инструменты администрирования хранилища Инструменты Business Intelligence Приложения Business Intelligence Витрины данных Поиск закономерностей 2

Место хранилища в информационной технологии поддержки принятия решений Системы поддержки принятия решений Аналитические приложения (B I ) Аналитические приложения OLAP ИАД Имитация Нечеткие множества Иерархия (BI) Эконометрика Спец. Отчеты Хранилище (Data Warehouse) Интеллектуальные интерфейсы Системы планирования ресурсов (ERP) Корпоративные информационные системы (CIS) Клиент-серверные приложения ( «Тонкие клиенты» ) 3

Расхождения в требованиях к хранению данных в БД и ХД Традиционные данные, хранимые в БД Данные для принятия решений Детализированы Обобщены либо очищены Точны в момент доступа Представляют значения на указанное время Могут корректироваться Не корректируются, если введены в Хранилище Требования к способам дальнейшей обработки выясняются заранее Требования к способам дальнейшей обработки не имеют первостепенного значения Строятся на основе обычного цикла разработки систем Совершенно иной цикл разработки систем Чувствительны к производительности БД и поэтому предъявляют к ним жесткие требования Мягкие требования к производительности БД 4

Продолжение таблицы Обрабатывается один данных за один запрос элемент Обрабатывается множество элементов данных за один запрос Управляются транзакциями Управляются аналитическими запросами Ориентированы на приложения Ориентированы на анализ Высокая степень доступности Относительная доступность Контролируется целостность всех данных Контролируется целостность подмножества данных Данные не избыточны Данные избыточны Статическая структура, произвольное содержание Гибкая структура Массивы данных редко используются Массивы данных широко в процессе обработки используются в процессе обработки Поддерживают ежедневные операции Поддерживают периодический анализ 5

Появление хранилищ вызвано, двумя причинами: аналитическая работа с данными в ХД (специализированных БД) не сказывается на производительности основных БД; аналитики и работники управления могут полностью ориентироваться на специализированные хранилища в режиме «Что, если. . . «. 6

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

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

Вывод из опыта использования БД Возникает необходимость в технологиях, позволяющих автоматически собирать данные из различных баз данных, систем обработки данных, согласовывать и объединять в предметно-ориентированный формат, который нужен аналитикам. 9

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

Основные составляющие Хранилища данных: предметная ориентированность; интегрированность (целостность и внутренняя взаимосвязь); временная привязка; неразрушаемая совокупность данных. 11

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

Интегрированность (целостность и внутренняя взаимосвязь): Несмотря на то что данные погружаются из различных источников, но они объединены едиными законами именования, способами измерения атрибутов и др. Это имеет большое значение для корпоративных организаций, в которых одновременно могут эксплуатироваться различные по своей архитектуре вычислительные системы, представляющие одинаковые данные по -разному. Например, могут использоваться несколько различных форматов представления дат или один и тот же показатель может называться по-разному, например, «вероятность доведения информации» и «вероятность получения информации». В процессе погружения подобные несоответствия устраняются автоматически; 13

Временная привязка: Оперативные системы охватывают небольшой интервал времени, что достигается за счет периодического архивирования данных. DW, напротив, содержит исторические данные, накопленные за большой интервал времени (пять—семь лет); 14

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

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

Разновидности хранилищ – витрины данных: Поскольку конструирование хранилища данных — сложный процесс, который может занять несколько лет, некоторые организации вместо этого строят витрины данных (data mart), содержащие информацию для конкретных подразделений. Например, маркетинговая витрина данных может содержать только информацию о клиентах, продуктах и продажах и не включать в себя планы поставок. Несколько витрин данных для подразделений могут сосуществовать с основным хранилищем данных, давая частичное представление о содержании хранилища. Витрины данных строятся значительно быстрее, чем хранилище, но впоследствии могут возникнуть серьезные проблемы с интеграцией, если первоначальное планирование проводилось без учета 17 полной бизнес-модели.

Компонента— средства извлечения, преобразования и загрузки данных: этап извлечения и преобразования; этап очистки данных; этап загрузки; этап обновления; управление метаданными. 18

Этап извлечения и преобразования Цель этапа извлечения данных — перенести данные из разнородных источников в базу данных, где их можно модифицировать и добавить в хранилище. Цель последующего этапа преобразования данных — устранить несоответствия в схеме и соглашениях о значениях атрибутов. Набор правил и скриптов, как правило, выполняет преобразование данных из исходной схемы в итоговую схему. К примеру, дистрибьютор может разделить имя каждого клиента на три части: имя, отчество (или инициалы) и фамилия. 19

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

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

Этап обновления Должны быть рассмотрены два вопроса: когда обновлять и как обновлять: 1. Обычно хранилища данных обновляются периодически в соответствии с заранее установленным расписанием, например, ежедневно или еженедельно. 2. Администраторы хранилища данных определяют правила обновления в зависимости от требований пользователей и трафика. Расписание обновлений может быть различным для разных источников данных. 22

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

Технологии хранения данных

1. Денормализованные, пространственные базы данных 25


Денормализованные, пространственные базы данных Одним из направлений развития РБД в интересах систем принятия решений является разработка таблиц с денормализованной формой (модификации схемы организации данных типа звезда). Структура такой базы данных не будет реляционной — это будет пространственная база данных с целью анализа данных, а не выполнения транзакций. 26

Методология Dimensional Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. В результате, выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что существенно увеличивает время отклика. Создание хранилища данных подразумевает создание денормализованной структуры данных (допускается избыточность данных и возможность возникновения аномалий при манипулировании данными), ориентированной в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и ухудшает эффективность выполнения запроса. 27

Как проектировать ненормализованную БД? Большинство Case – средств проектирования БД поддерживает методологию моделирования хранилищ благодаря использованию специальной нотации для физической модели – Dimensional. 28

Особенности проектирования Моделирование Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличаются целями. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная (Dimensional) модель ориентирована в первую очередь на выполнение сложных запросов к БД. 29

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

Основные составляющие структуры хранилищ данных Схема звезда обычно содержит одну большую таблицу, называемую таблицей факта (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта — дочерней. Схема звезда может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности дочерними. 31

Структура ХД — звезда 32

Структура ХД — снежинка 33

Обозначения таблиц в схеме “звезда” 34

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

О связи таблицы фактов с таблицами измерений Таблица факта является центральной таблицей в схеме звезда. Она может состоять из миллионов строк и содержать суммирующие или фактические данные, которые могут помочь ответить на требуемые вопросы. Она соединяет данные, которые хранились бы во многих таблицах традиционных реляционных базах данных. Таблица факта и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу факта в качестве внешних ключей. В размерной модели направления связей явно не показываются – они определяются типом таблиц. Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в 36 меньшие по объему таблицы измерений.

Первичный ключ (таблица факта “REVENUE”) составлен из четырех внешних ключей: movie_key, market_key, customer_key и time_key 37

Наиболее часто встречающихся типы фактов факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата); факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). 38

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

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

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

Отличие от схемы «звезда» Если хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). 42

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

Закладка Dimensional диалога Table Editor В диалоге описания свойств таблицы Table Editor имеется закладка Dimensional, в которой задаются специфические свойства таблицы в размерной модели, роль таблицы в схеме (Dimensional Modeling Role) 44

Правила хранения данных (Data Warehouse Rules) Для каждой таблицы можно задать шесть типов правил манипулирования данными: обновление (Refresh), дополнение (Append), резервное копирование (Backup), восстановление (Recovery), архивирование (Archiving) и очистка (Purge). Для задания правила следует выбрать имя правила из соответствующего списка выбора. Каждое правило должно быть предварительно описано в диалоге Data Warehouse Rule Editor (меню Edit / Data Warehouse Rule). Для каждого правила должно быть задано имя, тип, определение. Например, определение правила дополнения данных может включать частоту и время дополнения (ежедневно, в конце рабочего дня), продолжительность операции и т. д. Связать правила с определенной таблицей можно с помощью диалога Table Editor. 45

Мастер Йода рекомендует:  Зарплаты в IT на 2020 год «богатые» архитекторы ПО и «бедные» омские разработчики

2. Кубы данных (многомерная модель данных) 46

Хранилища данных и OLAP-средства (стр. 1 из 2)

1 Вечное хранение данных

2 Важная терминология

3 Базы и хранилища данных

4 Неизменный спутник хранилищ данных

5 Некоторые аспекты хранения данных

5.1 Структуры хранения данных

6 Несколько советов по повышению производительности OLAP-кубов

Тема контрольной работы «Хранилища данных и OLAP- средства».

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

1 Вечное хранение данных

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

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

В оперативных БД информация может добавляться, удаляться и изменяться, а в ХД данные могут только загружаться и читаться. При этом все данные в ХД данных делятся на три основных категории:

2 Важная терминология

Хранилище данных( Data Warehouse ). Предметно-ориентированный, интегрированный, неизменяемый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений (по определению основателя хранилищ данных Б. Инмона). Более просто: это база данных, хранящая данные, агрегированные по многим измерениям.

Витрина (или киоск) данных ( Data Mart ). Небольшое хранилище, а конечные пользователи могут создавать собственные структуры данных в нем.

Информационная система руководителя (ИСР) ( Executive Information System ([ EIS )). Приложения, созданные для использования руководителями.

Средства OLAP ( On line Analytical Processing ). Инструментарий навигации по многомерным данным.

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

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

HOLAP( Hybrid OLAP ). Детальные данные остаются на месте (в реляционной БД), а агрегаты хранятся в многомерной БД.

Оперативные БД. Этот термин обозначает традиционные БД и введен для того, чтобы подчеркнуть их существенное отличие от БД, используемых для реализации ХД.

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

3 Базы и хранилища данных

Ни для кого не секрет, что одним из основных факторов успеха в бизнесе и управлении является скорость и качество принимаемых решений. А вот в основе этих решений лежит имеющаяся информация. В эпоху глобальной компьютеризации информация получается из данных, которые хранятся в электронном виде в файлах различных форматов. Для эффективного хранения данных сегодня используются базы данных (БД), а точнее СУБД — системы управления базами данных. В составе любой базы данных имеются таблицы, между полями которой существуют связи (реляции, отношения). Отсюда и название «реляционные БД». Именно с их помощью можно структурировать информацию и обеспечивать быстрый и удобный доступ к ней.

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

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

Несомненно, базы данных — это незаменимый источник информации. Кроме того, они используются как в локальных финансово-учетных системах, так и MRP- и ERP-системах. Но ведь обычная БД обслуживает не только руководителей, принимающих решения, но и других пользователей непосредственно работающих с данными, что сказывается на скорости обработки информационных потоков.

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

Вот поэтому все чаще взоры экспертов и аналитиков обращены к хранилищам данных (ХД) — оптимально организованной БД, хранящей данные, агрегированные по многим измерениям, и обеспечивающей максимально быстрый доступ к информации, необходимой для принятия управленческих решений. Данные в ХД попадают из оперативных БД и систем, которые предназначены для автоматизации бизнес-процессов. Кроме того, ХД может пополняться из внешних источников, например, статистических отчетов. Резонный вопрос: чем ХД лучше БД? Ведь они содержат заведомо избыточную информацию, которая хранится в БД или файлах оперативных систем? Анализировать данные оперативных систем непосредственно невозможно или, по крайней мере, весьма затруднительно, так как данные хранятся в форматах различных СУБД и на разных носителях в корпоративной сети.

Пополнение ХД происходит периодически, при этом автоматически формируются новые агрегаты данных, зависящие от старых, т. е. в одном месте и в простой структуре хранится «сырье» для анализа (рис. 1).

Если до недавнего времени для анализа имеющихся данных применялась схема: БД — Средство анализа,то в быстро развивающаяся концепция хранилищ данных (ХД) предлагает изменить эту схему: БД — объекты ХД — Средство анализа.Это и есть суть информационная система нового поколения.

4 Неизменный спутник хранилищ данных

Централизация и удобное структурирование данных — это далеко не все, что нужно аналитику. Традиционные отчеты, даже построенные на основе единого хранилища, лишены гибкости. Они не позволяют

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

Не вдаваясь в сложную теорию определяющих принципов OLAP, сформулированных Е. Коддом — «изобретателем» реляционных БД, приведем следующее определение OLAP: Быстрый Анализ Разделяемой Многомерной Информации — FASMI (FastAnalysisofSharedMultidimensionalInformation). Fast означает, что система должна обеспечивать выдачу большинства ответов пользователям в пределах 5 секунд. Analysis означает, что система может справляться с любым логическим и статистическим анализом. Shared означает, что система осуществляет все требования конфиденциальности (возможно до уровня записи), а при доступе нескольких пользователей обеспечивает блокировку изменений на соответствующем уровне. Multidimensional — система должна обеспечить многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий данных. И, наконец, Information — это все, с чем мы работаем каждый день и пытаемся на ее основе получить прогнозируемые результаты.

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

Курс Реализация хранилища данных SQL (Код: 20767)

Этот пятидневный курс под руководством инструктора дает студентам знания и навыки для предоставления базы данных Microsoft SQL Server. Курс охватывает предоставление SQL Server как локально, так и в Azure, а также установку из новой и миграцию из существующей установки.

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

  • Базовые знания операционной системы Microsoft Windows и ее основных функций.
  • Знание реляционных баз данных.
  • Некоторый опыт проектирования баз данных.

Модуль 1: Введение в хранилище данных

Этот модуль описывает концепции хранилища данных и рассмотрение архитектуры.

  • Обзор хранилищ данных
  • Соображения по поводу решения для хранилища данных

Лабораторная работа: изучение решения для хранилища данных

  • Изучение источников данных
  • Изучение процесса ETL
  • Изучение хранилища данных

После завершения этого модуля вы сможете:

  • Описывать ключевые элементы решения для хранилищ данных
  • Описывать ключевые аспекты решения для хранилища данных

Модуль 2: Планирование инфраструктуры хранилища данных

Этот модуль описывает основные аппаратные соображения для построения хранилища данных.

  • Соображения относительно инфраструктуры хранилища данных.
  • Планирование оборудования хранилища данных.

Лабораторная работа: планирование инфраструктуры хранилища данных

  • Планирование оборудования хранилища данных

После завершения этого модуля вы сможете:

  • Описывать основные аппаратные соображения для построения хранилища данных
  • Объяснять, как использовать эталонные архитектуры и устройства хранилища данных для создания хранилища данных

Модуль 3: Проектирование и реализация хранилища данных

Этот модуль описывает, как вы приступаете к разработке и реализации схемы для хранилища данных.

  • Обзор дизайна хранилища данных
  • Разработка таблиц измерений
  • Разработка таблиц фактов
  • Физический дизайн для хранилища данных

Лабораторная работа: реализация схемы хранилища данных

  • Реализация звездной схемы
  • Реализация схемы снежинки
  • Реализация таблицы измерения времени

После завершения этого модуля вы сможете:

  • Реализовывать логический дизайн для хранилища данных
  • Реализовывать физический дизайн хранилища данных

Модуль 4: Индексы Columnstore

Этот модуль представляет Columnstore Indexes.

  • Введение в индексы Columnstore
  • Создание индексов Columnstore
  • Работа с индексами Columnstore

Лабораторная работа: использование индексов Columnstore

  • Создайте индекс Columnstore в таблице FactProductInventory
  • Создайте индекс Columnstore в таблице FactInternetSales
  • Создать оптимизированную для памяти таблицу Columnstore

После завершения этого модуля вы сможете:

  • Создавать индексы Columnstore
  • Работать с индексами Columnstore

Модуль 5: Реализация хранилища данных SQL Azure

В этом модуле описаны хранилища данных SQL Azure и способы их реализации.

  • Преимущества хранилища данных SQL Azure
  • Реализация хранилища данных SQL Azure
  • Разработка хранилища данных SQL Azure
  • Миграция в хранилище данных Azure SQ
  • Копирование данных с помощью фабрики данных Azure

Лабораторная работа: реализация хранилища данных SQL Azure

  • Создайте базу данных хранилища данных Azure SQL
  • Миграция в базу данных хранилища данных SQL Azure
  • Скопируйте данные с помощью фабрики данных Azure.

После завершения этого модуля вы сможете:

  • Описывать преимущества хранилища данных SQL Azure
  • Реализовывать хранилище данных SQL Azure
  • Описывать рекомендации по разработке хранилища данных SQL Azure
  • Планировать миграции в хранилище данных SQL Azure

Модуль 6: Создание решения ETL

В конце этого модуля вы сможете реализовать поток данных в пакете служб SSIS.

  • Введение в ETL с SSIS
  • Изучение исходных данных
  • Реализация потока данных

Лабораторная работа: реализация потока данных в пакете служб SSIS

  • Изучение исходных данных
  • Передача данных с помощью задачи строки данных
  • Использование компонентов преобразования в строке данных

После завершения этого модуля вы сможете:

  • Описывать ETL с помощью SSIS
  • Исследовать исходные данные
  • Реализовывать поток данных

Модуль 7: Реализация потока управления в пакете служб SSIS

Этот модуль описывает реализацию потока управления в пакете служб SSIS.

  • Введение в поток управления
  • Создание динамических пакетов
  • Использование контейнеров
  • Управление согласованностью.

Лабораторная работа: реализация потока управления в пакете служб SSIS

  • Использование задач и приоритетов в потоке управления
  • Использование переменных и параметров
  • Использование контейнеров

Лабораторная работа: использование транзакций и контрольных точек

  • Использование транзакций
  • Использование контрольных точек

После завершения этого модуля вы сможете:

  • Описывать поток управления
  • Создавать динамические пакеты
  • Использовать контейнеры

Модуль 8. Отладка и устранение неполадок пакетов служб SSIS

Этот модуль описывает, как отлаживать и устранять неполадки пакетов служб SSIS.

  • Отладка пакета служб SSIS
  • Регистрация событий пакета служб SSIS
  • Обработка ошибок в пакете служб SSIS

Лабораторная работа: отладка и устранение неполадок пакета служб SSIS

  • Отладка пакета служб SSIS
  • Регистрация выполнения пакета служб SSIS
  • Реализация обработчика событий
  • Обработка ошибок в потоке данных

После завершения этого модуля вы сможете:

  • Отлаживать пакета служб SSIS
  • Журналировать событий пакета служб SSIS
  • Обрабатывать ошибки в пакете служб SSIS

Модуль 9: Внедрение решения для извлечения данных

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

  • Введение в инкрементный ETL
  • Извлечение модифицированных данных
  • Загрузка измененных данных
  • Временные таблицы

Лабораторная работа: извлечение измененных данных

  • Использование столбца datetime для постепенного извлечения данных
  • Использование сбора данных изменений
  • Использование задачи управления CDC
  • Использование отслеживания изменений

Лабораторная работа: загрузка хранилища данных

  • Загрузка данных из таблиц вывода CDC
  • Использование преобразования поиска для вставки или обновления данных измерений
  • Реализация медленно меняющегося измерения
  • Использование оператора слияния

После завершения этого модуля вы сможете:

  • Описывать инкрементный ETL
  • Извлекать измененные данные
  • Загружать измененные данные.
  • Описывать временные таблицы

Модуль 10: обеспечение качества данных

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

  • Введение в качество данных
  • Использование служб качества данных для очистки данных
  • Использование служб качества данных для сопоставления данных

Лаборатория: очистка данных

  • Создание базы знаний DQS
  • Использование проекта DQS для очистки данных
  • Использование DQS в пакете служб SSIS

Лабораторная работа: дедупликация данных

  • Создание соответствующей политики
  • Использование проекта DS для сопоставления данных

После завершения этого модуля вы сможете:

  • Описывать данные качества услуг
  • Очищать данные с помощью услуг качества данных
  • Сопоставлять данные, используя службы качества данных
  • Устранять дубликаты данных, используя службы качества данных

Модуль 11: Использование сервисов основных данных

Этот модуль описывает, как реализовать службы основных данных для обеспечения целостности данных в источнике.

  • Введение в службы основных данных
  • Реализация модели сервисов основных данных
  • Иерархии и коллекции
  • Создание центра основных данных

Лабораторная работа: внедрение сервисов основных данных

  • Создание модели сервисов основных данных
  • Использование надстройки служб основных данных для Excel
  • Обеспечение соблюдения бизнес-правил
  • Загрузка данных в модель
  • Использование данных сервисов основных данных

После завершения этого модуля вы сможете:

  • Описывать ключевые концепции службы основных данных
  • Реализовывать модель службы основных данных
  • Управлять основными данными
  • Создать центр основных данных

Модуль 12. Расширение служб интеграции с SQL Server (SSIS)

Этот модуль описывает, как расширить SSIS с помощью пользовательских сценариев и компонентов.


  • Использование сценариев в SSIS
  • Использование пользовательских компонентов в SSIS

Лабораторная работа: использование скриптов

  • Использование задачи скрипта

После завершения этого модуля вы сможете:

  • Использовать пользовательские компоненты в SSIS
  • Использовать сценарии в SSIS

Модуль 13: Развертывание и настройка пакетов служб SSIS

Этот модуль описывает, как развернуть и настроить пакеты служб SSIS.

  • Обзор развертывания служб SSIS
  • Развертывание проектов служб SSIS
  • Планирование выполнения пакета служб SSIS

Лабораторная работа: развертывание и настройка пакетов служб SSIS

  • Создание каталога служб SSIS
  • Развертывание проекта SSIS
  • Создание сред для решения служб SSIS
  • Запуск пакета служб SSIS в студии управления SQL-сервером
  • Планирование пакетов служб SSIS с помощью агента сервера SQL

После завершения этого модуля вы сможете:

  • Описывать развертывание служб SSIS
  • Развертывать пакеты служб SSIS
  • Планировать выполнение пакетов служб SSIS

Модуль 14: Использование данных в хранилище данных

Этот модуль описывает, как отлаживать и устранять неполадки пакетов служб SSIS.

  • Введение в бизнес-аналитику
  • Введение в анализ данных
  • Введение в отчетность
  • Анализ данных с помощью хранилища данных SQL Azure

Лабораторная работа: использование хранилища данных

  • Изучение отчетов службы отчетов
  • Изучение книги PowerPivot
  • Изучение отчета Power View

После завершения этого модуля вы сможете:

  • Описывать на высоком уровне бизнес-аналитики
  • Показывать понимание отчетности
  • Показывать понимание анализа данных
  • Анализировать данные с помощью хранилища данных Azure SQL

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

Контакты:

Навигация

Прикладная математика и информатика

Математика и компьютерные науки

Математическое обеспечение и администрирование инф.

Картография и геоинформатика

Экология и природопользование

Информатика и вычислительная техника

Информационные системы и технологии

Инфокоммуникационные технологии и системы связи

Лазерная техника и лазерные технологии

Государственное и муниципальное управление

2015, Информационные технологии в бизнесе, Очная

2020, Информационные технологии в бизнесе, Очная

2020, Информационные технологии в бизнесе, Очная

2020, Информационные системы в бизнесе и управлени.

2020, Информационные системы в бизнесе и управлени.

Проектирование хранилищ больших объемов данных

Осень 2020

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

— Умение доказать необходимость внедрения ХД
— Умение выбрать между подходами к построению ХД по Кимбаллу и Инмону
— Знание основных подходов к проектированию БД (OLAP, Data Vault, Anchor modeling) и умение сделать обоснованный выбор между ними
— Умение проектировать потоки данных с помощью code-driven средств
— Базовые навыки работы с MPP системами и Hadoop
— Навык выбора СУБД, модели данных и ETL-инструмента адекватно задаче

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

Образовательная программа по курсу: «Хранилища данных и информационно-аналитические системы»

Министерство образования и науки Российской Федерации

Федеральное государственное автономное образовательное учреждение

«Московский физико-технический институт (государственный университет)»

УТВЕРЖДАЮ

Первый проректор

«_____» ______________ 2012 г.

ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА

ПО КУРСУ: «Хранилища данных и информационно-аналитические системы»

магистерская программа: физико-техническая информатика

Факультет инноваций и высоких технологий

Кафедра физико-технической информатики

Практические (семинарские) занятия 16 ч.

Лабораторные занятия часов

Зачет (диф.) X семестр

Самостоятельная работа часов в неделю

Составители (или автор): к. ф.-м. н.

Программа обсуждена на заседании кафедры «_____» _________ 2012 года

Программа утверждена Решением Ученого Совета (Факультет инноваций и высоких технологий)

«___» ________ 2012 г.

Председатель Ученого Совета

Заведующий кафедрой физико-технической информатики

Темы лекционных занятий:

1. Хранилища данных

1.2. Создание многомерного хранилища данных

1.3. Создание структуры витрины

1.4. Построение OLAP срезов. Инструмент анализа Data Analyzer.

2. Информационно-аналитические системы

2.1. Базовые понятия информационно-аналитических систем

2.2. Информационное пространство как среда анализа

2.3. Технологии оперативного и интеллектуального анализа данных

2.4. Основы создания и применения информационно-аналитических систем.

1. Цель курса: изучение основ теории и практики создания, развития и использования Хранилищ данных и информационно-аналитических систем.

2. Хранилища данных

1) Понятия о хранилищах

2) Технологии хранения данных

3) Денормализованные, пространственные базы данных

— Кубы данных (многомерная модель данных)

— Форматы хранения данных в OLAP кубах

5) Создание многомерного хранилища данных

— Подключение к источнику данных (Data Source)

— Создание Data Source View

— Подключение дополнительных размерностей

— Подключение размерности типа «Время и Дата»

— Подключение к кубу размерности, созданной из таблицы фактов

6) Создание структуры витрины

— Создание базы данных для витрины данных

— Создание таблицы измерений

— Заполнение пустой витрины с помощью служб интеграции

7) Построение OLAP срезов. Инструмент анализа Data Analyzer

— Возможности построения OLAP срезов

— Создание сводных диаграмм с данными OLAP-кубов

— Создание локальных OLAP-кубов с помощью Microsoft Excel

— Инструмент анализа Data Analyzer

— Подключение к источникам данных

— Средства анализа данных

3. Информационно-аналитические системы

1) Базовые понятия информационно-аналитических систем

— Аспекты проблемы анализа и их реализация в программных продуктах

2) Информационное пространство как среда анализа

— Понятие информационного пространства

— Элементы структуры информационного пространства. Понятие показателя

— Пространственная интерпретация понятия показатель

— Содержание экономических показателей

3) Технологии оперативного и интеллектуального анализа данных

— Подходы к выполнению анализа средствами информационных технологий (IT-анализа)

— Интеллектуальный анализ данных Data mining

4) Основы создания и применения информационно-аналитических систем

— Программные инструментальные средства ИАС

— Состав программных инструментальных средств ИАС

— Средства сбора и доработки данных

— Средства преобразования данных

— Средства оперативного (OLAP) анализа

— Средства интеллектуального анализа данных

— Управление и проектирование ИАС

— Управление информационно-аналитическими системами

— Задачи и средства администрирования ИАС

— Принципы проектирования информационных хранилищ ИАС

Учебный курс Хранилища данных Лекция 2 Технологии хранения данных Лекции читает Кандидат технических наук, доцент Перминов Геннадий Иванович. — презентация

Презентация была опубликована 5 лет назад пользователемАртем Панкрашин

Похожие презентации

Презентация на тему: » Учебный курс Хранилища данных Лекция 2 Технологии хранения данных Лекции читает Кандидат технических наук, доцент Перминов Геннадий Иванович.» — Транскрипт:

1 Учебный курс Хранилища данных Лекция 2 Технологии хранения данных Лекции читает Кандидат технических наук, доцент Перминов Геннадий Иванович

2 2 2. Кубы данных (многомерная модель данных)

3 3 Понятие о кубах Куб OLAP — это структура, в которой хранятся совокупности данных, полученные из базы данных OLAP путем всех возможных сочетаний измерений с фактами продаж в таблице фактов. Исходя из этого, создание окончательного отчета выполняется гораздо эффективнее, поскольку не требует выполнения никакого сложного запроса.

4 4 Вид трехмерного куба

5 5 Основными понятиями многомерной модели данных являются: Показатель — это величина (обычно числового типа), которая собственно и является предметом анализа. Один OLAP-куб может обладать одним или несколькими показателями. Измерение (dimension) — это множество объектов одного или нескольких типов, организованных в виде иерархической структуры и обеспечивающих информационный контекст числового показателя. Измерение принято визуализировать в виде ребра многомерного куба. Объекты, совокупность которых и образует измерение, называются членами измерений (members). Члены измерений визуализируют как точки или участи, откладываемые на осях гиперкуба. Например, временное измерение: Дни, Месяцы, Кварталы, Годы — наиболее часто используемые в анализе, могут содержать следующие члены: 8 мая 2002 года, май 2002 года, 2-ой квартал 2002 года и 2002 год. Как уже было сказано, объекты в измерениях могут быть различного типа, например «производители» — «марки автомобиля» или «годы» — «кварталы». Эти объекты должны быть организованы в иерархическую структуру так, чтобы объекты одного типа принадлежали только одному уровню иерархии. Ячейка (cell) — атомарная структура куба, соответствующая конкретному значению некоторого показателя. Ячейки при визуализации располагаются внутри куба и здесь же принято отображать соответствующее значение показателя.

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

7 7 Иерархии в измерениях необходимы для возможности агрегации и детализации значений показателей Существуют следующие типы иерархий: сбалансированные (balanced); несбалансированные (unbalanced); Неровные (balanced).

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

9 9 Несбалансированные иерархии Это — иерархии, в которых число уровней может быть изменено, и каждая ветвь иерархического дерева может содержать объекты, принадлежащие не всем уровням, только нескольким первым. Необходимо заметить, что все объекты несбалансированной иерархии принадлежат одному типу. Типичный пример несбалансированной иерархии — иерархия типа «начальник- подчиненный», где все объекты имеют один и тот же тип — «Сотрудник».

10 10 Неровные иерархии Это- иерархии, в которых число уровней определено её структурой и постоянно, однако в отличие от сбалансированной иерархии некоторые ветви иерархического дерева могут не содержать объекты какого-либо уровня. Иерархии такого вида содержат такие члены, логические «родители» которых не находятся на непосредственно вышестоящем уровне. Типичным примером является географическая иерархия, в которой есть уровни «Страны», «Штаты » и «Города», но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями «Страны» и «Города».

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

12 12 DW с витринами данных

13 13 Многомерный куб с несколькими таблицами фактов

14 14 Варианты реализации хранилищ данных: Виртуальное хранилище данных Концепция CIF Концепция Data Warehouse Bus Гибридная многоуровневая архитектура хранилища данных

15 15 Виртуальное хранилище данных В данном случае в отличие от классического (физического) ХД данные из оперативных источников данных (ОИД) не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов в оперативной памяти компьютера. Фактически такие запросы напрямую адресуются к ОИД

16 16 Основными достоинствами виртуального ХД являются: минимизация объема памяти, занимаемой на носителе информацией; работа с текущими, детализированными данными.

17 17 Недостатки технологии виртуального хранилища Время обработки запросов к виртуальному ХД значительно превышает соответствующие показатели для физического хранилища. Интегрированный взгляд на виртуальное хранилище возможен только при выполнении условия постоянной доступности всех ОИД. Таким образом, временная недоступность хотя бы одного из источников может привести либо к невыполнению аналитических запросов, либо к неверным результатам. Различные ОИД могут поддерживать разные форматы и кодировки данных. Часто на один и тот же вопрос может быть получено несколько вариантов ответа. Это может быть связано с несинхронностью моментов обновления данных в разных ОИД, отличиями в описании одинаковых объектов и событий предметной области, ошибками при вводе, утерей фрагментов архивов и т. д. Главным же недостатком виртуального хранилища следует признать практическую невозможность получения данных за долгий период времени. При отсутствии физического хранилища доступны только те данные, которые на момент запроса есть в ОИД. Основное назначение OLTP-систем оперативная обработка текущих данных, поэтому они не ориентированы на хранение данных за длительный период времени. По мере устаревания данные выгружаются в архив и удаляются из оперативной БД.

Мастер Йода рекомендует:  Ajax для Java разработчиков Часть 2. Cпособы сериализации данных для Ajax

18 18 Концепция Corporate Information Factory, (сокр. СIF) Билла Инмона Концепция CIF объединила оперативные приложения, накопители оперативных данных (Operational Data Store, ODS, OLTP-системы), центральное хранилище данных (DW), витрины данных (Data Mart) и системы интеллектуального анализа данных (Data Mining) в единый процесс выработки и потребления информации на предприятии. В CIF оперативные приложения служат для управления частными процессами. ODS накапливают в себе временные срезы различных процессов, происходящих на предприятии, и согласуют их между собой. ODS часто используется как оперативный источник информации. Как правило, ODS хранят значительно более детализированную информацию, чем хранилище, но за меньший период времени от полугода до года, так как для доступа к данным в нем не используются предварительно рассчитываемые агрегаты.

19 19 Работа Хранилища СIF состоит из следующих этапов: скоординированное извлечение данных из источников. загрузка реляционной базы данных, состоящей из таблиц в третьей нормальной форме, содержащей атомарные данные. получившееся нормализованное Хранилище используется для того, чтобы наполнить информацией дополнительные репозитории презентационных данных, т.е. данных, подготовленных для анализа. Эти репозитории, в частности, включают специализированные Хранилища для изучения и «добычи» данных (Data Mining), a также витрины данных.

20 20 Концепция Data Warehouse Bus Использование пространственной модели организации данных с архитектурой «звезда» (star scheme). Использование двухуровневой архитектуры, которая включает стадию подготовки данных, недоступную для конечных пользователей, и Хранилище. В состав последнего входят несколько витрин атомарных данных, несколько витрин агрегированных данных и персональная витрина данных, но оно не содержит одного физически целостного или централизованного Хранилища данных. Хранилище Кимболла — скорее «виртуальный» объект. Это коллекция витрин данных, которые могут быть пространственно разобщенными.

21 21 Гибридное хранилище данных В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных. Тогда естественной становится трехуровневая архитектура системы.

22 22 Гибрид нормализованного и пространственного Хранилищ данных

23 23 Первый уровень гибридного хранилища На первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД. Это хранилище интегрированных в основном детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP- систем, в частности, в связи с требованием многомерного представления данных.

24 24 Второй уровень гибридного хранилища На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.

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

26 26 Форматы хранения данных в OLAP кубах

27 27 Данные форматы различаются методами хранения кубов данных многомерный OLAP-формат (Multi-dimensional OLAP — MOLAP); реляционный OLAP-формат (Relational OLAP — ROLAP); гибридный OLAP-формат (Hybr >

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

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

30 30 Область применения MOLAP объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), т.е. уровень агрегации данных достаточно высок; набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба); время ответа системы на нерегламентированные запросы является наиболее критичным параметром; широкое использование сложных встроенных функций требуется для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможности написания пользовательских функций.

31 31 ROLAP Реляционные хранилища OLAP содержат данные, передаваемые в кубы данных, вместе с агрегациями данных куба, причем данные хранятся в реляционных таблицах, размещенных в реляционном ХД.

32 32 Преимущества ROLAP Преимущества ROLAP : в большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в MOLAP; при переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP-системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД; реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.

33 33 НедостаткиROLAP Недостатки ROLAP Главный недостаток ROLAP по сравнению с MOLAP меньшая производительность. Для обеспечения производительности, сравнимой с многомерными базами данных, необходимо использовать звездообразные схемы. В этом случае производительность реляционных систем может быть приближена к производительности систем на основе MOLAP.

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

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

36 36 Сравнительные характеристики Массивы Записи Структурные элементы Исторические, текущие и прогнозируемые Исторические и текущие Текущие Сроки хранения данных Суммарные Детальные и суммарные Детальные Уровень данных Большой От малого до большого Небольшой Объем данных на транзакцию Определяемые пользователем Неизменяемы е Экраны Высокий СреднийНизкий Уровень аналитических требований Анализ ОтчетОбновление Типовая операция 4321 MOLAPROLAPOLTPХарактеристика

37 37 Достоинства OLAP: простота использования и восприятия выходных таблиц; полнота аналитических данных; полная и легкая настройка отчета без программиста; возможность детализировать отчет в процессе анализа данных (от итогов к деталям); формирование отчетов в 10 раз быстрее; непротиворечивость данных в отчетах; консолидация информации из разных баз данных; повышенная защита данных; эквивалентность одного OLAP-отчета целому набору простых отчетов.

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

39 39 Литература Перминов Г.И. УМК — «Системы интеллектуального анализа данных» (Business Intelligence). ГУ-ВШЭ, Microsoft SQL Server Analysis Services. Под ред. Горбач И. –С-Пб,: БХВ-Петербург, 2007 Э. Спирли. Корпоративные хранилища данных. Планирование, разработка, реализация. Том. 1: Пер. с англ. — М.: «Вильямс»,

Курс «Хранилища данных»

Индивидуальные онлайн уроки: Отправьте запрос сейчас: ut2020@protonmail.com
Математика (ЕГЭ, ОГЭ), Английский язык (разговорный, грамматика, TOEFL)
Решение задач: по математике, IT, экономике, психологии

Тема лекции: « Хранилища данных и системы бизнес-аналитики».

  1. Системы бизнес-интеллекта ( B usiness I ntelligence, BI) .
  2. Системы бизнес-аналитики. С истемы управления эффективностью бизнеса (Business Performance Management, BPM ).
  3. Эффективность аналитических систем.
  1. СИСТЕМЫ БИЗНЕС-ИНТЕЛЛЕКТА ( B USINESS I NTELLIGENCE, BI) .

1.1. Аналитическая пирамида.

Информационную инфраструктуру компании можно представить в виде нескольких иерархических уровней, каждый из которых характеризуется степенью агрегированности информации и своей ролью в процессе управления. В качестве примера схематического представлений информационной инфраструктуры можно привести так называемую «аналитическую пирамиду» (analytical stack), разработанную компанией Gartner (рисунок 1).

В этой иерархии прослеживаются несколько уровней:

1. Уровень транзакционных систем.

2. Уровень систем бизнес-интеллекта, включая хранилища данных, витрины данных и OLAP-системы.

3. Уровень аналитических приложений.

Рисунок 1. Аналитическая пирамида.

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

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


1.2. Уровень транзакционных систем.

К числу транзакционных относятся ERP-системы, автоматизированные банковские системы (АБС), биллинговые системы, учетные системы и некоторые другие. Часто для обозначения таких систем используется термин OLTP (On-Line Transaction Processing – обработка транзакций в режиме реального времени). Эти системы представляют собой источники первичной информации, используемой для аналитической обработки. Данные из этих источников требуется собрать, структурировать и представить в виде, удобном для принятия решений. Сами транзакционные системы тоже содержат некоторые аналитические возможности, но, строго говоря, не относятся к категории аналитических систем. В то же время именно они являются поставщиками информации для систем бизнес-интеллекта и аналитических приложений.

Передача данных из транзакционных систем в аналитические приложения может производиться как последовательно, через все обозначенные ярусы аналитической пирамиды (хранилища данных, OLAP-системы) так и более коротким путем, минуя один или несколько уровней (это отражено на схеме в виде стрелочки bypass – «прямая передача»). Способ передачи данных зависит как от технических возможностей программных продуктов, так и от того, каким образом предполагается использовать те или иные данные.

1.3. Уровень систем бизнес-интеллекта.

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

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

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

Английское слово «Intelligence» означает способность узнавать и понимать, готовность к пониманию, знания, переданные или приобретенные путем обучения, исследования или опыта, действие или состояние в процессе познания, разведку, разведывательные данные.

В русском языке слово «интеллект» означает мыслительную способность человека.

Термин «Business Intelligence» получил широкое распространение, когда был введен в обращение аналитиками компании Gartner Group в конце 80-х годов прошлого века как «пользователецентрический процесс, включающий доступ и исследование информации, ее анализ, выработку интуиции и понимания, которые ведут к улучшенному и неформальному принятию решений». Хотя ранее этот термин, например, использовался в компании IBM в качестве внутрикорпоративного термина.

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

В русскоязычной литературе термин «Business Intelligence» переводится как «бизнес-интеллект», «интеллектуальный анализ данных», «деловая осведомленность» или вводится просто как аббревиатура BI.

Понятие систем бизнес-интеллекта ( B usiness I ntelligence, BI ) объединяет различные средства и технологии анализа и обработки данных масштаба предприятия.

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

1) Хранилища данных ( D ata W arehouse s ) находятся на следующем, после транзакционных систем, уровне аналитической пирамиды.

Концепция хранилища данных подробно нами рассмотрена на лекции 1 «Технологии хранилища данных». Напомним, что один из авторитетных специалистов в этой области – Билл Инмон – определяет хранилища как «предметно-ориентированные, интегрированные, стабильные, поддерживающие хронологию наборы данных, организованные для целей поддержки управления, призванные выступать в роли «единого и единственного источника истины», обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений». [ см .: Inmon W.H. SAP and Data Warehousing. — Kiva Productions Speakers Bureau, 1999.].

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

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

Построение хранилища данных — достаточно сложный проект, и обеспечить его окупаемость в краткосрочной перспективе бывает непросто.

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

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

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

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

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

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

Именно для этого предназначены специальные системы аналитической обработки данных в режиме реального времени — ОLAP-системы.

2) Витрины данных ( Da ta M arts) , как и хранилища, представляет собой структурированные информационные массивы, но отличие состоит в том, что витрины в еще большей степени являются предметно-ориентированными. Как правило, витрина содержит информацию, относящуюся к какому-либо определенному направлению деятельности организации. Поэтому информация в витрине данных хранится в специальном виде, наиболее подходящем для решения конкретных аналитических задач или обработки запросов определенной группы аналитиков.

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

3) Следующий уровень пирамиды – OLAP- системы (On-Line Analytical Processing). Под термином OLAP, как правило, понимают системы аналитической обработки данных в режиме реального времени. OLAP-системы могут обеспечить решение многих аналитических задач: анализ ключевых показателей деятельности, маркетинговый и финансово-экономический анализ, анализ сценариев, моделирование, прогнозирование и т.д. Такие системы могут работать со всеми необходимыми данными, независимо от особенностей информационной инфраструктуры компании.

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

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

Правила и особенности OLAP -систем мы подробно рассмотрели на лекции 3, посвященной технологии OLAP . Разобравшись в том, что такое OLAP и каковы его свойства, перейдем к самому, пожалуй, важному вопросу: для кого предназначены программные продукты этого класса?

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

Таким образом, OLAP-системы занимают в информационной инфраструктуре компании вполне определенное место.

Часто возникает вопрос: чем, с точки зрения пользователя-аналитика, OLAP-система отличается от хранилища данных?

Можно сказать, что главное, с точки зрения пользователя, отличие OLAP состоит в структурированности информации в соответствии с ее предметной (именно предметной, а не технической) сущностью. Работая с OLAP-приложением, аналитик использует привычные финансово-экономические термины, категории и показатели (виды материалов и готовой продукции, регионы продаж, объем реализации, себестоимость, прибыль и т.п.); а для того чтобы сформировать любой, даже довольно сложный запрос, ему не придется изучать язык SQL. И при этом ответ на запрос будет получен в течение всего нескольких секунд. Кроме того, работая с OLAP-системой, экономист может пользоваться такими привычными для себя инструментами, как электронные таблицы, или специальными средствами построения отчетов.

Если хранилище данных — это в основном объект внимания I Т-службы, то OLAP — это инструмент «предметных» специалистов-аналитиков.

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

O LAP – инструмент универсальный. Но в то же время именно универсальность делает его не вполне подходящим для специфических финансово-экономических задач, требующих применения специальных методик и организационных принципов. Поэтому OLAP-приложения не могут служить полноценной альтернативой специализированным аналитическим приложениям, например системам бюджетирования или консолидации финансовой отчетности. Здесь нет никакого противоречия: программный продукт, реализующий общие принципы экономического анализа, вряд ли может претендовать на решение абсолютно всех частных задач. Но, с другой стороны, именно сочетание OLAP и специализированных систем дает экономисту наибольшие преимущества, так как в этом случае специальные функции, методы и алгоритмы успешно сочетаются с универсальностью аналитической обработки данных.

Именно поэтому OLAP-средства часто используются клиентскими аналитическими приложениями для многомерного хранения данных.

Здесь пользователь применяет привычные для него инструменты для реализации определенных управленческих методик, но при этом данные для обработки и анализа хранятся на OLAP-севере.

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

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

4) Еще одним элементом BI-платформы, который часто выделяют в отдельную категорию, являются средства добычи знаний ( D ata M ining). Соответствующие программные продукты обеспечивают выявление закономерностей в данных, позволяя аналитику получать качественно новую информацию (возможно, не содержащуюся в источнике данных явным образом), и таким образом, формировать знания на основе данных.

Г. Пиатецкий-Шапиро (G. Piatetsky-Shapiro), один из ведущих мировых экспертов в этой области, определяет DATA MINING как «процесс обнаружения в сырых данных ранее неизвестных нетривиальных практически полезных и доступных интерпретации знаний, необходимых для принятия решений в различных сферах человеческой деятельности» [см.: Piatetsky — Shapiro G ., Frawley W . J ., editors . Knowledge Discovery in Databases . – MIT Press , 1991.].

Здесь используются такие методы анализа данных, как фильтрация, дерево решений, ассоциативные правила, генетические алгоритмы, нейронные сети, статистический анализ. Подробно модели и методы D ata M ining мы рассмотрим на лекции 7.

5) Наконец, следует упомянуть инструментарий выполнения запросов и построения отчетов ( query and reporting tools ). Такие системы обеспечивают функции построения запросов к информационно-аналитическим системам (в пользовательских терминах), интеграцию данных из нескольких источников, просмотр данных с возможностью детализации и обобщения, построение полноценных отчетов и их печать.

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

Как уже было отмечено, средства формирования запросов и построения отчетов (Query and Reporting too ls ) обеспечивают функции построения запросов к информационно-аналитическим системам, интеграцию данных из нескольких источников, просмотр данных с возможностью детализации и обобщения, построение и печать полноценных отчетов, в том числе презентационного качества. Некоторые из программных продуктов этого класса могут использоваться конечными пользователями, с минимальной поддержкой ИТ-департамента, другие же требуют определенного программирования и настраиваются техническими специалистами. С точки зрения конечного пользователя, это — удобный инструмент, позволяющий решить уже упоминавшуюся проблему, с которой так часто сталкиваются менеджеры и предметные специалисты — проблему «единого взгляда на управленческую информацию». Напомним, что эта проблема состоит в том, что очень часто управленческая информация, необходимая для анализа и принятия решений, хранится в разных источниках — учетных системах, ERP-системах, базах данных и т.п. Это крайне затрудняет получение нужной информации и ее представление в удобном для пользователя виде: специалисты вынуждены тратить время на рутинные процедуры сбора данных и их обработки, причем с риском искажения. Управленческая информация, полученная таким путем, часто не соответствует требованиям достоверности и актуальности, что снижает ее ценность. В этом плане BI-решения позволяют существенно упростить и ускорить сбор информации, унифицировать ее и представить в удобной и наглядной форме. Такая информация — надежная база для принятия управленческих решений, при этом рутинные процедуры сводятся к минимуму, а время специалистов высвобождается для решения аналитических задач.

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

Таким образом, сегодня принято говорить о целом комплексе средств, которые в совокупности называют системами бизнес-интеллекта ( Business Intelligence , В I ).

Типичными представителями BI -систем являются программные продукты корпорации Oracle (источник – официальный сайт корпорации http://www.oracle.com/ru.).

Семейство решений Oracle Business Intelligence (дата последнего релиза: май 2014 года) – это интегрированный комплекс аналитических инструментов, который разработан с целью обеспечить лучшее видение и понимание бизнеса широкому кругу пользователей и позволяет любому пользователю организации получить быстрый Web-доступ к актуальной информации.

Особенности решения Oracle Business Intelligence.

Линейка программных продуктов Oracle Business Intelligence Suite Enterprise Edition ( Oracle BI Suite EE) является одной из самых мощных и наиболее динамично развивающихся платформ бизнес — анализа в мире . С внедрением Oracle BI Suite EE компании приобретают возможность получать полное, а главное своевременное представление о состоянии своего бизнеса, не прибегая к помощи ИТ-службы.

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

Архитектура Oracle Business Intelligence .

В центре системы находится единая модель данных (также называемая репозиторием). Модель состоит из трех слоев — презентационного, бизнес и физического.

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

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

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

Мастер Йода рекомендует:  Как правильно подобрать ключевые слова для SEO

Когда пользователь открывает отчет, сервер презентаций (Presentation Server) генерирует запрос на языке Logical SQL к серверу BI. Сервер BI разбирает запрос, и переводит его в запросы к источникам данных на их «родных» языках — sql, mdx и т.п. После получения данных от источников сервер объединяет их, проводит различные действия над данными (например, вычисляет агрегаты, если это необходимо), и возвращает результат серверу презентаций. Сервер презентаций, в свою очередь, отрисовывает полученные данные в Web -интерфейсе или генерирует статичный отчет.

Oracle Business Intelligence Foundation Suite 11.1.1.8.1 ( май 2014).

В мае 2014 года корпорация Oracle анонсировала обновление версии готовых решений для бизнес-анализа Oracle Business Intelligence (BI) Applications, которые призваны улучшить информационное представление организаций об эффективности бизнеса и повысить их гибкость и динамичность. Предлагая новые методы анализа данных о закупках, а также новый модуль для анализа данных о ценных сотрудниках, Oracle продолжает расширять возможности организаций по извлечению важной и полезной для бизнеса информации из широкого спектра источников данных и приложений. Кроме того, Oracle представила новый аналитический модуль Oracle Human Resources Analytics, предназначенный для формирования, развития и поддержки квалифицированного персонала.

Oracle BI Applications , построенные на технологической платформе для бизнес-анализа нового поколения Oracle Business Intelligence Foundation Suite, позволяют организациям с легкостью расширить корпоративную среду бизнес-анализа или создавать собственные BI-приложения для удовлетворения специфических аналитических потребностей менеджеров подразделений и высших руководителей.

Примеры практического использования BI -систем.

В качестве примера рассмотрим крупную производственную компанию.

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

В процессе внедрения BI-платформы была поставлена задача сбора и согласования финансовой и нефинансовой информации со всех предприятий компании, а также предоставления всей отчетной информации в едином стандарте с использованием большого числа разрезов аналитики.

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

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

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

2. Межбанковская система ипотечного кредитования .

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

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

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

Таким образом, распределенная информационная система ипотечного кредитования должна позволять решать следующие задачи:

— ввод исходных данных с бумажных носителей посредством сканирования договоров или вручную;

— учет выделенных кредитов и расчетов по ним;

— хранение всей информации в централизованном хранилище данных (ЦХД);

— интеграция с существующими в банках автоматизированными банковскими системами (АБС) и организация обмена данными с ЦХД (экспорт и импорт данных);

— анализ данных, хранящихся в ЦХД;

— формирование отчетов и представление их банкам-операторам.

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

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

Рисунок 2. Основные элементы распределенной информационной системы ипотечного кредитования.

Как видно из схемы, основными элементами системы являются:

1) реляционное хранилище данных (реализуется, например, на платформе MS SQL Server, с использованием набора хранимых процедур);

2) многомерное хранилище данных (OLAP-сервер и необходимые компоненты);

3) средства построения запросов, анализа данных, формирования отчетности и ее регламентированной доставки;

4) сервер приложений.

Рабочие места администраторов и пользователей системы:

  1. Рабочее место администратора реляционного хранилища (функции: генерация сертификатов и назначение прав доступа, регламентированные операции, контроль процессов, обновление версий программного обеспечения на клиентских местах);
  2. Рабочее место администратора многомерного хранилища данных и средств запросов и отчетности (функции: ввод и редактирование описаний пользователей, распределение прав доступа, выполнение регламентированных операций, контроль процессов);
  3. Рабочее место оператора по вводу данных (функции: обмен данными с автоматизированной банковской системой, ввод данных с бумажных носителей, экспорт и импорт данных). При этом рабочее место предусматривает возможность ввода и модификации данных даже в случае отсутствия связи с центральным сервером, путем ввода данных в локальном режиме и последующей синхронизации с центральным хранилищем;
  4. Рабочее место оператора по учету кредитов и расчетам. Рабочее место также предусматривает возможность работы в локальном режиме, с последующей синхронизацией с центральным хранилищем;
  5. Рабочее место аналитика (функции: построение различных аналитических отчетов).

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

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

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

  1. СИСТЕМЫ БИЗНЕС-АНАЛИТИКИ. СИСТЕМЫ УПРАВЛЕНИЯ ЭФФЕКТИВНОСТЬЮ БИЗНЕСА (BUSINESS PERFORMANCE MANAGEMENT, BPM ).

2.1. Уровень аналитических приложений.

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

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

Для того чтобы система могла считаться аналитическим приложением, она должна удовлетворять следующим критериям:

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

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

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

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

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

С ПРЕДМЕТНОЙ ТОЧКИ ЗРЕНИЯ, МОЖНО ВЫДЕЛИТЬ ТРИ ОСНОВНЫЕ КАТЕГОРИИ АНАЛИТИЧЕСКИХ ПРИЛОЖЕНИЙ:

1. Системы управления эффективностью бизнеса ( Business Performance Management);

2. Приложения для анализа операционной/производственной деятельности ( Operations/Production Analysis);

3. Системы анализа взаимоотношений с клиентами ( CRM Analysis).

2.2. Концепция Business Performance Management (BPM).

Сложившиеся в начале XXI века реалии управления крупными предприятиями предполагают, что применяемые инструментальные средства учитывают современные тенденции развития бизнеса. Глобализация, лавинообразный рост объема информации и обострение конкуренции заставляют компании выявлять и задействовать все возможные резервы. При этом необходимо, чтобы управление основывалось на оперативных и достоверных результатах комплексного анализа данных. Именно для этого разработан особый класс информационных систем — Business Performance Management.

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

Системы класса Business Performance Management ( BPM ) предназначены для широкого круга задач: анализа и оптимизации финансовых индикаторов, определения стратегии развития компании, бюджетного планирования, финансовой консолидации.

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

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

Приложения для анализа операционной и производственной деятельности (Operations/Production Analysis) предназначены для анализа и оптимизации процессов производства и/или поставок продукции и услуг (например, планирование спроса, оптимизация работы персонала).

Системы анализа взаимоотношений с клиентами (CRM Analysis) предназначены для решения таких задач, как, например, оценка прибыльности клиентов, разработка мер, направленных на «удержание» заказчиков, маркетинговый анализ. Специализированные аналитические приложения анализа клиентской базы изначально использовались в качестве основы для деятельности в маркетинговых подразделениях компаний, но сейчас они становятся многофункциональными.

Очень важно не путать аналитические приложения с системами бизнес-интеллекта: их функциональность существенно отличается от BI-систем в трех аспектах – в предметной специализации, в сегментации рынка и в структуре.

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

С точки зрения сегментации , рынок аналитических приложений может быть структурирован в зависимости от вида бизнес-процессов (например, маркетинг, операционное планирование, бюджетирование, консолидация финансовой отчетности), в то время как рынок средств BI может быть сегментирован в зависимости от типа архитектуры каждой из систем (например, системы Data Mining или OLAP).

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

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

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

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

Термин ETL был введен в лекции 1 «Технологии хранилищ данных». Напомним, что под термином ETL ( extraction , transformation , loading – извлечение, преобразование, загрузка) понимают три основных процесса, используемые при переносе данных из одной системы в другую. Программные средства этой категории извлекают исходную информацию из определенного источника, преобразуют ее в формат, поддерживаемый базой данных назначения, а затем загружают в базу назначения уже преобразованную информацию.

В части извлечения данных (extraction) ETL-системы могут использоваться без необходимости писать код для открытия файлов или чтения записей, хотя и требуют весьма трудоемкой настройки. Более того, некоторые ETL-системы включают в себя предварительно созданные процедуры извлечения данных из наиболее популярных транзакционных систем.

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

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

Проблемы и этапы очистки данных мы подробно рассмотрели на лекции 1 «Технологии хранилищ данных».

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

Перевод значений (value translation) — еще одна распространенная процедура преобразования, ее необходимость вызвана тем, что во многих системах данные часто хранятся в закодированном виде. Перевод значений предусматривает замену закодированных данных на более понятные описания, такие преобразования производятся на основе нормативно-справочной информации.

Создание полей (field derivation) применяется в том случае, если для конечных пользователей создается какая-либо новая информация. Например, если в исходной базе данных есть поле цены товара и поле объема продаж, то на их основе можно создать третье поле – выручка от реализации. Современные ETL-системы позволяют программистам использовать для создания новых полей математические операции, статистические функции, возможности работы со строками, арифметические действия и условную логику.

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

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

Большинство современных ETL-систем поддерживают и постоянную, и периодическую загрузку данных. Некоторые продукты также позволяют переносить не все данные, а только те, которые претерпели изменения.

При загрузке применяются разные схемы: при pull-тиражировании приложение назначения «вытягивает» данные по мере необходимости, а при push-тиражировании система «проталкивает» преобразованные данные в базу данных назначения.

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

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

  1. ЭФФЕКТИВНОСТЬ АНАЛИТИЧЕСКИХ СИСТЕМ.

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

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

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

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

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

— противодействие нерациональным решениям. Оптимизация процесса принятия некоторых управленческих решений также требует адекватной реакции специалистов на нерациональные действия. Это учитывается также разработчиками аналитических систем.

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

3.1. Информационная безопасность BI -систем и аналитических приложений (analytic applications).

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

Необходимость безопасности систем оперативной обработки транзакций (On-Line Transaction Processing, OLTP) осознается большинством компаний. Особенность реализации этой задачи для OLTP-приложений заключается в том, что OLTP -системы хорошо поддаются структуризации и являются статичными (определенные приложения каждый раз одинаковым образом обращаются к определенным данным). Круг пользователей весьма ограничен — это работники с определенными бизнес-функциями, они работают с приложениями и данными, которые касаются только их поля деятельности. Кроме того, физическая структура этих приложений также остается довольно постоянной. Инструментальные средства и базовая структура данных меняются нечасто.

Среда бизнес-аналитики и ХД, наоборот, характеризуется значительной динамичностью вкупе с широкой и часто меняющейся пользовательской аудиторией, причем пользователи могут быть как внутренними, так внешними. В такой ситуации гораздо сложнее (а иногда и практически невозможно) распределить пользователей по подмножествам данных; особенно это касается аналитических приложений высокого уровня, таких как, например, решения управления эффективностью корпорации ( corporate performance management), где окончательная информация формируется на основе изучения данных всего предприятия. Помимо этого, физическая структура этой среды часто является неясной: в нее устанавливается множество различных средств, а сами данные пребывают в постоянном движении (из ХД в витрины данных и на пользовательские машины в информационные панели). В результате мероприятия по обеспечению безопасности корпоративной информации обходят стороной приложения бизнес-аналитики и ХД.

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

1. Безопасность данных.

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

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

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

— Кто располагает доступом к ХД, витрине данных, OLAP -кубам и т.д.?

— Каковы рамки их доступа: одна предметная область, множество предметных областей или все предметные области?

— Каким типом доступа они обладают, например, только чтение или возможность модификации?

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

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

— Насколько распределенной является архитектура данных, поддерживающая бизнес-аналитику?

— Имеется ли дополнительное распределение данных и если да, то каковы связанные с ним риски?

— Что делают пользователи с загружаемыми данными?

— Передают ли пользователи данные внешним партнерам?

2. Процесс сбора данных.

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

— Кто располагает доступом к средствам извлечения данных из операционных систем?

— Где находятся данные, пребывающие в процессе сбора, перед тем как оказаться в ХД, и кто имеется доступ к этой области?

— Какова логика преобразования, безопасность которой реализуется в средствах извлечения, преобразования и загрузки (ETL)?

— Если никакие средства не используются, то какова защита ETL-процессов, написанных пользователем, от несанкционированных модификаций?

3. Пользовательские средства формирования запросов и аналитические приложения.

Программные инструменты BI -систем и аналитические приложения — это, в первую очередь, механизмы, предназначенные для доступа к данным в ХД. Такие средства часто приобретались в большом количестве с целью широкого и глубокого развертывания бизнес-аналитики по всему предприятию. Эти инструменты представляют особую ценность только для определенных пользователей и несут серьезную опасность, если попадают не в те руки.

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

— Кто располагает разрешением на использование средств формирования запроса и отчетности?

— Назначен ли каждому пользователю личный ID?

Появление и развитие аналитических приложений для электронной коммерции по схеме «бизнес-бизнес» (business-to-business) и «поставщик-покупатели» (business-to-consumer) усилили насущность вопросов безопасности. Поэтому актуальными являются следующие вопросы.

— Насколько свободно ваши клиенты и поставщики обмениваются предоставленной им информацией в рамках своих предприятий?

— Предоставляют ли они ее своим внешним акционерам?

— Не может ли эта информация попасть в руки ваших конкурентов?

4. Политика информационной безопасности.

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

Поэтому при формировании корпоративной политики информационной безопасности необходимо рассмотреть следующие вопросы:

1) Учитывает ли корпоративная политика безопасности специфику ИT?

2) Имеются ли области значительного риска, которые могут быть устранены посредством такой политики?

3) Затрагивают ли правительственные постановления информацию, которая хранится, анализируется и представляется среде бизнес-аналитики?

4) Не нарушают ли текущие или планируемые мероприятия по развертыванию среды бизнес-аналитики эти постановления?

СПИСОК РЕКОМЕНДОВАННОЙ ЛИТЕРАТУРЫ.

[1] Барсегян А. А., Куприянов М. С. , Степаненко В. В., Холод И. И. Методы и модели анализа данных: OLAP и Data Mining. – СПб.: БХВ-Петербург, 2004. — 336 с.

[2] Духонин Е.Ю., Исаев Д.В., Мостовой Е.Л. и др. Управление эффективностью бизнеса. Концепция Business Performance Management . Под. Ред. Генса Г.В. М.: Альпина Бизнес Букс, 2005. – 269 с.

[3] Исаев Д.В., Кравченко Т.К. Информационные технологии управленческого учета. М., ГУ-ВШЭ, 2006. – 297 с.

[4] Туманов В.Е. Проектирование хранилищ данных для систем бизнес-аналитики: учебное пособие. – М.:Интернет-Университет Информационных технологий: Бином. Лаборатория знаний, 2010. – 615 с.

[5] Фоменко Е.Ю. Хранилища данных. Анализ данных: Курс лекций. — М.: Ф-т ВМиК МГУ им. М.В. Ломоносова, 2007.

Добавить комментарий