Existe um momento em que o uso de um relacionamento de banco de dados 1: 1 faz sentido?

162

Eu estava pensando outro dia na normalização, e me ocorreu que não consigo pensar em um momento em que deveria haver um relacionamento 1: 1 em um banco de dados.

  • Name:SSN? Eu os teria na mesma mesa.
  • PersonID:AddressID? Mais uma vez, mesma mesa.

Posso criar um zilhão de exemplos de 1: muitos ou muitos: muitos (com tabelas intermediárias apropriadas), mas nunca um 1: 1.

Estou perdendo algo óbvio?

Pulsehead
fonte
7
SSNs não são números únicos. Eles são reutilizados.
É mais fácil dividir o banco de dados em vários dispositivos físicos quando ele é separado assim.
Pacerier 06/07/12
2
Perdoe um comentário em um comentário realmente antigo acima: os SSNs não são reutilizados e, de fato, identificam uma pessoa exclusivamente.
Derek
É verdade, mas com base em alguns cálculos matemáticos, cerca de metade dos números possíveis já foram emitidos. A SSA afirma que haverá muito mais por algumas gerações, mas mais cedo ou mais tarde eles ficarão sem números, a menos que a política / lei mude. Encontre mais em: ssa.gov/history/hfaq.html
Pulsehead
2
Você pode imaginar que tipo de humor o Mark Brady estava em 5 de fevereiro de 2009 entre as 23:10 e as 23:33. Ele Ele.
Robert

Respostas:

161

Um relacionamento 1: 1 normalmente indica que você particionou uma entidade maior por algum motivo. Freqüentemente, é devido a razões de desempenho no esquema físico, mas também pode ocorrer no lado lógico se se espera que uma grande parte dos dados seja "desconhecida" ao mesmo tempo (nesse caso, você tem 1: 0 ou 1: 1, mas não mais).

Como exemplo de uma partição lógica: você tem dados sobre um funcionário, mas há um conjunto maior de dados que precisam ser coletados, se e somente se eles optarem por ter cobertura de saúde. Eu manteria os dados demográficos referentes à cobertura de saúde em uma tabela diferente para facilitar o particionamento de segurança e evitar transportar esses dados em consultas não relacionadas ao seguro.

Um exemplo de uma partição física seria os mesmos dados hospedados em vários servidores. Posso manter os dados demográficos da cobertura de saúde em outro estado (onde fica o escritório de RH, por exemplo) e o banco de dados primário só pode vincular a ele por meio de um servidor vinculado ... evitando replicar dados confidenciais para outros locais, mas disponibilizando-os para (assumindo aqui raras) consultas que precisam.

O particionamento físico pode ser útil sempre que você tiver consultas que precisem de subconjuntos consistentes de uma entidade maior.

Godeke
fonte
32
Um exemplo perfeito disso pode ser uma tabela que contém arquivos. Você pode (por razões óbvias) ter uma tabela que contenha apenas os metadados do arquivo (nome do arquivo, tipo mime etc.) e outra tabela mapeada 1: 1 que contenha os dados reais do blob. Isso reduziria a sobrecarga na consulta / classificação dos arquivos em alguns casos.
22610 Kevin Peno
2
Sim. Depende do banco de dados (os designs modernos estão armazenando blobs no sistema de arquivos apenas usando o tipo correto) e, mesmo com esse suporte, é preciso ter cuidado para excluir as colunas (nas listas de colunas explícitas do SQL são normais, mas alguns ORMs querem arrastar o registro inteiro). O truque é conhecer seu padrão de uso: se na maioria das vezes os dados reais forem ignorados, eu usaria uma tabela de blob 1: 1. Se a maioria dos acessos for downloads dos dados, eu usaria o mecanismo de armazenamento nativo.
Godeke
@Ochado Embora eu concorde que você tenha muitas razões naturais (não físicas) para 1: 1, a advertência "se você não tiver informações históricas" faz os casos em que eu provavelmente não usaria uma relação 1: 1 para aplicar.
Godeke
1
@ Ochado Eu acho que o relacionamento IS-A é um bom exemplo, no entanto. Tento evitar tentar forçar conceitos orientados a objetos em minhas tabelas (em vez disso, usando um ORM como uma biblioteca de dados), mas vi casos em que fui tentado. O desempenho de tais sistemas em escala matou esses experimentos. Ainda assim, esse é provavelmente o melhor exemplo de exemplo não relacionado ao desempenho.
Godeke 11/01
Na verdade, o IS-A e também os cenários de reservas correspondentes provavelmente permaneceriam 1: 1, mesmo se os dados históricos forem armazenados.
Tripartio
125

Um dos motivos é a eficiência do banco de dados. Ter um relacionamento 1: 1 permite dividir os campos que serão afetados durante um bloqueio de linha / tabela. Se a tabela A possui muitas atualizações e a tabela b possui muitas leituras (ou muitas atualizações de outro aplicativo), o bloqueio da tabela A não afeta o que está acontecendo na tabela B.

Outros trazem um bom argumento. A segurança também pode ser um bom motivo, dependendo de como os aplicativos etc. estão atingindo o sistema. Eu tenderia a adotar uma abordagem diferente, mas pode ser uma maneira fácil de restringir o acesso a determinados dados. É realmente fácil negar o acesso a uma determinada mesa rapidamente.

Minha entrada de blog sobre isso.

kemiller2002
fonte
47

Escassez. O relacionamento de dados pode ser tecnicamente 1: 1, mas as linhas correspondentes não precisam existir para cada linha. Portanto, se você tiver vinte milhões de linhas e houver algum conjunto de valores que exista apenas para 0,5% deles, a economia de espaço será grande se você empurrar essas colunas para uma tabela que pode ser pouco preenchida.

caos
fonte
8
"mas as linhas correspondentes não precisam existir para todas as linhas". Isso não é 1: 1. Você está falando de 1: 0,1.
1
Sim. Não sei se o OP faz a distinção.
caos
2
Bem, eu diria que eles fizeram porque 1: 0,1 tem muitos usos, incluindo o seu, mas 1: 1 tem muito menos. E eles estavam lutando para encontrar usos, então eu diria que o OP estava fazendo a distinção.
12
Minha suposição de trabalho foi o contrário, porque ele enumerou 1: 1, 1: muitos e muitos: muitos sem mencionar 1: 0,1.
caos
26

A maioria das respostas altamente classificadas fornece motivos de otimização e otimização do banco de dados muito úteis para relacionamentos 1: 1, mas eu quero focar em nada além de exemplos "inativos" onde os relacionamentos 1: 1 ocorrem naturalmente.

Observe uma característica importante da implementação do banco de dados da maioria desses exemplos: nenhuma informação histórica é mantida sobre o relacionamento 1: 1. Ou seja, esses relacionamentos são 1: 1 em um determinado momento. Se o designer do banco de dados quiser registrar alterações nos participantes do relacionamento ao longo do tempo, os relacionamentos se tornarão 1: M ou M: M; eles perdem sua natureza 1: 1. Com isso entendido, aqui vai:

  • Relações "Is-A" ou supertipo / subtipo ou herança / classificação: Esta categoria é quando uma entidade é um tipo específico de outra entidade. Por exemplo, poderia haver uma entidade Funcionário com atributos que se aplica a todos os funcionários e, em seguida, entidades diferentes para indicar tipos específicos de funcionários com atributos exclusivos para esse tipo de funcionário, por exemplo, Médico, Contador, Piloto, etc. Esse design evita vários valores nulos, pois muitos funcionários não teriam os atributos especializados de um subtipo específico. Outros exemplos nessa categoria podem ser Product como supertipo e ManufacturingProduct and MaintenanceSupply como subtipos; Animal como supertipo e Cão e Gato como subtipos; etc. Observe que sempre que você tenta mapear uma hierarquia de herança orientada a objetos em um banco de dados relacional (como em um modelo de objeto relacional), esse é o tipo de relacionamento que representa esses cenários.

  • Relações de "chefe" , como gerente, presidente, presidente etc., em que uma unidade organizacional pode ter apenas um chefe e uma pessoa pode ser chefe de apenas uma unidade organizacional. Se essas regras se aplicarem, você terá um relacionamento 1: 1, como um gerente de um departamento, um CEO de uma empresa etc. Os relacionamentos de "chefe" não se aplicam apenas às pessoas. O mesmo tipo de relacionamento ocorre se houver apenas uma loja como sede de uma empresa ou se apenas uma cidade for a capital de um país, por exemplo.

  • Alguns tipos de alocação escassa de recursos , por exemplo, um funcionário pode receber apenas um carro da empresa por vez (por exemplo, um caminhão por caminhoneiro, um táxi por motorista de táxi, etc.). Um colega me deu esse exemplo recentemente.

  • Casamento (pelo menos em jurisdições legais onde a poligamia é ilegal): uma pessoa pode ser casada com apenas uma outra pessoa de cada vez. Eu recebi esse exemplo de um livro que o usou como exemplo de um relacionamento unário 1: 1 quando uma empresa registra casamentos entre seus funcionários.

  • Reservas correspondentes : quando uma reserva exclusiva é feita e depois atendida como duas entidades separadas. Por exemplo, um sistema de aluguel de carros pode registrar uma reserva em uma entidade e, em seguida, um aluguel real em uma entidade separada. Embora essa situação possa ser projetada alternativamente como uma entidade, pode fazer sentido separar as entidades, pois nem todas as reservas são cumpridas e nem todos os aluguéis exigem reservas, e as duas situações são muito comuns.

Repito a ressalva que fiz anteriormente de que a maioria desses relacionamentos é de 1: 1 somente se nenhuma informação histórica for registrada. Portanto, se um funcionário mudar de função em uma organização, ou se um gerente assumir a responsabilidade de um departamento diferente, ou se um funcionário for transferido para um veículo ou se alguém for viúvo e se casar novamente, os participantes do relacionamento poderão mudar. Se o banco de dados não armazenar nenhum histórico anterior sobre esses relacionamentos 1: 1, eles permanecerão relacionamentos legítimos 1: 1. Mas se o banco de dados registra informações históricas (como adicionar datas de início e término para cada relacionamento), elas praticamente se transformam em relacionamentos M: M.

Há duas exceções notáveis ​​na nota histórica: Primeiro, alguns relacionamentos mudam tão raramente que as informações históricas normalmente não seriam armazenadas. Por exemplo, a maioria dos relacionamentos IS-A (por exemplo, tipo de produto) é imutável; isto é, eles nunca podem mudar. Assim, o ponto de registro histórico é discutível; estes sempre seriam implementados como relacionamentos naturais 1: 1. Segundo, a loja de relacionamento reserva-aluguel data separadamente, pois a reserva e o aluguel são eventos independentes, cada um com suas próprias datas. Como as entidades têm suas próprias datas, em vez de o relacionamento 1: 1 ter uma data de início, eles permaneceriam como relacionamentos 1: 1, mesmo que as informações históricas sejam armazenadas.

Tripartio
fonte
2
Eu realmente gosto de como você se ateve ao espírito de pergunta original sobre quando essa relação está correta e não quando é útil por razões terrenas, como a natureza física dos computadores.
user1852503
21

Sua pergunta pode ser interpretada de várias maneiras, devido à maneira como você a formulou. As respostas mostram isso.

Definitivamente, pode haver relacionamentos 1: 1 entre itens de dados no mundo real. Nenhuma pergunta sobre isso. O relacionamento "é um" geralmente é um para um. Um carro é um veículo. Um carro é um veículo. Um veículo pode ser um carro. Alguns veículos são caminhões; nesse caso, um veículo não é um carro. Várias respostas abordam essa interpretação.

Mas acho que o que você realmente está perguntando é ... quando existem relacionamentos 1: 1, as tabelas devem ser divididas? Em outras palavras, você deve ter duas tabelas que contêm exatamente as mesmas chaves? Na prática, a maioria de nós analisa apenas chaves primárias, e não outras chaves candidatas, mas essa pergunta é um pouco diferente.

As regras de normalização para 1NF, 2NF e 3NF nunca exigem a decomposição (divisão) de uma tabela em duas tabelas com a mesma chave primária. Ainda não descobri se colocar um esquema em BCNF, 4NF ou 5NF pode resultar em duas tabelas com as mesmas chaves. Em cima da minha cabeça, vou adivinhar que a resposta é não.

Há um nível de normalização chamado 6NF. A regra de normalização para 6NF pode definitivamente resultar em duas tabelas com a mesma chave primária. O 6NF tem a vantagem sobre o 5NF de que NULLS podem ser completamente evitados. Isso é importante para alguns, mas não para todos os designers de banco de dados. Eu nunca me preocupei em colocar um esquema em 6NF.

No 6NF, os dados ausentes podem ser representados por uma linha omitida, em vez de uma linha com um NULL em alguma coluna.

Há outros motivos além da normalização para dividir tabelas. Às vezes, as tabelas divididas resultam em melhor desempenho. Com alguns mecanismos de banco de dados, você pode obter os mesmos benefícios de desempenho particionando a tabela em vez de realmente dividi-la. Isso pode ter a vantagem de manter o design lógico fácil de entender, enquanto fornece ao mecanismo de banco de dados as ferramentas necessárias para acelerar as coisas.

Walter Mitty
fonte
19

Eu os uso principalmente por alguns motivos. Uma é a diferença significativa na taxa de alteração de dados. Algumas de minhas tabelas podem ter trilhas de auditoria nas quais rastreio versões anteriores de registros, se apenas desejar rastrear versões anteriores de 5 de 10 colunas dividindo essas 5 colunas em uma tabela separada com um mecanismo de trilha de auditoria mais eficiente. Além disso, posso ter registros (digamos, para um aplicativo de contabilidade) que são apenas para gravação. Você não pode alterar os valores em dólares ou a conta em que estavam, se cometer um erro, precisará fazer um registro correspondente para ajustar o registro incorreto e criar uma entrada de correção. Tenho restrições na tabela que impõem o fato de que elas não podem ser atualizadas ou excluídas, mas posso ter alguns atributos para esse objeto que são maleáveis, esses são mantidos em uma tabela separada sem a restrição de modificação. Outra vez que faço isso é em aplicativos de registros médicos. Existem dados relacionados a uma visita que não podem ser alterados após o encerramento da sessão e outros dados relacionados a uma visita que podem ser alterados após a saída. Nesse caso, dividirei os dados e acionarei a tabela bloqueada, rejeitando atualizações na tabela bloqueada quando desconectado, mas permitindo atualizações nos dados nos quais o médico não está assinando.

Outro pôster comentou que 1: 1 não estava sendo normalizado, eu discordaria disso em algumas situações, especialmente na subtipagem. Digamos que eu tenha uma tabela de funcionários e a chave primária seja o SSN (é um exemplo, vamos salvar o debate sobre se essa é uma boa chave ou não para outro encadeamento). Os funcionários podem ser de tipos diferentes, por exemplo, temporários ou permanentes e, se forem permanentes, terão mais campos a serem preenchidos, como o número de telefone do escritório, que só deve ser nulo se o tipo = 'Permanente'. Em um terceiro banco de dados de formulário normal, a coluna deve depender apenas da chave, ou seja, o funcionário, mas na verdade depende do funcionário e do tipo; portanto, um relacionamento 1: 1 é perfeitamente normal e desejável nesse caso. Isso também evita tabelas excessivamente esparsas, se eu tiver 10 colunas normalmente preenchidas,

Shane Delmore
fonte
1
@ShaneD +1 para exemplo de palavras reais. Eu também gosto da distinção "Somente leitura".
Michael Riley - AKA Gunny
13

O cenário mais comum em que consigo pensar é quando você tem BLOB's. Digamos que você queira armazenar imagens grandes em um banco de dados (normalmente, não é a melhor maneira de armazená-las, mas às vezes as restrições o tornam mais conveniente). Você normalmente deseja que o blob esteja em uma tabela separada para melhorar as pesquisas dos dados que não são de blob.

Erik Funkenbusch
fonte
Seriamente? Normalmente não é o melhor caminho? O maior fornecedor de música on-line armazena seus MP3s em um banco de dados.
1
@ Mark, existem algumas perguntas que tratam da melhor maneira de armazenar imagens, em um banco de dados ou fora, e o consenso parece ser o de que, na maioria das vezes, o sistema de arquivos é mais rápido. Imagino que, se isso é verdade, o mesmo se aplica aos MP3s.
21413 James McMahon
1
"Você normalmente deseja o BLOB em uma tabela separada" - normalmente os BLOBs não são armazenados em linha (se excederem um determinado comprimento de linha específico do db). BLOBs, se não estiverem em linha, geralmente são armazenados como um 'ponteiro' para sua localização física nas páginas do banco de dados.
blispr
1
É discutível se faz sentido armazenar grandes dados (arquivos) em um banco de dados, alguns são para alguns contra todos têm razões válidas, mas +1 para o exemplo de 1: 1.
22610 Kevin Peno
Essa deveria ser realmente a sua própria pergunta que eu gostaria de ver. Com a contribuição de pessoas inteligentes que medem o tempo / prestanda para diferentes discos rígidos / OS / RDBMS. DEVE haver uma resposta definitiva para esta pergunta, não deve ser discutível, se medido corretamente. Já ninguém fez isso tudo?
Stefan
9

Em termos de ciência pura, sim, eles são inúteis.

Em bancos de dados reais, às vezes é útil manter um campo raramente usado em uma tabela separada: para acelerar consultas usando esse e somente esse campo; para evitar bloqueios, etc.

Quassnoi
fonte
3
@ Mark Brady: não, não, pois existem Na2SO4 e KCl. Ao criar um banco de dados do universo, você deve criar t_atom (id INT, prótons INT, nêutrons INT), t_molecule (id INT, atom_id INT) e fazer junções. É um relacionamento um para muitos.
Quassnoi
2
Pensando bem, a INT pode não ser suficiente aqui, pois existem 10 ^ 78 átomos no universo. Até dois GUIDs colados podem conter apenas 1/10 dos átomos. Precisamos de uma chave primária RAW (40) - caso o nosso banco de dados cresça rápido demais. Matéria escura, você sabe, de alguma coisa.
Quassnoi
1
Ah, então apenas a teoria relacional é pura ciência. Não percebemos que a química não era uma ciência pura, a menos que construíssemos um banco de dados para ela.
1
@ Mark Brady: você não poderia dizer o que é que você não concorda? Eu não entendo o seu sarcasmo, realmente :)
Quassnoi
Quassnoi (e Mark Brady) Você recebe um voto positivo pelo LOL que você acabou de me dar.
Pulsehead
8

Em vez de usar visualizações para restringir o acesso aos campos, às vezes faz sentido manter os campos restritos em uma tabela separada à qual apenas alguns usuários têm acesso.

onze81
fonte
8

Também posso pensar em situações em que você tem um modelo OO em que você usa herança, e a árvore de herança precisa ser mantida no banco de dados.

Por exemplo, você tem uma classe Pássaro e Peixe que ambos herdam de Animal. No seu banco de dados, você poderia ter uma tabela 'Animal', que contém os campos comuns da classe Animal, e a tabela Animal tem um relacionamento individual com a tabela Bird e um relacionamento individual com o Fish tabela.

Nesse caso, você não precisa ter uma tabela Animal que contém muitas colunas anuláveis ​​para conter as propriedades Bird e Fish, onde todas as colunas que contêm dados de Fish são definidas como NULL quando o registro representa um pássaro.

Em vez disso, você tem um registro na tabela Birds que possui um relacionamento individual com o registro na tabela Animal.

Frederik Gheysels
fonte
Esta resposta está relacionada a outra pergunta: a da relação de 1 a 0‑1.
precisa saber é o seguinte
8

Os relacionamentos 1-1 também são necessários se você tiver muita informação. Há uma limitação de tamanho de registro em cada registro da tabela. Às vezes, as tabelas são divididas em duas (com as informações mais comumente consultadas na tabela principal) apenas para que o tamanho do registro não seja muito grande. Os bancos de dados também são mais eficientes na consulta se as tabelas são estreitas.

HLGEM
fonte
6

É também uma maneira de estender uma tabela que já está em produção com menos risco (percebido) do que uma alteração "real" no banco de dados. Ver um relacionamento 1: 1 em um sistema legado geralmente é um bom indicador de que os campos foram adicionados após o design inicial.

JT Grimes
fonte
Por que equivocar? Você acha que uma marca que bate em uma nova tabela tem tanto risco quanto alterar uma tabela existente? Por favor, liste as coisas que quebram quando novas tabelas são adicionadas. A única coisa em que consigo pensar é no código que opera sobre os metadados, ou seja, SELECT * From USER_TABLES loop <something> end loop.
1
É menos provável que as coisas quebrem do que muitas vezes é necessário mais trabalho para adicionar uma tabela 1: 1 corretamente do que para adicionar um campo extra. Agora, um novo registro significa atualizar duas tabelas em vez de apenas uma. Excluindo um registro? Duas consultas também. Agora estamos mantendo mais código em vez de alterá-lo uma vez.
JT Grimes
@ Mark Brady, conjuntos de dados fortemente tipados podem ser um inferno para gerenciar ao adicionar alguns arquivos no banco de dados. Se um leitor de tabela no conjunto de dados tiver muitas consultas e assim por diante, é muito mais fácil arrastar a nova tabela e pronto.
Stefan
@ Stefan: Não há inserção em cascata.
JT Grimes
@ Boofus, bem ... às vezes temos que usar o teclado e programar um pouco pelo dinheiro que ganhamos. ;)
Stefan
5

No SQL, é impossível impor um relacionamento 1: 1 entre duas tabelas que é obrigatório em ambos os lados (a menos que as tabelas sejam somente leitura). Para propósitos mais práticos, um relacionamento "1: 1" no SQL realmente significa 1: 0 | 1.

A incapacidade de oferecer suporte à cardinalidade obrigatória em restrições referenciais é uma das sérias limitações do SQL. Restrições "adiadas" não contam realmente porque são apenas uma maneira de dizer que a restrição não é impingida em algum momento.

nvogel
fonte
4

Se você estiver usando os dados com um dos ORMs populares, convém dividir uma tabela em várias tabelas para corresponder à sua Hierarquia de Objetos.

Jason Punyon
fonte
3
Triste, triste razão. Se um ORM não pode lidar com uma divergência entre o modelo de objeto e o armazenamento físico, então ... é triste.
Na verdade, se eu entendi direito, isso significa implementar hierarquias de classificação no banco de dados relacional. Este é um caso perfeitamente legítimo e natural de relacionamentos 1: 1; não há nada de "triste" nisso.
Tripartio
4

Descobri que quando faço um relacionamento 1: 1 é totalmente por uma razão sistêmica, não por uma razão relacional.

Por exemplo, descobri que colocar os aspectos reservados de um usuário em uma tabela e colocar os campos editáveis ​​do usuário em uma tabela diferente permite escrever logicamente essas regras sobre permissões nesses campos muito mais fácil.

Mas você está correto, em teoria, os relacionamentos 1: 1 são completamente inventados e são quase um fenômeno. No entanto, logicamente, permite que os programas e otimizações abstrajam o banco de dados com mais facilidade.

DevelopingChris
fonte
fenômeno: é qualquer fato ou evento de interesse científico suscetível de ser descrito e / ou explicado cientificamente. Eu não acho que você pretendia usar essa palavra.
1
Eu pretendia usá-lo, em sua conotação, de ser uma coisa rara. Normalmente, o fenômeno é usado para descrever discrepâncias, mesmo que sua definição defina sua necessidade de corrigir cada palavra no meu post.
DevelopingChris
@DevelopingChris Concordo que 1: 1 é um fenômeno. Exceto pela teoria da escola, existem muito poucas situações do mundo real.
Michael Riley - AKA Gunny
4

Na maioria das vezes, pensa-se que os desenhos sejam 1: 1 até que alguém pergunte "bem, por que não pode ser 1: muitos"? O divórcio prematuro dos conceitos é feito em antecipação a esse cenário comum. Pessoa e endereço não se vinculam tão firmemente. Muitas pessoas têm vários endereços. E assim por diante...

Normalmente, dois espaços de objetos separados implicam que um ou ambos possam ser multiplicados (x: muitos). Se dois objetos eram verdadeiramente, verdadeiramente 1: 1, mesmo filosoficamente, então é mais um relacionamento é. Esses dois "objetos" são na verdade partes de um objeto inteiro.

Mark Canlas
fonte
3

informações estendidas necessárias apenas em certos cenários. em aplicativos herdados e linguagens de programação (como RPG), em que os programas são compilados sobre as tabelas (por isso, se a tabela mudar, é necessário recompilar o (s) programa (s)). Os arquivos de tag along também podem ser úteis nos casos em que você precisa se preocupar com o tamanho da tabela.

Ryan Guill
fonte
2

Na maioria das vezes, é mais uma construção física do que lógica. É comumente usado para particionar verticalmente uma tabela para aproveitar a divisão de E / S entre dispositivos físicos ou outras otimizações de consulta associadas à segregação de dados acessados ​​com menos frequência ou dados que precisam ser mantidos mais seguros que o restante dos atributos no mesmo objeto (SSN, salário, etc).

A única consideração lógica que prescreve um relacionamento 1-1 é quando determinados atributos se aplicam apenas a algumas das entidades. No entanto, na maioria dos casos, existe uma maneira melhor / mais normalizada de modelar os dados por meio da extração da entidade.

JohnFx
fonte
2

A melhor razão que eu posso ver para um relacionamento 1: 1 é um SuperType SubType de design de banco de dados. Criei uma estrutura de dados do Real Estate MLS com base nesse modelo. Havia cinco feeds de dados diferentes; Residencial, Comercial, Multifamiliar, Hotéis e Terrenos.

Criei uma propriedade chamada SuperType que continha dados comuns a cada um dos cinco feeds de dados separados. Isso permitiu pesquisas "simples" muito rápidas em todos os tipos de dados.

Criei cinco subtipos separados que armazenavam os elementos de dados exclusivos para cada um dos cinco feeds de dados. Cada registro SuperType tinha um relacionamento 1: 1 com o registro SubType apropriado.

Se um cliente quisesse uma pesquisa detalhada, ele teria que selecionar um tipo Super-Sub, por exemplo PropertyResidential.

Michael Riley - também conhecido por Gunny
fonte
1

Na minha opinião, um relacionamento 1: 1 mapeia uma herança de classe em um RDBMS. Há uma tabela A que contém os atributos comuns, ou seja, o status da classe de partente. Cada status de classe herdado é mapeado no RDBMS com uma tabela B com um relacionamento 1: 1 com a tabela A, contendo os atributos especializados. O nome da tabela A também contém um campo "type" que representa a funcionalidade "casting"

Tchau Mario


fonte
1

Você pode criar uma tabela de relacionamento um para um se houver algum benefício significativo de desempenho. Você pode colocar os campos raramente usados ​​em uma tabela separada.

kta
fonte
0

Os relacionamentos 1: 1 realmente não fazem sentido se você estiver na normalização, pois qualquer coisa que seria 1: 1 seria mantida na mesma tabela.

No mundo real, porém, muitas vezes é diferente. Você pode dividir seus dados para corresponder à interface de aplicativos.

Eppz
fonte
Eu discordo da teoria de uma tabela. Há momentos em que um relacionamento SuperType SubType é melhor expresso com relacionamentos 1: 1.
Michael Riley - AKA Gunny
1
Na verdade, se você adotasse uma extrema normalização, teria muito mais relacionamentos 1: 1. As primeiras formas de normalização propostas por Date incluíram a regra de que nenhuma coluna deve permitir NULL. Isso significava que, se uma coluna pudesse ser NULL para uma tabela, ela deveria estar em sua própria tabela e uma linha adicionada somente quando avaliada. Esta regra foi descartada principalmente, inclusive pelo Codd.
TomHard6
0

Possivelmente se você tiver algum tipo de objeto digitado no seu banco de dados.

Digamos que em uma tabela T1 você tenha as colunas C1, C2, C3 ... com uma relação de um para um. Está tudo bem, está na forma normalizada. Agora, digamos que na tabela T2, você tenha as colunas C1, C2, C3,… (os nomes podem diferir, mas digamos que os tipos e a função sejam os mesmos) com uma relação de um para um também. Não há problema em T2 pelos mesmos motivos que em T1.

Nesse caso, no entanto, vejo um ajuste para uma tabela separada T3, contendo C1, C2, C3 ... e uma relação de um para um de T1 para T3 e de T2 para T3. Eu vejo ainda mais um ajuste se existir outra tabela, com a qual já exista uma para vários C1, C2, C3 ... digamos da tabela A para várias linhas na tabela B. Então, em vez de T3, você usa B e tem uma relação um a um de T1 a B, o mesmo para T2 a B e ainda a mesma relação múltipla de A a B.

Acredito que a normalização não concorda com isso, e isso pode ser uma idéia fora dela: identificar tipos de objetos e mover objetos do mesmo tipo para seu próprio pool de armazenamento, usando uma relação de um para um de algumas tabelas e uma para vários relação de algumas outras tabelas.

Hibou57
fonte
0

É desnecessário para fins de segurança, mas existem maneiras melhores de realizar verificações de segurança. Imagine, você cria uma chave que pode abrir apenas uma porta. Se a chave puder abrir qualquer outra porta, você deverá tocar o alarme. Em essência, você pode ter "CitizenTable" e "VotingTable". Cidadão Um voto para o Candidato Um que está armazenado na Mesa de Votação. Se um cidadão aparecer novamente na mesa de votação, então deve ser um alarme. Seja um conselho, este é um relacionamento individual, porque não estamos nos referindo ao campo do candidato, estamos nos referindo à mesa de votação e à mesa do cidadão.

Exemplo:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Então, se virmos a mesa de votação da seguinte forma:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Poderíamos dizer que o cidadão número 3 é um mentiroso que enganou Bern Nie. Apenas um exemplo.

Lesly Revenge
fonte
0

Quando você está lidando com um banco de dados de um produto de terceiros, provavelmente não deseja alterar o banco de dados para evitar um acoplamento rígido. mas você pode ter dados que correspondem 1: 1 com os dados deles

simbionte
fonte
-4

Em qualquer lugar, duas entidades totalmente independentes compartilham um relacionamento individual. Deve haver muitos exemplos:

pessoa <-> dentista (é 1: N, está errado!)

pessoa <-> médico (é 1: N, também está errado!)

pessoa <-> cônjuge (é 1: 0 | 1, então é quase todo errado!)

EDIT: Sim, esses foram exemplos muito ruins, principalmente se eu estava sempre procurando um 1: 1, não um 0 ou 1 de cada lado. Eu acho que meu cérebro estava disparando errado :-)

Então, vou tentar novamente. Depois de um pouco de reflexão, acontece que a única maneira de ter duas entidades separadas que devem (no que diz respeito ao software) estar juntas o tempo todo é que elas existam juntas em uma categorização mais alta. Então, se e somente se você cair em uma decomposição mais baixa, as coisas são e devem ser separadas, mas no nível superior elas não podem viver uma sem a outra. Contexto, então é a chave.

Para um banco de dados médico, convém armazenar informações diferentes sobre regiões específicas do corpo, mantendo-as como uma entidade separada. Nesse caso, um paciente tem apenas uma cabeça e eles precisam dela, ou não são pacientes. (Eles também têm um coração e vários outros órgãos únicos necessários). Se você estiver interessado em rastrear cirurgias, por exemplo, cada região deve ser uma entidade separada e única.

Em um sistema de produção / estoque, se você estiver acompanhando a montagem de veículos, certamente desejará assistir o motor progredir de forma diferente da carroceria do carro, mas há um relacionamento individual. Um cuidado deve ter um motor e apenas um (ou não seria mais um 'carro'). Um motor pertence a apenas um carro.

Em cada caso, você poderia produzir as entidades separadas como um grande registro, mas, dado o nível de decomposição, isso seria errado. São, nesses contextos específicos, entidades verdadeiramente independentes, embora possam não parecer assim em um nível superior.

Paulo.

Paul W Homer
fonte
Um dentista tem um paciente? Um médico tem apenas um paciente? Pessoa ao cônjuge em apenas 1: 1, se você colocar um cônjuge em uma mesa e o outro cônjuge em outro (Eu estava prestes a dizer homens em um e mulheres em outro oh bem.)
Mark, você pode simplesmente criar uma tabela "Casais", onde as linhas sempre vêm em pares. Mas, caso contrário, eu concordo com o seu, ehm ... discurso retórico. : P
JohannesH
Sim, eu também concordo com o Mark. :-) (Eu sou eu permitido dis minha própria resposta estúpida?)
Paul W Homer
Sim, aceitar a "burrice" prova o quão inteligente você é. Os covardes verdadeiros apagam suas respostas idiotas ... ainda bem que não são médicos, apagando registros médicos. Na verdade, é uma coisa boa que também não somos; reiniciar seria um tratamento médico ruim.
2
Eu sempre imaginei que mesmo a pessoa mais inteligente do mundo (quem quer que seja nesse momento) ainda tem seus momentos de estupidez. É uma maldição humana :-) Enquanto meu computador tem momentos de quase inteligência.
2113 Paul W Homer