¿Cuándo debemos usar entidades débiles al modelar una base de datos?

12

Esta es básicamente una pregunta sobre qué son las entidades débiles. ¿Cuándo debemos usarlos? ¿Cómo deben ser modelados?

¿Cuál es la principal diferencia entre entidades normales y entidades débiles? ¿Las entidades débiles corresponden a objetos de valor cuando se hace un diseño dirigido por dominio?

Para ayudar a mantener la pregunta sobre el tema, aquí hay un ejemplo tomado de Wikipedia que las personas pueden usar para responder a esta pregunta: ingrese la descripción de la imagen aquí

En este ejemplo OrderItemse modeló como una entidad débil, pero no puedo entender por qué no se puede modelar como una entidad normal.
Otra pregunta es, ¿qué pasa si quiero hacer un seguimiento del historial de pedidos (es decir, los cambios en su estado), ¿sería una entidad normal o débil?

design database database-design entity Songo
fuente

Respuestas:

10

Formalmente, una entidad "débil" tiene las siguientes características.

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

Yo diría que en la práctica no decidirías abiertamente hacer de algo una entidad "débil" per se; en su lugar, estructuraría los datos para que sean representativos de lo que sea que intente modelar. Si, después de haber hecho esto, observa una entidad en particular y tiene las características de una entidad "débil", puede documentarla o diagramarla en consecuencia si por alguna razón siente la necesidad de llamarlo explícitamente o por el bien de formalidad

Ed Hastings
fuente
hmmm ¿y qué hay de mi ejemplo? aquí OrderItemdepende, Orderya que no orderItemspuede existir sin pertenecer a un order, pero no puedo ver por qué no puedo usar ItemLineNumberpara identificar únicamente un artículo. En realidad, ¿podría hacer ItemLineNumberun autogenerado intpara asegurar la unicidad y usar una clave foránea orderIDpara vincular las dos entidades?
Songo
2
Si define su OrderItem para que tenga una identificación secuencial de identificación única, y el OrderId no es parte de la clave, entonces está tratando a los OrderItems como ciudadanos de primer orden y realmente no tiene una entidad débil. Puede FK otras tablas a OrderItems individualmente si lo desea; no es necesario tener un OrderId para obtener OrderItems. Por otro lado, si tecleó OrderItem con OrderId y un secuenciaId (o similar) relevante para el Pedido, tendría una entidad débil y las líneas de pedido individuales solo serían referenciables usando OrderId y secuenciaId. Uso del modelo según lo previsto.
Ed Hastings
2
Además, como comentario tangencial, puede ser muy tentador dar a cada tabla su propia clave primaria secuencial y mantener las relaciones lo más simple posible con relaciones de campo único PK-> FK. Es ideal para bases de datos simples en particular, y es fácil razonar sobre ello. Sin embargo, al modelar relaciones más complejas y / o sofisticadas, las teclas compuestas se vuelven muy útiles y le brindan más opciones para modelar matices.
Ed Hastings
1

Un OrderItemno puede existir sin un pedido o un producto. Por lo tanto, es débil ya que sus dependencias lo controlan.

Si, por ejemplo, elimina el pedido, no tiene forma de saber dónde debe enviarse el artículo. O si retira el producto, no sabe qué enviar.

jgauffin
fuente
-1

Según tengo entendido en el diagrama anterior, han incluido las dos entidades / tablas en lugar de una, es decir, pedidos y elemento de pedido, de modo que acceder a la información se vuelve fácil cuando se diseñan dos entidades. Y el artículo de pedido depende de la entidad de pedidos, por lo que se considera una entidad débil. porque la característica de la entidad débil es que depende de otra entidad. Suponga que si no incluye la entidad del artículo del pedido, ¿cómo podrá saber el precio del artículo del pedido, el descuento? y como dijo jgauffin Si, por ejemplo, elimina el pedido, no tiene forma de saber dónde debe enviarse el artículo. O si retira el producto, no sabe qué enviar.

El diagrama ER debe diseñarse de acuerdo con los requisitos comerciales.

sam
fuente
-1

Vea, un pedido tiene muchos artículos de pedido (atributo multivalor). Por lo tanto, de acuerdo con la regla, creamos una tabla separada.

Ahora, digamos que 2 clientes tienen el mismo pedido, por ejemplo, ambos compran iPhone al mismo precio, descuento, misma fecha, etc. Por lo tanto, idealmente debería haber dos tuplas exactas por orden de iPhone en relación con el artículo. Pero de acuerdo con la restricción de una relación, todas las tuplas deben ser únicas. Así que relacionemos dos órdenes con el mismo item_line_number.no hay problema hasta ahora. Ahora considere uno de los clientes cancela. Es el pedido del iPhone. También se eliminará la tupla item_line_number. Ahora, otros clientes que compraron iPhone también se eliminan debido a la correspondencia M: 1. Finalmente, la base de datos es inconsistente. Es por eso que usamos una clave descriptiva que será ordenada. De esta forma, eliminar un iPhone ordenado no causa daños en la base de datos.

VIVEK Barsopia
fuente