Информационные технологии в профессиональной деятельности экономиста: Обзор ИТ, предназначенных для оперативной и аналитической обработки данных. OLTP- и 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 системы Большой объем информации Часто различные БД для разных подразделений Нормализованная схема, отсутствие дублирования информации Интенсивное изменение данных Транзакционный режим работы Транзакции затрагивают небольшой объем данных Обработка текущих данных – мгновенный снимок Много клиентов Малое время отклика – несколько секунд Характеристики OLAP системы Большой объем информации Синхронизированная информация из различных БД с использованием общих классификаторов Ненормализованная схема БД с дубликатами Данные меняются редко, Изменение происходит через пакетную загрузку Выполняются сложные нерегламентированные запросы над большим объемом данных с широким применением группировок и агрегатных функций. Анализ временных зависимостей Небольшое количество работающих пользователей – аналитики и менеджеры Большее время отклика (но все равно приемлемое) – несколько минут






Правила Кодда для реляционных БД 1. Правило информации. 2. Правило гарантированного доступа. 3. Правило поддержки недействительных значений. 4. Правило динамического каталога, основанного на реляционной модели. 5.Правило исчерпывающего подъязыка данных. 6. Правило обновления представлений. 7. Правило добавления, обновления и удаления. 8. Правило независимости физических данных. 9. Правило независимости логических данных. 10. Правило независимости условий целостности. 11. Правило независимости распространения. 12. Правило единственности.


Правила Кодда для OLAP 1. Концептуальное многомерное представление. 2. Прозрачность. 3. Доступность. 4. Постоянная производительность при разработке отчетов. 5. Клиент-серверная архитектура. 6. Общая многомерность. 7. Динамическое управление разреженными матрицами. 8. Многопользовательская поддержка. 9. Неограниченные перекрестные операции. 10. Интуитивная манипуляция данными. 11. Гибкие возможности получения отчетов. 12. Неограниченная размерность и число уровней агрегации.


Реализация OLAP Типы OLAP - серверов MOLAP (Multidimensional OLAP) - и детальные данные, и агрегаты хранятся в многомерной БД. ROLAP (Relational OLAP) - детальные данные храняться в реляционной БД; агрегаты хранятся в той же БД в специально созданных служебных таблицах. HOLAP (Hybrid OLAP) - детальные данные храняться в реляционной БД, а агрегаты хранятся в многомерной БД.








Особенности ROLAP – схемы типа звезда 1.Одна таблица фактов, которая сильно денормализована 2.Несколько таблиц измерений, которые также денормализованы 3.Первичный ключ таблицы фактов является составным и имеет по одному столбцу на каждое измерение 4.Агрегированные данные храняться совместно с исходными Недостатки Если агрегаты храняться совместно с исходными данными, то в измерениях необходимо использовать дополнительный параметр – уровень иерархии











Структура хранилища в ORACLE СУБД SQL клиентMOLAP клиент Java API JDBC OCI ODBC OLE DB CWM или CWM2 Хранилище OLAP (BLOB в реляционной таблице) Схема звезда Регистрация метаданных Многомерное ядро (процесс в ядре ORACLE) OLAP DML SQL интерфейс к OLAP (DBMS_AW, OLAP_TABLE, …) Многомерные метаданные

    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.

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

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

    Иерархическая структура предполагала хранение данных в виде структуры дерева.

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

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

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

    Транзакция − это последовательность операций над БД, рассматриваемых СУБД как единое целое. Транзакция переводит БД из одного целостного состояния в другое.

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

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


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

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

    История развития СУБД тесно связана с совершенствованием подходов к решению задач хранения данных и управления транзакциями. Развитый механизм управления транзакциями в современных СУБД сделал их основным средством построения ОLTP-систем, основной задачей которых является обеспечение выполнения операций с БД.

    3.1.3. Использование OLTP-технологии
    в системах поддержки принятия решений

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

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

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

    Основными требованиями предъявляемыми к системам OLTP и СППР являются следующие:

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

    2. Качество данных. OLTP-системы, как правило, хранят информацию, вводимую непосредственно пользователями систем (операторами ЭВМ). Присутствие "человеческого фактора" при вводе повышает вероятность ошибочных данных и может создать локальные проблемы в системе.

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

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

    5. Управление данными. Основное требование к OLTP-системам − обеспечить выполнение операций модификации над БД. При этом предполагается, что они должны выполняться в реальном режиме, и часто очень интенсивно.

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

    7. Характер запросов к данным. В OLTP-системах из-за нормализации БД составление запросов является достаточно сложной работой и требует необходимой квалификации.

    8. Время обработки обращений к данным. OLTP-системы, как правило, работают в режиме реального времени, поэтому к ним предъявляются жесткие требования по обработке данных.

    9. Характер вычислительной нагрузки на систему. Как уже отмечалось ранее, работа с OLTP-системами, как правило, выполняется в режиме реального времени.

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

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

    Общая идея хранилищ данных заключается в разделении БД для − систем и БД для выполнения анализа и последующем их проектировании с учетом соответствующих требований.

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

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

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

    В СУБД развит механизм управления транзакциями, что сделало их основным средством создания систем оперативной обработки транзакций (OLTP-систем). К таким системам относятся первые СППР, решающие задачи информационно-поискового анализа − ИСР.

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

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

    Вопросы для самоконтроля

    1. Перечислите основные задачи, которые решают системы поддержки принятия решений.

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

    3. Укажите типы структур для организации хранилищ данных в СППР. В чем состоят преимущества и недостатки каждого из типов структур?

    4. Обоснуйте целесообразность использования постреляционной модели подсистемы сбора и обработки информации в СППР.

    5. Как интерпретируется понятие транзакции в системах обработки данных?

    6. В чем проявляется основное свойство транзакции в системах обработки данных?

    7. Кратко охарактеризуйте механизм управления транзакциями в OLTP-системах.

    8. Укажите роль и место OLTP-систем для оперативной обработки транзакций. Почему OLTP-системы неэффективны для решения задач оперативно-аналитического и интеллектуального анализа?

    9. Назовите основные требования к OLTP-системам. В чем состоит противоречивость требований к OLTP-системам?

    10. Назовите пути повышения эффективности оперативно-аналитического и интеллектуального анализа в СППР.

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

    OLTP

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

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

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

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

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

    Информационные системы класса OLTP характеризуются следующими особенностями.

    Характеристики ИС - информационных систем - класса OLTP

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

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

    Стратерия разработки систем

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

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

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



Похожие публикации