|
Программирование >> Проектирование баз данных
рекомендации по архивации Как мы говорили выше, не следует предполагать, что архивация - легкая задача. Если вы задержались на этой работе дольше, чем на предыдущих, не рассчитывайте, что уйдете задолго до того, как архивация поднимет свою грозную голову! Подводя итоги, хочется дать вам следующие рекомендации; Планируйте архивацию с самого начала проекта. Выполняйте архивацию по сущностям, а не по таблицам. Если одной сущности соответствуют две таблицы, их следует архивировать в одной операции. Особенно тщательно следует учитьгеать влияние ссылочной целостности. Нельзя оставлять в базе данных беспризорные строки, архивируя родительские строки и забывая о дочерних - необходимо определять архивные группы связанных таблиц. Если используются файлы, то следует обеспечить хорошее описание формата (по сути дела, использовать файлы-отчеты). Реализуйте архивацию в рамках главного приложения, а тестируйте - в рамках приемо-сдаточных испытаний всего комплекта. Аудит Что такое аудит и как он связан с безопасностью? Аудит - это действия, позволяющие определить, кто что делал в системе и имел ли он право на эти действия. Обеспечение безопасности имеет целью, прежде всего, помешать пользователям делать недопустимые вещи. В любой системе, которая обслуживает денежные операции (например, в системе, где ведутся записи о ссудах), средства аудита и безопасности должны гарантировать надежную защиту информации. Конечно, очень хорошо, если надежность такой защиты будет стопроцентной. Хотя аудит и безопасность взаимосвязаны, эти задачи реализуются отдельно. Под термином аудит в информационных технологиях часто подразумевают ведение журнала аудита. Журнал аудита - это специальный набор записей, создаваемых системой, который надежно защищен от несанкционированного доступа. Иногда эти понятия используют как синонимы. Однако мы постарались быть точными и применяем термин журнал аудита , когда говорим о ведении записей, а термин аудит - когда имеем в виду Использование журнала аудита для реализации функции генерации отчетов. Основное назначение журнала аудита - выступать в роли средства. Позволяющего обнаружить действия, которые могут нарушить целостность Системы. Другими словами, с его помощью мы можем выявить как мошеннически введенные данные, так и несанкционированные запросы. (Почему-fo во многих организациях уделяют одной из этих задач больше внимания, Чем другой.) Что содержит журнал аудита? Какую информацию должна записывать система в журнал аудита? Теоретически кандидатом на регистрацию является любое происходящее в системе событие. Особенно важны для аудита вход в систему и выход из системы, а также обновление данных. Аудит запросов несколько затруднен, если запросы производятся не через хранимые процедуры, поскольку средства аудита можно встроить в сами процедуры. В больщинстве организаций регистрируются все случаи входа в систему и сообщается о всех входах в систему, которые выполнены в нерабочее время или посредством коммутируемого доступа (если их можно отличить). Можно создать отдельную запись для всех финансовых операций, в ходе которых деньги отправлялись из системы. Один из способов реализации этого - случайный выбор счетов или событий и их сверка с принимающей системой на предмет того, не нарущается ли баланс в бухгалтерских книгах. Другой способ - выбор всех операций с большими суммами. Конечно, все обнаруживаемые в процессе аудита операции уже свершились. Как мы говорили, аудит неразрывно связан с безопасностью. Лучше предотвратить мошенничество или нарушение защиты путем введения жестких правил безопасности, чем затем, когда дело уже сделано, обнаруживать это средствами аудита. В некоторых организациях средства аудита также используются для измерения объема документооборота и производительности подразделений и отдельных сотрудников. Например, по журналу аудита можно обнаружить, что заказ был впервые зарегистрирован в системе 21 апреля (из CRE-ATED DT для ORDERS), но товары не отгружались до 14 июня (из CRE-ATED DT для DISPATCHES). Определив среднее значение времени выполнения заказа, менеджеры могут сделать выводы о производительности труда. Однако нам кажется, что это опасная практика. Часто существуют вполне обоснованные причины того, почему ввод данных откладывается и не соответствует дате, когда произошло событие. Если необходимо определить статистические показатели работы, то в таблице должны быть столбцы (отдельные от столбцов аудита) для записи соответствующей информации (например, дат отгрузки). Простейшая форма журнала аудита Рассмотрим простейшее решение задачи аудита. В данном примере мЫ полагаем, что нас интересует только регистрация доступа к данным - в частности, сведения о том, кто создал каждую строку и кто последним изменил каждую строку (если это имело место). Для большинства наших таблиц мы можем добавить четыре столбца: created by VARCHAR2(30) NOT NULL created dt DATE NOT NULL updated by VARCHAR2{30) updated dt DATE Эти столбцы заполняются автоматически при помощи триггеров на таблице: CREATE OR REPLACE TRIGGER tl bir BEFORE INSERT ON tl FOR EACH ROW BEGIN . new. created by := USER; :new.created dt := SYSDATE; END tl bir; CREATE OR REPLACE TRIGGER tl bur BEFORE UPDATE ON tl FOR EACH ROW BEGIN :new.updated by := USER; ;new.updated dt := SYSDATE; END tl bir; При использовании этой формы журнала из аудита обычно исключаются таблицы с постоянными справочными данными - вероятно, считается, что время изменения таких данных не имеет значения. Как-то одному из нас сказали, что журналы аудита для таких данных не нужны, потому что эти данные редко изменяются . Мы сразу же спросили, откуда нащ собеседник знает это, не имея журнала аудита. Вразумительного ответа на свой вопрос мы не получили. Вместо триггера BEFORE INSERT можно использовать фразы DEFAULT для столбцов CREATED BY и CREATED DT. Это рещение очень просто реализовать, и оно не слишком дорого с точки зрения затрат периода выполнения и дополнительной памяти в базе данных. Еще одно преимущество аудита этого уровня состоит в том, что вся информация хранится в обыкновенных таблицах. Это облегчает выполнение аудиторских запросов к данным, например, запросов на получение общей стоимости заказа для каждого его создателя. Каковы же недостатки? Давайте разберем их по отдельности. 1. По этим столбцам можно определить только создателя и последнего, кто изменил строку. Все следы промежуточных изменений навсегда исчезают. 2. Можно увидеть, кто последним изменил строку и когда он это сделал, но нельзя понять, какие столбцы были изменены. Мы не можем узнать, был ли обновлен столбец состояния заказа или же изменилась сумма (или и то, и другое). 3. Можно увидеть, кто создал строку и кто последним обновил ее, но если строка удалена, то все ее следы исчезают (включая сведения о создании и изменении).
|
© 2006 - 2024 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки. |