O mito da chave primária

Eu sei que vou comprar uma briga grande com esta frase, mas vamos lá: A Chave primária não é obrigatória na implementação de um modelo relacional.

Respire fundo, contenha sua ira e abra sua mente pois agora vamos ao detalhamento do polêmico tópico.

A primeira coisa que você precisa manter em mente: Eu não estou dizendo que a chave primária é irrelevante em uma modelagem de banco de dados relacional.

A chave primária é fundamental e tem por função não só ser o identificador único do registro na tabela mas também permitir a ligação com outras tabelas, onde esta se tornaria a chave estrangeira.

Não vou entrar aqui na discussão se devo utilizar uma chave natural ou uma chave forçada. particularmente, eu prefiro a chave forçada e opto por colocar a chave natural como sendo uma “Alternate Key”, e vou considerar assim para base deste artigo.

O objetivo deste artigo é demonstrar que nem todas as tabelas precisam de uma chave primária física.
Primeiro vamos na teoria.

Em seu artigo “A Relational Model of Data for Large Shared Data Banks” datado de Junho de 1970, o Doutor Edgar Frank Codd faz as seguintes afirmações:

(1) “Keys provide a user-oriented means (but not the only means) of expressing such crossreferences”
(2) “Normally, one domain (or combination of domains) of a given relation has values which uniquely identify each element (n-tuple) of that relation. Such a domain (or combination) is called a primary key”
(3) “We shall call a domain (or domain combmation) of relation R a foreign key if it is not the primary key of R but its elements are values of the primary key of some relation S (the possibility that S and R are identical is not excluded)”

Estas três frases definem basicamente o seguinte:

• Chave é um elemento que permite a inter-relação entre as informações.
• A chave primária é o elemento que permite a identificação do registro e pode ser um ou múltiplos campos.
• Um elemento único em uma relação é uma chave estrangeira se não for chave primária mas seus elementos são iguais a chave primaria de uma relação.

Para definir a aderência de um SGBD ao conceito de Banco de Dados Relacional, criou-se 12 regras. No nosso estudo a mais importante é a segunda:

(4) “Each and every data (atomic value) in a relational data base is guaranteed to be logically accessible by resorting to a combination of table name, primary key value and column name”

Neste caso a regra diz que todo registro no modelo relacional deve ter a garantia de ser logicamente acessado através de um dado único.

Vejamos um exemplo prático de um modelo de dados:

Uma determinada empresa de cartões que atua em nível global mantém ativos em torno de 3 bilhões de cartões que são transacionados em um número de 10 milhões de estabelecimentos, fazendo cada cartão faz em média 15 transações por mês.

O registro de transações é meramente informacional e não possui nenhuma transação dependente mas, por questões jurídicas, os detalhes de cada transação precisam estar disponíveis no sistema principal por 48 meses.
O modelo de dados elaborado para controle geral tem as seguintes entidades:

Cartão –> 30 Bytes por Cartão –> 84 GB Total
CartaoID BigInt Not Null –> 8 Bytes
CartaoNr Char(19) Not Null –> 19 Bytes
MesValid TinyInt Not Null –> 1 Byte
AnoValid TinyInt Not Null –> 1 Byte
Sicuacao Char(1) Not Null –> 1 Byte

Conveniados –> 30 Bytes por Conveniado –> 0,24 GB Total
ConveniadoID Int Not Null –> 4 Bytes
ConveniadoNm Varchar(50) Not Null –> 26 Bytes (Média)

Transações –> 45 Bytes por transação –> 1.886 GB Total por mês –> 90.528 GB total geral ou 2,160 trilhão de registros na tabela
CartaoID BigInt Not Null –> 8 Bytes
ConveniadoID Int Not Null –> 4 Bytes
DataTransac DateTimeOffSet Not Null –> 10 Bytes – Preciso do fuso horário
VlrTransac Money Not Null –> 8 Bytes
NumRecibo Char(15) Not Null –> 15 Bytes

Pelo consenso que existe, toda tabela deve possuir uma chave primária física implementada, o que forçaria a criação, na tabela de transação do seguinte campo:

TransacaoID BigInt Not Null –> 8 Bytes

De acordo com as características teóricas citadas acima, temos como Chaves estrangeiras os campos CartãoID e ConveniadoID e não temos uma chave primária (a menos que você queira criar o campo TransacaoID), Certo?

Porém, a teoria nos diz que:

(1) Um domínio que tem um valor que identifica um único elemento é a chave primária.
(4) Cada dado atômico (registro que não se repete) pode ser logicamente acessado.

O que temos na tabela transação é uma chave primária natural composta, que garante o acesso a um registro único. São eles:

CartãoID –> Identifica o Cartão que fez a transação
Conveniado ID –> Identifica o local onde a transação ocorreu
DataTransac –> Identifica a Hora, Minuto, segundo e fuso horário onde a transação ocorreu

A menos que haja uma fraude ou um erro, não vai acontecer duas transações onde estas três informações se repetem.
Portanto, apesar de não existir um campo que defina uma chave primária física ou uma constraint que a implemente, a chave primária conceitual está presente na tabela, o que atende aos requisitos do modelo relacional. No caso de a chave conceitual não estar presente, seria interessante rever o seu modelo pois ele apresenta uma inconsistência quanto ao modelo relacional.

No caso da chave primária física, fica a critério da administração do banco de dados criá-la ou não como um campo ou uma constraint da tabela. A criação física da chave tem impactos técnicos e – principalmente – econômicos que precisam ser considerados.

Como uma transação não vai gerar informações derivadas, a criação de um campo específico para ser chave primária não agregará benefício, somente gerará problemas para o modelo, por conta principalmente de espaço adicional.

Nota Importante

Observe que a característica de “não haver transações derivadas” é um requisito do sistema. O sistema poderia contemplar, por exemplo, um processo de auditoria, onde cada transação poderia ser auditada, conforme modelo abaixo:

Auditoria
TransacaoID BigInt Not Null –> 8 Bytes
AuditorID SmallInt Not Null –> 2 Bytes
DataAudit Date Not Null –> 4 Bytes

Nesse caso, a transação possui informações derivadas, o que torna necessário a criação explicita de uma chave primária e a auditoria ficaria como “Fim de Linha”, sem a necessidade de chave primária física.

Considerações Finais

A chave Primária é uma característica fundamental do modelo relacional e é o elemento de relação entre as informações.

Toda informação deve possuir uma chave primária, mas nem toda tabela física terá a necessidade de ter esta constraint física implementada.

A definição da implementação física é uma questão de economicidade e/ou uma característica técnica que deve encontrar respaldo (econômico ou técnico) para sua criação.

No caso de economicidade, a adição de um campo exclusivo para isso ou de utilizar as chaves naturais representa espaço adicional que não se justificará por esta não ser responsável por nenhuma relação com outra tabela. Uma justificativa poderia ser a possibilidade de expansão da informação (como no exemplo da auditoria).

No caso de necessidade técnica, uma justificativa poderia ser a utilização do “Entity Framework“, que exige uma chave primária na tabela para que não se perca nas transações. Outro bom exemplo seria o fato se ser uma tabela com muito acesso de pesquisa, o que obrigaria um índice, o que, neste caso, seria mais interessante criar a chave primária composta com os três campos para finalidade de acesso.

As tabelas “Fim de Linha” são as únicas onde se justificaria a não utilização da constraint física de chave primária.

Portanto, a afirmação de que toda tabela deverá ter uma chave primária somente pode ser considerado verdade no modelo lógico, pois não há a obrigatoriedade de implementar uma chave primária no modelo físico caso a tabela seja “fim de linha”.

Em suma, se você encontrar uma tabela física sem a chave primária implementada, analise antes as possibilidades e as razões pela qual ela existe, pois isso não é um pecado mortal na religião da modelagem de dados.