Técnicas de Normalização por Phaser http://phpbrasil.com/articles/article.php/pagerrow/0/id/146 Dos fatores mais importantes no desenvolvimento de páginas dinâmicas é a definição de banco de dados. Se suas tabelas não estão definidas apropriadamente, isso pode lhe causar muita dor de cabeça quando você tiver executar chamadas SQL miraculosas no seu código PHP e extrair os dados que você deseja. Ao entender o relacionamento entre os dados e a normalização de dados, você estará mais bem preparado para começar a desenvolver suas aplicações em PHP. Trabalhando com Access, MySQL, PosgreSQL ou Oracle, você deve conhecer os métodos de normalização do esquema de tabelas no seu sistema de banco de dados relacional. Eles podem ajudar a fazer seu código PHP ser mais fácil de entender, mais fácil de expandir e, em alguns casos, acelerar sua aplicação. Basicamente as Regras de Normalização são reforçadas pela eliminação de redundâncias e dependências inconsistentes no projeto de suas tabelas. Eu irei explicar o que isso significa examinando os cinco passos progressivos de normalização de que você deve estar ciente para criar banco de dados funcionais e eficientes. Também irei detalhar os tipos de relacionamentos que sua estrutura de dados pode utilizar. Digamos que nós queiramos criar uma tabela com informações de pacientes, e que queiramos armazenar o Nome, Convenio, Endereço do Convenio, e alguns CID de cada paciente. Você pode começar definindo uma estrutura de tabela como esta: Forma Zero pacientes nome convenio convenio_tel diagnostico1 diagnostico2 Carlos ABC 5432-1234 Dor precordial Hipoglicemia Flávia XYZ 1234-5678 Dor precordial Anorexia Iremos dizer que esta tabela é Forma Zero porque nenhuma das regras de normalização foi aplicada ainda. Note os campos Diagnostico1 e Diagnostico2. O que faremos se nossa aplicação precisar adicionar mais um terceiro Diagnostico? Você quer continuar adicionando colunas em sua tabela e codificar mais este campo INPUT no seu código
PHP? Óbvio que não, você criaria um sistema funcional que poderia crescer com as novas exigências de desenvolvimento. Olhemos para as regras para a Primeira Forma Normal, e então vamos aplicá-las a esta tabela. Primeira Forma Normal 1. Eliminar grupos repetidos em tabelas individuais. 2. Criar tabelas separadas para cada conjunto de dados relacionados; 3. Identificar cada conjunto de dados relacionados com uma chave primária Você nota que estamos quebrando a primeira regra ao repetirmos os campos Diagnosticos1 e Diagnosticos2? E quanto à regra três, chaves primárias? A regra três significa basicamente que queremos definir um tipo de valor inteiro único e autoincrementado em cada uma de nossas linhas. Caso contrário, o que aconteceria se tivéssemos dois pacientes com nome Flávia e quiséssemos separar um do outro? Quando aplicamos as regras da Primeira Forma Normal nós teremos a seguinte tabela: pacientes rghsp nome convenio convenio _tel diagnostico 1 Carlos ABC 5432-1234 Dor precordial 1 Carlos ABC 5432-1234 Hipoglicemia 2 Flávia XYZ 1234-5678 Dor precordial 2 Flávia XYZ 1234-5678 Anorexia Agora nossa tabela é dita estar na Primeira Forma Normal. Nós solucionamos o problema da limitação de campos de Diagnostico, mas olhe a dor de cabeça que nos colocamos agora. Cada vez que colocamos uma nova linha na tabela de pacientes nós duplicamos todos os dados da companhia e do nome do paciente. Nosso banco de dados não vai apenas ficar muito maior do que esperávamos, mas nós poderíamos facilmente corromper nossos dados misturando algumas dessas informações redundantes. Vamos aplicar as regras da Segunda Forma Normal: Segunda Forma Normal 1. Criar tabelas separadas para conjuntos de valores que se aplicam a registros múltiplos 2. Relacionar estas tabelas com chaves estrangeiras
Nós extraímos os valores Diagnostico para uma tabela separada para que possamos adicionar mais diagnósticos no futuro sem ter que duplicar os dados. Nós também vamos querer usar nosso valor de chave primária para relacionar estes campos: pacientes rghsp nome convenio convenio_tel 1 Carlos ABC 5432-1234 2 Flávia XYZ 1234-5678 diagnosticos cid rghsp descricao_cid R07.2 1 Dor precordial E16.2 1 Hipoglicemia R07.2 2 Dor precordial R63.0 2 Anorexia Criamos tabelas separadas, e a chave primária na tabela de Pacientes o rghsp, agora relacionamos à chave estrangeira rghsp na tabela de Diagnosticos. Nós temos uma forma muito melhor agora. Mas o que acontece se quisermos adicionar outro Paciente do Convenio ABC? Ou mais 2000 pacientes? Teríamos agora nomes de Convênios e de pacientes duplicando-se por todos os lugares. Com certeza teremos uma situação perfeita para duplicar erros em nossos dados. Então teremos que aplicar a Terceira Forma Normal: Terceira Forma Normal 1. Eliminar campos que não dependem da chave. O nome e endereço do nosso Convênio não tem nada a ver com a identificação do paciente, então eles teriam que ter seus próprios Códigos de identificação de Convênio:
pacientes rghsp nome cod_convenio 1 Carlos 1 2 Flávia 2 convenios cod_convenio convenio convenio_tel 1 ABC 5432-1234 2 XYZ 1234-5678 Agora nós temos a chave primária cod_convenio na tabela de Convenios relacionada à chave estrangeira na tabela de pacientes também chamada cod_convenio, e podemos adicionar 2000 pacientes enquanto só inserimos os Convênios ABC e XYZ. diagnosticos rghsp cid descricao_cid 1 R07.2 Dor precordial 1 E16.2 Hipoglicemia 2 R07.2 Dor precordial 2 R63.0 Anorexia Nossa tabela de Pacientes e Diagnósticos poderão crescer sem necessariamente duplicar ou corromper nossos dados. A maioria dos desenvolvedores diriam que a Terceira Forma Normal é suficiente, e que o nosso esquema de dados poderiam facilmente manipular dados de todo um Ambulatório. De certa forma e na maioria dos casos eles estariam corretos. Mas olhando para nossos campos de CID notamos a duplicação de dados? Isso é perfeitamente aceitável se não estamos predefinindo estes campos. Se o input da página HTML permite que nossos pacientes insiram livremente o seu texto não há nada que
possamos fazer a respeito disso, e é apenas uma coincidência que Carlos e Flávia ambos puseram o mesmo diagnostico. Mas e se temos um menu drop-down onde sabemos que somente estes 2 CID são permitidos, ou talvez 20 ou mais 1000? Podemos elevar o nosso esquema de banco de dados para o próximo nível, a Quarta Forma, uma que muitos desenvolvedores ignoram porque ela depende em um tipo muito específico de relacionamento, o relacionamento muitos-para-muitos, o qual nós não encontramos ainda em nossa aplicação. Relacionamento de Dados Antes de definirmos a Quarta Forma Normal, vamos dar uma olhada nos 3 tipos básicos de relacionamento; um-para-um, um-para-muitos e muitos-para-muitos. Observe a tabela de pacientes na Primeira Forma Normal acima. Por um instante vamos imaginar que colocamos os campos de Diagnostico em uma tabela separada, e toda vez que nós inserimos um registro na tabela de pacientes nós iríamos inserir uma linha na tabela Diagnosticos. Nós teríamos então um relacionamento um-para-um: cada linha na tabela de pacientes teria exatamente uma linha correspondente na tabela de Diagnósticos. Para os propósitos da nossa aplicação isso não seria nem útil nem normalizado. Agora olhe para as tabelas no exemplo da Segunda Forma Normal. Nossas tabelas permitem a um paciente ter muitos Diagnósticos associados a este registro de paciente. Esta é uma relação umpara-muitos, o tipo mais comum, e até que atingíssemos o dilema apresentado na Terceira Forma Normal, o único tipo que precisaríamos. O relacionamento muitos-para-muitos, por outro lado, é um pouco mais complexo. Note que no nosso exemplo da Terceira Forma Normal nós temos um paciente relacionado a muitos Diagnosticos. Como mencionado, nós queremos mudar esta estrutura para permitir que muitos pacientes estejam relacionados com muitos Diagnósticos, dessa forma nós queremos um relacionamento muitos-para-muitos. Vamos dar uma olhada no que isso faria à estrutura das nossas tabelas antes de discutimos. paciente rghsp nome 1 Carlos 1 2 Flávia 2 cod_convenio convenios cod_convenio convenio convenio_tel
1 ABC 54321-1234 2 XYZ 1234-5678 diagnosticos cid descricao_cid R07.2 Dor precordial E16.2 Hipoglicemia R63.0 Anorexia diagnostico_pac cid rghsp R07.2 1 R07.2 2 E16.2 1 R63.0 2 Para diminuir a duplicação de dados (e no processo que nos leva à Quarta Forma de Normalização), nós criamos uma tabela com chave primária e estrangeira em Diagnostico_Pac. Agora podemos expressar com exatidão a quais diagnósticos Carlos e Flávia estão relacionados. Vejamos agora o que diz exatamente a Quarta Forma de Normalização: Quarta Forma Normal 1. Num relacionamento muitos-para-muitos, entidades independentes não podem ser armazenadas na mesma tabela. Já que isso só se aplica a relacionamentos muitos-para-muitos, muitos desenvolvedores podem corretamente ignorar esta regra. Mas ela torna-se útil em certas situações, como
esta. Nós modificamos com sucesso nossa tabela de Diagnósticos para eliminar redundâncias e movemos os relacionamentos em sua própria tabela. Só para lhe dar um exemplo prático, agora nós podemos selecionar todas os Diagnósticos de Carlos executando a seguinte chamada SQL: SELECT nome, descricao_cid,cid FROM pacientes, diagnosticos, diagnostico_pac WHERE pacientes.rghsp =1 AND diagnosticos.cid= diagnostico_pac.cid E se quiséssemos circular por todas as informações de Pacientes e Diagnósticos de todo mundo, faríamos algo assim: SELECT nome, descricao_cid FROM pacientes, diagnosticos, diagnostico_pac WHERE pacientes.rghsp = diagnostico_pac.rghsp and diagnosticos.cid = diagnostico_pac.cid Quinta Forma Normal Aqui está uma forma de normalização que as vezes é aplicada, mas é realmente muito esotérica e em muitos dos casos não é exigida para ter a maior funcionalidade a partir da estrutura de dados ou aplicação. Ela sugere que:
1. A tabela original deve ser reconstruída a partir das tabelas que foram geradas por ela. O benefício de aplicar esta regra garante que você não criou nenhuma coluna estranha nas suas tabelas, e que todas as estruturas das tabelas que você criou só são tão grandes quanto elas necessitam ser. É de boa prática aplicar esta regra, mas a não ser que você esteja lidando com um esquema de dados muito grande você provavelmente não vai precisar dela. Espero que você tenha achado este artigo útil e que seja capaz de aplicar estas regras de normalização para todos os seus projetos de banco de dados. E caso você esteja imaginando de onde veio isso tudo, as primeiras três regras de normalização são descritas pelo Dr. E.F. Codd em um trabalho seu de 1972, "Further Normalization of the Data Base Relational Model". Outras regras tem, desde então, sido teorizadas por matemáticos posteriores da Teoria de Conjuntos e Álgebra Relacional. Consulte também http://www.locasite.com.br/sistemas/msaccess.shtml http://www2.superasp.com.br/conteudo/tutoriais/apostila_de_bd_esql.doc http://www.geocities.com/fatecinfo/inf06002.htm