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 utilizar una clave externa junto con sus atributos para crear una clave primaria . La clave externa suele ser una clave primaria de una entidad con la que está relacionada.
La clave foránea es un atributo del conjunto de entidades identificador (o propietario , padre o dominante ) . Cada elemento del conjunto de entidades débiles debe tener una relación con exactamente un elemento del conjunto de entidades propietarias [1] y, por lo tanto, la relación no puede ser una relación de muchos a muchos.
Se pueden asociar dos entidades sin que ninguna de ellas sea clasificada como débil, incluso si una depende de la otra, siempre que cada una tenga su propio atributo único. [1] Por ejemplo, una entidad persona puede vincularse a un automóvil sin que uno de ellos sea considerado una entidad débil.
En los diagramas de relación entre entidades (diagramas ER) , un conjunto de entidades débiles se indica mediante un rectángulo en negrita (o de doble línea) (la entidad) conectado por una flecha de tipo negrita (o de doble línea) a una negrita (o de doble línea) 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 primaria aparte de su clave primaria 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 para subtipo de entidades en función del valor del discriminador .
En IDEF1X , un estándar gubernamental para capturar requisitos, las posibles relaciones de subtipo son:
Un ejemplo clásico de una entidad débil sin una relación de subtipo serían los registros de "encabezado/detalle" 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. a elementos individuales.
El ejemplo estándar de una relación de subtipo completa es la entidad parte . Dado el TIPO DE PARTIDO discriminador (que podría ser individuo, sociedad, Corporación C, Asociación del Subcapítulo S, Asociación, Unidad Gubernamental, Agencia cuasi gubernamental), las dos entidades de subtipo 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 organizativas 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 tabla base. Los subtipos se consideran tablas derivadas, que corresponden a entidades débiles. La integridad referencial se aplica mediante actualizaciones y eliminaciones en cascada.
Considere una base de datos que registra 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 mediante un número de cliente ( clave primaria ); otro identificando los productos que se pueden vender mediante un número de producto ( clave primaria ); y contendría un par de tablas que describen los pedidos.
Una de las tablas podría llamarse Pedidos y tendría un número de pedido ( clave principal ) para identificar este pedido de forma única y contendría un número de cliente ( clave externa ) para identificar a quién se venden los productos, además de otra 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 constaría tanto del número de pedido ( clave externa ) como de un número de línea de artículo; con otros atributos de clave no principal, como el número de producto ( clave externa ) que se solicitó, 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 forma transitoria, cuando el pedido se ingresa por primera vez y antes de que se registre el primer artículo pedido).
La tabla OrderItem almacena entidades débiles precisamente porque un OrderItem no tiene significado independiente del Order. Algunos podrían argumentar que un artículo de pedido tiene algún significado por sí solo; 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 es de 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 que lo creara, por lo que se podría argumentar que un pedido se describiría como una entidad débil y que los productos solicitados serían un atributo multivalor del pedido.