Bom dia Chiappa. Acho que não expliquei direito. 1º) Sim, na tabela cliente (pai) a pk é o CNPJ e na tabela fabrica (filha) vai ter um campo CNPJ com FK na tabela cliente. 2º) A PK da tabela fabrica seria composta por CNPJ + Sequencia 3º) O índice unique da tabela fabrica sera composto de CNPJ + Fabrica + Local entrega + Doca + Tipo de programa. Com esse índice acho que simulo uma chave primaria composta pelos mesmos campos
Espero que tenha ficado mais claro. Emerson Em seg, 1 de jul de 2019 às 17:11, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Blz ? Então, primeira coisa se na tabela-pai a PK é CNPJ, para que a nova > tabela seja considerada FILHA da tabela-pai ela TEM que ter essa mesma > coluna CNPJ criada como FK e apontando pra PK da tabela pai, okdoc ?? A PK > da tabela-filha não importa pra essa funcionalidade... > Muito bem : isso dito,antes de discutirmos questões de acesso , índices, > e etc, plz ENTENDA que vc tem duas situações COMPLETAMENTE DIFERENTES aí!! > A contraint PK composta indica que qquer um dos valores (ou uma combinação > de todos exceto um) pode SIM se repetir nos outros registros, o que não > pode é duplicar TODOS da chave.... No seu exemplo, se vc tiver a PK > composta criada como CNPJ + FABRICA + LOCAL ENTREGA + DOCA + TIPO PROGRAMA, > isso quer dizer (por exemplo) que UM local de entrega pode ter N docas pra > mesma fabrica e mesmo CNPJ, tipo : > > |CNPJ |Fabrica|Local entrega|Doca|Tipo programa| > |53.358.644/0001-12|FAB01 |BRAS |D10 | TIPO1 | > |53.358.644/0001-12|FAB01 |VILA CARRAO |D10 | TIPO1 | > > ==> OU SEJA, os dois registros acima tão válidos porque NÂO FORAM TODOS OS > CAMPOS DA PK COMPOSTA que se REPETIRAM.... > > Agora, se vc criar uma constraint UNIQUE separada pra cada coluna, isso > indica que NA TABELA TODA, independente de qquer coisa, a coluna UNIQUE só > poderá ter um valor.... Imagine que a PK foi criada como CNPJ + SEQUENCIA > como vc propôs, e que as colunas FABRICA , LOCAL ENTREGA , DOCA e TIPO > PROGRAMA cada uma tem a sua UNIQUE KEY própria : suponha que eu tenho a > mesma situação acima, e inseri pro CNPJ 53.358.644/0001-12 inseri o > registro : > > |CNPJ |Fabrica|Local entrega|Doca|Tipo programa| > |53.358.644/0001-12|FAB01 |BRAS |D10 | TIPO1 | > > ==> Se eu tentar gravar (prum outro CNPJ ou pro mesmo com outra sequência, > tantofaz) um outro registro para (digamos) LOCAL DE ENTREGA = BRAS kaput, a > constraint UNIQUE do LOCAL DE ENTREGA ** não vai me deixar ** fazer isso... > Com as constraints UNIQUE separadas, isso significa que NENHUM OUTRO CNPJ > poderia ter a fábrica FAB01, ou o local de entrega BRAS ou a doca D10 !!! É > isso que significa uma constraint UNIQUE particular pra cada coluna... Faz > sentido isso na sua modelagem ?? > Ou seja, essas duas construções ** ABSOLUTAMENTE NÃO SÃO ** duas maneiras > de fazer a mesma coisa, como vc parece dar a entender : na verdade são > coisas COMPLETAMENTE DIFERENTES, são Validações feitas de maneira > completamente DIFERENTE, okdoc ??? > > []s > > Chiappa > >
