Проектирование баз данных

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

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

ER-диаграмма

Реляционные модели изображают с помощью ER-диаграмм (диаграмм «сущность-связь»). В такой диаграмме сущность изображается в виде прямоугольника, с уникальным именем, выраженным существительным. Атрибуты сущности (тоже называемые существительными) записываются внутри прямоугольника. Среди атрибутов выделяется ключ сущности — неизбыточный набор атрибутов, однозначно определяющий экземпляр. Связь изображается линией, связывающей две сущности, и называется глаголом.

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

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

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

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

Первая нормальная форма

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

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

Не нужно проектировать базы, где порядок строк играет роль. Язык запросов плохо учитывает порядок строк, и если к нему привязываться, то запрос будет сложно выполнять параллельно. Если в данных важен порядок, достаточно ввести порядковый индекс.

Вторая нормальная форма

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

Третья нормальная форма

Требования третьей группы требуют исключать транзитивные зависимости.

Пусть в таблице X → Y → Z поле Z зависит от поля Y, не являющегося ключевым (X). Чтобы привести подобную таблицу к третьей форме, надо вынести колонку Z из таблицы в отдельную таблицу Y → Z.