Проектирование многотабличной базы данных
ПЛАН ЗАНЯТИЯ №14
по дисциплине
Информатика и ИКТ на 25.10.2022
Тема урока: Схема БД. Связывание таблиц в многотабличных базах данных. Целостность данных.
План урока:
Организационный момент, Выход на связь по средствам мессенджера. Проверка явки студентов и готовности к уроку.
Постановка темы и целей урока
Ознакомление с новым материалом, составление краткого конспекта.
Ответы на вопросы
Подведение итогов урока, выставление оценок
Домашнее задание
Ход урока:
Проектирование многотабличной базы данных
Рассмотрим на конкретном примере методику проектирования многотабличной базы данных. Для этого снова вернемся к задаче моделирования работы с информацией, выполняемой приемной комиссией при поступлении абитуриентов в университет.
Табличная форма модели данных
Эти три таблицы можно рассматривать как модель данных в реляционной СУБД. Но работать с БД в таком виде неудобно. Помимо того что реляционная БД должна состоять из таблиц, к ней предъявляется еще ряд требований.
Одним из главных требований является требование отсутствия избыточности (или минимизация избыточности) данных. Избыточность приводит к лишнему расходу памяти. Память нужно экономить. Это не только увеличивает информационную плотность базы данных, но и сокращает время поиска и обработки данных.
Очевидный недостаток описанных таблиц — многократное повторение длинных значений полей в разных записях. Например, название специальности «Радиофизика и электроника» будет повторяться в 100 записях для 100 абитуриентов, которые на нее поступают. Проще сделать так. В таблице СПЕЦИАЛЬНОСТИ для каждой специальности ввести свой короткий код. Тогда полное название запишется в БД только один раз, а в анкетах абитуриентов будет указываться только код. Точно так же можно закодировать названия факультетов.
Внесем изменения в таблицы ФАКУЛЬТЕТЫ и СПЕЦИАЛЬНОСТИ.
Здесь предполагаются два упрощающих допущения: пусть на разных специальностях одного факультета сдаются одни и те же экзамены, а число экзаменов на всех факультетах равно трем (это вполне разумно).
Очень неудобной для работы является таблица АБИТУРИЕНТЫ. В ней слишком много полей. В частности, такую таблицу неудобно будет просматривать на экране, легко запутаться в полях. Поступим следующим образом. Разделим «большую» таблицу АБИТУРИЕНТЫ на четыре таблицы поменьше:
С такими таблицами работать гораздо проще. На разных этапах работы приемной комиссии каждая из этих таблиц будет иметь самостоятельное значение.
Таблица АНКЕТЫ содержит анкетные данные, не влияющие на зачисление абитуриента в вуз. В таблице АБИТУРИЕНТЫ содержатся сведения, определяющие, куда поступает абитуриент, а также данные, которые могут повлиять на его зачисление (предположим, что это может быть производственный стаж и наличие медали). Таблица ОЦЕНКИ — это ведомость, которая будет заполняться для всех абитуриентов в процессе приема экзаменов. Таблица ИТОГИ будет содержать результаты зачисления всех абитуриентов.
Отношения и связи
Каждая из спроектированных выше таблиц будет представлена в БД отдельным отношением. Опишем все их в строчной форме, дав в некоторых случаях полям сокращенные имена и подчеркнув главные ключи.
