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

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

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

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

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

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

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

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

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

- Пути обеспечения надежности системы водоснабжения

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

- I. Концепция безопасности системы защиты

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

- После принятия основных решений по конструкции системы отопления

ПРОЕКТИРОВАНИЕ СИСТЕМЫ ВОДЯНОГО ОТОПЛЕНИЯ ЗДАНИЯ Начертите схемы тепловых узлов при подключении системы отопления по открытой и закрытой схемам. Вопросы для самопроверки При теплоснабжении нескольких зданий. Насосы и другое оборудование устанавливают... [читать подробенее]

- Требования по обеспечению пожарной безопасности системы предотвращения пожара.

Основы обеспечения пожарной безопасности технологических процессов. Вопрос 2.Пожарная профилактика объекта (25мин.) Пожарная профилактика включает в себя комплекс организационных и технических мероприятий, направленных на обеспечение безопасности людей,... [читать подробенее]

- Ткани и системы органов животных

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

В геномах высших эукариот присутствуют многочисленные повторяющиеся последовательности ДНК. У человека, например, такие повторы занимают более 40 % всего генома. И этого следует, что при образовании DSBs вероятность одновременного образования нескольких разрывов по... [читать подробенее]

- Определение групп крови системы АВО цоликлонами анти-А, анти-В и анти-АВ

ОПРЕДЕЛЕНИЕ ГРУПП КРОВИ Согласно этому правилу всем больным можно переливать кровь О(1) группы, так как она не содержит агглютиногенов, а реципиентам АВ(1У) группы можно переливать кровь других групп, так как она не содержит агглютиногенов. Отсюда введены понятия...

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

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

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

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

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

Система оперативной обработки данных (ON LINE TRANSACTION PROCESSING) OLTP рассчитаны на быстрое обслуживание относительно простых запросов большого числа пользователей. Эти системы требуют защиты от несанкционированного доступа, от нарушения целостности данных, аппаратных и программированных сбоев.

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

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

Транзакция - это некоторое законченное с точки зрения пользователя действие над БД.

Системы аналитической обработки данных (ON LINE ANALIZIS PROCESSING) OLAP- это системы поддержки принятия решений, ориентированны на выполнение более сложных запросов, требующих статистической обработки исторических данных, накопленных за определенный промежуток времени. Аналитические системы включают:

1. средства обработки информации на основе методов искусственного интеллекта

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

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

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

Приведенные классы систем (OLAP и OLTP), они основаны на использовании СУБД, но типы запросов сильно отличаются.

Обработка транзакций в OLTP системах

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

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

Транзакция должна обладать 4 основными свойствами:

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

2. согласованность , гарантирует взаимную целостность данных.

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

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

Результатом выполнения транзакции может быть ее фиксация и откат.

Фиксация - это действие, обеспечивающее запись в БД всех изменений.

Откат - если нормальное завершение транзакции невозможно, БД возвращается в исходное состояние, все изменения аннулируются.

При откате и фиксации транзакции используется журнал транзакций, в котором сохраняются все изменения.

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

При откате СУБД по журналу транзакций восстанавливает те строки, которые были модифицированы.

Границы транзакции - это первая и последняя, входящая в неё операции. Предполагается, что транзакция начинается с 1-го SQL оператора, следующие операторы составляют тело транзакции и тело может разветвляется:

1. SQL оператором commit work

SQL оператором rollback

2. простым завершением оператора, вызвавшего транзакцию.

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

Применение транзакции - это эффективный механизм организации многопользовательского доступа к БД.

Проблемы:

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

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

Для устранения этого используют сериализацию (совместная отработка):

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

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

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

Взаимоблокировка транзакций

Пусть транзакция т1 обновляет отношение - о1. Далее эта транзакция т1 пытается модифицировать отношение о2 , которая была ранее заблокирована транзакцией т2. Транзакция т1 переводится в состояния ожидания пока не снята блокировка с отношения о2; в тот же момент транзакция т2 пытается изменить данные отношения о1, ранее заблокирована транзакцией т1. СУБД вынуждена перевести в состояния ожидания и транзакцию т2 следовательно возникает ситуация взаимоблокировки транзакций.

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

Средства восстановления после сбоев

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

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

 OLTP и OLAP системы В предыдущем подразделе отмечалось, что для адекватного представления предметной области, простоты разработки и поддержания базы данных отношения должны быть приведены к третьей нормальной форме (существуют формы нормализации и более высоких порядков, но на практике они используются достаточно редко), то есть быть сильно нормализованными. Однако слабо нормализованные отношения также имеют свои достоинства, основным из которых является то, что если к базе данных обращаться в основном только с запросами, а модификации и добавление данных проводить очень редко, то их выборка производится значительно быстрее. Это объясняется тем, что в слабо нормализованных отношениях уже как бы произведено их соединение и на это не тратится процессорное время. Выделяют два класса систем, для которых в большей степени подходят сильно и слабо нормализованные отношения. Сильно нормализованные модели данных хорошо подходят для OLTP-приложений - On-Line Transaction Processing (OLTP) - приложений оперативной обработки транзакций. Типичными примерами OLTP-приложений являются системы складского учета, заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Таким образом, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. Другим типом приложений являются OLAP-приложения - On-Line Analitical Processing (OLAP) - приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений - Decision Support System (DSS), хранилищ данных - Data Warehouse, систем интеллектуального анализа данных - Data Mining. Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу "что если..." и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками: * добавление в систему новых данных происходит относительно редко крупными блоками, например, один раз в месяц или квартал; * данные, добавленные в систему, как правило, никогда не удаляются; * перед загрузкой данные проходят различные подготовительные процедуры, связанные с приведением их к определенным форматам и тому подобное; * запросы к системе являются нерегламентированными и достаточно сложными; * скорость выполнения запросов важна, но не критична. Базы данных OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся значения этих данных. Физически гиперкуб может быть построен на основе специальной многомерной модели данных - Multidimensional OLAP (MOLAP) или представлен средствами реляционной модели данных - Relational OLAP (ROLAP). В системах OLAP, использующих реляционную модель данных, данные целесообразно хранить в виде слабо нормализованных отношений, содержащих заранее вычисленные основные итоговые данные. Избыточность данных и связанные с ней проблемы здесь не страшны, так как их обновление происходит достаточно редко и вместе с обновлением данных осуществляется пересчет итогов. Характеристики и круг задач, эффективно решаемых каждой технологией, поясняется следующей сравнительной таблицей: ХарактеристикаOLTPOLAPНазначение системыРегистрация, оперативный поиск и обработка транзакций, регламентированный анализРабота с историческими данными, аналитическая обработка, прогнозирование, моделирование Хранимые данныеОперативные, детализированныеОхватывающие большой период времени, агрегированныеТип данныхСтруктурированныеРазнотипные"Возраст" данныхТекущие (несколько месяцев)Исторические (за годы) и прогнозируемыеЧастота обновления данныхВысокая, небольшими "порциями"Малая, большими "порциями"Уровень агрегации данныхДетализированные данныеВ основном - агрегированные данныеПреобладающие операцииВвод данных, поиск, обновлениеАнализ данныхСпособ использования данныхПредсказуемыйНепредсказуемыйВзаимодействие с пользователем На уровне транзакции На уровне всей базы данных Вид деятельностиОперативная, тактическаяАналитическая, стратегическаяПриоритетыВысокая производительность Высокая доступностьГибкость Автономность пользователяКатегория пользователейБольшое количество работников исполнительного звенаОтносительно малое количество работников руководящего звена Сравнение OLTP и OLAP Характеристика OLTP OLAPХарактер запросовМного простых транзакцийСложные транзакцииХранимые данныеОперативные, детализи-рованныеОхватывающие большой период времени, агреги-рованныеВид деятельностиОперативная, тактическаяАналитическая, страте-гическаяТип данныхСтруктурированныеРазнотипныеСистемная характеристикаУчетная система (OLTP)OLAPВзаимодействие с пользователем На уровне транзакции На уровне всей базы данных Данные, используемые при обращении пользователя к системеОтдельные записиГруппы записейВремя откликаСекундыОт нескольких секунд до нескольких минутИспользование аппаратных ресурсовСтабильноеДинамическоеХарактер данных Главным образом первичные (самый низкий уровень детализации)В основном производные (сводные значения)Характер доступа к базе данныхПредопределенные или статические пути доступа и отношения данных Неопределенные или динамические пути доступа и отношения данных Изменчивость данныхВысокая (данные обновляются с каждой транзакцией)Низкая (во время запроса данные обновляются редко)Приоритеты Высокая производительность Высокая доступностьГибкость Автономность пользователя