2.15 Модель предметной области описывается следующим неформальным текстом:

1. В университете занятия проводятся в различных корпусах.

2. Каждый корпус имеет уникальное название.

3. Номера аудиторий уникальны в пределах одного корпуса.

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

5. Один и тот же тип может быть у различных аудиторий.

6. Каждый корпус имеет свой адрес.

7. К каждой аудитории прикреплен один сотрудник, ответственный за пожарную безопасность.

8. Один сотрудник может быть ответственным за несколько аудиторий.

9. Сотрудник имеет табельный номер, ФИО, должность, служебный телефон.

а. Постройте функциональную модель для заданной предметной области с помощью методологии DFD:

• идентифицировать систему

• определить сущности

• определить потоки данных между сущностями и системой

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

в. Структуру спроектированной базы данных реализуйте с помощью любой СУБД. Приложение должно содержать следующие объекты: формы, отчеты и меню.

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

Систему назовём «Система учёта аудиторий».

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

Определим сущности предметной области:

• Корпуса

• Аудитории

• Сотрудники

Определим потоки данных между сущностями и системой.

Функциональная модель представлена при помощи диаграмм потоков данных (DFD). Контекстная диаграмма приведена на рисунке 2.15.1, а её детализация на рисунке 2.15.2.

Рис. 2.15.1. Контекстная диаграмма

Рис. 2.15.2.Детализированная диаграмма потоков данных

Словарь данных

@ИМЯ = ПОИСК АУДИТОРИИ

@ТИП = дискретный поток

@БНФ = Название корпуса + Номер аудитории

@ИМЯ = ДАННЫЕ О КОРПУСЕ

@ТИП = дискретный поток

@БНФ = Название корпуса + Адрес

@ИМЯ = ДАННЫЕ ОБ АУДИТОРИИ

@ТИП = дискретный поток

@БНФ = Название корпуса + Номер аудитории + Число посадочных мест + Тип аудитории + Сотрудник

@ИМЯ = ДАННЫЕ О СОТРУДНИКЕ

@ТИП = дискретный поток

@БНФ = Табельный номер + ФИО + Должность + Служебный телефон

@ИМЯ = ТИП АУДИТОРИИ

@ТИП = дискретный поток

@БНФ = {«поточная», «лекционная», «лаборатория», «компьютерный класс»}

@ИМЯ = СВЕДЕНИЯ ОБ АУДИТОРИИ

@ТИП = дискретный поток

@БНФ = Название корпуса + Номер аудитории + Число посадочных мест + Тип аудитории + Адрес

@ИМЯ = ОТЧЁТ О ПОЖАРНОЙ БЕЗОПАСНОСТИ

@ТИП = дискретный поток

@БНФ = ПОИСК АУДИТОРИИ + ДАННЫЕ О СОТРУДНИКЕ

@ИМЯ = ИНФОРМАЦИЯ О КОРПУСЕ

@ТИП = дискретный поток, внутренний

@БНФ = ДАННЫЕ О КОРПУСЕ

@ИМЯ = ИНФОРМАЦИЯ ОБ АУДИТОРИИ

@ТИП = дискретный поток, внутренний

@БНФ = ДАННЫЕ ОБ АУДИТОРИИ

@ИМЯ = ИНФОРМАЦИЯ О СОТРУДНИКЕ

@ТИП = дискретный поток, внутренний

@БНФ = ДАННЫЕ О СОТРУДНИКЕ

@ИМЯ = ИСКАТЬ СВЕДЕНИЯ ОБ АУДИТОРИИ

@ТИП = дискретный поток, внутренний

@БНФ = ПОИСК АУДИТОРИИ

@ИМЯ = РЕЗУЛЬТАТ ПОИСКА АУДИТОРИИ

@ТИП = дискретный поток, внутренний

@БНФ = СВЕДЕНИЯ ОБ АУДИТОРИИ

@ИМЯ = ИСКАТЬ СВЕДЕНИЯ О СОТРУДНИКЕ

@ТИП = дискретный поток, внутренний

@БНФ = ПОИСК АУДИТОРИИ

@ИМЯ = СВЕДЕНИЯ О СОТРУДНИКЕ

@ТИП = дискретный поток, внутренний

@БНФ = ДАННЫЕ О СОТРУДНИКЕ

Спецификация процессов

Спецификация процесса A0.1

@ВХОД = ДАННЫЕ О КОРПУСЕ

@ВЫХОД = ИНФОРМАЦИЯ О КОРПУСЕ

@СПЕЦПРОЦ A0.1 ФОРМИРОВАТЬ ИНФОРМАЦИЮ О КОРПУСЕ

ЕСЛИ добавить ИНФОРМАЦИЮ О КОРПУСЕ ТО

ИНФОРМАЦИЯ О КОРПУСЕ = ДАННЫЕ О КОРПУСЕ

КОНЕЦ ЕСЛИ

ЕСЛИ изменить ИНФОРМАЦИЮ О КОРПУСЕ ТО

ВЫПОЛНИТЬ редактировать ИНФОРМАЦИЮ О КОРПУСЕ

КОНЕЦ ЕСЛИ

ЕСЛИ удалить ИНФОРМАЦИЮ О КОРПУСЕ ТО

ВЫПОЛНИТЬ удалить ИНФОРМАЦИЮ О КОРПУСЕ

КОНЕЦ ЕСЛИ

Спецификация процесса A0.2

@ВХОД = ДАННЫЕ О СОТРУДНИКЕ

@ВЫХОД = ИНФОРМАЦИЯ О СОТРУДНИКЕ

@СПЕЦПРОЦ A0.2 ФОРМИРОВАТЬ ИНФОРМАЦИЮ О СОТРУДНИКЕ

ЕСЛИ добавить ИНФОРМАЦИЮ О СОТРУДНИКЕ ТО

ИНФОРМАЦИЯ О СОТРУДНИКЕ = ДАННЫЕ О СОТРУДНИКЕ

КОНЕЦ ЕСЛИ

ЕСЛИ изменить ИНФОРМАЦИЮ О СОТРУДНИКЕ ТО

ВЫПОЛНИТЬ редактировать ИНФОРМАЦИЮ О СОТРУДНИКЕ

КОНЕЦ ЕСЛИ

ЕСЛИ удалить ИНФОРМАЦИЮ О СОТРУДНИКЕ ТО

ВЫПОЛНИТЬ удалить ИНФОРМАЦИЮ О СОТРУДНИКЕ

КОНЕЦ ЕСЛИ

Спецификация процесса A0.3

@ВХОД = ДАННЫЕ ОБ АУДИТОРИИ

@ВЫХОД = ИНФОРМАЦИЯ ОБ АУДИТОРИИ

@СПЕЦПРОЦ A0.3 ФОРМИРОВАТЬ ИНФОРМАЦИЮ ОБ АУДИТОРИИ

ЕСЛИ добавить ИНФОРМАЦИЮ ОБ АУДИТОРИИ ТО

ИНФОРМАЦИЯ ОБ АУДИТОРИИ = ДАННЫЕ ОБ АУДИТОРИИ

КОНЕЦ ЕСЛИ

ЕСЛИ изменить ИНФОРМАЦИЮ ОБ АУДИТОРИИ ТО

ВЫПОЛНИТЬ редактировать ИНФОРМАЦИЮ ОБ АУДИТОРИИ

КОНЕЦ ЕСЛИ

ЕСЛИ удалить ИНФОРМАЦИЮ ОБ АУДИТОРИИ ТО

ВЫПОЛНИТЬ удалить ИНФОРМАЦИЮ ОБ АУДИТОРИИ

КОНЕЦ ЕСЛИ

Спецификация процесса A0.4

@ВХОД = ПОИСК АУДИТОРИИ

@ВХОД = РЕЗУЛЬТАТ ПОИСКА АУДИТОРИИ

@ВЫХОД = ИСКАТЬ СВЕДЕНИЯ ОБ АУДИТОРИИ

@ВЫХОД = СВЕДЕНИЯ ОБ АУДИТОРИИ

@СПЕЦПРОЦ A0.4 ВЫДАТЬ СВЕДЕНИЯ ОБ АУДИТОРИИ

ЕСЛИ осуществляется поиск аудитории ТО

ИСКАТЬ СВЕДЕНИЯ ОБ АУДИТОРИИ = ПОИСК АУДИТОРИИ

СВЕДЕНИЯ ОБ АУДИТОРИИ = РЕЗУЛЬТАТ ПОИСКА АУДИТОРИИ

КОНЕЦ ЕСЛИ

Спецификация процесса A0.5

@ВХОД = ПОИСК АУДИТОРИИ

@ВХОД = СВЕДЕНИЯ О СОТРУДНИКЕ

@ВЫХОД = ИСКАТЬ СВЕДЕНИЯ О СОТРУДНИКЕ

@ВЫХОД = ОТЧЁТ О ПОДАРНОЙ БЕЗОПАСНОСТИ

@СПЕЦПРОЦ A0.5 ВЫДАТЬ ОТЧЁТ О ПОЖАРНОЙ БЕЗОПАСНОСТИ

ЕСЛИ осуществляется поиск ответственного сотрудника за пожарную безопасность в аудитории ПОИСК АУДИТОРИИ ТО

ИСКАТЬ СВЕДЕНИЯ О СОТРУДНИКЕ = ПОИСК АУДИТОРИИ

ОТЧЁТ О ПОДАРНОЙ БЕЗОПАСНОСТИ = ПОИСК АУДИТОРИИ + СВЕДЕНИЯ О СОТРУДНИКЕ

КОНЕЦ ЕСЛИ

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

Для разработанной функциональной модели спроектируем структуру базы данных.

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

Связь «Аудитории – Сотрудники» имеет тип «многие к одному», так как к каждой аудитории прикреплен один сотрудник, ответственный за пожарную безопасность, но один сотрудник может быть ответственным за несколько аудиторий.

Диаграмма связей между сущностями представлена на рисунке 2.15.3

Рис. 2.15.3. Диаграмма связей между сущностями

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

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

Каждая аудитория характеризуется числом посадочных мест, типом, также к каждой аудитории прикреплён один сотрудник, ответственный за пожарную безопасность. Для однозначной идентификации этой сущности достаточно совокупности значений атрибутов «Название корпуса», к которому принадлежит эта аудитория и «Номер аудитории». Первый атрибут является также и внешним ключом, так как реализует связь с сущностью «Корпуса».

Сущность «Сотрудники» имеет атрибуты: «Табельный номер сотрудника», «ФИО», «Должность», «Служебный телефон». Уникальным идентификатором этой сущности является атрибут «Табельный номер сотрудника». Атрибуты «ФИО» и «Должность» для этой цели не годятся, так как могут быть не уникальны даже в совокупности. Атрибут служебный телефон тоже не подходит, ибо может содержать неопределённые значения (NULL), что недопустимо для первичного ключа.

Структура спроектированной базы данных приведена на рисунке 2.15.4

Рис. 2.15.4. Структура БД

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

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

Покажем, что в схеме БД нет атрибутов, зависящих от неключевых.

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

У сущности «Корпуса» имеется только один неключевой атрибут «Адрес».

У сущности «Аудитории» имеются три неключевых атрибута: «Табельный номер сотрудника», «Число посадочных мест» и «Тип». Покажем, что между ними нет функциональных зависимостей. Один сотрудник может быть ответственным за несколько аудиторий, среди которых могут оказаться и аудитории с разным числом посадочных мест, значит значения атрибута «Число посадочных мест» не зависят функционально от значений атрибута «Табельный номер сотрудника». Для разных аудиторий, характеризующихся одним и тем же числом посадочных мест, могут быть разные сотрудники, значит значения атрибута «Табельный номер сотрудника» не зависят функционально от значений атрибута «Число посадочных мест». Значения атрибута «Тип» не уникальны, то есть один и тот же тип может быть у различных аудиторий, среди которых могут оказаться как несколько аудиторий, к которым прикреплены разные сотрудники, так и несколько аудиторий, характеризующихся разным числом посадочных мест. Значит ни значения атрибута «Табельный номер сотрудника», ни атрибута «Число посадочных мест» функционально не зависят от значений атрибута «Тип». Аналогично можно показать, что атрибут «Тип» не зависит ни от одного из атрибутов «Табельный номер сотрудника» и «Число посадочных мест», ибо один сотрудник может быть ответственным за несколько аудиторий, среди которых могут оказаться несколько аудиторий, имеющих разный тип, также как и среди нескольких аудиторий с одним и тем же числом посадочных мест могут оказаться несколько аудиторий, имеющих разный тип.

Определим таблицы базы данных и укажем типы данных и ограничения для каждого поля.

Таблица Аудитории (Auditoriums)

Наименование поля	Тип данных	Ограничения
Название корпуса (name_build)	Строка (20)	Входит в состав первичного ключа
Номер аудитории (number_aud)	Целое число	Входит в состав первичного ключа
Табельный номер сотрудника (number_emp)	Целое число	NOT NULL
Число посадочных мест (number_pla)	Целое число	NOT NULL
Тип (type_)	Строка (20)	NOT NULL

Таблица Корпуса (Buildings)

Наименование поля	Тип данных	Ограничения
Название корпуса (Name_build)	Строка (20)	Первичный ключ
Адрес (Address)	Строка (20)	NOT NULL

Таблица Сотрудники (Employees)

Наименование поля	Тип данных	Ограничения
Табельный номер сотрудника (number_emp)	Целое число	Первичный ключ
ФИО (FIO)	Строка (30)	NOT NULL
Должность (Jobtitle)	Строка (20)	NOT NULL
Служебный телефон (telephone)	Строка (10)

Реализация спроектированной базы данных при помощи СУБД Visual FoxPro

Создадим проект приложения баз данных. Для чего выберем в главном меню File – New, затем выберем Project и укажем New File – введём имя проекта Auditoriums и сохраним файл проекта (*.PJT). Далее откроется окно Project Manager (диспетчер проектов) в котором перейдём на вкладку Data (Данные) и выберем пункт Free Tables(Свободные таблицы) и нажмём кнопку New. Появится окно, в котором выберем New Table (Новая таблица) и сохраним таблицу как Auditoriums.dbf. После этого на экране появится диалоговое окно Table Designer(Конструктор таблиц) в котором введём названия всех полей таблицы Аудитории (Auditoriums), укажем их типы данных и ограничения.