1.2.1. Проектирование бд системы

В БД отражается информация об определенной предметной области. Предметная область – это часть реального мира, представляющая интерес для данного исследования или использования.

Создание инфологической модели (ИЛМ)

Для проектирования структуры БД необходимо иметь исходную информацию (желательно в формализованном виде). Формализованным видом представления информации является инфологическая модель.

Инфологическая модель предметной области – это описание информационных аспектов предметной области, выполненное с помощью специальных языковых средств, не зависящее в дальнейшем от выбранных средств разработки.

Все работы, проводимые в НИИ ВС и СУ можно условно разделить на работы с разрабатываемыми изделиями и с примененными в них ЭРИ. Одним из требований технического задания являлась систематизация данных об изделиях и элементах. С этой целью мне потребовалось спроектировать таблицы для хранения информации об изделиях и примененных в них элементах (рис. 1.2 и 1.3).

Идентификатор изделия

Идентификатор темы Идентификатор назначения изделия Шифр изделия Название изделия

Рис. 1.2. Структура таблицы «Изделия»

Идентификатор элемента

Идентификатор назначения элемента Тип элемента Фирма-изготовитель, страна Основные характеристики Вид исполнения Полные аналоги элемента Рекомендуемая замена Фирмы, у которых можно купить Цена элемента Организация, выдавшая разрешение на использование Номер протокола с разрешением Дата протокола с разрешением Дата регистрации или обновления Комментарий

Рис. 1.3. Структура таблицы «Элементы»

Так как разработка электронной аппаратуры связана с использованием большого количества электро- и радиоизделий, то эти таблицы должны быть связаны, причем эта связь имеет тип «многие ко многим» (одно изделие может состоять из нескольких элементов и один элемент может быть применен при разработке нескольких изделий) (рис. 1.4).

Рис. 1.4. Связь таблицы «Изделия» и таблицы «Элементы»

Для реализации связи типа «многие ко многим» между таблицами изделий и элементов потребовалось ввести дополнительную таблицу «Элементы_Изделия» (рис. 1.5).

Идентификатор изделия Идентификатор элемента

Рис. 1.5. Структура таблицы «Элементы_Изделия»

В результате связь между таблицами изделий и элементов разбилась на две (рис. 1.6 а, б):

а)

б)

Рис. 1.6. а - связь таблицы «Изделия» и таблицы «Элементы_Изделия»,

б - связь таблицы «Элементы» и таблицы «Элементы_Изделия».

Каждое изделие, разрабатываемое в НИИ ВС и СУ, принадлежит определенной категории и реализует основные характеристики этой категории. Для описания списка функциональных назначений изделий я ввел в рассмотрение таблицу «Категории изделий» (рис. 1.7). Таблицы «Категории изделий» и «Изделия» связаны между собой и имеют связь типа «один ко многим».

Идентификатор назначения изделия

Название категории

Рис. 1.7. Структура таблицы «Категории изделий»

Каждое изделие разрабатывается в рамках определенной темы одним или несколькими разработчиками. На каждое готовое изделие разработчиками выпускается техническая и программная документация. Для хранения данной информации были спроектированы таблицы «Темы», «Разработчики изделий» и «Документация на изделия» соответственно (рис. 1.8).

Идентификатор темы

Шифр темы Название темы Руководитель Ответственный исполнитель Дата начала Дата окончания

а)

Идентификатор разработчика

ФИО Пол Дата рождения Должность Подразделение

б)

Идентификатор документа

Идентификатор изделия Децимальный номер документа Наименование документа Местонахождение файла Код доступа

в)

Рис. 1.8. Структура таблиц «Темы» (а), «Разработчики изделий» (б) и «Документация на изделия» (в)

Эти таблицы связаны с таблицей «Изделия» и имеют типы связей, изображенные на рис. 1.9.

а)

б)

в)

Рис. 1.9. а - связь таблицы «Изделия» и таблицы «Темы»,

б - связь таблицы «Разработчики изделий» и таблицы «Изделия»,

в - связь таблицы «Документация на изделия» и таблицы «Изделия»

Как разрабатываемые изделия, так и примененные в них элементы тоже принадлежат определенным категориям. Для описания списка функциональных назначений элементов предусмотрена таблица «Категории элементов» (рис. 1.10). Таблицы «Категории элементов» и «Элементы» связаны между собой и имеют связь типа «один ко многим».

Идентификатор назначения элемента

Название категории

Рис. 1.10. Структура таблицы «Категории элементов»

Все примененные элементы имеют свое описание и электрическую схему. Информация о местонахождении файла с описанием элементов, функциональных электрических схем и др. хранится в специальных таблицах (рис 1.11).

Идентификатор описания элемента

Идентификатор элемента Местонахождение файла Адрес описания элемента Дата обновления описания

а)

Идентификатор схемы

Идентификатор элемента Местонахождение файла Адрес источника информации Дата обновления информации

б)

Рис. 1.11. Структура таблиц «Описание элементов» (а) и «Схемы» (б)

Данные таблицы связаны с таблицей «Элементы» и имеют типы связей, изображенные на рис. 1.12.

а)

б)

Рис. 1.12. а – связь таблицы «Элементы» и таблицы «Описание элементов»,

б - связь таблицы «Элементы» и таблицы «Схемы»

Имеющиеся в наличии элементы хранятся в определенном месте на складе. Для ведения складского учета была спроектирована таблица «Места на складе» (рис. 1.13, а), которая связана с таблицей «Элементы» связью типа «многие ко многим». Для обеспечения такой связи создается дополнительная таблица «Места на складе - Элементы». В ней указываются идентификаторы элемента и места хранения, а также количество элементов, хранящихся в данном месте, и количество зарезервированных элементов для исполнения заявок (рис. 1.13, б).

Идентификатор места

Указатель местоположения

а)

Идентификатор места Идентификатор элемента

Количество имеющихся элементов Количество зарезервированных элементов

б)

Рис. 1.13. Структура таблиц «Места на складе» (а) и

«Места на складе - Элементы» (б)

Для хранения приходных и расходных ведомостей, заявок на выдачу элементов со склада и фиксаций операций с этими документами предусмотрены таблицы «Ведомости» и «Журнал операций», а также таблицы-словари «Тип ведомости» и «Статус ведомости». В таблице «Ведомости» хранятся сведения о типе и статусе ведомости (идентификаторы соответствующих значений словарей), дате создания и документе-основании (рекурсивная связь), исполнителе и номере ведомости (рис 1.14).

Идентификатор ведомости

Идентификатор типа Идентификатор документа-основания Идентификатор исполнителя Номер ведомости Дата создания Идентификатор статуса

Рис. 1.14. Структура таблицы «Ведомости»

В ведомость включаются элементы, изымаемые или помещаемые на различные места хранения. Для реализации такой трехсторонней связи типа «многие ко многим» была введена дополнительная таблица «Ведомости – Элементы», в которой содержатся идентификаторы ведомости, элемента, его количества и места хранения (рис. 1.15).

Идентификатор ведомости Идентификатор элемента Идентификатор места хранения

Количество элемента

Рис. 1.15. Структура таблицы «Ведомости - Элементы»

Таблицы-словари «Тип ведомости» и «Статус ведомости» имеют простую структуру, которая включает в себя идентификатор элемента словаря и его значение (рис. 1.16, а, б).

Идентификатор типа ведомости

Тип ведомости

а)

Идентификатор статуса ведомости

Статус ведомости

б)

Рис. 1.16. Структура таблиц «Тип ведомости» (а) и «Статус ведомости» (б)

В таблице «Журнал операций» отражаются все операции, производимые со складскими документами – получение, исполнение и аннулирование заявок, проведение и отмена проводок ведомостей. В ней хранится информация о документе, над которым производилась операция, дате проведения, исполнителе и результате операции (рис. 1.17).

Идентификатор операции

Идентификатор ведомости Идентификатор исполнителя Идентификатор статуса Дата операции

Рис. 1.17. Структура таблицы «Журнал операций»

Разрабатываемая система является многопользовательской, поэтому для хранения информации о пользователях предусмотрена таблица «Пользователи системы» (рис.1.18). Кроме стандартных учетных сведений («фамилия, имя, отчество», «login», «пароль») в базе данных хранится информация о подразделении, в котором работает пользователь, и о занимаемой должности. Для статистического анализа фиксируется количество входов в систему и дата регистрации пользователя. В процессе автоматической регистрации вырабатывается признак нового пользователя.

Идентификатор пользователя

ФИО пользователя Имя пользователя (Login) Пароль пользователя Должность пользователя Подразделение, в котором работает Код доступа к документам Категория пользователя Дата регистрации Счетчик входов в систему Признак нового пользователя

Рис. 1.18. Структура таблицы «Пользователи системы»

В разрабатываемой системе предусмотрен механизм разграничения прав доступа пользователей. Он реализуется с помощью определения категории пользователя (роли) и кода доступа к документам. Для последующего варьирования этих параметров (добавление и удаление ролей и уровней доступа) мной были спроектированы таблицы-словари «Роли пользователей» и «Коды доступа к документам» (рис. 1.19).

Идентификатор роли

Описание роли

а)

Идентификатор кода доступа

Код доступа Описание кода доступа

б)

Рис. 1.19. Структура таблиц «Роли пользователей» (а)

и «Коды доступа к документам» (б)

Данные таблицы связаны с таблицей «Пользователи системы» посредством связи «один ко многим». Кроме того, таблица «Коды доступа к документам» дополнительно связана с таблицей «Документация на изделия».

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

В результате инфологического моделирования была получена модель, показанная на рис.1.20.

Рис. 1.20. Результат построения инфологической модели

Создание даталогической модели (ДЛМ)

Даталогическая модель – это описание структуры баз, сделанное на языке выбранной СУБД. Выбранной СУБД является Firebird, достоинства которой были рассмотрены ранее. Требования, предъявляемые к системе, полностью можно реализовать с помощью данной СУБД. Она обеспечивает достаточно большое быстродействие на отдельном компьютере и в пределах небольшой локальной сети. ДЛМ является концептуальной моделью БД и представляет собой отражение логических связей между информационными элементами ИЛМ. ДЛМ строится в терминах условных единиц, допустимых в конкретной СУБД. Результат построения даталогической модели представлен на рисунке 1.21.

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

Результатом даталогического проектирования является схема базы данных. Она включает в себя описание всех полей таблиц с указанием их типов. Схема БД для разрабатываемой системы приведена в таблице 1.1.

Таблица 1.1

Название таблицы	Описание таблицы	Название поля	Тип данных поля	Описание поля
Designers	Разработчики готовых изделий	DBirthDay	DATE	Дата рождения разработчика

Таблица 1.1 (продолжение)

Название таблицы	Описание таблицы	Название поля	Тип данных поля	Описание поля
		DDep	VARCHAR(50)	Подразделение, в котором работает разработчик
		DName	VARCHAR(50)	Фамилия, имя, отчество разработчика
		DPost	VARCHAR(50)	Должность разработчика
		DSex	CHAR(1)	Пол разработчика (М, Ж)
		IdR	INTEGER	Уникальный идентификатор разработчика
Documents	Документация на разработанные изделия	DACL	INTEGER	Код доступа к документу - Access Control Level (используется для сравнения с кодом доступа пользователя системы к документам)
		DocName	VARCHAR(100)	Полное наименование документа
		DocNum	VARCHAR(100)	Децимальный номер документа по принятой системе обозначений
		FileDoc	VARCHAR(100)	Местонахождение файла с текстом документа на диске
		IdD	INTEGER	Уникальный идентификатор документа
		IdI	INTEGER	Уникальный идентификатор изделия
EDescription	Описание импортного элемента	ERenewDate	DATE	Дата обновления описания импортного элемента
		FileLoc	VARCHAR(100)	Местонахождение файла с описанием элемента на диске
		FileURL	VARCHAR(100)	Адрес описания элемента в Интернете
		IdE	INTEGER	Уникальный идентификатор элемента
		IdO	INTEGER	Уникальный идентификатор описания элемента

Таблица 1.1 (продолжение)

Название таблицы	Описание таблицы	Название поля	Тип данных поля	Описание поля
Elements	Импортные элементы изделий	AllowDate	DATE	Дата протокола с разрешением на использование/приобретение импортного ЭРИ
		AllowOrg	VARCHAR(100)	Организация, выдавшая разрешение на использование/приобретение импортного ЭРИ
		Analogs	VARCHAR(600)	ЭРИ, являющиеся полными аналогами данного ЭРИ
		IdE	INTEGER	Уникальный идентификатор элемента
		IdNE	INTEGER	Уникальный идентификатор назначения элемента
		MainValues	VARCHAR(100)	Функциональное назначение и основные характеристики ЭРИ
		Performance	VARCHAR(50)	Вид исполнения/наличие исполнения millitary
		Price	DECIMAL(12,2)	Цена ЭРИ (в У.Е.)
		Producer	VARCHAR(100)	Фирма-изготовитель, страна
		ProtocolN	VARCHAR(20)	№ протокола с разрешением на использование/приобретение импортного ЭРИ
		RenewDate	DATE	Дата регистрации или обновления сведений об ЭРИ
		Replacement	VARCHAR(100)	ЭРИ, используемые для замены
		TypeE	VARCHAR(300)	Тип примененного импортного электрорадиоизделия  (ЭРИ)
		Vendor	VARCHAR(100)	Фирмы, у которых можно купить ЭРИ
Elem_Products	Таблица связи «Элементы-Изделия»	IdE	INTEGER	Уникальный идентификатор элемента
		IdI	INTEGER	Уникальный идентификатор изделия

Таблица 1.1 (продолжение)

Название таблицы	Описание таблицы	Название поля	Тип данных поля	Описание поля
ENomination	Функциональное назначение ЭРИ	IdNE	INTEGER	Уникальный идентификатор назначения элемента
		NameNE	VARCHAR(100)	Наименование функционального назначения элемента (ЭРИ)
EScheme	Электрические схемы ЭРИ	FileLoc	VARCHAR(100)	Местонахождение файла с описанием  электрической схемы на диске
		FileURL	VARCHAR(100)	Адрес источника информации  в Интернете
		IdE	INTEGER	Уникальный идентификатор элемента
		IdS	INTEGER	Уникальный идентификатор электрической схемы импортного элемента
		SRenewDate	DATE	Дата обновления электрической схемы импортного элемента
PNomination	Функциональное назначение изделия	IdNI	INTEGER	Уникальный идентификатор назначения изделия
		NameNI	VARCHAR(100)	Наименование функционального назначения изделия
Products	Информация о разработанном изделии	IdI	INTEGER	Уникальный идентификатор изделия
		IdNI	INTEGER	Уникальный идентификатор назначения изделия
		IdT	INTEGER	Уникальный идентификатор темы
		PCode	VARCHAR(100)	Условное обозначение изделия
		PName	VARCHAR(100)	Полное название изделия
Prod_Designers	Таблица связи «Изделия-Разработчики»	IdI	INTEGER	Уникальный идентификатор изделия
		IdR	INTEGER	Уникальный идентификатор разработчика

Таблица 1.1 (продолжение)

Название таблицы	Описание таблицы	Название поля	Тип данных поля	Описание поля
StorePlaces	Места на складе, где находятся импортные ЭРИ	IdM	INTEGER	Уникальный идентификатор места на складе
		Place	VARCHAR(50)	Указатель местоположения ЭРИ на складе
SP_Elements	Таблица связи «Места на складе-Элементы»	IdE	INTEGER	Уникальный идентификатор элемента
		IdM	INTEGER	Уникальный идентификатор места на складе
Themes	Темы выполненные или выполняемые	FinishDate	DATE	Дата окончания выполнения темы
		IdT	INTEGER	Уникальный идентификатор темы
		StartDate	DATE	Дата начала выполнения темы
		TChief	VARCHAR(50)	Руководитель темы
		TCode	VARCHAR(50)	Условное обозначение темы
		TName	VARCHAR(100)	Полное название темы
		TRuler	VARCHAR(50)	Ответственный исполнитель темы
Users	Пользователи системы	Count	INTEGER	Счетчик входов пользователя в систему
		IdU	INTEGER	Уникальный идентификатор пользователя системы
		Login	VARCHAR(20)	Имя пользователя системы
		Password	VARCHAR(20)	Пароль зарегистрированного пользователя для входа в систему
		RegDate	DATE	Дата регистрации пользователя системы
		Role	INTEGER	Роль пользователя

Таблица 1.1 (окончание)

Название таблицы	Описание таблицы	Название поля	Тип данных поля	Описание поля
		UACL	INTEGER	Код доступа пользователя  к документам
		UDep	VARCHAR(50)	Подразделение, в котором работает пользователь системы
		UName	VARCHAR(50)	Фамилия, имя, отчество пользователя системы
		UPost	VARCHAR(50)	Должность пользователя системы

Ограничения целостности

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