Seções iMasters
Banco de Dados

Chave primária não é opcional

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.

Comente também

6 Comentários

edgardalanpoe

Também é interessante observar que grande parte dos desenvolvedores (não vou incluir DBAs) adoram criar campos auto incremento para utilizar como PK sem ao menos procurar por chaves candidatas.

Lucas Tiago Moraes

Muito bom artigo. Eu não uso chave primária quando uso Temporal e quando faço um relacionamento, 1 para 1, geralmente é algumas informações extras, então vejo necessidade de colocar, porque na tabela principal já tem a chave primária. E para evitar que os dados se repitam é usar unique.

    Wagner Crivelini

    aí q tá, lucas. se vc já teve q criar um índice único e teve q criar os campos como não nulos (pra evitar problema nos relacionamentos), já devia criar tb a chave primária. Como eu comentei no artigo, isso criaria um índice cluster na tabela e suas consultas seriam ainda mais rápidas.

      Lucas Tiago Moraes

      Vou seguir seu conselho. Mas em Temporal não teria motivo para usar, porque toda pesquisa baseia se na maior data.

Adriano Alves

Wagner ,chave primária é igual mulher é essencial e não pode faltar.

natalia

Que engraçado… Estava fazendo um trabalho e as tabelas estão com uns problemas, dai uns colegas fizeram as tabelas sem as chaves primarias, então não estavam dando certo. Então comecei a procurar algo sobre as chaves primárias e adorei este post, me ajudou bastante. Muito obrigada! bjs

Qual a sua opinião?