Введение
Тип элемента в реляционной базе данных, в информатике.
В реляционной базе данных слабая сущность – это сущность, которая не может быть однозначно идентифицирована только своими атрибутами; поэтому она должна использовать внешний ключ в сочетании со своими атрибутами для создания первичного ключа. Внешний ключ обычно является первичным ключом сущности, с которой она связана. Внешний ключ является атрибутом идентифицирующего (или владельческого, родительского, доминирующего) набора сущностей. Каждый элемент в наборе слабых сущностей должен иметь отношение ровно к одному элементу в наборе сущностей-владельцев, и, следовательно, отношение не может быть отношением "многие ко многим". Две сущности могут быть связаны, не будучи классифицированы как слабые, даже если одна зависит от другой, пока каждая имеет свой уникальный атрибут. Например, сущность "человек" может быть связана с сущностью "автомобиль", не считая ни одну из них слабой сущностью. На диаграммах "сущность-связь" (ER-диаграммах) набор слабых сущностей обозначается жирным (или двойным) прямоугольником (сущность), соединенным жирной (или двойной) стрелкой с жирным (или двойным) ромбом (отношение). Этот тип отношения называется идентифицирующим отношением, и в нотации IDEF1X он представлен овальной, а не квадратной сущностью для базовых таблиц. Идентифицирующее отношение – это отношение, в котором первичный ключ передается дочерней слабой сущности в качестве первичного ключа в этой сущности. В общем случае (хотя и не обязательно) слабая сущность не имеет в своем первичном ключе никаких элементов, кроме унаследованного первичного ключа и порядкового номера. Существует два типа слабых сущностей: ассоциативные сущности и сущности подтипов. Последнее представляет собой важный тип нормализации, когда сущность супертипа наследует свои атрибуты сущностям подтипа на основе значения дискриминатора. В IDEF1X, государственном стандарте для фиксации требований, возможны следующие отношения подтипов: Полное отношение подтипов, когда все категории известны. Неполное отношение подтипов, когда не все категории могут быть известны. Классическим примером слабой сущности без отношения подтипа являются записи "заголовок/детали" во многих реальных ситуациях, таких как претензии, заказы и счета-фактуры, где заголовок содержит информацию, общую для всех форм, а детали – информацию, специфичную для отдельных элементов. Стандартным примером полного отношения подтипа является сущность "сторона". Учитывая дискриминатор "ТИП СТОРОНЫ" (который может быть физическим лицом, партнерством, корпорацией, ассоциацией, правительственным учреждением, квази-правительственным агентством), два подтипа сущностей – это "ЛИЦО", которое содержит информацию, специфичную для физического лица, такую как имя, фамилия и дата рождения, и "ОРГАНИЗАЦИЯ", которая будет содержать такие атрибуты, как юридическое название и организационные иерархии, такие как центры затрат. Когда отношения подтипов отображаются в базе данных, супертип становится так называемой базовой таблицей. Подтипы рассматриваются как производные таблицы, которые соответствуют слабым сущностям. Референциальная целостность обеспечивается посредством каскадных обновлений и удалений.
In a relational database, a weak entity is an entity that cannot be uniquely identified by its attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create a primary key. The foreign key is typically a primary key of an entity it is related to. The foreign key is an attribute of the identifying (or owner, parent, or dominant) entity set. Each element in the weak entity set must have a relationship with exactly one element in the owner entity set, and therefore, the relationship cannot be a many to many relationship. Two entities can be associated without either being classified as weak, even if one depends on the other, as long as each has its own unique attribute. For instance, a person entity can be linked to a car without one of them being considered as weak entity. In entity relationship diagrams (ER diagrams), a weak entity set is indicated by a bold (or double lined) rectangle (the entity) connected by a bold (or double lined) type arrow to a bold (or double lined) diamond (the relationship). This type of relationship is called an identifying relationship and in IDEF1X notation it is represented by an oval entity rather than a square entity for base tables. An identifying relationship is one where the primary key is populated to the child weak entity as a primary key in that entity. In general (though not necessarily) a weak entity does not have any items in its primary key other than its inherited primary key and a sequence number. There are two types of weak entities: associative entities and subtype entities. The latter represents a crucial type of normalization, where the super type entity inherits its attributes to subtype entities based on the value of the discriminator. In IDEF1X, a government standard for capturing requirements, possible sub type relationships are:
Complete subtype relationship, when all categories are known. Incomplete subtype relationship, when all categories may not be known. A classic example of a weak entity without a sub type relationship would be the "header/detail' records in many real world situations such as claims, orders and invoices, where the header captures information common across all forms and the detail captures information specific to individual items. The standard example of a complete subtype relationship is the party entity. Given the discriminator PARTY TYPE (which could be individual, partnership, C Corporation, Sub Chapter S Association, Association, Governmental Unit, Quasi governmental agency) the two subtype entities are PERSON, which contains individual specific information such as first and last name and date of birth, and ORGANIZATION, which would contain such attributes as the legal name, and organizational hierarchies such as cost centers. When sub type relationships are rendered in a database, the super type becomes what is referred to as a base table. The sub types are considered derived tables, which correspond to weak entities. Referential integrity is enforced via cascading updates and deletes.
Пример
Рассмотрим базу данных, в которой регистрируются заказы клиентов, где заказ включает в себя один или несколько товаров, продаваемых предприятием. База данных будет содержать таблицу, идентифицирующую клиентов по номеру клиента (первичный ключ); другую таблицу, идентифицирующую продукты, доступные для продажи, по номеру продукта (первичный ключ); и пару таблиц, описывающих заказы. Одна из таблиц может называться "Заказы", она будет иметь номер заказа (первичный ключ) для уникальной идентификации заказа и содержать номер клиента (внешний ключ) для указания покупателя, а также другую информацию, такую как дата и время размещения заказа, способ оплаты, адрес доставки и т.д. Другая таблица может называться "ДеталиЗаказа"; она будет идентифицироваться составным ключом, состоящим из номера заказа (внешний ключ) и номера позиции в заказе, а также другими атрибутами, не являющимися ключами, такими как номер продукта (внешний ключ), количество, цена, скидка, специальные опции и т.д. Для каждой записи в таблице "Заказы" может быть ноль, один или несколько соответствующих записей в таблице "ДеталиЗаказа", но запись в "ДеталиЗаказа" не может существовать без соответствующей записи в "Заказах". (Случай с нулем записей обычно возникает временно, при первом вводе заказа и до добавления первой позиции). Таблица "ДеталиЗаказа" хранит слабые сущности, поскольку позиция в заказе не имеет смысла без привязки к заказу. Некоторые могут утверждать, что позиция в заказе имеет самостоятельное значение, так как фиксирует факт заказа определенного количества определенного продукта в некий момент времени. Эта информация может быть полезна сама по себе, но ее ценность ограничена. Например, для выявления сезонных или географических тенденций продаж конкретного товара потребуется информация из соответствующей записи заказа. Заказ не может существовать без продукта и клиента, поэтому можно утверждать, что заказ является слабой сущностью, а заказанные продукты – многозначным атрибутом заказа.