Formas normais e consultas com PHP e MySQL – Parte 02

Mar 31, 2012 by Sergio Novelli    No Comments    Posted under: Análise de sistemas, Desenvolvimento

Olá pessoal! Como prometi no post anterior, vamos dar sequência ao tutorial sobre normalização de banco de dados e manipulação com PHP e MySQL. Para quem não viu o post anterior, recomendo fazer a leitura para entender melhor qual é nosso objetivo. É só clicar aqui.

Bom, hoje vamos entender o que vamos desenvolver e como vamos fazer isso. Nossa aula não terá muita prática ainda, pois será focada na análise do projeto e na abstração do mesmo. Então vamos para a análise.

Nosso projeto consiste em um pequeno sistema para gerenciamento de treinamentos oferecidos aos funcionários de uma escola, sendo que essa escola possui matriz e filiais. Vamos nos concentrar no gerenciamento de inscrições, onde deveremos, no fim do projeto, conseguir cadastrar escolas, funcionários, treinamentos, categorias de treinamentos e, finalmente, fazer inscrições dos funcionários nos treinamentos. E, logicamente, precisaremos gerar alguns relatórios, como por exemplo, lista de inscritos no(s) treinamento(s), entre outros. Relatórios será um assunto abordado futuramente nos últimos posts desta série.

Se você prestar atenção neste último parágrafo, perceberá que já conseguimos aqui, visualizar todas as tabelas necessárias para nosso banco de dados. São elas: funcionarios, escolas, treinamentos, categorias e inscricoes. Poderíamos ainda, ter uma tabela filiais, mas vamos cadastrar as filiais e a matriz dentro da tabela escolas apenas para simplificar nosso projeto.

Agora, vamos começar a pensar em quais dados serão cadastrados em nossas tabelas. Iniciando pela tabela funcionarios, vamos levantar quais as regras de negócio dessa tabela. Para início de conversa, todo funcionário terá obrigatoriamente um número de matrícula interno da escola que jamais deverá se repetir. Outro campo obrigatório é o CPF, que por natureza também não deverá se repetir e deverá ser validado. Logicamente teremos um campo para o nome do funcionário. Além desses, também haverão os campos telefone (fixo) e celular. Vamos acrescentar ainda o campo e-mail. Os campos nome, telefone e celular serão obrigatórios e o email será opcional.

Agora pense comigo: será que todas essas regras serão abordadas no banco de dados? Nota 10 se você respondeu NÃO!

A obrigatoriedade do preenchimento dos campos será tratada na camada de aplicação. No banco de dados trataremos da integridade dos dados, ou seja, garantiremos que as chaves primárias, por exemplo, se repitam jamais, mesmo quando eu apagar um registro, a sua chave não será reutilizada. E o campo matricula do funcionário, como vamos garantir que o mesmo seja gerado automaticamente e jamais se repita? Bom, aí teremos que fazer uma análise mais profunda sobre como esse campo é formado. Por exemplo, vamos supor que este campo seja formado pelos quatro dígitos do ano de contratação do funcionário e finalizado com o número atual do funcionário na empresa, separados por um hífen. Ex: 2012-58, sendo que sempre haverá os dois últimos dígitos, ou seja, números abaixo de 10, serão preenchidos com zero à esquerda.

Nesse caso, deveremos gerar esse número na camada de aplicação. Outra opção seria usar o conceito de chave primária composta, o que permitiria juntar dois campos numéricos, obrigatoriamente, como chave primária. Porém este conceito é mais complexo, na minha opinião. É muito mais simples trabalhar com chave primária simples, deixando o banco responsável por essa tarefa. Como em nosso projeto, o campo matrícula terá um caractere hífen e essa numeração não será utilizada para cálculos, concluímos que este campo pode tranquilamente ser do tipo varchar e não o utilizaremos como chave primária da tabela.

Para concluir nossa análise na tabela funcionários, vamos ter então um campo que, geralmente chamam de ‘id’. Eu costumo chamar este campo de ‘pk_<nomeDaTabela>‘, o qual será nossa chave primária. Vamos apresentar nossa tabela funcionarios:

funcionarios (pk_funcionario, matricula, funcionario, cpf, telefone, celular, email)

Agora vamos definir quais os tipos de dados e o tamanho de cada um dos campos.

pk_funcionario será um integer de tamanho 11, que é o padrão para chaves primárias.

matricula será um varchar de tamanho 10. Lembrem-se que os últimos dígitos desse campo corresponde ao número do funcionário, portanto, temos que abrir margem para que o sistema permita cadastrar os funcionários com números de 3, 4 e até 5 dígitos. Ex: 2012-99999.

funcionario é um varchar com o nome da pessoa e deverá ter, no mínimo tamanho 50.

cpf é também um varchar com o tamanho 14, pois vamos guardá-lo já formatado com pontos e hífen. Ex: 999.999.999-99.

telefone e celular são varchar com tamanho 14 também. Ex: (99) 9999-9999.

email é um campo varchar com tamanho 50 assim como o campo funcionario.

Bom pessoal. É assim que se faz a análise de um banco de dados. Tentem fazer a análise das demais tabelas citadas nesse post antes de ler o próximo.

No próximo post, não farei essa análise. Partirei direto para o entendimento do DER e disponibilizarei o código SQL para começarmos a implementar nosso banco.

Deixem suas dúvidas nos comentários, de preferência. Fiquem à vontade para sugerir, criticar ou corrigir qualquer falha que eu tenha cometido em minha análise.

Até o próximo.