O uso universal de bases de dados relacionais consolidou um conjunto de boas práticas que actualmente são respeitadas com um rigor quase religioso pela sua comunidade de utilizadores. O baixo, ou mesmo nulo, nível de redundância (repetição dos mesmos dados em mais do que um local da base de dados) é o exemplo paradigmático, e mais conhecido, de uma das regras basilares do desenho de bases de dados relacionais. Para atingir bons níveis de redundância e de integridade da informação uma base de dados é tipicamente composta por um grande número de tabelas que se encontram ligadas entre si através de campos comuns.
A exploração da informação numa base de dados é feita através da linguagem SQL (Structured Query Language). As técnicas de programação em SQL (vulgarmente designadas como queries) são complexas e, consequentemente, fora do alcance dos utilizadores das bases de dados. Desse modo, a exploração dos dados está sempre limitada a um conjunto relativamente restrito de queries pré-programadas por especialistas na matéria. E, quando o utilizador tem uma necessidade diferente das que estão previstas inicia-se um círculo vicioso em que é feito um pedido aos informáticos, esse pedido entra na “linha de montagem” das queries, e num momento no futuro o programa é, finalmente, disponibilizado ao utilizador que avaliará a sua eficácia e formatação, o que poderá provocar um feedback (neste caso negativo) que retomará todos as etapas do circuito.
Um gestor que pretenda analisar a informação de uma base de dados segundo uma perspectiva original, para tomar uma determinada decisão tem, além de ter conhecimentos de programação em SQL, a obrigação de conhecer em profundidade o esquema da base de dados, i.e., em que tabelas estão armazenados os dados que procura e a forma como essas tabelas estão relacionadas entre si. Para um mero utilizador essas tarefas são um autêntico quebra-cabeças. Penso que nenhuma organização terá qualquer proveito em perder um bom gestor e ganhar um mau programador.
