Entidad débil

En una base de datos relacional, una entidad débil es una entidad que no puede identificarse únicamente por sus atributos únicamente; por lo tanto, debe usar una clave externa junto con sus atributos para crear una clave principal. La clave externa suele ser una clave principal de una entidad con la que está relacionada.

La clave foránea es un atributo del identificador (o propietario, padre o dominante) conjunto de entidades. Cada elemento del conjunto de entidades débiles debe tener una relación con exactamente un elemento del conjunto de entidades propietario y, por lo tanto, la relación no puede ser una relación de muchos a muchos.

En los diagramas entidad-relación (diagramas ER), un conjunto de entidad débil se indica mediante un rectángulo en negrita (o doble línea) (la entidad) conectado por una flecha en negrita (o doble línea) a una negrita (o doble línea) -rayado) diamante (la relación). Este tipo de relación se denomina relación de identificación y en la notación IDEF1X se representa mediante una entidad ovalada en lugar de una entidad cuadrada para las tablas base. Una relación de identificación es aquella en la que la clave principal se completa con la entidad débil secundaria como clave principal en esa entidad.

En general (aunque no necesariamente), una entidad débil no tiene ningún elemento en su clave principal que no sea su clave principal heredada y un número de secuencia. Hay dos tipos de entidades débiles: entidades asociativas y entidades de subtipo. Este último representa un tipo crucial de normalización, donde la entidad de supertipo hereda sus atributos a las entidades de subtipo en función del valor del discriminador.

En IDEF1X, un estándar gubernamental para capturar requisitos, las posibles relaciones de subtipo son:

• Relación subtipo completa, cuando todas las categorías son conocidas.
• Relación subtipo incompleta, cuando todas las categorías pueden no ser conocidas.

Un ejemplo clásico de una entidad débil sin una relación de subtipo sería el "encabezado/detalle' registros en muchas situaciones del mundo real, como reclamaciones, pedidos y facturas, donde el encabezado captura información común en todos los formularios y el detalle captura información específica de elementos individuales.

El ejemplo estándar de una relación de subtipo completa es la entidad parte. Dado el discriminador TIPO DE PARTE (que podría ser individuo, sociedad, Corporación C, Asociación del Subcapítulo S, Asociación, Unidad Gubernamental, Agencia Cuasi-gubernamental), los dos subtipos de entidades son PERSONA, que contiene información específica del individuo, como nombre y apellido. y fecha de nacimiento, y ORGANIZACIÓN, que contendría atributos tales como el nombre legal y jerarquías organizacionales tales como centros de costos.

Cuando las relaciones de subtipo se representan en una base de datos, el supertipo se convierte en lo que se conoce como una tabla base. Los subtipos se consideran tablas derivadas, que corresponden a entidades débiles. La integridad referencial se aplica a través de actualizaciones y eliminaciones en cascada.

Ejemplo

Considere una base de datos que registre los pedidos de los clientes, donde un pedido es para uno o más de los artículos que vende la empresa. La base de datos contendría una tabla que identifica a los clientes por un número de cliente (clave principal); otro que identifica los productos que pueden ser vendidos por un número de producto (clave primaria); y contendría un par de tablas que describen órdenes.

Una de las tablas podría llamarse Pedidos y tendría un número de pedido (clave principal) para identificar este pedido de manera única, y contendría un número de cliente (clave externa) para identificar a quién se venden los productos, además de otros información como la fecha y hora en que se realizó el pedido, cómo se pagará, a dónde se enviará, etc.

La otra tabla podría llamarse OrderItem; se identificaría mediante una clave compuesta que consiste tanto en el número de pedido (clave externa) como en el número de línea del artículo; con otros atributos de clave no principal, como el número de producto (clave externa) que se ordenó, la cantidad, el precio, cualquier descuento, cualquier opción especial, etc. Puede haber cero, una o varias entradas de artículo de pedido correspondientes a una entrada de pedido, pero no puede existir ninguna entrada de artículo de pedido a menos que exista la entrada de pedido correspondiente. (El caso de artículo de pedido cero normalmente solo se aplica de manera transitoria, cuando el pedido se ingresa por primera vez y antes de que se registre el primer artículo pedido).

La tabla de artículos de pedido almacena entidades débiles precisamente porque un artículo de pedido no tiene significado independiente del pedido. Algunos podrían argumentar que un artículo de pedido tiene algún significado por sí mismo; registra que en algún momento no identificado por el registro, alguien no identificado por el registro ordenó una determinada cantidad de un determinado producto. Esta información puede ser de alguna utilidad por sí sola, pero tiene un uso limitado. Por ejemplo, tan pronto como desee encontrar tendencias estacionales o geográficas en las ventas del artículo, necesitará información del registro de Pedido relacionado.

Un pedido no existiría sin un producto y una persona para crear el pedido, por lo que se podría argumentar que un pedido se describiría como una entidad débil y que los productos pedidos serían un atributo multivalor del pedido.