Для достижения этой цели в System R* используется двухфазный протокол завершения распределенной транзакции. Этот протокол является общеупотребимым в распределенных системах баз данных и описан во многих литературных источниках. Поэтому мы здесь опишем его очень кратко и неформально.
Для описания протокола используется следующая модель. Имеется ряд независимых транзакций-участников распределенной транзакции, выполняющихся под управлением транзакции-координатора. Решение об окончании распределенной транзакции принимается координатором. После этого выполняется первая фаза завершения транзакции, когда координатор передает каждому из участников сообщение "подготовиться к завершению". Получив такое сообщение, каждый участник переходит в состояние готовности как к немедленному завершению транзакции, так и к ее откату. В терминах System R* это означает, что буфер журнала с записями об изменениях базы данных участника выталкиваются на внешнюю память, но синхронизационные захваты не снимаются. После этого каждый участник, успешно выполнивший подготовительные действия, посылает координатору сообщение «готов к завершению». Если координатор получает такие сообщения ото всех участников, то он начинает вторую фазу завершения, рассылая всем участникам сообщение «завершить транзакцию», и это считается завершением распределенной транзакции. Если не все участники успешно выполнили первую фазу, то координатор рассылает всем участникам сообщение «откатить транзакцию», и тогда эффект воздействия распределенной транзакции на состояние баз данных отсутствует.
По отношению к особенностям реализации двухфазного протокола завершения транзакции в System R* заметим еще следующее. В качестве координатора выступает транзакция, выполняющаяся в главном узле, т.е. та, по инициативе которой возникли дополнительные транзакции. Тем самым, наличие центрального координирующего узла не требуется, что соответствует требованию автономности узлов. Для откатов транзакций используется базовый механизм точек сохранения System R. Наконец, классический протокол двухфазного завершения оптимизирован, чтобы сократить число необходимых сообщений.
Как и в System R, согласованность состояния баз данных при параллельном выполнении нескольких транзакций в System R* обеспечивается на основе механизма синхронизационных захватов объектов базы данных при соблюдении двухфазного протокола захватов. Напомним, что это означает разбиение каждой транзакции с точки зрения синхронизации на две фазы - рабочую фазу, на которой захваты только устанавливаются, и фазу завершения, когда все захваты объектов базы данных, произведенные данной транзакцией, снимаются. Синхронизация производится в точности так же, как и в System R: каждая транзакция-участник обращается к локальной базе данных через RSS своего узла. Основной новой проблемой является проблема возможных распределенных тупиков, которые могут возникнуть между несколькими распределенными транзакциями, выполняющимися параллельно. (Тупики между транзакциями - участниками одной распределенной транзакции невозможны, поскольку все участники получают один общий идентификатор транзакции и не конфликтуют по синхронизации). Для обнаружения распределенных синхронизационных тупиков в System R* применяется оригинальный распределенный алгоритм, не нарушающий требования автономности узлов сети и минимизирующий число передаваемых по сети сообщений и необходимую процессорную обработку.
Основная идея алгоритма состоит в том, что в каждом узле периодически производится анализ на предмет существования тупика с использованием информации о связях транзакций по ожиданию ресурсов, локальной в данном узле и полученной от других узлов. При проведении этого анализа обнаруживаются либо циклы ожиданий, что означает наличие тупика, либо потенциальные циклы, которые необходимо уточнить в других узлах. Эти потенциальные циклы представляются в виде специального вида строк. Строка представляет собой по сути дела список транзакций. Все транзакции упорядочены в соответствии со значениями своих идентификаторов («номеров транзакций»). Строка передается для дальнейшего анализа в следующий узел (узел, в котором выполняется самая правая в строке транзакция) только в том случае, если номер первой транзакции в строке меньше номера последней транзакции. (Это оптимизация, уменьшающая число передаваемых по сети сообщений). Этот процесс продолжается до обнаружения тупика.
Если обнаруживается наличие синхронизационного тупика, он разрушается за счет уничтожения (отката) одной из транзакций, входящей в цикл. В качестве жертвы выбирается транзакция, выполнившая к этому моменту наименьший объем работы. Эта информация также передается по сети вместе со строками, описывающими связи транзакций по ожиданию.
2 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ НА ПРИМЕРЕ «АРМ КЛАДОВЩИКА»
2.1 Обследование предметной области, выявление запросов пользователей и построение концептуальной информационной модели ПО
Анализ приведенных ниже объектов и атрибутов позволяет выделить сущности проектируемой базы данных, приняв решение о создании реляционной базы данных, можно построить ее модель.
- Каждая таблица проектируемой базы данных должна содержать информацию на отдельную тему, а каждое поле таблицы – содержать сведения по теме таблицы.
Проектирование БД заключается в определении состава полей ее таблиц и связей между таблицами. От того, насколько тщательно проведен анализ и насколько грамотно спроектирована БД, в существенной мере зависит эффективность будущей СУБД и ее полезность для пользователя.
Предметная область при проектировании базы данных склад. Автоматизации подлежит задача «Учет поступления и отпуска товаров» и решается с целью получения актуальной информации о выдаче товара со склада по заказам клиентов, поступления товаров на склад от постащиков, о клиентах, поставщиках и товарах.
В результате решения задачи предоставляются следующие выходные документы:
- «Инвентаризационная ведомость»
- «Договор поставки»
В предметной области сформируем запросы, необходимые для решения задачи:
1.Кто является получателем товара?
2.Какие товары хранятся на складе?
3.Кто работает на складе?
4.Кто поставляет товар?
Для удобства работы с атрибутами введем их идентификаторы. Наименование атрибута и идентификатор каждого используемого в дальнейшем атрибута приведен ниже (см. таблицу 1).
Таблица 1
Атрибуты и их идентификаторы
| № | Наименование атрибута | Идентификатор |
| 1 | Табельный номер кладовщика | ТН |
| 2 | ФИО кладовщика | ФИО |
| № | Домашний адрес кладовщика | АДРЕС |
| 3 | Телефон | ТЕЛ |
| 4 | Дата рождения | ДАТА_РОЖ |
| 5 | РНН | РНН |
| 6 | Стаж | СТАЖ |
| 7 | Оклад | ОКЛАД |
| 8 | Должность | ДОЛЖ |
| 9 | ФИО клиента | КЛИЕНТ |
| 10 | Банковский счет клиента | БАНК |
| 11 | Адрес клиента | АДР_КЛ |
| 12 | Фирма клиента | НАЗ_ФИРМ |
| 13 | Номер заказа | НЗ |
| 14 | Телефон клиента | ТЕЛ_КЛ |
| 15 | Срок поставки товара | СРОК |
| 16 | Количество поставки товара | КОЛ_ВО |
| 17 | Номенклатурный номер товара | ННТОВ |
| 18 | Цена товара отпускная | ЦЕНА_ПОС |
| 19 | Наименование товара | НАЗ_ТОВ |
| 20 | Стоимость товара | СТОИМ |
| 21 | Стоимость без НДС | БЕЗ_НДС |
Продолжение таблицы 1
| № | Наименование атрибута | Идентификатор |
| 22 | Количество товара на складе | КОЛ_ВО_СКЛ |
| 23 | Единица измерения товара | ЕД_ИЗМ |
| 24 | ТМБ | ТМБ |
| 25 | Марка товара | МАРКА |
| 26 | ГОСТ | ГОСТ |
| 27 | Идентификационный номер поставщика | ИДП |
| 28 | ФИО представителя поставщика | ФИО_ПОС |
| 29 | Наименование фирмы-поставщика | НАИМ_ФИРМ |
| 30 | Телефон поставщика | ТЕЛ_ПОС |
| 31 | Адрес поставщика | АДР_ПОС |
| 32 | Счет поставщика | СЧЕТ |
| 33 | РНН | РС |
| 34 | МФО | МФО |
На основании необходимых запросов выделим следующие сущности с атрибутами:
ЗАКАЗ (Номер заказа, ФИО клиента, номер банковского счета, название фирмы, адрес, телефон, номенклатурный номер товара, цена, количество, дата поставки);
ТОВАР (номенклатурный номер товара, наименование товара, стоимость, стоимость без НДС, количество, единица измерения, ТМБ, марка товара, гост);
ПОСТАВЩИК (Идентификационный код поставщика, ФИО, наименование фирмы, адрес поставщика, телефон, счет, рнн, мфо );
КЛАДОВЩИК (табельный номер, ФИО, адрес, телефон, дата рождения, рнн, стаж, оклад, должность);
Проведем анализ связей между сущностями:
КЛАДОВЩИК, ЗАКАЗ - оформляет; связь типа М:М;
КЛАДОВЩИК, ТОВАР – получает, связь типа М:М;
ПОСТАЩИК, ТОВАР - поставляет, связь типа М:М;
После выбора сущностей, задания атрибутов и анализа связей между сущностями проектируем концептуальную схему БД. (см. рис. 7)