Um relacionamento é estabelecido entre duas tabelas de banco de dados quando uma tabela usa uma chave estrangeira que referencia a chave primária de outra tabela. Este é o conceito básico por trás do termo banco de dados relacional.
Como uma chave estrangeira funciona para estabelecer um relacionamento
Uma chave primária identifica exclusivamente cada registro na tabela. É um tipo de chave candidata que geralmente é a primeira coluna em uma tabela e pode ser gerada automaticamente pelo banco de dados para garantir que seja exclusiva. 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:
| Course_ID | Nome_Curso | Teacher_ID |
|---|---|---|
| Curso_001 | Biologia | Teacher_001 |
| Curso_002 | Matemática | Professor_002 |
| Curso_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 | Verônica |
| Professor_003 | Jorge |
Podemos dizer que a chave estrangeira Teacher_ID ajudou a estabelecer uma 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 para Um
Este 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 utiliza 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 uma empresa com um banco de dados que possui tabelas Clientes e Pedidos.
Um único cliente pode comprar vários pedidos, mas um único pedido não pode ser vinculado a vários clientes. Portanto, a tabela Orders conteria uma chave estrangeira que correspondesse à chave primária da tabela Customers, enquanto a tabela Customers não teria nenhuma chave estrangeira apontando para a tabela Orders.
Muitos-para-Muitos
Esta é uma relação complexa na qual muitos registros em uma tabela podem se vincular a muitos registros em outra tabela. Por exemplo, nossa empresa provavelmente precisa das tabelas Clientes e Pedidos e provavelmente também precisa de uma tabela Produtos.
Novamente, o relacionamento 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, pois vários clientes podem enviar um pedido que contenha alguns dos mesmos produtos. Esse tipo de relacionamento requer no mínimo três tabelas.
Por que os relacionamentos de banco de dados são importantes?
Estabelecer 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 vinculássemos nenhuma tabela por meio de uma chave estrangeira e, em vez disso, combinássemos os dados nas tabelas Cursos e Professores, assim:
| Teacher_ID | Nome_do professor | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia, Matemática |
| Professor_002 | Verônica | Matemática |
| Professor_003 | Jorge | Inglês |
Este design é inflexível e viola o primeiro princípio de normalização de banco de dados, First Normal Form, que afirma que cada célula da tabela deve conter um único e discreto pedaço de dados.
Ou talvez tenhamos decidido adicionar um segundo registro para Carmen, para reforçar 1NF:
| Teacher_ID | Nome_do professor | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_001 | Carmen | Matemática |
| Professor_002 | Verônica | Matemática |
| Professor_003 | Jorge | Inglês |
Este ainda é um design fraco, introduzindo duplicação desnecessária e o que é chamado de anomalias de inserção de dados, o que significa que pode 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 realizando a edição de dados não perceber que existem vários registros? A tabela conteria dados diferentes para o mesmo indivíduo, sem nenhuma maneira clara de identificá-lo ou evitá-lo.
Quebrar esta tabela em duas tabelas, Professores e Cursos, cria o relacionamento adequado entre os dados e, portanto, ajuda a garantir a consistência e a precisão dos dados.
