Завершение транзакции

Регистрация

Блокировка

Размеры блокируемых элементов

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

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

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

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

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

Физическая и логическая независимость. (Архитектура базы данных.)

С точки зрения моделей современные СУБД имеют трехуровневую систему организации БД, предложенную американским комитетом по стандартизации ANSI (American National Standards Institute) изображенная на рис. 2.4:

Рис. 2.4. Трехуровневая модель системы управления базой данных, предложенная ANSI

1. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.

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

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

Процесс прохождения пользовательского запроса

Рисунок 2.5 иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке запроса на получение данных. Цифрами помечена последовательность взаимодействий:

1. Пользователь посылает СУБД запрос на получение данных из БД – стрелка (1).

2. Анализ прав пользователя и внешней модели данных, соответствующей данному пользователю, подтверждает или запрещает доступ данного пользователя к запрошенным данным – (2) и (3).

3. В случае запрета на доступ к данным СУБД сообщает пользователю об этом (стрелка 12) и прекращает дальнейший процесс обработки данных, в противном случае СУБД определяет часть концептуальной модели, которая затрагивается запросом пользователя – (4).

Рис. 2.5. Схема прохождения запроса к БД

4. СУБД получает информацию о запрошенной части концептуальной модели – (5).

5. СУБД запрашивает информацию о местоположении данных на физическом уровне (файлы или физические адреса) – (6).

6. В СУБД возвращается информация о местоположении данных в терминах операционной системы – (7).

7. СУБД просит операционную систему предоставить необходимые данные, используя средства операционной системы – (8).

8. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер – (9).

9. Операционная система оповещает СУБД об окончании пересылки (10).

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

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

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

Разумеется, механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.

Пользователи банков данных

Как любой программно-организационно-технический комплекс, банк данных существует во времени и в пространстве. Он имеет определенные стадии своего развития:

1. Проектирование.

2. Реализация.

3. Эксплуатация;

4. Модернизация и развитие.

5. Полная реорганизация.

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

Определим основные категории пользователей и их роль в функционировании банка данных:

Ø Конечные пользователи. Это основная категория пользователей, в интересах которых и создается банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты вашей фирмы, просматривающие каталог вашей продукции или услуг с обобщенным или подробным описанием того и другого. Регулярными пользователями могут быть ваши сотрудники, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении своих должностных обязанностей. Например, менеджер, планирующий работу сервисного отдела компьютерной фирмы, имеет в своем распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать на складе необходимые комплектующие для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.

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

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

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

Рассмотрим их более подробно.

В составе группы администратора БД должны быть:

Ø системные аналитики;

Ø проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;

Ø проектировщики технологических процессов обработки данных;

Ø системные и прикладные программисты;

Ø операторы и специалисты по техническому обслуживанию.

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

Основные функции группы администратора БД

1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса (доступности, секретности) информации, определение потребностей пользователей, определение соответствия «данные—пользователь», определение объемно-временных характеристик обработки данных.

2. Проектирование структуры БД: определение состава и структуры файлов БД и связей между ними, выбор методов упорядочения данных и методов доступа к информации, описание БД на языке описания данных (ЯОД).

3. Задание ограничений целостности при описании структуры БД и процедур обработки БД:

Ø задание декларативных ограничений целостности, присущих предметной области;

Ø определение динамических ограничений целостности, присущих предметной области в процессе изменения информации, хранящейся в БД;

Ø определение ограничений целостности, вызванных структурой БД;

Ø разработка процедур обеспечения целостности БД при вводе и корректировке данных;

Ø определение ограничений целостности при параллельной работе пользователей в многопользовательском режиме.

4. Первоначальная загрузка и ведение БД:

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

Ø разработка технологии проверки соответствия введенных данных реальному состоянию предметной области. База данных моделирует реальные объекты некоторой предметной области и взаимосвязи между ними, и на момент начала штатной эксплуатации эта модель должна полностью соответствовать состоянию объектов предметной области на данный момент времени;

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

5. Защита данных:

Ø определение системы паролей, принципов регистрации пользователей, создание групп пользователей, обладающих одинаковыми правами доступа к данным;

Ø разработка принципов защиты конкретных данных и объектов проектирования; разработка специализированных методов кодирования информации при ее циркуляции в локальной и глобальной информационных сетях;

Ø разработка средств фиксации доступа к данным и попыток нарушения системы защиты;

Ø тестирование системы защиты;

Ø исследование случаев нарушения системы защиты и развитие динамических методов защиты информации в БД.

6. Обеспечение восстановления БД:

Ø разработка организационных средств архивирования и принципов восстановления БД;

Ø разработка дополнительных программных средств и технологических процессов восстановления БД после сбоев.

7. Анализ обращений пользователей БД: сбор статистики по характеру запросов, по времени их выполнения, по требуемым выходным документам

8. Анализ эффективности функционирования БД:

Ø анализ показателей функционирования БД;

Ø планирование реструктуризации (изменение структуры) БД и реорганизации БнД.

9. Работа с конечными пользователями:

Ø сбор информации об изменении предметной области;

Ø сбор информации об оценке работы БД;

Ø обучение пользователей, консультирование пользователей;

Ø разработка необходимой методической и учебной документации по работе конечных пользователей.

10. Подготовка и поддержание системных средств:

Ø анализ существующих на рынке программных средств и анализ возможности и необходимости их использования в рамках БД;

Ø разработка требуемых организационных и программно-технических мероприятий по развитию БД;

Ø проверка работоспособности закупаемых программных средств перед подключением их к БД;

Ø курирование подключения новых программных средств к БД.

11. Организационно-методическая работа по проектированию БД:

Ø выбор или создание методики проектирования БД;

Ø определение целей и направления развития системы в целом;

Ø планирование этапов развития БД;

Ø разработка общих словарей-справочников проекта БД и концептуальной модели;

Ø стыковка внешних моделей разрабатываемых приложений;

Ø курирование подключения нового приложения к действующей БД;

Ø обеспечение возможности комплексной отладки множества приложений, взаимодействующих с одной БД.