Реляционная модель данных. Таблицы, записи, поля, связи.
Впервые термин "реляционная модель данных" появился в статье сотрудника фирмы IBM д-ра Кодда опубликованной 6 июня 1970г. Будучи математиком по образованию Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц, которые он назвал отношениями -relation (англ.). Реляционной является БД, в которой все данные доступные пользователю, организованы в виде набора связанных двумерных таблиц, а все операции над данными сводятся к операциям реляционной алгебры.
(с инета) Название реляционная связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся только к одному конкретному объекту.
В реляционной СУБД все обрабатываемые данные представляются в виде плоских таблиц. Информация об объектах определенного вида представляется в табличном виде: в столбцах таблицы сосредоточены различные атрибуты объектов, а строки предназначены для сведения описаний всех атрибутов к отдельным экземплярам объектов.
Пример:
Таблица в реляционной модели:
Таблица описывает отдельную сущность предметной области (объект или событие). У таблицы есть имя.
Запись это данные о конкретном экземпляре объекта или события, каждая запись представляет собой набор значений, содержащихся в полях (запись это одна строка таблицы). У записи есть ключ.
Поле это контейнер для хранения данных об атрибутах (свойствах) сущностей предметной области, из полей складываются столбцы таблицы. У поля (столбца таблицы) есть имя.
Связи между таблицами устанавливаются при помощи специальных полей – ключей.
Первичный ключ – поле однозначно идентифицирующее запись в таблице (значение этого поля уникально в столбце)
Внешний ключ – поле, в котором содержится значение первичного ключа другой таблицы, это поле необходимо для создания связи между записями таблиц.
Нормализация баз данных
Нормализация – это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных.
Нормальные формы – это рекомендации по проектированию баз данных.
Цель нормализации сводится к получению такого проекта базы данных, в котором исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных и предсказуемости поведения системы во время эксплуатации.
По Фомину:
Если база данных нуждается в нормализации – значит она неправильно спроектирована.
Если вы научитесь правильно проектировать базы данных, то нормализовывать их не надо.
(от меня на основе лекции Фомина) Правильные связи в таблицах БД осуществляются по ключу! То есть таблицы связываются с помощью ключей (пример: таблица Сотрудники содержит поле «физ лицо», которое является числовым и связано с полем «Код физ лица» таблицы ФизЛица)
Из инета про нормализацию (по мне так неплохо):
Первая нормальная форма ( 1НФ ) требует, чтобы каждое поле таблицы БД было неделимым (атомарным) и не содержало повторяющихся групп. Неделимость означает, что в таблице не должно быть полей, которые можно разбить на более мелкие поля. Например, если в одном поле мы объединим фамилию студента и группу, в которой он учится, требование неделимости соблюдаться не будет. Первая нормальная форма требует, чтобы мы разбили эти данные по двум полям.
Вторая нормальная форма ( 2НФ ) требует, чтобы таблица удовлетворяла всем требованиям первой нормальной формы, и чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей.
Третья нормальная форма ( 3НФ ) требует, чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, то есть, чтобы значение любого поля, не входящего в первичный ключ, не зависело от другого поля, также не входящего в первичный ключ.