Проектирование реляционной базы данных с использованием нормализации

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

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

Первая нормальная форма (1НФ) требует, чтобы все атрибуты отношения были атомарными (неделимыми). Так как требование первой нормальной формы является базовым требованием классической реляционной модели данных, считается, что исходное универсальное отношение уже соответствует этому требованию.

Вторая нормальная форма (2НФ). Отношение R находится во второй нормальной форме в том и только в том случае, когда находится в 1НФ и каждый неключевой атрибут полностью зависит от первичного ключа.

Третья нормальная форма (3НФ). Отношение R находится в третьей нормальной форме в том и только в том случае, когда находится в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

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

4.4. Создание информационно-логической и логической моделей базы данных

Цель работы: разработать информационно-логическую модель реляционной БД Деканат; разработать логическую модель реляционной БД Деканат.

Выполнение и рекомендации:

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

2. Представим состав реквизитов этих объектов в виде «название объекта (перечень реквизитов)»: Студенты (код студента, фамилия,имя, отчество, номер группы, дата рождения, стипендия, оценка), Дисциплины (код дисциплины, название дисциплины), Преподаватели (код преподавателя, фамилия, имя, отчество, дата рождения, телефон, заработная плата).

3. Рассмотрим связь между объектами Студенты и Дисциплины. Студент изучает несколько дисциплин, что соответствует многозначной связи и отражено на рис. 4.1 двойной стрелкой. Понятно, что каждая дисциплина изучается множеством студен­тов. Это тоже многозначная связь, обозначаемая двойной стрелкой (связь «один» обозначена одинарной стрелкой). Таким образом, связь между объектами Студенты и ДисциплиныМногие-ко-многим (М: N).

 
 


Рис. 4.1.Типы связей между объектами Студенты, Дисциплины и Преподаватели

Множественные связи усложняют управление БД, например, в СУБД Access при множественных связях нельзя использовать Механизм каскадного об­новления. Поэтому использовать такие связи нежелательно и нужно строить реляци­онную модель, не содержащую связей типа Многие-ко-многим. В Access для контроля целостности данных с возможностью каскадного обновления и удаления данных необходимо создать вспомогательный объект связи, который состоит из клю­чевых реквизитов связываемых объектов и который может быть дополнен описатель­ными реквизитами. В нашем случае таким новым объектом для связи служит объект Оценки, реквизитами которого являются код студента, код дисциплины и оценки. Ка­ждый студент имеет оценки по нескольким дисциплинам, поэтому связь между объек­тами Студенты и Оценки будет Один-ко-многим (1: М). Каждую дисциплину сдает множество студентов, поэтому связь между объектами Дисциплины и Оценки также будет Один-ко-многим (1: М). В результате получаем информационно-логическую модель БД, приведенную на рис. 4.2.

 
 


Рис. 4.2.Информационно-логическая модель реляционной базы данных

4. В реляционной БД в качестве объектов рассматриваются отношения, кото­рые можно представить в виде таблиц. Таблицы между собой связываются посред­ством общих полей, т.е. одинаковых по форматам и, как правило, по названию, имеющихся в обеих таблицах. Рассмотрим, какие общие поля надо ввести в таблицы для обеспечения связности данных. В таблицах Студенты и Оценки таким полем будет «Код студента», в таблицах Дисциплины и Оценки — «Код дисциплины», в таблицах Преподаватели и Дисциплины — «Код дисциплины». Выбор цифровых кодов вместо фамилий или названий дисциплин обусловлен меньшим объемом ин­формации в таких полях: например, число «2» по количеству символов значительно меньше слова «математика». В соответствии с этим логическая модель БД представлена на рис. 4.3, где жирными буквами выделены ключевые поля.

Студенты Оценки Дисциплины Преподаватели

Код студента 1:M Код студента 1:M Код дисциплины 1:M Код дисциплины
Фамилия Код дисциплины Название дисциплины   Код преподавателя
Имя       Фамилия
Оценки       Имя
Отчество         Отчество
Номер группы         Преподаваемая дисциплина
Дата рождения         Телефон
Стипендия          
       
               

Рис. 4.3. Логическая модель базы данных


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: