Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
заготовка курсовой записки ВлГУ1.1.doc
Скачиваний:
19
Добавлен:
21.03.2015
Размер:
4.12 Mб
Скачать
  1. Постановка задачи

2.1 Цели и назначение системы

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

    • 2.2 Перечень функций системы, обеспечивающих достижение целей

  1. Учет выданных займов и их погашений

  2. Хранение информации о клиентах

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

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

  5. Динамическое (по совершение транзакции) обновление данных на рабочих местах сотрудников.

  6. Расчёт графика платежей по займу

2.3 Формы, которые необходимо создать в системе

  1. Анкета клиента

  2. Список клиентов

  3. Договор займа

  4. Список займов

  5. Приходной кассовый ордер

  6. Пользователя системы

  7. Списка пользователей

  8. Списка отчётов

  9. Статистики по выдачам займов

2.4 Отчеты, которые необходимо создать в системе

  1. О выданных, возвращенных, частично возвращенных займах за период (Приложение А)

  2. О невозвращенных займах, переданных на юридическое рассмотрение (Приложение Б)

  3. Об истории выданных займов заёмщику (Приложение В)

2.5 Запросы, которые необходимо создать в системе

  1. Информация о клиенте

  2. Информация о займе

  3. История выдачи займов заёмщику

  4. Выдачи и погашения займов за период

  5. Состояние займов, переданных на юридическое рассмотрение

3 Разработка базы данных

3.1 Перечень документов и функций с атрибутами, которые должны быть отражены в БД

На рисунке 3.1 представлена IDEF1-диаграмма нашей предметной области по выделенным бизнес-процессам и автоматизируемым функциям:

Рисунке 3.1 - IDEF1-диаграмма

3.2 Построение общей схемы БД

На рисунке 3.2 представлена общая схема базы данных:

Рисунке 3.2 - схема БД

3.3 Построение подсхем БД

3.4 Построение XML-структуры БД по разработанной общей схеме

4 Средства и инструменты защиты баз данных

4.1 Определение ролей БД и их прав доступа к объектам БД

Приводится описание политики безопасности для доступа к объектам БД. Приводится код программы с настройкой ролей в БД и прав доступа для них.

4.2 Управление учетными записями пользователей БД

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

4.3 Анализ данных, попадающий под действий закона о персональных данных

Наша компания являющаяся субъектом персональных данных - несет ответственность за защиту персональных данных субъекта в соответствии с Федеральный закон Российской Федерации N 152-ФЗ.

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

Перечень обрабатываемой информации:

  • Фамилия, имя, отчество,

  • Год, месяц, дата и место рождения, 

  • Адрес, семейное, социальное, имущественное положение, образование, профессия, доходы,

  • Другая информация (см. ФЗ-152, ст.3);

В общедоступные источники персональных данных (адресные книги, списки и другое информационное обеспечение) с письменного согласия физического лица могут включаться его фамилия, имя, отчество, год и место рождения, адрес, абонентский номер и иные персональные данные (см. ФЗ-152, ст.8).

Персональные данные относятся к информации ограниченного доступа и должны быть защищены в соответствии с законодательством РФ.

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

4.4. Порядок резервирования и восстановления БД

Возможность в любой момент восстановить базу данных из рабочей копии – существенная часть обеспечения непрерывности рабочего процесса. Целостность и возможность к восстановлению являются важной частью задач управления ИТ.

Внимание уделим технологиям и возможностям выбранной нами реляционной СУБД Microsoft SQL Server 2012.

Комплексный план резервного копирования:

  • Решить, что нужно копировать.  Администратор СУБД решает, какие базы данных, а также связанные с ними операционные системы и приложения необходимо копировать. Перечень того, что должно быть зарезервировано,

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

  • СУБД. Необходимо также создавать резервную копию СУБД после всех изменений и обновлений,

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

Пароли. Все пароли superuser, которые могут понадобиться во время восстановления, должны храниться в надежном и доступном месте. Рекомендуется убедиться, что пароль, который был предоставлен по умолчанию во время установки СУБД, был изменен;

  • СУБД MS SQL сервер:

  • Необходимо создавать резервные копии как системной, так и пользовательских БД,

  • Отдельный план технического обслуживания системных БД, т.е. мастер, модель, MSDB. Мастер поддерживает только полные резервные копии, резервирование tempdb не требуется, так как она перестраивается при запуске SQL сервер,

  • Создавать резервные копии всех пользовательских БД. Настроить все пользовательские базы данных на работу в режиме полного восстановления, и копировать как БД, так и “логи” транзакций, 

Принятие решения о месте хранения резервных копий. MS SQL могут писать свои резервные копии напрямую на диск (локально или по сети), а затем эти копии могут быть записаны на ленточный архив. Хорошей практикой считается записывать резервные копии на диск, дублировать их на ленты и хранить эти копии в разных зданиях для большей гарантии восстановления в случае чрезвычайной ситуации.

Для осуществления данной операции необходимо выполнить скрипт создания резервной копии (приложение 1 (.sql)):

BACKUP DATABASE [DB_LOANS]

TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backup\DB_LOANS.bak'

WITH RETAINDAYS = 1, NOFORMAT, NOINIT, NAME = N'DB_LOANS-Полная База данных Резервное копирование',

SKIP,

NOREWIND,

NOUNLOAD,

NO_COMPRESSION,

STATS = 10,

CHECKSUM

GO

declare @backupSetId as int

select @backupSetId = position from msdb..backupset

where database_name=N'DB_LOANS'

and backup_set_id=(select max(backup_set_id)

from msdb..backupset where database_name=N'DB_LOANS' )

if @backupSetId is null begin raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "DB_LOANS" не найдены.', 16, 1) end

RESTORE VERIFYONLY

FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backup\DB_LOANS.bak'

WITH FILE = @backupSetId, NOUNLOAD, NOREWIND

GO

Комплексный план восстановления из резервных копий:

Администратор должен сформулировать детальную стратегию действий:

  • Тестирование восстановления. Должно быть прописано требование к тестированию возможности восстановления с дисков, 

  • Проверка восстановления, где возможно. Администратор может проверить резервные копии не выполняя процедуру восстановления. Команда «проверка восстановления БД» (restore validate database) выполнит все действия, кроме самого восстановления. Это лучший метод определения работоспособности резервных копий, до того как ситуация не стала критической,

  • Развертывание тестовых баз из резервных копий продуктивных баз. Это хорошая практика – периодически производить восстановление БД в непродуктивной среде из резервных копий продуктивных баз данных,

  • Выполнение тестирования восстановления баз данных из резервной копии раз в 1-2 года в рамках проведения аудита. Администратор должен рассказать процесс восстановления, а также показать логи и скриншоты процедуры восстановления,

  • Фактические восстановления. Во время фактических восстановлений, администратор должен создать резервную копию БД перед процедурой восстановления. В зависимости от типа потери данных и наличия актуальной резервной копии, администратор принимает решение о полном восстановлении с частичной потерей данных, либо о частичном восстановлении.

Для осуществления данной операции необходимо выполнить скрипт восстановления из резервной копии (приложение 2 (.sql)):

RESTORE DATABASE [DB_LOANS] FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backup\DB_LOANS.bak'

WITH FILE = 1,

NOUNLOAD,

STATS = 10

GO

Данная информация была взята с сайта: http://www.4by4.ru/ru/analytics/db_recovery_bestpractice