Banco de Dados

24 abr, 2013

Chave primária não é opcional

Publicidade

Independente do cargo que você ocupa – DBA, desenvolvedor, gerente de projeto ou qualquer outro que você queira citar -, provavelmente já viu tabelas que não tinham chaves primárias. E é uma pena que isso tenha ocorrido, porque elas são um componente essencial no modelo de banco de dados.

Existem várias razões para que você implemente chaves primárias nas suas tabelas. A primeira delas é que o modelo relacional exige que cada registro da tabela seja distinto de todos os outros.  E quem garante isso é a chave primária da tabela, ou ao menos deveria ser através delas que esta exigência seria garantida.

Estudando um pouco mais a fundo este assunto, vale lembrar que o modelo relacional não menciona o uso de chaves primárias. Ele especifica que cada tabela deve conter o que se costuma chamar de superchaves.

Porém o modelo relacional não exige que esta superchave seja única na tabela. Isto  quer dizer que pode haver mais do que um campo ou conjunto de campos na tabela que podem identificar o registro. Todas estas superchaves são chamadas de chaves candidatas, mas apenas uma delas será eleita a chave primária da tabela. Em termos de implementação do modelo, isso quer dizer que a tabela pode ter vários índices do tipo único, mas apenas uma chave primária.

Muitas vezes, a superchave da tabela é formada por diversos campos e, neste caso, são chamadas chaves compostas. Nem sempre é uma boa ideia trabalhar com este tipo de chave, porque eles dificultam diversas operações, entre elas a junção de tabelas. Por isso que tantos arquitetos gostam de criar campos do tipo IDENTITY e usá-los como chaves primárias (que então também podem ser chamadas de chaves substitutas).

Eu estou descrevendo toda esta nomenclatura para mostrar a importância das superchaves para o modelo relacional e justificar meu ponto de vista: elas devem ser formalmente implementadas como chaves primárias.

A segunda razão para se criar chaves primárias nas suas tabelas é que só podemos formalizar a relação entre duas tabelas quando a tabela mãe tem uma chave primária. Só então poderemos definir uma chave estrangeira na tabela filha e assim temos uma relação formal entre ambas. Este tipo de implementação é fundamental para garantir qualidade de dados.

Mas existe uma terceira razão menos comentada, mas de fundamental importância em alguns SGBDs: quando se cria uma chave primária, por padrão está sendo criado também um índice clustered, isso é, um índice que organiza a sequência de gravação dos registros dentro dos arquivos físicos. Esta organização é de fundamental importância para a boa performance, porque facilita muito a localização física dos registros.

Sendo assim, se sua tabela não tem nenhuma chave primária e nem um índice clustered definidos, os registros serão gravados em disco sequencialmente, na mesma ordem em que são inseridos. Mas raramente esta ordem cronológica é a melhor forma de pesquisa em tabelas grandes.

É muito mais eficiente organizar os registros com base na sua superchave, porque é assim que vamos procurar um registro nas nossas consultas. Imagine, por exemplo, o caso da  junção de duas tabelas que receberam inserções de registros de forma independente. Para fazer a junção delas, você obrigatoriamente vai precisar da superchave de uma delas e a chave estrangeira da outra tabela. E é evidente que pesquisar registros em ordem cronológica não vai ajudar a garantir performance nesta consulta.

Portanto, é importante lembrar que, em muitos SGBDs, a definição das chaves primárias tem um impacto monstruoso na performance do sistema. SQL SERVER e ORACLE funcionam de modo parecido com o que eu acabei de descrever. O DB2, por sua vez, trata chaves primárias e índices clustered de forma independente e ambos precisam ser formalmente definidos.

Seja pela razão que for, por favor, não imagine que sistemas transacionais sejam capazes de funcionar adequadamente sem uma implementação formal dos objetos e conceitos que lhe são importantes. Esta formalização ajuda muito na boa performance e boa qualidade dos seus dados. E, quando falamos de bancos de dados relacionais, a chave primária é o conceito mais importante desta lista.