Проектирование базы данных

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

Данные темы подробно раскрыты в этом разделе.

Прежде, чем начать стоить приложение, работающее с базами данных, надо иметь сами базы данных. Для создания БД в данном случае использовалась программа Database Desktop, которая поставляется вместе с BDE и Delphi и которая позволяет создавать таблицы баз данных некоторых СУБД, задавать и изменять их структуру.

Для создания с помощью Database Desktop таблиц базы данных была использована СУБД Paradox 7. В Paradox 7 база данных — это каталог, в котором лежат таблицы — файлы с расширением.db.

При разработке структуры БД было принято решение о создании четырех таблиц:

Таблица 2. «SOTRUDNIK» .

ID — порядковый номер

N_otd — номер сотрудника в отделе.

FNS — Фамилия, Имя, Отчество сотрудника.

Data_Birth — Дата рождения.

Work — должность.

Dey_begin — дата приема на работу.

Last_work — предыдущее место работы.

Stag — стаж.

Education — образование.

Married — наличие семьи.

N_child — количество детей.

Notdela — номер отдела Таблица 3. «OTDEL» .

ID — порядковый номер

Name_of_depart — номер отдела.

SN_Header — начальник отдела.

Phone — телефон.

Таблица 4. «OBRAZOVANIE» .

Таблица 5. «FAMILY» .

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

Рисунок 4. Окно конструктора Paradox 7.

Для каждого поля создаваемой таблицы, прежде всего, указывается имя — идентификатор поля. Он может включать до 25 символов и не может начинаться с пробела. Затем надо выбрать тип данных этого поля. Для некоторых типов необходимо задать размер (Size). Например, для строкового типа Alpha размер — это число символов.

Ключевые поля должны быть отмечены символом «*» в последней колонке.

Для таблицы SOTRUDNIK. db создается вторичный индекс fio, и в окне задания вторичного индекса на панели радиокнопок Index Options (опции индекса) устанавливается Maintained, что обуславливает обновление индекса при каждом изменении в таблице. В противном случае индекс обновляется только в момент связывания с таблицей или передачи в нее запроса. Поэтому полезно включать эту опцию для обновляемых таблиц. Если таблица используется только для чтения, эту опцию лучше не включать [3].

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

Нормализация модели БД. Нормализация — это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных [47].

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

Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, «нормализованная» и «находящаяся в 1НФ» означают одно и то же. Однако на практике термин «нормализованная» часто используется в более узком смысле — «полностью нормализованная», который означает, что в проекте не нарушаются никакие принципы нормализации. Дадим точные определения наиболее распространенных форм нормализации.

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

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

Таблица 6. Инфологическая таблица базы данных «Кадровый учет» .

Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что «(N+1)-я нормальная форма» не обладает некоторыми непривлекательными особенностями, свойственным «N-й нормальной форме» .

Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей. Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные [48].

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

Полная функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от, А и не зависит функционально от любого подмножества поля А.

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

Вывод: Разрабатываемая модель БД находится в третьей нормальной форме, так как:

• 1) ни одна из строк таблиц БД не содержит в любом своем поле более одного значения;
• 2) ни одно из ключевых полей не пусто;
• 3) ни одно из неключевых полей всех таблиц БД не зависит функционально от любого другого неключевого поля.

Выделение сущностей.

Сущность «сотрудник» является стержневой сущностью разрабатываемой модели. С сотрудником заключается трудовой договор, на основании которого осуществляется его деятельность на предприятии. В качестве ключа для данной сущности вводится атрибут ID. Все сущности, их атрибуты и ключи представлены в таблице 7.

Таблица 7. Выделение сущностей

При проектировании БД существуют взаимосвязи между информационными объектами трех типов: «один к одному», «один ко многим», «многие ко многим» (рисунок 5).

Рисунок 5. Взаимосвязи между объектами.

Построение концептуальной модели.

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

Модели «сущность-связь», дающие возможность представлять структуру и ограничения реального мира, а затем трансформировать их в соответствии с возможностями промышленных СУБД, являются весьма распространенными [49].

Под сущностью понимают основное содержание того явления, процесса или объекта, о котором собирают информацию для БД. В качестве сущности могут выступать место, вещь, личность, явление и т. д. При этом различают тип сущности и экземпляр сущности. Под типом сущности обычно понимают набор однородных объектов, выступающих как целое. Понятие «экземпляр сущности» относится к конкретному предмету. Например:

Тип сущности — сотрудник Экземпляр сущности — Иванов, Петров, Сидоров и др.

В данном примере отдел, сотрудник, образование семья — сущности. Проанализируем связи между сущностями (рисунок 5).

Рисунок 5. Выделение связей между сущностями.

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

Логическое проектирование базы данных.

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

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

Рисунок 6. ER-диаграмма модели данных «Кадровый учет» .

TableOtdel — otdel.db.

TableSotrud — sotrudnik.db.

TableFamily — family.db.

TableObraz — obrazovanie.db.

В данном случае головной таблицей является таблица OTDEL и связана с таблицей SOTRUDNIK по ключевому полю ID и полю Notdela.

Связь устанавливается следующим образом: в свойстве MasterSource компонента Table, настроенного на вспомогательную таблицу, то есть SOTRUDNIK, устанавливается имя головной таблицы.

После этого в свойстве Master Fields, щелчком открывается окно редактора связей полей (Field Link Designer). Его вид приведен на рисунке 8.

Рисунок 7. Логическое проектирование базы данных.

В нем слева в окне Detail Fields расположены имена полей вспомогательной таблицы, но только тех по которым таблица индексирована. Слева в окне Master Fields расположены поля головной таблицы.

Теперь необходимо выделить в одном и другом окне поля по которым будет осуществляться связь таблиц, и после щелчка по кнопке Add, эти поля переносятся в окно Joined Fields — соединяемые поля.

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

Таблица FAMILY связана с таблицей SOTRUDNIK по ключевым полям IDsort и ID и таблицы OBRAZOVANIE и SOTRUDNIK, также по ключевым полям IDsort и ID.

Рисунок 8. Окно редактора связей полей головной (OTDEL) и вспомогательной (SOTRUDNIK) таблиц.