ГЛАВА 10 Стый Ьаш дзнньи

Отслеживание рация системных событий

В большинстве случаев доступом к данным

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

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

Если нужно всего лишь знать, кто и когда работал с системой, то скорее всего, одной сущности с атрибутами U-erNnrntiOauHnHR пользователя), LogOn (Время регистрации в системе) и 1одОДВремя завершения работы с системой) достаточно. При регистрации пользователя в системе создана новая запись, которая затем

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

данных, то вы можете использовать первичную сущность с двумя дополнительными атрибутами: Сгедгей?%(Пользователь, создавший запись) и Created On (Дата создания записи).

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

ретить удалять записи, а операцию удаления записей

заменить установкой флага Deleted (Удалена) для соответствующей записи. Информацию о том, кто и когда удалил запись, можно сохранить, добавив атрибуты DeletedВг (Пользователь, удаливший запись) и DeletedOn (Дата удаления записи). Этот метод подойдет, и если нужно скопировать записи в архивный файл перед удалением их из базы данных,

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

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

2 баз

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

Реализуя любую из описанных выше возможностей отслеживания событий при помоши механизма баз данных Microsoft Jet, запретите пользователям прямой доступ к таблицам, поскольку он позволяет обойти все механизмы зашиты данных. Для SQL Server запрещать

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

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

Мой опыт подсказывает, что в большинстве случаев регистрация системных событий - это одна из форм страховки от потери и порчи данных, и записанная в соответствующие файлы, будет

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

Системные администраторы могут использовать интерфейс Access

или SQL Server Enterprise Manager для доступа к данным и выполнения необходимых действий.

Итоги

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

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

ГЛАВА 10 Скзт базы данных

сети. Или же данные размещены на сетевом ресурсе, но доступ к ним имеет только один пользователь. Приложения, реализованные на основе механизма баз данных Microsoft Jet, в которгх пользователи обращаются к данным через сеть, также являются одноуровневыми с логической точк ия, однако доступ к данным в этом случае имеют несколько пользователей, которые могут работать с базой данных одновременно.

Двухуровневые, или клиент-серверные, приложения можно реализовать на основе SQL Server. Для этой архитектуры характерно распределение операций по обработке и поддержке данных между клиентской рабочей станцией и сервером. Сервер выполняет операции манипулирования с данными, а клиентский компьютер - все операции взаимодействия с пользователем. Принципы, положенные в основу двухуровневой архитектуры, можно развить, увеличивая число уровней и, соответственно, число компьютеров, на которых размешаются компоненты этих уровней.

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

это индексы и запросы, которые создаются в проектируемой базе данных.

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

Следующая глава будет посвящена документированию разработки системы и представлению результатов проектирования заказчику и

разработчикам, которые будут работать над ее созданием.