Типы связей
Отношения могут быть связаны следующими типами связей:
- один-к-одному (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 с момента его появления, можно разделить на следующие группы: