Em Qua, 2015-02-04 às 13:39 -0200, Matheus de Oliveira escreveu: > > 2015-02-04 12:50 GMT-02:00 Matheus Saraiva > <[email protected]>: > Um campo 'x' da tabela 'A' pode se relacionar tanto com o > campo 'x' da > tabela 'B' quanto com o campo 'x' da tabela 'C'. > Sei que dá para criar duas chaves separadas na tabela 'A' uma > que > relaciona A(x)=>B(x) e outra que relaciona A(x)=>C(x). Mas na > hora de > incluir, alterar? Isso daria certo? Tipo digamos que na tabela > 'C' > exista dados gravados mas a tabela 'B' esteja vazia. Daria > erro na hora > de inserir dados em 'A'? Ou seja, o erro que informa que o > valor > informado em A(x) não existe em B(x)? > > > Não, não dá certo. > > O que você tem que fazer é, na tabela A criar dois campos, vamos dizer > B_x e C_x. Daí quando o relacionamento for de A=>B o campo B_x recebe > o valor enquanto o C_x fica com valor NULL (quando um campo é NULL a > FK não é verificada), e vice-versa para A=>C. > > > Caso você precise forçar que apenas ou um outro esteja no > relacionamento, você pode usar uma CHECK CONSTRAINT. Por exemplo, para > forçar *exatamente* um ter relacionamento você pode usar: CHECK(B_x IS > NULL <> C_x IS NULL). > > > E se esse além de uma chave estrangeira o campo em 'A' também precisar ser uma chave primária? Uma tabela não pode ter duas chaves primárias, além do que uma chave primária não pode ser nula. Eu pensei em fazer dessa forma para não ter que criar duas tabelas individuais uma que se relacionaria com 'B' e outra que se relacionaria com 'C', pois a única coisa que elas teriam de diferente seria apenas o nome. Os campos (quantidade, nome, tipos, etc.) seriam os mesmos, até os dados que serão guardados seriam iguais. Então minha ideia era algo parecido com orientação a objetos. 'A' seria como um objeto que poderia se relacionar tanto com 'B' como com 'C'. O problema é a direção do relacionamento, é 'A' quem deve apontar para 'B' ou 'C' e não o contrário. A modelagem utilizada é análoga à uma nota fiscal e os itens que compõe a nota. 'B' seria a nota propriamente dita, com os dados do cabeçalho da nota, já 'A' seria a tabela que conteria os itens da nota. Um produto (registro) em 'A' apontaria para a nota (registro) em 'B' a qual pertence. Agora imagine que a tabela 'C' seria um orçamento. Seria ideal usar a mesma tabela 'A' pois os itens que estão presentes em uma nota podem ser utilizados também em um orçamento. Mas pelo visto acho que não tem como, terei que criar tabelas separadas.
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
