Restrição de banco de dados ou database constraint do tipo unique ou único ou exclusivo. Nós vamos utilizar essa constraint para que o valor específico que nós estamos atribuindo a uma coluna ou a um conjunto de colunas seja único, ou seja, nós não tenhamos registros duplicados. Vamos aos detalhes. Aqui nós temos a possibilidade de definir as chaves únicas ou chaves exclusivas e o NICKEYS ao nível de uma tabela e, como eu comentei, pode incluir uma ou mais colunas e esta construinte vai garantir que não existam valores duplicados. E nós podemos criar tantas quantas forem necessárias para atender um requisito de negócio de exclusividade de registro ou de não duplicidade. Vamos ver os exemplos de código. Em Oracle, vamos fazer a alteração da tabela departamento, adicionar a construinte, nome departamento local, o K. Então aqui estou nomeando de maneira explícita, estou aplicando o meu padrão de nomenclatura, o K de unique key, e estou dizendo que o nome do departamento e o local são únicos. Então, esta combinação desses dois valores não podem ser repetidos na tabela. Em MySQL, também em departamento, eu estou dizendo que o nome, o atributo nome daquele departamento é único. Então, nesta empresa que estou modelando aqui em MySQL, não existem departamentos exatamente com o mesmo nome. O nome é exclusivo. Este é o objetivo desta verificação, desta constraint. Este é o objetivo desta verificação, desta constraint. Em SQL Server, também estou fazendo a nomeação explícita da minha constraint, conforme a minha regra de nomenclatura, o k produto, produto id, e estou dizendo aqui que tanto o identificador deste produto, quanto o nome deste produto, são atributos únicos. E aqui eu estou dizendo que individualmente cada um desses atributos são únicos. Ao contrário do exemplo anterior que eu coloquei unique com dois elementos, o nome do departamento e o local. Então, naquele exemplo anterior, era a combinação de ambas as colunas que é exclusiva, que é única. Neste exemplo, ambas as colunas precisam ser únicas. Não vai existir produto com o mesmo nome e não vai existir produto com a mesma identificação. Em POSSIBILITY, também vamos perceber a possibilidade de ter a CONSTRUint nomeada, conforme o meu padrão de nomenclatura. E estou dizendo aqui que UNIQUE vai para o departamento nome, ou seja, nome de departamento nesta organização que usa pôsteres também não se repete. E também estou colocando de maneira não explícita com o nome, o e-mail como único. Não existirão departamentos com o mesmo e-mail. E com isso, vimos as características e exemplos da Constraint Unique ou Exclusiva ou Única, não duplicados os dados.