Um relacionamento é estabelecido entre duas tabelas de banco de dados quando uma tabela possui uma chave estrangeira que faz referência à chave primária de outra tabela. Este é o conceito básico por trás do banco de dados relacional.
Como uma chave estrangeira funciona para estabelecer um relacionamento
Vamos rever os fundamentos das chaves primárias e estrangeiras. Uma chave primária identifica exclusivamente cada registro na tabela. É um tipo de chave candidata que geralmente é a primeira coluna de uma tabela e pode ser gerada automaticamente pelo banco de dados para garantir que seja única.
Uma chave estrangeira é outra chave candidata (não a chave primária) usada para vincular um registro a dados em outra tabela.
Por exemplo, considere estas duas tabelas que identificam qual professor ensina qual curso.
Aqui, a chave primária da tabela Courses é Course_ID. Sua chave estrangeira é Teacher_ID:
| Identidade do curso | Nome do curso | Teacher_ID |
|---|---|---|
| Course_001 | Biologia | Teacher_001 |
| Course_002 | Matemática | Teacher_001 |
| Course_003 | Inglês | Professor_003 |
Você pode ver que a chave estrangeira em Cursos corresponde a uma chave primária em Professores:
| Teacher_ID | Nome do professor |
|---|---|
| Teacher_001 | Carmen |
| Professor_002 | Veronica |
| Professor_003 | Jorge |
Podemos dizer que a chave estrangeira Teacher_ID ajudou a estabelecer um relação entre as tabelas Cursos e Professores.
Tipos de Relacionamentos de Banco de Dados
Usando chaves estrangeiras ou outras chaves candidatas, você pode implementar três tipos de relacionamentos entre tabelas:
Um a um: Esse tipo de relacionamento permite apenas um registro em cada lado do relacionamento.
A chave primária refere-se a apenas um registro - ou nenhum - em outra tabela. Por exemplo, em um casamento, cada cônjuge tem apenas um outro cônjuge. Esse tipo de relacionamento pode ser implementado em uma única tabela e, portanto, não usa uma chave estrangeira.
Um para muitos: Um relacionamento um-para-muitos permite que um único registro em uma tabela seja relacionado a vários registros em outra tabela.
Considere um negócio com um banco de dados que tenha tabelas Customers e Orders.
Um único cliente pode comprar vários pedidos, mas um único pedido não pode ser vinculado a vários clientes. Portanto, a tabela Pedidos conteria uma chave estrangeira que correspondia à chave primária da tabela Clientes, enquanto a tabela Clientes não teria nenhuma chave estrangeira apontando para a tabela Pedidos.
Muitos para muitos: Este é um relacionamento complexo em que muitos registros em uma tabela podem vincular a muitos registros em outra tabela. Por exemplo, nossa empresa provavelmente precisa não apenas de tabelas Customers e Orders, mas provavelmente também precisa de uma tabela Products.
Novamente, a relação entre a tabela Clientes e Pedidos é um-para-muitos, mas considere o relacionamento entre a tabela Pedidos e Produtos. Um pedido pode conter vários produtos e um produto pode estar vinculado a vários pedidos: vários clientes podem enviar um pedido que contenha alguns dos mesmos produtos. Esse tipo de relacionamento requer no mínimo três tabelas.
O que são relações de banco de dados importantes?
O estabelecimento de relacionamentos consistentes entre as tabelas do banco de dados ajuda a garantir a integridade dos dados, contribuindo para a normalização do banco de dados. Por exemplo, e se não ligássemos tabelas por meio de uma chave estrangeira e, em vez disso, apenas combinássemos os dados nas tabelas Cursos e Professores, da seguinte forma:
| Teacher_ID | Nome do professor | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia, Matemática |
| Professor_002 | Veronica | Matemática |
| Professor_003 | Jorge | Inglês |
Esse design é inflexível e viola o primeiro princípio de normalização do banco de dados, First Normal Form (1NF), que afirma que cada célula da tabela deve conter uma única parte discreta de dados.
Ou talvez tenhamos decidido simplesmente adicionar um segundo registro para Carmen, a fim de impor 1NF:
| Teacher_ID | Nome do professor | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_001 | Carmen | Matemática |
| Professor_002 | Veronica | Matemática |
| Professor_003 | Jorge | Inglês |
Este ainda é um projeto fraco, introduzindo duplicações desnecessárias e o que é chamado anomalias de inserção de dados , o que significa apenas que poderia contribuir para dados inconsistentes.
Por exemplo, se um professor tiver vários registros, e se alguns dados precisarem ser editados, mas a pessoa que estiver executando a edição de dados não perceber que existem vários registros? A tabela conteria dados diferentes para o mesmo indivíduo, sem qualquer maneira clara de identificá-lo ou evitá-lo.
Quebrando essa tabela em duas tabelas, Teachers and Courses (como visualizado acima), cria a relação adequada entre os dados e, portanto, ajuda a garantir a consistência e precisão dos dados.
