Um visão descomplicada sobre…base de dados (Parte I)

Por Progster a.k.a Vitor Lopes para o PPLWARE.COM

Em conversa com um grupo de amigos, a seguinte questão veio ao de cima: “É possível falar de bd’s de forma descomplicada?”. Eu penso que sim, e desafio quem estiver interessado no tema a ler este artigo e tirar as suas próprias conclusões.

No artigo anterior (Estruturação de uma base de dados), foram abordados alguns dos pontos mais importantes indispensáveis para que qualquer pessoa, com conhecimentos reduzidos possa dar os primeiros passos no desenvolvimento de base de dados. Desengane-se quem pensa que criar uma base de dados, é só construir meia dúzia de tabelas, aliás podemos concluir que criar uma base de dados, é muito mais do que isto, o segredo está na organização, é o planeamento prévio do que se quer desenvolver, do que se quer criar, o que leva a que por vezes seja necessário criar vários esboços da dita cuja, até que se atinga o objectivo que levou à sua criação, ou seja, corresponder às necessidades do utilizador final.

Um outro ponto, tão ou ainda mais importante a ter em conta, é a validação dos dados, que é o que irá determinar o sucesso ou insucesso de uma base de dados, ou seja, é o que irá determinar a sua utilização por parte do utilizador final.

Validação

A redundância de dados numa base de dados, é um facto que pode ocorrer em toda e qualquer base de dados, pois por mais e melhores intenções que o(s) criador(es) tenham, podem sempre escapar um ou outro pormenor por diversos motivos, seja por falta de atenção, seja pelo facto de não se poder prever toda e qualquer possível eventualidade que possa ocorrer. Em determinadas situações, são estes pormenores que podem prejudicar, até senão mesmo “destruir” todo um sistema informático.

Validação dos dados

Todos nós, de uma ou de outra maneira, já ouvimos seja em conversa com outras pessoas seja na televisão, queixas relativas a problemas com sistemas informáticos seja por exemplo, de correspondência enviada para o local errado, sejam pessoas que já faleceram, e continuam a receber correspondência, seja os problemas anuais da colocação de professores, etc,etc,etc. Isto pode ocorrer por diversas variáveis, que podem escapar ao controlo, não só do(s) criador(es), mas também do(s) utilizador(es) das respectivas bases de dados.

Não é “obrigatório”, mas mesmo antes de se criar as tabelas, já se deve ter pelo menos uma ideia do tipo de dados que a BD irá conter. Por exemplo, para um determinado campo nome, o criador deverá decidir se quer que o campo contenha o nome completo, se irá conter só o primeiro e ultimo nome, se quer que o nome seja escrito em letras minúsculas, se quer que o nome seja escrito em letras maiúsculas, se quer que as iniciais do nome sejam escritas em letras maiúsculas etc…

Alguns dos problemas que este exemplo pode evitar são:

• Redundância de dados;
• Identificação precisa de uma determinada pessoa;

Ou seja, poderá evitar (apesar da identificação de uma pessoa não ser necessariamente só feita com base no nome da mesma) que uma tabela tenha mais do que um registo para uma pessoa, melhorando não só a qualidade do serviço prestado, mas também a eficiência do atendimento à essa mesma pessoa, o que em especial nos dias de hoje é crucial para uma empresa.

Por exemplo:

• O apoio técnico da Cabovisão;

Apesar de a empresa já ter uma ficha de cliente, é pedido sempre alguns detalhes: O nome da pessoa com quem estão a falar, pois pode não a pessoa à qual o serviço está associado, o número de cliente associado à ficha de cliente, etc. Nestas e noutras situações por motivos óbvios, é sempre feita a validação dos dados inseridos na BD, por parte do operador, ou seja, para além do(s) criador(es) do programa utilizado pela empresa, terem feito a respectiva validação dos campos das tabelas de modo a permitir que os utilizadores tirem um melhor partido do mesmo, os utilizadores validam também os dados já existentes na BD, não só pelos motivos óbvios associados ao negocio em si, mas também de modo a manterem a BD actualizada, evitando alguns dos problemas já referidos anteriormente.

A validação pode também ser aplicada, a outros campos, por exemplo, pode-se definir se no campo número de telefone, se quer que contenha só 9 algarismos, se quer que apareça uma mensagem de erro para o caso de se escreverem caracteres nesse campo, etc. Como já disse anteriormente, e insisto neste pormenor, cabe ao criador da BD o que vai querer validar de modo a corresponder às necessidades do utilizador final.

De referir que validar dados, é muito mais do que foi apresentado neste artigo, o objectivo foi mesmo “apresentar” aos utilizadores com conhecimentos reduzidos, uma “nova” variável tão ou ainda mais importante a ter em conta, e que não deve ser descurada. Espero que este artigo seja uma mais-valia tanto para a comunidade, como para qualquer outro visitante, e que possa contribuir para ajudar a resolver toda, e qualquer duvida que possa surgir.