Инфологическая модель базы данных

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

Сущность (объектное множество, таблица) – это собирательное понятие, абстракция реально существующего процесса, объекта или явления, о котором необходимо хранить информацию [3,4].

Атрибут (реквизит) – поименованная характеристика сущности [7].

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

Приведем список сущностей с соответствующими атрибутами:

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

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

3. Комната (Номер комнаты, количество мест, количество свободных мест, качество, примечание).

4. Журнал коменданта (Номер записи, Номер комнаты, Код договора, дата въезда-выезда, факт проживания, факт оплаты, номер квитанции).

5. Квитанция (Номер квитанции, номер записи, сумма, дата оплаты).

На основании выявленных сущностей построим модель «сущность - связь».

Рисунок 1.3. Модель «сущность-связь» проектируемой базы данных

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

Перейдем от инфологической модели данных к реляционной. Как видно из рисунка 1.3 связи между сущностями 1: М (один ко многим). В этом случае строится по одному отношению для каждой сущности. Ключ односвязной сущности добавляется в качестве внешнего ключа в другое отношение.

Нормализуем полученные отношения. Нормализация – это разбиение отношений-таблиц на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. В теории нормализации существует пять нормальных форм таблиц. Эти формы предназначены для уменьшения избыточной информации от первой до пятой нормальной формы. Поэтому каждая последующая НФ должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям [8,9].

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

В отношении Факультет добавим Фамилия, Имя, Отчество декана, телефон и порядок следования в документах. То есть в случае переименования факультета Вечернего и дистанционного обучения в Заочный факультет, то достаточно в этой таблице изменить Истина на Ложь в данном поле.

Далее поскольку договора заключаются и продлеваются на каждом новом курсе то данное поле разумнее добавить в отношение Договор.

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

Получим следующие отношения:

1. Студент (Номер зачетной книжки, Фамилия, Имя, Отчество, код факультета, код специальности, номер удостоверения, фото, прописка, наличие регистрации).

2. Факультет (Код факультета, название, короткое название, порядок следования в документах, Фамилия, Имя, Отчество декана, телефон).

3. Специальность (Код специальности, Название, Короткое название).

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

5. Комната (Номер комнаты, количество мест, количество свободных мест, качество, примечание).

6. Журнал коменданта (Номер записи, Номер комнаты, Код договора, дата въезда-выезда, факт проживания, факт оплаты, номер квитанции).

7. Квитанция (Номер квитанции, номер записи, сумма, дата оплаты).

8. Пользователи (Логин, пароль).

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