Normalização de dados

olá Valquiria, a melhor opção é fazer uma modelagem e seguir as normas para em hipotese alguma vc ter problemas.

Olá Alan obrigada pela resposta vou revisar minha modelagem.

Concordo com o Alan!
Com a estrutura bem elaborada e com os recursos bem utilizados, dificilmente vc terá problemas.

Ola Bom dia!!!

Penso eu que tudo vai depender basicamente do seu projeto e da analise, se a 1FN atende, blz, ou se o ideal eh chegar a Boyce e Cod(acho que eh assim que escreve, nao lembro mais. rsrsr).

Alguns analistas/especialistas no assunto, dizem que se o seu banco chegar na 3FN ja estara de bom tamanho e atendera os requisitos de desempenho e normalizacao.

Lembrando que alguns problemas nos desempenhos de bases bem normalizadas sao minimizados com indices bem criados e views bem elaboradas.

Um ponto importante na montagem dos codigos eh entender bem o algoritimo que o banco trabalha por tras dos scripts utilizados.

Parece loucura, mas estudar e entender bem algebra relacional ajuda a entender bem o funcionamento dos algoritimos do banco.

e levar sempre em conta as diferencas entre um banco e outro e certas estruturas funcionam melhor em um que outro.

Espero ter ajudado.

Abraco.

qualquer probleminha ou duvida, estamos aqui.

vejo que ultimamente isso está sendo deixado de lado, algebra relacional só se vê em faculdade, não deveria ser somente nesse ambiente.

Eu acho q tem "coisas" que não são mais vistas em função dos frameworks que já fazem boa parte do trabalho.

infelizmente está assim, mas deveria pelo menos explicar.

pessoal, pensando em situação, quando um profissional de banco de dados já pega um banco mal modelado, como fica a normalização quando se quer "consertar"? refaz o banco?

ai depende muito.

o SQL Server tem uma ferramenta que vc consegue dividir as tabelas para vc corrigir normalizacoes.

Um exemplo seria a tabela de clientes com o endereco completo do cliente, depois de um tempo vc pode separar os dados de endereco da tabela e utilizar o campo cep como relacionamento entre a tabela nova e a tabela de clientes.

Nesse exemplo vc teria um unico cadastro de endereco e se tivesse cadastros separados de clientes, fornecedores, fabricantes, funcionarios, vendedores, etc, etc, vc diminuiria consideravelmente o tamanho de espaco etc, etc, e acredito que seria uma boa normalizacao.

mas dependendo do banco valera mais a pena refazer. rsrsr

Abraco.

Obrigada pelas opiniões.

Estou fazendo um projeto para Firebird.
Uma outra dúvida que me ocorre, é na criação das chaves primárias no caso do relacionamento entre as tabelas, como conseguir boa performance e integridade referencial?
Por exemplo já vi tabelas com até 4 campos formando chaves primárias e todas as tabelas "detalhes ou filhas", carregando estes mesmos campos, no final um custoso e enorme join.

Seria mais eficiente criar apenas um campo "ID" como chave ? Se sim como referenciar os relacionamentos?

Agradeço qualquer ajuda.

dependendo estrago feito rsrsrs, entendi, é melhor ter um trabalhão para refazer do que ter um trabalhão todo santo dia.

de nada Valquiria, sobre as novas duvidas, não estou apto a te responder.

o retrabalho sempre da mais trabalho que o trabalho. kkkk

ficou parecendo coisa de filosofo louco... mas tudo bem. kkk

Oi Honestamente nao entendi muito bem. rsrsr

se entendi bem, se ha necessidade de tantos campos assim para ter uma chave primaria, talvez seja necessario se pensar na divisao da tabela e usar apenas o relacionamento comum.

como nao sou a pessoa mais experiente no assunto, nao conseguirei ajudar bem, desculpe.

ficou mesmo rsrsrsrs.