Qual a diferença entre identificar e não identificar relacionamentos?


800

Não fui capaz de entender completamente as diferenças. Você pode descrever os dois conceitos e usar exemplos do mundo real?


11
as respostas a esta pergunta são tão confuso que não é engraçado
Dennis

Boa pergunta, a roda não deve ser reinventada: Peter Chen. O Modelo de Relacionamento com Entidades, Rumo a uma Visão Unificada dos Dados, 1976 , ponto 2.3.2: " Se os relacionamentos forem usados ​​para identificar as entidades, chamaremos de fraca relação de entidade. Se os relacionamentos não forem usados ​​para identificar as entidades, chamaremos é uma relação de entidade regular ". A questão do OP se resume a: O que são relações de entidade fracas / regulares? .
mins

Respostas:


1063
  • Um relacionamento de identificação é quando a existência de uma linha em uma tabela filho depende de uma linha em uma tabela pai. Isso pode ser confuso, porque é prática comum atualmente criar uma pseudo-chave para uma tabela filho, mas não tornar a chave estrangeira para a parte pai da chave primária da criança. Formalmente, a maneira "correta" de fazer isso é tornar a chave estrangeira parte da chave primária da criança. Mas o relacionamento lógico é que a criança não pode existir sem os pais.

    Exemplo: A Personpossui um ou mais números de telefone. Se eles tivessem apenas um número de telefone, poderíamos simplesmente armazená-lo em uma coluna de Person. Como queremos oferecer suporte a vários números de telefone, criamos uma segunda tabela PhoneNumbers, cuja chave primária inclui a person_idreferência à Persontabela.

    Podemos pensar nos números de telefone como pertencentes a uma pessoa, mesmo que eles sejam modelados como atributos de uma tabela separada. Essa é uma forte pista de que esse é um relacionamento de identificação (mesmo que não incluamos literalmente person_idna chave primária de PhoneNumbers).

  • Um relacionamento sem identificação é quando os atributos da chave primária do pai não devem se tornar atributos da chave primária do filho. Um bom exemplo disso é uma tabela de pesquisa, como uma chave estrangeira ao Person.statereferenciar a chave primária de States.state. Personé uma tabela filho em relação a States. Mas uma linha Personnão é identificada por seu stateatributo. Ou stateseja, não faz parte da chave primária de Person.

    Um relacionamento não identificador pode ser opcional ou obrigatório , o que significa que a coluna de chave estrangeira permite NULL ou desativa NULL, respectivamente.


Veja também minha resposta para Ainda confuso sobre identificar e não identificar relacionamentos


9
+1: projeto de lei, "atualmente é prática comum criar uma pseudo-chave para uma tabela filho, mas não transformar a chave estrangeira na parte pai da chave primária da criança" - existem links sobre o motivo? O Google está falhando comigo.
hobodave

17
Parece que a construção "apropriada" de relacionamentos de identificação levaria a chaves primárias desagradáveis. por exemplo, o prédio tem andar, o quarto tem cama. O PK para cama seria (bed_id, floor_id, room_id, building_id). Parece estranho que eu nunca vi isso na prática, nem o ouvi sugerir como uma maneira de fazer qualquer coisa. São muitos dados redundantes no PK.
hobodave

24
@ Hobodave: Eu vi chaves primárias de várias colunas que são ainda maiores. Mas eu entendo o seu ponto. Considere que as chaves primárias de várias colunas transmitem mais informações; você pode consultar a Bedstabela para todas as camas em um edifício específico sem fazer nenhuma junção.
Bill Karwin

2
@ Eugene, sim, eu esperaria que fosse um relacionamento sem identificação. user_iddeve ser a chave primária por si só e updated_bynão faz parte de uma chave primária com várias colunas.
Bill Karwin

4
Eu nunca vou usar isso para modelar isso. A melhor resposta é de "aqsa rao" abaixo, que afirma o seguinte: "Um relacionamento de identificação significa que a tabela filho não pode ser identificada exclusivamente sem o pai". Porque sua definição está adicionando semântica desnecessária que pode confundir as pessoas. Não é a dependência entre as entidades o motivo pelo qual você cria um relacionamento de identificação ou não-identificação.
Sebastian

888

Há outra explicação do mundo real:

Um livro pertence a um proprietário, e um proprietário pode possuir vários livros. Mas, o livro pode existir também sem o proprietário, e a propriedade dele pode mudar de um proprietário para outro. O relacionamento entre um livro e um proprietário é um relacionamento não identificador.

Um livro, no entanto, é escrito por um autor, e o autor poderia ter escrito vários livros. Mas, o livro precisa ser escrito por um autor - ele não pode existir sem um autor. Portanto, a relação entre o livro e o autor é uma relação de identificação.


2
Uma explicação decente, mas acredito que também é instrutivo estender um pouco o exemplo. Um livro tem várias páginas. Ele não pode existir sem páginas e, portanto, podemos concluir que o relacionamento entre um livro e o número de páginas que ele possui também é um relacionamento identificador. Mas o atributo número de páginas fará parte de qualquer esquema de identificação (chave) do livro? Provavelmente não. O termo "relacionamento de identificação" é normalmente reservado para relacionamentos que envolvem atributos de identificação - atributos principais em termos relacionais.
Nvogel

13
O que acontece se o livro foi escrito por mais de um autor? Não está mais identificando o relacionamento como tipo M: N, por quê?
NGix

2
Esses exemplos reais são inúteis. Quando você percebe como cria tabelas no ER e como a integridade dos dados será mantida, você joga fora esses exemplos. Se você criar um forte relacionamento entre duas entidades, estará forçando a criação de uma chave primária na tabela de entidades combinada com PK da outra entidade. Se o seu modelo permitir que o mesmo livro possa ter vários autores, não há problema em ser forte. Mas se o seu modelo permite apenas 1 autor e 1 livro, você não pode ter essa restrição usando um relacionamento forte porque PK(Book.id, Book.person_id).
Sebastian

2
mas o uso real é "o livro pode existir sem o autor?". A resposta é sim, na realidade, porque as pessoas procurarão o livro diretamente. Portanto, na prática, para este caso, eles devem ser sempre "relações não identificáveis".
windmaomao

3
o que está acontecendo pessoal !!, Este não é um exemplo válido para the Identifying relationship !!! sim, um livro não pode ser escrito sem um autor, mas o campo do autor na tabela de livros NÃO ESTÁ IDENTIFICANDO a linha do livro !!!
Contador

33

A resposta de Bill está correta, mas é chocante ver que, dentre todas as outras respostas, ninguém aponta o aspecto mais significativo.

Dizem repetidas vezes que, na identificação e relacionamento, a criança não pode existir sem os pais. (por exemplo, user287724 ). Isso é verdade, mas erra completamente o ponto. Seria suficiente que a chave estrangeira não fosse nula para conseguir isso. Ele não precisa fazer parte da chave primária.

Então, aqui está o verdadeiro motivo:

O objetivo de um relacionamento de identificação é que a chave estrangeira NUNCA MUDE , porque faz parte da chave primária ... portanto, identificando !!!


2
+1 para "Seria o suficiente para a chave estrangeira ser não nula, para conseguir isso". Ele deve ser suficiente, mas infelizmente não é quando se trata de algo como Entity Framework, que não funciona direito a menos que você use uma relação de identificação, mas então o campo "Id" de uma entidade perde a sua singularidade, como resultado de ser apenas uma parte de uma chave composta.
Triynko

25

Um relacionamento de identificação especifica que um objeto filho não pode existir sem o objeto pai

Relacionamentos sem identificação especifica uma associação regular entre objetos, cardinalidade 1: 1 ou 1: n.

Os relacionamentos de não identificação podem ser especificados como opcionais quando um pai não é necessário ou obrigatório quando um pai é necessário, definindo a cardinalidade da tabela pai ...


6
Isso parece mais uma descrição da participação total em um relacionamento do que de um relacionamento identificador.
22620 Thomas Padron-McCarthy

1
Você está literalmente competindo com um cara com 218k de reputação. Apenas jogando isso lá fora, porque vocês dois definitivamente sabem mais do que eu.
Marc DiMillo

Não concordo com as definições acima. Você pode ter um objeto que depende de seu pai e deseja que esse objeto seja restrito a ser vinculado apenas a 1 linha pai. A Housetem Walls. Você remove a casa e não tem paredes. Mas uma parede pertence apenas a uma casa. Portanto, fazer relacionamentos fortes não funcionará: PK(Wall.id, House.id)permitirá que você insira no modelo a mesma parede em outra casa.
Sebastian

15

Aqui está uma boa descrição:

Os relacionamentos entre duas entidades podem ser classificados como "identificadores" ou "não identificáveis". Os relacionamentos de identificação existem quando a chave primária da entidade pai é incluída na chave primária da entidade filho. Por outro lado, existe um relacionamento não identificador quando a chave primária da entidade pai é incluída na entidade filho, mas não como parte da chave primária da entidade filho. Além disso, relacionamentos não identificados podem ser classificados ainda como "obrigatórios" ou "não obrigatórios". Existe um relacionamento obrigatório de não identificação quando o valor na tabela filho não pode ser nulo. Por outro lado, existe um relacionamento não identificador não obrigatório quando o valor na tabela filho pode ser nulo.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Aqui está um exemplo simples de um relacionamento de identificação:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

Aqui está um relacionamento não identificador correspondente:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

1
Sua resposta está em conflito com a fornecida por Bill Karwin, na diferença entre se a Chave estrangeira "não é" ou "não deve" fazer parte da Chave Primária na linha Filha.
Nicole

@ Andy White Mas a chave primária do pai em um relacionamento de identificação pode ser não obrigatória, ou seja, nula, quando faz parte de uma chave primária composta de três colunas?
Frederik Krautwald

10

A resposta de user287724 fornece o seguinte exemplo do relacionamento de livro e autor:

Um livro, no entanto, é escrito por um autor, e o autor poderia ter escrito vários livros. Mas o livro precisa ser escrito por um autor, ele não pode existir sem um autor. Portanto, a relação entre o livro e o autor é uma relação de identificação.

Este é um exemplo muito confuso e definitivamente não é um exemplo válido para um identifying relationship.

Sim, um booknão pode ser escrita sem pelo menos um author, mas o author(é chave estrangeira) do booké não identificarem o bookna booksmesa!

Você pode remover o author(FK) a partir da booklinha e ainda pode identificar a linha livro por algum outro campo ( ISBN, ID... etc), mas não o autor do livro !!

Eu acho que um exemplo válido de um identifying relationshipseria o relacionamento entre (tabela de produtos) e um (tabela de detalhes específicos do produto)1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

Neste exemplo, o Product_IDna printers_detailsmesa é considerado um FK referências a products.idmesa e TAMBÉM uma PK na printers_detailstabela, isto é uma relação de identificação porque o Product_ID(FK) na tabela de impressoras é identificar a linha dentro da tabela de criança, que não é possível remover a product_idpartir da tabela filho porque não conseguimos mais identificar a linha porque perdemos sua chave primária

Se você quiser colocá-lo em 2 linhas:

um relacionamento de identificação é o relacionamento quando o FK na tabela filho é considerado um PK (ou identificador) na tabela filho enquanto ainda faz referência à tabela pai

Outro exemplo pode ser quando você possui 3 tabelas (importações - produtos - países) em uma importação e exportação para um banco de dados de alguns países

A importtabela é a criança que possui esses campos (o product_id(FK), o country_id(FK), o valor das importações, o preço, as unidades importadas, o meio de transporte (aéreo, marítimo) we may use the (product_id , thecountry_id`) para identificar cada linha das importações "se todas no mesmo ano" aqui, as duas colunas podem compor uma chave primária na tabela filho (importações) e também fazer referência às tabelas pai.

Por favor, estou feliz por finalmente entender o conceito de identifying relationshipe non identifying relationship, portanto, não me diga que estou errado com todos esses votos para um exemplo completamente inválido.

Sim, logicamente, um livro não pode ser escrito sem um autor, mas um livro pode ser identificado sem o autor. Na verdade, não pode ser identificado com o autor!

Você pode 100% remover o autor da linha do livro e ainda pode identificá-lo! .


5
Você está certo, se você tiver apenas livros e autores de tabelas. Não há relação de identificação lá. Mas se você usar uma terceira tabela para representar o relacionamento muitos-para-muitos, a chave primária dessa terceira tabela consistirá em duas chaves estrangeiras, fazendo referência à tabela de livros e à tabela de autores. Essa tabela tem uma relação de identificação com livros e autores. Veja meu exemplo em stackoverflow.com/questions/2814469/…
Bill Karwin

8

Relação não identificável

Um relacionamento sem identificação significa que um filho está relacionado aos pais, mas pode ser identificado por ele próprio.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

A relação entre CONTA e PESSOA não é identificável.

Identificando relacionamento

Um relacionamento de identificação significa que o pai é necessário para dar identidade ao filho. A criança existe apenas por causa dos pais.

Isso significa que a chave estrangeira também é uma chave primária.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

O relacionamento entre ITEM_LANG e ITEM está sendo identificado. E entre ITEM_LANG e LANGUAGE também.


2
Como PERSON e CONTA não são identificadas? Como a CONTA pode existir sem PERSON?
MrRobot9

por que não há resposta para o comentário anterior? @ MrRobot9
AAEM

4

Se você considerar que o item filho deve ser excluído quando o pai for excluído, será um relacionamento de identificação.

Se o item filho deve ser mantido, mesmo que o pai seja excluído, é um relacionamento não identificador.

Como exemplo, tenho um banco de dados de treinamento com estagiários, treinamentos, diplomas e sessões de treinamento:

  • estagiários têm uma relação de identificação com as sessões de treinamento
  • treinamentos têm uma relação de identificação com as sessões de treinamento
  • mas os estagiários têm uma relação não identificável com diplomas

Somente as sessões de treinamento devem ser excluídas se um dos trainees, treinamentos ou diplomas relacionados for excluído.


3

O relacionamento identificativo significa que a entidade filha depende totalmente da existência da entidade mãe. Exemplo de tabela de pessoa da tabela de contas e personaccount. A tabela de contas da pessoa é identificada apenas pela existência da tabela de contas e pessoas.

O relacionamento sem identificação significa que a tabela filho não é identificada pela existência do exemplo da tabela pai. Existe uma tabela como accounttype e account.accounttype não é identificada com a existência da tabela


2

Como bem explicado no link abaixo, uma relação de identificação é algo como uma relação fraca do tipo de entidade em relação à sua matriz no modelo conceitual de ER. Os CADs no estilo UML para modelagem de dados não usam símbolos ou conceitos de ER, e os tipos de relações são: identificação, não identificação e não específico.

Os identificadores são relações pai / filho em que o filho é uma espécie de entidade fraca (mesmo no modelo tradicional de ER, chamado relacionamento de identificação), que não possui uma chave primária real por seus próprios atributos e, portanto, não pode ser identificado exclusivamente por seus próprios . Todo acesso à tabela filho, no modelo físico, dependerá (inclusive semanticamente) da chave primária do pai, que se transforma em parte ou total da chave primária do filho (também sendo uma chave estrangeira), geralmente resultando em uma chave composta no lado da criança. As eventuais chaves existentes do próprio filho são apenas chaves pseudo ou parciais, insuficientes para identificar qualquer instância desse tipo de Entidade ou Conjunto de Entidades, sem a PK do pai.

Relações de não identificação são as relações comuns (parciais ou totais), de conjuntos de entidades completamente independentes, cujas instâncias não dependem das chaves primárias uma da outra para serem identificadas exclusivamente, embora possam precisar de chaves estrangeiras para relacionamentos parciais ou totais, mas não como a chave primária da criança. A criança tem sua própria chave primária. O idem pai. Ambos de forma independente. Dependendo da cardinalidade do relacionamento, a PK de uma passa como FK para a outra (lado N) e, se parcial, pode ser nula, se total, não deve ser nula. Mas, em um relacionamento como esse, o FK nunca será também o PK da criança, como quando um relacionamento de identificação é o caso.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships


2

Os atributos migrados de pai para filho ajudam a identificar 1 o filho?

  • Se sim : a identificação-dependência existe, o relacionamento está sendo identificado e a entidade filha é "fraca".
  • Caso contrário : a identificação-dependência não existe, o relacionamento não é identificado e a entidade filha "forte".

Observe que a identificação-dependência implica a existência-dependência, mas não o contrário. Todo FK que não seja NULL significa que um filho não pode existir sem o pai, mas isso por si só não identifica o relacionamento.

Para mais informações sobre isso (e alguns exemplos), consulte a seção "Identificando Relacionamentos" do Guia de Métodos do ERwin .

PS: Percebo que estou (extremamente) atrasado para a festa, mas sinto que outras respostas não são inteiramente precisas (definindo-as em termos de dependência da existência em vez de dependência da identificação), ou um tanto sinuosas. Espero que esta resposta forneça mais clareza ...


1 O FK da criança faz parte da restrição PRIMARY KEY da criança ou UNIQUE (não NULL).


1

Um bom exemplo vem do processamento de pedidos. Um pedido de um cliente normalmente possui um Número de pedido que identifica o pedido, alguns dados que ocorrem uma vez por pedido, como a data do pedido e o ID do cliente, além de uma série de itens de linha. Cada item de linha contém um número de item que identifica um item de linha em um pedido, um produto solicitado, a quantidade desse produto, o preço do produto e a quantidade do item de linha, que pode ser calculada multiplicando a quantidade pelo valor preço.

O número que identifica um item de linha apenas o identifica no contexto de um único pedido. O primeiro item de linha em cada pedido é o número do item "1". A identidade completa de um item de linha é o número do item, juntamente com o número do pedido do qual ele faz parte.

O relacionamento pai-filho entre pedidos e itens de linha é, portanto, um relacionamento de identificação. Um conceito intimamente relacionado na modelagem de ER atende o nome "subentidade", em que o item de linha é uma subentidade de ordem. Normalmente, uma subentidade tem um relacionamento obrigatório de identidade pai-filho com a entidade à qual está subordinado.

No design clássico do banco de dados, a chave primária da tabela LineItems seria (OrderNumber, ItemNumber). Alguns dos designers de hoje dariam a um item um ItemID separado, que serve como chave primária e é incrementado automaticamente pelo DBMS. Eu recomendo o design clássico neste caso.


0

Digamos que temos essas tabelas:

user
--------
id
name


comments
------------
comment_id
user_id
text

O relacionamento entre essas duas tabelas identificará o relacionamento. Porque, apenas os comentários podem pertencer ao seu proprietário, não a outros usuários. por exemplo. Cada usuário tem seu próprio comentário e, quando ele é excluído, os comentários deste usuário também devem ser excluídos.


0

Um relacionamento de identificação é entre duas entidades fortes. Um relacionamento de não identificação nem sempre pode ser um relacionamento entre uma entidade forte e uma entidade fraca. Pode existir uma situação em que o próprio filho tenha uma chave primária, mas a existência de sua entidade possa depender de sua entidade pai.

Por exemplo: pode existir uma relação entre um vendedor e um livro em que um livro está sendo vendido por um vendedor, onde o vendedor pode ter sua própria chave primária, mas sua entidade é criada apenas quando um livro está sendo vendido

Referência baseada em Bill Karwin


5
Pode ajudar a definir o que você quer dizer com entidade "forte" e "fraca" aqui.
nullability
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.