Файл: Виды связей между таблицами в реляционных базах данных (Основные понятия БД и СУБД).pdf

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 07.07.2023

Просмотров: 222

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Ключ - это минимальный набор атрибутов, значения которых можно использовать для однозначного поиска требуемого экземпляра сущности. Минимальность означает, что исключение любого атрибута из набора не позволяет идентифицировать сущность остальными. Для объекта Schedule ключом является атрибут Flight_number или набор: Departure_point, Departure_time и Destination_point (при условии, что один самолет вылетает из точки в точку за раз).

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

2.2 Описание ссылок и язык моделирования

При построении инфологических моделей можно использовать язык ERдиаграмм (от английского Entity-Relationship, то есть сущность-связь). В них объекты изображены в виде отмеченных прямоугольников, ассоциации - отмечены ромбами или шестиугольниками, атрибуты - отмечены овалами, а связи между ними - в виде ненаправленных ребер, по которым определяется степень связи (1 или буква, заменяющая слово «многие» ) и можно поставить необходимое объяснение.

Между двумя объектами, например A и B, возможны четыре типа отношений.

Первый тип - это отношение ОДИН К ОДНОМ (1: 1): в каждый момент времени каждый представитель (экземпляр) объекта A соответствует 1 или 0 представителям объекта B:

Студент не может «зарабатывать» стипендию, получать обычную стипендию или одну из увеличенных стипендий.


Второй тип - это отношение ОДИН К МНОГИМ (1: M): один представитель объекта A соответствует 0, 1 или нескольким представителям объекта B.

Квартира может быть пустой, в ней могут проживать один или несколько жильцов.

Поскольку между двумя сущностями возможны отношения в обоих направлениях, существует еще два типа отношений МНОГИЕ К ОДНОМУ (M: 1) и МНОГИМ К МНОГИМ (M: N).

Пример. Если отношения между сущностями МУЖЧИНА и ЖЕНЩИНА называются БРАКОМ, то есть четыре возможных представления таких отношений:

Характер отношений между организациями не ограничивается перечисленными. Есть и более сложные связи: Множество связей между одними и теми же объектами

(пациент, имеющий одного лечащего врача, может также иметь несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать нескольких других пациентов);

(врач может назначить несколько пациентов на несколько тестов, анализ может быть назначен несколькими врачами нескольким пациентам, а пациент может быть назначен на несколько тестов несколькими врачами);

· Связи более высокого порядка, семантика (значение) которых иногда бывает очень сложной.

2.3 Классификация сущностей

Существует три основных класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения.

Ядро (core) - это независимый объект (более подробно он будет определен ниже).

В рассмотренных выше примерах стержнями являются «Студент», «Квартира», «Мужчины», «Доктор», «Женитьба» и другие, названия которых заключены в прямоугольники. Ассоциативный объект (ассоциация) - это отношение «многие ко многим» («ко многим» и т. Д.) Между двумя или более объектами или экземплярами объектов. Ассоциации считаются полноценными организациями:

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

Характеристический объект (характеристика) - это отношение «многие-кодному» или «один-к-одному» между двумя объектами (особый случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области - описать или уточнить какую-то другую сущность. Потребность в них возникает из-за того, что объекты реального мира иногда обладают многозначными свойствами. У мужа может быть несколько жен, книга - несколько характеристик переиздания (переработанное, дополненное, исправленное, ...) и т. Д.

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются своего статуса жен, если их муж умирает.

Назначающий объект или обозначение - это отношения «многие к одному» или «один к одному» между двумя организациями, которые отличаются от характеристики тем, что не зависят от обозначенного объекта.

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

С помощью этих пользователей определены следующие объекты и характеристики проектируемой базы:

  1. Блюда, которые необходимо описать с использованием данных, включенных в их рецепты: номер блюда (например, из книги рецептов), название блюда, тип блюда (закуска, суп, горячее и т. Д.), Рецепт (технология приготовления), выход (вес порции), название, калорийность и вес каждого продукта, входящего в блюдо.
  2. Для каждого поставщика товаров: наименование, адрес, наименование поставляемого товара, дата доставки и цена на момент доставки.
  3. Ежедневное потребление (потребление) пищи: блюдо, количество порций, дата.

Анализ объектов позволяет выделить:

· Жезлы Блюда, Еды и Города;

Состав ассоциаций (связывает блюда с продуктами) и

Поставки (связывает Поставщиков с Продуктами);

· Обозначение Поставщиков;

· Характеристики рецептов и потребления.

2.4 Первичный и внешний ключи

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


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

Теперь о внешних ключах:

Если объект C связывает объекты A и B, то он должен включать внешние ключи, соответствующие первичным ключам объектов A и B.

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

Таким образом, при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных необходимо ответить на главный вопрос: «Что такое внешние ключи?» И далее, для каждого внешнего ключа необходимо решить три вопроса:

  1. Может ли данный внешний ключ принимать нулевые значения (значения NULL)? Другими словами, может ли существовать некоторый экземпляр объекта данного типа, для которого целевая сущность, указанная внешним ключом, неизвестна? В случае отгрузки это, вероятно, невозможно - отгрузка от неизвестного поставщика или отгрузка неизвестного продукта не имеет смысла. Но в случае сотрудников такая ситуация, однако, может иметь смысл - вполне возможно, что какой-либо сотрудник в настоящее время вообще не зарегистрирован ни в каком отделе. Обратите внимание, что ответ на этот вопрос не зависит от прихоти разработчика базы данных, но определяется фактическим курсом действий, предпринятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные комментарии относятся к вопросам, обсуждаемым ниже.
  1. Что должно произойти при попытке УДАЛИТЬ целевой объект, на который ссылается внешний ключ? Например, при удалении поставщика, осуществившего хотя бы одну доставку. Есть три возможности:

КАСКАДЫ

Операция удаления выполняется "каскадно", чтобы также удалить поставки от этого поставщика.

ОГРАНИЧЕНО

Удаляются только те поставщики, которые еще не осуществили поставки. В противном случае операция удаления отклоняется.

УСТАНОВЛЕНЫ

Для всех поставок удаляемого поставщика значение NULL внешнего ключа устанавливается равным null, а затем поставщик удаляется. Этот вариант, конечно, неприменим, если данный внешний ключ не должен содержать значений NULL.

3. Что должно произойти, если вы попытаетесь ОБНОВИТЬ первичный ключ целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть сделана попытка обновить номер поставщика, для которого существует по крайней мере одна соответствующая поставка. Для определенности рассмотрим этот случай более подробно. Доступны те же три варианта, что и для удаления:


КАСКАДЫ

Операция обновления выполняется "каскадно", чтобы обновить внешний ключ и в поставках этого поставщика.

ОГРАНИЧЕНО

Только те поставщики, которые еще не поставили, обновляют первичные ключи. В противном случае операция обновления отклоняется.

УСТАНОВЛЕНЫ

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

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

Наконец, о характеристиках - обозначающих сущности, существование которых зависит от обозначаемого типа.

2.5 Ограничения целостности

Целостность (от англ. Integrity - неприкосновенность,

неприкосновенность, сохранность, целостность) - понимается как верность данных в любое время. Но эта цель может быть достигнута только в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, введенного в базу данных (хотя каждое значение можно проверить на достоверность). Например, вы не можете найти, что входное значение 5 (представляющее номер дня недели) на самом деле должно быть 3. С другой стороны, значение 9, очевидно, будет неправильным, и СУБД должна его отклонить. Однако для этого ей нужно сказать, что номера дней недели должны принадлежать набору

(1,2,3,4,5,6,7).

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

Есть три группы правил честности:

  1. Целостность по сути.
  2. Целостность ссылок.
  3. Целостность, определяемая пользователем.

В разделе 2.3 обсуждается обоснование двух правил целостности, общих для любой реляционной базы данных.

  1. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
  2. Значение внешнего ключа должно: