Os nomes dos diferentes tipos de constraints devem obedecer às regras seguintes:

1. Todos os nomes de constraints devem ser compostos por um prefixo e um identificador único: 

• O prefixo é constituído por um par de letras que permitem identificar o tipo de constraint:
  PK (chave primária), CK (check constraint), UK (chave única) e FK (chave estrangeira).
• O identificador único é composto por uma ou mais partes extraídas dos nomes dos objetos envolvidos, possuindo uma regra de formação definida para cada tipo de constraint (conforme itens a seguir 2 a 6, nesta página desta subseção Nomes de constraints).
• Obs.: Para a composição desse identificador em modelos multidimensionais, devem ser descartados os prefixos que identificam o tipo de tabela, tais como: DIM, STG, DW e EXT. Por outro lado, no caso de tabelas fato, a palavra FATO deve ser mantida e também deve ser considerada para fins de abreviação (conforme orientado na seção Regras de abreviatura de nomes de tabelas para composição de nomes de objetos).

2. Quando se tratar de chave primária, o nome da constraint deve ser precedido pelo prefixo PK, seguido do nome da tabela: 

Exemplo:

3. Quando se tratar de check constraint, o nome deve ser precedido pelo prefixo CK, seguido da abreviação do nome da tabela (conforme orientado na seção Regras de abreviatura de nomes de tabelas para composição de nomes de objetos) e do nome da coluna que será checada:

Exemplo:

4. Quando a check constraint referir-se a múltiplas colunas, deve ser utilizado na composição o nome da coluna mais relevante. 

5. Quando se tratar de unique key, o nome deve ser precedido pelo prefixo UK, seguido de abreviação do nome da tabela (conforme orientado na seção Regras de abreviatura de nomes de tabelas para composição de nomes de objetos) e de um complemento, que deve, preferencialmente, ser o nome da coluna da UK ou da primeira das colunas que constituem a UK:

Exemplo:

6. Para chaves estrangeiras (FK), cabem as seguintes orientações:

• Situação considerada normal: quando a FK for passada uma única vez para uma tabela, seu nome deve ser precedido do prefixo FK, seguido pelo nome da tabela de relacionamento (origem da FK ou tabela pai) e pela abreviatura (conforme orientado na seção Regras de abreviatura de nomes de tabelas para composição de nomes de objetos) do nome da tabela na qual a constraint está sendo criada (destino da FK ou tabela filha):

Exemplo:

• Exceção: caso a FK seja passada mais de uma vez para a mesma tabela, seu nome deve ser formado pelo prefixo FK, seguido por:
  • (1) nome abreviado (conforme orientado na seção Regras de abreviatura de nomes de tabelas para composição de nomes de objetos) da tabela de relacionamento (origem da FK ou tabela pai);
  • (2) uma parte significativa e não-abreviada do nome do atributo relacionado;
  • (3) nome abreviado (conforme orientado na seção Regras de abreviatura de nomes de tabelas para composição de nomes de objetos) da tabela onde a constraint está sendo criada (destino da FK ou tabela filha):

Exemplos:

Obs.: este exemplo retrata o relacionamento entre as tabelas TIPO_NIVEL_CONHECIMENTO e IDIOMA_SERVIDOR. A primeira linha do exemplo retrata o relacionamento com campo escrita, a segunda com o campo leitura e a terceira com o campo conversacao.

7. No caso de definições de valor default, o nome deve ser precedido pelo prefixo VD, seguido do próprio valor. Neste caso, a aplicação da regra restringe-se à sua definição no próprio modelo de dados, já que o nome não é replicado em banco.

Exemplos: