- •Аннотация
- •Содержание
- •Введение
- •Безопасность.
- •Индексы.
- •Руководство пользователя (администратора).
- •1. Описание предметной области
- •2. Проектирование базы данных
- •2.1. Схема базы данных
- •2.2. Концептуальное проектирование
- •2.3. Обоснование нормализации (3нф)
- •3. Создание базы данных
- •4. Создание таблиц и ограничений целостности
- •5. Заполнение таблиц данными
- •6. Объекты промежуточного слоя
- •6.1. Пользовательские функции (udf)
- •6.2. Представления (Views)
- •6.3. Хранимые процедуры и подсистема xml
- •7. Стратегия резервного копирования
- •Часть 4: стратегия резервного копирования
- •8. Безопасность
- •8.1. Уровни аутентификации и авторизации
- •8.2. Ролевая модель разграничения доступа
- •8.3. Тестирование системы безопасности
- •9. Индексы
- •9.1. Кластеризованные индексы
- •9.2. Некластеризованные индексы
- •10. Руководство пользователя (администратора)
- •10.1. Установка и развертывание системы
- •10.2. Сценарии работы с данными
- •Заключение
- •Список используемых источников
- •Приложение а
- •Часть 1: оптимизация (индексы)
- •Часть 2: безопасность (без dbo)
- •Часть 3: ролевая модель (schema permissions)
- •Часть 4: стратегия резервного копирования
4. Создание таблиц и ограничений целостности
Физическая реализация структуры базы данных выполнена с использованием языка DDL (Data Definition Language) диалекта Transact-SQL. Создание объектов производилось скриптом, обеспечивающим строгий порядок выполнения: сначала создаются схемы, затем справочные таблицы, и в конце — зависимые таблицы с данными.
Организация схем (Schemas)
Для логического разделения объектов базы данных и упрощения администрирования прав доступа, вместо использования стандартной схемы dbo по умолчанию, была спроектирована структура из двух пользовательских схем:
Схема [Ref] (Reference) — предназначена для хранения условно-постоянной, справочной информации. В эту схему помещены таблицы Manufacturers, Categories, PackageTypes и SimulationTypes. Такое выделение позволяет в дальнейшем защитить справочники от случайного изменения, предоставив права на запись в эту схему только администраторам.
Схема [Stock] — предназначена для хранения основных оперативных данных системы. Сюда входят таблицы Components, ComponentParams и ComponentModels.
При создании таблиц внутри этих схем были использованы следующие механизмы обеспечения целостности данных [7]:
Первичные ключи (PRIMARY KEY):
Каждая таблица имеет суррогатный первичный ключ целочисленного типа (INT). Это гарантирует уникальность каждой записи и ускоряет операции соединения таблиц.
Пример: CONSTRAINT PK_Components PRIMARY KEY (ComponentID)
Внешние ключи (FOREIGN KEY):
Для реализации связей между таблицами используются ограничения внешнего ключа. Они обеспечивают ссылочную целостность между схемами [Stock] и [Ref], запрещая добавление компонента с несуществующим производителем.
Пример: CONSTRAINT FK_Components_Manufacturers FOREIGN KEY (ManufacturerID) REFERENCES [Ref].Manufacturers (ManufacturerID)
Автоинкремент (IDENTITY):
Для всех первичных ключей используется свойство IDENTITY(1,1). Это перекладывает задачу генерации уникальных идентификаторов на СУБД, освобождая клиентское приложение от необходимости вычислять следующий свободный номер.
Каскадное удаление (ON DELETE CASCADE):
Для таблиц детализации (ComponentParams, ComponentModels) в схеме [Stock] настроено каскадное удаление. Это означает, что при удалении записи о компоненте из главной таблицы, СУБД автоматически удалит все связанные с ним параметры и модели.
5. Заполнение таблиц данными
Первичное наполнение базы данных информацией производится с помощью специализированного SQL-скрипта. Данный процесс необходим для демонстрации работоспособности системы, тестирования хранимых процедур и проверки корректности формирования отчетов.
Процесс загрузки данных разделен на три последовательных этапа:
Предварительная очистка и сброс счетчиков
Перед загрузкой новых данных выполняется полное удаление всей существующей информации из таблиц. Это гарантирует отсутствие дубликатов и конфликтов при повторном развертывании системы.
Удаление производится в строгом порядке: сначала очищаются таблицы с зависимыми данными (параметры, модели), а затем — родительские справочники.
Для всех таблиц выполняется команда сброса счетчиков автоинкремента (DBCC CHECKIDENT). Это позволяет начинать нумерацию записей (ID) с единицы при каждой новой установке базы данных.
Заполнение справочной информации (Схема [Ref])
На этом этапе в базу данных загружаются статические классификаторы, необходимые для работы системы:
Список производителей электроники (таблица Manufacturers);
Категории компонентов (таблица Categories);
Типы корпусов и стандарты моделей моделирования.
Данные вводятся прямыми командами вставки, так как они являются фундаментальными для предметной области.
Заполнение основных данных (Схема [Stock])
Загрузка информации о конкретных электронных компонентах выполняется с использованием метода динамического поиска идентификаторов.
В скрипте не используются жестко прописанные числовые коды (например, ManufacturerID = 1), так как при изменении порядка загрузки справочников эти коды могут измениться. Вместо этого применяется вложенный запрос, который находит нужный идентификатор по текстовому названию:
INSERT INTO [Stock].[Components] (PartNumber, ManufacturerID, CategoryID, PackageID, Description, IsActive)
VALUES
-- --- Микроконтроллеры ---
(N'STM32F103C8T6',
(SELECT ManufacturerID FROM [Ref].[Manufacturers] WHERE Name = 'STMicroelectronics'),
(SELECT CategoryID FROM [Ref].[Categories] WHERE Name = 'Микроконтроллеры'),
(SELECT PackageID FROM [Ref].[PackageTypes] WHERE Name = 'LQFP-48'),
N'Популярный ARM Cortex-M3 MCU', 1),
Такой подход обеспечивает ссылочную целостность и устойчивость скрипта к изменениям. Всего в базу данных загружается расширенный набор тестовых записей (более 20 позиций), включающий различные типы компонентов (микроконтроллеры, резисторы, транзисторы) и их технические параметры, что позволяет в дальнейшем продемонстрировать эффективность работы индексов и аналитических отчетов.
