Обоснование выбора и характеристики системы управления базами данных
В качестве систем управления базами данных, для релизации задания выберем MS Access. Эта система не является СУБД в полном смысле этго слова, однако полностью удовлетворяет нашим требованиям к масштабам и быстродейсвию базы данных. Среди положительных качеств MS Access стоит выделить следующие:
- система не требует установки системных служб и поддержания работоспособности сервера баз данных,
- система поставляется компанией Microsoft совместно с другими продуктами линейки office,
- из предыдущего пункта прямо вытекает максимальная совместимость MS Access с другими продуктами «офисной линейки», схожий интерфейс и интуитивно-понятные средства разработки,
- база данных, реалзованная на MS Access в случае необходимости легко масштабируется, дополняется формами на Visual Basic и имеет возможность экспорта во «взрослую» СУБД MS SQL Server.
Структура базы данных
Выбор системы управления базами данных определяет логическую структуру самой базы. В случае реляционной системы управления данные в базе будут храниться в виде одной или нескольких таблиц. В последнем случае необходимо обеспечить связи между таблицами.
Очевидно, что если непосредственно преобразовать граф информационно-логической модели в табличную форму, то эта таблица будет выглядеть следующим образом.
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Вид спорта | Спорт. разряд | …... | Вид спорта | Спорт. разряд |
Этот подход имеет явный недостаток: размер таблицы по горизонтали не определен. Возможен другой вариант, с фиксированным числом столбцов:
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Вид спорта | Спорт. разряд |
Но в этом случае некоторые записи (строки таблицы) придется частично дублировать, например:
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Вид спорта | Спорт. разряд |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва | Футбол | |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва | Бокс |
Такое положение является весьма нежелательным, и подобной ситуации на практике стараются избегать. Причина заключается в том, что при корректировках каких-либо атрибутов могут возникать технические ошибки, связанные с работой оператора базы данных. Например, изменился домашний адрес сержанта Иванова. В этом случае требуется внести изменения во все строки, связанные с сержантом Ивановым. Если же будет пропущена хотя бы одна строка и адрес в ней останется прежним, то содержание базы данных не будет соответствовать реальному положению дел. Кроме того, такое дублирование ведет к неоправданному возрастанию объема базы данных.
Выход из сложившейся ситуации состоит в разбиении исходной таблицы на несколько меньших по размеру.
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва |
| Фамилия | Вид спорта | Спорт. разряд |
| Иванов | Футбол | |
| Иванов | Бокс |
В этом случае необходимо организовать связь между таблицами. Связующим звеном выступает поле "Фамилия":
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| сержант | Иванов | Иван | Иванович | 01.01.1985 | г. Москва |
 | Фамилия | Вид спорта | Спорт. разряд | ||
| Иванов | Футбол | ||||
| Иванов | Бокс |
Назовем верхнюю таблицу главной (ее имя Слушатель или Курсант), а нижнюю - подчиненной (ее имя - Спортивные успехи). В главной таблице не должно быть повторяющихся фамилий, а в подчиненной - повторяющихся сочетаний Фамилия - Вид спорта. Первое условие введено искусственно для упрощения примера (в случае однофамильцев пришлось бы вводить дополнительный столбец, например с номерами слушателей или курсантов для их однозначной идентификации). Второе условие вполне естественно: у человека не может одновременно быть двух разных разрядов по одному и тому же виду спорта. Таким образом, обнаруживается, что в главной таблице ключевым является столбец Фамилия, а в подчиненной - столбцы Фамилия и Вид спорта (составной ключ). Поскольку каждой строке главной таблицы может соответствовать несколько строк подчиненной (один человек имеет разряды по нескольким видам спорта), то связь этих таблиц характеризуется как "один-ко-многим". Схематично это изображается следующим образом.
| Слушатель (Курсант) | |||||
| Спец. звание | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| Спортивные успехи | |||||
| | Фамилия | Вид спорта | Спорт. разряд | ||
Структура выглядит неплохо, однако все еще несет в себе критические недочеты, на практике делающие работу с ней невозможной.
Для того, чтобы нагляднопродемонстрировать это, давайте представим, что кроме сержанта Иванова из вышеприведенного примера в учебное заведение поступает его брат Иванов Алексей Иванович. К какому именно Иванову будут относиться спортивные успехи? Кроме того, праила работы СУБД Access просто не позволят нам создать записи с одинаковым первичным ключом. Т.е. младшему брату образцового, во всех отношениях сержанта, придется указать на дверь.
Решение напрашивается само-собой – сделать первичным ключом таблицы «Студенты» составной ключ из трех полей «фамилия», «имя» и «отчество». К сожалению, этот вариант тоже не так хорош как кажется. Полные тезки нет-нет да и встречаются в реальной жизни. Кроме того, по ходу работы БД может возникнуть необходимость хранить в базе архивные данные по студентам, закончившим обучене много лет назад. В этом случае вероятность попдания в базу полных тезок возрастает на порядок.
Выход есть, хотя он може показаться несколько не очевидным. В качестве первичного ключа в таблицу «Студенты» добавим невидимое пользователю, автоматически генерируемое уникальное поле «Код студента». В таблице спортивных успехов внешним ключом (и часть составного ключа), соответсвенно так же будет код студента, а не его фамилия.
С учетом выше сказанного, к описанию атрибутов БД добавим еще один:
| Атрибут | Тип атрибута | Размер атрибута | Обязательность атрибута |
| Код студента | Счетчик | Обязателен |
А структура данных изменится следующим образом:
| Слушатель (Курсант) | ||||||
| Спец. звание | Код студента | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес |
| Спортивные успехи | |||||
| | Код студента | Вид спорта | Спорт. разряд | ||
Характеристики таблиц, схема данных, содержимое таблиц, примеры запросов и отчетов приведены ниже в виде форм машинных документов. Учебный пример реализован в среде системы управления базами данных Microsoft Access.