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

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

Рассмотрим на конкретном примере методику проектирова­ния многотабличной базы данных. Для этого снова вернемся к за­ даче моделирования работы с информацией, выполняемой прием­ ной комиссией при поступлении абитуриентов в университет (Л16. § 3 Пример структурной модели предметной области).

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

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

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

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

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

свой короткий код. Тогда пол­ное название запишется в БД только один раз, а в анкетах абиту­риентов будет указываться только код. Точно так же можно зако­дировать названия факультетов.

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

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

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

Поступим следующим образом. Разделим «большую» таблицу АБИТУРИЕНТЫ на четыре таблицы поменьше:

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

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

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

Каждая из спроектированных выше таблиц будет представле­на в БД отдельным отношением. Опишем все их в строчной фор­ ме, дав в некоторых случаях полям сокращенные имена и под­ черкнув главные ключи.

ФАКУЛЬТЕТЫ (КОД_ ФКТ, ФАКУЛЬТЕТ, ЭК3АМЕН_l ,

                         ЭКАМЕН_2 , ЭК3АМЕН_3)

СПЕЦИАЛЬНОСТИ (КОД_ СПЕЦ, СПЕЦИАЛЬНОСТЬ,

                                  КОД_ФКТ, ПЛАН)

АБИТУРИЕНТЫ (РЕГ _НОМ, КОД_ СПЕЦ, МЕДАЛЬ, СТАЖ)

АНКЕТЫ (РЕГ_НОМ, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО,

                 ДАТА_РОЖД, ГОРОД, УЧ_3АВЕДЕНИЕ)

ОЦЕНКИ (РЕГ_НОМ, ОЦЕНКА_l , ОЦЕНКА_2 , ОЦЕНКА_3)

Чтобы эти шесть таблиц представляли собой систему, между ними должны быть установлены связи.

Фактически связи уже имеются через общие имена полей. Первые два отношения связаны между собой кодом факультета, второе и третье - кодом специальности, а четыре последних - регистрационным номером. Связи позволяют определить соответ­ствия между любыми данными в этих таблицах, например между фамилией некоторого абитуриента и его оценкой по математике; между названием города и результатами экзамена по русскому языку выпускников школ этого города и пр. Благодаря этим свя­зям возможно получение ответов на запросы, требующие поиска информации в нескольких таблицах одновременно.

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

Для явного указания связей между таблицами должна быть построена схема базы данных. В схеме указывается наличие свя­зей между таблицами и типы связей. Схема для нашей системы представлена на рис . 1.11.

Рис. 1.11. Схема базы данных

В схеме использованы два типа связей: один к одному и один ко многим. Первый обозначен двунаправленной одинарной стрел­ кой, второй - одинарной стрелкой в одну сторону и двойной в другую. При связи «один к одному» с одной записью в таблице связана одна запись в другой таблице . Например, одна запись об абитуриенте связана с одним списком оценок. При наличии связи «один ко многим» одна запись в некоторой таблице связана с множеством записей в другой таблице . Например, с одним фа­культетом связано множество специальностей, а с одной спе­циальностью - множество абитуриентов, поступающих на эту специальность.

Связь «один ко многим» - это связь между двумя соседними уровнями иерархической структуры. А таблицы, связанные отно­шениями «один к одному», находятся на одном уровне иерархии. В принципе все они могут быть объединены в одну таблицу, по­скольку главный ключ у них один – РЕГ_ НОМ. Но чем это не­удобно, было объяснено выше.

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

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

Система не допустит, чтобы одноименные поля в разных свя­занных между собой таблицах имели разные значения. Согласно этому принципу, будет автоматически контролироваться ввод дан­ных. В связанных таблицах может быть установлен режим каскад­ ной замены: если в одной из таблиц изменяется значение поля, по которому установлена связь, то в других таблицах одноименные поля автоматически изменят свои значения. Аналогично действует режим каскадного удаления: достаточно удалить запись из одной таблицы, чтобы связанные записи исчезли из всех остальных таб­лиц. Это естественно, поскольку, например, если закрывается ка­ кой-то факультет, то исчезают и все его специальности. Или если у абитуриента изменяют регистрационный номер в таблице АБИТУРИЕНТЫ, то автоматически номер должен обновиться и в других таблицах.

На этом проектирование базы данных завершается. Это был теоретический этап. Практическая работа по созданию базы дан­ных будет проходить в рамках компьютерного практикума.

Система основных понятий