Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
курсач / Наволоцкий_1302_v2.docx
Скачиваний:
0
Добавлен:
27.12.2025
Размер:
2.47 Mб
Скачать

4. Создание таблиц и ограничений целостности

Физическая реализация структуры базы данных выполнена с использованием языка DDL (Data Definition Language) диалекта Transact-SQL. Создание объектов производилось скриптом, обеспечивающим строгий порядок выполнения: сначала создаются схемы, затем справочные таблицы, и в конце — зависимые таблицы с данными.

Организация схем (Schemas)

Для логического разделения объектов базы данных и упрощения администрирования прав доступа, вместо использования стандартной схемы dbo по умолчанию, была спроектирована структура из двух пользовательских схем:

  1. Схема [Ref] (Reference) — предназначена для хранения условно-постоянной, справочной информации. В эту схему помещены таблицы Manufacturers, Categories, PackageTypes и SimulationTypes. Такое выделение позволяет в дальнейшем защитить справочники от случайного изменения, предоставив права на запись в эту схему только администраторам.

  2. Схема [Stock] — предназначена для хранения основных оперативных данных системы. Сюда входят таблицы Components, ComponentParams и ComponentModels.

При создании таблиц внутри этих схем были использованы следующие механизмы обеспечения целостности данных [7]:

  1. Первичные ключи (PRIMARY KEY):

Каждая таблица имеет суррогатный первичный ключ целочисленного типа (INT). Это гарантирует уникальность каждой записи и ускоряет операции соединения таблиц.

    1. Пример: CONSTRAINT PK_Components PRIMARY KEY (ComponentID)

  1. Внешние ключи (FOREIGN KEY):

Для реализации связей между таблицами используются ограничения внешнего ключа. Они обеспечивают ссылочную целостность между схемами [Stock] и [Ref], запрещая добавление компонента с несуществующим производителем.

    1. Пример: CONSTRAINT FK_Components_Manufacturers FOREIGN KEY (ManufacturerID) REFERENCES [Ref].Manufacturers (ManufacturerID)

  1. Автоинкремент (IDENTITY):

Для всех первичных ключей используется свойство IDENTITY(1,1). Это перекладывает задачу генерации уникальных идентификаторов на СУБД, освобождая клиентское приложение от необходимости вычислять следующий свободный номер.

  1. Каскадное удаление (ON DELETE CASCADE):

Для таблиц детализации (ComponentParams, ComponentModels) в схеме [Stock] настроено каскадное удаление. Это означает, что при удалении записи о компоненте из главной таблицы, СУБД автоматически удалит все связанные с ним параметры и модели.

5. Заполнение таблиц данными

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

Процесс загрузки данных разделен на три последовательных этапа:

  1. Предварительная очистка и сброс счетчиков

Перед загрузкой новых данных выполняется полное удаление всей существующей информации из таблиц. Это гарантирует отсутствие дубликатов и конфликтов при повторном развертывании системы.

    1. Удаление производится в строгом порядке: сначала очищаются таблицы с зависимыми данными (параметры, модели), а затем — родительские справочники.

    2. Для всех таблиц выполняется команда сброса счетчиков автоинкремента (DBCC CHECKIDENT). Это позволяет начинать нумерацию записей (ID) с единицы при каждой новой установке базы данных.

  1. Заполнение справочной информации (Схема [Ref])

На этом этапе в базу данных загружаются статические классификаторы, необходимые для работы системы:

    1. Список производителей электроники (таблица Manufacturers);

    2. Категории компонентов (таблица Categories);

    3. Типы корпусов и стандарты моделей моделирования.

Данные вводятся прямыми командами вставки, так как они являются фундаментальными для предметной области.

  1. Заполнение основных данных (Схема [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 позиций), включающий различные типы компонентов (микроконтроллеры, резисторы, транзисторы) и их технические параметры, что позволяет в дальнейшем продемонстрировать эффективность работы индексов и аналитических отчетов.

Соседние файлы в папке курсач