Quando devemos usar entidades fracas ao modelar um banco de dados?

12

Esta é basicamente uma pergunta sobre o que são entidades fracas? Quando devemos usá-los? Como eles devem ser modelados?

Qual é a principal diferença entre entidades normais e entidades fracas? Entidades fracas correspondem a objetos de valor ao executar o Design Orientado a Domínio?

Para ajudar a manter a pergunta sobre o tópico, aqui está um exemplo da Wikipedia que as pessoas podem usar para responder a essa pergunta: insira a descrição da imagem aqui

Neste exemplo, OrderItemfoi modelado como uma entidade fraca, mas não consigo entender por que não pode ser modelado como uma entidade normal.
Outra pergunta é: se eu quiser rastrear o histórico de pedidos (ou seja, as alterações no status), isso seria uma entidade normal ou fraca?

design database database-design entity Songo
fonte

Respostas:

10

Formalmente, uma entidade "fraca" possui as seguintes 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.

Eu diria que, na prática, você não iria decidir abertamente tornar uma entidade "fraca" por si só; em vez disso, você estruturaria os dados para serem representativos do que quer que esteja tentando modelar. Se, depois de fazer isso, você olhar para uma entidade em particular e ela possuir as características de uma entidade "fraca", poderá documentá-la ou diagrama-la adequadamente se, por algum motivo, sentir a necessidade de explicitamente chamar isso ou por uma questão de razão. formalidade.

Ed Hastings
fonte
hmmm e o meu exemplo? aqui OrderItemdepende de Ordercomo não orderItemspode existir sem pertencer a um order, mas não vejo por que não posso usar ItemLineNumberpara identificar apenas um item ?! Na verdade, eu poderia apenas criar ItemLineNumberum auto gerado intpara garantir a exclusividade e usar uma chave estrangeira orderIDpara vincular as duas entidades ?!
Songo
2
Se você definir seu OrderItem para ter um ID sequencial de identificação exclusivo, e o OrderId não fizer parte da chave, você estará tratando OrderItems como cidadãos de primeira ordem e realmente não tem uma entidade fraca. Você poderia enviar outras tabelas para OrderItems individualmente, se quisesse; não é necessário já ter um OrderId para acessar OrderItems. Por outro lado, se você digitou OrderItem com OrderId e um sequenceId (ou similar) relevante para o Order, você teria uma entidade fraca e os itens de linha individuais seriam referenciáveis ​​apenas usando o OrderId e o sequenceId. Modele o uso como pretendido.
Ed Hastings
2
Além disso, um comentário tangencial, pode ser muito tentador fornecer a cada tabela sua própria chave primária seqüencial e manter os relacionamentos o mais simples possível com os relacionamentos PK-> FK de campo único. É ótimo para bancos de dados simples, em particular, e é fácil de raciocinar. No entanto, ao modelar relacionamentos mais complexos e / ou sofisticados, as chaves compostas se tornam muito úteis e oferecem mais opções para modelar nuances.
Ed Hastings
1

Um OrderItemnão pode existir sem uma ordem ou um produto. Por isso, é fraco, pois suas dependências o controlam.

Se, por exemplo, você remove o pedido, não tem como saber para onde o item deve ser enviado. Ou, se você remover o produto, não sabe o que enviar.

jgauffin
fonte
-1

De acordo com meu entendimento no diagrama acima, eles incluíram as duas entidades / tabelas em vez de uma ou seja, pedidos e itens de pedidos, para que o acesso às informações se torne fácil quando duas entidades são projetadas. E o item do pedido depende da entidade do pedido, por isso é considerado uma entidade fraca. porque a característica de entidade fraca é que depende de outra entidade. Suponha que, se você não incluir a entidade do item do pedido, como poderá saber o preço e o desconto do item do pedido. e como disse jgauffin Se, por exemplo, você remove o pedido, não tem como saber para onde o item deve ser enviado. Ou, se você remover o produto, não sabe o que enviar.

O diagrama de ER deve ser projetado de acordo com os requisitos de negócios.

sam
fonte
-1

Veja, um pedido tem muitos itens de pedido (atributo de valores múltiplos). Assim, de acordo com a regra, criamos tabela separada.

Agora, digamos que 2 clientes tenham a mesma ordem. Ambos compram o iPhone pelo mesmo preço, desconto, mesma data, etc. Então, idealmente, deve haver duas tuplas exatas para a ordem do iPhone na relação orderitem. Mas, de acordo com a restrição de um relacionamento, todas as tuplas devem ser únicas. Então, vamos relacionar dois pedidos ao mesmo item_line_number.no problema até agora. Agora considere que um dos clientes cancela. É a ordem do iPhone. Também a tupla item_line_number será excluída. Agora, outros clientes que compraram o iPhone também são excluídos por causa da correspondência M: 1. Então, finalmente, o banco de dados é inconsistente. É por isso que usamos uma chave de descrição que será solicitada. A exclusão de um iPhone solicitado não causa corrupção no banco de dados.

VIVEK barsopia
fonte