Comentários sobre: Identifying e non-identifying relationships

Por: 1berto

1berto — Thu, 24 Jun 2010 23:12:36 +0000

O post do Vicente também está correto, mas tem mais um aspecto sobre a relação de identidades e chaves artificiais.
Vamos supor que você estivesse modelando um sistema que precisasse atender a várias empresas e filiais destas empresas (ou seja uma situação prática envolvendo o exemplo que ele postou), fisicamente você poderia simplesmente criar um sequencia único para todas as filiais e ai não iria sentir falta da chave estrangeira (da empresa) na chave primária da filial. Mas para o negócio aquele seria um número ‘burro’, duas filiais de uma mesma empresa ficariam ‘sem ligação’ nenhuma se você olhar somente a chave, você poderia ter por exemplo a filial 2045 e a 3197 pertencentes a mesma empresa.
Fazendo como ele falou (colocando um sequencial para cada filial) você tem um número mais ‘real’, a filial 01 de uma empresa seria a primeira a ter sido cadastrada, a 02 a segunda, etc, etc. Ou seja este sequencial que ele criou não é uma chave artificial.
Se não me engano a receita utiliza uma abordagem deste tipo, sendo que o CNPJ /0001 é sempre da matriz, o /0002 e seguintes são das filiais. Eu particularmente iria tentar primeiro criar uma chave com outros atributos (talvez endereço, entendendo que não podem haver duas filiais no mesmo endereço/complemento), mas isto é outra conversa, quanto ao assunto que está sendo discutido, o post dele está correto.

Por: 1berto

1berto — Mon, 12 Apr 2010 07:56:10 +0000

Isso é um debate curioso, na verdade as duas afirmações são
praticamente a mesma coisa só que em termos físico e lógico…
Exceto por um pequeno detalhe chamado: Chaves primárias
artificiais
O exemplo do Lucas de Cidade/Estado realmente é uma relação de
identidade (prefiro o termo UF ao termo Estado) ou seja no
contexto q ele colocou está incorreto, como apontou o Rodrigo.
O Rodrigo disse “uma cidade PRECISA de um estado para ser
únicamente identificável”, do ponto de vista da lógica de negócio
pura está absolutamente correto… Então como o Lucas conseguiu
criar a tabela sem perceber a incorreção? Reparem… Ele criou
uma chave artificial
Quando você coloca uma chave única artificial você não ‘acha’ a
necessidade deste tipo de relação.
Isso de uma única coluna artificial como chave para a tabela por
si dá um debate e tanto, o que importa quanto ao assunto que
estamos discutindo é:
Se usar uma única coluna artificial como chave a análise da
Relação de identidade fica no mínimo ‘oculta’. Se você entende
que precisa ‘somente’ de um código para achar uma cidade, não
faz o menor sentido eu te dizer que você precisa do nome e da
UF…
Mas você pode usar uma segunda abordagem:
Uma tabela de UF poderia conter somente a sigla (dois chars), a
sigla é uma chave (não há dois estados com a mesma sigla, do ponto
de vista da lógica não há necessidade nenhuma de código aqui).
Na tabela de cidade você coloca o nome… OK, mas para poder ser
uma chave você precisa da sigla da UF para identificar univocamente
uma cidade você precisa só do nome e da UF (Como apontou o Rodrigo).

Por: Lucas Renan

Lucas Renan — Thu, 11 Mar 2010 16:13:02 +0000

Vicente,

você pode me passar uma referência bibliográfica para que eu possa atualizar o post?

Por: Vicente Russo

Vicente Russo — Sat, 06 Mar 2010 14:11:52 +0000

O comentário do rodrigo está correto. Qdo uma entidade não faz sentido se separada de outra, temos um relacionamento identificado. Neste caso, temos uma “entidade fraca”. Exemplo: Empresa possui Filial => Filial é uma entidade fraca de empresa, possuindo um relacionamento identificador. Assim, a chave primária de Filial provavelmente será composta pela chave primária de Empresa (a qual também será uma chave estrangeira) e um número que identifica da filial dessa empresa:

Empresa(idEmpresa, Nome, …)
Filial(idEmpresa, idFilial, Endereço, …)

Por: Lucas Renan

Lucas Renan — Sat, 06 Feb 2010 00:51:11 +0000

Rodrigo,

acredito que sua explicação tenha fundamento, até mesmo porque eu me basei em informações que achei na internet, então não posso garantir que o meu post está correto. Você poderia me passar alguma fonte confiável que contenha essa informação, para que eu possa atualizar o post?

valeu

Por: Rodrigo Furtado

Rodrigo Furtado — Thu, 04 Feb 2010 17:39:04 +0000

Sua explicação está errada.

Ou pelo menos parcialmente correta.

O fato é que uma “identifying relationship” é uma relação onde uma tabela para existir precisa obrigatoriamente ter as informações da outra para ser unicamente identificável enquanto que uma relação “non identifying não precisa”.

Seu exemplo de relação entre a tabela cidade com estado por exemplo é um ótimo exemplo de uma “identifying relationship”(ao contrário do que você marcou) pois uma cidade PRECISA de um estado para ser únicamente identificável, uma vez que existem cidades com o mesmo nome em diferentes estados.

Um exemplo de uma relação “non identifying” seria de uma tabela de pedidos com uma tabela de descontos. Embora a tabela de pedidos precise de uma chave estrangeira para identificar um desconto que ela recebe, a mesma não deve ser primaria pois pode ocorrer do pedido não ter nenhum desconto (e mesmo assim o pedidoainda é totalmente válido e único).

Abraço!

Por: leandro silva

leandro silva — Wed, 16 Dec 2009 17:54:46 +0000

nossa eu tambem tava com duvida quanto a isso vou muito borigado pela explicação

Parabens pelo site XD

Por: Lucas Renan

Lucas Renan — Sat, 23 May 2009 02:29:02 +0000

uahuahauha

eu sempre tive dúvidas sobre esses relacionamentos.

Por: Guilherme

Guilherme — Fri, 22 May 2009 13:29:44 +0000

Opa, agora apareceu a imagem aqui jauihauhua.

Por: Guilherme

Guilherme — Fri, 22 May 2009 13:29:10 +0000

Massa o Post.

Essa imagem seria então do relacionamento de um relacionamento 1:n identificado e como ficaria um 1:n não identificado?