Em 23 de março de 2013 04:38, Danilo Silva <[email protected]> escreveu: > Pessoal, > > Tenho a seguinte estrutura de tabelas (eu resumi nos campos para facilitar): > > CREATE TABLE empresa ( > codempresa serial, > CONSTRAINT empresa_codempresa_pk PRIMARY KEY (codempresa) > ); > > CREATE TABLE filial ( > codempresa integer, > codfilial serial, > CONSTRAINT filial_codfilial_pk PRIMARY KEY (codempresa,codfilial), > CONSTRAINT filial_codempresa_fk FOREIGN KEY (codempresa) REFERENCES empresa > (codempresa) MATCH SIMPLE ON UPDATE CASCADE ON DELETE RESTRICT > ); > > CREATE TABLE usuario ( > codempresa integer, > codfilial integer, > coduser serial, > CONSTRAINT usuario_coduser_pk PRIMARY KEY (codempresa,codfilial,coduser), > CONSTRAINT usuario_codfilial_fk FOREIGN KEY (codempresa,codfilial) > REFERENCES filial (codempresa,codfilial) MATCH SIMPLE ON UPDATE CASCADE ON > DELETE RESTRICT > );
Veja, aqui /parece/ haver dois erros: um de conceito e outro de modelagem (ou modelação, como queira): 1) O usuário apesar de estar registrado em uma empresa pode atuar em outras empresas, certo? Será que o código da empresa e da filial fazem sentido nesta PK? Talvez deixar as colunas codempresa e codfilial como FK, *not null* e fora da PK faria mais sentido. 2) Se a empresa filial já está cadastrada na tabela EMPRESA não é necessário uma FK para a tabela FILIAL. E se uma matriz não possuir filiais, como faz? Eu removeria a coluna codfilial e colocaria uma FK diretamente de EMPRESA, assim o modelo ficaria mais coeso e simplista. > CREATE TABLE registro ( > codempresa integer, > codfilial integer, > codregistro integer, > coduserinc integer, > coduseralt integer, > CONSTRAINT registro_codregistro_pk PRIMARY KEY > (codempresa,codfilial,codregistro), > CONSTRAINT registro_codfilial_fk FOREIGN KEY (codempresa,codfilial) > REFERENCES filial (codempresa,codfilial) MATCH SIMPLE ON UPDATE CASCADE ON > DELETE RESTRICT > ); > > A minha dúvida está na tabela "registro", pois um usuário de uma filial pode > inserir um registro "em nome" de outra filial, logo como deveria ficar a > chave para o campo "coduserinc"? > A mesma coisa aconteceria para o campo "coduserdel", onde qualquer usuário > com permissão pode alterar o registro. 1) Se você continuar usando a estrutura como está, terá que criar 6 colunas adicionais como codempresainc, codfilialinc e codusuarioinc para inclusão e codempresaalt, codfilialalt e codusuarioalt para alteração com suas respecticas FKs. 2) Se você mudar a PK da tabela usuário para apenas codusuario, a tabela registro não precisará de alteração. 3) Seria mais coeso remover a coluna codfilial a exemplo da tabela USUARIO, criando uma FK diretamente da tabela EMPRESA. -- TIAGO J. ADAMI http://www.adamiworks.com @tiadami _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
