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

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

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

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

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

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

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

Очень короткий ответ:

Различные базы данных имеют разные виды использования. Я не эксперт по базам данных. Когда сомневаюсь, я просто использую SQL.

Короткий ответ:

Рассмотрим два примера сценариев:

Сценарий 1:

Вы строите интернет-магазин/веб-сайт, и хотите иметь возможность:

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

Вы хотите найти данные для конкретного пользователя, изменить его имя... В основном выполнять операции INSERT, UPDATE, DELETE для пользовательских данных. То же самое с продуктами и т.д.

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

Сценарий 2:

У вас есть интернет-магазин/веб-сайт, и вы хотите вычислить такие вещи, как

• "общие расходы на деньги для всех пользователей"
• "какой самый продаваемый продукт"

Это относится к области аналитики/бизнес-аналитики, поэтому OLAP, вероятно, более подходит.

Если вы думаете в терминах "Было бы хорошо знать, как/что/сколько"... и включает весь "объект" одного или нескольких видов (например, всех пользователей и большинство продуктов чтобы узнать, сколько всего потрачено), тогда OLAP, вероятно, лучше подходит.

Более длинный ответ:

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

Итак, каково может быть принципиальное различие между OLAP и OLTP?

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

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

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

Из этого следует, что :

• Базы данных

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

С другой стороны, базы данных

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

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

Говоря об аббревиатурах:

Разница довольно проста.

OLTP (обработка транзакций в режиме on-line).

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

OLAP (он-лайн аналитическая обработка)

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

OLTP (O n- L ine T ransaction P обработка) vs OLAP ( O n- L ine A nalytical P ) p >

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

В следующей таблице приведены основные различия между дизайном системы OLTP и OLAP.


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

Основные характеристики хранилищ данных.

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

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

• многомерное представление данных ;
• поддержка сложных расчетов;
• правильный учет фактора времени.

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

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

OLAP и OLTP. Характеристики и основные отличия

OLAP	OLTP
Хранилище данных должно включать как внутренние корпоративные данные, так и внешние данные	основным источником информации, поступающей в оперативную БД , является деятельность корпорации , а для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов )
Объем аналитических БД как минимум на порядок больше объема оперативных. для проведения достоверных анализа и прогнозирования в хранилище данных нужно иметь информацию о деятельности корпорации и состоянии рынка на протяжении нескольких лет	Для оперативной обработки требуются данные за несколько последних месяцев
Хранилище данных должно содержать единообразно представленную и согласованную информацию, максимально соответствующую содержанию оперативных БД . Необходима компонента для извлечения и "очистки" информации из разных источников. Во многих крупных корпорациях одновременно существуют несколько оперативных ИС с собственными БД (по историческим причинам ).	Оперативные БД могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую
Набор запросов к аналитической базе данных предсказать невозможно. хранилища данных существуют, чтобы отвечать на нерегламентированные запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической БД стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.)	Системы обработки данных создаются в расчете на решение конкретных задач. Информация из БД выбирается часто и небольшими порциями. Обычно набор запросов к оперативной БД известен уже при проектировании
При малой изменчивости аналитических БД (только при загрузке данных ) оказываются разумными упорядоченность массивов, более быстрые методы индексации при массовой выборке, хранение заранее агрегированных данных	Системы обработки данных по своей природе являются сильно изменчивыми, что учитывается в используемых СУБД (нормализованная структура БД , строки хранятся неупорядоченно, B- деревья для индексации , транзакционность )
Информация аналитических БД настолько критична для корпорации , что требуются большая грануляция защиты (индивидуальные права доступа к определенным строкам и/или столбцам таблицы)	Для систем обработки данных обычно хватает защиты информации на уровне таблиц

Правила Кодда для OLAP систем

В 1993 году Кодд опубликовал труд под названием " OLAP для пользователей-аналитиков: каким он должен быть". В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.

1. Концептуальное многомерное представление. OLAP -модель должна быть многомерной в своей основе. Многомерная концептуальная схема или пользовательское представление облегчают моделирование и анализ так же, впрочем, как и вычисления .
2. Прозрачность. Пользователь способен получить все необходимые данные из OLAP -машины, даже не подозревая, откуда они берутся. Вне зависимости от того, является OLAP -продукт частью средств пользователя или нет, этот факт должен быть незаметен для пользователя. Если OLAP предоставляется клиент -серверными вычислениями, то этот факт также, по возможности, должен быть невидим для пользователя. OLAP должен предоставляться в контексте истинно открытой архитектуры, позволяя пользователю, где бы он ни находился, связываться при помощи аналитического инструмента с сервером. В дополнение к этому прозрачность должна достигаться и при взаимодействии аналитического инструмента с гомогенной и гетерогенной средами БД .
3. Доступность. OLAP должен предоставлять свою собственную логическую схему для доступа в гетерогенной среде БД и выполнять соответствующие преобразования для предоставления данных пользователю. Более того, необходимо заранее позаботиться о том, где и как, и какие типы физической организации данных действительно будут использоваться. OLAP -система должна выполнять доступ только к действительно требующимся данным, а не применять общий принцип "кухонной воронки", который влечет ненужный ввод.
4. Постоянная производительность при разработке отчетов . Производительность формирования отчетов не должна существенно падать с ростом количества измерений и размеров базы данных.
5. Клиент -серверная архитектура. Требуется, чтобы продукт был не только клиент -серверным, но и чтобы серверный компонент был бы достаточно интеллектуальным для того, чтобы различные клиенты могли подключаться с минимумом усилий и программирования.
6. Общая многомерность. Все измерения должны быть равноправны, каждое измерение должно быть эквивалентно и в структуре, и в операционных возможностях. Правда, допускаются дополнительные операционные возможности для отдельных измерений (видимо, подразумевается время), но такие дополнительные функции должны быть предоставлены любому измерению. Не должно быть так, чтобы базовые структуры данных , вычислительные или отчетные форматы были более свойственны какому-то одному измерению.
7. Динамическое управление разреженными матрицами . OLAP системы должны автоматически настраивать свою физическую схему в зависимости от типа модели , объемов данных и разреженности базы данных.
8. Многопользовательская поддержка . OLAP -инструмент должен предоставлять возможности совместного доступа (запроса и дополнения), целостности и безопасности.
9. Неограниченные перекрестные операции. Все виды операций должны быть дозволены для любых измерений.
10. Интуитивная манипуляция данными. Манипулирование данными осуществлялось посредством прямых действий над ячейками в режиме просмотра без использования меню и множественных операций.
11. Гибкие возможности получения отчетов . Измерения должны быть размещены в отчете так, как это нужно пользователю.
12. Неограниченная

Принимая во внимание все перечисленное, сравнение между различными MDDпродуктами можно проводить только по самым обобщенным категориям. В более дешевом секторе рынка присутствуют лишь однопользовательские и предназначенные для небольших локальных сетей средства просмотра многомерных данных. Хотя они обладают довольно высоким уровнем функциональных возможностей и удобны в использовании, эти системы ограниченны по своему масштабу. и им недостает средств, необходимых для реализации OLAPобработки в широком смысле. В данную категорию попадают такие продукты, как PowerPlay корпорации Cognos, PaBlo фирмы Andyne и Mercury компании Business Objects. Дорогой же сектор рынка представлен системами Acumate ES фирмы Kenan Technologies, Express корпорации Oracle, Gentium компании Planning Sciences и Holos фирмы

Holistic Systems. Они настолько разнятся по своим возможностям, что любую из них можно смело выделять в отдельную категорию. И наконец, MDD-системы в чистом виде: Essbase корпорации Arbor Software, LightShip Server фирмы Pilot Software и TM/1 компании Sinper .

Второй класс OLAP-средств -реляционные OLAP-системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной. Подобно средствам первого класса, ROLAP-системы хорошо приспособлены для работы с крупными информационными хранилищами, требуют значительных затрат обслуживания специалистами информационных подразделений и предусматривают работу в многопользовательском режиме. Среди продуктов этого типа - IQ/Vision корпорации IQ Software, DSS/Server и DSS/Agent фирмы MicroStrategy и DecisionSuite компании Information Advantage.

ROLAP-средства реализуют функции поддержки принятия решений в надстройке над реляционным процессором БД.

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

в частности:

- иметь мощный оптимизированный для OLAP генератор SQLвыражений, позволяющий применять многопроходные SQL-операторы SELECT и/или коррелированные подзапросы;

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

Генерирвать SQL-выражения, оптимизированные для целевой реляционной СУБД, включая поддержку доступных в ней расширений этого языка;

- предоставлять механизмы описания модели данных с помощью метаданных и давать возможность использовать эти метаданные для построения запросов в реальном масштабе времени;

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

Третий, сравнительно новый тип OLAP-средств -инструменты генерации запросов и отчетов для настольных ПК , дополненные

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

компания Brio Technology со своей системой Brio Query Enterprise, Business Objects с одноименным продуктом и Cognos с PowerPlay.

В настоящее время увеличивается число Web-совместимых продуктов OLAP.

Важным является вопрос приспосабливания OLAP к остальному ПО. Хотя поставщики OLAP начинают предлагать некоторые способы взаимодействия с SQL-СУБД и другими инструментами, но однако, пользователи и аналитики предупреждают, что уровень интеграции может быть различным и, вероятно, потребует значительного объема кодирования, включая написание запросов на языке SQL. Более того, для интеграции OLAP с остальным программным обеспечением предприятия не существует промышленного стандарта.

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

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

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

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

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

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

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

Таблица 8

Круг задач решаемых OLTP- и OLAP-системами

Характеристика
Частота обновления	Высокая частота,	Малая частота, большие "порции"
	небольшие "порции"
Источники данных	В основном, внутренние	По отношению к аналитической
		системе, в основном,
Возраст данных	Текущие (несколько	Исторически (за годы) и
		прогнозируемые
Уровень агрегации	Детализированные данные	В основном
		агрегированные данные
Возможности	Регламентированные	Последовательность
аналитических		интерактивных очетов,
операций		динамическое изменение уровней
		агрегаций и срезов данных
Назначение	Фиксация, оперативный	Работа с историческими
	поиск и обработка данных,	данными, аналитическая
	регламентированная	обработка, прогнозирование,
	аналитическая обработка	моделирование

				Таблица 9
	Сравнение OLTP и OLAP
характеристика
Преобладающие		Ввод данных, поиск		Анализ данных
операции
Характер запросов				Сложные транзакции
		транзакций
Хранимые данные		Оперативные,		охватывающие
		детализированные
				агрегированные
Вид деятельности		Оперативная,		Аналитическая,
		тактическая		стратегическая
Тип данных		Структурированные		Разнотипные

3.7. Подходы к выбору экономических информационных систем

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

1. Насколько технологии бизнеса в фирме отличаются от традиционных.

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

неэффективной - часть модулей системы будут неприменимы или неработоспособны в поставленных условиях.

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

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

3. Какие суммы готова вложить фирма в автоматизацию.

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

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

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

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

Более подробный анализ достоинств и недостатков методов автоматизации представлен в таблице.

Таблица 10

Достоинства и недостатки методов автоматизации

Достоинства подхода

Недостатки подхода

Ориентация

российские

Проблема

инвестиций

адаптация

законы, "особенности" бизнеса,

первоначальные

готовой ЭИС

бухгалтерского учета

абсолютные

величины

российского

оказаться

невелики,

дальнейшие

производства

Доступность

разработчиков

обучение,

поддержки

обслуживание

развитие

сопровождения, что в варианте

информационной

с зарубежным продуктом либо

быть весьма значительными). В

имеет куда меньше масштабы,

условиях

нестабильности

обходится

экономики

несовершенства

дороже (возможно в десятки и

законодательства,

сотни раз). Рабочий день одного

гарантии

стабильности

квалифицированного

производителя

программного

специалиста

настройке

обеспечения (ПО) на протяжении

адаптации систем такого класса

всего срока эксплуатации ПО.

западная фирма вполне может

оценить очень дорого.

1.2.Покупка и

Наибольшим

начальные

адаптация

подобного

является

готовой ЭИС

огромная

мощность

Весьма значительные

затраты на

зарубежного

потенциал западных продуктов

внедрение

продукта,

обучение

производства

и комплексов автоматизации.

персонала и связанные с этим

Обычно они состоят из ряда

изменения

комплектуются

коснуться

аппаратного

зависимости

обеспечения фирмы.

потребителя (хотя существует и

В связи со многими чисто

целый ряд систем, которые по

российскими факторами (большая

причинам

динамичность

модульными

являются;

обстановки,

системам

свойственна

человеческого

большая закрытость и большая

другое) величина риска подобного

трудность

эксплуатации

рода вложений очень высока.

внедрении).

Основной

проблемой

является

необходимость

переориентации

технических

аспектов деятельности фирмы под

то, как это представляли себе

разработчики продукта, что в

наших условиях возможно очень

редко, даже если эти технологии

признаны

общепринятыми.

Отсутствие

некоторых

продуктах

типичных

российского

пользователя

компонент,

недостаточная

локализация

затруднить

значительно

эффективность его применения.

Стратегии

и критерии выбора

западной

информационной

достаточно

непросты,

главными из требований, которые

могут быть предъявлены системе

подобного

являются:

функциональная

открытость,

модульность,

масштабируемость, способность к

работе в распределенной среде,

настраиваемость

поставки в исходных текстах),

ценовая политика производителя

продукта и его представителей в

2.Разработка

Этот подход в большинстве

Большое (причем подчас трудно

случаев применим лишь в двух

прогнозируемое) время разработки

собственным

вариантах: для достаточно

и, во многих случаях, большая

крупной фирмы, способной

величина затрат.

квалифицированных

разработчиков ПО и в том

случае, если комплекс

автоматизации не очень велик и

может быть разработан

достаточно ограниченными

ресурсами.

Обычно этот вариант

автоматизации используется в

том случае, когда ни один из

существующих коммерческих

продуктов не удовлетворяет

руководство предприятия, либо

если бизнес настолько

динамичен, что перенастройка

готового продукта окажется

дороже или менее

эффективной, чем своего.

Достоинства:

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

конкретную фирму

комплекс

автоматизации,

покрывающий

требуемый

качество,

эффективность и оперативность

"поддержки" (никто не знает

всех особенностей бизнеса

фирме лучше

ее собственных

сотрудников).

3.Разработка

Этот вариант перекликается с

Однако тут возникают проблемы,

предыдущим, но отличается от

сходные первым вариантом

совместно с

него следующим: фирме не

автоматизации, но обычно этими

проблемами легче управлять из-за

разработчико

программистов с одной

более тесных контактов

стороны, и она получает

потребителя информационной

ориентированный чисто на нее

системы и фирмы-разработчика

продукт - с другой.

(или интегратора).

В случае наличия у фирмы-

разработчика технологического

"конструктора" (ядра

информационной системы,

достаточно легко развиваемого

и адаптируемого под

меняющиеся условия) такой

вариант автоматизации может

оказаться дешевле и

эффективнее второго подхода и

динамичнее и технологичнее

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

Внедрение качественной ЭИС является одним из важнейших элементов рыночного успеха предприятия и условием ее динамичного развития.

3.8. Критерии выбора ЭИС

При выборе ЭИС необходимо учитывать следующие критерии:

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

сколько работающих систем в России. Имеются ли внедрения на родственных предприятиях? Потребовалась ли помощь внешних консультантов?

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

качество локализации западной системы. Есть области производства, где действуют стандарты - юридические и фактические. Например - методы бухгалтерского учета, бухгалтерская и налоговая отчетность. В конструкторской и технологической подготовке производства у отечественных предприятий повсеместно приняты стандарты ЕСКД и ЕСТД. На западных предприятиях принята предметно замкнутая организация производства, а для отечественных - более привычна технологическая специализация. На западе безцеховая структура управления, в России - цеховая. Все эти моменты должны быть отработаны при локализации. Желательно, чтобы система отрабатывала такие российские реалии как бартер, цепочки зачетов, предоплату, оплата в неденежной форме, неотфактурованные поставки и т.д.

какая российская команда стоит за западной системой. Кто ее русифицировал, кто внедряет? Знают ли они производство? Какое у них образование? Какой опыт? Какая за ними “история успехов”? Какой их подход к внедрению?

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

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

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

гибкость. Система будет внедряться полтора-три года и будет работать пять - десять лет. За это время предприятие изменится. Изменится продукция, оргструктура, организация управления, бизнес - процессы, роли и полномочия управленцев. Система управления должна меняться вместе с производством. Значит система должна позволять легко менять АРМы и меню, формировать отчеты и справки, делать произвольные выборки информации в удобном представлении, менять бизнес - процессы и алгоритмы путем параметрической настройки и так далее. Обычная проблема с западными системами - не понятно, для какого пользователя экраны для ввода информации. Вроде бы для технолога, но при чем тут нормативы планирования? Вроде бы для кладовщика, но при чем тут цены и длительность цикла? Вроде бы для бухгалтера, но для какого раздела учета? В этом случае придется разбивать экраны, убирать лишние реквизиты, добавлять нужные, менять названия полей, менять их расположение на экране, менять значность, добавлять поля в базу данных, менять HELP. Позволит ли это делать система и какой ценой? Система должна также легко интегрироваться с другими модулями, например, с российскими программами расчета зарплаты или управления персоналом (не очевидно, что удастся использовать соответствующие западные аналоги) или с уже существующими старыми разработками, которые нельзя отключить (из-за специфики, уникальности и т.п.). Системы европейского производства обычно более гибки, чем американские, - они изначально ориентированы на учет национальных особенностей разных стран Европейского сообщества,

архитектура. Желательна трехзвенная - сервер базы данных, сервер приложений, клиент - клиент-серверная архитектура с возможностью использования “тупых терминалов”. Клиент может быть “толстым” или “тонким”,

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

Недостатки
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-процессом).
и т.д.................