Информационные технологии в профессиональной деятельности экономиста: Обзор ИТ, предназначенных для оперативной и аналитической обработки данных. Open Library - открытая библиотека учебной информации

Знаете ли Вы, в чем ложность понятия "физический вакуум"?

Физический вакуум - понятие релятивистской квантовой физики, под ним там понимают низшее (основное) энергетическое состояние квантованного поля, обладающее нулевыми импульсом, моментом импульса и другими квантовыми числами. Физическим вакуумом релятивистские теоретики называют полностью лишённое вещества пространство, заполненное неизмеряемым, а значит, лишь воображаемым полем. Такое состояние по мнению релятивистов не является абсолютной пустотой, но пространством, заполненным некими фантомными (виртуальными) частицами. Релятивистская квантовая теория поля утверждает, что, в согласии с принципом неопределённости Гейзенберга, в физическом вакууме постоянно рождаются и исчезают виртуальные, то есть кажущиеся (кому кажущиеся?), частицы: происходят так называемые нулевые колебания полей. Виртуальные частицы физического вакуума, а следовательно, он сам, по определению не имеют системы отсчета, так как в противном случае нарушался бы принцип относительности Эйнштейна, на котором основывается теория относительности (то есть стала бы возможной абсолютная система измерения с отсчетом от частиц физического вакуума, что в свою очередь однозначно опровергло бы принцип относительности, на котором постороена СТО). Таким образом, физический вакуум и его частицы не есть элементы физического мира, но лишь элементы теории относительности, которые существуют не в реальном мире, но лишь в релятивистских формулах, нарушая при этом принцип причинности (возникают и исчезают беспричинно), принцип объективности (виртуальные частицы можно считать в зависимсоти от желания теоретика либо существующими, либо не существующими), принцип фактической измеримости (не наблюдаемы, не имеют своей ИСО).

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

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

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

Вопросы к госэкзамену

Жизненный цикл КИС. Этапы жизненного цикла КИС

Модели жизненного цикла КИС (бизнес-приложений)

Технологические процессы создания КИС

CASE-средства поддержки жизненного цикла КИС

Методы и средства структурного системного анализа и проектирования

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

Корпоративные информационные системы. Их структура. Примеры КИС

Информационная архитектура КИС. Назначение и состав. Методы и средства описания архитектуры данных

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

Архитектурные шаблоны (OLTP, OLAP – системы) в информационной архитектуре предприятия

OLAP-системы

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) - технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Реализации технологии OLAP являются компонентами программных решений класса Business Intelligence.

Основоположник термина OLAP - Эдгар Кодд, предложил в 1993 году «12 законов аналитической обработки в реальном времени».

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

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

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

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

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

Разработка каждого отчёта требует работы программиста.

Отчёты формируются очень медленно (зачастую несколько часов), замедляя при этом работу всей информационной системы.

Данные, получаемые от различных структурных элементов компании не унифицированы и часто противоречивы.

OLAP-системы, самой идеологией своего построения предназначены для анализа больших объёмов информации, позволяют преодолеть ограничения традиционных информационных систем.

Создание OLAP-системы на предприятии позволит:

Интегрировать данные различных информационных систем, создав единую версию правды

Проектировать новые отчеты несколькими щелчками мыши без участия программистов.

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

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

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

Итоги внедрения OLAP-системы

Руководство получает полное ясное видение ситуации и единый механизм учёта, контроля и анализа.

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

Действие OLAP

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

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

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, 3 группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.

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

Вместе с базовой концепцией существуют три типа OLAP:

OLAP со многими измерениями (Multidimensional OLAP - MOLAP);

реляционный OLAP (Relational OLAP - ROLAP);

гибридный OLAP (Hybrid OLAP - HOLAP).

MOLAP - это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов.

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

HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.

Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP - R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

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

Реализации OLAP

Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией считается система Express, разработанная в 1970 году компанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database). Термин OLAP ввёл Эдгар Кодд в публикации в журнале Computerworld в 1993 году, в которой он предложил 12 принципов аналитической обработки, по аналогии с 12 правилами для реляционных баз данных, сформулированными им же десятилетием ранее, в качестве референтного продукта, удовлетворяющего предложенным принципам, Кодд указал систему Essbase компании Arbor (поглощённой в 1997 году компанией Hyperion, которую, в свою очередь, в 2007 году купила Oracle). Примечательно, что впоследствии публикация была изъята из архивов Computerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor.

Другие известные OLAP-продукты: Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), SAS OLAP Server, TM1, PowerPlay, SAP BW, MicroStrategy Ingelligence Server, Mondrian, Аналитический комплекс ПРОГНОЗ.

C точки зрения реализации делятся на «физический OLAP» и «виртуальный» (реляционный, англ. Relational OLAP, ROLAP). «Физический», в свою очередь, в зависимости от реализации подразделяется на многомерный (англ. Multidimensional OLAP, MOLAP) и гибридный - (англ. Hybrid OLAP, HOLAP).

В первом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную базу данных, обеспечивающую быстрое извлечение и экономичное хранение. Примеры таких продуктов - Microsoft Analysis Services, Oracle OLAP Option, Essbase, SAS OLAP Server, TM1, PowerPlay.

Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной базе данных, а агрегаты - в многомерной.

В ROLAP-реализациях все данные хранятся и обрабатываются реляционных системах управления базами данных, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов - SAP BW, Microstrategy Intelligence Server, Mondrian.

С точки зрения пользователя все варианты выглядят похожими по возможностям. Наибольшее применение OLAP находит в продуктах для финансового планирования, хранилищах данных, решениях класса Business Intelligence.

OL T P-системы (Системы оперативной обработки транзакций)

OLTP (Online Transaction Processing), транзакционная система - обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.

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

Проблема целостности – в обеспечении правильности данных БД в любой момент времени. Она может быть нарушена в след случаях: 1. при вводе и обновлении, когда подаются неверные сведения. 2. когда данным пользуются одновременно несколько userов. 3. при сбоях АПС.

Решение проблем целостности надо рассматривать с программной и организационной точки зрения. Для ПОбл 1. надо ряд организац мероприятий (чтобы следили за вводом), user должен знать правила ввода и ограничения. Для проблем 2-3 – стандартные средства СУБД или спец программные модули. СУБД – 2 основных ограничения целостности: 1. структурные ограничения (задаются функциональными связями и проверяются путем проверки равенства значений БД) 2. ограничения реальных значений. Требуют, чтобы значения поля принадлежали некоторому диапазону, либо это зависимость между значениями некоторых полей. (типы данных и маски ввода). Ограничения могут задаваться АБД в любой момент, но СУБД может не принять ограничение (если много записей ему уже не удовлетворяют), если соответствие есть – записывается в словарь и используется. Ограничения различаются по уровню сложности:

2. ограничения на совокупность атрибутов строки. (должность – разрядные ставки, края – города).

3. ограничения одновременно на множество строк.

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

Должна обладать 4 свойствами: 1. Атомарность (неделимость): выполняется как одинарная операция доступа к БД, должна выполняться полностью или не выполняться совсем. 2. Согласованность – гарантирует взаимную целостность данных после окончания обработки транзакций. 3. Изолированность (каждая транзакция может изменять данное, которое временно находится в несогласованном состоянии). При этом доступ других транзакций к этим данным запрещен, пока транзакция не завершится. 4. долговечности – если транзакция выполнена успешно, то изменения не будут потеряны. Результатом выполнения транзакции может быть её фиксация (действие по фиксации изменений в БД) или откат (отмена транзакции и возврат БД в состояние до начала её). Механизм фиксации и откат основан на использовании журнала транзакций, где сохраняется состояние ДО (в нескольких итерациях) и ПОСЛЕ. Некоторые диалекты SQL включают операторы промежуточной фиксации (откат от точки к точке).

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

На современном рынке мониторов транзакций основными "действующими лицами" являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), TUXEDO Sytem (Novell).

Совместное использование данных

При реализации транзакций возникает проблема: потеря обновлений (в БД фиксируется только изменения одного userа, остальные теряются). И 2 проблема – чтение незафиксированных данных. Для решения - спец механизмы обработки транзакций. Принципы: 1. транзакция не имеет доступа к незафиксированным данным. 2. результат совместного выполнения транзакций эквивалентен их последнему выполнению. Реализуется этот механизм через систему блокировок: СУБД блокирует часть БД, к которой обращается транзакция до момента её фиксации, т.е. 2-ю транзакцию надо поставить в очередь ожидания. Чем больше блокируемый элемент, тем медленнее обрабатывается транзакция. В системах OLTP обычно блокируется строка, при этом транзакции могут попадать в ситуацию взаимной блокировки. Для предотвращения СУБД периодически опрашивает блокировки и если такое есть, одна из транзакций прерывается. Для более удобной работы допускаются блокировки совместного использования данных: параллельно работающим userам запрещается изменять данные, но разрешается выборка их. Этот подход не единственный, можно, например использовать тиражирование данных в системах с распред доступом. Эта технология предполагает отказ от распределенности данных, и в каждом узле – своя копия БД. Средства, обеспечивающие это должны поддерживать согласованное состояние БД копированием изменений. Процесс переноса изменений исходной БД в БД отдельных узлов называется тиражированием данных. Эти функции выполняет определенный модуль (сервер тираж-я/ репликатор). Схема его работы – полное обновление содержимого БД на удаленных серверах (схема с полн обновлением) или обновление только изменяющихся данных (схема с быстрым обновлением) Если нет необходимости постоянно обновлять данные, то репликатор накапливает изменения и копир-т их в нужный момент.

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

Современные технологии БД предъявляют определенные требования в области архитектуры. До недавнего времени выделялось три класса задач:

задачи оперативной обработки транзакций;

задачи пакетной обработки;

задачи принятия решений.

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

Системы OLTP характеризуются:

поддержкой большого числа users;

малым временем отклика на запрос;

относительно короткими запросами;

короткими транзакциями;

участие в запросах небольшого числа таблиц.

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

Сервер оперативной обработки транзакций строится в предположении:

OLTP- операции поддерживают большое число user;

наиболее часто используются короткие простые транзакции;

обычно транзакции не использую одинаковые данные;

операторы обычно затрагивают небольшое число строк;

время отклика - доли секунды;

только несколько таблиц имеют большие размеры или могут быть изменены.

Реализация такого сервера опирается на:

физические методики сокращений операций с дисками;

обработку небольших объемов данных в памяти;

примитивный оптимизатор запросов;

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

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

Data Mining переводится как "добыча" или "раскопка данных". Нередко рядом с Data Mining встречаются слова "обнаружение знаний в базах данных" (knowledge discovery in databases) и "интеллектуальный анализ данных". Их можно считать синонимами Data Mining. Возникновение всех указанных терминов связано с новым витком в развитии средств и методов обработки данных.

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

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

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

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

Данные имеют неограниченный объем

Данные являются разнородными (количественными, качественными, текстовыми)

Результаты должны быть конкретны и понятны

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

Традиционная математическая статистика, долгое время претендовавшая на роль основного инструмента анализа данных, откровенно спасовала перед лицом возникших проблем. Главная причина - концепция усреднения по выборке, приводящая к операциям над фиктивными величинами (типа средней температуры пациентов по больнице, средней высоты дома на улице, состоящей из дворцов и лачуг и т.п.). Методы математической статистики оказались полезными главным образом для проверки заранее сформулированных гипотез (verification-driven data mining) и для “грубого” разведочного анализа, составляющего основу оперативной аналитической обработки данных (online analytical processing, OLAP).

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

Важное положение Data Mining - нетривиальность разыскиваемых шаблонов. Это означает, что найденные шаблоны должны отражать неочевидные, неожиданные (unexpected) регулярности в данных, составляющие так называемые скрытые знания (hidden knowledge). К обществу пришло понимание, что сырые данные (raw data) содержат глубинный пласт знаний, при грамотной раскопке которого могут быть обнаружены настоящие самородки (рис.1).

Рисунок 1. Уровни знаний, извлекаемых из данных

В целом технологию Data Mining достаточно точно определяет Григорий Пиатецкий-Шапиро - один из основателей этого направления:

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

2. Кому это нужно?

Сфера применения Data Mining ничем не ограничена - она везде, где имеются какие-либо данные. Но в первую очередь методы Data Mining сегодня, мягко говоря, заинтриговали коммерческие предприятия, развертывающие проекты на основе информационных хранилищ данных (Data Warehousing). Опыт многих таких предприятий показывает, что отдача от использования Data Mining может достигать 1000%. Например, известны сообщения об экономическом эффекте, в 10–70 раз превысившем первоначальные затраты от 350 до 750 тыс. дол. . Известны сведения о проекте в 20 млн. дол., который окупился всего за 4 месяца. Другой пример - годовая экономия 700 тыс. дол. за счет внедрения Data Mining в сети универсамов в Великобритании.

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

ИЛИ

Что такое Data Mining

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

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

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

OLTP и OLAP-системы. Data Mining

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

Сильно нормализованные модели данных хорошо подходят для так называемых OLTP-систем (On-Line Transaction Processing - оперативная обработка транзакций ).

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

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

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

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

Другим типом информационных систем являются так называемые OLAP-системы (On-Line Analitical Processing - оперативная аналитическая обработка данных ). OLAP используется для принятия управленческих решений, поэтому системы, использующие технологию OLAP, называют системами поддержки принятия решений (Decision Support System - DSS ).

Концепция OLAP была описана в 1993 году Эдгаром Коддом, автором реляционной модели данных.

В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

· предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;

· возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;

· многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

· многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это - ключевое требование OLAP);

· возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

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

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

· Данные, добавленные в систему, обычно никогда не удаляются и не изменяются.

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

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

· Скорость выполнения запросов важна, но не критична.

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

В последнее время активно развивается еще одно направление аналитической обработки данных, получившее название Data Mining (осмысление данных, иногда говорят «раскопка данных» ). Это направление направлено на поиск скрытых закономерностей в данных и решение задач прогнозирования. Приложения DataMining также не изменяют данные, с которыми они работают, поэтому для них более предпочтительной является денормализованная база данных.

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

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

Сильно нормализованные модели данных хорошо подходят для OLTP-приложений – On-Line Transaction Processing (OLTP) – приложений оперативной обработки транзакций. Типичными примерами OLTP-приложений являются системы складского учета͵ заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически всœе запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединœения отношений и от скорости выполнения которых существенно зависит работа приложений.

Другим типом приложений являются OLAP-приложения – On-Line Analitical Processing (OLAP) – приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений – Decision Support System (DSS), хранилищ данных – Data Warehouse, систем интеллектуального анализа данных – Data Mining. Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу «что если…» и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками:

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

Данные, добавленные в систему, как правило, никогда не удаляются;

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

Запросы к системе являются нерегламентированными и достаточно сложными;

скорость выполнения запросов важна, но не критична.

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

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

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

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

Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit - двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

Пример: Необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:
Начать транзакцию
прочесть баланс на счету номер 5
уменьшить баланс на 10 денежных единиц
сохранить новый баланс счёта номер 5
прочесть баланс на счету номер 7
увеличить баланс на 10 денежных единиц
сохранить новый баланс счёта номер 7

Окончить транзакцию
Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

Режим оперативной обработки транзакций OLTP

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

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

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

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

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

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

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

Исторически такие системы возникли в первую очередь, поскольку реализовывали потребности в учете, скорости обслуживания, сборе данных и пр. Однако вскоре пришло понимание, что сбор данных - не самоцель и накопленные данные могут быть полезны: из данных можно извлечь информацию.
Стратегия разработки систем
Длительное время в качестве стратегии разработки подобных систем использовалось следующее:
построение отдельных АРМ, предназначенных для обработки групп функционально связанных документов, и тиражирование готовых АРМ на места,
построение полнофункциональных параметризуемых систем с тиражированием и настройкой по местам. Однако получаемые таким способом системы имели невысокие адаптационные возможности по преодолению динамики предметных областей. Они предъявляли высокие требования к эксплуатационному персоналу и требовали больших накладных расходов на сопровождение.
Относительно недавно начала применяться новая, третья стратегия разработки информационных систем класса OLTP. Ее суть состоит в следующем: тиражируются не готовые системы, а некоторые заготовки и технологический инструмент, позволяющие непосредственно на месте быстро построить/достроить систему с необходимой функциональностью и далее с помощью этого же инструмента ее модифицировать в соответствии с динамикой предметной области.

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

OLTP-технологии

В практике общения с представителями информационных служб предприятий нередко приходится сталкиваться с серьезным недопониманием различий в возможностях, назначении и роли технологий, предназначенных для сбора информации, - OLTP-систем (On-Line Transaction Processing) и технологий анализа информации. Между тем они существенно различны по функциональности, и каждая из них отвечает за свою область в информационной системе.
Задачи OLTP-системы – это быстрый сбор и наиболее оптимальное размещение информации в базе данных, а также обеспечение ее полноты, актуальности и согласованности. Однако такие системы не предназначены для максимально эффективного, быстрого и многоаспектного анализа.
Разумеется, по собранным данным можно строить отчеты, но это требует от бизнес-аналитика или постоянного взаимодействия с IT-специалистом, или специальной подготовки в области программирования и вычислительной техники.
Как выглядит традиционный процесс принятия решений в российской компании, использующей информационную систему, построенную на OLTP-технологии?
Менеджер дает задание специалисту информационного отдела в соответствии со своим пониманием вопроса. Специалист информационного отдела, по-своему осознав задачу, строит запрос оперативной системе, получает электронный отчет и доводит его до сведения руководителя. Такая схема принятия критически важных решений обладает следующими существенными недостатками:
-используется ничтожное количество данных;
-процесс занимает длительное время, поскольку составление запросов и интерпретация электронного отчета – операции довольно канительные, тогда как руководителю, может быть, необходимо принять решение незамедлительно;
-требуется повторение цикла в случае необходимости уточнения данных или рассмотрения данных в другом разрезе, а также при возникновении дополнительных вопросов. Причем этот медленный цикл приходится повторять и, как правило, неоднократно, при этом времени на анализ данных тратится ещё больше;
негативным образом сказывается различие в профессиональной подготовке и областях деятельности специалиста по информационным технологиям и руководителя. Зачастую они мыслят разными категориями и, как следствие, не понимать друг друга;
неблагоприятное действие оказывает такой фактор, как сложность электронных отчетов для восприятия. У руководителя нет времени выбирать интересующие цифры из отчёта, тем более что их может оказаться слишком много. Понятно, что работа по подготовке данных чаще всего ложится на специалистов информационных отделов. В результате грамотный специалист отвлекается на рутинную и малоэффективную работу по составлению таблиц, диаграмм и т. д., что, естественно, не способствует повышению его квалификации.
Выход из этой ситуации один, и сформулирован он Биллом Гейтсом в виде выражения: "Информация на кончиках пальцев". Исходная информация должна быть доступна ее непосредственному потребителю – аналитику. Именно непосредственно доступна (!). А задачей сотрудников информационного отдела является создание системы сбора, накопления, хранения, защиты информации и обеспечения ее доступности аналитикам.

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

OLTP - системы , являясь высокоэффективным средством реализации оперативной обработки, оказались мало пригодны для задач аналитической обработки. Это вызвано следующим:
1. средствами традиционных OLTP -систем можно построить аналитический отчет и даже прогноз любой сложности, но заранее регламентированный. Любой шаг в сторону, любое нерегламентированное требование конечного пользователя, как правило, требует знаний о структуре данных и достаточно высокой квалификации программиста;
2. многие необходимые для оперативных систем функциональные возможности являются избыточными для аналитических задач и в то же время могут не отражать предметной области. Для решения большинства аналитических задач требуется использование внешних специализированных инструментальных сре дств дл я анализа, прогнозирования и моделирования. Жесткая же структура баз не позволяет достичь приемлемой производительности в случае сложных выборок и сортировок и, следовательно, требует больших временных затрат для организации шлюзов.
3. в отличие от транзакционных, в аналитических системах не требуются и, соответственно, не предусматриваются развитые средства обеспечения целостности данных, их резервирования и восстановления. Это позволяет не только упростить сами средства реализации, но и снизить внутренние накладные расходы и, следовательно, повысить производительность при выборке данных.

Круг задач, эффективно решаемых каждой из систем, определим на основе сравнительных характеристик OLTP - и OLAP –систем

Данные в OLTP-системах организованы главным образом для поддержки таких транзакций, как:

регистрация заказа, введенного с кассового терминала или через Web-узел;

размещение заказа на комплектующие изделия, когда их количество на складе становится меньше определенного числа;

отслеживание компонентов во время сборки конечного продукта на производстве;

регистрация сведений о работниках;

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

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

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

Современные задачи Хранилищ данных
Разделение данных с конкретными целями

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

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

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

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

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

Эти тенденции реализуются следующим образом:
Интеграция данных в реальном времени для Хранилища данных. Получение и передача данных в реальном времени из операционных систем в Хранилище, что делает данные доступными для анализа.
Активное Хранилище данных. ХД в реальном времени, дополняемое инструментами Business Intelligence для обработки и выполнения бизнес-решений. Решения автоматически передаются в OLTP-системы. В результате формируется замкнутый цикл обработки.

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

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

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

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

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

Другим подходом к интеграции данных в реальном времени является технология управления транзакционными данными (transactional data management - TDM), предназначенная для получения, передачи, преобразования, поставки и верификации транзакционных данных в гетерогенной среде в реальном времен.TDM функционирует на выполненных транзакциях: выбирает их из OLTP-системы, применяет основные методы преобразования и передает их в Хранилище. По своей архитектуре технология асинхронна, однако обеспечивает синхронное поведение, работает с задержкой в долю секунды, поддерживая целостность данных в транзакции.

EAI и TDM предназначены для передачи изменений и обновлений данных, а не целостных выборок данных. Ни то, ни другое не требует приостановки исходных систем, так как эти технологии поддерживают целостность операций языка манипулирования данными (data manipulation language - DML). За счет этого существенно сокращается объем необходимых перемещений данных. И если ETL-средства в основном предназначены для исходной загрузки и преобразования данных, то EAI и TDM больше подходят для постоянного сбора данных.

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

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

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

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

Сбор данных

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

Доставка данных

Все новые данные передаются в промежуточную область хранения ХД, при этом временная задержка составляет доли секунды. А значит, наиболее актуальные данные всегда доступны для самых передовых методов Business Intelligence, а также для отчетности и принятия решений. Поскольку в течение заданного промежутка времени передаются меньшие выборки данных (чем в случае пакетной передачи), то дополнительная нагрузка на OLTP-систему оказывается очень незначительной.

Гетерогенность

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

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

Выборочность данных

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

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

Преобразование данных

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

Гибкость

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

Динамическое определение таблиц

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

Обратная связь

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

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

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