Restrição de banco de dados, ou database constraint, do tipo chave primária, ou primary key. Nesta restrição, que talvez seja uma das mais conhecidas, porque quando a gente se aprofundar em modelagem de dados, nós veremos que precisamos modelar um identificador único para o registro que estamos inserindo na nossa tabela, nós vamos perceber que a ideia é justamente ter esse identificador único deste registro e que esse identificador, além de ser único, também é não nulo, ou seja, ele tem que ser preenchido. Então, vamos aos detalhes. ser preenchido. Então, vamos aos detalhes. Primary Key, ou chave primária, será o nosso identificador do registro que estamos inserindo na tabela. Então, conforme eu comentei inicialmente, esse registro precisa ser único e tem que ser obrigatoriamente preenchido, ou seja, é não nulo. A chave primária pode ser simples, ou seja, a gente atribui apenas a uma única coluna ou pode ser uma chave primária composta, quando a gente coloca mais de uma coluna para ter aquele identificador único e não nulo do nosso registro. Então, chave simples, uma única coluna, chave composta, múltiplas colunas, identificando de forma única, de forma obrigatoriamente preenchida, ou seja, não nula, aquele registro que nós temos na tabela. Vamos aos exemplos de código. Vamos aos exemplos de código. Em Oracle, estamos criando a nossa tabela empregado e nós temos aqui empregado ID, então estou seguindo a nomenclatura da organização na qual eu trabalho, ID de identificador daquele empregado, daquela pessoa, e é um número. identificador daquele empregado, daquela pessoa, e é um número. Logo mais abaixo, nós estamos vendo a expressão, o keyword, primary key, que define que o empregado ID é a chave primária, ou seja, o identificador único desta tabela que estamos criando, criando que representa o objeto de uma pessoa empregada na nossa organização em mais ficou temos aqui um exemplo curto de uma criação de tabela de departamentos da nossa empresa aonde seguimos uma regra basicamente similar a que vimos aqui no oráculo que ter a declaração do departamento a edição identificador deste departamento é um inteiro e ao final da declaração do departamento id, então o identificador deste departamento é um inteiro, e ao final da declaração nós temos a chave, o keyword, primary key, chave primária, dizendo que departamento id é a chave primária, ou seja, identificador único desta tabela de departamento. tabela de departamento. Em SQL Server, aqui nós temos um alter table, ou seja, o comando de modificação de uma tabela, aonde nós estamos adicionando a constraint e inclusive estamos nomeando explicitamente. Então, aqui eu relembro o conceito de que podemos nomear de forma explícita. Aqui estamos nomeando como PK produto. Este é o meu padrão de organização onde eu trabalho. E estou dizendo que, como primary key, produto ID é o identificador único dessa tabela de produto. Quando a gente não nomear de maneira explícita, o banco de dados vai colocar um nome artificial, um nome técnico para esta construinte. Sempre que possível, pense na pessoa que vai herdar este código e sugiro sempre nomenclaturas intuitivas dentro dos padrões da sua organização e, claro, seu código sempre muito bem documentado. Postgres, criação de tabela produto, então nós temos a declaração dos atributos, produto id, inteiro, not null, nome de produto, caractere, varchar, not null, e aqui também temos a keyword constraint para a nossa chave primária, estamos nomeando como pk produto, pk dentro da minha nomenclatura de organização, Primary Key, e a declaração logo em seguida, Primary Key, abre parênteses, produto ID como identificador desta tabela. E com isso definimos chaves primárias nos quatro bancos relacionais mais populares, de acordo com o DB Engines.