none
Uso Chave Composta RRS feed

  • Pergunta

  • 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



    quarta-feira, 24 de setembro de 2008 12:41

Respostas

  • 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

     

    quarta-feira, 24 de setembro de 2008 14:27

Todas as Respostas

  • 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

     

    quarta-feira, 24 de setembro de 2008 14:27
  • 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.

    quarta-feira, 24 de setembro de 2008 14:27
  • Gustavo,

     

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

     

    quarta-feira, 24 de setembro de 2008 20:18