Главная arrow Учебники arrow Информатика и ИКТ 10-11 класс Семакин 2012 arrow §32 Проектирование многотабличной базы данных

§32 Проектирование многотабличной базы данных

Информатика и ИКТ 10-11 класс Семакин, Информатика 10-11 класс Семакин, Проектирование многотабличной базы данных, Табличная форма модели данных, Отношения и связи, Схема базы данных, Что такое целостность данных

Рассмотрим на конкретном примере методику проектирования многотабличной базы данных. Для этого снова вернемся к задаче моделирования работы с информацией, выполняемой приемной комиссией при поступлении абитуриентов в университет (см. § 15).
Табличная форма модели данных
В § 15 была построена модель данных, состоящая из трех взаимосвязанных таблиц. Воспроизведем ее еще раз.

ФАКУЛЬТЕТЫ

Название факультета

Экзамен 1

Экзамен 2

Экзамен 3

СПЕЦИАЛЬНОСТИ

Название специальности

Название факультета

План приема

АБИТУРИЕНТЫ

Регистрационный номер

Фамилия

Имя

Отчество

Дата рождения

Город

Законченное учебное заведение

Название специальности

Производственный стаж

Медаль

Оценка за экзамен 1

Оценка за экзамен 2

Оценка за экзамен 3

Зачисление

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

ФАКУЛЬТЕТЫ

Код факультета

Название факультета

Экзамен 1

Экзамен 2

Экзамен 3

СПЕЦИАЛЬНОСТИ

Код специальности

Название специальности

Название факультета

План приема

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

АНКЕТЫ

АБИТУРИЕНТЫ

ОЦЕНКИ

ИТОГИ

Регистрационный

номер

Регистрационный

номер

Регистрационный

номер

Регистрационный

номер

Фамилия

Код специальности

Оценка за экзамен 1

Зачисление

Имя

Медаль

Оценка за экзамен 2

 

Отчество

Производственный

стаж

Оценка за экзамен 3

 

Дата рождения

 

 

 

Город

 

 

 

Законченное учебное заведение

 

 

 

С такими таблицами работать гораздо проще. На разных этапах работы приемной комиссии каждая из этих таблиц будет иметь самостоятельное значение.
Таблица АНКЕТЫ содержит анкетные данные, не влияющие на зачисление абитуриента в вуз. В таблице АБИТУРИЕНТЫ содержатся сведения, определяющие, куда поступает абитуриент, а также данные, которые могут повлиять на его зачисление (стаж и наличие медали). Таблица ОЦЕНКИ — это ведомость, которая будет заполняться для всех абитуриентов в процессе приема экзаменов. Таблица ИТОГИ будет содержать результаты зачисления всех абитуриентов.
Отношения и связи
Каждая из спроектированных выше таблиц будет представлена в БД отдельным отношением. Опишем все их в строчной форме, дав в некоторых случаях полям сокращенные имена и подчеркнув главные ключи.
ФАКУЛЬТЕТЫ (КОД_ФКТ, ФАКУЛЬТЕТ, ЭКЗАМЕН_1, ЭКАМЕН_2, ЭK3AMEH_3)
СПЕЦИАЛЬНОСТИ (КОД_СПЕЦ, СПЕЦИАЛЬНОСТЬ, КОД_ФКТ, ПЛАН)
АБИТУРИЕНТЫ (РЕГ_НОМ, КОД_СПЕЦ, МЕДАЛЬ, СТАЖ)
АНКЕТЫ (РЕГ НОМ, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГОД_РОЖД, ГОРОД, УЧ_ЗАВЕДЕНИЕ)
ОЦЕНКИ (РЕГ_НОМ, ОЦЕНКА_1, ОЦЕНКА_2, ОЦЕНКА_3)
ИТОГИ (РЕГ_НОМ, ЗАЧИСЛЕНИЕ)
Чтобы эти шесть таблиц представляли собой систему, между ними должны быть установлены связи.
Фактически связи уже имеются через общие имена полей. Первые два отношения связаны между собой кодом факультета, второе и третье — кодом специальности, а четыре последних — регистрационным номером. Связи позволяют определить соответствия между любыми данными в этих таблицах, например между фамилией некоторого абитуриента и его оценкой по математике; между названием города и результатами экзамена по русскому языку выпускников школ этого города и пр. Благодаря этим связям становится возможным получение ответов на запросы, требующие поиска информации в нескольких таблицах одновременно.
Схема базы данных
Для явного указания связей между таблицами должна быть построена схема базы данных. В схеме указывается наличие связей между таблицами и типы связей. Схема для нашей системы представлена на рис. 5.22.
Схема базы данных
В схеме использованы два типа связей: один к одному и один ко многим. Первый обозначен двунаправленной одинарной стрелкой, второй — одинарной стрелкой в одну сторону и двойной — в другую. При связи «один к одному» с одной записью в таблице связана одна запись в другой таблице. Например, одна запись об абитуриенте связана с одним списком оценок. При наличии связи «один ко многим» одна запись в некоторой таблице связана с множеством записей в другой таблице. Например, с одним факультетом связано множество специальностей, а с одной специальностью — множество абитуриентов, поступающих на эту специальность.
Как говорилось ранее, связь «один ко многим» — это связь между двумя соседними уровнями иерархической структуры. А таблицы, связанные отношениями «один к одному», находятся на одном уровне иерархии. В принципе все они могут быть объединены в одну таблицу, поскольку главный ключ у них один — РЕГ НОМ. Но чем это неудобно, было объяснено выше.
Что такое целостность данных
СУБД поддерживает организацию связей между таблицами БД, обеспечивающую одно важное свойство базы данных, которое называется целостностью данных.
Система не допустит, чтобы одноименные поля в разных связанных между собой таблицах имели разные значения. Согласно этому принципу, будет автоматически контролироваться ввод данных. В связанных таблицах может быть установлен режим каскадной замены: если в одной из таблиц изменяется значение поля, по которому установлена связь, то в других таблицах одноименные поля автоматически изменят свои значения. Аналогично действует режим каскадного удаления: достаточно удалить запись из одной таблицы, чтобы связанные записи исчезли из всех остальных таблиц. Это естественно, поскольку, например, если закрывается какой-то факультет, то исчезают и все его специальности. Или если у абитуриента изменяют регистрационный номер в таблице АБИТУРИЕНТЫ, то автоматически номер должен обновиться и в других таблицах.
На этом проектирование базы данных завершается. Это был теоретический этап. Практическая работа по созданию базы данных будет проходить в рамках компьютерного практикума.
Система основных понятий

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

1-й этап: анализ предметной области Результат: построение структуры данных - информационной модели предметной области

2-й этап: построение модели данных для будущей БД

Реляционная модель данных

(система таблиц)

Типы связей

Схема

Целостность

Один к одному, один ко многим

Граф, отражающий структуру данных и связей в БД

Свойство согласованности действий с повто­ряющимися данными (поддерживается СУБД)