План проведения занятий на учебный год (по учебнику Семакина И.Г.) 1 час в неделю



Уроки 4 - 10
Базы данных (§§ 5 - 9)
Практическая работа 1.3. "Знакомство с СУБД LibreOffice Base"
Практическая работа 1.4. "Создание базы данных «Приемная комиссия»"
Практическая работа 1.6. "Реализация простых запросов в режиме дизайна"
Практическая работа 1.7. "Расширение базы данных "Приемная комиссия". Работа с формой"
Практическая работа 1.8. "Реализация сложных запросов к базе данных "Приемная комиссия""
Практическая работа 1.9. "Создание отчета"






Содержание урока

База данных — основа информационной системы (§ 5)

Проектирование многотабличной базы данных. Создание базы данных (§§ 6 - 7)

Проектирование многотабличной базы данных. Табличная форма модели данных

Отношения и связи

Схема базы данных

Что такое целостность данных

Вопросы и задания

Создание базы данных

Практикум. Практическая работа № 1.4. Создание базы данных «Приемная комиссия»

Запросы как приложения информационной системы (§ 8)

Логические условия выбора данных (§ 9)

Проект: системология. Практическая работа 1.2. "Проектные задания по системологии"

Проект: разработка базы данных. Практическая работа 1.5. "Проектные задания на самостоятельную разработку базы данных"

Итоговое тестирование по теме. «Информационные системы и базы данных»


Проектирование многотабличной базы данных (§ 6)
Создание базы данных (§ 7)
Практическая работа 1.4. "Создание базы данных «Приемная комиссия»"


Табличная форма модели данных


В §3 "Пример структурной модели предметной области" была построена модель данных, состоящая из трех взаимосвязанных таблиц. Воспроизведем ее еще раз.

image

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

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

Очевидный недостаток описанных таблиц — многократное повторение длинных значений полей в разных записях. Например, название специальности «Радиофизика и электроника» будет повторяться в 100 записях для 100 абитуриентов, которые на нее поступают. Проще сделать так. В таблице СПЕЦИАЛЬНОСТИ для каждой специальности ввести свой короткий код. Тогда полное название запишется в БД только один раз, а в анкетах абитуриентов будет указываться только код. Точно так же можно закодировать названия факультетов.

Внесем изменения в таблицы ФАКУЛЬТЕТЫ и СПЕЦИАЛЬНОСТИ.

image

Здесь предполагаются два упрощающих допущения: пусть на разных специальностях одного факультета сдаются одни и те же экзамены, а число экзаменов на всех факультетах равно трем (это вполне разумно).

Очень неудобной для работы является таблица АБИТУРИЕНТЫ. В ней слишком много полей. В частности, такую таблицу неудобно будет просматривать на экране, легко запутаться в полях. Поступим следующим образом. Разделим «большую» таблицу АБИТУРИЕНТЫ на четыре таблицы поменьше:

image

С такими таблицами работать гораздо проще. На разных этапах работы приемной комиссии каждая из этих таблиц будет иметь самостоятельное значение.

Таблица АНКЕТЫ содержит анкетные данные, не влияющие на зачисление абитуриента в вуз. В таблице АБИТУРИЕНТЫ содержатся сведения, определяющие, куда поступает абитуриент, а также данные, которые могут повлиять на его зачисление (предположим, что это может быть производственный стаж и наличие медали). Таблица ОЦЕНКИ — это ведомость, которая будет заполняться для всех абитуриентов в процессе приема экзаменов. Таблица ИТОГИ будет содержать результаты зачисления всех абитуриентов.

Следующая страница Схема базы данных








Наверх