курсач / Наволоцкий_1302_v2

8. БЕЗОПАСНОСТЬ

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

Главной особенностью разработанного решения является отказ от использования стандартной схемы dbo и назначение прав доступа на уровне пользовательских схем (Schema-Level Permissions). Это значительно упрощает администрирование: новые объекты, добавляемые в схему, автоматически наследуют права доступа, установленные для этой схемы [3].

8.1. Уровни аутентификации и авторизации

Система безопасности построена по иерархическому принципу:

аутентификацию (проверку пароля) при подключении к экземпляру SQL

Server.

2.Уровень базы данных (Users): Логинам сервера сопоставлены пользователи базы данных Manager и Engineer.

3.Уровень ролей и схем (Roles & Schemas): Права доступа назначаются не пользователям напрямую, а ролям базы данных, в которые включаются пользователи.

8.2. Ролевая модель разграничения доступа

В системе реализованы две функциональные роли с четко

Предназначена для сотрудников, занимающихся аналитикой.

a. Права: Предоставлено право SELECT на схемы [Stock] и [Ref].

42

b.Ограничения: Полный запрет на изменение данных. Пользователь не имеет прав INSERT, UPDATE, DELETE ни на одну таблицу, а

также не может запускать процедуры модификации.

2.Роль «Инженер» (Role_ComponentEditor)

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

a.Права:

i.EXECUTE ON SCHEMA::[Stock] — разрешает выполнение всех хранимых процедур в оперативной схеме (поиск,

создание, импорт).

ii.SELECT ON SCHEMA::[Ref] — разрешает чтение справочников (необходимо для работы выпадающих списков и процедур поиска).

b.Принцип наименьших привилегий: Инженеру не выданы прямые права на вставку или удаление записей в таблицах (GRANT INSERT/DELETE). Все изменения осуществляются строго через хранимые процедуры, что гарантирует прохождение всех проверок бизнес-логики и транзакционную целостность.

8.3. Тестирование системы безопасности

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

Сценарий теста:

2.Предпринята попытка выполнить деструктивное действие — удаление справочной таблицы [Ref].[Manufacturers].

3.Предпринята попытка вызвать процедуру создания компонента,

доступную только инженерам.

43

Результат:

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

Рисунок 7 – Демонстрация отказа в доступе при попытке удаления таблицы пользователем с ограниченными правами

44

9. ИНДЕКСЫ

Для обеспечения высокой производительности системы при росте объема данных была разработана стратегия индексации [10]. Проектирование индексов выполнялось на основе анализа планов выполнения (Execution Plans)

типовых запросов, используемых в хранимых процедурах и представлениях.

В базе данных «CircuitDB» реализованы три типа индексов:

9.1. Кластеризованные индексы

Создаются автоматически при определении ограничений первичного ключа (PRIMARY KEY). В таблице [Stock].[Components] данные физически упорядочены на диске по полю ComponentID. Это обеспечивает максимально быстрый доступ к строке при выборке по идентификатору.

9.2. Некластеризованные индексы

Для оптимизации поиска по неключевым полям были созданы дополнительные структуры B-деревьев:

1.Уникальный индекс по артикулу (IX_Components_PartNumber)

a.Цель: Оптимизация процедуры поиска usp_SearchComponents и

контроль целостности.

b.Обоснование: Поле PartNumber является основным критерием поиска для пользователей. Без индекса СУБД вынуждена выполнять полное сканирование таблицы, просматривая каждую строку. Создание индекса позволяет использовать операцию поиска по индексу.

c.Особенность: Индекс объявлен как UNIQUE, что создает дополнительное логическое ограничение, запрещая вставку дубликатов.

2.Покрывающий индекс (IX_Components_ManufacturerID_Includes)

45

a.Цель: Ускорение формирования отчетов и операций соединения

(JOIN).

b.Обоснование: Большинство аналитических запросов (например,

c.Особенность (Покрывающий индекс): В индекс, помимо ключа,

включены неключевые поля — IsActive и CategoryID.

i.Эффект: Это позволяет SQL Server извлекать все необходимые данные непосредственно из индекса, не обращаясь к основной таблице. Это снижает нагрузку на дисковую подсистему ввода-вывода.

46

10. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ (АДМИНИСТРАТОРА)

Так как информационная система реализована на уровне базы данных,

взаимодействие с ней осуществляется через среду SQL Server Management

Studio.

10.1. Установка и развертывание системы

Для установки системы на сервер разработан пакет SQL-скриптов,

обеспечивающий автоматизированное развертывание всех компонентов.

Порядок установки:

1.Запустить Microsoft SQL Server Management Studio.

2.Подключиться к целевому серверу (SQLExpress).

3.Последовательно открыть и выполнить файлы скриптов в строгом порядке нумерации:

a.01_CreateStructure.sql — Создание базы данных, схем [Ref] и [Stock], таблиц.

b.02_InsertData.sql — Первичное наполнение справочников и тестовых данных.

e.05_SecurityAndAdmin.sql — Настройка пользователей, прав доступа и индексов.

После успешного выполнения всех скриптов в Обозревателе объектов

появится база данных «CircuitDB» с настроенной структурой.

47

Рисунок 8 – Структура базы данных после успешной установки

Средства автоматизации

В дополнение к ручному режиму, для администратора системы разработаны пакетные командные файлы (Batch scripts), использующие утилиту командной строки sqlcmd [6]:

Install_DB.bat: Выполняет автоматическое развертывание системы «в

один клик», последовательно запуская все скрипты (01–05).

48

AutoBackup.bat: Предназначен для настройки регулярного автоматического резервного копирования через Планировщик заданий

Windows (Task Scheduler).

10.2. Сценарии работы с данными

Взаимодействие с системой осуществляется путем вызова хранимых процедур и обращением к представлениям. Ниже описаны основные пользовательские сценарии.

Поиск и фильтрация компонентов

Для поиска информации используется

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

Рисунок 9 – Результат выполнения поискового запроса

49

Аналитика и отчетность

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

Сводный отчет (v_FullComponentReport): Консолидирует данные из оперативной таблицы и всех справочников, предоставляя человекочитаемое описание компонентов (вместо числовых ID) и их текущий статус.

Инженерный фильтр (v_ActiveComponentsSpiceready): Автоматически отбирает только те компоненты, которые находятся в производстве и имеют прикрепленную математическую модель SPICE, что необходимо для задач моделирования.

Управленческая аналитика (v_CategoryAnalytics): Использует обобщенные табличные выражения (CTE) для расчета статистики наполненности склада. Отчет показывает общее количество номенклатуры по каждой категории и вычисляет процент активных компонентов.

Все отчеты формируются динамически в момент запроса. Для подтверждения актуальности данных в каждую выборку добавлена метка времени сервера (ReportTime). Результат представлен на рисунке 10.

50