Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Вопросы и ответы для экзамена по курсу.docx
Скачиваний:
71
Добавлен:
11.09.2019
Размер:
86.84 Кб
Скачать
  1. Типы связей, примеры

При установлении связи между двумя таблицами одна из них будет являться глав­ной (master), а вторая — подчиненной (detail).

Различие между ними несколько уп­рощенно можно пояснить следующим образом.

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

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

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

Различают четыре типа связей между таблицами реляционной базы данных:

  • один к одному каждой записи одной таблицы соответствует только одна за­пись другой таблицы;

  • один ко многим одной записи главной таблицы могут соответствовать несколь­ко записей подчиненной таблицы;

  • многие к одному нескольким записям главной таблицы может соответство­вать одна и та же запись подчиненной таблицы;

  • многие ко многим одна запись главной таблицы связана с несколькими запи­сями подчиненной таблицы, а одна запись подчиненной таблицы связана с не­сколькими записями главной таблицы.

Различие между типами связей «один ко многим» и «многие к одному» зависит от того, какая из таблиц выбирается в качестве главной, а какая — в качестве подчиненной. Например, если из связанных таблиц СТУДЕНТЫ и УСПЕВАЕМОСТЬ в качестве глав­ной выбрать таблицу СТУДЕНТЫ, то получим тип связи «один ко многим». Если же выбрать в качестве главной таблицу УСПЕВАЕМОСТЬ, получится тип связи «многие к одному».

Рассмотрим теперь некоторые важнейшие свойства отношений реляционной мо­дели данных.

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

Свойство отсутствия упо­рядоченности кортежей отношения также является следствием определения от­ношения как множества кортежей. Отсутствие требования к поддержанию по­рядка на множестве кортежей отношения дает СУБД дополнительную гибкость при хранении баз данных во внешней памяти и при выполнении запросов к базе данных.

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

Атрибуты отношений также не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута.

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

Атомарность значений атрибутов. Это следует из определения до­мена как потенциального множества значений простого типа данных, то есть сре­ди значений домена не могут содержаться множества значений (отношения).