Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
21-30.doc
Скачиваний:
1
Добавлен:
01.03.2025
Размер:
174.08 Кб
Скачать
  1. Создание прототипа БД и его отладка. Отладка подразумевает проверку правильности функционирования процедурных объектов БД (триггеры, процедуры, функции). Прототип позволяет определить жизнеспособность проекта БД и выявить его недостатки, что может потребовать внесения изменений в проект. Прототип также нужен как база для разработчиков приложений. Для этого БД наполняется реальными или тестовыми данными.

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

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

  4. Тестирование работы базы данных и аис в целом. Различают такие виды тестов, как:

  • автономные – тесты отдельных модулей;

  • тесты связей – тесты между модулями;

  • регрессивные – тесты на проверку уже автономные – тесты отдельных модулей;

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

  • нагрузочные – тесты на проверку времени реакции системы в рабочем режиме или определение производительности системы;

  • системные – тесты на проверку функционирования системы в целом;

  • приёмо-сдаточные – тесты, которые проводятся при сдаче системы (АИС) в эксплуатацию.

  1. Эксплуатация и сопровождение созданной аис. Здесь можно выделить ряд задач:

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

  • Необходимо выполнять резервное копирование данных, чтобы предотвратить их потерю в случае серьёзного сбоя или ошибки пользователя.

  • Сопровождение АИС обычно включает периодические проверки выполнения системных ограничений (на объём данных и время реакции системы). В результате этих проверок удаляются устаревшие данные (если не предусмотрено автоматическое архивирование данных). Улучшение показателей производительности системы может быть достигнуто за счёт настройки СУБД, которая выполняется администратором базы данных.

Вопрос 22. Два уровня защиты данных в Interbase. Управление парольной защитой и виды паролей.

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

Безопасность InterBase основана на концепции "пользователя" (user). Безопасность всей базы данных, в сущности, зависит от проверки подлинности идентификатора пользователя. Информация о пользователях, зарегистрированных для конкретного сервера InterBase, хранится в особой базе данных безопасности(security database) - ADMIN.IB. Для каждого сервера InterBase существует своя собственная база данных безопасности, таким образом, пользователь "привязан" к конкретному серверу. Пользователь с таким же именем может существовать на нескольких серверах, но для этого информация о нем должна быть заведена на каждом из серверов. В базе данных безопасности также для каждого пользователя хранится зашифрованное значение пароля. Пользователь, авторизованный на сервере, имеет доступ ко всем базам данных этого сервера.

Имя пользователя может состоять максимум из 31 символа, при этом их регистр не учитывается. Пароль может состоять максимум из 8 символов (если ввести больше, лишние символы игнорируются), регистр - учитывается.

Механизм логина на сервере следующий - клиентская часть, принимая пароль пользователя, шифрует его алгоритмом DES с потерей данных, после чего передает зашифрованный пароль на сервер. Сервер, приняв пароль, шифрует его еще раз тем же алгоритмом, и сравнивает со строкой, хранящейся в таблице users базы isc4.gdb. Т.е. пароль никогда не дешифруется в исходный вид, и это сделать невозможно. Даже перехватив "полузашифрованный" пароль на этапе его пересылки с клиента на сервер единственным способом "взлома" остается только прямой подбор пароля.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]