Типы связей

Отношения могут быть связаны следующими типами связей:

- один-к-одному (1:1);

- один-ко-многим (1:M);

- многие-ко-многим (M:M).

Рассмотрим сущность этих связей на примере следующих отношений. Пусть книга в библиотеке описывается отношением

КНИГА = (КНИГА_N, АВТОР_N, НАЗВАНИЕ, ИЗДАТЕЛЬСТВО_N).

Каждая книга имеет место на полке

МЕСТО = (МЕСТО_N, КНИГА_N).

Каждая книга выпускается издательством

ИЗДАТЕЛЬСТВО = (ИЗДАТЕЛЬСТВО_N, АДРЕС).

У каждой книги есть автор

АВТОР = (АВТОР_N, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО).

Связь один-к-одному означает, что в каждый момент времени одной записи отношения A соответствует только одна запись отношения B и наоборот. Например, каждая книга имеет одно место на полке и на каждом месте стоит только одна книга

.

Связь между отношениями осуществляется по полю КНИГА_N.

Связь один-ко-многим предполагает, что одной записи отношения A соответствуют несколько записей отношения B, но одной записи отношения B соответствуют только одна запись отношения A. Например, одно издательство может издать несколько книг, но книга издается только одним издательством.

.

Связь между отношениями осуществляется по полю ИЗДАТЕЛЬСТВО_N.

При связи многие-ко-многим одной записи отношения A соответствуют несколько записей отношения B и наоборот. Например, один автор может написать несколько книг, и у книги может быть несколько авторов

.

Связь между отношениями осуществляется по полю

АВТОР_N,

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

При проектировании базы данных решаются две основные проблемы:

• Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области, и было, по возможности, лучшим (эффективным, удобным и т. д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

• Как обеспечить эффективность выполнения запросов к базе данных? Эту проблему обычно называют проблемой физического проектирования баз данных. Здесь слишком много зависит от используемой СУБД

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

Основные свойства нормальных форм такие:

• каждая следующая нормальная форма в некотором смысле лучше предыдущей;

• при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

Процесс проектирования реляционной базы данных на основе метода нормализации преследует две основные цели:

• избежать избыточности хранения данных;

• устранить аномалии обновления отношений.

Язык реляционных баз данных SQL

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

Юридическим и фактическим стандартом стал язык SQL (Structured Query Language – «язык структурированных запросов»).

SQL представляет собой некоторую комбинацию реляционного исчисления кортежей и реляционной алгебры, и был разработан в середине 70-х годов в компании IBM в рамках проекта экспериментальной реляционной СУБД System R. Деятельность по стандартизации SQL началась практически одновременно с появлением его первых коммерческих реализаций. В 1986 г. был принят стандарт ANSI, а в 1987 г. Этот стандарт был одобрен международной организацией по стандартизации (ISO). Время от времени выпускается пересмотренная версия этого стандарта; наиболее свежее обновление было выпущено в 2008 г.

Формальное название стандарта SQL – ISO/IEC 9075 «Database Language SQL».

Несмотря на наличие международного стандарта, многие производители СУБД вносят изменения в язык SQL, тем самым отступая от стандарта. В результате у разных производителей СУБД в ходу разные диалекты SQL, в общем случае между собой несовместимые. В настоящее время проблема совместимости решается так: описание языка имеет модульную структуру, основная часть стандарта вынесена в раздел «SQL/Foundation», все остальные выведены в отдельные модули, остался только один уровень совместимости – «Core», что означает поддержку этой основной части. Поддержка остальных возможностей оставлена на усмотрение производителей СУБД.

Все операторы, составляющие основу SQL с момента его появления, можно разделить на следующие группы: