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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


реферат OLTP технологии

Информация:

Тип работы: реферат. Добавлен: 24.06.2012. Сдан: 2011. Страниц: 8. Уникальность по antiplagiat.ru: < 30%

Описание (план):


 
Недостатки
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[1]-решения, ранее предназначенные для интеграции приложений, сегодня часто конкурируют или сосуществуют с 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-процессом).
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.