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

• операторы определения данных (Data Definition Language – DDL)

  • CREATE создает объект базы данных

  • ALTER изменяет объект

  • DROP удаляет объект

• операторы манипуляции данными (Data Manipulation Language – DML)

  • SELECT считывает данные, удовлетворяющие заданным условиям

  • INSERT добавляет новые данные

  • UPDATE изменяет существующие данные

  • DELETE удаляет данные

• операторы определения доступа к данным (Data Control Language – DCL)

  • GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом

  • REVOKE отзывает ранее выданные разрешения

  • DENY задает запрет, имеющий приоритет над разрешением

• операторы управления транзакциями (Transaction Control Language – TCL)

  • COMMIT применяет транзакцию.

  • ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции.

  • SAVEPOINT делит транзакцию на более мелкие участки.

История СУБД (примеры)

1968г – 1 СУБД система IMS IBM

Эпоха персональных ЭВМ

Clipper и FoxPro Microsoft Access

Эпоха сетей (Объектно-ориентированные БД) (распределенные БД)

Дальнейшим расширением в структурных преобразованиях являются объектно-ориентированные базы данных. В объектно-ориентированной парадигме предметная область моделируется как множество классов взаимодействующих объектов.

(язык манипуляции данными SQL)

(клиент-серверная архитектура)

Microsoft Access 2000, Oracle 8.4, MS SQL 7.0, SQL Server,

Перспектива – переход на ИНТРАНЕТ – способ доступа к данным без клиентского приложения

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

Для разработки Интернет-приложений, которые связаны с базами данных, широко используются новые средства программирования: это язык PERL, язык РНР (Personal Home Page Tools), язык Javascript и ряд других. 

11