Реляционная модель данных. Таблицы, записи, поля, связи

Впервые термин "реляционная модель данных" появился в статье сотрудника фирмы IBM д-ра Кодда опубликованной 6 июня 1970г. Будучи математиком по образованию Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц, которые он назвал отношениями -relation (англ.). Реляционной является БД, в которой все данные доступные пользователю, организованы в виде набора связанных двумерных таблиц, а все операции над данными сводятся к операциям реляционной алгебры.

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

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

Пример:

Таблица в реляционной модели:

— Таблица описывает отдельную сущность предметной области (объект или событие). У таблицы есть имя.

— Запись это данные о конкретном экземпляре объекта или события, каждая запись представляет собой набор значений, содержащихся в полях (запись это одна строка таблицы). У записи есть ключ.

— Поле это контейнер для хранения данных об атрибутах (свойствах) сущностей предметной области, из полей складываются столбцы таблицы. У поля (столбца таблицы) есть имя.

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

— Первичный ключ– поле однозначно идентифицирующее запись в таблице (значение этого поля уникально в столбце)

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

Нормализация баз данных

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

· Нормальные формы – это рекомендации по проектированию баз данных.

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

По Фомину:

— Если база данных нуждается в нормализации – значит она неправильно спроектирована.

— Если вы научитесь правильно проектировать базы данных, то нормализовывать их не надо.

(от меня на основе лекции Фомина) Правильные связи в таблицах БД осуществляются по ключу! То есть таблицы связываются с помощью ключей (пример: таблица Сотрудники содержит поле «физ лицо», которое является числовым и связано с полем «Код физ лица» таблицы ФизЛица)

Из инета про нормализацию (по мне так неплохо):

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

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

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