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

Рисунок 2 – база данных из SQL Server Management Studio

2.3. Обоснование нормализации (3НФ)

При проектировании базы данных была выполнена нормализация до уровня Третьей Нормальной Формы (3НФ). Это необходимо для устранения избыточности данных, предотвращения аномалий при обновлении и обеспечения логической целостности [1].

Выполнение требований нормализации:

1.Первая Нормальная Форма (1НФ):

Требование: Все атрибуты должны быть атомарными (неделимыми),

отсутствуют повторяющиеся группы.

Реализация: В таблицах отсутствуют поля, содержащие списки

значений (например, «10V, 20mA»). Характеристики компонента

21

вынесены в отдельную таблицу [Stock].ComponentParams, где каждый параметр хранится в отдельной строке.

Таблица [Stock].Components содержит только уникальный первичный ключ ComponentID.

2.Вторая Нормальная Форма (2НФ):

Требование: Таблица находится в 1НФ, и каждый неключевой атрибут полностью зависит от всего первичного ключа.

Реализация: Так как все таблицы имеют простой (не составной)

первичный ключ (ID), условие 2НФ выполняется автоматически.

Например, атрибут Description в таблице [Stock].Components зависит

именно от конкретного компонента (ComponentID), а не от какой-либо

его части.

3.Третья Нормальная Форма (3НФ):

Требование: Таблица находится во 2НФ, и отсутствуют транзитивные зависимости (неключевые атрибуты не должны зависеть от других неключевых атрибутов).

атрибуты, зависящие друг от друга.

Пример устранения транзитивной зависимости: Если бы мы хранили название производителя и адрес его сайта прямо в таблице компонентов, то адрес сайта зависел бы от названия производителя (Component -> ManufacturerName -> Website).

таблице [Stock].Components хранятся только ссылки (ID) на эти справочники.

22

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

требованиям 3НФ.

23

3. СОЗДАНИЕ БАЗЫ ДАННЫХ

Физическая реализация базы данных «CircuitDB» выполнена в среде

Microsoft SQL Server 2012 Express Edition. Создание базы данных осуществляется с помощью DDL-скрипта, который не полагается на настройки по умолчанию, а явно определяет параметры физического хранения файлов.

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

1.Файл данных (Primary Data File, .mdf) — содержит основные таблицы,

индексы и системные представления.

2.Файл журнала транзакций (Log File, .ldf) — фиксирует все изменения данных для обеспечения целостности и возможности восстановления

(ACID).

Реализация выполнена командой CREATE DATABASE с указанием

файловых групп:

CREATE DATABASE CircuitDB

ON PRIMARY

(

NAME = N'CircuitDB_Data',

FILENAME = N'C:\Program Files (x86)\Microsoft SQL

Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\CircuitDB.mdf',

SIZE = 10MB,

MAXSIZE = UNLIMITED,

FILEGROWTH = 5MB

)

LOG ON

(

24

NAME = N'CircuitDB_Log',

FILENAME = N'C:\Program Files (x86)\Microsoft SQL

Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\CircuitDB_log.ldf',

SIZE = 5MB,

MAXSIZE = 2GB,

FILEGROWTH = 1MB

);

Обоснование выбранных параметров:

Пути к файлам (FILENAME): Файлы размещаются в системной директории экземпляра SQL Server, однако предусмотрена возможность их разнесения на физически разные диски для ускорения операций ввода-вывода.

Начальный размер (SIZE): Установлен в 10 МБ для данных и 5 МБ для журнала, что достаточно для развертывания структуры и начального набора данных.

Автоматическое увеличение (FILEGROWTH): Настроен фиксированный шаг прироста (5 МБ), что предотвращает сильную фрагментацию файловой системы, которая могла бы возникнуть при слишком частом увеличении файла маленькими порциями.

Перед созданием базы данных скрипт выполняет проверку на наличие существующей версии с таким же именем. В случае обнаружения, старая база переводится в режим SINGLE_USER (для принудительного разрыва соединений) и удаляется, что гарантирует корректную работу инсталлятора.

25

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). Это гарантирует уникальность каждой записи и ускоряет операции соединения таблиц.

26

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

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

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

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

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

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

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

Для таблиц детализации (ComponentParams, ComponentModels) в схеме

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

27

5. ЗАПОЛНЕНИЕ ТАБЛИЦ ДАННЫМИ

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

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

1.Предварительная очистка и сброс счетчиков Перед загрузкой новых данных выполняется полное удаление всей

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

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

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

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

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

необходимые для работы системы:

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

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

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

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

3.Заполнение основных данных (Схема [Stock])

Загрузка информации о конкретных электронных компонентах выполняется с использованием метода динамического поиска идентификаторов.

28

В скрипте не используются жестко прописанные числовые коды

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

29

6. ОБЪЕКТЫ ПРОМЕЖУТОЧНОГО СЛОЯ

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

6.1.Пользовательские функции (UDF)

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

1.Скалярная функция (Scalar Function) — [Stock].[udf_FormatValue]

Предназначена для форматирования единиц измерения. Функция принимает числовое значение и строковый код единицы измерения,

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

Листинг реализации функции приведен ниже:

IF OBJECT_ID('[Stock].[udf_FormatValue]', 'FN') IS NOT NULL

DROP FUNCTION [Stock].[udf_FormatValue];

GO

CREATE FUNCTION [Stock].[udf_FormatValue]

(

@Value NVARCHAR(100),

@Unit NVARCHAR(20)

)

RETURNS NVARCHAR(150)

AS

BEGIN

DECLARE @Result NVARCHAR(150);

30