Shpory_po_SUBD
.pdf39.Неявное определение транзакций.
Необязательно явно указывать начало транзакций.
ВSS система автоматически начинает новую транзакцию после того, как завершена предыдущая. При открытии нового соединения также создаѐтся новая транзакция, но автоматического фиксирования транзакций не происходит, и пользователь должен с помощью команд COMMIT TRAN или ROLLBACK TRAN выполнять фиксирование или откат транзакций.
Автоматическое фиксирование транзакций возможно лишь в следующих случаях: 1) изменение таблицы – ALTER TABLE;
2) создание в БД нового объекта;
3) удаление данных из таблицы;
4) удаление объекта БД;
5) выборка данных из курсора.
ВSS есть специальная команда, которая позволяет задавать или отклонять режим
неявного начала транзакций: SET IMPLICIT TRANSACTION ON (включѐн)
40.Распределенные транзакции.
Распределѐнные транзакции (РТ) (distributed transaction) – это совокупность 2х или более локальных транзакций, выполняемых одновременно в различных БД.
Каждая из локальных транзакций выполняется самостоятельно, не подозревая о том, что является частью РТ. Поэтому возникает задача синхронизации действий в РТ. В качестве такого централизованного менеджера в SS имеется координатор распределѐнных транзакций (КРТ) (MSDTC – Microsoft Distributed Transaction Coordinator).
Этот координатор реализован в виде службы ОС и может запускаться отдельно
от SS.
Источник данных, к которым происходит обращение, называется менеджером ресурсов (МР). РТ передаѐт запрос на выборку данных МР. МР должен обеспечить возможность создания, фиксирования, отката транзакций, а также управлять ходом работы полученного запроса, для того чтобы синхронизировать действия множества МР-ов, задействованных в РТ.
Для решения этих задач имеется специальный модуль, называемый обработчиком распределѐнных запросов (ОРЗ).
Как и в случае с обычными транзакциями РТ состоит из 2 фаз: 1) начало; 2) завершение.
Как правило, начало РТ не вызывает трудностей. Как только инициализированы все локальные транзакции, можно начинать выполнение РТ. Возникают сложности при фиксации РТ. Здесь необходим механизм синхронизации фиксирования всех локальных транзакций. Для этой цели имеется двухфазный протокол фиксирования транзакций
(Two Phase Commit Protocol -- TPCP).
Состоит из 2х фаз: 1) фаза подготовки.
На этом этапе каждому из локальных МР посылается сообщение к фиксированию транзакций.
2) фаза фиксирования.
Информация об успешном или неуспешном выполнении фазы подготовки РТ поступает КРТ. Если все локальные МР успешно выполнили фазу подготовки, координатор посылает им команду на окончательное фиксирование транзакций. Считается, что транзакция успешно зафиксирована.
Если хотя бы 1 из локальных транзакций не может быть зафиксирована, координатор посылает МР, которые участвовали в РТ, команду отката локальных транзакций.
41.Блокировки: назначение, создание.
Блокировкой называется временное ограничение, которое накладывается системой на использование тех или иных ресурсов. Блок-ки необходимы для обеспечения изолированности транзакций.
Простейшим способом обеспечения изолированности транзакций является запрещение любого обращения к данным, которые используются в транзакции. Часто бывает достаточно запретить изменение данных, можно оставить возможность чтения данных. Но если транзакция вносит изменения в данные, они должны блокироваться полностью с тем, чтобы другие транзакции не использовали промежуточные данные.
В SS имеется несколько различных типов блокировок. Блокировки могут накладываться на отдельную строку таблицы, в целом на таблицу. Управлением блокировками занимается менеджер блокировок (МБ). В СУБД, которые не имеют механизмов изоляции транзакций, могут возникнуть следующие проблемы:
1) проблема последнего обновления/изменения (The last update problem).
При одновременной попытке транзакций изменять одни и те же данные часть их будет утеряна.
Изменения, которые были внесены ранее выполненными транзакциями, будут утеряны. Внесутся изменения, выполненные последними транзакциями. При этом транзакции не будут знать, что их изменения потеряны.
2) проблема грязного чтения (The uncommitted depending problem).
Эта проблема возникает, когда транзакция пытается считать данные, которые находятся на стадии обработки другими транзакциями. При этом данные могут нарушать ограничения целостности и правила.
3) проблема неповторяемого чтения (The inconsistent analysis problem).
Возникает, если транзакция многократно читает одни и те же данные. Между операциями чтения другая транзакция может изменить данные, и в результате первая транзакция будет оперировать изменѐнными данными.
4) проблема чтения фантомов (The phantom read problem).
Возникает, если во время выполнения транзакции в таблицу добавляются новые строки, которые могут быть обработаны транзакциями.
Имеется стандарт, который определяет уровни блокировки:
Level 0 – запрещение загрязнения данных (реш-ся пробл. посл. загрязнения): одни и те же данные в каждый момент времени может изменять только одна транзакция.
Level 1 – запрещение грязного чтения. Если транзакция начинает изменение данных, СУБД должна блокировать ресурсы с тем, чтобы ни 1 из транзакций не могла прочитать данные до тех пор, пока транзакция, которая вносит изменения, не будет зафиксирована или изменена.
Level 2 – запрещение неповторяемого чтения. Если транзакция обращается к каким-либо данным, СУБД организует блокировку таким образом, чтобы ни 1 из транзакций не могла изменить эти данные. Если транзакция только читает данные, то достаточно запретить лишь изменение данных, если изменение – то необходимо полностью блокировать ресурсы.
Level 3 – запрещение фантомов. Если транзакция производит выборку по логическому условию, никакая другая транзакция не должна добавлять или удалять строки, которые удовлетворяют этому логическому условию. В SS поддерживаются все эти уровни блокировок.
42.Приложение по работе с базой данных: основные требования, структура.
1.Сбор информации. Вам необходимо знать все, что хотят пользователи, заказчик или Ваше руководство от этой системы. В цивилизованном обществе принято давать разработчику ТЗ, а также разделять программистов-аналитиков, проектирующих систему, от просто-программистов, пишущих код, и тем более различать администраторов и разработчиков Баз Данных.
2.Выбор платформы. Включает в себя как выбор железа, в соответствии с планируемой нагрузкой на БД с учетом масштабируемости, так и выбор СУБД. Существует множество критериев, и для каждого они свои. Для кого-то важна цена/бесплатность продукта, для кого-то производительность.
3.Грамотное проектирование структуры БД, с максимальным вынесением логики работы на уровень сервера БД.
4.Собственно проектирование и разработка интерфейса к БД. Ни один пользователь никогда не полезет в дебри утилит администрирования БД, а тем более не будет использовать SQL для получения или изменения каких-либо данных.
При проектировании интерфейса также можно выделить несколько этапов:
Примерно представить как все это должно выглядеть и какую функциональность выдавать пользователям. Исходя из этого, определиться с минимально необходимым набором компонентов для реализации.
Найти данные компоненты.
Создать программу
43. Автоматизированные информационные системы (АИС). Определение, структура АИС.
Большинство приложений по работе с БД не что иное, как автоматизированные информационные системы (АИС).
Основу ИС составляют 3 компонента:
1)БД, как правило, реляц. типа, которая поддерживает доступ на основе стандарта SQL;
2)программные средства, обеспечивающие логику обработки данных;
3)интерфейс пользователя.
ИС (или АИС) – это программно-аппаратная схема, предназначенная для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающая в соответствии с заложенной в неѐ логикой обработки возможность получения, модификации и хранения информации.
44.АИС. Основные требования.
В спецификации АИС, которая выполняется для продаж, обязательно необходимо указывать, какие стандарты и технологии управления она поддерживает. Разработка ИС ведѐтся в соответствии с документом требований к АИС.
Существуют различные трактовки понятия «требование»:
1)требование – это условие или возможность, которым должна соответствовать
система;
2)треб-е – это исходные данные, на основе которых создаѐтся АИС.
Первичные данные поступают из различных источников. Они характеризуются чаще всего противоречивостью, нечѐткостью, изменчивостью, неполнотой. Поэтому значительная часть требований собирается и обрабатывается на ранних стадиях создания АИС.
Требования классифицируются следующим образом:
1)требования к продукту (то, что формулирует заказчик) – основополагающие при разработке АИС.
2)требования к проекту – как разработчик будет выполнять работы по созданию целевой системы. Здесь на этапе разработки требования к проекту следует регламентировать совместно с заказчиком для того, чтобы снизить риск получения проекта с опозданием либо ненадлежащего качества.
Уровни требований:
1)бизнес-требования (верхний уровень);
2)уровень требований пользователя (как правило, требования пользователя касаются в основном интерфейса, поэтому бывают плохо структурированы, противоречивы – необходима формализация требований);
3)функциональные требования (требования по работе с отдельными элементами системы).
45. АИС. Классификация по масштабу.
По масштабу: 1) однопользовательские; 2) групповые; 3) корпоративные. Однопользовательские ИС предназначены для использования на одном рабочем
месте. В качестве основы одноп. систем лежит стандарт XBase (Clipper, FoxPRO, Dbase, Paradox, MS Access). Каждая из перечисленных систем обладает собственной высокоуровневой инструментальной средой, которая позволяет создать БД, логику обработки, пользовательский интерфейс.
Групповые ИС предназначены для автоматизации деятельности в рабочей группе. Групповые системы, как правило, представляют собой специализированные клиентские решения (поэтому их называют и рабочие места).
Для создания групповых ИС в основонм используются те же средства, что и для однопользовательских ИС. Однако предпочтительнее при создании групповых систем отдавать предпочтение реляционным серверам, использовать выделенный сервер
(Oracle, MSSQL, Informix).
Корпоративные ИС-ы (КИС) предназначены для автоматизации деятельности предприятия. Понятие КИС неразрывно связано с понятием ERP-системы.
В основе ERP-систем лежит международный стандарт управления предприятием MRP-II, который позволяет вести учѐт, анализ и планирование основных ресурсов: финансовых, человеческих и материальных.
Среди требований, кот. предъявляются к КИС, следует отметить:
1)централизация данных в единой БД;
2)близкий к реальному режим работы;
3)сохранение общей модели управления для предприятий разных отраслей;
4)поддержка территориально-распределѐнных структур;
5)работа на широком круге аппаратно-программных платформ и СУБД.
Примеры КИС: Галактика, SAPR3.
46.АИС. Классификация по архитектуре.
Архитектура «файл-сервер»
Исполняемые модули и данные размещаются в отдельных файлах. Для хранения данных используется выделенный сервер, который является файловым сервером. Исполняемые модули хранятся либо на рабочих станциях, либо на файловом сервере.
Архитектура «клиент-сервер»
Клиент запрашивает те или иные сервисы в соответствии с определѐнным протоколом обмена данными. Сервер обрабатывает запрос клиента и передаѐт ему запрашиваемую порцию данных.
Различают понятия «тонкий клиент» и «толстый клиент».
В системах на основе «тонкого клиента» используется мощный сервер БД, библиотека ХП которого реализует основную логику обработки данных непосредственно на сервере. Основное достоинство таких систем – относительная дешевизна клиентских станций.
Системы с толстым клиентом, напротив, реализуют основную логику работы на клиенте, а сервер представляет собой в чистом виде сервер БД, который обеспечивает исполнение только стандартных запросов на обработку БД. В этих системах более высокие требования предъявляются к клиентам, к серверу ниже.
Трѐхслойная архитектура
Базируется на специализации компонент архитектуры. Клиент занимается организацией интерфейса пользователя, сервер БД – только стандартизированной обработкой данных. Для реализации логики обработки данных архитектура реализует отдельный слой – слой бизнес-логики. Этот слой может представлять собой либо выделенный сервер (сервер приложения), либо размещается на клиенте в качестве динамической библиотеки.
Эта архитектура позволяет объединить в себе достоинства толстого и тонкого клиента: хорошая переносимость + невысокие требования к клиенту.
С развитием интернет-технологий появилась разновидность трѐхслойной архитектуры. Здесь роль сервера приложения играет web-сервер, роль клиента – стандартный web-браузер.