Weak entity

related topics
{math, number, function}
{company, market, business}
{area, part, region}
{woman, child, man}
{album, band, music}

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.

In entity relationship diagrams a weak entity set is indicated by a bold rectangle (the entity) connected by a bold type arrow to a bold 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 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.

Example

Consider a database that records customer orders, where an order is for one or more of the items that the enterprise sells. The database would contain a table identifying customers by a customer number (primary key); another identifying the products that can be sold by a product number (primary key); and it would contain a pair of tables describing orders.

One of the tables could be called Orders and it would have an order number (primary key) to identify this order uniquely, and would contain a customer number (foreign key) to identify who the products are being sold to, plus other information such as the date and time when the order was placed, how it will be paid for, where it is to be shipped to, and so on.

Full article ▸

related documents
EXPSPACE
Almost everywhere
Continuity property
Linear congruence theorem
Partition of unity
Monoid ring
Arithmetic-geometric mean
Normed division algebra
Bilinear map
NP-easy
Composite number
Permutation group
Group homomorphism
Multiple inheritance
Wikipedia:Searching bug reports
Pole (complex analysis)
HTML scripting
Lyapunov fractal
Laurent polynomial
Catalan's constant
Best-first search
LALR parser
Nearest neighbour algorithm
Gauss–Legendre algorithm
Krull dimension
Chosen-plaintext attack
Data set
Contraction mapping
Complete measure
Blum Blum Shub