Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПЛЕЩ.docx
Скачиваний:
47
Добавлен:
13.05.2015
Размер:
3.97 Mб
Скачать

1.3.4. Порядок взаимодействия пользователя, субд и ос

Приведем порядок взаимодействия пользователя, СУБД и ОС при обработке запроса на получение данных (рисунок 1.3.4.1, содержание данного пункта скопировано из работы [19]).

Рисунок 1.3.4.1. Схема взаимодействия пользователя, СУБД и ОС

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

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

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

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

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

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

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

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

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

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

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

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

1.3.5. Поддержка целостности базы данных

Выделяют четыре вида поддержки целостности базы данных (содержание данного пункта скопировано из работы [19]).

1. Поддержка структурной целостности, которая трактуется как то, что реляционная СУБД (системы управления реляционными базами данных, представляющих совокупность взаимосвязанных двумерных таблиц) должна допускать работу только с однородными структурами данных типа «реляционное отношение» (п.1.3.8.1) или двумерная таблица.

В дополнение к структурной целостности необходимо рассмотреть проблему неопределенных Null значений. Неопределенное значение интерпретируется в реляционной модели как значение, неизвестное на данный момент времени. Это значение при появлении дополнительной информации в любой момент времени может быть заменено на некоторое конкретное значение. При сравнении неопределенных значений не действуют стандартные правила сравнения: одно неопределенное значение никогда не считается равным другому неопределенному значению. Для выявления равенства значения некоторого атрибута неопределенному применяют специальные стандартные предикаты:

<имя атрибута>IS NULL и <имя атрибута> IS NOT NULL.

Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL – FALSE (Ложь), в противном случае предикат IS NULL принимает значение FALSE, а предикат IS NOT NULL принимает значение TRUE.

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

Логическое выражение> IS {TRUE | FALSE | UNKNOWN}

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

3. Поддержка ссылочной целостности (Declarative Referential Integrity, DRI). Ссылочная целостность обеспечивает поддержку непротиворечивого состояния БД в процессе модификации данных при выполнении операций добавления или удаления.

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

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

Пример.Блокировка ввода записи дочернего объекта “СОТРУД­НИК”, ес­ли указывается значение атрибута “Код подразде­ле­ния”, отсут­ствую­ще­го в родительском объекте “ПОДРАЗДЕЛЕНИЕ”.

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

Пример.После изменения в родительском объекте “ПОДРАЗДЕЛЕ­НИЕ” значения атрибута “Код подразделения” с 2 на 202 автоматически из­ме­нят­ся в дочернем объекте “СОТРУДНИК” все записи со значением атрибута “Код подразделения”, равным 2, на новое значение 202 (все сотрудники из подразделения с кодом 2 переведутся в подразделение с новым кодом 202). Если такой перевод не может быть реальным, то можно установить правило блокировки корректировки, что не позволит изменить код под­раз­де­ления в объекте “ПОДРАЗДЕЛЕНИЕ” на новое значение, если есть сот­руд­ники в данном подразделении.

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

Пример.После удаления в родительском объекте “ПОДРАЗДЕЛЕ­НИЕ” записи со значением атрибута “Код подразделения”, равным 201, авто­матически удаляются в дочернем объекте “СОТРУДНИК” все записи со значением атрибута “Код подразделения”, равным 201 (все сотрудники из подразделения с кодом 201 увольняются). Если такого расфор­миро­ва­ния подразделения не может быть, то устанавливают правило блокировки каскадного удаления записей. Это не позволит удалить запись с кодом под­раз­де­ления в объекте “ПОДРАЗДЕЛЕНИЕ”, равным значению 201 (снача­ла нужно удалить все записи из объекта “СОТРУДНИК” со значением атри­бута “Код под­раз­де­ле­ния”, равным 201, а затем удалить запись в ро­ди­тельском объекте “ПОД­РАЗДЕЛЕНИЕ” со значением атри­бута “Код подразделения”, равным 201).

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

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

Семантическая поддержка может быть обеспечена двумя путями: декларативным и процедурным путем.

Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего «бизнес-правилами» (Business Rules) или декларативными ограничениями целостности.

Выделяются следующие виды декларативных ограничений целостности.

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

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

Ограничения целостности, задаваемые на уровне отношения.

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

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