O Modelo Relacional de Dados – Parte V

Nesta quinta e última parte falarei sobre o projeto de banco de dados e ressaltarei a importância de fazer a Modelagem do Banco de Dados, antes de partir para a implementação prática. Falarei também sobre a Arquitetura do Microsoft Access.

por Júlio Cesar Fabris Battisti

Objetivo: Na primeira parte deste artigo falei sobre Entidades (tabelas), Atributos (campos) e sobre o conceito de Chave Primária. Na segunda parte falei sobre Relacionamentos e tipos de relacionamentos. Na terceira parte falei sobre um dos conceitos mais importantes do modelo relacional de dados: Integridade Referencial. Também mostrei um exemplo prático de como configurar Relacionamentos e Integridade Referencial no Microsoft Access. Na quarta parte sobre os fundamentos do Modelo Relacional de dados, falei sobre Normalização de banco de dados e as três principais formas normais. Nesta quinta e última parte falarei sobre o projeto de banco de dados e ressaltarei a importância de fazer a Modelagem do Banco de Dados, antes de partir para a implementação prática. Falarei também sobre a Arquitetura do Microsoft Access. O entendimento do Modelo Relacional e da Arquitetura do Microsoft Access são fundamentais.

Muitos dos emails que recebo, com dúvidas sobre o Access, são relativo à dúvidas que seriam solucionadas com o conhecimento do Modelo Relacional e da Arquitetura do Access. O que acontece, muitas vezes, é que o usuário parte diretamente para o uso do Access, criando tabelas, consultas, formulários e relatórios, sem antes ter feito um projeto cuidadoso da estrutura do banco de dados, implementando relacionamentos, fazendo a normalização e impondo Integridade referencial. Trabalhar desta maneira é como fazer um prédio sem ter antes feito um estudo do terreno, ter feito a planta e os cálculos estruturais. Você moraria em um prédio construído desta maneira? Eu não.

Nota: Os exemplos apresentados utilizarão telas do Microsoft Access e o arquivo de exemplos Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho: C:\Arquivos de programas\Microsoft Office\Office\Samples Porém os princípios básicos do modelo relacional aplicam-se a qualquer banco de dados baseado no modelo relacional de dados. Estes bancos de dados são algumas vezes denominados: SGBDR - Sistemas Gerenciadores de Banco de Dados Relacionais.

Normalização de tabelas

Objetivo: O objetivo da normalização é evitar os problemas provocados por falhas no Projeto do Banco de Dados, bem como eliminar a "mistura de assuntos" e as correspondentes repetições desnecessárias de dados.

Projetando um Banco de Dados

Neste item você aprenderá a projetar um Banco de Dados. Você aplicará os conhecimentos sobre Tabelas, Campos, Relacionamentos, Chave Primária e Normalização, vistos anteriormente, nas primeiras partes deste tutorial.

Antes de começar a trabalhar com o Microsoft Access, é preciso fixar bem os conceitos vistos nas partes anteriormentes, aplicando-os no Projeto de um Banco de Dados. Um banco de dados bem projetado fornece um acesso conveniente às informações desejadas. Com uma boa estrutura, gasta-se menos tempo na construção de um banco de dados e, ao mesmo tempo, assegura-se resultados mais rápidos e precisos. Nunca é demais lembrar que jamais devemos misturar assuntos em uma mesma tabela.

Etapas na estruturação e projeto de um Banco de dados:

è Determinar qual o objetivo do banco de dados: Isto ajuda na determinação de quais os dados devem ser armazenados. É fundamental ter bem claro qual o objetivo a ser alcançado com o banco de dados. É fazer o acompanhamento das despesas, a evolução das vendas ou outro objetivo qualquer.

è Determinar as tabelas necessárias: Após definirmos os objetivos do Banco de Dados, as informações devem ser definidas e separadas em assuntos diferentes, tais como "Clientes", "Empregados", "Pedidos", pois cada um irá compor uma tabela no banco de dados. Lembre-se da regrinha número um: "Não misturar assuntos na mesma tabela", ou seja, uma coisa é uma coisa e outra coisa é outra coisa.

è Determinar os Campos de cada Tabela: Definir quais informações devem ser mantidas em cada tabela. Por exemplo, a tabela Clientes poderia ter um campo para o Código Do Cliente, outro para o Nome Do Cliente e assim por diante.

è Determinar a Chave Primária de cada tabela, sendo que pode haver tabelas onde não exista uma chave primária: Determinar, em cada tabela, quais campos serão utilizados como Chave Primária. Esta é uma etapa importantíssima para a definição dos Relacionamentos que vem a seguir. Pode haver tabelas onde não exista uma chave primária.

è Determinar os Relacionamentos: Decidir como os dados de uma tabela se relacionam com os dados de outras tabelas. Por exemplo, Clientes podem Fazer Vários Pedidos, então existe um relacionamento do tipo Um-para-vários entre a tabela Clientes (lado um) e a tabela Pedidos (lado vários). Fornecedores podem fornecer Vários Produtos, etc.

è Refinar a Estrutura do Banco de Dados: Antes de inserir muitos dados, ou até mesmo antes de inserir qualquer dado, verificar se a estrutura contém erros, isto é, verificar se os resultados obtidos são os desejados. Isto, normalmente, pode ser obtido através do processo de Normalização. Caso necessário, deve-se alterar a estrutura do banco de dados.

Com uma boa estrutura, gasta-se menos tempo na construção e manutenção do banco de dados e, ao mesmo tempo, assegura-se resultados mais rápidos e precisos.

Dicas para determinação dos campos de uma Tabela:

è Relacionar diretamente cada campo ao assunto da tabela: Se um campo descreve o assunto de uma tabela diferente, este campo deve pertencer a outra tabela. O mesmo acontece quando uma informação se repete em diversas tabelas. Este é um indício de que existem campos desnecessários em algumas tabelas.

è Não Incluir dados Derivados ou Calculados: Não é recomendado armazenar o resultado de cálculos nas tabelas. O correto é que o cálculo seja executado quando necessitarmos do resultado, normalmente em uma consulta.

è Incluir todas as informações necessárias: Como é fácil esquecer informações importantes, deve-se ter em mente todas as informações coletadas desde o início do processo e perguntar se com elas é possível obter todas os resultados desejados.

è Armazenar todas as informações separadamente: Existe uma tendência em armazenar informações em um único campo. Por exemplo, o nome do curso e o tempo de duração em uma mesmo campo. Como as duas informações foram combinadas em um único campo, ficará difícil conseguir um relatório classificado pelo tempo de duração dos cursos.

Como selecionar o campo que será a Chave Primária?

Um bom Sistema Gerenciador de Banco de Dados (SGBD) é aquele que encontra e nos fornece, rapidamente, todas as informações necessárias que nele estejam armazenadas, mesmo que estas informações estejam em diferentes tabelas. Para que isto seja possível é necessário incluir um campo ou conjunto de campos que identifiquem de modo único cada registro de uma tabela. Esta informação é chamada Chave Primária. Deve-se ter certeza que este campo (ou conjunto de campos) seja sempre diferente para cada registro, por não ser permitido valores duplicados em um campo de chave primária.

Ao escolher campos de Chave Primária, considere os seguintes detalhes:

è Não é permitido duplicidade de valores ou nulos (informações desconhecidas).
è Caso não exista um identificador único para uma determinada tabela, pode-se usar um campo que numere os registros seqüencialmente.
è Pode-se utilizar o valor deste campo para encontrar registros.
è O tamanho da chave primária afeta a velocidade das operações, portanto, para um melhor desempenho, devemos utilizar o menor tamanho que acomode os valores necessários que serão armazenados no campo.

Agora que já revisamos diversos conceitos importantes sobre banco de dados vamos colocá-los em prática, através de um exercício de Projeto de Banco de Dados. Será apresentada uma determinada situação e você deverá projetar o Banco de Dados para atender a Situação Solicitada. Projetar o banco de dados significa fazer um diagrama Entidade x Relacionamentos onde são indicadas quais tabelas farão parte do banco de dados, quais os campos de cada tabela, qual o campo que será a Chave Primária nas tabelas que terão Chave Primária e quais os relacionamentos entre as tabelas. Na figura a seguir temos um exemplo de um diagrama Entidades x Relacionamentos:

Nota: Os campos que aparecem em negrito representam a Chave Primária de cada tabela.Exercício: Imagine que você está projetando um Banco de Dados para uma Escola. Este Banco de Dados deverá conter informações sobre os Alunos, os Pais dos Alunos, As matérias em que cada aluno está matriculado (imagine que alunos da mesma série podem estar matriculados em diferentes matérias), as notas do aluno em cada matéria e em cada bimestre, bem como todo o histórico do aluno na escola. O histórico inclui as notas do aluno em cada matéria em cada um dos anos em que ele esteve na escola. O banco de dados deve manter um cadastro de alunos, dos pais dos alunos, das disciplinas ofertadas, da nota de cada aluno em cada disciplina, e em que disciplina cada aluna está matriculado.

O Sistema deverá ser capaz de fornecer, a qualquer momento, a situação atual do aluno em termos de suas notas, bem como todo o seu histórico. O Sistema não deve permitir que seja cadastrado um aluno sem antes serem cadastrados os seus pais. Além disso todo aluno terá um número de matrícula que é único. Cada disciplina também terá um código único.

O Sistema deve ser capaz de emitir relatórios com as notas por turma e por bimestre, além das médias para cada disciplina.

Projete um Banco de Dados capaz de atender a estas necessidades. O Resultado final do seu trabalho será o "Diagrama Entidades x Relacionamentos", com as Tabelas, Campos de Cada Tabela, Chaves Primárias e Relacionamentos entre as tabelas.

Ao Final do Processo, aplique o processo de Normalização para verificar se a estrutura apresenta algum tipo de Problema.

Arquitetura do Microsoft Access

Neste item iremos analisar a Arquitetura do Microsoft Access Veremos os diversos elementos que podem fazer parte de um Banco de Dados do Microsoft Access, bem como os relacionamentos entre estes diversos elementos. Veremos também alguns exemplos práticos de solução de problemas.

Abordarei os seguintes tópicos:

è Os diversos elementos do Microsoft Access e a Relação entre os eles.
è Alguns Exemplos de Situações do dia-a-dia.

Os Diversos Elementos do Access e a Relação entre eles:

Um banco de dados é uma coleção de informações relacionadas a um determinado assunto ou finalidade, como controle de pedidos dos clientes ou manutenção de uma coleção de CDs e assim por diante. Se o seu banco de dados não está armazenado em um computador, ou se somente partes dele está, você pode estar controlando informações de uma variedade de fontes, tendo que coordená-las e organizá-las você mesmo.

Um arquivo .mdb é um Banco de Dados do Microsoft Access. Esse banco de dados contém diversos elementos: Tabelas, Consultas, Formulários, Relatórios, Macros, Páginas de dados e Módulos.

Utilizando o Microsoft Access, você pode gerenciar todas as suas informações a partir de um único arquivo de banco de dados. Dentro do arquivo, divida seus dados em compartimentos de armazenamento separados denominados tabelas (ou entidades); visualize, adicione e atualize os dados da tabela utilizando formulários on-line; localize e recupere apenas os dados desejados utilizando consultas; e analise ou imprima dados em um layout específico utilizando relatórios.

Para armazenar seus dados, crie uma tabela para cada tipo de informação que você registra. Para reunir os dados de várias tabelas em uma consulta, formulário ou relatório, você define relacionamentos entre as tabelas. Aqui nos temos dois fatos de grande importância:

è Todos os dados ficam armazenados em Tabelas. Quando uma Consulta exibe os resultados com base em um Critério, na verdade ele está buscando os dados em uma determinada tabela. Quando um formulário exibe um determinado registro, ele também está buscando estes dados em uma determinada tabela. No Microsoft Access, o único local onde os dados ficam armazenados é nas tabelas.

è Mesmo que as informações estejam separadas em diferentes tabelas (Clientes, Pedidos, Detalhes do Pedido, etc) é possível reuni-las em Consultas, Relatórios e Formulários. Por exemplo, posso criar um Relatório de Vendas por Cliente, classificados pelo País de Destino.

Na Figura a seguir, vemos os diversos elementos que formam um Banco de Dados do Microsoft Access, bem como o Relacionamento entre os diversos elementos.

Os Diversos Elementos de um Banco de Dados do Microsoft Access.

Nunca é demais salientar que o único local onde ficam armazenados os dados é nas tabelas. Por isso que ao construirmos uma consulta, formulário ou relatório, o Microsoft Access solicita os dados para a tabela na qual a consulta, formulário ou relatório está baseado.

Algumas Observações sobre os Elementos do Microsoft Access:

è Observe o Relacionamento que existe entre os Elementos. Uma consulta é baseada em uma tabela, isto é, os dados que a consulta exibe são buscados a partir de uma ou mais tabelas. Se os dados forem alterados na consulta, na verdade estas alterações são refletidas diretamente na tabela. Por isso uma seta de dupla mão entre tabelas e consultas. As mesmas observações são válidas para a relação entre formulários e tabelas.

è Um relatório também pode ser baseado diretamente em uma consulta, assim como um Formulário também pode ser baseado diretamente em uma Consulta. Quando o Formulário (ou Relatório) é aberto, o Microsoft Access executa a consulta, a qual busca os dados na Tabela, e retorna os dados para o Formulário (Ou Relatório).

è Observe que as Macros e Módulos foram colocados ao redor, envolvendo os demais elementos. Isto significa que posso ter Macros e Módulos interagindo com qualquer elemento de um banco de dados do Microsoft Access. Por exemplo, posso criar uma macro que Maximize um formulário quando o formulário é aberto. Posso criar um módulo para calcular o Dígito Verificador de um campo CPF, de tal forma que quando um CPF é digitado, o CPF não é aceito se estiver com o Dígito Verificador incorreto.

è Uma situação bastante comum é o caso em que precisamos de um relatório, porém os dados necessários não estão na forma necessária nas tabelas. Neste caso podemos criar uma consulta que selecione os dados necessários e faça as consolidações necessárias e criamos o Relatório baseado nesta consulta e não diretamente na tabela. Estes seis elementos: Tabelas, Consultas, Formulários, Relatórios, Macros e Módulos podem ser criados e gerenciados a partir da Janela Principal do Banco de Dados do Microsoft Access, conforme indicado a seguir:

Janela "Banco de Dados", dando acesso aos diversos elementos do Microsoft Access.

Alguns exemplos e situações do dia-a-dia:

Para ilustrar o relacionamento entre os diversos elementos do Microsoft Access, vamos considerar algumas situações usuais do dia-a-dia. Nossas situações serão baseadas no arquivo Northwind.mdb, o qual é instalado juntamente com o Microsoft Access, conforme descrito na Introdução.

Situação 1: Vamos supor que seja solicitado um Relatório com os totais por Pedido. Como atender esta demanda ?

Solução: Os dados necessários não estão disponíveis diretamente na tabela Pedidos. Criaremos uma consulta baseada nas tabelas Pedidos e Detalhes do Pedido. Esta consulta fará o cálculo do total por Número de Pedido. Nosso Relatório será baseado nesta consulta. Quando o Relatório for aberto, a consulta será acionada, buscará os valores nas tabelas Pedidos e Detalhes dos Pedidos, realizará os cálculos e fornecerá os valores para o Relatório. Aprenderemos a criar este tipo de consulta no decorrer deste curso.

Situação 2: Como fazer um relatório que exiba o total de Vendas por país de Destino e por Ano?

Solução: Novamente os dados necessários não estão disponíveis diretamente nas tabelas Pedidos e Detalhes do Pedido. Crio uma consulta do tipo Tabela de Referência Cruzada, baseada na Consulta que calcula os totais por Pedido. Nesta consulta adiciono um campo para o Ano do Pedido e outro campo para o País de Destino. Crio o meu relatório baseado nesta consulta. Ao ser aberto o Relatório é acionada a consulta do tipo Tabela de Referência Cruzada, a qual por sua vez aciona a Consulta na qual ela é baseada, a qual busca os dados nas tabelas. O Caminho inverso é percorrido, até que os dados são fornecidos para o Relatório, o qual exibe os mesmos na tela ou imprime na Impressora. Aprenderemos a criar este tipo de consulta no decorrer deste curso.

Situação Desafio: Os dados sobre o cabeçalho do Pedido ( tabela Pedidos) e os diversos itens de cada Pedido (Tabela Detalhes do Pedido) estão separados. Como reunir estas informações em um formulário de tal maneira que o mesmo se pareça com uma Nota Fiscal?

Solução: ?

Conclusão:

Bem amigo leitor, com este artigo, encerramos a série sobre o Modelo Relacional de dados. A recomendação mais enfática que eu posso fazer é a seguinte: "Não pense que fazer modelagem de dados é perda de tempo". Muito pelo contrário: É ganho de tempo e de qualidade em nossos programas. Sem a modelagem, você vai criando o banco na tentativa e erro, quando uma consulta não dá certo o programador faz um "gambiarra", adapta aqui, adapta ali e assim vai. Isso não é programação. Perdoem-me por ser enfático neste ponto. Isso é remendo, é tentativa e erro. Por isso que temos muitos programas com péssimo desempenho, funcionalidades que deixam a desejar, sem documentação, impossíveis de serem alterados a não ser por quem os criou. É meu mais sincero desejo que eu possa ter colaborado para, pelo menos, despertar uma reflexão no amigo leitor. Não deixe de acompanhar a série de artigos sobre TCP/IP, a qual passarei a publicar quinzenalmente. Um forte abraço.

Entre em contato. Deixe-me conhecer a sua opinião e também suas sugestões. Entre em contato através do e-mail webmaster@juliobattisti.com.br ou diretamente através de um dos seguintes sites: www.juliobattisti.com.br e www.certificacoes.com.br.