Слабая сущность
В реляционной базе данных слабая сущность — это сущность, которую нельзя однозначно идентифицировать только по ее атрибутам; следовательно, он должен использовать внешний ключ в сочетании со своими атрибутами для создания первичного ключа . Внешний ключ обычно является первичным ключом объекта, с которым он связан.
Внешний ключ является атрибутом идентифицирующего (или владельца , родительского или доминирующего ) набора сущностей . Каждый элемент в слабом наборе сущностей должен иметь связь ровно с одним элементом в наборе сущностей-владельцев. [1] и, следовательно, связь не может быть связью «многие ко многим».
Две сущности могут быть связаны, не классифицируя ни одну из них как слабую, даже если одна зависит от другой, при условии, что каждая из них имеет свой собственный уникальный атрибут. [1] Например, физическую сущность можно связать с автомобилем , при этом ни одна из них не будет считаться слабой сущностью.
На диаграммах отношений сущностей (диаграммах ER) слабый набор сущностей обозначается жирным (или двойной линией) прямоугольником (объектом), соединенным жирной (или двойной линией) стрелкой с жирным (или двойной линией) стрелкой. алмаз (отношения). Этот тип отношений называется идентифицирующим отношением , и в нотации IDEF1X он представлен овальным объектом, а не квадратным объектом для базовых таблиц. Идентифицирующая связь — это связь, в которой первичный ключ заполняется дочерней слабой сущностью в качестве первичного ключа в этой сущности.
В общем (хотя и не обязательно) слабый объект не имеет в своем первичном ключе никаких элементов, кроме унаследованного первичного ключа и порядкового номера. Существует два типа слабых сущностей: ассоциативные сущности и сущности подтипа . Последний представляет собой важнейший тип нормализации , при котором сущность супертипа наследует свои атрибуты сущностям подтипа на основе значения дискриминатора .
В IDEF1X , правительственном стандарте для сбора требований, возможные отношения подтипов :
- Полная связь подтипов , когда известны все категории.
- Неполная связь подтипов , когда не все категории могут быть известны.
Классическим примером слабой сущности без связи подтипа могут быть записи «заголовок/подробности» во многих реальных ситуациях, таких как претензии, заказы и счета-фактуры, где заголовок фиксирует информацию, общую для всех форм, а детали фиксируют конкретную информацию. к отдельным предметам.
Стандартным примером полной связи подтипа является сущность- сторона . Учитывая дискриминатор ТИП СТОРОНЫ (который может быть индивидуальным, партнерством, корпорацией C, ассоциацией подраздела S, ассоциацией, правительственным подразделением, квазиправительственным учреждением), двумя объектами подтипа являются ЧЕЛОВЕК, который содержит индивидуальную информацию, такую как имя и фамилия. и дата рождения, а также ОРГАНИЗАЦИЯ, которая будет содержать такие атрибуты, как официальное название, а также организационные иерархии, такие как центры затрат.
Когда отношения подтипа отображаются в базе данных, супертип становится тем, что называется базовой таблицей. Подтипы считаются производными таблицами и соответствуют слабым сущностям. Ссылочная целостность обеспечивается посредством каскадных обновлений и удалений.
Пример
[ редактировать ] | Эта статья , возможно, содержит оригинальные исследования . ( январь 2024 г. ) |
Рассмотрим базу данных, в которой регистрируются заказы клиентов, где заказ относится к одному или нескольким товарам, которые продает предприятие. База данных будет содержать таблицу, идентифицирующую клиентов по номеру клиента ( первичный ключ ); другой, идентифицирующий продукты, которые могут быть проданы, по номеру продукта ( первичный ключ ); и он будет содержать пару таблиц, описывающих заказы.
Одну из таблиц можно назвать «Заказы», и она будет иметь номер заказа ( первичный ключ ), чтобы однозначно идентифицировать этот заказ, и будет содержать номер клиента ( внешний ключ ), чтобы определить, кому продаются продукты, а также другую информацию, такую как дата и время размещения заказа, способ его оплаты, куда он должен быть отправлен и т. д.
Вторую таблицу можно было бы назвать Товар заказа ; он будет идентифицирован составным ключом, состоящим как из номера заказа ( внешнего ключа ), так и из номера строки товара; с другими атрибутами, не являющимися первичными ключами, такими как номер продукта ( внешний ключ заказанного ), количество, цена, любая скидка, любые специальные опции и т. д. Их может быть ноль, один или несколько Записи OrderItem , соответствующие записи Order, но нет Запись OrderItem может существовать, если не существует соответствующей записи Order. (Ноль Регистр OrderItem обычно применяется только временно, при первом вводе заказа и до того, как будет записан первый заказанный товар.)
The Таблица OrderItem хранит слабые сущности именно потому, что OrderItem не имеет значения независимо от Order. Некоторые могут возразить, что OrderItem сам по себе имеет некоторое значение; в нем зафиксировано, что в какой-то момент, не указанный в записи, кто-то, не указанный в записи, заказал определенное количество определенного продукта. Эта информация может быть полезна сама по себе, но она имеет ограниченное применение. Например, если вы хотите найти сезонные или географические тенденции в продажах товара, вам понадобится информация из соответствующей записи заказа.
Заказ не существовал бы без продукта и человека, создающего заказ, поэтому можно утверждать, что заказ будет описываться как слабая сущность и что заказанные продукты будут многозначным атрибутом заказа.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Jump up to: а б Эльмасри, Рамез (2016). Основы систем баз данных . Шам Навате (Седьмое изд.). Хобокен, Нью-Джерси: Pearson Education . п. 79. ИСБН 978-0-13-397077-7 . OCLC 913842106 .