O que é um relacionamento um para um na modelagem de dados? Como você implementa esse relacionamento em um banco de dados? Os exemplos neste artigo responderão a essas perguntas.
Existem três tipos de relacionamentos entre entidades (tabelas) na modelagem de dados:
- Relações de um para muitos (também indicadas como 1:M).
- Relações muitos para muitos (M:N).
- Relações individuais (1:1).
O tipo mais comum de relacionamento é um relacionamento um-para-muitos, em que um registro em uma entidade pode ser referenciado por vários registros em outra entidade. Outro tipo comum é um relacionamento muitos-para-muitos. Esse tipo de relacionamento é usado apenas em modelos de dados lógicos. Em um banco de dados físico, ele deve ser implementado usando relacionamentos um-para-muitos e uma tabela de junção.
Neste artigo, discutiremos o terceiro tipo de relacionamento:o relacionamento individual . Esse é o tipo menos comum de relacionamento em um modelo de dados. Daremos exemplos de relacionamentos um para um, mostraremos a notação para relacionamentos um para um em um diagrama ER e discutiremos os relacionamentos um para um na prática.
Exemplos de relacionamentos individuais
Primeiro, o que é um relacionamento de um para um? É um relacionamento onde um registro em uma entidade (tabela) está associado a exatamente um registro em outra entidade (tabela).
Vamos ver alguns exemplos da vida real de relacionamentos um para um:
- País - capital :Cada país tem exatamente uma capital. Cada capital é a capital de exatamente um país.
- Pessoa - suas impressões digitais . Cada pessoa tem um conjunto único de impressões digitais. Cada conjunto de impressões digitais identifica exatamente uma pessoa.
- E-mail - conta de usuário . Para muitos sites, um endereço de e-mail está associado a exatamente uma conta de usuário e cada conta de usuário é identificada por seu endereço de e-mail.
- Cônjuge - cônjuge :em um casamento monogâmico, cada pessoa tem exatamente um cônjuge.
- Perfil do usuário - configurações do usuário . Um usuário tem um conjunto de configurações de usuário. Um conjunto de configurações de usuário está associado a exatamente um usuário.
Para maior clareza, vamos contrastar esses exemplos com relacionamentos que não são um para um:
- País - cidade: Cada cidade está em exatamente um país, mas a maioria dos países tem muitas cidades.
- Pai - filho :cada filho tem dois pais, mas cada pai pode ter muitos filhos.
- Funcionário - gerente :cada funcionário tem exatamente um supervisor ou gerente imediato, mas cada gerente geralmente supervisiona muitos funcionários.
Denotando um relacionamento de um para um em um diagrama ER
Um relacionamento um para um em um diagrama ER é indicado, como todos os relacionamentos, com uma linha conectando as duas entidades. A cardinalidade “um” é denotada com uma única linha reta. (A cardinalidade “muitos” é indicada com o símbolo de um pé de galinha.)
A relação um-para-um entre país e capital pode ser denotada assim:
As linhas retas perpendiculares significam “obrigatório ”. Este diagrama mostra que é obrigatório que uma capital tenha um país e é obrigatório que um país tenha uma capital.
Outra possibilidade é que um ou ambos os lados do relacionamento sejam opcionais . Um lado opcional é indicado com um círculo aberto. Este diagrama diz que existe uma relação de um para um entre uma pessoa e suas impressões digitais. Uma pessoa é obrigatória (as impressões digitais devem ser atribuídas a uma pessoa), mas as impressões digitais são opcionais (uma pessoa pode não ter impressões digitais atribuídas no banco de dados).
Relações individuais em um banco de dados físico
Existem algumas maneiras de implementar um relacionamento um para um em um banco de dados físico.
Chave primária como chave estrangeira
Uma maneira de implementar um relacionamento um para um em um banco de dados é usar a mesma chave primária em ambas as tabelas. As linhas com o mesmo valor na chave primária são relacionadas. Neste exemplo, a França é um
country com o id 1 e sua capital está na tabela capital em id 1. country | id | nome |
|---|---|
| 1 | França |
| 2 | Alemanha |
| 3 | Espanha |
capital Tecnicamente, uma das chaves primárias deve ser marcada como chave estrangeira, como neste modelo de dados:
A chave primária na tabela
capital também é uma chave estrangeira que faz referência à coluna id na tabela país . Desde capital.id é uma chave primária, cada valor na coluna é único, então a capital pode fazer referência a no máximo um país. Também deve referenciar um país – é uma chave primária, portanto, não pode ser deixada em branco. Chave estrangeira adicional com restrição exclusiva
Outra maneira de implementar um relacionamento um para um em um banco de dados é adicionar uma nova coluna e torná-la uma chave estrangeira.
Neste exemplo, adicionamos a coluna
country_id na tabela capital . A capital com id 1, Madrid, está associado ao país 3, Espanha. country | id | nome |
|---|---|
| 1 | França |
| 2 | Alemanha |
| 3 | Espanha |
capital | id | nome | id_país |
|---|---|---|
| 1 | Madri | 3 |
| 2 | Berlim | 2 |
| 3 | Paris | 1 |
Tecnicamente, a coluna
country_id deve ser uma chave estrangeira referenciando o id coluna na tabela country . Como você deseja que cada capital seja associado a exatamente um país, você deve tornar a coluna de chave estrangeira country_id exclusivo. 
Relacionamentos individuais na prática
Poucos relacionamentos individuais duram
Relacionamentos um para um são o tipo de relacionamento menos frequente. Uma das razões para isso é que existem muito poucos relacionamentos um-para-um na vida real. Além disso, a maioria dos relacionamentos um-para-um só é um-para-um por algum período de tempo. Se o seu modelo incluir um componente de tempo e capturar o histórico de alterações, como é frequentemente o caso, você terá muito poucos relacionamentos um para um.
Um relacionamento monogâmico pode se separar ou um dos parceiros pode morrer. Se você modelar a realidade dos relacionamentos monogâmicos (como casamentos ou uniões civis) ao longo do tempo, provavelmente precisará modelar o fato de que eles duram apenas por um determinado período.
Você pensaria que uma pessoa e suas impressões digitais nunca mudam. Mas e se a pessoa perder um dedo ou o dedo estiver gravemente queimado? Suas impressões digitais podem mudar. Não é um cenário muito frequente; ainda assim, em alguns modelos, pode ser necessário levar isso em consideração.
Mesmo algo aparentemente tão estável quanto os países e suas capitais mudam ao longo do tempo. Por exemplo, Bonn costumava ser a capital da Alemanha Ocidental (Bundesrepublik Deutschland) após a Segunda Guerra Mundial, quando Berlim fazia parte da Alemanha Oriental. Isso mudou após a reunificação alemã; a capital da Alemanha (Bundesrepublik Deutschland) é agora Berlim. Se você deve ou não levar isso em consideração depende da realidade do seu negócio e do aplicativo em que está trabalhando.
Um cenário 1:1 viável:partes opcionais da tabela
Posso pensar em um cenário viável para um relacionamento real de um para um:partes opcionais de uma tabela. Imagine que você tenha a tabela usuário com dados do usuário. A tabela contém informações gerais do usuário, como nomes de usuários, endereços de e-mail e datas de inscrição. Ele também contém configurações do usuário, como o tema de cores ou o login automático para esse aplicativo. No entanto, a maioria dos usuários não possui configurações de usuário; eles usam as configurações padrão.
user | id | nome | data de inscrição | tema | login automático | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | escuro | verdadeiro |
| 2 | Talitha Yates | [email protected] | 14-12-2020 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | luz | falso |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Igreja Maurício | [email protected] | 20-12-2020 | ||
| 6 | Arwa Valdez | [email protected] | 21-12-2020 |
Há muitos campos vazios nesta tabela. Você pode dividir o
user table em duas tabelas:user e user_settings , que contém informações sobre as configurações dos usuários para aqueles que optaram por selecioná-los. user | id | nome | data de inscrição | tema | login automático | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | escuro | verdadeiro |
| 2 | Talitha Yates | [email protected] | 14-12-2020 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | luz | falso |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Igreja Maurício | [email protected] | 20-12-2020 | ||
| 6 | Arwa Valdez | [email protected] | 21-12-2020 |
user_settings | user_id | tema | login automático |
|---|---|---|
| 1 | escuro | verdadeiro |
| 3 | luz | falso |
A divisão de dados em duas tabelas torna a consulta de tabelas mais complexa:você precisa unir dados de ambas as tabelas. Por outro lado, o principal usuário tabela é mais simples de gerenciar.
Saiba mais sobre relacionamentos de banco de dados
Um relacionamento um para um é um relacionamento em que um registro em uma tabela está associado a exatamente um registro em outra tabela. Esse tipo de relacionamento é raro na vida real. Se você incluir o tempo em seu modelo de dados, muitos relacionamentos um-para-um se tornarão relacionamentos um-para-muitos ou muitos-para-muitos. O cenário mais comum para usar um relacionamento um para um em um banco de dados é dividir uma tabela em duas:uma com colunas obrigatórias e outra com colunas opcionais.
Se você gostou deste artigo, confira outros artigos sobre relacionamentos um-para-muitos e muitos-para-muitos em nosso blog.
Se você é um estudante fazendo aulas de banco de dados, certifique-se de criar uma conta acadêmica gratuita no Vertabelo, nossa ferramenta online de desenho de diagramas ER. Vertabelo permite desenhar diagramas ER lógicos e físicos diretamente no seu navegador. Ele suporta PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift e outros bancos de dados relacionais. Experimente e veja como é fácil começar!
