Uso Chave Composta

Question

Bom dia,

Estou com uma duvida conceitual no uso de chave composta, tenho uma tabela Ex: "funcionarios_Roteiro_Producao"

com os seguintes campos:

id (auto numeração)
id_produto (chave estrangeira)
id_roteiro (chave estranegeira)


existe a seguinte regra os campos "id_produto" e "id_roteiro" não podem se repetir para outros registros, gostaria de saber se é errado eu definir este dois campos como chave primária e NÃO definir o campo "id" como chave ja que na verdade ele seria o indice da tabela, mas se eu eu definir os três então nao vou conseguir atender minha regra, e se eu definir somente o "id" então vou ter que validar isso em meu sistema e isso pode ocorrer em mais de um lugar ao inves de fazer essa validação no banco. Existe a possibilidade de definir o campo "id" como primaria key e essas duas chaves como unicas? Estou usando o SQL Server Express 2005.


Obrigado
Charbel Daia

Answer 1

Bom Dia,

 

Muito interessante sua dúvida (e muito comum nas aulas de modelagem). Na verdade existem pelo menos uns três "dilemas" por de trás dessa dúvida.

 

Durante o processo de modelagem, identificamos atributos ou combinação de atributos que definem cada ocorrência (registro) como único. Cada uma dessas combinações é conhecida como chave candidata. As chaves candidatas identificam a ocorrência como única, mas dentre o rol de chaves precisamos eleger uma delas como chave primária.

 

As seguintes combinações seriam possíveis:

• ID
• IDProduto + IDRoteiro
• ID + IDProduto + IDRoteiro

Ainda seguindo as regras de normalização, sabemos que devemos manter a chave ao mínimo possível e nesse caso a combinação ID + IDProduto + IDRoteiro deve ser descartada. Ficamos então com ID x IDProduto + IDRoteiro.

 

Essa é uma decisão muito comum. Devemos escolher entre uma chave artificial e uma chave natural. A chave artificial é controlada pelo banco e não diz respeito ao negócio enquanto a chave natural é introduzida pelo usuário e diz muito respeito ao negócio. Existem várias vantagens e desvantagens associadas à essa escolha. Chaves artificiais economizam espaço nos índices e nas colunas quando repassadas a FKs e chave naturais costumam economizar em JOINs (se repassamos a chave natural para outras tabelas, talvez não precisemos fazer um JOIN).

 

Em todo caso, o grande dilema entre chaves artificiais e chaves naturais é a volatilidade de suas regras de negócio. Se você escolhe uma chave natural e hoje a combinação dela é única, o que fazer com o seu modelo de dados se amanhã ela não for única ? Seria desastroso sair "costurando" o modelo.

 

Outro ponto é a questão da unicidade. Quando temos mais de uma chave candidata certamente só poderemos escolher uma chave primária. No seu caso, se optarmos pelo ID, ainda temos a obrigação de garantir a unicidade entre IDProduto e IDRoteiro. As boas práticas dizem que para todas as chaves candidatas que foram rejeitadas, você deve criar uma constraint Unique. No seu caso faríamos o seguinte:

 

Code Snippet

ALTER TABLE tbl ADD ID INT Identity(1,1) NOT NULL

ALTER TABLE tbl ADD Constraint PK_tbl PRIMARY KEY (ID)

ALTER TABLE tbl ADD Constraint UQProdutoRoteiro UNIQUE (IDProduto, IDRoteiro)

 

 

[ ]s,

 

Gustavo

 

Answer 2

Charbel,

 

Dizer que esta errado talvez seja algo muito implicito, mas podemos dizer que seria necessário analisar e entender melhor para poder definir melhor o que é certo ou errado, como também dizer qual seria melhor forma de normalizar e estruturar os seus relacionamentos.

Answer 3

Gustavo,

 

Isso era exatamente o que eu precisava, obrigado!!!