Различия между распределенной и локальной транзакциями.

Локальные транзакции Самый простой вид транзакций. В них прикладная программа обращается только к одной СУБД и сама определяет, когда закреплять или откатывать транзакцию. То есть в них роль TM отводится AP.

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

Распределенные транзакции.

То, ради чего и написана спецификация. Намного более сложный случай, но, несмотря на это прикладной код усложняется ненамного, решение о закреплении или откате ложится на плечи координатора, прикладная программа определяет только границы транзакций. Менеджер транзакций делит одну глобальную на несколько веток (branch), которые с большой натяжкой можно назвать локальными. Как это происходит? Допустим, есть два RM, которые участвуют в распределенной транзакции. 1.AP начинает транзакцию. Управление передается TM. 2.Для каждой из них TM вызывает xa_open() для инициализации. Транзакции как таковой ещё нет. 3.Для каждой RM вызывается xa_start() с параметром xid, в котором global_id одно, а branch_id разные. Транзакция началась. 4.Управление возвращается AP, которая выполняет бизнес логику.5.TM завершает транзакцию, вызывая xa_end().

6.TM закрепляет транзакцию, используя протокол двухфазной фиксации (xa_prepare() и xa_commit() или xa_rollback()).

Кроме того, спецификация поддерживает вложенные транзакции (nested transactions), которые полезны, например, для логирования. 1.TM "завершает" ветвь транзакции, вызывая xa_end() с параметром XA_SUSPEND. 2.TM обрабатывает вложенную транзакцию. 3.TM "начинает" "завершенную" ветвь, вызывая xa_start() с параметром XA_RESUME. Локальная транзакция работает с одним источником, например одна БД; распределенная использует несколько — например jms source и БД. Если механизм локальных транзакций прост, то для распределенных требуется определенная инфраструктура. Распределенный процесс требует некого элемента, который будет синхронизировать работу всех источников. Этот элемент — менеджер распределенных транзакций. Подобные менеджеры выпускаются большим количеством компаний, и все они требую определенного изучения документации.

46)Потеря результатов обновления.
Две транзакции по очереди записывают некоторые данные в одну и ту же строку и фиксируют изменения. Обе транзакции успешно накладывают S-блокировки и читают объект . Транзакция A пытается наложить X-блокирокировку для обновления объекта . Блокировка отвергается, т.к. объект уже S-заблокирован транзакцией B. Транзакция A переходит в состояние ожидания до тех пор, пока транзакция B не освободит объект. Транзакция B, в свою очередь, пытается наложить X-блокирокировку для обновления объекта . Блокировка отвергается, т.к. объект уже S-заблокирован транзакцией A. Транзакция B переходит в состояние ожидания до тех пор, пока транзакция A не освободит объект. Результат. Обе транзакции ожидают друг друга и не могут продолжаться. Возникла ситуация тупика

47)Объектно-ориентированные СУБД, их свойства и отличие от реляционных СУБД.

Реляционная (или основанная на таблицах) модель базы данных безусловно наиболее часто используется сегодня и представлена как большими коммерческими пакетами, как Oracle, Sybase, Informix, Ingres и Gupta, так и маленькими как DBaseIV, Access, FoxPro, Alpha4 и Paradox. Все они основаны на первой теоретической работе Кодда и др. 1970 года. Из трех моделей, реляционная модель имеет наиболее хорошую математическую базу, включающую реляционную алгебру и реляционное исчисление. Последнее является основой языка запросов SQL и расширения ODBC, которые широко применяются для подключения пользовательского интерфейса в 2-х и 3-х слойных приложениях клиент/сервер. Объектно-ориентированные базы данных относительно новы и по-прежнему достаточно примитивны в некоторых отношениях. В большинстве из современных систем, таких как Objectivity, Poet и Versant ощущается недостаток удобства как для пользователя, так и для программиста, и сама по себе теория баз данных не имеет такой хорошей математической основы как реляционные или древовидные модели. Это указывает на молодость данной технологии. Серьезная работа ведется по исправлению обоих этих недостатков, и обе системы баз данных (и реляционная, и древовидная) стремятся применить объектно-ориентированные модели, как правило, поверх их собственных неотъемлемых структур.Все реляционные базы данных используют в качестве модели хранения данных двумерные таблицы. Любая система данных, не имеет значения какой сложности, может быть сведена к набору таблиц (или "отношений" в терминологии СУРБД) с некоторой избыточностью. Избыточность контролируется путем приведения отношений к канонической "нормальной" форме, которая минимизирует ненужную избыточность без уменьшения связей между элементами данных.Соединение (при котором временное отношение создается путем соединения информации двух отношений, используя общие поля). Выборка (в которой выбирается подмножество записей в отношении, основываясь на определенных значениях или ряде значений в выбранных полях). Другие операции с данными обычно не поддерживаются в базах с реляционной структурой. Добавление произвольных данных, которые, например, не соответствуют ни одному полю в описании данных, запрещено. Добавление поля для произвольных данных потребовало бы перестройки (реструктурирования) базы данных. А этот, зачастую очень длительный, процесс может выполняться только когда базой данных никто не пользуется. В настоящее время модель реляционной базы данных - лидирующая в компьютерной индустрии и занимает эту позицию уже приблизительно 20 лет. Но эта позиция силы может превратиться в позицию слабости. Несмотря на то, что РБД стали доминирующими в индустрии баз данных за последние 20 лет, многие эксперты почувствовали, что РБД будут вытесняться более современными и гибкими моделями, в первую очередь моделью объектно-ориентированной базы данных. Объектно-ориентированные БД - относительно новая концепция и, как таковая, не имеет четкого определения. Требования, которым должна отвечать " объектно-ориентированная " БД, целиком и полностью лежат на совести их авторов. Свойства, представляющиеся общими для большинства реализаций, таковы: 1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-либо класса. Класс определяется как совокупность свойств (properties), методов (methods), общедоступных (public) и частных (private) структур данных, а также программы, применимых к объектам (экземплярам) данного класса. Классы представляют собой ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызывается для того, чтобы произвести какие-либо действия с объектом (например, напечатать себя или скопировать себя). Свойства - это значения данных, связанные с каждым объектом класса, характеризующие его тем или иным образом (например, цвет, возраст). Свойства присутствуют не во всех реализациях, по сути дела, они являются краткой записью методов без аргументов (таких как "сообщите свой цвет", "сообщите свой возраст"). 2. Инкапсуляция: Внутреннее представление данных и деталей реализации общедоступных и частных методов (программ) является частью определения класса и известно только внутри этого класса. Доступ к объектам класса разрешен только через свойства и методы этого класса или его родителей (см. ниже "наследование"), а не путем использования знания подробностей внутренней реализации. 3. Наследование (одиночное или множественное): Классы определены как часть иерархии классов. Определение каждого класса более низкого уровня наследует свойства и методы его родителя, если они только они явно не объявлены ненаследуемыми или изменены новым определением. При одиночном наследовании класс может иметь только один родительский класс (т.е. классовая иерархия имеет древовидную структуру). При множественном наследовании класс может происходить от многочисленных родителей (т.е. иерархия классов имеет структуру ориентированного нециклического графа, не обязательно древовидную). Не все объектно-ориентированные СУБД поддерживают множественное наследование. 4. Полиморфизм: Несколько классов могут иметь совпадающие имена методов и свойств, даже если они считаются различными. Это позволяет писать методы доступа, которые будут правильно работать с объектами совершенно различных классов, лишь бы соответствующие методы и свойства были в этих классах определены. 5. Сообщения: Взаимодействие c объектами осуществляется путем посылки сообщений с возможностью получения ответов. Это отличается от традиционного для других моделей вызова процедур. Для того, чтобы применить метод к объекту, надо послать ему сообщение типа "примени к себе данный метод" (например, "напечатай себя"). Парадигма пересылки сообщений не всегда используется в объектно-ориентированных базах данных, однако типична для "истинно" ОО-реализаций. успех объектно-ориентированного подхода лежит в смещении акцента со структуры данных (в особенности, от вида связей между данными) к процессу, с помощью которого эти данные создаются, изменяются и уничтожаются. Реальные структуры данных - деталь реализации, лучше всего относящаяся к внутренней работе каждого класса - и разные классы для обеспечения наивысшей эффективности могут быть реализованы совершенно по-разному. Ведение базы данных выполняется как раз за счет знания методов и свойств, предоставляемых классами. Модель ООБД находится на более высоком уровне абстракции, чем реляционные или древовидные БД, поэтому классы можно реализовать, опираясь либо на одну из этих моделей, либо на какую-нибудь еще. Поскольку в центре разработки оказываются не структуры данных, а процедуры (методы), важно, чтобы выбиралась базовая модель, которая обеспечивает достаточную прочность, гибкость и производительность обработки. Реляционные БД с их строгим определением структуры и ограниченным набором разрешенных операций, бесспорно, не подходят в качестве базовой платформы для ООБД. Система М-языка/БД с ее более гибкой структурой данных и более процедурным подходом к разработке представляется особенно хорошо приспособленной для использования в качестве базовой платформы для СУООБД. По-видимому, объектно-ориентированный подход на базе М может превзойти соответствующие реляционные аналоги по скорости доступа и обработки. Объектно-ориентированный подход к системам БД широко разрекламирован как грядущая парадигма, которая заменит реляционную модель через несколько лет. Он действительно дает большую гибкость по сравнению с реляционной моделью и позволяет сосредоточить внимание при разработке и документировании на описании отдельных типов предметов, а не на общей структуре базы данных. Это обещает быть особенно полезным при построении сложных систем БД, которые имеют различные типы данных, особенно, если часто встречаются связи "многие-ко-многим", которые по своей природе не годятся для таблиц. К сожалению, объектно-ориентированный подход пока не столь широко испытан и не настолько "зрел", как остальные два подхода. Наиболее доступный подход к объектно-ориентированной БД - это наложить ее на реляционную или древовидную модель. Так как ООП в большей степени связан с процессом, чем со структурой, представляется, что древовидная модель подходит лучше. Создавая ООБД на основе реляционной структуры, приходится жертвовать свободой, радовавшей на стадии разработки, когда дело доходит до внедрения и сопровождения. 2)Преожение SELECT языка SQL. Выборка с использованием IN, вложенный SELECT. Подзапрос с несколькими уровнями вложенности. оррелированный подзапрос.

SELECT column_name FROM table_name; - простейший вариант селекта Например: - исходная таблица SELECT LastName, FirstName FROM Persons; - выводится на экран

SELECT * FROM Persons; - выводит всю таблицу SELECT IN: SELECT column_name FROM table_nameWHERE column_name IN (value1, value2,..); SELECT SUM(Sales) FROM Store_Information WHERE Store_name IN (SELECT store_name FROM Geography WHERE region_name = 'West'); 3)Использование средств IBM System i для организации защиты систем на основе MS Windows от вирусов.