Caro Gerhard, Esclareceu e muito as minhas dúvidas.
Muito obrigado Um forte abraço Alinei --- Em delphi-br@yahoogrupos.com.br, "Gerhard Roger Nack" <[EMAIL PROTECTED]> escreveu > > Bem vamos lá, a situação 2 eu, particularmente faria assim: > > Situação 2: > > TAB_PESSOA > CODPESSOA > NOME > CPFCNPJ > DATACAD > CODENDERECO > CODTELEFONE > IDEMAIL > EMAIL > SEXO ( M - F ) > DATANASC > > TAB_ENDERECO > CODENDERECO > TIPOLOGADOURO > ENDERECO > NUMERO > COMPLEMENTO > CIDADE > UF > CEP > > TAB_TELEFONE > CODTELEFONE > IDTELEFONE > TELEFONE > TPTELEFONE ( TRABALHO - RESIDENCIAL - FAX - CELULAR ) > > Ou seja, eu não criaria uma tabela para email pois é uma informação que dificilmente irá se repetir e geraria um overhead muito na hora dos join's, como também não criaria a tabela SEXO_DATANASC pelo mesmo motivo. > > Você colocou o CODPESSOA em todas as tabelas, o correto seria cada tabela ter o seu código próprio (ENDERECO, TELEFONE, etc) e a PESSOA ter o CODENDERECO, CODTELEFONE, etc., pois do contrario você nunca poderia utilizar um mesmo TELEFONE para mais de uma pessoa. Isso inviabilizaria a criação dessas tabelas de referência, pois no fundo você sempre teria um relacionamento de 1-1 e nunca de 1-N que é justamente o que justifica a normalização. > > Seria melhor normalizaria a tabela ENDERECO para algo assim: > > TAB_ENDERECO > CODENDERECO > TIPOLOGADOURO > ENDERECO > NUMERO > COMPLEMENTO > CODCIDADE > CEP > > TAB_CIDADE > CODCIDADE > CIDADE > UF > > Mas particularmente eu ainda utilizaria o campo CEP juntamente com a tabelas do correio ou da GSE Soft, normalizando a tabela ENDERECO para algo assim: > > TAB_ENDERECO > CODENDERECO > CEP > NUMERO > COMPLEMENTO > > Ou seja, deixaria apenas o CEP e restante dos dados como Endereco, Tipo Logradouro, Cidade, UF e Bairro buscaria na base dos correios e só teria os dados específicos daquele endereço como NUMERO e COMPLEMENTO. > > Resumindo, deve-se normalizar as tabelas sim, porém o bom censo deve prevalecer pois nem sempre pode-se levar a normalização até o último nível possível pois degradaria muito a performance do sistema. > > OBS: Para fins de clareza no email deixei o prefixo "TAB_" que você utilizou, mas jamais, jamais utilizaria isso no mundo real, pois como se trata de uma tabela e sabendo-se que todas elas encontram-se no banco de dados não se justifica utilizar esse prefixo que seria igual a todas elas. > > Espero ter esclarecido um pouco, e qualquer dúvida estamos ai. > > > > Bem mas vamos ao assunto que venho estudando. > > Estou desenvolvendo um projeto que tem por objetivo ser multi- banco, > estou utilizando o Oracle XE e o Firebird 2.0 para testes com tabelas > que têm em média 100.000 registros > > Pesquisando o assunto, tenho observado que depende muito das regras > de negócio que cada um adota em seus projetos de modelagem. > > Minha dúvida é o que seria melhor, deixar os campos que têm ligação > de dependência funcional na mesma tabela ou dividi-los em tabelas > filhas ex: > > Situação 1: > > Tab_Pessoa > CODIGO > NOMERAZAO > CPFCNPJ > IDENTESTADUAL > SEXO > DATANASC > ENDERECO > NUMERO > COMPLEMENTO > BAIRRO > CIDADE > CEP > TELEFONE > CELULAR > EMAIL > DATACAD > > Situação 2: > > TAB_PESSOA > CODPESSOA > NOME > CPFCNPJ > DATACAD > > TAB_ENDERECO > CODPESSOA > TIPOLOGADOURO > ENDERECO > NUMERO > COMPLEMENTO > CIDADE > UF > CEP > > TAB_TELEFONE > CODPESSOA > IDTELEFONE > TELEFONE > TPTELEFONE ( TRABALHO - RESIDENCIAL - FAX - CELULAR ) > > TAB_EMAIL > CODPESSOA > IDEMAIL > EMAIL > > TAB_SEXO_DATANASC > CODPESSOA > SEXO ( M - F ) > DATANASC > > Qual das situações é a mais correta ? Qual a melhor prática ? Na > Situação 1 podiamos "desegregar" os campos "telefone" e "e-mail", e > manter os demais campos na tabela pessoa, dessa forma qual dos > modelos seria o mais correto. > > O que vocês recomendam ? > > Um forte abraço a todos > > alineri > > - Em delphi-br@yahoogrupos.com.br <mailto:delphi-br% 40yahoogrupos.com.br> , "Gerhard Roger Nack" <ginho@> > escreveu > > > > Então comecemos a normalizar os textos. > > > > > > > > Não é "campu" é "campo". > > > > > > > > Frase começar com maiúsculo e também existem palavras acentuadas na > língua portuguesa. > > > > > > > > > > > > De: delphi-br@yahoogrupos.com.br <mailto:delphi-br% 40yahoogrupos.com.br> [mailto:delphi- > [EMAIL PROTECTED] <mailto:br%40yahoogrupos.com.br> ] Em nome de alineri > > Enviada em: sexta-feira, 14 de dezembro de 2007 16:31 > > Para: delphi-br@yahoogrupos.com.br <mailto:delphi-br% 40yahoogrupos.com.br> > > Assunto: [delphi-br] dependencia funcional normalizacao e numero de > campos > > > > > > > > ola pessoal, sei que nao tem a ver com a ferramenta Delphi, e sobre > > modelagem mas acredito ser a duvida de muitos tambem que pararam > para > > observar essa questao. > > > > tenho uma duvida que carrego ja a um tempo. > > > > um exemplo, tenho os dados de um formulario para ser modelado, ao > > todo sao uns 80 campus e no formulario os campos sao subdivididos > em > > categoria, ex: atendimento, execucao, entrega, quantidades etc... > > > > a maioria desses campus seguem o conceito de dependencia funcional > so > > que dessa forma minha tabela fica com um numero de campus muito > > grande, entao eu geralmente normalizo a tabela criando tabelas > filhas > > contendo esses outros campus, seguindo a "ideia" de subdivisao > feita > > no formulario, isso esta correto ? e uma boa pratica ? > > > > minha duvida vem pq aplicando a 2FN ou a 3FN acabo tendo umas 4 a 5 > > tabelas filhas, e na hora de fazer uma juncao eu acabo tendo uma > > lentidao que acredito ser disso pois se trata de muitos registros. > > > > Gostaria da opniao dos colegas a respeito disso, se e uma boa > pratica > > ou nao ou oq e mais recomendado. > > > > um abarco a todos > > alineri > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
