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

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

• 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

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.

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 !!!

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 ...

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

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! .

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.

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.

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

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

Os atributos migrados de pai para filho ajudam a identificar ¹ 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 ...

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

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.

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.

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