En una base de datos relacional , una entidad débil es una entidad que no se puede identificar de forma única solo por sus atributos; por lo tanto, debe utilizar 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 externa es un atributo del conjunto de entidades identificadoras (o propietarias , principales o dominantes ) . 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.
Dos entidades pueden asociarse 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 una de ellas sea considerada como entidad débil.
En los diagramas de relación de 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 mediante una flecha en negrita (o de doble línea) a un rombo en negrita (o de doble línea) (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. Esta última 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:
Un ejemplo clásico de una entidad débil sin una relación de subtipo serían los registros "encabezado/detalle" en muchas situaciones del mundo real, como reclamos, pedidos y facturas, donde el encabezado captura información común a todos los formularios y el detalle captura información específica de artículos individuales.
El ejemplo estándar de una relación de subtipo completa es la entidad de la 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), las dos entidades de subtipo son PERSONA, que contiene información específica de la persona, como nombre y apellido y fecha de nacimiento, y ORGANIZACIÓN, que contendría atributos como el nombre legal y jerarquías organizacionales como centros de costos.
Cuando se representan relaciones de subtipos en una base de datos, el supertipo se convierte en lo que se denomina una 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 pedidos de clientes, donde un pedido corresponde a 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 ); otra que identifica los productos que se pueden vender por un número de producto ( clave principal ); 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 están vendiendo 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 consta 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 ordenó, la cantidad, el precio, cualquier descuento, cualquier opción especial, etc. Puede haber cero, una o muchas entradas de OrderItem correspondientes a una entrada de Order, pero no puede existir ninguna entrada de OrderItem a menos que exista la entrada de Order correspondiente. (El caso de OrderItem cero normalmente solo se aplica transitoriamente, cuando se ingresa el pedido por primera vez y antes de que se haya registrado el primer artículo pedido).
La tabla OrderItem almacena entidades débiles precisamente porque un OrderItem no tiene un significado independiente del Order. Algunos podrían argumentar que un OrderItem sí 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 cierta 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 Order 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.