Chaves (índices) compostas

Para sermos mais concretos, digamos que você tem pessoas da tabela tblestudantes que fizeram cursos da tabela tblCursos e você identifica quem fez quais cursos na tabela tblEstudantesCursos.

Autor: Jeff Jeff Khoubesser (JeffK) - UtterAccess

Postei isto recentemente com relação a por que as chaves primárias compostas são ruins, e recebi alguns pedidos para que colocasse aqui. Eis a situação:

Você tem esta estrutura:

· Tabela tbl1 com Id1 como Chave Primária
· Tabela tbl2 com Id2 como Chave Primária
· Tabela tblJuncao que contém combinações válidas de registros de tbl1 e tbl2

Uma Chave Primária tentadora, mas incorreta para tblJuncao é uma chave composta consistindo dos dois campos chave estrangeiros Id1 e Id2. Entretanto, a Chave Primária, como sempre, deve ser um campo único, preferivelmente Auto Numeração. Vejamos porquê a chave primária composta não é uma boa idéia, por mais tentadora que seja:

Para sermos mais concretos, digamos que você tem pessoas da tabela tblestudantes que fizeram cursos da tabela tblCursos e você identifica quem fez quais cursos na tabela tblEstudantesCursos. Começamos assumindo que cada estudante só pode participar do curso uma única vez, assim sendo, a tabeloa tblEstudantesCursos poderia ter combos únicas com idEstudante e idCurso.

Problema 1
Você tem um formulário onde seleciona um estudante e seus cursos são mostrados em uma caixa de listagem. O usuário deve ter uma forma de remover um aluno de um curso se ocorrer algum erro.

Eis o código se a chave primária for composta:

Currentdb.Execute "DELETE FROM tblestudantesCursos WHERE idEstudante = " & me.cboEstudante & " AND idCurso = " & me.lstCursos

Currentdb.Execute "DELETE FROM tblEstudantesCursos WHERE idEstudanteCurso = " & me.lstCursos

Qual é melhor? Quando você deseja isolar um registro para ação, é mais rápido e com menos código ter tal registro indicado por um valor único para dizer à base de dados sobre qual registro você está falando. Dizer à base de dados qual registro você quer excluir não tem nada a ver com o que identifica unicamente o registro para você. No primeiro método, o seu código precisa saber algumas informações sobre o que está no registro, não apenas seu número (meu: Identificador único), e, se você decidir que deve permitir que um estudante frequente um curso diversas vezes este código provavelmente teria que incluir um novo campo na chave primária (tipo data do curso). O ponto é, uma chave primária de campo único não se preocupa com o que está contido no registro, ela é apenas indicada com um valor sem significado de modo que todo código VBA, relacionamentos e consultas podem se referir a ela sem saber o que contém.

Problema 2

E se você deseja selecionar um registro com chave primária composta em uma combo box?
João Cálculo
João Química
Jane Francês
Jane Biologia

Se a coluna vinculada não é única, você pode selecionar o segundo registro "Química" e ver a combo box mostrar "Cálculo" como valor para sua coluna 2. Isto acontece porque para a base de dados você selecionou "João", não importando qual curso do João que você escolheu, e mostra o primeiro "João". Experimente. Isso é chato! Novamente, a combo box não se importa se a combinação de João e Cálculo significa alguma coisa para você, ela só quer saber a que número de registro você está se referindo.

Problema 3

Agora temos a tabela tblProvas com idProva e desejamos criar a tabela tblEstudantesCursosNotas para mostrar as notas de cada estudante em cada prova de cada curso. Se tblEstudantesCursos não tiver uma chave simples, serão necessárias três peças de informação na sua tabela: idEstudante, idCurso e idProva. Se você usa uma chave primária simples, você precisa apenas de idEstudanteCurso e idProva - o estudante e o curso podem ser determinados por idEstudanteCurso. É neste ponto que se vê que a criação de uma chave primária simples vai deixar mais espaço para desenvolvimento de modelos maiores...

Sempre que vi um caso para o uso de chaves primárias multi-campos ele decorria do conceito que a chave primária deve significar alguma coisa, ou que ela deveria descrever o resto do registro. Não é o caso. Note que em todas as descrições de normalização de bases de dados se diz que os outros campos devem descrever a chave primária e não a chave primária descrever os outros campos. Ela deve ser usada apenas para indicar o registro físico na base de dados, sem compreensão ou preocupação com que está contido nop registro. Neste sentido nenhuma tabela é diferente de outras tabelas quando se trata da criação da chave primária.

Se você precisa identificar um registro para seus próprios propósitos ou pela integridade dos dados, crie um índice composto ou SSN ou seja o que for, mas usar isto como identificador do registro para o VB, relacionamentos, etc só vai fazer com que seja necessário escrever código extra e bastante trabalho para manutenção.

Não se deve confundir Chave Primária e Índice.

A Chave Primária é o identificador único do registro (sem significado algum para o usuário).

O Índice pode ser qualquer campo do registro, permitindo ou não duplicação, e serve, principalmente, para acelerar consultas.

No caso descrito na postagem anterior teríamos:

tblEstudantes
idEstudante -> Autonumeração -> Chave Primária
Matrícula -> Número gerado por uma função ou digitado -> Índice sem duplicação
NomeEstudante -> Texto -> Índice com duplicação
...

tblCursos
idCurso -> Autonumeração -> Chave primária
NomeCurso -> Texto
...

tblEstudanteCurso
idEstudanteCurso -> Autonumeração -> Chave Primária
idEstudante -> Número -> idEstudante da tblestudantes ---
idCurso -> Número -> idCurso da tblCursos----- Índice composto...