Соотношение терминов в теории и практике

Теория реляционных БД	Принятые соглашения
Отношение	Таблица
Кортеж	Запись (Строка)
Домен	Столбец
Атрибут	Поле

Определения.

Атрибут – это характеристика (свойство) объекта, отраженное в названии поля.

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

Кортеж – это элемент отношения, строка таблицы; упорядоченный набор из N элементов, полей.

Отношение – это множество однотипных записей, являющихся экземплярами одного объекта.

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

Поле – элементарная единица логической организации данных.

Поле имеет следующие характеристики:

• имя;

• тип;

• длина;

• точность для числовых данных.

Правила проектирования БД

Для создания надежного и эффективного приложения необходимо использовать правила нормализации баз данных.

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

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

Правило 1: Уникальность полей

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

Вывод. Каждое поле таблицы должно представлять уникальный тип информации.

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

Под ключевым понимается поле, значения которого уникальны.

Правило 2: Первичные ключи (поля)

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

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

Всегда, когда это возможно, в качестве первичного ключа следует использовать самые простые данные, имеющие «естественные» уникальные значения, например код книги.

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

Правило 3: Функциональная зависимость

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

Вывод. Для каждого значения первичного ключа (поля, значения которого уникальны) значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.

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

Правило 4: Независимость полей

И, наконец, последнее правило позволяет проверить, не возникнут ли проблемы при изменении данных в таблицах.

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

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

Описанные выше приемы проектирования помогут эффективно связывать данные. Можно заметить, что в результате нормализации базы данных, как правило, получается множество отдельных таблиц. До появления реляционных баз данных пришлось бы при проектировании таблиц самому отслеживать связи между файлами или таблицами. В реляционных базах таких проблем не возникает. Имея хороший проект, можно не заботиться о том, как объединить данные в нужный момент.