Создание базы данных «Грузопоток», которая позволяет быстро и эффективно управлять грузооборотом, вести учет транспортных средств, составлять отчеты для руководителей и различных отделов, страница 7

Рис. 34

                     Восстановление и сжатие Базы данных

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

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

·  Изменяются статистические сведения о таблицах, которые обычно используются в процессе оптимизации запросов, если они в силу каких-то причин не соответствовали текущему состоянию таблиц. Для всех запросов устанавливаются признаки перекомпиляции с тем, чтобы при следующем вызове они были перекомпилированы с учетом изменившихся статистических данных.

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

Сервис – Служебные программы – Сжать и восстановить базу данных.                      

Рис. 35

Операция сжатия базы данных «Грузопоток» будет выполняться регулярно. В Access легко это сделать, т.к. в параметрах системы можно установить флажок CompactOnClose или задать пороговое значение в процентах, и если увеличение размера базы превышает указанный порог, автоматически будет выполнено ее сжатие.

Резервное копирование

Резервное копирование является одним из самых надежных способов защиты данных от потери. При потере данных резервная копия переносится в систему, и пользователи могут снова работать с информацией. Конечно, система будет восстановлена в том состоянии, в котором она была во время создания резервной копии. Если данные обновляются часто, то администратор должен выполнять резервное копирование достаточно часто, чтобы в случае повреждения данных восстановить информацию с наименьшими потерями. Если же данные обновляются редко или вовсе не обновляются, то резервирование может производиться реже. Резервное копирование может выполняться двумя путями: созданием копии файла базы данных и ее архивированием. Создание копии осуществляется стандартными средствами Windows, а архивирование – либо стандартными средствами Windows, либо специальными программами архивирования. Причем для уменьшения места, занимаемого резервной копией, базу данных перед резервированием нужно сжать.

В данном случае администратором будет производиться периодическое резервное копирование БД на приобретенный ранее CD-RW диск.

Триггеры

Триггер – это особый вид процедур, который активизируется при попытке изменения данных в таблице, для которой определен триггер. Физические триггеры являются ни чем иным, как хранимыми процедурами специального типа. Каждый триггер связан с конкретной таблицей и запускается сервером автоматически каждый раз, когда пользователи пытаются произвести вставку, изменение или удаление данных. Триггер получает всю информацию о выполняемых пользователем изменениях в таблице. Разработчик реализовывает в триггер необходимые проверки и изменения данных в других таблицах базы данных.

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

Существует несколько типов триггеров, каждый из которых реагирует на определенный тип изменений данных:

·  INSERT TRIGGER. Триггеры этого типа вызываются при попытке пользователя добавить данные в таблицу, например, с помощью команду INSERT;

·  UPDATE TRIGGER. Этот тип триггеров выполняется при изменении данных с помощью команды UPDATE;

·  DELETE TRIGGER. Этот тип триггеров выполняется при удалении данных с помощью команды DELETE.

Например, для нашей базы данных «Грузопоток» создадим триггер, который будет запрещать всякое изменение столбца KKat, в котором хранится идентификационный номер категории.

Код триггера будет таким:

CREATE TRIGGER zapret_trigger1

          ON Kat WITH ENCRYPTION FOR UPDATE

          AS

          IF UPDATE(KKat)

          BEGIN

          RAISEERROR(‘Изменение идентификационного номера категории запрещено’)

          ROLLBACK TRAN

Или триггер, запрещающий удаление строчек из таблицы Транспорт:

CREATE TRIGGER zapret_trigger2

          ON TRUNS WITH ENCRYPTION FOR DELETE

          AS

          RAISEERROR(‘Удаление запрещено’)

          ROLLBACK TRAN

Репликация

При репликации создается копия базы данных, которая называется репликой. После этого как в оригинал базы данных (который называется основной репликой), так и в реплику могут независимо вноситься различные изменения. Помимо самих изменений, в базе данных (и в реплике) сохраняется информация о моментах времени, когда производились изменения. Затем выполняется операция синхронизации реплики с оригинальной базой данных, которая переносит все изменения из реплики в оригинальной базе с момента создания реплики. Таким образом, после синхронизации оригинальная база данных оказывается в точности в том состоянии, которое бы она имела, если бы все изменения (в том числе изменения, которые делались в реплике) выполнялись непосредственно в оригинальной базе данных.