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

В реляционной модели любой набор данных представлен в виде двумерных таблиц. Каждая таблица обладает следующими свойствами:

• все элементы столбца имеют одинаковый тип данных и длину;

• столбцам присвоены уникальные имена;

• в таблице нет двух одинаковых строк;

• порядок расположения строк и столбцов в таблице не имеет значения.

Таблица такого рода называется отношением. База данных, построенная с по­мощью отношений, называется реляционной базой данных.

В понятие базы данных обязательным элементом входит описание правил взаимо­связи между таблицами базы. Независимо от того, сколько таблиц входит в базу данных, каждая стро­ка любой таблицы содержит данные об одном объекте (человеке, техническом устройстве, документе и т. д.), а столбцы содержат различные характеристики этих объектов (названия, адреса, даты и т. д.). Строки таблицы принято называть записями, а столбцы — полями записей. Заголовки столбцов таблицы называют атри­бутами. Все записи имеют одинаковые поля, содержащие раз­ные значения атрибутов. Каждое поле записи имеет строго определенный тип данных — текст, число, дата и т. п. (Приложение 1).

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

В Microsoft Access можно выделить три типа ключевых полей: счетчик, простой ключ, составной ключ.

Счетчик используется, если в таблице нет поля, которое могло бы однозначно определять каждую запись. В этом случае в таблицу добавляется новое поле и ему определяется тип счетчик. При добавлении каждой записи в это поле автоматически вносится порядковое число. Указание такого поля в качестве ключевого является наиболее простым способом создания ключевых полей. Если до сохранения созданной таблицы ключевые поля не были определены, то при сохранении будет предложено создать ключевое поле счетчик. Простой ключ применяется, если поле содержит уникальные значения, такие как коды или инвентарные номера. Это поле можно определить как ключевое. Если выбранное поле содержит повторяющиеся или пустые значения, то оно не будет определено как ключевое. Ключ, состоя­щий из нескольких полей, называют составным. Его применяют в случаях, когда невозможно гарантировать уникальность значений каждого поля. Если определить подходящий набор полей для составного ключа сложно, просто добавьте поле счетчика и сделайте его ключевым.

При создании связи между таблицами связываемые поля могут иметь разные имена. Однако связываемые поля должны иметь одинаковый тип данных, за исключением случая, когда поле первичного ключа является полем типа счетчик. Поле счетчика связывается с числовым полем, если значения свойства Размер поля обоих полей совпадают. Например, допускается связывание поля счетчика с числовым полем, если свойство Размер поля обоих полей имеет значение Длинное целое. Даже в том случае, когда связываются поля типа «Числовой», их свойства Размер поля должны иметь одинаковые значения.

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

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

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

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

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

Например, отношение Студент = (Номер*, Ф.И.О., Группа) необходимо привести к первой нормальной форме. Атрибут Ф.И.О. разбивается на три простых атрибута. В результате получим следующее отношение Студент = (Номер*, Фамилия, Имя, Отчество, Группа).

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

Например, отношение Студент = (Номер*, Фамилия, Имя, Отчество, Группа) находится во второй нормальной форме, так как описательные атрибуты однозначно определены и зависят от ключа Номер.

Третья нормальная форма (3НФ). Таблица находится в третьей нормальной форме, если она удовлетворяет определению 2НФ и ни одно из ее не- ключевых атрибутов не зависит от любого другого неключевого атрибута (нет скрытых зависимостей). Например, если в состав описательных атрибутов отношения Студент включить фамилию старосты группы (Староста), которая определяется только номером группы, то одна и та же фамилия старосты будет повторяться многократно. В этом случае появляются затруднения при корректировке фамилии старосты в случае необходимости, а также дополнительный расход памяти для хранения дублированных данных. Для устранения этих недостатков необходимо провести «расщепление» исходной таблицы.

Отношение Студент = (Номер*, Фамилия, Имя, Отчество, Группа, Староста) представляется в виде двух: Студент = (Номер*, Фамилия, Имя, Отчество, Группа) + Группа (Группа*, Староста). После разделения таблицы Студент на две, все таблицы удовлетворяют требованиям 2НФ, а так как в них нет неключевых полей, функционально зависящих друг от друга, то они находятся в 3НФ.