Identifying e non-identifying relationships
Nos comentários provavelmente está a resposta correta.
Quando vamos criar uma base de dados, necessitamos de muito conhecimento e planejamento para garantirmos confiabilidade, performance e organização dos dados, já que a informação na maioria dos casos tem valor inestimável. Muitas pessoas, assim como eu, se deparam com situações inusitadas a cada dia, principalmente se tratando de banco de dados. As vezes possuímos dúvidas com assuntos teoricamente comuns e/ou rotineiros.
Acredito que muitas pessoas que utilizam um banco de dados, como por exemplo o MySQL, já se depararam com alguma dúvida referente a chaves estrangeiras, quanto a modelagem do banco: Qual tipo de relacionamento utilizar?
Quem usa a ferramenta MySQL Workbench, muito provavelmente já notou que existem dois tipos para os relacionamnetos 1:1 e 1:n, os identificados e os não identificados. Fazia algum tempo que tinha essa dúvida, hoje resolvi procurar a respeito e encontrei a resposta:
O relacionamento identificado é para quando a tabela que busca a referência, vai ter o campo da chave estrangeira também como chave primária.
O relacionamneto não identificado é para quando a tabela que busca a referência, não vai ter o campo da chave estrangeira como chave primária.
Posts relacionados:
Tags: chave estrangeira mysql, Identifying e non-identifying relationships, MySQL, mysql workbench
Postado em sábado, maio 16th, 2009 at 1:37 na categoria MySQL. Siga o RSS 2.0 feed. You can leave a response, or trackback from your own site.
16/05/2009 as 1:43
Twitted by LucasRenan disse:[...] This post was Twitted by LucasRenan – Real-url.org [...]
22/05/2009 as 10:29
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?
22/05/2009 as 10:29
Opa, agora apareceu a imagem aqui jauihauhua.
22/05/2009 as 23:29
uahuahauha
eu sempre tive dúvidas sobre esses relacionamentos.
16/12/2009 as 14:54
nossa eu tambem tava com duvida quanto a isso vou muito borigado pela explicação
Parabens pelo site XD
4/02/2010 as 14:39
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!
5/02/2010 as 21:51
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
6/03/2010 as 11:11
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, …)
11/03/2010 as 13:13
Vicente,
você pode me passar uma referência bibliográfica para que eu possa atualizar o post?
12/04/2010 as 4:56
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).
24/06/2010 as 20:12
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.