Информационно-логическая модель предметной области
Приведенные запросы служат основой построения информационно-логической модели (в графическом виде). Пример построения такой модели показан ниже.
Множественность ветви "Спорт" свидетельствует о том, что любой слушатель (курсант) может иметь квалификацию (разряд) по нескольким видам спорта. Если слушатель (курсант) не имеет спортивного разряда, то это не меняет сущности информационно-логической модели. В этом случае позиции "Вид спорта" и "Спортивный разряд" для него будут пустыми. В дальнейшем, по мере совершенствования спортивного мастерства данного слушателя (курсанта) они могут заполняться и даже неоднократно. Дополнительно можно заметить, что в информационно-логической модели предусмотрена позиция "Отчество", хотя в исходных запросах она отсутствует. Учитывая тот факт, что в ходе ведения базы данных могут появляться новые пользователи и/или запросы, в которых весьма вероятно будет встречаться и этот атрибут, введение рассматриваемой позиции в модель оправдано.
Таким образом, в качестве объектов учета в базе данных выступают слушатели (курсанты) учебной группы. Их характеристики (атрибуты) показаны в виде "листьев" дерева информационно-логической модели.
Далее необходимо описать сами атрибуты. Это описание целесообразно представить в виде следующей таблицы.
| Атрибут | Тип атрибута | Размер атрибута | Обязательность атрибута | Повторяемость атрибута |
| Специальное звание | Текст | 15 символов | Обязателен | Не повторяется |
| Фамилия | Текст | 15 символов | Обязателен | Не повторяется |
| Имя | Текст | 12 символов | Обязателен | Не повторяется |
| Отчество | Текст | 14 символов | Обязателен | Не повторяется |
| Дата рождения | Дата | 10 символов | Обязателен | Не повторяется |
| Домашний адрес | Текст | 14 символов | Обязателен | Не повторяется |
| Вид спорта | Текст | 10 символов | Не обязателен | Повторяется |
| Разряд | Число | 1 разряд | Не обязателен | Повторяется |
Обоснование выбора и характеристики системы управления базами данных
В этой части необходимо привести аргументы в пользу выбора той или иной системы управления базами данных из известных обучающихся. Также следует указать, на каком компьютере предполагается использовать эту систему управления и строить саму базу данных. При перечислении характеристик системы управления базами данных особое внимание надо обратить на тип поддерживаемой модели данных.
Структура базы данных
Выбор системы управления базами данных определяет логическую структуру самой базы. В случае реляционной системы управления данные в базе будут храниться в виде одной или нескольких таблиц. В последнем случае необходимо обеспечить связи между таблицами.
Очевидно, что если непосредственно преобразовать граф информационно-логической модели в табличную форму, то эта таблица будет выглядеть следующим образом.
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Вид спорта | Спорт. разряд | ….. | Вид спорта | Спорт. разряд |
Этот подход имеет явный недостаток: размер таблицы по вертикали не определен. Возможен другой вариант, с фиксированным числом столбцов:
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Вид спорта | Спорт. разряд |
Но в этом случае некоторые записи (строки таблицы) придется частично дублировать, например:
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Вид спорта | Спорт. разряд |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва | Футбол | |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва | Бокс |
Такое положение является весьма нежелательным, и подобной ситуации на практике стараются избегать. Причина заключается в том, что при корректировках каких-либо атрибутов могут возникать технические ошибки, связанные с работой оператора базы данных. Например, изменился домашний адрес сержанта Иванова. В этом случае требуется внести изменения во все строки, связанные с сержантом Ивановым. Если же будет пропущена хотя бы одна строка и адрес в ней останется прежним, то содержание базы данных не будет соответствовать реальному положению дел. Кроме того, такое дублирование ведет к неоправданному возрастанию объема базы данных.
Выход из сложившейся ситуации состоит в разбиении исходной таблицы на несколько меньших по размеру.
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва |
| Фамилия | Вид спорта | Спорт. разряд |
| Иванов | Футбол | |
| Иванов | Бокс |
В этом случае необходимо организовать связь между таблицами. Связующим звеном выступает поле "Фамилия":
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва |
 | Фамилия | Вид спорта | Спорт. разряд | ||
| Иванов | Футбол | ||||
| Иванов | Бокс |
Назовем верхнюю таблицу главной (ее имя Слушатель или Курсант), а нижнюю - подчиненной (ее имя - Спортивные успехи). В главной таблице не должно быть повторяющихся фамилий, а в подчиненной - повторяющихся сочетаний Фамилия - Вид спорта. Первое условие введено искусственно для упрощения примера (в случае однофамильцев пришлось бы вводить дополнительный столбец, например с номерами слушателей или курсантов для их однозначной идентификации). Второе условие вполне естественно: у человека не может одновременно быть двух разных разрядов по одному и тому же виду спорта. Таким образом, обнаруживается, что в главной таблице ключевым является столбец Фамилия, а в подчиненной - столбцы Фамилия и Вид спорта (составной ключ). Поскольку каждой строке главной таблицы может соответствовать несколько строк подчиненной (один человек имеет разряды по нескольким видам спорта), то связь этих таблиц характеризуется как "один-ко-многим". Схематично это изображается следующим образом.
| Слушатель (Курсант) | |||||
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| Спортивные успехи | |||||
| | Фамилия | Вид спорта | Спорт. разряд | ||
Характеристики таблиц, схема данных, содержимое таблиц, примеры запросов и отчетов приведены ниже в виде форм машинных документов. Учебный пример реализован в среде системы управления базами данных Microsoft Access.
Машинная реализация базы данных) структура таблицы Слушатель (курсант)
б) пример заполнения таблицы Слушатель (курсант)
в) структура таблицы Спортивные успехи
г) пример заполнения таблицы Спортивные успехи
д) схема базы данных
е) пример связанных записей таблиц Слушатель (курсант) и Спортивные успехи
ж) общая структура запроса Начальник факультета
з) пример выполнения запроса Начальник факультетабез условий
и) пример структуры запроса Начальник факультетас условием
Специальное звание = Курсант
к) пример выполнения запроса Начальник факультета с условием
Специальное звание = Курсант
л) общая структура запроса Начальник курса
м) пример выполнения запроса Начальник курсабез условий
н) пример структуры запроса Начальник курса с условием
Специальное звание = Курсант и Спортивный разряд = 2
о) пример выполнения запроса Начальник курса с условием
Специальное звание = Курсант и Спортивный разряд = 2
п) пример выполнения отчета по запросу Начальник факультета с условием
Специальное звание = Курсант
р) пример выполнения отчета по запросу Начальник курса с условием
Специальное звание = Курсант и Спортивный разряд = 2
