Уроки 6 - 16
Базы данных (§§ 5 - 9)
Практическая работа 1.3. "Знакомство с СУБД LibreOffice Base"
Практическая работа 1.4. "Создание базы данных «Приемная комиссия»"
Практическая работа 1.6. "Реализация простых запросов в режиме дизайна"
Практическая работа 1.7. "Расширение базы данных "Приемная комиссия". Работа с формой"
Практическая работа 1.8. "Реализация сложных запросов к базе данных "Приемная комиссия""
Практическая работа 1.9. "Создание отчета"
Содержание урока
Уроки 6 - 7. База данных — основа информационной системы (§ 5)
Уроки 8 - 10. Проектирование многотабличной базы данных. Создание базы данных (§§ 6 - 7)
Проектирование многотабличной базы данных
Практическая работа № 1.4. Создание базы данных «Приемная комиссия»
Уроки 11 - 12. Запросы как приложения информационной системы (§ 8)
Уроки 13 - 16. Логические условия выбора данных (§ 9)
Уроки 8 - 10
Проектирование многотабличной базы данных (§ 6)
Создание базы данных (§ 7)
Практическая работа 1.4. "Создание базы данных «Приемная комиссия»"
Проектирование многотабличной базы данных
Рассмотрим на конкретном примере методику проектирования многотабличной базы данных. Для этого снова вернемся к задаче моделирования работы с информацией, выполняемой приемной комиссией при поступлении абитуриентов в университет (см. "Пример структурной модели предметной области").
Табличная форма модели данных
В §3 "Пример структурной модели предметной области" была построена модель данных, состоящая из трех взаимосвязанных таблиц. Воспроизведем ее еще раз.
Эти три таблицы можно рассматривать как модель данных в реляционной СУБД. Но работать с БД в таком виде неудобно. Помимо того что реляционная БД должна состоять из таблиц, к ней предъявляется еще ряд требований.
Одним из главных требований является требование отсутствия избыточности (или минимизация избыточности) данных. Избыточность приводит к лишнему расходу памяти. Память нужно экономить. Это не только увеличивает информационную плотность базы данных, но и сокращает время поиска и обработки данных.
Очевидный недостаток описанных таблиц — многократное повторение длинных значений полей в разных записях. Например, название специальности «Радиофизика и электроника» будет повторяться в 100 записях для 100 абитуриентов, которые на нее поступают. Проще сделать так. В таблице СПЕЦИАЛЬНОСТИ для каждой специальности ввести свой короткий код. Тогда полное название запишется в БД только один раз, а в анкетах абитуриентов будет указываться только код. Точно так же можно закодировать названия факультетов.
Внесем изменения в таблицы ФАКУЛЬТЕТЫ и СПЕЦИАЛЬНОСТИ.
Здесь предполагаются два упрощающих допущения: пусть на разных специальностях одного факультета сдаются одни и те же экзамены, а число экзаменов на всех факультетах равно трем (это вполне разумно).
Очень неудобной для работы является таблица АБИТУРИЕНТЫ. В ней слишком много полей. В частности, такую таблицу неудобно будет просматривать на экране, легко запутаться в полях. Поступим следующим образом. Разделим «большую» таблицу АБИТУРИЕНТЫ на четыре таблицы поменьше:
С такими таблицами работать гораздо проще. На разных этапах работы приемной комиссии каждая из этих таблиц будет иметь самостоятельное значение.
Таблица АНКЕТЫ содержит анкетные данные, не влияющие на зачисление абитуриента в вуз. В таблице АБИТУРИЕНТЫ содержатся сведения, определяющие, куда поступает абитуриент, а также данные, которые могут повлиять на его зачисление (предположим, что это может быть производственный стаж и наличие медали). Таблица ОЦЕНКИ — это ведомость, которая будет заполняться для всех абитуриентов в процессе приема экзаменов. Таблица ИТОГИ будет содержать результаты зачисления всех абитуриентов.
Следующая страница 
Отношения и связи
