Представление таблицы (сущности) в виде диаграммы

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

Такие диаграммы иногда называют ER-диаграммами (от англ. Entity/Relationship – сущность/связь) – с их помощью изображают сущности и связи между ними. (О связях и их изображении мы расскажем ниже). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи и необходимое пояснение.

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

Нормализация

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

Пройдём все этапы нормализации на примере БД школьной библиотеки. Основное назначение такой БД – хранение данных о книгах. Сделаем одно важное допущение, существенно упрощающее разработку БД: предположим, что у каждой книги может быть только один автор.

Первая нормальная форма (1NF)

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

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

Нужно сделать так, чтобы каждый атрибут содержал только элементарные значения, т.е. данные, которые в данном случае нельзя разделить на части. Конечно, можно “разобрать по буквам” фамилию автора – но в этом нет смысла; поэтому “фамилия автора” – элементарное значение.

Изменим таблицу сущности “Книга”.

Процесс поиска книг по значениям атрибутов станет намного проще.

Говорят, что модель данных находится в первой нормальной форме (1NF) тогда и только тогда, когда каждый атрибут каждого экземпляра сущности (т.е. каждая клетка таблицы) всегда содержит только элементарные значения. Если атрибут можно логично разделить на несколько – следует это сделать; после этого БД будет находиться в первой нормальной форме.

Уникальный идентификатор

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

У каждой сущности должен быть уникальный идентификатор (ключ).

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности «Расписание авиарейсов» ключом является атрибут «Номер рейса» или набор: «Пункт отправления», «Время вылета» и «Пункт назначения» (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет). Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ.

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

Свойства атрибута, являющегося ключем:

· Он уникален для каждого экземпляра сущности (т.е. во всех строках таблицы он не должен повторяться).

· Для каждого экземпляра сущности он имеет значение в течение всего срока существования экземпляра в БД, причём это значение не меняется, пока экземпляр существует. Это означает, что данный столбец не может быть пустым; причём он заполняется в момент создания строки, и его значение не изменяется вплоть до удаления строки.

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

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

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

На ER-диаграммах названия идентифицирующих атрибутов обычно подчеркивают или помечают звездочкой.

(Интересно, что библиотекари тоже столкнулись с необходимостью такого идентифицирующего атрибута. Поэтому каждая библиотечная книга имеет специальный “шифр” или “инвентарный номер”; он обычно подписывается на внутренней стороне обложки.)

О внешних ключах:

· Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

· Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

При попытке УДАЛЕНИЯ экземпляра сущности, на которую ссылается внешний ключ необходимо определить метод обработки такого события. Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:

· КАСКАДИРОВАНИЕ – Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика;

· ОГРАНИЧЕНИЕ – Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается;

· УСТАНАВЛИВАНИЕ – Для всех поставок удаляемого поставщика внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

ОБНОВЛЕНИЕ первичного ключа сущности, на которую ссылается некоторый внешний ключ может осуществляться похожими методами.