REGISTROS DUPLICADOS
boa tarde
tenho uma tabela access [Ô]tbldados[Ô] com dados cliente, endereco, cpf,contrato onde existem varios registros do mesmo cliente só que com contratos diferentes
gostaria de juntar em unico registro deste cliente, no campo contrato, todos os contratos, ficando sómente um registro
agradeço
luz
tenho uma tabela access [Ô]tbldados[Ô] com dados cliente, endereco, cpf,contrato onde existem varios registros do mesmo cliente só que com contratos diferentes
gostaria de juntar em unico registro deste cliente, no campo contrato, todos os contratos, ficando sómente um registro
agradeço
luz
Posta a estrutura do seu banco de dados.
estou enviando bd exemplo
O correto seria criar duas tabelas:
Tabela Clientes com os campos CodCliente, NomeCliente, CpfCnpj, Cidade, Uf com PrimaryKey CodCliente
Tabela Contratos com os campos CodCliente, NumeroContrato com PrimaryKey CodCliente
Assim suas informações estarão bem estruturadas e sem repetição desnecessária.
Tabela Clientes com os campos CodCliente, NomeCliente, CpfCnpj, Cidade, Uf com PrimaryKey CodCliente
Tabela Contratos com os campos CodCliente, NumeroContrato com PrimaryKey CodCliente
Assim suas informações estarão bem estruturadas e sem repetição desnecessária.
Citação::
O correto seria criar duas tabelas:
Tabela Clientes com os campos CodCliente, NomeCliente, CpfCnpj, Cidade, Uf com PrimaryKey CodCliente
Tabela Contratos com os campos CodCliente, NumeroContrato com PrimaryKey CodCliente
Assim suas informações estarão bem estruturadas e sem repetição desnecessária.
Só corrigindo, na tabela Contratos a chave primária teria que ser o NumeroContrato, o CodCliente seria uma chave estrangeira, senão só permitiria um contrato por cliente do mesmo jeito, e isso levando em conta que nunca vão existir dois contratos com o mesmo número, ou dois clientes com o mesmo contrato.
Eu pessoalmente prefiro sempre adicionar um outro campo para ser a chave primária como auto-numeração, campo que só uso internamente e nunca mostro no programa, facilita no caso de precisar alterar o código de algum registro já que assim não vai interferir com os relacionamentos.
Concordo do ponto de vista da normalizacao dos dados o correto e ter uma tabela clientes e outra tabelas contrato e utilozar join para relacionar os dados bas consultas.
Há alguns problemas, não apenas a duplicação dos registros. Em têrmos de normatização dos dados:
1.- Cada tabela deve sempre possuir um campo de chave primária (identificação, primary key) unÃvoco, preferenciamente autonumeração (Identity, autonum, trigger etc). Isto deve ser feito para permitir ao mecanismo de dados identificar o registro correto no momento de uma alteração ou de uma exclusão. Observe que, usando a ADO antiga, os Recordsets mantém a coleção de registros incluindo sua posição de linha, e portanto, recordsets, ainda que com algumas conseqüências, conseguem manipular tabelas sem PrimaryKey, mas os Clients mais novos não são capazes de fazer isso.
2. - O campo CPF pode ser alterado para que não permita duplicação, basta criar nele um Ãndice exclusivo.
3. - O campo CONTRATO deverá ser removido da tabela [ô]tblsaldo[ô] e estar em uma tabela própria.
4. - Como um cliente pode ter mais de um contrato, mas creio que cada contrato pode ter apenas um cliente, a nova tabela deve possuir um campo de identidade (primary key), um campo preferencialmente numérico que conterá o valor do campo de identidade do registro equivalente na tabela [ô]tblsaldo[ô] e o campo CONTRATO, com as mesmas caracterÃsticas atuais.
Mas ainda assim, você pode obter uma lista com apenas um registro por cliente, e a quantidade de contratos que os mesmos possuem, usando uma consulta como:
Em tempo:
CHMATOS, não estou querendo ser chato com você, pois centenas de professores, engenheiros, programadores e analistas utilizam o têrmo [Ô]normalização[Ô] com freqüência, seja graças á um sistema educacional que deixa algo á desejar, seja por interpretação [Ô]apressada[Ô] dos tradutores de livros técnicos. E não estou pedindo que leve em conta o que vou expôr, pois nada tem á ver sequer com programação. é mais algo como um desabafo.
O fato é que o têrmo correto, no caso intaurado por este tópico, é [Ô]normatização[Ô], ou seja, o ato de estabelecer normas ou regras onde as informações possam ser armazenadas sem pêrda da integridade objetiva, ou seja, mantendo-as prontas para o fim á que se dentinam, que são as consultas.
Já o têrmo [Ô]normalização[Ô] seria o mesmo que dizer [Ô]o ato de tornar os registros normais[Ô]. Ainda que a palavra [Ô]normal[Ô] seja oriunda de [Ô]norma[Ô], ela é aplicável á médias, ou seja, quando uma maioria se comporta de uma determinada forma, aquele que se comporta diferentemente está fora da normalidade. Oras, não existe [Ô]registro anormal[Ô], uma vez que quem rege o comportamento dos registros é a estrutura tabular. Assim, o que existe é estrutura mal-dimensionada, e dessa forma, como um registro não pode por si mesmo ser considerado [Ô]normal[Ô] ou [Ô]anormal[Ô], pois a média é determinada pela estrutura, o uso deste têrmo é um equÃvoco (ou desastre) lingüÃstico que a imensa maioria dos tradutores, professores e mestres deveriam perceber e não cometer.
Novamente, desculpe aproveitar sua resposta para este desabafo.
1.- Cada tabela deve sempre possuir um campo de chave primária (identificação, primary key) unÃvoco, preferenciamente autonumeração (Identity, autonum, trigger etc). Isto deve ser feito para permitir ao mecanismo de dados identificar o registro correto no momento de uma alteração ou de uma exclusão. Observe que, usando a ADO antiga, os Recordsets mantém a coleção de registros incluindo sua posição de linha, e portanto, recordsets, ainda que com algumas conseqüências, conseguem manipular tabelas sem PrimaryKey, mas os Clients mais novos não são capazes de fazer isso.
2. - O campo CPF pode ser alterado para que não permita duplicação, basta criar nele um Ãndice exclusivo.
3. - O campo CONTRATO deverá ser removido da tabela [ô]tblsaldo[ô] e estar em uma tabela própria.
4. - Como um cliente pode ter mais de um contrato, mas creio que cada contrato pode ter apenas um cliente, a nova tabela deve possuir um campo de identidade (primary key), um campo preferencialmente numérico que conterá o valor do campo de identidade do registro equivalente na tabela [ô]tblsaldo[ô] e o campo CONTRATO, com as mesmas caracterÃsticas atuais.
Mas ainda assim, você pode obter uma lista com apenas um registro por cliente, e a quantidade de contratos que os mesmos possuem, usando uma consulta como:
SELECT Max(tblsaldo.CLIENTE) AS Cliente, tblsaldo.CPF AS CPF, Max(tblsaldo.CIDADE) AS Cidade, Max(tblsaldo.UF) AS UF, Count(tblsaldo.CONTRATO) AS Contratos FROM tblsaldo GROUP BY tblsaldo.CPF ORDER BY Max(tblsaldo.CLIENTE);Em tempo:
CHMATOS, não estou querendo ser chato com você, pois centenas de professores, engenheiros, programadores e analistas utilizam o têrmo [Ô]normalização[Ô] com freqüência, seja graças á um sistema educacional que deixa algo á desejar, seja por interpretação [Ô]apressada[Ô] dos tradutores de livros técnicos. E não estou pedindo que leve em conta o que vou expôr, pois nada tem á ver sequer com programação. é mais algo como um desabafo.
O fato é que o têrmo correto, no caso intaurado por este tópico, é [Ô]normatização[Ô], ou seja, o ato de estabelecer normas ou regras onde as informações possam ser armazenadas sem pêrda da integridade objetiva, ou seja, mantendo-as prontas para o fim á que se dentinam, que são as consultas.
Já o têrmo [Ô]normalização[Ô] seria o mesmo que dizer [Ô]o ato de tornar os registros normais[Ô]. Ainda que a palavra [Ô]normal[Ô] seja oriunda de [Ô]norma[Ô], ela é aplicável á médias, ou seja, quando uma maioria se comporta de uma determinada forma, aquele que se comporta diferentemente está fora da normalidade. Oras, não existe [Ô]registro anormal[Ô], uma vez que quem rege o comportamento dos registros é a estrutura tabular. Assim, o que existe é estrutura mal-dimensionada, e dessa forma, como um registro não pode por si mesmo ser considerado [Ô]normal[Ô] ou [Ô]anormal[Ô], pois a média é determinada pela estrutura, o uso deste têrmo é um equÃvoco (ou desastre) lingüÃstico que a imensa maioria dos tradutores, professores e mestres deveriam perceber e não cometer.
Novamente, desculpe aproveitar sua resposta para este desabafo.
Valeu Maluco pela explicação.Eu os chamo de Especialistas.
È o caso de um cabeça de bagre onde muitas empresas tratam
o funcionário de COLABORADOR.Desde quando um empregado ou
funcionário virou colaborador.Isto é assasinato do português.Vá lá
e verifica o que é Colaborador,funcionário ou empregado.
Eles acham bonito falar COLABORADOR.
È o caso de um cabeça de bagre onde muitas empresas tratam
o funcionário de COLABORADOR.Desde quando um empregado ou
funcionário virou colaborador.Isto é assasinato do português.Vá lá
e verifica o que é Colaborador,funcionário ou empregado.
Eles acham bonito falar COLABORADOR.
obrigado ALEVALE, FEDERHEN, OCELOT, CHMATOS, PROFESSOR pelas sugestões
luiz
luiz
Tópico encerrado , respostas não são mais permitidas