2.6 Identificador (chave primária e estrangeira)

Toda entidade deve possuir um atributo com valores únicos, ou seja, um identificador que diferencia uma ocorrência das demais dentro da entidade. Isso é necessário pois, ao efetuar alguma ação naquela ocorrência, o SGBD deve ser capaz de poder identificá-la como única. O termo técnico utilizado para se referir a esse identificador se chama chave primária. Por exemplo:

Figura 17 - Identificador

Visualmente conseguimos identificar que na Figura 17 o identificador da entidade Curso é o atributo Código; já na entidade Aluno o identificador é o atributo CPF. Esses dois identificadores representam valores que jamais irão se repetir; eles têm a missão de tornar cada ocorrência única. Existem casos nos quais um único identificador não é capaz de tornar as ocorrências únicas; nesses casos é necessário utilizar identificadores compostos:

Figura 18 - Identificador composto

Na Figura 18, para a entidade Curso, temos dois identificadores (Código e Título), ou seja, essa entidade possui identificadores compostos. Separadamente esses atributos não serão capazes de garantir a unicidade das ocorrências, porém juntos conseguirão cumprir muito bem essa missão.

Quando a chave primária for composta por um único identificador ela será considerada uma chave simples; já quando existirem dois ou mais identificadores formando uma chave primária ela será considerada uma chave composta. Toda chave primária é obrigatória, ou seja, seu valor não pode ser nulo (vazio).

Existe ainda um conceito muito importante conhecido como chave estrangeira, que nada mais é do que uma chave primária em outra entidade com a qual a entidade atual mantém relacionamento. Sua utilização tem como resultado inúmeros benefícios; iremos utilizar a Figura 18 como objeto de nossa análise e elemento facilitador para transmitir esse conceito e, sendo assim, vamos aos benefícios gerados pela utilização de chave estrangeira:

• Consistência dos dados. Por exemplo: se você tentar cadastrar um aluno no curso X e o curso não existir, o banco irá retornar uma mensagem de erro.
• Se tentar excluir um curso que está relacionado a algum aluno, o banco irá retornar uma mensagem de erro.
• Ao tentar alterar uma chave primária, ocorrerá erro caso exista algum relacionamento ativo; isso garante a integridade e consistência do relacionamento.

Ao escolher uma chave estrangeira (chave de relacionamento), escolha sempre a chave mais simples. No exemplo da Figura 18, seria o atributo Código. Isso garante uma maior performance.

Assim como prometido em tópicos anteriores, irei realizar uma demonstração de relacionamento utilizando somente duas tabelas em vez de três:

Figura 19 - Relacionamento entre duas entidades

Na Figura 19, a entidade aluno mantém um relacionamento com a entidade curso por meio da coluna cd_curso.

Em um cenário em que a cardinalidade fosse “0,1” não existiria problema em utilizar a proposta sugerida na Figura 19, porém, a partir do momento que podemos ter múltiplos relacionamentos para uma mesma ocorrência, a ideia proposta na imagem acima passa a ser desencorajada.

Uma das grandes vantagens da utilização do banco de dados é extinguir a duplicidade de registros. Se na imagem acima tivermos um relacionamento do tipo “1,n”, iremos sofrer com um sério problema de duplicidade de registros. Pense bem: sempre que um aluno tiver interesse em fazer dois ou mais cursos seremos forçados a duplicar o seu nome para poder promover um novo relacionamento, sem falar, é claro, que o nome pode ser escrito ou abreviado de outra forma, resultando em mais um problema que seria justamente a inconsistência das informações.

Mas calma aí! Esse tipo de relacionamento também pode ser muito útil quanto utilizado da forma correta e em cenários propícios. No exemplo abaixo ele se encaixa perfeitamente:

Figura 20 - Relacionamento entre duas entidades

Na regra de negócio acima, cada ocorrência da entidade usuario irá se relacionar obrigatoriamente com somente uma ocorrência da entidade perfil; sendo assim a proposta apresentada na Figura 20 atende a todas as expectativas para o cenário apresentado na Figura 20.

Tenha em mente que, quanto menos entidades envolvidas em “um” relacionamento, menor será o custo computacional para realizar as interações necessárias para lidar com os dados; sendo assim, a estruturação e elaboração correta do banco pode ser um diferencial valioso. Sempre que possível, evite criar entidades de relacionamento desnecessárias. Em geral elas são inúteis quando a cardinalidade máxima do relacionamento é 1.

Lembre-se do que foi dito anteriormente: tudo depende da sua regra de negócio. Em geral, uma entidade de relacionamento é utilizada quando um mesmo registro precisa se relacionar com N ocorrências de outra entidade. Veja este exemplo:

Figura 21 - Relacionamento via entidade de relacionamento

A Figura 21 nos permite ter um melhor entendimento do que foi explicado: veja que o aluno Fábio se relaciona com duas ocorrências diferentes que estão presentes na entidade curso. Como os relacionamentos não estão mais concentrados na entidade aluno, temos uma maior flexibilidade para relacionar quantas ocorrências forem necessárias sem precisar duplicar registros.

No exemplo acima os atributos codigo das entidades curso e aluno, bem como cd_curso e cd_aluno da entidade turma são chaves primárias. Como sabemos disso? O relacionamento se dá por meio desses atributos.

Quando temos chaves compostas em uma entidade, devemos eleger uma chave para ser utilizada como chave estrangeira (chave de relacionamento). Uma boa prática é utilizar a chave mais simples possível como objeto de relacionamento.

Atenção: os dois atributos da entidade turma apontam para chaves estrangeiras, logo é normal que esses dois atributos sejam configurados como chaves primárias compostas, ou seja, esses dois atributos juntos irão garantir a unicidade das ocorrências dentro de sua entidade.