Слабая сущность - Википедия - Weak entity
 | Эта статья не цитировать любой источники. (Октябрь 2008 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
В реляционная база данных, а слабая сущность это объект, который нельзя однозначно идентифицировать только по его атрибутам; следовательно, он должен использовать иностранный ключ в сочетании с его атрибутами для создания первичный ключ. Внешний ключ обычно является первичным ключом объекта, с которым он связан.
В диаграммы отношений сущностей (диаграммы ER), слабый набор объектов обозначается полужирным (или двухстрочным) прямоугольником (объект), соединенным жирной (или двухлинейной) стрелкой с жирным (или двухлитым) ромбом (отношение). Этот тип отношений называется идентификация отношений И в IDEF1X нотации он представлен овальным объектом, а не квадратным объектом для базовых таблиц. Идентифицирующая взаимосвязь - это взаимосвязь, при которой первичный ключ заполняется дочерней слабой сущностью как первичный ключ в этой сущности.
В общем (хотя и не обязательно) слабая сущность не имеет никаких элементов в своем первичном ключе, кроме унаследованного первичного ключа и порядкового номера. Есть два типа слабых сущностей: ассоциативные объекты и сущности подтипа. Последний представляет собой решающий тип нормализация, где сущность супертипа наследует свои атрибуты сущности подтипа исходя из стоимости дискриминатор.
В IDEF1X, государственный стандарт для регистрации требований, возможно отношения подтипа находятся:
- Полное отношение подтипа, когда известны все категории.
- Неполное отношение подтипа, когда не все категории могут быть известны.
Классическим примером слабой сущности без связи подтипов могут быть записи «заголовок / подробности» во многих реальных ситуациях, таких как претензии, заказы и счета-фактуры, где заголовок фиксирует информацию, общую для всех форм, а подробности - конкретную информацию. на отдельные предметы.
Стандартный пример полное отношение подтипа это партия юридическое лицо. С учетом дискриминатора PARTY TYPE (который может быть индивидуальным, партнерским, C Corporation, Sub Chapter S Association, Association, Governmental Unit, Quasi-Government Agency) двумя объектами подтипа являются PERSON, который содержит индивидуальную информацию, такую как имя и фамилия. дата рождения и ОРГАНИЗАЦИЯ, которые будут содержать такие атрибуты, как юридическое имя, и организационные иерархии, такие как центры затрат.
Когда отношения подтипов отображаются в базе данных, супертип становится тем, что называется базовой таблицей. Подтипы считаются производными таблицами, которые соответствуют слабым объектам. Ссылочная целостность принудительно выполняется через каскадные обновления и удаления.
Пример
Рассмотрим базу данных, в которой записываются заказы клиентов, где заказ относится к одному или нескольким товарам, которые продает предприятие. База данных будет содержать таблицу, идентифицирующую клиентов по номеру клиента (первичный ключ ); другой идентифицирует продукты, которые могут быть проданы по номеру продукта (первичный ключ ); и он будет содержать пару таблиц с описанием заказов.
Одна из таблиц могла бы называться Заказы, и в ней был бы номер заказа (первичный ключ ), чтобы однозначно идентифицировать этот заказ, и будет содержать номер клиента (иностранный ключ ), чтобы определить, кому продаются продукты, а также другую информацию, такую как дата и время, когда заказ был размещен, как он будет оплачиваться, куда он должен быть отправлен и т. д.
Другая таблица может называться OrderItem; он будет идентифицирован составным ключом, состоящим из номера заказа (иностранный ключ ) и номер позиции позиции; с другими атрибутами непервичного ключа, такими как номер продукта (иностранный ключ ) который был заказан, количество, цена, скидки, специальные опции и т. д. Может быть ноль, одна или несколько записей OrderItem, соответствующих записи Order, но запись OrderItem не может существовать, если соответствующая запись Order не существует. (Нулевой случай OrderItem обычно применяется только временно, когда заказ вводится впервые и до того, как первый заказанный элемент был записан.)
В таблице OrderItem хранятся слабые сущности именно потому, что OrderItem не имеет значения независимо от Order. Некоторые могут возразить, что OrderItem сам по себе имеет какое-то значение; в нем фиксируется, что в какой-то момент, не идентифицированный записью, кто-то, не идентифицированный записью, заказал определенное количество определенного продукта. Эта информация может быть полезна сама по себе, но имеет ограниченное применение. Например, если вы хотите найти сезонные или географические тенденции продаж товара, вам понадобится информация из соответствующей записи заказа.
Заказ не существовал бы без продукта и лица, создавшего заказ, поэтому можно утверждать, что заказ будет описан как слабая сущность, а заказанные продукты будут многозначным атрибутом заказа.
Рекомендации
- Элмасри, Р. и Нават, С.Б., Пирсон, Основы систем баз данных, 7-е изд.